先日、SpringOne Tour 2018 に行ってきました。簡単に所感をまとめます。
メモから抜粋。スライドが公開されたらリンクを貼っておきます。逐次通訳はあったのですが、理解が誤ってる箇所があるかもしれません...。
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<T>
- 通常の Java では単一の Object か Collection を返す
- Publisher は 0..無限 の値を返せる
- Spring WebFlux では、0 or 1 / 0..無限の値を返す
- WebSocket はサーバーからのイベントに対応している
- MongoDB はリアクティブサポートあり (Reactive MongoDB)
- Embedded MongoDB は組み込みで手軽に開発できる
- テスト/開発で使うときは build.gradle を
testimplementation
⇒implementation
に変える
- 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
- 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 が提供する機能)
- 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によるクラウドイベント駆動型アーキテクチャ
- events / commands / invariants (不変条件)
- オブジェクト指向、メッセージング
- RabbitMQ を通してそれぞれがイベントをやり取りできるようにする
- Spring Cloud Stream
@EnableBinding(Source.class)
@EnableBinding(Channels.class)
@EnableScheduling
- (メモ) pilloPl/credit-cards-producer
- (メモ) pilloPl/credit-cards-consumer
サーバーレス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 のイベントがあったのですが、そっちも参加すればよかった...。もったいない。