7月12日（金）のJSUG勉強会2019その7に参加しました。

クラウド時代だからspring-retryフレームワーク

ビズリーチ社の渡辺 祐さんによる発表。 発表スライドはこちら

学び

• リトライ制御の方針
  • 自動リトライ：短期間で復旧する可能性が高い場合に使う
  • 通信過多の場合はスロットリング
  • aws-sdk-java：スロットリングとリトライの両方を内蔵している
• RDSのフェイルオーバーの挙動
  • フェイルオーバーすると、DBのマシン名が変わる
  • 切り替わるまで60秒〜120秒。（経験的には90秒）
• JDBC接続のコネクションプールやリトライに必要な設定
  • -Dnetworkaddress.cache.ttl=3を設定する。
    デフォルトの-1だとIPアドレスがずっとキャッシュされてしまうので、適当な時間を設定する必要がある。
  • ConnectionTimeoutやValidationTimeoutは重要。数秒程度を設定すると良い
• Spring Retry
  • @Retryableアノテーションよりも、RetryTemplateを使ったほうが分かりやすく、実行速度にも優れる
  • Backoff Policyを指定可能。Exponential Backoffにも対応
• DBCPが正しく設定されていればRetryは必ずしも必要ない

会場アンケート

業務で使用しているJavaのバージョン

Java 8とJava 9/10/11/12が半々程度でほとんど。

業務で使用しているRDBMS

オンプレミスが半数以上、AWS/GCPが3割くらい？
フェイルオーバー試験をしていたのは、AWS/GCP利用者の中の1割（全体の3%？）程度。

業務で使用しているコネクションプールライブラリ

HikariCPが圧倒的多数。

所感

コネクションプールでHikariCPが圧倒的人気だったのは、やはりSpring Boot 2.0系の影響だろうか？
Spring Bootにしておくと標準的な構成をキャッチアップできるのは大きなメリットだなぁと再認識。

@Retryableは知っていたがRetryTemplateは知らなかったので、リトライ処理実装の選択肢が増やせたのは収穫だった。
またRDSフェイルオーバー時の挙動や、JVMのnetworkaddress.cache.ttlは勉強になった。
（少なくともAWSでは）ボタン一つでフェイルオーバーがテストできるそうなので、今後クラウドのDBを利用する際には注意したい。

渡辺さんのプレゼンでは、来場者に対して「ここでの学びがあったか、それを自分たちの業務へどのように落とし込むか」を最後に問いかけていたのが素晴らしいと思った。
元々はSpring Retryを理解するために参加していたが、導入するためのハードルはかなり下げられたと思うので、今後使えそうな場面では活用していきたい。

フレームワーク移行で学ぶ Spring Boot のつまづきポイント

ビズリーチ社の木下 真さんによる発表。

所感

Spring Bootで0から開発した経験があるので、個人的にはあまり収穫がなかったが、2年前の自分に聞かせたかった内容。
一番刺激になったのは、発表者が新卒2年目の方だったこと。
場慣れしていて、堂々と発表していたのが印象的だった。

これで怖くない！？コードリーディングで学ぶSpring Security

カサレアル社の多田 真敏さんによる発表。 発表スライドはこちら。（2018年の発表と同等の内容）

学び

• Spring Security 5.0からリアクティブ対応機能が実装された
• SpringSecurityFilterChainは2つある
  • 片方はサーブレットフィルターとして、もう片方はBeanとして管理されている
• わかりづらいクラス名がちらほらあるので、読み解く際は注意（昔の実装を引きずっているらしい）
• 統合認証基盤などを使っている場合は、ログアウト処理をLogoutHandlerの中に記述する

所感

Spring Securityは全く読んだことがないので勉強になったが、まだまだ理解不足。付いていけなかった内容もちらほら。
所々でクラス名がわかりづらい、エラーハンドリング時の挙動は複雑、などと、しっかり読み解くのは難易度が高そう。
それを踏まえると、Spring Securityを使う際には特にテストコードに重点を置いたのは正解だったかもしれない。
今後はSpring Security自体のソースコードも徐々に理解していきたい。