2017-03-28

BASEさん主催のPAY Developer Meetup #00 に参加してきた

イベント決済

週末募集開始されて、月曜開催というタイトなスケジュール。
特に用事なんて無いので参加させていただきました！

base.connpass.com

f:id:mamepika:20170328002814j:plain

BASEさんの新イベント用スペースめっちゃ綺麗でした！
椅子も今日出したばかりの新品らしい。

LT2本立ての構成でした。
次は喋ってみたいな～。

PAY ID決済イントロダクション

speakerdeck.com

PAY事業部の高野さん。
PAY IDの概要から、実装までを見せてくれました。
ダッシュボードでクライアント用ID発行して、HTMLに1行追加するだけでカード入力画面にPAY ID決済ボタンが出現！

詳しくは↓
id.pay.jp

PAY ID

2016年6月27日に提供開始した購入者向け決済サービス
PAY IDにクレカ情報や配送情報を紐づけることで都度入力せずに決済が可能
BASE加盟店を含む40万加盟店で利用可能

毎回決済のたびに財布からカード取り出して、番号やセキュリティコード入力する手間が省けるのでいいですよね。

導入方法

1 PAY ID Checkout

決済時の画面遷移なし
画面遷移させたくない

2 OAuth API

決済時の画面遷移アリ
住所や電話番号も扱えるので物販ECなどで利用

デモ

あっという間に実装されるさまは圧巻。
ダッシュボードのUIも今風でかっこいい。

質疑応答

Q.UIのカスタマイズは
A.Checkoutは既存のもの。OAuthAPI使えばカスタマイズできる。

Q.テスト環境使ってるんだけど任意の値が入れられるけど、表示順がバラバラになる
A.導入を検討する。

Q.PAYIDの住所や電話番号は認証済み？
A.物販で使用された実績はあるが、100%の保証はない。

PAY.JP使ってます

MAMORIOの高野さん
www.mamorio.jp

Pay.jp、使ってます from Masanori Takano

www.slideshare.net

金曜日にLTの依頼があったらしい。

PAY.JPにした理由

ApplePayでの課金実現可能
HPが綺麗だったから
コミュニケーションが他社よりフランク
開発者ページが充実

懇親会では途中ボッチになってましたが、会話に混ざっていくことで
結果としていろんな人と話が出来て良かったです。

次回もぜひ参加したいです。
ありがとうございました！

2017-03-13

Apache Struts2の脆弱性(S2-045,CVE-2017-5638) を突かれ、クレジットカード情報等72万件流出

f:id:mamepika:20170313151525j:plain

週末にびっくりするニュースが飛び込んできましたね。
都税と住宅金融支援機構のサイトからクレジットカード情報などが大量に流出しました。
itpro.nikkeibp.co.jp

3月8日にIPAが公開した、Apache Sturts2の脆弱性を突かれたようです。
www.ipa.go.jp

Sturts2の脆弱性

Struts2は2016年にも重大な脆弱性が報告され、ネットを騒がせました。

www.ipa.go.jp

この時に修正版を適用して良しとするのではなく、システム全体を改修すべきだったようです。
Java EEやSpringではこのようなことは起きていませんからね。

Struts2は何度も致命的な脆弱性を出しています。
そのたびにNGワードを追加することで対応してきたのですが、対応がお粗末です。

通常のサイトであれば、Struts2を使い続ける選択肢はあると思いますが、
クレジットカード情報など機微な情報を扱うサイトでは、去年の時点で移行をすべきだったように思います。

無くならないカード情報流出事件

去年起こった大きな事件としては以下の2点を挙げておきます。
www.itmedia.co.jp

[http://www.itmedia.co.jp/enterprise/articles/1612/02/news106.html:title=ニュース - 資生堂子会社で個人情報流出の疑い、最大42万件脆弱性突かれる：ITpro]

これらの事件を受けて、カード情報を扱う事業者に対してPCI DSSの取得を義務付ける流れになっており、
PCI DSSの取得が難しい事業者については、決済代行業者にカード情報を預けるように施策が進んでいたのですが、
決済代行業者による流出事故ということで、インパクトが大きいです。

Struts1.Xを使い続けるということ

今回、Struts2のみが対象となり、Struts1は無事だったので、Struts1なら大丈夫という間違った認識がありますが、
Sturts1は誰も公式にメンテナンスをしておらず、潜在的リスクはStruts2以上に存在します。

修正版適用までのスピード感

今回、脆弱性発表からわずか数日で大量のデータ流出が起きたことから、
修正版の適用にはスピードが求められます。
Sturts1は誰も公式にはパッチを作りませんので、Struts1を使っている会社がそれぞれパッチを作成、テスト、適用をしなくてはなりません。
クラッカーとの時間勝負の中で、これでは完全に負けてしまいます。

個人情報を扱うようなシステムの場合、Strutsからの早期の移行が必要になると思います。

脆弱性についての情報収集体制

3月8日にIPAから情報が発信されましたが、業者が実際に調査を開始したのは3月9日の18時以降となっています。
そして、その時点で既に攻撃を受けていたということですので、
決済代行業者には情報収集の体制強化が求められることになるでしょう。

PCI DSSについて

www.jcdsc.org

今回、流出した情報の中にセキュリティコードがありました。
PCI DSSではセキュリティコードの保存は禁止されていますので、PCIDSSに準拠していなかったということになります。

PCI DSS審査の信用失墜

PCI DSSはカード情報を扱う会社に取得が義務付けられています。
厳しい実地調査もあるのですが、セキュリティコードの保存をしていても認証を受けられてしまうということで審査に対して疑問符が打たれます。

PCI DSS認定事業者について

PCI DSSの審査の信用が失墜したことにより、PCI DSSに準拠しているというだけではユーザは安心できない状態になります。
業界全体で信用回復への取り組みが必要になるでしょう。

情報処理安全確保支援士の活用

個人情報を扱うシステムの開発・運用に情報処理安全確保支援士を必須とするといいと思います。
まさにこういった自体を防ぐために、資格が整備されたはずです。

対象者4万人と言われる中、初回登録申請者数が4000人強にとどまったのは
飴とムチのムチのみが規定された現状では仕方ないと思います。

www.ipa.go.jp

情報処理安全確保支援士の独占業務を作り、情報共有ネットワークの整備・高度な研修による実務的な技術を身に着けられるようにすれば、
取得希望者も増え、技術者の待遇向上にも寄与し、日本国内の情報システムのセキュリティ向上も図れるかと思います。

2017-03-13

JAWS DAYS 2017に参加してきた #jawsdays

イベント AWS

今年から仕事でAWSを使うようになって、
色々とAWSが気になってきているところに丁度イベントがあったため参加してきました。

f:id:mamepika:20170313004235j:plain

朝から参加しようと思ってましたが、起きれず11時からのセッションの参加でした。
会場がビルかと思ってたら、低層の建物でびっくりしました。

参加したセッションは以下の通り

本当の敵は社内にいる！？～攻める情シスが吠える座談会～
ランチタイムセッション　株式会社はてな
EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
金融クラウド＆FINTECH最前線。～AWSで金融からイノベーション！ 2017
武闘派CIO３人が、ホンネで語るITの現実
AWSデータベースアップデート 2017

本当の敵は社内にいる！？～攻める情シスが吠える座談会～

企業の情シスの担当者が、如何に社内システムをクラウドに移行させていくか、移行させるにはどんな苦労があるかっていう話でした。

クラウド導入で変わったこと

従来のウォーターフォールからアジャイル型に変わってきた。
旧来のベンダーはクラウドの知識が浅く、社内担当者のほうが詳しいこともある。
ベンダーもクラウド移行に伴い、クラウドファーストなベンダーに切り替えていった。

等々。
CIOが社長決裁直前の稟議書を破り捨てて、クラウド移行を推し進めた話など面白かったです。

ランチタイムセッション　株式会社はてな

ベストトーカーそーだいさんの話。
PostgreSQLの話ではなく、Mackerelの話でした。

グラフは綺麗で直感的でした。
リソース監視に重点置いたシステムなのかなって思いました。
僕は今、業務では開発者目線でElasticsearch + Kibanaでの可視化を進めてますが、
Mackerelは運用目線ではよさげです。

EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS

これはあんまりおもしろくなかったですね。
Excelから脱却と銘打っておきながら、Excelファイル生成してたので良く分かりませんでした。

DevOpsも今まで手動でやってきたことが自動でできるよで、話が止まってたので、
いや、それじゃ昔と変わらないじゃん・・・って。

金融クラウド＆FINTECH最前線。～AWSで金融からイノベーション！ 2017

FinTechって独り歩きしてて、何がFinTechなのかってのがいまいち分かってないので参加してみました。
なお、僕の理解としては、
「今まで金融機関の中で閉じていた大量のデータを集計・分析した結果をAPIを通じて公開する」だと思っています。
肝はAPIですね。

クレジットカードの決済や残高照会、振込なんかは今までもあったので、違うかなと。
それ＋αを金融会社がどう提供できるかって話ですよね。

金融クラウド FinTech

1年余りで猛烈な勢いで大変化。
クラウドエンジニアと金融が急速に身近になってきている。
まずは金融とエンジニアの話。ゴールドマンサックスさんなんかが凄いですよね。

FinTech企業のこれから

電子決済代行業者

登録制の導入
情報の適切な管理
業務管理体制の整備

⇒金融機関も上記の状況を確認する

オープンAPIの利用

顧客は金融機関に対して利用申請。
金融機関が決済代行業者にトークンを発行しアクセス権限を付与。
中間業者はトークンを利用して金融機関のAPIを通じて、処理を実行。

三菱東京UFJがAWS使うよって話が10分くらいあって、そういうこと聞きたいんじゃないけどなって感じでしたが、
後半はFinTechってのがどういうものか、少しだけ話があって形が見えてきました。
FinTechはやはりAPIだなっていうのは確認できました。

武闘派CIO３人が、ホンネで語るITの現実

CIO三人がのっけからお酒飲み始めて笑いました。

以下の名言は肝に銘じます。
新しいことやりたいなら、勝手に初めて客を付けてきてから社内にやりたいって言え

ただやりたいってだけなら、会社からは今の仕事をやれとしか言われない。
客を付けてきてから言えば、会社もNoとは言えないってことでした。
いや、これ実践したいと思いますよ。

AWSデータベースアップデート 2017

Aurora凄いって話でした。(簡略化しすぎ)
検索スピードとかだけでなく、データ移行のしやすさとかも考慮されてて、ほんとAmazonに任せておけば大体解決するって感じです。。。

セッションには若干当たりはずれありましたが、イベント全体通しては参加してよかったです。
学校の同級生にも会えたので満足。
運営の皆さん、スポンサー企業の皆さんありがとうございました！

2017-03-04

Kibanaで円グラフ(Pie Chart)を作って可視化する #elasticsearch

Elastic Stack Kibana

リソースの可視化、ログデータの投入と来たら次はログデータ自身の可視化ですね。

Kibanaでは様々なグラフや表が用意されており、
それらを組み合わせることで目的に合わせたダッシュボードを作ることができます。

今回は、ログ内のUser Agent情報から、デバイス・OS・ブラウザの割合を円グラフ(Pie Chart)を使って可視化してみたいと思います。

User Agentは以下のサイトを参考にさせていただきました。
歌うキツネ : User-Agent (ユーザーエージェント) 一覧

こんな感じのログを適当に作成

2017-03-02_23-11-00.123,hostap1,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393
2017-03-02_23-12-00.123,hostap1,Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

Logstashの設定ファイルはこんな感じ。

input{
    file{
      path => "C:\dev\ua.txt"
      start_position => "beginning"
    }
}

filter{
     csv{
       columns => ["processingDate","hostName","userAgent"]
       separator => ","
     }
     date{
       match => ["processingDate" , "yyyy-MM-dd_HH-mm-ss.SSS"]
       timezone => "Asia/Tokyo"
     }
     useragent{
       source => "message"
       prefix => "ua."
       
     }
     mutate{
       remove_field => ["host","userAgent"]
     }
}
output{
    elasticsearch{
       hosts => ["<Elasticsearchが動作しているサーバのIPアドレス>"]
       index => "useragent-%{+YYYYMMdd}"
    }
}

filter-useragent

今回の肝。
指定されたソースからUserAgentの書式を見つけて、
いい感じに各項目にパースしてくれるフィルターです。
prefixで接頭語を指定できます。この場合"ua."で始まる項目がuseragentフィルターで作成された項目ということになります。

mutate-remove_field

出力項目から指定された項目を除外するフィルターです。
userAgent項目はパースされており、2重になるので省いています。

Kibanaで可視化

さて、Kibanaで可視化してみましょう。

Index Patternsの追加

Kibanaのメニューの一番下にある「Management」をクリックし、
表示された項目の「Index Patterns」をクリックします。

f:id:mamepika:20170304152509p:plain

そして「+Add New」ボタンをクリック。
f:id:mamepika:20170304152614p:plain

Index name or patternに今回設定ファイルで設定した”useragent-YYYYMMdd”が対象になるように
「useragent-*」を入力し、「Create」ボタンをクリック。
f:id:mamepika:20170304152738p:plain

Discoverでの表示

Kibana画面右上の時計マークをクリックして、対象のログの時間に合わせます。
f:id:mamepika:20170304153107p:plain

Kibanaのメニュー「Discover」をクリックし、
左上に表示されているindexパターンの「▼」を押して「useragent-*」を指定します。
するとまあなんということでしょう。
ログデータが表示されますね。
f:id:mamepika:20170304152937p:plain

円グラフ(Pie chart)の作成

さて遂に本題の可視化です。
今回はどんなOSが使われているのか、
そしてそのOSからどのようなブラウザを使用していて、
ブラウザのバージョンはいくつなのかといったことを可視化していきたいと思います。

Visualizeの作成

Kibanaメニューの「Visualize」をクリックし、
表示された中から「Pie chart」をクリックします。
f:id:mamepika:20170304154116p:plain

index選択で今回追加した「useragent-*」を選択します。
f:id:mamepika:20170304154226p:plain

OSの分布を可視化する

Split Slices選択して以下のように入力します。

Aggregation : Terms
Field : ua.os.keyword
Order By : metric:Count

f:id:mamepika:20170304160909p:plain

こんな感じにOS毎の円グラフが作成されます！
f:id:mamepika:20170304160837p:plain

円グラフの分割しブラウザの使用状況を可視化する

OS分布を可視化したら次はOS毎の使用ブラウザを可視化します！

「Add Sub buckets」から再度「Split Slices」を選択し以下のように入力します。

Aggregation : Terms
Field : ua.name.keyword
Order By : metric:Count

f:id:mamepika:20170304161220p:plain

Windows10でChrome使ってる人、IE使ってる人などが可視化されました！！
f:id:mamepika:20170304161205p:plain

ブラウザのバージョンを可視化する

最後にブラウザのバージョンを可視化しましょう。
サポート外のブラウザ使ってアクセスしてる人、
サポート外したいのに、まだ使ってる人が多いブラウザなどが可視化出来ますね。

「Add Sub buckets」から再度「Split Slices」を選択し以下のように入力します。

Aggregation : Terms
Field : ua.major.keyword
Order By : metric:Count

f:id:mamepika:20170304161506p:plain

まだIE8を使ってる人がいる、ということを可視化出来ました！

作ったグラフは画面右上の「Save」ボタンから保存することができます。

2017-02-26

Logstashで一部がkey value形式のログをパースする #elasticsearch

Elastic Stack

Logstashで取り込むログは多種多様で、色々なテンプレートも用意されています。

ただ、アプリケーションログはそれぞれのアプリで独自のフォーマットで記述されていることが多いと思います。

f:id:mamepika:20170226223831p:plain

今回、ちょっと複雑なログの形式として
項目が":"区切りで且つKey=Value形式の項目があるログをパース出来たので、方法を残しておきます。

ログはこんな形式です。

2017-02-26_11-46-00.123:hostap1:bwegaa3JkLKJIHGKGGIkjahawlwk2134:10000123:OUT:OAUT45    :OperateId=1Update&0&ProcessId=2kdajgkagkdjgjgkgjgkb&ProcessPass=214resdkljg6ykdhjglkgshg&SalesDate=20170226&TenantId=0001&TransactionDate=20170226&ResponseCd=OK
2017-02-26_12-46-00.123:hostap1:bwegaa3JkLKJIHGKGGIkjahawlwk2134:10000123:OUT:OAUT45    :OperateId=1Update&0&ProcessId=2kdajgkagkdjgjgkgjgkb&ProcessPass=214resdkljg6ykdhjglkgshg&SalesDate=20170226&TenantId=0001&TransactionDate=20170226&ResponseCd=NG
2017-02-26_12-45-00.123:hostap1:bwegaakJkLKJIHGKGGIkjahawlwk2134:10000123:IN :OAUT45    :OperateId=1Create&0&ProcessId=d5aaa2jgkjgghhhglalkg&ProcessPass=234resdkljg6ykdhjglkgshg&SalesDate=20170226&TenantId=0001&TransactionDate=20170226
2017-02-26_12-46-00.123:hostap1:bwegaa3JkLKJIHGKGGIkjahawlwk2134:10000123:OUT:OAUT45    :OperateId=1Update&0&ProcessId=2kdajgkagkdjgjgkgjgkb&ProcessPass=214resdkljg6ykdhjglkgshg&SalesDate=20170226&TenantId=0001&TransactionDate=20170226&ResponseCd=NG

処理日付、サーバ名、セッションIDが":"区切りで、最後の項目にPOSTされた内容がKey=Value形式で記述されています。

Logstashの設定ファイルは以下のような感じで記述しました。

input{
    file{
      path => "C:\dev\inout.txt"
      start_position => "beginning"
    }
}
filter{
     csv{
       columns => ["processingDate","hostName","sessionId","merchantId","inout","functionId","telegram"]
       separator => ":"
     }
     date{
      match => ["processingDate" , "yyyy-MM-dd_HH-mm-ss.SSS"]
     }
     kv{
       source => "telegram"
       field_split => "&?"
     }
     mutate{
       remove_field => ["telegram","@version","host"]
     }
}
output{
    elasticsearch{
       hosts => ["<Elasticsearchが動作しているサーバのIPアドレス>"]
       index => "inout-%{+YYYYMMdd}"
    }
}

filter-kv

ここが今回のキモです。
csvフィルターで":"に項目分けをされた項目を
sourceで指定し、field_splitで"&?”を指定することでKey=Valueをそれぞれの項目として抽出できます。
(dateフィルターで、同じようなことをしているので、もしかしたら出来るかなとやってみたら見事出来ました。)

Elasticsearchに投入しKibanaで見てみます。

f:id:mamepika:20170226224617p:plain

項目数に差異があっても同じインデックスに格納されていますね。
便利！
f:id:mamepika:20170226225045p:plain

f:id:mamepika:20170226225058p:plain

検索もきちんと出来ます。

f:id:mamepika:20170226225408p:plain

2017-02-26

WindowsでLogstashを使ってElasticsearchに既存のログを投入する #elasticsearch

Elasticsearch、Kibanaの環境を構築したら、
次はログを流し込んで可視化したくなるのが人情ですよね。

ということで出番なのがLogstash。

以下のURLからダウンロードできます。

www.elastic.co

通常の使い方はLogstashを各種サーバにインストールし、
リアルタイムでログを転送し可視化するのですが、
まずは手始めとして、手元にあるログをElasticsearchに転送してみようと思います。

動作させている環境は以下の通りです。

OS:Windows 10 Pro
Java: Oracle JDK 8u121
Logstash:5.2.1

Elasticsarch,Kibanaは以下の記事で作成したものを使っています。
mamelog.hatenablog.jp

Logstashとは

公式ページには以下の記述があります。

https://www.elastic.co/jp/products/logstash

Logstashは、オープンソースのサーバーサイドデータ処理パイプラインで、

膨大な数のソースから同時にデータを取り込み、

変換して、指定された任意の「格納庫（スタッシュ）」（私たちの場合は当然、Elasticsearchです）に送信します。

つまるところ、いろんな形式のデータを一か所に集約できる凄いツールってことですね。

使い方

ダウンロードしてきたzipファイルを適当な場所に解凍します。
(C:\dev配下に解凍しました。)

f:id:mamepika:20170226144205p:plain

テストデータを用意する

こんな感じの:区切りのデータを用意しました。

2017-02-26_00-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,351:0.901
2017-02-26_03-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,351:0.901
2017-02-26_06-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,351:10.901
2017-02-26_09-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,251:0.901
2017-02-26_12-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,51:0.901
2017-02-26_15-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:DELETE:0,551:0.901
2017-02-26_18-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:CREATE:0,351:0.901
2017-02-26_21-00-00.123:hostap1:B01hkafjaglggkgngaJHFJHGlgkghwgh:00000123:OCC001:UPDATE:0,311:0.901

設定ファイルを書く

Logstashは大きく分けて、
input,filter,outputの3つの処理に分かれます。

こんな感じで書いてみました。

input{
    file{
      path => "C:\dev\request.txt"
      start_position => "beginning"
    }
}

filter{
     csv{
       columns => [
         "processingDate",
         "hostName",
         "sessionId",
         "merchantId",
         "functionId",
         "operateId",
         "internalProcessingTime",
         "externalProcessingTime"]
       separator => ":"
     }
     date{
      match => ["processingDate" , "yyyy-MM-dd_HH-mm-ss.SSS"]
      timezone => "Asia/Tokyo"
     }
     mutate{
       convert => {
          internalProcessingTime => float
          externalProcessingTime => float
       }
       remove_field => ["telegram","@version","host"]
     }
}
output{
    elasticsearch{
       hosts => ["<elasticsearchが動作しているサーバのIPアドレス>"]
       index => "request-%{+YYYYMMdd}"
    }
}

input-file

pathに取り込みたいファイルのパスを書きます。
start_positionはファイルのどこから取り込み対象にするかを指定します。"beginning"を指定することでファイルの最初から取り込めます。
デフォルトではLogstash起動後に更新された行から取り込み対象にするようです。

filter-csv

CSV形式のファイルを取り込むときに使用します。csvと書いていますが、今回のようにseparatorに任意の文字を指定することで
カラム区切りでない文字列にも対応できます。
columusに区切ったそれぞれの値の項目名を指定します。

date

様々な書式の日付の文字列をパースします。

mutate-convert

指定しないと全て文字列になってしまうので、数値の項目は明示的に変換をかける必要があります。
floatやintegerが指定可能です。
数値にしておかないと、平均や合計、最大値最小値などの値を可視化出来なくなるので注意が必要です。

output-elasticsearch

Elasticsearchにデータを転送するのでelasticsearchを指定します。
hostsにIPアドレスを指定すればOKです。
indexはこの設定で投入されるデータのインデックス名です。
毎日違うインデックス名で投入するようにする設定になっています。

Logstashを起動する

コマンドプロンプトでLogstashをインストールしたフォルダ直下のbinフォルダに移動します。

cd C:\dev\logstash-5.2.1\bin

以下のように設定ファイルを指定して起動します

logstash -f request.conf

しばらくすればElasticsearchにデータが投入されKibanaで見ることができます。
f:id:mamepika:20170226143546p:plain
テストデータの通り、3時間おきの計8件のデータが投入されました。

インデックス名と@timestampの日付がずれる

時差、タイムゾーンの問題だと思うのですが、
設定ファイルでインデックス名をパラメータ指定していると、午前9時までのデータが前日のindex名で格納されてしまいます。
f:id:mamepika:20170226143859p:plain

indexを日付指定で削除するような運用をしていきたいのですが、
この状態だと日付をまたいでデータが削除されてしまうので困っています。

2017-02-21

第18回Elasticsearch勉強会に参加してきました #elasticsearch

Elastic Stack

www.meetup.com

新機能の紹介と色々な事例を聞けてとても為になりました。
開催ありがとうございました！

What's new Elastic Stack 5.2 Jun Ohtaniさん

トップバッターはElasticの大谷さん。

Elastic5.1,5.2の新機能とElastic日本法人の説明をしていただきました。
speakerdeck.com

Elasticsearch Serverという本を翻訳しましたが、買わないでください。(古すぎる)

トレーニングはマニュアルは英語だけどエンジニアは日本人で日本語で受けられるとのこと。
上司を説得しましょう。(僕は既にしました。)

Elastic日本チーム

・8人
・オフィス：大手町フィナンシャルシティグランキューブ
・株式会社なのでサポート契約も安心

タスクマネジメントAPI

検索のクエリをキャンセルできるように。

レンジ

数値のレンジを登録できるようになり、クエリでも直接指定できるようになった。
(スケジュールとか宿泊データとかで便利らしい)

keywordとtext

5.0から追加されたkeywordに対して、小文字寄せなどが簡単に。

集計結果のページング

アグリゲーションの集計結果TOP10件などを今まで取っていたが、全件ほしいというニーズがあるため対応。

Kibana

タグクラウド

頻出単語が大きくなったりするやつ。

ヒートマップ

アクロクエストの人が書いてるからそこをみて。
acro-engineer.hatenablog.com

地図のズームレベルが18まで

地図の詳細表示が可能に。
X-Packが必要

Logstash

パーシステントキュー

inputを受け取って、outputする前にLogstashが落ちた時などにもデータの漏れがないように。

input受け取ったら、いったんキューに格納し、outputし終わったらキューから削除。

Beats

Go言語で書かれた軽量シッパー。

CPU使用率、プロセス数など。
Dockerコンテナごとの数字も取れるように。

メタデータ付加

AWSのアベイラビリティゾーンなどを付加して投げてられるので、
障害個所の特定に役立つ。

JSON in JSON

JSONの中のJSON文字列もデコードできる。

Heartbeat

死活監視用Beats

x-pack

すべてが有料ではない。登録するだけで使えるものも。

モニタリング

Elasticsearchのモニタリングが可能。

Logstashのモニタリングも可能(5.2～)

pairsでのElasticsearch 小島広樹さん株式会社エウレカ

www.pairs.lv

ユーザ増えて検索負荷に耐え切れなく。(MySQL)

ユーザ検索などにElasticsearchを使用。

MySQLとElasticsearchのデータってどういう風に同期取ってるんだろと質問しようとしたら、
質問してくれた人がいて、同期バッチとかでやってるらしい。

資料が喪失してしまったらしく、中途半端な形で終わってしまったのは残念でした。

LT1 : タイトル：RettyのElasticsearchの使い方李晟圭(イ・ソンギュ)さん Retty株式会社

Retty：実名グルメサービス
retty.me

ログ解析
データ検索に使用しているの事。

ビジュアライズしていると説明しやすい。
エンジニアだけならログだけでもなんとかなっても、ディレクターなどにグラフを見せると話が早い。

LT2 : タイトル：Elasticsearch 5.2とJava Clientで戯れる森谷大輔さんヤフー株式会社

Elasticsearch 5.2とJava Clientで戯れる #elasticsearchjp from Yahoo!デベロッパーネットワーク