gummybare

NoSQLをもっと分かりやすく!

Couchbase Connect 2015 (SF) – 全米No.1の衛星放送企業DIRECTVの事例紹介

さて、今回はCouchbase Connect 2015のオープイングで紹介された全米No.1の衛星放送企業DIRECTVの事例を紹介します。DIRECTVの事例はKeynoteと個別のセッション「Agility with Data Modeling at DIRECTV Using Couchbase with Node.js; Couchbase Connect 2015」で紹介されていました。。。。が、プレゼンターのFidencio Garrido氏、Keynoteの最初に笑いを取ろうとしたのかどうかは分かりませんが、本人も「terrible accent」とコメントしている通り英語を母国語としていない人にとってはちょっとヒアリングが難しい!と感じるセッションでした。しかも笑いも取れなかったのが更に悲しい。でも訛りがあっても無くても大勢の前でプレゼンするのは緊張するのですごいことですよね。

本題に入りますが、DIRECTVは米国では非常に有名な衛星放送の企業のようで、シリコンバレー在住のCouchbase Mobile (Andorid) 開発者の板倉さんが「DIRECTVがCouchbaseを使ってるってほんとすごいですね!」と人ごとのように興奮していたことからも伺えました。どれくらいすごいのかというのをちょっと調べたところ、例えば同じ衛星放送を提供しているスカパーJSATの2014年年度末登録者数は約350万件であるのに対し、DIRECTVは「37million customer (約3700万の顧客)」と約10倍というところからも分かります。(※インターネット上の情報となりますので、あくまで参考情報です。誤りがございましたらご指摘ください)Fidencioさんのスライドでは38 millionと紹介されているので、顧客数がものすごい勢いで増加していることも予想できます。

以下からはFidencioさんセッションの概要をまとめた内容となります。

冒頭でFidencioさんがお話しているように、ビジネスの拡大によって開発者はより良いテクノロジーへの選択を迫られ、その上大きなシステムになればなるほど、DBAや開発者などのチームまたはグループなどそれぞれの観点から好まれるソリューションも変わってきます。嬉しいことにDIRECTVではCouchbase Serverが唯一のソリューションで、異なるチームの要望をただ解決するばかりか、Couchbaseのお陰でシステムをもっとシンプルに開発・運用できるになったと明言してくれました。

DIRECTVは3000以上のチャンネルを提供しており、この数字を聞いただけではそれほど多いとは感じないかもしれません。(※ちなみにスカパーは259chということなので、かなりのチャネル数だというのが分かるかと思います)しかし、このチャネル全てまたは特有のコンテンツを特有のエリア(国、地域など)に放映したりすることを考えるだけでもかなり複雑な仕組みになってきます。そして更にフォーマットの変更を何度も行うことを考えるといかに複雑か想像がつくでしょう。20年前のビジネスはもっとシンプルで、例えば契約形態もサブスクリプション契約の一種類でした。今日ではフォーマットもプラットフォームも多種多様で、例えばモバイル端末にもコンテンツ配信を行っています。またコンテンツの配信先も一般家庭だけでなくホテル、バー、イベント会場などへも提供しており、契約形態も多様化してきました。一般的にあまり知られていないホームセキュリティ(ドア/窓のセンサー、火災センサーなど)のサービスも提供しています。

約1年前、Fidencioさんのマネージャが新しいプロジェクトについて相談してきました。それはこれまでにはない考えで、柔軟性を必要とし、開発スピードを早くするためコード変更が少なく(UIの変更を度々することなど、エンジニアやDBAであれば誰でも嫌気が指してしまう)、検証の時間も最小限に押さえることができることを理想としていました。例えば、一般家庭とモバイル端末に配信するコンテンツのフォーマットなど、異なるスキーマに対応したシステムが必要でした。このような理由からRDBMSでの実現が難しいということはすぐに結論に至りました。以下はスライドから抜粋したものです。:

1)システム要件:新しいタイプのメタデータ(異なるバージョン)の追加・更新、複雑な設定、最小限のコード変更

2)DB要件:信頼性、スケーラビリティ、ハイパフォーマンス、(できれば運用性も)

3)選択肢:RDBMS、KVS、またはドキュメント型DB

そこで紹介されたのがCouchbase Serverでした。初めは単なるキャッシュか単純なKVSかと思い、検証した結果パフォーマンスには非常に驚かされたもののクエリについては懸念点が残りました(なおCouchbase Serverは他のどのドキュメント型DBと比較しても2倍以上のパフォーマンスが出るということが分かったともコメントしていました)。そこでCouchbase社に問合せたところSQLライクなクエリ言語「N1QL (SQL for Document)」を紹介され、上記2)の要件を満たしていると感じました。そのためCouchbase ServerのことをDIRECTVでは「Performance Beast」とよんでいます。しかも、できれば欲しいと思っていた簡単な運用ツールについてもCouchbase Serverは提供していました。モニタリングのツール、REST API、スケーラビリティ(例:ワンクリックのノード追加・削除、リバランスなど)など、Couchbase Serverはダウンロードから設定、開発に入るまで本当に時間がかからないことに驚かされます。

正直なところ、Couchbase Serverのこれまでの検索機能であるMap Reduceでは自分たちの想定しているシステムは到底作れないと思いました。N1QLを紹介された時、99%SQLと同じだと感じ、ラーニングコストも抑えることができたと思います。通常JSONのクエリにはJavascriptを使った方が良いと考えるエンジニアが多いかもしれませんが、N1QLは本当にSQLのように扱えるのでチームメンバーの吸収も早く、たったの数週間で運用フェーズでも使えると確信しました。もしデータをアプリケーション層で変換しないといけないのであれば効率的ではありません。そのためDIRECTVにとってJSONのデータをオペレーションレベルで使うことは効率的で、かつ高いパフォーマンスでもあるので、これがこのプロジェクトにとって非常に重要であると感じています。検証の段階では1 million (100万件)のレコードを使って行いましたが、1ミリ秒以下という非常に高いパフォーマンスで驚かされました。Node.jsを使うことに決めたのは高速にデータの入出力ができるようにすることが目的で、かつDIRECTVではJSONオブジェクトを多く扱うためです。JSONオブジェクトはデータの形式だけでなく認証にも使われています。DIRECTVでは至る所でJavascriptが使われる仕様になっています。例えばWebブラウザ、バックエンド、Couchbase (ビューの作成など)です。

他にもCouchbase Serverを使うメリットがあります。例えば一般的には書込みと読込みの量によってロードバランサを都度調整しなければいけないかと思いますが、Couchbase Serverの場合はスマートクライアントと呼ばれるものが負荷を自動的に分散するためロードバランサの調整が全く必要ありません。クエリのパフォーマンスを上げたい場合はN1QLを追加すれば終わりです。そして、サービスの増加またはグローバル展開に伴いデータを他のデータセンタにも展開したい場合、Couchbase Serverではクロスデータセンタレプリケーション(XDCR)を使って実現することができます。

以下からはスピーカーがIsidro Salcedoさんに代わりN1QLについて紹介しています。下記はN1QLについてスライドからN1QLについて紹介を抜粋したものですが、従来のSQLとほとんど同じというのがすぐに分かるかと思います。ここからはIsidroさんのコメントについて概要を紹介します。

◆Classic SQL (普通のSQL)

SELECT first_name, last_name

FROM customers

WHERE email = “someone@directv.com”;

◆N1QL (Couchbaseの新しいクエリ言語)

SELECT first_name, last_name

FROM bucket

WHERE email= “someone@directv.com”;

N1QLではアドホッククエリができ、DIRECTVとしてはこの機能を必要としていたので嬉しいです。そしてN1QLのユニークな機能の1つに検索の配列を設定できるということです。実際にクエリが実行されている時にパフォーマンスに問題があればインデックスを修正することで対応できました。

Couchbase ServerとN1QLはDIRECTVの求める機能を提供していましたが、それでも新しいテクノロジーなのでいくつか解決するべき点もありました。当時はまだRDBMSのイメージで開発していたので、テーブル=CBバケット、各バケットがエンティティ。。。と考え、そのアプローチが間違いであることに気がつきました。ドキュメントはドキュメントとして考え、各ドキュメントのデザインやバケットの構造を考える必要がありました。今後の計画としてはCouchbase Server 4.0 (N1QLとMulti Dementional Scaling)を使うことを予定しています。

いかがでしたでしょうか?後半はDIRECTVの事例というよりN1QLについて技術的な紹介がメインでしたが、DIRECTIVがCouchbase Serverを選択した理由が伝われば幸いです。Couchbase Server 4.0についてはCouchbase日本法人のSEである河村さんのブログで紹介されていますので、ぜひこちらも読んで頂ければと思います。(※4.0はまだデベロッパープレビューです)

次回の投稿もお楽しみに!

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

情報

投稿日: 2015年7月1日 投稿者:

ナビゲーション

%d人のブロガーが「いいね」をつけました。