こちらの記事でAmazon ECSサービス解体新書のブログをアウトプットしましたが、今回は前回書ききれなかったブルー/グリーンデプロイを中心に書いていきたいと思います。

※本記事に登場するIPアドレスや、サービス名についてはダミーの値を使用しています。

ブルー/グリーンデプロイ

ローリングアップデートとの比較で、ローリングアップデートはローラーを描けるように順繰り複数コンテナをアップデートしていくもの

とこちらの記事では説明しました。

Amazon ECSサービス解体新書

では、ブルー/グリーンデプロイとはどうやってデプロイしていくのか？

そもそもブルーとグリーンとは、

• ブルー環境: 既存の稼働環境であり、すでに本番運用されている環境です。デプロイメント作業中はこの環境へトラフィックを継続されます。
• グリーン環境: 既存の稼働環境からアップデートした環境のことであり、デプロイメント作業中はこの環境へのトラフィックはありません。

既存環境とアップデート環境を作って、アップデート環境側で正しく動作できていれば、トラフィックをアップデート環境に切り替えることでアップデートバージョンをリリースします。

ブルーグリーン/デプロイの流れを図に表すと以下の通りです。

1.productionのリスナーとtestリスナーを分けて、ブルー環境、グリーン環境を用意します。

Client側はブルー環境 (既存環境)にアクセスすることを継続させたまま、ブルー環境 (新環境)を構築します。

この際、ブルー環境はリスナーポートを別に追加することで、開発者はブルー環境の動作確認などを可能にします。

2.グリーン環境のデプロイ完了後、clientのトラフィックのルーティングをブルー環境 -> グリーン環境に変更します。

3.グリーン環境へのルーティング変更後、ブルー環境を削除します。

ロードバランシング

トラフィック先であるブルー環境、グリーン環境の設定はロードバランシングで行います。

リスナー/ターゲットグループの設定

リスナーやターゲットグループ自体の作成は、ロードバランシング -> ターゲットグループの画面から作成をしておく必要があります。

production用、test用のターゲットグループを事前に作成しておき、サービスの画面にて「プロダクションリスナー」「とテストリスナー」を事前に作成していたリスナーやターゲットグループを選択することができます。

サービス検出

サービス検出とはECSクラスター内の各サービス間の名前解決を可能にすることができます。

名前解決とは言っても、クラスター内部の話になるのでパブリックに名前解決するわけではありません。

内部的にはRoute53のプライベートホストゾーンを使用しているので、あくまでVPC内部での名前解決となります。

上図の「名前空間名」とは、イコール「内部ドメイン名」とほぼ同義です。

名前空間は論理的に関連するサービスのグループを定義するために使用されます。

名前空間内にはユニークなサービス名を持ち、サービス名と名前空間を合わせてDNSレコードが作成されます。

DNSレコードタイプは「A」を指定しているためIPv4を指定しています。

TTLは「Time To Live」の略称で、そのリソースレコードをキャッシュしても良い時間です。

以下の図を例に取ってみてみましょう。

赤い〇で囲われた部分が「名前空間」です。仮に名前空間名を「local」とします。

サービス名は「frontend-service」です。

この場合、frontend-service.localというDNSレコードが作成され、このレコードをクエリするとfrontend-service内のタスクのIPアドレスが返却されます。

複数のタスクが存在する場合には、タスク分のDNSレコードが作成され、タスク分のIPアドレスが返されます。

下図のようにクラスターが分かれている場合には、サービス名が異なるため名前解決はできません。

クラスターが分かれている場合にはALBやNLBなどを通じて後続のコンテナにアクセスする必要があります。

まとめ

ECS Serviceについてのまとめ記事第二弾はブルー/グリーンデプロイ、ロードバランシング、名前空間 (DNS名前解決)を中心に書きました。

コンソール上である程度の内容が理解できたら、次はIaC化に挑戦です。

現場で使用されるIaCツールはそれぞれ異なるかと思いますので、今自分が使用するものを理解に努めると良いかと思います。

参考書籍

AWSコンテナ設計・構築[本格]入門