インフラにかかるコストを正しく「説明」するための取り組み

技術部 SRE グループの mozamimy です。

クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいます。

昨年夏に公開した記事である、インフラのコスト最適化の重要性と RI (リザーブドインスタンス) の維持管理におけるクックパッドでの取り組みでは、

• なぜインフラのコスト最適化が必要なのか、具体的にどのような考え方に沿って進めてゆけばよいのか。
• SRE が一括して管理する AWS のリソースプールそのもののコスト最適化を実践するための具体的な取り組みの一例として、RI のモニタリングや異常時の対応フローによる維持管理。

といった話題にフォーカスしました。

今回は、インフラにかかるコストを正しく「説明」するための取り組みということで、コスト最適化に貢献する社内アプリケーションである Costco (Cost Console の略です) と、その設計思想や目指すところについて解説します。多分に社内コンテキストを含むツールなので OSS とはしていませんが、読者の皆さんの組織で同様の仕組みを構成するときの役に立つことでしょう。

今回ご紹介するトピックは、ある程度のパブリッククラウド (特に AWS) の知識があれば前回の記事の予備知識がなくとも読める内容となっています。しかしながら、読者の皆さんの組織に応用することを考えると、その背景を知っておくと理解がより深まると思いますので、前回の記事の、特に前半部分を読んだ上で今回の記事を読むことをおすすめします。

以降、単にコストと表記した場合は金銭コストのことを指すこととします。

あなたのサービスのインフラコスト、妥当な金額ですか?

いきなりですが、真か偽で答えることのできる、一つの問について考えてみましょう。

「あなたが運用しているサービスにかかっているインフラのコストは妥当な金額ですか？」

この問について、それが合っているか否かはさておき、確信を持って答えられる人は少ないのではないでしょうか。もし自信を持って答えられるのであれば、あなたの組織は高いレベルでコストを管理することができているでしょう。

では、なぜこの問に対して自信を持って答えることができないのでしょうか。理由は簡単で、インフラにかかっているコストの状況を継続的に把握できていないからです。逆に言えば、かかっているコストの妥当性を評価する仕組みを用意し、定期的にふりかえる場を持つことで、この問に答えるための根拠となるのです。

インフラコストの妥当性について考える

前節で「サービスにかかっているコストは妥当かどうか」という問について考えました。そもそもクラウドの特長として「必要な分を必要なだけ利用できる」という点があげられます。つまり「必要な分を必要なだけ利用しているのだから、健全に決まっているじゃないか」と言えそうな気がします。

しかしながら当然そのようなことはなく、大なり小なりどこかにムダが発生しているのが常です。オーバープロビジョニングな EC2 や RDS インスタンスなど、クラウドを利用しているどのような組織でも探せばどこかにムダが見つかることでしょう。

オーバープロビジョニングはもっとも分かりやすい例ですが、アーキテクチャの差異による必要コストの違いを適切に評価することはもっと厄介です。AWS の場合、SQS や SNS、 EC2 といったプリミティブなものから、RDS や ElastiCache といった高レベルなミドルウェアを提供するマネージドサービスまで、多様なビルディングブロックを組み合わせてアーキテクチャを構成できます。つまり、達成したい目的を満たすアーキテクチャの可能性はいくつもあるわけです。

アーキテクチャの違いによるコスト差の一例として、ECS における ELB の利用方法があげられます。ECS を素直に利用する場合、ECS に組み込まれている ELB サポートを利用し、1 サービスに対して 1 つの ELB を紐付ける構成がもっとも素朴で一般的な構成です。ただし、無数にある社内向けアプリケーションについてはどうでしょうか? ひとつひとつに ELB を割り当てると、その積み重ねで無視できないコストになります。そこで、社内アプリケーション向けに 1 つの ELB を共有し、ECS サービスと ELB の割当部分を自前で作り込んで運用する、という構成も考えられます*1。

後者の場合では、運用・作り込みのコストを対価として、金銭的なコストを軽減しているといえます。実際、クックパッドでも社内アプリケーションについては ELB を共有する構成が標準となっています。このように、自前で作るコストと金銭コストを天秤にかけるというシチュエーションはしばしば起こり、その評価を正しく行うためにもかかっているコストを分類して正しく把握することは重要です。

「必要な分を必要なだけ」というクラウド利用料金と組織の「財布」のギャップを埋める

そして「必要な分を必要なだけ利用できる」というのは、組織の財布の仕組みとも相性があまり良くありません。クックパッドもそうですが、一般的な組織では 1 年を基本単位として予算を決定し、それに基づいて資金を使っていくことになります。クラウドの料金は、基本は使った分だけ払うという仕組みなので、ここにギャップがあります。これは社会の仕組みであり資金が有限なのは変えられないことなので、わたしたちはそのギャップと戦う必要があります。クラウドを利用する場合でも予算案を提出し、ステークホルダーに対して必要な理解を得て、責任を持ってその予算内でやりくりする必要があるのです。

どの程度予算に沿うことを強く要請されるかは、組織の持つ規模や資金状況によって様々だと思われますが、少なくとも予算の利用状況を「説明」できるようにすることはどのような組織でも共通でしょう。

説明ができれば、どこにムダがあるのかを明らかにし、必要であれば手を打つこともできます。説明ができれば、次年度の予算案も正しい根拠とともに立てて理解を得ることができます。説明ができれば、もし予算をオーバーしても正しく理由付けができます。

「説明」できるようになるために必要なこと

説明できるようになるために何が必要なのかを考え、わたしたちは以下の 2 点に行き着きました。

• コストを適切に分類し、何にどの程度コストがかかっているのかを把握できるようにする。
• 定期的 (1 ヶ月に 1 回程度のスパン) にふりかえりの場を持ち、その月と年始からのコストの様子をまとめて蓄積する。

わたしたちはソフトウェアエンジニアであり、そのスキルは問題を解決するための強力な武器となります。後ほど詳しく説明しますが、いくつかの選択肢を考えた上でコストを管理するためのコンソールアプリケーションを開発することにし、そのツールに Cost Console の略で Costco と名付けました。

Costco が持つ機能とそれにより達成できること

Costco は多分に社内コンテキストを含むツールなので、残念ながら OSS とはしていません。しかしながら、その機能一覧とそれによって達成できること、設計思想は読者のみなさんの組織で同様のアプリケーションを作る参考になるはずです。

では、百聞は一見にしかずということで、まずどのような機能を持つのか一通り説明してから、その設計思想について説明していきます。Costco の機能一覧は以下のとおりです。

• 予算と月次のふりかえりに関する機能
• Cost Explorer のフィルタとして予算を定義する機能
• 当月のコストの予算に対する進捗を一覧できる機能
• 月次でコストをレポートとしてまとめる機能
• 購入決裁に関する機能
• 年間のインフラ用の購入決裁として割り当てられた金額を設定できる機能
• 購入決裁の利用状況を確認できる機能
• コスト配分タグに関する機能
• コスト配分タグにコメントなどのメタデータをつけ、管理する機能
• コスト配分タグをカテゴライズして、まとめて扱う機能
• 特定のコスト配分タグをもつ AWS リソースを一覧できる機能
• その他コストの管理に役立つ細かい機能

Costco が扱っているデータのほとんどは Cost Explorer API から取得したデータそのものや、それらを加工したものです。API のコールには 1 リクエストあたり 0.01USD と、積み重なるとそれなりに高額になりうる料金がかかるため、バッチ処理で定期的に Costco に取り込むようにしています。

予算と月次のふりかえりに関する機能

予算を Cost Explorer のフィルタとして定義する

Costco には予算という概念があります。これは組織としての予算に対して Cost Explorer のフィルタを紐付けるものです。ここで設定した Cost Explorer のフィルタは「ある予算が何を意味しているのか」をコード (JSON) として直接説明しています。ここに日本語のような曖昧さは発生しません。さらに良いことに、このフィルタは実際に動きます。フィルタを使って Cost Explorer で簡単にコストを可視化できるのです。

たとえば、クックパッドが日本で展開しているサービスすべてをひっくるめた予算は、以下のようなフィルタで定義しています。

{
  "and": [
    {
      "dimensions": {
        "key": "REGION",
        "values": [
          "",
          "ap-northeast-1",
          "global"
        ]
      }
    },
    {
      "not": {
        "dimensions": {
          "key": "LINKED_ACCOUNT",
          "values": [
            "***************"
          ]
        }
      }
    },
    {
      "not": {
        "dimensions": {
          "key": "SERVICE",
          "values": [
            "Tax"
          ]
        }
      }
    }
  ]
}

Costco に入力された日本で展開しているサービスをひっくるめた予算

クックパッドでは、REGION の dimension が ap-northeast-1・global・No region に分類されるコストを日本国内向けサービスの費用として、それ以外を国外向けサービスの費用として扱っており、このフィルタはそれをコードとして表現しています。(諸事情によりある AWS アカウントは集計から除外しています)

予算名から分かるように、国内サービス全体の予算をさらに細かく分割し、研究開発にかかる費用や開発者が自由に利用できるサンドボックス AWS アカウントにかかる費用など、それぞれに予算を設定しています。たとえば日本の研究開発にかかる費用は以下のように定義しています。

{
  "and": [
    {
      "dimensions": {
        "key": "REGION",
        "values": [
          "ap-northeast-1"
        ]
      }
    },
    {
      "dimensions": {
        "key": "LINKED_ACCOUNT",
        "values": [
          "************"
        ]
      }
    },
    {
      "not": {
        "dimensions": {
          "key": "SERVICE",
          "values": [
            "Tax"
          ]
        }
      }
    }
  ]
}    

Costco に入力された日本の研究開発にかかる予算

アカウント ID は黒塗りにしていますが、ここには研究開発のために開発者が自由に利用できる AWS アカウントが設定されています。

Cost Explorer のフィルタと予算を紐付けて管理するというやり方は、AWS の機能の一つである AWS Budgets にインスパイアされたものです。ただし、AWS Budgets ではフィルタに not 条件を書けないというわたしたちのユースケースにおいては致命的な弱点があり、それは Costco を開発した理由の一つになっています。

定義した予算をもとに当月のコストの進捗と予測を一覧する

ここで設定した予算をもとに、以下のように当月のコストの進捗と予測を一覧できます。この予測は、Cost Explorer の GetCostForecast API で取得した値です。

当月のコストの進捗と予測を一覧する画面

大部分が黒塗りになっていて少しわかりにくいですが、左から 3 番目のカラムに各予算に対する当月のコストの着地点の予測が表示されています。予測額が予算を上回っている場合黄色⛈で表示され、収まっていれば緑☀️で表示されます。また、左から 4 番目のカラムには予算に対する今月の料金の進捗が金額と%で表示されています。

SRE グループの毎週の定例ミーティングでは、この画面を起点として、詳細は Cost Explorerを見ながらその週のコストの様子を簡単にふりかえっています。

月次レポートとしてコストを自動集計し日本語で所見をまとめる

この機能は Costco の目玉機能であり、設計思想を体現している機能の一つです。まずはその内容を見てみましょう。

Costco によって自動集計された 2020-02 の月次レポート

このようなレポートが毎月 Costco のバッチ処理によって自動的に生成されます。具体的な数字は黒塗りにしていますが、スクリーンショットは 2020-02 分の実際のレポートです。

対実績のカードでは、予算に設定された金額と実績を比べ、予算を超過しているかそうでないかを一覧することができます。

クックパッドでは、従来 EC2 について RI を購入していましたが、 RI の維持管理を楽にするために既存の RI が切れ次第、Savings Plans (Compute) に置き換えを進めています。Savings Plans (Compute) では、一定のルールにしたがってリザーブが自動的に適用されるため、結果的にどのリージョンにどの程度 Savings Plans が適用されたかは Cost Explorer API から取得したデータを使って自前で計算する必要があります。

予算定義の節で述べたように、クックパッドでは国内向けサービス (JP) と国外向けサービス (UK) にかかるコストはリージョンで区別しています。また、RI や Savings Plans といった先払いする料金については、以下の画像のようにそれを毎月均等に割って振替えるという経理処理をしています。

先払いする AWS 料金の毎月の振替の例

この割合は毎月変わりうるため、月次レポートの「Savings Plans の JP/UK 利用割合」カードに Cost Explorer から得られたデータを計算して出した割合を表示し、経理のスタッフが確認できるようになっています。

一番下のカードは担当者 (今は SRE グループのわたしが見ています) が所見を書く欄となっており、月内での社内の動きや Cost Explorer をドリルダウンして調べた結果をもとに、コストの様子についてまとめています。

この 2020-02 のレポートは特に印象的で、所見に書かれているように MediaLive の利用料金が大きく増加していることに気づくことができています。このあと開発チームに相談してコスト増加の原因の解明と修正をしたのですが、Costco によってアノマリの早期発見ができた良い例です。

実際に AWS から請求書が届いて利用料金が fix するまでは月次レポートの実績の値が変化する可能性があるため、月が変わったすぐの状態では以下のような表示にしています。請求書が届き次第、レポートの所見欄を書いて凍結ボタンを押すという運用にしています。

請求が未確定な月次レポート

また、年間を通して予算の状況を確認できる画面もあります。

年間を通した予算ごとのコスト状況を一覧できる画面

予算に関連する機能で達成できること

ここまで説明したように、Costco を使って定期的に AWS の利用状況をコスト面からふりかえることで、早い段階で異常に気づくことができる上に、毎月の利用状況をレポートという形で蓄積することができます。

定期的にレポートを蓄積しておくことで、年末の次年度の予算案の作成や購入決裁の申請など、社内での手続きを楽に進めることができます。夏休みの終盤に宿題の処理に慌てなくていいように少しずつ進めておく、というイメージに近いです。

また、この画面は全社員が見られるようになっているため、エンジニアはもちろんのこと、コストに興味のあるすべての人に情報は開かれています。特に経理といったバックオフィスのスタッフにも利用されており、それだけでもウェブアプリケーションとして内製した価値があると感じています。

このように、Costco そのものというよりは、Costco を中心としたコストの定期的な評価の機会を持つというオペレーションが良い結果をもたらしています。

購入決裁に関する機能

一般的な他の組織と同様、お金を使う場合は予算とは別にそれをもとにした購入決裁 (いわゆる稟議とも呼ばれるものです) を申請し、承認を受ける必要があります。実際に支払いが発生すると、承認を受けた金額の枠からその分が引かれ、消化していく形になります。

RI や Savings Plans で先払いした金額は予算上は毎月の償却として扱いますが、購入決裁においては実際に支払った分が消化されます。つまり、予算と購入決裁の消化状況に差が発生するため、購入決裁は独立して定期的に確認しておく必要があります。

クックパッドでは ERP として Workday を採用しており、購入決裁そのものやその承認プロセスの管理、金額の枠の消化状況 (請求情報) は Workday のデータベースに格納されています。コーポレートエンジニアリング部の尽力によって、Workday に格納されている請求情報を Informatica Cloud によって S3 バケットにエクスポートできるようになっています。Costco では、そのようにして連携されたデータ (AWS に関する請求情報のリスト) をバッチで取り込むことで、以下のように AWS の購入決裁の消化状況を簡単に確認できるようにしています。

購入決裁とそれに紐づく請求情報を一覧する画面

このように、購入決裁の消化状況も予算とあわせて定期的にチェックすることで、枠が不足しつつあることを早めに察知できます。その場合は、追加の購入決裁を出す手続き (稟議) をすることになります。

コスト配分タグに関する機能

クックパッドでは、コスト配分タグとして以下のタグのキーを設定しています。

• Project
• Name
• Role
• Environment
• Resource
• Owner

個々のタグの役割の詳しい説明は記事の趣旨を超えるため割愛しますが、このうち特に重要なのが Project タグで、このタグに設定された値によって AWS リソースがどのプロジェクトで利用されているかを分類しています。

たとえばクックパッドのレシピサービスで利用されているリソースは Project=cookpad、クックパッドマートに関わるリソースには Project=mart というような粒度でつけています。また、個々のユーザ向けのサービスによる分類だけでなく、たとえば VPC 運用に必要なものには Project=infra-vpc というタグをつけていたりもします。

Costco とは別の仕組みとなるためここでは詳細な解説は割愛しますが、EC2 や RDS、ElastiCahce、S3 など、AWS コスト全体に対して料金が支配的なサービスについては、Project タグの付与を強制する仕組みも内製で整備しています。

クックパッドでは AWS Organizations やアカウント間での VPC 共有などの機能が発達する前から長らく AWS を利用しており、一つの本番用アカウントにあらゆるアプリケーションが動くという構成になっています。アカウントが分かれていればそれだけである程度コストの分類が可能となりますが、そうではないため Project タグを整理することは特に重要な作業となっています。

Project タグをカテゴライズしてまとめて扱う機能

Project タグによる分類は便利ですが良くも悪くも粒度として細かく、もっとマクロな視点でコストを眺めたいときには不便です。くわえて、現状で約 300コの Project タグの値が存在しており、数が多くてそれらをフラットに扱うのは困難です。

そこで、Project タグの値をカテゴリという単位にまとめられるようにしました。カテゴリの一覧は以下のような感じになっています (一部です)。

Project タグのカテゴリ一覧 (抜粋)

漏斗のボタンを押すと、以下のように Cost Explorer に遷移し、自動的に Project タグによるフィルタが設定された状態でそのカテゴリ全体でかかっているコストを簡単に視覚的に確認することができます。以下のスクリーンショットは ECS・Hako カテゴリ*2の例です。

Cost Explorer によるカテゴリにかかるコストの可視化例

各カテゴリには、以下のようにいくつかの Project タグの値がぶら下がっています。これも ECS・Hako カテゴリの例です。

ECS・Hako カテゴリに属する Project タグの値一覧

このように、クックパッドにおける ECS・Hako エコシステムはいくつかのプロジェクト(≒アプリケーション) によって構成されていることがわかります。カテゴリの場合と同様、漏斗のボタンを押すことで Cost Explorer に遷移してコストを視覚的に把握できます。また、虫眼鏡のボタンを押すと、そのタグがつけられた AWS リソースを検索することができます。

Project=hako-console で検索した AWS リソースの一覧

このスクリーンショットは Project=hako-console の例です。

各 Project タグの値を複数のカテゴリに所属させるような、N:M (つまりタグに対するタグ) の関係で管理することも考えましたが、経験上、そのようなデータ構造にすると人間の認知能力の限界を超えてしまって収拾がつかなくなるため、あえて自由度を下げてカテゴリ:タグの値 を 1:N の関係で管理する仕様にしています。

Project タグの値にメタデータをつけて秩序をもたらす

Project タグの値が増えてくると、その値が持つコンテキストを頭の中で把握しておくことが困難になります。また、クローズしたアプリケーションやサービスに関連する Project タグに特別なフラグをつけて区別したくなります。その他にも、新たなプロジェクトが始まる際には Project タグの値を追加することになりますが、その値が適切な粒度がどうか、命名が適切かどうかを考え、誰かがレビューする必要があります。

これらの問題を解決するため、Costco に Project タグの値に対して以下のようなメタデータをつけて管理する機能を実装しました。

• コメント
• 非推奨フラグ

一見して値の意味がわかりにくいものについては、以下のスクリーンショットの infra-cost-optimization のようにコメントを書いて役割を明示することができます。

Project=infra-cost-optimization にコメントを付与している例

また、すでにクローズしたアプリケーションに関係する Project タグや、間違って新たに作ってしまったようなタグには非推奨フラグを設定し、今後新たに作る AWS リソースにはそのタグを付与しないように勧告することができます。

非推奨フラグが設定された Project タグの値

また、非推奨フラグが付与された Project タグによるコストが発生している場合、今月のコスト予測の画面で以下のような警告が表示され、AWS リソースの削除漏れに気づくことができます。

非推奨フラグが設定された Project タグによるコストの警告

Project タグの値として設定できる値はホワイトリスト管理されており、AWS リソース管理の Terraform 移行 - クックパッド開発者ブログ で説明されている Terraform 用のリポジトリにそのホワイトリストがあります。ホワイトリストの内容は以下のような素朴な改行区切りのテキストファイルで、このリポジトリの master ブランチにコミットが積まれたときに webhook を介してホワイトリストの内容を Costco の DB に取り込むようになっています。

Project タグがとりうる値のホワイトリスト

新しくプロジェクトを立ち上げる際には、当然そのアプリケーションで利用する RDS インスタンスなどの AWS リソースが必要になります。リソースの追加はこの Terraform 管理用のリポジトリに pull request を出すことになるので、その pull request にホワイトリストに対する変更を含め、SRE がレビューするという自然なフローになっています。その結果、みだりに Project タグの値が増えることがなくなり、秩序を保つことができます。

もしホワイトリストに存在しない Project タグの値が検出されたり、どのカテゴリにも分類されていない値がある場合、Costco の画面に以下のように警告が表示されます。その場合にはメッセージの内容に従い、警告を消すようにします。

未知の Project タグの値や未分類の値が検出されたときの警告

Project タグにメタデータをつけて管理するというアイデアは、dmemo の設計思想*3からインスパイアされたものです。時間の経過によって Project タグが持つコンテキストは徐々に失われてしまい、「このタグは何に利用されていたものだっけ？」となってしまうことがあります。そうならないよう、Costco では Project タグの値に対してコメントを書いたり非推奨フラグを付与することで、明示的に使われていない Project タグの値を区別できるようにしているのです。

予算の設定機能は AWS 謹製の AWS Budgets と役割が競合しているのですが、この Project タグの管理機能は Costco オリジナルなものであり、月次レポート機能と並んで個人的にとても気に入っている機能です。コスト最適化の作業の一環で、Project=management のような意味が広くて分類として機能していない Project タグの値を整理する作業を進めているのですが、タグごとの AWS リソースの検索機能を含め、とても役に立っている実感があります。

その他コストの管理に役立つ細かい機能

ここまで Costco のもっとも重要な二大機能である予算管理と Project タグ管理について説明しましたが、その他にもコスト管理に役立つ細かい機能を実装しています。

その一つの例として、以下のスクリーンショットのような Route 53 で購入したドメインの請求情報を一覧できる画面があります。

Route 53 で購入したドメインの請求一覧

このように、コストを管理するためのコンソールが存在することで、日々のコスト関連のオペレーションを楽にするための機能も実装することができます。その結果、SRE の文脈でいうところのトイルやオーバーヘッドによる負荷を軽減することができます。

Costco を内製するまでに検討した別の手法との比較

コストの妥当性を説明するという目的を達成するためのアプローチとして、わたしたちは Costco を作って運用するという道を今のところは歩んでいます。とはいえ、道はそれだけではないはずです。ツールを内製するという判断をするまでに、別の手法も検討しました。

VS. AWS Budgets

機能の紹介で述べたように、Cost Explorer のフィルタを予算額と紐付けて管理するというコンセプトは AWS の Budgets サービスと役割が競合しているため、一見して車輪の再発明をしているように見えます。

しかしながら、現状の AWS Budgets では Cost Explorer で使えるフィルタを完全に再現できないという問題があります。具体的には、AWS Budgets ではフィルタに not 条件を含めることができません。

また、月次レポートをまとめる場合にも、何らかの Wiki のようなシステムに AWS Budgets の情報を転記する必要があって面倒です。Savings Plans の国内向けサービス側と国外向けサービス側の利用割合のような、社内固有の情報も AWS Budgets からは取得できないため、結局スクリプトで集計した結果を転記する必要があります。

AWS Budgets は強力なツールですが、残念ながらわたしたちのユースケースはそれでは満たせないことがわかっています。

VS. CUR & Tableau ダッシュボード

AWS のコスト関連の機能の一つに、コストと使用状況レポート (Cost and Usage Report: CUR) というものがあります。これは Cost Explorer が利用しているコストの生データに (おそらく) 近いもので、設定次第で任意の S3 バケットに出力することができます。

クックパッドの DWH チームの尽力により CUR が Redshift Spectrum で簡単にクエリできるように整備されており、社内の Tableau を利用することで CUR のデータをベースにしたダッシュボードを作れるようになっています。ただし、CUR のデータは良くも悪くも「生」なデータで、非常に多くのカラムがあり、それらを正しく組み合わせてダッシュボードを作ることは、まさに Tableau 職人の技といえるでしょう。

わたしは残念ながらその域には達していないことと、Route 53 のドメイン請求一覧の機能などは Tableau では実現できないため、Costco のようなウェブアプリケーションの形にしました。その他にも、CUR だけでは Cost Explorer API で取得できるようなコストの予測値は得られませんし、Cost Explorer API では簡単に得られる償却コストの計算も難しいです。

ただし、今後 Cost Explorer API では得られないような情報を Costco で扱いたくなった場合には、CUR のデータをもとに Redshift で集計して Costco に取り込む、というニーズが発生するかもしれません。また、Costco 上でグラフィカルに表示することが難しい場合に Tableau ダッシュボードにリンクするなど、うまく活用していく道があるかどうかは常に考えています。

まとめ

まず冒頭でインフラコストの妥当性と、それを評価するために何が必要なのかを説明しました。そして具体的な実装例として、クックパッドで内製している Costco というコスト管理コンソールを紹介し、それによって達成されることをご紹介しました。

Costco では、

• 予算を Cost Explorer のフィルタと紐付けて管理し、月次レポートの一部を自動生成する機能
• Project タグ (コスト配分タグのひとつ) にメタデータを付与して管理しやすくする機能
• その他コストに関するオペレーションを楽にする機能

を実装することで、それらを使ってコストの妥当性を定期的に評価し、コストの状況に変化があった場合に「なぜその変化が起きたのか」ということを「説明」できる状態にすることを目指しています。また、エンジニアの枠にとらわれずに全社員が Costco を見ることで、誰もがなんとなくインフラのコスト状況がわかるようになり、経理などのバックオフィスのスタッフもコスト最適化の推進に巻き込んでいくこともねらいの一つです。

ともすれば、Costco のようなアプリケーションを開発することは、組織の規模感や状況によってはオーバーエンジニアリングとなるかもしれません。しかしながら、その根底にある考え方はあらゆる組織で役立つものだと信じています。たとえば、コスト配分タグの管理を Google スプレッドシートなどのツールで小さく始めてみるのも良いかもしれません。

これからインフラのコスト最適化に取り組んでいこうという方や、今まさに取り組んでいるという方に、この記事が届いて役立てていただければ幸いです。

*1:今では ALB に ECS によるターゲットグループを複数紐付けることで、このような構成にすることは簡単になりました。かつては ELB をもたないような ECS サービスを作り、Consul などのミドルウェアでサービスディスカバリを提供し、その情報をもとに NGINX などのウェブサーバからプロキシするというような構成を自作する必要がありました

*2:クックパッドにおける ECS の利用やそれを支える Hako エコシステムについて知りたい場合はhttps://techlife.cookpad.com/entry/2018/04/02/140846 や  https://logmi.jp/tech/articles/320723 が参考になります

*3:https://techlife.cookpad.com/entry/2016/08/08/103906