楽天証券がExadataを選んだ理由は「DWHアプライアンスではなくデータベース・マシンだから」

楽天証券がExadataを選んだ理由

　今回の移行で、オンライン処理においては、発注処理が最大2倍、株価参照取引処理が最大7倍に高速化した。さらに夜間バッチ処理は100分かかっていたものが60分に短縮され40%の効率化がなされた。Oracle Exadataは2台構成ではあるが、実際に処理を行っているのは1台だけだ。1台は障害時にバックアップシステムとなるスタンバイシステムとして導入されている。このサーバー統合により、年間の消費電力量が約5000万円も削減できると言うのだから、そのメリットもかなり大きなものとなっている。

　大きく処理が高速化されたわけだが、楽天証券がExadataを選択したのはその高速性だけではない。むしろ重視したのは、システムの信頼性を高度に保つための可用性の向上のために採用したとのこと。

業務改善命令から、「システム安定化推進プロジェクト」へ

　楽天証券では、2005年11月、2007年6月、2009年3月とこれまでに3度、監督官庁である金融庁から業務改善命令を受けている。

「会社として大きな課題を抱えていた」

　「そのいずれもがシステムに起因するものであり、これは会社として極めて大きな課題と捉えていた」と楽天証券株式会社 取締役 常務執行役員（CIO）今井隆和氏は言う。同氏が楽天証券に着任したのは、2回目改善命令の出る直前。すでに2回目の命令が出るであろうことは分かっていた。そのため、同氏は、現状を分析し、改善のためのさまざまな施策を打つことになる。たとえば、「キャパシティ確保のために2500台以上のサーバーを導入していた」とのこと。にもかかわらず、3度目の業務改善命令につながる、大規模なシステム障害が発生してしまう。

　「やることはやったつもりだったが、それでも駄目だった。根本的な見直しをしなければならなかった」（今井氏）

　その結果、最高責任者を同社社長とする「システム安定化推進プロジェクト」が始まる。メンバーは全執行役員、システム関連部門部長、牽制部門部長、社外有識者、ベンダー責任者というそうそうたるメンバーが推進委員として参加した。ここで目標とされたのが、社会インフラとしてのシステムの信頼性の確保だった。

　具体的なシステムの目標としては、障害が起きることを前提として障害からの復旧時間を短縮しサービスへの影響範囲を極小化すること、そして重度障害発生の可能性がある事象をあらかじめ取り除くことの2つだった。このために選択されたのが、Oracle Exadataだったわけだ。Oracle Exadataと比較検討したのは、IBMのハイエンドUNIXのマシンとOracleデータベースの組み合わせ、IAサーバーとOracle データベースの組み合わせの2つ。ここで重要だったのは、性能はもちろんのこと、拡張性、さらにはOracleの提供する高可用性実現のためのフレームワークMAA（Maximum Availability Architecture）が実現できることだった。

　じつは、上記のどの構成でもMAA自体は適用し実現することはできた。しかしながら、実際にそれを運用するとなると、ハードウェアとソフトウェアのベンダーが異なれば「障害の原因をハードとソフトでキャッチボールすることになる」と今井氏は指摘する。そのような状況ではシステムの仕組みが高可用性を持っていたとしても、運用面では1段階信頼性を損なうことになる。Oracle Exadataであれば、それをワンストップにすることができる点は、同社にとっては大きな評価ポイントだったようだ。MAAは、Oracleが提供する、さまざまな信頼性、可用性を確保する機能のフレームワークだ。複数の施策を組み合わせることで、計画外停止、計画停止のどちらにも対応できるとのこと。