EKS on Fargateの特徴、通常のEKSとの違いは何か？（第1回）

みなさん、こんにちは。コンテナ化を用いたシステムの導入が進んできた昨今、ECSやEKSにおいてFargateを本番環境で導入してみた……といった話を目にする機会も増えてきました。

今回はそんな「無くてもいいけど有るととても便利」なEKS on Fargateに関して特徴からメリット／デメリット、今後のFargateの動向に関してご紹介したいと思います。

基本的なおさらい

AWSでDockerコンテナを構成する（コンテナオーケストレーション）ためのサービスはElastic Kubernetes ServiceとElastic Container Serviceの2つがあり、共にデータプレーンとしてEC2とFargateを利用することが出来ます。

今回の記事では、EKSを使う時にデータプレーンとしてAWS上でEC2とFargateを任意に選べる時、それぞれどのようなメリット・デメリットがあり、技術選定においてどちらを選ぶべきかという点に絞ってご紹介できればと思います。

Fargateの特性

AWS Fargateはコンテナを実行する時にホストマシンとなるEC2のスペックを意識する事なく設計が行えるようにするためのサービスです。

例えばEKSのデータプレーンをEC2にする場合、マネージドかセルフマネージドかによらず、EC2としてインスタンスを管理しながら、そのリソースに収まる様に各ポッド(Pod)を管理する立ち上げる等の構成上の工夫が生じますが、FargateでPodを構成する場合、ノード(Node)のレイヤの管理が不要になり、Kubernetesの管理上はNodeとPodが1:1で紐付いた状態になります。

EKS on Fargate と EKS on EC2の構成の違い

上記特性を踏まえると上図の様になり、EKSというプラットフォームから見た構成としてはEC2のレイヤーが無くなる分、可視性という観点ではノードグループの相互な依存関係を除外して設計を行うことができます。

Kubernetesとして「1Node1Pod」で構成される事が、構成上の違いとなってきます。

Fargateは物凄い勢いでアップデートされている？

Fargateを用いたEKSの構成を検討する時、「1ヶ月前の情報がアテにならない」事はザラにあります。

例えば中級者向けのAWS Black Beltセミナーでの資料からも分かる通り、コンテナ関連のアップデートは把握しきれない量のボリュームがあり、「出来ないと思っていたけど実は先日アップデートにより出来るようになっていた」といったケースに度々遭遇します。

ここで挙げる「EKS on Fargateを用いた時の違い・メリット・デメリット」に関しても例にもれず情報がすぐに古くなるはずなので、情報の取捨選択と適切なタイミングでのキャッチアップがFargateと付き合う上ではとても重要になります。

運用上のメリット

Nodeの影響を考慮する必要なく、Podごとにリソースの設定を行うことができる

Vertical Pod AutoscalerやHorizontal Pod Autoscaler（Podの自動スケーリング）を利用する時、EC2をデータプレーンに利用している時であればノード（EC2インスタンス）の持てるプライベートIPの数や、ノードのリソースを意識しながらスケーリングの構成を組む必要がありますが、Fargateは1Pod1Nodeの構成を取っている都合上、他に立ち上がっているPodのリソース消費量を気にする必要なくスケーリングの設計を行うことが出来ます。

マネージド型ノードグループであっても、EC2のインスタンスがスケーリングする時に余分なリソースを確保してしまうため、高頻度で大量のリソースを要求するPodがスケーリングする場合、Fargateの良さが活かせる場合が多いです。

特定の時間帯にバーストさせたい場合等に対して、オンデマンドでリソースの確保が行える

どうしてもバッチをKubernetesのインフラに乗せたい場合や、特定時期にサービスの負荷が上がるようなケースではEC2のノードのスケーリング設定を組むこと無く、Fargateのデプロイ単体でスケーリングを作り込む事ができます。

EKS on Fargateに向けた機能がアップデートされていて、デメリットが解消されつつある

EKS on Fargate機能がリリースされたのは2019年末ですが、出た当初はDaemonSetやNLBが未サポートで、ログ収集やネットワーキングに関してある程度の制約があった時期もありました。
最近では2020年8月にSaving Plansの適用やEFS／NLBのサポート、2020年12月にFargateのfluent bit対応と、抱えていた課題に対して徐々にアップデートが行われており、最近の動向を見る限りでは引き続き機能ベースのアップデートが行われそうなので続々と利便性が向上してゆくことは間違いないと思われます。デメリットが少ないこともメリットです。

運用上のデメリット

とはいえ、通常と異なる構成を取る都合上、実現できない課題というのも現時点では多く存在します。

インスタンスタイプは指定できない

GPUやGravitonを利用したい場合はEC2を利用する必要があります。

Nodeに直接SSHできない

Podの吐くログ以外に障害の調査等でコンテナの状況を確認するためにノードにSSHするといった運用対応のシチュエーションは数多くありますが、Fargateを利用している場合はNodeにSSHする事ができず、「コンテナになにか問題があるようだけれど、docker execコマンドを打てなくて思うようにデバッグが出来なくて辛い……」といった状況に当たるリスクがあります。

SecurityGroupPolicyの未サポート

EKSではPod単位でセキュリティグループの設定が行えるSecurityGroupPolicyという項目が利用できますが、Fargateではまだ未サポートです。セキュリティグループの運用方法によっては、少し大雑把な設定が必要になるかもしれません。

PodにパブリックIPはアタッチされない

FargateによってデプロイされたPodはプライベートIPのみが割り当てられるので、ロードバランサーを省略したネットワーク構成を取るような用途には向きません。

Podの立ち上がりが遅い

Fargateはホストのリソースの確保から始まるので、Podが立ち上がるまで30秒~100秒ほど掛かる（vCPU/メモリの割当やAWSの状況によってバラつきがある）事は、急激なリソースのスパイクやアプリケーションのリリース時間に対してボトルネックになります。

いかがでしたでしょうか。EKS on Fargateの活用事例について、次回お届けします！

AWSをご利用いただくには、直接契約するより断然お得。
AWS利用料が5％割引、さらに日本円の請求書による支払いが可能です！