サーバーレスで構築するスケーラブルなベッティング基盤

導入：最初に来たのは“スパイクの夜”だった

大きな試合の日。前半が終わる瞬間に、ベットが一気に来ました。古いVMと太いDBでは間に合いません。キューは詰まり、払い戻しも遅れました。そこで、コアをイベント駆動に変え、実行をサーバーレスに寄せました。次の試合では、同じスパイクでp99が320ms、落ちもゼロ。皿を増やさず、流れを良くしただけです。

全体像を先に：2週間で動く“骨格”

完璧は後回し。まずは歩く骨格（walking skeleton）を作ります。流れはシンプルです。受付API → ベット検証 → イベント投入 → 台帳（不変ログ）→ オッズ配信 → 監視。少ない機能でも、端から端まで動くことが大事です。ここまでを2週間で通すのが目標です。

先に制約を置く：規制・SLO・レイテンシ予算

賭けは規制の上で動きます。リモート技術基準や公平性、監査が必要です。イギリスのリモート技術基準は読みやすく、骨子の確認に役立ちます（規制遵守の基本指針）。決済やカード情報に触れるならPCI DSS v4.0の流れも押さえます（PCI DSS v4.0の要点）。

次にSLOです。例：受付APIの可用性99.95%。p99レイテンシ250ms以内。ベット整合（最終的整合）5秒以内。レイテンシ予算を定義し、どこに時間を使えるかを決めます。API 80ms、検証80ms、書き込み70ms。余白20ms。数字があると、会話が早いです。

設計の中核はイベント駆動：ベットは“流れる”

状態を直接書き換えるより、事実の列を積み上げます。ベット受付はイベントです。検証や集計もイベントです。並びはログが守ります。リトライに強く、再生もできます。基本はidempotency keyで二重計上を防ぎ、DLQ（デッドレター）で不正なメッセージを隔離します。考え方の基礎はここがわかりやすいです（イベント駆動アーキテクチャの基礎）。

サーバーレス選定の原則：AWS/GCP/Azure/エッジの使い分け

選び方は単純です。冷スタート、スループット、地理分散、データの一貫性、この4つで見ます。CPUが短くても回数が多いならFaaS。I/Oが長いならコンテナ型（短時間課金）。配信が世界中ならエッジで薄く配る。設計の実務はここがまとまっています（Azure Functionsの実践ベストプラクティス）と、ベンダー中立の視点はこれが良いです（CNCF Serverless Whitepaper）。

データモデルの正念場：一貫性・パーティション・二相の罠

台帳は不変ログ。集計は派生ビュー。二相コミットは避けます。強整合が必要なら少数のホットキーに注意。パーティションキーは「ユーザーID＋時間帯」や「試合ID＋市場」のように分散と順序の両方を意識します。DynamoDBの特性は必ず把握します（DynamoDBのアダプティブキャパシティ）。

オッズと配信：リアルタイム＋遅延容認の二層化

オッズは鮮度が命です。超リアルタイムの層はエッジに置きます。ミリ秒で返す軽い関数と、短いTTLのキャッシュで守ります。実装の入口はここが一番早いです（Cloudflare Workersのドキュメント）。

一方で、統計や不正検知は秒〜分の遅れでも平気です。ストリームからDWHに流し、視点ごとに集約します。GCPならこの手順が分かりやすいです（BigQueryのストリーミング挿入ガイド）。

コストの現実：1000ベットあたりの単価で語る

1ベットに何回関数が動くか。メッセージはいくつ。ストレージに何KB。出口の通信は何MB。これが全てです。関数は128MB/50msで1000回なら、実行課金はだいたい$0.0001前後。呼び出し課金を入れても$0.0003程度。ストリーム書き込みは1000件で$0.00002〜0.0002のレンジ。台帳の書き込みはキー設計しだいで上下します。細かい計算は電卓に任せます（AWS料金計算ツール）。

目安として、1000ベットあたりの合計は$0.003〜$0.02の間に収まることが多いです。スパイク時にバースト課金が跳ねないよう、キューとバッチ処理で平準化します。

信頼性の作り方：SLO/SLI、エラーバジェット運用

まずSLIを決めます。p99レイテンシ、成功率、取り消し率、DLQ件数。SLOはそれに対する目標です。エラーバジェットが減ったら、新機能を止めて品質に集中します。実務の原典はここです（SRE本（SLO/SLI設計））。

ミニケース：欧州の決勝で、ピークは毎秒8,300ベット。サーバーレス構成でp99は受付230ms、全体320ms。リトライ嵐が出たのは、外部決済の一時遅延が原因。ベット受付と決済確認を疎結合にし、取り消し可の状態で一旦受け、後で整合させて復旧。DLQは0.002%以下で安定しました。

セキュリティ/不正対策：権限最小化と行動検知

IAMは最小権限。関数は単機能でロールを分けます。WAFとレート制限は標準。KYC/AMLは外部とAPI連携し、監査証跡を残します。ボットやマルチアカウントは行動の連続で見るほうが効きます。サーバーレス特有の脅威はここで一覧化されています（OWASP Serverless Top 10）。

監視とトレーシング：可観測性は“最初の一機能”から

メトリクス、ログ、トレース。この3つをセットで入れます。相関IDを最初から通し、関数間で渡します。サンプリングはp99付近を優先。ベンダーロックインを避けるなら、標準のSDKから入るのが安全です（OpenTelemetryドキュメント）。

実装の短距離ラン：1スプリントで歩く道

1. 受付API（スキーマ固定とidempotency key）
2. 同期の軽い検証（フォーマットと簡単な限度チェック）
3. イベント投入（ストリーム/キュー、DLQ設定）
4. 台帳（不変ログ、監査用の署名と時刻）
5. 疑似の決済と払い戻し（本番連携の前にテーブルドリブン）
6. オッズ配信のプロトタイプ（エッジ＋短TTL）
7. 可観測性（相関ID、主要SLIダッシュボード）
8. 負荷テスト（スパイク/ステップ/ソーク）

現場メモ：やって失敗したこと

• ホットキー地獄：試合IDだけでパーティション → 一部シャードが飽和
• 冷スタート連鎖：関数が同時に起きてタイムアウト → ウォームプールと並列抑制で回避
• リトライ嵐：外部APIの短時間障害 → サーキットブレーカとJitter付きバックオフで緩和

壊し方を学ぶのが早道です。実例はここが深いです（Netflix Tech Blogのカオスエンジニアリング）。

比較表：ベッティング基盤の主要機能とサーバーレス選択肢

注1：値はリージョンや設計により大きく変わります。注2：データ転送料金は別途。注3：コストは試算レンジです（詳細は各クラウドの電卓で再計算）。

小さなFAQで締める

責任あるUXと“プレイヤー教育”の導線

信頼はUIだけで生まれません。仕組みの見える化と、学べる導線が効きます。オッズの更新条件、入出金の待ち時間、KYCの手順を短い言葉で明記します。第三者のレビューや比較ガイドも役立ちます。責任あるギャンブルの支援はここが参考になります（BeGambleAware）。

また、地域の事情に合った情報を示すのも有効です。たとえばスウェーデンの利用者向けには、casino bonusar för svenska spelare（スウェーデンのプレイヤー向けボーナス比較）のようなガイドを、注意点と一緒に紹介します。年齢制限、賭け条件、出金ポリシーを必ず確認できるようにします。誘導は控えめに、判断の材料として置くだけで十分です。

免責と法令順守の注意

本記事は技術情報です。賭博の勧誘ではありません。対応すべき法令は国・地域で異なります。公開前に、現地の規制、年齢制限、広告規制、データ保護を法務と確認してください。自己排除、入金上限、プレイ時間の制御など、責任ある機能も用意しましょう。

運用の断片ログ（参考）

まとめ：流れを設計し、小さく走って、早く学ぶ

大事なのは3つだけです。先に制約とSLOを置く。事実の流れを中心に据える。コストは1000ベット単位で語る。あとは小さく走り、数字で学び、直すだけです。仕組みがシンプルなら、スパイクの夜でも静かに流れます。

参考リンク（本文内に登場）

• 規制遵守の基本指針（UKGC Remote Technical Standards）
• PCI DSS v4.0の要点
• イベント駆動アーキテクチャの基礎
• Azure Functionsの実践ベストプラクティス
• CNCF Serverless Whitepaper
• DynamoDBのアダプティブキャパシティ
• Cloudflare Workersのドキュメント
• BigQueryのストリーミング挿入ガイド
• AWS料金計算ツール
• SRE本（SLO/SLI設計）
• OWASP Serverless Top 10
• OpenTelemetryドキュメント
• Netflix Tech Blogのカオスエンジニアリング
• BeGambleAware

著者について

著者はリアルタイム配信とフィンテックのアーキテクト。欧州・アジアで規制対応のプロダクトを設計・運用。ピーク10万イベント/秒規模の実戦経験あり。SLO運用とコスト最適化を現場で推進。技術は人のために使う、が信条です。