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
GraphQL における quota を見ながら 高負荷試験 してみた
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Kazuki Miura
PRO
September 30, 2022
Technology
1.2k
0
Share
GraphQL における quota を見ながら 高負荷試験 してみた
#jawsug_sre
AppSync の負荷試験のお話
token って難しいよね
Kazuki Miura
PRO
September 30, 2022
More Decks by Kazuki Miura
See All by Kazuki Miura
地域のCCoEの拡大を目指す 企業間コミュニティ 「re:light local」について
miu_crescent
PRO
0
41
us-east-1 に障害が起きた時に、 ap-northeast-1 にどんな影響があるか 説明できるようになろう!
miu_crescent
PRO
13
5k
これだけはやっておいた方がよさそう?awsにおけるランサムウェア対策
miu_crescent
PRO
1
150
生成AIを活用した音声文字起こしシステムの2つの構築パターンについて
miu_crescent
PRO
4
410
なぜ あなたはそんなに re:Invent に行くのか?
miu_crescent
PRO
0
410
エンタメ方向のTを広げよう!Werner先生の クロージングキーノートを 深掘りするための小ネタ10
miu_crescent
PRO
1
190
Amazon Bedrockを活用した 報道向け文字起こしシステムの開発
miu_crescent
PRO
1
180
us-east-1 の障害が 起きると なぜ ソワソワするのか
miu_crescent
PRO
0
79
us-east-1 の障害が 起きると なぜ ソワソワするのか
miu_crescent
PRO
3
1.1k
Other Decks in Technology
See All in Technology
「コーディング」しない人のための Claude Code 入門 ChatGPT の次の一歩 — 業務に組み込む 育成・共有・自動化
rfdnxbro
2
1.2k
Javaコミュニティをもっと楽しむための9箇条
takasyou
0
1.2k
速さだけじゃない! VoidZero ツールが移行先に選ばれる理由
mizdra
PRO
6
740
コードレビューを制するチームがソフトウェアデリバリーのフローを制す / Beyond Code Review: Distributing Its Responsibilities Across the SDLC
mtx2s
3
990
JEP 522 Deep Dive - G1 GC同期コスト削減によるスループット向上を徹底検証&解説
tabatad
1
730
実装は速くなった、レビューはどうする? ― 自身のレビューをAIで再現させるサーヴァントエンジニアリングのすゝめ / Implementation got faster. So what about reviews? — An invitation to Servant Engineering: Recreating your own code reviews with AI
nrslib
6
3.5k
BigQuery の Cross-cloud Lakehouse への歩み
phaya72
2
540
製造業のクラウド活用最適解〜AI,DXを加速するデータ基盤の作り方〜
hamadakoji
0
340
AI Testing Talks: Challenges of Applying AI in Software Testing: From Hype to Practical Use
exactpro
PRO
1
110
Mastering Ruby Box
tagomoris
3
140
AI活用を推進するために ファインディが下した、一つの小さな決断
starfish719
0
240
トークン数だけでは測れない — Claude Code 組織展開の効果検証から学んだこと
makikub
0
120
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
174
15k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
350
Un-Boring Meetings
codingconduct
0
310
The Illustrated Children's Guide to Kubernetes
chrisshort
51
52k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
Bash Introduction
62gerente
615
210k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
30k
Raft: Consensus for Rubyists
vanstee
141
7.5k
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
150
Transcript
#JAWSUG_SRE GraphQL における quota をみながら 負荷試験してみた 2022年9月30日 #04
#jawsug_sre 04 自己紹介 三浦一樹(36) #Sauna #Sapporo #HTB #Amplify #StepFunctions #Serverless
#AWSSamurai2019 #Marvel #Hinatazaka46 #ANN #PdM #PjM #SM
#jawsug_sre 04 SREじゃないんですけど ツイートしたら捕まりましたw
数年に1度やってくる 瞬間的な高負荷 スパ イク #JAWSUG_SRE 04
#jawsug_sre 04
落城
#jawsug_sre 04 2021
None
#jawsug_sre 04 query mutation 商品データ 10Table ユーザデータ 10Table
#jawsug_sre 04 query mutation amplify-cli
#jawsug_sre 04 mutation ここがやばい 商品データ 10Table ユーザデータ 10Table
クォータ #JAWSUG_SRE 04 リクエスト/s 最適化
最初の1クエリで 全データを持ってくる 2022.04.28 〜 2022.03.01 〜
#jawsug_sre 04 2022
クォータ #JAWSUG_SRE 04 リクエスト/s
だと おもってたら
変わってた (本番 1週間前)
クォータ #JAWSUG_SRE 04 リクエスト トークン /s リクエスト/s ↓
とーくん??
#JAWSUG_SRE 04 課金制度が変わった時? クォータが変更されたアナウンスは 見つからず、、 くやしいので、 過去のキャッシュを漁って、履歴を確認する
#JAWSUG_SRE 04 通常は 1token ってことは、変わらなそうじゃん レスポンスヘッダーの x-amzn-appsync-TokenConsumed を確認してみましょう 冷静にドキュメントを読むんだ、、!
x-amzn-appsync-tokenconsumed:50
x-amzn- appsync- tokencon sumed: 50
None
😴
#JAWSUG_SRE 04 2000 リクエスト /s 1ユーザは初期2クエリする 2000 ➗ 2 =
1000 users / s 昔の想定
#JAWSUG_SRE 04 2000 リクエスト /s 1ユーザは初期2クエリする 2000 ➗ 2 =
1000 users / s 2000 リクエスト トークン/s 1ユーザは 約 60トークン消費 2000 ➗ 60 ≒ 33 users/ s 昔の想定 実際
#JAWSUG_SRE 04 2000 リクエスト /s 1ユーザは初期2クエリする 2000 ➗ 2 =
1000 users / s 2000 リクエスト トークン/s 1ユーザは 約 60トークン消費 2000 ➗ 60 ≒ 33 users/ s 昔の想定 実際 想定の 30分の1 しか耐えられない!
怒りのデス・ロード
割愛
高負荷かけると 消費量が変化する 結論 #JAWSUG_SRE 04
#jawsug_sre 04 JMeter から AppSync にクエリなげる CloudWatch logs Insight で頑張って集計する
(金額はまぁすごいことに) いろんな負荷のかけ方をしてみた
#jawsug_sre 04 JMeter から AppSync にクエリなげる 100 rps 付近から トークン消費が
「1」に漸近する CloudWatch logs Insight で頑張って集計する (金額はまぁすごいことに) いろんな負荷のかけ方を試してみ たところ token consumed/queryのログのcount (それぞれ1秒間のSUM)
スパイク前に JMeterで 高負荷かけたれ
スパイクが予想される 前に高負荷かけて クエリあたりのトークン 消費量を 大幅に減少させ クォータの制限ないに 収めることができた!! まとめ #JAWSUG_SRE 04
基本はオンライン 東京以外はオフライン会場も