高可用性概要およびベスト・プラクティス

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

Oracle Maximum Availability Architectureによって企業の高可用性要件を効果的に評価するフレームワークが提供される仕組みを学習するには、次のトピックを参照してください。

高可用性要件

Oracle Databaseに高可用性戦略を設計して実装する作業は、ビジネス影響分析を徹底的に実行し、原因が計画外停止であるか計画停止であるかによって、停止時間やデータ損失でエンタープライズにどのような影響があるかを確認することから始めます。

エンタープライズが営利企業であるか、政府機関であるか、あるいは非営利団体であるかを意識しなくてよいように、ビジネス影響という言葉を使用しています。いずれの場合も、データ損失や停止時間は、エンタープライズの業務遂行能力に深刻な影響を及ぼします。高可用性の実現は、次のような重要な課題を伴います。

レガシー・システムの廃止
より高度で堅牢なシステムや設備への投資
この高可用性モデルに合せたITアーキテクチャと操作全体の再設計
高可用性インフラストラクチャを最大限に利用するための既存アプリケーションの変更
ビジネス・プロセスの再設計
人員の雇用およびトレーニング
アプリケーション/データベースの一部また全体のOracle Public Cloudへの移動
連結、柔軟性、分離の適切なレベルでのバランス調整
既存のシステムおよびネットワーク・インフラストラクチャの機能と制限の把握

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

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

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

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

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

ビジネス影響分析

ビジネス影響分析では、IT関連の停止の影響の重大度に基づいてビジネス・プロセスを分類します。

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

組織内の重要なビジネス・プロセスの特定
各ビジネス・プロセスに影響を与える計画外IT停止および計画IT停止の定量化可能な損失リスクの算出
停止が与える影響の概略のまとめ
基本的なビジネス機能、人的リソースおよびシステム・リソース、政府規制、内部および外部のビジネス依存関係の考慮
豊富な知識を持つ経験豊かな人員とのインタビューで収集した客観的、主観的データの使用
ビジネス手法の履歴や財務報告書、ITシステム・ログなどの調査

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

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

同様に、E-Commerce会社は、Webサイトへの顧客のトラフィックに大きく依存して収益をあげています。サービスの中断や可用性の喪失が発生すると、顧客の操作性が損なわれ、競合他社に顧客を奪われてしまいます。このため、顧客のトラフィックの急増に対して既存のインフラストラクチャをスケーリングして対応できることを確認する必要があります。オンプレミスのハードウェアを使用したり、クラウドを移動することでは、システムが常に稼働し続けるようにできない場合があります。

停止時間のコスト

ビジネス影響分析を完全に実施すれば、計画外停止時間および計画停止時間のコストの定量化に必要な見通しが得られます。

このコストは、高可用性の投資の優先付けに役立ち、停止時間のリスクを最小限に抑えるために選択する高可用性テクノロジに直接影響を与えるため、必ず理解しておく必要があります。

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

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

リカバリ時間目標

ビジネス影響分析では、リカバリ時間目標(RTO)とも呼ばれる、停止時間の許容範囲を決定します。

RTOは、組織が受け入れがたい結果(経済的損失、顧客不満足、評価など)を被り始める前に、ITベースのビジネス・プロセスを停止できる最大時間として定義されます。RTOは、一般的に、ビジネス・プロセスまたは組織の許容停止時間に相当します。

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

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

障害の発生確率に基づいてRTOを変えている組織もあります。簡単なクラスの分離としては、ローカルな障害(単一データベースの計算、ディスク/フラッシュ、ネットワーク障害など)、およびそれと対照的な大規模な障害(完全なクラスタ、データベース、データの破損、サイトの障害など)があります。通常、ビジネスで重要なシステムを運用する顧客の場合は、ローカルな障害に対しては1分より短いRTO、大規模な障害に対しては1時間より短いRTOを設定することがあります。ミッション・クリティカルなアプリケーションの場合、RTOはすべての計画外停止で同じである可能性があります。

リカバリ・ポイント目標

ビジネス影響分析では、リカバリ・ポイント目標(RPO)とも呼ばれる、データ損失の許容範囲も決定します。

RPOは、組織に損害を与えずに、ITベースのビジネス・プロセスで失うことのできる最大データ量です。RPOは、一般的に、ビジネス・プロセスまたは組織の許容データ損失量を計測します。このデータ損失は、通常、データ損失ゼロ、何秒分、何時間分または何日分のデータ損失というように、時間に換算して測定されます。

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

障害に対してRPOをゼロにすることは困難ですが、データベースを保護する各種のOracleテクノロジ(特にZero Data Loss Recovery Appliance)を使用して達成することができます。

管理性目標

管理性目標は、RPOやRTOよりも主観的です。組織で使用できるスキル・セット、管理リソースおよびツールの客観的な評価、および組織が高可用性アーキテクチャのすべての要素を正常に管理できる程度を決定する必要があります。

RPOおよびRTOが停止時間やデータ損失に対する組織の許容差を測定するのと同様に、管理性目標はIT環境の複雑さに対する組織の許容差を測定します。複雑さがそれほど要求されない場合、高可用性を実現するには、管理が複雑な方法よりも単純な方法が好まれ、複雑な方法の方が積極的なRTOおよびRPO目標を達成できる場合でも当てはまります。管理性目標を理解すれば、組織で実現が可能と思われる事項と実現が実用的である事項とを区別する際に役立ちます。

OracleデータベースをOracle Cloudに移動すると、管理性のコストと複雑さを大幅に軽減できます。Oracle Cloudを使用すると、最大可用性アーキテクチャの各種のアーキテクチャを組込みの構成やライフ・サイクル操作で選択できるからです。Autonomous Database Cloudを使用すると、バックアップとリストア、ソフトウェア更新、キーの修復操作などのデータベースのライフ・サイクル操作が自動化されます。

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

総所有コスト(TCO)と投資利益率(ROI)の目標を理解することは、組織のビジネス目標も達成する高可用性アーキテクチャを選択する際に不可欠です。

TCOには、選択する高可用性ソリューションの耐用年数におけるすべてのコスト(取得、実装、システム、ネットワーク、設備、スタッフ、トレーニング、サポートなど)が含まれます。同様に、ROIの計算では、指定の高可用性アーキテクチャで発生するすべての金銭的利益が算出されます。

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

企業は、新しいデータ・センターを構築するために事前の資本投資を行うのではなく、ワークロードをクラウドに移動することによって、インフラストラクチャのニーズの増大によるTCOを減らすこともできます。経済的な面での主なアピールとしては、設備投資を営業のための支出に変換することによって、ROIがより高くなることが挙げられます。

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

ビジネス影響分析は、すでに認識されている事項をドキュメント化するために役立ちます。ビジネス影響分析の結果により、類似したRTOおよびRPO目標を持つデータベースをグループ化するために必要な見通しが提供されます。

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

類似するRTOおよびRPOごとのデータベースのグループを、必要なサービス・レベルに最も近い処理が行われる高可用性リファレンス・アーキテクチャの制御されたセットにマップできます。データベース間に依存性がある場合は、高可用性要件が最も厳しいデータベースとグループ化されることに注意してください。

Oracle MAAリファレンス・アーキテクチャ

Oracle MAAのベスト・プラクティスでは、高可用性リファレンス・アーキテクチャを定義し、あらゆる規模や業種のエンタープライズで必要とされる可用性とデータ保護のすべての範囲に対応しています。

Platinum、Gold、Silver、BronzeのMAAリファレンス・アーキテクチャ(層)は、オンプレミス、プライベート・クラウドとパブリック・クラウド構成、およびハイブリッド・クラウドに適用できます。これらは、次の図に記載されているサービス・レベルに対応します。

図2-2 Oracle MAAリファレンス・アーキテクチャ

「図2-2 Oracle MAAリファレンス・アーキテクチャ」の説明

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

Oracle Multitenantを使用するコンテナ・データベース(CDB)は、BronzeからPlatinumまでどの層にも存在でき、統合密度とTCOを高めることができます。通常、統合密度はBronzeおよびSilver層で高く、Platinum層をデプロイする場合、統合密度は低くなるか、ゼロです。

また、Oracle Database In-MemoryをどのMAA層でも利用できます。インメモリー列ストアがOracle Databaseにシームレスに統合されているため、MAA層から取得される高可用性のメリットは、Oracle Database In-Memoryの実装時に継承されます。

Oracle Engineered Systemはどの層にも存在できます。Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)をデータ・センター全体のOracle Databaseバックアップおよびリカバリ・ソリューションとして統合すると、バックアップから復元する際のRPOおよびRTOが削減されます。Oracle Exadata Database MachineをMAAリファレンス・アーキテクチャのデータベース・プラットフォームとして利用すると、最小のRTOおよび低下で最適なデータベース・プラットフォーム・ソリューションがExadataのMAAのサービス品質とともに提供されます。

Bronzeリファレンス・アーキテクチャ

Bronze層は、障害が発生したコンポーネント(リスナー、データベース・インスタンス、データベースなど)の単純な再起動、またはバックアップからのリストアが十分なHAとDRで行われるデータベースに適しています。

Bronzeリファレンス・アーキテクチャは、すべてのOracle Enterprise Editionのライセンスに含まれているデータ保護と高可用性のための多くの機能を実装するMAAベスト・プラクティスを使用した、単一インスタンスのOracle Databaseに基づいています。Oracle Recovery Manager (RMAN)を使用してOracleに最適化されたバックアップによりデータが保護され、停止によってデータベースの再起動が妨げられる場合に、可用性をリストアするために使用されます。Bronzeアーキテクチャでは、Oracleのテクノロジ(Oracle Restart、Recovery Manager (RMAN)、Zero Data Loss Recovery Appliance、フラッシュバック・テクノロジ、オンライン再定義、オンライン・パッチ適用、自動ストレージ管理(ASM)、Oracle Multitenantなど)で拡張された冗長なシステム・インフラストラクチャを使用します。

Silverリファレンス・アーキテクチャ

Silver層では、ほとんどの一般的な計画メンテナンス・イベント(ハードウェアおよびソフトウェアのアップデートなど)のみでなく、データベース・インスタンスやサーバー障害の際に、停止時間を最小限またはゼロにする必要があるデータベースの高可用性のレベルが高くなります。

Silverリファレンス・アーキテクチャでは、Oracle RACまたはOracle RAC One Nodeを使用したクラスタリング・テクノロジを含む、エンタープライズ機能と利点の充実したセットが追加されます。また、アプリケーション・コンティニュイティは、実行中のトランザクションの信頼できるリプレイを提供し、ユーザーが停止を認識しないようにして、アプリケーションのフェイルオーバーを単純化します。

Goldリファレンス・アーキテクチャ

Gold層は、データベース、クラスタ、破損またはサイト障害などの障害に対して高いRTOおよびRPOを許容できないビジネスで重要なアプリケーションに対して、多大な役割を果たします。また、データベースのメジャー・アップグレードまたはサイトの移行を秒単位で実行できます。

Gold層では、すべてのレプリカが常時、積極的に使用されるため、投資利益率が向上すると同時に、コストも削減されます。

Goldリファレンス・アーキテクチャでは、データベース対応のレプリケーション・テクノロジ(Oracle Data GuardおよびOracle Active Data Guard)が追加され、本番データベースのレプリカが1つ以上同期されて、リアル・タイムのデータ保護と可用性が実現されます。データベース対応のレプリケーションにより、ストレージ・レプリケーション・テクノロジで可能な範囲を超えて、高可用性とデータ保護(破損保護)が大幅に強化されます。Oracle Active Data Guardの遠隔同期は、距離に関係なくデータ損失なしの保護に使用されます。

従来のソリューションより優れているOracle Data Guardの利点も参照してください。

Platinumリファレンス・アーキテクチャ

Platinum層では、停止時間なしのアップグレードおよび移行のためのOracle GoldenGateを含めて、いくつかの新しいOracle Database機能が導入されています。

エディション・ベースの再定義により、アプリケーション開発者は停止時間なしのアプリケーションのアップグレードを設計できます。Oracle Sharding用のアプリケーションを別の方法で設計できます。この方法では、データベースのサブセットを可用性の高いシャードに分散することによって最大の可用性が提供され、アプリケーションは1つの論理データベースとしてデータベース全体にアクセスできます。

これらのテクノロジのいずれも、実装に追加の作業が必要ですが、停止時間が許されない、最も重要なアプリケーションにとっては十分な価値があります。

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

各MAAリファレンス・アーキテクチャにより、テストされた既知のレベルの停止時間およびデータ保護が提供されます。

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

表2-1 MAAリファレンス・アーキテクチャ別の高可用性およびデータ保護の属性

MAAリファレンス・アーキテクチャ	計画外停止(ローカル・サイト)	計画メンテナンス	データ保護	リカバリ不能なローカル停止および障害時リカバリ
Bronze	単一インスタンス、リカバリ可能なインスタンスおよびサーバー障害での自動再起動。単一のコンポーネント(ディスク、フラッシュ、ネットワークなど)の障害によって停止時間が発生しないようにするための、システム・インフラストラクチャの冗長性。	一部オンライン、大部分オフライン	基本的なランタイム検証と手動チェックの組合せ	バックアップからのリストア、最後のバックアップ以降に生成されたデータを失う可能性。Zero Data Loss Recovery Applianceを使用すると、データ損失の可能性がゼロまたはほとんどゼロになります。
Silver	インスタンスおよびサーバーの障害に自動フェイルオーバーを使用するHA	ほとんどがローリング、一部がオンライン、ごく一部がオフライン	基本的なランタイム検証と手動チェックの組合せ	バックアップからのリストア、最後のバックアップ以降に生成されたデータを失う可能性。Zero Data Loss Recovery Applianceを使用すると、データ損失の可能性がゼロまたはほとんどゼロになります。実行中のトランザクションは、アプリケーション・コンティニュイティを使用して維持されます。
Gold	包括的な高可用性および障害時リカバリ	すべてがローリングまたはオンライン	包括的なランタイム検証と手動チェックの組合せ	リアルタイム・フェイルオーバー、ゼロまたはゼロに近いデータ損失
Platinum	Platinum対応アプリケーションではアプリケーションの停止なし	アプリケーションの停止なし	包括的なランタイム検証と手動チェックの組合せ	Platinum対応アプリケーションでは、アプリケーションの停止はゼロになります(データ損失もゼロ)。Oracle RAC、Oracle Active Data GuardおよびOracle GoldenGateが相互に補完し合い、計画外停止でのデータベース・サービスの停止時間をゼロにするための広範なソリューションが提供されます。または、サイト障害の保護のためにOracle Shardingを使用すると、アプリケーションに対する影響がデータベース全体ではなく障害の発生したサイトのシャードのみになります。Platinum対応アプリケーションの場合、各シャードは、リアルタイムのフェイルオーバー、ゼロまたはゼロに近いデータ損失、またはアプリケーションの停止なしで構成できます。実行中のトランザクションは維持され、データ損失はありません。