（レポート）第17回Elasticsearch勉強会に参加してきました #elasticsearch #elasticsearchjp

第17回Elasitcsearch勉強会に参加してきましたのでレポートします。

第17回Elasticsearch勉強­会 #elasticsearch #elasticsearchjp

会場はいつものリクルートテクノロジーズさんのグラントウキョウサウスタワーです。オシャレです。

Elastic Stack 5.0 alpha1-5

スピーカー : Elastic 大谷 純さん

Elastic Stack 5.0 の新機能についてご紹介いただきました。

Elastic Stack 5.0のリリース状況

Elastic Stack 5.0 alpha5までリリース済み

バージョン番号「5」について

• なぜ突然「5」なのか
• 今までElasticsearch、Kibana、Logstash、Beatsのバージョン番号が揃っていなかった
• バージョンの組み合わせによりうまく動作しないことがあり、事情を知らない人がバージョンの組み合わせでトラブルとなるケースが多くあった
• そのため、Elastic Stack 5から各プロダクトのバージョン番号を統一

Elasticsearchの新機能

Ingest Node

• 今までElasitcsearchに投入するデータの変換、加工はLogstashなどで処理する必要があった
• Ingest NodeによりElasticsearchでデータの変換、加工を行うことができる
• 例えば、FilebeatでテキストファイルをElasticsearchに投入したい時、データの変換、加工を行う場合、一度、Logstashを経由する必要があった。Ingest NodeによりFilebeatから送信された生のログメッセージをElasticsearchでデータの変換、加工することでLogstashをなくすことが可能となった

Painless Scripting

• 今までGroovyでスクリプトを利用できた。Groovyの実装によってセキュリティホールが生まれることがある
• Painless ScriptingはGroovyっぽい独自の言語。パフォーマンス、セキュリティが高い

Kuromoji

• Lucene 6.0から実装されたn-best costが実装された
• Cost値によってAnalizeの結果を調整できる？
• 漢数字、アラビア数字の変換が可能

Plubinコマンド変更

• bin/plugin -> bin/elasticsearch-plugin

stringがText/Keywordに

• Analyzeするかどうかをフィールドタイプで指定可能
  • Analyzeする : text
  • Analyzeしない : keyword

Netty

• Netty 3 -> Netty 4

_analyze API

• どのようにAnalizeされるか（転置インデックスが生成されるか）を確認できる
• 2.x系までは定義したAnalyzerでしか確認できなかった
• 5.x系から_analyzerAPIでAnalyzerを定義できるようになった

ES-Hadoopの新機能

• Spark2.0に対応しました

Kibanaの新機能

UIの変化

• 画面を広く使える
• ダッシュボードのボーダーがなくなりグラフのサイズ調整が細かく出来る

CSVインポート

• CSVファイルをアップロードすることでインデックスを生成できるようになった

TileMap

• MapQuest を利用できなくなり、TileMap が表示できなくなっていた（Kibana 4.1.10、4.5.3より前）
• Elastic社がMapサーバーの提供を開始した
  • ズームがまだ弱い。改善予定あり

Logstashの新機能

モニタリングAPI

• API経由でステータスを取得できる
  • 入力されたデータ数、キューのデータ数などを取得可
  • Plugin単位で処理数を取得可

IPv6対応

• IPv6を解析可能
• それによりGeoIP２を利用できるようになった

Beatsの新機能

JSON対応

• FilebeatがJSON形式に対応

フィルタリング対応

• 出力するデータのフィールドを絞ることができる

Kafka対応

• 出力先にApache Kafkaが追加された

x-pack

各種サブスクリプションプラグインをx-packに統一。呼び名も変更。

• Shield -> Security
• Watcher -> Alerting
• Marvel -> Moniroting
• Graphはそのまま

ShieldのKibana対応

• Shieldのユーザー管理がKibanaのWeb GUIで可能

Reporting機能追加

• ダッシュボード、Visualizationをエクスポートできる

Elastic Cloud

2種類のサービス

• Elastic Cloud
  • AWS環境でElasticが提供するElasticsearch as a Service
  • Elasticsearch、Kibana、X-Packを提供
• Elastic Cloud Enterprise
  • オンプレミスなど独自の環境にElastic Cloudの環境を立てられる
  • 今はまだPrivate Beta

eurie での Elasticsearch 活用事例 と マルチテナント利用時の設計あれこれ

スピーカー : eurie 池内 孝啓さん

発表前にスライドはアップされていました。

プロダクトeurie Desk の検索機能にElasticsearchを導入してみて、RDBとの連携方法、マルチテナント環境における注意点、Elasticsearchの構成についてご紹介いただきました。

プロダクトの紹介

• eurie Desk
  • ヘルプデスクのSaaS
  • プライベートベータ
  • 問い合わせの検索用途にElasticsearchを利用

RFC 5988 - Web Linking

• Web APIのHTTPレスポンスのLinkヘッダでページネーションを実装
• ElasticsearchのSearch APIではなく、RFC 5988に準拠させたかったので、APIサーバでElasticseearchのレスポンスからクライアントへのレスポンスを生成

RDBとの併用における検討事項

• データストアにAmazon Aurora for RDS、Elasticsearchでデータを保持
• Amazon Auroraでマスターデータ
• Elasticsearchで検索用データ
• 処理フロー
  • 問い合わせデータはRDBまでを同期的に処理
  • Elasticsearchは非同期にデータを投入する

マルチテナント環境の利用

• 権限を持つユーザーのみ参照できる
• アカウントをまたいだドキュメントは禁止したい
• アカウント毎にインデックスを作成する
• アプリケーションで認証・認可を行い、参照の可否、アカウントのインデックスを参照させている

Elasticsearch on EC2 vs Amazon Elasticsearch Service

最初はAmazon Elasticsearch Serviceを採用する方向で検討していた

• IAMベースのポリシーで制御することが難しかった
  • IPアドレス制御：Auto Scaling環境だとIPアドレスを特定できない
  • IAM：アクセスポリシー
• 最新バージョンへの対応が遅い
• プラグインをインストールできない

以上から採用を見送った。

Elasticsearch5.0.0で再インデク­シングの高速化を探究した話

スピーカー : サイボウズ 渡辺 政義さん

Elasticsearch 2.3から実装されたReindex APIを、Scroll search、Bulk APIを並行処理することで高速な再インデクシングした検証・検討記録をご紹介いただきました。

詳細は以下のブログをご参照ください。

Elasticsearch 5.0.0で再インデクシングの高速化を探求する

Scroll searchは初めて知りました。

Scroll search

• インデックスからドキュメントを指定したサイズ単位で取得することができる

Sliced scroll search

• Elasticsearch 5.0.0 alpha-4より実装された機能
• Scroll APIを分割して取得する
• 例えば、ドキュメントが6000件あるインデックスを3000件ずつ2分割し、1000件ずつScrollで取得する、といったことが可能です

Elastic Stackを用いたログ分析・管理

スピーカー : Acroquest Tehnology 樋口 慎さん
Elastic テクニカルワークショップの講師

ログ分析・管理環境のElastic Stack基盤を構築してみてわかったこと、ハマったポイントをご紹介いただきました。

想定するケース

1000〜5000件/sec、1.6億/日、600GB/日

構成図

（所感）Elastic Stackをたくさん利用した構成カッコイイ。es-hadoopを使っている環境初めて見た

Logstash shipper
　↓
Apache Kafka
　↓
Logstash indexer　　→　　HDFS
　↓　　　　　　　　　　　　　↓
Elasticsearch　←Hive-　es-hadoop

Kafka導入のポイント

• Logstashのキュー溢れによるデータロストを防止
  • スパイクアクセスなどによる大量のログ発生時、Logstashの処理速度をログ発生量が超えた場合にキューが溢れてデータロストが懸念される
  • 一度、Kafkaでキューイングし、Logstashが捌ける量を取得・処理することで、データロストを防止する
• データを再取得できる
  • 例えばパースに失敗したログデータをそれようにインデクシングしておく
  • 想定外のルールのLogstashのコンフィグを生成
  • 再度、Kafkaから取り出して、インデクシングすることでデータロストを防止

es-hadoop導入のポイント

• データ量が大規模な場合、Elasticsearchの運用コストが高くなる
• Elasticsearchには検索・分析に必要なデータを投入する
  • 期間を絞る
  • フィールドを絞る
• HDFSに生データを保管する
• HDFSにあるデータを分析したい時にHive（es-hadoop）でデータを投入する

ハマったポイント

• Logstash でパースに失敗するデータがあった
• 原因：UDPで送られてくるメッセージがあり、文字数が長いメッセージの送信に失敗していた
• 対策：TCPで送るようにして、TCPで受けるようにした（送る側の都合もあるのでTCPに対応できる場合に有効）

• Hive - Elasticseearchの型変換

• 原因：Hiveにipやgeo_pointといった型を持っていないためそのままデータ投入するとstringなどでえ認識してしまう

• 対策：事前にインデックスを定義しておき、Mappingを定義しておく

• hive側のスキーマを定義にしておく必要があった

• 事前にログを知っておく、hiveの処理
• Hiveのカラム名は大文字小文字を区別しないが、Elasticsearchは大文字小文字を区別する

まとめ

Elastic Stackの代表的な機能、ユースケースは把握していても、実際の商用環境で使ってみないと分からないことが多くあります。今回は商用環境に導入したお話が2件聞けて非常に勉強になりました。