バックアップ要件には、ほぼ必ず保存期限の指定があります。
たとえば、こんな要件です。
バックアップデータを5日分保存すること
一見すると、単純な要件に見えます。
バックアップソフトの保持期間を5日に設定すればよい。
AWS Backupであれば、ライフサイクルの保持期間を5日にすればよい。そう考えたくなります。
しかし、ここで確認すべきことがあります。
この「5日」は、カレンダー上の5日なのか。
それとも、業務日としての5日なのか。
この確認を曖昧にしたまま設計すると、バックアップジョブは正常に動いているのに、実は業務要件を満たしていない、という状態になることがあります。
「5日」と「5営業日」は違う
要件が次のようなものだったとします。
バックアップデータを5営業日分保存すること
この場合、単純に保持期間を5日に設定してよいとは限りません。
なぜなら、多くのバックアップ製品やクラウドサービスの保持期間は、営業日ではなく、カレンダー上の日数ベースで管理されるからです。
AWS Backupを例にすると、バックアップのライフサイクルでは、リカバリポイントを作成後、何日で削除するかを指定します。
つまり、基本的には「作成後なん日」という考え方です。
土日祝日や会社独自の休日カレンダーを考慮して保持期間を調整する。
こうした営業日ベースの世代管理を、標準の保持期間設定だけで実現できるとは限りません。
AWS Backupではスケジュール設定により、取得する曜日や時間を制御することはできます。
しかしこれはあくまで「いつバックアップを取得するか」の話です。「何営業日分のバックアップを保持するか」とは別の話です。
ここを混同すると、設計ミスになります。
土日や大型連休をまたぐと、要件未達になることがある
たとえば、バックアップを毎日取得し、保持期間を5日に設定したとします。
土日をまたぐと、保持されているバックアップの中に土日分が含まれます。
その結果、業務日として見ると、5営業日分ではなく3営業日分程度しか残っていない、ということが起こり得ます。
さらに、年末年始、ゴールデンウィーク、会社独自の休業日を挟む場合はもっと問題が大きくなります。
5日間の連休がある場合、保持期間を5日にしていると、連休前に取得したバックアップが連休明け時点で削除対象になっている可能性があります。
システム上は、保持期間5日で正しく動いている。バックアップジョブも正常終了している。リカバリポイントも存在している。
それでも、業務要件としての「5営業日分保存」は満たせていない可能性があります。
障害が起きているわけではありません。
ジョブが失敗しているわけでもありません。製品の不具合でもありません。
ただ、要件の解釈と製品仕様がずれている。その結果、設計として不足している状態になります。
バックアップ要件で確認すべきこと
バックアップ保存期限の要件が出てきたら、少なくとも次の点は確認する必要があります。
- 保存期限の「日」はカレンダー上の日数か、営業日か
- 土日祝日、年末年始、大型連休をどう扱うか
- 必要なのは「日数保持」なのか「世代保持」なのか
- 復旧時に必要なのは、直近何営業日分なのか、特定時点なのか
- 月次・年次・決算期など、長期保持が別途必要か
特に重要なのは、次の3つは同じ意味ではないということです。
- 5日保持：期間の話
- 5世代保持：バックアップ取得回数の話
- 5営業日分保持：休日カレンダーを考慮した復旧可能時点の話
似ています。しかし、設計上は別物です。この違いを曖昧にしたまま詳細設計に入ると、後工程で問題になります。
また、要件の言葉をそのまま受け取らず、製品仕様にぶつけるための問いに変換する習慣も重要です。
たとえば、次のように考えます。
現実的な３つの対策
休日カレンダーを考慮した世代管理機能がない場合、現実的な対策は大きく3つです。
1 保持期間を長めに設定する
5営業日分を確実に残したいのであれば、土日祝日や大型連休を考慮して、10日、14日など余裕を持った保持期間にする。
これで要件を満たせるなら、構成はシンプルです。
ただし、バックアップ容量が増え、ストレージコストも増えます。
2 バックアップ取得はAWS Backupなどに任せ、世代管理をジョブ管理側で制御する
営業日、祝日、会社休日に柔軟に対応しやすい一方で、ジョブ設計、運用設計、監視、試験項目が増えます。
3 AWS CLIやLambdaなどを使って、独自に削除・保持制御を実装する
追加のジョブ管理製品なしで柔軟に制御できますが、スクリプト開発、試験、保守、誤削除防止の設計が必要になります。
特に削除処理を独自に作る場合、単に不要なバックアップを削除すればよいわけではありません。
誤削除防止、削除ログ、削除失敗時の検知、復旧テストまで含めて設計する必要があります。
要件・製品仕様・運用仕様のズレは、次のように整理すると分かりやすくなります。
これは詳細設計で見つけるべき論点である
今回の話は、バックアップ設計だけの話ではありません。
詳細設計で考えるべきことの典型例です。
基本設計で「バックアップを5営業日分保存する」と書くことはできます。しかし詳細設計ではそこで終わりません。
実際に採用する製品やサービスで、
その要件をどう実現するのか。
標準機能で実現できるのか。
設定だけで足りるのか。
運用で補う必要があるのか。
スクリプトやジョブ管理が必要なのか。
その場合、監視、ログ、異常時対応、試験はどうするのか。
ここまで確認して、初めて設計として実装可能になります。
詳細設計書にはパラメータを書く必要がありますが、パラメータだけでは弱いです。
「保持期間：14日」とだけ書かれていても、なぜ14日なのかが分かりません。
本来はこういう根拠が必要です。
要件は5営業日分の保持。標準機能では営業日単位の保持制御ができないため、土日祝日および大型連休を考慮し、保持期間を14日に設定する。これにより、通常の土日祝日を含む期間でも5営業日分のリカバリポイントを保持する。
こう書いておけば、レビューでも説明できます。
運用担当にも伝わります。テスト担当も、何を確認すべきか分かります。
後から気づくと、設計書の修正、スクリプト追加、試験項目の追加、運用手順書の修正、顧客説明、コスト再見積もりが発生します。
一つひとつは小さく見えても、後工程では明確な手戻りです。
詳細設計とは、パラメータシートを埋める作業ではありません。
基本設計で決めた内容を、製品仕様、制約、運用条件に照らして、構築できる形、試せる形、運用できる形に落とし込む工程です。
まとめ
「5日保存」は、単純にバックアップソフトへ5日と設定すればよい、という話ではありません。
その5日がカレンダー上の日数なのか、営業日なのか。土日祝日や大型連休をどう扱うのか。何世代必要なのか。どの時点に復旧できる必要があるのか。これを確認しないまま設計すると、バックアップジョブは正常でも、業務要件を満たせない可能性があります。
バックアップは、取れていればよいわけではありません。必要な時点に、必要な期間分、確実に戻せること。そこまで確認して、初めてバックアップ要件を満たしていると言えます。
こういうズレを構築前に見つけるのが、詳細設計の仕事です。
この考え方については、以下の記事でも整理しています。
〖後編②〗詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程
シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。
コメント