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