3つの打ち手とは？
小林未来氏（以下、小林）：コストの話がちょっと長くなってしまったんですけど、打ち手についてお話しします。（スライドを示して）打ち手は大きく分けて3種類のカテゴリを用意しました。Fargate spec自体のoptimize、Fargateの実行時間の削減、EKS on EC2へ移行です。
1つ目のoptimizeの部分であれば、まず実際のメトリクスからFargate Podの実行specを調整していきます。
それで実行時間の削減であれば、不要なFargate Podの自動削除やImage Pull速度の改善。最後の移行の部分はEKS on EC2へ移行することによるコスト圧縮。先ほどのAutifyさんとアプローチが似ていますね。
打ち手その1 Fargate specのoptimize
（スライドを示して）まずはspecのoptimizeですが、私たちは監視ツールとしてDatadogを利用しています。Datadogダッシュボードからpodの利用メトリクスをチェックして、その中の内部で動いているコンテナがどれぐらいのCPUを必要としているのか、メモリを必要としているのかをすべて算出して、そちらをManifestで修正していきました。
こちらは複数のデプロイメントが動いていたので、そのすべてに対して調整をかけていくという、非常に地味ですが重要なアプローチを取りました。
打ち手その2 Fargate実行時間の削減
（スライドを示して）続いてFargate実行時間の削減です。こちらは2つあります。1つ目のFargate実行時間の削減ですが、稀にワークフローの実行完了後に削除されないFargate Podが存在していました。その場合どうなるかというと、もうFargate Podは動いてはいないけれどもAWS上ではReadyになっている。つまり課金されてしまう状態でした。
なので、ここをコントロールするためにワークフロー実行完了後にFargate Podが削除されるまでの時間を宣言的に設定しました。これはどうやったかというと、jobに対してttlSecondsAfterFinishedというフラグを追加して、この例であれば、jobが完了してから30秒後にPodがきれいに削除されるようにするという設定を入れ込んでいます。
もう1つですね。私たちは最終的に実施しなかったのですが、Image圧縮アルゴリズム変更によるImage Pull時間の削減というアプローチも検証していました。冒頭のコストの考え方のところで話したと思いますが、Fargateの課金は、実はPodであったりタスクが立ち上がってから課金されるのではなく、ImageのPullを開始した時点から発生します。
なので、Image自体をより小さなサイズにすることによって結果的に全体のFargateの実行時間が削減されて、コストが削減できるのではと考えました。gzipの圧縮方式からzstdの圧縮方式に変更することでImageサイズを圧縮できないかと検証しましたが、採用しませんでした。
WEARでこの圧縮をしたところ、5パーセント程度Image圧縮に成功したのですが、実際のPull時間への影響は1秒、2秒の世界だったので、これはいったん後回しにしようということで最終的に採択には至りませんでした。（スライドを示して）ただ非常におもしろいアプローチなので、現在Imageのサイズにお困りの方がいらっしゃいましたら、このAWS公式のブログを見てちょっとチェックしてみると良いのかなと思っています。
打ち手その3 EKS on FargateからEKS on EC2への移行
（スライドを示して）そして最後の打ち手ですね。EKS on FargateからEKS on EC2への移行です。こちらは、現在検証中の話になるので最終的な着地は変わる可能性がありますが、おおよそこのような流れで動いています。Pod実行環境をEC2に変更することで、さらなるコスト圧縮を図るということですね。動いていたFargateをすべてEC2に載せ替えて、コストの圧縮を図ります。
冒頭で述べたとおり「運用コストがかかるんじゃないの？」という話があると思いますが、こちらはEC2 Managed Node Groupという機能があるので、それを利用して運用コストを抑えます。実際に別のクラスタでEC2 Managed Node Groupをすでに活用しており、そこで運用のコストもスルーできる範囲だと判断したので、採用しました。
この時のさらなる工夫として、単純なEKS on EC2への移行ではなく、Podの性質ごとに配置するノードを調整するアプローチを取っています。（スライドを示して）こちらですね。下に大きく分けてEC2 Common GroupとEC2 Critical Groupがあります。こちらは例題ですが、実行環境に高いインスタンス性能が不要なPod、オペレーター、比較的低いスペックでも動くものですね。
そのあたりはT系のインスタンスを利用してコストを圧縮したり、Criticalは実行環境に高いインスタンス性能や安定性が必要な、例えばバッチ処理のワークフローの中でデータを処理するものや、大量のデータを引っ張ってくるものにはC系やM系などのインスタンスを採用して、Podの性質ごとに利用するインスタンスを変更することでコストの圧縮を図ろうとしています。
（スライドを示して）ではどうやってやるのか。ManifestにNode Affinityを追加して、宣言的にノードを選択します。この例であれば、NodeGroupName、criticalというタグを付与して、そちらからPodが選択できるようにしています。
結果的にどうなるのか。（スライドを示して）このようにデプロイメントのCriticalがEC2 Critical Groupに配置されて、Deployment CommonはEC2 Common Groupに配置されることが可能になりました。
ピーク時の50パーセント程度までコスト削減ができた
最後にまとめです。今回はWEARにおけるEKSコスト削減にまつわるあれこれを紹介しました。進行中ですが、現時点でピーク時の50パーセント程度までEKS単体ではコスト削減ができています。
いろいろと今回EKSのことをお話ししましたが、コスト削減で大事なのは3点だと思っています。1つ目はコストをWatchすること。続いてサービスのリソースを観測し続けること。そして、現状に合わせた最適化を続けていくこと。この3つだと思います。今日最適だと思ったことが、明日にはもうズレている、ということが多々ある業界だと思うので、これについては私たちも心がけつつ日々最適化していければと思っています。
俺たちの戦いはこれからだ！ ということで最後のおまけです。私たちZOZOは「世界中をカッコよく、世界中に笑顔を。」という企業理念のもと一緒に働いてくれるメンバーを募集しています。ぜひご応募くださいませ。ご清聴ありがとうございました。
データの転送費用は比べているのか？
司会者：ありがとうございました。少し質問が来ているので、紹介していきたいと思います。1つ目です。「Fargateだと毎回Image Pullしますが、EC2だとローカルにImageキャッシュが残るため、AWSのTransfer feeも多少減りそうな印象があります。before/afterでデータの転送費用は比べられていますか？」という質問があります。
小林：すばらしい質問ですね。そうですね。データの転送費用はそこまで意識はしていなかったのですが、現在まさに測定している段階です。なので、もし今後発信できることがあればお伝えできればと思っています。
司会者：ありがとうございます。
EKS on EC2のスケール速度に課題はあるのか？
司会者：続いての質問です。「EKS on EC2はスケール速度に課題があったりするのでしょうか？ 必要なら余剰ノードを構成することも考えられますか？」ということです。
小林：そうですね。実は私たちも検証の時に「（スケールの速度は）課題になるのではないか？」と考えました。現状の構成では、クラスターオートスケーラーを利用してEC2をスケールさせていますが、Fargateと実測で比べたところ、そこまで大きな差はなかったという結論が出て、問題ないだろうと考えています。
さらにEC2に移行することによって、やはりコンテナキャッシュが効くようになり、以降も同じEC2インスタンスで起動するImageのPodについては非常に高速になるので、その恩恵が受けられるのではないかと考えています。
司会者：なるほど。ありがとうございます。どんどん紹介していこうと思います。「10倍コストは問題にはならなかったですか？」というのが来ています。
小林：問題になりました（笑）。
司会者：そうですよね（笑）。
小林：問題になってこうなっています（笑）。
司会者：（笑）。ありがとうございます。
コストの監視方法や頻度について
司会者：続いてです。「コストのwatch方法や頻度を教えてください」。
小林：コストのwatch方法や頻度は、基本的にはAWSのCost Explorerを見るのが私たちの運用になっています。基本的にまず心がけることとして、デイリーのコストをウォッチするのが各自のやるべきことで、ただそれではできない可能性もあるので、必ず週次のチーム内の定例でコストをチェックしてどんな差分が出ているのかをチェックするようにしています。
司会者：なるほど。ありがとうございます。続いてです。「現状でもEKS移行前コストの数倍だと推察いたしますが、それでも現構成を採用し続けるのは運用面などのメリットがあるからでしょうか？」。
小林：ありがとうございます。EKS移行前のコストの数倍……。そうですね。ただこの「数倍」は、おそらく先ほどのグラフを見られてだと思うのですが、実はEKSのクラスタの中で動いているサービスがどんどん増えていっているんですね。なので、ある程度低い数値から倍になるのは仕方のない部分なんですね。
今回のご質問の意図は、ECSからEKSに移行することによって、数倍になったのではないか？ なのかなと思っているのですが、そこについてはコストには大きく変わりはなく運用できています。
司会者：なるほど。サービスが増えているので多くなっているように見えるというイメージでしょうか？
小林：はい、おっしゃるとおりです。
司会者：ありがとうございます。
コスト観点で将来的に構成を変える可能性もある
司会者「Transfer feeがどの程度だったか教えていただけますか？」という質問は、私は意図が読み取れないんですが……。
小林：これはData Transferの量ですかね？ Transfer feeですかね？ こちらについては現在確実な数字を言い切れないお恥ずかしいところではあるのですが、確認の上、別途ご回答できる場があれば回答させてもらえればと思います。
司会者：ありがとうございます。続いて、「コスト観点で将来的にここから構成を変える可能性はありますか？」
小林：もちろんあります。今はEKSにおいてFargate Spotが対応していないという認識ですが、今後対応した場合はもしかしたらまたFargateに戻す可能性もありますし、現在Managed Node Groupで運用しているものをさらにスケーリングの速度や、インスタンスの最適化を行うためにKarpenterを採用して実施することも考えています。
なので、その打ち手については、これもどこかで発信できればいいなと思っています。ありがとうございます。
司会者：ありがとうございました。それではいい時間になりましたので、ここで質疑応答を終了したいと思います。
