はじめに
先日、ミーティング中でのメンバーの発言。
「ｘｘｘｘｘはL4層で制御している～～～」
「ｘｘｘｘｘはL7層で～～～」
「L4」「L7」、これらがOSI参照モデルの階層のことを指していて、
なんとなく「通信を階層構造に分けている」ということまでは知っていましたが、
それぞれの層が具体的に何を示しているのか、
ずっと理解がふわっとしたままここまで来てしまっていたので一度インプットを兼ねて整理しようと思います。
誤ったことを書いていたら指摘いただけますと幸いです。
「OSI参照モデル」ってなに？
OSI参照モデルとは、
「コンピュータネットワークに求められる機能（通信機能）を7階層の構造に分割し定義したもの」
ここまでは以前から知っていました。以下階層構造に分けられます。
| 層 (Layer) | 名称 | 主な役割 |
|---|---|---|
| L7 | アプリケーション層 (Application Layer) | ユーザーが利用するアプリケーション・ソフトウェアと通信機能の窓口。利用する機能に応じて様々なプロトコルを扱う。 |
| L6 | プレゼンテーション層 (Presentation Layer) | 通信先のデータ形式に合わせて、文字コード等のデータの形式変換、暗号化・復号、圧縮などを行う。 |
| L5 | セッション層 (Session Layer) | 通信の開始・維持・終了を管理する。セッション制御を担う。 |
| L4 | トランスポート層 (Transport Layer) | ポート番号を用いてアプリケーション間の通信を制御する。TCP/UDPによる信頼性制御を行う。 |
| L3 | ネットワーク層 (Network Layer) | IPアドレスを用いて通信経路（ルーティング）を決定する。 |
| L2 | データリンク層 (Data Link Layer) | 同一ネットワーク内での通信を制御する。MACアドレスによるフレーム転送を行う。 |
| L1 | 物理層 (Physical Layer) | 電気信号や光信号としてビットを物理媒体（ケーブルなど）に流す。 |
上記は以下を参考に整理しました。
AWSサービスとの関連
続いて、各層ではどのようにAWSサービスを使って制御・セキュリティ担保を行うのかをマッピングしてみます。
（おそらく、厳密に「このサービスはこの層」とは言えないです。あくまで私の見解です。）
それぞれの層の役割を抑えると、自然と、「あのサービスはこの層での機能やセキュリティを担っているのか」とイメージが湧くようになりました。
L1L2はクラウドの文脈ではユーザはあまり意識し無さそうなところなのでここからは割愛します。
| 階層 | キーワード | 対応AWSサービス例 |
|---|---|---|
| アプリケーション層 (L7) | HTTP、API、アプリ制御 | AWS WAF / ALB / API Gateway / CloudFront |
| プレゼンテーション層 (L6) | 暗号化、データ形式変換 | ACM / KMS |
| セッション層 (L5) | セッション管理、接続維持 | ALB（スティッキー） / ElastiCache |
| トランスポート層 (L4) | TCP・UDP、ポート制御 | NLB / Security Group |
| ネットワーク層 (L3) | IP、ルーティング | VPC / Route Table / TGW/ IGW |
ALBとNLBの違いって何？
SAPやSAAの試験で頻出の（覚えがある）ALBとNLBの違いを踏まえて適切な選択肢を選ぶ問題も、
上記の整理を踏まえると違いが分かりやすくなります。これを機に整理してみます。
（試験当時はあまり分からずふわっとしたまま解いてました、、）
まずは、コンソールからざっと設定値を確認してみましょう。
EC2＞ロードバランサー＞作成を押すと、どのLBを作成するかを選択する画面が表示され、
各ロードバランサーの違いが記載されています。
ALBはL7層、NLBはL4層で通信を処理するため、
それぞれHTTPS/HTTP、TCP/UDP/TLSと記載があります。
基本設定/ネットワークマッピング/セキュリティグループ
上記はALB・NLB共に同じ設定です。
そのLBが内部向きか外部向きか、配置するVPC/サブネット、アタッチするSGを指定します。
リスナーとルーティング
ALB/NLBで大きく仕様が異なるところはここです。
ALB
ALBではルーティング先として、
- ターゲットグループに転送
- 固定URLにリダイレクト
- 固定レスポンスを残す
の三つが選択可能です。それぞれ、
-
ターゲットグループに転送
→ 指定したEC2/ECS等にリクエストを振り分ける -
固定URLにリダイレクト
→ HTTP→HTTPSへの強制リダイレクト -
固定レスポンスを返す
→ 503メンテナンスページなどをLB側で返却
ということが可能です。
また、プロトコルとして、HTTP/HTTPSを選択することが可能となっています。
これは、ALBがL7（アプリケーション層）で動作し、HTTPの内容を理解できるためです。
NLB
一方で、NLBでは、ターゲットグループに転送の1つしか選択することが出来ません。
これは、NLBがL4（トランスポート層）で動作し、通信の中身を理解せず、IP＋ポートで転送するだけのためです。
ついでにTCP・UDPの違いをざっくり整理すると、以下のような違いがあるようです。
↓以下を参照
TCPとUDPの違い
| 項目 | TCP | UDP |
|---|---|---|
| 信頼性 | 高い（再送制御あり） | 低い |
| 通信方式 | コネクション型 | コネクションレス |
| 主な用途 | Web通信 | ゲーム、DNS等 |
| 速度 | やや遅い | 高速 |
サービス統合で最適化
統合できるサービスにも、ALB・NLBで違いがあります。
ALB
ALBは、CloudFront・WAF・Global Acceleratorと統合することが出来ます。
ALBはL7でHTTP/HTTPSを扱うため、WAFやCloudFrontのようなアプリ層サービスと親和性が高いためです。
特にWAFはHTTPの中身を検査するため、ALBとの組み合わせが基本構成となります。
NLB
一方でNLBはGlobal Acceleratorとのみ統合可能です。
これは、NLBがL4で動作し、HTTPレベルの検査や制御が出来ないため、WAFやCloudFrontのようなL7サービスとは直接統合できないためです。
その他の違い
そのほかには以下のような違いを理解しておくことが大事だと思いました。
- NLBは静的IPを持つことができる（ALBは不可）
- NLBの方がレイテンシが低く、大規模トラフィックに強い
- ALBはパスベースルーティングが可能
- ALBはスティッキーセッション（Cookie）をサポート
まとめ
そのほかのサービスの仕様も、「なぜ」が分かりやすくなる
上記では、私がずっとひっかかっていたALB・NLBの仕様についてまとめましたが、
OSI参照モデルを理解する＝通信の仕組みを理解すると、そのほかのサービスの仕様もなんとなく「なぜ」が分かってきます。
例）WAFはなぜALBやAPI Gatewayにアタッチ出来てNLBにはダメなのか
AWSサービスは、ITの仕組みがサービスに落ちてきているため、AWSサービスの仕様とITの仕組み・概念を関連付けて循環的に学ぶことで、より理解が深まると、当然のことですが改めて気付かされました。
（開発やテストからやると「なぜ」の意識が抜け落ちがち、、、）
おわり