スタディサプリ Product Team Blog

株式会社リクルートが開発するスタディサプリのプロダクトチームのブログです

【 RECRUIT Job for Student 2022 Autumn】Kubecostの検証をしてみました

Engineering SRE

EKS上でKubecostの検証

初めまして、今回 RECRUIT Job for Student 2022 Autumn Engineer に参加させていただいていた@masaki12-sです。 私は本アルバイトでスタディサプリ小中高のSREチームに配属され、Kubecostと呼ばれるツールの調査を行いました。本記事ではEKS上でのKubecostの導入から調査の結果を軽くまとめています。

本記事での貢献

  • EKS上へのKubecostの導入方法（Cost&Usage Report統合は未完了）
  • Kubecostの概要や詳細についての説明

調査のきっかけ

スタディサプリ小中高では複数のマイクロサービスで構成されていて、各チームがそれぞれマイクロサービスを開発運用しています。 開発運用をしていく中で各チームがマイクロサービスにかかるコストを把握することができれば、どの部分でコストが発生しているのかを特定しマイクロサービス運用コストの改善につなげることができます。 そのためにはKubernetesで運用しているマイクロサービスのコストをチーム単位に集計できる構造が必要になってきます。そこでKubecostと呼ばれるツールを導入することにより、マイクロサービスごとにかかるコストの監視ができるのか調査しました。

Kubecostとは

Kubecostは2019年に公開されて、Kubernetesクラスターの運用にかかるコストをアプリケーション、プロジェクト、チーム単位に集計して監視することができるツールです。 Kubecostの主な機能として公式が提唱しているのが以下の4つです。

  • コストの割り当て（Cost Allocation）
    • Deployment、Service、Namespace等Kubernetesのリソースごとにコストを分類
  • 総合的なコスト監視（Unified cost monitoring）
  • 最適化（Optimization Insights）
    • コストとパフォーマンスを考え、節約すべき箇所を提示
  • アラートとガバナンス（Alerts & Governance）
    • リアルタイムのアラートと定期的なレポートの発行でチームのインフラ制御に貢献

KubecostはKubernetesのクラスターからリアルタイムデータを収集して分析し、詳細なコストの内訳を正確に把握できます。 またKubecostはGCP、AWS、Azure等のクラウドサービスとも統合することができ、各クラウドサービスで使用しているアーキテクチャごとのコストを算出できます。 今回の調査ではAWSを使用していますが、AWSとKubecostは2022年8月に共同でコスト監視ツールを発表しました。そのためEKS上へのKubecostの導入やKubecostとAWSとの統合を楽に行うことができます。またKubecostを運用していく上でAWS側のサポートを受けることができます。

調査内容

今回の調査内容は以下の通りです。

  • Kubecostの仕組み
  • Kubecost運用にかかるコスト

本記事では上記の3点について調査できなかったことを含め記述します。

Kubecostの導入

調査の前にKubecostの導入手順を示します。KubecostをEKSのクラスター上にデプロイするためには、いくつか方法があります。 今回はAWS EKSのノード上にKubecostを導入するため、AWSのコストモニタリングの公式ページと同様の手順で進めていきます。

各種バージョン

Kubecostのインストール

  1. Amazon EBS CSIドライバーをクラスターにインストール
  2. helmを使用してKubecostをインストール
helm upgrade -i kubecost oci://public.ecr.aws/kubecost/cost-analyzer --version 1.96.0 \
    --namespace kubecost --create-namespace \
    -f https://raw.githubusercontent.com/kubecost/cost-analyzer-helm-chart/develop/cost-analyzer/values-eks-cost-monitoring.yaml
kubectl get pods -n kubecost

を実行して

  • kubecost-cost-analyzer
  • kubecost-kube-state-metrics
  • kubecost-prometheus-server

が作成されていて、STATUSがRunningになっていれば成功です。

この段階でポートフォワーディングを行うことでフロントエンドのアプリケーションを見ることが可能になります。 以下のコマンドを実行した場合、127.0.0.1:9090でアクセスすることが可能です。

kubectl port-forward --namespace kubecost deployment/kubecost-cost-analyzer 9090

アクセスするとこんな感じのページが表示されます。

Kubecostでは以下のようにnodeやpod,name等の単位で各コストを監視することが可能です。またKubecost自体のコストも監視することが可能です。

またAWSのMarketplaceからデプロイすることも可能です。 細かい設定を調整したい場合は、helmを利用してカスタマイズすることも可能です。

しかしこの段階ではAWSでの正確なコストを可視化できているわけではありません。理由としてはAWSの詳細なデータを取り込んでいないためです。後述しますがKubecostではAWSの公開価格データとCost&Usage Report Data（以下CUR）を使用してコストを計算しています。しかしこの段階ではAWSの公開価格データのみを参照しています。 CURを参照するにはCUR統合を行う必要があります。 後述しますが、今回の調査ではCUR統合がうまくいかなかった部分があるため手順は割愛しますが、公式が示している手順はこちらを参考にしてください。 CUR統合を行うことでEC2やECSなどのAWSの各アーキテクチャごとにかかる料金も監視することが可能です。詳しくはこのページを参照してください。

他にできること

今回実践していない内容もありますが、Kubecostを使用してできることを示します。

  • 複数クラスターの監視 今回は単一クラスターをコスト監視の対象としていましたが、複数のクラスターでのコスト監視も可能です。
  • APIの使用 KubecostはAPIが提供されており、各APIを介してコストデータを含んだjsonデータを取得することが可能です。

Kubecostのしくみ

Kubecostのアーキテクチャは以下のような図になります。

(参考: https://docs.kubecost.com/install-and-configure/install/provider-installations/aws-eks-cost-monitoring)

Kubecostには各リソースのコストを表示するためのFrontendとコストを算出するためのCost modelがあります。 ここでAWSの公開価格データとCURを用いてリソースのコストを算出します。細かいコストの算出はこちらに記載されているようです。 ここで計算されたデータはKubecostを導入する際に追加されるPrometheus上に蓄積されます。

またCUR統合を行う上で

の3つのサービスが使用されます。基本的にはCloudFormationでIaC化されていますが、CURをクエリするためのAthena、Athenaのクエリ結果やCURを保存するためにS3が必要になります。

Kubecost運用にかかるコスト

Kubecostを実際に運用する上ではKubecostの運用コストを把握する必要があります。Kubecostはクラスターのコストを細かい単位で集計可能であり、コストの発生箇所を特定し運用コストの改善につなげることが可能です。 一方でKubecost運用にもコストは発生するので導入の価値があるかを検討する必要があります。ここではKubecostを運用するにあたってコストが発生する可能性がある箇所を示しています。

Kubecostのプラン

KubecostにはFree Plan、Business Plan、Enterprise Planの3つのプランがあります。各プランの詳細はこちらにあるので、必要に応じて選択しましょう。 なおFree Planでは15日分のコストデータのみWeb上で確認できます。それ以前のデータは残り続けますが、Web上からは確認することができません。

必要なスペック

こちらも公式ドキュメント通りですが、Kubecostを配置するnodeは以下のスペックが必要になります。 監視対象の50,000ポッドごとに約2つのCPUと10GBのRAMが必要

backing Prometheusデータベースには 1分間に取り込まれる100万メトリクスあたり約2CPUと25GBが必要

ディスク容量

Kubecostは計算するために必要なコストデータおよび計算結果を蓄積しています。それらは監視する対象の数や稼動時間により変動します。公式ドキュメントでは以下のような計算式が挙げられています。 $$needed_disk_space = retention_time_minutes * ingested_samples_per_minutes * bytes_per_sample$$ 15日で300podsを監視するなら32GBあれば良いと述べられており、その例から概算すれば良いと考えられます。

残った課題

個人的には残念ですが、今回の調査では主にドキュメントを調査といった内容が大半を占めていたこともあったので、検証できなかった部分もあります。ここでは今後導入にあたって必要だろうと考えられる課題を示しておきます。

CUR統合においてうまくAthenaのクエリ結果が返ってこない

今回CUR統合がうまくいかなかったのはこれが理由であると考えています。 KubecostとAWSのCURを統合した際のフローとしては、

  1. AWS側がCURを数時間に1回発行してS3バケットに保存
  2. AthenaでS3バケットに保存されたCURをクエリする
  3. クエリ結果を元にコストを計算する

といった流れになります。 S3バケットへのCURの吐き出しやCloudFormationによるリソースの作成は成功していました。しかし今回の検証では以下のようにCUR統合の一部の処理が適切に動作していないようでした。

原因調査の結果AWS AthenaからCURの保存されているS3バケットに対してうまくクエリを行えていないことが考えられました。クエリ自体は成功しており、結果が0件となっているためテーブルやカラムの指定ミスではないと考えられます。

開発・本番環境への導入

Kubecostのドキュメントではある程度必要と考えられるノードのスペックや容量の計算式が示されていますが、公式でも1週間ほど実環境での運用を推奨しています。そのため実際に運用されている環境に導入して正常に動作しているか、維持コストはどのくらいであるかを確認する必要があります。

おわりに

最後になりますが、今回のアルバイトを始める前はKubecostどころかKubernetesについての知識も0の状態でした。この1ヶ月という短いアルバイト期間の中でKubernetesの知見を広めたり、Kubecostの調査がここまで進められたのは担当していただいたメンターの方のおかげです。 やりたいこと全てを調査仕切れたわけではないので悔しい部分はありますが、技術の調査はSREという職種においては重要な任務であると考えています。今回の経験は大変ではありましたが、今後SREという道を歩んでいく上での貴重な経験であることは間違いないと思っています。 仕事内容だけでなくオフィス内の雰囲気や働き方など業界や職種に対する認識も増えたので、アルバイトを通してリクルートが好きになりました。今回僕自身を受け入れていただき、貴重な経験をさせていただいた株式会社リクルート様やアルバイトメンバーである自分を普段の業務メンバーと同じ形で受け入れていただいたスタディサプリのSREの方々、今回の取り組みやそれ以外の悩み等の相談も行っていただいた担当のメンターには感謝しても仕切れないです。本当にありがとうございました。