Spring Bootでマイクロサービス作って苦労したお話 / DeveloperSummit2019-SpringBoot

株式会社ブロードリーフ
松本宏紀
2019.02.14
Spring Bootでマイクロサービス作って苦労したお話
#devsumiE 14-E-2

View Slide

Copyright © Broadleaf Co., Ltd. All Rights Reserved. 1
自己紹介
松本宏紀
株式会社ブロードリーフ基盤開発部 (札幌)
• システム・アーキテクト
• ソフトウェア・エンジニア
• オフショアラボチームリーダー
• デブサミ2018夏：
［Cassandra x Kubernetesによる大規模データ基盤の仕組みと苦労]

View Slide

Spring Boot 好きです。
本日のテーマ

View Slide

猫も杓子もSpring Boot。
JavaといえばSpring Boot。
そんなにSpring Bootがいいですか？
マイクロサービス・アーキテクチャでも？
本日のテーマ

View Slide

マイクロサービスアーキテクチャっぽいサービス開発。
Service
Service
Service
Service
Service
Service
Service
Service
背景
Spring Boot
Spring Data
JDBC Cassandra Elasticsearch Redis
Spring for Apache Kafka等々…
DATA-FRMEWORK
マルチテナントにおける各データストアアクセスの提供、
及びデータ・ディクショナリ提供
API-FRAMEWORK
RESTful APIの提供するためのフレームワーク。
認証、認可(role,license)…などの共通化。
SERVICE
各サービスの実装。
>=43

View Slide

問題
アプリケーションの起動が遅い。
アプリケーションのテストが遅い。
開発
運用
遅い。人が待たされる。
開発

View Slide

起動が遅い
開発中、速く動作確認したいけど、中途半端に待たされる。
BUILD TEST DEPLOY
maxUnavailable = replicas/2
2分待つことになる。
入れ替えの順序性が必要な場合だと待たされるのがつらい。
65秒
15秒 11分
podがOOMとかで落ちちゃった際の修復時間に直結して遅くなる。
Gitlab RunnerのPIPELINEが詰まる。
ci-worker1
BUSY
pipeline request
起動が遅い。
開発
開発
開発
運用

View Slide

起動が遅い
a)起動時に最適化：CPU割当増やす。
b) コストで最適化：このまま。運用状態での最適化。
c) やれることやろう！
d) golangに段階的に移行しよう！
理由1：CPU割当が潤沢ではない。(limit:600ms)
理由2：膨大なクラス数のロード。(14,000～)

View Slide

起動が遅い
起動時間：65秒→48秒
• Java8+Spring Boot 1.5→Java11+Spring Boot 2.1
• fatJarライブラリの整理 (lombokとかのscope=providedも含まれていた)
やれることやる！きっかけはJava11リリース！

View Slide

起動が遅い
起動時間：48秒→43秒
kubernetesのcpu.limitを600msにしている場合の結果です。
興味本位で、cpu.limitを200msにしてみると、下記のような結果。
内部で大量のjar、及びクラスのロードが必要な場合、効果ある。
ただし、全ライブラリspring-context-indexerが有効でなければならない。
cpu.limit:200msの場合
indexerの有効：約100秒
indexerの無効：約140秒
spring-context-indexerを導入する。

View Slide

起動が遅い
起動時間：43秒→28秒 ( ビルド時間：15秒→3分 )
docker image構築時に、下記のように生成・有効化。
Dockerfile.template
FROM maven:3.5.4-jdk-11-slimベースのimage as maven-builder
mvn clean package -U
FROM adoptopenjdk/openjdk11:alpineベースのimage as cds-builder
RUN mv $APP_JAR_FILE /app/framework
RUN java -XX:MaxMetaspaceSize=256M -XX:MetaspaceSize=256M ¥
-Xshare:off -XX:DumpLoadedClassList=/app/cds/api.classlist ¥
-cp "${CLASSPATH}" ${MAIN-CLASS}
RUN java -XX:MaxMetaspaceSize=256M -XX:MetaspaceSize=256M ¥
-Xshare:dump -XX:SharedArchiveFile=/app/cds/api.jsa ¥
-XX:SharedClassListFile=/app/cds/api.classlist -cp "${CLASSPATH}"
FROM adoptopenjdk/openjdk11:alpineベースのimage
COPY --from=cds-builder /app /app
CMD ["/app/startup.sh"]
コンパイル&テスト&packaging
jlinkで縮小されたベースイメージで、
Class Data Sharing有効化。
jlinkで縮小化されたイメージをベースに、
実行時イメージ作成。
Application Class-Data Sharing(JEP310)を導入する。

View Slide

テストが遅い
忘れた頃にやってくるテスト通知。失敗すると辛い。
テスト大事。でも待たされるのがつらい。
開発
BUILD TEST DEPLOY
65秒
15秒 11分

View Slide

テストが遅い
起動時間：11分→2分
• Java起動時オプションのチューニング
• -XX:TieredStopAtLevel=1
• -XX:+TieredCompilation
階層型コンパイル。2分ちょっと短縮(11分→9分)。
• Maven Surefire PluginのreuseForksをtrueに変更。9分→2分！
※元々は、spring-bootのissue#10366の問題を回避するために
reuseForksをfalseにしていた。
本当は、この前段階でApplication Class Data Sharingしたかったが断念。
Classpath mismatch
The classpath used with -Xshare:dump must be the same as, or be a prefix of, the classpath used with -Xshare:on. Otherwise,
the JVM will print an error message about the mismatched classpath and refuse to start. To analyze the mismatch, you can
add -Xlog:class+path=info to the application's command-line, and the JVM will print out detailed diagnostic information
about what classpath is expected, and what classpath is actually used.
引用:https://openjdk.java.net/jeps/310

View Slide

結果
起動が遅い。
テストが遅い。
65秒→28秒
11分→2分
12分→6分
ある程度改善。
開発
運用
開発
BUILD TEST DEPLOY
65秒→28秒
15秒→3分 11分→2分

View Slide

反省
ローカル環境で動かすの結構大変。
profileでしっかりmock、API call切り替えれるようにした方が良い。
後は、docker-composeなり、kubernetesのenvironmentで設定。
Metaspaceの領域も意識しておかないと、メモリの消費が激しくなる。
Dynamic Configuration最初から意識しておかないと、運用がしんどい。
Spring Cloud Kubernetesにものすごく期待。
どこまで抽象化するか？
アプリケーションフレームワークまで完全抽象化(フレームワーク化)すると、
• 多くの人は、どうやって動いているのか謎状態
• 最低でも3つくらいのバージョン平行運用
とか発生する。
先に良く考えておくこと。

View Slide

反省
API Application Apache Kafka
Apache Cassandra
Elasticsearch
CloudSQL
Consumer
Consumer
Consumer
Redis
Consumer
引用：デブサミ2018夏発表資料
より責務を細分化。
育ってきたら、もっとシンプルに。より疎結合に。
でも育てる時は早くリリース→フィードバックを得られる形が良い。

View Slide

反省
Spring Boot
Eclipse MicroProfile
Micronaut
• 理解している人が多い。
• フルスタックフレームワーク。クラウド環境、データストア多数対応。
• ドキュメントが豊富。
• 重量級。
• Spring Fu等、Micronaut的なフレームワークも開発中。
• マイクロサービスアーキテクチャに最適化。
• Eclipse Foundationのプロジェクト。
• 仕様と実装の分離。
色々と…Jakarta EE標準化仕様サブセットとして統一化されていくかも？
• やっぱり重量級。
• DI、AOPをコンパイル時に解決。起動がものすごく速い。
• native-image化できる。起動速度が30msとかのレベル感。
• Apache Kafka、Apache Cassandraをサポート。
• 比較的軽量。
マイクロサービスにも合う形で進化途中。
Spring Boot以外の選択肢を考慮すべき。速いは正義。

View Slide

今後
Service
Service
Service
Service
Service
Service
Service
Service
やれる所から変えていく。フィードバックしていく。
チーム間・サービス間でより良い競争をしたい。

View Slide

SHARE YOUR FUN!
SHARE YOUR FUN!

View Slide

SHARE YOUR FUN!
体験
チーム仕事の価値
自分が今いる環境の中で、自分たちで物事を変えていく。
新しいことに興味を持つ。失敗しても、許される。
それを、体験する。変えていけるのは自分たちだけ。

View Slide

SHARE YOUR FUN!
変化を
楽しく
受け入れる

by Developer Summit Summer 2018

View Slide

Spring Bootでマイクロサービス作って苦労したお話 / DeveloperSummit2019-SpringBoot

Spring Bootでマイクロサービス作って苦労したお話 / DeveloperSummit2019-SpringBoot

Broadleaf Co., Ltd.

More Decks by Broadleaf Co., Ltd.

Other Decks in Technology

Featured

Transcript