Spring Fest 2018に参加しました #jsug
2018年10月31日に行われた、
Spring Fest2018に参加してきました。
springfest2018.springframework.jp
次のシステムはSpring Bootを使って構築しようとしているので、
Springの動向、事例収集が目的です。
結論としては、かなり聞きたい情報が聞けた、満足度100%のイベントでした。
聴講したセッションは以下の通り
KEYNOTE
Springエコシステムの今とこれから。
個人的にはKotlin推しが気になってます。
Kotlin + Spring Bootでこれから勉強していこうと思いました。
英語のセッションで同時通訳レシーバーを使っている人が多かったのですが、
音漏れが酷く、セッションに集中できない状態でしたが、
運営の多田さんが、途中でアナウンスしてくれてみんなが音量を下げてくれてからは、集中して聴くことが出来ました。
私は英語力向上のため、レシーバーなしで聴講しているので非常に助かりました。
まあ、半分くらいしか分かってませんがw
決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発
www.slideshare.net
Elastic{on}のときも参考にさせていただきましたが、
同業他社の事例紹介。
PCFとSpringの決済システムの構築事例は大変ためになりました。
この事例との差異は、言語がKotlinになるところと、
カード会社との独自接続網をどのようにマイクロサービス内に組み込むか、といったところでしょうか。
既存システムの残し方、
ある決済機関で遅延や障害が起きた時の、障害の伝搬など課題認識が同じで先行事例として非常に助かりました。
Spring ♥ GCP ー Spring と GCPの素敵な関係(アプリ実行環境としてのGCPを考える)
昼休み明けてこちらに。
現状のクラウドインフラはAWSを使っていますが、
実はGCPのほうが相性が良いのではと思い、聞いてみました。
GAE、GKEのデモは見飽きたものであまり、新鮮な内容はなかったかなといった印象でした。
来年には大阪リージョンも開設されるので、
そのあたりから国内事例にも期待していけるでしょう。
あわよくば私が最初の事例になりたいものです。
Amazon Cognito使って認証したい?それならSpring Security使いましょう!
JJUGでお世話になっている、リョーちゃんのセッションへ。
Cognitoとタイトルに合ったものの、中身はSpring Securityの深い話でした。
日頃、フレームワークのソースやクラス名なんて意識しないので、いい機会でした。
資料に使われているアイコンが可愛い。
以下のURLで手に入れられるようです。
SimpleDiagrams | Desktop App for Creating Diagrams, Flowcharts and Hand-drawn Visualizations | SimpleDiagrams
次はCognitoを組み込んだ実例が聞けると期待しています。
Pivotal認定講師が解説!基礎からのOAuth 2.0とSpring Security 5.1による実装
www.slideshare.net
システム開発にあたって、必ず作る必要があるのが認証・認可。
それなのに情報は少ないですし、実装方法も複雑なので気になってました。
OAuth2でオペレーションは楽になるのですが、実装はまだまだ一筋縄ではいかないなといった印象です。
Spring BootでHello Worldのその先へ ~ウェブDBプレスのSpringBoot特集で伝えたかったこと&伝えきれなかったこと~
会場の111が分からず、スタッフの方に聞いてしまいました。
他の3つの会場は2階と3階なのですが、111は11階でした。
WEB +DB PRESSのSpring Boot特集の続編的位置づけのセッションでした。
Hello worldで終わらず、メッセージキューやデータベースのつなぎ方を見せていただき、楽しいセッションでした。
業務で使いたいWebFluxによるReactiveプログラミング
最後はこちら。
speakerdeck.com
最後のセッションなのに広い会場がだいたい埋まっていました。
凄いです。
リアクティブ、よくわからないですが、これから来そうな気配は感じました。
Intellij IDEAがフリーズしてデモが出来ない事象が発生していましたが、
うまく笑いにつなぎ、デモもきちんと行えてたのでさすがだなと…。
BABTMETAL 3人の時は一生心に残しておきます。
懇親会
美味しい料理と、ワインを堪能しました。
沢山お話もできたので、有意義でした。
もう少し、知らない人やセッションのスピーカーへ話に行く勇気を持たないと駄目ですね。
運営の皆さん、スピーカーのみなさん、ありがとうございました!
平成30年度 秋期 システムアーキテクト試験を受験しました
2018年10月21日にシステムアーキテクト試験を受験してきました。
問題はこちら。
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2018h30.html#30aki
情報処理技術者試験歴
2009年10月 基本情報技術者試験合格
2010年10月 応用情報技術者試験合格
2011年06月 情報セキュリティスペシャリスト試験合格
2017年10月 情報処理安全確保支援士登録
情報セキュリティスペシャリスト試験合格後は、
高度試験を色々受けてたり、受けてなかったり(午前0試験で敗北)で合格からは遠ざかってます。
ここ2年は春はデータベーススペシャリスト試験、秋はシステムアーキテクト試験に絞って受験しています。
午前1は免除なので、会場には10時くらいに到着。
自分の受験教室を確認して、10時30分くらいまでリラックスしてから臨みました。
午前Ⅱ試験
16/25(自己採点)
過去問からの出題が少なく焦りました。
直前で結構答えを書き換えたところが間違ってて冷や汗もの。
当日、IPAから発表された解答で自己採点したところ、16/25だったので
解答の写し間違いやマークミスがなければ、たぶんクリアできているはず。
午後Ⅰ試験
問1と問3を選択。
それぞれ可もなく不可もなくといったところ。
TACの解答が発表されたので見比べてみると、
各問に概ね応えられてるかなーと甘めの自己採点。
http://www.tac-school.co.jp/kaitousokuhou/downloads/14_30F_SA%E8%A7%A3%E7%AD%94%E4%BE%8B.pdf
午後Ⅱ試験
問1を選択。
こちらはデータ分析とデータの提供がテーマだったので、
業務で行っているElasticsearchのログ可視化をアレンジして記述しました。
規定文字数はクリアしたので、あとは祈るのみ。
結果は12月に発表なので、それまでドキドキですね。
結果報告がなければ、お察しください。
全体の感想
午前2は過去問からの出題がなく、方向転換が伺えました。
アジャイルの用語だけ知ってても別に意味はないんですが、
午前でアジャイルについて問われることが増えてますね。
試験制度変わって9年ですが、ここらでもう一度変えるべきなのかもしれません。
午後はシステムアーキテクトとITストラテジストの違いが曖昧になっているように思います。
Developers Summit 2018 Summerに参加しました #devsumi
7月27日に行われた、Developers Summit 2018 Summerに参加しました。
テーマはデータ活用ということで、
機械学習、AI、ビッグデータなどですね。
資料は以下のページに纏められています。
codezine.jp
データ活用の事例というより
データを活用していくために
どういう組織が必要か、そのために今の組織をどう変えるかなど泥臭い内容も聞けたので満足です。
JJUG CCC 2018 Spring に運営とスピーカーとして参加しました #jjug
大分時間が経過してしまいましたが、
2018年5月26日に行われた『JJUG CCC 2018 Spring』に運営として、そしてスピーカとして参加しました。
スピーカとして
大きな舞台での登壇は2回目でした。
まあ、朝イチ且つテーマが技術寄りでもないので、あまり人は集まりませんでしたが、
聞きにくれた方はありがとうございます!
資料は以下のとおりです。
www.slideshare.net
情報処理安全確保支援士に登録して、講習も受けてきたのでレポートとして発表しました。
今の所、登録しててもなにか変わるわけでもないですが、
情報セキュリティの重要性は今後増す一方だと思いますので、
そこで情報処理安全確保支援士がニーズに対して応えられる知識・技術を持っているようにせねばと思います。
秋は、技術よりの話題で登壇してみたいなあ。
運営として
一方通行は今回も実施し概ね好評でした。
ただ、厳格にやりすぎてしまい、セッション中の通路が閑散としているときにも一方通行によって不便を強いられる事があったようです。
ここは次回改善点です。
懇親会
寿司!
LINEさんありがとう!寿司!
LogstashのJdbc_streaming filterを使ってDBから取得した項目をログに付加する
この記事は、Elastic Stack Advent Calendar 22日目の記事となります。
皆さん、ログ可視化してますか?
ログにIDしか出力されておらず、名前がほしいなと思ったことはありませんか?
僕は、常々名前がほしいなと思ってました。
ログ出力処理をいじって、ログに出力されるようにするのが一番なのですが、
該当のシステムは外部ベンダーが作っており、なかなか難しかったりします。
そこで色々手段を検討していたのですが、
Logstash自身に、ログの一部をキーにDB検索をし結果をログに付与する機能があるのを見つけました。
それがJdbc_streaming filterです。
www.elastic.co
inputをJDBCで出来るのは知っていたけど、filter処理もできるとは知りませんでした。
下準備
DBと読み込む対象のCSVファイルを準備します。
JDBC Driverのダウンロード
使っているRDBMSに即したJDBC Driverが必要になります。
今回はPostgreSQLを使用するので、PostgreSQLのJDBC Driverをダウンロードしてきます。
対象のテーブル
テーブルはこんな感じにデータを入れています。
読み込む対象のCSVファイル
読み込むCSVファイルは以下のような感じです。
2017/12/22 00-00-00.000,hostap1,_07obfLIAdLHyL5VjcTWs8Zu_2xsN-QQ,1,Login 2017/12/22 00-00-00.000,hostap1,_07obfLIAdLHyL5VjcTWs8Zu_2xsN-QQ,2,Login 2017/12/22 00-00-00.000,hostap1,_07obfLIAdLHyL5VjcTWs8Zu_2xsN-QQ,3,Login 2017/12/22 00-00-00.000,hostap1,_07obfLIAdLHyL5VjcTWs8Zu_2xsN-QQ,4,Login 2017/12/22 00-00-00.000,hostap1,_07obfLIAdLHyL5VjcTWs8Zu_2xsN-QQ,5,Login 2017/12/22 00-00-00.000,hostap1,_07obfLIAdLHyL5VjcTWs8Zu_2xsN-QQ,1,Logout
Logstashの準備
設定ファイルを以下のように作成します。
上記の公式ページのjdbc_connection_string には "が2つ記述されていますが、
2つ書いたままだと動かなかったので、1つにしています。
JDBCの設定自体は普段Javaを書いている人には馴染みのあるものかと思います。
input{ file{ path => "C:/dev/members.txt" start_position => "beginning" } } filter{ csv{ columns => ["processingDate","hostName","sessionId","memberid","function"] separator => "," } date{ match => ["processingDate" , "yyyy-MM-dd_HH-mm-ss.SSS"] } jdbc_streaming{ jdbc_driver_library => "C:/dev/postgresql-42.1.4.jar" jdbc_driver_class => "org.postgresql.Driver" jdbc_connection_string => "jdbc:postgresql://localhost:5432/postgres" jdbc_user => "postgres" jdbc_password => "password" statement => "select * from members WHERE memberid = :memberid" parameters => { "memberid" => "memberid"} target => "member_details" } mutate{ remove_field => ["@version","host"] } } output{ stdout {codec => rubydebug} }
このファイルは、Logstashフォルダ配下のbinフォルダに保存します。
Logstashの実行
コマンドプロンプトから実行します。
Logstashフォルダ配下のbinフォルダまで下ってから以下のコマンドで実行できます。
logstash -f <設定ファイル名>
結果の確認
以下のように、ログには書かれていなかった項目がDBから取得され、付与されていることが確認できます。
尚、結果が複数返ってくるSQLの場合は配列になって格納されるようです。
今回は*で全カラムを取得していますが、カラムを指定すれば、そのカラムだけ配列に入ります。
パフォーマンス
ローカルPC上で起動したLogstashから
RDS for PostgreSQLのt2.smallインスタンスに対して実行した際に、
秒間600~1000行程度のログを捌くことが出来ていたので、パフォーマンス的にはさほど問題にならないかなと思います。
Elastic Stackは進化のスピードが速く、どんどん痒いところにまで手が届いていく感じが好きです。
来年からはX-Packの機能も触っていけるので、blogに書く機会も増やしていきたいな~。
Elastic{on} Tour Tokyo 2017に参加しました #elasticon
2017年12月14日 10:00~18:00に虎ノ門ヒルズで開催された、
Elastic{on} Tour Tokyo 2017に参加しました。
今年から有料イベントになりましたが、参加費の11000円は会社に負担してもらいました。
Elastic Stackは現在社内でも絶賛稼働中で、今年中に有料サブスクリプションの契約をするので、
その下調べを兼ねてという体です。
コーヒーと紅茶、お菓子が用意されており、コーヒー3杯くらい頂きました!
クッキーも大変美味しかったです。
お弁当は今半の高級そうなやつでこれもまた美味。
基調講演
日本法人のカントリーマネージャーの方のお話。
日本チームは11人
取引先は100社を超えるとのこと。
今年中にうちも契約しますー!
CEOのShay Banonsさんからの講演ではこれからの予定など。
セキュリティアナリティクス
- SIEM
アプリケーションのログ可視化だけでなく、SIEMとしてもElastic Stack活用していきたいので、
ここの機能が強化されるのは嬉しい限りです。
Machine Learning
Elasticsearch: Past,Present,&Future
日本のエバンジェリスト大谷さんのプレゼン。
1系、2系を使ってる人?という質問にパラパラと手が挙がってました。
5や6を使ってほしいとのことですw
Elasticsearch 5.0
2016/10リリース
2から5へ。
全てのプロダクトのバージョン番号を統一
数値に関する改善
- metricbeatなどで数値データをElasticseachに送ることが増えた。
- 数値の計算を高速化、使用ヒープを削減
安全第一
- bootstrapチェック
起動時に設定値を確認し、設定が正しくない場合は起動ができない。
ヒープサイズの最小値、最大値が異なる場合など
- OOMを極力出さない
より簡単に
- Injest Node
Beatsから可視化するのが簡単に
Elasitcsearch 5.6
2017/9リリース
様々な改善
Elastic 6.0
悩みのタネ
- ディスクの使用量
空白が多いデータも配列で一括で保持していたが。データの持ち方が変わった
5.Xの60%程度に圧縮可能に。
allフィールドをデフォルトで向こうに
各種データ登録に効果的な設定
- 堅牢性やリカバリ
トランザクションログという一意な番号を保持し、そのログをもとに復旧させる。
- メジャーバージョンアップグレード
5.6.Xから6.latestへはローリングアップグレードが可能
Java high level REST Client
5.6でリリース
JavaのClientとElasticsearchのバージョンが違っても検索可能
CRUD&Searchをサポート
Elasticsearch6.1
2017/12/14 リリース
Index Splitting
Composite Aggregation
Adaptive Replica Selection
Scripted Similarities
Ingest and the Elastic Stack
Aaron Mildensteinさん。
Multiple Pipeline
設定を個別に記述できるように
ユースケース
ロギング
- システム、ウェブサービス、キュー
メトリクス
- インフラ、コンテナ、データベース
セキュリティ
- SecOps
Kibana Deep Dive
アラート
Setting -> Wathcer
アクセス制御
ユーザロール追加
kibana dashboard only user
Spaces
ユーザやグループで閲覧、操作制御できたが
インデックスパターン、ダッシュボード単位などで制御が可能に。
SAML認証
サードパーティの認証プロバイダとの連携でSSOを実現
Saved Object API
ダッシュボード、ヴィジュアライゼーションなどをAPI経由で保存可能
Kibanaはログ可視化のツールだけでなく、Elastic Stackの管理画面としての機能も提供していくイメージですね。
Machine Learning Deep Dive
Rules Don't Scale
- where do you set the thereshold
- who updates the Rules
- Flase positives are costly
・ダッシュボードから人の目で見て異常値を検知するのは難しい
・異常のしきい値もどの程度の値を設定すれば良いかを人が決めていくのは難しい
・常にデータは変化していくので一度きめたしきい値がずっと有効とは限らない
そこで機械学習を活用していく
2つの異常値を検知できる
これまでとは違う変化
他とは違う突出した変化
LINE infra Security Log Platform And Analysis
セキュリティ用途でのElastic Stackの活用事例
とにかくシステム規模が半端ない!
後半は英語だったので雰囲気しか掴めませんでしたw
40以上のログを30000以上のデータソース
一日1TB!
ログのロスト、Elasticsearchのフリーズ、Kibanaのパフォーマンスダウンなど問題が顕在化
システム名:Monolith
Fluentd->Logstash
kafka
有料オプションを契約。
コレクター4台
パーサー5台
Elasticsearch20台
Kibana3台
リモートデスクトップ接続
SSH接続
などの状況を可視化
ダッシュボードを見るのは人の目。人の目には限界がある。
分析・検知は自動化したい。
そこでMachine Learning
普段使われてないPC、普段使用していないユーザからのリモートデスクトップ接続を検知できる。
アラートの精度が上がった。
KibanaのWebhookでLINEに連携
LINEを使う理由は
1. 夜でも担当者に連絡ができる
2. 休日でも担当者に連絡ができる
ソフトバンク・ペイメント・サービス 決済サービスの監視を支えるElastic Stack
私的に本日メインの発表。
同じサービスを提供している会社の事例は貴重です。
誰にでも見やすいダッシュボード、障害検知の仕組み、
機械学習の検証から実践まで惜しみなく事例を紹介していただき、ありがとうございます。
オンライン決済サービスの監視
年間取扱高2兆1949億
トランザクション2億件
障害発生時に状況を素早く共有できていなかった。
システム部門-営業部門-加盟店
システムも営業も
「システムの状況をリアルタイムに把握したい」
Kibanaで「サービズ全体の状況をリアルタイムで可視化」
RDBに決済情報が格納されているので、
Logstash jdbc input pluginを1分間隔で実行しElasticsearchに投入
ダッシュボードを作り際に意識したこと
誰でも
どこでも
いつでも
決済手段ごと
OK・NGの比率
色を統一
職場のモニタに常時ダッシュボードを表示
KibanaのダッシュボードをSleniumとJnekinsでスクショ取ってSlackに通知
Machine Learning
毎月1日は与信枠開放の影響でトランザクションが増える。最初は検知していたが、4ヶ月目くらいから検知しなくなった。
対象加盟店のみで絞れば気づけるが、加盟店全体で見ると不正アクセスのNGが埋もれてしまう
障害時はほぼ検知
可視化しても人間では見つけられない埋没した情報も検知可能
気づき
母数の少ない決済手段の場合、1人のユーザが数回エラーを起こすだけで以上検知されてしまう
同じ周期で不正利用によるリクエストが来た場合、3周忌目くらいから学習され反応しなくなってしまう
Watcher JSONの設定が難しい つらい
ビジネスデータの可視化
ヒートマップで営業担当の目標達成率を可視化
VELTRA 問い合わせ業務の自動化
日・中・英の問い合わせメールを自動ラベリング
システム名はイーグル
コンサルタントの稼働を減らしてエンジニアの稼働が増えては意味が無いので、Elastic Cloudを採用。
Elastic Stackの進化は凄まじく、追随していくだけでも難しいですが、
コミュニティがどんどん広がって情報共有が進むと、この辺が楽になると思うので、今後の発展に期待しています。
僕も本番稼働させたら事例の共有などしたいと考えています。
JJUG CCC 2017 Fallに運営で参加してきた #jjug_ccc
2017年11月18日にJJUG CCC 2017 Fallが開催され運営側として参加してきました。
今回は主にカメラマンを担当しました!
混雑緩和
今回のイベントでは、上記のページにもある通り混雑緩和が一つのテーマでした。
その為、各セッションの部屋の入り口・出口を一つにし、
通路も一方通行にする施策を取ってみました。
結果としては、これがかなり功を奏し、身動きできないような混雑は起きず、
セッション間の移動もスムーズに行われていました!
協力してくれた参加者の皆さん、ありがとうございました!
アンケートでも一方通行は好評でした。
写真撮影
海外のイベントなどでは写真が多く撮られており、参加していない人にもイベントのイメージがつきやすいので
今回はボランティアの方と2人で写真撮影を行いました。
登壇者の皆さんには個別に連絡が行くかと思います。
ストロボ使用について
セッション中は前方にスライドが投影される関係上、部屋が暗くなっており撮影の為ストロボを使用しておりました。
ストロボが不快な方もいるので、なるべくカメラの設定などでストロボが不要なようにします。
JJUG CCCは2018年春にも開催予定です。
皆さん奮ってご参加ください。