Azure プロフェッショナルのための Google Cloud: ストレージ

更新日: 2020 年 12 月 07 日

Microsoft Azure と Google Cloud が提供するストレージ サービスを比べてみましょう。ここでは、次のタイプのサービスについて説明します。

  • 分散オブジェクト ストレージは、冗長化された Key-Value ストアであり、データ オブジェクトを保存できます。
  • ブロック ストレージは、仮想ディスク ボリュームであり、仮想マシンのインスタンスに接続できます。
  • ファイル ストレージは、ネットワークに接続された、ファイル サーバーベースのストレージです。
  • ストレージ エリア ネットワークは、ブロックレベルでストレージにアクセスできるリモート ストレージです。
  • クール ストレージは、データ バックアップを保存するように設計されたストレージ サービスです。
  • アーカイブ ストレージは、コンプライアンスや分析を目的としてアーカイブ データを保存するように設計されたストレージ サービスです。

ここでは、データベースやメッセージ キューについては説明しません。

サービスモデルの比較

Microsoft Azure と Google Cloud は、ストレージ サービスの高レベルの組織と構成に対して異なる手法を取っています。ただし実際には、ストレージ サービス自体には相違点よりも類似点のほうが多くあります。

Microsoft Azure

Azure では、バイナリ オブジェクト(blob)、データベース、メッセージ キューなどのさまざまなタイプのデータを、ストレージ アカウント内の特定のサービスに保管します。Azure では、ストレージ アカウント レベルでアカウント タイプ、ディスクタイプ、冗長性タイプを定義する必要があります。これらの属性は、そのアカウント内のすべてのストレージ サービスに適用されます。

Azure ストレージ アカウントには、汎用 v1(GPv1)、blob 固有、汎用 v2(GPv2)という 3 つのタイプがあります。GPv1 アカウントでは、Azure のすべての標準ストレージ タイプをサポートできます。blob 固有アカウントは、Azure Blob Storage の高度な機能をサポートするように設計されています。これらのアカウント タイプでサポートしていない API と機能は、GPv2 アカウントでサポートされます。

blob 固有アカウントはハードディスク ドライブ(HDD)上で排他的に実行されますが、汎用アカウントの両方は、HDD 上で実行される標準ストレージ アカウントと、ソリッド ステート ドライブ(SSD)上で実行されるプレミアム ストレージ アカウントにさらに分割されます。後者のアカウント タイプは、ページ blob のみをサポートしています。

新しい Azure ストレージ アカウントを作成するときに、使用するレプリケーションのレベルを選択します。Azure では、以下のレベルが用意されています。

  • ローカル冗長ストレージ(LRS): ストレージ アカウントを含むデータセンター内でローカルにデータをレプリケートします。データは 3 回レプリケートされます。
  • ゾーン冗長ストレージ(ZRS): 結果整合性を持つように、1 つまたは 2 つのリージョン間でデータをレプリケートします。LRS と同様に、データは局所的に 3 回レプリケートされます。ZRS は、汎用ストレージ アカウントでの blob ストレージをブロックするように制限されています。
  • 地理冗長ストレージ(GRS): プライマリ リージョンと、そこから 100 マイル以上離れたセカンダリ リージョンでデータをレプリケートします。データはプライマリ リージョンで 3 回レプリケートされた後、セカンダリ リージョンで非同期的に 3 回レプリケートされます。
  • 読み取りアクセス地理冗長ストレージ(RA-GRS): GRS と同じですが、セカンダリ リージョンにセカンダリ読み取り専用エンドポイントが追加されます。

Google Cloud

Azure と同様に、Google Cloud は各データタイプをタイプ固有のサービス内に保存します。ただし、Google Cloud にはストレージ アカウントのような高レベルの組織レイヤはありません。代わりに、ストレージ リソースを作成し、サービスレベルでディスクタイプや冗長性タイプなどのリソース属性を定義します。

Google Cloud では、分散オブジェクト ストレージとして Cloud Storage を提供しています。これは、Azure Blob Storage のブロック blob と追加 blob ストレージに相当します。ブロック ストレージについては、Google Cloud では Compute Engine 永続ディスクを提供しています。これは、Azure VHD に相当します。

分散オブジェクト ストレージ

分散オブジェクト ストレージとして、Azure は Azure Blob Storage を、Google Cloud は Cloud Storage を提供しています。

Azure Blob Storage と Cloud Storage は、多くの点で類似しています。どちらのサービスでも、指定されたストレージ ユニット内にバイナリ オブジェクトを保存します。Azure Blob Storage では、これらのバイナリ オブジェクトは blob と呼ばれ、ストレージ ユニットはコンテナと呼ばれます。Cloud Storage では、これらのバイナリ オブジェクトはオブジェクトと呼ばれ、ストレージ ユニットはバケットと呼ばれます。

どちらのサービスでも、ストレージ ユニット内の各バイナリ オブジェクトは、そのストレージ ユニット内で一意のキーによって識別され、各オブジェクトにはメタデータ レコードが関連付けられます。このメタデータ レコードには、オブジェクトのサイズ、最終変更日、メディアタイプなどの情報が含まれています。適切な権限があれば、このメタデータの一部を閲覧、変更できます。必要に応じて、カスタム メタデータを追加することもできます。

コンテナとバケットは両方とも Key-Value ストアですが、それぞれのユーザー エクスペリエンスはファイル システムと同一ではないとしても、類似しています。慣例により、通常、オブジェクト キーは "/foo/bar.txt" や "/foo/subdir/baz.txt" のようなパスになります。Azure と Cloud Storage はどちらもファイル システムのような API を提供しています。たとえば、Azure Blob Storage の List Blobs メソッドと Cloud Storage の list メソッドは両方とも、共通のプレフィックスを持つすべてのオブジェクト キーをリストできます。これは、Unix のようなファイル システム上の ls -R とは異なります。

分散オブジェクト ストレージとしての一般的な利用法に加え、どちらのサービスも、静的なウェブ コンテンツとメディアをホストするためにも利用できます。

Azure Blob Storage と Cloud Storage の機能と用語は、次のように対応しています。

機能 Azure Blob Storage Cloud Storage
デプロイ ユニット コンテナー バケット
デプロイ識別子 アカウント レベルの一意のキー グローバル一意キー
ファイル システムのエミュレーション 制限されます 制限されます
オブジェクト タイプ ブロック blob、追加 blob、ページ blob オブジェクト
オブジェクトのメタデータ
オブジェクトのバージョニング 手動、オブジェクト単位のスナップショット バケット内のすべてのオブジェクトの自動バージョニング(有効にする必要あり)
オブジェクトのライフサイクル管理 〇(ライフサイクル ルールまたは Azure Automation を使用) 〇(ネイティブ)
オブジェクト変更通知 〇(Azure Event Grids を使用) 〇(Pub/Sub を使用)
サービスクラス 冗長レベル: LRS、ZRS、GRS、RA-GRS
階層: ホット、クール、アーカイブ
Standard、Nearline、Coldline、Archive
デプロイの範囲 ゾーン、リージョン Regional、Multi-Regional
冗長性

blob のタイプ

Azure Blob Storage では、ブロック blob追加 blobページ blob のいずれかとしてデータを保存します。Cloud Storage では、すべてのデータをオブジェクトとして保存します。これは、ブロック blob に相当します。Google Cloud では、追加 blob に直接相当するサービスまたはオブジェクト タイプは提供されていません。ただし、Cloud Storage のオブジェクト複合機能と同時実行制御を使用して、追加 blob の機能に近づけることができます。詳しくは、複合オブジェクトと並列アップロードをご覧ください。

Azure とは異なり、Google Cloud ではディスク ボリュームを、オブジェクト ストレージ サービス内のページ blob として保存しません。代わりに、ディスク ボリュームは Google Cloud の IaaS(Infrastructure-as-a-Service)オファリングである Compute Engine 内に保存されます。詳しくは、ブロック ストレージをご覧ください。

アクセス階層とレプリケーション

Azure Blob Storage の柔軟性は、作成したストレージ アカウントのタイプと、そのアカウントに選択したレプリケーション オプションによって異なります。GPv1 ストレージ アカウントを使用している場合、blob ストレージに使用できる階層は、Azure のデフォルト階層に制限されます。ただし、blob 固有または GPv2 ストレージ アカウントを使用すると、Azure Blob Storage のアクセス階層として、ホット階層、クール階層、アーカイブ階層のいずれかを選択できます。ホット階層は頻繁にアクセスされるデータ用、クール階層は頻繁にアクセスされないデータ用、アーカイブ階層はデータ アーカイブ用に設計されています。Azure Blob Storage サービスのレプリケーション レベルは、ストレージ アカウントで使用しているレプリケーション タイプによって決まります。

一方、Cloud Storage のレプリケーション タイプはそのサービスクラスに組み込まれています。これらのサービスクラスは、Azure Blob Storage のアクセス階層とレプリケーション タイプに以下のように対応しています。

構成 Azure Google Cloud
頻繁にアクセスされるデータ(地域的な冗長性を構成した場合) GRS または RA-GRS を使用した Azure Blob Storage(汎用またはホット階層) マルチリージョンまたはデュアルリージョンの Standard Storage
頻繁にアクセスされるデータ(リージョン冗長性を構成した場合) ZRS を使用した Azure Blob Storage(汎用) リージョン内の Standard Storage
頻繁にアクセスされるデータ(ローカル(データセンター)冗長性を構成した場合) LRS を使用した Azure Blob Storage(汎用またはホット階層) リージョン内の Standard Storage*
頻繁にアクセスされないデータ Azure Blob Storage クール階層 Cloud Storage Nearline と Cloud Storage Coldline
アーカイブ データ Azure Blob Storage アーカイブ階層 Cloud Storage Archive

* リージョン冗長性は、Google Cloud で使用可能な最も低いレベルの冗長性です。

オブジェクトのバージョニング

Azure と Cloud Storage ではいずれも、異なるバージョン ID を設定した所定のキーを使用して、異なるバージョンのオブジェクトを保存することで、保存するオブジェクトをバージョニングすることができます。ただし、この機能の実装は異なる方法で行われます。

Azure Blob Storage では、blob の読み取り専用スナップショットを取ることで、バージョニングを行えます。プログラムを使用してファイルをアップロードする場合、各アップロードの前に新しいスナップショットを取ることができます。また、Azure Blob Storage ではアクセス条件を指定して、不要なスナップショットを回避することもできます。

一方、Cloud Storage では、バケット内のすべてのオブジェクトに対して、自動オブジェクト バージョニングを有効にできます。自動バージョニングを有効にすると、ユーザーがオブジェクトを変更するたびに、Cloud Storage によってそのオブジェクトの新しいバージョンが自動的に作成されます。この手法ではオブジェクトのバージョニング処理を簡略化できますが、Azure の手法よりも柔軟性はわずかに劣ります。オブジェクトの各バージョンも保存されるデータ総量に計上されるため、ストレージ費用が上がる可能性があります。この問題は、Cloud Storage のオブジェクトのライフサイクル管理を使用することで軽減できます。

同時実行制御

Azure Blob Storage と Cloud Storage はそれぞれ、「最後の書き込みが有効」という書き込み方式にデフォルト設定されています。この方式は順次書き込みについてはうまく機能しますが、同じオブジェクトに同時書き込みを実行すると競合状態が発生することがあります。この問題を軽減するために、両方のサービスで同時書き込みを管理する仕組みが用意されています。

Azure では、楽観的または悲観的に同時書き込みを管理できます。

  • 楽観的手法: GET オペレーションを行うときにオブジェクトの ETag ヘッダーを取得し、その ETag とオブジェクトの現在の ETag を、書き込みを行うときに比較します。タグが一致する場合、書き込みを commit します。
  • 悲観的手法: 書き込みを行っている間、指定された期間、ターゲット オブジェクトをリースしてロックします。

Cloud Storage では、楽観的手法を使用します。同時書き込みを管理するために、指定されたオブジェクトの同時生成数を取得し、スクリプトまたはアプリケーションが書き込みを試行する際に、その生成数をチェックします。数値が一致する場合、書き込みを commit します。それ以外の場合は、トランザクションを中止してから再始動します。詳しくは、オブジェクトのバージョニングと同時実行制御をご覧ください。

オブジェクトのライフサイクル管理

Azure Blob Storage ライフサイクル管理では GPv2 と blob ストレージ アカウントのルールベース ポリシーを使用できます。これらのポリシーを使用すると、データを適切なアクセス階層に移動できます。また、データのライフサイクルの終了時に期限切れにできます。Azure オブジェクト ライフサイクル管理ルールは、経過時間に基づくデータのアーカイブや削除、取り込み時のデータのアーカイブ、古いスナップショットの削除などのシナリオをサポートします。

Cloud Storage では、ユーザーが指定したライフサイクル ポリシーに従って、オブジェクトの削除を自動化できます。詳しくは、オブジェクトのライフサイクル管理をご覧ください。

Azure Blob Storage にはネイティブのライフサイクル管理機能が提供されていませんが、Azure Automation を使用してオブジェクトの削除を自動化できます。

オブジェクト変更通知

Azure と Google Cloud ではどちらも、オブジェクトが変更されたときに通知を送受信するために使用できるパブリッシュ / サブスクライブ モデルを提供しています。Azure Blob Storage では、Azure Event Grid を使用して Blob Storage のイベントを追跡し、そのイベントの通知を webhook、Azure Function、またはその他のエンドポイントに送信できます。Google Cloud でも同様に、Pub/Sub Notifications を使用して、Cloud Storage バケット内のオブジェクトの作成時、削除時、更新時に通知を Pub/Sub トピックにパブリッシュできます。他のアプリケーションやサービスからでも、該当する Pub/Sub トピックにサブスクライブすることで、これらの通知を受信できます。

暗号化

Azure では、データ保存時の Azure Storage Service Encryption(SSE)を使用した保存時の暗号化がサポートされています。ストレージ アカウント内のすべての blob ベースのストレージは、上りで AES256 によって暗号化され、下りで復号されます。すでにデータをアップロードした後に、アカウントに対して暗号化を有効にすると、そのデータは書き換えられるまで暗号化されません。また、Azure ではサーバー側の暗号化(SSE)として顧客管理の暗号鍵(CMEK)を使用できます。Azure Blob Storage と Azure Files の SSE は Azure Key Vault と統合されているため、Key Vault を使用して暗号鍵を管理できます。

同様に、Cloud Storage などの Google Cloud のストレージ サービスに保存されたすべてのデータは、AES256 または AES128 のいずれかで、保存時に自動的に暗号化されます。独自の暗号鍵を管理する必要のあるデータについては、Google Cloud は Cloud Key Management Service を使用した CMEK と、顧客指定の暗号鍵(CSEK)もサポートしています。詳しくは、Google Cloud Platform での保存時の暗号化をご覧ください。

サービスレベル契約

Microsoft と Google はどちらも稼働率のサービスレベル契約(SLA)を提供しており、この SLA が実現しない場合には顧客アカウントに返金するポリシーを定めています。Microsoft は Azure Storage SLA で Azure Blob Storage に関する保証とポリシーを規定しています。Google は、Cloud Storage SLA で Cloud Storage に関する保証とポリシーを規定しています。

費用

Azure Blob Storage

Azure Blob Storage は、1 か月あたりのデータ保存量、ストレージ アカウントのタイプ、レプリケーション タイプ、ネットワーク(下り)によって価格設定されています。オブジェクトのスナップショットを取ると、それらのスナップショットは、オブジェクトのライブ バージョンと同じレートで課金されます。Azure Blob Storage では、一般的な API リクエストに関しても課金されます。

Cloud Storage Standard

Cloud Storage Standard は、1 か月あたりの保存データ量と下り(外向き)ネットワークのデータ量に基づいて課金されます。オブジェクトのバージョニングが有効になっているバケットについては、オブジェクトのアーカイブされたバージョンごとに、オブジェクトのライブ バージョンと同じ料金が請求されます。Cloud Storage Standard でも、一般的な API リクエストに課金されます。

ブロック ストレージ

Google Cloud と Azure のいずれでも、ブロック ストレージのオプションが用意されています。Google Cloud では、永続ディスクという形のブロック ストレージが、Compute Engine の一部として提供されています。Azure では、マネージド ディスクの形式でブロック ストレージが提供されています。どちらのプラットフォームでも、ローカルに接続された SSD を使用できます。

サービスモデルの比較

保存される方法を除けば、Compute Engine 永続ディスクと Azure Managed Disks はよく似ています。どちらも、ディスク ボリュームはネットワークに接続されます。一方で、Compute Engine と Azure では、必要に応じてディスクをローカル接続することもできます。ネットワーク接続されたディスクは、ローカル接続されたディスクに比べて動作レイテンシが大きく、スループットが低くなっていますが、組み込まれた冗長性、スナップショットの作成、ディスクの切断と再接続の簡便さといった利点も多くあります。

Azure Managed Disks

Azure マネージド ディスクのサイズは、最大 32 TiB(Ultra SSD の場合は 64 TiB)です。Azure 仮想マシン(VM)では、同時に接続できるマネージド ディスクの数に対して、マシンタイプ ベースの制限が設定されています。

各マネージド ディスクは、ディスクが接続されている VM と同じリージョンに存在する必要があります。マネージド ディスクのレイテンシとスループットは、ディスクタイプと VM のマシンタイプの両方によって決まります。

  • Azure Standard HDD(ハードディスク ドライブ)は磁気の HDD を稼働させるため、頻繁にアクセスしないデータや、バルク ストレージのユースケースに推奨されます。
  • Azure Standard SSD(ソリッド ステート ドライブ)、Azure Premium SSD、および Azure Ultra SSD は、さまざまな SSD ドライブ上で実行されるため、本番環境のワークロードの需要に従って使用することをおすすめします。マネージド ディスク ストレージ階層を増やすと、スループットと IOPS は増加します。A0 などの一部の低い階層のマシンでは、SSD を使用するマネージド ディスクはサポートされていません。

Compute Engine 永続ディスク

Google Cloud では、永続ディスクという形でブロック ストレージが提供されています。このブロック ストレージは Compute Engine に格納されます。カスタム マシンタイプか事前定義されたマシンタイプのほとんどの Compute Engine VM インスタンスでは、最大で 128 個の永続ディスクをアタッチできます。共有コア マシンタイプのインスタンスは、永続ディスク数が最大で 16 個に制限されています。VM インスタンスごとに最大 257 TB の永続ディスクを接続できます。各永続ディスクのサイズは最大で 64 TB にできます。

永続ディスクは HDD、分散(SSD ベース)、SSD のいずれかになります。ゾーン永続ディスクは、VM インスタンスと同じゾーンに作成されます。リージョン永続ディスクはゾーン間で複製されます。

Compute Engine の永続ディスクは、Azure マネージド ディスクと次のように対応しています。

機能 Azure マネージド ディスク Compute Engine 永続ディスク
ボリューム タイプ 標準 HDD、標準 SSD、プレミアム SSD、Ultra SSD 標準永続ディスク(HDD)、負荷分散永続ディスク(SSD ベース)、SSD 永続ディスク
管理方法 マネージド ディスク、非マネージド ディスク 該当なし(プロジェクト レベルで Google Cloud により管理)
ボリュームの接続 通常のマネージド ディスクは一度に 1 つのインスタンスにのみ接続可能
容量が限られている場合、共有ディスクは複数のインスタンスに接続可能
読み取り / 書き込みボリューム: 一度に 1 つのインスタンスにのみ接続可能
読み取り専用ボリューム: 複数のインスタンスに接続可能
最大ボリューム サイズ 標準 HDD、標準 SSD、プレミアム SSD の場合 32 TiB
Ultra SSD の場合 64 TiB
64 TB
冗長性
スナップショット作成
ディスクの暗号化 デフォルトで暗号化 デフォルトで暗号化

以下は、Compute Engine と Azure のローカル接続されたディスクを比較したものです。

機能 Azure Compute Engine
サービス名 ローカル SSD ローカル SSD
ボリュームの接続 インスタンスのタイプに関連付け 共有されていないコア インスタンスすべてに接続可能
インスタンスあたりの接続ボリューム インスタンスのタイプに依存 24 まで
ストレージ容量 インスタンスのタイプに依存 ボリュームあたり 375 GB、合計 9 TB
ライブ マイグレーション ×
冗長性 なし なし

レプリケーション

Azure マネージド ディスクは Azure アベイラビリティ ゾーンを使用できます。この機能により、同じゾーン内の最大 3 つのデータセンターにレプリカを作成できます。1 つのデータセンターで問題が発生した場合、可用性ゾーンでマネージド ディスクを使用する VM のフェイルオーバーが可能です。

ゾーン永続ディスクを使用して、単一の Compute Engine リージョン内で Compute Engine の永続ディスクを複製できます。Compute Engine で堅牢なシステムを設計する場合は、リージョン永続ディスクを使用して複数のゾーンのリソースに高可用性を維持できます。リージョン永続ディスクは、アプリケーション レベルのレプリケーションを持たないワークロードに対して同期レプリケーションを提供します。障害が発生した場合、リージョン永続ディスクがフェイルオーバーを自動的に行い、使用可能なリージョンの別の VM インスタンスに接続するように構成できます。

どちらのサービスでもレプリケーションを使用して耐久性を強化できますが、この機能によって、ユーザーやアプリケーションのエラーが原因で生じるデータ破損や予期しない削除から保護されるわけではありません。重要なデータを保護するには、定期的にデータのバックアップやディスクのスナップショット作成を行うようにしてください。

ボリュームの接続と切断

ディスク ボリュームを作成した後、そのボリュームを VM に接続できます。Azure VM インスタンスと Compute Engine VM インスタンスは同じように動作します。その後、VM インスタンスによって、他のブロック デバイスと同じようにディスク ボリュームをマウントし、フォーマットできます。同様に、ボリュームをインスタンスからマウント解除または切断できます。さらに、他のインスタンスに再接続することもできます。

ほとんどの Azure マネージド ディスクは、一度に 1 つの VM にのみ接続します。一部のプレミアム SSD および Ultra SSD マネージド ディスクは、VM 間で共有できます。使用と構成には制限があります。読み取り / 書き込みモードの Compute Engine 永続ディスクは 1 つの VM インスタンスにしか接続できませんが、読み取り専用モードの永続ディスクは複数の VM インスタンスに同時に接続できます。

ボリュームのバックアップ

Compute Engine と Azure ではどちらも、ユーザーがディスク ボリュームのスナップショットをキャプチャして保存できます。これらのスナップショットは、あとで新しいボリュームを作成するために使用できます。

Compute Engine の永続ディスクと Azure マネージド ディスクはどちらも、差分スナップショットまたは増分スナップショットをサポートしています。最初のスナップショットではボリュームのフルコピーが作成されますが、その後のスナップショットでは、前回のスナップショット以降に変更されたブロックのみがコピーされます。いくつかの差分スナップショットが取られた後、別のフルスナップショットが取られ、サイクルが繰り返されます。

また、Azure では Azure Backup と Azure Recovery Service も提供され、これらを使用してバックアップ動作とリストア動作を自動化できます。Google Cloud では、これらのサービスに相当するサービスは提供されていません。

ボリュームの性能

Compute Engine の永続ディスクと Azure マネージド ディスクの両方で、ディスクのパフォーマンスは次のような要因によって決まります。

  • ボリューム タイプ: どちらのサービスにも、固有のボリューム タイプがいくつかあります。タイプごとに、それぞれ異なる性能特性と上限があります。
  • 利用可能な帯域幅: ネットワーク接続されたボリュームのスループットは、ボリュームが接続される Compute Engine または Azure VM で利用できるネットワーク帯域幅によって異なります。

このセクションでは、それぞれのサービスのその他の性能についても詳しく説明します。

Azure Managed Disks

Azure VM のタイプは、ネットワーキングの性能という点で大きく異なります。コア数が少ない VM のタイプには、指定されたマネージド ディスクタイプに対してアドバタイズされた最大 IOP やスループットを達成するのに十分なネットワーク容量がない可能性があります。詳しくは、VM 向けの高パフォーマンスのプレミアム ストレージとマネージド ディスクをご覧ください。

Compute Engine 永続ディスク

Compute Engine は、コア単位でスループットを割り振ります。仮想 CPU コアあたりのネットワーク下り容量は 2 Gbps です。これは、1 つの仮想マシン インスタンスに対して最大 16 Gbps ということになります。Compute Engine には、3.3x のデータ冗長性要因があるため、1 回の論理的書き込みを完了させるには、実際には 3.3 回分の書き込みを行うためのネットワーク帯域幅が必要になります。そのため、コアの数が少ないマシンタイプには、その永続ディスクのタイプに対してアドバタイズされた最大 IOP やスループットを達成するのに十分なネットワーク容量がない可能性があります。詳しくは、下りネットワーク上限をご覧ください。

Compute Engine のそれぞれのディスクタイプで利用可能な I/O の合計は、インスタンスに接続されているボリュームの総サイズに関係します。たとえば、2 つの 2.5 TB 標準型永続ディスクがインスタンスに接続されている場合、利用可能な総 I/O は、読み取りで 3,000 IOPS、書き込みで 7,500 IOPS になります。

ローカル接続されるディスク

ネットワーク接続される標準的なブロック ストレージに加え、Azure と Compute Engine では、インスタンスを実行している物理マシンにローカル接続された SSD も使用できます。どちらの環境でも、このようなディスクはローカル SSD と呼ばれます。ローカル SSD では、ネットワーク接続されたブロック ストレージよりも、はるかに高速に転送できます。ただし、ネットワーク接続されたブロック ストレージとは異なり、データの永続性は保証されず、ネイティブの差分スナップショット機能を使用してスナップショットを作成することはできません。

Azure では、ローカル SSD のサイズと可用性はマシンのタイプと直接関係します。ローカル SSD のサイズは 16 GiB の小容量のものや、8 TiB の大容量のものがあります。A Series などの一部のマシンタイプでは、ローカル SSD は組み込まれません。

Compute Engine では、f1-micro や g1-small のような共有コアタイプを除き、ほぼすべてのマシンタイプにローカル SSD を接続できます。ローカル SSD のサイズはディスクあたり 375 GB に固定されており、1 つのインスタンスに最大 24 を接続でき、合計は 9 TB です。

Compute Engine では、メンテナンスのためにホストマシンを停止する前に、ローカル SSD が自動的かつシームレスに移行されます。詳しくは、ライブ マイグレーションをご覧ください。

料金

Azure では、ディスク ボリュームは 1 か月あたりの割り当てられた GB 数で課金されます。ローカル SSD の料金は、VM の料金に含まれています。

Compute Engine の永続ディスクとディスク スナップショットも、1 か月あたりの GB 数で課金されます。ローカル SSD は、マシンとは別に課金されます。詳しくは、ローカル SSD の料金体系をご覧ください。

ファイル ストレージ

ファイル サーバー ベースのワークロード用に、Azure では分散 SMB ベースのファイル サーバー サービスである Azure Files が用意されています。

Google Cloud の Filestore は、データ用のファイル システム インターフェースと共有ファイル システムを必要とするアプリケーション向けのマネージド ファイル ストレージ サービスです。Filestore を使用すると、Compute Engine や Google Kubernetes Engine(GKE)のインスタンスでマネージド ネットワーク接続型ストレージ(NAS)をネイティブで簡単に活用できるようになります。

ストレージ エリア ネットワーク(SAN)

SAN ネットワークについては、Azure では Microsoft が専有する StorSimple という SAN アプライアンスを統合できます。アーキテクチャ上、StorSimple はオンプレミスの StorSimple SAN と、オンプレミス SAN の動作を複製する仮想クラウドベースのアプライアンスで構成されています。

Google Cloud では、永続ディスクを使用して SAN を想定するワークロードをサポートできます。SAN のコンテキストで使用される場合、永続ディスクは論理ユニット番号(LUN)デバイスを介してアクセスする論理ディスク ボリュームと類似しており、同様の方法でプロビジョニングできます。LUN ベースの論理ディスク ボリュームの場合と同様に、複数の永続ディスクを単一の VM インスタンスにマウントできます。また、単一の読み取り専用永続ディスクを複数の VM インスタンスにマウントすることもできます。詳しくは、データセンター プロフェッショナルのための Google Cloud Platform: ストレージをご覧ください。

クール ストレージ

Google Cloud と Azure はそれぞれ、定期的にアクセスする必要のないデータ用に、クール ストレージ オプションを用意しています。Cloud Storage の追加クラスは Cloud Storage Nearline および Cloud Storage Coldline と呼ばれています。また、Azure Blob Storage には追加のクール階層があります。

レイテンシ

どちらのサービスでも、最初のバイト転送時間は数ミリ秒です。

レプリケーション

Azure Blob Storage のクール階層を使用する場合、データのレプリケーション方法は、ストレージ アカウントに設定されているレプリケーション タイプによって異なります。Cloud Storage Nearline または Cloud Storage Coldline を使用するとき、データがレプリケーションされる方法は、データが格納されるロケーションのタイプによって異なります。

ストレージ期間

blob 固有ストレージ アカウントを使用する場合、Azure Blob Storage のクール階層には最小ストレージ期間は設定されていません。GPv2 ストレージ アカウントの場合、Azure Blob Storage のクール階層には、blob ごとに 30 日間の最小ストレージ期間が適用されます。最小ストレージ期間が終了する前に blob を削除または上書きすると、追加料金が発生します。

Cloud Storage Nearline のデータ オブジェクトごとの最小ストレージ期間は 30 日ですが、Cloud Storage Coldline のデータ オブジェクトごとの最小ストレージ期間は 90 日です。GPv2 アカウント内で Azure Blob Storage のクール階層を使用する場合と同じく、最小ストレージ期間が終了する前にデータ オブジェクトを削除または上書きすると、追加料金が発生します。

費用

Azure Blob Storage のクール階層

Azure Blob Storage のクール階層は、1 か月あたりのデータ保存量、ストレージ アカウントのタイプ、レプリケーション タイプ、ネットワーク(下り)によって価格設定されています。Azure Cool Blob Storage の場合も、一般的な API リクエスト、データ書き込み、データ取得に対して課金されます。

Cloud Storage Nearline と Cloud Storage Coldline

Cloud Storage Nearline と Cloud Storage Coldline のどちらも、1 か月あたりのデータの保存量とネットワーク(下り)のデータ量に応じて課金されます。最小ストレージ期間が終了する前にデータを削除または変更した場合、残りの期間分も課金されます。たとえば、オブジェクトを保存してから 5 日後に Cloud Storage Nearline として保存したオブジェクトを削除すると、そのオブジェクトの残りの 25 日分の保存に対して課金されます。Cloud Storage Nearline と Cloud Storage Coldline では、一般的な API リクエストとデータ取得に対しても課金されます。

Cloud Storage Nearline と Cloud Storage Coldline の料金の詳細については、Cloud Storage の料金をご覧ください。

アーカイブ ストレージ

GCP と Azure のそれぞれで、アーカイブ ストレージ オプションが用意されています。Cloud Storage では Cloud Storage Archive と呼ばれる追加クラスが提供されており、Azure Blob Storage では追加のアーカイブ層が提供されています。

レイテンシ

Cloud Storage Archive では、最初のバイト転送時間は数ミリ秒です。Azure Blob Storage のアーカイブ階層では、最初のバイト転送時間は 15 時間以下となります。

レプリケーション

Azure Blob Storage のアーカイブ階層を使用する場合、データのレプリケーション方法は、ストレージ アカウントに設定されているレプリケーション タイプによって決まります。Cloud Storage Archive を使用するとき、データがレプリケーションされる方法は、データが格納される場所のタイプによって異なります。

ストレージ期間

Azure Blob Storage のアーカイブ階層には、blob ごとに 180 日間の最小ストレージ期間が適用されます。最小ストレージ期間が終了する前に blob を削除または上書きすると、追加料金が発生します。

Cloud Storage Archive には、データ オブジェクトごとに 365 日間の最小ストレージ期間が設定されています。Azure Blob Storage のアーカイブ階層と同じく、最小ストレージ期間が終了する前にデータ オブジェクトを削除または上書きすると、追加料金が発生します。

費用

Azure Blob Storage のアーカイブ階層

Azure Blob Storage のアーカイブ階層は、1 か月あたりのデータ保存量、ストレージ アカウントのタイプ、レプリケーション タイプ、ネットワーク(下り)によって価格が設定されます。最小ストレージ期間が終了する前にデータを削除または変更しても、残りの期間に対して課金されます。たとえば、blob を保存して 5 日後にその blob を削除すると、残り 175 日分の blob 保存に対して課金されます。さらに、blob のスナップショットを取ると、それらのスナップショットは、blob のライブ バージョンと同じレートで課金されます。

Azure Blob Storage のアーカイブ階層では、一般的な API リクエストに対しても課金されます。

Cloud Storage Archive

Cloud Storage Archive は、1 か月あたりの保存データ量とネットワークからの送信量に基づいて課金されます。最小ストレージ期間が終了する前にデータを削除または変更した場合、残りの期間分も課金されます。たとえば、オブジェクトを保存した 5 日後に削除した場合、残り 360 日分のオブジェクトの保存に対しても課金されます。Cloud Storage Archive では、一般的な API リクエストとデータ取得に対しても課金されます。

Cloud Storage Archive の料金の詳細については、Cloud Storage の料金をご覧ください。

次のステップ

Azure プロフェッショナルのための Google Cloud に関するその他の記事をご覧ください。