2012年12月02日

VPC環境構築をしてみた

かなり前の記事から間が空いてしまいましたが、久しぶりの更新です。

急遽、VPC環境の構築をすることになり、どうしたものかと試行錯誤していたところ、いいタイミングでsuz-labブログに「CloudFormationでVPCの構築」という記事があったので、今回は記事の流れに沿ってCloudFormationを使い、VPC環境の構築をしてみました。

やることは非常に簡単です。
以下の手順でそのままVPC環境が作成することができます。

(1)AWSコンソールへログイン
(2)CloudFormationを開いて、「Create New Stack」もしくは「Create Stack」をクリック
・Create New Stack
vpc_1-1.gif

・Create Stack
vpc_1-2.gif

(3)Stack Name(何でもOKです)を入力し、Provide a Template URLを選択して、https://s3-ap-northeast-1.amazonaws.com/template.suz-lab.com/template/suz-lab_vpc-basic-0.0.1.json を入力後に「Continue」をクリック。
vpc_2.gif

(4)画面遷移して、VPCCIDRを入力します。今回は同じように10.10を第2オクテットまで入力して、「Continue」をクリック。
vpc_3.gif

(5)画面遷移後のKeyとValueを入力する項目がありますが、何も入力せずに「Continue」をクリック。
vpc_4.gif

(6)今まで入力した内容の確認画面が表示されるので、問題がなければ「Continue」をクリック。
vpc_5.gif

CloudFormationが開始されると、StatusがCREATE_IN_PROGRESSになり、完了までしばらく待つ必要があります。
vpc_6.gif
ちなみに僕の場合は18分待ってCloudFormationのStatusがCREATE_COMPLETEに変わり、実際にVPCのSubnetsを確認したところ問題なくSubnetが作成されていました。
(待ってる間に不安な場合は、作成経過をCloudFormationのEventsにて確認できます。)
vpc_7.gif

尚、今回は東京リージョンで作成したので3ゾーンに渡ってSubnetが作成されており、
1ゾーン当たり6個のSubnetで、合計18個のSubnetが出来ました。
vpc_8.gif
※Subnetのアドレス体系等については、「VPCのSubnetのCIDRの設計方針(一例として)」を参照。

CloudFormationのテンプレートはjsonで出来ているので自分自身で作成することが可能です。
勿論、構築する環境によっては構成がかわると思いますが、このjsonテンプレートをベースにすれば、構築したいVPC環境も簡単に構築することが出来るかもしれません。

短い時間で、簡単にVPC環境を構築出来たので、非常に助かりました!
posted by memo4me at 22:12 | Comment(0) | TrackBack(0) | aws | このブログの読者になる | 更新情報をチェックする

2011年06月15日

Route 53でGoogle Appsの所有権をTXTレコードで確認

Google Appsを利用する際には、サービスを有効にするために、
利用するドメインの所有者をGoogle側で確認する必要があります。

Google側で、ドメインの確認方法をいくつか用意していて、
4種類の中から選ぶことができます。

ドメインの DNS 設定で TXT レコードを作成します。
この方法では、ドメイン ホストのウェブサイトでドメインの DNS 設定にアクセスする必要があります。

ドメインのウェブサーバーに HTML ファイルをアップロードする
この方法では、ドメインのウェブサーバーにファイルをアップロードできる必要があります。ドメインの DNS 設定にアクセスできない場合は、この方法をお試しください。

タグをホームページに追加する
この方法は、一部のお客様のみが利用できます(導入中のもう 1 つの新しい方法です)。ドメインのウェブサーバーにアクセスできる必要がありますが、アップロードできる必要はありません。サーバー上のファイルへの書き込み権限があり、新しいファイルをアップロードできない場合は、この方法をお試しください。

Google アナリティクス トラッキング コードを使用して確認する
この方法では、Google Apps を申し込むのと同じドメインに Google アナリティクス アカウントを持っている必要があります。

※詳細は、ドメインの所有権を確認のドメイン確認オプションの中に書いてあります。

尚、今回はWebサーバを利用していないため、TXTレコードを設定する形で進めてみました。

設定については、AWSのRoute53を利用する形ですが、
Googleドキュメントのスプレッドシートでの設定が簡単そうなので試してみました。
※設定方法は、上記記事で確認してください。

TXTレコードで、所有権の確認をする場合、Google Appsが以下のような文字列を発行します。
google-site-verification=XXXXXXXXXXXXXX

この文字列をvalueに設定する形で、DNSレコードを追加します。

img_route53_01.gif

上記のように記述した内容にたいして、
Submitするとエラーが表示されてしまいました。

img_route53_02.gif

もしかしたら、スプレッドシートでの設定がダメ?ってことも考慮して、
今度は、R53foxを使って同様の設定を試してみました。
※R53foxの利用方法は、R53 Fox(新機能に対応済み)を利用してみましたを元に行っています。

スプレッドシートで行った際の設定をR53 Foxでも同様に行ってみたところ、
やはり、こちらでもエラーが表示されてしまいました。

img_route53_03.gif

TXTレコードを登録すれば問題なかったと思うのですが・・・。
登録が出来ないとなると承認がされないわけで、困りました・・・。
ちなみにvalue値の設定は、以下の2種類試しています。
google-site-verification=XXXXXXXXXXXXXX

"google-site-verification=XXXXXXXXXXXXXX"


何故登録することが出来ないかの原因は分からないですが、
ダメ元で、以下のGoogle AppsのMXレコードを登録してみたところ
10 aspmx.l.google.com.
20 alt2.aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
30 aspmx2.googlemail.com.
30 aspmx3.googlemail.com.
30 aspmx4.googlemail.com.
30 aspmx5.googlemail.com.

上記のMXレコードは、無事登録することが出来ました。
じゃあ、MXレコードを登録した後なら、TXTレコードも登録出来るだろうと、
またダメ元でTXTレコードを登録すると、無事登録出来ました。
これにより承認され、利用出来る形になりました。

最終的には、R53 Foxで登録を行ったのですが、
ポイントとして、
(1)MXレコードを先に登録する。
(2)value値は、下記のようにダブルクォーテーションで囲った上で設定
"google-site-verification=XXXXXXXXXXXXXX"

という流れで登録できました。

ただただ府に落ちない点として、
そもそもMXレコードを登録しないと確認が出来ない仕様でしたっけ・・・??
いろいろ探してみましたが、どこにもそんな内容は書かれておらず・・・。

とりあえずは、無事に出来てよかった。
posted by memo4me at 23:15 | Comment(0) | TrackBack(0) | aws | このブログの読者になる | 更新情報をチェックする

2011年06月08日

CDNホスティングからS3ホスティングへの乗り換えについて

前回の記事(Amazon S3とCloudFrontを利用したホスティングの正しい利用方法)で書いた
ANDROID IRETをCDNホスティングからS3ホスティングへ乗り替えました。

尚、ANDROID IRETは、東京リージョンがOPENする前に作成しているため、
シンガポールで作成しているので、東京リージョンでS3ホスティングをする形で進めたいと思います。

まずCDNホスティングについてですが、S3上に置いているデータをオリジンとして、
CDNにキャッシュとしてデータをブラウザ上で、表示させるものです。
この状態からS3ホスティングをする場合、同じリージョンであれば、
設定しているCloudFront削除し、DNSの向き先をS3に変更すれば完了です。

しかし今回は、下記の理由により非常に手間がかかります。
手間がかかる理由として、
(1)リージョンが変わる
(2)すべてのリージョンで、同じバケット名を作成できない
という点です。

まずリージョンが変わるので、バケットを作成しないといけないのですが、
同じ名前でバケットの作成でが出来ないため、既存のバケットを削除する必要があります。
しかし、そのまま消してしまうとサイトが見れなくなってしまうので、
代替サーバを用意し、一時的に移動する必要があります。
※今回は、EC2に領域を作成し、移行しました。

そして、既存のバケットを削除した後、ホスト名でバケットを作成しようとすると
下記のように怒られてしまいました。

img_notice.gif

上記の場合、少し時間を開けると、同じバケット名が作成出来るので、
少し時間を空けて、S3ホスティングの準備を行います。
※今回は、1時間程度空けた後、作成が出来ました。

バケットが出来れば、あとは設定のみです。
まずは、バケットを右クリックして、プロパティを開きます。
そして、WebSite機能を利用できるように設定します。
※error.htmlが無い場合、403が表示されるので、アップロードする必要があります。

img_website.gif

最後にパーミッション設定で、Everyoneを追加します。

img_permissions.gif

これでS3ホスティングの設定は終了です。
設定にミスがなければ、S3で発行されるURLでページが表示されます。
今回は、下記のURLです。
http://www.android-iret.com.s3-website-ap-northeast-1.amazonaws.com/

バケットで設定したドメインで表示するには、
CNAMEで設定すれば完了です。

リージョンが変わる点がなければ、バケットを削除する必要もないし、
簡単にS3ホスティングを始めれますね。
posted by memo4me at 12:00 | Comment(0) | TrackBack(0) | aws | このブログの読者になる | 更新情報をチェックする

2011年05月16日

Amazon S3とCloudFrontを利用したホスティングの正しい利用方法

AWSのAmazon EC2を利用せずに、静的ファイル(HTML/CSS/JS/画像/動画/Flashなど)のみを対象としたホスティングを行うことが可能で、
Amazon S3を利用した「S3ホスティング」とAmazon CloudFrontを利用した「CDNホスティング」の2種類の方法があります。
(読み方は、人それぞれ違うかも?)

実際にそれぞれのホスティングを利用し、気づいた点があったのでまとめてみました。

実験したサイトは、http://www.iret.co.jp/ で、以下のようにホスティングを変更してみました。
-----
一般的なDC

CDNホスティング(運用期間:約6ヶ月)

S3ホスティング(運用期間:約2ヶ月〜)
-----
※ちなみに構成ファイルは同じで、企業サイトなのでほぼ更新していません。

まず一般的なDCにデータを置いていた際、どういう状態だったかというと、
各種検索エンジンで、http://www.iret.co.jp/ の全ページがインデックスされており、
「iret」「アイレット」「アイレット株式会社」などのキーワードで1位表示。
尚、Googleで、サイトリンクが表示されていました。

上記の状態からCDNホスティングへ変更し、約6カ月運用している間に、
「サイトリンクの消滅」という現象が起こりました。
※サイトリンクの詳細は、サイトリンク - ウェブマスターツールヘルプをご確認ください。

元々サイトリンクの出ているサイトは、サーバを変更してもドメインが同じですので、
基本的サイトリンクが消滅することはありません。
しかしCDNホスティングの場合、サイトリンクは消えてしまいました・・・。

次にこの状態から、S3ホスティングに変更し、現時点で約2ヶ月間運用してみたところ、
DCで運用していた頃と同じように、サイトリンクの復活が見られました。

s3hosting01.jpg


何故CDNホスティングの場合に、サイトリンクが消えてしまうのでしょうか?
それとも、S3ホスティングとCDNホスティングで違いがあるのか?

とりあえずは、レスポンスヘッダーを確認してみました。

○S3ホスティングで運用しているサイト
s3hosting02.jpg

○CDNホスティングで運用しているサイト
s3hosting03.jpg
※2011/05現在では、ANDROID IRETは、CDNホスティングしています。

レスポンスヘッダーを見てみると、CDNホスティングの場合には、「X-Cache: Hit from cloudfront」とあり、
CloudFrontから配信されていることが分かります。
また「X-Cache」と表示されているので、キャッシュコンテンツと考えられると思います。


ではサイトリンクが出ている際のインデックス数はどうだったか?
DCに置いていた時と、S3ホスティングは、以下になります。
s3hosting04.jpg


じゃあ、CDNホスティングの場合は、どうかというと・・・
s3hosting05.jpg


結果として、CDNホスティングを利用していた場合には、インデックス数の減少し、
Googleウェブマスターツール側でも、サイトリンクは表示されていないとでていました。

Googleのアルゴリズムは公開されていませんので憶測になってしまいますが、
個人的な見解としては、上記を考慮するとCloudFrontによるCDNホスティングを利用し、HTMLファイルを置いているの場合、
キャッシュコンテンツと認識されて、サイトとして見られず、インデックス数が減少していったものと思っています。
尚、この状態を継続していく場合、インデックスが無くなるもしくはTOPページのみになる可能性も考えられるので、
他の方法でのホスティングに切り替える必要があります。

ちなみに上記でも記載しましたが、http://www.iret.co.jp/ は、S3ホスティングへ切り替えて、
約1カ月ちょっと運用したところ、サイトリンクおよびインデックス数が復活しました。
(※構成ファイルは、DCで運用していたものと同様)
元々サイトリンクが出ていたから早かったのかな...


上記に書いた内容をまとめるとS3ホスティングとCDNホスティングの正しい利用方法は、
以下のようにするのが望ましいと思います。
-----
S3ホスティング:  静的サイトまるごと。
CDNホスティング: CSSやJSといったファイルのみ。
-----

CDNなので、一般的な使い方をしてくださいってことになるんですね。

ただしCDNホスティングは、低コストで世界対応が出来るホスティングなので、
短期間集中型の静的キャンペーンサイトなら、広告でアクセスを集めてもインデックスされる必要はないので、
利用は問題ないかなと思います。

正しい使い方をしないと、痛い目をみてしまいますね。
ご利用は計画的に。
posted by memo4me at 23:35 | Comment(0) | TrackBack(0) | aws | このブログの読者になる | 更新情報をチェックする

2011年03月28日

はじめてのスケールアップ

AWSで運用しているInstanceを強力なInstanceに変えるべく、
スケールアップをしてみました。

普段サーバとかを触ることはありませんが、
すべてブラウザ内で完結出来るので、今後のためのメモしておきます。

はじめに、AWS Management Consoleへログインします。

ログイン後に、EC2タブをクリックします。
左メニューのInstancesからをスケールアップするInstance(サーバ)を右クリックでstopします。
Instanceを止めた後に、止めたInstanceを再度右クリックし、Create Image(EBS AMI)を選択。
選択すると、左メニューのAMIs内にAMIが作成されます。

作成したAMIを利用して、新しいInstanceを立ち上げる必要があるので、
AMIを右クリックして、Launch Intanceを選びます。

選択するとFloating Windowが表示されるので、
画面内の指示に沿って設定をしていきます。

はじめは、INSTANCE DETAILSです。
作成するAvailability Zone(a zone or b zone)とInstance Typeを選択して、Continueで次に進みます。
そして次に、Monitoringにチェックを入れます。
同一画面には、様々な項目がありますが、特に触る必要はないです。



次にCREATE KEY PAIRでkeyとvalueを入れる必要があり、valueにのみ分かりやすい情報を入力します。
入力が終わったら、Continueで次に進みます。



次にCONFIGURE FIREWALLでF/Wの設定を行います。
今回はスケールアップで、既にセキュリティグループがあるので、
既存のものを選び、Continueで次に進みます。



ここまで進み、今まで設定した内容に問題がなければ、Launchを押します。



Launchを押した後、左メニューのInstances内に、新しいInstanceが作成されます。
※Instanceは作成と同時に起動されます。


これでスケールアップは完了。
これ以外にも設定項目等はあるが、そこはサーバエンジニアへお願い・・・。


やってみると簡単にスケールアップできた!
次も出来ればいいけど・・・。
posted by memo4me at 23:25 | Comment(0) | TrackBack(0) | aws | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。