AWS箇条書きナレッジ

話のネタ

• ドワンゴ Advent Calendar
• 元々はプログラマで、3年くらい前にインフラ（サーバー）エンジニアに転向
  • オンプレミスで物理サーバー設置・OS等インストール・運用を担当
  • Chef今も活用してます（Chef Solo代替を検討中。そのうち何か晒したい）
• AWS未経験の2015年6月から4か月間で、悪戦苦闘しながら ニコルンを無事リリース
• AWSおもしろいけど、覚えること知らないといけないことが多すぎて、しかもやってから罠を踏むこと多数
• AWSこれから始める人や、経験したことのある人でも役立つ、
  構築・運用するときのポイントをまとめたナレッジ書いてみました

導入

• AWSって費用がお得なの？
  • AWSの方がコスト割高：VPS1つで収まる程度の規模、大規模なシステム
  • AWSの方がお得な傾向：スタートアップなシステム、規模にマッチした設計・運用ができているシステム
  • サーバー起動中は1時間ごとに従量課金（時間単位でサーバー停止して節約…とかはあまりやらないけど）
• オンプレミスと比べてどう？
  • 導入：物理設置がないので、すぐ作れてすぐ使える
  • 運用：物理障害による物理交換はしなくてもよい
    　　　が、AWSでも故障に伴って作業が必要なことはある
  • 可用性：AWSが提供してるサービスの多くはデフォルトで冗長化されている
  • 性能：規模に応じた適切なスペックを簡単に選べる・変更できる
    　　　ただしニコニコの動画配信のような大規模なサービスではオンプレミスの方が優位な面も
  • 増設：サーバーのディスクイメージのダンプとって、複製が簡単にできる
    　　　Auto Scalingを利用すれば、負荷に応じて自動的にサーバー増設もされる
  • 管理：GUIだけでなく、CLI等コマンドで管理（情報取得・登録・削除）ができる
• AWSの明確なデメリット
  • 学習コストが高い
  • 費用が従量制なので翌月にならないと金額が確定しない

---

VPC（ネットワーク）

リージョン・Availability Zone（以下AZ）

• リージョン：地理的に離れた領域
  • 例）アジアパシフィック（東京）、米国西部（北カリフォルニア）
  • 米国リージョンだけ先に新機能が提供され、東京リージョンは後回し…ということもよくある
  • リージョン間をまたぐ通信は、通常よりも費用が余計にかかる
• AZ：リージョン内でのデータセンター
  • 例）ap-northeast-1a、ap-northeast-1c
  • 地理的に分かれている
  • 各リージョンでEC2を作成すれば、災害等物理的な障害が起きてもサービスへの影響が起きにくい
• VPCのサイズ（CIDR）は一度作成したら変更不可
  • 作り直すしかないが、VPC等の設定内容をコピーして構築し直しはできない

VPC

• 仮想的なネットワークで、VPC内にはSubnetを作成でき、Subnetごとにアクセス制御設定が可能
  • そのSubnetにEC2が属する
  • 開発環境VPCと本番環境VPC、というような分け方をする
• デフォルトでは 172.31.0.0/16 というデフォルトVPCが切られている
  • デフォルトVPCを使ってもよいが、別環境とVPN接続等するときはIPアドレス帯がかぶらないようにする
• VPC間は通信できないが、"VPC Peering"を設定したSubnet間だけ通信できる
• VPCやSubnet等を利用すること自体に費用は発生しない
  • VPCへのネットワーク通信量に応じた従量課金は発生する
• VPCはマルチキャスト未サポート
  • LVS導入する場合マルチキャスト対応が必要だが、マルチキャストをユニキャストに変換するパッチをあてればできなくはない
• VPCを使わずにEC2を設置するのはEC2-Classicと呼ぶ
  • AWSの初期はこれしかなかったが、現在はVPCを構築するのがデフォルト

Subnet

• VPC内のAZごとにSubnetを作成する
  • AZをまたぐSubnetは作成することはできない
• プライベートSubnet、パブリックSubnet といった単位で区切ったりする
  • 例えばWebサーバーはパブリック、DBサーバーはプライベートに配置
  • パブリックかプライベートかの違いは、後述する"Internet Gateway"がSubnetにアタッチされている（＝インターネットからアクセスできうる）かどうか
• Subnetの最小サイズは/28から作成できる
  • ただ、Subnetで5IP分（Subnet内の先頭から4IPと最後1IP）はAWS側が確保するので、/28でも実際使えるIPは11個
  • 後述のELBをSubnetで使う場合は、最小は/27でないといけない

Route Table

• ネットワークトラフィックの経路をRoute Tableとして定義
• Route Tableは複数のSubnetに関連付けできる
  • 例えば「Webサーバー（EC2）を配置するとき、分散のためAZを分けてSubnetを切るが、どちらも同じルーティング設定にする」
• 通常はOS内でルーティング設定をするが、AWSのEC2ではRoute Tableで設定することが多い
• Route Tableで指定できるターゲットには、Internet Gateway・VPN Gateway・NAT・VPC Peering等がある

Internet Gateway

• インターネット(から|へ) の通信をするときには必ず必要
• Intenet Gatewayを作成して、それを使う設定をRoute Tableに定義
  • そのRoute Tableが関連付けられているSubnet内にいるEC2がインターネットと通信できる
• Route Tableの設定で、Internet Gatewayの送信先は0.0.0.0/0にする
  • Default Gatewayの設定になる
• 実際にインターネットと通信する全てのEC2にグローバルIP割り当ても必要
  • 外→中：ELB（があるSubnetにInternet Gateway）があれば、各EC2にグローバルIPはなくても通信可
  • 中→外：後述のNATサーバーやProxyサーバーを経由すれば、各EC2にグローバルIPはなくても通信可

VPC Endpoint

• インターネットを経由せずにプライベートネットワークのみでhttp接続できるようになる
  • （現状では）S3との接続のみ
• Endpointを作成したら、Route Tableに設定をする
• ただ、http接続にこだわらないなら、AWS CLI使えばファイルのダウンロード・アップロードはできる

NAT Gateway

• 2015/12/18から提供された、インターネットとつながっていないEC2が外と通信するためのマネージドNATサービス
  • それまではEC2でNAT用インスタンスを立ち上げるしかできなかった
  • その場合、NATの冗長対応は自前で構築しないといけなかった
• NAT Gatewayに障害が発生しても、数秒～数十秒で置き換わる
• NAT GatewayにElastic IPを割り当てることで使用可能となる
• Internet GatewayがないSubnetからでも内→外へ通信できる
  • 外→内へは通信できないので、セキュリティも確保
• 送信元IPアドレスを一意にできるので、IPアドレスでのアクセス制限サイトへの接続IPを1つで済ませられる
• Availability ZoneごとにNAT Gatewayを設置する
  • NAT Gatewayが1つだけだと、1cのEC2が 1aから出ていく、ということになってしまう
  • それぞれのAvailability Zoneに作るとなると、Elastic IPが2個必要となる

EC2

概要

• GUI（管理コンソール）やCLIから、仮想化されたサーバーを簡単に自由に作成できる
  • EC2はXenを利用して仮想化している
• どの物理サーバーに配置されてるかユーザーは知るすべはない
  • 他のユーザーのVMと相乗りになる
  • もしVMがいる物理サーバーが調子悪ければ、EC2をstop→startすると別の物理サーバーへ移動する

• 海外のリージョンを使えば、海外の物理サーバーにVMが作られる

  • 海外現地向けのサイトであれば、そっちに作った方がユーザーからの通信速度が速い

• OSが含まれたディスクイメージ（AMI = Amazon Machine Image）から仮想サーバー（インスタンス）を作成する

• EC2で使えるOSは、無償のLinuxだけでなく有償のWindows等も利用できる

  • 有償OSのライセンス料はAWSの利用料金に含まれる
  • EC2での利用に最適化された、AWS公式のAmazon Linuxも提供している

• サーバーのスペックに応じた様々なインスタンスタイプが存在し、インスタンス作成時そこから選ぶ

  • 汎用的なスペックのものの他に、CPU・メモリ・ディスク・GPUに特化したスペックのもある

Amazon Linux

• Amazon社が提供してるRed Hat Enterprise Linux（RHEL6）ベースのディストリビューション
  • EC2ユーザーなら追加料金なしで利用可能
  • 半年に一回のペースで新しいOSイメージ（AMI）に更新されている
  • バージョンは「Amazon Linux AMI release 2015.09」と年月表記
• AWS環境で利用するのに適した設定が入っている
  • AWS CLIツールがデフォルトでインストール済み
  • 拡張ネットワーキング（高パフォーマンス・低レイテンシ）対応ドライバがインストール・設定済み
• Amazon LinuxのyumリポジトリはS3にある
  • VPC Endpoint機能を使うと、S3との通信にインターネットを介さずに済むので、グローバルIPがなくてもyum updateできる
• yum updateでkernelも定期的に更新されるため、変わってほしくないならバージョン固定する必要がある
• 初回起動時に重要なセキュリティアップデートが自動インストールされる
  • yumリポジトリに接続できない環境だと、何回かRetryするため起動が遅くなることも
• "ec2-user"というユーザーが設定済みで、パスワードなしのsudo実行できる
  • EC2インスタンスを作成するときにssh鍵を作成・設定
• Amazon Linux AMI Security Centerで脆弱性情報を確認できる ※

構築

• 個人ユーザーで無料でお試しできるAMIやインスタンスタイプは決まっているので、"無料利用枠"か表記確認忘れずに

AMI選定

• AMI一覧から次の情報をもとに選択する
• OSの種類・32,64bit等を選ぶ
• ルートデバイスがSSDかHDDか（基本はSSDを選ぶとよい）

• "仮想化タイプ"として、"PV"（準仮想化）と、"HMV"（完全仮想化）がある

  • 昔は"PV"の方が性能高いこともあったが、今は"HMV"の方が優位でありスタンダード
  • 拡張ネットワーキングは"HMV"しか対応してない

• 提供されているAMIの種類

• Amazon社や各ディストリビューションから公式AMIが提供されている

  • Amazon Linux, Redhat Enterprise Linux, Windows Server, CentOS, Fedora, Debian, Ubuntu, SUSE…

• Wordpressがすぐ使えるAMIや、その他有志が作成したAMIもある（コミュニティAMI）

  • ただしコミュニティAMIだと悪意のあるツールがインストールされてる可能性もあるので利用には注意

• 信頼できるベンダーが提供する有償AMIもある（AWS Marketplace）

• 自分で1から好きなOSをインストールして構築することも可能

インスタンスタイプ選択

• スペック情報
• vCPU…インスタンスの仮想CPU数
• ECU（EC2 Compute Unit）…相対的な性能指標で、1ECU＝1.0-1.2GHz 2007 OpteronかXeonのCPU能力
• ストレージ…"EBSのみ"とあれば別途ディスクをマウントしてOSをインストール、
  ディスク容量が書かれてる場合はインスタンスストアを指す
  • インスタンスストアは、仮想サーバーと同じ物理サーバーにマウントされたディスク
  • インスタンスストアは、OSシャットダウン時にデータが消えるため、主にキャッシュ・バッファ・スワップ用途で使用する
  • EBSは永続的なストレージで、EC2とは切り離された環境にネットワーク接続でマウントする
• ネットワークパフォーマンス…低・中・高と表記されてるが、同じ"高"なインスタンスタイプでも速度差はある
  • 高だと1Gbpsくらいは出る感じ
• EBS最適化…EC2-EBS間のネットワークに専用スループットが実現される
  • 特にネットワーク通信量が多いサーバーだと効果あり
  • デフォルト有効なのはM4,C4,D2、その他C3なども対応してるが、T2は対応してない

• 拡張ネットワーキング…秒間のパケット数が拡張され、高パフォーマンス・低レイテンシとなる

  • 仮想化タイプが"HVM"で、Kernelにixgbevfモジュールがあり、インスタンスのsriovNetSupport属性が設定済みなことが条件 ※

• インスタンスタイプ

• 種別と世代で名称が決まる（例：T2）※

  • 2015/12現在使えるのは、汎用(T2, M4, M3)、CPU最適化(C4, C3)、メモリ最適化(R3)、GPU最適化(G2)、ストレージ最適化(I2, D2)

• インスタンスタイプによってはインスタンスストア（ストレージ）が付くものもある ※

  • インスタンスが稼働するサーバーに直接物理的に接続されているストレージ
  • ネットワークを経由するEBSと比べて高速
  • サーバーを停止・起動したり、サーバーの物理障害が発生すると、内容は失われる
  • スワップや一時作業ディスク、Cluster系のストレージとして使用するのが適している
  • 複数のディスクがあるインスタンスタイプなら、ソフトウェアRAID0を組むことで高速化も

• T2

  • 最小の一番費用の安いインスタンスが作れる (メモリ0.5GBなt2.nanoなら$0.01 /1時間)
  • 他の多数のユーザーとサーバー相乗りしている
  • 負荷によって規定のCPU上限値を超えて動くバースト機能があるが、バーストできる回数は限られている
  • 侵入テストはnano、micro、smallインスタンスにはポリシー上実行できない

• C3

  • Webサーバー等、CPU性能が求められるサーバーに向いている
  • 拡張ネットワーキングのサポート

• I2

  • 大容量のインスタンスストレージを積んでいる（800GBが複数台）
  • Clusterのストレージとして最適（障害でデータをロストしても、スタンバイがいる）
  • SSDのTRIMコマンドをサポート

• 上位世代が提供されると、古い世代は新規に選択できなくなることがある

• 各インスタンスタイプ、性能の異なる"モデル"から選択する

  • スペックが倍になると費用も倍になる傾向

インスタンスの詳細設定

• インスタンスは2つ以上一気に作成することもできる
• 購入のオプションでスポットインスタンスをチェックつけないと、いわゆる時間課金なインスタンスとなる
• Subnetを指定できるのは作成時のみで、後で変更はできない
  • EC2が立ち上がったあとSubnetを変更したい場合は、稼働中のEC2をイメージ化（AMI）して、そこから新規作成し直す
• 同じ用途のサーバーを、異なるAZのSubnetを配置することで、耐障害性が向上する（マルチAZ）
• "自動割り当てパブリックIP"を使用すると、そのEC2（正確にはネットワークインターフェイス）にグローバルIPが割り当てられる
  • パブリックIPの値を自分で変更することはできない
  • 停止して再起動すると、この自動割り当てパブリックIPは変更される
  • 永続的なグローバルIPアドレスにしたい場合は、EC2作成後にEIP（Elastic IP）を別途割り当てる
• IAMロールは、EC2内からS3等他AWSサービスを利用するときの権限グループ
  • 役割（Web, DB, ...）ごとに同じ名前をつけるとよい
  • 後で変更ができない！ 変更したい場合はSubnetと同じくAMIから作り直し
• "ユーザーデータ"では、EC2の起動時に自動的に実行するスクリプトを定義
  • cloud-initの機能で、シェルスクリプトを書けば初回起動時のみ実行される

ストレージの追加

• EC2で使う永続的なストレージ EBS(Elastic Block Store)をアタッチ（仮想的に外付け）する
  • EC2とは別に管理されているので、別のEC2にEBSを付け替えることもできる
  • 自動的にレプリケートされている
• EBSのタイプにはSSD（汎用,プロビジョンドIOPS）とHDD（マグネティック）がある ※
  • プロビジョンドIOPSは安定した低レイテンシーでDBストレージなどに最適
• ルートデバイスのボリュームサイズは、AMIによって最低サイズが決まっている
• ディスクの追加もできる
  • 特定スナップショット（ディスクイメージ）から複製したのを追加も可能
  • OSとデータを別ディスクにすれば、OS停止せずにデータ用ディスクサイズ変更ができる

リザーブドインスタンス（RI）

• あらかじめ1年、3年分のインスタンス起動を前提とする代わりにディスカウントされる仕組み
  • サーバー起動しっぱなしであれば、オンデマンドよりも平均30%程度安くなる
  • オンデマンドなら不要時に停止することで節約することもできるが、RIだと停止してても料金として計上される
  • 一度RIを購入してしまうと、キャンセルはできない（1年なら1年分支払う必要がある）
  • インスタンスタイプが決まってるため、後で別のインスタンスタイプに変更ができない
• 次の支払い方法があり、ディスカウント率が変わってくる
  • 1年前払いなし、1年一部前払い、1年全前払い、　3年一部前払い、3年全前払い
  • 途中でキャンセルはできない（"前払いなし" でも "全前払い" でも必ず1年分払う必要がある）ので、1年全前払いが一番お得だが、初月に大規模な請求が発生してしまう
• 親アカウントでRIを購入すると、子アカウントで（オンデマンドとして）起動しているインスタンスに対して、自動的に割引料金が適用される
  • 必ずRIが適用される保証はない（他アカウント分に回されてしまう可能性も）
  • それがいやであれば、子アカウントでRIを買うしかない

タグ

• 自由に定義できるタグ
  • "Name"というキーはAWSサービスで名前として扱われることが多く、EC2の場合はマシン名として使うと良い
  • 他に"Environment"として"development", "production"と切っとくと、後で「開発環境のマシンだけ検索する」といったことができる

セキュリティグループ

• EC2サーバーへ入ってくる通信のポリシーを定義する
  • （TCP,UDP,ICMP）・（port）・（接続元IP(CIDR)）で定義する
• 多数作られることが予想されるため、セキュリティグループ名は VPC環境・Port・接続元が見分けつきやすいとよい
• 既存のセキュリティグループから選択もできる
• ここでできるのはInboundの設定のみで、Outboundの設定は別途"セキュリティグループ"設定で行う
• LinuxであればSSH(22)許可されるセキュリティグループを選択しないと警告が出る（OS起動後ログインできない）

キーペアの作成

• Amazon Linux等はデフォルトでec2-userユーザーが作成される
  • sudoでパスワードなしで実行できる
• ec2-userのSSH用の秘密鍵・公開鍵（キーペア）を作成、もしくは既存のキーペアを指定する
• ただしec2-userは全世界で共通なので、別名のユーザーを作りec2-userは削除する運用もあり
• OS起動までに3～5分程度
  • この間にIPアドレスが決まる（管理コンソールから確認できる）

運用

サポート契約

• ベーシック：技術サポート非対応だが無償、開発者：平日日中メールでの技術サポート、ビジネス：24時間電話での技術サポート ※
  • 技術サポートでは各種AWSサービスの問題のトラブルシューティングを受けられる
  • サーバーの物理的な障害の調査も
• 契約変更にはAWSのルートアカウントが必要
• ひと月分契約しなかった場合は日割りとなる

制限

• AWSで作成できるサービスには上限値が設定されている ※
  • 使いすぎやうっかりを防止するため
• 制限緩和のリクエストをフォームから申請する
  • 解除に2，3日かかることも

初期値

• インスタンス数：インスタンスタイプにより異なる ※
  • 小規模なインスタンスなら20、大規模であれば2
• Elastic IP：5
• 他にEBSの容量、Route Table数、等

バックアップ

• EC2のバックアップにはAmazon Machine Image(AMI)と、EBSのスナップショットと呼ばれるものがある
• EBSスナップショット…EBSボリューム（ディスクイメージ）のダンプ
  • スナップショットはS3に保存される
• AMI…インスタンス構成情報＋EBSスナップショット
  • インスタンスに複数のEBSがマウントされてるなら、AMIにはその複数EBSを保持する
• イメージ作成するときにOS再起動がかかる
  • データの整合性を保つため
  • "再起動しない"チェックはあるが、推奨はされない
  • 実際にイメージが作成されるまでに数分かかる

セキュリティ

• AWS全般のセキュリティと対策は次のページにまとめられている https://aws.amazon.com/jp/security/security-bulletins/

障害

• 想定通り動いていない場合、物理的な障害が発生してる可能性も
  • 本当に物理障害かどうかは、サポート問い合わせになる
  • 止められるサーバーなら、stop→startすることで物理サーバーが移動するので、取り急ぎ回避
• EBSがハードウェア障害でデータがロストする可能性もゼロではない
  • 定期的にデータやスナップショットをS3等に保存しとくのが望ましい

メンテナンス

• EC2のメンテナンスのため、再起動等の対応が必要なことがたまに発生する
• 管理コンソールの"イベント"メニューで、対応が必要なインスタンスを確認できる
• AWSからの通知は現状メールのみ
  • それ以外の通知をさせたい場合、自前でEC2のAPIを呼んで取得する必要がある
• 対応が必要なものとして、"インスタンスリブート"、"システムリブート"、"リタイア"がある ※
• インスタンスリブート
• インスタンスのリブートが必要となる
• 予定された日時に自動的にインスタンスがリブートされる
• それよりも前に手動でリブートした場合は、その後自動でリブートされることはない
• システムリブート
• EC2の物理サーバーもしくはXenのメンテナンスのため
• 予定された日時に自動的にリブートされる
  • リブート時間は2～10分程度
• 自動でリブートされたくない場合は、事前にインスタンスをstop→startして別の物理サーバーに移動させる
• リタイア
• ハードウェアの不調で、その物理サーバーが使用不能となる
• 予定された日時にEC2がstopされてしまう
  • インスタンスストレージ（≠EBS）の内容は破棄されてしまう
• 予定日時より前にstop→startして別の物理サーバーへ移動しないといけない

その他

• EC2内から http://169.254.169.254 にwebアクセスすると、自分のEC2の情報が取得できる
• AWS CLIを叩きすぎると制限がかかる

ELB

概要

• TCP,SSL(L4)と HTTP,HTTPS(L7)のバランシングをサポート
  • 負荷分散はラウンドロビンのみ
  • URL, cookie, HTTPヘッダでの振り分けはできない
• 負荷に応じてスケールアップ/スケールアウトする
  • ただしスケールするまでに数分程度かかるので、突発的なアクセスがあるとスケールが間に合わないことも
  • Business/Enterpriseのサポート契約をしてれば、Pre-Warming（事前にスケール）させられる
  • 意図的にELBへアクセス負荷をかけてスケールさせることもできる（が、アクセスする分 ELB・EC2で余計な通信費用が発生）
• 固定のグローバルIPは割り当てされない・できない（スケール時にIPが変わる）
  • 独自ドメインで運用する場合に DNS設定にてAレコード指定ができない
  • Route53への委任かCNAMEにて設定 ※詳しくはRoute53の項を参照
• DSR(Direct Server Return)には対応しない

構築

• SubnetにELBを設置すると、全体で(最低でも)8IP確保してしまう（＋Subnetも5IP消費）
  • そのためELBを設置するSubnetのCIDRは /27以上でないといけない
• SubnetにはInternet Gatewayがアタッチされてる必要がある
• 複数AZにいるEC2を対象にする場合、それぞれのAZでSubnetを作成する
• プライベートSubnet内のEC2をバランシングするInternal ELBも作れる
  • この場合ELBはグローバルIPを持たない
  • SubnetにInternet Gatewayがアタッチされてなくても設置可能
• "クロスゾーン負荷分散の有効化"をしないと、AZ間でEC2の台数に偏りがあった場合、均等にバランシングされない
• クライアントとELB間のセッションは60秒間維持
  • WebサーバーのKeepAliveは有効、KeepAliveのTimeoutは120秒が推奨
• ELBを経由したEC2でのアクセス元IPはELBのIPとなる
  • L7(HTTP,HTTPS)の場合、X-Forwarded-ForヘッダーにクライアントIPが記載される
  • L4(TCP,SSL)の場合、Proxy Protocolを有効にすればクライアントIPはわかる ※有効にするにはCLIからのみ設定可能

運用

• 以前は、ELB配下のEC2をstopしてELB上で"Out Of Service"になったあとにEC2をstartさせても自動的に"In Service"にならないことがあったが、今は解消された ※
• 1カ月起動してるだけでおよそ$20の費用 （＋通信データ量によっての従量課金）

Route53 (DNS)

• ELB, S3, CloudFrontのグローバルIPは動的に変わる（Aレコード指定ができない）
• 独自ドメインでアクセスできるようには、CNAMEでELBのDNS名を指定するか、NSレコードでRoute53に委任する
  • CNAMEではホスト名を持たないZone Apex（www.example.comではなくexample.com）には未対応
  • CNAMEはDNSクエリが二回発生してしまうので効率が悪い
  • Route53の場合、Aレコードのように見えるAliasレコードにてELB等のDNS名を指定する
• AliasレコードはRoute53側でTTLは設定できない
  • ELBのTTLは60秒
• ヘルスチェックにELBを指定可能
• DNS RoundRobin

IAM

AutoScaling

S3

RDS

ElastiCache

• …書くのが間に合わず申し訳ないです
• まだまだ書ききれてない気づきにくいノウハウあるので、需要があれば引き続きまとめていこうと思います
• 引き続きAWS案件も、既存のサービスの拡充もがんばっていきます！