Help us understand the problem. What is going on with this article?

Amazon ECSに任せて見えてきたDockerのエッセンス

More than 1 year has passed since last update.

本記事は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 Architecture Diagram.png

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の方などにはおすすめします:nerd:

hihats
mainly in charge of architecture and its peripheral technology
https://hihats.pro
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした