Azure Data Lake Storage に関する主な考慮事項
Azure Storage には、データ用のさまざまなストレージ オプションが用意されています。 この記事では、コストとパフォーマンスのバランスを取ることができるように、適切なアクセス層を選択するのに役立つ考慮事項について説明します。 また、アクセス層を効果的に使用するのに役立つ機能やベスト プラクティスなど、Storage のライフサイクル管理についても説明します。
ライフサイクル管理
Azure Storage には、BLOB オブジェクト データの格納に使用できるさまざまなアクセス層が用意されています。 コストを最適化するために、ワークロードに最適なレベルを選択します。
頻繁にアクセスされるデータを格納するには、ホット 層 を使用します。
アクセス頻度の低いデータを格納するには、クール層 を使用します。 この層には、少なくとも 30 日間のデータが格納されます。
コールド 層 を使用して、アクセス頻度の低いデータまたは変更されたデータを格納します。 この層は、少なくとも 90 日間データを格納します。 コールド アクセス層は、クール アクセス層と比べてストレージ コストが安く、アクセス コストが高くなります。
アクセス頻度の低いデータを格納するには、アーカイブ層 を使用します。 この層は、少なくとも 180 日間データを格納します。 このデータにアクセスすると、柔軟な待機時間の要件が得られます。つまり、データの取得に数時間かかる場合があります。
重要
オンライン アクセス層 (ホット、クール、コールド) には、信頼性、セキュリティ、オペレーショナル エクセレンス、またはパフォーマンス効率のトレードオフはありません。 そのため、各 BLOB のコストに基づいて決定する必要があります。 ワークロード アクセスのデータ サイズ、操作上の相互作用、BLOB が削除されるまでの時間を検討します。 これらの要因に基づいて、BLOB ごとに適切な層 を選択します。 詳細については、「Azure Blob Storage のコストのプランと管理」を参照してください。
アクセス層を使用する場合は、次の要因を考慮してください。
アカウント レベルでホット アクセス層とクール アクセス層のみを設定します。 アカウント レベルでは、アーカイブ アクセス層はサポートされていません。
アップロード中またはアップロード後に、BLOB レベルでホット層、クール 層、アーカイブ層を設定します。
クール層とコールド 層のデータの可用性は若干低くなりますが、これらの層には、高い持続性、取得待ち時間、スループットなど、ホット 層と同様の機能が用意されています。 クール層またはコールド 層のデータの場合、可用性が低く、アクセス コストが高いほど、ホット 層と比較してストレージ コストが削減されるため、トレードオフが許容されます。
アーカイブ ストレージの場合、データはオフラインで格納され、ストレージ コストは最も低くなります。 しかし、データの再構築とアクセスにかかるコストが最も高くなります。
詳細については、「BLOB データ用のアクセス層」を参照してください。
重要
クラウド規模の分析の場合は、カスタム マイクロサービスを使用して、ライフサイクル管理を実装します。 ユーザーが検出できるデータをクール ストレージに移動する場合の影響を慎重に検討してください。 データ レイクのセクションをクール層に移動するのは、十分に理解されているワークロードの場合のみです。
Data Lake の接続
各データ レイクでは、データ ランディング ゾーンの仮想ネットワークに統合するプライベート エンドポイントを使用する必要があります。 ランディング ゾーンをまたぐアクセスを提供するためには、仮想ネットワーク ピアリングを介してデータ ランディング ゾーンを接続します。 この接続は、コストとアクセス制御の両方の観点から最適なソリューションを提供します。
詳細については、「プライベート エンドポイント」と「データ管理ランディング ゾーンからデータ ランディング ゾーンへ」を参照してください。
重要
データ ランディング ゾーンは、仮想ネットワーク ピアリングを介して別のデータ ランディング ゾーン内のデータにアクセスできます。 プライベート エンドポイントは、各データ レイク アカウントに関連付けられている接続を確立します。 湖へのパブリック アクセスをすべてオフにし、プライベート エンドポイントを使用することをお勧めします。 プラットフォーム運用チームは、データ ランディング ゾーン間のネットワーク接続を管理する必要があります。
コンテナーの論理的な削除
コンテナーの論理的な削除は、偶発的または悪意のある削除からデータを保護するのに役立ちます。 ストレージ アカウントに対してコンテナーの論理的な削除を有効にした場合、Storage は削除されたコンテナーとその内容を指定された期間保持します。 データ保有期間中は、以前に削除したコンテナーを復元できます。 このアクションでは、削除されたときにそのコンテナーにあった BLOB も復元されます。
次のデータ保護機能を有効にして、エンドツーエンドの BLOB データ保護を強化します。
ソフト削除を使用して削除されたコンテナーを復元します。 詳細については、「コンテナーの論理的な削除を有効にして管理する」を参照してください。
BLOB のソフト削除を使用して、削除された BLOB またはバージョンを復元します。 詳細については、BLOB の論理的な削除の有効化と管理に関するページを参照してください。
警告
ストレージ アカウントを削除した後は、削除を元に戻すことはできません。 コンテナーのソフト削除では、ストレージ アカウントの削除は保護されず、アカウント内のコンテナーの削除に対してのみ保護されます。 ストレージ アカウントを削除から保護するには、ストレージ アカウント リソースに対してロックを構成します。 詳細については、「リソースをロックして予期しない変更を防ぐ」を参照してください。
監視
データ ランディング ゾーンで、分析のために、すべての監視を Azure ランディング ゾーン管理サブスクリプションに送信します。
詳細については、「Azure Monitor を使用して Azure リソースを監視
ログ エントリは、サービス エンドポイントに対する要求に対してのみ作成されます。 次の種類の認証済み要求がログに記録されます。
- 成功した要求
- タイムアウト、調整、ネットワークの問題、承認の問題、その他のエラーなど、失敗した要求
- Shared Access Signature (SAS) または OAuth を使用した要求 (失敗した要求と成功した要求を含む)
$logsコンテナーの従来のログ データやテーブルのクラス メトリック データ$metricのような分析データに対する要求。
ストレージ サービスそのものによる要求 (ログの作成や削除など) は記録されません。 次の種類の匿名要求がログに記録されます。
- 成功した要求
- サーバー エラー
- クライアントとサーバーの両方のタイムアウト エラー
- エラー コード 304 (
Not Modified) を持つ失敗した HTTP GET 要求
失敗した他の匿名要求はログに記録されません。
重要
ストレージを監査し、ログをエンタープライズ規模の管理サブスクリプションに送信するように、既定の監視ポリシーを設定します。
Data Lake ゾーンのセキュリティ
Data Lake ゾーンには、次のセキュリティ パターンをお勧めします。
生の使用状況 では、セキュリティ プリンシパル名 (SPN) のみを使用してデータにアクセスできます。 マネージド ID を使用することをお勧めします。
エンリッチされた使用状況 では、SPN のみを使用してデータにアクセスできます。 マネージド ID を使用することをお勧めします。
キュレーションされた使用状況 では、SPN とユーザー プリンシパル名 (UPN) を使用してデータにアクセスできます。
詳細については、「Data Lake Storageでのアクセス制御モデルの