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

by Yosuke Tsuchiya

Slide 1

Slide 1 text

Go + SQS + Fargate 速度品質低コストを実現する 2021/8/25 土屋陽介

Slide 2

Slide 2 text

2 ● バックエンドエンジニア ○ 開発・保守・インフラ等 ● いまレンタルスペースでやりたいこと ○ 屋上スペースでビアガーデン🍺 自己紹介土屋陽介 2019.8 Spacemarket入社

Slide 3

Slide 3 text

3 1. はじめに結論 2. Go 3. SQS 4. Fargate 5. まとめアジェンダ

Slide 4

Slide 4 text

4 はじめに結論

Slide 5

Slide 5 text

5 Go + SQS + Fargateのシステム構成にしたことで得られた主な効果【課題１】プランの変更がカレンダーに反映されるまでにタイムラグがある　　=> ほぼリアルタイムで変更内容をカレンダーに反映【課題２】稀にプランの変更がカレンダーに反映されていないことがある　　=> 日次全件同期により反映漏れにも対応【課題３】ハイスペックなインスタンスのためコストが高い => 柔軟なスケーリングによりコスト最適化を実現はじめに結論

Slide 6

Slide 6 text

6 Go

Slide 7

Slide 7 text

7 Goの主な特徴 ● コンパイラ型言語で処理が高速 ● 並列処理が言語レベルでサポートされている ○ goroutine ○ channel ● シンプルな文法

Slide 8

Slide 8 text

8 Goを採用した背景

Slide 9

Slide 9 text

9 従来の予約導線 ① はじめにプランを選択 ② 予約可能な日時の中から利用したい日時を選択

Slide 10

Slide 10 text

10 従来のアーキテクチャオンライン処理で空き状況を計算している　=> CPU負荷が高く時間がかかる処理だった

Slide 11

Slide 11 text

11 空き状況の照会を1つのプランではなく全プラン行うという要件が出てきた新たな予約導線 ① 利用日時を指定 ② 予約可能なプランのみを表示（全プランの空き状況照会） ③ 予約したいプランを選択

Slide 12

Slide 12 text

12 従来のアーキテクチャひとつのスペースに数十個のプランが存在することも実際にある　=> 数十倍の計算量になってしまいUXに致命的な影響を与えてしまう...！

Slide 13

Slide 13 text

13 従来のアーキテクチャ画面表示に数十秒もかかるサービスを使いたいとは誰も思わない... => ユーザー離れに繋がってしまう

Slide 14

Slide 14 text

14 事前計算する仕組みに変更空き状況の照会に必要な情報を事前計算（キャッシュ）するバッチを新設

Slide 15

Slide 15 text

15 差分更新バッチを常駐起動し前回処理以降の更新レコードを検出　=> カレンダー情報の差分のみを更新例）営業時間を変更変更後の営業時間前回実行以降に更新されたレコードがバッチ処理対象キャッシュ再構築キャッシュ更新

Slide 16

Slide 16 text

16 差分更新   カレンダー同期ジョブ（AWS Batch）を無限ループ差分を検知 => キャッシュ更新処理を繰り返す仕組み AWS Batch Step Function

Slide 17

Slide 17 text

17 今回の要件にマッチ求める要件 ● キャッシュ作成処理を高速に実行できること ● 習得難易度が高くないこと Goの特徴 ● コンパイラ型言語で処理が高速 ● 並列処理が言語レベルでサポートされている ● シンプルな文法 Goを採用した理由

Slide 18

Slide 18 text

18 Go + キャッシュ方式を採用した結果

Slide 19

Slide 19 text

19 処理速度の高速化 ● オンライン処理の応答性能 ○ 平均およそ 500 ms から数十 ms に向上 ○ 性能テストの結果、平常時トランザクションの約5倍まで劣化なし学習コスト ● 各BEエンジニアがキャッチアップしながらの開発・保守が行えている Go + キャッシュ方式を採用した結果

Slide 20

Slide 20 text

20 SQS

Slide 21

Slide 21 text

21 SQSを採用した背景

Slide 22

Slide 22 text

22 事前計算方式の課題 ● 反映されるまでにタイムラグがある ○ 平均15分 ■ インスタンス起動時間 ■ ジョブ間の待機時間 ■ 処理対象がない場合でも5分程のインターバルが発生 ● 全件同期がしづらい ○ 現状の作りだと前の処理が終わらないと次の差分が反映されない ■ 全件同期を行うと処理対象が大量となるため、全件同期中に発生した新たな変更については反映されるまでにかなり時間がかかってしまう SQSを使い始めた背景

Slide 23

Slide 23 text

23 カレンダーに影響がある要素の更新(*)エンドポイントとキャッシュ作成バッチとの間にSQS（キュー）を設置 * 貸出可能時間、特別営業期間 etc... 反映までのタイムラグを少なくする

Slide 24

Slide 24 text

24 反映までのタイムラグを少なくする  カレンダーに影響がある要素が更新(*)された時にほぼリアルタイムでキャッシュが更新されるようになる * プラン料金の変更、貸出可能時間の変更 etc... 営業時間を更新した際に SQSにキューイング

Slide 25

Slide 25 text

25 カレンダーに影響がある要素が更新(*)された時にほぼリアルタイムでキャッシュが更新されるようになる * プラン料金の変更、貸出可能時間の変更 etc... 反映までのタイムラグを少なくする  バッチを常駐起動（Fargate） SQSを常時監視しメッセージをトリガに処理実行

Slide 26

Slide 26 text

26 全件同期をしやすくするこのままの状態で、全件同期するとキューが詰まって差分更新が遅れてしまう差分更新は優先度が高い（変更された要素）全件更新は優先度が低い（実際に更新される件数は僅か） SQSは先に入ったものから処理する（FIFOキュー）高優先を先に処理して欲しいが前が詰まっている

Slide 27

Slide 27 text

27 全件同期をしやすくする   高優先と低優先のキューおよびFargateを設置　　Priority Queue Pattern 低優先に大量にキューイングされている場合でも高優先の差分更新は即実行できる

Slide 28

Slide 28 text

28 SQSを採用した結果

Slide 29

Slide 29 text

29 SQSを採用した結果【課題】反映されるまでにタイムラグがある　　=> 変更をほぼリアルタイムでカレンダーに反映【課題】全件同期がしづらい => 高優先、低優先に分けたことで後続を気にせずに全件同期ができるようになった　　=> 万が一カレンダーの反映漏れがあっても日次で最新の状態に更新

Slide 30

Slide 30 text

30 Fargate

Slide 31

Slide 31 text

31 ● 管理が容易 ○ サーバーレス（EC2インスタンスの管理が不要） ○ EC2起動タイプと比較すると単価が高い ● コスト最適化 ○ Auto Scaling ○ Fargate Spot Fargateの特徴

Slide 32

Slide 32 text

32 Fargateを採用した背景

Slide 33

Slide 33 text

33 AWS Batch で構築したシステム（再掲）   大量に差分が発生する場合を見越してハイスペックなインスタンスで並列処理を実行 AWS Batch 処理対象が少なくても大きなインスタンスで実行 => コスト最適化が課題

Slide 34

Slide 34 text

34 SQSから一度に取得できるメッセージは最大 10件　NG　　ハイスペックなインスタンスで並列処理（スペックを活かしきれない）　Good　複数の小さなインスタンスで処理実行（適切なスペック・コストで処理） Fargate + SQS で構築したシステム（新）  キューのメッセージ数に応じてバッチの処理能力を増減させたい

Slide 35

Slide 35 text

35 Auto Scaling メッセージが少ない時メッセージが多い時 1台 5台 Fargateはスケーリングが容易

Slide 36

Slide 36 text

36 Auto Scaling 設定キューが100未満なら1台キューが100以上なら2台キューが1000-2100なら3台 ...etc

Slide 37

Slide 37 text

37 一定の制限付きで格安で使用できるFargate Spotを使用 Fargate Spotの特徴 ● AWSクラウドの空きリソースを70%OFFで利用できる ● AWS側のリソースが少なくなると許可なくサーバーが落とされる可能性があるスケールアウト時のコストを抑える

Slide 38

Slide 38 text

38 スケールアウト時のコストを抑える Fargate Spot採用にあたっての留意事項 ● べき等性が担保された処理 ○ サーバーが落ちて処理が中断しても問題ないこと ○ 再実行すればあるべきデータ状態にリカバリできる ● キャパシティープロバイダー戦略 ○ 仮に全部のFargate Spotが落ちた場合であってもキャッシュ更新処理が完全に止まらないように一定割合はFargateを利用

Slide 39

Slide 39 text

39 キャパシティープロバイダー戦略 Fargate : Fargate Spot = 1 : 5 の割合で使用最初の1台はFargate 2台目-6台目はFargateSpot 7台目はFargate 8-13台目はFargateSpot ...

Slide 40

Slide 40 text

40 Fargateを採用した結果

Slide 41

Slide 41 text

41 Fargateを採用した結果【課題】ムダなコストがかかってしまっている ● 従来の30%もサーバーコストを抑えることができた。 ○ 必要な分だけインスタンスを起動（Auto Scaling） ○ Fargate Spotを利用 ● EC2インスタンスの管理が不要 ○ Auto Scaling を容易に実現 ○ 管理コストを削減

Slide 42

Slide 42 text

42 まとめ

Slide 43

Slide 43 text

43 ● Go + キャッシュ方式 ○ 高速なキャッシュ作成バッチを構築 ● SQS ○ カレンダー反映のタイムラグを解消 ○ 高優先、低優先を分けることで全件同期を日次で実行できるようになった ● Fargate ○ マネージドサービスのため管理が容易 ○ コストの最適化 ■ Auto Scaling ■ Fargate Spot ● サーバーコストを30%削減まとめ

Slide 44

Slide 44 text

44 Go + SQS + Fargate 方式のバッチ処理の適用範囲を広げていきたい従来のRails + AWS Batch方式のバッチ処理が未だに一部存在これらには以下のような課題がある ● 反映に時間がかかる ● インフラコストの最適化の余地がある今後の展望

Slide 45

Slide 45 text

　ご清聴ありがとうございました。