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-6008d1d4f3c72773667155/]

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

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

[crayon-6008d1d4f3c79341722010/]

これで作業は完了です!
なお、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領域について~」ということでお話しますのでお楽しみに!


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

こんにちは!

以前の記事では、「Amazon EC2編~EC2インスタンスを監視するには~」記述したと思います。

もちろんシステムの監視をおこなうことも大事ですが、もうひとつ欠かせないことがあります。
それは・・・

「データ」の保守です!!

AWSに限らず、システムを運用していくうえで「データ」はとても重要なものです。
大事なデータが消えてしまった!なんてことが起きてしまったら・・・
一大事ですよね?!!

そこで、やはりデータの保存[バックアップ]がとても大切になってくると思います。
今回は、そんなバックアップの際に重要になってくるSnapshotとAMIについてお話していきます。

これからAMIの作成と、SnapshotからAMIを作成する方法を説明していきたいと思いますが、その前にSnapshotとAMIについて簡単にまとめておきます。

AMI(Amazon Machine Image)とは


・Amazon EC2環境で実行可能なソフトウェア構成(OS、アプリケーション等)を含むテンプレートイメージ。
EC2インスタンスがスムーズに起動、動作することを目的として設計されている
・必要でないインストールパッケージは削除し、セキュリティ面における安全性を強化

Snapshotとは


・HDDのイメージファイルのことをいい、データだけでなくOSをまるごと複製することもできます。
・その他特徴

①ある瞬間のデータの複製バックアップが可能
②プログラムの更新確認やテスト環境を一時的に作る際など、ある特定のデータ部分を用いて環境を作りたいというニーズにも対応可能

以上の点から、Snapshotを使用することであの時の状態でインスタンスを起動したい!・・・という場合でもSnapshotからAMIを作成し、簡単に新しいインスタンスを立ちあげることができます。

AMIとSnapshotをうまく組み合わせて利用していけば、有効にバックアップをおこなうことが可能です。

それでは、始めにAMIの作成方法を説明します。

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

20130621_02_01

2. インスタンスの一覧から、AMIを作成する対象インスタンスを右クリックし、「Create Image(EBS AMI)」を選択します。

20130621_02_02

3. 下記画面で以下の項目を任意で確認・入力して、[Yes, Create]をクリックします。
・[Image Name]:AMI作成日付等
・[Image Description]:対象サーバの名称

20130620_02_03

4. 初めの画面に戻り、左メニューの「AMIs」をクリックします。

20130621_02_04

5. AMI一覧から、作成をおこなったAMIの作成完了状況を確認します。
完了に時間がかかっている場合は画面右上にあるRefreshマークをクリックして再度、確認してください。
※「Status」の項目が緑の文字で"available"と表示されるまで待ちましょう。

20130619_01_05

これで、AMIの作成が完了です!
この作成したAMIから、新たにEC2インスタンスを起動することが可能になります。

次に、SnapshotからAMIを作成する方法です!

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

2. 一覧から、利用したい瞬間のスナップショットを右クリックして、「Create Image from Snapshot」を選択します。
20130261_02_07

3. 下記画面で以下の項目を任意で確認・入力して、「Yes, Create」をクリックします。
・[Name]:作成日付等
・[Description]:サーバ名称
・[Architecture]:x86_64に変更
20130621_02_08

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

バックアップと聞くと、手間も工数もかかり面倒なイメージもあるかもしれませんがAWSでは、簡単にバックアップをおこなえることがお分かりいただけたかと思います。

冒頭にもお話しましたが重要なデータを損失するリスクを解消するためにも、ちょっとした時に上記の方法で簡単バックアップをおこなっておきましょう!

次回は「Amazon S3編!」ということで、Amazon S3でのファイルサーバのバックアップについてお話しますのでお楽しみに!!

ナレコムではAWSに興味がある、AWSを仕事にしたいクラウドエンジニアを絶賛募集中です!興味がある方はこちらからお問い合わせください。


Amazon EC2編~EC2インスタンスを監視するには~

先日AWSの方で、Amazon CloudWatchに新機能が追加されたと発表がありました。
新機能とは、Amazon CloudWatchでサービスに異常を検知してアラームがトリガされた場合、EC2などのインスタンスでサービスを停止または、終了する機能だそうです。

この機能はフェイルセーフ(異常な状態を検知してから行動する)やアプリケーションの処理ロジックの一部(期待される条件を待ってから行動する)として使うことができるので、非常に便利な機能です。このアラームアクションの設定についても後ほど、ご説明したいと思います。

ということで今回は、そんなAmazon EC2での監視について記述したいと思います。

システムを運用していくうえで懸念事項となるのは、やはり「障害」かと思います。
どんなに万全に設定をおこなっても、障害が起きてしまうことはあります。
障害をいち早く検知また、できるだけ障害を未然に防ぐには日々のシステム監視が重要になります。
監視方法はいくつかありますが、まずは「Amazon CloudWatch」を紹介しましょう!

基本的にAWSでの監視はこのAmazon CloudWatch行えます。
Amazon CloudWatchは、リソース監視のためにあらかじめAWSで用意されている測定基準(メトリクス)をもとに、インスタンスをモニタリングしてそのデータに基づくアラートアクションを構成できるサービスです。
あらかじめ、CloudWatchで設定をおこなっておけば何か監視項目で変動が起こった際、所定の通知先にアラートメールを通知することもできます。

下記画面が実際のEC2でのCloudWatch監視項目です。
(※通常にAWS管理コンソールにログインしていただき、EC2サービスに入った画面下部の「Monitoring」タブをクリックしていただくと、表示されます。)

20130620_03_01

また、EC2でのCloudWatchアラート通知設定方法についても説明しておきましょう!

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

2.インスタンスの一覧から今回、設定をおこなう対象インスタンスをチェック、画面下部より「Monitoring」タブを選択して「Create Alarm」をクリックします。

20130620_03_03

3.「create topic」をクリックします。

20130620_03_04

4.「Send a notification to:」の項目に任意の名前(アラーム名称)を入力していただき、「with these recipients:」にメールアドレス(ア ラーム通知先)を入力します。
「Whenever」の「of」の後の項目で「Status Check Failed(Any)」を選択、「Create Alarm」をクリックします。

20130620_03_05

5.Closeをクリック

20130620_03_06

また、今回は監視項目で「Status Check Failed(Any)」を選択しましたが、監視の設定項目は他にも以下の項目を選択することが可能です。
それぞれAverage(平均)、最大(Maximum)、最小(Minimum)で表示させることができるので簡単に項目の設定をおこなうことができます。

・CPU Utilization(CPU使用率)
・Disk Reads(ディスク読み込み状況)
・Disk Writes(ディスク書き込み状況)
・Network In,Out(ネットワーク状況)
・Status Check Failed(ステータスチェックに失敗した際)

また、手順3の画面にも表示されているしきい値のグラフはリアルタイムに反映され、下記画面のように確認することができます。

アラーム通知設定の手順2と同様、画面下部で「Monitoring」タブをクリックすると、グラフが表示されます。
20130315_01_05.png

これで、アラーム通知設定は完了です!

ただ、CloudWatchの基本設定だけではLoad Average(処理を待っているプロセス数)やメモリ利用状況、Disk Usage(ディスク利用状況)といったOS内部の情報を監視することはできません。その補完としてあるのが、「カスタムメトリクス」です。
「カスタムメトリクス」はCloudWatchにある機能の1つで、先述であげたような、CloudWatchの基本設定だけだと監視することができないけど、この部分については監視したい!という項目のメトリクスを独自に作成し監視をおこなうことも可能です。
20130315_01_06.png

加えて、冒頭でお話したCloudWatchのアラームアクションの設定に関する説明ですがもし、このアラームアクションの設定をおこなう際は、先ほどのアラーム通知設定の手順3の画面の「Take the action」の項目にチェックを付け、「Stop」か「Terminate」を選択してアラームがトリガされた場合の処理を決めましょう!

最後にもうひとつだけ、監視ツールをご紹介します。「Nagios」という監視ツールです。

Nagiosはサーバ自体の稼動状態を監視するツールです。
Nagiosには、システムの異常を検知してメールで報告する機能、Webインターフェースによるサーバステータスの一覧や、レポートの出力機能などがあります。
20130315_01_07.png

こちらでご紹介した監視ツールおよび監視方法は、ほんの一例です。
特に監視方法については、紹介したCloudWatchの「カスタムメトリクス」を用いることで様々なパターンで監視をおこなうことが可能です。
また監視をおこなう上で、「カスタムメトリクス」については公式のものも公開されていますので詳細については以下のページも参考にしてみてください。

■Amazon CloudWatch開発ガイドはこちら

いかがでしたでしょうか?
是非、監視ツールを活用していただき、負荷なく監視をおこないましょう!

次回は、「SnapshotやAMIを使ったバックアップと運用~パート①~」と題して、SnapshotやAMIを使ったバックアップについてお話しますのでお楽しみに!