クラウド時代の従来のバックアップ戦略の再考

クラウド コンピューティングは、IT 環境とそのバックアップ戦略および実行に技術的な変化をもたらしました。確立されたローカル バックアップ ルールとパターンに依存するのは便利ですが、リスクを伴います。これらのバックアップ戦略は、ローカル環境における重要な問題に効果的に対処できるため、人気があります。ただし、これらのソリューションをそのままクラウド環境に移行することが依然として意味を持ち、適用可能であり、コスト効率が良いという保証はありません。

広く使用されている 2 つのローカル バックアップ戦略 (Grandfather-Father-Son と 3-2-1) を見て、パブリック クラウド環境でもそれが意味をなすかどうかを検討してみましょう。

「3-2-1」バックアップ戦略

バックアップの世界で最も有名な戦略の 1 つである 3-2-1 パターンは、次の 3 つの要素で構成されています。

• データのコピーを（少なくとも） 3 つ保存してください。
• バックアップを (少なくとも) 2 種類のバックアップ メディアに保存します。
• 少なくとも 1 つのコピーをオフサイトに保管します。

アーキテクトは、この戦略をクラウド設計に単純にコピーするのではなく、次のように自問する必要があります。オンプレミス環境でこのパターンの規律がなぜそれほど重要なのか。エンジニアや建築家はそれらを使って何を達成したいのでしょうか?

クラウド機能を備えたビンテージバックアップコンセプト

従来のバックアップ概念とクラウド機能はこれを反映しています。パターンのルールは左の列にリストされています。中央の列には、このパターンのルールにつながるニーズと要件が表示されます。最後に、右端の列はクラウド時代にとって重要であり、Amazon の AWS、Google の GCP、Microsoft の Azure などのパブリック クラウドの変更点がリストされています。

数十年にわたり、サービス プロバイダーや企業は、場所に応じて慎重に選択されたデータ センターにサーバーを設置してきました。彼らは洪水や土砂崩れなどの環境災害のリスクを軽減したいと考えている。多くの中小規模の公的機関や民間組織、中小企業では、依然としてオフィスビルの地下にサーバーを設置している場合があります。

火災、地震、トラックの建物への衝突など、これらの出来事はすべて、サーバー ルームを含む建物全体を破壊する可能性があります。この場合、推奨される「オフサイト バックアップ コピー」が唯一の救世主となります。しかし、クラウド時代において、このようなバックアップはまだ意味があるのでしょうか?

クラウド時代では「オンサイト」と「オフサイト」の概念は変化しましたが、常に残るリスクが 1 つあります。それは、サイトをどれだけ慎重に選択し、物理的なセキュリティをどれだけ真剣に考慮しても、選択した建物に飛行機が墜落したり、火災 (およびその後の消火活動) によってデータ センターが破壊されたりする可能性があるということです。実稼働ワークロードを 1 つのデータ センターに配置し、少なくとも別の 1 つのデータ センターにバックアップを用意することは依然として理にかなっています。 AWS クロスリージョンレプリケーションや Azure の地理的冗長ストレージなどの機能により、中小企業でも地域または国の災害に備えることができます。

「2 種類のバックアップ メディア」ルールの必要性は、あまり明らかではありません。しかし、企業がバックアップをテープや光ディスクに保存していた時代を振り返って、何が問題になる可能性があるかを見てみましょう。まず、エンジニアは利便性のためにすべてのバックアップを単一のメディアに保存することを決定する場合があります。このメディアに欠陥があったり紛失したりすると、すべてのバックアップが失われます。 1 つのメディアでは明らかにリスクが高すぎますが、それぞれが数年または数十年使用できる 3 つのテープを使用する場合のリスクはどの程度でしょうか。

説明を簡単にするために、1 年間にバックアップ テープが失われる確率は 0.1% であり、バックアップは 3 つあると仮定します。そうすると、3 つのバックアップすべてが失われる確率は 0.1%*0.1%*0.1%=0.001% になります。この値が高すぎると思われる場合は、さらに 3 つのバックアップを追加できます。 1 年以内に 6 つのバックアップがすべて失われる確率は 0.000001% です。比較すると、生涯で雷に打たれる確率は 0.0065% です。このような可能性を考慮すると、3 本または 6 本のテープが同時に失われるリスクを軽減するために投資しますか?

これは、よくある間違い、つまり、これらのイベントは互いに無関係であると想定しているが、実際にはそうではない（統計における従属変数と独立変数）という仮定に基づいているため、難しい質問です。 1 本のテープが材料の欠陥によって損傷した場合、同じ工場の同じ機械で製造されたすべてのテープに同じ欠陥が生じる可能性があります。したがって、ローカル環境では、2 種類のバックアップ メディアの使用を要求することは、すべてのメディアが同時に破損するリスクを軽減するための便利で実装しやすい方法です。しかし、このルールはクラウド バックアップにどのように役立つのでしょうか?

答えは「複雑だ」です。 S3 オブジェクト ストレージの耐久性サービス レベル契約は、1 年間で 99.99999999999% です。ただし、これはサービス レベル契約 (SLA) であるため、サービス プロバイダーを信頼する必要があり、技術的な設計と実装を検証することはできません。クラウド プロバイダーが SLA を履行できない場合、あなたの会社は倒産する可能性がありますが、クラウド プロバイダーは倒産しません。クラウド プロバイダーはクラウド サービスの料金に少額の割引を提供する場合がありますが、データが失われた場合、その割引は無意味になります。私の個人的な意見としては、「2 つのメディア」ルールをクラウドで実現するのはほぼ不可能ですが、サービス レベル契約を信頼する場合、このルールは不要です。

「3-2-1」の「3」は、データの 3 つのバージョンを保持することを意味します。たとえば、異なる時点で 2 つのバックアップを作成します。これらの要件を超えるこの戦略の一般的なバリエーションは、もう 1 つのよく知られたバックアップ戦略である「Grandfather-Father-Son」パターンです。

祖父・父・息子戦略を理解する

このデータ バックアップ モードの一般的な実装:

• 毎週バックアップを作成する（親）
• 毎日バックアップを実行する（サブ）
• 毎月 1 つのバックアップを保持する (例外あり)

祖父・父・息子のバックアップコンセプトの月間プランの例

毎週の「Father」バックアップ、毎月の「Grandfather」バックアップ、および毎日の「Child」バックアップを含むスケジュールがどのようになるかを示します。

「Grandfather-Father-Son」バックアップ戦略は、企業がバックアップを必要とするさまざまなシナリオをカバーする複雑な概念です。最初の状況は操作上のエラーに関係します。理論上、管理者が誤って運用データベースを削除することは決してありません。

同様に、エンジニアはテスト システムの構成変更を本番システムに適用する前に、慎重に確認する必要があります。しかし、現実が理論と異なる場合、エンジニアはサーバーとコンポーネントを混乱前の状態に迅速にロールバックする必要があり、解決策は前日のバックアップなどの最新の更新を使用することです。 「子」バックアップはこの要件を満たすことができます。

ランサムウェア集団や政府が支援するハッカーが IT 環境に侵入した場合、数日または数週間検出されない可能性があります。したがって、昨日のバックアップはあまり役に立ちません。代わりに、エンジニアは構成とアプリケーション (ビジネス データではない) を、侵入が発生していなかった数週間前の状態にロールバックする必要がありました。この場合、「祖父」バックアップが理想的なソリューションです。

上記の 2 つのシナリオ例は、クラウド環境にも不可欠です。違いは、オブジェクトのバージョン管理やポイントインタイムリカバリなど、クラウド内の新しいデータ バックアップ機能にあります。

ポイントインタイムリカバリ (PITR) はさまざまなデータベースで以前から利用されてきましたが、パブリッククラウドの登場により、企業のバックアップ戦略への導入と統合が加速しています。 PITR は、管理者やエンジニアがデータベースの状態を特定の期間内 (先週や 1 か月など) の任意の時点にロールバックできるようにするタイム トラベル ツールです。 PITR が利用可能で有効になっている場合、毎日および毎週のバックアップは不要になります。特定のクラウド サービスの具体的な要件、リスク許容度、機能によっては、企業は PITR に加えて「適用除外」バックアップを必要とする場合があります。

オブジェクトのバージョン管理は、オブジェクト ストレージに特に役立つもう 1 つの概念です。ユーザー、スクリプト、またはアプリケーションがオブジェクトを新しいバージョンに置き換えると、クラウドは定義された期間、古いバージョンを保持します。この間、追加のバックアップ (毎日または毎週など) は必要ありませんが、アーキテクトは追加の長期バックアップを構成する必要がある場合があります。

高度なクラウド バックアップ機能の例 – Azure Cosmos DB (左) と AWS S3 (右)

従来のバックアップルールは現在でも適用されています

クラウドでのバックアップの構成がこれまでになく簡単になりました。数回クリックするだけで完了しますが、ストレージに多額の費用がかかると、ビジネスケースが台無しになる可能性があります。コストの急騰を防ぐために、アーキテクトはクラウド バックアップ戦略を策定する際にコストと利益の関係を考慮する必要があります。毎月のバックアップを 1 年間保存すると、バックアップは 12 個になります。毎週のバックアップを 1 か月間保存すると、バックアップがさらに 4 つ追加されます。次に、毎日バックアップを厳密に実行し、それを 1 週間保存すると、さらに 7 つのバックアップが追加されます。したがって、バックアップ ストレージは実稼働ストレージの 21 倍のサイズになります。

「3-2-1」や「Grandfather-Father-Son」などの確立された従来のバックアップ ルールは、今日のクラウド アーキテクチャでも依然として有効です。それらの重要性は、特定のルールやテクニックからではなく、戦略の背後にある要件から生じます。しかし、クラウドでは冗長性やクラウド バックアップ機能など、ほんの数年前にはほとんどの中小企業が夢にも思わなかった新しい機能も可能になります。

したがって、クラウド エンジニアの仕事は、以前のモデルをコピーすることではありません。過去の要件のうちまだ意味のある部分に対処するには、今日のクラウド機能を使用する必要があります。これにより、IT 部門はコスト効率が高くプロアクティブなクラウド バックアップ戦略を定義し、実行できるようになります。