課題13: ヘルスケアアプリのマイクロサービス化
難易度: 🟡 中級
1. 分類情報
| 項目 | 内容 |
|---|---|
| 難易度 | 初級〜中級 |
| カテゴリ | マイクロサービス・API |
| 処理タイプ | 非同期 |
| 使用IaC | Terraform |
| 想定所要時間 | 6-7時間 |
2. シナリオ
企業プロフィール
〇〇株式会社は、健康管理アプリを提供するヘルスケアスタートアップです。ユーザー数は20万人を超え、日々の活動量、食事記録、睡眠データを管理するサービスを展開しています。
現状の課題
サービス開始から3年が経過し、モノリシックなアーキテクチャの限界に直面しています：
- デプロイの複雑化：全機能が1つのアプリケーションに集約され、小さな変更でも全体のデプロイが必要
- スケーリングの非効率：特定機能（活動量記録）に負荷が集中しても、全体をスケール
- 技術的負債の蓄積：PHP製のモノリスに新機能追加が困難
- チーム間の競合：5チームが1つのコードベースを共有し、マージコンフリクトが多発
数値で見る問題
- デプロイ頻度：月 2回（リスクが高く慎重になる）
- デプロイ所要時間：4時間
- インシデント発生率：デプロイごとに 30%
- 機能追加のリードタイム：3ヶ月
成功指標（KPI）
| 指標 | 現状 | 目標 |
|---|---|---|
| デプロイ頻度 | 2回/月 | 週1回以上/サービス |
| デプロイ時間 | 4時間 | 30分/サービス |
| インシデント発生率 | 30%/デプロイ | 5%以下 |
| 機能追加リードタイム | 3ヶ月 | 2週間 |
3. 達成目標
主要な学習成果
- モノリスからマイクロサービスへの段階的移行手法
- ECS Fargateによるコンテナ基盤の構築
- ALBを使ったパスベースルーティング
- サービス間通信パターンの理解
習得するスキル
- Strangler Fig パターンによる移行
- Docker マルチステージビルド
- ECS サービスディスカバリ
- ALB ターゲットグループの管理
4. 学習するAWSサービス
メインサービス
| サービス | 用途 | 重要度 |
|---|---|---|
| ECS Fargate | マイクロサービス実行 | 高 |
| ALB | ルーティング・ロードバランシング | 高 |
| RDS (Aurora) | データベース | 高 |
| ElastiCache (Redis) | キャッシュ・セッション | 中 |
補助サービス
| サービス | 用途 |
|---|---|
| ECR | コンテナイメージ保存 |
| Cloud Map | サービスディスカバリ |
| Secrets Manager | 認証情報管理 |
| CloudWatch | ログ・メトリクス |
| X-Ray | 分散トレーシング |
5. 最終構成図
現状（モノリス）
目標（マイクロサービス）
移行計画（5フェーズ）
| フェーズ | 内容 | 期間目安 |
|---|---|---|
| 1 | インフラ基盤構築（VPC、ECS、ALB） | - |
| 2 | User Service 抽出・移行 | - |
| 3 | Activity Service 抽出・移行 | - |
| 4 | Meal / Sleep Service 移行 | - |
| 5 | モノリス廃止・最終検証 | - |
6. 前提条件
必要な知識
- コンテナとDockerの基本
- REST API設計の基礎
- データベース設計の基礎
事前準備
- AWSアカウント
- AWS CLI v2
- Docker Desktop
- Terraform CLI
7. トラブルシューティング課題
Challenge 1: サービス間通信のタイムアウト
状況: Activity Service から User Service への呼び出しがタイムアウト
調査ポイント:
- Security Group のルールを確認
- Service Discovery の名前解決を確認
- ターゲットのヘルスチェック状態を確認
Challenge 2: データ整合性の問題
状況: User Service でユーザーを削除したが、Activity Service に古いデータが残っている
調査ポイント:
- キャッシュの TTL を確認
- イベント駆動の同期を検討
- Saga パターンの導入を検討
Challenge 3: デプロイ順序の依存関係
状況: User Service の API 変更により、Activity Service が動作しなくなった
調査ポイント:
- API のバージョニング戦略を確認
- 後方互換性の維持
- Consumer-Driven Contract Testing の導入
8. 設計の考察ポイント
ディスカッション1: データ分割戦略
テーマ: 共有DBからサービス別DBへの移行
| パターン | メリット | デメリット |
|---|---|---|
| Shared Database | シンプル、トランザクション | 結合度が高い |
| Database per Service | 独立性高い | 分散トランザクション |
| Shared Schema | 移行が容易 | 中途半端 |
ディスカッション2: 同期 vs 非同期通信
テーマ: サービス間通信パターンの選択
| パターン | ユースケース |
|---|---|
| REST (同期) | 即座の応答が必要 |
| gRPC (同期) | 高パフォーマンス要件 |
| Event (非同期) | 疎結合、耐障害性重視 |
ディスカッション3: Strangler Fig パターン
テーマ: 段階的移行の進め方
ステップ:
- ファサードの導入（ALB ルーティング）
- 機能単位での切り出し
- データ移行
- 旧機能の廃止
9. 発展課題
Advanced 1: サービスメッシュの導入
課題: AWS App Mesh を導入し、サービス間通信の可観測性とトラフィック制御を向上
Advanced 2: イベント駆動アーキテクチャ
課題: Amazon EventBridge を使って、サービス間をイベント駆動で疎結合に
Advanced 3: CQRS パターン
課題: 読み取りと書き込みを分離し、読み取り専用のビューを作成
10. 想定コストと削減方法
月額コスト概算
| サービス | 構成 | 月額コスト |
|---|---|---|
| ECS Fargate | 0.5vCPU / 1GB × 10タスク | $180 |
| ALB | 1 | $16 |
| Aurora Serverless v2 | 4 ACU | $345 |
| ElastiCache | cache.t3.small | $24 |
| NAT Gateway | 1 | $32 |
| ECR | 10GB | $1 |
| CloudWatch | ログ・メトリクス | $20 |
合計: 約 $618/月（約93,000円）
11. 学習のポイント
重要な概念の整理
Strangler Fig パターン
- 段階的にモノリスを置き換え
- リスクを最小化しながら移行
- ファサード（ALB）でルーティング制御
サービス境界の設計
- ドメイン駆動設計（DDD）の境界付けられたコンテキスト
- データの所有権を明確に
- API契約の重要性
分散システムの課題
- ネットワーク障害への対応
- 結果整合性の受け入れ
- 分散トランザクションの回避
GCPとの比較
| 概念 | AWS | GCP |
|---|---|---|
| コンテナ実行 | ECS Fargate | Cloud Run |
| ロードバランサー | ALB | Cloud Load Balancing |
| サービスディスカバリ | Cloud Map | Service Directory |
| マネージドDB | Aurora | Cloud SQL / AlloyDB |
| キャッシュ | ElastiCache | Memorystore |
次のステップ
- 残りのサービス（Meal, Sleep）の移行
- CI/CD パイプラインの構築
- 可観測性の強化（X-Ray, CloudWatch）