Taste of Tech Topics

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

Elastic{ON} Tokyo 2015レポート 〜事例紹介 その3 星野リゾート、ゴールドマンサックス #elasticon

事例紹介その3は、星野リゾートと、ゴールドマンサックスです。
これで事例紹介は最後となります。

星野リゾートにおけるELKを活用した可視化と共有の取り組み

続いては、星野リゾートの久本英司さんによる
星野リゾートにおけるELKを活用した可視化と共有の取り組み」です。

私たちも一緒に取り組みをさせていただいています!(><)


星野リゾートは創業101年のホテル・旅館の運営会社で、
メディアなどに取り上げられる機会も増えて、認知度が非常に高まっています。

一般的に、ホテルや旅館は縦割り組織が多く、
フロントはフロント、清掃は清掃、レストランはレストランという形ですが、
星野リゾートでは、いわゆる「多能工」で、スタッフはマルチタスクで動いています。

そのほかにも、全員で経営判断をできるようにするとか、フラットな組織文化にするなどして、
顧客満足と生産性の両立を目指しています。


特に経営判断に必要なのが、情報共有です。

星野リゾートでは積極的な情報共有を行っていますが、
既存のシステムが古くて使い物にならないものがあったり、
KPIを収集する仕組みが世の中の変化についていけないとか、
あるいはセキュリティ面での課題があり、改善が必要となりました。

改善のアプローチとして、あらゆる経営情報を蓄積しておける場所が必要となり
ここにAcroquestからの提案で、Elasticsearchを利用することにしました。

手書きの絵やマインドマップを使ったビジョン共有を行い、
必要最小限のダッシュボードを作って見せてフィードバックを受け取り、
また改善したものを見せてはディスカッションしてフィードバックを受け取り、
ということを数ヶ月繰り返しました。

そのようなものを利用したところ、

1泊宿泊制限が解除されたタイミングで急に予約数が増えることが分かった
 → 制限が解除されるまで、多少、予約が少なくても大丈夫

とか、
他にも予約が入るタイミングが年々早くなっていること、
会員数が順調に伸びていることなどが、はっきり可視化されました。


将来構想としては、あらゆるデータを投入し、
Timelionや、Sparkとの連動、HipChatなどとの連携を進めたり、
たとえば大量キャンセルなどのタイミングでアラートを上げるなどの
業務に直結する部分のシステム化を進めようとしています。

またIoTの導入による生産性や満足度の向上、
需要予測・稼働予測、稼働調整なども視野に入れています。


実際に動いているものを見たい方は、ぜひAcroquestのブースまで!(>▽<)ノ

Goldman Sachs Engineering

続いては、事例紹介としては最後となります、
Goldman SachsのIan Macleanさんによる「Elastic in Equity Finance」です。

ワークフローやトレーディングオーダーの検索、法規文書やレジュメの全文検索
JVMやリソースなどのメトリクス、アラート、データ解析など
幅広い範囲でElasticsearchを利用しています。

GitHubからElasticsearchのソースをクローンして内部でビルドしており、
独自プラグインを用いて、セキュリティやバックアップの強化を行っているとのことです。
(マジか!)


Elasticsearchのメリットとして、サポートを挙げているところが興味深かったです。
設計レビューやパフォーマンスチューニング、パッチの適用など
サポートで得られるメリットが大きいとのことです。


事例としては、オーダーの検索が説明されました。
オーダー情報はSybaseに保存していましたが、とにかくレコードが多すぎたため
DBをかなり分割しなくてはいけなくなりました。

また検索も時間が掛かり、数時間かかるものがありました。
そのため、意味のある分析をするのが難しかったのです。
(そうですよね、検索が遅いと、分析を試すこともなかなかできない)


そこでElasticsearchを導入しました。
履歴データをElasticsearchに入れ、取引時間中のデータもインデックスしておき、
分析や可視化に利用します。Aggregationを使った高速な分析も行うようにしました。

そして、独自に「Sharp-X」という名の、管理/分析ダッシュボードを作成しました。
オーダーのデータを市場ごとに分析できるダッシュボードです。
履歴データと現在のデータを比較した分析や、取引でエラーが起きてないかどうかの確認などができます。

結果、アーキテクチャソースコードも、かなりシンプルなものになりました。


Elasticsearchは、開発が容易で、スケーラブルな、Game changerです。
今後、RDBMSから、HadoopとElasticsearchを用いたシステムにを置き換えることを計画しています。
(なんか私たちとやりたことが似てる!)


どちらも刺激的なセッションですね。
星野リゾート様のセッションは技術寄りよりも経営寄りの興味深い話でしたし、
Goldman Sachsは力の入れ方に圧倒される一方で、次にやりたいことなどが
非常によく似ているので、ぜひディスカッションさせてもらいたいなと思いました。


さて、事例紹介は以上となり、次はテクニカルセッションです!

Elastic{ON} Tokyo 2015レポート 〜事例紹介 その2 日本経済新聞 #elasticon

記事検索とログ解析でのElasticsearch活用事例

続いては、日本経済新聞社デジタル編成局の梅崎裕利さんによる
「記事検索とログ解析でのElasticsearch活用事例」です。

f:id:acro-engineer:20151216142913j:plain

新聞記事の全文検索とか、なかなか胸が熱くなるタイプのヤツですね。

検索の需要がある中でSolrとElasticsearchの検証を進める中、
気がついたらElasticsearchがメインの仕事になっていたとのこと。
これ、Elasticsearchあるあるですかね。


コンテンツ検索とログ可視化の両方で使えるから、という理由でElasticsearchを採用したそうです。

コンテンツ検索は、200万のデータ(5GB)で、1日数千の更新頻度、リクエストは秒間100回ぐらい。
検索APIは、Django API + Elasticsearchで、マスターはMySQLに別途保存。
本番稼働を始めてから半年以上運用しているようです。

Kuromoji、ICU normalizerの利用、ngramと形態素解析の両方でインデックス作成、
また完全一致用にnot_analyzed(文節や単語で分かち書きしないやつです)も残しています。
(なるほど、検索のために全力だ)

また、新聞記事をスマホで撮ると、関連記事を検索する「もっと日経」というサービスが提供されていまして、
こちらは写真の画像をOCRして、Elasticsearchを用いて検索しています。
OCRの課題はあるそうですが、これは面白いサービスですね。


一方、アクセスログ解析の方は、いわゆるELK/EFK構成(Elasticsearch + Logstash/Fluentd + Kibana)

アクセスログは、1日約3億件(120GB)で、1週間分を保持。
r3.xlargeを6台で運用し、物理メモリ180GB(うちヒープは72GB)という構成。

それで月額20万円程度、もしスポットインスタンスが使えれば月約3万円ぐらいになること。
24時間分のログ集計に、10秒〜1分ぐらいかかるそうです。
検索回数が多くないので、この程度の台数で済んでいるとのこと。
(かなりサイジングの参考になる事例ですやん!)


アクセスログから、HTTPエラーやファイルごとの帯域の可視化、
どの地域からのアクセスが多いかなどを分析しているとのこと。

何よりも、これまでエンジニアが秘伝のソースで解析していたログを
Kibanaで可視化することで、URLや画像で共有できるようになったことが大きな改善ポイント。

また解析に掛かる時間も、当初10分〜1日以上というバッチだったところから
長くとも1分ぐらいになっている点で、フィードバックも早くなりました。

「Kibanaは楽しいから、気づいたら時間がすごい経ってる」というのは、私も共感するところです!


ということで、ここで休憩に入りました。


きゃー、LTの準備が進んでないー!!

Elastic{ON} Tokyo 2015レポート 〜事例紹介 その1 リクルートテクノロジーズ、Naver #elasticon

つづいて、各企業の事例紹介に移ります。
Elastic{ON}は、この東京だけでなく、Elastic{ON} Tourとして世界中をツアーしているのですが、
いずれの地域でも、必ずたっぷり事例紹介が行われています。

リクルート流Elasticsearchの使い方

そんな事例紹介の第一弾は、
株式会社リクルートテクノロジーズの中原裕成さんによる
リクルート流Elasticsearchの使い方」です。


検索基盤や通知基盤でElasticsearchを利用

全社検索基盤「QASS」や、全社プッシュ通知基盤「Pusna-RS」、
またそれらを含む様々なサービスの可視化などでElasticsearchを利用しています。


元々はApache Solrで、各サービスごとに検索エンジンクラスタを組んでいたが、
当時の構成の都合上、検索性能 / 更新性能に限界がありました。

検索品質を向上させるため、全サービス共通の、検索サービスの共通基盤を作ることにして、
その時に盛り上がっていたElasticsearchを採用することにしました。
それで出来たのが全社共通検索基盤「QASS」です。

Spark / Hadoopを用いた分析基盤があるため、これでelasticsearchの検索結果を分析し、
専門チームがelasticsearchの検索結果の継続的品質向上を行っているとのことです。
(何それすごい!)


続いてPusna-RSですが、これはリアルタイムなプッシュ通知を送るシステムです。

データをDynamoDBに保存しているのですが、単純な投入や全件取得は高速なのですが
検索条件を指定した検索は苦手で、そこでelasticsearchを利用することにした。

同じデータを、DynamoDBとelasticsearchの両方に投入し、用途に応じて使い分けている。
(マジか!!)


そして、それぞれのサービスは可視化しており、QASSの検索結果の指標や
プッシュ通知の登録状況や配信状況を可視化しています。

運用ノウハウ

ありがたいことに運用ノウハウの共有もありました。
1. プラグイン機構の利用
2. スナップショットの利用
3. Re-indexの手法


elasticsearchにで提供されているプラグイン機構を用いて、検索を最適化する、
スナップショット機能を利用してS3やHDFS、ディスクなどにスナップショットを残す、
スナップショットのリストアはJenkinsを用いて行うなどしています。

またre-indexですが、考え方的にはブルーグリーンデプロイメントと同様で
クラスタごと再構築を行い、データを流し込んでから、クラスタの切り替えを行っているそうです。


あと、バージョンアップでそれなりに内部構造も変わるので
バージョンアップは計画的に、とのことでした
(分かる!!)

Searching and Alerting for application logs with Elasticsearch at Naver

2社目は、NaverのJaeik Leeさん、Seungjin Leeさんによる
「Searching and Alerting for application logs with Elasticsearch at Naver」です。

最初にLINEを使っている人、という質問がありましたが、ほぼほぼ全員が手を挙げる感じでした。
ちなみにこのブログの写真も、他のメンバーに撮ってもらってLINEで共有しています。


さて、そんなNaver社のElasticsearchの使い方ですが、
元々、エラーログの収集や解析をするシステムを利用していたところ
収集や検索性能に限界を感じて、elasticsearchで再構築をしたとのことです。

スケールとしては、8クラスタ、229ノード、毎日2TBのログが集まっており
現在までに160TBのログが集まっているとのこと。
(半端ないんですけど、何すかそれ?)


Kafka + Kafka Riverを使ってElasticsearchにデータを流し込んでいたところ
パフォーマンス問題や、不安定さ、デバッグの難しさがあったため
Kafka + Stormの構成に変更し、改善させたそうです。

クラスタはマスターノード群、データノード群、クライアントノード群(or ロードバランサ)に分けるほか
直近1週間のデータはSSD、それより古いものはHDDに入れて、保存しているとのことです。


通知の仕組みとして、パーコレーターAPIを用いてこれに合致したものを
Kafkaに送り、そこで判定を行って通知を投げているそうです。
(パーコレーターAPIの一番正しい使い方ですよねこれ)

そしてKafka側で、設定された閾値と時間(たとえば5分間に10回、とか)に従って
ログイベントの通知判定を行って、通知しているとのこと。
通知ルールを変えた際には、Kafkaに通知して、キャッシュをクリアすることにしているとのこと。


2社とも相当なスケールの事例紹介で、少ないノードでなんとか回してる私としては圧倒される感もありますが
リカバリの方法や、通知の方法など、ぜひ取り入れたい学びもありました。

さぁ、続いてのセッションも楽しみですよ!

Elastic{ON} Tokyo 2015 キーノートレポート #elasticon

elastic須田さんの明るい挨拶から始まりました、基調講演。
堅苦しくない、会場のスーツ率も低めな、エンジニアのイベントという雰囲気あります!

f:id:acro-engineer:20151216120211j:plain

Elasticsearchが生まれたきっかけは?

最初はElasticのファウンダーでありCTOであるShay Banonから、
elasticsearchの生まれた経緯の紹介がありました。

奥様が使う検索システムとして、Java + luceneを使ったのがきっかけなんだとか。
やばい、初耳だけどいい話やん!

f:id:acro-engineer:20151216120159j:plain

事例紹介。NASAでも使ってるよ!

そして大きな事例紹介。
Wikipedia検索エンジンとしてElasticsearchを利用した。

またmozillaFirefoxのクラッシュレポートをelasticsearchで集めて、
セキュリティ問題への対策などを行った。

NASAは火星のRoverで取ったデータをElasticsearchに集めた。
マジか! 震える!!(うつった)

verizonはミッションクリティカルアプリケーションの中で
elasticsearchでを使って情報を集め続けた。


そんな事例たちです。

ちなみに英語のセッションですが、同時通訳されています。
ただ、パッと見で、半分ぐらいの人がイヤホンをつけてない感じがします。

Elastic{ON}に来る人たちの英語力の高さよ!!

Elasticのスタックたち

続いて、ELKスタックの紹介。


またプラグインで、さらに機能追加ができます。

この辺りは実案件で利用するには欠かせない機能たちですよね。

Elasticsearch 2.1

そして最近リリースされたElasticsearch 2.0/2.1の新機能や機能改善の話。
Elasticsearchはアップデートが早いので、1ヶ月単位でも色々と改善されます。

回復力、というか最近よく見るキーワードの「Resiliency」

  • リカバリ時間の短縮
  • 永続的な書き込み
  • Javaセキュリティマネージャ

パフォーマンス改善

  • クラスタの強化
  • メモリやストレージの削減。特に2.0からヒープをあまり使わない設定がデフォルトになりました。
  • キャッシュとスロットリングの改善

分析の強化

  • 列ストア。これまではJavaのヒープを使っていたけど、ファイルを使うようになった。
  • 時系列での計算。たとえば増加する数値の差分計算など。これを使ったUIがTimelionですね?
  • 予測と異常検知。何かと思ったらPipeline Aggregationでした、なるほど。
Elasticsearchの将来

もちろん現状だけでなく、次のロードマップ的なものも紹介されます。

機能強化

  • geoデータ分析の強化
  • クエリのプロファイリング

管理機能の強化

  • Reindex API
  • タスク管理API

特に管理機能のRe-index APIは、みんな欲しくなる機能ですよね。
いまはLogstashや、自前でコードを書くなどして頑張ってRe-indexしているので
これは早くサポートして欲しいところです!

Kibana 4.2 & 4.3 and Future

続いて、Kibanaの紹介。
Kibanaは可視化のダッシュボードです。
Kibana開発者であるRashid Khanからの発表で、
twitterでも「お世話になってます!」のメッセージが見えますw

f:id:acro-engineer:20151216120356j:plain

4.2では、バブルチャートやヒートマップの追加、
フィールドのフォーマット(数値にカンマ入れたりできるやつ!)や
地図のカスタマイズなどが強化されました。

4.3では、サーバ状態を閲覧できるページが追加されたほか(エラーの時だけ出てくるやつや!)
ログレベルの設定、オブジェクトのエクスポート、タイムゾーンのサポートなどが追加されました。
エクスポート機能なんてついてたんですね、知りませんでした。試してみます!

また紹介されませんでしたが、4.2だか4.3だかで、項目ラベルを自分でカスタマイズできる機能も追加されました。
これは地味に嬉しいやつで、この機能を求めるissueには、いっぱい +1 がついてました。
っていうかいまだにつき続けています。


Kibanaは将来的に、アプリケーションプラットフォーム化されていきます。
Angular + node.js + Elasticsearchを用いた可視化アプリを簡単に作るためのプラットフォームです。

ちなみにこの辺りはまだオフィシャルな情報はないのですが、Elasticsearch Advent Calendarの2日目エントリー、
「Kibanaプラットフォームでアプリケーションをつくってみよう」で紹介されています。
http://qiita.com/zoetro/items/cd66f79cedd6d435a645
私もKibanaアプリを作りたいっていうか、作らなきゃいけない感じになってきていますので
このページなど見ながら勉強したいと思います!

Timelion

Timelionというスペルで、アイコンもライオンなのに、「タイムライン」って発音するKibanaアプリ。
時系列データに特化したダッシュボードを作ることができ、
複数のグラフを重ね合わせたり、グラフ間での計算などができるようになりました。
Kibanaにこういう機能が欲しい、とリクエストされていたものが別の形になって表れた形ですね。

Logstash 2.1

Logstashとこの後のBeatsの説明は、Tanya Braginが行いました。
この方とは、以前、Mountain View訪問した際に打ち合わせをさせていただきました。

f:id:acro-engineer:20151216120257j:plain

Logstashは情報の収集を行うツールです。
(たぶん日本では「fluentdみたいなやつ」って言った方が、理解が早い気がします!)

Logstash 2.1ではシャットダウンの改善、パフォーマンスの改善、
デフォルトでの設定値の見直し、プラグインのオフラインインストール対応などが行われました。


今後はキューが大幅に見直され、永続化されるようになり、
またキューの長さも可変になり、デッドレターキューが追加されるなど、
キューとしてきちんと使える、つまりデータの中継地として活用できるようになってきました。

多数のサーバのシステムリソース収集やログ収集を始めると、
ログを集中的に収集して、中継するような仕組みが欲しくなるものなのですが、
そこにLogstashが入ってくる形ですね。

AWSで言うところのKinesisの役割を、Logstashが負ってくることを期待しています。

Beats & ES-Hadoop

Beatsは昨日震えたやつなので、そちらを参照してください。
acro-engineer.hatenablog.com

なお昨日は触れられていませんが、ログファイルをElasticsearch/Logstashに転送する「Filebeat」というBeatもあります。
これまで、Logstash forwarderやfluentdのtail pluginなどで実現していたところで、このFilebeatが使える形になります。


ES-Hadoopは名前のまんまですが、ElasticsearchとHadoopを連携するプロダクトです。

Elasticsearchから情報を取って、Hadoopで加工/分析/集計などを行って、
またElasticsearchに書き戻すことができるようにするための機能ですね。
MapReduce、Hive、Pig、Cascading、Spark、Stormに対応しています。

Elasticsearchを検索エンジンや、可視化のためのストレージだけでなく、
アプリケーションプラットフォームの中枢として用いることを狙っているように思うプロダクトですね。

拡張機能たち

まだまだ紹介は続きますよー! 続いては拡張機能たち。
これはSteve Mayzakから紹介されました。

Shieldはセキュリティプラグイン
LDAPと連携したSSOや、通信経路の暗号化、監査ログなどの機能を有しています。

Shield 2.1からindex(RDBMSで言うところのテーブル)レベルのセキュリティ制限だけでなく、
フィールド(RDBMSで言うところのカラム)レベルでのセキュリティ設定ができるようになりました。

将来的には、APIの強化や、管理UIの追加などが予定されています。
管理UIはよっ!


Watcherはアラートや通知を行うためのプラグイン
モニタリングの用途にElasticsearchを使う時には、絶対なくてはならないヤツですね。

Watcher 2.1で複数のデータソースに対する複合的な判定(と、その結果による通知)や
Pipeline Aggregationを用いた異常検知機能が追加されています。
この辺も、早く試してみなくては!

こちらも将来的に、管理UI、Kibanaとの統合などが計画されており、早く来て欲しいです!


MarvelはElasticsearch自体のモニタリングを行うためのプラグイン
こちらは既にKibanaアプリとして、Kibanaに統合されています。

Elasticsearchが動いているJavaプロセスのCPU使用率、メモリ使用量、ディスクの空きサイズ、
またindexの数や、検索/追加のスループットなども、すべて可視化されます。

現在はElasticsearchのモニタリングのみですが、
将来的にはLogstash、Kibana、Beatsのモニタリング機能や、アラート機能の追加が計画されています。

ELKの開発者にフルサポートされている「唯一の」マネージドElasticsearchサービス、Found

Elasticsearch as a Serviceの形で提供されているのが、Foundです。
唯一の、というところが強調されており、
AWS Elasticsearch Serviceへの対抗意識が垣間見えます。
そう、AWSのやつはOSSホスティングなので、上に書いた拡張機能が使えなかったり、
elastic社のサポートが受けられなかったりするのですよね。

どうあれ、
Elasticsearchの環境構築や運用というのは、それなりに大変だなと日々使っていて思うので、
この辺りを一気にアウトソーシングできるFoundは、かなり有用な気がします。


ということで、elasticの今とこれからを一気に紹介する、お腹いっぱいの基調講演でした。
午後からは、各社の事例紹介が続きます!


ちなみに、お昼はお弁当が用意されています。
無料イベントなのに、ありがたすぎます!!!

Elastic{ON} Tokyoスタート! #elasticon

Hello world, @ です!

いよいよ始まりました、Elastic{ON} Tokyo 2015!!
https://www.elastic.co/elasticon/tour/2015/tokyowww.elastic.co


elastic社のCTOやプロダクトマネージャ、アーキテクトなどが集う本イベントは
かなり人気が高く、サイトが公開されてから数日のうちに満席になっていました。

というか当初は開催地が「東京」とだけ書かれて、場所の詳細が分からなかったのですが
その時点で既に満席になってましたよね (^^;


そんなElastic{ON} Tokyoに、Acroquestもスポンサーとして参加してデモブースを出展しています。
昨晩も深夜まで準備していたことはもちろん内緒ですが、
Elasitcsearch + Kibanaを使ったシステム可視化、ビジネス可視化、ユーザ分析、そしてセキュリティ可視化など
いくつかのデモを用意しています。もし会場にいらっしゃる方がいれば、ぜひお越しください。


そしてイベントに参加されない方も、
今日はイベントレポートでブログをどんどん更新していく予定ですので、ぜひ読んでください!

それでは、
Stay Elastic,
See you!


あー、LTの準備しなきゃ!!

elasticの新プロダクト「Beats」シリーズに震える!

初めてこのブログに投稿します、PlNOKlOです!
皆さんよろしくお願いします。

このエントリーは、Elasticsearch Advent Calendar 2015の15日目です。

f:id:acro-engineer:20151215231044p:plain

さて、
今日紹介したいのは、elasticの新プロダクト「Beats」シリーズです。

社内で @ さんが「みんなでBeatsのWebinarを見る夕食会」なるイベントを
突発的に企画したので、よく分からないながらも参加してきたのですが、、、

震えました

モニタリングツールとしてかなりよくできている感じで、
@ さんが騒ぐ理由も分かる気がしました。

特にPacketbeatは想像以上にヤバかったですね。
皆さん、こいつは注目です!

ということで、そんなBeatsシリーズのうち、
TopbeatPacketbeatの2つについて、私の震えポイントを紹介します!

1. Beatsとは?

まずBeatsって何ですの?ってところからですよね。

Beatsはelastic社の新プロダクト群で、
Elasticsearch/Logstashに情報を送信するshipperという位置づけです。

サーバに常駐して、リソース情報や、ログファイル、HTTPリクエストや、
発行したSQLなど(!)を取得して、Elasticsearchなどに情報を転送します。

そのあと、Elasticsearch側でKibanaを使って可視化をする、ということになります。

要するに、
モニタリングツールのエージェント」という位置づけですね!震えるぜ!!

2. インストールの手軽さに震えた

最初の震えポイントは、インストールの手軽さ、というか構成のシンプルさでした!

Topbeat、Packetbeatとも、それぞれファイルが「3つ」ずつしかありません。
RPMでインストールしても、zipやtar.gzを解凍しても、3ファイルしかできません。

Topbeatで言えば、

1. topbeat : 実行用バイナリ
2. topbeat.yml : 設定ファイル
3. topbeat.template.json : elasticsearch用テンプレート

この3つです。ホントにこれだけ。

そして設定ファイルにelasticsearchのアドレスを書いて、
Elasticsearchにテンプレート (json) をcurl -XPUTで流し込めば、すぐに使い始めることができます。

※もちろん事前にelasticsearchがセットアップされてることが条件ですが(◎_◎;)!

この手軽さ、震えます!!

3. ダッシュボード作成の簡単さに震えた

私は仕事でElasticsearch + Kibanaを使ってダッシュボードを作成しているのですが、
難しくないとはいえ、それなりに面倒な作業だったりします。

じゃぁBeatsの可視化も面倒かというと・・・
なんと、ダッシュボードのサンプルがgithubで公開されていて、
これをダウンロードしてelasticsearchに突っ込めば、ダッシュボードが完成します。

https://github.com/elastic/beats-dashboards

これで作ったTopbeatの画面は、こんな感じ。

f:id:acro-engineer:20151215231155p:plain

HOOOOOOOOOO!!FURUERU!!!!


4. Packetbeatで取れる情報に震えた

Packetbeatって、せいぜい通信量の可視化ができる程度の
プロダクトって思いません?名前的に。

ところがどっこい。全然それどころじゃないんですよ。

Packetbeatは、キャプチャしたパケットを解析して、
それがたとえばHTTPのパケットであれば、リクエストURLやHTTPステータスを取得する、
MySQLのパケットであれば、発行しているSQLや、発行結果を取得することができます。

ミドルウェアごとのパケットを解析して、その中身を見ているということです。
たとえばMySQL(実際にはAWS Auroraなんですが)は、こう見えています。

f:id:acro-engineer:20151215233810p:plain

発行したSQL回数や、時間が掛かったSQLのランキングなどは、明らかに便利そうですね。
PreparedStatementのバインド変数 ? も、値をバインドした状態で出力されます。助かります!


ちなみに、Packetbeatはクライアント側でパケットキャプチャをするので、
MySQLサーバにインストールするのではなく、Webサーバ側にインストールすることになります。
だからAWSのRDSでも問題なくパケットキャプチャ&可視化ができるというわけですね。

現在までに対応しているミドルウェア
MySQLPostgreSQL、Redis、Thrift、MongoDB、memcache、
それDNS、HTTP、TCP/UDP、ICMPに対応していて、今後も対応プロトコルを増やすとのことです。


これがOSSで公開されているというのがすごい!!
震えますね!!!!!


5. Go言語が便利で震えた

ところでBeatsシリーズってどの言語で実装されているの?
と思ってリポジトリを見てみると、

https://github.com/elastic/beats

ふむふむ。Go言語で実装されていると。

Go言語はLinux / Mac / Windowsのクロスコンパイルができるので、複数の環境で動かしやすいとか、
Javaのようなランタイムをインストールする必要がないとか、
また、メモリのフットプリントが小さいので、マシンのリソースあまり食わないとかですから、
なるほど、Beatsシリーズのようなエージェントの実装には最適だと思わされました。

まぁ全部先輩の受け売りなんですが。。。

とにかくGo言語
なんか便利そうで震える!!!!!!

まとめ

震えました。


なお、明日12/16(水)に開催されるElastic{ON} Tokyoでは、
Acroquestもブーススポンサーとして出展します ^^)/

様々なダッシュボードのデモもお見せしますので、
皆さん、よければぜひお越しください!


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


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

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

AWS IoTの性能を測ってみた ~AWS IoT Performance Benchmarks~

こんにちは、再びishida(@)です。

本投稿はQiitaのAWS IoTアドベントカレンダーの11日目になります。
8日目「AWS IoTから NumericなRangeKeyを持つDynamoDBテーブルへput-itemをする方法 - Qiita」からの投稿からの続きとなります。

2015年10月に、AWS re:Invent 2015にて発表されたAWS IoTですが、じわじわと人気が出始めていますね。ブログで「○○と繋いでみた」というような記事を公開している人も増えてきました。

f:id:acro-engineer:20151211103150p:plain

AWS IoTはデバイスとクラウドのセキュリティを確保しつつ、HTTPやMQTTといった様々な通信プロトコルにも対応し、さらに各種AWSサービスへの連携も簡単に可能な、マネージド型クラウドプラットフォームです。

今回、このAWS IoTに対してPub/Subの性能評価を実施し、その結果をまとめてみました。

前提

AWS IoTは、普通のMQTTの仕様に対して、限定的な対応がされています。MQTT v3.1.1とAWS IoTを比較すると、以下のようになります。

AWS IoT MQTT
対応QoS 0,1 0,1,2
Retain ×
Will ×
TLS/SSL
Payloadサイズ制限 128KB 256MB
順序保証 × ×

計測条件/内容

以下の条件で、今回測定をしています。

Clientツール AWS IoT
リージョン ap-northeast-1 ap-northeast-1
インスタンスタイプ c4.xlarge -
インスタンス 1(Pub/Sub同一インスタンス上で実施) -

計測結果

3回ずつ測っての平均値をとりましたが、以下の通りになりました。

Publish Subscribe
QoS=0 32273 4844
QoS=1 10512 1012

*単位は[messages/sec]

  • Publishについては約32000msg/secと、十分な性能を出すことができている。
  • Subscribeは約4800msg/secと、Publishに比べて性能が出ていない。


SSLを使用したMQTT通信のため、そもそも性能がそれほど出ないのではないかと思っていましたが、予想に反してPublishの性能が良かったですね。

IoTが世間でも頻繁に使われるようになった現在において、如何にAWS IoTが時代を引っ張って行ってくれるか、まだまだ目が離せませんね!


それでは。

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


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

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