JSUGイベントSpringOne Platform 2018報告会メモ

SpringOne Platform 2018報告会

SpringOne Platform全体所感

• NTT 岩塚卓弥さん、NTTデータ 岩本純佳さん
• 前身カンファレンス（Groovyとかといっしょの時代とか）からくらべて10年目
• スポーサーとして日本からはNTTDataと富士通
• セッション１５０個のうち、一番多かったのはケーススタディ
• Springのセッションがそこまで多くなかったのは前年にSpring5のメジャーバージョンアップがあったから
• JDK11使う人はSpring5.1を使う
• 5.2は6月リリース予定
• 5.1は去年発表のリリース予定から数ヶ月遅くなったので、5.2も遅くなる可能性あり
• 関数型スタイルVSアノテーションスタイル
  • これからも両建て
  • 関数型スタイルも選択できる
    • パッケージスキャン不要
    • KotrinDSLで簡潔にかける
• フレームワーク内のリフレクション使用の最適化
  • Spring5.1(Boot2.1)にするだけでヒープサイズ、起動時間が少なく短く起動できる
  • 関数型Bean定義で明示的に定義するとさらに早く起動できる
• GraalVMによるnative imageへのコンパイル
  • GraalVMとはOracleがOSS公開している多言語対応VM
• Spring5.2
  • JDK12のサポート
  • GraalVMへの完全対応
  • Kotorin1.3の完全サポート
  • HibernateORMの5.3
• DBS銀行の事例
  • 外注と内製の割合を逆転（8:2)
  • 技術の社内展開：技術者とのペアでの活動
  • 新規人材採用
    • 採用プロセスにオンライン技術テストやハッカソンを取り入れた（hack2hire)
• https://codezine.jp/article/detail/11180

Spring Cloud Stream および2.1での新機能

• Jia Xiaozhouさん
• メッセージドリブンマイクロサービスのためのフレームワーク
• Spring Integration + Spring Boot => Spring Cloud Stream
• コンセプトはBinderレイヤを設けることによってアプリとミドルを疎結合（RabbitMQやKafkaなどをアプリからメッセージキューの種類を意識せずに使える）
• 2.1ではSpring Cloud Functionとの連携
• FunctionをBean登録、プロパティ指定するとイベント契機で呼べる
• Function Compositoin：アプリに閉じたワークフローの定義ができる
  • Spring Cloud Data Flowとの連携も現地で話されていた
• Source -> メッセージの源
• Sink -> メッセージが流される場所（受け取る側）
• Processor -> Source兼Sink
• Functionの引数でメッセージを受けとって、戻り値がメッセージ送信になる
• ActuatorエンドポイントからBinderを停止したり出来る

High Performance Batch Processing

• アスクル 寺山さん
• Spring Batchの情報が古いので参加
• 半年前からBatch使っている
• SpringBatchはStepという概念で管理
• stepの途中で失敗したら失敗したところからリラン可能
• stepはtasklet（読み込み、加工、書き込みに別れる）とchunk（それ以外）にわかれる

Reactor NettyネタとKafkaネタ

• Yahoo! JAPAN 水落さん
• PCFを利用
• reactor-netty最新は0.8
• Nettyネットワークプログラミング向けのフレームワーク（HTTP以外のTCPやUDPも選べる）
• 高スループット、複雑な非同期処理が求められるミドルウェア等の実装に向いている
• non-bloking IO
• WebFluxのデフォルトバックエンド
• Springからみるとメタフレームワークと言える
• Reactor NettyはReactor利用時のネットワーク通信全般に用いる
• イベントループ前提
• wiretapメソッドを入れておくと通信ダンプがログに出る
• KafkaはStreaming Platform
  • Producer/Consumer
    • Kafkaにデータを送受信する基本的な機能
    • Producer/Consumer　APIにより実装する
  • Connectors
    • Kafkaとデータ連携するアプリケーション
    • データソース、シンクごとに実装が公開されている（MySQL,Elasticserch)
  • Sreaming Engine
    • トピック間同士でリアルタイムにデータを変換、統合するようなアプリケーション
    • Streams APIにより実装する
    • 後述のKafka Streamsライブラリより手軽実装できる
• KafkaStrems
  • Kafkaを用いたストリーミング処理を書くためのライブラリ
• Spring for Apache Kafka
  • KafkaTemplete
  • ＠KafkaListener

R2DBCネタとRSocketネタ

• Pivotal 槙俊明さん
• SpringOne 2018 Ben Haleで検索して出てくる動画を参照
• リアクティブプログラミング
  • ハイスループット
  • 効率的
• Springの人たちが言うにはback pressureが大事
  • Reactive Streamのrequest(n)が大事
  • Subsctiverがボリュームかわりに流れてくるデータ量を調整できる（back pressure)
• WebClientはリアクティブでなくても使えるので、おすすめ。シンプルに書ける
• JDBCがノンブロッキングなので、別のものをAPIを作ったもの
• OracleのADBAによい影響を与えたいという思いでSpringチームが開発している
• Driver SPI（サービスプロバイダインターフェース）
• JDBCっぽくかけるが、MonoやFluxで戻り値をもらえる
• トランザクショナルなインサートも実現。スレッドローカルは使わない（JDBCだとつかっている）
• SPIではなく、r2dbc-clientでハイレベルなAPIが提供されている。テンプレートパターン的な。
• spring-data-r2dbcというとなりの存在のプロジェウトも。リポジトリインターフェースの作成だけで実現できる。リポジトリパターン。
• WebFluxを使えばReactiveになるわけではない。書き方に注意。currectAllとかすると待ってしまうので、リアクティブではない
• リアクティブアプリケーション間のback pressureを制御できあかった課題に対してのプロトコルがRsocket。L7のプロトコル（HTTPと同じレイヤ）
• NetflixでrScoketを使っていた人がFacebookにいって活用していた人がキーノートに
• Netflixでは今はあまりrSocketを使わずにgRPCを使っている
• プロトコル定義なので、プログラム言語非依存（今はJS、Java、Kotlin、C++)
• TCP直接使えないようなプラウザ上ではWebSocketを使ってその上でRSocketを使う。プロトコルなので下は意識しない。
• マイクロサービス的な構成になった場合にRsocketを使うとback pressureを伝播できる。Istioと競合？
• battle-flux-ui.apps.pcfone.io
• Rsocketでクライアントからback pressureを設定できるデモ