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
550
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
サーバーレスアーキテクチャにおける AWS と SaaS を活用しての スパイクアクセス対策
#jawsug #jawsug_sapporo
#serverdays2023 の再演です
Kazuki Miura
PRO
September 28, 2023
More Decks by Kazuki Miura
See All by Kazuki Miura
地域のCCoEの拡大を目指す 企業間コミュニティ 「re:light local」について
miu_crescent
PRO
0
53
us-east-1 に障害が起きた時に、 ap-northeast-1 にどんな影響があるか 説明できるようになろう!
miu_crescent
PRO
13
5.2k
これだけはやっておいた方がよさそう?awsにおけるランサムウェア対策
miu_crescent
PRO
1
160
生成AIを活用した音声文字起こしシステムの2つの構築パターンについて
miu_crescent
PRO
4
460
なぜ あなたはそんなに re:Invent に行くのか?
miu_crescent
PRO
0
430
エンタメ方向のTを広げよう!Werner先生の クロージングキーノートを 深掘りするための小ネタ10
miu_crescent
PRO
1
210
Amazon Bedrockを活用した 報道向け文字起こしシステムの開発
miu_crescent
PRO
1
200
us-east-1 の障害が 起きると なぜ ソワソワするのか
miu_crescent
PRO
0
95
us-east-1 の障害が 起きると なぜ ソワソワするのか
miu_crescent
PRO
3
1.2k
Other Decks in Technology
See All in Technology
AWS環境のセキュリティ不安を解消した企業事例 ~よくある課題と対策を一挙公開~
asanoharuki
0
170
壊して学ぶAWS CDK: そのcdk deployで消えるもの、残るもの
k_adachi_01
1
500
生成 AI 時代にいま一度「問い合わせ」について考えてみる
kazzpapa3
1
130
データエンジニアリングとドメイン駆動設計
masuda220
PRO
14
2.6k
AI_Dev_Day_製造業領域でのAI活用から見た活用の罠と成功に導く実践知.pdf
kintotechdev
0
200
全社でのソフトウェアサプライチェーン攻撃対策をやってみた with Takumi Guard
z63d
0
300
インシデント事例と パッケージの全量解析に学ぶ ソフトウェアサプライチェーンの守り方 / supply-chain-attack-defense
flatt_security
0
1k
AI時代の開発生産性を捉え直す — 経営と現場をつなぐ「開発組織のオブザーバビリティ」— / AI Dev Ex Conference 2026
tkyowa
1
1.5k
データ活用研修 データマネジメント【MIXI 26新卒技術研修】
mixi_engineers
PRO
2
100
OpenTelemetryにおけるGoのゼロコード・コンパイル時計装について #fukuokago
quiver
0
310
AI x 開発生産性を取り巻く予算戦略と投資対効果
i35_267
7
3.3k
Power Automateアップデート情報
miyakemito
0
240
Featured
See All Featured
Designing Powerful Visuals for Engaging Learning
tmiket
1
460
Utilizing Notion as your number one productivity tool
mfonobong
4
460
A Tale of Four Properties
chriscoyier
163
24k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
390
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Amusing Abliteration
ianozsvald
1
240
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
A Soul's Torment
seathinner
6
3.1k
Leo the Paperboy
mayatellez
8
1.9k
Facilitating Awesome Meetings
lara
57
7k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.7k
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