**クラウド時代の Web ストレージ/データベース戦略(池邊さん)
クラウドのメリットとはなにか。利用者からは、クラウドの特徴は物理的なサーバ・ネットワークを意識しないで済む。自分達でやるよりも高可用性が得られ、柔軟な課金体系もある。提供者からは、高価な機器に依存せず、スケールアウトのメリットが得られる。
Livedoor の Web ポータルとしては、物理サーバリソースは投資済。Livedoor の提供サービスは Saas であり、さらにコスト効率を上げたい。クラウド的なサービスを提供するというよりは、(I|P)aaS 的なクラウド環境を自分達で作って自分達で使うという形が今からである。
Livedoor が求めるストレージはそんなに高機能ではない。サービスとして画像系を扱うことが多いため、Web サービスのメディア(画像・動画)を配信できるようなストレージが欲しい。 -安い -容量無限 -冗長性 -高可用性 本来クラウドにおいては、利用者に対するストレージの見せ方はブラックボックスであるべき。ただ Livedoor では自分達でつくって自分達で使うので、ちょっとだけ意識した方が良いかもしれない。
***STF (Storage Farm) 蝶野選手の技名。
HTTP を利用した分散ストレージ。MogileFS、Amazon S3 等を参考にしている。 階層構造はストレージのレイヤでは必要ない。そのため、シンプルな key-value ストアを利用し、クライアントには巨大なストレージプールとして見せる。普通のサーバを使用して拡張可能。Apache モジュールを利用。ただし、ファイルシステムとしてマウントはできない。パーミッション・アクセス制御もできないが、自分たちで使うだけなので細かくても良いかなと割り切っている。
デザインとしては、ファイル群を束ねる Bucket の概念を使用。リソースに対してリクエスト(GET/PUT/DELETE)を発行してデータをアクセス・操作する。レプリカの作成数はヘッダで(自分達)で指定する。サムネイルはなくなったところでオリジナルさえあれば良いし、そういった形でレプリカ数の調整が可能になっている。
アクセスするパスは以下のような形式。
-http://stf.example.com/
***基本戦略 バグを入れたくないので、コードを書きたくない。オープンソースの方が非常に安定している。 作りながらサービスに投入しているので、httpd とかを作り出すと結構大変で、それを投入するのには非常に勇気がいる。そのため、枯れたコードを使用したいという思いがあった。
Apache モジュールを C で実装し、URI => 物理ロケーションのマッピングは MySQL で保存。MessageQueue を利用した非同期処理を実施している。コンパイルとかが面倒なので Perl で実装している。 ***構成 マッピング情報は MySQL と memcached。ディスパッチャーノードで、マッピング情報がどのストレージにあるかを決定している。 テーブルとしては以下の 4 つがある。 -storage -bucket -object URI <=> オブジェクト ID -entity オブジェクト ID <=> ファイル実体 MySQL としてはデュアルマスタが使えるように実装している。
mod_stf.c はリクエストディスパッチャ。MySQL・MessageQueue と通信。 mod_stf_storage.c については、GET は default-handler 任せ。PUT は Recursive にディレクトリを生成。同一ファイルでの上書きはできない。更新は一回消して内部的には別ファイルとしている。
Delete は、最初は MySQL でマッピングを消しているのみ。ファイル実体は MessageQueue 経由で非同期に消去している。
**Web I/F ストレージ管理用の Web I/F。Catalyst 使用。 サーバをセットアップして Web I/F からストレージを追加できる。その他、利用状況の確認や、ストレージのモード切り替えもできる。
***TODO -key-value なのに RDB なのはオーバスペックなので、MySQL から脱却したい -特定ノードの使用(最新・人気のものだけ SSD 対応させる) -オープンソースでの公開
**ライブドア流クラウド的サービス(田畑さん、市川さん)
Livedoor でもクラウドサービスをやろうという話がでてきた。Livedoor の強みを出した、Livedoor の色を出したサービスにしたい。できれば安価にしたい。 Livedoor はどういう風に見えているかを考えると、Web サービスに強いという気がする。DATAHOTEL というデータセンタを運用している関係で、回線・ラック等も自由にやりたいことができる。そのあたりを上手く使って、Livedoor 風サービスを考えている。 クラウドの利点は動的なリソースの増減がある。一方、フルマネージドホスティングの利点は、サーバの完全な管理とサーバリソースの占有が可能になること。
これらを総合的に考えると、 -Webサービスのクラウド化 サービス規模に応じて、短期間でリソースの増減を可能にする -バックエンドは専用サーバ化 リソースが必要な DB、セッション管理、ストレージサーバは占有サーバとする
***思考錯誤
VMWare は性能、安定性、機能は申し分ないが、ライセンスが高い。DRS、ライブマイグレーションを使うにはバックエンドに信頼性の高いストレージが必要で予算的に見送り。KVM は管理ツールが弱く、専用プログラムを導入する必要があったり手間がかかる。 Parallels 製品はレンタルサーバサービスで利用中であり、運用ノウハウの蓄積もあるので、今回は Parallels 製品を使って、Livedoor 流クラウド的サービスを実現することにした。
***技術編
検証したのは Parallels Server 4 Beta Metal。OS バーチャライゼーションの検証をしている。ハイパーバイザ型の方も検証しているが、ネットワーク構成を変更すると再起動が必要になり、今回の使用用途には不適切であると考えている。
ネットワークは タグ付き VLAN を使用している。スケールアップは、1 サーバに複数インスタンスパワーを持たせておき、要望に応じていくつのインスタンスを使うかを変更する。既に複数インスタンスが立っているサーバで、そのうちの特定インスタンスを大きくしたい場合は、別サーバへとマイグレーションする。
顧客に管理用コントロールパネルを渡して、インスタンスが必要だったら追加、必要なくなったら削除できるようにする。それだけでなく、マイグレーションや冗長構成管理もこのパネルから実行したい(顧客側から扱えるようにしたい)と思っている。これらによって、スケールアップ、スケールアウトをユーザの簡単な操作で即時に行える。 -急激なトラフィック増加があるサービスへの対応 -スモールスタートの規模を最小に留めて個人開発者を支援する -人的リソース温存
**Livedoor Reader のクローラと Streaming API などの話 (ma.la さん)
Streaming API は更新情報をリアルタイムに取得できる API。今後の新機能、新サービスの基盤として利用していくことを考えている。 外部ドメインでも普通に動く。JavaScript を書くだけで、フィード情報を受信できる。
リアルタイムといっても、Reader がクロールしたタイミングである。ただし、PubSubHubbub 対応サービスについては、まさにリアルタイムとなる。
***サーバサイド
LDR のバックエンドは
-Apache -MySQL -Q4M -Tokyo Tyrant -InnoDB Plugin -Nginx (Stream API のフロントエンドとして利用。long-poll コネクション可) -PSGI/Plack -Coro (DoS ツール用。負荷試験用)
データサイズは圧縮状態(テキストのみ)で 1TB 。過去記事削除はしばらくやっていない。 クロール対象は 180 万フィード。MySQL + Q4M で分散処理を行っている。 クローラは 4 つのプロセスに分類して、別の優先度で実行している。 -Broker cron で 1 分おきに起動する。多重起動防止用にロック。クロール対象をキューへ -Fetcher HTTP を投げる。一番処理時間が予想できない部分。 -Parser そのまま。XML::LibXML + XML::Liberal + 独自の Feed 解析処理。 巨大フィードを馬鹿正直に解析するのではなく、1000 件で切るとかを行うために拡張可能なように Parser を書いている。 -Updater 解析 Feed を DB に保存ずみの記事かどうかを判断し、データベースにかきこむ。 判別はフィードごとに既出フラグを保存していて、Tokyo Tyrant 側でこの情報を持っている。記事ごとに空白を trim したハッシュ値を保存している。
スピードはやすぎてメモとるの諦めた。
**ニフティクラウドの紹介と今後の展望
***サービス概要
IaaS がニフティクラウドが抑えているところ。ユーザに対するメリットは様々なレイヤに及ぶ。ムダの排除はもちろん、インフラ運用からの解放やリソースの動的な配分など。 ニフティでは数万台規模の拡張性を考慮して基盤を構築済。@nifty の WEB サービスの 95 % が既にクラウド上にある。
クラウドプラットフォーム提供希望になるための 7 つの条件(@IT) にほぼ当てはまっているのがニフティである。 約 5 分くらいでサーバの準備が完了。顧客側にコントロールパネルを提供しており、顧客側でそれらの操作ができる。従量課金で 2 つのプランを用意している。
サーバ OS は CentOS 5.x (32bit, 64bit) に対応しており、RHEL 5.x、WindowsServer 2008 R2 も準備中。 監視サービス(自動監視)、プレイアムサポートも開始予定。社外からクラウド上への VPN 接続も現状の仕組みで対応できる。
