要件定義をするときに意識していることをまとめてみた ~要件定義を例を添えて~
2025.07.28要件定義で意識していることを言語化したくなった
こんにちは、のんピ(@non____97)です。
皆さんは要件定義で意識していることを言語化したくなったことはありますか? 私はあります。
いくつかのプロジェクトで要件定義をしてきましたが、改めて考えると、普段は感覚でやっている箇所も多くあったなと感じています。
そこで、改めて言語化することで、プロジェクトごとのブレを抑えたり、さらにどういった対応が必要なのかが整理できる予感がしてきました。
ということで、以降、要件定義で意識していることと要件の例を紹介します。
なお、「要件定義とは」や「要件定義の進め方」は語りません。書籍やインターネット上に先人たちが大量にアウトプットしてくださっているため、そちらを参照ください。
特にIPAが公開している「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」や「システム再構築を成功に導くユーザガイド 第2版〜ユーザとベンダで共有する再構築のリスクと対策〜」、「超上流から攻めるIT化の事例集：要件定義」は非常に参考になります。
AWSにおいては、AWS Well-Architected フレームワークの各柱やAWS Well-Architected レンズを確認すると良いでしょう。
要件をヒアリングする際には以下記事を参考にすることも多くあります。
要件定義で意識していること
プロジェクトの目的とゴールを設定する
まずはプロジェクトの目的とゴールの設定をし、プロジェクト関係者と合意をしましょう。
要件定義をしている間、無限に要求が出てくる時があります。最初は「ついでに」だった要求が「絶対に満たせないとダメ」といった強い要求に変わってくることがあります。特に関係者が多い場合、それぞれの立場の意見があるため、整合性のとれていない要求が上がってくることもあります。
このような時にプロジェクトの目的とゴールの設定が適切になされていると、無闇なスコープの拡大を防ぐことができます。それぞれの要件についてプロジェクトのゴールとリンクしているのかを精査して、それを要件として扱うのはを判断していきます。
また、大量の細かい要件を詰めていると、つい方向性がブレてしまいます。大方針としてのゴールを設定し、そこを軸とすれば迷子になるリスクを軽減できます。
目的とゴールの設定は理想や、プロジェクトを開始するきっかけとなった出来事や課題、理想とのギャップについてを会話すると、方向性が定まりやすいと感じています。
目的とゴール設定の必要性は以下記事の「プロジェクトの背景と目的、想定している手段」もご覧いただくと良いかなと思います。
プロジェクトとして対応が必要なことを決める
要件定義では プロジェクトとして対応が必要なこと を定めます。
よく、Why と What を意識するようにと言われることもあるのではないでしょうか。一足飛びに方法論に固執すると、本当に何をしたかったのかが分からなくなってしまいます。まず、要望や要求をヒアリングし、「何を」「何故」やるのかをしっかり合意しましょう。
ここでポイントなのは「要望や要求がある = そのプロジェクトの要件となる」ではない点です。
出てきた要求が必ずしも正解とは限りません。場合によっては方向性がズレていることもあるでしょう。設定したゴールを元に、本当にそれは要件として扱う必要があるのかということを丁寧に検討しましょう。
また、並列で複数プロジェクトが走っている場合や、既存のシステムとの連携を行う場合は、自身のプロジェクトの成果物の責務がどこまでなのかが分かるように明記をしましょう。併せて、他プロジェクトに求める要件を記載するのも良いでしょう。早めに文書化をしておいて、お互いの認識のズレを早めに発見しておきたいです。
私はタマゴケさん(@s5ml)の以下図が好きです。
やることだけではなく、やらないことも決める
やることだけはなく、やらないことも決めましょう。
プロジェクトが進むと、要件として明記していなかったについて「当然やると思っていた」や「追加で対応して欲しい」とリクエストをもらうことがあります。
追加要件として扱うスケジュールやコスト、体制、影響度合いといったプロジェクトとしての余力があるのであれば、対応することも検討はできますが、難しい場面もあるでしょう。
そのような場面に備えて、あらかじめ対応する予定のないものは「対応をしない」と明記すると良いでしょう。
これは前職の上司によく言われました。今だに覚えています。感謝です。
やらないことのリストアップは生成AIが大活躍する領域です。どんどん活用しましょう。
要求として出てきていない = やらなくても良い ではない
「要求として出てきていない = やらなくても良い」ではありません。
むしろ、細かいシステム要件や考慮事項が出てくることは稀でしょう。
「一般的にはこのような要件がある」などと、色々とヒアリングをして要件を引き出しましょう。エンジニアとしての腕の見せ所だと思います。
私はタマゴケさん(@s5ml)の以下図が好きです。
実現しようとしていることがどのようにビジネスに影響するのかを把握する
プロジェクトのゴールを設定すると関連していますが、実現しようとしていることがどのようにビジネスに影響するのかを把握しておきましょう。
どのようにビジネスに影響をしているのかを意識しながら要件を詰めることによって、過大/過小な要件な要件となる可能性を抑えることができると考えています。
過大/過小な要件ではプロジェクトは失敗します。
要件の量と深さは、プロジェクトの規模や顧客特性、重要度を加味した上で、認識齟齬が発生するリスクが最小限となる程度にする
要件定義を進めると無限に要件が増えていくことがあります。
以下で紹介されているとおり、網羅的な要件を出すことは出来ません。
要件定義プロセスは全体にアイデア創出の連続であり、どこまでいっても検討に終わりが見出せないが、時間や労力には限りがあるため、どこかで検討を打ち切り、そこまでに検討した内容に基づいて成果物を作成せざるを得ないという特性を持つ。
時間とコストには限りがあります。
そのため、個人的には要件の量と深さは「プロジェクトの規模や顧客特性、重要度を加味した上で、認識齟齬が発生するリスクが最小限となる程度にする」必要があると考えています。
以降紹介する要件例を元に項目埋めるだけなのは適切な要件定義とは言えません。プロジェクトによって適切な要件の量と深さは全く異なります。
信頼関係や普段のコミュニケーション量も重要になってくるでしょう。
要件を引き出す際には具体例を出し、それを抽象化するサイクルを繰り返すのも良いでしょう。あまりにも具体的な要件やHowに固執した要件では柔軟性がなくなってしまいます。
決定しなければならない要件ごとの優先順位を付ける
大量の要件がある中で全て要求順に対応をして行ってはキリがありません。本当に重要な要件の検討に割く時間がなくなってしまうことがあります。
全体構成やプロジェクトのゴールに直結する要素、実装コストに影響が高いものからヒアリングしましょう。
ログの保持期間が1年から1年半になっても、それが大きな影響を与えることは少ないでしょう。
要求を満たせない場合の影響度合いを確認する
要求によって温度感は全く違う事があります。「その要求を満たせないとシステムローンチできないレベルのものかどうか」など、要求を満たせない場合の影響度合いを確認します。
QCDSの中で調整をすることになります。
例えば、プロジェクトの期間を延長したり、今回のプロジェクトのスコープから切り出して今後の機能追加でも問題ないとすることもあるでしょう。
関連して、要件達成の可能性が低い場合やリスクが高い場合は、その旨を申し送り事項に記載しましょう。
全ては実装コスト、ランニングコスト、スケジュールのトレードオフであることの意識を持つ
QCDのどれを重視するかという話です。
手当たりに要求を全て要件として合意をしていくと、プロジェクト開始時の想定よりも遥かにスケジュールや対応工数、ランニングコストが増えてしまっている事があります。
一つ一つの要件に対して、全ては実装コスト、ランニングコスト、スケジュールのトレードオフであることの意識を持ち、現実的な落とし所を探る必要があります。夢ばかりを描いても幸せになりません。
会話をする際は、コスト影響を簡単にでも良いので説明できると良いと考えます。
対応として、工数やスケジュールの捻出のために、他要件のレベルを落としたり、プロジェクトの対応スコープを狭めたりといった対応をとることがあります。
現物を触って認識合わせする
なかなか要件が定まらない時には現物を触って認識合わせするのも良いでしょう。
特に、使い勝手は触るのが一番です。そのフィードバックを要件として言語化しましょう。
一方で、現物を触るとHowに固執してしまうため、要件とする際には「そのHowはどのような目的で、何を成しているか」と分解して上手く抽象化する必要があります。
妄想を働かせる
「特殊な運用や、現在のお使いの製品独自の機能を使っているものはありますか?」
とオープンなヒアリングをしても、回答が出てこないことが多いです。
妄想を叩かせて、例をいくつか出して相手の脳を整理させましょう。
妄想の壁打ち相手で生成系AIを使うのも手です。
要件ヒアリング時にはその質問の意図と、回答内容の扱われ方を明確にする
質問の意図が相手に伝わらないとコミュニケーションロスが大きくなります。スケジュール的にメンタル的にもよろしくありません。
要件をヒアリングする際には意図と、ヒアリングの内容がどのようなアウトプットになるのかを提示をしましょう。
こうすることで、さらなる要求を引き出すこともできます。
実際の例として、こちらの記事で以下のように紹介しています。
## 目的
- 大規模障害の発生した場合の復旧までの目標に関わる要件を整理する
## 実施事項
- [ ] DR時のRPOについて合意する
- [ ] DR時のRTOについて合意する
- [ ] DR時のRLOについて合意する
## 詳細
### DR時のRPO（目標復旧地点）
以前ご共有いただいた参考情報(1) A.1.1 には以下のように記載がございました。
- インシデント発生の1日以内のデータを用いて業務を復旧したい
#### ご回答依頼
以下についてご回答をお願いいたします。
- DR時のRPO
ご回答例)
- DR時のRPO :
- 目標は原則24時間以内
- ただし、バックアップジョブ開始から完了までの時間、およびバックアップデータのDRサイトへの転送時間を考慮して最大48時間まで許容する
いただいた情報をもとにバックアップの取得間隔を決定いたします。
#### 要件イメージ
ご回答依頼にてご回答いただいた内容を元に、要件として以下でまとめることを考えております。
- DR時のRPOは<ご回答いただいた内容を記載>
- DR時のRPOの補足条件として以下がある
- <ご回答いただいた内容を記載>
要件のイメージ、フォーマットについて改善したい点や不明点がございましたら、お教えください。
### DR時のRTO（目標復旧時間）
以前ご共有いただいた参考情報(1) A.1.2 には以下のように記載がございました。
- 該当システムの業務的な優先度は高い
- インシデント発生後2日以内に行いたい
- ただし、人命最優先
#### ご回答依頼
以下についてご回答をお願いいたします。
- DR時のRTO
ご回答例)
- DR時のRTO : 48時間
いただいた情報をもとにActive/StandbyなどDRサイトの実装方法やDRオペレーションのフローを検討いたします。
#### 要件イメージ
ご回答依頼にてご回答いただいた内容を元に、要件として以下でまとめることを考えております。
- DR時のRTOは<ご回答いただいた内容を記載>とする
- RTOの基準はインシデントが発生したタイミングとする
- 意思決定者および切り替え担当者を複数セット定義する
- 人命を最優先とし、天災を起因とする障害によってはインシデント発生時に、DR発動判断の判断者および、DR切り替え担当者への連絡が取れない可能性があることを考慮する
- DR発動時はDRサイトにフェイルオーバーし業務を継続する
- DRサイトは単なるデータ退避場所ではない
要件のイメージ、フォーマットについて改善したい点や不明点がございましたら、お教えください。
### DR時のRLO（目標復旧レベル）
以前ご共有いただいた参考情報(1)には関連する記載はございませんでした。
#### 要件イメージ
今までのお打ち合わせの内容を踏まえて、要件として以下でまとめることを考えております。
- DR時のRLOは以下とする
- DR対象としている全てのデータが復旧している
- プライマリサイトと同じSMBファイル共有がDRサイト上でも作成されている
- Active Directoryを用いた認証によるNASアクセスができる
- クライアントが接続先のドメイン名を変更しなくともNASアクセスができる
- DRサイトでは以下の処理を行わない
- アンチマルウェアソフト連携機能の利用
- アーカイブストレージへの自動連携
- 管理アクティビティ監査ログのログ集約
- DRサイト上で実行しない上述の処理はプライマリサイト復旧後に再開する
- (申し送り事項 : それぞれの具体的な実装方法は基本設計フェーズで検討する)
- DR時の前提として以下状態となっていることとする
- AD DCが本プロジェクトの範囲外でマルチリージョンで構築されている状態
- Direct Connect等でオンプレミスとAWSネットワークの疎通が取れている状態
- Transit GatewayによってVPC間、オンプレミスネットワーク間の疎通が取れている状態
要件のイメージ、フォーマットについて改善したい点や不明点がございましたら、お教えください。
## アウトプット
- 要件定義書
## 参考情報
(1) 非機能要求一覧.xlsx
実現性が薄い要素を回答によってはできるかのようにヒアリングしない
実現性が薄い要素を回答によってはできるかのようにヒアリングしないように注意しましょう。
「回答したのがからプロジェクトの要件として扱われるんですよね?」という形になりがちです。もし、後から対応ができないことが判明するとガッカリしてしまいます。
期待値調整として、現実的な回答案の例示や回答内容のQCDへの影響度合いを一緒に添えると良いでしょう。
対応主体を決める
要件定義の中で要件を合意していくと、徐々にプロジェクトのスコープが形作られていきます。
そこでつい棚に上がりがちなのが、その要件の対応主体が誰なのかです。
「要件を出したから後よろしく」ではありません。誰もやるつもりがない要件が出来上がっても、絵に描いた餅です。
責任分界点として対応主体が誰なのかを合意しましょう。
可能な限り要件を満たしていることを定量的に評価可能な記載にする
要件を元に、設計→構築→テストと進めていき、テストのタイミングで要件を満たしているのか確認することとなります。
要件定義で計測、評価しづらいと、何を持って問題ない = 要件を満たしているのかと判断が付かず、テストが非常に行いづらいです。自分で自分の首を絞める形になります。
可能な限り要件を満たしていることを定量的に評価可能な記載にしましょう。
仮決めや暫定対応は、いつ本決定が行われるのか、決定の決め手となる要素とネクストアクション、暫定対応から変わってしまった場合の影響、誰がボール持っているのかを整理する
要件定義の中で決めきれないものも出てきます。
そういった場合は仮決めをしたり、暫定対応をしたりします。
しかし、ついその場の対応がそのままズルズルと引き伸ばされ、プロジェクト終盤になって問題が発覚するのはあるあるだと思います。
仮決めや暫定対応は以下のような観点で整理をしておきましょう。
- いつ本決定が行われるのか
- 本決定ができない理由、背景
- 決定の決め手となる要素
- 決定をするにあたって誰がボール持っているのか
- ネクストアクション
- 暫定対応から変わってしまった場合の影響
また、整理した結果は文書の中で埋もれさせるのではなく、チケットとしてオープンにして、定期的に棚卸しをしましょう。
要件の補足説明や、背景やその意思決定に至った流れを記載する
要件を整理する過程でヒアリングした背景についても整理しましょう。
他設計や現物から要件を推測することは可能ですが、それに至った経緯を完全に把握することは不可能に近いです。
GitHubのIssueやBacklogのチケットでやり取りしている場合は、そこに要約した背景をまとめておきましょう。今では生成系AIにチケットのやり取りを要約させることで、目的や背景を簡単に整理することも可能でしょう。
そのためにも一つのチケットでは一つの要件について議論した方が良いと思います。
問題や気づきを先送りにしない
要件定義の終わりがけに「今更確認するのも」という場面に遭遇します。
例えば要件を一覧化して、眺めている中で決めが甘いものを発見する時があります。
このような場面では先送りにせず、正直にプロジェクトとしてエスカレーションや打ち合わせの議題に上げましょう。
問題を先送りにして、上手く行った試しは私はありません。
早めにプロジェクト全体のタスクとしてテーブルに上げて検討した方が事故が減ります。
現行踏襲という単語を使わない
「現行踏襲」という単語はみなさん好きですか?私は好きではありません。
要求を出す立場からすると、「現行踏襲」という単語は非常に労力が低くお手軽な魔法の言葉です。
しかし、以下記事で紹介されているとおり、要件を「現行踏襲で」という形にしてしまうと、高い確率でトラブルになりえます。
特にリプレースで、今までの運用、SIベンダーと別のベンダーが主体となってプロジェクトを推進する場合、情報は非対称です。要件の抜け漏れはもちろん、実装の調査に非常に時間がかかったり、古いシステムの問題点や非効率な部分もそのまま引き継いでしまったりすることもあります。私は基幹システム移行案件でトラウマがあります。
結局、形作る過程で現行踏襲では立ち行かなくなります。具体的な要件を出す労力を厭わず、関係者を巻き込んで要件を整理しましょう。
使用する予定のサービスのクォータを把握する
要件定義をする中でシステムのアーキテクチャや使用するサービスがある程度固まってくることがあるでしょう。
そのサービスを使用する前提でプロジェクトが進み、最後のテストのタイミングでサービスクォータに抵触してしまうと目も当てられません。
特に触ったことがあるサービスであっても、プロジェクトの規模感が違うとサービスクォータに抵触してしまったり、そのサービスのパフォーマンスの限界値に達してしまうことがあります。
一度、使用する予定のサービスのクォータを確認して、フィジビリティを取っておきましょう。不安であれば、実際にPoCで裏どりするのも良いと思います。
要件例の前提
以降、ファイルサーバー移行時の要件の例と共に各要件のポイントを紹介します。
要件例の前提は以下のとおりです。
- オンプレミスおよび、オンプレミスネットワークについては本要件定義外とする
- 大まかな役割分担についてはプロジェクト計画書で合意済み
- ファイルサーバー移行の機能要件と非機能要件について記載
- 規模は中規模程度
- ガッチリしたワークロードではない
- 目的や背景についての言及は省略
- 以下は含んでいない
- 詳細な通信要件
- 運用メンバーや利用者への教育、運用引き継ぎ
- サービスデスク、運用体制
- 役割分担
実際には不足している項目もあると思います。
必要に応じて以下のようなの要件が出てくる時もあると思います。
- DNS
- NTP
- メール配送
- ジョブ管理
- メトリクスやログ分析基盤、運用ダッシュボード
- 国内にのみ保存する必要があるデータ
- DR訓練
また、ファイルサーバー以外ではアプリケーションのデプロイについて検討する必要があるでしょう。
可用性
稼働率
求められる稼働率を定義します。
稼働率は以下のように求めます。
- 稼働率 = 稼働時間 / 負荷時間
- 負荷時間 = 運用時間 – 計画停止時間
- 稼働時間 = 負荷時間 – 計画外の停止時間
この稼働率を下回らないような設計にする必要があります。
無理をすると大変です。停止時のビジネスインパクト等のシステムの重要度に応じて設定しましょう。
要件例としては以下のとおりです。
- 求める稼働率は月99.9%とする
- 稼働率計算には以下シチュエーションによる停止を含まない
- 運用時間外での停止
- 計画停止
- 大規模災害等のリージョンレベルでの停止
例に挙げたとおり、「大規模災害等のリージョンレベルでの停止」は計画外停止であっても例外として稼働率計算に含めないことがあります。
また、各種AWSサービスが提供しているSLAについても参考情報としてまとめておくと良いでしょう。
- FSxN : Multi-AZの場合は99.99% (Amazon FSxサービスレベルアグリーメント)
- EC2 : Single-AZの場合は99.5%、Multi-AZの場合は99.99% (Compute Service Level Agreement)
- Direct Connect : 複数ロケーションの場合は99.99% (AWS Direct Connectサービスレベルアグ リーメント)
2023年3月8日時点と少し古いですが、AWSの各サービスのSLAは以下記事にまとまっています。
場合によってはAWSサービスのSLAをそのまま稼働率とすることもあります。
なお、AWSのSLAは「SLAで定義した時間以上必ず停止しない」という保証ではありません。要注意です。SLAを満たさない場合は利用費に応じたサービスクレジットが返還されるだけで、仮にサービス停止が長期化しても、その期間発生したビジネス上の損失分の金額を補填する訳ではありません。
稼働率についてのあくまで目安、と捉えると良いでしょう。
稼働率計算対象範囲
稼働率計算対象範囲を定めます。
稼働率を計算と元となるコアとなる要素、業務を指すと良いでしょう。
その際は、要件を満たせていることを証明するためにも計測可能なものがオススメです。「全部計測する」としても、「全部ってどうやって計測する？」、「そもそも全部とはいえ、どこまでの範囲？」となり、後で具体的にアクションを起こすことが難しいです。
業務遂行に必須ではないものは必須でないもの、重要度の低いものについては範囲外にしてしまうと良いでしょう。特にマネージドサービスの仕様の関係で稼働率をコントロールする術を持たないものについて厳しめの稼働率で合意してしまうと、後々苦しむことになります。個人的には無理にカスタマイズするよりも、「あるものを使う」、「業務をシステムに合わせる」形で行きたいです。(それが難しい場面が多数あることも重々承知しています)
要件例としては以下のとおりです。
- 稼働率計算対象範囲は以下のとおり
- ファイルサーバーへのSMBアクセス
- Active Directoryを用いた認証
- オンプレミス拠点からファイルサーバーへのネットワーク接続
- 上述に記載されていない以下のような項目については範囲外
- バックアップ処理
- Snapshot、SnapMirrorを含む
- アンチマルウェアソフトサーバーと連携したマルウェアスキャン
- ファイル管理システム用サーバーからのACLの割り当て
- ファイル管理システム用サーバーからのスキャン処理
- NASアクセスログ、監査ログ等の各種ログ出力
- CloudWatchメトリクスへのメトリクスのPUT
- バックアップ処理
こちらの要件例であれば、「拠点からDirect Connectを通ってファイルサーバーへ1分間隔でSMBによるファイルのRead/Write/Deleteを実施する」といった外形監視を実装し、その結果を持って計算をすれば良いでしょう。
業務継続が最優先されるべきであるため、例ではバックアップやログ出力については稼働率計算の範囲外にしています。
単一ノード障害や一部AZの障害等のリージョン内の一部データプレーン障害時のRTO/RPO/RLO
RTO/RPO/RLOを定めます。
RTO/RPO/RLO自体の説明や、定める際のポイントは以下記事の「障害シナリオごとのRTO/RPO/RLOと前提、優先度の定義」の章をご覧ください。
あわせて上述の記事の以下項目もチェックして、現実的な落とし所を探りましょう。
- リストアやDR発動の基準の定義
- リストアやDR時のビジネス上の影響整理
- リストアやDR発動の意思決定、連絡フローの定義
- DR環境で業務継続するための必要要素の整理
要件の例は以下のとおりです。
- 単一ノード障害や一部AZの障害等のリージョン内の一部データプレーン障害時のRTO/RPO/RLOは以下のとおり
- RTO : 1時間
- RPO : 10分
- RLO :
- ファイルサーバーのrootボリュームを除く全ボリュームがRPOで定めた地点に復旧
- Active Directoryで認証を行い、オンプレミス拠点およびVPCからファイルサーバーへSMBでアクセスできる
- 以下項目は定めたRTO以内の復旧は行わず、順次対応を行う
- バックアップ処理の再開
- Snapshot、SnapMirrorを含む
- アンチマルウェアソフトサーバーと連携したマルウェアスキャン
- ファイル管理システム用サーバーからのACLの割り当て
- ファイル管理システム用サーバーからのスキャン処理
- NASアクセスログ、監査ログ等の各種ログ出力
- バックアップ処理の再開
- RTO/RPO/RLOの前提は以下のとおり
- RTO/RPO/RLOは目標であり、保証するものではない
- RTOの基準は運用者が障害の認知や、復旧時の作業を開始したタイミングではなく、障害によりサービスが停止が発生したタイミングとする
- データプレーンのみではなく、特定リージョン全体のコントロールプレーンも動作していないこととする
- ここでいう一部データプレーン障害にはDirect Connectの単一VIF、単一Connectionの障害を含める
- Direct Connectに使用しているWANや各接続拠点自身および、WANまでの回線の障害は考慮しないものとする
- データ量およびファイル数は本要件定義で定めた上限に収まっていること
- 求める整合性はクラッシュ整合性までとし、ファイルシステム整合性やアプリケーション整合性は求めない
- ボリューム内に保持しているSnapshotはロストすることを許容する
- SMBアクセス時のスループットの劣化は平常時の50%まで許容する
- ユーザーは障害発生後で同一の名前で接続できることとする
前提には以下のような要素を記載しています。
- RTO/RPO/RLOの建て付け
- RTOの起点となる事象
- 発生している障害のシチュエーション
- 考慮しない障害のシチュエーション
- 要件の前提となるシステムやデータの状態
- 復旧しない、できないデータ
- 縮退運転の有無と許容範囲
規模が大きくなると、ステークホルダーも多くなる傾向があります。そういった時に「書かれていないけど、常識的に考えてこうなると思っていたのに」と後工程でトラブルになると、リカバリーに非常に時間とコストがかかります。設計モレを少なくするためにもなるべく丁寧に決めましょう。
また、今回の例では「一部データプレーンに対して障害発生した場合」などと障害の種類と範囲で分類していますが、ひとまとめにすることもあります。むしろ体感そちらの方が多いです。そもそも、小規模で重要度もそこまで高くないシステムの場合はここまで記載しないことがほとんどです。
特定リージョン全体のデータプレーン障害時のRTO/RPO/RLO
特定リージョン全体のデータプレーン障害時のRTO/RPO/RLOも同様に決めます。
いわゆるリージョン障害に対する要件です。
過去に発生したAWSの大規模な障害は以下ページにまとめられています。
過去リージョン全体がダウンするような事象は2025/6/14時点では発生していないようです。
影響時間については過去実績では最大で17時間程度でした。リージョン障害のDRとして別リージョンにフェイルオーバーすることがよく挙げられますが、復旧を待った方が早かったという場面もあるかと思います。
とはいえ、障害によって毎回リソースが自然復旧してくれるとは限りません。データが物理的、論理的に破損してしまい、障害発生リージョンではすぐさまに復旧できないこともあるでしょう。
障害シナリオ、ビジネス影響、業務の優先度、RTO、コスト、スケジュールを加味しながら決定しましょう。
特に、RTOはサービス停止が発生してから、リカバリー作業の判断と実施開始までのリードタイムも含めると良いでしょう。理由は以下のとおりです。
- 障害範囲が一部なのか、リージョン全域なのかといった障害の範囲と程度を即座に判断することは難しいため
- 天災による大障害規模の場合は、DR発動判断の判断者および、DR切り替え担当者への連絡が取れない可能性があるため
- 他にリカバリーを優先するべき業務に人手が取られる可能性があるため
他、以下記事の以下項目をチェックしながら落としどこを探ります。
- 障害シナリオごとのRTO/RPO/RLOと前提、優先度の定義
- リストアやDR発動の基準の定義
- リストアやDR時のビジネス上の影響整理
- リストアやDR発動の意思決定、連絡フローの定義
- DR環境で業務継続するための必要要素の整理
要件の例は以下のとおりです。
- 特定リージョン全体のデータプレーン障害時のRTO/RPO/RLOは以下のとおり
- RTO : 48時間 (リカバリー処理開始からは12時間での復旧を目標)
- RPO : 72時間
- RLO :
- ファイルサーバーのrootボリュームと監査ログ用を除く全ボリュームがRPOで定めた地点に復旧
- Active Directoryで認証を行い、オンプレミス拠点およびVPCからファイルサーバーへSMBでアクセスできる
- 以下のような項目は定めたRTO以内の復旧は行わず、順次対応を行う
- バックアップ処理の再開
- Snapshot、SnapMirrorを含む
- NASアクセスログ、監査ログ等の各種ログ出力
- バックアップ処理の再開
- RTO/RPO/RLOの前提は以下のとおり
- RTO/RPO/RLOは目標であり、保証するものではない
- RTOの基準は運用者が障害の認知や、復旧時の作業を開始したタイミングではなく、障害によりサービスが停止が発生したタイミングとする
- データプレーンのみではなく、特定リージョン全体のコントロールプレーンも動作していないこととする
- ここでいうデータプレーン障害にはDirect Connectの単一VIF、単一Connectionの障害を含める
- Direct Connectに使用しているWANや各接続拠点自身および、WANまでの回線の障害は考慮しないものとする
- 複数リージョンの多重障害は考慮しない
- データ量およびファイル数は本要件定義で定めた上限に収まっていること
- 求める整合性はクラッシュ整合性までとし、ファイルシステム整合性やアプリケーション整合性は求めない
- ボリューム内に保持しているSnapshotはロストすることを許容する
- SMBアクセス時のスループットの劣化は平常時の70%まで許容する
- ユーザーは障害発生後で同一の名前で接続できることとする
- フェイルオーバー先であるDRサイトでの障害の考慮は不要とする
マルウェア感染によるサービス停止発生時のRTO/RPO/RLO
マルウェア感染によるサービス停止発生時のRTO/RPO/RLOも定義しておきましょう。
要求事項として、マルウェア感染に対するリカバリーがある場合に策定することがあります。
リカバリーの過程で別サイトにフェイルオーバーさせたり、一から作り直すことがあります。RTOはリカバリー方法をある程度意識して設定しましょう。
RPOについてはいつ感染したのか次第で戻すべきポイントが変わるので、ここでは具体的な時間についての言及はできません。仮にRPOを24時間と定義していても、24時間前のタイミングで既に感染していたら意味がないです。どの間隔で、どの時間まで状態を戻せるかについてはここではなく、バックアップ要件として確認します。
要件の例は以下のとおりです。
- マルウェア感染によるサービス停止発生時のRTO/RPO/RLOは以下のとおり
- RTO : 48時間
- RPO : 感染前もしくは感染したファイルが含まれない最新のバックアップ、もしくはSnapshot
- RLO :
- ファイルサーバーのrootボリュームを除く全ボリュームがインシデント発生前の状態に復旧
- Active Directoryで認証を行い、オンプレミス拠点およびVPCからファイルサーバーへSMBでアクセスできる
- 以下のような項目は定めたRTO以内の復旧は行わず、順次対応を行う
- バックアップ処理の再開
- Snapshot、SnapMirrorを含む
- NASアクセスログ、監査ログ等の各種ログ出力
- バックアップ処理の再開
- RTO/RPO/RLOの前提は以下のとおり
- RTO/RPO/RLOは目標であり、保証するものではない
- RLOはデータ復旧までであり、マルウェアの駆除完了は含めない
- RTOの基準は運用者が障害の認知や、復旧時の作業を開始したタイミングではなく、障害によりサービスが停止が発生したタイミングとする
- データ量およびファイル数は本要件定義で定めた上限に収まっていること
- 求める整合性はクラッシュ整合性までとし、ファイルシステム整合性やアプリケーション整合性は求めない
- ボリューム内に保持しているSnapshotはロストすることを許容する
- SMBアクセス時のスループットの劣化は平常時の50%まで許容する
他障害時のRTO/RPO/RLO
他障害時のRTO/RPO/RLOも定めます。
意味合いとしては、「他要件で定めた障害以外によって発生したサービス停止にはRTO/RPO/RLOは定めない」という形で使っています。
全ての障害パターンに対して網羅的にその障害にあったRTO/RPO/RLOを設定することは難しいです。プロジェクトとしてのスケジュールやコスト的にも発生確率が高い、もしくは業務影響度の高いものから復旧の要件を優先的に検討します。
その結果、検討できていない障害についても出てくるでしょう。検討できていないものについて目標を定めることはできないと考えます。逆に検討できるなら設定してしまいましょう。
要件の例は以下のとおりです。
- 他要件で定めた障害以外によってサービス停止が発生した場合のRTO/RPO/RLOは定めない
DRサイトで継続しない処理と業務
DRサイトで継続しない処理と業務について定めます。
RLOはRTOで定めた時間内に復旧させたい状態を定めています。初動としてRLOで定めた状態に復旧し、他のものについては順次復旧作業を行うでしょう。一方で、場合によっては縮退運転とし、一部業務は復旧させないことがあります。
要件の例は以下のとおりです。
- DRサイトで継続しない処理と業務は以下のとおり
- ファイル管理システム
- マルウェアスキャン
- その他、「マルウェア感染によるサービス停止発生時のRTO/RPO/RLO」および、「マルウェア感染によるサービス停止発生時のRTO/RPO/RLO」で記載していない処理、業務
- 上述の処理、業務についてはプライマリサイトのインフラ復旧後に、DRサイトからフェイルバックし順次復旧を行う
復旧処理の自動化範囲
復旧処理の自動化範囲についても定めておきます。
「一部障害において、復旧を自動化させること」といった復旧時の自動化が要求事項として出てくる時があります。
設計やコストに跳ねてくる要素であるため、早めに確認をします。
要件の例は以下のとおりです。
- 以下については復旧処理の自動化を行う
- ファイルサーバーのノードの単一障害時の別ノードでの業務継続
- ファイル管理システムサーバー、マルウェアスキャンサーバーの障害時のインスタンスの復旧
- 上述以外の以下のような処理については明示的な復旧処理の自動化を行わない
- インスタンス復旧後の業務再開処理
EC2インスタンスにおいては、最近ではデフォルトでAuto Recoveryが有効になっています。
これにより、物理ホストの電源やネットワーク接続喪失などAWSの基盤の問題で、EC2インスタンスがダウンしたとき自動的にインスタンスの復旧をしてくれます。とはいえ、クラッシュした状態によってはサービスの自動起動ができなかったり、依存関係があるシステムはまだダウンしている場合などと、スムーズに業務継続できるとは限りません。期待値調整に注意しましょう。
リストアとフェイルオーバーの粒度
リストアとフェイルオーバーの粒度について決定します。
粒度によって実装難易度が変動します。
よくある粒度については以下記事にまとめています。
要件の例は以下のとおりです。
- ファイルサーバーのリストアはボリューム単位で行う
- VMのリストアはVMのイメージ単位で行う
- DRサイトへのフェイルオーバーはSVM単位で行う
- ファイル単位、ディレクトリ単位でのリストアをする要件はない
性能・拡張性
ユーザー数、接続元システム数
想定ユーザー数と接続元システム数を定義します。
利用ユーザーやシステム数によって負荷のかかり具合も変わってくるので、事前に確認しておきましょう。他にも、使用するソフトウェアがユーザー数のライセンス課金である場合は、調達コストも変わってきます。
社員向けの全社ファイルサーバーなのであれば、ユーザー数 = 全社員数となるでしょう。
今後の増加見込みについても言及します。また、増加した時の対応のために必要に応じて計画停止を許容するか否かも合意しておくと、「無停止で対応できると思っていた」といった認識齟齬を回避することができます。
要件例は以下のとおりです。
- リリース時のファイルサーバー想定ユーザー数は1,000人とする
- リリース時のファイルサーバーとの連携システム数は30とする
- ユーザー数および連携システム数はリリース時の最大1.27倍まで対応可能とする
- 5年間5%/年 = 27%の増加見込み
- ユーザー数および連携システム数増加時の対応のために必要に応じて計画停止を許容する
最大同時セッション数
ユーザー数やシステム数とは別に同時セッション数も確認します。
要件では「同時アクセス数」とよく聞きますが、ことファイルサーバーにおいては「同時セッション数」の方がfsmgmt.mscやONTAP CLI、ONTAP REST APIで確認できるので後の評価がしやすいです。
「同時アクセス数」とした場合は、ファイルの読み書きといった実際にSMBファイルアクセスが同時に何件発生しているのかを把握する意味合いも含まれていると思います。これはなかなか計測することが難しいです。NASアクセスの監査ログを分析するといった一手間が必要でしょう。
「同時セッション数」や「同時アクティブユーザー数」といった表現が分かりやすいと思います。
要件例は以下のとおりです。
- リリース時のファイルサーバーへの想定最大同時SMBセッション数は1,500とする
- 「ファイルの読み書きといった実際にSMBファイルアクセスが同時に何件発生してるか」については要件として定めない
- 同時SMBセッション数はリリース時の最大1.27倍まで対応可能とする
- 5年間5%/年 = 27%の増加見込み
- 同時セッション数増加時の対応のために必要に応じて計画停止を許容する
データ量
想定データ量について定義します。
定義した量によって使用するストレージの選定や、ストレージコストへ跳ねてきます。ただし、ここで合意したサイズで見積もりをすると、ストレージ使用率100%のものが出来上がってしまいます。ストレージコストの見積もりの際には使用率やインフラのオーバーヘッド分も加味して計算しましょう。
また、ここでいうデータ量は論理データ量です。重複排除や圧縮は正直実際やってみないと分からない要素ではあるので、物理データ量で合意すると後々トラブルになりかねません。
DBや各種サーバーなどコアとなるリソースについては各リソースごとに確認をしましょう。ただし、VPC Flow Logs等のコアとなる業務外のログについては、細かく決めないこともあります。
拡張性という観点では、ストレージによってはリソースの作り直しを行わずに縮小することはできないため、その旨も合意しておくと良いでしょう。
要件例は以下のとおりです。
- リリース時のファイルサーバーの想定論理データ量は20TBを想定する
- ファイルサーバーデータ量には以下も含む
- NASアクセスの監査ログ
- Snapshot
- ファイルサーバーデータ量には以下も含む
- リリース時のファイルサーバーのバックアップデータの想定論理データ量は30TBを想定する
- 上述で言及されていない以下のような要素についても本要件定義の対象外
- VPC Flow Logsで出力するログ
- CloudTrailが出力するログ
- AWS Configが出力するログ
- 各種Lambda関数がCloudWatch Logsに出力するログ
- データ量はリリース時の最大1.27倍まで対応可能とする
- 5年間5%/年 = 27%の増加見込み
- データ量増加時の対応のために必要に応じて計画停止を許容する
- プロビジョニングしているストレージサイズをリソースの作り直しを行わずに縮小する要件はない
オンラインリクエスト件数
オンラインリクエスト件数の定義をします。
オンラインでリクエストを受け取ってレスポンスを返す処理がある場合は、単位時間あたりの目安を定義しましょう。読み取りや更新、決済、出荷処理などリクエストする処理によっては大きく目安は変わるため、代表的な業務や処理ごとに定義する形が良いでしょう。
オンラインリクエスト件数を定義する際にも単位時間を合意しましょう。この時、月や年といった大きな単位で合意をすると、スパイクアクセスに対応できない可能性があります。ピーク時性能として単位を秒や分にした場合の定義も行います。
ことファイルサーバーについてはオンラインリクエストの単位が分かりづらい、かつファイルサイズによって大きく結果が変動するので、決めないことが多いでしょう。
要件例は以下のとおりです。
- オンラインリクエスト件数の要件は定めない
余裕があれば季節や日、時間帯、何かしらのイベントといったリクエスト数の想定分布も確認、合意しておくと良いでしょう。
バッチ処理件数
業務の各バッチ処理ごとに単位時間あたりに捌く必要がある件数を定めます。
一般的なファイルサーバーではバッチ処理件数は要件として定めないことが多いでしょう。
定めるとするならば、連携するシステムのデータストアとして使用している場合です。この場合、連携システム側でバッチ処理件数の要件が出ていることがあるため、それをこちらにも記載する形となります。
ただし、連携システムが別プロジェクトとして走っている場合において、テスト結果から要件を満たせられないことが判明した際にどちらが主体を持って対応とするのかでトラブルになりがちです。別プロジェクトのメンバーとも適宜コミュニケーションをとり、他ファイルサーバーの性能として具体的に求められる要件や、責任分解点について合意をしましょう。
要件例は以下のとおりです。
- バッチ処理件数の要件は以下のとおり
- 月次帳票出力処理 : 10,00件/月、毎月4時間以内に完了
- 日次売上集計レポート処理 : 100件/日、毎日1時間以内に完了
- バッチ処理件数はリリース時の最大1.61倍まで増加し、定められた時間内に処理完了する
- 5年間10%/年 = 61%の増加見込み
- バッチ処理件数増加時の対応のために必要に応じて計画停止を許容する
- 上述以外のバッチ処理件数の要件は定めない
オンラインレスポンス性能
一件あたり何秒で処理を終わらせることができるかのオンラインレスポンス性能についても定めます。
オンラインリクエスト件数と同様に代表的な業務や処理ごとに定義しましょう。
また、順守率についても合意しておきましょう。SLOとして使われます。
こちらもファイルサーバーでは要件として定めないことが多いでしょう。
要件の例は以下のとおりです。
- オンラインリクエスト件数の要件は定めない
スループット
ファイルサーバーやストレージの場合はスループットとして要件を決めることがあります。
スループットの単位はMBpsやGBpsといったように時間あたりの読み書きの量です。
スループット以下のように種類があると考えます。
- スコープ
- End-to-Endのスループット
- ファイルサーバーやストレージにおけるネットワークスループット
- ディスクスループット
- プライマリ層
- キャパシティプール層
- 操作
- 読み取り
- 書き込み
どのスコープのどの操作のスループットについて指しているのか意識しながら要件を詰めましょう。
合意の仕方としては「最大X MBps」のように、最大値で合意します。ファイル数やファイルサイズ、アクセスパターン、アクセス場所、負荷状況によってスループットは大きく変動するため、ベースラインや平均のスループットを定めたとしても、あまり参考になりません。
一方で、一部のアクセス場所が遠地でレイテンシーが他アクセス場所よりも増大する場合は、そのシチュエーションにおいてどの程度のスループットを出せる必要があるのかの要件を決めておくと安心です。最大のスループットを出せる条件と同一条件において、アクセス場所だけ変更した場合に最大のスループットを出せる条件と同一条件比で何%程度のスループットを出せる必要があるのか決めておきましょう。場合によってはFlexCache等のキャッシュを遠地に配置することもあるでしょう。
参考までにAmazon FSX for NetApp ONTAPにおけるパフォーマンスチューニングの観点は以下記事をご覧ください。
要件の例は以下のとおりです。
- スループットの要件は以下のとおり
- End-to-Endの書き込みスループット : 最大50MBps
- End-to-Endの読み込みスループット : 最大100MBps
- 最大スループット条件でアクセス場所のみ変更した場合、元条件の20%以上のスループットを維持すること
- メモリキャッシュやNVMeキャッシュ等のキャッシュヒットによってスループットが向上した場合も含める
- 上述の要件を同時に満たすことは要件ではない
- 他ディスクスループット等の要件はない
- 求められるスループットを到達させるためには、一時的なダウンタイムの発生は許容するものとする
- スケールアウト/スケールアップといった手法は問わない
- 負荷に応じた自動拡張/縮小の要件はない
IOPS
IOPSについても確認します。
IOPSも以下のように種類があると考えます。
- スコープ
- End-to-EndのIOPS
- ディスクIOPS
- プライマリ層
- キャパシティプール層
- 操作
- 読み取り
- 書き込み
他考え方はスループットの場合と同様です。
要件の例は以下のとおりです。
- IOPSの要件は以下のとおり
- End-to-Endの書き込みIOPS : 最大1,000IOPS
- End-to-Endの読み込みディスクIOPS : 最大5,000IOPS
- 最大IOPS条件でアクセス場所のみ変更した場合、元条件の20%以上のIOPSを維持すること
- メモリキャッシュやNVMeキャッシュ等のキャッシュヒットによってIOPSが向上した場合も含める
- 上述の要件を同時に満たすことは要件ではない
- 他ディスクIOPS等の要件はない
- 求められるIOPSを到達させるためには、一時的なダウンタイムの発生は許容するものとする
- スケールアウト/スケールアップといった手法は問わない
- 負荷に応じた自動拡張/縮小の要件はない
コンピューティングリソース
コンピューティングリソースの拡張性について要件を定めます。
ここでいうコンピューティングリソースはCPUとメモリのことを指します。
負荷に応じてスケールアップさせたり、スケールダウンさせたりする必要があるのか確認します。また、ダウンタイムの有無や自動化の要件も確認します。
要件の例は以下のとおりです。
- コンピューティングリソースは拡張、縮小できるものとする
- スケールアウト/スケールアップといった手法は問わない
- 一時的なダウンタイムの発生は許容するものとする
- 負荷に応じた自動拡張/縮小の要件はない
- ここでいうコンピューティングリソースとはCPUとメモリを指す
- CPUのみ、メモリのみを拡張/縮小する要件はない
ネットワーク帯域
利用するネットワーク帯域についての要件を定めます。主にオンプレミスネットワークとの接続の帯域についてです。
既存のネットワーク回線を共有利用する場合は、既存のネットワーク回線の帯域使用状況も確認しておきましょう。
要件例は以下のとおりです。
- 東京リージョンとオンプレミス接続拠点の回線帯域は1Gbpsの帯域保証とする
- 大阪リージョンとオンプレミス接続拠点の回線帯域は1Gbpsのベストエフォートとする
- オンプレミスネットワーク内のルーターやスイッチ、サーバー、各種端末は1GBpsのネットワークで接続されているものとする
- 使用するネットワーク回線や各ネットワーク機器は他システムとも共有利用するものとする
- 東京リージョンVPCと大阪リージョンVPC間のネットワークの要求帯域はない
- 各種ネットワーク帯域に対する拡張性に関する要件はない
- その他、ネットワーク帯域に対する要件は定めない
ファイル共有数
ファイルサーバー移行の場合はファイル共有数についても言及します。
要件例は以下のとおりです。
- リリース時のファイルサーバーのSMBファイル共有数は100個とする
- データ量はリリース時の最大1.27倍まで対応可能とする
- 5年間5%/年 = 27%の増加見込み
- SMBファイル共有数増加時の対応のために必要に応じて計画停止を許容する
inode数
inode数も定めます。
細かいファイルが大量にある場合はinode不足により書き込みができなくなることがあります。
FSxNにおけるinodeについての説明は以下記事をご覧ください。
要件例は以下のとおりです。
- リリース時のファイルサーバーのinode数は2,000万個とする
- データ量はリリース時の最大1.27倍まで対応可能とする
- 5年間5%/年 = 27%の増加見込み
- inode数増加時の対応のために必要に応じて計画停止を許容する
運用保守
FSxNにおけるファイルサーバーの運用内容はおおよそ以下記事にまとめています。併せてご覧ください。
運用時間
システムの運用時間を定義します。
つまり、サービスが提供されており、ユーザーやシステムが不具合、遅延なく利用できる時間です。
ユーザーやシステムがいつ利用するのか、いつ利用できないと困るのかを整理して、現実的な運用時間を定めましょう。
24時間365日連続無停止だと実装難易度が跳ね上がります。強制的なメンテナンスが走るマネージドサービスを利用する想定においては、このような強いコミットに対して、コスト小さく対応することが難しい場面もあるため、例外としてメンテナンス時の停止についても言及しておくと安心でしょう。
要件例としては以下のとおりです。
- 通常、月曜日 - 日曜日の0:00 - 24:00 (JST) でサービスを提供する
- ただし、計画停止で定めたメンテナンスによる停止は許容する
計画停止
計画停止の有無を定義します。
運用時間でも触れた様に、RDSやFSxなどのマネージドサービスを使用する場合、メンテナンスウィンドウの設定や定期的なバージョンアップが必要なことがあります。
また、マネージドサービスを使っていなくとも、EC2インスタンスではスケールアップ/ダウンをする際には停止が求められますし、パッチ適用をする際にもOS、ないしは対象サービスを提供しているミドルウェアの再起動を求められることがあります。
理想は無停止だとは思いますが、それではビジネス要件変更に伴う設定変更や、調整をする余地もなくなってしまいます。
事前に計画停止有無について合意しておくと安心でしょう。
計画停止を行う場合については事前アナウンス有無についても合意しましょう。
AWS起因のメンテナンスは事前アナウンスしてくれるものも多いですが、FSx等事前アナウンスがないものもそれなりにある認識です。AWSが事前にメンテナンス通知してくれないものを、事前にユーザー部門にアナウンスすることは現実的にはできないので、一括りに事前アナウンスの確約をするのは危険です。
要件例としては以下のとおりです。
- 以下計画停止を予定する
- 週一回メンテナンスによる3時間枠内の数分程度の断続的な停止
- 四半期に一度の3時間程度の全体メンテナンスによる停止
- 計画停止時の事前アナウンス有無は以下のとおり
- マネージドサービス等のAWSによる自動メンテナンスについては、ユーザーや連携システム利用部門への事前アナウンスは不要
- 他メンテナンスについては事前アナウンスの実施が必要
このタイミングで具体的に「毎週何曜日の何時から何時までメンテナンスをする」時間帯の合意をすることは難しいでしょう。また、無理に合意したとしても合意した結果を活かすことができる場面はすぐにはありません。
申し送り事項として、以下のような記載をしておくと良いでしょう。
- 最終的な計画停止のスケジュールについては基本設計のタイミングで、各システム連携先のオーナーおよび、利用部門の代表者と協議をして決定する
ちなみに、メンテナンスウィンドウはメンテナンスを開始する時間の枠であって、メンテナンスの開始から終了までの枠ではありません。つまり、メンテナンスウィンドウで設定した時間外で、フェイルバックのために一時的なダウンタイムが発生する可能性があります。詳細は以下記事をご覧ください。
バックアップ目的と対象
バックアップの目的と対象を定義します。
RTO/RPO/RLOの項目で紹介したとおり、どのような障害や事象からの復旧を想定するのかや、どの程度の復旧時間を許容するのかによって、バックアップ方式は大きく変わります。そのため、目的をしっかり合意しましょう。
場合によってはアーカイブ目的でバックアップを保持することや、データ分析、テスト用データとしての活用もあります。
要件の例は以下のとおりです。
- バックアップの利用目的は以下のとおり
- 障害発生時の物理的なデータ損失防止
- ランサムウェアによる被害からの回復
- ユーザエラーからの回復
- バックアップの対象は以下のとおり
- ファイルサーバーのrootボリュームを除くボリューム内のデータ
- システム情報等のバックアップは含まない
- ファイル管理システムのデータ
- ファイルサーバーのrootボリュームを除くボリューム内のデータ
また、本来方式設計で決める要素ではあると思うのですが、バックアップの利用目的とリンクするバックアップ/リストア方式も軽く会話しておくと良いでしょう。
FSxNにおいては以下のようになります。
- 障害発生時の物理的なデータ損失防止として、ボリュームのバックアップを行う
- Snapshotはボリューム内に保存されており、ボリューム自体がなんらかの原因で消失した場合はSnapshotを用いてリストアできないため
- ランサムウェアによる被害からの回復および、ユーザエラーからの回復対応として、Snapshotを取得する
- Snapshotを用いたリストアは高速かつ、ボリューム全体のリストアだけでなく特定のファイルやフォルダのみのリストアも可能であり、利便性が高いため
- ボリュームのバックアップからのリストアはバックアップデータサイズによっては数分から数十時間かかることもあることに加え、リストアの粒度がボリューム単位となるため
以下記事も参考になるでしょう。
バックアップ取得間隔と保持期間
業務継続性とストレージコストのバランスを考慮し、バックアップ頻度と保持期間を設定します。
取得間隔は、許容できるデータ損失量と業務の重要度によって決まります。日次バックアップであれば最大1日分のデータ損失を許容することになります。一方、頻度を上げすぎると、ストレージコストやネットワーク負荷、手組みで行う場合はコンピューティングリソースのコストが増大します。
保持期間については、法的要件、監査要件、業務上の必要性を総合的に判断する必要があります。
ランサムウェア対策の観点でいうと、感染から発見までの期間を考慮した保持期間の設定も重要です。「リストア時は最新のバックアップからしか戻さないから保持期間は2日」とすると、感染して3日後に気づいてしまった場合にリカバリーできないデータが出てきてしまいます。
保持期間は保持"世代"なのか、保持"期間"なのかを認識合わせておきましょう。
要件例としては以下のとおりです。
- バックアップ取得間隔は以下のとおり
- ファイル管理システムのバックアップ : 日次
- ファイルサーバーのボリュームのバックアップ : 日次
- ファイルサーバーのボリュームのSnapshot : 毎時、日次、週次
- バックアップ保持期間は以下のとおり
- ファイル管理システムのバックアップ : 7日間
- ファイルサーバーのボリュームのバックアップ : 31日間
- ファイルサーバーのボリュームのSnapshot : 毎時6世代、日次14世代、週次4世代
- DRリージョンに転送されたバックアップおよび、Snapshot : プライマリリージョンと同一保持世代、保持期間
監視
監視要件について決めます。
閾値や具体的に見るべきメトリクス、監視手法といった詳細な監視項目は基本設計、詳細設計にて実施します。まずは、どういった種類の監視をするのかを確認しましょう。
要件例としては以下のとおりです。
- 監視実施内容は以下のとおり
- リソース監視 : CPU、メモリ、ディスク使用率等のリソースの使用量の確認
- 死活監視 : AWS Health Dashboardによるサービス状態確認
- 外形監視 : 実際のファイルアクセスの確認
- バックアップ監視 : バックアップジョブの成功/失敗状況
- セキュリティ監視 : 不審なアクティビティ、およびセキュリティポリシーにマッチしない状態のリソースの状態確認
- コスト監視 : ランニングコストの確認
- 監視通知先はSlackとする
- 通知内容の重要度に応じて通知先のSlackチャンネルを切り替える
ログ取得
取得する必要があるログの種別を定めます。
それぞれのログの利用目的も併せてヒアリングしましょう。監査目的、障害調査、アクセス分析などログごとの目的を知れば、ログにどのような情報が記載されているか、最適な保管場所はどこかを設計する材料になります。
要件の例は以下のとおりです。
- 取得するログは以下のとおり
- AWSのAPI実行ログ
- VPC上で発生した通信ログ
- 特権IDシステムで記録された管理アクティビティ監査ログ
- ファイルサーバーのNASアクセスの監査ログ
- 以下ログは取得しない
- DNSによる名前解決ログ
ログ保管期間
ログの保管期間について要件を定めます。
運用効率を向上やコンプライアンス要件を満たすために、適切なログ保管期間を設定しましょう。
ログは障害調査はもちろん、セキュリティ監査、コンプライアンス対応等で重要な材料になります。次の一手を打つために必要な情報です。可能な限り残しておきたい気持ちが出てきます。一方で、長期間の保管はストレージコストの増加につながるため、業務要件に応じた適切な保管期間の設定が重要です。
法的要件や監査要件がある場合は、それらを満たす期間を設定する必要があります。また、ログの種類によって重要度が異なるため、種類別の保管期間設定も検討しましょう。
要件例としては以下のとおりです。
- ログ保管期間は以下のとおり
- 原則として1年以上保持する
- 例外として以下は保管期間要件の対象外とする
- ONTAP内部に保存されている管理アクティビティの監査ログ (システム制約により48日間または4,800MB分)
- SnapMirrorのヘルスチェック用Lambda関数がCloudWatch Logsに出力するログ (運用ログのため短期保持で十分)
- ログ保管期間の見直しは年次で実施し、法的要件の変更や業務要件の変化に対応する
運用保守作業自動化範囲
自動化が必要な運用保守作業についての大枠を定義します。
手動での作業は、作業忘れや手順ミスのリスクが高く、対応品質にばらつきが生じがちです。定期的な作業を自動化することで運用効率を高めることが可能です。
なお、緊急時の手動実行や、イレギュラーな状況への対応余地も残しておくことも重要です。自動化されたプロセスが正常に動作しているかの監視も併せて検討しましょう。
要件例としては以下のとおりです。
- 以下の処理を自動化する
- スケジュールに基づくバックアップジョブの実行
- 設定した保持期限、保持世代数の上限に達したバックアップの削除
- バックアップデータの別リージョンへの転送
- パッチ適用
- ログローテーション
- 監視通知
- 以下の処理については自動化は行わない
- ポリシー違反したリソースの自動修復
- ファイルサーバーのストレージサイズの自動拡張
- ファイルサーバーのスケールアップ/スケールイン
セキュリティ
順守すべき規程
要件のベースとなる順守すべき規程を定義します。
連携された規定は必要に応じて要件として取り込みます。モノによってはオンプレミス前提だったりと対象外の規定もあるでしょう。そういったものは取り込みません。
また、長いプロジェクトだとベースとなるドキュメントがアップデートされてしまうこともあります。その結果、気づいたら要件を満たせていないということも起こりうるので、いつ時点のドキュメントなのかも表記しましょう。
要件例は以下のとおりです。
- 順守すべき社内規程、ルール、法令、ガイドラインは以下のとおり
- 全社セキュリティガイド.xlsx (2025/7/10 10:11受領)
- 個人情報保護規程 v3.0.pdf (2025/7/10 10:11受領)
- システム安全対策マニュアル.pdf (2025/7/10 10:11受領)
認証
認証有無および、その方式をまとめます。
重要な操作については多要素認証を必須とする形が良いでしょう。また、各システムの特性に応じた適切な認証方式を選択することが重要です。ユーザー負荷軽減が必要なのであればSSOを求められるでしょう。
要件の例は以下のとおりです。
- 重要な業務については多要素認証 (ワンタイムパスワード、生体認証、パスキー等) を活用して本人確認する
- 各操作ごとの認証は以下のとおり
- AWSマネジメントコンソールの操作 : ID/PASS認証 + MFAデバイス認証
- AWS CLIを用いた操作 : 一時的に発行された認証情報
- 特権ID管理システムへの接続 : Active DirectoryとのKerberos認証
- ファイルサーバーへのSSHを用いた操作 : 特権ID管理システムの認証 + ID/PASS認証
- ファイルサーバーへのAPIを用いた操作 : ID/PASS認証
- ファイルサーバーへのMMCスナップインを用いた操作 : Active DirectoryとのKerberos認証
- ファイルサーバーへのNASアクセス : Active DirectoryとのKerberos認証 もしくは NTLMv2認証 (原則Kerberos認証を用いること)
- 各種Windows ServerへのRDP接続 : 特権ID管理システムを介したActive DirectoryとのKerberos認証
- ファイル管理システムのWebコンソールを用いた操作 : 特権ID管理システムの認証 + ID/PASS認証
- AWSマネジメントコンソールで操作をする際に使用する認証情報は各AWSアカウントに用意するのではなく、代表のAWSアカウントにて管理を行う
- 以下の要件はない
- 管理者権限を用いた操作をする際に複数の承認者による承認要求
- 統一的なセッションタイムアウト時間
- パスワードの入力失敗回数の制限
必要によっては端末IDや電子証明書確認等で接続相手先が正当な端末であることを確認する必要がある場面もあるでしょう。
Howの要素はあまり早期に絞り込みたくはないですが、決定内容に対して後続タスクのブレ幅が大きい時は決めてしまう時もあります。
ユーザー管理
個人の識別可能性と責任追跡性を確保するため、適切なユーザー管理を実施します。
共有アカウントの利用は、操作の責任所在が不明確になるため、原則として個々人に割り当てましょう。
要件の例は以下のとおりです。
- 原則、ユーザーアカウントはユーザー個人に割り当てる
- 以下のようなシステムで使用するユーザーアカウントについては共有アカウントとして使用する
- ファイルサーバー用REST API用サービスアカウント
- ユーザーライフサイクル管理として以下を実施する
- 入社時のアカウント作成
- 異動時の権限変更
- 退職時のアカウント無効化
- 以下の要件はない
- 一定期間システムにアクセスのないユーザーアカウントの自動無効化や削除
アクセス制御
どのような方針でアクセス制御を行うのか決定します。
過度な権限付与は、内部不正や権限昇格攻撃のリスクを高めるため、職務に応じた適切な権限設計が重要です。
要件の例は以下のとおりです。
- 過剰な権限付与を行わない
- 社内ネットワーク内からのアクセスであっても全てのIPアドレスからの全ポートへのアクセス許可は行わず、極力必要最小限の許可を行う
- 社内部間通信のためIPS/IDS機能は不要
IPS/IDSを導入する方向の場合は、TLSインスペクションの有無も確認しましょう。TLSインスペクションを行う場合はIPS/IDSを通るHTTPSクライアントにTLSインスペクションで使用する証明書の署名で使われているCA証明書を配布する必要があります。
他にもネットワーク型なのかホスト型なのかも決めると良いでしょう。ネットワーク型の場合は以下のようにパターンがあります。
- VPCとVPC間
- VPCとオンプレミスネットワーク間
- VPCとインターネット間
- インターネットからのインバウンドリクエスト
- VPCからのアウトバウンドリクエスト
例えば、インターネットからのインバウンドリクエストをきっかけとする場合、ALBとターゲットの間に構成が複雑になります。
暗号化
データの機密性を保護するため、転送時および保存時の暗号化を実施します。
データ漏洩時の影響を最小化する重要な対策です。ただし、暗号化による性能影響や実装コスト増加も考慮し、リスクと効果のバランスを取った実装が必要です。
要件の例は以下のとおりです。
- 転送データ暗号化は以下のとおりとする
- ファイルサーバーとのNASアクセスはNASアクセスプロトコルによる暗号化を実施する
- ファイルサーバーへの変更や削除などといった各種操作時の通信は暗号化を実施する
- AWSマネジメントコンソールやAWS CLIを始め、AWSの操作時の通信は暗号化を実施する
- IPSec VPNやSSL VPNなど通信経路に対する暗号化は必須ではない
- その他上述以外の通信の暗号化は必須ではない
- 保存データ暗号化は以下のとおりとする
- ストレージ側での暗号化を原則必須とする
- 実装コストや運用コストの見合いで現実的ではない場合は、非暗号化でも良いこととする
- クライアント側の暗号化は必須ではない
- 暗号化キーは自組織で以下管理が可能なものとする
- 暗号化キーを起点としたアクセス権限のコントロール
- ローテーション間隔のコントロール
- ストレージ側での暗号化を原則必須とする
ログ保護
ログに対する保護要件を確認します。
例えば、オブジェクトロックをかけたり、SCPでS3バケット内のオブジェクトの削除を禁止したりします。
要件の例は以下のとおりです。
- 取得したログについて改ざん・不正アクセスを防ぐためにアクセス権の設定やファイル削除防止機能の利用などの保護策を講ずる
バックアップ保護
バックアップについても保護要件を確認します。
近年のランサムウェアはバックアップデータも標的とするため、単にバックアップを取得するだけでは不十分です。WORM (Write Once Read Many) 機能により、一度作成されたバックアップデータの変更や削除を防ぐことができます。
ただし、WORM機能を有効にすると、保持期間中はデータの削除ができないため、誤って設定してしまった場合のリスクは大きいです。ストレージコストも増加してしまうでしょう。長期間のバックアップ保持を予定している場合は慎重な検討が必要です。
要件例としては以下のとおりです。
- バックアップ保護機能は以下のとおり
- ボリュームのバックアップ : WORM機能を使用
- ボリュームのSnapshot : WORM機能は使用しない
- WORM設定の変更は、セキュリティ管理者の承認を必要とする
マルウェア対策
ランサムウェアを含むマルウェアからシステムを保護するための対策要件を確認します。
ファイルサーバーは多くのシステムやクライアントPCが接続していることが多いため、マルウェア感染またはマルウェアファイルが配置された場合の影響が甚大です。リアルタイムスキャンにより、感染ファイルの拡散を防ぎます。ただし、可用性とのバランスも考慮した設計が必要です。
要件の例は以下のとおりです。
- マルウェア対策としてファイルサーバー上のファイルに対してアンチマルウェアソフトのスキャンを行い、不審なファイルの駆除を行う
- スキャンはNASによるファイル操作をトリガーとしたリアルタイムスキャンとする
- スケジュールによるスキャンは行わない
- なんらかの理由でマルウェアスキャンに失敗した場合はNASアクセスを優先する
- マルウェアスキャン用のサーバに対して障害が発生した場合はNASアクセスの継続提供を優先し、マルウェアスキャン用のサーバが復旧するまでマルウェアスキャンの実施を行わない
クライアントにもEPPやEDRがインストールされていることが望ましいですね。必要に応じて備考にその前提であることを書いておきましょう。
アノマリ検知
内部不正や異常な操作パターンを検知するための対策要件を確認します。
正常な操作パターンから逸脱した操作を検知することで、内部不正やアカウント乗っ取りなどの脅威を早期に発見できます。
GuardDutyが最も分かりやすいでしょう。
FSxNではARP機能が該当します。
具体的に検出したい攻撃やブロックしたい操作を起点に考えていきましょう。
要件の例は以下のとおりです。
- 以下のような不審なアクティビティーを検知する
- ファイルの大量コピーや大量同時削除
- 通常と異なる時間帯でのアクセス
- 通常と異なるアクセス元からの接続
データ改ざん対策
データ改ざんへの対策要件を確認します。
転送時のデータについてはTLSで暗号化されていれば、その暗号化処理の中でMACを行い改ざんを防いでくれます。
保存されているデータに対する改ざん対策は難易度が高いです。WORMで書き込みや変更を防ぐ方向性もあれば、何かしらの変更があった場合に通知をするといった方向性もあります。後者の場合、手組みするのは非常に大変なのでTripwire等を製品やサービスを導入する必要があると考えています。保存されてるデータの改ざん検知をしたい場合はリアルタイム性についても詰めてましょう。
要件の例は以下のとおりです。
- 改ざん対策の実施内容は以下のとおり
- 転送時のデータは、暗号化により改ざんを防ぐものとする
- ログ及びバックアップを除いて、保存されているデータに対する特別な改ざん対策は不要
DDoS対策
DDoS対策の要件を確認します。
インターネットに公開しているWebシステムであれば、CDNを挟んだりWAFを導入したり、AWS Shield Advancedを使用したりすることがあるでしょう。他にも負荷に応じてスケーリングして性能を増強する方向性で対策することもあると考えます。
ファイルサーバーのような社内向けのシステムであれば行わないことがほとんどでしょう。
要件の例は以下のとおりです。
- 現時点では外部公開しないため、個別のDDoS対策は不要
パッチ適用
パッチ適用に対する要件を定めます。
セキュリティ脆弱性への対応とシステムの安定性維持のため、定期的なパッチ適用を行いたいところです。
セキュリティパッチの適用遅れは、既知の脆弱性を悪用した攻撃のリスクを高めます。AWSマネージドサービスの自動アップデート機能を活用することで、運用負荷を軽減しながら適切なセキュリティレベルを維持します。定常運用に組み込まれていないビッグバンパッチ適用は、その実行回数の少なさから手順の習熟が遅く、余計にパッチ適用のハードルが高くなってしまう印象があります。
既存のパッチ適用のルールを確認した上で合意しましょう。
要件の例は以下のとおりです。
- ファイルサーバーやファイル管理システムサーバー等、各種リソースは定期的にパッチ適用を行う
- 定期パッチ適用のためのメンテナンスウィンドウを設定する
- パッチ適用による再起動は自動的には行わせず、再起動は手動で行う
- パッチ管理用の専用のリポジトリサーバーは用意しない
- 原則、パッチ適用はステージング環境から実施する
- ステージング環境適用から、本番環境適用までのクールタイムは要件としては定めず、基本設計以降で定める
パスワードポリシー
パスワードポリシーを合意します。
要件の例は以下のとおりです。
- パスワードポリシーは以下のとおり
- 3種類以上の複数文字種 (数字・英大小文字・記号) 、かつ12桁以上を設定する
- 利用者個人に紐づくユーザーアカウントのパスワードは180日以内に定期的に変更をする
- 前回もしくは以前と同一のパスワードは使用禁止とする
- システム的な制限の実施は問わない
システム的な制限を行うか否かは一つポイントだと考えます。
脆弱性管理
脆弱性管理に対する要件を定めます。
脆弱性は日々新たに発見されるため、一度の対応で終わりではなく継続的な監視と対応が必要です。システムの脆弱性を継続的に管理し、セキュリティリスクを最小化するために何を行うのか決めましょう。
要件の例は以下のとおりです。
- 定期的な脆弱性スキャンの実施を行う
- 脆弱性スキャン対象する要素は以下
- インストールされているパッケージ
- Lunuxについてはデフォルトのパッケージマネージャーリポジトリでインストールしたもののみとする
- コードの脆弱性についてはスキャン対象外とする
- インストールされているパッケージ
- 検出された脆弱性の対応は基本設計以降で定める
セキュリティ診断実施の範囲と実施タイミング
セキュリティ診断実施について定義します。
リリース前、もしくは継続的に脆弱性診断を求められることがあります。特に個人情報を扱う場合や、外部接続部分については行われる印象があります。
要件の例は以下のとおりです。
- セキュリティ診断実施の範囲はファイルサーバーおよびファイル管理システムサーバー
- セキュリティ診断ツールとしてNessus、OWASP ZAP、Security Hubを使用する
- 実施タイミングは以下のとおり
- 本番リリース前
- 日次 (Security Hubのみ)
- 年次
- 重要な設定変更後
- 設定変更後 (Security Hubのみ)
移行
システム移行期間
システム移行の全体期間を定義します。
ファイルサーバー移行限らず、大規模な移行ではデータ量や業務の複雑性、既存環境への影響度合い、リスクを加味してスケジュールを組み立てる必要があります。スケジュールについての制約事項など会話しておきましょう。
スケジュールを立てる際には機器のEOLやDC撤去などハードリミットとなる要素についても洗い出します。
要件例としては以下のとおりです。
- システム移行期間は2025/7/1から2026/6/30とする
- ここでいう移行期間は移行作業計画から移行先環境の並行稼働期間完了までの期間を指す
- 移行リハーサルは2回以上実施する
- スケジュール制約として以下を設定する
- 組織改編のある3月4月、9月10月の期間を跨ぐような移行は回避
- 年末年始、ゴールデンウィーク期間中の移行作業は原則実施しない
- 決算期など業務繁忙期との重複を避ける
- 現行仮想化基盤の運用保守契約は2026/8/31までであるため、少なくとも2026/7/31までには移行する必要がある
正直、文章として起こすのは難しいので別途項目ごとのスケジュールはPowerPointやExcel等で図示しておきましょう。項目としては以下があると良いでしょう
- 移行計画立案
- 移行計画レビュー会議
- 移行手順書作成
- 移行テスト実施
- 移行リハーサル実施
- 本番移行実施判定会議
- 本番移行実施
- 初期データ移行
- 差分データ転送
- システム移行
- 業務移行
- 運用移行
- 本番移行完了判定会議
- 並行稼働期間
- 並行稼働終了判定会議
単純な作業以外にも判定会議のようなプロジェクト的なマイルストーンも決めておきたいです。プロジェクト規模によっては経営層に出張っていただく必要もあります。そのタイミングで何も情報を共有してしまうと正常な判断を行うことができなくなってしまいます。
移行計画立案のフェーズでは以下のようなことを実施します。
- 移行対象の実機および各種メトリクス、ドキュメントの情報収集、分析
- 移行対象ごとの移行方式の整理
- 主要タスクおよびマイルストーンのスケジュールの立案
- 実施体制の計画
- 必要な移行前後で必要な業務調整の整理
- 移行リスク評価
- 移行判定基準の整理
- コンティンジェンシープランの計画
移行計画はつい構築が完了の目処がついたタイミングで手をつけがちですが、私の経験上計画を後回しにするのはトラブルの元です。要件定義や基本設計をしているタイミングで並行して計画を進めましょう。
ちなみに、移行作業は以下のように4種類に大別して考えると良いでしょう。
| 移行種別 | 内容 |
|---|---|
| データ移行 | 既存ファイルサーバーからファイル/フォルダの実データおよびメタデータの転送 |
| システム移行 | クライアントからのアクセス先ファイルサーバーの切り替え |
| 業務移行 | ファイルの変換、新ファイルサーバーの利用方法や管理ルール、業務フローの切り替え |
| 運用移行 | バックアップや監視、セキュリティ対策などファイルサーバーに関する運用の移行 |
システム停止可能タイミング
システムの停止が可能なタイミングを定義します。
直前だと業務調整ができない場合もあるので、早めにシステム停止が可能なタイミングの確認と、要望を伝えておきます。
要件の例は以下のとおりです。
- 移行に伴う現行システム停止は以下のとおり実施する
- 原則土日に実施
- 一部土日業務利用部門は個別調整を実施する
- 停止時間は最大8時間以内とする
- 停止の2週間前に事前に利用者へ通知を実施する
- 原則土日に実施
個別調整が必要な利用部門は申し送り事項として記載しておきましょう。
もし、システム停止ができない場合はシステムやネットワーク、業務の負荷が低い時間帯を探し出してシステム移行やデータ移行を実施しましょう。場合によっては業務調整をして一時的に時間をズラすといったことも可能だと思います。
並行稼働
並行稼働の有無を定義します。
並行稼働期間を設けることで、ユーザーの負担は減りますが、移行プロセスが複雑化します。個人的には避けることが可能なのであれば避けたいところです。特に現行環境と新環境のデータ同期をどうするのかはよく議論しましょう。コンフリクトを回避しながら自動で新環境に反映させるのは中々大変です。
仮に並行稼働をする場合の要件例としては以下のとおりです。
- 並行稼働は以下のとおり実施する
- 一部領域については並行稼働期間を設ける
- 並行稼働期間は最大1ヶ月とする
- 並行稼働期間中の差異対応は以下のとおり実施する
- ファイルの差分 : 現行環境で行なった変更はユーザー部門が新環境にも反映を行う
- ファイル共有の差分 : 並行稼働期間中は現行環境上でファイル共有の作成/変更/削除を凍結
上述の例では、並行稼働を行う領域について申し送り事項として起票し、別フェーズで詰めましょう。
展開ステップ
移行の展開ステップを定義します。
一括展開をするのか、ユーザー部門や拠点、システム等のまとまりで段階的に展開していくのかを決めましょう。
個人的にはカナリアリリースのように一部部門で先行展開を行い、実業務での動作や性能、運用の確認を行った後、他部門含めた移行を行う形が好みです。
要件例としては以下のとおりです。
- 展開方式は以下のとおり
- ユーザー部門および、システム単位で現行環境から新環境へ切り替えを実施する
- 切り替え後1週間は切り戻し可能な体制を維持する
- 展開順序として以下の2ステップで行う
- ステップ1 : IT部門での展開
- ステップ2 : その他部門、システムでの展開
移行対象
移行対象の定義をします。
移行対象を明確にすることで、移行漏れや想定外の作業を防ぐことができます。既存のログをどうするかで後々トラブルになるのはあるあるだと思うので、持っていかないものとしても明記できるものは明記しましょう。
要件例としては以下のとおりです。
- 移行対象システムは以下のとおり
- ファイルサーバー上に保存されている各種実データファイル
- ファイル管理システム用サーバー機能
- 以下のような上述以外の要素は移行対象外とする
- AD DC
- 一時ファイル
- システムファイル
- 各種ログデータ
移行データ仕様
移行対象のデータ仕様を定義します。
データ量やファイル数の正確な把握は、移行時間の見積もりや必要リソースの算出に不可欠です。
要件例としては以下のとおりです。
- 移行データの基本仕様は以下のとおり
- 移行データ量 : 10.0TB想定 (2025/7/26時点で9,500GB)
- 移行データ形式 : NTFSで取り扱えるもの
- ファイルおよびフォルダ数 : 900万個想定 (2025/7/26時点で8,500,000個)
移行先で保持するメタデータ
データの完全性を保つため、移行時に保持すべきメタデータを定義します。
移行のタイミングで、ファイルの作成日時やACLといった情報が抜けてしまうとユーザー側からすると、非常に不便です。後々トラブルとならないように維持する必要があるメタデータ、および失われても良いメタデータを合意しましょう。
要件例としては以下のとおりです。
- 保持対象メタデータは以下のとおり
- ファイルのアクセス時間
- 変更時間
- 作成時間
- ファイル所有者のセキュリティ識別子
- 標準ファイル属性
- Read Only
- アーカイブ
- システム
- 隠し
- 圧縮
- 暗号化
- ディレクトリ属性
- DACL
- SACL
- 保持できないメタデータとして以下を明記する
- 拡張属性
- 代替データストリーム
- ファイルシステム固有の属性
システム環境
システム利用範囲
システムの利用範囲を定義します。
特定部門、全社、グループ会社、社内システム、BtoB、BtoCなどシステムの利用範囲を明確化します。内容によって満たすべきセキュリティポリシーや、バーストトラフィックへの対応、ネットワークレイテンシーのパフォーマンス影響の緩和策といった考慮をする必要があります。
要件の例は以下のとおりです。
- システムの利用範囲は以下のとおり
- 日本国内の全社のユーザー
- 特定の社内システム
- 具体的な社内システムは別表で記載
構築時制約条件
構築時の制約条件を定義します。
制約となる社内基準や法令、各地方自治体の条例などの制約が存在しているかを確認します。例えば、マネジメントコンソールにアクセスする場合は閉域接続 かつ 必ず許可されたIPアドレスや端末からしか接続する必要があるといった要件だったり、リソースは原則IaCで行うという要件があったりします。
要件の例は以下のとおりです。
- 原則、IaCで作成できるリソースはIaCで作成する
- 具体的にどのリソースをどの手法で構築するかは基本設計内で検討
運用時制約事項
同様に運用時の制約条件を定義します。
要件の例は以下のとおりです。
- EC2インスタンスに接続する際には特権管理IDシステム経由で接続する必要がある
- 定期的にアクセス状況等のログ情報を活用して、付与権限の棚卸しを行う必要がある
- 特権IDは業務必要時のみ申請し、不必要に特権IDを使用してはならない
システム環境
開発/ステージング/本番といったワークロードの各環境を用意するかを合意します。
本番環境へのいきなりの変更作業は、サービス停止やデータ損失のリスクが高く、事故になりやすいです。事前にステージング環境での十分な検証を行いたいところです。
可能であればAWSアカウントレベルでの環境分離をしましょう。アカウント分離の背景やアカウント分離時の対応は以下記事にまとまっています
アカウント分離はAWS Well-Architected フレームワークでも紹介されています。
要件例としては以下のとおりです。
- 本番/ステージング/開発の各環境を用意する
- 各環境ごとにAWSアカウントを分離する
- 本番およびステージング環境にはDRサイトを用意する
- ステージング環境は本番環境と同等の構成とする
- 平常時は性能は本番環境と同等ではなくとも良いが、検証時は本番環境と同等の条件に揃えられるものとする
- 環境間のデータ連携は行わない
特定製品採用
OSやミドルウェア、SaaS等の何か特定の製品利用の指定があるか確認します。
ライセンス調達方法の検討やサポートの体制を組むことができるかを判断する材料とします。
要件の例は以下のとおりです。
- 特定製品指定はなし
製品指定がない場合でも、備考としては利用予定商用製品をリストアップしておくと良いでしょう。
ファイルサーバー機能
サポートするファイルアクセス用のプロトコル
ファイルサーバーにファイルアクセスする際に使用するプロトコルを定義します。
同一ファイルにマルチプロトコルでアクセスさせることが要件だと、途端に複雑性が増します。
Amazon FSx for NetApp ONTAPにおけるマルチプロトコルアクセスや、SFTP接続については以下記事をご覧ください。
要件の例は以下のとおりです。
- サポートするファイルアクセス用のプロトコルは以下のとおり
- SMB 3系
- 上述していない以下のようなプロトコルの使用は要件として存在しない
- NFS
- SFTP
- iSCSI
- NVMe over TCP
ファイルやディレクトリに対する制約
ファイルの最大サイズやフルパスについての制約を定義します。
クライアントによっては最長のフルパス名の上限が短かいことがあります。
要件例は以下のとおりです。
- 1ファイルの想定最大サイズは6GB想定とする
- 最長ファイル名は255文字までとする
- 最長フルパス名は259文字までとする
- フルパスの範囲は "<SMBファイルサーバー名><SMBファイル共有名><ディレクトリ名><ファイル名>"
- ただし、上述のいずれの要件もシステム的なハードリミットは行わない
ファイルやフォルダへのアクセス制限方法
ファイルやフォルダへのアクセス制限方法を定義します。
要件の例は以下のとおりです。
- ユーザーやシステムがファイルサーバー上のファイルおよびフォルダへ参照/更新/削除といったアクセスの制限は以下の方法にて行う
- 各ファイルおよびフォルダにて設定したNTFS ACL
- SMBファイル共有ごとに設定したACL
- 「SMBファイル共有ごとに設定したACL」は各SMBファイル共有のSecurityタブで設定する共有権限のことを指す
- ファイルサーバーへのネットワーク的な制限は本要件には含めず、別要件で定義する
「共有フォルダ」という単語は誤解を生みやすいので、使いません。SMBファイル共有で統一します。「共有フォルダ」という単語を使うことによる注意点は以下記事にまとめています。
ストレージクォータ
ストレージクォータの有無と種類、通知の要件について定めます。
ストレージクォータを設定することで、ファイルシステムやボリュームといった大きな単位ではなく、より小さな単位でストレージの使用量を割り振ることができます。
要件の例は以下のとおりです。
- ストレージクォータを設定する
- ストレージクォータはボリューム内に作成した任意のサブフォルダ単位で設定できるものとする
- ユーザーやグループ単位では設定しない
- ストレージクォータはソフトクォータとする
- ハードクォータは行わない
- ソフトクォータ超過の検出は日次で行う想定とする
- 通知のタイミングはリアルタイムおよび、ニアリアルタイムである必要はない
- 障害等による影響でソフトクォータ超過を検出する仕組みがダウンした場合については、日次で検出できなくとも良い
- ソフトクォータ超過を検出する仕組みが復旧後に対応するものとする
- ソフトクォータに達した場合は各サブフォルダごとに設定した管理者に通知を行う
- 通知の方法は問わない
- ソフトクォータの各適用対象の現在の使用率を示すダッシュボードは不要
なお、上述の要件はAmazon FSx for NetApp ONTAPのみの機能では実装できません。何かしらの3rdパーティ製品を採用する必要があります。
ONTAPではディレクトリ単位のストレージクォータをかけるにはqtreeを使用するのですが、qtreeはボリューム直下にしか作成できず、任意の階層には作成できないためです。qtreeを用いたストレージクォータについては以下記事をご覧ください。
セッション管理
ファイルサーバーの管理者向けにセッションを管理する機能の要件について定めます。
FSxNにおけるセッション管理は以下記事にまとめています。
要件例としては以下のとおりです。
- セッション管理機能は以下のとおり
- ファイルサーバ上のファイルを開いているセッションの確認および削除ができる
- 確認および削除方法は問わない (GUI、CLI、API等)
- セッション情報として以下を表示する
- 接続ユーザー名
- 接続元IPアドレス
- 開いているファイル名
- セッション開始時刻
ファイル名やディレクトリ名のUTF-8の4バイト文字対応
ファイル名やディレクトリ名のUTF-8の4バイト文字対応が必要か否かを定義します。
UTF-8の4バイト文字対応については以下記事で紹介しています。
要件例としては以下のとおりです。
- ファイル名やディレクトリ名の文字エンコードは4バイト文字に対応したUTF-8を使用するものとする
Active Directoryのドメイン参加
ADのドメイン参加有無について記載します。
ドメイン参加をすることによって、既存のドメインユーザーでファイルサーバーにアクセスできます。また、管理者目線からしても、専用のユーザーアカウントの発行を回避でき、統一的なアカウント管理が可能になります。
一方で小規模な環境ではむしろADの管理負荷の高さから導入をしないことがあります。
要件例としては以下のとおりです。
- ファイルサーバーは既存のActive Directoryにドメイン参加をする
アクセス頻度に応じたデータの階層化
アクセス頻度に応じたデータの階層化について定めます。
数TBほどあるファイルサーバーだと全てのデータが常時アクセスされるケースは非常に稀でしょう。
その場合、長期間アクセスされていないデータを低コストなストレージに移動することで、コスト効率を高めることができます。ただし、階層化したデータにアクセスした場合のレイテンシーは増大します。コストとパフォーマンスを加味した上で判断する必要があります。
FSxNにおいてはFabricPoolによる階層化は以下記事で紹介しています。
一方で、FSxNおよびFSxZ、S3以外は透過的なデータの階層化を行うことはできません。アーカイブ用の別領域に移動させるのであれば、自作でスクリプトを組んだり、3rdパーティ製品を導入したりする必要があります。個人的には自作はハードルが高いので実施する方向性には持っていきません。
要件例としては以下のとおりです。
- データ階層化機能は以下のとおり
- 最終アクセス日から一定期間経過したデータを透過的に安価なストレージへ階層化をする
- 階層化されたデータにアクセスした場合、プライマリストレージに戻す
- 階層化の単位はファイルレベル、ブロックレベル問わない
- 最終アクセス日から一定期間経過したファイルの自動削除を行う要件はない
もし、可能なのであれば想定している最終アクセス日から、1ヶ月の内にアクセスされるデータの割合 : 全体のデータサイズのうち30%を想定
物理データ削減処理
物理データを削減する処理が必要か否かを定義します。
一般的なファイルサーバーには、同一または類似のファイルが保存されることが多く、重複排除により大幅な容量削減が期待できます。圧縮やコンパクションと合わせて体感10% - 20%程度削減できる感覚があります。
こちらも使用予定のストレージにて機能として提供されていない場合は、実装する方向に持って行かない方が良いでしょう。
FSxNにおける物理データ削減処理は以下記事にまとめています。
要件例としては以下のとおりです。
- 物理データ削減処理は以下のとおり
- 原則として重複排除、圧縮、コンパクションといった物理データ削減処理を実装する
- スループットに著しい影響がある場合は実装を行わなくとも良い
- 重複排除の粒度はブロック単位、ファイル単位問わない
- 物理データ削減割合についてはコミットしない
利用者自身でのファイルリストア
ユーザーの利便性向上と管理者の運用負荷軽減のため、利用者自身でのファイルリストア機能を用意することがあります。
VSS等の誤ってファイルを削除したり、古いバージョンに戻したい場合に、管理者に依頼することなく、利用者自身で復旧できる機能は非常に便利です。
FSxNにおける利用者自身のファイルリストアについては以下記事で紹介しています。
なお、以下記事で紹介しているととおり、ディレクトリ配下全体ををSnapshot取得時点にリストアすることはできません。ユーザー側で対象ディレクトリ配下を全て削除した上でリストアする形を取る必要があります。
要件例としては以下のとおりです。
- 利用者自身でのセルフリストア機能の要件は以下のとおり
- 特定のファイルを任意のSnapshot取得時点に戻す機能を提供する
- 指定したディレクトリ配下全体を特定時点に戻す機能は不要とする
- リストア速度に対する要件はない
ファイル検索
ファイル検索機能について要件を定めます。
一般的にファイルを検索する際は、ファイル名やディレクトリ名等で絞り込みを行います。
さらに、大量のドキュメントファイルから必要な情報を迅速に見つけるため、ファイル名だけでなく、ファイル内容も検索対象とする全文検索機能があると非常に便利です。
一方でファイルサーバーの機能として標準的に実装されていることは限られます。Nextcloudでは以下のように全文検索用にElasticseatchと連携するプラグインを導入するという対応が必要になります。
完全に自作をするにはハードルが高すぎます。機能としてサポートをしている製品をピンポイントで選定することになるでしょう。
要件例としては以下のとおりです。
- ファイル検索機能の要件は以下のとおり
- ファイル名、ディレクトリ名での検索機能はエクスプローラーやFinderといったクライアントの機能を使用する前提とし、ファイルサーバー自体の機能としては提供しない
- ファイルサーバー機能として、ファイル内容を対象とした全文検索機能を提供する
- 全文検索機能用にWebブラウザベースの専用のインターフェイスを提供する
- 全文検索の対応ファイル形式として以下を含める
- Microsoft Office製品 (Word、Excel、PowerPoint)
- テキストファイル
- 以下についての機能実装は行わない
- キーワード等複数検索条件指定時の"AND"および"OR"の明示的な指定は行わない
- 検索履歴の保存
Webブラウザからのファイル操作
BoxやOneDriveのようにWebブラウザからのファイル操作を求められているのかを確認します。
こちらの要件がある場合、個人的には素直にBoxやOneDriveを導入した方が良いと考えます。サーバー間でのデータやり取りの場としても必要なのであれば、Nextcloudを導入する形になると考えます。
要件例としては以下のとおりです。
- Webブラウザからのファイル操作機能の要件は以下のとおり
- ファイルおよびディレクトリの検索、削除、移動、コピーが可能
- ファイルのアップロード、ダウンロードが可能
- 特定拡張子のファイルのプレビューが可能
- Microsoft Office製品 (Word、Excel、PowerPoint)
- テキストファイル
- 画像
- 動画
ファイル共有リンク機能
組織外のメンバーとファイルを共有するために、一時的な共有リンク機能が必要か確認をします。
こちらも要件がある場合はBoxやOndDriveといった専用のSaaSを導入することを検討しましょう。
要件例としては以下のとおりです。
- ファイル共有リンク機能の要件は以下のとおり
- 指定した期限付きの共有リンクの生成が可能
- 共有リンクからアクセスする際に別途パスワードを要求
- アクセス状況の追跡は不要
プロジェクト成功のために要件を整理しよう
要件定義を例を添えて、要件定義をするときに意識していることをまとめてみました。
プロジェクト成功のために要件を整理しましょう。「これは！」というモノがあれば必要に応じて気づいたタイミングで更新していこうかなと思います。
ちなみに、このぐらい各要件ごとの説明と例を生成AIへインプットとして提示すると、ボチボチな精度で他に考慮するべき要件とその説明、例を出力してくれます。「もう一人のボク」な気分です。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
![[トラブルシュート] fish + awsumeを使ってスイッチロールした時の権限エラーの解決メモ](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-afb8c010d7789109015110e5802383b4/506a5c1ec4d5d675831f8f65783b5d2f/aws-cli)
