COLUMN
オンプレミスとAWSの通信の仕組みの違いを徹底的に解説
![]() |
こんにちは、白鳥です。 |
---|
本日のコラムはIPネットワークの仕組みから、AWSのリソース間の通信の仕組みやその違いについて解説しながら、AWSのリソースとどうつながるのかの理解を深めていきたいと思います。
想定する読者
- AWSの通信の仕組みついて理解したい方
- オンプレミスの通信の仕組みと、AWSの通信の仕組みの違いを理解したい方
- AWSをはじめ、ネットワークの仕組みについて理解を深めたい方
オンプレミスの通信の仕組み
まずは基本となる、オンプレミスの通信の仕組みをおさらいしていきたいと思います。オンプレミスの通信の仕組みも奥深く、これだけでかなりの分量になってしまうため、今回はAWSのネットワークを理解するための最小限の内容にとどめます。
OSI参照モデルについて
異なるコンピュータ間で通信を行い、相互に情報を交換する仕組みのことをネットワークと言います。ネットワークにはいくつかの仕組みがありますが、プロトコルという決まった約束事があり、このプロトコルで「どのようにデータを送るのか」などの仕組みを定めています。これらのプロトコルを組み合わせてエンドツーエンドの通信の仕組みを定めておりますが、AWSをはじめ今日のインターネットやLAN/WANの世界では、TCP/IPという仕組みを使っています。TCP/IP以外にもプロトコルはありますが、これらのプロトコルがどのような役割を持っているかを定めたものがOSI参照モデルという7つのレイヤーからなる階層構造で分けることができます。
- 横にスクロールします
レイヤー | 名前 | 役割 | 主なプロトコル |
---|---|---|---|
レイヤー7 (第7層) |
アプリケーション層 | アプリケーションごとの固有の規定 | HTTP/SMTP |
レイヤー6 (第6層) |
プレゼンテーション層 | 文字コードなど表現形式 | MIME/SSL |
レイヤー5 (第5層) |
セッション層 | 通信プロトコルの通信の確立・維持・終了の規定 | ソケット |
レイヤー4 (第4層) |
トランスポート層 | データ転送の信頼性の規定 | TCP/UDP |
レイヤー3 (第3層) |
ネットワーク層 | ネットワーク間の通信の規定 | IP/ICMP |
レイヤー2 (第2層) |
データリンク層 | 同一ネットワーク内の通信のための規定 | Ethernet/PPP |
レイヤー1 (第1層) |
物理層 | ビット列を電気信号に変換するための規定 | 1000BASE-T/802.11 |
通信を行う場合、送信側ではレイヤーの高い方から順番に処理を行い、ヘッダ情報を付加していきます。一方で受信側では、レイヤーの低い方から処理を行い、必要な処理を行っていきます。本コラムでは各プロトコルの詳細は省略しますが、同一ネットワークの通信の仕組みと、ネットワーク間の通信の仕組みを簡単におさらいしておきます。
同一ネットワークの通信の仕組み
それでは、ネットワークの通信の仕組みを振り返ります。レイヤー3のIP(インターネットプロトコル)で規定されるIPアドレスとレイヤー2のEthernetで規定されるMACアドレスが相互に作用して通信を行う仕組みを簡単に振り返ります。
IPアドレスの考え方(IPv4/IPv6共通)
IP(インターネットプロトコル)は、RFC791で規定されるIPv4と、RFC2460で規定されるIPv6があります。どちらも送信元と送信先にあるIPアドレスがヘッダにあり、IPアドレスをもとに通信の制御を行うことは同じです。
IPv4の場合、32bitの数値で、8bitずつ4つに分割して表記されます。前半部のネットワーク部と後半のホスト部に分けており、ここではネットワーク部の異なる通信をネットワーク間の通信、ネットワーク部が同一の通信を同一ネットワークの通信とします。
また、IPv4のアドレスにはインターネットから到達可能な「グローバルIPアドレス」と、内部で利用可能な「プライベートIPアドレス」(※ローカルIPアドレスなど複数の呼び名がありますが、ここではプライベートIPアドレスに統一します)があり、グローバルIPアドレスは米国の非営利団体ICANNなどの団体で管理されています。
プライベートIPアドレスは重複が可能ですが、RFC1918に規定されている下記のアドレス帯を使用します。
クラス | アドレス帯 |
---|---|
クラスA | 10.0.0.0/8(10.0.0.0~10.255.255.255) |
クラスB | 172.16.0.0/12(172.16.0.0~172.31.255.255) |
クラスC | 192.168.0.0/16(192.168.0.0~192.168.255.255) |
他にもIPv4で個別に規定されたアドレス帯や、IPv6でも個別に規定されたアドレス帯がありますが本コラムでは省略します。
MACアドレスの考え方
MACアドレスは、ネットワークインターフェースを識別するために使用される識別子で、Ethernetでは48ビットで表現され、前半32bitがベンダーID、次の8bitが機器ID、最後の16bitがシリアルIDとなることが一般的ですが、例外もあります。過去にはすべての機器が一意に識別されるという説明もありましたが、現在ではこれも例外があります。ネットワークインターフェースごとにMACアドレスを持つため、複数のMACアドレスを持つ機器もあります。
同一ネットワークの通信の仕組み
では、IPアドレスとMACアドレスを利用してどのように通信を行うかをおさらいしていきます。
同一ネットワークを192.168.0.0/24として送信元192.168.0.1と送信先192.168.0.2の間で通信を行うとします。
送信元はMACアドレスをしるため、ARPというプロトコルを使って同一ネットワークのすべての機器にリクエスト(ブロードキャスト)をかけます。
送信先の機器がMACアドレスを回答(ユニキャスト)します。
送信元がMACアドレスを入手したら、送信先に通信を行うようにします。
MACアドレスを使って、すべての機器と通信できれば良いのですが、MACアドレスを使った通信の場合、都度MACアドレスの回答が必要となり、リクエストと回答でトラフィックを消費し、MACアドレスを覚えていられる範囲(MACアドレステーブル)が無尽蔵に大きくなってしまいます。したがって、このMACアドレスを知っている範囲をある程度絞る必要があり、これをブロードキャストドメインといいます。したがって、ネットワーク間の通信とは、ブロードキャストドメインの異なるネットワークへの通信と言い換えることもできます。
ネットワーク間の通信の仕組み
異なるネットワーク間の通信の仕組みをおさらいしていきます。
ネットワーク間の通信の仕組み
異なるネットワークへの通信に関しては、多くの場合端末ではIPアドレスのみを知っており、送信先への経路を知らないという状況になります。したがって、まずは同一ネットワークにいる、経路を知っていそうなデフォルトゲートウェイとなる機器への通信を行います。デフォルトゲートウェイへの通信は同一ネットワークの場合と同じです。
デフォルトゲートウェイは多くの場合ルーターやL3スイッチといった機器(以後、まとめてルーターと呼びます)になります。
ルーターでは、複数のネットワークアドレスとルーティングテーブルという経路の情報を持っており、宛先のネットワークに応じて次にどのルーターに転送すればよいかを判断します。
図にするとこのような形です。PC-AからPC-Bへの通信を行う場合は次の通りになります。
- PC-Aは異なるネットワークへの通信に対して、デフォルトゲートウェイである、ルーターAに通信を行う
- ルーターAは自身のルーティングテーブルを参照し、中継ネットワークである10.0.0.2へ転送
- ルーターBは自身が所属するネットワークからPC-Bへ転送
インターネット経由の通信の場合
インターネット経由の場合も、基本的には異なるネットワーク間の通信と同じになります。ただ、大量の機器を使用しての通信になるため、ルーティングテーブルにすべての経路情報を手動で設定したり、送信先になるIPアドレスをすべて保持したりすることは現実的ではありません。したがって、次のような仕組みで経路情報を交換したり、IPアドレス情報を交換したりします。
ルーティングプロトコル
ルーティングテーブルに登録できる経路情報は手動で設定するスタティックルートと、隣接するルーター同士が経路情報をやり取りするダイナミックルートの2種類があります。ダイナミックルートにはRFCで定められたものやCiscoなどのメーカー独自の実装がありますが、AWSを利用する場合は、BGPというプロトコルがダイナミックルートのプロトコルとしてよく出てきます。この場で詳しくは解説しませんが、AWSと閉域接続を行ったり、VPN接続を行ったりする際には利用します。
DNS
IPアドレスは時に可変のアドレスとなり、すべての通信に対してIPアドレスを記憶して通信を行うことは得策ではありません。普段はドメイン名を使って通信を行います。DNS(Domain Name System)をつかって、名前とIPアドレスの紐づけを管理します。(DNSには名前とIPアドレスを管理するだけのプロトコルではありませんが、今回はここだけに絞ります)。DNSサーバーと呼ばれるサーバーに問い合わせを行って、IPアドレスを取得します。DNSサーバーは複数の階層からなっており、分散して名前の管理を行っています。
DNSの仕組みは詳しく解説しませんが、このような形で普段ドメイン名を使って接続する場合には名前解決を行ってから送信先への接続を行います。
AWSの通信の仕組み
ここまで簡単にオンプレミスの通信の仕組みをおさらいしてきました。ここからAWSの通信の仕組みを理解していきたいと思います。VPCでの通信と、マネージドサービスの通信を分けて考えていきます。まずは初級編としてAmazon VPCの基本概念のおさらいをしながら、通信の仕組みを理解していきたいと思います。
AWSの通信の仕組み(初級編)
Amazon VPCの基本概念
Amazon VPCはAWS上に仮想プライベートネットワークを構成し、レイヤー3のネットワークとして使うことができます。通信を行うための基本的な機能としては、サブネットと各種ゲートウェイ、オプションサービスがあります。
- サブネット
サブネットは、VPCから払い出されたIPアドレス範囲(CIDRブロックといいます)をさらに分割してブロードキャストドメインを分割することができます。
サブネットはインターネットと直接通信できる「パブリックサブネット」と、インターネットと直接通信できない「プライベートサブネット」に分かれます。
各サブネットは、一つのアベイラビリティゾーン内に設定され、アベイラビリティゾーンをまたいだサブネットを作ることはできず、アベイラビリティゾーンごとに作る必要があります。
よくAWSの構成図として書かれるVPCとしては、下のような形で表現されます。
- 各種ゲートウェイ
VPCの外部と通信するコンポーネントとして、各種ゲートウェイサービスがあります。例えば、インターネットと接続するインターネットゲートウェイ、NAT変換を行うNATゲートウェイ、VPCとVPNや閉域接続を行う仮想プライベートゲートウェイ(VGW)、VPC間の通信を行うTransit Gatewayなどがあります。これらを表現した構成図は下記のようになります。
- オプションサービス
Amazon VPCにはいくつかオプションサービスがあり、DNSリゾルバーとなるAmazon Route 53 Resolverや、リソースに払い出すIPアドレスを管理するDHCPサーバーの設定を管理するDHCPオプションセット、時刻同期を管理するAmazon Time Sync Serviceなどがあります。
通信の仕組み(初級編)
VPCを使って通信を行う場合は、利用者側ではあまり意識することはありません。オンプレミスと同じような理解をしていけば、おおむね理解できます。サブネット内の通信は同一ネットワークの通信になります。サブネット間の通信の場合は、サブネット間に仮想ルーターがありますので、仮想ルーターを使って通信をします。VPC外部との通信の場合は、Route 53 Resolverを使って名前解決を行い、インターネットゲートウェイや仮想プライベートゲートウェイ、Transit Gatewayを経由して通信を行います。
AWSの通信の仕組み(上級編)
基本的な機能での理解を行ったところで、いくつか疑問点が浮かんできます?例えば、このような疑問です。
- 物理のIPアドレスとVPCのIPアドレスの関係性
- 仮想ネットワークインターフェースとVPCの紐づけはどうやっているのか?
- 異なるユーザー間で通信ができないような仕組みはどうなっているのか?
- 各種ゲートウェイのスケーリングの仕組み
上級編では、これらの疑問に答えながら進めていきたいと思います。
VPCの全体像
VPC内部の理解を行うために、Nitroや物理ホストの構造に着目して再構成すると、VPCの全体像はこのようになります。
(参考)
AWS re:Invent 2017: Another Day, Another Billion Flows (NET405) AWS re:Invent 2018: Amazon VPC: Security at the Speed Of Light (NET313)をもとに再構成
最初に記載した構成図とは異なり、Mapping ServiceとHyperplaneとBlackfoot Edge Serviceという見慣れない単語が出てきます。これらのサービスは普段AWSを利用するうえではあまり意識しませんが、物理ホストのレイヤーまで意識した場合には、どういった仕組みで通信しているかを理解したほうが良いところになります。
- Mapping Service
Mapping Serviceは、VPC内部のリソースのIPアドレスやVPCのIDなどを管理しているサービスになります。ARPリクエストに対してMapping Serviceが回答を行ったり認証を行ったりすることで異なる物理ホストにあるリソースに対しての通信や、接続されていないVPC間の通信ができないような制御を行っています。
- Hyperplane
Hyperplaneを一言でいうと、AWS内部で利用されるロードバランシングサービスになります。もともとはS3 APIのロードバランサーをベースに作られていますが、実態はマネージドのEC2フリートとなり、具体的なサービスではNATゲートウェイやTransit Gateway、インターフェースVPCエンドポイントで使われています。
仕組みとしては、ユーザーのVPCへのENIを伸ばし、ENIの先にあるEC2フリートが起動して、NAT変換やトラフィックの処理を分散して行い、宛先に対して通信を行う形になります。
- Blackfoot Edge Service
VPCの外に出る通信サービスがこちらにまとまっています。具体的にはインターネットゲートウェイ/仮想プライベートゲートウェイ/ゲートウェイVPCエンドポイントがこちらにあたります。Mapping Serviceによって適切なデバイスを選択し、外部への通信を行うことができるようになります。
VPC内部の通信の仕組み(上級編)
簡単にこれらの概念を理解したことで、VPC内部の通信の仕組みを理解します。EC2-AからEC2-Bへの通信を行うとします。物理ホストのレイヤーにも着目してみると、このような絵になります。
① EC2-Aは、EC2-BのMACアドレスを要求するために、ARPをリクエスト
② 物理ホストがMapping ServiceにEC2-BのMACアドレスと物理ホストの物理IPアドレスをクエリ
③ Mapping ServiceからEC2-BのMACアドレスと物理ホストの物理IPアドレスの回答
④ 物理ホストからEC2-Aに対してEC2-BのMACアドレスを回答
MACアドレスを取得したEC2-Aからの通信は次のようになります。
① EC2-AからEthernetのヘッダとIPヘッダを付加して通信(オンプレミスの通信と同じ)
② 物理ホストは宛先の物理ホストのEthernetヘッダとIPヘッダ、VPC-IDを付加
③ 宛先の物理ホストは、Mapping Serviceに対してEC2-Aが送信元ホストの正規のインスタンスかを認証し、Mapping Serviceが回答
④ 回答を受け取ったら物理ホストのヘッダを削除し、EC2-Bへ送信
⑤ EC2-Bはオンプレミスの通信と同じように、受信する
サブネットをまたぐ場合はEC2とデフォルトゲートウェイとなる仮想ルーターとの通信となります。仮想ルーターも実態はEC2となりますので、同じように通信することができます。
VPC外部との通信の仕組み(上級編)
VPCからVPC外部への通信の仕組みも観ていきたいと思います。VPC外部への通信を行う場合は、EC2にある物理ホストから、Blackfoot Edge Serviceにリソースへの通信を行います。対応するVPCと各サービス(Internet Gatewayなど)の紐づけをMapping Serviceで行い、物理ホストのEthernet/IPヘッダでカプセル化して通信を粉います。また、NATゲートウェイやTransit GatewayといったHyperplaneでの処理が必要なサービスはHyperplaneに接続するためのENI(Elastic Network Interface)へ送信します。Hyperplaneで処理を行った後、宛先の物理ホストや、Blackfoot Edge Serviceへの通信を行います。
AWSのVPC外のサービスのネットワークについて
では、VPC外のサービスへの接続はどのように行っているのでしょうか?今回は軽くご紹介させていただきます。AWSは各サービスでパブリックエンドポイントと呼ばれる接続先を持っています。リージョンサービスであれば、リージョンごとに、グローバルサービスであれば全体で一つのエンドポイントを持っています。こちらにAPIリクエストを行うことで、各種サービスを利用することができるようになります。
IPアドレスの範囲は日々変わりますが、json形式で公開されています。
https://ip-ranges.amazonaws.com/ip-ranges.json
ここのIPアドレス範囲を確認すると、AWSが管理しているグローバルIPアドレスで、グローバルIPアドレスではあるものの、AWSの内部に閉じるネットワークとなっています。そのため、AWSの各サービスで通信を行う場合はAWSの管理ネットワークの配下で通信を行い、AWS管理外のネットワークで通信することはありません。
まとめ
今回は通信の基礎からVPC内部の通信を中心に解説させていただきました。ユーザー側であまり意識することのない物理ホストの通信の領域になりましたが、通常のオンプレミスの通信との違いをみながら簡単に振り返ってみました。大量のVPCやインスタンスがあっても正確にトラフィックを制御できる仕組みが理解できれば何よりです。
NTT東日本では、AWSの構築保守だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供をおこなっております。
経験値豊かなメンバーがご担当させていただきますので、是非お気軽にお問い合わせください!
RECOMMEND
その他のコラム
相談無料!プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。