多くのエンタープライズ企業に採用されている「Oracle Real Application Clusters（以下、Oracle RAC）」。
クラウドコンサルティング事業部
事業部長 今村哲也氏
クラウド時代が本格化して基幹システムもクラウドに移行するケースが増える現在、Oracle RACの有効性と、これからの時代における課題は何なのか？
今回は株式会社システムサポート クラウドコンサルティング事業部長 今村哲也氏、シニアマネージャー 山口正寛氏のお二人に、Oracle RACに関する現状を探りたいと思います。
>>【資料ダウンロード】Oracle RACに関する課題と解決策
–まず、システムサポート社について教えてください。
今村氏：
1980年に石川県金沢市で設立され主にシステム開発業務を主力に成長してきました。現在では東京、名古屋、大阪に支社支店を置いています。今は売り上げも社員数も半分は東京で、本社を金沢に置きながら大都市を中心にビジネスを広げており、IPOの計画もあります。
–お二人の所属部門やミッションは。
クラウドコンサルティング事業部
シニアマネージャー 山口正寛氏
山口氏：
私たちの所属はクラウドコンサルティング事業部といいまして、AWSをはじめとするパブリッククラウドを利用して、お客様のオンプレミスのシステムをクラウドに移行したり、あるいは新たにクラウドを利用されるお客様に対して、最適なクラウドの利用方法を提案したりさせていただく業務が中心です。
同様のことを行っている会社は他にもありますが、私たちの一番の特色は、もともとOracleデータベースを強みにしている部隊から分離独立してできた事業部ですので、OracleデータベースをはじめとするRDBMSの技術力を強みにしながら、クラウドへの移行やクラウド基盤の構築などをご支援しているところです。
–今村様についてはいかがでしょう。
今村氏：
私は、クラウドコンサルティング事業部の責任者を務めています。事業部ではデータベース周りのノウハウを最大の強みとしながら、ただデータベースだけをやるのではなく、その周りのシステムも含めて対応しています。軸足をデータベースに置きながら、システム全体のクラウドへの移行をご支援しております。
Contents
画期的だったOracle RACの登場
–ありがとうございます。早速ですが、Oracleデータベースに関する技術力と最近の傾向を熟知されている貴社からみて、Oracle RACが2000年代初頭に登場した当時、どこが画期的だったのでしょうか。
今村氏：
Oracle RACが登場する以前は、クラスターといえばアクティブ/スタンバイの形態でした。Oracle RACはアクティブ/アクティブのクラスターを実現し、スケールアウトも自在にできるデータベースでした。この機能は他のどのデータベースも備えていませんでしたから、その全てが画期的だったといえると思います。
–それから約15年が経過して、現在は二桁台数のサーバを並べるようなハイエンドのOracle RACユーザーもいれば、Standard Editionのライセンスで利用可能な「SE RAC」と呼ばれるようなサーバ2台構成のRACユーザーもいらっしゃると思います。システムサポート社のお客様では、その割合はどのくらいでしょうか？
今村氏：
システムサポートのお客様全体で見ると、ハイエンドのOracle RACのお客様は比較的少なく、数としては、SE RACで構築しているお客様の方が多いと思います。
山口氏：
ただ、それなりの規模のエンタープライズのお客様でOracle RACを組んでいないのは、あまり想像できません。クラウドコンサルティング事業部では、いろいろなお客様とやり取りさせていただいていますが、RACを組んでいない方が割合は少ないですね。
Oracle RACの強みと普及のわけ
–では、エンタープライズでOracle RACを使用しているお客様が求めているものは何でしょうか？可用性かパフォーマンスか、あるいは別の理由があるのでしょうか。
山口氏：
基本的には、正に可用性とパフォーマンス向上の2つだと思います。つまり、Oracle RACを組めばサーバ台数を増やして性能を上げられることと、アクティブ/スタンバイにして1台を眠らせておくより、アクティブ/アクティブでその1台をクラスターへ参加させ、よりシステム負荷を下げて運用できるから、という考えが理由だと思います。
ただ、ユーザーとしてはおそらく、スケールアウトしていけばリニアに速くなると期待していると思いますが、実際にはそうでもありません。たとえば、一昔前はネットワークの帯域がそれほど太くなかったので、台数を増やせば増やすほどキャッシュフュージョンと呼ばれる処理に伴うオーバーヘッドで性能劣化が発生していました。
サーバの台数が多ければ、Oracle RACの特徴でもある複数のサーバを使ったパラレルクエリといった機能が有効になります。ただし、あまりにも台数が多いとやはり問題は起きますので、きちんとクエリの分散ができるようなアプリケーションの設計をしてリニアにスケールアウトさせるようにします。
–では、SE RACのユーザーが求めていることは何でしょう。
山口氏：
基本的にはOracle RACを利用しているお客様と同じで、可用性を求めつつも、アクティブ/スタンバイで眠らせておくともったいないので、アクティブ/アクティブにした方が得という感覚のユーザーが多いのではないでしょうか。高可用性も実現できますし、スペック的にも上がりますから。
–アクティブ/アクティブで「それなりの」高効率、高可用性、あるいはスモールスタートができるといったことがSE RACへの期待ということですね。
今村氏：
はい。「Oracle RACは落ちない」と考えているお客様が多いこと、SE RACではライセンス料金が別途かからず、純正品でクラスター環境を構築できることもあると思います。
ユーザーは見過ごしている？Oracle RACの盲点
–Oracle RACの盲点はあるのでしょうか？
今村氏：
データベースの実体がひとつしかないという点に関しては、シングルとなんら変わりません。要は処理を行うノードの冗長性は保たれていても、複数ノードから利用されるデータベース自体はひとつなのです。とはいえ、たとえばOracle Data Guardのような別の機能を使ってさらに冗長化構成を組めば、この部分の可用性を担保することが可能です。
–運用面での課題はありますか？
山口氏：
Oracle RACだから、シングルだからということはアプリケーションからは関係がありません。ただ、強いていえば普通のシングル構成に比べて、インフラ側にOracle RAC固有の機能がありますので、その一連の機能を熟知しておかないと止まってしまうということになりかねません。
今村氏：
Oracle RACに精通しているエンジニアは、以前より増えてはいるものの、必要十分な数は満たせていない印象です。そこは一つ課題と言えるのではないかと。優れた数々の機能を十分活用するためにも、Oracle RACを熟知しているエンジニアは、運用上どうしても必要になってきます。
オープンソース系データベースへの移行の現実味は？
–Oracleからオープンソース系データベースに移行するとなると現実的にはどうでしょう？
山口氏：
エンジニア視点で見るとOracleは非常によくできたデータベースで、たとえば現在、MySQLは5.6が出ていますが、それはOracleのバージョン7か8のイメージです。基幹系のシステムでは、たとえばSAPにはHANAという製品があり選択肢が増えてきていますが、今後もOracleデータベースは最有力の候補の一つだと思います。
データウェアハウスに関しては、redshiftのようにもともとデータウェアハウスに特化したデータベースが出てきているので、Oracleのような汎用性の高いよくできた製品が、今後どういった分野で活用されるか注視しているところです。
Oracle 19c周りのお問い合わせについて
Oracle Database 19c では SE2(Standard Edition2) RACがサポートされません。
Oracle SE2 RACユーザーが抱える課題と、その解決策をご紹介しています。
>>「Oracle RACの課題と解決策 」の資料ダウンロードはこちらから
