Kibanaのマルチテナント運用について考えてみた(前編)

こんにちは。
@shin0higuchiです😊

最近Elasticsearch + Kibanaをマルチテナントで利用する方を多く見かけます。
そういったときに問題になってくるのが、セキュリティですね。

たとえば

• 「一部のダッシュボードだけを見せたい」
• 「編集できないようにしたい」
• 「ダッシュボードの存在を知られたくない」

など、色々とセキュリティ要件が発生するはずです。

この記事では、実際に上記のような設定ができるのか、どうやって設定するのかといったところを
改めて整理してみます。
※多少回りくどい検証過程を書いているので、「結局どうしたらいいの？」という部分のみ知りたい方は、後編にご期待ください。

バージョン情報など

macOS High Sierra version 10.13.2
Elasticsearch 6.1.1
Kibana 6.1.1
Logstash 6.1.1
x-packはElasticsearchとKibanaにインストールしています(試す場合はトライアル版で構いません)

目次

1. 下準備(サンプルデータの内容など)
2. indexごとに制御
3. ダッシュボードの閲覧専用ユーザー(後編)
4. ダッシュボードの存在を隠す(後編)

下準備

まずは、今回の記事で使うサンプルデータについてです。

想定として、自分がkibanaによるログ可視化サービスを提供しており、クライアントとしてA社およびB社がいると仮定します。
さらにクライアントの中にも、管理者と一般ユーザーがいると仮定しましょう。
整理すると下のような4種類になります(厳密にはサービス自体の管理者を含むと5種類)

	A社	B社
admin	A社のダッシュボードを編集できる	B社のダッシュボードを編集できる
一般社員	A社のダッシュボードの閲覧のみ可能	B社のダッシュボードの閲覧のみ可能

作成してあるダッシュボード

ダッシュボード名	使用index	概要
[A社]売り上げ推移	company_a	A社の売り上げ推移を可視化したダッシュボード
[B社]売り上げ推移	company_b	B社の売り上げ推移を可視化したダッシュボード
[管理者]売り上げ推移ダッシュボード	company_a, company_b	A社B社のデータを横断して推移を可視化したダッシュボード

それぞれのダッシュボードは下の画像のようになっています。
（機能確認用のサンプルなので必要最低限の内容です）

• [A社]売り上げ推移

• [B社]売り上げ推移

• [管理者]売り上げ推移ダッシュボード

各ユーザーごとの権限は下記の通りです。

	[A社]売り上げ推移	[B社]売り上げ推移	[管理者]売り上げ推移ダッシュボード
admin	編集可能	編集可能	編集可能
userA_admin	編集可能	閲覧不可	閲覧のみ※
userA_general	閲覧のみ	閲覧不可	閲覧のみ※
userB_admin	閲覧不可	編集可能	閲覧のみ※
userB_general	閲覧不可	閲覧のみ	閲覧のみ※

※自社データのみ閲覧可能

index毎に制御

まず、もっともシンプルなアクセス制御方法として、index毎の権限を設定する方法があります。
例えば「userA_adminにはcompany_a indexへのall権限」、「userB_generalにはcompany_b indexへのread権限のみ」といった具合です。
この部分は非常にシンプルですが、実際にKibanaで設定してみます。

既に使ったことのある方はご存じかと思いますが、
Elasticsearchのアクセス制御の仕組みは、Roleとして権限グループを作成し、そこにUserを結びつけることで実現します。

ではまず、A社のadminである「userA_admin」について見ていきます。

最初に、Roleとして「roleA_admin」を作成します。

Create roleを選択し...

Role名および権限を設定します。
ここではcompany_aというindexにall権限を付与しています。
※Cluster Privilegesに関する説明は本記事では割愛します。要望があれば別途まとめる....かもしれません。

次にroleA_adminのロールに紐付くユーザーとしてuserA_adminを作成します。

Create userを選択します。

userA_adminという名前のユーザーを作り、Roleとして、「roleA_admin」「kibana_user」を付与します。
（kibana_userについては後述します。kibanaを使うために必要な権限だと考えてください。）

userA_adminでログインして、ダッシュボードを確認してみます。

上がA社のダッシュボード、下がB社のダッシュボードです。
B社のダッシュボードは見えなくなっていますね。
※ただし、「B社のダッシュボードが存在すること」がわかってしまいます。この問題については後述します。

他のユーザーなども同様に作ります。

試しにuserA_generalも試してみます。
期待する挙動はA社ダッシュボードの閲覧のみができることです。

しかし....編集できてしまいました....

そうなんです。
Kibanaのダッシュボード自体の情報は、.kibanaというindexに保存されているので、
company_aのindexを制御しても、ダッシュボードの編集や削除ができてしまうのです。
B社のダッシュボードが一覧に表示されてしまったのもこのためです。
つまり、ダッシュボードの編集権限をカットするには、.kibana indexへの権限を制限する必要があります。

少し長くなってしまったので、その方法に関しては、後編で書くことにします。
ご期待ください☺️

Acroquest Technologyでは、キャリア採用を行っています。

• ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
データ分析基盤Elasticsearchを使い倒したいエンジニア募集！ - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com

モブプログラミング×ブログ ＝「モブブロギング」に挑戦しました

皆さんこんにちは。
@tereka114です。最近とっても暑いですね。

社内で試しにモブブロギングをやってみました。
モブブロギングはモブプログラミングが派生した活動で、
皆で１つのブログを書く取り組みです。このやってみたモチベーションは次のとおりです。

1. 特定の人が書き続けている。
2. 書き慣れている人の暗黙知がある。
3. 知識の共有をしたい。

そこで、会社の寮でモブブロギングを当社の若手で試しに行ってみました。
モブブロギングの成果物はこちらです。

acro-engineer.hatenablog.com

モブブロギング

作業内容

本日の作業は次の通り行いました。

1. 導入・・・モブプログラミングとは何かの説明
2. 設計・・・課題感・作業内容を明確にする。
3. 実装・・・検証内容の実装・検証
4. 執筆・・・ブログの執筆を行う

13:30〜

まずは、導入です。
モブプログラミングとはどういったものかを説明しています。
説明には、次のスライドを利用しました。

speakerdeck.com

特にモブブロギングはおろかモブプログラミングがはじめてなので、
心理的安全性の箇所に書いてある「ヤッター！！」という部分を主に説明しました。
うまくいった時にうまくいったことを共有して、モチベーションを保っています。結構難しいものです。

13:45〜

まずは、お題の整理をしました。
お題は上司から言われて検証したいと依頼された内容です。
そのため、課題のイメージの認識あわせと作業を明確化し、
時間がかかりそうな部分はワークフローを分担しました。

14:00〜

データの投入の時間長いので、その間に執筆していました。
今回、執筆は普段書き慣れていない人に担当してもらいました。
というのも、書き方を共有をしたいとの考えがあり、暗黙知的な何かを共有するために実際にやってみました。

15:15〜

2.2GBのApacheのログを利用し、投入していました。
別途、裏で何人かで準備を進めていた内容が終了し、「やったー」みたいな感じになりました。

検証内容の都合上、もう一つIndexが必要となったので、その間にReindexを開始しています。

16:00〜

だんだんとブログの内容が固まってきました。
ただ、細かい説明の記載が難しくなってきているので、
より正しい理解を共有するために皆でディスカッションしています。
詳しい人が複数人集まると議論ができて勉強になります。

16:15〜

Reindexが完了し、実装側の画面を写しています。
参加者で状況を共有しつつブログも併せてブラッシュアップしています。

16:50〜

作業用BGMの変更とforce mergeを開始しました。
皆でいけっーとかいっていました。（あっという間に終わりましたが・・・）

17:00〜

検証で必要な結果を出し終えたので、ブログの仕上げを開始しました。
結果を出してみての確認やフッダー、タグなどの確認をしています。

17:30

Finish!!　最後の喜びのポーズ

やってみてどうだったか？

良かった点

技術的な知見を共有できた。

Elasticsearchを深く使っている人からそれなりに使っている人もいたので、知識の差がありました。
この記事を書いている私も知らないことが多く、非常に勉強になりました。

心理的安全があった

皆で検証していたので仮説の誤りが少なく、
一人では、はまったところでも助け合えました。
もちろん、皆で感動を分かち合いました。

改善点

いろんな人が様々な話をしだした。

モブプログラミングだけに皆が自由に発言をしすぎて
ドライバを混乱させてしまった場面が時々ありました。
この点は発言の内容や論点を明確に話す必要があると感じています。

最後に

モブブロギング楽しい！
暗黙知・知識の共有といった点は、途中の議論のタイミングで適宜、認識を合わせられたことにより、
得られるものが多く、非常に良かったと思っています。
しかし、ドライバがよりうまくやっていくためには、各々が整理して話していくことが課題になるとも感じました。

今後も皆で共有したい！と思うことを書いてみると成果が出ると感じました。
実際のモブプログラミングもやってみたいです！
次回はもっと面白い内容をやってみます。

Acroquest Technologyでは、キャリア採用を行っています。

• ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

モノリシックなアプリケーションをマイクロサービス化したいエンジニア募集！ - Acroquest Technology株式会社のWeb エンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com

ElasticsearchのShrink APIを検証した

こんにちは。
最近暖かくなってきて春を感じている新人エンジニアの片岡です。
elasticsearch運用時には、indexのライフサイクルマネジメントとして、
書き込みせずに参照だけになるindexに対してshard数の変更やforcemergerを実行してメンテナンスする必要ありますよね。
elasticsearchでは一般的な手順として次のような手順を実行します。

1. shard数の削減
2. 圧縮形式の変更
3. merge処理を行いセグメントをまとめる

elasticsearchではデータを保持する際に裏で圧縮を行っています。
そこで、圧縮方法の違いやmerge処理によるサイズ変化への影響を検証してみました。

検証概要

次の検証を行いました。

1. 2.2GBのApacheログをelasticsearchに投入し、Primary Shardの数を5に設定した。
2. Shrink APIを使ってshard数を削減し、Primary Shard : 1にする。
　その際圧縮方法をLZ4→Best Compressionに変更する。
3. force mergeを実行する。

shard数を減らせるShrink APIを用いて、shard数を減らしたり、圧縮方法を変更したりしています。
データが圧縮されたかどうかはディスクサイズを確認して検証しました。

今回はelasticsearchを自分のPC一台で立ち上げています。
そのためReplicaは生成されないのでReplica数は0にして検証を行っています。

検証環境

OS X 10.1.3
elasticsearch 6.2.1

検証内容

初期状態

まずはデータを投入した段階のshardの状態をcat APIを使って見てみました。
元のデータサイズである2.2GBと比べると2倍以上の大きさになっていますが、
これはelasticsearchがデータを持つときのオーバーヘッドや、Logstashの加工による影響があるためです。

圧縮形式:LZ4

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open apache_log vMBqxqeQS46IoALeCsW_UQ 5 0 10310474 0 4.7gb 4.7gb

Shrink API

初期状態からShrink APIをたたいてみました。

POST apache_log/_shrink/best_compression
{
    "settings": {
        "index.number_of_replicas": 0,
        "index.number_of_shards": 1, 
        "index.codec": "best_compression" 
    }
}

実行したときのレスポンス遅延はほとんどありませんでした。
shrinkのマニュアルにありますが、即応答を返して、非同期でshrink処理が実行されるからですね。

The above request returns immediately once the target index has been added to the cluster state — it doesn’t wait for the shrink operation to start.

www.elastic.co

結果は以下。
best compressionにしたらstore.sizeが大きくなってしまいました。
公式HPを見ると、

Best compression will only take affect when new writes are made to the index,
such as when force-merging the shard to a single segment.

とあります。圧縮方法の変更は新しく書き込まれたデータにしか適用されないなので
force merge等を利用する必要がありますね。

www.elastic.co

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open apache_log vMBqxqeQS46IoALeCsW_UQ 5 0 10310474 0 4.7gb 4.7gb
green open best_compression UgRAepvGR1Or1Pl3MZLqOQ 1 0 10310474 0 6.8gb 6.8gb

Force merge

複数のセグメントを1つにまとめるmerge処理を強制的に行うAPIです。

POST best_compression/_forcemerge
{
    "max_num_segments":1
}

結果はこちら。

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open apache_log vMBqxqeQS46IoALeCsW_UQ 5 0 10310474 0 4.7gb 4.7gb
green open best_compression UgRAepvGR1Or1Pl3MZLqOQ 1 0 10310474 0 4.3gb 4.3gb

best compressionされました。
LZ4と比べて8%削減されましたね。

検証結果

以下のように検証を行いディスクサイズが変化しました。

まとめ

ShrinkAPIを実行しただけでは圧縮が適用されないということ、
また、Shrink APIを実行すると、一度データサイズが大きくなることには注意が必要ですね。

Acroquest Technologyでは、キャリア採用を行っています。

• ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

データ分析基盤Elasticsearchを使い倒したいエンジニア募集！ - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com

言語処理学会2018の「形態素解析の今とこれから」で発表してきました！

こんにちは！新人エンジニアの佐々木です。
私は3/15,16と岡山に行っていました。

何をしに行ったかというと、言語処理学会2018の最終日の
「形態素解析の今とこれから」というワークショップで一般発表をするために行きました。

私が今回発表したのは、
「検索サービスにSudachiを適用して運用コストを軽減した話」
というタイトルです。
新しい形態素解析器であるSudachiをElasticsearchに適用して得られた
効果について話しました。

資料はこちら

検索サービスにSudachiを適用して運用コストを削減した話 from Sasaki Takashi

発表後にSudachiの開発者の方や、もうすでにSudachiを適用してみた方、
または同じく検索サービスを運用しているエンジニアの方と
お話しできたことが非常にうれしかったです。
やはり誰でも複数の分割単位というのは、待ちわびていた機能のようです。
私も非常に便利だと思います。

また、このワークショップ自体も形態素解析の話だけで１日すべてを使うという
かなり硬派なワークショップでしたが、普段使っている形態素解析器（Mecab,KyTea,JUMAN++,Sudachi）や辞書（NEologd,Unidic）の
開発者から発表があって、それぞれどういう構造または、思想で作られたのかなどを
知れてとても面白かったです。

NEologdの開発者の講演や

Mecabの開発者のからも！

今回は、2日間だけの参加となりましたが、来年は
フルで参加してもっといろいろな人の発表を聞いて、
いろいろな人と話したいと思った2日間でした。

それではまた。

Acroquest Technologyでは、キャリア採用を行っています。

• ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

データ分析案件で時系列データの異常検知に挑戦したいエンジニアWanted！ - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com

Elastic{ON} 2018 最終日セッションレポート LogsとMetricsとAPMをElastic Stackで統合 #elasticonjp

こんばんは。@muraken720です。

3日間に渡るElastic{ON}があっという間に終わってしまいました！
伝えたいことが多すぎて困ってしまいますが、少しでも雰囲気をお伝えできればと思います。

Elastic社APMチームのPMであるRasmusさん、Tech leadのRonさんらと共に記念写真。

今日参加したセッション

私が本日参加したセッションと概要は次の通りです。

1. The State of Geo in Elasticsearch
   • Elasticsearchの2.x => 5.x => 7.xのGeo周りの進化について。仕組みが体系的に説明され、なぜElasticsearchがGeo系の処理が得意なのかを説明してくれていた（と思う）。Vega/VegaLiteにも地図表現があるので増えたよ。
2. Kubernetes, Docker, and Containers at Elastic: Monitoring, Logging, and More
   • Kubernetes(k8s)でDockerコンテナを運用する上で実際に何をMonitoringするかについて。豊富なDashboardでの可視化例が参考になりました。
3. Logs, Metrics, and APM: The Holy Trinity of Operations
   • ログ、メトリクス、そしてAPM。なぜElasticsearchでこれらのデータを収集し、いま一つのスタックで分析できることの意味とは。複数の異なるindexを一つのグラフにまとめて可視化する例は非常に参考になりました。
4. Managing the Elastic Stack in Production
   • 実際にProduction環境になったらどのようにElastic Stackを管理しないといけないか。基本的な戦略が紹介されていたが、ちょっと学びが少なかったです。
5. A Security Analytics Platform for Today
   • セキュリティ関連のログをElasticsearchに入れて、ルールベースのAlertとMLを使った検知を行うという内容。残念ながらあまり学びがありませんでした。。。早めに終わったのでその足でSecurity Analyticsのデモブースに行ってGraphの話を聞きました。
6. Lyft's Wild Ride from Amazon ES to Self-Managed Elasticsearch
   • Lyftが成長していく中で、Splunk ⇒ AWS ES ⇒ Self-Managed ESと変化していった経緯を皮肉？を織り交ぜて説明。終わった後は参加者の質問の列ができていました！

その中から、今回は同じようなAPM製品を作ってきた自分たちとして、いろいろ思うところがあった「Logs, Metrics, and APM: The Holy Trinity of Operations」についてのレポートをお送りします。

APMの登場。Logs、Metrics、APMの特徴を理解する

まずは導入として、Logs、Metrics、APMとは何を指すのか？という定義から。

• Logs
  • records of events
• Metrics
  • periodic numerical measurements
• APM
  • application performance monitoring

こういう現在地点をあらためて確認することで、これから複雑な話をするよ！というスタートは好きです。
前のせろ氏はあまり興味なさそうですが。

サーチエンジンであるElasticsearchがメトリクスの分析エンジン、APMへと進化する流れ

そこから話はサーチエンジンであるElasticsearchがなぜメトリクスの分析エンジンとなり、APMに繋がるのかについて、Elasticsearchの進化の歴史をポイントを挙げながら説明をしてくれました。

前のせろ氏は「歴史はいいから早くAPMを！」とぶつぶつ呟いていましたが、私としては、この流れは必然であり、この先に歩む道もまた当然行きつくべき先であるという力強いメッセージが感じられて好きです。

１つの技術スタックでLogs、Metrics、APMを扱うメリット

Elastic Stackとして、Logs、Metrics、APMのデータをまとめて扱えるようになると何が嬉しいのでしょうか。
ここでは統合されたダッシュボードによる分析、同じツールなので、同じ操作によるダッシュボードのカスタマイズ、ML、アラート設定などの利点が説明されていました。

異なるアプリケーションでバラバラにグラフを見るのではなく、一つにまとめてみたいし、一つのアプリケーションの中で行き来したいですよね。

実際にfilebeat, metricbeat, APMのデータを一つのVisualBuilderのグラフにする方法の紹介

こちらはライブデモで、実際にVisualBuilderを操作しながら、異なるindexのデータを一つのグラフに重ねていく様子です。

MySQL（マイシーケル）のslow logを一緒にダッシュボードに表示

現在マイブームの「マイシーケル」もslow logを表示できるテーブルを追加してダッシュボードが完成！

BeatsにはModuleの仕組みがあり、専用のダッシュボードも作成されるのですが、このようにして、filebeat、metricbeat、APMのデータを統合して分析できるダッシュボードが作れると運用業務が効率化できそうです。

今後のロードマップ

ロードマップとして、次が挙げられていました。

1. 新しいBeats Module/Logstash inputの登場
2. 既にリリースされているModuleのDashboard、ML Job、Alertingの改善
3. Agentless Shinppers
4. 分散トレーシング

BeatsのModuleでML Job、Dashboard、Alertingの設定が自動的に作られる環境が整っていくのは嬉しいですね。Agentless Shipperはちょっと理解ができませんでしたが、分散トレーシングは分散システムのログを可視化する時の起点となる問題意識として私たちも持っているので、長年の課題を今の技術でどのように解決していくのか楽しみです。

また、他のセッションでも紹介されたのですが、このElastic Common Schemaを決めていく動きというのも要注目したいところです。

まとめ

というわけで、APMのセッションレポートをお届けしました。

うちの会社でもENdoSnipe APMというAPM製品を長らく開発してきており、目指している理想は非常に共感できるものでした。
昨日のAPMのセッションも含めると、自分たちが進んで来た過程や、今の立ち位置、この後の進む方向性についていろいろと考える機会と刺激を受けましたね。

冒頭の写真の通り、Elastic APMチームとは情報交換をしながらお互いに協力関係で進めて行きますので、ぜひENdoSnipeにもご期待ください！

その他にも紹介したいものがあるのですが、長くなってしまいますので、どこか勉強会などでフィードバックしたいと思います！

それでは皆さん、日本で会いましょう！

Acroquest Technologyでは、キャリア採用を行っています。

• データ分析（Elasticsearch、Python関連）、ビッグデータ（Hadoop/Spark、NoSQL）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

Elastic{ON} 2018 最終日セッションレポート k8sのモニタリングとSQLの話を聞いてきた！ #elasticonjp

西海岸の風を浴びた同僚が「シークェール ！(SQL)」「マイシークェール！ (MySQL)」などと連呼するのを見て泣いている @cero_t です。海外カンファレンスに参加した人なら誰もが一度は掛かるハシカみたいなもんですよね、これ。
さて、Elastic{ON}も今日で最終日。昨日は初日セッションレポートだったのに、今日が最終日セッションレポートっていうのは、何ともスピーディーな感じですね！

今日参加したセッション

私が本日参加したセッションは次の通りです。

1. Elastic Cloud: What’s next?
   • SaaSで提供されるElastic Cloudと、それをセルフホスティングするElastic Cloud Enterpriseの紹介と今後の予定
   • ツイートまとめ: https://twitter.com/hashtag/ec_cloud?f=tweets
2. Kubernetes, Docker, and Containers at Elastic: Monitoring, Logging, and More
   • KubernetesやDockerなどのコンテナや、その上で稼働するアプリケーションのモニタリングについて
   • ツイートまとめ: https://twitter.com/hashtag/ec_k8s?f=tweets
3. Logs, Metrics, and APM: The Holy Teinity of Operations
   • Elasticsearchの新機能「APM」の紹介と、今後拡充する機能について
   • ツイートまとめ: https://twitter.com/hashtag/ec_apm?f=tweets
4. Logging and Metrics in Elastic Cloud: Drinking Our Own Champagne
   • Elastic CloudのSREチームが、どのようにロギングやメトリクスを収集してきたかという事例
   • ツイートまとめ: https://twitter.com/hashtag/ec_eclog?f=tweets
5. State of Elasticsearch’s Java Clients
   • Elasticsearchにアクセスできる3種類のJavaクライアントの紹介と、今後の予定、コントリビュート募集について
   • ツイートまとめ: https://twitter.com/hashtag/ec_java?f=tweets
6. Elasticsearch SQL
   • みんな気になるElasticsearchのSQL対応について
   • ツイートまとめ: https://twitter.com/hashtag/ec_sql?f=tweets
7. Ask Me Anything
   • ElasticsearchのG1GC対応の状況
   • MetricbeatのJolokia ModuleはいつGAになるの？ APMのJava対応と関係ある？
   • MetricbeatのElasticsearch ModuleはいつGAになるの？ X-PackのMonitoringとどう使い分けるの？

昨日とは打って変わって、王道系のテクニカルセッションに参加するようにしました。この中でも皆さんが気になりそうな「コンテナのモニタリング」と「Elasticsearch SQL」について、詳しくレポートします。

コンテナ監視に必要なのは、監視対象の自動検出

kubernetes (k8s) やdockerなどのコンテナについて、ログやメトリクスを収集する方法について解説するセッションです。
通常のサーバであれば、BeatsやElasticsearch、Logstash、Kibanaなどを使って監視する方法がそれなりに確立されてきました。ただ、世の中ではサーバをそのまま運用するのではなく、dockerやk8sのようなコンテナを利用する方法に注目が集まってきており、このようなコンテナでアプリケーションを運用監視する場合には、また少し違った方法論が必要となってきます。
このセッションでは、そのようなコンテナのログ収集やモニタリングを行う際に役立つ機能が紹介されました。

ツイートまとめ: https://twitter.com/hashtag/ec_k8s?f=tweets

自動で収集対象を見つける autodiscover

コンテナ上で動くアプリケーションの監視で難しいところは、「監視対象のアプリケーションが変わる」ところです。起動や停止の頻度が高く、またスケールアウト、スケールインなども、通常のサーバに比べれば高いため、「サーバを起動するたびに、監視側の設定も書き換える」のは困難です。
そこでFilebeatやMetricbeatに「autodiscover」という機能が追加され、稼働中のコンテナから監視対象を見つけて、情報の収集を行うことができるようになりました。

docker上で動くnginxのログファイルを収集するFilebeatの設定は次のようになります。

少しピンぼけして見づらいですが、17行目の filebeat.autodiscover 以降がその設定です。ここではdockerのimage名が「nginx」と一致するコンテナを対象としています。それより上の行は、docker自身のログを収集するための設定です。

Metricbeatやk8sでも同様の設定ができます。次の例は、k8sで動くmysqlとnginxのメトリクスを収集する設定です。

58行目以降でautodiscoverを設定しています。これで見つけた監視対象のサーバは ${data.host} という変数が参照できるようですね。また、57行目以前には、dockerやk8sのメトリクスを収集するための設定が記載されています。

このような設定でデータの収集を行うのと同時に、ダッシュボードも自動で出来上がります。次の例は、k8sの全体を俯瞰するためのダッシュボードです。

ノードやポッドの状況などが分かります。ダッシュボードを切り替えることで、k8sの上で稼働するnginxやmysqlなどの個別の情報を収集することももちろん可能です。

特定のpodを絞り込んで、リソースの使用状況を表示することができています。

監視環境はコンテナの外に作ろう

ところでこのような監視システムを構築する場合、ElasticsearchやKibanaはコンテナの中に構築すべきなのか、それとも外に構築すべきなのか、どちらにするのが良いのだろうかと思ったことがありました。このセッションでは「コンテナの外」で構築していました。

またk8sの監視構成する場合はこのような感じ。この外側にElasticsearchなどを構築します。

いわゆる「神の視点」が必要なので、コンテナの外側に立てるのが良いのでしょうね。
また、コンテナも、その上で稼働するアプリケーションも含めて、全体を一元的に見られるほうが便利だと思います。このように一元的に見ることを、SPOG（Single Pane of Glass）と呼んでいました。SPOF (Single Point of Failure) と違ってネガティブな意味合いはありません。使っていこ。

という感じで、Elasticスタックを使ったdockerやk8sの監視環境は、かなり充実してきていることが分かります。私はまだあまりdockerやk8sを使ったシステムの監視を経験していないのですが、少し手を動かしておかなきゃなと思わされました。

k8s用のmanifestサンプルがここで公開されているので、試してみたい方は参考にどうぞ。
https://go.es.io/beats-k8s

ついにSQLが来るぞ！

皆さんお待ちかね、SQLのセッションです。
昨年のElastic{ON}で発表されて衝撃を与えたSQLですが、その後1年間リリースされることなく、次のElastic{ON}を迎えることとなりました。開発状況や機能などが気になるところですが、その大半が紹介されたのでレポートしたいと思います。

ツイートまとめ: https://twitter.com/hashtag/ec_k8s?f=tweets

次のマイナーバージョンでリリースされるぞ！

まず最初に、SQL機能のリリース予定が紹介されました。なんと次回のマイナーバージョンである「Elasticsearch 6.3」にSQL機能が入るそうです。6.3と言えばX-Packのソースコードが公開されるバージョンですから、その辺りの調整も含め少しリリースに時間が掛かるかも知れません。
ただそれでもゴールデンウィークぐらいまでにはリリースされるんじゃないかなと私は予想しています。

なおSQLはX-Packとして提供される機能の一部ですが、この機能は無償で利用できる範疇に入っているそうです。

SQL標準に準拠するとこ、しないとこ

Elasticsearch SQLはANSI SQLベースとして、独自の関数を追加した（逆に一部の機能が使えない）ものとなっています。このあたりは実際のSQLの雰囲気を見てもらったほうが早いと思います。

前半はANSI SQL準拠のSQLですが、後半にはQUERYやMATCH、SCOREと言った独自関数が入っています。Elasticsearchが持つ同名の関数を利用できる感じです。

またSQLの集計関数も利用できます。

集計関数はElasticseaerchのaggregtion機能を利用して実現しているようです。

また、SQLのjoin句はサポートされないのですが、違う形でごく限定的にjoin相当の機能がサポートされます。それがParent-Childです。

子のフィールドを列挙したり、条件に合う子を持つ親を検索するようなクエリを書けるようです。これがnested typeを使っているのかjoin datatypeを使っているのかは聞き取りそこねたのですが、いずれにせよnested queryやhas_child / has_parent queryで実現できそうな範囲はサポートするようです。

この辺りが更に充実すれば、もう少しElasticsearchで親子構造を持つデータも扱いやすくなるのですが、どうでしょうね。

RESTだけでなく、CLI / JDBC / ODBCでアクセス可能

SQLが使えるのはRESTアクセスのみかと思っていたら、RDBMSのコマンドコンソール（mysqlとかpsqlとかsqlplusとか）のようなCLIツールが提供されるほか、独自のJDBCドライバ、ODBCドライバも提供されるそうです。

JDBCドライバと簡単なO/Rマッパーを利用してアクセスすれば、Elasticsearchの検索結果をJavaのオブジェクトにマッピングする辺りも含め、今よりもかなり簡単に記述できるようになりそうです。もちろん課題なども少なくないとは思いますが。

そんな感じで、一体いつ出るのかとやきもきしていたSQLですが、そう遠くないうちに出てきそうだとか、JDBCドライバも利用できるとか、思った以上に作り込まれていることがよく分かりました。最初は思ったように使えない部分などもありそうですが、選択肢の一つとして引き続き注目したいと思います。

全体を通して

今回は、2年ぶり2度目のElastic{ON} San Franciscoでした。
2年前はまだまだ荒削りなプロダクトで、「これから整理していくぞー」という感じだったのですが、今年はかなり洗練されてきているように感じました。初日のキーノートレポートにも書いたように、「インストールすればすぐに使い始められる」とか「Webで確認、設定ができる」というような「簡単さ」「使いやすさ」にフォーカスした開発が行われているという印象を受けましたし、プラットフォームからソリューションになってきており、新プロダクトのAPMなどはその最たる例でしょう。
今回のイベントでは、そういう潮目のように感じました。

あ、そうそう、書き忘れていたのですが、昨日のセッションが全部終わった後に、招待制のボウリングイベントがあったんですよね。そこでCEOのShay Banonとお話をしたり

抽選会で、Elasicのバックパックが当たったり（！）しました。

・・・このバックパック、どこかでプレゼント企画でもするかなぁ？

そんなわけで明日はいよいよ帰国です。
短い期間でしたが、新しい情報や知見を得られる充実したイベント参加となりました。Elasticsearch社の皆様、Elastic{ON}のスタッフはじめ、参加者も含めてイベント関わった皆さん、お疲れ様でした＆ありがとうございました！！

Stay elastic,
see you!

Elastic{ON} 2018 最終日セッションレポート 時系列データ以外も機械学習で異常検知 #elasticonjp

こんばんは。100TBのElasticsearchクラスタを運用している @snuffkin です。

実は、サンフランシスコに居ながらクラスタの状況報告を受けたり、日本と会議していました。
今回のElastic{ON}でクラスタ管理の話がいろいろ出たので、それらの機能が使えるようになるのが楽しみです。

今日参加したセッション

1. Disaggregated System Architectures with Elasticsearch
   • Pure Storage社によるセッションです。専用ストレージを搭載したラックを使い、CPU周りとストレージ周りを別々にスケールさせる話でした。
2. Upgrade to 6.0: Leading with Empathy
   • Elastic社によるセッションです。6.0へのアップグレードの際に、ユーザの事・チームの事を考えて改善していった内容の紹介です。
3. Machine Learning in the Elastic Stack
   • Elastic社によるセッションです。X-Pack Machine Learningの生みの親であるSteveさんから、少し前に追加された予測機能や、今後追加予定の機能について紹介がありました。
4. The Math Behind Elastic Machine Learning
   • Elastic社によるセッションです。X-Pack Machine Learningのアルゴリズム解説などです。
5. Elasticsearch SQL
   • Elastic社によるセッションです。いよいよSQL対応の具体的な内容が紹介されました。

SQLのセッションもアツかったのですが、そちらは @cero_t さんがレポートしてくれると思うので、私はX-Pack Machine Learningについてレポートします。

時系列データ以外も機械学習で異常検知

セッション「Machine Learning in the Elastic Stack」では、X-Pack Machine Learningの生みの親であるSteveさんから、少し前に追加された予測機能や、今後追加予定の機能について紹介がありました。

まず、既存機能のおさらいで、予測機能の紹介でした。
図の水色の部分が過去に対する異常判定で、オレンジ色の部分が未来予測の部分です。
色の付いた範囲から外れた箇所を異常と判定します。

そして今後追加される機能の紹介です。
これまでは「時系列データの異常検知」に注力しており、様々な機械学習のアルゴリズムが使える訳ではありませんでした。
しかし、今後、「時系列データ以外の異常検知」を行う機能が追加されます。
具体的には、多次元ベクトルの異常検知ができるようになります。

また、フィールドの値の分布を見ることができたり、

散布図行列を見ることができるようになります。

本格的に分析する前にデータの概要を確認すると思いますが、そういったときに便利な機能ですね。
もしかすると、一般的な分析ツールが持ってる機能が段々と追加されていくかもしれません。

異常検知の数学的な話

セッション「The Math Behind Elastic Machine Learning」では、X-Pack Machine Learningで行っている「時系列データの異常検知」のアルゴリズムが紹介されました。

アルゴリズムについてこれまでは、雰囲気が語られたくらいでした。
今回紹介されたレベルでの詳しい解説は初めてだったので、非常に興奮しながら聞いていました。

このセッションを聞いて、頭が痛くなった方もいたとは思いますが。。。
帰国後に自社の機械学習チームにフィードバックするのが楽しみな内容でした。

Elastic{ON}を振り返って

という訳で、今年のElastic{ON}が閉幕しました。

私は初めての参加でしたが、新機能の発表が目白押しで、今後楽しみな事ばかりです。
X-Packのソース公開、SQL対応、Machine Learningの拡大、クラスタ管理周りは特に興味深い内容でした。
また、AMA(Ask Me Anything)でエンジニアの方と直接話せたのは大きく、ここでしか聞けなそうな話を聞けたのは収穫でした。

いろいろとパワーをもらって帰国します^^
それではまた～。

Acroquest Technologyでは、キャリア採用を行っています。

• データ分析（Elasticsearch、Python関連）、ビッグデータ（Hadoop/Spark、NoSQL）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。