Web engineering fundamentals
書けるけれど、
説明できない。を埋める
フレームワークの使い方は調べれば出てきます。調べても身につかないのは、その下で動いている仕組みと、先人が何を悩んで今の形にしたかという設計判断です。 このサイトは言語の文法を扱いません。動く図解で仕組みを見せ、設計判断を問う演習で「自分ならどうするか」を言葉にしてもらいます。
想定している読者は実務 1〜3 年目です。 動くものは書けて、レビューも通る。けれど「なぜこの形なのか」を聞かれると言葉に詰まる、という段階の方へ。
記事 78 本・演習 580 問。全トピックはこちら。設計判断を問う演習は 66 問が無料です。
書いたコード
products.map(p =>
getCategory(p))1 行。ループも、通信も書いていない
実際に起きていること
101回、DB に問い合わせている
AI が書いたものを、判断できるか
コードを書く速さは、もう差になりません。聞けば動くものが出てきます。差が出るのは、出てきたものを自分のシステムに入れてよいかを決めるところです。
このリトライは、落ちている相手を潰さないか。この列に UNIQUE を張れば二重課金を防げるのか。落ちたとき、どこから見るか。ここには、調べて出てくる答えがありません。前提が自分の状況に依存するからです。その前提を持っているのは、あなただけです。
そして判断は、一度わかって終わりません。忘れます。だからこのサイトでは、演習で自分の言葉にしてもらい、自己採点をもとに忘れた頃に戻ってくる形にしています。
こういう問いに、答えてもらいます
調べれば出てくる答えがありません。前提が状況に依存するからです。実際の演習を 1 つ、そのまま載せます。
演習 — 設計判断を問う
この条件で、切り替え計画の TTL をどう設計しますか?
与えられた条件
- EC サイトの本番サーバーを、来週の火曜 深夜2時に新環境へ移行する
- 現在の A レコードの TTL は 86400（24時間）
- 新旧どちらの環境も同じ本番 DB を参照する構成にはできない（DB も同時に移行する）
- 深夜2時でも注文は毎時30件ほど入っている
- 旧環境は移行後いつでも停止できる状態にある
この軸で考える
- · TTL を下げる作業そのものにかかる浸透時間
- · 切り替え後、旧環境にアクセスが残る最大時間
- · 旧環境で注文を受けてしまった場合のデータの分岐
まず選ぶ（そのうえで、なぜそう判断したかを書きます）
- 火曜の深夜1時に TTL を 60 に下げ、2時に切り替える
- 月曜の朝に TTL を 60 に下げ、火曜2時に切り替える
- 前週の月曜に TTL を 60 に下げ、火曜2時に切り替え、水曜に 3600 へ戻す
- TTL は 86400 のまま切り替え、旧環境を1日動かし続ける
この演習に答えてみる（DNS — 名前からIPアドレスにたどり着くまで）。無料です。
書いた判断を、判断軸と照らす
さきほどの演習に、こう答えたとします。自分の判断を書くと、その演習に定められた3 つの判断軸と照らして返します。採点ではありません。点数も順位も出しません。どの軸に触れていて、どこが抜けているかだけを返します。
演習 — 設計判断を問う
この条件で、切り替え計画の TTL をどう設計しますか?
書いた答え
切り替えの前日に TTL を 300 秒に下げておいて、当日 A レコードを差し替えます。そうすれば 5 分くらいで新しい IP に向くはずです。
判断軸との照合
- 逆のことを言っているTTL を下げる作業そのものにかかる浸透時間
「切り替えの前日に TTL を 300 秒に下げておいて、当日 A レコードを差し替えます」
- 抜けている切り替え後、旧環境にアクセスが残る最大時間
- 抜けている旧環境で注文を受けてしまった場合のデータの分岐
TTL を下げる作業自体が、旧 TTL（24時間）の間キャッシュに浸透しません。前日に下げても、切り替え時点で多くのリゾルバはまだ 86400 を保持しており、最大24時間旧環境を見続けます。また、毎時30件の注文が入る中で、旧環境での書き込みをどう防ぐかも検討が必要です。
この演習も無料で試せます（DNS — 名前からIPアドレスにたどり着くまで）。書いた判断との照合も、購読しなくても 3 回ためせます。
どの記事も、同じ順序で進みます
読む側が構造を覚えなくていいように、並びを固定しています。解説と、最初の演習までは無料です。
事故
実際に起きる障害から入る。知識ではなく困りごとを先に見せる
What
動く図解。文章より先に、図を触って掴む
Why
設計意図と歴史的経緯。退けられた代替案まで踏み込む
演習
解説を読む前に、まず自分で判断する
実務での判断ポイント
いつ使い、いつ使わないか。しきい値とトレードオフ
さらに演習
設計判断を問う演習と、説明できるかの練習
無料月額 980 円（税込）。いつでも解約できます
7 つの領域
各カテゴリは「読み終わったら答えられるようになる問い」で定義しています。
ネットワーク / Web
9 本リクエストが届くまでに何が起きているか
ブラウザの URL 欄に文字を打ってから画面が出るまで、名前解決・接続確立・暗号化・キャッシュという4つの関門がある。障害調査で「どこまでは届いているのか」を切り分けられるかは、この層を絵で描けるかどうかで決まる。
- ?DNS の TTL を短くすると何が起きるのか
- ?HTTP/2 にしたのにページが速くならないのはなぜか
- ?CDN のキャッシュが消えないとき、どこを疑うか
ブラウザ
13 本画面が描かれる仕組みと、その上の制約
ブラウザは HTML を受け取ってから描画するまでに決まった工程を通る。どの CSS プロパティを触ると工程のどこからやり直しになるか、なぜ非同期処理が「詰まる」のか。そして、そこに被さる同一オリジンという安全装置。
- ?top を書き換えると重く、transform だと軽いのはなぜか
- ?重い処理中にクリックが効かなくなるのはなぜか
- ?CORS エラーはサーバーとブラウザのどちらが出しているのか
認証 / セキュリティ
12 本誰であるかを証明し、なりすましを防ぐ
認証は「セッションをサーバーが覚える」か「トークンに書いて持たせる」かの選択から始まる。この選択が、ログアウトの実装可能性・スケール特性・漏洩時の被害範囲をすべて決める。攻撃手法は、その選択の穴を突いてくる。
- ?JWT を使うとなぜ即時ログアウトが難しくなるのか
- ?SameSite=Lax だけで CSRF は防げるのか
- ?アクセストークンを localStorage に置くと何が起きるのか
データ / DB 設計
11 本正しく保ち、速く引く
テーブル設計は「同じ事実を2か所に書かない」ことから始まり、インデックスは「読む行を減らす」ためにある。そしてトランザクションの分離レベルは、同時に動く処理がお互いをどこまで見てよいかの取り決め。遅いクエリの原因は、たいていこの3つのどれか。
- ?複合インデックスの列の順番はなぜ重要なのか
- ?READ COMMITTED で起きて REPEATABLE READ で起きない異常は何か
- ?件数が増えたら急に遅くなったクエリの、最初に見る場所はどこか
設計 / アーキテクチャ
11 本変更しやすさを構造で買う
設計の良し悪しは「動くかどうか」では測れない。測れるのは、仕様変更が来たときに何ファイル触るか。凝集度・結合度・依存の向きは、その「触る範囲」を制御するための語彙であり、SOLID もレイヤードもその適用例にすぎない。
- ?依存性逆転は具体的に何を逆転させているのか
- ?レイヤードアーキテクチャで DB のカラム名が画面まで漏れるのはなぜ問題なのか
- ?「共通化」がかえって変更を重くするのはどういうときか
API 設計
11 本他人が使う契約をつくる
API は一度公開すると簡単には変えられない契約になる。リソースの切り方、同じリクエストが2回届いたときの振る舞い、失敗の伝え方。これらは実装の都合ではなく、呼ぶ側が安全なコードを書けるかどうかで決まる。
- ?決済 API に同じリクエストが2回届いたらどうなるべきか
- ?エラーレスポンスに何を入れると呼び出し側が自動復旧できるのか
- ?GraphQL にすると何が楽になり、何が難しくなるのか
運用 / 開発プロセス
11 本壊さずに届け、壊れたら気づく
リリースは「デプロイして終わり」ではない。同じ成果物がどの環境でも同じように動く保証、壊れたときに戻せる仕組み、壊れていることに人間より先に気づく仕組み。テストはその一番外側の防波堤。
- ?手元では動くのに本番で動かない、を構造的に潰すには何が要るか
- ?アラートが多すぎて誰も見なくなる状態をどう避けるか
- ?E2E テストを増やすほど開発が遅くなるのはなぜか
料金
解説は全部無料。有料は、演習と復習
仕組みの解説はすべて無料です。各種類の最初の演習も無料で試せます。
- 実務で判断が分かれる場面と、その分かれ目
- 設計判断を問う演習。選ぶだけでなく、自分の言葉で書く
- 自己採点にもとづく復習リスト。忘れた頃に戻ってくる
- 書いた判断を、その演習の判断軸と照らす（月 50 回まで）
記事を増やしている途中です。いまの価格は早期購読のもので、今後見直すことがあります。
いま購読された方は、解約されるまでこの金額のままご利用いただけます。