徹底解説! 初めてでも分かるAmazon Web Services【第2回】
AWSの仮想サーバ「Amazon EC2」と、使える周辺サービス
AWSの仮想サーバである「Amazon Elastic Compute Cloud」(Amazon EC2)とともに、その周辺サービスである「Elastic Load Balancing」(ELB)、「Auto Scaling」「VM Import/Export」を解説する。
これまでの連載
- 第1回:AWSを導入する上で知っておきたい基礎知識
- 第2回:AWSの仮想サーバ「Amazon EC2」と、使える周辺サービス
- 第3回:AWSのストレージサービス「Amazon S3」と、その周辺のサービス
- 第4回:AWSの3大ネットワーク機能を理解する
連載インデックス:徹底解説! 初めてでも分かるAmazon Web Services
Amazon Elastic Compute Cloud
「Amazon Elastic Compute Cloud」(Amazon EC2)とは、一言でいえば仮想サーバである。AWS Management Consoleと呼ばれるAWSのWebサービス管理画面で好みの条件を設定し、画面上のボタンをクリックするだけで、数分後にはサーバが起動され利用することができる。
オンプレミスではなかなか難しいサーバの丸ごとバックアップ、稼働開始後の構成や稼働場所の変更も容易で、サーバ仮想化の恩恵を最大限に受けられる。
ユーザーにはサーバの管理者権限が与えられるので、自由にサーバを設定することができる。Amazon EC2はAmazonの実績あるデータセンターとネットワークで稼働しており、その可用性は99.95%を誇る。
インスタンス
Amazon EC2は数日や数時間ではなく数分単位で能力を増減させられるとともに、仮想サーバ(インスタンス)は一から数百以上と、幾つでも同時に動作させられる。これはWebサービスAPIでコントロールされるため、ユーザーはAWS Management Consoleから手動もしくはプログラムによってAPIを発行し、自動的にインスタンスを増減したり、停止、再起動したりできる。
また、AWSには、サードパーティーから提供されているAmazon Machine Image(AMI)というサーバイメージがある。AMIはOSの種類など目的に応じて選択でき、CPUコア数やメモリ容量、ディスク容量を設定するだけで使用を開始できる。AMIには、仮想CPUコア数が1つのものから80を超えるもの、メモリ容量が最小640Mバイトのものから240Gバイトを超えるものまで、CPUコア数とメモリ容量の組み合わせでは多様なラインアップがそろっている。
提供されているOSには次のような種類がある。
| AWSが提供する商用OS | Windows Server Red Hat Enterprise Linux Oracle Enterprise Linux SUSE Linux Enterpriseなど |
|---|---|
| コミュニティーOS | Debian Ubuntuなど |
| AWS独自のOS | Amazon Linux(Red Hat Enterprise Linuxと互換性が非常に高い) |
AWS Market Placeと呼ばれるサードパーティーが配布や小売りを行っているサイトでは、CentOSなども提供されている。
小規模なWebサイトの運用から、クラスタコンピュートを形成するような大規模な解析処理まで、用途に応じて多種多様なインスタンスを選択できる。また、Elastic IP(EIP)と呼ばれるグローバル固定IPを付加することも可能だ。
前述のようにAmazon EC2のインスタンスは、ユーザーにルートアクセス権(管理者権限)があり、Linuxの場合はsshを、Windowsの場合はリモートデスクトップ接続してログインし、オンプレミスのサーバと同様に設定・運用ができる。
バックアップはAMIを作成することで、サーバを丸ごとバックアップできる。AMIの作成はサーバを止めずに行うことも可能である。
料金
支払い形態は大きく3種類ある。
まず、時間単位で利用料を支払うオンデマンドインスタンス。スペックと利用時間に応じて料金が決まるので、ハードウェアのプランニング、調達や管理の煩雑さから解放される。必要に応じて調達できるので、アクセスの急増に備えて余剰リソースを購入しておく必要がない。
次に、予約金を支払うリザーブドインスタンス。インスタンスの長期利用を見込んでいる場合は、予約金を支払うことで、オンデマンドインスタンスよりも時間単位の料金が割り引かれる。予約金のプランは利用量によって3プランあり、先払いする予約金と実際に支払う時間単位の利用料金とのバランスを取ることができる。また、購入した利用分が不要になった場合は売却することもできる。
そして、AWSの余剰リソースをユーザーが入札するスポットインスタンス。AWSがAmazon EC2の未使用の処理能力を売り出し、この売り出しにユーザーが価格を付けて支払う形態である。AWSが需要と供給に基づきスポット的に価格を決め、これにユーザーの値付けが上回っている限り、ユーザーはインスタンスを利用することができる。価格が安定しないため、定期もしくは長期的な利用よりも、短期の解析処理や緊急度の高くないバッチ処理などに利用すると利用料金を抑えることができる。
続いて、Amazon EC2の周辺サービスを紹介する。
Elastic Load Balancing
AWSでロードバランサの役割を果たすのが「Elastic Load Balancing」(ELB)である。ELBを使用すると、単一もしくは複数のアベイラビリティゾーンに配置された複数のAmazon EC2へのトラフィックを分散することができる。これによって、耐障害性に優れた運用を可能にし、流入するトラフィックに応じた負荷分散能力を提供する。
ELBはAmazon EC2インスタンスの状態を検出することができる。動作が適切でないインスタンスが検出されると、このインスタンスに対するトラフィックの割り当ては行わない。ELBによるトラフィックの分散は、健全(動作が適切)なインスタンスにのみに行う。
また、ELB自身、流入するトラフィックの負荷に応じて自動的にスケーリングする。ELB自らが1台当たりのスペックアップ/ダウンおよびELBの台数を増減し、キャパシティーを自動的に制御する。AWS Management Console、コマンドラインツール、SDKなどで制御可能で、プログラムによって自動化することもできる。
負荷分散は、Amazon EC2インスタンスのリクエスト数やコネクション数を基に行う。ELBがサポートしているプロトコルはHTTP、HTTPS、TCP、SSLである。SSL通信をする場合は、ELBにSSL証明書を設定でき、SSLアクセスの復号やSSL証明書の集中管理ができる他、オプションのパブリックキー認証を使用してバックエンドのAmazon EC2インスタンスを暗号化する機能を有している。
ELBの利用は、AWS Management Consoleから簡単に開始できる。AWS Management Consoleの「メニューからELBを選択→名前の決定→管理するプロトコルを選択→ELBの配下で処理するAmazon EC2インスタンスを選択→インスタンスが健全とする状態チェックの条件を設定」するだけである。
Auto Scaling
Auto Scalingは一言でいえば、サーバの負荷状態に応じてAmazon EC2インスタンスの数を自動的に増減させる仕組みである。AWSリソース(※)とAWS上でユーザーが実行するアプリケーションをモニタリングするサービス「Amazon CloudWatch」を利用し、インスタンスの稼働状態をモニタリングし、需要が急上昇したときはユーザーが使用中のインスタンスの数をシームレスに増やしてパフォーマンスを維持し、需要が落ち着いてきたときは自動的に減らす。特に、使用量が時間ごとに変化するアプリケーションに最適である。
※ Amazon EC2インスタンス、ELB、Amazon EBSボリューム、Amazon RDSインスタンスなど
Amazon EC2の利用を開始していればAuto Scalingは利用でき、利用開始のために特別な手続きは必要ない。
設定は、開発者用ツールからコマンドラインツールをダウンロードし、コマンドを使用して新しく立ち上がるインスタンスに必要なパラメーター、インスタンス数を増減させる条件を設定する。インスタンス数を増減させる条件を設定できるメトリック(測定基準)としては、CPU稼働率、ネットワーク流量、ディスク利用量がある。
例えば、Amazon EC2インスタンスの平均CPU使用率が70%以上になる際に新たに3つのインスタンスを起動したり、同様にCPUの平均利用率が10%を下回る場合に増やした分のインスタンスを取り除く設定が可能だ。
他には、Amazon EC2インスタンスの数や規模を固定したり、ELBと組み合わせてELBの配下にあるAmazon EC2インスタンスの数が一定数よりも少なくならないようにすることもできる。特に後者は、次のような場合に役立つ。ELBは健全でなくなったAmazon EC2インスタンスに処理を割り振らないように機能する。だが、健全でなくなったAmazon EC2インスタンスを除去し、新たにAmazon EC2インスタンスを起動して配下に置くような機能がないため、このような運用を行いたい場合は、AutoScalingの利用が必須になるだろう。
VM Import/Export
VM Import/Exportは、オンプレミスの仮想マシンイメージをAmazon EC2インスタンスにインポートしたり、元のオンプレミス環境にエクスポートしたりする機能である。
この機能によって、オンプレミスの仮想マシンをAmazon EC2インスタンスとしてすぐにAWS上で利用することができる。また、元のオンプレミス環境に任意のタイミングでエクスポートすることもできる。
インポートできるのは、次のファイルフォーマットだ。
- VMware ESX/ESXi
- VMware Workstation VMDKイメージ
- Citrix XenServer VHDイメージ
- Microsoft Hyper-V VHDイメージのWindows Server 2003/2003 R2/2008/2008 R2
インポートしたインスタンスは、次のファイルフォーマットにエクスポートできる。
- VMware ESX/ESXi VMDK
- VMware ESX/ESXi OVA
- Microsoft Hyper-V VHD
- Citrix XenServer VHD
インポートするには、コマンドラインツールを使用する。Amazon EC2インスタンスとしてどのアベイラビリティゾーンで稼働させるか、どのインスタンスのタイプを適用するかをコマンドラインツールで指定、実行するとイメージファイルが自動的にAWSに転送され、Amazon EC2インスタンスが生成される。インポートが終了したら、インポートしていないAmazon EC2インスタンスと同様に運用することができる。
インポートしたAmazon EC2インスタンスをエクスポートするには、同じくコマンドラインツールを使用する。対象とするAmazon EC2インスタンス、仮想マシンのファイルフォーマット、出力先を指定するだけで自動的にエクスポートされる。エクスポートされたイメージファイルはAmazon Simple Storage Service(Amazon S3)に出力される。このイメージファイルをダウンロードし、オンプレミスのサーバ仮想化インストラクチャーで起動することができる。
オンプレミスのWindows ServerイメージをAmazon EC2インスタンスとしてインポートすると、AWSがこのAmazon EC2インスタンスのためのWindows Serverライセンスキーを用意する。時間単位のAmazon EC2インスタンスの利用料金にWindows Serverを実行するためのライセンス利用料が含まれることになる。インポートしたオンプレミスのWindows ServerのライセンスキーはAmazon EC2インスタンスでは使用しないので、オンプレミス環境内で再利用が可能である。
また、インポートしたAmazon EC2インスタンスをエクスポートすると、Amazon EC2インスタンスに付与されていたWindows Serverのライセンスキーはエクスポート先に含まれないので、エクスポートしたイメージファイルをオンプレミスのサーバ仮想化インストラクチャーで起動する場合は、起動した後に新しいライセンスキーをサイドアクティブ化する必要がある。
Copyright © ITmedia, Inc. All Rights Reserved.
徹底解説! 初めてでも分かるAmazon Web Services
Amazon Web Services(AWS)に関する最新記事はこちら→ Amazon Web Services(AWS) (http://techtarget.itmedia.co.jp/tt/saas/aws/)
この記事の著者
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー