Successfully reported this slideshow.

Graviton 2で実現する
コスト効率のよいCDP基盤

1

Share

1 of 27
1 of 27

Graviton 2で実現する
コスト効率のよいCDP基盤

1

Share

Download to read offline

Graviton 2で実現する
コスト効率のよいCDP基盤

Graviton 2で実現する
コスト効率のよいCDP基盤

More Related Content

Slideshows for you

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Graviton 2で実現する
コスト効率のよいCDP基盤

  1. 1. Graviton 2で実現する
 コスト効率のよいCDP基盤 Compute x AWS Graviton 2 「Armプロセッサによるコスト最適化」 Treasure Data Software Engineer 佐々⽊ 海
  2. 2. ⾃⼰紹介 ● 佐々⽊海(ささきかい) ● Software Engineer at Treasure Data ● CDPの主にデータ処理部分の開発を担当 ● データ処理基盤や機械学習に関する本を執筆
  3. 3. 概要 ● CDPの中⼼となるデータ基盤、Prestoを⽤いてGraviton 2のOLAP⽤の
 マイクロベンチマークを⾛らせて評価を⾏った ● インスタンスタイプ ● JDKのディストリビューション ● ワークロードのタイプ ● 既存のサービスをGraviton 2に移す際にいくつかの技術的課題に直⾯ ○ Java 11 ○ jnr-ffi ○ libjvmkill ● ベンチマークでの評価によりGraviton 2はパフォーマンスベースで
 最⼤50%のROI向上が⾒込めることがわかった
  4. 4. © 2020 Treasure Data Enterprise CDP
  5. 5. Enterprise CDPとは様々なソースから集めたデータを
 顧客価値向上のため⼀元的に管理、活⽤するためのプラットフォーム
  6. 6. Enterprise CDPとは様々なソースから集めたデータを
 顧客価値向上のため⼀元的に管理、活⽤するためのプラットフォーム 多くの計算資源を消費する
  7. 7. ある⺟集団からユーザの属性、⾏動履歴もとに計算したセグメントに対し
 様々なマーケティングテクノロジと連携することが可能 Audience Segment email Web広告 Personalization
  8. 8. ユーザは直感的なユーザインタフェースから複雑な条件にマッチした 顧客(カスタマー)を知ることが可能 → セグメント
  9. 9. ユーザに指定された条件は下記のようなSQLに変換され 分散SQLエンジンであるPrestoによって処理される select a.* from "cdp_audience_170"."customers" a where a."age" > 30 and ( select count(*) from "cdp_audience_170"."behavior_weblogs" _r1 where _r1."cdp_customer_id" = a."cdp_customer_id" ) > 1
  10. 10. PrestoとはPresto Software Foundationが中⼼となって開発している 
 オープンソースの分散SQLエンジン。 Coordinator Worker Worker Worker Worker Worker Worker ● オンメモリのためインタラクティブな処理に適している ● 永続的なデータを保持しないためデータベースではない ● プラグインを⽤いて様々なデータソースにあるデータを処理することが可能 ○ Federated Query Engine
  11. 11. ⼤規模なJOIN、Subqueryを伴った複雑なSQLをより⾼速に コスト効率よく処理できるOLAP基盤が必要 
 
 → Graviton 2へのマイグレーション Segment Builder
  12. 12. © 2020 Treasure Data マイグレーション
  13. 13. PrestoはJavaで書かれたソフトウェアのため⼤きな変更は必要なし ● サポートしているアーキテクチャに aarch64を追加 ○ amd64 ○ aarch64 ○ ppc64el ● ArmサポートはExperimental See: https://github.com/prestosql/presto/pull/2809
  14. 14. JDK 11へのアップグレードでdeprecatedになったオプション ● GCのロギングオプションが廃⽌ ○ -XX:+PrintGCDetails ○ -XX:+PrintGCDateStamps ○ -Xloggc:... ● -Xlog:gc*:... に変更 ● Amazon Corrett 11 See: https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID- BE93ABDC-999C-4CB5-A88B-1994AAAC74D5
  15. 15. jnr-ffiパッケージによるzlib.soのロードエラー ● jnr-ffiはJavaプログラムからnative libraryを読み込むためのプログラム ○ https://github.com/jnr/jnr-ffi ● Supported Platformに”aarch64”があるにも関わらず読み込みに失敗 ○ https://github.com/jnr/jffi/tree/master/jni/libffi ● 最新のバージョンに上げることで解決 ○ jnr-ffi : 1.0.4 → 2.1.15 ○ jnr : 1.2.7 → 1.2.23 Exception in thread "main" java.lang.UnsatisfiedLinkError: could not load FFI provider jnr.ffi.provider.jffi.Provider at jnr.ffi.provider.InvalidProvider$1.loadLibrary(InvalidProvider.java:30) at jnr.ffi.LibraryLoader.load(LibraryLoader.java:228) at jnr.ffi.LibraryLoader.load(LibraryLoader.java:201) at zlib.main(zlib.java:17) Caused by: java.lang.ExceptionInInitializerError
  16. 16. libjvmkill.soのビルド ● libjvmkillはOOMなどでJVMアプリケーションが意図せぬ状態にならないよう強制的にプ ログラムを停⽌させるライブラリ ○ https://github.com/airlift/jvmkill ● CIパイプライン上でaarch64⽤のlibjvmkillをビルドするのは困難 ○ CircleCIでARM⽤のネイティブビルドは未サポート ○ https://ideas.circleci.com/images/p/support-for-arm-based-docker-images ● ローカルでビルドしたものをCodeDeployパッケージに含めデプロイ
  17. 17. © 2020 Treasure Data パフォーマンス
  18. 18. ベンチマーク ● PrestoのTPC-Hプラグインを使⽤ ○ 設定ファイルを書くだけなので利⽤が簡単 ○ IOを伴わないのでCPU性能を正確に評価することができる ● Warmupの後5回の平均を計算 ● TPC-Hクエリの中から下記を選択 ○ q01: Simple aggregation using SUM, AVG and COUNT ○ q10: Aggregation plus Sort ○ q18: SemiJoin with IN operator ○ q20: Nested Subquery ● スケーリングファクターはtinyとsf1を選択 ● docker-composeを⽤いて1 coordinator, 2 workerのクラスタを⽴ち上げ
  19. 19. Graviton 1
  20. 20. Graviton 1 ● 同じvCPUコア数を持つc5.4xlargeと⽐べ50%~200%遅い  ● sf1でより安定した性能を発揮 ● コスト効率 ○ a1.4xlarge is $9.8/day ○ c5.4xlarge is $16.3/day ● 同じメモリを積んだm5.2xlargeと⽐べると同等かあるいは⾼速 ○ m5.2xlarge is $9.21/day
  21. 21. Graviton 1 (Amazon Corretto)
  22. 22. Graviton 1 (Amazon Corretto) ● ⽐較的⼤きなデータに対してはAmazon Correttoの⽅が速い ● TPC-H tinyより⼤きなデータを扱うケースがほとんどなのでAmazon Correttoを採⽤ ○ サポート⾯ ○ AWSでの利⽤が主なケース
  23. 23. Graviton 2
  24. 24. Graviton 2 (Amazon Corretto)
  25. 25. Graviton 2 ● 同等のvCPU、メモリを持ったm5.4xlargeと⽐較して最⼤で30%速い ● tinyよりもsf1以上のスケールでよいパフォーマンスが期待できる ● コスト効率は20%良い ○ m6g.4xlarge: $14.78 / day ○ m5.4xlarge: $18.43 / day ● 全体として約50%のROIの向上が⾒込める
  26. 26. 参照 ● Presto ○ https://prestosql.io/ ● Graviton 1 パフォーマンス ○ https://prestosql.io/blog/2019/12/23/Presto-Experiment-with-Graivton- Processor.html ● Graviton 2 パフォーマンス ○ https://blog.treasuredata.com/blog/2020/03/27/high-performance-sql-aws- graviton2-benchmarks-with-presto-and-arm-treasure-data-cdp/ ○ Docker Image ○ https://hub.docker.com/repository/docker/lewuathe/presto-coordinator/tags? page=1 ○ https://hub.docker.com/repository/docker/lewuathe/presto-worker/tags?page=1 ○ Official Image ○ https://github.com/prestosql/presto/pull/4703/
  27. 27. © 2020 Treasure Data Thank you!

×