SAA-3.1高パフォーマンスでスケーラブルなストレージソリューションを選択する。

ヒントボタン

アベイラビリティゾーン障害時にも同じ NFS パスでシームレスに読書きしたい場合、リージョン冗長が標準で備わり、各 AZ にマウントターゲットを配置しても追加設定なしで自動フェイルオーバーする Amazon EFS がファーストチョイスになります。EC2 側はマウントコマンドを統一するだけなので運用工数を大幅に削減でき、ロードバランサーの切替や自前レプリケーションも不要になります。

1 GiB/秒や 50,000 IOPS クラスの突発負荷に備えるなら、Amazon EFS の Max I/O パフォーマンスモードとプロビジョンドスループットを組み合わせると、使用容量に比例してスループットが拡張され、必要帯域を予約することも可能です。ストレージは書込み量に応じて自動拡張するため、1 日 3 TB の継続的追記でもボリューム拡張や RAID 再構築は不要で、I/O クレジットを気にせず安定性能を維持できます。

ローカル NVMe インスタンスストアや io2 Block Express で自前 NFS を構築すると単一 AZ 障害で途切れやすく、Storage Gateway File Gateway はスループットとレイテンシに限界があります。マルチ AZ 可用性、数万 IOPS を超える性能、容量の無制限拡張、そしてフルマネージド運用という複数要件を俯瞰し総合判断すれば、選ぶべきサービスが浮かび上がるはずです。

ヒントボタン

500 台の c5n.18xlarge が 100 Gbps ENA を束ねて数百 GB/秒を単一ネームスペースで流す想定では、HPC 向け Amazon FSx for Lustre の並列 I/O と広帯域メタデータサーバーが目標値にどこまで合致するかを起点に考え、Amazon S3 API 直接アクセスやバーストクレジット型 Amazon EFS、io2 Block Express＋EBS Multi-Attach の公称上限と運用特性を並べて比較すると 200 GB/秒超を持続できる構成が浮かび上がります。

「POSIX 準拠かつ単一ネームスペース」と「Amazon S3 と双方向同期」を同時に満たすサービスを探すときは、Amazon FSx for Lustre が備えるデータリポジトリ関連付け（DRA）による on-demand import／自動エクスポートを思い出し、Amazon DataSync やスクリプトを介さず Lustre クライアントのファイル操作だけで S3 オブジェクトを透過的に扱える点をヒントに整理してみてください。

数時間単位で容量やスループットを伸縮しつつ運用を最小化したい場合、Amazon EFS の Elastic スループットと比較してもクラスターリサイズ API を持つ Amazon FSx for Lustre の自動スケールアウトと高速リビルドがサブミリ秒レイテンシを維持して数 PB 規模を扱える特性が光るため、HPC・フルマネージド・時間単位の拡縮という複数要件を俯瞰して総合判断を下す視点が鍵になります。

ヒントボタン

600 名の設計者が Windows から SMB 共有へ同時接続し、NTFS ACL や VSS シャドウコピーで自己復元したいという条件では、Active Directory 連携と Windows ネイティブ機能をフルに備えたストレージが欠かせません。Amazon FSx for Windows File Server はその要件をマネージドで丸ごと満たせる一方、FSx for Lustre は POSIX 向け、File Gateway はキャッシュ型で機能差が大きいことを思い出してください。

RTO 5 分・RPO 30 分を守るには AZ 障害時でも数秒で自動フェイルオーバーする構成が必要です。io2 マルチアタッチ EBS は同一 AZ 制限が残り DFS レプリケーションは非同期遅延が避けられませんが、Amazon FSx for Windows File Server をマルチ AZ 配置にするとプライマリとスタンバイが別 AZ で同期され、DNS 自動切替により SMB セッションをほぼ途切れさせずにサービスを継続できます。

2 GB/秒の高スループットと 40 TB までの拡張性は FSx for Windows File Server の SSD ボリュームで最大 8 GB/秒・64 TB までオンライン伸張可能なので余裕があります。日次自動バックアップやオンプレミスの Active Directory／AWS Managed Microsoft AD 参加も数クリックで有効化でき、運用者はパッチ適用やフェイルオーバー管理から解放されます。性能・可用性・運用負荷の三要素を総合的に比較すると、フルマネージドで Windows ワークロード特有の要求に最も自然に合致するサービスが見えてきます。

ヒントボタン

SMB プロトコルを完全マネージドで提供し、東京リージョンの 2 つの AZ に同期コピーを保持して障害発生時は数十秒で自動フェイルオーバーする仕組みを標準で備えるのは Amazon FSx for Windows File Server です。プロビジョンドスループットを 500 MB/s に設定すれば 10 TiB かつ同時 15,000 接続が性能設計ガイドライン内に収まり、SLA 99.99%、RTO 5 分、RPO 0 に到達できます。

オンプレミスの Active Directory と ID を継続利用しつつクラウド側のドメインコントローラのパッチ適用まで AWS に任せたいなら AWS Managed Microsoft AD との双方向信頼が定石です。Amazon FSx for Windows File Server をこのディレクトリに参加させると NTFS ACL、Kerberos、SMB 署名を変えずに使え、Direct Connect 経由で 5 ms 未満の低レイテンシも狙えます。さらにサービス側で自動スナップショットや OS パッチが実行されるため運用工数とコストを大幅に削減できます。

EC2 や Amazon EFS で SMB を自前構築する案、単一 AZ 構成や DFS Replication で冗長化する案は、可用性 99.99%、RPO 0、RTO 5 分、持続 500 MB/s といった複数の厳格要件を同時達成するために追加のレプリケーション設計や容量増設、性能チューニング、フェイルオーバー手順の自社運用が不可欠になります。これらの作業負荷とリスクを最小化しつつ要件を満たせるマネージドサービスとディレクトリ統合の組み合わせを総合的に評価すると、自動同期レプリケーションと高い SLA を提供する Amazon FSx for Windows File Server（マルチ AZ） + AWS Managed Microsoft AD 構成が最も合理的と言えます。

ヒントボタン

Windows ベースの CAD クライアントがそのままファイルを開けるには SMB プロトコルと NTFS ACL をフルに維持できる共有が不可欠で、Amazon EFS は NFS 専用、Amazon S3 ＋ File Gateway はオブジェクト ACL、EC2＋EBS ではクラスター運用と継続的パッチが必要になる一方、Amazon FSx for Windows File Server は Directory Service の AD Connector と組み合わせることでオンプレミスの Active Directory と透過的に連携しつつ SMB と NTFS をマネージドで提供でき、管理負荷を最小化できます。
要求される 10 万 IOPS・2GB／秒・5ms 未満という高負荷はスループット容量 2GB／秒を持つ Amazon FSx for Windows File Server のマルチ AZ 構成が高速 NVMe キャッシュと分散ファイルシステムで満たせ、マルチ AZ ミラーリングにより AZ 障害でも DNS フェイルオーバーだけで継続し、日次自動バックアップを 30 日間保持しても復元が数十分なので RTO 1 時間と RPO 24 時間の目標を余裕でクリアできます。
まとめると、SMB と NTFS ACL 互換、オンプレ AD 認証継続、10 万 IOPS と 2GB／秒のスループット、5ms 以下のレイテンシ、マルチ AZ 可用性、自動バックアップ 30 日、運用負荷最小化という複数要件を並べて評価すると、マネージドで Windows ネイティブの Amazon FSx for Windows File Server を中心に Directory Service を併用した構成が最もバランス良く要件を満たすと判断できます。

ヒントボタン

バッチ中に必要な 40 000 IOPS と 1 GiB/s を EBS だけで即座に賄えるのは io2 Block Express です。gp3 は 16 000 IOPS、io1 はスループットを拡張するには容量追加が要るためコストが跳ね上がり、st1 や Storage Gateway 経由の HDD は根本的に性能帯域が届きません。まず処理フェーズでボトルネックにならないボリューム性能表を見比べてみてください。

バッチ後の成果物は 30 日間よく読まれ、その後は 10 年保管という典型的な階層化ユースケースです。Amazon S3 に置いた直後は Standard で保持し、Lifecycle で 30 日目に Glacier Flexible Retrieval へ自動遷移、取り出しは Expedited リストアなら 1～5 分で完了します。これなら RTO 2 時間を余裕で満たしつつ保管単価を大幅に削減できます。

EBS スナップショットやオンプレミス NAS からテープへ退避する案もありますが、復元時間やハードウェア運用が増えがちです。S3 と Glacier 系は 11 ナインの耐久性とライフサイクル自動化で運用負荷を下げられるため、処理性能・コスト・保持・RTO という複数要件を総合的に見渡すとクラウドネイティブな階層化ストレージ構成が最も合理的と判断できます。

ヒントボタン

ヒント1
95パーセンタイルで 1 ms 未満という厳格な応答時間は、ディスク I/O が介在する Amazon RDS や素の Amazon DynamoDB では安定して達成しづらいです。インメモリでネットワーク往復だけになる Amazon ElastiCache for Redis ならマイクロ秒〜 1 ms 台が一般的で、クラスタモードを有効にすればシャーディングでスループットを線形に伸ばせます。まずは「超低レイテンシー要件→インメモリ」というマッピングを押さえてください。

ヒント2
マルチ AZ 障害対策では、プライマリ障害時に自動フェイルオーバーしつつ書き込みを引き継げる仕組みが不可欠です。Amazon ElastiCache for Redis の Multi-AZ 機能はプライマリとレプリカを異なる AZ に配置し、数十秒で昇格を完了します。Application Load Balancer のスティッキー機能ではインスタンス故障時にセッションが失われるため「サーバーはステートレス、セッションは共有ストア」という設計原則が安定運用への鍵になります。

ヒント3
30 分で自動消えるセッションなら期限切れデータをアプリで明示削除するより、TTL をネイティブ実装したサービスを使うほうがメモリコストを抑えられます。Redis はキー単位 TTL をサブミリ秒粒度で持ち、例えば 2 シャード × 3 ノード構成にするとレプリカを含む冗長化と水平スケールを両立できます。性能・可用性・コストの要件をすべて横並びに比較すると、インメモリかつ Multi-AZ フェイルオーバー対応で TTL が使える選択肢が最も理にかなっています。

ヒントボタン

HPCゲノム解析では1,000台規模のc6gnが数百万IOPSと毎秒200GB近い帯域を単一ネームスペースに投げるため、Amazon FSx for Lustreのように容量1TiBあたり200MB/sで水平方向にスループットを伸ばせる並列ファイルシステムが有効です。Scratch 2を選択すれば短期間利用でも使用量課金だけで済み、POSIX準拠のランダムI/Oを高効率に処理できます。

Amazon S3をs3fsでFUSEマウントする方式やAmazon EFSのプロビジョンドスループットはメタデータ負荷や高同時アクセス時の帯域がボトルネックになりやすく、各ノードのgp3＋RAID 0は共有空間を提供しないため、ジョブ間で同一データをやり取りするHPC用途には適合しにくいです。並列分散設計のFSx for Lustreはこのような制約を回避し、規模に応じて集約スループットを直線的に拡張できます。

FSx for LustreのS3リンク機能は入力データをキャッシュしつつジョブ完了後にAmazon S3へ自動エクスポートするため、aws cliでの転送スクリプトや監視の手間が不要になり、AWS Batchによるスポットインスタンスの増減にもシームレスに追従します。性能、共有性、運用簡素化、コストを総合的に見渡すと、HPC向けマネージド並列ファイルシステムを採用する判断が最も合理的です。

ヒントボタン

四半期ごとに500台を一気に立ち上げる場合、Availability Zone 内の物理キャパシティ保証が最優先です。Auto Scaling 台数を増やすだけでは需要集中時に「キャパシティ不足」エラーが出る恐れがあります。オンデマンドキャパシティ予約を使えば、ap-northeast-1a で t3.large を事前にブロックし、起動前でも確保できます。課金はオンデマンドレートのみで、バッチ終了後に予約を削除すれば追加費用は発生しません。

Reserved Instances は Zonal を選ぶとキャパシティも押さえられますが、1 年または 3 年単位のコミットメントと前払い（または分割払い）が必須です。今回のワークロードは 48 時間のみ大量に使い、平時は Auto Scaling で 50–100 台に抑える設計なので、長期契約を結ぶと不要な支出が膨らみます。短期かつ定期的なピーク需要には、前払いを伴わず使用時間分だけ料金が発生するモデルがより適合します。

スポットインスタンスは大幅割引が魅力ですが、供給逼迫時に 2 分前通知で中断される可能性と、必要台数が揃わないリスクがあります。Service Quotas の上限引き上げも物理在庫を保証するものではありません。RTO 15 分以内・遅延不可という金融バッチの要件では、確実性・利用期間・前払い回避の三要素を同時に満たす選択肢を総合的に判断することが重要です。