GCP Next Tokyo 2016

1. Google Container Engine と Kubernetes
で 無理をしないコンテナ管理
株式会社サイバーエージェント 技術本部
サービスリライアビリティグループエンジニア兼マネージャー
須藤 涼介

2. 2
自己紹介
● 須藤涼介（Suto Ryosuke）
● 株式会社サイバーエージェント
● 技術本部サービスリライアビリティグループ（SRG）
● カスタマーサポート→アメーバピグ→ネットワーク→コミュニ
ティ系サービス→ソーシャルゲーム→AbemaTV

3. 3
アジェンダ
● AbemaTVの紹介
● GKEの選定理由
● GKE利用のメリット
● 苦労したこと
● 導入した感想と課題

4. 4
株式会社サイバーエージェント
● メディア事業
● インターネット広告事業
● ゲーム事業
● 投資育成事業
「21世紀を代表する会社を創る」

5. 5
インターネットテレビ局「AbemaTV」
株式会社AbemaTV: 株式会社サイバーエージェントと株式会社テレビ朝日の共同出資により 2015年4月設立
会員登録不要 無料で利用可能 コメントや動画の投稿などの SNS連携機能
スマートデバイスに合わせた UI/UX 見逃し配信 オンデマンド機能（月額 960円）
テレビのような受け身視聴 24時間365日配信

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

7. 7
アーキテクチャ

8. 8
● Master：クラスタを管理
○ GKEでは表示されない
● Minion：Dockerが起動するノード
● Pod：コンテナのグループ
● Replication Controller：起動するPod数
や環境変数を管理（Replica Sets）
● Service：Pod郡のエンドポイント
Node1
Minion1
RC1 Pod1-1
Pod1-2
Pod2-1
Pod2-2
Service1 Service2
Kubernetesの構成

9. 9
apiVersion: v1
kind: ReplicationController
metadata:
name: abema-xxx
spec:
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: v1
kind: Service
metadata:
name: abema-xxx
labels:
name: abema-xxx
spec:
selector:
name: abema-xxx
ports:
- port: 8484 ↓Pod郡にアクセスするためのポート
nodePort: 30200
protocol: TCP
name: http
type: NodePort
ReplicationController.yaml Service.yaml

10. 10
GKE at AbemaTV
● ホストOS : Debian GNU/Linux 7
● Kubernetes v1.2.0
● Docker 1.9.1
● ベースイメージ : Alpine Linux, Ubuntu

11. 11
なぜDockerを選択したか？
● マイクロサービスアーキテクチャとの親和性
○ 各機能ごとに機能開発、リリース、スケール計画
○ 追加機能でインフラの準備が必要ない
○ カナリアリリース
● 迅速で容易なスケーラビリティ

12. 12
なぜGKEを選択したか
● 2015年8月にGKEの正式版が公開（GA）
● マネージドサービスとして提供されている
○ MasterやDockerレジストリの管理が不要
● インスタンスグループによるクラスター管理
● OSSによる活発な開発、アップデート

13. 13
利用するメリット
● 実行環境の差がなくなる
● クラスタのスケールが容易
● Stackdriver Loggingとの連携
○ 各コンテナの標準出力はStackdriver Loggingに

14. 14
苦労したこと

15. 15
Podとクラスタのオートスケール設計
● Podのスケール設定はKubernetesのHPA（Horizontal Pod Autoscaling）
● クラスタのスケール設定はGCEのInstance Group
● 協調するバランスが難しい
→現状は手動でコントロールしている

16. 16
負荷試験でQuota制限
● 負荷試験でPodのスクラップ&ビルド増加
● Cloud Logging APIのQuota制限
○ 負荷を調査したいのにログが出ない
● Cloud Monitoring APIのQuota制限
○ 負荷を調査したいのにリソースが（以下略

17. 17
運用してみての感想
● プロビジョニングツールがいらない
● DevとOpsの距離が近づく
○ アプリケーションエンジニアとインフラエンジニアが同じリ
リースフロー、開発サイクルで作業できる
■ Dockerイメージ作成
■ Replication Controller（Deployment）の更新

18. 18
今後の課題
● GKEクラスターのリソース管理
○ Requests, Limitsの最適化
○ クラスタのオートスケール
● Multi-Zone対応

19. 19
GKEではじめよう