本文へ移動

ホーム / PdM / 第2部 Web サービスの仕組み

第2部 Web サービスの仕組み・第4章

データベースの基礎

★☆☆ 発展4トピック・面接 2問

仕様の「項目を足す」「データを直す」「消す」の裏で何が起きているかを、判断に使える範囲で押さえる。

別のページで開く →

DBラボを読み込んでいます…

4.1テーブル・行・ID

用語★☆☆ 発展
ひとことで

データを表(テーブル)に入れ、ID でつないで管理する仕組み。1対多の関係の変更は影響が大きい。

多くのサービスは RDB(リレーショナルデータベース:MySQL・PostgreSQL など)にデータを保存します。データはテーブル(表)に入り、1件が行、項目が列です。テーブル同士は ID でつながります。

テーブルは ID でつながる。1人のユーザーに注文が何件もあるusers(ユーザー)id:1名前:佐藤メール:sato@…orders(注文)id:101・user_id:1id:102・user_id:1id:103・user_id:2user_id でつながる名前を変えても、注文の側は user_id のままなので直す必要がない
テーブルと ID のつながり
仕様の言葉DB で起きること
「ユーザーに電話番号を足したい」users に列を足す。既存の人は空になるので、空のときの扱いを決める
「1人が複数の住所を持てるように」1つの列では足りず、住所のテーブルを新しく作る。影響が大きい
「退会した人の注文は?」注文は残すか、つながりをどう切るかを決める

「1つ」が「複数」に変わる仕様は、テーブルの作りから変わることが多く、見積もりが大きくなりがちです。

面接ではこう答える

RDB は、データをテーブルという表に入れ、テーブル同士を ID でつないで管理します。例えばユーザーと注文は別のテーブルで、注文の側にユーザーの ID を持たせてつなぎます。PdM としては、項目を足すと既存のデータが空になること、「1つ」を「複数」にする変更はテーブルの作りから変わり大きな工事になることを意識して仕様を考えます。

止めずに変えるには、何段階かに分けて進める① 新しい列を足す古い列も残す② 両方に書くアプリを更新③ 古いデータを移す件数が多いと数時間〜④ 古い列を消す全員が新しい版に一気に変えると、移行中に止まる・古いアプリが壊れることがある
止めずにデータの形を変える手順

テーブルの形を変えることをマイグレーション、既存のデータを新しい形に移すことをデータ移行といいます。件数が多いと移行に時間がかかり、やり方によってはその間に書き込みが止まります。そのため、サービスを止めずに何段階かに分けて進めるのが普通です。

PdM が確かめること理由
既存のデータをどうするか新しい項目は過去の分が空。埋めるか、空の表示を決めるか
古いアプリの版古い版が新しい形を知らなくても動くか
移行にかかる時間と止まる時間メンテナンスの告知が要るか
戻せるか途中で問題が出たときに元に戻す手順

別のページで開く →

DBラボを読み込んでいます…

ひとことで

複数の書き込みを「全部成功するか、全部なかったことにするか」の1つのまとまりとして扱う仕組み。

途中で失敗したら、全部なかったことにするトランザクション在庫を1減らす注文を記録ポイントを使う全部成功 → 確定1つでも失敗 → 全部戻す在庫だけ減って注文がない、のような「半端な状態」を作らない
トランザクション:全部やるか、全部やらないか

トランザクションは、複数の書き込みを「全部成功するか、全部なかったことにするか」の1つのまとまりとして扱う仕組みです。在庫・注文・ポイントのように、どれかだけ反映されると困る処理を守ります。

同時に買われたときに在庫がマイナスにならないか、ボタンを2回押したら2回注文されないか、は仕様の大事な論点です。「残り1個を2人が同時に買ったらどうなる?」と聞くと、エンジニアと具体的に話せます。

面接ではこう答える

トランザクションは、在庫を減らす・注文を記録する・ポイントを使う、のような複数の書き込みを1つのまとまりとして扱い、途中で失敗したら全部を元に戻す仕組みです。これがあるので、在庫だけ減って注文がない、といった半端な状態を防げます。PdM としては、残り1個を2人が同時に買ったときや、ボタンが2回押されたときにどうなるかを、仕様の段階でエンジニアと確認しています。

別のページで開く →

DBラボを読み込んでいます…

ひとことで

RPO はどの時点まで戻れるか、RTO はどれだけの時間で戻せるか。どこまで求めるかは事業の判断。

どこまで戻れるか(RPO)と、どれだけで戻せるか(RTO)最後のバックアップ障害復旧RPO:失われうるデータの期間RTO:止まっている時間
RPO と RTO

バックアップから戻すとき、RPO(どの時点まで戻れるか=失ってよいデータの期間)と RTO(どれだけの時間で戻せるか)の2つで考えます。短くするほど費用がかかるので、どこまで求めるかは事業の判断です。

論点PdM が決めること・確かめること
RPO・RTO注文は数分以内、ログは1日分失っても許せる、など機能ごとに
誤操作からの復元ユーザーが消したデータを戻せるか(ごみ箱・取り消し)
退会・削除の依頼本当に消すのか、見えなくするだけか(論理削除)。バックアップの中はいつ消えるか
戻す練習実際に戻せるかを試したことがあるか

面接ではこう答える

バックアップは、RPO と RTO の2つで考えます。RPO はどの時点まで戻れるか、つまり失ってよいデータの期間で、RTO は止まってから戻るまでの時間です。どちらも短くするほど費用がかかるので、注文は数分、ログは1日のように、機能ごとに事業として決めます。PdM としては、ユーザーの削除依頼に対してバックアップの中のデータがいつ消えるかも確認しています。

この章のまとめ

🖨 まとめシート(印刷・PDF)
  • データは表(テーブル)に入り、ID でつながる。項目の追加や移行は思ったより時間がかかる
  • 在庫や決済は「全部やるか、全部やらないか」(トランザクション)で守る
  • バックアップから戻せる時点と時間(RPO・RTO)は事業の判断

この章のクイズ

面接ではこう聞かれる

まず答えを見ずに声に出して答え、そのあと開いて比べる。

Q1「ユーザーが住所を複数登録できるようにしたい」という要望の見積もりが大きく出ました。なぜだと思いますか?

模範回答

「1つ」を「複数」にする変更は、テーブルの作りから変わることが多いからです。今は users の列に住所が1つ入っているなら、住所のテーブルを新しく作り、既存の住所を移し、住所を読んでいるすべての画面・API・メールなどを直す必要があります。古いアプリの版への対応も要ります。

PdM としては、どの画面が住所を使っているかの洗い出しを一緒に見て、例えば「まずは配送先だけ複数にする」のように範囲を絞れないかを相談します。

深掘りされたら

  • 範囲を絞るとしたら、どこから始めますか?

見られているポイントデータの形の変更の影響範囲を想像できるか

Q2在庫が残り1個の商品を、2人が同時に購入しようとしたらどうなるべきですか?

模範回答

1人だけが買え、もう1人には「売り切れました」と分かる形で伝わるべきです。在庫がマイナスになったり、2人とも買えたことになったりしてはいけません。

そのために、エンジニアは在庫の確認と減らす処理をトランザクションやロックでまとめて扱います。PdM としては、買えなかった人への表示、カートに入れた時点で在庫を押さえるかどうか、押さえるなら何分で解除するか、を仕様として決めます。

深掘りされたら

  • カートに入れた時点で在庫を押さえる場合の注意は?

見られているポイント同時実行のエッジケースを仕様に落とせるか