前回の5責務を「2つの層」に分けて見る
前回のJ-01では、バックエンドが担う5つの責務を確認しました。今回はそのサーバーを、もう一段細かく分けて見ていきます。サーバーは大きく、外からのHTTP接続を受ける入口の層と、アプリ固有の処理を実行する層の2つに分かれます。この2層の見取り図を持っておくと、後の講義で扱う処理が「どの層の話か」を迷わず置けるようになります。
このスライドのポイント
- J-01: バックエンドの5責務（入力検証・業務ルール・認証判断・DB操作・外部接続）を確認した
- 本講義: そのサーバーを「入口の層」と「処理の層」の2つに分けて見る
- この2層の見取り図が、「どの層のエラーか」を切り分ける土台になる
2つのサーバーの定義
まず定義です。Webサーバーとは、外から届くHTTP接続を受け付け、画像やCSSのような静的ファイルをそのまま返し、必要なものを奥へ振り分ける入口の層です。アプリケーションサーバーとは、その奥でアプリ固有の処理、つまりJ-01で見た5責務を実行する層です。小規模なアプリでは、この2つが1つのプログラムに同居していることも多くあります。ただし同居していても役割は別で、B-01で見たOSとアプリの関係に似た層の分離だと捉えてください。
このスライドのポイント
- Webサーバー＝HTTP接続の受付・静的ファイルの返却・振り分けを担う入口の層
- アプリケーションサーバー＝アプリ固有の処理（J-01の5責務）を実行する層
- 小規模では1つのプログラムに同居することも多いが、役割は別
- B-01で見たOSとアプリの関係に似た「層の分離」
なぜ「層」で分けるのか
この区別が必要な理由は、障害対応で効いてきます。「サーバーエラーです」と一枚岩で捉えてしまうと、原因にたどり着けません。入口の層で止まっているなら、そもそもリクエストがアプリまで届いていない設定や起動の問題です。一方、アプリの層まで届いた上で失敗しているなら、処理の中身の不具合です。この2つは調べる場所も直し方も違うので、最初に層を見分けることが解決の近道になります。
このスライドのポイント
- 「サーバーエラー」を一枚岩で捉えると、原因にたどり着けない
- 入口の問題＝そもそもリクエストが届いていない（設定・起動の問題）
- アプリの問題＝届いたが、処理の途中で失敗した
- どちらかで、調べる場所も直し方も変わる
2層の断面図
構造を断面で見ます。手前にWebサーバー、その奥にアプリケーションサーバーが並びます。届いたリクエストはまず入口のWebサーバーを通り、静的ファイルで済むものはそこで折り返し、アプリの処理が要るものだけが奥へ渡されます。ここで思い出したいのが、D-06で学んだ502や503です。これらは入口とアプリの間の受け渡しが滞るときに出やすく、「入口は生きているがアプリが応えていない」状態を表します。
このスライドのポイント
- 断面: [Webサーバー: 受付・静的返却] → [アプリケーションサーバー: 5責務の実行]
- リクエストはまず入口を通り、必要なものだけが奥の処理層へ渡される
- D-06の502・503は、入口とアプリの間の受け渡しが滞るときに出やすい
静的ファイルと業務処理で「届く深さ」が違う
具体例で見ます。ページを開くとD-09で見たように画像やCSSが追加取得されますが、これらは用意済みのファイルなので、入口のWebサーバー層がそのまま返せます。奥の処理層まで行く必要はありません。一方、経費を申請するリクエストは、金額の検証や承認ルートの判定といったアプリ固有の処理が要るため、アプリケーション層まで届いて初めて実行されます。同じサーバーへの要求でも、静的ファイルは浅く、業務処理は深くと、届く深さが違うのです。
このスライドのポイント
- 画像やCSS（D-09で追加取得されるもの）は、入口のWebサーバー層が直接返せる
- 経費の申請処理は、アプリケーション層まで届いて初めて実行される
- 同じサーバーへの要求でも、静的ファイルは浅く、業務処理は深く届く
技術サンプル: リクエスト2本の経路比較
技術サンプルは、リクエスト2本の経路を比べる図です。1本目はCSSファイルの要求で、入口のWebサーバーで折り返され、アプリ層には届きません。2本目は経費申請のAPI要求で、入口を通り抜けてアプリケーションサーバーまで届き、5責務が実行されます。読み方は、静的ファイルの要求は入口で完結し、業務処理の要求だけが奥まで進むという深さの違いです。障害時にはAIへ「このエラーは入口の層とアプリの層のどちらで起きていますか。ログはどちらに出ていますか」と尋ねると、切り分けが進みます。
「全部だめ」と「アプリだけだめ」を見分ける
混同しやすいのは「サーバーが落ちている」と「アプリだけ落ちている」の2つです。前者は入口のWebサーバーごと停止していて、ページに一切つながりません。後者は入口は生きていて静的なページは見えるのに、ボタンを押すなどの操作だけが失敗します。この2つは見た目が似ていても原因の場所が正反対です。だからこそ、切り分けの初手として「静的なページが見えるかどうか」を確かめることが効いてきます。
バイブコーディングでの確認点
バイブコーディングでの確認点です。障害が起きたら、まず「静的なページは見えるか」を確かめてください。見えるなら入口のWebサーバーは生きているので、問題はアプリの層に絞れます。D-06で学んだエラー報告の3点セットに、「どちらの層で起きていそうか」の観察を1つ加えると、AIへの相談が具体的になります。たとえば「静的ページは見えるが操作だけ失敗します。これは入口とアプリのどちらの層の問題ですか」と尋ねると、当てずっぽうの修正を避けられます。
このスライドのポイント
- 障害時の初手: まず「静的なページは見えるか」を確認する（見えれば入口は生きている）
- D-06で学んだ報告の3点セットに、「どの層で起きていそうか」の観察を1つ加える
- AIへの質問例: 「静的ページは見えるが操作だけ失敗します。これは入口とアプリのどちらの層の問題ですか」
まとめと一問一答
最後に一問一答です。静的ファイルを返すのは、主にどちらの層でしょうか。……答えは、入口のWebサーバー層です。30秒でまとめます。サーバーはHTTP接続を受ける入口のWebサーバー層と、5責務を実行するアプリケーション層に分かれます。障害時はまず「静的ページが見えるか」を確かめて層を切り分けるのが初手でした。次回はそのアプリ層を動かす土台、Node.jsランタイムを見ていきます。関連資料は「Webアプリ構成図入門」と「エラー文の読み方」です。
このスライドのポイント
- 一問一答: 「静的ファイルを返すのは主にどちらの層？」
- 30秒まとめ: サーバーは入口のWebサーバー層と処理のアプリケーション層に分かれる／障害時はまず「静的ページが見えるか」で層を切り分ける
- 次回: アプリ層を動かす土台、Node.jsランタイムへ（J-03）
- 関連資料: 「Webアプリ構成図入門」「エラー文の読み方」
