Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AWSの基本的な使い方

 AWSの基本的な使い方

Sonoda Ryohei

June 18, 2018
Tweet

More Decks by Sonoda Ryohei

Other Decks in Technology

Transcript

  1. アジェンダ • 第1章 VPC ◦ サブネット ◦ NATゲートウェイ • 第2章

    EC2 / EBS ◦ EBS ◦ インスタンスプロファイル (IAMロール) ◦ UserData ◦ セキュリティグループ • 第3章 AutoScaling / ELB ◦ AMI ◦ Launch Template ◦ AutoScalingGroup ◦ ELB
  2. ネットワークリソースの構築(注意事項) VPC内のインスタンスからインターネットを参照可能とするかどうか VPC内のインスタンスは踏み台インスタンスを除き、インターネットから接続不可能なプ ライベートサブネットに構築するのが一般的です。ただし、インターネットへのアクセスは 必要になるケースは多いです。 • bundle installなど、パッケージのダウンロード • sentryやdockerhubなど外部サイトへのアクセス

    最初からこれらを考慮したクラウドネイティブなシステムを除き、ほとんどのケースでは 外部サイトへのアクセスが必要となります。 インターネットへのアクセスが必要な場合、通常はNATゲートウェイをVPCに構築しま す。(NATインスタンスやForward Proxyという手段もあります )
  3. ネットワークリソースの構築(詳細手順) 新規ネットワークを構築するには以下の手順で行います。 1. VPCの作成 2. インターネットゲートウェイの作成 3. パブリック用のサブネットの作成 4. パブリックサブネットの設定

    5. プライベート用のサブネットの作成 6. NATゲートウェイの作成 7. VPCエンドポイントの作成(作成は任意、今回は割愛) 8. プライベートサブネットの設定 この順序は、マネジメントコンソールでの作業順序となります。ややこしいのですが、マネジメントコン ソールで作成する場合と、Terraformなどで作成する場合で作業順序が異なることが多々あります。
  4. 補足: NATゲートウェイの冗長化 ここまでの手順で、以下のリソースが作成されています。 • VPC • インターネットゲートウェイ • パブリックサブネット *

    AZ • プライベートサブネット * AZ • NATゲートウェイ • ルートテーブル * 2 (パブリック用、プライベート用) このままでもシステム運用可能ですが、NATゲートウェイがシングルAZになっているた め、インターネット通信を頻繁に行うシステム(電子決済や外部認証など)では可用性が 問題になります。
  5. 補足: 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/月
  6. 補足: NATゲートウェイが不要なケース 以下に該当する場合はNATゲートウェイが不要な可能性があります。 • インターネット通信量や通信頻度が少ない場合 ◦ NATゲートウェイではなく、 NATインスタンスを構築する。 ◦ インターネット通信が必要な場合(デプロイ時や

    AMI作成時など)のみNATゲートウェイを構築して ルーティングする。(この操作は Lambdaなどで実装する) • 出口対策などでフォワードプロキシを構築する(もしくは構築済みの)場合 ◦ インターネット向けの通信をプロキシサーバを経由するようにルーティングする。 • 通信対象がAWSのサービスのみの場合 ◦ S3やCloudWatch LogsなどVPCエンドポイントがサポートされているサービスでは VPCエンドポイ ントを利用する。 ◦ Amazon LinuxのyumリポジトリはS3なので、標準リポジトリのみ利用の場合は VPCエンドポイント で代替可能。 • 接続先サイトに対してIPv6で接続可能な場合 ◦ Egress Only Internet Gatewayの利用を検討する。 (自分は使ったことないのであまり良く知りません・・・)
  7. 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など
  8. OSとバージョン選定 どのOSのどのバージョンを利用するかは、目的によって異なると思いますが、特に理由 がない限りAmazon Linuxの利用をオススメします。 • AWS利用における情報量の多さ、AWSのサポート • AWSが独自にパッチを当てたXenやKVMとの親和性 • パッケージリポジトリがS3に存在するため超高速インストール

    • 通常のRHELやCentOSよりもパッケージが少し新しめ • aws-ssm-agentなどAWSツールが標準リポジトリからインストール可能 なお、公式のAMIではカーネルパラメータやカーネルモジュールなどは汎用的な用途に マッチするように初期設定されています。これらはgrubやmodproveの設定を変更した 状態でAMIを作成することにより、ユーザによってチューニング可能です。
  9. OSとバージョン選定 RHEL や SUSE 、Windows など有料のOSのライセンスは従量課金の利用料金に含 まれています。 すでにライセンスを購入済みの場合は購入済みライセンスを適用することで従量課金額 を安くすることができます。(BYOL: Bring

    Your Own License) Windows Server のライセンス形態は複雑すぎてよくわからないので、不安な場合はソ リューションアーキテクトの方に相談してください。 ※ただでさえ複雑なWindowsライセンスがAWSの独自エディションでわけわからなくなっています。 Windowsに限らず、BYOL利用の場合はソリューションアーキテクトへの相談は必要に なるでしょう。
  10. OSとバージョン選定 まとめ • OS選定で最も重要なのは、インストールするパッケージのサポート。 • 次に重要なのは運用チームの習熟度。 • 特に理由がない限り、Amazon Linuxを選んでおけばOK。 •

    systemdを利用したい場合は RHEL7 か Amazon Linux 2。 • Windows向けの製品を利用したい場合。Windows向けだけではないけど、 Windowsに最適化された製品も多数存在する。(日立のCosminexusとか) マネジメントコンソールでの作業だとわかりづらいですが、OS選択画面では、裏側で当 該OSがプリインストールされたAMIのIDが選択されています。AMIについては後述しま す。
  11. インスタンスタイプ選定 現行世代には以下のインスタンスファミリーがあります。 • 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 以外は低価格 帯での提供タイプがないものが多いです。
  12. インスタンスタイプ選定 まとめ • とにかく低コストにしたいのであれば t2 • AutoScaling前提のWebシステムであれば汎用の t2 か旧世代の m3

    • 平常時のアクセス量が多い中規模以上のWebシステムであれば m5 • DBなどディスクI/O性能を求めるならストレージ最適化 • RedisやMemcachedなどオンメモリDBを利用するならメモリ最適化 • 機械学習など計算量が多いシステムならGPU最適化 • VMware on AWS など Hypervisor を利用したい場合は i3.metal • エムスリーなので m3
  13. EC2のストレージ (EBS) EBSは最低で100 IOPSのベースライン性能が出ます(gp2の場合)。また、IOクレジット があり、クレジットが枯渇しない限り最大3000 IOPSまでバースト可能です。 プロビジョンドIOPSストレージ(io1)の場合、IOPSを最大で60000まで指定することが可 能です。 EBSには gp2,

    st1, sc1 など種別があり、ランダムアクセスが得意、シーケンシャルアク セスが得意、スループットが安定しているなどの特性があります。 通常のWeb利用ではストレージ速度を気にすることはあまりないので、汎用ボリューム のgp2を選択することが多いです。
  14. Amazon Machine Image (AMI) 起動設定に利用するAMIの戦略として、代表的なパターンとして以下があります。 • 必要なミドルウェアのみインストールされた状態のAMI • アプリケーションまでインストールされた状態のAMI •

    アプリケーションの設定や環境変数まで格納されたAMI 下に行くほど起動は高速になりますが、設定や環境変数まで格納したAMIを作成する と、開発環境用AMI、本番用AMIなど非常に多くのAMIがバージョンごとに存在すること になり、コストも増大します。 そのため、よく利用されるパターンとしては2番めの戦略となります。その場合、アプリ ケーションの設定や環境変数は起動スクリプトなどで取得します。
  15. 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参照)
  16. ELB(ロードバランサー)の作成 AWSのロードバランサーは以下の3種類が存在します。 • Application Load Balancer (ALB) • Network Loadbalancer

    (NLB) • Classic Load Balancer (CLB) 通常のWebシステムではALBを利用しますが、他の2つについても非常に重要なのでそ れぞれの特徴について説明します。
  17. ELB (Elastic Load Balancer) ELBは通常のロードバランサーでよく見かける以下の機能があります。 • CookieによるSession Persistence • ヘルスチェック(ロードバランサーだから当たり前)

    • Connection Draining (切り離しても一定時間トラフィックを保持) • X-Forwarded-XXX ヘッダ (リバースプロキシのためのヘッダ) また、AWS特有の機能として以下があります。 • S3へのアクセスログ配信 • AWS WAF統合(ALBのみ) • リクエスト追跡のためのヘッダ(X-AMZN-TRACE-ID) これらの機能については今回は説明しません。
  18. 作成したリソースの削除 • NATゲートウェイの削除(時間がかかるので最初に行う) • AutoScalingGroupの削除 ◦ これをやらないとインスタンス削除しても復活してしまう • SNSトピックの削除 (AutoScalingGroup消しても消えない)

    • ロードバランサーの削除 • ターゲットグループの削除(ALB消しても消えない) • インスタンスの削除、AMIの削除 • ALBセキュリティグループの削除 • VPCの削除