2015年8月10日月曜日

Googleを怒らせると仕事にならない

こんにちは。
今回のテーマはクラウドというよりも検索といった方が良いかもしれませんね。

皆さん、普段ググッてますよね。
googleで検索をする事をググる(ggr)などというのは周知のことかと。

先日とある環境でgoogleから検索拒否を食らって検索出来なくなる自体が発生しました。
どうやら同じサブネット内にgoogleへロボットアクセスをしている人が居たらしく、
googleさんから人間のアクセスではないやろ?的な注意をされました。

最初の注意としては人とロボットを区別する為に、表示されるコードを入力させるというもの。
表示されるコードを入力すると普通に検索出来るように戻ります。
これを何回も繰り返すと、どうやら検索拒否となるようです。

で、実際に検索拒否になったときのメッセージがこちら。






まぁ、Yahoo!も同じエンジン使っているので、Yahoo!で検索をすれば良いのですが、
普段からググッている人は、もう完全にしみこんでるわけですね。
従って、Yahoo!で検索すればよくない?といいながら、Yahooをググッてるわけで。
この瞬間に気付きましたね。(あ、こりゃ仕事にならないな。)と。

普段ググれる事が当たり前な分、ありがたみもなく普通に使っていましたが、
ググれなかった時の対応というのも、検討しておかないといけないかもなぁ。
 と、ふと思いました。

一応、google、Yahoo、bingでブラウザを分けるというやり方を導入しました。
googleはchrome、YahooはFirefox、bingはIEという感じで。
同様のことが発生した際にはブラウザを変更して検索、対応することに。

え?検索プロバイダを変更するというやり方がスマート?
確かにそうなんですが、実際にこの局面になると、検索プロバイダの変更をググるという事態になったので、
やり方を知ってる人は良いんですが、パッと思いつかない人はブラウザ分けておけばいいと思います。

ちょっとした小ねたでした。

それでは、よいクラウド構築を。

2015年8月7日金曜日

S3へFailoverさせてソーリーページを表示させる


運用しているとsorry pageを表示させたいという時があると思います。
S3をWebsite Hostingさせていればソーリーページの運用も出来ます。

ソーリーページであればそこまで大きなファイルにならないでしょうし、
静的なものだと思いますので、S3のWebsite Hostingは使い勝手が良くなります。
料金の計算方法やWebsite Hostingのやり方は以下のエントリーをご覧下さい。
"S3でWebページを作る(Website Hosting)"
http://cloudyarouze.blogspot.com/2015/08/s3webwebsite-hosting.html

方法として今回はAWSのRoute53を使用します。
Route53にはFailoverの機能がついている為、この機能を使えば簡単に実装出来ます。

今回は以下のような図を想定しています。



メインで稼動しているのはEC2のインスタンスですが、何かしら障害があった際には、
DNSFailoverでDNSをS3へ向かせるというシナリオになります。
切り替えには1分~3分程度掛かりますので、こちらが許容である必要があります。

今回の設定の前提条件としては、indexに対してヘルスチェックを行って、
コードの200が返ってきている状態で設定しています。
別途ヘルスチェック用のページ等を用意する場合は読み替えて下さい。
また、EC2instanceとS3は既に設定済みの状態で進めます。
ドメインは以下を想定して作成しています。
EC2instance用:test.pc-bto.info
サービス用(Failoverさせるドメイン):failover.pc-bto.info
※通常、静的ウェブホスティングではindex documentにindexファイル、
  error documentにはエラー時のファイルを指定して表示させますが、
  ソーリーページはどのページへリクエストが来ても表示させるようにしたいため、
 S3のWebsite Hostingの設定でerror documentとindex document両方に
  同じファイルを指定します。これでどのようなパスでリクエストが来てもソーリーページが表示されます。


今回のチェックポイントとしては、
1.Route53でヘルスチェックの設定をする
2.Route53でEC2インスタンスのAレコードを設定する
3.Route53でEC2インスタンスのCNAMEレコードをFailover(primary)で設定する
4.Route53でS3のエンドポイントのCNAMEレコードをFailover(secondary)で設定する

CNAMEとAレコードを同名で登録することは出来ません。
S3はAレコードで登録する事は出来ませんので、EC2instance側をCNAMEに合わせる形にします。
従って、EC2instanceは1度Aレコードを登録する必要があります。

それでは、実際にやっていきます。

まずはヘルスチェックを作成します。



  


Nameには適当に名前を入れます。
今回はEC2instance側は1台の想定でやっているため、IPAddressでInstanceのIPを指定。
ELBの場合は、一旦CNAMEで別のドメイン名にした後、Domain Nameで登録することで対応可能。
pathは省略してもindexがあれば問題ありません。
今回は確認を早くしたいので、ルールはちょっと厳しめにしました。
10秒毎(fast)にヘルスチェックを行い、2回失敗したらNGという形にしています。
全部出来たらCreateをクリックして作成します。



追加したルールが表示されていることを確認します。




次にAレコードを登録します。
Hosted ZonesからCreate Record Setでレコード追加していきます。
Nameにはサーバ用のドメインを付けます。
ValueにはEC2instanceのIPを記載し、createボタンでレコードを確定します。




次に実際のサービス用ドメインをCNAMEレコードで登録します。
Nameにはサービス用ドメイン名(Failoverさせたドメイン名)を入力します。
TypeはCNAMEを選択。TTLはフェイルオーバー用のレコードになりますので60にします。
Valueには先ほど登録したAレコードのドメイン名を入力。
RoutingPolicyをFailoverに変更 。
Associate with Health CheckをYesにして、先ほど作成したヘルスチェック名を選択します。
この設定でPrimary側で問題が発生した際に検知できるようになります。




次はFailover先、Secondaryの設定をします。
NameとTypeはPrimaryと一緒です。
TTLを60秒にしてValueにはs3のエンドポイントを指定します。
Routing PolicyにFailoverを指定して、Secondaryにチェックを入れます。
SecondaryにはHealth Checkは不要です。この状態でCreateします。



これでS3へのフェイルオーバーの設定が完了しました。






切り替えの時間がそこまでタイトでなければ、良い方法ではないでしょうか。




それでは、よいクラウド構築を。

2015年8月6日木曜日

S3でWebページを作る(Website Hosting)

今更(2015/08/06現在)ですがS3のWebsite Hostingです。

静的なページであればS3だけでWebサイトを公開可能(ウェブサイトホスティング)です。
そもそもS3って何?という方は以下を参照願います。
http://aws.amazon.com/jp/s3/

AWSは勝手にどんどん値下げしてくれるので、知らないうちにどんどん安くなっていきます。
リリース当時は10円でウェブホスティングとか謳っていた記憶がありますが、
もはや1GBで4.2円程度。(1$125円で計算)
たとえドル円レートが1$150円になっても5円を切ってます。
S3にはリクエスト課金があります。
たとえばHTMLと画像が4点で構成した合計1MB程度のペラ1のページを作った場合、
ファイルが全てS3に置いてあれば1回の表示にHTML+画像4点で5リクエスト必要となります。

月間アクセス数が100万程度であれば、500万リクエストです。
この記事を書いている段階で1万リクエストで$0.0037なので、$1.85で231.25円となります。

トラフィックがこのケースだと100万x1MBで約977GBになります。
無料分の1GBを抜いて976GBとした場合、$136.64で17080円となります。
このケースでは、単純計算で17080+231.25+4.2=17316円かかる形となります。

やはりAWSはトラフィック次第で高くなるんですよね。
Cloudfrontを使っても同じくらいの価格です。

月間1万リクエストくらいで300KB位のページであれば、60円程度です。
ここまで落ちると最適なサイトパターンは大体読めてくると思います。

イメージとしては以下。簡単ですが・・・。(Route53は使わなくてもok)






実施方法は下記に公式ドキュメントがあります。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html


肝心の実施方法ですが、注意する点は3つです。
1.ドメイン名でS3バケットを作る
2.Website Hostingの設定をする
3.バケットポリシーを設定する

それではS3にバケットを作ります。
バケット名はHTTPアクセスさせたいドメイン名(FQDNの最後のドットを抜いたもの)です。



作成したらWebsite Hostingの設定をします。
ここで青線のエンドポイントをコピーしておきます。(後でDNSに登録します。)
indexのファイルを指定します。また、エラー時に特定ファイルを表示させたい場合は、
error documentの指定もします。設定しない場合はS3のエラーページが出ます。



次はVirtualHost出来るようにバケットポリシーを設定します。



バケットポリシーは公式に記載されている通りで問題ありません。
青線部分を今回作成したバケット名(要するにドメイン名)に変更します。





あとはこのバケットにindex.htmlをアップロードすればS3側の準備は完了。
さきほどコピーしたエンドポイントをCNAMEとしてレコード登録すればアクセス出来ます。


それでは、よいクラウド構築を。

2015年8月5日水曜日

IDCFクラウドでGitLabを構築

久しぶりにブログを書きます。
今回は500円でGitLabを構築します。
今更ですが、IDCFさんが連休前に宿題として出されていたものですねw

IDCFクラウドのLight.S1を用意します。 
ubuntuが楽なのでubuntuで作りましょう。 
ファイアウォール等の設定はめちゃ楽ガイドを見て頂ければ。 
http://www.idcf.jp/cloud/pdf/IDCFCloud_installation_guide.pdf 

ちなみにめちゃ楽ガイドではCentOS6.5で記載されています。 
今回この記事で使用しているのはubuntu14.04です。 


gitlabの以下URLでOSを選択する画面になりますので選択します。 
https://about.gitlab.com/downloads/ 

あとは記載通りです。(約10分) 
IDCFクラウドはrootログインなのでsudoの部分は消して良いでしょう。 

apt-get install openssh-server ca-certificates postfix
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash
apt-get install gitlab-ce
gitlab-ctl reconfigure

※自動的にミドルウェアも全部入れてくれます。 
※2015/05/12時点で「GitLab 7.10.4」がインストールされます。 

ちょっとmemoryが足りなくなるのでswapを1G位積んどきましょう。 

dd if=/dev/zero of=/swap bs=1024 count=1048576
mkswap /swap
swapon /swap
echo "/swap swap swap defaults 0 0" >> /etc/fstab

※swap積まないとrails側で処理出来ず、500エラーになります。 

あとはブラウザでアクセスします。 
※Passwordを変更する為に直ぐにアクセスして変更しましょう。 
http://IPアドレス/ 
Username: root 
Password: 5iveL!fe 


はい。これで500円gitlabが出来ました。 

それでは、よいクラウド構築を。