Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

10,067 views

Published on

GCP Next Tokyo 2016

Published in: Technology

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

  1. 1. Google Container Engine と Kubernetes で 無理をしないコンテナ管理 株式会社サイバーエージェント 技術本部 サービスリライアビリティグループエンジニア兼マネージャー 須藤 涼介
  2. 2. 2 自己紹介 ● 須藤涼介(Suto Ryosuke) ● 株式会社サイバーエージェント ● 技術本部サービスリライアビリティグループ(SRG) ● カスタマーサポート→アメーバピグ→ネットワーク→コミュニ ティ系サービス→ソーシャルゲーム→AbemaTV
  3. 3. 3 アジェンダ ● AbemaTVの紹介 ● GKEの選定理由 ● GKE利用のメリット ● 苦労したこと ● 導入した感想と課題
  4. 4. 4 株式会社サイバーエージェント ● メディア事業 ● インターネット広告事業 ● ゲーム事業 ● 投資育成事業 「21世紀を代表する会社を創る」
  5. 5. 5 インターネットテレビ局「AbemaTV」 株式会社AbemaTV: 株式会社サイバーエージェントと株式会社テレビ朝日の共同出資により 2015年4月設立 会員登録不要 無料で利用可能 コメントや動画の投稿などの SNS連携機能 スマートデバイスに合わせた UI/UX 見逃し配信 オンデマンド機能(月額 960円) テレビのような受け身視聴  24時間365日配信
  6. 6. 6 インターネット技術で「テレビ」を再現する
  7. 7. 7 アーキテクチャ
  8. 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. 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. 10 GKE at AbemaTV ● ホストOS : Debian GNU/Linux 7 ● Kubernetes v1.2.0 ● Docker 1.9.1 ● ベースイメージ : Alpine Linux, Ubuntu
  11. 11. 11 なぜDockerを選択したか? ● マイクロサービスアーキテクチャとの親和性 ○ 各機能ごとに機能開発、リリース、スケール計画 ○ 追加機能でインフラの準備が必要ない ○ カナリアリリース ● 迅速で容易なスケーラビリティ
  12. 12. 12 なぜGKEを選択したか ● 2015年8月にGKEの正式版が公開(GA) ● マネージドサービスとして提供されている ○ MasterやDockerレジストリの管理が不要 ● インスタンスグループによるクラスター管理 ● OSSによる活発な開発、アップデート
  13. 13. 13 利用するメリット ● 実行環境の差がなくなる ● クラスタのスケールが容易 ● Stackdriver Loggingとの連携 ○ 各コンテナの標準出力はStackdriver Loggingに
  14. 14. 14 苦労したこと
  15. 15. 15 Podとクラスタのオートスケール設計 ● Podのスケール設定はKubernetesのHPA(Horizontal Pod Autoscaling) ● クラスタのスケール設定はGCEのInstance Group ● 協調するバランスが難しい →現状は手動でコントロールしている
  16. 16. 16 負荷試験でQuota制限 ● 負荷試験でPodのスクラップ&ビルド増加 ● Cloud Logging APIのQuota制限 ○ 負荷を調査したいのにログが出ない ● Cloud Monitoring APIのQuota制限 ○ 負荷を調査したいのにリソースが(以下略
  17. 17. 17 運用してみての感想 ● プロビジョニングツールがいらない ● DevとOpsの距離が近づく ○ アプリケーションエンジニアとインフラエンジニアが同じリ リースフロー、開発サイクルで作業できる ■ Dockerイメージ作成 ■ Replication Controller(Deployment)の更新
  18. 18. 18 今後の課題 ● GKEクラスターのリソース管理 ○ Requests, Limitsの最適化 ○ クラスタのオートスケール ● Multi-Zone対応
  19. 19. 19 GKEではじめよう

×