Google Cloud Kubernetes Day 2019 セミナーメモ

Google Cloud Kubernetes Day 2019

2019/9/3　14:00～18:00

Google Cloud 主催のKubernetes関連の半日セミナー。実際の事例やGoogle Kubernetes Engine（GKE）の機能更新情報等の紹介等のセッション。

やっぱりKubernetes難しいな。。。具体的な実装方法などの話になるとついていけない箇所もチラホラ・・・

GoogleがマネージドKubernetes環境周辺を充実させようとしているのはよく分かった。

Anthos含めて、やっぱりGKEのシェアは確保したいところなんだろうな。（もともとGoogle発祥だし）

1：失敗しないアプリケーションモダナイゼーションの考え方　～アセスメントから開発アプローチ～

• モダナイゼーション

  • クラウドの利用
  • →クラウドネイティブ
  • →マイクロサービス
  • →Twelve-factor App

• Twelve-Factor App

  • セットアップ自動化
  • 実行環境間での移植性
  • アジリティを最大化する継続的なデプロイ
  • スケールアップ
  • モダンなクラウドプラットフォーム

• マイクロサービス

  • 小さなプロセス・コンテナを組み合わせてシステムを構築

• クラウドネイティブ

  • コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型API
  • 疎結合システム
  • インパクトのある変更を最小限の労力で頻繁かつ予測通りに行うことができる

• マイクロサービスのサンプルコード

  https://GitHub.com/GoogleCloudPlatform/microservices-demo

• パネルディスカッション：富士フィルム、フリークアウト

  • 富士フィルム
    • Prints & Gifts
      • プリントや写真雑貨を注文できるサービス
      • バックエンドの注文管理システム（OMS:Order Management System)を開発
  • フリークアウト
    • 広告関連プロダクト
    • Red for Publishers
      • プレミアムメディア向けアドプラットフォーム
      • 自社アドネットワークの基盤としても使用
        • 製品名：Poets
          • ほぼすべてをGCPで

• アーキテクチャ、DevOps導入について

  • 富士フィルム
    • 課題：注文管理システム：レガシーシステム（運用10年越え）のリプレース
      • スケーラビリティの確保
      • 保守・運用コスト
      • 機能改善スピードの向上
    • マイクロサービスアーキテクチャを導入
      • コンテナ（Docker）＋コンテナ管理（Kubernetes）
      • GCP（GKE）：当時GCPのみK8sマネージドサービス提供
      • 3か月半程度で切り替え
      • コンテナ等の実績なしの状態から3か月で検証、移行まで実行
    • 効果
      • 課題の解決は問題なし
      • GKE利用でスピーディな稼働
  • フリークアウト：Red for Publishers
    • スクラッチからクラウドネイティブに移行
    • GKE
      • Deploymentは10個程度（アプリケーションごと）
      • バッチはCloud Composer
      • ログはfluentdからBigQueryにStreaming Insert
      • CircleCIを利用した継続テスト
      • Cloud BUildによるCI
      • 構成変更はDeveloper,SRE問わず相互レビューで\実施
  • 疑問：サーバレスアーキテクチャとK8sどちらがよいか？
    • スケーラビリティの面ではK8s
    • 複数のアプリケーションが相互に連携する場合はK8sのほうが有利
    • サーバレスが生きる環境（システム）もある

• チーム体制について

  • 富士フィルム
    • 体制
      • 開発、運用・構築、QA、技術支援
    • 課題、対策
      • 周りの理解（経営層、技術者層）
      • 知識・実績
      • 失敗リスクの影響範囲の最小化
        • 技術学習（社内セミナー、独学、ハンズオン）
        • 資料作成＆説明行脚
        • スモールスタート（小規模PJ）
        • Googleサポートの支援体制
      • 連帯感の重要性（開発、インフラエンジニア、部門横断エンジニア）
        • 認識合わせ、技術習得などの連携強化
          • YAMLをどっちが書く？などの細かい話も相談しながら
      • サービス分割
        • バランスが重要。分割しすぎると制御＆障害対応時の難しさ
  • フリークアウト：Red for Publishers
    • 体制
      • Developer:11名
      • SRE:2名
      • Product Manager:2名
      • 大規模なインフラ構成運用はSRE中心（広告系：リリース頻度がはやい）
        • Kubernetes Update、Cloud Composer導入など
        • Terraform導入中
      • 日々の構成はDeveloperも運用を行う
        • ConfigMap（Fluentd.conf,nginx.confなど）
        • MySQL、BigQueryスキーマ変更

• これからアプリケーションをモダナイズしようとしている企業に向けて

  • クラウドネイティブ前提で進めるべき
    • クラウドを前提とした設計
    • コンテナベースで構築
      • →K8sへ
  • 適材適所、バランス
    • IaaS,コンテナ、FaaS等選択肢はたくさんある。バランスをとって行う
  • スモールスタートで少しずつ心配を取り除いていく
  • 各社の事例をキャッチアップしながら進めていくべき
  • GKEの運用面（StackDriverとの統合周りなど）の便利さを利用
    • マネージメントサービスで運用面で便利なものはぜひ利用すべき

• （※パネルディスカッション終了）

• Google Cloud 担当者講演：DevOpsについて

  • ソフトウェアが世界を飲み込む
  • DevOpsでアイディアをマーケットにより早く持ち込む
  • DevOpsの重要性
    • 1.53x：目標達成、もしくは超える可能性が1.53倍になる
  • Kubernetes登場による変化
    • 従来の開発運用：ソフトウェアエンジニアはソースコードを、インフラエンジニアがプラットフォームを担当し、VMとしてオペレータに届け、運用する
      • オペレータが運用内での気づきを反映しようとしても、オペレータだけでは実施できない：ソフトウェア／インフラエンジニアへの依頼が必要
      • 複数の関係者と連携・作業が必要で迅速な作業、サービス提供ができなかった
    • Kubernetesを使った開発運用の変化
      • ソフトウェア／インフラエンジニア、オペレータが独立してそれぞれの作業を担当しつつ、それらが協調してサービス提供をできるように
  • DevOpsを実践する際の問題
    • 開発と運用
      • インセンティブが一致しない
        • 開発：アジリティ
        • 運用：安定性
    • 合理的でない安定性の定義
      • ダウンタイムなし
      • 99.999999999％の稼働率
        • →合理的でない、現実的でもない
          • 解決策
            • 要求する「安定」を定義して計測する
            • 経営層、決定権のある人からのサポートを得て、組織、チーム間の壁を取り払う
    • 安定性の定義
      • システム運用者の考える安定性とユーザの安定性にはギャップがある
        • システムは99.9%、ユーザは98.9%でいいかも？とか
    • 安定性の計測
      • 率直なアプローチ
        • Availability= good time / total time
      • 人間にとって直感的
      • アップタイムなどのバイナリメトリクスより比較的簡単に計測可能
      • マイクロサービスの場合、計測はチャレンジが必要
        • リクエストが来ていないマイクロサービスはダウンしているのか？
    • Opsに求められること
      • 安定性の最適化
        • Reliability = MTBF / MTBF + MTTR X Impact
        • ITSシステムにおけるMTTR = Time To Detect(TTD) + Time To Medicate (TTM)
      • 改善の方向性
        • MTBF=　障害報告書
        • TTD = モニタリング
        • TTM =　ツール、トレーニング、自動化、ドキュメント
        • Impact =　エンジニアリング（なるべくインパクトが出ない構成にする）、チェンジマネジメント（変更時にインパクトがないように手順を構築する）
  • まとめ
    • ソフトウェアがビジネスの中心になり、以前にもましてDevOpsの重要性が増す
    • Kubernetesにより、技術的にDevOpsを実現しやすくなった
    • Opsには安定性の最適化が求められ、役割は以前にもまして重要に
    • 参考書籍
      • "Site Reliability Engineering" by O'reilly

2：Anthosで実現するモダンなアプリケーション管理プラットフォーム

• 2025年の崖
  • IT人材の不足
  • データの爆発
    • 世界のデータ量が33ZBから175ZBへ急激に増加
  • 技術的負債の増加
    • 既存システムが部門ごとに構築され、全社横断的なデータ活用ができない
  • 提言されている対策
    • モダナイズ、不要なものは塩漬け
  • これから作るものはどうする？
    • 今から技術的負債を増やさないためにこれからの開発はどうあるべきか？
      • Agility：敏捷性
      • Flexibility：柔軟性
      • Maintainability：保守性
        • 新しい考え方を取り入れ、モダンなアプリケーションへ
    • 現時点ではコンテナ基盤が増えている
      • Kubernetesをどう使うかが重要：すでにデファクト
    • Kubernetes導入時にぶつかる壁
      • どこで動かす？
      • 運用が大変
        • 3か月ごとにアップデートされる
      • 複数環境をどう扱う？
      • 足りない機能は？
        • メッセージキューなど
    • 自社のエンジニア力で突破する場合
      • オンプレ＋クラウド
      • 自社で専門家育成
      • 各種OSS、自社運用
      • クラウド利用、自社開発
        • →すべての会社がこれをできるわけではない
    • Anthos＋GCPがKubernetesをProduction Readyへ
      • ハイブリッド＋マルチクラウド
      • マネージドKubernetes（GKE）+ α
      • マネージドで複数環境の一元管理
      • GCPの各種サービス
  • Anthos Control Plane
    • クラスタ管理
      • GKE、GKE On-Prem
    • ポリシー管理
      • Anthos Config Management
    • サービス管理
      • Google cloud Service Mesh
• Anthos Deep Dive
  • GKE On-Prem
    • VMware環境上で稼働するプロダクショングレードのKubernetes
  • GCP ConsoleからGKEを一元管理
  • GCP Console経由でオンプレKubernetesにセキュアに接続可能
  • ポリシー管理
    • Anthos Config Management
      • Namespace や　Resource Quota等の環境管理
  • サービス管理
    • Service Mesh
      • Anthosの中の一部
      • フルマネージドサービスメッシュ
      • A.K.A Managed Istio
    • 可観測性
      • CLOを設定し、実際にモニタリングできる、など
    • トラフィックコントロール
    • セキュリティ
• まとめ
  • Anthosはハイブリッドおよびマルチクラウドで動作するアプリケーションモニタリングプラットフォーム
  • Anthosでモダンなアプリケーション開発・運用を実現

3：ユーザから見たAhthos GKE On-Premの利用について

• GKEとGKE On-Premについて
  • 使う前に
    • アップデート情報に常にアンテナをはる
      • GKE,GKE On-premとも常に多くのアップデートが走っている
      • Kubernetes自体も独立してアップデートを繰り返している
    • 組織的に学習する環境を整備する
      • Kubernetesの導入は簡単ではない
      • 組織的に学習できることが重要、文化づくり
    • リーダーの理解を得る、説明責任を果たす
      • ITの経験が浅い人に説明する機会がつきもの
        • 導入メリットや解決したい課題を丁寧に説明する必要がある
  • Managed Kubenetesにもとめるもの
    • Kubernetesアップデートをサポートしているか
    • 周辺ツールのサポート、統合のケイパビリティ
      • CI/CD周りのサポート、認証・認可の容易さ
    • ネットワーク、ストレージとの統合
      • ロードバランサの選択など
  • Anthosのユーザーとしての理解：GKEをどこでも
  • Kubernetesの運用はManaged Serviceを利用する選択肢が原則ベストである
    • 導入前に組織としてKubernetesを利用するための体制づくり、常に情報をアップデートしていくことが重要
• 環境構築について
  • 実行環境を考える、既存環境との統合は慎重に
    • ネットワークの構成・特性を理解
    • ワークロードの特性を見る　ステートをどうするか
  • GKE On-Prem：kubecltlとgkectlでツール提供
    • gkectlでAdmin Control
  • インフラ面
    • GKE On-PremはvSphere上で動作し、L4としてF5　Big IPをサポート
  • GKE On-PremとGKEをハイブリッドで利用する場合
    • クラスタ内部のネットワーク設計
    • 外部の設計
    • が必要
  • GKE On-Premはあるべき姿にデプロイするのが難しい
    • ネットワーク構成等、コンサルティング等を適切に利用しながら導入
• ベストプラクティス
  • 認証・認可を適切に設定
    • 初めに：RBACの概念を浸透させる
      • リソースを、誰が、なにに、どのレベルでアクセスできるかを考える
    • RBACとIAMを適切に管理
    • Open ID Connectベースの認証可能
      • G Suiteのアカウントベースログイン可能
    • OICDのほかに、Kubernetes標準の機能を利用して、サービスアカウントベースの認証・認可も可能
  • デプロイパイプラインの設計
    • CI/CDパイプライン
      • 開発からオペレーションに至る一貫したプロセスの自動化
        • Image Registry：　Docker Regisytry vs　Cloud Build
  • メトリクス管理
    • SLIの設定
    • SLOとSLAの設定
    • 目的に合わせたポリシーの策定
    • メトリクス管理のライフサイクル
      • SLIの設定→指標の取得→格納→振り返り→
    • SLIの基準として、Uptime Checkのメトリクスを採用
      • StackDriverのUptime Check機能：ユーザから見てアプリケーションが動いているか
• 今後について
  • 今後のアクション：事例づくり
    • Cloud Runとかものるんじゃないか？
    • フレキシブルに選択可能な環境
  • GKE On-Prem 中心にAnthosサポート実施

4 GCPで実現するCI/CD最前線

• Why CI/CD?
  • 最新レポート　From DORA(DevOps Research and assessment)
    • Elite teams outperform
    • Elite groupとLow Performerを比べると
      • コードのデプロイがより頻繁：208倍
      • コミットからデプロイまでのリードタイムがより高速：106倍
      • 変更の失敗の比率がより低い：7倍
      • インシデントからの復旧がより高速：2604倍
  • CDF（CD.Foundation）
    • CI/CDツールは多くのベンダーが乱立状態：ベンダー中立的な拠点として設立
      • 次世代のデリバリーコラボレーションを中立な立場で提供
        • Jenkins,Tekton,Spinnaker,JenkinsX
  • CI/CDにもとめられるもの
    • オープン
    • ポータビリティ
    • ハイブリット・マルチクラウド
    • Kubernetes連携
• GCPにおけるCI/CDとは？
  • 高速なローカル開発ループ
    • Cloud Codeを利用し、linting、保管、ローカルでのデプロイ（Skafforld)を支援
    • ローカルとクラウドで同じパイプラインを実行
  • GCPのCI/CD関連サービス
    • Cloud Build
      • フルマネージドなCI/CDプラットフォーム
        • Dockerfile、cloudbuild.yamlに基づいてビルドを実行
    • Spinnaker
      • CDをパイプラインで管理
      • CI連携はgitイベント、Jenkins、ほかのSpinnakerパイプライン、などなど
      • Immutable Infrastructure デフォルトでBlue/Green(R/B)をサポート
      • Spinnaker for GCPとして統合されたSpinnakerサービスがリリース
    • Container Registry脆弱性スキャン
      • CI/CDパイプラインの早い段階でセキュリティ脆弱性の発見を支援
    • Cloud Build Artifacts
      • パッケージリポジトリサービス　ON GCP
      • Maven、npmをサポート
      • Cloud IAMとの統合
    • Binary Authorization
      • 適切に署名されたコンテナのみが本番環境にデプロイされることを保証
  • ハイブリッドクラウド／マルチクラウドの場合は？
    • TEKTON
      • Kubernetes上でCI/CDを実現するためのOSS
      • ビジョン
        • 組み立て可能
        • 再現可能
        • 宣言的
        • クラウドネイティブ
      • 仕様とクラウドネイティブなテクノロジーによって、すべてのユーザーへのソフトウェア展開で利便性とセキュリティを向上
• まとめ
  • CI/CDはKubernetesを利用する開発において欠かすことのできない要素
  • ポータビリティなど、クラウド利用の要件に応じて、最適なプロダクトを選択する必要がある
  • Tektonをはじめ、今後のアップデートから目が離せません
  • GCP CI/CD developer hub
    • https://cloud.google.com/docs/ci-cd?hl=ja

5：kubemci を用いたカナリヤリリース　～グローバルチームにおけるGKEの監視事例～

• 株式会社LOB：広告プラットフォームサービス：現在は楽天傘下
  • 楽天本社と海外のRakuten Marketing関連会社と連携しながらサービス展開
• 広告配信システム
  • 全面的にGCP、GKE利用
• GKEクラスタの安定運用で課題となったもの
  • １．クラスタのメジャーバージョンアップを慎重に行いたい
  • ２．新しいソフトウェアを慎重に組み込みたい
  • ３．クラスタの設定や構成を柔軟に変更したい
  • ４．不具合発生時にクラスタのバージョンを戻したい
• 上記課題に対して、GKEのマルチクラスタ構成での解決にトライ

  • GKEではkubemciという専用のコマンド

  • 課題１，２への対応

    →マルチクラスタでGCLBのレートを操作してカナリヤリリース

  • 課題３，４への対応

    → マルチクラスタでクラスタを片側ずつ切り離して構成変更

• 北米・ヨーロッパ・アジアにおけるグローバルでのモニタリングの事例
  • 広告配信の監視、モニタリングとは？
    • request rate
    • response rate
    • ・・・諸々のメトリクスを使用
  • Prometheusを利用
    • オンプレ環境で使用していた
    • Kubernetesとの親和性も高い
  • モニタリングについて
    • GCP MarketplaceからPrometheusをデプロイ
      • パラメータを選択しクリックするだけでデプロイ可能
  • System metricsアーキテクチャ
    • Kubernetes内へのPrometheusとDatacenter内のPrometheusを併用で稼働中
  • Logging notification
    • stackdriver - cloud pub/sub - cloud funciton - slack
      • Stackdriver monitoringを用いるか、CloudFunctionで通知するかを検討中
  • 運用体制の改善（US,EU、JPでのグローバル運用体制）
    • JIRAのチケットベースでタスク管理
    • 習字でリモート会議
    • 年に一回グローバルでのオフサイトミーティング
  • まとめ
    • グローバル運用は大変
    • 買収企業が運用担当するのは大変・・・
    • Prometheusを用いたKubernetesモニタリング中