Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
クラウド時代だからSpring-Retryフレームワーク
Search
Yu Watanabe
July 23, 2019
Technology
0
270
クラウド時代だからSpring-Retryフレームワーク
Yu Watanabe
July 23, 2019
Tweet
Share
More Decks by Yu Watanabe
See All by Yu Watanabe
JUnitテストをCI環境で並列で実行する方法とその速度, スケーラビリティ
nabedge
5
2.6k
ツール比較しながら語るO/RマッパーとDBマイグレーション
nabedge
0
130
JavaでWebサービスを作り続けるための戦略と戦術
nabedge
0
74
サーバーサイドな人がフロントエンド技術と仲良くするはじめの一歩
nabedge
0
62
Selenium再入門
nabedge
0
51
Webエンジニアがスタートダッシュをキメるためのローカル開発環境の勘所
nabedge
0
65
テストゼロからイチに進むための戦略と戦術
nabedge
0
73
jOOQってなんて読むの?から始めるSpringBootとO/Rマッパーの世界
nabedge
0
120
あなたのプロジェクトが気軽にJavaをバージョンアップするために必要なこと
nabedge
0
47
Other Decks in Technology
See All in Technology
業務自動化プラットフォーム Google Agentspace に入門してみる #devio2025
maroon1st
0
180
SREとソフトウェア開発者の合同チームはどのようにS3のコストを削減したか?
muziyoshiz
1
100
SoccerNet GSRの紹介と技術応用:選手視点映像を提供するサッカー作戦盤ツール
mixi_engineers
PRO
1
160
AI Agentと MCP Serverで実現する iOSアプリの 自動テスト作成の効率化
spiderplus_cb
0
460
PythonとLLMで挑む、 4コマ漫画の構造化データ化
esuji5
1
130
Oracle Cloud Infrastructure:2025年9月度サービス・アップデート
oracle4engineer
PRO
0
370
Optuna DashboardにおけるPLaMo2連携機能の紹介 / PFN LLM セミナー
pfn
PRO
1
840
多野優介
tanoyusuke
1
200
「AI駆動PO」を考えてみる - 作る速さから価値のスループットへ:検査・適応で未来を開発 / AI-driven product owner. scrummat2025
yosuke_nagai
3
530
Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 / Go Conference 2025
flatt_security
0
330
ZOZOのAI活用実践〜社内基盤からサービス応用まで〜
zozotech
PRO
0
150
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
940
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.8k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
Why Our Code Smells
bkeepers
PRO
339
57k
Code Review Best Practice
trishagee
72
19k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
RailsConf 2023
tenderlove
30
1.2k
Designing for humans not robots
tammielis
254
25k
Navigating Team Friction
lara
189
15k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Transcript
クラウド時代だから Spring-Retry フレームワーク Y.Watanabe 2019-07-12 JSUG勉強会2019その7 ビズリーチにおけるSpringの活用
ストップウォッチ スタート 確認 2
ビズリーチでは エンジニアを募集しています 3
Who? • 渡辺 祐 • (株)ビズリーチ • SREグループ ◦ Site
Reliability Engeneering 4
アンケート • Java 5, 6, 7 • Java 8 •
Java 9,10,11,12… • まさかのJava1.3, 1.4 • わからない 5
RDBMSは? • オンプレミス • AWS-RDS, Google Cloud SQL • その他クラウド
• わからない 6
コネクションプールライブラリ • apache commons-pool 1.x • apache commons-pool 2.x •
Tomcat DBCP • HikariCP • その他 (c3po…. • わからない 7
今日お話したいこと • 数回の自動リトライで 得られる安眠がある • 自動リトライを実装する前に やるべきことがある • Spring-Retryの原始的な使い方 8
ある日の出来事 1. RDSが障害でフェイルオーバー 2. 90秒で自動復旧した 3. しかしアプリのエラーログアラートは10分以上鳴 りっぱなし 9
誰かがイイこと言った DBがフェイルオーバーしたくらいで なんでこんなに騒いでんの? 10
ある日の出来事(2) Slack APIが 「429 Too Many Request」を返却。 20分くらいエラーログアラートラッシュ 11
自動リトライに向いているのは? • 短期間(数分レベル)で復旧している可能 性が高いなら自動リトライ • そもそも通信過多の場合はスロットリング 12
aws-sdk-javaの場合 スロットリングとリトライの両方を内蔵している 13
1. JDBC接続のリトライ ↑今日はコレ 2. REST-APIへのhttpリクエストのリトライ ↑ ググった結果のコピペでイケます 14
RDSのフェイルオーバーとは? 15
RDSのフェイルオーバーとは • 主系に障害が発生すると 自動的に副系に切り替わる • 公式マニュアルでは 「60秒から120秒かかる」 • 経験値では90秒 16
DBが90秒で復帰してるのに アプリが90秒で復帰できないってどゆこと? 17
jdbc:mysql://db.biz.internal/hogedb $ host db.biz.internal db.biz.internal is an alias for a.rds.amazonaws.com.
a.rds.amazonaws.com has address 10.1.1.1 $ host db.biz.internal db.biz.internal is an alias for b.rds.amazonaws.com. b.rds.amazonaws.com has address 10.2.2.2 フェイルオーバー前 フェイルオーバー後 18
フェイルオーバーメカニズムでは、スタンバイ DB インスタンスをポイントするように DB インスタンスの DNS レコードが自動的に変更されます。したがって、DB インスタンスへ の既存の接続の再確立が必要になります。Java DNS
キャッシュメカニズムがどのよう に機能するかによって、JVM 環境の再設定が必要になる場合があります。フェイルオー バーの際に DNS 値をキャッシュする Java アプリケーションの管理方法の詳細につい ては、「AWS SDK for Java」を参照してください。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html RDSのマニュアルなのになぜか 「Javaの場合は注意しろ」とわざわざ書いてある(笑) 19
まずやるべきこと -Dnetworkaddress.cache.ttl=3 デフォルトは”-1” つまりJVMが生きてる間はDNS検索結果を ずっとキャッシュするのがデフォルト 20
(講演後の追記) 実は前の -Dnetworkaddress.cache.ttl=3 は嘘です。これじゃ設定できないっす。 正確にはこんな感じのコードをpublic static void main(args)を持つクラスの最初の方に 埋め込んでいます。 java.security.Security.setProperty("networkaddress.cache.ttl",
"3"); java.security.Security.setProperty("networkaddress.cache.negative.ttl", "3"); 21
他にもまだあるんじゃね? 22
@Bean public DataSource dataSource() { ds = new BasicDataSource(); ds.setUrl()...setUser()...
setPassword()... ds.maxActive(10? 50? アプリによりけり) ds.setValidationQuery(“SELECT 1”) return new TransactionAwareDatasourceProxy(ds) } // えっ?これだけ? 23
commons-pool 1.x の他のパラメータ • minEvictableIdleTimeMills • numTestPerEvictionRun • testWhileIdle •
validationQueryTimeout • 他多数 24
commons-pool 2.x で増えたパラメータ • fastFailValidation • logAbandoned • removeAbandonedOnBorrow •
他多数 25
• Tomcat-DBCPというのも速いらしい • 最近はやはりHikariCPがデファクトらしい 26
commons-pool 1.x は2012年で打ち止め 27
クラウド時代のRDBに向かって 7年前に開発打ち止めの コネクションプール機構を使い続けるとでも? 28
@Bean public DataSource dataSource() { conf = new HikariConfig(); conf.setUrl()...setUser()...
conf.setMaxIdle(10? 50? アプリによりけり) conf.setConnectionInitSql(...) conf.setConnectionTimeout(数秒) conf.setValidationTimeout(数秒) 意外と少ない設 定で良さげ 29
1. ここまでで最低限の準備が完了 2. ここからが本番の 「RDSがフェイルオーバーしたときの エラーログアラートラッシュ緩和のための Spring-Retry」 30
ちょっと休憩 時間を確認 25分くらい? 31
@Configuration @EnableRetry public HogeConfig {... Javaコンフィグ ...} @Retryable(value = {FooException.class},
maxAttempts=3) public Bar barMethod(args...) { // なんか不安定かもしれない外部通信 } 32
• AOPはちょっぴり遅くなる • RetryTemplateを明示的に使うほうが わかりやすくて確実 33
やりたいこと DB(RDS) JDBCドライバ コネプ アプリケーション DBコネクション取得失敗の場合 に、4回までリトライする 1sec後 -> 2sec
-> 4sec -> 8sec 34
retryTemplate = new RetryTemplate(); retryTemplate.setBackOffPolicy(省略); retryTemplate.setRetryPolicy(省略); 例: Excepation.classはリトライ対象だが RuntimeExceptionは対象外にする、等 まずRetryTemplateを準備しておく
35
spring-jdbc提供のDataSourceを拡張 public class FooDataSource extends DelegatingDataSource { @Override public Connection
getConnection() throws SQLException { return retryTemplate.execute(context -> { if (context.getRetryCount() > 0) { /* warnログなど */ } return super.getConnection(); }); 36
@Bean public java.sql.DataSource dataSource() { conf = new HikariConfig(); conf.set…(jdbc-url,
user, その他もろもろ) hikariDs = new HikariDataSource(conf); fooDs = new 前ページのFooDataSource(hikariDs); ds = new TransactionAwareDatasourceProxy(fooDs); return ds; 37
手動でフェイルオーバーさせて試す 38
DBAさん 39
まとめ 40
• クラウドの向こう側の障害が90秒で回復しても、 それに依存する自分のアプリケーションも90秒で 回復するとは限らない。 • フェイルオーバー試験するしかない。 41
AWS-SDKならその配布ライブラリ自体で リトライ機構が組み込み済みだが... aws-java-sdk-s3 aws-java-sdk-sqs aws-java-sdk-rdb ? aws-java-sdk-jdbc ? 存在しません 42
リトライは 最悪、無くてもいい。 リトライがあれば、DBがfail overから復帰するまでの90 秒のエラーログの飽和(からの精神的苦痛)をやわらげ ることができる DBCPの設定が ちゃんとできてれば 43
ほとんどのコードを書いてくれたS君に感謝 (自分はほぼレビューのみ) 44
週明け、皆さんのプロジェクトでやることは? • DBCPライブラリ、何使ってるか確認する? • DBCPの設定、確認する? • fail over試験、する? • (DBまわりに限らず)Spring-Retry
どこかで使えそう? 45
ビズリーチでは エンジニアを募集しています 46