KLab-データ分析グループのblog

安価で高性能なRedshift SSDノード(Dense Compute ノード)を試してみた

takada-atです。
先日Redshiftに新しく追加されたSSDノード(Dense Compute ノード)を評価してみました。
料金表で見ますと、従来型のHDDノードに比べ、容量はだいぶ少なくなっているものの、料金は安価となっております。
http://aws.amazon.com/jp/redshift/pricing/
 
容量価格
HDD: dw1.xlarge2TB HDD$0.850 /1 時間
SSD: dw2.large0.16TB SSD$0.250 /1 時間

※値段は2014年2月19日現在のものです。

われわれのユースケースだと、容量はそれほど使っていないので、こちらを利用することで性能改善やコスト削減を期待することができます。
現在使っているdw1.xlargeノード×4と、dw2.large(SSD)×4、dw2.large(SSD)×8でデータのインポートおよびクエリの性能を評価します。まずそれぞれのコストと容量は以下のようになっております
容量価格
HDD: dw1.xlarge×48TB HDD$3.4 /1 時間
SSD: dw2.large×40.64TB SSD$1.0 /1 時間
SSD: dw2.large×81.28TB SSD$2.0 /1 時間


なお、切替えも簡単で、AWSのコンソールから切替えることができます。ただしクラスターのリサイズ中は、データベースの書き込みが不可能になるので、タイミングに注意する必要があります。
37















まずデータロードについてですが、30万件10MB程度のデータのロードで、以下のような結果となりました。
  • HDD: dw1.xlarge×4 0.677 sec
  • SSD: dw2.large×4 3.240 sec
  • SSD: dw2.large×8 3.190 sec 
こちらはあまり改善は見られませんでした。元々の実行時間が1秒前後なので誤差が大きいのかもしれません。われわれのユースケースでは、これ以上大きなデータのインポートは使用していないので、それほど影響はないようです。


つづいて参照系のクエリについてですが、重いクエリにはかなりの改善が見られました。
(括弧内の数字はHDDと比較した際の時間比率です)
 
HDD: dx1.xlarge×4SSD: dx2.large×4SSD: dx2.large×8
クエリ112662.233 ms7960.340 ms (63%)6708.667 ms (53%)
クエリ230298.266 ms22166.461 ms (73%)12189.224 ms (40%)
クエリ324244.460 ms17963.970 ms (74%)10488.123 ms (43%)


10同ノード数でも若干性能が向上していますし、ノードを増やすとさらに性能改善が見られます。8ノードでも、従来の4ノードに比べてコストは2/3以下になるので、コスト低下と性能改善の両方が期待できます。

オープンソースのモバイル分析ツール「Countly」とは?(その3)

こんにちは。ponpoko1968です。

モバイル分析ツール「 Countly」の紹介、最後の3回目は実際のアプリを登録してSDKを組み込むまでを説明します。

アプリの登録

前回、サーバを起動して、アプリの登録画面がブラウザに表示されるまでを説明しました。
countly_initial_screen


実際に分析対象とするアプリを登録するには、上の画面で、
  • アプリの名称
  • カテゴリ選択
  • タイムゾーン
  • アイコン画像
を入力して、[アプリケーションを追加]ボタンを押します。もし、ボタンを押して何も起きない場合、前回説明した、countly-server/frontend/express/public/javascripts/countly/countly.config.jsのcountlyCommon.READ_API_URLという変数の値が正しくない(たとえば、ポート番号など)ことが考えられるので、修正してapp.jsを再起動し、ブラウザをリロードして最初からやりなおしててください。


設定が正しければ、下記のような画面が表示されるはずです。下の画面の「アプリケーションキー」の項目に表示されている文字列でサーバはアプリを識別します。SDKをアプリに組み込む際に使用するので控えておいてください。
countly_new_app

SDKの組み込み

次に、アプリにSDKを組み込みます。今回はiOSアプリの設定例を説明します。まずgithubからiOS用SDKのソースコードを取得します。
$ git clone https://github.com/Countly/countly-sdk-ios.git
Xcodeであらかじめ作ってあるアプリのプロジェクトを開いて、
  • Countly_OpenUDID.m
  • Countly.m
  • Countly.xcdatamodeld
  • CountlyDB.m
をドラッグ&ドロップで追加します。
countly_dnd_source

次に、プロジェクト設定の[Build Phase]タブの、"Link Binary with Libraries"を展開して、「+」ボタンを押すと、リンク可能な標準ライブラリのリストが表示されるので、その中から、
  • CoreTelephony.framework
  • CoreData.framework
を追加します。
countly_link_library


なお、ARCに対応したプロジェクトでCountly SDKを使用する場合、先ほど追加した、Countly SDKのソースコードはARC未対応であるため、コンパイルオプションに-fno-objc-arcをつける必要があります。リンク設定同様、プロジェクト設定の[Build Phase]タブの、"Compile Sources"を展開して、
  • Countly_OpenUDID.m
  • Countly.m
  • CountlyDB.m
をそれぞれダブルクリックするとソースファイル個別に適用するコンパイラオプションを指定する画面が表示されるので、"-fno-objc-arc"と入力します。
countly_objc-no-arc

次に、ソースコードを修正して、Countlyによるトラッキングを有効化します。
#import "Countly.h"
#import "CSAppDelegate.h"

@implementation CSAppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [[Countly sharedInstance] start:@"YOUR_APP_KEY" withHost:@"https://YOUR_API_HOST.com"];
.... 
「YOUR_APP_KEY」の部分は、アプリ登録後の画面に表示された「アプリケーションキー」、「https://YOUR_API_HOST.com」の部分は通信先APIサーバのURLで置き換えます。


カスタムイベントを登録するには
アプリ固有のイベントを記録・計測するには、カスタムイベントを使います。
記録したいイベントが起きたコードの前か後に、
[[Countly sharedInstance] recordEvent:@"event-name" count:1];    
と書くと、カスタムイベントが送信されます。1ユーザにつき、複数回起こりうるイベント、たとえばアプリ内課金などは、count:引数にアプリ側がカウントしていた回数を指定すれば良いでしょう。

イベントを送信する際、ユーザの属性など、付帯する情報を送ることも可能です。

NSDictionary* userAttribute = @{ @"userID" : user.id, @"level", user.level };

 [[Countly sharedInstance] recordEvent:@"event-name"

   segmentation:userAttribute 

   count:userBehavior.aCounter++];

付帯的な属性はNSDictionaryクラスにキー文字列、値のペアを設定して、Countly APIに渡すことが出来ます。

なお、CountlyはSDKの使用例サンプルも公開されており、githubから取得可能です。参考にしてみてください。

https://github.com/Countly/countly-sdk-samples.git

SDKを読んで気がついたこと

この記事の第1回でも書きましたが、Countlyを用いるユニークなメリットとして、クライアントSDKのソースが読めることが挙げられます。筆者がiOS版SDKのコードを読んで感じたことなどを簡単に共有しておきます。
  • 登録したイベントはすぐには送信されずCoreDataベースのキューに永続化され、バックグラウンドで順次送信される
  • つまり、アプリの異常終了があっても、データが失われることなく再起動時に送信が再開される
  • Countlyクラスのsuspend,resumeメソッドでイベントの送信処理を中断・再開できる。音ゲーやシューティングゲームなど、操作タイミングにシビアなゲームなどで、メインの処理を妨げないようにできそう
  • アプリがサスペンドしたら、送信処理は中断され、レジュームしたら再開される

まとめ
  • 導入自体は比較的簡単
  • 商用サービスよりは機能が少ないが、工夫とカスタマイズで補う余地はある
  • クライアントSDKのソースが読めるのは安心
  • ベース技術がnode.jsとmongoDBということで、導入する組織が、これらの運用ノウハウ(負荷・障害対策など)をもともと持ってるかどうかはポイントか

Countlyの紹介は以上となります。このシステムを実運用するとなると、それはそれで、いろいろと考慮・検討すべきことが多いとは思うのですが、手元のローカル環境では、思いのほか簡単に試せたので、アプリの行動解析に興味のある方は試してみられて、こういったサービスがどのようなものか見てみられてはいかがでしょうか。

ではまた。
 


 

オープンソースのモバイル分析ツール「Countly」とは?(その2)

こんにちは、ponpoko1968です。

前回ご紹介したオープンソースのモバイル分析ツール「 Countly」、今回はサーバプログラムのインストール、起動までを説明します。


前回ご説明したように、Countlyのサーバはnode,jsとMongoDBを使います。
今回は、MacOSX上にCountlyをインストールして起動するまでを説明します。

今回、MacOSXのパッケージ管理システムは、homebrewを使うことを前提とします。homebrewのサイトからインストールしておいてください。

まずMongoDB、node.js、imagemagickをインストールします。
brew install mongodb
brew install node
brew install imagemagick

つぎに、node.jsのパッケージ管理ツール、npmをインストールします。
$ curl https://npmjs.org/install.sh | sudo sh

countlyサーバのソースを展開します。
git clone https://github.com/Countly/countly-server.git

展開すると、下記のようなディレクトリが作成されます。
countly-server/
        ├── CHANGELOG
        ├── LICENCE
        ├── README.md
        ├── api/
        ├── bin/
        ├── frontend/
        └── log/

node-timeコンポーネントをインストールします。
$ cd countly-server/api 
$ sudo npm install time 

つぎに、countly-server/frontend/express/public/javascripts/countly/countly.config.jsを編集し、フロントサーバーからAPIサーバへのアクセス設定を行います。今回はフロントサーバとAPIサーバは同一ホスト上で動作させる前提とし、APIサーバーはデフォルト設定ではTCP3001番ポートで待ち受けるので、
countlyCommon.READ_API_URL = “http://127.0.0.1:3001”; 
とします。

次いで、APIサーバとフロントサーバーの設定ファイルを作成します。今回はサンプルで用意されているものをそのままコピーして使います。
$ cp countly-server/api/config.sample.js countly-server/api/config.js 
$ cp countly-server/frontend/express/config.sample.js countly-server/frontend/express/config.js 

準備が出来たので、MongoDBのサーバ、APIサーバー、フロントサーバーを起動します
$ /usr/lobal/bin/mongod &
$ node countly-server/api/api.js &
$ node countly-server/frontend/express/app.js &

フロントサーバには、ブラウザから、
http://127.0.0.1:6001/
にアクセスしてください。
下のような画面が表示されたら成功です。
countly_initial_screen


次回は、実際にスマートフォンアプリにSDKを組み込み、実際のデータをCountlyに送信して、結果を表示してみます。