2018年6月27日水曜日

IT放浪記~奄美大島編~

今回は技術の話は一切なく日記です。

本当は書こうか迷ったのですが、
ただITインフラを触る人や事業者には、割と興味を持って欲しいなと。
そうするには私が見てきた現状を発信する事が一番と思い書くことにしました。

そもそもが私の個人的な事業目的で奄美大島に訪れた為、
各アポ先にはもちろんblog掲載の許可を頂いていません。
なので出どころや詳しい話、人間関係や思惑等は記載しません。
ただ、聞いて回った話と私が感じた事を書こうと思います。

前置きはこの辺にしまして。

奄美大島に行ってきました。
奄美大島のイメージって皆さんどんな感じでしょうか。

私は調べるまでは沖縄の近くの島。というイメージしか持ってませんでした。
ただ調べてみるとフリーランスや情報通信産業に市が力を入れている事がわかりました。
行政がフリーランスや情報通信産業に力を入れる島というのも面白いなと。
いてもたっても居られなくなり、実際に状況を確認しに行ったというのが今回の放浪記です。

奄美大島のフリーランス施策や情報通信産業に関する施策ですが、

フリーランスが最も働きやすい島化計画

ここに解りやすく載っています。

面白そうという事と、丁度自分の事業計画にもマッチングしそうだった為、
直ぐに飛行機を予約して、アポ取りをはじめました。
で、実際に市役所にもアポを取って話を伺い、さらにICT施設も見学してきました。
また、ITエンジニアの教育現場も拝見し、お話を伺いました。
そしてさらに紹介を受けて地元の情報通信業の会社様にもお話を伺いました。

順を追って書いていきたいと思います。

まず市が行っているフリーランス施策ですが、厳密に言うとエンジニアは含まれていません。
この施策の大元となるのは島の活性化であり、島の人たちがITを使って発信する事を目的としているそうです。
例えば島の魅力等を伝えるライティング事業であったり、ハンドメイドをインターネットを使って売ってみたり、
そういうフリーランスの方々となります。
この施策はランサーズやGMOペパボ等の企業とタッグになって進めているそうです。
バリバリのITエンジニアの方々も勿論OKですけども、市がやってるフリーランス施策とは一線を画するという事を、
頭に入れておいて計画を練るのが良いと思います。
私の計画とは残念ながらマッチングしませんでした。2020年以降の次のステップで考えてるそうです。
フリーランス支援窓口があり、そこに相談をすると色々と相談に乗ってもらえます。
ここでは移住に関する相談も乗ってもらえるので、ITエンジニアの方も勿論相談に乗ってもらえます。

ICT施設も見学しました。ICT施設は空港に近いところにあります。
カードキーによる入室管理と防犯ビデオも完備されており、管理人が常駐してます。
入口、さらに各部屋にカードキーが設置されています。
更にサーバールームもあります。ここは空調でコントロールされていました。
ただ、ドアの結露がとても気になりました。
素で置いておくよりかはよっぽど良いと思いますが、高価な機器はおけなさそうです。
入居する為には奄美に移住する必要があります。
空港から近い為、1か月に1度訪れる程度で借りようと考える人が結構居るそうですが、
入居条件としては3/4以上は常駐する必要があるそうです。
ただ、ここが難しいところなのですが、ICT施設があるのは笠利という地区です。
奄美市の中心地は名瀬というところです。名瀬から笠利は車で40分くらいかかります。
はっきり言って移住して通うには通い辛いです。何故あそこに作ってしまったんだろう。
そう思わざるを得ない場所にあります。
空港から近いというのは1つの利点なのですが。ただ入居のハードルが少し高いです。
個人事業主でも借りれるそうなので、奄美に移住を考えているエンジニアは良いかもしれません。
ハブは山に入ったり藪や農道を通らなければ見かける事も困難なレベルなのでご安心を。

で、実際に移住を考えた場合なのですが、
正直、話を聞いた中での主観になりますが、地元にはエンジニアとしての仕事が殆ど無いと思います。
地元の企業も多くは東京から仕事を持ってきています。そして協力しながら仕事をこなしています。
外から仕事を持ってこれる人でないと厳しいです。

通信環境は整っていますし、携帯の電波もDocomoならほぼ入ります。
物価は平均して特に安くないです。家賃も名瀬なら鹿児島の中心地と変わらないです。
空き家は結構あるそうですが、大家さんとの交渉もあり、あまり出回っていません。
名瀬なら土着の不動産屋さんや市役所に相談して探した方が良いと思います。
実際に見つけた空き家の近所の人に大家さんを聞いて直接交渉する位の気持ちが丁度良さそうです。

さて、今回の旅で一番重要視していたのがITインフラへの知見だったのですが、
そもそもエンジニアもプログラマーが主体なので、
前述のICT施設のサーバールーム扱いからみてわかる通り、
サーバーに関してはまだまだ知識が不足しています。
更に離島あるあるといえばあるあるなのですが、まだまだ物理への信頼感があり、
クラウドに関して疑問を持ってる方が多いです。
なのでレンタルサーバーは普及していますが、クラウドは全く普及してません。
クラウドインフラの普及は急務な気がします。これこそ施策にして欲しいくらいに。
クラウドインフラを広めるようなイベントが開けたらと思いますが・・・
手をあげてくれる事業者が居ると嬉しいです。

今回、観光という観光は殆ど出来なかったのですが、
普段観光する人達が訪れないような場所に沢山立ち寄らせてもらえました。
専門学校や開発センターなど、いろいろと伺わせてもらいました。
島の人達はとても良い人ばかりで、そして皆さんとても自然を大事にしています。
私は奄美大島がとても好きになりました。

もちろん夜は飲み明かしました。
地元の方々にいろいろとお店を紹介してもらいながらハシゴ。
とても楽しい夜でした。
特にお世話になった屋仁川の心機一転の皆さん、Bar柊のマスターには感謝です。
奄美大島に訪れた際には絶対にまた立ち寄ります。
皆さんもとても楽しい素敵な旅になると思いますのでお勧めです。

一応、海の写真置いておきます。こんな素敵な海が直ぐ近くにあります。



奄美大島で東京に負けないような技術力を持ったインフラエンジニア集団が出来ればいいな。
もしクラウド事業者が本気を出せば、近い将来、それは訪れるかもしれませんね。

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

2018年5月26日土曜日

CentOS5でphpのcurlからTLS1.2対応をさせる話

PCIDSSの対応で各決済会社のTLS1.2縛りが始まりました。

乗り遅れてしまった!! やばい!間もなくじゃない?
的な話もチラホラ聞きます。

phpで作られているシステムであれば、curl等を用いて決済情報に確認を
しにいったりリクエストを投げたりしているところが多いのではないでしょうか。

CentOS6以降であれば普通にyumで対応出来ちゃうのですが、
CentOS5系ですとyumでは無理。
proxyで逃げるという策もあるのですが、サーバーも立てられない環境だと、
なかなか安易に逃げれない。
という訳で、今回はphp-curlを更新して対応させちゃう話です。

/usr/localにはソースインストールしているような形跡が無い前提で、
php-5.3.19の環境を元に書いていますので、
その辺は自身の環境と読み変えて下さい。


全て最新を入れたいところなのですが、
全て最新だとなかなかいろいろと問題が出るので、
TLS1.2に対応出来ているという形で収めます。

opensslをダウンロードします。

wget --no-check-certificate https://www.openssl.org/source/old/1.0.1/openssl-1.0.1u.tar.gz
tar xzvf openssl-1.0.1u.tar.gz
cd openssl-1.0.1u

既存環境を汚したくないのでprefixを指定してconfigureします。

./config --prefix=/usr/local/openssl shared
make
make install

完了です。

次にcurlをインストールするのですが、opensslのlibを読み込めるように、
ldconfigでpathを読めるように以下を追記しておきます。
vi /etc/ld.so.conf
---------
/usr/local/openssl/lib
---------
ldconfig

curlですがs3等で画像の存在確認をして表示をさせるようなシステムだと、
最新のcurlでは--outputオプションをつけないとbinaryは表示出来ない為、
エラーになるケースが見受けられました。

以下は新しいcurlで実施していますが、エラーが出るようでしたら
curlを7.19くらいに落とすと上手くいきます。
ただ7.19をダウンロードするにも公式からTLSではじかれるので、
7.58.0をインストールしてから
curl -k curlのURL -o ファイル名
でもいいと思います。
ca情報が古い場合はpemファイルを上記と同じようにcurl -k でゲットして配置しなおします。
詳しくはこちら。
うまい棒ブログ(id:hogemさん)
サーバのSSL CA(認証局)証明書が古くてcurl がエラーになる件
http://hogem.hatenablog.com/entry/20120705/1340284071


さて、続きやります。今回は7.58.0をゲットして入れます。
今回も環境汚染しないようにcurlをprefix指定して別にインストールします。
新しいsslを読み込んで作りたいので新しくインストールしたopensslディレクトリを指定します。

wget --no-check-certificate https://execve.net/mirror/curl/curl-7.58.0.tar.gz
tar xzvf curl-7.58.0.tar.gz
cd curl-7.58.0
./configure --prefix=/usr/local/curl --with-ssl=/usr/local/openssl
make
make install

以下でバージョン確認するとopenssl-1.0.1uを参照しているのがわかると思います。
/usr/local/curl/bin/curl --version

新しくインストールしたcurlを元にphp-curlを作り直します。
今回の環境はphp-5.3.19がyumでインストールしてあったので、同じバージョンをダウンロードします。
切り戻せるように元からあるモジュールはバックアップしておきましょう。

mv /usr/lib64/php/modules/curl.so /usr/lib64/php/modules/curl.so.old
※32bit環境であればlib64をlibにして下さい。


wget http://museum.php.net/php5/php-5.3.19.tar.gz
tar xzf php-5.3.19.tar.gz
cd php-5.3.19/ext/curl/
phpize

新しくインストールしたcurlをディレクトリとして指定します。
./configure --with-curl=/usr/local/curl
make
make install

これで完了です。
php -i で確認するとcurlの参照opensslが1.0.1の新しいものに
なっていると思います。

以下のようなテストスクリプトでphpの実行ファイルを作成し、
実行した際にページの情報が表示されればokです。

-----------------------------------
<?php
$url = "対象サイトのURL";
$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$html = curl_exec($ch);
var_dump($html);
curl_close($ch);
-----------------------------------

意図しない表示崩れ等を起こすと困るので、
apacheを再起動(gracefulやreloadでもok)して表示を確認しましょう。

今回はcurlでしたが他のphpモジュールで対応したい場合でも、
そのモジュールが参照するパッケージを新しくソースインストールして、
新しい方を参照する形で作り直せば通ると思います。

同じようにCentOS5のgitのsshやcurlでハマッてる人をよく見かけますが、
上記と同じようにopensslを元にsshやcurlを作れば大丈夫です。

ここまで書いといてあれですけど、
既に陳腐化しているシステムを無理くりやっているだけなので、
本来であればCentOS7に移行するのが筋です。

あくまでワークアラウンドでお考え下さい。

※ここに書いてある内容は一般的な対応方法では無いので
 くれぐれも実施後は確認を怠らず注意の上、自己責任でお願いします。


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

2017年12月23日土曜日

IDCFクラウドで追加ネットワークに仮想マシン作成時からIPを指定する

※IDCF Cloud Advent Calendar 2017 に参加してます。

気付いたら1年ぶりの投稿でした。
ブログって意識してないとホント書きませんね。
という訳で、アドベントカレンダーがあったので書くきっかけにしてみました。

IDCFクラウドで追加ネットワークって仮想マシン作成時に、
コントロールパネルからIP指定して起動出来ないんですよね。
・追加ネットワークだけ使いたい(裏側のDBとか)
・プライベートネットワークと接続している
・別途マネージドFW/LBを契約している
とかとか。そんな時に超不便。
なのでcloudstack-apiを使用してさくっとIP指定して作ってしまいます。

cloudstack-apiのインストール方法は下記。
http://docs.idcf.jp/cloud/introduction/#install
ちなみに、上記のマニュアルは一部古くて、curlは以下が正解です。
curl -kL https://bootstrap.pypa.io/get-pip.py | python

2018年2月には現在ベータ版のidcfcloud-apiの仮想マシン機能がリリース予定らしいので、
その時はidcfcloud-apiに書き換えちゃいましょうね。
それまでの間って短いなーって感じですが、短い間でも楽しなきゃ損なので。

基本形はこれ。
/usr/bin/cloudstack-api deployVirtualMachine \
--serviceofferingid $SERVICEOFFERINGID \
--templateid $TEMPLATEID \
--zoneid $ZONEID \
--group $GROUP \
--keypair $KEYPAIR \
--name $NAME \
--networkids $NETWORKIDS \
--ipaddress $IPADDR

順を追って確認しましょう。
先ずは serviceofferingidですが、仮想マシンのタイプです。
以下コマンドで起動したい仮想マシンのタイプのidをメモ。
cloudstack-api listServiceOfferings -t name,id

templateidも同じように以下コマンドで起動したいテンプレートのidをメモ。
※セルフテンプレートの場合は以下。公式のを使う人は templatefilterをselfからfeaturedに変更
cloudstack-api listTemplates --templatefilter self -t displaytext,id,name,ostypename,status,zonename

次はzoneidを確認。
cloudstack-api listZones -t name,id


groupを確認。
※新しく指定する場合は必要なし。
cloudstack-api listInstanceGroups -t name


keypairを確認。
※指定するときは名前。finger printは確認の意味で。
cloudstack-api listSSHKeyPairs -t name,fingerprint


networkidを確認。
cloudstack-api listNetworks -t name,id,cidr

上記コマンドで確認した内容を前述の以下コマンドで流せば作成できます。
$NAMEの部分は作成したい仮想マシンの名前。
$IPADDRの部分は指定したいIPアドレスを代入してください。
/usr/bin/cloudstack-api deployVirtualMachine \
--serviceofferingid $SERVICEOFFERINGID \
--templateid $TEMPLATEID \
--zoneid $ZONEID \
--group $GROUP \
--keypair $KEYPAIR \
--name $NAME \
--networkids $NETWORKIDS \
--ipaddress $IPADDR

ちなみにnetworkidsは複数指定可能なので、仮想ルーターのデフォルトNWと追加NWを両方出来ます。

これをshellとかにして引数にIPアドレスと名前を指定出来るようにしておけば、
オートスケールに使ったり出来るし、結構万能に使えます。

「なんで追加ネットワークのIP指定出来ないんだよ!」
って発狂気味の皆さんはぜひお試しください。

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

2016年12月19日月曜日

IDCFクラウドでゾーンを移設するメリットと方法

※本記事はIDCF Cloud Advent Calendar 2016に寄稿しています。

どうも。どんことtaka3110です。
前回はゾーン別のスペックについて書いてみました。
今回はゾーン移設を実際にやってみます。
手順を書いた長い記事ですので、面白いことは書いてません。あしからず。。

メリットについては前回のブログで書いた通り、
スペックが違う為、初期のゾーンから移設するという選択だけで、
性能アップが見込めます。

今回、wordpressとメール的な環境を想定してみました。
移設元は「メールサーバー + Webサーバー」(Web+DB)という内容です。

前提としては、
----
移設元環境
・IDCF提供のテンプレートを使用して構築されている
・仮想ルーターIPを使用している
・Webサーバーとメールサーバーに使用している
----
としています。

やり方はいくつかあります。
このブログでも紹介しましたが、rsyncでOSより上をまるっと移設する方法や、
1から構築してデータのみを移設する方法もあります。

今回はテンプレートファイルを作成し、それをリージョン移設して構築したいと思います。
今回はteslaから東日本2のluxに移設します。

極力ダウンタイムを減らしたいので、
Webについてはsorryサーバーを表示させ、メールはセカンダリを指定してみます。
今回の記事でもsorryサーバーとセカンダリメールサーバーの構築をしたいと思います。
移設前にはスムーズに作業、確認を行うためにDNSのTTLを下げておきましょう。
最低でも600以下にしておく事をお勧めします。

セカンダリメールサーバーを作成してそちらに向けるメリットとしては、
こちら側の意図でメールの再配信が出来るところにあります。
メールサーバーへの疎通ができない場合、送信元がリトライを行います。
リトライの回数、秒数については送信元によって違います。
セカンダリメールサーバーを用意しておくと、送信元はメール送信を完了し、
セカンダリメールサーバーで再送処理をする形になります。
作業完了後にセカンダリメールサーバーで再送処理をする事で、
移設後直ぐにメールサーバーを落としていた間のメールが届く形になります。
常時運用ではなく、今回はスポット的に使用しますが、とても簡単に構築出来ます。
なお、サービスを停止してからテンプレートを取得する手順を踏む為、
送信だけ行っている環境であればセカンダリメールサーバーの構築は今回必要ありません。

セカンダリメールサーバの構築時にluxのIPを使用するので、
移設元がIPを取得しているならば、先にIPの取得をしておきましょう。
(この記事では仮想ルーターのIPを使用します。)
また、ポートフォワードの設定も移設しておきましょう。

今回の流れ
0.移設先のIP取得とポートフォワードの設定
1.sorryサーバーとセカンダリメールサーバーの構築
2.DNSの登録とポートフォワードの設定変更
3.スナップショット、テンプレートの作成
4.テンプレートの移設
5.テンプレートから構築
6.移設後の確認
7.DNSの変更
8.セカンダリメールサーバーの再配送
9.後片付け
大体、15GBであれば1時間程度で完了する作業です。

先ずはsorryサーバー+セカンダリメールサーバーを作ります。
移設元の同じゾーンに仮想マシンを立ち上げます。
今回はCentOS6.8を選択して構築したいと思います。

仮想マシンが立ち上がったらIPアドレスを取得します。
IPアドレスを取得したら今回立ち上げた仮想マシンにNATの紐づけをします。
NATの紐づけはNATボタンから対象サーバーを選択して有効化するだけです。
この対応で全てのポートがNAT設定した対象サーバーに向けられます。
(もちろんポートフォワードでも構いません)

FWにはsorryサーバーとセカンダリメールサーバー用の許可設定を追加します。
先ずはsshのport22をMyIP等、作業環境から許可し、
httpのport80、smtpのport25をAny(0.0.0.0/0)で許可します。
(httpsのアクセスが必要な場合は443も許可しましょう)

上記まで完了したらsshでサーバーにログインしましょう。

Webサーバーを構築します。
# yum -y install httpd
# /etc/init.d/httpd start

下記にsorryページを配置しましょう。
/var/www/html/index.html

この状態で"http://取得したIPアドレス/"にアクセスして、
sorryページが表示されればOKです。

次にセカンダリメールサーバーを作成します。
既にpostfixはインストール済みになっているので、設定変更のみ行います。
# vi /etc/postfix/main.cf
----

以下をlocalhostからallへ変更
----
inet_interfaces = all
----

最終行に以下を追記
----
transport_maps = hash:/etc/postfix/transport
relay_domains = ドメイン名
----

# vi /etc/postfix/transport
以下を追記
----
ドメイン名 smtp:移設先サーバーのIP
----
例)ドメイン名がtest.orgで移設先サーバーが210.140.171.1だった場合
test.org smtp:210.140.171.1

設定を反映します。
# postmap /etc/postfix/transport
# /etc/init.d/postfix restart

以上でsorryサーバーとセカンダリメールサーバの構築は完了です。

次にセカンダリメールサーバー用にDNSを設定しましょう。
今回取得したsorryサーバー用のIPアドレスをAレコードで指定します。
mail2等、解りやすい名前で構いません。
次にMXレコードを今のものよりも大きい優先度で設定します。
例)今が10であればセカンダリは20

これでDNSが浸透すればセカンダリメールサーバの設定は完了です。


ここからは移設の作業になります。
ダウンタイムにある程度の許容があれば、データの不整合等もなくなるので、
この時点でsorryサーバーに切り替えてしまいましょう。
ダウンタイムに許容が無い場合は、sorryサーバーへの切り替えは最後に行い、
DNSの浸透を待って新しいサーバーへ同期を行いましょう。

今回はこの時点でsorryサーバーに切り替えを行う手順を取ります。
この記事ではhttp、httpsをsorryサーバーに切り替えます。
既存のサーバーのポートフォワードを一旦削除し、sorryサーバーへ向けます。
※既存のサーバーがNATでしたら別のIPを取得し、ポートフォワードで設定をし、
 そちらにDNSを向けて対応しましょう。

移設元サーバーにログインします。
既にサービスはsorryサーバーの方を向いている事を確認し、
各サービスを止めます。
# /etc/init.d/httpd stop
# /etc/init.d/mysqld stop
# /etc/init.d/postfix stop

ここからサーバーをコピーする作業を行います。
テンプレートを作成する前にnetwork deviceの情報を削除します。
# rm -f /etc/udev/rules.d/70-persistent-net.rules
また、Disk追加をしている場合は、fstabで追加Diskの行をコメントアウトしておきます。

上記が完了したらスナップショットを取得します。
スナップショットは
仮想マシン⇒(対象の仮想マシン名)⇒ボリューム⇒右下のボリューム操作へをクリック
表示されるボリューム名をクリックし、スナップショット⇒スナップショット作成で取得できます。

スナップショットが取得出来たら、スナップショットを確認します。
ステータスがBackedUpになっていればスナップショットの取得完了です。
スナップショットからテンプレート作成をクリックします。
テンプレート名やOSタイプを選択し、作成するをクリックします。

作成できたテンプレートをエクスポートします。
テンプレートから作成したテンプレートをクリックし、エクスポートをクリックします。
URLを発行するボタンが表示されるのでクリックします。
※生成中の間は他のページ等に遷移しないように注意してください。

テンプレートのURLが表示されるのでテキスト等にコピーをしておきます。

ここまで出来たら移設先の東日本2にページを切り替えます。

コンピューティングのテンプレートからテンプレート作成ボタンをクリックします。
テンプレート名~OSタイプまでを入力します。フォーマット以下は特に変更は不要です。
URLは先ほどコピーしたURLのhttpsの部分をhttpにして貼り付けます。
全て入力したらテンプレートを作成するボタンでテンプレートを作成します。

上記テンプレートを使用して仮想マシンを作成します。
今回の記事ではセカンダリメールで転送先指定をしているluxを指定しているので、
ゾーンはluxを使用します。
また、SSH keyは元のサーバーと同じものを使用します。
アップロードをクリックし、移設元サーバーで以下で表示される内容をコピーしましょう。
# cat /root/.ssh/authorized_keys

上記入力が完了したら仮想マシンを作成します。

仮想マシンにログイン出来る事を確認したら、
立ち上がっていないサービスが無いか確認しましょう。

※ログイン出来ないという時は、udevのルールが残っている可能性があります。
 コンソールからログインして削除をしてrebootしましょう。

これでサーバー側は完了です。

最後にDNSを新しいサーバーへ向けなおします。

DNSが浸透をした事を確認したら、sorryサーバーにログインし、
postfixの溜まったデータを再配送します。

# postfix flush

以下コマンドでqueueが空になっている事を確認しましょう。
# postqueue -p
Mail queue is empty

上記が完了したら、sorryサーバーは削除してしまいましょう。
旧サーバーも停止してしまいましょう。
データについては何かあった際に使う可能性がありますので、
念のため2~3日についてはサーバーはそのまま残しておく事をお勧めします。

以上で移設完了です。お疲れ様でした。

さて、画像等を使わないで文字だけでつらつらと書いてしまい、
解りづらい部分もあったかと思います。
こんなところにハマった。とか、こういうのはどうやってやるの?
質問等があればご連絡ください。
また、ユーザー会もありますので、ぜひ参加して聞いてみて下さい。

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

2016年12月4日日曜日

IDCFクラウドのゾーンから見る性能強化と進化

※本記事はIDCF Cloud Advent Calendar 2016 Advent Calendar 2016に寄稿しています。

どうも。どんことtaka3110です。

今回は久しぶりにIDCFクラウドについてです。
東日本に新しいリージョンがリリースされました。
これでリージョンは3個、ゾーンは10個となった訳ですが、
どれを使っても同じという訳ではありません。
という訳で、今回はゾーンについて振り返りながら性能を考えてみたいと思います。

まずはどんなゾーンがあるのか。

  ゾーン リージョン リリース
1 tesla※ 東日本 2014/10
2 pascal 東日本 2015/4
3 henry 東日本 2015/6
4 joule 東日本 2015/10
5 augusta 西日本 2015/11
6 radian※ 東日本 2016/3
7 newton 東日本 2016/7
8 monstera 西日本 2016/8
9 weber 東日本2 2016/11
10 lux 東日本2 2016/11

※は現在新規アカウントでは追加不可能のようです。

約2年で10なので、2.4か月に1ゾーンという形で増えています。
割と良いスピードで増えていますね。

2015年11月のaugusta以降は全てオールフラッシュディスクでの提供となっています。
(西日本、東日本2はオールフラッシュリージョン)
したがって、Disk性能がaugustaから飛躍的に上がっています。

性能だけが違うのかというと使えるサービスにも違いがあります。
例えばGPUインスタンスを立ち上げるには現在は東日本2になります。

ゾーン別の対応インスタンス

  ゾーン HighIO GPU
1 tesla※ highio.5XL128のみ 非対応
2 pascal 全て可 非対応
3 henry highio.5XL128のみ 非対応
4 joule 全て可 非対応
5 augusta 全て可 非対応
6 radian※ 全て可 非対応
7 newton 全て可 非対応
8 monstera 全て可 非対応
9 weber highio.3XL128のみ 対応
10 lux highio.3XL128のみ 対応


HighIOインスタンスに一部違いがあります。
また、GPUインスタンスは現在(2016/12/03現在)は東日本2リージョンのみの対応です。

ゾーンで違うのはこれだけではありません。
CPUの型も違います。newton以降から新しいCPUを搭載したマシンになっています。
light.S1は以下のようになっています。(タイプによってCPUが変わる場合があります。)

  ゾーン CPU
1 tesla※ Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
2 pascal Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
3 henry Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
4 joule Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
5 augusta Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
6 radian※ Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
7 newton Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
8 monstera Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
9 weber Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz
10 lux Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz

ここまで見てお分かり頂いたかと思いますが、
augusta以降からフラッシュディスクになり、newton以降からCPUが新しい型になっている為、
初期のゾーンと一番新しいゾーンでは、かなりの性能差が出ます。
勿論、値段が変わらないので新しいzoneを使った方が断然コストパフォーマンスが高くなります。


言葉よりも数値で見た方が解りやすいと思います。
light.S1で全ゾーンをhdparmで比較するとこうなります。

  ゾーン cached reads buffered disk reads
1 tesla※ 8706.18 MB/sec 275.83 MB/sec
2 pascal 8336.05 MB/sec 264.62 MB/sec
3 henry 8823.00 MB/sec 204.79 MB/sec
4 joule 8419.01 MB/sec 290.63 MB/sec
5 augusta 8823.96 MB/sec 314.37 MB/sec
6 radian※ 8593.79 MB/sec 249.83 MB/sec
7 newton 10150.15 MB/sec 316.51 MB/sec
8 monstera 9981.35 MB/sec 389.55 MB/sec
9 weber 10436.24 MB/sec 403.65 MB/sec
10 lux 10395.61 MB/sec 411.82 MB/sec

augusta以降はフラッシュディスクになっている為、buffered disk readsが性能強化されており、
newton以降はcpuが強化されているのでcached readsが増えています。
しかしながらradianがスペックの割に性能が出ていません。
勝手な想像ですが、恐らくは東日本で初めてフラッシュディスクになったゾーンですので、
仮想マシン数が多いのではないでしょうか。そういった理由も新規で選択出来なくなっている理由でしょう。
新しくIDCFクラウドを契約する方は特に気にする理由は無さそうです。
古くから使用しているユーザはサポート等に現状厳しいゾーンを聞けば答えてくれると思います。きっと。ええきっと。


さて、より分かりやすく性能を見るためにWEB2層のアプリケーションで確認してみます。
実際にlight.S1へコンテンツを載せてWRSで比較してみると以下のようになります。
※WRSとはデフォルトの状態でwordpressにabをかけて比較したものです。

  ゾーン ab -n 1 -c 1 ab -n 10 -c 10 ab -n 100 -c 10
1 tesla※ 6.30 [#/sec] 6.44[#/sec] 2.11[#/sec]
2 pascal 6.71 [#/sec] 6.3[#/sec] 2.07[#/sec]
3 henry 6.38 [#/sec] 7.12[#/sec] 2.13[#/sec]
4 joule 6.60 [#/sec] 6.56[#/sec] 2.1[#/sec]
5 augusta 7.47 [#/sec] 7.02[#/sec] 2.16[#/sec]
6 radian※ 6.63 [#/sec] 5.84[#/sec] 2.08[#/sec]
7 newton 8.54 [#/sec] 8.03[#/sec] 2.65[#/sec]
8 monstera 9.72 [#/sec] 9.38[#/sec] 2.79[#/sec]
9 weber 9.98 [#/sec] 9.54[#/sec] 2.99[#/sec]
10 lux 9.87 [#/sec] 9.56[#/sec] 2.82[#/sec]

何もしなくても、初期のteslaやpascalと比べて、
最新ゾーンのweber、luxは1.5倍程度の性能差が出ています。
勿論、まだリリース直後でユーザーが少ないというのも大きな要因ですが、
newtonで見てみても大分性能差が出ている事が解ります。

ちなみにab -n 100 -c 10だけ値が低いのは、
light.S1のCPUリミッター(0.8GHz)によるものです。
light.S1は0.8GHz相当という触書になっていますが、直ぐにCPUリミッターが掛かる訳ではありません。
上記表の通り、そこまでアクセス数が多くないサイト等であれば、2.4GHz相当で使用出来ます。

新しいゾーンが出ると性能が強化されて更に進化していくIDCFクラウド。
AWSではファミリーの世代という形で性能強化されていきますが、
IDCFクラウドでは現状、ゾーン毎に進化をしていきます。

上記のように性能が強化されるのでtesla等、旧ゾーンで性能が足りなくなってきたと感じたら、
ゾーン移設を検討するのも1つの手です。
複数台構成であれば、GSLB機能もあるのでサービス停止を回避しながらゾーン移設も可能です。

次回は旧ゾーンから新ゾーンに移設する方法をご紹介しようと思います。

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

2016年11月22日火曜日

CentOS5のyumな環境でATS対応させた話

どうもtaka3110ことどんです。

今回は待った無しになっているATS対応の話です。
そもそもATS対応って何じゃい?という方は、こちらをご参照下さい。

簡単に言うと、AppleさんとこのIOSアプリからAppleさんが言うセキュリティに
準拠していないサイトは片っ端から弾きまっせ。覚悟しとき。
という宣告です。

ATSに対応する為には
-------------------
・ TLS ver 1.2以上であること
・ 以下のcipherに対応している事
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
・サーバ証明書はsha256でキーは2048bit長以上にする事
-------------------
というルールがあるらしい。

何が困ったってCentOS5系を運用しているサイトやゲームですね。
特に側ネイティブでやっているアプリなんて季節的にもCentOS5があったりするのでは?

CentOS5でATS対応するには、
・opensslをsrcからコンパイル
・apacheの最新版をsrcからコンパイル
しなければ対応出来ません。
(対応出来たよ!という方は教えて下さい・・・)
ちなみにopensslをsrcコンパイルしてmod_ssl作ればええやん的な安易な発想でしたが、
SSLCompressionの設定、ECDHEに対応していない等の罠があり結論無理でした。

yumの環境だと相当難儀な作業になります。
モジュール類、特にphpもソースコンパイルして対応となると、
もうね、それだけで面倒な作業。

という訳で、出来る限りyumでインストールされている現況を崩す事なく、
何とかATS対応出来ないかという事でやってみました。

aprを変更せずに、prefix指定でソースコンパイルすれば、
そのままyumで入れた同じモジュールを使えるのではないか説が沸きあがり、
実際にやってみたら使えたのでご紹介します。
(実際にやっても自己責任でお願いしますね・・・)

1.作業ディレクトリ作成
解りやすく作業する為に作業ディレクトリを作ります。

mkdir /root/src
cd /root/src

2.ソースゲット
最新版のソースをゲットします。
元々2.2系だったので、2.2系の最新とopensslの1.0.1の最新を入れます。

wget http://ftp.jaist.ac.jp/pub/apache/httpd/httpd-2.2.31.tar.gz
wget https://www.openssl.org/source/openssl-1.0.1u.tar.gz

3.opensslのインストール
あくまでmod_sslを作るためだけのopensslにしたいので、
prefixを指定してインストールします。
#config時の"-fPIC"は入れても入れなくても大丈夫です。入れた場合、ソースの書き換えが一部必要になります。

tar xzvf openssl-1.0.1u.tar.gz
cd openssl-1.0.1u
./config --prefix=/usr/local/openssl1.0.1 shared
make
make install
cd ..

4.apache
apacheについても既存環境を汚さないようにprefixを指定してインストールします。
ちなみにenable類は無くても大丈夫だと思います。何か、念のためやりました。

tar xzvf httpd-2.2.31.tar.gz
cd httpd-2.2.31
./configure --prefix=/usr/local/httpd-2.2.31 \
--enable-dav=shared \
--enable-dav-fs=shared \
--enable-dav-lock=shared \
--enable-proxy=shared \
--enable-proxy-connect=shared \
--enable-proxy-ftp=shared \
--enable-proxy-http=shared \
--enable-proxy-balancer=shared \
--enable-proxy-ajp=shared \
--enable-rewrite=shared \
--enable-ssl=shared \
--enable-mem-cache=shared \
--enable-so \
--enable-modules=all \
--enable-mods-shared=all \
--with-ssl=/usr/local/openssl1.0.1
make
make install
cd ..


ここまで出来れば後はapacheのmoduleと起動スクリプト類を入れ替えるだけです。
ちなみに同じようなCentOS5が他にもある場合、ここで作ったディレクトリを配布すれば、
いちからコンパイルする必要は無いです。
/usr/local配下にopenssl1.0.1とhttpd-2.2.31ディレクトリを置いてやればokです。


適用作業はこんな感じでやりました。

5.初期コンフィグのバックアップ
戻せるようにしておきましょう。

mv /usr/local/httpd-2.2.31/conf /usr/local/httpd-2.2.31/conf.org
mv /usr/local/httpd-2.2.31/modules /usr/local/httpd-2.2.31/modules.org

6.既存モジュールのcopy
yumで入れたモジュールをコピーします。
#パスは64bitの場合です。

cp -rp /usr/lib64/httpd/modules /usr/local/httpd-2.2.31/

7.既存コンフィグのコピー
既存のコンフィグを適用させましょう。

cp -rp /etc/httpd/conf /usr/local/httpd-2.2.31/
cp -rp /etc/httpd/conf.d /usr/local/httpd-2.2.31/
cp -rp /etc/httpd/common /usr/local/httpd-2.2.31/

8.設定ファイル類のディレクトリ構成設定
運用性を考えて同じディレクトリ構成にしておきましょう。

mv /etc/httpd /etc/httpd.org
ln -s /usr/local/httpd-2.2.31 /etc/httpd

9.起動ファイルの変更
戻せるようにしておくのと、tab効きするようにしておきましょう。

mv /etc/init.d/httpd /etc/init.d/httpd.org
chmod -x /etc/init.d/httpd.org
ln -s /usr/local/httpd-2.2.31/bin/apachectl /etc/init.d/httpd
mv /usr/sbin/httpd /usr/sbin/httpd.org
chmod -x /usr/sbin/httpd.org
ln -s /usr/local/httpd-2.2.31/bin/httpd /usr/sbin/httpd

10.mod_sslのモジュールのみコピー
mod_sslは今回コンパイルしたものを使います。

cp -pi /usr/local/httpd-2.2.31/modules.org/mod_ssl.so /usr/local/httpd-2.2.31/modules/

11.logやrunフォルダの設定
logフォルダは引き継ぐようにしておきます。

mkdir /etc/httpd/run
mv /etc/httpd/logs /etc/httpd/logs.org
ln -s /var/log/httpd /etc/httpd/logs

12.アップデートしたopensslをmod_sslが読みに行く為の設定
最後にmod_sslがprefixしたopensslを読みに行けるようにしておきます。

echo "/usr/local/openssl1.0.1/lib" >> /etc/ld.so.conf
ldconfig

以上で完了。
古いapacheが上がっていればpkill httpdで落としてやれば、
普通に新しいapacheを上げられる筈。

これで構築したサイトを以下で見てみるとATS対応している筈。
https://www.ssllabs.com/ssltest/


ここまででとりあえず一時しのぎ的にATS対応出来たとしましょう。
でもね、そもそも論としてCentOS5を使い続けるってどうなのよ?
という疑問を投げかけざるを得ない。

という訳で、取り急ぎ時間が出来たという事で、
しっかりと計画してリプレースしましょう。

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












一応、、、、もとにもどす手順も置いときます。

rm /etc/httpd
mv /etc/httpd.org /etc/httpd
rm /etc/init.d/httpd
mv /etc/init.d/httpd.org /etc/init.d/httpd
chmod +x /etc/init.d/httpd
rm /usr/sbin/httpd
mv /usr/sbin/httpd.org /usr/sbin/httpd
chmod +x /usr/sbin/httpd

2016年9月20日火曜日

YAMAHAのルーターで存在しないNWを使ってVPNする話

どうもtaka3110ことどんです。

最近、YAMAHAのルーターと戯れる事が多かったので、
少しメモ代わりに書いておきます。

題名だけ見ると大それたというか、謎めいた感じですが、
簡単に言えばNATです。はい。
ただ、双方向NAT(TwiceNAT)のドキュメントはありますが、
単方向NATでマスカレードしないのはあまりなく、でも結構使う機会がある。
というところでブログネタにした訳です。

最近ではフレッツVPNなどで店舗間でも割と簡単にフレッツ網を使ったVPNがはれます。
店舗間データのやり取りをセキュアに行いたい等、結構使う機会はあると思います。
例えば、本店と店舗のNWが全く同じ場合は、前記のTwiceNATを用いれば良いですが、
(TwiceNATの設定例:http://jp.yamaha.com/products/network/solution/vpn/connect/twice_nat/ )
本店が「このNWで接続して下さい。」と払い出されて、店舗側が違うNWになっている場合。
これって、店舗側のNWを総入れ替えするか、NATするかの2択な訳で。
やれ工数だの改修だのを考えると、結論NATになる訳です。

ただ、もう1台ルーターを置いてやるのが綺麗なやり方。
存在しないNWではなく、存在するNWを作ってしまう。
本社ルーター --> 店舗ルーター(NEW) -(払い出しNW)-> 店舗ルーター
という感じで払い出しNWを作ってしまって、そこのIP帯でNATさせる。
というのが割と綺麗なやり方だと思います。
が、そんなポコスカとルーターを買うという訳にもいかないと思いますし、
出来るので、1台でやってしまいましょうと。

そうすると、やり方としてはざっと考えて2つあって、
・ セカンダリIPをつけてルーティングさせてしまう。
・ 払い出しNWのIPでNATさせてしまう。
という2つかと。

で、もう存在はしてないけど、払い出しNWのIPでNATして通信出来れば良い。
という事で、今回はそんな感じの話です。

本店から払い出されたNWは10.1.10.1/24
基幹に接続するコンピュータのIPは接続元制限により10.1.10.254のみ許可。
例えばストコンが基幹にデータを送る場合は上記IPで送る必要がある。
というような感じ。


構築するNWはこんな感じです。


















で、どう構築するかって話になるんですが、
先のTwiceNATのページのreverseの部分を削除すればいいだけ。
というより、TwiceNATも存在しないNWを間に挟んで同じNWを通信させてるイメージなので、
それと同じことをしてやれば良いと。

書き方も割と単純に、ほんとreverseを削除しただけのこんな感じで通ります。
(ISPの部分やVPN認証、フィルタ等の設定は別途必要)
---
#ルーティング
ip route 172.11.0.16/32 gateway pp 1
ip route 10.20.0.0/16 gateway tunnel 1

#NAT
nat descriptor type 1 masquerade
nat descriptor masquerade static 1 1 172.11.0.16 udp 500
nat descriptor masquerade static 1 2 172.11.0.16 esp
nat descriptor type 2 nat
nat descriptor address outer 2 10.1.10.1-10.1.10.254
nat descriptor static 2 1 10.1.1.254=192.168.1.50 1

pp select 1
ip pp address 172.11.0.1/32
ip pp nat descriptor 1

tunnel select 1
ip tunnel nat descriptor 2
---

やっぱり存在しないNWがあって、途中でNATにより処理する。
というのはあり得る話なんですが、少し気持ち悪いなぁ。と思うのは私だけかしら。。

割と設計的にはあり得る話ですが、ググってもなかなか出てこないので、
書いてみました。

というわけで、よいクラウド?構築を。

2016年8月27日土曜日

IDCFクラウドの追加NWの注意点

最近、IDCFクラウドの追加ネットワークでちょっとしたハマり方をしたのでメモ。


IDCFクラウドはネットワークを追加する事が出来ます。
NICも独立するので、インターネット側のNWとは別にしてVPNのネットワークを作ったり、
DBの通信にしようしたり、Heartbeat専用のネットワークを作ったり。
まぁ、いろんな設計が無停止で柔軟に出来るようになっています。
ネットワーク追加も従量課金で20円/時間で課金され、1か月1万円が課金上限になるシステムです。

で、今回は既存の環境から移設というところで構築したのですが、
色々な制限があり再設計する事になりました。
結論から言うと、追加ネットワークを使った設計をする時は、
実際に追加ネットワークをしてから設計するか、IPを柔軟に変更できる設計にしておくと良いです。
例えばDBと接続する際にIP指定で許可している場合、許可設定の変更をしたり、
そもそもDBのIPが変更しなければならない可能性があります。
同じハマり方をしないようにご注意というところで。


1.システム予約IPがある
後方20個のIPはシステム予約として使用出来ないIPになっています。
例えば、デフォルトで以下NWが指定されます。(もちろん変更可能)
192.168.0.0/21
上記のうち、192.168.7.235~254はシステムで予約して使用不可能になっています。
従って、後方20IPを使用したIP設計は見直しになります。

2.CIDRが/24~/21のみ
CIDRは/24~/21でしか使用できません。/25、/26のNWは作れません。
従って、/24よりも分割されたNWは設計見直しになります。

3.仮想ルーターにIPが自動で採番される
仮想ルーターにIPが自動で採番されます。これはシステム予約IPに含まれていません。
例えば、192.168.0.0/21のNWで構築した場合、どこに採番されるか解りません。
基本的には192.168.0.1が使用されるようですが、2や3が採番される可能性もあります。
仮想ルーターのIPは使用出来ないので、こちらも被った場合は設計見直しになります。


ご察しの通り、3に見事にはまりまして。
移設前はWebサーバーを192.168.0.1に割り振っていたのですが、
移設したところ仮想ルーターに192.168.0.1を取られてしまい採番出来なくなりました。
今回はteslaからnewtonへのゾーン間移設だったのですが、
移設前と移設後で仮想ルーターのIPが変わった為、このようなハマり方をした次第です。

もし、セキュリティ的にもしばりが無いようであれば、
192.168.0.0/24のNWを作る場合、
192.168.0.0/23のNWを作って、192.168.1.1~254の範囲でIP設計をすると良いと思います。
どうしても/24で作成する場合、念のため、192.168.0.1~10は使用しない等で回避が出来るかと思います。


ちなみに、NICは追加/削除をしていくとデバイス名が変わります。
CentOS7であればさほど困らないかもしれませんが、、

CentOS6系でNICを追加/削除してeth1のつもりがeth2や3になってeth1に戻したいという場合、
udevを修正する事で変更する事が可能です。
以下ファイルにNICの情報が記載されています。
/etc/udev/rules.d/70-persistent-net.rules
上記ファイルで不要なNIC情報を削除し、最後に割り当てられているNICのnameをeth1にします。
udev rulesの反映を行う為に以下コマンドを実行します。
start_udev
これでeth1に戻ります。
あまり使う機会は無いと思いますが。。

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

2016年7月11日月曜日

クラウドの勉強会をやる際に注意するポイント

最近、クラウド系の勉強会をやる機会が多いどん斉藤ことtaka3110です。

初級~中級、上級、テスト対策、いろいろとやります。
非エンジニア向けのクラウド勉強会などもやったりします。
ベンダーフリーで使うクラウドは問わないので、こんな勉強会やってよ!など、
ご依頼はtaka3110までご連絡頂ければ打ち合わせ/企画から一緒にやります。

さて、宣伝はこの辺にして。。
クラウド系の勉強会、特にハンズオンの勉強会をやるときに注意するポイントが結構あります。
今回、実際にハマるポイントを書こうと思います。

① 上限の確認
 複数人でやる場合、サーバーの上限やIPの上限等、
クラウドが定める上限値に達していないか確認をします。
上限以上を使用するならば、上限の緩和申請をサポートにしましょう。
殆どのクラウドで上限の緩和が可能です。
遅くても3営業日前には申請をするようにしましょう。

② 同じアカウント内で同時実行時のデフォルトパラメーター確認
 同じ資料を見ながら行った場合やデフォルトの値を使用する場合に、
値がすべて同じになってしまいエラーが続発する可能性があります。
特に同じアカウントでやる場合(AWSでIAM使用する場合も含む)は、
ユーザー名を追加する等、ユニークな値を入力してもらうようにしましょう。
例:AWSのサーバー起動時のセキュリティグループ等

③ リージョンの確認
 これもハンズオンをやる時にたびたび出る問題です。
多くのクラウドはリージョンの変更を行っても殆ど画面上に変化はありません。
リージョンを指定して、ログインした際に確認するように促します。

④ OS選択時のマイナーバージョンの確認
 OSによってはマイナーバージョンが違うだけでログイン方法が変わるものがあります。
(管理者ログインが禁止されているものなど)
テンプレートやAMI等を選んでもらう際にはID等で解るようにしておきます。

⑤ 削除漏れの確認
 削除したと思ってDiskが残っていたり、スナップショットが残っていたりする事があります。
勉強会が終わったら、早めにリソース状況の確認を行って削除するようにしましょう。

⑥ サービスとアカウントを分ける
 これが一番恐ろしいんです!
社内の場合、同じアカウント内にユーザーを作成して多人数で実施するケースが多いと思います。
サービス提供をしているサーバーがある場合は間違えて停止や削除等の誤操作をする可能性があります。
結構触ってもらいたい場合、管理者に近い権限を付与する事になります。
教える側も緊張するので、なるべくサービスアカウントではなく、別途アカウントを取得するようにしましょう!
いたしかたない場合はリージョンを変更する等で容易に触れられない環境を作りましょう。


クラウドは便利なんですけど、便利だから簡単に出来るのではなく、
最低限の準備は必要という事ですね。

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

2016年7月1日金曜日

IDCFクラウドのDisk領域を3GBにしたテンプレート

Disk領域3GBのCentOS6.8テンプレートを作りました。

light.S1ならば1か月稼働で260円程度(2016/06/30現在)になります。
落としておいても1か月60円程度ですので、気軽に複数台の検証サーバとして使えるかと。
空き容量は約1.4GB程度ありますので、
色々と試せる環境かと思います。
cloudstack-apiもインストール済みなので、
ちょっとしたAPIテストや、検証などにご使用ください。

またコンテンツ領域を追加Diskにしてlogローテを行い、
そのlogをオブジェクトストレージ上に保存する事で、
コンテンツ領域のみをスナップショットでバックアップしながら、
無償で使える50GBのオブジェクトストレージを有効活用するなんて事も出来るかと思います。

いろんな用途で試して頂ければ幸いです。

自分の場合はab(負荷テスト)用として使ったり、踏み台として利用したり。
使わない時は落としておくような、ちょっとした事に使ってます。

要望やバグ連絡は本ブログにコメント頂ければ幸いです。
ちなみに本テンプレートを元に更新してコミュニティテンプレートをアップ頂いて構いません。

詳細
----
OS:CentOS 6.8
インストール:Baseシステム
その他:
・VMW関連
vmware-tools-esx-nox
vmware-tools-esx-kmods
vmware-tools-vmxnet3-common

・IDCFクラウド関連
パスワード変更ツール
認証鍵変更ツール
cloudstack-api(v0.10.2)

・開発関連
pip(8.1.2)
git(1.7.1)
及び上記解決の為のソフトウェア

セキュリティ:
iptables off
ip6tables off
selinux Disable
----

2016年6月30日木曜日

IDCFクラウドでテンプレートのエクスポートロックを解除する話

どうも、taka3110ことどん斉藤です。

IDCFクラウドはテンプレートをエクスポートが出来ます。
ただしISOから作成した仮想マシンのテンプレートは、
ライセンスの問題もあってエクスポートが出来ないようになっています。

オープンソースの場合はサポートに申請をすれば、
すぐにエクスポートロックの解除対応をしてくれます。

こんな感じで申請します。
-----
CentOS6.8を使用して作成した以下テンプレートについて、
エクスポートロックの解除をお願いします。
テンプレートID:[テンプレートIDを記入]
-----

そうすると中の人が確認をしてくれます。
問題無ければエクスポートロックの解除をした旨連絡が入ります。

公式のテンプレートはDiskが15GBで縛られている為、
サーバーを止めていても月額で300円掛かってしまうんですよね。
自分は3GB程度あれば良いので、ISOから作成しています。

エクスポートロックが解除されるとリージョン/ゾーン間でコピー出来るようになりますし、
コミュニティテンプレートの公開も可能になります。
エクスポートロックが解除されたテンプレートは、そのままコミュニティテンプレートには
出来ません。
一旦、エクスポートのURLを発行して、そのURLを使ってテンプレート作成をする事で、
コミュニティテンプレートが作れるようになります。ここは謎仕様です。
(発行されたURLはhttps://~ですが、テンプレート作成時はhttp://~に書き換えれば読み込めます)

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


2016年5月24日火曜日

IDCFクラウド「MORIO Dojo」に認定してもらったはなし

ブログを書くのが苦手なtaka3110こと、どん斉藤です。

なんでブログって書けないんですかね。
これ書こう、あれ書こう、って思って休日を迎えるんですけど、
結果的に家族サービスや競馬やってるんですよね。
ITへの愛が足りないのか。愛が。

という訳で、環境から作ろうという事でブログを書くきっかけを作りました。
IDCFクラウドで新しくアンバサダープログラムが始まりました。
その名も「MORIO Dojo」(モリオ道場)
IDCFクラウドの使いっぷりやコミュニティでの活躍っぷりによって、
段位認定してくれるというシステム。

このプログラムに参加すると、クローズドのコミュニティに参加して、
IDCFクラウドに長けたいろんな方々と会話が出来たり、
限定イベントに招待してもらえたり、プレゼントもらったり出来るそうです。

段位自体は空手みたいな感じで帯色によって認定が分かれてます。
段位認定の条件をクリアすれば次の段位へ!という形で、
最高段位のMORI帯を目指す。という感じのようです。
ゲーミフィケーション的な感じで面白いですね。

私もコミュニティを運営している端くれとして青帯で認定依頼をしたところ、
認定してもらえた次第です。
MORI帯までの道のりとして、一番の山場は3か月間、1か月に1度はIDCFクラウドの記事を書く。
基本、このブログはIDCFクラウドネタが多いのですが、連続性が無い、というか、
ブログを続けて書けない人なので、これをモチベーションにしてブログを続けてみようと。
そういう次第であります。
さて、私のクリア状況ですが、

白帯:
◎PCにMORIOステッカーを貼ってる
◎個人で発信する媒体を持っている
青帯:[いまここ]
◎ユーザー会への参加
○クローズドコミュニティでの積極的な発言
茶帯:
×IDCFクラウドのバナーを貼っている
△IDCFクラウド関連の記事を投稿(1か月に1回程度)
黒帯:
×IDCFクラウド関連の記事を3か月連続で投稿
◎お客様の声への協力
MORI帯:
◎ユーザー会を運営
×コミュニティテンプレートを公開

という訳で、茶帯は直ぐいけそうですが、黒帯は3か月後になりそう。
飛び級出来るなら3か月後にはMORI帯になれるんじゃないかと。

白帯については割と直ぐに認定されそうです。
青帯ですが、ユーザー会への参加があります。
東京では6月28日(火)にユーザー会を予定してますので、
こちらもチェキっといてもらえれば来月には青帯になれると。
ユーザーコミュニティ

というか、ユーザーコミュニティを作ってしまえばMORI帯の条件をクリア出来ます。
初めての運営でもmeetup運営メンバーに優しくサポートしてもらえます。
作りたいけどどうすんの?とか、やりたいから手伝って!
という方は以下の問い合わせから連絡くれればお手伝いします。

MORIO道場で検索すると奈良のよくわからん公共施設がヒットするので、
検索するときはMORIO Dojoで検索しましょう。
もしくは以下URLからどうぞ。

早速6月に限定イベントやるそうなので、登録はお早めに~。

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という感じで。
同様のことが発生した際にはブラウザを変更して検索、対応することに。

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

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

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