CDK、楽しいですよね。Typescript でインフラがかけるなんて最高です。でも、学習を始めていくとある壁にぶつかりました。

ネット上の「CDKでECS構築してみた！」系の記事を参考にすると、大抵の場合 VPCもECSもRDSも全部一つの lib/my-stack.ts に処理が書かれている」のです。サンプルコードとしてはわかりやすいのですが、いざ実務でLMAP環境を作ろうとすると⋯…

• VPC は更新頻度が低いからスタックを分けたい
• RDS はステートフルだから独立させたい
• ECS はアプリケーションコードのデプロイで頻繁に更新が入るかも

とスタックを分割したくなりませんか？
でも、分割した途端に「StackA で作ったVPCのIDをどうやってStackBにわたすの？」という問題が発生します。

当記事では、現時点での私の持論である スタック間のリソース共有を紹介します。

IDではなくオブジェクトを渡す

VPC スタックとECSスタックを分けるときに、ついやってしまいがちなのが VPC IDを Props で渡す という手法です。
Terraform に慣れていると、この発想になりがちですよね。

この手法では CDK の 型安全を活かすことが出来ないので、 VPCオブジェクトそのもの を渡すのがベストだと考えています。

私の構成案：
司令塔となる エントリーポイント app がバケツリレーのようにオブジェクトを渡していくイメージです。

1. VPCStack： VPCを作る。 public readonly vpcでVPCオブジェクトを公開する
2. APP： VpcStack からVPCオブジェクトをもらい、 ECSStackに渡す
3. EcsStack： 受け取ったVPC オブジェクトを使ってクラスターを作る

実際にコードを見ていきましょう。

型安全の恩恵を受ける

VPCStack ⇒ 渡す側

ここでは this.vpcをクラスのメンバ変数として公開しておきます。

// lib/vpc-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { Construct } from 'constructs';

export class VpcStack extends cdk.Stack {
  // 外部に公開するプロパティ（これが重要！）
  public readonly vpc: ec2.IVpc;

  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    this.vpc = new ec2.Vpc(this, 'LampVpc', {
      maxAzs: 2,
    });
  }
}

EcsStack ⇒ 受け取る側

ここがポイントデス。 vpcId: stringではなく、 vpc: ec2.IVpc というインターフェース型で受け取ります。

// lib/ecs-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { Construct } from 'constructs';

// Propsの定義：文字列ではなく「VPCの型」を指定する
interface EcsStackProps extends cdk.StackProps {
  vpc: ec2.IVpc;
}

export class EcsStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: EcsStackProps) {
    super(scope, id, props);

    // 文字列から検索する必要なし！そのまま使える
    const cluster = new ecs.Cluster(this, 'LampCluster', {
      vpc: props.vpc, 
    });
  }
}

bin/app.ts ⇒ 繋ぐ場所

最後にエントリーポイントで紐づけます。

// bin/app.ts
import * as cdk from 'aws-cdk-lib';
import { VpcStack } from '../lib/vpc-stack';
import { EcsStack } from '../lib/ecs-stack';

const app = new cdk.App();

// 1. VPCを作る
const vpcStack = new VpcStack(app, 'VpcStack');

// 2. VPCオブジェクトをECSスタックに渡す
const ecsStack = new EcsStack(app, 'EcsStack', {
  vpc: vpcStack.vpc, // ここでバケツリレー
});

この方法の何が良いの？

この方法のメリットは2つあると思っています。
（一言で言うとプログラミング言語による抽象化です。）

1. 圧倒的な型安全性
   もし間違えてS3のオブジェクトを渡そうとすると、エディタがその場でエラーを吐いてくれます。
   「デプロイしてみたらIDが違ってコケた」という悲劇が未然に防げます
2. 記述がメチャ楽
   受け取る側で ec2.Vpc.fromLookup() のようなインポート処理を書く必要がありません。渡された瞬間から props.vpc.addInterfaceEndpoint のようにメソッドが使えます

議論したいポイント

ここまで「これが正解だ」という顔で書いてきましたが、実はこの構成には明確なデミリットもあります。それは、 スタック同士が密結合 になることです。

Cloudformation の Export/Import 機能でガッチリ紐づいてしまうため、以下のような問題が置きます。

• スタック間の参照があるため、「VPCだけを作り直したい」が出来ない

ただし、私は上記のような問題が発生したとしても、
LAMP 環境という一つのアプリケーションにおいて、VPCとECSは「運命共同体」にあたるため問題ないと考えています。

「ECSが生きているのにVPCだけ消したい」という状況は稀ではないでしょうか。そのためこの密結合はあえて受け入れるべき仕様だと割り切っています。

ただ、もし組織の基盤となる共通のVPCを作る場合は、ライフサイクルが異なるため、疎結合なID渡しにするのが正解なのかもしれません。

皆さんの構成おしてほしいっす。

しかし、ローカルの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側のヘッダー生成ロジックを見直すことは良いプラクティスです。

静的コンテツの配信サーバーの役割をこなしたり、イレブンナインの耐久性を持ったストレージサービスといった点からAWSの中でも大好きなサービスです。

便利が故にコスト面でネックになってしまう状況が多々あるかと思いましたので、個人的に経験したコストダウンの設計手法をご紹介したいと思いますー！

手始めに

まず初めにS3に関わる費用のざっくりとした内訳を確認しておきましょう。

• ストレージ
• データ転送（IN/OUT）
• セキュリティコントロール
• レプリケーション
• etc…

一般的な運用を想定すると ストレージ と データ転送 が費用の大部分を占めるはずです。

その中でストレージに関しては、
不必要なデータを置かない, データのライフサイクルを短くする, ストレージクラスを最適なものに設定するなどはありますが、S3にどのようなデータを置くかは各システムで要件が異なってくるため、費用の削減はあまり期待できません。

そうなってくるとデータ転送の部分でコストを最適化するのが必要になってきます。

通信量削減の取り組み

イメージ図

やりたいこと

S3に゙保管しているコンテンツを毎回S3からダウンロードすることを辞めるための設計です。

これにより、キャッシュを用いてS3からの転送量を大幅に減らすことができます。（サイトへのアクセスが多ければ多いほど今回の設計は意味を増してくると思います。

添付した画像のフローを改めて文字に起こします。

1. ページアクセス後に、必要なViewやCSS、画像などがリクエストされます。
2. まずアプリケーションサーバー（EC2）にコンテンツがキャッシュされているか確認します。
3. キャッシュに存在する場合は、そのままレスポンスを返します（転送料金が発生しません）。
4. キャッシュに存在しない場合は、S3からコンテンツを取得し、その後キャッシュします（S3へのアクセスを減らす）。

ChatGPT に計算してもらった

### 東京リージョン（Asia Pacific (Tokyo)）でのS3のデータ転送料金

2023年9月現在、東京リージョンでのS3のデータ転送料金は次の通りです：

- 最初の1GB: **無料**
- 1GB～10TBまでのデータ転送: **$0.114/GB**

これに基づいて、東京リージョンでの転送料金削減を計算します。

### 仮定
- 1回のアクセスでS3からダウンロードされるデータの量：**1MB**
- 1日のアクセス数：**10,000回**
- キャッシュ成功率：**80%**
- 東京リージョンでのS3データ転送料金：**$0.114/GB**

### 計算式（東京リージョン）
1MBのデータが10,000回ダウンロードされる場合：
```
1MB × 10,000 = 10,000MB = 10GB
```

#### S3へのアクセスがない場合のコスト（全アクセスがS3の場合）
```
10GB × 0.114 = $1.14
```

#### キャッシュ導入後のコスト
キャッシュ成功率80%の場合、S3へのアクセスが20%：
```
10,000 × 0.2 = 2,000回
```

2,000回分のダウンロードデータ量：
```
1MB × 2,000 = 2,000MB = 2GB
```

これに対する転送料金：
```
2GB × 0.114 = $0.228
```

#### 削減額
S3にすべてのリクエストを送る場合のコストは**$1.14**、キャッシュを利用した場合のコストは**$0.228**。
したがって、削減できる金額は：
```
$1.14 - $0.228 = $0.912
```

### 結論
キャッシュを使うことで、東京リージョンの場合は、
1日あたり約**$0.912**の転送料金削減が見込めます。

これを1ヶ月（30日）分に換算すると、約**$27.36**の削減が期待できます。

もちろん、アクセス数やキャッシュ成功率、ダウンロードデータのサイズによって結果は変わりますが、
このざっくりとした計算での削減効果は**80%**程度です。

注意点①

キャッシュクリアの方法を適切に設定しない場合、全てのコンテンツリクエストがキャッシュデータを返却してしまいます。

各方面から以下のようなお叱りが届いてしまうので、今回ご紹介した設計を取る場合は、しっかりとキャッシュクリアの戦略を練りましょう。。。

注意点②

アプリケーションサーバーにコンテンツを配置するので、アプリケーションサーバー自体のストレージを圧迫する可能性が大いにあります。
アプリケーションサーバーのストレージを外部に移す目的でS3を導入している場合は、今回の手法は取れないので、CDNサービス等を用いてキャッシュさせるのも一つの手になってくると思います。

注意点③

注意点②と同様にアプリケーションサーバーにコンテンツを配置するが故の問題として、センシティブなデータをアプリケーションサーバーに配置する可能性があります。
例： 個人情報の類のコンテンツ（運転免許証、何らかの明細）

これらを一時的にではありますが、アプリケーションサーバーに配置するのがシステム要件的にNGの場合は、絶対に今回の手法は取れません！

最後に

ちょいとした工夫でコストダウンを見込めますので、皆さんも試してみて欲しいですー！

システムの要件等で導入できなければごめんさい！！

I`m PHPer!!!!!

便利なstatic

PHPの static メソッドは、インスタンスを生成せずにクラスから直接呼び出せるメソッドです。

使うべきタイミング

状態を持たない処理

インスタンスの状態に依存しない、独立した処理を行う場合に適しています。例えば、ユーティリティ関数やヘルパー関数などがこれに該当します。

class MathHelper {
  public static function add($a, $b) {
    return $a + $b;
  }
}

echo MathHelper::add(3, 4); // 出力: 7

ファクトリーメソッド

クラスのインスタンスを生成するメソッド（ファクトリーメソッド）として使用されることがあります。

この場合、`new`キーワードを隠蔽して、インスタンス化の過程を制御できます。

class User {
  public $name;

  private function __construct($name) {
    $this->name = $name;
  }

  public static function create($name) {
    return new self($name);
  }
}

$user = User::create('John Doe');

あまり使いたくないね。。。

シングルトンパターン

特定のクラスのインスタンスが一つだけ存在することを保証するシングルトンパターンの実装に利用されます。

<?php

class Singleton
{
    private static $instance;

    private function __construct()
    {
// プライベートコンストラクタ
    }

    public static function getInstance()
    {
        if (self::$instance === null) {
            self::$instance = new self();
        }
        return self::$instance;
    }
}

$singleton = Singleton::getInstance();

だめな使い方

インスタンスの状態を操作する処理

インスタンスの状態に依存するメソッドに`static`を使うべきではありません。staticメソッドはクラスレベルで動作するため、インスタンス固有の状態を保持することができません。

class User {
  private $name;

  public static function setName($name) {
    $this->name = $name; // エラー: $thisを使えない
  }
}

過度な使用

全てのメソッドを`static`にすることは避けるべきです。

staticメソッドを多用すると、オブジェクト指向プログラミングの基本原則であるカプセル化や多態性が損なわれる可能性があります。
特に、後からメソッドをオーバーライドする必要が出てきた場合に柔軟性を失います。

依存性注入の回避

staticメソッドは依存性注入と相性が悪く、テストやメンテナンスが難しくなる場合があります。テスト可能なコードを維持するためには、インスタンスメソッドを使用し、必要な依存関係をコンストラクタやセッターで注入する方が望ましいです。

まとめ

static メソッドは、クラス固有の処理やユーティリティ関数として適切に使用することで、コードの構造を明確にし、インスタンス化を不要にするメリットがあります。ただし、過度な使用はオブジェクト指向の原則を損なう可能性があるため、状況に応じて適切に使い分けることが重要です。

セキュリティサポートが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 のコントリビューターに感謝を捧げます

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

RIP My Service…

作ったもの

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

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

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

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

技術構成

マネタイズポイント

物販購入

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

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

予約

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

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

売り方

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

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

• SNS
  • Instagram
  • Twitter
• ブログ

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

なぜ売れなかったのか

知名度

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

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

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

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

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

効果を得られるか不安

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

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

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

県民性

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

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

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

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

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

反省

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

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

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

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

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

先日 RDS を構築した際に EC2 と接続ができなくて泣きたくなった。

原因はシンプルで EC2 に MySQL クライアントが存在しませんよという内容です。

クラウド先（RDS）には MySQL が存在しているのに、わざわざ EC2 に MySQL 本体をインストールするのもなぁと思っていたのですが、ちょっと工夫するだけで EC2 から接続できるようにすることができることを知ったので共有ですぅぅぅ〜

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

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

いざ実践

• とりあえずアプデ

  sudo apt update
  

• mysql-client のパッケージを検索
  なんかいい感じのやつ出てくるよ

  apt search mysql-clien

• 最小を入れたい
  (お使いのバージョンに合わせたものを指定してね
  (client を入れれば MySQL コマンドが使えるよ

  apt install mysql-client-core-8.x

• MySQL に接続

  mysql -h rds.amazonaws.com -P 3306 -u rds -p

失敗時のエラー

権限不足

Permission denied

• Ubuntu で入ったから何となく行けてんのかと思いきや…
• sudo しなさいよ

接続失敗

ERROR 2003 (HY000): Can't connect to MySQL server on

• RDS の設定漏れ
• EC2 からの接続許可

両者の違いをわからないままノリで進めていくと大恥かくので先に学んでおく事をおすすめします。

UFW（Uncomplicated Firewall）とは

UFWは、Linuxベースのシステムでファイアウォールを設定するためのツールです。

UFWは、iptablesと呼ばれるより高度なファイアウォール設定を簡略化したもので、コマンドラインを通じて簡単に設定できます。

主な特徴は以下です

• ポートベースのファイアウォール設定をサポート
  • 特定のポートへのアクセスを制御
  • IPアドレス、サブネット、アプリケーションなどの設定が可能。
• シンプルな構文
  • ufwは非常に簡単な構文を持っており、コマンドラインで簡単に設定できる
  • ufwはシステム全体のファイアウォールとして機能する。
  • ネットワークトラフィックを制御するために使用される。
  • 特にWebアプリケーションのセキュリティには直接関係なし。

使用例

サーバーに対してセキュリティに関わる制限を設ける。

#HTTPS の port 開放 
sudo ufw allow 443

#MySQL の port 開放 
sudo ufw allow 3306

#sshの port 閉鎖 
sudo ufw deny 22

ufw にてポートの開閉を明示的に指示ができる。

WAF（Web Application Firewall）とは

WAFは、Webアプリケーションのセキュリティを強化するためのセキュリティツールです。

WAFは、Webトラフィックに対する特定のセキュリティルールを適用し、Webアプリケーション攻撃（例：SQLインジェクション、クロスサイトスクリプティングなど）から保護します。

主な特徴は以下です

• Webアプリケーションに対するトラフィックフィルタリング
  • WAFは、HTTPおよびHTTPSトラフィックを対象として、不正なリクエストや攻撃を検出し、遮断します。
  • パターンマッチング：WAFは特定の攻撃パターンや脆弱性に対する署名またはルールを使用して攻撃を検出します。
  • ロギングと監視：WAFは攻撃試行をログに記録し、セキュリティエンジニアがそれを監視および対応できるようにします。

WAFはWebサーバーとWebアプリケーションの間に配置され、攻撃をブロックしてWebアプリケーションを保護します。

WAFは販売されている

今回の勉強をするまでは、WAFの防御する内容が SQLインジェクションや XSS などであったため、自分で記述するプログラムにて防御するものだと思っていました。（自分で書くべきプログラムの総称と思っていた…

内容を深掘っていくとWAFはかなりの数が外反されており、運用を楽にするためにたくさんの企業が導入しているということがわかりました。

独自のルールを付加させる事のできるAWS WAF はその内勉強しないといけないなぁという印象です…

用途の異なるセキュリティツール

UFW（Uncomplicated Firewall）とWAF（Web Application Firewall）は、異なるセキュリティ関連のツールであり、異なる用途と機能を持っています。

簡単にまとめると以下のとおりですー。

• UFWはシステムのファイアウォール設定を簡単に行うためのツール
• WAFはWebアプリケーションのセキュリティを向上させるための特化したセキュリティツール

はじめにApache2の設定ファイルについて理解しておきます。

WEB検索にてApacheのセキュリティ対策と検索するとApache導入後に自動生成される「/etc/apache2/apache2.conf」に定義してと書いてあります。

私のようにSSL化に伴い、設定ファイルを作成した場合は作成したファイルにセキュリティ対策を定義します。

/etc/apache2/sites-available/ドメイン名.conf

「/etc/apache2/apache2.conf」と「/etc/apache2/sites-available/ドメイン名.conf」の違いとしては、

• 全般的な設定は/etc/apache2/apache2.confに定義してね
• サイトごとの設定をしたい場合は作成した設定ファイルに定義してね

って感じになります。

基本的に1サーバー1ドメインって形になるので、自動生成ファイルに記述していくことになるかと思います。

エラーが出る場合

これから紹介する対策を設定ファイルに定義した際にエラーが出る場合は下記のコマンドを実行してくださーい。

Invalid command ‘Header’, perhaps misspelled or defined by a module not included in the server configuration

エラー内容

Apache内でHTTPヘッダーの操作が許可されていませんよー。という内容

対策

下記コマンドでHTTPヘッダの有効化。

sudo a2enmod headers

クリックジャギング

クリックジャギングとは

悪意のあるウェブページや広告をユーザーが踏むことで、意図しない操作を実行してしまう攻撃です。

具体的にはiframeタグやリンクなどを挿入し、既存のコンテンツの上に透過した悪意のあるコンテンツを重ねることで悪意のあるコードを実行させてしまう手法です。
ユーザーからすると通常のボタンを押しただけなのに個人情報が盗まれてしまうという事象が発生します。

対策

HTTPヘッダーによる対策を実施します。

X-Frame-Options とはブラウザが特定のタグを許可するかどうかの設定です。

• DENY：どのサイトからも埋め込まれないようにする。
• SAMEORIGIN：同じオリジン（同じドメイン・プロトコル・ポート番号）のサイトからのみ埋め込まれるようにする。
• ALLOW-FROM：特定のURLからのみ埋め込まれるようにする。
  ※今は非推奨らしい

個人的には複数のサーバー(ロードバランサー)等で運用することが多いと思うので、SAMEORIGINを設定するケースが多いと思いますー。

Apacheの場合は以下のファイルに追記します。

X-Frame-Options: DENY

HTMLページに設定する場合は以下のように設定します。
※WEBサーバーに設定するのが推奨とのこと。

<meta http-equiv="X-FRAME-OPTIONS" content="DENY" />

XSS

XSSとは

悪意のあるスクリプトを注入し、ユーザーのブラウザで実行させることで、クッキー情報やセッションIDなどの個人情報を盗んだり、偽のWebページを表示してユーザーの意図しない行為を実施することができます。

具体的にはGETパラーメーターに悪意のあるウェブページのリンクを入れたりすることで実現できます。

考え方

基本的にアプリケーション側で文字列のエスケープ処理やサニタイズ処理を実施します。

Apacheでの対策

XSSフィルター機能を設定します。

XSSフィルター機能とはブラウザの機能であり、ウェブページに含まれるリクエストパラーメーターやHTMLタグなどの入力値を検査し、悪意のあるスクリプトがあれば削除/エスケープするなどの対策を実施します。

Header set X-XSS-Protection "1; mode=block"

CSP

CSPとは

Webページに埋め込まれる外部リソースの取り扱いを制限することを指します。

対策

Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; object-src 'none'; frame-ancestors 'none'"

CSPの設定後に以下のエラーが出る方はドメインも含む形で ‘unsafe-eval’を設定してください。

ご自身のJSファイルが正規のものと判断させるために必要です。

Uncaught EvalError: Refused to evaluate a string as JavaScript because ‘unsafe-eval’ is not an allowed source of script in the following Content Security Policy directive: “script-src ‘self’ ‘unsafe-inline'”.

ただし、Eval関数は文字列をJSの構文として扱うことが出来るので、推奨されません。

#実行されちゃう
let alert = alert('aiueo');
eval( "alert")

そのため、他にも追加で対策してください。
追加の対策として以下が考えられます。(N重にすることである程度は担保できるはずです。)

• XSSフィルター(サーバー側)
• 入力データの検証(アプリケーション側)

DOS/Ddos

DOS/DDOS

システムに対して大量のリクエストを送ることで正常なリクエストを中止/失敗させサービスを正常に運用させなくする攻撃です。

対策

mod_evasiveというモジュールを使用します。

Linuxのディストリビューションやバージョンによって記載するファイルが異なります。

<IfModule mod_evasive20.c>
   DOSHashTableSize 3097
   DOSPageCount 10
   DOSSiteCount 50
   DOSPageInterval 1
   DOSSiteInterval 1
   DOSBlockingPeriod 10
   DOSLogDir "/var/log/mod_evasive"
   DOSEmailNotify admin@yourdomain.com
   DOSWhitelist 127.0.0.1
</IfModule>

画像の直リンク

直リンクされて困ること

案件によっては、画像やPDFなどに情報を詰め込んだデータを扱う事があると思います。(保険の明細や履歴書など)

そういったデータをバイナリ化してDBへ登録するのではなく、特定ディレクトリに保管する場合に関しては、そのディレクトリに直接アクセスされてしまうと個人情報が公開されてしまいます。

そのための対策ですよん。

対策

リファラを使って直アクセスの対策を実施。

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?ドメイン.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

一応、Apacheならではの.htaccessを使用したアクセス禁止方法もあります。

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

バージョン情報の非表示

バージョンを表示することで対象のバージョンに合わせた攻撃を実施される/バージョンのセキュリティホールを見抜くなどの脅威があります。

サーバーにてコマンドを打てばバージョンを確認できるので、バージョンは非表示にしましょう。

Apacheのバージョン非表示

ServerTokens Prod

PHPのバージョン非表示

/etc/php/{PHPのバージョン}/apache2/php.iniを編集。

expose_php=off