様々なインスタンス

ここで、EC2で使える仮想マシンの種類を見ていきましょう。AWSではこれをインスタンスタイプと呼びます。

インスタンスタイプは、大まかに言ってCPUの処理能力、メモリの量、インスタンスストレージ（仮想マシンがローカルで持っているディスク）の種類や大きさで決まります（参照：Amazon EC2 インスタンスタイプ）。
最も小さく安価なのがマイクロインスタンスで、613MBのメモリと2ECUのCPU性能を持ちます（1ECUは、「1.0-1.2 GHz 2007 Opteron または 2007 Xeon プロセッサの CPU 能力に等しい能力」とされています）。マイクロインスタンスには、アカウント取得後ある程度の無料枠が設定されていますが、CPUの処理能力が状況によって一定しないため（最大2ECUですが、ある程度負荷をかけると抑制がかかることがあります）、使用目的には注意が必要です。学習用にはまったく問題ありませんが、本格的なWebアプリケーションの動作環境として使うには向いていません。

この1年ほどでEC2のインスタンスタイプやオプションは非常に豊富になりました。特筆すべきは、インスタンスストレージとして高速なSSDが搭載されているタイプが登場したり、接続するEBSストレージへの帯域を保証できるProvisionedIOといった機能が登場したことでしょう（これと対になるものとして、EBSにおけるIOPSの保障がありますが、これは次回に取り上げます）。これらはいずれも、EC2の有効範囲を、これまでストレージI/Oのパフォーマンスの観点から利用しづらかった領域まで広げるもので、何よりもエンドユーザーの要望に応えようとするAmazonの姿勢を示すものと言えるでしょう。

セキュリティグループ

セキュリティグループは、その中のEC2インスタンスがどのポートを通じて、何と通信できるかを決めるもので、EC2のインスタンスはいずれかのセキュリティグループに属することになります。

セキュリティグループは、管理コンソールのEC2のページから設定します（図5）。セキュリティグループに対しては、どのポートをそのセキュリティグループ外（この「外」にはAWSのデータセンター内の他のセキュリティグループも含まれます）からアクセス可能にするか、アクセス可能なのはどういったIPアドレスあるいはセキュリティグループなのか、といったことが設定できます。同一セキュリティグループ内のインスタンス同士が、任意のポートを使って通信し合えるようにすることもできます（もちろん、そのインスタンス上のOSがそのポートを開けている必要はあります）。

図5：管理コンソールのEC2ページ（クリックで拡大）

セキュリティグループは、EC2のインスタンスをネットワーク的に保護する基本の単位となるものですが、更にインスタンスをセキュアに保ちたい場合（特にAWSのデータセンター街からのアクセスに対して）には、前回取り上げたVPCを利用すると良いでしょう。

アベイラビリティゾーンとElastic Load Balancing

ここで、EC2のインスタンスを動作させる上でのアベイラビリティゾーンの考え方について説明しておきましょう。アベイラビリティゾーンが何なのかということについては、前回の記事を参照してください。

お試しで1台のインスタンスを立てるだけなら、どのアベイラビリティゾーンを使ってもかまいませんが、高可用性が求められるシステムを構築する場合は、必ず複数のアベイラビリティゾーンにインスタンスを配置するようにします。これは手動で行うことももちろんできますが、一般的にはAWSの別のサービスである、Elastic Load Balancing（ELB）とAuto Scalingを使って自動的に複数のゾーンへの配置が行われるよう設定します。

ELBの設定は、EC2の設定ページから行えます（図6）。ELBはサービスとして提供されるロードバランサであり、負荷に応じて処理能力が自動的に増減します（ただし数分間で負荷が10倍になるような極端なスパイクには対応しきれないことがあるので、注意も必要です）。

図6：ELBの設定はEC2の設定ページから行う（クリックで拡大）

多くの場合、ELBはCloudWatch（図7）とAuto Scalingというサービスと組み合わせて使われます。Amazon CloudWatchは、AWSにおける汎用的なモニタリングツールであり、例えばEC2インスタンスのCPU負荷やトラフィックといったメトリクス値を、極めて簡単に計測・蓄積してくれるサービスです。AutoScalingにはGUIが無く、コマンドラインツールから設定を行うことになります。

図7：ELBやAuto Scalingと組み合わせて使われるCloudWatch（クリックで拡大）

基本的な考え方としては、CloudWatchでのメトリクス値に対してアラームを設定し、例えばEC2インスタンスのCPU負荷が平均50%以上の状態が3分続けば、指定したAMIを使ってEC2のインスタンスを3台立ち上げ、ELBに対して追加する、といった設定を行います。逆に、平均20%以下が10分続けばインスタンスを3台終了させるわけです。

この際に、使用するリージョンが持っているアベイラビリティゾーン数に合わせてインスタンスの増減数を設定しておけば（東京リージョンは3つのアベイラビリティゾーンを持っています）、追加/削除されるインスタンスはアベイラビリティゾーンに対して分散されるので、自動的に冗長性を最適に保つことができるわけです。同一リージョン内の複数のアベイラビリティゾーン間のレイテンシは極めて小さいので、RDSのようなバックエンドのサービスも含めて、冗長性を持ちながら同期的に処理を行うシステムを構築することができます。なお、データベースサービスのRDSでも、Multi-AZオプションを使えば自動的に複数のアベイラビリティゾーンへの配置が行われます。RDSについては、次回詳しく見ていきます。

もちろん、複数のアベイラビリティゾーンを使って耐障害性を保とうとすれば、運用コストがかかることになります。とはいえ、AWSを利用する上での大原則は、「用意されている様々な選択肢から何を選ぶのか、決めるのは自分だ」ということです。セキュリティにしても、可用性にしても、AWSが提供しているのは、ユーザーの要求を様々なレベルで実現するための数多くの選択肢にしか過ぎません。

概して、高度な要求を満たすためにAWSの機能を使えば、AWSを利用するコストは高くなるでしょう。その代わり、例えば開発にかかるコストや時間をぐっと短縮することができるので、多くの場合、同レベルのシステムを構築・運用するためのコストは下がることになるでしょう。とはいえそこに、トレードオフが存在することには変わりありません。AWSがユーザーに提供してくれるのは、トレードオフのバランスをどこに置くのか、選択する自由なのです。