クラウド規模の分析の概要

クラウド規模の分析は、デプロイとガバナンスを容易にするための Azure ランディング ゾーンを基に構築されています。 Azure ランディング ゾーンの主な目的は、アプリケーションやワークロードが Azure にアクセスするときに、必要なインフラストラクチャの準備が既に整っているようにすることです。 クラウド規模の分析のランディング ゾーンをデプロイする前に、Azure ランディング ゾーンを 1 つ以上確立済みである必要があります。 Microsoft では、データ レイクとデータ メッシュのデプロイに使用できるサンプル テンプレートを提供しています。 これらのテンプレートは、機敏性を提供するもので、セキュリティとガバナンスの要件に準拠しています。

クラウド規模の分析の評価

企業では多くの場合、特定のユース ケース、プロジェクト、またはエンド ツー エンドのクラウド規模の分析のために技術的詳細の作成を始める前に、明快さや規範的なガイダンスが求められます。 企業が全体的なデータ戦略を策定するときに、現在の使用範囲内に含まれるすべての戦略的原則と必要な原則を確実に考慮に入れることは難しい場合があります。

これらの課題を念頭に置きながら、このエンド ツー エンドの分析情報を導入する取り組みの引き渡しをスピードアップするため、Microsoft では、クラウド規模の分析用の規範的なシナリオを開発してきました。 これは、「クラウド規模の分析の計画を作成する」で説明されている主要なテーマに沿って作成されています。

クラウド規模の分析は、Microsoft クラウド導入フレームワークに基づいて構築されており、同時に、Microsoft Azure Well-Architected Framework レンズが適用されています。 Microsoft クラウド導入フレームワークでは、クラウド運用モデル、参照アーキテクチャ、プラットフォーム テンプレートに関する規範的ガイダンスとベスト プラクティスが提供されます。 それは、最も困難で高度で複雑な環境から得られた実際の知識に基づいています。

クラウド規模の分析により、お客様は、分析ワークロードをホストして実行するためのランディング ゾーンを構築して運用化できるようになります。 ランディング ゾーンは、セキュリティ、ガバナンス、コンプライアンスを基盤として構築します。 これらはスケーラブルでモジュール式であり、同時に自律性とイノベーションをサポートしています。

データ アーキテクチャの歴史

1980 年代後半に、データ ウェアハウスの第 1 世代が導入され、それらによって、企業全体にわたる異種のデータ ソースが結合されました。 2000 年代後半に登場した第 2 世代では、Hadoop やデータ レイクなどのビッグ データ エコシステムが導入されました。 2010 年代中頃には、クラウド データ プラットフォームが登場しました。 これは以前の世代に似ていましたが、カッパ アーキテクチャやラムダ アーキテクチャのようなストリーミング データ インジェストが導入されました。 2020 年代初頭には、データ レイクハウス、データ メッシュ、データ ファブリック、データ中心操作パターンなどの概念が導入されました。

これらの進歩にもかかわらず、多くの組織は引き続き、一元化されたモノリシック プラットフォームである第 1 世代を使用しています。 このシステムはある程度まで問題なく機能します。 ただし、相互に依存するプロセス、緊密に結合されたコンポーネント、極度に専門化が進んだチームが原因でボトルネックが発生する可能性があります。 抽出、変換、読み込み (ETL) のジョブが目立つようになり、配信のスケジュールに遅れが出る可能性があります。

データ ウェアハウスとデータ レイクは依然として価値があり、全体としてのアーキテクチャの中で重要な役割を果たします。 以降の考証では、これらの従来の実施方法を使用してスケーリングするときに発生する可能性があるいくつかの課題を浮き彫りにしました。 これらの課題は特に、データ ソース、要件、チーム、出力が変化する複雑な組織に関連しています。

クラウド規模の分析への移行

現在の分析データ アーキテクチャと運用モデルには、データ ウェアハウス、データ レイク、データ レイクハウス構造のほか、データ ファブリックやデータ メッシュなどの新しいモデルさえ含まれる場合があります。

各データ モデルには、独自のメリットと課題があります。 クラウド規模の分析は、現在の構成から作業を行い、現在のインフラストラクチャと共に進化できるようにデータ管理に対するアプローチを移行するのに役立ちます。

基盤として機能し、スケーリングが実現されるエンド ツー エンドのクラウド規模の分析フレームワークを作成するために、どのデータ プラットフォームやシナリオでもサポートできます。

最新のデータ プラットフォームと必要な結果

最初の重点領域の 1 つは、スケーラブルでアジャイルな最新のデータ プラットフォームを反復的に構築することで、課題に対応するためのデータ戦略を活性化することです。

最新のデータ プラットフォームを使用すると、サービス チケットに圧倒されたり、両立しないビジネス ニーズを満たそうとしたりするのではなく、より価値の高い作業に集中するために時間を解放して、助言により重点を置いた役割を果たせます。 データと分析のニーズに関するセルフサービスを提供するためには、プラットフォームとシステムを使用して基幹業務を提供します。

最初に重点を置くことをお勧めする領域は以下のとおりです。

  • データ主導でビジネス上の意思決定を行うために、データ品質を向上させ、信頼を促進し、分析情報を得ます。

  • 組織全体で大規模に、総合的なデータ、管理、分析をシームレスに実装します。

  • 基幹業務のセルフサービスと柔軟性を実現する堅牢なデータ ガバナンスを確立します。

  • 完全に統合された環境でセキュリティと法的コンプライアンスを維持します。

  • 適切に設計された反復可能なモジュール式パターンを備え、すぐに使用できるソリューションによって、高度な分析機能の基盤を迅速に作成します。

分析資産の管理

2 つ目の考慮事項は、組織でデータ ガバナンスを実装する方法を決定することです。

データ ガバナンスとは、事業運営、レポート、分析で使用されるデータが、検出可能であること、正確であること、信頼できること、保護可能であることを確認する方法です。

多くの企業で期待されることは、データと AI によって競争上の優位性を高めることです。 その結果、経営幹部は、彼らの意思決定をデータに基づいたものにするために、AI 戦略を支援することに熱意を示します。 ただし、AI を効果的なものにするには、AI で使用しているデータが信頼されるものである必要があります。 そうでないと、意思決定の精度が損なわれたり、決定が遅れたり、行動の機会を逃したりする可能性があり、それらが最終利益に影響を及ぼすことがあります。 企業は、自社データの品質が、"ごみを入れればごみしか出てこない" 状態になることを望んでいません。最初は、デジタル変換がデータに及ぼした影響を調べるまで、データ品質を修正することは簡単に思えるかもしれません。

データがハイブリッド マルチクラウドと分散データ ランドスケープをまたいで分散している状態では、組織は自身のデータがどこにあるかを見つけ、それを管理することに苦労します。 管理されていないデータは、ビジネスに大きな影響を与える可能性があります。 データ エラーによって処理のエラーや遅延が発生するため、データ品質の低下は事業運営に影響します。 データ品質の低下は、ビジネス上の意思決定と、コンプライアンスを維持する能力にも影響します。 分析システム内で品質の問題を修正する方が、インジェスト フェーズの早期にデータ品質ルールを適用するよりも複雑でコストがかかる場合があるため、多くの場合、ソースでデータ品質を確保することをお勧めします。 データの利用状況の追跡と管理をサポートするには、データ ガバナンスに次のものが含まれている必要があります。

  • データの検出
  • データ品質
  • ポリシーの作成
  • データ共有
  • メタデータ

分析資産のセキュリティ保護

データ ガバナンスを推進するもう 1 つの大きな要因は、データ保護です。 データ保護は、規制法令に準拠するのに役立つ場合があり、データ侵害を防止することができます。 データのプライバシーとデータ侵害の発生数の増加によって、データ保護は役員にとっての最優先事項になっています。 これらの侵害によって、個人を特定できる顧客データなどの機密データへのリスクが強調されます。 データのプライバシー違反またはデータのセキュリティ違反の結果は多数あり、次のようなものが含まれる可能性があります。

  • ブランド イメージの喪失や重大な打撃

  • 顧客の信用とマーケット シェアの損失

  • 株価の下落。投資に対する株主への配当と役員報酬に影響します

  • 監査またはコンプライアンスの不適合による多額の制裁金

  • 法的措置

  • 侵害のドミノ倒し効果。たとえば、顧客がなりすましの被害者になる可能性があります

ほとんどの場合、株式を上場している企業は、これらの侵害を公表する必要があります。 侵害が発生した場合、顧客がまず非難するのは、ハッカーではなく企業になる傾向があります。 顧客は、数か月の間、企業の商品の購入を拒否したり、二度と戻ってこない場合があります。

データ プライバシーに関する規制法令への準拠に失敗すると、多額の制裁金が発生する可能性があります。 データの管理は、このようなリスクを回避するのに役立ちます。

運用モデルと利点

最新のデータ戦略プラットフォームを採用すると、組織が使用するテクノロジだけでなく、その運用方法も変更されます。

クラウド規模の分析には、以下のような人やチームの編成とスキルの向上を行う方法を検討するのに役立つ、規定されたガイダンスが用意されています。

  • 人、役割、責任の定義
  • アジャイル チーム、垂直チーム、クロス ドメイン チームにお勧めの構造
  • Microsoft Learn を介した Azure のデータや AI に関する認定資格を含むスキル リソース

最新化プロセスの全体を通して、また、引き続きプラットフォームを進化させて新しいユース ケースをオンボードするときには、エンド ユーザーを関与させることも重要です。

アーキテクチャ

Azure ランディング ゾーンは、環境の戦略的設計パスと、技術的に目指している状態を表します。 これらを使用すると、機敏性とコンプライアンスを向上させるためのデプロイとガバナンスの容易さが実現します。 Azure ランディング ゾーンでは、新しいアプリケーションやワークロードが環境内にアクセスしたときに、適切なインフラストラクチャの準備が既に整っていることも確認されます。 Azure データ管理とデータ ランディング ゾーンは、こうした同一の基本的原則を念頭に置いて設計されており、クラウド規模の分析の他の要素と組み合わせると、以下を実現する助けとなります。

  • セルフ サービス
  • スケーラビリティ
  • はじめに
  • セキュリティ
  • プライバシー
  • 最適化された運用

データ管理ランディング ゾーン

データ管理ランディング ゾーンでは、組織全体にわたり、プラットフォームの一元化されたデータ ガバナンスと管理の基盤が提供されます。 また、マルチクラウドやハイブリッド インフラストラクチャなど、デジタル資産全体からデータを取り込むための通信も容易になります。

データ管理ランディング ゾーンでは、以下のような、データ管理とガバナンスに関するその他の機能が多数サポートされています。

  • データ カタログ
  • データ分類
  • データ系列
  • データ品質の管理
  • データ モデリング リポジトリ
  • API カタログ
  • データの共有とコントラクト

データのランディング ゾーン

データ ランディング ゾーンは、データをユーザーに近づけて、セルフサービスを可能にするのと同時に、データ管理ランディング ゾーンへの接続を介して共通の管理とガバナンスを維持します。

ネットワーク、監視、データ インジェスト、処理などの標準的なサービスに加え、データ製品や視覚化などのカスタマイズをホストします。

データ ランディング ゾーンは、プラットフォームのスケーラビリティを実現する鍵です。 組織の規模とニーズに応じて、1 つまたは複数のランディング ゾーンから開始できます。

ランディング ゾーンを 1 つにするか複数にするかを決定するときは、リージョンの依存関係とデータ所在地の要件を考慮に入れてください。 たとえば、データを特定の場所に留めることが求められる地域の法律や規制が存在するか、などです。

データ ランディング ゾーンは、最初の決定にかかわらず、必要に応じて追加または削除できます。 1 つのランディング ゾーンで開始しようとしている場合は、移行に対する今後の必要性を解消するために、複数のランディング ゾーンへの拡張を計画することをお勧めします。

ランディング ゾーンの詳細については、「クラウド規模の分析のための Azure ランディング ゾーン」を参照してください。

まとめ

このドキュメント セット、特にガバナンス、セキュリティ、運用、ベスト プラクティスのセクションを読み終えたら、デプロイ テンプレートを使用して概念実証環境を設定することをお勧めします。 これらのテンプレートをアーキテクチャ ガイダンスと共に使用すると、いくつかの Azure テクノロジを実践的に経験できます。 詳細については、「作業開始のチェックリスト」を参照してください。

次の手順

クラウド規模の分析をクラウド導入戦略に統合する