「JJUG CCC 2015 Spring」に行ってきた

Java カンファレンス Elasticsearch

Javaのユーザグループ主催のカンファレンス「JJUG CCC 2015 Spring」に参加してきました。 普段見れない他社さんの仕組みの話とか流行りの技術の話とか聞けて、個人的には大満足。

今年でJava15年目。何度も他の言語に乗り換えようとするんだけど、なんだかんだ硬くて素直なところはJavaの良さではあります。あと、積み上げてきたスタックの大きさというか厚みというか、やっぱり信頼おける。と、個人的には思ってます。

13:00- G-1 Java が支える人気ニュースアプリ NewsPicks の裏側　by 文字 拓郎さん（株式会社ユーザベース）

プレゼンメモ

  • NewsPicks

    • Platform/Publisher,Picker
    • gunocyとかSmartNewsとは違う層
    • 意思決定者層が多い、専門家が多い
    • 35万人くらい。有料課金ユーザも増えてる。
    • エンジニアの数は10人くらい
    • プッシュはあえて手動でやっていたりする
    • チーム（プラットフォーム、ブランドデザイン、編集部）

  • NewsPicks裏側

    • Desktop Mobile EC2
    • AWS or Die みたいな感じ
    • DATABASE
      • RDS(MySQL),マスタ
      • Dynamo DB,トランザクション
      • ElasticCache , タイムライン、ランキング、キャッシュ
      • Redshift：Access Log解析
      • ElasticSearch を検索で使ってる
    • JAVA アプリサーバ、バッチサーバ、取り込みサーバ
    • リコメンド、ダッシュボード、CMS、管理とかもぜんぶJava

  • APP Server内側

    • Nginx,Tomcat,fluentd
    • Java8 Sprng MVC
    • REST API (Java8 + LOMBOK + Spring)
    • JSONの定義はLOMBOK使うと楽。
    • SPRING はやっぱりしんどくて実はなくしたい。(コードをどこみればいいのかわからない）
    • JAX-RS + Guice/Daggerがおすすめ

  • SQS

    • 可用性が担保された分散キュー。
    • トランザクショナルではない。

  • ElasticSearch

  • Backend

    • CRONでスケジュール
    • 取り込んだ記事がタイムラインに反映されるまで
      • DynamoDBに一旦取り込む
      • カテゴライズサービスでカテゴライズする
      • ユーザのタイムラインに向けて波及させる
      • 間にはキューを挟む

  • 他の言語

    • 他の言語も考えたけど、なんだかんだJavaがシンプル
    • ruby はやっぱりそこそこの規模だとつらい
    • scalaもコンパイルが遅くてつらい

  • Redis編

    • Redisのマスタースレイブ。たまにこけてタイムラインがなくなる。
    • ユーザ数１０万人くらいで垂直分割
    • selectする層を用意して使う
    • 人気ユーザが寄っているので、実はユーザで分散しちゃダメ。
    • 結局、ハッシュ分散
    • Read/Writeをわけて読み出しはReadレプリカ

  • SEO編

    • Angular で開発されたSPA。
    • Phantom でスナップショット

  • 急成長の代償

    • 後方互換性を維持したままひたすら拡張
    • レイヤリングがほどんどされていない
    • スタートアップ

  • グロース編

    • REDSHIFT トラッキングログを整備、KPIダッシュボード
    • SPRING BOOT , DOMA2 ,ANGULAR JS ,D3 一週間くらい
    • SQL20 がシンプル

  • Angularやめる

    • SEO
    • polyfill service ユーザエージェントでいろいろ
    • THYMELEAF
    • handlebars とか使うと便利かも

所感

  • 知らないライブラリが出てきたのと実際に動いているサービスの裏側のアーキの話をしていただけるのは大変貴重で、かなり勉強になった。
  • みんなreact使ってみたいんだな、と。

プレゼンスライド

https://speakerdeck.com/monzou/java-gazhi-eru-ren-qi-niyusuapuri-newspicks-falseli-ce

14:00- Web開発における最新テスト手法　by tokuhiromさん (subtech)

プレゼンメモ

  • 導入
  • サーバサイドの開発はテストコードを書く
  • どこまで自動化するが
    • 手動でやったほうが楽なものは手動で
    • 繰り返すものは自動で
  • テストコード「契約」となるので堅牢なものになる
  • ビジネスロジックはモデルに入るのでモデルをテストする
  • RDBまわり
    • RDBが絡むテストをどこまでやるか
    • RDBとどう付き合うか
      • RDB独自の機能を使いたい派　
      • JPAを使いたい派
    • mysqlをmavenから起動する？制御が大変なのでlocalに立てる。
    • junitでいきなりcreate databaseするのが楽。beforeClassで。スキーマを流しこむ。
  • 外部APIのテスト
    • embedded jetty を使う
    • apimock
  • コントローラのテスト
    • httpclientから叩く　＊結合テストのような感じか。
    • JSON APIは、
    • フォームのテストはテストコードにしてない。人力で結構見つかるので。
    • HTMLは変わりまくるので自動化テストの手間が見合わない。
  • ダミーデータ
  • テストライブラリ
    • asertj を使うとIDEフレンドリー
    • google truth もあるけどassertj と似てるけど足りない。

所感

  • なるべく動作環境に近い環境でテストしましょう、っていうのは同感。なのでjetty立ち上げTDDは試してみてもいいかも。
  • ただ、結局、何を確認したいかによるよねと。間違いようのないhttpアクセスのコードだったらモックでもいいじゃん、という気もする。というかそうしてる。

プレゼンスライド

  • 見つからなかったです。

15:00- 大規模な負荷でもドキドキしない為のJava EE　by nagaseyasuhitoさん （java-ja / グリー株式会社）

プレゼンメモ

  • 負荷テスト
    • アンチパターン
      • シングルスレッドで実行　→　実践的ではない
      • ユースケーストかけ離れたシナリオ
      • 複数のサーバでコマンドを叩いて手動実行
    • 負荷テストの目的
      • システムの限界性能を知る　
      • 高負荷時の不具合を発見する
    • Stress Test meets Continuous Integration
    • JMeter
      • HTTP Test Script Recorder (プロキシとしてトレースしてくれる）
      • Selenium Web Driver Sampler
      • JUnit Requestサンプラ　junitを実行できる
    • jmeter-maven-pluginで自動化
    • 負荷テストのパラメタはMavenのプロパティ化してチューニングするとよい。
    • jenkins performance plugin jmeterの結果を出力するプラグイン
    • 負荷をかけるとどうなるか
      • 他ユーザのレスポンすが返ってくる
      • レスポンセウが返ってこない
      • リソースは余ってるのにレスポンスが遅い
      • リクエストが遅い
      • レスポンスが遅い
    • ボトルネックを探す
    • Mission Control ,Flichg REcorderで取得したJVMの統計情報を可視化するツール
      • 以下のオプションをつけてアプリサーバを起動する -XX;LUnlockCommercialFeatures -XX:+FlightRecorder
  • JPAのスケールアウト戦略
    • enterprise とsocialの違いで戦略が違う
    • READ が頭打ち
      • Master-Slaveのレプリケーション
      • readの負荷状況によって２台、３台に増やす
      • Mysql ReplicationDriver
      • entityManager.unwrap(Connection.class).setReadOnly(true); なんかちょっと残念。
    • WRITEも頭打ち
      • パーティショニング。一定のルールに従ってクエリ発行するデータベースを振り分ける。
      • EclipseLink Partitioning
        • アノテーションを書くことで書き込み先のデータベースコネクションを切り替えられる。

所感

  • 意外とjmeterで地味に負荷かけてるんだな、っていうところが驚き。
  • CIにどこまでのシナリオを組み込むかは課題なのかな。uiが変わったら作り直しだし、毎回チューニングするわけにもいかないだろうし。
  • エンタープライズの人だからか、やっぱり、負荷テストやってから「限界を知る」っていうのには違和感がある。いやまあ、実際そういう面もあるんだろうけど、出来高でやってていいのかなあ、っと。

プレゼンスライド

16:00 『Embulk』に見るモダンJavaの実践的テクニック ～並列分散処理システムの実装手法～

by なひ さん（トレジャーデータ株式会社）

プレゼンメモ

  • Embulk
    • オープンソースのバルク転送ツール
      • A から B へレコード群を転送
    • プラグイン機構
    • バルク転送の難しさ
      • 入力データの正規化、エラー処理、メンテ、性能
      • 入力データ
      • エラー処理の扱い
        • 例外的な値が入ってきたときにどうするか。
        • ネットワークエラー、ディスクフル、重複データ転送の回避復旧。
      • メンテナンスの難しさ
      • 転送データ
        • 通常は増えていく
    • Embulkデモ
      • csvを入力するとカラムを推測してくれる
    • プラグイン
      • InputPlugin
      • FilterPlugin
      • OutputPlugin
      • Executorplugin
  • Java実装技術
    • Java7ネイティブ
      • try-with-resources
      • ファイル操作はFiles & Paths API
    • Guice
    • Jacksonによるモデルクラス
    • Immutableな変数はfinalにしておく
    • Nettyバッファアロケータ
      • レコード群のためのメモリをすべて自前管理
      • out of memory が起きる前に検出
      • GCコスト削減
      • 複数のバルクロードセッションをサーバプロセス内で実行しても大丈夫
    • Unsafe
      • airlift/slice - sun.misc.Unsafe API のラッパー
      • バイト列の直接操作（で・シリアライズ）
      • コピー削減

所感

  • やっぱりEmbulk便利そう
  • 噂には聞いているけどUnsafe API。名前からして触ってはいけないもの感が漂ってるんだよなあ。いつか触ってみよう。

プレゼンスライド

17:00- Grails 第3章 進化したSpring-bootベースフレームワーク

by 山本 剛さん（日本Grails/Groovyユーザーグループ, newcast inc.）

プレゼンメモ

  • Grails
  • Road to 3
    • Grails1系：古代
    • grails2.3系まで：近代
    • Spring Bootをベースにする
    • grails2.4 はspring4
  • Grails 3
    • Groovy 2.4
    • Spring 4.1
    • Spring Boot 1.2
    • Gradle
      • JavaやっててGradleやってないのはおかしい
    • なぜspring boot？
    • ＊spring bootが簡単そう
    • コアフィーチャ
      • Groovy2.4 で速くなった
      • 内部フローの変更
    • 開発環境フィーチャ
      • Intellij IDEAのgradleプロジェクトで開発
    • テストフィーチャ
  • まとめ
    • spring boot
    • 3.0はまだ不安定かも。3.1に期待。

所感

  • うーむ、grails3もちょっと厳しそうだな。

プレゼンスライド

18:00 いろんなデータをKibana4で見てみよう by 大谷 純 さん (elastic.co)

プレゼンメモ

  • elastic
    • elasticsearch から elasticへ変更。
  • ELK Stack
    • DataをLogstash に食わせて、elasticsearchにためて、データをkibanaで見る。
    • Logstash
      • 概要
        • ログデータの収集・管理
        • 収集、パース・加工、送出
        • jruby
      • アーキ
        • input Filter output
      • 設定ファイルでinput,filter,outputを指定する
    • Elasticsearch
      • キーワードの検索、絞り込み、ハイライト、ページング、集計、サジェスト
      • githubで使ってる
      • スキーマフリー、分散ドキュメントストア、REST & JSON
    • Kibana4
      • データを探索しやすく、elsticsearchの新機能を活用できる
      • 3つの画面
        • Discover
          • どんなフィールドがあるか
          • 検索した結果はどんなデータか
          • 検索条件の保存
        • Visualize
          • 検索結果をもとにグラフを作成
          • グラフのタイプを選択
          • 検索対象のデータを選ぶ
          • 集計単位を選択
          • グラフを表示させたら保存する。elasticsearchにjson形式で保存される。
        • Dashboard
          • 保存したグラフを貼り付けていく
      • kibana3との違い
        • 基本的に一枚だけだった。異なるデータを一緒の画面に出せなかった。
        • 異なるフィールドのデータを一緒にグラフに出すことができなかった。
  • ユースケース：アクセスログ
    • logstash
      • input:Accessログのパスを指定
      • filter:grok でパース。apacheのログの場合は構造化してくれるものが用意されている。
      • filter:geoipで緯度経度情報をとってきてくれる。
      • filter:useragent でよしなに抜き出してくれる
      • ouptut:elasticsearchにしてindexの名前を日毎に設定。
    • elasticsearch
      • Index template。
    • kibana
  • ユースケース：ツイート
  • ユースケース：git log
    • gitのヒストリを取り出してelasticsearchに投げる
  • ユースケース：javaのログ
    • multilineを使うとstacktraceとかの複数行も取れる
  • elasticsearch勉強会やってる

所感

  • kibana4になってますますsplunkっぽくなったなあ
  • raspberry pi2 に入れてみよっと

プレゼンスライド

  • 見つからなかったです。