SpringOne Tour 2018 に行ってきた #s1t

先日、SpringOne Tour 2018 に行ってきました。簡単に所感をまとめます。

Tokyo November 6 | SpringOne Tour

メモから抜粋。スライドが公開されたらリンクを貼っておきます。逐次通訳はあったのですが、理解が誤ってる箇所があるかもしれません...。

Spring Boot 2.0によるリアクティブSpring

www.slideshare.net

  • Reactive Programming
    • non-blocking, event-driven
    • 省スレッド
    • backpressure
  • Java は拡張されやすいように進歩してきたが、効率は効率はよくなかった
  • 新しいリクエスト/接続があるたびにスレッドを生成する必要がある
    • 各スレッドでIOを待つ必要があったり
  • イベントループによって少ないリソースで処理する
    • 非同期で処理する
    • ただの非同期ではなくリアクティブ
    • 非同期とリアクティブの違いは Backpressure
    • Backpressure がないと Subscriber の処理が追い付かない
    • Subscriber は Publisher に Backpressure して大量データを制御する
  • スケジューラによって比較的少ない数のスレッドで処理できる
  • リアクティブの目的はパフォーマンス向上より拡張性の向上
  • Reactive Streams: 4 interfaces ★
    • Publisher
    • Subscriber
    • Subscription
    • Processor<T,R>
    • ↑の仕様を実装したのが Project Reactor
    • Reactor が Java/Spring で使いやすくていい
  • Publisher<T>
    • 通常の Java では単一の Object か Collection を返す
    • Publisher は 0..無限 の値を返せる
    • Spring WebFlux では、0 or 1 / 0..無限の値を返す
    • WebSocket はサーバーからのイベントに対応している
  • MongoDB はリアクティブサポートあり (Reactive MongoDB)
    • Embedded MongoDB は組み込みで手軽に開発できる
    • テスト/開発で使うときは build.gradle を testimplementationimplementation に変える
  • ReactiveCrudRepository
    • repo.deleteAll() が最初に実行される保証はない ⇒ repo.deleteAll().block()ブロッキングできる
    • ただし、.block() は書くべきではない ⇒ repo.deleteAll().thenMany(...) でアップストリームの完了を待つ
    • thenMany() はチェインできる
  • Subscriber より Publisher が早いケースをシミュレート
    • onBackpressureDrop : Subscriber が処理しきれないときは捨てる
    • onBackpressureBuffer : Subscriber が処理しきれないときはバッファする (サイズ指定可能)
  • @SpringBootTest
    • Spring 全体のコンテキストをロードする
  • @WebFluxTest
  • 無限の Flux をテストするときは考慮が必要
    • StepVerifier でテストする
    • StepVerifier.withVirtualTime で時間が経過したことをシミュレートしてテストする
  • (メモ) FSR: The Full Stack Reactive (meta) repository

クラウドネイティブSpring

  • Reactive MongoDB
  • Java 11
  • Lombok
  • R2DBC
    • R2DBC では Spring Data JDBC を使う
    • Reactive MongoDB は使わない?
    • Production ではまだ使わない (GAではないので)
    • R2DBC では deleteAll は使えない?
  • RouteLocator (Spring Cloud Gateway)
  • Spring Security
    • bcrypt を使う?
    • Reactive に対応しているが、古い AuthenticationManager は動作する (Problem?)
  • 429 Too Many Requests

Spring Cloud Gateway

  • マイクロサービスが増えるとサービス間の関連が増える
  • 通常は Gateway を配置する
  • 主な目的は Routing (リクエストを適切なインスタンスに流す)
  • すべてのアプリケーションに対してセキュリティを実施
  • Canary-ing
    • 新バージョンをリリースするときに Canary Release する
    • 少量のリクエストを流してテストする
  • Monolith なアプリケーションをマイクロサービスに移行する
  • ロードバランサ
  • Netflix Zuul 1
    • Servlet, Blocking IO
    • パフォーマンスに問題があった
    • API が使いにくい
  • Spring Cloud と Zuul 1 は統合済み
  • Netflix Zuul 2
    • Netty, Non-blocking IO
  • Spring Cloud が Zuul 2 と連携すると Zuul 1 と後方互換性がなくなる
  • Spring Cloud Gateway
    • Node.js のような event-loop のアーキテクチャ
    • Request --> Event Queue --(Schedule)--> Event Loop --(Schedule)--> Network Call
    • Network Call --(Callback)--> Event Loop --(Callback)--> Event Queue --> Response
  • Handler Mapping (Spring が提供する機能)
    • Predicates
    • Pre-Filters : ダウンストリームに送る前に実行される filter
    • Global Filters : ダウンストリームにリクエストする (WebSocket などのプロトコルをサポート)
    • Post-Filters : HTTP ステータスやヘッダを変えたり、Cookie をセットしたり
  • RouteLocator
    • route に ID を付けるとデバッグのときに便利
  • Hystrix
  • WebSocket
    • クライアント/サーバー間で Gateway を通して persistent な接続を維持する
  • Embedded
    • Spring アプリに Gateway を組み込む
    • レイテンシに厳しい場合など、Cross-Origin の問題も心配なし?
  • Facade
    • クライアントとアプリの間に配置する
    • アプリに直接接続する必要がない
    • 技術(?)が違う場合でも接続できる
    • アプリが切り替わってもクライアントに影響しない
  • Cross-Cutting + App-Specific
  • Gateway で Spring Boot の Auto Configuration が使える (Spring Boot ベースなので)
  • Micrometer Support
    • SLF4J メトリック
  • Zipkin で分散トレーシング
  • (メモ) httpbin.org
  • (メモ) HTTPie

Spring Cloud Stream 2.0によるクラウドイベント駆動型アーキテクチャ

サーバーレスSpring

www.slideshare.net

  • Serverless ★
    • sacle to N, scale to zero
  • Knative & riff
  • HTTP ★
    • spring-cloud-starter-function-web
    • Function インタフェースを実装して Bean 定義する
  • Message ★
    • spring-cloud-function-context + spring-cloud-stream-binder-rabbit
  • Supplier, Function, Consumer
  • Source, Processor, Sink
  • @EnableBinding(Processor.class)
  • Exchange, Topic
  • s.c.s.function.definition にパイプで function をチェインできる
  • Spring Cloud Function Adapter ★
    • PaaS プロバイダに依存せずデプロイ/実行できる
  • Knative & riff
  • Knative は k8s ベースのプロダクト
    • build, deploy, manage
  • riff は Knative 上で動く
    • Knative を簡単に使えるようにするもの
    • polyglot
    • CLI, Function Invokers, BuildTemplates
  • Pivotal Function Service
    • riff の商用サービスとして提供予定

Pivotal Application Serviceで稼働するSpring Boot/Spring Cloudアプリケーション

  • Pivotal Application Service
    • 開発した Spring Boot アプリをどのように運用するか
  • Full Cycle Developers (by Netflix) ★
  • Atlas
    • Netflix 製の監視ツール
    • アプリを監視できるように自分でツールに設定するのは面倒
    • アプリ側からツールに自身を設定するようにした
  • MOSH
  • Spring Cloud Pipeline
    • CredHub
    • 12 Factor App
  • アップロードされたパッケージからCF側でランタイムを判断して環境を構築してくれる?
    • Buildpacks の中でできるっぽい
  • Pivotal Cloud Cache

Using Spinnakerを使用したKubernetes上の開発ワークフローの作成

  • Container をまとめたものが Pod
  • Pod をまとめたものが ReplicaSet
    • 可用性
  • ReplicaSet を拡張したものが Deployment
  • LB側でグローバルIPを持つ
  • Ingress
    • 1つのURLで複数のアプリを持てる
  • Helm
  • Helm Chart
  • Kuberapps Hub

所感など

先週の Spring Fest 2018 に続いて、2週連続の Spring イベント。とにかく登壇者が豪華でした。みなさん、ユーモアが豊富でおもしろかったです。全体的にデモやライブコーディングがあってよかった。特に、Josh Long のセッションとライブコーディングは勢いが凄まじかったです。

とはいえ、PCF や k8s などは使ったことがなくてイマイチ理解が追い付かず。特に、k8s あたりは避けては通れないと思われるので勉強しなければ。

当日、JJUG x JSUG のナイトセミナー で Josh Long のイベントがあったのですが、そっちも参加すればよかった...。もったいない。