【初心者向け】クラウドにおけるマイクロサービス通信パターン
対象読者
- クラウド上でマイクロサービス開発を検討しているアーキテクト・開発者
- AWS, Google Cloud, Azureにおけるサービス間通信の実装方法の違いを知りたい方
- 同期通信と非同期通信の使い分けを整理したい方
TL;DR
- マイクロサービス間の通信は、システムの性能と信頼性を決める最重要要素です。
- 同期通信には「内部LB」「動的なエンドポイント」「APIゲートウェイ」のパターンを使い分けます。
- 非同期通信には「メッセージキュー/イベントバス」を利用し、サービス間の疎結合性を高めます。
はじめに：マイクロサービスと「通信」の重要性
マイクロサービスアーキテクチャとは？
マイクロサービスアーキテクチャとは、一つの大きなアプリケーションを、独立してデプロイ可能な小さな「サービス」の集合体として構築する設計手法です。巨大な一枚岩（モノリシック）なアプリケーションに比べ、サービスごとにチームを分けられたり、最適な技術を選べたりと、開発の俊敏性やスケーラビリティに優れています。
なぜ「通信」が鍵となるのか？
しかし、サービスを分割した代償として、サービス間の通信という新たな複雑さが生まれます。ある機能を実現するために、複数のサービスが連携して動作する必要があるからです。この通信がボトルネックになったり、一部のサービスの障害がシステム全体に波及（連鎖障害）したりする危険性があります。
そのため、堅牢なマイクロサービスを構築するには、要件に応じて適切な通信パターンを選択することが不可欠です。この記事では、その中核となる4つのパターンを解説します。
第1章：内部ロードバランサによるVPC内通信
目的: 仮想ネットワーク（VPC/VNet）内で、サービス間の同期的な直接通信を安全かつ効率的に行う。
これはマイクロサービス間のトラフィックを管理する最も基本的なパターンです。サービスAがサービスBのAPIを直接呼び出し、応答を待つようなケースで利用します。
1-1. L7 (HTTP/S) ロードバランシング
| クラウド | 主要サービス | 特徴 |
|---|---|---|
| AWS | Application Load Balancer (ALB) (Internal) | パス・ホスト・ヘッダー情報に基づく高度なルーティング。ターゲットグループ単位でのヘルスチェックや、Lambda関数を直接呼び出す機能が強力。 |
| Google Cloud | Internal Application Load Balancer | Envoyプロキシベースのモダンなアーキテクチャ。Cloud Run, GKE, VMなど多様なバックエンドに統一的な方法でルーティング可能。リージョン単位で動作。 |
| Microsoft Azure | Azure Application Gateway (Private IP) | Web Application Firewall (WAF)を統合可能で、セキュリティを重視する構成に強い。パスベースルーティング、SSLオフロードなど標準的な機能を網羅。 |
1-2. L4 (TCP/UDP) ロードバランシング
| クラウド | 主要サービス | 特徴 |
|---|---|---|
| AWS | Network Load Balancer (NLB) (Internal) | 超低レイテンシと高スループットを実現。固定の静的IPアドレスを割り当て可能で、ソースIPアドレスをバックエンドに維持したまま転送できる。 |
| Google Cloud | Internal Passthrough Network Load Balancer | パケットをそのままバックエンドに転送するため非常に高速。TCP, UDPに加え、ICMPなど多様なプロトコルに対応する柔軟性が特徴。 |
| Microsoft Azure | Azure Load Balancer (Internal) | TCP/UDPに対応した標準的なL4ロードバランサ。Standard SKUでは、高可用性を実現するHAポートなどの高度な機能を提供。 |
第2章：動的なエンドポイントの解決
目的: コンテナやサーバーレスのように、IPアドレスが動的に変わるサービスのエンドポイントを、ハードコーディングせずに発見・解決する。
サービスが増加し、動的にスケールする環境では、エンドポイントの管理が破綻します。この課題を解決するのがサービスディスカバリです。
| クラウド | 主要サービス | 特徴・実現方法 |
|---|---|---|
| AWS | AWS Cloud Map | フルマネージドのサービスレジストリ。APIコールまたはプライベートDNS経由でサービスを発見できる。ECSやEKSとのシームレスな統合が非常に強力で、コンテナ環境のデファクトスタンダード。 |
| Google Cloud | Service Directory | クラウド全体のサービスレジストリとして機能。GKE, Cloud Run, VMなど、異なるコンピュート環境で稼働するサービスを統一的に管理できる点が強み。DNSやgRPCでの名前解決にも対応。 |
| Microsoft Azure | (組み合わせアプローチ) | 直接的な競合サービスはなく、複数のサービスを組み合わせて実現する。 ・基本: Azure DNS Private Zones を用いた静的な名前解決。 ・AKS: Kubernetes標準のDNS (CoreDNS) を利用。 ・サーバーレス: Azure Container Appsが持つDapr連携によるサービス呼び出し機能などを活用。 |
第3章：APIゲートウェイによる外部公開
目的: 内部のマイクロサービス群を、外部クライアントに対して、安全かつ統制された「統一的な窓口」として公開する。
認証・認可、流量制御、ロギングといった非機能要件をAPIゲートウェイに集約することで、個々のマイクロサービスはビジネスロジックに集中できます。
| クラウド | 主要サービス | 特徴 |
|---|---|---|
| AWS | Amazon API Gateway | 用途に応じて3タイプ（REST API, HTTP API, WebSocket API）から選択可能。特にHTTP APIは低コスト・低レイテンシでモダンな構成に適している。CognitoやLambda Authorizerによる柔軟な認証が強力。 |
| Google Cloud | API Gateway | OpenAPI SpecificationでのAPI定義が必須。Cloud Run, Functions, GKEなどサーバーレス/コンテナとの親和性が高い。認証はAPIキー, JWT, Google IDトークンに対応。 |
| Microsoft Azure | Azure API Management (APIM) | 開発者ポータルの自動生成、ポリシーによるリクエスト/レスポンスの柔軟な変換など、APIライフサイクル全体の管理機能が非常に充実している。エンタープライズ向けの本格的なAPI基盤。 |
第4章：非同期メッセージングによる疎結合な連携
目的: サービス間の直接的な依存を断ち切り、システム全体の耐障害性を向上させる。
これまでの同期通信とは異なり、サービスAがメッセージを投げっぱなし（Publish）にし、サービスBは自分のタイミングでメッセージを受け取って処理する非同期のパターンです。これにより、サービスBが一時的にダウンしていても、サービスAは影響を受けずに処理を続けられます。
| クラウド | 主要サービス | 特徴 |
|---|---|---|
| AWS | ・Amazon SQS (キュー) ・Amazon SNS (Pub/Sub) ・Amazon EventBridge (イベントバス) |
用途別にサービスが細分化されているのが特徴。SQSは1対1の確実なタスク伝達、SNSは1対多のファンアウト、EventBridgeは多様なイベントソースを連携させるハブとして機能する。 |
| Google Cloud | Cloud Pub/Sub | キューとPub/Subの機能を兼ね備えた、シンプルかつ非常にスケーラブルなサービス。プッシュ型・プル型の両方に対応し、フィルタリングや順序保証などの高度な機能も提供。 |
| Microsoft Azure | ・Azure Service Bus (キュー/Pub/Sub) ・Azure Event Grid (イベントバス) |
Service Busは高信頼性が求められる業務トランザクション（順序保証、重複排除など）に強い。Event GridはAzure内外の様々なイベントをトリガーに処理を起動する、リアクティブなシステム構築に特化。 |
第5章：まとめ - 最適なパターンを選択するために
4つの通信パターンは、それぞれに明確な役割があります。
- APIゲートウェイ: 外部からのリクエストを受け付ける最初の入口。
- 内部ロードバランサ: 内部でサービス同士が同期的に、かつ直接的に連携する際の基本。
- 動的なエンドポイント解決: コンテナなど動的な環境で、サービスを発見するための仕組み。
- 非同期メッセージング: サービス間の疎結合性と耐障害性を高めたい場合の最有力候補。
堅牢なシステムは、これらのパターンを適切に組み合わせることで実現されます。例えば、APIゲートウェイが受けたリクエストをきっかけに、一部は同期的に処理しつつ、時間のかかる処理は非同期メッセージングで後続のサービスに依頼する、といったハイブリッドな構成が一般的です。
各クラウドの特色を理解し、プロジェクトの要件に最も合った通信パターンを選択することが、マイクロサービス開発成功への道筋となります。
公式リファレンス
- AWS: ALB, NLB, Cloud Map, API Gateway, SQS, SNS, EventBridge
- Google Cloud: Internal Application LB, Internal Passthrough Network LB, Service Directory, API Gateway, Pub/Sub
- Microsoft Azure: Application Gateway, Load Balancer, DNS Private Zones, API Management, Service Bus, Event Grid