クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。

2014年3月9日
から hiruta
0件のコメント

DevCloud2でCloudStack環境を構築

3月6日「CloudStack Day 2014」、3月7日「第16回CloudStackユーザ会」に参加しました。CloudStack基盤を利用して、サービスを行っている事業者も、IDCフロンティア、Cloudnなどもあります。

VirtualBox 仮想アプライアンス環境「DevCloud2」を使って、CloudStack環境を構築することで、実際作業した内容になります。

まずは、http://people.apache.org/~bhaisaab/cloudstack/devcloud/devcloud2.ova　からDevCloud2仮想アプライアスをダウンロードします。

次に、DevCloud2仮想アプライアンスをVirtualBoxインポートします。

ホストオンリーアダプタ追加

DHCPサーバー
サーバー有効化　チェックをはずす

DevCloud2にプリインストールされているJavaが6なので、そのままCloudStackをビルドすると、エラーになりますので、Java7を最初にインストールします。DevCloud2はベースは、Debianを利用しています。

システムアップデート

apt-get update

make-jpkgを利用可能にするのはjava-packageをインストール。

apt-get install java-package

make-jpkgは、rootでは弾かれるので、一般ユーザを作成して実行

make-jpkg jdk-7u51-linux-i586.tar.gz

debファイルをインストール

dpkg -i oracle-j2sdk1.7_1.7.0+update51_i386.deb

Java7をデフォルトにします。

update-alternatives –config java

ここまでで、CloudStackビルドの準備は終わりです。

git リポジトリからcloudstackをクローン

git clone https://git-wip-us.apache.org/repos/asf/cloudstack.git

最新版は4.4 (?)だと、マイ環境では「Imort Error：No module named codes」で後述の基本ゾーン作成で失敗しました。

今回は、4.2-forwardのrevisionを利用しました。

git checkout -b 4.2 origin/4.2-forward

ビルドを実行。しばらく時間がかかります。

mvn -P developer,systemvm clean install

デプロイ

 mvn -P developer -pl developer,tools/devcloud -Ddeploydb

java heap sizeとかの設定を行わないと、cloudstackが起動できないので、java heap sizeの設定を行います。

export MAVEN_OPTS="-XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M -Xms512m -Xmx1024m"

cloudstackを起動します。

mvn -pl :cloud-client-ui jetty:run

管理サーバーへログインまで確認

http://192.168.10.56:8080/client/

別コンソールを開いて、必要なパッケージの導入

pip install mysql-connector-python
pip install requests

基本ゾーンの設定

mvn -P developer -pl tools/devcloud -Ddeploysvr

初期設定までは行うことができました。

2014年3月2日
から hiruta
0件のコメント

WindowsAzureとAWSのN/Wレイテンシーを比較してみました。

2/26に、WindowsAzureの国内リージョンが開設されたので、「海外リージョンに比べて、x3のレイテンシーの向上」と歌っていますが、他クラウドサービスの比較で、事実上のクライド業者の一人者になりつつあるAWSとのネットワークレイテンシーをツールを使って比較してみました。

ネットワークの帯域幅を測定するnuttcp[http://www.lcp.nrl.navy.mil/nuttcp/nuttcp.html]を使って、WindowsAzureとAWSのネットワーク帯域を調べてみました。　nuttcpは、さくらのナレッジの記事で紹介されています。

結果は。。。。

WindowsAzure(Type S/ CentOS 6.5)では、

77.0707 MB / 10.33 sec = 62.5661 Mbps 0 %TX 3 %RX 0 retrans 67.04 msRTT

10.33秒で77.0707MB転送でき、RTTが67.04との結果となりました。

一方AWS(Type m1.small / Amazon Linux )では、

81.1263 MB / 10.37 sec = 65.6427 Mbps 0 %TX 6 %RX 0 retrans 35.54 msRTT

10.37秒で81.1263MB転送でき、RTTが35.54との結果となりました。
簡単に調べた結果ですが、AWSの方がN/Wレイテンシー的には上になりました。ただ、差はほとんどないので、Azureも相当頑張っている印象。ただ、東京リージョン開設したばかりなので、利用しているユーザ数はAWS東京リージョンより少ないので、二か月後再度測ってみたいと思います。

2014年2月23日
から hiruta
0件のコメント

node.jsを使って、さくらのBase Storageにアクセスしてみました。

Node.js + AWS SDKを使って、S3に差分ファイルをアップデートし続けるnode-s3maをS3互換ストレージでも使えないか、node.jsの動作検証をさくらのBase Storageで行ってみました。

node-s3maのスライドはslideshareに公開されているので、こちらを参照ください。

※node-watchをファイルの差分チェックに使用されていますので、上記サンプルはnode-s3maが動かした後のファイルの同期に有効です。node-s3ma実行前のファイルはアップロードされません。
はじめに、node.js 、npmの環境構築から。node.js環境は、CentOS6の場合以下で一発でインストールできます。
yum install nodejs npm --enablerepo=epel

node.js用aws-sdkなどをインストール.

 npm install aws-sdk node-watch mime

var AWS = require("aws-sdk");

var config = require('./conf/config.json');

AWS.config.loadFromPath("./conf/config.json");
var s3 = new AWS.S3({endpoint: config.endpointSync});

s3.listBuckets(function(err,data){

for ( var index in data.Buckets){
 var bucket = data.Buckets[index];
 console.log("Bucklets:", bucket.Name, ' : ', bucket.CreationDate);
 }
});

アクセスキーなどの設定ファイルをjson形式で外だしすることも可能です。下記設定ファイルには、上記で使用していないプロパティもあります。


{
 "accessKeyId":"xxxxxx",
 "secretAccessKey":"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
 "region":"ap-northeast1",
 "topPrefix" : "backups/",
 "endpointSync": "b.storage.sakura.ad.jp",
 "watchDir": "/var/www/html/cms/"
}

実行すると、ネームスペースが返ってくることがわかります。ネームスペース作成日時も問題なく返ってきます。


# node node-s3-sample.js
Bucklets: xxxxlog : Mon Feb 03 2014 20:18:15 GMT+0900 (JST)

Node.js用のAWS SDKは以下にサンプルが公開されています。

http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/node-examples.html

2014年2月21日
から hiruta
0件のコメント

2/20 gumistudy#18　の勉強会に参加してきました。

昨日 2月20日　西新宿のgumi本社で行われた「gumi study#18」勉強会に参加してきました。

（都庁前駅A5出口から新宿中央公園を通って勉強会会場でありましたgumi本社に到着。10～15分はみておくのがいい。初台からでも距離はあまり変わりませんが、都庁前駅がオススメ）

まずは会場風景

IMAG0025

「AutoScalingを約1年運用してきました」　株式会社gumi 西村　遊様

AutoScalingを運用してみた経験の話でした。git(bootstrap用)、chef（サーバー設定)を組み合わせて、サーバーインスタンスの構築を一から構築することを避けている。

AutoScalingのパターンとして以下をあげていました。

Scaduled Scale out

トラフィック同時接続数が増加したら、インスタンスを起動し、減少したら、インスタンスを削除することをスケジュールで制御。gumiではゲームアプリなので、ユーザ層が利用する時間が異なる＝時間によって負荷も違う

Auto Healing

インスタンス数を調整するパターン。

最初は、gumiではスポットインスタンスで行っていたとのこと。

スポットインスタンスがくせ者で、スポットプライスの変動が激しくなっている。( ap-northest-1cだけが激しい。ap-norhest-1bも激しくなってきた。）オンデマンド価格の三倍に設定してみても、追いつかない。

入札価格が超えてしまい、スポットインスタンスが強制的にterminateしてしまう。最近ではスポットインスタンスでの運用をやめたとこと。

「クラメソ的 CloudFormationのススメ」 クラスメソッド　植木　和樹様

CloudForamtionの話。

利用するメリット

  • クリックで構築可能
  • 再利用可能。同じような構成だと別の案件で使っていたものをコソコソ直して、数日で提供した案件もあつたとのこと
  • 何度でも使い回せる
  • ELB、EC2の構成のシステムには最適
  • git、subverisionで変更管理

デメリット

  • jsonのクセ
  • CFnで対応できないプロパティがある
  • 対応していないAWSサービスがある。最近RedShiftがCFnに対応したなど
  • COMPLETE直前でロールバックしてしまつた

CFnを利用することで、AWSサービスの構成がよくわかるなど、学習効果がある。AWSを理解してみたい方にはオススメ。

「Chef導入後のインフラ業務あれこれ」　株式会社gumi 本間　和教

「このサーバーがだれが準備したかわからない」

「どのように準備したかわからない」

など運用に問題山積み。

運用を改善する目的で、Chefを導入。

Chef-serverを導入して、すべて解決したわけではない。

社内のChatTool、機能別ではなく、サーバー別で。

インストール手順もレシピ化。

2014年2月20日
から hiruta
0件のコメント

さくらの夕べに参加しました。

vagrant + Ansibleの構成ツールの話とか、主に帯域を食いつぶすDoSをどうさくらが対応してきたか、LT4本ほどの内容でした。

Ansible/Vargrantでアドテク環境を最速構築

(内容については後日)

大雪の影響で開催延期となりましたJAWS-UG千葉勉強会 Vol.3で発表するはずだったLTも今回初発表しました。

2014年2月15日
から hiruta
0件のコメント

本日開催予定のJAWS-UG千葉勉強会の延期

本日開催予定の交通の乱れと雪の影響からJAWS-UG千葉勉強会 Vol.3を延期することになりました。

今回初LTとして、「さくらのBase Storage v.s S3」の標題で話されて頂く予定でしたが、残念です。

JAWS-UG勉強会の代わりというわけではありませんが、2/19 (水)　新宿ロイヤルビル3Fで19:30から開催される第14回さくらの夕べのLTで話させて頂く予定です。

2014年2月6日
から hiruta
0件のコメント

さくらのBase Storageへfluentd(td-agent)を利用してnginxのログの転送に成功！

前回のブログで、fluentd(td-agent)を利用して、さくらのBase Storageへnginxのログの転送にエラーが出る件ですが、設定を試行錯誤した結果、無事転送できるようになりました。

修正したところは、fluentd起動にアクセスチェックを行わないように、check_apikey_on_startをfalseにしたところになります。

これは、IDCFの分散ストレージへのfluentd(td-agent)による転送の設定と同じでした。

fluentdの設定を一部記載しておきます。

<match nginx.access>
 type s3
aws_key_id XXXXXXX
 aws_sec_key YYYYYYYYYYYYYYYYYYYYYYYYYY
 s3_bucket sakuralog
check_apikey_on_start false
 s3_object_key_format %{path}%{time_slice}_%{index}.%{file_extension}
 s3_endpoint b.storage.sakura.ad.jp
 path logs/
 buffer_path /var/log/td-agent/s3
 flush_interval 1440m
 time_slice_format %Y%m%d-%H
</match>

ストレージ内をs3cmdで確認すると、確かに、ログが作成されていることが確認できました。


# s3cmd ls s3://sakuralog/logs/
 DIR s3://sakuralog/logs/20140204/
2014-02-06 13:08 635 s3://sakuralog/logs/20140206-04_0.gz
2014-02-06 13:08 2939 s3://sakuralog/logs/20140206-05_0.gz

相変わらず、Base Storageのコントロールパネルのオブジェクトからは確認できない。この辺りはおそらく未実装ではと予想される。

この状態でしばらく運用してみます。

2014年2月3日
から hiruta
0件のコメント

さくらのストレージサービス Base Storageを試してみました。

2/3 さくらインターネットからストレージサービス　Base Storageベータサービスが発表されました。

主な特徴として

  • S3互換ストレージ
  • 1オブジェクト最大4TBまで扱える。(S3だと5TBまで)
  • イレイジャーコーディングによるデータ保護　(S3はコピーを複数Azに作る方法とは別のようです)

まずはサインアップ

さくらインターネット会員登録

さくらの会員ＩＤをもっていれば、ログインして電話認証

さくらインターネット会員登録-1

画面に記載された電話番号に電話を掛けて、音声案内で暗証番号が読み上げられるので、上記下部部分に暗証番号を入力してＯＫ

Base Storageのページのコントロールパネルをクリック

さくらのクラウドとはコントロールパネルが異なるので注意。翌々は統一してもらいたいところ。

アカウント選択-1

アカウント選択-2

ネームスペース（S3だとBucket）を新規作成

パブリック、プライベートしか設定できず。S3ほどのアクセスポリシーの機能はなさそう。

作成 ネームスペース

管理 ネームスペース

アクセストークンのユーザ名が、AWSだとアクセスキー、トークンが、シークレットキーに相当します。

ここ　に記載されている通りで、s3cmdでストレージへのアクセスは成功しました。

s3cmd lsでは表示されるのに、コントロールパネルの一覧にはなにも表示されない症状が表示されてしまいます。

次に、fluentd(td-agent)のs3-pluginをさくらのBase Storageに振り向けてみた。
aws_key_id、aws_sec_key、s3_bucket、s3_endpoint を変更。
SSLのワイルドカードSSLが「*.storage.sakura.ad.jp」なので、「s.b.storage.sakura.ad.jp」だとSSLでエラーが起きているようにみられる。td-agentが出力したエラーは下記となります。

2014-02-03 20:57:40 +0900 [error]: unexpected error error_class=OpenSSL::SSL::SSLError error=#<OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed>

2014年1月31日
から hiruta
0件のコメント

2月参加予定の勉強会

2月参加予定の勉強会（セミナー）です。

2/4  AWSクラウドで安全なWebシステムを実現     「Deep Security＆InfoCage SiteShellハンズオンセミナー」　申し込みサイト
2/4  第4回 OSS運用管理勉強会　申し込みサイト
2/15 JAWS-UG 千葉支部 Vol.3 -AWSスタートアップあるある  申し込みサイト
2/19 第4回さくらの夕べ　申し込みサイト
2/20 gumiStudy #18　申し込みサイト

勉強会（セミナー)参加レポートは後日ブログにアップします。

2014年1月21日
から hiruta
0件のコメント

M3インスタンスタイプの値下げ

M3インスタンスタイプの価格が時間あたり　$0.171から$0.113にプライスダウンのニュースリリースがAWsから発表されました。元記事はこちら。

となっていますが、m3.medium、前世代のm1を比較してみました。

vCPU ECU メモリ インスタンスストレージ(GB) Linux/UNIX 料金
m3.medium 1 3 3.75  1 x 4 SSD $0.113/時間
m1.medium 1 2 3.75 1 x 410 $0.175/時間
m1.small 1 1 1.7 1 x 160 $0.088/時間
c3.large 2 7 3.75 2 x 16 SSD $0.192/時間

上記表から一目でわかる通り、m3.mediumをm1.smallに近い価格で利用できます。

おまえに、m3.mediumのインスタンスストレージはSSDなので、高速なIOを必要とする処理も十分対応できると思われます。