architecture-paradigm-microservices

マイクロサービスアーキテクチャパラダイム

このパラダイムを採用する場合

• 組織構造上、高いチームの自律性と独立したリリースサイクルが求められる場合。
• 異なるビジネス機能（境界づけられたコンテキスト）で、それぞれ異なるスケーリング要件がある場合、または異なるテクノロジースタックを活用するメリットがある場合。
• 高度なオブザーバビリティ、CI/CD、インシデント対応能力など、DevOps と SRE の成熟度向上に組織として多大な投資を行う場合。

このパラダイムを採用しない場合

• チームの規模が小さく、組織の複雑さが低い場合
• DevOps の成熟度が低い場合、またはプラットフォームエンジニアリングのリソースが限られている場合
• システム内の操作間で強いトランザクション整合性が求められる場合
• 要件が急速に変化するスタートアップの初期段階の場合
• 規制上の制約により、分散データ管理が困難な場合

導入手順

1. 境界づけられたコンテキストを定義する：各マイクロサービスを明確なビジネス機能に対応づけ、データの所有権を曖昧さなく確立します。
2. サービスのデータ自律性を検証する：各サービスは独自のデータベースまたは永続化メカニズムを所有し、管理する必要があります。サービス間でデータを共有する場合は、共有テーブルではなく、API またはイベントを介して行う必要があります。
3. 本番環境に対応したプラットフォームを構築する：サービスをデプロイする前に、サービスディスカバリー、分散トレーシング、集中ログ管理、CI/CD テンプレート、自動化されたコントラクトテストのための基盤インフラストラクチャを確立します。
4. レジリエンスを考慮して設計する：すべてのサービス間通信に、タイムアウト、再試行、サーキットブレーカー、バルクヘッドなどのレジリエンスパターンを実装します。サービスレベル指標（SLI）とサービスレベル目標（SLO）を正式に文書化します。
5. ガバナンスを自動化する：すべてのサービスで、セキュリティスキャン、依存関係管理ポリシー、一貫したバージョニング戦略を徹底する自動化プロセスを実装します。

主な成果物

• サービス境界、対応するデータストア、通信パターン（同期 API と非同期イベントなど）をすべて記録したアーキテクチャ決定記録（ADR）。
• プラットフォーム上で新しいサービスを作成し、運用するための一連の「ゴールデンパス」テンプレートとランブック。
• 単体テスト、コントラクトテスト、統合テスト、カオス／レジリエンステストを含む詳細なテスト戦略。

テクノロジーに関するガイダンス

API 通信：

• REST API：Spring Boot（Java）、Express.js（Node.js）、FastAPI（Python）
• GraphQL：Apollo Server（Node.js）、Hasura（PostgreSQL）
• gRPC：高性能な内部通信向けの gRPC フレームワーク

サービスディスカバリーと設定：

• サービスレジストリ：Consul、Eureka、etcd
• 設定：Spring Cloud Config、HashiCorp Vault、AWS Parameter Store

メッセージブローカーとイベント：

• メッセージブローカー：Apache Kafka、RabbitMQ、AWS SQS/SNS
• イベントストリーミング：Apache Kafka、Apache Pulsar、AWS Kinesis

オブザーバビリティ：

• 分散トレーシング：Jaeger、Zipkin、AWS X-Ray
• メトリクス：Prometheus、Datadog、CloudWatch
• ログ管理：ELK Stack、Fluentd、Splunk

実際の導入例

Netflix：再生、レコメンデーション、請求、ユーザー認証など、さまざまな機能を担当する数百のマイクロサービスを持つ動画ストリーミングプラットフォームです。各チームは、ほかのチームに影響を与えずに独立してデプロイできます。

Amazon：商品カタログ、注文処理、決済、在庫、配送を担当する個別のサービスを持つ e コマースプラットフォームです。Prime Day のようなトラフィックの多いイベント時に、個別にスケーリングできます。

Uber：乗客とドライバーのマッチング、ドライバーの配車、料金設定、決済処理、通知を担当するマイクロサービスを備えたライドシェアプラットフォームです。これにより、機能を迅速に開発し、デプロイできます。

リスクと軽減策

• 分散システムの複雑さ：
  • 軽減策：マイクロサービスアーキテクチャの運用負荷は相当なものです。この複雑さを管理し、サービスチームを支援するため、専任のプラットフォームチームと共有ツールに投資してください。
• データ整合性の課題：
  • 軽減策：サービス間でデータ整合性を維持することは、主要な課題です。トランザクションを調整する Saga などのパターンを採用し、メッセージベースの通信が冪等であることを検証し、結果整合性に対処するために照合ジョブを使用してください。
• サービスの粒度が不適切（「分割しすぎ」）：
  • 軽減策：サービスが小さすぎると、通信のオーバーヘッドが分散によるメリットを上回ることがあります。各サービスが、意味のある十分な機能を担っていることを検証してください。サービス間の変更の結合度を監視し、統合候補を特定してください。

具体的なコンポーネント

このパラダイムの実装に伴うことが多い、ツールと抽象化の用語集です。依存関係でも、tools: のフロントマターでもありません。

• service-boundary-analyzer：呼び出しグラフとデータ所有権の分析を通じて、候補となる境界を見つけます
• api-contract-generator：新しいサービス境界向けの OpenAPI／protobuf のひな形を生成します
• resilience-patterns：再試行、サーキットブレーカー、バルクヘッド、タイムアウトのライブラリ

完了条件

• サービスを個別にデプロイする前に、すべてのサービス境界と、それぞれのデータストアおよび通信パターン（同期 API 対非同期イベント）を記載した ADR が作成されている。
• 各サービスが独自のデータベースまたは永続化メカニズムを所有し、他のサービスのテーブルを直接読み取るサービスがない（データ所有権レビューで検証済み）。
• 本番環境にサービスを移行する前に、レジリエンスパターン（タイムアウト、再試行、サーキットブレーカー、バルクヘッド）が文書化され、サービス間のすべての呼び出しに実装されている。
• 2つ目のチームがアーキテクチャの採用を始める前に、新しいサービスの作成と運用に関する「ゴールデンパス」のランブックが用意されている。