前回の記事では、「止めないシステム」が守っているのはサーバーではなく、業務の流れだと整理しました。
前回の内容を軽く振り返ると、
- サーバーが落ちないこと
- DBが起動していること
- クラスタが組まれていること
もちろん、どれも大事です。
でも、それだけでは「業務が止まらない」とは言い切れません。
- ユーザーが操作を続けられるのか
- 注文や決済のデータを失わないのか
- 障害が起きたあと、安全に戻せるのか
- メンテナンスや障害対応を、運用として続けられるのか
可用性設計で本当に見たいのは、そこです。
今回は、前回の「業務の流れを守る」という考え方を、Oracle Maximum Availability Architecture（MAA）に当てはめて見ていこうと思います。
ちなみにMAAは、Oracleが公開している高可用性・データ保護・災害復旧のためのリファレンスアーキテクチャとベストプラクティスの体系です。
特定の構成を唯一の正解として扱うのではなく、業務を「止めない・失わない・戻せる」ために、可用性設計をどう分解して考えるかを見るための地図として読んでいきます。
MAAは、製品名の一覧？
MAAの話を聞くと、最初は製品や機能の一覧に見えるかもしれません。
たとえば、Oracle Databaseの高可用性まわりでは、次のような名前が出てきます。
- Oracle RAC
- Oracle Data Guard
- Oracle Active Data Guard
- RMAN
- Flashback
- Application Continuity
- GoldenGate
この並びだけを見ると、
「結局、どれを使えばいいの？」
「全部入れれば止まらないの？」
「Bronze、Silver、Gold、Platinum、Diamondって何のランク？」
となりがちです。
でも、MAAを読むときに最初に見るべきなのは、製品名ではありません。
まず見るべきなのは、
その技術が、どのリスクを小さくするためにあるのか
です。
まずは3つに分けて見る
可用性設計は、ざっくり言うと次の3つに分けると見やすくなります。
止めない
障害やメンテナンス中でも、業務影響を小さくする
失わない
障害が起きたとき、データ損失をどこまで抑えるか決める
戻せる
壊れた状態、誤操作、災害から安全に復旧できるようにする
この3つは似ていますが、同じではありません。
たとえば、システムがすぐに切り替わっても、直前のデータが失われていたら困る業務があります。
逆に、データは守れていても、復旧手順が複雑すぎて業務再開まで時間がかかることもあります。
バックアップがあっても、戻したあとの整合性確認や業務再開判断ができなければ、「戻せる」とは言いにくいです。
つまり、可用性設計では
- 止まる時間をどう減らすか
- 失うデータをどう減らすか
- 壊れた状態からどう戻すか
を分けて考える必要があります。
MAAで見ると、技術の役割が分かりやすくなる
MAAをこの観点で見ると、少し読みやすくなります。
たとえば、ざっくり言うとこんな見方です。(もちろん、実際の役割は構成や要件によって重なります。ここでは、まず読み方をつかむために、かなり大きく分けています。)
| 観点 | 見たいこと | 関係する技術の例 |
|---|---|---|
| 止めない | 障害やメンテナンス時の停止時間をどう小さくするか | RAC、Application Continuity など |
| 失わない | 障害時のデータ損失をどう抑えるか | Data Guard、Active Data Guard など |
| 戻せる | 誤操作、破損、障害からどう復旧するか | RMAN、Flashback、Recovery Appliance、バックアップ/リカバリ関連の仕組みなど |
| 続けられる | その構成を運用・監視・変更し続けられるか | パッチ適用、構成変更、定期フェイルオーバーテスト、DR訓練、ライフサイクル運用など |
ここで大事なのは、技術名を丸暗記することではありません。
「RACを入れれば十分」
「Data Guardがあれば安心」
「GoldenGateを入れれば解決」
という見方ではなく、
それぞれが、どの障害シナリオに対する守りなのか
を見ることです。
Bronze〜Diamondは「強さランキング」ではない
MAAでは、Bronze、Silver、Gold、Platinum、Diamond といった段階でリファレンス・アーキテクチャが整理されます。
この名前だけを見ると、つい
「Diamondが一番強いなら、全部Diamondにすればいいのでは？」
と思ってしまうかもしれません。
でも、可用性設計では、上位の構成ほど常に正解というわけではありません。
求める継続性が高くなるほど、一般的には次のものも重くなります。
- 構成の複雑さ
- 設計・検証のコスト
- 運用スキルの要求
- 監視や切替手順の整備
- アプリケーション側の考慮
つまり、Tierは「偉さ」ではなく、どこまで守る必要があるかを考える段階として見るのがよさそうです。
MAAではそれぞれのTierごとに、
想定する業務要件や可用性目標に応じたリファレンスアーキテクチャが示されています。
Diamond
Platinum
Gold
Silver
Bronze
上に行くほど「偉い」ではなく、
求める継続性が厳しくなる。
その分、
構成・運用・コスト・検証も重くなる。
たとえば、社内の参照系システムと、決済システムでは、止まったときの影響が違います。
同じ「5分止まる」でも、業務影響はまったく同じではありません。
だからこそ、最初に決めるべきなのは「どの技術を使うか」ではなく、
この業務は、どこまで止められないのか
どこまでデータを失えないのか
どの時間までに戻せないと困るのか
です。
“全部入り”より、“何を守るか”を先に決める
高可用性の話をしていると、つい構成を強くしたくなります。
- クラスタを組む
- スタンバイを置く
- 遠隔地にも複製する
- バックアップを取る
- アプリケーション側で再試行する
どれも重要な選択肢です。
ただし、全部を入れれば自動的に正解になるわけではありません。
設計で大事なのは、先に守るものを決めることです。
守りたい業務は何か
↓
RTO（復旧までに許容できる時間）
↓
RPO（失ってよいデータの範囲）
↓
どの時点まで戻せればよいか
↓
そのために必要な構成を選ぶ
この順番を逆にすると、技術から設計を始めてしまいます。
MAAは、「この機能があるから使う」ではなく、「このリスクを小さくしたいから、この技術を検討する」の順番で読むと、かなり見通しがよくなります。
まとめ：MAAは、“何を守るか”から読む
MAAは、製品名の一覧として見ると少し難しく見えます。
でも、
- 止めない
- 失わない
- 戻せる
- 運用し続ける
という観点で分解すると、各技術が何を守るためにあるのかが見えやすくなります。
大事なのは、どの技術が一番強いかではありません。
- 自分のシステムでは、何を守る必要があるのか
- どの障害シナリオに備えたいのか
- どこまでの停止、データ損失、復旧時間なら業務として受け入れられるのか
そこを考えるための地図として、MAAを読むと全体像が見えてきます。
次は、この地図をもう少し具体的にして、RTO/RPOという数字で見ていきます。
- 「RTO 5分」と聞いたとき、それは本当に現実的なのか
- どこまで設計すれば、その数字を守れそうなのか
そのあたりを整理したいと思います。
参考資料
- Oracle Maximum Availability Architecture
https://www.oracle.com/database/technologies/maximum-availability-architecture/ - Oracle AI Database MAA Best Practices
https://www.oracle.com/database/technologies/high-availability/oracle-database-maa-best-practices.html - Oracle MAA Reference Architectures
https://docs.oracle.com/en/database/oracle/oracle-database/19/haiad/maa_overview.html
免責
本記事は筆者個人の見解であり、所属組織の公式見解ではありません。筆者はOracleに所属していますが、本記事は公開情報をもとに、可用性設計の観点で自分なりに整理したものです。製品・サービスの仕様は変更される可能性があるため、最終的な判断は公式ドキュメントをご確認ください。