特集
データ製品を活用するために必要な、プラットフォームのアーキテクチャ設計はどうすべきか？
AI時代の大規模なデータ分析基盤構築における、陥りやすい罠と考えるべきポイント【第3回】
2024年12月20日 09:00
これまで2回にわたって、大規模なデータ分析基盤構築における注意点と、考えるべきポイントとしてのデータガバナンスやデータアーキテクチャについて、解説してまいりました。データ製品やドメインの定義、コラボレーションのためのガイドラインが決まれば、次はプラットフォームのアーキテクチャ設計です。今回は、データ製品をドメイン間で効果的にコラボレーションして作成、配置、利用するためのプラットフォームアーキテクチャについて、解説します。
【特集】AI時代の大規模なデータ分析基盤構築における、陥りやすい罠と考えるべきポイント
▼【第1回】大規模なデータ分析基盤の構築時に待ち受ける“落とし穴”
▼【第2回】大規模データ分析・AI基盤の目指すべき姿を“データの視点”から考える
▼【第3回】データ製品を活用するために必要な、プラットフォームのアーキテクチャ設計はどうすべきか？（本記事）
未来対応型プラットフォームアーキテクチャ
クラウドの世界では、さまざまな機能がサービスとして（as-a-Service）提供されていますが、前回解説したような共通の原則や基準を、ドメインが管理する全てのデータ製品に適用するには、必要な機能を各ドメインが共通で利用できるような共有サービスを採用する必要があります。大規模なデータ分析基盤に必要な共有サービスは、データパイプラインの生成、SQLエンジン、機械学習エンジン、ストレージ管理、サロゲートキーの管理、リソースの最適化、分散データ管理、データカタログなど、多岐に渡ります。それら一連のサービスの実装、保守、改善はプラットフォームチームの役割であり、どのようなテクノロジーで実現するかは、どのようなユースケースを想定するかによりますが、必要なサービスから必要なデータ製品へ必要な時にアクセス可能とする柔軟性と俊敏性が求められます。
Teradataでは、データ分析基盤に必要なサービスを論理的に一元化し、データへの接続性を確保した未来対応型のプラットフォームのアーキテクチャを、「コネクテッド・アナリティクス・アーキテクチャ」と呼んでいます。
ドメインによって所有・管理されるデータ製品は、論理的に接続されたデータストアサービスの集合体であるコネクテッド・データ基盤に、パフォーマンスやデータ配置の要件に応じて、オープンまたは最適化された形式で保存されます。
それらデータ製品を作成、管理、保守、分析するためのさまざまな種類のコンピュートサービスは、ドメインによって必要に応じて起動され、データ基盤上のデータ製品をほかのコンピュートサービスと共有して利用します。その際、コンピュートサービスは独自のエンジンカタログまたはオープンなカタログを使用し、インテリジェントメッシュと呼ばれる分散データを統合管理するファブリック機能を通して、さまざまな物理ストアに配置されたデータ製品にシームレスにアクセスします。
各サービスはSQLやPythonやRESTなど、標準のAPIによって接続可能な状態（APIファブリック）ですが、ユーザーはそれを意識することなく、自然言語を使って、エンタープライズカタログによって一元的に概念化されたビジネスで必要な情報を、安全で信頼されたガバナンスプロセスのもとで、好きなコンピュートを使って、自由に取り出すことが可能です。
このアーキテクチャのように、さまざまなコンピュートが論理的に一元化されたデータ基盤を共有可能とすることで、データの冗長化と不要な移動を防ぎ、コスト効率良いドメインのコラボレーションを実現します。ただ、それと同時に個々のドメインは、統制されたプラットフォーム上において、独自のサービスを導入・利用する自由や、管理するデータ製品を共有しない自由も保持します。
このコネクテッド・アナリティクス・アーキテクチャは、Teradataのビジョンを表現したものですが、特定のテクノロジーに特化したものではなく、どのようなテクノロジーを選択するかは自由です。このようなアーキテクチャを想定しておくことで、時代の変化と共に移り行くテクノロジーに依存しない、強固なデータ分析基盤の構築を目指したものになります。
しかしながら、いくつか最新のテクノロジーのトレンドとして、記しておくべきポイントも存在します。
①さまざまなデザインパターンの融合
かつて、オンプレミスの時代では、データウェアハウス、データマート、データレイク、などのデータ基盤のデザインパターンごとに別のテクノロジーが存在していましたが、最近ではそれらが融合し、レイクハウスなどの包括したデザインパターンが主流になっています。
また、データ基盤とAI/ML基盤も以前は全く別のものとして分けて構築するものでしたが、最近ではAI/ML機能を取り込んだデータ基盤、あるいはデータ管理機能を取り込んだAI/ML基盤など、1つのプラットフォームで多くのユースケースをカバーするものが主流になりつつあります。
そのようなデータ基盤とAI/ML基盤が融合したプラットフォームでは、コンピュートエンジンもCPUベースだけでなくGPUベースのエンジンも必要に応じて利用可能となり、従来の統計解析から最新の生成AIまで、あらゆる高度分析が1つのプラットフォーム上で可能になっています。それに伴い、これまでデータ基盤からAI/ML基盤へデータの移動を行う必要があったものが、その必要がなくなり、データ管理の冗長化もなくなるなど、時間とコストの効率良い運用が可能になります。
しかしその分、1つのプラットフォーム上で実行されるワークロードの種類や量も増え、同時実行される処理は複雑化するため、今後はよりインテリジェントなクエリ解析機能やワークロード管理機能などのリソース最適化機能が重要になってくるでしょう。
②オープン・データ・スタンダードの進化
かつてデータ製品は、データベースエンジンに付随したクローズドなブロックストレージに配置されるものでしたが、オープンスタンダードを活用する現在のトレンドは、データの配置にも及んでいます。コスト効率の良いオブジェクトストレージを利用した、ParquetやJSON、CSVなどのオープンファイルフォーマット（OFF）の利用は、移植性が高くさまざまなエンジンで読み取りが可能である反面、固有のデータ管理やガバナンスがなく信頼性に劣る上に、パフォーマンスに問題がありました。
そこで現在急速に普及が進んでいるのが、オープンテーブルフォーマット（OTF）です。OTFの代表的なものとしては、Iceberg、Delta Lake、Apache Hudiなどがあり、それぞれ少しずつ違いはあるものの、OFFの利便性を保ちながら、単一のメタデータ管理レイヤー（オープンカタログ）を併せ持つことで、ACID準拠、スキーマの変更、タイムトラベルなど、高度なデータマネジメント機能を実現する特徴を持っています。これにより、さまざまなコンピュートエンジンから品質を保ったアクセスが可能となるため、ベンダーにまたがるデータ統合の複雑性軽減やコスト抑制に大きく貢献すると言われています。また、コンピュートとは別に簡単に拡張可能となることから、より大量のデータにもコスト効率よく対応可能です。オープン・スタンダードな方法でデータマネジメントを実現するこの形式は、データ製品の相互運用性の観点や柔軟性の観点から、今後ますます需要が見込まれます。
ただ、従来の各種エンジンに最適化されている高パフォーマンスなブロックストレージやオブジェクトストレージのストア形式も、高いSLAが必要なデータ製品や高アクセスなデータ製品には最適であることから、今後はこれら4つを併せて利用することで、データ製品の性質により適した細かなデータ配置が可能になります。
この図が示すデータ製品の配置は、あくまで推奨事項です。実際には、各データ製品の最適な配置は、利用可能なデータプラットフォーム、SLA、再利用の必要性によって考える必要がありますのでご注意ください。
③より柔軟で広範なデータ配置：マルチクラウド、ハイブリッドクラウド
クラウドは柔軟性が高く、サービス利用までの時間とコストを大幅に縮小するas-a-Serviceモデルが時代にマッチしていることもあり、2000年代後半に誕生して以降、またたく間に世界中に浸透していきました。ここ最近は、複数のパブリッククラウドを利用する、いわゆる「マルチクラウド」の企業も珍しくなくなり、多くの企業がサービスごとに使い分けたり、災害対策のバックアップを別のクラウドにしたりと、複数のクラウドを利用しています。こうしたクラウドファーストの傾向は今後も続くと思われます。
しかし、一方で、オンプレミスを継続しクラウドへの移行を行わない企業や、一度クラウドへ移行したものの再度オンプレミスに戻ってくる、いわゆる「オンプレ回帰」の企業も顕在化してきています。また、ある程度クラウドを利用しているものの、機密性の高いデータに関してはオンプレミスを利用するなど、クラウドもオンプレミスもどちらも利用する「ハイブリッドクラウド」の企業も多くあります。特に最近では、大規模な生成AIの利用による情報漏えいのリスクからオンプレミスを求める声や、必ずしも大規模モデルが必要ではないユースケースについて、安全なオンプレミス環境で小～中規模の生成AIの開発やファインチューニングを求める声も多く聞かれるようになってきました。
今後は、クラウドかオンプレミスかのどちらか一択ではなく、ユースケースに応じてさまざまなパブリッククラウドとオンプレミス環境を同時に利用する、ハイブリッドクラウドが主流になってくると思われます。
その場合、オンプレミスでもパブリッククラウドでも利用可能な、移植性の高いテクノロジーをプラットフォームに選択しておくことで、データ製品の相互運用性を確保するだけでなく、将来的なデプロイの柔軟性も保証することになりますので、検討項目の1つとして加えられることをお勧めします。
＊＊＊＊＊
以上、3回にわたり、大規模な組織における、AIの活用を促し迅速な意思決定や業務への活用を行うためのデータ分析基盤構築における、陥りやすい罠と考えるべきポイントについて、データガバナンス、データアーキテクチャ、プラットフォームアーキテクチャの観点で解説してまいりました。この3回で共通して言えるのは、重要なのは「何を構築するか」ではなく、「何のために構築するか」ということです。そこが存在しないと、単にテクノロジーだけを取捨選択して組み合わせ、場当たり的な構築に陥り、結果、根本的な課題が何も解決されないか、かえって問題が複雑化してしまう可能性があります。
大規模なデータ分析基盤で大切なのは、安全で信頼できるデータを、組織全体でいかに効率良く提供するか、ということです。それはデータ量が今ほど多くなかった時代から変わることはありませんが、より大規模に、より複雑に、よりスピーディなっている現代だからこそ、さらに全体を俯瞰した形で最適化を考えていくことが重要になっています。
テクノロジーだけしか考慮しないのであれば、そのテクノロジーが廃れると、それまで築き上げたものが引き継がれず、またゼロから全て構築し直さなければならず、それを永久に繰り返していく必要があります。これまでの資産をうまく活用し、将来的な進化にも上手く対応していくためには、テクノロジーから切り離した次元で物事を捉え、時代の変化と共に進化していくビジョンとアーキテクチャを描き、それを改善し続けることです。そこに必要なのが、データをはじめとするアーキテクチャやガバナンスとなります。
なお、筆者が所属しているTeradataは長年、大規模データを全社の分析に利用するためのデータ分析基盤を世界中のグローバル企業へ提供し続けており、その過程において、本稿で取り上げたような様々な課題に直面し、それを乗り越えるためのノウハウをさまざま蓄積してきました。本稿が、同じような悩みを抱える皆さまにとって、解決のための一助になれば幸いです。
- 日本テラデータのデータ分析プラットフォームにおける、リファレンス・アーキテクチャ策定の責任者。ワールドワイドなデータアーキテクチャチームの一員としてインフォメーション・アーキテクチャの分野において日本をリードしている。
金融、通信、自動車、製薬など多岐にわたる各種業界において、将来を見据えたデータ活用の目的やデータ管理などのコンサルティングを行い、企業のデータ統合・分析基盤のアーキテクチャ策定や構築を支援。