猫でもわかるWeb開発・プログラミング

本業エンジニアリングマネージャー。副業Webエンジニア。Web開発のヒントや、副業、日常生活のことを書きます。

トップ > プログラミング・開発 > LINE Developer Meetup in Tokyo #27 -Elastic- メモその2 LINEデリマでのElasticsearchの運用と監視の話

LINE Developer Meetup in Tokyo #27 -Elastic- メモその2 LINEデリマでのElasticsearchの運用と監視の話

プログラミング・開発

もくじ

LINE Developer Meetup in Tokyo #27 -Elastic-

以下のイベントに参加してきました。

line.connpass.com

3つの発表が行われたのですが、今回はこのうち『LINEデリマでのElasticsearchの運用と監視の話』を聞きながら書いた僕のメモを公開していきます。

資料

発表資料はこちらで公開されています。発表資料と並行して見るのがいいかも。

www.slideshare.net

本

今回の勉強会で登壇したElasticの大谷さんが書いた本もあるようなので参考にしてみるといいかもしれません。

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

メモ

目的: LINEデリマにおけるelastic searchの監視について説明する

LINEデリマとは

  • フードデリバリーサービス
  • 2017.07.26〜
  • twitter: @linedelima
  • 懇親会のフードはLINEデリマで用意したものではなかった！

リリース当初のelasticの構成

  • master1台、data2台で運用していた
  • これは問題がある（分かる人には分かると思うが、後に説明）
  • LINEデリマのサーバーサイドはJAVA

プレスリリース時の対応について

  • プレスリリース時にElasticsearchサーバーに大量のリクエストが（4000req/s）
  • 急遽2台のサーバーをクラスタに追加（openstackを使っている）
  • クラスタの追加はAnsibleを使って行う
  • master1台、data4台という構成になった

とりあえずこの日の負荷には耐えられるようになった

プレスリリース後

  • masterが1台しかおらず、こいつがダウンするとアカンという問題がある
  • masterはクラスタ管理だけを行い、検索対象にはしないようにする
    • masterに検索要求が来た場合、dataノードからフェッチしてそれを返すような動きをする
    • masterはdataノードの管理だけを行う。こうするとmasterの負荷はすごく少ない

master3台の構成になった！

予めセットアップしていたmasterをクラスタに追加。変更作業は20分程度。

indexingだったっりESのrebalanceなどは止めずに実施したが。とめたほうがいい。Shard Allodation Settingを参考に

Admin（管理ツールとか）からElasticsearchを使いたい

Admin（多分管理ツールとかそういう系）からElasticsearchを使いたい。（Adminからのクエリが重かった場合にサービスに影響が出たらアカンので）サービスで利用しているdataサーバーには影響を与えたくないので、zoneを分けてdataノードを追加。

  • masterは共通のmasterでいい
  • 検索フローなどは同じzoneで閉じるので、AdminはAdminのゾーン内だけで処理できるので、Adminで重いクエリを投げてもサービスに影響はなし！

地上波でサービスが紹介された時

テレビで紹介されて、プレスリリース時以上に負荷がやばなりそう。Threadを使い果たしてQueueが溢れたりしそうなのでチューニングを行った。

  • Thread Poolのサイズの変更
  • Queueのサイズを大きくする（1000→3000）
    • Threadがいっぱいになった時にはQueueに積まれるという挙動する
  • ※Elasticsearch 5の設定なので6では異なっている。注意。

実際に放送されて

  • 放送前: 150prs, 3-4ms search time, Queueは使われていない
  • 放送後: 750rps, 3-4ms search time, Queueは使われていない

結局Queueは使われなかったが、チューニングによって乗り切れたのかなという感じ。

現在

現在は問題なく稼働している

監視

これまでの監視はどうしていたか

  • 内製アラートツール
    • 提供部署に設定変更などは依頼
  • IMON（内製アラートツール）
    • Javaで書かれている

問題: 詳細な監視項目の設定ができなかったり、監視項目の変更などがめんどい。

これからの監視

Prometheus & Graphan & Promgena

Prometheus

  • 設定に応じて、対象のサーバーに定期的にメトリクスを取りに行く
  • 各サーバーにはAgentがいて、そいつにHttpリクエストを行うことでメトリクスを取得
  • 閾値超えたらアラートなどなど

Graphana

  • Prometheusのデータを元にグラフ描写

Promgen

  • https://github.com/line/promgen
  • LINE製のパラメータあれこれするやつ
  • LINE Developer Blogとかにある
  • Casual Talkみたいなイベントもやっている

ESとPrometheus

今後

  • Elasticsearch 6系にしたりなどなど（アップデートの検証は完了している状態）
  • 個人的にはElasticsearchの検証記事をPublicに公開していきたい