Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント

2024/10/28のオンプレミス VMware 仮想環境からAWS クラウド移行の選択肢を考える～事例から学ぶ移行のアプローチ～で登壇した際の資料です。

Transcript

1. 2024/10/28 クラスメソッド株式会社 のんピ Amazon FSx for NetApp ONTAPを利⽤するに あたっての要件整理と設計のポイント
2. ⾃⼰紹介 2 • 2017年 前職(SIer)⼊社 インフラエンジニア ◦ 仮想化基盤および⾃社DCの運⽤保守 ◦ ⾦融機関のインターネット系システムの構築 • 2019年 クラウドメインの部署へ異動 ◦ 基幹システムの⼤規模AWSマイグレーション • 2021年 クラスメソッド⼊社 SA ◦ AWSコスト最適化⽀援 ◦ 1,000万PV超のECサイトリプレース⽀援 ◦ 300TBファイルサーバーの移⾏⽀援 • 部署 ◦ AWS事業本部コンサルティング部 • 名前（ニックネーム） ◦ ⼭本涼太 (のんピ) • 出⾝ ◦ 島根県 • 好きなAWSサービス ◦ Amazon FSx for NetApp ONTAP ◦ AWS Transit Gateway
3. Amazon FSx for NetApp ONTAP(FSxN)を 使ってみたい!! と思われたと確信しています 今までのセッションを聞かれて 3
4. • アーキテクチャ設計 
 • システム連携系設計 
 • ネットワーク設計
 • セキュリティ設計
 • ログ設計
 • パフォーマンス設計 
 • 可用性/信頼性設計 
 • バックアップ/リストア設 計
 • 監視設計
 • 運用設計
 • 命名規約
 では、どのようなステップで導⼊すれば良いでしょうか 4 よくあるシステム導⼊までのスケジュール 基本設計 • 各種リソース設計
 • テスト計画の策定
 詳細設計 • 各種リソースの構築 
 構築 • 要求整理
 • 非機能要件定義
 • 機能要件定義
 要件定義 • 各種リソースのテスト 
 単体テスト • 基本設計に対するテス ト
 結合テスト • 要件に対するテスト
 システムテスト
5. 要件への対応の答え合わせに 時間がかかりすぎる 従来の⼿法では 5
6. • アーキテクチャ設計 
 • システム連携系設計 
 • ネットワーク設計
 • セキュリティ設計
 • ログ設計
 • パフォーマンス設計 
 • 可用性/信頼性設計 
 • バックアップ/リストア設 計
 • 監視設計
 • 運用設計
 • 命名規約
 (再掲) 6 よくあるシステム導⼊までのスケジュール 基本設計 • 各種リソース設計
 • テスト計画の策定
 詳細設計 • 各種リソースの構築 
 構築 • 要求整理
 • 非機能要件定義
 • 機能要件定義
 要件定義 • 各種リソースのテスト 
 単体テスト • 基本設計に対するテス ト
 結合テスト • 要件に対するテスト
 システムテスト
7. FSxNはクラウドのサービスであるため 調達、作り直しが⾏いやすい FSxNのポイント 7
8. 要件定義で発⽣した必須要件やリスクについて 要件定義内で検証を⾏う そのため 8
9. 要求の洗い出しと要件の整理 9 「⾮機能要求グレード2018」と 「地⽅公共団体情報システム⾮機能要件の標準」を活⽤ • 可⽤性 • 性能‧拡張性 • 運⽤保守性 • 移⾏性 • セキュリティ • システム環境‧エコロジー ※ 全ての項⽬を活⽤する必要はない ※ オンプレミスメインの項⽬は適宜読み替えが必要
10. リスクを収集し分析する 10 課題‧懸念点 顕在化した際の影響 考えられる対応 直⾯している課題や今後発⽣ し得る懸念点をまとめる。 1 2 3 各評価軸に対する影響を整理 する。 - ⾦銭的コスト - 運⽤コスト - スケジュール - セキュリティ - パフォーマンス - 可⽤性 - その他必須要件 対応を以下観点で整理する。 - 受容や回避、軽減など アプローチの⼤⽅針 - その対応がどのように作 ⽤することを期待して いるか - 対応するにあたっての 前提条件
11. リスクの影響度と発⽣可能性を整理する 11 影響度 発⽣可能性 ⾼ • 顕在化した際に、プロジェクトの 必須要件を満たすことができない • システム全体の機能や性能に重⼤な 影響を与え、⼤規模な変更や再構築 が必要 中 • 顕在化した際に、プロジェクトの ⼗分要件を満たすことができない • ⼀部の機能や性能に影響を与える が、部分的な変更で対応可能 低 • 受容可能なものや軽微な設定変更、 ⼩コストな運⽤回避のみで対応可能 ⾼ • 確実もしくはそれに準ずる可能性で 発⽣する 中 • 特定のシナリオで発⽣する可能性が ある 低 • 考慮が必要となるケースが稀
12. リスク対応の優先度をつける 12 影響度と発⽣可能性を元に対応の 優先度をつける 右の図では以下順番に対応をする • No.4 • No.1 • No.2 • No.3
13. No 課題‧懸念点 顕在化した際の影響 考えられる対応 影響度 発⽣可能性 1 FSxNに対してプロジェクトで利用可能なアンチマルウェアの仕組み がない • ファイルサーバーを起点にマルウェアに感染する可能性がある [回避] • 貴社にてVscanに対応したアンチマルウェアソフトウェアのライ センスを契約およびVscanサーバーをご用意し、定期的なマル ウェアスキャンを行う [軽減] • FPolicyによる拡張子ベースの書き込み制御を行い、拡張子を変更 するタイプのランサムウェアの活動を防ぐ • クライアントにアンチマルウェアソフトのインストールを行い、 クライアント側で検出する方向性とする ⾼ ⾼ 2 FSxNのメンテナンスウィンドウを利用者、他システムと合意が必要 • 合意が取れない場合、意図しないダウンタイムが発生する可能性 がある [回避] • 連携システム、利用者と週次メンテナンス時刻について合意する • 各利用部門から代表者を選定し、利用時間帯についてヒアリング を行う ⾼ ⾼ 3 FSxNのONTAPバージョンが自動でアップデートされる • SnapMirrorの送信元のNetApp ONTAPのバージョンと離れすぎ る可能性がある • サポートされていないSnapMirrorとなる [回避] • 定期的にオンプレミスNetApp ONTAPのバージョンアップを実施 する • バージョンアップ時の既存環境への影響を調査する • スポットで既存ベンダーにNetApp ONTAPのバージョンアップ対 応を実施できるか依頼をする ⾼ ⾼ 4 AWSとDCとを接続する回線が現時点で存在しない • SnapMirrorの転送開始時期が遅れる [回避] • プロジェクト早期またはプロジェクト開始前にAWSとDC間の接 続方式の決定する • 現行ネットワークベンダーのサービスメニューを確認する • 決定した接続方式を実現するために必要なハードウェア、回線の 手配をプロジェクト早期に行う 中 ⾼ 5 既存のファイル共有と同じACLとなるように設定を自動化することが できない可能性がある • ファイル共有の設定コストが増大する • 自動化できない設定は「ReadのみのDeny」と「ReadとChangeの みのDeny」 • 参考 : • https://dev.classmethod.jp/articles/amazon-fsx-for-net app-ontap-migrate-multiple-file-share-settings-with-ne tapp-ontap-powershell-toolkit/ [受容] • 自動化できない設定は通常行い設定であるため、No Access とし て設定する • 自動化できない範囲については、ONTAP CLIではなく、MMCス ナップインのファイル共有一覧などから手動でを設定することが 可能 低 低 リスクを整理する 13
14. リスク対応状況の可視化 14 リスク対応をチケットで管理する • 整理時にまとめた内容 • クローズ条件 • 対応の状態 • 残課題/ネクストアクション • 現在の対応者 • 最新の優先度 • 現在の⾒込み終了⽇
15. 優先度が⾼く、早期に検証できるものは即座に検証 15
16. 検証を⾏うにあたっての注意点 16 ⽬的意識を持つ = ゴールを設定 • 何のための検証なのか • ゴール設定ができない場合 ◦ 始まらない検証 ◦ 終わらない検証 ◦ かかり続けるコスト ◦ 完了しないリスク対応
17. • アーキテクチャ設計 
 • システム連携系設計 
 • ネットワーク設計
 • セキュリティ設計
 • ログ設計
 • パフォーマンス設計 
 • 可用性/信頼性設計 
 • バックアップ/リストア設 計
 • 監視設計
 • 運用設計
 • 命名規約
 ⾒直し後のスケジュール 17 要件定義と基本設計の中でリスクを整理し、検証する中で、早期に失敗を経験し、⽅向性を整える 基本設計 • 各種リソース設計
 • テスト計画の策定
 詳細設計 • 各種リソースの構築 
 構築 • 要求整理
 • 非機能要件定義
 • 機能要件定義
 要件定義 • 各種リソースのテスト 
 単体テスト • 基本設計に対するテス ト
 結合テスト • 要件に対するテスト 
 システムテスト リスク整理 検証評価 継続して反復 検証実施
18. 設計をするときのポイント 18 • 要件とのリンク • 設計によって変動する内容と影響範囲の把握 • AWS Well-Architected Frameworkの活⽤ • 設定の上限/下限/制約事項の把握 • 後からリカバリーする際に時間のかかる設計要素の把握
19. 設計をするときのポイント 19 • 要件とのリンク • 設計によって変動する内容と影響範囲の把握 • AWS Well-Architected Frameworkの活⽤ • 設定の上限/下限/制約事項の把握 • 後からリカバリーする際に時間のかかる設計要素の把握
20. AWS Well-Architected Framework(W-A)とは 20 AWSとAWSユーザの10年以上の経験からまとめられたベストプラクティス集
21. W-Aのベストプラクティス例 21 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_protect_data_rest_key_mgmt.html
22. 設定の上限/下限/制約事項の把握 22 AWS公式ドキュメントから 各種クォータを確認 https://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/limits.html
23. 設定の上限/下限/制約事項の把握 23 数値や⽂字を⼊⼒する場合は AWS APIレベルで確認することも https://docs.aws.amazon.com/ja_jp/fsx/latest/APIReference/API_Creat eFileSystemOntapConfiguration.html
24. オンプレミスONTAPでは設定できて、FSxNでは設定できないものもある 24 SNMPやARPなどの⼀部設定は 現時点では設定不可 許可されているコマンドは `security login role show` で確認可能
25. 後からリカバリーする際に時間のかかる主な設計要素 25 • VPC • デプロイタイプ (Single-AZ or Multi-AZ) • HAペア数 • SSDサイズ • ボリュームの分割⽅針 FSxNはストレージという性質上、稼働後にゼロから作り直すのは⼿間
26. VPC 26 • VPCやサブネット、エンドポイント IP アドレス範囲はデプロイ後変更不可 • 変更する際は、再作成が必要 • 既存ボリューム内のデータを引き継ぎたい場合はSnapMirrorで実施 (要ダウンタイム)
27. SnapMirrorを活⽤してSMBサーバーを切り替える⽅法 27 1. クラスターピアリング 2. SVMピアリング 3. 転送先SMBサーバーの設定 a. SMB暗号化 b. SMBバージョン c. NASアクセスの監査ログ など d. ボリュームのデフォルト⾔語設定 4. SnapMirrorの設定 5. DNS CNAMEレコードの設定 6. 転送先ボリュームのジャンクションパスの設定 7. 転送先SMBサーバー上にSMBファイル共有の設定 8. 転送先上でのSnapshot Policyの作成 9. 転送先上でのストレージクォータの設定 10. SnapMirrorの最終同期 11. SnapMirrorのカットオーバー 12. DNS CNAMEレコードの切り替え 13. SPNの切り替え 14. 転送先ボリュームへのSnapshot Policyの適⽤
28. デプロイタイプ (Single-AZ or Multi-AZ) 28 • コスト重視ならSingle-AZ (ストレージサイズとSSD IOPSのコストが半額、スループットキャパシティのコストは約60%) • 可⽤性重視ならMulti-AZ (Single-AZ SLA 99.9%, Multi-AZ SLA 99.99%) • デプロイ後に変更は双⽅向で不可
29. HAペア数 29 • HAペアを追加することでノードとAggregateが増加し、性能の引き上げが可能 ◦ その分、コストも増加 • HAペア数の追加は可能だが、縮⼩は不可であるため徐々に増強をするべき
30. SSDサイズ 30 • SSDサイズによってSSD上に保存できるデータ量とベースラインSSD IOPSが変動 ◦ SSD IOPSはスループットキャパシティとの兼ね合い • SSDサイズの増強は可能だが、縮⼩は不可であるため徐々に増強するべき
31. SSDのサイジング 31 最低限必要なSSDのサイズ(GiB) = ボリューム1で最低限必要なSSDのサイズ((保存した いデータサイズ(GiB) / Snapshot Reserve(階層化ポリ シーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01) + ボリューム2で最低限必要なSSDのサイズ((保存した いデータサイズ(GiB) / Snapshot Reserve(階層化ポリ シーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01) + ... + ボリュームnで最低限必要なSSDのサイズ プロビジョニングするSSDのサイズ(GiB) = 最低限必要な SSDのサイズ(GiB) / (1 - 0.16) / 0.7
32. ボリュームの分割⽅針 32 • SnapMirrorで以下の操作はできない ◦ 複数ボリュームから1つのボリュームにデータを集約 ◦ 1ボリューム内の⼀部データを別ボリュームに分離 • ボリューム内のデータ移動はRobocopyやAWS DataSyncなど⾏う必要があり、転送効率が落ちるため分割⽅針は慎重に
33. FSxNのファイルシステム/SVM/ボリューム/qtreeの分割の考え⽅ 33 • ファイルシステム ◦ 物理的にリソースを分けたい、⾮機能 要件が異なる場合 • SVM ◦ ファイルサーバーとしての⽤途が異な る場合 • ボリューム ◦ 保存データの⽤途や特徴、⾮機能要件 が異なる場合 • qtree ◦ クォータをかけたいディレクトリが分 かれている場合
34. まとめ 34 • 要件定義や設計は検証をしながら進める ◦ 検証する中で、早期に失敗を経験し、⽅向性を整える • 検証はリスク分析の結果に基づいて優先順位の⾼いものから進める • 設計時は以下ポイントを意識する ◦ 要件とのリンク ◦ 設計によって変動する内容と影響範囲の把握 ◦ AWS Well-Architected Frameworkの活⽤ ◦ 設定の上限/下限/制約事項の把握 ◦ 後からリカバリーする際に時間のかかる設計要素の把握