AWS Fargate で使える Reserved/Spot コンピューティング・リソース機能が欲しいですね

AWS Fargate Advent Calendar 2017 の 24 日目です.

記事のアイデアを練り始めたときは「流量が安定しない Amazon SQS キューと AWS Fargate で動かす “lazy-worker” なコンテナってすごく相性良さそうですよね」という小ネタを書くはずだったんですが、気づいたらなぜかポエムになっていました. しかも図が一つもありません. お許しください.

リリースされたばかりということで AWS Fargate とその関連機能について間違って理解している可能性もあります. 発見された方は Twitter とかで構わないので教えてもらえると嬉しいです.

AWS Fargate で見られる夢

AWS Fargate は任意の Docker コンテナを一定の制約の範囲内で仮想マシンのプロビジョニングや管理なしに走らせてくれる夢のサービスです.

どのへんに夢があるかというと、以下のような点について我々が考える/対処する必要がなくなるところです.

• どんなインスタンス・タイプの EC2 を起動するか
• VM で走る docker-engine¹、ecs-agent のバージョン
• VM 内ミドルウェアの脆弱性対応
• クラスター・キャパシティの過小/過大問題
  逆に言うと、これらは AWS 側に隠蔽されているので考えたところで何もできなさそう. 我々にやれるのはガチャをやって実行環境が変わることを祈るぐらいですかね.

VM の状態を意識しなくてよくなるため、少なくともコンピューティング・リソースを確保するユーザー視点においてはコンテナより下のレイヤーについては何も特別なことをしなくても完全にイミュータブルなものとして取り扱うことができる、というのも夢の一つかもしれません. 最高なサービスですね.

今後どういう形で Fargate や ECS に機能追加が行われるかにもよりますが、もしかしたら以下のような夢も捌けるようになる日がくるかもしれません.

• EC2 で動かしている既存 ECS サービスの負荷が高まってきた際、EC2 ではなく Fargate 側でスケール・アウトするとか
• 謎の技術で VM の用意や docker pull にかかる時間が隠蔽され、API を蹴ったら秒でコンテナが実行されるとか
• それにより負荷の高まりに対して秒単位でスケール・アウトしまくるとか
  (カッコいい…

AWS Fargate が解決する「ネットワーク二重設計」問題

一般に Fargate のメリットは「VM レイヤーのコンピューティング・リソースを隠蔽してくれること」と言われているような気がします. 出典はありませんが.

これは間違いではなくて、たとえ Fargate を使っていてもコンテナそれ自体のメリットが強化されたりデメリットが軽減されたりすることはありません. docker pull の時間は相変わらず必要だろうし、同一のコンテナが同じ時間で処理できる作業量は自前の EC2 インスタンス上で動かしたときと変わらないでしょう. スケール・dアウトにかかる時間が劇的に短くなることもないし、Docker イメージ内部の脆弱性対応は相変わらずユーザー側でやる必要があります.

では Fargate が解決してくれる問題とはなんなのか.

僕は AWS 環境のコンテナ・ワークロードにおけるネットワーク二重設計の複雑さ・煩雑さの解消こそが Fargate の最大のメリットだと考えています².

コンテナが最近のように当たり前になるまで、すべてのアプリケーションを生 EC2 で使っていた頃は、今考えるといろんなことがもうちょっとシンプルでした. VM とそこで動くアプリケーションのネットワーキングやサイジングさえ考えていればアプリケーションは普通に動かせたし、脆弱性対応に代表されるミドルウェア・パッチなどのメンテナンスについても VM のレイヤーについてだけ考えていれば OK でした(多少語弊はありますが). 例えば VM 内で動いているアプリケーション名を EC2 インスタンスのタグに入れちゃっても困らないくらい、コンピューティング・リソースとアプリケーションは密なものだった気がします.

もちろん Docker 社によってモデル化された “Build, Ship, Run” に乗っかってコンテナを使うようになったことで CI/CD は間違いなく今までよりも簡単かつ美しくなったし、開発環境で動くものはそのままプロダクション環境で動くという夢のような話も実現容易性が高まりました. また、コンテナによってもたらされるいい感じのプロセス・アイソレーションはクラスター内に配置された仮想マシンのリソースを最大限使い切るような構成を目指しやすくしました.

しかし、プロセスのアイソレーションに代表されるコンテナのメリットをより活かす構成を追求していくと、VM の中でなんのアプリケーションが動いているのかは分からなくならざるを得ないし、それにより特にセキュリティ・グループや NACL といったエンティティの複雑さが増していきます. (もしくは妥協してものすごく粗々な設定になります)

最近のコンテナ技術について「コンテナ型仮想化」という表現を使うシーンが時折ありますが、特にネットワークのレイヤーにおける EC2 という仮想化レイヤーの上にコンテナの仮想化レイヤーが重なり、もうやめてこれ以上設計が複雑になっちゃうと脳みそ死んじゃう、という状況になりつつありました.

ここまで読むと、「あぁ awsvpc ネットワーク・モード³の話ね. AWS Fargate 関係ないじゃん.」となります. (その通りです. 一番デカイのは awsvpc ネットワーク・モードの話です)

しかし、単に awsvpc ネットワーク・モードを EC2 インスタンスで構成されたクラスター内で併用してもネットワーク設計の二重性を完全に解消することはできないどころか、より複雑になります(と思っています. もし自分が勘違いしてたらぜひ指摘して欲しいです). 設計者の意識の中で、複数種類のネットワークとそれらの相互関係がデザインされている必要があるからです.

そこで awsvpc ネットワーク・モードの利用を強制する仕様である AWS Fargate です. 明示的にプロビジョニングされた EC2 インスタンスが存在しない「ピュア Fargate」なクラスターでワークロードを構成すれば、コンテナのメリットを最大限享受しながらも EC2 インスタンスのネットワークだけを考えていればよかったようなそんな牧歌的な時代に戻れる可能性が高いし、戻りたいです. なんか戻れそうな気がしてます.

また、awsvpc ネットワーク・モードでサービス(タスク)に対してセキュリティ・グループが付与できるというのもこの幸せな妄想に一役買っていて、これによりサービス間通信の可否をある程度安全にコントロールするようなことも簡単にやれちゃうじゃないかという気持ちになります.

また、re:Invent 2017 のセッションで発表されていた Amazon ECS ネイティブで Route 53 の Auto Naming API を使ってサービス・ディスカバリーをサポートする⁴という話もこの辺の妄想にさらに拍車を掛けてワクワクします.

(この辺り、昨今のサービス・メッシュみたいな文脈に合わせて今後もっと機能追加されてかないかなーとか思ってるんですが妄想し過ぎでしょうか)

というわけで、突然ですが僕が今一番欲しい機能は Reserved/Spot Instances ならぬ Reserved/Spot Compute Resources みたいなやつです.

余談

AWS Lambda は内部的に Lambda コンテナを走らせるための VM プールがあって、定期的にそのプールから VM を外してパッチ適用などを済ませ、あらためてプールに戻す、という実装によって VM のメンテナンスを行なっているらしいです. これによりユーザーがマシンのレイヤーを気にしなくてすむようになっているということですね. 便利です.

AWS Fargate もユーザーから VM が見えないようになっているので AWS 内部でパッチ適用するような実装が必要になるはずですが、Lambda と違ってロング・ランニングなコンテナを走らせることができる Fargate では容易に VM の入れ替えができない気がします.

ということはアレでしょうか. EC2 で長いこと同じインスタンスが走っていると(運が悪いと起動したばっかりのインスタンスでも)再起動や退役のお知らせメールが届くことがあるように、Fargate のコンテナもある日突然再起動イベントの対象になったりするんでしょうか. コンテナを動かすときに指定してる Platform version ってやつが deprecated になったりするんですかね.

気になります.

そして最近に限った話ではないんですが、ここのところリリースされてくる VPC, EC2, コンテナまわりの機能を見るたびに「あーすごいなーよく出来てるなーよく考えられてるなーこれまでの機能ともちゃんと連携する機能設計だなーすごいなー」と素人のように感心しています.