Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reflex works20120818 1

1,412 views

Published on

クラウド温泉3.0 の説明用資料
(前編)

  • Be the first to comment

Reflex works20120818 1

  1. 1. ぶいてく流スケーラブルアプリの作り方 2012(前編) 2012/8/18 有限会社バーチャルテクノロジー 1   Copyright © Virtual Technology, Inc
  2. 2. •  竹嵜伸一郎 (たけざき しんいちろう)•  寺田典子(てらだ のりこ)•  (有)バーチャルテクノロジー –  分散KVSのミドルウェア開発(ReflexWorks) 2   Copyright © Virtual Technology, Inc
  3. 3. Agenda 1.なんでスケーラブルにするのか2.どうすればスケーラブルになるか 2−1.アプリの観点 2−2.システムの観点3.ReflexWorksの概要4.スケーラブルアプリの設計5.データの一貫性6.アクセス制御とソーシャル化7.大規模Web帳票システムの事例(LT) 3   Copyright © Virtual Technology, Inc
  4. 4. 1. なんでスケーラブルにするのか 4   Copyright © Virtual Technology, Inc
  5. 5. パフォーマンスと全体最適化の問題 •  パフォーマンスの問題 –  データが増えると遅くなる –  アクセスが多くなると遅くなる•  全体最適化の問題 –  VMの全体最適化では不十分 5   Copyright © Virtual Technology, Inc
  6. 6. Scale-up vs Scale-Out Scale-Up Scale-Out性能の高いサーバは、極端に高くなる性能の頭打ち(ムーアの法則) 性能は、価格に比例 廉価サーバ 6   Copyright © Virtual Technology, Inc
  7. 7. 2−1.どうすればスケーラブルにな るか(アプリの観点) 7   Copyright © Virtual Technology, Inc
  8. 8. 論点 •  集中 vs 分散•  密結合 vs 疎結合•  同期 vs 非同期 •  ステートフル vs ステートレス –  分散で疎結合で非同期でステートレスなシステム (つまり、メール)が最強。しかし、それだけでは済 まないのが世の中。➡ オンラインWebアプリ –  スケールアウト性を損なわずに、どこをどう妥協し ていくか 8   Copyright © Virtual Technology, Inc
  9. 9. 集中 vs 分散 •  集中化で運用管理は楽になるが・・ –  RDBに負荷が集中することでパフォーマンス劣化 –  MemcachedではRDBとの整合性確保が困難になる –  障害になるとシステム全体に影響を及ぼす•  分散化でスケーラブルになるが・・ –  運用管理が複雑になる –  厳密なデータの一貫性の確保が困難 一貫性確保などの課題を克服して   分散化でいくことができるか(これが命題) 9   Copyright © Virtual Technology, Inc
  10. 10. 密結合 vs 疎結合 •  密結合で高速な動作が可能になるが・・ –  分散化(スケールアウト)しにくい –  例) JSP(APに負荷)とHTML+JS(Webに負荷)•  疎結合で分散化しやすくなるが・・ –  高速処理に向かないケースがある。 –  個々のコンポーネントの独立性が高く相互依存性 が低い。また分散化しやすい。 可能な限り疎結合とする(異論はないはず)    ブラウザ、サービス、DBの間は少なくとも   10   Copyright © Virtual Technology, Inc
  11. 11. 同期 vs 非同期 •  同期だと処理(トランザクションや実行順序)が 保証されるが・・ –  他の処理をブロックさせてしまう –  1つのリソースに処理が集中するとスケールしない•  非同期だとスケールするが・・ –  データの一貫性は確保できない –  遅延が発生する 一貫性は重要であり、同期処理をやらざるを   得ないケースがある。トランザクション処理など 11   Copyright © Virtual Technology, Inc
  12. 12. ステートフル vs ステートレス •  ステートフルだと高速になるが・・ –  メモリ、DBなどを介すためスケールさせにくい –  セッションオブジェクトに中間データを保存すること で処理(再送、再計算など)を省略できる•  ステートレスだとスケールするが・・ –  必要な情報を毎回送信する必要があり冗長になる。 –  認証、データチェックなどは都度実行となり、パ フォーマンスは悪くなる ステートフルにせざるを得ないケースがある   Webアプリの認証、WebSocket、・・   12   Copyright © Virtual Technology, Inc
  13. 13. 2−2.どうすればスケーラブルに なるか(システムの観点) 13   Copyright © Virtual Technology, Inc
  14. 14. これまでの3階層システム トランザクション   はDBMSの機能で実現 WEB AP DB 14   Copyright © Virtual Technology, Inc
  15. 15. DBとボトルネック 単にWEBやAPを増やしてもスケールしない DBがボトルネックとなり  WEB AP スケールしない WEB AP DB WEB AP 15   Copyright © Virtual Technology, Inc
  16. 16. 分散キャッシュ 読込性能は上がるが・・   整合性はどうする? WEB AP WEB AP Cache DB WEB AP 16   Copyright © Virtual Technology, Inc
  17. 17. PaaS(パブリッククラウド)の例 DBにKVSを採用、AP,DBともにオートスケール、規模の経済性 AP AP AP AppEngine  Datastore   DB(KVS) AWS  Dynamo   OS OS OS OS H/W H/W 17   Copyright © Virtual Technology, Inc
  18. 18. プライベートクラウドの課題 VMで全体最適化が図れるもスケーラビリティに課題  かといって、PaaSのような大規模なDB構築は容易ではない AP AP AP AP スケールしない DB DB DB DB OS OS OS OS H/W H/W 18   Copyright © Virtual Technology, Inc
  19. 19. (解決案)AP統合、一方でシャーディング APは論理的には1つだが実際はそれぞれの担当ノードに別れる (困難は分割せよ  by  デカルト) #1 #2 AP #3 #4 Consistent  Hashing   シャーディング DB DB DB DB OS OS OS OS H/W H/W 19   Copyright © Virtual Technology, Inc
  20. 20. シャーディングの考え方 •  お互いに干渉しないような分割キーを見つける –  ユーザIDなど•  SalesForceのマルチテナントアーキテクチャー –  テナント別の「組織ID」で物理分割 •  http://www.publickey1.jp/blog/09/2id.html –  ユーザー企業が増えた場合でも、データが増えた場合でも、 パーティションを増やし、そのパーティションを処理するイン スタンスを追加することでスケーラブルな対応をする 20   Copyright © Virtual Technology, Inc
  21. 21. 1、2章のまとめ •  集中 vs 分散•  密結合 vs 疎結合•  同期 vs 非同期 •  ステートフル vs ステートレス –  分散で疎結合とすべきなのは異論がないところ。 –  さらに非同期でステートレスにできればよいがそれ だけで済まない現実がある。 –  APをシャーディングで分割する案 21   Copyright © Virtual Technology, Inc

×