JSUG勉強会 2019その7 ビズリーチにおけるSpringの活用

自分用にとったメモを共有します。

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

スライドはこちら

自動リトライに向いているのは

数分レベルで復旧している可能性が高いなら自動リトライ
そもそも通信過多の場合はスロットリング
クラウドを用いる場合は自動リトライとスロットリングについて頭に入れておかなければならない。

RDSのフェイルオーバーとは

主系に障害が発生すると自動的に副系に変わること

フェイルオーバー後にCNAMEが切り替わる
→だからアプリケーションが勝手に起動する。

JVMが生きている間はDNS検索結果をずっとキャッシュするのがデフォルト
→なので、CNAMEが切り替わってもJVMがキャッシュのせいで理解しない
"-Dnetowrkaddress.cache.ttl=3"　デフォルトの-1から秒数を設定してあげる

Spring Retry

AOPはわずかに遅くなる。
RetryTemplateを明示的に使うほうがわかりやすくて確実。

アプリケーション
↓　←ここに失敗した場合は××回までリトライする。
　　　間隔を指数関数的にリトライすることも可能
コネクションプール
↓
JDBCドライバ
↓
DB

まとめ

クラウドの向こう側の障害が90秒で回復しても、それに依存する自分のアプリケーションも90秒で回復するとは限らない。
フェイルオーバー試験するしかない。
リトライは(DBCPの設定がちゃんとできていれば)最悪、無くてもよい。

参考

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

ニクリーチ

1年前にSpringへフレームワーク移行を実施。
Seasor, SAStruts, JSPから移行した。

移行作業

作業の大半はControllerとテンプレートの書き換え。

大きく異なる点

viewにデータを渡す方法
Formクラスでの値の受け取り方

viewにデータを渡す方法

Springは書き方がめちゃくちゃある

Model
ModelAndView
@ModelAttribute
などなど・・・

とりあえずチーム内で渡し方のルールを決める
あらかじめHelperクラスを作っておけば、統一しやすい。

Springのコントローラーはデフォルトがsingletonなので注意
@Scopeアノテーションを用いることでコントローラークラスのインスタンス生成のタイミングを変えることができる。(デフォルトがsinglton)

Formクラスでの値の受け取り方

注意点/つまづきポイント

th:fieldとth:objectによるFormバインディングの際にはFormクラスにはgetter/setterが必要であることに注意が必要。
SpringSecurityを有効にしている場合、csrfトークンを有効にしておかないと403になってしまう→th:actionを用いると解決される。

SpringSecurityのつまづきやすい認証処理

SpringSecurityの場合
Controllerでパラメーターを受け取らない。必要なクラスをBean定義するだけ。

なぜわかりにくいのか

処理が隠ぺいされてしまっているから
認証がしっかりと抽象化されているから

どういうところでつまづいたか

実装の選択肢が多い→viewにデータを渡す方法など
覚えることが多い→アノテーションの数,SpringSecurityなど
フレームワークの隠蔽化がすごい→CSRFトークン,SpringSecurityなど

ではどうするか

実装の選択肢が多い→チームで共通化する。他のチームやプロダクトを参考にする
覚えることが多い→頑張る。必要なものは都度覚える
フレームワークの隠蔽化がすごい→頑張る。

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

スライドはこちら

SpringSecurityとは

Springのサブプロジェクト
認証認可を中心にセキュリティにまつわる様々な機能を提供する
何重ものサーブレットフィルターで機能を実現している

数あるプロダクトの中でもかなり複雑

アーキテクチャをざっくり理解する

従来のサーブレット版を前提に解説
フィルターはBeanとして管理されている。
application.propertiesでlogging.level.org.springframework.security = debug
とするとログで確認することができる。

コードを読んで深く理解する

フィルターのコードから読むようにするとよい。

なぜThreadLocalを使うのか
実行中スレッドのどこからでもSecurityContext内のユーザー情報にアクセスできるため

LogoutHandlerは何をしているのか
SecurityContextLogoutHandlerが必ず最後に実行される

AuthenticationManagerとは
認証処理を行うインターフェース

まとめ

Spring Securityは複雑だが、コードリーディングは楽しい

参考

雑感

話を聞いた中では２人目の木下さんの話は共感できることが非常に多く、印象的でした。
特にまとめにあった

実装の選択肢が多い
覚えることが多い
フレームワークの隠蔽化がすごい

は非常に共感できました。

また、Spring Retryの存在は初耳でしたし、難しいなぁと感じていたSpring Securityが他の人にとっても難しいものであるということを認識できたことも良かったです。