Cloud Native and Monorepo

@DMM.go #1

Transcript

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

   2020/01/23

   

   View Slide

2. © DMM.com
   自分とDMMについて
   2
   

   View Slide

3. © DMM.com 3
   Corporate Message
   

   View Slide

4. © DMM.com 4
   Corporate Message
   DMM. ESSENCE
   "DMMらしさ" や
   "組織風土" を言語化し、
   ５のエッセンスにまとめました。
   

   View Slide

5. © DMM.com 5
   

   View Slide

6. © DMM.com 6
   

   View Slide

7. © DMM.com
   40以上の
   サービスを展開
   7
   事業について
   オンラインゲームや動画配信をはじめ
   としたエンタメコンテンツから、 DMMFX
   などの金融サービス、その他人材育成
   事業といった様々な分野の事業・活動
   に取り組んでいます。
   金融
   グローバル
   ビジネス
   教育・
   コミュニティ
   ミュージアム
   ・テーマパーク
   

   View Slide

8. © DMM.com 8
   事業について ゲーム
   エンターテインメント
   ・コンテンツ
   ハードウェア
   ・プロダクト
   自然エネルギー
   Eコマース
   40以上の
   サービスを展開
   オンラインゲームや動画配信をはじめ
   としたエンタメコンテンツから、 DMMFX
   などの金融サービス、その他人材育成
   事業といった様々な分野の事業・活動
   に取り組んでいます。
   

   View Slide

9. © DMM.com 9
   事業について
   ライフスタイル
   アミューズメント
   その他、様々なサービスを展開＆開発中↓↓
   https://www.dmm.com/
   40以上の
   サービスを展開
   オンラインゲームや動画配信をはじめ
   としたエンタメコンテンツから、 DMMFX
   などの金融サービス、その他人材育成
   事業といった様々な分野の事業・活動
   に取り組んでいます。
   

   View Slide

10. © DMM.com
    • 松本 勇気 (@y_matsuwitter)
    • DMM.com CTO / 日本CTO協会理事
    • 経歴
    • 東京大学在学中に3社のスタートアップの立ち上げ・支
    援
    • 2013年 Gunosy入社
    • Gunosyにて執行役員、CTO、新規事業担当を経て
    DMM.comへ
    • 高負荷環境のシステム設計や機械学習、VR、
    Blockchainなど新技術領域担当を歴任
    10
    自己紹介
    

    View Slide

11. © DMM.com
    本日のアジェンダ
    11
    

    View Slide

12. © DMM.com
    Cloud Native時代の開発と現状

    

    monorepoという選択肢

    

    GoとbazelでCloud Nativeなmonorepo運用

    本日のアジェンダ
    12
    Cloud Nativeな時代での実際とmonorepo運用について考えてみます。

    

    View Slide

13. © DMM.com
    Cloud Native時代の
    開発と現状
    13
    

    View Slide

14. © DMM.com
    改めて、Cloud Nativeとは？
    CNCFの定義から考えてみる。
    14
    クラウドやコンテナの利点を最大限に活用し、プロダクトの成長を高効率で支えていく。
    クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境におい
    て、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテ
    ナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型 APIがあります。
    これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わ
    せることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。
    Cloud Native Computing Foundationは、オープンソースでベンダー中立プロジェクトのエコシステムを育成・維持して、このパラダ
    イムの採用を促進したいと考えてます。 私たちは最先端のパターンを民主化し、これらのイノベーションを誰もが利用できるように
    します。
    https://github.com/cncf/toc/blob/master/DEFINITION.md より引用
    

    View Slide

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など。

    

    Ｌｌ
    

    View Slide

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
    

    View Slide

17. © DMM.com
    monorepoという選択肢
    17
    

    View Slide

18. © DMM.com 18
    Cloud Nativeでの課題
    プロダクトを複数のサービスで運用するゆえの課題が発生。
    サービス間の依存関係が多様。
    サービスによっては多様なプロトコルを利用。(gRPC, JSON,...)
    ある変更がどこに影響を与えるか見えない。
    結果として、リリース時に想定外の障害が。
    各サービス間での一貫した管理に関する課題
    

    View Slide

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など様々な基
    盤を利用するケースが多々。
    

    View Slide

20. © DMM.com
    関連する全ソースコードを一つのrepositoryで管理す
    る手法

    ● 依存する全パッケージが一箇所で管理可能。

    

    採用事例

    ● Google, Facebook

    パッケージ間のインターフェイスが一つのリポジトリに
    集約される。

    ● CI/CDを通じて変更の影響を検出しやすい。

    ● goであればstructとして共有できるので単一言
    語で構成する場合開発も比較的楽。

    

    仕組みの共有が容易

    ● デプロイや共通モジュールなど

    monorepoという選択肢
    20
    複雑化するCloud Nativeな世界に対しての緩和策として検討しうる選択肢。
    monorepoとは？ なぜmonorepoを検討するか？
    サービス間の一貫した管理を一つのrepositoryに乗せることで実現する。
    

    View Slide

21. © DMM.com
    GoとbazelでCloud Nativeな
    monorepo運用
    21
    

    View Slide

22. © DMM.com
    全サービスのソースコードが集まる。

    ● 全体をビルドしテストするコストはサービスが拡
    大するごとに成長

    

    ビルド方法の多様性

    ● 様々な基盤に合わせたツールが必要

    — Goのbuild, awsコマンド, gcloudコマンド,
    kubectl...etc

    依存関係を明示したビルド

    ● サービスやパッケージ間の依存関係を解析・記
    述

    ● 依存グラフから必要部分のみを再ビルド、テスト

    

    各環境のセットアップ

    ● ビルドツールのインストールから実行までをサ
    ポートする必要。

    monorepo運用での課題と対策
    22
    1つのrepositoryゆえの運用効率課題。

    大きなrepositoryゆえの課題 対策：賢いビルドツール
    monorepo運用に向けては適切なビルドツール運用が求められていく。
    

    View Slide

23. © DMM.com
    Bazelを活用する
    DSLベースで依存関係やビルド方法などを記述できるOSSビルドツール。
    23
    特徴
    • 依存関係に応じて影響する部分を特定しビルド
    • ビルド結果のキャッシュにより不要なビルドを行わな
    い。
    • キャッシュはローカルだけでなくリモート環境も指定
    が可能。
    • 様々な言語に対応、プラグイン機構によりビルド環
    境などもbazel側で構築できる。
    monorepoにおいての課題をうまく吸収可能な効率的ビルド環境を構築できる。
    

    View Slide

24. © DMM.com
    Goとbazelでmonorepo
    Bazel + GazelleでGoビルド環境を用意に構築可能。
    24
    $PROJECT/WORKSPACE
    

    View Slide

25. © DMM.com
    Goとbazelでmonorepo
    Bazel + GazelleでGoビルド環境を用意に構築可能。
    25
    $PROJECT/BUILD.bzl
    

    View Slide

26. © DMM.com
    Gazelleで依存関係を自動生成
    go.sumからのrepositories.bzl生成
    26
    上：repositories生成
    右：実際に生成されたrepositories.bzl
    

    View Slide

27. © DMM.com
    Gazelleで依存関係を自動生成
    リポジトリ内のgoソースコードから生成。
    27
    上：各パッケージのビルド設定生成
    右：実際に生成されたBUILD.bzl
    

    View Slide

28. © DMM.com
    インターフェイスを共有する
    grpcやjsonなどの型情報はパッケージ間で共有可能。
    28
    • 個人的な方針
    • gRPC等の生成されたgoファイルはリポジトリに
    含める。
    • そうしたインターフェイスの定義もbazel管理で
    依存関係を明示していく。
    • メリット
    • インターフェイス変更は必要なパッケージのビ
    ルドやテストに適切に反映される。
    サービス間のデータ型の変更はbazelの利用で検知できる。
    

    View Slide

29. © DMM.com
    bazelの注意点
    当然ながらツールに対する学習コストや落とし穴は多々存在する。
    29
    bazelや周辺プラグインの理解を進め、環境構築の責任者を置こう。
    依存関係を全て記述する必要がある。

    ● 各言語の機能と二重管理になるケースも。

    ● 記述の無い依存関係は解決できなくなる。

    ● 自動生成がない言語は面倒が発生。

    

    bazel自体の機能が豊富。

    ● 独特の構文と機能を使いこなすには一定の学習
    が必要。

    — DevOps担当チームによるレクチャー等が求
    められる。

    protobufとの相性

    ● bazel側機能を利用すると都度goコードを生成し
    てしまう。

    — 生成結果もコミットしたい場合はbazelを使
    わず生成する。

    

    ほとんどの生成過程をbazelのキャッシュディレクトリ
    にて実行

    ● ツール側との相性問題が出うる。

    bazel自体の課題 各ツールとの組み合わせ
    

    View Slide

30. © DMM.com
    まとめ
    30
    

    View Slide

31. © DMM.com
    依存関係をDSLで明示しビルド・
    テストを実行可能

    ● monorepo内において変更と
    影響箇所のみを対象にビル
    ド・テスト

    ● キャッシュ機能により効率的
    に再ビルド

    

    トレードオフ

    ● bazel自体の複雑さ

    — ルールを理解し、全依
    存を定義する必要

    ● 他ツールとの相性課題

    一つのリポジトリで全てを包含

    ● 全ての関連するパッケージ
    間の依存が明瞭

    ● ビルドやテスト段階で依存関
    係起因の課題を把握しやす
    い。

    

    賢いビルドツールが必要

    ● 都度真面目に全ビルドして
    は効率が悪い。

    ● ビルド方法も多様、開発者の
    負担を減らす必要。

    より効率的な運用を求めて

    ● k8s、CaaS、FaaS、Managed
    Serviceなど様々な選択肢の
    中で組み合わせる。

    

    実運用のプロダクトは様々

    ● 多様なデプロイ、多様な
    Microservices間のインター
    フェイス

    ● 効率的な管理が課題

    31
    まとめ
    Cloud Nativeな時代ではmonorepo運用も一つの選択肢として活用しうる。
    Cloud Nativeと運用課題 monorepoという選択 Bazelの利用
    

    View Slide