フロントエンドエンジニアがサーバ/インフラを学んで気づいたこと——見えていなかった仕組み

DNS・負荷分散・冗長化など、フロントエンド寄りのエンジニアが「サーバ/インフラを支える技術」を読んで初めて腑に落ちたインフラの基礎知識をまとめる。

テックリードになって最初に感じた壁は、インフラの話についていけないことだった。

フロントエンドを長くやっていると、コードはある程度書けるし、React・TypeScriptの設計議論もできる。だがインフラエンジニアやSREとの会話になった瞬間に「なんとなくわかる」と「本当にわかる」の差を突きつけられる。「リバースプロキシとロードバランサーって結局何が違うんですか」——そんな質問を自分がするのが恥ずかしくなってきたタイミングで、この本を手に取った。

「URLを叩いてから画面が表示されるまで」が本当にわかっていなかった

フロントエンドの文脈では「APIを叩く」「レスポンスを受け取る」で話が済む。だがその裏で何が起きているか、正直なところかなり雑にしか理解していなかった。

この本を読んで一番に整理できたのがDNSの仕組みだ。

ブラウザがドメイン名に対してIPアドレスを問い合わせるとき、まずローカルのキャッシュを見て、次にスタブリゾルバ、フルサービスリゾルバ、権威DNSサーバという順番でたどっていく。TTLが切れるまでキャッシュが使われるので、DNSレコードを変更してもすぐには反映されない——これは知識として知っていたが「なぜそういう構造になっているか」まで理解できていなかった。

DNSは分散データベースとして設計されており、世界中のリクエストを一台のサーバで処理するのが不可能なため階層構造を持っている。この「なぜ」を理解したことで、デプロイ時のDNS切り替え作業や、Route53の設定変更後に「しばらく待ってください」となる理由が腹落ちした。

ロードバランサーと冗長化——「落ちない設計」の基本

フロントエンドでは「APIサーバが落ちた」という事態を受け手として経験するが、落ちないようにする側の設計を考えたことがなかった。

ロードバランサーは複数のサーバにリクエストを振り分けることで、一台が落ちても残りが処理を続けられるようにする仕組みだ。振り分けのアルゴリズムにはいくつか種類がある。

アルゴリズム概要向いているケース
ラウンドロビン順番に均等に振り分ける処理時間が均一なとき
最小接続数接続数が少ないサーバを優先処理時間がばらつくとき
IPハッシュ送信元IPで振り分け先を固定セッションの維持が必要なとき

セッションアフィニティ(スティッキーセッション)という概念も初めてちゃんと理解した。ログイン状態などをサーバサイドのセッションで管理している場合、同じユーザーを毎回同じサーバに振り向けないとセッションが壊れる。JWTなどのステートレスな認証が現代で好まれる理由の一端がここにある。

Active-StandbyとActive-Activeの違い

冗長化の文脈で「フェイルオーバー」という言葉は何となく知っていたが、具体的な構成まで追えていなかった。

Active-Standbyは現用系が1台で待機系がすぐに引き継げる状態で待つ構成。切り替えは速いが待機系はリソースを遊ばせることになる。Active-Activeは複数台を同時に稼働させてロードバランサーで振り分ける構成。リソースを無駄にしないが、データの整合性管理が複雑になる。

データベースの場合はプライマリ-レプリカ構成が一般的で、書き込みはプライマリ、読み込みはレプリカに向けることでスケールアウトが可能になる。フロントエンドからは「API叩くだけ」だが、その裏でこういった設計をしているエンジニアたちがいる。

キャッシュ戦略を「サーバ側」の視点で考える

Webフロントエンドをやっていると、キャッシュはブラウザキャッシュやCDNキャッシュの話になることが多い。だがサーバ側でもキャッシュの設計は重要で、Webサーバ・アプリケーションサーバ・データベースのそれぞれにキャッシュが存在する。

Nginxのプロキシキャッシュ、Memcached・Redisによるオブジェクトキャッシュ、RDBMSのクエリキャッシュ——これらが多層的に組み合わさっている。どのレイヤーでキャッシュするかによって、鮮度・コスト・実装の複雑さのトレードオフが変わってくる。

フロントエンドで「APIレスポンスが古い」と感じた経験は誰もあると思うが、それがどのキャッシュレイヤーの問題かを切り分けられるようになったのは大きかった。

テックリードとして得たこと

この本を読んで変わったのは、インフラエンジニアとの会話の質だ。

以前は「そのあたりはインフラの人に聞いて」と丸投げしていた領域で、「レプリカラグが出ているとしたら読み込みをプライマリに向けるのが早いですか」といった具体的な話ができるようになった。全部を自分で設計・構築する必要はないが、議論に参加できる程度の共通言語は持っておくべきだった。

フロントエンドの知識と組み合わせると「CDNとオリジンサーバの間でどういう設計にするか」という話も具体的に考えられるようになる。Astroでブログを構築するにあたってCloudFrontの設定を自分で書いたのも、この本を読んだ後だった。

まとめ

「サーバ/インフラを支える技術」は、インフラ初学者が全体像をつかむのに適した一冊だ。

コマンドの使い方を羅列するのではなく「なぜこういう設計になっているか」という背景を丁寧に説明してくれる。フロントエンド寄りのエンジニアがテックリードやフルスタック方向に進む際に、最初に読む一冊として強くすすめたい。