メディアコンテンツを支えるデータストアサービスをAWSで
•
2 likes•1,216 views
X-Tech JAWS 第4回のmedia tech枠で発表した内容です。 データストアサービス構築にあたって使用したAWSサービスとその非機能面の話（性能・DR）が中心です。
Recommended
More Related Content
Similar to メディアコンテンツを支えるデータストアサービスをAWSで
Similar to メディアコンテンツを支えるデータストアサービスをAWSで (20)
メディアコンテンツを支えるデータストアサービスをAWSで
- 1. メディアコンテンツを支える データストアサービスをAWSで Future Architect, Inc. Yasuhiro Murata X-Tech JAWS 【第4回】 2018/07/19
- 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
- 4. こんな会社です エンジニアを大切にするITコンサルティング企業です • B to Bでシステムを提案・構築しています • OSSの制作・公開もしています
- 6. 本日のメイントピック • データストアサービス構築において活用したAWSサービスと そのポイント • データストアサービスの非機能面の話 • パフォーマンス検証を振り返って • マルチリージョン構成でのDR開発について • RDBからNoSQL、分散DBへ移行するときのツラミ（おまけ）
- 7. 本日のトピックから外したもの • 各種AWSサービスの概要レベルの話 • API設計で考えたもろもろ • データモデリング • 現場でのDevOps この辺は別の機会に...
- 8. もくじ • Introduction ~メディアコンテンツを扱うということ~ • システムアーキテクチャの話 • パフォーマンス検証の話 • DRの話 • おまけ（時間があれば） • まとめ
- 11. Introduction メディアコンテンツを扱う上で考えなきゃいけないこと • あらゆるメディア形式に対応すること • コンテンツは記事・写真・動画など様々な種類がある • 格納したコンテンツ群から欲しいものをすばやく取得できること • 大量の過去記事を参考に新しい記事を書くことは日常茶飯事
- 12. システムアーキテクチャの話
- 14. システムアーキテクチャの話（2/6） 今回採用したアーキテクチャ • gRPC Client with Java • gRPC Server with Golang @ ECS • DynamoDB • Amazon Elasticsearch Service
- 15. システムアーキテクチャの話（3/6） gRPCを採用したわけ ~採用して良かったこと・辛かったこと~ • インターフェースの定義がprotoファイルに落ちる • 1ソース（proto）からサーバ・クライアントの両ソースが自動生成できる • JsonSchemaのようなチェック機構をごりごり実装する必要がなかった • HTTP/2での高速通信が可能 • NLBの登場により通信プロトコルとしてgRPCを採択できた（※）
- 16. システムアーキテクチャの話（4/6） NLBの登場でgRPC採用に踏み切れた...とは？ • ALBが言う「HTTP/2に対応！」はClient↔LB間の話であって、LB↔TargetGroup の話ではなかった • NLBはTCPレイヤーでのロードバランシング Client Client HTTP/2 OK HTTP/2 NG HTTP/2 OK HTTP/2 OK
- 17. システムアーキテクチャの話（5/6） DynamoDBを採用したわけ ~採用して良かったこと・辛かったこと~ • マネージドサービスである • AWS各サービスとの親和性が高い • DynamoDB Streamsに感謝 • スキーマレスなため検証時の立ち上がりが早い • ローカルからのアクセス時にCredentialを必要としたため、本番想定アプリケー ションをローカルで動かしてもDynamoDBへはアクセスできなかった • DynamoDB Streamsを利用した検証はローカルでは難しかった
- 18. システムアーキテクチャの話（6/6） Elasticsearchを採用したわけ ~採用して良かったこと・辛かったこと~ • 全文検索エンジンとして利用できる • 日本語で書かれた記事は、英語のようにスペースで区切ればよいわけではなく、形態素解析を行うことが 望ましい • 【WIN】Amazon ES vs 【LOSE】Elasticsearch on EC2 • なるべくマネージドを、の思いからAmazon ESを採択 • KibanaやS3バックアップを設定なしで利用可能 • 旧字体の展開が可能だったことが決め手 • 検索精度の正解が見えない（見えない） • Googleやっぱりすごい
- 19. パフォーマンス検証の話
- 21. パフォーマンス検証の話（2/13） 検証の前提 • メッセージサイズは65kb（メディアコンテンツのサイズを想定） • 負荷掛けツールはGatlingを使用 • ECSコンテナインスタンスは r3.xlarge × 2台 • 1インスタンスに1コンテナとし、リソースは全て割り当てた • DynamoDBのCUは多めに設定し、消費した値を確認 • Amazon ESは r4.2xlarge × 3台 • EBSは1.5TBをアタッチ
- 22. パフォーマンス検証の話（3/13） gRPCでのパフォーマンス検証のツラミ • gRPCで負荷を掛けられるツールがあまりない • 一時はgRPC Gatewayを立ててRESTでやろうかと思った時期もありました... • 最終的にGatlingを採用 • https://github.com/tamediadigital/grpc-gatling ｱﾘｶﾞﾄｳ
- 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リクエストあたりの取扱件数増加であればスケールアップで対応する • スケールアップによりリニアに性能が改善する傾向も確認できた
- 26. パフォーマンス検証の話（7/13） DynamoDB のパフォーマンス特性 • 札束で叩けば無限に(?)スケールする • CUの範囲内であればLatencyは常に一定 • CUはメッセージサイズとTPS次第だが、TPSの制御はなかなか難しいのでメッセー ジサイズをなるべく小さくする考慮を設計段階から入れられるとベター • CUに余裕があってもスロットリングが発生するケースに遭遇（※）
- 27. パフォーマンス検証の話（8/13） CUに余裕があってもスロットリングが発生！（遂に遭遇しました） • Capacity UnitはDynamoDB内の各シャードで按分される • そのため特定IDにのみ連続でアクセスするとスロットリングが発生する W/CU : 1000 shard1 shard2 shard3 shard4 shard5 各シャードの W/CUは200ずつ 1request = 5kb とすると 200TPS捌けるはずだが 実際は40TPS（概算）
- 28. パフォーマンス検証の話（9/13） Elasticsearch のパフォーマンス特性 • パフォーマンスはQueryとfrom（offset値）に依存する • 初回QueryのQueryLatency速度の担保が難しい • Warm APIなくなったけど... • 性能を担保するに足るQueryの定義が分からない • フリーワード検索は結局 ”入力される単語次第” なところもある • “max_result_window” の壁に出会う（※）
- 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]
- 30. パフォーマンス検証の話（11/13） “max_result_window” はめちゃくちゃあげても大丈夫でした but... • “max_result_window” を10,000,000にあげてみてもメモリ使用量が爆上がりする ことはなかった • メモリ使用量にダイレクトにはねたのはsize（同時取得件数）だった shard1 shard2 shard3 shard4 shard5 59= 0 各シャード上位 90万50件を抽出 全てマージし 90万 ~ 90万50件目 を特定
- 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を特定
- 33. DRの話
- 36. DRの話（3/6） 平常時のデータレプリケーションをどうやって実現するか • DynamoDBを起点にリージョン間のデータ同期をとる方式を採択 • Cross-Region-Replication ｱﾘｶﾞﾄｳ • でも...東京リージョンにはGlobalTableがない！！（号泣） • なので...dynamodb-cross-region-libraryを使ってReplication Programを実装 • ElasticsearchへのインデクシングはDynamoDB Streamsを利用
- 37. DRの話（4/6） どうやって切り戻すか • 東京リージョン壊滅を想定 • 実際は「DynamoDBだけダウン」等が起こりうる現実的なラインだろうが、Disasterパターンごとに復 旧シナリオを考えるのはなかなかキツい • 切り戻しもDynamoDBを起点にリージョン間のデータ同期をとる方式でGO • Cross-Region-Replication ﾎﾝﾄｳﾆｱﾘｶﾞﾄｳ • でも...東京リージョンにはGlo（ry • ただし同期開始前のデータの移送には考慮が必要（※） • Live Stream data はDynamoDB Streams経由でCross-Region-Replicate • Existing dataはDynamoDB Streamsのキューが失効する24時間以内になにかしらの方式でコピーして おく必要がある
- 39. DRの話（6/6） 検討したけどやらなかった・できなかったものたち • GlobalTableによるDynamoDBのCross-Region-Replication • これを一番やりたかった... • いずれ東京にも来るはず！！ • DynamoDBのOnDemand-Backupをベースに別リージョンでテーブルをRestore • そもそも同一リージョンでしかRestoreできない • S3バックアップをベースにしたElasticsearchの別リージョンでのRestore • 仕掛け上可能ではあるがデータ作成の経路が複数できてしまうために却下
- 40. おまけ
- 41. おまけ（1/2） RDBをNoSQLに移行する際のツラミ • 当たり前だが、「SQLで外部結合じゃ！」みたいなことができない • 親子関係を持つデータの管理方法をしっかり検討する必要があった • 【LOSE】互いのキー情報を持ち合う？ • 【WIN】それとも親子管理テーブルを持つ？ • 処理がシンプルになるのはどっちなんだろうか • 検索時に結合できないから事前にビュー的なものを生み出す機構を準備した レコード更新をtriggerに 検索index側に集計項目をPUT
- 42. おまけ（2/2） 分散DB（Elasticsearch）ならではのツラミ • 大量件数ヒットするようなQueryを扱うならScroll APIの利用が望ましい • しかし要件定義次第ではfrom / sizeの指定による検索が必要になってしまう • 今回はSearch APIを使っています（泣） • 可能であればページネーションはつけない画面設計ができると平和（とても平和） • TwitterとかFacebookのTLを見てみなさい、という話 Lovely♡（私見） NO!（私見）
- 43. まとめ
- 44. まとめ • アーキテクチャ • DynamoDBはやっぱりAWS各サービスとの親和性が高くてうれしい • パフォーマンス検証 • gRPCメッセージのシリアライズ・デシリアライズ処理が一番ネックになった • DynamoDBは札束で殴ればスケールする • ElasticsearchはQueryの初回Latency担保が悩ましい • DR • Cross-Region-Replication ｱﾘｶﾞﾄｳ