Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
Search
のんピ
October 28, 2024
Technology
1
390
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
2024/10/28のオンプレミス VMware 仮想環境からAWS クラウド移行の選択肢を考える~事例から学ぶ移行のアプローチ~で登壇した際の資料です。
のんピ
October 28, 2024
Tweet
Share
More Decks by のんピ
See All by のんピ
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
460
VPC間の接続方法を整理してみた #自治体クラウド勉強会
non97
1
1.8k
Amazon FSx for NetApp ONTAPのパフォーマンスチューニング要素をまとめてみた #cm_odyssey #devio2024
non97
0
750
Amazon FSx for Net App ONTAPにおけるファイルシステム/SVM/ボリューム/qtreeの分割の考え方を整理してみる #storagejaws
non97
1
1.2k
オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた #自治体クラウド勉強会
non97
1
6.1k
上手く活用すればコスト削減につながる、ONTAPの Temperature Sensitive Storage Efficiency (TSSE) の紹介
non97
0
660
Amazon FSx for NetApp ONTAPへの移行方法を整理してみた
non97
0
1.6k
Amazon FSx for NetApp ONTAPは オブジェクトストレージとしても使えるんだぞ 〜ONTAP S3〜 #hibiyatech
non97
0
5k
Amazon FSx for NetApp ONTAPを 利用するときに気をつけることn選 〜移行プロセスを添えて〜 #devio2023
non97
0
1.4k
Other Decks in Technology
See All in Technology
DevinはクラウドエンジニアAIになれるのか!? 実践的なガードレール設計/devin-can-become-a-cloud-engineer-ai-practical-guardrail-design
tomoki10
3
1.3k
Tirez profit de Messenger pour améliorer votre architecture
tucksaun
1
130
LINEギフトのLINEミニアプリアクセシビリティ改善事例
lycorptech_jp
PRO
0
240
チームの性質によって変わる ADR との向き合い方と、生成 AI 時代のこれから / How to deal with ADR depends on the characteristics of the team
mh4gf
4
330
バックエンドエンジニアによるフロントエンドテスト拡充の具体的手法
kinosuke01
1
660
チームビルディング「脅威モデリング」ワークショップ
koheiyoshikawa
0
130
数百台のオンプレミスのサーバーをEKSに移行した話
yukiteraoka
0
640
ソフトウェアプロジェクトの成功率が上がらない原因-「社会価値を考える」ということ-
ytanaka5569
0
120
ClineにNext.jsのプロジェクト改善をお願いしてみた / 20250321_reacttokyo_LT
optim
1
1.3k
ソフトウェア開発におけるインターフェイスという考え方 / PHPerKaigi 2025
k1low
9
3.9k
頻繁リリース × 高品質 = 無理ゲー? いや、できます!/20250306 Shoki Hyo
shift_evolve
0
150
Vision Language Modelを活用した メルカリの類似画像レコメンドの性能改善
yadayuki
9
1.2k
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
30
1.1k
A Modern Web Designer's Workflow
chriscoyier
693
190k
GraphQLの誤解/rethinking-graphql
sonatard
70
10k
Visualization
eitanlees
146
15k
We Have a Design System, Now What?
morganepeng
51
7.5k
Adopting Sorbet at Scale
ufuk
75
9.3k
GraphQLとの向き合い方2022年版
quramy
45
14k
Facilitating Awesome Meetings
lara
53
6.3k
Designing for humans not robots
tammielis
250
25k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.4k
RailsConf 2023
tenderlove
29
1k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.7k
Transcript
2024/10/28 クラスメソッド株式会社 のんピ Amazon FSx for NetApp ONTAPを利⽤するに あたっての要件整理と設計のポイント
⾃⼰紹介 2 • 2017年 前職(SIer)⼊社 インフラエンジニア ◦ 仮想化基盤および⾃社DCの運⽤保守 ◦ ⾦融機関のインターネット系システムの構築 •
2019年 クラウドメインの部署へ異動 ◦ 基幹システムの⼤規模AWSマイグレーション • 2021年 クラスメソッド⼊社 SA ◦ AWSコスト最適化⽀援 ◦ 1,000万PV超のECサイトリプレース⽀援 ◦ 300TBファイルサーバーの移⾏⽀援 • 部署 ◦ AWS事業本部コンサルティング部 • 名前(ニックネーム) ◦ ⼭本涼太 (のんピ) • 出⾝ ◦ 島根県 • 好きなAWSサービス ◦ Amazon FSx for NetApp ONTAP ◦ AWS Transit Gateway
Amazon FSx for NetApp ONTAP(FSxN)を 使ってみたい!! と思われたと確信しています 今までのセッションを聞かれて 3
• アーキテクチャ設計 • システム連携系設計 • ネットワーク設計 • セキュリティ設計
• ログ設計 • パフォーマンス設計 • 可用性/信頼性設計 • バックアップ/リストア設 計 • 監視設計 • 運用設計 • 命名規約 では、どのようなステップで導⼊すれば良いでしょうか 4 よくあるシステム導⼊までのスケジュール 基本設計 • 各種リソース設計 • テスト計画の策定 詳細設計 • 各種リソースの構築 構築 • 要求整理 • 非機能要件定義 • 機能要件定義 要件定義 • 各種リソースのテスト 単体テスト • 基本設計に対するテス ト 結合テスト • 要件に対するテスト システムテスト
要件への対応の答え合わせに 時間がかかりすぎる 従来の⼿法では 5
• アーキテクチャ設計 • システム連携系設計 • ネットワーク設計 • セキュリティ設計
• ログ設計 • パフォーマンス設計 • 可用性/信頼性設計 • バックアップ/リストア設 計 • 監視設計 • 運用設計 • 命名規約 (再掲) 6 よくあるシステム導⼊までのスケジュール 基本設計 • 各種リソース設計 • テスト計画の策定 詳細設計 • 各種リソースの構築 構築 • 要求整理 • 非機能要件定義 • 機能要件定義 要件定義 • 各種リソースのテスト 単体テスト • 基本設計に対するテス ト 結合テスト • 要件に対するテスト システムテスト
FSxNはクラウドのサービスであるため 調達、作り直しが⾏いやすい FSxNのポイント 7
要件定義で発⽣した必須要件やリスクについて 要件定義内で検証を⾏う そのため 8
要求の洗い出しと要件の整理 9 「⾮機能要求グレード2018」と 「地⽅公共団体情報システム⾮機能要件の標準」を活⽤ • 可⽤性 • 性能‧拡張性 • 運⽤保守性
• 移⾏性 • セキュリティ • システム環境‧エコロジー ※ 全ての項⽬を活⽤する必要はない ※ オンプレミスメインの項⽬は適宜読み替えが必要
リスクを収集し分析する 10 課題‧懸念点 顕在化した際の影響 考えられる対応 直⾯している課題や今後発⽣ し得る懸念点をまとめる。 1 2 3
各評価軸に対する影響を整理 する。 - ⾦銭的コスト - 運⽤コスト - スケジュール - セキュリティ - パフォーマンス - 可⽤性 - その他必須要件 対応を以下観点で整理する。 - 受容や回避、軽減など アプローチの⼤⽅針 - その対応がどのように作 ⽤することを期待して いるか - 対応するにあたっての 前提条件
リスクの影響度と発⽣可能性を整理する 11 影響度 発⽣可能性 ⾼ • 顕在化した際に、プロジェクトの 必須要件を満たすことができない • システム全体の機能や性能に重⼤な
影響を与え、⼤規模な変更や再構築 が必要 中 • 顕在化した際に、プロジェクトの ⼗分要件を満たすことができない • ⼀部の機能や性能に影響を与える が、部分的な変更で対応可能 低 • 受容可能なものや軽微な設定変更、 ⼩コストな運⽤回避のみで対応可能 ⾼ • 確実もしくはそれに準ずる可能性で 発⽣する 中 • 特定のシナリオで発⽣する可能性が ある 低 • 考慮が必要となるケースが稀
リスク対応の優先度をつける 12 影響度と発⽣可能性を元に対応の 優先度をつける 右の図では以下順番に対応をする • No.4 • No.1 •
No.2 • No.3
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 リスク対応をチケットで管理する • 整理時にまとめた内容 • クローズ条件 • 対応の状態 •
残課題/ネクストアクション • 現在の対応者 • 最新の優先度 • 現在の⾒込み終了⽇
優先度が⾼く、早期に検証できるものは即座に検証 15
検証を⾏うにあたっての注意点 16 ⽬的意識を持つ = ゴールを設定 • 何のための検証なのか • ゴール設定ができない場合 ◦
始まらない検証 ◦ 終わらない検証 ◦ かかり続けるコスト ◦ 完了しないリスク対応
• アーキテクチャ設計 • システム連携系設計 • ネットワーク設計 • セキュリティ設計
• ログ設計 • パフォーマンス設計 • 可用性/信頼性設計 • バックアップ/リストア設 計 • 監視設計 • 運用設計 • 命名規約 ⾒直し後のスケジュール 17 要件定義と基本設計の中でリスクを整理し、検証する中で、早期に失敗を経験し、⽅向性を整える 基本設計 • 各種リソース設計 • テスト計画の策定 詳細設計 • 各種リソースの構築 構築 • 要求整理 • 非機能要件定義 • 機能要件定義 要件定義 • 各種リソースのテスト 単体テスト • 基本設計に対するテス ト 結合テスト • 要件に対するテスト システムテスト リスク整理 検証評価 継続して反復 検証実施
設計をするときのポイント 18 • 要件とのリンク • 設計によって変動する内容と影響範囲の把握 • AWS Well-Architected Frameworkの活⽤
• 設定の上限/下限/制約事項の把握 • 後からリカバリーする際に時間のかかる設計要素の把握
設計をするときのポイント 19 • 要件とのリンク • 設計によって変動する内容と影響範囲の把握 • AWS Well-Architected Frameworkの活⽤
• 設定の上限/下限/制約事項の把握 • 後からリカバリーする際に時間のかかる設計要素の把握
AWS Well-Architected Framework(W-A)とは 20 AWSとAWSユーザの10年以上の経験からまとめられたベストプラクティス集
W-Aのベストプラクティス例 21 https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_protect_data_rest_key_mgmt.html
設定の上限/下限/制約事項の把握 22 AWS公式ドキュメントから 各種クォータを確認 https://docs.aws.amazon.com/ja_jp/fsx/latest/ONTAPGuide/limits.html
設定の上限/下限/制約事項の把握 23 数値や⽂字を⼊⼒する場合は AWS APIレベルで確認することも https://docs.aws.amazon.com/ja_jp/fsx/latest/APIReference/API_Creat eFileSystemOntapConfiguration.html
オンプレミスONTAPでは設定できて、FSxNでは設定できないものもある 24 SNMPやARPなどの⼀部設定は 現時点では設定不可 許可されているコマンドは `security login role show` で確認可能
後からリカバリーする際に時間のかかる主な設計要素 25 • VPC • デプロイタイプ (Single-AZ or Multi-AZ) •
HAペア数 • SSDサイズ • ボリュームの分割⽅針 FSxNはストレージという性質上、稼働後にゼロから作り直すのは⼿間
VPC 26 • VPCやサブネット、エンドポイント IP アドレス範囲はデプロイ後変更不可 • 変更する際は、再作成が必要 • 既存ボリューム内のデータを引き継ぎたい場合はSnapMirrorで実施
(要ダウンタイム)
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の適⽤
デプロイタイプ (Single-AZ or Multi-AZ) 28 • コスト重視ならSingle-AZ (ストレージサイズとSSD IOPSのコストが半額、スループットキャパシティのコストは約60%) •
可⽤性重視ならMulti-AZ (Single-AZ SLA 99.9%, Multi-AZ SLA 99.99%) • デプロイ後に変更は双⽅向で不可
HAペア数 29 • HAペアを追加することでノードとAggregateが増加し、性能の引き上げが可能 ◦ その分、コストも増加 • HAペア数の追加は可能だが、縮⼩は不可であるため徐々に増強をするべき
SSDサイズ 30 • SSDサイズによってSSD上に保存できるデータ量とベースラインSSD IOPSが変動 ◦ SSD IOPSはスループットキャパシティとの兼ね合い • SSDサイズの増強は可能だが、縮⼩は不可であるため徐々に増強するべき
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 • SnapMirrorで以下の操作はできない ◦ 複数ボリュームから1つのボリュームにデータを集約 ◦ 1ボリューム内の⼀部データを別ボリュームに分離 • ボリューム内のデータ移動はRobocopyやAWS
DataSyncなど⾏う必要があり、転送効率が落ちるため分割⽅針は慎重に
FSxNのファイルシステム/SVM/ボリューム/qtreeの分割の考え⽅ 33 • ファイルシステム ◦ 物理的にリソースを分けたい、⾮機能 要件が異なる場合 • SVM ◦
ファイルサーバーとしての⽤途が異な る場合 • ボリューム ◦ 保存データの⽤途や特徴、⾮機能要件 が異なる場合 • qtree ◦ クォータをかけたいディレクトリが分 かれている場合
まとめ 34 • 要件定義や設計は検証をしながら進める ◦ 検証する中で、早期に失敗を経験し、⽅向性を整える • 検証はリスク分析の結果に基づいて優先順位の⾼いものから進める • 設計時は以下ポイントを意識する
◦ 要件とのリンク ◦ 設計によって変動する内容と影響範囲の把握 ◦ AWS Well-Architected Frameworkの活⽤ ◦ 設定の上限/下限/制約事項の把握 ◦ 後からリカバリーする際に時間のかかる設計要素の把握
None