こんにちは。インフラエンジニアの永井(shnagai)です。
この記事はコネヒト & aws-fargate Advent Calendar 2017 22日目の記事です。
※本当は別記事二本書く予定だったのですが、パワー不足で一本にまとめさせてもらいました。
コネヒト Advent Calendar 2017 - Qiita
AWS Fargate Advent Calendar 2017 - Qiita
コネヒトでは、本番環境のほとんどのサービスでDockerを導入し、ECSを使ってサービス運用しているのですが、今回のre:Inventで発表されたFargateにこの環境を置き換えるとどんな未来が待っているかについて、考察してみました。
現状の自分が認識している情報ベースで書いているので、正確な情報とはいえずツッコミあれば指摘いただけると幸いです。
目次
- Docker導入で何を目指したかったのか
- 下記テーマについて、ECS→Fargateにリプレイスした先の未来を考察
- インフラ的な運用面
- コスト面
- 監視周りの話
- スケジュール系バッチと集計系バッチの話
- これからの課題
- まとめ
Docker導入で何を目指したかったのか
そもそもECSやFargateを動かすには、アプリケーションの実行基盤をDocker化する必要があります。 コネヒトでは、約半年かけて開発環境から本番までDocker化を進めてきたのですが、改めて目指していた状況と現在を振り返ってみたいと思います。
【解決したかった課題】
- 開発環境が不安定
多数のVMにより、ホストに負荷がかかり重くて開発速度に支障が出てきていた
- 本番/開発環境の乖離
開発、本番それぞれ別環境/オペレーションでOSやミドルウェアのメンテが必要なため必然的に乖離が生じる
【導入後の経過】
- 開発環境が不安定
Docker for Mac特有の問題が少しあるものの、概ね開発環境への不満はなくなりました。
- 本番/開発環境の乖離
Dockerfileに全ての情報を集約した為に、開発者自身がDockerfileをメンテナンスしながら日々の開発が行えるようになりました。 よくある、開発者からインフラへの「本番にこれ入れたいんでお願いします」的な話がなくなりました。 これは、アプリケーション実行基盤自体をコードで管理するというDocker化の一番の恩恵なのかなと思っています。
【新たな課題】
当初の目的は達成したのですが、Dockerの実行基盤としてECSを採用した為、今度は、ECSに関するオペレーションが新たな課題として持ち上がってきました。 ECSは、ご存知の通りEC2を束ねたクラスタを組みその上に、Dockerのコンテナを動かすというDockerオーケストレーション層のサービスです。
故に、EC2を強く意識しながら運用することが求められます。
- キャパプラする時に、ホスト(EC2)側のリソースとタスク(コンテナ)のリソースを計算しながら本番トラフィックを捌ける構成を組む
- 監視に関しても、コンテナ+ホスト(EC2)に関する二重の監視が必要
なので、インフラレイヤ含めたアプリケーション実行基盤は開発者だけで作れても、ECS上でトラフィックに耐えうるサービスとして動かすところはECSの専門的な知識がないとちょっと難しいという状況が生まれました。 キャパプラ・監視・デプロイ等、ECSのアーキテクチャを理解してないと運用は難しいといった問題が出てきたというところです。
そして、EC2を強く意識する運用から脱却したいなと待ち望んでいたところに、今回のre:InventでFargateというDockerコンテナのマネージドサービスが発表されました。 ここからは、東京リージョンにFargateが来てECSからFargateに乗り変えたらどんな未来が待っているのかというのを、自分が今認識している情報ベースで書き連ねたいと思います。
ECSからFargateに移行するとどうなるか
4つのタームに分けて個人的な考察を書きます。
Fargate実際に触ってみた時の所感はこちら！ tech.connehito.com
インフラ的な運用面
現状
①クラスタ内のホスト(EC2)とタスク(コンテナ)を意識しながら、キャパシティプランニングをしないといけない
ECSだとクラスタとタスクを連動して考えないとならず、クラスタのキャパシティを確保した上で、タスク(コンテナ)のリソースを考えないといけない。 これは、オートスケールを組む際も同じで、面倒&事故につながる可能性も高いので今は使いづらい。 ※オートスケールをCPUトリガにしてても、緩やかに上っていくというより一気にしきい値超えてくるような状態多いですよね。だから、結局クラスタに余裕もたせる戦略の方が安全という話
②新規開発時にうまく動かない時は、たまにコンテナにSSHしてデバッグすることがある(あまりやらないようにはしてるけど)
例えば、新しいツールをECS上で動かそうとする時に、意図しない挙動をする事がある。 そんな時は、テスト環境でタスクを立ち上げて、コンテナ内にSSHして何が起きているかデバッグしている。 いくらDockerで開発環境で動いたものを持っていくと言ってもいざという時にデバッグは必要。 トラブル起きてる時に、top叩いてあたりつけたいですよねという話
Fargateになると
①の苦労がなくなる事が、Fargateを導入する一番のメリットになるのではと個人的には思っている。 ECS環境作る時に、裏にいるEC2を強く意識しながらサービスを作っていたからそこから解放されるのは大きい。 オートスケールする時に、まずEC2のリソース確保してからその中でスケール出来るコンテナ数とか考えたくないですよね。
②に関しては、マネージドサービスを使う時点で、SSHはまぁ出来ないだろうなという印象。 只、いざというときのデバッグを出来るような仕組みは欲しいなというのが正直なところ。
願望
サービスのオートスケールにAutoScalingGroupにあるようなスケジュールでスケールする機能がついてくるうれしい。サービス毎にピークタイムはもちろん異なると思いますが、予め予測出来ている負荷に対しては準備しておきたい。 これ入ると、かなり動的にコンテナ数を増減しながらコストメリットも出していくような未来的な運用が出来そうだなと思っています。
コスト面
現状
Blue/Greenデプロイを実現するために、必要なコンピューティングリソースの2倍をEC2インスタンスとしてクラスタ内に構えているため、サービスを稼働するために必要なコンピューティングリソースの2倍の金額がかかっている。 が、EC2のリザーブドインスタンスを使ってるので、実質は、オンデマンドインスタンスの四掛くらいの料金がECSでサービスを動かすためのコストとして掛かっている。
Fargateになると
ざっくり、オンデマンドインスタンスとの比較で約2倍の料金設定というレポートがあったので、クラスタで常時動くコンピューティングリソースが半分になると考えるとコスト的には現在と変わらないか、リザーブド値引き分があるので、少しコストが上がるのかなという感覚。 ココらへんは、東京リージョンにローンチされてサービスメニューを見てみないとなんとも言えないので、来たら確認しようと思う。
こちら参考にさせていただきました。http://tech-blog.abeja.asia/entry/fargate-ecs-spotfleet
願望
バッチ的な使い方でなく、Web環境で使うとなるとある程度固定的にコンピューティングリソースを確保しておきたいという要望はかなりあると思うので、コンピューティングリソースのリザーブド的なメニューが出てくるのではと推測しています。裏で動いているのはEC2だと思うので、リソースを予約してコストダウン図れるようにしていけたら幸せだなと思っています。
監視周りの話
現状
- ECSだと、サービス(同じ役割のDockerコンテナの集合体)単位とクラスタ(EC2インスタンスの集合体)単位で監視をしている
- ECS関連で取れるメトリクスは、CPU,Memのみで、Web環境に関しては、ALBのUnhealthyHostをコンテナの生存確認としてチェックしている
- EC2側は、AutoScallingGroupのNWIn/OutとStatusCheckFailだけチェックしている
Fargateになると
監視項目はかなり減りそう(とれるメトリクスがCPU,Memだけなので)
- CPU,Memをタスク定義で1コンテナあたりに割り当てていくから、今でいうサービスで取れるメトリクスの(CPU,Mem)だけを見ておく状態??
- Memoryはハードリミット一択になりそうだから、OOMは気をつけないといけない
- CPU使用率が一番重要なメトリクスになるのは今と変わらない
- EC2側で気にかけているStatusCheckFailは不要になる
FargateのCPU,MemとALBから取れるメトリクスを組み合わせて監視を作っていく形になるだろう。 只、見るべきポイントが少なくなるのはマネージドサービスの恩恵を受けれる部分で、安定運用しているうちは変に高濃度なメトリクスは取ろうとしないで運用をAWSに任せるのが良いアプローチな気がする
願望
それこそDatadogとかMackerelとか使えよという話だが、プロセス監視とか高濃度メトリクスを手軽に取れるとよさそう。 後は、1台だけにNewRelicのようなミドルウェア入れるみたいな事出来るといいなと。 CloudWatchのメトリクスが何もしなくても値取ってきてくれるイメージで、Fargate(ecs-agent??)に組み込みの形で任意のメトリクスとか取れるといいなと思っています。
スケジュール系バッチと集計系バッチの話
現状
- スケジュール系、集計系バッチともに、ECS ScheduleTasksを使って実行している
- 現状起きていないが、集計系の重い処理はホスト側のリソース競合が起きることを念頭に起きながら運用しなければならない
Fargateになると
バッチ系に関しては使い分けが必要と個人的には思っている
集計系バッチ処理
- 時間への強い制約がないので、Fargateで強めのコンピューティングリソースを使いと従量課金でやるのがよさそう。Lambda的な時間制限もないので、この使い方は普及しそう
スケジュール系バッチ処理
- 何時何分に動くことに意味があるバッチとかだと、どうしても初回起動の遅さがあるかなというのを危惧している(もちろんDockerイメージのサイズによるところが大きいがホスト固定されない分、Pull時のキャッシュが効かなくなるから)
- ひとまずは、今のScheduleTaskで運用して様子を見る
願望
特になくて色々なユースケースが集まってくるといいなと思っています。
これからの課題
コネヒトの今見えているDocker周りに関する課題について、書いておこうと思います。
- Docker導入を優先してやってきたので、Dockerイメージのリファクタ等に手をつけられておらず、イメージスリム化しないとFargateだと起動が遅くなるだろうからそこに着手
- デプロイフローをECSありきで組んだので、Fargateにフィットさせるべく改良
- すぐに使うことはないけど、k8sの情報も追いかけながら最適なDockerのサービス運用環境を探っていく(最近の話だと、マイクロサービス化した時の内部通信(例えばAPI間通信とか)はk8sのプロキシスタイルのほうが優秀なのかなと思ってる)
まとめ
今思ってることを書き連ねてみたが、Fargateを導入することで運用コストを下げてコンテナをサービス運用する、幸せにそうな未来が見えてきたので、早く東京リージョンに来て色々とやっていきたい。
手元で開発したコンテナを、あまり何も考えずにサービスとして動かせる未来が近づいてきている感じがした。(最初にオートスケール等を組んで運用にのせれば)
| テーマ | ECS | Fargate | 補足 |
|---|---|---|---|
| インフラ的な運用面 | ☓ | ○ | EC2管理からの解放！！SSHは出来ないだろうけどそこはマネージドサービスと割り切る |
| コスト面 | △ | △ | Fargateの方が少し高くなるのかも??(未知) |
| 監視周りの話 | △ | ○ | 気にかけるべきメトリクスが減るのは良いこと |
| スケジュール系バッチと集計系バッチの話 | ○ | ○ | Fargateはコンテナ起動速度が少し気になる(Dockerイメージサイズ次第) |
明日のコネヒトアドベントカレンダーは、katsutomu さんによる、記事です。 お楽しみに！
コネヒトではコンテナ周りの基盤を整備したりサービス改善を行うエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。
