AWS VPC Latticeで構築するマイクロサービス間通信の冗長設計|マルチAZ対応の実践パターン

運営:リナックスマスター.JP(代表 宮崎智広)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > AWS(Amazon Linux) > AWS VPC Latticeで構築するマイクロサービス間通信の冗長設計|マルチAZ対応の実践パターン
「マイクロサービスが増えるにつれ、サービス間の通信管理が煩雑になってきた」
「VPCピアリングやTransit Gatewayだけでは、細かいアクセス制御や冗長設計が難しい」

AWS環境でマイクロサービスアーキテクチャを採用するケースが増える中、サービス間通信のルーティングと冗長性の確保は重要な設計課題です。この記事では、AWS VPC Latticeを活用したマイクロサービス間通信の冗長設計と、マルチAZ対応の実践パターンを解説します。

この記事では、Amazon Linux 2023環境を想定し、VPC Latticeのアーキテクチャ構成からマルチAZ冗長設計の具体的なパターン、トラブルシューティングまでをカバーします。

この記事のポイント

・AWS VPC Latticeはクロスアカウント・クロスVPC間のサービス通信をフルマネージドで制御できる
・マルチAZ冗長設計はターゲットグループに複数AZのターゲットを登録しヘルスチェックを有効化して構成する
・加重ルーティングでBlue/Greenデプロイやカナリアリリースを実現できる
・障害調査はアクセスログをCloudWatch Logsに出力してターゲット別のエラー状況を確認する


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

AWS VPC Latticeとは?マイクロサービス間通信の新標準

AWS VPC Latticeは、AWSが提供するフルマネージドのアプリケーションネットワーキングサービスです。これまでマイクロサービス間の通信には、VPCピアリング、Transit Gateway、API Gatewayなど複数のサービスを組み合わせる必要がありましたが、VPC Latticeはサービス間通信の制御・観測・冗長化を統合的に扱えます。

VPC Latticeが解決する主な課題:

・クロスVPC通信の複雑さ:異なるVPC・AWSアカウント間のサービス通信をシンプルに接続できる
・アクセス制御の統一:IAMポリシーとLattice独自の認証ポリシーで細かいアクセス制御が可能
・冗長設計の自動化:マルチAZのターゲットグループとヘルスチェックによるフェイルオーバーを自動化できる
・可観測性の向上:CloudWatchとの統合により、サービス間通信のメトリクスやアクセスログを一元管理できる

VPC Latticeの最大の特徴は、サービスネットワーク(Service Network)を仲介することで、VPCの数や構成に依存せずにサービス間通信を管理できる点にあります。サービスネットワークに複数のVPCを関連付けるだけで、それぞれのVPC内リソースが相互に通信できる環境が整います。

VPC Latticeのアーキテクチャ構成要素

VPC Latticeを使った冗長設計を理解するには、まず構成要素を把握しておくことが重要です。

1. サービスネットワーク(Service Network)

サービスネットワークは、複数のサービスをグループ化する論理的なコンテナです。VPCをサービスネットワークに関連付けることで、そのVPC内のリソースがネットワーク上のすべてのサービスにアクセスできるようになります。

・関連付けの単位:1つのサービスネットワークに複数のVPCを関連付けられる
・マルチアカウント対応:AWS Resource Access Manager(RAM)経由で別アカウントのVPCも関連付け可能
・IAMポリシー:サービスネットワーク単位でアクセスポリシーを定義できる

2. サービス(Service)とターゲットグループ(Target Group)

サービスは、実際のアプリケーション(EC2インスタンス、Lambdaファンクション、ECSコンテナなど)へのルーティングを定義します。サービスにはリスナーとルーティングルールを設定し、ターゲットグループにトラフィックを振り分けます。

# サービスの構成イメージ Service └── Listener(HTTP/HTTPS/gRPC) └── Rules(ルーティングルール) ├── Path-based routing(パスベースルーティング) ├── Header-based routing(ヘッダーベースルーティング) └── Target Group(ターゲットグループ) ├── AZ-a: EC2インスタンス x 2 └── AZ-c: EC2インスタンス x 2

ターゲットグループの登録先として指定できるリソースタイプ:

・EC2インスタンス(Instance):インスタンスIDを指定
・IPアドレス(IP):プライベートIPを指定(コンテナにも対応)
・Lambdaファンクション(Lambda):関数ARNを指定
・ALB(Application Load Balancer):ALBのARNを指定

マルチAZ冗長設計の基本パターン

VPC Latticeでマルチ冗長設計を構成する核心は、ターゲットグループへのヘルスチェック設定と複数AZへのターゲット分散にあります。

1. マルチAZターゲットグループの構成

冗長設計の基本は、ターゲットグループに複数AZのターゲットを登録することです。以下はAWS CLIでターゲットグループを作成する際の設定例です(出力例(環境により異なります))。

# ターゲットグループの作成(CLIコマンド例) aws vpc-lattice create-target-group \ --name "myservice-tg" \ --type INSTANCE \ --config '{ "port": 8080, "protocol": "HTTP", "vpcIdentifier": "vpc-xxxxxxxx", "healthCheck": { "enabled": true, "protocol": "HTTP", "path": "/health", "port": 8080, "healthyThresholdCount": 2, "unhealthyThresholdCount": 3, "intervalSeconds": 30, "timeoutSeconds": 10 } }' # 出力例(環境により異なります) { "arn": "arn:aws:vpc-lattice:ap-northeast-1:123456789012:targetgroup/tg-xxxxxxxxxxxxxxxxx", "id": "tg-xxxxxxxxxxxxxxxxx", "name": "myservice-tg", "status": "CREATE_IN_PROGRESS", "type": "INSTANCE" }

ヘルスチェックの設定ポイント:

・healthyThresholdCount:2回以上の連続成功でHealthyに遷移(デフォルト2)
・unhealthyThresholdCount:3回以上の連続失敗でUnhealthyに遷移(デフォルト3)
・intervalSeconds:ヘルスチェックの間隔(30秒推奨。短くしすぎると対象への負荷増大)
・timeoutSeconds:ヘルスチェックのタイムアウト(intervalSecondsより小さい値を指定)

2. AZ間トラフィック分散の確認

ターゲットをマルチAZに登録した後、各AZのターゲットが正常に稼働しているか確認します。

# AZ-a(ap-northeast-1a)とAZ-c(ap-northeast-1c)にターゲットを登録 aws vpc-lattice register-targets \ --target-group-identifier "tg-xxxxxxxxxxxxxxxxx" \ --targets '[ {"id": "i-aaaaaaaaaaaaaaaa1", "port": 8080}, {"id": "i-aaaaaaaaaaaaaaaa2", "port": 8080}, {"id": "i-bbbbbbbbbbbbbbbb1", "port": 8080}, {"id": "i-bbbbbbbbbbbbbbbb2", "port": 8080} ]' # ターゲットの健全性確認 aws vpc-lattice list-targets \ --target-group-identifier "tg-xxxxxxxxxxxxxxxxx" # 出力例(環境により異なります) { "items": [ {"id": "i-aaaaaaaaaaaaaaaa1", "port": 8080, "status": {"state": "HEALTHY"}}, {"id": "i-aaaaaaaaaaaaaaaa2", "port": 8080, "status": {"state": "HEALTHY"}}, {"id": "i-bbbbbbbbbbbbbbbb1", "port": 8080, "status": {"state": "HEALTHY"}}, {"id": "i-bbbbbbbbbbbbbbbb2", "port": 8080, "status": {"state": "HEALTHY"}} ] }

i-axxxxxxx系がAZ-a(ap-northeast-1a)、i-bxxxxxxx系がAZ-c(ap-northeast-1c)に配置されているイメージです。すべてのターゲットがHEALTHY状態であることを確認してから本番運用に移行してください。

3. フェイルオーバー動作の設計

VPC Latticeのフェイルオーバーは、ターゲットのヘルスチェック失敗に応じて自動的に動作します。特定のターゲットがUnhealthyになった場合、そのターゲットへのトラフィックが自動停止し、残りのHealthyなターゲットにルーティングされます。

フェイルオーバー設計で意識すべきポイント:

・最低2AZ×最低2ターゲット:1つのAZが完全に障害になっても残りのAZでサービス継続できる構成を基本とする
・ヘルスチェックパスの実装:アプリケーション側に/healthエンドポイントを実装し、依存するDBやキャッシュの接続状態も含めた総合的な死活確認を返すようにする
・ターゲット数の余裕:1ターゲットがUnhealthyになっても処理が詰まらないよう、残りのターゲットで十分なスループットが出る構成にする

実践的な冗長設計パターン

VPC Latticeの冗長設計をさらに発展させる実践パターンを紹介します。AWSのクラウド基礎から体系的に学びたい方は、AWS・Amazon Linux 入門講座ガイドも参考にしてください。

1. 加重ルーティングによる段階的デプロイ(Blue/Green)

VPC Latticeのルーティングルールには加重ルーティング(Weighted Routing)が設定でき、Blue/Greenデプロイメントや段階的なトラフィック切り替えに活用できます。

# リスナールールに加重ルーティングを設定(Blue:90% / Green:10%) aws vpc-lattice create-rule \ --service-identifier "svc-xxxxxxxxxxxxxxxxx" \ --listener-identifier "listener-xxxxxxxxxxxxxxxxx" \ --name "weighted-routing" \ --priority 10 \ --match '{"httpMatch": {"pathMatch": {"match": {"prefix": "/"}}}}' \ --action '{ "forward": { "targetGroups": [ {"targetGroupIdentifier": "tg-blue-xxxxxxxxxxxxxxxxx", "weight": 90}, {"targetGroupIdentifier": "tg-green-xxxxxxxxxxxxxxxxx", "weight": 10} ] } }'

この設定により、新バージョン(Green)へのトラフィックを10%から始め、動作確認後に段階的に比率を変更(30%→50%→100%)することが可能です。カナリアリリースにも同じ仕組みが応用できます。加重ルーティングはリスナールールのupdateコマンドで即時変更できるため、ダウンタイムなしに切り替えを進められます。

2. パスベースルーティングによるマイクロサービス分割

VPC Latticeではパスベースのルーティングルールを設定し、1つのサービスネットワークで複数のマイクロサービスにトラフィックを振り分けることが可能です。

# /api/users → ユーザーサービス(マルチAZ TG) aws vpc-lattice create-rule \ --service-identifier "svc-xxxxxxxxxxxxxxxxx" \ --listener-identifier "listener-xxxxxxxxxxxxxxxxx" \ --name "users-service" \ --priority 20 \ --match '{"httpMatch": {"pathMatch": {"match": {"prefix": "/api/users"}}}}' \ --action '{"forward": {"targetGroups": [{"targetGroupIdentifier": "tg-users-xxxxxxxxxxxxxxxxx", "weight": 100}]}}' # /api/orders → 注文サービス(マルチAZ TG) aws vpc-lattice create-rule \ --service-identifier "svc-xxxxxxxxxxxxxxxxx" \ --listener-identifier "listener-xxxxxxxxxxxxxxxxx" \ --name "orders-service" \ --priority 30 \ --match '{"httpMatch": {"pathMatch": {"match": {"prefix": "/api/orders"}}}}' \ --action '{"forward": {"targetGroups": [{"targetGroupIdentifier": "tg-orders-xxxxxxxxxxxxxxxxx", "weight": 100}]}}'

各ターゲットグループに独立したマルチAZ構成とヘルスチェックを設定することで、特定のマイクロサービスに障害が発生しても他のサービスへの影響を最小化できます。

よくあるエラーと対処法

1. ターゲットがUNHEALTHYになり続ける

ターゲットのヘルスチェックが失敗し続ける場合、原因のほとんどはアプリケーション側のヘルスチェックエンドポイントの不備またはセキュリティグループの設定ミスです。

・確認ポイント1 - ヘルスチェックエンドポイント:指定したパスがHTTP 200を返しているか確認する
・確認ポイント2 - セキュリティグループ:VPC LatticeのCIDR(169.254.171.0/24)からのインバウンドを許可しているか確認する
・確認ポイント3 - プレフィックスリスト:マネージドプレフィックスリスト(com.amazonaws.ap-northeast-1.vpc-lattice)をSGのインバウンドルールに追加することも有効

# VPC Latticeヘルスチェック用のセキュリティグループ設定例 aws ec2 authorize-security-group-ingress \ --group-id sg-xxxxxxxxxxxxxxxxx \ --ip-permissions '[ { "IpProtocol": "tcp", "FromPort": 8080, "ToPort": 8080, "IpRanges": [{"CidrIp": "169.254.171.0/24", "Description": "VPC Lattice health check"}] } ]'

2. サービスネットワーク関連付け後に通信できない

VPCとサービスネットワークを関連付けた後、エンドポイントへの通信が失敗するケースでは以下を確認します。

・関連付けのステータス:aws vpc-lattice list-service-network-vpc-associationsでステータスがACTIVEになっているか確認
・サービス側の認証ポリシー:サービスに認証ポリシーが設定されている場合、送信元のIAMロール/プリンシパルがアクセス許可されているか確認
・DNS名前解決:VPC内のRoute 53リゾルバーがVPC Latticeのドメイン(*.vpc-lattice-svcs.ap-northeast-1.on.aws)を解決できるか確認

# 関連付けステータスの確認 aws vpc-lattice list-service-network-vpc-associations \ --service-network-identifier "sn-xxxxxxxxxxxxxxxxx" # 出力例(環境により異なります) { "items": [ { "status": "ACTIVE", "vpcId": "vpc-xxxxxxxx" } ] } # VPCからDNS解決テスト(Amazon Linux 2023上) nslookup myservice.xxxxxxxxxxxxxxxxx.vpc-lattice-svcs.ap-northeast-1.on.aws

3. CloudWatchメトリクスでエラーレートが急上昇

CloudWatchのRequestCountに対して5xxResponseCountが増加している場合、ターゲット側のアプリケーションエラーが原因であることが多いです。VPC Latticeのアクセスログを有効化してCloudWatch Logsに出力し、エラーの詳細を確認します。

# サービスのアクセスログ有効化(CloudWatch Logs出力) aws vpc-lattice create-access-log-subscription \ --resource-identifier "svc-xxxxxxxxxxxxxxxxx" \ --destination-arn "arn:aws:logs:ap-northeast-1:123456789012:log-group:/vpc-lattice/myservice" # アクセスログのフィールド例(環境により異なります) # requestTime, sourceIp, sourceVpcId, destinationIp, targetGroupArn, # httpMethod, url, statusCode, responseTime, grpcStatusCode

アクセスログには、リクエストのソース・ターゲット・HTTPステータスコード・レスポンスタイムが記録されるため、どのターゲットでエラーが多発しているか特定できます。

本記事のまとめ

AWS VPC Latticeを使ったマルチAZ冗長設計の要点をまとめます。

設計項目 推奨設定・ポイント
マルチAZターゲット登録 最低2AZ × 各AZ最低2ターゲットを基本構成とする
ヘルスチェック間隔 intervalSeconds: 30秒(短縮は負荷と相談)
Unhealthy判定閾値 unhealthyThresholdCount: 3(デフォルト推奨)
セキュリティグループ 169.254.171.0/24 からのインバウンドを許可
Blue/Greenデプロイ 加重ルーティングで10%→100%へ段階的移行
障害調査 アクセスログをCloudWatch Logsに出力してターゲット別のエラー状況を確認

VPC Latticeは単なるサービスメッシュの代替ではなく、AWSネイティブの認証・可観測性・ルーティングを統合したサービスです。マルチAZ構成とヘルスチェックを正しく設計することで、マイクロサービス間通信の冗長性をAWSマネージドな仕組みで実現できます。

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AWSを含むクラウド・Linux環境の構築スキルをゼロから体系的に学べる講座を用意しています。

>> AWS・Amazon Linux 入門講座ガイドを見る

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。