EC2 概要

サーバーインスタンスだが、他のサービスもEC2ベースとしており、AWSの基本中の基本サービス。

構成要素

EC2サーバー本体
EBSディスク
ENIネットワークインターフェース。複数アタッチ可能だが、最初のENIのIPは固定になるので、作成時に指定し忘れるとDHCPの割当となる

EC2 ライフサイクル

起動、停止、terminateは削除なので間違わないように

DNATを作成

#!/bin/bash
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
sudo sh -c "echo 0 >  /proc/sys/net/ipv4/conf/eth0/send_redirects"
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 目的のIP:目的のポート
sudo iptables -t nat -A POSTROUTING -j MASQUERADE
sudo service iptables save

EBS

Elastic Block Storeの略。スナップショット機能など多彩な機能がある。通常インスタンスストレージは停止したら消えるのであまり使わずEBSがEC2のメインストレージとなるだろう。EBSは同一AZでのインスタンスにしかアタッチできない。スナップショットから別AZへコピーできる

EBSの種類

GP2は容量を増やすとパフォーマンスが伸びる。Provisioned IOPSは自分でパフォーマンスを指定できるが、増やしすぎると値段が上がるので注意。

AMI

マシンのOSイメージのこと。マイクロインスタンスであれば、RHELもWindowsも無料の枠内に収まるとのこと。「free tier eligible」とあればマイクロインスタンスとの組み合わせで無料。自分でAMIを作ることが可能で、実用上は公式提供のAMIをカスタマイズして自分のシステムのベースを作る。仮想マシンの方式がhvmとparavirtualがあるが、今後の主流はhvmであるのでhvmベースで作成すべし!

EC2初期設定

Cloudinit

起動時に設定などを実施できるcloud-init(yml)かシェルスクリプトを設定できる。APIからも設定可能。

コンソールから入れる場合

#!/bin/bash
#TIMEZONE JST
/bin/cp -f /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
yum install -y postfix
yum install -y mysql-server
yum install -y nginx
# start service
/etc/init.d/postfix start
/etc/init.d/mysqld start
/etc/init.d/nginx start
# enable service auto start
chkconfig --level 345 postfix on
chkconfig --level 345 nginx on
chkconfig --level 345 mysqld on

EC2インスタンスの作成からログインまで

無料枠を超えないようにインスタンスはT2.micro、その他はデフォルトで進める。秘密鍵のペアはpemファイルとなるが、puttygenでインポートしてからputty形式のファイルにして、ec2-userでログイン成功

インスタンスの作成手順詳細

  1. AMIを選ぶ
  2. 6. Configure Security GroupでSGを指定する

インスタンスタイプ

名称備考
t1,t2CPUがバースト可能。しかし低コストなので常時CPUが必要ならC1,C2を
c1,c2CPUに重点を置いたタイプ。
r3データベース向け

Elastic IP

静的なIPでインスタンスにひもづけることができる。起動していないインスタンスにEIPを確保しておくと課金対象。ここを見るとPrivate IPとの紐づけも見られる。 一応使わないでも再起動しなければ起動時に動的に割り当てられたpublic IPでアクセスできる。PublicIPの自動割り当て機能は起動時のみ利用出来る為、起動後に付与したくなった場合にはEIPを利用する必要がある。

ELB

Elastic Load Balancing。インスタンスを複数ぶら下げて振り分ける。異常からの復帰時はデフォルトだと最低300秒かかるので気長にまつか、設定を変更する。それぞれのAZで等しい台数とスペックをぶら下げるのが基本。

Internal ELB

名前解決はpublicなDNSで行うため、利用側にインターネット接続必要。またスケールアップ時にIPが変わるため、直接IPでアクセスしてはいけない。

ELB負荷対策

ELBのスケールアップ・スケールアウトはAWS側で勝手にやってくれる。配下でインスタンスが全滅していると勝手に一個になる。復帰すると2個になる。apache benchをやり続けるとそのIPだけタイムアウトになってしまう!なにか見ているのかも?

こちらで負荷監視する項目はCloudWatchから取得できる処理数や処理待ちなどのデータ。

スティッキーセッション

クラウド時代にはあまり好ましくはないが、特定のサーバーに振り分けるスティッキーセッションの設定もできる。ELBの説明欄から維持設定をクリック

元アクセスのリクエストヘッダ

HTTP_X_FORWARDED_FOR
HTTP_X_FORWARDED_PORT
HTTP_X_FORWARDED_PROTO

ELBのサブネット

所属するサブネットに最低8IPの空きが必要。

EC2 オートスケール

負荷状況に合わせて増やしたり、一定数以上の稼働を保証させることができる仕組み。もととなるAMIを使って起動するので、そのAMIを作成しておく。起動設定でアプリのデプロイをしてELBに関連づけ(AutoScaleの設定画面から既存ELBを選択)しておくとよい。

Security Group

HTTPの外回りと内回り

同じインスタンスにアクセスする場合PrivateIP指定の場合は内回りとなり、SGのアクセス元としてSGを持っていることが指定できる。Global IPを指定した場合は外回りのアクセスとなり、一般的なIP制限と同じようにIP指定で許可しないとつながらない。

デフォルトSG

基本的にプライベート内部は全部の通信が許可されるデフォルトSGが存在する。

特に支障がない限りこれを各インスタンスにつけておくことをお勧めする。 デフォルトSGを持っているのものを全部許可する設定になっているので

EC2複製

AMIを作成して複製

固定PrivateIPだと既存EC2消さないとダメ

EBSボリューム複製して既存インスタンスにアタッチ

これは複製ではなく障害復旧だな。

EBSボリュームを複製して手動マウント

上記2パターンがうまくいかないときの最終手段。


トップ   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS