西海岸の風を浴びた同僚が「シークェール ！(SQL)」「マイシークェール！ (MySQL)」などと連呼するのを見て泣いている @cero_t です。海外カンファレンスに参加した人なら誰もが一度は掛かるハシカみたいなもんですよね、これ。
さて、Elastic{ON}も今日で最終日。昨日は初日セッションレポートだったのに、今日が最終日セッションレポートっていうのは、何ともスピーディーな感じですね！
今日参加したセッション
私が本日参加したセッションは次の通りです。
- Elastic Cloud: What’s next?
- SaaSで提供されるElastic Cloudと、それをセルフホスティングするElastic Cloud Enterpriseの紹介と今後の予定
- ツイートまとめ: https://twitter.com/hashtag/ec_cloud?f=tweets
- Kubernetes, Docker, and Containers at Elastic: Monitoring, Logging, and More
- KubernetesやDockerなどのコンテナや、その上で稼働するアプリケーションのモニタリングについて
- ツイートまとめ: https://twitter.com/hashtag/ec_k8s?f=tweets
- Logs, Metrics, and APM: The Holy Teinity of Operations
- Elasticsearchの新機能「APM」の紹介と、今後拡充する機能について
- ツイートまとめ: https://twitter.com/hashtag/ec_apm?f=tweets
- Logging and Metrics in Elastic Cloud: Drinking Our Own Champagne
- Elastic CloudのSREチームが、どのようにロギングやメトリクスを収集してきたかという事例
- ツイートまとめ: https://twitter.com/hashtag/ec_eclog?f=tweets
- State of Elasticsearch’s Java Clients
- Elasticsearchにアクセスできる3種類のJavaクライアントの紹介と、今後の予定、コントリビュート募集について
- ツイートまとめ: https://twitter.com/hashtag/ec_java?f=tweets
- Elasticsearch SQL
- みんな気になるElasticsearchのSQL対応について
- ツイートまとめ: https://twitter.com/hashtag/ec_sql?f=tweets
- Ask Me Anything
昨日とは打って変わって、王道系のテクニカルセッションに参加するようにしました。この中でも皆さんが気になりそうな「コンテナのモニタリング」と「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!
