Azure Blob Storage に関する Azure Well-Architected Framework の観点
Azure Blob Storage は、クラウド用の Microsoft オブジェクト ストレージ ソリューションです。 Blob Storage は大量の非構造化データを格納するために最適化されます。 非構造化データは、特定のデータ モデルまたは定義に従っていないデータ (テキスト データやバイナリ データなど) です。
この記事では、アーキテクトとしてストレージ オプションを確認し、ワークロードを実行するストレージ サービスとして Blob Storage を選択したことを前提としています。 この記事のガイダンスでは、Azure Well-Architected Framework の柱の 原則にマップされるアーキテクチャに関する推奨事項を示します。
重要
このガイドの使用方法
各セクションには、設計戦略と共に関心のあるアーキテクチャ領域を示す設計チェックリストがあります。
また、 これらの戦略の 実装に役立つテクノロジ機能に関する推奨事項も含まれています。 推奨事項は、Blob Storage とその依存関係で使用できるすべての構成の完全な一覧を表すわけではありません。 代わりに、設計パースペクティブにマップされた主要な推奨事項が一覧表示されます。 推奨事項を使用して概念実証を構築するか、既存の環境を最適化します。
信頼性
信頼性の柱の目的は、十分な回復性と障害から迅速に回復する機能を構築することで 、継続的な機能を提供することです。
信頼性設計の原則は 、 個々のコンポーネント、システム フロー、およびシステム全体に適用される高度な設計戦略を提供します。
設計チェック リスト
信頼性の設計レビュー チェックリストに基づいて、設計戦略を開始します。
エラー モード分析の使用: 仮想ネットワーク、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 のストレージ メトリックと診断ログを使用して、アラートを調査します。
推奨事項
| 推奨事項 | 特長 |
|---|---|
| 冗長性を確保するためにアカウントを構成します。 可用性と持続性を最大限に高める場合は、ゾーン冗長ストレージ (ZRS) または GZRS を使用してアカウントを構成します。 |
冗長性により、予期しない障害からデータが保護されます。 ZRS と GZRS の構成オプションは、異なる可用性ゾーン間でレプリケートされ、停止中にアプリケーションがデータの読み取りを続行できるようにします。 詳細については、停止シナリオ別の持続性と可用性、および持続性と可用性のパラメーターに関する説明を参照してください。 |
| フェールオーバーまたはフェールバックを開始する前に、最後の同期時刻プロパティの値をチェックして、データ損失の可能性を評価します。 この推奨事項は、GRS および GZRS 構成にのみ適用されます。 | このプロパティは、アカウントのフェールオーバーを開始することによって失われる可能性があるデータの量を見積もるのに役立ちます。 最後の同期時刻より前に書き込まれたデータとメタデータはすべてセカンダリ リージョンで使用できますが、最後の同期時刻より後に書き込まれたデータとメタデータは、セカンダリ リージョンに書き込まれていないため失われる可能性があります。 |
| バックアップと復旧の戦略の一環として、コンテナーの論理的な削除、BLOB の論理的な削除、バージョン管理、および特定の時点の復元オプションを有効にします。 | 論理的な削除オプションを使用すると、ストレージ アカウントで削除されたコンテナーと BLOB を回復できます。 バージョン管理オプションは、BLOB に加えられた変更を自動的に追跡します。 このオプションを使用すると、BLOB を以前の状態に復元できます。 ポイントインタイム リストア オプションを使用すると、誤った BLOB の削除や破損から保護し、ブロック BLOB データを以前の状態に復元できます。 詳細については、「データ保護の概要」を参照してください。 |
セキュリティ
セキュリティの柱の目的は、機密性、整合性、可用性の保証をワークロードに提供することです。
セキュリティ設計原則は 、 Blob Storage 構成の技術的な設計にアプローチを適用することで、これらの目標を達成するための高度な設計戦略を提供します。
設計チェック リスト
セキュリティの設計レビュー チェックリストに基づいて、設計戦略を開始します。 セキュリティ体制を改善するための脆弱性と制御を特定します。 必要に応じて、より多くのアプローチを含むように戦略を拡張します。
Azure Storage のセキュリティ ベースラインを確認する: 開始するには、まず Storage のセキュリティ ベースラインを確認します。
ネットワーク制御を使用してイングレス トラフィックとエグレス トラフィックを制限する: ストレージ アカウントへのすべてのパブリック トラフィックを無効にします。 アカウント ネットワーク制御を使用して、ユーザーとアプリケーションに必要な最小限のレベルのアクセス権を付与します。 詳細については、「ストレージ アカウントのネットワーク セキュリティにアプローチする方法」を参照してください。
攻撃対象領域を減らす: 匿名アクセス、アカウント キー アクセス、またはセキュリティで保護されていない (HTTP) 接続経由のアクセスを防ぐと、攻撃対象領域が減少する可能性があります。 トランスポート層セキュリティ (TLS) プロトコルの最新バージョンを使用して、クライアントにデータの送受信を要求します。
パスワードやキーを使用せずにアクセスを承認する: Microsoft Entra ID は、共有キーや共有アクセス署名と比較して優れたセキュリティと使いやすさを提供します。 セキュリティ プリンシパルに、タスクを実行するために必要なアクセス許可のみを付与します。
機密情報の保護: アカウント キーや Shared Access Signature トークンなどの機密情報を保護します。 通常、これらの形式の承認は推奨されませんが、ローテーション、期限切れ、および安全に保存する必要があります。
安全な転送が必要なオプションを有効にする: すべてのストレージ アカウントでこの設定を有効にすると、ストレージ アカウントに対して行われたすべての要求が、セキュリティで保護された接続を介して行われる必要があります。 HTTP 経由で行われた要求はすべて失敗します。
重要なオブジェクトを保護する: 不変ポリシーを適用して重要なオブジェクトを保護します。 ポリシーは、法的、コンプライアンス、またはその他のビジネス目的で格納されている BLOB が変更または削除されないように保護します。 設定された期間、または管理者によって制限が解除されるまで、保留を構成します。
脅威の検出: Microsoft Defender for Storage で脅威を検出できるようにします。 セキュリティ アラートは、アクティビティで異常が発生したときにトリガーされます。 アラートは、疑わしいアクティビティの詳細と、脅威の調査と修復方法に関する推奨事項を電子メールでサブスクリプション管理者に通知します。
推奨事項
| 推奨事項 | 特長 |
|---|---|
| コンテナーと BLOB への匿名読み取りアクセスを無効にします。 | ストレージ アカウントに対して匿名アクセスが許可されている場合、適切なアクセス許可を持つユーザーは、コンテナーの匿名アクセス設定を変更して、そのコンテナー内のデータへの匿名アクセスを有効にすることができます。 |
| ストレージ アカウントに Azure Resource Manager ロックを適用します。 | アカウントをロックすると、アカウントが削除され、データが失われるのを防ぐことができます。 |
| ストレージ アカウントのパブリック エンドポイント へのトラフィックを無効にします。 Azure で実行されるクライアントのプライベート エンドポイントを作成します。 Azure 外部のクライアントとサービスがストレージ アカウントへの直接アクセスを必要とする場合にのみ、パブリック エンドポイントを有効にします。 特定の仮想ネットワークへのアクセスを制限するファイアウォール規則を有効にします。 | ゼロ アクセスから開始し、クライアントとサービスに必要な最小レベルのアクセスを段階的に承認して、攻撃者に不要な開口部を作成するリスクを最小限に抑えます。 |
| Azure ロールベースのアクセス制御 (RBAC) を使用してアクセスを承認します。 | RBAC では、侵害される可能性のあるパスワードやキーはありません。 セキュリティ プリンシパル (ユーザー、グループ、マネージド ID、またはサービス プリンシパル) は、OAuth 2.0 トークンを返すために Microsoft Entra ID によって認証されます。 トークンは、Blob Storage サービスに対する要求を承認するために使用されます。 |
| 共有キーの承認を許可しない。 これにより、アカウント キーアクセスだけでなく、サービスおよびアカウント共有アクセス署名トークンも無効になります。これは、アカウント キーに基づいているためです。 | Microsoft Entra ID で承認されているセキュリティで保護された要求のみが許可されます。 |
| アカウント キーは使用しないことをお勧めします。 アカウント キーを使用する必要がある場合は、 Key Vault に格納し、定期的に再生成してください。 | Key Vault を使用すると、アプリケーションを使用してキーを保存するのではなく、実行時にキーを取得できます。 また、Key Vault を使用すると、アプリケーションを中断することなく、キーを簡単にローテーションできます。 アカウント キーを定期的にローテーションすると、悪意のある攻撃にデータが公開されるリスクが軽減されます。 |
| Shared Access Signature トークンは使用しないことをお勧めします。 Blob Storage リソースへのアクセスをセキュリティで保護するために、Shared Access Signature トークンが必要かどうかを評価します。 作成する必要がある場合は、作成して配布する前に、この共有アクセス署名のベスト プラクティスの一覧を確認してください。 | ベスト プラクティスは、共有アクセス署名トークンが漏洩するのを防ぎ、リークが発生した場合に迅速に復旧するのに役立ちます。 |
| クライアントが TLS 1.2 の最小バージョンを使用してデータを送受信できるように、ストレージ アカウント を構成します。 | 最新の暗号アルゴリズムと暗号スイートをサポートしていない TLS 1.0 および 1.1 よりも、TLS 1.2 の方が安全性が高く高速です。 |
| ストレージ アカウント内のデータを保護するには、独自の暗号化キーを使用することを検討してください。 詳細については、「Azure Storage 暗号化のカスタマー マネージド キー」を参照してください。 | カスタマー マネージド キーは、より高い柔軟性と制御を提供します。 たとえば、Key Vault に暗号化キーを格納し、自動的にローテーションすることができます。 |
コストの最適化
コストの最適化では 、支出パターンの検出、重要な領域への投資の優先順位付け、組織の予算とビジネス要件を満たすために他のユーザー での最適化に重点を置いています。
コスト最適化の設計原則は 、 Blob Storage とその環境に関連する技術的な設計において、これらの目標を達成し、必要に応じてトレードオフを行う高度な設計戦略を提供します。
設計チェック リスト
投資のコスト最適化の設計レビュー チェックリストに基づいて、設計戦略を開始します。 ワークロードがワークロードに割り当てられている予算に合わせて設計を微調整します。 設計では、適切な Azure 機能を使用し、投資を監視し、時間の経過と同時に最適化する機会を見つける必要があります。
請求書の計算に使用されるメーターを特定します。メーターは、アカウントに格納されているデータの量 (データ容量) と、データの書き込みと読み取りに実行される操作の数と種類を追跡するために使用されます。 また、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 を収集していることを示している可能性があります。 オブジェクトの有効期限が切れるか、よりコスト効率の高いアクセス層に移行するための戦略を策定します。オブジェクトの有効期限が切れるか、オブジェクトをより手頃な価格のアクセス層に移動するための計画を立てる。
推奨事項
| 推奨事項 | 特長 |
|---|---|
| よりクールな階層に移動する前に、小さなファイルを大きなファイル にパックします。 TAR や ZIP などのファイル形式を使用できます。 | クール層では、データ転送コストが高くなります。 大きなファイルを減らすことで、データ転送に必要な操作の数を減らすことができます。 |
| アーカイブ ストレージから BLOB をリハイドレートする場合は、標準優先度のリハイドレートを使用します。 緊急データ復元の状況でのみ、優先度の高いリハイドレートを使用します。 詳細については、「アーカイブされた BLOB をオンライン層にリハイドレートする」を参照してください 。 | アーカイブ層からの優先順位の高いリハイドレートは、通常よりも高い請求につながる可能性があります。 |
| 適切なログ ストレージの場所を選択し、ログ保有期間を管理することで、リソース ログの使用コストを削減します。 ログのクエリを定期的に行うだけの場合 (コンプライアンス監査のログのクエリなど)、Azure Monitor ログ ワークスペースにリソース ログを送信するのではなく、ストレージ アカウントにリソース ログを送信することを検討してください。 Azure Synapse Analytics などのサーバーレス クエリ ソリューションを使用してログを分析できます。 詳細については、「頻度の低いクエリのコストを最適化する」を参照してください。 ライフサイクル管理ポリシーを使用して、ログを削除またはアーカイブします。 | 後で分析するためにストレージ アカウントにリソース ログを格納する方が安価なオプションです。 ライフサイクル管理ポリシーを使用してストレージ アカウントのログリテンション期間を管理すると、大量のログ ファイルが時間の経過と同時に蓄積されなくなり、不要な容量料金が発生する可能性があります。 |
| バージョン管理を有効にする場合は、ライフサイクル管理ポリシーを使用して、古い BLOB バージョンを自動的に削除します。 | BLOB に対するすべての書き込み操作で、新しいバージョンが作成されます。 これにより、容量コストが増加します。 不要になったバージョンを削除することで、コストをチェックに維持できます。 |
| バージョン管理を有効にする場合は、頻繁に上書きされる BLOB を、バージョン管理が有効になっていないアカウントに配置します。 | BLOB が上書きされるたびに、新しいバージョンが追加され、ストレージ容量の料金が増加します。 容量の料金を削減するには、頻繁に上書きされるデータを、バージョン管理が無効になっている別のストレージ アカウントに格納します。 |
| 論理的な削除を有効にする場合は、頻繁に上書きされる BLOB を、論理的な削除が有効になっていないアカウントに配置します。 保持期間を設定します。 この機能が請求書に与える影響をより深く理解するには、短い保有期間から始めてみてください。 推奨される最小保持期間は 7 日です。 | BLOB が上書きされるたびに、新しいスナップショットが作成されます。 これらのスナップショットの作成がログに表示されないため、容量料金の増加の原因はアクセスが困難な場合があります。 容量の料金を削減するには、頻繁に上書きされるデータを、論理的な削除が無効になっている別のストレージ アカウントに格納します。 保有期間により、論理的に削除された BLOB が積み上がって容量のコストが増えるのを防ぐ。 |
| SFTP サポートは、データの転送に使用される場合にのみ有効にします。 | SFTP エンドポイントを有効にすると、時間単位のコストがかかります。 SFTP サポートを慎重に無効にし、必要に応じて有効にすると、アカウントにパッシブ料金が発生しないようにすることができます。 |
| 不要な料金を回避するために必要のない暗号化スコープを無効にします。 | 暗号化スコープには、1 か月あたりの料金が発生します。 |
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、主に開発プラクティス、可観測性、リリース管理の手順に重点を置いています。
オペレーショナル エクセレンス設計原則は 、 ワークロードの運用要件に対してこれらの目標を達成するための高度な設計戦略を提供します。
設計チェック リスト
Blob Storage 構成に関連する監視、テスト、デプロイのプロセスを定義するためのオペレーショナル エクセレンスの設計レビュー チェックリストに基づいて、設計戦略を開始します。
メインテナントと緊急復旧計画を作成する: データ保護機能、バックアップと復元の操作、およびフェールオーバー手順を検討します。 潜在的な データ損失とデータの 不整合、フェールオーバーの 時間とコストに備える。
ストレージ アカウントの正常性を監視する: ストレージ分析情報ダッシュボードを作成して、可用性、パフォーマンス、回復性のメトリックを監視します。 アラートを設定して、システム内の問題を特定して対処してから、顧客が問題に気付く前に対処します。 診断設定を使用して、リソース ログを Azure Monitor ログ ワークスペースにルーティングします。 その後、ログにクエリを実行して、アラートをより深く調査できます。
BLOB インベントリ レポートを有効にする: BLOB インベントリ レポートを有効にして、ストレージ アカウントの内容の保持、訴訟ホールド、または暗号化の状態を確認します。 BLOB インベントリ レポートを使用して、データの合計データ サイズ、経過時間、階層分布、またはその他の属性を把握することもできます。 Azure Databricks や Azure Synapse Analytics、Power BI などのツールを使用して、インベントリ データをより適切に視覚化し、関係者向けのレポートを作成します。
BLOB を削除するか、コスト効率の高いアクセス層に移動するポリシーを設定します。初期の条件セットを使用してライフサイクル管理ポリシーを作成します。 ポリシー実行では、定義した条件に基づいて BLOB のアクセス層が自動的に削除または設定されます。 コスト効率を最適化するために条件を調整できるように、モニター メトリックと BLOB インベントリ レポートを使用してコンテナーの使用を定期的に分析します。
推奨事項
| 推奨事項 | 特長 |
|---|---|
| コードとしてのインフラストラクチャ (IaC) を使用して、Azure Resource Manager テンプレート (ARM テンプレート)、Bicep、または Terraform でストレージ アカウントの詳細を定義します。 | 既存の DevOps プロセスを使用して新しいストレージ アカウントをデプロイし、Azure Policy を使用して構成を適用できます。 |
| Storage Insights を使用して、ストレージ アカウントの正常性とパフォーマンスを追跡します。 Storage Insights は、すべてのストレージ アカウントの障害、パフォーマンス、可用性、容量の統合ビューを提供します。 | 各アカウントの正常性と操作を追跡できます。 利害関係者がストレージ アカウントの正常性を追跡するために使用できるダッシュボードとレポートを簡単に作成できます。 |
パフォーマンス効率
パフォーマンス効率は、容量メイン管理して負荷が増加した場合でも、ユーザー エクスペリエンスを維持することです。 この戦略には、リソースのスケーリング、潜在的なボトルネックの特定と最適化、ピーク パフォーマンスの最適化が含まれます。
パフォーマンス効率設計の原則は 、 予想される使用に対してこれらの容量目標を達成するための高度な設計戦略を提供します。
設計チェック リスト
パフォーマンス効率の設計レビューチェックリストに基づいて、設計戦略を開始します。 Blob Storage 構成の主要業績評価指標に基づくベースラインを定義します。
スケールの計画: ストレージ アカウントのスケール ターゲットについて説明します。
最適なストレージ アカウントの種類を選択します。ワークロードで高いトランザクション レート、小さいオブジェクト、および一貫して低いトランザクション待機時間が必要な場合は、Premium ブロック BLOB ストレージ アカウントの使用を検討してください。 ほとんどの場合、標準の汎用 v2 アカウントが最適です。
クライアントとサーバー間の移動距離を減らす: 接続しているクライアントに最も近いリージョン (理想的には同じリージョン) にデータを配置します。 オブジェクト レプリケーションまたはコンテンツ配信ネットワークを使用して、遠くのリージョンのクライアントに対して最適化します。 既定のネットワーク構成は、最適なパフォーマンスを提供します。 セキュリティを向上させるためにのみ、ネットワーク設定を変更します。 一般に、ネットワーク設定では移動距離が減少せず、パフォーマンスが向上しません。
効率的な名前付けスキームを選択する: BLOB パーティション キーの先頭に最も近いハッシュ タグ プレフィックス (アカウント、コンテナー、仮想ディレクトリ、または BLOB 名) を使用して、一覧表示、一覧表示、クエリ、読み取り操作の待機時間を短縮します。 このスキームは、主にフラットな名前空間を持つアカウントにメリットがあります。
データ クライアントのパフォーマンスを最適化する: ワークロードのデータ サイズ、転送頻度、帯域幅に最適なデータ転送ツール を選択します。 AzCopy などの一部のツールはパフォーマンス用に最適化されており、介入はほとんど必要ありません。 待機時間に影響を与える要因を検討し、各ツールで公開されているパフォーマンス最適化ガイダンスを確認してパフォーマンスを微調整します。
カスタム コードのパフォーマンスを最適化する: BLOB REST 操作用の独自のラッパーを作成する代わりに、Storage SDK を使用することを検討してください。 Azure SDK はパフォーマンス用に最適化されており、パフォーマンスを微調整するためのメカニズムを提供します。 アプリケーションを作成する前に、Blob Storage のパフォーマンスとスケーラビリティのチェックリストを確認します。 クエリ アクセラレーションを使用して、ストレージ要求中に不要なデータを除外し、クライアントがネットワーク経由で不必要にデータを転送しないようにすることを検討してください。
パフォーマンス データの収集: ストレージ アカウントを監視して、調整によって発生するパフォーマンスのボトルネックを特定します。 詳細については、「ストレージ分析情報の監視を使用したストレージ サービスの監視」を参照してください。 メトリックとログの両方を使用します。 メトリックは、調整エラーなどの数値を提供します。 ログにはアクティビティが記述されています。 調整メトリックが表示された場合は、ログを使用して、調整エラーを受信しているクライアントを識別できます。 詳細については、「データ プレーン操作の監査」を参照してください。
推奨事項
| 推奨事項 | 特長 |
|---|---|
| 依存リソースが配置されているのと同じリージョンにストレージ アカウントをプロビジョニングします。 モバイル デバイス アプリやオンプレミスのエンタープライズ サービスなど、Azure でホストされていないアプリケーションの場合は、それらのクライアントに近いリージョンでストレージ アカウントを見つけます。 詳しくは、「Azure の地域」をご覧ください。 別のリージョンのクライアントが同じデータを必要としない場合は、リージョンごとに個別のアカウントを作成します。 別のリージョンのクライアントで一部のデータのみが必要な場合は、オブジェクト レプリケーション ポリシーを使用して、関連するオブジェクトを他のリージョンのストレージ アカウントに非同期的にコピーすることを検討してください。 |
ストレージ アカウントと VM、サービス、およびオンプレミス クライアントの間の物理的な距離を減らすと、パフォーマンスが向上し、ネットワーク待機時間が短縮されます。 物理的な距離を減らすと、1 つのリージョン内の帯域幅の使用量が無料になるため、Azure でホストされているアプリケーションのコストも削減されます。 |
| Web クライアント (ストリーミング ビデオ、オーディオ、または静的な Web サイト コンテンツ) による広範な使用については、Azure Front Door を介したコンテンツ配信ネットワークの使用を検討してください。 | コンテンツは、世界中の何百ものグローバルおよびローカルのプレゼンス ポイントを持つ Microsoft グローバル エッジ ネットワークを使用するため、クライアントにすばやく配信されます。 |
| BLOB のパーティション キーにできるだけ早くハッシュ文字シーケンス (3 桁など) を追加します。 パーティション キーは、アカウント名、コンテナー名、仮想ディレクトリ名、BLOB 名です。 名前にタイムスタンプを使用する場合は、そのスタンプの先頭に秒の値を追加することを検討してください。 詳細については、「パーティション分割」を参照してください。 | パーティション キーの先頭に最も近いハッシュ コードまたは秒の値を使用すると、クエリと読み取り BLOB の一覧表示に必要な時間が短縮されます。 |
| BLOB またはブロックをアップロードするときは、256 KiB を超える BLOB またはブロック サイズを使用します。 | 256 KiB を超える BLOB またはブロック サイズは、より大きな BLOB とブロック サイズ専用に行われたプラットフォームでのパフォーマンスの強化を利用します。 |
Azure のポリシー
Azure には、Blob Storage とその依存関係に関連する広範な組み込みポリシー セットが用意されています。 上記の推奨事項の一部は、Azure ポリシーを使用して監査できます。 たとえば、次の場合にチェックできます。
- コンテナーと BLOB への匿名パブリック読み取りアクセスが有効になっていません。
- Blob Storage の診断設定は、リソース ログを Azure Monitor ログ ワークスペースにストリーミングするように設定されます。
- セキュリティで保護された接続 (HTTPS) からの要求のみが受け入れられます。
- Shared Access Signature の有効期限ポリシーが有効になっています。
- テナント間オブジェクトレプリケーションが無効になっています。
- 共有キーの承認が無効になっています。
- ネットワーク ファイアウォール規則がアカウントに適用されます。
包括的なガバナンスについては、ストレージの Azure Policy 組み込み定義と、コンピューティング レイヤーのセキュリティに影響する可能性があるその他のポリシーを確認します。
Azure Advisor の推奨事項
Azure Advisor は、ベスト プラクティスに従って Azure デプロイメントを最適化できるようにする、個人用に設定されたクラウド コンサルタントです。 Blob Storage の信頼性、セキュリティ、コスト効率、パフォーマンス、オペレーショナル エクセレンスの向上に役立つ推奨事項をいくつか次に示します。