はじめに
本資料の目的
本資料は、AWS上でマイクロサービスアーキテクチャを理解し、実践するための道しるべです。設計の考え方と、それを支えるAWSサービスの二つの軸で整理して解説します。実務で役立つ視点を重視して書いています。
対象読者
クラウドやマイクロサービスに関心のあるエンジニア、設計担当者、運用担当者向けです。初心者は全体像をつかむために順番に読むことをおすすめします。経験者は必要な章だけ参照してください。
本資料の読み方
章ごとに「考え方」「よく使うサービス」「設計と運用のポイント」「関連キーワードの広げ方」を扱います。実例を交えて説明するので、チームでの議論や設計レビューにそのまま使えます。
注意事項
専門用語はできるだけ控え、具体例で補います。環境や要件によって最適解は変わるため、本資料を出発点として各プロジェクトに合わせて調整してください。
基本的な考え方
概要
マイクロサービスは、アプリケーションを小さな自律したサービスに分けて作る考え方です。各サービスは独立してデプロイ・スケールできます。例えばECサイトなら「注文」「在庫」「認証」を別々のサービスにすると分かりやすくなります。
サービスの分割と境界
重要なのはドメイン境界を明確にすることです。機能ごとに責任を決め、重複を避けます。実務ではチームごとにサービスを所有して、変更やデプロイの権限を持たせるとスムーズです。
API契約と通信
サービス間はAPIでやり取りします。代表的な方法はHTTPのRESTやGraphQL、非同期のメッセージングです。たとえば在庫更新はイベントで通知して、注文サービスはそのイベントを受け取って処理すると性能が安定します。
データ管理と整合性
サービスごとにデータを持つことを推奨します。共有データベースは結合度を高めるため避けます。整合性は即時でなくても許容する設計（eventual consistency）で対応することが多いです。
運用と観測
個別サービスのログ・メトリクス・分散トレーシングが重要です。問題発生時にどのサービスが原因か特定しやすくなります。自動デプロイやヘルスチェックも整えておくと運用負荷が下がります。
チームと組織
技術だけでなく組織設計も大切です。小さなチームがサービスを責任持って運用する体制を作ると、変更や改善が早くなります。
AWSでよく使うサービス
この章では、実際のシステム構築でよく使うAWSの主要サービスを、用途に応じて分かりやすく説明します。具体例を交えながら、選び方のポイントもお伝えします。
コンピュート
- Amazon ECS/EKS：コンテナを使うときに選びます。ECSは設定が比較的シンプルで、EKSはKubernetesを使いたいときに向きます。たとえば複数のマイクロサービスをチームで開発する場合に便利です。
- AWS Fargate：サーバー管理をしたくないときにおすすめです。コンテナを動かすが、インスタンスの管理は不要です。小規模から中規模のサービスで運用負荷を減らせます。
- AWS Lambda：短い処理やイベント駆動に適しています。画像処理やWebhookの受け口など、短時間で完結する処理に向きます。
選び方の目安：起動時間やコスト、運用の手間で判断します。即時レスポンス重視ならLambda、細かい制御が必要ならEKS/ECS、管理を減らしたければFargateが候補です。
通信と公開
- Amazon API Gateway：外部にAPIを公開する際の入り口です。認証やレート制限を簡単に設定できます。
- Application Load Balancer（ALB）：HTTP/HTTPSの負荷分散を行います。パスごとのルーティングや複数サービスへの振り分けに便利です。
- AWS App Mesh：サービス間の通信を可視化・制御します。トラフィックの分割や観測を行いたいときに役立ちます。
具体例：外部クライアントはAPI Gatewayを叩き、内部はALBでコンテナ群に振り分け、サービス間はApp Meshで運用管理する構成が多いです。
データストア
- Amazon RDS：リレーショナルデータ（ユーザー情報やトランザクション）に向きます。バックアップやスケールが簡単です。
- Amazon DynamoDB：スケーラブルなキー・バリューストア。セッション情報やアクセスログの高速参照に適しています。
- Amazon S3：画像やログ、バックアップなどのオブジェクト保存に使います。耐久性が高くコストも抑えられます。
各サービスが独自のデータストアを持つ設計は、障害の影響を局所化できる利点があります。ただしデータの整合性や運用は注意が必要です。必要に応じてバックアップや暗号化を設定してください。
設計と運用上のポイント
観測性（Observability）
サービス間の遅延や障害箇所を可視化します。Amazon CloudWatchでメトリクスとアラームを集約し、AWS X-Rayで分散トレーシングを有効にすると経路ごとのレイテンシが分かります。ログはCloudWatch Logsや集中ログ基盤（例：ElasticsearchやS3＋Athena）へ送って検索可能にします。具体例：APIのレスポンスタイムが閾値超過時にX-Rayでどのマイクロサービスが遅いかを特定します。
デプロイ戦略
サービス単位で安全にリリースすることを優先します。Blue/GreenやカナリアリリースはCodePipeline＋CodeDeployで自動化できます。段階的にトラフィックを増やし、問題があれば即座にロールバックします。例：新バージョンを10%だけに流し、エラー率が上がれば自動で元に戻す設定。
リライアビリティ
部分障害が全体に影響しない設計を心がけます。サーキットブレーカーで故障する依存を切り、リトライ＋指数バックオフで一時的な失敗を吸収します。非同期処理はSQSやEventBridgeでバッファを設け、SNSで通知を分配します。キューの深さや処理遅延を監視し、異常時はスケールアウトやアラートを出します。
運用の実践ポイント
- SLO／監視：重要な指標にSLOを設定し、アラートは冗長にしない。
- ロギング：トレースIDを全サービスで渡す。
- テスト：カナリア環境で負荷と障害注入の検証を行う。
- 自動化：CI/CDでのデプロイ手順とロールバックを自動化する。
キーワードの広げ方
検索の基本的な考え方
目的に合わせてキーワードを少しずつ広げます。設計ガイドや実装例を探すなら「ベストプラクティス」「リファレンスアーキテクチャ」「実装例（サンプル）」などを追加します。運用や監視が目的なら「分散トレーシング」「ログ」「モニタリング」を加えます。
組み合わせ例（すぐ使えるクエリ）
- AWS マイクロサービス ベストプラクティス
- AWS サーバーレス マイクロサービス アーキテクチャ
- AWS 分散トレーシング マイクロサービス
- ECS マイクロサービス 実装例
- EKS マイクロサービス リファレンスアーキテクチャ
- API Gateway マイクロサービス パターン
検索エンジンで site:github.com や filetype:pdf を使うと、コードや設計書を見つけやすくなります（例: site:github.com “EKS マイクロサービス”）。
英語キーワードも併用する
同じテーマでも英語の情報は量が多いです。例: “AWS serverless microservices best practices”, “distributed tracing microservices”。英語と日本語を組み合わせると実務に近い情報が見つかります。
情報の見極め方
公式ドキュメント、AWSのリファレンスアーキテクチャ、GitHubのスター数や更新日を確認します。ブログは実装例が詳しいことが多いですが、古い記事だと非推奨の手法が混ざるので日付を確認してください。
検索後の整理と共有
気になった記事やリポジトリはブックマークやノートで整理します。タグを付けると後で用途別に探しやすくなります。チームで使う場合は共有ドキュメントにまとめ、短い説明を添えておくと役立ちます。
これらの方法でキーワードを広げると、設計ガイド、実装サンプル、運用ノウハウを効率よく見つけられます。
