BETA

ECS(on EC2)をterraformで管理し始めの頃の自分へ7つのアドバイス

投稿日:2020-05-10
最終更新:2020-05-10

sumamry

  • ECS(on EC2)をterraformに関するアドバイス集
  • 定義、更新、運用の3つの観点から全部で7つ
  • 図はなくて文字だらけですまない

context

ECS(on EC2)をterraformを始めてみる頃は、以下のような状況だった

  • もともとAWS上で、EC2上で直接Webアプリが動いている
  • AWS経験は4年くらい
  • terraformは雰囲気で触ったことあるレベル
  • dockerの基本的なところはわかる

topic

terraformとかAWSの知識についてはあまり補足しないため、わからない用語は各自で調べてください。

terraformリソース定義の観点

この観点のアドバイスは3つあります。

capacity provider

terraformで定義するときは留意が必要なリソースです。
留意点は2つあります。

  • リソースの命名をユニークにする利用する
  • Auto Scaling Groupはリソース自体がユニークであるようにする

まずはわかりやすい、リソースの命名をユニークにする利用する方から。

同名のcapacity providerは作成することができないAWSの制約があるため、
置換するような形で更新がかかる場合、命名が被らない工夫が必要です。

これはcapacity providerは削除できないAWSリソースだからです。
※terraformのドキュメントにも記載あり

削除時にterraformの管理から外れますが
disableなAWSリソースとして残り続けます。

続いてAuto Scaling Groupはリソース自体がユニークであるようにするについて

capacity providerが置換して更新される場合、capacity providerはdisableになるだけで残っており、同じAuto Scaling Groupを参照してしまうため、AWSの制約違反で更新に失敗します。

この制約はAuto Scaling Groupは1つのcapacity providerにのみ設定できるというものです。

機能の説明を少し補足します。
capacity providerは、ECSでコンテナを稼働させるAWSリソースをいい感じに手配する機能です。
EC2ではコンテナインスタンスを手配することになるため、Auto Scaling Groupが中で動くことで実現します。terraformのリソース定義時に、Auto Scaling Groupを指定するのはこのためです。
※fargateの場合はfargateのサービスが該当します。fargate自体がcapacity providerです。

Elastic Load Balancer

まだterraformで定義できない設定があります。

Support ALB weighted target groups · Issue #10942 · terraform-providers/terraform-provider-aws · GitHub

target groupごとにルーティングの重み付けをする設定がまだ定義できません。

この辺りは機械的に管理するというよりかは、手動で調整するケースの方が多い気がするので
無理にterraformで管理するよりも、ベースとなるルーティングのルールまでをterraformで作成して、あとは手動で状況によって調整していくのがよいかもしれません。

terrafromには定義がなさそうにみえるリソース

これはterraformの仕様というよりもAWSの仕様に関してです。
実際に作成されるリソースは、既存のAWSリソースの組み合わせであることが多いということを心に留めておくと、新しい用語がたくさん出てきても戸惑うことが少なくなります。

AWSのドキュメントなどを見るとECS向けに以下のようなサービスないし機能が紹介されていますが、いずれも既存のサービスの組み合わせです。

  • ECSサービスオートスケーリング
  • ECSクラスターオートスケーリング

AWSのコンソールで作成するときと、terraformで定義するときのリソース名は違う名前だったりするのはこのためです。

例えば、サービスオートスケーリングはterraformではそのままの名称では定義がありません。AWS Application ScallingのECS用の設定を行います。
CPUやメモリなど、指定したメトリクスに対するCloud watchアラームが作成され、データを元にサービス数を調整してくれます。

同様に、クラスターオートスケーリングというリソースはterraformの定義としてはなく、capacity providerを定義してECSのクラスタに適用することで実現できます。

terraformリソース更新の観点

この観点のアドバイスは1つだけです。

更新時の依存関係などは、ある程度自動的にterraformが計算してやってくれます。

展開するdocker imageなどを更新した場合、ECS task定義の更新や、task定義更新に伴うECS service定義の更新も一緒に実施する必要がありますが、この辺りは自動で依存するリソースにも更新をかけてくれます。

terraform運用の観点

この観点のアドバイスは3つあります。

スケールイン・アウトの挙動に関して

まず前提として、EC2で実施する場合、並べるコンテナの数を調整するサービスオートスケールと、コンテナを並べるためのコンテナインスタンス数を調整するクラスターオートスケーリングがあります。

どちらもメトリクスを基準に、数を調整するため、増やす・減らすの2つのCloud watch alarmがそれぞれ作られます。

サービスオートスケールの方は、CPUやメモリ基準ですがタスク定義がゆるいと、メトリクスが20,000%とかになってしまうので予約CPUやメモリの値は、実測値から設定しておくとよいでしょう。

また、クラスターオートスケールの方は、CapacityProviderReservationという値を基準にスケール判断をします。必要なタスク数と実際に稼動できているタスク数の割合という感じですが、詳しい計算方法は公式の説明を方がわかりやすいでしょう。
Amazon ECS クラスターの Auto Scaling を深く探る | Amazon Web Services ブログ

なお、サービスオートスケーリングの最大値を0にすると、土台となるコンテナインスタンスを0までスケールインすることができます。(これは本番以外の利用しない時間帯がある環境で利用するのに使えます)

EC2に付与するtag設定について

Capacity Providerを作成するとき、紐づけられるAuto Scaling Groupは管理するインスタンスにECS管理だよってタグを付与するようになります。

terraformで定義してなくても作られて、別で更新した時に削除してしまうのでちゃんとterraformでも意図的に定義する必要がある。

Amazon ECS クラスターの Auto Scaling - Amazon Elastic Container Service

環境レベルでの構成管理

本番環境、開発環境といった構成の管理のこと。

更新漏れなどの懸念もあるが、それは別手段で回避しようがあるので、
terraformではstateを分けて管理する方がベターです。

ルートモジュールを分けることで、環境ごとに読み込むモジュールを少し変えたり、部分的にモジュールを追加したり、削除したりできる恩恵を受けれれる。

環境ごとに差異がないほうがよいのは理想だが、アップデートや構成変更で一時的に環境差異を吸収できる方が運用しやすい。

まとめ

ずらずらと書きました。terraformで管理すると気づきにくいミスもいくつかありますが、AWSコンソールでぽちぽちしていると気づかなかった連携の仕組みとか、気づけることが多い点もメリットかもしれません。誰かに教える時になった時に当時を思い出せない将来の自分や、同じような状況でECS(on EC2)をterraformで管理し始めようとしている人の参考になればうれしいです。

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@mesh1nek0x0の技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう