1
Springベースの
Cloud Native Application
2021/10/18
日本Springユーザ会
土岐 孝平
自己紹介
• 土岐 孝平
• 合同会社 現場指向
– Springのオンライン研修
– 開発支援
– メモラキー
• 書籍の執筆
2
[改訂新版]Spring入門 OpenID Connect入門
Cloud Native Applicationとは?
• クラウドで動くことを前提に作られたアプリケーション
– Microserviceを採用
– Containerで動かす
– 動的にオーケストレーションされる
• Containerの動的なスケールアウト・イン、ローリング
アップデート
– ・・・
3
Spring
?
Springベースのアプリでは、
どのようなやり方が良いのだろう?
Container
アプリA Container
アプリB
Container
アプリB
アジェンダ&紹介するセッション
• Microserviceのインフラ
– Next-Generation Cloud Native Apps with Spring
Cloud and Kubernetes
• Native Image + Container + Serverless
– Going Serverless Using the Spring Framework
Ecosystem
4
Microserviceのインフラ
5
Microserviceのインフラ
(※一般用語ではありません)
• Microserviceを導入するときに必要となる諸々を提
供する基盤
– Service Discovery
– Load Balancing
– Fault Tolerance
• Retry、 CircuitBreaker、・・・
– Observability
• Tracing、Metrics、・・・
– ・・・
6
Service
Discovery
インスタンス
インスタンス
インスタンス
サービスA
インスタンス
インスタンス
インスタンス
サービスB
インフラを実現する手段の大まかな分類
7
分類 ライブラリで実現 プラットフォームで実現
製品の例 Spring Cloud、Netflix OSS、など Kubernetes、Istio、Linkerd、など
メリット ・開発チームで完結
アプリと同じスキルセット
・開発者フレンドリー
学習しやすい、デバッグしやすい、
など
・アプリの負担が減る
・インフラ周りの設定を変更してもア
プリをリデプロイする必要がない
デメリット ・ライブラリ・言語が変わると、アプ
リの実装が変わる
・アプリの負担が増える
・インフラ周りの設定を変更すると
基本はアプリをリデプロイ
・アプリと異なるスキルセット
・運用チームとの責任分担が難しい
アプリ
インフラ アプリ
インフラ
プラットフォーム
Spring
Springベースだとどのアプロー
チがよいのだろう?
紹介するセッション
• Next-Generation Cloud Native Apps with Spring
Cloud and Kubernetes
8
出典
https://springone.io/2021/sessions/next-gen-cloud-native-apps-with-
spring-cloud-and-k8s
セッションの概要
• Spring CloudとKubernetesを連動させる方法を説
明
– Spring Cloudのみの場合はどうか
– Spring CloudとKubernetesをミックス
– さらに、Spring Cloud Kubernetes を使ってSpring
CloudとKubernetesを連動
– ライブデモ
9
Spring Cloudのみの場合
10
出典:当該セッションの発表スライド
Proxy
補足
• Spring Cloud Config
– アプリが外部から取得する設定値を一元管理できる
– プロファイル毎に設定値を管理できる
– 設定値をGitから読み込める
– Spring Cloud Bus(裏でRabbit MQなどを使う)を使うことで、変更をアプリに
通知できる
– リフレッシュスコープを使うことで、アプリを再起動せずに反映できる(リフレッ
シュスコープのBeanだけ更新)
11
機能 ライブラリ
Service Discovery Server Spring Cloud Netflix (Eureka)
Tracing Spring Cloud Sleuth
Circuit Breaker Spring Cloud Circuit Breaker
Load Balancing Spring Cloud Loadbalancer
Config Server Spring Cloud Config
@RefreshScope
Spring Cloudのみの場合の課題
• アプリのオーケストレーションを自分たちでやる必要
がある
– オートスケール、ローリングアップデート、デプロイ戦略(ブ
ルー・グリーンデプロイメント、カナリーデプロイメントなど)
、・・・
• サービスの種類が増える
– Service Discovery Server、Config Server、RabbitMQ
12
Spring Cloud + Kubernetes
13
出典:当該セッションの発表スライド
Pod
Pod
補足
• オーケストレーションはKubernetesに任せる
• Service DiscoveryやLoad BalancingはKubernetesの
Serviceに任せる
– Tracing、Circuit BreakerはSpring Cloudで対応
• KubernetesのConfig Mapから設定値を取得
– Config Mapで設定したデータを、環境変数やファイルを介してアプリ
が取得する
14
Pod
Container
アプリA
Container
アプリB
Container
アプリB
Kubernetes Service
Spring Cloud + Kubernetesの課題
• Config Mapの変更をアプリが検知できないので、
基本はアプリのリデプロイが必要
• アプリ側でロードバランスの制御ができない
15
出典:当該セッションの発表スライド
Spring Cloud Kubernetesの利用
16
出典:当該セッションの発表スライド
補足
• Spring Cloud Kubernetesとは?
– Spring Cloud と Kubernetesを連動させるライブラリ
• KubernetesのServiceの情報(PodのIPアドレスなど)
を取得して、Spring Cloud LoadBalancerを使ってク
ライアント側でロードバランスする、など
– 裏ではKubernetesのAPI Serverを使用している
• Config Watcher
– Spring Cloud Kubernetesが提供する機能の1つ
– Config Mapの変更時に、アプリにリフレッシュイベントを
通知する
• リデプロイせずに設定値を再読み込み可能
17
課題
• アプリがKubernetesのAPI Serverにアクセスする
必要がある
– Podの権限設定が必要
– 企業によっては嫌がる
18
出典:当該セッションの発表スライド
Spring Cloud Kubernetes発展形
19
出典:当該セッションの発表スライド
補足
• Spring Cloud Kubernetes Discovery Server
– Discovery Server(Eurekaは使ってない様子)
– K8S API ServerからServiceの情報(IPアドレスなど)を取
得するので、アプリ側はDiscovery Serverへの登録が不
要
• Spring Cloud Config Server
– Config Mapからもプロパティを読み込む
• アプリはConfig Serverだけ意識すればよい
• アプリがKubernetes API Serverにアクセスしなくて
も良い
20
どのやり方がよいのか?
21
出典:当該セッションの発表スライド
個人的な感想
• 最後の発展形は、高機能ではあるが、運用が複雑
になりそう
– 登場人物が多くなる分、管理対象が増えたり、問題の切
り分けが難しくなりそう
• まずは、Spring Cloud + Kubernetesでスタートして
、必要に応じてSpring Cloud Kubernetesを導入し
ていけばよいと思う
22
Native Image + Container +
Serverless
23
Serverlessとは?
• 利用者がサーバのインスタンスを意識しなくてもよいプラット
フォーム
– 「サーバが存在しない」という意味ではない
• 大まかな分類
– BaaS (Backend as a Service)
• サーバ側はマネージドサービスだけで完結
– 認証、DB、プッシュ通知など
– アプリのロジックはクライアント側で作る
• 代表的な製品: Google Firebase
– FaaS (Functions as a Service)
• アクセスに応じたロジックを関数という単位で作成しデプロイ
• アクセスされた時に起動(Cold Start)し、しばらくアクセスが
無ければ停止
• 代表的な製品: AWS Lambda
24
Serverlessのメリット・デメリット
• メリット
– サーバ側の環境を意識しなくてよいので運用が楽
– 処理が実行されたときだけ課金されるので低料金
• デメリット
– 自由度が低い
– ベンダーロックインになりがち
– デバッグがしにくい、ローカル開発がしにくい
– Cold Startする際に処理が遅延する
25
メリットをそのままに、デメリットを解決する
手段はないか?
紹介するセッション
• Going Serverless Using the Spring Framework
Ecosystem
• SpringのアプリをNative ImageにしてKnative上で
実行する方法を説明
26
出典
https://springone.io/2021/sessions/going-serverless-using-the-spring-
framework-ecosystem
Native Imageとは?
• Javaのコードを、Nativeコード(OS上で直接動くコード)にコン
パイルした実行ファイル
– JVMを使わない
– 専用の実行環境がNative Imageに含まれる
• JVMを使わないので起動が速い、メモリ使用量も少
ない
• GraalVMを使ってNative Imageにコンパイルできる
• Native Imageのコンパイラは、従来のJIT(Just In Time)コン
パイラに対して、AOT(Ahead of Time)コンパイラと呼ばれる
27
JITとAOT
28
出典:当該セッションの発表スライド
JVMとNative Imageのトレードオフ
29
出典:当該セッションの発表スライド
Native Imageを作成するときの課題
• コンパイル時に特定できないクラスはNative Image
に含まれない(メモリのフットプリントを少なくするた
め)
– リフレクションでアクセスされるクラス
– 自動生成されるProxyのクラス
– など
• 特定できなくても含めたい場合は明示的に設定して
GraalVMに渡す必要がある
30
自分で設定するのは大変
Spring Nativeとは?
• Springを使ったアプリを簡単にNative Imageにする
ことができるツール
– GraalVMに渡す情報(自動生成されるProxyのクラスや、
リフレクションでアクセスされるクラスなど)を自動的に生
成してくれる
– MavenのプラグインでNative Imageをビルド
• Spring Nativeのゴール
– Springを使ったアプリに、何も手を入れずにNative
Imageにできることを目指している
• ※現在はExperimental版
31
Spring NativeでNative Imageを作る際の
2つの方法
32
出典:当該セッションの発表スライド
ビルドするマシン
GraalVM
ビルドするマシン
Buildpackの
Container
GraalVM
Container Image
Native Image Native Image
JVMとNative Imageの性能比較
33
出典:当該セッションの発表スライド
Knativeとは?
• Kubernetes上でServerlessにContainerを動かしてくれるプ
ラットフォーム
– 処理が呼び出された際にContainerが自動で起動し、しばらく使われ
なかったら自動で停止する
– さまざまな種類の入力を受けつけることができる
• HTTP、Kafka、GitHub、・・・
• マネージドサービスを利用できる
– Google Cloud Runなど
34
Kubernetes
Knative
Pod
Container
アプリ
Pod
Container
アプリ
使われなかったら自動で停止
• セッション内のデモの中で「kubectl get pods」コマン
ドでPodの数を定期的に確認
– 2回目のコマンドでは「Running」のPodが無くなっている
35
出典:当該セッションの動画
Knative + Native Image
• Serverlessのメリットをそのままにデメリットを解消
– マネージドサービスを使えば、サーバ側の環境を意識し
なくてよいので運用が楽
– 処理が実行されたときだけ課金されるので低料金
– Cold Start時の起動が速い、メモリの消費も低い
– 自由にアプリを作れる
• アプリをContainer Imageにするだけ
36
個人的な感想
• クラウドを利用しているエンタープライズな業務アプ
リにも向いてるかも
– 時間帯によってユーザ数やアクセス数に差がある
• 昼休みや業後はほとんどアクセスが無い、など
– リリースの頻度が少ない
• ビルドに時間がかかっても問題ない
– お金を節約したい
37
紹介したセッション
• Microserviceのインフラ
– Next-Generation Cloud Native Apps with Spring
Cloud and Kubernetes
• Native Image + Container + Serverless
– Going Serverless Using the Spring Framework
Ecosystem
38
39
ご清聴ありがとうございました
40
ライセンスについて
• JSUGマスコットアイコン(本スライド左下)が残されている場合に限り、本作品(またそれを元にした派生
作品)の複製・頒布・表示・上演を認めます。
• 非商用目的に限り、本作品(またそれを元にした派生作品)の複製・頒布・表示・上演を認めます。
• 本作品のライセンスを遵守する限り、派生作品を頒布することを許可します。

SpringベースのCloud Native Application