はじめに
Amazon FSx for OpenZFSを触っていて、作成後に変更できる項目としてまず目に入るのがストレージ容量、スループットキャパシティ、プロビジョンドSSD IOPSです。
「後から変更できるなら、とりあえず小さめに作って必要になったら増やせばよさそう」と考えたくなるのですが、実際にはそれぞれに制約があります。特にストレージ容量は縮小できません。また、スループット変更時は構成によって短時間の不可用性が発生し、ストレージやIOPSの変更リクエストには6時間の間隔を空ける必要があります。これらは運用前に把握しておいたほうがよいポイントです。
この記事では、FSx for OpenZFSの中でもストレージ容量、スループットキャパシティ、IOPSの変更に絞って、設計・運用時に気をつけたい点を整理します。
想定読者
- AWSの基本的なサービスを理解しているインフラエンジニア
- FSx for OpenZFSをこれから設計・運用する方
- ファイルシステム作成後の性能・容量変更に関する制約を整理したい方
この記事でわかること
- FSx for OpenZFSで作成後に変更できる容量・性能系パラメータ
- ストレージ容量を増やすときの制約
- スループットキャパシティ変更時の影響
- プロビジョンドSSD IOPSの考え方
- 運用前に検証しておきたいポイント
前提
この記事では、主にFSx for OpenZFSのSSD(provisioned)ストレージを前提にしています。
また、検証メモの文脈ではSingle-AZ (non-HA)構成を中心に見ています。Multi-AZ (HA)やSingle-AZ (HA)、Intelligent-Tieringでは選択できるスループット値や変更時の挙動が異なる場合があるため、最終的には採用するデプロイタイプの公式ドキュメントを確認してください。
まず3つの役割を整理する
FSx for OpenZFSの容量・性能まわりでは、似たような設定項目が並んでいます。
| 項目 | 何を決めるか | 主な注意点 |
|---|---|---|
| ストレージ容量 | ファイルシステムとして確保するSSD容量 | 増やせるが減らせない。1回の拡張は現在容量の10%以上が必要 |
| スループットキャパシティ | ファイルサーバーがデータを処理する持続的な転送能力 | 変更時にファイルサーバーの入れ替えが発生する。Single-AZ (non-HA)では数分間利用できなくなる |
| プロビジョンドSSD IOPS | SSDストレージに対するI/O性能 | AutomaticとUser-provisionedを選べる。User-provisionedではSSD容量1GiBあたり3 IOPS以上が必要 |
ストレージ容量は「どれだけ入るか」、スループットは「ファイルサーバーがどれだけ速くさばけるか」、IOPSは「ディスク側でどれだけI/Oを処理できるか」と考えると整理しやすいです。
ストレージ容量の変更で気をつけること
増やせるが、減らせない
FSx for OpenZFSのSSDストレージ容量は、作成後に増やすことができます。一方で縮小はできません。
この制約があるため、容量不足を避けようとして最初から大きく作りすぎると、あとから使っていない容量を減らせません。検証環境や開発環境では小さめに始める判断もしやすいですが、本番環境では拡張単位や将来のデータ増加も含めて考える必要があります。縮小を行うためには再作成が必要になります。実際の案件では、すべてをルートボリューム直下で使うよりも、アプリケーションや用途ごとに子ボリュームを分けるほうが運用しやすい場面は多そうです。ただし、これは容量縮小のためというより、管理単位を分けるための設計と考えたほうがよさそうです。
使わなくなった容量を落としたい場合
運用していると、一時的なデータ増加に合わせて拡張したものの、後から「やっぱりここまでの容量はいらなかった」という場面はありそうです。
この場合、既存ファイルシステムのSSDストレージ容量をその場で小さくする方法はありません。不要データを削除すれば使用済み容量は減りますが、プロビジョニングしたSSDストレージ容量自体は減らないため、容量課金を落とすことはできません。容量課金を下げたい場合は、小さい容量で新しいFSx for OpenZFSファイルシステムを作成し、必要なデータだけを移行して切り替えるのが基本方針になります。注意点として、ファイルシステムバックアップからの復元では、復元先のストレージ容量に元のファイルシステム以上の値を指定する必要があります。そのため、単純なバックアップ復元は「容量を小さくして作り直す」用途には向きません。
現実的な選択肢は、以下のような流れです。
| 方法 | 概要 | 向いている場面 |
|---|---|---|
| 新しいファイルシステムを作成してrsyncなどで移行 | 小さい容量のファイルシステムを作り、必要なデータだけをコピーする | 容量を本当に下げたい場合 |
| アプリ単位で子ボリュームを分けて段階移行 | 移行単位として扱いやすくするため、用途ごとに子ボリュームを分けておく | 将来の移行・整理を見越す場合 |
| 不要データ削除のみ | 既存FSx上の使用済み容量だけ減らす | 容量課金は下がらなくてもよい場合 |
容量縮小が必要になったときの基本的な対応は、新しいファイルシステムの作成とデータ移行です。移行時は初回同期後に差分を同期し、書き込みを止めて最終同期してからマウント先を切り替えます。動作確認後に古いファイルシステムを削除します。
最初の設計段階では、将来のデータ整理や移行単位を意識して、ボリューム構成やマウント設計を決めておくのがよさそうです。
1回の拡張は10%以上が必要
ストレージ容量を増やす場合、1回の拡張は現在のSSDストレージ容量の10%以上である必要があります。以下は、64GiBから65GiBへ変更しようとして、10%以上の増加が必要というエラーが表示された画面です。
64GiBのファイルシステムでは、71GiBへの拡張であれば約10.94%の増加になるため変更できます。筆者が東京リージョンのSingle-AZ (non-HA)構成で検証した際は、更新リクエストから更新履歴が完了済みになるまで約3分でした。所要時間は環境によって異なる可能性があります。
一方で、容量が大きくなるほど「10%」の絶対量も大きくなります。たとえば100TiBのファイルシステムでは、構成上110TiBを利用できる場合でも最低10TiBの拡張が必要です。少しだけ増やす運用はできない点に注意が必要です。
拡張後は通常数分以内に利用可能になる
公式ドキュメントでは、SSDストレージ容量の増加後、新しい容量は数分以内に利用可能になると説明されています。また、ストレージ容量の拡張はエンドユーザーやアプリケーションの可用性には影響しないとされています。今回の検証では、再マウントせずにdfの表示が64GiB相当から71GiB相当に変わりました。
ただし、実際の運用では以下は確認しておいたほうがよいです。
- マウント済みクライアントの
dfで容量増加がいつ見えるか - アプリケーション側で容量情報をキャッシュしていないか
- 監視しきい値やアラート設定を更新する必要があるか
ボリュームのクォータにも注意する
FSx for OpenZFSでは、ファイルシステム自体のストレージ容量とは別に、ボリューム側のストレージ容量クォータがあります。ルートボリュームのクォータがファイルシステム容量と同じ値に設定されている場合、ファイルシステム拡張時にルートボリュームのクォータも自動的に更新されます。
一方で、それ以外のボリュームや、ルートボリュームのクォータがファイルシステム容量と一致していない場合は、必要に応じて手動でクォータを増やす必要があります。つまり、ファイルシステムのストレージ容量だけ増やしても、ボリューム側のクォータが小さいままだと、アプリケーションから見える利用可能容量は増えない可能性があります。
スループットキャパシティの変更で気をつけること
スループットはファイルサーバー側の性能
スループットキャパシティは、FSx for OpenZFSのファイルサーバーがファイルデータを処理する持続的な速度を表します。
スループットを上げると、単純な転送速度だけでなく、ファイルサーバー側のキャッシュ用メモリや一部のI/O性能にも影響します。そのため、Amazon CloudWatchメトリクスを見ながら、ストレージ容量を増やすべきなのか、スループットを増やすべきなのか、IOPSを増やすべきなのかを切り分ける必要があります。
Single-AZ (non-HA)では変更時に数分間利用できなくなる
スループットキャパシティを変更すると、裏側ではファイルシステムのファイルサーバーが入れ替わります。Multi-AZ (HA)やSingle-AZ (HA)ではフェイルオーバーとフェイルバックを伴います。Single-AZ (non-HA)では、スループット変更中にファイルシステムが数分間利用できなくなります。
今回の検証環境では、AWSマネジメントコンソールに「15分未満使用できなくなります」と表示されました。
そのため、Single-AZ (non-HA)でスループットを変更する場合は、短時間の停止を許容できる作業枠で実施したほうがよいです。
ストレージ容量やIOPSの更新中は変更できない
ストレージ容量やプロビジョンドSSD IOPSの更新が進行中の場合、スループットキャパシティの変更はリクエストできません。容量不足と性能不足が同時に見えている場合でも、すべてを同時に変更できるわけではありません。どの変更を先に行うか、変更後にどのくらい待つ必要があるかを運用手順に含めておく必要があります。
IOPSの変更で気をつけること
AutomaticとUser-provisionedがある
FSx for OpenZFSのプロビジョンドSSD IOPSには、AutomaticとUser-provisionedの2つのモードがあります。
| モード | 内容 | 向いているケース |
|---|---|---|
| Automatic | SSD容量1GiBあたり3 IOPSを、ファイルシステムの最大IOPSを上限として自動設定する | まずは標準的な設定で運用したい場合 |
| User-provisioned | 仕様上の範囲内でIOPS値を指定する | 容量に対して高いIOPSが必要な場合 |
User-provisionedを選ぶ場合、指定するIOPSはSSD容量1GiBあたり3 IOPS以上である必要があります。上限は通常1GiBあたり1,000 IOPSですが、一部リージョンでは1GiBあたり50 IOPSです。また、ファイルシステムやスループットキャパシティごとの上限もあります。
容量拡張と同時にも、単独でも変更できる
IOPSはストレージ容量を増やすタイミングで一緒に変更することも、IOPSだけを単独で変更することもできます。ただし、ストレージ容量とIOPSには関係があります。Automaticの場合は、ファイルシステムの最大IOPSに達するまで、容量に応じてIOPSが自動的に増えます。User-provisionedを使用中に容量を増やす場合は、同じ更新リクエストで新しい容量1GiBあたり3 IOPS以上となる値を指定する必要があります。指定しない場合や最低値を下回る場合は、更新リクエストが失敗します。
最大IOPSはデプロイタイプで変わる
プロビジョンドSSD IOPSの最大値は、デプロイタイプによって変わります。
公式ドキュメントでは、Single-AZ 1は最大160,000 IOPS、Single-AZ 2は最大400,000 IOPSと説明されています。Multi-AZは最大400,000 IOPSですが、リージョンなどによって上限が異なります。また、実際に利用できるIOPSはスループットキャパシティにも制限されます。本番設計では、サービスクォータだけでなく、最新のSSDパフォーマンス表も確認してください。
変更時の制約をまとめる
ここまでの内容を、運用時に確認しやすい形でまとめます。
| 変更対象 | 可用性への影響 | 主な制約 | 運用上の注意 |
|---|---|---|---|
| ストレージ容量 | 公式上、可用性への影響なし | 増加のみ。1回の拡張は現在容量の10%以上 | 拡張後、ボリュームクォータも確認する |
| スループットキャパシティ | Single-AZ (non-HA)では数分間利用不可 | ストレージ容量・IOPS更新中は変更不可 | 作業枠を確保し、アプリのリトライ挙動も確認する |
| IOPS | 公式ドキュメントには可用性への影響が明記されていない | User-provisionedではSSD容量1GiBあたり3 IOPS以上が必要。ファイルシステムなどの上限あり | 無停止を前提にせず、事前に検証する |
SSDストレージ容量の増加またはIOPS変更は、前回の変更リクエストから6時間経過するまで再度リクエストできません。これはAmazon EBSだけの話ではなく、Amazon FSx for OpenZFSの公式ドキュメントにも記載されています。Multi-AZやIntelligent-Tieringでは、スループット変更との間にも6時間の待ち時間が関係します。
短時間で何度も微調整する運用はしづらいため、変更前にCloudWatchメトリクスを見て、必要な変更量をある程度見積もってから実施するのがよさそうです。
運用前に検証しておきたいこと
実際に本番で使う前に、以下は一度検証しておくと安心です。
| 検証項目 | 確認したいこと | 見るポイント |
|---|---|---|
| ストレージ拡張 | マウント済みクライアントから容量増加が自動で見えるか |
dfの反映時間、再マウント要否、アプリ側の認識 |
| ボリュームクォータ | ファイルシステム拡張後、ルート以外のボリュームクォータを手動変更する必要があるか | ルートボリュームと子ボリュームで挙動が違うか |
| スループット変更 | Single-AZ (non-HA)で実際に何分止まるか | NFSエラー、アプリのリトライ、停止時間 |
| IOPS変更 | IOPS変更中にI/Oエラーや性能劣化が出るか | CloudWatchメトリクス、アプリログ、変更完了時間 |
| 変更リクエストの間隔 | 6時間制約が運用に影響するか | 連続変更が必要になった場合の手順 |
特にスループット変更時の停止時間は、公式ドキュメントだけでは実アプリケーションへの影響を判断しづらいです。NFSクライアントやアプリケーションのリトライ挙動によって見え方が変わるため、検証環境で実際に読み書きしながら変更するのがよいと思います。
まとめ
FSx for OpenZFSのストレージ容量、スループットキャパシティ、IOPSは作成後に変更できます。ただし、「変更できる」というだけで、いつでも気軽に変えられるわけではありません。
押さえておきたいポイントは以下です。
- ストレージ容量は増やせるが、減らせない
- ストレージ拡張は1回あたり現在容量の10%以上が必要
- ストレージ拡張後は、ファイルシステム容量だけでなくボリュームクォータも確認する
- スループット変更ではファイルサーバーの入れ替えが発生する
- Single-AZ (non-HA)では、スループット変更中に数分間利用できなくなる
- IOPSはAutomaticとUser-provisionedを選べる
- User-provisionedではSSD容量1GiBあたり3 IOPS以上が必要
- ストレージ容量・IOPSの変更リクエストは、前回のリクエストから6時間空ける必要がある
個人的には、最初から大きく作りすぎるよりも、CloudWatchメトリクスを見ながら必要に応じて増やす方針が取りやすいサービスだと感じています。ただし、10%拡張や6時間待ち、スループット変更時の短時間停止を考えると、無計画に小さく作ればよいわけでもありません。
本番導入前には、ストレージ拡張、ボリュームクォータ、スループット変更、IOPS変更の4点は一通り検証しておくのがよさそうです。
参考
- Modifying provisioned SSD storage capacity and IOPS - FSx for OpenZFS
- Modifying throughput capacity - FSx for OpenZFS
- Restoring backups - FSx for OpenZFS
- Creating volumes - FSx for OpenZFS
- SSD storage performance - FSx for OpenZFS
- Migrating using rsync - FSx for OpenZFS
- Service quotas on Amazon FSx for OpenZFS resources