クラウド アプリケーションの経済性
CSP は、従来のデプロイからユーザーを引き込むために多大な労力を費やしています。 パブリック IaaS クラウドの価格は、サービスの開始以来、着実かつ急激に低下しています。 平均して、ほとんどの主要な CSP の価格は、2013 年以降、年間 20% から 30% 低下しています。
ただし、このように価格が低下したとしても、クラウドの導入は依然として慎重に行う必要があります。 本当の意味でクラウドのコスト メリットを得るには、使用状況を把握し、予算を立て、計画し、監視し、慎重に分析することが重要です。 また、CSP がリソースをパッケージ化するための標準的な方法は存在せず、常に同じ価格モデルに従っていないため、個別のユース ケースに合わせて CSP を選択することは困難です。
価格モデル
通常、クラウド プロバイダーは、次の 3 つの種類のパラメーターのいずれかに基づいてリソースに課金します。
- 時間ベース: リソースは、ユーザーにプロビジョニングされた時間に基づいて課金されます。 たとえば、時間、日、月、年あたり一定の料金を支払って仮想マシンを IaaS クラウド上で実行するとします。 課金期間の細かさは、クラウド プロバイダーによって異なります。 たとえば、Amazon では、日割りではなく時間単位でユーザーに課金します。
- 容量ベース: ユーザーには、使用または消費された特定のリソースの量に基づいて課金されます。 これは、クラウド ストレージ システムの一般的な課金モデルです。 たとえば、Azure Blob Storage などのクラウド オブジェクト ストレージ システムに 1 ギガバイトを格納する場合、ユーザーには一定の金額が課金されます。
- パフォーマンスベース: 多くのクラウド プロバイダーでは、ユーザーがより高い料金を支払うと、リソースに対してより高いパフォーマンス レベルを選択できます。 仮想マシンの場合、より多くの CPU、メモリ、およびディスク容量を備えたより大規模でより強力なマシンをより高い時間単位でプロビジョニングできます。
このような課金パラメーターに基づいて、CSP では次の一般的な価格モデルのいずれかが使用されます。
- オンデマンドおよび従量課金制の価格: 通常、これは長期的な使用のための最もコストの高い価格モデルです。 支払いはごく短時間の使用に対して行われます (通常、分単位または時間単位で計測されます)。 利点は、長期契約の必要がないため、現在のニーズに基づいてスケールインとスケールアウトを非常に柔軟に実行できることです。 一般的ではありませんが、CSP は高需要時にはコストを上げ、低需要時にはコストを下げる可能性があります。 これは、サービス プロバイダーだけでなく、クラウドを使い始めたばかりのクラウド ユーザーにとっても優れたモデルです。
- 予約インスタンスとサブスクリプションベースの価格: ユーザーは、時間単位または分単位の料金を支払うのではなく、前払いして、非常に長い期間 (数週間から数か月間) にわたってリソースを予約することを選択できます。 これは、多くの場合、大幅な値下げ (20% から 50%) につながりますが、長期的なコミットメントが必要です。 予約型価格モデル内の支払い方式は、前払いから、契約上義務付けられた定期的な支払いまでさまざまです。
- スポット価格: スポット価格は、CSP が、過剰な未使用の容量を、オンデマンド リソースよりも大幅に低価格で販売するように提供することで対処する方法です。 価格はユーザー オークションによって決定されます。ユーザー オークションでは、ユーザーがリソースに対して支払うことができる最高金額を入札します。 最大の欠点は、スポット価格が実際の入札価格を超えた場合、いつでもリソースが終了される可能性があることが多いことです。 スポット リソースは、投機的に実行できる重要ではない短時間のジョブに最適です。
通常、予約インスタンスは、システムの基本要件を満たすために使用する必要があります。 80% の時間に 2 つのインスタンス、15% の時間に 3 つのインスタンス、5% の時間に 4 つのインスタンスが必要なアプリケーションの場合、通常、アプリケーションの有効期間中に 2 つのインスタンスを予約し、オンデマンド インスタンスまたはスポット インスタンスを使用してスケールアウトします。 前述のように、ビジネスに不可欠なアプリケーションである場合、またはオンデマンド価格と現在のスポット価格の差が突然終了するリスクと相殺される場合にのみ、スケールアウト中にオンデマンド インスタンスを選択するようにします。 この判断は、多くの場合、ビジネス ケースに固有のものです。
コスト使用率を最適化する方法
企業がコスト効果の高い方法でクラウドを使用するには、デプロイ、監視、および使用状況の視覚化を行うリソースを選択する成熟したプロセスと、無駄を特定して使用率を最適化する明確なメカニズムを開発する必要があります。
図 11: コストの最適化プロセス
組織は、コスト要件を検討する前に、在庫管理、輸送によるオーバーヘッド、資材処理などの物理的制約に対処しながら、スタッフ数などの固定リソースに基づいて、一定期間に完了することができる作業量を計画する必要があります。IT リソースのプロビジョニングは、組織の物理的な容量を満たすか、超えるように設計する必要があります。 これは非常に重要です。クラウドで提供される弾力性があるので、開発チームは、意思決定によるコストへの影響を考慮することなく、単純に必要に応じてリソースを追加できるからです。
クラウドにかかる費用を削減する最初の手順は、リソースの種類をアプリケーションの実際の要件と一致させることです。 これは、異なるメモリ構成またはコア数の VM のどちらを選択するかを意味する場合があります。 さまざまなリソースの種類でアプリケーションのテストとベンチマークを行う以外に、それを簡単に実行できる方法はありません。
よりコストの高いリソース クラスでアプリケーションのパフォーマンスが向上しても、パフォーマンスの向上がコストの増加に比例するかどうかを確認することが重要です。 たとえば、ベースの 7.5 倍のコストがかかる VM を使用するアプリケーションで 1.2 倍の向上が見られる場合は、ベース リソースを水平方向にスケールアウトしてパフォーマンスを向上させる方が理にかなっている可能性があります。
使用されているさまざまなリソースを監視する監視および視覚化システムを構築することが重要です。 監視システムは、観察された過負荷またはアイドルのパターンに応じてスケーリング イベントをトリガーするように設計する必要があります。 多くの場合、インフラストラクチャ チームは積極的にスケールアップまたはスケールアウトを選択しますが、スケールダウンまたはスケールインの選択はより保守的です。 この方法はリソース プロビジョニングの点ではよりコストが高くなりますが、理論的には常にピーク容量近くで稼働するよりも高いサービス品質を実現できます。
ただし、多くの場合、組織は使用頻度の低いリソースをスケールダウンして終了する必要性を過小評価します。 アプリケーションのさまざまなコンポーネントの実行を計画する際には、おおよその使用期間に基づいて、使用率を異なるビンに分類することが重要です。 たとえば、夜間または週単位で短時間実行されるジョブには、リソースを 24 時間 365 日使用しないようにします。 また、アイドル状態のリソースには、監視システムによって (特定のルールに基づいて) フラグを付けて終了するようにします。
コスト最適化に結びつく重要な手法は、リソースにタグを付けることです。 タグ付けは、監視および分析ツールで識別できるラベルをリソースに割り当てるプロセスです。 タグ付けを使用すると、リソースへのアクセス制御リスト、課金アラート、特定のスケーリング ポリシーなど、カスタム ルールをタグごとに定義することもできます。 よく使用されるタグでは、特定のリソースの所有者 (ユーザーまたはグループ)、それが属する環境 (たとえば、運用、バックアップ、ステージング、テスト)、請求の支払いを担当するコスト センターなどを指定します。これにより、費用を分析する際に、特定のアプリケーションや特定の開発チームやテスト チームに基づいてグループ化されたビューを生成できます。