クラウド・コスト最適化を極める。成功のためのフレームワーク

記事をシェアする:

本記事は、ブログ連載記事「クラウド・コスト最適化を極める」の第2回です。

今回は、デジタル・トランスフォーメーション（DX）やクラウド最適化ジャーニーに成功した企業が採用しているフレームワークをご紹介します。

クラウド支出の最適化に向けたイニシアチブ（および課題）

2017年、RightScale（現Flexera）の『State of the Cloud』レポートで、「既存のクラウド支出の最適化」が2016年の最優先イニシアチブ「ワークロードのクラウド移行の推進」を抜いて、クラウド・ユーザーの最優先イニシアチブ（53%）に初めて躍り出ました。

コスト最適化のイニシアチブは、それ以降のすべてのレポートで1位を維持しており、2020年に至っては73%もの回答者が最優先イニシアチブとして挙げています。

では、企業が今もなおクラウド・コストの削減を最優先クラウド・イニシアチブや最優先課題として挙げているのはなぜでしょうか。読者の皆さんがおそらく自身の経験からすでにご存じのとおり、この取り組みは言うほど容易なことではありません。

前回の記事「クラウド・コスト最適化を極める。その原理」では、クラウド・コスト最適化の主な課題と、適切に設計された絶えず最適化されるクラウド環境を実現するために必要なコア原則を取り上げました。本稿を読み進める前に、必ずそちらの記事に目を通し、内容を理解しておいてください。

今こそアクションを起こす時

長年、企業はレポートに重点を置くことによって、コスト最適化の達成に努めてきました。これにはチャージバック・レポートや長いExcelスプレッドシート、図やグラフを多用したダッシュボードなどが含まれます。

しかし、悲しいかな、このアプローチがうまくいくことはまれです。データをじっと見つめたところで、クラウド請求書の金額が下がることもなければ、関係者間でレポートの検討が進むこともありません。

誤解のないように申し上げると、何もコストの可視化や報告の重要性を軽視しているわけではありません。コストの可視化は、企業のクラウド・コストの最適化戦略に不可欠な基盤であり、必要な説明責任を確立するために大切ですが、それだけでは不十分です。クラウド環境を最適化するには、アクションを実行しなければなりません。しかし、これも言うほど簡単なことではありません。

アクションを実行するには、いつ、どんなアクションを起こすべきか、そのアクションの結果としてコスト削減以外に何が得られるかを理解する必要があります。

これまで、クラウド最適化アクションの特定・分析・実行のための内部プロセスを定めた企業に何度もお会いして、お話を伺ったことがあります。多くは、そのプロセスが手動で、時間と手間がかかる上に、拡張性に乏しいということを認めています。特に大規模クラウド環境では、そうした努力の効果もさらに限定的になります。

解決策は、オートメーションです。つまり、人間が介入しなくても最適化アクションを実行できるようにすることです。技術的観点から言えば、オートメーションはそれほど難しくありません。詳しい資料と強力なAPIが用意されているパブリッククラウドの場合は特にそうです。クラウド最適化の自動化を実現する上での主な課題としては、複雑性と信頼の2つが挙げられます。

多面的な複雑性

ここでの複雑性とは、仮想マシン（VM）、PaaS（Platform-as-a-Service）、さらにはコンテナの規模の適正化など、正確で実用的なクラウド最適化アクションを生成するプロセスのことを指します。

例えば、1つのワークロードを適切なサイズに変更するには、まず応答時間やトランザクション数といったアプリケーション・パフォーマンスのモニタリングを行うほか、複数のメトリック（CPU、メモリー、IOPS、ネットワークなど）にわたってリソースの使用状況を観測する必要があります。次に、すべてのデータを分析し、クラウド・ベンダーが提供している膨大な構成オプション（および料金）の増え続けるカタログの中から、最適なターゲット・インスタンス・タイプ／SKUを決定します。その後、ターゲット構成が決まったら、組織の方針、OSドライバー要件、ストレージ・タイプのサポートなどの制約事項を検討する必要があります。下の図は、ワークロードをスケーリングする際に考慮すべきさまざまな要素を示しています。

オートメーション・ジャーニーには信頼が必要

アクションを自動化することについて組織の同意を得るには、アクションが正確かつ安全で、特に本番環境におけるアプリケーションのパフォーマンス低下を招かないという信頼を獲得しなければなりません。

信頼を得るには、時間と体系的なアプローチが必要です。これは複数の段階を踏むジャーニーであり、パブリッククラウドの成熟度モデルにほぼ寄り添う形になります。

• 可視化から始める：最初のステップでは、クラウド環境全体を可視化し、差し当たっての最適化機会に目星を付けます。このステップには、すべてのアカウントとサブスクリプションの把握と集約のほか、クラウド・プロバイダーに対する全体的な支出とコミットメントの理解、そして目的、所有者、環境（本番、テスト、開発など）に基づく各種ワークロードのタグ付け／ラベル付けが含まれます。以上は、すべてのサブスクリプション／アカウントにわたって行う必要があります。
• まず簡単に達成できる目標から取り組む：主に最も抵抗が少ないためという理由で手始めとしてお勧めなのは、使用されていない不要なVM、ロード・バランサー、パブリックIP、アタッチされていないボリューム、古いスナップショットといった未使用のリソースを終了させることです。この段階で、かなりのコスト削減効果が得られます。
• 本番用の1年予約を購入する：また、本番以外にも注意を払いながら、本番用の1年予約の購入を検討することもお勧めします。というのも、最適化には時間がかかるためです。これはどうすることもできません。1年のリザーブド・インスタンスまたはSavings Planを購入することにより、非本番環境で高度な最適化スキルを磨くにつれて30～40%のコスト削減を実現することが可能になります。3年よりも1年をお勧めするのは、1年目のうちに本番用としてさらに高度な最適化計画を立てることが目標だからです。この取り組みには、本番ワークロードを最適なサイズ（適正化など）にスケーリングした上で、最適化されたインスタンス・タイプ／SKUに基づいて新たな予約を購入することが含まれます。
• 計画停止を実施する：営業時間外に非本番ワークロードを停止すると、直ちにかなり大きなコスト削減効果が得られます。例えば、午後6時から午前6時までワークロードを停止すると、コンピューティング・コストを50%削減でき、週末や休日の間も停止すればさらなるコスト削減が可能です。
• 非本番環境でIaaSのスケーリングを実行する：この段階では顕著なコスト削減効果が得られるため、多くのチームがさらなるコスト削減の機会の発見に意欲的になります。事業部門のやる気を生かし、スケーリング・アクションで非本番環境に取り組むことをお勧めします。この段階は最適化の取り組みの成否を大きく左右するため、この段階のみに注目した成熟度曲線を作成しました。
  • 手動のアクション実行から始める：すべてのスケーリング・アクションをレビューして正確性を検証し、これをさまざまな事業部門の少数のステークホルダー（IT／クラウド運用、アプリケーション・チーム、財務部門からのステークホルダーなど）と共に精査します。アクションを実行し、影響を検証します。一度に一歩ずつ前進し、信頼の高まりに応じて実行するアクションの数を増やします。
  • 承認ワークフロー：次のステップは、ITSMソリューション（ServiceNowなど）で承認ワークフローを実装することです。最適化スケーリング・アクションは、しかるべき所有者の承認や拒否を受けるか、アクションの作成時に考慮されていなかった、または利用できなかった要素に対処するための調整の提案を受ける必要があります（例：「処理するトランザクションの数が来週から倍増する予定であるため、提案されたインスタンス・タイプはこのワークロードには適していません」）。
  • 保守／変更時間帯：スケーリング・アクションを実行するタイミングに関しては、承認されたすべてのスケーリング・アクションを実行する毎週の変更時間帯を定義することから始めます。この変更時間帯の範囲と頻度を徐々に拡大していきます。当社のお客様の多くは、毎日の変更時間帯を利用して非本番ワークロードに対するスケーリング・アクションを実行しています。成熟したお客様は、目標である完全なリアルタイム・オートメーションへすでに移行済みです。
  • 非本番用の予約を購入する：長期の非本番ワークロードの大部分が最適なコンピュート構成に最適化されたら、予約を購入してさらにコスト削減効果を得ることができます。
  • 本番に焦点を合わせる：次に本番ワークロードに取り組む番です。非本番で得られた教訓をすべて生かして、上記のステップに従って本番に適用します。
• リアルタイム・オートメーションを実現する：前述のとおり、成熟したお客様の中にはリアルタイム・オートメーションをすでに実現している企業もあります。そうしたお客様が他社に先駆けてオートメーションを実現できたのは、アプリケーションのモダナイズがすでに完了していたからです（これについては次のセクションで詳しく取り上げます）。

アプリケーション・モダナイゼーションとコスト効率

クラウドに対するスケーリング・アクションは一定の混乱を伴うため、すべてのワークロードが頻繁にサイズ変更できるとは限りません。中には、スケーリング・プロセスの一環として、特定のサービスのグレースフル・シャットダウンが必要なものもあります。クラウドネイティブなアーキテクチャーやPaaSサービスを利用できるようにアプリケーションをモダナイズすれば、アプリケーションに影響を与えることなく、最適化アクションのリアルタイム実行やオートメーションの活用が可能になります。

したがって、企業は継続的な最適化イニシアチブと並行して、アプリケーション・モダナイゼーションに投資し、コンテナやファンクション（つまり、サーバーレス）などのクラウドネイティブ・テクノロジーやPaaSサービスを利用して、コスト効率に優れたアプリケーション・アーキテクチャーを構築することが極めて重要になります。

本ブログ連載記事「クラウド・コスト最適化を極める」の次回は、「クラウドコスト・モデルと割引の概要」がテーマです。ワークロードに合ったクラウドコスト・モデルの利用は、最も効果的なクラウド・コスト削減方法の1つです。次回の記事では、クラウドで利用可能なコスト・モデルおよび割引モデルの概要と利用すべき場合について解説します。

IBM Turbonomicによる自動的かつ継続的なクラウド最適化を通じて、パフォーマンスを維持しながらコストを抑制する方法の詳細については、このリンクをクリックしてください。 →

可能な限り低コストでのアプリケーション・パフォーマンスの確保に向けて、一歩を踏み出しましょう。IBM Turbonomicのデモは、こちらからご依頼いただけます。 →

アセナ・ハーツ（Asena Hertz）

Turbonomicプロダクト・マーケティング担当バイスプレジデント

この投稿は2022年9月21日に米国Cloud Blogに掲載された記事 (英語) の抄訳です。