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