AWSの基本的な使い方

Slide 1

Slide 1 text

AWSの基本的な使い方 M3 社内研修用エンジニアリンググループ園田

Slide 2

Slide 2 text

はじめにスライドに利用しているマネジメントコンソールのスクリーンショットは2018/06時点のものとなります。 AWSの情報探索時の心構えとして、マネジメントコンソールは頻繁にUIが変わるので、スクリーンショットをあてにしないようにしましょう。（リソースのモデルを把握しましょうw）今回のスライドはかなり初心者向けの内容となっているため、ざっと資料を先読みして自分にとって不要だなと判断したら時間がもったいないので読み飛ばしていただいて結構です。

Slide 3

Slide 3 text

はじめにアンケートなどでM3でのユースケースがあるとわかりやすいという意見がありますが（実際私もその方がわかりやすいと思いますが）、M3のユースケースを私自身すべては把握しておらず、また使い方も千差万別のため「コレ」というものがありません。前回講義でも触れましたが、AWSは非常に膨大な機能仕様があり、それらの組み合わせはほぼ無限に存在するため、この短い時間では代表的なユースケースですら解説するのは困難です。使い方の説明をメインにしているため、料金体系などの説明もあまり出てきません。今回の講義はどんなユースケースにおいても必要になるサービスや概念の説明がメインとなっています。

Slide 4

Slide 4 text

アジェンダ ● 第1章 VPC ○ サブネット ○ NATゲートウェイ ● 第2章 EC2 / EBS ○ EBS ○ インスタンスプロファイル (IAMロール) ○ UserData ○ セキュリティグループ ● 第3章 AutoScaling / ELB ○ AMI ○ Launch Template ○ AutoScalingGroup ○ ELB

Slide 5

Slide 5 text

一般的なWebシステムにおけるAWS環境の構築手順通常のWebシステムの場合、構築手順はおおまかに以下のような流れになります。 1. ネットワークリソースの構築（VPC, サブネットなど） 2. サーバリソースの構築（EC2、RDS、セキュリティグループなど） 3. 負荷分散環境の構築（ELB、AutoScalingGroupなど） 4. BCP(国外リージョンによるDR)環境の構築（今回は触れません）以降のスライドでは、それぞれの構築フェーズで行う作業と、考慮すべきポイントを解説します。

Slide 6

Slide 6 text

構築環境のイメージ時間の都合上、今回はRDS構築の説明はしません。

Slide 7

Slide 7 text

第1章 VPC

Slide 8

Slide 8 text

ネットワークリソースの構築 VPCによるネットワークリソースの構築を行います。VPCはほとんどのユースケースで必要になる可能性が高いです。AWS利用の前提知識といえます。 VPCを構築する上で考慮しなければならない事項は以下の通りです。 ● 他のVPCや別アカウントのVPCと接続する必要があるかどうか。 ● 必要なIPアドレスの個数。（1VPCあたり上限65,536 - α） ● IPv6でのアクセスが必要かどうか。（通常は不要） ● VPC内のインスタンスからインターネットを参照可能とするかどうか。（通常は必要）特に上２つは後からの変更が非常に困難なため、初期構築時に必ず検討する必要があります。

Slide 9

Slide 9 text

ネットワークリソースの構築（注意事項）他のVPCや別アカウントのVPCと接続する必要があるかどうか。 VPCは構築時にCIDRを指定しますが、後から変更はできません。他のVPCや別アカウントのVPCとVPCピアリング（VPC間接続）する際に、プライベートネットワークのアドレスが被っていた場合、接続できません。そのため、接続先のVPCとネットワークアドレスが被らないようにCIDRを指定する必要があります。 VPCエンドポイント + NLBという手段で接続できなくもないですが、構成が複雑になるためオススメしません。これは最終手段です。 https://dev.classmethod.jp/cloud/aws/try-aws-privatelink_1/

Slide 10

Slide 10 text

ネットワークリソースの構築（注意事項）必要なIPアドレスの個数。（1VPCあたり上限65,536 - α） VPCのIPレンジ（ネットマスク）は最小で16ビットです。65536個のIPアドレスを発行可能ですが、AWSの内部リソースに消費される予約分や、ELBなど動的に増減するIPアドレスを考慮に含めてIPアドレスの個数を検討します。通常のWebシステムでIPアドレスが枯渇することはまずありませんが、VPC内で Lambdaを大量に実行する場合や、EMRなどで大量のスポットインスタンスを立ち上げる場合はIPアドレスの枯渇を意識する必要があります。もし60000を超えそうな場合はVPCを分割しても問題ないアーキテクチャで実装する必要があります。

Slide 11

Slide 11 text

ネットワークリソースの構築（注意事項） VPC内のインスタンスからインターネットを参照可能とするかどうか VPC内のインスタンスは踏み台インスタンスを除き、インターネットから接続不可能なプライベートサブネットに構築するのが一般的です。ただし、インターネットへのアクセスは必要になるケースは多いです。 ● bundle installなど、パッケージのダウンロード ● sentryやdockerhubなど外部サイトへのアクセス最初からこれらを考慮したクラウドネイティブなシステムを除き、ほとんどのケースでは外部サイトへのアクセスが必要となります。インターネットへのアクセスが必要な場合、通常はNATゲートウェイをVPCに構築します。(NATインスタンスやForward Proxyという手段もあります )

Slide 12

Slide 12 text

ネットワークリソースの構築（詳細手順）新規ネットワークを構築するには以下の手順で行います。 1. VPCの作成 2. インターネットゲートウェイの作成 3. パブリック用のサブネットの作成 4. パブリックサブネットの設定 5. プライベート用のサブネットの作成 6. NATゲートウェイの作成 7. VPCエンドポイントの作成（作成は任意、今回は割愛） 8. プライベートサブネットの設定この順序は、マネジメントコンソールでの作業順序となります。ややこしいのですが、マネジメントコンソールで作成する場合と、Terraformなどで作成する場合で作業順序が異なることが多々あります。

Slide 13

Slide 13 text

VPCの作成 VPCの作成に必要なパラメータは名前とCIDRの2つです。 VPCの名前です。Nameタグに設定されます。他の人が見てもわかりやすい名前をつけましょう。my-vpcとかは言語道断。 VPCのIPアドレス範囲です。他のVPCと同じでもエラーになりませんが、VPC間でのネットワーク接続が必要な場合は考慮が必要です。特に理由がない限り16ビットで切るのが一般的です。これらのパラメータは通常のケースではデフォルトで問題ないです。 IPv6でのアクセスが絶対に必要な場合はまずないでしょう。

Slide 14

Slide 14 text

VPCの作成 VPCを作成すると、以下のリソースがデフォルト生成されます。 ● デフォルトのセキュリティグループ ● デフォルトのルートテーブル（メインルートテーブル）これらのデフォルトで生成されたリソースは、VPCが存在する限り破棄できないため、 TerraformなどInfrastructure as Codeで管理する場合は基本的に利用しないほうがいいです。 VPCに限らず、デフォルト生成されたリソースは基本的に無視したほうがTerraformなどで管理しやすいです。自動生成されるリソースは、他にはDHCPオプションやRDSパラメータグループなどがあります。

Slide 15

Slide 15 text

インターネットゲートウェイの作成 VPCとインターネットを接続するための仮想ルータである、インターネットゲートウェイ (IGW)を作成します。インターネットからの接続が不要でも、NATゲートウェイ経由でインターネットへ接続する際に必要になるため、作成するケースがほとんどです。踏み台インスタンスにも必須です。

Slide 16

Slide 16 text

インターネットゲートウェイの作成作成したIGWをVPCにアタッチします。IGWをアタッチしない限り、VPCとインターネットは相互通信不能です。(セキュリティインシデント発生時など、IGWをデタッチすることがあります)

Slide 17

Slide 17 text

パブリック用のサブネットの作成 AWSにおいてAZで分割された仮想ネットワークをサブネットと呼びます。インターネットから直接通信可能なサブネットをAWS用語でパブリックサブネットといいます。パブリックサブネットを構築するためには、まずパブリックサブネット用のサブネットを作成します。ややこしいのですが、パブリックサブネットというリソースは存在しません。作成されたサブネットに対してIGWをルーティングすることで、そのサブネットはパブリックサブネットとなります。パブリックサブネットには、踏み台インスタンス、および外部からHTTP(S)でアクセスするためのELBを含めることになります。ELBをマルチAZで構築するためには、パブリックサブネットを複数のAZに作成する必要があります。

Slide 18

Slide 18 text

パブリック用のサブネットの作成サブネットの名前です。Nameタグに設定されます。SuffixにAZをつけるのが慣例です。 AZを選択します。マルチAZにする場合はサブネットを複数作成します。サブネットのAZを後から変更することはできません。サブネットのIPレンジをCIDRで指定します。通常、プライベートサブネットよりもIPアドレスの個数は少なくすみますが、わかりやすくするため/24にすることが多いです。

Slide 19

Slide 19 text

パブリックサブネットの設定パブリックサブネット用に作成したサブネットに割り当てるルートテーブルを作成します。

Slide 20

Slide 20 text

作成したルートテーブルに 0.0.0.0/0 宛（ローカルネットワーク以外のすべての通信）のパケットをVPCにアタッチしたIGWにルーティングさせるように設定します。（ルートテーブルは上から評価されます）パブリックサブネットの設定 VPC内のIPアドレスはすべてローカルネットワーク内の通信として扱われ、変更はできません。そのため、他のVPCと通信する場合はIPアドレスの範囲がかぶらないようにしなければなりません。

Slide 21

Slide 21 text

この設定が完了した時点で、関連づけたサブネットは便宜上、パブリックサブネットと呼ばれるようになります。パブリックサブネットの設定作成したルートテーブルとパブリックサブネット用に作成したサブネットを関連付けます。 ELBなどをマルチAZ構成にする場合はAZの異なる複数のサブネットを関連付けます。明示的に関連付けを行う前は、VPC作成時に自動生成されたデフォルトのルートテーブル（メインルートテーブル）と関連付けられています。

Slide 22

Slide 22 text

プライベート用のサブネットの作成パブリック用のサブネットを作成した際と同様に、プライベート用のサブネットを作成します。マルチAZが必須なケースがほとんどなので、複数AZで作成します。VPC内で大量のリソースを作成する場合はCIDRを大きめに切ります。当然ですが、パブリックサブネットと同じAZを選択したほうが通信のレイテンシが少ないため、特に理由がない限りパブリックサブネットと同じAZを選択します。

Slide 23

Slide 23 text

NATゲートウェイの作成プライベートサブネット内のインスタンスがインターネットに接続可能なようにNATゲートウェイを作成します。 NATゲートウェイと関連付けるサブネットを選択します。ここで選択するサブネットはIGWと通信可能でなくてはなりません。つまり、先に作成したパブリックサブネットを選択する必要があります。

Slide 24

Slide 24 text

プライベートサブネットの設定プライベートサブネット用のルートテーブルを作成します。

Slide 25

Slide 25 text

プライベートサブネットの設定作成したルートテーブルに、インターネット向けパケットをNATゲートウェイに送信するようにルーティング設定を行います。

Slide 26

Slide 26 text

プライベートサブネットの設定プライベートサブネット用に作成したサブネットを、ルートテーブルに関連付けます。これで、プライベートサブネット内に構築されるインスタンスがインターネットに対してパケットを送信可能になります。このキャプチャは保存前の状態です。

Slide 27

Slide 27 text

補足: NATゲートウェイの冗長化ここまでの手順で、以下のリソースが作成されています。 ● VPC ● インターネットゲートウェイ ● パブリックサブネット * AZ ● プライベートサブネット * AZ ● NATゲートウェイ ● ルートテーブル * 2 (パブリック用、プライベート用) このままでもシステム運用可能ですが、NATゲートウェイがシングルAZになっているため、インターネット通信を頻繁に行うシステム（電子決済や外部認証など）では可用性が問題になります。

Slide 28

Slide 28 text

補足: NATゲートウェイの冗長化 NATゲートウェイを冗長化するためには、各AZのパブリックサブネットと関連付けた NATゲートウェイを複数作成し、プライベートサブネット用のルートテーブルをそれら NATゲートウェイの数だけ作成する必要があります。 1. NATゲートウェイを各AZに作成する。 2. ルートテーブルを各AZ用に作成してNATゲートウェイにルーティング。 3. 各AZごとのサブネットに個別にルートテーブルを関連付ける。 3.1. ルートテーブル:プライベートサブネットが 1:1になる。 NATゲートウェイの冗長化はそれなりに費用がかかります。デプロイのタイミングでしかインターネット通信が不要な場合や、ミッションクリティカルでないシステムではNATゲートウェイの冗長化が本当に必要か検討しましょう。 AZあたりのNATゲートウェイ料金 => $0.062/時 => $45.26/月

Slide 29

Slide 29 text

補足: NATゲートウェイが不要なケース以下に該当する場合はNATゲートウェイが不要な可能性があります。 ● インターネット通信量や通信頻度が少ない場合 ○ NATゲートウェイではなく、 NATインスタンスを構築する。 ○ インターネット通信が必要な場合（デプロイ時や AMI作成時など）のみNATゲートウェイを構築してルーティングする。（この操作は Lambdaなどで実装する） ● 出口対策などでフォワードプロキシを構築する（もしくは構築済みの）場合 ○ インターネット向けの通信をプロキシサーバを経由するようにルーティングする。 ● 通信対象がAWSのサービスのみの場合 ○ S3やCloudWatch LogsなどVPCエンドポイントがサポートされているサービスでは VPCエンドポイントを利用する。 ○ Amazon LinuxのyumリポジトリはS3なので、標準リポジトリのみ利用の場合は VPCエンドポイントで代替可能。 ● 接続先サイトに対してIPv6で接続可能な場合 ○ Egress Only Internet Gatewayの利用を検討する。（自分は使ったことないのであまり良く知りません・・・）

Slide 30

Slide 30 text

以上でネットワーク構築は完了です。

Slide 31

Slide 31 text

お気づきになりましたか？ここまでで、セキュリティグループについて触れていません。 AWS初心者にありがちなのが、ネットワーク通信制御とセキュリティグループとを混同することです（少なくとも私は最初混乱しました。インフラの人から見たらハナから別物なのかなあ・・・）。セキュリティグループで通信を許可しても、VPCでルーティングされていなければ通信は不可能です。また、セキュリティグループは文字通り、リソースを通信単位でグルーピングするためのものです。ネットワーク設定とは厳密に異なります。AZやサブネットの概念がありません。セキュリティグループはリソースありきとなるため、次の章から説明します。とはいえあまり複雑に捉えず、セキュリティグループはネットワーク設定の上にあるレイヤと思っておけば問題ないです。

Slide 32

Slide 32 text

第2章 EC2 / EBS

Slide 33

Slide 33 text

サーバリソースの構築 EC2は仮想マシンを時間課金で起動するタイプの、いわゆるIaaSという概念に該当するものです。つい最近、ベアメタルインスタンス（物理マシン）のサポートも開始されました。 ELB、ECS、Elastic Beanstalk、EMR など数多くのサービスがEC2をラップしたサービスなので、EC2の概要を知ることはAWS利用の上で必須といえます。実際に踏み台用のEC2インスタンスを作成する手順に沿って、EC2構築における概念や考慮事項を説明していきます。

Slide 34

Slide 34 text

サーバリソースの構築 EC2を構築するうえで考慮しなければならないのは以下の事項です。 ● OSとバージョン ● インスタンスタイプ（CPU、メモリ、ネットワーク帯域） ● ストレージの種類とサイズ、IOPS性能 ● サーバの初期化処理（UserData =>プロビジョニングスクリプト） ● インスタンスプロファイル（IAMロール） ● Windowsの場合はドメイン、ライセンスなど考慮事項多数

Slide 35

Slide 35 text

OSとバージョン選定 EC2の作成では、まずOSとバージョンを選択します。

Slide 36

Slide 36 text

OSとバージョン選定 EC2では以下のOS(ディストリビューション)が利用可能です。 ● Amazon Linux ● Amazon Linux 2 (LTS候補版) ● Ubuntu Server ● RedHat Enterprise Linux ● SUSE Linux Enterprise Server ● Windows Server 各種 ● コミュニティAMIには多種多様なディストリが存在する ○ CentOS、FreeBSD、openSUSE、Debian、Gentoo、Fedoraなど

Slide 37

Slide 37 text

OSとバージョン選定どのOSのどのバージョンを利用するかは、目的によって異なると思いますが、特に理由がない限りAmazon Linuxの利用をオススメします。 ● AWS利用における情報量の多さ、AWSのサポート ● AWSが独自にパッチを当てたXenやKVMとの親和性 ● パッケージリポジトリがS3に存在するため超高速インストール ● 通常のRHELやCentOSよりもパッケージが少し新しめ ● aws-ssm-agentなどAWSツールが標準リポジトリからインストール可能なお、公式のAMIではカーネルパラメータやカーネルモジュールなどは汎用的な用途にマッチするように初期設定されています。これらはgrubやmodproveの設定を変更した状態でAMIを作成することにより、ユーザによってチューニング可能です。

Slide 38

Slide 38 text

OSとバージョン選定 RHEL や SUSE 、Windows など有料のOSのライセンスは従量課金の利用料金に含まれています。すでにライセンスを購入済みの場合は購入済みライセンスを適用することで従量課金額を安くすることができます。(BYOL: Bring Your Own License) Windows Server のライセンス形態は複雑すぎてよくわからないので、不安な場合はソリューションアーキテクトの方に相談してください。 ※ただでさえ複雑なWindowsライセンスがAWSの独自エディションでわけわからなくなっています。 Windowsに限らず、BYOL利用の場合はソリューションアーキテクトへの相談は必要になるでしょう。

Slide 39

Slide 39 text

OSとバージョン選定まとめ ● OS選定で最も重要なのは、インストールするパッケージのサポート。 ● 次に重要なのは運用チームの習熟度。 ● 特に理由がない限り、Amazon Linuxを選んでおけばOK。 ● systemdを利用したい場合は RHEL7 か Amazon Linux 2。 ● Windows向けの製品を利用したい場合。Windows向けだけではないけど、 Windowsに最適化された製品も多数存在する。(日立のCosminexusとか) マネジメントコンソールでの作業だとわかりづらいですが、OS選択画面では、裏側で当該OSがプリインストールされたAMIのIDが選択されています。AMIについては後述します。

Slide 40

Slide 40 text

インスタンスタイプ選定 OSを選択したら、次にインスタンスタイプを選択します。

Slide 41

Slide 41 text

インスタンスタイプ選定 EC2には用途に応じてインスタンスタイプという区分が存在します。インスタンスタイプによって搭載される仮想CPUコア数、メモリ量や、ネットワーク帯域、ローカルストレージ容量が変わります。インスタンスタイプは用途を表すアルファベット1文字と世代を表す数字1文字、グレードで表されます。用途と世代を合わせた2文字をインスタンスファミリーと呼称します。インスタンスファミリーは2文字以上のものも存在します。例: m5.4xlarge の場合 ● m => 汎用インスタンスを表す。 ● 5 => 第５世代のインスタンスを表す。 ● 4xlarge => インスタンスファミリーにおけるグレード。 ○ 大きいほど高価で高性能。 4xlargeはxlargeの4倍という意味。

Slide 42

Slide 42 text

インスタンスタイプ選定現行世代には以下のインスタンスファミリーがあります。 ● m4, m5 => 汎用インスタンス ● t2 => CPU利用制限がある廉価な汎用インスタンス ● c4, c5, c5d => CPUコア数が多いコンピューティング最適化インスタンス ● p2, p3, g3 => GPU搭載量が多いGPU最適化インスタンス ● h1, i3, d2 => ストレージ容量が多いストレージ最適化インスタンス ● i3.metal => ベアメタルインスタンス ● f1 => FPGAによる拡張が可能な特殊インスタンス通常のWebシステムでは m5 か t2 を選ぶことになります。価格も m と t 以外は低価格帯での提供タイプがないものが多いです。

Slide 43

Slide 43 text

インスタンスタイプ選定 t2インスタンスは、普段はCPUが従来の20%しか利用できない代わりに時間単価がかなり安いインスタンスタイプです。時間経過とともにクレジット（単位は時間）が溜まっていき、このクレジットを消費することでクレジット分の時間だけバースト（CPU性能を100%利用可能な状態）することができます。また、Unlimitedオプションを有効にすると、クレジットが枯渇しても追加料金を支払うことでバースト時間を増やすことができます。現行世代では低パフォーマンス帯のインスタンスタイプはt2でしか提供されていないので、今後利用する際にはt2ファミリーの利用が増えると思います。

Slide 44

Slide 44 text

インスタンスタイプ選定インスタンスタイプごとに設定されているvCPU数やメモリ容量は理論値です。実際にまったく同じインスタンスタイプのEC2インスタンスでも、パフォーマンスに大きく差が出ることがよくあります。これは、DCに設置されているKVMホストマシンもしくは接続機器の故障や老朽化によって仮想マシンにパフォーマンス劣化の影響が出ているためです。 EC2インスタンスのパフォーマンスにバラツキがあるため、このような事象をEC2ガチャと呼んだりします。なので、低パフォーマンスのEC2を引いたときでも即廃棄できるようにイミュータブルなシステムを構築することはクラウドにおいて必須と言えます。

Slide 45

Slide 45 text

インスタンスタイプ選定一部のインスタンスタイプでは、EC2インスタンスの仮想マシンに物理接続されているローカルストレージであるインスタンスストア（エフェメラルディスク）が付いてきます。このインスタンスストアはEC2終了時にデータが消去されますが、ネットワーク接続されているEBSと比べてI/Oが圧倒的に高速というメリットがあります。なので、ログや中間ファイルなどをインスタンスストアに入出力することでシステム全体のパフォーマンス向上に寄与します。ただし、インスタンスストアは現行世代のインスタンスにはほとんど搭載されていません。つい最近まで m3.medium ですらあったのに、なんで！？

Slide 46

Slide 46 text

インスタンスタイプ選定まとめ ● とにかく低コストにしたいのであれば t2 ● AutoScaling前提のWebシステムであれば汎用の t2 か旧世代の m3 ● 平常時のアクセス量が多い中規模以上のWebシステムであれば m5 ● DBなどディスクI/O性能を求めるならストレージ最適化 ● RedisやMemcachedなどオンメモリDBを利用するならメモリ最適化 ● 機械学習など計算量が多いシステムならGPU最適化 ● VMware on AWS など Hypervisor を利用したい場合は i3.metal ● エムスリーなので m3

Slide 47

Slide 47 text

ネットワークの設定 EC2インスタンスの詳細設定画面です。量が多いのでセクションごとに説明します。まずはネットワーク周りです。VPCとサブネットを選択します。 EC2インスタンスは必ずVPC内のサブネットに属します。（昔はVPC外に作成することができました。）後からVPCやサブネットを変更することはできません。変更したい場合はスナップショットを作成して起動しなおします。踏み台インスタンスでは、EIPをアサインしてIPを固定にするため自動割り当てのパブリックIPは利用しません。

Slide 48

Slide 48 text

スポットインスタンススポットインスタンスは、入札により課金額が決定するインスタンスです。通常のオンデマンドインスタンスより最大9割くらい安く稼働させることができますが、入札額が相場を下回ると自動的に停止します。ステートレスな処理を大量に行うバッチ処理などで有効です。Webシステムではスパイクアクセスなどによりトラフィックが急増した際に利用したりします。また、AWS BatchやEMRなど一部のサービスではスポットインスタンスを利用する機能が備わっているものもあります。

Slide 49

Slide 49 text

プレイスメントグループ AZ内のEC2インスタンス間通信は十分に高速ですが、プレイスメントグループを作成するとさらに高速な通信が可能になります。プレイスメントグループは、ネットワーク的に近いHW上にインスタンスを構築することで、通信のレイテンシを最小限におさえることが可能です。ただし、「ネットワーク的に近い = 物理的な距離が近い」なので、災害などによりまとめて死ぬことがありえます。一般的なWebシステムでは、インスタンス間の通信は不要なことが多いため、プレイスメントグループを利用することは少ないと思います。分散バッチなどでの利用がメインとなるでしょう。他には、インスタンス間通信を前提としたErlang/OTPや、トライアド構成のシステムなどでも有用かもしれません。

Slide 50

Slide 50 text

ネットワーク以外の設定です。IAMロールは後述します。モニタリングやテナンシーは今回は割愛します。その他の設定 EC2インスタンスに紐付けるIAMロールを選択します。IAMロールはインスタンスプロファイルを持っている必要があります。

Slide 51

Slide 51 text

IAMロール (インスタンスプロファイル) EC2にはIAMロールを紐付けることができます。 IAMロールがアタッチされたEC2インスタンスからは、各AWSサービスに対してアクセスキーなしでAPI実行が可能なため、セキュアにAWSのAPIを利用可能です。 EC2からAWSのサービスを利用する場合は、必ずIAMロールを設定するようにしてください。間違ってもIAMユーザーを作成して、アクセスキーをEC2上に格納しないように気をつけてください。

Slide 52

Slide 52 text

UserData (プロビジョニングスクリプト) EC2では初回起動時に行うプロビジョニングの処理を設定することができます。これを UserDataと言います。 Linuxであればshebangで実装言語を指定可能です。#cloud-config をshebangに指定した場合は、YAMLで記述可能なCloud-Initの仕様を利用可能です。

Slide 53

Slide 53 text

UserData (プロビジョニングスクリプト) BashでUserDataを記載する例を見てみます。以下の例では、sshdのListenポートを変更しています。 ※前職でよく使っていました。その時は443に変更してました。

Slide 54

Slide 54 text

UserData (プロビジョニングスクリプト) Cloud-InitはクラウドサーバをプロビジョニングするためのDSL仕様で、ansibleみたいに宣言的にサーバの状態を記述できるため非常に便利です。以下のリンクに様々なユースケースでのサンプルコードが載っています。 http://cloudinit.readthedocs.io/en/latest/ 初回起動時以外のイベント処理も記載可能で、冪等性も担保されます。なお、ECSではクラスタインスタンスの利用でUserDataを必ず利用します。Elastic BeanstalkではUserDataの代わりにインスタンスを初期化する手段があります。

Slide 55

Slide 55 text

EC2のストレージ (EBS)

Slide 56

Slide 56 text

EC2のストレージ (EBS) EBSは仮想ブロックストレージです。仮想ハードディスクと思っておけば大体あってます。EC2のOSイメージや、アプリケーションバイナリ、ログファイルなどのファイルを格納するための永続化ストレージです。 EC2そのものは永続ストレージを持っていません。EC2起動時にOS起動イメージが格納されたEBSが複製・アタッチされ、アタッチされたEBSがマウントされた状態で起動します。ファイルシステムはAmazon LinuxデフォルトだとXFSです。また、EBSはEC2上で動作する他のサービスでも利用されます。代表的なもので、RDS やElasticsearchがあります。これらのサービスはEBS上にデータを永続化しています。ちなみに、API上ではEBSはVolumeというエンティティ名です。忘れやすいので注意。

Slide 57

Slide 57 text

EC2のストレージ (EBS) EBSは最低で100 IOPSのベースライン性能が出ます(gp2の場合)。また、IOクレジットがあり、クレジットが枯渇しない限り最大3000 IOPSまでバースト可能です。プロビジョンドIOPSストレージ(io1)の場合、IOPSを最大で60000まで指定することが可能です。 EBSには gp2, st1, sc1 など種別があり、ランダムアクセスが得意、シーケンシャルアクセスが得意、スループットが安定しているなどの特性があります。通常のWeb利用ではストレージ速度を気にすることはあまりないので、汎用ボリュームのgp2を選択することが多いです。

Slide 58

Slide 58 text

EC2のストレージ (EBS) EBSはスナップショット機能があります。オンラインで取得可能なのでデータの信頼性が重要なシステムでは重宝します。ただ、リストアにそれなりに時間がかかるので、RTT（目標復旧時間）の指標が厳しいミッションクリティカルなシステムではEBSのスナップショットとは別に、OS内でファイルシステムのスナップショット(LVMスナップショットやxfs_dumpなど)を取得することもよくあります。前職では2台のEC2でDRBDを組んだりしてました。 RDSの自動バックアップ機能はEBSのスナップショットにより実現されています。スナップショットされたイメージはS3に格納されます。なお、S3のコンソールからスナップショットを確認することはできません。

Slide 59

Slide 59 text

タグの設定 EC2においてタグは比較的重要です。Systems Managerによるパッチ適用やパッケージインストールなどを行うにあたり、タグを利用するためです。サーバーロールや環境名、サービス名などを入れておきましょう。

Slide 60

Slide 60 text

セキュリティグループの設定セキュリティグループについては後述します。ここでは社内からのSSHを許可しています。

Slide 61

Slide 61 text

キーペアの選択

Slide 62

Slide 62 text

以上で踏み台インスタンスの構築は完了です。

Slide 63

Slide 63 text

セキュリティグループセキュリティグループは文字通り、通信を許可するリソースをグルーピングするための機能です。通信の受信（Ingress）と送信（Egress）を、ホワイトリストとブラックリストにより認可します。設定可能な代表的なパターンは以下の通りです。 ● 特定のセキュリティグループからのアクセスに対する認可 ● セキュリティグループ内のアクセスに対する認可 ● 特定のIPアドレス(CIDR)からのアクセスに対する認可 ● 特定のIPアドレス(CIDR)へのアクセスに対する認可 ● VPCエンドポイントへのアクセスに対する認可（今回は割愛）

Slide 64

Slide 64 text

セキュリティグループ特定のセキュリティグループからのアクセスに対する認可 VPC内のリソースからのアクセスを制御するパターンで、頻出パターンです。EC2に対するELBからのアクセス、RDSに対するEC2のアクセスなど、AWSリソース間でのアクセス制御に利用します。非常にシンプルですが、設計を誤ると相互参照が発生します。相互参照は作成する分にはエラーにはなりませんが、削除しようとするとエラーになるため、terraformなどで厄介です。

Slide 65

Slide 65 text

セキュリティグループセキュリティグループ内のアクセスに対する認可同一セキュリティグループ内の通信を許可するパターンです。RDSやElastiCacheのセキュリティグループとして利用することが多いです。複数のセキュリティグループをオーバーラップさせる前提となります。相互参照しづらくなるためterraformなどとの相性がいいですが、人間にはわかりづらいというデメリットがあります。

Slide 66

Slide 66 text

セキュリティグループ特定のIPアドレス(CIDR)からのアクセスに対する認可踏み台インスタンスへのSSH接続、テスト環境へのWebアクセスなど、VPCの外にある拠点からのアクセスを制限する場合に利用します。これには、VPN接続で接続されている別のVPCや、Direct Connect経由で接続されているオンプレからのアクセスも含まれます。

Slide 67

Slide 67 text

セキュリティグループ特定のIPアドレス(CIDR)へのアクセスに対する認可特定のIPアドレスへの通信のみを許可し、外部へのアクセスを制限するパターンです。マルウェアや内部犯行対策として設定することがほとんどです。

Slide 68

Slide 68 text

ネットワークACL IPアドレスに対する制限は（説明していませんが）ネットワークレイヤであるサブネットの ACLでも可能です。より堅牢にするのであれば、サブネットのACLとセキュリティグループを併用して同じ制限をかけます。こうすることによって、誤ってどちらかの制限を解除してしまった場合でも救済することができます。当然、管理は煩雑になるのでterraformなどで管理したほうがいいでしょう。

Slide 69

Slide 69 text

第3章 AutoScaling / ELB

Slide 70

Slide 70 text

AutoScaling AutoScalingは、最小インスタンス数と最大インスタンス数を指定して、スケーリングポリシーに応じてスケールアウト・スケールインを行う仕組みの総称です。AWSに限った用語ではありません。 AWSでは、ロードバランサーから接続するWebサーバを負荷分散するために利用するのが主な用途です。なお、ロードバランサーは必須ではなく、バッチ処理を複数サーバで分散処理する場合にも利用されます。 AutoScalingの機能自体はロードバランサーに依存していないため、多くのユースケースで利用が可能です。

Slide 71

Slide 71 text

Amazon Machine Image (AMI) AutoScalingを説明する上で、AMIの説明は避けて通れないのでAMIを紹介します。 AMIとは、EC2起動前のVMイメージです。より具体的にはEC2のメタデータ（OSやデバイスマッピング情報など）と、OS起動イメージやファイルなどが格納されているEBSを圧縮したアーカイブファイルです。 AWSから提供されているAMIでEC2を起動し、起動したEC2にミドルウェアやアプリケーションをインストールして、AMIを作成することができます。 EC2は必ずこのAMIから起動されます（起動時にAMIのIDを指定します）。

Slide 72

Slide 72 text

Amazon Machine Image (AMI) AutoScalingでは、スケールアウトさせる際に、どのAMIを利用してEC2を起動するかを予め定義しておく必要があります。 AWS提供のデフォルトAMIから起動してUserDataでもろもろ初期化してもAutoScaling は可能ですが、パッケージインストールしてアプリケーションを展開して設定ファイルを生成してなどをUserDataで行うと、スケールアウトまでの時間が非常に長くなってしまいます。そのため、通常はアプリケーションなどをインストール済みの状態でAMIを作成しておき、AutoScalingの起動設定でそのAMIを指定することで起動時間を短縮することができます。

Slide 73

Slide 73 text

Amazon Machine Image (AMI) 起動設定に利用するAMIの戦略として、代表的なパターンとして以下があります。 ● 必要なミドルウェアのみインストールされた状態のAMI ● アプリケーションまでインストールされた状態のAMI ● アプリケーションの設定や環境変数まで格納されたAMI 下に行くほど起動は高速になりますが、設定や環境変数まで格納したAMIを作成すると、開発環境用AMI、本番用AMIなど非常に多くのAMIがバージョンごとに存在することになり、コストも増大します。そのため、よく利用されるパターンとしては２番めの戦略となります。その場合、アプリケーションの設定や環境変数は起動スクリプトなどで取得します。

Slide 74

Slide 74 text

Amazon Machine Image (AMI) アプリケーションまで含めたAMIはCI/CD対象です。アプリケーションに変更を加え、Gitにプッシュしたら新しいバージョンのAMIを作成するためのジョブを起動し、最新のAMIが即時利用可能な状態にしておくのが望ましいです。（古いバージョンの削除も行います）起動AMIをCI/CDするための仕組みはAWSでは多数用意されています。 ● CodePipeline + CodeBuild + Packer ● Systems Manager の Automation ● Elastic Beanstalk の Custom Platform Builder これらを説明している時間はないので、起動AMIは作成済みという前提で先に進みます。(※Nginxインストール済みAMIの作成は資料末尾のAppendix参照）

Slide 75

Slide 75 text

AutoScalingの起動設定 (非推奨） AutoScalingを設定するためには、スケールアウト時にどのAMIを起動するかを予め設定しておく必要があります。この設定をLaunchConfiguration(起動設定)といいます。 LaunchConfigurationの内容は、EC2の起動で入力したパラメータとほぼ同じです。なお、LaunchConfiguration は現在非推奨となっています。起動テンプレートを利用することが推奨されているため、今回は起動設定の説明を割愛します。起動テンプレートはローンチされたばかりの新しい機能です。そのため、Webで検索するとほとんどは起動設定がヒットします。注意してください。

Slide 76

Slide 76 text

Launch Template LaunchConfigurationはAutoScalingでしか利用できませんが、Launch Templateは通常のEC2起動に利用可能です。また、起動テンプレートはバージョン管理されます。以下は起動テンプレート作成画面です。

Slide 77

Slide 77 text

Launch Template 起動テンプレートで起動するAMIのIDとインスタンスタイプ、キーペア名を指定します。ネットワークタイプは必ずVPCを選択してください。Classicを使うことは将来的に見てもありません。 AutoScalingに利用する場合は、アプリケーションなどがインストールされたAMIのIDを指定します。起動したEC2にSSHログインする必要がない場合は空にします。 ssm-agentを利用する前提であればSSHログインは不要です。

Slide 78

Slide 78 text

ネットワークインターフェイス、ストレージは空のままにします。 Launch Template AutoScalingで利用する場合は、AutoScalingGroupの設定でネットワークを設定するため不要です。ルートボリュームはAMIに含まれています。ルートボリューム以外をアタッチする必要がある場合のみ指定します。

Slide 79

Slide 79 text

タグを指定します。このタグはAutoScalingで起動されたすべてのインスタンスに設定されます。これらとは別に、AutoScalingGroupのIDなどメタ情報のタグも設定されます。 Launch Template

Slide 80

Slide 80 text

セキュリティグループを指定します。起動されたすべてのEC2インスタンスがここで設定したセキュリティグループに所属します。 Launch Template まだELBを作成していないので、とりあえず同一セキュリティグループからのHTTPアクセスを許可しておきます。

Slide 81

Slide 81 text

その他の詳細設定です。EC2起動時に設定した内容と似ていますが、ElasticGPUなどの項目が追加されています。特定のAMIでのみ有効な項目もあります。 RAMディスクIDとカーネルIDはほぼ利用することはないでしょう。重要なパラメータとしてモニタリングがあります。次のスライドで説明します。 Launch Template

Slide 82

Slide 82 text

モニタリングは重要なポイントなので補足します。詳細モニタリングを有効にしなかった場合、スケーリングの判断に必要なCloudWatchのメトリクスは最小でも5分間隔でしか取得されません。これはつまり、閾値を超えてスケールアウトが必要になるまでに最大で10分かかることを意味します。そこからEC2が起動して準備完了になるまでさらに数分かかるため、スケールアウトが完了するまでの時間は12〜15分くらいかかることになります。迅速なスケールアウトが必要なシステムでは必ず詳細モニタリングを有効にしてください。（ただし、詳細モニタリングはコストが上がります） Launch Template

Slide 83

Slide 83 text

AutoScalingGroupの作成起動テンプレートができたら、AutoScalingGroupを作成します。作成した起動テンプレートを選択します。起動テンプレート画面から AutoScalingGroupの作成を実行した場合はこの画面はスキップされます。

Slide 84

Slide 84 text

起動するテンプレートのバージョンとグループ名を指定します。 AutoScalingGroupの作成「バージョンID」もしくは「最新」を選択可能です。起動テンプレートもCI/CDを行うのであれば、「最新」を選択してはいけません。新しいインスタンスが勝手に最新バージョンの AMIで起動されてしまいます。

Slide 85

Slide 85 text

作成直後のインスタンス数と、起動対象となるVPCおよびサブネットを指定します。 AutoScalingGroupの作成複数のサブネットを指定することでMulti-AZ構成となります。ここではプライベートサブネットのゾーンAとゾーンCで起動するように指定しています。

Slide 86

Slide 86 text

なお、AutoScalingGroupの画面から直接ELBを指定することも可能ですが、今回は先にAutoScalingGroupを作成するため、ここでは行いません。 AutoScalingGroupの作成

Slide 87

Slide 87 text

AutoScalingGroupの作成 AutoScalingで最も重要なパラメータである、スケーリングポリシーを設定します。最小サイズ、最大サイズ、メトリクス、閾値などを指定します。ここではCPU利用率以外には、ネットワークOut、ネットワークIn、リクエスト数が選択可能です。他のメトリクスを利用する場合はCLIなどから設定します。AutoScalingGroup については、マネジメントコンソールで可能な操作が極端に制限されています。以前よりも設定項目が減っています。

Slide 88

Slide 88 text

AutoScalingGroupの作成スケーリングポリシーに関しては、AWSのキモと言ってもいい設定です。そのため、設定内容は非常に細かく、マネジメントコンソールで設定しようとするとUIが非常に煩雑になるため、あえてシンプルな設定しかできないようにデグレードしたものと思われます。シンプルなスケーリングポリシーを利用する場合は問題ありませんが、カスタムメトリクスの利用や、細かい制御を行いたい場合はCLIやterraformでの設定が必須となります。そもそもスケーリングポリシーに関しては運用中に頻繁に見直すべき内容ですので、最初はシンプルなもので設定しておくというのは理にかなっているのかもしれません。

Slide 89

Slide 89 text

AutoScalingGroupの作成ライフサイクルイベント発生時の通知先を指定可能です。画面ではメールアドレスを指定していますが、SNSトピックであれば何でもいいので、ライフサイクルイベント発生時にフック処理を行う場合はSNS経由でLambdaを呼び出します。

Slide 90

Slide 90 text

AutoScalingGroupの作成最後にタグを設定して作成完了です。

Slide 91

Slide 91 text

ELB(ロードバランサー)の作成 AWSのロードバランサーは以下の３種類が存在します。 ● Application Load Balancer (ALB) ● Network Loadbalancer (NLB) ● Classic Load Balancer (CLB) 通常のWebシステムではALBを利用しますが、他の2つについても非常に重要なのでそれぞれの特徴について説明します。

Slide 92

Slide 92 text

ELB (Elastic Load Balancer) 各ELBを説明する前に、ELB全体についての説明をします。 ELBは負荷量に応じて自動でスケールアウトするロードバランサーのEC2インスタンスです。スケールアウトは全自動で行われ、利用者が制御することはほぼできないので、いつの間にか台数が増えたり減ったりしています。スケールアウトした場合は当然IPアドレスが消費されるので、ELBを使うサブネットではスケールアウト分のIPアドレス余剰がなければいけません。（IPアドレスが足りないとスケールアウトが失敗しますが、ELB自体が無効になったりはしません）また、キャンペーンや〇〇砲など、負荷増大が事前にわかっている場合は、ウォームアップ申請を行ってスケールアウトを高速化することが可能です。

Slide 93

Slide 93 text

ELB (Elastic Load Balancer) ELBは通常のロードバランサーでよく見かける以下の機能があります。 ● CookieによるSession Persistence ● ヘルスチェック（ロードバランサーだから当たり前） ● Connection Draining （切り離しても一定時間トラフィックを保持） ● X-Forwarded-XXX ヘッダ（リバースプロキシのためのヘッダ）また、AWS特有の機能として以下があります。 ● S3へのアクセスログ配信 ● AWS WAF統合（ALBのみ） ● リクエスト追跡のためのヘッダ（X-AMZN-TRACE-ID）これらの機能については今回は説明しません。

Slide 94

Slide 94 text

Application Load Balancer HTTPに特化したL7ロードバランサーです。ホスト名もしくはパスに応じて振り分け先のインスタンス（またはAutoScalingGroup）を動的に決定します。 ALBでは、HTTPもしくはHTTPSプロトコルのリスナーを追加して、プロトコルを有効にします。HTTPリスナーが追加されていればHTTPが、HTTPSリスナーが追加されていればHTTPSが有効になります。 HTTPリスナーでは受信ポートを指定できます。HTTPSリスナーでは受信ポートに加え、TLSの証明書を指定できます。TLSの証明書はACM(Amazon Certificate Manager)に登録されている必要があります。通常のWebシステムであればこのALBを利用します。構築方法については後述します。

Slide 95

Slide 95 text

Network Load Balancer TCPのL4ロードバランサーです。ALBと違うのは、負荷分散対象がEC2インスタンス以外に、静的なIPアドレスを対象にできるということです。 IPアドレスが疎通していればどんな対象にでもトラフィック可能なため、EC2インスタンスに限らず、オンプレのサーバや他のAWSサービスに対しても負荷分散が可能です。 2018年6月現在ではTLS終端の機能は持っていないため、TLS終端処理はターゲット側で行う必要があります。主な用途としては、オンプレとの負荷分散、VPCエンドポイントの負荷分散、および gRPCなどHTTP/2の負荷分散です。（ALBではHTTP/2の負荷分散はできません）

Slide 96

Slide 96 text

Classic Load Balancer TCPのL4ロードバランサーです。ALBと違い、ホスト名やパスでのルーティングはできません。対象はEC2インスタンスもしくはAutoScalingGroupとなります。 NLBと違い、TLS終端機能を持ちます。そのため、現状ではインターネットからgRPCを利用する場合はほぼCLB一択となります。(VPC内であればNLBでいいと思います。) Classicと名前が付いていますが、NLBがTLS終端機能を持っていないため、HTTP以外の負荷分散ではバリバリの現役選手です。 TLS終端で利用する証明書はACM(またはIAM Server Certification)に登録されている必要があります。IAM Server CertificationはACMが出る前の旧機能。

Slide 97

Slide 97 text

ALBの作成作成済みのAutoScalingGroupに対して負荷分散を行うALBを構築します。

Slide 98

Slide 98 text

ALBの作成今回はHTTPSは使わずにHTTPのみです。

Slide 99

Slide 99 text

ALBの作成 ELBのサブネットを指定します。インターネット向けのELBはパブリックサブネットに構築しなければなりません。また、ELBは可用性のためMulti-AZで負荷分散することがほとんどです。

Slide 100

Slide 100 text

ALBの作成セキュリティグループを設定します。インターネット向けなのでHTTPを全公開しています。スクリーンショットのために 0.0.0.0/0 を指定していますが、評価目的などではオフィスのグローバルIPからのみアクセスを許可してください。

Slide 101

Slide 101 text

ALBの作成続いて、ALBの設定のキモであるターゲットグループを作成します。ここではデフォルト（すべてのパス）のターゲットグループを作成します。ターゲットへの通信はHTTP/1.1です。HTTP/2に対応していません。そのため、gRPCなどHTTP/2が必須の場合にALBが利用できません。

Slide 102

Slide 102 text

ALBの作成ターゲットグループごとにヘルスチェックの指定ができます。成功コードは複数指定やレンジ指定が可能です。

Slide 103

Slide 103 text

ALBの作成ターゲットのインスタンスを登録しますが、AutoScalingGroupを利用する場合はここでインスタンスを登録してはいけません。AutoScalingGroup側から追加します。ここで登録してしまうとインスタンスが固定のためスケールアウトで追加されたインスタンスにトラフィックが到達しません。

Slide 104

Slide 104 text

ALBの作成 ALBの作成が完了したら、ルールを確認します。

Slide 105

Slide 105 text

ALBの作成マネジメントコンソールから作成した場合、デフォルトのルールのみが存在します。これは、すべてのHTTPトラフィックをターゲットグループ edu-201806 にルーティングするルールを表しています。

Slide 106

Slide 106 text

AutoScalingGroupをALBに登録 AutoScalingGroupをALBのターゲットグループとして登録します。先ほど作成した AutoScalingGroupの設定画面で、ALBのターゲットグループを入力して設定を保存します。

Slide 107

Slide 107 text

AutoScalingGroupをALBに登録すると、自動的にターゲットグループのターゲットにAutoScalingGroup配下のインスタンスが登録されます。

Slide 108

Slide 108 text

セキュリティグループの設定最初にAutoScalingGroupを作成してからALBを作成したため、ALBからEC2への通信が許可されていません。そのためヘルスチェックに失敗します。 ALBからEC2への通信を許可するには2通りのやり方があります。 ● ALBをEC2のセキュリティグループに参加させる。 ● ALBのセキュリティグループからのアクセスをEC2のセキュリティグループで許可する。

Slide 109

Slide 109 text

セキュリティグループの設定 ALBをEC2のセキュリティグループに参加させる場合ロードバランサーメニューで当該ALBを選択してセキュリティグループの編集を行います。

Slide 110

Slide 110 text

ALBからのアクセスをEC2のセキュリティグループで許可する場合 EC2の起動テンプレートで設定したセキュリティグループに対してALBのセキュリティグループからのアクセスを許可します。セキュリティグループの設定

Slide 111

Slide 111 text

セキュリティグループの設定どちらの手段で設定したとしても、ターゲットの状態がHealthyになりました。

Slide 112

Slide 112 text

ブラウザでの確認 ALBのDNS名を確認して、ブラウザでアクセスします。

Slide 113

Slide 113 text

ブラウザでの確認起動テンプレートで指定したNginxインストール済みのEC2インスタンスに接続されることが確認できました。

Slide 114

Slide 114 text

作成したリソースの削除 ● NATゲートウェイの削除（時間がかかるので最初に行う） ● AutoScalingGroupの削除 ○ これをやらないとインスタンス削除しても復活してしまう ● SNSトピックの削除 (AutoScalingGroup消しても消えない) ● ロードバランサーの削除 ● ターゲットグループの削除（ALB消しても消えない） ● インスタンスの削除、AMIの削除 ● ALBセキュリティグループの削除 ● VPCの削除

Slide 115

Slide 115 text

まとめ今回説明した内容はAWSの基礎中の基礎となるサービスの、ごく一部の機能だけです。膨大なスライドの量にもかかわらず、実際に作業してみると１時間もかかりません。なので、取っ掛かりを得たら実際に手を動かして構築してみましょう。ところどころ書きましたが、AWSをちゃんと使うためにはマネジメントコンソールでは限界があります。 CLIやterraform、CloudFormationの使い方を理解してチャレンジしましょう。

Slide 116

Slide 116 text

Appendix Nginx入りのAMI作成手順は以下のとおりです。 1. パブリックサブネットにAmazon LinuxのEC2を作成。キーペアを指定。 2. EC2にEIPをアタッチしてSSHで対象EIP宛にec2-userでログイン。 3. yumでnginxをインストール。chkconfig nginx onしてSSHを終了。 4. 起動中のEC2からイメージを作成。イメージが作成できたらEC2を削除。