Web サービスの全体像と速さ

「項目を1つ足すだけなのに、なぜ2週間かかるのか」「文言を直すだけなのに、アプリはなぜすぐに変わらないのか」。エンジニアとの会話で出てくるこうした疑問の多くは、サービスがどんな部品でできていて、変更がどの部品に入るかを知ると分かるようになります。

見積もりや障害の連絡を受けたときも、どの部品の話をしているかが分かると、判断が早くなります。

Web サービスは、おおむね次の部品でできています。ユーザーが画面を操作すると、画面（フロントエンド）が API（サーバーの窓口）を呼び、サーバーが DB（データベース）を読み書きして結果を返します。インフラは、これらを動かすサーバー・ネットワーク・クラウドの土台です。

構成図の読み方：箱は部品、矢印はリクエストの向きです。まず「ユーザーの1つの操作が、どの箱をどの順に通るか」を指でたどります。1本の矢印しかつながっていない箱は、そこが止まると全体が止まる場所（単一障害点）かもしれません。

SRE の「典型的な Web サービスの構成と各層の冗長化」

SRE の「URL 入力から表示まで」

下の「ブラウザで試す」の図は、ブラウザに URL を入れてからページが表示されるまでを、通信の順番どおりに追うものです。DNS で名前を IP アドレスに変え、ロードバランサーと接続し、アプリサーバーが DB に問い合わせて HTML を返し、最後に CSS や画像を CDN から取ります。途中の TCP・TLS の手順は細かく読まなくてかまいません。上の表の部品（CDN・ロードバランサー・アプリサーバー・DB）が、1つの操作でどの順に出てくるかに注目してください。

画面とサーバーは HTTP という決まりでやりとりします。画面が「何をしたいか」をリクエストで送り、サーバーは結果をステータスコード（3けたの番号）と中身をつけたレスポンスで返します。

400 台は利用者側、500 台はサーバー側の問題とおおまかに分けられます。障害の判断やエラー率の目標では、主に 500 台の割合を見ます。

「さっき直したはずの価格が、まだ古いまま表示されている」という問い合わせは、多くの場合バグではなく、キャッシュの仕様どおりの動きです。キャッシュはサービスを速く・安くするために欠かせない一方で、少し古い内容が見えることがあるという性質を持ちます。

PdM がこの性質を知っておくと、問い合わせへの答え方や、仕様で決めるべきこと（どのデータはどれくらい古くてよいか）が分かります。

キャッシュは、一度作った結果を近くに置いて使い回す仕組みです。CDN は世界各地のサーバーに画像やページの写しを置き、利用者の近くから返して速くします。サーバーの中では Redis などに DB の結果を一時的に置き、DB の負荷を減らします。

「更新したのに反映されない」のは、たいていキャッシュの有効期限（TTL）が切れるまで古い写しが返っているからです。CDN・ブラウザ・アプリ・Redis のどこかに古いものが残っています。急ぐときは CDN の写しを消す（パージ）こともできます。

PdM が仕様で決めるのは「どれくらい古くてよいか」です。お知らせやランキングは数分遅れても困りませんが、価格・在庫・権限は古いと事故になります。データごとに許せる遅れを伝えると、エンジニアがキャッシュの置き方を決めやすくなります。

Web の「HTTP キャッシュ」

SRE の「Redis の運用」

下の「ブラウザで試す」の図では、画像を CDN に要求すると、最初はオリジン（S3）から取ってきて CDN とブラウザに保存し、次からはブラウザのキャッシュや、別の利用者でも CDN の写しから返る様子を見られます。後半では、ログイン後のページのように人ごとに変わる応答はキャッシュさせないこと、更新するときはファイル名を変えるか CDN の写しを消す（パージ）ことが出てきます。上の表の「CDN」「ブラウザ」の行がどの手順にあたるかを見てください。Redis やアプリの中のキャッシュは図には出てきません。

メール送信・CSV の作成・画像の変換のような時間のかかる処理は、画面を待たせずに非同期（後で裏で処理する）にすることがよくあります。頼まれた仕事をキュー（順番待ちの列）に入れ、ワーカー（裏で動く処理役）が順に片付けます。

非同期にすると、「受け付けた」と「終わった」の間に状態ができます。その間の見せ方、失敗したときの知らせ方、同じ処理が2回走っても結果が変わらないこと（冪等性）を、仕様の段階でエンジニアと決めておきます。

「テレビで紹介されたらサイトが落ちた」「セールの開始と同時につながらなくなった」は、よくある障害です。アクセスの集中は、前もって分かっていれば準備で防げることが多く、その情報をいちばん早く持っているのは、PdM やマーケティングの側です。

ここでは、なぜ急な集中に弱いのか、エンジニアに何をいつ伝えればよいかを押さえます。

サーバーの台数や性能を増やして多くのアクセスに耐えることをスケールといいます。クラウドには自動で台数を増やす仕組み（オートスケール）がありますが、増えるまでに数分かかることが多く、テレビ放映やセール開始の瞬間のような急な集中には間に合いません。また、DB は画面やサーバーのように簡単には増やせません。

大きな集中が分かっているなら、数週間前には伝えて、負荷試験や台数の増強、待合室（順番待ちの画面）の準備の時間を取ってもらいます。

下の「ブラウザで試す」の図は、台数を増やすときの土台になるロードバランサー（リクエストを複数のサーバーに振り分ける装置）の動きです。リクエストが2台のサーバーに交互に振り分けられ、片方が故障するとヘルスチェック（定期的な生存確認）で自動で外されて、残りの1台が全部を受けます。「1台になっても全部をさばける余力があるか」は、集中に耐えられるかと同じ問いである点に注目してください。オートスケールや待合室そのものは図には出てきません。

「遅い」の原因は、大きく通信の距離・サーバーの処理・データ（DB）・画面（ブラウザ）の4か所に分けられます。どこで時間がかかっているかで直し方も工数も変わるので、エンジニアと「どの部分が何秒か」を見ながら話すのが近道です。

直す前に、まず計測して、どこで何秒かかっているかを確かめます。思い込みで直すと、効かないところに工数を使ってしまいます。

SRE の「レイテンシの正しい見方」

Web の「Core Web Vitals」

速さは平均ではなく、パーセンタイルで見ます。p95 は「遅い方から5%の境目」、つまり95%の人はこれより速いという値です。平均が速くても、一部の人がとても待たされていることがあるからです。

Web 画面では Google の Core Web Vitals がよく使われ、実際の利用者の p75（4回の表示のうち3回がこれより速い）で判定します。

Web の「Core Web Vitals」

SRE の「レイテンシの正しい見方」

表示が遅いと離脱が増え、購入や登録の率が下がる傾向は多くの事例で報告されています。ただし効き方はプロダクトごとに違うので、まず自社のデータで「速さと CVR（購入などに進む率）の関係」を見てから、どこにどれだけ投資するかを決めます。

画面・指標・目標値・理由の4つがそろうと、エンジニアは見積もりと方法を決めやすくなり、終わったかどうかも数字で判断できます。