汎用 v2 ストレージ アカウントにアップグレードする
汎用 v2 ストレージ アカウントは、最新の Azure Storage の機能をサポートし、汎用 v1 と BLOB ストレージ アカウントのすべての機能が組み込まれています。 ほとんどのストレージ シナリオに汎用 v2 アカウントをお勧めします。 汎用 v2 アカウントは、業界内の他社に引けを取らないトランザクション料金で、Azure Storage に対してギガバイトあたり容量の最低価格を提供しています。 汎用 v2 アカウントでは、ホットまたはクールの既定のアカウント アクセス層と、ホット、クール、またはアーカイブ間の BLOB レベル階層がサポートされます。
汎用 v1 または BLOB ストレージ アカウントから汎用 v2 ストレージ アカウントへのアップグレードは簡単です。 Azure portal、PowerShell、または Azure CLI を使用してアップグレードできます。 汎用 v2 ストレージ アカウントへのアップグレードに伴うダウンタイムやデータ損失のリスクはありません。 アカウントのアップグレードは、アカウントの種類を変更する、Azure Resource Manager の単純な操作によって行われます。
重要
汎用 v1 または BLOB ストレージ アカウントから汎用 v2 へのアップグレードは永続的であり、元に戻すことはできません。
Note
Microsoft ではほとんどのシナリオで汎用 v2 アカウントを推奨していますが、Microsoft では新規および既存のお客様向けに汎用 v1 アカウントを引き続きサポートしています。 これらのリージョンで Azure Storage を利用できる場合は常に、新しいリージョンに汎用 v1 ストレージ アカウントを作成できます。 Microsoft では、現時点で汎用 v1 アカウントのサポートを廃止する予定はなく、Azure Storage 機能のサポート終了の少なくとも 1 年前に事前通知する予定です。 Microsoft では、汎用 v1 アカウントのセキュリティ更新プログラムを引き続き提供しますが、このアカウントの種類に対して新しい機能の開発は予定されていません。
2020 年 10 月 1 日以降にオンラインになった新しい Azure リージョンでは、汎用 v1 アカウントの料金は変更されており、これらのリージョンの汎用 v2 アカウントの料金と同じです。 2020 年 10 月 1 日より前に存在していた Azure リージョンの汎用 v1 アカウントの料金は変更されていません。 特定のリージョンの汎用 v1 アカウントの価格の詳細については、Azure Storage の価格ページを参照してください。 リージョンを選択し、 [価格プラン] の横にある [その他] を選択してください。
アカウントのアップグレード
汎用 v1 または BLOB ストレージ アカウントを汎用 v2 アカウントにアップグレードするには、Azure portal、PowerShell、または Azure CLI を使用します。
Azure portal にサインインします。
ストレージ アカウントに移動します。
[設定] セクションで、 [構成] を選択します。
[アカウントの種類] の下にある [アップグレード] を選択します。
[アップグレードの確認] に、アカウントの名前を入力します。
ブレードの下部にある [アップグレード] を選択します。
BLOB データのアクセス層を指定する
汎用 v2 アカウントは、すべての Azure ストレージ サービスとデータ オブジェクトをサポートしていますが、アクセス層は BLOB ストレージ内のブロック BLOB に対してのみ使用できます。 汎用 v2 ストレージ アカウントにアップグレードするときは、既定のアカウント アクセス層としてホットまたはクールを指定できます。これは、個々の BLOB アクセス層パラメーターが指定されていない場合と同様に、BLOB データがアップロードされる既定の層を示します。
BLOB アクセス層を使用すると、想定される使用パターンに基づいて最も費用対効果の高いストレージを選択できます。 ブロック BLOB は、ホット層、クール層、またはアーカイブ層に格納できます。 アクセス層の詳細については、「Azure Blob Storage:ホット ストレージ層、クール ストレージ層、アーカイブ ストレージ層」をご覧ください。
既定では、新しいストレージ アカウントはホット アクセス層に作成され、汎用 v1 ストレージ アカウントはホットまたはクール アカウント層にアップグレードできます。 アカウントのアクセス層がアップグレード時に指定されていない場合、既定でホットにアップグレードされます。 アップグレード用にどのアクセス層を使用するか検討している場合は、現在のデータ使用シナリオを考慮してください。 汎用 v2 アカウントに移行する一般的なユーザー シナリオには、次の 2 つがあります。
- 汎用 v1 ストレージ アカウントを既に持っており、適切なストレージ アクセス層の BLOB データを使用して、汎用 v2 ストレージ アカウントへのアップグレードを評価したい。
- 汎用 v2 ストレージ アカウントを使用することを決定しているか、または既に持っており、BLOB データにホットまたはクール ストレージ アクセス層のどちらを使用すべきかを評価したいと考えている。
いずれの場合も、最初にすべきことは、汎用 v2 ストレージ アカウントに格納されるデータの格納、アクセス、操作にかかるコストを見積もり、そのコストを現在のコストと比較することです。
価格と課金
v1 ストレージ アカウントから汎用 v2 アカウントへのアップグレードは無料です。 アップグレード プロセス中に、目的のアカウント層を指定できます。 アップグレード時にアカウント層が指定されていない場合、アップグレードされたアカウントの既定のアカウント層は Hot
になります。 ただし、アップグレード後にストレージ アクセス層を変更すると、請求書が変更される可能性があるため、アップグレード時に新しいアカウント層を指定することをお勧めします。
すべてのストレージ アカウントでは、各 BLOB の層に基づいた Blob Storage の価格モデルを採用しています。 ストレージ アカウントを使用するときには、課金に関して次の点を考慮してください。
ストレージ コスト:データの格納のコストは、格納されているデータの量だけでなく、ストレージ アクセス層にも左右されます。 よりクールな層になるほど、ギガバイトあたりのコストが下がります。
データ アクセス コスト:データ アクセス料金は、よりクールな層になるほど高くなります。 クールおよびアーカイブ ストレージ アクセス層のデータの場合、読み取りに対して、ギガバイト単位のデータ アクセス料金が課金されます。
トランザクション コスト:すべての層に対してトランザクションごとに課金されます。よりクールな層になるほどコストが高くなります。
geo レプリケーション データ転送コスト:GRS と RA-GRS を含む geo レプリケーションが構成されているアカウントだけに適用されます。 geo レプリケーション データ転送には、ギガバイトあたりの料金がかかります。
送信データ転送コスト:送信データ転送 (Azure リージョン外に転送されるデータ) では、帯域幅使用量に対する課金が 1 ギガバイトごとに発生します。これは、汎用ストレージ アカウントと同じです。
ストレージ アクセス層の変更:アカウント ストレージ アクセス層をクールからホットに変更すると、ストレージ アカウントに存在するすべてのデータの読み取りと同等の課金が発生します。 ただし、アカウント アクセス層をホットからクールに変更したときは、クール層への全データの書き込みに相当する課金が発生します (GPv2 アカウントのみ)。
Note
ストレージ アカウントの価格モデルの詳細については、Azure Storage の価格に関するページを参照してください。 送信データ転送の価格の詳細については、データ転送の料金詳細に関するページを参照してください。
現在の使用パターンのコストを見積もる
特定の層に汎用 v2 ストレージ アカウントの BLOB データを格納してアクセスするコストを見積もるには、既存の使用パターンを評価するか、予想される使用パターンを概算します。 一般に、以下のことを調べる必要があります。
以下のような BLOB ストレージの使用量 (GB 単位)
- ストレージ アカウントに格納されているデータの量はどれくらいか。
- 月単位でデータ ボリュームがどのように変化するか。古いデータが定期的に新しいデータに置き換わるかどうか。
以下のような BLOB ストレージ データの主なアクセス パターン。
- ストレージ アカウントから読み取られているデータの量とストレージ アカウントに書き込まれているデータの量はどれくらいか。
- ストレージ アカウントのデータに対して実行されている読み取り操作と書き込み操作の数。
実際のニーズに最適なアクセス層を決定するには、BLOB データの容量と、そのデータが使用されている方法を確認すると役に立ちます。 それを行うには、アカウントの監視メトリックを調べるのが最善の方法です。
既存のストレージ アカウントの監視
既存のストレージ アカウントを監視し、そのデータを収集するには、Azure Storage Analytics を利用できます。これにより、ログ記録が実行され、ストレージ アカウントのメトリック データが得られます。 Storage Analytics では、GPv1、GPv2、BLOB というストレージ アカウントの種類について、ストレージ サービスへの要求に関して集計されたトランザクション統計情報と容量データを含むメトリックを格納できます。 このデータは、同じストレージ アカウント内の既知のテーブルに格納されます。
詳細については、「About Storage Analytics Metrics (Storage Analytics メトリックについて)」と「Storage Analytics Metrics Table Schema (Storage Analytics メトリックのテーブル スキーマ)」を参照してください。
Note
BLOB ストレージ アカウントは、そのアカウントのメトリック データの格納とアクセスのためだけに Table service エンドポイントを公開します。
BLOB ストレージのストレージ使用量を監視するには、容量メトリックを有効にする必要があります。 これを有効にすると、ストレージ アカウントの Blob service に関する容量データが毎日記録されます。これは、同じストレージ アカウント内の $MetricsCapacityBlob テーブルに書き込まれるテーブル エントリとして記録されます。
BLOB ストレージのデータ アクセス パターンを監視するには、API から時間単位のトランザクション メトリックを有効にする必要があります。 時間単位のトランザクション メトリックを有効にすると、API あたりのトランザクションが 1 時間ごとに集計され、同じストレージ アカウント内の $MetricsHourPrimaryTransactionsBlob テーブルに書き込まれるテーブル エントリとして記録されます。 $MetricsHourSecondaryTransactionsBlob テーブルには、RA-GRS ストレージ アカウントを使用している場合のセカンダリ エンドポイントに対するトランザクションが記録されます。
Note
汎用ストレージ アカウントがあり、そのアカウントに、ページ BLOB と仮想マシン ディスク (またはキュー、ファイル、テーブルのいずれか) を、ブロック BLOB データと追加 BLOB データと共に格納している場合、この見積もりプロセスは適用できません。 容量データにおいて、ブロック BLOB と他の種類が区別されず、他の種類のデータに関する容量データが得られません。 これらのタイプを使用する場合、直近の請求書に記載された数量に着目することで対応することもできます。
データ使用量とアクセス パターンを正確に見積もるには、通常の使用状況を表すメトリックの保有期間を選択したうえで推定することをお勧めします。 その方法の 1 つとして、メトリック データを 7 日間保持し、そのデータを毎週収集して、月末に分析を行う方法があります。 そのほかに、過去 30 日間のメトリック データを保持し、30 日の期間の最後にそのデータを収集、分析する方法もあります。
メトリック データの有効化、収集、および表示の詳細については、Storage Analytics のメトリックに関するページを参照してください。
Note
分析データの格納、アクセス、ダウンロードについても、通常のユーザー データと同様に課金されます。
コストを見積もるための使用状況メトリックの利用
容量のコスト
行キー "data" がある容量メトリック テーブル $MetricsCapacityBlob の最新のエントリは、ユーザー データによって使用されたストレージ容量を示します。 行キー "analytics" がある容量メトリック テーブル $MetricsCapacityBlob の最新のエントリは、分析ログによって使用されたストレージ容量を示します。
ユーザー データと分析ログ (有効な場合) の両方によって使用されたこの合計容量は、ストレージ アカウントにデータを格納するコストを見積もるために使用できます。 また、同じ方法を使用して、GPv1 ストレージ アカウントでのストレージ コストを見積もることができます。
トランザクション コスト
"TotalBillableRequests" の合計は、トランザクション メトリック テーブル内の API のすべてのエントリを対象とし、その特定の API のトランザクションの総数を示すものです。 "たとえば"、特定期間の "GetBlob" トランザクションの合計は、行キー "user;GetBlob" を備えたすべてのエントリに対する課金対象の要求をすべて加算することによって計算できます。
BLOB ストレージ アカウントのトランザクション コストを見積もるには、トランザクションを 3 つのグループに分類する必要があります (それぞれ価格が異なるため)。
- "PutBlob" 、 "PutBlock" 、 "PutBlockList" 、 "AppendBlock" 、 "ListBlobs" 、 "ListContainers" 、 "CreateContainer" 、 "SnapshotBlob" 、 "CopyBlob" などの書き込みトランザクション。
- "DeleteBlob" 、 "DeleteContainer" などの削除トランザクション。
- その他すべてのトランザクション。
GPv1 ストレージ アカウントのトランザクション コストを見積もるには、操作と API に関係なく、すべてのトランザクションを集計する必要があります。
データ アクセスと geo レプリケーション データ転送のコスト
Storage Analytics では、ストレージ アカウントに対する読み取りと書き込みのデータ量は示されませんが、トランザクション メトリック テーブルを確認することで大まかに見積もることは可能です。 トランザクション メトリック テーブル内の API の全エントリを対象とした "TotalIngress" の合計は、その特定の API の受信データの総量をバイトで示すものです。 同様に、 "TotalEgress" の合計は、送信データの総量をバイトで示します。
BLOB ストレージ アカウントのデータ アクセス コストを見積もるには、トランザクションを 2 つのグループに分類する必要があります。
ストレージ アカウントから取得されたデータの量は、主に "GetBlob" 操作と "CopyBlob" 操作の "TotalEgress" の合計を確認することで見積もることができます。
ストレージ アカウントに書き込まれたデータの量は、主に "PutBlob" 操作、 "PutBlock" 操作、 "CopyBlob" 操作、 "AppendBlock" 操作の "TotalIngress" の合計を確認することで見積もることができます。
また、BLOB ストレージ アカウントの geo レプリケーション データ転送のコストは、GRS ストレージ アカウントまたは RA-GRS ストレージ アカウントを使用する場合に書き込まれるデータ量の見積もりを使用することによって計算することもできます。
Note
ホット ストレージ アクセス層またはクール ストレージ アクセス層を使用する場合のコストの計算に関する詳細な例については、「Azure Storage の価格」ページのホット、クール アクセス層とはどのようなものか、また使用する層を決定する方法に関するタイトルの FAQ を確認してください。