Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

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

こんばんは。@です。

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

Elastic社APMチームのPMであるRasmusさん、Tech leadのRonさんらと共に記念写真。
f:id:acro-engineer:20180302183358j:plain:w700

今日参加したセッション

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

  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

f:id:acro-engineer:20180302183443j:plain:w400
f:id:acro-engineer:20180302183514j:plain:w400

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

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

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

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

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

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

f:id:acro-engineer:20180302183706j:plain:w400
f:id:acro-engineer:20180302184205j:plain:w400
f:id:acro-engineer:20180302184224j:plain:w400

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

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

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

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

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

f:id:acro-engineer:20180302183915j:plain:w400

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

今後のロードマップ

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

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

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

f:id:acro-engineer:20180302184307j:plain:w400
また、他のセッションでも紹介されたのですが、この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)」などと連呼するのを見て泣いている @ です。海外カンファレンスに参加した人なら誰もが一度は掛かるハシカみたいなもんですよね、これ。
さて、Elastic{ON}も今日で最終日。昨日は初日セッションレポートだったのに、今日が最終日セッションレポートっていうのは、何ともスピーディーな感じですね!

今日参加したセッション

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

  1. Elastic Cloud: What’s next?
  2. Kubernetes, Docker, and Containers at Elastic: Monitoring, Logging, and More
  3. Logs, Metrics, and APM: The Holy Teinity of Operations
  4. Logging and Metrics in Elastic Cloud: Drinking Our Own Champagne
  5. State of Elasticsearch’s Java Clients
  6. Elasticsearch SQL
  7. Ask Me Anything
    • ElasticsearchのG1GC対応の状況
    • MetricbeatのJolokia ModuleはいつGAになるの? APMJava対応と関係ある?
    • 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の設定は次のようになります。
f:id:acro-engineer:20180302175835j:plain:w400
少しピンぼけして見づらいですが、17行目の filebeat.autodiscover 以降がその設定です。ここではdockerのimage名が「nginx」と一致するコンテナを対象としています。それより上の行は、docker自身のログを収集するための設定です。

Metricbeatやk8sでも同様の設定ができます。次の例は、k8sで動くmysqlとnginxのメトリクスを収集する設定です。
f:id:acro-engineer:20180302175856j:plain:w400
58行目以降でautodiscoverを設定しています。これで見つけた監視対象のサーバは ${data.host} という変数が参照できるようですね。また、57行目以前には、dockerやk8sのメトリクスを収集するための設定が記載されています。

このような設定でデータの収集を行うのと同時に、ダッシュボードも自動で出来上がります。次の例は、k8sの全体を俯瞰するためのダッシュボードです。
f:id:acro-engineer:20180302180010j:plain:w700
ノードやポッドの状況などが分かります。ダッシュボードを切り替えることで、k8sの上で稼働するnginxやmysqlなどの個別の情報を収集することももちろん可能です。
f:id:acro-engineer:20180302180032j:plain:w400
特定のpodを絞り込んで、リソースの使用状況を表示することができています。

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

ところでこのような監視システムを構築する場合、ElasticsearchやKibanaはコンテナの中に構築すべきなのか、それとも外に構築すべきなのか、どちらにするのが良いのだろうかと思ったことがありました。このセッションでは「コンテナの外」で構築していました。
f:id:acro-engineer:20180302180101j:plain:w700
またk8sの監視構成する場合はこのような感じ。この外側にElasticsearchなどを構築します。
f:id:acro-engineer:20180302180124j:plain:w700
いわゆる「神の視点」が必要なので、コンテナの外側に立てるのが良いのでしょうね。
また、コンテナも、その上で稼働するアプリケーションも含めて、全体を一元的に見られるほうが便利だと思います。このように一元的に見ることを、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 SQLANSI SQLベースとして、独自の関数を追加した(逆に一部の機能が使えない)ものとなっています。このあたりは実際のSQLの雰囲気を見てもらったほうが早いと思います。
f:id:acro-engineer:20180302180206j:plain:w700
前半はANSI SQL準拠のSQLですが、後半にはQUERYやMATCH、SCOREと言った独自関数が入っています。Elasticsearchが持つ同名の関数を利用できる感じです。

またSQLの集計関数も利用できます。
f:id:acro-engineer:20180302180226j:plain:w700
集計関数はElasticseaerchのaggregtion機能を利用して実現しているようです。

また、SQLのjoin句はサポートされないのですが、違う形でごく限定的にjoin相当の機能がサポートされます。それがParent-Childです。
f:id:acro-engineer:20180302180247j:plain:w700
子のフィールドを列挙したり、条件に合う子を持つ親を検索するようなクエリを書けるようです。これが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ドライバも提供されるそうです。
f:id:acro-engineer:20180302180324j:plain:w700
JDBCドライバと簡単なO/Rマッパーを利用してアクセスすれば、Elasticsearchの検索結果をJavaのオブジェクトにマッピングする辺りも含め、今よりもかなり簡単に記述できるようになりそうです。もちろん課題なども少なくないとは思いますが。


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

全体を通して

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

あ、そうそう、書き忘れていたのですが、昨日のセッションが全部終わった後に、招待制のボウリングイベントがあったんですよね。そこでCEOのShay Banonとお話をしたり
f:id:acro-engineer:20180302180403j:plain:w700
抽選会で、Elasicのバックパックが当たったり(!)しました。
f:id:acro-engineer:20180302180420j:plain:w400
・・・このバックパック、どこかでプレゼント企画でもするかなぁ?


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

Stay elastic,
see you!

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

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

実は、サンフランシスコに居ながらクラスタの状況報告を受けたり、日本と会議していました。
今回の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のセッションもアツかったのですが、そちらは @ さんがレポートしてくれると思うので、私はX-Pack Machine Learningについてレポートします。

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

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

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

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

また、フィールドの値の分布を見ることができたり、
f:id:acro-engineer:20180302160252j:plain:w700

散布図行列を見ることができるようになります。
f:id:acro-engineer:20180302160259j:plain:w700

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

異常検知の数学的な話

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

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

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

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などの技術を使ったり、データ分析機械学習などのスキルを活かしたい。
  • 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

 

Elastic{ON} 2018 初日セッションレポート Logstashのクラスタ化 #elasticonjp

こんばんは。@です。

AMA(Ask Me Anything)でElastic社のエンジニアの方と直接話せるのは良いですね。
いろいろと助かります。
f:id:acro-engineer:20180301185445j:plain:w400


今日参加したセッション

さて、Elastic{ON} 2018もいよいよ、セッションが始まりました。
いろいろ聞きたいことはあるのですが、私は次のセッションに参加しました。

  1. Bigger, Faster, Stronger: Leveling Up Enterprise Logging
  2. Reinventing Fermilab's Scientific Computing Grid Accounting with the Elastic Stack
    • フェルミ研究所(アメリカにある物理学の研究所)のセッションです。加速器素粒子の解説、、じゃなくて、科学計算で利用するスーパーコンピュータをElastic Stackで監視する話でした。
  3. Deep Learning & Accelerating the NLP Journey in the Unstructured World at Credit Suisse
    • クレディ・スイス社によるセッションです。Elastic Stackを使って組まれた通信監視を行うプラットフォームの話。ディープ・ラーニングを利用して誤検知を減らす話も出てきました。
  4. What's the Latest in Logstash
    • Elastic社によるセッションです。5.0以降のLogstashの機能の振り返りと、今後追加される機能についての説明がありました。
  5. The Seven Deadly Sins of Elasticsearch Benchmarking
    • Elastic社によるセッションです。Elasticsearchのベンチマークを行うときに失敗しがちな内容について説明がありました。
  6. Site Search with Swiftype
    • Elastic社によるセッションです。昨年、ElasticにジョインしたSwiftypeの話です。
  7. Scaling Log Aggregation at Fitbit
    • 42Lines社によるセッションです。Elasticsearchを3年以上運用し、アップグレード、スケールアウトを行ってきた流れに関する話です。

Elasticsearchベンチマーク7つの大罪

これらの中でも、「The Seven Deadly Sins of Elasticsearch Benchmarking」は好きなセッションでした。
性能測定とか運用周りは仕事がら興味がありますが、「Elasticsearchベンチマーク7つの大罪」というタイトルも興味をかき立てますね。

「ちゃんとプロダクション環境と同じ条件でベンチマークを行いましょう」から始まって、性能測定時に押さえておくべき内容が解説されました。
f:id:acro-engineer:20180301165124j:plain:w700

また、このようなベストプラクティスを取り込んだ「rally」というベンチマークツールがあり、Elasticsearchのベンチマークを行う際には、これを使う事が推奨されていました。
github.com

Logstashのクラスタ

他には、「What's the Latest in Logstash」も興味を惹かれました。
前半は5.0以降の新機能の振り返り。
Persistent Queueとか、もう遠い昔の機能のような気がしてましたが、割と最近なんですよね。

後半は今後追加される機能についての説明。
Logstashのパイプライン管理はサーバサイド(Elasticsearch)で集中的に管理できるようになりました。
今後は、Grok PatternやGeoIP Databaseなど、Logstashのローカルディスクに保持していたものが、サーバサイドで管理できるようになるそうです。
f:id:acro-engineer:20180301173037j:plain:w700

サーバサイドでいろいろ管理できるようになるのは嬉しいですが、今回の目玉はLogstashのクラスタ化(?)です。
これまで、Logstashが複数台起動していても、協調して動作する機能はありませんでした。
そのため、例えば、障害が発生してLogstashがフェイルオーバーしたときに、どこまでイベントを送信したのか管理することは難しい問題でした。
今後は、Logstashのクラスタ化が進み、このような問題も解決されていくようです。
f:id:acro-engineer:20180301170906j:plain:w700

今後も、どんどん機能追加されていくようで、運用しやすくなっていきそうですね!

さて、明日はいよいよ最終日。
楽しみなセッションが続きます。
それではまた~。

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


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

 

Elastic{ON} 2018 初日セッションレポート オーバーウォッチの運用チームに知見をもらった! #elasticonjp

いよいよ2月も終わって3月になりましたが、皆さんいかがお過ごしでしょうか。
こちらサンフランシスコも先ほど日付が変わって3月となり、サンガツフランシスコ!! ・・・みたいな感じのボケも考えたのですが、どうにも滑りが悪いですね、@ です。
Elastic{ON}では、今日から通常セッションが始まりました。

今日参加したセッション

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

  1. Watching Overwatch at Activision Blizzard
  2. Guide to Finding a Doctor in Spanish
  3. Reliable by Design
  4. BoF: Custom Kibana Graphs with Vega
    • Vegaを使ってKibanaのVisualizationを自作する
  5. BoF: Ingesting Data From Oracle Databases
  6. Visualizing Content Performance with Elastic at Canadian Broadcasting Corporation (CBC)
    • カナダの放送局CBCで、パフォーマンスを可視化した事例
  7. Ask Me Anything
    • 検索スコアのboostについて
    • Parent Childについて

ユーザー事例やニッチめの話など、なかなか他では聞けない話を中心に聞いて回りました。この中でも特に印象深かった「オーバーウォッチの話」と「Ask Me Anything」について、詳しくレポートします。

オーバーウォッチ運用チームの、KPI収集と改善活動を垣間見た

Blizzard社のオンラインゲーム「オーバーウォッチ」の運用チームが、どのようにゲームサーバのモニタリングをしているかなど紹介するセッションです。
Blizzardと言えばDiabloシリーズやWarcraftシリーズ、最近ではカードゲームのハースストーンなどでも有名です。学生時代、Diabloに手を出したがばかりにオンラインゲーム沼にハマってしまった私としては、このセッションは見逃せませんでした。

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


オーバーウォッチの運用チームは、サーバのメトリクス情報やサービスの状態をsyslogやbrubeck (https://github.com/github/brubeck) などで収集し、それをKafka経由でElasticsearch / Cassandra / HDFSに保存しています。
f:id:acro-engineer:20180301180559j:plain:w700
Elasticsearchには直近の1週間分のデータのみ保存し、それより過去のデータはHDFSに保存しているとのこと。私も過去の案件で同じようなことをやったので、このあたりはだいぶ共感できます。

またBEAMSという自作ツールで、収集したデータからアラートなどを飛ばす仕組みも作っていました。
f:id:acro-engineer:20180301180517j:plain:w700
BEAMSは、データの加工やルールの定義、アラートの内容などをブラウザから簡単に設定できるシステムのようですね。
f:id:acro-engineer:20180301180533j:plain:w700
ちょうど、Logstash + Watcherをまとめたような位置づけでしょうか。


さて、面白いのは、ここからです。

このようなデータプラットフォームを整備したことで、オーバーウォッチの運用チームは様々な情報を可視化・分析できるようになりました。その一例が、ゲームプレイ中の切断です。どの時間に、どれぐらいの頻度で、どの地域で切断が起きているかなどを可視化することで、サーバ障害やその影響範囲などを探ることができます。
f:id:acro-engineer:20180301180726j:plain:w700
このような可視化やアラートを整備することで、オーバーウォッチの運用チームは2017年に起きた134の大きめの障害のうち、78%をアラートで気づくことができたそうです。また障害のうち30%は、モニタリングの改善にフィードバックすることもできました。

この数字がキッチリ出てくるところが、良いですよね。

システムの運用中に発生する障害は、必ずしもリアルタイムに検知できるわけではなく、時にはお客様からの連絡やクレームで初めて気づくことだってあります。ただその際に、どうすればリアルタイムに検知できるのかを考えて運用にフィードバックするという改善活動を行い、またリアルタイムに検知できた/できなかった件数をKPIとして計測することで、改善の効果を確認することができます。このような活動が、オンラインゲームのように難しいシステムを安定稼働させるうえで欠かせなかったのだと思います。

そんなのはSREの人にとっては当たり前のこと(SRE本などにも書いてあること?)なのかも知れませんが、私にとってはすごく良い知見になりました。面白かったです!

やっぱりAMAは最高だな!

Elastic{ON}名物のAsk Me Anythingブース、通称AMA。
このブースは、Elasticsearchの開発者やサポートチームに直接質問をすることができるもので、言い換えればElasticsearchのコンサル(すごくお値段が高いんだヨ!)を無料で受けられるようなコーナーです。
そんなわけで人気があり、どうしても休憩時間などは大変な混雑になってしまいます。そこでいくつかのセッションをキャンセルし、セッション時間中にAMAブースに立ち寄ることにしました。正味、セッションに出るよりもコスパが良いと思うんですよね。


さて、AMAブースで聞いた1つめの質問が、Elasticsearchの検索スコアを調整する「boost」をどのように利用するべきかという話。機能ではなく、いかに利用して運用していくかという質問です。
f:id:acro-engineer:20180301180642j:plain:w400
このようなオープンクエスチョンに対しても、開発者自身の経験や見聞きしたユースケースなどから、取りうる戦略をアドバイスしてもらいました。またElasticsearch 6.2で実験的に導入された機能も使える可能性があるなど、見落としていた新機能なども教えてもらうことができました。


もう一つ質問したのが、ElasticsearchでRDBMSのような親子関係を扱うための「parent-child relationship」の話。この機能は5.xを最後にdeprecatedになり、6.xからはjoin datatypeを使うことが推奨されています。ただその互換性や将来性に疑問があったため、この機能の開発者(!)に直接質問をぶつけてみました。
f:id:acro-engineer:20180301180623j:plain:w700
この機能の将来性や、この機能とElasticsearch SQLの関係性など、いくつか話を重ねた後で、ふと「SQLのhavingに相当するクエリって、Elasticsearchで実現する方法ないですよね」と聞いたところ、「裏技だけど、あるよ」と言って教えてくれました。私的にはこの裏技が本日最大の衝撃でした。細かすぎて伝わらない内容ですがw
こちらはまた日本に帰ってから試してみたいと思います。


・・・という感じで、質問する側にもそれなりの知識や問題意識が必要になるとは言え、これぐらい深めの話を聞けるのが、AMAブースの特徴です。そもそも開発者と1対1と話せること自体、かなり豪華ですよね。本当に貴重な機会ですし、こう言いうのも何ですが、すごく効率がよくてありがたいです!

そうは言っても英語ディスカッションだけのBoFは辛い

そういえばBoFについては触れてなかったのですが、Elastic{ON}のBoFは、こんな感じの座談会形式で行われます。
f:id:acro-engineer:20180301180702j:plain:w700
資料なしで英語のディスカッションのみなので、さすがにこれは英語力が追いつかずに苦しかったです。

一方で、AMAブースは筆談や図を交えながら話せば何とかなりますし、こちらのペースに合わせて話してもらえるため、コミュニケーション面ではあまり困りませんでした。
明日もいくつかセッションに参加する予定ですが、しっかりAMAブースにも行って、まだまだ課題を解決したいと思います!


Stay elastic,
see you!

Elastic{ON} 2018 初日セッションレポート Kibanaは優しさの強化と再構築 #elasticonjp

こんばんは。@です。

初日のセッションがあっという間に終わってしまいました。
セッションに参加しつつ、デモブースやAMAを回っていると時間が足りない!というのが正直な感想です。

Elastic社のAaronさんとAMAにて記念写真。
f:id:acro-engineer:20180301181529j:plain:w400

今日参加したセッション

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

  1. What's Evolving in Elasticsearch
    • Elasticsearchの5.x => 6.x => 7.xの進化について、Indexing, Search, Security, Administrationの4つのテーマからお届け。
  2. What's Cooking in Kibana
    • Kibana 6.xで今後追加される機能と 7.xで訪れる(またもや?)大きな変更点について。
  3. What's Brewing in Beats
    • 新しく追加されるInfra UIとFilebeat、MetricbeatによるKubernetes(k8s)の可視化とAuditbeatについて。
  4. Monitoring Anything and Everything with Beats at eBay
    • eBayがBeatsを活用しながらどのようにMonitoringを実現していったか。
  5. APM with the Elastic Stack
    • 6.2でGAとなったAPMの全体と新たに追加される待望のReal User Monitoring(RUM)と今後の予定。
  6. Creating Canvas for Real-Time Infographics in Kibana
    • Canvasの(だいぶ動くようになった)現在状況をデモを交えながらお届け。


その中から、今回は現在のElastic Stackがどのような状況にあるかを勝手に想像したくなる「What's Cooking in Kibana」についてのレポートをお送りします。

Kibanaの新機能は飛び道具的なものではなく、運用を助けるもの

紹介されたKibanaに対する追加機能は、「その辺りを埋めに来たか」という印象を持ちました。
と言うのも、目新しい新機能はあまりなく、今実際に運用している中であったら嬉しい機能や
どんなユーザ、ユースケースでもまずは必要になりそうな汎用的な機能をソリューションに近い形で提供していく方針が感じ取れたからです。

そんな中での新Visuailze「Waffle map」

上記のように書きましたが、新たに追加になる新Visualizeに「Waffle map」があります。
今回のイベントの中で既に何度も目にしたこの表現は新しいVisualizeであり、確かにk8sの複数のPodの状態を表現するのに向いていますね。

f:id:acro-engineer:20180301181207j:plain:w400

地道な改善

Kibana 6.0から追加されたKQL(Kibana Query Language)のAutoCompleteがFiled、Operator、Valueに対して効くというのはとても便利そうでした!

f:id:acro-engineer:20180301181151j:plain:w400

Index ManagementのUI改善では、Indexの設定やMappingがまとめて見られることに加え、GUIによってIndexのClose、forcemerge、flush、Deleteなどが行えるようになっており、ユーザにとっての身近なUIに進化しています。

f:id:acro-engineer:20180301181225j:plain:w400

新たに追加されるAppsのInfra UIとLogging UI

Infra UIとLogging UIはどんなユーザ、ユースケースでもまずは必要でしょう?というメッセージが聞こえてくる感じの新しいKibanaアプリ(プラグイン)です。

Infra UIはMetricbeatで集めた情報からサーバ毎のメトリックを可視化してくれます。Beatsのセッションでも紹介されていましたがk8sの場合には、さらにk8s用に拡張された画面になるようです。

f:id:acro-engineer:20180301181128j:plain:w400

Logging UIもまずはログを集めたらtail -fのように眺めたいし、検索やフィルタしたいよね、という声に応える内容となっています。これまでは仕方が無くDiscoverをログ検索に使っていたユーザは多いと思いますが、そのようなユーザにとって優しいプロダクトを目指す方向性を強く感じます。

f:id:acro-engineer:20180301181115j:plain:w700

運用を強力にサポートする Index Lifecycle Management & Rollups

ElasticseachのセッションにおいてIndex Lifecycke Managementの機能を提供するという説明があったのですが、それはKibanaのManagement UIでサポートされます(X-Packとして)。さらにキーノートでも紹介されたRollupについても合わせてManagement UIでサポートするようで、これまでCuratorなどを駆使して運用で対応してきたものが標準機能(ただしX-Pack)で提供されるようになるのは非常に嬉しいです。

f:id:acro-engineer:20180301181247j:plain:w400

ただし、紹介された画面のキャプチャを見る限りではKibana 7.xでの提供になるようです(セッション内では提供時期の説明はなく、キャプチャからの私の予想です)。

でも、Kibanaはやっぱり大きく変わるってさ

そんな中で紹介されたのが、新しいデザインの変更です。Kibana 6でもKibana全体に渡る大きなデザイン変更があったわけですが、Kibana 7.xでもさらに全体的なデザイン変更があります。

f:id:acro-engineer:20180301181302j:plain:w400

アクセシビリティに考慮したというKibana6のデザインはなんだったの?と思わなくないですが、その背景にはEUIと呼ぶElastic UI Frameworkを提供し、このEUIベースで画面コンポーネントを作り直しているからのようです。

f:id:acro-engineer:20180301181316j:plain:w400

これまでKibanaの独自Visualizeやプラグインの開発は、マイナーレベルのバージョンまで合わせる必要があり、バージョンアップがあれば都度ビルドしてリリースする必要がありました。
そのような開発の制約を無くしたいという点は、うちもKibanaプラグインを開発することが多いので非常に嬉しい限りですが、Kibana6への対応も大変だったのに、また・・・と涙目になる気持ちもあります (TT

f:id:acro-engineer:20180301181335j:plain:w400

しかも、今後はReact + RxJS + TypeScriptが開発のコアになるそうで、同じ恩恵を得るためには今のAngularJSからの移行を考える必要がありそうです(プラグインの開発は今まで通りAngularJSでもできるよ!でもReactをオススメするよ!とスピーカーの方は話していました >< )。

f:id:acro-engineer:20180301181350j:plain:w400

まとめ

というわけで、Kibanaのセッションレポートをお届けしました。
Elastic Stackは全体としては成熟してきた状態に入っており、Kibanaはよりユーザに優しいプロダクトとなるべく今まで埋まっていなかった隙間を埋めてきているという印象を受けました。

飛び道具的な機能はCanvasやVegaがあるとも言えますしね。

今後は汎用的なソリューションに近いものはInfra UIやLogging UIのようにKibanaが提供し、よりソリューションとして特化したものはSwiftypeのように外側アプリケーションやSaaSとして提供されるのだと感じました。

その他「What's Evolving in Elasticsearch」や「What's Brewing in Beats」の内容も紹介したいものがあるのですが、長くなってしまいますので、どこか勉強会などでフィードバックしたいと思います!

明日はもう最終日です!
Stay tuned!

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


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

 

Elastic{ON} 2018 キーノートレポート Elastic goes more open! #elasticonjp

いよいよ始まりました、Elastic{ON} 2018 サンフランシスコ。キーノートセッションで開幕です。
日本では花粉症に悩まされ、サンフランシスコに来たら治るのかなと思ったら全く症状が変わらず、風邪ひいてるのかも知れない @ です。もしかして風邪ひいてても気づかないタイプ?

さて、昨年まではPier 48という桟橋の上にある倉庫で行われていたElastic{ON}ですが、今年はMarriott Marquisというホテルで開催され、人権を取り戻した感じの 以前にも増して豪華なイベントとなりました。さらにキーノートはThe Masonicというイベント会場で行われます。まずはこのキーノートのレポートをお送りしたいと思います。

f:id:acro-engineer:20180228181220p:plain:w700

盛りだくさんのキーノート

キーノートは2時間を(大幅に)超えるボリュームで、10以上のデモが行われました。

ツイッターのリアルタイム実況はこちらを見てください。
togetter.com

発表された内容をかいつまんで紹介すると、次のような感じです。

  1. Rollup API : 定期的に過去のデータを集計する
  2. Machine Learning : 未来予測もできるようになった(ビットコインの予測はできないよ!)
  3. Canvas : 感銘を与えるUI、そしてSQL
  4. Infra UI : Dockerやk8sの監視もできる
  5. APM : アプリの監視をすぐに始められる
  6. Security : セキュリティ問題の可視化とML。あと、Mr.ROBOTのハッキングがガチすぎる
  7. Geo : 地図をレイヤーとして扱って、ポイントを重ねられるのが便利そう(小学生並みの感想)
  8. Search : Swiftype App Searchは、Web UIで簡単に検索のカスタマイズができる
  9. Elastic Cloud : 用途別にノードの性能を変えられるようになった
  10. X-Pack : X-PackのコードもGithubで公開!!

このうち、特に印象深かった「Canvas」と「Infra UI」、そして「X-Pack」について紹介します。

Canvas meets SQL

Canvasは、Kibanaの新しいUIのひとつです。現在はTechnology Preview版が公開されています。
f:id:acro-engineer:20180228181308j:plain:w700
紹介でも「from realism to IMPRESSionism」と書かれていたように、単にデータを見せるだけではなく、印象を与えるためのUIと言えるでしょう。顧客や上位管理層へのプレゼンやデモで利用されることを想定しているのでしょう。とりあえず見た目がカッコイイと、それだけで説得されたような気分になります。

また、このデモではCanvasだけでなく、新機能であるSQLも利用されていました。
次の画像では、少し見づらいですが画面の下のほうにSQLがあり、その検索結果をチャートにプロットしています。
f:id:acro-engineer:20180228181317j:plain:w700
selectとgroup byを使って集計するクエリですね。

ふつうのselectだけのものもプロットしています。
f:id:acro-engineer:20180228181326j:plain:w700

SQLは使い慣れてるし、これがあればElasticsearchの独自クエリを学習しなくて良いし便利だよな」というぐらいに捉えていたのですが、このCanvasSQLのデモには、また別の可能性を感じました。
データの絞り込みや集計を直感的に書けるSQLを使い、その結果をリアルタイムで可視化することで、どのようなデータがどのように分布しているかがすぐに分かります。たとえばアクセスログなどに対しても、SQLで検索してすぐ可視化できるわけです。

これって相当のおおごとなんじゃないですかね。

実際にどこまでできるのか、またSQLがどれぐらい使えるようになるのかは分かりません。そもそもSQL機能のリリース時期も不明です。ただその可能性を感じずにはいられないデモでした。

k8sを監視できるとかヤバいでしょ

さらっとデモが始まったのに、衝撃的だったのがInfra UI。ツイッターで遊んでたら、いきなりkubernetes (k8s) のモニタリングが始まっていました。遊ぶなよって話ですが。
f:id:acro-engineer:20180228181030j:plain:w700
f:id:acro-engineer:20180228181051j:plain:w700
Infra UIは、k8sのpod(コンテナ的なやつ)の全体やリソース状況などを、リアルタイムにモニタリングできる機能です。もちろんk8sだけでなく、個別のサーバやサービスの状況、またDockerもモニタリングができるようです。
これまでインフラのモニタリングは、自分で構成や監視項目を考えて情報収集を行っていましたが、このInfra UIを利用することで、より早くモニタリング環境を構築できるようになりそうです。

また写真を取りそびれたのですが、このInfra UIとMachine Learning (ML) を組み合わせて、一部のコンテナで問題が起きていることを検出して、それを取り除くデモも行っていました。簡単にモニタリングできますよ、というだけでなく、MLとの連携で「異常検知も素早く始められる」ということが、Elasticsearchの強みなのだなと再認識させられました。

X-Packのソースコードをオープン化!

このキーノートで一番盛り上がったのは、CanvasでもSQLでも、Infra UIでもなく、最後にShay Banonが「X-Packのコードをオープン化する」と発表した時でした。
f:id:acro-engineer:20180228181548j:plain:w700

ElasticsearchはOSSのプロダクトですが、いくつかの有償版の機能(X-Pack)のソースコードは非公開でした。当たり前ですよね。むしろ「有償版の機能のソースを公開するバカがいるかよ!」という話ですが、そのバカがここにいたんです。

ソースコードを公開することで、X-Packの機能がより認知され、フィードバックやコントリビュートなども得られるようになる一方で、リスクやデメリットなどもあると思います。ただElasticsearchやX-Packを使っているエンジニアとして、この方針はすごくありがたいです。正直な話、X-Packのいくつかの機能はソースコードJavadocが公開されていないせいで、利用しづらいと感じたこともありました。

この件についてShay Banonがブログを書いているので、ぜひ読んでみてください。
Doubling Down on Open | Elastic
あくまでもソースが公開されるだけであって、これまで有償だった機能(Machine Learningとか)が無償利用できるわけではない、という事だけは強調しておきたいと思います。

キーノート全体の感想

今年のキーノートは、何か凄く目玉となる新機能があったわけではなく、初公開の機能と、出たばかりの機能やユースケースを、いくつか取り揃えて紹介するという内容でした。また全体を通じて「立ち上げのスピード感」と「Machine Learningの自然な利用」を強調してきたなと感じました。

「立ち上げのスピード感」とはElasticsearchを使って「すぐに」監視や検索を始められることです。Infra UIがk8sをすぐにモニタリングできるなどが良い例でしょう。これはElasticsearchがミドルウェアやプラットフォームから、「ソリューション」に近くなっている様子を感じます。

また「Machine Learning (ML) の自然な利用」とは、Infra UIやAPMなどで、MLを使った問題の自動検出を行っていたところです。とても自然な流れで行っていました。そうやって使えるように、MLをうまくコモディティ化していると感じます。

この辺りの戦略面については話すと長くなりそうなので、また機会を改めて書きたいと思いますね。


そんなわけで、大きな目玉はないものの、有償プロダクトであるX-Packのソースコードをオープンにするという爆弾が投じられたElastic{ON}ですが、まだ始まったばかり。残りの2日間も、積極的に情報を集めてきます。


Stay elastic,
see you!