コラム

CTC教育サービス・ホーム　＞　コラム　＞　AWSではじめよう、ネットワークの世界　＞　第１回　AWSのVPCを紐解いてみよう！

AWSではじめよう、ネットワークの世界

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第１回　AWSのVPCを紐解いてみよう！ (津村彰) 2016年4月

1. はじめに

こんにちは、はじめまして。津村と申します。フリーランスでネットワークを中心にインフラエンジニアを生業としております。よろしくお願いします。
さて、「AWSではじめよう、ネットワークの世界」では、AmazonWebServices(以降AWS)や身近なLAN・WANを例題として、我々が日夜お世話になっておりIPネットワークを身につけてみよう、というコラムです。もちろん本職の方からすると、「LANケーブルは作るもの！」「ケーブルテスターは300万円から！」「箱（ルータ・スイッチ等の実機のこと）が触れてナンボ！」といった意見があるかもしれませんし、それらはデータセンタを支え続けるにあたって、この20年以上変わらない必要な技術です。
一方で、AWSをはじめとするIaaS・VPSの普及により、OSがインストールされた状態からインテグレーション始まるケースが増えている事も事実です。最近のシステムインテグレータの現場では、「ミドルウェアは触れるけどLinuxをインストールした事が無いエンジニア」という方も現れてきたとか。
話は戻り、このコラムはAWSや身近なLAN・WANを例題に、IPプロトコルを理解してみよう、という試みです。IPネットワークはパズルの一種で脳トレの一種と思って読んでいただけると幸いです。
どうぞお付き合いください。よろしくお願いします。

2. IPプロトコルとは？

まずは復習です。IPプロトコルについて。・・・とは言っても、CCENTやCCNAの授業ではありません。もっと気楽に行きましょう。

世界中のインターネットで接続されるコンピュータは、IP(Internet Protocol)で接続されている。
すべてのIPネットワークで通信するコンピュータには、IPアドレスが付与されている。
IPアドレスをある程度束ねたものを、サブネット（例：255.255.255.0もしくは/24等と表記）という。
他のサブネットへ通信を中継してくれる存在を、ルータもしくはゲートウェイという。その中でも標準で使われるものを「デフォルトゲートウェイ」という。
例えば「www.yahoo.co.jp」といったものをFQDN(完全修飾ドメイン名)と言い、これをIPアドレスと相互変換するシステムをDNS（Domain Name System）という。

《図解１》

簡潔に解説すると、上記のシンプルな5つのルールでインターネットはできています。決して簡単ではありませんが、この仕組は1982年に標準化され、現在まで生き続けています。

3. AWS上ではどうなっているか。

AWS上ではVPC(Virtual Private Cloud)というサービスにあたり、一定の制約はありますが自由にネットワークをデザインする事ができます。

プライベートIPアドレスを使用し、自由なサイズのVPC(仮想クラウド)を作ることができる。
VPCの中には、Availability zone（以下AZ）と呼ばれる物理的に離れたデータセンタがある。東京リージョンでは、現在ap-northeast-1aとap-northeast-1c が提供されている。
AZ毎に好きなサブネットのネットワークを作ることが出来、インスタンスをそこに作ることが出来る。
インターネットとインスタンスが通信する為には、ElasticIP(EIP)を付与するか、NAT Gatewayを経由する必要がある。
SecurityGroup(インスタンス単位・サブネット単位でのファイヤーウォール・以下SG)では、サブネット単位で通信を制御する事ができる。

併せて、制約条件を挙げましょう。

リンクローカルアドレス（169.254.0.0/16）は利用できない。
DirectConnectやVPN Connectionを使用してオンプレミスと接続する場合、VPCのサブネットはオンプレミスのサブネットとバッティングできない。
NACL(ネットワークACL)では設定できるACL数に制限がある為、SGの利用が推奨される。
（NACLはSGより強制力を持つ代わりに、エントリ数が限られている。）

これらを併せて、AWSにおけるVPCのデザインの例を紹介します。

《図解2》

AWSをはじめとするクラウドベンダーでは、従来のような単一のデータセンタでは防ぐことが出来なかったデータセンタ(AZ)の被災によるダウンに対し、様々な手段でサービスダウンを防ぐ仕組みがあります。この被災には、従来でいう天変地異のほか、セキュリティインシデントやテロといった脅威も含まれ、インフラストラクチャレベルにおいて可能な限り顧客のサービスを保護する体制が取られています。

オンプレミスとAWSは設計レベルで大きく異なるため、一度飲み込むまでは大変ですが、前途のIPプロトコルと併せて紐解くと、少しずつ理解が進むのではないでしょうか。

4. AWSとデータセンタを比べてみよう

以下はAWS上とデータセンタで、ウェブサービス（Web・AP・DBのウェブ三層構造）のインフラをデザインした例です。
以下の2例は機能的に同じであり、コストの違いはあるもののアプリケーションをデプロイし運用する上では全く同じことが可能です。

《図解３・オンプレミス論理図》

今回はネットワーク業界で一般的に使われる、Cisco Systemsが提供しているアイコン素材を使用しています。

一般的にA系・B系と２系統にインフラを分け、場合によっては電源レベルで冗長する為にそれぞれラックを分ける場合もあります。例えばCTC横浜コンピュータセンタの場合、多系統受電のほか、５台の発電機、および２重のUPSによりデータセンタの電源は保護されています。しかしラック内の機器の損傷が生した場合、故障するパーツによってはラックやUPSのブレーカーが働き同一の電源を使用しているラック内機器全体がダウンする事も考えられます。その為、コストが許す場合はA系とB系でラックを分けることが推奨されています。

《図解４・VPCデザイン》

AWSでは特有のデザインアイコンを使ってインフラを表現します。これはAWSサイトよりダウンロードして自由に使う事ができます。

AWSシンプルアイコン
https://aws.amazon.com/jp/architecture/icons/

今回は、Webサーバ・APサーバにはEC2インスタンスを、DBにはMySQL RDS（マネージドDBサーバ）インスタンスを採用するものとします。
AWSではデータセンタでいうラックの冗長は、AZレベルで行います。物理的距離がある為若干のレイテンシがあるのが実情ではありますが、先の通り万が一テロなどで片方のデータセンタの１つがダウンした場合でも、サービスを継続させる事が可能です。
また、RDSというマネージドデータベース、およびELBというマネージドロードバランサを使用する事により、インスタンスの障害などでサービスが停止する事を防ぐ事が可能です。

5. おわりに

AWSからネットワークに入る方も、データセンタ・オンプレミスからネットワークに入る方も、少し頭の体操になりましたでしょうか？
IPネットワークは真面目に取り組むととても難しく、30年余り基礎となる事柄(IPv4)が変わっていない事もあり、基礎力がとても問われます。しかし、逆に言えば冒頭にも申したとおり「パズル」なのであって、通信が疎通した瞬間や、物事の意味がわかった瞬間はとても楽しく、やりがいを感じる事でしょう。

次回からも一緒にパズルを解いていきましょう！