こんにちは。インフラエンジニアの永井(shnagai)です。
今回は、Fargateを本番投入し1ヶ月強が過ぎたので、運用する中で気付いた点について書こうと思います。
以前書いた、Fargateに関する調査のまとめ記事はこちら。
内容はざっくり下記3項目です。
- いきなりFargateはハードルが高め
- 良かった点
- コンテナのリソースキャパシティを簡単に変更出来る
- オートスケーリングもシンプルに組める
- 安定運用
- つらい点
- タスクの起動速度がEC2バックエンドと比べるとやはり遅い
- 料金面
いきなりFargateはハードルが高め
Fargate導入を通して一番感じたのは、新規にコンテナ化するアプリケーションをECSで動かす場合、EC2バックエンドで試験をパス出来る状態まで持っていった後に、最後にFargateで動かすパターンがよさそうということです。
今回のFargateの本番投入では、 EC2で動いているサービスをDockerコンテナ化して新たにFargateでリリースするというものでした。 他のサービスでも同じような作業をしていたので、 Dockerコンテナ化やアプリケーション改修については比較的スムーズに終わりました。
サービス公開前に試験用ECSをFargateで作り、コンテナをデプロイして試験を始めたのですが色々と困りごとが起こりました。 アプリケーションがうまく動かず下記のような会話が繰り広げられました。
- 環境変数がうまく読み込めていないのでは?
- NW通信がうまく出来ていないのでは?
- ちょっと1コマンド叩いて検証したい。
docker exec でコンテナに入りデバッグ出来たらすぐに解決出来るような問題ばかりなのですが、Fargateはコンテナに入りデバッグが出来ないのがネックになりました。
初期の環境構築では、どうしても意図せぬ設定漏れ等が出てくることはあり、それを潰すための試験だったのですが、デバッグに時間がかかり非効率になってしまいました。
結局EC2バックエンドで試験環境を作り、試験をパスした状態でFargate用にタスク定義を作り直すというステップを踏むことにしました。
もちろん標準出力は、CloudWatchLogsにはかれるのである程度はデバッグ出来るのですが、NWの問題やOSレイヤのデバッグは少し厳しいなというのが正直な感想です。
本番運用後は、コンテナにログインするような事はないので特に問題ないのですが、開発フェーズではEC2バックエンドでdocker execでデバッグ出来る状態にしたほうが、効率よく作業出来ると思いました。
良かった点
ここからは、Fargateを導入してよかった点について書いていきます。
コンテナのリソースキャパシティを簡単に変更出来る
Fargateの最大のメリットだなと個人的に感じた点で、 これまで意識しなければならなかったクラスタを構成するEC2側のリソースキャパシティを考慮せずに、 タスク単位で自由に割当リソースの変更が可能となります。
※現状だと1コンテナあたり Memory:0.5〜30GB vCPU 0.25〜4の制限あり
下記図をみていただくとわかりやすいのですが、EC2バックエンドとFargateではコンテナに対するリソース割り当ての考え方が根本的に違います。
何が嬉しいかというと、負荷試験で決めたキャパシティが実際にサービスインしてみると不足していたり逆に少し過剰気味というようなケースやサービスが爆発的に成長してリソース増強が必要になるようなケースで、コンテナに割り当てるリソースの見直しを行うステップが劇的に簡単になります。
【EC2バックエンド時代】
- EC2バックエンドの実態である、AutoScallingGroup(ASG)でインスタンスタイプや台数を変更すると同時にECSサービス側で新しいASGでもコンテナが動くように起動数を調整
- ASGの変更内容を元に計算し、タスク定義にて1コンテナあたりに割り当てるリソース量を変更
- 新たなタスク定義でECSサービスを更新して反映
1のステップが特に面倒で、リソースを縮退する時には、コンテナがリソース不足で落ちてしまわないように注意を払う必要がありました。
これがFargateになると下記のように簡単なステップでリソースの変更が可能になります
【Fargate】
- タスク定義で、コンテナに割り当てるリソース量を変更
- 新たなタスク定義でECSサービス更新
クラスタ側のリソースは考えずに、コンテナに割り当てたいリソース量を変更するだけでOKとなります。
今後、Fargateに関してはリソース容量の増加や様々なアップデートがあるのではと予想していますが、タスク定義を変更するだけで柔軟に設定が変えられるのは大きなメリットだなと思いました。
オートスケーリングもシンプルに組める
オートスケーリングについても前述のEC2を意識しないキャパシティプランニングが可能なことと同じ理由で、 シンプルにコンテナあたりのCPU、MemoryもしくはELBでカウントするリクエスト数のしきい値ベースで設定が可能なので設定が簡単になります。
安定運用
1ヶ月強本番運用している中で、Fargate起因でサービスが落ちたことはないので基盤として安定しているのはとても安心出来ます。 ECSのオートヒーリングがあるので、仮に1コンテナ落ちたとしてもサービス影響は限定的ではあるのですが。
つらい点
今回一部のサービスをFargate化しましたが、全部を入れ替えるのはまだ先だなと感じたつらいポイントについても書こうと思います。
タスクの起動速度がEC2バックエンドと比べるとやはり遅い
Fargateにするとホストが固定されないため、Docker Pull時のレイヤキャッシュが効かなくなります。 それが理由でEC2バックエンド時代と比べるとECSサービス更新からコンテナが立ち上がるまでの時間が約1.5〜2分程遅くなりました。 その分デプロイ速度が遅くなってしまいます。
これはDockerイメージのサイズも大きく影響するので一概には言えないですが、アーキテクチャ上仕方ないとは思いつつ、AWSの今後の進化に期待したい部分だと思っています。 Cron的な起動時間が厳格に求められるスケジュールバッチのバックエンドには、FargateでなくEC2バックエンドを使うのが今のところは正解かなと個人的には思っています。
料金面
スポットインスタンスやリザーブドインスタンス(RI)を使って、EC2バックエンドでは大幅なコスト削減が可能です。 同じリソースを使った際のオンデマンド料金でも、Fargateの価格設定は少し割高かつRIのような料金プランもないので現状コスト比較をすると分が悪いです。
これは、来週開催されるre:invent かその後かはわからないですが、そのうちRDSのRIのように柔軟なリソース変更に自動適用する形でRIが発表されるのではと期待しています。
まとめ
先日、パラメータストアに置いた秘匿変数をタスク定義で環境変数に展開する機能がリリースされたり、 ECSでのDockerコンテナ運用は、Dockerイメージ+タスク定義で簡単に出来る世界が徐々に整備されつつあるなと感じる今日このごろでした。
コネヒトではコンテナ周りの基盤を整備したりサービス改善を行うエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。
