ホットリンクはこれまでビッグデータ分析を軸にした「クチコミ@係長」というソーシャルリスニングツールの提供を事業の中心にしていました。昨年からは「クチコミ@係長」のマーケティング領域での活用にも軸足を広げた事業展開をしています。
具体的には、SNSコンサルティング、SNS広告運用支援を行っています。

大量のデータを蓄積して検索するところでしょうか。
本番系の物理サーバーは28台のクラスターで構成、容量にして50TBぐらいの規模感です。

蓄積された膨大なデータに対して、大規模なElasticsearchを建て、分散型の検索基盤で高速な検索を実現しています。
また、Elasticsearchと密接に絡み合いながら、分析機能を載せているところも特徴です。
いかにデータをリアルタイムに検索基盤にインポートしていくか、という点が重要なポイントになります。

「クチコミ@係長」は使い勝手が良いという点で評価をいただいております。評価いただいているポイントのひとつとして、応答速度の速さが挙げられます。この部分は分析基盤プラットフォームの性能にも大きく左右されるところです。

データ自体が大容量なので「3台のElasticsearchで扱えるのか？」という懸念がありました。そこに関してはElasticsearchのパラメーターをチューニングすることでクリアできました。
次に検索について「検索性能が出せるのか？」という点を突き詰めていくのですが、いきなり本番並みのリクエストを捌くのはハードルが高かったので、限られたクエリなどを実際に動かしてみて、使い物になるのかの検証から徐々にスタートし、最終的には、本番と同じインデックスの処理を流してみる、という検証を行い、平常時の性能と、ピーク時の性能を段階的に確認していきました。

Elasticsearch自体がJavaで動いているので、メインになるのはElasticsearchのJavaのヒープをどのぐらい割り当てるか、その残りをディスクのキャッシュとして割り当てるというバランスですね。それぞれのパラメーターをチューニングしてどれだけ高速化できるのかを確かめました。
また、Javaに巨大なヒープを割り当てるとなると、ガベージコレクションのパラメーターの調整が必要になってくるので、これも大きなポイントとなりました。

検索についてはどれだけElasticsearchのキューが捌けるのかというのを見ていて、捌けないクエリがキューに溜まってしまうと運用に耐えられないので、キューを捌くために1個1個のクエリの速度をどうやってあげるのか、というのを主に調べました。
そこで大きく問題になってくるのがJavaのガベージコレクションで、起こってしまうと10秒単位でスレッドが止まってしまうので、これをどうやって回避するのかというのを詰めていきました。

今回の取り組みは我々にとってチャレンジングで、いきなりやるのは怖い面がありましたが、両社での検証期間を設けられたことが大きかった。我々としても検証し、このまま進めても問題なさそうという実感を事前に得られたことが良かったと思います。
また、ベアメタルサーバーのマシンのコストパフォーマンスの良さも大きなポイントでした。自前のオンプレミスのサーバー群をリプレイスすることによるコストメリットが得られるということを事前に検証できました。

初期の頃に技術的な協力をしていただいて、使ったことがないメモリのキャッシュや、OSのセットアップからご協力いただき、使える状態まで持っていってもらえたことが助かりました。

この体制が良かったですね。二人三脚で検証を進めようというスタンスで取り組めたことです。コミュニケーションツールなどで気軽に意思疎通を図れる体制にしていただけて良かったなと。やはりグローバルなクラウド事業者だと、こういったことは望めないので、両社一体となって新しいものを作って行こうという形をとっていただけたのは良かったと思っています。