（2019/04 追記 この記事の情報は古いです。 今では The Cloud Billing Reports ができて、プロジェクトごとのコストが追いやすくなりました！ありがたいです！）
この記事はCyberAgent エンジニア Advent Calendar 2015 の24日目の記事です。
メリークリスマス！エンジニアブログ運営チームの柿島大貴です。今年は、前半は１月に共著でHBaseの本を出したり、5月にサンフランシスコで行われたHBaseCon 2015で発表したりとHBaseのことばかり考えている日々を過ごしていました。後半は、アメーバでのAmazon Web Services（以下、AWS）やGoogle Cloud Platform（以下、GCP）といったパブリッククラウドの利用が増えてきたため、7月から急遽部署を異動してパブリッククラウドのコスト削減や利用戦略などを考えるチームを作って日々色々な社内プロジェクトと連携をしています。
今回は、その流れでパブリッククラウド、特にGCPのコストについて書きたいと思います。今回の記事で利用する画像はマスクが多く入りますがご了承ください。（イブ公開の記事なのにクリスマスまったく関係ないのもご了承ください）
アメーバでは、AWS,GCPともに支払いアカウント（billing account）は1つでそのアカウントに各プロジェクトのアカウントを紐づける運用をしています。この仕組みはでは支払いアカウントにまとめて請求が来るため、支払い面では便利なのですが、各プロジェクトには請求書が届きません。データセンターに大量のサーバを購入して利用するオンプレミス環境と違って、パブリッククラウドの場合、利用するプロジェクトのエンジニアがコストを意識できる環境を作ることがコスト削減の近道ではないかと考えているのですが、コストがわかりづらいとそもそも意識することが難しいよねというお話になります。
AWSではCost Explorerといった仕組みがあるので、各アカウントでもコストの推移などが調べやすい環境があるのですが、GCPでは各プロジェクトで当月のコストは見えても(Fig.1)、過去の履歴は支払いアカウントでしか見れません(Fig.2)。ただ、この支払いアカウントは支払いに関する情報や他のプロジェクトの情報が見えてしまうといったこともあって最低限のメンバーにしか権限を与えておりません。そのため、各プロジェクトのメンバーから問い合わせがあったときに私からそのプロジェクトのみに絞った過去のデータを渡すという対応をしていました。
Fig.1 各プロジェクトで見れる請求情報は当月のもの
Fig.2 支払いアカウントでは過去のデータも見れるが、権限は最低限のメンバーのみに絞っている
ただ、この問い合わせ対応ベースで過去の履歴を渡すのは、利用プロジェクト側も私たちも面倒なためコストを気軽に確認するという環境ではありませんでした。これを改善したいというのが今回のモチベーションです。
1. Export billing data を有効にする
まずは、支払いアカウントで Export billing dataを有効にします。この機能はdailyのGCPの使用量や料金を指定したGCSのbucketに2日遅れくらいでｃｓｖやjsonで出力してくれる機能です。有効にする方法や出力されたファイルがどんな項目を持つかは https://support.google.com/cloud/answer/6293835?hl=en をみてください。この機能を有効にします（Fig.3）。ここで指定するGCSのbucketを持つプロジェクト、GCSのbucketの権限は支払いアカウントに触れるメンバーに限定してあります。
Fig.3 Export billing dataを有効にする
この例ではcsvのフォーマットでExport billing dataを有効にしています。有効にした日以降のdailyのファイルが2日遅れぐらいで出力されますので、数日後に指定したGCSのbucketを見てみるとこのようにdailyでcsvが出力されていることがわかります（Fig.4）。
Fig.4 指定したGCSのbucketには指定したフォーマットでファイルが出力される
2. Bigqueryにデータを入れる1.で出力されたファイルはcsvやjsonなので、好きなように使うことができると思います。色々やり方はありますが、GCPにはBigqueryという便利な分析サービスがありますのでアメーバではこれを利用します。アメーバでは、AWSやオンプレで動いているサービスのログ解析として、Bigqueryを利用しているものもあって（社内のログ解析基盤もあります）、エンジニアが慣れているということや、REST APIや各種言語のクライアントライブラリもあるため、他のものとの連携もしやすいのではというのが理由です。
BigqueryへはプロジェクトごとにDatasetをわける形でロードをします（Fig.5）.。なぜ、DatasetごとにわけるかというとこのDatasetの単位でアクセスコントロールが可能なためです。 また、月単位でtableをわける運用にしています。各プロジェクトには共有をしないですが、管理側で使用するために全プロジェクト含んだtableも作成しています。
Fig.5 プロジェクトごとにDatasetsをわける
Bigqueryへのデータのロード方法も、Export billing dataで指定したGCSのbucketのファイルを直接ロードしてからCreate table from queryで作る方法もあありますが、一部前処理をする都合で一度Pandasで処理してからBigqueryにロードしています。当月に関してはcronでdailyの更新をしています。ここらへんのロード方法はまだまだいい方法があると思うので模索中です。
ロードしたtableに対して、実際にクエリを投げてみます。たとえば、先月（2015年11月）のとあるプロジェクトのコストが高かった要素TOP5を見てみます。例えばとあるプロジェクトではBigqueryが高く（Fig.6）、別のプロジェクトはGCEのインスタンスが高い（Fig.7）ということがわかります。
Fig.6 とあるプロジェクトの先月のコストが高かった要素のランキング TOP5（Bigqueryが高い）
Fig.7 別のプロジェクトの先月のコストが高かった要素のランキング TOP5（GCEのインスタンスが高い）
3. Datasetごとに共有設定をする
では、このBigqueryのDatasetに各プロジェクトのメンバーが使えるように共有設定をします。ここではGUIで設定をしてみます。Dataset右側の+ボタンを押すとあらわれるメニューから「Share dataset」をクリックします（Fig.8）。共有する単位はいくつかあります（Fig.9）。また、"Is owner"/"Can edit"/"Can view"の権限レベルも選ぶことができます。今回は、User by e-mailで1人対してDatasetを"Can view"で共有します（Fig.10）。
Fig.8 Share dataset メニューの場所
Fig.9 共有オプションの種類
Fig.10 User by e-mailで1人に共有をしてみます
共有をされたプロジェクトのメンバー側で確認をしてみると、共有されたDatasetだけ見えていることがわかります（Fig.11）。画像はマスクでわかりづらいですが、cost_ではじまるDatasetは1つだけ見えています。
Fig.11 共有したプロジェクトのメンバー側では共有したDatasetsのみ利用可能
4. 利用者に試してもらう（いまここ）
実際にはいまは一部のプロジェクトにだけこの仕組みを提供しています。Bigqueryに入れるのが本当に使いやすいか等、色々意見を聞きながら改善をしてから、全プロジェクトに展開をしようと考えています。
5. Cloud Datalabで可視化をする（おまけ）
データがあると可視化したくなりますよね！Betaサービスとして先日提供されたGoogle CloudDatalabで可視化をしてみます。CloudDatalabではpythonやSQLなどを使って分析が可能です。同じGCPのプロダクトなのでBigqueryへの接続も簡単にできます。例えば、アメーバのとあるプロジェクトの直近3か月のコスト推移を表示してみます（Fig.）。
Fig.12 とあるプロジェクトのここ3か月のコスト推移
表示できましたね！ただ、こちらのCloudDatalabは他の方との共有方法に難ありだったので別の方法（re:dashあたり）を模索中です。
このような感じで、Google Cloud Platform（GCP）で各プロジェクトでコストを追える環境を整えている最中です。利用する各プロジェクトがコストを意識できるような環境を提供することで間接的にアメーバのコストを最適化していけたらと思っています。
明日は CyberAgent エンジニア Advent Calendar 2015の最終日 @kakerukaeru の「今年も1年ありがとうございました from 公式エンジニアブログ」です。