BPStudy20121221

300万トランザクション/日を処理する
スケールアウト型
Web帳票システムの仕組みについて

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

1
Copyright © Virtual Technology, Inc

•  竹嵜伸一郎（たけざきしんいちろう）

•  （有）バーチャルテクノロジー
–  分散KVSのミドルウェア開発(ReflexWorks)
•  1992-2003
–  日本IBM ソフトウェア事業部
•  2007-2009
–  （株）暮らしのデザイン CTO

2

Agenda

１．Web帳票システムの概要
２．分散KVSについて
３．Thin Server Architecture
４．スケーラビリティ
５．トランザクション処理
６．パフォーマンス
７．可用性
　　まとめ

3

1. Web帳票システムの概要

4

背景

インストール型帳票アプリをWeb化するにあたって・・
　　　　　　　　　　　　　　　　　　
•  ユーザビリティ、パフォーマンス
–  クライアントアプリに比べ遜色のないUI/UX
–  ボタンを押して数秒以内に印刷開始、高速な印刷実行
–  バーコード(EAN128など)やQRコードといった高品位な帳票印刷

•  モダンブラウザ対応
–  昔はWindows+IEで十分だったが、最近ではMacでもという要望が増加
–  Chrome、Firefox、Safariといったモダンブラウザにも対応させたい

•  急激なアクセス数の増大に柔軟に対応
–  スタート時は最小のリソースで開始したいが実際にどれくらいのアクセス
が来るかわからない。（数十万ユーザの同時利用に耐えられるか）
–  将来的なアクセス増大に単純なリソース追加により対応したい。

5

Web帳票システムのこれまでのソリューション

2005年頃ブームになったリッチクライアントでは・・
　　　　　　　　　　　　　　　　　　
•  ActiveXコンポーネント
–  ダイレクト印刷コンポーネント
–  IE6問題の諸悪の根源

結論：
•  独自ブラウザインターネット利用
–  インストール型と実質変わらない。
に向かない
–  ○○Browser、curl、Adobe AIR

•  サーバサイドでPDF生成
–  サーバ負荷が大きい
–  スケールしない

6

企業内業務システムで今大変な問題が起きている
Ac>veXへの強依存があってIE6をやめられない

IE6
やめようと思ってももう手遅れ

h0p://www.slideshare.net/bath>meﬁsh/ie6-‐15583209
7

ReﬂexWorks
Web帳票システム

8

３つのポイント

　　UI/UX、パフォーマンス、スケーラビリティの３つを同時に解決
•  Thin Server Architecture
–  APサーバはデータを返すだけ(JSON/XML)
–  Webサーバは静的コンテンツを返すだけ(HTML,CSS,JavaScript等）
Flash利用の異論
–  クライアントによるレンダリングで７０％負荷軽減
ActiveXと同じ問題？
HTML5は？
➡ 現実解
•  Flash印刷コンポーネント
–  クライアントリソースの活用でサーバ側への負荷は最小限
–  バーコード、QRコードなどをクライアント側で高速に印刷
–  Active Xを使用していないため様々なOSやブラウザで動作する
•  Flash導入率は世界で99%以上。スマホなどを除くとほぼすべてのブラウザに対応

•  分散KVS
–  顧客数を最大に見積もらなくてもスモールスタートが可能
–  急激なアクセス増大にも単純なノードを追加で対応可能
9

2. 分散KVSについて

10

なぜ分散KVSを採用したのか
•  キャッシュとして利用
–  読込/書込性能向上
–  RDBのボトルネックを解消、スケールアウトできる
•  O/Rマッパーが不要になる
–  KVSに直接オブジェクトを保存可能
–  工数削減、開発の４割がマッピングに費やされている
–  RDBを実質的に廃止できる RDBのインスタンス

•  管理コストが低いを増やすと管理が大変

–  導入設定が不要、スキーマの生成が不要
–  単純なログファイル、管理が非常に楽
11

KVSで業務アプリを作るのは大変

•  検索（複合条件、OR検索）

•  ソート

•  JOIN

•  カウント
INDEX爆発が
起りがち

12

分散KVSを業務アプリで使うには
業務アプリにKVSであることを意識させないことが大事
h0p://blog.virtual-‐tech.net/2012/07/kvs.html
•  ユーザビリティ
–  ドキュメント指向でRESTによる操作を基本とする
•  トランザクション処理
–  業務アプリを作るうえで必須（後述）
•  RangeScan、セカンダリIndex
–  キー以外の項目でも高速に検索できないと全走査
となって使い物にならない

•  1.5次元レベル、GAE
DatastoreなどはINDEXがある
13

NoSQLのデータモデル
業務アプリで使うにはドキュメント指向じゃないと辛い

Dynamo

Cassandra

MongoDB

ReﬂexWorks

14

紙（≠ドキュメント）指向
•  コンピュータがない時代、全部紙だったじゃないか。

受付

15

ReflexWorks
エンタープライズ向けアプリケーションを容易に構築できる
トランザクショナルKVS
•  2010年10月開始、商用、Javaで記述

•  ドキュメント指向、JSON、XML、MessagePackに対応

•  ORM(Object-‐Rela>onal
Mapping)不要

–  En>tyオブジェクトをシリアライズ保存

–  ソフトスキーマ（スキーマレスではないが）

•  RDBからデータ復元（可用性向上）

•  シャーディング水平スケーリング（パフォーマンス向上）

–  ConsistentHashアルゴリズム採用

•  オンラインでACIDトランザクション処理が可能

•  認証・アクセス管理機能

•  データ保存効率は悪い（圧縮はしない）

16

3. Thin Server Architecture
(RESTで疎結合)

17

Thin Server Architecture
クライアントからRESTでサーバリソースにアクセス

サーバからはJSONやXMLのデータを返すのみ

BaaSのような感じ

REST

データ
・・・

18

ReflexWorksにおけるデータ管理

19

直感的なRESTAPIによる操作
•  リソースURLは自由に設定、追加できる。

•  マッピングルールなどを書く必要がない

→
設定ファイル地獄、アノテーション地獄からの解放

•  リソースを様々なフォーマットに変換できる。

•  単純なプロパティとListをもつPOJOで階層構造を表現

→
JSON
,
XML
,
msgpackなどに変換可能

•  リソースに対してCRUD操作可能

20

フォルダとエントリの階層表現
•  フォルダ配下の取得とエントリの取得
–  GET /{フォルダ}
•  {フォルダ}の集合(ATOM Feed)を取得
–  GET /{フォルダ}/{エントリ}?entry
•  {フォルダ}の集合の1エントリ (ATOM Entry)を取得

•  実はフォルダとエントリの区別はない
–  エントリはフォルダの性質をあわせもつ
–  GET /{フォルダ}/{エントリ}
•  {フォルダ}/{エントリ}の集合を取得
–  GET /{フォルダ}/{エントリ}/{エントリ2}?entry
•  {フォルダ}/{エントリ}の集合の1エントリを取得

21

検索条件など
GET /d/{selfid}?{name}{=|.eq.|.lt.|.le.|.gt.|.ge.|.ne.}{value}&{name}{=|.eq.|.lt.|.le.|.gt.|.ge.|.ne.}{value}&...&l={n}
• 　パラメータに「プロパティ名=値」の形で複数指定可能
• 　等しい条件以外の条件（以上、未満など）を指定する場合、=の代わりに以下を指定する。
　.eq. : = (等しい)
　.lt. : < (未満)
　.le. : <= (以下)
　.gt. : > (より大きい)
　.ge. : >= (以上)
　.ne. : != (等しくない)
•  name=valueの形式での条件指定について、値の最後に“*”を指定することで前方一致検索ができる。
　また、前後に指定することであいまい検索ができる。
• 　&countを付けることで件数を取得できる。
• 　パラメータにlを指定することで、取得件数の上限を指定できる。
• 　検索結果が取得件数の上限に達した場合、link rel=“next”タグにcursor文字列が返されるので、次の検索においてパラメー
タpを使ってcursor文字列を渡す。

例）上限を３件として検索。検索結果が３件以上ある場合、cursor文字列が含まれて返される。
http://tagging-service.appspot.com/d/cloudec/Men/Tops?xml&l=3

次のページを表示するにはpにcursor文字列を指定する
http://tagging-service.appspot.com/d/cloudec/Men/Tops?xml&l=3&p=E9oBxxxx

予約語(以下の名称はtagging service内で使用しているためproperty名には使用できません）
　callback
　login
　logout
　related
　title (entryのtitleを定義済)
　allocids
その他の制約
　プロパティは２文字以上の名称をつけてください。　先頭に_（アンダースコア）をつけた名称は、内部処理で使用しているため、プロパティの名前に使用できません。
　パラメータのつなぎに.（ドット）を使用しているため、プロパティの名前に使用できません。

22

XMLとJSONが扱える
XML
<feed>
<entry>
•  ATOM
Feed/Entryを拡張しユーザ定義の項目を追加する

•  XMLとJSONの互換性を考えて通常は名前空間は省略
<transaction>
<total>100</total>
</transaction>
<item_list>
<item>
<description>商品1</description>
<unit_price>100</unit_price>
</item>
</item_list>
<content>テスト</content>
</entry>
</feed>

JSON
{"feed"
:
{"entry"
:
[{"transac>on"
:
{"total"
:
"100"},

"item_list"
:
{"item"
:
[{"descrip>on"
:
"商品1","unit_price"
:
"100"}]},

"content"
:
{"_______text"
:
"テスト"}}]}}

23

WebSocketによるイベント通知機能
•  WebSocketのコネクション確立時に認証する
•  接続情報をセッションで管理
•  フォルダ共有（R権限）でかつログイン中のユーザに通知

Reactive!

h0p://reﬂexworks.jp/features.html#pushNo>ﬁca>ons

24

疎結合だから並行開発できる
内部設計～単体テストフェーズにおいて並行開発ができる

・ユースケース図、ユースケース記述
・分析クラス図、論理ビュー要件定義
・画面モックアップ外部設計
・エンティティ設計、テーブル設計、インスタンス作成

・画面実装・Resorceモデル設計・DAOモデル設計
内部設計
・単体テスト
・フローアセンブル・O/Rマッピング実装
・単体テスト
・単体テスト

・統合テストテスト
・システムテスト

リリース
25

4. スケーラビリティ

26

基本的なスタンス
効率よくスケールすれば雲の中身はどうでもいい
BaaSのような感じ

WEB
AP
REST
セッションオブジェクト

DB
WEB
AP

・・・
WEB
AP

27

以下の技術とは区別する
枯れた技術だけを採用し以下は使わない方針
•  並列・並行プログラミング
–  メニーコアで最大能力を引き出す
•  http://modegramming.blogspot.jp/2012/12/scala3.html
–  Concurrent Revisions
•  http://research.preferred.jp/2011/10/modern-parallel-
concurrent-programming/
•  リアルタイム処理
–  ストリームデータ処理
•  STM(Software Transactional Memory)
28

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

•  パフォーマンスの問題
これらの問題は実は

–  データが増えると遅くなるモダンプログラミング

じゃなくても解決できる
–  アクセスが多くなると遅くなる
ユーザ100万人が同時に使える？
実は他に改善すべき
•  全体最適化の問題ことがいっぱいある
–  VMの全体最適化では不十分

29

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

はDBMSの機能で実現

WEB
AP
DB

30

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

DBがボトルネックとなり

WEB
AP
スケールしない

WEB
AP
DB

WEB
AP

31

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

DBとの整合性はどうする？

WEB
AP

WEB
AP
Cache
DB

WEB
AP

32

案：スケーラブルなDBを使う

APをステートレスにしてAutoScaleできれば概ね解決

WEB
AP

DynamoDB

WEB
AP
　　　とか

WEB
AP

33

しかし、本当にスケールするか？

なぜFacebook
Messages
でCassandraではなく
Hbaseが採用されたの
か？

h0p://www.slideshare.net/okuyamaoo/okuyama-‐20120119-‐ss
34

本当にスケールするか？

35

本当にスケールするか？

2.4系から仮想メモリを廃止

つまり、メモリサイズを超えるデータの扱いが困難

ACIDのDをどうするか？
DB
AP

×
h0p://redis.io/topics/virtual-‐memory

36

分割すりゃいいじゃん

困難は分割せよ

By
ルネ・デカルト

37

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

廉価サーバ

38

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

AP
AP
AP
AppEngine
Datastore

DB（KVS）
AWS
Dynamo

OS
OS
OS
OS

H/W
H/W

39

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

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

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

OS
OS
OS
OS

H/W
H/W

40

シャーディング分割案
APは論理的には１つだが実際はそれぞれの担当ノードに分かれる

#1
#2
AP
#3
#4
Consistent
Hashing

シャーディング
DB
DB
DB
DB

OS
OS
OS
OS

H/W
H/W

41

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

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

42

Berkeley DB Java Edition
通常はキャッシュで処理、永続化も備える

43

ScalabilityとConsistencyを両立
ノードは一定数のユーザを担当
同期でステートフルでもOK
実質APだけで動作（RDBも疎結合）
ノード追加で処理性能向上

疎結合
疎結合

スケーラブル！！

シャーディングでも敗北感を感じる必要はない

44

シャーディングで問題になるケース

•  情報共有
–  ある情報を複数のユーザが更新する

•  リカバリー
–  障害ノードを復旧させるのがちょっと大変

45

5. トランザクション処理

46

一貫性
•  一貫性(Consistency)
これ重要
•  可用性(Availability)

•  分割耐性(ParAAon
Tolerance)

•  しかし、Consistencyはとても重要

47

CAP定理とプロダクト

Hadoopは、
Availabilityを犠牲
Cassandraは、
Consistencyを犠牲

（C）Nathan
Hurst's
Blog

48

在庫とシステムの一貫性の問題
•  本を買う例でいうなら、本はカートに入れられるか、
入れるのに失敗するかでなければいけない。ある
いは買うか、買わないか。

A

在庫 0 点

在庫残り１点 !!
B

49

ReflexWorksのトランザクション処理
データの一貫性を確保しつつ高いスループットを実現

•  Feed単位のAtomicトランザクション
–  分離レベル：REPEATABLE READ
•  かつ、Entry単位のバージョン比較
–  分離レベル：SNAPSHOT ISOLATION
–  全てのEntryはURLとリビジョンで管理される
–  リビジョン＝更新されると＋１される
詳細：
h0ps://www.facebook.com/notes/virtual-‐technology/

bdbトランザクションとreﬂexworksの処理について/486790368009209

50

Feed単位の１UOW(Unit
of
Work)

＜atomicity（原子性）、isolation(分離性)＞
・　entryはトランザクションの最小単位（RDBにおける１レコードに相当）
・　aliasの追加・削除はentry内でatomicでありisolationが保たれる
（例えばフォルダ移動で２重に見えたりはしない）

＜consistency(一貫性)＞
・　feedのPOST/PUTは１UOWで実行され一貫性は保たれる
　（どれか一つのEntryが失敗するとロールバックされる）
ATOM Feed

<feed>
<entry> sｅｌｆ
<link rel=“self" href=”/folder0/document1">
<link rel="alternate" href="/folder1/document1"> aｌｉａｓ
・・・
</entry> transaction scope
<entry>
・・・
</entry>
　・・・
</feed>

51

「受注と明細」を1つの更新処理に束ねる
•  RDBだと２テーブルに跨ぐはず
–  トランザクションで括るなど必要
•  これを１リクエストで実行する
–  1Feed内に本体と明細のentryを入
れるだけで１トランザクションとして
実行可能

POST/PUT/DELETE
<feed>

<entry>

<id>受注のid
</id>

<entry>

<entry>

<id>明細のid</id>

<entry>

</feed>

52

6. パフォーマンス

53

BDBのパフォーマンス
•  Total 100,000 requests、 100回繰り返し
•  writeとdeleteの処理を実行、Value sizeは 1024 bytes
•  Server1台(2CP,2.66GHz,3.3GB)、Client4台

• 

メモリ内で実行
実際にBDBに書き込む

30000クライアントまで
30000クライアントまで

10000〜12000
(trans/sec)
4500〜8500
(trans/sec)

メモリに比べ

出典：Voldemort
性能は約半分
54

ReflexWorksのパフォーマンス
•  50万リクエスト/時で平均レスポンス 100~150ms
–  Read 90%,Write 10%
–  1ノードの性能
ReflexWorks 1ノード
12000

10000

8000
ms

6000
1ノードの処理性能
4000

2000
限界値

0
これをこえるとFullGC頻発

55

本当のボトルネックはどこか
コンテンツ関係だけで相当な改善効果があった
サーバサイド
はJSON返すのみ
•  動的コンテンツの廃止
–  クライアントによるレンダリングで70%負荷削減
–  帳票作成の負荷削減効果は計り知れない
•  静的コンテンツのWebサーバへの移動
– 10%~20%の負荷削減(ロードアベレージ）

56

本当のボトルネックはどこか
シリアライズ30%、永続化40%、その他30%
•  シリアライズ/デシリアライズ KVSがボトルネック
になる部分は実は
–  オブジェクトóJSON/XML変換のコストあまりない
•  永続化
–  オブジェクトをBDBなどのDatastoreに保存するコスト
•  その他プログラミングモデル変更で
果たして改善できるか？
–  ビジネスロジック処理
•  マスター参照を伴うデータチェックなど重いものは全体の
90%以上を占める

57

Publicクラウドはレイテンシーが課題
Flash印刷パフォーマンステスト
(Azure)
Windows
Azure
@singapore
・　データ１０００件分格納後、取り出しを行う

3300Bytes
　　　上り：４１秒/１０００件、下り：１８秒/１０００件

Table
Storage
/１レコード

1000レコード
444レコード*2
・　Flash側でダイレクト印刷する

WebRole(C#)

　　　１２５秒/３０００ページ

AMF
Messaging
Gateway

　　　（印刷開始は１P目がスプールされた時点）
AMF3

125秒/3000ページ

(※印刷は１P目がスプールに出されると直ぐに開始される）
100MBPS

AWSも当時は東京リージョンがなく

同様だった
Windows7
/
Corei7　/
Flash10

58

7．可用性

59

どうせ世界が滅亡するんだから
どうでもいい話です・・可用性

マヤ暦が２０１２/１２/２１

までしかないんだから、

それ以降は知りません。

60

障害発生時の切替処理

61

実際のところ故障率は？
数ノードであれば故障はほとんどない
•  エンタープライズシステムは故障率が低い
•  HWが故障しても動き続ける
•  SWの理由で停止しても年間1ノードが数十分程
度ぐらい。
•  RDBにきちんと格納さえできていれば大丈夫
–  RDBの代わりにHBaseはアリかも
•  KVSの冗長化は無駄
–  ３台に同じデータを書き込むなんて・・・
62

信頼性と安心感
実績、保守サポート体制が重要
•  BDBはOracleの保守サポートを受けられる
–  他のOSSなどと比較すると安心感はある

63

まとめ
•  分散KVSでスケールアウトを実現
–  実質RDBいらない、過度な冗長機能はいらない
–  トランザクション大事
•  Thin Server Architecture
–  疎結合、REST、ユーザビリティ
–  本当のボトルネックをなんとかすべき

64

ReflexWorksは進化していきます
OLTP+OLAPの組み合わせが標準になると予想（やはりRDBいらない）　
　　　　　　　雲(OLTP)の中身はモダンプログラミング?

OLTP
REST

MessagePack
並列・並行プログラミング
OLAP
Monad

ロックフリー、　　　　
Impala?
・・・
Concurrent
Revisions
Fluentd

STM

ご清聴ありがとう
ございました

65

BPStudy20121221

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à BPStudy20121221

Similaire à BPStudy20121221 (20)

Plus de Shinichiro Takezaki

Plus de Shinichiro Takezaki (15)

BPStudy20121221