Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Go + SQS + Fargate で速度、品質、低コストを実現する
Search
Yosuke Tsuchiya
August 26, 2021
Programming
0
1.2k
Go + SQS + Fargate で速度、品質、低コストを実現する
スペースマーケットの予約サービスに必要な性能とコストの最適化という課題を解消すべくGo + SQS + Fargate でシステムをリニューアルしました。
各要素技術に対して課題と効果をご紹介します。
Yosuke Tsuchiya
August 26, 2021
Tweet
Share
Other Decks in Programming
See All in Programming
Learning Ruby
okuramasafumi
5
370
まっちすいっち戦争 / match vs switch
takuyakatsusa
1
630
WasmOS: Wasmを実行する自作Microkernel
riru
0
360
PHPアプリケーションのスケーラビリティと 信頼性を革新する nginx+ngx_mrubyとGoの融合
pyama86
2
220
品質が高いコードって何?Rev2.1
ickx
1
390
Laravel標準バリデーションでできること
hmb_ok
1
330
PHP 8.3で追加されたjson_validate()を徹底的に深掘りしてみよう
mashirou1234
0
630
オープンなデータ・ソフトウェアを活用した開発
404background
0
160
軽率にVue 3で リアルタイム3Dアプリを作れる ライブラリを作ってみた/vue-with-3d-app
drumath2237
3
1.2k
ここ1~2年くらいで 使えるようになった(主要ブラウザーの最新版 がすべて対応した ) ウェブの新機能について ランダムに喋る!
myzkyy
7
5.9k
PHPカンファレンス関西2024でLTとスタッフした
ohmori_yusuke
2
120
CSC308B Lecture 12
javiergs
PRO
0
110
Featured
See All Featured
Building an army of robots
kneath
300
41k
For a Future-Friendly Web
brad_frost
170
8.8k
Designing with Data
zakiwarfel
94
4.8k
Mobile First: as difficult as doing things right
swwweet
215
8.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
4
1.4k
Raft: Consensus for Rubyists
vanstee
130
6.2k
Visualization
eitanlees
135
14k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
226
16k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
28
5.9k
Rebuilding a faster, lazier Slack
samanthasiow
72
8.1k
Into the Great Unknown - MozCon
thekraken
10
810
From Idea to $5000 a Month in 5 Months
shpigford
376
45k
Transcript
Go + SQS + Fargate 速度 品質 低コスト を実現する 2021/8/25
土屋 陽介
2 • バックエンドエンジニア ◦ 開発・保守・インフラ等 • いまレンタルスペースでやりたいこと ◦ 屋上スペースでビアガーデン🍺 自己紹介
土屋 陽介 2019.8 Spacemarket入社
3 1. はじめに結論 2. Go 3. SQS 4. Fargate 5.
まとめ アジェンダ
4 はじめに結論
5 Go + SQS + Fargateのシステム構成にしたことで得られた主な効果 【課題1】プランの変更がカレンダーに反映されるまでにタイムラグがある => ほぼリアルタイムで変更内容をカレンダーに反映 【課題2】稀にプランの変更がカレンダーに反映されていないことがある
=> 日次全件同期により反映漏れにも対応 【課題3】ハイスペックなインスタンスのためコストが高い => 柔軟なスケーリングによりコスト最適化を実現 はじめに結論
6 Go
7 Goの主な特徴 • コンパイラ型言語で処理が高速 • 並列処理が言語レベルでサポートされている ◦ goroutine ◦ channel
• シンプルな文法
8 Goを採用した背景
9 従来の予約導線 ① はじめにプランを選択 ② 予約可能な日時の中から利用したい日時を選択
10 従来のアーキテクチャ オンライン処理で空き状況を計算している => CPU負荷が高く時間がかかる処理だった
11 空き状況の照会を1つのプランではなく全プラン行うという要件が出てきた 新たな予約導線 ① 利用日時を指定 ② 予約可能なプランのみを表示 (全プランの空き状況照会) ③ 予約したいプランを選択
12 従来のアーキテクチャ ひとつのスペースに数十個のプランが存在することも実際にある => 数十倍の計算量になってしまいUXに致命的な影響を与えてしまう...!
13 従来のアーキテクチャ 画面表示に数十秒もかかるサービスを使いたいとは誰も思わない... => ユーザー離れに繋がってしまう
14 事前計算する仕組みに変更 空き状況の照会に必要な情報を事前計算(キャッシュ)するバッチを新設
15 差分更新 バッチを常駐起動し前回処理以降の更新レコードを検出 => カレンダー情報の差分のみを更新 例) 営業時間を変更 変更後の営業時間 前回実行以降に更 新されたレコードが
バッチ処理対象 キャッシュ再構築 キャッシュ更新
16 差分更新 カレンダー同期ジョブ(AWS Batch)を無限ループ 差分を検知 => キャッシュ更新処理 を繰り返す仕組み AWS
Batch Step Function
17 今回の要件にマッチ 求める要件 • キャッシュ作成処理を高速に実行できること • 習得難易度が高くないこと Goの特徴 • コンパイラ型言語で処理が高速
• 並列処理が言語レベルでサポートされている • シンプルな文法 Goを採用した理由
18 Go + キャッシュ方式を採用した結果
19 処理速度の高速化 • オンライン処理の応答性能 ◦ 平均およそ 500 ms から数十 ms
に向上 ◦ 性能テストの結果、平常時トランザクションの約5倍まで劣化なし 学習コスト • 各BEエンジニアがキャッチアップしながらの開発・保守が行えている Go + キャッシュ方式を採用した結果
20 SQS
21 SQSを採用した背景
22 事前計算方式の課題 • 反映されるまでにタイムラグがある ◦ 平均15分 ▪ インスタンス起動時間 ▪ ジョブ間の待機時間
▪ 処理対象がない場合でも5分程のインターバルが発生 • 全件同期がしづらい ◦ 現状の作りだと前の処理が終わらないと次の差分が反映されない ▪ 全件同期を行うと処理対象が大量となるため、全件同期中に発生し た新たな変更については反映されるまでにかなり時間がかかってし まう SQSを使い始めた背景
23 カレンダーに影響がある要素の更新(*)エンドポイントと キャッシュ作成バッチとの間にSQS(キュー)を設置 * 貸出可能時間、特別営業期間 etc... 反映までのタイムラグを少なくする
24 反映までのタイムラグを少なくする カレンダーに影響がある要素が更新(*)された時にほぼリアルタイムで キャッシュが更新されるようになる * プラン料金の変更、貸出可能時間の変更 etc... 営業時間を更新した際に SQSに キューイング
25 カレンダーに影響がある要素が更新(*)された時にほぼリアルタイムで キャッシュが更新されるようになる * プラン料金の変更、貸出可能時間の変更 etc... 反映までのタイムラグを少なくする バッチを常駐起動(Fargate) SQSを常時監視しメッセージをトリガに処理実行
26 全件同期をしやすくする このままの状態で、全件同期するとキューが詰まって差分更新が遅れてしまう 差分更新は優先度が高い(変更された要素) 全件更新は優先度が低い(実際に更新される件数は僅か) SQSは先に入ったものから処理する (FIFOキュー) 高優先を先に処理して欲しいが前が詰まっ ている
27 全件同期をしやすくする 高優先と低優先のキューおよびFargateを設置 Priority Queue Pattern 低優先に大量にキューイングされている場合でも高優先の差分更新は即実行できる
28 SQSを採用した結果
29 SQSを採用した結果 【課題】反映されるまでにタイムラグがある => 変更をほぼリアルタイムでカレンダーに反映 【課題】全件同期がしづらい => 高優先、低優先に分けたことで後続を気にせずに全件同期ができるように なった =>
万が一カレンダーの反映漏れがあっても日次で最新の状態に更新
30 Fargate
31 • 管理が容易 ◦ サーバーレス(EC2インスタンスの管理が不要) ◦ EC2起動タイプと比較すると単価が高い • コスト最適化 ◦
Auto Scaling ◦ Fargate Spot Fargateの特徴
32 Fargateを採用した背景
33 AWS Batch で構築したシステム(再掲) 大量に差分が発生する場合を見越して ハイスペックなインスタンスで並列処理を実行 AWS Batch 処理対象が少なくても大きなインスタンスで実行
=> コスト最適化が課題
34 SQSから一度に取得できるメッセージは最大 10件 NG ハイスペックなインスタンスで並列処理(スペックを活かしきれない) Good 複数の小さなインスタンスで処理実行(適切なスペック・コストで処理) Fargate + SQS で構築したシステム(新) キューのメッセージ数に応じてバッチの処
理能力を増減させたい
35 Auto Scaling メッセージが少ない時 メッセージが多い時 1台 5台 Fargateはスケーリングが容易
36 Auto Scaling 設定 キューが100未満なら1台 キューが100以上なら2台 キューが1000-2100なら3台 ...etc
37 一定の制限付きで格安で使用できるFargate Spotを使用 Fargate Spotの特徴 • AWSクラウドの空きリソースを70%OFFで利用できる • AWS側のリソースが少なくなると許可なくサーバーが落とされる可能性がある スケールアウト時のコストを抑える
38 スケールアウト時のコストを抑える Fargate Spot採用にあたっての留意事項 • べき等性が担保された処理 ◦ サーバーが落ちて処理が中断しても問題ないこと ◦ 再実行すればあるべきデータ状態にリカバリできる
• キャパシティープロバイダー戦略 ◦ 仮に全部のFargate Spotが落ちた場合であってもキャッシュ更新処理が 完全に止まらないように一定割合はFargateを利用
39 キャパシティープロバイダー戦略 Fargate : Fargate Spot = 1 : 5
の割合で使用 最初の1台はFargate 2台目-6台目はFargateSpot 7台目はFargate 8-13台目はFargateSpot ...
40 Fargateを採用した結果
41 Fargateを採用した結果 【課題】ムダなコストがかかってしまっている • 従来の30%もサーバーコストを抑えることができた。 ◦ 必要な分だけインスタンスを起動(Auto Scaling) ◦ Fargate
Spotを利用 • EC2インスタンスの管理が不要 ◦ Auto Scaling を容易に実現 ◦ 管理コストを削減
42 まとめ
43 • Go + キャッシュ方式 ◦ 高速なキャッシュ作成バッチを構築 • SQS ◦
カレンダー反映のタイムラグを解消 ◦ 高優先、低優先を分けることで全件同期を日次で実行できるようになった • Fargate ◦ マネージドサービスのため管理が容易 ◦ コストの最適化 ▪ Auto Scaling ▪ Fargate Spot • サーバーコストを30%削減 まとめ
44 Go + SQS + Fargate 方式のバッチ処理の適用範囲を広げていきたい 従来のRails + AWS
Batch方式のバッチ処理が未だに一部存在 これらには以下のような課題がある • 反映に時間がかかる • インフラコストの最適化の余地がある 今後の展望
ご清聴ありがとうございました。