Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

クラウドコスト最適化の文化を社内に根づかせる3つのステップ

By Matan BordoNov 22, 202311 min read

このページはEnglishDeutschEspañolFrançaisItalianoPortuguêsでもご覧いただけます。

社内にコスト最適化の文化を築くために欠かせない3つの基本要素と、DoiTの製品を使って実践するためのステップバイステップガイドをご紹介します。

コスト最適化の文化を築く3つのステップ

多くの企業でコスト最適化は、「請求額を見て財務チームが慌てた」「資金調達を控えてバーンレートを下げる必要に迫られた」といった外部要因をきっかけに、慌てて着手される"火消し作業"になりがちです。

もし心当たりがあるなら、_会社全体で_もっと先回りした取り組みへと舵を切る必要があります。コスト最適化は誰か一人に任せる仕事ではなく、すべてのエンジニア、すべてのクラウド利用者が自分ごととして向き合うべきテーマです。

とはいえ、クラウド利用者に当事者意識を持ってもらうには、_全員が_クラウドコストに対する責任感とオーナーシップを持てる仕組みづくりが欠かせません。そのためには、まず利用者一人ひとりが自分のコストを把握できる状態をつくること。そしてそれを支えるのが、適切なコスト配賦(クラウドコストを所有者にひも付けること)です。

YouTube

タップしてミュート解除

YouTubeで動画を視聴

エラー 153

動画プレーヤーの設定エラー

YouTubeで他の動画を検索

クラウド利用者が_自分の_コストを把握できるようになると、自然と関心も高まります。「なぜこの金額になっているのか」と質の高い問いが生まれ、機能設計の段階からコストを織り込んだり、じわじわ膨らんでいる費用に先手を打ったりと、能動的な動きにつながります。

本記事では、社内にコスト意識の高い文化を根づかせ、クラウド利用者全員にとっての継続的な営みにしていくために必要な3つの基本要素を解説します。

ヒント #1 - リソース階層を組織構造に合わせる

クラウドリソースは、自社の実際の組織構造に沿って整理するのが理想です。Google CloudのフォルダやAWSのOrganizational Units(OU)は、それを実現するうえで非常に有効な仕組みです。

これらは、組織内の部門やチームごとにリソースを分離・分類するために使われます。その配下にプロジェクト(Google Cloud)またはアカウント(AWS)を配置し、各workloadは1つのプロジェクト/アカウントに紐づけます。

YouTube

タップしてミュート解除

YouTubeで動画を視聴

エラー 153

動画プレーヤーの設定エラー

YouTubeで他の動画を検索

この構造がないと、リソースの乱立、コスト配賦のしづらさ、アクセス管理の複雑化といった課題に直面しがちです。

クラウドリソース階層の例

これは、ソフトウェア開発の世界では決して新しい考え方ではありません。コンウェイの法則は、チームのコミュニケーションや組織のあり方が、そのチームが生み出す製品やシステムに影響を与えることを示しています。クラウドの世界でも同様で、組織構造を映したリソース構成にしておくと、運用も連携も格段にスムーズになります。

workloadは独立したアカウント/プロジェクトに切り分ける

さらに、各workloadは専用のAWSアカウントまたはGoogle Cloudプロジェクトに切り分けることが大切です。実際の現場では、すべてのworkloadを1つのアカウント/プロジェクトに詰め込んでいる、あるいは複数チームで共用しているお客様によく出会います。

関連性のないworkloadを1つのアカウントやプロジェクトにまとめてしまうと、コストの管理も利用状況の把握も一気に難しくなります。

YouTube

タップしてミュート解除

YouTubeで動画を視聴

エラー 153

動画プレーヤーの設定エラー

YouTubeで他の動画を検索

たとえば、別々の2つのアプリケーションのリソースが同じGoogle Cloudプロジェクト内に同居している状況を考えてみてください。プロジェクト/アカウントで分けていないと、タグ運用の完璧さに過度に依存することになります(これについては次のヒントで詳しく取り上げます)。組織が拡大するほど、この方式はコスト配賦の難易度を押し上げるばかりです。

Bad Foundations Blog Header

基本は「1アカウント/プロジェクトにつき1 workload」。ただし、規模もスコープも近い小さなworkloadが複数あるなら、まとめて同じアカウントに配置しても構いません(下図参照)。

Workloadアカウントのスコープ例

こちらも、エンジニアであれば馴染みのある発想でしょう。クラウドworkloadをアカウントやプロジェクト単位で切り分けることは、独立性が高く依存関係を最小限にするコンポーネント設計の原則「疎結合」と同じ考え方に立っています。

workloadを別々のアカウントやプロジェクトに分けることで、互いへの依存が最小限の独立した環境ができあがります。そのメリットはコスト配賦のしやすさだけにとどまりません。権限設計やレートリミットといった運用面・セキュリティ面の利点も、自然とついてきます。

ヒント #2 - リソースにタグやラベルを付ける

タグ(AWS、Azure)やラベル(Google Cloud)は、クラウドリソースに細やかな情報を付与するための仕組みです。

主なユースケースは次のとおりです。

  • 請求情報の補強(例:リソースにコストセンター情報を追加)
  • 環境/アプリケーションの分類(例:データセキュリティレベルの指定)
  • 自動化(例:再起動スケジュールの判定)

1つ目のユースケースに注目すると、タグやラベルはコスト配賦と追跡においてきわめて重要な役割を果たします。

タグを使えば、環境やチームといった単位でリソースを分類でき、それぞれのカテゴリにおける利用状況をはっきり切り分けられます。整理されたアカウント設計と組み合わせれば、フィルタの精度が上がり、特定のチームやアプリケーション単位でレポートを柔軟にカスタマイズしやすくなります。

YouTube

タップしてミュート解除

YouTubeで動画を視聴

エラー 153

動画プレーヤーの設定エラー

YouTubeで他の動画を検索

クラウドリソースにタグを付けるときの基本ルール

タグを設計するとき、つい「全リソースに適用すべき」と考えて多種多様なタグを盛り込んだ精緻な体系を組み立てたくなるものです。志は立派ですが、最初からそれを目指すのは現実的ではありません。まずは2〜3個のタグに絞って小さく始め、その運用を厳格に徹底することをおすすめします。

当社が「これだけは外せない」と考える3つのタグはこちらです。

  • アプリケーション名(例:「app_name」)
  • チーム(例:「team」)
  • ステージ/環境(例:「env」)

タグは大文字・小文字を区別するため、スネークケースのような命名規約を定めて重複を防ぐとよいでしょう。名称はもちろん自社の文化に合わせて自由に決めて構いませんが、わかりやすく説明的なものにしてください。この例では、「app_name」はマイクロサービスやworkloadの名前を、「env」は「development」「testing」「production」といった開発ステージを指します。

クラウドコスト配賦ウェビナー

各フィールドの値も、できるだけ標準化されたリストから選ぶ運用が理想です。たとえば「Website - Backend」のように表記がバラついたタグが付けられていると、データ分析の妨げになります。

タグがクラウド利用状況の理解に役立つ典型例として、組織内に「共有リソース」アカウントがあり、複数チームが利用するデータベースリソースをそこにまとめているケースが挙げられます。各データベースに対して、利用料を負担すべきチームを示すタグやラベルを割り当てておけば、誰がどれだけ使ったのかを明確にできます。

このトピックは、ブログ記事「Resource Labeling Best Practices」でさらに詳しく解説しています。

ヒント #3 - リアルタイムレポートとカスタムアラートを整える

整ったクラウドリソース階層を設計し、タグを付けて分類できるようにする。ここまでは大きな前進です。しかし、その細分化されたデータをもとにクラウド利用者へリアルタイムでレポートやアラートを届けなければ、せっかくの仕組みも宝の持ち腐れになってしまいます。

「プリウス効果」

O'Reillyの『Cloud FinOps』では、リアルタイムレポートがエンジニアのコスト意識ある行動に与える影響を、プリウスの運転になぞらえた"プリウス効果"として説明しています。

プリウスを運転すると、エネルギー消費量や、バッテリーが切れるまでの残り時間がリアルタイムで表示されます。アクセルを強く踏み込めば、エネルギー使用量が跳ね上がり、バッテリー残時間が短くなる様子が一目でわかります。この情報を見て、より穏やかな運転を心がける人もいれば、「急いでいるからバッテリーを早く減らしてでも加速する価値がある」と判断する人もいるでしょう。

その情報をどう使うかにかかわらず、ポイントは、これまで持っていなかったデータをもとに、より納得感のある意思決定ができている、という点にあります。

リアルタイムレポートが、現場主導の意思決定を後押しする

燃料消費がバッテリー寿命に与える影響を表示するプリウスのように、リアルタイムのクラウドコストレポートはその場で気づきをもたらし、自分が責任を持つインフラ領域について、クラウド利用者が自律的に判断を下せる状態をつくります。

コスト意識の高い文化への転換は一朝一夕には実現しませんが、リアルタイムレポートには、よりコスト効率の高い意思決定へと行動を変えていく力があります。

具体的には、コスト・利用状況レポート、ダッシュボード、予算、その他のカスタムアラートといった形で、それを見るクラウド利用者にとって意味のある情報を届けることが大切です。つまり、クラウド利用者が目にするレポートは、タグや関連アカウントを組み合わせてフィルタされ、本人やそのチームが責任を持つ消費分_のみ_が表示される状態が望ましい、ということです。

DoiTでコスト意識の高い文化を推進する

デジタルネイティブ企業は、DoiTの製品portfolioと、FinOpsおよびインフラ支援を担うクラウド専門家のグローバルネットワークを組み合わせて、自社のクラウド利用に関する確かな意思決定を実現しています。

ここでは、多くのDoiTのお客様がエンジニアリングチーム全体にコスト意識と当事者意識の文化を根づかせるために実践しているステップを、順を追ってご紹介します。

クラウドコストをビジネスのカテゴリにマッピングする

コスト配賦の最初のステップは、コストを割り当てたいビジネス上のグルーピングを定義することです。DoiT Cloud Intelligence™では、これをAttributionsを使って行います。Attributionsを使えば、クラウドリソースをグループ化し、配賦したい単位に沿ってコストを整理できます。

以下に、Attributionsを使ってコストを自社のカテゴリにマッピングする例を2つご紹介します。

1つ目の例では、3つの異なるAWSアカウントをまとめて、1つのアプリケーションのコストとして定義しています。

あるアプリケーションを想定したクラウドコストのマッピング あるアプリケーションを想定したクラウドコストのマッピング

2つ目の例では、プロダクトエンジニアリングチーム(ここでは「Team Bruteforce」)のコストを、**「team」ラベルまたはプロジェクトラベルの値が「bruteforce」**であるリソースとして定義しています。

あるエンジニアリングチームを想定したクラウドコストのマッピング

あるエンジニアリングチームを想定したクラウドコストのマッピング

リアルタイムのレポートとダッシュボードを作成する

定義したAttributionsは、Reportsやダッシュボードのフィルタとして活用し、特定のチーム・環境・アプリなど、Attributionsで定義した単位に絞って消費を表示できます。

たとえば下図では、「Application A」のAttributionをフィルタとして使い、コストをサービス別に分解したうえで、コスト上位10件だけを表示しています。

DoiTのAttributionsで定義したアプリケーションのコストを分解したクラウドコストレポート

DoiTのAttributionsで定義したアプリケーションのコストを分解したクラウドコストレポート

このレポートは、関連するクラウド利用者に向けて、定期的に更新・配信するスケジュールを組むこともできます。メンバー一人ひとりに「自分がクラウドコストに与える影響」を意識してもらう、シンプルで効果的な第一歩です。

クラウドコストレポートの定期配信スケジュール設定

クラウドコストレポートの定期配信スケジュール設定

さらに、特定のチームやアプリ専用のダッシュボードを作成し、関係するクラウド利用者がコストを俯瞰できるようにすることもできます。下図では、「Application A - Service Cost」レポートを、このアプリケーションの消費に関するレポートをまとめるために新しく作成したダッシュボードに追加しています。

あるアプリケーションのクラウドコストレポートを、同アプリケーションに関するレポートを集めたダッシュボードに追加

あるアプリケーションのクラウドコストレポートを、同アプリケーションに関するレポートを集めたダッシュボードに追加

下図は、関連するクラウド利用者へのレポート定期配信に加えて、チーム向けに作成できるダッシュボードの一例です。

特定のアプリケーションに関するカスタムクラウドコストレポートをまとめたダッシュボード

特定のアプリケーションに関するカスタムクラウドコストレポートをまとめたダッシュボード

カスタムアラートと、対象を絞ったAnomaly Detection

レポートに加えて、クラウド支出の特定領域を詳しく確認すべきタイミングを利用者に知らせるタイムリーなアラートも、意識と当事者意識を高めるうえで効果的です。

関係者向けに、きめ細かいクラウドコストアラートを設定する

たとえばDoiTのお客様は、より細かい粒度の利用状況をステークホルダーに把握してもらいたいときにアラートを設定しています。

下図では、「Application A」のAttributionをスコープにコストアラートを設定しています。_Evaluate for each_ドロップダウンで「customer」タグを選んでいるため、いずれかの_顧客_に対するサービス提供コストが前週比で25%以上増加した場合に通知が届く設定です。_Evaluate for each_ドロップダウンは、同じディメンションの各インスタンス(たとえばK8sの各ネームスペース)を個別に評価したいときに重宝します。

Evaluate for eachドロップダウンで「customer」タグを選び、いずれかの顧客に対するサービス提供コストが前週比25%以上増加した際に通知するアラート

Evaluate for eachドロップダウンで「customer」タグを選び、いずれかの顧客に対するサービス提供コストが前週比25%以上増加した際に通知するアラート

対象を絞ったAnomaly Detectionを設定する

DoiT Anomaly Detectionは、コストの急増を自律的に監視し、異常な支出を検知した時点で通知することで、請求への影響を最小限に抑える仕組みです。デフォルトでは、各アカウントまたはプロジェクトごとに、SKU単位で異常な挙動を検知します。

S3のDataTransferOut SKUで検知された異常の例

AWS S3のDataTransfer-Out-Bytes SKUで検知された異常の例

一般的なAnomaly Detection機能は、組織全体のクラウド利用を対象に異常を検知します。しかしこの広く構えるアプローチでは、各チームの業務には直接関係のない通知まで大量に届き、ノイズになりがちです。

一方、DoiT Anomaly DetectionではAttributionsを活用して、各クラウド利用者を「自分が責任を持つコスト」に関するアノマリーアラートだけにサブスクライブできます。これにより、アノマリー通知は一段進化し、各チームは自分たちが責任を負うクラウドコストに絞ったアラートだけを受け取れるようになります。

Attributionを作成したら、あとはそのAttributionに対してAnomaly Detectionをオンに切り替えるだけです。

特定のアプリケーションのクラウドリソースに対するAnomaly Detectionを有効化

特定のアプリケーションのクラウドリソースに対するAnomaly Detectionを有効化

あとは、Application Aの担当メンバーの通知設定から、当該Attributionに紐づくアラートにサブスクライブさせる(あるいは本人がサブスクライブする)だけです。

特定のAttributionのアノマリーアラートをサブスクライブする方法

特定のAttributionのアノマリーアラートをサブスクライブする方法

社内にコスト意識の高い文化を築くことは、「もっとコストを気にしてください」とクラウド利用者に呼びかければ済む話ではありません。利用者自身が、自分の業務にかかるコストを実感できるよう、データを届ける必要があります。

そして、各メンバーやチームがクラウド請求に与える影響について、できるだけ正確なデータを示すには、リソース階層を組織構造に合わせ、必要なタグを設計し、リソースに確実に付与していくことが欠かせません。さらに真価を発揮するのは、こうした基盤づくりとリアルタイムのレポート・アラートの仕組みを組み合わせたときです。

DoiTなら、その両方を一貫して実現できます。まずは当社のFinOps専門家と一緒に、まだ整っていなければ作成すべきタグや、自社の組織構造に合ったリソース階層を一緒に設計していきます。

基盤が整ったら、DoiTの製品を活用して、クラウド利用者にとって意味のあるリアルタイムなレポートとアラートを届けられます。

すでにDoiTをご利用中の方は、ここでご紹介した内容をDoiT Cloud Intelligenceでそのまま順番に実践していただけます。まだご利用でない方は、ぜひお問い合わせください。クラウド活用のどのフェーズにおいても、DoiTの製品とコンサルティングサービスをどう活かせるかをご案内します。