AWSの基本的な使い方

Transcript

1. AWSの基本的な使い方 M3 社内研修用 エンジニアリンググループ 園田
2. はじめに スライドに利用しているマネジメントコンソールのスクリーンショットは2018/06時点のも のとなります。 AWSの情報探索時の心構えとして、マネジメントコンソールは頻繁にUIが変わるので、 スクリーンショットをあてにしないようにしましょう。（リソースのモデルを把握しましょうw） 今回のスライドはかなり初心者向けの内容となっているため、ざっと資料を先読みして 自分にとって不要だなと判断したら時間がもったいないので読み飛ばしていただいて結 構です。
3. はじめに アンケートなどでM3でのユースケースがあるとわかりやすいという意見がありますが （実際私もその方がわかりやすいと思いますが）、M3のユースケースを私自身すべては 把握しておらず、また使い方も千差万別のため「コレ」というものがありません。 前回講義でも触れましたが、AWSは非常に膨大な機能仕様があり、それらの組み合わ せはほぼ無限に存在するため、この短い時間では代表的なユースケースですら解説す るのは困難です。使い方の説明をメインにしているため、料金体系などの説明もあまり 出てきません。 今回の講義はどんなユースケースにおいても必要になるサービスや概念の説明がメイ ンとなっています。
4. アジェンダ • 第1章 VPC ◦ サブネット ◦ NATゲートウェイ • 第2章 EC2 / EBS ◦ EBS ◦ インスタンスプロファイル (IAMロール) ◦ UserData ◦ セキュリティグループ • 第3章 AutoScaling / ELB ◦ AMI ◦ Launch Template ◦ AutoScalingGroup ◦ ELB
5. 一般的なWebシステムにおけるAWS環境の構築手順 通常のWebシステムの場合、構築手順はおおまかに以下のような流れになります。 1. ネットワークリソースの構築（VPC, サブネットなど） 2. サーバリソースの構築（EC2、RDS、セキュリティグループなど） 3. 負荷分散環境の構築（ELB、AutoScalingGroupなど） 4. BCP(国外リージョンによるDR)環境の構築（今回は触れません） 以降のスライドでは、それぞれの構築フェーズで行う作業と、考慮すべきポイントを解説 します。
6. 構築環境のイメージ 時間の都合上、今回はRDS構築の説 明はしません。
7. 第1章 VPC
8. ネットワークリソースの構築 VPCによるネットワークリソースの構築を行います。VPCはほとんどのユースケースで 必要になる可能性が高いです。AWS利用の前提知識といえます。 VPCを構築する上で考慮しなければならない事項は以下の通りです。 • 他のVPCや別アカウントのVPCと接続する必要があるかどうか。 • 必要なIPアドレスの個数。（1VPCあたり上限65,536 - α） • IPv6でのアクセスが必要かどうか。（通常は不要） • VPC内のインスタンスからインターネットを参照可能とするかどうか。（通常は必要） 特に上２つは後からの変更が非常に困難なため、初期構築時に必ず検討する必要があ ります。
9. ネットワークリソースの構築（注意事項） 他のVPCや別アカウントのVPCと接続する必要があるかどうか。 VPCは構築時にCIDRを指定しますが、後から変更はできません。 他のVPCや別アカウントのVPCとVPCピアリング（VPC間接続）する際に、プライベート ネットワークのアドレスが被っていた場合、接続できません。 そのため、接続先のVPCとネットワークアドレスが被らないようにCIDRを指定する必要 があります。 VPCエンドポイント + NLBという手段で接続できなくもないですが、構成が複雑になるた めオススメしません。これは最終手段です。 https://dev.classmethod.jp/cloud/aws/try-aws-privatelink_1/
10. ネットワークリソースの構築（注意事項） 必要なIPアドレスの個数。（1VPCあたり上限65,536 - α） VPCのIPレンジ（ネットマスク）は最小で16ビットです。65536個のIPアドレスを発行可能 ですが、AWSの内部リソースに消費される予約分や、ELBなど動的に増減するIPアドレ スを考慮に含めてIPアドレスの個数を検討します。 通常のWebシステムでIPアドレスが枯渇することはまずありませんが、VPC内で Lambdaを大量に実行する場合や、EMRなどで大量のスポットインスタンスを立ち上げ る場合はIPアドレスの枯渇を意識する必要があります。 もし60000を超えそうな場合はVPCを分割しても問題ないアーキテクチャで実装する必 要があります。
11. ネットワークリソースの構築（注意事項） VPC内のインスタンスからインターネットを参照可能とするかどうか VPC内のインスタンスは踏み台インスタンスを除き、インターネットから接続不可能なプ ライベートサブネットに構築するのが一般的です。ただし、インターネットへのアクセスは 必要になるケースは多いです。 • bundle installなど、パッケージのダウンロード • sentryやdockerhubなど外部サイトへのアクセス 最初からこれらを考慮したクラウドネイティブなシステムを除き、ほとんどのケースでは 外部サイトへのアクセスが必要となります。 インターネットへのアクセスが必要な場合、通常はNATゲートウェイをVPCに構築しま す。(NATインスタンスやForward Proxyという手段もあります )
12. ネットワークリソースの構築（詳細手順） 新規ネットワークを構築するには以下の手順で行います。 1. VPCの作成 2. インターネットゲートウェイの作成 3. パブリック用のサブネットの作成 4. パブリックサブネットの設定 5. プライベート用のサブネットの作成 6. NATゲートウェイの作成 7. VPCエンドポイントの作成（作成は任意、今回は割愛） 8. プライベートサブネットの設定 この順序は、マネジメントコンソールでの作業順序となります。ややこしいのですが、マネジメントコン ソールで作成する場合と、Terraformなどで作成する場合で作業順序が異なることが多々あります。
13. VPCの作成 VPCの作成に必要なパラメータは名前とCIDRの2つです。 VPCの名前です。Nameタグに設定されます。他の人が見てもわかり やすい名前をつけましょう。my-vpcとかは言語道断。 VPCのIPアドレス範囲です。他のVPCと同じでもエラーになりません が、VPC間でのネットワーク接続が必要な場合は考慮が必要です。特 に理由がない限り16ビットで切るのが一般的です。 これらのパラメータは通常のケースではデフォルトで問題ないです。 IPv6でのアクセスが絶対に必要な場合はまずないでしょう。
14. VPCの作成 VPCを作成すると、以下のリソースがデフォルト生成されます。 • デフォルトのセキュリティグループ • デフォルトのルートテーブル（メインルートテーブル） これらのデフォルトで生成されたリソースは、VPCが存在する限り破棄できないため、 TerraformなどInfrastructure as Codeで管理する場合は基本的に利用しないほうがい いです。 VPCに限らず、デフォルト生成されたリソースは基本的に無視したほうがTerraformなど で管理しやすいです。自動生成されるリソースは、他にはDHCPオプションやRDSパラ メータグループなどがあります。
15. インターネットゲートウェイの作成 VPCとインターネットを接続するための仮想ルータである、インターネットゲートウェイ (IGW)を作成します。 インターネットからの接続が不要でも、NATゲートウェイ経由でインターネットへ接続する 際に必要になるため、作成するケースがほとんどです。踏み台インスタンスにも必須で す。
16. インターネットゲートウェイの作成 作成したIGWをVPCにアタッチします。IGWをアタッチしない限り、VPCとインターネット は相互通信不能です。(セキュリティインシデント発生時など、IGWをデタッチすることが あります)
17. パブリック用のサブネットの作成 AWSにおいてAZで分割された仮想ネットワークをサブネットと呼びます。 インターネットから直接通信可能なサブネットをAWS用語でパブリックサブネットといい ます。パブリックサブネットを構築するためには、まずパブリックサブネット用のサブネット を作成します。 ややこしいのですが、パブリックサブネットというリソースは存在しません。作成されたサ ブネットに対してIGWをルーティングすることで、そのサブネットはパブリックサブネットと なります。 パブリックサブネットには、踏み台インスタンス、および外部からHTTP(S)でアクセスする ためのELBを含めることになります。ELBをマルチAZで構築するためには、パブリックサ ブネットを複数のAZに作成する必要があります。
18. パブリック用のサブネットの作成 サブネットの名前です。Nameタグに設定されます。SuffixにAZをつけ るのが慣例です。 AZを選択します。マルチAZにする場合はサブネットを複数作成しま す。サブネットのAZを後から変更することはできません。 サブネットのIPレンジをCIDRで指定します。通常、プライベートサブ ネットよりもIPアドレスの個数は少なくすみますが、わかりやすくするた め/24にすることが多いです。
19. パブリックサブネットの設定 パブリックサブネット用に作成したサブネットに割り当てるルートテーブルを作成します。
20. 作成したルートテーブルに 0.0.0.0/0 宛（ローカルネットワーク以外のすべての通信）の パケットをVPCにアタッチしたIGWにルーティングさせるように設定します。（ルートテー ブルは上から評価されます） パブリックサブネットの設定 VPC内のIPアドレスはすべてローカルネットワーク内の通信として扱われ、変更はでき ません。そのため、他のVPCと通信する場合はIPアドレスの範囲がかぶらないようにし なければなりません。
21. この設定が完了した時点で、関連づけたサブネットは便宜上、パブリックサブネットと呼 ばれるようになります。 パブリックサブネットの設定 作成したルートテーブルとパブリックサブネット用に作成したサブネットを関連付けます。 ELBなどをマルチAZ構成にする場合はAZの異なる複数のサブネットを関連付けます。 明示的に関連付けを行う前は、VPC作成時に自動生成されたデフォルトのルー トテーブル（メインルートテーブル）と関連付けられています。
22. プライベート用のサブネットの作成 パブリック用のサブネットを作成した際と同様に、プライベート用のサブネットを作成しま す。マルチAZが必須なケースがほとんどなので、複数AZで作成します。VPC内で大量 のリソースを作成する場合はCIDRを大きめに切ります。 当然ですが、パブリックサブネットと同じAZを選択したほうが通信のレイテ ンシが少ないため、特に理由がない限りパブリックサブネットと同じAZを選 択します。
23. NATゲートウェイの作成 プライベートサブネット内のインスタンスがインターネットに接続可能なようにNATゲート ウェイを作成します。 NATゲートウェイと関連付けるサブネットを選択します。ここで選択する サブネットはIGWと通信可能でなくてはなりません。つまり、先に作成し たパブリックサブネットを選択する必要があります。
24. プライベートサブネットの設定 プライベートサブネット用のルートテーブルを作成します。
25. プライベートサブネットの設定 作成したルートテーブルに、インターネット向けパケットをNATゲートウェイに送信するよ うにルーティング設定を行います。
26. プライベートサブネットの設定 プライベートサブネット用に作成したサブネットを、ルートテーブルに関連付けます。これ で、プライベートサブネット内に構築されるインスタンスがインターネットに対してパケット を送信可能になります。 このキャプチャは保存前の状態です。
27. 補足: NATゲートウェイの冗長化 ここまでの手順で、以下のリソースが作成されています。 • VPC • インターネットゲートウェイ • パブリックサブネット * AZ • プライベートサブネット * AZ • NATゲートウェイ • ルートテーブル * 2 (パブリック用、プライベート用) このままでもシステム運用可能ですが、NATゲートウェイがシングルAZになっているた め、インターネット通信を頻繁に行うシステム（電子決済や外部認証など）では可用性が 問題になります。
28. 補足: 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/月
29. 補足: NATゲートウェイが不要なケース 以下に該当する場合はNATゲートウェイが不要な可能性があります。 • インターネット通信量や通信頻度が少ない場合 ◦ NATゲートウェイではなく、 NATインスタンスを構築する。 ◦ インターネット通信が必要な場合（デプロイ時や AMI作成時など）のみNATゲートウェイを構築して ルーティングする。（この操作は Lambdaなどで実装する） • 出口対策などでフォワードプロキシを構築する（もしくは構築済みの）場合 ◦ インターネット向けの通信をプロキシサーバを経由するようにルーティングする。 • 通信対象がAWSのサービスのみの場合 ◦ S3やCloudWatch LogsなどVPCエンドポイントがサポートされているサービスでは VPCエンドポイ ントを利用する。 ◦ Amazon LinuxのyumリポジトリはS3なので、標準リポジトリのみ利用の場合は VPCエンドポイント で代替可能。 • 接続先サイトに対してIPv6で接続可能な場合 ◦ Egress Only Internet Gatewayの利用を検討する。 （自分は使ったことないのであまり良く知りません・・・）
30. 以上でネットワーク構築は完了です。
31. お気づきになりましたか？ ここまでで、セキュリティグループについて触れていません。 AWS初心者にありがちなのが、ネットワーク通信制御とセキュリティグループとを混同す ることです（少なくとも私は最初混乱しました。インフラの人から見たらハナから別物なのかなあ・・・） 。 セキュリティグループで通信を許可しても、VPCでルーティングされていなければ通信は 不可能です。また、セキュリティグループは文字通り、リソースを通信単位でグルーピン グするためのものです。ネットワーク設定とは厳密に異なります。AZやサブネットの概念 がありません。セキュリティグループはリソースありきとなるため、次の章から説明しま す。 とはいえあまり複雑に捉えず、セキュリティグループはネットワーク設定の上にあるレイヤと思っておけば問題な いです。
32. 第2章 EC2 / EBS
33. サーバリソースの構築 EC2は仮想マシンを時間課金で起動するタイプの、いわゆるIaaSという概念に該当する ものです。つい最近、ベアメタルインスタンス（物理マシン）のサポートも開始されました。 ELB、ECS、Elastic Beanstalk、EMR など数多くのサービスがEC2をラップしたサービ スなので、EC2の概要を知ることはAWS利用の上で必須といえます。 実際に踏み台用のEC2インスタンスを作成する手順に沿って、EC2構築における概念 や考慮事項を説明していきます。
34. サーバリソースの構築 EC2を構築するうえで考慮しなければならないのは以下の事項です。 • OSとバージョン • インスタンスタイプ（CPU、メモリ、ネットワーク帯域） • ストレージの種類とサイズ、IOPS性能 • サーバの初期化処理（UserData =>プロビジョニングスクリプト） • インスタンスプロファイル（IAMロール） • Windowsの場合はドメイン、ライセンスなど考慮事項多数
35. OSとバージョン選定 EC2の作成では、まずOSとバージョンを選択します。
36. 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など
37. OSとバージョン選定 どのOSのどのバージョンを利用するかは、目的によって異なると思いますが、特に理由 がない限りAmazon Linuxの利用をオススメします。 • AWS利用における情報量の多さ、AWSのサポート • AWSが独自にパッチを当てたXenやKVMとの親和性 • パッケージリポジトリがS3に存在するため超高速インストール • 通常のRHELやCentOSよりもパッケージが少し新しめ • aws-ssm-agentなどAWSツールが標準リポジトリからインストール可能 なお、公式のAMIではカーネルパラメータやカーネルモジュールなどは汎用的な用途に マッチするように初期設定されています。これらはgrubやmodproveの設定を変更した 状態でAMIを作成することにより、ユーザによってチューニング可能です。
38. OSとバージョン選定 RHEL や SUSE 、Windows など有料のOSのライセンスは従量課金の利用料金に含 まれています。 すでにライセンスを購入済みの場合は購入済みライセンスを適用することで従量課金額 を安くすることができます。(BYOL: Bring Your Own License) Windows Server のライセンス形態は複雑すぎてよくわからないので、不安な場合はソ リューションアーキテクトの方に相談してください。 ※ただでさえ複雑なWindowsライセンスがAWSの独自エディションでわけわからなくなっています。 Windowsに限らず、BYOL利用の場合はソリューションアーキテクトへの相談は必要に なるでしょう。
39. OSとバージョン選定 まとめ • OS選定で最も重要なのは、インストールするパッケージのサポート。 • 次に重要なのは運用チームの習熟度。 • 特に理由がない限り、Amazon Linuxを選んでおけばOK。 • systemdを利用したい場合は RHEL7 か Amazon Linux 2。 • Windows向けの製品を利用したい場合。Windows向けだけではないけど、 Windowsに最適化された製品も多数存在する。(日立のCosminexusとか) マネジメントコンソールでの作業だとわかりづらいですが、OS選択画面では、裏側で当 該OSがプリインストールされたAMIのIDが選択されています。AMIについては後述しま す。
40. インスタンスタイプ選定 OSを選択したら、次にインスタンスタイプを選択します。
41. インスタンスタイプ選定 EC2には用途に応じてインスタンスタイプという区分が存在します。インスタンスタイプに よって搭載される仮想CPUコア数、メモリ量や、ネットワーク帯域、ローカルストレージ容 量が変わります。 インスタンスタイプは用途を表すアルファベット1文字と世代を表す数字1文字、グレード で表されます。用途と世代を合わせた2文字をインスタンスファミリーと呼称します。イン スタンスファミリーは2文字以上のものも存在します。 例: m5.4xlarge の場合 • m => 汎用インスタンスを表す。 • 5 => 第５世代のインスタンスを表す。 • 4xlarge => インスタンスファミリーにおけるグレード。 ◦ 大きいほど高価で高性能。 4xlargeはxlargeの4倍という意味。
42. インスタンスタイプ選定 現行世代には以下のインスタンスファミリーがあります。 • 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 以外は低価格 帯での提供タイプがないものが多いです。
43. インスタンスタイプ選定 t2インスタンスは、普段はCPUが従来の20%しか利用できない代わりに時間単価がか なり安いインスタンスタイプです。 時間経過とともにクレジット（単位は時間）が溜まっていき、このクレジットを消費すること でクレジット分の時間だけバースト（CPU性能を100%利用可能な状態）することができ ます。 また、Unlimitedオプションを有効にすると、クレジットが枯渇しても追加料金を支払うこと でバースト時間を増やすことができます。 現行世代では低パフォーマンス帯のインスタンスタイプはt2でしか提供されていないの で、今後利用する際にはt2ファミリーの利用が増えると思います。
44. インスタンスタイプ選定 インスタンスタイプごとに設定されているvCPU数やメモリ容量は理論値です。 実際にまったく同じインスタンスタイプのEC2インスタンスでも、パフォーマンスに大きく 差が出ることがよくあります。 これは、DCに設置されているKVMホストマシンもしくは接続機器の故障や老朽化によっ て仮想マシンにパフォーマンス劣化の影響が出ているためです。 EC2インスタンスのパフォーマンスにバラツキがあるため、このような事象をEC2ガチャ と呼んだりします。 なので、低パフォーマンスのEC2を引いたときでも即廃棄できるようにイミュータブルな システムを構築することはクラウドにおいて必須と言えます。
45. インスタンスタイプ選定 一部のインスタンスタイプでは、EC2インスタンスの仮想マシンに物理接続されている ローカルストレージであるインスタンスストア（エフェメラルディスク）が付いてきます。 このインスタンスストアはEC2終了時にデータが消去されますが、ネットワーク接続され ているEBSと比べてI/Oが圧倒的に高速というメリットがあります。 なので、ログや中間ファイルなどをインスタンスストアに入出力することでシステム全体 のパフォーマンス向上に寄与します。 ただし、インスタンスストアは現行世代のインスタンスにはほとんど搭載されていませ ん。つい最近まで m3.medium ですらあったのに、なんで！？
46. インスタンスタイプ選定 まとめ • とにかく低コストにしたいのであれば t2 • AutoScaling前提のWebシステムであれば汎用の t2 か旧世代の m3 • 平常時のアクセス量が多い中規模以上のWebシステムであれば m5 • DBなどディスクI/O性能を求めるならストレージ最適化 • RedisやMemcachedなどオンメモリDBを利用するならメモリ最適化 • 機械学習など計算量が多いシステムならGPU最適化 • VMware on AWS など Hypervisor を利用したい場合は i3.metal • エムスリーなので m3
47. ネットワークの設定 EC2インスタンスの詳細設定画面です。量が多いのでセクションごとに説明します。まず はネットワーク周りです。VPCとサブネットを選択します。 EC2インスタンスは必ずVPC内のサブネットに属します。（昔はVPC外 に作成することができました。） 後からVPCやサブネットを変更することはできません。変更したい場合 はスナップショットを作成して起動しなおします。 踏み台インスタンスでは、EIPをアサインしてIPを固定にするた め自動割り当てのパブリックIPは利用しません。
48. スポットインスタンス スポットインスタンスは、入札により課金額が決定するインスタンスです。 通常のオンデマンドインスタンスより最大9割くらい安く稼働させることができますが、入 札額が相場を下回ると自動的に停止します。 ステートレスな処理を大量に行うバッチ処理などで有効です。Webシステムではスパイ クアクセスなどによりトラフィックが急増した際に利用したりします。 また、AWS BatchやEMRなど一部のサービスではスポットインスタンスを利用する機能 が備わっているものもあります。
49. プレイスメントグループ AZ内のEC2インスタンス間通信は十分に高速ですが、プレイスメントグループを作成す るとさらに高速な通信が可能になります。 プレイスメントグループは、ネットワーク的に近いHW上にインスタンスを構築すること で、通信のレイテンシを最小限におさえることが可能です。 ただし、「ネットワーク的に近い = 物理的な距離が近い」なので、災害などによりまとめて 死ぬことがありえます。 一般的なWebシステムでは、インスタンス間の通信は不要なことが多いため、プレイスメ ントグループを利用することは少ないと思います。分散バッチなどでの利用がメインとな るでしょう。他には、インスタンス間通信を前提としたErlang/OTPや、トライアド構成のシ ステムなどでも有用かもしれません。
50. ネットワーク以外の設定です。IAMロールは後述します。モニタリングやテナンシーは今 回は割愛します。 その他の設定 EC2インスタンスに紐付けるIAMロールを選択します。IAMロールはイン スタンスプロファイルを持っている必要があります。
51. IAMロール (インスタンスプロファイル) EC2にはIAMロールを紐付けることができます。 IAMロールがアタッチされたEC2インスタンスからは、各AWSサービスに対してアクセス キーなしでAPI実行が可能なため、セキュアにAWSのAPIを利用可能です。 EC2からAWSのサービスを利用する場合は、必ずIAMロールを設定するようにしてくだ さい。 間違ってもIAMユーザーを作成して、アクセスキーをEC2上に格納しないように気をつけ てください。
52. UserData (プロビジョニングスクリプト) EC2では初回起動時に行うプロビジョニングの処理を設定することができます。これを UserDataと言います。 Linuxであればshebangで実装言語を指定可能です。#cloud-config をshebangに指定 した場合は、YAMLで記述可能なCloud-Initの仕様を利用可能です。
53. UserData (プロビジョニングスクリプト) BashでUserDataを記載する例を見てみます。 以下の例では、sshdのListenポートを変更しています。 ※前職でよく使っていました。その時は443に変更してました。
54. UserData (プロビジョニングスクリプト) Cloud-InitはクラウドサーバをプロビジョニングするためのDSL仕様で、ansibleみたいに 宣言的にサーバの状態を記述できるため非常に便利です。 以下のリンクに様々なユースケースでのサンプルコードが載っています。 http://cloudinit.readthedocs.io/en/latest/ 初回起動時以外のイベント処理も記載可能で、冪等性も担保されます。 なお、ECSではクラスタインスタンスの利用でUserDataを必ず利用します。Elastic BeanstalkではUserDataの代わりにインスタンスを初期化する手段があります。
55. EC2のストレージ (EBS)
56. EC2のストレージ (EBS) EBSは仮想ブロックストレージです。仮想ハードディスクと思っておけば大体あってま す。EC2のOSイメージや、アプリケーションバイナリ、ログファイルなどのファイルを格納 するための永続化ストレージです。 EC2そのものは永続ストレージを持っていません。EC2起動時にOS起動イメージが格 納されたEBSが複製・アタッチされ、アタッチされたEBSがマウントされた状態で起動し ます。ファイルシステムはAmazon LinuxデフォルトだとXFSです。 また、EBSはEC2上で動作する他のサービスでも利用されます。代表的なもので、RDS やElasticsearchがあります。これらのサービスはEBS上にデータを永続化しています。 ちなみに、API上ではEBSはVolumeというエンティティ名です。忘れやすいので注意。
57. EC2のストレージ (EBS) EBSは最低で100 IOPSのベースライン性能が出ます(gp2の場合)。また、IOクレジット があり、クレジットが枯渇しない限り最大3000 IOPSまでバースト可能です。 プロビジョンドIOPSストレージ(io1)の場合、IOPSを最大で60000まで指定することが可 能です。 EBSには gp2, st1, sc1 など種別があり、ランダムアクセスが得意、シーケンシャルアク セスが得意、スループットが安定しているなどの特性があります。 通常のWeb利用ではストレージ速度を気にすることはあまりないので、汎用ボリューム のgp2を選択することが多いです。
58. EC2のストレージ (EBS) EBSはスナップショット機能があります。オンラインで取得可能なのでデータの信頼性が 重要なシステムでは重宝します。 ただ、リストアにそれなりに時間がかかるので、RTT（目標復旧時間）の指標が厳しい ミッションクリティカルなシステムではEBSのスナップショットとは別に、OS内でファイル システムのスナップショット(LVMスナップショットやxfs_dumpなど)を取得することもよく あります。前職では2台のEC2でDRBDを組んだりしてました。 RDSの自動バックアップ機能はEBSのスナップショットにより実現されています。スナッ プショットされたイメージはS3に格納されます。なお、S3のコンソールからスナップショッ トを確認することはできません。
59. タグの設定 EC2においてタグは比較的重要です。Systems Managerによるパッチ適用やパッケー ジインストールなどを行うにあたり、タグを利用するためです。サーバーロールや環境 名、サービス名などを入れておきましょう。
60. セキュリティグループの設定 セキュリティグループについては後述します。ここでは社内からのSSHを許可していま す。
61. キーペアの選択
62. 以上で踏み台インスタンスの構築は完了です。
63. セキュリティグループ セキュリティグループは文字通り、通信を許可するリソースをグルーピングするための機 能です。通信の受信（Ingress）と送信（Egress）を、ホワイトリストとブラックリストにより 認可します。 設定可能な代表的なパターンは以下の通りです。 • 特定のセキュリティグループからのアクセスに対する認可 • セキュリティグループ内のアクセスに対する認可 • 特定のIPアドレス(CIDR)からのアクセスに対する認可 • 特定のIPアドレス(CIDR)へのアクセスに対する認可 • VPCエンドポイントへのアクセスに対する認可（今回は割愛）
64. セキュリティグループ 特定のセキュリティグループからのアクセスに対する認可 VPC内のリソースからのアクセスを制御するパターンで、頻出パターンです。EC2に対 するELBからのアクセス、RDSに対するEC2のアクセスなど、AWSリソース間でのアク セス制御に利用します。非常にシンプルですが、設計を誤ると相互参照が発生します。 相互参照は作成する分にはエラーにはなりませんが、削除しようとするとエラーになるた め、terraformなどで厄介です。
65. セキュリティグループ セキュリティグループ内のアクセスに対する認可 同一セキュリティグループ内の通信を許可するパターンです。RDSやElastiCacheのセ キュリティグループとして利用することが多いです。複数のセキュリティグループをオー バーラップさせる前提となります。相互参照しづらくなるためterraformなどとの相性がい いですが、人間にはわかりづらいというデメリットがあります。
66. セキュリティグループ 特定のIPアドレス(CIDR)からのアクセスに対する認可 踏み台インスタンスへのSSH接続、テスト環境へのWebアクセスなど、VPCの外にある 拠点からのアクセスを制限する場合に利用します。これには、VPN接続で接続されてい る別のVPCや、Direct Connect経由で接続されているオンプレからのアクセスも含まれ ます。
67. セキュリティグループ 特定のIPアドレス(CIDR)へのアクセスに対する認可 特定のIPアドレスへの通信のみを許可し、外部へのアクセスを制限するパターンです。 マルウェアや内部犯行対策として設定することがほとんどです。
68. ネットワークACL IPアドレスに対する制限は（説明していませんが）ネットワークレイヤであるサブネットの ACLでも可能です。 より堅牢にするのであれば、サブネットのACLとセキュリティグループを併用して同じ制 限をかけます。こうすることによって、誤ってどちらかの制限を解除してしまった場合でも 救済することができます。 当然、管理は煩雑になるのでterraformなどで管理したほうがいいでしょう。
69. 第3章 AutoScaling / ELB
70. AutoScaling AutoScalingは、最小インスタンス数と最大インスタンス数を指定して、スケーリングポリ シーに応じてスケールアウト・スケールインを行う仕組みの総称です。AWSに限った用 語ではありません。 AWSでは、ロードバランサーから接続するWebサーバを負荷分散するために利用する のが主な用途です。 なお、ロードバランサーは必須ではなく、バッチ処理を複数サーバで分散処理する場合 にも利用されます。 AutoScalingの機能自体はロードバランサーに依存していないため、多くのユースケー スで利用が可能です。
71. Amazon Machine Image (AMI) AutoScalingを説明する上で、AMIの説明は避けて通れないのでAMIを紹介します。 AMIとは、EC2起動前のVMイメージです。より具体的にはEC2のメタデータ（OSやデバ イスマッピング情報など）と、OS起動イメージやファイルなどが格納されているEBSを圧 縮したアーカイブファイルです。 AWSから提供されているAMIでEC2を起動し、起動したEC2にミドルウェアやアプリケー ションをインストールして、AMIを作成することができます。 EC2は必ずこのAMIから起動されます（起動時にAMIのIDを指定します）。
72. Amazon Machine Image (AMI) AutoScalingでは、スケールアウトさせる際に、どのAMIを利用してEC2を起動するかを 予め定義しておく必要があります。 AWS提供のデフォルトAMIから起動してUserDataでもろもろ初期化してもAutoScaling は可能ですが、パッケージインストールしてアプリケーションを展開して設定ファイルを生 成してなどをUserDataで行うと、スケールアウトまでの時間が非常に長くなってしまいま す。 そのため、通常はアプリケーションなどをインストール済みの状態でAMIを作成してお き、AutoScalingの起動設定でそのAMIを指定することで起動時間を短縮することがで きます。
73. Amazon Machine Image (AMI) 起動設定に利用するAMIの戦略として、代表的なパターンとして以下があります。 • 必要なミドルウェアのみインストールされた状態のAMI • アプリケーションまでインストールされた状態のAMI • アプリケーションの設定や環境変数まで格納されたAMI 下に行くほど起動は高速になりますが、設定や環境変数まで格納したAMIを作成する と、開発環境用AMI、本番用AMIなど非常に多くのAMIがバージョンごとに存在すること になり、コストも増大します。 そのため、よく利用されるパターンとしては２番めの戦略となります。その場合、アプリ ケーションの設定や環境変数は起動スクリプトなどで取得します。
74. 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参照）
75. AutoScalingの起動設定 (非推奨） AutoScalingを設定するためには、スケールアウト時にどのAMIを起動するかを予め設 定しておく必要があります。この設定をLaunchConfiguration(起動設定)といいます。 LaunchConfigurationの内容は、EC2の起動で入力したパラメータとほぼ同じです。 なお、LaunchConfiguration は現在非推奨となっています。 起動テンプレートを利用することが推奨されているため、今回は起動設定の説明を割愛 します。 起動テンプレートはローンチされたばかりの新しい機能です。そのため、Webで検索す るとほとんどは起動設定がヒットします。注意してください。
76. Launch Template LaunchConfigurationはAutoScalingでしか利用できませんが、Launch Templateは通 常のEC2起動に利用可能です。また、起動テンプレートはバージョン管理されます。以 下は起動テンプレート作成画面です。
77. Launch Template 起動テンプレートで起動するAMIのIDとインスタンスタイプ、キーペア名を指定します。 ネットワークタイプは必ずVPCを選択してください。Classicを使うことは将来的に見ても ありません。 AutoScalingに利用する場合は、アプリケーションなどがインストールされ たAMIのIDを指定します。 起動したEC2にSSHログインする必要がない場合は空にします。 ssm-agentを利用する前提であればSSHログインは不要です。
78. ネットワークインターフェイス、ストレージは空のままにします。 Launch Template AutoScalingで利用する場合は、AutoScalingGroupの設定でネットワー クを設定するため不要です。 ルートボリュームはAMIに含まれています。ルートボリューム以外をアタッ チする必要がある場合のみ指定します。
79. タグを指定します。このタグはAutoScalingで起動されたすべてのインスタンスに設定さ れます。これらとは別に、AutoScalingGroupのIDなどメタ情報のタグも設定されます。 Launch Template
80. セキュリティグループを指定します。起動されたすべてのEC2インスタンスがここで設定 したセキュリティグループに所属します。 Launch Template まだELBを作成していないので、とりあえず同一セキュリティグループからのHTTPアク セスを許可しておきます。
81. その他の詳細設定です。EC2起動時に設定 した内容と似ていますが、ElasticGPUなど の項目が追加されています。 特定のAMIでのみ有効な項目もあります。 RAMディスクIDとカーネルIDはほぼ利用す ることはないでしょう。 重要なパラメータとしてモニタリングがありま す。次のスライドで説明します。 Launch Template
82. モニタリングは重要なポイントなので補足します。詳細モニタリングを有効にしなかった 場合、スケーリングの判断に必要なCloudWatchのメトリクスは最小でも5分間隔でしか 取得されません。 これはつまり、閾値を超えてスケールアウトが必要になるまでに最大で10分かかること を意味します。そこからEC2が起動して準備完了になるまでさらに数分かかるため、ス ケールアウトが完了するまでの時間は12〜15分くらいかかることになります。迅速なス ケールアウトが必要なシステムでは必ず詳細モニタリングを有効にしてください。（ただ し、詳細モニタリングはコストが上がります） Launch Template
83. AutoScalingGroupの作成 起動テンプレートができたら、AutoScalingGroupを作成します。 作成した起動テンプレートを選択します。起動テンプレート画面から AutoScalingGroupの作成を実行した場合はこの画面はスキップされます。
84. 起動するテンプレートのバージョンとグループ名を指定します。 AutoScalingGroupの作成 「バージョンID」もしくは「最新」を選択可能です。起動テンプレートもCI/CDを行うのであ れば、「最新」を選択してはいけません。新しいインスタンスが勝手に最新バージョンの AMIで起動されてしまいます。
85. 作成直後のインスタンス数と、起動対象となるVPCおよびサブネットを指定します。 AutoScalingGroupの作成 複数のサブネットを指定することでMulti-AZ構成となります。ここではプライベートサブ ネットのゾーンAとゾーンCで起動するように指定しています。
86. なお、AutoScalingGroupの画面から直接ELBを指定することも可能ですが、今回は先 にAutoScalingGroupを作成するため、ここでは行いません。 AutoScalingGroupの作成
87. AutoScalingGroupの作成 AutoScalingで最も重要なパラメータである、スケーリングポリシーを設定します。最小 サイズ、最大サイズ、メトリクス、閾値などを指定します。 ここではCPU利用率以外には、ネットワークOut、ネットワークIn、リクエスト数が選択可 能です。他のメトリクスを利用する場合はCLIなどから設定します。AutoScalingGroup については、マネジメントコンソールで可能な操作が極端に制限されています。以前より も設定項目が減っています。
88. AutoScalingGroupの作成 スケーリングポリシーに関しては、AWSのキモと言ってもいい設定です。そのため、設定 内容は非常に細かく、マネジメントコンソールで設定しようとするとUIが非常に煩雑にな るため、あえてシンプルな設定しかできないようにデグレードしたものと思われます。 シンプルなスケーリングポリシーを利用する場合は問題ありませんが、カスタムメトリク スの利用や、細かい制御を行いたい場合はCLIやterraformでの設定が必須となりま す。 そもそもスケーリングポリシーに関しては運用中に頻繁に見直すべき内容ですので、最 初はシンプルなもので設定しておくというのは理にかなっているのかもしれません。
89. AutoScalingGroupの作成 ライフサイクルイベント発生時の通知先を指定可能です。画面ではメールアドレスを指 定していますが、SNSトピックであれば何でもいいので、ライフサイクルイベント発生時 にフック処理を行う場合はSNS経由でLambdaを呼び出します。
90. AutoScalingGroupの作成 最後にタグを設定して作成完了です。
91. ELB(ロードバランサー)の作成 AWSのロードバランサーは以下の３種類が存在します。 • Application Load Balancer (ALB) • Network Loadbalancer (NLB) • Classic Load Balancer (CLB) 通常のWebシステムではALBを利用しますが、他の2つについても非常に重要なのでそ れぞれの特徴について説明します。
92. ELB (Elastic Load Balancer) 各ELBを説明する前に、ELB全体についての説明をします。 ELBは負荷量に応じて自動でスケールアウトするロードバランサーのEC2インスタンス です。スケールアウトは全自動で行われ、利用者が制御することはほぼできないので、 いつの間にか台数が増えたり減ったりしています。 スケールアウトした場合は当然IPアドレスが消費されるので、ELBを使うサブネットでは スケールアウト分のIPアドレス余剰がなければいけません。（IPアドレスが足りないとス ケールアウトが失敗しますが、ELB自体が無効になったりはしません） また、キャンペーンや〇〇砲など、負荷増大が事前にわかっている場合は、ウォーム アップ申請を行ってスケールアウトを高速化することが可能です。
93. ELB (Elastic Load Balancer) ELBは通常のロードバランサーでよく見かける以下の機能があります。 • CookieによるSession Persistence • ヘルスチェック（ロードバランサーだから当たり前） • Connection Draining （切り離しても一定時間トラフィックを保持） • X-Forwarded-XXX ヘッダ （リバースプロキシのためのヘッダ） また、AWS特有の機能として以下があります。 • S3へのアクセスログ配信 • AWS WAF統合（ALBのみ） • リクエスト追跡のためのヘッダ（X-AMZN-TRACE-ID） これらの機能については今回は説明しません。
94. Application Load Balancer HTTPに特化したL7ロードバランサーです。ホスト名もしくはパスに応じて振り分け先の インスタンス（またはAutoScalingGroup）を動的に決定します。 ALBでは、HTTPもしくはHTTPSプロトコルのリスナーを追加して、プロトコルを有効にし ます。HTTPリスナーが追加されていればHTTPが、HTTPSリスナーが追加されていれ ばHTTPSが有効になります。 HTTPリスナーでは受信ポートを指定できます。HTTPSリスナーでは受信ポートに加 え、TLSの証明書を指定できます。TLSの証明書はACM(Amazon Certificate Manager)に登録されている必要があります。 通常のWebシステムであればこのALBを利用します。構築方法については後述します。
95. Network Load Balancer TCPのL4ロードバランサーです。ALBと違うのは、負荷分散対象がEC2インスタンス以 外に、静的なIPアドレスを対象にできるということです。 IPアドレスが疎通していればどんな対象にでもトラフィック可能なため、EC2インスタンス に限らず、オンプレのサーバや他のAWSサービスに対しても負荷分散が可能です。 2018年6月現在ではTLS終端の機能は持っていないため、TLS終端処理はターゲット側 で行う必要があります。 主な用途としては、オンプレとの負荷分散、VPCエンドポイントの負荷分散、および gRPCなどHTTP/2の負荷分散です。（ALBではHTTP/2の負荷分散はできません）
96. 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が出る前の旧機能。
97. ALBの作成 作成済みのAutoScalingGroupに対して負荷分散を行うALBを構築します。
98. ALBの作成 今回はHTTPSは使わずにHTTPのみです。
99. ALBの作成 ELBのサブネットを指定します。インターネット向けのELBはパブリックサブネットに構築 しなければなりません。また、ELBは可用性のためMulti-AZで負荷分散することがほと んどです。
100. ALBの作成 セキュリティグループを設定します。インターネット向けなのでHTTPを全公開していま す。 スクリーンショットのために 0.0.0.0/0 を指定していますが、評価目的などでは オフィスのグローバルIPからのみアクセスを許可してください。
101. ALBの作成 続いて、ALBの設定のキモであるターゲットグループを作成します。ここではデフォルト （すべてのパス）のターゲットグループを作成します。 ターゲットへの通信はHTTP/1.1です。HTTP/2に対応していません。そのた め、gRPCなどHTTP/2が必須の場合にALBが利用できません。
102. ALBの作成 ターゲットグループごとにヘル スチェックの指定ができます。 成功コードは複数指定やレン ジ指定が可能です。
103. ALBの作成 ターゲットのインスタンスを登録しますが、AutoScalingGroupを利用する場合はここでイ ンスタンスを登録してはいけません。AutoScalingGroup側から追加します。ここで登録 してしまうとインスタンスが固定のためスケールアウトで追加されたインスタンスにトラ フィックが到達しません。
104. ALBの作成 ALBの作成が完了したら、ルールを確認します。
105. ALBの作成 マネジメントコンソールから作成した場合、デフォルトのルールのみが存在します。これ は、すべてのHTTPトラフィックをターゲットグループ edu-201806 にルーティングする ルールを表しています。
106. AutoScalingGroupをALBに登録 AutoScalingGroupをALBのターゲットグループとして登録します。先ほど作成した AutoScalingGroupの設定画面で、ALBのターゲットグループを入力して設定を保存しま す。
107. AutoScalingGroupをALBに登録 すると、自動的にターゲットグループのターゲットにAutoScalingGroup配下のインスタン スが登録されます。
108. セキュリティグループの設定 最初にAutoScalingGroupを作成してからALBを作成したため、ALBからEC2への通信 が許可されていません。そのためヘルスチェックに失敗します。 ALBからEC2への通信を許可するには2通りのやり方があります。 • ALBをEC2のセキュリティグループに参加させる。 • ALBのセキュリティグループからのアクセスをEC2のセキュリティグループで許可す る。
109. セキュリティグループの設定 ALBをEC2のセキュリティグループに参加させる場合 ロードバランサーメニューで当該ALBを選択してセキュリティグループの編集 を行います。
110. ALBからのアクセスをEC2のセキュリティグループで許可する場合 EC2の起動テンプレートで設定したセキュリティグループに対してALBのセキュリティグ ループからのアクセスを許可します。 セキュリティグループの設定
111. セキュリティグループの設定 どちらの手段で設定したとしても、ターゲットの状態がHealthyになりました。
112. ブラウザでの確認 ALBのDNS名を確認して、ブラウザでアクセスします。
113. ブラウザでの確認 起動テンプレートで指定したNginxインストール済みのEC2インスタンスに接続されるこ とが確認できました。
114. 作成したリソースの削除 • NATゲートウェイの削除（時間がかかるので最初に行う） • AutoScalingGroupの削除 ◦ これをやらないとインスタンス削除しても復活してしまう • SNSトピックの削除 (AutoScalingGroup消しても消えない) • ロードバランサーの削除 • ターゲットグループの削除（ALB消しても消えない） • インスタンスの削除、AMIの削除 • ALBセキュリティグループの削除 • VPCの削除
115. まとめ 今回説明した内容はAWSの基礎中の基礎となるサービスの、ごく一部の機能だけで す。 膨大なスライドの量にもかかわらず、実際に作業してみると１時間もかかりません。 なので、取っ掛かりを得たら実際に手を動かして構築してみましょう。 ところどころ書きましたが、AWSをちゃんと使うためにはマネジメントコンソールでは限界 があります。 CLIやterraform、CloudFormationの使い方を理解してチャレンジしましょう。
116. Appendix Nginx入りのAMI作成手順は以下のとおりです。 1. パブリックサブネットにAmazon LinuxのEC2を作成。キーペアを指定。 2. EC2にEIPをアタッチしてSSHで対象EIP宛にec2-userでログイン。 3. yumでnginxをインストール。chkconfig nginx onしてSSHを終了。 4. 起動中のEC2からイメージを作成。イメージが作成できたらEC2を削除。