« August 2009 | Main | October 2009 »

September 2009

September 28, 2009

パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)

先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。

1. Happy Optimization

最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。

2. Scaling?

次に、スケールアウトとスケールアップについて、技術の進化と要件の変化の両面から、自分がどう捉えているかを話しました。

3. Incline & Pacific - なぜ作るのか

現在開発している Incline と Pacific という、RDB Sharding のためのふたつのツールについて、開発している理由を説明しました。

4. A Clever Way to Scale-out a Web Application

Incline と Pacific の実装および実際の使い方について、デモを交えて説明しました。デモは途中で終わっちゃいましたが。

5. A Better Cached

そして最後に、MySQL に memcached プロトコル対応機能を追加する Mycached について説明し、また、何が Memcached の問題だと思っているか、について話しました。

話を終わって

一番うれしかったのは、多数の質問をいただけたことです。説明の足りない点を補えるのはもちろん、自分と違う視点から見て、Incline と Pacific にどのような問題/限界があるのか、改めて考えるいい機会になりました。聞きにきてくださった皆さん、運営の方々にも、改めて御礼申し上げたいと思います。

なお、紹介した各ソフトウェアのソースコードについては、以下の URL にあります。それぞれ成熟度に差がありますが、ダウンロードしてお試しいただければと思います。

September 22, 2009

「サーバ書くなら epoll 使うべき」は、今でも正しいのか

 多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか? echoサーバを書いて、ベンチマークを取ってみることにしました。

 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。

  • epoll も per-thread モデルも、良くスケールする
  • epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速

 少なくとも、1コネクション1スレッド、という選択肢が現実的であることは確かのようです(特にポータビィリティでイベント駆動モデルよりも優れていることを考えると注1)。また、今日ではマルチプロセッサ対応は必須ですから、マルチスレッド(マルチプロセス)+イベント駆動の二階建てにするよりも、1コネクション1スレッドのモデルの方が、必然的に単純になります。

 一方で、ロックの競合が問題になる場合や、最後の一滴までサーバのリソースを搾り取りたい場合は、まだイベント駆動でがんばるべきなのかもしれません注2

注1: イベント駆動モデルでは、ファイルシステムへのアクセス等も非同期 /Oを使用して書く必要があります
注2: mycached は、このケース

参考: 軽量スレッドブームだと思うので、そこらへんの情報をまとめてみる, Thousands of Threads and Blocking I/O, Completely Fair Scheduler によるマルチプロセッシング

September 11, 2009

A Clever way to scale-out a web application (YAPC::Asia 2009 Presentation)

For couple of months I have been writing middlewares for database shards, and today I made a presentation covering them.  It includes the following.

  • Incline - a trigger and queue based distributed materialized view manager
  • Pacific - a set of perl scripts to manage MySQL shards, a MySQL shard can be split into two in less than 10 seconds of write blocking (and no read blocks)
  • DBIx::ShardManager - a client API for accessing database shards using Incline and Pacific

With these middlewares I think it is no more difficult to write web applications that runs on database shards.  In fact IMHO it is as easy as writing a webapp that runs on a standalone database.

The presentation slides are available from slideshare.  If you have any question or suggestions, please leave a comment.  Thank you.

Writing Hot-deployable servers (introduction of Server::Starter)

Yesterday at YAPC::Asia 2009, I did a LT introducing verious techniques to write hot-deployable servers, and introduced a perl module called Server::Starter that encapsulates the burden of developing support for hot-deployment within each TCP server program. The presentation slides are on Slideshare.