Hybrid Storage Architecture

オンプレミスとAWSをまたぐストレージを設計するとき、重要なのは単に、

データをAWSへコピーする

ことではありません。

既存アプリケーションが現在利用しているアクセス方式を維持しながら、

オンプレミスアプリケーション
↓
AWSストレージ

をどのように段階的に統合するかを考えます。

AWS Storage GatewayのVolume Gatewayは、そのための選択肢の1つです。

1. ハイブリッドストレージでは「アプリケーションの場所」と「データの場所」を分けて考える

移行期間中は、アプリケーションはオンプレミス、データの一部または主要データはAWS、という構成が必要になることがあります。

例えば、

オンプレミスアプリケーション
↓
iSCSI
↓
AWS Storage Gateway
↓
AWS側ストレージ

という形です。

この場合、アプリケーションから見えるアクセス方式をすぐには変更せず、ストレージ基盤だけを段階的にAWSへ統合できます。

つまりハイブリッドストレージでは、アプリケーションを移行する時点と、データをAWSへ移す時点を分離できることが重要です。

2. Volume GatewayはiSCSIブロックアクセスを維持する

AWS Storage GatewayのVolume Gatewayは、オンプレミスのアプリケーションサーバーへストレージボリュームをiSCSIデバイスとして公開します。

アプリケーション側からは、

アプリケーション
↓
OS / ファイルシステム
↓
iSCSIブロックボリューム

として利用できます。

したがって、既存アプリケーションがブロックデバイスを前提としている、すぐにAmazon S3 APIへ変更できない、既存のiSCSI利用を一定期間維持したい、という場合に評価できます。

重要なのは、AWS Storage Gatewayを利用しても、アプリケーションから見えるVolume Gatewayのインターフェイスはブロックアクセスであるということです。

3. キャッシュ型ボリュームではプライマリデータをAWS側へ置く

キャッシュ型ボリュームでは、プライマリデータをAWS側へ保存し、頻繁に利用するデータをオンプレミスのキャッシュへ保持します。

概念的には、

オンプレミスアプリケーション
↓
iSCSI
↓
Volume Gateway
↓
ローカルキャッシュ
↓
AWS

となります。

この方式では、オンプレミスですべてのデータ容量を保持する必要性を減らしながら、頻繁にアクセスするデータにはローカルキャッシュから低レイテンシーでアクセスできます。

したがって、全データ分のオンプレミスストレージを増設したくない、データの主要な保管先をAWS側へ移したい、頻繁に利用するデータだけはローカルで高速に利用したい、という場合に適しています。

4. キャッシュは「すべてのデータのローカルコピー」ではない

キャッシュ型ボリュームでは、アクセスされたデータをローカルキャッシュへ保持します。

アプリケーションが必要なデータを要求すると、

ローカルキャッシュを確認
↓
存在する
→ ローカルから利用

存在しない
→ AWS側から取得

という動作になります。

したがって、キャッシュ型ボリュームを、

AWSにもデータがある
+
オンプレミスにも全データが常に完全複製されている

と考えてはいけません。

ローカルキャッシュは、主に頻繁に利用するデータへの低レイテンシーアクセスを提供するための領域です。

5. 全量読み取りはキャッシュの利点を損なう場合がある

キャッシュ型ボリュームでは、アクセス頻度の高いデータをローカルに保持することで効果を得ます。

そのため、全ボリュームを定期的に読み取るウイルススキャン、全データを順番に読み込む処理、大量のコールドデータを継続的に走査する処理、などでは、AWS側にあるデータを大量にローカルへ読み戻す可能性があります。

この場合、

キャッシュヒットを増やす

という本来の利用方法とは逆に、

大量のデータ取得
↓
ネットワーク帯域幅の使用量増加
↓
キャッシュ内容の入れ替わり

が発生する可能性があります。

したがってキャッシュ型ボリュームでは、総データ容量だけでなく、実際のアクセス局所性も確認します。

6. Volume GatewayのAmazon S3利用は通常のオブジェクトアクセスとは異なる

キャッシュ型ボリュームではAWS側の主要データ保存にAmazon S3が利用されます。

しかし、これは、

アプリケーション
↓
Amazon S3 API
↓
オブジェクト

という通常のAmazon S3オブジェクトアクセスへアプリケーションを変更したことを意味しません。

Volume Gatewayによって保存されるボリュームデータへ、通常のAmazon S3 APIやAmazon S3コンソールから直接アクセスする設計ではありません。

アプリケーションから見えるのは引き続き、

iSCSIブロックボリューム

です。

つまり、バックエンドでAmazon S3を利用することと、アプリケーションをオブジェクトストレージへ変更することは別です。

7. 保管型ボリュームではデータセット全体をオンプレミスへ保持する

保管型ボリュームでは、プライマリデータセット全体をオンプレミスに保持します。

概念的には、

オンプレミスアプリケーション
↓
iSCSI
↓
Volume Gateway
↓
ローカル保管ボリューム
↓
ポイントインタイムスナップショット
↓
AWS

となります。

アプリケーションはローカルにあるデータセット全体へ低レイテンシーでアクセスしながら、データのポイントインタイムスナップショットをAWS側へ非同期にバックアップできます。

したがって、データセット全体へのローカル低レイテンシーアクセスが必要、全データを保持できるオンプレミスストレージ容量がある、AWSへオフサイトバックアップを作成したい、という場合に評価します。

8. キャッシュ型と保管型では「どちらを正本にするか」が異なる

2つの構成を整理すると、

したがって、

キャッシュが欲しい

という理由だけでキャッシュ型を選ぶのではありません。

中心となる判断は、プライマリデータをAWS側へ置くのか、オンプレミスへ残すのかです。

9. Volume Gatewayはオンプレミス統合の境界になる

Volume Gatewayを利用すると、既存アプリケーションからはiSCSIブロックアクセスを維持しながら、AWS側へデータを連携できます。

このため移行期間中に、

アプリケーション
= オンプレミス

ブロックアクセス
= iSCSI

ストレージ統合
= AWS Storage Gateway

という構成を取れます。

この設計では、アプリケーションを先に変更する、データ形式を先にオブジェクトへ変換する、という作業を必須にせず、ストレージ統合だけを先行できます。

一方、最終的にアプリケーション自体をオブジェクトAPIや共有ファイルアクセスへ変更する場合は、そのアクセス方式に適した別のストレージモデルを改めて評価します。

10. スナップショットは条件を満たせばAWS側への移行経路にも利用できる

Volume Gatewayのボリュームからは、ポイントインタイムのスナップショットを作成できます。

これらはAmazon EBSスナップショットとして扱われます。

Amazon EBSへ復元可能なサイズなどの条件を満たす場合は、スナップショットからAmazon EBSボリュームを作成し、Amazon EC2へ接続できます。

特に注意するのはサイズです。

Amazon EBSボリュームとして復元できるスナップショットは16 TiB以下です。

キャッシュ型Volume Gatewayでは16 TiBを超えるボリュームを構成できる場合がありますが、そのようなボリュームのスナップショットを、そのままAmazon EBSボリュームへ復元できるとは限りません。

したがって、移行経路として、

オンプレミスアプリケーション
↓
Volume Gateway
↓
スナップショット
↓
Amazon EBS
↓
Amazon EC2

を計画する場合は、対象ボリュームがAmazon EBSへ復元可能な条件を満たしているかを事前に確認します。

Volume Gatewayは、

永久にオンプレミスへ残すためだけの構成

とは限りません。

条件を満たすワークロードでは、オンプレミスのiSCSIアクセスを維持するハイブリッド期間を作り、その後AWS側のAmazon EC2 + Amazon EBSへ移るという段階的な移行にも利用できます。

11. 移行の切り替えでは最終状態を先に決める

ハイブリッド構成を設計するときは、

まずVolume Gatewayを導入する

だけで終わってはいけません。

最終的に、アプリケーションをオンプレミスへ残すのか、Amazon EC2へ移行するのか、ブロックアクセスを継続するのか、将来は別のストレージモデルへ変更するのか、を確認します。

例えば最終状態が、

Amazon EC2
+
Amazon EBS

なら、対象ボリュームがAmazon EBSへの復元条件を満たすことを確認したうえで、

ハイブリッド期間：

オンプレミス
↓
iSCSI
↓
Volume Gateway

移行時：

スナップショット
↓
Amazon EBS

移行後：

Amazon EC2
↓
Amazon EBS

という段階的な構成を計画できます。

16 TiBを超えるなどAmazon EBSへそのまま復元できない条件では、この経路を前提にせず、別の移行方法を検討します。

12. Volume Gatewayは単なる一括データ転送サービスではない

一度だけ大量データをAWSへコピーすることと、オンプレミスアプリケーションが継続して利用するストレージをAWSと統合することは異なります。

Volume Gatewayでは、オンプレミスアプリケーションが継続的にiSCSIボリュームを利用できます。

したがって、

既存ブロックアクセスを維持
+
ハイブリッド期間を運用
+
AWS側へデータを保護
+
将来の移行経路を準備

という要件で評価します。

単純な一括コピーだけが目的なら、データ転送方法そのものは別途判断します。

13. 判断フロー

既存アプリケーションが必要とする
ストレージアクセス方式を確認
↓
iSCSIブロックアクセスを
移行期間中も維持する必要があるか
↓
AWS Storage Gateway
Volume Gatewayを評価
↓
プライマリデータをどこへ置くか
├─ AWS側
│   ↓
│  キャッシュ型ボリューム
│
└─ オンプレミス
    ↓
   保管型ボリューム
↓
必要なローカル低レイテンシーアクセスを確認
↓
キャッシュ型ではアクセス局所性を確認
↓
将来AWS側へ移行する場合は
Amazon EBSへの復元条件を確認
↓
条件を満たす場合
スナップショット → Amazon EBS
↓
ハイブリッド期間と最終構成を確定

重要なのは、Volume Gatewayを単なるバックアップ機能として見るのではなく、既存ブロックアクセスを維持しながらオンプレミスとAWSの境界を段階的に移動させるためのストレージアーキテクチャとして判断することです。