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の設定がちゃんとできていれば)最悪、無くてもよい。
参考
- https://github.com/spring-projects/spring-retry
- https://qiita.com/kazuki43zoo/items/d9182c8ddb2b754f150f
フレームワーク移行で学ぶ 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が他の人にとっても難しいものであるということを認識できたことも良かったです。