MEMO 4 ME

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

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

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

（1）AWSコンソールへログイン
（2）CloudFormationを開いて、「Create New Stack」もしくは「Create Stack」をクリック
・Create New Stack


・Create Stack


（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」をクリック。


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


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


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


CloudFormationが開始されると、StatusがCREATE_IN_PROGRESSになり、完了までしばらく待つ必要があります。

ちなみに僕の場合は18分待ってCloudFormationのStatusがCREATE_COMPLETEに変わり、実際にVPCのSubnetsを確認したところ問題なくSubnetが作成されていました。
（待ってる間に不安な場合は、作成経過をCloudFormationのEventsにて確認できます。）


尚、今回は東京リージョンで作成したので3ゾーンに渡ってSubnetが作成されており、
1ゾーン当たり6個のSubnetで、合計18個のSubnetが出来ました。

※Subnetのアドレス体系等については、「VPCのSubnetのCIDRの設計方針(一例として)」を参照。

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

短い時間で、簡単にVPC環境を構築出来たので、非常に助かりました！

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レコードを追加します。



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



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

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



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レコードを登録しないと確認が出来ない仕様でしたっけ・・・？？
いろいろ探してみましたが、どこにもそんな内容は書かれておらず・・・。

とりあえずは、無事に出来てよかった。

最近は、様々なソーシャルサイトが数多く存在しており、
それらのサイトへ情報を共有することが出来ます。

メジャーなところだと、twitter、facobookなどですね。
※勿論、ソーシャルボタンを用意しています。

実際にBloggerに設置しようと思ってもうまくいかないことが多々あるので、
そのままコピー＆ペーストして、設置が出来るようにソースを用意しました。

○twitter（※アカウント名だけは、自分のものを記述）

<a class='twitter-share-button' data-count='horizontal' data-lang='ja' data-via='twitterアカウント名' expr:data-text='data:title + ": "+ data:post.title' expr:data-url='data:post.url' href='http://twitter.com/share'>Tweet</a><script src='http://platform.twitter.com/widgets.js' type='text/javascript'/>

○facebook

<iframe allowTransparency='true' expr:src='"http://www.facebook.com/plugins/like.php?href=" + data:post.url + "&layout=button_count&show_faces=false&width=105&height=21&action=like&font=arial&colorscheme=light"' frameborder='0' scrolling='no' style='border:none; overflow:hidden; width:105px; height:21px;'/>

○はてなブックマーク

<a class='hatena-bookmark-button' data-hatena-bookmark-layout='standard' data-hatena-bookmark-title=' + data:post.title' expr:href='"http://b.hatena.ne.jp/entry/" + data:post.url' title='このエントリーをはてなブックマークに追加'><img alt='このエントリーをはてなブックマークに追加' height='20' src='http://b.st-hatena.com/images/entry-button/button-only.gif' style='border: none;' width='20'/></a><script async='async' charset='utf-8' src='http://b.st-hatena.com/js/bookmark_button.js' type='text/javascript'/>

○EVERNOTE

<script src='http://static.evernote.com/noteit.js' type='text/javascript'/><a expr:onclick='"Evernote.doClip({providerName:\"" + data:title + "\", title:\"" + data:post.title + "\", url:\"" + data:post.url + "\"}); return false;"' href='#'><img alt='Clip to Evernote' src='http://static.evernote.com/article-clipper.png'/></a>

○Google +1
・</head>タグ前

<script src='https://apis.google.com/js/plusone.js' type='text/javascript'>{lang: 'ja'} </script>

・設置したいところ

<g:plusone expr:href='data:post.url' size='medium'/>

※twitter、facebookk、Google +1の場合、bloggerのブログ投稿設定で追加することも可能です。

まあ、これだけあれば、十分かな。

あと、試していないですが、Bloggerの場合、タイトルとURLのタグは、
以下のようになっています。

【記事URL】 　　　data:post.url
【記事タイトル】　data:post.title

この部分を各ブログのタグに置き換えれば、なんとなく出来そうな予感がするな

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

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

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

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

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

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



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

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



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



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

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

リージョンが変わる点がなければ、バケットを削除する必要もないし、
簡単にS3ホスティングを始めれますね。

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で運用していた頃と同じように、サイトリンクの復活が見られました。




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

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

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


○CDNホスティングで運用しているサイト

※2011/05現在では、ANDROID IRETは、CDNホスティングしています。

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


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



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



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

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

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


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

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

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

正しい使い方をしないと、痛い目をみてしまいますね。
ご利用は計画的に。

開発時にApacheを利用するため、静的サイトを作成するときは、
IISを利用してサイトの作成を行っています。

今回、自分の関わっているサイトのページ数も多くなり、
共通部分を何百ページも変更してられないので、SSIを導入することにしました。

SSIを導入するとなると、サーバでSSI設定箇所に必要情報がインクルードされますが、
ローカルでもインクルードされないと表示上に問題あるかの確認ができません。
僕の環境はApacheではないためがないので、IISでSSIが使えるように設定する必要があります。

設定方法は、以下になります。
（※IIS7.0で設定です。）

(1)サーバー側インクルードを許可する
Windowsの機能の有効化または無効化よりインフォメーションインターネットサービスの
World Wide Webのアプリケーション開発機能よりサーバ側インクルードにチェックを入れて、OKを押します。

(2)shtmlでの読込が可能になったかを確認
コンピューターの管理から、インフォメーションインターネットサービス（IIS）マネージャーを開き、
ハンドラマッピングを選択して、以下の内容があるかを確認。
-----
SSINC-shtm
SSINC-shtml
SSINC-stm
-----

(3)htmlでSSIを可能にする
(2)で開いている画面より、「モジュールマップの追加」をクリック。
以下の内容を登録する。
-----
要求パス：　　　　　*.html
モジュール：　　　　ServerSideIncludeModule
実行可能ファイル：　空欄でOKです
名前：　　　　　　　SSINC-html
-----

次に、「要求の制限」をクリック
「マップ」タブを選び、チェックボックスにチェックを入れ、ファイルを選択。
そして「動詞」タブを選び、「次の動詞のうちの１つ」をチェックし、テキストエリアには、「GET,POST」と記入。
最後に「アクセス」タブを選び、スクリプトを選んでOKを押します。

(4)htmlでSSIが可能になったかを確認
(2)で開いたハンドラマッピングを開きます。
(3)の内容を設定すると、一覧の中に「SSINC-html」が入っています。

これでSSIの利用ができる状態になります。

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は作成と同時に起動されます。


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


やってみると簡単にスケールアップできた！
次も出来ればいいけど・・・。

自分自身がtwitterをどのくらい利用しているか忘れましたが、
今まで利用したSNSサービスの中では、twitterが1番長い期間利用していると思います。
次は、facebookでしょうか。

さまざまなブログの記事内に、Tweetを貼り付けてる人がいますが、
初期の頃は、画像のものでした。

今まで自分自信が、ブログ内にtweetを記載することは無いだろうと
スルーしてましたが、ついに記載する時がきたので、
忘れないようにメモしておきます。

Blackbird Pie - Twitter Media

Twitterが公式に用意しているようで、掲載したいTweetのURLを上記ページ内のフォーム入力し、
「Bake it」ボタンを押すと、ソースコードが表示されます。
表示されたソースコードをブログの記事内に貼り付けると、Tweetが表示されます。

こんな感じ。

↓


（なんかこのブログだとちゃんと表示されないみたいだけど、実際は、背景画像とか出ます。）


しかし自分で貼り付けるとは思わなかった。
やろうと思った自分にビックリ。

今まで面倒だなと思いつつやっていなかったのですが、
やっと重い腰を上げて、サイト内へcanonical属性の追加をしました。

rel="canonical"は、検索エンジンに正しいサイトのURLを認識させるために使用されるものです。
同一サイト内のコンテンツで、どうしても重複してしまうこともあるが、
canonical属性を入れることで、正しいURLを指定することが出来る。
検索エンジン各社でも随分に前から正しいURLを認識するために、導入しています。

使用するポイントとしては、分かりやすいところだと、
URLにパラメータが付く場合と付かない場合に同じコンテンツが表示される時などです。

詳細は、検索結果に優先的に表示させたいページの指定についてあたりを見るのがいいと思います。

また記述の方法は、HTMLのheadタグ内に記述するもので、
以下のようになります。

<link rel="canonical" href="http://www.hogehoge.com/">

問題点としては、正しい導入の仕方を知った上で使わないと、
インデックスが削除されたりなど面倒なことになる場合もあるので、
注意が必要になります。

すべてのコンテンツに書くのは面倒だった・・・。

日々の作業でブログの更新しますが、利用しているブログがBloggerです。
そのBloggerでは、サイトフィードの設定することが可能で、フィードリダイレクトURLを登録することが出来ます。
ちなみにサイトフィードは、設定を変えない限り、http://***.blogspot.com/feeds/posts/default といったURLがフィードURLです。

運用しているブログでは、RSS購読者数を知るべくfeedburnerを利用しているのですが、
作成したサイトフィードをBloggerのサイトフィードに登録することで、
デフォルトフィードURLにアクセスしても、設定したfeedburnerのフィードURLにリダイレクトされるようになります。

最近のサイト運用では、当たり前のようにGoogleウェブマスターツールを利用していると思いますが、
feedburnerを利用していると、Google ウェブマスターツールでサイトマップの送信数が正しい数値になりません。
私の場合、毎日26件のみ送信されていました。

更新しているブログの記事は、約200件あるのできちんとサイトマップを送信したいと思っていましたが、
下記のサイトで回避方法をみつけました。
Feedburner 導入後のサイトマップ登録エラーを回避する

2つのパラメータを利用するこで解決できるようです。
○リダイレクト回避（リダイレクトさせない）

redirect=false

○表示数制限（表示件数を500件に設定）

max-results=500

そして下記のように設定

http://***.blogspot.com/feeds/posts/default?redirect=false&max-results=500

設定したURLをGoogleウェブマスターツールへ登録し、サイトマップ送信を行うと、
無事にすべての記事を送信することができました。

記事数も500に設定しておけば、1年分はなんとかなるので、
また1年後まで放置しよう。

いやー助かりました