保存先を選ぶ

全部を同じ所に入れない

席の予約サービスでは、予約、ログイン中の状態、座席図を保存します。使い方が違うので、何を一緒に更新したいかと、どう読み出すかから保存先を選びます。

関係データベースは、複数の更新をまとめて成功か失敗にそろえるトランザクションに向きます。席の在庫を減らす処理と予約を作る処理は、片方だけ成功してはいけません。

キーバリューは、鍵で1件を引く保存先です。セッションIDでログイン中の状態を探す用途が合います。オブジェクトストレージは、座席図の画像など大きなファイルを置く用途に向きます。

運用する保存先が少なければ、管理は楽です。ただし大きな画像を予約の行に混ぜると、転送やバックアップが重くなり、予約の処理と資源を奪い合います。

分ければ管理する場所も増えます。月5万円の予算では、データを分ける効果が費用や運用の手間に見合うかも確かめます。

譲れない条件から選ぶ

最初に、どの更新をひとまとまりにしたいかを決めます。次に1件の大きさを見て、中身を別の保存先へ出せるか考えます。

大きな中身と、利用できるかを示す状態を分けます。中身の場所を指す文字列と有効状態を関係データベースに置けば、予約と同じ更新で状態を変えられます。

ファイルの保存まで同じトランザクションに入るわけではありません。先に非公開で保存し、場所を予約に登録できなければ、残ったファイルを後で片づける手順が必要です。

予約サービスで解いてみる

DAU3万人、1人6回の要求は1日18万回、平均約2 QPSです。ピーク係数50で100件/秒を見込む予約サービスに、1件5MBの座席図付きチケットを追加します。

予約取り消しと同時に使えなくする条件なら、チケット本体はオブジェクトストレージへ置きます。予約の行には、その場所を指す文字列と有効状態だけを入れます。

取得時は予約が有効かを確認してから、本体を渡します。無効化した瞬間に本体を削除できなくても、利用者には返しません。公開URLを知れば誰でも読める形では、この条件を守れません。

答えは、本体の置き場所と無効化の判定を分ける設計です。1台40件/秒という見積もりも、5MBの転送を含むかで変わるので、予約の処理とファイル配信を分けて測ります。