クラウド時代だからSpring-Retryフレームワーク
0 likes3,402 views
JSUG(Japan Spring Users Group)2019年7月勉強会資料
クラウド時代だからSpring-Retryフレームワーク
- 4. Who? ● 渡辺 祐 ● (株)ビズリーチ ● SREグループ ○ Site Reliability Engeneering 4
- 5. アンケート ● Java 5, 6, 7 ● Java 8 ● Java 9,10,11,12… ● まさかのJava1.3, 1.4 ● わからない 5
- 6. RDBMSは？ ● オンプレミス ● AWS-RDS, Google Cloud SQL ● その他クラウド ● わからない 6
- 7. コネクションプールライブラリ ● apache commons-pool 1.x ● apache commons-pool 2.x ● Tomcat DBCP ● HikariCP ● その他 (c3po…. ● わからない 7
- 8. 今日お話したいこと ● 数回の自動リトライで 得られる安眠がある ● 自動リトライを実装する前に やるべきことがある ● Spring-Retryの原始的な使い方 8
- 9. ある日の出来事 1. RDSが障害でフェイルオーバー 2. 90秒で自動復旧した 3. しかしアプリのエラーログアラートは10分以上鳴 りっぱなし 9
- 11. ある日の出来事(2) Slack APIが 「429 Too Many Request」を返却。 20分くらいエラーログアラートラッシュ 11
- 14. 1. JDBC接続のリトライ ↑今日はコレ 2. REST-APIへのhttpリクエストのリトライ ↑ ググった結果のコピペでイケます 14
- 18. 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
- 19. フェイルオーバーメカニズムでは、スタンバイ 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
- 21. （講演後の追記） 実は前の -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. 他にもまだあるんじゃね？ 22
- 23. @Bean public DataSource dataSource() { ds = new BasicDataSource(); ds.setUrl()...setUser()... setPassword()... ds.maxActive(10? 50? アプリによりけり) ds.setValidationQuery(“SELECT 1”) return new TransactionAwareDatasourceProxy(ds) } // えっ？これだけ？ 23
- 24. commons-pool 1.x の他のパラメータ ● minEvictableIdleTimeMills ● numTestPerEvictionRun ● testWhileIdle ● validationQueryTimeout ● 他多数 24
- 25. commons-pool 2.x で増えたパラメータ ● fastFailValidation ● logAbandoned ● removeAbandonedOnBorrow ● 他多数 25
- 29. @Bean public DataSource dataSource() { conf = new HikariConfig(); conf.setUrl()...setUser()... conf.setMaxIdle(10? 50? アプリによりけり) conf.setConnectionInitSql(...) conf.setConnectionTimeout(数秒) conf.setValidationTimeout(数秒) 意外と少ない設 定で良さげ 29
- 32. @Configuration @EnableRetry public HogeConfig {... Javaコンフィグ ...} @Retryable(value = {FooException.class}, maxAttempts=3) public Bar barMethod(args...) { // なんか不安定かもしれない外部通信 } 32
- 34. やりたいこと DB(RDS) JDBCドライバ コネプ アプリケーション DBコネクション取得失敗の場合 に、4回までリトライする 1sec後 -> 2sec -> 4sec -> 8sec 34
- 35. retryTemplate = new RetryTemplate(); retryTemplate.setBackOffPolicy(省略); retryTemplate.setRetryPolicy(省略); 例： Excepation.classはリトライ対象だが RuntimeExceptionは対象外にする、等 まずRetryTemplateを準備しておく 35
- 36. 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
- 37. @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
- 39. DBAさん 39
- 40. まとめ 40
- 45. 週明け、皆さんのプロジェクトでやることは？ ● DBCPライブラリ、何使ってるか確認する？ ● DBCPの設定、確認する？ ● fail over試験、する？ ● （DBまわりに限らず）Spring-Retry どこかで使えそう？ 45