今日も会議で、あくびをひとつ

サラリーマン人生を謳歌するためのヒントを、下世話で煮染めてご提供。

【本まとめ】とりあえずログ突っ込んどけ! 「データ分析基盤構築入門 Elasticsearch編」

春眠亭あくびです。

 

※1回目 2018/03/02

※2回目 2018/03/05

※3回目 2018/03/09

→とりあえず読み直し終了。

 

IT関連の書籍のまとめです。興味ない方は下記から退出してください(風俗サイト風)

Yahoo! JAPAN

 

ぼくはシステムの保守運用をやってるんだけど、故障が起こると真っ先にやることがあります。

それは、エラーログを見ること。

よく映画とかで、システムが猛烈にハッキングされたりするのを「ウェイウェイウェイウェイ!」とか言いながら猛烈にタイピングしてなんとかするというシーンがあるけど、あれウソです。

基本はログ見ながらウンウン悩みつつ箇所を特定していきます。

 

そんな大事なログを一箇所にまとめて、手軽に検索できるようにできて、かつライセンスが無料なのが、「Elasticsearch」です。

 

 

 

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

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

 

 

もう少し言うと、

1)ログを集めてきて、(fluentd)

2)格納して、(Elasticsearch )

3)見やすくする、(kibana)

までがこの本で書かれているのですが、今回は2)の格納する部分(つまり、Elasticsearch について)をまとめようと思います。

 

なんでログをまとめるの?

 実際、システム運用にくる問い合わせって、「なんか動かないんだけど」とか「なんかエラーって表示されたような気がするけど次はうまくいっちゃって」みたいな、ものすごいふんわりとした内容ばかりなのです。

それなのにふんわりとした回答をすると「それだとわからないじゃないか!はっきりしたまえ!」となるわけです。

誰でもいいからと女の子を紹介したのに、いざその子を見るとあれこれケチをつける童貞のようなものです。

ではそんな童貞どもとどう渡り合うかというと、それっぽいなーと思うサーバに一台ずつログインして、ログを1つずつ確認しては、「これじゃないか。じゃあ次のやつ見て見るか」なんてことをひたすら地道にやるのです。

地味。

ひたすら地味。

グレーのポロシャツをグレーのチノパンにシャツインするくらい地味。

 

それが、ログが1つにまとまってるとどうでしょう。

見る箇所が1つでいいんですよ?

楽。

超楽。

そして地味な作業が超派手に。

志茂田景樹くらい派手に。

これはもう、ログはまとめるしかないんですね。

 

でもですよ。

確定申告の時の領収書と同じで、まとまっていたとしても整理しておかないとあとで地獄を見ますよね。

どこにどのログがあるのかわからないですよね。

なので、ある程度整理したり検索したりするためにでてくるのが、データストアというやつ。

たくさん保管できるデータベースみたいなもんです。

 

 

データストアは扱いが大変

ログを整理するために データストアに格納しようと書きました。

データストアはデータベースの一種なので、検索をかけたり整理したりが得意です。

ここで結構大変なのが、データ型問題。

例えば、「ジャンル」という項目があったとしてます。

そこには「マジックミラー号」とか「マジックミラー便」というテキストデータが格納されています。

マジックミラー号シリーズかどうかは、このジャンルを見れば整理できていました。

ところが、「マジックミラー号 突撃大捜査隊スペシャル版♪ 花のお江戸のナンパセックス三昧 かくいう私も・・・」みたいにめちゃくそ長いジャンルが出てきたとします。

そうすると、このジャンルという項目の格納できる文字数とか、♪みたいな特殊文字が処理できるようにするとか、データ型を修正する必要が出てきます。

こうやって、データ型は運用してると結構変わりがちなんです。

そして、大半のデータストア、例えば有名なGoogleさんのBigQueryなんていうサービスは、データ型の途中変更なんかはできません。

そうなると、変更するきはデータベースを一から作り直すことになったりします。

このデータ型問題、僕みたいな素人はほんと苦戦します。

Tomestamp型がうまく入らなくて死ぬほどシステムから怒られたりします。

 

そして何を隠そう、Elasticsearch はこのデータ型の変更が途中でできます。

すごい!

マルチフィールドっていう機能でして、昔のデータのデータ型を変更することはできないけど、新しく入ってくるデータのデータ型を変えることができます。

※もちろん、検索する時はデータ型がごっちゃになってることを加味しないといけないので、データ型はそろってるのが望ましいようです。

 

ついでにいうとデータ型を自動で設定させることもできます。

Bigqueryは必ずデータ型を指定する必要がありますが、Elasticsearch は「とりあえずデータを突っ込んでおく」ことができます。

これ、マジで本当にすごい機能なんです。

 

サーバ壊れてもへっちゃら!

この手の無料ライセンス系(OSS)製品って、わりと冗長が弱かったりします。

冗長、つまりサーバが一台壊れても他のサーバでデータや設定保存してるから大丈夫、ってやつです。

Elasticsearch は冗長構成(クラスタ化)がスーパー楽

クラスタを組むには、クラスタ名を設定する。ローカル内で同じクラスタ名のElasticsearch を見つけると、勝手にクラスタ化してくれる。

 

さらにElasticsearch は、壊れても大丈夫以外にも冗長にする意味があります。

それはズバリ、スピードアップ

ひとつのインデックス、つまりDBで言うところのテーブル、早い話がデータの箱があって、その箱を複数のサーバに分割しておくことができます。

この分割をElasticsearch ではシャードと言って、シャード数が多けれは箱をたくさん分割できるから、箱に入れる処理や箱から出す処理も早くなるって寸法。

これも、シャード数を設定するだけ。超簡単。

これを分散システムっていうらしい。有名なHadoop とかと同じ。

で、このシャードはプライマリシャードとレプリカシャードがあって、レプリカシャードはつまりコピー。バックアップ。

このコピーが多ければ、壊れても大丈夫なサーバも多くなります。

この辺もサクッと設定するだけ!

普通ならlife keeperみたいな冗長ソフト持ってきて自分で設定するのに、設定ひとつでできるのはほんとすごい!

 

さらにオールインワン

Elasticsearch の凄まじいところはこれだけじゃないんです。

ログを突っ込んでおくデータストアの役割をElasticsearch は担っています。

ですが、それだけではこちらの要望は満たせません。

例えば僕好みのAVを検索するためのシステムを構築するなら、データを収集する、データを貯める、素敵な画面やグラフでわかりやすく表示することが必要になります。

これ、全部Elasticsearch でできます

正確には、Elastic stackという製品群で実現できます。

Logstash / beats でログ収集(fluentdでなくてもできる)

Elasticsearch でログ蓄積

Kibana でグラフ化

しかもやっぱりライセンス無料。すごすぎる。

 

 

いいところばかりじゃない。注意点(そこそこ詳しい人用)

  • メモリは大きいののせとかないと、パフォーマンスでない。ヒープサイズ(Elasticsearch が使えるメモリサイズ)は、実メモリの半分以下にする。
  • ということは、ライセンスは無料でも、サーバ代金は高くつくので、総じて高額になりがち。
  • 基本、DBではなく、インデックスという大量のファイルの集合体。だから、インデックスが増えても、インデックス自体の中身の容量が増えても、パフォーマンス悪くなる。定期的に削除が必要。
  • 冗長化とパフォーマンスアップで、クラスタノードを増やすのはあり。その時、シャードというデータのコピー数がデフォルト5になってるので、5ノード以上に増やすなら、シャードの設定変える必要あり。
  • インデックスごとにプライマリシャード数を決めるんどけど、途中で変更はできない。あとでノード数が変更になったりしたらインデックス再作成になる。なのでログデータのようにインデックスの容量が大きくなりがちなものは、日付ごとにインデックスを作成するといい。ただこれも、インデックス数が増えすぎても問題だから、定期的に削除が望ましい。ちなみにレプリカシャード数は途中から変えられる。
  • 日付ごとのインデックスを削除したり、管理が結構大変。そこで便利なのがpythonベースのcurator。削除ルールはもちろん、検索対象から外したいけど保存はしておきたいニーズにも対応(クローズ機能)。誤操作でインデックス削除したときに戻せるように、スナップショット機能もあり。

 

 

用語集(そこそこ詳しい人用)

  • インデックス:DBでいう、テーブルのこと。
  • マッピング:データ型とか、いわゆるスキーマ設定のこと。Elasticsearch はスキーマレス。
  • タイプ:インデックスごとにひとつ選ぶ。データ型のテンプレ。
  • ドキュメント:DBでいう、レコードのこと。

 

最後に

これをDBとして使おうとするのは無理がある。だって途中でデータ型変わっちゃうから、一貫性ない。

適材適所で使っていくのがいい。

検索をメインにするのなら、とてもいいテクノロジー。 

すいません、最後マジメになっちゃいました。

 

おしり。