Upgrade to Pro — share decks privately, control downloads, hide ads and more …

300以上のマイクロサービスを支えるマルチクラウドアーキテクチャ戦略

 300以上のマイクロサービスを支えるマルチクラウドアーキテクチャ戦略

前回のDeveloper Conferenceから3年経ったABEMA。

様々な機能追加やサービス規模の拡大に対応するためにクラウドアーキテクチャの改修を行ってきました。

本セッションでは、ABEMAのこれまでの課題とそれらを解決するために取り組んだクラウドアーキテクチャの変遷を紹介します。

https://developer.abema.io/2021/sessions/JRrRCKSqyD/?utm_medium=social&utm_source=slideshare

2016ba6b977a2e6691811fa66d5f4336?s=128

CyberAgent
PRO

December 15, 2021
Tweet

More Decks by CyberAgent

Other Decks in Technology

Transcript

  1. None
  2. AbemaTV, Inc. All Rights Reserved
 Cloud Platform Team 2 About

    Mission • 基幹システムの開発・保守 • 次世代アーキテクチャの立案・浸透 • クラウドソリューションの活用戦略 @na_ga @gotyoooo @editnuki
  3. AbemaTV, Inc. All Rights Reserved
 Cloud Architecture の変遷 a. ABEMA

    b. High Level Architecture アジェンダ 3 Kubernetes on GCP & AWS a. Cloud Edge Proxy b. Service Mesh c. Secret Resource d. Role Based Access Control e. Optimization Node Pool
  4. 前回の ABEMA Developer Conference 2018 から比較した 1. Cloud Architecture の変遷

    4
  5. AbemaTV, Inc. All Rights Reserved
 ※ 出典 CyberAgent, inc. 2021

    年通期決算発表資料 2018 年比較 • Download 数: 約 2 倍 ABEMA における変化 5
  6. AbemaTV, Inc. All Rights Reserved
 2018 年比較 • Download 数:

    約 2 倍 • Weekly Active Users: 約 2 倍 ABEMA における変化 6 ※ 出典 CyberAgent, inc. 2021 年通期決算発表資料
  7. AbemaTV, Inc. All Rights Reserved
 2018 年は GKE を中心とした Micro

    Service Architecture High Level Architecture の変化 Micro Services Micro Services Micro Services Ingress Micro Services API Gateways Micro Services MongoDB Micro Services BigTable Micro Services Pub/Sub Micro Services Redis Cluster Micro Services Cloud Storage Micro Services BigQuery Micro Services Cloud CDN region: asia-east1 Kubernetes Cluster 共通 SDK 共通 SDK 7
  8. AbemaTV, Inc. All Rights Reserved
 2018 年は GKE を中心とした Micro

    Service Architecture High Level Architecture の変化 Micro Services Micro Services Micro Services Ingress Micro Services API Gateways Micro Services MongoDB Micro Services BigTable Micro Services Pub/Sub Micro Services Redis Cluster Micro Services Cloud Storage Micro Services BigQuery Micro Services Cloud CDN region: asia-east1 Kubernetes Cluster 共通 SDK 共通 SDK GCP 台湾リージョン 8
  9. AbemaTV, Inc. All Rights Reserved
 2018 年は GKE を中心とした Micro

    Service Architecture High Level Architecture の変化 Micro Services Micro Services Micro Services Ingress Micro Services API Gateways Micro Services MongoDB Micro Services BigTable Micro Services Pub/Sub Micro Services Redis Cluster Micro Services Cloud Storage Micro Services BigQuery Micro Services Cloud CDN region: asia-east1 Kubernetes Cluster 共通 SDK 共通 SDK GCP 台湾リージョン サービス間の gRPC通信は共通 SDK によるクライアント LB 実装 9
  10. AbemaTV, Inc. All Rights Reserved
 開発者の要望 • AWS の Managed

    Service と Compute Resource を活用したい • 日本国内のリージョンを活用し、通信遅延を削減したい High Level Architecture の変化 10
  11. AbemaTV, Inc. All Rights Reserved
 開発者の要望 • AWS の Managed

    Service と Compute Resource を活用したい • 日本国内のリージョンを活用し、通信遅延を削減したい High Level Architecture の変化 11 Micro Services Micro Services Micro Services API Gateways Micro Services BigTable Micro Services Trace Micro Services Pub/Sub Micro Services Momerystore Micro Services Cloud Storage Micro Services BigQuery Kubernetes Cluster … etc Micro Services DynamoDB Micro Services SQS Micro Services SNS Micro Services Lambda Micro Services S3 Micro Services Redshift AWS Cloud Kubernetes Cluster … etc Micro Services Micro Services Micro Services API Gateways + 配信システムのリプレス CQRS + Event Sourcing
  12. AbemaTV, Inc. All Rights Reserved
 開発者の要望 • AWS の Managed

    Service と Compute Resource を活用したい • 日本国内のリージョンを活用し、通信遅延を削減したい High Level Architecture の変化 12 台湾リージョン 大阪リージョン 東京リージョン
  13. AbemaTV, Inc. All Rights Reserved
 2021 年 High Level Architecture

    の変化 Micro Services Micro Services Micro Services Ingress Micro Services API Gateways Micro Services BigTable Micro Services Trace Micro Services Pub/Sub Micro Services Spanner Micro Services Momerystore Micro Services Cloud Storage Micro Services BigQuery Micro Services MongoDB Micro Services Micro Services Micro Services Ingress Micro Services API Gateways Micro Services DynamoDB Micro Services SQS Micro Services SNS Micro Services Aurora Micro Services Lambda Micro Services S3 Micro Services Redshift Micro Services Kinesis Micro Services Cloud CDN region: asia-east1 and asia-northeast1 region: ap-northeast-1 AWS Cloud Micro Services CloudFront Micro Services Edge Proxies Micro Services Edge Proxies Kubernetes Cluster Kubernetes Cluster App Mesh Anthos Service Mesh … etc … etc 13
  14. AbemaTV, Inc. All Rights Reserved
 High Level Architecture の変化 14

    2021 年は GCP と AWS を活用したマルチクラウド環境 • 開発者にクラウド各社の差異を意識させない仕組み • 従来の台湾リージョンに加えて 東京リージョンに展開 • マルチクラウド環境を前提とした Monitoring & Alerting 基盤のリプレス • Kubernetes におけるサービス間通信の標準化 • Kubernetes におけるマルチテナントを前提としたセキュリティ設計 • Kubernetes における異なるワークロードの 特性に最適化したノードプール設計
  15. AbemaTV, Inc. All Rights Reserved
 15 マルチクラウド環境を前提とした Monitoring & Alerting

    基盤 関連発表
  16. 今回は Kubernetes 周辺システムや各種設計を紹介します 2. Kubernetes on GCP & AWS

  17. AbemaTV, Inc. All Rights Reserved
 October 2018 The normal capacity

    is 3,000 vCPU and 4,000 GiB memory on 100 nodes. The normal workload is 1,000 pods always running on 50 services. Kubernetes Resources in production environment 17 December 2021 The normal capacity is 4,000 vCPU and 5,500 GiB memory on 150+ nodes. ※ The normal workload is 2,500+ pods always running on 300 services. ※ ※ As the peak load increases, the number of nodes and pods is increased by the autoscaler.
  18. AbemaTV, Inc. All Rights Reserved
 October 2018 The normal capacity

    is 3,000 vCPU and 4,000 GiB memory on 100 nodes. The normal workload is 1,000 pods always running on 50 services. Kubernetes Resources in production environment 18 December 2021 The normal capacity is 4,000 vCPU and 5,500 GiB memory on 150+ nodes. ※ The normal workload is 2,500+ pods always running on 300 services. ※ ※ As the peak load increases, the number of nodes and pods is increased by the autoscaler. サービスの細分化が加速し、異なる特性を持ったワークロードが増加した
  19. AbemaTV, Inc. All Rights Reserved
 GKE と EKS を活用した Multi

    Kubernetes Cluster 構成 High Level Architecture for Kubernetes Micro Services Micro Services Micro Services API Gateways region: ap-northeast-1 AWS Cloud Micro Services CloudFront Micro Services Ingress Micro Services Edge Proxies Kubernetes Cluster App Mesh Micro Services Micro Services Micro Services API Gateways Micro Services Ingress region: asia-east1 Micro Services Cloud CDN Micro Services Edge Proxies Kubernetes Cluster Anthos Service Mesh Micro Services Micro Services Micro Services API Gateways Micro Services Ingress region: asia-northeast1 Micro Services Cloud CDN Micro Services Edge Proxies Kubernetes Cluster Anthos Service Mesh Plain mTLS 19
  20. AbemaTV, Inc. All Rights Reserved
 High Level Architecture for Kubernetes

    GKE と EKS を活用した Multi Kubernetes Cluster 構成 クラウド間のグローバル通信 Cloud Edge Proxy サービス間のインターナル通信 Service Mesh マルチテナントを前提とした Security 異なるワークロードの特性に最適化した Node Pool Plain mTLS 20
  21. Kubernetes on GCP & AWS 2a. Cloud Edge Proxy

  22. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 経緯 22

    GCP と AWS を活用した Multi Kubernetes Cluster 構成 • システムの多様化によって、異なるクラウドでマイクロサービスが稼働する 背景
  23. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 経緯 23

    GCP と AWS を活用した Multi Kubernetes Cluster 構成 • システムの多様化によって、異なるクラウドでマイクロサービスが稼働する 異なるクラウドに対して透過的かつ安全に通信したい • EKS 上のサービスも従来の GKE 上のサービスと gRPC 通信を行いたい • グローバル通信となるため認証や暗号化を考慮する必要がある 背景 課題
  24. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 経緯 24

    GCP と AWS を活用した Multi Kubernetes Cluster 構成 • システムの多様化によって、異なるクラウドでマイクロサービスが稼働する 異なるクラウドに対して透過的かつ安全に通信したい • EKS 上のサービスも従来の GKE 上のサービスと gRPC 通信を行いたい • グローバル通信となるため認証や暗号化を考慮する必要がある 背景 課題 開発者にそれらを意識させず透過的に利用できる基幹システムを提供したい
  25. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 技術選定 25

    VPN Connection • 方式: IPsec • サポート: GCP & AWS • 運用・保守コスト: 低い • ランニングコスト: 高い • Routing 制御: 不可 Envoy Proxy • 方式: Mutual TLS • サポート: コミュニティ • 運用・保守コスト: 高い • ランニングコスト: 低い • Routing 制御: 可能
  26. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 技術選定 26

    VPN Connection • 方式: IPsec • サポート: GCP & AWS • 運用・保守コスト: 低い • ランニングコスト: 高い • Routing 制御: 不可 Envoy Proxy • 方式: Mutual TLS • サポート: コミュニティ • 運用・保守コスト: 高い • ランニングコスト: 低い • Routing 制御: 可能
  27. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 技術選定 27

    柔軟な拡張性や Capacity Planning の観点から Envoy Proxy を採用 VPN Connection • 方式: IPsec • サポート: GCP & AWS • 運用・保守コスト: 低い • ランニングコスト: 高い • Routing 制御: 不可 Envoy Proxy • 方式: Mutual TLS • サポート: コミュニティ • 運用・保守コスト: 高い • ランニングコスト: 低い • Routing 制御: 可能
  28. AbemaTV, Inc. All Rights Reserved
 クラウド間のグローバル通信を Mutual TLS によって保護 Cloud

    Edge Proxy: 概要 Micro Services Micro Services Micro Services API Gateways region: ap-northeast-1 AWS Cloud Micro Services CloudFront Micro Services Ingress Micro Services Edge Proxies Kubernetes Cluster App Mesh Micro Services Micro Services Micro Services API Gateways Micro Services Ingress region: asia-east1 Micro Services Cloud CDN Micro Services Edge Proxies Kubernetes Cluster Anthos Service Mesh Micro Services Micro Services Micro Services API Gateways Micro Services Ingress region: asia-northeast1 Micro Services Cloud CDN Micro Services Edge Proxies Kubernetes Cluster Anthos Service Mesh Plain mTLS 28
  29. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 詳細 29

    Kubernetes Cluster 各 Kubernetes Cluster に Envoy Proxy が動作するサービスを配置 Namespace: xxxxx-A Namespace: edge-proxy Namespace: xxxxx-B Kubernetes Cluster Namespace: xxxx-C Namespace: edge-proxy Namespace: xxxx-D AWS Cloud Micro Services grpc-egress Micro Services grpc-ingress Micro Services grpc-ingress Micro Services grpc-egress gRPC Connection gRPC Connection Routing Rules Routing Rules Routing Rules Routing Rules Micro Services service A Micro Services service C Micro Services service B Micro Services service D Plain mTLS L 4 L B L 4 L B
  30. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 詳細 30

    Kubernetes Cluster 各 Kubernetes Cluster に Envoy Proxy が動作するサービスを配置 Namespace: xxxxx-A Namespace: edge-proxy Namespace: xxxxx-B Kubernetes Cluster Namespace: xxxx-C Namespace: edge-proxy Namespace: xxxx-D AWS Cloud Micro Services grpc-egress Micro Services grpc-ingress Micro Services grpc-ingress Micro Services grpc-egress gRPC Connection gRPC Connection Routing Rules Routing Rules Routing Rules Routing Rules Micro Services service A Micro Services service C Micro Services service B Micro Services service D Plain mTLS L 4 L B L 4 L B 内部通信は PLAIN 内部通信は PLAIN
  31. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 詳細 31

    Kubernetes Cluster 各 Kubernetes Cluster に Envoy Proxy が動作するサービスを配置 Namespace: xxxxx-A Namespace: edge-proxy Namespace: xxxxx-B Kubernetes Cluster Namespace: xxxx-C Namespace: edge-proxy Namespace: xxxx-D AWS Cloud Micro Services grpc-egress Micro Services grpc-ingress Micro Services grpc-ingress Micro Services grpc-egress gRPC Connection gRPC Connection Routing Rules Routing Rules Routing Rules Routing Rules Micro Services service A Micro Services service C Micro Services service B Micro Services service D Plain mTLS L 4 L B L 4 L B 外部通信は mTLS 内部通信は PLAIN 内部通信は PLAIN
  32. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: 詳細 32

    Kubernetes Cluster 各 Kubernetes Cluster に Envoy Proxy が動作するサービスを配置 Namespace: xxxxx-A Namespace: edge-proxy Namespace: xxxxx-B Kubernetes Cluster Namespace: xxxx-C Namespace: edge-proxy Namespace: xxxx-D AWS Cloud Micro Services grpc-egress Micro Services grpc-ingress Micro Services grpc-ingress Micro Services grpc-egress gRPC Connection gRPC Connection Routing Rules Routing Rules Routing Rules Routing Rules Micro Services service A Micro Services service C Micro Services service B Micro Services service D Plain mTLS L 4 L B L 4 L B Backoff Retry & Circuit Breaker
  33. AbemaTV, Inc. All Rights Reserved
 Cloud Edge Proxy: まとめ 33

    クラウド間を透過的かつ安全な通信を確立 • 開発者は mTLS を意識する必要がない • Kubernetes Cluster 内の Edge Proxy サービスに従来通りに接続する • Edge Proxy サービスを経由して異なるクラウドのサービスに対して mTLS 通信を行う サービス側に意識させることなく信頼性を向上 • リトライ可能なレスポンスコードに対して、自動的に Backoff Retry を行う • リトライが好ましくないなど、サービス特性に合わせた個別設定を上書きできる • 異常なリクエストを検出した場合は Circuit Breaker によって影響範囲を最小化する
  34. Kubernetes on GCP & AWS 2b. Service Mesh 34

  35. AbemaTV, Inc. All Rights Reserved
 共通 SDK を使用したサービス間通信 • 共通

    SDK でサービス間の均等な負荷分散を実装している Service Mesh: 経緯 35 背景
  36. AbemaTV, Inc. All Rights Reserved
 Service Mesh: 経緯 36 共通

    SDK を使用したサービス間通信 • 共通 SDK でサービス間の均等な負荷分散を実装している サービスの多様化により共通 SDK の難しさに直面 • 言語毎に一貫性を保った SDK を実装する必要がある • SDK のアップデートを全てのサービスに適用する難しさ 背景 課題
  37. AbemaTV, Inc. All Rights Reserved
 Service Mesh: 経緯 37 共通

    SDK を使用したサービス間通信 • 共通 SDK でサービス間の均等な負荷分散を実装している サービスの多様化により共通 SDK の難しさに直面 • 言語毎に一貫性を保った SDK を実装する必要がある • SDK のアップデートを全てのサービスに適用する難しさ 背景 課題 Service Mesh Solution を導入し Networking 処理を移譲したい
  38. AbemaTV, Inc. All Rights Reserved
 Service Mesh: 技術選定 38 Istio

    • Data Plane: Envoy Proxy • 提供: Self • サポート: コミュニティ • ランニングコスト: 低い • 運用・保守コスト: 激難 ASM & App Mesh • Data Plane: Envoy Proxy • 提供: Managed ※ • サポート: GCP & AWS • ランニングコスト: 低い • 運用・保守コスト: 低い ※ ASM の Control Plane は Self (In-Cluster) 方式も選択可能
  39. AbemaTV, Inc. All Rights Reserved
 Service Mesh: 技術選定 39 Istio

    • Data Plane: Envoy Proxy • 提供: Self • サポート: コミュニティ • ランニングコスト: 低い • 運用・保守コスト: 激難 ASM & App Mesh • Data Plane: Envoy Proxy • 提供: Managed ※ • サポート: GCP & AWS • ランニングコスト: 低い • 運用・保守コスト: 低い ※ ASM の Control Plane は Self (In-Cluster) 方式も選択可能
  40. AbemaTV, Inc. All Rights Reserved
 Service Mesh: 技術選定 40 Istio

    • Data Plane: Envoy Proxy • 提供: Self • サポート: コミュニティ • ランニングコスト: 低い • 運用・保守コスト: 激難 ASM & App Mesh • Data Plane: Envoy Proxy • 提供: Managed ※ • サポート: GCP & AWS • ランニングコスト: 低い • 運用・保守コスト: 低い クラウド各社が提供する Managed Service を採用 ※ ASM の Control Plane は Self (In-Cluster) 方式も選択可能
  41. AbemaTV, Inc. All Rights Reserved
 各クラウドの Service Mesh Solution を活用したサービス間通信を実現

    Service Mesh: 概要 Micro Services Micro Services Micro Services API Gateways region: ap-northeast-1 AWS Cloud Micro Services CloudFront Micro Services Ingress Micro Services Edge Proxies Kubernetes Cluster App Mesh Micro Services Micro Services Micro Services API Gateways Micro Services Ingress region: asia-east1 Micro Services Cloud CDN Micro Services Edge Proxies Kubernetes Cluster Anthos Service Mesh Micro Services Micro Services Micro Services API Gateways Micro Services Ingress region: asia-northeast1 Micro Services Cloud CDN Micro Services Edge Proxies Kubernetes Cluster Anthos Service Mesh Plain mTLS 41
  42. AbemaTV, Inc. All Rights Reserved
 Service Mesh: 詳細 42 Namespace:

    api-gateway Sidecar の Envoy Proxy Container 経由でサービス間通信が可能 Plain mTLS Ingress Anthos Service Mesh Namespace: service-a Namespace: service-b Namespace: service-c API Gateways API Gateway API Gateways Envoy Proxy API Gateways Service A API Gateways Envoy Proxies API Gateways Service B API Gateways Envoy Proxies API Gateways Service C API Gateways Envoy Proxies Auto Injection by Kubernetes Cluster Pod: API Gateway Pod: Service A Pod: Service B Pod: Service C
  43. AbemaTV, Inc. All Rights Reserved
 Service Mesh: 詳細 43 Kubernetes

    Cluster Namespace: api-gateway Sidecar の Envoy Proxy Container 経由でサービス間通信が可能 Plain mTLS Ingress AWS App Mesh Namespace: service-a Namespace: service-b Namespace: service-c API Gateways API Gateway API Gateways Envoy Proxy API Gateways Service A API Gateways Envoy Proxies API Gateways Service B API Gateways Envoy Proxies API Gateways Service C API Gateways Envoy Proxies Auto Injection by AWS Cloud Pod: API Gateway Pod: Service A Pod: Service B Pod: Service C
  44. AbemaTV, Inc. All Rights Reserved
 Service Mesh によるサービス間通信 • 共通

    SDK から脱却 • セキュリティ担保のために内部通信に Mutual TLS を選択可能 • サービスのコンテキストを持たない横断チームによるトラフィック管理の実現 サービス側に意識させることなく信頼性を向上 • リトライ可能なレスポンスコードに対して、自動的に Backoff Retry を行う • リトライが好ましくないなど、サービス特性に合わせた個別設定を上書きできる • 異常なリクエストを検出した場合は Circuit Breaker によって影響範囲を最小化する 44 Service Mesh: まとめ
  45. Kubernetes on GCP & AWS 2c. Secret Resource 45

  46. AbemaTV, Inc. All Rights Reserved
 Secret Resource: 経緯 46 暗号化したファイルをPUSH

    kubesec を利用、Default Namespace のみの運用 • Secret Resource Manifest 自体を暗号化 • 復号のために KMS へアクセスし鍵を取得 • 1つの Secret を複数のサービスで利用 背景 開発者に依存した適用方法、複数 Namespace 運用の開始 • 開発者の Local 環境で復号・Apply、一貫性がない • 明確にマイクロサービスの分離を行うために、 Namespace を分割 ◦ 同じ内容の Secret Resource を複数の Namespace で作成するケースが発生 課題
  47. AbemaTV, Inc. All Rights Reserved
 Secret Resource: 経緯 47 暗号化したファイルをPUSH

    kubesec を利用、Default Namespace のみの運用 • Secret Resource Manifest 自体を暗号化 • 復号のために KMS へアクセスし鍵を取得 • 1つの Secret を複数のサービスで利用 背景 開発者に依存した適用方法、複数 Namespace 運用の開始 • 開発者の Local 環境で復号・Apply、一貫性がない • 明確にマイクロサービスの分離を行うために、 Namespace を分割 ◦ 同じ内容の Secret Resource を複数の Namespace で作成するケースが発生 課題 暗号化 復号化 開発者 Key Management Service 鍵取得 暗号化 暗号化したファイルをPUSH Kubernetes Engine 開発者 Key Management Service 鍵取得 復号 暗号化したファイルを取得 復号したファイルをApply
  48. AbemaTV, Inc. All Rights Reserved
 Secret Resource: 経緯 48 暗号化したファイルをPUSH

    kubesec を利用、Default Namespace のみの運用 • Secret Resource Manifest 自体を暗号化 • 復号のために KMS へアクセスし鍵を取得 • 1つの Secret を複数のサービスで利用 背景 開発者に依存した適用方法、複数 Namespace 運用の開始 • 開発者の Local 環境で復号・Apply、一貫性がない • 明確にマイクロサービスの分離を行うために、 Namespace を分割 ◦ 同じ内容の Secret Resource を複数の Namespace で作成するケースが発生 課題 Namespace default Secret wildcard.abema.tv Namespace A Secret wildcard.abema.tv Namespace B Secret wildcard.abema.tv Namespace C Secret wildcard.abema.tv
  49. AbemaTV, Inc. All Rights Reserved
 Secret Resource: 経緯 49 暗号化したファイルをPUSH

    kubesec を利用、Default Namespace のみの運用 • Secret Resource Manifest 自体を暗号化 • 復号のために KMS へアクセスし鍵を取得 • 1つの Secret を複数のサービスで利用 背景 開発者に依存した適用方法、複数 Namespace 運用の開始 • 開発者の Local 環境で復号・Apply、一貫性がない • 明確にマイクロサービスの分離を行うために、 Namespace を分割 ◦ 同じ内容の Secret Resource を複数の Namespace で作成するケースが発生 課題 Secret も CD を導入可能にし 一貫性を持った管理手法に変更
  50. AbemaTV, Inc. All Rights Reserved
 Secret Resource: 選定 ExternalSecrets 50

  51. AbemaTV, Inc. All Rights Reserved
 Secret Resource: ExternalSecrets ExternalSecrets https://github.com/external-secrets/kubernetes-external-secrets

    51 OSS 秘匿情報を 外部サービスに保管 Kubernetes エコシステム クラウド各社に対応
  52. AbemaTV, Inc. All Rights Reserved
 Secret Resource: ExternalSecrets 52 kube-apiserver

    app Namespace app Namespace app Namespace External Secrets Secrets External Secrets Controller AWS Secrets Manager GCP Secret Manager OR 1. Get ExternalSecrets 3. Upsert Secrets 2. Fetch secrets properties
  53. AbemaTV, Inc. All Rights Reserved
 GCP Secret Manager / AWS

    SecretsManager で一元管理 Secret Resource: ExternalSecrets 53 kube-apiserver app Namespace app Namespace app Namespace External Secrets Secrets External Secrets Controller AWS Secrets Manager GCP Secret Manager OR 1. Get ExternalSecrets 3. Upsert Secrets 2. Fetch secrets properties { "crt": "-----BEGIN CERTIFICATE-----\nMIIHJTXXX-----END CERTIFICATE-----", "key": "-----BEGIN PRIVATE KEY-----\nMIIEvgXXX-----END PRIVATE KEY-----" }
  54. AbemaTV, Inc. All Rights Reserved
 開発者は ExternalSecret Resource を作成しデプロイ Secret

    Resource: ExternalSecrets 54 kube-apiserver app Namespace app Namespace app Namespace External Secrets Secrets External Secrets Controller AWS Secrets Manager GCP Secret Manager OR 1. Get ExternalSecrets 3. Upsert Secrets 2. Fetch secrets properties apiVersion: kubernetes-client.io/v1 kind: ExternalSecret metadata: name: wildcard-abema-tv namespace: example spec: backendType: gcpSecretsManager projectId: examples template: type: kubernetes.io/tls data: - name: tls.crt key: wildcard_abema_tv version: latest property: crt - name: tls.key key: wildcard_abema_tv version: latest property: key
  55. AbemaTV, Inc. All Rights Reserved
 ExternalSecrets Controller が自動でSecrets Resourceを作成・更新 Secret

    Resource: ExternalSecrets 55 kube-apiserver app Namespace app Namespace app Namespace External Secrets Secrets External Secrets Controller AWS Secrets Manager GCP Secret Manager OR 1. Get ExternalSecrets 3. Upsert Secrets 2. Fetch secrets properties
  56. AbemaTV, Inc. All Rights Reserved
 Secret Resource: Secret management by

    PipeCD https://pipecd.dev/ 56 CyberAgent DP室 開発 OSS GitOps Continuous Delivery Tool Git で秘匿情報 を安全に保持
  57. AbemaTV, Inc. All Rights Reserved
 Secret Resource: Secret management by

    PipeCD app Namespace app Namespace app Namespace Secrets 開発者 57 PipeCD Console 1. Encrypt Confidential value 2. Get Public key Piped Agent Key Pair 3. Push File include encrypt value 4. Pull Files 5. Upsert Resource include Confidential value
  58. AbemaTV, Inc. All Rights Reserved
 Secret Resource: Secret management by

    PipeCD app Namespace app Namespace app Namespace Secrets 開発者 58 PipeCD Console 1. Encrypt Confidential value 2. Get Public key Piped Agent Key Pair 3. Push File include encrypt value 4. Pull Files 5. Upsert Resource include Confidential value 開発者が PipeCD Console で暗号化
  59. AbemaTV, Inc. All Rights Reserved
 Secret Resource: Secret management by

    PipeCD app Namespace app Namespace app Namespace Secrets 開発者 59 PipeCD Console 1. Encrypt Confidential value 2. Get Public key Piped Agent Key Pair 3. Push File include encrypt value 4. Pull Files 5. Upsert Resource include Confidential value 暗号化文字列を元に Manifest を作成し、Git に Push apiVersion: pipecd.dev/v1beta1 kind: KubernetesApp spec: encryption: encryptedSecrets: token: XXXXXXXX decryptionTargets: - secret.yaml input: namespace: example apiVersion: v1 kind: Secret metadata: name: example namespace: example type: Opaque data: token: "{{ .encryptedSecrets.token }}"
  60. AbemaTV, Inc. All Rights Reserved
 Secret Resource: Secret management by

    PipeCD app Namespace app Namespace app Namespace Secrets 開発者 60 PipeCD Console 1. Encrypt Confidential value 2. Get Public key Piped Agent Key Pair 3. Push File include encrypt value 4. Pull Files 5. Upsert Resource include Confidential value PipeCD デプロイ時に自動でDecrypt
  61. AbemaTV, Inc. All Rights Reserved
 • CloudPlatformTeam が提供する秘匿情報の暗号化に利用 • 現在は

    TLS 証明書が主 Secret Resource: 使い分け 61 • 各サービス毎に必要な秘匿情報 の暗号化に利用 • 環境変数、SaaS API Key、Token etc... ExternalSecrets
  62. AbemaTV, Inc. All Rights Reserved
 62 Secret Resource: まとめ GCP

    / AWS ともに同じ手法で Secret Resource の管理が可能に • 開発者に GKE / EKS を極力意識させない Gitリポジトリに秘匿情報を配置しない • 外部のリソースを利用して暗号化することで、 Git リポジトリ単体では復号不可 に
  63. Kubernetes on GCP & AWS 2d. Role Based Access Control

    63
  64. AbemaTV, Inc. All Rights Reserved
 Role Based Access Control (RBAC)

    とは • Resource へのアクセス権限管理を Role 型で取り扱う仕組み • 必要権限セットを持った Role を作成し、UserAccount / ServiceAccount に付与 (Binding) Role Based Access Control: 説明 64 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-secrets-global subjects: - kind: User name: example@abema.tv apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
  65. AbemaTV, Inc. All Rights Reserved
 Kubernetes UserAccount の仕様に微妙に違いが・・・ Role Based

    Access Control: 検証 65 GKE • IAM に付与した Role による権限 + ClusterRoleBinding / RoleBinding で リンクした権限 • どちらかに付与されている権限で 操作可能 EKS • ClusterRoleBinding / RoleBinding で リンクした権限でのみ操作可能 • IAM エンティティに AdministratorAccess が付与されていても、 それだけでは操作不可
  66. AbemaTV, Inc. All Rights Reserved
 Role Based Access Control: 経緯

    66 暗号化したファイルをPUSH GCP IAM に依存 • User Account / ServiceAccount 共に GCP IAMにて権限管理 • GCP の GKE Owner / Editor などをそのまま利用 • 誰でも Secret Resource を編集できる状態 背景 クラウド各社に依存せず、不必要な権限を外したい • EKS を利用するにあたり権限管理手法を統一したい • 権限を絞ることで、開発者を守りたい 課題 Kubernetes RBAC のみで完結させる
  67. AbemaTV, Inc. All Rights Reserved
 Role Based Access Control: Role

    設計 67 1 User が複数の Namespace を担当することが多い ABEMA の開発組織に沿った形に • owner : すべての権限 • editor : 全 Namespace の Secret リソースを除いた編集権限 • viewer : 全 Namespace の Secret リソースを除いた閲覧権限 • restricted-editor : 特定 Namespace の Secret リソースを除いた編集権限 • restricted-viewer : 特定 Namespace の Secret リソースを除いた閲覧権限
  68. AbemaTV, Inc. All Rights Reserved
 RBAC 向け Google グループ を活用し社内

    Identity Provider (IDP)と連携 Role Based Access Control: User Account on GCP 68 開発者 IDP 1. 認証 Cloud IAM Kubernetes Engine 2. リクエスト
  69. AbemaTV, Inc. All Rights Reserved
 RBAC 向け Google グループ を活用し社内

    Identity Provider (IDP)と連携 Role Based Access Control: User Account on GCP 69 開発者 IDP 1. 認証 Cloud IAM Kubernetes Engine 2. リクエスト group.editor ├─ user.x └─ user.y group.owner ├─ user.a └─ user.b group.owner └─ オーナー group.editor ├─ 閲覧 └─ Terraform 管理外のサービス編集者 group.owner └─ owner 向け ClusterRole group.editor └─ editor 向け ClusterRole gke-security-group ├─ group.owner └─ group.editor
  70. AbemaTV, Inc. All Rights Reserved
 SAML Federation を活用し社内 Identity Provider

    (IDP) と連携 Role Based Access Control: User Account on AWS 70 開発者 IDP 1. 認証 AWS Cloud (開発 アカウント) 2. SAML認証 AWS Cloud (サービスプロバイダー アカウント) SAML用 AWSサインイン エンドポイント STS 3. リクエスト IAM EKS
  71. AbemaTV, Inc. All Rights Reserved
 SAML Federation を活用し社内 Identity Provider

    (IDP) と連携 Role Based Access Control: User Account on AWS 71 開発者 IDP 1. 認証 AWS Cloud (開発 アカウント) 2. SAML認証 AWS Cloud (サービスプロバイダー アカウント) SAML用 AWSサインイン エンドポイント STS 3. リクエスト IAM EKS group.owner = role/aws-abema-owner group.editor = role/aws-abema-editor role/aws-abema-owner └─ AdministratorAccess role/aws-abema-editor ├─ ReadOnlyAccess └─ Terraform 管理外のサービス Editor group.editor ├─ user.x └─ user.y group.owner ├─ user.a └─ user.b role/aws-abema-owner └─ owner 向け ClusterRole role/aws-abema-editor └─ editor 向け ClusterRole
  72. AbemaTV, Inc. All Rights Reserved
 Role Based Access Control: まとめ

    72 • GKE / EKS ともに同じ Role を設定 ◦ ABEMA のポリシーとして運用可能に ◦ 変更時も同時反映、運用コストの低減
  73. Kubernetes on GCP & AWS 2e. Optimization Node Pool 73

  74. AbemaTV, Inc. All Rights Reserved
 Node Pool: 経緯 74 新しい

    Kubernetes Cluster を構築 • AWS の活用や日本国内リージョンの活用 • 既存 Kubernetes Cluster の構成自体に課題 背景
  75. AbemaTV, Inc. All Rights Reserved
 Node Pool: 経緯 75 同一スペックノード

    同一スペックノード Proxy VM Kubernetes Cluster Internet Service pod Service pod 既存の Node Pool 構成
  76. AbemaTV, Inc. All Rights Reserved
 Node Pool: 経緯 76 新しい

    Kubernetes Cluster を東京リージョンに構築 • AWS の活用や日本国内リージョンの活用 • 既存 Kubernetes Cluster の構成自体に課題 運用コストが高い • ノードのリソース使用効率が悪い • NAT 用の Proxy VM が乱立 • クラスタのリソース不足で担当者が手動でノード追加 背景 課題
  77. AbemaTV, Inc. All Rights Reserved
 Node Pool: 経緯 77 運用コストが高い

    • ノードのリソース使用効率が悪い • 固定 IP 用の Proxy VM が乱立 • クラスタのリソース不足で担当者が手動でノード追加 課題 40%未使用   60%利用 95%利用
  78. AbemaTV, Inc. All Rights Reserved
 Node Pool: 経緯 78 運用コストが高い

    • ノードのリソース使用効率が悪い • NAT 用の Proxy VM が乱立 • Cluster のリソース不足で担当者が手動でノード追加 課題 Service pod Proxy VM Proxy VM Kubernetes Cluster Internet
  79. AbemaTV, Inc. All Rights Reserved
 Node Pool: 経緯 79 運用コストが高い

    • ノードのリソース使用効率が悪い • NAT 用の Proxy VM が乱立 • Cluster のリソース不足で担当者が手動でノード追加 課題
  80. AbemaTV, Inc. All Rights Reserved
 Node Pool: 経緯 80 新しい

    Kubernetes Cluster を東京リージョンに構築 • AWS の活用や日本国内リージョンの活用 • 既存 Kubernetes Cluster の構成自体に課題 運用コストが高い • ノードのリソース使用効率が悪い • NAT 用の Proxy VM が乱立 • Cluster のリソース不足で担当者が手動でノード追加 背景 課題 リソース使用効率が高く、開発者が利用しやすい Cluster を提供したい
  81. AbemaTV, Inc. All Rights Reserved
 これらの要件を満たせる設計を行うこととした • ワークロードの特性に合わせた Node Pool

    によるリソース使用効率の改善 • NAT 用の Node Pool を用意し接続元グローバル IP の振る舞いを変更 • オートスケールできる Node Pool を追加 Node Pool: 要件 81
  82. AbemaTV, Inc. All Rights Reserved
 これらの要件を満たせる設計を行うこととした • ワークロードの特性に合わせた Node Pool

    によるリソース使用効率の改善 • NAT 用の Node Pool を用意し接続元グローバル IP の振る舞いを変更 • オートスケールできる Node Pool を追加 Node Pool: 要件 82
  83. AbemaTV, Inc. All Rights Reserved
 これらの要件を満たせる設計を行うこととした • ワークロードの特性に合わせた Node Pool

    によるリソース使用効率の改善 • NAT 用の Node Pool を用意し接続元グローバル IP の振る舞いを変更 • オートスケールできる Node Pool を追加 Node Pool: 要件 83
  84. AbemaTV, Inc. All Rights Reserved
 これらの要件を満たせる設計を行うこととした • ワークロードの特性に合わせた Node Pool

    によるリソース使用効率の改善 • NAT 用の Node Pool を用意し接続元グローバル IP の振る舞いを変更 • オートスケールできる Node Pool を追加 Node Pool: 要件 84
  85. AbemaTV, Inc. All Rights Reserved
 実現しようとすると以下の課題が発生した • Node Pool の種類が増えると開発者がどこに起動させればよいかわからない

    • GKE, EKS と構成が異なるとプラットフォームごとに対応を変える必要がある • Node のスケールイン、スケールアウトでそれぞれの課題が発生する Node Pool: 新たな課題 85
  86. AbemaTV, Inc. All Rights Reserved
 実現しようとすると以下の課題が発生した • Node Pool の種類が増えると開発者がどこに起動させればよいかわからない

    • GKE, EKS と構成が異なるとプラットフォームごとに対応を変える必要がある • Node のスケールイン、スケールアウトでそれぞれの課題が発生する Node Pool: 新たな課題 86
  87. AbemaTV, Inc. All Rights Reserved
 実現しようとすると以下の課題が発生した • Node Pool の種類が増えると開発者がどこに起動させればよいかわからない

    • GKE, EKS と構成が異なるとプラットフォームごとに対応を変える必要がある • Node のスケールイン、スケールアウトでそれぞれの課題が発生する Node Pool: 新たな課題 87 Kubernetes Engine
  88. AbemaTV, Inc. All Rights Reserved
 実現しようとすると以下の課題が発生した • Node Pool の種類が増えると開発者がどこに起動させればよいかわからない

    • GCP, AWS と構成が異なるとプラットフォームごとに対応を変える必要がある • Node のスケールイン、スケールアウトでそれぞれの課題が発生する Node Pool: 新たな課題 88 Kubernetes Cluster Service pod Service pod pod が再起動されてしま う
  89. AbemaTV, Inc. All Rights Reserved
 実現しようとすると以下の課題が発生した • Node Pool の種類が増えると開発者がどこに起動させればよいかわからない

    • GCP, AWS と構成が異なるとプラットフォームごとに対応を変える必要がある • Node のスケールイン、スケールアウトでそれぞれの課題が発生する Node Pool: 新たな課題 89 Kubernetes Cluster Service pod Service pod Node が起動するまで Pending 状態となる
  90. AbemaTV, Inc. All Rights Reserved
 Node Pool: 新たな課題 90 Kubernetes

    Cluster Node が起動するのに数 分かかる Service pod Service pod 実現しようとすると以下の課題が発生した • Node Pool の種類が増えると開発者がどこに起動させればよいかわからない • GCP, AWS と構成が異なるとプラットフォームごとに対応を変える必要がある • Node のスケールイン、スケールアウトでそれぞれの課題が発生する
  91. AbemaTV, Inc. All Rights Reserved
 Node Pool: 設計 91 Managed

    NAT Service Kubernetes Cluster Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable) Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable)
  92. AbemaTV, Inc. All Rights Reserved
 Node Pool: 設計 92 Managed

    NAT Service Kubernetes Cluster Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable) Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable)
  93. AbemaTV, Inc. All Rights Reserved
 Node Pool: 設計 93 Managed

    NAT Service Kubernetes Cluster Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable) Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable)
  94. AbemaTV, Inc. All Rights Reserved
 Node Pool: 設計 94 Managed

    NAT Service Kubernetes Cluster Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable) Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable)
  95. AbemaTV, Inc. All Rights Reserved
 Node Pool: 設計 95 Managed

    NAT Service Kubernetes Cluster Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable) Node Pool: High CPU Type (Fixed) Node Pool: High CPU Node Pool (Auto Scalable) Node Pool: High Memory Type (Fixed) Node Pool: High Memory Node Pool (Auto Scalable)
  96. AbemaTV, Inc. All Rights Reserved
 内容 • 適切な Node Pool

    をチェックシートで判断した Kustomize Patch を適用 • GKE は ip-masq-agent と Cloud NAT , EKS は NAT Gateway で NAT 化 • Node リソースは AWS に合わせて GCP では Custom Instance を活用 • Auto Scale を無効にした Fixed Node Pool を活用 • Balloon Pod を活用した即時スケールアウト Node Pool: 課題の解決方法 96
  97. AbemaTV, Inc. All Rights Reserved
 内容 • 適切な Node Pool

    をチェックシートで判断した Kustomize Patch を適用 • GKE は ip-masq-agent と Cloud NAT , EKS は NAT Gateway で NAT 化 • Node リソースは AWS に合わせて GCP では Custom Instance を活用 • Auto Scale を無効にした Fixed Node Pool を活用 • Balloon Pod を活用した即時スケールアウト Node Pool: 課題の解決方法 97
  98. AbemaTV, Inc. All Rights Reserved
 チェックシート 98 NAT IP を

    利用する 1 vCPU に対して Memory 2 GiB 以下 再配置を 許容できる 再配置を 許容できる NAT IP を 利用する NAT IP を 利用する NAT IP を 利用する Yes ex: High CPU Workload No ex: High Memory Workload Yes No Yes No private-cpu .yaml Yes No public-cpu .yaml private-cpu -asg.yaml Yes No public-cpu -asg.yaml private-mem -asg.yaml Yes No public-mem- asg.yaml private-mem .yaml Yes No public-mem .yaml
  99. AbemaTV, Inc. All Rights Reserved
 目的 • Node Pool の選択方法の簡略化

    内容 • Node Pool 毎の Patch を提供 • PriorityClass, NodeAffinity を設定 Kustomize Patch 99 apiVersion: apps/v1 kind: Deployment metadata: name: deployment spec: template: spec: priorityClassName: middle-priority affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: type operator: In values: - public-cpu - public-cpu-asg preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: type operator: In values: - public-cpu-asg ※ public-cpu-asg.yaml ファイル
  100. AbemaTV, Inc. All Rights Reserved
 内容 • 適切な Node Pool

    をチェックシートで判断した Kustomize Patch を適用 • GKE は ip-masq-agent と Cloud NAT , EKS は NAT Gateway で NAT 化 • Node リソースは AWS に合わせて GCP では Custom Instance を活用 • Auto Scale を無効にした Fixed Node Pool を活用 • Balloon Pod を活用した即時スケールアウト Node Pool: 課題の解決方法 100
  101. AbemaTV, Inc. All Rights Reserved
 GKE の NAT 構成 101

    Cloud NAT GKE Cluster ※ Subnet Public Node Pools Nodes ip-masq-agent-public DaemonSet Private Node Pools Nodes ip-masq-agent-private DaemonSet ※ GKE Cluster は Public Cluster を利用している
  102. AbemaTV, Inc. All Rights Reserved
 EKS の NAT 構成 102

    NAT Gateway EKS Cluster Subnet: public Public Node Pools Nodes Private Node Pools Nodes Subnet: private
  103. AbemaTV, Inc. All Rights Reserved
 内容 • 適切な Node Pool

    をチェックシートで判断した Kustomize Patch を適用 • GKE は ip-masq-agent と Cloud NAT , EKS は NAT Gateway で NAT 化 • Node リソースは AWS に合わせて GCP では Custom Instance を活用 • Auto Scale を無効にした Fixed Node Pool を活用 • Balloon Pod を活用した即時スケールアウト Node Pool: 課題の解決方法 103
  104. AbemaTV, Inc. All Rights Reserved
 目的 • クラウド各社の差異を吸収する 設計 •

    AWS の Instance Type に合わせる • CPU, Memory でそれぞれ定義する • Terraform では次のように指定できる Custom Instance 104 variable "cpu_machine_type" { // 8 vCPU 16 GiB Memory default = "n2-custom-8-16384" } variable "mem_machine_type" { // 4 vCPU 32 GiB Memory default = "n2-custom-4-32768" } ※ EKS の Terraform Variables ファイル variable "cpu_machine_type" { // 8 vCPU 16 GiB Memory default = "c5.2xlarge" } variable "mem_machine_type" { // 4 vCPU 32 GiB Memory default = "r5.xlarge" } ※ GKE の Terraform Variables ファイル
  105. AbemaTV, Inc. All Rights Reserved
 内容 • 適切な Node Pool

    をチェックシートで判断した Kustomize Patch を適用 • GKE は ip-masq-agent と Cloud NAT , EKS は NAT Gateway で NAT 化 • Node リソースは AWS に合わせて GCP では Custom Instance を活用 • Auto Scale を無効にした Fixed Node Pool を活用 • Balloon Pod を活用した即時スケールアウト Node Pool: 課題の解決方法 105
  106. AbemaTV, Inc. All Rights Reserved
 目的 • Pod の再配置を減らす 設計

    • Auto Scale しない Node Pool を提供 Fixed Node Pool 106 ※ Node Pool の用途を記載した資料
  107. AbemaTV, Inc. All Rights Reserved
 内容 • 適切な Node Pool

    をチェックシートで判断した Kustomize Patch を適用 • GKE は ip-masq-agent と Cloud NAT , EKS は NAT Gateway で NAT 化 • Node リソースは AWS に合わせて GCP では Custom Instance を活用 • Auto Scale を無効にした Fixed Node Pool を活用 • Balloon Pod を活用した即時スケールアウト Node Pool: 課題の解決方法 107
  108. AbemaTV, Inc. All Rights Reserved
 目的 • Node スケールアウト時間の短縮 設計

    • Balloon Pod 用の Priority Class (-5) を定義 • 通常の Pod よりも優先度を低くする • 約 6 割の Resource Request を設定する Balloon Pod 108 apiVersion: apps/v1 kind: Deployment metadata: namespace: balloon name: balloon-private-cpu spec: template: spec: priorityClassName: balloon-priority containers: - name: app image: google/cloud-sdk:alpine resources: requests: cpu: 4800m # 6割のリソース memory: 9.6Gi # 6割のリソース ※ Balloon Pod の Deployment Manifest ファイル
  109. AbemaTV, Inc. All Rights Reserved
 Balloon Pod 109 application pod

    application pod balloon pod
  110. AbemaTV, Inc. All Rights Reserved
 Balloon Pod 110 application pod

    application pod balloon pod application pod New Scheduled evicted
  111. AbemaTV, Inc. All Rights Reserved
 Balloon Pod 111 application pod

    application pod balloon pod application pod Pending pod
  112. AbemaTV, Inc. All Rights Reserved
 Balloon Pod 112 application pod

    application pod balloon pod New Node application pod
  113. AbemaTV, Inc. All Rights Reserved
 コスト最適化 • Auto Scale Node

    Pool の活用により必要に応じたキャパシティを確保 • ワークロードの特性に合わせた Node Pool により Node リソース使用効率を改善 利便性の向上 • Balloon Pod による Node スケールアウト時間を短縮 • 全ての Kubernetes Cluster において同一手段による NAT 化を実現 • 全ての Kubernetes Cluster において同一手段による Node Pool の選択を実現 Node Pool: まとめ 113
  114. 3. まとめ 114

  115. AbemaTV, Inc. All Rights Reserved
 透過的なマルチクラウド活用の基盤構築 • 冗長化用途での活用 • フルマネージドサービスの活用

    • シームレスなクラウド間連携 • セキュリティ/コスト管理の整備 115 まとめ GCP AWS Container Monitoring Authentication ServiceMesh Security
  116. AbemaTV, Inc. All Rights Reserved
 高可用性プラットフォームへの挑戦 • Multi Region Kubernetes

    Cluster • 東日本/西日本レベルでの災害に対する冗長化 • 更なる同時接続数を許容できるキャパシティ 今後の展望 116
  117. 117