AWSの基本的な使い方
Sonoda Ryohei
June 18, 2018
AWSの基本的な使い方
Sonoda Ryohei
June 18, 2018
![537bf56f8f2b658d3bcf98f2996189bc?s=48](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48"><rect fill-opacity="0"/></svg>){kind=avatar}
sonodar
reverentgeek
rmw
skipperchong
keathley
productmarketing
clairelew
thoeni
jcasabona
Transcript
-
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)環境の構築（今回は触れません） 以降のスライドでは、それぞれの構築フェーズで行う作業と、考慮すべきポイントを解説 します。 -
7.
-
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などで作成する場合で作業順序が異なることが多々あります。 -
14.
VPCの作成 VPCを作成すると、以下のリソースがデフォルト生成されます。 • デフォルトのセキュリティグループ • デフォルトのルートテーブル（メインルートテーブル） これらのデフォルトで生成されたリソースは、VPCが存在する限り破棄できないため、 TerraformなどInfrastructure as Codeで管理する場合は基本的に利用しないほうがい
いです。 VPCに限らず、デフォルト生成されたリソースは基本的に無視したほうがTerraformなど で管理しやすいです。自動生成されるリソースは、他にはDHCPオプションやRDSパラ メータグループなどがあります。 -
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の利用を検討する。 （自分は使ったことないのであまり良く知りません・・・） -
31.
お気づきになりましたか？ ここまでで、セキュリティグループについて触れていません。 AWS初心者にありがちなのが、ネットワーク通信制御とセキュリティグループとを混同す ることです（少なくとも私は最初混乱しました。インフラの人から見たらハナから別物なのかなあ・・・） 。 セキュリティグループで通信を許可しても、VPCでルーティングされていなければ通信は 不可能です。また、セキュリティグループは文字通り、リソースを通信単位でグルーピン グするためのものです。ネットワーク設定とは厳密に異なります。AZやサブネットの概念 がありません。セキュリティグループはリソースありきとなるため、次の章から説明しま す。
とはいえあまり複雑に捉えず、セキュリティグループはネットワーク設定の上にあるレイヤと思っておけば問題な いです。 -
32.
-
34.
サーバリソースの構築 EC2を構築するうえで考慮しなければならないのは以下の事項です。 • OSとバージョン • インスタンスタイプ（CPU、メモリ、ネットワーク帯域） • ストレージの種類とサイズ、IOPS性能 • サーバの初期化処理（UserData
=>プロビジョニングスクリプト） • インスタンスプロファイル（IAMロール） • Windowsの場合はドメイン、ライセンスなど考慮事項多数 -
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については後述しま す。 -
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 以外は低価格 帯での提供タイプがないものが多いです。 -
46.
インスタンスタイプ選定 まとめ • とにかく低コストにしたいのであれば t2 • AutoScaling前提のWebシステムであれば汎用の t2 か旧世代の m3
• 平常時のアクセス量が多い中規模以上のWebシステムであれば m5 • DBなどディスクI/O性能を求めるならストレージ最適化 • RedisやMemcachedなどオンメモリDBを利用するならメモリ最適化 • 機械学習など計算量が多いシステムならGPU最適化 • VMware on AWS など Hypervisor を利用したい場合は i3.metal • エムスリーなので m3 -
49.
プレイスメントグループ AZ内のEC2インスタンス間通信は十分に高速ですが、プレイスメントグループを作成す るとさらに高速な通信が可能になります。 プレイスメントグループは、ネットワーク的に近いHW上にインスタンスを構築すること で、通信のレイテンシを最小限におさえることが可能です。 ただし、「ネットワーク的に近い = 物理的な距離が近い」なので、災害などによりまとめて 死ぬことがありえます。 一般的なWebシステムでは、インスタンス間の通信は不要なことが多いため、プレイスメ
ントグループを利用することは少ないと思います。分散バッチなどでの利用がメインとな るでしょう。他には、インスタンス間通信を前提としたErlang/OTPや、トライアド構成のシ ステムなどでも有用かもしれません。 -
55.
-
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を選択することが多いです。 -
61.
-
63.
セキュリティグループ セキュリティグループは文字通り、通信を許可するリソースをグルーピングするための機 能です。通信の受信（Ingress）と送信（Egress）を、ホワイトリストとブラックリストにより 認可します。 設定可能な代表的なパターンは以下の通りです。 • 特定のセキュリティグループからのアクセスに対する認可 • セキュリティグループ内のアクセスに対する認可 •
特定のIPアドレス(CIDR)からのアクセスに対する認可 • 特定のIPアドレス(CIDR)へのアクセスに対する認可 • VPCエンドポイントへのアクセスに対する認可（今回は割愛） -
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.
-
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が出る前の旧機能。 -
114.
作成したリソースの削除 • NATゲートウェイの削除（時間がかかるので最初に行う） • AutoScalingGroupの削除 ◦ これをやらないとインスタンス削除しても復活してしまう • SNSトピックの削除 (AutoScalingGroup消しても消えない)
• ロードバランサーの削除 • ターゲットグループの削除（ALB消しても消えない） • インスタンスの削除、AMIの削除 • ALBセキュリティグループの削除 • VPCの削除 -
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を削除。
