アンチパターンやムダな支出の兆候となりうる、クラウド請求書に潜む見落としがちな7つの危険信号と、その対処法をご紹介します。
クラウドコストの最適化では、請求書の行間を読み解くことが求められる場面があります。
目に見えるコストの急増ばかりに意識が向きがちですが、数字の裏に潜む、もっと微妙で気づきにくいシグナルにも目を向けてみてはいかがでしょうか。
先日配信したCloud Mastersポッドキャストでは、DoiTの3名のテクニカルアカウントマネージャー(TAM)が集まり、お客様のもとで実際に見つけた「見落としがちなクラウド請求書の危険信号」7つと、その代わりに取るべきアクションについて語り合いました。
いずれも「一目でそれとわかる」コスト急増ではなく、ムダな支出や非効率な運用を示唆しているかもしれない、もっとさりげないヒントです。
下記からエピソード全編をお聴きいただくか、このまま読み進めて、それぞれの危険信号と具体的な対策をご確認ください。
危険信号 #1:AWS CloudTrailに料金を払っている
CloudTrailに少しでも料金が発生しているなら、クラウド請求書を圧縮できる余地があります。リージョン内で最初のCloudTrail trailは無料です。そしてtrailは_AWS Organizationレベルにのみ_作成すべきです。Organization trailはOrganization内のすべてのメンバーアカウントに自動で作成されるためです。
注意したいのは、新しいtrailはメンバーアカウント内の既存trailに_追加で_作成されるという点です。過去にメンバーアカウントごとに個別のtrailを作成していた場合は、それらを削除することでコストを削減できる可能性があります。
CloudTrail trailをOrganizationレベルで作成すると、Organization trailの設定がすべてのアカウントに伝播するため、組織内のアカウント全体でイベントロギング戦略を統一的に適用・運用できます。そのため、Organization trailの設定が、配下のすべてのアカウントに望ましい内容になっているかを必ず確認してください。
危険信号 #2:データライフサイクルポリシーがなく、ストレージコストが右肩上がり
クラウドストレージのコストが時間の経過とともにじわじわと増えているなら、適切なオブジェクトライフサイクルポリシーが適用されていないサインかもしれません。
オブジェクトライフサイクルポリシーは、事前に定義したルールに基づいてデータを別のストレージクラスに移行したり削除したりする処理を自動化し、ストレージコストをデータの価値やアクセス頻度に見合ったものに揃えてくれます。これにより、即時アクセスが不要なデータや陳腐化したデータの保管に過剰な費用を払わずに済みます。
ライフサイクルポリシーがないと、データはたまり続け、ログストアは肥大化し、不要なスナップショットが残り続けます。その結果、特に古いデータやアクセス頻度の低いデータが高コストのストレージ階層に置かれたままだと、ストレージコストは右肩上がりになります。
多くの場合、30〜90日でオブジェクトを移行または期限切れにすれば十分です。コストが上昇傾向にあるなら、ストレージを詳しく見直す価値があるという何よりのサインです。
危険信号 #3:CloudWatchのGetMetricData APIコストが高い
New RelicやDatadogといったサードパーティサービスは、最新の利用状況を取得するために、お客様のクラウドアカウント(通常はCloudWatchメトリクス)を定期的にスキャンしています。
しかし、これらのサービスが発行するAPIリクエストにも料金が発生していることに気づいていないケースが少なくありません。これらのAPIリクエストは、CloudWatchの「GetMetricData」API SKUに反映されます。注意を怠ると、サードパーティ製ソフトウェアからのGetMetricData API呼び出しが原因で、CloudWatchに莫大なコストを支払うことになりかねません。
そのため、次の点に目を配る必要があります。
- これらのAPI呼び出しの頻度
- スキャン対象となっているメトリクスやデータの内容
たとえば、リソースの多い開発アカウントで毎分APIが呼び出され、CloudWatchに多額のコストが発生しているといったケースが考えられます。こうした状況では、その頻度、そしておそらくはデータの粒度が本当に必要なのかを問い直すべきです。
こうしたAPI呼び出しによるCloudWatchコストを下げるには、多くの場合、サードパーティサービス側に依頼して、特定のアカウントやプロジェクトに対する取得頻度やメトリクスを調整してもらうだけで十分です。
危険信号 #4:ロギングコストがクラウド請求の20%超
ロギングは監視やトラブルシューティングに欠かせませんが、過剰なロギングはクラウド請求を膨らませます。
前項のAPI呼び出しに関するアドバイスと同じく、ロギングで取得している頻度やメトリクスがそのユースケースに見合っているかを問い直してみましょう。たとえばログデータでダッシュボードを更新しているなら、必ずしも秒単位の更新は必要なく、5分おきの更新で十分なこともあります。
目安として、クラウド請求の20%以上をロギングに費やすべきではありません。この20%を超えているなら、ロギングコストの内訳を詳しく確認すべきサインです。ログを利用している各チームに用途を聞いてみると、頻度や取得しているロギングメトリクスを調整できる箇所が見えてくるはずです。
あわせて、本番以外の環境でのロギングもしっかり見直しましょう。本番以外の環境は必ずしも収益を生むわけではありません。本番アカウントと同じ頻度や同じメトリクスを追跡する必要はないはずです。本番以外で何かが壊れたときは、ログをオン/オフ切り替えれば対応できますが、本番では原因を特定するためにより多くの情報が必要になります。
危険信号 #5:意思決定をクロスチェックしていない
この危険信号は、請求書やコスト・使用状況レポートで具体的に確認できる項目ではありませんが、技術や設計の意思決定をクロスチェックしないでいると、後々クラウド請求の頭痛のタネやパフォーマンス問題に発展しかねません。
非常によくあるのが、あるチームが組織全体の戦略や他チームのニーズを踏まえずに、独断でcommitment割引(例:Savings Plan)を購入してしまうケースです。技術部門は今後2年でサーバーレスへの移行を考えていたのに、誰かが3年契約のSavings Plansを購入してしまい、結果としてVMの利用に縛られてしまう、といった具合です。
クラウドで構築する際に「客観的に正しい」意思決定というものは存在しません。クラウドに関する判断を単独で下すと、非効率やコスト増を招きます。同僚や他チームと、自分の判断が妥当かどうかを社内でどう確認しているかを問い直してみましょう。より具体的には、エンジニアリングの戦略やビジョン、あるいは関連するRFCやADRドキュメントに照らして、クラウドインフラの意思決定を検証するということです。
危険信号 #6:組織ポリシーでリージョンやインスタンスタイプを制限していない
組織ポリシー(Google CloudおよびAWSのドキュメントを参照)は、クラウドユーザーが自社のクラウドリソースにどのようにアクセスし、利用し、管理できるかを定義するための仕組みです。
コスト最適化(およびセキュリティ)の観点では、本来サービスを起動すべきでない場所でユーザーが勝手に起動してしまうのを防ぐうえで特に有効です。
具体的には、インスタンスタイプやリージョンを制限する組織ポリシーがないと、クラウドインフラはセキュリティ脆弱性やムダな支出のリスクにさらされます。悪意のある攻撃者はこの管理の甘さを突いて、使われていないリージョンにインスタンスを立て、検出を逃れながら不正な活動を行う可能性があります。
たとえば、すべてのリソースが欧州にあるのに、悪意であれミスであれ、誰かが南米でt4インスタンスではなくx1インスタンスを立ち上げてしまう——そんな事態を防ぐためにも、利用するインスタンスタイプとリージョンを限定しましょう。
組織ポリシーを導入することで、クラウド環境を確実に保護しつつ、リソース利用を最適化できます。
危険信号 #7:ストレージバケットへの過剰なAPI呼び出し
ストレージバケットへの頻繁かつ不要なAPI呼び出しは、ストレージコストを押し上げ、パフォーマンスにも影響します。この危険信号はさまざまな場面で現れます。
アプリケーションがクラウドストレージバケットに対して頻繁にAPIを呼び出している、というケースが考えられます。これは特に、大量のデータを生成するアプリケーションや、頻繁にデータ転送を行うアプリケーションで起こりがちです。あるいは、ストレージバケットと連携するスケジュール処理が、時間の経過とともにAPI呼び出しを大量に積み上げている可能性もあります。
コスト面に加えて、頻繁なAPI呼び出しはアプリケーションのパフォーマンスにも影響し、遅延やタイムアウト、さらにはシステム停止を招くこともある点を踏まえる必要があります。
適切な監視を行っていないと、請求書が届くか、サービスのクォータ上限に達するまで何の警告もなく、気づかないうちに過剰な支出が積み上がってしまいます。
そのため、各処理に必要なAPI呼び出し回数を最小限に抑えられるよう、アプリケーションコードを見直し、最適化しましょう。あわせて、頻繁にアクセスするデータをメモリに保持するキャッシュ機構を実装し、ストレージバケットへの繰り返しのAPI呼び出しを減らすのも有効です。
クラウド請求書に「正しい問い」を投げかける
注目すべき危険信号のリストはお示しできますが、見直すべき項目は挙げればきりがありません。だからこそ長期的には、クラウド支出に対して好奇心を持ち続けることが何より重要です。請求金額をそのまま受け入れるのではなく、「なぜ?」と問い、さらにもう一度「なぜ?」と掘り下げてください。
たとえばS3のコストが増えているなら、どのバケットが増加要因なのかを問います。次に、そのバケットでコストを押し上げているSKUは何かを問います。そしてデータ転送コストが原因だと判明したら、それらのバケットにおけるデータ転送コストの増加が想定内だったかどうかを、自分自身やチームに問いかけてみましょう。コスト増加には正当な理由があるかもしれませんが、問わなければ何もわかりません。
こうした積み重ねによって、社内全体にコスト最適化の文化が根付き、誰もがクラウド請求への自身の貢献を意識し、自ら行動を起こせるようになります。
ここで挙げた危険信号は、いずれも責任を分かち合うことと、クラウド請求書に好奇心を持つことの重要性を浮き彫りにしています。最適化の機会を見つけ出す役割は、Head of InfrastructureやFinOps Leadだけが背負うものではありません。これは、チームワークがあってこそ進む取り組みなのです。