| Oracle® Database高可用性概要 11gリリース2 (11.2) B56308-04 |
|
 前 |
 次 |
この章では、次の項目について説明します。
高可用性計画を設計および実現しようとする企業は、高可用性を必要とするビジネス要因の徹底的な分析から始める必要があります。高可用性の実現は、次のような重要な課題を伴います。
レガシー・システムの廃止
より高度で堅牢なシステムや設備への投資
この高可用性モデルに合せたITアーキテクチャと操作全体の再設計
ビジネス・プロセスの再設計
人員の雇用およびトレーニング
この章では、ビジネスの高可用性要件を効果的に評価するためのフレームワークを示します。ビジネス要件を分析した上で、様々な高可用性ソリューションの実装に必要な投資レベルを理解することで、ビジネス面と技術面の両方の目的を達成する高可用性アーキテクチャの開発が可能になります。
高可用性分析フレームワークを使用すると、次のことが可能になります。
ビジネス影響分析の実施
高可用性要件を持つ重要なビジネス・プロセスの特定および分類
停止時間のコストの公式化
各種ビジネス・プロセスの使用率、リカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)の設定
管理性、総所有コスト(TCO)および投資利益率(ROI)の目標の理解
このフレームワークにより、ビジネスの重要な局面の高可用性という見地から品質保証契約(SLA)を定義することができます。たとえば、SLAではビジネス・プロセスをいくつかの高可用性層に分類できます。
第1層のプロセスはビジネスに最大の影響を与えます。これらは最も厳しい高可用性要件を持ち、RTOおよびRPOはゼロに近くなります。また、継続的に使用できるサポート・システムが必要です。E-Commerceを大規模に展開しているビジネスの場合、Webベースの顧客対応システムなどがこれに当たります。
第2層のプロセスの高可用性およびRTOおよびRPOの要件は、多少緩やかでもかまいません。E-Commerceビジネスの第2層は、サプライ・チェーン・システムやマーチャンダイジング・システムなどです。たとえば、これらのシステムはきわめて高い可用性を維持する必要はないため、RTOおよびRPOの値がゼロではないこともあります。したがって、第2層のプロセスをサポートするために選択する高可用性システムは、第1層のプロセスとは異なっている可能性があります。
第3層のプロセスは、内部開発プロセスや品質保証プロセスに関連したものです。これらのプロセスをサポートするシステムには、他の層のような厳しい高可用性要件はありません。
図2-1に示すように、次のステップは、各種高可用性システムおよびテクノロジの機能を評価し、ビジネス・パフォーマンスの問題、予算の制約、および予想されるビジネスの成長によって決まるガイドラインの範囲内で、SLA要件を満たすものを選択することです。
この分析フレームワークは次の要素で構成されます。
組織内の重要なビジネス・プロセスの特定
各ビジネス・プロセスに影響を与える計画外IT停止および計画IT停止の定量化可能な損失リスクの算出
停止が与える影響の概略のまとめ
基本的なビジネス機能、人的リソースおよびシステム・リソース、政府規制、内部および外部のビジネス依存関係の考慮
豊富な知識を持つ経験豊かな人員とのインタビューで収集した客観的、主観的データの使用
ビジネス手法の履歴や財務報告書、ITシステム・ログなどの調査
ビジネス影響分析では、IT関連の停止の影響の重大度に基づいてビジネス・プロセスを分類します。たとえば、世界各地にチップ製造工場を持つ半導体製造業者について考えてみましょう。半導体製造業は、高生産量で償却される、巨額な財政投資を必要とする非常に競争の激しいビジネスです。工場管理で使用される人的リソース・アプリケーションは、工場の製造プロセスを制御するアプリケーションほどミッションクリティカルであるとみなされない傾向があります。製造をサポートするアプリケーションに障害が発生すると、その影響は生産レベルに及び、企業の決算報告に直接の影響が出ます。
同様に、経営コンサルティング企業では内部ナレッジ管理システムがミッションクリティカルであるとみなされる傾向があります。これは、クライアントを重視する企業のビジネスにとって、コンサルタントやナレッジ・ワーカーが内部調査にアクセスできることが基本であるためです。このようなシステムの停止時間のコストは、このビジネスにとってきわめて高くつきます。そこで、高可用性要件フレームワークの次の要素である停止時間のコストについて考えてみることにします。
ビジネス影響分析を完全に実施すれば、計画外停止時間および計画停止時間のコストの定量化に必要な見通しが得られます。このコストは、高可用性の投資の優先付けに役立ち、停止時間のリスクを最小限に抑えるために選択する高可用性テクノロジに直接影響を与えるため、必ず理解しておく必要があります。
様々な業界の停止時間のコストをまとめた各種レポートが発行されています。コストは、仲買業務やクレジット・カード販売の1時間当たり数百万ドルから、荷物輸送サービスの1時間当たり数万ドルまで、多岐にわたります。
これらの数字は驚異的ですが、その理由は明らかです。インターネットでは、ビジネスと何百万もの顧客を直接結び付けることができます。アプリケーションの停止時間によってこの結び付きは分断され、ビジネスと顧客が切り離されてしまいます。停止時間は収益の損失を生むだけでなく、カスタマ・リレーションシップ、競争力、法的義務、業界での評価、株主の信頼などにも悪影響を及ぼす可能性があります。
ビジネス影響分析では、リカバリ時間目標(RTO)を決定します。RTOは、組織が受け入れがたい結果(経済的損失、顧客不満足、評価など)を被り始める前に、ITベースのビジネス・プロセスを停止できる最大時間として定義されます。RTOは、一般的に、ビジネス・プロセスまたは組織の許容停止時間に相当します。
RTO要件はビジネスのミッションクリティカル性によって左右されます。したがって、証券取引所を運営するシステムの場合、RTOはゼロまたは非常にゼロに近い数値になります。
組織には、各種ビジネス・プロセスにまたがる様々なRTO要件があるものです。したがって、大規模なE-Commerce Webサイトの場合、高速のレスポンスが期待され、顧客のスイッチング・コストが非常に小さいため、E-Commerceの売上を押し上げるWebベースの顧客対応システムのRTOはゼロに近くなります。しかし、出荷や請求などのバックエンド業務をサポートするシステムのRTOはそれより長くてもかまいません。このようなバックエンド・システムが停止した場合は、一時的に手動操作に切り替えて、重大な影響が出るのを防ぐことができます。
E-Commerce Webサイトを介してすばやく注文を受けられること(RTO)のほうがPROより重要です。失われたデータは後でリロードできるためです。
ビジネス影響分析では、リカバリ・ポイント目標(RPO)も決定します。RPOは、組織に損害を与えずに、ITベースのビジネス・プロセスで失うことのできる最大データ量です。RPOは、一般的に、ビジネス・プロセスまたは組織の許容データ損失量に相当します。このデータ損失は、通常、5時間または2日分のデータ損失というように、時間に換算して測定されます。
毎分数百万ドルに相当するトランザクションが発生する証券取引所では、データを失うわけにはいきません。したがって、RPOをゼロにする必要があります。E-Commerceの例について言えば、Webベースの販売システムではRPOがゼロであることが厳密に求められるわけではありませんが、顧客満足のためにはRPOを抑えることが不可欠です。ただし、バックエンドのマーチャンダイジング・システムおよび在庫更新システムでは、RPOが大きくなることもあります。失ったデータの再入力が可能であるためです。
管理性目標は、RPOやRTOよりも主観的です。これは、組織で使用できるスキル・セットや管理リソースの客観的な評価、および組織が高可用性アーキテクチャのすべての要素を正常に管理できる程度に起因します。RPOおよびRTOが停止時間やデータ損失に対する組織の許容差を測定するのと同様に、管理性目標はIT環境の複雑さに対する組織の許容差を測定します。複雑さがそれほど要求されない場合、高可用性を実現するには、管理が複雑な方法よりも単純な方法が好まれ、複雑な方法の方が積極的なRTOおよびRPO目標を達成できる場合でも当てはまります。管理性目標を理解すれば、組織で実現が可能と思われる事項と実現が実用的である事項とを区別する際に役立ちます。
総所有コスト(TCO)と投資利益率(ROI)を理解することは、組織のビジネス目標を達成する高可用性アーキテクチャを選択する際に不可欠です。TCOには、選択するソリューションの耐用年数におけるすべてのコスト(取得、実装、システム、ネットワーク、設備、スタッフ、トレーニングおよびサポートなど)が含まれます。同様に、ROIの計算では、指定の高可用性アーキテクチャで発生するすべての金銭的利益が算出されます。
たとえば、リモートのスタンバイ・サイトのITシステムおよびストレージがアイドル状態の高可用性アーキテクチャがあり、そのスタンバイ・システムで処理できるビジネス用途が他にないとします。このスタンバイ・サイトの投資利益率は、フェイルオーバー・シナリオで使用する場合に回避される停止時間のコストのみです。このアーキテクチャと別の高可用性アーキテクチャを比較します。別の高可用性アーキテクチャでは、スタンバイ・サイトのITシステムおよびストレージがスタンバイ・ロールで本番用に使用できます(レポート作成や、エンドユーザーの問合せのプライマリ・システムのオーバーヘッドをオフロードする場合など)。このようなアーキテクチャの利益投資率には、回避された停止時間のコストと、スタンバイ・データベース・ロールでの本番使用で生じる金銭的利益の両方が含まれます。
次の各項では、高可用性システムの機能、ビジネスのパフォーマンス、予算および成長の計画について詳しく説明します。「正しい高可用性アーキテクチャの選択」も参照してください。
高可用性ソリューションでは、最終的にビジネス要件に対処することが必要です。たとえば、プライマリ・データベースのすべてのトランザクションをリモート・データベースに同期的にミラー化する、データ損失ゼロのソリューションを使用したとします。しかし、光速限界およびネットワークに関連する物理的限界を考えると、ネットワーク送信にはラウンドトリップ遅延が発生します。この遅延は距離とともに増大し、ネットワーク帯域幅、トラフィックの輻輳、ルーターの待機時間などによって変化します。したがって、この同期ミラー化を大規模なWide Area Network(WAN)上で実行した場合、プライマリ・サイトのパフォーマンスに影響が出る可能性があります。
オンライン・バイヤーはこうしたシステム待機時間に気づき、システムのレスポンスの遅さに不満を抱きます。その結果、どこか他へ行って購入することになります。これは、データ損失ゼロのソリューションの採用とシステム・パフォーマンスの最大化のいずれかを犠牲にする必要がある例です。逆に、ビジネス推進要因によってこのトレードオフを回避するための投資が正当であると証明されれば、プライマリ・サイトに近いデータ損失ゼロの同期スタンバイ・サイトと、何千マイルも離れた場所にある別の非同期スタンバイ・サイトを配置するマルチサイト・アーキテクチャを実装できます。
高可用性ソリューションでは、財務的な問題および将来的な成長の予測を念頭におくことも必要です。ITインフラストラクチャ全体に冗長性を持たせ、インフラストラクチャの障害対策が万全であることを主張したくなるものです。高可用性は必ずしもコスト増加を意味するわけではありませんが、軽率に判断すると、予算超過に陥るだけでなく、非常に複雑で統合やメンテナンスにコストがかかり、管理性もスケーラビリティもないソリューションの組合せが生まれる可能性があります。
パフォーマンス・ベンチマークですばらしい結果を収めた高可用性ソリューションは、魅力的に思えます。しかし、テクノロジの機能がビジネス推進要因にどのように一致するかを注意深く分析せずにそのようなソリューションに投資することは浅はかです。結果として次のようなソリューションで終わる可能性があります。
システム・インフラストラクチャの他の部分とうまく統合できません。
実装コストを優に上回る統合コストやメンテナンス・コストが毎年かかります。
賢明で思慮深い意思決定者は、適切に統合され、標準に準拠し、実装、メンテナンスおよび管理が容易で、将来的なビジネスの成長に対応できるスケーラブルなアーキテクチャを持つソリューションにのみ投資するはずです。
