こんにちは。
カスタマーサクセス部の山本です。😺
以前、ECS のサービス検出のブログを書きました。
ECS サービスにタスクを追加した際に、クライアントから見える DNS レコードの内容がどのように変化するのか、確認しました。
画面キャプチャを貼っていますが、10〜20 回の動作検証をした中で、タイミングよく取得できたものを載せているので、ID などは一貫性がないです。ご了承ください。
- AWS ドキュメントの該当箇所
- 先に検証結果を書きます
- タスクを追加する前の状態
- ECS サービスにタスクを8つ追加し、ECS タスクが「保留中」の状態
- 8つの ECS タスクが「実行中」になった状態
- 補足
- 余談
AWS ドキュメントの該当箇所
タスク追加時は、Cloud Map のサービスインスタンスに UNHEALTHY(異常) として登録されるようです。
そして、タスクが正常に起動すると、Cloud Map 側も HEALTHY (正常)になるようです。
タスクとインスタンスはコンテナのヘルスチェックが値を返すまで UNHEALTHY として登録されます。ヘルスチェックが成功した場合、ステータスは HEALTHY に更新されます。コンテナのヘルスチェックに失敗すると、サービス検出インスタンスは登録解除されます。
ドキュメント:サービス検出を使用して Amazon ECS サービスを DNS 名で接続する
先に検証結果を書きます
ECS タスクは以下の順に遷移します。
- プロビジョニング → 保留中 → アクティブ化中 → 実行中
観察すると、追加した ECS タスクが「保留中」になり、ヘルスステータスが「不明」になったとき、Cloud Map にはすでにサービスインスタンスが登録されていました。
しかし、Cloud Map ではそのサービスインスタンスのヘルスが「不明」または「異常」と表示されていました。ドキュメントの記載通りです。
また、この時点で Route 53 には新しいレコードが追加されていましたが、クライアントがDNSに問い合わせても、その新しいレコードは返されませんでした。
ECS タスクが「実行中」になり、ヘルスステータスが「正常」になったとき、Cloud Map のヘルスも「正常」に変わりました。ドキュメントの記載通りです。
このタイミングでクライアントが DNS に問い合わせると、Route 53 から新しいレコードが返されました。
タスクを追加する前の状態
ECS サービスに「実行中」のタスクは1つです。
Cloud Map 上にもサービスインスタンスは1つです。
Route 53 プライベートホストゾーンにレコードが1つです。
ECS サービスにタスクを8つ追加し、ECS タスクが「保留中」の状態
ECS サービスのタスク数を 1台から 8台に増やします。
最初は「プロビジョニング 」状態です。
一部が「実行中」になったものの、「保留中」状態になりました。キャプチャできなかったですが、ヘルスステータスは「不明」です。
ECS タスクが「保留中」状態での Cloud Map
Cloud Map にサービスインスタンスが 7 台新しく登録されるものの、ヘルスは「不明」または「異常」となります。
「不明」→「異常」の順番に遷移します。
元々あった1レコードのみ「正常」です。
不明状態の例:
ECS タスクが「保留中」状態での Route 53
Route 53 にはレコードが 8 つあります。
しかし、ECS サービスと同じ VPC にある EC2 から dig しても 元々あった1レコードのみ返却されます。
Cloud Map でヘルスが正常にならない限りは、レコードが返却されないようです。
8つの ECS タスクが「実行中」になった状態
ECS タスクが アクティブ化中 → 実行中 と遷移します。ヘルスステータスが「不明」から「正常」に遷移します。
↓
ECS タスクが「実行中」状態での Cloud Map
Cloud Mapのヘルスは「正常」状態になりました。
ECS タスクが「実行中」状態での Route 53
クライアントが DNS に問い合わせると、Route 53 から新しいレコードが返されました。
補足
今回、10〜20 回くらい実験した際に、Cloud Map のヘルス が「不明」または「異常」の状態でも、Route 53 から新しいレコードがクライアントに返却されることがありました。
おそらく、Cloud Map のヘルス画面への状態反映が間に合っていなかったりするのでしょう。
ただ、前記事にも記載した通り、サービス検出では Route 53 のルーティングポリシーは「複数値回答(MultiValue)」になっています。
「複数値回答(MultiValue)」を選択しているとき、クライアント側では、DNS クエリを行って、最大 8 個の IP アドレスをキャッシュします。
もし、1つのウェブサーバーが応答しない場合は、キャッシュ内の他の IP アドレスにリクエストを送ります。
こういった仕様になっているので、「不明」または「異常」の状態のレコードがクライアントに返ってしまっても、長いダウンタイムにはならないのでは、と想像します。
複数値回答ルーティングは、複数の IP アドレスに DNS レスポインスを分散します。リゾルバーがレスポンスをキャッシュした後でウェブサーバーが使用できなくなると、クライアントはダウンタイムを避けるためにレスポンス内の他の最大 8 個の IP アドレスを試すことができます。
参考:複数値回答ルーティングポリシーとシンプルルーティングポリシーの違いは何ですか?
余談
夜の伊豆山稜線歩道をジョギングしてきました。
海に沈む夕焼けや星空が綺麗でした。