Go + SQS + Fargate で速度、品質、低コストを実現する

スペースマーケットの予約サービスに必要な性能とコストの最適化という課題を解消すべくGo + SQS + Fargate でシステムをリニューアルしました。
各要素技術に対して課題と効果をご紹介します。

Transcript

1. Go + SQS + Fargate 速度 品質 低コスト を実現する 2021/8/25 土屋 陽介
2. 2 • バックエンドエンジニア ◦ 開発・保守・インフラ等 • いまレンタルスペースでやりたいこと ◦ 屋上スペースでビアガーデン🍺 自己紹介 土屋 陽介 2019.8 Spacemarket入社
3. 3 1. はじめに結論 2. Go 3. SQS 4. Fargate 5. まとめ アジェンダ
4. 4 はじめに結論
5. 5 Go + SQS + Fargateのシステム構成にしたことで得られた主な効果 【課題１】プランの変更がカレンダーに反映されるまでにタイムラグがある 　　=> ほぼリアルタイムで変更内容をカレンダーに反映 【課題２】稀にプランの変更がカレンダーに反映されていないことがある 　　=> 日次全件同期により反映漏れにも対応 【課題３】ハイスペックなインスタンスのためコストが高い => 柔軟なスケーリングによりコスト最適化を実現 はじめに結論
6. 6 Go
7. 7 Goの主な特徴 • コンパイラ型言語で処理が高速 • 並列処理が言語レベルでサポートされている ◦ goroutine ◦ channel • シンプルな文法
8. 8 Goを採用した背景
9. 9 従来の予約導線 ① はじめにプランを選択 ② 予約可能な日時の中から利用したい日時を選択
10. 10 従来のアーキテクチャ オンライン処理で空き状況を計算している 　=> CPU負荷が高く時間がかかる処理だった
11. 11 空き状況の照会を1つのプランではなく全プラン行うという要件が出てきた 新たな予約導線 ① 利用日時を指定 ② 予約可能なプランのみを表示 （全プランの空き状況照会） ③ 予約したいプランを選択
12. 12 従来のアーキテクチャ ひとつのスペースに数十個のプランが存在することも実際にある 　=> 数十倍の計算量になってしまいUXに致命的な影響を与えてしまう...！
13. 13 従来のアーキテクチャ 画面表示に数十秒もかかるサービスを使いたいとは誰も思わない... => ユーザー離れに繋がってしまう
14. 14 事前計算する仕組みに変更 空き状況の照会に必要な情報を事前計算（キャッシュ）するバッチを新設
15. 15 差分更新 バッチを常駐起動し前回処理以降の更新レコードを検出 　=> カレンダー情報の差分のみを更新 例） 営業時間を変更 変更後の営業時間 前回実行以降に更 新されたレコードが バッチ処理対象 キャッシュ再構築 キャッシュ更新
16. 16 差分更新 
 カレンダー同期ジョブ（AWS Batch）を無限ループ 差分を検知 => キャッシュ更新処理 を繰り返す仕組み AWS Batch Step Function
17. 17 今回の要件にマッチ 求める要件 • キャッシュ作成処理を高速に実行できること • 習得難易度が高くないこと Goの特徴 • コンパイラ型言語で処理が高速 • 並列処理が言語レベルでサポートされている • シンプルな文法 Goを採用した理由
18. 18 Go + キャッシュ方式を採用した結果
19. 19 処理速度の高速化 • オンライン処理の応答性能 ◦ 平均およそ 500 ms から数十 ms に向上 ◦ 性能テストの結果、平常時トランザクションの約5倍まで劣化なし 学習コスト • 各BEエンジニアがキャッチアップしながらの開発・保守が行えている Go + キャッシュ方式を採用した結果
20. 20 SQS
21. 21 SQSを採用した背景
22. 22 事前計算方式の課題 • 反映されるまでにタイムラグがある ◦ 平均15分 ▪ インスタンス起動時間 ▪ ジョブ間の待機時間 ▪ 処理対象がない場合でも5分程のインターバルが発生 • 全件同期がしづらい ◦ 現状の作りだと前の処理が終わらないと次の差分が反映されない ▪ 全件同期を行うと処理対象が大量となるため、全件同期中に発生し た新たな変更については反映されるまでにかなり時間がかかってし まう SQSを使い始めた背景
23. 23 カレンダーに影響がある要素の更新(*)エンドポイントと キャッシュ作成バッチとの間にSQS（キュー）を設置 * 貸出可能時間、特別営業期間 etc... 反映までのタイムラグを少なくする
24. 24 反映までのタイムラグを少なくする
 カレンダーに影響がある要素が更新(*)された時にほぼリアルタイムで キャッシュが更新されるようになる * プラン料金の変更、貸出可能時間の変更 etc... 営業時間を更新した際に SQSに キューイング
25. 25 カレンダーに影響がある要素が更新(*)された時にほぼリアルタイムで キャッシュが更新されるようになる * プラン料金の変更、貸出可能時間の変更 etc... 反映までのタイムラグを少なくする
 バッチを常駐起動（Fargate） SQSを常時監視しメッセージをトリガに処理実行
26. 26 全件同期をしやすくする このままの状態で、全件同期するとキューが詰まって差分更新が遅れてしまう 差分更新は優先度が高い（変更された要素） 全件更新は優先度が低い（実際に更新される件数は僅か） SQSは先に入ったものから処理する （FIFOキュー） 高優先を先に処理して欲しいが前が詰まっ ている
27. 27 全件同期をしやすくする 
 高優先と低優先のキューおよびFargateを設置 　　Priority Queue Pattern 低優先に大量にキューイングされている場合でも高優先の差分更新は即実行できる
28. 28 SQSを採用した結果
29. 29 SQSを採用した結果 【課題】反映されるまでにタイムラグがある 　　=> 変更をほぼリアルタイムでカレンダーに反映 【課題】全件同期がしづらい => 高優先、低優先に分けたことで後続を気にせずに全件同期ができるように なった 　　=> 万が一カレンダーの反映漏れがあっても日次で最新の状態に更新
30. 30 Fargate
31. 31 • 管理が容易 ◦ サーバーレス（EC2インスタンスの管理が不要） ◦ EC2起動タイプと比較すると単価が高い • コスト最適化 ◦ Auto Scaling ◦ Fargate Spot Fargateの特徴
32. 32 Fargateを採用した背景
33. 33 AWS Batch で構築したシステム（再掲） 
 大量に差分が発生する場合を見越して ハイスペックなインスタンスで並列処理を実行 AWS Batch 処理対象が少なくても大きなインスタンスで実行 => コスト最適化が課題
34. 34 SQSから一度に取得できるメッセージは最大 10件 　NG　　ハイスペックなインスタンスで並列処理（スペックを活かしきれない） 　Good　複数の小さなインスタンスで処理実行（適切なスペック・コストで処理） Fargate + SQS で構築したシステム（新）
 キューのメッセージ数に応じてバッチの処 理能力を増減させたい
35. 35 Auto Scaling メッセージが少ない時 メッセージが多い時 1台 5台 Fargateはスケーリングが容易
36. 36 Auto Scaling 設定 キューが100未満なら1台 キューが100以上なら2台 キューが1000-2100なら3台 ...etc
37. 37 一定の制限付きで格安で使用できるFargate Spotを使用 Fargate Spotの特徴 • AWSクラウドの空きリソースを70%OFFで利用できる • AWS側のリソースが少なくなると許可なくサーバーが落とされる可能性がある スケールアウト時のコストを抑える
38. 38 スケールアウト時のコストを抑える Fargate Spot採用にあたっての留意事項 • べき等性が担保された処理 ◦ サーバーが落ちて処理が中断しても問題ないこと ◦ 再実行すればあるべきデータ状態にリカバリできる • キャパシティープロバイダー戦略 ◦ 仮に全部のFargate Spotが落ちた場合であってもキャッシュ更新処理が 完全に止まらないように一定割合はFargateを利用
39. 39 キャパシティープロバイダー戦略 Fargate : Fargate Spot = 1 : 5 の割合で使用 最初の1台はFargate 2台目-6台目はFargateSpot 7台目はFargate 8-13台目はFargateSpot ...
40. 40 Fargateを採用した結果
41. 41 Fargateを採用した結果 【課題】ムダなコストがかかってしまっている • 従来の30%もサーバーコストを抑えることができた。 ◦ 必要な分だけインスタンスを起動（Auto Scaling） ◦ Fargate Spotを利用 • EC2インスタンスの管理が不要 ◦ Auto Scaling を容易に実現 ◦ 管理コストを削減
42. 42 まとめ
43. 43 • Go + キャッシュ方式 ◦ 高速なキャッシュ作成バッチを構築 • SQS ◦ カレンダー反映のタイムラグを解消 ◦ 高優先、低優先を分けることで全件同期を日次で実行できるようになった • Fargate ◦ マネージドサービスのため管理が容易 ◦ コストの最適化 ▪ Auto Scaling ▪ Fargate Spot • サーバーコストを30%削減 まとめ
44. 44 Go + SQS + Fargate 方式のバッチ処理の適用範囲を広げていきたい 従来のRails + AWS Batch方式のバッチ処理が未だに一部存在 これらには以下のような課題がある • 反映に時間がかかる • インフラコストの最適化の余地がある 今後の展望
45. 　ご清聴ありがとうございました。