[追記] この記事の内容について訂正
この記事内、及び Speaker Deck に投稿したスライドの中で誤っていた箇所があったため、訂正致します。
「ECS Optimized AMI では ecs-agent のバージョンが固定されない」という内容ですが、そういった問題はありませんでした。
AWS の方から直接アドバイスを頂いたところ、弊社が使用していた User Data のスクリプト内で $ yum update を実行していたことが原因となっていました。
$ yum update によりインスタンスを新規に立てた際に常に最新の ecs-agent や Docker がインストールされていました。
そのため、ECS Optimized AMI によってインストールされる ecs-agent と Docker のバージョンは以下のドキュメントで提示されているバージョンが常にインストールされることになります。
スライド中でも紹介しているように、一番困っていた問題が解消されたため AWS のサポートの方には非常に感謝をしております。
誤った情報を公開してしまい、申し訳ありませんでした。
こんにちは、バックエンドエンジニアの tsub (
id:tsub511) です。
先日の社内 LT 大会にて、「ここがつらいよ ECS」というタイトルで発表してきました。
社内 LT 大会の記事についてはこちらをご覧ください。
私が発表したスライドはこちらです。
せっかくですので、スライドにて紹介している「第一位 ecs-agent と Docker のバージョンが勝手に上がる」についてもう少し詳しく解説をしたいと思います。
ECS を用いたバッチシステムの運用について
弊社では Amazon ECS を用いたバッチシステムを運用しています。
Amazon ECS を用いたバッチシステムについての詳細は以前弊社の新卒エンジニアが書いてくれたので、こちらの記事をご覧ください。
ecs-agent について
ecs-agent とは、Amazon ECS にインスタンスを認識させるために動かす必要のあるエージェントです。
Docker イメージが配布されていて、通常はコンテナとして立ち上げます。
ECS Optimized AMI を利用していれば、インスタンスを起動したタイミングで勝手に立ち上げてくれるので、特に意識せずとも ECS を使えると思います。
ただし、ECS においてはこの ecs-agent がコンテナの配置、監視などを行っているため、かなり重要な役割となりますので、無視してはいけない存在です。
ecs-agent のバグによりいくつかのタスクが起動しなかった
以前、以下の Issue で取り上げられている ecs-agent v1.14.2 のバグにより ECS でいくつかのタスクが起動しなくなっていました。
2017/06/08 に ecs-agent を全コンテナインスタンスで v1.14.2 にアップデートしたことにより、06/08 から 06/13 にかけて 6 つのタスクが PENDING 状態のまま止まっていてインシデントが起きてしまいました。
この時は、上記 Issue でも書かれているように、一旦 amazon/amazon-ecs-agent:latest イメージにバグが発生する以前の v1.14.1 を Push し直してくれたことで、バージョンをロールバックすることはできました。
ただ、このような問題を再度起こさないためにも ecs-agent のバージョンは固定したいところですが、固定はできないという問題がここで発覚しました。
ECS Optimized AMI では ecs-agent のバージョンが固定されない
ECS Optimized AMI を使っていれば ecs-agent を自動的に立ち上げてくれますが、これが少々曲者です。
ECS Optimized AMI を使ってインスタンスを立ち上げた時、起動する ecs-agent のバージョンは常に最新のものが使われるのです。
しかも、AMI の中に ecs-agent がパッケージングされているかと思ったら、AMI をアップデートせずとも、インスタンスを新しく起動したら最新の ecs-agent が自動的に使用されます。
更に言うと、この ecs-agent のバージョンをユーザーが固定することはできず、最新バージョンしか選択肢がありません。
そのため、上述したようなバグが ecs-agent に含まれてしまった場合に回避不可能になります。
新たにインスタンスを立ち上げず、手動で ecs-agent をアップデートしなければ今動いてるもののバージョンが変わることはありませんが、オートスケーリングの設定をしていた場合、スケールアウトしたらそのインスタンスからは最新の ecs-agent が使われてしまう、という状況です。
この回避不可能な仕様に日々悩まされています。
ちなみに、Docker のバージョンも ecs-agent と同じようにバージョンが固定されていません。
どう運用しているか
では、弊社ではどう運用しているかというと、一部のコンテナインスタンスにカナリアリリース的にアップデートし、しばらく最新バージョンの ecs-agent をクラスタの中に紛れ込ませて稼働させておきます。
例えば 10 台のコンテナインスタンスを動かしていたとして、その内の 2, 3 台だけ ecs-agent をアップデートします。
アップデート自体は AWS コンソールから可能ですので簡単です。
数台だけアップデートした後 1, 2 週間ほど経ってから ecs-agent の Issue を確認して、特に大きな問題が起きてなさそうなら全台アップデートする、というような運用をしています。
これで今のところ ecs-agent のバグを踏む確率は多少減ったかな、という印象です。
まとめ
- ecs-agent のアップデートによりバグが入り込む可能性がある
- ECS Optimized AMI における ecs-agent と Docker のバージョン固定はできず、新しいインスタンスを起動すると最新が使われる
- 一部のコンテナインスタンスだけアップデートし、しばらく経って問題なければ全台アップデートする、という運用をしている
というわけで、今後も ECS による運用を続けていきますが、何か良いソリューションがあれば教えていただきたい次第です。
