Azure Blob Storage についてよく寄せられる質問

ポリシーの構成後、有効になるまでに最大 24 時間かかることがあります。 ポリシーが有効になると、アクションの実行にかかる時間は、ストレージ アカウントのサイズと実行される操作によって異なる場合があります。

更新されたポリシーは、有効になるまで最大 24 時間かかります。 ポリシーが有効になると、アクションの実行にかかる時間は、ストレージ アカウントのサイズと実行される操作によって異なります。 更新がルールを無効化または削除するものであり、enableAutoTierToHotFromCool が使用されていた場合、ホット層への自動階層化は依然として発生します。 たとえば、最後のアクセスに基づき、enableAutoTierToHotFromCool を含むルールが設定されます。 このルールが無効化または削除されていて、BLOB が現在クールまたはコールド層にあり、アクセスされると、BLOB はホット層に戻されます。このルールがライフサイクル管理外のアクセスに対して適用されるためです。 ライフサイクル管理ルールが無効化または削除されていると、その後、BLOB はホット層からクールまたはコールド層に移動しません。 autoTierToHotFromCool を回避する唯一の方法は、最終アクセス時刻の追跡をオフにすることです。

ストレージ アカウントに含まれるオブジェクトのサイズや数によっては、全オブジェクトを処理するために複数の実行が必要になることがあります。 また、ストレージ リソース ログを確認して、ライフサイクル管理ポリシーによって操作が実行されているかどうかを確認することもできます。

ストレージ アカウントで論理的な削除やバージョン管理などのデータ保護機能が有効になっているかどうかを確認します。 ポリシーが BLOB を削除している場合でも、これらの BLOB は、これらの機能の構成方法によっては、論理的に削除された状態または古いバージョンとして存在する可能性があります。

ストレージ アカウントに対するライフサイクル管理ポリシーが有効な場合、層を変更して BLOB をリハイドレートすると、ライフサイクル ポリシーによって BLOB がアーカイブ層に戻されるというシナリオが発生する可能性があります。 これは、最終更新時刻、作成時刻、または最終アクセス時刻がポリシーに設定されたしきい値を超えている場合に発生する可能性があります。 この問題が発生しないようにするには、次の 3 つの方法があります。

• daysAfterLastTierChangeGreaterThan 条件を tierToArchive アクションに追加します。 「ライフサイクル管理ポリシーを使用して BLOB をアーカイブする」を参照してください。

• この BLOB に影響を与えるルールを一時的に無効にして、再びアーカイブされないようにします。 BLOB が安全にアーカイブ層に移動されたら、ルールを再度有効にします。

• BLOB をホット層、クール層、またはコールド層に永続的に保持する必要がある場合は、ライフサイクル管理ポリシーが有効でない別の場所に BLOB をコピーします。

ポリシーの BLOB プレフィックス一致フィールドは BLOB の完全または部分的なパスであり、ポリシーのアクションを適用したい BLOB に照合するために使用します。 パスは、コンテナー名で始まる必要があります。 プレフィックス一致が指定されていない場合、ポリシーはストレージ アカウントのすべての BLOB に適用されます。 プレフィックス一致文字列の形式は [container name]/[blob name]です。
プレフィックス一致文字列について以下の点に注意してください:

• container1/ のようなプレフィックス一致文字列は、container1 という名前のコンテナー内のすべての BLOB に適用されます。 後続のスラッシュ文字 (/) のない container1 のプレフィックス一致文字列は、コンテナー名が文字列 container1 で始まるすべてのコンテナー内のすべての BLOB に適用されます。 プレフィックスは、 container11、 container1234、container1ab などの名前の コンテナーと一致します。
• container1/sub1/ のプレフィックス一致文字列は、文字列 sub1/で始まる container1 という名前のコンテナー内のすべての BLOB に適用されます。 たとえば、プレフィックスは container1/sub1/test.txtまたは container1/sub1/ sub2/test.txtという名前の BLOB と一致します。
• アスタリスク文字 * は、 BLOB 名で有効な文字です。 プレフィックスにアスタリスク文字が使用されている場合、プレフィックスは、名前にアスタリスクを持つ BLOB と一致します。 アスタリスクはワイルドカード文字として機能しません。
• 疑問符文字 ? は、BLOB 名で有効な文字です。 プレフィックスに疑問符文字が使用されている場合、プレフィックスは名前に疑問符が付いた BLOB と一致します。 疑問符はワイルドカード文字として機能しません。
• プレフィックスの一致では、正の (=) 論理比較のみが考慮されます。 負の (!=) 論理比較は無視されます。
• プレフィックスの一致は、大文字と小文字が区別される方法で動作します。

残念ながら、バックグラウンド スケジューリング プロセスであるため、ポリシーが実行される time を追跡する方法はありません。 ただし、プラットフォームは 1 日に 1 回ポリシーを実行します。

日次インベントリ ルールは、毎日 1 回実行するように設計されています。 さらに、毎週日曜日にスケジュールされる週次インベントリ ルールがあります。

一貫したエクスペリエンスを提供するよう努めていますが、各実行の正確な実行時刻を保証することはできません。 インベントリ ルールの実行時刻は異なる場合があります。 たとえば、今日はポリシーが午前 0 時 5 分にスケジュールされたとしても、明日以降は午前 0 時 7 分、午前 0 時 15 分、または他の時刻に開始される可能性があります。

BLOB インベントリ レポートでは、3 種類のファイルが生成されます。 インベントリ ファイルを参照してください。 BLOB インベントリを使用している既存のお客様は、1 つのファイルから複数のファイルにインベントリ ファイルの数が変化したことに気付いたかもしれません。 現在、ファイルの一覧を提供するマニフェスト ファイルが既に用意されています。 この動作は変更されないため、これらのファイルはマニフェスト ファイルに一覧表示されます。

この変更は、特に 500 万を超えるオブジェクトを含む大規模なストレージ アカウントに対して、BLOB インベントリのパフォーマンスを向上させるために実装されました。 これで、結果が複数のファイルに並列に書き込まれ、1 つのインベントリ ファイルを使用するボトルネックが解消されます。 この変更は、単一の非常に大きなインベントリファイルを開いて操作するのが困難であるというお客様からのフィードバックによって行われたものです。

この変更は、ユーザーとしてのお客様の BLOB インベントリの実行に関するエクスペリエンスにプラスの影響を与えます。 これはパフォーマンスを向上させ、全体的な実行時間を短縮することが期待されています。 ただし、この改善のメリットを完全に得るには、1 つだけではなく複数の結果ファイルを処理するようにコードを更新する必要があります。 この調整により、コードが新しいアプローチに合わせて調整され、インベントリ データの処理が最適化されます。

いいえ、既存のデータは影響を受けません。 新しい BLOB インベントリの結果だけが、複数のインベントリ ファイルとなります。

いいえ、変更はシームレスに行われます。

必要なアクションは、お客様が現在どのように BLOB インベントリの結果を処理しているかによって次のように異なります。

• 現在の処理で 1 つのインベントリ結果ファイルが想定されている場合は、複数のインベントリ結果ファイルに対応するようにコードを変更する必要があります。

• しかし、現在の処理にマニフェスト ファイルからの結果ファイル一覧の読み取りが含まれている場合、結果の処理方法に何か変更を行う必要はありません。 既存のアプローチは、更新された機能を使用してシームレスに引き続き動作します。

これは推奨されませんが、可能です。 この機能をオフにするように依頼するには、サポート チャネルを通じて行ってください。

現在のアカウント チームとサポート チャネルを通じて行ってください。

この変更は、2023 年 9 月 1 日から段階的なロールアウトを開始します。

不正解です。 Azure Compute はディスク上のメトリックをサポートします。 詳細については、マネージド ディスクと非管理ディスクのディスクあたりのメトリックに関するページをご覧ください。

可用性データや待機時間データを表示するものなど、一部の Azure メトリック グラフでは、破線を使用して、既知の 2 つの時間グレイン データ ポイントの間に欠損値 (null 値とも呼ばれます) があることを示します。 たとえば、時間セレクターで時間の細分性 1 minute を選択したが、メトリックが 07:26、07:27、07:29、07:30 に報告された場合、07:27 と 07:29 は破線で接続されます。この 2 つのデータ ポイント間には 1 分のギャップがあるためです。 他のデータ ポイントはすべて実線で接続されます。 メトリックで count と sum の集計が使われている場合、破線は 0 まで下がります。 avg、min、または max の集計の場合は、破線は最も近い 2 つの既知のデータ ポイントを接続します。 また、グラフの右端または左端のデータが不足している場合は、破線は不足しているデータ ポイントの方向に延長されます。

Azure Resource Health サービスに基づいてリソース正常性アラートを構成して、ストレージ アカウントの可用性を追跡できます。 アカウントにトランザクションがない場合、アラートは、ストレージ アカウントが配置されているストレージ クラスターの正常性に基づいて報告されます。

BLOB 容量と BLOB 数のメトリックは、1 時間ごとに出力されます。 バックグラウンド プロセスがこれらのメトリックを計算し、それらを 1 日に複数回更新します。

分析ログには、すべての操作にわたる成功した要求と失敗した要求を含むすべての読み取り、書き込み、一覧表示、および削除操作のレコードが含まれています。 分析ログはベストエフォートであり、順序は保証されません。

変更フィードは、BLOB の作成、変更、削除などの、アカウントへの成功した変異または変更のトランザクション ログを提供するソリューションです。 変更フィードでは、すべてのイベントが BLOB ごとの成功した変更の順序で記録および表示されることが保証されるため、大量の読み取り操作または失敗した要求からのノイズをフィルターで除外する必要はありません。 変更フィードは、基本的に、特定の保証を必要とするアプリケーション開発向けに設計および最適化されています。

変更フィードと BLOB ストレージ イベントは同じ配信の信頼性保証を備えた同じ情報を提供するため、両方の機能を活用できます。主な違いは、イベント レコードの待ち時間、順序、および保存です。 変更フィードでは、変更から数分以内にレコードがログに公開され、BLOB ごとの変更操作の順序も保証されます。 ストレージ イベントはリアルタイムでプッシュされ、順序付けされない可能性があります。 変更フィード イベントが独自の定義された保持期間を持つ読み取り専用の安定したログとしてストレージ アカウントの内部に永続的に格納されるのに対して、ストレージ イベントは、明示的に格納しない限り、イベント ハンドラーによって一時的に使用されます。 変更フィードの場合は、任意の数のアプリケーションが BLOB API または SDK を使用して、それぞれの都合に合わせてログを使用できます。

はい。 ストレージ アカウントのネットワーク セキュリティ規則 (IP ベースおよび VNET ファイアウォールを含む) は、静的 Web サイトのエンドポイントでサポートされており、Web サイトを保護するために使用できます。

不正解です。 静的 Web サイトでサポートされるのは、 $web コンテナー内のファイルに対する匿名パブリック読み取りアクセスのみです。

Azure Content Delivery Network (Azure CDN) を使用して、静的 Web サイトでカスタム ドメインを構成できます。 Azure CDN によって、世界中のどこからアクセスする場合でも Web サイトの待ち時間が一貫して短くなります。

Azure CDN を使用して、静的 Web サイトでカスタム SSL 証明書を構成できます。 Azure CDN によって、世界中のどこからアクセスする場合でも Web サイトの待ち時間が一貫して短くなります。

静的 Web サイトのホスト ヘッダーを構成するには、Azure CDN - Verizon Premium を使用します。 こちらでフィードバックをお寄せください。

正しくない大文字と小文字を使用してファイル名を参照した場合、404 エラーが発生する可能性があります。 たとえば、index.html ではなく Index.html になります。 静的 Web サイトの URL にあるファイル名と拡張子は、HTTP を介して提供される場合でも大文字と小文字が区別されます。 これは、Azure CDN エンドポイントがまだプロビジョニングされていない場合にも発生することがあります。 新しい Azure CDN をプロビジョニングした後、伝達が完了するまで、最大 90 分間待ってください。

Azure portal で、お使いのアカウントの静的 Web サイト構成ページを開き、 [インデックス ドキュメント名] フィールドに設定されている名前と拡張子を見つけてください。 この名前が、ストレージ アカウントの $web コンテナにあるファイルの名前と完全に同じであることを確認します。 静的 Web サイトの URL にあるファイル名と拡張子は、HTTP を介して提供される場合でも大文字と小文字が区別されます。

いいえ、BLOB データ内で検索する必要がある場合は、クエリ アクセラレーションまたは Azure Search を使用してください。

文字列データ型のみが BLOB インデックス タグによってサポートされ、クエリを実行すると辞書の順序で結果が返されます。 数値の場合は、0 を埋めます。 日付と時刻の場合は、ISO 8601 準拠の形式で格納します。

いいえ。Resource Manager タグは、サブスクリプション、リソース グループ、ストレージ アカウントなどのコントロール プレーン リソースを整理するのに役立ちます。 インデックス タグにより、データ プレーンでの BLOB の管理と検出が提供されます。

Azure Blob Storage のストレージ容量は、1 か月間の格納データの総量から 1 日あたりの平均量 (ギガバイト単位) を算出し、それを基準に請求されます。 たとえば、ストレージを月の前半には 10 GB 使用し、後半には一切使用しなかった場合には、平均使用量 5 GB として請求されます。

次のステップ

Azure Blob Storage の詳細については、次のリンク先を参照してください:

• Azure ストレージの概要
• Azure Blob Storage とは