AWS試験対策（⑦ネットワーク）

自分用メモ、ネットワーク編。ポチポチ構築できるので一回やってみると意外と楽しいかもー。
但し、試験となると覚えることは多い。

VPC

論理的に分割された仮想ネットワーク。
ルータとかを物理的に調達する必要がない。
VPC作成→サブネット作成→ルートテーブル作成→セキュリティ設定の流れ。

まず、VPCはリージョンを跨げない。AZは跨げるよ。
CIDR（サイダー）をこのとき決める。シュワシュワして美味しそ。
サイダーってのは、ネットワークアドレスの部分を決めれる。たとえば16なら前の16ビットがネットワークアドレスになる。
10.0.0.0とかなら8ビットが、172.16.0.0とかなら16ビットが、192.168.0.0とかなら24ビットがネットワークアドレスだったのが、サイダーって技術でなくなって自分で指定できるようになったと思えばよき。

その次はサブネットを作成する。
AZごとにつくる。AZを跨ぐことはできない。
サブネット作成するときに、サイダーブロックを指定する。
計算は深く考えないで、VPC側が16ビットでサブネットマスクが18なら、サブネットの数は18-16=2、2の2乗になり、IPの数は32-18=14、2の14乗になる。
一番多いのはサブネットマスクが24。第3オクテット目で区切れるからわかりやすい。
サブネットの数は24-16で2の8乗。IPの数は32-24でこちらも2の8乗になる。気をつけなきゃいけないのは、オンプレは2IP使えなかったが、AWSは5IP使えない。
また、サブネットはインターネットにルートがあるパブリックサブネットと、ルートがないプライベートサブネットがある。

次に、ルートテーブルを設定することによって、サブネットを出るアウトバウンドトラフィックは送信先が指定される。
サブネットにルートテーブルを作るというよりは、ルートテーブルを作ってそれをサブネットに関連付けてるイメージ。

次に、ゲートウェイを作って、VPCにアタッチする。
主要なゲートウェイは以下。

• インターネットゲートウェイ
  インターネットと通信するためのゲートウェイ。

• 仮想プライベートゲートウェイ
  他の拠点（オンプレとか？）とVPN接続する際の、VPC側に作るゲートウェイ。

• カスタマーゲートウェイ
  オンプレとVCPをVPN接続する際に、クライアント側に作るゲートウェイ。

• NATゲートウェイ
  プライベートサブネットからインターネットにアクセスする際に、プライベートIP→パブリックIPにアドレス変換してくれるゲートウェイ。インターネットからはプライベートサブネットにアクセスしないようにできる。
  要するにこれをパブリックサブネットに置いて、
  プライベートサブネット→パブリックサブネット→インターネットゲートウェイ→インターネットって順で繋ぐ。

サブネットの種類は、ルートテーブルにインターネットゲートウェイが設定されてるかどうかで決まる。
送信先を0.0.0.0/0とするとインターネットゲートウェイを指定したことになるので、パブリックサブネットになる。逆にそうじゃないならプライベートになる。

セキュリティ設定
ファイアーウォールをセキュリティグループとネットワークACLで設定する。

セキュリティグループ
インスタンス単位で、許可する通信のみをインバウンドとアウトバウンドのトラフィックについて設定する。
ステートフルなので戻りのトラフィックは気にしなくていい。設定したすべてのルールが適用される。

ネットワークACL
サブネット単位で、許可、拒否する通信をインバウンドとアウトバウンドのトラフィックについて設定する。
ステートレスなので戻りのトラフィックを気にしないといけない。設定した番号の順番通りにルールが適用される。

エンドポイントの作成

プライベートIPで使える空間とパブリックIPで使える空間がある。パブリックIPを持つサービス（S3とか）にVPC内部からアクセスしたいときに、このエンドポイントという中継地点を使う。S3の時に書いた。略。

ピア接続

VPC同士の接続ができる。異なるAWSアカウントでも関係ない。
しかし、これで通信できるのは、直接ピア接続してるVPCのみ。友達の友達は友達じゃないのだ。その人と友好関係を築ければ別だが。

ELB

ロードバランサー。3種類あるよ。ALB、NLB、CLBの3つ。アプリかネットワークかクラシックか。CLBはレガシーでもうほとんど使わないらしい。
また、作るときは2つ以上のAZを指定しないとだめだよ。

	ALB	NLB	CLB
種類	L7 リバースプロキシ	L4 NATロードバランサ	L4/L7 リバースプロキシ
サポートプロトコル	HTTP、HTTPS(Layer7)	TCP、TLS(Layer4/5)	HTTP、HTTPS(Layer7) TCP、TLS(Layer4/5)
セキュリティグループ	設定あり	設定なし	設定あり
SSL Termination	HTTPS Termination	TLS Termination	SSL Termination
主なユースケース	柔軟なアプリ管理とHTTP Terminationが必要な場合	高度なパフォーマンスと静的IP(固定IP)が必要な場合	昔の。

特徴は次の通り

• ALB

レイヤー7（なんのこっちゃ）をサポートする。同一インスタンスでも複数のポートに負荷分散したり、パスベース、ホストベースのルーティングサポートがあったり、ネイティブHTTP/2（なんのこっちゃ）対応してたりする。

パスベースのルーティングとは、リクエスト内のURLに基づいてリクエストを転送してくれるルーティング方式。要するに、http://hoge/app1からきたリクエストも、http://hoge/app2からきたリクエストもすべてこいつが各コンテナに振り分けてくれる。今まではhttp://hoge/app1用のロードバランサー、http://hoge/app2用のロードバランサー…と一つ一つ必要だった。

ホストベースのルーティングは、HTTPヘッダー内のホストフィールドに基づいてリクエストを転送する仕組み。要するに、http://www1.hoge/からきたリクエストも、http://www2.hoge/からきたリクエストもすべてこいつが各ホストに振り分けてくれる。今まではこっちも一つ一つ必要だった。

• NLB

レイヤー4/5をサポート（なんのこっちゃ）する。NLBは固定IPを持つことができる。
また、NATタイプのロードバランサーなので、トラフィックの宛先のIPを書き換えて転送するため、帰りのトラフィックはロードバランサー経由せずターゲットから直接クライアントへ行く。なのでパフォーマンスが高い。
要するに、クライアント→ALB→ターゲット→ALB→クライアントって戻るのが普通のところ、
クライアント→NLB→ターゲット→クライアントへ直に戻る。

また、セキュリティグループが使えないため、ターゲットのインスタンスで設定する必要がある。

• CLB 古い。以上。

スケーラビリティ

負荷が増えると自動的にELBを増やしてくれるよ。負荷増えすぎて間に合わないほどやばかったら503エラーを返してくれるよ。
ただ、こうなるのを防ぐために、Pre-Warmingという暖機運転機能がある。やばくなりそうな時間帯がわかってるなら予め増やしておけばいいってわけ。しかしこれはサポートに申請する必要がある。ビジネスかエンプラじゃないと使えないってよ…

ヘルスチェック

健康診断。インスタンスがちゃんと動いてるか見る。TCP/HTTP/HTTPSで応答確認する。正常ならリクエストを転送する。障害やメンテで異常になったらそこへは転送しない。検知するだけで再起動とかはしてくれない。

SSL Termination

Webサーバの場合、外部通信をSSLで暗号化するのが普通。これを使えばクライアントとELBの間をSSL通信にしてくれる。ELBとターゲット間はHTTP通信。これを使うには、証明書をロードバランサに入れる必要がある。
また、NLBではSSLアクセラレーション機能が提供されていないため、ターゲット側でSSLターミネートを行う必要がある。

スティッキーセッション

ELBによってクライアントからのリクエストを毎回同一のインスタンスへ送信する方法。
同じクライアントから来たリクエストを同じインスタンスへ送信しなきゃいけない場合とかに使う。Cookieに設定した値を利用しながら動作するとき等。
株買うときとかに使われるアレかと。

• 任意の有効期限を指定する方法

任意に指定された有効期限までの間、同一インスタンスとのセッションを維持する。チケット買うときとか、10分以内に手続き済ませてくださいみたいなやつ。
有効期限指定しなかった場合はCookieをクライアント側で意図的に削除しないと永続。

• アプリケーションのCookieに従う方法

セッションの維持を行うCookie名を指定することで、そのCookie名を含むリクエストがあった場合、同一のインスタンスとのセッションを維持する。
要するに顔パス的な。最初は覚える必要あるけど二回目は前の続きからすっと入れる。

Auto Scaling

需要に応じてインスタンスを増やしたり減らしたりできる機能。また、異常が起きたらそれを切り離ししたりしてくれる。
コスト最適化と高可用性。
これ自体に課金は発生しない。増えたインスタンスなどには課金される。
対象は以下。

• EC2
• EC2スポットフリート
• ECS
• DynamoDB
• Aurora

起動設定

どのようなインスタンスを起動するかの設定。自分でインスタンス作る時と同じように設定していく。設定しておけばこれが起動される、いわばAutoscalingのテンプレ。

Auto Scalingグループ

グループに対してスケーリングしてくれる。起動したインスタンスは複数のAZで均一にバランシングされる。AZ自体が逝ってしまった場合はその他のAZで起動してくれる。
しかし、リージョンをまたぐことはできない。
設定項目は以下。

• インスタンスの希望起動数(最大、最小起動数)
• VPC/サブネット
• ELB/ヘルスチェック
• スケジューリングポリシー
• スケジュールされたアクション

スケジューリングプラン

手動、動的、スケジュールの三種類がある。
手動はその名の通り、バッチ処理があるときとかに手動で設定する。
動的はCloudWatchで閾値に近づいたらインスタンス数を変更する。みたいなことができる。

• Target tracking scaling
  平均使用率が50%になるようにスケーリング的な

• Step scaling
  使用率40超えたら一台追加、90超えたら二台目追加のような、ステップ(段階)を踏んで増やせる。

• Simple scaling
  使用率が40超えたら一台追加みたいな感じ。

の三種類がある。維持するのか、段階を踏むのか、やばくなってきたから増やすのか。

スケジュールスケーリングは、毎日21時にアクセス多いからあらかじめ毎日21時に増やす設定しておこう！みたいな感じ。繰り返す系ならこれ。

ELB/ヘルスチェックの設定

ELB配下のインスタンスを対象にする場合、ヘルスチェックのタイプをEC2もしくはELBにする。
EC2の場合はステータスがrunning以外となった場合、また、システムステータスがimpairedとなったときに異常と判断される。
ELBの場合はEC2の場合プラス、ELBのヘルスチェックが正常とならない場合、異常と判断される。
異常になった場合、該当インスタンスは削除され、新しいインスタンスを起動することで±0する。代わりはいくらでもいるのよ。
これをAuto Healingという。
ちなみに、この管理下のインスタンスを停止すると、インスタンスはTerminate(削除)される。
これは、「EC2がrunning以外になったから異常だ！増やさなきゃ！！」ってなるのを防ぐため。
自分で停止させたのに、AutoScalingちゃんが「一台減っちゃった！増やさなきゃ！！」って増やしちゃったらまったく意味ないから。便利なようでおちゃめな子だよね。

いったん区切り。次回Route53、Direct Connect、CloudFrontをやってネットワークは終わり。DBへ行く。