More Related Content Similar to メディアコンテンツを支えるデータストアサービスをAWSで (20) メディアコンテンツを支えるデータストアサービスをAWSで2. Self Introduction
村田 靖拓(むらた やすひろ)
l 2014/10 新卒でFuture Architectへ入社
l Technology Innovation Group所属
l PJ配属当初はフロントエンジニア(Web UIコンポーネント開発など)
l 最近はAWSを利用したアプリ開発・インフラエンジニア
l 趣味はテニスとドラム 水瀬いのりの曲を叩きたいんじゃ(BPM早いよー...orz)
l 五反田専用飲み会隊長 野崎屋・それがし・グラフトン・塚田農場によく行きます
l 本日が登壇デビューです!お手柔らかにおねがいしますmm
@famipapamart
23. パフォーマンス検証の話(4/13)
gRPCサーバ on ECS のパフォーマンス特性
• 今回のアーキテクチャで一番ボトルネックとなった
• Protocol Bufferでのシリアライズ・デシリアライズ処理がCPUリソースを多量に
消費した
• 「TPS × メッセージサイズ × 取扱件数/request」 で算出した時間あたりの流量に
応じてわかりやすく性能劣化の傾向がみてとれた
• r3.xlargeでは1コンテナあたり9MBが限界だった(※)
24. パフォーマンス検証の話(5/13)
アクセス
パターン
Req
/sec
取得
件数
秒間流量
(MB/sec)
コンテナ
(個)
R/CU レイテンシ
Min Avg 50th 75th 95th 99th Max
Read
Dynamo
10 10 6.5 1 505 146msec 189msec 179msec 190msec 214msec 506msec 826msec
15 10 9.75 1 756 361msec 709msec 692msec 791msec 947msec 1.0sec 1.2sec
17 10 11.05 1 858 637msec 8.7sec 7.3sec 13.7sec 20.1sec 22.1sec 23.6sec
17 10 11.05 2 798 132msec 157msec 148msec 156msec 178msec 442msec 761msec
34 10 22.1 4 2021 133msec 157msec 149msec 157msec 176msec 417msec 785msec
パフォーマンス特性に基づいたスケーリング戦略
• 単純なTPS増加であればスケールアウトで対応する(稼働後は基本こっちなはず)
• 1リクエストあたりの取扱件数増加であればスケールアップで対応する
• スケールアップによりリニアに性能が改善する傾向も確認できた
25. パフォーマンス検証の話(6/13)
アクセス
パターン
Req
/sec
from size 秒間流量
(MB/sec)
インスタンス
タイプ
レイテンシ
Min Avg 50th 75th 95th 99th Max
Read
ES
10 0 10 6.5 r3.xlarge 189msec 232msec 224msec 238msec 278msec 453msec 773msec
10 0 10 6.5 r3.2xlarge 181msec 209msec 203msec 211msec 229msec 365msec 688msec
10 0 20 6.5 r3.4xlarge 168msec 191msec 186msec 191msec 216msec 363msec 671msec
10 0 20 13 r3.xlarge - - - - - - -
10 0 20 13 r3.2xlarge 318msec 356msec 349msec 360msec 384msec 541msec 853msec
パフォーマンス特性に基づいたスケーリング戦略
• 単純なTPS増加であればスケールアウトで対応する(稼働後は基本こっちなはず)
• 1リクエストあたりの取扱件数増加であればスケールアップで対応する
• スケールアップによりリニアに性能が改善する傾向も確認できた
29. パフォーマンス検証の話(10/13)
“max_result_window” の壁...とは?
• Elasticsearchのパラメータ “max_result_window” のデフォルト値が10,000であ
ることに由来する(デフォ値10,000が悪いとかでは全くないです!念のため。)
• 100万件以上ヒットするQueryを offset - limit 形式で投げる必要があった
• 素直にSearch API使って ”90万件目から50件取得” と投げようとすると...
• じゃあ “max_result_window” をめちゃくちゃあげればすむ話なの?
Result window is too large, from + size must be less than or equal to: [10000]
31. パフォーマンス検証の話(12/13)
from値が大きくなればなるほどLatencyは上がっていった
• 1indexあたりのデータ件数はなるべく小さくできると良い
• “max_result_window” デフォ値10,000の重要性を改めて理解した
アクセス
パターン
Req/sec from size レイテンシ
Min Avg 50th 75th 95th 99th Max
Read
3 150 20 256msec 282msec 274msec 281msec 298msec 445msec 764msec
3 1,500 20 251msec 282msec 277msec 283msec 302msec 378msec 700msec
3 15,000 20 266msec 295msec 286msec 294msec 311msec 482msec 803msec
3 150,000 20 389msec 442msec 430msec 450msec 493msec 584msec 846msec
3 1,500,000 20 629msec 738msec 713msec 786msec 883msec 1094msec 1413msec
32. パフォーマンス検証の話(13/13)
100万件以上ヒットするQueryを offset - limit 形式で...はどうしたの?
• indexを複数に分割し、Count APIを利用してデータ取得対象indexを特定する方式に
• ソート条件が固定(作成年月日)だったため、indexはあらかじめ年月順にならべておく構成をとった
index1 - 2014 index2 - 2015 index3 - 2016 index4 - 2017 index5 - 2018
①
各indexにCount APIを投げ
indexごとのヒット件数を取得
③
特定したindexにQueryを投げる
②
取得対象データが格納されている
indexを特定