Tweet7月12日(金)のJSUG勉強会2019その7に参加しました。自動リトライ:短期間で復旧する可能性が高い場合に使う通信過多の場合はスロットリングaws-sdk-java:スロットリングとリトライの両方を内蔵しているRDSのフェイルオーバーの挙動フェイルオーバーすると、DBのマシン名が変わる切り替わるまで60秒〜120秒。(経験的には90秒)JDBC接続のコネクションプールやリトライに必要な設定-Dnetworkaddress.cache.ttl=3を設定する。デフォルトの-1だとIPアドレスがずっとキャッシュされてしまうので、適当な時間を設定する必要がある。ConnectionTimeoutやValidationTimeoutは重要。Policyを指定可能。9/10/11/12が半々程度でほとんど。業務で使用しているRDBMSオンプレミスが半数以上、AWS/GCPが3割くらい?フェイルオーバー試験をしていたのは、AWS/GCP利用者の中の1割(全体の3%?)程度。Bootにしておくと標準的な構成をキャッチアップできるのは大きなメリットだなぁと再認識。@Retryableは知っていたがRetryTemplateは知らなかったので、リトライ処理実装の選択肢が増やせたのは収穫だった。RDSフェイルオーバー時の挙動や、JVMのnetworkaddress.cache.ttlは勉強になった。(少なくともAWSでは)ボタン一つでフェイルオーバーがテストできるそうなので、今後クラウドのDBを利用する際には注意したい。渡辺さんのプレゼンでは、来場者に対して「ここでの学びがあったか、それを自分たちの業務へどのように落とし込むか」を最後に問いかけていたのが素晴らしいと思った。Retryを理解するために参加していたが、導入するためのハードルはかなり下げられたと思うので、今後使えそうな場面では活用していきたい。Bootで0から開発した経験があるので、個人的にはあまり収穫がなかったが、2年前の自分に聞かせたかった内容。刺激になったのは、発表者が新卒2年目の方だったこと。場慣れしていて、堂々と発表していたのが印象的だった。発表スライドはこちら。Securityは全く読んだことがないので勉強になったが、まだまだ理解不足。付いていけなかった内容もちらほら。所々でクラス名がわかりづらい、エラーハンドリング時の挙動は複雑、などと、しっかり読み解くのは難易度が高そう。Securityを使う際には特にテストコードに重点を置いたのは正解だったかもしれない。Security自体のソースコードも徐々に理解していきたい。