エラスティックコンピューティングとは何か?エンタープライズガイド

主なポイント

• エラスティックコンピューティングは需要の変動に応じて計算、メモリ、ストレージを動的にスケールさせ、手動の管理介入を排除します。
• 需要が減少した際に使われていないリソースをデプロビジョニングすることは、スケールアップと同じくらい重要です。スケールダウンの効率はクラウドコスト削減を直接決定します。
• 「エラスティックコンピューティング」と「クラウドエラベシティ」は同じ運用能力を指し、エンタープライズクラウドアーキテクチャ全体で同義的に使われます。
• Elasticityは、バースティ、季節的、アドホックなAIや分析ワークロードに対して最大のROIを提供します。連続的で定常状態のレポート作業は、はるかに少ない恩恵を受けます。
• ハードスケーリング制限、リアルタイムテレメトリー、部門ごとのコスト帰属がなければ、動的自動スケーリングは管理されない運用コストを生み出します。

弾力的計算の定義

従来のエンタープライズ容量計画は静的な予測に依存しています。インフラチームはピークのリソース需要を見積もり、そのピークをカバーするための物理ハードウェアや予約されたインスタンスを購入し、オフピーク時のアイドル容量の財務コストを吸収します。

エラスティックコンピューティングは静的予測を継続的な運用フィードバックループに置き換えます。クラウドプラットフォームはアクティブなワークロードのテレメトリを監視し、リアルタイムでリソースのプロビジョニングまたはデプロビジョニングを行います。

真の弾力的計算と静的リザーブインフラを区別する2つの特徴があります。

• 自動化: 資源の調整はリアルタイムの利用トリガーに基づいてプログラム的に行われ、人の介入は一切必要ありません。
• 双方向性: クエリの同時進行が減少すると自動的に容量が縮まり、変動するクラウドインフラコストを直接抑制します。

クラウドデータウェアハウジング、データレイクハウス、エンタープライズ分析において、このアーキテクチャ的特性はクラウドの弾力性とも呼ばれます。両用語は、計算供給とリアルタイム処理需要をマッチングする基盤的なメカニズムを表しています。

弾力計算の仕組み

実際にスケールするもの

エンタープライズのデータプラットフォームやAIアーキテクチャにおいて、弾力性は3つの異なるインフラ層にまたがり、それぞれ異なる速度で調整されます。

• Compute: 分離された仮想ノードや実行クラスタを通じてプロビジョニングされる処理能力。Computeは調整が最速のレイヤーであり、ワークロードの急増を管理する主要なダイヤルとして機能します。
• メモリ: 計算インスタンスと並行してスケールするシステムRAMは、複雑な解析結合、高並行ベクトル探索、分散型機械学習アルゴリズムの運用ボトルネックとなることが多いです。
• ストレージ: 現代のクラウドデータアーキテクチャでは、 共有オブジェクトストア層を活用し、計算とストレージを分離しています。この分離により、Teradataデータベース内の基盤データセットを物理的に移動したり再分割したりすることなく、計算資源が動的に拡張・収縮できます。

スケーリングイベントを引き起こすもの

スケーリングアクションは、システムレベルのモニタリングエンジンによって制御され、あらかじめ定められたポリシーの閾値に対して運用指標を追跡します。一般的な運用トリガーには以下が含まれます:

• 定められた制限を超えた持続的なCPUまたはノード利用率(例:3分間の利用率85%)。
• 予期せぬトラフィックの急増時のクエリキュー深度の増加や同時実行制限。
• ストリーミングデータ取り込みパイプラインやリアルタイムAPIリクエストの急増。
• 高並行性モデルスコアリング、特徴工学、またはTeradata Databaseのデータベース内分析機能を通じて開始される エージェント的ワークフロー 。

エンタープライズプラットフォームでは、システム管理者が明確な上限および下限閾値を設定でき、自動スケーリングが事前承認されたパラメータ内で厳密に動作するようにします。

スケールダウンは難しい半分です

需要急増時の容量拡大は簡単です。縮小はクラウド経済的ROIの勝敗を左右します。計算ノードが過度にデプロビジョニングを行うと、その後のクエリバーストでコールドスタート遅延が発生します。実行完了後もノードがプロビジョニングされたままであれば、期待されるクラウドコスト削減はすぐに消えてしまいます。

84%の経営幹部がクラウド支出管理を主要な運用上の課題と挙げているため、効果的なノードのテイクダウンポリシーは極めて重要です。インスタンスプロビジョニング、ノードテラダウン、ワークロード分離の詳細な運用概要については、 About Teradata Elastic Compute のドキュメントをご覧ください。

弾力計算の実践例

グローバルな小売組織が、日々の取引量に対応したエンタープライズ分析を運用している例を考えてみましょう。年次プロモーションイベント中は、サプライチェーン、マーケティング、在庫、顧客体験チームが同時にアドホックな分析クエリを実行するため、同時ユーザートラフィックが10倍に増加します。同時に、自動化された推薦モデルはオフピークの夜間バッチではなく連続的に実行されます。

弾力的計算がなければ、企業は二つの高額な選択肢に直面します。

• 過剰供給: ピークのプロモーションボリュームに合わせてインフラを恒久的にサイズ化すると、標準営業週中に最大70%の計算容量がアイドル状態になります。
• 供給不足: 中央値の日々需要に合わせてインフラを拡大すると、クエリキューのタイムアウト、ポータルのパフォーマンス低下、ピーク時のプロモーション時間帯の収益損失の可能性が招かれます。

しかし、弾力的なクラウドアーキテクチャでは、クエリの並行性が増えると独立した計算クラスターが自動で外側にスケールし、ピーク時にはスループットを維持し、トラフィックが正規化されると自動的に終了します。企業は稼働中の稼働時間のみ、計算容量の増加に対して料金を支払います。

弾力性とスケーラビリティは同じものではありません

しばしば同義語として使われますが、スケーラビリティと弾力性は根本的に異なる工学的目標を扱っています。

システムは弾力的でなくても高いスケーラブル性を持つことができます。 オンプレミスのデータウェアハウス はしばしばペタバイト単位のストレージにスケールしますが、計算容量を増やすにはハードウェアの取得と恒久的なインストールが必要です。

包括的な比較分析については、 クラウド弾力性とクラウドスケーラビリティに関する詳細なガイドをご覧ください。

弾力的計算が活かすところ

• バースト的かつ予測不可能なワークロード: ベースラインとピークのリソース需要に大きなばらつきがある場合、組織はオンデマンドの計算割り当てを実装することで即座に財務的リターンを得られます。
• データサイエンス、AI、モデルトレーニング:機械学習モデルの訓練、検索拡張生成(RAG)ベクトル探索の実行、アドホックのデータサイエンス探索は、限られた時間で大量の計算を必要とします。エラスティック計算クラスターは、チームが専用ノードを起動して実行し、完了するとすぐにスピンダウンできるようにします。
• 季節的およびイベント駆動型の処理: 月次財務取引のクロージング、四半期ごとの規制申告、プロモーション的な小売販売は予測可能な急増を生み出し、恒久的なハードウェア拡張よりも動的配分で対応するのが最適です。これらのパターンは昨年の数字にもすでに記録されており、最も弾力性のあるケースとして正当化しやすいです。

企業の考慮事項

コスト予測可能性とガードレール

最近の企業調査によると、パブリッククラウドのインフラ支出の29%が無駄に失われており、これは主に管理されていない計算スケーリングやアイドルな開発者環境によって引き起こされています。予算の予測可能性を維持するために、FinOpsチームは明確なインフラのガードレールを強制しなければなりません。消費ベースの クラウド価格モデル は支出を可視化し、 ワークロードレベルのコスト見積も りは、プロビジョニング前に特定の構成が実際にどれくらいかかるかを示します。

これらのインフラをガードレールと考えてみてください。

• 定義されたスケーリング範囲: クエリ異常時の計算費の暴走を防ぐため、自動スケーリングインスタンス作成の厳格な上限と下限を設定します。
• リアルタイムテレメトリとアラート: スケーリングイベントのログを記録し、プラットフォーム管理者がリソース拡張がなぜトリガーされるのかを即座に把握できるようにします。
• コストの帰属とショーバック: 部門、プロジェクト、事業部門ごとに動的計算インスタンスにタグ付けし、財務責任を強制します。

ガバナンスとアクセス制御

制御されない自動スケーリングは運用上およびセキュリティ上のリスクを生み出します。エンタープライズクラウド展開はロールベースアクセス制御(RBAC)を強制し、データ暗号化ポリシーを動的計算クラスター全体に自動的に拡張し、すべてのスケーリングイベントを記録してコンプライアンス監査を行う必要があります。

弾性が間違った答えである場合

エラスティックコンピューティングはすべてのエンタープライズワークロードプロファイルに通用するソリューションではなく、こうしたシナリオでは意味をなさないかもしれません。

• 予測可能なベースライン処理: 一定かつ高い利用率で動作するコア エンタープライズデータウェアハウスクエリ は、専用の予約済み計算容量ではるかにコスト効率よく動作します。
• 超低遅延SLA: 新しい計算ノードを起動するために必要な短い初期化遅延に耐えられないワークロードは、事前に割り当てられた常時稼働のインフラストラクチャが必要です。
• ストレージまたはI/Oにバウンドするボトルネック: ネットワークスループットやストレージディスクI/Oによってボトルネックに陥ったアプリケーションにコンピュートクラスターを追加しても、実行速度は向上しません。

専用のベースラインインフラと動的計算の間の構造的なトレードオフを評価するために、私たちの『 The Always-On Reality』の分析をご覧ください。

テラデータ上の弾力的計算

現代のエンタープライズデータアーキテクチャは、予測不能で高同時進行の分析と並行して定常状態のビジネスレポートをサポートしなければなりません。 Teradata Cloud は、両方の計算モデルを単一のワークロード管理フレームワークの下で統合しています。

• Teradataアクティブコンピュート: 予測可能なエンタープライズデータウェアハウジング、運用レポート、コアマdashboard作成のための常時オン専用コンピュートノードを安定したレートで提供します。
• Teradataの弾力的計算: 探索的データサイエンス、アドホック部門分析、AIモデル実行のための動的かつオンデマンドの計算クラスタースケーリングを提供します。これらの孤立したクラスターは、基盤となるオブジェクトストレージ(IcebergやDeltaなどのオープンテーブル形式を含む)から独立してスケールし、ワークロードが終了すると自動的にデプロビジョニングされます。

統合ワークロード管理の下でアクティブ計算と弾力計算を調整することで、エンタープライズ組織はリソース競合を排除し、厳格なコスト上限を維持し、インフラの過剰供給を避けつつ継続的な分析を可能にします。

AWS、Microsoft Azure、Google Cloudにまたがるプラットフォームのどこにでも同じワークロード管理が適用されます。

結論

エラスティックコンピューティングは、現代企業がクラウド分析の設計と支払い方法を再定義しました。リアルタイムで計算供給と処理需要を動的にマッチングすることで、組織は一時的な使用急増のために高価なインフラを過剰に配置する必要を排除します。しかし、クラウド弾力性の真の財務的利益を捉えるには、意図的な運用ガバナンスが必要です。厳密なスケーリング上限、リアルタイムテレメトリー、明確なコスト帰属がなければ、自動スケーリング機能はクラウド支出の無駄を急速に悪化させる可能性があります。

最も効果的なエンタープライズデータ戦略は、弾力的スケーリングと専用のベースライン計算を組み合わせ、バースティ分析やAIワークロードを必要に応じてスケールさせ、定常状態レポートを最大コスト効率で予測可能に実行させることです。

クラウドデータアーキテクチャの最適化は準備できていますか?

スケーラブルでコスト管理されたデータ基盤を構築する

Teradata Autonomous Knowledgeプラットフォーム上で、予測可能なエンタープライズワークロードと動的かつオンデマンドのスケーリングをバランスよく行う方法を発見しましょう。Teradata Cloudを探索するか、「About Teradata Elastic Compute」ドキュメントをご確認いただき、コスト管理が抑えられ、高スケーラブルなデータインフラを構築しましょう。

よくある質問