こんにちはmatsです。
IMでは2016年の夏頃からdocker環境への全面移行を行っております。 一旦、一段落したので、色々とまとめてみようかと思います。
なぜECSを採用したのか
dockerの基盤としてはKubernetesやDocker Swarmなど、いくつか選択肢があり、IMでもいくつか検討してみましたが、下記の理由でECSを採用しました。
- Spot Fleet との相性がいい
- コンテナのオートスケールをCloudWatch連動で出来る
- 管理画面をAWSがホストしてくれる
- Docker Swarmをサポート予定（らしい）
色々理由はあるのですが、一番はサクッと試してみることができて、ラフに運用が出来るのが一番の理由だったりします。
何をdocker環境で動かしているのか
IMのほぼすべてのシステムがdocker環境で稼働しており、下記のようなサービスがあります。
しかし、Aerospikeまわりで数ミリ秒レベルの高速性が要求される箇所に関しては、dockerのネットワークレイテンシの影響が強く出るため採用していません。
dockerの運用で気をつけていること
基盤のAMIはAWSが用意したものをそのまま使う
設定内容によっては、AWSが用意しているECS向けのAMIをそのまま使いにくいケースもあるかもしれませんが、IMでは自前でAMIをビルドすることは行っておりません。
下記のようなことを徹底しており、docker基盤のLinuxの入れ替えが簡単に行えるようにしております。
- AWSが用意しているECS向けのAMIをそのまま使う
- 設定変更はcloud-initで行う
無理にAlpine Linuxを採用しない
docker界隈ではそのイメージサイズの小ささからAlpine Linuxが注目されていますが、IMでは採用するケースはあまり多くありません。
IMのアプリケーションはpythonで書かれているものがほとんどですが、ライブラリの中にはC拡張のものも少なくなく、OSによってはインストールのハードルが高いことがあるので、ライブラリの動作確認が取れているDebian (Ubuntu)を採用するケースが多いです。
また、アプリケーションエンジニアの多くが自分で調べて解決できる環境という点でも、マイナーOSの採用は慎重になったほうがいいかと思います。
基盤の運用にはSpot Fleetを使う
運用負荷とサーバコストの観点から、Spot Fleetにて基盤の運用を行っております。
適切に運用できればオンデマンドの1/4〜1/5程度の費用で運用が出来ることと、オートスケールのように自動復旧が可能になることからECSの基盤としてはベストな選択かと思います。ただ、AMIの入れ替えについてはSpot Fleetの設定を作り直さなくてはいけなかったりするので、若干使いにくい部分もあります。
まとめ
全環境でSpot Fleetを利用できる様になったことでコストの圧縮につながり、また、アプリケーションをコンテナ化することで運用・開発効率が上がりました。
次回以降はそれぞれのサービスについて少し細かく書いていこうかと思います。