BPStudy20121221

4,386 views

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
4,386
On SlideShare
0
From Embeds
0
Number of Embeds
2,555
Actions
Shares
0
Downloads
18
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

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

×