オンプレミスとクラウド データ ウェアハウスの長所と短所

データ ウェアハウスは、ビジネス インテリジェンス (BI) や分析アプリケーション用に大量のデータを取り込み、保存し、処理するために、あらゆる規模の企業で広く使用されています。データ ウェアハウスは 1990 年代に登場し、成熟した主流のテクノロジーとなっています。しかし、今日データ ウェアハウスを導入しようとしている企業にとって、それをオンプレミスに配置するかクラウドに配置するかは大きな決断の 1 つです。

他の種類の IT システムと同様に、クラウド データ ウェアハウスには、オンプレミス データ ウェアハウスと比較して、容易なスケーラビリティ、優れた柔軟性、データベース管理者 (DBA) の日常的な管理作業の軽減など、さまざまな利点があります。しかし、ビジネスごとにニーズと優先順位が異なるため、データ ウェアハウスの導入を計画する前に、クラウドとオンプレミスのオプションを比較することが重要です。これを支援するために、2 つのアプローチとその長所と短所を示します。

オンプレミスのウェアハウス アーキテクチャとクラウド データ ウェアハウス アーキテクチャ

サーバー、オペレーティング システム、ストレージ、データベースなどの高品質のコンピューティング環境は、大量のデータを使用するアプリケーションの成功に不可欠です。これはデータ ウェアハウスにも当てはまります。最適なデータ ウェアハウス プラットフォームを選択するには、IT チームとデータ管理チームが、コア データベース ソフトウェアだけでなく、システム環境全体を評価する必要があります。

従来のデータ ウェアハウス アーキテクチャは、次の 3 つのレイヤーで構成されています。

• 最下層には、データ ウェアハウス自体が含まれるデータベース サーバーがあります。
• 中間層では、通常、オンライン分析処理 (OLAP) エンジンによって分析用のデータが処理されます。
• 最上位層は、ビジネス インテリジェンスおよび分析ツールのプレゼンテーション層およびフロントエンド インターフェイスとして機能します。

エンタープライズ データ ウェアハウスは、企業のすべての業務オペレーションのデータを集中型プラットフォームに保存します。一方、データ マートは、特定の部門、ビジネス ユニット、またはユーザー グループのデータのサブセットを格納する小規模なストレージ システムです。多くの場合、データ ウェアハウス アーキテクチャには両方とも組み込まれています。以下は、アーキテクチャを設計するための 2 つの主なアプローチです。この選択は、単に Inmon 対 Kimball と呼ばれることもあります。

• トップダウンアプローチ。コンピューター科学者でベンダー幹部のビル・インモン氏によって創設されたこのアプローチは、エンタープライズ データ ウェアハウスから始まり、そこに保存されているデータ セットを使用してさまざまなデータ マートを設定します。
• ボトムアップアプローチ。テクノロジー コンサルタントの Ralph Kimball 氏は、個別のデータ マートを構築し、それを統合してエンタープライズ データ ウェアハウスを作成するという代替アプローチを開発することで、根本的な変化を実現しました。

クラウド コンピューティングでは、これらの従来の概念を使用して、データ ウェアハウス ベンダーが基盤となるハードウェアとソフトウェアのアーキテクチャをカスタマイズし、さまざまな処理要件を満たすことができます。以下に、クラウド データ ウェアハウス製品の代表的な例をアルファベット順に示します。

• 分析とデータ ウェアハウス用の自律型データベース。クラウドでデータを分析するための Oracle の主力システムは、Oracle Database と Oracle Exadata コンピューティング プラットフォーム上に構築されています。このシステムは、共有または専用インフラストラクチャに導入できるほか、Oracle の Cloud@Customer サービスを通じてオンプレミスにインストールすることもできます。 Oracle の共有インフラストラクチャは、より伝統的なクラウド コンピューティング サービスですが、専用インフラストラクチャは、独自のコンピューティング、ストレージ、ネットワーク、データベース リソースを備えた完全にプライベートなパブリック クラウド環境を顧客に提供します。
• Azure Synapse 分析。 Microsoft のクラウド分析サービスは、サーバーレスの専用リソース モデルを提供し、Synapse SQL と呼ばれる分散 SQL 処理エンジンを使用してデータ ウェアハウスに対してクエリを実行します。また、ビッグ データ分析エンジンとして Apache Spark が、データ ストレージとして Azure DataLake Storage Gen 2 も含まれています。このプラットフォームは、複数のノードにワークロードを分散し、コンピューティング リソースをストレージから分離するスケールアウト型超並列処理 (MPP) アーキテクチャに基づいており、顧客は各ノードを個別に拡張できます。
• ビッグクエリ。 Google BigQuery は、ほとんどのデータをテーブルに保存する分散型 SQL ベースの MPP 分析エンジンを備えたサーバーレス クラウド データ ウェアハウスです。各テーブル列は個別に保存されるため、BigQuery は従来の行ベースのストレージよりも効率的にデータセット全体の個々の列をスキャンできます。 BigQuery は、パーティショニングとクラスタリングの両方を使用して、高パフォーマンスのデータ アクセスを提供します。また、マルチクラウド データ ウェアハウスの展開もサポートしており、機械学習、予測モデリング、地理空間分析用のエンジンも含まれています。
• 赤方偏移。 AWS の Amazon Redshift は、クラスターを使用して 1 つ以上のコンピューティングノードをプロビジョニングし、データ ウェアハウス、運用データベース、データ レイクで分析アプリケーションを実行します。 AWS は、サーバーレス オプション、機械学習モジュール、ビジネス インテリジェンス、データ統合、ビッグ データ処理ツールなど、さまざまな他のクラウド サービスとのネイティブ統合を提供します。 BigQuery と同様に、Redshift は各テーブル列を個別に保存します。また、データセットの物理レイアウトを改善することでクラスター全体のクエリ速度を向上させる自動テーブル最適化機能も提供します。
• スノーフレーク。ほとんどの競合他社とは異なり、Snowflake のデータ ウェアハウス システムは、AWS、Azure、Google Cloud Platform 全体で実行されるように設計されています。 Snowflake は、その処理環境を共有ディスク/共有なしのハイブリッド アーキテクチャとして説明しています。この製品は、中央リポジトリを使用して環境全体でデータを共有し、複数の超並列処理 (MPP) コンピューティング クラスターを使用してワークロードを分離します。クラスター内の各ノードは、データ セットの一部をオンプレミスで保存します。完全に管理されたサービスである Snowflake は、データ レイク、データ エンジニアリング、データ サイエンスのワークロードもサポートします。

オンプレミスとクラウド データ ウェアハウスの長所と短所

オンプレミスのデータ ウェアハウスの大きな課題は、企業のデータ アーキテクチャと処理要件を満たすハードウェアおよびソフトウェアのコンピューティング環境を導入する必要があることです。ハードウェア サポート チーム、システム管理者、データベースおよびデータ ウェアハウス ソフトウェア ベンダーが連携してオペレーティング環境を構築しますが、この環境は複雑であることが多く、管理とサポートを行う専任チームが必要になります。さらに、データ ストレージとワークロードの増加に対応するためにオンプレミス システムを拡張すると、コストと時間がかかります。

しかし、クラウド コンピューティング データ ウェアハウスは、企業にいくつかの課題をもたらし、IT プロセスの変更を必要とする可能性もあります。ここでは、いくつかの重要な分野における両方のアプローチの長所と短所について詳しく説明します。

（１）費用

当然のことながら、データ ウェアハウス システムを社内で導入してサポートするコストは、クラウド コンピューティング プロバイダーから従量課金制でデータ ウェアハウス システムをレンタルするコストよりもはるかに高くなります。これは、ベンダーによって完全に管理されるサービスとしてのデータ ウェアハウス (DWaaS) 環境に特に当てはまります。しかし、既存のデータセンターにすでに投資している企業にとって、クラウド コンピューティングとオンプレミス展開のコスト比較はそれほど単純ではありません。

クラウド プラットフォームの本来のセールス ポイントは、IT コストを削減できることでした。しかし、クラウドでアプリケーションを実装する企業は、コスト削減が必ずしもクラウドの主なメリットの 1 つではないことにすぐに気付きます。企業はクラウド データ ウェアハウス システム用のサーバーやソフトウェアを購入する必要がないかもしれませんが、特にデータ ウェアハウスのワークロードが予期せず増加した場合、クラウド ベンダーのコンピューティング、メモリ、ディスク リソースの使用コストが増加する可能性があります。

もちろん、オンプレミスとクラウド プラットフォームを比較する際に IT チームが考慮する必要があるコストはシステム コストだけではありません。環境をサポートするために必要な労働コストも考慮する必要があります。オンプレミス データ センターの場合、これにはコンピューティング ハードウェア、オペレーティング システム、ディスク ストレージ、データベースの管理サポートが含まれます。クラウド データ ウェアハウスではサポート コストが完全になくなるわけではありません。たとえば、DWaaS 環境では、データ ウェアハウスが管理タスクを処理する必要があります。しかし、このコストはクラウドでは通常はるかに低くなります。

見落とされがちな他のコストもあります。パブリック クラウドにデータ ウェアハウスを導入する企業は、コンプライアンス認証、データ センターの環境制御、エネルギー消費、高可用性と災害復旧の構成、システムの改善などに直接かかるコストを負担する必要がありません。これらのコストはクラウド コンピューティング サービスのコストに含まれており、企業にとっては使用コストが高くなる場合もありますが、クラウド コンピューティング プロバイダーが支払います。

（２）新機能

クラウド データ ウェアハウス市場は競争が激しく、クラウド ベンダーは機能セットを最大限に活用する必要に迫られています。自社製品を競合他社の製品と差別化するには、継続的に革新し、新機能を統合することが絶対に必要です。その結果、クラウド データ ウェアハウスのユーザーは、継続的に提供される新機能や機能を活用できるようになります。

さらに、クラウド コンピューティング プロバイダーはデータ ウェアハウス システム全体を担当するため、その顧客は基盤となるコンピューティング インフラストラクチャからデータ ウェアハウス ソフトウェア自体に至るまでの機能強化の恩恵を受けることができます。独自の環境を管理するオンプレミス ユーザーの場合、システムのアップグレードや新しいソフトウェア バージョンの展開はより複雑になります。また、オンプレミスのデータ ウェアハウス ソフトウェアでは、ベンダーによって継続的に更新されるクラウド コンピューティング サービスほど迅速に新機能が利用できない場合もあります。

クラウド プラットフォームのもう 1 つの潜在的な利点: 基本的なビジネスとレポート作成の目的でコア データ ウェアハウス機能を補完するために、大手クラウド コンピューティング ベンダーやその他の競合他社は、データ レイク、機械学習、ビッグ データ分析、データ パイプライン、高度な分析アプリケーションやその他の機能の開発をサポートする追加のテクノロジを提供しています。

（３）スケーラビリティ

システムのスケーラビリティにより、IT チームは処理ワークロードの増加に対応できるようになります。パフォーマンスのチューニングやソフトウェア構成の更新がシステム スループットにプラスの影響を与えなくなった場合は、ハード ディスク、メモリ、コンピューティング能力を追加する必要があります。新しいソース システムが追加されるにつれてデータの増加に対応するために、データ ウェアハウスにとってスケーラビリティも重要です。

しかし、オンプレミスのデータ ウェアハウス プラットフォームを拡張するのは困難な作業になる可能性があります。サーバーに CPU またはメモリを追加する機能がある場合、システム管理者はシャーシを開いてコンポーネントを交換または追加する必要があります。追加の利用可能な容量がないサーバーの場合は、ハードウェアをより大規模なシステムにアップグレードする必要があります。クラスター環境では、サーバーを追加することで水平方向のスケーリングが可能になりますが、ハードウェア、ソフトウェア、および管理のコストがすぐに高額になる可能性があります。

クラウド プラットフォームの主なセールス ポイントの 1 つは、スケーラビリティの容易さです。たとえば、Amazon Redshift ユーザーは、環境にノードをすばやく追加して、パフォーマンスを向上させ、ストレージを増やすことができます。 Oracle Autonomous Database は、コンピューティング リソースやストレージ リソースを自動的に増やすことができる自動スケーリング機能を提供することで、さらに一歩進んでいます。 AWS と Snowflake は、ワークロードの増加に応じてクラスターの容量を自動的に増やす同様の同時実行スケーリング機能を提供します。

（４）パフォーマンスの監視と調整

データ ウェアハウスのパフォーマンスを最適化するために、オンプレミス プラットフォームでは通常、IT チームが個別のツールを使用してハードウェア、オペレーティング システム、データベースを監視する必要があります。クラウド ベンダーは、データ ウェアハウス インフラストラクチャのパフォーマンス監視ツールとアドバイザリ ユーティリティをカスタマイズできるため、これらのツールはオンプレミス ツールよりも包括的な情報を提供することがよくあります。

ただし、標準的なデータベース パフォーマンス チューニングの課題に加えて、クラウド プラットフォームではパフォーマンスの監視とトラブルシューティングに別の側面が加わります。クラウド データ ウェアハウス システムとの間でデータを転送することは、特にデータ量が多く時間が重要な場合には困難になる可能性があります。さらに、クラウド プラットフォーム上にデータ ウェアハウスを実装する企業は、パフォーマンスに対して完全な責任を負うわけではありません。システムのパフォーマンスに疑問があり、スケーリングがオプションまたはソリューションではない場合は、企業はクラウド プロバイダーと協力して根本原因を特定する必要があります。

さらに悪いことに、クラウド データ ウェアハウス システムでは、リソースが過剰に使用されている場合にワークロードが停止する可能性があります。オンプレミスでもクラウドでも、どのデータベース環境でも、適切に調整されていないクエリがいくつかあるだけで、リソースの消費量が増加します。しかし、クラウド コンピューティング リソースの使用率が継続的に増加すると、組織はより高いパフォーマンス層にアップグレードする必要に迫られる可能性があります。

（５）経営管理

オンプレミス環境では、IT 部門がコンピューティング システムを完全に制御し、責任を負います。クラウド データ ウェアハウスでは、企業はこれらの責任をベンダーと共有します。特に、完全に管理された DWaaS 環境では、企業はデータ ウェアハウス プラットフォームの管理の所有権の一部を放棄する場合があります。

一部の IT 部門はこれをメリットと見なし、他の部門はリスクと見なしますが、ほとんどの部門はこれをリスクとメリットの組み合わせと見なすでしょう。大手のクラウド データ ウェアハウス プロバイダーは、最小稼働率を保証するサービス レベル契約を提供しており、これによりシステムの制御を失うことへの懸念を軽減できます。

（６）安全性

同様に、オンプレミスのデータ ウェアハウスを導入する企業は、ハードウェア インフラストラクチャからソフトウェア スタックに至るまで、環境全体を保護する責任を負います。しかし、クラウドでは、セキュリティの責任はプロバイダーと共有されます。企業がセキュリティ責任の 100% をベンダーに委ねているわけではないことを理解することが重要です。クラウド セキュリティの責任共有モデルでは、データ ウェアハウス環境の保護の特定の側面については、引き続き顧客が対応する必要があります。

責任の分担方法はサプライヤーごとに異なる場合があります。また、企業がホスト型 DWaaS 環境を使用しているか、IaaS 環境を使用しているかによっても異なります。IaaS 環境では通常、ベンダーは基盤となる IT インフラストラクチャのセキュリティ保護のみを担当します。ただし、一般的には、IT チームは依然として、データ セキュリティ、データ分類、アクセス制御、エンドポイント デバイスのセキュリティなどのタスクを担当します。

標準的なセキュリティのベスト プラクティスはオンプレミスとクラウドの両方に適用されますが、クラウド データ ウェアハウス システムを使用する企業は、運用環境を保護するためのコストをクラウド ベンダーと分担できます。クラウド コンピューティング ベンダーのセキュリティ機能を活用できることももう 1 つの利点です。クラウド プラットフォームのセキュリティを確保するインセンティブが強く、この点に関して多額の投資を行っています。

（７）監査と規制遵守

前述のように、クラウド データ ウェアハウスの利点の 1 つは、クラウド ベンダーが基盤となるアーキテクチャの責任を負うことです。しかし、これは、社内標準だけでなく業界標準や規制コンプライアンスにも準拠する必要がある企業にとって課題となる可能性があります。

セキュリティと同様に、コンプライアンスは顧客とクラウド コンピューティング プロバイダーの間で共有される責任です。クラウド コンピューティング ベンダーは、多くの場合、HIPAA、GDPR、およびその他のコンプライアンス フレームワークに関するサードパーティ監査コンプライアンス レポートと証明書を提供します。ただし、企業はクラウド コンピューティング ベンダーと連携して、企業固有の監査ニーズに基づいて必要な裏付けとなる証拠を収集し、データ ウェアハウス システムが該当するフレームワークに準拠していることを確認する必要があります。

クラウド コンピューティング サービスを使用すると、必要な証拠を見つけるのに時間がかかるようになるかもしれませんが、企業にとっては、規制遵守コストの一部をクラウド コンピューティング プロバイダーに転嫁することがより重要になる場合があります。