EC2は、AWSマネージメントコンソールからクリック1つでインスタンスを起動できる、非常に便利なクラウドサービスである。一方でとても簡単に利用できることから、全ての制限が取っ払われ、自分の思い通りのまま自由にリソースを使用できるサービスだというような錯覚に陥りがちだ。EC2も元を辿ればデータセンターの中にある物理マシンである。使用する際にはいくつかの注意すべき点が存在する。

サービスで使用する際にTインスタンスは使わない

T2インスタンスは、AWSの公式説明によると「ベースラインを超えてバーストする能力がある CPU パフォーマンスのベースラインを提供する、バーストパフォーマンスインスタンスです」とある。しかし実際は、データセンター内の同一物理サーバ上に収納されている他のインスタンスが実験用途等で使用され、バースト上の負荷がそのインスタンスに掛かった場合は、自分のインスタンスにも影響が出る可能性がある。したがって商用サービス等の安定した運用が求められる利用方法の場合にTインスタンスを使用することはおすすめしない。

バックアップを用意しよう

インスタンスが落ちたり、リージョンごとサービスダウンする可能性もゼロではない。24時間365日稼動しているように見えるクラウドサービスにもダウンタイムは確実に存在する。少なくともアベイラビリティゾーンを分ける、可能であれば他のリージョンにもバックアップを取るなどの障害対策はしておこう。

古いインスタンスは使わない

仮想環境、仮想OSといえど元はデータセンターにある物理サーバである。古くなれば電源やHDDなどが故障するリスクも高まる。実際にハードウェアに異常が起こり、EC2のインスタンスが急に応答しない、インスタンスが落ちるなどの現象が発生することがあるようだ。したがって、古いインスタンスはなるべく使わず、M3を使うぐらいならM4を、C3を使うくらいならC4を使おう。ちなみにインスタンスに障害が発生した場合、Auto Recovery機能をONにしていれば、自動で再起動される。

リソースは枯渇する

仮想環境、仮想OSといえど元はデータセンターにある物理サーバである。用意しているリソース量が全て使用されればリソースは枯渇する。実際に東京リージョンでは、年末年始などの多くの企業がイベント利用を行うシーズンに、特定のインスタンスタイプが起動できないことがあるようだ。またリソースの枯渇だけでなく、メンテナンスが原因で新たなリソースが確保できないということもあり得る。どうしてもリソースの確保が必要であれば事前に確保しておき、実際に使用するまでインスタンスをStopしておくなどの対応が必要である。リザーブドインスタンスの利用も検討したい。

バージニアリージョンは諸刃の剣

バージニアリージョンは、AWS創業の地。新しいサービスが一番に投入されるリージョンでもあり、リソース量も他のリージョンと桁違いに大きい。しかし一方で施設の老朽化が進んでいるからか異常なほどサービスダウンが多い。日本でEC2を使ったサービスを展開をする際に、わざわざバージニアリージョンを使用するメリットはあまり無いが、リソース量が大きいためバックアップリージョンとして利用する価値はあるだろう。レイテンシーを気にするのであれば、リソース量は劣るが物理距離が近い、シンガポール等のアジアパシフィック地域のリージョンも候補に入れたい。

上限引き上げはお早めに

AWSのサービスには、それぞれサービス制限（スロットリング）が適用されており、例えば、EC2は初期状態では最大20台までしかインスタンスを起動できない設定となっている。上限値以上にリソースを使用する場合はサポートプランに加入の上、サポートに必要なリソース数とその理由を付けて上限値の引き上げや撤廃を申請する必要があるが、上限値の変更が必要な理由が不明確であったり必要以上のリソースを要求すると断られる場合もあるので、少なくとも処理に3営業日以上掛かることを見越して、早めに上限引き上げを申請しておいたほうがよいだろう。

Auto Scaleは過信しない

Auto Scaleはリソース量に合わせてインスタンス量を自動で調整してくれるとても便利なサービスである。しかし、閾値を超えたことを検知して新たなインスタンスを立ち上げるまで数分を要する。したがってバースト的な負荷には対応できない。瞬間的なアクセスが予想されるのであれば、Auto Scaleは使わずにあらかじめ手動で、一定数のインスタンスを立ち上げておこう。

CPU使用率が定常的に30%を超えるのであれば代替策を考えよう

CPU使用率が定常的に30%を超えるのであればもう1つ上のインスタンスに変更するか、同じインスタンスをもう1つ用意しよう。

性能の良いインスタンスで台数少なく運用する方がラク

どのような処理をするかにもよるが、低い性能のインスタンスを大量に並べるよりかは、性能の良いインスタンスを台数少なく並べたほうが運用がラクなことが多い。

EBSのボリュームサイズによってI/O性能は変化する

ディスク容量あまり使わないからと最小限のディスク容量しか確保していない状態で、大量のディスクアクセスが発生した場合に期待したディスクの読み書き性能が出ないことがある。汎用（SSD） ボリュームのパフォーマンスはボリュームサイズによって変化するように設計されており、ボリュームサイズが大きければ大きいほど、良いI/O性能が与えられる。一定量のディスクアクセスが発生する可能性がある場合は、1TBなど大きめのボリュームサイズを割り当てておくほうがよい。

とりあえずCPU利用率を見ていればOK

CloudWatchはいろいろな項目があるので、どの項目を確認すればEC2が正常であるのか判断に困るかもしれない。そんなときは取り敢えずはCPU使用率だけでも見ておこう。

「なんか遅い」というときは…

まずはCloudWatchを参照してサチっている項目を探そう。
+ Tインスタンスを使用している場合は、CPUクレジットが枯渇していないか確認する
+ 汎用SSDを使用している場合は、ボリュームサイズとインスタンスに割り当てられたIOPSの上限を確認する
+ AZ間の通信が発生している場合は、AZ間のレイテンシが発生している場合がある。また、インスタンスタイプによるネットワーク帯域の上限も確認する。

あと、よくある質問をきちんと読む！
4年間SAをやった中で、よくされる10の質問と回答

そのほかに注意すること

• インスタンスを停止状態から実行状態に移行するたびに 1 時間分のインスタンス時間が課金される 。
  • [追記] 2017年10月12日から秒課金がスタートしている。
• インスタンス起動後に設定変更できない項目が存在する。VPCやサブネット、Roleなどは後から変更できない。Roleは使う予定がなくても取り敢えず作成しておいたほうが良い。
  • VPC
  • サブネット
  • プライベートIP
• Amazon Linux AMIには、SWAPは用意されていない。