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

少人数でのサービス開発・運用を支えるためのインフラ構成についての解説資料です。

Transcript

1. 高速多品種開発・運用を支える BonBonのインフラ 藤原 涼馬
2. 自己紹介 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月号特集記事) ▪ ほか
3. 目次 3 • BonBonが実現したいことってなんだ？ • 制約事項 • 制約事項を反映したアーキテクチャの考え方 • 実現したアーキテクチャ • アーキテクチャの詳細 • まとめ
4. 4 BonBonが実現 したいことってなんだ?
5. BonBonが実現したいこと 5 医療にかかわる人に感動と喜びを
6. つまり(藤原の解釈) 6 医療従事者・患者など医療に関わるすべての人たちが ”気持ちよく”医療行為に関われるようにする
7. つまり(藤原の解釈) 7 医療従事者・患者など医療に関わるすべての人たちが ”気持ちよく”医療行為に関われるようにする その実現手段としての 医療・ヘルスケアサービスの開発・提供
8. 主に開発・提供(開発中のもの含む)しているサービス 8 名称のみ • Porous • Trepo • Manabon • Aiseki • stluke ◦ などなど
9. 主に開発・提供(開発中のもの含む)しているサービス 9 名称のみ • Porous • Trepo • Manabon • Aiseki • stluke ◦ などなど 提供している(またはしようとしている)ものは多い
10. 主に開発・提供(開発中のもの含む)しているサービス 10 名称のみ • Porous • Trepo • Manabon • Aiseki • stluke ◦ などなど 提供している(またはしようとしている)ものは多い かつ、世の中に存在しないジャンルのサービスばかりなので どんどん仮説検証サイクルを回して進化させる余地がある
11. 前提と制約事項 11 1. 事業アイデアはたくさん ◦ 新規領域でいくらでも仮説検証したいことはある 2. ただし、人手は多くない ◦ 人海戦術で対応みたいな戦略は取れない
12. 前提と制約事項 12 1. 事業アイデアはたくさん ◦ 新規領域でいくらでも仮説検証したいことはある 2. ただし、人手は多くない ◦ 人海戦術で対応みたいな戦略は取れない エンジニアリング観点では、 開発・運用ともに徹底的な効率化が必要
13. 注意点 13 ただし、医療系サービスという性質上、 一定以上の非機能品質（特にセキュリティ）が求められる エンジニアリング観点では、 開発・運用ともに徹底的な効率化が必要
14. つまり 14 • 少人数で • 一定以上の非機能品質を保ちつつ • 効率的に開発・運用できる仕組みをつくる
15. 15 制約事項をクリアするための 方針とアーキテクチャ
16. 制約事項をクリアするための方針 16 • 開発の効率化 ◦ バックエンドの技術スタックの標準化 • 運用の効率化 ◦ 運用しなければいけない範囲の最小化 ◦ システムアーキテクチャの標準化
17. 制約事項をクリアするための方針 17 • 開発の効率化 ◦ バックエンドの技術スタックの標準化 • 運用の効率化 ◦ 運用しなければいけない範囲の最小化 ◦ システムアーキテクチャの標準化
18. バックエンドの技術スタックの標準化 18 個々のサービスの構築においては言語選択は自由でも問題はな いが、組織全体で見ると大きな問題につながる
19. バックエンドの技術スタックの標準化 19 個々のサービスの構築においては言語選択は自由でも問題はな いが、組織全体で見ると大きな問題につながる • 認知負荷の増大 • 知見の横展開の困難化
20. バックエンドの技術スタックの標準化 20 したがってバックエンドAPI開発には Go言語を全面的に利用するように選択
21. Why? Go言語 21 • インフラ構成(後述)と合わせたときのビルド容易性 • “比較的”低い学習コスト
22. 制約事項をクリアするための方針 22 • 開発の効率化 ◦ バックエンドの技術スタックの標準化 • 運用の効率化 ◦ 運用しなければいけない範囲の最小化 ◦ システムアーキテクチャの標準化
23. 運用しなければいけない範囲の最小化 23 提供したいのはサービス サービスを提供するための計算リソースが欲しい
24. 運用しなければいけない範囲の最小化 24 提供したいのはサービス サービスを提供するための計算リソースが欲しい 計算リソース ≒ 仮想サーバ
25. 運用しなければいけない範囲を最小化するための選択 25 • GCE ◦ 仮想マシンを直接利用することで自由度は高いが、 管理の手間は最も大きい • GKE ◦ Managed Kubernetesの利用によって、自由度も高く保ちつつ管理も 容易。 ◦ 但し、Kubernetesのバージョンそのものの管理の手間が起きる • Cloud Run ◦ サーバーレス ◦ ビルド済みのコンテナイメージさえあれば良い
26. 運用しなければいけない範囲を最小化するための選択 26 • GCE ◦ 仮想マシンを直接利用することで自由度は高いが、 管理の手間は最も大きい • GKE ◦ Managed Kubernetesの利用によって、自由度も高く保ちつつ管理も 容易。 ◦ 但し、Kubernetesのバージョンそのものの管理の手間が起きる • Cloud Run ◦ サーバーレス ◦ ビルド済みのコンテナイメージさえあれば良い
27. 運用しなければいけない範囲を最小化するための選択 27 • GCE ◦ 仮想マシンを直接利用することで自由度は高いが、 管理の手間は最も大きい • GKE ◦ Managed Kubernetesの利用によって、自由度も高く保ちつつ管理も 容易。 ◦ 但し、Kubernetesのバージョンそのものの管理の手間が起きる • Cloud Run ◦ サーバーレス ◦ ビルド済みのコンテナイメージさえあれば良い アプリケーションの実行基盤には 原則 Cloud Runを利用
28. 制約事項をクリアするための方針 28 • 開発の効率化 ◦ バックエンドの技術スタックの標準化 • 運用の効率化 ◦ 運用しなければいけない範囲の最小化 ◦ システムアーキテクチャの標準化
29. システムアーキテクチャの標準化(同期処理) 29 Cloud Runを利用 Cloud Run
30. システムアーキテクチャの標準化(同期処理) 30 これで運用コストや非機能品質を担保できるか?? サービス1 サービス2 サービス3 サービスN-1 サービスN
31. システムアーキテクチャの標準化(同期処理) 31 これで運用コストや非機能品質を担保できるか?? サービス1 サービス2 サービス3 サービスN-1 サービスN 正直しんどい
32. システムアーキテクチャの標準化(同期処理) 32 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway
33. システムアーキテクチャの標準化(同期処理) 33 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway まず最初にモニタリングすべきポイントを 定めることでサービスの運用を効率化 & OpenAPI specによって公開API、公開範 囲などを明示
34. システムアーキテクチャの標準化(同期処理) 34 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway まず最初にモニタリングすべきポイントを 定めることでサービスの運用を効率化 & OpenAPI specによって公開API、公開範 囲などを明示 何か問題が出たときに見るポイントを明確化 (その上で掘るべきサービスを確認)
35. システムアーキテクチャの標準化(同期処理) 35 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway Firebase Authentication
36. システムアーキテクチャの標準化(同期処理) 36 サービス1 サービス2 サービス3 サービスN-1 サービスN API Gateway Firebase Authentication 認証にFirebase Authenticaionなどを利用 API GatewayのOpen API定義で記述 Open APIとFirebase Authenticationほか で認証まわりの品質を担保
37. システムアーキテクチャの標準化(非同期処理) 37 Cloud PubSubを利用 　 Cloud Run Compute Engine Pub/Sub 1時間以内で終了する処理の場合 1時間以内で終了しない処理の場合
38. システムアーキテクチャの標準化関連まとめ 38 同期処理 非同期処理 ※ データの永続化には Cloud SQLやGCSを利用 バックエンドAPIの言語選択
39. アーキテクチャの標準化によって得られたメリット 39 • サービス横断でのAPIの活用の容易化 ◦ API Gateway経由で他サービスとの連携が比較的容易にできた • 開発環境の標準化 • CI/CDアーキテクチャの標準化
40. アーキテクチャの標準化によって得られたメリット 40 • サービス横断でのAPIの活用の容易化 ◦ API Gateway経由で他サービスとの連携が比較的容易にできた • 開発環境の標準化 • CI/CDアーキテクチャの標準化
41. 開発環境の標準化 41 Cloud Runをベースとして利用することを前提とすることで開発環 境についても標準化を図れている
42. 開発環境の標準化 42 Cloud Runをベースとして利用することを前提とすることで開発環 境についても標準化を図れている Cloud Codeを使った開発 https://cloud.google.com/code
43. Cloud Codeのメリット 43 • ローカルでCloud Runを実行してテスト可能 ◦ 仕組み的にはローカルでminikubeとknativeとGoogle Cloudの認証プ ラグインを組み合わせて実現 • ローカルでGCPのサービスアカウントをセキュアに利用できる ◦ jsonファイルをエクスポートすること無く利用できる • VSCodeやJetBrainsのIDE(IntelliJやGoLand)などのプラグイ ンが提供されている
44. Cloud Codeのメリット 44 • ローカルでCloud Runを実行してテスト可能 ◦ 仕組み的にはローカルでminikubeとknativeとGoogle Cloudの認証プ ラグインを組み合わせて実現 • ローカルでGCPのサービスアカウントをセキュアに利用できる ◦ jsonファイルをエクスポートすること無く利用できる • VSCodeやJetBrainsのIDE(IntelliJやGoLand)などのプラグイ ンが提供されている これについては一度使ってみたほうが良い (サーバーレスの開発体験が全然変わる )
45. アーキテクチャの標準化によって得られたメリット 45 • サービス横断でのAPIの活用の容易化 ◦ API Gateway経由で他サービスとの連携が比較的容易にできた • CI/CDアーキテクチャの標準化 喋るべき内容が多々あるのでコレは別途 章立てして説明
46. 46 CI/CDの標準化
47. 47 基本的なポイント 1. CI/CDはCloud Buildで実現 2. バックエンドの言語を標準化(Go言語)している 3. Cloud Runを利用している 4. API Gatewayを利用している
48. 48 基本的なポイント 1. CI/CDはCloud Buildで実現 2. バックエンドの言語を標準化(Go言語)している 3. Cloud Runを利用している 4. API Gatewayを利用している
49. 2. バックエンドの言語を標準化(Go言語)している 49 • Go Modulesを利用することでパッケージ管理を実施 • Dockerのマルチステージビルドを利用して最小要素のみを含 むコンテナイメージを作成 ◦ less code, less vulnarability ◦ buildpackの利用も検討中 • CIではdocker-composeでテストを実行 docker-compose up --build --exit-code-from=xxxx
50. 2. バックエンドの言語を標準化(Go言語)している 50 • Go Modulesを利用することでパッケージ管理を実施 • Dockerのマルチステージビルドを利用して最小要素のみを含 むコンテナイメージを作成 ◦ less code, less vulnarability ◦ buildpackの利用も検討中 • CIではdocker-composeでテストを実行 docker-compose up --build --exit-code-from=xxxx
51. 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
52. 3. API Gatewayを利用している 52 API Gatewayでも同様の仕組みがあるため特定のサービスのみを新バージョンに入れ 替えたGatewayを準備してQAを実行する API Gateway 本番ドメイン 本番用 OpenAPI spec サービス1 (リビジョンN) サービス2 (リビジョンN) サービス3 (リビジョンN) サービス3 (リビジョンN+1) 動作確認用ドメイン (動的に払い出し) 動作確認用 OpenAPI spec
53. 4. 安全なCDを志向した手順 53 以下のようなステップを開発環境や本番環境で実行することで 安全なデプロイを実現している サービス3ではリビジョンN+1 のリビジョンタグドメインにア クセスするよう OpenAPI specをCDパイプラ イン内で動的に生成 0. デプロイ前 1.新しいリビジョンをデプロイ 　(トラフィックなし) 2.新しいリビジョンに リビジョンタグドメインを紐付け 3. API Gatewayで動作確認用のOpenAPI specを生成(リビジョンN+1に流す) 4. 問題なさそうであればサービス 3のトラフィッ クをリビジョンNからリビジョンN+1に切替(カナリ アリリースも可能)
54. 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のドメイン払い出しまでを 実現することで実施が可能
55. 注意点(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を生成
56. CI/CDまとめ 56 • Cloud Build便利(あまり語ってないが) • Cloud RunのリビジョンとAPI Gatewayの組み合わせでかなり 効率的かつ安全なリリースが実現できる • 但しシステムアーキテクチャやアプリケーションのビルド手順 がある程度標準化していないと構築の手間が増えるので技術 スタック、アーキテクチャを絞り込むことは必須
57. 全体のまとめ 57 • 少人数で高速多品種開発・運用を実現するためのBonBon における取り組み内容について解説しました • キーポイントは以下です ◦ 技術スタック、アーキテクチャを絞り込むことによるCI/CD実現の容易 化、ノウハウの横断的な適用による開発の効率化 ◦ サーバーレスやAPIゲートウェイを使うことによるサービス開発以外の 運用タスクの最小化と監視・モニタリングにおける起点の提供
58. 今後進めていきたいこと 58 • テストの改善 ◦ テストピラミッドの考え方に準拠したテストの充実と品質の可視化 & 客 観的な品質改善の方向性の策定 • 監視・モニタリング品質の向上 ◦ プロダクションで動くものが増えてきたため運用品質を高めたい ◦ モニタリングをしやすい仕組みは考慮した設計にはしているつもりなの で通知や対応プロセスなどを作り込む(予定)
59. 59 内容は以上です。 ご清聴ありがとうございました