クラウド ストレージの支出に問題があるのは決して良いことではありませんが、問題の存在を認めるという、最初の(難しい)一歩を踏み出せたことは喜ぶべきことです。ここでは、問題の解決策として、文字どおり今日から取り組める実践的な方法を紹介します。以下に挙げる10のヒントは、IT部門を対象としたものがほとんどですが、クラウド ストレージに格納された移動可能なデータの所有者も、このヒントを参考にデータの使用状況をチェックすれば、ストレージの設置面積を削減して、組織の支出を抑制できます。
01. 接続されていないクラウド ストレージを削除する
VMを終了すると、通常はVMに関連付けられたルート ボリュームのみが自動的に削除されますが、追加されたストレージ ボリュームはそのまま残り、ストレージ コストが発生します。場合によっては、誤った削除を避けるため、そのような仕様になっている場合もあります。クラウド コストを削減する簡単な方法は、接続されていないボリュームを見つけて削除することです。使用していないストレージは削除しましょう。ただし、紐付けられていないリソースと同様、これを行うには、検出作業によってストレージの所有者を洗い出し、そのストレージが必要かどうかを本人に確かめなければなりません。データに存在意義があるかどうかは、本人でないとわからないからです。
「ホット」なストレージ階層(通常、アクセス頻度の高いデータを格納しているストレージ)は、「コールド」階層と比べて、料金が5倍もかかることがあります。
02. 適切なストレージ階層を選択する
パブリック クラウド プロバイダからは、さまざまなストレージ階層が提供されているにもかかわらず、誰もが最速の(かつ最も値の張る)階層を選ぶ傾向があります。そこにはコスト意識がほとんど感じられません。料金が高いほどストレージ階層として適切なのでしょうか。そうとはかぎりません。
一般に、階層の1カ月あたりのGB単価は、データへのアクセス頻度とアクセス速度に基づいて設定されており、「ホット」なストレージ階層(通常、アクセス頻度の高いデータを格納するため、低レイテンシ、高パフォーマンスと高スループット、高可用性が求められる)は、「コールド」階層(バックアップやアーカイブなど、アクセス頻度の低いデータに最適な階層)と比べて、料金が5倍もかかることがあります。
ストレージ階層の評価では、必要なパフォーマンスとコストの2つを考慮し、目標とする予算とニーズをバランス良く実現できるかを考えることが重要です。データは後から、別の階層にいつでも移動することができます。
03. 使用率の低いストレージ ボリュームのサイズを最適化する
クラウド ストレージに無駄な費用をかけたければ、最も簡単な方法は、作成したストレージ ボリュームを遊ばせておくことです。クラウド プロバイダは、ストレージ ボリュームのサイズが大きすぎても、縮小するよう言ってはくれません。まずは、必要以上に大きいボリュームがないかを確認し、もし見つかったら、本当に必要なスペースを備えたボリュームを新たに作成し、そこに既存のデータを移行してから大きすぎるボリュームを削除することを推奨します。そうすれば、今後はボリュームを作成する際に、必要なストレージの評価プロセスを適用するだけで済みます。
04. 必要なスループットを基にストレージをダウングレードする
クラウド プロバイダからは、顧客のスループット要件を満たせるよう、さまざまなパフォーマンス階層も提供されています。ボリュームごとに実際の読み取り / 書き込みアクセスを監視し、スループットが低いボリュームが見つかったらパフォーマンス階層をダウングレードすると、ストレージ コストを削減できます。ストレージのIOPSもワークロードに適した値に低減するので、併せてコスト削減に貢献できます。
05. ストレージに必要な冗長性のレベルを考える
データをどこにでもレプリケートできると伝えると、なぜかお客様は冷静さを失い、はるか遠くの場所を選びがちです。しかし、米国のデータを、たとえばハリケーンによる損失から保護するためにイギリスにレプリケートする必要が本当にあるでしょうか?答えはもちろん「ノー」です。超大型ハリケーンに備えるためだとしても、そこまでする必要はありません。こうした選択はコストにも影響します。たとえば、地理的にまったく異なる地域間で冗長構成を組むと、同じ地域内で組む場合と比べて費用が2倍になる場合があります。ビジネスへの影響とリスクを評価したうえで、本当に必要な冗長性のレベルを見極め、必要な冗長構成計画を賢く考えることが重要です。
容量とスループットを基に適切なストレージ階層を選択し、使用量がピークになる時期のみ上のストレージ階層に移動すれば、月々のクラウド料金を最大70%削減できます。
06. 古いスナップショットを削除する
仮想マシンのリカバリ戦略に、スナップショットは欠かせません。スナップショットがいくつも取得されていれば、ディザスタ リカバリの際に特定の時点のデータをリストアできます。ワークロードの所有者が必要としているものを消去してしまうのは、絶対にやってはいけないことですが、VMが何百もある環境で、前日のスナップショットが削除されないまま、それぞれのVMで日々スナップショットが作成されていては、クラウド ストレージの費用が膨らむ一方です。スナップショットの有効期限に関する戦略が必要です。幸い、大半のクラウド プロバイダには何らかのスナップショット ライフサイクル管理ポリシーがあり、それに基づいてスナップショットが自動で削除されるので、1人の管理者だけに頼る必要はありません。
07. アウトバウンド データ転送のリクエストを管理する
データ移動にお金がかかるのは事実です。ただし、すべての場合で同じように費用が発生するわけではありません。クラウドの場合、データ転送費はソースとデスティネーションのクラウド サーバの場所によって異なります。通常、インバウンド トラフィックは無料(または、ほぼ無料)ですが、クラウド プロバイダのネットワーク外にデータを転送すると(データ エグレス)、たちまち料金が跳ね上がります。また、忘れてならないのは、データの所有者としては、データ転送は「必要だから行う」のであって、「どうすればコスト効率よく行えるか」は関係ないということです。この問題に対処するには、実際に使用する場所のできるだけ近くにデータを格納するよう所有者に勧めて、データを別の場所に移動する必要性をなくすことです。さらに、データ移動の前に圧縮や重複排除を実行し、差分のみの同期を利用すれば、転送コストを抑えられます。最後に、データの削除やアーカイブ階層への移動が可能なら、積極的に行うことを推奨します。
08.リージョン間やゾーン間のデータ転送を最小限に抑える
データを別のリージョンや別の国、別のアベイラビリティ ゾーンに移動すると、クラウド プロバイダから追加料金を請求されます。アプリケーションのアーキテクチャには、DevOpsがテスト データの維持に使用できるよう、こうしたデータ転送が組み込まれている場合があります。冗長性戦略の一部に組み込まれている場合もあります。そのためデータ転送には、明確な目的と承認の両方が必要です。必要なデータは、できるだけユーザベースと地理的に近い場所でホストするよう心がけてください。長期的には、ソリューションのアーキテクチャを見直して、データ移動の経路を最短化することを検討すると良いでしょう。
09. ストレージの料金設定を確認する
ストレージとデータ転送の料金設定には、どちらも、消費量に基づいて料金が追加されるプランが含まれていることがよくあります。クラウド プロバイダの料金表の一定レベル(「<ストレージ量>を超えている場合」などと示されています)に達していたら、よりお得な料金プランを交渉できるかもしれません。ただし、大幅割引が適用されるのは、料金設定要件を満たしたデータに限られるので注意してください。最後に、複数年契約に縛られている可能性はありませんか。契約期間に縛りがあると、月日の経過とともに使用量が増えて、よりお得な契約を交渉したいと思っても、期間中は別の契約に切り替えられないので、これも注意が必要です。
「四半期あたりの節約額は数十万ドルに上ります。場合によっては、クラウドベースのアーキテクチャの設計方法を検討するだけで、1カ月あたり10万ドルを削減できます」
10. 完了しなかったアップロードをストレージから削除する
ワークロードの中には、ユーザがファイルをアップロードしなければならないものがあります。その際、アップロードが途中で停止すると、オブジェクトの一部が使用不可能なデータとしてクラウド ストレージに残り、それが原因で料金が発生することがあります。サイズによっては、不完全なアップロードのために取り残されたデータの破片が、積もり積もって大量になる場合もあります。これは管理者に、不明なデータの削除や移動を避ける傾向があるからです(ステップ6を参照)。対処としては、アップロードが完了しなかった場合は、バックアップしてから削除する方法を推奨します。