Amazon VPCを使ってWEBサーバを構築しよう!~パート②~

前回に引き続き、今回もAmazon VPCを使ってWEBサーバを構築しよう!~パート②~と題して、お話していきたいと思います。

パート①では、「Public Subnet」のテンプレートを利用してVPCの作成までをおこないました。
パート②となる今回では、「実際にインスタンスを立ち上げてアクセスするまで」を紹介していきます!
なお、前回のパート①の記事は下記を参照してください。

Amazon VPCを使ってWEBサーバを構築しよう!~パート①~

それではさっそく進めていきましょう!

1. EC2のページから「インスタンス作成」で起動ページに移動します。
※今回はAmazon Linuxを利用して立ち上げてみます。
VPC2-01

2. インスタンスタイプの設定を行います。
VPC2-02

3. 「インスタンス詳細の設定」の画面の「ネットワーク」で今回作成したVPCを選択します。「ネットワークインターフェイス」の設定でIP Addressの追加や設定を行います。
VPC2-03

4. ストレージの設定を行います。
VPC2-04

5. インスタンス名などのタグの設定を行います。
VPC2-05

6. 「セキュリティグループ」の設定をしていきます。
VPC2-06

7. 作成するインスタンスの設定を確認し、問題がなければ「作成」をクリックします。
VPC2-07

8. 「キーペア」を設定していきます。
VPC2-08

下記の画面が出ていれば、無事に起動出来ています!
VPC2-09

これで、インスタンスの立ちあげは完了です!
・・・・

ただし!!このままではパブリックIPが付与されていないため接続が出来ません!
VPC2-10

9. まずは、インターネットから接続出来るようにEIP(グローバルIP)を付与します。
左メニューの「Elastic IP」に移動して「新しいアドレスの割り当て」からVPCで利用する新規EIPを取得します。
VPC2-11

10. 次に、先ほど作成したインスタンスに紐付けます。
※ネットワークインターフェイスを指定して紐付けることも可能です。
VPC2-12

※紐付けが成功したかは、「インスタンス」の画面で確認してみましょう。
VPC2-13

11. EIPが設定されているのを確認出来たら、実際に接続して確認してみましょう。
20130329_03_19

12. 次にApacheをインストールして、WEBサーバとしての機能も確認してみましょう。
20130329_03_20

20130329_03_21

それでは、実際にインスタンスのアドレスでブラウザでにアクセスしてみます。
20130329_03_22

できましたか?
これで、無事に表示が確認出来ました!

いかがでしたでしょうか?
今回は「Public Subnet」を利用してのWEBサーバ構築方法を紹介しましたが、
他にも「Private Subnet」や「Public Subnet」と「Private Subnet」の組み合わせ、VPN接続など様々なテンプレートがあります。
また、ELBやRDS・NACLやSecurity Groupでのネットワーク制御などVPCでは使える機能がたくさんありますので、要件に合わせて最適な形を設計して利用していきましょう!

次回は、「Amazon RDS編~ログ管理について~」のレシピになりますのでお楽しみに!


Amazon VPCを使ってWEBサーバを構築しよう!~パート①~

前回まではRoute53を利用したサイト公開ということでお話しましたが、今回はAmazon VPCを使ってWEBサーバを構築しよう!ということで2回にわたってお話していきたいと思います。なお、前回までのRoute53編の記事は以下を参照してください。

Amazon Route53編~サイトを公開してみよう!~パート①~

Amazon Route53編~サイトを公開してみよう!~パート②~

AWSではVPCを利用する事でネットワークセキュリティを高めるなど、自由なネットワーク設計が可能となります。
今回はそんなAmazon VPCの「Public Subnet」でWEBサーバを構築するまで、を2回にわたって説明していきます。
パート①ではまず、VPCを作成するまでの手順を紹介します!

では、さっそく実際にやってみましょう!

1. まず始めに、WEBコンソールにログインしてVPC画面まで移動します。
その後に「VPC ダッシュボード」で「VPCウィザードの開始」を選択します。
VPC1-01

2. 「VPCの設定選択」が立ち上がりますので、「1個のパブリックサブネットを持つVPC」を選択します。
※パブリックサブネットはEIPをアサインして利用する形になります。
パブリックサブネットを利用するメリットとしては、高いセキュリティでWEBアプリケーションを稼働出来る事や、IPアドレスを自由に設計出来る事が挙げられます。
VPC1-02

3. 入力項目を確認して「VPCの作成」をクリックします。(デフォルトの設定で構いません。)
VPC1-03

4. 上記の操作だけでVPCが作成されます。
VPC1-04

VPC1-05

5. 作成が完了したら、左ペインから以下の各項目を選択し、確認をしていきます。

※VPC
VPC1-06

※サブネット
VPC1-07

※ルートテーブル
VPC1-08

※ネットワークACL
VPC1-09

以上でVPCの作成が完了です!

いかがでしたでしょうか?
テンプレートを利用して、とても簡単にVPCが作成出来ました。

次回は、『Amazon VPCを使ってWEBサーバを構築しよう!~パート②~』と題して、実際にインスタンスを立ち上げてみましょう!お楽しみに!


Amazon Route53編~サイトを公開してみよう!パート②~

前回に続きRoute53を使ったサイト公開方法について、お話したいと思います。
なお前回の記事は以下を参照ください。

Amazon Route53編~サイトを公開してみよう!パート①~

Route53を使ったサイトの公開は、S3+Route53を組み合わせることで、スケール設計が不要でより耐久性のあるS3 Webサーバを構築することができます。
S3 Webサーバのメリットとして次のような事が挙げられます。


S3 Webサーバのメリット

 


・スケール不要で大規模なアクセスにも耐えられる
・サーバのセットアップ不要で、直ぐ使うことが出来る
・監視などの運用手順が不要
・容量+転送料のみで利用できるのでEC2などと比較しても圧倒的に安い

といったことなどが挙げられ、静的なコンテンツであれば動画等も含めて配信することが可能です。

それでは実際に、S3+Route53でサイトを公開する方法をご紹介しましょう!

1.ManagementConsoleのServicesからS3を選択します。

2.「Create Bucket」をクリックし、ポップアップウィンドウに対して下記の必要項目を入力し、「Set Up Logging」をクリックします。
20130329_02_01
・Bucket Name:Webサーバとして公開するドメイン名を入力
・Region :アクセスする主なユーザーがいるリージョンを選択

3.S3のログに関する設定です。下記必要項目を入力し、「Create」をクリックします。
20130329_02_02
・Enabled    :S3に対するアクセスログを取得する場合はチェックして下さい。
・Target Bucket :ログを保存するバケット名を選択して下さい。
・Target Prefix :ログに対して付与する設定後が設定出来ます。

4.上記までで作成されたバケット選択し、右側から「Enable website hosting」を選択して必要情報を入力します。
S3の設定は以上で終了です。
20130329_02_03
・Index Document:トップページ(index)のファイルパスを入力
・Error Document :エラーページのファイルパスを入力

5.次にRoute53にて、設定をします。
ManagementConsoleのServicesからRoute53を選択します。

6.メインビューの該当のドメインを選択し、「Go to Record Sets」をクリックします。
該当ドメインに対してCNAMEレコードに対してAlias「No」を選択し、S3のエンドポイントを入力します。
20130458_01_001

以上で、S3を使ったサイト公開が完了です!

2回わたってRoute53を利用したサイト公開方法をご紹介しましたが、いかがでしたでしょうか?
Route53を利用するだけでも簡単にサイトを公開することができますし、さらにS3を組み合わせることでより実用的なWebサーバを構築してサイト公開をおこなうことができます!

是非、今回の記事を参考にして負荷なくサイトを運用しましょう!

次回は、「Amazon VPCを使ってWEBサーバを構築しよう!」ということで、こちらも2回にわたってお話していきたいと思いますので、お楽しみに!


Amazon Route53編~サイトを公開してみよう!パート①~

これまでの記事ではEC2やRDSの立ちあげや設定、S3へのバックアップなどの基本的な設定について一通り記述させて頂きました。

さて今回は、「サーバの立ちあげや基本設定ができたのでサイトを公開してみたい!」といった場合に必要となる設定についてお話します。
サイトを公開するにあたり必要になるのがDNSサービスです。DNSはAWSのRoute53を使って設定することができます。

Route 53の特徴としては以下が挙げられます。
・SLA 100%
・ホストゾーンあたり$1/月以下の安価な料金体系

特に「SLA 100%」というのが非常に魅力的ですね。
ちなみにRoute53という名称は、DNSサーバがクエリの送受信に使用する「UDPポート53」に由来しています。

ドメインの取得自体はお名前.comなどのサービスを利用する必要があります。
以下にお名前.comで取得したドメインをRoute53で利用する手順を記述します。

1.ManagementConsoleのServicesから「Route53」を選択します。

2.メインビューの「Create Hosted Zone」をクリックして右側に表示されるフォームに対して以下の必要項目を入力し、ページ右下の「Create Hosted Zone」をクリックします。

・Domain Name:設定するドメイン名
・Comment  :管理用のコメント。日本語の利用が可能です。
20130329_01_01

3.設定が完了すると、ドメイン一覧に登録したドメイン名が表示されます。

4.ドメイン名をクリックするとページ右「Hosted Zone Details」に詳細が表示されます。

・Domain Name :設定したドメイン名
・Hosted Zone ID :AWS上での管理用のID
・Record Set Count:登録済みのレコード数
・Comment :登録時に入力したコメント
・Delegation Set  :ここに表示される4つのネームサーバ情報をお名前.com等に登録する必要があります。
20130329_01_02

5.ドメインを選択している状態で「Go to Record Sets」をクリックします。

6.作成した時点でNS/SOAそれぞれ1つ登録されていることが確認できます。
「Create Record Set」をクリックして新しいゾーンの設定を行います。
20130329_01_03

7.Nameに対して無記入・www・*など必要な名前を入力します。
20130329_01_04

Typeに対して「A – IPv4 address」を選択します。
AliasはEC2のEIP等IPの場合は「No」、ELBを利用する場合やS3のエンドポイントを設定する場合には「Yes」を選択します。

○Noの場合
TTLは特に短時間に反映が必要なければ標準の300秒(5分)となります。
ValueはIPアドレスを入力します。

○Yesの場合
Alias Targetに対してELBのドメイン名やS3のエンドポイントを設定します。アカウント内の情報であれば、入力フォームを選択することで自動的に候補が表示されます。
20130329_01_05

以上でAWSのManagementConsoleで設定する内容は完了です。
続けて以下に、お名前.comでの設定方法を説明します。
※ネームサーバ情報が更新されるまで数時間から最大72時間程度かかる場合があります

お名前.comにログインし、「ネームサーバの変更」より設定したいドメインを選択し”ネームサーバー情報を入力”に対して4つのDelegation Setで表示された4つのネームサーバを入力して登録します。
20130329_01_06

ネームサーバの変更が反映されるとRoute53で設定した情報が反映されていることが確認できると思います。以後の変更はRoute53でおこない、TTLの時間以内に反映されるようになります。

いかがでしたでしょうか?

次回も引き続き、「Amazon Route53編~サイトを公開してみよう!パート②~」と題してお話していきますので、お楽しみに!


Amazon RDS編~Multi-AZでできること~

前回の記事に引き続き、今回もAmazon RDS編です!
今回はMulti-AZというものについてお話したいと思いますが、その前にAmazon RDSに関する情報をご紹介します。

先日、米国Amazon Web Services(AWS)は、Amazon RDSの新機能追加を発表しました。
ストレージの容量が最大3TBまでとなり、さらにDBインスタンスの処理性能が最大3万POIPS(Provisioned IOPS)まで引き上げられたそうです。
これにより、今後も処理性能の向上および、オプション機能の充実をはかっていくとのことです。
AWSは、サービス全体において新機能の追加がめまぐるしくおこなわれているので日々、チェックをおこなっていく必要がありますね!

というわけで本題に入りまして、今回はMulti-AZの設定について記述したいと思います。
そもそもMulti-AZというのはAmazon RDSの中のオプションの1つで、RDSのDBインスタンスの冗長性を高めるための機能です。
このオプションを利用すると一方のAvailability Zoneに属するDBインスタンスとは別に、異なるAvailability Zoneに属するDBインスタンスが作成され、ホットスタンバイとして扱われるようになります。

これにより、アクティブなインスタンスに問題が生じた場合、その時点で自動的にフェールオーバがおこなわれ、サービスを継続することが可能となります。(通常フェールオーバには3分程度かかります。)

20130322_02_01

それではさっそく、DBインスタンスでMulti-AZの設定をおこなってみましょう!

1. AWS管理コンソールにログインしてサービスで「RDS」を選択、下記画面を開き左メニューの「DB Instances」をクリックします。
20130621_01_01

 

2. DBインスタンス一覧から対象のDBインスタンスを右クリックし、「Modify」を選択します。
20130621_01_02

 

3. 「Multi-AZ Deployment」の項目をYesとします。
なお、この時、即時反映としたい場合は「Apply Immediately」の項目にチェックを付け、「Continue」をクリックします。
20130621_01_03

 

4. 設定項目を確認して、「Modify DB Instance」をクリックします。
20130621_01_04

 

5. DBインスタンス一覧を確認すると、対象のDBインスタンスの再起動が開始されていますので「Status」の項目を確認し、
「available」となるまで待ちます。(数分はかかります)
20130621_01_05

 

6. これで、設定作業は完了です!
「Description」タブをクリックし、「Multi-AZ Deployment」が「Yes」になっていることを確認してください。
20130621_01_06

 

設定が完了したら、Multi-AZが正しく設定されているか実際にフェールオーバさせてみましょう!
手動でフェールオーバさせる場合は、DBインスタンスを下記の手順で再起動します。

1. 先ほどMulti-AZを設定したDBインスタンスを右クリックし、「Reboot」を選択します。
20130621_01_07

 

2. 表示されたウィンドウで「Reboot With Failover」にチェックを付け、「Yes, Reboot」をクリックします。
20130621_01_08

 

3. DBインスタンス一覧からRebootしたDBインスタンスの「Status」が「available」となったら、RebootしたDBインスタンスの「Description」を確認して「Zone」が切り替わっていれば成功です!
20130621_01_09

 

いかがでしたでしょうか?
以上の設定をおこなっておくだけで、もしRDSで障害が発生してしまった場合でも迅速に対応することが可能になります。
是非、1度ご確認のうえ、設定をおこなってみてください!

次回は「Amazon Route53編!」ということで、「Amazon Route53編~サイトを公開してみよう!パート①~」と題してお話していきますので、お楽しみに!


Amazon RDS編~EC2インスタンスからDBインスタンスへの接続~

今回はAmazon RDS編と題して、Amazon EC2からAmazon RDSへの接続についてお話したいと思います。

以前の記事でもAmazon RDS編ということで、RDSのDBインスタンスの立ち上げに関する記事を記述させていただきましたが、ここ最近、Amazon RDSがより利用しやすいサービスになってきています。

無料枠が追加されたり、更には、これまで選択可能だったMy SQLやOracle Database、SQL Server 2008 R2に加え、新たにMicrosoft SQL Server 2012も選択可能になりました。

今後も次々と新機能やDBエンジンが追加されていくことが予想されるので、これを機会にAmazon RDSを利用していくというのもよいかと思います。

なお、以前のRDS DBインスタンスの立ち上げに関する記事は以下を参照してください!

Amazon RDS編~DBインスタンスを立ちあげてみよう!~

さて、ここから今回の本題に入りたいと思いますがその前に、今回のレシピでお話するEC2からRDSへの接続について簡単に表記しておきます!

以前の記事にて立ちあげたAmazon RDSのDBインスタンスですがデフォルトの状態だと、どこからも接続できない状態になっています。

SnapCrab_NoName_2013-5-22_17-58-50_No-00

これをAmazon EC2インスタンスから接続できるようにするためには、Amazon RDSのDBインスタンスのセキュリティグループで、MySQLポートを開放するという作業が必要になります。

SnapCrab_NoName_2013-6-28_9-52-58_No-00

それでは以下、その一連の作業手順を説明していきましょう!

  1. まずは、DBインスタンスで適用されているセキュリティグループで、MySQLのポートを開放します。

AWS管理コンソールにログインしてサービスメニューの中からEC2を選択して下記画面を開き、Resourcesにある「Security Groups」をクリックします。

20130705_02_01

  1. 該当のセキュリティグループを選択し、「Inbound」をクリックします。

20130628_05_02

  1. プルダウンメニューからMySQLを選び、「Add Rule」をクリックして加えます。最後に「Apply Rule Changes」をクリックして反映させます。

20130628_05_03

これでMySQLのポートは開放されました!

つぎに、実際にDBインスタンスに接続する際に必要な情報を確認します。

  1. サービスメニューの中からRDSを選択し、左メニューにある「DB Instances」をクリックします。

20130628_05_04

  1. DBインスタンス一覧から対象のDBインスタンスを選択して、下記項目の確認をおこないます。

①Endpoint
②Username
③Name

20130628_05_05

DBインスタンスへの接続コマンド

  1. DBインスタンスへの接続は、PuTTYなどからEC2インスタンスに接続して以下のコマンドを入力しておこないましょう。

mysql -h [ENDPOINT] -P 3306 -u [Username] –p [Name]

例:

[crayon-61084cd03b00a433727731/]

...と入力すると「Enter password: 」と表示されますので、RDSのインスタンスを立ち上げた際に設定したマスターパスワードを入力します。

  1. マスターパスワードを入力した後に、下記の様に表示されれば接続は成功です!

[crayon-61084cd03b015327968249/]

これで作業は完了です!
なお、EC2インスタンスへの接続については以前に記述した下記の記事を参照してください。

Amazon EC2インスタンスにPuTTYで接続!
Amazon EC2インスタンスにTera Termで接続するには?

いかがでしたでしょうか?

せっかくDBインスタンスの立ちあげをおこなっても、デフォルトの状態のままだと接続がおこなえませんので立ちあげた後は接続するための設定もおこなっておきましょう!

次回も、引き続きAmazon RDS編ということで、「Amazon RDS編~Multi-AZでできること~」と題してAmazon RDSのMulti-AZ機能についてお話します。
お楽しみに!
ナレコムではAWSに興味がある、AWSを仕事にしたいクラウドエンジニアを絶賛募集中です!興味がある方はこちらからお問い合わせください。

 

【12月4日(金)15:00~】【AWS AI/MLオンラインセミナー】ABEJA様/ブレインズテクノロジー様/dotData Japan様との共同登壇!視聴無料!まだ申し込み可能です。

申し込みはこちら


Amazon EC2編~SnapshotやAMIを使ったバックアップと運用パート②~

今回は、「SnapshotやAMIを使ったバックアップと運用~パート②~!」と題してお話をしていきます。

以前の記事では「Amazon EC2編~SnapshotやAMIを使ったバックアップと運用パート①~」ということで、主にAMIの作成とSnapshotからのAMIの作成について記述したかと思います。
そこで今回はパート②ということで実際に障害が発生してしまった際、この作成したAMIを使ってどのように障害復旧を行うか記述しておきたいと思います。

パート①でもお話したように、バックアップを行なっておくということはとても重要です。
特に、実際に障害が発生してしまった時はバックアップがものをいいます。
Amazon EC2インスタンスに「SSHで接続できなくなった!」や「Ping疎通がされない!」といった場合にAMIを利用して障害を復旧させます。

※AMIを利用して復旧作業を行う前には、必ずPingやhttpdなどの障害が発生している該当サービスの再起動を行ってください。
また、障害が発生している該当EC2インスタンスの再起動および、停止してから起動を行ってみましょう!
それでも改善しない場合にAMIを利用して復旧作業を開始します。

ではまず、通常にAMIを利用して障害が発生してしまっているEC2インスタンスと同スペックのインスタンスを同一のゾーンで起動し直してみます。

1.AWS管理コンソールにログインしてサービスでEC2を選択、下記画面を開き左メニューの「AMIs」をクリックします。

20130620_01_01

2.AMI一覧から該当AMIを右クリックし、「Launch」を選択します。

20130620_01_02

なお、以降の手順は以前の記事の「Amazon EC2インスタンスを立ちあげてみよう!」の手順10から参照していただき、作業を行ってもらえれば大丈夫です。また確認事項として、
手順15のインスタンスキーの生成は「Choose from your existing Key Paris」を選び、既存のEC2インスタンスを作成したときに生成したKeyを選択してください。

これで作業は完了です!・・・が!!!

もし、以上の作業を行っても障害が解消されない場合は、先ほどの作業のなかで設定した、Availability Zoneを別のゾーンに設定して改めてインスタンスを起動し直してみましょう。

いかがでしたでしょうか?
このように、事前にAMIを作成しておけば障害が発生してしまった場合でも障害復旧作業は短時間で簡単に行えます。
障害はできれば起こって欲しくないものですが万が一に備え、是非、確認しておいてください!

次回は「Amazon RDS編!」ということで、EC2インスタンスからDBインスタンスへの接続についてお話していきたいと思いますので、お楽しみに!


Amazon EC2編~スポットインスタンスを使ってみよう!~

今回は、AWSのちょっと変わったインスタンスについて紹介したいと思います。

「スポットインスタンス」というものをご存知でしょうか?
スポットインスタンスとは、AWSサーバ上に存在し、使われていないEC2インスタンスに値段をつけ、その入札価格が現在のスポット価格(※長期ではなく、1回ごとの取引で決定され成立した市場価格)を上回っている限り、そのインスタンスを利用することができるというものです。
これにより、コスト削減も見込めます。
そのため、スポット価格は需要と供給の関係に基づいてリアルタイムに変動します。

SnapCrab_NoName_2013-5-22_17-44-47_No-00

ただし、スポットインスタンスでは、インスタンスが中断される可能性があるのでそれに備えておく必要があります。
最高入札価格を高く設定することで、スポットインスタンスが終了する可能性を下げることができますが、中断を防ぐことはできません。スポット価格が、設定した最高入札額を上回った場合は予期せずインスタンスが終了しますので、停止を想定したインスタンスの利用を行なうことをおすすめします。

ではその注意点を踏まえたうえで、実際にスポットインスタンスの利用法を説明していきます。

まず、スポットインスタンスリクエストを作成する前に、スポット価格履歴を確認してください。
インスタンスタイプ、インスタンスを実行するオペレーティングシステム、期間、起動する利用可能ゾーンに基づいて、1日から90日間のスポット価格の変動履歴を見られるのでこちらも合わせて事前に確認しておきましょう!
以下、スポット価格履歴の表示の仕方です。

1.AWS管理コンソールにログインして、以下の画面で「EC2」を選択します。
20130716_01_01

 

2.画面左側メニューの「Spot Requests」をクリックします。
20130716_01_02

 

3.画面上部にある「Pricing History」をクリックします。
20130716_01_03

 

4.スポットインスタンスの価格設定履歴確認画面が表示されます。
任意のOS、インスタンスタイプ、指定期間、利用可能ゾーンを選択して価格履歴の確認をおこないます。
20130716_01_04

 

スポットインスタンスリクエストの作成に入る前に、リクエストについて記述しておきましょう。
スポットインスタンスリクエストには以下、2種類のリクエスト方法があります。

ワンタイムリクエスト

リクエストをおこなった全てのインスタンスが起動するか、リクエストの期限が切れるか、リクエストをキャンセルするかのいずれかが確認されて時点でリクエストが完了するという方法です。

持続スポットインスタンスリクエスト

おこなったリクエストの期限が切れるかもしくは、キャンセルをおこなうまでリクエストの完了または終了はしません。
また、Amazon EC2 での最高入札価格が、リクエストをおこなった際の入札価格を超える場合はインスタンスを起動し、下回る場合はインスタンスを停止します。

ワンタイムリクエストでも持続リクエストでも、スポット価格を下回るか、終了するか、自動的に終了しない限りインスタンスは続行します。
また、最大価格がスポット価格とまったく同じである場合、インスタンスは続行する場合としない場合があるのでご注意ください。

さて、いよいよ下記、スポットインスタンスリクエストの作成です!
なお手順は、先ほどのスポット価格履歴の表示手順2までは同様の手順になります。

また、リクエストできる最大スポットインスタンス数は、最大100となっています。
それ以上のスポットインスタンスをリクエストする場合は、同じく以下のAmazon EC2インスタンス申請フォームから申請をおこなえば制限数を増やすことができます。

・Amazon EC2インスタンス申請フォームはこちら

スポットインスタンスリクエストの作成

1.画面上部にある「Request Spot Instances」をクリックします。
20130716_01_05

 

2.今回は試験として、Amazon Linuxでスポットインスタンスのリクエストをおこないますが、選択内容は自由なので任意で選択をしてください。まずは通常のインスタンスの立ち上げ同様にOSを選択します。
20130716_01_06

 

  1. 任意で仕様に合わせて項目を選択し、「Continue」をクリックします。
    20130716_01_07

 

以下は項目の説明です。

Max Price 1時間ごとの、支払うことができる最高入札額
Launch Group 一連のリクエストをまとめるグループのためのレベル
設定をするとグループ単位で起動・終了できる
Request Valid From リクエストの有効期間のはじまり
Request Valid Until リクエストの有効期間の終わり
Persistent Request? リクエストがワンタイムか接続かを決定
デフォルトではワンタイムリクエスト

 

これより先の手順はAmazon EC2インスタンス立ちあげ手順と同じになります。
※Amazon EC2インスタンス立ちあげのレシピはこちら

  1. 作成したスポットインスタンスのStateが「open」から「active」になったら完了!
    20130716_01_08

 

・・・ですが、

中には、リクエストしたスポットインスタンスを設定したものの、やっぱりキャンセルしたい・・・!
という方もいらっしゃると思うのでキャンセルのやり方についても、念のため記述しておきます。
なお、スポットインスタンスはSTOPをすることができませんので不必要になったらキャンセルしてインスタンスを削除するしかありません。

スポットインスタンスのキャンセル方法

手順2までは、先ほどのスポットインスタンスリクエスト作成と同じです。
1. リクエストをおこなっていれば、以下のようにスポットインスタンスリクエストの一覧が表示されているはずです。削除をおこないたいスポットインスタンスを選択して、画面上部の「Cancel」をクリックします。
20130716_01_09

  1. 「Yes, cancel request」をクリックしてスポットインスタンスのリクエストをキャンセルします。
    20130716_01_10

 

  1. そうすると、スポットインスタンスのStateが「cancelled」、Statusが「request-canceled-and-instance-running」になります。
    20130716_010_11

 

  1. リクエストはキャンセルされたけどインスタンスは起動しているということなので、インスタンス画面から対象インスタンスを左クリックして「terminated」をクリックします。
    20130716_01_13

 

  1. 「Yes, Terminate」をクリックします。
    20130716_01_14

 

  1. そうするとスポットリクエストのStatsが「instance-terminated-by-user」となり、スポットインスタンスがキャンセルされます。
    20130716_01_15

 

これで、スポットインスタンスのキャンセルをおこなうことも可能です。

いかがでしたでしょうか?
注意事項もありますが、スポットインスタンスを有効活用すれば、AWSを使ってより効率よく、そして低コストでシステムを運用する
ことが可能になりますので皆さんも是非、スポットインスタンスを使ってみましょう!

次回は以前のレシピに引き続き、「Amazon EC2編~SnapshotやAMIを使ったバックアップと運用パート②~」と題してお話していきたいと思いますので、お楽しみに!

 

【12月4日(金)15:00~】【AWS AI/MLオンラインセミナー】ABEJA様/ブレインズテクノロジー様/dotData Japan様との共同登壇!視聴無料!まだ申し込み可能です。

申し込みはこちら

 

 


Amazon EC2編~microインスタンスのSWAP領域について~

つい先日、AWSよりEC2リザーブドインスタンスの料金を最大27%値下げすると発表されました。
これによってコストも削減され、さらにEC2が手軽に利用できるようになりますね!

今回はそんなAmazon EC2に関することで、microインスタンスのSWAP領域についてお話したいと思います。

■SWAP領域とは?

システムの動作中に容量が不足しメモリを使い切りそうになってしまった場合、メモリから内容の一部を取り出して一時的に退避させるためのHDD上の領域になり、容量を有効活用しよう!という手段です。
Linuxでは、専用の領域としてパーティション作成時に確保します。

なお、EC2のmicroインスタンスには標準ではSWAP領域がありません。
SWAP領域が必要な場合は、設定をおこなう必要があるので、その設定方法を以下に記述しておきます。

①ddコマンドで適当なサイズのファイルを作成します。
コマンドオプションの「of」にファイルのパスを指定して「bs」に基準となる容量の単位を指定して「count」にbsの量を指定します。
②「mkswap」コマンドで、ファイルをSWAPフォーマットに変更します。
③「swapon」コマンドでSWAPファイルをシステムのSWAP領域として有効にします。
④「swapon -s」コマンドで確認すると、SWAPが組み込まれたことが分かります。

20130315_04_01.png

また、以下のように「top」コマンドで確認をしてもSWAP領域が使われていることが分かるかと思います。

20130315_04_02.png

最後に「/etc/fstab」ファイルの最終行にSWAP設定を追加します。その際は、キーボードの「Insert」キーで設定を開始します。
これで設定は完了です!

なお、設定を追加したらキーボードの「Esc」キー:を押して、「wq」コマンドを入力し設定を保存しましょう!

ただ、SWAPを利用する際には十分、注意が必要です。
SWAP領域を作成するとEBSのI/Oリクエストが頻繁におこなわれ、その都度、課金がおこなわれます。
そのため、SWAPを利用する際は一時的な利用をおすすめします。
長時間の利用をしなければならないといった場合は、一つ上のスペックのインスタンスタイプを使ってスワップしないメモリ容量を確保するようにしましょう。

なお、SWAPを無効にしたい場合は「swapoff -a」コマンドを実行すれば可能です。

いかがだったでしょうか?
SWAP領域はデメリットをしっかり確認しておけば、十分、活用することは可能です。
是非、EC2上でデータを運用する際の参考にしてください!

次回は、「Amazon EC2編~スポットインスタンスを使ってみよう!~」と題して、Amazon EC2のスポットインスタンスについてお話しますのでお楽しみに!


Amazon S3編~ファイルサーバのバックアップ~

先日、米国Amazon Web Services(AWS)がストレージサービスの「Amazon S3(Simple Storage Service)」において、Cross Origin Resource Sharing(CORS)のサポートを開始すると発表しました。
S3については後ほど説明したいと思いますが、このサポートによって異なるドメインで提供するWebアプリケーションから、S3上にあるデータへのアクセスができるようになります。

CORSとは、主コンテンツと異なるドメインにあるリソースへのリクエストを行うWebアプリケーションの開発を可能にする仕様のことです。
今回S3がCORSをサポートしたことで、S3上に保存されたWebフォントや画像などを、異なるドメインで提供しているWebページやスタイルシート、アプリケーションなどで参照できるようになるというものです。
さらに、ドラッグ&ドロップでのS3へのアップロードやアップロードの進捗を表示など、Webアプリケーションから直接コンテンツを更新したりできるHTML5を実装することが可能になりました。

今までこうした機能を実現するためには、WebアプリケーションとS3の間にプロキシサーバを用意する必要があったため、今回のCORSのサポートによって無駄が削減され、さらなるS3の有効活用につながるのではないでしょうか。

これまでも何度かバックアップに関して話をしてきましたが、今回もそんなバックアップに関連した話を記述したいと思います。
冒頭でも少し出てきたかと思いますが、Amazon S3(Simple Storage Service)というAWSサービスをご存知でしょうか?

S3とはインターネット用のストレージサービスで、よりスムーズにウェブスケールなコンピュータ作業ができるようにと設計されました。
S3ではいつでも、ウェブ上のどこからでも容量に関係なくデータを格納・取得できます。これにより、拡張可能で信頼性が高く、安全で、高速でありながら安価なインフラストラクチャを利用することが可能になります。
また、S3でのデータ耐久性は99.999999999%(イレブンナイン)と言われており、S3に1万個のデータを保存した場合でもそのうちの1データが障害によって失われる可能性は平均で、1000万年に1度あるかないかというほどの耐久性です。
これは、S3領域の複数の機器に対する冗長構成によって実現しているということです。

S3にただデータを保存するだけで、バックアップやスケーリング、デバイスの故障、その他災害などといったデータに関する心配事から開放されるでしょう!

ということで今回は、ファイルサーバでのバックアップを例にあげて、S3を採用することによるメリットや、構成例等を説明します。

バックアップをおこなっていくうえでの全体の課題としては、以下のような点があげられるかと思います。

・ファイルサーバのバックアップ方法としてテープバックアップをおこなっている場合、定期的なテープの交換作業およびリストア時における該当テープの調査とサーバセットアップ等の運用に関する工数がかかる
・バックアップ保存先が単一拠点の場合、大規模災害時にデータを喪失してしまう

ここで、上記の問題を解決できるS3が登場します!S3の導入メリットは以下になります。

・容量無制限のS3をバックアップストレージとして採用することでテープのように、「容量がいっぱいになったらテープ交換しなければならない」といったことがなくなり、作業工数の削減につながる
・単一拠点ではなく、複数拠点に保存(S3リージョン内で自動複製)されるのでデータ堅牢性が高く、BCP強化に最適

また、以下のようなサードパーティ製のツールの利用も可能です。

・Cloud Berry:リストアがファイル単位で簡単におこなえる
・WebDrive  :Windows ServerのファイルをS3にバックアップする場合、ファイルサーバとS3を自動的に同期することが可能

■構成イメージ

20130315_03_01.png

いかがでしたでしょうか?
以上のことから、サーバのバックアップをおこなう際の手段としてS3も非常に有効であるということがお分かりいただけたかと思います。
運用負荷の軽減及び遠隔バックアップの災害対策を目的とした、AWSのストレージサービスS3を是非利用しましょう!

次回は、「Amazon EC2編~microインスタンスのSWAP領域について~」ということでお話しますのでお楽しみに!