AWS Fargateを採用せずにシンプルなECSを採用した話
AWS Fargateを採用せずにシンプルなECSを採用した話:
この記事は、Recruit Engineers Advent Calendar 2018 5日目の代打記事です。
どうも。リクルートライフスタイルでプロダクト開発をしています @tacumai です。
今回はタイトルにもある通り、あえて便利なFargateを使わずにAWS上でコンテナ利用を行なったときの話をしたいと思います。
言わずもがな、とはおもいますが、改めてざっくり説明すると、AWS FargateとはAWSが用意してくれているコンテナマネージドサービスの1つで、日本でも2018年ごろからしだいに使われるようになったサービスになります。関連（というか前代）としてECSが存在します。雑にできることの対応表を整理すると以下のようになります。
AWS Fargateの利点はなんといってもインスタンス管理を必要としない部分。開発者はホストの管理に悩まされることなく、コンテナの中身に集中できるようになるので、非常に便利なサービスとして一躍有名になりました。一方で、ECSの場合は自分たちでインスタンスを生成し、そこにDocker実行環境を整備することを目的としたサービスなため、ホスト管理・必要に応じたスケーリング対応・モニタリングが必要となってきます。
ここでようやく自分の話に入れるのですが、最近ぼくはAWS上に高負荷試験を実行するための環境をつくっていました。これまでは
さらにこの環境のサーバは長年かけて積み重なったサーバの状態をむやみに変えることはできず、どうなっているのか誰もわからない状態になっていたので危険です。こういうことになり始める前にコンテナ化でもしてあげてプロビジョニング不要な世界・状態を気にしないでもいい世界をつくらなければなりません（過激派思考で申し訳ない）。
そこで、せっかくコンテナ運用サービス・オペレーション支援ツールも手厚いAWSを使っているのですし、もう少し楽に負荷試験できるような環境にしたいなと思い、取り組んでみました。
しかし、思ったよりもセキュリティ制約が厳しく、AWS Fargateを素直に使うとエライ目にあうな?ということに気づき始めます。以下に主なセキュリティ要件をリスト化します。
この制約のために、AWS Fargateの長所が短所に変わりました。AWS Fargateはインスタンス管理を不要とする部分が長所の1つなのですが、 「コンテナを実行するたびにAWSが勝手にIPを振り分けたリソースを提供する」 ということを裏でやっているにすぎないため、コンテナ（正しくはタスク・サービス）が実行されるたびに新たなリソースを生むことになり、その都度IPが変わります。そして今回の制約の
これはこれで運用が面倒になります。インスタンス管理しなくて済むメリットがありつつも、NWの面倒をみなきゃいけないので逆にめんどくささが増しかねません。僕一人だけの運用であればまだ良いのですが、他の人にもゆくゆくは運用してもらいたいので、AWS Fargateを使うのはむしろ握手なのでは...?という気持ちが次第に強くなっていきました。
以上の懸念により、 「むしろECSにしたほうがよいのでは!!!!!!」 と考え始めました。
つまり、古き良き?インスタンスと固定IPが利用できるメリットは大きいと判断。
インスタンスのリソースマネジメントを定期的にしなければなりませんが、ネットワーク運用の負担がほぼゼロになるのは嬉しいことなので、このような構成を組んで新たな環境を構築しなおしました。
構築した環境で得られたメリットは以下の通りです。
以上、あえてECS採用したよ、という話でした。
この記事は、Recruit Engineers Advent Calendar 2018 5日目の代打記事です。
どうも。リクルートライフスタイルでプロダクト開発をしています @tacumai です。
今回はタイトルにもある通り、あえて便利なFargateを使わずにAWS上でコンテナ利用を行なったときの話をしたいと思います。
そもそもAWS Fargateとは
言わずもがな、とはおもいますが、改めてざっくり説明すると、AWS FargateとはAWSが用意してくれているコンテナマネージドサービスの1つで、日本でも2018年ごろからしだいに使われるようになったサービスになります。関連（というか前代）としてECSが存在します。雑にできることの対応表を整理すると以下のようになります。| AWS Fargate | AWS ECS | |
|---|---|---|
| 概要 | インスタンスの運用を気にすることなく、必要に応じてコンテナを作れる | 自分たちで管理するEC2上にDocker実行環境をつくってくれる。冗長性も高めることができる。 |
| Dockerイメージのリソース | どこでも(主にECR?） | どこでも(主にECR?） |
| インスタンス管理 | ナシ | アリ |
| 運用コスト | ◎ | ▲ |
負荷試験環境をつくるにあたり...
ここでようやく自分の話に入れるのですが、最近ぼくはAWS上に高負荷試験を実行するための環境をつくっていました。これまでは- サーバにログイン
- サーバ上で負荷試験用のシナリオを最新化
- 実行
- サーバの状態を変更したいときは他チームとの調整・慎重な動作確認
さらにこの環境のサーバは長年かけて積み重なったサーバの状態をむやみに変えることはできず、どうなっているのか誰もわからない状態になっていたので危険です。こういうことになり始める前にコンテナ化でもしてあげてプロビジョニング不要な世界・状態を気にしないでもいい世界をつくらなければなりません（過激派思考で申し訳ない）。
そこで、せっかくコンテナ運用サービス・オペレーション支援ツールも手厚いAWSを使っているのですし、もう少し楽に負荷試験できるような環境にしたいなと思い、取り組んでみました。
直面した課題
しかし、思ったよりもセキュリティ制約が厳しく、AWS Fargateを素直に使うとエライ目にあうな?ということに気づき始めます。以下に主なセキュリティ要件をリスト化します。- 基本的にインスタンス/アプリケーションを直接グローバル環境に出すのはNG。プライベートなサブネットの中で管理すること
- インターネットからのアクセスを許可したい場合は、LBを経由すること
- たとえ開発に必要なツールで社内からのアクセスだけを想定していても上記は守ること
この制約のために、AWS Fargateの長所が短所に変わりました。AWS Fargateはインスタンス管理を不要とする部分が長所の1つなのですが、 「コンテナを実行するたびにAWSが勝手にIPを振り分けたリソースを提供する」 ということを裏でやっているにすぎないため、コンテナ（正しくはタスク・サービス）が実行されるたびに新たなリソースを生むことになり、その都度IPが変わります。そして今回の制約の
2. にあたるのですが、LB経由でコンテナが持つIPにアクセスを許可したいため、タスクを実行するたびにLBのターゲット設定を変える必要がありました。これはこれで運用が面倒になります。インスタンス管理しなくて済むメリットがありつつも、NWの面倒をみなきゃいけないので逆にめんどくささが増しかねません。僕一人だけの運用であればまだ良いのですが、他の人にもゆくゆくは運用してもらいたいので、AWS Fargateを使うのはむしろ握手なのでは...?という気持ちが次第に強くなっていきました。
最終的に実現させたこと
以上の懸念により、 「むしろECSにしたほうがよいのでは!!!!!!」 と考え始めました。つまり、古き良き?インスタンスと固定IPが利用できるメリットは大きいと判断。
インスタンスのリソースマネジメントを定期的にしなければなりませんが、ネットワーク運用の負担がほぼゼロになるのは嬉しいことなので、このような構成を組んで新たな環境を構築しなおしました。
実際に使ってみて
構築した環境で得られたメリットは以下の通りです。- プロビジョニング不要な世界をつくることができた
- DockerImageさえ固まっていればあとはタスクを実行するだけのシンプルな作業で済むようになった
- 他チームにも活用してもらえる汎用的な環境に整えることができた
- サーバの状態を気にせずに済むようになった
- インフラ管理の手間も最小限になった
- リソース管理はしなければなりませんが、これはAWS Fargateを使わないデメリットを享受することと動議
- 厳格なセキュリティ要件に叶った環境に仕立てることができた
以上、あえてECS採用したよ、という話でした。
コメント
コメントを投稿