Reflex works20120818 1

Copyright © Virtual Technology, Inc

ぶいてく流スケーラブルアプリの作り方

2012（前編）

2012/8/18　有限会社バーチャルテクノロジー

1


•  竹嵜伸一郎（たけざきしんいちろう） •  寺田典子（てらだのりこ）

•  （有）バーチャルテクノロジー – 分散KVSのミドルウェア開発(ReflexWorks)

2


Agenda １．なんでスケーラブルにするのか２．どうすればスケーラブルになるか

２−１.アプリの観点２−２.システムの観点

３．ReflexWorksの概要４．スケーラブルアプリの設計５．データの一貫性６．アクセス制御とソーシャル化７．大規模Web帳票システムの事例（LT）

3


１. なんでスケーラブルにするのか

4


パフォーマンスと全体最適化の問題

•  パフォーマンスの問題 – データが増えると遅くなる – アクセスが多くなると遅くなる

•  全体最適化の問題 – VMの全体最適化では不十分

5

Copyright © Virtual Technology, Inc 6

Scale-up vs Scale-Out Scale-Up Scale-Out

性能は、価格に比例性能の高いサーバは、極端に高くなる性能の頭打ち（ムーアの法則）

廉価サーバ


２−１．どうすればスケーラブルにな

るか（アプリの観点）


論点 •  集中 vs 分散 •  密結合 vs 疎結合 •  同期 vs 非同期

•  ステートフル vs ステートレス

– 分散で疎結合で非同期でステートレスなシステム(つまり、メール）が最強。しかし、それだけでは済まないのが世の中。➡ オンラインWebアプリ

– スケールアウト性を損なわずに、どこをどう妥協していくか

8


集中 vs 分散

•  集中化で運用管理は楽になるが・・ – RDBに負荷が集中することでパフォーマンス劣化 – MemcachedではRDBとの整合性確保が困難になる – 障害になるとシステム全体に影響を及ぼす

•  分散化でスケーラブルになるが・・ – 運用管理が複雑になる – 厳密なデータの一貫性の確保が困難

9

一貫性確保などの課題を克服して分散化でいくことができるか（これが命題）


密結合 vs 疎結合

•  密結合で高速な動作が可能になるが・・ – 分散化（スケールアウト）しにくい – 例） JSP(APに負荷）とHTML+JS(Webに負荷）

•  疎結合で分散化しやすくなるが・・ – 高速処理に向かないケースがある。 – 個々のコンポーネントの独立性が高く相互依存性

が低い。また分散化しやすい。

10

可能な限り疎結合とする（異論はないはず）　ブラウザ、サービス、DBの間は少なくとも


同期 vs 非同期

•  同期だと処理（トランザクションや実行順序）が保証されるが・・ – 他の処理をブロックさせてしまう – １つのリソースに処理が集中するとスケールしない

•  非同期だとスケールするが・・ – データの一貫性は確保できない – 遅延が発生する

11

一貫性は重要であり、同期処理をやらざるを得ないケースがある。トランザクション処理など


ステートフル vs ステートレス •  ステートフルだと高速になるが・・

– メモリ、DBなどを介すためスケールさせにくい – セッションオブジェクトに中間データを保存すること

で処理（再送、再計算など）を省略できる •  ステートレスだとスケールするが・・

– 必要な情報を毎回送信する必要があり冗長になる。 – 認証、データチェックなどは都度実行となり、パ

フォーマンスは悪くなる

12

ステートフルにせざるを得ないケースがある Webアプリの認証、WebSocket、・・


２−２．どうすればスケーラブルになるか（システムの観点）


これまでの３階層システム

WEB AP DB

トランザクションはDBMSの機能で実現

14


WEB AP DB

AP

AP

DBがボトルネックとなりスケールしない WEB

WEB

単にWEBやAPを増やしてもスケールしない

DBとボトルネック

15


WEB AP DB

AP

AP

Cache WEB

WEB

WEB

読込性能は上がるが・・整合性はどうする？

分散キャッシュ

16


H/W

OS OS

AP

H/W

OS OS

DB（KVS）

AP AP

PaaS（パブリッククラウド）の例

AppEngine Datastore AWS Dynamo

DBにKVSを採用、AP,DBともにオートスケール、規模の経済性


プライベートクラウドの課題

18

H/W

OS OS

DB DB

AP AP

H/W

OS OS

DB DB

AP AP

VMで全体最適化が図れるもスケーラビリティに課題かといって、PaaSのような大規模なDB構築は容易ではない

スケールしない


H/W

OS OS OS

DB DB DB

AP

OS

DB

H/W

（解決案）AP統合、一方でシャーディング

Consistent Hashing シャーディング

APは論理的には１つだが実際はそれぞれの担当ノードに別れる

#1 #2 #3 #4

（困難は分割せよ by デカルト）


シャーディングの考え方

•  お互いに干渉しないような分割キーを見つける –  ユーザIDなど

•  SalesForceのマルチテナントアーキテクチャー –  テナント別の「組織ID」で物理分割

•  http://www.publickey1.jp/blog/09/2id.html

–  ユーザー企業が増えた場合でも、データが増えた場合でも、パーティションを増やし、そのパーティションを処理するインスタンスを追加することでスケーラブルな対応をする

20


１、２章のまとめ •  集中 vs 分散 •  密結合 vs 疎結合 •  同期 vs 非同期

•  ステートフル vs ステートレス

– 分散で疎結合とすべきなのは異論がないところ。 – さらに非同期でステートレスにできればよいがそれ

だけで済まない現実がある。 – APをシャーディングで分割する案

21

Documents

Reflex works20120818 1