AWS と GCP のコストを減らせ！（Redash による可視化編）

DSOC Infrastructure Group の大澤です。
最近自身のあまりの不健康ぶりにさすがに危機感を抱いたので、自宅から徒歩10分にある24時間営業のフィットネスクラブに申し込んできました。過去何回か挫折しているので今度こそ継続したいものです。

さて、突然ですが、皆さんは AWS や GCP などのクラウドサービスを使っていますか？使っている人は毎月どのぐらいお金がかかっているか把握していますでしょうか？おそらく個人利用している人は毎月の利用料金についてシビアに見ている人は多いと思いますが、会社や団体などで使っている人はそこまで見ていない人が多いんじゃないかなと思います。私のタスクの一つに AWS、GCP のコスト管理があり、毎月の支払い額の把握や EC2 リザーブドインスタンスの購入計画、翌月の費用予測などをしています。

DSOC では AWS と GCP のマルチクラウドを採用しており、名刺データ化システム GEES に加え、名寄システム、新規事業も増え、利用するクラウドサービス・人員増加にともなって（金銭的）コストも増加傾向にあります。意図せぬ出費がないか日々ウォッチしていますが、スピードを求めるために少々のコストを犠牲にすることもしばしばあるため、結果として日々の積み重ねで増えていきます（私のお腹まわりのようですね）。

そこでコスト削減（ダイエット）を図るべく、開発者、R&D、データエンジニア、インフラエンジニアが一丸となってコストに向き合う、コスト削減プロジェクトが立ち上がりました。このプロジェクトは個々のメンバーにコスト意識を持ってもらうことと、コスト削減の2つを目的としています。DSOC 内の各グループから一人ずつ担当者をアサインしてもらい、それぞれ目標削減額を設定し、半年という短い期間で削減するための施策を打ち、その達成をめざします（今まさにすすめている最中です）。

コスト可視化における課題

プロジェクトのメイン担当である私が最初に取り組んだことがコストの可視化でした。コストを正確に把握することができなければ、何から始めればいいか分からず、ただ闇雲に取り組んだとしても費用対効果は小さいものになります。
今までは AWS Cost Explorer（以下、Cost Explorer）や、コスト配分タグによるタグ別のコスト算出を行ってきましたが、プロジェクトをすすめるにあたって以下の問題点がありました。

どこにお金が多くかかっているかを深く調査できない
各サービス・グループの正確なコストがわからない
AWS、GCP を横断したコストを把握しづらい

1 は Cost Explorer から EC2 や RDS などクラウドサービス別やインスタンスタイプ別にコストを知ることはできますが、リソースレベル（どのリソースか）でオペレーションレベル（どんな操作をしたのか）のコストを見ることはできません*1。ただなんとなく EC2 が高い、DynamoDB が高いことがわかってもどのリソースでどういったことをしたときが高いのかが分からず推測ベースになってしまいます。

2 は歴史的経緯から 1つの AWS アカウントに複数のサービス・システムが混在しているため、コスト配分タグによってタグ別にコスト算出をしています。タグ付けはおおよその範囲をカバーしていますが、完全とはいえずタグに紐付いていない「見えないコスト」が存在していました。また、今回のプロジェクトの目的の一つである、個々のメンバーのコスト意識を持つためにグループ単位の可視化が必要でした。

3 は AWS と GCP の請求金額を確認できる画面が別々であるため、マルチクラウドで運用している場合、全体コストが見えづらくなります。また、Cost Explorer で複数の AWS アカウントをまたいで見る場合は、支払い AWS アカウント（マスターアカウント）で見る必要があるのですが、マスターアカウントは経理など一部の人しかアクセスできないようにしているため、プロジェクトメンバーへの展開は難しいという事情があります。

BI ツールの要件

コスト可視化をするにあたり、以下の要件を満たす必要があります。

AWS・GCP を横断したサービス・グループ毎のコストを可視化できる
リソースレベル・オペレーションレベルでコストを追うことができる
なるべくコストをかけたくない
プロジェクトメンバーにとって馴染みやすい

1と2は先ほど説明した通りです。3と4は、利用者がほぼプロジェクトメンバーに限られ、個々によって利用頻度が異なるため、高価な商用ツールは導入へのハードルが高いです。また、プロジェクト期間が短めであるため、新ツール導入における学習コストをかけることは望ましくありません。

Redash の採用

様々な BI ツールを選定した結果、Redash を採用しました。採用理由は以下のとおりです。

コストが安価
AWS、GCP の請求データをクエリで取得でき、ダッシュボードが作成できる
DSOC メンバーが操作に慣れている

DSOC ではエンジニア・非エンジニアに関わらず、名刺のデータ化状況や KPI、調査目的に Redash を利用しています。オープンソース版 Redash を EC2 インスタンスにホスティングしているため、ユーザ追加などによる追加料金は発生せず、かかる料金は EC2 インスタンスのみです。さらに Redash は多くのデータソースと連携ができ、今回採用した Amazon Athena と BigQuery に対応していることが決め手となりました。

ダッシュボード

Redash は保存したクエリに対してグラフを作成しダッシュボードに貼ることができます。

実際のダッシュボードはこのようになっています。これはあるサービスのダッシュボードです。
サービス全体の費用や AWS サービス別・日別の推移が見れます。

f:id:ohsawa0515:20191122032633p:plain

また、ピボットテーブルでリソース・オペレーションレベルで可視化することができるため、どこに多く費用がかかっているかがわかりやすくなりました。

f:id:ohsawa0515:20191122032639p:plain

GCP も同じダッシュボード画面に表示させています。AWS と同様にサービス全体費用、GCP サービス別・日別の推移を出しています。また、リソースにラベル（後述）を付与することでアプリケーション別の料金推移も表示させています。

f:id:ohsawa0515:20191122032644p:plain

GCP でもピボットテーブルでオペレーションレベルの明細を出すようにしていますが、残念ながらリソース ID が取れていないため AWS と比較して情報量が落ちます。

f:id:ohsawa0515:20191122032649p:plain

Redash と AWS、GCP との連携

AWS、GCP における請求データのエクスポートおよび Redash との連携方法について説明します。全体像は以下の図となります。

f:id:ohsawa0515:20191121212637p:plain

AWS Cost and Usage Report

AWS Cost and Usage Report（以下、CUR）によって S3 バケットに請求データがアップロードされます。Amazon Athena（以下、Athena）からクエリ実行できるようにし、Redash のデータソースに Athena を追加することで、Redash から請求データをクエリできるようになります。

CUR では、請求データが配信される S3 バケットはマスターアカウントが所有している必要があり、Athena も同じ AWS アカウントからクエリ実行する必要があります。しかし、諸般の事情で Athena を実行するのは子の AWS アカウントからにするため、2つ工夫を施しました。

1つ目は AWS Glue（以下、Glue）です。Athena で CUR を利用するには、Glue データベース、Glue クローラを設定し Athena でテーブル作成する必要があります。AWS から提供されている CloudFormation テンプレートを使うことでこれらが簡単に設定できます。しかし、CloudFormation テンプレートだとマスターアカウントで設定を行うことになります。そのため、CloudFormation テンプレートを使わず、テンプレートの内容に沿って子 AWS アカウントで Glue を設定しました。このとき、Glue の IAM サービスロールでマスターアカウントに Assume Role でアクセスできるようにします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": [
                "arn:aws:s3:::<ビリング用S3バケット>/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::<マスターAWSアカウントID>:role/billing"
            ]
        }
    ]
}

2つ目は請求データファイル（S3 オブジェクト）のアクセス権限です。CUR から S3 バケットに配信する際、S3 オブジェクトの所有者はマスターアカウントではなく CUR 自身になります。Athena には Glue のように Assume Role でアクセスできる仕組みがないため、子 AWS アカウントの Athena からクエリ実行するには S3 バケットポリシーだけでは不十分でした。そこで、S3 オブジェクトが配信されたら AWS Lambda（以下、Lambda）を実行して S3 オブジェクトに子 AWS アカウントの Read 権限を付与するようにしました。一日数回の配信なので Lambda 実行にかかるコストは微々たるものになります。

AWS リソースのタグ付け

前述したように、サービス・所属グループ毎のコストを可視化するにあたって、すでにサービス別に AWS アカウントが別れている場合を除いてリソースのタグ付けが必要です。しかし、すべての AWS リソースに対して正確なタグ付けをしていくのは大変時間がかかってしまいます。幸いなことにサービス・所属グループに由来した AWS リソース名（もしくは Name タグ）が付けられていたため、ルールに則ってリソース名からサービス・所属グループのタグを自動的に付与することにしました。例えばプレフィックスに「gees」とついていたら Service:GEES、「randd」とついていたら Service:Randd といった具合です。これらは簡単な例ですが、実際には様々なパターンに則ってタグを付けていきます。対象となる AWS サービスは EC2（EBS、AMI、EBS スナップショット、ELBを含む）、RDS（スナップショットを含む）、S3 といったメジャーなものから Glue、CloudWatch Logs など見逃しがちなサービスまでカバーしています。これを Lambda で日次実行しています。ステージング・開発用の AWS アカウントもタグ付けの対象になるため、Assume Role で複数の AWS アカウントにあるリソースにアクセスするようにしています。

しばしばタグ付けルールに入らないリソースが出てくるため、Redash ダッシュボードでタグ付けされていない割合とリソース一覧を見れるようにし、定期的にチェックすることで漏れを減らしていくようにしています。

Amazon Aurora クラスタのタグ付けについて

タグ付けをしていく中で頭を悩ませたのが Amazon Aurora クラスタ（以下、Aurora クラスタ）です。AWS CLI やマネジメントコンソールから Aurora クラスタにタグ付けはできるのですが、CUR を使うにあたって以下の問題が生じました。

CUR の lineItem/ResourceId に Aurora クラスタのリソース ID が表示される
Aurora クラスタがコスト配分タグに対応していない

CUR の lineItem/ResourceId に Aurora クラスタのリソース ID が表示される

lineItem/ResourceId に AWS リソース ID が表示されます。EC2 インスタンスであればインスタンスID、S3 であれば S3 バケット名が該当しますが、Aurora クラスタの場合はクラスタ名ではなく、Aurora クラスタに紐付いたリソース ID となります。

例えば、foo-cluster という Aurora クラスタの場合、CUR には arn:aws:rds:ap-northeast-1:123456789012:cluster:cluster-anm724oxm5beoil5j5ptbgbihm というように我々が認識できるクラスタ名に紐付かないため、CUR だけでは何の Aurora クラスタなのかを知ることはできません。

Aurora クラスタがコスト配分タグに対応していない

Aurora クラスタ ID の CUR レコードを見ると、コスト配分タグが記録されておらず、タグによるコスト算出ができなくなります。サポートに問合せしましたがバグではなく仕様とのことで対応時期は未定とのことでした。

解決策

この問題の解決策として、Aurora クラスタ名とリソース ID をマッピングした CSV ファイルを S3 に配置し、Athena で CUR とテーブルジョインすることにしました。具体的には、以下のようなファイルを日次で Lambda 実行して作成します。1レコードに Aurora クラスタ名、リソースIDに加えて AWS アカウント ID とコスト配分タグを含めます。

account_id	db_cluster_identifier	db_cluster_resource_id	service_tag
123456789012	foo-cluster	arn:...（省略）...:cluster-abcd	foo
123456789012	bar-cluster	arn:...（省略）...:cluster-efgh	bar

Athena で CUR と同じデータベースでテーブルを作成しておき、Redash からクエリ実行するときには CUR のテーブル名とこのテーブルをジョインすれば Aurora クラスタ名でタグに紐付いたコストを取得することができます。

例えば、このようなクエリを実行することで、ある Aurora クラスタの費用を出すことができます。

SELECT
    SUM(line_item_unblended_cost) AS cost
FROM "aws_billing"."billing_cur_athena"
LEFT JOIN rds_aurora_cluster_resource   -- Aurora クラスタのマッピングテーブル
ON billing_cur_athena.line_item_resource_id = rds_aurora_cluster_resource.db_cluster_resource_id
WHERE year = '2019' AND month = '11' AND db_cluster_identifier = 'foo-cluster';

GCP（Cloud Billing）

GCP（Cloud Billing）は請求データを BigQuery にエクスポートすることができます。自動的に日毎にパーティションされており、必要に応じて保存期間を設定できます。
Redash のデータソースに BigQuery を追加することで、Redash から請求データをクエリできるようになります。

ラベリング

GCP にはラベルという機能があり、AWS 同様にラベル別にコストを算出することができます。ラベルはリソースだけではなく GCP プロジェクトに対しても付けることができます。DSOC ではサービス・チーム別に GCP プロジェクトを分けており、GCP プロジェクトにラベルを付けています。そのため、リソースにラベルを付与しなくてもコスト算出することができます。

下図は Resource Manager から GCP プロジェクトにラベルをつけています（モザイクばかりですいません･･･なんとなく雰囲気だけ感じ取ってください）。

f:id:ohsawa0515:20191121212647p:plain

例えば、service:foo というラベルをつけた GCP プロジェクト別の費用を取得するには以下のようなクエリを実行します。

SELECT
  project.id AS project_id,
  -- 通常料金にクレジット、丸め誤差を加えた合計
  SUM(cost) + SUM(IFNULL((SELECT SUM(c.amount)
                FROM UNNEST(credits) c), 0)) AS jpy
FROM `<project_id>.<table>`
INNER JOIN UNNEST(project.labels) AS plabels
  ON plabels.key = "service" AND plabels.value = 'foo'
  WHERE invoice.month = '201911'
GROUP BY
    project_id
ORDER BY jpy DESC;