Azure Blob Storage に関する Azure Well-Architected Framework の観点

エラー モード分析の使用: 仮想ネットワーク、Azure Key Vault、Azure Content Delivery Network、Azure Front Door エンドポイントの可用性などの内部依存関係を考慮して、障害点を最小限に抑えます。 Blob Storage にアクセスするためにワークロードに必要な資格情報が Key Vault から不足している場合、または削除されたコンテンツ配信ネットワークに基づいてワークロードがエンドポイントを使用している場合、エラーが発生する可能性があります。 このような場合、ワークロードでは、接続に代替エンドポイントを使用することが必要になる場合があります。 障害モード分析の一般的な情報については、障害モード分析を実行するためのおすすめを参照してください。

信頼性と復旧のターゲットを 定義する: Azure サービス レベル アグリーメント (SLA) を確認します。 ストレージ アカウントのサービス レベル目標 (SLO) を派生させます。 たとえば、SLO は、選択した冗長性構成の影響を受ける可能性があります。 リージョンの停止の影響、データ損失の可能性、および停止後にアクセスを復元するために必要な時間を考慮してください。 また、障害モード分析の一部として識別した内部依存関係の可用性も考慮してください。

データの冗長性を構成する: 持続性を最大にするため、可用性ゾーンまたはグローバル リージョン間でデータをコピーする構成を選択します。 可用性を最大限に高めるために、プライマリ リージョンの停止中にクライアントがセカンダリ リージョンからデータを読み取る構成を選択します。

アプリケーションの設計: プライマリ リージョンが何らかの理由で使用できなくなった場合に、セカンダリ リージョンからのデータの読み取りにシームレスに移行するようにアプリケーション を設計します。 これは、geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージ (GZRS) の構成にのみ適用されます。 停止に対処するアプリケーションを設計すると、エンド ユーザーのダウンタイムが短縮されます。

復旧ターゲットを満たすのに役立つ機能について説明します。BLOB が誤って破損、編集、または削除された場合に回復できるように、BLOB を復元可能にします。

復旧計画を作成する: データ保護機能、バックアップと復元の操作、またはフェールオーバーの手順を検討します。 潜在的な データ損失とデータの 不整合、フェールオーバーの 時間とコストに備える。 詳細については、ディザスター リカバリー戦略の設計に関するおすすめを参照してください。

可用性の問題の可能性を監視する: Azure Service Health ダッシュボードをサブスクライブして、潜在的な可用性の問題を監視します。 Azure Monitor のストレージ メトリックと診断ログを使用して、アラートを調査します。

Azure Storage のセキュリティ ベースラインを確認する: 開始するには、まず Storage のセキュリティ ベースラインを確認します。

ネットワーク制御を使用してイングレス トラフィックとエグレス トラフィックを制限する: ストレージ アカウントへのすべてのパブリック トラフィックを無効にします。 アカウント ネットワーク制御を使用して、ユーザーとアプリケーションに必要な最小限のレベルのアクセス権を付与します。 詳細については、「ストレージ アカウントのネットワーク セキュリティにアプローチする方法」を参照してください。

攻撃対象領域を減らす: 匿名アクセス、アカウント キー アクセス、またはセキュリティで保護されていない (HTTP) 接続経由のアクセスを防ぐと、攻撃対象領域が減少する可能性があります。 トランスポート層セキュリティ (TLS) プロトコルの最新バージョンを使用して、クライアントにデータの送受信を要求します。

パスワードやキーを使用せずにアクセスを承認する: Microsoft Entra ID は、共有キーや共有アクセス署名と比較して優れたセキュリティと使いやすさを提供します。 セキュリティ プリンシパルに、タスクを実行するために必要なアクセス許可のみを付与します。

機密情報の保護: アカウント キーや Shared Access Signature トークンなどの機密情報を保護します。 通常、これらの形式の承認は推奨されませんが、ローテーション、期限切れ、および安全に保存する必要があります。

安全な転送が必要なオプションを有効にする: すべてのストレージ アカウントでこの設定を有効にすると、ストレージ アカウントに対して行われたすべての要求が、セキュリティで保護された接続を介して行われる必要があります。 HTTP 経由で行われた要求はすべて失敗します。

重要なオブジェクトを保護する: 不変ポリシーを適用して重要なオブジェクトを保護します。 ポリシーは、法的、コンプライアンス、またはその他のビジネス目的で格納されている BLOB が変更または削除されないように保護します。 設定された期間、または管理者によって制限が解除されるまで、保留を構成します。

脅威の検出: Microsoft Defender for Storage で脅威を検出できるようにします。 セキュリティ アラートは、アクティビティで異常が発生したときにトリガーされます。 アラートは、疑わしいアクティビティの詳細と、脅威の調査と修復方法に関する推奨事項を電子メールでサブスクリプション管理者に通知します。

請求書の計算に使用されるメーターを特定します。メーターは、アカウントに格納されているデータの量 (データ容量) と、データの書き込みと読み取りに実行される操作の数と種類を追跡するために使用されます。 また、BLOB インデックス タグ、BLOB インベントリ、変更フィードのサポート、暗号化スコープ、SSH ファイル転送プロトコル (SFTP) サポートなどのオプション機能の使用に関連するメーターもあります。 詳細については、「Blob Storage の課金方法」を参照してください。

各メーターの価格を理解する: 適切な価格ページを使用し、そのページで適切な設定を適用してください。 詳細については、各メーターの単価の検索を参照してください。 各価格に関連付けられている操作の数を検討してください。 たとえば、書き込み操作と読み取り操作に関連付けられている価格は、10,000 操作に適用されます。 個々の操作の価格を決定するには、表示価格を 10,000 で除算します。

容量と操作のコストを見積もる: Azure 料金計算ツールを使用して、データ ストレージ、イングレス、エグレスに関連するコストをモデル化できます。 フィールドを使用して、さまざまなリージョン、アカウントの種類、名前空間の種類、冗長性の構成に関連付けられているコストを比較します。 特定のシナリオでは、Microsoft ドキュメントで使用できるサンプル計算とワークシートを使用できます。 たとえば、データのアーカイブコストを見積もったり、AzCopy コマンドを使用して BLOB を転送したりするコストを見積もることができます。

容量の課金モデルを選択する: コミットメントベースのモデルを 使用する方が、従量課金ベースのモデル を使用するよりもコスト効率が高いかどうかを評価します。 必要な容量が不明な場合は、使用量ベースのモデルから開始し、容量メトリックを監視してから、後で評価できます。

アカウントの種類、冗長性レベル、および既定のアクセス層を選択します。ストレージ アカウントを作成するときは、これらの設定ごとに値を選択する必要があります。 すべての値は、トランザクションの料金と容量の料金に影響します。 アカウントの種類を除くこれらすべての設定は、アカウントの作成後に変更できます。

最もコスト効率の高い既定のアクセス層を選択します。BLOB のアップロードごとに層が指定されていない限り、BLOB は既定のアクセス層設定からアクセス層を推論します。 ストレージ アカウントの既定のアクセス層の設定を変更すると、アクセス層を明示的に設定していない、アカウント内のすべての BLOB に適用されます。 大量の BLOB を収集した場合、このコストは大きくなる可能性があります。 階層の変更が既存の各 BLOB に与える影響の詳細については、「BLOB のアクセス層の変更」を参照してください。

最もコスト効率の高いアクセス層にデータを直接アップロードする: たとえば、アカウントの既定のアクセス層の設定がホットであっても、アーカイブ目的でファイルをアップロードする場合は、アップロード操作の一環としてアーカイブまたはコールド層としてクール層を指定します。 BLOB をアップロードした後、ライフサイクル管理ポリシーを使用して、最後にアクセスした時刻などの使用状況メトリックに基づいて最もコスト効率の高い層に BLOB を移動します。 最適な層を前もって選択すると、コストを削減できます。 既にアップロードしたブロック BLOB の層を変更した場合は、最初に BLOB をアップロードするときに初期層に書き込むコストを支払い、次に目的の層に書き込むコストを支払います。

データ ライフサイクルを管理するための計画があります。アクセス層とライフサイクル管理を利用して、トランザクションと容量のコストを最適化します。 使用頻度の低いデータは、よりクールなアクセス層に配置する必要があります。一方、頻繁にアクセスされるデータは暖かいアクセス層に配置する必要があります。

必要な機能を決定します。バージョン管理や BLOB の論理的な削除などの一部の機能では、追加のトランザクションと容量のコストが発生し、その他の料金が発生します。 アカウントに追加する機能を選択する場合は、これらの機能について説明した記事の価格と課金のセクションを必ず確認してください。

たとえば、BLOB インベントリ機能を有効にした場合、スキャンされたオブジェクトの数に対して課金されます。 BLOB インデックス タグを使用する場合は、インデックス タグの数に対して課金されます。 SFTP のサポートを有効にした場合、SFTP 転送がない場合でも、時間単位の料金が課金されます。 機能を使用しない場合は、アカウントの作成時に一部の機能が自動的に有効になるため、機能が無効になっていることを確認します。

ガードレールの作成: サブスクリプションとリソース グループに基づいて予算を作成します。 ガバナンス ポリシーを使用して、リソースの種類、構成、場所を制限します。 さらに、RBAC を使用して、保留中を超える可能性があるアクションをブロックします。

コストの監視: コストが予算内に収まるようにし、コストと予測を比較し、超過支出が発生する場所を確認します。 Azure portal の [コスト分析 ] ウィンドウを使用して、コストを監視できます。 また、コスト データをストレージ アカウントにエクスポートし、Excel または Power BI を使用してそのデータを分析することもできます。

使用状況の監視: 使用状況パターンを継続的に監視し、未使用または使用率の低いアカウントとコンテナーを検出します。 Storage Insights を使用して、使用のないアカウントまたは低使用率のアカウントを識別します。 BLOB インベントリ レポートを有効にし、Azure Databricks や Azure Synapse Analytics、Power BI などのツールを使用してコスト データを分析します。 予期しない容量の増加に注意してください。これは、多数のログ ファイル、BLOB バージョン、または論理的に削除された BLOB を収集していることを示している可能性があります。 オブジェクトの有効期限が切れるか、よりコスト効率の高いアクセス層に移行するための戦略を策定します。オブジェクトの有効期限が切れるか、オブジェクトをより手頃な価格のアクセス層に移動するための計画を立てる。

メインテナントと緊急復旧計画を作成する: データ保護機能、バックアップと復元の操作、およびフェールオーバー手順を検討します。 潜在的な データ損失とデータの 不整合、フェールオーバーの 時間とコストに備える。

ストレージ アカウントの正常性を監視する: ストレージ分析情報ダッシュボードを作成して、可用性、パフォーマンス、回復性のメトリックを監視します。 アラートを設定して、システム内の問題を特定して対処してから、顧客が問題に気付く前に対処します。 診断設定を使用して、リソース ログを Azure Monitor ログ ワークスペースにルーティングします。 その後、ログにクエリを実行して、アラートをより深く調査できます。

BLOB インベントリ レポートを有効にする: BLOB インベントリ レポートを有効にして、ストレージ アカウントの内容の保持、訴訟ホールド、または暗号化の状態を確認します。 BLOB インベントリ レポートを使用して、データの合計データ サイズ、経過時間、階層分布、またはその他の属性を把握することもできます。 Azure Databricks や Azure Synapse Analytics、Power BI などのツールを使用して、インベントリ データをより適切に視覚化し、関係者向けのレポートを作成します。

BLOB を削除するか、コスト効率の高いアクセス層に移動するポリシーを設定します。初期の条件セットを使用してライフサイクル管理ポリシーを作成します。 ポリシー実行では、定義した条件に基づいて BLOB のアクセス層が自動的に削除または設定されます。 コスト効率を最適化するために条件を調整できるように、モニター メトリックと BLOB インベントリ レポートを使用してコンテナーの使用を定期的に分析します。

スケールの計画: ストレージ アカウントのスケール ターゲットについて説明します。

最適なストレージ アカウントの種類を選択します。ワークロードで高いトランザクション レート、小さいオブジェクト、および一貫して低いトランザクション待機時間が必要な場合は、Premium ブロック BLOB ストレージ アカウントの使用を検討してください。 ほとんどの場合、標準の汎用 v2 アカウントが最適です。

クライアントとサーバー間の移動距離を減らす: 接続しているクライアントに最も近いリージョン (理想的には同じリージョン) にデータを配置します。 オブジェクト レプリケーションまたはコンテンツ配信ネットワークを使用して、遠くのリージョンのクライアントに対して最適化します。 既定のネットワーク構成は、最適なパフォーマンスを提供します。 セキュリティを向上させるためにのみ、ネットワーク設定を変更します。 一般に、ネットワーク設定では移動距離が減少せず、パフォーマンスが向上しません。

効率的な名前付けスキームを選択する: BLOB パーティション キーの先頭に最も近いハッシュ タグ プレフィックス (アカウント、コンテナー、仮想ディレクトリ、または BLOB 名) を使用して、一覧表示、一覧表示、クエリ、読み取り操作の待機時間を短縮します。 このスキームは、主にフラットな名前空間を持つアカウントにメリットがあります。

データ クライアントのパフォーマンスを最適化する: ワークロードのデータ サイズ、転送頻度、帯域幅に最適なデータ転送ツール を選択します。 AzCopy などの一部のツールはパフォーマンス用に最適化されており、介入はほとんど必要ありません。 待機時間に影響を与える要因を検討し、各ツールで公開されているパフォーマンス最適化ガイダンスを確認してパフォーマンスを微調整します。

カスタム コードのパフォーマンスを最適化する: BLOB REST 操作用の独自のラッパーを作成する代わりに、Storage SDK を使用することを検討してください。 Azure SDK はパフォーマンス用に最適化されており、パフォーマンスを微調整するためのメカニズムを提供します。 アプリケーションを作成する前に、Blob Storage のパフォーマンスとスケーラビリティのチェックリストを確認します。 クエリ アクセラレーションを使用して、ストレージ要求中に不要なデータを除外し、クライアントがネットワーク経由で不必要にデータを転送しないようにすることを検討してください。

パフォーマンス データの収集: ストレージ アカウントを監視して、調整によって発生するパフォーマンスのボトルネックを特定します。 詳細については、「ストレージ分析情報の監視を使用したストレージ サービスの監視」を参照してください。 メトリックとログの両方を使用します。 メトリックは、調整エラーなどの数値を提供します。 ログにはアクティビティが記述されています。 調整メトリックが表示された場合は、ログを使用して、調整エラーを受信しているクライアントを識別できます。 詳細については、「データ プレーン操作の監査」を参照してください。