ネットワーク – エンジニア見習い

Laravel+Inertia+ReactをECSで動かしたい！ NginxとPHP-FPMのコンテナ分離

hrokig2 — Tue, 28 Oct 2025 05:24:52 +0000

Laravel + Inertia (React/Vue) の組み合わせは、SPA（シングルページアプリケーション）の体験とサーバーサイド（Laravel）の書きやすさを両立できる、非常に強力な構成です。

しかし、ローカルの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が処理)

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

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

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

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

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

npm run build を実行し、public/build ディレクトリを生成します。
PHP-FPMイメージのビルド:
- Laravelのコード（app/, routes/ など）をコピーします。
- ステップ1のために public/build/manifest.json をコピーします。（リンク生成に必要）
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タスク2コンテナ（Nginx + PHP-FPM）」構成を採用します。
fastcgi_pass: NginxからPHP-FPMへの通信は、同一タスク内のため fastcgi_pass 127.0.0.1:9000; を指定します。
静的ファイル: ビルドしたJS/CSSは、パフォーマンス最適化のためNginxコンテナに配置し、Nginxから直接配信させます。
manifest.json: HTMLシェル生成のため、PHP-FPMコンテナにも manifest.json が必要です。

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

【AWS解説】ALBのHTTPSリダイレクト、コンテナはポート80でなぜOK？

hrokig2 — Fri, 17 Oct 2025 01:45:08 +0000

AWSでWebアプリケーションを構築する際、ALB (Application Load Balancer) を使ってHTTPS化するのはもはや常識です。しかし、多くの開発者が一度は疑問に思う点があります。

「ALBでHTTPS化したのに、なぜ後ろにいるECSコンテナはポート80（HTTP）のままで通信できるんだろう？」

この一見不思議な挙動は、ALBが持つ2つの重要な役割を理解することで、スッキリと解決します。今回は、このALBの「魔法」の仕組みを、セキュリティグループの設定から紐解いていきましょう。

最終的な構成：安全な3層アーキテクチャ

まず、私たちが目指すのは、セキュリティと可用性のベストプラクティスに基づいた、以下のような3層アーキテクチャです。

Web層: ALBがインターネットからのリクエストをすべて受け付けます。
AP層: ECSコンテナがプライベートな領域でアプリケーションを動かします。
DB層: RDSがさらに内側のプライベートな領域でデータを安全に保管します。

この構成のセキュリティの肝は「ECSはALBからの通信しか受け付けない」というルールです。これを実現するのが、次に説明するセキュリティグループです。

門番の役割を担う「セキュリティグループ」

セキュリティグループは、リソースのドアを守る「バーチャルな門番」です。今回は3人の門番を配置します。

ALBの門番: インターネットからの訪問者（ポート80, 443）を全員受け入れます。
ECSの門番: ALBの門番から紹介された人（ALBからのトラフィック）だけを通します。それ以外の人は全員お断りです。
RDSの門番: ECSの門番から紹介された人（ECSからのトラフィック）だけを通します。

この連携により、たとえ攻撃者がECSに直接アクセスしようとしても、門前払いされる仕組みが完成します。

ALBがこなす2つの全く異なる仕事

さて、ここからが本題です。ユーザーがhttp://でアクセスしてきた時に、ALBとコンテナの間で何が起きているのでしょうか。実は、これは2段階の独立した処理になっています。

ポイントは役割が2つ存在するということです。

ブラウザへの「リダイレクト指示」

最初のやり取りは、ユーザーのブラウザとALBの間だけで完結します。

ユーザー: ブラウザで http://example.com (ポート80) にアクセス。
ALB (ポート80の受付係): リクエストを受け取ると、中身は見ずにこう応答します。「すみません、こちらの窓口は安全ではありません。向かいにある安全な443番の窓口へ行き直してください」。これがHTTP 301リダイレクトです。

この時点では、リクエストはまだECSコンテナには一切届いていません。

ステップ2：コンテナへの「リクエスト転送」

ブラウザはALBからの指示に従い、今度は最初から安全な窓口へ向かいます。

ユーザー: ブラウザが自動的に https://example.com (ポート443) に新しいリクエストを送信します。
ALB (ポート443の受付係):
- 暗号化されたリクエストを受け取り、持っているSSL証明書を使って通信を復号します（SSL/TLS終端）。
- 安全な平文になったリクエストを、宛先であるECSコンテナのポート80へ転送（フォワード）します。
ECSコンテナ (ポート80): ALBから来た通常のHTTPリクエストを受け取り、処理を実行します。

このように、ALBはユーザーを正しい入口へ案内する「案内係」の仕事と、リクエストを内部の担当者へ届ける「取次係」の仕事という、2つの全く異なる役割をこなしているのです。

コンテナからすれば、常にALBという信頼できる取次係から、暗号化が解かれた分かりやすいリクエストが届くだけなので、ポート80で待ち受けていれば良い、というわけです。

非常に便利ですね。。

CDKの実装

SecurityGroup の実装

// ALB用セキュリティグループ
const albSecurityGroup = new ec2.SecurityGroup(this, 'AlbSg', { vpc });
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(80), 'Allow HTTP');
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(443), 'Allow HTTPS');

// ECS用セキュリティグループ
const ecsSecurityGroup = new ec2.SecurityGroup(this, 'EcsSg', { vpc });
// ALBからの通信のみを、コンテナのポート80で許可
ecsSecurityGroup.addIngressRule(
    albSecurityGroup,
    ec2.Port.tcp(80),
    'Allow traffic only from ALB'
);

ALBリスナー

// ALB本体を作成
const alb = new elbv2.ApplicationLoadBalancer(this, 'MyAlb', {
    vpc,
    internetFacing: true,
    securityGroup: albSecurityGroup,
});

// HTTPリスナー (ポート80): HTTPSへリダイレクトするだけ
alb.addListener('HttpListener', {
    port: 80,
    defaultAction: elbv2.ListenerAction.redirect({
        protocol: 'HTTPS',
        port: '443',
        permanent: true,
    }),
});

// HTTPSリスナー (ポート443): ECSへリクエストを転送する
alb.addListener('HttpsListener', {
    port: 443,
    certificates: [certificate], // ACMで発行した証明書
    defaultAction: elbv2.ListenerAction.forward([ecsTargetGroup]), // ECSのターゲットグループ
});

まとめ

ALBのHTTP→HTTPSリダイレクトは、「リダイレクト指示」と「リクエスト転送」の2段階で行われる。
SSL/TLSによる暗号化・復号の処理はALBがすべて肩代わりしてくれる（SSL/TLS終端）。
コンテナは、ALBから転送されてくる暗号化されていないHTTPリクエストを受け取るだけで良い。
セキュリティグループを正しく設定することで、この安全な通信経路が完成する。

役割が2つあることが分からなければ理解できなかったなぁ。

参考記事

【AWS】VPCってなんだかんだ難しいよね

hrokig2 — Tue, 22 Oct 2024 20:37:25 +0000

ネットワークACLとセキュリティグループ

項目	ネットワークACL（NACL）	セキュリティグループ
適用範囲	サブネット単位で適用	インスタンス単位で適用
ルールの処理順	番号順に評価（最初に一致したルールが適用）	全ルールを評価し、許可されるものだけが適用
許可・拒否の指定	許可と拒否の両方のルールを指定可能	許可ルールのみ指定可能
ステートフル / ステートレス	ステートレス（応答トラフィックもルールで明示的に許可する必要あり）	ステートフル（インバウンドが許可されると、その応答は自動的に許可）
適用タイミング	サブネットレベルでトラフィックがフィルタリングされる	インスタンスレベルでトラフィックがフィルタリングされる
デフォルトの動作	すべてのトラフィックを許可（デフォルトNACLの場合）	すべてのトラフィックを拒否（デフォルトセキュリティグループの場合）
ルールの数	最大20のルール（1つのNACLあたり）	最大60のルール（1つのセキュリティグループあたり）
ユースケース	複数のインスタンスに対して一貫したトラフィック制御が必要な場合	インスタンスごとに細かくトラフィックを制御したい場合
推奨される用途	サブネットレベルのアクセス制御（外部からのトラフィックのフィルタリング）	アプリケーションレベルのアクセス制御（特定インスタンスへのアクセス制御）

NatゲートウェイとNATインスタンス

項目	NATゲートウェイ	NATインスタンス
設定と管理	フルマネージドサービス。AWSが自動でスケーリング、冗長性を提供。	EC2インスタンスを手動で立ち上げ、管理。スケーリングや冗長化はユーザーが設定する必要あり。
可用性	高可用性（単一のアベイラビリティゾーンまたはマルチAZ対応）。	冗長化は手動で設定が必要（自動フェイルオーバーなし）。
スケーラビリティ	自動スケーリングに対応。トラフィック量に応じて自動的に調整。	インスタンスのサイズや数を手動で調整する必要あり。
料金	使用した時間とトラフィックに応じて課金されるが、基本的に高コスト。	インスタンスのサイズと実行時間に基づく課金。小規模な環境ではコストを抑えられる。
ネットワークスループット	最大45Gbpsのスループットを提供し、大量のトラフィックに対応。	インスタンスの種類に依存。大規模なトラフィックでは性能が制約される。
セキュリティグループ	セキュリティグループは設定不可。NACL（ネットワークACL）で制御する。	セキュリティグループを設定して、きめ細かいアクセス制御が可能。
運用の複雑さ	AWSが管理するため、運用負担が少ない。	監視・メンテナンスが必要。手動でスケーリングやフェイルオーバーを設定する必要がある。
ユースケース	高可用性とスケーラビリティが重要な環境。	コストを抑えたい小規模環境やテスト環境。

ルートテーブル

VPC内のルーティングを行ってくれる。

送信先に当てはまらない通信はデフォルトの「0.0.0.0/0」に流れる。

送信先に一致した通信はそのターゲットにルーティングしてくれる。

VPC内で使われるリソース/機能

ENI

VPCエンドポイント

S3やDynamoDBなどインターネットから直接利用できるVPC外のAWSサービスへアクセスは、通常インターネットゲートウェイを経由して通信する。

VPCエンドポイントは、セキュリティ上の制約でインターネットとの通信が制限されているプライベートサブネット内のAWSリソースから、インターネットゲートウェイを経由せずにVPC外のAWSサービスへアクセス可能にする機能になりまっす。

この機能は２つの手法がある。

ゲートウェイ型

ルートテーブルにVPCのエンドポイントを指定してルーティングする

イメージ： VPCに専用の穴を開ける

PrivateLink（インターフェース型）

AWSのサービスへ接続したいリソースが配置されているサブネットにプライベートIPアドレスを持つENIを作成して、ENIとサービスをリンクさせる

イメージ：直リンク

VPCピアリング

VPC同士を紐づける機能

異なるアカウント間のVPC接続
- 1つのAWSアカウントに限らず、別のAWSアカウントのVPCともピアリングが可能。
リージョン間のリソース接続
- VPCピアリングを使えば、異なるリージョンにあるVPC間でも安全な通信を確立できます。

Egress-Onlyインターネットゲートウェイ

IPv6専用のアウトバウンド通信を提供するゲートウェイ。
AWS VPCでIPv6アドレスを使用する場合、インターネットへの発信通信は許可し、受信通信をブロックする必要がある場合に使用するよん。

NATゲートウェイのIPV6用と思ってもらえれば良い。

AWS Transit Gateway

複数のVPCやオンプレミスネットワークを中央集約的なハブで接続するためのネットワーキングサービスです。各VPCやVPNはTransit Gatewayに接続され、個別にルーティングする必要なく効率的な相互接続が可能になります。

スループットとレイテンシーとIOPS

hrokig2 — Tue, 15 Oct 2024 13:17:25 +0000

部屋とYシャツと私のような記事タイトルですみません。。。

今回は、ネットワークの基礎となる

スループット
レイテンシー
IOPS

を紹介したいと思います。

インフラ構築をしているとよく出てくるキーワードですが、度々こんがらがってしまうため改めて学び直します。

お前ら何やねん

スループットとは

特定の時間にネットワークを実際に通過できるデータの平均量を指します。

つまり通信速度です。

5Gbps=5×1,000,000,000ビット/秒=5,000,000,000ビット/秒

1秒間に10億ビット通過できるんだ-と思いますが、ネットワーク内には様々なリソースがあるので、提供されるスペック通りの値が通過できるとは限りません。あくまで平均ね。

レイテンシーとは

リクエストを送信してから応答が返ってくるまでの遅延時間を指します。

ちょうわかりやすく言うと、「データの処理や通信がどれだけ迅速に行われるか」の指標のことです。

IOPSとは

ストレージやデータベースが1秒間に処理できる入出力操作の回数を指します。

IOPSはスループットとある程度、比例関係にあります。

小さいブロックサイズの場合、1回のIO操作で処理されるデータ量が少ないため、操作回数が多くなり、IOPSが増加する
大きなブロックサイズの場合、1回のIO操作で大量のデータを処理するため、IO操作回数が少なくなり、IOPSは減少しますが、スループットは向上する

3つの違いのまとめ

レイテンシー

嬉しい状態:低いほうが嬉しい
理由:
レイテンシーが低い（つまり遅延時間が短い）ほど、システムがより速く応答し、ユーザーが操作を行った際の待ち時間が少なくなります。
たとえば、Webページが速く表示されたり、データベースのクエリが迅速に実行されたりすることで、ユーザー体験が向上します。
例: ネットワークレイテンシーが低いと、Webサイトの応答が速くなります。

スループット

嬉しい状態: 高いほうが嬉しい
理由:
スループットが高いほど、システムが短時間で多くのデータやリクエストを処理できることを意味します。
特に、大量のデータを処理する場合や多くのユーザーが同時にアクセスするシステムにおいて、高いスループットはシステムの効率や全体のパフォーマンスを向上させます。
例: スループットが高いネットワークでは、1秒間に多くのデータを送受信でき、ダウンロードやストリーミングがスムーズに行えます。

IOPS

嬉しい状態: 高いほうが嬉しい
理由:
IOPSが高いほど、ストレージデバイスが1秒間に処理できる入出力操作の回数が多くなります。
これは、特にデータベースやファイルシステムなど、頻繁にデータの読み書きが発生するシステムにとって重要です。
高いIOPSは、より多くの入出力操作を短時間で処理できるため、パフォーマンスが向上します。
例: IOPSが高いSSDは、ディスクアクセスが多いアプリケーション（例えばデータベースクエリやログ書き込み）の性能を大幅に改善します。

【HTTPとHTTPS】Webの基盤となるプロトコルをちゃんと理解しましょう

hrokig2 — Fri, 12 Apr 2024 15:01:48 +0000

こんにちは。三流プログラマーとして都内で勤務しているやんやんです。

先日インターン生からこんな質問を受けました。

インターン生

HTTPってなんですか？

私自身、しっかりと理解できていないためか上手な説明ができなかったので改めて勉強しようと思った今日この頃です。

この記事では、これらのプロトコルの基本、特にメソッド、ステータスコード、ヘッダー、クッキーという要素に焦点を当て、それらがどのようにWebの基盤となっているかを掘り下げます。

さらに、HTTPSがHTTPにセキュリティ層を追加する方法と、その重要性についても触れていこうと思いまっす

HTTPとは

HTTPは、WebブラウザとWebサーバー間の通信を可能にするプロトコルです。

太古の昔(1990年代)にWebの成長とともに進化してきました。

HTTPはステートレスなプロトコルであり、つまり、過去のリクエストやレスポンスの状態を保持しないという特徴があります。これにより、プロトコルのシンプルさと拡張性が保たれています。

あわせて読みたい関連記事

[getpost id=”1569″ target=”_blank” cat_name=”1″ date=”0″]

HTTPSとその重要性

HTTPSは、HTTPにセキュリティ層を加えたものです。

具体的には、SSL（Secure Sockets Layer）またはTLS（Transport Layer Security）を使用して、クライアントとサーバー間の通信を暗号化します。

この暗号化により、データの盗聴や改ざん、なりすましを防ぐことが可能になります。特に、Eコマースやオンラインバンキングなど、機密性が求められる情報を扱うWebサイトではHTTPSが必須となっています。

SSLを知らないとWEB業界では大恥をかくので、皆さんご注意を。

あわせて読みたい関連記事

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

HTTPメソッド

HTTPメソッドは、クライアントがサーバーに対して何をしたいのかを指示するための手段です。
最も一般的なメソッドは以下の通りです。

GET
リソースを取得するために使用します。
POST
リソースを作成するために使用します。
PUT
リソースを更新するために使用します。
DELETE
リソースを削除するために使用します。

これらのメソッドは、RESTful APIの設計において重要な役割を果たします。

ステータスコード

HTTPステータスコードは、サーバーがクライアントのリクエストをどのように処理したかを示します。以下は、よく使われるステータスコードの例です。

200 OK: リクエストが成功したことを示します。
404 Not Found: リクエストされたリソースが見つからなかったことを示します。
500 Internal Server Error: サーバー側で問題が発生したことを示します。

これらのコードは、デバッグやエラー処理において極めて有用です。

ヘッダーとクッキー

HTTPヘッダーは、リクエストやレスポンスのメタデータを提供します。例えば、Content-Typeヘッダーはリソースのタイプを示し、Set-Cookieヘッダーはクライアントにクッキーを設定するよう指示します。

クッキーは、サーバーがクライアントのブラウザにデータを保存するために使用される小さなデータ片です。これにより、セッション管理、パーソナライゼーション、トラッキングなどが可能になります。

まとめ

HTTPとHTTPSは、Web上での情報交換の基盤を成すプロトコルです。HTTPSによる暗号化は、オンラインでの安全性を大幅に向上させています。HTTPメソッド、ステータスコード、ヘッダー、クッキーといった要素の理解は、Web技術において深い知識を持つために不可欠です。これらの基本を押さえることで、よりセキュアで効率的なWebアプリケーションの開発が可能となります。

CIDRが分からないから少し理解するまでに至りたい

hrokig2 — Sun, 28 Jan 2024 07:25:44 +0000

CIDR（Classless Inter-Domain Routing）って聞いたことありますか？僕は知らないままサーバー構築していたのでお客様との打ち合わせで大恥を書いた経験があります。

本業はプログラマーですがお客様やインフラの方との話ができるなるべく、全くわからないから少し理解したっていう状況を目指して勉強していきましょーう

CIDRとは

CIDR（Classless Inter-Domain Routing）とは、インターネットでIPアドレスをうまく管理するための技術 のことを指します。

昔はIPアドレスが「クラス」という固定の枠に分けられていたんですけど、CIDRではそんな枠組みをなくして、もっと自由にアドレスを割り当てられるようになったんですよ。

例を挙げると、「192.168.0.0/24」っていうのはCIDR形式のアドレスになります。

ここで「192.168.0.0」がIPアドレスで、「24」がネットワークの大きさを示すんです。

「192.168.0」の部分（最初の24ビット）は、ネットワークアドレスを示しています。
このネットワーク内の個々の機器は、「.1」のように、最後の8ビットで区別されます。

つまり、「192.168.0.1」から「192.168.0.254」までのアドレスは、すべて「192.168.0.x」という形で、同じネットワーク（「192.168.0」）に属している機器として識別されるのです。

// 無理やりMarkDownで表すと以下のような感じ
- 192.168.0.0
  - 192.168.0.1
    |
  - 192.168.0.254

CIDRが難しく感じる理由

「CIDRってなんだか難しそう…」と思うのは、私たちが普段使ってるIPアドレスの考え方とちょっと違うからかもしれません。

サブネットマスクっていうのをビット単位で調整することで、ネットワークの大きさを自由に変えられるんです。

これ、最初はピンとこないかもしれませんが、慣れればすごく便利なんですよ。

AWSにおけるCIDR

AWSにおいて CIDRはものすごく大事な役割を果たしています。

たとえば、VPC（Virtual Private Cloud）を作るとき、CIDRブロックを使って、そのVPC内で使えるIPアドレスの範囲を決めます。

これがあるおかげで、私たちは自由にネットワークを設計できるんです。

「10.0.0.0/16」っていうCIDRブロックは、10.0.0.0から10.0.255.255までのIPアドレスを含んでいて、これをサブネットに分けて使うことができるんです。

ユースケース

CIDRの具体的なユースケースについて考えてみましょう。

例えば、大学のキャンパスネットワークを思い浮かべてください。
学生用、教職員用、研究用といった複数のセグメントに分かれていますよね。CIDRを使用することで、これらの異なるセグメントに効率的にIPアドレスを割り当てることができます。

別の例として、大手企業が複数のオフィスを持っている場合を考えてみましょう。
各オフィスは地理的に離れているため、それぞれ独立したネットワークを必要とします。
CIDRを利用することで、各オフィスに必要なIPアドレス範囲を効率的に割り当て、ネットワークの管理を簡素化できます。

もう一つの例は、セキュリティ面です。
異なるサブネット間での通信を制限することで、ネットワーク内部のセキュリティを強化できるんです。クラウド環境では、このようなネットワーク分離がデータ保護やアクセス制御に役立つんですよ。

まとめ

CIDRって最初はちょっと難しそうに見えますけど、実はすごく便利なツールなんです。
基本さえ理解すれば、ネットワークの設計がぐんと楽になりますよ。まずはこの記事を読んで、CIDRの世界に少しずつ慣れていきましょう！