雑文発散

▼ [Elasticsearch] 第10回 Elasticsearch 勉強会へ参加してきた昨日の話

昨日、第10回elasticsearch勉強会 へ参加してきた。

えっ、日記なのに今日の話じゃなくて昨日の話を書くのはどうなの！？という思いもあるけど、昨日は別の話題で、ちょっと長めの日記を書いてしまっていたので、日を分けてしまおうという考え。まぁ、なんだ、ネタ切れ防止だ。

ちなみに少なくとも2014年1月1日から今日まで、途切れなく毎日この Web 日記を書いている。ただ、気負い過ぎるとツラくなるので「ネタが無い場合にはヒトコトで良し！」という方針でやっているので、わりと気楽だ。

まぁ、そんな話は置いておいて、勉強会の感想など。

Elastic{ON}の報告と商用プラグインの紹介

Elasticsearch およびその周辺にまつわる初の単独カンファレンスであるところの elastic{ON} の紹介など。このときに Elasticsearch から Elastic へ社名を変更した。

また、Elasticsearch を AWS 上で構築して商用サービスをやっている Found 社の買収についてもこの時に発表されたらしい。Found 社のサービスは、ES のバージョンアップとかもマネジメントコンソール的な画面からポチポチやっていけるらしい。

Elasticsearch は最初の構築が簡単なので導入時はいいんだけど、いざ運用に入るといろいろな問題が発生しそうな予感はある（まだ体験していない）。こういう「サービス開発の本筋ではないところ」を運用してくれるサービスはこれからも増えていくんだろうな。

elastic{ON} の講演のサマリでは、名だたる企業が ES を使っている様子が伺えた。Microsoft は msn や Azure Search などで利用。Yelp は Solr から ES へ乗り換え。GitHub の検索も ES だし、Wikimedia でも利用されているとか。あとは企業ではないけど NASA では、宇宙にある機器からのデータを ES にブチ込んでいるんだとか。「宇宙」って聞くだけで盛り上がる人種には、ES と関わっているだけで嬉しくなる話だ。

Facebook でも社内で使っているとか。（社内？）ハッカソンで使ってみて、いいね！ということになったらしく、内部システムで利用しているとか。

それから Elastic 社の有償プラグインである Marvel、Shield、Watcher についての紹介。

Marvel は ES のクラスタやノードの状態（ヒープサイズ、ディスクサイズなど）の監視に利用でき、その取得データを Kibana 上で閲覧するもののようだ。またクエリを投げる UI もあり、そこでは Elasticsearch API のサジェスト機能や JSON の構文チェック機能などがあるとか。

Shield は ES をよりセキュアにするためのもので、誰でもアクセスできちゃう割とオープンな仕様の ES のユーザー認証・認可などが行えるようになる。また ES のクラスタ内での通信も SSL 化できるそうだ。あと、重要なデータを入れた場合に必要になってくる監査ログの取得・閲覧機能もあるそうだ。

Watcher は、まだベータ版で、クエリによる監視・通知サービス。定期的にクエリを投げて「システムとしては正常かどうしているが、データに異常値が見つかった」などの検知に使えるみたいだ。この検出をトリガーとして、メール送信やら Slack などへのチャットへ投げたりできるとか。

企業内に入れていくなら、このあたりのプラグインは欲しくなるね。うまいところを付いている商売だと思う。

Aamazon Web Service で実現するelasticsearchの大規模運用

【資料はまだアップされてないかも】

自社サービスでの Elasticsearch の利用内容と AWS Auto Scaling での利用事例の紹介だった。

パブリック DMP として、現在約4億件のデータを ES に蓄積・検索をしているそうだ。提携している各メディアからの来訪者情報、閲覧履歴やネットリサーチからのアンケート情報などを絡めたセグメントを広告配信ツールへ提供してエンドユーザーの趣味嗜好などに合わせた広告配信を実現するためのサービスの一角を担っている。

全て AWS 上に構築し、クラスタがひとつで Type もひとつというシンプルな構成。そこにノードが 86 台あるそうだ。86 台の内訳は、マスタ（データは持たない）が3台で、データ（マスタ機能は持たない）が80台、検索を受け付ける ES が2台にインデクサ（index を作成する役割）が1台。さらにこのフロントに ELB が置かれている。インデクサ以外は Auto Scaling の対象になっているそうだ。

この構成に決める前に、負荷試験などを行なってみたそうで、ノード数 == シャード数の状態では100台くらいまで性能向上が見られたが200台くらいで検索のパフォーマンス劣化を見つけ、シャードとノードの比率が 1 を超える（例えばシャード 10 に対しノード 8 とかの状態？）だと、パフォーマンス劣化が見られるなどを発見したそうだ。

インスタンスの性能については、SSD の性能重視で選択し、c3 ファミリーに。コストパフォーマンスを考えて xlarge にしているそうだ。

Auto Scaling は、100台単位のクラスタを数人で回すために必要だったとのこと。運用コストを減らす対策。その一方でスケールアウトしやすくなったというメリットも出たそうだ。

Auto Scaling って、急な負荷のときの対策というイメージが強かったんだけど、一定数の規模のクラスタを運用し続けるという使い方もあるんだね。そこが分かってなくて、勉強会の最中にはあまりピンと来ていなかった。よく見たら AWS のドキュメントにも「必要な数の Amazon EC2 インスタンスを確実に実行するための助けとして、Auto Scaling を使用することができます」と書いてあったわ。

「一定数の規模のクラスタの維持」の話だということでリカバリの話もあった。コケたサーバとか、ライフサイクルにより入れ替わったサーバを復帰させるときのリカバリ処理を速くする TIPS。indices.recovery.max_bytes_per_sec をデフォルトの 40mb から 500mb にしているとか。こういった設定などで、CPU 4 コア、データ量 40GB のノードが10分程度でサービスインできるそう。

これが速いのか遅いのか、ちょっとまだオレの感覚にはないなぁ。。。

ELB のヘルスチェックは、検索受付用サーバ以外にも実行しているそうだ。これはリカバリしたノードで、ごくたまに ES がうまく立ち上がらない場合があるからだそうだ。9200 ポートを叩いて返事があるかどうかでチェックしてるそう。

Q&A コーナーでは、検索用ノードを分けた理由についての質問が興味深かった。もともとマスタノードで検索をしていたが、激しい検索で GC が発生してマスタノードがコケたからだそうだ。「激しいクエリ」がどのくらいなのかは分からないけど、そういう可能性があるという良いノウハウを聞けた。

Spark in small or middle scale data processing with Elasticsearch

【資料はまだアップされてないかも】

ビズリーチ社での利用事例。Scala で Elasticsearch を叩いているそうだ。Scala の知識が無かったので、そのメリットについてはあまり分からなかったけど、サービス構築までの裏話が聞けて面白かった。

サービス開発は1年くらいかけたのだけど、その間に何回か作りなおしたりしていたそう。当初は AWS の CloudSearch を使っていたそうなのだが、今回のサービスは「検索」そのものに重きを置いているので、そのキモの部分をブラックボックスである CloudSearch に任せてしまうことへのリスクを考え、ES にしたとのこと。ES なら自分たちで手を入れることが可能なのもプラスポイントになったそう。

当初のアーキテクチャでは、クロールしてきたデータを入れる ES と、そのデータを元にして検索用データを投入する ES を分けていた。そこをふたつに分けていくことにより、それぞれのサービス開発のライフサイクルの違いを吸収。別々にデプロイしやすくしたそうだ。

データ量の増加と作業の反復などを踏まえて、Apache Spark を導入して分散処理ができるようにしたそうだ。ただ、初期には map のタスク数 == シャード数にしてしまい、タスクが分割されないというミスも。また、Spark で大量に書き込みを行ったら、シャードが壊れてしまう事故も発生したので、設定値の一部を低くして書込しすぎないようにしたんだとか。

現在ではアーキテクチャの一部を変更して、Spark Streaming を導入しているそうだ。クロールしたデータは ES へ入れるのではなく S3 へ登録、Spark Streaming で S3 を監視し、新しいファイルがあれば処理を開始するというスタイルになっているとか。

Elasticsearchのサジェスト機能を使った話

サジェスト機能の話もさることながら、先日の Testing Casual Talks #2 のときに引き続き、Gatling の名前が出てきた。負荷試験には Gatling がいいのかもなー。

Elasticsearchで作る形態素解析サーバ

形態素解析のいろいろな準備が面倒なので、Elasticsearch の API を使って、形態素解析 API サーバを作っちゃおうという話。ちょうどこの辺について興味があったので、似たようなことを試してみたい。

開発効率UP! Elasticsearch Client Tool 作ってみた

Sublime Text 3 の拡張（プラグイン？）で Elasticsearch にクエリを投げたり結果をみたりするヤツだそうだ。Emacs にも es-mode があるので試してみたい。

あと、Hello! Elasticsearch. のなかの人だったとは。いろいろ勉強させてもらってます。

変わり種プラグインの作り方

【資料はまだアップされてないかも】

Elasticsearch のプラグインは簡単に作れるよ、いろんな部分で作れるよ、という話。フック出来る箇所がたくさん良いされているそうだ。

アプリケーション側で行われている処理を ES のプラグイン化してしまえば、ES 本体のクラスタ機能により、処理が分散でき、スケールするという考えが面白かった。そういう発想は無かった。

全体を通して

いろいろな方面の話があって面白い回だった。実況ツイートという名のメモを書いていたけど、自分の知識の範囲外の単語も出てきて、なかなか大変だったけど、勉強になった。まさに勉強会。

開催ありがとうございました。