Bronze、Silver、Gold、Platinum、Diamond
この図は、Oracleが公開する高可用性・データ保護・災害復旧の設計体系「Oracle Maximum Availability Architecture（MAA）」のTierを示したものです。
この並びを見ると、Diamondがいちばんよい構成だと思ってしまいます。名前だけを見れば、Bronzeは入門向けで、そこから段階的に上を目指していく順位表のようにも見えるからです。
ただ、可用性設計では、上に行くことがそのまま正解になるとは限りません。
前回の記事「RTO 5分を成立させるまでの長い話」では、「RTO 5分」という数字を決めるだけでは復旧要件は完成しない、という話をしました。
障害を検知してからの5分なのか、データベースが利用可能になるまでの5分なのか、アプリケーションを含めて業務を再開できるまでの5分なのかによって、必要な設計は大きく変わります。
この考え方をOracle MAAのBronze〜Diamondに当てはめると、Tierは「どの構成がいちばん強いか」を決める順位表ではなく、求める復旧目標に応じて、どこまで備えるかを考えるための地図として見えてきます。
「RTO 5分ならGold」で決めてよいのか
たとえば、要件に「RTO 5分」と書かれていたとします。
この数字だけを見て、Goldを選べばよいと結論を出すことはできません。まず確認したいのは、その5分がどの障害を対象にしているかです。
データベースプロセスの停止とサーバー全体の停止では備え方が異なります。データセンターが利用できなくなるケースまで含めるなら、さらに広い範囲で設計しなければなりません。
また、復旧の終点も明確にする必要があります。
例えば、データベースが利用可能になれば復旧完了とするのか、利用者が再び業務を続けられる状態までを含めるのかによって、必要な対策は変わります。
つまり、同じ「5分」でも、対象とする障害と復旧の終点が違えば、必要な構成も変わるということです。
そのため、MAA Tierを見るときは、RTO/RPOの数字だけではなく、次の観点を重ねて考える必要があります。
| 観点 | 考えたいこと |
|---|---|
| 停止時間 | どの障害から、どの状態まで、何分で戻したいのか |
| データ保護 | どの程度のデータ損失まで許容できるのか |
| 障害範囲 | プロセス、サーバー、サイト、リージョンのどこまで備えるのか |
| 運用 | 切替、監視、テスト、自動化を継続できるのか |
Bronze〜Diamondは、この4つの観点を重ねながら読むと、それぞれの設計段階が何を目的としているのかを理解しやすくなります。
実際のシステムは、Tierの境界をまたいでいる
ここで注意したいのは、すべてのシステムをBronze、Silver、Gold、Platinum、Diamondのいずれかに完全一致させることが目的ではない、という点です。
実際の構成は、業務要件、既存環境、利用できるサービス、コスト、運用体制などの制約を受けます。一つのシステムの中でも、データベースとアプリケーション、周辺システムで異なる復旧目標を持つことがあります。
そのため、Tierへの適合自体をゴールにするのではなく、自分たちの構成とMAAを比較することで、設計上の差分を確認する使い方が現実的です。
たとえば、どの障害には対応できているのか、どこに手動作業が残っているのか、データベースの復旧後にアプリケーションや業務の再開が遅れる可能性はないか、といった点を確認できます。
MAAのTierと完全に一致しない構成が、直ちに誤りになるわけではありません。ただし、どこが異なり、その違いによってどのようなリスクや運用負荷が残るのかは、要件に照らして説明できるようにしておく必要があります。
MAA Tierはシステムにラベルを付けるためではなく、現在地を把握し、足りない対策と過剰な対策の両方を見つけるためのものさしとして使えます。
上位Tierには、上位Tierなりの重さがある
Diamondに近づくほど、より短い停止時間や、より広い障害範囲への対応を目指す設計になります。
一方で、必要になるのは製品や機能に加えて、監視、切替、自動化、復旧テスト、アプリケーションの再接続、障害時の判断手順など、設計を支える運用も複雑になります。
冗長構成を用意しても、障害を検知できなければ切替は始まりませんし、データベースが切り替わっても、アプリケーションが再接続できなければ、利用者から見たサービスは復旧していないということになります。
また、災害対策環境を用意していても、実際の切替を訓練していなければ、想定した時間で業務を再開できるとは限りません。
Tierを上げることは、保護の範囲を広げるだけでなく、その状態を維持する責任を引き受けることでもあります。構成が高度になるほど、運用する人、手順、テスト、コストまで含めて設計する必要があります。
Bronzeは妥協案なのか
Bronzeという名前から、「最低限の構成」という印象を持つかもしれません。
しかし、すべてのシステムが障害発生後すぐに復旧しなければならないということではないと思います。
システムの中には一定時間の停止を許容できるシステムや、バックアップから復旧するための時間を確保できるシステムもあります。
そのようなシステムに高度で複雑な構成を導入すれば、得られる保護は増えるかもしれない一方で、運用負荷やコストまで含めると、その高度で複雑な構成が必ずしも全てのシステムにおいてバランスのよい設計になるとは限りません。
反対に、決済や受注のように、短い停止でも業務への影響が大きいシステムでは、バックアップからの手動復旧だけでは要件を満たせない可能性があります。
つまり、Bronzeが弱く、Diamondが強いという単純な話ではなく、重要なのは、業務への影響、許容できる停止時間やデータ損失、運用可能な体制に対して、設計が合っているかどうかです。
まとめ：Tierを選ぶ前に、守る対象を決める
Oracle MAAのBronze〜Diamondは、上から順番に採用すべき構成を並べた順位表ではなく、停止時間、データ保護、想定する障害範囲、運用負荷を整理し、自分たちの要件に合う設計を考えるための枠組みです。
「RTO 5分ならGold」と数字だけでTierを決めようとしていた場合は、いったん立ち止まり、その5分がどの障害を対象とし、どの業務を、どの状態まで戻す時間なのかを考えてみましょう。
Diamondが常に正解というわけでも、Bronzeが妥協案というわけでもありません。大切なのは、選んだ設計が要件に合い、障害時に実行でき、継続的に運用・検証できることです。
免責
本記事は筆者個人の見解であり、所属組織の公式見解ではありません。筆者はOracleに所属していますが、本記事は公開情報をもとに、可用性設計の観点で整理したものです。製品・サービスの仕様は変更される可能性があるため、最終的な判断は公式ドキュメントをご確認ください。