ゆるふわ系SRE・小林未来氏
小林未来氏：それでは続いて、株式会社ZOZOから私、小林が「WEARのEKSコストを救いたい」という内容で発表いたします。よろしくお願いします。
まず私が誰なのかをお話しします。私は株式会社ZOZOから参りました、ブランドソリューション開発本部 バックエンド部 SREブロックの小林未来と申します。「ゆるふわ系SRE」と勝手に名乗っていて、Twitterも「@mirai_kobaaaaaa」という名前でやっているので、ぜひフォローしてもらえればうれしいなと思います。
私が好きなサービスは、AWS CDKという、プログラミング言語を用いてインフラを定義できるツールです。
今、所属のお話をしたのですが「結局あなたは誰なの？」というのがよくわからない部分なので、そのあたりも先にお話しできればなと思います。
（スライドを示して）私たちZOZOは「世界中をカッコよく、世界中に笑顔を。」という企業理念のもと、日々活動しています。
主なプロダクトは「ZOZOTOWN」で、ファッションECです。1,500以上のショップ、8,500以上のブランドの取り扱いがあります。
最近はコスメ専門モールの「ZOZOCOSME」や、靴の専門モールの「ZOZOSHOES」などを展開しているほか、即日配送サービスやギフトラッピングサービス、ツケ払いなどもあるので、ぜひご活用いただければと思っています。
私は「『WEAR』から来た」という話をしているので、WEARの紹介も少しいたします。WEARはファッションコーディネートアプリとして展開していて、今は1,600万ダウンロードいただいています。コーディネート自体は1,300万件ぐらいです。これは2022年12月時点のデータなので、今はもう少し増えているかなと思います。
ピックアップタグから最新のトレンドをチェックして、他の方がどんなコーディネートで着ているかを見ながら、着用アイテムを公式サイトで購入して自身もそのお洋服を着てみることもできます。今回はこのWEARについてのお話をいたします。
（スライドを示して）本日お話しすることは、WEARにおけるEKSコスト最適化に向けた打ち手です。なぜ最適化が必要なのか。調査した結果、何が課題だったのか。現状の取り組みと今後の打ち手。こちらについて話します。一方、本日お話ししないことですが、EKS（Amazon Elastic Kubernetes Service）の細かな仕様部分やKubernetes自体の概要、詳細など。また、WEARの内部アプリケーションの話は今回割愛します。
EKSコストが約10倍になってしまった
では前置きが長くなりましたが、さっそく本題に入っていきたいと思います。あれは2022年某日。といってももうこの図で月がわかってしまうのですが、私たちWEARのSREは、EKSコストが増加していることを検知しました。増加をすることはある意味想定範囲内という背景があって、どういうことかというと、当時ECS（Elastic Container Service）環境で動いていた各種APIをEKSへリプレイスするプロジェクトが進行していました。
テストや切り替えで、EKSコストが上がるのはまず確実ですし、それが多少上がる分には想定範囲内だろうと、最初私たちは「これはOK」だと判断をしていました。ですが、翌月に、これはもうビックリなんですが、2ヶ月前と比べて約10倍のコストに到達していました。10倍です。これは明らかに異常値だろうと私たちは考えて、さっそく調査を開始しました。
バッチ処理ワークフローを実行するクラスタのコストが急増していた
（スライドを示して）調査の内容よりも調査結果を話してしまいますが、バッチ処理ワークフローを実行するクラスタのコストが急増していました。少し補足をすると、私たちWEARの中では、サービスのAPIを実行するクラスタや、このようにバッチ処理のワークフローを実行するクラスタが動いています。今回課題になるのが、バッチ処理ワークフローを実行するクラスタ側ですね。
こちらの構成を少し補足しておくと、Fargateのみですべて構成されています。1日で2,400podぐらいが実行されています。図でわかるとおり、クラスタの中にメチャクチャいっぱいのFargateが動いているイメージです。この中で何が課題だったのかというと、Fargateの使用量が増加してコストが嵩んでいました。このFargateの増加によって、かなりコストが増えて、先ほどの10倍という数字になっていたというのが背景でした。
EKSコストの考え方
このコストの計算について少し補足したいと思います。（スライドを示して）EKSコストの考え方ですが、まずEKSクラスタ自体のコストが定額でかかります。加えてEKSクラスタの中で実行したKubernetes Worker Nodeの実行環境のコストが発生します。
この図で見てわかるとおり、EKSクラスタのコスト＋AWS Fargateや、Amazon EC2のコストがかかるということですね。これだけではちょっとふわっとしてしまうので、もう少し掘り下げていきます。
Worker Nodeのコスト・Fargateの場合
（スライドを示して）では、Worker NodeのコストをFargateで考えてみたいと思います。これは実行されるFargateのスペックによって算出します。Image Pull時間からPodが終了するまでに使用されたリソースで計算します。1時間当たりのvCPU単位×1時間当たりのGBメモリ単位×Pod数、これだけじゃわかりにくいですよね。僕もわかりにくいです。なのでもう少し話します。
（スライドを示して）計算式を入れることでよりわかりにくくなった可能性があるのですが、少しお話しします。例えば、2台のEKS Podを30日フル稼働させた場合ですね。30日を24時間で、Podのスペックは1vCPU 2GBのメモリとします。例えば上の部分のvCPU料金＝（Pod数）×（vCPU数）×（CPU時間）当たり……と話すと長いので、こちらは少し見てもらえればと思います。
実際に計算すると下側の青の部分ですね。今回の例題であれば、これは東京リージョンの料金です。vCPU料金＝2×1×約0.05USドル×24時間×30日で72.81USD。メモリ料金も同様に計算して、15.93USDです。この例題で計算すると、合計のFargateのコンピューティングの月額料金は88.74USDと計算できます。
こちらは2023年2月10日時点の東京リージョンの料金で計算しているので、また時間が経つと違う金額が出る可能性があります。
Worker Nodeのコスト・EC2の場合
続いてEC2の場合ですね。（スライドを示して）EC2はWorker Node実行のために使用したAWSリソースで算出します。「どういうことやねん」って思うと思います。私もそう思いました。これは後ほど少し話しますが、Managed Node Groupというものがあって、それを利用した場合もコストの算出方法は同じです。
では具体的にどういうことかというと、EC2インスタンスコスト×EBSボリューム×インスタンス数ですね。これも計算式をお話しすると少し長いので割愛して、青の部分を見てください。今回は先ほどと同じように2台のEKS Podを30日フル稼働で、Podのスペックは1vCPU 2GBメモリとしているので、そちらを基に計算します。
それで青の部分ですね。EC2の場合はそのPodが配置される合計数を計算しなければならないので、2vCPUと4GBメモリのインスタンスが必要になります。これを例えばc5.largeで切って、かつSSDを汎用SSDのgp2、20GBで計算した場合ですね。計算式を話すとかなり長くなってしまうので、結論だけ言います。79.42USDです。
先ほどのFargateの計算を思い出してもらえばといいかと思いますが、Fargateとの金額の差はだいたい10パーセントですね。ただこちらはいろいろな工夫によってまた上下することもできます。
ここで注意点です。よくFargate VS EC2など、いろいろな話が出ると思いますが、FargateとEC2の単純比較は難しいものになっていて、Fargateを実行することによってEC2インスタンス自体の運用のコストが下げるのは実際問題あります。そのあたりは利用する時にどういったリソースが自社の環境に合っているのかを考えながら選定するのが良いかと思います。
（次回へつづく）
