2013年4月27日土曜日

splunkってなんじゃ?(splunk stormでfluentd)

前回の記事でsplunk enterpriseを利用しましたが、今回はsplunk stormを使用してみます。
enterpriseはインストール型でしたが、stormはサービス型です。
stormでは無料枠ではデータストレージが1GBまでとなっています。

また今回はsplunkのfluentプラグインがあるので、ログをfluentでstormに投げてみたいと思います。

splunk stormに登録して、プロジェクトを作ります。




ストレージ容量を決めます。1GBまでは無料です。



データの入力を設定します。
ここではAPIを利用するように設定します。


APIのリンクをクリックすると、APIの認証とエンドポイントの情報が表示されます。
  • AccessToken
  • API Hostname
  • ProjectID




次に、fluentdの設定です。
splunkのAPIに対してログを送信するBufferedOutputプラグインを作成している方がいたので、それを使ってみます。

fluent-plugin-splunkapi
https://github.com/k24d/fluent-plugin-splunkapi

# /usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-splunkapi


ソースやドキュメントを見ながらstorm用の設定を行います。
今回もapacheのログを送信します。

# vi /etc/td-agent/td-agent.conf
<source>
  type tail
  format apache
  path /var/log/httpd/access_log
  tag server1.apache.access
</source>

<match *.apache.*>
  type splunkapi
  access_token xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  project_id yyyyyyyyyyyyyyyyyyyyyyy
  protocol storm
  sourcetype fluent
  format text
  flush_interval 10s
  buffer_type memory
  buffer_queue_limit 16
</match>


access_tokenとproject_idには、上述のAPIの情報画面の情報を設定します。
fluentdを起動します。

# /etc/init.d/td-agent start


上の画像の「Explore data」をクリックすると、ログデータのサマリーが表示されます。
ソース欄に、fluentで設定したタグ名が表示されています。



このリンクをクリックすると、収集されたログデータの一覧が表示されます。




enterprise版と同様に、レポートを作成することもできますし、ダッシュボードに各種グラフを表示することもできます。





splunk stormでは、無料枠では1GB制限の他、1プロジェクトまでしか登録できないようです。

サービス型なので、サーバーメンテが必要ないのは良い点ですが、基本的にもっさりしています。
Plan選択画面で、2GB以上の有料枠に「Guaranteed response time for reported issues」とあるので
有料だとパフォーマンスが改善するのかもしれません。

自社でインフラを持ちたくなく、カスタマイズもそこまで必要ないという場合は、このようなサービス型のプロダクトは有効だと思います。

以上です。







2013年4月26日金曜日

StorageGatewayってなんじゃ?(バッファやキャッシュの容量を追加)

AWSのStorageGatewayを利用していて、パフォーマンスの見積もりが実際と合わず、最初に設定したバッファストレージやキャッシュストレージの容量が少なかったというケースがあるかもしれません。

公式ドキュメントでは、

Adding and Removing Upload Buffer Capacity (Gateway-Cached)

You can add more buffer capacity to your gateway without interrupting existing gateway functions. Note that when you add more upload buffer capacity, you do so with the gateway VM powered on; however, when you reduce the amount of upload buffer capacity, you must first power off the VM.

既存のゲートウェイ機能を中断せずにバッファ容量を追加することができます。
アップロードバッファ容量を追加する時は、ゲートウェイVMが起動中に行えますが
容量を減らす場合はまずVMをシャットダウンしておく必要があります。

As your application needs change and you add more storage volume capacity, you will might need to increase the gateway's upload buffer capacity. You can add more buffer capacity using the AWS Storage Gateway API (see AddUploadBuffer) or the AWS Storage Gateway console. 

アプリケーションのニーズが変化に応じてストレージ容量を追加すると、アップロードバッファ容量も増やす必要が出てきます。APIかAWSコンソールからバッファ容量を増やすことができます。




Adding Cache Storage (Gateway-Cached)


You can add more cache storage to your gateway without interrupting existing gateway functions and with the gateway VM powered on

既存のゲートウェイ機能を中断せずに起動したままキャッシュ容量を追加することができます。

You can add more cache storage using the AWS Storage Gateway API (see AddCache) or the AWS Storage Gateway console.

APIかAWSコンソールからバッファ容量を増やすことができます

Removing a disk allocated as cache storage is currently not supported.

キャッシュストレージの取り外しは現時点ではサポートされていません。


ということで、稼働中にバッファやキャッシュを追加することができます。
また現時点では、WEBシステムなどで利用していて後々アクセスが下がってきた場合キャッシュボリュームは減らせないので、料金的にリスクがありそうです。
長期的に考え、増やすときは必要な分だけ、というのがよさそうです。


では試してみます。




キャッシュ、バッファの追加




今回はゲートウェイインスタンス(EC2)の場合でやってみます。
以下の様な既存のゲートウェイインスタンスがあるとします。







「Gateway」タブの「Configure Local Storage」をみると、アップロードバッファに10GBのボリュームが適用されているのがわかります。また、キャッシュボリュームは20GBです。






ここで、ゲートウェイインスタンスにさらにアップロードバッファ用に10GB、キャッシュ用に20GBのボリュームを用意しアタッチします。





StorageGatewayの画面で、ふたたび「Gateway」タブの「Configure Local Storage」をクリックします。





すると、新しいディスクが認識され、バッファ用かキャッシュ用かを選択できるようになっています。
ここでは既存と同様、バッファ10GB、キャッシュ20GBとします。
「Save」ボタンを押すと、すぐに適用され、以下の画面でもバッファが20GBになってことがわかります。








バッファの削除



それではバッファを削除します。
削除する場合はシャットダウンが必要です。
「Gateway」タブの「Shut Down」をクリックして、コンソールをリロードして以下の画面になるまで待ちます。





上のような画面になったら、先ほど追加したバッファ用の10GBをデタッチします。





ディスクステータスが「Available」になったら、StorageGateway画面に戻り、先ほどの「Restart」ボタンをクリックします。
しばらくして、Gatewayが「Available」になったら「Gateway」タブの「Configure Local Storage」でストレージをみてみると、、、、





このように無事バッファボリュームを減らすことが出来ました。


また、これと同じようにキャッシュボリュームを減らそうとすると、Gatewayが「IRRECOVERABLE」という恐いステータスになってしまい、ボリュームが壊れてしまうようなので、停止中でもキャッシュボリュームはデタッチしてはいけません。サポートされるのをおとなしく待ちましょう。



以上です。





2013年4月18日木曜日

Kibanaってなんじゃ?(Kibana+elasticsearch+fluentdでログ解析)

前回の記事では splunk enterpriseを使ってみました。

今回もログ解析プラットホームである、Kibanaを使ってみます。
Kibanaは検索などにElasticsearchを利用します。
またKibanaはデータの収集にLogstashの利用を推奨しています。

それぞれ以下のようなプロダクトです。

Logstash
ログデータを収集し、解析して保存します。
この組み合わせで使用する場合、保存先はelasticsearchになります。

Elasticsearch
リアルタイムデータの全文検索や統計などをRestfulインターフェースで提供します。

Kibana
データの情報を描画し、検索したりドリルダウンで情報をたどれるGUIアプリケーションです。



この3つを組み合わせて使用すると便利なログ解析プラットホームが作れますよというのがKibanaの売りです。
データの収集や解析を行うLogstashは、入力、フィルタ、出力のプラグインを組み合わせて使うようになっているようです。こう見るとfluentdを思い出さずにはいられません。

そこでElasticsearchにfluentdでOUT出来ればLogstashの替わりにfluentdを使うことができ、より便利そうです。

探してみると、、、、
やっぱり、elasticsearchプラグインを作っている方がいました。
https://github.com/uken/fluent-plugin-elasticsearch


つまり、


fluentd + fluent-plugin-elasticsearch
ログデータを収集し、解析して保存します。
この組み合わせで使用する場合、保存先はelasticsearchになります。



ということで、完全にLogstashを置き換えられそうです。

そういうわけで早速インストールしてみました。

# cd ~/
# mkdir app
# cd app/
# curl -OL https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.20.6.tar.gz
# tar xzvf elasticsearch-0.20.6.tar.gz
# cd elasticsearch-0.20.6
# ./bin/elasticsearch -f

フロントで起動されました。今回はこのまま使います。

別のターミナルで同じマシンにログインします。

# cd ~/app
# yum -y install gcc ruby ruby-devel rubygems rdoc
# git clone --branch=kibana-ruby https://github.com/rashidkpc/Kibana.git
# cd Kibana/
# gem install bundler
# gem install eventmachine -v '1.0.3'
# bundle install

設定ファイルを以下のように編集します。
# vim ./KibanaConfig.rb
~略~

  Elasticsearch = "localhost:9200"

  #Set the Net::HTTP read/open timeouts for the connection to the ES backend
  ElasticsearchTimeout = 500

  # The port Kibana should listen on
  KibanaPort = 5601

  # The adress ip Kibana should listen on. Comment out or set to
  # 0.0.0.0 to listen on all interfaces.
  #KibanaHost = '127.0.0.1'
  KibanaHost = '0.0.0.0'

~略~


それでは起動してみます。
# ruby kibana.rb


これでKibanaとElasticsearchが起ち上がりました。

Kibanaはデフォルト5601ポートで起動するので、
http://xxx.xxx.xxx.xxx:5601/
にブラウザでアクセスします。



なにもデータがないため殺風景です。
データを用意しましょう。

データは別のサーバーからfluentdで送信します。

apacheを稼動しているサーバーで、fluentdを起動し、プラグインをインストールします。

# vim /etc/yum.repos.d/td.repo
[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/$basearch
gpgcheck=0
# yum install td-agent -y


次に、プラグインをインストールします。
/usr/lib64/fluent/ruby/bin/fluent-gem install fluent-plugin-elasticsearch


そして、設定ファイルを作ります。 今回は、apacheのaccess_logをtailしてelasticsearchに送信します。
# vim /etc/td-agent/td-agent.conf
<source>
  type tail
  format apache
  path /var/log/httpd/access_log
  tag server1.apache.access
</source>

<match *.apache.*>
  index_name adminpack
  type_name apache
  type elasticsearch
  include_tag_key true
  tag_key @log_name
  host 54.248.82.123
  port 9200
  logstash_format true
  flush_interval 10s
</match>

ここで、ポイントは、sourceのtagにサーバー名.apache.accessとしたことです。
matchディレクティブでtag_key @log_nameとすると、Kibanaに送られた後にこの名前で絞込みができ、別サーバーや別のタイプのログなどと区別できます。

それではfluentdを起動します。
# /etc/init.d/td-agent start


これで準備は整ったので、このサーバーのコンテンツにアクセスしてアクセスログを発生させます。
その後、Kibanaの画面を再度確認すると、、


ログのデータが表示されています。
左側のペインで一覧にカラム表示する項目を+押下して選択します。

ヘッダ中央のキーワード入力欄に
code:404などとすると404レスポンスを返したログだけを絞り込めます。

また、@log_nameという項目が、先ほどのtagになるので、キーワード入力欄に
 @log_name:"server1.apache.access"
と入力すると、サーバーやログの種類で絞りこまれます。




現在Kibanaは複数ログに対応する機能がないようなので、このようにしてログ毎の集計をとる形になりそうです。


やはりsplunkと比べると機能面では物足りませんが、用途によってはこれで十分な場合もありますので、選択肢の一つとして覚えておきたいです。

以上です。

2013年4月17日水曜日

splunkってなんじゃ?(splunk enterpriseを使ってみる)

ちまたでsplunkがちょっとキテるようなので、ためしにインストールしてみました。

splunkは日時のあるデータは全てログだとして、ログのデータを収集、集計、検索、レポートできるダッシュボード付きのログ解析プラットフォームです。
また、splunk streamというサービス型とsplunk enterpriseというインストール型の2つの製品にわかれているようです。
enterprise型は60日間無料試用でき、1日最大500MBのデータのインデックス化が可能だそうで、それ以上は有償版が必要だそうです。

今回はenterprise型を試用してみます。



インストール



splunkのサイトでサインアップし、ダウンロードページを開きます。

インストールしたいプラットホームのファイルリンクをクリックして次に進みます。
今回はLinux32bitのtgzファイルを選択します。





右カラムに「Get  this URL.」リンクをクリックして表示されるフロートにあるコマンドをコピーします。




Linuxの適当な場所で、このコマンドをペーストして実行します。

# wget -O splunk-5.0.2-149561-Linux-i686.tgz 'http://ja.splunk.com/page/download_track?file=5.0.2/splunk/linux/splunk-5.0.2-149561-Linux-i686.tgz&ac=&wget=true&name=wget&typed=releases&elq=621f839c-c06b-404d-a422-118feac791fd'


解凍して実行します。
# tar xzvf splunk-5.0.2-149561-Linux-i686.tgz
# cd splunk
# ./bin/splunk start
SPLUNK SOFTWARE LICENSE AGREEMENT

THIS SPLUNK SOFTWARE LICENSE AGREEMENT ("AGREEMENT") GOVERNS THE
INSTALLATION AND USE OF THE SPLUNK SOFTWARE DESCRIBED HEREIN. THE
INSTALLATION AND USE OF THE SPLUNK SOFTWARE WILL BE SUBJECT TO THE
ORDER DOCUMENT(S).

YOU WILL BE REQUIRED TO INDICATE YOUR AGREEMENT TO THESE TERMS AND
CONDITIONS IN ORDER TO DOWNLOAD THE SOFTWARE, REGISTER THE SOFTWARE
WITH SPLUNK AND OBTAIN LICENSE KEYS NECESSARY TO COMPLETE THE
INSTALLATION PROCESS FOR THE SOFTWARE. BY CLICKING ON THE "YES" BUTTON
OR OTHER BUTTON OR MECHANISM DESIGNED TO ACKNOWLEDGE AGREEMENT TO THE
TERMS OF AN ELECTRONIC COPY OF THIS AGREEMENT, OR DOWNLOADING OR
INSTALLING THE SOFTWARE, OR USING ANY MEDIA THAT CONTAINS THE
SOFTWARE, YOU ARE CONSENTING TO BE BOUND BY THIS AGREEMENT, INCLUDING
ALL TERMS INCORPORATED BY REFERENCE. THIS AGREEMENT IS ENFORCEABLE
AGAINST ANY PERSON OR ENTITY THAT USES THE SOFTWARE AND ANY PERSON OR
ENTITY THAT USES THE SOFTWARE ON ANOTHER PERSON'S OR ENTITY'S BEHALF.
YOU AGREE THAT THIS AGREEMENT IS EQUIVALENT TO ANY WRITTEN NEGOTIATED
AGREEMENT SIGNED BY YOU.

IF YOU AGREE TO THESE TERMS ON BEHALF OF A BUSINESS OR A GOVERNMENT
AGENCY, DEPARTMENT OR INSTRUMENTALITY, YOU REPRESENT AND WARRANT THAT
YOU HAVE AUTHORITY TO BIND THAT BUSINESS TO THIS AGREEMENT, AND YOUR
AGREEMENT TO THESE TERMS WILL BE TREATED AS THE AGREEMENT OF THE
BUSINESS. IN THAT EVENT, "YOU" AND "YOUR" REFER HEREIN TO THAT BUSINESS.

THIS SOFTWARE IS BEING LICENSED AND NOT SOLD TO YOU. SPLUNK PERMITS YOU
TO DOWNLOAD, INSTALL AND USE THE FUNCTIONALITY OR FEATURES OF THE
SOFTWARE ONLY IN ACCORDANCE WITH THE TERMS OF THIS AGREEMENT.

1. DEFINITIONS. Capitalized terms not otherwise defined herein can be
found in Exhibit A.

2. TERM. This Agreement will be in effect perpetually unless earlier
terminated as provided herein (the "Term").

3. LICENSE GRANTS. Subject to your compliance with the terms and
conditions of this Agreement, including (as applicable) your timely
payment of license fees set forth in the applicable Order Document (the
"License Fees"), Splunk grants to you the following nonexclusive,
worldwide, nontransferable, nonsublicensable, revocable, limited
licenses during the Term (or such other period of time provided in your
Order Document) to use:

3.1 the Purchased Software solely for your Internal Business Purpose
and to index no more than the peak daily volume of uncompressed data
Do you agree with this license? [y/n]: y

This appears to be your first time running this version of Splunk.

Copying '/opt/cloudpack/app/splunk/etc/openldap/ldap.conf.default' to '/opt/cloudpack/app/splunk/etc/openldap/ldap.conf'.
Generating RSA private key, 1024 bit long modulus
...................................++++++
...................................................++++++
e is 65537 (0x10001)
writing RSA key

Generating RSA private key, 1024 bit long modulus
...++++++
...............++++++
e is 65537 (0x10001)
writing RSA key
Moving '/opt/cloudpack/app/splunk/share/splunk/sarch_mrsparkle/modules.new' to '/opt/cloudpack/app/splunk/share/splunk/search_mrsparkle/modules'.

Splunk> Be an IT superhero. Go home early.

Checking prerequisites...
 Checking http port [8000]: open
 Checking mgmt port [8089]: open
 Checking configuration...  Done.
 Checking indexes...
  Creating: /opt/cloudpack/app/splunk/var/lib/splunk
  Creating: /opt/cloudpack/app/splunk/var/run/splunk
  Creating: /opt/cloudpack/app/splunk/var/run/splunk/appserver/i18n
  Creating: /opt/cloudpack/app/splunk/var/run/splunk/appserver/modules/static/css
  Creating: /opt/cloudpack/app/splunk/var/run/splunk/upload
  Creating: /opt/cloudpack/app/splunk/var/spool/splunk
  Creating: /opt/cloudpack/app/splunk/var/spool/dirmoncache
  Creating: /opt/cloudpack/app/splunk/var/lib/splunk/authDb
  Creating: /opt/cloudpack/app/splunk/var/lib/splunk/hashDb
 Validated databases: _audit _blocksignature _internal _thefishbucket history main summary
 Done
New certs have been generated in '/opt/cloudpack/app/splunk/etc/auth'.
 Checking filesystem compatibility...  Done
 Checking conf files for typos...   Done
All preliminary checks passed.

Starting splunk server daemon (splunkd)...  Done
                                                           [  OK  ]
Starting splunkweb...  Generating certs for splunkweb server
Generating a 1024 bit RSA private key
..++++++
.++++++
writing new private key to 'privKeySecure.pem'
-----
Signature ok
subject=/CN=ip-10-132-86-233/O=SplunkUser
Getting CA Private Key
writing RSA key
                                                           [  OK  ]
Done

If you get stuck, we're here to help.
Look for answers here: http://docs.splunk.com

The Splunk web interface is at http://ip-10-132-86-233:8000


これでスタートできました。
このサーバーはデフォルトで8000番のポートで動いているようです。

それではブラウザで確認してみます。
http://xxx.xxx.xxx.xxx:8000/





データの入力



ログイン画面が現れたので、デフォルトのID/Passwordを入力してサインインします。
次の画面で本パスワードに変更すると、ホーム画面が現れます。
ここで、扱いたいログデータの追加をしてみます。

「データの追加」のリンクをクリックします。




データ追加画面が表示されます、ここではsyslogをセットしてみます。
syslogのリンクを選択します。




リモートのsyslogを取得することでもできますが、今回はこのサーバーのsyslogを取得します。




ログの場所として/var/log/messagesを設定して、次に進みます。




ソースタイプはそのまま続行します。




プレビューがちゃんと表示されてますね。




そのまま続行して完了です。
同じようにapacheのaccess_logをセットしておきます。




検索



ダッシュボードにいくと、2つのログが登録されているのが分かります。




ここで、ソースの/etc/httpd/logs/access_logのリンクをクリックしてみると、そのログの全検索結果が表示されます。「サーチ」入力欄をみるとわかるように、これは「サーチ」入力欄に
source="/etc/httpd/logs/access_log"
と入力したのと同じ結果になります。




また、更に絞り込むために、
source="/etc/httpd/logs/access_log" useragent="*Chrome*"
などと入れると、UserAgentがChromeを含んだもののみが表示されたりします。




レポート


これらの検索などを組み合わせたりした集計をレポートという形式で保存することもできます。
画面右上の「作成」から「レポート...」をクリックします。




するとレポート作成するための画面が表示され、サーチクエリかフォーム選択で作成するレポートの条件を決めることができます。
ここでは、ステータスコード別のレスポンス数の推移統計をとってみます。

【サーチクエリで指定する場合は】

source="/etc/httpd/logs/access_log" | timechart count by status


【フォームで指定する場合は】

レポートデータ
  • レポートタイプ:値の推移
  • レポートが表示されます:他のフィールドで分割された単一フィールド

フィールド
  • 表示:数(カウント)
  • /:イベント
  • 分割基準:status(n)

と設定します。


次にグラフの種類などを指定します。
種類を「面」で、スタックを「スタック」にして決定します。




決定して、名前を決めて保存します。
レポートページから保存したレポート名を選択すると以下のように、レポートをいつでも見ることができます。
httpステータスコード別のリクエスト数の推移がスタックグラフで確認できます。


クエリなどはドキュメントが必要ですが、ほとんどの操作を直感的にできてしまいました。

このように、ログとして扱うことの出来るデータならなんでも取り込んですぐに時系列データとして組み合わせたりフィルタリングしてグラフなどにしたり、特定条件の検索などもできるので運用やカスタマーサービス、マーケティングの強い味方になりそうです。

以上です。

EMRってなんじゃ?(別アカウントのS3に入出力)

EMRをつかって、別のアカウントのS3バケットにアクセスしたい時があります。

ここでは例として、アカウントAのEMRからアカウントBのS3のログを集計して、アカウントBのS3バケットへ出力してみます。

まず、アカウントBのS3バケットのACLを設定します。
方法は以前の記事と同じようにSDKで設定します。
S3ってなんじゃ?(S3のログファイルを別アカウントでダウンロード


$src = 'memorycraft-log';//入力ログバケット
$target = 'memorycraft-archive';//出力先バケット
$owner_canonical_id = 'オーナー(アカウントB)の標準ユーザーID';
$other_canonical_id = '別アカウント(アカウントA)の標準ユーザーID';
$s3 = new AmazonS3(array('key'=>'オーナーのアクセスキー','secret'=>'オーナーのシークレットキー');
$s3->set_region(AmazonS3::REGION_APAC_NE1);

$res = $s3->set_bucket_acl($src, array(
  array('id' => AmazonS3::USERS_LOGGING,     'permission' => AmazonS3::GRANT_READ_ACP),
  array('id' => AmazonS3::USERS_LOGGING,     'permission' => AmazonS3::GRANT_WRITE),
  array('id' => $other_canonical_id,         'permission' => AmazonS3::GRANT_FULL_CONTROL),
  array('id' => $owner_canonical_id,         'permission' => AmazonS3::GRANT_FULL_CONTROL),
));

$res = $s3->set_bucket_acl($target, array(
  array('id' => $other_canonical_id,         'permission' => AmazonS3::GRANT_FULL_CONTROL),
  array('id' => $owner_canonical_id,         'permission' => AmazonS3::GRANT_FULL_CONTROL),
));



このままの状態でEMR(Hive)で出力すると出力されたファイルは以下のようになります。





パーミッションがありません。
これは出力するファイル自体のパーミッションの設定がおかしいためです。
これに権限を追加するにはHiveの場合は、HiveScriptの先頭に以下のコマンドを追加します。

set fs.s3.canned.acl=BucketOwnerFullControl;

再度実行すると、出力されたファイルにも権限が与えられているのがわかります。





この説明に関しては、最近日本語化されたEMRの公式ドキュメントにPigやカスタムJARの場合の対応法とともに詳しく記載されています。
http://docs.aws.amazon.com/ja_jp/ElasticMapReduce/latest/DeveloperGuide/emr-s3-acls.html

これで、アカウントをまたいだリソース集計が可能になります。
以上です。

2013年4月15日月曜日

EMRってなんじゃ?(HiveでS3のログをJSTに変換して1日分をまとめる)

S3のwebホスティングで、ログ出力の設定をしていた場合、ログファイルが大量に出力されます。
ログの記録時間は標準時で出力されていてわかりづらいです。

今回はEMRのHiveを利用して、日本時間の0時〜翌日の0時までのログを1ファイルにまとめてみたいと思います。


HiveScript



HiveScriptは以下のようにします。
まずフォーマット解析用のJARを読み込みます。

add jar /home/hadoop/hive/contrib/hive-contrib-0.8.1.jar;

入力用のテーブルを定義します。LOCATIONは引数から受け取ります。
ネックとなるのは、S3のログは基本的に半角スペース区切りですが、項目の値の中に半角スペースが入り込むため、「FIELDS TERMINATED BY」句ではなく、SERDEを使用して正規表現でログの1行を項目分けします。
今回は日付フィールドはそのまま年月日と時間部分に分けてしまいます。
CREATE EXTERNAL TABLE IF NOT EXISTS log (
 bucket_owner string,
 bucket_name string,
 log_time string,
 log_timezone string,
 remote_ip string,
 requester string,
 request_id string,
 operation string,
 key string,
 request_uri string,
 http_status string,
 error_code string,
 bytes_sent string,
 object_size string,
 total_time string,
 turn_around_time string,
 referer string,
 user_agent string,
 version_id string
) ROW FORMAT SERDE 'org.apache.hadoop.hive.contrib.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
  "input.regex" = "([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ \"]*|\"[^\"]*\") ([^ ]*) ([^ ]*) (-|[0-9]*) (-|[0-9]*) (-|[0-9]*) (-|[0-9]*) ([^ ]*) ([^ \"]*|\"[^\"]*\") ([^ ]*)",
      "output.format.string" = "%1$s %2$s %3$s %4$s %5$s %6$s %7$s %8$s %9$s %10$s %11$s %12$s %13$s %14$s %15$s %16$s %17$s %18$s %19$s"
)
LOCATION '${INPUT_BUCKET_LOCATION}';



出力用のテーブルを定義します。LOCATIONは引数から取得します。
パーティションはyyyy,mm,ddという単位で分割します。
CREATE EXTERNAL TABLE IF NOT EXISTS log_archive (
 bucket_owner string, 
 bucket_name string, 
 log_time string,  
 remote_ip string, 
 requester string, 
 request_id string, 
 operation string, 
 key string, 
 request_uri string, 
 http_status string, 
 error_code string, 
 bytes_sent string, 
 object_size string, 
 total_time string, 
 turn_around_time string, 
 referer string, 
 user_agent string, 
 version_id string
 )
 PARTITIONED BY (yyyy string, mm string, dd string)
 ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n' STORED AS TEXTFILE LOCATION '${OUTPUT_BUCKET_LOCATION}'; 


集計設定をします。
DynamicPartitionを無効にし、出力をgz圧縮します。
set hive.exec.dynamic.partition= false;
set hive.exec.compress.output = true;


集計します。
対象日のYYYY、MM、DDを引数から受け取ります。
ポイントとなるのは日付の扱いで、日時分割した年月日の方のカラムを0:00:00としてタイムスタンプに変換しJST⇛UTC変換したもので当日分のログとしてフィルタしています。
INSERT INTO TABLE log_archive PARTITION (yyyy='${YYYY}', mm='${MM}', dd='${DD}')
SELECT
 bucket_owner,
 bucket_name,
 concat("[", from_utc_timestamp(from_unixtime(unix_timestamp(concat(log_time, " ", log_timezone), '[dd/MMM/yyyy:HH:mm:ss Z]')), 'JST')," +0900]") as jsttime,
 remote_ip,
 requester,
 request_id,
 operation,
 key,
 request_uri,
 http_status,
 error_code,
 bytes_sent,
 object_size,
 total_time,
 turn_around_time,
 referer,
 user_agent,
 version_id
 FROM
 log
 WHERE
 unix_timestamp(concat(log_time, " ", log_timezone), '[dd/MMM/yyyy:HH:mm:ss Z]') >= unix_timestamp(to_utc_timestamp(concat('${YYYY}-${MM}-${DD}', ' 00:00:00'), 'JST')) 
AND
 unix_timestamp(concat(log_time, " ", log_timezone), '[dd/MMM/yyyy:HH:mm:ss Z]') < unix_timestamp(to_utc_timestamp(concat(date_add('${YYYY}-${MM}-${DD}', 1),' 00:00:00'), 'JST'))
 SORT BY
 jsttime
;



実行


Hiveジョブフローの主な起動設定などは以下の通りです。
Extra ArgsでHiveスクリプトに渡す引数を設定しています。





実行すると以下のように出力されます。




中身を見ると以下のように1日分がまとまっています。
また、日時の部分はJSTに変換して出力されています。

b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 01:29:44 +0900],10.115.82.47,arn:aws:iam::821635308497:user/iam-user,52A74398D7C4DBFE,REST.GET.VERSIONING,-,"GET /myfirst-bucket?versioning HTTP/1.1",200,-,162,-,28,-,"-","S3Console/0.4",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 01:29:44 +0900],10.115.82.47,arn:aws:iam::821635308497:user/iam-user,7CB888CE4F00C988,REST.GET.BUCKET,-,"GET /myfirst-bucket?prefix=&max-keys=100&marker=&delimiter=/ HTTP/1.1",200,-,1254,-,1044,1043,"-","S3Console/0.4",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 01:29:44 +0900],10.15.128.6,arn:aws:iam::821635308497:user/iam-user,473043B904924EB1,REST.GET.LOCATION,-,"GET /myfirst-bucket?location HTTP/1.1",200,-,142,-,29,-,"-","S3Console/0.4",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 01:29:44 +0900],10.15.149.57,arn:aws:iam::821635308497:user/iam-user,E1A726EAAA9ED195,REST.GET.LOCATION,-,"GET /myfirst-bucket?location HTTP/1.1",200,-,142,-,47,-,"-","S3Console/0.4",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 01:29:49 +0900],10.115.82.47,arn:aws:iam::821635308497:user/iam-user,648FA2CF0669ED48,REST.GET.VERSIONING,-,"GET /myfirst-bucket?versioning HTTP/1.1",200,-,162,-,26,-,"-","S3Console/0.4",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 01:29:49 +0900],10.115.82.47,arn:aws:iam::821635308497:user/iam-user,4620CF20BB92DE10,REST.GET.BUCKET,-,"GET /myfirst-bucket?prefix=&max-keys=100&marker=&delimiter=/ HTTP/1.1",200,-,1254,-,601,600,"-","S3Console/0.4",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 01:29:51 +0900],10.115.82.47,arn:aws:iam::821635308497:user/iam-user,AD489CC457FB430B,REST.GET.ACL,-,"GET /myfirst-bucket?acl HTTP/1.1",200,-,1317,-,406,-,"-","S3Console/0.4",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 01:29:51 +0900],10.115.144.24,arn:aws:iam::821635308497:user/iam-user,700100DED6F992D5,REST.GET.NOTIFICATION,-,"GET /myfirst-bucket?notification HTTP/1.1",200,-,115,-,21,-,"-","S3Console/0.4",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 01:29:51 +0900],10.115.144.24,arn:aws:iam::821635308497:user/iam-user,EEF9831033863E2B,REST.GET.LOGGING_STATUS,-,"GET /myfirst-bucket?logging HTTP/1.1",200,-,932,-,414,-,"-","S3Console/0.4",-

〜〜中略〜〜

+0900],10.89.198.21,b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,139A543A03AB1E01,REST.GET.ACL,-,"GET /?acl=&x-amz-security-token=AQYGQXBwVGtubLMUm1%2BEi%2BJ69YRAEYru2QGPPayzdgIKktgcIhBULb3hBbeFaN3DjPydiCyvDuvQ7g4kucsy0nQsWnAMBR2zfK1R%2B7Y7%2BdVgxVeH2fVJ9FQLFTkg2kkCaVj%2Fj%2FEWi8r%2F1hShQ4prv8OLBfDFETmtdw%3D%3D HTTP/1.1",200,-,1317,-,14,-,"-","aws-sdk-java/unknown-version Linux/2.6.18-194.17.4.el5.acc4xen Java_HotSpot(TM)_Server_VM/20.12-b01",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 17:36:44 +0900],10.89.198.21,b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,5FA69CCF9D1F8ABF,REST.GET.BUCKET,-,"GET /?max-keys=0&x-amz-security-token=AQAGQXBwVGtu2GApXRs%2FDi9mf5qWz55MQRSyS9v%2FnmGvqPo7lsP%2BAkR1V57UhWpJlAn6tYGp2tOL%2BC6Ai1BrRVOWUdUp6JkO%2FMqep7zd4h%2B5xJP8HtcO6pEWEV6t%2BikUh0qYfG8TatCWKvh15j6qu3XExYR5fnveRw%3D%3D HTTP/1.1",200,-,237,-,19,19,"-","aws-sdk-java/unknown-version Linux/2.6.18-194.17.4.el5.acc4xen Java_HotSpot(TM)_Server_VM/20.12-b01",-
b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,myfirst-bucket,[2013-03-20 17:36:44 +0900],10.89.198.21,b00fb3b3fbeb37e2dc44f010cdbeff2c31bc467a2022f00401bf18abbf9e4543,EB88F164094C5ECB,REST.GET.ACL,-,"GET /?acl=&x-amz-security-token=AQEGQXBwVGtuw71vZ%2F%2BhXOKS3VoBVeYAGzc2Csc0R73DDmsCndxf9cMwWqyG9fGRYM%2F%2BJVpuKk4gdS%2Ftr64M7O2VA%2BmzWfPUz8eSwYA3zvEmdBvC8JJrDlvDImPfhqi8mXHF5weAqj2byecuDWLTqJ7AQZBtY3b8dQ%3D%3D HTTP/1.1",200,-,1317,-,26,-,"-","aws-sdk-java/unknown-version Linux/2.6.18-194.17.4.el5.acc4xen Java_HotSpot(TM)_Server_VM/20.12-b01",-


これで日本時間でのアクセス集計ができました。 以上です。

2013年4月1日月曜日

Spiderってなんじゃ?(tpcc-mysqlでベンチマークをとってみた)

久しぶりのSpiderの話題です。
今回はtpcc-mysqlというベンチマークツールを使ってSpiderのベンチマークをとってみました。

mysqlにかぎらずDBのベンチマークツールの多くは、TPCという団体の定めたベンチマーク仕様に基いて実装されていて、トランザクションやアクセスなどのDB用途によっていくつかのベンチマークタイプに分かれていて、OLTP向けのTPC-Eや意思決定システム向けのTPC-HやTPC-DSなど色々あるようです。
http://www.tpc.org/information/benchmarks.asp

その中で、TPC-Cというのが複数ユーザーのトランザクションが発生するベンチマーク仕様で、顧客が商品を注文し在庫チェックと発送などをシュミレートするもののようです。
そして、このTPC-C仕様をmysqlのベンチマークとして実装したものが、tpcc-mysqlです。

このあたりのことは、以下のサイトに詳しく書かれていて非常に勉強になりました。
データベース負荷テストツールまとめ(2)
tpcc-mysqlによるMySQLのベンチマーク

今回はtpcc-mysqlを使ってSpider+RDS*4とRDS単体をテストしてみます。
構成は以下の通りです。




tpcc-mysqlのインストール


まず、ベンチ用のインスタンス(10.0.1.99)にtpcc-mysqlをインストールします。
# yum install bzr mysql-devel -y
$ mkdir ~/test
$ cd ~/test/
$ bzr init
$ bzr branch lp:~percona-dev/perconatools/tpcc-mysql
$ cd tpcc-mysql/
$ cd src
$ make all

これでインストールできました。
~/test/tpcc-mysql配下にtpcc_loadとtpcc_startという実行ファイルができていれば成功です。
$ ls -l ~/test/tpcc-mysql/
合計 248
-rw-rw-r-- 1 appadmin appadmin    851  4月  1 20:03 2013 README
-rw-rw-r-- 1 appadmin appadmin   1621  4月  1 20:03 2013 add_fkey_idx.sql
-rw-rw-r-- 1 appadmin appadmin    317  4月  1 20:03 2013 count.sql
-rw-rw-r-- 1 appadmin appadmin   3105  4月  1 20:03 2013 create_table.sql
-rw-rw-r-- 1 appadmin appadmin    763  4月  1 20:03 2013 drop_cons.sql
-rw-rw-r-- 1 appadmin appadmin    477  4月  1 20:03 2013 load.sh
drwxrwxr-x 2 appadmin appadmin   4096  4月  1 20:03 2013 schema2
drwxrwxr-x 5 appadmin appadmin   4096  4月  1 20:03 2013 scripts
drwxrwxr-x 2 appadmin appadmin   4096  4月  1 20:33 2013 src
-rwxrwxr-x 1 appadmin appadmin  60751  4月  1 20:33 2013 tpcc_load
-rwxrwxr-x 1 appadmin appadmin 154558  4月  1 20:33 2013 tpcc_start



テーブルの準備


予めstressという名前のデータベースを作成しておきます。
(名前はなんでも構いません)

次に、対象のテーブルとインデックスを作成します。
tpcc-mysql配下には、テーブルとインデックスの作成用DDL(create_table.sql、add_fkey_idx.sql)が付属しています。

インデックス用のSQLファイルには外部キーの作成も含まれていますが、
Spiderでは外部キーが使用できないため、外部キーからインデックス部分を除いたものを作ります。


また、Spiderノード用のテーブル作成DDLも作成します。

またSpiderノードからRDSに接続するときのために、Spiderノードのmy.cnfに以下の設定をしておきます。
spider_remote_sql_log_off = 1


次に作成したDDLを各インスタンスに流し込みます。
$ mysql -h 10.0.1.172 -u memorycraft stress -p < ~/test/tpcc-mysql/create_table.sql
$ mysql -h 10.0.1.20 -u memorycraft stress -p < ~/test/tpcc-mysql/create_table-spider.sql
$ mysql -h data1.cwnvl1ncuiwq.ap-northeast-1.rds.amazonaws.com -u memorycraft stress -p < ~/test/tpcc-mysql/create_table.sql
$ mysql -h data2.cwnvl1ncuiwq.ap-northeast-1.rds.amazonaws.com -u memorycraft stress -p < ~/test/tpcc-mysql/create_table.sql
$ mysql -h data3.cwnvl1ncuiwq.ap-northeast-1.rds.amazonaws.com -u memorycraft stress -p < ~/test/tpcc-mysql/create_table.sql
$ mysql -h data4.cwnvl1ncuiwq.ap-northeast-1.rds.amazonaws.com -u memorycraft stress -p < ~/test/tpcc-mysql/create_table.sql

$ mysql -h 10.0.1.172 -u memorycraft stress -p < ~/test/tpcc-mysql/add_fkey_idx.sql
$ mysql -h 10.0.1.20 -u memorycraft stress -p < ~/test/tpcc-mysql/add_fkey_idx.sql
$ mysql -h data1.cwnvl1ncuiwq.ap-northeast-1.rds.amazonaws.com -u memorycraft stress -p < ~/test/tpcc-mysql/add_fkey_idx.sql
$ mysql -h data2.cwnvl1ncuiwq.ap-northeast-1.rds.amazonaws.com -u memorycraft stress -p < ~/test/tpcc-mysql/add_fkey_idx.sql
$ mysql -h data3.cwnvl1ncuiwq.ap-northeast-1.rds.amazonaws.com -u memorycraft stress -p < ~/test/tpcc-mysql/add_fkey_idx.sql
$ mysql -h data4.cwnvl1ncuiwq.ap-northeast-1.rds.amazonaws.com -u memorycraft stress -p < ~/test/tpcc-mysql/add_fkey_idx.sql


ここまででDDLは出来上がりました。


テストデータの投入


次にデータの投入です。データの投入には先ほどのビルドで出来たtpcc_loadコマンドを使用します。
第1〜第4引数まではそれぞれホスト、DB名、DBユーザー、DBパスワードを指定し、第5引数には倉庫(warehouse)の数を指定します。 warehouseは1つにつき一番レコードの多いorder_lineテーブルで30万件程度に増えます。ここではwarehouseを100(order_lineテーブルで3000万件程度) に設定します。
このデータ投入処理はとても時間がかかります。
./tpcc_load 10.0.1.172 stress memorycraft xxxxxxxxx 100
./tpcc_load 10.0.1.20 stress memorycraft xxxxxxxxx 100



テストの実行


データがロードできたらtpcc_startでテストを実行します。
-w以降のオプションは以下の通りです。

  • -w:warehouseの数、基本的にはloadで設定したのと同じ値
  • -c:接続数 
  • -r:待機時間 
  • -l:実行時間(秒) 

基本的にはwarehouse数と、接続数を調整していろいろなパターンでテストしていきます。
./tpcc_start -h 10.0.1.172 -P 3306 -d stress -u memorycraft -p xxxxxxxxx -w 100 -c 10 -r 300 -l 3600
./tpcc_start -h 10.0.1.20 -P 3306 -d stress -u memorycraft -p xxxxxxxxx -w 100 -c 10 -r 300 -l 3600


結果は以下のようになり、一番最後のTpmC(1分間に処理できたトランザクション数)が指標になります。
***************************************
*** ###easy### TPC-C Load Generator ***
***************************************
option h with value '10.0.1.20'
option P with value '3306'
option d with value 'stress'
option u with value 'memorycraft'
option p with value 'satoru00'
option w with value '100'
option c with value '10'
option r with value '300'
option l with value '3600'

     [server]: 10.0.1.20
     [port]: 3306
     [DBname]: stress
       [user]: memorycraft
       [pass]: satoru00
  [warehouse]: 100
 [connection]: 10
     [rampup]: 300 (sec.)
    [measure]: 3600 (sec.)

RAMP-UP TIME.(300 sec.)

MEASURING START.

  10, 257(0):3.061|3.773, 258(0):0.580|0.773, 25(0):0.297|0.415, 26(0):3.753|4.259, 26(0):9.967|11.042
  20, 265(0):3.003|3.222, 264(0):0.570|0.617, 27(0):0.252|0.329, 26(0):3.448|3.478, 26(0):8.935|9.011
  30, 258(0):3.185|3.452, 256(0):0.626|0.684, 26(0):0.374|0.414, 25(0):3.700|4.063, 26(0):9.790|10.474
  40, 247(0):3.191|3.331, 249(0):0.605|0.630, 24(0):0.279|0.298, 26(0):3.702|4.258, 24(0):10.012|10.016
  50, 251(0):2.930|2.980, 248(0):0.526|0.548, 25(0):0.258|0.275, 24(0):3.111|3.113, 25(0):8.949|8.967
  60, 252(0):2.864|3.176, 254(0):0.544|0.585, 25(0):0.248|0.253, 26(0):3.249|3.315, 26(0):9.449|9.567
  70, 249(0):2.850|2.878, 247(0):0.527|0.540, 25(0):0.247|0.276, 25(0):3.126|3.156, 24(0):9.074|9.135
  80, 246(0):3.337|3.388, 249(0):0.651|0.663, 25(0):0.310|0.338, 24(0):3.897|3.967, 25(0):11.210|11.281
  90, 261(0):2.923|3.133, 262(0):0.548|0.577, 26(0):0.284|0.297, 27(0):3.218|3.283, 27(0):9.433|9.563
 100, 262(0):2.910|3.139, 258(0):0.528|0.561, 27(0):0.254|0.282, 26(0):3.170|3.193, 26(0):8.908|9.046
 110, 254(0):3.013|3.200, 253(0):0.570|0.586, 25(0):0.279|0.289, 25(0):3.328|3.511, 25(0):9.278|9.294
 120, 269(0):2.912|2.975, 272(0):0.546|0.553, 26(0):0.250|0.259, 27(0):3.180|3.212, 26(0):8.939|8.954
 130, 266(0):2.936|2.960, 265(0):0.533|0.567, 27(0):0.257|0.264, 26(0):3.190|3.192, 27(0):9.350|9.428
 140, 263(0):2.936|2.963, 263(0):0.578|0.632, 26(0):0.256|0.259, 27(0):3.348|3.456, 27(0):9.167|9.708
 150, 248(0):2.888|2.948, 247(0):0.545|0.603, 25(0):0.252|0.258, 24(0):3.144|3.165, 24(0):9.086|9.450
 160, 231(0):2.936|3.002, 232(0):0.526|0.539, 23(0):0.245|0.262, 24(0):3.199|3.237, 24(0):8.894|10.282
~(略)~
3480, 265(0):2.957|3.211, 265(0):0.534|0.603, 26(0):0.264|0.267, 26(0):3.267|3.330, 26(0):9.178|9.661
3490, 262(0):2.919|2.949, 266(0):0.527|0.538, 26(0):0.249|0.251, 27(0):3.178|3.183, 27(0):8.766|9.398
3500, 259(0):2.952|3.189, 257(0):0.541|0.652, 27(0):0.263|0.282, 26(0):3.266|3.279, 25(0):9.387|9.501
3510, 259(0):2.901|3.069, 262(0):0.532|0.612, 25(0):0.246|0.252, 25(0):3.205|3.226, 27(0):8.785|9.184
3520, 260(0):2.880|2.899, 259(0):0.519|0.586, 26(0):0.253|0.254, 27(0):3.168|3.189, 25(0):8.908|9.342
3530, 259(0):2.914|3.136, 250(0):0.534|0.604, 25(0):0.269|0.278, 25(0):3.296|3.330, 26(0):8.985|9.735
3540, 253(0):3.034|3.061, 261(0):0.572|0.632, 27(0):0.258|0.262, 26(0):3.234|3.319, 26(0):9.063|9.236
3550, 270(0):2.959|3.097, 269(0):0.522|0.547, 26(0):0.254|0.273, 27(0):3.242|3.244, 27(0):8.790|9.263
3560, 251(0):3.057|3.258, 250(0):0.609|0.653, 26(0):0.276|0.360, 25(0):3.360|3.444, 25(0):9.423|9.474
3570, 244(0):3.031|3.133, 248(0):0.546|0.618, 24(0):0.251|0.259, 24(0):3.286|3.299, 25(0):8.948|9.190
3580, 260(0):2.933|3.057, 260(0):0.527|0.542, 26(0):0.243|0.249, 27(0):3.175|3.190, 26(0):8.928|9.061
3590, 260(0):3.000|3.370, 255(0):0.560|0.667, 26(0):0.257|0.310, 25(0):3.327|3.329, 25(0):9.263|9.397
3600, 262(0):2.933|3.016, 263(0):0.523|0.540, 27(0):0.256|0.257, 27(0):3.180|3.230, 26(0):9.017|9.607

STOPPING THREADS..........


  [0] sc:91448  lt:0  rt:0  fl:0 
  [1] sc:91446  lt:0  rt:0  fl:0 
  [2] sc:9145  lt:0  rt:0  fl:0 
  [3] sc:9145  lt:0  rt:0  fl:0 
  [4] sc:9144  lt:0  rt:0  fl:0 
 in 3600 sec.


  [0] sc:91448  lt:0  rt:0  fl:0 
  [1] sc:91446  lt:0  rt:0  fl:0 
  [2] sc:9145  lt:0  rt:0  fl:0 
  [3] sc:9145  lt:0  rt:0  fl:0 
  [4] sc:9144  lt:0  rt:0  fl:0 

 (all must be [OK])
 [transaction percentage]
        Payment: 43.48% (>=43.0%) [OK]
   Order-Status: 4.35% (>= 4.0%) [OK]
       Delivery: 4.35% (>= 4.0%) [OK]
    Stock-Level: 4.35% (>= 4.0%) [OK]
 [response time (at least 90% passed)]
      New-Order: 100.00%  [OK]
        Payment: 100.00%  [OK]
   Order-Status: 100.00%  [OK]
       Delivery: 100.00%  [OK]
    Stock-Level: 100.00%  [OK]


                 1524.133 TpmC


何通りかテストをした結果、RDS単体とSpider+RDS*4で結果が入れ替わる条件がありました。

タイプデータ数接続数RDS*1Spider+RDS*4
mediumwarehouse=100102287.250 tpm1524.133 tpm
mediumwarehouse=100202368.133 tpm1564.283 tpm
mediumwarehouse=150201418.667 tpm1540.333 tpm


作者の斯波さんにも伺ったのですが、Spiderの特性としてデータノードへのオーバーヘッドがある分、通常の単体DBに比べると最初はパフォーマンスが落ちますが、並列アクセス(同時アクセス数)が多くなり、データ数も多くなってくるとSpiderの優位性が出てくるとのことで、それが上の結果と一致しました。

細かなチューニングなどで結果も変わってくるかと思いますが、最初からSpider構成にするというよりも、負荷やデータ量の拡大に応じて移行していくのがよいのかなと感じました。
前述のように外部キーが使用できないなど、Spiderはいくつかの特殊な制限があるため、運用後のSpiderによるスケールアウトを視野に入れているのであれば、Spiderの制限などを見越したテーブル、データ設計なども考慮したほうが良いのかもしれません。

以上です。

EC2ってなんじゃ?(CentOSでSSDインスタンス)

USリージョンにはSSDインスタンスというものがあって、「ハイ I/O クワドラプル エクストラ ラージ」というすごい名前で、hi1.4xlargeというタイプのようです。

QuickStartのAMI一覧でこのインスタンスタイプを使用できるのは、Cluster系のAMIのみのようです。


AMIによって選択できるできないの違いを調べてみると、通常のAMIはXenにおける、Para-Virtualization(準仮想化)という形式、hi1.4xlargeやその他のクラスタコンピューティング用のAMIはHVM(完全仮想化)という形式で、この2つはゲストOSの扱いが異なり、それにともなってAMIの作りも違うようです。

AMIの仮想化方式はインスタンス一覧に表示されている、この部分です。



通常のparavirtualのAMIを起動しようとすると、、


hi1.4xlargeは見つかりません。

なので、たとえばhi1.4xlargeのCentOSを立ち上げようと思ったら、通常のparavirtualのAMIではなくHVMのAMIを使う必要があります。

現在使用できるHVMのCentOSのAMIは以下が使用可能です。
https://aws.amazon.com/amis/centos-6-3-x86-64-hvm


このAMIを起動すると、



選択肢にhi1.4xlargeが出てきます。
これを選択していくと、SSDがエフェメラルディスクとして追加されるのがわかります。



このようにHVMのAMIを使用するとSSDインスタンスを作れるようです。

今回は以上です。