概要
投稿日を遡っていくと実は今日は7日目であるという悲しい現実が分かりました。
というわけで6日目と7日目に自分の中で終わらせておこうと思っていた部分をまとめていきます。
2018.08.26 誤字修正：
＜修正箇所＞
修正前：Resion
修正後：Region
wannabe様よりRegionのスペルが間違っているとご指摘をいただきましたので記事を修正しました。
ありがとうございます。
AWSの全体像
◆ネットワーキング
1.VPC(Virtual Private Cloud)
非常に大切な部分なので、まずはAmazon様の定義を確認しておこうと思います。
Amazon Virtual Private Cloud (Amazon VPC) では、
アマゾン ウェブ サービス (AWS) クラウドの論理的に分離したセクションがプロビジョニングされ、
ここからお客様が定義する仮想ネットワークで AWS リソースを起動できます。
独自の IP アドレス範囲の選択、サブネットの作成、ルーティングテーブルと
ネットワークゲートウェイの設定など、仮想ネットワーク環境を完全にコントロールできます
プロビジョニングという言葉が出てきましたね。
これはどういう意味なのかというと…
プロビジョニング:
プロビジョニングとは、ユーザの需要を予想し、
設備やサービスなどのリソースを計画的に調達し、
ユーザの必要に応じたサービスを提供できるように備える行為の総称。
(出典：IT用語辞典 e-words)
言葉の定義は上記の通りなのですが、e-wordsには更に掘り下げられて書いてありまして、
複数のサーバやネットワーク、アプリケーション、ストレージなどの
リソースを仮想化によって一つのコンピュータリソースとみなし、
ユーザから要求があった場合や障害時などに、必要な分だけ、
コンピュータリソースを動的に別のシステムに割り当てられるようにすること。
(出典：IT用語辞典 e-words)
複数バラバラに存在しているリソースを仮想化することにより一つに統合し、
その上でリソースをニーズに合わせて動的に展開させることを意味しているようです。
それを踏まえた上でAmazon様のお言葉に戻ってきますと、
アマゾン ウェブ サービス (AWS) クラウドの論理的に分離したセクションがプロビジョニングされ
論理的に分離したセクションがプロビジョニング…
意味は何となく理解できますが、セクションという言葉は一般的な用語としての意味なのでしょうか？
それとも、IT用語として存在している言葉なのでしょうか？
というわけで調べてみますと一応、「セクション」という言葉はIT用語として存在しているようです。
セクション:
セクションとは区画や部門をあらわす単語で、
PC関連では効果が適応される範囲を表す用語として使われる。
たとえば、ワープロソフトでこの言葉を利用すると、
自分で設定したページの設定が適応される範囲を表すことになる。
ただし…
この言葉は利用する環境、ソフトによって意味を大きく変わってしまうのだ。
そのためこの単語を利用するときは単語を利用する前提をきちんと決める必要があるのだ。
(出典：IT用語辞典サイトの「イッツペディア(IT PEDIA)」)
なるほど、感覚的に理解している言葉でも文章におこして説明を見ると
曖昧だった理解が大分、明確に整理されて頭の中に入りますね。
つまり、Amazon様の掲げておられるVPCの定義というのは
論理的に分離された区画に仮想化されたリソース(サーバー、ストレージ、アプリケーション)が
展開され、利用者が定義した仮想ネットワークでAWSリソースを起動できる。
お～、なんか自分のなかで抱いていたイメージと一致してきましたよ！
ちなみに論理図では以下のようになるそうです。
この図の中にAvailability Zoneという記載がありますね。
そういえば、これは1日目にも登場した言葉でした。
この言葉を理解するにはセットでRegionについても理解する必要があります。
というわけで以下にまとめてみました。
AmazonEC2は大きく2つの定義で構成されている。
Region(リージョン):
Amazonの世界各地に存在しているコンピュータリソースを地理的に分割したロケーションのこと。
例）
米国東部(バージニア北部)
米国西部(北カリフォルニア)
…
アジアパシフィック(東京)
アジアパシフィック(ソウル)
顧客要件を満たすためであったり、法的要件を満たすためにこれらのリージョンを変更します。
また、アカウントにはよっては中国(北京)リージョンへログイン可能なもの、
米国の連邦政府、州、各地方自治体が使用するためのリージョンへログイン可能なものがある。
Availability Zone(アベイラビリティゾーン):
1つのリージョン内からさらに独立して複数存在しているロケーションのこと。
東京には以下3つのアベイラビリティゾーンが存在しています(2016/9/18日時点)
ap-northeast-1a
ap-northeast-1b ※
ap-northeast-1c
※bは新規リソースの割り当てが停止しているようで新規作成したAWSアカウントでは
新しいサブネットを定義できないようです。
しかし、アカウントによっては1aで新しいサブネットを定義できないなんて話もあるそうです。
ちなみに現在のリージョンとアベイラビリティゾーンの数は
リージョン13、アベイラビリティーゾーン35だそうです(2016/9/18日時点)
来年に4つのリージョンと9つのアベイラビリティーゾーンが追加になるんだそう。
[参考]
①クラウドとは？
https://aws.amazon.com/jp/cloud/
②グローバルインフラストラクチャ
https://aws.amazon.com/jp/about-aws/global-infrastructure/
③リージョンとアベイラビリティーゾーン
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
上記がリージョンとアベイラビリティゾーンについてです。
Amazon様が説明に用いている関係図は以下のような形になっています。
さて、前段はここまででここからがやっとVPCについての話になります。
VPCっていうのはそもそもネットワークの話でした。
そして、EC2やEC2を基盤としたRDSなどのAWSインスタンスが起動される領域の話が
リージョンやアベイラビリティゾーンの話でした。
この二つはどうやらAWS(クラウド)とローカルをネットワークでつなぐって話で落ち着きそうです。
リージョンやアベイラビリティゾーンのなかでインスタンスを起動させるだけで
接続できない「ただの箱」状態になっていては何の意味も成さない。
そこでVPCがAWSインスタンスへの接続の足を提供してくれるっていうわけです。
まぁ、この位にしておいて細かい話はおいおいってことにしますか。
2.Direct Connect
AWSと専用ネットワークで接続することができるサービスです。
それってどういう要件で利用されるのですかね…
そもそも、VPCというもの自体がプライベートなネットワークなのに
敢えて専用回線で接続させる必要があるのでしょうか…
専用線だから、アクセス時間は早くなりそうですが、
専用にしないとVPCではそんなに遅いのでしょうか…
(あからさまに初心者の発想ですみません)
理解を深めるためにも具体的な場面を思い浮かべて考えたほうが良さそうです。
利用シーン：
AWS上で作成したアプリケーションを専用線をつないでエンドユーザが利用する環境に提供する
これは想定ですけど、ダイレクトにWebアプリケーションサーバにつながせるのではなくて、
一度、nginx ※1などのリバースプロキシ ※2サーバにつないだ上でアクセスさせるのでしょう。
そうなると専用線でつなぐのはリバースプロキシとAWS間のネットワークということになるのでしょうか。
※1 nginx
nginxとは、人気の高いオープンソースのWebサーバソフトの一つ。
HTTPリバースプロキシサーバやメール（POP3/IMAP4）プロキシサーバなど
ロードバランサ（負荷分散）としての機能も持っている。
(出典：IT用語辞典 e-words)
※2 リバースプロキシ
リバースプロキシとは、特定のサーバの代理として、そのサーバへの
外部からのすべての接続を中継するプロキシサーバ。
(出典：IT用語辞典 e-words)
これで具体的に得られるメリットとは何でしょうか。
まずは通常にオンプレの環境とAWSの環境を併せた環境の場合を想定してみますか…
通常の場合：
1.エンドユーザ(クライアント端末)
↓
2.リバースプロキシ
↓
3.エッジルータ
↓
4.インターネット
↓
5.AWS VPC
↓
6.EC2 or RDS or S3 ※
(※各インスタンスに接続するごとに経路別のトラフィックが発生)
通常の場合、公衆回線を通って、AWS内のリソースにアクセスすることになるわけですが…
こうやって整理すると結構な遠回りになりそうですね。
ここに書いてある以外にも中継する機器はありそうですし…
おっ、ちょっと待てよ。機能紹介ページにこんなことが書いてありますね。
業界標準の 802.1q VLAN を使用して、この専用接続を
複数の仮想インターフェースに分割することができます。
このようにすると、同じ接続を使用して、パブリックリソース
（例えば Amazon S3 に格納されたオブジェクト）には
パブリック IP アドレススペースを使用してアクセスし、
プライベートリソース（例えば VPC内で実行されているEC2インスタンス）には
プライベート IP スペースを使用してアクセスすることができるので、
パブリック環境とプライベート環境の間でネットワークを分離できます。
VLANが使えるそうです。
専用回線を1つ引いてしまえば、その早い回線を利用して
複数のリソースにアクセス可能になるわけですね。
このDirectConnectを使用すると以下のような形になりますね。
1.エンドユーザ(クライアント端末)
↓
2.リバースプロキシ
↓
3.エッジルータ
↓
4.DirectConnect
↓
5.VPC ※1 or EC2 or RDS or S3 ※2
※1 VPCに接続させた上でEC2やその他のサービスに接続させる
※2 直接、サービスのインスタンスに接続させる
…とはいってもVPCを利用したハイブリッドクラウドの環境が
具体的にどのくらいのものなのかが分からない以上は比較できないですね。
本当にそんなに劇的に早くなるものでしょうか。
あとはアクセス量が多い場合は使えないと思うので用途を絞って使うことになるのか…
…という私の心の内を見透かしたAmazon様はこんなお言葉を書いてました。
これにより、多くの場合、ネットワークのコスト削減、帯域幅のスループットが向上し、
インターネットベースの接続よりも均質なネットワーク体験を提供できます。
ははぁ、そうですか。
ちなみにこの機能には導入に際しての条件といくつか制限事項があるそうです。
結構、導入にはハードルが高そうですね。それに導入した後のメンテナンスも…
3.Route53
ネットワーキングの最後はDNSです。
Amazon様のお言葉では…
Amazon Route 53 は、可用性と拡張性に優れたクラウドDNSウェブサービスです
だそうです。
ここまでで大分、体力を消耗してしまったので細かいところは後々、振り返るとして
具体的にできることは以下のことのようです。
(1)リソースとトラフィックパフォーマンスの監視
(2)DNSラウンドロビンによる負荷分散
(3)DNSフェールオーバーによるフォールトトレラントの実装
(4)ドメインの購入および登録
あれっ何か機能的には色々できてすごそうな印象を受けるな…
ちなみに(3)はリソースの状況を監視して、正常でないと分かった場合に
自動的に正常なリソースへDNSの向き先を変更してフェールオーバーしてくれるそうです。
(これぞ、ハイテクっ！な感じですね…)
まぁ、とは言いつつも使ってみないと何も分からないんですけどね。
総括
VPCってネットワークだったんだっていうのがこの部分の振り返りの感想ですね。
正直、インスタンスを入れる器位にしか覚えていなかったので、色々と勉強になりました。
あとはDirectConnectって個人的な印象ですが、導入したら早くなるかもしれないけど、
何か起こった際の切り分けってめちゃめちゃ大変そうだなという印象を受けました。