Your SlideShare is downloading. ×
0
300万トランザクション/日を処理する      スケールアウト型Web帳票システムの仕組みについて	  2012/12/21 有限会社バーチャルテクノロジー	          1	                    Copyright ...
•  竹嵜伸一郎 (たけざき しんいちろう)•  (有)バーチャルテクノロジー  –  分散KVSのミドルウェア開発(ReflexWorks)•  1992-2003  –  日本IBM ソフトウェア事業部•  2007-2009  –  (株...
Agenda	1.Web帳票システムの概要2.分散KVSについて3.Thin Server Architecture4.スケーラビリティ5.トランザクション処理6.パフォーマンス7.可用性  まとめ                   3	  ...
1. Web帳票システムの概要	     4	        Copyright © Virtual Technology, Inc
背景	  インストール型帳票アプリをWeb化するにあたって・・	                  •  ユーザビリティ、パフォーマンス –  クライアントアプリに比べ遜色のないUI/UX –  ボタンを押して数秒以内に印刷開始、高速な印刷実行...
Web帳票システムのこれまでのソリューション	  2005年頃ブームになったリッチクライアントでは・・	                  •  ActiveXコンポーネント –  ダイレクト印刷コンポーネント –  IE6問題の諸悪の根源  ...
企業内業務システムで今大変な問題が起きている	 Ac>veXへの強依存があってIE6をやめられない	   IE6	  やめようと思ってももう手遅れ	     h0p://www.slideshare.net/bath>mefish/ie6-­‐1...
ReflexWorks	  Web帳票システム	        8	             Copyright © Virtual Technology, Inc
3つのポイント	    UI/UX、パフォーマンス、スケーラビリティの3つを同時に解決	•  Thin Server Architecture  –  APサーバはデータを返すだけ(JSON/XML)  –  Webサーバは静的コンテンツを返す...
2. 分散KVSについて	    10	         Copyright © Virtual Technology, Inc
なぜ分散KVSを採用したのか	•  キャッシュとして利用 –  読込/書込性能向上 –  RDBのボトルネックを解消、スケールアウトできる•  O/Rマッパーが不要になる –  KVSに直接オブジェクトを保存可能 –  工数削減、開発の4割がマ...
KVSで業務アプリを作るのは大変	•  検索(複合条件、OR検索)	  •  ソート	  •  JOIN	  •  カウント	     INDEX爆発が                起りがち		            12	         ...
分散KVSを業務アプリで使うには	業務アプリにKVSであることを意識させないことが大事	                          h0p://blog.virtual-­‐tech.net/2012/07/kvs.html	•  ユー...
NoSQLのデータモデル	業務アプリで使うにはドキュメント指向じゃないと辛い	                                Dynamo	                              Cassandra	    ...
紙(≠ドキュメント)指向	•  コンピュータがない時代、全部紙だったじゃないか。	    受付	           15	         Copyright © Virtual Technology, Inc
ReflexWorks	エンタープライズ向けアプリケーションを容易に構築できるトランザクショナルKVS•  2010年10月開始、商用、Javaで記述	  •  ドキュメント指向、JSON、XML、MessagePackに対応	  •  ORM...
3. Thin Server Architecture      (RESTで疎結合)	         17	            Copyright © Virtual Technology, Inc
Thin Server Architecture	 クライアントからRESTでサーバリソースにアクセス	   サーバからはJSONやXMLのデータを返すのみ	    BaaSのような感じ	        REST	               ...
ReflexWorksにおけるデータ管理	       19	         Copyright © Virtual Technology, Inc
直感的なRESTAPIによる操作	•  リソースURLは自由に設定、追加できる。	       •  マッピングルールなどを書く必要がない	       	  	  	  	  	  	  →	  設定ファイル地獄、アノテーション地獄からの解放...
フォルダとエントリの階層表現	•  フォルダ配下の取得とエントリの取得 –  GET /{フォルダ}   •  {フォルダ}の集合(ATOM Feed)を取得 –  GET /{フォルダ}/{エントリ}?entry   •  {フォルダ}の集合...
検索条件など	GET /d/{selfid}?{name}{=|.eq.|.lt.|.le.|.gt.|.ge.|.ne.}{value}&{name}{=|.eq.|.lt.|.le.|.gt.|.ge.|.ne.}{value}&...&l...
XMLとJSONが扱えるXML	    <feed>	           <entry>	               	                             •  ATOM	  Feed/Entryを拡張しユーザ定義の項...
WebSocketによるイベント通知機能•  WebSocketのコネクション確立時に認証する  	•  接続情報をセッションで管理•  フォルダ共有(R権限)でかつログイン中のユーザに通知                           ...
疎結合だから並行開発できる	内部設計~単体テストフェーズにおいて並行開発ができる	        ・ユースケース図、ユースケース記述           ・分析クラス図、論理ビュー                   要件定義         ...
4. スケーラビリティ	    26	        Copyright © Virtual Technology, Inc
基本的なスタンス	         効率よくスケールすれば雲の中身はどうでもいい	         BaaSのような感じ	                    WEB	          AP	        REST	           ...
以下の技術とは区別する	   枯れた技術だけを採用し以下は使わない方針	•  並列・並行プログラミング  –  メニーコアで最大能力を引き出す     •  http://modegramming.blogspot.jp/2012/12/sca...
要はパフォーマンスと全体最適化の問題	•  パフォーマンスの問題                         これらの問題は実は	   –  データが増えると遅くなる         モダンプログラミング	                 ...
これまでの3階層システム	                        トランザクション	                          はDBMSの機能で実現	WEB	            AP	       DB	        3...
DBとボトルネック	    単にWEBやAPを増やしてもスケールしない	                          DBがボトルネックとなり	  WEB	              AP	   スケールしない	WEB	         ...
分散キャッシュ	             読込性能は上がるが・・	                            DBとの整合性はどうする?	WEB	            AP	WEB	            AP	   Cache	...
案:スケーラブルなDBを使う                    	APをステートレスにしてAutoScaleできれば概ね解決	WEB	              AP	                          セッションオブジェク...
しかし、本当にスケールするか?	                                                               なぜFacebook	  Messages                      ...
本当にスケールするか?	    35	     Copyright © Virtual Technology, Inc
本当にスケールするか?	2.4系から仮想メモリを廃止	  つまり、メモリサイズを超えるデータの扱いが困難	  ACIDのDをどうするか?	                                              DB	    ...
分割すりゃいいじゃん	            困難は分割せよ	                 By	  ルネ・デカルト	   37	             Copyright © Virtual Technology, Inc
Scale-up vs Scale-Out    Scale-Up              Scale-Out性能の高いサーバは、極端に高くなる性能の頭打ち(ムーアの法則)	        性能は、価格に比例	                ...
PaaS(パブリッククラウド)の例	DBにKVSを採用、AP,DBともにオートスケール、規模の経済性	  AP	          AP	                AP	                                  ...
プライベートクラウドではスケールしない	 VMで全体最適化が図れるもスケーラビリティに課題	   かといって、PaaSのような大規模なDB構築は容易ではない	  AP	   AP	   AP	      AP	                 ...
シャーディング分割案	APは論理的には1つだが実際はそれぞれの担当ノードに分かれる	  #1	       #2	   AP	    #3	        #4	   Consistent	  Hashing	                 ...
シャーディングの考え方	•  お互いに干渉しないような分割キーを見つける –  ユーザIDなど•  SalesForceのマルチテナントアーキテクチャー –  テナント別の「組織ID」で物理分割   •  http://www.publicke...
Berkeley DB Java Edition	  通常はキャッシュで処理、永続化も備える	        43	              Copyright © Virtual Technology, Inc
ScalabilityとConsistencyを両立	ノードは一定数のユーザを担当	               同期でステートフルでもOK	実質APだけで動作(RDBも疎結合)	           ノード追加で処理性能向上	        ...
シャーディングで問題になるケース	•  情報共有 –  ある情報を複数のユーザが更新する•  リカバリー –  障害ノードを復旧させるのがちょっと大変           45	           Copyright © Virtual Te...
5. トランザクション処理	    46	          Copyright © Virtual Technology, Inc
一貫性	•  一貫性(Consistency)	             これ重要	•  可用性(Availability)	  •  分割耐性(ParAAon	  Tolerance)	  •  しかし、Consistencyはとても重要	 ...
CAP定理とプロダクト	                  Hadoopは、                  Availabilityを犠牲                  Cassandraは、                  Cons...
在庫とシステムの一貫性の問題	•  本を買う例でいうなら、本はカートに入れられるか、   入れるのに失敗するかでなければいけない。 ある   いは買うか、買わないか。	  A                      在庫 0 点       ...
ReflexWorksのトランザクション処理	データの一貫性を確保しつつ高いスループットを実現	•  Feed単位のAtomicトランザクション  –  分離レベル:REPEATABLE READ•  かつ、Entry単位のバージョン比較  –...
Feed単位の1UOW(Unit	  of	  Work)	  <atomicity(原子性)、isolation(分離性)>・ entryはトランザクションの最小単位(RDBにおける1レコードに相当)・ aliasの追加・削除はentry内で...
「受注と明細」を1つの更新処理に束ねる	                 •  RDBだと2テーブルに跨ぐはず                  –  トランザクションで括るなど必要                 •  これを1リクエストで実...
6. パフォーマンス	  53	         Copyright © Virtual Technology, Inc
BDBのパフォーマンス	•  Total 100,000 requests、 100回繰り返し•  writeとdeleteの処理を実行、Value sizeは 1024 bytes•  Server1台(2CP,2.66GHz,3.3GB)、...
ReflexWorksのパフォーマンス	•  50万リクエスト/時で平均レスポンス 100~150ms –  Read 90%,Write 10% –  1ノードの性能                     ReflexWorks 1ノード ...
本当のボトルネックはどこか	コンテンツ関係だけで相当な改善効果があった	                      サーバサイド                     はJSON返すのみ•  動的コンテンツの廃止 –  クライアントによるレン...
本当のボトルネックはどこか	 シリアライズ30%、永続化40%、その他30%	•  シリアライズ/デシリアライズ       KVSがボトルネック                        になる部分は実は –  オブジェクトóJSON/...
Publicクラウドはレイテンシーが課題	                         Flash印刷パフォーマンステスト	  (Azure)	Windows	  Azure	   @singapore	                  ...
7.可用性59	     Copyright © Virtual Technology, Inc
どうせ世界が滅亡するんだから どうでもいい話です・・可用性	               マヤ暦が2012/12/21	  	                 までしかないんだから、	                 それ以降は知りません。	 ...
障害発生時の切替処理	   61	        Copyright © Virtual Technology, Inc
実際のところ故障率は?	  数ノードであれば故障はほとんどない	•  エンタープライズシステムは故障率が低い•  HWが故障しても動き続ける•  SWの理由で停止しても年間1ノードが数十分程   度ぐらい。•  RDBにきちんと格納さえできてい...
信頼性と安心感	    実績、保守サポート体制が重要	•  BDBはOracleの保守サポートを受けられる –  他のOSSなどと比較すると安心感はある          63	            Copyright © Virtual T...
まとめ•  分散KVSでスケールアウトを実現  –  実質RDBいらない、過度な冗長機能はいらない  –  トランザクション大事•  Thin Server Architecture  –  疎結合、REST、ユーザビリティ  –  本当のボト...
ReflexWorksは進化していきますOLTP+OLAPの組み合わせが標準になると予想(やはりRDBいらない)        雲(OLTP)の中身はモダンプログラミング?	                                   ...
Upcoming SlideShare
Loading in...5
×

BPStudy20121221

3,902

Published on

1 Comment
8 Likes
Statistics
Notes
  • USTはこちらです => http://www.ustream.tv/recorded/27904291
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
3,902
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
17
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

Transcript of "BPStudy20121221"

  1. 1. 300万トランザクション/日を処理する スケールアウト型Web帳票システムの仕組みについて 2012/12/21 有限会社バーチャルテクノロジー 1   Copyright © Virtual Technology, Inc
  2. 2. •  竹嵜伸一郎 (たけざき しんいちろう)•  (有)バーチャルテクノロジー –  分散KVSのミドルウェア開発(ReflexWorks)•  1992-2003 –  日本IBM ソフトウェア事業部•  2007-2009 –  (株)暮らしのデザイン CTO 2   Copyright © Virtual Technology, Inc
  3. 3. Agenda 1.Web帳票システムの概要2.分散KVSについて3.Thin Server Architecture4.スケーラビリティ5.トランザクション処理6.パフォーマンス7.可用性  まとめ 3   Copyright © Virtual Technology, Inc
  4. 4. 1. Web帳票システムの概要 4   Copyright © Virtual Technology, Inc
  5. 5. 背景  インストール型帳票アプリをWeb化するにあたって・・                   •  ユーザビリティ、パフォーマンス –  クライアントアプリに比べ遜色のないUI/UX –  ボタンを押して数秒以内に印刷開始、高速な印刷実行 –  バーコード(EAN128など)やQRコードといった高品位な帳票印刷•  モダンブラウザ対応 –  昔はWindows+IEで十分だったが、最近ではMacでもという要望が増加 –  Chrome、Firefox、Safariといったモダンブラウザにも対応させたい•  急激なアクセス数の増大に柔軟に対応 –  スタート時は最小のリソースで開始したいが実際にどれくらいのアクセス が来るかわからない。(数十万ユーザの同時利用に耐えられるか) –  将来的なアクセス増大に単純なリソース追加により対応したい。 5   Copyright © Virtual Technology, Inc
  6. 6. Web帳票システムのこれまでのソリューション  2005年頃ブームになったリッチクライアントでは・・                   •  ActiveXコンポーネント –  ダイレクト印刷コンポーネント –  IE6問題の諸悪の根源 結論:•  独自ブラウザ インターネット利用 –  インストール型と実質変わらない。 に向かない –  ○○Browser、curl、Adobe AIR•  サーバサイドでPDF生成 –  サーバ負荷が大きい –  スケールしない 6   Copyright © Virtual Technology, Inc
  7. 7. 企業内業務システムで今大変な問題が起きている Ac>veXへの強依存があってIE6をやめられない IE6  やめようと思ってももう手遅れ   h0p://www.slideshare.net/bath>mefish/ie6-­‐15583209 7   Copyright © Virtual Technology, Inc
  8. 8. ReflexWorks  Web帳票システム 8   Copyright © Virtual Technology, Inc
  9. 9. 3つのポイント    UI/UX、パフォーマンス、スケーラビリティの3つを同時に解決 •  Thin Server Architecture –  APサーバはデータを返すだけ(JSON/XML) –  Webサーバは静的コンテンツを返すだけ(HTML,CSS,JavaScript等) Flash利用の異論 –  クライアントによるレンダリングで70%負荷軽減 ActiveXと同じ問題? HTML5は? ➡ 現実解 •  Flash印刷コンポーネント –  クライアントリソースの活用でサーバ側への負荷は最小限 –  バーコード、QRコードなどをクライアント側で高速に印刷 –  Active Xを使用していないため様々なOSやブラウザで動作する •  Flash導入率は世界で99%以上。スマホなどを除くとほぼすべてのブラウザに対応•  分散KVS –  顧客数を最大に見積もらなくてもスモールスタートが可能 –  急激なアクセス増大にも単純なノードを追加で対応可能 9   Copyright © Virtual Technology, Inc
  10. 10. 2. 分散KVSについて 10   Copyright © Virtual Technology, Inc
  11. 11. なぜ分散KVSを採用したのか •  キャッシュとして利用 –  読込/書込性能向上 –  RDBのボトルネックを解消、スケールアウトできる•  O/Rマッパーが不要になる –  KVSに直接オブジェクトを保存可能 –  工数削減、開発の4割がマッピングに費やされている –  RDBを実質的に廃止できる RDBのインスタンス•  管理コストが低い を増やすと管理が大変 –  導入設定が不要、スキーマの生成が不要 –  単純なログファイル、管理が非常に楽 11   Copyright © Virtual Technology, Inc
  12. 12. KVSで業務アプリを作るのは大変 •  検索(複合条件、OR検索)  •  ソート  •  JOIN  •  カウント   INDEX爆発が 起りがち   12   Copyright © Virtual Technology, Inc
  13. 13. 分散KVSを業務アプリで使うには 業務アプリにKVSであることを意識させないことが大事 h0p://blog.virtual-­‐tech.net/2012/07/kvs.html •  ユーザビリティ –  ドキュメント指向でRESTによる操作を基本とする•  トランザクション処理 –  業務アプリを作るうえで必須(後述)•  RangeScan、セカンダリIndex –  キー以外の項目でも高速に検索できないと全走査 となって使い物にならない   •  1.5次元レベル、GAE  DatastoreなどはINDEXがある 13   Copyright © Virtual Technology, Inc
  14. 14. NoSQLのデータモデル 業務アプリで使うにはドキュメント指向じゃないと辛い Dynamo Cassandra MongoDB   ReflexWorks 14   Copyright © Virtual Technology, Inc
  15. 15. 紙(≠ドキュメント)指向 •  コンピュータがない時代、全部紙だったじゃないか。 受付 15   Copyright © Virtual Technology, Inc
  16. 16. ReflexWorks エンタープライズ向けアプリケーションを容易に構築できるトランザクショナルKVS•  2010年10月開始、商用、Javaで記述  •  ドキュメント指向、JSON、XML、MessagePackに対応  •  ORM(Object-­‐Rela>onal  Mapping)不要   –  En>tyオブジェクトをシリアライズ保存   –  ソフトスキーマ(スキーマレスではないが)  •  RDBからデータ復元(可用性向上)  •  シャーディング水平スケーリング(パフォーマンス向上)   –  ConsistentHashアルゴリズム採用  •  オンラインでACIDトランザクション処理が可能  •  認証・アクセス管理機能  •  データ保存効率は悪い(圧縮はしない)   16   Copyright © Virtual Technology, Inc
  17. 17. 3. Thin Server Architecture (RESTで疎結合) 17   Copyright © Virtual Technology, Inc
  18. 18. Thin Server Architecture クライアントからRESTでサーバリソースにアクセス   サーバからはJSONやXMLのデータを返すのみ BaaSのような感じ REST データ ・・・ 18   Copyright © Virtual Technology, Inc
  19. 19. ReflexWorksにおけるデータ管理 19   Copyright © Virtual Technology, Inc
  20. 20. 直感的なRESTAPIによる操作 •  リソースURLは自由に設定、追加できる。   •  マッピングルールなどを書く必要がない              →  設定ファイル地獄、アノテーション地獄からの解放  •  リソースを様々なフォーマットに変換できる。   •  単純なプロパティとListをもつPOJOで階層構造を表現   →  JSON  ,  XML  ,  msgpackなどに変換可能  •  リソースに対してCRUD操作可能               20   Copyright © Virtual Technology, Inc
  21. 21. フォルダとエントリの階層表現 •  フォルダ配下の取得とエントリの取得 –  GET /{フォルダ} •  {フォルダ}の集合(ATOM Feed)を取得 –  GET /{フォルダ}/{エントリ}?entry •  {フォルダ}の集合の1エントリ (ATOM Entry)を取得•  実はフォルダとエントリの区別はない –  エントリはフォルダの性質をあわせもつ –  GET /{フォルダ}/{エントリ} •  {フォルダ}/{エントリ}の集合を取得 –  GET /{フォルダ}/{エントリ}/{エントリ2}?entry •  {フォルダ}/{エントリ}の集合の1エントリを取得 21   Copyright © Virtual Technology, Inc
  22. 22. 検索条件など 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文字列を渡す。 例)上限を3件として検索。検索結果が3件以上ある場合、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 その他の制約  プロパティは2文字以上の名称をつけてください。 先頭に_(アンダースコア)をつけた名称は、内部処理で使用しているため、プロパティの名前に使用できません。  パラメータのつなぎに.(ドット)を使用しているため、プロパティの名前に使用できません。 22   Copyright © Virtual Technology, Inc
  23. 23. 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   Copyright © Virtual Technology, Inc
  24. 24. WebSocketによるイベント通知機能•  WebSocketのコネクション確立時に認証する •  接続情報をセッションで管理•  フォルダ共有(R権限)でかつログイン中のユーザに通知 Reactive! h0p://reflexworks.jp/features.html#pushNo>fica>ons   24   Copyright © Virtual Technology, Inc
  25. 25. 疎結合だから並行開発できる 内部設計~単体テストフェーズにおいて並行開発ができる ・ユースケース図、ユースケース記述 ・分析クラス図、論理ビュー 要件定義 ・画面モックアップ 外部設計 ・エンティティ設計、テーブル設計、インスタンス作成 ・画面実装 ・Resorceモデル設計 ・DAOモデル設計 内部設計 ・単体テスト ・フローアセンブル ・O/Rマッピング実装 ・単体テスト ・単体テスト ・統合テスト テスト ・システムテスト リリース 25   Copyright © Virtual Technology, Inc
  26. 26. 4. スケーラビリティ 26   Copyright © Virtual Technology, Inc
  27. 27. 基本的なスタンス 効率よくスケールすれば雲の中身はどうでもいい BaaSのような感じ WEB AP REST セッションオブジェクト        DB WEB AP セッションオブジェクト ・・・ WEB AP セッションオブジェクト 27   Copyright © Virtual Technology, Inc
  28. 28. 以下の技術とは区別する 枯れた技術だけを採用し以下は使わない方針 •  並列・並行プログラミング –  メニーコアで最大能力を引き出す •  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   Copyright © Virtual Technology, Inc
  29. 29. 要はパフォーマンスと全体最適化の問題 •  パフォーマンスの問題 これらの問題は実は   –  データが増えると遅くなる モダンプログラミング   じゃなくても解決できる –  アクセスが多くなると遅くなる ユーザ100万人が同時に使える? 実は他に改善すべき•  全体最適化の問題 ことがいっぱいある –  VMの全体最適化では不十分 29   Copyright © Virtual Technology, Inc
  30. 30. これまでの3階層システム トランザクション   はDBMSの機能で実現 WEB AP DB 30   Copyright © Virtual Technology, Inc
  31. 31. DBとボトルネック 単にWEBやAPを増やしてもスケールしない DBがボトルネックとなり  WEB AP スケールしない WEB AP DB WEB AP 31   Copyright © Virtual Technology, Inc
  32. 32. 分散キャッシュ 読込性能は上がるが・・   DBとの整合性はどうする? WEB AP WEB AP Cache DB WEB AP 32   Copyright © Virtual Technology, Inc
  33. 33. 案:スケーラブルなDBを使う APをステートレスにしてAutoScaleできれば概ね解決 WEB AP セッションオブジェクト DynamoDB  WEB AP    とか セッションオブジェクト WEB AP セッションオブジェクト 33   Copyright © Virtual Technology, Inc
  34. 34. しかし、本当にスケールするか? なぜFacebook  Messages でCassandraではなく Hbaseが採用されたの か?  h0p://www.slideshare.net/okuyamaoo/okuyama-­‐20120119-­‐ss 34   Copyright © Virtual Technology, Inc
  35. 35. 本当にスケールするか? 35   Copyright © Virtual Technology, Inc
  36. 36. 本当にスケールするか? 2.4系から仮想メモリを廃止  つまり、メモリサイズを超えるデータの扱いが困難  ACIDのDをどうするか? DB AP × h0p://redis.io/topics/virtual-­‐memory 36   Copyright © Virtual Technology, Inc
  37. 37. 分割すりゃいいじゃん 困難は分割せよ By  ルネ・デカルト 37   Copyright © Virtual Technology, Inc
  38. 38. Scale-up vs Scale-Out Scale-Up Scale-Out性能の高いサーバは、極端に高くなる性能の頭打ち(ムーアの法則) 性能は、価格に比例 廉価サーバ 38   Copyright © Virtual Technology, Inc
  39. 39. PaaS(パブリッククラウド)の例 DBにKVSを採用、AP,DBともにオートスケール、規模の経済性 AP AP AP AppEngine  Datastore   DB(KVS) AWS  Dynamo   OS OS OS OS H/W H/W 39   Copyright © Virtual Technology, Inc
  40. 40. プライベートクラウドではスケールしない VMで全体最適化が図れるもスケーラビリティに課題   かといって、PaaSのような大規模なDB構築は容易ではない AP AP AP AP スケールしない DB DB DB DB OS OS OS OS H/W H/W 40   Copyright © Virtual Technology, Inc
  41. 41. シャーディング分割案 APは論理的には1つだが実際はそれぞれの担当ノードに分かれる #1 #2 AP #3 #4 Consistent  Hashing   シャーディング DB DB DB DB OS OS OS OS H/W H/W 41   Copyright © Virtual Technology, Inc
  42. 42. シャーディングの考え方 •  お互いに干渉しないような分割キーを見つける –  ユーザIDなど•  SalesForceのマルチテナントアーキテクチャー –  テナント別の「組織ID」で物理分割 •  http://www.publickey1.jp/blog/09/2id.html –  ユーザー企業が増えた場合でも、データが増えた場合でも、 パーティションを増やし、そのパーティションを処理するイン スタンスを追加することでスケーラブルな対応をする 42   Copyright © Virtual Technology, Inc
  43. 43. Berkeley DB Java Edition 通常はキャッシュで処理、永続化も備える 43   Copyright © Virtual Technology, Inc
  44. 44. ScalabilityとConsistencyを両立 ノードは一定数のユーザを担当   同期でステートフルでもOK 実質APだけで動作(RDBも疎結合) ノード追加で処理性能向上 疎結合 疎結合 スケーラブル!!   シャーディングでも敗北感を感じる必要はない 44   Copyright © Virtual Technology, Inc
  45. 45. シャーディングで問題になるケース •  情報共有 –  ある情報を複数のユーザが更新する•  リカバリー –  障害ノードを復旧させるのがちょっと大変 45   Copyright © Virtual Technology, Inc
  46. 46. 5. トランザクション処理 46   Copyright © Virtual Technology, Inc
  47. 47. 一貫性 •  一貫性(Consistency)   これ重要 •  可用性(Availability)  •  分割耐性(ParAAon  Tolerance)  •  しかし、Consistencyはとても重要 47   Copyright © Virtual Technology, Inc
  48. 48. CAP定理とプロダクト Hadoopは、 Availabilityを犠牲 Cassandraは、 Consistencyを犠牲 (C)Nathan  Hursts  Blog 48   Copyright © Virtual Technology, Inc
  49. 49. 在庫とシステムの一貫性の問題 •  本を買う例でいうなら、本はカートに入れられるか、 入れるのに失敗するかでなければいけない。 ある いは買うか、買わないか。 A 在庫 0 点 在庫残り1点 !! B 49   Copyright © Virtual Technology, Inc
  50. 50. ReflexWorksのトランザクション処理 データの一貫性を確保しつつ高いスループットを実現 •  Feed単位のAtomicトランザクション –  分離レベル:REPEATABLE READ•  かつ、Entry単位のバージョン比較 –  分離レベル:SNAPSHOT ISOLATION –  全てのEntryはURLとリビジョンで管理される –  リビジョン=更新されると+1される 詳細: h0ps://www.facebook.com/notes/virtual-­‐technology/   bdbトランザクションとreflexworksの処理について/486790368009209 50   Copyright © Virtual Technology, Inc
  51. 51. Feed単位の1UOW(Unit  of  Work)  <atomicity(原子性)、isolation(分離性)>・ entryはトランザクションの最小単位(RDBにおける1レコードに相当)・ aliasの追加・削除はentry内でatomicでありisolationが保たれる (例えばフォルダ移動で2重に見えたりはしない)<consistency(一貫性)>・ feedのPOST/PUTは1UOWで実行され一貫性は保たれる (どれか一つのEntryが失敗するとロールバックされる) ATOM Feed <feed> <entry> self <link rel=“self" href=”/folder0/document1"> <link rel="alternate" href="/folder1/document1"> alias ・・・ </entry> transaction scope <entry> ・・・ </entry>  ・・・ </feed> 51   Copyright © Virtual Technology, Inc
  52. 52. 「受注と明細」を1つの更新処理に束ねる •  RDBだと2テーブルに跨ぐはず –  トランザクションで括るなど必要 •  これを1リクエストで実行する –  1Feed内に本体と明細のentryを入 れるだけで1トランザクションとして 実行可能 POST/PUT/DELETE <feed>        <entry>          <id>受注のid  </id>        <entry>    <entry>        <id>明細のid</id>        <entry>   </feed> 52   Copyright © Virtual Technology, Inc
  53. 53. 6. パフォーマンス 53   Copyright © Virtual Technology, Inc
  54. 54. 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   Copyright © Virtual Technology, Inc
  55. 55. ReflexWorksのパフォーマンス •  50万リクエスト/時で平均レスポンス 100~150ms –  Read 90%,Write 10% –  1ノードの性能 ReflexWorks 1ノード 12000 10000 8000 ms 6000 1ノードの処理性能 4000 2000 限界値   0 これをこえるとFullGC頻発 55   Copyright © Virtual Technology, Inc
  56. 56. 本当のボトルネックはどこか コンテンツ関係だけで相当な改善効果があった サーバサイド はJSON返すのみ•  動的コンテンツの廃止 –  クライアントによるレンダリングで70%負荷削減 –  帳票作成の負荷削減効果は計り知れない•  静的コンテンツのWebサーバへの移動 – 10%~20%の負荷削減(ロードアベレージ) 56   Copyright © Virtual Technology, Inc
  57. 57. 本当のボトルネックはどこか シリアライズ30%、永続化40%、その他30% •  シリアライズ/デシリアライズ KVSがボトルネック になる部分は実は –  オブジェクトóJSON/XML変換のコストあまりない •  永続化 –  オブジェクトをBDBなどのDatastoreに保存するコスト•  その他 プログラミングモデル変更で 果たして改善できるか? –  ビジネスロジック処理 •  マスター参照を伴うデータチェックなど重いものは全体の 90%以上を占める 57   Copyright © Virtual Technology, Inc
  58. 58. Publicクラウドはレイテンシーが課題 Flash印刷パフォーマンステスト  (Azure) Windows  Azure   @singapore   ・ データ1000件分格納後、取り出しを行う   3300Bytes      上り:41秒/1000件、下り:18秒/1000件   Table  Storage   /1レコード  1000レコード 444レコード*2   ・ Flash側でダイレクト印刷する   WebRole(C#)        125秒/3000ページ   AMF  Messaging  Gateway        (印刷開始は1P目がスプールされた時点) AMF3   125秒/3000ページ   (※印刷は1P目がスプールに出されると直ぐに開始される) 100MBPS   AWSも当時は東京リージョンがなく   同様だった Windows7  /  Corei7 /  Flash10     58   Copyright © Virtual Technology, Inc
  59. 59. 7.可用性59   Copyright © Virtual Technology, Inc
  60. 60. どうせ世界が滅亡するんだから どうでもいい話です・・可用性 マヤ暦が2012/12/21     までしかないんだから、   それ以降は知りません。   60   Copyright © Virtual Technology, Inc
  61. 61. 障害発生時の切替処理 61   Copyright © Virtual Technology, Inc
  62. 62. 実際のところ故障率は? 数ノードであれば故障はほとんどない •  エンタープライズシステムは故障率が低い•  HWが故障しても動き続ける•  SWの理由で停止しても年間1ノードが数十分程 度ぐらい。•  RDBにきちんと格納さえできていれば大丈夫 –  RDBの代わりにHBaseはアリかも•  KVSの冗長化は無駄 –  3台に同じデータを書き込むなんて・・・ 62   Copyright © Virtual Technology, Inc
  63. 63. 信頼性と安心感 実績、保守サポート体制が重要 •  BDBはOracleの保守サポートを受けられる –  他のOSSなどと比較すると安心感はある 63   Copyright © Virtual Technology, Inc
  64. 64. まとめ•  分散KVSでスケールアウトを実現 –  実質RDBいらない、過度な冗長機能はいらない –  トランザクション大事•  Thin Server Architecture –  疎結合、REST、ユーザビリティ –  本当のボトルネックをなんとかすべき 64   Copyright © Virtual Technology, Inc
  65. 65. ReflexWorksは進化していきますOLTP+OLAPの組み合わせが標準になると予想(やはりRDBいらない)        雲(OLTP)の中身はモダンプログラミング?   OLTP REST   MessagePack 並列・並行プログラミング   OLAP Monad   ロックフリー、       Impala? ・・・ Concurrent  Revisions   Fluentd   STM   ご清聴ありがとう ございました 65   Copyright © Virtual Technology, Inc
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×