Cloud Native and Monorepo

@DMM.go #1

Transcript

1. © DMM.com Cloud Nativeな時代に考える monorepo DMM.go #1 DMM.com CTO 松本 勇気
 2020/01/23

2. © DMM.com 自分とDMMについて 2
3. © DMM.com 3 Corporate Message
4. © DMM.com 4 Corporate Message DMM. ESSENCE "DMMらしさ" や "組織風土" を言語化し、 ５のエッセンスにまとめました。
5. © DMM.com 5
6. © DMM.com 6
7. © DMM.com 40以上の サービスを展開 7 事業について オンラインゲームや動画配信をはじめ としたエンタメコンテンツから、 DMMFX などの金融サービス、その他人材育成 事業といった様々な分野の事業・活動 に取り組んでいます。 金融 グローバル ビジネス 教育・ コミュニティ ミュージアム ・テーマパーク
8. © DMM.com 8 事業について ゲーム エンターテインメント ・コンテンツ ハードウェア ・プロダクト 自然エネルギー Eコマース 40以上の サービスを展開 オンラインゲームや動画配信をはじめ としたエンタメコンテンツから、 DMMFX などの金融サービス、その他人材育成 事業といった様々な分野の事業・活動 に取り組んでいます。
9. © DMM.com 9 事業について ライフスタイル アミューズメント その他、様々なサービスを展開＆開発中↓↓ https://www.dmm.com/ 40以上の サービスを展開 オンラインゲームや動画配信をはじめ としたエンタメコンテンツから、 DMMFX などの金融サービス、その他人材育成 事業といった様々な分野の事業・活動 に取り組んでいます。
10. © DMM.com • 松本 勇気 (@y_matsuwitter) • DMM.com CTO / 日本CTO協会理事 • 経歴 • 東京大学在学中に3社のスタートアップの立ち上げ・支 援 • 2013年 Gunosy入社 • Gunosyにて執行役員、CTO、新規事業担当を経て DMM.comへ • 高負荷環境のシステム設計や機械学習、VR、 Blockchainなど新技術領域担当を歴任 10 自己紹介
11. © DMM.com 本日のアジェンダ 11
12. © DMM.com Cloud Native時代の開発と現状
 
 monorepoという選択肢
 
 GoとbazelでCloud Nativeなmonorepo運用
 本日のアジェンダ 12 Cloud Nativeな時代での実際とmonorepo運用について考えてみます。

13. © DMM.com Cloud Native時代の 開発と現状 13
14. © DMM.com 改めて、Cloud Nativeとは？ CNCFの定義から考えてみる。 14 クラウドやコンテナの利点を最大限に活用し、プロダクトの成長を高効率で支えていく。 クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境におい て、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテ ナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。 これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わ せることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。 Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダ イムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるように します。 https://github.com/cncf/toc/blob/master/DEFINITION.md より引用
15. © DMM.com ベンダー中立なコンテナ実行環境
 • OSSとして最も開発が盛ん。
 • KubeflowやIstioなど様々な周辺プロダクト。
 • ベンダーに縛られないため、マルチクラウドなど柔軟 な構成が可能。
 
 15 Cloud Native時代の基盤の選択肢 実際のCloud Nativeでは様々な基盤が登場、日々活用されている。 Kubernetes Container as a Service AWS ECSやAWS Fargate、GAEなど
 • コンテナ実行環境をマネージドに提供し、スケーラビ リティなどを担保。
 • k8sと比べると、各クラウドベンダ内の組み合わせを 想定し機能を薄くしてある模様。
 
 Function as a Service AWS LambdaやCloud Function
 • 小さな関数、コード単位での実行環境
 • 他ツールとのグルー的に使うなど用途は様々。
 • リソース意識が少なく済む。
 Managed Service DBやファイルストレージなど様々なレイヤで存在。
 • 各用途に対する各ベンダーの最適解。
 • 自前で運用するより楽に運用可能。
 — AWS S3、Aurora、GCP Cloud Spanner、 BigQueryなど。
 
 Ｌｌ
16. © DMM.com Cloud Nativeでのプロダクトの実際 実際のプロダクト開発でのアーキテクチャの雑な事例。 16 様々な種別のサービスを組み合わせることで各種の強みを活かし効率的、省力的に開発・運用する。 Kubernetes Cluster AWS Lambda MySQL AWS Kinesis Stream AWS Lambda AWS API Gateway AWS DynamoDB App App App App
17. © DMM.com monorepoという選択肢 17
18. © DMM.com 18 Cloud Nativeでの課題 プロダクトを複数のサービスで運用するゆえの課題が発生。 サービス間の依存関係が多様。 サービスによっては多様なプロトコルを利用。(gRPC, JSON,...) ある変更がどこに影響を与えるか見えない。 結果として、リリース時に想定外の障害が。 各サービス間での一貫した管理に関する課題
19. © DMM.com Cloud Nativeでの課題 19 Kubernetes Cluster AWS Lambda MySQL AWS Kinesis Stream AWS Lambda AWS API Gateway AWS DynamoDB App App App App JSON JSON JSON gRPC JSON 様々な型、プロトコルで App間のデータがや り取りされ、依存関係も複雑化していく傾向 にある。 Repositories デプロイ対象もk8sやLambdaなど様々な基 盤を利用するケースが多々。
20. © DMM.com 関連する全ソースコードを一つのrepositoryで管理す る手法
 • 依存する全パッケージが一箇所で管理可能。
 
 採用事例
 • Google, Facebook
 パッケージ間のインターフェイスが一つのリポジトリに 集約される。
 • CI/CDを通じて変更の影響を検出しやすい。
 • goであればstructとして共有できるので単一言 語で構成する場合開発も比較的楽。
 
 仕組みの共有が容易
 • デプロイや共通モジュールなど
 monorepoという選択肢 20 複雑化するCloud Nativeな世界に対しての緩和策として検討しうる選択肢。 monorepoとは？ なぜmonorepoを検討するか？ サービス間の一貫した管理を一つのrepositoryに乗せることで実現する。
21. © DMM.com GoとbazelでCloud Nativeな monorepo運用 21
22. © DMM.com 全サービスのソースコードが集まる。
 • 全体をビルドしテストするコストはサービスが拡 大するごとに成長
 
 ビルド方法の多様性
 • 様々な基盤に合わせたツールが必要
 — Goのbuild, awsコマンド, gcloudコマンド, kubectl...etc
 依存関係を明示したビルド
 • サービスやパッケージ間の依存関係を解析・記 述
 • 依存グラフから必要部分のみを再ビルド、テスト
 
 各環境のセットアップ
 • ビルドツールのインストールから実行までをサ ポートする必要。
 monorepo運用での課題と対策 22 1つのrepositoryゆえの運用効率課題。
 大きなrepositoryゆえの課題 対策：賢いビルドツール monorepo運用に向けては適切なビルドツール運用が求められていく。
23. © DMM.com Bazelを活用する DSLベースで依存関係やビルド方法などを記述できるOSSビルドツール。 23 特徴 • 依存関係に応じて影響する部分を特定しビルド • ビルド結果のキャッシュにより不要なビルドを行わな い。 • キャッシュはローカルだけでなくリモート環境も指定 が可能。 • 様々な言語に対応、プラグイン機構によりビルド環 境などもbazel側で構築できる。 monorepoにおいての課題をうまく吸収可能な効率的ビルド環境を構築できる。
24. © DMM.com Goとbazelでmonorepo Bazel + GazelleでGoビルド環境を用意に構築可能。 24 $PROJECT/WORKSPACE
25. © DMM.com Goとbazelでmonorepo Bazel + GazelleでGoビルド環境を用意に構築可能。 25 $PROJECT/BUILD.bzl
26. © DMM.com Gazelleで依存関係を自動生成 go.sumからのrepositories.bzl生成 26 上：repositories生成 右：実際に生成されたrepositories.bzl
27. © DMM.com Gazelleで依存関係を自動生成 リポジトリ内のgoソースコードから生成。 27 上：各パッケージのビルド設定生成 右：実際に生成されたBUILD.bzl
28. © DMM.com インターフェイスを共有する grpcやjsonなどの型情報はパッケージ間で共有可能。 28 • 個人的な方針 • gRPC等の生成されたgoファイルはリポジトリに 含める。 • そうしたインターフェイスの定義もbazel管理で 依存関係を明示していく。 • メリット • インターフェイス変更は必要なパッケージのビ ルドやテストに適切に反映される。 サービス間のデータ型の変更はbazelの利用で検知できる。
29. © DMM.com bazelの注意点 当然ながらツールに対する学習コストや落とし穴は多々存在する。 29 bazelや周辺プラグインの理解を進め、環境構築の責任者を置こう。 依存関係を全て記述する必要がある。
 • 各言語の機能と二重管理になるケースも。
 • 記述の無い依存関係は解決できなくなる。
 • 自動生成がない言語は面倒が発生。
 
 bazel自体の機能が豊富。
 • 独特の構文と機能を使いこなすには一定の学習 が必要。
 — DevOps担当チームによるレクチャー等が求 められる。
 protobufとの相性
 • bazel側機能を利用すると都度goコードを生成し てしまう。
 — 生成結果もコミットしたい場合はbazelを使 わず生成する。
 
 ほとんどの生成過程をbazelのキャッシュディレクトリ にて実行
 • ツール側との相性問題が出うる。
 bazel自体の課題 各ツールとの組み合わせ
30. © DMM.com まとめ 30
31. © DMM.com 依存関係をDSLで明示しビルド・ テストを実行可能
 • monorepo内において変更と 影響箇所のみを対象にビル ド・テスト
 • キャッシュ機能により効率的 に再ビルド
 
 トレードオフ
 • bazel自体の複雑さ
 — ルールを理解し、全依 存を定義する必要
 • 他ツールとの相性課題
 一つのリポジトリで全てを包含
 • 全ての関連するパッケージ 間の依存が明瞭
 • ビルドやテスト段階で依存関 係起因の課題を把握しやす い。
 
 賢いビルドツールが必要
 • 都度真面目に全ビルドして は効率が悪い。
 • ビルド方法も多様、開発者の 負担を減らす必要。
 より効率的な運用を求めて
 • k8s、CaaS、FaaS、Managed Serviceなど様々な選択肢の 中で組み合わせる。
 
 実運用のプロダクトは様々
 • 多様なデプロイ、多様な Microservices間のインター フェイス
 • 効率的な管理が課題
 31 まとめ Cloud Nativeな時代ではmonorepo運用も一つの選択肢として活用しうる。 Cloud Nativeと運用課題 monorepoという選択 Bazelの利用