CyberZが提供する広告効果測定ツール「Force Operation X」は国内・海外合わせて現在150社を超える広告会社とシステム連携しています。ワンタグ・ワンSDKという形でF.O.Xで一元的に計測した広告成果情報を各広告会社にリアルタイムに通知することで、広告会社は成果を把握することができ、場合によってはそのデータを基に広告主への請求額を決定しています。
図1 F.O.Xのシステム連携図
したがって、F.O.Xが停止することは、F.O.Xを導入している広告主だけではなく、連携している各広告会社にも迷惑をかけることになるため、たとえメンテナンス中であっても計測およびシステム連携している広告会社への成果通知は一切止めない仕組みの導入が必須となりました。その仕組みをリリースしたのがちょうど1年前なのですが、それ以降は障害・メンテナンス含めて全くシステムを停止させておらず、稼働率100％の無停止運用を実現しています。
アプリケーションとRDBMSの分離
当初はRDBMSとしてMySQLを使い、システムを構築していました。しかし、負荷の高いバッチ処理中に大量のリクエストがあると、計測処理が遅延してしまうという問題がしばしば発生していました。また、バージョンが上がるごとに徐々に改善しているとはいえ、MySQLはテーブルの定義変更でテーブルロックを取ることがあります。このようにMySQLに計測処理が依存していることで、機能追加やメンテナンス作業に大きな制限が生じている状態でした。
現在のF.O.Xでは計測処理がRDBMSに依存しない仕組みとすることで、たとえMySQLに障害が発生しダウンしたとしても計測処理に影響のない作りになっています。そこで検討したのが、KVS系のNoSQLでした。
無停止システムにおけるKVS選定の5つのポイント
KVS選定においては次のポイントが重要となりました。
- 高速であること。
- 負荷分散の仕組みを持っていること。
- 冗長構成を取ることができること。
- データの永続性があること。
- メモリサイズに依存せずデータを保持できること。
特に5点目のデータ容量の上限がメモリサイズに依存しないという点が重要でした。広告効果測定とは、どの広告を経由してユーザを獲得したかという基本的な計測に加え、広告を経由して獲得したユーザが最終的にどれだけサービスを使っているかというLTV（ライフ・タイム・バリュー）を測ることですので、過去の成果情報を全て保持している必要があります。たとえば、課金額をLTVの指標とする場合には、ユーザに対して課金が発生するたびに過去の成果情報と照合する処理が行われるわけです。
多くのアプリケーションやサイトにF.O.Xの採用が進み、保持すべき成果情報も飛躍的に増大している状況でしたので、メモリサイズという比較的到達の早い容量が上限となることは、回避すべきリスクでした。
さらに、F.O.Xではアクセス解析データを広告流入元でレポートできる機能があります。アクセス解析ではアプリケーションの起動や画面遷移といったアクセスログを過去の広告成果とリアルタイムに照合するため、RDBMSでは計測が間に合わず、問い合わせの高速化が課題でした。
多くのKVSはキャッシュという位置付けで処理の高速性をうたう一方、データベースサイズの上限がメモリサイズに当たっていました。そうした中、上記5点を全て満たすことができたものがkumofsでした。
KVSとしてのkumofsの特長
kumofsは、分散型KVSとして複数のノードにデータのレプリカを持つことで負荷分散と冗長性を兼ね備えています。ノードをクラスタに追加していくことで、データ分散と再配置が自動で行われます。更にどのノードに接続しても全てのデータにアクセスできる特性を持っており、高い耐障害性があります。
データストアには内部的にTokyo Cabinetを利用しており、データの永続性が保障されています。性能面に関してはmemcachedのような純粋なキャッシュKVSと比較すれば、ディスクI/Oの発生がオーバーヘッドとなりますが、弊社検証ではMySQLと比較してkumofsでは50倍程度のスループット向上が見込める結果が出たため、全く問題ないと判断しました。
図2 kumofsのアーキテクチャ
また、memcachedプロトコルと互換性があり、当時F.O.Xではmemcachedも利用していたことから、インターフェイスを変更することなくkumofsへ移行できることも開発の短縮という面で大きなメリットでした。
現在のF.O.Xではkumofsでリアルタイムな処理を全て完結させ高速にレスポンスを返す一方で、非同期で計測データをMySQLへと同期させ、集計やレポーティング処理を行っています。
Redisの採用
最後に今後のインフラ構成についてお話します。kumofsの機能的特長は申し分なく、またこれまで全くと言っていいほどトラブルを起こしていないためこのまま使い続けていきたいところです。しかしながら、一点だけ運用上リスクと感じていることがあります。それはkumofsの開発が停止しているということです。
そのため、kumofsが今後何らかのトラブルが発生しても問題が起きないよう、KVSプロダクト自体の冗長化を検討しており、現在はRedisの検証を行っています。基本的には全く同じデータをkumofsとRedisの両方に書いていき、kumofsの製品トラブルに備えようと考えています。
