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
サーバーレスアーキテクチャにおける AWS と SaaS を活用しての スパイクアクセス対策
Search
Kazuki Miura
PRO
September 28, 2023
Technology
0
500
サーバーレスアーキテクチャにおける AWS と SaaS を活用しての スパイクアクセス対策
#jawsug #jawsug_sapporo
#serverdays2023 の再演です
Kazuki Miura
PRO
September 28, 2023
Tweet
Share
More Decks by Kazuki Miura
See All by Kazuki Miura
完全未経験からAWSと共に セキュリティに立ち向かった半生
miu_crescent
PRO
0
78
Stripe Terminal を触ってみた!!
miu_crescent
PRO
0
49
アクシズを探せ! 各勢力の位置関係についての考察
miu_crescent
PRO
1
41
地方だからできた! 東北でのAWS事例を一挙紹介!#地方だからできる
miu_crescent
PRO
0
22
APIからデータベースまで、全てサーバレスで作ってみよう!
miu_crescent
PRO
0
12
「フィニッシャーズ・スマイル」の開発と当日運用のお話
miu_crescent
PRO
2
93
AWS Systems Manager Incident Manager 使い所を考えてみた
miu_crescent
PRO
0
21
「入門 OpenTelemetry」 入門
miu_crescent
PRO
1
75
AZ 名とAZ ID の違いを 何度でも言うよ
miu_crescent
PRO
1
240
Other Decks in Technology
See All in Technology
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
14
82k
AI時代、“平均値”ではいられない
uhyo
8
2.8k
ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう
sansantech
PRO
1
550
個人でデジタル庁の デザインシステムをVue.jsで 作っている話
nishiharatsubasa
3
5.2k
プレイドのユニークな技術とインターンのリアル
plaidtech
PRO
1
510
20251027_マルチエージェントとは
almondo_event
1
480
入院医療費算定業務をAIで支援する:包括医療費支払い制度とDPCコーディング (公開版)
hagino3000
0
120
データとAIで明らかになる、私たちの課題 ~Snowflake MCP,Salesforce MCPに触れて~ / Data and AI Insights
kaonavi
0
160
RemoteFunctionを使ったコロケーション
mkazutaka
1
150
CNCFの視点で捉えるPlatform Engineering - 最新動向と展望 / Platform Engineering from the CNCF Perspective
hhiroshell
0
140
SRE × マネジメントレイヤーが挑戦した組織・会社のオブザーバビリティ改革 ― ビジネス価値と信頼性を両立するリアルな挑戦
coconala_engineer
0
300
現場の壁を乗り越えて、 「計装注入」が拓く オブザーバビリティ / Beyond the Field Barriers: Instrumentation Injection and the Future of Observability
aoto
PRO
1
700
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.7k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
Agile that works and the tools we love
rasmusluckow
331
21k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
How GitHub (no longer) Works
holman
315
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
253
22k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.7k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Transcript
サーバーレスアーキテクチャにおける AWS と SaaS を活用しての スパイクアクセス対策 三浦一樹 北海道テレビ放送株式会社 2023/09/28
@shimagaji 無念の欠席
代打登壇!
資料がない!
先週の使い回し
serverless days のほぼ再演です
自己紹介 三浦一樹 北海道テレビ放送株式会社 Sonu Kim 株式会社Serverless Operations
放送に関することは いっさい仕事でやってません!
サービス紹介
2012年4月 サービス開始 前身のサービス PaaS を採用 フロントの改修が大変 スパイクに耐えられない 他の自社サービスとデータ連携できない 10 年も経つと課題が、、
2つサービスの開発運用 2022 年 3 月〜 2022 年 4 月〜 フルスクラッチ
AWS サーバレスで
サーバレスのおかげでなんとか 2022 年 3 月〜 2022 年 4 月〜 エンジニア5名
3年前に未経験の人たちで スタート
None
VPC LESS VPC LESS VPC LESS OS LESS OS LESS
OS LESS
OIDC OIDC OIDC 全体アーキテクチャ(簡易) S3 MediaConvert S3 DynamoDB DynamoDB DynamoDB
AppSync Lambda API-GW Step Functions API-GW Amplify Amplify 担当者向け CMS 倉庫 システム BFF Frontend Backend
ServerlessDays Tokyo 2022 Virtual 詳しくは昨年の ServerlessDays の資料で!
動画配信サービス hod どうでしょうの新作配信
過去のどうでしょう新作は すべてサーバーダウン
放送は落ちないのにねぇ
やってやろうじゃないの
25,000ユーザ / 5,000 TPS を耐えられるように!! 絶対落ちないように ※オンプレ時代の情報を元にざっくり算出
今日のお話に出てくる 覚えておいて欲しい Limit
今日のお話に出てくる AWS Service Limit AppSync Rate of request tokens DynamoDB
Hot Partition 2,000 /s (soft limit) 3,000 read /s 1,000 wright /s (hard limit) 1,500KB秒以下のメモリとvCPU時間で1トークン 普通に使ってると、1 TokenConsumed / 1 query
課題
DynamoDB のホットパーテーション 多段 connection 問題 AppSync TokenConsumed 問題 近い構成で高負荷状態ではTokenが減少するの を確認済み
EpisodeGroup 1対多 1対多 AppSync と DynamoDB の関係 DynamoDB AppSync Program
Connection ConnectionEpisode Episode 1対多 1対1 1対1 Recoil に格納 初期ロード時に 全てのデータを DynamoDB User ユーザ系のデータ(ログイン時) くらい 番組情報は 全部で10MB amplify-cli で、どんどん増やしちゃった 番組系のデータ
EpisodeGroup 1対多 1対多 AppSync と DynamoDB の関係 DynamoDB AppSync Program
Connection ConnectionEpisode Episode 1対多 1対1 1対1 くらい 番組情報は 全部で10MB AppSync で 3000 resolver が解決 AppSync で 200 TokenConsumed DynamoDB で EpisodeTableに集中 1query で +
(別構成)AppSync と TokenConsumed 負荷をかけると1クエリあたりのToken消費が減る
負荷かけたけど 100 Token/query までしか下がらない
5000 TPS だと 5000 TPS ✖︎ 100 tokenだから quota は
50万必要...
AWS さん! 50万 Token まで上げて!!!
まぁ、一旦落ち着こうか
AWSさんのご提案 ・cacheを使ってみよか ・バックエンド作り直そか
残り2ヶ月で バックエンド作り直しは無理、、
cache しかない!!
キャッシュの 試行錯誤
キャッシュはVPC内サービス、、 ElastiCache はVPC使うので却下 DAX はVPC使うので却下 AppSync に cache がついてる FULL
cache Per resolver cache これらも結局、ElastiCacheで時間課金 Cache 導入によるToken低減の期待 キャッシュにオフロードできたらToken減りそう 1,500KB秒以下のメモリとvCPU時間で1トークン
AppSync の Cache Full request caching Per-resolver caching AppSync
AppSync の Cache テストしてみた Full request caching Tokenが激増 6000/query Per-resolver
caching ホットパーテーションは回避可能 Tokenは減らない。。 AppSync
これは、もう、、 デスマーチ宣言をするしか、、 ☠️
サーバーレスで キャッシュがあればなぁ
💡
4月の渋谷の夜 photo by @TAKA_0411
もめんと!
Momentoの 導入
元DynamoDBを担当してた方が立ち上げた サーバーレスキャッシュサービス Momento Cache Topics
キムさんにMomentoの相談(本番50日前くらい) AppSync Merged API 採用の検討 フロントエンドの修正を最小限に フロントエンドver と バックエンドver の提案
キャッシュ取得の構成案をMomentoチームと相談 構成図の解説
AppSync の Merged API Build time アプローチ Run time アプローチ
AppSync の 後ろに Momento Cache
AppSync の subscription 使いたい
実際の構築 (2週間くらい)
実際の構成
更新を含めると
超えてきた ハードル
Lambdaペイロードサイズ制限 バースト耐性 momento上限緩和等 実装で気をつけたこと
Lambdaペイロードサイズ制限 同期呼出で6MBを超えることができず AppSyncリゾルバーではストリーミング 応答もできない 番組データのサンプルは最大10MBを想定 更新を含めると
JSON 文字列 圧縮バイナリ Chunk 1 (1MB) Chunk 1 (1MB) Chunk
1 (1MB) 圧縮バイナリのチャンク単位で Momentoにキャッシュさせる → 3MB 10MB ・・・ Momento Cache
負荷試験中、AWS Lambda でおきたスロットル
AWS Lambda のバースト耐性 Token Bucket Algorithm 同時実行数(Concurrency)とバースト制限 ※「AWS Lambda におけるバースト耐性」:https://aws.amazon.com/jp/builders-flash/202212/lambda-burst-resistance
リクエスト不可に応じたバースト制限の同時実行数とスロットリング → リトライと Provisioned Concurrency で対応 ※「AWS Lambda におけるバースト耐性」:https://aws.amazon.com/jp/builders-flash/202212/lambda-burst-resistance
Momentoキャッシュのサービス上限と緩和申請 ~ 5000 TPS ~ 5000 TPS × 1MB チャンクは
1MB までなので そのまま
Momentoチームに課題と構成案を説明・相談 ※日本語のサポートもあります! MoCon参加で前フリをしていたので、今回は英語で。
相談したバックエンドverの構成
相談したフロントエンドverの構成
モニタリング 負荷試験
負荷試験はDistributed Load Testing on AWSを使用 5,000 rps まで負荷の負荷試験を実施 20,000 Token/s
まで上限緩和するために負荷試験を求めら れた AppSyncのdevとprodが同アカウントの同リージョン 段階的に上限緩和をしてもらう Momento 込みで負荷試験
Distributed Load Testing on AWS CloudFormation テンプレートを配布してる
CloudWatchメトリクスで確認 毎秒の値はCloudWatch Logs Insight で(高い) JMeterでレスポンスの情報をS3に保存 Colaboratory で集計してお金の節約 Momento のメトリクスもCloudWatchに連携
モニタリング
CloudWatch Dashboard dev と prod を 手動で作るの大変。。 CDKは途中で心折れた…
段階的に 負荷をかけていく
5,000 TPS クリア!!
CloudWatch Dashboard 負荷をかけると 反応が良くなる Momento Cache 1700ms 700ms AVG 5min
Momento Cache Get Latency
もともとは AppSync Rate of request tokens DynamoDB Hot Partition 2,000
/s (soft limit) AppSync DynamoDB 200 3,000 read /s 1,000 wright /s (hard limit) TokenConsumed
上限緩和とMomento の導入 AppSync Rate of request tokens DynamoDB Hot Partition
2,000 /s (soft limit) Momento が 受けてくれる! 20,000 /s ↓ AppSync Lambda Resolver Momento Cache Concurrent executions 20,000 + Provisioned Concurrency 1 TokenConsumed
REALLY APPRECIATE!!
配信当日
8/30 23:45:00
リクエスト数 AppSync
リクエスト数 3000 request/min AppSync
リクエスト数 3000 request/min あ、オンプレのデータって毎分だったのね、、 AppSync
リクエスト数 毎秒100くらい… AppSync
無風 😆
はじめて陥落しなかったから ヨシ!
まとめ
ついにサーバレスキャッシュがやってきた! フロントにキャッシュするしかなかった 全体でのキャッシュ戦略を考えたい NoSQL の設計をもう一度 @connection ディレクティブどうする? Amplify GraphQL Transformer
v2 ? AppSync Resolver 自分で書く? 大規模な上限緩和の相談はお早めに AWSさんには本当に感謝です 負荷試験は時間かかります まとめ
ありがとうございました! 三浦一樹 北海道テレビ放送株式会社 Sonu Kim 株式会社Serverless Operations 2023/09/23