はじめに
弊社は、SPA化するためにフロントエンドとAPIを分離することにしました。それによってコンテナ間の通信状況とパフォーマンスをより簡単に把握したいニーズが生まれ、監視の高度化・インフラの安定化を目的として、AWS App Meshの導入を検討しました。
AWS App Meshとは、AWS上に存在するコンテナ間の通信を監視し、かつ制御できるサービスメッシュです。
aws.amazon.com
導入にあたって、はまったポイントとその解消方法を記載します。
構成
フロントエンドとAPIを分離した状態での検証をするために、以下の構成でApp Meshの設定を行いました。
- 1層目 : Frontend Micro Service
- 2層目 : Bff Micro Service (バックエンドAPI)
- 3層目 : 各種 Micro Service 群
はまったポイントその１. DBにつながらない
事象
APサーバにHTTPリクエストは到達したのですが、内部でエラーが発生してしまいました。
対象となるECSのコンテナにApp Meshの設定をしたことで、Envoyプロキシを全ての通信が通過するようになりました。
このEnvoyプロキシがTCP通信を全て遮断するため、APサーバからDBにつながらなくなってしまったようです。
解決方法
以下の手順で、Envoyに対してバイパスするポートを指定することで回避しました。
1. Amazon ECSのタスク定義から、「新しいリビジョンの作成」を選択。
2. プロキシ設定から無視された出力ポートに、通信を許可したいポート番号を入力。
3. 画面の一番下にある「作成」を選択。
タスク定義の無視された出力ポートに、2で入力したポート番号が表示されていればOKです。
はまったポイントその２. タイムアウトエラー
事象
ダウンロードやアップロードのような、比較的時間がかかる処理でタイムアウト(upstream timeout)が発生してしまいました。
解決方法
App Meshにデフォルトで設定されているタイムアウト時間は15秒だったため、以下の手順でタイムアウト時間を延長することで回避しました。
仮想ルータ側
- AWS App Meshの仮想ルータから、「編集」を選択。
- Request timeoutとIdle durationを任意の時間に設定。
- 画面の一番下にある「保存」を選択。
仮想ノード側
- AWS App Meshの仮想ノードから、「編集」を選択。
- Request timeoutとIdle durationを任意の時間に設定。
- 画面の一番下にある「保存」を選択。
仮想ノードと仮想ルータそれぞれの設定にあるRequest timeoutとIdle durationの欄に、2で入力した値が表示されていればOKです。
最後に
どのエンドポイントに何秒かかったか、どのトラフィックが一番時間がかかっているかなどといった情報が表として出力されるので、非常にわかりやすくなりました！
クライアントが閲覧しているブラウザやデバイスの統計が出るので、ハイレベルな戦略を立てる場合の一つの材料にすることができます。
また、エンドポイントが呼ばれた回数が把握でき、どの機能がよく使われているのかがわかるようになるので、フィードバック開発の意思決定に役立てることもできます。
Holmesはエンジニア・デザイナーを募集しています
興味がある方はぜひこちらからご連絡ください！
lab.holmescloud.com
lab.holmescloud.com
