翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS App Mesh と Amazon ECS の開始方法
**重要**
サポート終了通知: 2026 年 9 月 30 日、 AWS はサポートを終了します AWS App Mesh。2026 年 9 月 30 日以降、 AWS App Mesh コンソールまたは AWS App Mesh リソースにアクセスできなくなります。詳細については、このブログ記事[「 から Amazon ECS Service Connect AWS App Mesh への移行](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)」を参照してください。
このトピックは、Amazon ECS で実行されている実際のサービス AWS App Mesh で を使用するのに役立ちます。このチュートリアルでは、複数の App Mesh リソースタイプのベーシックな機能について説明します。
## シナリオ
App Mesh の使用方法を説明するために、次の特性を持つアプリケーションがあると仮定します。
+ `serviceA` および `serviceB` という名前の 2 つのサービスで構成されています。
+ どちらのサービスも、`apps.local` という名前の名前空間にメンバー登録されます。
+ `ServiceA` は、HTTP/2、ポート 80 を介して `serviceB` と通信します。
+ すでに `serviceB` のバージョン 2 をデプロイし、`serviceBv2` 名前空間に `apps.local` という名前でメンバー登録しました。
次の要件があります。
+ からのトラフィックの 75% を `serviceA` に送信`serviceB`し、トラフィックの 25% を`serviceBv2`最初に に送信します。に 25% のみを送信することで`serviceBv2`、 からトラフィックの 100% を送信する前に、バグがないことを検証できます`serviceA`。
+ トラフィックの重み付けを簡単に調整して、信頼性が証明されたら、トラフィックの 100% が `serviceBv2` へ転送されるようにします。すべてのトラフィックが `serviceBv2` に送信されたら、`serviceB` を切断します。
+ 上記の要件を満たすために、実際のサービスの既存のアプリケーションコードまたはサービスディスカバリ登録を変更する必要はありません。
要件を満たすために、仮想サービス、仮想ノード、仮想ルーター、およびルートで、App Mesh サービスメッシュを作成することにします。メッシュを実装した後、サービスを更新して、Envoy プロキシを使用します。更新されると、サービスは相互に直接ではなく、Envoy プロキシを介して相互に通信します。
## 前提条件
**重要**
サポート終了通知: 2026 年 9 月 30 日、 AWS はサポートを終了します AWS App Mesh。2026 年 9 月 30 日以降、 AWS App Mesh コンソールまたは AWS App Mesh リソースにアクセスできなくなります。詳細については、このブログ記事[「 から Amazon ECS Service Connect AWS App Mesh への移行](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)」を参照してください。
+ App Mesh の概念を既に理解している。詳細については、「[とは AWS App Mesh](what-is-app-mesh.md)」を参照してください。
+ Amazon ECS の概念に関する既存の理解。詳細については、Amazon Elastic Container Service デベロッパーガイドの「[Amazon ECS とは](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)」を参照してください。
+ App Mesh は、DNS に登録されている Linux サービス AWS Cloud Map、またはその両方をサポートしています。この入門ガイドを使用するには、DNS に登録されている3つの既存のサービスをお勧めします。このトピックの手順は、既存のサービスが、`serviceA`、`serviceB`、`serviceBv2` という名前で、すべてのサービスが `apps.local` という名前の名前空間を介して検出可能であることを前提としています。
サービスが存在しない場合でもサービスメッシュとそのリソースを作成できますが、実際のサービスをデプロイするまでメッシュを使用することはできません。Amazon ECS でのサービスディスカバリの詳細については、「[サービスディスカバリ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html)」を参照してください。サービスディスカバリを使用して Amazon ECS サービスを作成するには、「[チュートリアル: サービスディスカバリを使用したサービスの作成](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-discovery.html)」を参照してください。サービスをまだ実行していない場合は、「[サービスディスカバリを使用した Amazon ECS サービスを作成する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-discovery.html)」を参照してください。
## ステップ 1: メッシュと仮想サービスを作成する
サービスメッシュは、サービス間のネットワークトラフィックの論理的な境界であり、サービスはその中に存在します。詳細については、「[サービスメッシュ](meshes.md)」を参照してください。仮想サービスは、実際のサービスを抽象化したものです。詳細については、「[仮想サービス](virtual_services.md)」を参照してください。
次の リソースを作成します。
+ シナリオ内のすべてのサービスが `apps` 名前空間にメンバー登録されているため、`apps.local` という名前のメッシュ。
+ `serviceb.apps.local` という名前の仮想サービス。仮想サービスは、その名前で検出可能なサービスを表しているため、別の名前をリファレンスするようにコードを変更したくないためです。`servicea.apps.local` という名前の仮想サービスが、次のステップで追加されます。
AWS マネジメントコンソール またはバージョン 1.18.116 AWS CLI 以降、または 2.0.38 以降を使用して、次のステップを完了できます。を使用する場合は AWS CLI、 `aws --version` コマンドを使用してインストールされている AWS CLI バージョンを確認します。バージョン 1.18.116 以降、または 2.0.38 以降をインストールしていない場合は、[AWS CLIをインストールまたは更新](https://docs.aws.amazon.com/cli/latest/reference/appmesh/cli-chap-install.html)する必要があります。使用するツールのタブを選択します。
------
#### [ AWS マネジメントコンソール ]
1. App Mesh コンソールの初回実行ウィザードを [https://console.aws.amazon.com/appmesh/get-started](https://console.aws.amazon.com/appmesh/get-started) で開きます。
1. **[メッシュ名]** に **apps** と入力します。
1. **[仮想サービス名]** に **serviceb.apps.local** と入力します。
1. 続行するには、**[次へ]** を選択します。
------
#### [ AWS CLI ]
1. `[create-mesh](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-mesh.html)` コマンドを使用してメッシュを作成します。
```
aws appmesh create-mesh --mesh-name apps
```
1. `[create-virtual-service](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-service.html)` コマンドを使用して仮想サービスを作成します。
```
aws appmesh create-virtual-service --mesh-name apps --virtual-service-name serviceb.apps.local --spec {}
```
------
## ステップ 2: 仮想ノードを作成する
仮想ノードは、実際のサービスの論理ポインタとして機能します。詳細については、「[仮想ノード](virtual_nodes.md)」を参照してください。
仮想ノードの 1 つが `serviceB` という名前の実際のサービスを表すため、`serviceB` という名前の仮想ノードを作成します。仮想ノードが表す実際のサービスは、`serviceb.apps.local` というホスト名を持つ `DNS` を介して検出可能です。または、 を使用して実際のサービスを検出することもできます AWS Cloud Map。仮想ノードは、ポート 80 で HTTP/2 プロトコルを使用してトラフィックをリッスンします。ヘルスチェックと同様に、その他のプロトコルもサポートされています。次のステップで、`serviceA` および `serviceBv2` の仮想ノードを作成します。
------
#### [ AWS マネジメントコンソール ]
1. **[仮想ノード名]** に **serviceB** と入力します。
1. **[サービスディスカバリ]** で、**[DNS]** を選択し、**[DNS ホスト名]** に **serviceb.apps.local** と入力します。
1. **[リスナーの設定]** で、**[プロトコル]** に **[http2]** を選択し、**[ポート]**に **80** と入力します。
1. 続行するには、**[次へ]** を選択します。
------
#### [ AWS CLI ]
1. 次の内容で、`create-virtual-node-serviceb.json` という名前のファイルを作成します。
```
{
"meshName": "apps",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http2"
}
}
],
"serviceDiscovery": {
"dns": {
"hostname": "serviceB.apps.local"
}
}
},
"virtualNodeName": "serviceB"
}
```
1. JSON ファイルを入力として使用して、[create-virtual-node](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-node.html) コマンドで仮想ノードを作成します。
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-serviceb.json
```
------
## ステップ 3: 仮想ルーターとルートを作成する
仮想ルーターは、メッシュ内の 1 つ以上の仮想サービスのトラフィックを送信します。詳細については、「[仮想ルーター](virtual_routers.md)」および「[ルート](routes.md)」を参照してください。
次の リソースを作成します。
+ `serviceB` という名前の仮想ルーター。`serviceB.apps.local` 仮想サービスは、他のサービスとのアウトバウンド通信を開始しないためです。前に作成した仮想サービスは、実際の `serviceb.apps.local` サービスの抽象化であることに注意してください。仮想サービスは、仮想ルーターにトラフィックを送信します。仮想ルーターは、ポート 80 で HTTP/2 プロトコルを使用してトラフィックをリッスンします。その他のプロトコルもサポートされています。
+ `serviceB` という名前のルート。このルートはトラフィックの 100% を `serviceB` 仮想ノードにルーティングします。重み付けは、`serviceBv2` 仮想ノードを追加した後のステップで行います。このガイドでは説明しませんが、ルートにフィルタ条件を追加したり、通信の問題が発生したときに Envoy プロキシが仮想ノードへのトラフィックの送信を複数回試行する再試行ポリシーを追加したりできます。
------
#### [ AWS マネジメントコンソール ]
1. **[仮想ルーター名]** に **serviceB** と入力します。
1. **[リスナーの設定]** で、**[プロトコル]** に **[http2]** を選択して、**[ポート]** に **80** を指定します。
1. **[ルート名]** に **serviceB** と入力します。
1. **[ルートタイプ]** で、**[http2]** を選択します。
1. **[ターゲット設定]** の **[仮想ノード名]**で、[`serviceB`] を選択し、[**重み**]に **100** と入力します。
1. **[一致設定]** で、**[方法]** を選択します。
1. 続行するには、**[次へ]** を選択します。
------
#### [ AWS CLI ]
1. 仮想ルーターを作成します。
1. 次の内容で、`create-virtual-router.json` という名前のファイルを作成します。
```
{
"meshName": "apps",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http2"
}
}
]
},
"virtualRouterName": "serviceB"
}
```
1. JSON ファイルを入力として使用し、[create-virtual-router](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-virtual-router.html) コマンドで仮想ルーターを作成します。
```
aws appmesh create-virtual-router --cli-input-json file://create-virtual-router.json
```
1. ルートを作成します。
1. 次の内容で、`create-route.json` という名前のファイルを作成します。
```
{
"meshName" : "apps",
"routeName" : "serviceB",
"spec" : {
"httpRoute" : {
"action" : {
"weightedTargets" : [
{
"virtualNode" : "serviceB",
"weight" : 100
}
]
},
"match" : {
"prefix" : "/"
}
}
},
"virtualRouterName" : "serviceB"
}
```
1. JSON ファイルを入力として使用し、[create-route](https://docs.aws.amazon.com/cli/latest/reference/appmesh/create-route.html) コマンドでルートを作成します。
```
aws appmesh create-route --cli-input-json file://create-route.json
```
------
## ステップ 4: 確認して作成する
前のステップと照らし合わせて設定を確認します。
------
#### [ AWS マネジメントコンソール ]
いずれかのセクションに変更を加える必要がある場合は、**[編集]** を選択します。設定が完了したら、**[メッシュの作成]** を選択します。
**[ステータス]** 画面には、作成されたすべてのメッシュリソースが表示されます。作成したリソースをコンソールに表示するには、**[メッシュの表示]** を選択します。
------
#### [ AWS CLI ]
[describe-mesh](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-mesh.html) コマンドで作成したメッシュの設定を確認します。
```
aws appmesh describe-mesh --mesh-name apps
```
[describe-virtual-service](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-service.html) コマンドで作成した仮想サービスの設定を確認します。
```
aws appmesh describe-virtual-service --mesh-name apps --virtual-service-name serviceb.apps.local
```
[describe-virtual-node](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-node.html) コマンドで作成した仮想ノードの設定を確認します。
```
aws appmesh describe-virtual-node --mesh-name apps --virtual-node-name serviceB
```
[describe-virtual-router](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-virtual-router.html) コマンドで作成した仮想ルーターの設定を確認します。
```
aws appmesh describe-virtual-router --mesh-name apps --virtual-router-name serviceB
```
[describe-route](https://docs.aws.amazon.com/cli/latest/reference/appmesh/describe-route.html) コマンドで作成したルートの設定を確認します。
```
aws appmesh describe-route --mesh-name apps \
--virtual-router-name serviceB --route-name serviceB
```
------
## ステップ 5: 追加のリソースを作成する
このシナリオを完了するには、次のことを行う必要があります。
+ `serviceBv2` という名前の仮想ノードと、`serviceA` という名前の別の仮想ノードを作成します。両方の仮想ノードは、HTTP/2 ポート 80 経由でリクエストをリッスンします。`serviceA` 仮想ノードには、`serviceb.apps.local` のバックエンドを設定します。`serviceA` 仮想ノードからのすべてのアウトバウンドトラフィックは、`serviceb.apps.local` という名前の仮想サービスに送信されます。このガイドでは説明しませんが、仮想ノードのアクセスログを書き込むファイルパスを指定することもできます。
+ `servicea.apps.local` という名前の追加の仮想サービスを 1 つ作成します。これにより、すべてのトラフィックが `serviceA` 仮想ノードに直接送信されます。
+ 前のステップで作成した `serviceB` ルートを更新して、トラフィックの 75% を `serviceB` 仮想ノードに送信し、25% を `serviceBv2` 仮想ノードに送信します。時間の経過とともに、`serviceBv2` が 100% のトラフィックを受信するまで、継続して重みを変更することができます。すべてのトラフィックが `serviceBv2` に送信されたら、`serviceB` 仮想ノードと実際のサービスをシャットダウンして中止することができます。重みを変更しても、`serviceb.apps.local` 仮想サービス名および実際のサービス名は変更されないため、コードを変更する必要はありません。`serviceb.apps.local` 仮想サービスは仮想ルーターにトラフィックを送信し、仮想ルーターはトラフィックを仮想ノードにルーティングすることに注意してください。仮想ノードのサービスディスカバリ名は、いつでも変更できます。
------
#### [ AWS マネジメントコンソール ]
1. 左のナビゲーションペインで **[メッシュ]** を選択します。
1. 前のステップで作成した `apps` メッシュを選択します。
1. 左側のナビゲーションペインで、**[仮想ノード]** を選択します。
1. **[仮想ノードの作成]** を選択します。
1. **[仮想ノード名]** に **serviceBv2** と入力し、**[サービスディスカバリ]** で **[DNS]** を選択して、**[DNS ホスト名]** に **servicebv2.apps.local** と入力します。
1. **[リスナーの設定]** で、**[プロトコル]** に **[http2]** を選択し、**[ポート]** に **80** を入力します。
1. **[仮想ノードの作成]** を選択します。
1. **[仮想ノードの作成]** をもう一度選択します。**[仮想ノード名]** に **serviceA** と入力してください。**[サービスディスカバリ]** で **[DNS]** を選択し、**[DNS ホスト名]** に **servicea.apps.local** と入力します。
1. **[新しいバックエンド]** の下の **[仮想サービス名の入力]** に **serviceb.apps.local** と入力します。
1. **[リスナーの設定]** で、**[プロトコル]** に **[http2]** を選択し、**[ポート]** に **80** を入力して、**[仮想ノードの作成]** を選択します。
1. 左側のナビゲーションペインで **[仮想ルーター]** を選択し、リストから [`serviceB`] 仮想ルーターを選択します。
1. **[ルート]** で、前のステップで作成した `ServiceB` という名前のルートを選択し、**[編集]** を選択します。
1. **[ターゲット]** の**仮想ノード名**で、`serviceB` の **[重み]** の値を **75** に変更します。
1. **[ターゲットの追加]** を選択し、ドロップダウンリストから `serviceBv2`を選択して、**[重み]** の値を **25** に設定します。
1. **[保存]** を選択します。
1. 左側のナビゲーションペインで、**[仮想サービス]** を選択し、**[仮想サービスの作成]** を選択します。
1. **[仮想サービス名]** に **servicea.apps.local** と入力し、**[プロバイダー]** に **[仮想ノード]** を選択し、**[仮想ノード]** に `serviceA` を選択し、**[仮想サービスの作成]**を選択します。
------
#### [ AWS CLI ]
1. `serviceBv2` 仮想ノードを作成します。
1. 次の内容で、`create-virtual-node-servicebv2.json` という名前のファイルを作成します。
```
{
"meshName": "apps",
"spec": {
"listeners": [
{
"portMapping": {
"port": 80,
"protocol": "http2"
}
}
],
"serviceDiscovery": {
"dns": {
"hostname": "serviceBv2.apps.local"
}
}
},
"virtualNodeName": "serviceBv2"
}
```
1. 仮想ノードを作成します。
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicebv2.json
```
1. `serviceA` 仮想ノードを作成します。
1. 次の内容で、`create-virtual-node-servicea.json` という名前のファイルを作成します。
```
{
"meshName" : "apps",
"spec" : {
"backends" : [
{
"virtualService" : {
"virtualServiceName" : "serviceb.apps.local"
}
}
],
"listeners" : [
{
"portMapping" : {
"port" : 80,
"protocol" : "http2"
}
}
],
"serviceDiscovery" : {
"dns" : {
"hostname" : "servicea.apps.local"
}
}
},
"virtualNodeName" : "serviceA"
}
```
1. 仮想ノードを作成します。
```
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicea.json
```
1. 前のステップで作成した `serviceb.apps.local` 仮想サービスを更新して、そのトラフィックを `serviceB` 仮想ルーターに送信します。仮想サービスが最初に作成された時点では、`serviceB` 仮想ルーターがまだ作成されていないため、トラフィックはどこにも送信されませんでした。
1. 次の内容で、`update-virtual-service.json` という名前のファイルを作成します。
```
{
"meshName" : "apps",
"spec" : {
"provider" : {
"virtualRouter" : {
"virtualRouterName" : "serviceB"
}
}
},
"virtualServiceName" : "serviceb.apps.local"
}
```
1. [update-virtual-service](https://docs.aws.amazon.com/cli/latest/reference/appmesh/update-virtual-service.html) コマンドを使用して、仮想サービスを更新します。
```
aws appmesh update-virtual-service --cli-input-json file://update-virtual-service.json
```
1. 前のステップで作成した `serviceB` ルートを更新します。
1. 次の内容で、`update-route.json` という名前のファイルを作成します。
```
{
"meshName" : "apps",
"routeName" : "serviceB",
"spec" : {
"http2Route" : {
"action" : {
"weightedTargets" : [
{
"virtualNode" : "serviceB",
"weight" : 75
},
{
"virtualNode" : "serviceBv2",
"weight" : 25
}
]
},
"match" : {
"prefix" : "/"
}
}
},
"virtualRouterName" : "serviceB"
}
```
1. [update-route](https://docs.aws.amazon.com/cli/latest/reference/appmesh/update-route.html) コマンドを使用してルートを更新します。
```
aws appmesh update-route --cli-input-json file://update-route.json
```
1. `serviceA` 仮想サービスを作成します。
1. 次の内容で、`create-virtual-servicea.json` という名前のファイルを作成します。
```
{
"meshName" : "apps",
"spec" : {
"provider" : {
"virtualNode" : {
"virtualNodeName" : "serviceA"
}
}
},
"virtualServiceName" : "servicea.apps.local"
}
```
1. 仮想サービスを作成します。
```
aws appmesh create-virtual-service --cli-input-json file://create-virtual-servicea.json
```
------
**メッシュの概要**
サービスメッシュを作成する前に、`servicea.apps.local`、`serviceb.apps.local`、および `servicebv2.apps.local` という 3 つの実際のサービスがありました。実際のサービスに加えて、実際のサービスを表す次のリソースを含むサービスメッシュが作成されました。
+ 2 つの仮想サービス。プロキシは、仮想ルーターを経由して、`servicea.apps.local` 仮想サービスからのすべてのトラフィックを `serviceb.apps.local` 仮想サービスに送信します。
+ `serviceA`、`serviceB`、および `serviceBv2` という名前の 3 つの仮想ノード。Envoy プロキシは、仮想ノードに対して設定されたサービスディスカバリ情報を使用して、実際のサービスの IP アドレスを検索します。
+ Envoy プロキシがインバウンドトラフィックの 75% を `serviceB` 仮想ノードに、25% を `serviceBv2` 仮想ノードにルーティングするように指定する 1 つのルートを持つ仮想ルーター。
## ステップ 6: サービスを更新する
メッシュを作成したら、次のタスクを完了する必要があります。
+ 各 Amazon ECS タスクでデプロイする Envoy プロキシに、1 つ以上の仮想ノードの設定を読み取りすることを許可します。プロキシの認可方法の詳細については、[「プロキシ認可](https://docs.aws.amazon.com/app-mesh/latest/userguide/proxy-authorization.html)」を参照してください。
+ 既存の各 Amazon ECS タスク定義を更新して、Envoy プロキシを使用します。
**認証情報**
Envoy コンテナには、App Mesh サービスに送信されるリクエストに署名するための AWS Identity and Access Management 認証情報が必要です。Amazon EC2 起動タイプでデプロイされた Amazon ECS タスクの場合、認証情報は[インスタンスのロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/instance_IAM_role.html)または、[タスクの IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)から取得できます。Linux コンテナの Fargate を使用してデプロイされた Amazon ECS タスクは、インスタンス IAM プロファイル認証情報を提供する Amazon EC2 メタデータサーバーにアクセスできません。認証情報を提供するには、Linux コンテナの Fargate タイプを使用してデプロイされたタスクに IAM タスクのロールをアタッチする必要があります。
タスクが Amazon EC2 起動タイプでデプロイされ、Amazon EC2 メタデータサーバーへのアクセスがブロックされている場合、[タスク用の IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)の*重要な*注釈で説明されているように、タスク IAM ロールもタスクに添付する必要があります。インスタンスまたはタスクに割り当てるロールには、[プロキシ認可](https://docs.aws.amazon.com/app-mesh/latest/userguide/proxy-authorization.html)で説明するように IAM ポリシーが添付されている必要があります。
**を使用してタスク定義を更新するには AWS CLI**
Amazon ECS AWS CLI コマンド を使用します[https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)。以下のタスク定義の例は、サービスの App Mesh を設定する方法を示しています。
**注記**
コンソールを使用した Amazon ECS の App Mesh の設定は利用できません。
### タスク定義 json
**プロキシ設定**
App Mesh を使用するように Amazon ECS サービスを設定するには、サービスのタスク定義に次のプロキシ設定セクションがある必要があります。プロキシ設定 `type` を `APPMESH` に、`containerName` を `envoy` に設定します。これに応じて、次のプロパティ値を設定します。
`IgnoredUID`
Envoy プロキシは、このユーザー ID を使用するプロセスからのトラフィックをルーティングしません。このプロパティ値には任意のユーザー ID を選択できますが、この ID はタスク定義の Envoy コンテナの `user` ID と同じである必要があります。この一致により、Envoy はプロキシを使用せずに、それ自体のトラフィックを無視することができます。例では、履歴上の目的で `1337` を使用します。
`ProxyIngressPort`
これは、Envoy プロキシのコンテナのインバウンドポートです。この値は `15000` に設定します。
`ProxyEgressPort`
これは、Envoy プロキシのコンテナのアウトバウンドポートです。この値は `15001` に設定します。
`AppPorts`
アプリケーションコンテナがリッスンするインバウンドポートを指定します。この例では、アプリケーションコンテナはポート `9080` でリッスンします。指定するポートは、仮想ノードリスナーで設定されたポートと一致する必要があります。
`EgressIgnoredIPs`
Envoy は、これらの IP アドレスにトラフィックをプロキシしません。この値を `169.254.170.2,169.254.169.254` に設定することで、Amazon EC2 メタデータサーバーと Amazon ECS タスクのメタデータエンドポイントを無視します。メタデータのエンドポイントは、タスクの認証情報用に IAM ロールを提供します。さらにアドレスを追加できます。
`EgressIgnoredPorts`
コンマで区切られたポートのリストを追加できます。Envoy は、これらのポートにトラフィックをプロキシしません。ポートがない場合でも、ポート 22 は無視されます。
無視できるアウトバウンドポートの最大数は 15 です。
```
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "envoy",
"properties": [{
"name": "IgnoredUID",
"value": "1337"
},
{
"name": "ProxyIngressPort",
"value": "15000"
},
{
"name": "ProxyEgressPort",
"value": "15001"
},
{
"name": "AppPorts",
"value": "9080"
},
{
"name": "EgressIgnoredIPs",
"value": "169.254.170.2,169.254.169.254"
},
{
"name": "EgressIgnoredPorts",
"value": "22"
}
]
}
```
**アプリケーションコンテナ Envoy の依存関係**
タスク定義のアプリケーションコンテナは開始する前に Envoy プロキシがブートストラップして起動するのを待機する必要があります。これを確実に行うには、各アプリケーションコンテナの定義に `dependsOn` セクションを設定して、Envoy コンテナが `HEALTHY` としてレポートするのを待ちます。次のコードは、この依存関係があるアプリケーションコンテナの定義の例を示しています。次の例のすべてのプロパティが必須です。一部のプロパティ値も必須ですが、*置き換え可能*なものもあります。
```
{
"name": "appName",
"image": "appImage",
"portMappings": [{
"containerPort": 9080,
"hostPort": 9080,
"protocol": "tcp"
}],
"essential": true,
"dependsOn": [{
"containerName": "envoy",
"condition": "HEALTHY"
}]
}
```
**Envoy コンテナの定義**
Amazon ECS タスク定義には、App Mesh Envoy コンテナイメージを含める必要があります。
[サポートされている](https://docs.aws.amazon.com/general/latest/gr/appmesh.html)すべてのリージョンは、*リージョンコードを* `me-south-1`、`ap-east-1`、、、`ap-southeast-3``eu-south-1``il-central-1`、および 以外の任意のリージョンに置き換えることができます`af-south-1`。
標準
```
840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
FIPS 準拠
```
840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod-fips
```
`me-south-1`
Standard
```
772975370895.dkr.ecr.me-south-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`ap-east-1`
Standard
```
856666278305.dkr.ecr.ap-east-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`ap-southeast-3`
Standard
```
909464085924.dkr.ecr.ap-southeast-3.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`eu-south-1`
Standard
```
422531588944.dkr.ecr.eu-south-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`il-central-1`
Standard
```
564877687649.dkr.ecr.il-central-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`af-south-1`
Standard
```
924023996002.dkr.ecr.af-south-1.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod
```
`Public repository`
標準
```
public.ecr.aws/appmesh/aws-appmesh-envoy:v1.34.13.0-prod
```
FIPS 準拠
```
public.ecr.aws/appmesh/aws-appmesh-envoy:v1.34.13.0-prod-fips
```
**重要**
App Mesh での使用は、バージョン v1.9.0.0-prod 以降のみサポートされています。
Envoy プロジェクトチームが App Mesh をサポートする変更をマージをするまでは、App Mesh Envoy コンテナイメージを使用する必要があります。詳細については、「[GitHub ロードマップの問題](https://github.com/aws/aws-app-mesh-roadmap/issues/10)」を参照してください。
次の例のすべてのプロパティが必須です。一部のプロパティ値も必須ですが、*置き換え可能*なものもあります。
**注記**
Envoy のコンテナの定義は `essential` とマークされる必要があります。
Envoy コンテナに `512` CPU ユニットと少なくとも`64` MiB のメモリを割り当てるようお勧めします。Fargate では、設定できる最低メモリは `1024` MiB です。
Amazon ECS サービスの仮想ノード名は、`APPMESH_RESOURCE_ARN` プロパティの値に設定する必要があります。このプロパティには、Envoy イメージのバージョン `1.15.0` 以降が必要です。詳細については、「[Envoy イメージ](envoy.md)」を参照してください。
`user` 設定の値は、タスク定義のプロキシ設定の `IgnoredUID` 値と一致する必要があります。この例では、`1337` を使用します。
ここに示されているヘルスチェックは、Envoy コンテナが正常にブートストラップするのを待機して、Envoy コンテナが正常な状態であり、アプリケーションコンテナが開始する準備ができていることを Amazon ECS に報告します。
デフォルトでは、App Mesh は、Envoy によってメトリクスとトレースでそれ自体が参照されるとき、`APPMESH_RESOURCE_ARN` で指定したリソースの名前を使用します。`APPMESH_RESOURCE_CLUSTER` 環境変数に独自の名前を設定することで、この動作を上書きできます。このプロパティには、Envoy イメージのバージョン `1.15.0` 以降が必要です。詳細については、「[Envoy イメージ](envoy.md)」を参照してください。
次のコードは Envoy コンテナの定義の例を示しています。
```
{
"name": "envoy",
"image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod",
"essential": true,
"environment": [{
"name": "APPMESH_RESOURCE_ARN",
"value": "arn:aws:appmesh:us-west-2:111122223333:mesh/apps/virtualNode/serviceB"
}],
"healthCheck": {
"command": [
"CMD-SHELL",
"curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
],
"startPeriod": 10,
"interval": 5,
"timeout": 2,
"retries": 3
},
"user": "1337"
}
```
**タスク定義の例**
次の Amazon ECS タスク定義例は、上記の例を `taskB` のタスク定義にマージする方法を示しています。ここでは、 AWS X-Rayの使用の有無にかかわらず、両方の Amazon ECS 起動タイプのタスクを作成するための例を示します。必要に応じて、*置換可能*な値を変更し、シナリオから `taskBv2` および `taskA` という名前のタスクの定義を作成します。メッシュ名と仮想ノード名を `APPMESH_RESOURCE_ARN` 値に置き換え、アプリケーションがリッスンするポートのリストをプロキシ設定の `AppPorts` 値に置き換えます。デフォルトでは、App Mesh は、Envoy によってメトリクスとトレースでそれ自体が参照されるとき、`APPMESH_RESOURCE_ARN` で指定したリソースの名前を使用します。`APPMESH_RESOURCE_CLUSTER` 環境変数に独自の名前を設定することで、この動作を上書きできます。次の例のすべてのプロパティは必須です。一部のプロパティ値も必須ですが、*置き換え可能*なものもあります。
「認証情報」セクション タスクで説明されているように、Amazon ECS タスクを実行している場合は、既存の[タスク IAM ロール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)を例に追加する必要があります。
**重要**
Fargate は 1024 より大きいポート値を使用する必要があります。
**Example Amazon ECS タスク定義の JSON - Linux コンテナの Fargate**
```
{
"family" : "taskB",
"memory" : "1024",
"cpu" : "0.5 vCPU",
"proxyConfiguration" : {
"containerName" : "envoy",
"properties" : [
{
"name" : "ProxyIngressPort",
"value" : "15000"
},
{
"name" : "AppPorts",
"value" : "9080"
},
{
"name" : "EgressIgnoredIPs",
"value" : "169.254.170.2,169.254.169.254"
},
{
"name": "EgressIgnoredPorts",
"value": "22"
},
{
"name" : "IgnoredUID",
"value" : "1337"
},
{
"name" : "ProxyEgressPort",
"value" : "15001"
}
],
"type" : "APPMESH"
},
"containerDefinitions" : [
{
"name" : "appName",
"image" : "appImage",
"portMappings" : [
{
"containerPort" : 9080,
"protocol" : "tcp"
}
],
"essential" : true,
"dependsOn" : [
{
"containerName" : "envoy",
"condition" : "HEALTHY"
}
]
},
{
"name" : "envoy",
"image" : "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod",
"essential" : true,
"environment" : [
{
"name" : "APPMESH_VIRTUAL_NODE_NAME",
"value" : "mesh/apps/virtualNode/serviceB"
}
],
"healthCheck" : {
"command" : [
"CMD-SHELL",
"curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
],
"interval" : 5,
"retries" : 3,
"startPeriod" : 10,
"timeout" : 2
},
"memory" : 500,
"user" : "1337"
}
],
"requiresCompatibilities" : [ "FARGATE" ],
"taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole",
"executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"networkMode" : "awsvpc"
}
```
**Example Linux コンテナ上の Fargate AWS X-Ray を使用した Amazon ECS タスク定義の JSON**
X-Ray を使用すると、アプリケーションが処理するリクエストに関するデータ収集が可能になります。また、トラフィックフローを視覚化するために使用できるツールが提供されます。Envoy 用の X-Ray ドライバーを使用すると、Envoy はトレース情報を X-Ray に報告することができます。[Envoy の設定](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html)で、X-Rayトレースを有効にすることができます。設定に基づいて、Envoy は、[サイドカー](https://docs.aws.amazon.com/xray/latest/devguide/xray-daemon-ecs.html)コンテナとして実行されている X-Ray デーモンにトレースデータを送信し、デーモンは、トレースを X-Ray サービスに転送します。トレースが X-Ray に発行されたら、X-Ray コンソールを使用してサービス呼び出しグラフを視覚化し、トレースの詳細をリクエストできます。次の JSON は、X-Ray の統合を有効にするためのタスク定義を表しています。
```
{
"family" : "taskB",
"memory" : "1024",
"cpu" : "512",
"proxyConfiguration" : {
"containerName" : "envoy",
"properties" : [
{
"name" : "ProxyIngressPort",
"value" : "15000"
},
{
"name" : "AppPorts",
"value" : "9080"
},
{
"name" : "EgressIgnoredIPs",
"value" : "169.254.170.2,169.254.169.254"
},
{
"name": "EgressIgnoredPorts",
"value": "22"
},
{
"name" : "IgnoredUID",
"value" : "1337"
},
{
"name" : "ProxyEgressPort",
"value" : "15001"
}
],
"type" : "APPMESH"
},
"containerDefinitions" : [
{
"name" : "appName",
"image" : "appImage",
"portMappings" : [
{
"containerPort" : 9080,
"protocol" : "tcp"
}
],
"essential" : true,
"dependsOn" : [
{
"containerName" : "envoy",
"condition" : "HEALTHY"
}
]
},
{
"name" : "envoy",
"image" : "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod",
"essential" : true,
"environment" : [
{
"name" : "APPMESH_VIRTUAL_NODE_NAME",
"value" : "mesh/apps/virtualNode/serviceB"
},
{
"name": "ENABLE_ENVOY_XRAY_TRACING",
"value": "1"
}
],
"healthCheck" : {
"command" : [
"CMD-SHELL",
"curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
],
"interval" : 5,
"retries" : 3,
"startPeriod" : 10,
"timeout" : 2
},
"memory" : 500,
"user" : "1337"
},
{
"name" : "xray-daemon",
"image" : "amazon/aws-xray-daemon",
"user" : "1337",
"essential" : true,
"cpu" : "32",
"memoryReservation" : "256",
"portMappings" : [
{
"containerPort" : 2000,
"protocol" : "udp"
}
]
}
],
"requiresCompatibilities" : [ "FARGATE" ],
"taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole",
"executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"networkMode" : "awsvpc"
}
```
**Example Amazon ECS タスク定義の JSON - EC2 起動タイプ**
```
{
"family": "taskB",
"memory": "256",
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "envoy",
"properties": [
{
"name": "IgnoredUID",
"value": "1337"
},
{
"name": "ProxyIngressPort",
"value": "15000"
},
{
"name": "ProxyEgressPort",
"value": "15001"
},
{
"name": "AppPorts",
"value": "9080"
},
{
"name": "EgressIgnoredIPs",
"value": "169.254.170.2,169.254.169.254"
},
{
"name": "EgressIgnoredPorts",
"value": "22"
}
]
},
"containerDefinitions": [
{
"name": "appName",
"image": "appImage",
"portMappings": [
{
"containerPort": 9080,
"hostPort": 9080,
"protocol": "tcp"
}
],
"essential": true,
"dependsOn": [
{
"containerName": "envoy",
"condition": "HEALTHY"
}
]
},
{
"name": "envoy",
"image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod",
"essential": true,
"environment": [
{
"name": "APPMESH_VIRTUAL_NODE_NAME",
"value": "mesh/apps/virtualNode/serviceB"
}
],
"healthCheck": {
"command": [
"CMD-SHELL",
"curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
],
"startPeriod": 10,
"interval": 5,
"timeout": 2,
"retries": 3
},
"user": "1337"
}
],
"requiresCompatibilities" : [ "EC2" ],
"taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole",
"executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"networkMode": "awsvpc"
}
```
**Example EC2 起動タイプを使用した Amazon ECS AWS X-Ray タスク定義の JSON**
```
{
"family": "taskB",
"memory": "256",
"cpu" : "1024",
"proxyConfiguration": {
"type": "APPMESH",
"containerName": "envoy",
"properties": [
{
"name": "IgnoredUID",
"value": "1337"
},
{
"name": "ProxyIngressPort",
"value": "15000"
},
{
"name": "ProxyEgressPort",
"value": "15001"
},
{
"name": "AppPorts",
"value": "9080"
},
{
"name": "EgressIgnoredIPs",
"value": "169.254.170.2,169.254.169.254"
},
{
"name": "EgressIgnoredPorts",
"value": "22"
}
]
},
"containerDefinitions": [
{
"name": "appName",
"image": "appImage",
"portMappings": [
{
"containerPort": 9080,
"hostPort": 9080,
"protocol": "tcp"
}
],
"essential": true,
"dependsOn": [
{
"containerName": "envoy",
"condition": "HEALTHY"
}
]
},
{
"name": "envoy",
"image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.34.13.0-prod",
"essential": true,
"environment": [
{
"name": "APPMESH_VIRTUAL_NODE_NAME",
"value": "mesh/apps/virtualNode/serviceB"
},
{
"name": "ENABLE_ENVOY_XRAY_TRACING",
"value": "1"
}
],
"healthCheck": {
"command": [
"CMD-SHELL",
"curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
],
"startPeriod": 10,
"interval": 5,
"timeout": 2,
"retries": 3
},
"user": "1337"
},
{
"name": "xray-daemon",
"image": "amazon/aws-xray-daemon",
"user": "1337",
"essential": true,
"cpu": 32,
"memoryReservation": 256,
"portMappings": [
{
"containerPort": 2000,
"protocol": "udp"
}
]
}
],
"requiresCompatibilities" : [ "EC2" ],
"taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole",
"executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"networkMode": "awsvpc"
}
```
## 高度なトピック
### App Mesh を使用した canary デプロイ
canary デプロイ/リリースは、アプリケーションの古いバージョンと新しくデプロイされたバージョンの間でトラフィックを切り替えるのに役立ちます。また、新しくデプロイされたバージョンのヘルスも監視します。新しいバージョンに問題がある場合、canary デプロイはトラフィックを古いバージョンに自動的に切り替えることができます。canary デプロイでは、アプリケーションのバージョン間でトラフィックを詳細に制御して切り替えることができます。
App Mesh を使用して Amazon ECS の canary デプロイを実装する方法の詳細については、「[App Mesh を使用して Amazon ECS の canary デプロイを使用したパイプラインを作成する](https://aws.amazon.com/blogs/containers/create-a-pipeline-with-canary-deployments-for-amazon-ecs-using-aws-app-mesh/)」を参照してください。
**注記**
App Mesh のその他の例とチュートリアルについては、[App Mesh サンプルリポジトリ](https://github.com/aws/aws-app-mesh-examples)を参照してください。