正直に告白します。僕はこれまで、なんとなくログを出していました。
「エラーが起きたら怖いから、とりあえず try-catch してログに残しておこう」
「ないよりはマシだろう」

でも、いざ本番で障害が起きたとき、そのログは僕を助けてくれませんでした。
深夜のアラート対応で、システムエラーが発生しました とだけ書かれたログを前に途方に暮れた経験、皆さんにもありませんか？

今回は、そんな「なんとなくログ」を卒業し、トラブルシューティングや分析に本当に役立つ「使えるログ」を設計するために学んだことをまとめました。

ログの目的を再定義する

そもそも、なぜログを書くのでしょうか？ チームで決まっているからではなく、エンジニアとして以下の3つの目的を意識する必要があります。

1. トラブルシューティング（Why & Where?）
   • 「なぜ落ちたのか」「どこで落ちたのか」を特定し、バグを再現・修正するため。
2. 可観測性・分析（Observability）
   • 「この機能、どれくらい使われてる？」「処理に何秒かかってる？」といったシステムの健康状態やユーザー行動を知るため。
3. 監査・セキュリティ（Security）
   • 「いつ、誰が、重要なデータを変更したか」の証跡を残すため。

これらを意識すると、「とりあえず出力」ではなく「目的に合わせて出力」する必要があることに気づきます。

構造化ログってなんや

ログ設計を学ぶと必ず出てくるのが「構造化ログ（Structured Logging）」です。

構造化ログとは「ログを人間への手紙ではなく、機械へのデータとして扱う」ということです。

非構造化ログ

従来のテキスト形式のログです。

// 人間には読めるけど、機械（検索）には辛い
Log::error("User 123 failed to login from 192.168.0.1");

これだと、「ユーザーID 123 のエラーだけ集計したい」と思ったときに、正規表現で頑張って文字列解析をしなければなりません。
ログの文言が少し変わっただけで検索できなくなるので、運用が非常に辛くなります。

構造化ログ

ログをJSONなどの形式で出力します。

// メッセージとデータを分ける
Log::error("Login failed", [
    "user_id" => 123,
    "ip_address" => "192.168.0.1",
    "event" => "auth_error"
]);

これが出力されると、以下のようなJSONになります。

{
  "level": "ERROR",
  "message": "Login failed",
  "context": {
    "user_id": 123,
    "ip_address": "192.168.0.1",
    "event": "auth_error"
  },
  "datetime": "2024-01-07T12:00:00+09:00"
}

こうしておけば、DatadogやCloudWatch Logsなどのログ管理ツールで context.user_id = 123 のようにクエリ一発で検索・集計ができます。

現代のWeb開発では、ログは「読むもの」ではなく「検索・集計するもの」です。
構造化ログはマストと言えます。

ログ設計の実践

では、実際にコードを書くときに何を意識すべきでしょうか。

やるべきこと

コンテキスト（文脈）を含める

「エラーです」だけでは無意味です。
「その時何が起きていたか」の情報を連想配列（Context）として渡しましょう。

何が起こったかを把握するためにも 5W1H を意識するといいかもですね。

• 誰が？ (User ID)
• 何を？ (Input Data)
• どこで？ (Request URL, IP Address)

トレースID (Trace ID / Request ID) を通す

これが今回一番の学びでした。
「1回のリクエスト」に対して、ユニークなID（Trace ID）を割り当て、それを全てのログに含めます。

// 理想的なログ出力
{
    "message": "DB error",
    "request_id": "a0eebc99-9c0b...",  // これ
    "user_id": 101
}

これがあれば、マイクロサービスや非同期処理でログがバラバラになっても、IDで検索して「一連の処理の流れ」を追うことができます。

Laravelなどでは、ミドルウェアで自動的にIDを発行し、Log::shareContext() 等を使って全ログに自動付与する設定を入れておくと、コードを書くときに意識しなくて済むので最高です。

ログレベルを適切に使い分ける

チーム内の基準に従いましょう。ない場合は基準を決めておきましょう。

下記は一例です。

• ERROR: 即時対応が必要（深夜でも電話がかかってくるレベル）。
• WARN: 異常だがシステムは稼働継続可能（後で要確認）。
• INFO: 正常系イベント（KPI分析や動作確認用）。
• DEBUG: 開発時のデバッグ用（本番では出さない）。

アンチパターン

機密情報の出力

パスワード、アクセストークン、クレジットカード番号、個人情報（PII）をログに出してはいけません。

ログファイル自体が漏洩したときのリスクが甚大です。平文なのでね。

「とりあえずcatchしてログ」による握りつぶし

一番やりがちなやつです。

try {
    $user->save();
} catch (Exception $e) {
    // 最悪なパターン：エラーが起きた事実だけログして、処理を続行してしまう
    Log::error("Error happened"); 
}

これだと、データ不整合が起きているのにシステムが動き続け、後で原因不明のバグになります。
対処できないエラーはログに出すだけでなく、適切に例外を再スローするか、エラーレスポンスを返す必要があります。

ログ運用

「ログをどこに出すか」も重要です。

DockerやKubernetesなどのコンテナ環境では、「標準出力（stdout/stderr）に吐く」のが定石です（The 12-Factor Appの思想）。

アプリは標準出力にJSONを流すだけ。あとはFluentdやDatadog Agentがそれを拾って、S3やログ管理基盤に転送する。アプリは「ログの保存場所」に関知しない設計にするのがモダンな運用です。

5. ログローテート

最後に、地味だけど大事な「お掃除」の話です。 もしファイルにログを出力する場合、書き続けるといつかディスクが溢れます。数GBのテキストファイルを開こうとしてエディタが固まった経験、ありますよね？
（いつぞやに対応したEC2のアラート対応で、15GBのログファイルがサーバーを圧迫していた事件がありました。）

• ローテート（Rotation）： 日次やサイズ指定でファイルを分割する（例: app.log -> app.log.2024-01-07）。
• 保持期間（Retention）： 「14日経過したら削除する」といったルールを決める。

PHP（Monolog）なら RotatingFileHandler を使うことで簡単に実装できますし、Linuxの logrotate コマンドで管理することもあります。

「ディスクフルでサーバーダウン」は一番悲しい障害なので、リリース前に必ず確認しましょう。

おわりに

ログ設計を見直すことは、「未来の自分やチームメイトへの思いやり」です。

障害発生時、適切なログ（構造化され、Trace IDがあり、必要な情報が詰まっているログ）があれば数分で解決できる問題が、ログがないために数日かかることもあります。

「何かあったときに、このログを見て原因がわかるか？」 「一年後の自分がこのログを見て感謝するか？」

そう自問しながら、明日からの Log::info() を書いていきたいと思います。

AIに頼めば、ものの数秒で大量のコードが生成されます。
まるで魔法のようですが、同時にこうも思うのです。「これ、本当に動くの？」「仕様、合ってる？」と。

大量に出力されるコードの波に飲まれず、「人間が手綱を握り続ける」ために僕が実践してきた開発のTipsを書き残しておきます。

これは、2026年の自分への手紙でもあります。
「あの頃はそんな苦労をしてたんだな」と笑って読み返せますように。

機会にできることは機械に任せる（Lint / Pre-commit / Auto Format）

AIは優秀ですが、たまにインデントを崩したり、変な書き癖を出してきたりします。
生成された大量のコードを目視でレビューして「ここ、スペース空いてないよ」なんて指摘するのは、人間のやる仕事じゃありませんよね。

だからこそ、Lint と Pre-commit、そして 自動フォーマット は必須でした。

• 保存＝整形（Auto Format）
  エディタで保存した瞬間に、コードが綺麗になる設定はマスト。AIが吐き出したコードを貼り付けた瞬間、プロジェクトの規約に合わせて「シュッ」と整う快感。これがないと精神衛生が保てません。
• コミット前の門番（Pre-commit）
  Gitにコミットする前に、Linterが自動で走るように設定しました。型エラーや未使用変数は、人間が気づく前に機械に弾いてもらう。

「コードの見た目」や「単純なミス」に脳のメモリを使わない。これがAI時代を生き抜く第一歩でした。（AI開発がどうっていう話ではないがより一層重要になっている

実装指示は細かくStepByStep形式

最終的なゴールを明示したうえで、StepByStepで実装させました。

ゴールは .documents にMarkdownを配置し、その仕様書通りになるように指示をします。

## As Is

## To Be 

## Task

## Remarks

1. 〇〇を最終ゴールとします。実装方針を出して。
2. ツッコミを入れる
   • Step1の実装のセキュリティホールは？
   • タイムアウトの条件は〇〇に
3. テスト書いてもらう
4. もちろんRed
5. テストのレビュー
   • テスト問題なければ実装
   • 問題あれば2を見直す
6. テストがGreenになるような実装

この辺はガイドラインやコーディング規約などを整備すればよかったのかなぁと考えている反省点です。

テスト戦略：AIに任せる部分、僕が譲らない部分

ここが一番のキモです。
AIはコードを書くのは早いですが、「僕たちが本当に作りたいもの」を100%理解しているわけではありません。
だからテストの役割分担をこう決めました。

単体テスト（ViteTest / PHPUnit）

関数単体や小さなロジックの検証には、ViteTestやPHPUnitを使いました。
ここはAIにも手伝ってもらいやすい領域です。「この関数のテスト書いて」と言えば、エッジケースまで網羅したテストを提案してくれます。

※ 単体テストをAIに書いてもらうために、関数は限りなく小さくするような単一責任の原則でAIに実装してもらっています。ぜーんぶAIです。

Featureテスト（結合・機能テスト）は「僕」が書く

けれど、機能全体が正しく動くかを確認するFeatureテストだけは、僕自身の手で書くようにしました。
これには明確な理由が2つあります。

1. コードの理解：
   AIが書いたブラックボックスなコードも、テストを書く過程で読み解く必要があります。「どう動くべきか」を定義するのは人間です。
2. 要求仕様の達成：
   求められている「要件」を満たしているか判定できるのは、今のところまだ人間だけです。

「AIにコードを書かせるなら、人間はテスト（仕様）を書け」 これが2025年の僕の合言葉でした。
テストが通る＝仕様を満たしているという安心感があって初めて、AIのスピードを享受できるんです。

2026年の僕へ

どうですか？ 2026年の開発現場は。

AIが仕様の矛盾すら指摘して、テストまで完ぺきに書いてくれるようになっているのでしょうか。

もしそうなっていたとしても、2025年の僕は「正しく動くものを届けたい」という一心で、Linterを設定し、Featureテストを書いていたことを覚えていてください。

エンジニアとしての仕事に楽しさは残っていますか？2025年末では、だんだんと辛くなってきています。

それじゃ、また。良い開発ライフを！

PHPアプリケーションのコンテナイメージを作成する際、ビルドに必要なツール（Composer、各種コンパイラなど）をすべて含めてしまうと、イメージが肥大化し、セキュリティリスクも増大します。

この課題を解決するのが、コンテナビルドの効率を最大化する技術、マルチステージビルドです。

マルチステージビルドとは？

マルチステージビルドとは、一つのDockerfile内で複数のFROM命令（ステージ）を定義し、最終的なイメージにデプロイに必要なファイルだけをコピーする手法です。

役割分担

1. ビルドステージ (Build Stage):
   • 目的: アプリケーションのビルドと依存関係の解決。
   • 使用イメージ: 大きなイメージ（例: composer:latest、php:8.3-fpmなど）。
   • 作業: Composerによる依存パッケージのインストール、フロントエンドアセットのコンパイル、テストの実行などを行います。
   • 特徴: このステージは最終的なデプロイには使用されません。
2. 最終ステージ (Final Stage):
   • 目的: アプリケーションの実行環境の構築。
   • 使用イメージ: 軽量なイメージ（例: php:8.3-fpm-alpine、distrolessなど）。
   • 作業: ビルドステージで生成された成果物（例: vendorディレクトリ、コンパイル済みバイナリ、PHPコード）のみをコピーします。

メリット

• イメージサイズの劇的な削減: ビルドツールやキャッシュ、開発用の依存関係が最終イメージから完全に除外されます。
• セキュリティ向上: 最終イメージが最小限の構成になるため、攻撃対象となる領域が縮小します。
• ビルド時間の短縮: 軽量なイメージを使用することで、プル時間が短くなります。

PHPアプリケーションでのマルチステージビルド

PHPアプリケーションの典型的なマルチステージビルドは、Composerによる依存関係の解決を分離することに焦点を当てます。

Dockerfile

以下のDockerfileは、Composerで依存関係を解決するステージと、それを使ってアプリケーションを実行する最小限のステージに分離しています。

# =============================================
# ステージ1：build_stage（依存関係の解決）
# =============================================
FROM composer:latest AS build_stage 
WORKDIR /app 
# 先に依存関係ファイルだけをコピー（キャッシュ効率化のため）
COPY composer.json composer.lock ./ 
# 本番環境用に最適化してインストール 
# --no-dev: 開発用パッケージを除外
# --optimize-autoloader: オートローダーを最適化して高速化 
RUN composer install \
--no-dev \
--no-interaction \
--optimize-autoloader 
# =============================================
# ステージ2：final_stage（最小限の実行環境）
# =============================================
# 軽量なAlpine LinuxベースのPHP-FPMイメージを使用
FROM php:8.3-fpm-alpine AS final_stage 
# セキュリティ：実行用の非特権ユーザーを作成
RUN adduser -D appuser
USER appuser
WORKDIR /var/www/html
# ステージ1からvendorディレクトリのみをコピー
# --chown で所有権を同時に変更するのがポイント
COPY --from=build_stage --chown=appuser:appuser /app/vendor ./vendor
# アプリケーションのソースコードをコピー
COPY --chown=appuser:appuser . .
 
# PHP-FPMを起動 
EXPOSE 9000
CMD ["php-fpm"]

実行手順

1. プロジェクトルートに配置: 上記のDockerfileをプロジェクトのルートディレクトリに配置します。
2. docker buildを実行: 通常通りdocker buildコマンドを実行するだけです。Dockerエンジンが自動的にマルチステージビルドを処理します。

docker build -t my-php-app:prod .

PHPでのポイント

1. composer_stageの利用: Composerをインストールする手間を省くため、公式のcomposerイメージをビルダーとして使うのが最も効率的です。
2. --no-dev: 開発時のみ必要なパッケージ（テストフレームワークなど）は最終イメージに含めないようにします。
3. USER nonroot: セキュリティのため、最終ステージでは必ずroot権限を放棄し、非特権ユーザーでアプリケーションを実行するように設定しましょう。（これにより、低ポート番号の使用には制約が生じますが、セキュリティが大幅に向上します）
4. COPY --fromの活用: この命令が全てです。Composerの巨大なキャッシュやビルドツール群を最終イメージから排除し、必要なvendorディレクトリだけをクリーンにコピーします。

マルチステージビルドは、軽量で安全なPHPコンテナイメージを作成するための必須技術です。ぜひあなたのプロジェクトに導入してください。

しかし、ローカルのDocker Compose環境では問題なく動作しても、AWSのECS Fargateのような本番環境にデプロイしようとすると、いくつかの疑問に直面します。

• 「NginxとPHP-FPMコンテナはどう連携させるのがベスト？」
• 「fastcgi_pass ってローカルと設定を変える必要ある？」
• 「InertiaでビルドしたReactのJS/CSSファイルは、結局どのコンテナに置くのが正解？」

この記事では、fastcgi_pass の基本から、ECS Fargateでの最適なコンテナ構成、そしてInertia/Reactプロジェクト特有の「静的ファイルの配置場所」問題までを、順を追って解説します。

fastcgi_pass とは？

NginxとPHP-FPMの「橋渡し」

まず基本のおさらいです。Nginxは高性能なWebサーバーですが、それ自体はPHPコードを実行できません。
一方、PHP-FPMはPHPコードを実行することに特化したプロセス（サーバー）です。

Nginxがクライアント（ブラウザ）から .php ファイルへのリクエストを受け取ったとき、そのリクエストをPHP-FPMに処理してもらう必要があります。

このとき、Nginxの設定ファイル（nginx.conf）で、「どのPHP-FPMに処理を依頼するか」の宛先を指定するのが fastcgi_pass ディレクティブです。

location ~ \.php$ {
    # ...
    # ↓ この一行が「橋渡し」の指定
    fastcgi_pass php-fpm-server:9000; 
}

ローカル開発 (Docker Compose) での構成

ローカル開発では、「1コンテナ1責務」の原則に従い、NginxとPHP-FPMを別々のコンテナとして docker-compose.yml で定義するのが一般的です。

# docker-compose.yml (抜粋)
version: '3'
services:
  # Nginxコンテナ
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./laravel-project:/var/www/html

  # PHP-FPMコンテナ
  php:
    build: . # PHP-FPMとLaravelコードを含むDockerfile
    volumes:
      - ./laravel-project:/var/www/html

この構成では、NginxコンテナとPHPコンテナは 別々のネットワーク空間 に存在します。Docker Composeが提供する内部ネットワークを介して、サービス名で通信します。

したがって、NginxコンテナからPHPコンテナへは、php というサービス名（ホスト名）を使ってアクセスします。

# nginx.conf (Docker Compose用)
location ~ \.php$ {
    # ...
    # 'php' サービス（コンテナ）の 9000番ポートに転送
    fastcgi_pass php:9000;
}

（※ このTCP/IP通信によるパフォーマンスやセキュリティの懸念は、コンテナ間通信がDockerの内部ネットワークに限定されていれば、実用上ほとんど問題になりません。）

【1タスク2コンテナ】本番 (ECS Fargate) での構成：

さて、本題のECS Fargateです。
ECSでは、docker-compose.yml に相当するものとして「タスク定義 (Task Definition)」を使います。

ここで重要なキーポイントは、「1つのタスク定義の中で、NginxコンテナとPHP-FPMコンテナの2つを定義する」ことです。

これら2つのコンテナは、1セットで「Webアプリケーションサーバー」として機能します。

ECS Fargateでのfastcgi_passはどうなる？

ECSの同一タスク内で実行されるコンテナは、同じネットワーク空間（ネットワークモード awsvpc）を共有します。

これは、Nginxコンテナから見ると、PHP-FPMコンテナが「他人」ではなく、「自分自身（localhost）」として見えることを意味します。

したがって、ECS Fargate用のNginxイメージに含める nginx.conf の設定は、以下のようになります。

# nginx.conf (ECS Fargate用)
location ~ \.php$ {
    # ...
    # サービス名ではなく、localhost (127.0.0.1) を指定する
    fastcgi_pass 127.0.0.1:9000;
}

タスク定義のイメージ

タスク定義では、以下のように設定します。

• コンテナ-A: php-fpm-container
  • イメージ: （Laravelコードを含むPHP-FPMイメージ）
  • ポートマッピング: なし (外部に公開する必要はないため)
• コンテナ-B: nginx-container
  • イメージ: （設定済みのnginx.confと静的ファイルを含むNginxイメージ）
  • ポートマッピング: 80:80 (ALBからのトラフィックを受け取るため)

ALB（ロードバランサー）からのトラフィックはNginxコンテナが受け取り、必要に応じて localhost:9000 を介してPHP-FPMコンテナに処理を渡します。

Inertia/Reactのビルドファイルはどこに置く？

ここで、Inertia/React構成特有の問題に直面します。

「InertiaはLaravel（PHP）がビューを配信する仕組みだから、npm run build で生成された public/build フォルダは、PHP-FPMコンテナにだけ置けば良いのでは？」

これはよくある誤解ですが、パフォーマンスと責務分離の観点から、ビルドした静的ファイル（JS/CSS）はNginxコンテナに配置するのが正解です。

この理由を理解するために、Inertiaのページが読み込まれる2段階のフローを見てみましょう。

ステップ1: HTMLシェルのリクエスト (PHP-FPMが処理)

1. ブラウザが https://example.com/dashboard にアクセスします。
2. ALB → Nginxコンテナがリクエストを受け取ります。
3. NginxはこれがPHPのリクエストだと判断し、fastcgi_pass 127.0.0.1:9000 を使ってPHP-FPMコンテナに転送します。
4. PHP (Laravel) が起動し、Inertiaは app.blade.php をレンダリングしようとします。
5. このとき、PHPは public/build/manifest.json を読み取り、HTMLに含めるべきJS/CSSのファイル名を特定します。
6. PHPは以下のようなHTMLの「ガワ」を生成し、Nginx経由でブラウザに返します。

   <html>
   <head>
       <script src="/build/assets/app.12345.js" defer></script>
       <link rel="stylesheet" href="/build/assets/app.67890.css">
   </head>
   <body>
       <div id="app" data-page="..."></div>
   </body>
   </html>
   

ステップ2: 静的アセット(JS/CSS)のリクエスト (Nginxが処理)

1. ブラウザは、ステップ1で受け取ったHTMLを解析します。
2. 「/build/assets/app.12345.js と /build/assets/app.67890.css が必要だ」と判断し、ブラウザは別途2回のリクエストをサーバーに送信します。
3. このリクエストは、もはやPHPとは全く関係ありません。
4. ALB → Nginxコンテナがこの2つのリクエストを受け取ります。
5. Nginxは「自分の管理下（public フォルダ）にそのファイルがあるか？」を探します。
6. Nginxコンテナに public/build/ 以下の実体ファイルが存在するため、NginxはPHP-FPMを起動することなく、それらの静的ファイルを超高速でブラウザに直接返します。

もし、NginxコンテナにJS/CSSファイルがなければ、このリクエストもPHP-FPMに転送されてしまい、「JSファイルを取得するためだけにLaravelを起動する」という深刻なパフォーマンスボトルネックが発生します。

CI/CDでのベストプラクティス

上記2ステップから、CI/CDパイプラインでDockerイメージをビルドする際は、以下の構成が最適です。

1. npm run build を実行し、public/build ディレクトリを生成します。
2. PHP-FPMイメージのビルド:
   • Laravelのコード（app/, routes/ など）をコピーします。
   • ステップ1のために public/build/manifest.json をコピーします。（リンク生成に必要）
3. Nginxイメージのビルド:
   • nginx.conf をコピーします。
   • ステップ2のために public フォルダ全体（index.php と、public/build 以下の 全てのJS/CSSファイル を含む）をコピーします。（静的アセットの配信用）

結論

manifest.json はPHP-FPMコンテナに、JS/CSSの実体ファイルはNginxコンテナに必要です。

両方のイメージに public フォルダ（または public/build）全体をコピーするのが、最もシンプルで確実な方法です。

まとめ

ECS Fargateで Laravel + Inertia + React 構成を動かすための要点をまとめます。

1. 構成: 「1タスク2コンテナ（Nginx + PHP-FPM）」構成を採用します。
2. fastcgi_pass: NginxからPHP-FPMへの通信は、同一タスク内のため fastcgi_pass 127.0.0.1:9000; を指定します。
3. 静的ファイル: ビルドしたJS/CSSは、パフォーマンス最適化のためNginxコンテナに配置し、Nginxから直接配信させます。
4. manifest.json: HTMLシェル生成のため、PHP-FPMコンテナにも manifest.json が必要です。

この構成により、PHP-FPMは動的処理に専念し、Nginxは静的ファイルの高速配信に専念するという、「1コンテナ1責務」のメリットを最大限に活かした、スケーラブルな本番環境を構築できます。

Ubuntu：24.04
PHP：8.2
Laravel：11.x

起こったこと

NginxをWebサーバーとして、LaravelアプリケーションとPHP-FPMを連携させている環境で、ある日突然 upstream sent too big header while reading response header from upstream というエラーがNginxのエラーログに表示され、Webサイトが正常に表示されなくなリマした…

調べていくと、このエラーは、PHP-FPM（アップストリームサーバー）がNginxに返そうとしたHTTPレスポンスヘッダーのサイズが、Nginxが受け入れられる設定値の上限を超えてしまった場合に発生します。

特にLaravelのような動的なアプリケーションでは、セッション情報やクッキーの肥大化が原因で発生しやすい問題とのことでやんす。

エラーが起きる原因は？

NginxがWebサーバーとしてクライアントからのリクエストを受け取り、それをバックエンドのPHP-FPM（FastCGIプロセス）に渡して処理してもらいます。

PHP-FPMが処理を終えてNginxに応答を返す際、そのHTTPレスポンスにはヘッダー情報が含まれます。このヘッダー情報がNginxが設定しているバッファのサイズを超えると、エラーが発生してしまいます。

主な原因として、以下のようなものが挙げられます。

• セッションデータの肥大化: Laravelなどのフレームワークでセッションをクッキーベースで管理している場合、ユーザーが多くの情報をセッションに保存したり、ショッピングカートに大量のアイテムを追加したりすると、クッキーのサイズが大きくなります。この大きなクッキー情報がレスポンスヘッダーに含まれることで、上限を超えてしまうことがあります。
• 多数のクッキーやカスタムヘッダー: アプリケーションが非常に多くのクッキーを設定している、または独自のカスタムヘッダーを大量に追加している場合も、ヘッダー全体のサイズが大きくなります。
• リダイレクトループ: 不適切なリダイレクト設定により、ブラウザが何度もリダイレクトを繰り返す際、そのたびに新しいクッキーやヘッダーが付与され、最終的にヘッダーが大きくなってしまうケースも考えられます。

解決策：Nginxの設定を調整する

最も手軽で直接的な解決策は、Nginxが受け入れられるヘッダーバッファのサイズを増やすことです。

Nginxの設定ファイル（通常は /etc/nginx/nginx.conf か、サイト固有の .conf ファイル）を開き、http ブロック内、または対象の server ブロック内に以下のディレクティブを追加または調整します。http ブロックに記述すると、すべてのバーチャルホストに適用されます。

http {
    # ... 他の http ブロック内の設定 ...

    # upstream sent too big header エラー対策
    # PHP-FPM（FastCGI）からのレスポンスヘッダーに対応するため、fastcgi_ のディレクティブを設定します。
    # 必要に応じて proxy_ のディレクティブも設定しますが、PHP-FPMの場合はfastcgi_を優先します。
    fastcgi_buffer_size 128k;   # FastCGIヘッダーバッファの初期サイズ。デフォルトは4k/8k。
    fastcgi_buffers     4 256k; # 256KBのバッファを4つ用意。合計1MB。

    # 必要に応じて、もしプロキシとして使用している場合も考慮するなら、こちらも設定
    # proxy_buffer_size   128k;
    # proxy_buffers       4 256k;
    # proxy_busy_buffers_size 256k;

    # ... 他の http ブロック内の設定 ...
}

ディレクティブの解説

• fastcgi_buffer_size: NginxがFastCGIからのレスポンスヘッダーを読み込むための最初のバッファサイズを指定します。デフォルト値（通常は 4k または 8k）よりも大きな値（例：128k）を設定することで、大きなヘッダーにも対応できるようになります。
• fastcgi_buffers: ヘッダーを含むレスポンス全体をバッファリングするためのバッファの数とサイズを設定します。上記の例では、256KBのバッファを4つ使用し、合計で1MBのバッファスペースを確保します。

注意点: これらの値を必要以上に大きくしすぎると、Nginxが使用するメモリ量が増加し、サーバーリソースを圧迫する可能性があります。まずはエラーが出なくなる最小限の増加から試し、サーバーの負荷状況を見ながら調整してください。

設定変更後の手順

1. Nginx設定ファイルを保存: 変更したNginx設定ファイルを保存します。
2. 設定ファイルのテスト:
   sudo nginx -t

    

   このコマンドで構文エラーがないかを確認します。test is successful と表示されればOKです。

3. Nginxのリロード:

   sudo systemctl reload nginx
   

    

   Nginxサービスをリロードして、新しい設定を適用します。

これで、Nginxが大きなHTTPレスポンスヘッダーを適切に処理できるようになり、「upstream sent too big header」エラーは解消されるはずです。

根本的な解決策：Laravelアプリケーション側の最適化

Nginxの設定でエラーを抑制できますが、Laravelアプリケーション側で不必要に大きなヘッダーが生成されている場合は、そちらの最適化も検討することをお勧めします。

• セッションデータの見直し:
  • クッキーに保存しているセッションデータが大きすぎる場合、データベースやRedisなどのサーバーサイドストレージにセッションを保存するようにLaravelの設定を変更することを検討してください。これにより、クッキーにセッションIDのみが保存されるため、クッキーのサイズを大幅に削減できます。Laravelのセッション設定は config/session.php で変更可能です。
• クッキーの管理:
  • アプリケーションが設定しているクッキーの数や、個々のクッキーのサイズを減らせないかレビューします。不要なクッキーは削除しましょう。
• カスタムヘッダーの確認:
  • アプリケーションがレスポンスに含めているカスタムHTTPヘッダーが多すぎないか、または内容が大きすぎないかを確認します。

Nginxの設定調整で当面のエラーは解消されますが、アプリケーションの効率性を高めるためにも、Laravel側のヘッダー生成ロジックを見直すことは良いプラクティスです。

セキュリティサポートが2022年末に終了して久しいPHP7系で動いているシステムが乗っかているサーバーの移行タスクです。

事の発端

CentOS 7のサポート終了がきっかけです。

DevOps系のお仕事に携わっている人なら理解してくれると思うのですが、サポートが切れた技術を継続して使用していくことの恐ろしさったら中々のものです。

まぁそんな事情があったので、CentOSを別のOSに移行していこうー！というノリで始まりました。

困ったことに

クラウドサービスはAWSを選択しているので、AWSが提供しているOSであるAmazonLinux2023を移行先のOSとして決定しました。

単純なLAMP環境を構築することが今回のタスクだったので、作業をガシガシ進めていくと一つの問題にぶち当たりました。

PHP7系がインストールできない…

Remiリポジトリ, EPELが使えない

そもそもの問題としてPHP7系は2022年末にサポートが切れているので、AmazonLinuxがサポートしている訳がありません。
普通に考えてみれば至極真っ当です。

今回のタスクでは、PHP7系を使うことは外せない要件として上がっていたので、どうしてもPHP7系が必要です。

こうなったらRemiリポジトリから持ってくるしかないなーと思っていた矢先、Remiリポジトリも使えないとのこと。（EPELがそもそも使えないため

AWS ドキュメント
EPEL
CentOSなどで使う、RemiRepositoryってなんだ？

今回の要件（PHP7系 install）を達成する事は、Amazonlinux2023 では不可能だと知った瞬間でした…

OS選定

CentOS の移行先で検索すると以下のOSたちがよくヒットしました。

• RedHatEnterpriseLinux
• AlmaLinux
• RockyLinux

PHP7系 が使えること 及び 互換性があること , ある程度の認知度 があるOSを選択したかったので、 RockyLinux で行くことに決定しました。

最終的にはRockyLinux上でRemiリポジトリを使用して目的の環境を作成することができたよーん。

感謝を捧げる

振り回された感が拭えないタスクだったのですが、誰が悪いとかはないなーという所感です。

CentOSのサポートが切れるのも、Amazonlinux2023 がPHP7 をサポートしていないのも、PHP7を使って未だに運用しているシステムも誰も悪くないです。
（PHP7に゙関しては早くバージョンアップしてほしい…

最終的には何とかなったので、 RockeyLinux のコントリビューターに感謝を捧げます

メモリ制限の設定 (memori_limit)

PHPスクリプトが消費することができる最大メモリ量を指定します。デフォルト設定では「128M」が多いですが、大規模なアプリケーションを扱う場合はこの値を増やす必要があります。不足するとスクリプトが突然停止することがあるため、適切なメモリ量を設定しましょう。

memory_limit = 256M

実行時間の制限 (max_execution_time)

スクリプトが実行を終了するまでの最大時間を秒単位で設定します。デフォルトは「30秒」ですが、時間がかかるプロセスを扱う場合はこの値を調整するこことが重要です。

max_execution_time = 60

エラーレポーティング (error_reporting)

開発中はすべてのエラーを表示することが重要です。しかし、本番環境ではエラー表示を抑えるべきです。この設定を通じて、どのレベルのエラーをレポートするかを制御できます。

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

ファイルアップロード (file_uploads)

ファイルアップロードを許可するかどうかを制御します。セキュリティ上の理由から、使用しない場合は無効化することが推奨されます。

file_uploads = On

セッションのセキュリティ設定

セッションIDの扱いには特に注意が必要です。セッションハイジャックを防ぐために、セッションIDの再生成やセキュアなクッキーの使用が推奨されます。

session.use_strict_mode = 1
session.cookie_secure = 1
session.cookie_httponly = 1

まとめ

これらの設定は、PHPのパフォーマンスとセキュリティを大きく向上させることができます。php.iniの設定は一見複雑に見えるかもしれませんが、それぞれの項目に慎重に注意を払い、アプリケーションのニーズに応じて適切に調整することが非常に重要です。この記事があなたのPHP設定を見直すきっかけになれば幸いです。

RESTful APIは、ウェブアプリケーションやウェブサービスで使われるプログラミングインターフェースです。
REST（Representational State Transfer）の原則に基づいて設計されており、ウェブ上のリソースへのアクセスや操作を統一的な方法で提供します。
リソースはURLで識別され、HTTPメソッド（GET、POST、PUT、DELETEなど）を使ってアクセスされます。

[getpost id=”1672″ cat_name=”1″ date=”0″]

SPA（シングルページアプリケーション）とは？

SPAは、ユーザーがアプリケーションを操作する際にページの再読み込みをせずに、必要なデータのみをサーバーから非同期に取得し、動的にページの内容を更新するウェブアプリケーションの形式です。

これにより、従来のマルチページアプリケーションに比べてユーザーエクスペリエンスが向上します。

僕が所属しているチームでもページのリロードが嫌だというユーザーの使用感からSPAへの移行が少しづつ始まってきています。
世間的にもSPAは流行っていますよね。（流行っているから偉いというわけではない。知ることが大事

RESTful APIとSPAの関係性

SPAでは、ページの初回読み込み時にアプリケーションの全てのコード（HTML、CSS、JavaScript）がロードされます。

その後のユーザーの操作によってデータが必要になる場合、SPAはRESTful APIを通じてサーバーからデータを非同期に取得します。
このデータはJSONやXML形式で返され、JavaScriptを用いてクライアントサイドで処理され、ページの一部分だけが動的に更新されます。

このアーキテクチャにより、SPAはユーザーにスムーズで反応の良いインターフェイスを提供できます。

RESTful APIはこのプロセスの背後にあるデータ通信の基盤となります。

PHPとReactを使った例

ここでは、PHPで書かれた簡単なRESTful APIと、Reactを使ったSPAの例を示します。

PHPによるRESTful API

PHPで簡単なAPIエンドポイントを作成します。この例では、GETリクエストを受け取り、簡単なJSONデータを返します。

<?php 
    header('Content-Type: application/json');
    $response = ['message' => 'Hello, world!'];
    echo json_encode($response); 

    // Response
    //{"message": "Hello, world!"} ?>

このPHPスクリプトは、サーバーに配置してのようにアクセスするとJSONが返されます。

ReactによるSPA

Reactで簡単なSPAを作成し、上記のAPIからデータを取得して表示します。

import React, { useState, useEffect } from 'react';
import axios from 'axios';

function App() {
  const [message, setMessage] = useState('');

  useEffect(() => {
    axios.get('http://yourserver.com/index.php')
      .then(response => {
        setMessage(response.data.message);
      })
      .catch(error => console.error('There was an error!', error));
  }, []);

  return (
    <div>
      <button>{message}</button>
    </div>
  );
}

export default App;

SPA（シングルページアプリケーション）とRESTful APIを使用する際には、セキュリティとパフォーマンスの両方に配慮することが重要です。
以下では、これらの観点から基本的なガイドラインをいくつか紹介します。

セキュリティ

1. HTTPSを使用する
   データの暗号化を確実に行うため、APIとの通信には常にHTTPSを使用します。（当たり前です）
   これにより、中間者攻撃（MITM）のリスクを減らすことができます。
2. CORSポリシーを適切に設定する
   クロスオリジンリソースシェアリング（CORS）ポリシーを適切に設定し、信頼できるオリジンからのリクエストのみを許可します。
   不適切なCORS設定は、セキュリティリスクを招く可能性があります。
3. 認証と認可
   JWT（JSON Web Tokens）やOAuthなどの堅牢な認証メカニズムを使用して、APIへのアクセスをセキュアに管理します。
   また、ユーザーの権限に基づいてアクセスを制御する認可も重要です。
4. 入力の検証とサニタイズ
    SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃を防ぐため、サーバー側とクライアント側の両方で入力値の検証とサニタイズを行います。
5. 依存関係のセキュリティ
   使用するライブラリやフレームワークのセキュリティ脆弱性に注意し、定期的に更新を行い脆弱性を修正します。

この辺の対策については過去に記事にしていますので時間ある人は読んでみてくださーい

[getpost id=”1618″ cat_name=”1″ date=”0″][getpost id=”1256″ cat_name=”1″ date=”0″]

パフォーマンス

1. コードの分割
   ユーザーが必要とするコードのみをダウンロードするように、コード分割（Code Splitting）を実装します。
   これにより、初期ロード時間を短縮できます。
2. キャッシュ戦略の利用
   静的リソースやAPIレスポンスのキャッシュを適切に利用することで、パフォーマンスを向上させることができます。
   ブラウザのキャッシュやCDNの利用が有効です。
3. 遅延ローディング（Lazy Loading）
    画像やコンポーネントなど、必要になるまでロードしないようにします。
   これにより、初期ロードのパフォーマンスを向上させることができます。
4. APIの最適化
   不必要なデータの送受信を避けるため、APIのレスポンスをできるだけ小さく保ちます。
   また、必要なデータのみを取得するためのフィルタリングやページネーションをAPI側でサポートします。
5. フロントエンドのパフォーマンス最適化
   Reactなどのフロントエンドフレームワークを使用する場合は、不要な再レンダリングを避け、メモ化（memoization）や仮想DOMの効率的な利用などのテクニックを活用します。

セキュリティとパフォーマンスは、アプリケーションの設計と開発の初期段階から考慮する必要があります。
これらの基本的なガイドラインを実践することで、ユーザーに安全で快適な体験を提供することができます。

Webの世界は複雑で、ちょっとしたことが大きな違いを生むんですよね。CORSもその一つ。

さあ、一緒にCORSを理解してきましょう〜

CORSって何？

まず、CORSって何？って話から始めます。

CORSは、Webページが異なるオリジン（つまり、異なるドメイン、プロトコル、またはポート）のリソースにアクセスする際のセキュリティメカニズムです。

つまり、あなたのサイトが他のサイトのデータを安全に扱うためのルールのこと。これがないと、セキュリティリスクが高まります。

なぜCORSが必要なの？

Webはオープンでつながっているけど、同時にセキュリティも重要です。

例えば、あなたがログインしているサイトAから、悪意のあるサイトBがデータを盗もうとするといったリスクがあります。

CORSは、このような不正なアクセスを防ぐために存在しているんです。
安全なWebのためには、必要不可欠なんですよ。

CORSの仕組み

CORSの基本は「信頼できるオリジンからのリクエストのみ許可する」ということ。

これは、サーバー側で設定され、ブラウザがこの設定に従います。

サーバーは、リクエストが来たときに「このオリジンからのリクエストはOKかな？」とチェック。

OKならリソースを提供し、ダメなら拒否。これで、安全にデータのやりとりができるようになります。

簡単なCORSの例

例えば、あなたのサイト（example.com）が、他のサイト（api.example.com）からデータを取得したい場合があるとします。

もし、api.example.comがCORSでexample.comを許可していれば、問題なくデータのやりとりができます。

でも、許可されていなければ、「CORSエラー」が発生してアクセスできないんです。

CORSをどう扱う？

開発者としては、CORSは頭痛の種になることも。

しかし、適切に設定することでセキュリティを確保しつつ、必要なデータ交換も可能になります。サーバーの設定を見直したり、必要に応じてオリジンを許可リストに追加することが大切です。

設定方法

素のPHP

※WEBサーバーにて設定することも可能ですが、今回はPHPでの実装を想定。

header("Access-Control-Allow-Origin: http://example.com");
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE");
header("Access-Control-Allow-Headers: Content-Type, X-Requested-With");

/**
* - http://example.com からのアクセスを許可
* - 許可メソッドは GET, POST, PUT, DELETE
* - リクエスト中に許可されるHTTPヘッダー
*     - Content-Type（リソースのメディアタイプ
*     - X-Requested-With（通常、Ajaxリクエストを識別するために使用される）
*/

Laravel

※Laravel 7.x以降ではデフォルトでCORS設定が組み込まれているっぽい。

return [
    'paths' => ['api/*'],
    'allowed_methods' => ['*'],
    'allowed_origins' => ['http://example.com'],
    'allowed_origins_patterns' => [],
    'allowed_headers' => ['*'],
    'exposed_headers' => [],
    'max_age' => 0,
    'supports_credentials' => false,

    /**
     * - http://example.com からのアクセスを許可
     *   'allowed_origins' => ['http://example.com']
     *   この設定は、http://example.com からのリクエストを許可します。
     * 
     * - 許可されるHTTPメソッド
     *   'allowed_methods' => ['*']
     *   この設定は、すべてのHTTPメソッドを許可します。特定のメソッドのみを許可する場合は、
     *   ['GET', 'POST', 'PUT', 'DELETE'] のように配列を編集します。
     * 
     * - 許可されるHTTPヘッダー
     *   'allowed_headers' => ['*']
     *   この設定は、すべてのHTTPヘッダーを許可します。特定のヘッダーのみを許可する場合は、
     *   必要なヘッダーを配列に追加します。
     */
];

まとめ

CORSは、Webの安全性を保つための重要なメカニズム。最初は複雑に感じるかもしれませんが、基本を理解すれば、より安全で効果的なWebアプリケーション開発が可能になります。

これにてCORSの基本を何となく理解！

本業とは別に取り組んでいた個人開発でマネタイズができず、サービスを終了させてしまったのでここで供養させてください。

RIP My Service…

作ったもの

HP 兼 予約サイト 兼 ECサイトなるシステムを開発しました。

僕が沖縄県出身ということもあり、沖縄の個人経営を営んでいる小さな企業さんを相手に営業の肩代わりをすることを目的にシステムを開発しました。

というのも沖縄県は観光地として有名でありながらもHPすら持たず、地元の口コミのみで経営を行っているお店が多々ある状態でした。

せっかくの観光地でありながらお客様を呼び込めないのはかなりもったいないという思いから作った次第でございます。

技術構成

マネタイズポイント

物販購入

沖縄ならではの商品が展開されるEC機能を開発しました。

1商品当たり個別に x％ の手数料をいただく契約になります。

予約

美容院やレジャー施設の予約を受け付ける機能を開発しました。

こちらもEC同様に1予約あたり、x円の手数料 or オプション契約 のどちらかを契約する想定でした。

売り方

沖縄出身ではあるものの都内で勤務しているということもあり現地での営業活動ができないという状況でした。
そのため、現地で営業活動を行ってもらうために地元の友だちに「俺はこれから月100万円稼ぐシステムを開発するから営業をしてくれ」と大きく誇張した言い分を持って営業活動をしてもらいました。

その友人は面白そうだからという理由で快く引き受けてくれ、以下のマーケティング手法で営業を行ってもらいました。

• SNS
  • Instagram
  • Twitter
• ブログ

先に結論から入るのですが、期間としては6ヶ月間行ってもらい、皆さんの想像通り契約は1件も入らなかったです。

なぜ売れなかったのか

知名度

これは誰しもが考えることだと思うのですが 認知されていないサービスにお金を払う ことは避けたいはずです。

尚更、登記もしていない個人が開発したシステムに対して自分の命であるお金を注ぐことはあり得ないです。

考えられる手法としては以下の手法が取れるはずです。

• 正しい営業をする
• 受託等で知名度を得る
• その他のサービスで知名度を得る（知名度が無いことによる無限ループが発生する…）

お客様が安心してこのサービスにはお金を投資できると胸を張って言えるようなシステムを構築するのは難しいですね。。。

効果を得られるか不安

知名度がないという理由にも近しいですが、当システムを使用することで利益を得られることに対する不安を拭い去る事はできませんでした。

なぜなら契約が1件もないということは実績が無いということですからお客様からすると不安しかありません。

世の中のスタートアップはどうやって利益を得ているんですか？？

県民性

こちらは確固たるデータがある訳ではないんですが、ハードに仕事をしないという県民性を見誤っていた可能性がある事を感じています。

沖縄は「のんかーな性格（のんきな性格）」と呼ばれる人が多い印象です。

事実として僕の知っている沖縄の経営者では食べていける分を稼げて楽しい毎日を送ることが大切という人が多いです。（4人だけしか知りませんが…）

そういった考えを持っている人に対して業務を効率化して売上を伸ばしましょうなんて言っても「忙しくなるなら現状のままで」といった答えが返ってくるに決まっています。

そのあたりをしっかりと調査する or ターゲットを先に見つける事が大切かなぁという印象です。

反省

僕はゴミを作ってしましました。

誰にも使われないシステムなんてゴミです。ただのゴミクズです。

今回は僕一人と頭の悪い友人の時間だけが溶けただけで済んで本当に良かったです。（実際には5万ほど運用費としてお金を使いました。）

仮に起業という形でサービスを開発していた場合は廃業に大きく近づいていたので、個人開発の一環でここまでの勉強ができたのは僕の才能かもしれません。笑

まだまだ作りたいものはあるので引き続き頑張っていきたいですねぇ〜