ヘッダーをスキップ
Oracle® Database高可用性概要
12cリリース1 (12.1)
B71280-03
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

2 高可用性およびデータ保護 - 要件からのアーキテクチャの取得

この章では、エンタープライズの高可用性要件を効果的に評価するためのフレームワークを示します。次の項で構成されます。

2.1 高可用性要件

Oracle Databaseに高可用性戦略を設計して実装する作業は、ビジネス影響分析を徹底的に実行し、原因が計画外停止であるか計画停止であるかによって、停止時間やデータ損失でエンタープライズにどのような影響があるかを確認することから始めます。エンタープライズが営利企業であるか、政府機関であるか、あるいは非営利団体であるかを意識しなくてよいように、ビジネス影響という言葉を使用しています。いずれの場合も、データ損失や停止時間は、エンタープライズの業務遂行能力に深刻な影響を及ぼします。高可用性の実現は、次のような重要な課題を伴います。

  • レガシー・システムの廃止

  • より高度で堅牢なシステムや設備への投資

  • この高可用性モデルに合せたITアーキテクチャと操作全体の再設計

  • 高可用性インフラストラクチャを最大限に利用するための既存アプリケーションの変更

  • ビジネス・プロセスの再設計

  • 人員の雇用およびトレーニング

ビジネス要件を分析した上で、様々な高可用性ソリューションの実装に必要な投資レベルを理解することで、ビジネス面と技術面の両方の目的を達成する高可用性アーキテクチャの開発が可能になります。

図2-1 可用性の高い企業の計画および実現

図2-1の説明が続きます
「図2-1 可用性の高い企業の計画および実現」の説明

2.2 高可用性要件を文書化する方法

この分析フレームワークは次の要素で構成されます。

2.2.1 ビジネス影響分析

厳密なビジネス影響分析では、次のことが行われます。

  • 組織内の重要なビジネス・プロセスの特定

  • 各ビジネス・プロセスに影響を与える計画外IT停止および計画IT停止の定量化可能な損失リスクの算出

  • 停止が与える影響の概略のまとめ

  • 基本的なビジネス機能、人的リソースおよびシステム・リソース、政府規制、内部および外部のビジネス依存関係の考慮

  • 豊富な知識を持つ経験豊かな人員とのインタビューで収集した客観的、主観的データの使用

  • ビジネス手法の履歴や財務報告書、ITシステム・ログなどの調査

ビジネス影響分析では、IT関連の停止の影響の重大度に基づいてビジネス・プロセスを分類します。たとえば、世界各地にチップ製造工場を持つ半導体製造業者について考えてみましょう。半導体製造業は、高生産量で償却される、巨額な財政投資を必要とする非常に競争の激しいビジネスです。工場管理で使用される人的リソース・アプリケーションは、工場の製造プロセスを制御するアプリケーションほどミッションクリティカルであるとみなされない傾向があります。製造をサポートするアプリケーションに障害が発生すると、その影響は生産レベルに及び、企業の決算報告に直接の影響が出ます。

同様に、経営コンサルティング企業では内部ナレッジ管理システムがミッションクリティカルであるとみなされる傾向があります。これは、クライアントを重視する企業のビジネスにとって、コンサルタントやナレッジ・ワーカーが内部調査にアクセスできることが基本であるためです。このようなシステムの停止時間のコストは、このビジネスにとってきわめて高くつきます。

2.2.2 停止時間のコスト

ビジネス影響分析を完全に実施すれば、計画外停止時間および計画停止時間のコストの定量化に必要な見通しが得られます。このコストは、高可用性の投資の優先付けに役立ち、停止時間のリスクを最小限に抑えるために選択する高可用性テクノロジに直接影響を与えるため、必ず理解しておく必要があります。

様々な業界の停止時間のコストをまとめた各種レポートが発行されています。コストは、仲買業務やクレジット・カード販売の1時間当たり数百万ドルから、荷物輸送サービスの1時間当たり数万ドルまで、多岐にわたります。

まさに驚くべき数字です。インターネットでは、ビジネスと何百万もの顧客を直接結び付けることができます。アプリケーションの停止時間によってこの結び付きは分断され、ビジネスと顧客が切り離されてしまいます。停止時間は収益の損失を生むだけでなく、カスタマ・リレーションシップ、競争力、法的義務、業界での評価、株主の信頼などにも悪影響を及ぼす可能性があります。

2.2.3 リカバリ時間目標

ビジネス影響分析では、リカバリ時間目標(RTO)とも呼ばれる、停止時間の許容範囲を決定します。RTOは、ITベースのビジネス・プロセスが停止しても、組織に受け入れがたい影響(経済的損失、顧客不満足、風評など)が生じない、最大時間として定義されます。RTOは、一般的に、ビジネス・プロセスまたは組織の許容停止時間に相当します。

RTO要件はビジネスのミッションクリティカル性によって左右されます。したがって、証券取引所を運営するシステムの場合、RTOはゼロまたはゼロに近い数値になります。

組織には、各種ビジネス・プロセスにまたがる様々なRTO要件があるものです。したがって、大規模なE-Commerce Webサイトの場合、高速のレスポンスが期待され、顧客のスイッチング・コストが非常に小さいため、E-Commerceの売上を押し上げるWebベースの顧客対応システムのRTOはゼロまたはゼロに近くなります。しかし、出荷や請求などのバックエンド業務をサポートするシステムのRTOはそれより長くてもかまいません。このようなバックエンド・システムが停止した場合は、一時的に手動操作に切り替えて、重大な影響が出るのを防ぐことができます。

E-Commerce Webサイトを介してすばやく注文を受けられること(RTO)のほうがRPOより重要です。失われたデータは後でリロードできるためです。

2.2.4 リカバリ・ポイント目標

ビジネス影響分析では、リカバリ・ポイント目標(RPO)とも呼ばれる、データ損失の許容範囲も決定します。RPOは、組織に損害を与えずに、ITベースのビジネス・プロセスで失うことのできる最大データ量です。RPOは、一般的に、ビジネス・プロセスまたは組織の許容データ損失量を計測します。このデータ損失は、通常、データ損失ゼロ、何秒分、何時間分または何日分のデータ損失というように、時間に換算して測定されます。

毎分数百万ドルに相当するトランザクションが発生する証券取引所では、データを失うわけにはいきません。したがって、RPOをゼロにする必要があります。E-Commerceの例について言えば、Webベースの販売システムではRPOがゼロであることが求められるわけではありませんが、顧客満足のためにはRPOを抑えることが不可欠です。ただし、バックエンドのマーチャンダイジング・システムおよび在庫更新システムでは、RPOが大きくなることもあります。失ったデータの再入力が可能であるためです。

2.2.5 管理性目標

管理性目標は、RPOやRTOよりも主観的です。これは、組織で使用できるスキル・セット、管理リソースおよびツールといった客観的な評価、および組織が高可用性アーキテクチャのすべての要素を正常に管理できる程度に起因します。RPOおよびRTOが停止時間やデータ損失に対する組織の許容差を測定するのと同様に、管理性目標はIT環境の複雑さに対する組織の許容差を測定します。複雑さがそれほど要求されない場合、高可用性を実現するには、管理が複雑な方法よりも単純な方法が好まれ、複雑な方法の方が積極的なRTOおよびRPO目標を達成できる場合でも当てはまります。管理性目標を理解すれば、組織で実現が可能と思われる事項と実現が実用的である事項とを区別する際に役立ちます。

2.2.6 総所有コストおよび投資利益率

総所有コスト(TCO)投資利益率(ROI)の目標を理解することは、組織のビジネス目標を達成する高可用性アーキテクチャを選択する際に不可欠です。TCOには、選択するソリューションの耐用年数におけるすべてのコスト(取得、実装、システム、ネットワーク、設備、スタッフ、トレーニングおよびサポートなど)が含まれます。同様に、ROIの計算では、指定の高可用性アーキテクチャで発生するすべての金銭的利益が算出されます。

たとえば、リモートのスタンバイ・サイトのITシステムおよびストレージがアイドル状態の高可用性アーキテクチャがあり、そのスタンバイ・システムで処理できるビジネス用途が他にないとします。このスタンバイ・サイトの投資利益率に含まれるのは、フェイルオーバー・シナリオで使用された場合に回避される停止時間関連のコストのみです。これを、スタンバイ・サイトのITシステムおよびストレージがスタンバイ・ロール(レポート作成や、ユーザー問合せのプライマリ・システムのオーバーヘッドをオフロードする場合または読取り/書込みワークロードを分散する場合など)のときに、生産的に使用できる別の高可用性アーキテクチャと比較します。そのようなアーキテクチャの投資利益率には、回避された停止時間のコストと、高可用性やデータ保護を可能にすると同時に、生産的に使用した場合に発生する金銭的利益の両方が含まれます。

2.3 アーキテクチャへの要件のマッピング

ビジネス影響分析を行うと、すでに把握していることが文書化されます。様々なアプリケーションやそれらをサポートするいくつものデータベースがありますが、エンタープライズにとっての重要度は、それぞれに異なります。停止したとしても、すぐさまエンタープライズに影響するわけではないアプリケーションにとっては、高可用性インフラストラクチャへの高額の投資も意味を成しません。では、何から始めたらよいのでしょうか。

ビジネス影響分析の結果により、エンタープライズ内のデータベースが、同じようなRTOおよびRPOの目標を持つ別のデータベースとグループ化されます。そのグループを、統制された高可用性参照アーキテクチャのセットにマップすると、必要なサービス・レベルに最大限近づけることが可能です。データベース間に依存性がある場合は、高可用性要件が最も厳しいデータベースとグループ化されることに注意してください。

2.3.1 Oracle MAA参照アーキテクチャ

Oracle MAAのベスト・プラクティスでは、4つの高可用性参照アーキテクチャを定義し、あらゆる規模や業種のエンタープライズで必要とされる可用性とデータ保護のすべての範囲に対応しています。このアーキテクチャ(または層)には、Platinum、Gold、SilverおよびBronzeが指定されています。これらは、図2-2に記載されているサービス・レベルに対応します。

図2-2 Oracle MAA参照アーキテクチャ

図2-2の説明が続きます
「図2-2 Oracle MAA参照アーキテクチャ」の説明

各層では異なるMAA参照アーキテクチャを使用して、Oracle高可用性機能の最適なセットがデプロイされ、指定されたサービス・レベルが、最小限のコストと複雑さで確実に達成されます。これらの層は、メンテナンス、移行またはその他の目的による計画停止のみでなく、データ破損、コンポーネント障害、システムやサイトの停止など、あらゆるタイプの計画外停止にも明示的に対応します。

2.3.2 Bronze参照アーキテクチャ

Bronze層は、単純な再起動やバックアップからのリストアができれば、可用性は十分に高いというデータベースに適しています。Bronze層は単一インスタンスのOracle Databaseに基づいており、そこに組み込まれているMAAベスト・プラクティスでは、Oracle Enterprise Editionの全ライセンスに含まれている、データ保護と高可用性のための数多くの機能が使用されます。Oracle Recovery Manager (RMAN)を使用してOracleに最適化されたバックアップによりデータが保護され、停止によってデータベースが再起動しないよう、可用性をリストアするために使用されます。

2.3.3 Silver参照アーキテクチャ

Silver層では、様々なタイプの計画メンテナンスのみでなく、データベース・インスタンスやサーバー障害の際に、停止時間を最小限またはゼロにする必要があるデータベースの高可用性のレベルが高くなります。Silver層では、クラスタリング・テクノロジ(Oracle RACまたはOracle RAC One Node)が追加されます。RMANにより、データベースに最適化されたバックアップが作成されてデータが保護され、停止によってクラスタが再起動しないよう、可用性がリストアされます。

2.3.4 Gold参照アーキテクチャ

Gold層では、単一点障害に対する脆弱性を許容できない、ビジネス上重要なアプリケーションのリスクが大幅に低くなります。この層では、データベース対応のレプリケーション・テクノロジ(Oracle Active Data GuardおよびOracle GoldenGate)が追加され、本番データベースのレプリカが1つ以上同期されて、リアル・タイムのデータ保護と可用性が実現されます。データベース対応のレプリケーションにより、ストレージ・レプリケーション・テクノロジで可能な範囲を超えて、高可用性とデータ保護が大幅に強化されます。すべてのレプリカが常時、積極的に使用されるため、投資利益率が向上すると同時に、コストも削減されます。

2.3.5 Platinum参照アーキテクチャ

Platinum層には、Oracle Database 12cの複数の新機能と、以前から使用されていた製品で、最新リリースにおいて拡張されたものが導入されています。アプリケーション・コンティニュイティはそうした機能のうちの1つで、処理中のトランザクションが確実にリプレイされるため、ユーザーは停止したことに気が付きません。Oracle Active Data Guard Far Syncは、距離にかかわらず、データ損失ゼロの保護を可能にします。Oracle GoldenGateは、停止時間ゼロのアップグレードと移行を実現するために拡張されています。グローバル・データ・サービスは、レプリケートされたデータベース環境における、自動サービス管理とワークロードのバランシングを目的としています。これらのテクノロジのいずれも、実装に追加の作業が必要ですが、停止時間やデータ損失が許されない、最も重要なアプリケーションにとっては十分な価値があります。

2.3.6 層ごとの高可用性およびデータ保護の属性

表2-1に、各層に固有の高可用性およびデータ保護の属性をまとめます。それぞれの層には、その前の層の機能がすべて含まれ、そのアーキテクチャ上に層を構築することで、対応範囲が広がった障害の領域に対処しています。各アーキテクチャに含まれる様々なコンポーネントや、達成されるサービス・レベルについては、別のトピックで説明します。

表2-1 層ごとの高可用性およびデータ保護の属性

停止クラス/高可用性層 計画外停止(ローカル・サイト) 計画メンテナンス データ保護 リカバリ不能なローカル停止および障害時リカバリ

Platinum

Platinum対応アプリケーションではアプリケーションの停止なし

アプリケーションの停止なし

包括的なランタイム検証と手動チェックの組合せ

Platinum対応アプリケーションではアプリケーションの停止なし、処理中のトランザクションを維持、データ損失ゼロ

Gold

包括的な高可用性と障害時リカバリ

すべてがローリングまたはオンライン

包括的なランタイム検証と手動チェックの組合せ

リアルタイム・フェイルオーバー、ゼロまたはゼロに近いデータ損失

Silver

自動フェイルオーバーを含む高可用性

一部ローリング、一部オンライン、一部オフライン

基本的なランタイム検証と手動チェックの組合せ

バックアップからのリストア、最後のバックアップ以降に生成されたデータを失う可能性

Bronze

単一インスタンス、リカバリ可能なインスタンスおよびサーバー障害での自動再起動

一部オンライン、大部分オフライン

基本的なランタイム検証と手動チェックの組合せ

バックアップからのリストア、最後のバックアップ以降に生成されたデータを失う可能性