今回は、先日書籍(Amazon Web Servicesクラウドデザインパターン設計ガイド)の発売も発表された Cloud Design Pattern(CDP)の記事になります。 対象は「Floating IPパターン」です。 このパターンの「注意点」に下記のような記載があります。 該当EIPにSSH接続している場合は同じIPでサーバが入れ替わることになるので、なりすましの可能性が警告されログインできないことがあります。 具体的には、EIPを別のEC2に付け替えるとSSH接続時に下記のようにサーバが今までのものと違うため警告が表示されログインできない状態になります。 $ ssh -i suz-lab_ap-northeast-1.pem -l root xxx.xxx.xxx.xxx @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
今回は、先日書籍(Amazon Web Servicesクラウドデザインパターン設計ガイド)の発売も発表された Cloud Design Pattern(CDP)の記事になります。 対象は「Ondemand Diskパターン」です。 このパターンの「実装」に下記の記載があります。 アタッチ後、使用しているファイルシステムのリサイズコマンド(例えばresize2fs)で 新しい容量まで領域を拡張する。 こちらの内容は、本ブログでも様々な形で紹介してきていたので、本記事で、まとめ直してみました。 ▼Linuxで拡張する場合 CDPでも紹介されているresize2fsを利用します。 詳しくは「EBSの容量を増やす」の記事が参考になります。 ただし、EBSをパーティション分割している場合は、上記の方法だけではうまくいかず、 「パーティション分割されたEBSをresize2fsで拡張」の記事で紹介し
今回は、Cloud Design Pattern(CDP)の記事になります。 対象は「URL Rewritingパターン」です。 このパターンの「実装」に下記の記載があります。 Apacheのフィルターモジュール(mod_ext_filter/mod_sed)やプロキシーとして用意したNginxなどで動的に書き換えることも可能。 mod_ext_filterに関しては、mod_ext_filterで画像などのURLをCloudFrontのものにの記事で 紹介しているので、今回は同様のことをmod_sedで実現してみました。 はじめにインストールですが、下記のようにatomicリポジトリを登録してyumで簡単にインストールできました。 # rpm -Uvh http://www6.atomicorp.com/channels/atomic/centos/6/x86_64/RPMS/atomi
今回は、Cloud Design Pattern(CDP)の記事になります。 対象は「Cloud DIパターン」です。 このパターンの「利点」に下記の記載があります。 EC2インスタンスの構築だけでなく、AMIやスナップショットの自動取得を行う仕組みを作る場合にも利用できる。 そこで今回は、EC2のタグ情報を利用してスナップショット(AMI)の取得や世代管理を行なう PHPスクリプトを作成しました。 このPHPスクリプトを定期的に実行することで、AWSマネジメントコンソールにてEC2のタグを編集し、スナップショット(AMI)の取得対象にするか、世代をどれだけ残すかということを容易に管理することができます。 PHPスクリプトは長いので最後に掲載することとし、先に仕様をまとめておきます。 指定のアカウント・リージョンのすべての稼働しているEC2に対して実施 ○稼働はinstance-state
今回は、Cloud Design Pattern(CDP)の記事になります。 対象は「Multi-Datacenterパターン」です。 このパターンの「注意点」に下記の記載があります。 AZ間の通信速度が気になる場合は、アプリケーションやHAProxyなどのミドルウェアで基本的には同一AZのEC2と通信するようにし、そのEC2が障害時に別AZのEC2と通信するように制御することも可能である。 そこで今回は、HAProxyを利用して通常は同一AZのEC2と通信するところを、そのEC2に障害が起きた場合、別AZのEC2と通信するような設定を試してみました。 HAProxyの設定は、HAProxyを用いたRead Replica(RDS)の振り分けの記事で紹介したbackupオプションを利用することで簡単に実現することが可能です。 尚、backupオプションは、backupオプションが付与されて
今回は、Cloud Design Pattern(CDP)の記事になります。 対象は「Scheduled Autoscalingパターン」です。 このパターンの注意点に下記のような記載があります。 バッチ処理が終了する時刻を決めるのが難しい場合は、EC2上のバッチ処理が終了してから、EC2自身が自分を終了する 作り込みを行う方法もよく用いられる。 今回は、上記の方法を実際に作り込んでみました。 はじめに、Auto Scalingにてスケールアウトに使われるAMIの作成です。 このAMIはEC2起動時にバッチ処理を開始し、バッチ処理が終了する時に自分自身(EC2)もターミネートされるようにする必要があります。 具体的には、起動時にバッチ処理(/opt/suz-batch/bin/run-batch)が開始されるように、下記の起動スクリプト(/etc/init.d/suz-batch)を用意し
今回は、Cloud Design Pattern(CDP)の記事になります。 対象は「Read Replicaパターン」です。 このパターンの実装に下記のような記載があります。 複数のリードレプリカを利用することでも、そのリードレプリカを複数のデータセンタに配置することも可能だが、アプリケーション側でその振り分けを行う必要がある。HAProxyやMySQL Proxy等のミドルウェアを用いても良い。 今回は、HAProxyを用いたリードレプリカの振り分けを試してみました。 まずは、下記のRDS(MySQL)群を用意します。 Master (master.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com) Read Replica 1 (slave1.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com) Rea
今回は、Cloud Design Pattern(CDP)の記事になります。 対象は「Multi-Serverパターン」です。 このパターンの利点の一つに下記があり、実際に試してみました。 ELBとAuto Scalingの設定により、ある一定数のサーバ(例えば、3台)を設定して、 常に3台で稼働させることを行える。 はじめに、Auto Scalingで起動するAMIを用意します。 このAMIは下記のように起動時にApacheが立ち上がり、/index.htmlでアクセスできるようにしておきます。 # yum -y install httpd # chkconfig httpd on # chkconfig --list httpd httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off # /etc/init.d/httpd start # cat /va
CDP(Cloud Design Pattern)の新パターンWeighted Transitionに触発され、このパターンの主役となるプロダクトRoute 53のルーティング系機能を改めて試してみました。 はじめに、Route 53には下記のように3種類のルーティングに関する機能(Routing Policy)が用意されています。 ▼simple 通常のDNSの機能です。 同一DNS名にAレコードを複数登録することで、DNSラウンドロビンが実現されます。 ▼weighted DNS名に対するターゲット(IP/DNS名)の選択に重みを付与することができ、 DNSラウンドロビンよりも柔軟にアクセス分散させることが可能です。 ▼latency DNS名に対するターゲット(IP/DNS名)の選択を最もレイテンシーが低い場所にします。 同一DNS名にリージョンが違う複数のEC2を登録した場合、アク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く