Kotlin × Spring Boot × DDD のアプリに 非同期処理基盤を導入するまで

Transcript

1. 1 2024.07.18 南部 豪 Kotlin × Spring Boot × DDD のアプリに 非同期処理基盤を導入するまで
2. 2 自己紹介 株式会社ログラス　開発部 エンジニア 南部 豪 / Go Nambu ベンチャー企業2社を経て、2023年9月にログラスに入社 Loglassのマスタ領域を担うチームのリーダー チームでの業務の傍ら、チーム横断的な働き方も行っている。 - E2E基盤の構築・非同期処理基盤の構築 - 新規開発体制のPoC 犬を愛し、犬に愛される(?)男
3. 3 - こちらのテックブログ＋αです - 非同期処理の基盤を作った話です - インフラ・SpringBootの話も多めです - 今後の展望 3 本日お話しすること
4. 4 4 ©2024 Loglass Inc. アジェンダ ③ 開発体験の設計 ④ リリースとその後の課題 ② ⾮同期処理基盤の設計 ⑤ 今後の展望 ① ⾮同期処理基盤導⼊の背景
5. 5 5 ©2024 Loglass Inc. アジェンダ ③ 開発体験の設計 ④ リリースとその後の課題 ② ⾮同期処理基盤の設計 ⑤ 今後の展望 ① ⾮同期処理基盤導⼊の背景
6. 6 ©2023 Loglass Inc. ⾮同期処理が必要とされるとき 画面をブロックせずバックグラウンドで処理をしたい Kotlin Coroutinesで実現可能 Loglassでも用いて実装している箇所もある
7. 7 ©2023 Loglass Inc. ⾮同期処理が必要とされるとき 画面をブロックせずバックグラウンドで処理をしたい Kotlin Coroutinesで実現可能 Loglassでも用いて実装している箇所もある 別で非同期処理基盤は不要なのでは？
8. 8 ©2023 Loglass Inc. 基盤が別で必要な理由 1コンテナに負荷がかかってしまう！！ システムの安定稼働に悪影響
9. 9 9 ©2024 Loglass Inc. アジェンダ ③ 開発体験の設計 ④ リリースとその後の課題 ② ⾮同期処理基盤の設計 ⑤ 今後の展望 ① ⾮同期処理基盤導⼊の背景
10. 10 10 ©2024 Loglass Inc. 要求仕様 • 既存APIとは別のインフラで処理を実行 ◦ インフラ負荷軽減 ◦ アプリの安定稼働 非同期で処理を行う以上の要求仕様 • 処理は並列で実行可能 ◦ 既存のAPIでの実行は並列に行えていたため • 監視を行う ◦ 既存の設計に乗れば可能
11. 11 11 ©2024 Loglass Inc. 設計
12. 12 12 ©2024 Loglass Inc. DDD(オニオンアーキテクチャ)のパワー • 対象処理の実装は既存ユースケースを流用するだけ！ ◦ 処理部分とSQSへのタスク送信部分を分離する ◦ APIはSQSへのタスク送信ユースケースを実行 ◦ Workerは処理部分のユースケースを実行
13. 13 13 ©2024 Loglass Inc. トイルの削減 高負荷などが理由で処理が途中で止まる DBの実行ステータスが実行中のまま 実行中ステータスだと再実行できない エンジニアがDBに入りステータスを更新する 手が震える作業・・・
14. 14 14 ©2024 Loglass Inc. トイルの削減 高負荷などが理由で処理が途中で止まる DBの実行ステータスが実行中のまま 実行中ステータスだと再実行できない エンジニアがDBに入りステータスを更新する 勝手にステータスをエラーに倒す！ 手が震える作業・・・
15. 15 15 ©2024 Loglass Inc. Spring Cloud AWS • 既存APIからSQSにタスクを送信する
 • WorkerでSQSをポーリングする

16. 16 16 ©2024 Loglass Inc. Queueへの送信 sqsTemplate.send { to -> to.queue("my-queue-name").payload(workerTask).headers(headers) }
17. 17 17 ©2024 Loglass Inc. Queueのポーリング acknowledgeModeを指定することも可能 - 成功したら削除 - 常に削除 アノテーション指定
18. 18 18 ©2024 Loglass Inc. アジェンダ ③ 開発体験の設計 ④ リリースとその後の課題 ② ⾮同期処理基盤の設計 ⑤ 今後の展望 ① ⾮同期処理基盤導⼊の背景
19. 19 19 ©2024 Loglass Inc. 開発体験を阻害しうる2⼤要素 • トランザクションを張る ◦ @Transactionalで解決 阻害とは？ →処理を追加するために必ず実装しないといけないが、扱いが難しい • RowLevelSecurity(RLS)を突破する ◦ APIと同じ解決はできない ◦ 認証情報を持っていないため
20. 20 20 ©2024 Loglass Inc. 開発体験を阻害しうる2⼤要素 • トランザクションを張る ◦ @Transactionalで解決 阻害とは？ →処理を追加するために必ず実装しないといけないが、扱いが難しい • RowLevelSecurity(RLS)を突破する ◦ APIと同じ解決はできない ◦ 認証情報を持っていないため
21. 21 21 ©2024 Loglass Inc. RLSとは？ テーブル内の行へのアクセスを制御する機能
 テナント間の情報漏洩が防げる • 暗黙的にwhere句が追加されたような動作になる • マルチテナントのDBに有効
22. 22 22 ©2024 Loglass Inc. 既存APIのRLS突破 ユースケース層に必ず@Transactionalが付与される →@TransactionalめがけてAOPしてクエリを発行する RLSを突破するためのクエリ SET LOCAL app.current_tenant = '${tenantId.value}'
23. 23 23 ©2024 Loglass Inc. ⾮同期処理基盤でどのように突破するか ポーリングのために付与 ここでTenantIdを保持したい Transactionを張るために付与 AOPでクエリを発行 トランザクションを張るタイミングで、 TenantIdがどこかから取得できればよい ThreadLocalを用いる
24. 24 24 ©2024 Loglass Inc. 開発体験としてRLSを意識しないために TenantIdが必ず実行時の引数に入る RLS突破はAOPにのるので実装不要
25. 25 25 ©2024 Loglass Inc. アジェンダ ③ 開発体験の設計 ④ リリースとその後の課題 ② ⾮同期処理基盤の設計 ⑤ 今後の展望 ① ⾮同期処理基盤導⼊の背景
26. 26 26 ©2024 Loglass Inc. テスト 処理自体をテストし直す必要はない • 既存APIはタスクをSQSに投げるだけとなる 
 • 投げる直前に、排他制御のためにDBの実行ステータスを更新する 
 • タスクを実行してから処理されるまでにタイムラグが発生する 
 • その間に実行タスクの設定が変更されうる 
 • WorkerがSQSからタスクを受け取って処理する 
 • 異常終了した場合にはDLQにタスクが移動する 
 • 移動後、実行ステータスがエラーになる処理が走 る
 処理差分
27. 27 27 ©2024 Loglass Inc. リリース⽅法 FTを使用 同期・非同期を簡単に切り替え可能に • デプロイとロールアウトを分割できる ◦ リリース時はFT更新のみ • 本番検証用テナントで検証できる • 問題ありのときもFT更新のみ
28. 28 28 ©2024 Loglass Inc. リリース後に発⽣した問題 なぜか処理が失敗する・・・・ 処理中のタスクの取得に失敗していることが判明 →まだ処理中になっていないうちに処理が実行されている これはCommit後にやるべき 排他制御を別クラスに切り出して DIする
29. 29 29 ©2024 Loglass Inc. 今後の展望 • 開発組織への伝搬 ◦ ドキュメントの作成 • 別の処理も基盤に乗せる ◦ 現状5つの処理が移行済み • 1タスク1コンテナでオンデマンド実行 ◦ ネイティブイメージビルドを用いる • より安全なリリース方法 ◦ 現状は、killされてしまう可能性