【AWS】知識ゼロから理解するRDS超入門
AWSのデータベースサービス「Amazon RDS」を初心者にもわかるように解説します。未経験には難しいMultiAZ構成やレプリケーションは、マスター/スレ...
前回（第1回）のおさらい
前回の「VPC設計に必要なIPアドレスとサブネットの基礎知識」では、IPアドレスとサブネットマスクの基礎について理解を深めることができたかと思います。
これらはAWSにてVPCネットワーク・サブネットなどを構築する際に必須となる大事な知識ですので、多少時間がかかったとしても必ず押さえておくべき内容です。
この記事でもなるべく丁寧に解説していきますので、前回の記事を参考にしながら進めていきましょう！
この記事で実現したいこと
MIYABI Labでは、完成図をきちんとイメージすることを大切にしています。何かを製作する上ではここにしっかりと時間をかけることが後々大切になっていきます。
まずこちらが、連載「AWS VPCネットワークを構築してセキュアな環境にEC2 Webサーバーを設置・運営する」シリーズ全体の最終目標になります。
そしてこちらが、第2回（この記事）と第3回と第4回で目指す目標になります。
何層にも重なっているので少々分かりづらいですね...笑
全体から見るとほんの一部かもしれませんが、これでも立派なネットワークです。複雑で巨大なネットワークでも、分解していくとコンパクトな構成の積み重ねで成り立っていることに気づきます。
この記事では、以下の部分まで完成させることを目標にします。
それでは、AWSにおける基本となるVPCネットワーク・サブネットの作り方について、その原理をひとつずつ理解しながら構築していきましょう！
重要なAWS用語の意味を理解しよう
ネットワーク構築に取り掛かる前に、まずはAWSで使用される重要な用語について確認しておきましょう。
結構なボリュームがありますが、どれも欠かすことのできない大切な知識なので、ひとつずつ丁寧に見ていきます。
上の図を参考に、外側から順に解説していきます。
AWS（Amazon Web Service：アマゾンウェブサービス）
Amazonが提供するクラウドコンピューティングサービスの総称で、仮想サーバーやストレージ、データベース、アプリケーション、機械学習などの様々なソリューションが提供されています。
代表的なサービスには、EC2（後述）の他にも、S3（Simple Storage Service：オンラインストレージサービス）、ELB（Elastic Load Balancing：ロードバランサー）、Route 53（DNSサービス）などがあり、100を超えるサービスの巨大複合体です。
IGW（Internet Gatewat：インターネットゲートウェイ）
その名の通り、インターネット（外の世界）と、後述するVPCネットワーク（中の世界）とを隔てる扉としての役割を果たします。
IGWを設置することによってインターネット経由でのアクセスを受け入れ、外部との通信を行うことができるようになります。逆にこれを設置しないと、HTTPやHTTPS通信はおろかSSHでの接続すらできません。
なお、IGWは後述するVPCを構築した際に自動的に作成され、自動的に紐づけられます。後から別途作成したり、削除することも可能です。
VPC（Virtual Private Cloud）
AWSクラウドの他の仮想ネットワークから論理的に切り離されている、いわば自分だけの自由なプライベート空間です。
この空間内は サブネットマスクで自由に区切ることができます。
AWSでは、VPCや後述するサブネットを作成する際のサブネットマスクは /16〜/28との制限があります。
つまり、VPCネットワークを10.0.0.0/16 とした場合には、10.0.0.0 ~ 10.0.255.255 の範囲でIPアドレスを振り分けることができます（厳密にはAmazon側で予約しているアドレスがあるので計算より5 IPアドレス分少ないです）。
IPアドレスとサブネットマスクについては必須の知識になりますので、詳しくは前回の「AWS VPCネットワーク構築に必要なIPアドレスとサブネットの基礎知識」をご覧ください。
AZ（Availability Zone：アベイラビリティーゾーン）
AWSにはRegionとAZというエリアに関する2つの概念があり、大小関係としては「Region > AZ」となります。
これらは、データセンターが存在する物理的な場所を示しており、現在では世界中に18のRegionと51のAZが存在しています。
Regionとしては、例えば米国東部（バージニア北部）、カナダ（中部）、アジアパシフィック（東京）、アジアパシフィック（シンガポール）などに別れています。
一方、Regionがアジアパシフィック（東京）の場合、その中に4つのAZが存在しています。AZ間の物理的な距離は数kmから数十kmと言われているようです。
これらが分かれている理由は一般的な負荷分散としての役割に加え、震災や戦争等によるデータセンターの機能不全を回避するための分散策としてもその役割を果たしています。
サブネット（Subnet）
サブネットとは、ある1つの大きなネットワークの中をさらに小さく分割した小規模ネットワークのことをいいます。
以下の図のように、VPC内に複数のサブネットを設置して部屋を区切ることで、役割の異なった空間を作り出すことができます。
サブネットの分割についてはサブネットマスクという概念が必要になりますので、詳しくは前回の記事をご覧ください。
ルートテーブル（Route Tables）
ルートテーブルとは、VPCネットワーク内でのトラフィックの経路を判断する際に利用され、各サブネットにはそれぞれ1つのルートテーブルを関連づける必要があります。
概念として正確にイメージするのは難しいので、それぞれのサブネットが土地で、ルートテーブルに記載する情報が道路だと思って頂ければOKです。
つまり、道がどこに繋がっているかを明示している案内板のようなものがルートテーブルです。
ちなみに、VPC内の各ルートテーブルを読み取って処理を振り分ける肝心のルーター機能については、AWS内で暗黙的に備わっているので設置や設定等の必要はありません。
この図を例にすると、
- 10.0.0.0/16 : Local
- 0.0.0.0/0 : IGW
となっています。
左の数値部分が送信先ネットワークアドレス、右の英字部分がターゲットの名称を示しています。
ここは理解するのが難しいので、少し詳しく見ていきましょう。
送信先とターゲットが意味すること
まず1つめの「10.0.0.0/16 : Local」ですが、こちらはルートテーブルを作成した際に自動的に生成されるもので、VPC構築の際に最初に設定した仮想ネットワーク全体を示しています。
したがって、このサブネットからはVPC内に道が張り巡らされている状態になるので、VPC内の通信であればこの経路が利用されます。
そして2つめの「0.0.0.0/0」ですが、この書き方はデフォルトルートと呼ばれ全ての経路を示しています。
重要なポイントとして、ルートテーブルは記載した上から順に読まれていきます。
最後の行に「0.0.0.0/0 : IGW」と書いてあるということは、すなわちどれにも該当しなかった「その他の通信」を意味するものであり、ここでは内部に向けられた通信以外は全てIGW（を通じた外の世界）に向けられているということです。
パブリックサブネットとプライベートサブネット
前述の解説について、ひとつ例を挙げて解説します。
例えば、
- 10.0.0.0/16 : Local
- 0.0.0.0/0 : IGW
というルートテーブルが関連づけられたサブネット内に存在するEC2インスタンス（後述：Webサーバー）から、yumコマンドを使って何らかのライブラリをインストールするとします。
このときEC2インスタンスは外部との通信（＝10.0.0.0/16 : Loacl ではない！）を試みるので、向かう先は0.0.0.0/0 : IGWとなります。
もしここで0.0.0.0/0 : IGWが登録されていなかったら、IGWを介してインターネット（外の世界）にパケットを転送することができないため、道に迷った通信は破棄されます。
これらのことから、0.0.0.0/0 : IGW を持つルートテーブルが紐づいたサブネットのことをパブリックサブネットと呼びます。
対照的に、これを持たないルートテーブルが紐づいたサブネットについては、外部との直接的な通信から隔離されているため、プライベートサブネットと呼びます。
当然ですが、プライベートサブネットの方がセキュリティが高いです。今回の連載の最終目標では、メインとなるEC2サーバーはプライベートサブネットに隔離する予定です。
セキュリティグループ（Security Gourp）
セキュリティグループは一種のファイアウォールのような概念であり、インバウンド（入ってくる受動的な通信）とアウトバウンド（出て行く自発的な通信）それぞれのポートと場所を制御することができます。
例えば、『後述するEC2インスタンス（Webサーバー）へのインターネット経由のアクセスはHTTP（:80）とHTTPS（:443）とSSH（:22）だけに制限したい！』といった場合には、セキュリティーグループを作成し、上記のポートのみ許可する旨を記載し、そこにEC2インスタンスを内包します。
イメージとしては、EC2（＝城）をセキュリティグループ（＝石垣）で守り、特定のアクセス（＝:80などの通行許可証を持ってる人）のみ出入りを許可する、という感じです。
インバウンドとアウトバンドにはポート以外にも、どこからのアクセスを許可するか（＝インバウンド：自宅IPのみ？誰でもOK？など）や、どこへのアクセスを許可するか（＝アウトバウンド：別のサブネットのみ？IGWを通じて外の世界へ？）といった場所についても別々に指定することができます。
EC2（Elastic Compute Cloud）
EC2はAmazonが保有するコンピューティングリソースをレンタルするサービスの名称であり、小さく分割してレンタルされた仮想マシンをEC2インスタンスと呼びます。
AWSにてWebサーバーを運用する場合は「EC2サーバー」などと表現をする場合もありますが、EC2そのものはコンピューティングリソースであって、そこにLinuxなどのOS（オペレーティングシステム）を導入することで初めてコンピューターとしての操作基盤が整います。
OSについては、EC2インスタンスを新規で立てる際に、いくつかの種類から自由に選ぶことができます。AWSではこれらをAMI（Amazon マシンイメージ）と呼んでおり、今回の連載では最新のAmazon Linux 2（RedHat系OSでEC2に最適化されている）を導入する予定です。
また、Webサーバーとしての機能を持たせたいのであれば、導入したOS （AMI）にてApacheやNginXなどのWebサーバーソフトウェアをインストールし、特定のディレクトリ領域に対するインターネットからのアクセスを許可することで、ようやくWebサーバーとしての役割を果たすことができます。
ただ、殆どの場合EC2はWebサーバーとして利用されることが多いのが現状なので、言葉足らずな会話に遭遇したら上手く脳内変換しましょう。
EBS（Elastic Block Store）
EBSはいわゆるHDDやSSDといった類のストレージ領域を提供するサービスで、状況の変化に応じて後から自由に拡大縮小させることができ、料金についても使用した分だけという使い勝手の良さがあります。
前述のEC2インスタンスはあくまでもコンピューティングリソースでありストレージ領域を持っていませんので、EBSなどを別途紐づける必要があります（自作PCみたいですね）。
実際には、EC2インスタンスを新規で立てる際に「EBSどうします？」という質問をされるので、通常はそこで作成してアタッチします。
後から容量が足りなくなって拡張する時も非常に簡単で、コンソール画面から「ボリュームを変更する」を選び、新しい容量を入力するだけです。
MySQL
依然として世界第2位の普及率を誇る、汎用性の高いオープンソースのリレーショナルデータベースです。こちらは有名すぎて説明する必要はないかもしれませんね。
AWSにもRDS（Relational Database Service）などのストレージサービスがあり、EC2とは別にRDSインスタンスを立てて、そこにMySQLをインストールしてデータを管理することも可能です（RDSは有料です）。
ただ、今回は小規模ですしデータ量も全然多くないので、EC2のAmazon Linux 2に直接MySQLをインストールして利用することにしました。
ちなみに、Amazon Linux 2のデフォルトリポジトリであるamzn2-coreを利用して yum install mysqlを実行すると、mariaDBとしてインストールされてしまいます（marinaDBについてはこちらを参考にしてください）。
marinaDBでも別にいいのですが、慣れてないのでトラブった時に面倒だなと思い、大人しくMySQLにしました。
ただ、Amazon Linux 2 へのMySQLのインストールには重要なポイントがあります。詳細なインストール方法は次回（第3回）に詳しく記載してありますので参考にしてください。
VPCネットワークを構築する
ここまでで一通り重要単語を解説してきましたが、ざっくりとイメージできましたでしょうか？
完全に理解できなかったとしても、実際にネットワーク構築を進めていくと見えてくる部分も沢山あるので安心してください。
それではAWSコンソール画面から作業を開始します。学んだ知識を形にしていきましょう！
完成イメージ
冒頭でご紹介した通り、今回（第2回）では以下の状態まで作っていきます。
AWSアカウントを作成する
これがないと何も始まりません！
アカウント作成についてもまとめようかと思ったのですが、Amazon公式がしっかりとスクショ付きで解説してくれていたので、ぜひ公式ドキュメントを参考にしてください。
料金については使った分だけ課金される従量課金制で、EC2インスタンスが1年間無料などの特典もついてきます。
課金される要素については各項目で必ずアナウンスするのでご安心ください。
コンソールにログインする
アカウントが作り終わったらそのままログインしてみましょう。
さあ、早速VPCを構築しよう！と言いたいところなのですが、ここでいきなり罠が待ち構えています（笑）
早速画面右上をご覧ください。
Regionが米国西部（オレゴン）になっているではありませんか！
このままではオレゴン州にサーバーを立てることになってしまいます。遠すぎるので通信が遅いです、たぶん。。
いずれにせよ、さすがにこの状態では気持ち悪いのでアジアパシフィック（東京）に変更しておきましょう。
VPCの作成手順と各設定項目の解説
気を取り直して進めていきます。
まずサービス一覧からVPCを選択し、VPCウィザードの開始をクリックします。
最終的なゴールとしては2つめの「パブリックとプライベートサブネットを持つVPC」の形にしようとしているのですが、今回はサブネットを単独で作成する手順なども別途解説していきたいので、1つめの「1個のパブリックサブネットを持つVPC」を選択して次に進みます。
特に意識しないのであれば、
- パブリックサブネットのIPv4 CIDR ：10.0.0.0/20~24
- アベイラビリティゾーン：ap-northeast-1d（指定無しでもこれになるが念のため）
として設定しておくと良いでしょう。残りは以上のように必要事項を埋めていきましょう。
上から順番に詳しく解説していきます。
VPCのIPv4 CIDRブロックの決め方
前回の記事でIPアドレスについてがっつり解説しているので、そちらを見て頂いた方は理解できるかと思います。
IPv4は一般的にxxx.xxx.xxx.xxxの形式で表されるIPアドレスの記法であり、CIDR（Classless Inter-Domain Routing：サイダー）表記はネットワーク部とホスト部の区切りを自由に決めることができる仕組みでしたね。
ここでは10.0.0.0/16なので、2進数表記にした場合、前半の16ビットがネットワーク部、後半の16ビットがホスト部になります。
ホスト部の部分がIPアドレスとして割り当てられる総数になるので、256 * 256 = 65,536 通りになります。
ここでは利用可能なIPアドレスが65,531となっていますが、AWS公式によると、
10.0.0.0: ネットワークアドレスです。
10.0.0.1: VPC ルーター用に AWS で予約されています。
10.0.0.2: AWS で予約されています。DNS サーバーの IP アドレスは、常に VPC ネットワークのベースに 2 を付加したものですが、各サブネット範囲のベースに 2 を付加したアドレスも予約されています。複数の CIDR ブロックを持つ VPC の場合、DNS サーバーの IP アドレスはプライマリ CIDR にあります。詳細については、「Amazon DNS サーバー」を参照してください。
10.0.0.3: 将来の利用のために AWS で予約されています。
10.0.0.255: ネットワークブロードキャストアドレスです。VPC ではブロードキャストがサポートされないため、このアドレスを予約します。
とのことですので、65,536 - 5 = 65,531 通りとなっています。
もしここでVPCのネットワークアドレスを10.0.0.0/24としたとき、2進数表記にした場合、前半の24ビットがネットワーク部、後半の8ビットがホスト部になりますので、IPアドレスは256 - 5 = 251通りしか使えません。
あまり小さくしすぎても今後のさらなる分割（サブネットの作成）によりどんどん少なくなってしまいますので、VPCはできるだけ大きく取っておくほうが無難です。
IPv6 CIDRブロックは必要か？
結論から言うと、Webサイトの運営程度であれば到底必要ありません。「IPv6 ブロックなし」を選んでおけばOKです。
本当にいらないの？と不安な人のために、IPv6が提供できるIPアドレスについて簡単に紹介しておきます。
- IPv4は32ビットを8ビットずつピリオド（ . ）で4つに分割して表現していました。
- IPv6は128ビットを16ビットずつコロン（ : ）で8つに分割して表現します。
つまり、IPv6はIPv4の4倍のビット数をもつことになります。
ただし、単純にIPアドレスの数が4倍になった、というのは計算間違いです。計算式で表すと、
- IPv4：2^32 = 1024^3 * 4 = 約43億個となります（これでも世界では枯渇して問題になっている...）。
- IPv6：2^128 = 1024^12 * 256 = ... 約340澗（かん）個になります（一 十 百 千 万 億 兆 京 垓 杼 穣 溝 澗←）。
となります。もう桁違いです。理論上限りなく無限に近く、IPアドレスの枯渇問題は解決されます。
IPv4 ですら使い切るのは難しいかと思いますので、IPv6は今回は必要ないでしょう。
パブリックサブネットのIPv4 CIDR
ここは将来的な展望を想像してから決定しましょう。
前の画面で「1個のパブリックサブネットを持つVPC」を選択しているので、ここでそのサイズを決めろと言われている状況です。
例えば、以下のようにサブネットを10.0.0.0/18として作成したとします。
これを32ビットで表記すると以下のようになります。
// 10.0.0.0/18ネットワークを2進数で表す
00001010 00000000 00000000 00000000 : VPC内のサブネットワーク1のネットワークアドレス
00001010 00000000 01000000 00000000 : VPC内のサブネットワーク2のネットワークアドレス
00001010 00000000 10000000 00000000 : VPC内のサブネットワーク3のネットワークアドレス
00001010 00000000 11000000 00000000 : VPC内のサブネットワーク4のネットワークアドレス
11111111 11111111 11000000 00000000 : VPC内のサブネットワークのサブネットマスク
左から16ビットがネットワーク部、次の2ビットがホスト部を削って作られたサブネットワーク部、残り14ビットがホスト部となります。
つまり、サブネットを10.0.0.0/18とすると、最大で2^2 = 4つまでサブネットを作成することができ、2^14 = 16,384 通りのIPアドレスを作ることができます。
ですが、これだとサブネットが少なすぎますよね。すぐに枯渇してしまいそうで不安です。
同様に計算すると、
// サブネットマスク、利用できるサブネット数およびIPアドレス数
/18 = /16+2 = 2^2=4通りのサブネット、2^14=16,384通りのIPアドレス
/20 = /16+4 = 2^4=16通りのサブネット、2^12=4,096通りのIPアドレス
/22 = /16+6 = 2^6=64通りのサブネット、2^12=1,024通りのIPアドレス
/24 = /16+8 = 2^8=256通りのサブネット、2^12=256通りのIPアドレス
となります。
ここで言うIPアドレスは、VPC内に設置するEC2インスタンスやELB（ロードバランサー）、EDS（データベース）インスタンスなどに使用するローカルIPのことを指しています。先ほどと同様に予約の関係で-5します。
僕の場合は、サブネットはどんなに多くても5,6個しか使わなかなと思ったので、キリの良い10.0.0.0/20として設定しました。
それでも不安な場合は、/22や/24でも全然問題ないと思います。
AZ（アベイラビリティーゾーン）の選択
現状では、
- ap-northeast-1a
- ap-northeast-1c
- ap-northeast-1d
の3つから選ぶことができます。また、指定無しを選ぶと新しい-1dに自動的に割り振られます。
どれかがハズレみたいなことはないので、好きなアルファベットを選んでください（笑）
残りの項目について
VPC名は自由に決めてOKです。後からでも変更できます。
サブネット名も後から変更できるのですが、ここではパブリックサブネットを作成するので、publicという英単語を入れておくと後で分かりやすくなります。
エンドポイントについては、作成するVPCとAWSの他のサービス（S3など）を接続する際に、IGW経由ではなくAWS内で完結するプライベートな接続を実現するために必要なサービスです。
今回はそれらのサービスは利用しないので、追加しなくて大丈夫です。
DNSホスト名は有効にして名前解決できるようにします。
ハードウェアのテナンシーとは、ハードウェアを物理的に占有するかどうかの話であり、デフォルト（＝占有しない）のままでOKです。
VPCを作成する
上述した設定項目の内容をきちんと理解した上で選択できてから作成ボタンを押しましょう。
問題がなければ以下の画面に遷移します。
この画面に遷移する直前に一瞬だけ表示されるのですが、VPCの作成と同時にIGWとルートテーブルが自動的に作成されています。
また、設定したIPv4 CIDRのサブネットも作成されていますので、それぞれコンソール画面の左メニューから確認しておきましょう。
それぞれ名前がないものはつけておくと便利です。タグはどちらでも構いませんが、この規模であれば不要です。
IGWの確認
- 名前は入力しましたか？
- 状態はattachedになっていますか？
- アタッチされているVPCは先ほど作成したもので間違いありませんか？
ルートテーブルの確認
- 名前は入力しましたか？
- 明示的に関連づけられたサブネットが1になっていますか？（画像では2になってます）
- 送信先0.0.0.0/0のターゲットがIGWを向いていますか？
- ステータスはアクティブですか？
サブネットの確認
- 名前は入力しましたか？
- 親となるVPCは先ほど作成したもので間違いありませんか？
- サブネットのIPv4 CIDRは適切ですか？
- AZはきちんと設定されていますか？
- ルートテーブルは上記のものに紐づいていますか？
正しく設定できていればOK！
お疲れ様でした！これで最低限のネットワーク環境の整備が整いました。
ここまでの作業で、目標としていたところまで構築することができました。
次回（第3回）の目標はこちら↓です。事前に知識さえついて入れば、次もスムーズに作業を進めていけるかと思います。
足りていないのは、
- セキュリティグループの作成
- EC2インスタンスの作成
- EBSの関連付け（アタッチ）
- ApacheやMySQLなどのインストール
の4項目です。
このうち上の3項目は一発で作れてしまうので、作業自体はそこまで多くないです。理解して進めるのに一番時間がかかると思いますが、一生モノの知識になるので続きも頑張っていきましょう！
第2回のまとめ
今日はここまで！このままEC2インスタンスの設置まで進めようと思ったのですが、このままだと20,000文字を超えそうな勢いだったのでここら辺で記事を分割します。
勉強しながらなのでスピード感に欠けると思われるかもしれませんが、ここまでの内容を理解できていれば次回以降も楽しく進めていくことができるはずです。
ここまでの流れで躓いてしまったり、よく理解できない部分などがありましたらお問い合わせフォームからご連絡ください。完成するまで責任を持ってしっかりサポートいたします！
次回、連載「知識ゼロからAWS VPCネットワークを構築してセキュアな環境にEC2 Webサーバーを設置・運営する」の第3回は、
- 構築したVPCネットワークへのEC2インスタンスの作成
- EBSとセキュリティーグループの作成
- EC2インスタンスへのSSH接続および初期設定
についてご紹介する予定です。
引き続きどうぞよろしくお願いいたします！
連載（知識ゼロからAWS VPCネットワークを構築してセキュアな環境にEC2 Webサーバーを設置・運営する）の記事一覧
- 第1回：VPC設計に必要なIPアドレスとサブネットの基礎知識
- 第2回：専門用語の解説とVPC環境を構築する手順（ここ）
- 第3回：EC2を作成してSSH接続する
- 第4回：Apache2.4, PHP7, MySQLの導入と初期設定
- 第5回：踏み台サーバーでセキュアなネットワークを構築する
- 第6回：執筆中です！
