「Facebookになったつもりで考える」── 第1回NHNテクノロジーカンファレンスから: ITジャーナリスト星暁雄の"情報論"ノート

「Facebookになったつもりで考える」── 第1回NHNテクノロジーカンファレンスから

2012年5月19日（土）、「第1回NHNテクノロジーカンファレンス」というイベントに参加しました。グリー、DeNA、NHN Japan各社のストレージに関する議論、そして新しい分散フレームワークDripcastに関する技術的な話を聴いてきました。

カンファレンスの開催概要はこちら。

第1回NHNテクノロジーカンファレンス詳細内容決定！

主催者から一つ大事なメッセージが。「YAPC::Asia2012（2012年9月27〜29日）にぜひ来てください」とのことです。

以下、このカンファレンスのメモです。網羅的ではありません。全貌を把握したい方は動画と発表資料を見てくださるようお願いします。

DeNAのMySQL運用管理の実際を解説

講演タイトルは「ビッグデータと戦うMobage DBA」（発表資料）。講演者はディー・エヌ・エーシステム統括本部IT基盤部Mobage基盤管理グループ岩永亮介氏。

「モバゲー」のPV（ページビュー）は現在は公開していない
2006年時点で6億PV/日、2009年（ソーシャルゲーム開始）時点で20億PV/日のトラフィックだった。
MySQLが好き！
500台以上のDBサーバーを管理
データのサイズは100TB規模（レプリカ含む）
トラフィックはピーク時には1Mqps（query/s）以上
スケールアウトのため、DBをマスタ/スレーブに分割、複製によりスケーラビリティを確保する
Shading手法。末端を増やす。テーブルで分ける方法、レコードで分ける方法がある
スケールバックが必要な場合がある。サーバ集約やサービス縮小。
集約のさい、2個のマスタDBを1個にくっつけるのは無理がある。DeNAのやり方は、OSは1個で、MySQLのインスタンスを2つ設定し、違うIPアドレスを割り当てる方法。
データのアベイラビリティ。MySQL-MHA: MySQL Master High Availability manager and tools（DeNA開発のオープンソースソフトウエア）を使い、マスタDBに障害が発生した場合、バックアップを昇格させる。
Purge重要。DBのサイズが肥大化すると性能は劣化する。そこで不要のレコードを消す。対象は古いメッセージやログなど。
MySQL5.1以前はDELETEを発行して消すしかない。だが時間で範囲を指定するクエリは遅い。そこでバックアップから消すレコードを選択し、プライマリキーを利用してDELETEを発行する。レプリ遅延を防ぎつつ、負荷を抑えつつ、消していく
MySQL5.1以降では、消すだけであればRANGE partitioningを使える。
プライマリキーを用いたクエリはKVSライクな内容。そこでHandler Socket Plugin for MySQLを書いて使っている。SQLパーサをスキップし、Handlerインタフェースを直接使う。memcachedよりも高速。ただしキャッシュのコンシステンシへの配慮はない
レプリケーション遅延をどう管理するかが問題。事前には分からない。バックアップは先に遅延するため、これを利用してバックアップサーバを監視する
SSDはスレーブへの適用に効果的。SATA-SSDを活用している。PCIe-SSDは高価

興味深かったのは、質疑応答です。グリーの藤本氏から、「MySQLマルチインスタンスか、仮想化か」というトレードオフについての質問がありました。岩永氏は、「仮想化はI/Oのペナルティが大きい。OSは1つにして複数のMySQLインスタンスを立てる」という回答だったのですが、藤本氏は「Solarisの人が、Linuxだからダメなのだと言っているのですが・・」とコメント。製品が変われば、手法のトレードオフが変わってくる可能性を示唆した格好です。

DBサーバ集約では1OS上に複数のMySQLインスタンスを配置し、IPアドレスで振り分け

「枯れた技術」によるオブジェクトストレージSTF

講演タイトルは「STF - コモディティツールによる内製ストレージ」（発表資料）。講演者はNHN Japan/ Japan Perl Association牧大輔氏（lestrrat）。NHN Japanの中でも、特に旧ライブドアのインフラ部門の流れをくむ講演でした。

STFは、NHN Japanのサービスで利用しているストレージ。「ロケタッチ」などで使われている
Amazon S3と似たもの
スケーラブルなオブジェクトストア。ストレージの残り容量を一切きにせず、とりあえずSTFに突っ込んでおけばよい。何億個でもファイルを入れられる。
URIがオブジェクト
オープンソース。GitHubで公開（https://github.com/stf-storage/stf）。
主にPerlで作られている
HTTP（Plack, nginx）、MySQL+Q4M、Memcashedと「枯れた」技術を使っている。運用をシンプルに、手を入れやすくした
S3を使わず内製している理由は、一つはデータセンターを運営しており、サーバもバックボーン回線も持っていることがある。S3やEC2を利用した場合、月間100万円規模の課金が発生するのではないかと考えられる。最大の理由は「エンジニアがいるし、その方がたのしい」ことだろう。
もちろん、条件が変わればS3の方が割安になる場合もあるだろう。
なお、司会者からの補足で、「開発当時はAmazon S3には日本リージョンがなかった」ことも理由の一つだったとのこと。
数十台のサーバー、4〜5億個のオブジェクト、13億のレプリカ、70〜80TBのストレージ。
「ストレージが足りなくなったら、PUT/GET/DELETEを理解するHTTPサーバーをガチャンと入れるだけで容量が数TB増える。スケールアウト簡単」
今実装中の"STF Future"では、クラスタリングを取り入れ。1クラスタに3ストレージがあり、すべて同じエンティティを保存する。

STFは「ロケタッチ」でも写真の格納に使われている

STFは「枯れた」技術を利用

グリーのストレージ戦略の基本はMySQL

講演タイトルは「データストレージEXPOで話してきた、感想を交えつつGREEのストレージのはなし」改め「ソーシャルプラットフォーマーとしてのGREEのストレージ戦略」。講演者はグリー株式会社取締役執行役員CTO 開発本部長藤本真樹氏。

「データストレージEXPO」で講演したが、アウェイ感が強くてつらかった
エンタープライズ向けストレージ製品は、私たちが求めているストレージとは考え方が違う。小さく始めたい。自分達で作りたいし障害対応したい。合わせて新鮮さが欲しい。
改めてGREEのストレージ戦略の話を
MySQLは安定している。多くのツール、ノウハウ、実績がある。今後も投資していく。
困ったらSSDとか
分析系は、1PBのZFSストレージを置いて、MySQLを動かしている
というとなぜHadoopにしない、とよく聞かれるが、この中で1PBでHadoopを動かした事がある人は挙手願います！
PBクラスを扱うことを考えると、10万円のマシンを1000台入れてHadoopを使ったとして1億円、安くない。AWSを使っても同様。MySQLはやはり便利
1日数十億のリクエスト。アクセスログだけで1日1TBは下らない。これをAWSで扱うと・・・そこで中で持とうということに
HadoopとMySQL、トレードオフはシビア。今はこういうアプローチでやっている。
尽きることのない欲望、というもの。例えば、ゲームで性能限界による意識的、無意識的なギャップを乗り越えられたらどうなるか。もしすべてのデータを瞬時に検索/集計できたら？ DAU（Daily Active Users）をリアルタイムに計算できたら。
非連続的なアップデートというものある
「テンプレ」といえばGoogleかFacebook
ちょうど丸山先生がFacebookの論文を抄訳してくれた（「FacebookのリアルタイムBig Data処理」）。
Facebookになった気分で思考実験してみる。
FacebookのDAU（Daily Active Users ）8億4500万人。Like27億/日。Photo1日2億5000。Links 1000億。
どういうアプローチをとるか。20億Likeぐらいなら、さばけそうな気がする。ただピークで秒間20万Likeとかがくると、しんどそう。ShardingしてもHotSpotが偏る。ロングテールな形でLikeボタンが押されるので（特定のページなり写真なりにLikeが集中）、分散したけどその中の1個のShadeに偏る、ベストなソリューションはない。
Likeのアーキテクチャは分散と非同期書き込み。高いスループットと柔軟な解析。トラフィックが集中する箇所はこのアプローチか。
FacebookのアーキテクチャはScribe+PTail+Puma+HBase（P*はFacebookオリジナル）
このあたりの近々オープンソースになるのなら、それはありがたい。楽しみにしている。PTail+Pumaに期待。
一方で、日本発のものでシリコンバレーより良いものができたら、楽しいじゃないですか。

Facebookがさばくトラフィックの規模

1日20億Likeはさばけそう、1秒20万Likeはしんどそう

Likeのアーキテクチャ

Javaベースの新分散フレームワークDripcast

講演タイトルは「M2M時代のクラウド型開発モデル- Dripcast - server-less Java programming framework」。講演者はインテック先端技術研究所主席研究員中川郁夫氏。

サーバレスのJavaプログラミングフレームワークについて説明します
サーバを意識しないプログラミングが可能に
想像してみよう。大きな農場に羊がたくさん。Androidをみんなに与える。GPSでロケーションを集め、集約してタブレット端末で表示する。
新たな分散フレームワークDripcastでは、プログラムコードに「おまじない」を1行入れるだけで、分散コードになる。データをクラウドに格納し、クラウド上でメソッドを実行する。
Dripcastクラウドを試せる環境は東京大学、WIDEなど日本国内に6カ所。
国内の大手企業とも組んで実証実験を行う予定。

Dripboxのコンセプト

わずかな追加（赤字の部分）で分散処理を記述

国内6カ所にDripcastクラウドを試せる環境を設置

このDripcastは、まだ登場から6カ月ほどの新しいフレームワークだそうです。「中村正三郎のホットコーナー」に記載がありますね（第１回クラウド勉強会…）。

このDripcastはちょっと気になることがあったので、手を挙げて質問しました。「Javaの分散オブジェクトは今までにも登場していますが、違いはなんでしょうか？」回答としては、「分散オブジェクトのテクニックはいくつか使っている。RPCやコンシステントハッシュなど。大きな違いはスケーラビリティと保存した後の信頼性。分散オブジェクトの多くはインタフェースまでしか定義しないが、こちらはオブジェクトを保存した後まで含めたフレームワークとしている」との回答でした。

DeNA岩永氏、NHN Japan牧氏、グリー藤本氏の講演は、「今提供しているサービスのインフラ」の生々しい話でした。

特に、グリー藤本氏の発表では、「エンタープライズ分野との違い」や、「Facebookに負けたくない」といった（技術者視点での）挑戦的な視点が感じられて、興味深く聞きました。

一方、インテック中川氏の講演は、いわば「近未来の分散環境」を語るものでした。とはいえ、Android端末や、さらにM2M系の世界で、この種の分散フレームワークが使われるようになる可能性は大いにあります。このようなフレームワークが当たり前になった世界では、「できること」の幅が大きく広がるような予感がします。その一方で、現実世界への適用へのハードルもたくさん出てきそうですが。

togetterまとめはこちら。 NHN テクノロジーカンファレンス #nhntech まとめ

参加された方のBlogなど
NHNテクノロジーカンファレンスで見たDeNAのMySQL運用の話とAmazon RDSの比較など。DeNA岩永氏の講演内容を報告しています。

以下は余談。会場はNSビル30階でした。以下はビルの窓からGalaxy Nexusで撮ってみたパノラマ写真です。

都庁側