本記事はDocker Advent Calendar 2019の13日目の記事になります。
TL;DR
- Webサービスの運用をECSに全て任せる環境にしてみた
- したらいろいろ問題と発見がでてきた話
- 構築ノウハウではありません
- Kubernetesはまだちょっと敷居が高いかも…という方にちょうどいいかも
まえがき
通常、WebサービスをDockerで運用する場合で、AWS環境にデプロイするとしたら選択肢は
- EC2にDockerホストさせる
- ECS
- Elastic Beanstalk
もしくはリージョンにこだわらなければ
- EKS
になるかと思います。
せっかくDockerというシンプルな仮想環境を扱うので、マネージド感が強いEBより、dockerコマンドで動くことが直感的に描きやすいECSを使うことにしました。
が、使ってみるとECSもまぁまぁ独自性が強い（後述します）
基本構成
- CIサービスを用いてアプリケーションのビルド、アプリケーションが乗っかるDockerイメージのビルド、ECRへのpushを行う
- 最後の部分のPull（ECS ← ECR）とECSのサービスアップデートは手動でもいいけど、Githubでオペレーション全て完結したいのであればそのままCIサービスに任せるのがよいでしょう
- ステージングか本番か環境によってレジストリを変えるという手もあるが、せっかくステージングで動作保証ができているイメージが有るのであれば、それをそのまま本番へPullするのが素直で余計なビルドの手間も省ける
赤破線枠の中がECS（簡略化のためにMulti-AZやサブネットは省略しています）
ECSの独自性
ECSが扱う単位には
- クラスター
- サービス
- タスク
があり、さらにその中に複雑な定義箇所があります。それらがECSの理解の最初のハードルかと思います。
例えば、EC2にDokcerをホストする環境をつくり、イメージをPullして動かすにしても何かしらエージェントは必要でしょう。
仮に複数イメージを同時に起動し相互に連携させたいとなると
- グループ単位（docker-compose相当）でコンテナを管理するエージェントも必要で、それがECSでいうService
- 「個別のイメージ（プラスdocker runオプション）」がECSサービスの中で定義されるTask Definition
と個人的に定義しています。
そして、ECSクラスターは複数のEC2インスタンスと複数のServiceが多対多で関係しあって存在する状態も管理する。
Fargate
さらにFargateというサービスの誕生のおかげでEC2を意識することなく、「複数のServiceの中の複数のタスク」の管理だけでよくなりました。ホスティングの実体を意識しないで良いというのはある意味不安もありますが、無数のマイクロサービスの運用していくという点で考えるとこれは大きい。
速度や料金の問題から、フルスタックなWebサービスをFargateだけで賄うのはまだ先になりそうですが、Fargateで済んでしまうものは全てこちらに寄せたいと思わせるだけの力があります。
カナリーデプロイ
タスクを気軽にデプロイできる一番のポイント
ポートを分けて自分たちだけで本番で検証したり何かあったときの影響を少なくできるのが心強い
本題
ようやくかよ❗という感じですが上記のECS運用を踏まえ、ここからが本題になります。
コンテナ管理がベースになると小さくしたい欲が出てくる
- 本当に常駐しておかなければならないプロセス（コンテナ）はなんだ
- バックアップ処理や即時性不要な非同期ジョブは全て別コンテナに切り出せる
- コンテナのPortabilityがそのまま再利用性に繋がる
そしてそれらの効用として
マイクロサービスの粒度がつかめる
基本的にECSタスクで分割できるということはそういうこと
とにかく、アプリ間の依存がないというのは素晴らしい
リソースを意識せざるをえない
Fargateの「EC2を意識しないでよい」点とは矛盾するようだが、インスタンスリソースはよしなにやってくれるという信頼があると逆説的に落とせるコンテナは落としたくなるため、リソースやコスト意識が勝手に高まる。イメージの軽量化や分割の技術が、増え続ける世の中のコンピューティングリソースの問題に対して大きな意味をもつようになってくると感じます。
あとから気づく課題
レジストリのグルーピングをちゃんとしたい
最初から名前空間/ で計画的に切っておけばよかった
ECSサービスのグルーピング、名前付け重要
上のレジストリもそうだが、ECSサービス名やタスク名など、あとから変更するとなるとなかなか手間がかかる
タスクを増やすのは気軽にできるが
そのためにcloudformationのテンプレートを毎度書くのはなかなか手間だしALBのターゲットグループへの依存が増えるのが少し気になる。
まとめ
総合的なコストは他の運用方法とさほど変わらず、それでいて得られる知見が多いです。
開発環境はDockerだけど、本番ではやったことのないSREの方などにはおすすめします