COLUMN

1. 対象候補

対象候補は以下のとおりです。

• NFSサーバー on EC2
• SMBサーバー on EC2
• Amazon EFS
• Amazon FSx for Windows File Server
• Amazon FSx for NetApp ONTAP
• Amazon S3 File Gateway

各候補のコスト的優位点は以下のとおりです。

1-1. NFSサーバー on EC2

NFSサーバーをEC2インスタンスを使って構築する方法です。

EBSボリュームをCold HDD ボリュームとすることで、安価にアーカイブ用途のファイルサーバーを準備できそうです。

また、EBSスナップショットからリストアする際はファーストタッチペナルティは発生しますが、ボリュームをリストアしてからデータにアクセスできるまでの時間が短いことは魅力的です。

注意点としてはio2 Block Expressを除くEBSボリュームは2024/5/17時点で16TiBまでしかサイジングできません。これ以上のサイズの領域を一つの領域としてエクスポートする必要がある場合はLVMなどを使用して、複数のボリュームを束ねる必要があります。

1-2. SMBサーバー on EC2

SMBサーバーをEC2インスタンスを使って構築する方法です。

先述のNFSサーバー on EC2のSMBサーバー版です。

Windowsインスタンスを使用しており、複数のEBSボリュームを束ねる場合は記憶域スペースと記憶域プールを使うと良いでしょう。

• 記憶域スペースの概要 | Microsoft Learn

1-3. Amazon EFS

AWSが提供しているマネージド型のNFSサーバーサービスであるAmazon EFS(以降EFS)を使用して構築する方法です。

マネージドサービスでありOSのメンテナンスを行う手間がなくなるため、運用コストを下げることが可能です。

EBSボリュームや後述するAmazon FSx for Windows File Server、Amazon FSx for NetApp ONTAPと異なり、ストレージのプロビジョニングが不要です。サイジングの手間がなく、保存されているデータサイズに応じて課金が発生する仕組みなのでお手軽に利用できます。

また、最後にアクセスされてからの経過日数に応じて、より安価な低頻度アクセスクラスやアーカイブクラスに階層化することでコスト削減に繋げることが可能です。わざわざアーカイブ用のファイルサーバーに移動する必要がないのは非常にポイントが高いです。

• [アップデート] Amazon EFS に新たなストレージクラス Archive が追加され、より安価にデータを保存できるようになりました #AWSreInvent | DevelopersIO
• Amazon EFS アーカイブストレージクラスの利用をはじめる前に知っておきたい利用費のこと | DevelopersIO

1-4. Amazon FSx for Windows File Server

AWSが提供しているマネージド型のWindowsと互換性のあるファイルサーバーサービスであるAmazon FSx for Windows File Serverを使用して構築する方法です。

FSxWではストレージにHDDを選択することが可能です。アーカイブ用途にはピッタリではないでしょうか。

もちろん、マネージドサービスであるためEC2インスタンスを使用するパターンと比べて運用負荷は低くなると考えます。

また、HDDとは相性は悪いですが重複排除機能も存在します。

注意点としては1つのファイルシステムのストレージサイズの上限は64TiBである点です。1つのファイル共有で64TiBよりも大きいサイズを見せる必要がある場合はDFSを使用することになります。ファイル共有を分割しても良いのであれば、単純にFSxWを分割することになります。

1-5. Amazon FSx for NetApp ONTAP

AWSが提供しているマネージド型のNetApp ONTAPと互換性のあるストレージサービスであるAmazon FSx for NetApp ONTAP(以降FSxN)を使用して構築する方法です。

EFSのようにFabricPoolというアクセス頻度に応じてデータブロックを安価なストレージに階層化する機能があります。上手に活用することでペタバイトスケールのファイルサーバーとして動作させることが可能です。

また、重複排除や圧縮、コンパクションと物理データ使用量を削減する仕組みが多いことも魅力的です。

こちらもマネージドサービスであるためEC2インスタンスを使用するパターンと比べて運用負荷は低くなると考えます。

1-6. Amazon S3 File Gateway

ファイルをS3バケット上に保存し、そのゲートウェイを仮想マシンとして動作させるハイブリッドクラウドストレージソリューションであるAmazon S3 File Gateway(以降S3 File Gateway)を使用して構築するパターンです。

ファイルをS3の安価なストレージクラスに移動させることによって、コスト効率良くファイルを保存することができます。

S3を利用することによる高耐久性も見逃せません。

一方で、S3 File Gateway自体は多数のクライアントから同時に利用する用途として使用することは非推奨であることを注意しましょう。

2.コスト試算前提条件

コスト試算をするにあたっての前提条件は以下のとおりです。

ストレージの種類

• HDDが使用できる場合はHDDを選択

  • アーカイブ用途のため
  • ただし、EC2インスタンスのルートボリュームはSSD 30GiB固定

• S3のストレージクラスはStandardとStandard-IAを使用

  • Glacier Instant RetrievalやGlacier Flexible RetrievalなどGlacierのストレージクラスは2024/5/20時点では未対応

ストレージサイズ

• プロビジョニングする種類のストレージの場合、ストレージ使用率が70%になるようにプロビジョニング

• 上述に加えて、FSxNの場合はONTAPのオーバーヘッドを加味して以下のようにSSDをプロビジョニング

  • プロビジョニングするストレージサイズが30TiB未満 : 84%
  • プロビジョニングするストレージサイズが30TiB以上 : 89%

• FSxWでプロビジョニングするストレージサイズが64TiBを超過する場合は、FSxWを分割

  • その際、DFSは使用しない
• FSxNはStorage Efficiencyにより物理データ使用量が25%削減される想定で計算

• FSxWの重複排除・圧縮は0%で計算

  • HDDと重複排除処理の相性が悪いため

• FSxNのSSDの割合は7%で計算

  • Tiering Policy All想定
• EFSの頻繁にアクセスされるデータの割合は10%で計算
• EFSの低頻度アクセスリクエストはデータサイズの10%で計算
• S3のStandardとStandard-IAの割合は1:9

インスタンスサイズ

• 10TiB未満はメモリサイズ8GiB、10以上はメモリサイズ16GiBのものを選択する

  • EC2インスタンス : m6i.large or m6i.xlarge
  • 例外としてS3 File Gatewayはxlargeが必須要件であるためm6i.xlarge固定
• EFSはバーストスループットモードを選択

• FSxWはスループットキャパシティを以下のように選択

  • ストレージサイズが10TiB未満 : 64MBps
  • ストレージサイズが10TiB以上 : 128MBps
• FSxNはスループットキャパシティを128MBpsに選択

デプロイ

• 以下リソースはSingle-AZでデプロイ

  • FSxN
  • FSxW
  • EFS
  • EC2
• EFSはMulti-AZファイルシステムのパターンも作成

バックアップ

• EBSスナップショットの差分は毎日データサイズの1%分発生する想定

• 以下についてはバックアップストレージサイズをデータサイズの120%として計算

  • FSxN
  • FSxW
  • EFS
• EBSスナップショットアーカイブ、EFSバックアップのコールドストレージは使用しない

OS

• NFSサーバー on EC2のOSはAmazon Linux 2023想定
• SMBサーバー on EC2のOSはWindows Server想定

その他

• 料金は東京リージョン
• EC2インスタンスの料金は前払いなし3年Compute Savings Plansで計算
• FSxNのキャパシティプールストレージへの読み込みと書き込みリクエスト数に対する課金は計算しない
• S3のAPIリクエストの課金は計算しない
• S3のStandard-IAへのライフサイクル移行リクエスト数は毎月50,000 / TiB

アクセス頻度や、バックアップサイズによって料金は大きく変動するため、プロジェクトで活用する際は実際のワークロードに即した値に変更して試算してください。

3. コスト試算結果

コスト試算結果は以下のとおりです。

3-1. 1TiBの場合

EFSが非常に安価であることが分かります。

一方で保存したいデータ量が少ない場合はFSxNはToo muchのようです。

3-2. 5TiBの場合

S3 File Gateway以外はバックアップを取得しているのでS3 File Gatewayの安さが飛び抜けています。

NFSサーバー on EC2とSMBサーバー on EC2は相対的に高く見えます。コスト観点だと積極的にセルフマネージドで用意する必要性は薄そうです。

3-3. 10TiBの場合

FSxNがFabricPoolおよび重複排除・圧縮効果により相対的にコストが安くなってきました。

3-4. 50TiBの場合

バックアップ有無を差し引いてもS3 File Gatewayが圧倒的に安いです。

その他の候補についてはバックアップの有無でコストが倍以上の差が出るようになりました。これはストレージの階層やボリュームタイプに関わらず、バックアップやスナップショットの料金は同じであるためです。

3-5. 100TiBの場合

バックアップの有無でFSxNのコスト順位が変わることが分かります。これはバックアップデータに対しても重複排除や圧縮といったデータ削減処理が効いているためです。バックアップを取らないことにより、その優位性が相対的に薄れています。

4. まとめ

AWS上でアーカイブ用途のファイルサーバーとして選択され得る各構成のコスト試算をしてみました。

私個人の選択の目安をフローチャートに起こしてみました。

コストだけを追い求めるのであればS3 File Gatewayだとは思います。一方で、複数クライアントからファイルサーバーとしてアクセスさせるのであればEFSやFSxN、FSxWが選択肢に入るでしょう。

何はともあれ、意思決定をする際はよりお使いのワークロードに近しい値でコスト試算をすることをオススメします。バックアップサイズや更新量、アクセス数などでコストは大きく変動すると考えます。

この記事が誰かの助けになれば幸いです。

以上、クラスメソッドの のんピ でした!