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.

20190523 IMC meetup-IMDG&DS

2019/5/23 In-memory Computing Meetup Vol.1の発表資料

  • Be the first to comment

  • Be the first to like this

20190523 IMC meetup-IMDG&DS

  1. 1. インメモリーデータグリッドと分散処理 2019.5.23 Thu. In-memory Computing Meetup Vol.1 #imtech_jp
  2. 2. 自己紹介 山河 征紀 ウルシステムズ株式会社 マネージングコンサルタント { “分野” : ”金融系”, “得技” : [“分散処理”, “インメモリー処理”], “その他” : ”サンデープログラマー” “その他” : ”Apache Geodeコミッター” }
  3. 3. インメモリー処理はどれ? 2 • 全部インメモリー処理だけど・・・ APP APP APP DB インメモリーDB DG 処理 処理 処理 ディスク キャッシュ インメモリーDB インメモリー処理 今日のトークテーマ! キャッシュ
  4. 4. 理想的なインメモリー処理 Part 1
  5. 5. インメモリー処理は速い! • APP中のメモリーだけで処理が完結 4 APP(プロセス) 処理 インメモリー処理 オブジェクト 作成 更新 参照 APP(プロセス) 処理 RDB ≠インメモリー処理 (RDBの例) 通信がボトルネックに… オブジェクト
  6. 6. APPのメモリーには上限がある • データ量が多くなるとGCによる性能劣化、最悪の場合OOMEに! 5 APP(プロセス) 処理 オブジェクト
  7. 7. そこでインメモリーデータグリッド! 6 APP#1 APP#2 APP#3 APP#4 APP#5 APP#6 データA データB データC データD データE
  8. 8. そこでインメモリーデータグリッド! • インメモリーデータグリッドは複数APPのメモリーへデータを分散 7 APP#1 APP#2 APP#3 APP#4 APP#5 APP#6 データA データB データC データD データE 耐障害性 永続化 (オプション) メモリーへのデータ保持であっても システムとして求められる機能は インメモリーデータグリッドがサポート 分散による無限のスケーラビリティー
  9. 9. 使い方はとても簡単 • java.util.Mapを使用してる感覚でデータが分散される 8 Cache cache = new CacheFactory() .set("cache-xml-file", “cache.xml").create(); Region<Long, User> region = cache.getRegion(“Users"); Long userId = 1; User user = new User(…); // データ登録 region.put(userId, user); // データ取得 User value = region.get(userId); // データ削除 region.remove(userId); ※リージョンはRDBにおけるテーブルみたいなもの
  10. 10. APP#2 APP#1 単純にデータを分散してしまうとメモリー使用量は均等になるが… • 通信が発生して思ったより速くならない 9 処理 ユーザー1の新規注文 ユーザー#2 注文#1 ・ユーザー#1 ・商品B ・5個 注文#3 ・ユーザー#2 ・商品C ・25個 処理 ユーザー2の新規注文 ユーザー#1 注文#2 ・ユーザー#2 ・商品A ・10個 注文#4 ・ユーザー#2 ・商品D ・300個 例:ECサイトでユーザーマスターと過去の注文情報をチェックしつつ、注文処理を行う場合
  11. 11. 理想の分散処理 • 高速な分散処理を行うためにはデータがどこに配置されるかが重要! 10 APP#2 APP#1 処理 ユーザー1の新規注文 ユーザー#1 注文#1 ・ユーザー#1 ・商品B ・5個 注文#3 ・ユーザー#2 ・商品C ・25個 処理 ユーザー2の新規注文 ユーザー#2 注文#2 ・ユーザー#2 ・商品A ・10個 注文#4 ・ユーザー#2 ・商品D ・300個 例:ECサイトでユーザーマスターと過去の注文情報をチェックしつつ、注文処理を行う場合
  12. 12. データはどのように分散される? • 真のインメモリー処理を実現するためにはAPPで使用するオブジェクトを一か所に集める 11 同一ユーザーIDの注文データは 同じAPPに分散されるようにする APP#1 注文#1 ・ユーザー#1 … APP#2 注文#6 ・ユーザー#2 … APP#3 注文#3 ・ユーザー#3 … 注文#7 ・ユーザー#3 … APP#4 注文#4 ・ユーザー#4 … 注文#8 ・ユーザー#4 … APP#1 注文#1 ・ユーザー#1 … 注文#5 ・ユーザー#1 … APP#2 注文#2 ・ユーザー#2 … 注文#6 ・ユーザー#2 … APP#3 注文#3 ・ユーザー#3 … 注文#7 ・ユーザー#3 … APP#4 注文#4 ・ユーザー#4 … 注文#8 ・ユーザー#4 … 注文#2 ・ユーザー#2 … 注文#5 ・ユーザー#1 … デフォルトではキーのハッシュで ランダムに分散される
  13. 13. データの分散を意図的行う場合の実装例 • キーオブジェクトでPartitionResolverを実装してリージョンの設定に指定する 12 public class OrderKey implements PartitionResolver { private Long userId; private Long orderId; … @Override public Serializable getRoutingObject(EntryOperation op) { return this.userId; } } <cache> <region name=“Orders“ refid="PARTITION"> <region-attributes> <partition-attributes redundant-copies="1"> <partition-resolver name=“OrderUserIdPartitionResolver"> <class-name>myPackage.OrderKey</class-name> </partition-resolver> </partition-attributes> </region-attributes> </region> </cache> リージョン設定キーオブジェクト実装
  14. 14. 複数リージョンのデータはどのように分散されるか? • APPで使用する複数リージョンのオブジェクトを一か所に集める 13 同一ユーザーIDの注文データは 同じAPPに分散されるようにする APP#1 注文#1 ・ユーザー#1 … APP#2 注文#2 ・ユーザー#2 … APP#3 注文#3 ・ユーザー#3 … APP#4 注文#4 ・ユーザー#4 … それぞれのデータに関連はなく ランダムに分散される ユーザー#2ユーザー#1 ユーザー#3 ユーザー#4 APP#1 注文#4 ・ユーザー#4 … APP#2 注文#3 ・ユーザー#3 … APP#3 注文#1 ・ユーザー#1 … APP#4 注文#2 ・ユーザー#2 … ユーザー#2ユーザー#1 ユーザー#3 ユーザー#4
  15. 15. 複数リージョンのデータ分散を意図的行う場合の実装例 • 2つのリージョンには関連があることを示すキーワード「colocated-with」を指定する 14 <cache> <region name=“Users“ refid="PARTITION"> <region-attributes> <partition-attributes redundant-copies="1“ /> </region-attributes> </region> <region name=“Orders“ refid="PARTITION"> <region-attributes> <partition-attributes redundant-copies="1“ colocated-with=“Users"> <partition-resolver name=“OrderUserIdPartitionResolver"> <class-name>myPackage.OrderKey</class-name> </partition-resolver> <partition-attributes> </region-attributes> </region> </cache> Colocated-withを設定する 2つするリージョンのキーは同じ になっていないといけない
  16. 16. ここまでのまとめ • 真のインメモリー処理を実現するためには… 15 Geode等のインメモリーデータグリッドを使用すると良い 単にインメモリーデータグリッドを使えば良いというわけではない データの分散を意識して通信を極力発生しないようにする必要がある
  17. 17. インメモリー処理適用時の課題 ~ ケース1:株式取引システム ~ Part 2
  18. 18. 株式取引システム(ビフォー) • 高い処理性能と耐障害性が必須条件のミッションクリティカルシステム 取引所接続 プロトコル変換 など 注文管理 など 注文入力 約定一覧表示 など データベース フロント AP 注文管理 システム LH LH取引所接続 モジュール LH LH取引所接続 モジュール 注文管理 システム ・・・ フロント AP フロント AP 株、先物等 注文管理 システム 17 核となるシステムにインメモリーデータ グリッドを採用し、インメモリー処理 による高速処理を実現したい! ・・・
  19. 19. うちはC#なんですけど 大丈夫ですよね? 18
  20. 20. Apache GeodeでC#は使えるのか? • サーバーはJava実装 • C++&.NET Appに「ネイティブキャッシュ」を提供 19 Apache Geodeドキュメントより抜粋
  21. 21. つまり… • C# APPでは今回のテーマのインメモリー処理が出来ない 20 C# APP RDB C# APP DG C# APP DG 一般的なAPP+RDB構成のC# APP この構成を取ることは出来るが 通信が発生してしまう処理 処理 この構成を取ることは出来ない Javaのサーバーを立てる必要がある 処理ビフォー 理想 現実
  22. 22. そこでFunction Execution! • 任意の処理をデータの存在する場所で実行する機能 21 C# APP (クライアント) ①クライアントは データと実行したい 処理を指定 DG#1 データA DG#2 データB DG#3 データC 処理 (データA) 処理 (データB) 処理 (データC) ②指定された処理がデータのある ノードで並列に実行される
  23. 23. C# APPでもインメモリー処理が出来る • 特にパフォーマンスの求められる処理をFunction Executionを用いて実装 22 C# APP DG処理 C# APP RDB C# APP DG C# APP DG 一般的なAPP+RDB構成のC# APP この構成を取ることは出来るが 通信が発生してしまう処理 処理 この構成を取ることは出来ない Javaのサーバーを立てる必要がある 処理ビフォー 理想 現実 アフター Function Execution C#で実装していた処理をJavaで再実装して インメモリー処理を可能とした
  24. 24. Function Executionのコード例 • FunctionをJavaで実装。C#は注文情報を渡して呼び出すだけ 23 var cacheFactory = new CacheFactory(); var cache = cacheFactory.Create(); var region = cache.GetRegion(“Orders"); … ArrayList orders = new ArrayList(); orders.Add(order); var exc = Client.FunctionService<object> .OnRegion(region); Client.IResultCollector<object> rc = exc.WithArgs<object>(orders) .Execute(“ExecuteOrder"); ICollection<object> res = rc.GetResult(); public class ExecuteOrder implements Function { @Override public void execute(FunctionContext context) { Order order = (Order) context.getArguments(); // 注文処理(リージョン参照・登録・更新) // インメモリー処理 … context.getResultSender().lastResult(result); } } サーバー側実装(Java)呼び出し側実装(C#)
  25. 25. ・・・ 株式取引システム(アフター) • インメモリーデータグリッドの採用により高い処理性能と耐障害性を両立 フロント AP フロント AP 注文管理 システム フロント AP 注文管理 システム ・・・ ・・・ 注文管理 システム フロント AP フロント AP キャッ シュ キャッ シュ キャッ シュ キャッ シュ キャッ シュ LH キャッ シュ LH キャッ シュ 取引所接続 モジュール キャッ シュ LH キャッ シュ LH キャッ シュ 取引所接続 モジュール キャッ シュ データベース 非同期 ApacheGeode
  26. 26. インメモリー処理の実業務への適用 ~ ケース2:リアルタイム債券時価計算システム ~ Part 3
  27. 27. リアルタイム債券時価計算システム(ビフォー) • 各システムに分散している債券時価計算ロジックを1か所に集約して計算サーバーを構築 時価計算結果 銘柄情報 顧客時価 配信システム 債券計算 ロジック 顧客時価計算結果 マーケット情報 報告 システム 顧客時価 提供 ・・・ 債券計算 ロジック ・・・ 計算 各システムで重複して作成して いる時価計算ロジックを集約 して高速なリアルタイム高速計 算サーバーを立てたい! リスク管理 システム 計算結果 債券計算 ロジック
  28. 28. C++の時価計算ロジックは そのまま使いたいんだけど… 27
  29. 29. つまり… • C++時価計算ロジックをそのまま使おうとすると今回のテーマのインメモリー処理が出来ない 28 C++ APP RDB C++ APP DG 一般的なAPP+RDB構成のC++ APP この構成を取ることは出来るが 通信が発生してしまう処理 この構成を取ることは出来るがFunction ExecutionはJava実装のため使えない 処理ビフォー 現実 C++ APP DG処理理想 Function Execution 時価計算ロジック 時価計算ロジック 時価計算ロジック
  30. 30. キャッシュのPush更新! • 時価計算時に参照するデータが最新になっていれば良い 29 C++ APP DG処理 キャッシュ ①変更があれば キャッシュを更新 ②C++ APPからは常にメモリー上 のキャッシュを参照する キャッシュは変更があれば更新さ れるため、常に最新の状態となる 銘柄情報 マーケット情報 リアルタイム リアルタイム
  31. 31. C++ APPでもインメモリー処理が出来る • C++APP内のキャッシュを常に最新に保つ 30 C++ APP RDB C++ APP DG 一般的なAPP+RDB構成のC# APP この構成を取ることは出来るが 通信が発生してしまう処理 この構成を取ることは出来るがFunction ExecutionはJava実装のため使えない 処理ビフォー 現実 C++ APP DG処理理想 Function Execution C++ APP DG処理 キャッシュアフター クライアントキャッシュを常に最新に保つ設定 によりインメモリー処理を可能とした 非同期Push更新
  32. 32. 時価計算システム リアルタイム債券時価計算システム(アフター) • インメモリーデータグリッドを内包する計算サーバーを新設 • 高い処理性能とスケーラビリティを実現した 31 時価計算サーバー 時価計算サーバー 時価計算サーバー 時価計算サーバー 銘柄情報 Apache Geode マーケット情報 Apache Geode 分散処理 キュー Apache Geode 債券時価計算 ロジック (C++) リアルタイム リアルタイム 銘柄管理 システム 時価計算 クライアント 計算 顧客時価 配信システム リスク管理 システム
  33. 33. まとめ Part 4
  34. 34. まとめ 33 インメモリー処理は速い メモリーの上限を突破させてくれるのがインメモリーデータグリッド インメモリーデータグリッドを使うと分散処理は出来るが、 通信が発生しないようにしないと真のインメモリー処理にはならない 実プロジェクトでは理想的な構成に出来ない場合もあるが、 インメモリーデータグリッドの機能を活用すれば理想に近づける
  35. 35. Thank you! 34

×