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分程度で完結しますので、小腹が空いたら是非お試しください。

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