Storage ArchitectureをModernizeする

既存システムでは、ストレージそのものよりも、そのストレージを維持するための運用がアプリケーションの成長を妨げていることがあります。

例えば共有ファイル基盤で、

NFSファイルサーバー
↓
容量不足
↓
ディスク追加
↓
ファイルシステム拡張
↓
障害に備えて待機系を維持
↓
OSパッチ
↓
監視

を運用担当者が継続している構成です。

別のシステムでは、

Amazon EC2
├─ ローカル画像
├─ ローカル画像
└─ ローカル画像

cron / rsync
↓
各インスタンスへ複製

のように、ストレージ容量とデータ複製がコンピューティングの台数へ結び付いている場合もあります。

Storage Modernizationでは、何を保存するかだけでなく、保存するために現在どの運用責任を自前で持っているかを確認します。

1. ストレージ方式の再選択ではなく運用責任を探す

Block / File / Object Storageの違いや、Amazon EFSとAmazon S3のアクセス方式はすでに確認しています。

ここではそれを前提として、

必要なアクセス方式
↓
確定済み

その方式を維持するために
どの運用を自前で行っているか
↓
Modernization候補

と考えます。

例えば共有ファイルであれば、

ファイルサーバーOS
容量
冗長構成
障害切り替え
ファイルシステム

を自前で管理している可能性があります。

オブジェクトとして扱えるデータであれば、

EC2ローカルディスク
複製スクリプト
容量追加
インスタンス間同期

が残っている場合があります。

これらをストレージ固有の技術的負債として確認します。

2. Shared Fileの意味が必要なら、その意味は残す

既存アプリケーションが、

複数のLinuxサーバー
↓
同じディレクトリ
↓
同じファイルを参照・更新

しており、

NFS
ファイルパス
ディレクトリ
POSIX系ファイル操作

を維持する必要があるとします。

この場合、Modernizationの目的は、共有ファイルを必ずオブジェクトへ変換することではありません。

必要な共有ファイルの意味は維持しながら、ファイルサーバーそのものを利用者が管理する責任を減らせるかを考えます。

3. 自前NFSファイルサーバーの運用責任を棚卸しする

既存の共有ファイル基盤では、例えば次の作業を行っている場合があります。

OSパッチ
NFSサービス管理
ディスク容量監視
容量追加
ファイルシステム拡張
障害ノード交換
待機系管理

重要なのは、共有ファイルを使いたいという業務要件と、ファイルサーバーを自分たちで構築・維持したいという運用方式を分けることです。

後者が必須要件でなければ、Modernizationの余地があります。

4. Amazon EFSへShared Fileの基盤責任を移せるか評価する

共有ファイルのアクセス方式を維持する必要がある場合は、Amazon EFSへの移行を評価できます。

例えば、

現在

Linuxアプリケーション
↓
自前NFSファイルサーバー
↓
自前ディスク管理

から、

Modernization後

Linuxアプリケーション
↓
Amazon EFS

へ変更します。

ここでの中心は、NFSだからAmazon EFSというサービス選択ではありません。

すでに必要なアクセス方式が確認できている状態で、ファイルサーバー基盤、容量管理、ストレージインフラ管理を利用者側から減らせるかを判断します。

5. 容量拡張作業をストレージ利用から切り離す

自前ファイルサーバーでは、

使用量増加
↓
容量追加
↓
ファイルシステム拡張

という運用が発生する場合があります。

Amazon EFSの既習特性を前提に、ここでは、共有ファイルを利用するというアプリケーション要件と、保存量の増加に合わせてストレージ基盤を手動拡張するという運用責任を分離できるかを評価します。

Storage Modernizationで削減したいのは、共有ファイルという要件そのものではなく、利用量の変化へ追従するための基盤変更作業です。

性能要件については、容量管理とは別に引き続き確認します。

6. 旧環境の耐障害構成をそのまま再現しない

自前ファイルサーバーでは、

RAID
待機サーバー
複製
バックアップ

などを組み合わせて要件を満たしている場合があります。

Amazon EFSへModernizeするときは、旧環境で利用していた個々の仕組みをそのままAWS上へ再作成するのではありません。

先に、

どの障害に耐える必要があるか
どの程度のDurabilityが必要か

という要件へ戻し、AWSサービス側へ移せる責任と、利用者に残る保護要件を整理します。

目的は旧構成のコピーではなく、必要な要件を満たしながら自前のストレージ基盤管理を減らすことです。

7. コンピューティングごとにデータを複製していないか確認する

別のModernization候補が、

データ
=
アプリケーションサーバーの
ローカルディスク

という構成です。

例えば画像配信システムで、

EC2-A
/images

EC2-B
/images

EC2-C
/images

を持ち、

cron
+
rsync

で同じ画像を複製しているとします。

この構成では、

アプリケーションを
1台増やす
↓
新しいディスクを用意
↓
画像を複製
↓
同期対象を追加

となります。

つまり、コンピューティングのScalabilityとストレージのScalabilityが結合しています。

8. Object Storageへ変更できるデータはコンピューティングから分離する

画像、生成済みレポート、配布ファイルなどが、

オブジェクト単位で保存
+
IDやキーで取得
+
共有ファイルロック不要
+
アプリケーションを
オブジェクトAPIへ変更可能

であるなら、Amazon S3へ責任を移せる可能性があります。

例えば、

現在

EC2
↓
ローカル画像
↓
他EC2へ複製

から、

Modernization後

EC2群
   ↓
Amazon S3

へ変更します。

これによって、EC2台数と、保存データのコピー数・ストレージ容量を分離できます。

9. Amazon S3へ移した後も旧複製方式を残さない

Amazon S3へオブジェクトを移した後に、

念のため各EC2にも
同じファイルを保持する

という構成を残すと、

インスタンス追加
↓
コピー追加
↓
同期対象増加

という元の運用依存が残ります。

ここではAmazon S3のDurabilityそのものを再学習するのではなく、既習のサービス特性を前提として、自前コピーで担っていた責任のうちAWS側へ移せたものは何かを確認します。

サービス移行後も不要な旧運用を残すと、Storage Modernizationの効果を十分に得られません。

10. AWSへ移らないデータ保護責任を整理する

マネージドストレージへ移した後も、利用者側に残るデータ保護要件があります。

例えば、

誤削除から復旧したい
過去の状態へ戻したい
一定期間保持したい

などです。

これらについては、既習のS3 バージョニングなどを要件に応じて利用します。

ここでの判断対象は、Durabilityとは何かではなく、ストレージ基盤をAWSへ移した後、どの保護責任まで移ったのか、どの責任は利用者に残るのかを再整理することです。

11. Scalabilityを妨げている手作業を探す

既存ストレージでは、

保存量が増える
↓
容量変更作業

サーバーが増える
↓
データコピー追加

アクセスが増える
↓
構成変更

という運用が発生する場合があります。

ここではAmazon S3やAmazon EFSのScalability自体を再講義するのではなく、

ワークロードの成長
↓
ストレージ担当者の
手作業も比例して増える

構造をModernization対象として確認します。

目標は、コンピューティング台数、保存データ量、アクセス量の増減を、手動の容量変更、複製先追加、ストレージ基盤変更からできるだけ分離することです。

12. 1つのNASに異なる責任が混在していないか確認する

既存の1つのNASに、

共同編集する業務ファイル
+
生成済み画像
+
配布用レポート

がまとめて保存されている場合があります。

しかし、現在1台のNASに入っているからといって、Modernization後も1種類のストレージだけですべて処理する必要はありません。

例えば、

共同編集する業務ファイル
↓
Shared Fileの意味を維持
↓
Amazon EFS

生成済み画像・配布レポート
↓
Object Storageへ変更可能
↓
Amazon S3

と分割できます。

この分離によって、共有ファイル容量の増加と、大量に増えるオブジェクトデータを同じファイルサーバー基盤で処理する必要がなくなります。

Storage Modernizationでは、既存ストレージ装置の境界ではなく、データが必要とするアクセス方式と運用責任で境界を引き直すことを検討します。

13. マネージドストレージでも利用者側の責任は残る

Amazon EFSやAmazon S3へ移行しても、何も設計しなくてよいわけではありません。

例えば利用者側では引き続き、

アクセス制御
暗号化要件
性能要件
保持要件
必要なデータ保護
監視
コスト管理

などを考える必要があります。

一方、

物理ディスク交換
ファイルサーバーOSのパッチ
ストレージ装置の容量拡張

などは、利用しているAWSサービスによっては直接管理する必要がなくなります。

Modernizationでは、以前やっていた作業をすべてAWS上でも続けるのではなく、AWSへ移った責任と利用者に残る責任を整理し直します。

14. モダナイゼーション判断表

15. 判断フロー

既存ストレージを確認
        ↓
必要なアクセス方式は
すでに確定しているか
        ↓
はい
        ↓
現在どの運用責任を
自前で持っているか確認

Shared Fileなら、

共有ファイルの意味を
維持する必要がある
        ↓
自前ファイルサーバー
容量管理
基盤管理が残っている
        ↓
Amazon EFSへ
責任を移せるか評価

Object Storageへ変更できるなら、

ローカルディスクや
共有ファイルに保存
        ↓
アプリケーションは
オブジェクトAPIへ変更可能
        ↓
Amazon S3へ
データを分離できるか評価
        ↓
コンピューティングごとの
コピー・容量管理を削減

1つのストレージへ異なるデータが混在しているなら、

Shared Fileが必要なデータ
+
Object Storageへ変更できるデータ
        ↓
責任境界を分ける
        ↓
Amazon EFS
+
Amazon S3
を必要な部分へ適用

最後に、

AWSへ移った運用責任
        ↓
利用者に残る
アクセス・性能・保持・
データ保護要件
        ↓
重複した旧運用を廃止

します。

最終的な目的は、ストレージをAWSへ置くことではなく、必要なアクセス方式を維持しながら自前のストレージ基盤運用とコンピューティングへの依存を減らすことです。