2014年11月に開催した日経BP社主催セミナー「半導体ストレージサミット2014~エンタープライズ分野の主役に躍り出たフラッシュメモリー~」から、楽天グループのプライベートクラウド基盤を担当する高泉 公一氏の講演を、日経BP半導体リサーチがまとめた。3回連載の第2回である今回は、楽天のデータベースの歴史を取り上げる。第1回はこちら。(日経BP半導体リサーチ)

楽天のデータベースの歴史

 続いて、データベースシステムの側面からフラッシュストレージを見ていく。

 私が楽天に入社した2003年当時にデータベースで使用していたシステムは、Fibre ChannelのネットワークとEMC社のストレージ、米Sun Microsystems社(当時)のSPARCサーバーを組み合わせたものだった。ストレージは「EMC Symmetrix」に1万5000回転のHDDをたくさん並べて性能を高めていた。当時は、フラッシュストレージは高価すぎて、使用することなど想像すらできなかった。

 SPARCサーバーに構築されていた巨大なデータベースは現在も基幹データベースとして残っており、それは前述したV-MAX+EFDの上で動いている。同様に、SSDを使用したOracle社「Exadata」のほか、Violin+Oracle Databese、そして私が担当しているRIaaSでもフラッシュを使用している。10年前はなかなか使用できなかったフラッシュだが、現在では使用するのが当たり前のような状況となったのである。

 2000年代初期のデータベースは、SANの共有ストレージでアクティブ/スタンバイ構成を取り、Write I/OとRead I/Oをアプリケーション側が分けるようなシステムだった。Writeについては、SANの巨大なストレージにあるマスターのデータベースに書き込む。Write用のキャッシュメモリーを大量に積んであるため、それがあふれない限りレイテンシーは少ない。Readについては、データベースのレプリケーションの仕組みを使ってスレーブサーバーを作り、性能を高めていた。

 さらに性能が欲しいときにはスレーブを増やすことでReadも増やす、Writeの場合はマスターのデータベースを増やすといったように、どんどん分散させていくことで対応した(図5)。しかしこれは、実際のサーバーが増えてしまう。その分のコストに加えて、運用するためのコストも掛かってしまう。当時は100台以上のSPARCサーバーを使用していたため、このコストが課題となっていた。

図5●データベースのSharding(分割)
図5●データベースのSharding(分割)
[画像のクリックで拡大表示]