楽天、性能向上を分散オブジェクトキャッシュで実現。将来のデータ構造変革のプラットフォームとしても期待

2010年7月22日

楽天は、同社ECサイトのバックエンドで稼働している受注データベース、在庫データベースへのアクセスの増大によって、システム全体の性能が低下することに対する解決策を求めていました。

その結果導入したのが、分散オブジェクトキャッシュです。これにより性能面での改善以外に、画面とロジックの分離に成功し、さらにデータベースの運用についての自由度も拡大してます。

7月12日、13日にガートナージャパン主催で行われたイベント「ガートナーアプリケーション＆アーキテクチャサミット2010」のセッション「楽天株式会社にみる変化に柔軟なシステム構造構築の取り組み～SOAとDCPの組み合わせ」で説明された楽天の取り組みを紹介しましょう。

ロジックの分散による複雑化とスケーラビリティが課題

解説されたのは、楽天株式会社開発部アーキテクチャ＆コアテクノロジー課技術理事仲宗根徹也氏（写真右）。聞き手はガートナーリサーチバイスプレジデントの飯島公彦氏（写真左）。

楽天のバックエンドで稼働している「商品購入サービス」は、いわゆるECサイトで買い物カゴを実現する機能を提供しています。しかし、以下のような課題が存在したとのこと。

システム間依存の多さ
アプリケーションロジックの複雑化、分散
改修コスト、品質確保の高コスト化

商品購入サービスを呼び出す部分はライブラリ化され、画面遷移のアプリケーションに埋め込まれていたことも課題の1つだったそうです。

商品購入サービスの構造は以下のようになっています。

商品購入サービスの構造（この図は、セッションでの説明を基にPublickeyが独自に描き起こしたものです）

ECサイトへの来訪者がWeb画面の注文ボタンを押すと、受注確定のAPIが呼び出されます。APIが呼び出されると、受注情報の保存と在庫の更新をそれぞれデータベースに対して実行。2つのデータベースへの操作を2フェーズコミットで確認したうえで、画面遷移を行い、来訪者へ確認画面を表示するという流れになっています。

しかも、受注データベースや在庫データベースは、楽天に出店している店舗用のシステムからもアクセスされるため、注文が集中しているときには店舗用システムの処理も重くなります。

また、受注確定以外にも、住所に応じて送料の計算、会員か非会員かによって画面が違うなど、画面遷移ごとにビジネスロジックを個別に持っているため、さまざまなロジックがアプリケーションの中に分散していたことも課題でした。

分散オブジェクトキャッシュにより、UIとロジックを分離

楽天はこうした課題を解決するために、以下のような改善策を検討しました。

UIとビジネスロジックの分離
ロジックはAPI側に持たせ、UI側はAPIを呼び出すだけ
ライブラリ化したロジックの使いまわしは困難が多い
2フェーズコミットをやめる
データベースの性能に引きずられてスケールしない
アプリケーションが複雑する要因のひとつ
DBへの依存をはがす
データベース停止しても商品購入可能な仕組みにする

そこで採用したのが、APIの裏側に分散オブジェクトキャッシュを採用すること。具体的にはオラクルのCoherenceを採用しました。これによって、以下のような構造となったそうです。

分散オブジェクトキャッシュとしてCoherenceを導入したあとの構造（この図は、セッションでの説明を基にPublickeyが独自に描き起こしたものです）

受注データベースに関しては、必ずしもリアルタイムでコミットする必要がないため、処理をキューイングし、在庫データベースだけは必ず引き落としを行うようにコミット処理を実行。また、APIの中にオブジェクト操作によるロジックも組み込んでいるようです。

APIとデータベースの間にキューイングをする仕組みについては、Coherenceだけでなく、EntityBeanやESB（Enterprise Service Bus）、メッセージキューなども検討したそうですが、それらを入れると複雑なシステムになってしまうため、分散オブジェクトキャッシュのCoherenceにすることがもっともシンプルな構成で、シンプルな使い方を保てると判断したそうです。

分散オブジェクトキャッシュを適用したことにより、具体的には以下のことが実現できるようになったとのこと。

画面とロジックの分離に成功し、ロジックをAPIの中に入れた
UI開発が容易に（APIを呼び出すフレームワークさえ熟知していれば作れるようになった）
各種デバイス向け展開が複数のチームでやりやすくなった。

UIアプリケーションはユーザーのキーだけを管理し、SOAP経由でAPIを呼び出すというシンプルな構成になりました。フレームワークだけでUIアプリケーションの開発が成り立つようになったため、より生産性の高いフレームワークが出たときにはそれに乗り換えることが容易になったとのこと。

ステートの管理は分散オブジェクトキャッシュの仕組みの中に持たせ、UIアプリケーションから渡されるキーでステート管理するようにしています。これでUIアプリケーション、APIともにステートレスに作れるようになりました。

ステート管理のために必ず同じサーバにつなげるといった工夫が不要になり、キーさえ渡せばステートフルなAPIのように運用できるため、システムの裏側で任意のサーバを落としてメンテナンスできるようになったことで運用が楽になったそうです。

つまりCoherenceによって、システム全体はステートレスでも、ビジネス上の情報はステートフルに扱えるという仕組みを実装できました。こうした構成は、クラウド環境でのトランザクション処理のベストプラクティスになるのではないかと思うと、仲宗根氏は発言しています。

ガートナーの飯島氏は「キャッシュテクノロジーというと性能向上のための考えられがちだが、それだけの用途ではないところがポイントだと思う」と、分散オブジェクトキャッシュの性能以外の効用について指摘しています。

データ構造変革のためのプラットフォームとして使える

さらに、店舗側のシステムについてもCoherenceによる分散オブジェクトキャッシュを適用し、新たな構造にしようと考えているとのこと。

Coherenceを入れることで、単純なキャッシュとして負荷をさげるだけではなく、アプリケーションからはSQLの代わりにオブジェクトのput/getによってデータベースの操作を行うため、データベースの抽象化によって、特定のデータベースへの実装依存がなくなり、将来的にはバックエンドで稼働しているデータベース製品をリプレースしやすくなる可能性があるのではないか、と期待されています。

こうなると、アプリケーション側からはどんなデータベースを操作しているかは分からなくなるはずなので、重要度にあわせて商用データベースやオープンソースデータベースなどバックエンドを分割することなどが可能性として考えられています。

分散オブジェクトキャッシュ技術は、「キャッシュとしての利用だけではなく、データ構造変革のためのプラットフォームとして使えるんじゃないか」と仲宗根氏は発言していました。

次の記事≫ SQLの都市伝説。マイケル・ストーンブレイカー御大が斬る！
前の記事≪ クラウドの利用者に保証されるべき6つの権利、ガートナーが提唱