変わるOracle RAC、その有効性とクラウド時代の課題（後編）

>前編から読む

基幹システムもクラウドに移行するケースが増える現在、Oracle RACの有効性と、これからの時代における課題は何なのか？
引き続き、株式会社システムサポート　クラウドコンサルティング事業部長　今村哲也氏、シニアマネージャー　山口正寛氏のお二人にお話を伺います。

>>Oracle RACに関する課題と解決策

クラウド上ではOracle RACが動かない

–オープンソース化と並ぶトピックとして、クラウド移行も最近の重大テーマだと思います。オンプレ環境でのOracle RACユーザーが、システムをクラウドに移行しようとしたときに、障壁となるものは何でしょう？

山口氏：
　クラウド上ではOracle RACが動かないということですね。Oracle RACはマルチキャスト通信が必要なのですが、パブリッククラウドはマルチキャスト通信を基本的に禁止しています。そこが最大の障壁です。私たちもソフトウエアVPNを使ってトンネリングを組み、そのトンネルの中でマルチキャスト通信を行う手法も試したのですが、VPNソフトのオーバーヘッドが大きすぎ、思ったような性能が出ませんでした。お客様に提案できるような状況ではなく、まだシングル構成で提案した方がいいという結論です。

–共有ストレージに関してはいかがですか？

山口氏：
　共有ストレージが組めないという話は、お客様からよく聞かれます。ただ、ストレージサーバのようなものを立てて、そこにディスクを積んでNASマウントさせることは可能です。やはり、一番のネックはマルチキャスト通信ができないことですね。

Oracle RACユーザーがクラウド移行する際の代替手段

–では、今までオンプレ環境でOracle RACを使っていたユーザーがクラウドへシステム移行しようとする場合、システムサポート社ではどのような代替手段をご提案されてきたのでしょうか。

山口氏：
　Oracle Data Guardのような製品を使ったマルチエージェント構成をご提案させていただいています。これだとデータベースそのものの冗長化ができるので、可用性はより高くなります。

–Oracle Data Guardは、レプリケーション機能を提供する製品という印象でしたが。

山口氏：
　Oracle Data Guardには、Oracle Data Guard Brokerという障害検知や障害時の自動切り替え機能もあります。ただ、それをオンにするかどうかは要件次第です。誤作動を起こして勝手に切り替わってしまうのもよくないので。

　この機能は、あらかじめ登録した条件に合致しているかどうかを監視していて、条件に合致した場合にはダウンしたとみなして、プライマリからプライマリロールをスタンバイ側へ移設し、スタンバイ側をアクティブにするというような機能です。

–クライアント側からの透過性のような機能はあるのでしょうか？

山口氏：
　それは基本的にはなく、Oracle Clientのリトライ機能を使ったり、あとはAWSであればEnterprise Load Balancerの機能を使ったりします。OracleデータベースのEnterprise Editionライセンスをお持ちのお客様にはOracle Data Guardを提案させていただきますが、Standard Editionしかお持ちでないお客様はOracle Data Guardの機能は使えないので、少し頭を悩ますところです。

今村氏：
　Standard Editionしか使えないお客様には、Standby Expressという製品を使わせていただいたり、サイオステクノロジーのレプリケーションソフトウェアDataKeeperを使用させていただいたりしています。

–Oracle Data Guardを使ったとしても、Oracle RACの持つ拡張性やパラレルクエリのような機能が使えるわけではないので、これがそっくりそのままOracle RACの代わりになるとは思えませんが、Enterprise Editionのライセンスを持っている「リッチな」ユーザーが、レプリケーション型での高可用性環境を作る手段としては有効ということですね。それ以外に課題はありますか？

山口氏：
　Oracle Data Guard Brokerは自動で切り替わるとはいえ、その切り替えの実装は、かなり細かい配慮が必要になります。Standby Expressは手動で切り替えるのですが、切り替えには、意外と作業工数が多くなります。どちらももっと手軽に切り替えられれば、今の課題にもフィットするのですが。

SE RACユーザーの求める可用性と代替手段

–SE RACを使っている方々は、たとえば99.9999％のような超可用性を要件として想定しているのでしょうか。

山口氏：
　それはありません。RFPには、「各データベースサーバは冗長構成であること」くらいしか書かれていませんから。障害時の切替時間の要件まで厳密に定義するレベルであれば、それはもうエディションの問題ではないですね。

今村氏：
　そこまでいくとOracle Data Guardでも要件を満たせないようなお客様もいらっしゃいました。その時はまた別の手を使うことになってしまいます。

–少し話をまとめてみると、SE　RACのユーザーの中は「それなりの性能が出て、それなりの可用性が担保できれば十分」という方もかなりの割合で存在するように思われます。サイオステクノロジーはLifeKeeperというHAクラスター製品や、DataKeeperというデータレプリケーション機能を自社開発して販売しています。今まで伺ったような状況から考えると、むしろシンプルなアクティブ/スタンバイ型のクラスターが見直されてもいいのではないかと思っています。豊富な実績もありますし、クラウド上でのユースケースも増えています。特にこれまでのSE RACのユーザー層には安心してお使いいただけるのではないかと思っています。

>>【資料ダウンロード】Oracle RACに関する課題と解決策

今村氏、山口氏：
　それなりの性能が出て、それなりの可用性が担保できれば十分というお客様は一定数いらっしゃいますし、私たちもその可能性は十分にあると思っています。

Oracle RACユーザーのAmazon RDS移行の可能性

–最後に、AWS上ではRDSというマネージドサービスがありますが、Oracle RACユーザーがRDSへ移行するという可能性はいかがでしょう？

山口氏：
　RDSは優れたサービスですので、それはあり得ると思います。運用面を考慮しても、メリットは大変大きいです。ただ、いくつかの制約事項はあり、たとえばRDSはデータベースサービスなので、OSにログインできません。そのため、従来エージェントを入れて動かしていたり、スクリプトを配置していたり、それがそもそもマスト要件であると、RDSは導入できません。

　またRDSはIPアドレスを固定できません。IPアドレスが変わってしまうので、あまり考えにくいですが、アプリケーションが自分でデータベースのIPアドレスを取ってきてそれをキャッシュしておくようなことがあれば、変更を加える必要があります。そういった、いくつかの制約事項を全てクリアできるのであれば、RDSは非常に楽ですね。

–OSにログインできないということは、調整できないチューニングパラメータもあるということですよね。

山口氏：
　調整できるものもありますが、たとえばログスイッチ関連のパラメータはいじれません。5分に一回、ログスイッチが強制的に実行されてしまいます。

–そうすると、5分ごとにリソースの使用率が跳ね上がる可能性があるということですね？

山口氏：
　ログスイッチはダーティキャッシュなどをディスクに書き出したりするので、あまり頻繁に実行されるとパフォーマンス上よろしくないといわれていました。そのため一昔前は、私たちが構築するときにはログスイッチは30分に1回や1時間に1回で設計していました。もっとパフォーマンスにシビアなお客様は1日に1回というケースもありました。それが5分に1回必ずということになるので、そこがボトルネックになるケースがあると、少しやっかいですね。
一方で、ログスイッチが5分毎に実行される為、確実に5分前の状態まで復元可能となりますので、利用者にとって必ずしもデメリットになるとは限りませんが。

–お客様の要件に合った的確なご提案をするには、各サービス・環境の仕様と制限事項を正確に把握している必要があるということですね。本日は貴重なお話をどうもありがとうございました。

Oracle 19c周りのお問い合わせについて

Oracle Database 19c では SE2(Standard Edition2) RACがサポートされません。
Oracle SE2 RACユーザーが抱える課題と、その解決策をご紹介しています。
>>「Oracle RACの課題と解決策 」の資料ダウンロードはこちらから