可用性も不安なし！ Oracle Cloud Platformの「実力」とは：“ミッションクリティカルクラウド”は本当か 【可用性検証】編（1/2 ページ）

“ミッションクリティカルクラウド”としてのOracle Cloud Platformの実力を測るべく、PSソリューションズが引き続き技術検証に取り組んでいる。前回の「性能」に続いて、今回は「可用性」にフォーカスを当てて検証作業を実施した。その結果を紹介しよう。[パブリッククラウド][Oracle Cloud][Oracle Database 12c]

[PR／＠IT]

PR

「ミッションクリティカル領域で活用する」ための検証作業

PSソリューションズ エンタープライズ事業本部 エンタープライズ事業推進部 部長／チーフテクニカルエンジニアの飯泉卓也氏

　オラクルが“ミッションクリティカルクラウド”として機能強化を続けている「Oracle Cloud Platform」。その中核となる「Oracle Database Cloud Service」は、「Oracle Database」をPaaS（Platform as a Service）として従量課金で利用可能なサービスだ。2015年に本格提供を開始して以来、これまでオンプレミスでオラクルの製品や技術を取り扱ってきたパートナーを中心に、性能や機能に関する技術検証が活発に行われている。中でも、特にミッションクリティカル領域における活用にフォーカスして検証作業を進めている1社が、ソフトバンクグループでITソリューションを手掛けるPSソリューションズである。

　本サイト掲載記事「Oracle Database Cloud Serviceはどこまで『使える』か」で紹介したように、同社は昨年（2015年）、Oracle Database Cloud Serviceと「Oracle Java Cloud Service」の使い勝手や性能に関して検証を行っている。それに続いて、新たにOracle Database Cloud Serviceの「Oracle Real Application Clusters（RAC）」機能を中心に、パブリッククラウド上におけるOracle Databaseの可用性確保に関して検証作業を実施した。

　PSソリューションズ エンタープライズ事業本部 エンタープライズ事業推進部 部長／チーフテクニカルエンジニアの飯泉卓也氏は、「当社はオラクル製品によるミッションクリティカル分野のソリューションを強みとしていますが、Oracle Cloud Platformをこの分野で活用するためには、『性能』に加えて、『可用性』や『セキュリティ』といった複数の視点による入念な検証が必要だと考えています。その第一弾として、昨年（2015年）は性能に関する検証を行いましたが、それに続いて、Oracle Database Cloud ServiceとOracle Java Cloud Serviceの『可用性』について検証を実施しました。これに関しても同サービスの有効性を確認できました」と話す。以下、この検証作業で得られた結果を紹介する。

クラウド上のRACではVIPが使えない！ 可用性をどう担保するか？

　一般に、Oracle Databaseで高い可用性を確保するためには、複数ノードによるクラスタ構成で、1つのサーバに障害が発生した際にもデータベースシステム全体としての稼働を継続可能にするOracle RACを利用する。飯泉氏によれば、Oracle Database Cloud Serviceでは、このOracle RACに関する事情がオンプレミスとは少し異なるという。オンプレミスのOracle RAC構成で広く利用されている「仮想IPアドレス（VIP）」によるフェイルオーバーが、Oracle Database Cloud Serviceでは利用できないのだ。

　VIPが利用可能な場合、サーバに障害が発生するとVIPは他のサーバにフェイルオーバーされるため、アプリケーション側ではサーバの障害を即座に検知することができる。一方、VIPを利用できない場合は、SQL*NetやOS上で稼働するTCPのタイムアウトまで、通信への応答がない状態のまま待機することになる。そこで、PSソリューションズは「VIPが使えない環境で、どのように可用性を担保するか」に焦点を当てて検証を行った。

PSソリューションズ エンタープライズ事業本部 エンタープライズ事業推進部 シニアテクニカルエンジニアの福田隆弘氏

　検証作業を担当したエンタープライズ事業本部 エンタープライズ事業推進部 シニアテクニカルエンジニアの福田隆弘氏によれば、Oracle Database Cloud Serviceで可用性を確保するには、「新規セッション」と「既存セッション」のそれぞれについて、適切な設定や運用を考える必要があるという。

　まず、新規セッションは、デフォルトで「最大60秒」となっているSQL*Netのタイムアウト値（TCP.CONNECT_TIMEOUT値）を変更することで、VIPがない場合でも障害の検知時間を短縮可能だという。今回の検証では、検証環境を考慮して「最大3秒」に設定を変更している。

　一方、既存セッションについては、障害検知時間の短縮と透過的な処理再実行を目的に、Oracle RACとOracle WebLogic Serverの組み合わせで利用可能な機能である「Fast Connection Failover（FCF）」と「Application Continuity（AC）」を活用した。

　「FCFとACを組み合わせて利用することで、RACインスタンスの障害をアプリケーションサーバが自動的に検知して、接続先の変更とリトライを行えるようになります。これにより、クライアント側ではRAC側で起きている障害を意識せずに処理を継続できるのです」（福田氏）

　実際の検証はOracle Cloud Platform上で行われ、データベース環境としてOracle Database Cloud Service、アプリケーション実行環境としてOracle WebLogic ServerのPaaSである「Oracle Java Cloud Service」、検証用に疑似的な負荷を掛けるためのクライアント環境として「Oracle Developer Cloud Service」を利用した。

　テストでは、2ノードのOracle WebLogic Server、2ノードのOracle RACインスタンスの間に各ノードで20（合計40）のセッションを張り、その状態で「Oracle RACインスタンスの1つがOSごとダウンする」というシナリオを設定。FCF（Fast Connection Failover）とAC（Application Continuity）を「どちらも利用しない場合（パターン1）」「FCFのみ利用する場合（パターン2）」「どちらも利用する場合（パターン3）」という3つのパターンについて、「（クライアント側での）トランザクションエラーの発生数」と「障害収束時間」がどのように変化するかを確認した。