エクスポートされた履歴データをホストするターゲット Azure プラットフォームを選択する

  • [アーティクル]

移行プロセス中に行う重要な決定の 1 つは、履歴データを保存する場所です。 この決定を行うには、さまざまなターゲット プラットフォームを理解し、比較できる必要があります。

この記事では、パフォーマンス、コスト、使いやすさ、管理のオーバーヘッドの観点からターゲット プラットフォームを比較します。

注意

この表の考慮事項は、履歴ログの移行にのみ適用され、長期保有などの他のシナリオには適用されません。

基本ログ/アーカイブ Azure Data Explorer (ADX) Azure Blob Storage ADX + Azure Blob Storage
機能: • 低コストの Azure Monitor ログのほとんどの機能に適用されます。
• 基本ログは 8 日間保持され、その後自動的にアーカイブに転送されます (元の保持期間に従います)。
• 検索ジョブ を使用してペタバイト単位のデータを検索し、特定のイベントを見つけます。
• 特定の時間の範囲で詳細な調査を行う場合は、アーカイブからデータを復元します。 その後に、データをホット キャッシュで使用して、さらに分析することができます。		 • ADX と Microsoft Sentinel はどちらも Kusto 照会言語 (KQL) を使用できるので、両方のプラットフォームでデータのクエリ、集計、関連付けを行うことができます。 たとえば、Microsoft Sentinel から KQL クエリを実行して、ADX に格納されているデータを Log Analytics に格納されたデータと結合することができます。
• ADX を使用すると、クラスターのサイズと構成を厳格に制御できます。 たとえば、より大きなクラスターを作成してより高いインジェスト スループットを実現したり、より小さなクラスターを作成してコストをコントロールしたりすることができます。		 Blob Storage は、テキスト データやバイナリ データなどの大量の非構造化データを格納するために最適化されています。
•競争力のあるコストを提供します。
• 組織がコンプライアンスや監査の要件を満たす必要がある場合など、組織がアクセシビリティやパフォーマンスを優先しないシナリオに適しています。		 • データは、低コストの BLOB ストレージに格納されます。
• ADX を使用して KQL のデータに対してクエリを実行することで、データに簡単にアクセスできます。 ADX を使用して Azure Monitor データにクエリを実行する方法について説明します
使いやすさ: 大変良い

アーカイブと検索のオプションは、Microsoft Sentinel ポータルからアクセスして、簡単に使用できます。 ただし、データはクエリですぐに使用できるわけではありません。 検索を実行してデータを取得する必要があり、スキャンしたときに返されるデータの量によっては、時間がかかる場合があります。		 良い

Microsoft Sentinel のコンテキストで非常に簡単に使用できます。 たとえば、Azure ブックを使用して、Microsoft Sentinel と ADX の両方に分散しているデータを視覚化できます。 ADX プロキシを使用して、Microsoft Sentinel ポータルから ADX データにクエリを実行することもできます。		 悪い

履歴データの移行では、何百万ものファイルを操作する必要があり、データの探索が困難になる場合があります。		 普通

参照する BLOB の数が多いと、externaldata 演算子の使用が非常に困難になりますが、外部 ADX テーブルを使用すると、この問題は解消されます。 外部テーブル定義は、BLOB ストレージのフォルダー構造を理解するので、多くの異なる BLOB やフォルダーに含まれているデータを透過的に照会できるようになります。
管理のオーバーヘッド: フル マネージド

検索とアーカイブのオプションはフル マネージドであり、管理のオーバーヘッドは増加しません。		 高

ADX は Microsoft Sentinel の外部にあり、監視とメンテナンスが必要です。		 低

このプラットフォームではメンテナンスがほとんど必要ありませんが、このプラットフォームを選択すると、ライフサイクル管理の設定など、監視と構成のタスクが増加します。		 Medium

このオプションを使用すると、ADX と Azure Blob Storage をメンテナンスおよび監視することができます。これらはどちらも Microsoft Sentinel の外部コンポーネントです。 ADX をときどきシャットダウンできますが、このオプションでは管理のオーバーヘッドが増加することを考慮してください。
パフォーマンス: Medium

通常は、検索ジョブを使用してアーカイブ内の基本ログを操作します。これは、データへのアクセスを維持する必要があってもデータへの即時アクセスは必要ない場合に適しています。		 高から低

• ADX クラスターのクエリのパフォーマンスは、クラスター内のノード数、クラスターの仮想マシン SKU、データのパーティション分割などによって異なります。
• クラスターにノードを追加すると、パフォーマンスが向上しますが、コストが増加します。
• ADX を使用する場合は、パフォーマンスとコストのバランスを取ることができるようにクラスター サイズを構成することをお勧めします。 この構成は、どれぐらいの時間で移行を完了する必要があるか、データにアクセスする頻度、予想される応答時間など、組織のニーズによって異なります。		 低

プレミアムまたは標準の 2 つのパフォーマンス レベルを提供します。 どちらのレベルも長期的なストレージのオプションですが、標準の方がコスト効率が高くなります。 パフォーマンスとスケーラビリティの制限について説明します。		 低

データは BLOB Storage に存在するため、パフォーマンスはそのプラットフォームによって制限されます。
コスト: 高

コストは、次の 2 つのコンポーネントで構成されます。
• インジェスト コスト。 基本ログに取り込まれるすべての GB 単位のデータは、Microsoft Sentinel および Azure Monitor ログのインジェスト コストの対象となります。これは合計すると約 $1/GB になります。 価格の詳細に関するページを参照してください。
• アーカイブ コスト。 アーカイブ レベルのデータのコストは、合計で 1 か月あたり約 $0.02/GB になります。 価格の詳細に関するページを参照してください。
データに頻繁にアクセスする必要がある場合は、これら 2 つのコスト コンポーネントに加えて、検索ジョブを使用してデータにアクセスするときに追加のコストが適用されます。		 高から低

• ADX は仮想マシンのクラスターであるため、コンピューティング、ストレージ、ネットワーク使用率に加え、ADX マークアップに基づいて課金されます (価格の詳細を参照してください)。 そのため、クラスターに追加するノードおよび格納するデータが多いほど、コストが高くなります。
• ADX は、必要なワークロードに適応する自動スケーリング機能も提供します。 ADX は、予約インスタンスの価格のメリットを得ることもできます。 Azure 料金計算ツールで自社のコスト計算を実行できます。		 低

最適なセットアップにすると、Azure Blob Storage のコストが最も低くなります。 効率を向上させ、コストを削減するために、Azure Storage ライフサイクル管理を使用して、古い BLOB をより安価なストレージ層に自動的に配置することができます。		 低

この場合、ADX はプロキシとしてのみ機能するため、クラスターを小さくすることができます。 さらに、データにアクセスする必要がない場合はクラスターをシャットダウンし、データ アクセスが必要な場合にのみクラスターを起動することができます。
データにアクセスする方法: 検索ジョブ 直接 KQL クエリ externaldata 変更されたKQL クエリ
シナリオ: 不定期アクセス

負荷の高い分析を実行したり、分析ルールをトリガーしたりする必要がなく、ときどきデータにアクセスする必要があるようなシナリオに関連しています。		 頻繁なアクセス

データに頻繁にアクセスする必要があり、クラスターのサイズと構成方法を制御する必要があるシナリオに関連しています。		 コンプライアンス/監査

• 大量の非構造化データを格納するのに最適です。
• コンプライアンスや監査を目的とする場合など、データへの迅速なアクセスや高いパフォーマンスが不要なシナリオに関連しています。		 不定期アクセス

低コストの Azure Blob Storage のメリットを得て、データへの比較的迅速なアクセスを維持するシナリオに関連しています。
複雑さ: 非常に低い Medium 低 高
対応性: GA GA GA GA

一般的な考慮事項

使用可能なターゲット プラットフォームの詳細がわかったので、最終的な決定を行うために、次の主な要因を確認しましょう。

取り込まれたログの使用

インジェスト プラットフォームの選択のガイドになるように、取り込まれたログを組織で使用する方法を定義します。

次の 3 つの一般的なシナリオを考えてください。

  • 組織は、コンプライアンスまたは監査の目的でのみログを保持する必要があります。 この場合、組織がデータにアクセスすることはめったにありません。 組織がデータにアクセスする場合でも、高いパフォーマンスや使いやすさは優先されません。
  • 組織は、チームが簡単かつ迅速にログにアクセスできるようにログを保持する必要があります。
  • 組織は、チームがときどきログにアクセスできるようにログを保持する必要があります。 パフォーマンスと使いやすさは二次的なものです。

これらの各シナリオに適したプラットフォームを理解するには、プラットフォームの比較を参照してください。

移行の速度

たとえば、ライセンスの有効期限が切れるために組織が以前の SIEM から緊急に移行する必要がある場合など、一部のシナリオでは、厳しい期限を守らなければならない場合があります。

移行の速度を決定するコンポーネントと要因を確認します。

データ ソース

通常、データ ソースはローカル ファイル システムまたはクラウド ストレージ (S3 など) です。 サーバーの記憶域のパフォーマンスは、ディスク テクノロジ (SSD と HDD)、IO 要求の性質、各要求のサイズなど、複数の要因によって異なります。

たとえば、Azure 仮想マシンのパフォーマンスの範囲は、小規模な VM SKU の 30 MB/秒から、NVM Express (NVMe) ディスクを使用するストレージ最適化 SKU の 20 GB/秒まであります。 高いストレージ パフォーマンスを実現するために Azure VM を設計する方法について説明します。 ほとんどの概念は、オンプレミス サーバーにも適用できます。

コンピューティング能力

場合によっては、ディスクでデータをすばやくコピーできる場合でも、コンピューティング能力がコピー処理のボトルネックになります。 このような場合は、次のスケーリング オプションのいずれかを選択できます。

  • 垂直方法のスケーリングする。 CPU を追加するか、CPU 速度を上げることで、1 台のサーバーの処理能力を増やします。
  • 水平方向にスケーリングする。 サーバーを追加することで、コピー処理の並列処理能力を増やします。

ターゲット プラットフォーム

このセクションで説明するターゲット プラットフォームごとに、パフォーマンス プロファイルが異なります。

データの量

データの量は、移行プロセスの期間に影響を与える主要な要因です。 そのため、データ セットに応じて環境を設定する方法を検討する必要があります。

移行の最短期間とボトルネックが発生する可能性がある場所を特定するには、データの量とターゲット プラットフォームの取り込み速度を考慮してください。 たとえば、1 秒あたり 1 GB を取り込むことができるターゲット プラットフォームを選択し、100 TB を移行する必要があるとします。 この場合、移行には少なくとも 100,000 GB に、1 秒あたり 1 GBの速度を掛けた量が必要です。 結果を 3600 で除算すると、計算結果は 27 時間になります。 この計算は、パイプライン内の残りのコンポーネント (ローカル ディスク、ネットワーク、仮想マシンなど) が 1 秒あたり 1 GB の速度で稼働できる場合に正しくなります。

次のステップ

この記事では、QRadar から Microsoft Sentinel に移行ルールをマップする方法について説明しました。

データ インジェスト ツールを選択する