2022年の暮れ、日本オラクルから届いたニュースリリースを見て驚いた。「ベネッセの大規模基幹システムにOracle Cloud Infrastructureが採用」とある。基幹システムをクラウドへ移行した勇気に感心したわけではない。かつて取材したベネッセコーポレーションの「脱オラクル」事例を思い起こしたからだ。
今回アナウンスされたのは、販売管理・新顧客基盤を含む基幹システムの移行完了である。Oracle Cloud Infrastructureが提供する「Oracle Exadata Database Service」上で安定稼働しているのに加え、従来システムに比べて約60％のCPUを削減しながら、性能を維持しているという。
一方、以前に取材した脱オラクルの話は、小学生向けタブレット学習サービス「チャレンジタッチ」を支えるシステムである。オンプレミス環境で稼働していたOracle DBを、Microsoft Azure上のデータベースサービス「Azure SQL Database」へ移行。ハードウエア購入費用やソフトウエアライセンスの削減などにより、月額のランニングコストは従来の7分の1に下がったという。
サーバー6台のクラスタリング構成から移行
先の日本オラクルのリリース中では、Microsoft Azureへ移行済みのシステムを「Webフロント系」と紹介している。今回の移行対象である基幹システムの重要性とコントラストを感じさせる言い回しである。確かに、販売管理・新顧客基盤を含む基幹システムは停止すると「事業」に支障を来す重要なシステム、いわゆるミッションクリティカルだ。
しかし、チャレンジタッチを含むWebフロント系システムは、止まったり、遅延が発生したりすれば会員が離れる原因になりかねない。停止すると「売り上げ」に支障を来す重要なシステムであり、これもミッションクリティカルといえないだろうか。
その証拠に、チャレンジタッチがオンプレミス環境で稼働していた際は、Oracle DB Enterprise Editionでクラスタリング機能「Oracle Real Application Clusters（Oracle RAC）」を使って可用性を高めていた。しかも、データベースサーバーは6台構成という強力なスペックだった。
データベースの歴史を振り返るとき、2001年にリリースされたOracle RACはひときわ輝く画期的な機能だと思う。複数サーバーのメモリー間でデータを共有しながら転送可能とすることで、データの整合性を保ちながら容易にクラスタリング構成が組める。Oracle RACの登場は、メインフレームからオープン系システムへの移行にも一役買っているだろう。
そんなOracle RACの利用をやめ、ベネッセはチャレンジタッチをなぜ別のデータベースサービスに乗り換えられたのか。
