はじめに
BlackBeltが難しかったのでリベンジ
やってみたこと
リージョン・AZ・データセンター
- リージョンとは、AWSがサービスを提供している拠点のこと
- アベイラビリティーゾーンとは、複数のデータセンターが集まったもの
- データセンターは、複数のサーバが集まったもの
- リージョン > AZ(アベイラビリティーゾーン) > データセンター > サーバ等
- 扇風機が壊れる→サーバが熱暴走→データセンターに異常→AZが不調
- 特定のリージョン・AZのみを使っている人は動作がおかしくなる、みたいな影響がでる
- AWSのAZは距離的に十分離れているものの、レイテンシーが2ミリ秒以下という超少ない影響しか無い
- マルチAZとは、複数のAZを利用して構築する方法
- 単一のAZで運用していた場合、一つの災害でサービスが止まるといった懸念がある
- 一方で、コストもかかるのでマルチAZが最適かどうかは要件次第
VPC
- VPCとは、ネットワークをAWS内に作成できるサービス
- VPC内にサブネットという単位でネットワークを構築できる
- 利用できるIPアドレスの範囲をCIDRブロック形式で指定する
- 一度CIDRブロックを指定すると変更できないので、なるべく大きめにIPアドレスの範囲を確保できる設定にするとよい
- サブネットごとにネットワークACLをセットできる
- セキュリティグループを利用すると、インスタンス単位で通信制御ができる
- ネットワークACLを利用すると、サブネット単位で通信制御ができる
- インターネットゲートウェイを利用すると、VPCとインターネットを接続することができる
- インターネットゲートウェイは、単一障害点ではない。なぜならAWSのマネージドサービスであるため
- サブネットにはプライベートサブネットとパブリックサブネットがある
- インターネットゲートウェイとつながっているサブネットはパブリックサブネットと言われる
- インターネットゲートウェイとつながっていないサブネットはプライベートサブネットと言われる
- 仮想プライベートゲートウェイを利用すると、VPCがVPNやDirect Connectと接続することができる
- VPCエンドポイントを利用すると、VPC内から、S3等にセキュアにアクセスできる
- VPCエンドポイントには、ゲートウェイエンドポイントとインターフェースエンドポイントがある
- インターフェースエンドポイントはAWS PrivateLinkのことである
- VPCピアリングを利用すると、2つのVPC間をつなぐことができる
- AWSの外に出ないで通信できる
- つなぎ方は色々ある
- VPCフローログという機能で通信を解析できる
- Direct Connect Gatewayを利用して、1つのDirect Connect接続で、拠点と複数のAWSアカウント・VPCに接続することができる。
VPC構築例
段階的にVPCの機能を適用する例を示す。
AWSを使わない場合

AWSを使わない場合、アクセスが増えるとサーバのスケールアップ・スケールアウトが求められる

往々にして、ピークの時間とそうでない時間がある。対応としては3つあり、ピークを超えた(=稼働できなくなった)際に何らかの処理を行うか、ピークを予期した段階で何らかの処理を行うか、その両方である。
これを簡単に行うのは、AWSなどのクラウドを利用するのがよい。AWSを利用するとなると、VPCを利用したネットワークを作成することになる。


最小限の構成はIGWをVPCに接続すること。ただし、このままでは負荷が上がると耐えられない。

そこでELBやS3も組み合わせて、次の場合に対応する
- 通常時
- サーバが落ち、切り替え中
- 切り替え完了後
また、そのために「メイン」「sorry」「落ちたとき用」の系を事前準備しておく。

上記の構成では通信制御まで考慮できていない。なのでそのままでは不正アクセスのリスクが残る。

ネットワークACLやセキュリティグループによって、必要な通信のみを許可するように設定する。さらに、S3などVPC外への通信が発生しうるものは、VPCエンドポイントを利用するなどしてリスクを最小化する。

災害時等に備えて、複数AZにまたがる構成にする

最後に
難しい。