重い処理をLambdaに逃してAPIサーバ本体を守ったぞ

# 秋のSRE談義

## 概要
AIで変わりゆくエンジニアの仕事が増えていく中、変わらない仕事もある。
そんな話を「重い処理をLambdaに逃す」という改善事例の紹介とともに語ってみました。

Transcript

1. © Dress Code Inc . All rights reserved. Dress Code株式会社 / Product & Technology 西銘 承太郎（じょじょ） 1 重い処理をLambdaに逃して APIサーバ本体を守ったぞ
2. © Dress Code Inc . All rights reserved. 先日 Platform Engineering Kaigiに スポンサー参加しました 2
3. © Dress Code Inc . All rights reserved. 3 AIによってエンジニアリングが どう変わるか、変わらないかのアンケートをとりました
4. © Dress Code Inc . All rights reserved. AIで変わるものがたくさんある中で 「変わらないもの」 に印象的なものがありました 4
5. © Dress Code Inc . All rights reserved. 「リソース勝負」 「意思決定・責任」 5
6. © Dress Code Inc . All rights reserved. この言葉を今回の内容に絡めて 話そうと思います 6
7. © Dress Code Inc . All rights reserved. 7 今日伝えたいこと ベストに囚われず、 ベターを選択しよう
8. © Dress Code Inc . All rights reserved. では本題です 8
9. © Dress Code Inc . All rights reserved. 入社初日に任されたタスクは 重い処理をいい感じにすることでした 9
10. © Dress Code Inc . All rights reserved. 重い処理 = 10
11. © Dress Code Inc . All rights reserved. 重い処理 = スクレイピングによる 外部サービスの認証処理 11
12. © Dress Code Inc . All rights reserved. 12 弊社には外部サービス連携管理機能があります
13. © Dress Code Inc . All rights reserved. 13 弊社には外部サービス連携管理機能があります 外部サービスの仕様変更に対応するため、 スクレイピングが必要になりました！
14. © Dress Code Inc . All rights reserved. 14 弊社には外部サービス連携管理機能があります スクレイピング処理の実装自体は 前任の方が残してくれていたので、 タスクとしては「良い感じに」することでした
15. © Dress Code Inc . All rights reserved. 弊社プロダクトは 現在ほぼ全ての機能が同じAPIサーバで 動いてます 15
16. © Dress Code Inc . All rights reserved. 前任の方が残した実装は APIサーバ本体にスクレイピング処理を 実装したものでした 16
17. © Dress Code Inc . All rights reserved. これにはどんな 課題とリスクがあるか？ 17
18. © Dress Code Inc . All rights reserved. 課題とリスク 18
19. © Dress Code Inc . All rights reserved. 課題とリスク ⚠ イメージサイズの増加（ビルドが重い） 19
20. © Dress Code Inc . All rights reserved. 課題とリスク ⚠ イメージサイズの増加（ビルドが重い） • イメージプル/プッシュに時間がかかり、CI/CDの遅延につながる • 依存ライブラリが増えると脆弱性検知の範囲が広がり、アップデート負荷増 • ECR/GCRなどのレジストリの保管コスト増 • 大きなイメージはキャッシュ効率が悪く、ネットワーク不調時に失敗しやすい 20
21. © Dress Code Inc . All rights reserved. 課題とリスク ⚠ イメージサイズの増加（ビルドが重い） 🚨 メモリ使用量・CPU使用率の増加（処理が重い） • イメージプル/プッシュに時間がかかり、CI/CDの遅延につながる • 依存ライブラリが増えると脆弱性検知の範囲が広がり、アップデート負荷増 • ECR/GCRなどのレジストリの保管コスト増 • 大きなイメージはキャッシュ効率が悪く、ネットワーク不調時に失敗しやすい 21
22. © Dress Code Inc . All rights reserved. 課題とリスク ⚠ イメージサイズの増加（ビルドが重い） 🚨 メモリ使用量・CPU使用率の増加（処理が重い） • イメージプル/プッシュに時間がかかり、CI/CDの遅延につながる • 依存ライブラリが増えると脆弱性検知の範囲が広がり、アップデート負荷増 • ECR/GCRなどのレジストリの保管コスト増 • 大きなイメージはキャッシュ効率が悪く、ネットワーク不調時に失敗しやすい • 実行時にメモリ上限を超えるとPod/タスクが落ちてAPI全体がエラーになるリスク • ECSで必要メモリが増え、タスク数やインスタンスタイプの単価が上がる • スクレイピング処理がCPUを専有し、通常APIのレスポンスが遅延 • オートスケールが暴発して過剰なスケールによるコスト増 • etc… 22
23. © Dress Code Inc . All rights reserved. APIサーバ本体に置くのは 危ない！！ 23
24. © Dress Code Inc . All rights reserved. そこで取った手段がこちら 24
25. © Dress Code Inc . All rights reserved. 重い処理をLambdaに逃して APIサーバ本体を守ったぞ 25
26. © Dress Code Inc . All rights reserved. 解決案 APIサーバ本体に集約されたスクレイピング処理を 26
27. © Dress Code Inc . All rights reserved. 解決案 APIサーバ本体に集約されたスクレイピング処理をLambdaに移行 • ECSからAWS SDK経由でLambda呼び出し • AIで2,3日で実装！ 27
28. © Dress Code Inc . All rights reserved. AIで本当に実装が楽になった 28
29. © Dress Code Inc . All rights reserved. でもこの構成、良いのか？ 29
30. © Dress Code Inc . All rights reserved. ECSから直接Lambdaを呼ぶことのリスク 30
31. © Dress Code Inc . All rights reserved. ECSから直接Lambdaを呼ぶことのリスク • Lambda側の制限 ◦ 同時実行数制限(アカウント全体で1000) ◦ リクエストレート制限(数千リクエスト/秒) ◦ Lambdaコールドスタートなどによるレイテンシ増加 31
32. © Dress Code Inc . All rights reserved. ECSから直接Lambdaを呼ぶことのリスク • Lambda側の制限 ◦ 同時実行数制限(アカウント全体で1000) ◦ リクエストレート制限(数千リクエスト/秒) ◦ Lambdaコールドスタートなどによるレイテンシ増加 • ECS(Fargate)側の制限 ◦ スレッド、ソケット数の枯渇リスク ◦ 疎通失敗時にAWS SDK内部のリトライによるCPU/メモリ圧迫リスク • etc… 32
33. © Dress Code Inc . All rights reserved. ECSから直接Lambdaを呼ぶことのリスク • Lambda側の制限 ◦ 同時実行数制限(アカウント全体で1000) ◦ リクエストレート制限(数千リクエスト/秒) ◦ Lambdaコールドスタートなどによるレイテンシ増加 • ECS(Fargate)側の制限 ◦ スレッド、ソケット数の枯渇リスク ◦ 疎通失敗時にAWS SDK内部のリトライによるCPU/メモリ圧迫リスク • etc… 33 正直、ベストな選択肢とは思ってません。。。
34. © Dress Code Inc . All rights reserved. ではなぜこれにしたのか？ 34
35. © Dress Code Inc . All rights reserved. ベストではないが ベターな選択肢だったんです 35
36. © Dress Code Inc . All rights reserved. 検討案1: 非同期処理 36 非同期処理でスマートに実装したらええやん →同期呼び出しを非同期化して通知まで整えるのは工数もスコープもオーバー
37. © Dress Code Inc . All rights reserved. 検討案2: 専用サーバ 37 工数削減したいなら新しくAPIサーバ建ててコピーしたらええやん →現状1ヶ月に数回の低頻度なユースケースに対してランニングコストが高過ぎる
38. © Dress Code Inc . All rights reserved. お？ 38
39. © Dress Code Inc . All rights reserved. そう、今回の処理 呼び出されるのは低頻度なんです 39
40. © Dress Code Inc . All rights reserved. 先ほどお伝えした ECSから直接Lambdaを呼び出すリスク 実は低頻度ならリスクはほぼありません 40
41. © Dress Code Inc . All rights reserved. 検討案3: 今回の採用案 41 ECSからLambda直呼び出しのリスクは数百リクエスト/秒程度から顕在化 →今は低頻度だしリスクは許容範囲内！
42. © Dress Code Inc . All rights reserved. こうしてベターな選択肢で APIサーバ本体を守りました 42
43. © Dress Code Inc . All rights reserved. ちなみに 43
44. © Dress Code Inc . All rights reserved. 今回の判断はADRに残し、 将来負債化してもチームで 返済しやすい状態にしてます 44
45. © Dress Code Inc . All rights reserved. 45 ADRについて弊社いっぱい語ってますので是非
46. © Dress Code Inc . All rights reserved. 46 まとめ
47. © Dress Code Inc . All rights reserved. 様々な手段を並べて検討すると 実はベストだけが 正解じゃないことがわかる 47
48. © Dress Code Inc . All rights reserved. AIで実装や ベストプラクティスの調査が 早くできるようになったが 48
49. © Dress Code Inc . All rights reserved. 事業フェーズを考慮して ベターな選択を考えるのは まだまだエンジニアの仕事！ 49
50. © Dress Code Inc . All rights reserved. 「リソース勝負」 「意思決定・責任」 50 この経験とアンケートのこの言葉に つながりを感じたので語ってみました
51. © Dress Code Inc . All rights reserved. 51 今日伝えたいこと ベストに囚われず、 ベターを選択しよう
52. © Dress Code Inc . All rights reserved. 52 ご清聴ありがとうございました！！！
53. © Dress Code Inc . All rights reserved. 53 宣伝
54. © Dress Code Inc . All rights reserved. 54 一緒にプロダクト開発しようぜ！ • プロダクトマネージャー • コミュニケーションデザイナー • デジタルプロダクトデザイナー • デザインエンジニア • プロダクトエンジニア • etc… 新しいオフィスにも移転しています！