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

by CyberAgent

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

前回の ABEMA Developer Conference 2018 から比較した 1. Cloud Architecture の変遷 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

今回は Kubernetes 周辺システムや各種設計を紹介します 2. Kubernetes on GCP & AWS

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

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. サービスの細分化が加速し、異なる特性を持ったワークロードが増加した

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Kubernetes on GCP & AWS 2a. Cloud Edge Proxy

Slide 22

Slide 22 text

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

AbemaTV, Inc. All Rights Reserved  Cloud Edge Proxy: 技術選定 27 柔軟な拡張性や Capacity Planning の観点から Envoy Proxy を採用 VPN Connection ● 方式: IPsec ● サポート: GCP & AWS ● 運用・保守コスト: 低い ● ランニングコスト: 高い ● Routing 制御: 不可 Envoy Proxy ● 方式: Mutual TLS ● サポート: コミュニティ ● 運用・保守コスト: 高い ● ランニングコスト: 低い ● Routing 制御: 可能

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Kubernetes on GCP & AWS 2b. Service Mesh 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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) 方式も選択可能

Slide 39

Slide 39 text

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) 方式も選択可能

Slide 40

Slide 40 text

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) 方式も選択可能

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Kubernetes on GCP & AWS 2c. Secret Resource 45

Slide 46

Slide 46 text

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 で作成するケースが発生課題

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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 を導入可能にし一貫性を持った管理手法に変更

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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-----" }

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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 で暗号化

Slide 59

Slide 59 text

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 }}"

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Kubernetes on GCP & AWS 2d. Role Based Access Control 63

Slide 64

Slide 64 text

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: [email protected] apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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 のみで完結させる

Slide 67

Slide 67 text

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 リソースを除いた閲覧権限

Slide 68

Slide 68 text

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Kubernetes on GCP & AWS 2e. Optimization Node Pool 73

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Slide 87

Slide 87 text

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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)

Slide 92

Slide 92 text

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)

Slide 93

Slide 93 text

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)

Slide 94

Slide 94 text

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)

Slide 95

Slide 95 text

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)

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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 ファイル

Slide 100

Slide 100 text

Slide 101

Slide 101 text

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 を利用している

Slide 102

Slide 102 text

Slide 103

Slide 103 text

Slide 104

Slide 104 text

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 ファイル

Slide 105

Slide 105 text

Slide 106

Slide 106 text

Slide 107

Slide 107 text

Slide 108

Slide 108 text

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 ファイル

Slide 109

Slide 109 text

Slide 110

Slide 110 text

Slide 111

Slide 111 text

Slide 112

Slide 112 text

Slide 113

Slide 113 text

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