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のセキュリティ ベースラインを確認します。まず、Azure 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 分析情報 を使用して、使用しないアカウントまたは低使用率のアカウントを識別します。 BLOB インベントリ レポートを有効にし、Azure Databricks や Azure Synapse Analytics や Power BI を などのツールを使用してコスト データを分析します。 予期しない容量の増加に注意してください。これは、多数のログ ファイル、BLOB バージョン、または論理的に削除された BLOB を収集していることを示している可能性があります。 オブジェクトの有効期限が切れるか、よりコスト効率の高いアクセス層に移行するための戦略を策定します。オブジェクトの有効期限が切れるか、オブジェクトをより手頃な価格のアクセス層に移動するための計画を立てる。

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

ストレージ アカウントの正常性を監視する: 可用性、パフォーマンス、回復性のメトリックを監視するために、Storage 分析情報 ダッシュボードを作成します。 アラートを設定して、システム内の問題を特定して対処してから、顧客が問題に気付く前に対処します。 診断設定を使用して、リソース ログを 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の パフォーマンスとスケーラビリティのチェックリストを確認してください。 クエリ 高速化 を使用して、ストレージ要求中に不要なデータを除外し、クライアントがネットワーク経由で不必要にデータを転送しないようにすることを検討してください。

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