下図が構築していく概要図です。作成していくと何が何やらこんがらがってくるので、図を振り返りながら作成していくと宜しいかと思います。ついては下記ブログに詳しく説明されています。適当な名前で作成します。nodeを作成サービス検出(CloudMap)と仮想ノードが連携することが見て取れます。ヘルスチェックは設定しておきます。別のプライベートホストゾーンを作成します。名前解決さえできれば問題ないので、対応する適当なレコードを入力しています。ALBとメッシュ内との窓口となる仮想ゲートウェイを作成します。サービスから起動させます。ここでは、必要最小限の名前とプロトコル:ポートのみを選択して作成します。仮想ゲートウェイのポートには注意です。(最初、80番ポートを充ててうまくいかない理由がわからず、困惑しました。)ALBのターゲットグループで開放するポートと合わせます。続けて、ゲートウェイルートを作成します。今回は宛先は1サービスですが、リクエストとの一致条件やリクエスト設定の書き換えなど、細かくトラフィックを複数の仮想サービスに分散させるルーティングも可能です。とでそれぞれ設定項目が異なります。適当な名前を入力し、プロトコルタイプ、仮想サービス名を選択します。一致条件は必ず1つ以上は入力しないといけないので、今回はパスの一致タイプだけ入力しました。イメージ運用は非推奨なのですが、検証ということを言い訳にして雑にプッシュします。ファイルで対応します。値を設定する必要があります。仮想ゲートウェイで設定したポート、ALBのターゲットグループで開放するポートにします。タスクロール、タスク実行ロールを更新します。タスクロールには以下ポリシーを付与しておきます。実環境で利用する際は、必要に応じて権限を限定しましょう。ファイルを作成します。mesh/<メッシュ名>/virtualNode/<仮想ノード名>を入力します。タスクロール、タスク実行ロールを更新できたらタスク定義を作成します。サービスを作成サービスを実行する前にロググループを作成する必要があります。/ecs/uwsgi-flask-restful-appロードバランサー直下となる仮想ゲートウェイのサービス検出名は、外部サービスがメッシュ内のリソースにアクセスするために使用する名前になります。仮想ノードに関連付けられるアプリに関しては、既存のサービス検出名を選択すること、セキュリティグループは仮想ノードのリスナー:ポートを開放します。確認すると以下のような図が出ます。どこらへんで時間がかかっていることがあるのか、なども判別しやすいですね。見るとリクエスト元やレスポンス結果、所要時間などの詳細も確認することもできます。最後に仮想ルータを作って、複数の仮想ノードに転送するルートを作成してみます。このような構成図になります。1つ仮想ノードを作成します。仮想ノードのリスナーに合わせて、仮想ルータを作成します。おいて、下記のように再試行ポリシーが推奨事項なので対応します。少なくとも2の値を指定し、再試行イベントタイプをサポートする各ルートタイプの再試行イベントのタイプごとに、次のオプションを指定することをお勧めします。unavailableゲートウェイとは異なり、書き換えはできないようですが、リクエストとの一致条件によって複数の仮想ノードにルーティングできます。とでそれぞれ設定項目が異なります。Meshを参照下さい。条件指定はせず、2つの仮想ノードに振り分けるだけとします。更新して適当な名前でサービスを作成します。],サービスが無事起動していることが確認できたら、最後に仮想サービスのプロバイダを仮想ノードから仮想ルータに変更します。X-Rayの図は以下のようになりました。冒頭に挙げた以下のような機能の利用イメージをつかむことができたかと思います。(各機能を分離してマイクロサービスのアーキテクチャにする必要性がある水準)が前提となり、気軽に導入するわけにもいかず、はっきとした課題解消イメージがなければ、とりあえず判断は先送りになると思います。情報は少ないのだろうと考えます。モノリシックなアーキテクチャからマイクロサービスのアーキテクチャに移行せざるを得なくなる流れは強くなるのではないかと考えています。活かせるように気楽な再入門ができると助かるな、というのが今回ブログでまとめた動機になります。必要に応じて、ちょくちょく追記をしていければ良いなーと考えています。設定項目が多くてコンソールだと厳しめですね...以上です。どなたかのお役に立てば幸いです。