2005年の個人投資家の株式投資ブームの当時、急増し続ける取引数は、「インフラの増強をはるかに上回るスピードでした」と、楽天証券株式会社 取締役で常務執行役員 CIOの今井 隆和氏は振り返る。トランザクションの急激な上昇に起因するシステム障害やデータベースのトラブルなどにより取引が一時停止し、金融庁から業務改善命令が出されたケースもあったという。
　
もちろん、同社ではこうしたトラブルの再発を防ぐべく、インフラの増強と並行して品質管理体制の整備や監視強化などの取り組みを続けていた。データベースの可用性については、Oracle Real Application Clusters（以下、Oracle RAC）も導入し、「その時点で考えられる手だてはすべて講じていました」と話す今井氏は、「これ以上何をすべきかわからず悩みました」とも打ち明ける。
　
そんなとき、オラクル・コーポレーション サーバーテクノロジー部門 プロダクトマネジメント バイス・プレジデントのマーク・タウンゼントから薦められたのが、「Oracle Maximum Availability Architecture」（以下、Oracle MAA）だった。タウンゼントに、「ミッションクリティカルなシステムでは、Oracle RACを導入するだけでなく、Oracle MAAも利用すべきだとアドバイスされたのです」（今井氏）
　
Oracle MAAは、オラクルのテクノロジーとベストプラクティスに基づき、最高の可用性を実現するための枠組みである。「以前は、データベース自体が壊れることをまったく考えていませんでしたが、2009年3月に発生したシステム障害ではまさにこれが起こったのです。Oracle MAAの要件定義を見たところ、このことにも言及されていた。これまでの私たちの想定が足りなかったことがわかったのです」と今井氏。

Oracle MAAを使って可用性設計をやり直した同社は、2009年10月頃からプラットフォーム構築に着手。もっとも重視したのは、Oracle MAAを実現するための可用性、そして拡張性だった。「2006年のライブドア・ショックなど、突発的な要因で市場が大きく動き、取引量が3～4倍に跳ね上がることはしばしばあります。そのような状況にすばやく対応できる柔軟な拡張性は必須です」と、同社インフラ統括部長の西賀 与一氏は説明する。
　
もちろん、パフォーマンスも重要だ。「以前のシステムでは、夜間バッチ処理に時間がかかっていました」と語るのは、同社情報システム本部 インフラ統括部の村上 靖氏。さまざまな要因が重なり、4時間以上かかることもあったという。
　
同社では、候補に挙がった製品を3つにまで絞り込んだうえで、2010年11月から2カ月半かけ、100近い試験項目について概念実証実験（POC）を実施。その結果、選定されたのがOracle Exadata Database Machineである。
　
Oracle Exadataは、障害試験ではOracle MAAで規定される可用性をすべてクリア。拡張性についても、「ノードを増やしても性能が下がらず、理想的な形でスケールアウトできました」（今井氏）と高い評価を受けた。
　
村上氏が驚いたのは、レイテンシの少なさだったという。「広帯域のInfiniBandが威力を発揮しており、Cache Fusionのパフォーマンスもきわめて高い」と話す。プロジェクト・マネージャーを務めた新日鉄ソリューションズ株式会社 ITインフラソリューション事業本部 ITエンジニアリング事業部 エンジニアリング第五部の島田 亮氏も、「InfiniBandによる高速化と大容量化で、ノードが増えてもインターコネクト関連の『待ち』がたいへん少なく、追加分の性能向上が100%近く期待できます。これは楽天証券のように、トランザクションが日々増加するシステムのデータベースには大きなメリットです」と評価する。
　
性能比較でも、Oracle Exadataはずば抜けていた。既存システムとの比較検証では3倍以上の性能を発揮。また、CPU使用率96%以上の高負荷状態で52時間の連続稼動や、数GB～20GBのデータで28～7%の高い圧縮率が確認できたという。
　
今井氏は、採用の決め手になったもう1つのポイントとして、「オラクルのコミットメント」を挙げる。「Oracle Exadataは、CEOのラリー・エリソン氏が陣頭指揮を執る戦略商品。ハードとソフトが一体化しているので万一障害が発生したときにも、トータルで責任をもって見てくれるという安心感がありました」

Oracle Exadataの採用が決定されたのは2010年2月頃で、同年9月からアプリケーション・テストやデータ移行テストを開始し、2011年3月のシステム切替えを目指して作業が進められた。
　
新システムは、1つのプライマリ・データベースに対し、フィジカルとロジカルの2つのスタンバイ・データベースで構成。プライマリとスタンバイ間はOracle Data Guardを使ってリアルタイムに同期をとっている。
　
切替え時のトラブルに対する備えも万全だった。具体的には、Oracle GoldenGateを使って旧システムとリアルタイムに同期をとり、万一の場合にも5分で旧システムに戻せるようにしたのだ。「Oracle GoldenGateは、実は保険として入れていました。使わずに済むことが成功の条件になっていました」と同社インフラ統括部 リーダーの前田 佳輝氏は語る。
　
移行が実施されたのは2011年3月18～22日。「本当は負荷が低いときにリリースしたかったのですが、東日本大震災の影響でトランザクションが増え、少し緊張しました」と西賀氏は振り返る。
　
村上氏によれば、データ移行時にミスが発生したものの、Oracle Flashback Database機能を使って事なきを得たという。「システムの移行は業種柄、土日しかできない。この機能がなければ、半日かかるデータ移行を翌週に繰り越すことになったでしょう」と西賀氏。
　
祝日明けの3月22日から国内株取引の負荷が加わったが、新システムは順調に稼動。予定どおり3月31日には旧システムを止め、移行が完了した。

Oracle MAAとOracle Exadataを活用した新システムは、その後も安定して稼動しているという。今井氏は、「以前のシステムでは6筐体でおこなっていた処理を、Oracle Exadataでは1筐体で実現しています。現在は8ノード中5ノードを使っていますが、15分程度でノードを増やせるので、急激なトランザクションの変化に柔軟に対応できるのはとても助かります」と話す。
　
「SQLのチューニングなどはまったくしておらず、とりあえず以前のものをそのまま載せ替えただけ」（今井氏）だが、圧倒的なパフォーマンス向上には驚きの声が上がっている。発注処理で最大200%、株価参照取引処理で最大700%も高速化したのだ。
　
課題だったバッチ処理も大幅に時間が短縮された。島田氏は、「大規模検索のパフォーマンスは特筆すべきものがあります。他のデータウェアハウス・アプライアンス製品にも検索が高速なものはありますが、Oracle Exadataは更新処理も通常のOracleデータベースとして稼動するのが大きなメリット。そのため、他社データウェアハウス・アプライアンスでは実現しにくい『バッチ処理の高速化』が可能です」と説明する。事実、これまでおよそ100分かかっていた処理が60分に短縮され、「さらにチューニングすれば、30分程度にできるでしょう」と今井氏。
　
さらに、今井氏が「じつは一番嬉しかった」と言うのが電力削減効果だ。「旧システムに比べ電力消費量を43%も削減できたうえ、データセンターのコストも年間約5,000万円圧縮。おかげで政府の打ち出す15%の削減目標に対し、すでに10%達成できており、1～2カ月以内に15～20%に達しそうです」と満足そうだ。
　
今後は、さらなるチューニングにより、Oracle Exadataの性能を最大限発揮させてパフォーマンス向上を狙う。前田氏は、「Oracle Exadataの強みは大量検索のスピード。ここで威力を発揮させたい」と語る。西賀氏も「トリプルミラーリングの環境活用を考えたい。可用性を高めると同時に、検索用データウェアハウスとしての利用を実現したいですね」と、スタンバイの有効活用に意欲を見せている。

（本事例の内容は2011年6月のものです）