Google Container Engine と Kubernetes で 無理をしないコンテナ管理

株式会社サイバーエージェント 技術本部

サービスリライアビリティグループエンジニア兼マネージャー

須藤 涼介

2

自己紹介

● 須藤涼介（Suto Ryosuke）● 株式会社サイバーエージェント

● 技術本部サービスリライアビリティグループ（SRG）

● カスタマーサポート→アメーバピグ→ネットワーク→コミュニ

ティ系サービス→ソーシャルゲーム→AbemaTV

3

アジェンダ

● AbemaTVの紹介

● GKEの選定理由

● GKE利用のメリット

● 苦労したこと

● 導入した感想と課題

4

株式会社サイバーエージェント

● メディア事業

● インターネット広告事業

● ゲーム事業

● 投資育成事業

「21世紀を代表する会社を創る」

5

インターネットテレビ局「AbemaTV」

株式会社AbemaTV: 株式会社サイバーエージェントと株式会社テレビ朝日の共同出資により 2015年4月設立

会員登録不要　無料で利用可能 コメントや動画の投稿などの SNS連携機能

スマートデバイスに合わせた UI/UX 見逃し配信　オンデマンド機能（月額 960円）

テレビのような受け身視聴　 24時間365日配信

6

インターネット技術で「テレビ」を再現する

7

アーキテクチャ

8

● Master：クラスタを管理

○ GKEでは表示されない

● Minion：Dockerが起動するノード

● Pod：コンテナのグループ

● Replication Controller：起動するPod数や環境変数を管理（Replica Sets）

● Service：Pod郡のエンドポイント

Node1Minion1

RC1 Pod1-1

Pod1-2

Pod2-1

Pod2-2

Service1 Service2

Kubernetesの構成

9

apiVersion: v1kind: ReplicationControllermetadata: name: abema-xxxspec: replicas: 4 ←起動するPodの数 selector: name: abema-xxx template: metadata: labels: name: abema-xxx environment: dev spec: containers: - name: abema-xxx ↓環境変数 env: - name: ENV value: development - name: REDIS_ADDR value: redis-a:6379,redis-b:6379,redis-c:6379 image: asia.gcr.io/[projectid]/abema-xxx:v1.1.0 ports: ↑起動するDockerイメージとタグ - containerPort: 30500 protocol: TCP initialDelaySeconds: 15 timeoutSeconds: 5

apiVersion: v1kind: Servicemetadata: name: abema-xxx labels: name: abema-xxxspec: selector: name: abema-xxx ports: - port: 8484 ↓Pod郡にアクセスするためのポート

nodePort: 30200 protocol: TCP name: http type: NodePort

ReplicationController.yaml Service.yaml

10

GKE at AbemaTV

● ホストOS : Debian GNU/Linux 7

● Kubernetes v1.2.0

● Docker 1.9.1

● ベースイメージ : Alpine Linux, Ubuntu

11

なぜDockerを選択したか？

● マイクロサービスアーキテクチャとの親和性

○ 各機能ごとに機能開発、リリース、スケール計画

○ 追加機能でインフラの準備が必要ない

○ カナリアリリース

● 迅速で容易なスケーラビリティ

12

なぜGKEを選択したか

● 2015年8月にGKEの正式版が公開（GA）

● マネージドサービスとして提供されている

○ MasterやDockerレジストリの管理が不要

● インスタンスグループによるクラスター管理

● OSSによる活発な開発、アップデート

13

利用するメリット

● 実行環境の差がなくなる

● クラスタのスケールが容易

● Stackdriver Loggingとの連携

○ 各コンテナの標準出力はStackdriver Loggingに

14

苦労したこと

15

Podとクラスタのオートスケール設計

● Podのスケール設定はKubernetesのHPA（Horizontal Pod Autoscaling）

● クラスタのスケール設定はGCEのInstance Group

● 協調するバランスが難しい

→現状は手動でコントロールしている

16

負荷試験でQuota制限

● 負荷試験でPodのスクラップ&ビルド増加● Cloud Logging APIのQuota制限

○ 負荷を調査したいのにログが出ない● Cloud Monitoring APIのQuota制限

○ 負荷を調査したいのにリソースが（以下略

17

運用してみての感想

● プロビジョニングツールがいらない

● DevとOpsの距離が近づく

○ アプリケーションエンジニアとインフラエンジニアが同じリ

リースフロー、開発サイクルで作業できる

■ Dockerイメージ作成

■ Replication Controller（Deployment）の更新

18

今後の課題

● GKEクラスターのリソース管理○ Requests, Limitsの最適化○ クラスタのオートスケール

● Multi-Zone対応

19

GKEではじめよう