Reflex works20120818 1

ぶいてく流
スケーラブルアプリの作り方
2012（前編）

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

1
Copyright © Virtual Technology, Inc

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

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

2

Agenda

１．なんでスケーラブルにするのか
２．どうすればスケーラブルになるか
２−１.アプリの観点
２−２.システムの観点
３．ReflexWorksの概要
４．スケーラブルアプリの設計
５．データの一貫性
６．アクセス制御とソーシャル化
７．大規模Web帳票システムの事例（LT）

3

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

4

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

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

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

5

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

廉価サーバ

6

２−１．どうすればスケーラブルにな
るか（アプリの観点）

7

論点
•  集中 vs 分散
•  密結合 vs 疎結合
•  同期 vs 非同期
•  ステートフル vs ステートレス

–  分散で疎結合で非同期でステートレスなシステム
(つまり、メール）が最強。しかし、それだけでは済
まないのが世の中。➡ オンラインWebアプリ
–  スケールアウト性を損なわずに、どこをどう妥協し
ていくか
8

集中 vs 分散
•  集中化で運用管理は楽になるが・・
–  RDBに負荷が集中することでパフォーマンス劣化
–  MemcachedではRDBとの整合性確保が困難になる
–  障害になるとシステム全体に影響を及ぼす
•  分散化でスケーラブルになるが・・
–  運用管理が複雑になる
–  厳密なデータの一貫性の確保が困難
一貫性確保などの課題を克服して

分散化でいくことができるか（これが命題）

9

密結合 vs 疎結合
•  密結合で高速な動作が可能になるが・・
–  分散化（スケールアウト）しにくい
–  例） JSP(APに負荷）とHTML+JS(Webに負荷）
•  疎結合で分散化しやすくなるが・・
–  高速処理に向かないケースがある。
–  個々のコンポーネントの独立性が高く相互依存性
が低い。また分散化しやすい。

可能な限り疎結合とする（異論はないはず）

　ブラウザ、サービス、DBの間は少なくとも

10

同期 vs 非同期
•  同期だと処理（トランザクションや実行順序）が
保証されるが・・
–  他の処理をブロックさせてしまう
–  １つのリソースに処理が集中するとスケールしない
•  非同期だとスケールするが・・
–  データの一貫性は確保できない
–  遅延が発生する

一貫性は重要であり、同期処理をやらざるを

得ないケースがある。トランザクション処理など
11

ステートフル vs ステートレス
•  ステートフルだと高速になるが・・
–  メモリ、DBなどを介すためスケールさせにくい
–  セッションオブジェクトに中間データを保存すること
で処理（再送、再計算など）を省略できる
•  ステートレスだとスケールするが・・
–  必要な情報を毎回送信する必要があり冗長になる。
–  認証、データチェックなどは都度実行となり、パ
フォーマンスは悪くなる
ステートフルにせざるを得ないケースがある

Webアプリの認証、WebSocket、・・

12

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

13

これまでの３階層システム
トランザクション

はDBMSの機能で実現

WEB
AP
DB

14

DBとボトルネック
単にWEBやAPを増やしてもスケールしない

DBがボトルネックとなり

WEB
AP
スケールしない

WEB
AP
DB

WEB
AP

15

分散キャッシュ
読込性能は上がるが・・

整合性はどうする？

WEB
AP

WEB
AP
Cache
DB

WEB
AP

16

PaaS（パブリッククラウド）の例
DBにKVSを採用、AP,DBともにオートスケール、規模の経済性

AP
AP
AP
AppEngine
Datastore

DB（KVS）
AWS
Dynamo

OS
OS
OS
OS

H/W
H/W

17

プライベートクラウドの課題
VMで全体最適化が図れるもスケーラビリティに課題

かといって、PaaSのような大規模なDB構築は容易ではない

AP
AP
AP
AP
スケールしない
DB
DB
DB
DB

OS
OS
OS
OS

H/W
H/W

18

（解決案）AP統合、一方でシャーディング
APは論理的には１つだが実際はそれぞれの担当ノードに別れる
（困難は分割せよ
by
デカルト）

#1
#2
AP
#3
#4
Consistent
Hashing

シャーディング
DB
DB
DB
DB

OS
OS
OS
OS

H/W
H/W

19

シャーディングの考え方
•  お互いに干渉しないような分割キーを見つける
–  ユーザIDなど
•  SalesForceのマルチテナントアーキテクチャー
–  テナント別の「組織ID」で物理分割
•  http://www.publickey1.jp/blog/09/2id.html

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

20

１、２章のまとめ
•  集中 vs 分散
•  密結合 vs 疎結合
•  同期 vs 非同期
•  ステートフル vs ステートレス

–  分散で疎結合とすべきなのは異論がないところ。
–  さらに非同期でステートレスにできればよいがそれ
だけで済まない現実がある。
–  APをシャーディングで分割する案

21

Reflex works20120818 1

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to Reflex works20120818 1

Similar to Reflex works20120818 1 (20)

More from Shinichiro Takezaki

More from Shinichiro Takezaki (16)

Reflex works20120818 1