GenieeBlogジーニーは最先端の広告テクノロジーで顧客の収益を最大化します。BLOGコーポレートブログジーニーは最先端の広告テクノロジーで顧客の収益を最大化します。Hueを使用して、Sensuからのアラートをランプで視覚化してみましたのでそれについて簡単にご紹介させていただきます。準備とりあえずアラートを表現したい種類分購入しました。今回は・SSP・DSP・DMP・その他の4種類としました。開封の儀を執り行った後は、初期設定を行います。パッケージの説明にもありますが、ランプの追加などもほぼ全てアプリからできるようです。APIで手軽に操作できます。hue」のAPIを叩いてみた。blog今回はsensuの状態をランプの色で可視化したいので、とりあえず手順通りにsensuユーザーを作成して試してみます。}}}が返ってきます。これがランプ一覧と現在の状態のようです。すると[]が返ってきました。eventのcategoryとそのstatus(CRITICALかWARNNIGか)を集計すればうまくいきそうです。版はcrontabに登録して1分ごとに回してみます。明るさで表現できない数のイベント発生も考慮して点滅(alert)も設定する感じにしました。“alert”=>$a};でエンコードされるようなjsonをHTTPでPUTします。実際の動作風景は以下の様な感じです。今回はcronで適当にapiを叩くというようなスクリプトなので、状態管理などの高等なことがあまりできていません。今後やる暇があったら、新規イベントがあったら一回点滅するなどしていければと思っています。技術トピックShareTweetTwitterFacebookHatena明けましておめでとうございます。2015年の第一弾はデータの分析に関する内容を紹介させていただきます。今回紹介するのはオープンソースのBIツールPentahoを使ったデータ分析についてです。PentahoとはPentahoとはオープンソースのBIツールです。PentahoはBIスイートですので、レポーティング、アナリティクス、ダッシュボード、データ統合など様々な機能が用意されていて、これらの機能の中から必要な機能に限定して利用することもできます。弊社では広告配信に関連するデータを集計して日々モニタリングしています。データを分析する切り口はユーザによって様々であり、定型的なレポートを各ユーザごとに作成するのが難しい状況でした。そこで、Pentahoのアナリティクス機能を導入し、ユーザがそれぞれ自分の見たい切り口でデータを分析できる環境を準備することになりました。Analyticsを使ってデータ分析を行います。データを蓄積するDBにはMySQLを利用しています。5.xMySQLはデータ分析用にレプリケーションされたものを利用します。アナリティクス環境ではユーザが自由にクエリを発行できるため、広告配信用のDBとは分離して分析専用のDBを用意することにしました。今回はDBにMySQLを使っているため、Pentahoの設定ファイルでMySQLに接続するための設定を行う必要があります。分析を行う前に、分析対象となるデータのスキーマを設定する必要があります。キューブ、ディメンジョン、メジャーをそれぞれ設定します。キューブとは多次元構造を表すもので、1つのデータソースとなります。キューブに対して、分析を行う集計軸(ディメンジョン)と指標(メジャー)を設定します。Workbenchを使って行いましたが、ここでは詳細な操作方法については割愛させていただきます。分析例Saikuの操作は直感的に操作できるインターフェースとなっています。ここでは、日付(Date)と広告のサイズ(Size)別にインプレッション(Impression)とクリック(Click)を抽出してみます。左側のMeasuresからImpressionとClickを選択します。次にDimensionsからSizeを選択してColumnsに、DateのYear/Month/DayをRowsに設定します。設定後にクエリを実行すると、画面右側のマトリックスが表示されます。(※結果の数値は適当な値です)結果のマトリックスをご覧いただければ分かるように、日付、広告サイズ別のインプレッションとクリックが指定した行列形式で表示されます。今回はシンプルなキューブを作成して分析を行いましたが、実際にはディメンジョン、メジャー共に10種類以上の項目を設定して利用しています。Pentaho構築前は細かな集計をエンジニアに都度依頼して集計してもらう必要がありましたが、Pentahoの構築によって利用者は項目を自由に選択して分析できるようになりました。エンジニアに依頼して集計してもらう場合は依頼するハードルやコスト、結果が出るまでに時間がかかる等、いろいろな問題が発生してしまいますが、これらの問題を少し解決できたのではないかと思います。Date2015.01.07Authorエンジニア201412.18便利な時系列データベースのInfluxDBと、その可視化ツールGrafanaについて技術トピックShareTweetTwitterFacebookHatena今回は、前回の記事で少し話題に出したデータベースのInfluxDBと、その可視化フロントエンドのGrafanaについて紹介していきたいと思います。InfluxDBは、単純に利用するだけならばMySQL等のRDBMSと似た感覚で使用する事ができ、監視系のデータをとりあえず入れておくという用途にはぴったりのデータベースです。GrafanaはInfluxDBに入れたデータを綺麗なグラフにして表示する事ができ、複数のグラフをまとめたものをダッシュボードとして保存して、いつでもそのグラフセットを簡単に呼び出すなど、機能も豊富な可視化ツールです。概要InfluxDBは時系列のデータを取り扱うのに特化したデータベースであり、Go言語で書かれています。特徴としては、スキーマレスであるHTTPのRestfulAPIから操作できるので、特別なクライアントが必要ない検索にはSQLライクなクエリ言語を利用できるため、クライアントサイドで利用するだけなら技術的障壁はかなり低い時系列での集計関数が豊富シャーディングおよびレプリケーションによるスケールアウトの効果が大きいなどがあります。単純にデータを挿入していくだけで自動的に時系列管理ができるため、弊社ではこれを監視システムによって取得したデータの保存先として利用しています。何か問題が発生した場合は、このデータベースから情報を取得して、いつどのような問題が発生したかの解析の助けとします。HTML5で書かれています。無骨な見た目のグラフで作業するよりもモチベーションが上がったという話も聞きます。表示範囲や項目の表示非表示の切り替え、表示データのフィルタリングなども簡単に行う事ができ、問題が発生した時により調査を行いやすくなっています。簡単な機能の紹介InfluxDBの設置とクエリ発行InfluxDBはdebおよびyumパッケージが用意されているため、InfluxDBを設置するサーバを用意して、サーバ上で以下のコマンドを実行するだけでInfluxDBをインストールする事ができます。influxdb-latest-1.x86_64.rpmInfluxDBは、データを「データベース」と「シリーズ」という単位で階層化します。シリーズはデータを格納すれば自動作成されます。curlコマンドを使ってデータベース作成からデータの格納までを行うと次のようになります。‘[{“name”:”test”,”columns”:[“val”],”points”:[[33]]}]’以上により、testingデータベースを作成し、testシリーズにval=23と、val=33という2つのデータを格納しました。次にここからデータを検索してみます。test”[{“name”:”test”,”columns”:[“time”,”sequence_number”,”val”],”points”:[[1418214673850,116725100001,33],[1418214334450,116703830001,23]]}]本当にcurlだけでデータの格納から取得までができてしまいました。timeとsequence_numberが追加されていますが、格納された時間と、格納されたデータの通し番号が自動的に追加される仕組みです。部分に注目してください。SQLと全く同じ構文です。最新5分のデータを取得する事ができます。)など、たくさんの機能がクエリから使用できます。詳しくは本家サイトのドキュメントを御覧ください。HTML5で書かれているため、普通のWebサイトの設置と同じ方法で利用する事ができます。公式サイトからtar.gzファイルを落として来てWebサーバから見える場所に置き、config.jsonを環境に合わせて設定(主にInfluxDBへの接続設定)するだけで使用可能になります。画面の操作も簡単で、グラフの作成時にInfluxDBの強力な集計関数も利用することができます。差分値などは重宝しています。成長するプロダクト達InfluxDBもGrafanaも成長が著しいプロダクトです。InfluxDBは、執筆時点(2014年12月現在)のバージョンはv0.8.6です。その時点では0.7.3でしたので、かなりの機能がこの間に追加されています。正規表現を用いたシリーズのJOINが可能になったりなど、使い勝手がかなり向上しています。Grafanaについても、以前は描いたグラフの情報を保存して次回接続時にも同じグラフを確認するためにはElasticsearchが必要でしたが、バージョンも上がってInfluxDBのみで設定が完結するようになりました。フィルタリング機能が強力になったなど、グラフの機能面でも強化されています。これらのプロダクトの成長に負けないように、弊社のプロダクトも日進月歩で成長していきたいと思っています。技術トピックShareTweetTwitterFacebookHatena今回は、弊社のインフラを監視しているシステムについて紹介させていただきます。広告の配信は24時間365日行われなければならないので、一旦配信サーバが落ちてしまうと大変な損害になります。弊社の配信サーバに限らず、止まってはいけないサーバに対しては、ほぼリアルタイムでサーバの状態を監視するシステムが動いていると思います。Cacti、Zabbix、Muninなどが知られています。これらのシステムは、サーバの状態を監視および記録し、異常を検知した時には、メールなどで通知を行います。監視システムを運用していく面で色々と使いづらくなっていきました。監視対象や監視項目の追加の作業の負担がどんどん大きなものになってしまうという懸念がありました。以上の点から代替のシステムを探して、Sensuという監視システムに行き着きました。簡単かつ柔軟な対応が可能であるという点でこちらに移行することになりました。移行の際の課題CactiからSensuに移行する際には、Sensuのクライアントを直接導入できないルータなどに対しても監視を行えるようにする必要があるSensuそのものは取得したデータの保存およびグラフ化機能を持たないため、別途用意する必要があるの2点が課題としてありました。ルータの監視を行うのは簡単ではありませんでした。ルータの情報を見に行って監視するためのクライアントとして同時に運用することで解決しました。ための情報がありますが、Graphiteの難しいところとしては、導入が複雑で容易ではないという点があります。Graphiteそのものの導入や設定が難しく、元々動いているCactiから置き換えるコストには見合わないと判断しました。代わりのメトリクス収集ツールとして、deb/rpmパッケージが用意されており導入が楽なInfluxDBを利用する事にしました。InfluxDBはNoSQLの一種で、時系列データを扱うことに特化したデータベースです。Sensuからここに保存したデータをGrafanaという可視化ツールでグラフ化しています。新しい監視対象を作ることができなかったのです。そのため例えばNginxでとりあえず作り、MySQLの分は手で追加するという事が必要でした。Sensuでは1つのサーバに複数のタグ付け(Sensu上ではroleといいます)が可能なので、このような問題は起こりません。新しく監視項目が増えた時に、その分だけをあとから追加する事も簡単になりました。Cactiでは実現が難しかった、異常検知時の通知方法を細かく設定することも簡単になりました。Cactiではできなかった複数の方法での通知を設定しています。技術トピックShareTweetTwitterFacebookHatena今回は、暗号の話をしましょう。いっても、難しい数学の話をするわけではありませんよ。数個のコマンドをたたくだけです。インターネットという開かれた空間の中であんまり収集されると困る情報をやりとりするのに暗号は重要です。弊社では広告配信のステータスをユーザのブラウザを介して送受信するので、そこで最も暗号化処理が活躍します。私の勝手なイメージですが、ブロック暗号の中ではBlowfishが処理速度が速いと思っていました。他にも3DESやAESといったよく使われる暗号方式はありますが、それらはBlowfishと比べて暗号強度は強いが処理は遅いものだと思っていました。この加速装置がどのくらいの性能であるのかみてみましょう。Standard)専用のCPU命令群です。AESのために専用の回路がCPUの中にあるわけです。CPUに足し算やかけ算をさせるのと同じように、AES(の処理の1ステップ)をやれ、と命令できるわけです。暗号標準と言われるだけありますね。すさまじい優遇措置です。速度比較opensslコマンドを使ってベンチマークをします。AESのベンチマークができます。opensslのバージョンなどは結果を参照ください。結果は次のようになりました。114657.96k3DESはやっぱり遅いですね。Blowfishの1∕4程度の速度しか出ていません。AESもBlowfishに比べれば遅......くもないですね。1KBを超えてから突如として性能が良くなっています。実は加速装置はまだ使っていないはずなんですが。今後の考察対象になりますね。メモリの速度とかまで関係してくると最早わかりませんが。試しに比較対象にしてみたCamelliaが意外に速かったです。本番さて、AES-NIを使うためには次のようなコマンドを使わないとならないようです。enc)ための暗号化プログラムを使うということでしょうか。時間があったらソースコードを見てみたいですね。-evpをつけた複数のアルゴリズムを同時に速度比較できないようなので、AESだけで実行します。結果は次のようになりました。397369.34k先ほどの結果と並べてみましょう。もとのAESとの比較では、256Bytesのときに6.4倍にもなっています。暗号標準は優遇されていますね。Intelでは?せっかくなので、IntelのCPUでも比較してみました。1コアあたりの公称周波数は上で使ったAMDのマシンよりちょっと劣りますね。aes-256-cbc結果。365707.26kAMDと比較して、周波数が低いので全体的に遅くなるかなと思いきや、Blowfishだけなぜか速くなっています。SSEなどベクトル演算関係の命令の速さの違いとか、opensslのバージョンによる実装の違いとか、あるかもしれませんね。cbcのほう)と使った場合(aes-256-cbcのほう)を比較すると、どの平文のサイズでも安定して4.9倍くらいになっています。まとめBlowfishと比べるとその他のアルゴリズムは遅いものと思っていましたが、完全に勝手な思い込みでした。3DESが3回暗号化している分3倍遅いくらいで、AESもチートハードウェアのアシストがなくてもそれなりのスピードでした。今まで使おうとも思ったことがなかったCamelliaが、AMDのCPUではBlowfishを上回るスピードを出してくれたのも収穫でした。技術トピックShareTweetTwitterFacebookHatena今回は、主にウェブサーバー、具体的にはLinuxのSO_REUSEPORT(プログラミング言語としてはC言語)の話題になります。背景として、弊社では、広告配信がいわゆるネイティブアプリケーションであるため、ウェブサーバーの開発を行っているといったことが挙げられます。そもそも今回の記事を書いたきっかけは、弊社でSO_REUSEPORTを使用し始めており、それについて紹介したいと考えたからです。「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のことが詳しいので今回は説明を省略します。Overflowを一読されると概要はつかめるかと思います。ここでいうSO_REUSEPORTは、特に言及が無い限りLinuxのものをさしておりますので、BSD系におけるそれとは異なりますので予めご了承ください。自社でHTTPを話すアプリケーションを作成する際に、やはり既存のウェブサーバーを参考にするのは非常に容易に思いつく手段です。弊社では、nginxをリバースプロキシや簡単なソフトウェアバランサとして使用している実績があり、そのパフォーマンス(特にスケーラビリティ)が非常に良いことは実感しています。CPU(コア数)だけ設定すればチューニングは不要というようなプログラムを作りたいという希望もあったので、安直ではありますが、自然にepollを使用したevent-drivenなプログラムを作成していこうという方針になりました。ようなライブラリ(HTTPまで実装されている!)があるのも後押しになりました。スケーラビリティの確保C10K問題をクリアするというのはNginxという先駆者を参考にしているので当然の話ですが、一方で負荷分散のデザインがなかなか固まりませんでした。ユーザーからのリクエストをバランシングする方法は実に様々ですが、スケーラビリティを確保するということを念頭に当初思いついた案は次のような物でした。細かい点は置いておいて、まず素朴な案としてはとりあえずスレッド(プロセス)ごとに同じソケットを監視してしまえということが思い浮かびます。ロジックとしては以下のような感じです。みんなacceptしに行くパターンの動作イメージ上の通りこの案は、実際の動作は無視できるとはいえエラーがたくさん起きるため、人によっては気持ち悪いと感じるかもしれせん。実際acceptが1リクエストにたいして全スレッド(プロセス)分発生するのでオーバーヘッドもあります。逆に利点としてはロジック自体シンプルですし、実際プログラムもシンプルに書けるということがあります。シンプルといっても同じソケットである必要があるため、既存のシングルスレッドのプログラムを単純に複数立ち上げるだけではできません。次に思いつくのは、acceptは排他的なので一人だけでやってほかのワーカー(返事を作る人たち)にソケットを渡すという方式です。実はmemcachedがこれで実装されているみたいなのですが、簡単に図にするとこんな感じです。listen()して1つだけソケットを作成スレッド(またはプロセス)を必要なだけ立ち上げる1スレッドだけ着信を待ち受ける。その他はpipeを待つ。memcachedっぽい何か案1と違って、動作上は非常にすっきりしたように見えます。この実装だと素朴な疑問として、accept担当のスレッドは暇なのかどうかや、ワーカーはコア数分立ち上げればいいのかacceptするスレッドを引いてコア数-1立ち上げるのかという議論もあり、当初の方針である「CPU(コア数)だけ設定すればチューニングは不要」から逸れてしまいます。案1と案2で作ってみたもののやはりぱっとしないので、nginxの実装を調べてみることにします。すると以下のようにaccept()を各ワーカー間で持ち回りにしていることが分かります。ランダムにacceptするlockを一定期間保持する起動後ワーカーが一斉にmutexを獲得しようとします。一定リクエストを処理したらmutexを解放することで、すべてのワーカーがリクエストを分散して処理できるようにしています。先ほどの案2と違って、ワーカー数=CPU(コア)数で余計な心配がありません。ワークロードが不均一な場合には、重たい処理をしているほどmutexを獲得しにいく頻度が減りますので、結果的にうまいこと負荷分散もできているように見えます。今まで出てきた案の中で一番良さそうかつ実績のあるこの方式ですが、やはりacceptをしに行くスレッドは瞬間的には一人ですので、性能的には案2と大差ないと考えられます。何よりも今まででてきた中で最も実装するものが多くなりそうです。上述の案をためしてみたのですが、(当たり前ですが)案1の「とにかくみんな取りにいく(acceptしにいく)」が非常に簡単かつ速くコードが書けてしまいます。3.9を知ることになります。score;}}SO_REUSEPORTが追加される前は、接続要求があった時にcompute_scoreで受信アドレスを指定しているか等優先度はあるものの、単純にlistenしているソケットを探しているため、このままでは常に同じソケットが選ばれます。next_pseudo_random32(phash);}}接続要求があった時にlistenしているソケットをラウンドロビンで選んでいることが分かります。これを採用すると、はじめの素朴な案1並みにシンプルなプログラムが書けます。SO_REUSEPORTを利用したときの動作イメージまた、既存のプログラムを活用するという意味では、SO_REUSEPORTをセットして複数立ち上げるだけで簡単なロードバランシングができてしまいます。今回の記事は以上になります。普段の仕事で使っているものの感想も幾分混じっている記事で、イマイチだったかもしれませんが、感想やご指摘いただけますと今後の参考にさせて頂きたいと思います。それでは、また次回をご期待ください。World!ジーニーでエンジニアをやっているxxjです。弊社もエンジニアがブログを書くという試みを始めて行きたいと思います。中身についてはまだ未定な部分も多いのですが、できれば以下の2点を満たすものを毎回執筆担当を変えてやっていきたいと思います。使っている人は少ないが、重要だと考えられる技術など日本語の情報が少ないもの弊社の情報発信という側面もありますが、読んでいる方に少しでも有意義な話題を書いていきたいです。お願いします!Date2014.09.25Authorエンジニアジーニーの経営、社内の制度雰囲気、マーケティング、技術まで、いろんなテーマで、ジーニーをご紹介していきます。Memberジーニー代表の工藤です。社風やジーニーでの働き方などをご紹介していきます。