世界のクラウド支出は2023年に6,000億ドル規模に到達する見通しで、前年比21%の成長が見込まれています。クラウドが世界経済にいかに浸透しているかが分かる数字です。クラウドを前提に生まれた企業(デジタルネイティブ)は増え続け、ビジネス拡大の最大の価値と機会はパブリッククラウドにあると判断してクラウド移行を進めてきた企業の仲間に加わっています。
企業の規模を問わず、成長に伴ってクラウド環境の規模もそれに応じた支出も拡大していきます。事業がスケールすればインフラコストも上がるのは自然なことです。成功の鍵、そしてFinOpsの実践に長けた組織であることの証は、ビジネスニーズに見合った形でクラウドフットプリントを成長・拡張させ、それ以上は広げないことにあります。その大部分を占めるのが、節約のチャンスを活かして可能な限り支出を最適化し、不要なコストを抑え込む取り組みです。
とはいえ、クラウド環境は動的で複雑なため、言うほど簡単ではなく、クラウド支出をコントロール下に置くには専門知識と地道な努力の両方が欠かせません。そこで本記事では、AWSコスト最適化に着手する、あるいは既存の取り組みを強化するうえで押さえておきたい3つの領域をご紹介します。
commitment割引のカバレッジを引き上げる
EC2をはじめとするコンピュートサービスは、クラウド請求額全体の50〜70%を占めるケースが多く、ここを抑えることが大幅な節約に直結する最大のチャンスです。AWSはSavings PlansとReserved Instancesという2種類のリソースcommitment割引を用意しており、いずれも1年または3年契約で購入できますが、買い戻しや柔軟性の面で重要な違いがあります。
各commitmentタイプの違いはこちらで詳しく解説していますが、実際のところcommitmentsを管理し節約効果を最大化する作業はフルタイムの仕事に匹敵します。コンピュート使用量を予測する際には、マシンタイプ、リージョン、クラウドサービスなど複数の要素を考慮したうえで、利用状況や有効期限を追跡し、適切なタイミングで判断していく必要があります。
commitmentカバレッジを最大化する最善の方法は、できる限り多くのworkloadsを3年契約のRIまたはSavings Plansでカバーすることです。1年契約の割引が25〜35%なのに対し、3年契約は60〜70%もの割引が得られます。ただし当然ながら、3年契約は1年契約と比べて本質的にリスクが高くなります。それだけ先のworkloadsを見通すのははるかに難しいからです。十分な成熟度と安定性を備えた企業であれば、予測されるworkloadsの約半分を3年契約でカバーし、残りを1年契約で補うやり方が有効でしょう。
DoiT Flexsave™のようなソリューションが優れているのは、まだ割引が適用されていないオンデマンドのコンピュートworkloads(EC2、Fargate、Lambdaを含む)について、1年契約の管理を自動化して節約効果を最大化してくれる点です。FinOpsの管理負担が軽減されるだけでなく、結局使い切れないリソースに過剰commitしてしまうリスクも回避できます。
Flexsaveは、既存のSavings Plansの全体像と割引カバレッジの分析をダッシュボード上に直接表示し、AWS commitment戦略のFinOpsハブとしても機能します。グラフには既定で利用頻度の高い上位10個のSKUのカバレッジが表示されますが、より多くのSKUを確認したい場合やリージョン別に分解して見たい場合は、ダッシュボードから直接Cloud Analyticsレポートを開けばOKです。そこから、割引対象外となっているサービスを把握し、該当workloadsを再設計して節約効果を高める余地がないか検討できます。
Flexsaveダッシュボードの使い方については、下の画像をクリックしてご覧ください。
Spot Instancesを活用する
Savings PlansやRIと同じく、Spot Instancesもオンデマンドのコンピュートworkloadsに大幅な割引をもたらしますが、見過ごせない注意点があります。Spotのworkloadsは、わずか2分前の通知でAWSによって回収される可能性があるのです。最大90%もの割引でSpot Instancesからさらに大きな節約効果を引き出せる一方で、リスクも一段と大きくなります。そのため、コンテナ化されたworkloads、ステートレスなWebサーバー、テスト環境、ビッグデータアプリケーションなど、フォールトトレラントな処理に限って使うのが基本です。
Spot InstancesはAWS上でAuto Scalingグループ(ASG)を使って管理できますが、利用にあたっては、要求するインスタンスタイプやアベイラビリティゾーンに一定の柔軟性が求められます。なぜでしょうか。狙ったスペックではどれも確保できない可能性があるからです。さらにASGは、コンピュート需要を大きな中断なく安定的に満たせるよう、手動で設定し定期的にチューニングしなければなりません。手作業で煩雑なうえ、設定を誤れば、そもそも動かないこともあります。
こうしたリスクと手間を踏まえ、Spot Instancesに手を出すこと自体を見送る担当者も少なくありません。しかしDoiT Spot Scalingを使えば、このプロセスを自動化して中断リスクを取り除き、Spot Instancesでworkloadsを安定的に動かせるようになります。ASGを自動的に分析してベストプラクティスに沿った構成を推奨し、適用可能な場合はオンデマンドインスタンスを大幅割引のSpot Instancesに置き換えてくれます。さらに、市場にSpotキャパシティがない状況ではオンデマンドへフォールバックする仕組みも備えており、リスクを抑えられます。
Spot Scalingの実際の動きは、下の画像をクリックしてご覧ください。
ストレージを監査し最適化のチャンスを見つける
毎月のクラウド請求額に占める割合はコンピュートほどではないものの、ストレージコストはスケールに伴って一気に膨らむことがあるため、コストを最小限に抑えるには定期的な監査が欠かせない領域です。AWSはデータへのアクセス頻度に応じて価格が変わる複数のストレージクラスを用意しています。つまり、参照頻度が下がったオブジェクトでも、Infrequent Accessやさらに低頻度のGlacierに移せばよいのに、依然としてS3 Standardに置かれたままになっているケースが起こり得るのです。
ストレージクラスのコスト効率を最大化するには、ライフサイクルポリシーを使い、アクセスパターンに応じてデータを別のストレージクラスへ自動で移行させると効果的です。取得料金や転送料金はGB単位で課金されるため、オブジェクトの数とサイズも必ず合わせて考慮しましょう。また、Amazon S3 Selectを使ってS3オブジェクトから必要なデータだけを取り出すようにすれば、転送データ量の削減も期待できます。
もう一つ覚えておきたいのは、小さなオブジェクトが大量にあるとコストが一気に膨らみやすいという点です。極小ファイルが多い場合は、S3ではなくDynamoDBやMySQLのようなデータベースサービスに格納するほうが合理的なこともあります。それが難しい場合は、まとめて1つのファイルにして保存することも検討してみてください。
DoiT Cloud Analyticsは、コスト配分のグルーピング機能を活用し、サービス、SKU、アベイラビリティゾーンなどの切り口でコストを分解することで、何がコストを押し上げているのかをすばやく可視化し、こうした分析を後押しします。
これらのCloud Analytics機能がDoiT Cloud Navigatorの中でどのように動くのかは、下の画像をクリックしてインタラクティブなツアーでご確認ください。
