はじめに
弊社平成最初で最後の新卒エンジニアの石川です。 本記事では 「JSUG勉強会 2019その７ ビズリーチにおけるSpringの活用」の勉強会に参加してきたので、その備忘録をここに記します。 全３セッションでした。
本勉強会のツイート（#jsug）はこちらにまとめています。
====
- 参加者数は９０人くらいで、6 割ぐらいはスーツのかた、残りの 4 割くらいは私服のかたでした
- 会場内での Java の各バージョンの使用率アンケート
- 一番多いのは Java 8 で全体の約半数
- 次いで Java 5, 6, 7 と Java 9, 10, 11, 12 が残りの半々ずつくらい
クラウド時代だからSpring-Retryフレームワーク
DBに障害があってフェイルオーバーにより９０秒で復帰してるけど、アプリが９０秒で復帰できないという問題に直面したときの、原因究明や解決にいたるまでの道のりについてのおはなしでした。
以下雑記。
- 自動リトライとは？
- 外部サービスやメール送信で通信接続失敗したときや、DB にデータ格納する際にハッシュ値かぶってるときに再試行すること
- リトライ処理書くのは結構めんどう
- リトライ処理を手動で書くと try のネストになる
- そこで Spring-Retry ！（リトライ処理がシンプルに書ける）
- 自動リトライに向いているのは？
- 短期間（数分レベル）で復旧している可能性が高いなら自動リトライ
- そもそも通信過多の場合はスロットリング
- RDS のフェイルオーバーとは？
- 主系に障害が発生すると自動的に副系に切り替わること
- フェイルオーバー試験ちゃんとやろうね
- Java の場合は注意せよ
- JVM の DNS キャッシュが悪さをして、DBインスタンスにアクセスできず、アプリが復旧しなかった
- AWS SDK for Java 参照
JVM の DNS キャッシュについて調べてみた。 Oracle Java SE 8 のドキュメントにはこう書いてある。
デフォルトでは、セキュリティ・マネージャがインストールされている場合は、DNSなりすまし攻撃から身を守るため、成功したホスト名解決の結果が永続的にキャッシュされます。
本セッションの事例では、フェイルオーバーによって DB インスタンスが切り替わり、ホスト名解決の結果（接続先 DB インスタンスの IP アドレス）も変わった。 しかし、JVM の DNS キャッシュにより、接続先 DB インスタンスの IP アドレスが切り替わる前のものを指しているままだった。 そのため、DBが復旧してもアプリが DB を参照することができず、復旧しなかったということか。なるほど。
フレームワーク移行で学ぶ Spring Boot のつまづきポイント
お腹を空かせた学生のための肉食就活サイト「ニクリーチ」のフレームワークを移行した際に気づいた点やつまづいたところのおはなし。登壇者の木下さんは現在新卒2年目で、入社して最初に任された仕事がこれだったらしい。喋り方貫禄ある。すげえー。
以下雑記。
- 旧フレームワーク：JSP、SAStruts、Seasar
- JSP：HTML内にJavaのコードを埋め込んでおくと、Webサーバで動的にWebページを生成してクライアントに返してくれるテンプレートエンジン
- SAStruts：Strutsを使った開発をさくさく行なうためのフレームワーク
- Seasar：DI と ASP をサポートした軽量コンテナ
- 移行作業のほとんどは Controller クラスの書き換え
- Spring では view にデータを渡す方法がむちゃくちゃある
- 同じ目的を達するなら手段は少ないほうがよいと思う
- ニクリーチが気になりすぎてセッションあまり聞けてない。反省
これで怖くない！？コードリーディングで学ぶ Spring Security
Spring Security の認証・認可の仕組みを、ソースコードをもとに解説する中級者向けセッション。
認証と認可の区別がつく方向けって言ってたけど、わからなかったのでちょこっと調べてみた（http://e-words.jp/w/%E8%AA%8D%E8%A8%BC.html）。
- 認証
- 対象の正当性や真正性を確かめること
- つまり相手が本当に対象としている本人であるかどうかを確認するということ
- 認可
- 認証済みの利用者に対し、アクセス権の設定などを参照して本人に与えられた適切な権限による操作を許可する（権限外の利用を拒否する）こと
- 利用者本人だからといってなんでもできるわけではない
Spring Security は Spring のサブプロジェクトで、認証・認可機能を中心にセキュリティにまつわる様々な機能を提供している。数あるプロダクトの中でもかなり複雑なのだそう。
何重ものサーブレットフィルターで機能を実現していて、本セッションではその中でも重要な以下の５つのフィルターについて解説。
- SecurityContextPersistenceFilter
- セッションに格納していた SecurityContext を ThreadLocal に移す
- LogoutFilter
- ログアウト処理を行う
- UsernamePasswordAuthenticationFilter
- フォーム認証を行う
- ExceptionTranslationFilter
- 発生した例外を受け取ってエラー画面を表示する
- FilterSecurityInterceptor
- アクセス制限を行う
以下気になった発言メモ。
- Spring Security は歴史が長いので API が古いものがある
- 返り値が Object 型のメソッドがあったり（Authentication#getPrincipal とか）
- Twitter でも共感の声がちらほら
- 送られてきた文字列が正しいかどうかの判定において、文字列の比較を途中でやめてはいけない
- レスポンス時間によって、ここまではこの文字列であっているんだなと推測されるのを防ぐため
- 『サイドチャネル攻撃の一種。2018年のお正月に話題になった Meltdown とSpectre もサイドチャネル攻撃の一種ですね』 by 教育係の阿部氏
おわりに
- 弊社では Spring-Retry を使っていないが、めんどくさいリトライ処理をどうやって実装しているか気になった。あとでコード見てみよう
- Spring って歴史が長いしモジュールもたくさんあるので、サーバー開発はこれさえあればなんでもできそう。逆に Spring が提供していない機能は何なんだろう？
- ニクリーチを考えた人は天才に違いない
- 弊社採用面談も肉食べながらがよかったなー
- 弊社でも肉プロジェクトやりましょう
- 全国の肉好きと出会える交流サイト「Meat Up」とか、焼肉屋でエンジニアをつなぐIT勉強会支援プラットフォーム「肉 is 美 (ﾆｸｲｽﾞﾋﾞｰ)」とか
L is B では新たに開発チームに加わってくれるエンジニアを募集しています。
ご興味のあるかたはこちらからご応募いただければと思います。
カジュアル面談もやっておりますので、会社の雰囲気を知りたい or 自分をアピールしたい！というかたもお気軽に遊びに来てくださいね。お待ちしております。
