インメモリーで超高速処理を実現する場合のカギ

ULS
Copyright © 2011-2016 UL Systems, Inc. All rights reserved.
Proprietary & Confidential Powered by
Apache GEODE Meetup Tokyo #2
インメモリーで超高速処理を実現する場合のカギ
2016/10/11
ウルシステムズ株式会社
http://www.ulsystems.co.jp
mailto:info@ulsystems.co.jp
Tel: 03-6220-1420 Fax: 03-6220-1402

ULS
Proprietary & Confidential Powered by 1
About Me
山河征紀
Business
Private
• GEODE歴：9年（Since 2008）
• GEODEバグ報告数：nnn 件
• マラソン
• 横浜マラソン2016：4h17m
• 目標は今年度中のサブ4
• 登山
• 目標はココ

ULS 2
インメモリーで
超高速処理を実現する場合のカギ

ULS
処理に応じてデータの分散を繰り返す
Apache Geodeでの大量データ処理
処理A 処理B 処理C
パーティション
リージョン
リージョン
リージョン
リージョン
どうしてもメモリーにのらないデータはDiskやRDBへ保持
高速に処理を行うためには、
たくさんのオブジェクトをメモリーへのせることが重要！

ULS
リージョンのおさらい
リージョンとは分散するデータを保持する入れ物のこと
データの特性によってレプリケーションとパーティションを
使い分ける
パーティションレプリケーション
すべてのマシンで同一のデータ
を保持する
何れかのマシンにデータが存在
する
今回の例で言うと
処理への入出力データは「パーティションリージョン」
マスターデータは「レプリケーションリージョン」

ULS
データは、Javaのヒープメモリ上にJavaのオブジェクトと
して管理される
Geodeにおけるデータ管理
JVM
Cache
Region
Key Value
ABC
GGG
XYG
Region
…
Region
…
• インメモリデータへのエントリポイント
• アプリケーションはキャッシュを介して、データへの一連の操作を行う
• 任意のリージョンにより構成
• 論理的なデータのグループ（RDBにおけるテーブルのイメージ）
• Key-Value形式でのデータ管理
• 任意のオブジェクトに対して、一意のKeyを指定
• スキーマの概念はなく、任意のオブジェクトを格納
Cache
Region
public class Employee {
private int employeeNo;
private String firstName;
private String lastName;
private String deptCode;
・・・
・・・
}

ULS
1. Javaオブジェクトのメモリー使用量
2. 通信レイテンシー
今日、お話したいこと
リージョン
リージョン
リージョン
リージョン

ULS 7
Javaオブジェクトのメモリー使用量

ULS
Apache Geodeのメモリー使用量
1億件のオブジェクトをデータ分散してみると…
public class ObjectPerson implements Serializable {
private Integer id;
private Integer age;
private Address address;
private List<String[]> phoneNumbers;
private List<String> emails;
private Date createdAt;
private Date updatedAt;
…（setter/getter略）…
JVM
サーバ
JVM
サーバ
JVM
サーバ
JVM
サーバ
1億件
データ分散
（パーティション）
1オブジェクト
のサイズ
200byte
（感覚値）
全体サイズ
20GB
（200byte×1億件）
1Nodeあたり
メモリ使用量
5GB
（20GB÷4Node）
見積値
（感覚）

ULS
Apache Geodeのメモリー使用量
予想を大幅に超えるメモリー使用量！
0.0 GB
20.0 GB
40.0 GB
60.0 GB
80.0 GB
100.0 GB
120.0 GB
140.0 GB
160.0 GB
180.0 GB
見積値実測値
Server1 Server2 Server3 Server4
見積値の
約9倍！
44.2 GB
45.7 GB
44.5 GB
45.5 GB
179.9 GB
20.0 GB

ULS
なぜJavaオブジェクトが肥大化するのか
Javaでは、フィールドが何もないオブジェクトを生成するだ
けでも、メモリーを消費してしまう
public class EmptyObject {
}
public class NullSetObject {
private String str01 = null;
(略)
private String str50 = null;
private Integer int01 = null;
(略)
private Integer int50 = null;
}
String, Integerそれぞれ50個あり、
すべてnullを設定したオブジェクト
フィールドがひとつもない
オブジェクト
それぞれ100万オブジェクト生成し、生成にかかった時間とメモリー使用
量を測定した結果は…
EmptyObject NullSetObject
生成時間 17 ms 382 ms
メモリー使用量 33.5 MB 430.2 MB
22倍も遅い
13倍も多い

ULS
Stringのために88Byte必要
int配列4Byteのために32Byte必要
なぜJavaオブジェクトが肥大化するのか
オブジェクトを1つ生成する毎に、標準のメタデータが必要！
メタデータ：クラスポインター、状態フラグ、同期情報フラグなど
標準のメタデータ int
0 24 28 [Byte]
標準のメタデータサイズ int
0 24 32 [Byte]36
標準のメタデータ Obj固有のメタデータポインタ char char標準のメタデータサイズ char ・・・
0 5624 48 0 3824 32
int用の4Byteのために24Byte必要
数値をIntegerで保持する場合
数値配列をInteger配列で保持する場合
Stringの場合

ULS
jmapによりオブジェクト数を確認してみると…
num #instances #bytes class name
----------------------------------------------
1: 28000397 896018224 [Ljava.lang.String;
2: 14000714 812049584 [Ljava.lang.Object;
3: 28000000 672000000 java.util.Date
4: 14000012 336000288 java.util.ArrayList
5: 7000000 336000000 geodemeetup2.object.optimize.person.ObjectPerson
6: 14000128 224002048 java.lang.Integer
7: 7000000 224000000 geodemeetup2.object.optimize.person.ObjectAddress
8: 7000001 168001040 [Ljava.lang.Integer;
9: 5254 616936 [C
10: 575 126992 [B
11: 5171 124104 java.lang.String
12: 614 69544 java.lang.Class
13: 879 35160 java.util.LinkedHashMap$Entry
14: 785 31400 java.util.TreeMap$Entry
15: 305 19520 java.net.URL
16: 529 16928 java.util.HashMap$Node
17: 130 12480 java.util.jar.JarFile$JarFileEntry
18: 24 11584 [Ljava.util.HashMap$Node;
19: 138 11040 [Ljava.util.WeakHashMap$Entry;
20: 271 10840 java.lang.ref.Finalizer
21: 135 8640 java.util.jar.JarFile
…
Total 119019230 3669289272
Dateだけで
670MB！
Integerと配列
を合わせて
390MB！

ULS
オブジェクトではなくプリミティブ型を使用
プリミティブ型を使用すれば、このオーバーヘッドは削減で
きる
public class ObjectPerson implements Serializable {
private Integer id;
private Integer age;
private Address address;
private List<String[]> phoneNumbers;
private List<String> emails;
private Date createdAt;
private Date updatedAt;
…（setter/getter略）…
private int id;
private int age;
private long createdAt;
private long updatedAt;
日付はlongで
表せるので

ULS
プリミティブ型利用によりメモリー使用量削減
----------------------------------------------
3: 7000000 392000000 geodemeetup2.object.optimize.person.PrimitiveObjectPerson
4: 14000007 336000168 java.util.ArrayList
5: 7000000 280000000 geodemeetup2.object.optimize.person.PrimitiveObjectAddress
6: 7000101 168003768 [I
7: 2639 402240 [C
11: 9 25008 [B
13: 158 10112 java.net.URL
14: 283 6792 java.io.ExpiringCache$Entry
15: 69 4968 java.lang.reflect.Field
16: 256 4096 java.lang.Integer
17: 10 3760 java.lang.Thread
…
Total 77009353 2884700216
Date、Integerは
出現しなくなった
オブジェクト数、
バイト数ともに削減
（約780MB）Total 119019230 3669289272
before

ULS
オブジェクト内のすべてのフィールドを1つのバイト配列とし
て保持！
通常のオブジェクト
究極のオーバーヘッド削減コンセプト
Person
String firstName
String lastName
Integer age
Address address
Integer[] phoneNumber
Taro
Yamada
32
03 1234 5678
Taro
Yamada
32
03 1234 5678
YY-ZZ ABCマンションNNN2 1 2神奈川県横浜市XX区YY-ZZ ABCマンションNNN
1つのバイト配列としたオブジェクト
列挙型
共有オブジェクト
Person
byte[] data Taro Yamada 32 0312345678
String[] prefectureList 東京都,神奈川県,埼玉県,…
String[] cityList 横浜市,川崎市,…
YY-ZZ ABCマンションNNN2 1 2
1つのbyte配列として
保持することで
オーバーヘッドを0へ
リスト型データの場合、
内部的にリスト番号で
保持することにより
さらにデータを削減

ULS
バイト配列オブジェクトのメモリー使用量
Javaのオーバーヘッドを大幅に削減！
45.5 GB
8.4 GB
44.5 GB
8.4 GB
45.7 GB
8.4 GB
44.2 GB
8.7 GB
0.0 GB
20.0 GB
40.0 GB
60.0 GB
80.0 GB
100.0 GB
120.0 GB
140.0 GB
160.0 GB
180.0 GB
実測値（オブジェクト）実測値（バイト配列）
約81%
削減
179.9 GB
33.9 GB

ULS
加えて、GC処理の発生を大幅に低減
メモリー使用量の削減のみならず、GCへの影響を極小化し
てパフォーマンスも向上！
22.8 sec
12.2 sec
22.9 sec
12.1 sec
22.8 sec
12.1 sec
22.8 sec
12.0 sec
0.0 sec
10.0 sec
20.0 sec
30.0 sec
40.0 sec
50.0 sec
60.0 sec
70.0 sec
80.0 sec
90.0 sec
100.0 sec
オブジェクトバイト配列
GC時間
オブジェクト数が少ないため
GC時間も少ない
91.2 sec
48.3 sec

ULS
バイト配列オブジェクトの実装
オブジェクト内部のデータはバイト配列のみ
public class ObjectPerson
implements Serializable {
private Integer id;
…
public class BinaryPerson
implements Externalizable {
private byte[] data = new byte[150];
通常のオブジェクトの場合バイト配列オブジェクトの場合

ULS
アクセサ（setter,getter）呼び出し時にバイト配列を検索
public void setId(Integer id) {
this.id = id;
}
public Integer getId() {
return id;
}
public void setId(Integer id) {
int offset = 0;
int val = id.intValue();
data[offset] = (byte) (val >>> 24);
data[offset + 1] = (byte) (val >>> 16);
data[offset + 2] = (byte) (val >>> 8);
data[offset + 3] = (byte) (val);
}
public Integer getId() {
int offset = 0;
int val = 0;
for (int i = 0; i < 4; i++)
val = (val << 8) + (data[offset + i] & 0xff);
return Integer.valueOf(val);
}

ULS
アクセサ（setter,getter）呼び出し時にバイト配列を検索
public void setFirstName(
String firstName) {
this.firstName = firstName;
}
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
int offset = 22;
String val = firstName;
byte[] bytes = val.getBytes();
int newLen = data.length + 2 + bytes.length;
byte[] newBytes = new byte[newLen];
System.arraycopy(data, 0, newBytes, 0, data.length);
data = newBytes;
data[offset] = (byte) (bytes.length >>> 8);
data[offset + 1] = (byte) (bytes.length);
System.arraycopy(data, offset + 2,
bytes, 0, bytes.length);
}
public String getFirstName() {
int offset = 22;
int len = 0;
for (int i = 0; i < 2; i++)
len = (len << 8) + (data[offset + i] & 0xff);
byte[] byteString = new byte[(short) len];
System.arraycopy(data, offset + 2, byteString, 0, len);
return new String(byteString);
}

ULS
バイト配列オブジェクトのjmap
----------------------------------------------
1: 7000572 1568125136 [B
2: 7000000 112000000 geodemeetup2.object.optimize.person.BinaryPerson
4: 5264 617488 [C
9: 305 19520 java.net.URL
11: 529 16928 java.util.HashMap$Node
12: 130 12480 java.util.jar.JarFile$JarFileEntry
13: 24 11584 [Ljava.util.HashMap$Node;
14: 138 11040 [Ljava.util.WeakHashMap$Entry;
15: 269 10760 java.lang.ref.Finalizer
16: 135 8640 java.util.jar.JarFile
…
Total 14019353 1709288312
ほぼバイト配列
のみ！
もとのオブジェクトから
約2GB削減！
Total 119019230 3669289272
before

ULS 22
通信レイテンシー

ULS
Apache GeodeではPut等のデータ操作処理においてサーバ
を跨いだ通信が発生
データ分散による通信
サーバ#1
オブジェクト
シリアライズ処理
バイト配列
サーバ#2
オブジェクト
デシリアライズ処理
バイト配列
通信
Put等
Event Latency
CPUキャッシュアクセス（L2） 3 ns
メモリーアクセス 120 ns
SSDディスク I/O 150,000 ns
同一データセンター内通信 500,000 ns
ディスク I/O 10,000,000 ns
通信は、メモリーで完
結する処理に比べ、
4000倍以上も開きが
ある

ULS
高速処理を行うためには、次の2つが重要！
高速処理を実現する上で大事なこと
パフォーマンス
シリアライズ
処理時間
通信時間＝＋
高速シリアライザー
通信プロトコル
と
コンパクトなデータ

ULS
シリアライズ処理とは
メモリー上に存在する情報を、ネットワークを超えた別の
JVMでも、同じデータとして扱えるようにする形式へ変換す
ること
メモリー（Javaヒープ）
T a r o 3 2
Y a m a d a
t a r o . y a m a d
a @ e x a m p l e . c o m
Person
String firstName Taro
String lastName Yamada
Integer age 32
String Email taro.yamada@example.com
<Person>
<firstName>Taro</firstName>
<lastName>Yamada</lastName>
<age>32</age>
</Person>
{
"firstName" : "Taro",
"lastName" : "Yamada",
"age" : 32
}
XMLの場合 JSONの場合
TaroYamada32
バイナリーの場合
代表的なシリアライズ形式

ULS
通信プロトコル
Geodeではアプリケーションの特性やクラスタ構成によって
次のプロトコルが選択可能
通信箇所通信プロトコル
クラスタ間の通信
TCP
（デフォルト）
信頼性が高いが低速
UDPユニキャスト
TCPより信頼性が低いが高速
※独自にデータの到達確認を行い
信頼性を向上させている
UDPマルチキャスト大規模クラスタで有効
クライアント-サーバ
間の通信
TCP
クライアント

ULS
シリアライズ/デシリアライズ
通信の際のデータのシリアライズ/デシリアライズ処理は選択することが
可能
オブジェクトの更新部分が一定となる場合は差分のみのシリアライズを
行うことで通信時のデータサイズをさらに圧縮することが出来る
シリアライズ方式備考
Java標準の方式
（java.io.Serializable）
Java以外のクライアントと通
信することが出来ない
Geode独自の高速シリアライズ方式
（com.gemstone.gemfire.DataSerializable）
処理速度は最速となる
PDX方式（Geode独自）
（Portable Data eXchange）
異なるバージョンのオブジェク
トでも通信することが出来る
シリアライズ方式毎の処理速度の比較

ULS
まとめ
Javaオブジェクトのメモリー使用量
–Javaのオーバーヘッドは予想以上に大きい
–プリミティブ型の方がメモリー使用量は少ない
–オブジェクト内部を1つのバイト配列で表現するのが究極
–オブジェクト数の削減はGC処理にも効果あり
通信レイテンシー
–高速処理を実現するためには以下の選択が重要
通信プロトコル
高速シリアライザー
通信データをコンパクトに

ULS
宣伝：簡易にメモリー使用量の削減できる！
Memory Optimizer

インメモリーで超高速処理を実現する場合のカギ

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (7)

Similar to インメモリーで超高速処理を実現する場合のカギ

Similar to インメモリーで超高速処理を実現する場合のカギ (20)

More from Masaki Yamakawa

More from Masaki Yamakawa (10)

Recently uploaded

Recently uploaded (16)

インメモリーで超高速処理を実現する場合のカギ