要約

  • AtlasのBackup Compliance Policyはプロジェクト全体に最低限のバックアップ要件を適用する。所有者を含め、保護中のスナップショットの削除や作成後の保存期間短縮はできない。
  • 対象クラスターを終了しても、既存のスナップショットはポリシーに従って残る。保護期間の後に設ける追加保存期間では、適切な権限を持つ利用者が削除できる。

所有者の肩書が通用しない場面

管理画面で「所有者」と呼ばれると、最後は自分で片づけられる気がする。MongoDB AtlasのBackup Compliance Policyは、その期待に冷静な返事をする。保護されたバックアップを消す場面では、その肩書にも特別席はない。

MongoDBの説明によれば、ポリシーを有効にすると、役割にかかわらず保護中のスナップショットを削除できない。撮影済みのものについて保存期間を短くすることも、Cloud Backupを無効にすることも制限される。個別クラスターの要件をプロジェクトの最低基準より下げる操作も認められない。

この不自由さには買う理由がある。管理者が急いで環境を整理したとき、復元用の履歴まで一度に失いたくない。管理者のアカウントを奪った相手にも、同じ履歴を自由に処分させたくない。そのためには、普段の所有者自身も一定の削除権限を手放すことになる。

MongoDBは、その結果としてバックアップの削除や保存期間短縮によるコスト削減が制約されることを明記している。保護の強さを承認する会議には、残る保存費を引き受ける人も呼ぶべきだ。

試験環境もプロジェクトの約束を相続する

文書が挙げる適用条件はM10以上の専用クラスターであり、ここではAtlas Coreの該当環境を扱う。ポリシーはプロジェクト単位だ。既存クラスターは最低要件を満たすように調整され、新しいクラスターにも適用される。個別にさらに厳しい保存基準を選ぶ余地はある。

このため、短い試験をどこで動かすかが費用の決定にもなる。長期保存を求めるプロジェクトに短命な検証サービスを置けば、検証が終わった後にもバックアップの約束が続き得る。実験期間と履歴の保存期間は、同じカレンダーには収まらない。

将来のバックアップ頻度は、プロジェクトの最低要件を守る範囲で変えられる。ただし頻度を落とした効果は今後の分に限られ、既存の操作ログは元の期間に従う。保護ポリシーを変更しても、既に受け入れた過去の保存日程をまとめて短縮できるわけではない。

したがって節約には、今後増やす約束を見直す仕事と、既に残っている約束を満了まで管理する仕事がある。両方を「バックアップ削減」の一言で済ませると、担当者は存在しない近道を探すことになる。

クラスターの終わりは履歴の終わりとずれる

クラスター終了の手順では、保護ポリシーが有効なら、終了後も既存のスナップショットがバックアップ方針に従って保持される。一方、保護ポリシーなしでCloud Backupを使う場合には、終了時に既存スナップショットを残す選択肢がある。Cloud Backupを無効にしている場合、その選択肢はない。

Atlas Coreでは、特定時点への復元に使う操作ログも、復元に利用できなくなるまで静的な状態で保存される。残るのは既に記録された履歴だ。終了したデータベースが新たな業務処理を続ける仕組みではない。

保存した履歴は管理上の居場所も必要とする。ポリシーの下でスナップショットが残るプロジェクトは削除できず、全プロジェクトを削除できなければ組織も削除できない。終了したクラスター名はスナップショットの識別に使われるため、同名のクラスターを作れないとも文書にある。

クラスターの稼働時間に対する料金と、残ったバックアップの保存料は別の対象に付く。終了後も履歴の費用が発生することを、終了した計算資源が動き続ける話にすり替えると、必要な管理が見えなくなる。残る日程と請求を誰に渡すかが、ここでの仕事だ。

空っぽという言葉にも条件がある

ポリシーの無効化には、指定されたセキュリティーまたは法務の担当者がサポートを申請し、詳細な確認を受け、MongoDB Supportが承認する経路がある。その後、プロジェクト所有者が無効化できる。プロジェクトを管理する役割と、申請を出す資格は分かれている。

例外は空のプロジェクトだ。稼働中のクラスターも、一時停止中のクラスターも、終了済みクラスターから残るスナップショットもない場合、組織所有者またはプロジェクト所有者が無効化できる。稼働一覧が白紙になっただけでは、保存済みの履歴がこの条件を満たさない。

指定担当者の連絡先も重要になる。設定には氏名とサポートポータルで使うメールアドレスを登録し、誤ったアドレスはSupportと修正する。保護期間が社員の在籍期間を超えるなら、担当の交代は手順の一部として残す必要がある。公開資料には個別顧客の処理日数がなく、必要な待ち時間を一律には計算できない。

長く置くことと、消せなくすること

追加スナップショット保存では、保護期間を過ぎてもスナップショットを残せる。この追加期間に入ると、適切な役割を持つ利用者は削除できる。追加期間の終了時にはAtlasが自動的に削除する。

つまり同じ一つのコピーが、保護中の履歴から、必要に応じて削除できる履歴へ移る。保存の総日数だけを報告すれば、この権限の変化が抜け落ちる。管理者による削除への備えが目的なら保護の終了日を、後からデータを参照する余地も必要なら追加保存の終了日を、それぞれ把握したい。

保存ルールが重なる場合も日付は単純ではない。MongoDBの例では、毎日のスナップショットを2日間、土曜日の週次スナップショットを3週間残す設定が重なると、同じスナップショットには長い方の週次保存が適用される。この例の期間を一般の初期設定と取り違えず、どのルールが各履歴を保持しているかを読む必要がある。

枚数からは請求を読めない

専用クラスターの料金文書は、通常のCloud Backupsが多くの場合増分方式で、保存事業者の報告する容量とリージョンを基に計算されると説明する。GB月の料金を日別のGB-day項目で示すことは、同じ費用の二重計上を意味しない。継続的バックアップは別の料金体系で、スナップショットと内部操作ログを合わせて扱う。

構成変更、障害時の切り替え、基盤クラウドの保守などによって完全スナップショットが複数必要になる場合もある。逆に、一つ消しても他のスナップショットが参照するデータは残る。枚数と現在のデータベース容量を掛けるだけでは、金額も削減額も出ない。実際の請求対象容量、保存地域、期限と適用料金が必要だ。

購入時に決めるべきなのは、その情報を誰が追い続けるかである。未来の削除を止める仕組みは、設定した担当者より長く働くことがある。会社の引き継ぎも、それに付き合える長さで設計しておきたい。