クラウドネイティブアーキテクチャで、どこでも拡張可能なデータ分析を実現

Kubernetesを用いたアーキテクチャ設計は、データ分析を非常に柔軟にし、ビジネスニーズのある場所ならどこでも、大規模かつ高並行性、高性能、高効率、高可用性で実行できる不可欠な核心要素です。

金融サービス、保険、製造、ヘルスケアなど多様な業種の数千の企業が、パブリッククラウド、プライベートクラウド、ハイブリッド、エッジ展開を組み合わせてデータ管理と分析のニーズに対応する必要性を認識しています。したがって、分散クラウドの概念がクラウドの成熟の一部となっていることは驚くべきことではありません。データウェアハウス、データレイク、高度な分析を分散クラウドアーキテクチャに導入することは、市場の向かう先です。このアーキテクチャをより高度なデータ管理・分析サービスに拡張することは、自然と「分散データクラウド」の概念へとつながります。分散データクラウドでは、エンタープライズデータウェアハウスが社内の数百人のアナリストやデータサイエンティスト向けの分析提供にとどまらず、数万単位のエンドカスタマーが直接利用するリアルタイム分析アプリケーションを支えるまでになります。データはどこでも即座にアクセス可能になり、インサイトを生み出します。

関連記事: 2021年のクラウド導入トレンド、2022年に加速

目的地の探求

「クラウドネイティブ」はよく使われる言葉ですが、ソフトウェアアーキテクチャが分散クラウドの利点を活かすためにゼロから設計されている場合、それは実質的な意味を持ちます。完全に実現されたクラウドネイティブデータウェアハウスは、論理的に分散データクラウドアーキテクチャを活用すべきです。広い意味では、それはデータが存在する場所に分析をもたらし（逆ではない）、集中リスクを軽減し、効率を劇的に高め、コスト管理と競争優位性のためのモダナイゼーションを推進します。

より具体的に言うと、クラウドネイティブなデータ管理・分析テクノロジーは、分散データクラウドの青写真に沿うために以下の5つの重要な特性を備えるべきです。

• どこにでもデータと分析をプロビジョニングできるプラットフォームに依存しないランタイム
• どこでも共通のユーザー体験
• あらゆる展開ターゲットで共通のセキュリティとガバナンス機能
• どこでもコストと技術の効率性、リソースを最小限に抑え、強力なコスト管理（FinOps）と支出ガードレールを実現
• パブリッククラウド、オンプレミス、ネットワークエッジのすべての展開を統合する単一のコントロールプレーン

必要な場所に展開可能な、完全に実現されたクラウドネイティブデータウェアハウスは、クラウド、オンプレミス、ネットワークエッジのインフラの複雑さをエンドユーザーから隠蔽します。目的は、彼らをインフラの詳細から解放し、分析から価値を生み出し、データを管理することに集中させつつ、クラウドのネイティブな力を提供することです。

適切なガイドの選択

では、どうすればその目的地に到達できるのか？ オープンソースのコンテナオーケストレーションツールであるKubernetesが、クラウドネイティブ運用への最も一般的な道筋を提供します。Unixでのワークロード分割のアイデアは1970年代からありましたが、コンテナが広く実装され、アプリケーション開発をより容易に、ポータブルに、リソース効率よくしたのは約10年前のことです。しかし、数百、数千のアプリケーションを巨大なマイクロサービスアーキテクチャ全体に展開することは極めて困難でした。他の選択肢もありますが、GoogleのオープンソースKubernetesプロジェクト（現在はCloud Native Computing Foundationが管理）がマイクロサービスアプリケーションのオーケストレーションを解決するために台頭し、アプリケーションを汎用インフラで実行し、標準的な方法で監視・管理し、オープン標準で認証できるようにしました。

これはアプリケーションには良いことですが、データの世界ではどうでしょう？ クラウドネイティブデータウェアハウスが、パブリック/プライベートクラウド、ネットワークエッジ、ハイブリッド、完全分散クラウド全体で弾力性と展開の柔軟性を提供するには、同じ基盤となるコンテナオーケストレーションが必要です。

スケールアウトWebアプリケーションのクラウドネイティブ再アーキテクチャは一般的ですが、データベースはほとんど「リフト＆シフト」でクラウドネイティブの世界に移されただけです。データベースをコンテナに入れるだけではモダンインフラで動作しますが、クラウドのすべてのメリットを示す体験にはなりません。ソフトウェアはコンテナ環境で動いていることをほとんど認識せず、エルゴスなクラスタ管理などの操作は、OperatorやHelmチャートのハックを使ってデータベースの外部から手作業で不格好に処理しなければなりません。複数の弾力的なオンデマンドコンピュートクラスタがオブジェクトストレージの同じ基盤データを共有するような機能は、しばしば利用できません。弾力的なクラウドベースのデータウェアハウスからビジネス価値を得たいユーザーは、Helmチャート、Pod、ノード、設定ファイルについて知りたくありません。彼らはただデータウェアハウスをプロビジョニングし、弾力的なクラスタを管理し、データからインサイトを得たいだけです。

Kubernetes上でSQLインターフェースを提供し、複数の弾力的クラスタをオンデマンドでプロビジョニングし、Kubernetesの複雑さをDBAとエンドユーザーから隠蔽することが答えです。

この方式では、異なるユーザーに異なるコンピュートクラスタでワークロードを実行させ、使用中のコンピュートクラスタをSQLでランタイムに変更できます（権限に従う）。クラスタはアイドル期間後に自動的にサスペンドし、オンデマンドで再開するよう設定できます。例えば、必要なときにETLプロセスを実行する別のコンピュートクラスタ、アドホックBI用のクラスタ、複数のデータサイエンスクラスタを作成できます。コンピュートクラスタは使用量が多い期間にオンラインで拡張し、閑散期にはコスト削減のためにオフにできます。日次、週次、月次のバッチレポートタスク用に、それらの期間のみアクティブなクラスタを作成できます。コンピュートクラスタのノードサイズとノード数の両方を制御でき、インスタンスレベルでリソース消費の上限を設定して予測可能性を確保できます。同様に、プライマリデータウェアハウスインスタンスからレプリケーショントラフィックを受信する低コストレプリカシステムをセットアップし、レプリカが必要なときにオンデマンドでスケールアップすることも可能です。

この種の弾力性は、Kubernetesと深く統合するだけでなく、開発者ツールの代わりにSQL自体をクラスタの「作成、サスペンド、再開、管理」のための「ユーザーインターフェース」として使用することで実現されます。Kubernetesはすべてのクラスタの状態に関する信頼できる唯一の情報源です。クラスタの状態を示すシステムビューは、KubernetesのAPIを使用してKubernetesからデータを取得します。クラスタ管理SQL文が実行されると、クラウドネイティブデータウェアハウスはKubernetesに接続してインスタンスの望ましい状態を変更し、Kubernetesが必要な変更を実装します。クラスタ内のノードが不健全になれば、Kubernetesが代替ノードをオンラインにします。

これはKubernetesとのユニークな「インサイドアウト」の関係を表します。Kubernetesがクラスタの状態を駆動する「ユーザーインターフェース」になるのではなく、Kubernetesによって管理されるデータベース自体がユーザーインターフェースになります。このアーキテクチャは共生関係を生み、独自の完全なクラウド体験を提供します。Kubernetesの力とクロスプラットフォームの柔軟性がデータウェアハウスで利用可能になり、すべてSQLを通じて駆動されます。

より多くのデータが生成され、より多くのユースケースが展開されるにつれ、企業は特定のクラウド内でエコシステムがますます深く根付く悪循環に陥りやすくなります。金融サービスや保険などの厳格に規制された分野では、単一のクラウドにおけるシステミックリスクが、ミッションクリティカルなITインフラにとって過度の曝露となり得ます。Kubernetesでのアーキテクチャ設計は、完全に実現されたクラウドネイティブデータウェアハウスを実現する唯一の核心概念ではありません。分散データクラウドパターンに沿った唯一のアーキテクチャコンポーネントでもありません。しかし、それはデータ分析を非常に柔軟にし、ビジネスニーズのある場所ならどこでも、大規模かつ高並行性、高性能、高効率、高可用性で実行できる「不可欠な核心要素」です。その結果、ある企業内の数千人のユーザーが、異なるビジネスラインや地理的地域で、ほぼリアルタイムで動く分析から非常に高速な意思決定を行い、価値を生み出せるようになります。