ランタイムアーキテクチャ

リクエスト処理フローと設定ポイント

なぜランタイムの理解が重要か？

エラーが発生した時、どの層で問題が起きているかを特定できないと対応が遅れます。 例: 5GBファイルアップロードエラー → PHPの設定だけでなく、 mod_fcgidのFcgidMaxRequestLenも確認が必要。

リクエスト処理の階層

1
クライアント / ネットワーク
接続タイムアウト、DNS解決、TLS handshake
↓
2
Webサーバー (Nginx/Apache)
LimitRequestBody、client_max_body_size、タイムアウト
↓
3
アプリケーションサーバー / ゲートウェイ
PHP-FPM、Gunicorn、Tomcat、各種タイムアウト・メモリ制限
↓
4
言語ランタイム
PHP: memory_limit、Java: -Xmx、Python: メモリ制限なし
↓
5
アプリケーション / フレームワーク
Laravel、Django、Spring Boot 等のフレームワーク設定

言語別アーキテクチャの違い

言語実行モデルプロセスモデル主な設定箇所
PHPリクエストごとに起動/終了FPM: プロセスプールphp.ini, php-fpm.conf, Apache/Nginx
Pythonワーカープロセス常駐Gunicorn: prefork/workergunicorn.conf.py, Nginx
JavaJVM常駐、スレッドプールマルチスレッドJVMオプション, server.xml
Goシングルバイナリ常駐goroutine (軽量スレッド)アプリケーション内設定

エラー調査の基本フロー

1. どの層でエラーが発生しているか特定

  • • Webサーバーのエラーログ (access.log, error.log)
  • • アプリケーションサーバーのログ (php-fpm.log, gunicorn.log)
  • • アプリケーションログ

2. その層の設定を確認

  • • タイムアウト値
  • • リクエストサイズ制限
  • • メモリ/CPU制限
  • • プロセス/スレッド数

3. 設定の依存関係を確認

例: FcgidMaxRequestLen >= post_max_size >= upload_max_filesize
上流の設定が下流より小さいと、下流の設定は意味がない

言語別ランタイム詳細

PHP

PHP Runtime

Apache/Nginx → mod_fcgid/PHP-FPM → PHP

Python

Python Runtime

Nginx → Gunicorn/uWSGI → Python

Java

Java Runtime

LB → Tomcat/Jetty → JVM → Application

Go

Go Runtime

シングルバイナリ、net/http、直接リクエスト処理