PLAID’s Journey with multi cloud

Google Cloud Day: Digital でお話した、
2015-2020年にかけてのKARTE のマルチクラウドアーキテクチャの変遷について
https://cloudonair.withgoogle.com/events/google-cloud-day-digital?talk=d1-appdev04

Transcript

1. PLAID’s Journey with multi cloud Naohiko Takemura PLAID, Inc Head of engineering
2. 株式会社プレイド 東京都中央区銀座6-10-1 GINZA SIX 10F 設立：2011年10月 従業員：210名
3. Customer Experience Platform karte.io
4. KARTE 導入企業様（一部抜粋）
5. Real time Large scale Analytics Service 0.x sec to real-time actions 105,000 events per sec 500+ datasets for clients 4 billion events per day 6000 slots with flat Rate US & JP 8+ PB stored in BigQuery 1 PB streaming insert per month 180+ PB analysis per month
6. Events データ量の変化
7. Current Architecture AWS Cloud Bigtable Analyze Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling GCE Cloud Pub/Sub Admin GKE Autoscaling Admin GKE on AWS Autoscaling Track Amazon EC2 Autoscaling Route53 Route53 Ops
8. VM based MultiCloud GCP Databases (BigQuery & Bigtable) + AWS 2014 2016 2018 2019 2020 2017 2015 SingleCloud with AWS Launch VM based MultiCloud + GKE (Self Contained System) Release Release Release History VM based MultiCloud + Container based MultiCloud
9. VM based MultiCloud GCP Databases (BigQuery & Bigtable) + AWS 2014 2016 2018 2019 2020 2017 2015 SingleCloud with AWS Launch VM based MultiCloud + GKE (Self Contained System) Release Release Release History VM based MultiCloud + Container based MultiCloud
10. AWS 概要 - Launch スピードを意識した SingleCloud - そもそも GCP がまだメジャーでなかっ た Elastic MapReduce Track Amazon EC2 Autoscaling Elasticache DynamoDB Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 SingleCloud with AWS
11. AWS 概要 - Launch スピードを意識した SingleCloud - そもそも GCP がまだメジャーでなかっ た 課題 - Launch 前には読みきれなかった問題 - 想定外の負荷パターン - Batch 解析の運用コスト Elastic MapReduce Track Amazon EC2 Autoscaling Elasticache DynamoDB Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 SingleCloud with AWS
12. VM based MultiCloud GCP Databases (BigQuery & Bigtable) + AWS 2014 2016 2018 2019 2020 2017 2015 SingleCloud with AWS Launch VM based MultiCloud + GKE (Self Contained System) Release Release Release History VM based MultiCloud + Container based MultiCloud
13. AWS BigQuery Track Amazon EC2 Autoscaling Elasticache Cloud Bigtable Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 GCP Databases (BigQuery & Bigtable) + AWS 概要 - 別 Cloud の相性の良い Product を取り入れた Partial MultiCloud - Bigtable - BigQuery
14. 概要 - 別 Cloud の相性の良い Product を取り入れた Partial MultiCloud - Bigtable - BigQuery 課題 - 通信コスト増 - GCP ↔ AWS 通信問題 - (Bigtable Beta の通信コストは当時 free ) - 安定性 - クラウドプロバイダーの障害に弱い - KARTE のシステム要件が厳しい AWS BigQuery Track Amazon EC2 Autoscaling Elasticache Cloud Bigtable Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 GCP Databases (BigQuery & Bigtable) + AWS
15. VM based MultiCloud GCP Databases (BigQuery & Bigtable) + AWS 2014 2016 2018 2019 2020 2017 2015 SingleCloud with AWS Launch VM based MultiCloud + GKE (Self Contained System) Release Release Release History VM based MultiCloud + Container based MultiCloud
16. VM based MultiCloud (step 1/3) Track Amazon EC2 Autoscaling Cloud Bigtable Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling 概要 - GCP でも AWS と同じ Application が動くようにしたVM based MultiCloud - PrivateNW を IPsecVPN で拡張 - Bigtable / BigQuery とヘビーに通信する部分は GCP が main 、AWS が sub - Admin はそのまま - 通信量 - Websocket - MultiCloud での負荷分散 - Web : Route53 TrafficFlow - Worker : Queue Elasticache AWS Route53
17. VM based MultiCloud (step 1/3) Track Amazon EC2 Autoscaling Cloud Bigtable Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling 概要 - GCP でも AWS と同じ Application が動くようにしたVM based MultiCloud - PrivateNW を IPsecVPN で拡張 - Bigtable / BigQuery とヘビーに通信する部分は GCP が main 、AWS が sub - Admin はそのまま - 通信量 - Websocket - MultiCloud での負荷分散 - Web : Route53 TrafficFlow - Worker : Queue 課題 - VPN の帯域がボトルネックでリアルタイム解析の Latency 悪化 - Queue with Elasticache for events - Read Action Data from mongoDB - BigQuery への write が確率的に失敗し、 データが欠損 Elasticache AWS Route53
18. VM based MultiCloud (step 2/3) Track Amazon EC2 Autoscaling Cloud Bigtable Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling 概要 - 通信の流れを整理 - Queue は RedisLabs の Redis を使い PublicEndpoint にバイパス - Mongo の ReadReplica を GCP にも作成 し、replication 通信のみを VPN 経由に - BigQuery への write の安定性をあげるた め、前段に Cloud Pub/Sub を GCE Cloud Pub/Sub AWS Route53
19. VM based MultiCloud (step 2/3) Track Amazon EC2 Autoscaling Cloud Bigtable Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling 概要 - 通信の流れを整理 - Queue は RedisLabs の Redis を使い PublicEndpoint にバイパス - Mongo の ReadReplica を GCP にも作成 し、replication 通信のみを VPN 経由に - BigQuery への write の安定性をあげるた め、前段に Cloud Pub/Sub を 課題 - Multi Cloud での構成管理、監視、デプロイに運用 コストがかかる GCE Cloud Pub/Sub AWS Route53
20. VM based MultiCloud (step 3/3) Track Amazon EC2 Autoscaling Cloud Bigtable Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling GCE Cloud Pub/Sub 概要 - MultiCloud な Ops tool / Service で運用負荷低減 - Terraform でインフラの構成管理 - Datadog でインフラ/アプリケーションの監 視 - Spinnaker でアプリケーションのデプロイ Ops AWS Route53
21. VM based MultiCloud (step 3/3) Track Amazon EC2 Autoscaling Cloud Bigtable Analyze Amazon EC2 Autoscaling Admin Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling GCE Cloud Pub/Sub 概要 - MultiCloud な Ops tool / Service で運用負荷低減 - Terraform でインフラの構成管理 - Datadog でインフラ/アプリケーションの監 視 - Spinnaker でアプリケーションのデプロイ 課題 - (強いてあげるなら ) SRE /インフラエンジニアがボト ルネック - 運用 - インフラ設計 / 構築 - エンジニア総数が 15 人ぐらいだったので、ある程度 の属人性があったほうがパフォーマンスがでる時期 だった AWS Route53 Ops
22. Events Cost VM based MultiCloud 後、Cost Performance がよい System に
23. https://status.cloud.google.com/incident/compute/16020 Cloud Provider の障害を回避 / 低減することもできた
24. VM based MultiCloud GCP Databases (BigQuery & Bigtable) + AWS 2014 2016 2018 2019 2020 2017 2015 SingleCloud with AWS Launch VM based MultiCloud + GKE (Self Contained System) Release Release Release 継続的なサブプロダクト / プラグインのリリースにより システムが膨大になっていく VM based MultiCloud + Container based MultiCloud
25. 54人 3人 2018 年頃からエンジニアの数も急増
26. 新たな課題 モノリシックなアーキテクチャ起因で 開発スピードがスケールしない
27. VM based MultiCloud GCP Databases (BigQuery & Bigtable) + AWS 2014 2016 2018 2019 2020 2017 2015 SingleCloud with AWS Launch VM based Multi Cloud + GKE (Self Contained System) Release Release Release History VM based MultiCloud + Container based MultiCloud
28. GKE (Self Contained System) Track Amazon EC2 Autoscaling Cloud Bigtable Analyze Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling GCE Cloud Pub/Sub 概要 - GKE (k8s) を全面的に活用した粒度の粗い マイクロサービス “Self Contained Systems (SCS)” - https://tech.plaid.co.jp/self-contained-systems/ - 開発が活発な Admin をまずは対象 - 使い勝手から GKE を選択、AWS ➝ GCP に - Admin を開発/チーム単位で緩く分割 - https://speakerdeck.com/komukomo/migrating- to-microservices - Track / Analyze は現状 GKE には移さない - massive & performance intensive - 変更が Admin ほど多くない Admin GKE Autoscaling AWS Route53 Ops
29. GKE (Self Contained System) Track Amazon EC2 Autoscaling Cloud Bigtable Analyze Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling GCE Cloud Pub/Sub 概要 - GKE (k8s) を全面的に活用した粒度の粗い マイクロサービス “Self Contained Systems (SCS)” - https://tech.plaid.co.jp/self-contained-systems/ - 開発が活発な Admin をまずは対象 - 使い勝手から GKE を選択、AWS ➝ GCP に - Admin を開発/チーム単位で緩く分割 - https://speakerdeck.com/komukomo/migrating- to-microservices - Track / Analyze は現状 GKE には移さない - massive & performance intensive - 変更が Admin ほど多くない 課題 - Admin の可用性 - SLO が厳しめのシステムの増加 - 開発のロックイン - 開発者の技術選定の自由度 Admin GKE Autoscaling AWS Route53 Ops
30. VM based MultiCloud GCP Databases (BigQuery & BigTable) + AWS 2014 2016 2018 2019 2020 2017 2015 SingleCloud with AWS Launch VM based Multi Cloud + GKE (Self Contained System) Release Release Release History VM based MultiCloud + Container based MultiCloud
31. k8s のMultiCloud ？ EC2 上に k8s を構築 or AWS のk8s サービス利用？ イニシャルコスト + 運用コスト ?
32. Container based MultiCloud AWS Track Amazon EC2 Autoscaling Cloud Bigtable Analyze Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling GCE Cloud Pub/Sub Admin GKE Autoscaling Admin GKE on AWS Autoscaling 概要 - Anthos GKE on AWS を利用した Container based MultiCloud - 既存の AWS VPC 上に GKE の cluster を構築 - Route53 で traffic をバランシング Route53 Route53 Ops
33. 　 Management Cluster Control Plane 　AWSNode 　Pool AWS API 　NLB NLB 　ELB Jump Server Admin User User Cluster の 作成 / 更新 / 削除 zone-a zone-b zone-c User Cluster (AWSCluster) GKE Hub クラスタ / ワークロード の情報など kubectl kubectl AWS VPC Control Plane 　AWSNode 　Pool Control Plane 　AWSNode 　Pool Anthos GKE on AWS アーキテクチャ
35. Pros • 最小限構成は簡単に初期構築できる、 30 min • 既存の AWS NW をそのまま使えるオプションがある • 使い勝手は GKE ◦ GKE (k8s) での manifests を (ほぼ) そのまま使える ◦ 運用周りは GKE の方法に統一できる Cons • 初期構築に Terraform を使うので Terraform の知識が 多少必要になる (カスタマイズしなければほぼ不要 ) • カスタマイズした構成を作りたい場合はハマる • GKE の全ての機能に対応しているわけではない Workload Identity, etc • パスベースルーティングは Builtin の Istio ベース ALB はオフィシャルには対応していない • 現状、AWS メインで問題なく動かしている人は使うインセン ティブはないかも (GKE を使っている人は試してみる価値あり ) GKE on AWS (Beta) を動かしてみて
36. • GKE で出来て GKE on AWS で出来ないことの改善 • AWS のサービスへのさらなる対応 (ALB など） • MultiCloud Ingress • k8s based MultiCloud Private Network • Multi Cloud な Ops の充実 (CI/CD, Secret 管理) • Cloud 時代の OS が生まれるようにリーディング ◦ cloud Provider と user とで一緒に作り上げいく GKE on AWS に今後期待すること
37. まとめ
38. VM based MultiCloud GCP Databases (BigQuery & Bigtable) + AWS 2014 2016 2018 2019 2020 2017 2015 SingleCloud with AWS Launch VM based MultiCloud + GKE (Self Contained System) VM based MultiCloud + Container based MultiCloud Release Release Release History
39. Current Architecture AWS Cloud Bigtable Analyze Amazon EC2 Autoscaling Amazon EC2 BigQuery Track GCE Autoscaling Analyze GCE Autoscaling GCE Cloud Pub/Sub Admin GKE Autoscaling Admin GKE on AWS Autoscaling Track Amazon EC2 Autoscaling Route53 Route53 Ops
40. • はじめから全てうまくはいかない。フェーズで前提は変わる。走りながらつど見直す /壊す • MultiCloud はあくまでも手段、目的ではない ◦ 可用性の向上？ ◦ パフォーマンス向上 / コスト削減？ ◦ 開発の自由度の向上？ • 全てを MultiCloud にしようとせず、濃淡をつける Bigtable, BigQuery の代替システムを作る /運用するのはコストが掛かる • 自分たちで仕組みを作ろうとし過ぎず、 Cloud Service / OSS を積極的に活用し、還元する ポイント
41. Thank you.