2015年12月31日木曜日

メール配信で送信元IPを変更しながら負荷分散をする

最近検証したネタの備忘録です。

メール配信での悩みはキャリアのブロッキングです。
複数IPを持ってタイムコントロールをしながら配信管理をする事で、
キャリアの閾値以内で収めて配信する必要があります。

これが想像以上に面倒で、しかもspam認定されると解除もとても面倒なので、
SendGrid等の安価でAPIが使えるメール配信サービスをお勧めしています。

今回はどうしても内製化しなければならず、どうにか出来ないか?という話があったので、
どうにか作れないもんかと試行錯誤してやってみました。

先日クーポンを頂いた「さくらのクラウド」で試してみます。
メールの大量配信についてはどのクラウドでも推奨事項ではないので、あくまでもテストという事で。
一応、約款を見てもspamじゃなければ問題無さそうだったのでテスト環境に採用しました。

さくらのクラウドの良いところは、とにかく柔軟に何でも作れるというところだと思います。
価格設定~コントロールパネルまで全てオリジナリティのある内容なので、
どこか独立系のイメージがあります。IDCFクラウド同様に尖がってるなぁというイメージです。

今回はIPが複数必要だったので/28で払い出されるRouterを帯域幅100Mで契約しました。
/28ですが使用出来るIPの数は11個です。
サーバはCentOS release 6.7 (Final)を1GB/1仮想コアを契約しました。

今回はpostfixを使用して、間にHAproxyを挟んで負荷分散させます。
問題は送信元IPを変更するところなのですが、こちらはpostmultiを使って解消しました。

手順は以下です。
1.サーバにIPを割り当てる
2.必要なミドルウェアをインストールする
3.postmultiでpostfixインスタンスを複数構成にする
4.リレーの設定をする

以下のような構成を作ります。
事前にDNS(mxやtxtレコード)は設定しておきます。



まずはサーバにIPを割り当てますが、今回はセカンダリIPで手っ取り早く済ませます。
-----------------------
# vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=eth0:1
NETMASK=255.255.255.240
IPADDR=[使用範囲内のIPアドレス]
# ifup eth0:1
-----------------------
同様にeth0:2、eth0:3・・・と作成していきます。

次に今回使用するミドルウェアをインストールします。
postfixはデフォルトでインストールされているものを使用するので、
必要なのはhaproxyです。
(接続確認用にtelnetを入れておくと便利です。)
-----------------------
# yum install haproxy
# yum install telnet
-----------------------


HAProxyの設定をします。
-----------------------
#vi /etc/haproxy/haproxy.cfg
listen smtp
  bind 127.0.0.1:25
  mode tcp
  balance roundrobin
  server mail2 インスタンス2のIPアドレス:25 check
  server mail3 インスタンス3のIPアドレス:25 check
  server mail4 インスタンス4のIPアドレス:25 check
  server mail5 インスタンス5のIPアドレス:25 check

listen smtp2
  bind HAProxyに設定するIP:25
  mode tcp
  balance roundrobin
  server mail2 インスタンス2のIPアドレス:25 check
  server mail3 インスタンス3のIPアドレス:25 check
  server mail4 インスタンス4のIPアドレス:25 check
  server mail5 インスタンス5のIPアドレス:25 check
-----------------------


次にpostmultiを使用した環境に変更をします。
マスターのpostfixは止めておきます。
# /etc/init.d/postfix stop

メールの受付/キューイング用にインスタンスを1つ。
そして配信用に複数のインスタンスを作ります。

postmultiでの複数インスタンス作成(例はインスタンス名postfix-mail1)
-----------------------
postmultiの構成の初期化
# postmulti -e init

postmulti構成でのインスタンス作成
# postmulti -I postfix-mail1 -G postfix -e create

作成したインスタンスの有効化
# postmulti -i postfix-mail1 -e enable

インスタンスの起動/停止
# postmulti -i postfix-mail1 -p start
# postmulti -i postfix-mail1 -p stop
-----------------------

postmultiのインスタンスでinet_interfacesにIPを指定します。
これが配信元IPとなります。
mydestinationやrelayhostの設定を行います。
postmultiのキューイング用インスタンスのコンフィグ変更点
-----------------------
inet_interfaces = 設定するIPアドレス
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, メールのドメイン
relayhost = [127.0.0.1]:25
relayhost = [HAproxyの設定アドレス]:25
default_destination_concurrency_limit = 1
default_destination_recipient_limit = 1
master_service_disable =
allow_mail_to_commands = alias,forward,include
-----------------------
配信用インスタンスは上記からrelayhostの設定を外します。

これで前記の構成が完了しました。
複数アドレスを記載したaliasを用意して、そのアドレスに外部から送信すると、
配信元IPを変更して送信される事がわかるかと思います。

まだこの状態ではセキュリティの担保等の複数問題点が残っていますが、
配信元IPを変えて送信することができました。

ここまでやって思うのは、やはりメールサーバは外部サービスが便利ということ。
メールサーバの運用は色々と面倒が多いので、内製化が必要なケースでも、
なんとか外部サービスに委託する形にもっていった方が、全員が幸せになるんじゃないかなー。
と思う次第です。

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

2015年12月30日水曜日

IDCFクラウドの新旧light.S2を比較してみる

IDCFクラウドが10月にエントリー向けのlight.S2の料金を半額に価格改定しました。
これだけでも衝撃的だったのですが、CPUのクロックアップもしており、
実質的には半額で性能倍という、これまた面白い価格改定でした。

年末でサーバー整理をしていたところ・・・なんと、旧light.S2が未だ稼働しているではないですか!
ということで、旧light.S2のサーバーを新light.S2に変更して、
今更ながら新旧でほんまに性能倍になっとるんかいな?という検証をしてみたいと思います。
ちなみに新たにlight.S2を契約すると、全て新スペックとなりますので、あしからず。

まずはCPUを見てみましょう。
model name      : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
新旧light.S2ともにCPUのモデルは変わっていないようです。
どうもクロックの制限に変化があるだけのようなので、
いつも通りWordpressに負荷をかけるやり方で確認してみます。

例のごとくyumでインストールしたLAMP環境にWordpressのver3.0をインストールします。
まずは10アクセス/10クライアントでのチェック。
#ab -n 10 -c 10 http://localhost/wordpress/

Requests per second:    6.18 [#/sec] (mean)
Requests per second:    5.56 [#/sec] (mean)
Requests per second:    5.16 [#/sec] (mean)

Requests per second:    6.50 [#/sec] (mean)
Requests per second:    5.64 [#/sec] (mean)
Requests per second:    6.21 [#/sec] (mean)

変わりませんね。誤差です。
クロック制限については、ある程度負荷をかけないとVM上で認識されている、
仮想CPUの性能速度で値が返ってきてしまうので、ここまでは想定内です。
なので、そんなに負荷がない環境でMemoryもそんなに使わない。というのであれば、
light.S1とlight.S2は変わりません。

次に100アクセス/100クライアントでチェック。
#ab -n 100 -c 100 http://localhost/wordpress/

Requests per second:    1.83 [#/sec] (mean)
Requests per second:    1.86 [#/sec] (mean)
Requests per second:    1.89 [#/sec] (mean)

Requests per second:    4.33 [#/sec] (mean)
Requests per second:    3.74 [#/sec] (mean)
Requests per second:    4.41 [#/sec] (mean)

見事に性能がアップしています。
旧の方はクロック制限に見事に引っかかって伸び悩んでいるのに対して、
制限が倍になった分が新しい方は伸びています。

価格が変わった分、変更しないと損なのは間違いないですが、
性能面からみても、変更する価値は十分にあることが解りました。
ハードウェアの認識も変わらず、あくまでクロックアップしただけのようなので、
何か紐づいたアプリケーションを使っていても、そこまで気を遣う必要はなさそうです。

ちなみに月の途中で性能変更する際には、変更後は新たに課金が始まるので、
上限(月額)まで達している場合は、新たに月が変わってからの方が良いかもしれません。

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

2015年12月25日金曜日

MeetUpでIDCFクラウドを楽しむ

#この投稿はIDCF Cloud Advent Calendar 2015に寄稿しています。

IDCFクラウドについて取り上げることが多いこのブログですが、
もっとIDCFクラウドを楽しんだり、知るためにMeetUpをご紹介します。

皆さん、IDCFクラウドMeetUpってご存知でしょうか。
https://idcfcloudug.doorkeeper.jp/
twitterハッシュタグ: #idcfug
私も実行委員として関わらせてもらっているので、ちょっとご紹介を。

約2か月に1回くらいの割合でユーザーが集まるMeetUpを実施してます。
ユーザー主体で行っているので、ゆるふわな感じで登壇者を募って、
その時に発表された新機能や実際に使用した事例などの情報を共有しています。

IDCFクラウドMeetUpは以下の概要で開催しています。

  • ユーザー主体のユーザーの為のコミュニティ
  • 新規ユーザーを増やして裾野を広げる
  • 既存ユーザの知識をシェアして習熟度を上げる
  • IDCFへフィードバックを行いサービスに反映してもらう
  • 気の合う仲間たちと出会う
  • 先進技術を楽しむ
  • ネガティブフィードバックも行える自由発言
  • 他クラウドとの連携などなど

IDCFクラウドMeetUpの目的は

「業務でIDCFクラウドを使っている方や、これから業務で使いたいと考えている方が、ノウハウを共有する場所。」
「課題意識が共有できる方たちと共通の話題でカジュアルに楽しく会話する場所。」
「最新の技術に対してのノウハウや解決手法をシェアする場所。 IDCFクラウドの使い方が解らない・・・という方の不安を取り除く場所」

という感じで、IDCFクラウドの情報を共有したり最新の技術をシェアしたり。
気軽に集まれる環境をとっています。
そのため、ユーザー企業に会議室をおかりして無料で集まれる勉強会スタイルをとっています。



初回は2015年8月に六本木のジープラ株式会社にて会議室をおかりして開催しました。

充実のノベルティ!w
初めての開催でしたが、増員対応という事で注目の高さを再認識しました。
ASCII.jpさんで紹介して頂きました
ちなみに懇親会はジープラさんの系列店「九州鳥酒 とりぞの」さんで開催。
20名近くの方が参加してお酒を片手に技術の話や最近のトレンドなどの話に花を咲かせました。

とりぞのさんありがとうございました!


第二回は2015年11月に渋谷のA8.netでおなじみの株式会社ファンコミュニケーションズにて開催!

勉強会っぽい!
この回から他社クラウドとの連携というテーマも加わり、初回はBluemixとの連携をご紹介。
人数も初回から更に増加し、懇親会の参加者も増えて飛び込みLTもありました。
普通のユーザー会ではそのクラウドだけのテーマが多かったりするんですが、
IDCFクラウドMeetUpでは、よりIDCFクラウドを効果的に使う為にと委員会が考えて、
他クラウドとの連携も良いんじゃないかという発想の元、シリーズ化した次第であります。
なかなかの自由度です。

そして第三回は2016年1月28日に新宿のNHNテコラス株式会社にて開催が決定しました。

スクエニさんと同じビルの13F!
第三回では・・・是非、足をお運び頂ければ!
以下コミュニティに登録して是非開催のお知らせをゲットしてください。

そして、IDCFクラウドMeetUpでは実行委員も募集しております!
基本的にはMeetUpの開催内容を企画したり、飲んだり、場所を決めたり、飲んだり。
そして忘年会を企画していろんな人に声をかけて集まってもらったり、飲んだり。
というわけで、企画大好きな楽しい運営チームです!
やってみたいな~。という方は遠慮せずにdoorkeeperの問合せからご連絡ください!
MeetUpの時に実行委員に声をかけて頂いても結構です!ご参加をお待ちしております!
東京以外でも開催したい!という声があれば是非ご連絡ください!
(大阪では既に動きが!?)

さらにさらに、IDCFクラウドMeetUpでは会議室を貸していただける企業さんも募集中です!
よろしくお願いします!

なんか宣伝が長々となりましたが、php7やansibleの話が聞けたり、
次回もslackの話が出る予定だったりと、IDCFクラウドを知らなくても楽しめる構成になっていますので、
クラウドに興味がある方は、ぜひぜひお誘いあわせの上、参加してみてください!


2015年12月21日月曜日

IDCFクラウドの料金シミュレーターで500円クーポンの限界を探ってみる

#この投稿はIDCF Cloud Advent Calendar 2015に寄稿しています。

IDCFクラウドには「1か月試せる500円クーポン」がついてきます。
これはlight.s1を1台1か月稼働させても無料で使えるという意味なんですが、
時間単位での課金の為、別にlight.s1を1台1か月稼働させなくても、
めちゃくちゃ大きいサーバを複数台たてて1時間500円分稼働させる。
ということもできます。

IDCFクラウドには料金シミュレーターがあります。
https://www.idcf.jp/cloud/simulation.php?cl=cl_price
クラウドには大体ついている料金シミュレーターと同様、
IDCFクラウドの料金シミュレーターも直感的に操作して料金を調べる事が出来ます。



とりあえずHighIOタイプのHighIO-5XL128を選んでみます。
CPU 40
Mem 128GB
従量 370円/h
上限 179,000円
とりあえず、1時間370円らしいです。
HighIOタイプは900GBがルートディスク+データディスクとして無料でついてきます。
なので、ストレージは別に取られないので1時間370円です。
OSは無償のCentOSを選択します。

これで半分以上使ってるんですが、次にHighMemoryタイプのHighMEM-XL64を選んでみます。
CPU 8
Mem 64GB
従量 124円/h
上限 60,000円
これでルートディスクは0.04円課金されるので、15GB分だと0.6円。



合計金額は494円となり、この構成で1時間試せる!という事が解りました。


さて、次にどれだけ並べられるの?という事を試してみたいと思います。
上限緩和の申請をしなければ仮想マシンのリソースリミットは20台です。
なので、20台並べられる構成を考えてみます。

HighCPU-L8を10台
CPU 4
Mem 8GB
従量 38円/h
上限 18,300円

Standard-S4を10台
CPU 1
Mem 4GB
従量 11円/h
上限 5,300円

で、計20台を500円で1時間分起動させることができます。




もちろん、Light.s1を複数台数時間立ててみるということもできますし、
500円というクーポンを色々と試行錯誤して使ってみると、
意外に500円でも色々出来るなーと再認識できるかと思います。
是非お試しください。

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

2015年12月14日月曜日

IDCFクラウドで東日本リージョンのWordPress環境を西日本リージョンに移して性能アップしてみる

#この投稿はIDCF Cloud Advent Calendar 2015に寄稿しています。

本ブログではIDCFクラウドの西日本リージョンを2回にわたってフォーカスしてみました。
東京からIDCFクラウド西日本リージョンを触ってみた
IDCFクラウド西日本リージョンがオールフラッシュだと言うので検証してみたら神速だった

今回は3回目という事で西日本リージョンに移して性能アップするんかい!?
というのを実際に検証プロセスを共有しながらやってみたいと思います。

東日本リージョン上にWordpressを構築します。
Light.S1でCentOS6.6を使用してインスタンスを立ち上げます。
Wordpressは最近のだと負荷あんまりないので、ver3.0をインストールしてみます。
ちなみにWordpressは全部デフォルトでやると2分で終わります。こんな感じ。

[root@wordpress ~]# yum -y install httpd mysql-server php php-mysql
[root@wordpress ~]# wget http://ja.wordpress.org/wordpress-3.0-ja.tar.gz
[root@wordpress ~]# tar xzvf wordpress-3.0-ja.tar.gz
[root@wordpress ~]# mv wordpress/wp-config-sample.php wordpress/wp-config.php
[root@wordpress ~]# mv wordpress /var/www/html/
[root@wordpress ~]# service mysqld start
[root@wordpress ~]# mysql -uroot -hlocalhost -e "create database database_name_here"
[root@wordpress ~]# mysql -uroot -hlocalhost -e "grant all privileges on *.* to username_here@localhost identified by 'password_here'"
[root@wordpress ~]# service httpd start

以上!

この状態でIPアドレスでWebアクセスすれば見れるんですが、
リージョン間で移動した時にリンクの解決やらで色々と面倒な事になるので、
面倒ですけどDNSを設定してドメインでアクセスする事をお勧めします。。

http://[ドメイン名]/wordpress/

って感じでアクセスしてサイトの初期設定をします。
初期設定したら再度上記のアドレスでWordpressコンテンツが見れる事を確認。
これで一旦計測してみます。
今回はteslaにサーバを立てました。そして同じteslaに居るマシンから計測するという、
東日本リージョンに超絶ハンデを与えて確認してみます。

確認のコマンドは以下。
ab -n 10 -c 10 http://[ドメイン名]/wordpress/

結果はこんな感じでした。
-----
Concurrency Level:      10
Time taken for tests:   1.441 seconds
Complete requests:      10
Failed requests:        0
Write errors:           0
Total transferred:      71330 bytes
HTML transferred:       68760 bytes
Requests per second:    6.94 [#/sec] (mean)
Time per request:       1440.580 [ms] (mean)
Time per request:       144.058 [ms] (mean, across all concurrent requests)
Transfer rate:          48.35 [Kbytes/sec] received
-----

何回か実施しましたが、Requests per secondは6~7という感じでした。

さて、この子をそのまま西日本リージョンに持っていこうと思います。
先ずはnetworkの固有設定を削除してテンプレート化します。

[root@wordpress ~]# rm -f /etc/udev/rules.d/70-persistent-net.rules

「おまえ、syncしたのか?」と言われ続けた世代なので、一応儀式。

[root@wordpress ~]# sync

で、スナップショットとってテンプレートを作ってやります。ここが一番時間かかるかなー。3分くらい。
(安心してください。無停止ですよ。)
初めてやる人はこの辺は、詳しくドキュメントがあるのでこちらが参考になるかと。
http://www.idcf.jp/cloud/pdf/manual_005.pdf
ちなみにCentOS6.6がOSタイプに無いですけど6.4で大丈夫です。

作ったテンプレートを選択してエクスポートからURLを発行します。
発行したURLは後で使うのでメモ帳とかにコピーしておきます。

ここで西日本リージョンにコンパネを切り替えて作業に入ります。
さっき作ったテンプレートを移設するのでコンピューティングからテンプレートを選択します。
テンプレート作成でテンプレートを作っていくんですが、
URLのところにさっきエクスポートから発行したURLをhttpにして入れます。
発行した時はhttpsで発行されますが、ここでインポートするときはhttpに書き換えます。
OSタイプも似てるの選んだり、あとは適当でOKです。
これで西日本リージョンへテンプレートのコピーが始まります。楽勝。
ステータスがDownload Completeになれば完了。およそ2分程度。

で、そのテンプレートを使って仮想マシンを作成すればokです。
西日本リージョンが初の方はsshで入る鍵を作る必要があるのでご注意を。
作ったサーバにログインすればさきほど東日本で作成した見慣れた環境があるはず。
あれ?デジャヴ?と思ったらapacheとmysqlを起動してあげてください。

DNSを西日本リージョンのサーバに向けて浸透を待ちます。
(紛らわしいので東日本リージョンのサーバは落としておくと吉)
これで準備完了。
いよいよ西日本リージョンのサーバを計測します。
超絶ハンデで東日本リージョンのさっきのサーバから計測します。

ab -n 10 -c 10 http://[ドメイン名]/wordpress/

結果はこれ。
----
Concurrency Level:      10
Time taken for tests:   1.386 seconds
Complete requests:      10
Failed requests:        0
Write errors:           0
Total transferred:      71330 bytes
HTML transferred:       68760 bytes
Requests per second:    7.21 [#/sec] (mean)
Time per request:       1386.119 [ms] (mean)
Time per request:       138.612 [ms] (mean, across all concurrent requests)
Transfer rate:          50.25 [Kbytes/sec] received
----

複数回実施しても平均的に6.5~7.5のスコアをマーク。
超絶ハンデを与えたのにすげーぜ!西日本リージョン!

とまぁ、ここまで書いてワクワクしている人には申し訳ないのですが、
恐らくはリリースしたてという事もあるのかなぁと。
この後、東日本リージョンと同じ負荷状況になった時にどうなるかは不明。
なので、ご利用は計画的に。

ただ、現時点では単純に性能アップが見込めるのは間違いなさそうです。
レイテンシの問題を気にされる方が結構居ますが、
日本内ですし、この程度であれば、大体のWebサイトは気にならない程度で済みます。
まぁ、GCP使ってる人であればレイテンシは気にしないでしょうし、
サーバ2~3台で運営しているのであれば、東日本から西日本に置き換えて性能見るのも、
まぁ、1つの手ではないかなーと個人的には思います。
画像が多いサイトは東日本のオブジェクトストレージに入れておけば、
ユーザ側からはそんなにストレス無いんじゃないすかね。

今回プロセスを共有してやってみましたが、DNSの浸透を抜かせば、
全工程は大体10分程度で完結しますので、小腹が空いたら是非お試しください。

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

2015年11月12日木曜日

IDCFクラウド西日本リージョンがオールフラッシュだと言うので検証してみたら神速だった

IDCFクラウド西日本リージョンがリリースされました。
このブログでも既にレイテンシについて取り上げました。
http://cloudyarouze.blogspot.jp/2015/11/idcf.html

今回はオールフラッシュというDisk性能について迫ってみました。
結論から言うと、速すぎ。爆速とか言っててごめんなさい。神速でした。
これを500円で提供してしまうのは本当にクラウド業界にとって良い事なのだろうか?
と余計な心配をユーザにさせてしまうくらい速いです。
これが出来るし、やってしまうのがIDCFクラウドなんですよね。
ほんと他のクラウドと違っていて尖ってて面白いです。

今回はread性能をhdparmで確認する簡易的な性能測定しかしていないです。
なのでこの記事を鵜呑みにせず、是非ご自身で反証をして頂きたい。
クーポンもついてきて無料で試せますし、触った事無い方は是非触って確認してほしいです。
また、writeも確認出来るような形で是非性能測定をしてみてほしいです。(丸投げ)

各クラウドでインスタンスはミニマムなものを選択しています。
比較はhdparm -tを5回で行いました。(間にioctlしてません)
その結果、read速度は以下のようになりました。

GCP(標準) 12.8MB/sec
GCP(SSD) 233.39MB/sec
GMO ALTUS 67.428MB/sec
AWS(汎用SSD) 81.17MB/sec
IDCFクラウド東日本リージョン 209.786MB/sec
IDCFクラウド西日本リージョン 609.334MB/sec

元々東日本リージョンでもGCPのSSDと同じくらいの性能は出てたんですが、
西日本リージョンでは影すら踏めない値が出てしまいました。
何度も時間を変えて繰り返しやりましたが、ばらつきがあるものの、
IDCFクラウドの西日本リージョンは最低でも300MB/secは出てました。
なので、本当にこれだけの速度差があるのだと思います。
GCPの標準Diskは冗長してるので速さ比較して判断するものではないですが
しかし、想像以上に遅いですね。みんなLocalSSDを使いたがる理由がわかります。

この部分だけで単純比較してもクラウドの優位性は影響しないと思っています。
例えばAWSで言えば暖機させる事でさらに性能が出ますし、GCPはcpuがボトルネックでDisk性能が上がりきってないと思います。
bufferだけでなく実際に-Tオプションを使用してcache補正する事でも変わる事もあるかと思います。
そのクラウドにとって最適な状態で行わず、あくまでインスタンス立ち上げ直後のデフォルトの状態を使っています。
また負荷のピークタイムもクラウドによって違うので一概に言えません。
なので、是非ご自身のやり方で、そしてご自身の目でもご確認頂くのが良いと思います。
新規アカウント登録すれば500円のクーポンがついてきますので、是非試してみてください。
http://www.idcf.jp/cloud/

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

2015年11月10日火曜日

東京からIDCFクラウド西日本リージョンを触ってみた

久々のエントリーです。
IDCFクラウドに待望の西日本リージョンが誕生しました!

先週から触れていた(ステルステスト?)んですが、本日公式発表がありました。
これでやっとIDCFクラウド内でディザスタリカバリ環境を構築したり、
ロケーションを分けて対応をするといった事ができるようになりました。

注目なのは西日本リージョンはDiskが爆速でオールフラッシュ仕様との事。
これは結果によっては東で作るより西で作った方が速くなる可能性がありそうです。
というわけで、やはり気になるのは東京からのレイテンシ。
簡易的ですが早速測ってみました。

AWSの東京リージョンから64byteのpingを100回打って応答速度をみてみました。
東日本リージョン 平均 5.67msec
西日本リージョン 平均15.247msec
東日本→西日本 平均 22.969msec
ちなみに千葉のローカル環境からpingを打った応答速度も殆ど変わりませんでした。
なので、東京からだと約10ミリ秒程度差があるようです。

ちなみに、AWSの東京リージョンから他のロケーションだと、
GCP アジアパシフィック 平均35.315msec
GMO ALTUS東京リージョン 平均2.899msec
という感じですので、さすがに東京と比べると地理的にレイテンシが高くなりますが、
それでも10ミリ秒程度。逆にGCPで気にならない方は全く気にならないと思います。

AWSのシンガポールリージョンからだと東日本の方が早い結果になりました。
地理的に近いから~的な話よりも経路の問題が大きいようですね。
東日本リージョン→シンガポール 平均71.217msec
西日本リージョン→シンガポール 平均80.635msec

ちなみに他のロケーションからですと、
GCP アジアパシフィック→シンガポール 平均217.345msec
GMO ALTUS東京リージョン→シンガポール 平均78.094msec
という感じで、シンガポールに対しては東日本リージョンが1番早い結果になりました。

10ミリ秒程度の差であれば、Diskの速度を考えると
西日本で作った方が早くなりそうですね。
今は未だオープンしたてで人が増えたらどうなるかわかりませんが、
この感じだとかなり期待出来るんじゃないでしょうか。
あ、ちなみに起動はIDCFクラウドですので勿論20秒仕様で爆速でした。

現在、DRに必要な機能がIDCF内では殆ど完結しないので、
DR設計にはRoute53等、別の何かを考える必要がありそうです。
早くDNSにFailover機能や重みづけでのバランシング機能が付くと良いですね。
あと、オブジェクトストレージのエンドポイントが西日本には無いようです。
S3との互換性は高いので当分はS3が良い感じでしょうか。
もしくは無料枠もありますし、東日本リージョンで我慢ですね。

次は西日本リージョン噂の爆速ディスクに迫る検証をしてみたいと思います。

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

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が出来ました。 

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

2015年3月12日木曜日

VPSからIDCFクラウドにrsyncだけで移設した話

先日、VPSからIDCFに個人的に借りていたサーバを移設しました。
今回はその時に移設した方法をご紹介します。

尚、今回は試しにいつもと違うエディタ使ったら見にくくなりました。ご了承下さいorz

今まで自分のメールやWebサイト的なものはVPS(KVM)で稼動していました。
超絶安定稼動していたので移設等は考えていなかったのですが、
オペミスやら何やらがあったらしく、極めつけはブロードキャストストーム。。
これは早めに解約しなければデータもなくなるんじゃないか?という危機感を抱き、
どこかに移設しようと思い立った訳であります。
ただわざわざミドルウェアを構築しなおしてやる程の話でもないので、
2時間停止のメンテ前提で一気にrsyncで移設しました。

使用用途:Web/Mailサーバ
apache + MySQLでCMSはConcrete5、Wordpressの2つをインストールしてありました。
Mailはpostfix + Dovecot を Webメーラーとpostfixadminで操作する感じでした。
それぞれ複数特に特殊な事もしてません。


VPSのスペック
価格 1000円弱
Mem 2GB (使用としてはほぼCacheでbufferも162MB程度)
Disk 50G (常時使用領域は9GB程度)
CPU 2core(共有)


移設候補としてはAWSのt2.microや新しいGMOクラウド等を視野に入れてましたが、
最終的にコストパフォーマンスが最も優れたIDCFクラウドのlight.S1に移設する事にしました。

light.S1のスペック(標準)
価格 500円
CPU 1core
MEM 1GB
Disk 15GB
トラフィック 3TBまで無料
オブジェクトストレージ 50GBまで無料
監視ツール Mackerel ホスト数無制限 無料


全部で500円(税込)です。

元々1000円弱使っていたので、その予算であれば2台冗長も可能です。
スナップショットも1GB30円程度なので、どちらの運用でも1000円以内で収まります。
今回はオブジェクトストレージを使ってバックアップをする形で、
500円以内に収めてしまおうとおもいます。

今回は検証や自分のドメインのWebサイトなので2時間程度停止して行う事にしました。
(メールについてはセカンダリのサーバが無い場合建てた方が良いです。)
今回の作業の順番としては以下のとおり。
  1. 移行先サーバの準備
  2. コンテンツの移設
  3. DNSの変更
ミドルウェア等を構築しなおすと色々と面倒臭いのでrsyncで丸ごと移設させます。
今回はVPS側はCentOS6.2だったのですが、IDCFクラウドにはCentOS6.5からしか
テンプレートがないので、強引に実行する事にしました。
(本来、バージョンを合わせないと後々面倒になります。)

先ずは移行先サーバの準備をします。
詳しいことはめちゃ楽ガイドに書いてありますので省きます。
http://www.idcf.jp/cloud/pdf/IDCFCloud_installation_guide.pdf
サーバを作ってネットワークの設定をしてsshで接続出来れば完了。

あとはコンテンツの移設です。ミドルウェアを停止していきます。
うちの場合は、以下を停止しました。

# /etc/init.d/httpd stop
# /etc/init.d/postfix stop
# /etc/init.d/dovecot stop
# /etc/init.d/mysqld stop

停止したら一気にrsyncでもってきます。
/etc領域にクラウド毎に必要なファイルが結構あったりするので、deleteオプションを入れてません。
その移設先のクラウド特有の変更してはいけないファイルが解っていれば、
事前にrsyncのexcludeに追加しておきましょう。

コンソール操作が出来るクラウドであれば何とかなりますが(まさに今回救済されましたw)、
出来ない場合は致命的になり再起動後に上がってこなくなります。
以下は移設先から実行する例です。

rsync \
# システムディレクトリ
  --exclude=/proc \
  --exclude=/sys \
# デバイスファイル
  --exclude=/dev\
# lost+found (破損しているファイル置き場。無ければ不要。)
  --exclude=/boot/lost+found \
  --exclude=/lost+found \
# リムーバブルメディア
  --exclude=/media \
  --exclude=/mnt \
# ネットワーク設定
  --exclude=/etc/sysconfig/network \
  --exclude=/etc/sysconfig/network-scripts \
# カーネル関連
  --exclude=/boot \
  --exclude=/etc/sysconfig/modprobe.conf \
  --exclude=/lib/modules \
# テンポラリディレクトリ
  --exclude=/tmp \
  --exclude=/var/tmp \
# ファイルシステムの自動マウント設定
  --exclude=/etc/fstab \
# DNSのresolv設定(自動で生成される場合が多い為)
  --exclude=/etc/resolv.conf \
# ログファイル(上書きをしてはいけない場合のみ)
  --exclude=/var/log \
  -alze ssh [移行元]:/  /

これで実行して後は待つだけです。簡単ですね。
容量的には8GB程度くらいでしたが、Global越しに30分くらいで終わりました。
移設先でミドルウェアを起動して確認を行います。

# /etc/init.d/httpd start
# /etc/init.d/postfix start
# /etc/init.d/dovecot start
# /etc/init.d/mysqld start

ここで起動しなかったり、Webが見えなかったり、メールが飛ばなかったりした場合は、
別の問題が発生している可能性が高いので切り戻しを考えて、作戦を練り直しましょう。

起動したらvirtualhostもしっかりクライアント側のhostsに書いて確認します。
問題なければ移設先のOSを再起動しますが、
問題がある場合は、大体、ここで死にます(微笑)
要するに上がってこないパターンですね。

上がってこないケースはカーネルパニックやネットワークトラブルです。
カーネルパニックの場合はgrubやfstab周りを確認してみましょう。
最近のクラウドはコンソールがついているのでコンソールから復帰させることが出来ます。
IDCFクラウドもコンソールを触れるので、何かあっても問題は確認可能です。

今回は再起動をしたところ、network疎通が出来なくなりました。
コンソールで確認したところ、eth0を認識しなくなり、dhcpが動作しなかった模様です。
今回はudevも持ってきてしまったのでそこが影響しました。
/etc/udev/rules.d/70-persistent-net.rules
上記から重複エントリーになってる部分を削除して、本来のデバイス(今回追加されているデバイス)をeth1からeth0へ元に戻します。

詳細は以下URLを参考にすると解り易いと思います。

http://qiita.com/tsumekoara/items/964182390a08b678d576
[VirtualBox 4.3] 複製したゲストOS (CentOS) がネットワークに繋がらない: Device eth0 does not seem to be present, delaying initialization が表示された際の対応(tsumekoara)

上記を変更してリブートをしたら正常に上がってきてくれました。
再度、問題ないかアクセスやサービスのチェックを行います。
問題がなければDNSを切り替えて終了になります。

全ての作業をあわせて約1時間程度でした。
全てのサービス停止が必要になりますが、1時間程度で移設出来れば十分ですね。

コンテンツが多い場合でも先にコンテンツを移行させて、
rsyncで同期を常にとっておいて、移設のタイミングの時の負荷を減らすことも可能です。
容量に合わせてプランニングすると良いと思います。

ちなみに今回のrsync移設ですが、稼働中のサーバをAWSに移設したい!
なんて時にloopbackにrsyncでコピーしてAMI化するなんて事もしてました。

中にはCDをマウントして事前に作った環境をrsyncで同様にコピーしておいて、
それをネット環境に繋げないデータセンターに持ち込んで展開する。
なんて方もいたので、色々汎用性があると思います。
移設のハードルを下げてくれると思いますので、ぜひ試してみて下さい。

取り急ぎ移設しましたがバックアップ等の設定は未だしていません。
そのうち色々と必要になると思うのでこのサーバの運用設定等について、
今後は書いていきたいと思います。

今回は自分のVPSからの移設ついでに簡単にサーバ移設する方法をご紹介しました。

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

2015年1月23日金曜日

Yahoo!ビッグデータインサイトとTableauOnlineを連携させる

先日、IDCフロンティアさんのハンズオンセミナーに行ったのですが、
TableauのMyPageをアクティベーションの問題(凄い時間かかる)から作る事が出来ず、
失意のままセミナーが終わってしまったので、復習がてら資料読みながらやってみます。

ハンズオンセミナーは定期的にやるという話ですので、
是非、以下URLをウォッチして確認してみてください。
http://idcf.doorkeeper.jp/

今回のゴールは、
YBIとTableauOnlineを連携させて、TableauOnline上でグラフ化してみる。
ところまでやりたいと思います!
※Tableauのグラフ生成操作や詳しく解析手法を説明するという事は、
 今回の記事ではしませんのでご注意下さい!

今回用意する環境

IDCFクラウド
  light.S1
  Ubuntu Server 14.04 LTS 64-bit
Yahoo!ビッグデータインサイト(以降YBI)のアカウント
TableauOnlineのアカウント
です。
YBIもTableauもクレジットカードは今回不要です。
YBIは無料コースがありますし、Tableauは試用期間があります。
気楽に進めて下さい。

IDCFの初期構築はめちゃ楽ガイドをご参照ください。
http://www.idcf.jp/pdf/cloud/IDCFCloud_installation_guide.pdf

ちなみに2015/01/22時点で、新規ユーザは3000円分のクーポンついてます。
(3000円はlight.S1を半年上げっ放しでもOKな金額なので安心して検証出来ます!)
お友達紹介キャンペーンも併用すると最大6000円分のクーポンがついてきますので、
是非ご活用ください!(ご紹介は taka3110_pcc でお願いします!w)


その他のサイトのアカウント類は先に作っておきましょう。
(特にTableauはアクティベーションに1時間くらい掛かります。)

Yahoo!ビッグデータインサイトのアカウント作成

以下URLにアクセス
https://console-ybi.idcfcloud.com/users/sign_up


・・・簡単ですね。
SignUpをするとMyPageに飛んでデモが始まるので適当に流してください。
最初からいくつかサンプルデータが入ってますので、HiveやPrestoを使う事が出来ます。
HiveやPrestoを使う環境をSignUpのたった5項目書くだけで揃っちゃう。
ちょっと使ってみたいなーっていうときは便利ですね。

MyPageの右上、自分の名前が書いてあるメニューをクリックすると、
My Profile画面に移動できます。こちらでAPIKeyを取得します。

APIKeyを取得する為にパスワードを入力します。


APIKeyが表示されるので、今回はWrite-Only API Keysを使用します。
こちらをコピーしてメモ帳等にでも保存しておいてください。
(あとでtd-agentのコンフィグに記載する必要がある為)



TableauOnlineのアカウント作成

以下、URLにアクセス
https://www.tableau.com/ja-jp/products/online
無料で試すボタンを押すと以下のように入力画面が出てきます。
項目を埋めて下さい。

リクエスト送信後、1時間くらいでMyPage作成についてのリンクが記載されたメールが来ます。
かなり時間がありますので先にサーバを作ってしまいましょう。


サーバ構築


さて、それでは中身を構築しましょう。
ハンズオンセミナーに忠実に作ります。
今後、本サーバを使用した記事を書く予定ですが、今回の記事では実は使いません。
従って、YBIとTableauの連携だけ確認する方は飛ばしていただいて結構です。
ただAPIのサーバ指定を変更すればトレジャーデータでも使用できますので、
一般的にtd-agentとnginxの連携方法の練習と捉えていただければ。

連携についてはハンズオンセミナーの方で聞いて頂ければと思います。


apt-get install nginx
curl -L http://toolbelt.treasuredata.com/sh/install-ubuntu-precise.sh | sh
mkdir -p /usr/local/ybi/data
cd /usr/local/ybi/data
echo "export TD_API_SERVER=https://ybi.jp-east.idcfcloud.com" > ~/.bash_profile
source ~/.bash_profile
td account -f
#-----------------------------------------------
#以下対話式になるので記入(#は不要)
Enter your Treasure Data credentials.
Email: #YBIに登録したメールアドレス#
Password (typing will be hidden): #YBIに登録したメールアドレス#
Authenticated successfully. #←成功するとこのメッセージになります。
Use 'td db:create <db_name>' to create a database.
#-----------------------------------------------

td db:create handson
td table:create handson
apt-get install openjdk-7-jre
cp -p /etc/td-agent/td-agent.conf /etc/td-agent/td-agent.conf.org
vi /etc/td-agent/td-agent.conf
#-----------------------------------------------
#以下内容を記入。#APIキーを記入#の部分をYBIのAPIキーになおす。(#は不要)

# Tailing the Nginx Log
<source>
  type tail
  path /var/log/nginx/access.log
  pos_file /var/log/td-agent/nginx-access.pos
  tag td.handson.streaming
  format nginx
</source>
# Treasure Data Input and Output
<match td.*.*>
  type tdlog
  apikey #APIキーを記入#
  auto_create_table
  buffer_type file
  buffer_path /var/log/td-agent/buffer/td
  endpoint https://ybi.jp-east.idcfcloud.com
  flush_interval 10s
  use_ssl true
</match>
#-----------------------------------------------
chmod +x /var/log/nginx/
/etc/init.d/td-agent restart
/etc/init.d/nginx restart

これでnginxのログをtd-agentを経由してYBIへ自動的に送る設定が完了しました。

念の為テストしてみましょう。
curl http://localhost/
curl http://localhost/
curl http://localhost/
curl http://localhost/
curl http://localhost/
sleep 10
td query -w -t presto -d handson "SELECT * FROM streaming"

上記を実行すると5行(5 rows in set)のアクセスデータがテーブル型で表示されると思います。
表示されない場合はggrksで。

TableauOnlineを使う


Tableauはタブローと読みます。タブローソフトウェアという会社のBIツールです。
YBIにしろ中身であるtreasuredataにしろ、分析、結果の出力までは行います。
それを見やすいようにビジュアライズしたりするのが、
今回Tableauに代表されるBI(Business Intelligence)ツールが必要になります。

百聞は一見に如かず。早速やってみてみましょう。

アクティベートが完了していればメールが来ていると思います。
文中のCreate Your SiteのリンクをクリックしてMyPageを作成しましょう。
ログインをすると完成したMyPageのワークブックが表示されている状態となります。

管理者ボタンをクリックしてプロジェクトを追加していきましょう。


プロジェクトをクリックして追加のリンクをクリックします。




名前と説明を適当にいれて追加ボタンをクリックします。


追加したプロジェクトがプロジェクトの一覧に表示されていると思います。



YBIとTableauの連携


さて、次はYBIの方を触ります。
今回はYBI --> Tableauへクエリ結果を出力させるやり方を取ります。

それではYBIにクエリを用意しましょう。
New Queryをクリックし、Databaseドロップダウンメニューからsample_datasetsを選択します。
クエリを記入(下記コピペ)して、下図青枠のResult Exportのaddボタンをクリックします。


クエリはこちら
------------------------------------------------------------------------------
SELECT
  CAST(TD_TIME_FORMAT(time, 'YYYY-MM-dd', 'JST') AS TIMESTAMP) AS Datetime,
  method AS Method,
  COUNT(1) AS Count
FROM
  www_access
GROUP BY
  TD_TIME_FORMAT(time, 'YYYY-MM-dd', 'JST'),
  method
------------------------------------------------------------------------------

Result Exportの画面でExport toにTableau Server を選択。
HostにはTableauOnlineのドメインを記入します。
Username/PasswordはTableauOnlineにログインした際に使用したものを記入します。
Datasourceは適当に入力をして、画面をスクロールします。
最後にProjectに先ほど作成したProjectの名前を記入してUseをクリックします。


UseをクリックするとNew Queryの画面に戻るのでRunをクリックして、
Queryを走らせると自動的にJobの画面に遷移します。

Jobが完了すると下図のようにJOB番号の横がrunningからsuccessになります。
今回のQueryだと平均で30秒程度で終わると思います。

successになったらTableauの方で確認してみましょう。
先ほど追加したプロジェクトにデータソースが追加されていると思います。



BIツールでのビジュアル化


最後にグラフを作成してビジュアル化します。

データソース名の横にあるチェックボックスにチェックを入れて、
新しいワークブックのリンクをクリックするとグラフ作成画面に遷移します。

グラフ作成画面では左にあるディメンションやメジャーを列/行へドラッグ&ドロップする事で、
グラフを簡単に作成する事ができます。
Datetimeは+を押すことでより期間をスコープして確認する事ができます。
習うより慣れろですので、先ずは下図のような図を作ってみて色々と変更してみて下さい。




今回はYBIとTableauの連携でした。
上記内容は定期的にハンズオントレーニングをやっています。
詳細はIDCFのイベントページをご確認下さい!
http://idcf.doorkeeper.jp/

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

2015年1月14日水曜日

クラウド比較に使うWRSとは

WRSとは、WordpressResponseSpeedの略です。
知ってる人が居たら結構怖いです。
なぜなら私が勝手に考えたベンチマーク単位だからです(微笑)
簡単に言うと、「完全初期状態のwordpressの読みだし性能」です。

当サイトではWRSを使用して比較をしていきます。
WRSとは、apache / mysql / wordpress3.0 を全てデフォルトの状態でインストールし、
そのトップページにabで取得した1秒間のレスポンス回数です。
wordpressを3.0にしているのは、最適化されておらず、ほどよい負荷が掛かる為です。
回数ならTimeじゃないか。という突っ込みもあるかもしれませんが、
WRTだとDD-WRTと被ってしまい、DD-WRTを検索したい人に恨まれるので、
WRTではなく、WRSとしました。ちなみにWRSで検索してもIT系は殆どヒットしませんでした。

デフォルトのwordpress構成なので、phpがボトルネックになります。
CPUを上手く使えないので、CPUに負荷が掛かる形になり、
CPUの性能によって大きく結果が変わります。
従って、CPUの性能が顕著に出る比較となり、また完全デフォルト状態での実施の為、
Diskの性能も少し加味される形になります。
出してみて比較すると意外に良い感じな指標になるため、この方式を採用しました。

現在は以下構成で比較をおこなっています。

#OS:Ubuntu 12.04.1 LTS(64bit)
#apache 2.2.22
#MySQL 5.5
#PHP 5.3

Ubuntu 12.0.4 LTS(64bit)のapt-getでインストールされる最新のミドルウェアが
上記となっており、それを使用しています。
以下、環境構築方法と計測ルールになります。

環境構築


・以下、Ubuntu上で実施
apt-get update
apt-get install apache2 mysql-server php5 php5-mysql
wget http://ja.wordpress.org/wordpress-3.0-ja.tar.gz
tar xzvf wordpress-3.0-ja.tar.gz
mv wordpress/wp-config-sample.php wordpress/wp-config.php
mv wordpress /var/www/
/etc/init.d/apache2 restart
mysql -uroot -hlocalhost -e "create database database_name_here"
mysql -uroot -hlocalhost -e "grant all privileges on *.* to username_here@localhost identified by 'password_here'"

・以下、WebUI(http://[GlobalIP]/wordpress/)にアクセスして設定
サイトのタイトル:pc-concierge.net
ユーザ名:admin
パスワード:adminadmin
メールアドレス:abc@abc.abc
チェックボックス:外す
(このサイトが Google や Technorati などの検索エンジンに表示されるのを許可する。)
上記でインストール実施


計測ルール


localhostから計測
以下アドレスで試験
http://localhost/wordpress/
apache、mysqlはオプション変更毎にリスタートして計測
ab -n 1 -c 1 http://localhost/wordpress/
ab -n 10 -c 10 http://localhost/wordpress/
ab -n 100 -c 10 http://localhost/wordpress/
ab -n 100 -c 100 http://localhost/wordpress/
ab -n 1000 -c 100 http://localhost/wordpress/
上記コマンド毎の3回の最速値を取得
計測取得値
Requests per second
計測手法に変更があれば更新していきます。
そのうち自動構築系の配布も考えますが、今はコピペでやってます。

皆さんも是非WRSを使って比較してみてください。


それでは良いクラウド構築を!

2015年1月12日月曜日

【クラウド体験記】新旧IDCFクラウドの性能を比較してみる

去年、IDCFクラウドが新しくなりました。
それ以来、結構な頻度で触っているのですが、細かく数値化してみていなかったので、
ちょっと今回は具体的に数字にして比較して、どの様な設計が合うかをみたいと思います。

やり方は、
 Wordpressをインストールして、レスポンス性能を確認する
というやり方です。

IDCFの導入方法やインスタンスの作成は「めちゃ楽ガイド」という冊子があり、
そこに書いてあるのが1番詳しいのでリンクを貼っておきます。
http://www.idcf.jp/pdf/cloud/IDCFCloud_installation_guide.pdf

この記事では細かいミドルウェアの構築方法は記載せず、
比較手法と比較結果を書いて考察したいと思います。

環境は以下。
 Ubuntu 12.04.1 LTS(64bit)
  apache2 2.2.22
  mysql-server 5.5
  php5 5.3.10
  wordpress3.0
上記環境をapt-getでインストールした"デフォルトの状態"でabを掛けて比較します。



新旧の違いを考える

 CPUクロックがパワーアップ。起動スピードはクラウド随一に


新旧で目に見える違いはCPUのクロック。
以前は1.6GHzでしたが、2015年1月現在ではXeon E5-2680で2.8GHzのようです。
視覚の部分で大きく変わったのがインターフェース。
オリジナリティのあるコンパネになりました。
体感の部分が一番大きく変わっており、起動スピードはクラウド随一となっています。
インスタンス作成のジョブを流してから起動するまでに20秒程度しか掛かりません。
私がIDCFクラウドを注目している理由は2つあり、1つはこの起動スピード。
これはとても大きい変更で、これだけでも使う価値が出てくると考えています。
もう1つはYahoo!Japanのインフラにリーチしていることが大きいと考えています。
最近ではYahoo!ビッグデータインサイトや、コンテンツキャッシュサービスなどがあげられます。
運用面では未だ苦労することが多く、例えばスナップショットに時間が掛かる等、
課題も多い為、運用設計に注視をしておく必要があります。
価格についてもエントリーのインスタンスが劇的に安いのですが、それ以外は若干割高です。
こちらも設計がとても重要になります。
エンジニアのかゆいところを残しておいてくれるのはAWSやオラクル等と同じなのですが、
少し残されすぎかなぁという印象です。ちょっとかゆすぎ。
ただ、前記している起動スピードはクラウドで最も重宝される部分ですし、
現状、ユーザは暖機以外に選択がないので、設計次第ではかなり柔軟な構成が可能です。



新旧を比較してみる

 クロックアップの分だけ応答性能はアップ


話がそれました。
IDCFクラウドでの設計はまたの機会として、新旧比較に一旦戻しましょう。

abのオプションとして
1. -n 1 -c 1
2. -n 10 -c 10
3. -n 100 -c 10
4. -n 100 -c 100
5. -n 1000 -c 100
で比較をしているのですが、4~5についてはメモリの問題で出来ない事もあり、
低価格インスタンスでは1~3で比較されています。


上記図の単位はリクエスト/秒です。
CPU性能が上がっている分、性能としては全体的に上がっている事が解ります。
light系0.8GHzの場合、ある一定の段階でガクンと性能が落ちます。
上記図の場合、n10c10の負荷では1cpuと変わらない速度で応答しますが、
n100c10になった途端に制限がかかっていることがわかります。
継続負荷には弱いですが、断続的な応答であれば1コア使っているような感覚でしょうか。
この辺はAWSのmicro等と考え方は一緒で問題ないかと思います。
低価格インスタンスの応答性能が高いため、メモリをそこまで使用しないサイトであれば、
light.s1インスタンスを並べて処理をする等で、耐障害性も高めながら今よりも安く設計する事が可能だと思います。

上記から個人サイトのようなものや、そこまでアクセスが多くないEC/Webサイトでは、
メモリさえ間に合ってしまえばlight.s1インスタンスでも十分に処理が出来るかと思います。



その他クラウドとはどう違うか


その他クラウドとは運用コストが変わったりするため、単純比較は難しいのですが、
ハイCPUインスタンスでもこの高い性能は変わりません。
例えば、8コアCPUのインスタンスを他社と単純に応答速度だけで比較してみると
意外にもIDCFに良い結果が出て驚きました。(失礼。。)


価格で軸を置いて比較をするか、応答速度で比較をするか、等々
なにを軸にして比較するかによってこのような比較は意味の無いものになります。
今回は単純にWordpress初期構築時の応答速度を他社と比較してみましたが、
価格帯がバラバラなものの、結果としては悪くない値になっています。
※この記事はIDCFについて記載しているため、他社名は記載していませんが、
  当ブログではパブリックな比較をする際には正式名称記載で比較を行っています。



新しいIDCFクラウドのバリューとは


light系の0.8GHz制限があるインスタンスについては他社クラウドと同じ制限イメージがある為、
とりあえずlightで複数台構成を行い、イベントや流入見込みの際にインスタンスをstandard以上に
変更するというような、いわゆるクラウド的な使用方法が見えてきます。
ただ、このあたりの閾値を決める設計はかなり難儀なため、standard以上を使う形になってしまいそうです。

新旧と比べてみましたが、性能や使い勝手の面で格段にアップしていると思います。
新IDCFクラウドでは価格が安いlight.s1を攻略する事で、予算内での設計幅がかなり広がります。
スナップショット等、運用機能が貧弱な為、バックアップ等の運用設計は、
導入時にしっかりしておく事が必要になります。

また3Tまではトラフィック無料ですが、課金自体はアカウント単位で課金が行われるので、
トラフィック量が多い場合は複数アカウントを用意し、DNSラウンドロビンを使用して
対処する事でシステム的なコストダウンは出来ると思います。
この辺の設計やテクニックについても今後ブログでご紹介していきます。

国内クラウドの注目株IDCFクラウドの新旧比較でした。




それでは、良いクラウド構築を!

2015年1月7日水曜日

はじめにおよみください

このブログではいろんなクラウドを使ってみてレビューしたり、
色んな連携方法、設計方法を提案していきます。
基本的には参考にならない情報が満載になると思います。

このブログの基本方針

1.比較の場合は数字で根拠

何かを比較する場合は数字を根拠にして比較するように心がけます。

2.放言主義

率直な意見を書いていくので、ネガティブな意見を書いた投稿も散見すると思います。


基本方針が増えていったら上記に追加していきます。