Amazon Route53編～Route53でラウンドロビン（simple/weighted）～
こんにちは！中の人です。
前回のレシピに引き続き、今回もAmazon Route53編ということでお話していきます！
前回は「Amazon Route53編～GSLB（グローバルサーバロードバランシング）～」と題してお話をしましたが、今回はRoute53を使ったラウンドロビンについてお話したいと思います。
とその前に、今回は少しお知らせがあります！！
弊社も出展する、2013/06/05～2013/06/06の2日間でおこなわれるAWS summit Tokyo 2013の受付が開始されています。
AWSを既に使っている方はもちろん、興味のある方や、現在は他のサービスを利用しているけど情報収集に…という方も、是非お越しください！
さて、ここから本題に入りまして、「DNSラウンドロビンの設定について」お話していきたいと思います。
まず全体の構成ですが、以下のようになります。
AWS外にある既存のオンプレサーバとの並行利用などを行うことができ、少しずつウェイトを変える事で安全に切り替えることができます。
1. Management ConsoleよりRoute53に移動し、「Hosted Zone」を選択し、該当ドメインの編集画面に遷移します。
２． Aレコードを例に説明しますと、以下の様に設定を行います。
書いてて気づいたのですが、日本語入力が出来ました！
管理する時に日本語も使えると便利ですよね。
・Routing Policy→Weightedを選択します。
・Weight→数値を入力します。
・Set ID→任意の名称を入力して下さい。
【Weightの考え方】
IPアドレス：A x / IPアドレス：B yと設定すると
IPアドレス：A x/(x+y)*100%
IPアドレス：B y/(x+y)*100%
となります。いくつか例を挙げると
両方共１に設定した場合
IPアドレス：A 50％ IPアドレス：B 50％
Aに対して3、Bに対して１を設定した場合、
IPアドレス：A 75％ （3/4*100％）
IPアドレス：B 50％ （1/4*100％）
となります。
３． たったこれだけでラウンドロビンの設定が完了です！！
オンプレ環境からAWSに対して、1:10などからはじめ徐々に付加をかけながら移行することなども容易に出来ます。
それでは最後にきちんと確認がされているか、「nslookup」コマンドで確認してみましょう。
[crayon-61e521716c04c461000149/]
登録したものが表示されます。
次にAWSのDNSから参照すると参照するタイミングで以下のように登録したIPアドレスが帰ってくることが確認できます。
[crayon-61e521716c055318324451/]
いかがでしたでしょうか？
たったこれだけを行うだけで、ラウンドロビンを行うことができるので、ぜひ行なってみて下さい。
次回は、「Amazon IAM編～IAMを使ってみよう！パート①～」と題して、AWSのアカウントおよびアクセスコントロール機能であるIAM(Identity and Access Management)についてお話します。
お楽しみに！
Amazon RDS編～MySQLとAmazon RDSとの比較～
こんにちは！Rookieです。
以前のレシピに引き続き、今回もAmazon RDS編です！
今回はMySQLとAmazon RDSの比較についてお話していきたいと思いますが、その前にAmazon RDSに関する情報をご紹介します！
先日、AWSの方でAmazon RDSにイベントサブスクリプション機能が追加されたと発表がありました。
この機能は、Amazon RDSのインスタンスに関連づけられたさまざまなイベントに対して、SNSを介し通知を受け取れるようになるというものです。
Amazon RDS DBインスタンスのストレージ不足や障害等が発生してしまった場合でも、すぐにプッシュ通知で確認することが可能です。
他にもバックアップの開始や終了、データベースのシャットダウンや再起動など40以上の通知タイプが利用可能です。
SNSとの連携でEメールメッセージとして通知を受信することもできるので、
いつでもすぐにサービスの状態を確認することができてより詳細でより安全にシステム運用をすることができますね！
さて、ここから本題に入りまして、今回は物理サーバ環境でのMySQLでデータベースを利用した場合と、クラウド環境であるAmazon RDSでデータベースを利用した場合とでの比較についてお話していきたいと思います。
Amazon RDSはMySQLを通常にサーバにインストールして使うのに比べて、さまざまな機能が簡単に利用できるようになっています。
以下にMySQLとAmazon RDSとの比較をまとめてみます。
■簡単に調達できる！
データベースが必要になった際、Amazon RDSであれば、AWSの管理コンソールから操作をすることでたった数分で用意をすることができます。
以前のレシピ「Amazon RDS編～DBインスタンスを立ちあげてみよう！～」を参照いただいても、簡単に立ちあげをおこなえることがお分かりいただけるかと思います。
■Multi-AZ機能による冗長化構成が可能！
冗長性を上げる方法としてホットスタンバイのデータベースを作り、運用系に何かがあると切り替える（フェイルオーバー）という手法があるのですが、Amazon RDSにはそれを実現することのできるMulti-AZという機能があります。
Multi-AZ機能を利用することで2つのデータセンターにまたがりレプリカを作成し、運用系に何らかの障害が発生すると自動的にフェイルオーバーします。
通常だとレプリケーションラグというタイムラグが発生してしまうのですがAmazon RDSでは同期をおこなっているため、タイムラグが発生しません。
このMulti-AZを活用することでAmazon RDSは劇的に安定します。
また、Amazon RDSでは定期的にメンテナンスがありフルバックアップを取ったり、MySQLのマイナーバージョンアップをしたりするのですが、その間データベースサーバは停止してしまいます。
(※このメンテナンス時間は、開始から終了まで数分のみを要します。)
しかし、このMulti-AZ機能使うことでその作業はスタンバイ側のデータベースでおこなうことができるようになり、停止時間はほぼなくなります。
なお、Amazon RDSのMulti-AZ機能の詳細については、
以前のレシピ「Amazon RDS編～Multi-AZでできること～」を参照してください。
■バックアップ機能も充実！
Amazon RDSでは自動でデータベースとトランザクションログのバックアップをしています。
最大35日間で指定した期間のバックアップ保持をすることができ、最短で５分前の状態に戻すことができます。
通常に物理サーバでMySQLを運用した場合だと、定期的なバックアップも独自に設定しなければならないので、これは大きなメリットです。
さらに、任意のタイミングのスナップショットを取得することもでき、MySQLのデータをスナップショットとして残しておいて、そのスナップショットを使って新しくデータベースサーバを立ち上げるということも可能です。
■ディスク容量の増減が容易！
データベースを物理サーバで運用する際に問題となるのが、ディスク容量不足です。
マスター/スレーブなどのレプリケーション構成を取っていればなおさらで、溜まっていくデータがディスクを圧迫します。
物理サーバでこのような状態になると、とても厄介かと思いますが、かといって最初から容量の大きいディスクを用意するのも無駄が多いです。
Amazon RDSはクラウドサービスなので、もちろんその点も解決済でHDDの容量を後から増やすことも可能です。
最初10GBから初めて足りなくなってきたら20GB、また足りなくなったら200GBというように使っていきながら容量を増やしていくことができます。
これを物理環境で実現しようとしたら、高価なストレージサーバを用意するなどたくさんの費用がかかってしまいますがAWSは従量課金制なので、拡張性だけでなくコスト面のメリットも得られます。
■スケールアップも簡単！
Amazon RDSはクラウドサービスですので、負荷が高くなりデータベースが耐えられなくなってきたら、簡単によりハイスペックなデータベースサーバにすることが可能です。
それもたったの数分で終わります！
ただスケールアップをおこなう際、数分間インスタンスを停止する必要があるので注意しましょう！
また、Amazon RDSにはリードレプリカという機能もあり、書込みはできませんが読込み専用のデータベースを作成することができます。
リードレプリカの詳細については、
以前のレシピ「Amazon RDS～リードレプリカ編パート①、パート②～」に記述がありますので、
そちらを参照してください。
いかがでしたでしょうか？
このようにAmazon RDSを利用すればデータベースを簡単に用意することができ、
さらに、上記に記述したようなさまざまメリットもあります。
是非、確認していただきデータベース運用を効率良くおこないましょう！
次回は「Amazon S3編～S3バケットを作成してみよう！～」と題して、バケットの作成についてお話していきたいと思いますのでお楽しみに！
Amazon RDS編～Amazon VPCでRDSを起動してみよう！～
こんにちは！Rookieです。
今回も以前のレシピで既に記述させていただいているAmazon RDS編です！
以前までのレシピ「Amazon RDS リードレプリカ編パート①、パート②」の記事ではリードレプリカの概要と作成方法、更にリードレプリカをマスターに昇格させる方法などをお話していたかと思いますが、今回はAmazon VPCでRDSを起動させる方法についてお話していきたいと思います。
その前に、まずはAmazon RDSに関する情報をご紹介します！
今回お話するAmazon VPCでのRDSの起動ですが先日、米国Amazon Web Services（AWS）より新しく発表されたものになります。
Amazon VPCの中でAmazon RDSが利用可能になったと発表があり、これによってAmazon VPCがますます拡張されたサービスになったのと同時にAmazon RDSの運用の幅も広がったのではないかと感じます。
さて、ここから本題に入りまして、今回は実際にAmazon VPCでRDSを起動させてみたいと思います！
※なお、Amazon VPCの作成は以前のレシピ「Amazon VPCを使ってWEBサーバを構築しよう！～パート①～」を参照していただいて、事前におこなっておいてください。
1. まず、DB Subnet Groupを作成します。
AWS管理コンソールにログインしてサービスで「RDS」を選択、左メニューの「DB Subnet Groups」を選択して下記画面を開き、画面上部の「Create DB Subnet Group」をクリックします。
2. 表示されたウィンドウで以下の項目を設定し、「Yes,Create」をクリックします。
※Multi-AZ環境で使用する事を考え、DBサブネットグループには2つのAZを登録しましょう。
・Name : DBサブネットグループ名
・Description: 簡単なコメント
・Availability Zone
・Subnet ID
これで、DBサブネットグループの作成は完了です！
※DBサブネットグループ作成完了後、反映されるまでに少し時間がかかります。
3. 次に、Amazon RDSをAmazon VPC内で起動します。
AWS管理コンソールの左メニューにある「DB Instances」を選択、画面上部にある「Launch DB Instance」をクリックします。その後、画面に沿って進んで下記画面を開き、以下の項目の設定をおこないます。
・ Choose a VPC:作成済のAmazon VPCの選択
・ DB Subnet Group :作成済のDBサブネットグループの選択
※なお、今回説明したAmazon VPCでのAmazon RDSの起動に必要な設定項目以外の部分の項目についても適宜、設定していただく必要がありますので、それについては以前のレシピ「Amazon RDS編～DBインスタンスを立ちあげてみよう！～」を参照ください。
最後に設定内容を確認して、DBインスタンスを立ちあげれば、作業は完了です！
※なお、Amazon EC2などから今回起動したAmazon RDSに接続をする際は、Amazon RDS DBインスタンスのセキュリティグループの設定をおこなって接続許可をおこなう必要がありますので、詳細については以前のレシピ「Amazon RDS編～EC2インスタンスからDBインスタンスへの接続～」を参照ください。
いかがでしたでしょうか？
これからますますAmazon VPCでのシステムの利用が増加していくと思いますので今回ご紹介したことを含め是非、1度確認して試してみてください！
次回は、「Amazon RDS編～MySQLとAmazon RDSとの比較～」と題して、Amazon RDSとMySQLの比較ということでお話していきたいと思いますので、お楽しみに！
Amazon Route53編～GSLB（グローバルサーバロードバランシング）～
こんにちは！ 中の人です。
以前のレシピに引き続き、今回もAmazon Route53編と題してお話していきます！
今回はRoute53を使ったグローバルサーバロードバランシングについて記述したいと思いますが、その前にAWSに関する情報をご紹介します！
米調査会社のSynergy Research Groupが行ったIaaS/PaaS等のシェアについて調査結果をPublickey様のブログで紹介されております。
IaaS部門でAWSが突出しており、ますますAWSに対するニーズが高まることを感じます！
http://www.publickey1.jp/blog/13/iaasamazon36paassalesforce19synergy_research_group.html
さて、ここから本題に入りまして、今回はグローバルサーバロードバランシングの設定についてお話していきたいと思います。
グローバルにサービスを展開されている場合、静的なホームページであればCloudFront（CDN）を使う事で世界中にあるエッジロケーションからの配信が可能ですが、動的なサービスの場合はそれが利用できません。
そこで Route53を使ったグローバルサーバロードバランシングを利用します。これにより、動的なサービスについてもグローバルに展開することが可能になります。
１． 全体の構成は以下のようになります。
各リージョンにあるRoute53から各EC2に対してレイテンシーのチェックを定期的（30秒間隔）に行い、レイテンシーが低いEC2に対して振り分けるような仕組みです。
２． 事前準備として2台以上のEC2を用意します。
可能であれば、複数のリージョンをまたいでいることが好ましいです。
Management ConsoleよりRoute53に移動し、「Hosted Zone」を選択し、該当ドメインの編集画面に遷移します。
３． Aレコードを例に説明します。以下の様に設定を行います。
レイテンシ・ベース・ルーティングは、一般的な "A"、"AAAA"、"CNAME"、"TXT"のDNSレコードタイプに加え、Route 53特有の"ALIAS to A"、"ALIAS to AAAA"レコードタイプにおいて利用可能です。
<東京リージョン用>
<シンガポールリージョン用>
Routing Policy Latencyを選択します。
Region 対象があるリージョンを選択します。
Set ID 任意の名称を入力して下さい。
４． たったこれだけでGSLB（グローバルサーバロードバランシング）の設定が完了です！！
それでは最後にきちんと設定ができているか確認してみましょう！
東京リージョンのEC2から「nslookup」コマンドを実行すると東京側に設定したIPが確認できます。
次にシンガポールリージョンのEC2からも「nslookup」コマンドを実行してみるとシンガポール側に設定したIPが確認できます。
いかがでしたでしょうか？
上記でご紹介したように簡単な作業をするだけでGSLB（グローバルサーバロードバランシング）を行うことができるので、ぜひおこなってみてください。
次回は、「Amazon Route53編～Route53でラウンドロビン（simple/weighted）～」と題して、Route53の持つもう1つの機能 ラウンドロビンについてお話していきたいと思いますので、お楽しみに！
Amazon VPC編 ～VPN接続～
こんにちは！JQです。
前回は『AWS Command Line Tool (Developer Preview)を使ってみよう！』ということでご紹介しました。
今回はまた、以前のレシピでも記述してあるAmazon VPC編に戻りまして、PivateSubnetでVPCを構築して、VPN接続をしてみたいと思いますが、
その前に『AWSの新しいセキュリティオプションに関する情報』をご紹介します。
先日、AWS CloudHSMサービスが米国東部およびEU西部のリージョンでリリースされました！
こちらはHardware Security Module(ハードウェア・セキュリティ・モジュール)という安全な鍵の保管と暗号化操作のセキュリティオプションになります。
※AWS公式ブログの記事はこちら
VPCがデフォルトになる等、セキュリティに関する注目はどんどん高くなっております。
さて、ここから本題である『VPN接続の設定について』記述したいと思います。
それでは早速やってみましょう！
※今回はYamahaのRTX1100環境で行なっております。
1.テンプレートを利用してPrivateSubnetのVPCを構築します。
Customer GatewayであるRouterのグローバルIPを指定します。
下の項目ではローティングをダイナミックか静的か選択します。
完了まで待ちましょう！
2. configurationのダウンロード
作成完了後、以下の画面の「Download Configuration」を選択して設定ファイルをダウンロードします。
使用しているRouterの会社と機種を選択して雛形の設定ファイルをダウンロードします。
上記の設定ファイルが正しく設定してVPNコネクションのステータスがUPに変わっていれば成功です！
これでVPN接続の設定は完了です。
いかがでしたでしょうか？
設定ファイルの雛形をダウンロードすることで簡単に設定が出来ますので、ぜひおこなってみてください！
次回は、「Amazon VPC編～Natインスタンスについてパート①～」と題して、『VPCのNatについて』お話したいと思います。
お楽しみに！
AWS Command Line Interface (Developer Preview)を使ってみよう！
こんにちは！ JQです。
前回は『AWS SDK Rubyを使ってみよう！』ということでお話しました。
今回は『python版のCommand Line Tool』についてお話したいと思いますが、
その前にAWSの更新情報をご紹介します。
先日、AWSのAmazon Linux AMI 2013.03が利用可能となりました！
今回のVersionの変更点としては以下になります。
● Kernel 3.4.37へのアップグレード
● OpenSSH 6への移行。
● OpenSSL 1.0.1の追加。
● 新しいAWS Command Line Interfaceのデベロッパープレビュー版の追加。
● いくつかの新しいパッケージの追加と既存パッケージの更新。
さらに詳しい情報がお知りになりたい方は、Amazon Linux AMI 2013.03 リリースノートをご覧下さい。
最初からCommand Line Toolが入っているのは助かりますね！
さて、ここから本題に入りまして、『Command Line Toolに関して記述したいと思います。
今までのCommand Line ToolはJavaで構築されており、JVMがバックグラウンドで起動しておりました。
新VersionのAmazonLinuxで追加となったAWS Command Line Interfaceはpythonで書かれており、
Java版よりかなり軽量化がされております。
※対応サービス状況
そのpython版を今回はローカル環境のCentOS 6.4の環境で試してみます。
1.pythonのモジュール管理のインストール
easy_installを利用する為、python-setuptoolsをyumでインストールします。
[crayon-61e521716d9ba049069137/]
2.awscliのインストール
インストールしたモジュール管理のeasy_installでCommand Line Toolをインストールします。
[crayon-61e521716d9c1841833502/]
3.環境設定
AWSへの接続情報とリージョンを指定したファイルを作成します。
例、awscliconfig.txt
---------------------------------------------------------------------------------------
[default]
aws_access_key_id = xxxxxxxxxxxxxxxxxxxxx
aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxx
region = ap-northeast-1
---------------------------------------------------------------------------------------
上記へのパスをprofileに等で変数にエクスポートされるようにします。
[crayon-61e521716d9c5226976026/]
これで設定は完了です。
5.それでは実際にコマンドを叩いてみましょう！
※ヘルプ
[crayon-61e521716d9c8003635659/]
※EC2コマンドヘルプ
[crayon-61e521716d9cb762299893/]
※インスタンス情報取得
[crayon-61e521716d9ce185813355/]
また、下記のコマンドを叩く事でコマンドの補完を有効にする事が出来ます。
[crayon-61e521716d9d1618931707/]
下記の様にTabを叩く事で入力補完がされます。
[crayon-61e521716d9d3733835360/]
いかがだったでしょうか？
インストールに成功している場合は、正常に結果が返ってきていると思います。
他にもプロファイルの切替など出来る事はたくさんあります。
更に詳しい情報が知りたい方はgithubでソースが公開されている為、そちらをご確認頂ければと思います。
https://github.com/aws/aws-cli
次回は『Amazon VPC編 ～VPN接続～』と題してお話したいと思います。
お楽しみに！
Amazon RDS～リードレプリカ編パート②～
こんにちは！Rookieです。
Amazon RDS編のレシピも今回で6回目となりました。
なお以前のレシピは、下記を参照ください。
■Amazon RDS編～DBインスタンスを立ちあげてみよう！～
■Amazon RDS編～EC2インスタンスからDBインスタンスへの接続～
さて今回もパート①のレシピに引き続き、Amazon RDS～リードレプリカ編パート②～と題してお話をしていきます。
今回のパート②では、パート①で作成したリードレプリカをマスターに昇格させてみたいと思いますが、その前にAmazon RDSに関する情報をご紹介します！
先日、AWSの方でAmazon RDS for SQL Serverが、SSLのサポートを開始したと発表がありました。
これにより、保存されたデータだけでなく、転送中のデータも保護することができるようになり、以下のようなことが可能になります。
・SQL Server SSLはアプリケーションサーバとRDSデータベースインスタンス間を行き来するデータの保護
・SQL Serverの暗号化機能を使った、保存済データの保護
・Amazon RDS for SQL ServerのVirtual Private Cloud (VPC)内起動による、ネットワーク分離
今回のSSLサポート開始により、Amazon RDSのセキュリティ性もますます高まってきたと感じます。
さて、ここから本題に入ります。
パート①ではリードレプリカの作成までをおこないましたが、今回はその作成したリードレプリカをマスターへ昇格させてみたいと思います。
このAmazon RDS リードレプリカの昇格機能には、
①インデックスの作成・再作成等のDDL操作の高速化
②大きなデータベースを複数のマスターに分けるシャーディング
③MultiAZとバックアップ時へのリカバリ以外の方法を提供
という3点のメリットがあります。
また、今回の昇格機能を実行することで下記のことが起こります。
・旧マスターからのレプリケーションの停止
・昇格機能を実行したリードレプリカは"スタンドアロン"のデータベースインスタンスになる
では実際にリードレプリカのマスターへの昇格作業をおこなってみましょう！
1. AWS管理コンソールにログインしてサービスで「RDS」を選択、下記画面を開き左メニューの「DB Instances」をクリックします。
2. DBインスタンス一覧から対象のリードレプリカを右クリックして、「Promote Read Replica」を選択します。
3. 以下の項目の設定をします。
・ Enable Automated Backups:自動バックアップ有効または無効
・ Backup Retention Period :バックアップ保持期間
4. ※リードレプリカの昇格前に下記の注意画面が表示されます。
ここで表示されるのは、「ソースとなっているマスター側のトランザクションを全て終了させましょう！」という注意になります。
リードレプリカは、マスターから非同期にレプリケーションをしているので、マスターのメモリ上にあるデータやトランザクションを完了させないとレプリカへの反映が完了しません。
できるだけ最新状態にしてから昇格させるべきですので、事前におこなっておきましょう！
5. DBインスタンス一覧の昇格作業をおこなったリードレプリカのステータスが「available」になっていることを確認します。
また、その元々リードレプリカだった新マスターの詳細を画面下部の「Description」で見てみると、
「Read Replica Source」の項目が「None」となっており、独立したデータベースとなっていることが確認できるかと思います。
これで、リードレプリカの昇格作業は完了です！
いかがでしたでしょうか？
今回紹介したリードレプリカの昇格機能を活用すれば、データベース運用の幅もさらに広がるかと思いますので是非、確認してみてください！
次回もAmazon RDS編です。
次回は、「Amazon RDS編～Amazon VPCでRDSを起動してみよう！～」と題して、Amazon VPCでRDSを起動してみたいと思いますのでお楽しみに！
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-61e521716f634309314280/]
2.gemコマンドにて「aws-sdk」の依存関係も含めてインストールが可能です。
[crayon-61e521716f63c987574466/]
これでインストールは完了です！
3.インスタンス一覧を取得するプログラムは以下のような物になります。
[crayon-61e521716f63f525432653/]
4.インスタンスを作成するプログラムは以下のような感じになります。
[crayon-61e521716f646565303616/]
オプションで他にも様々な指定が可能です。
例、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～リードレプリカ編パート②～」ということで、
作成したリードレプリカをマスターに昇格させてみたいと思いますのでお楽しみに！