microservices-architect

マイクロサービスアーキテクト

目的

マイクロサービスアーキテクチャの設計と実装に関する専門知識を提供します。サービスの分割、サービス間通信パターン、サービスメッシュの実装、分散システムの課題解決を専門としています。

使用するタイミング

• モノリスをマイクロサービスに分割する
• サービス境界と API を定義する
• サービスメッシュ（Istio、Linkerd）を実装する
• API ゲートウェイパターンを設計する
• 分散トランザクション（Saga パターン）に対応する
• イベント駆動型通信を実装する
• サービスディスカバリーとロードバランシングを設定する
• 耐障害性を考慮した設計を行う（サーキットブレーカー、リトライ）

クイックスタート

このスキルを呼び出す場合：

• マイクロサービスをゼロから設計する
• 既存のモノリスを分割する
• サービス間通信を実装する
• サービスメッシュまたは API ゲートウェイを設定する
• 分散システムの課題を解決する

呼び出さない場合：

• レガシーシステムを段階的に移行する → /legacy-modernizer を使用する
• イベントストリーミングアーキテクチャ → /event-driven-architect を使用する
• Kubernetes の運用 → /kubernetes-specialist を使用する
• 単一サービスの API 設計 → /api-designer を使用する

意思決定フレームワーク

Communication Pattern?
├── Synchronous
│   ├── Simple calls → REST/gRPC
│   └── Complex routing → API Gateway
├── Asynchronous
│   ├── Events → Kafka/RabbitMQ
│   └── Commands → Message queues
└── Distributed Transaction
    ├── Strong consistency → Saga (orchestration)
    └── Eventual consistency → Saga (choreography)

主なワークフロー

1. サービスの分割

1. ドメインモデルから境界づけられたコンテキストを特定する
2. サービスの責任（単一の目的）を定義する
3. 各サービスの API を設計する
4. サービスごとのデータ所有権を決定する
5. サービス間通信を計画する
6. デプロイ戦略を定義する

2. サービスメッシュの実装

1. メッシュ（Istio、Linkerd、Consul）を選択する
2. サイドカープロキシをデプロイする
3. トラフィック管理を設定する
4. セキュリティのために mTLS を実装する
5. 可観測性（トレーシング、メトリクス）を設定する
6. リトライとサーキットブレーカーのポリシーを定義する

3. Saga パターンの実装

1. 分散トランザクションの境界を特定する
2. オーケストレーションとコレオグラフィーのどちらを採用するか選択する
3. 補償トランザクションを定義する
4. （オーケストレーション方式の場合）Saga コーディネーターを実装する
5. 障害シナリオに対応する
6. Saga の状態を監視する仕組みを追加する

ベストプラクティス

• 技術レイヤーではなく、ビジネス機能を中心にサービスを設計する
• データを所有する。各サービスが独自のデータベースを管理する
• 疎結合にするため、非同期通信を使用する
• 耐障害性を確保するため、サーキットブレーカーを実装する
• 障害を前提に設計する。いずれはすべてが失敗する
• 分散トレーシングには相関 ID を使用する

アンチパターン

アンチパターン	問題	適切なアプローチ
分散モノリス	サービスが結合し、両方の悪い点を抱える	適切な境界づけられたコンテキスト
共有データベース	密結合	サービスごとにデータベースを用意する
同期処理の連鎖	障害が連鎖する	可能な限り非同期にする
サーキットブレーカーなし	障害が連鎖する	Hystrix/Resilience4j を実装する
ナノサービス	運用上のオーバーヘッド	適切な規模のサービス