こんにちは、こんばんわ！クラウドインテグレーション事業部の魚介系エンジニア松尾です。
今回は Amazon FSx For NetApp ONTAP について、私が過去に経験したストレージコスト部分の躓きポイントと最適化する方法についてご紹介させていただきます。
はじめに
Amazon FSx for NetApp ONTAP とは？
Amazon FSx for NetApp ONTAP(以降FSxNと呼称)は、NetApp の ONTAP ソフトウェアを基盤とする、AWS のマネージドファイルシステムサービスです。
ユーザはオンプレミスの NetApp 環境と同じようにデータ管理と保護を行うことができます。
FSxN は高いスループットと低レイテンシを提供し、エンタープライズレベルのデータ管理機能（スナップショット、クローニング、レプリケーションなど）を備えています。
Amazon FSx for NetApp ONTAP のコスト構成
まずは各種コストの構成要素を簡単にご説明します。
リソースのデプロイパターン
FSxN はデプロイタイプよって全体のコストが大きく変動しますので最初に説明します。
デプロイパターンとしては以下の通りです。
- シングル AZ リソース1配置
- シングル AZ リソース2配置
- マルチ AZ リソース1配置
- マルチ AZ リソース2配置
AWS公式サイトの料金欄(Amazon FSx for NetApp ONTAP の料金 – AWS)記載の名称をそのまま流用しておりますが、「1配置」、「2配置」の違いはリソースの数ではなく世代の違いとなります。
コストに関しては世代による大きな違いはありませんが、他の AWS サービスと同様にシングル配置、マルチ配置の違いにより2倍のコストが発生するものもあります。
デプロイタイプによるコストの違いは各項目ごとの章で説明します。
デプロイタイプの詳細については以下のAWS公式ドキュメントをご確認ください。
可用性、耐久性、デプロイオプション - FSx for ONTAP
なお、現状東京リージョンでシングル/マルチ AZ リソース2配置は利用できません。
SSD ストレージキャパシティ
SSDストレージは高速なデータアクセスを提供するための主要コンポーネントであり、そのコストはリソース作成時に確保したストレージ容量(GB/月当たり)に基づいて計算されます。
1TB が最小の設定値となりますので、利用想定の容量がそれを大きく下回る場合は他のストレージサービスの利用もご検討ください。
なお、前述のデプロイタイプでシングル AZ を利用するかマルチ AZ を利用するかで金額が倍変わってきますので、その点を考慮した上での設計が必要です。
SSD IOPS
IOPS（Input/Output Operations Per Second）は、データの読み書き操作の速度を示す指標です。 高い IOPS を設定することで、アプリケーションのパフォーマンスが向上しますが、その分コストも増加します。
デフォルトでは、SSD ストレージの GB ごとに 3IOPS が付与されますが、オプションでより高いレベルの IOPS をプロビジョニングできます。
付与される IOPS レートを超えてプロビジョニングされた平均 IOPS に対して IOPS-月単位で支払います。
SSD ストレージキャパシティと同様にデプロイタイプによって金額が変動しますのでその点の考慮も必要です。
スループットキャパシティ
スループットキャパシティは、データの転送速度を示す指標で、プロビジョニングしたキャパシティ(MBps/月当たり)に応じてコストが増加します。
プロビジョニングできるキャパシティはデプロイタイプが「1配置」の場合 128MB/s、「2配置」の場合 384MB/s の倍数で指定が可能です。
デプロイタイプがシングル AZ、マルチ AZ の違いだけでなく、「1配置」、「2配置」の種類に応じてもコストが変動しますので、その点の考慮が必要です。
キャパシティプール
キャパシティプールは、アクセス頻度の低いデータ向けにコストが最適化されたストレージです。
SSD ストレージキャパシティ内でからデータのアクセス頻度に応じてキャパシティプールに移行を行うことが可能です。
なお注意点として、キャパシティプールに直接データを保存することはできず、必ず SSD ストレージキャパシティを経由する必要があります。
そのため、事前にキャパシティプールのコスト計算を行う場合は SSD ストレージキャパシティも併せて想定の利用量を算出する必要があります。(詳細は後述)
キャパシティプールに保管されたデータにアクセスする場合、後述の「キャパシティプールの読み取りリクエスト」、「キャパシティプールの書き込みリクエスト」料金を追加で支払う必要があります。
SSD ストレージキャパシティと同様にデプロイタイプによって金額が変動しますのでその点の考慮も必要です。
キャパシティプールの読み取りリクエスト
前述のキャパシティプール内に保管されたデータを読み取る際に発生するコストです。
1000件当たりのリクエスト量に応じて課金が発生します。
デプロイタイプによる金額の変動はございません。
キャパシティプールの書き込みリクエスト
前述のキャパシティプール内に保管されたデータに書き込み処理を行う際に発生するコストです。
1000件当たりのリクエスト量に応じて課金が発生します。
デプロイタイプによる金額の変動はございません。
バックアップ
データのバックアップは、データ保護とリカバリのために不可欠です。バックアップは増分バックアップとなり、保存された最新のバックアップについてのみ課金(GB/月当たり)が発生します。
デプロイタイプによる金額の変動はございません。
SnapLock ライセンス
SnapLockは データの不変性を保証する機能で、コンプライアンス要件を満たすために使用されます。
SnapLock ボリュームで毎月消費されるストレージ容量の(GB/月当たり)に対して、追加の SnapLock ライセンス料を支払う必要があります。
デプロイタイプによる金額の変動はございません。
データ転送
FSxN からリージョンをまたいだデータ転送を行う場合に利用料(GB当たり)が発生します。
2022年2月23日以降に作成された FSxN ファイルシステムにおいては、AWS リージョン内の AZ 間通信に対する料金は発生しません。
※AWS VPN と AWS Direct Connect を使用してオンプレミスからデータにアクセスする場合、それらのサービスに関連する標準データ転送料金が適用されます。
デプロイタイプによる金額の変動はございません。
ストレージコスト削減のためのベストプラクティス
ここで、FSxN のコストの大部分を担うストレージコストについての詳細をご紹介いたします。
圧縮と重複排除の活用(ストレージ効率)
データ圧縮と重複排除機能を活用することで、ストレージ容量を節約しコストを削減することができます。
FSxNでは「ストレージ効率(Storage Efficiency)」設定と呼称され、ボリュームの作成時に有効/無効を選択することができます。
以下 AWS の公式 FAQ に記載の通り、ほとんどのワークロードでは本設定によるパフォーマンスの影響はない旨記載がありますので、基本的には有効化しましょう。 NetApp ONTAP ファイルシステム管理リソース – Amazon Web Services
公式の料金ページ(Amazon FSx for NetApp ONTAP の料金 – AWS)記載の「効果的なコスト、ストレージの圧縮と重複排除が有効」列の金額は本機能有効化の上で汎用のファイル共有ワークロードにおける通常の圧縮と重複排除による 65% のコスト削減を想定している金額となりますので、実際にどの程度の圧縮/重複排除の効果があるかは実データを用いた確認を行う必要があります。(筆者がとあるワークロードで100TB程度のボリュームを作成した際は1～2%しか圧縮/重複排除が効かなかったため、事前の試算は難しいことを理解した上で実際のワークロードにデータを保管して確認するしかないと思います)
なお本機能は SSD ストレージキャパシティ上のデータが対象となり、後述のストレージ階層化設定において「All」を指定した場合、即時キャパシティプールストレージに移行されるため、恩恵はほとんど受けられませんのでご注意ください。
キャパシティプールストレージの効果的な使用
キャパシティプールストレージを効果的に利用することで、コスト効率を最大化できます。
通常の SSD ストレージキャパシティよりもキャパシティプールストレージは遥かにコストが低いため、キャパシティプールストレージの利活用が FSxN の全体のコストに大きく影響してきます。
本機能を利用するか否かで FSxN を選定するかどうかに関わってくるといっても過言ではありません。
FSxN では SSD ストレージキャパシティをそのままストレージ容量として利用するわけではなく、オンプレミスの NetApp 同様にファイルシステム上にボリュームを作成し、そのボリュームに対してデータが保存できます。
ボリュームはシンプロビジョニングで構築でき、SSD ストレージキャパシティとして確保しているストレージ容量よりも大きい容量を割り当てることが可能です。
このシンプロビジョニング自体は真新しい技術というわけではないのですが、FSxN で利用する場合はキャパシティプールストレージとの関係性も踏まえるとやや複雑なため、その点も踏まえて詳細を後述します。
キャパシティプールストレージは階層化ポリシーを有効化することで利用することができます。
設定する階層化ポリシーに応じてプライマリストレージからキャパシティプールストレージへデータが移行されます。
※プライマリストレージとキャパシティプールストレージの関係は後述します。
階層化ポリシーの種類は以下の通りです。
Auto
ボリューム作成時のデフォルトの値でアクセス頻度の低いデータをキャパシティストレージへ移行するポリシーです。
新規でデータが保管されてからキャパシティプールストレージにデータが移行されるまでの冷却期間(プライマリストレージに保持される期間)を指定する必要があり、2～183日の間(デフォルトは31日)で設定が可能です。
その冷却期間内にアクセスされていないデータがコールドとしてマークされ、キャパシティプールストレージストレージに移動されるまでの日数を定義されます。
この冷却期間の設定は「Auto」及び「Snapshot only」のみに適用されます。
なお、キャパシティプールストレージに移行されたデータにファイルアクセスがあった場合、プライマリストレージ階層にデータが戻されます。(一部シーケンシャルなアクセスを除く)
初めてボリュームを作成する場合は本階層化ポリシーを選択し、実際のキャパシティプールストレージへの移行状態を確認するとよいでしょう。Snapshot only
スナップショットデータのみキャパシティプールストレージに移行します。
スナップショットは RDS、EBS のスナップショットのようにリソースを丸ごとバックアップするようなものと違い、NetApp が昔から標準的に提供しているボリュームごとに設定されるバックアップ領域になります。
本ポリシーにおいても「Auto」と同様に冷却期間を指定する必要があります。All
メタデータを除くすべてのデータとスナップショットをキャパシティプールストレージに移行します。
仕様上必ずプライマリストレージを経由しますが、数分程度でキャパシティプールストレージに移行され、その後プライマリストレージ階層に戻ることはありません。
基本的に初めて FSxN を利用する場合、階層化ポリシーは「Auto」をお勧めしますが、実際に「All」を試してみてワークロードとして問題なく稼働できるようならコスト効率が最も良い「All」をお勧めします。
※前述の通り早々にキャパシティプールストレージに移行する関係上、圧縮/重複排除の恩恵がほとんど受けられない点はご注意下さい。- None
全てのデータをプライマリストレージに保管します。(キャパシティプールストレージを利用しない)
階層化ポリシーは後で変更可能なため、「Auto」でどの程度キャパシティプールストレージが利用されるかの確認と実際のパフォーマンスを確認しつつ、他の階層化ポリシーを検討すると良いでしょう。
SSD ストレージキャパシティとボリューム内のストレージ階層の関係性について
キャパシティプールストレージをうまく活用する上で理解しておかなければならないのが、FSxN に実際に割り当てる SSD ストレージキャパシティとボリュームの各階層の関係性についてです。
筆者はこの部分が初めに理解できておらず大きなコストを支払うことになりました・・・。
逆にここをはじめに理解しておけば、FSxN は何も恐くありません！！
プライマリストレージについて
プライマリストレージはボリューム内でデータが一度は保存される場所です。
階層化ポリシーの種類によってデータがプライマリストレージに残るか、キャパシティプールストレージに移行されるかが変わってきます。
前述の通りボリュームはシンプロビジョニングの技術により FSxN 作成時に確保する SSD ストレージキャパシティを超えて作成ができますが、プライマリストレージの保存量は SSD ストレージキャパシティを超えることはできず、SSD ストレージキャパシティから容量を消費するかたちでの利用となります。
したがってプライマリストレージにどの程度のデータが保管されるかを考慮した上で、SSD ストレージキャパシティの容量を予め確保しておく必要があります。
キャパシティプールストレージ
階層化ポリシーの設定によってプライマリストレージより移行される低コストで大容量のストレージで、基本的にアクセス頻度の低いデータが移行/格納され、プライマリストレージよりもレイテンシーが高かったり、データの読み取り/書き込みに別途コストがかかったりします。(この辺は S3 のストレージクラスと同じような感じですね！)
ここで一番知っておいていただきたいのが、SSD ストレージキャパシティにキャパシティプールストレージは含まれていない点です。
例えば 10TB のうち 5TB をプライマリストレージに、5TB をキャパシティプールストレージにデータを保管する計算だった場合、必要な SSD ストレージキャパシティは 5TB のみです。
仮に 10TB の SSD ストレージキャパシティを確保した場合、10TB 分の SSD ストレージキャパシティ料金 + 5TB 分のキャパシティプールストレージ料金がかかることとなりますのでご注意ください。
筆者はこの点が理解できておらず損することとなりました。。。
ただし、仮に事前に理解をしていたとしても、前述の通りキャパシティプールストレージに直接データが保存できるわけではないため、正確な数字を洗い出すには SSD ストレージキャパシティを多めに確保した上で、階層化ポリシーを「Auto」にし、割合を計算する他ないと思います。
どうしてもコストが気になる場合は、いっそ「All」で設定して、レイテンシーが気にならなければそのまま使い続けるようなかたちでもよいかもしれません。
パフォーマンスがやや落ちたり、読み取り/書き込みリクエストの料金は別途かかってしまいますが、コストの大部分であるストレージ料金が大きく低減されるメリットは非常に大きいと思いますので、キャパシティプールストレージは是非有効に活用してみてください！！
まとめ
FSxN をコスト試算する上でのポイントをいくつかまとめさせていただきます。
ワークロードに応じたデプロイパターンを選択する
シングル AZ 配置、マルチ AZ 配置の違いでコストが2倍になる項目( SSD ストレージキャパシティ、スループットなど)も出てきますので、ワークロードに応じた構成をご選択ください。ワークロードに応じた階層化ポリシーを設定する
ワークロードに応じた適切な階層化ポリシーを選択することで、 SSD ストレージキャパシティコストを大きく削減することが可能ですが、以下の点を考慮した設計が必要です。
- データへのアクセス頻度
階層化ポリシー「Auto」とした場合は、アクセス頻度に応じてキャパシティプールストレージへ移行されますが、「All」とした場合すべてのデータがキャパシティプールストレージにデータが移行されるため、ワークロードによってはパフォーマンスに影響が出る可能性があります。
- 圧縮/重複排除の作用率
圧縮/重複排除はプライマリストレージに配置されたデータ対象となるため、階層化ポリシー「All」とした場合十分な恩恵を受けることができません。
階層化ポリシーが「Auto」の場合は圧縮/重複排除が行われたのちにキャパシティプールストレージにデータが移行されるため、もともと全体的にデータのアクセス頻度の低くキャパシティプールストレージへの移行データが多い場合は、「All」のほうがかえって費用が掛かる可能性があります。
- データへのアクセス頻度
- キャパシティプールストレージは SSD ストレージキャパシティに含まれない
キャパシティプールストレージ分の容量は SSD ストレージキャパシティで確保する必要はありません。
SSD ストレージキャパシティでキャパシティプールストレージ分の容量を確保すると単純にコストが加算されるだけですのでご注意ください。
- 適切な SSD ストレージキャパシティのサイズを調整する
初期導入時は最小の SSD ストレージキャパシティを設定した上で階層化ポリシーは「Auto」とし、どの程度キャパシティプールストレージに移行されるかを確認しながら調整するとよいでしょう。
既存のシステムからデータ移行する場合は、一旦総量が保管できる SSD ストレージキャパシティを準備し、階層化ポリシー「Auto」で各ストレージの割合を確認するか、いっそ階層化ポリシー「All」にし、キャパシティプールストレージに全データを保管した上で階層化ポリシーを「Auto」に変更するなどでも良いでしょう。(キャパシティプールストレージ利用時はパフォーマンスがやや落ちる点には注意！！)
さいごに
今回は Amazon FSx For NetApp ONTAP の利用時にかかるコストについて紹介させていただきました。
FSxN は他のストレージサービスよりも多くの機能が備わっており、設計しがいのあるストレージサービスです。
次回以降にそういった機能面のご紹介もできればと思っております。
では次回もお楽しみに！！！
