AWS SDK Rubyを使ってみよう！
こんにちは！ JQです。
前回は『Amazon RDS編～ログの管理について～』ということでお話をしました。
今回は『AWS SDK Ruby』についてお話したいと思いますが、その前にAWSの更新情報をご紹介します。
先日、Amazon LinuxがVersionUPを発表しました。
様々変更点があり、新しくCommand Line Toolのpython版がデフォルトでインストールされるようになりました。
後々、こちらもご紹介したいと思います！
さて、ここから本題に入りまして、AWS SDK Rubyに関して記述したいと思います。
AWSでは様々なプログラム言語からアクセス出来るSDKが数多く提供されております。
今回はRubyのSDKのAmazonLinuxでのインストールから簡単なプログラム実行までをしてみます。
1.まずは必要なモジュールをyumでインストールします。
[crayon-62ffffcd5d2ae493154761/]
2.gemコマンドにて「aws-sdk」の依存関係も含めてインストールが可能です。
[crayon-62ffffcd5d2b6419947277/]
これでインストールは完了です！
3.インスタンス一覧を取得するプログラムは以下のような物になります。
[crayon-62ffffcd5d2b8260317708/]
4.インスタンスを作成するプログラムは以下のような感じになります。
[crayon-62ffffcd5d2ba721384119/]
オプションで他にも様々な指定が可能です。
例、VolumeSizeやSubnet
:volume_size => 30
:subnet => "subnet-xxxxx"
詳細をお知りになりたい方は下記の公式ドキュメントでご確認下さい。
http://docs.aws.amazon.com/AWSRubySDK/latest/frames.html
いかがでしたでしょうか？
SDKを利用してプログラマブルに効率よくAWSを利用しましょう！
次回は『AWS Command Line Interface (Developer Preview)を使ってみよう！』と題してお話したいと思います。
お楽しみに！
Amazon Route53編～Route53を使ったDNSフェールオーバー パート②～
こんにちは！中の人です。
前回のパート①では、『EC2⇔EC2間でのフェールオーバー設定方法について』をお話しました。
今回のパート②は、『EC2⇔S3間でのフェールオーバーの設定方法について』をお話していきたいと思います！
その前に、『Amazon Route53』に関する情報をご紹介します。
パート①では、Amazon Route53にフェールオーバー機能が追加されたと紹介させていただきましたが、Amazon Route53に追加された機能がもう1つあります。
それは、ヘルスチェック機能です！！
これにより、定期的にエンドポイントの状態を検査して、そのチェック結果をDNSクエリに対する応答を決定する際に使用するようにRoute53に設定をすることができます。
今回新たに追加された2つの機能によって、ますます、Amazon Route53が便利になりますね！
さて、ここから本題に入りまして、今回のパート②では『EC2 ⇔ S3間でのフェールオーバーの設定方法』をお話していきましょう！
1. EC2のHealth Checkは既に作られている前提で話を進めます。
※Health Checkの設定方法についてはパート①の記事を参照してください。
2. 「Hosted Zone」を選択し、該当ドメインの編集画面に遷移します。
3. EC2に対するゾーン設定は前回の記事を参考に以下のように入力します。
TTL デフォルトの300秒から推奨の60秒に変更します。
Routing Policy Failoverを選択します。
Failover Record Type 正系：Primary
Set ID 標準のままで問題ありません。
Associate Record Set with health check YESを選択します。
Health Check to Associate Step1で作成したHealth Checkを選択します。
4. S3に対しては以下の様に設定を行います。
(Record) Type A – IPv4 addressを選択
Alias Yesを選択
Alias Target S3のドメイン名を選択
Routing Policy Failoverを選択します。
Failover Record Type 正系：Primary
Set ID 標準のままで問題ありません。
Associate Record Set with health check NOを選択します。
以上で設定完了です！
パート①同様、Health Checkに設定しているURLをアクセスできない状態にすることで簡単にフェールオーバーの確認をおこなうことができます。
直接サイトを見て確認することもできますし、nslookupで確認することもできます。
いかがでしたでしょうか？
以上の設定をおこなっておくだけで、もしPrimaryのEC2に障害が発生してしまった場合にも、
twitterのくじらページなどと同じように別のページでアナウンスすることが可能です。
メンテナンスの時などにも利用することができます。
是非、1度ご確認のうえ、設定をおこなってみてください！
次回は「Amazon Route53編～GSLB（グローバルサーバロードバランシング）～」と題して、Amazon Route53を利用した『Global Server Load Balacing』についてご紹介をしたいと思います。
お楽しみに！
Amazon RDS～リードレプリカ編パート①～
こんにちは！Rookieです。
今回はリードレプリカについてということで2回にわたってお話していきたいと思いますが、その前にAmazon RDSに関する情報をご紹介します！
先日、AWSの方でAmazon RDSのエンドポイント名が変更可能になったと発表されました。
これにより、既存のDBインスタンスが何らかの理由で使えなくなった場合でも、新しく作成したDBインスタンスの名前とエンドポイントを既存のそれに変更することができますので、アプリケーション内でエンドポイントを更新する必要がなくなります。
より細かな部分まで設定ができるようになり、便利な点が増えることは嬉しいことですね！
さて、ここから本題に入りまして、今回はリードレプリカの概要および利用目的と作成方法について記述したいと思います。
そもそもリードレプリカというのは、読み込み専用として利用することができるマスターの複製データベースになります。
Amazon RDSでは、マスターのDBインスタンスのデータを非同期にレプリケーションする機能としてこのリードレプリカを提供しています。
Multi-AZ構成の際にはスレーブのDBインスタンスに対して利用者が直接アクセスすることはできませんでしたが、リードレプリカの場合は直接アクセスすることが可能です。
読み込みが多いアプリケーション等に有効ですが、非同期のため常にマスターと完全に内容が一致しているわけではなく常に最新のデータが取得できるということではありませんので、マスターの負荷分散用として利用するのがよいかと思います。
更新系はマスターで、参照系はレプリカでという使い方が想定されます。なお、Multi-AZ機能との併用も、もちろん可能です。
リードレプリカについて、以下にまとめておきます。
○Read Replica
■利用目的
データベースでは書き込みよりも読み込み比率の方が高いため、データベースへのアクセス頻度が高くDBサーバのリソースが逼迫している場合などの際に、読み込みを複数の「リードレプリカ（読み込み用のレプリカ）」に分散して処理をさせることで、全体のパフォーマンス向上させることを目的としています。
リードレプリカは、マスターに対する書き込みに追随するかたちで、自分自身のデータを反映させます。
読み込みは主にリードレプリカを利用することで、データ解析用途などの際もマスターの負荷を減らすことが可能になります。
■利点
・データベースからの読み込み負荷が高い場合、負荷を分散できる
・データ解析用途などでマスターに負荷をかけずに処理したいときにも有効
そんなリードレプリカの作成方法を記述しておきましょう！
1. AWS管理コンソールにログインしてサービスで「RDS」を選択、下記画面を開き左メニューの「DB Instances」をクリックします。
2. DBインスタンス一覧から対象のDBインスタンスを右クリックし、「Create Read Replica」を選択します。
3. 表示されたウィンドウの「DB Instance Identifier」に名前を入力し、「Yes, Create Read Replica」をクリックします。
各項目を簡単に説明しますと、
| Read Replca Source | リードレプリカの作成元となるDBインスタンス |
|---|---|
| DB Instance Identifier | DBインスタンスの名前 |
| DB Instance Class | 作成するリードレプリカのインスタンスタイプ |
| Auto Minor Version Upgrade | 作成するリードレプリカのMySQLにおける自動マイナーバージョンアップの有無 (※任意) |
| Availabirity Zone | ゾーンの設定 |
となります。
これで、リードレプリカの作成は完了です！
いかがでしたでしょうか？
このようにリードレプリカの作成は簡単にできますので、是非おこなってみてください！
次回も引き続き、「Amazon RDS～リードレプリカ編パート②～」ということで、
作成したリードレプリカをマスターに昇格させてみたいと思いますのでお楽しみに！
Amazon Route53編～Route53を使ったDNSフェールオーバー パート①～
こんにちは！中の人です。
今回は、『Amazon Route53のフェールオーバーの設定方法について』を2回にわたってお話していきます。
既に以前のレシピで、『Route53でサイトを公開してみよう！パート①、パート②』ということでお話していたかと思います。
今回のレシピでは『Amazon Route53を使ってフェールオーバーをおこなう際の設定方法』を記述していきたいと思いますが、
その前に『Amazon Route53に関する情報』をご紹介します。
今回お話するAmazon Route53のフェールオーバー機能ですが、この機能は先日、AWSより発表されたAmazon Route53の追加機能です。
Amazon Route53でのDNSフェールオーバー機能を利用することで、ELBを使えない環境でのフェールオーバーやEC2とS3間さらに、
EC2とEC2間でのフェールオーバーなどを行うことができ、東京リージョンのダウンを想定した海外リージョンとのフェールオーバーや動的サーバダウン時のS3でのエラー表示など様々な利用方法があります。
この追加機能をうまく活用すれば、より耐障害性のあるシステムを構築することができますね！
さてここから本題に入りまして、今回のパート①ではまず、『EC2 ⇔ EC2間でのフェールオーバーの設定方法』をご紹介します。
1. AWS管理コンソールにログインしてサービスで「Route53」を選択し、左メニューより「Health Check」をクリックします。
2. 「Create Health Check」をクリックし、必要な項目を入力して「Create Health Check」で保存します。
Protocol HTTP/HTTPSを選択します。
IP Address サーバのホスト名を入力します
Port HTTPなら80，HTTPSなら443、それ以外なら設定しているポート番号を入力します。
Host Name DNSに設定するホスト名を入力します。
Path ヘルスチェックを行うファイルのパスを入力します。
※ フェールオーバー先のsecondary用のホストに対しても同様に設定します。
3. 続いて左メニューより「Hosted Zone」を選択し、該当ドメインの編集画面に遷移します。
4. このDNSフェールオーバーの設定では、レコードセット時の「Routing Policy」から「Failover」を選択します。
※各レコードの設定方法は以前のレシピ（Amazon Route53編～サイトを公開してみよう！パート①～）を参照ください。
Routing Policy Failoverを選択します。
Failover Record Type 正系：Primary
副系：Secondary
を選択
Set ID 標準のままで問題ありません。
Associate Record Set with health check YESを選択
Health Check to Associate Step2で作成したHealth Checkを選択します。
5. Primary/Secondary共に登録すると設定完了です！
Health Checkに設定しているURLをアクセスできなくすることで簡単にフェールオーバーの確認を行うことができます。
直接サイトを見て確認することもできますし、nslookupで確認する事も出来ます。
いかがでしたでしょうか？
以上の設定をおこなっておくだけで、もしPrimaryのEC2に障害が発生してしまった場合は自動的にSecondaryでサービスすることができます。
是非、1度ご確認のうえ、設定をおこなってみてください！
次回は、『Amazon Route53編～Route53を使ったDNSフェールオーバー パート②～』と題して、
EC2⇔S3でのフェールオーバーについて紹介したいと思います。
お楽しみに！
Amazon RDS編～ログ管理について～
こんにちは！ JQです。
前回までのレシピでは『Amazon VPCを使ってWEBサーバを構築しよう！パート①、パート② 』と称して、VPC上でのWEBサーバ構築についてご紹介していたかと思います。
今回は『Amazon RDSのログに関するお話』をしたいと思いますが、その前に『Amazon RDS』に関する情報をご紹介します！
先日、WEBコンソールから今まで確認出来なかったRDSのmysql_errorのログが確認出来る様になりました。
RDSもさらに便利になっていきますね！
さて、それでは本題であるAmazon RDSのログに関してお話していきます。
まずは、RDSのerror.logの設定方法をしていきます。
1.RDSの画面に移動して、ログを見たいRDSを選択します。
2.画面下部のタブに「Logs」という項目があるので、そちらをクリックします。
3.error/mysql-error.log の項目がありますので、「View」を選択する事でLogの中身を確認する事が出来ます。
また、「Watch」を選択する事で5秒毎に更新する事でリアルタイムに近い形でログを確認出来ます。
「mysql-error.log」に関してはデフォルトで出力されますが、
「general.log」「slowquery.log」に関してはRDS DB Parameter Groupで有効にする事で出力する事が可能です。
それでは有効にしていきましょう。
4.まずは該当のRDSのParameter Groupに移動します。
5.このままでは該当のParameterを探しにくいので、「_log」のキーワードで絞込みを行います。
キーワードフォームの右側にある「Edit Parameters」をクリックして編集画面に移動します。
6.「general.log」「slowquery.log」のValueを「1」にして有効化します。
上記で有効化が完了です。
※ParameterGroup自体を変更する場合にはRDSの再起動が必要になります。
しばらく待つと先ほどのLogsに新たに加わっています。
また、DB上にも出力されている為、そちらからも確認が可能です。
error.logは1時間でローテートされ、24時間保持されます
また、DB上の「general.log」「slow_query_log」をローテートする場合には以下のストアドを利用して行います。
rds_rotate_general_log
rds_rotate_slow_log
MySQL以外のDBでは以下のようなログになります。
・Oracle Database ではアラートログとトレースファイルにアクセスできます。
・デフォルトで7日間保持され、必要に応じて保持期間を変更する事が可能です。
・SQL Server ではエラーログ、エージェントログ、トレースファイルにアクセスできます。
デフォルトで7日間保持され、必要に応じて保持期間を調整できます。
また、コマンドラインツールを利用して。Logファイルをダウンロードする事も可能です。
rds-download-db-logfile
いかがでしたでしょうか？
とても簡単にログが確認出来ますので、ぜひお試し下さい。
次回は『AWS SDK Rubyを使ってみよう！』と題してお話したいと思います。
お楽しみに！
Amazon VPCを使ってWEBサーバを構築しよう！～パート②～
前回に引き続き、今回もAmazon VPCを使ってWEBサーバを構築しよう！～パート②～と題して、お話していきたいと思います。
パート①では、「Public Subnet」のテンプレートを利用してVPCの作成までをおこないました。
パート②となる今回では、「実際にインスタンスを立ち上げてアクセスするまで」を紹介していきます！
なお、前回のパート①の記事は下記を参照してください。
■Amazon VPCを使ってWEBサーバを構築しよう！～パート①～
それではさっそく進めていきましょう！
1. EC2のページから「インスタンス作成」で起動ページに移動します。
※今回はAmazon Linuxを利用して立ち上げてみます。
2. インスタンスタイプの設定を行います。
3. 「インスタンス詳細の設定」の画面の「ネットワーク」で今回作成したVPCを選択します。「ネットワークインターフェイス」の設定でIP Addressの追加や設定を行います。
4. ストレージの設定を行います。
5. インスタンス名などのタグの設定を行います。
6. 「セキュリティグループ」の設定をしていきます。
7. 作成するインスタンスの設定を確認し、問題がなければ「作成」をクリックします。
8. 「キーペア」を設定していきます。
下記の画面が出ていれば、無事に起動出来ています！
これで、インスタンスの立ちあげは完了です！
・・・・
ただし！！このままではパブリックIPが付与されていないため接続が出来ません！
9. まずは、インターネットから接続出来るようにEIP(グローバルIP)を付与します。
左メニューの「Elastic IP」に移動して「新しいアドレスの割り当て」からVPCで利用する新規EIPを取得します。
10. 次に、先ほど作成したインスタンスに紐付けます。
※ネットワークインターフェイスを指定して紐付けることも可能です。
※紐付けが成功したかは、「インスタンス」の画面で確認してみましょう。
11. EIPが設定されているのを確認出来たら、実際に接続して確認してみましょう。
12. 次にApacheをインストールして、WEBサーバとしての機能も確認してみましょう。
それでは、実際にインスタンスのアドレスでブラウザでにアクセスしてみます。
できましたか？
これで、無事に表示が確認出来ました！
いかがでしたでしょうか？
今回は「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ウィザードの開始」を選択します。
2. 「VPCの設定選択」が立ち上がりますので、「１個のパブリックサブネットを持つVPC」を選択します。
※パブリックサブネットはEIPをアサインして利用する形になります。
パブリックサブネットを利用するメリットとしては、高いセキュリティでWEBアプリケーションを稼働出来る事や、IPアドレスを自由に設計出来る事が挙げられます。
3. 入力項目を確認して「VPCの作成」をクリックします。（デフォルトの設定で構いません。）
4. 上記の操作だけでVPCが作成されます。
5. 作成が完了したら、左ペインから以下の各項目を選択し、確認をしていきます。
※VPC
※サブネット
※ルートテーブル
※ネットワークACL
以上で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」をクリックします。
・Bucket Name:Webサーバとして公開するドメイン名を入力
・Region :アクセスする主なユーザーがいるリージョンを選択
3.S3のログに関する設定です。下記必要項目を入力し、「Create」をクリックします。
・Enabled :S3に対するアクセスログを取得する場合はチェックして下さい。
・Target Bucket :ログを保存するバケット名を選択して下さい。
・Target Prefix :ログに対して付与する設定後が設定出来ます。
4.上記までで作成されたバケット選択し、右側から「Enable website hosting」を選択して必要情報を入力します。
S3の設定は以上で終了です。
・Index Document:トップページ（index）のファイルパスを入力
・Error Document :エラーページのファイルパスを入力
5.次にRoute53にて、設定をします。
ManagementConsoleのServicesからRoute53を選択します。
6.メインビューの該当のドメインを選択し、「Go to Record Sets」をクリックします。
該当ドメインに対してCNAMEレコードに対してAlias「No」を選択し、S3のエンドポイントを入力します。
以上で、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 :管理用のコメント。日本語の利用が可能です。
3.設定が完了すると、ドメイン一覧に登録したドメイン名が表示されます。
4.ドメイン名をクリックするとページ右「Hosted Zone Details」に詳細が表示されます。
・Domain Name :設定したドメイン名
・Hosted Zone ID :AWS上での管理用のID
・Record Set Count:登録済みのレコード数
・Comment :登録時に入力したコメント
・Delegation Set :ここに表示される4つのネームサーバ情報をお名前.com等に登録する必要があります。
5.ドメインを選択している状態で「Go to Record Sets」をクリックします。
6.作成した時点でNS/SOAそれぞれ1つ登録されていることが確認できます。
「Create Record Set」をクリックして新しいゾーンの設定を行います。
7.Nameに対して無記入・www・*など必要な名前を入力します。
Typeに対して「A – IPv4 address」を選択します。
AliasはEC2のEIP等IPの場合は「No」、ELBを利用する場合やS3のエンドポイントを設定する場合には「Yes」を選択します。
○Noの場合
TTLは特に短時間に反映が必要なければ標準の300秒（5分）となります。
ValueはIPアドレスを入力します。
○Yesの場合
Alias Targetに対してELBのドメイン名やS3のエンドポイントを設定します。アカウント内の情報であれば、入力フォームを選択することで自動的に候補が表示されます。
以上でAWSのManagementConsoleで設定する内容は完了です。
続けて以下に、お名前.comでの設定方法を説明します。
※ネームサーバ情報が更新されるまで数時間から最大72時間程度かかる場合があります。
お名前.comにログインし、「ネームサーバの変更」より設定したいドメインを選択し”ネームサーバー情報を入力”に対して4つのDelegation Setで表示された4つのネームサーバを入力して登録します。
ネームサーバの変更が反映されると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分程度かかります。)
それではさっそく、DBインスタンスでMulti-AZの設定をおこなってみましょう！
1. AWS管理コンソールにログインしてサービスで「RDS」を選択、下記画面を開き左メニューの「DB Instances」をクリックします。
2. DBインスタンス一覧から対象のDBインスタンスを右クリックし、「Modify」を選択します。
3. 「Multi-AZ Deployment」の項目をYesとします。
なお、この時、即時反映としたい場合は「Apply Immediately」の項目にチェックを付け、「Continue」をクリックします。
4. 設定項目を確認して、「Modify DB Instance」をクリックします。
5. DBインスタンス一覧を確認すると、対象のDBインスタンスの再起動が開始されていますので「Status」の項目を確認し、
「available」となるまで待ちます。(数分はかかります)
6. これで、設定作業は完了です！
「Description」タブをクリックし、「Multi-AZ Deployment」が「Yes」になっていることを確認してください。
設定が完了したら、Multi-AZが正しく設定されているか実際にフェールオーバさせてみましょう！
手動でフェールオーバさせる場合は、DBインスタンスを下記の手順で再起動します。
1. 先ほどMulti-AZを設定したDBインスタンスを右クリックし、「Reboot」を選択します。
2. 表示されたウィンドウで「Reboot With Failover」にチェックを付け、「Yes, Reboot」をクリックします。
3. DBインスタンス一覧からRebootしたDBインスタンスの「Status」が「available」となったら、RebootしたDBインスタンスの「Description」を確認して「Zone」が切り替わっていれば成功です！
いかがでしたでしょうか？
以上の設定をおこなっておくだけで、もしRDSで障害が発生してしまった場合でも迅速に対応することが可能になります。
是非、1度ご確認のうえ、設定をおこなってみてください！
次回は「Amazon Route53編！」ということで、「Amazon Route53編～サイトを公開してみよう！パート①～」と題してお話していきますので、お楽しみに！