この記事では、効果的な Azure Data Explorer 概念実証 (POC) プロジェクトを準備して実行するための高度な手法について説明します。
開始する前に
プレイブックは、Azure Data Explorer の使用を評価するのに役立ち、Azure Data Explore に最適なシナリオ向けに設計されています。 POC を開始する前に、次のシナリオを使用して、Azure Data Explorer が適切なソリューションであるかどうかを判断します。
一般的なアーキテクチャ パターンのシナリオ
- 次の 1 つ以上の特性に適合するデータは、Azure Data Explorer に適している必要があります。
- ボリュームが多く速度が速い
- 追加のみで変更できないデータ
- データの休止: 変更されないデータ。 たとえば、オンライン ストアでの注文は、休止データの良い例です。
- コマンド クエリ責任分離 (CQRS) パターン は、Azure Data Explorer の追加専用アーキテクチャに適しています。
- Event Sourcing Pattern
その他のシナリオ
Azure Data Explorer には、次のシナリオも適しています。
- リアルタイムのテレメトリベース アラートに対する低待機時間のデータ ストア
- IoT テレメトリ データのストレージと分析
- 高速対話型分析レイヤー。 特に、Synapse Spark、DataBricks、Synapse SQL プールなどの従来のデータ ウェアハウスのような Apache Spark エンジンで使用する場合。
- ログと可観測性の分析
POC を準備する
POC プロジェクトは、Azure Data Explorer を使用するクラウドベースのプラットフォームにビッグ データと高度な分析環境を実装することについて、情報に基づいたビジネス上の意思決定を行うのに役立ちます。
POC プロジェクトでは、クラウドベースのビッグ データと高度な分析プラットフォームでサポートする必要がある主要な目標とビジネス ドライバーを特定します。 主要なメトリックをテストして、Data Engineering、機械学習モデルの構築、トレーニング要件の成功に不可欠である主要な動作を実証します。 POC は、運用環境へのデプロイを意図したものではありません。 むしろ、重要な問題に焦点を当てた短期的なプロジェクトであり、その結果は破棄できます。
Azure Data Explorer POC プロジェクトの計画を開始する前に、次の手順を実行します。
- クラウドへのデータの移動に関して組織が定める制限やガイドラインを明らかにします。
- ビッグ データと高度な分析プラットフォーム プロジェクトを支持する経営幹部やビジネス スポンサーを特定します。 クラウドへの移行に向けてその支持を取り付けてください。
- POC を遂行する過程で自分をサポートしてくれる技術のエキスパートやビジネス ユーザーの有無を確認します。
POC プロジェクトの準備を開始する前に、まず Azure Data Explorer のドキュメントに目を通しておくことをお勧めします。
ここまでで即時の阻害要因はないと判断しており、続いて POC の準備を始めることができます。 Azure Data Explorer を初めて使用する場合は、このドキュメント 参照してください。このドキュメントでは Azure Data Explorer アーキテクチャの概要を確認できます。
次の主要な概念について理解を深めます。
- Azure Data Explorer とそのアーキテクチャ。
- サポートされるデータ形式とデータ ソース。
- クラスター、データベース、テーブル、具体化されたビュー、Azure Data Explorer 成果物として機能します。
- インジェスト ウィザードと継続的インジェストでサポートされているインジェスト方法。
- Azure Data Explorer での認証と承認。
- Power BI、Grafana、Kibana などの視覚化ソリューションと統合されるネイティブ コネクタ。
- Azure SQL/SQL Server、Azure Cosmos DB、Azure Monitor、Azure Digital Twin からデータを読み取る外部テーブルの作成。
Azure Data Explorer では、コンピューティング リソースをストレージから切り離して、データ処理のニーズをより適切に管理し、コストを制御できるようにします。 コンピューティングについては、使用中の場合にのみ料金を支払います。 使用されていないときには、ストレージに対してのみ料金を支払います。 Azure Data Explorer のマネージド サービス アーキテクチャを使用すると、ストレージとは別にクラスターをスケーリングできます。 スケールアップとスケールダウン (vertical)、スケール インとスケールアウト (horizontal) を使用できます。 データを失うことなく、クラスターを手動で停止または autostopすることもできます。 たとえば、大量のデータ処理のニーズや大きな負荷に合わせてクラスターをスケールアップし、処理時間が短い間にスケールダウンしたり、完全にシャットダウンしたりできます。 同様に、週末にクラスターを効果的にスケーリングして停止し、コストを削減できます。
目標を設定する
POC プロジェクトの成功には計画が必要です。 まず、実際の目的を完全に把握するために POC を実施する理由を明らかにしましょう。 最新化、コスト削減、パフォーマンスの向上、統合されたエクスペリエンスなどの目的が考えられます。 POC の明確な目標と、その成功の定義となる基準を必ず文書化してください。 次のことを確認してください。
- POC の出力として何が必要か。
- それらの出力を使って何をするか。
- その出力をだれが使用するか。
- 何をもって POC の成功とするか。
POC は、限られた一連の概念と機能を迅速に証明するための短く集中した取り組みである必要があることに注意してください。 これらの概念と機能は、全体的なワークロードを代表するものであることが必要です。 証明すべき項目が多い場合は、複数の POC を計画することをお勧めします。 その場合は、次の POC に進むべきかどうかを判断するためのゲートを POC 間に定義してください。 たとえば、ある POC では、インジェストや処理など、Data Engineering ロールの要件に焦点を当てることができます。 別の POC では、機械学習 (ML) モデルの開発に重点を置くことができます。
POC の目標を検討するときは、次のような質問を自分に投げかけ、目標の形成に役立てましょう。
- ビッグ データと高度な分析を行う既存のプラットフォーム (オンプレミスまたはクラウド) から移行するか。
- 移行して、その過程でいくつかの広範な改善を考えているか。 たとえば、ログ分析のために Elastic Search から Azure Data Explorer に移行し、InfluxDB または Timescale DB から Azure Data Explorer に移行します。
- ビッグ データと高度な分析のためのまったく新しいプラットフォーム (グリーンフィールド プロジェクト) を構築するか。
- 現在困っていることは何か。 たとえば、スケーラビリティ、パフォーマンス、柔軟性が考えられます。
- 新たにサポートすべきビジネス要件は何か。
- 満たすべき SLA はどのようなものか。
- ワークロードはどのようなものになるか。 たとえば、ETL、バッチ処理、ストリーム処理、機械学習モデルのトレーニング、分析、レポート クエリ、対話型クエリが考えられます。
- プロジェクトを所有するユーザーは、どのようなスキルを備えているか (POC を実施すべきか)。 たとえば、SQL、Python、PowerBI、その他のスキルなどです。
POC 目標設定の例を次に示します。
- POC を実施する理由
- ビッグ データ ワークロードのデータ インジェストと処理パフォーマンスが新しい SLA を満たすかどうかを把握する必要があります。
- ほぼリアルタイムのストリーム処理が可能かどうか、およびどれくらいのスループットをサポートできるかを把握する必要があります。 (ビジネス要件をサポートしますか)。
- 既存のデータ インジェストと変換プロセスが適切かどうか、およびどこで改善が必要かを把握する必要があります。
- データ統合の実行時間を短縮できるかどうか、およびどのくらいの時間短縮できるかを把握する必要があります。
- データ サイエンティストが機械学習モデルを構築してトレーニングし、必要に応じて Azure Data Explorer で AI/ML ライブラリを使用できるかどうかを把握する必要があります。
- クラウドベースの Azure Data Explorer への移行はコスト目標を達成しますか?
- この POC によって次のような成果が得られます。
- データ処理のパフォーマンス要件をバッチ ストリーミングとリアルタイム ストリーミングの両方で満たすことができるかどうかを判断するデータが得られます。
- ユース ケースをサポートするさまざまなデータ型 (構造化、半構造化、非構造化) のすべてのインジェストおよび処理がテストされます。
- 既存のデータ処理のニーズの一部をテストし、Azure Data Explorer の更新ポリシーで完了できる作業を特定できます。
- データ インジェストと処理がテストされ、履歴データの初期移行と読み込みに必要な労力を見積もるためのデータ ポイントが得られます。
- データ インジェストと処理がテストされ、ETL/ELT 処理要件を満たすことができるかどうかを判断できます。
- 導入プロジェクトの遂行に必要な作業量の見積もりに役立つ分析情報が得られます。
- スケールとスケーリングのオプションがテストされ、より良い価格 - パフォーマンス設定のためにプラットフォームをより適切に構成するためのデータ ポイントが得られます。
- さらに詳しいテストが必要な項目のリストが得られます。
プロジェクトを計画する
実際の目標をもとに具体的なテストを見極め、明確な出力を規定しましょう。 それぞれの目標と期待される出力をサポートするために、必ず少なくとも 1 つのテストを用意することが大切です。 また、限定的なデータセットとコードベースを識別できるように、特定のデータ インジェスト、バッチ処理またはストリーム処理、および実行されるその他すべてのプロセスを識別します。 この特定のデータセットとコードベースによって、POC のスコープが定義されます。
Azure Data Explorer で評価される一般的なサブジェクト領域を次に示します。
- データ インジェストと処理: データ ソース、データ形式、インジェスト方法、コネクタ、ツール、インジェスト ポリシー、ストリーミングとキューインジェスト
- データ ストレージ: スキーマ、テーブルや具体化されたビューなどのストレージ成果物
- ポリシー: パーティション分割、更新、マージなど
- クエリと視覚化
- パフォーマンス: クエリの応答時間、インジェストの待機時間、弱い整合性、クエリ キャッシュの結果など
- コスト: 総保有コスト (TCO)
- セキュリティ: 認証、承認、データ アクセス、行レベルのセキュリティなど
Note
POC の計画に役立つ、よく寄せられる質問を次に示します。
- POC クラスターの SKU を選択操作方法。
Azure Data Explorer クラスターの SKU の選択ガイドを使用して、POC クラスターの SKU を選択します。 POC を開始するときは、テストと結果のキャプチャを開始するときに、小さな SKU から開始し、必要に応じて SKU をスケールアップすることをお勧めします。 - POC クラスターの作成時にキャッシュ期間を選択操作方法。
クエリのパフォーマンスを最大限に高めるために、取り込まれたデータはローカル SSD ディスクにキャッシュされます。 このレベルのパフォーマンスは常に必要であるとは限らず、クエリの頻度が低いデータは、より安価な BLOB ストレージに格納されることがよくあります。 BLOB ストレージ内のデータに対するクエリの実行速度は遅くなりますが、多くのシナリオではこの問題を許容できます。 これを知ることで、ローカル SSD にデータを保持してクエリのパフォーマンス要件を引き続き満たすために必要なコンピューティング ノードの数を特定できます。 たとえば、(インジェスト期間に基づいて) x 日分のデータをより頻繁にクエリし、y 日間データを保持してクエリを実行する頻度を減らす場合は、キャッシュ保有ポリシーで、ホット キャッシュ保有期間の値として x、合計保有期間の値として y を指定します。 詳細については、キャッシュ ポリシーに関するページを参照してください。 - POC クラスターの作成時に保持期間を選択操作方法。
保有期間は、クエリに使用できるホット キャッシュ データとコールド キャッシュ データの組み合わせです。 データ保有は、コンプライアンスやその他の規制要件に基づいてデータを保持する必要がある期間に基づいて選択します。 監査目的でクエリを高速化するために、ホット ウィンドウ機能を使用して、コールド キャッシュに格納されているデータをウォームアップすることができます。 詳細については、「ホット ウィンドウを使用してコールド データに対するクエリを実行する」をご覧ください。
次の例は、計画に際してどの程度の具体性が必要かを示したものです。
- 目標 A: 定義された SLA の下で、バッチ データのデータ インジェストと処理に関する要件を満たすことができるかどうかを把握する必要があります。
- 出力 A: キューに置かれたデータの取り込みと処理がバッチ データ処理の要件と SLA を満たすことができるかどうかを判断するデータがあります。
- テスト A1: クエリ A、B、C の処理は、通常 Data Engineering チームによって実行されるため、優れたパフォーマンス テストとみなされます。 また、これらは全体的なデータ処理のニーズを表します。
- テスト A2: クエリ X、Y、Z の処理は、ほぼリアルタイムのストリーム処理要件を含んでいるため、優れたパフォーマンス テストとみなされます。 また、これらは全体的なイベントベースのストリーム処理のニーズを表します。
- テスト A3: クラスターのさまざまなスケール (クラスター SKU、インスタンス数) でのこれらのクエリのパフォーマンスを、既存のシステムから取得したベンチマークと比較します。
- 目標 B: ビジネス ユーザーがこのプラットフォームでダッシュボードを構築できるかどうかを知る必要があります。
- 出力 B: さまざまな視覚化オプション、コネクタ、Kusto クエリを使用して、クラスター内のデータに関する既存のダッシュボードとビジュアルの一部をテストします。 これらのテストは、新しい環境に移行できるダッシュボードの特定に役立ちます。
- テスト B1: Azure Data Explorer データを使用して特定のビジュアルが作成され、テストされます。
- テスト B2: 要件を満たすために、すぐに使用できる KQL 関数と演算子をテストします。
- 目標 C: データ インジェストがテストされ、次のためのデータ ポイントが得られます。
- Azure Data Explorer クラスターへの最初の履歴データ移行の作業量を見積もります。
- 履歴データを移行する方法を計画する。
- 出力 C: 環境で達成可能なデータ インジェスト レートがテストされ決定されると、使用可能な時間枠の間に履歴データを移行するのにデータ インジェスト レートが十分かどうかを判断できます。
- テスト C1: 履歴データ移行のさまざまな方法をテストします。
- テスト C2: LightIngest、BLOB ストレージからの継続的インジェスト、または Data Lake Store を使用して、データ ソースからクラスターへのデータ転送をテストします。 詳細については、最も 履歴データを参照してください。
- 目標 D: 増分データ読み込みのデータ インジェスト率をテストし、データ インジェストおよび処理の時間枠を推定するためのデータ ポイントが得られます。
- 出力 D: データ インジェスト率をテストし、特定されたアプローチでデータ インジェストと処理の要件を満たすことができるかどうかを判断できます。
- テスト D1: 毎日、1 時間ごと、ほぼリアルタイムのデータ インジェストと処理をテストします。
- テスト D2: エンド ユーザー クエリの実行中に、継続的 (キューまたはストリーミング) のデータ インジェストと処理を実行します。
必ず複数のテスト シナリオを追加して、テストを調整してください。
次にテスト シナリオをいくつか示します。
- Azure Data Explorer テスト A: 複数のクラスター SKU サイズ (ストレージ最適化またはコンピューティング最適化)、およびさまざまな数のクラスター インスタンスにわたって、データ インジェスト、処理、クエリを実行します。
- Azure Data Explorer テスト B: Azure Data Explorer web UI などのダッシュボードとクエリ ツールを使用して、クラスターから処理されたデータに対してクエリを実行します。
POC の計画に役立つタスクの概要の例を次に示します。
| Sprint | タスク |
|---|---|
| 0 | 顧客チームに Azure Data Explorer を提示してデモする |
| 0 | 顧客が Azure Data Explorer を使用して実現するビジネス シナリオを定義する |
| 0 | データ ソース、インジェスト方法、データ保有、データ キャッシュ、SLA、セキュリティ、ネットワーク、IAM に関する技術的要件を定義する |
| 0 | クエリ パフォーマンスの期待、待機時間、同時要求、インジェスト、データの鮮度など、主要なパフォーマンスメジャーを定義する |
| 0 | Azure Data Explorer とそのデータ インジェスターとコンシューマーを使用して高レベルのアーキテクチャを定義する |
| 0 | POC スコープを定義する |
| 0 | POC 計画とタイムラインを定義する |
| 0 | POC 評価基準を定義、優先順位付け、および重み付けする |
| 1 | テストするクエリを定義して優先順位付けする |
| 1 | ユーザーのグループごとにデータ アクセス規則を定義する |
| 1 | 1 回限りの (履歴) データ インジェスト ボリュームと毎日のデータ インジェスト ボリュームを見積もる |
| 1 | データ保持、キャッシュ、および消去の戦略を定義する |
| 1 | ストリーミング、Python/R プラグイン、消去など、クラスターの作成時に必要な構成要素を定義する |
| 1 | ソース データの形式、構造、スキーマを確認する |
| 1 | 評価基準を確認、調整、修正する |
| 1 | Azure Data Explorer の Azure 料金計算ツールに基づく価格シナリオの構築 |
| 2 | アーキテクチャ設計に従って、クラスターと必要なデータベース、テーブル、具体化されたビューを作成する |
| 2 | データ アクセスに関連するユーザーにアクセス許可を割り当てる |
| 2 | パーティション分割ポリシーとマージ ポリシーを実装する (必要な場合) |
| 2 | データの 1 回限りのインジェストを実装する (通常は履歴データまたは移行データ) |
| 2 | クエリ ツールをインストールして構成する (必要な場合) |
| 2 | Data Explorer Web UI を使用して、取り込まれたデータに対するクエリをテストする |
| 2 | 更新と削除のシナリオをテストする |
| 2 | PowerBI への接続をテストする |
| 2 | Grafana への接続をテストする |
| 2 | データ アクセス管理規則を構成する |
| 2 | 継続的インジェストを実装する |
| 2 | Event Hubs/Iot Hub/Event Grid のデータ接続を作成する |
| 3 | Azure Data Explorer ダッシュボードまたは Grafana でほぼリアルタイムで監視するための自動参照ダッシュボードを実装する |
| 3 | ロード テストの実行方法を定義する |
| 3 | 以前のスプリントと完了したバックログ項目からの学習に基づいてインジェストの方法とプロセスを最適化する |
| 3 | Grafana ダッシュボードでのパフォーマンス評価 |
| 3 | コンカレンシー要件と予想される負荷要件に合わせてロード テストを実行する |
| 3 | 成功基準を検証する |
| 3 | スコアリングを確認する |
| 3 | さまざまな形式でデータを取り込む機能をテストする |
| 3 | POC の結果を検証する |
POC データセットを評価する
実際に洗い出したテストを使用して、それをサポートするデータセットを選択します。 このデータセットは慎重に確認してください。 そのデータセットが内容、複雑さ、規模の点で、将来の処理を適切に表現できることを確かめる必要があります。 小さすぎるデータセット (1 GB 未満) は、代表的なパフォーマンスが得られないため使用しないでください。 逆に、大きすぎるデータセットも、POC が完全なデータ移行になってしまうので使用を避けます。 パフォーマンス比較に使用できるように、必ず既存のシステムから適切なベンチマークを取得してください。 データセットがサポートされているデータ形式と一致しているかどうかを確認します。 その後、インジェスト方法 (キューまたはストリーミング) に応じて、データセットを適切なサイズのバッチで取り込むことができます。
重要
データをクラウドに移動する前に、必ずブロッカーがないか、ビジネス オーナーに確認してください。 クラウドにデータを移動する前に行う必要がある、セキュリティやプライバシーに関する懸念事項またはデータ難読化のニーズを特定します。
アーキテクチャの全体像を形成する
将来どのようなアーキテクチャにするかという計画の全体像に基づいて、POC の構成要素となるコンポーネントを洗い出します。 大まかなアーキテクチャの将来像には、多くのデータ ソースとデータ コンシューマー、ビッグ データ コンポーネント、場合によっては機械学習と人工知能 (AI) データ コンシューマーが含まれていることも考えられます。 POC アーキテクチャでは、POC に属するコンポーネントを具体的に洗い出す必要があります。 特に、POC テストの構成要素ではないコンポーネントを明確にすることが大切です。
既に Azure を使用している場合は、既に導入されているリソースのうち、POC の期間中に使用することができるリソース (Microsoft Entra ID、ExpressRoute など) を特定します。 また、自分の組織が使用する Azure リージョンも特定します。 ExpressRoute 接続のスループットを把握し、その一部を POC が使用することによって運用環境のシステムに悪影響が生じることがないか、他のビジネス ユーザーに確認する良い機会です。
詳細については、「ビッグ データ アーキテクチャ」を参照してください。
POC のリソースを洗い出す
POC をサポートするために必要な技術的リソースと時間的コミットメントを具体的に特定します。 以下はその例です。
- 要件と結果を監督するビジネス代表者。
- POC に使用するデータを調達し、既存のプロセスとロジックに関する知識を提供するアプリケーション データ エキスパート。
- Azure Data Explorer のエキスパート。 必要に応じて、Microsoft の連絡先に手配を要求できます。
- POC テストを最適化するエキスパート アドバイザー。 必要に応じて、Microsoft の連絡先に手配を要求できます。
- POC プロジェクトの特定のコンポーネントに必要なリソース (POC の実施期間中、必ずしも必須ではないもの)。 たとえば、ネットワーク管理者、Azure 管理者、Active Directory 管理者、Azure portal 管理者が挙げられます。
- 必要な Azure サービス リソースがすべてプロビジョニングされ、必要なレベルのアクセス権が付与されていること (ストレージ アカウントへのアクセス権など)。
- POC の作業範囲に含まれるすべてのデータ ソースからデータを取得するために必要なデータ アクセス権があるアカウント。
ヒント
エキスパート アドバイザーに POC の支援を依頼することをお勧めします。 Microsoft アカウント チームに問い合わせるか、Azure Data Explorer の評価、評価、または実装に役立つ専門家コンサルタントのグローバルな可用性に連絡してください。 Azure Data Explorer タグを使用して、 Stack Overflow に質問を投稿することもできます。
タイムラインを設定する
POC にかかる概算時間を見極めるために、POC 計画の詳細とビジネス ニーズを確認します。 POC の目標を達成するために必要な時間は現実的に見積もってください。 POC の所要時間は、POC データセットのサイズ、テストの数と複雑さ、テストするインターフェイスの数に左右されます。 POC の実行時間が 4 週間を超えると思われる場合は、その作業範囲を絞り込んで、優先度が最も高い目標のみに焦点を当てることを検討してください。 必ず主立ったリソースとスポンサー全員から承認と確約を得たうえで続行してください。
POC を実践する
運用プロジェクトの規範と厳格さを備えた POC プロジェクトを遂行することをお勧めします。 POC の作業範囲が拡大して手に負えなくなってしまう事態を防ぐため、プロジェクトは計画に従って実行し、変更要求プロセスを管理してください。
大まかなタスクの例をいくつか次に示します。
Azure Data Explorer クラスターと、POC プランで識別されるすべての Azure リソースを作成します。
POC データセットを読み込みます。
- ソースから抽出するか、Azure でサンプル データを作成して、データを Azure で使用できるようにします。 Azure Data Explorer でのデータの取り込みの初期テストでは、 get データ エクスペリエンスを使用します。
- クラスターにデータを取り込む際に使用する予定のコネクタ/統合方法をテストします。
データにクエリを実行するために Kusto クエリを作成します。
- SQL ベースのシステムから移行する場合は、 SQL から Kusto チート シート を使用して作業を開始できます。
テストを実行します。
- ダッシュボード、PowerBIm、Azure Data Explorer web UI など、さまざまなクライアント インターフェイスを使用して、クラスターで多くのテストを並列で実行。
- JMeter または Grafana k6 を使用して、load テストを作成できます。
- 利用しやすくわかりやすい形式で結果を記録します。
クエリとクラスターを最適化します。
- 新しい KQL クエリを作成する場合でも、他の言語から既存のクエリを変換する場合でも、クエリがクエリのベスト プラクティスに従っていることを確認することをお勧めします。
- テスト結果によっては、キャッシュ ポリシー、パーティション 分割ポリシー、クラスターのサイズ設定、またはその他の最適化を使用してクラスターの微調整が必要になる場合があります。 推奨事項については、「 Azure Data Explorer を使用して高いコンカレンシーを実現するための最適化」を参照してください。
トラブルシューティングとパフォーマンスのための監視を行います。
- 詳細については、「 Monitor Azure Data Explorer のパフォーマンス、正常性、使用状況とメトリックを参照してください。
- 技術的な課題については、サポート チケットを作成してください。
価格の見積もり:
- POC の最後に、POC で学習した内容を使用して、要件を満たすクラスターのコストをに見積もる必要があります。
POC を閉じます。
- POC フェーズの結果、学習したレッスン、成果を記録します (POC 中に適用したベンチマーク、構成、最適化など)。
- POC 中に作成し、不要になったすべての Azure リソースをクリーンアップします。
ヒント
Azure Data Explorer を続行し、運用環境 移行する予定がある場合は、POC クラスターを実行したままにすることをお勧めします。 これは、POC 中に適用した可能性のある構成と最適化を失わないように、運用クラスターを設定するのに役立ちます。
POC の結果を解釈する
すべての POC テストが完了したら、その結果を評価します。 まず、POC の目標が満たされ、目的の出力が収集されたかどうかを評価します。 さらに詳しいテストが必要か、または対処すべき問題があるかどうかを判断します。
POC から運用環境への移行
Azure Data Explorer に進み、POC クラスターを運用環境に移行する場合は、POC クラスターを実行したままにし、それを使用して運用クラスターを設定することを強くお勧めします。 これにより、POC 中に適用した可能性のある構成と最適化が失われないようにすることができます。
POC クラスターを運用環境に移行する前に、次の要因を考慮し、設計し、決定することを強くお勧めします。
- 機能要件と非機能要件
- ディザスター リカバリーと高可用性の要件
- セキュリティ要件
- ネットワーク要件
- 継続的インテグレーションと継続的デプロイ (CI/CD) の要件
- 監視とサポートの要件
- Azure Data Explorer での主要な担当者のトレーニング
- アクセス制御の要件
- スキーマ、データ モデル、データ フローの要件
- インジェストの要件
- 視覚化の要件
- データと分析情報の使用要件
- テスト要件