高速多品種開発・運用を支えるBonBonのインフラ

by BonBon

Slide 1

Slide 1 text

高速多品種開発・運用を支える BonBonのインフラ藤原涼馬

Slide 2

Slide 2 text

自己紹介 2 藤原涼馬 ● 経歴 ○ ユーザー系SIerにて研究員として活動した後、 2016年1月より大手メディア系企業にて新規サービス (主にHR系サービスが中心)構築支援、およびパブリッククラウド利活用の標準化について活動 ○ 並行して大手金融機関のグループ企業などにてパブリッククラウドのインフラ改善などの活動に従事 ● 得意?領域 ○ パブリッククラウドインフラストラクチャ・ CI/CD ● 社外実績 ○ コミュニティ・イベント運営 ■ Japan Container DaysおよびCloud Native Days Tokyo 2019/2020実行委員 ■ Rancher JPコアメンバー ○ 執筆・出版 Articles & publications ■ 先行事例に学ぶKubernetes企業活用の現実(@IT) ■ コンテナベースのCI/CD本番事例大解剖(@IT) ■ マルチクラウド時代の最強コンビ　 RancherによるKubernetes活用ガイド(ThinkIT) ■ RancherによるKubernetes活用完全ガイド(インプレス) ■ WAF実践 (Web+DB Press vol.123, 2021年6月号特集記事) ■ ほか

Slide 3

Slide 3 text

目次 3 ● BonBonが実現したいことってなんだ？ ● 制約事項 ● 制約事項を反映したアーキテクチャの考え方 ● 実現したアーキテクチャ ● アーキテクチャの詳細 ● まとめ

Slide 4

Slide 4 text

4 BonBonが実現したいことってなんだ?

Slide 5

Slide 5 text

BonBonが実現したいこと 5 医療にかかわる人に感動と喜びを

Slide 6

Slide 6 text

つまり(藤原の解釈) 6 医療従事者・患者など医療に関わるすべての人たちが ”気持ちよく”医療行為に関われるようにする

Slide 7

Slide 7 text

つまり(藤原の解釈) 7 医療従事者・患者など医療に関わるすべての人たちが ”気持ちよく”医療行為に関われるようにするその実現手段としての医療・ヘルスケアサービスの開発・提供

Slide 8

Slide 8 text

主に開発・提供(開発中のもの含む)しているサービス 8 名称のみ ● Porous ● Trepo ● Manabon ● Aiseki ● stluke ○ などなど

Slide 9

Slide 9 text

主に開発・提供(開発中のもの含む)しているサービス 9 名称のみ ● Porous ● Trepo ● Manabon ● Aiseki ● stluke ○ などなど提供している(またはしようとしている)ものは多い

Slide 10

Slide 10 text

主に開発・提供(開発中のもの含む)しているサービス 10 名称のみ ● Porous ● Trepo ● Manabon ● Aiseki ● stluke ○ などなど提供している(またはしようとしている)ものは多いかつ、世の中に存在しないジャンルのサービスばかりなのでどんどん仮説検証サイクルを回して進化させる余地がある

Slide 11

Slide 11 text

前提と制約事項 11 1. 事業アイデアはたくさん ○ 新規領域でいくらでも仮説検証したいことはある 2. ただし、人手は多くない ○ 人海戦術で対応みたいな戦略は取れない

Slide 12

Slide 12 text

前提と制約事項 12 1. 事業アイデアはたくさん ○ 新規領域でいくらでも仮説検証したいことはある 2. ただし、人手は多くない ○ 人海戦術で対応みたいな戦略は取れないエンジニアリング観点では、開発・運用ともに徹底的な効率化が必要

Slide 13

Slide 13 text

注意点 13 ただし、医療系サービスという性質上、一定以上の非機能品質（特にセキュリティ）が求められるエンジニアリング観点では、開発・運用ともに徹底的な効率化が必要

Slide 14

Slide 14 text

つまり 14 ● 少人数で ● 一定以上の非機能品質を保ちつつ ● 効率的に開発・運用できる仕組みをつくる

Slide 15

Slide 15 text

15 制約事項をクリアするための方針とアーキテクチャ

Slide 16

Slide 16 text

制約事項をクリアするための方針 16 ● 開発の効率化 ○ バックエンドの技術スタックの標準化 ● 運用の効率化 ○ 運用しなければいけない範囲の最小化 ○ システムアーキテクチャの標準化

Slide 17

Slide 17 text

制約事項をクリアするための方針 17 ● 開発の効率化 ○ バックエンドの技術スタックの標準化 ● 運用の効率化 ○ 運用しなければいけない範囲の最小化 ○ システムアーキテクチャの標準化

Slide 18

Slide 18 text

バックエンドの技術スタックの標準化 18 個々のサービスの構築においては言語選択は自由でも問題はないが、組織全体で見ると大きな問題につながる

Slide 19

Slide 19 text

バックエンドの技術スタックの標準化 19 個々のサービスの構築においては言語選択は自由でも問題はないが、組織全体で見ると大きな問題につながる ● 認知負荷の増大 ● 知見の横展開の困難化

Slide 20

Slide 20 text

バックエンドの技術スタックの標準化 20 したがってバックエンドAPI開発には Go言語を全面的に利用するように選択

Slide 21

Slide 21 text

Why? Go言語 21 ● インフラ構成(後述)と合わせたときのビルド容易性 ● “比較的”低い学習コスト

Slide 22

Slide 22 text

制約事項をクリアするための方針 22 ● 開発の効率化 ○ バックエンドの技術スタックの標準化 ● 運用の効率化 ○ 運用しなければいけない範囲の最小化 ○ システムアーキテクチャの標準化

Slide 23

Slide 23 text

運用しなければいけない範囲の最小化 23 提供したいのはサービスサービスを提供するための計算リソースが欲しい

Slide 24

Slide 24 text

運用しなければいけない範囲の最小化 24 提供したいのはサービスサービスを提供するための計算リソースが欲しい計算リソース ≒ 仮想サーバ

Slide 25

Slide 25 text

運用しなければいけない範囲を最小化するための選択 25 ● GCE ○ 仮想マシンを直接利用することで自由度は高いが、管理の手間は最も大きい ● GKE ○ Managed Kubernetesの利用によって、自由度も高く保ちつつ管理も容易。 ○ 但し、Kubernetesのバージョンそのものの管理の手間が起きる ● Cloud Run ○ サーバーレス ○ ビルド済みのコンテナイメージさえあれば良い

Slide 26

Slide 26 text

運用しなければいけない範囲を最小化するための選択 26 ● GCE ○ 仮想マシンを直接利用することで自由度は高いが、管理の手間は最も大きい ● GKE ○ Managed Kubernetesの利用によって、自由度も高く保ちつつ管理も容易。 ○ 但し、Kubernetesのバージョンそのものの管理の手間が起きる ● Cloud Run ○ サーバーレス ○ ビルド済みのコンテナイメージさえあれば良い

Slide 27

Slide 27 text

運用しなければいけない範囲を最小化するための選択 27 ● GCE ○ 仮想マシンを直接利用することで自由度は高いが、管理の手間は最も大きい ● GKE ○ Managed Kubernetesの利用によって、自由度も高く保ちつつ管理も容易。 ○ 但し、Kubernetesのバージョンそのものの管理の手間が起きる ● Cloud Run ○ サーバーレス ○ ビルド済みのコンテナイメージさえあれば良いアプリケーションの実行基盤には原則 Cloud Runを利用

Slide 28

Slide 28 text

制約事項をクリアするための方針 28 ● 開発の効率化 ○ バックエンドの技術スタックの標準化 ● 運用の効率化 ○ 運用しなければいけない範囲の最小化 ○ システムアーキテクチャの標準化

Slide 29

Slide 29 text

システムアーキテクチャの標準化(同期処理) 29 Cloud Runを利用 Cloud Run

Slide 30

Slide 30 text

システムアーキテクチャの標準化(同期処理) 30 これで運用コストや非機能品質を担保できるか?? サービス1 サービス2 サービス3 サービスN-1 サービスN

Slide 31

Slide 31 text

システムアーキテクチャの標準化(同期処理) 31 これで運用コストや非機能品質を担保できるか?? サービス1 サービス2 サービス3 サービスN-1 サービスN 正直しんどい

Slide 32

Slide 32 text

システムアーキテクチャの標準化(同期処理) 32 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway

Slide 33

Slide 33 text

システムアーキテクチャの標準化(同期処理) 33 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway まず最初にモニタリングすべきポイントを定めることでサービスの運用を効率化 & OpenAPI specによって公開API、公開範囲などを明示

Slide 34

Slide 34 text

システムアーキテクチャの標準化(同期処理) 34 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway まず最初にモニタリングすべきポイントを定めることでサービスの運用を効率化 & OpenAPI specによって公開API、公開範囲などを明示何か問題が出たときに見るポイントを明確化 (その上で掘るべきサービスを確認)

Slide 35

Slide 35 text

システムアーキテクチャの標準化(同期処理) 35 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway Firebase Authentication

Slide 36

Slide 36 text

システムアーキテクチャの標準化(同期処理) 36 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway Firebase Authentication 認証にFirebase Authenticaionなどを利用 API GatewayのOpen API定義で記述 Open APIとFirebase Authenticationほかで認証まわりの品質を担保

Slide 37

Slide 37 text

システムアーキテクチャの標準化(非同期処理) 37 Cloud PubSubを利用　 Cloud Run Compute Engine Pub/Sub 1時間以内で終了する処理の場合 1時間以内で終了しない処理の場合

Slide 38

Slide 38 text

システムアーキテクチャの標準化関連まとめ 38 同期処理非同期処理 ※ データの永続化には Cloud SQLやGCSを利用バックエンドAPIの言語選択

Slide 39

Slide 39 text

アーキテクチャの標準化によって得られたメリット 39 ● サービス横断でのAPIの活用の容易化 ○ API Gateway経由で他サービスとの連携が比較的容易にできた ● 開発環境の標準化 ● CI/CDアーキテクチャの標準化

Slide 40

Slide 40 text

アーキテクチャの標準化によって得られたメリット 40 ● サービス横断でのAPIの活用の容易化 ○ API Gateway経由で他サービスとの連携が比較的容易にできた ● 開発環境の標準化 ● CI/CDアーキテクチャの標準化

Slide 41

Slide 41 text

開発環境の標準化 41 Cloud Runをベースとして利用することを前提とすることで開発環境についても標準化を図れている

Slide 42

Slide 42 text

開発環境の標準化 42 Cloud Runをベースとして利用することを前提とすることで開発環境についても標準化を図れている Cloud Codeを使った開発 https://cloud.google.com/code

Slide 43

Slide 43 text

Cloud Codeのメリット 43 ● ローカルでCloud Runを実行してテスト可能 ○ 仕組み的にはローカルでminikubeとknativeとGoogle Cloudの認証プラグインを組み合わせて実現 ● ローカルでGCPのサービスアカウントをセキュアに利用できる ○ jsonファイルをエクスポートすること無く利用できる ● VSCodeやJetBrainsのIDE(IntelliJやGoLand)などのプラグインが提供されている

Slide 44

Slide 44 text

Cloud Codeのメリット 44 ● ローカルでCloud Runを実行してテスト可能 ○ 仕組み的にはローカルでminikubeとknativeとGoogle Cloudの認証プラグインを組み合わせて実現 ● ローカルでGCPのサービスアカウントをセキュアに利用できる ○ jsonファイルをエクスポートすること無く利用できる ● VSCodeやJetBrainsのIDE(IntelliJやGoLand)などのプラグインが提供されているこれについては一度使ってみたほうが良い (サーバーレスの開発体験が全然変わる )

Slide 45

Slide 45 text

アーキテクチャの標準化によって得られたメリット 45 ● サービス横断でのAPIの活用の容易化 ○ API Gateway経由で他サービスとの連携が比較的容易にできた ● CI/CDアーキテクチャの標準化喋るべき内容が多々あるのでコレは別途章立てして説明

Slide 46

Slide 46 text

46 CI/CDの標準化

Slide 47

Slide 47 text

47 基本的なポイント 1. CI/CDはCloud Buildで実現 2. バックエンドの言語を標準化(Go言語)している 3. Cloud Runを利用している 4. API Gatewayを利用している

Slide 48

Slide 48 text

48 基本的なポイント 1. CI/CDはCloud Buildで実現 2. バックエンドの言語を標準化(Go言語)している 3. Cloud Runを利用している 4. API Gatewayを利用している

Slide 49

Slide 49 text

2. バックエンドの言語を標準化(Go言語)している 49 ● Go Modulesを利用することでパッケージ管理を実施 ● Dockerのマルチステージビルドを利用して最小要素のみを含むコンテナイメージを作成 ○ less code, less vulnarability ○ buildpackの利用も検討中 ● CIではdocker-composeでテストを実行 docker-compose up --build --exit-code-from=xxxx

Slide 50

Slide 50 text

2. バックエンドの言語を標準化(Go言語)している 50 ● Go Modulesを利用することでパッケージ管理を実施 ● Dockerのマルチステージビルドを利用して最小要素のみを含むコンテナイメージを作成 ○ less code, less vulnarability ○ buildpackの利用も検討中 ● CIではdocker-composeでテストを実行 docker-compose up --build --exit-code-from=xxxx

Slide 51

Slide 51 text

Cloud RunのサービスA 3. Cloud Runを利用している 51 Cloud Runのrevision毎にトラフィックをコントロールしたり、revision毎にURLを発行できるのでこれを利用本番リリース時ドメイン revision N-1 revision N 0% 100% Cloud RunのサービスA ドメイン revision N-1 100% Cloud RunのサービスA ドメイン revision N-1 revision N 100% 0% --no-trafficで新リビジョンをデプロイして切替テスト時 Cloud RunのサービスA ドメイン revision N-1 revision N 0% 100% Cloud RunのサービスA ドメイン revision N-1 100% リビジョンタグドメインリビジョンにタグを付与して固有のドメインを払い出してテストテスト用URL

Slide 52

Slide 52 text

3. API Gatewayを利用している 52 API Gatewayでも同様の仕組みがあるため特定のサービスのみを新バージョンに入れ替えたGatewayを準備してQAを実行する API Gateway 本番ドメイン本番用 OpenAPI spec サービス1 (リビジョンN) サービス2 (リビジョンN) サービス3 (リビジョンN) サービス3 (リビジョンN+1) 動作確認用ドメイン (動的に払い出し) 動作確認用 OpenAPI spec

Slide 53

Slide 53 text

4. 安全なCDを志向した手順 53 以下のようなステップを開発環境や本番環境で実行することで安全なデプロイを実現しているサービス3ではリビジョンN+1 のリビジョンタグドメインにアクセスするよう OpenAPI specをCDパイプライン内で動的に生成 0. デプロイ前 1.新しいリビジョンをデプロイ　(トラフィックなし) 2.新しいリビジョンにリビジョンタグドメインを紐付け 3. API Gatewayで動作確認用のOpenAPI specを生成(リビジョンN+1に流す) 4. 問題なさそうであればサービス 3のトラフィックをリビジョンNからリビジョンN+1に切替(カナリアリリースも可能)

Slide 54

Slide 54 text

4. 安全なCDを志向した手順 54 以下のようなステップを開発環境や本番環境で実行することで安全なデプロイを実現しているサービス3ではリビジョンN+1 のリビジョンタグドメインにアクセスするよう OpenAPI specをCDパイプライン内で動的に生成 0. デプロイ前 1.新しいリビジョンをデプロイ　(トラフィックなし) 2.新しいリビジョンにリビジョンタグドメインを紐付け 3. API Gatewayで動作確認用のOpenAPI specを生成(リビジョンN+1に流す) 4. 問題なさそうであればサービス 3のトラフィックをリビジョンNからリビジョンN+1に切替(カナリアリリースも可能) 開発環境であれば、PRをトリガーとすることで API Gatewayのドメイン払い出しまでを実現することで実施が可能

Slide 55

Slide 55 text

注意点(QAおよび動作確認用API Gateway払い出しまでの流れ) 55 一つのAPI Gatewayに複数のサービス(＝Cloud Runサービス)がぶら下がる形になるのでCloud Buildの工夫が必要 GitHub ・あるサービスで PRを作成 Cloud Build ・Cloud Runでリビジョンをデプロイ & リビジョンに紐付いたドメインを生成 Cloud PubSub ・どのサービスでリビジョンが生成されたかを受け取って通知 Cloud Build ・Cloud Runでリビジョンをデプロイ & リビジョンに紐付いたドメインを生成 PR作成 (Cloud Runデプロイのトリガー ) Cloud Runのデプロイ (新規リビジョンのデプロイ &ドメイン生成) API Gatewayデプロイ (動的に生成された設定に基づいた Gateway生成) Terraformを使って動的に API GatewayのOpenAPI specとgatewayを生成

Slide 56

Slide 56 text

CI/CDまとめ 56 ● Cloud Build便利(あまり語ってないが) ● Cloud RunのリビジョンとAPI Gatewayの組み合わせでかなり効率的かつ安全なリリースが実現できる ● 但しシステムアーキテクチャやアプリケーションのビルド手順がある程度標準化していないと構築の手間が増えるので技術スタック、アーキテクチャを絞り込むことは必須

Slide 57

Slide 57 text

全体のまとめ 57 ● 少人数で高速多品種開発・運用を実現するためのBonBon における取り組み内容について解説しました ● キーポイントは以下です ○ 技術スタック、アーキテクチャを絞り込むことによるCI/CD実現の容易化、ノウハウの横断的な適用による開発の効率化 ○ サーバーレスやAPIゲートウェイを使うことによるサービス開発以外の運用タスクの最小化と監視・モニタリングにおける起点の提供

Slide 58

Slide 58 text

今後進めていきたいこと 58 ● テストの改善 ○ テストピラミッドの考え方に準拠したテストの充実と品質の可視化 & 客観的な品質改善の方向性の策定 ● 監視・モニタリング品質の向上 ○ プロダクションで動くものが増えてきたため運用品質を高めたい ○ モニタリングをしやすい仕組みは考慮した設計にはしているつもりなので通知や対応プロセスなどを作り込む(予定)

Slide 59

Slide 59 text

59 内容は以上です。ご清聴ありがとうございました