Amazon EC2を管理コンソールから操作してみよう
Management Console
前回の記事では、AWSの歴史や概要を見ました。今回からは、AWSのそれぞれのサービスを紹介していきましょう。AWSのアカウントをまだ持っていない人は、新たに取得して、これから説明する管理コンソールを見ながら読んでいただけると分かりやすいでしょう。
→ Amazon Web Services
AWSを操作する方法は、大きく分けて2つあります。1つは管理コンソールを使ってWebブラウザから操作する方法で、もう1つはAPIやSDKを使ってプログラムから操作する方法です。実際のシステムの構築や運用では後者が重要になってきますが、最初の入り口は前者の方がなじみやすいでしょう。
管理コンソールには、http://aws.amazon.com/jp/の右上にあるドロップダウンリストからログインします。ちなみにこのドロップダウンリストからは課金情報のページにも行くことができます。
管理コンソールは、このようになっています。
左上にあるドロップダウンリストからは、AWSの各種サービスの管理画面に飛ぶことができます。ここでは、自分がよく使うサービスへ飛ぶボタンを登録して、使いやすいようにコンソールをカスタマイズすることもできます。まずは、EC2のボタンを追加しておきましょう。
EC2の概要
さあ、それではEC2について見ていくことにしましょう。
一言で言えば、EC2は仮想マシンを時間単位で貸してくれるサービスです。主にLinuxやWindowsをOSとして、AWSのデータセンター内に仮想マシンを立ち上げ、インターネット経由でLinuxならSSH、Windowsならリモートデスクトップで接続し、ローカルのマシンと同様に使うことができます。
管理コンソールのEC2の画面でリージョンを選択し、Launchボタンをクリックすれば、EC2インスタンスを立ち上げるためのウィザードが開きます。このウィザードに沿って手順を踏んでいけば、数分もかからずに仮想サーバーが使えるようになるわけです。
この手順の中で設定できる項目は多岐にわたります。その中でも特に重要な項目を、この後紹介していきましょう。
- 起動ドライブのイメージの「AMI」
- EC2インスタンスのネットワーク接続を制御する「セキュリティグループ」
- EC2インスタンスの場所を制御する「アベイラビリティゾーン」と「リージョン」
AMI = Amazon Machine Image
EC2インスタンスの起動時には、Amazon Machine Image、略してAMIを選択します。（図3）。AMIは大雑把に言えば、EC2インスタンスの起動ドライブの内容をテンプレート化したものです。例えばAmazon LinuxのAMIの場合、その中にはFedoraをベースにカスタマイズされたLinuxの起動ドライブのイメージが入っており、インスタンスの起動時には仮想マシンの起動ドライブにAMIの内容がコピーされ、仮想マシンがブートされることになります。
例えるなら、AMIとEC2のインスタンスとの関係は、オブジェクト指向言語におけるクラスとインスタンスの関係のようなものです。AWSのデータセンターのサーバー群は、メモリ空間に当たると考えてもらえば良いでしょう。1つのクラスからは、いくつものインスタンスを生成することができます。
EC2を使い始めたときに悩むのが、「AMIがたくさんありすぎて、どれを使えば良いのか分からない」という点かも知れません。AMIは、ユーザーがカスタマイズして独自に作成したものを公開することもできるため、非常に多くの種類が登録されています（図4）。
ただし通常の場合は、LinuxであればAWS自身によってメンテナンスされているAmazon Linuxや、Ubuntuの公式のAMIを使えば良いでしょう。Windowsの場合は、Microsoftの公式のAMIがあります。Windowsの公式AMIには、OSのみのものもあれば、IISやSQL Serverがインストールされているものもあります。
また、AMIには32bit/64bitアーキテクチャの区別と、root device（起動ドライブ）がEBSベースかインスタンスストレージベースかといった区別があります。現在では、32bitアーキテクチャのAMIを利用しなければならない理由はほとんどありません（32bitアーキテクチャを選択する必要があるのは、インスタンス上で動かすアプリケーションが32bit環境でしか動かない場合だけでしょう）。
root deviceについては、通常はEBSのものを選択しておけば良いでしょう。EBSベースのインスタンスは、使わなくなった場合にそのまま停止させておくことができますが（停止中に生ずる課金はEBSのストレージ容量の分だけです）、インスタンスストレージの場合は、インスタンスは終了させることしかできません。
通常のPCに例えるなら、前者はPCの電源を切ってそのまま置いておくことに、後者はPCを完全に廃棄してしまうことに相当します。インスタンスストレージをベースのAMIは、起動が速い（すなわちスケールアウトが高速に行える）という利点があるので、後に取り上げるAuto Scalingと合わせて使う場合にメリットがあります。
AMIのカスタマイズ
公式のAMIから立ち上げられるインスタンスを、実運用のシステムでそのまま使うことはあまり多くありません。EC2のインスタンスも障害を起こすことがあるので、通常はアプリケーションなどをインストールしたカスタムのAMIを作成し、そのAMIからインスタンスを起動しさえすれば、すぐにアプリケーションが利用できるようにします。
AMIのカスタマイズはそれほど難しくありません。特にEBSベースのAMIの場合、基本的には必要なアプリケーションやライブラリをインストールしてからいったんインスタンスを停止しておき、Management Consoleのポップアップメニューで「Create Image」を選択するだけです。こうして作成したカスタムのAMIは、その後EC2インスタンスを立ち上げる際のAMIの選択画面で「My AMI」に表示されるようになるので、すぐに利用できるようになります。
AMIのカスタマイズは、AWSを利用する上で非常に重要です。この後取り上げるAutoScalingを使って冗長性を持たせたシステムの構築においても、自動的にインスタンスを立ち上げたり終了させたりするために、カスタムのAMIを用意することが必要になります。
様々なインスタンス
ここで、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がそのポートを開けている必要はあります）。
セキュリティグループは、EC2のインスタンスをネットワーク的に保護する基本の単位となるものですが、更にインスタンスをセキュアに保ちたい場合（特にAWSのデータセンター街からのアクセスに対して）には、前回取り上げたVPCを利用すると良いでしょう。
アベイラビリティゾーンとElastic Load Balancing
ここで、EC2のインスタンスを動作させる上でのアベイラビリティゾーンの考え方について説明しておきましょう。アベイラビリティゾーンが何なのかということについては、前回の記事を参照してください。
お試しで1台のインスタンスを立てるだけなら、どのアベイラビリティゾーンを使ってもかまいませんが、高可用性が求められるシステムを構築する場合は、必ず複数のアベイラビリティゾーンにインスタンスを配置するようにします。これは手動で行うことももちろんできますが、一般的にはAWSの別のサービスである、Elastic Load Balancing（ELB）とAuto Scalingを使って自動的に複数のゾーンへの配置が行われるよう設定します。
ELBの設定は、EC2の設定ページから行えます（図6）。ELBはサービスとして提供されるロードバランサであり、負荷に応じて処理能力が自動的に増減します（ただし数分間で負荷が10倍になるような極端なスパイクには対応しきれないことがあるので、注意も必要です）。
多くの場合、ELBはCloudWatch（図7）とAuto Scalingというサービスと組み合わせて使われます。Amazon CloudWatchは、AWSにおける汎用的なモニタリングツールであり、例えばEC2インスタンスのCPU負荷やトラフィックといったメトリクス値を、極めて簡単に計測・蓄積してくれるサービスです。AutoScalingにはGUIが無く、コマンドラインツールから設定を行うことになります。
基本的な考え方としては、CloudWatchでのメトリクス値に対してアラームを設定し、例えばEC2インスタンスのCPU負荷が平均50%以上の状態が3分続けば、指定したAMIを使ってEC2のインスタンスを3台立ち上げ、ELBに対して追加する、といった設定を行います。逆に、平均20%以下が10分続けばインスタンスを3台終了させるわけです。
この際に、使用するリージョンが持っているアベイラビリティゾーン数に合わせてインスタンスの増減数を設定しておけば（東京リージョンは3つのアベイラビリティゾーンを持っています）、追加/削除されるインスタンスはアベイラビリティゾーンに対して分散されるので、自動的に冗長性を最適に保つことができるわけです。同一リージョン内の複数のアベイラビリティゾーン間のレイテンシは極めて小さいので、RDSのようなバックエンドのサービスも含めて、冗長性を持ちながら同期的に処理を行うシステムを構築することができます。 なお、データベースサービスのRDSでも、Multi-AZオプションを使えば自動的に複数のアベイラビリティゾーンへの配置が行われます。RDSについては、次回詳しく見ていきます。
もちろん、複数のアベイラビリティゾーンを使って耐障害性を保とうとすれば、運用コストがかかることになります。とはいえ、AWSを利用する上での大原則は、「用意されている様々な選択肢から何を選ぶのか、決めるのは自分だ」ということです。セキュリティにしても、可用性にしても、AWSが提供しているのは、ユーザーの要求を様々なレベルで実現するための数多くの選択肢にしか過ぎません。
概して、高度な要求を満たすためにAWSの機能を使えば、AWSを利用するコストは高くなるでしょう。その代わり、例えば開発にかかるコストや時間をぐっと短縮することができるので、多くの場合、同レベルのシステムを構築・運用するためのコストは下がることになるでしょう。とはいえそこに、トレードオフが存在することには変わりありません。AWSがユーザーに提供してくれるのは、トレードオフのバランスをどこに置くのか、選択する自由なのです。
【参照リンク】
＜編集部より＞ 図7の説明文に一部誤りがあったため、修正しました。（2013.02.14）
