こんにちは。前回に続き、今回はEKS on Fargateの活用事例について、お届けします！

EKS on Fargateの活用事例

オンデマンドでのマシンリソースの確保というFargateの特性を生かして、「オンデマンドでスケーリングするJenkinsによるCI/CDパイプライン」という構成を実現することも可能です。

JenkinsによるDevOpsを実現する時、「開発者は活動時間帯が日によって偏りがあり、特にリリースの前にはCI/CDが頻繁に走り、無駄にハイスペックなマシンを用意する必要がある」という課題は特に生まれがちですが、JenkinsのビルドパイプラインをFargateに乗せることで、SaaSのCI/CDサービスように利用状況に応じて効率的にリソースを使えるようになります。

Jenkinsはステートフルなアプリケーションなので以前までのEFSをアタッチできないFargateではこの構成が取れませんでしたが、昨年のアップデートによりこのような構成を行うことが可能となりました。
詳しい構成や構築方法等はAWSのブログで解説されているので、詳しく知りたい方はこちらもご覧下さい。

まだまだ続くFargateのアップデート

EKS on Fargateを取り巻く状況は日々アップデートされており、AWSのオフィシャルイベント等で言及のあった（提供の可能性が高い）ものをいくつかピックアップしてみます。

  • AWS Distro for OpenTelemetry

Fargateだけに限ったモノでは無いのですが、OpenTelemetryと呼ばれるクラウド向けのメトリクス収集のためのアプリケーションのAWS組み込みの開発が進んでおり（現在はパブリックベータ）、将来的にはFargateのメトリクスに関しても詳細にCloudWatch等に送る仕組みが整備されそうです。

  • Podへのセキュリティグループのアタッチ

デメリットでも紹介した通りEKS on Fargateの場合セキュリティグループの設定に難がある状態ですが、こちらも解消される見込みのようです。

  • ローカルボリュームの20GB制限の拡張

Fargateの現行のプラットフォームバージョン(1.4)ではデフォルトで20GBのエフェメラルボリュームがアタッチされるのですが、Fargateはデータ分析のETL処理等、ローカルに大量のデータを持つようなワークロードには対応しきれていません。

この問題に対しても、今後テラバイト級のストレージを持てるようになる「予定」だという話があります。

まとめ

Fargateは利用者のニーズに対してオンデマンドでマシンリソースを提供するための仕組みです。

「Fargateでなければサービスが提供できない」事は無いので技術的・運用的な課題に当たらない限りは積極的にFargateを検討する機会も少ないと思いますが、最近になってデメリットも少なくなった所でリソース最適化による運用的・金銭的なメリットを狙うことが出来る状況になりつつあります。

「ノードのリソースを食いつぶす凶悪なPodがある」等、リソースの使い方を詰めきれていない場合はこの機会にFargate導入のチャレンジに関して検討してみるのはいかがでしょうか。

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