精読「マイクロサービスアーキテクチャ 第2版」(第二部 実装 - 第7章 ビルド)
マイクロサービスアーキテクチャ 第2版
マイクロサービスの設計、実装、運用に必要なベストプラクティスや最新技術を解説した、実践的なガイドブックです。これを読めば、マイクロサービスに関してそれっぽい会話もできますよ。
関連記事
継続的インテグレーション（CI）とは
継続的インテグレーション（CI）は、頻繁にコードを統合し、同期を保つことで品質を確保する手法。CIサーバーはコードのコミットを検出し、ビルドやテストを自動化。
**IaC（インフラをコードとして管理）**を活用すれば、コードやインフラ構成を一元管理でき、変更の透明性やビルド再現性が向上する。
本当にCIを行っているか
CI（継続的インテグレーション）を本当に実践しているかを確認するには、以下の3つの質問が重要
-
1日1回メインラインにチェックインしているか
頻繁にコードをメインブランチに統合することで、将来の統合トラブルを防げる。最低でも1日1回の統合が推奨される。 -
変更を検証するためのテストスイートがあるか
テストなしの統合は、単にコードが構文的に動作することを確認するだけで、システムの振る舞いへの影響を見逃す可能性がある。CIには、期待通りに動作するかを確かめるテストが必須。 -
ビルドが壊れた際に、それを修正することを最優先しているか
ビルドが失敗した場合、修正がチームの最優先事項でなければ、問題が蓄積し修正が困難になる。ビルドをグリーン状態に戻すことを徹底することが、CIを効果的に運用する鍵である。
CIツールを導入するだけでは不十分で、これらの実践を通じて初めてCIを真に活用できるようになる
ブランチモデル
-
ブランチ作成の利点と課題
- ソースコードブランチ（機能ブランチ）は、他の作業に影響を与えずに開発できるが、統合を遅らせることで最終的なマージが複雑になる。
-
トランクベース開発の推奨
- 頻繁な統合と検証が利点。機能フラグを活用し、不完全なコードを隠蔽しながら同じトランクで作業する。これにより効率が向上する。
-
調査結果の裏付け
- DORAや「State of DevOps」レポートによる研究では、高パフォーマンスなチームは短寿命のブランチ（1日未満）を使用し、トランクベース開発を採用している。これが継続的デリバリ成功の重要な要素とされる。
-
オープンソース開発との違い
- オープンソースは信頼できない貢献者を考慮したプロセスが必要で、長寿命ブランチを使用することが多い。ただし、クローズドソースでは短寿命ブランチや小さな変更が望ましい。
-
生産性向上の手段
- 短寿命ブランチ、小さく読みやすいパッチ、変更の自動テストを活用することで、開発者全体の生産性が向上する。
結論として、日常の開発では短寿命ブランチやトランクベース開発を取り入れるべきであり、特に小さな変更を早く統合することが重要。
ビルドパイプラインと継続的デリバリ（CD）
ビルドパイプラインは、高速テストを最初に実行し、成功後に低速テストを行うことで効率的なフィードバックを得る仕組み。同じ成果物を各ステージで使用し、本番環境での動作に確信を持てる。
継続的デリバリ（CD）は、すべてのチェックインをリリース候補として扱い、パイプラインの状態を可視化して迅速な修正と再テストを可能にする。
ツール
継続的デリバリ（CD）には、パイプラインを定義・可視化し、本番環境までの工程をモデル化できるツールが必要。自動と手動のステージを組み合わせ、進捗を管理・最適化する
成果物の作成
マイクロサービスのデプロイにおいて、成果物は一度だけビルドし、再利用することが推奨されている。成果物を作成する際には、ビルドの構成が毎回異なると問題が発生するため、一貫性を保つことが重要。ビルドされた成果物は、適切なリポジトリ（例: Artifactory、Nexus、コンテナレジストリ）に保存され、その後のすべてのパイプラインステージで再利用される。
また、異なる環境（テスト、パフォーマンス、本番環境など）で使用する場合、環境固有の設定は成果物の外部に保持し、同じ成果物を使い回す。これにより、デプロイの整合性が保たれ、効率的な運用が可能となる。
ソースコードとビルドのマイクロサービスへのマッピング
１つの巨大リポジトリ、１つの巨大ビルド
1つの巨大リポジトリと単一のビルドを使うアプローチは、初期段階で短期間に簡単に運用できる場合があるが、いくつかの重大な欠点がある。
- 例えば、1つのサービスに対する小さな変更でも、他のすべてのサービスが再ビルドされ、テストされるため、時間がかかり、サイクルタイムが遅くなる。
- また、どの成果物をデプロイすべきかを判断するのが難しく、結果的に全サービスをまとめてデプロイすることが多くなり、問題を引き起こす。
- さらに、ビルドが壊れると他のサービスの変更ができなくなる可能性がある。
このアプローチは、**モノリポ（monorepo）**と似ており、複数の独立したマイクロサービスのデプロイには適していないとされています。
パターン：マイクロサービスごとに１つのリポジトリ（別名マルチリポ）
各マイクロサービスが独立したリポジトリを持ち、コード変更がCIビルドに連動する。これにより、マイクロサービスごとの所有権管理が可能だが、複数リポジトリで作業する際に変更をアトミックに行うのが難しく、依存関係の管理やサービス間の結合が強くなる問題がある。
多くの変更が必要な場合は、モノリポアプローチが適していることもある。
パターン：モノリポ
複数のマイクロサービスのコードを同じリポジトリに保存する。この方法により、コードの変更を複数のプロジェクトにわたって一貫して行え、再利用性が高まる。代表的な例はGoogleで、同じリポジトリ内で複数のサービスを管理し、アトミックな変更を可能にしている。
モノリポの利点として、コードの可視性向上や、プロジェクト間での再利用が簡単に行える点がある。しかし、リポジトリが大規模になると、ビルドやデプロイの管理が複雑になる。ビルドプロセスは、リポジトリ内のフォルダをビルドにマッピングする方法で管理され、変更があったファイルに関連するビルドをトリガーする。
モノリポアプローチのデメリットは、管理ツールやビルドシステムの複雑さ。特に大規模なプロジェクトでは、効率的に依存関係を管理するために高度なツール（例：Bazel）が必要。
どの方法を使うべきか
モノリポは小規模チームでは問題ないが、組織が成長すると管理が困難になり、マルチリポの方が適している。モノリポの管理には追加投資が必要で、サンクコストの誤謬に陥りやすいため、方針転換が重要。
参考
Discussion