Coherenceを利用するときに気をつけること #OracleCoherence

5,269 views

Published on

0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,269
On SlideShare
0
From Embeds
0
Number of Embeds
639
Actions
Shares
0
Downloads
47
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Coherenceを利用するときに気をつけること #OracleCoherence

  1. 1. Coherenceを利用する ときに気をつけること 2013/08/21 槙 俊明 twitter:@making
  2. 2. Agenda • 今日の話のスコープ • 前提知識のおさらい • 設計編 • コーディング編 • チューニング編 • Advanced Topic
  3. 3. Agenda • 今日の話のスコープ • 前提知識のおさらい • 設計編 • コーディング編 • チューニング編 • Advanced Topic
  4. 4. 今日の話のスコープ • Coherenceのアプリケーション開発に関するノウ ハウについての説明 • インフラの話ではない(ネットワーク構成などは 話せない) • Coherenceに限らず、他の分散インメモリデータ グリッド製品を利用する場合にも適用できる • Inifinispan(RedHat) • eXtremeScale(IBM) • Gemfire(Pivotal ← VMware) • Coherence 3.7.1の話であり、Coherence 12c以降 改善されている可能性あり
  5. 5. 用途の決定 • Coherence設計ポイントは用途によって大きく異なる • DBのフロントのキャシュ用途なのか • パフォーマンスを上げるためにメモリサーバーだけの運 用するのか • CEP的なやつなのか
  6. 6. 用途の決定 • Coherence設計ポイントは用途によって大きく異なる • DBのフロントのキャシュ用途なのか • パフォーマンスを上げるためにメモリサーバーだけの運 用するのか • CEP的なやつなのか • ここでは2つ目の用途について説明する。 • 1つ目はJPAなどO/RマッパーのL2キャッシュを使用すれ ば良い
  7. 7. 用途の決定 • Coherenceを使う目的をはっきり決め て方針を決めることが重要。 • ここが曖昧になると、なんでもかんで も安直に「とりあえずCoherenceにい れよう!」っていう流れになってしま う。これは食い止めねばならない。
  8. 8. Agenda • 今日の話のスコープ • 前提知識のおさらい • 設計編 • コーディング編 • チューニング編 • Advanced Topic
  9. 9. 前提知識のおさらい • Cache方式 • DB連携方式
  10. 10. 前提知識のおさらい • Cache方式 • DB連携方式
  11. 11. Cache方式 • Partitioned Cache • Replicated Cache • Near Cache
  12. 12. Cache方式 • Partitioned Cache • Replicated Cache • Near Cache
  13. 13. Partitioned Cache • クラスタ上のどこか2つのノード (primary, backup)にキャッシュを置く。 • 書き込みは2ホップ、読み込みは1ホッ プ。 • 十分速く、普通はこちらを使う。
  14. 14. Partitioned Cacheの読み込み キャッシュノード1 アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B P B A B CD A B C D 読み取りは1hopの ネットワークアクセス P…プライマリデータ、B…バックアップデータ
  15. 15. Partitioned Cacheの書き込み キャッシュノード1 アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B P B P…プライマリデータ、B…バックアップデータ A B CD A B C D 書き込みは2hopの ネットワークアクセス
  16. 16. Partitioned Cacheのリカバリ キャッシュノード1 アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B P B A B CD A B C D P…プライマリデータ、B…バックアップデータ
  17. 17. Partitioned Cacheのリカバリ アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B B C A B D P…プライマリデータ、B…バックアップデータ
  18. 18. Partitioned Cacheのリカバリ アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B B C A B D A D バックアップが プライマリに昇格 P…プライマリデータ、B…バックアップデータ
  19. 19. Partitioned Cacheのリカバリ アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B B CBA D バックアップが プライマリに昇格 P…プライマリデータ、B…バックアップデータ
  20. 20. Partitioned Cacheのリカバリ アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B B C D B A A D C プライマリから バックアップを作成 P…プライマリデータ、B…バックアップデータ
  21. 21. Partitioned Cacheのリカバリ アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B B C D B A A D C P…プライマリデータ、B…バックアップデータ
  22. 22. Partitioned Cacheのノード追加 キャッシュノード1 アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B P B A B CD A B C D キャッシュノード4 P B P…プライマリデータ、B…バックアップデータ
  23. 23. Partitioned Cacheのノード追加 キャッシュノード1 アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B P B A B CD A B C D キャッシュノード4 P B D B 再パーティショニング P…プライマリデータ、B…バックアップデータ
  24. 24. Partitioned Cacheのノード追加 キャッシュノード1 アプリケーション アプリケーション キャッシュノード2 キャッシュノード3 P B P B P B A C A B C D キャッシュノード4 P B D B キャッシュ容量を 追加できる P…プライマリデータ、B…バックアップデータ
  25. 25. Cache方式 • Partitioned Cache • Replicated Cache • Near Cache
  26. 26. Replicated Cache • 全てのクラスタ上の全ノードにキャッシュを置く。 • 書き込みはN(=ノード数)-1ホップかかるので遅いが、 読み込みは0ホップで超高速(同一JVM上のlocalキャ ッシュと同等)。 • データサイズはスケールしないので、頻繁に読み込 む必要がある少量のデータ用途。 • 後述のread throughが使えない点に注意。
  27. 27. Replicated Cacheの読み込み キャッシュノード1 アプリケーション A B C D キャッシュノード2 アプリケーション A B C D キャッシュノード3 アプリケーション A B C D 読み取りは同一プロセス内で完結
  28. 28. Replicated Cacheの書き込み キャッシュノード1 アプリケーション A B C D キャッシュノード2 アプリケーション A B C D キャッシュノード3 アプリケーション A B C D 書き込みは他のノードへ複製
  29. 29. Cache方式 • Partitioned Cache • Replicated Cache • Near Cache
  30. 30. Near Cache • Partitioned Cache + Local Cache。 • 書き込みはLocal Cache→Partitioned Cacheの順 に行う。読み込み時にLocal Cacheになかったら Partitioned Cacheを探す。 • 読み込み速度は2回目以降は超高速 • キャッシュ削除の伝播が非同期であることに注 意。
  31. 31. AP Server Near Cache アプリケーション Partitioned Cache LocalC ache Near Cache
  32. 32. AP Server Near Cacheからデータ取得 アプリケーション Partitioned Cache LocalC ache Near Cache Get A
  33. 33. AP Server アプリケーション A Partitioned Cache 存在する LocalC ache Get A A 存在しない Near Cacheからデータ取得
  34. 34. AP Server アプリケーション A Partitioned Cache LocalC ache Get A 裏のPartitionedキャ ッシュからコピー A Near Cacheからデータ取得
  35. 35. AP Server アプリケーション A Partitioned Cache LocalC ache Get A A Near Cacheからデータ取得 2回目以降はLocalキャッシ ュから取得するため超高速
  36. 36. AP Server Near Cacheへデータ書込 アプリケーション Partitioned Cache LocalC ache Near Cache Write A
  37. 37. AP Server Near Cacheへデータ書込 アプリケーション Partitioned Cache LocalC ache Near Cache Write A A まずLocalキャッ シュに書込
  38. 38. AP Server Near Cacheへデータ書込 アプリケーション Partitioned Cache LocalC ache Near Cache Write A A A Localから分散へ コピー A
  39. 39. AP Server Near Cacheのデータ更新伝播 アプリケーション Partitioned Cache LocalC ache Near Cache Write A A A A AP Server アプリケーション LocalC ache A 更新or削除
  40. 40. AP Server Near Cacheのデータ更新伝播 アプリケーション Partitioned Cache LocalC ache Near Cache Write A A A A AP Server アプリケーション LocalC ache A 別ノードの同じデー タを非同期で削除
  41. 41. Cache方式の比較 方式 書き込み 読み込み データサイズ 耐障害性 一貫性 Partitio ned 1+n hop n=バック アップ数 通常n=1 1 hop ノードの追加 によって容量 を拡張可能 バックアップから プライマリへ昇格 し、新たなバック アップを別ノード に作成 一貫 Replicat ed m-1 hop m=ノード 数 (同期/非 同期でレ イテンシ が変わる) 0 hop 1プロセスに 割り当て可能 な最大量(2 ~4GB) 高い(落ちたノード を無視するのみ) 一貫 Near 1+n(+m- 1) ()内は非 0 hop (初回を除 く) Partitionedと 同じ (local cache が容量オーバ ? 要検討
  42. 42. 前提知識のおさらい • Cache方式 • DB連携方式
  43. 43. DB連携方式 • read through • キャッシュ上になかったらDBから取り出し キャッシュに乗せる • write through • キャッシュに書き込んだ後、同期してDBに 書き込む • write behind • キャッシュに書き込んだ後、非同期でDBに 書き込む
  44. 44. Read Through DBアプリケーション AGet A Cache Cluster 存在する
  45. 45. Read Through DBアプリケーション AGet A Cache Cluster 存在する A
  46. 46. Read Through DBアプリケーション AGet A Cache Cluster 存在しない
  47. 47. CacheStore Read Through DBアプリケーション Get A Cache Cluster CacheStoreを介して DBから取得 A select … from .. where id = A
  48. 48. Read Through DBアプリケーション Get A Cache Cluster A CacheStore A 二回目以降は 直接キャッシュか ら取得可能
  49. 49. Write Through DBアプリケーション Write A Cache Cluster A
  50. 50. CacheStore Write Through DBアプリケーション Write A Cache Cluster CacheStoreを介して DBへ書き込み A insert or update where id = A A
  51. 51. CacheStore Write Through DBアプリケーション Write A Cache Cluster CacheStoreを介して DBへ書き込み A insert or update where id = A A DBへ書き込みが同 期 =一貫性が保たれる
  52. 52. Write Behind DBアプリケーション Write A Cache Cluster A
  53. 53. CacheStore Write Behind DBアプリケーション Write A Cache Cluster CacheStoreを介して DBへ書き込み A insert or update where id = A A
  54. 54. CacheStore Write Behind DBアプリケーション Write A Cache Cluster CacheStoreを介して DBへ書き込み A insert or update where id = A A DBへ書き込みが非同期 =一貫性は保たれないが 高スループット
  55. 55. Agenda • 今日の話のスコープ • 前提知識のおさらい • 設計編 • コーディング編 • チューニング編 • Advanced Topic
  56. 56. 設計編 • キャッシュデータの種類 • メモリとDBの同期 • DB→メモリ • メモリ→DB • データの検索
  57. 57. 設計編 • キャッシュデータの種類 • メモリとDBの同期 • DB→メモリ • メモリ→DB • データの検索
  58. 58. キャッシュデータの種類 • メモリ上にのみ存在してDBには存在し ないもの • メモリ上にもDBにも存在して同期が必 要な物 • [メモリ上に一時的に存在してDBに同期 したら削除するもの]
  59. 59. キャッシュデータの種類 • メモリ上にのみ存在してDBには存在し ないもの(非永続データ) • メモリ上にもDBにも存在して同期が必 要な物(永続データ) • [メモリ上に一時的に存在してDBに同期 したら削除するもの(揮発データ)]
  60. 60. キャッシュデータの種類 • メモリ上にのみ存在してDBには存在し ないもの(非永続データ) • メモリ上にもDBにも存在して同期が必 要な物(永続データ) • [メモリ上に一時的に存在してDBに同期 したら削除するもの(揮発データ)] 同期方法要注意
  61. 61. 設計編 • キャッシュデータの種類 • メモリとDBの同期 • DB→メモリ • メモリ→DB • データの検索
  62. 62. メモリとDBの同期 • DBへの更新をどうメモリに反映させる か • メモリへの更新をどうDBに反映させる か • 一貫性は? • 性能は?
  63. 63. 設計編 • キャッシュデータの種類 • メモリとDBの同期 • DB→メモリ • メモリ→DB • データの検索
  64. 64. DB→メモリ • DBデータ更新時にDBトランザクショ ンとメモリの整合性に要注意
  65. 65. システム構成例 System1 System2 Coherence DB
  66. 66. システム構成例 System1 System2 Coherence DB 高スループット・低レスポンス タイムが求められる。 基本キャッシュアクセスのみ DBのCRUDが主処理 キャッシュアクセスはデータの同期用途 のみ
  67. 67. システム構成例 System1 System2 Coherence DB 高スループット・低レスポンス タイムが求められる。 基本キャッシュアクセスのみ DBが落ちても System1は運用する必 要がある DBのCRUDが主処理 キャッシュアクセスはデータの同期用途 のみ
  68. 68. システム構成例 System1 System2 Coherence DB 高スループット・低レスポンス タイムが求められる。 基本キャッシュアクセスのみ DB更新結果をどうキャッ シュに反映させるか
  69. 69. 次の例を考える Coherence DB account • user_id • first_name • last_name • email • password Account <value> • userId <key> • email • password
  70. 70. 次の例を考える Coherence DB Account <value> • userId <key> • email • password account • user_id • first_name • last_name • email • password Cacheのフィール ド∈ DBのフィール ド
  71. 71. DB更新結果をどうキ ャッシュに反映させる か • 案1: DB更新(キャッシュ上のフィールド 以外) + Write Through • 案2: DB更新(全フィールド) + キャッシ ュ書き込み • 案3: DB更新(全フィールド) + キャッシ ュ削除 + Read Through
  72. 72. 案1: DB更新(キャッシュ上のフィ ールド以外) + Write Through System2 Coherence DB Account更新処理
  73. 73. 案1: DB更新(キャッシュ上のフィ ールド以外) + Write Through System2 Coherence DB1. update first_name, last_name Account更新処理
  74. 74. 案1: DB更新(キャッシュ上のフィ ールド以外) + Write Through System2 Coherence DB 2. put Account 1. update first_name, last_name Account更新処理
  75. 75. 案1: DB更新(キャッシュ上のフィ ールド以外) + Write Through System2 Coherence DB 2. put Account 3. update user_id, email, password 1. update first_name, last_name Account更新処理 write through
  76. 76. 案1: DB更新(キャッシュ上のフィ ールド以外) + Write Through System2 Coherence DB 2. put Account 3. update user_id, email, password 1. update first_name, last_name Account更新処理 write through DB Transaction
  77. 77. 案1: DB更新(キャッシュ上のフィ ールド以外) + Write Through • Account更新処理の実装が複雑 • キャッシュ更新とDB更新の両方を意識する必要がある • JPAを使っており、accountテーブルの全フィールド更 新に比べて、一部フィールドのみ更新する実装コスト が高い • DB更新トランザクションとWrite Throughのトランザクシ ョンが別になり、片方DBでエラーが生じすると整合性が とれなくなる • キャッシュへputしたあとDBコミットするまでに整合性が とれていない期間がある • トランザクション(AOP)がロールバックされてもキャッ シュに残り続ける
  78. 78. 案2: DB更新(全フィールド) + キ ャッシュ書き込み System2 Coherence DB Account更新処理
  79. 79. 案2: DB更新(全フィールド) + キ ャッシュ書き込み System2 Coherence DB1. update user_id. email, password,first_ name, last_name Account更新処理
  80. 80. 案2: DB更新(全フィールド) + キ ャッシュ書き込み System2 Coherence DB 2. put Account 1. update user_id. email, password,first_ name, last_name Account更新処理
  81. 81. 案2: DB更新(全フィールド) + キ ャッシュ書き込み System2 Coherence DB 2. put Account 1. update user_id. email, password,first_ name, last_name Account更新処理 DB Transaction
  82. 82. 案2: DB更新(全フィールド) + キ ャッシュ書き込み • 実装は案1より低い • 案1同様キャッシュへputしたあとDBコ ミットするまでに整合性がとれていな い期間がある • トランザクション(AOP)がロールバッ クされてもキャッシュに残り続ける
  83. 83. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through System2 Coherence DB Account更新処理
  84. 84. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through System2 Coherence DB1. update user_id. email, password,first_ name, last_name Account更新処理
  85. 85. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through System2 Coherence DB1. update user_id. email, password,first_ name, last_name Account更新処理 2. remove Account
  86. 86. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through System2 Coherence DB1. update user_id. email, password,first_ name, last_name Account更新処理 2. remove Account DB Transaction
  87. 87. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through System1 Coherence DB Account参照処理
  88. 88. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through System1 Coherence DB Account参照処理 1. get Account
  89. 89. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through System1 Coherence DB Account参照処理 1. get Account remove済み
  90. 90. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through System1 Coherence DB Account参照処理 1. get Account 2. select user_id, email, password read through
  91. 91. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through System1 Coherence DB Account参照処理 1. get Account 2. select user_id, email, password read through 最新の情報を 取得できる
  92. 92. 案3: DB更新(全フィールド) + キ ャッシュ削除 + Read Through • 実装コストが低い • キャッシュモデル作成不要 • 対象のキーを使って削除するだけ • データ整合性が高い • データ不整合が起こる可能性が低い • 念のためDBコミット後もう一回削除で整合性 を高められる • キャッシュに初回読み込み時は連ポンスタイム が遅くなる • DB更新後にpreloadで対応
  93. 93. •どの案が適切はシステム 特性や業務内容次第
  94. 94. 参考 • Coherence 12cからHotCache機能が追加 • http://builder.japan.zdnet.com/sp_oracle/w eblogic_2013/35036005/2/
  95. 95. 設計編 • キャッシュデータの種類 • メモリとDBの同期 • DB→メモリ • メモリ→DB • データの検索
  96. 96. 設計編 • キャッシュデータの種類 • メモリとDBの同期 • DB→メモリ • メモリ→DB • データの検索
  97. 97. メモリ→DB • 高スループットが求められる箇所 →Write Behind • DBが落ちてもSystemをメモリだけで運 用する必要がある→Write Behind • そこまで性能を求められず、一貫性が 重要な箇所→Write Through
  98. 98. メモリ→DB • 高スループットが求められる箇所 →Write Behind • DBが落ちてもSystemをメモリだけで運 用する必要がある→Write Behind • そこまで性能を求められず、一貫性が 重要な箇所→Write Through 非同期でも問題ない か?
  99. 99. 非同期の問題点 System1 System2 Coherence DB
  100. 100. 非同期の問題点 System1 System2 Coherence DB 1. put Account
  101. 101. 非同期の問題点 System1 System2 Coherence DB 2. get Account
  102. 102. 非同期の問題点 System1 System2 Coherence DB 2. get Account WriteBehindの処理の前に、 データが参照されうる!
  103. 103. 非同期の問題点 System1 System2 Coherence DB 3. update Account
  104. 104. 非同期の問題点 System1 System2 Coherence DB 3. update Account 2. で取得した情報は最 新の状態ではない!
  105. 105. 非同期であることのトレード オフ •メモリ→DBを非同期にするこ とで、情報の不整合が必ず発 生しうる
  106. 106. 対処方法 •非同期で更新する項目に対し てSystem2からアクセスする パターンを全て洗い出し、ビ ジネス的なインパクトがない かを一つ一つお客様に確認す る
  107. 107. 設計編 • キャッシュデータの種類 • メモリとDBの同期 • DB→メモリ • メモリ→DB • データの検索
  108. 108. データの検索 • 基本はキーの検索 • 要件によってキー以外のフィールドで アクセスする必要がある • 例:Accountキャッシュに対してuserId(キ ー)だけでなく、emailでもアクセスしたい Account <value> • userId <key> • email
  109. 109. キー以外のフィールドによる検索 • 転置インデックス • 対象のフィールドの値がkeyで、対象のキャ ッシュのkeyがvalueなキャッシュを作る • RDBでないデータストアの検索手法として 一般的 • Filter • Coherence独自の検索機能 • 分散インメモリデータグリッド製品には大 体実装されている
  110. 110. 転置インデックス Account <value> • userId <key> • email AccountIndex • email <key> • userId <value> 転置インデックス key value A Account(userId=A, email=a@example.com) B Account(userId=B, email=b@example.com) key value a@example.com A b@example.com B
  111. 111. 転置インデックス Account <value> • userId <key> • email AccountIndex • email <key> • userId <value> 転置インデックス key value A Account(userId=A, email=a@example.com) B Account(userId=B, email=b@example.com) key value a@example.com A b@example.com B 転置
  112. 112. 転置インデックスを使っ たキャッシュアクセス アプリケーション AccountIndex Account
  113. 113. 転置インデックスを使っ たキャッシュアクセス アプリケーション AccountIndex get a@example.com A Account
  114. 114. 転置インデックスを使っ たキャッシュアクセス アプリケーション AccountIndex get a@example.com A get A Account(userId=A, email=a@example.com) Account
  115. 115. 転置インデックスの 作成• 手動で作成。CacheStoreに実装する。 • 主キャッシュのCRUD処理で転置インデック スを意識する必要がある • 主キャッシュ作成時に転置インデックスも 作成 • 主キャッシュロード時に転置インデックス もロード • 主キャッシュ更新時に転置インデックスも 更新 • 主キャッシュ削除時に転置インデックスも 削除
  116. 116. Filter • Coherence独自の検索処理 • SQLのLIKE文のように条件を指定でき る • 全キャッシュノードでパラレル処理
  117. 117. Filterの処理 アプリケーション search a@example.com Cache Cluster Filter Filter FilterFilter Filter
  118. 118. 比較 メリット デメリット 転置インデ ックス • 2hopで対象のキャッシュにア クセスできて高速 • 通常のキャッシュアクセス (put/get)の範疇で考えられる • CRUDそれぞれで転置イ ンデックス用のコーディ ングを意識する必要があ る • 一対多の場合複雑(排他処 理の検討、 EntryProcessor) Filter • 自動でインデックスを作成で きるのでコーディングがシン プル • Native APIの学習 • 全キャッシュノードに対 するパラレル処理になり、 負荷が大きい • 高スループットな処理に 向かない
  119. 119. Agenda • 今日の話のスコープ • 前提知識のおさらい • 設計編 • コーディング編 • チューニング編 • Advanced Topic
  120. 120. コーディング編 • キャッシュアクセスのコーディング • モックの利用
  121. 121. コーディング編 • キャッシュアクセスのコーディング • モックの利用
  122. 122. キャッシュアクセスのコー ディング • java.util.Mapを継承したkey/value インタフェースでアクセスできる と謳われている
  123. 123. キャッシュアクセスのコー ディング • java.util.Mapを継承したkey/value インタフェースでアクセスできる と謳われている
  124. 124. キャッシュアクセスのコー ディング • java.util.Mapを継承したkey/value インタフェースでアクセスできる と謳われている 業務アプリで直接Map インタフェースを使 うべきでない
  125. 125. 型不安全なキャッシュ アクセス • Mapインタフェースでキャッシュアクセス するとTypeUnsafeなコードになり、仕様 変更に弱い • キーの仕様変更は意外と起こる • キーがStringとは限らない • 該当のキャッシュを使用している箇所をト レースしにくい • 仕様変更すると実行時に ClassCastException連発…
  126. 126. 型安全なキャッシュ アクセスへ
  127. 127. 型安全なキャッシュ アクセスへ 実際にはここをSpringの CacheAbstract ion機構でさらに抽
  128. 128. 型安全なキャッシュ アクセスへ
  129. 129. 透過的キャッシュアクセス • だれでも好き勝手にキャッシュアクセ スすべきでない • 開発者全員がCoherenceを学ぶわけで はない • 明示的なキャッシュアクセスは性能要 件が厳しいところに絞り、その他は透 過的にキャッシュアクセスすべし • AOPなどを活用
  130. 130. 透過的キャッシュアク セスの利用例 System1 System2 Coherence DB
  131. 131. System2 Coherence DB1. update user_id. email, password,first_ name, last_name Account更新処理(案3) 2. remove Account DB Transaction 透過的キャッシュアク セスの利用例
  132. 132. System2 Coherence DB1. update user_id. email, password,first_ name, last_name 2. remove Account DB Transaction 透過的キャッシュアク セスの利用例 ここを開発者に意識 させたくない Account更新処理(案3)
  133. 133. System2 Coherence DB 1. update user_id. email, password,first_ name, last_name 2. remove Account DB Transaction 透過的キャッシュアク セスの利用例 Account更新処理(案3)
  134. 134. System2 Coherence DB 1. update user_id. email, password,first_ name, last_name 2. remove Account DB Transaction 透過的キャッシュアク セスの利用例 キャッシュ削除 はAOPで実装 Account更新処理(案3)
  135. 135. System2 Coherence DB 1. update user_id. email, password,first_ name, last_name 2. remove Account DB Transaction 透過的キャッシュアク セスの利用例 System2の開発者 はここだけ意識 Account更新処理(案3)
  136. 136. コーディング編 • キャッシュアクセスのコーディング • モックの利用
  137. 137. モックの利用 • Coherenceは使い方が簡単でも必ずは まる(起動の仕方、ネットワーク、キャ ッシュモデルの最新化し忘れ等・・) • -Dtangosol.coherence.distributed.localstorage=false • 開発が安定していない状態で全開発者 がCoherenceを起動すると混乱に陥る
  138. 138. 開発段階 System1 System2 Coherence DB
  139. 139. 開発段階 System1 System2 Coherence DB System2の開発中は Coherenceを意識させたくな い
  140. 140. 開発段階 System1 System2 Mock DB Cacheのモック化
  141. 141. 開発段階 System1 System2 Mock DB CacheRepository再活躍!
  142. 142. 開発の鉄則 • Step by Stepでビルドアップしましょう • いきなり全部作ろうとしてはダメ
  143. 143. Agenda • 今日の話のスコープ • 前提知識のおさらい • 設計編 • コーディング編 • チューニング編 • Advanced Topic
  144. 144. Coherenceのチューニング • Keyアクセスは基本的に速い • 1 hop = 1 msec と見積もって良い
  145. 145. Coherenceのチューニング • Coherenceのチューニング = いかにし てhop数を減らすか • 複数に渡るキャッシュアクセスをでき るだけまとめる
  146. 146. チューニング編 • データアフィニティ • EntryProcessor
  147. 147. チューニング編 • データアフィニティ • EntryProcessor
  148. 148. データアフィニティ • 関連するキャッシュデータを物理的に 同じノードに配置させる
  149. 149. データアフィニティ がない場合 アプリケーション Cache Cluster AccountIndex (key=a@example.co m) Account (key=A)
  150. 150. データアフィニティ がない場合 アプリケーション 1. get a@example.com Cache Cluster AccountIndex (key=a@example.co m) Account (key=A) A
  151. 151. データアフィニティ がない場合 アプリケーション 1. get a@example.com Cache Cluster AccountIndex (key=a@example.co m) Account (key=A) 2. get A A Account(key=A)
  152. 152. データアフィニティ がない場合 アプリケーション 1. get a@example.com Cache Cluster AccountIndex (key=a@example.co m) Account (key=A) 2. get A A Account(key=A) 2 hop必要
  153. 153. データアフィニティ がある場合 アプリケーション Cache Cluster AccountIndex (key=a@example.co m) Account (key=A)
  154. 154. データアフィニティ がある場合 アプリケーション Cache Cluster AccountIndex (key=a@example.co m) Account (key=A) 同じノードに 配置される
  155. 155. データアフィニティ がある場合 アプリケーション 1. get a@example.com Cache Cluster AccountIndex (key=a@example.co m) Account (key=A)A
  156. 156. データアフィニティ がある場合 アプリケーション 1. get a@example.com Cache Cluster AccountIndex (key=a@example.co m) Account (key=A) 2. get A A Account(key=A)
  157. 157. データアフィニティ がある場合 アプリケーション 1. get a@example.com Cache Cluster AccountIndex (key=a@example.co m) Account (key=A) 2. get A A Account(key=A) 結局2 hop必要・・・
  158. 158. チューニング編 • データアフィニティ • EntryProcessor
  159. 159. EntryProcessor • Cacheサーバー側に処理を置く • DBにおけるStoredProcedureに相当 • 複数のキャッシュモデルをAtomicに操 作
  160. 160. EntryProcessor アプリケーション Cache Cluster Entry Processor
  161. 161. EntryProcessor アプリケーション process Cache Cluster Entry Processor
  162. 162. データアフィニティ+ EntryProcessor アプリケーション process Cache Cluster AccountIndex (key=a@example.co m) Account (key=A) Entry Processor
  163. 163. データアフィニティ+ EntryProcessor process Entry Processor AccountIndex (key=a@example.co m) Account (key=A)
  164. 164. データアフィニティ+ EntryProcessor process Entry Processor AccountIndex (key=a@example.co m) Account (key=A) 1. get a@example.com 2. get A A Account(key=A) Account(key=A)
  165. 165. データアフィニティ+ EntryProcessor process Entry Processor AccountIndex (key=a@example.co m) Account (key=A) 1. get a@example.com 2. get A A Account(key=A) Account(key=A) EntryProcessor内では、 処理実行中の物理ノー ドにアクセスできる
  166. 166. データアフィニティ+ EntryProcessor process Entry Processor AccountIndex (key=a@example.co m) Account (key=A) 1. get a@example.com 2. get A A Account(key=A) Account(key=A) 1 hopで処理完了
  167. 167. EntryProcessorの注意 点 • コーディングが普通のキャッシュアク セスより煩雑になる • Coherenceと密結合になり、テスタビ リティが下がる • キャッシュサーバーにデプロイする必 要があるので開発効率が下がる
  168. 168. EntryProcessorの注意 点 • 速いからといって何でもかんでも EntryProcessorで実装すればよいという ものではない • 性能テストで性能要件が満たせない場 合に検討 • あとでEntryProcessorに以降できるよう な設計を予め行っておく
  169. 169. チューニングの鉄則 • 必要になるまでチューニングすべきで ない • 性能テストで測定してから最適化 • 予め実施すべきはスケーラビリティの 確保のみ 「早すぎる最適化は諸悪の根源であ る」 by ドナルド・クヌース
  170. 170. チューニングの鉄則 • 必要になるまでチューニングすべきで ない • 性能テストで測定してから最適化 • 予め実施すべきはスケーラビリティの 確保のみ Coherenceを採用すること自体 「早すぎる最適化は諸悪の根源であ る」 by ドナルド・クヌース
  171. 171. Agenda • 今日の話のスコープ • 前提知識のおさらい • 設計編 • コーディング編 • チューニング編 • Advanced Topic
  172. 172. 初期ローダ • DBに格納されている数億件のデータを 初回にプレロードしたい
  173. 173. 初期ローダ • DBに格納されている数億件のデータを 初回にプレロードしたい • 数時間以内で
  174. 174. 普通の考え DBアプリケーション put Cache Cluster select
  175. 175. 普通の考え DBアプリケーション put Cache Cluster select 完了するのに 数日かかる
  176. 176. 普通の考え+ DBアプリケーション put Cache Cluster select where mod(id, n) = m アプリケーション アプリケーション …
  177. 177. 普通の考え+ DBアプリケーション put select where mod(id, n) = m アプリケーション アプリケーション … 多少スケールするがアプリケーシ ョンサーバー数と管理がネック
  178. 178. InvocationService • キャッシュサーバーにタスクを依頼 • 非同期処理でタスク実行状況をobserve できる
  179. 179. InvocationService • キャッシュサーバーにタスクを依頼 • 非同期処理でタスク実行状況をobserve できる EntryProcessorは同期のみ対応
  180. 180. InvocationService • キャッシュサーバーにタスクを依頼 • 非同期処理でタスク実行状況をobserve できる たくさんいるキャッシュサーバーのリソース を使ってデータのロードを行う
  181. 181. InvocationService による分散処理 DBアプリケーション Cache Cluster InvocationServi ce put 各キャッシュノード にTaskをputする
  182. 182. InvocationService による分散処理 DBアプリケーション Cache Cluster Task Task InvocationServi ce put Task Task Task 各キャッシュノード にTaskをputする
  183. 183. InvocationService による分散処理 DBアプリケーション Cache Cluster select where mod(id, n) = m Task Task InvocationServi ce put Task Task Task Task内でDBからロ ードしキャッシュへ putする
  184. 184. InvocationService による分散処理 DBアプリケーション Cache Cluster select where mod(id, n) = m Task Task InvocationServi ce put Task Task Task あとはSQLチューニ ング
  185. 185. まとめ • 前提知識のおさらい • Cache方式 • DB連携方式 • 設計編 • キャッシュデータの種類 • メモリとDBの同期 • データの検索 • コーディング編 • キャッシュアクセスのコーディング • モックの利用 • チューニング編 • データアフィニティ • EntryProcessor • Advanced Topic • InvocationServiceによる初期ロード
  186. 186. おわりに • Coherenceは上手に使うとハイパフォーマンスを 実現してくれる良い製品 • 本発表のパターンがオンリー1なわけではない • 要件によってベストなパターンは変わりうる • カタログスペックを信用しすぎず、コンサルタン トとよく相談して方式を定めるべき • コンサルタントなしで利用すべきでない・・ • 細かいオプション多すぎ・・・(非推奨なものも 多数)

×