いにしえのバックエンド入門

• 全体図 ── 申請1件が、サーバーの中で8人の手を渡って DB に入るまで（実測と Wireshark）
• 素手で作ってみる ── 第3・4回はフレームワークなしで HTTP と DB を扱い、Spring が何を肩代わりしているかを確かめる
• 業務システムの定番 ── 入力チェック、エラーの返し方、トランザクション、承認の流れ、認証、ファイル、ログ、テスト
• 毎回、実際に測る ── 練習用のサーバーで動かし、ログ・SQL・パケット・時間の数字で説明する

題材は、これまでと同じ経費精算システムです。フロントエンド編の第10回で画面から送り、ネットワーク編の第10回で1行ずつ読んだあの申請を、今度は Java で受け取り、DB にしまいます。

練習用ネットワークは3台です。PC（192.168.1.10）、申請サーバー（192.168.1.20、名前は expenses.example）、DB サーバー（192.168.1.30）。申請サーバーで、この回のために作った Java のプログラムを起動しました。

# 申請サーバー（192.168.1.20）で Java のプログラムを起動
app$ java -jar expenses-0.0.1-SNAPSHOT.jar
    … Tomcat initialized with port 8080 (http)
    … HikariPool-1 - Start completed.
    … Started ExpensesApplication in 3.183 seconds
# だれが、どこで待っているか
app$ ss -ltnp 'sport = :8080'
    LISTEN  0.0.0.0:8080   users:(("java",pid=760,fd=18))
# DB への接続（起動したときに、もう張ってある）
app$ ss -tn 'dport = :5432' | wc -l
    10
# このプログラムの大きさ
app$ ls -l expenses-0.0.1-SNAPSHOT.jar ; grep VmRSS /proc/760/status ; ls /proc/760/task | wc -l
    24,319,744 bytes
    VmRSS:  200876 kB
    38

「サーバー」は、特別な機械のことではありません。番号（ポート）を開けて、頼みごとを待っているプログラムのことです。ss で見ると、java が 0.0.0.0 の 8080 番で待っています（ネットワーク編第11回の「すべての口で待つ」）。そして起動した時点で、DB サーバーの 5432 番へ10 本の接続を張り終えています。理由は第7章で。

起動には 3.2 秒、メモリは約 200 MB、スレッドは 38 本でした。小さな申請サーバーでも、中ではそれなりの数の仕事が動きはじめています。

PC から、ネットワーク編と同じ申請を送りました。

# PC から、第10回と同じ申請を送る
pc$ curl -D - -X POST -H 'Content-Type: application/json' \
       -d '{"date":"2026-10-26","item":"交通費","amount":1280}' \
       http://expenses.example:8080/api/expenses
    HTTP/1.1 201
    Location: /api/expenses/EXP-2026-0012
    Content-Type: application/json
    
    {"id":"EXP-2026-0012","status":"submitted"}     (0.281 s)
# 同じ申請をあと5回
    201 (0.009 s)  201 (0.010 s)  201 (0.007 s)  201 (0.005 s)  201 (0.005 s)

201 Created と受付番号が返り、受付番号は Location にも入っています（ネットワーク編第10回）。そのとき申請サーバーの中で何が起きたかは、ログに出しておきました。

# 申請サーバーのログ（2件目。スレッドはどれも http-nio-8080-exec-2）
    15:47:44.473 ExpenseController      窓口：申請を受け取った ExpenseRequest[…, amount=1280]
    15:47:44.473 JdbcTransactionManager Creating new transaction with name [example.expenses.ExpenseService.submit]
    15:47:44.473 JdbcTransactionManager Acquired Connection […] for JDBC transaction
    15:47:44.474 JdbcTemplate           Executing prepared SQL statement [select nextval('expense_no')]
    15:47:44.474 ExpenseService         担当者：受付番号を決めた EXP-2026-0013
    15:47:44.474 JdbcTemplate           Executing prepared SQL statement [insert into expense (…) values (?, ?, ?, ?, 'submitted')]
    15:47:44.475 ExpenseRepository      倉庫番：1行書いた EXP-2026-0013
    15:47:44.475 JdbcTransactionManager Committing JDBC transaction on Connection […]
    15:47:44.476 JdbcTransactionManager Releasing JDBC Connection […] after transaction
    15:47:44.476 ExpenseController      窓口：201 を返す EXP-2026-0013

Tomcat が HTTP を受け取り、Jackson が JSON を Java の値に変え、Hibernate Validator が中身を確かめます。そこまで済んでから、ようやく自分で書いた「窓口」が呼ばれます。窓口は「担当者」に渡し、担当者はトランザクションを始めて受付番号を決め、「倉庫番」が SQL で表に1行書きます。コミットして接続を池に返し、窓口が 201 を返す。ログの時刻では、受け取ってから返すまで 3 ミリ秒でした。

Wireshark の時刻で分けると、申請が届いてから DB に話しかけるまで 3.3 ミリ秒、DB との4往復が 2.5 ミリ秒、返事を書いて送るまで 1.6 ミリ秒です。

自分で書いた部分は、3つの役割に分けてあります。実際のコードです。

// 窓口（Controller）：HTTP を受け、担当者に渡し、201 を書く
@PostMapping
public ResponseEntity<Map<String, String>> submit(@Valid @RequestBody ExpenseRequest req) {
    log.info("窓口：申請を受け取った {}", req);
    String id = service.submit(req);
    log.info("窓口：201 を返す {}", id);
    return ResponseEntity.created(URI.create("/api/expenses/" + id))
            .body(Map.of("id", id, "status", "submitted"));
}

// 担当者（Service）：業務のきまり。ここから先は1つのトランザクション
@Transactional
public String submit(ExpenseRequest req) {
    String id = "EXP-2026-%04d".formatted(repo.nextNumber());
    log.info("担当者：受付番号を決めた {}", id);
    repo.insert(id, req);
    return id;
}

// 倉庫番（Repository）：SQL を書いて DB と話す
void insert(String id, ExpenseRequest r) {
    jdbc.sql("insert into expense (id, applied_on, item, amount, status) values (?, ?, ?, ?, 'submitted')")
        .params(id, r.date(), r.item(), r.amount())
        .update();
    log.info("倉庫番：1行書いた {}", id);
}

窓口（Controller）は HTTP のことだけ、担当者（Service）は業務のきまりだけ、倉庫番（Repository）は SQL のことだけを知っています。窓口に SQL を書けば動くことは動きますが、承認の流れや権限のチェックが増えるにつれ、1つのクラスが手に負えなくなります。役割で分けておけば、「DB を変える」なら倉庫番だけ、「金額の上限を変える」なら担当者だけを直せば済みます。

DB（データベース）は、申請サーバーの中の部品ではなく、別のサーバーで動く別のプログラムです。申請サーバーとは、TCP の 5432 番でつながっています。表紙の写真は、申請サーバーの口で記録したものです。PC からの申請（4番）と返事（19番）の間に、DB サーバーとのやりとり（6〜16番）がはさまっています。

やりとりは4往復でした。最初の「空の問い合わせ」は、接続の池から借りた接続がまだ生きているかの確認です。次に BEGIN（トランザクションの始まり）と受付番号の取り出し、そして INSERT、最後に COMMIT（確定）。トランザクションは第9回でくわしく扱います。

注目してほしいのは、SQL の文と値が別々に送られていることです。文の中は $1, $2, $3, $4 という空欄のままで、そこに入る受付番号・日付・品目・金額は Bind という別の箱で届きます。こうしておくと、品目に悪意のある文字列が入っていても、SQL の文として読まれることはありません。第4回で、わざと文と値を混ぜて、どう壊れるかを見ます。

# DB サーバーで、表の中を見る
db$ psql -d expenses -c 'select id, applied_on, item, amount, status from expense order by id limit 3'
          id       | applied_on |  item  | amount  |  status
    ---------------+------------+--------+---------+-----------
     EXP-2026-0012 | 2026-10-26 | 交通費 | 1280.00 | submitted
     EXP-2026-0013 | 2026-10-26 | 交通費 | 1280.00 | submitted
     EXP-2026-0014 | 2026-10-26 | 交通費 | 1280.00 | submitted

DB サーバーの側で表を見ると、申請はたしかに1行ずつ入っていました。金額は 1280.00。画面から送った 1280 が、DB では小数2桁の数になっています。お金を Java でどう持つかは、次回の大事な話です。

第3章の申請は、curl の時計で 0.281 秒かかりました。ところが、そのあとの5件は 0.005〜0.010 秒です。

差のほとんどは、DB に話しかける前にあります。1件目は、届いてから最初の DB への問い合わせまで 0.22 秒、温まってからは 0.003 秒。ログを見ると、1件目は窓口に届く前に約 0.15 秒かかっていました。JSON を読む道具や入力チェックの道具が、最初の1回で準備を整え、Java のクラスが読みこまれ、よく通る道筋は JVM がだんだん速い機械語に直していきます。

月末には、経理の締め切りに向けて申請が集中します。PC から 50 件を同時に送ってみました。

# PC から 50 件を同時に送る
pc$ python3 par.py
    status {201: 50}
    total 0.157 s  slowest 0.135 s  fastest 0.030 s
# 申請サーバーのログで、受け取ったスレッドの名前を数える
app$ grep 窓口：申請を受け取った app.log | (スレッド名) | sort -u | wc -l
    36
# Java のプログラムのスレッドの数（起動直後は 38）
app$ ls /proc/760/task | wc -l
    66

50 件は 0.157 秒ですべて 201 になりました。ログを見ると、受け取ったスレッドは 36 種類。Tomcat は、届いた頼みごとをスレッド（プログラムの中の、同時に動ける作業員）に1件ずつ割り当てます。一方、DB への接続は起動時に張った 10 本を使い回します（接続の池、コネクションプール）。毎回 TCP のあいさつからやり直さないための工夫で、ネットワーク編第6回の「接続の使い回し」そのものです。

36 人の作業員が 10 本の電話を順番に使う形なので、電話の空き待ちが起きます。スレッドの数、接続の数、仮想スレッド（Java 21 から）の話は、第15回で測ります。

この申請サーバーは、Spring Initializr（start.spring.io）で作った雛形に、Java のファイル5つと表の定義（schema.sql）を書き足し、設定を少し書きかえたものです。ビルドすると、1つの jar ファイルになります。

Java は雛形の1つを含めて 112 行。HTTP の受け取り、JSON の読み書き、入力チェック、接続の池は、すべてライブラリの仕事でした。それ自体は良いことです。ただ、ライブラリが何をしているか知らないと、動かなくなったときに手が出ません。だからこの連載は、第3回と第4回であえて素手で HTTP と DB を扱い、第5回で Spring Boot に戻ってきます。

今日の申請サーバーは、まだ「受け取って、しまう」だけです。業務システムのバックエンドには、ほかにも定番の仕事があります。この連載で扱う順に並べました。

DB との読み書きには、JPA と MyBatis という2つの有名なやり方があります。第8回で両方を同じ申請で試し、違いを比べます。それまでは、SQL を自分で書く素直なやり方（Spring の JdbcClient）で進めます。

次回から手を動かせるように、道具をそろえておきましょう。

Maven は、雛形に入っている mvnw（Windows は mvnw.cmd）が自動で用意してくれるので、別に入れなくてもかまいません。