つの重要なポイント
1. マイクロサービス: 小さく、自律的なサービスが連携する
マイクロサービスは、小さく、自律的なサービスが連携するものである。
マイクロサービスの基盤。 マイクロサービスアーキテクチャは、小さく独立したサービスのスイートとしてソフトウェアを開発する原則に基づいて構築されている。各サービスは一つのことに特化し、自身のプロセスで動作し、HTTP/REST APIのような軽量なメカニズムを通じて通信する。このアプローチは、モノリシックアーキテクチャと比較して、柔軟性、スケーラビリティ、保守性が向上する。
利点と課題。 マイクロサービスの主な利点には以下が含まれる：
- モジュール性の向上
- 個々のコンポーネントのスケーリングが容易
- 技術の多様性
- フォールトアイソレーションの強化
- デプロイメントサイクルの短縮
しかし、マイクロサービスには以下のような課題もある：
- 運用の複雑さの増加
- 分散システムの問題（例：ネットワーク遅延、フォールトトレランス）
- サービス間のデータ一貫性
2. 進化的アーキテクチャ: 変化する要件への適応
アーキテクトの役割は、大局を見て、このバランスを理解することである。
変化を受け入れる。 進化的アーキテクチャは、システムが時間とともに変化する要件に適応する必要があることを強調する。このアプローチは、すべての将来のニーズを予測することは不可能であると認識し、代わりに進化できる柔軟な基盤を作ることに焦点を当てる。
主要な原則：
- 漸進的な変更：大きな変更を少なくするよりも、小さな変更を頻繁に行う
- 指導された変更：アーキテクチャの決定を導く原則と実践を使用する
- 複数のアーキテクチャ：システムの異なる部分が異なる速度で進化することを認識する
このモデルのアーキテクトは、詳細を指示するのではなく、ガイドラインと制約を設定する都市計画者のような役割を果たす。これにより、チームはローカルな決定を行いながら、全体のシステムの一貫性を保つことができる。
3. サービスのモデリング: 境界とコンテキストの定義
サービスの境界をビジネスの境界に合わせることで、特定の機能のコードがどこにあるかが明確になる。
ドメイン駆動設計。 サービスを効果的にモデリングするには、ビジネスドメインの深い理解が必要である。ドメイン駆動設計（DDD）は、サービスの境界を定義するための貴重な概念を提供する：
- 境界づけられたコンテキスト：明確な境界を持つドメインの領域
- ユビキタス言語：開発者とドメインエキスパートが共有する共通の言語
- アグリゲート：ユニットとして扱われるドメインオブジェクトのクラスター
サービス境界の特定：
- ビジネス能力に合わせる
- データと行動をカプセル化する
- サービス間の依存関係を最小限にする
- チーム構造とコミュニケーションパターンを考慮する
明確に定義された境界は、より一貫性のあるサービスと、独立した開発とデプロイメントを促進する緩やかな結合をもたらす。
4. 統合戦略: 通信のための適切なアプローチの選択
自分が行うことには保守的であり、他者から受け入れることには寛容であれ。
統合の重要性。 効果的な統合は、マイクロサービスがシームレスに連携するために不可欠である。統合技術の選択は、システムの柔軟性、パフォーマンス、保守性に大きな影響を与える。
主要な統合パターン：
- 同期通信：REST、gRPC
- 非同期通信：メッセージキュー、イベントストリーミング
- APIゲートウェイ：リクエストルーティングとコンポジションのため
- サービスメッシュ：サービス間通信の処理
ベストプラクティス：
- 技術に依存しないプロトコル（例：HTTP）を使用する
- 変更を優雅に処理するためのトレラントリーダーを実装する
- サーキットブレーカーやバルクヘッドで障害に備える
- 緩やかな結合のためにイベント駆動アーキテクチャを検討する
適切な統合戦略は、特定のユースケース、パフォーマンス要件、チームの専門知識に依存する。
5. モノリスの分割: マイクロサービスへの移行
モノリスを大理石のブロックと考えよう。全体を爆破することもできるが、それはうまくいかないことが多い。むしろ、少しずつ削り取る方が理にかなっている。
漸進的アプローチ。 モノリシックアーキテクチャからマイクロサービスへの移行は、段階的に行うのが最善である。これにより、チームは学びながら適応し、リスクを最小限に抑えることができる。
モノリスの分割手順：
- 既存のコードベースのシームを特定する
- 境界づけられたコンテキストを別々のモジュールに抽出する
- 共有データ構造とデータベースをリファクタリングする
- モジュール間の通信のためのAPIを作成する
- モジュールを別々のサービスに抽出する
- 新機能をマイクロサービスとして実装する
考慮すべき課題：
- サービス間のデータ依存性
- サービス境界を越えたトランザクションの整合性
- ネットワーク通信のパフォーマンスへの影響
- 複数のサービスを管理する運用の複雑さ
最も簡単でリスクの少ない抽出から始めて、信頼と経験を積んでから、より複雑な部分に取り組む。
6. デプロイメント技術: 信頼性とスケーラビリティの確保
正しいことをするのが難しい場合、それを容易にする努力をすべきである。
自動化されたデプロイメント。 信頼性が高くスケーラブルなデプロイメントは、マイクロサービスの成功に不可欠である。継続的インテグレーション（CI）と継続的デリバリー（CD）の実践は、デプロイメントの複雑さを管理するために重要である。
主要なデプロイメント技術：
- インフラストラクチャー・アズ・コード（IaC）
- コンテナ化（例：Docker）
- オーケストレーションプラットフォーム（例：Kubernetes）
- ブルーグリーンデプロイメント
- カナリアリリース
デプロイメントの考慮事項：
- サービスディスカバリーと構成管理
- 監視とログ管理
- セキュリティとアクセス制御
- データベースの移行とデータの一貫性
ツールと自動化に投資して、デプロイメントをより簡単、迅速、信頼性の高いものにする。これにより、チームは頻繁に自信を持ってデプロイメントを行い、マイクロサービスアーキテクチャの利点を最大限に引き出すことができる。
7. マイクロサービスのテスト: 分散システムにおける品質の維持
動く部品が多いほど、テストは脆弱になり、決定論的でなくなる可能性が高い。
包括的なテスト戦略。 マイクロサービスのテストには、個々のサービスの品質と全体のシステムの動作を確保するための多層的なアプローチが必要である。
マイクロサービスのテストピラミッド：
- ユニットテスト：個々のコンポーネントに対する迅速で焦点を絞ったテスト
- 統合テスト：サービス間の相互作用を検証する
- コントラクトテスト：サービスが合意されたインターフェースを満たしていることを確認する
- エンドツーエンドテスト：システム全体の動作を検証する
テストの課題：
- 分散性による複雑さの増加
- サービス間のテストデータの管理
- 本番環境に近い環境のシミュレーション
- 非同期の相互作用の処理
ユニットテストと統合テストで迅速なフィードバックループを強調し、重要なパスを検証するために慎重に選ばれたエンドツーエンドテストを使用する。コンシューマードリブンコントラクトを使用して、サービス依存関係を効果的に管理することを検討する。
8. 監視とセキュリティ: マイクロサービスの健全性と保護の維持
良いログ管理、特に複数のシステムからのログを集約する能力は、予防ではなく、問題の検出と回復に役立つ。
全体的なアプローチ。 効果的な監視とセキュリティは、健全なマイクロサービスエコシステムを維持するために重要である。これらの側面は、分散システムではより挑戦的で重要になる。
監視のベストプラクティス：
- 中央集権的なログ管理とログ集約
- 分散トレーシング（例：相関IDの使用）
- リアルタイムのアラートとダッシュボード
- アプリケーションパフォーマンスモニタリング（APM）
- 重要なパスの合成監視
セキュリティの考慮事項：
- サービス間の認証と認可
- エッジセキュリティのためのAPIゲートウェイ
- シークレット管理
- ネットワークセグメンテーション
- 定期的なセキュリティ監査とペネトレーションテスト
多層防御戦略を実装し、周辺と個々のサービスの両方を保護する。自動化を使用して、すべてのサービスにわたるセキュリティポリシーの一貫した適用を確保する。
9. コンウェイの法則: 組織とシステム設計の整合
コンウェイの法則は、組織に合わないシステム設計を強制しようとする危険性を強調している。
組織への影響。 コンウェイの法則は、システム設計が組織内のコミュニケーション構造を反映することを示している。この原則は、マイクロサービスアーキテクチャにとって重要な意味を持つ。
チームとサービスの整合：
- ビジネス能力に基づいてチームを編成する
- サービスのエンドツーエンドの所有権をチームに与える
- チーム間の依存関係を最小限にする
- 協力と共有責任の文化を育む
考慮事項：
- チームのサイズと構成
- コミュニケーションパターンとツール
- 意思決定プロセス
- スキル開発と知識共有
組織構造とシステムアーキテクチャが相互に関連していることを認識する。両方を連携して進化させ、マイクロサービスの開発と運用に適した環境を作り出す。
10. マイクロサービスのスケーリング: 成長と障害の処理
スケールにおいて、最高のキットや最も高価なハードウェアを購入しても、障害が発生することを避けることはできない。
スケールと回復力の設計。 マイクロサービスアーキテクチャは、需要の増加と避けられない障害を優雅に処理するように設計されなければならない。
スケーリング戦略：
- 水平スケーリング（インスタンスの追加）
- 垂直スケーリング（インスタンスごとのリソースの増加）
- キャッシング（インメモリ、分散）
- データベースのシャーディングとレプリケーション
- 非同期処理とイベント駆動アーキテクチャ
回復力のパターン：
- カスケード障害を防ぐためのサーキットブレーカー
- フォールトアイソレーションのためのバルクヘッド
- 指数バックオフを伴うタイムアウトとリトライ
- 機能の優雅な劣化
CAP定理の考慮事項：
- 一貫性
- 可用性
- パーティション耐性
分散システムをスケーリングする際には、トレードオフが必要であることを理解する。特定の要件と制約に基づいて優先順位を付ける。観測性とカオスエンジニアリングの実践を導入して、システムの回復力を継続的に向上させる。
Last updated:
レビュー
本書『Building Microservices』は賛否両論を受けている。多くの読者は、マイクロサービスの概念に関する包括的な概要と実践的なアドバイスを称賛している。著者の慎重なアプローチと実際の事例が評価されている一方で、批評家たちは一部のトピックにおける深さの欠如や、マイクロサービスを過度に推奨する可能性を指摘している。初心者には価値があると感じる人が多いが、経験豊富なアーキテクトにはあまり役立たないと感じる人もいる。本書は、設計、デプロイメント、テスト、スケーリングなど、マイクロサービスのさまざまな側面を網羅している。具体的な実装の詳細をもっと知りたいと望む読者もいれば、ソフトウェアアーキテクチャに関する高レベルの視点を評価する読者もいる。