SEのアウトプット練習帳

関東在住のSEがやりたいこと、やったこと、思ったことを自由気ままに書きます。

Google Cloud Kubernetes Day に行ってきました

Google Cloud Kubernetes Dayに行ってきたのでメモ書きをアップします。

日にち:20190326
テーマ:Google Cloud Kubernetes Day
場所 :ベルサール渋谷


14:05-14:45「Kubernetes/Container による開発」の導入難易度とメリット
株式会社サイバーエージェント 青山 真也

  青山さん:Kubernetes完全ガイドの著者

  Bootstrapping(OSセットアップ)→Configuration(各種設定)→Orchestration(アプリデプロイ)
  ※時代により上記の各ステップで使われる技術が遷移してくる。自動化/イメージ化の流れ。
  ※現在は、Teraform→Docker→Kubernetesの流れになりつつある。

  Cloud Nativeとは? ※CNCFで定義されている。
    ・疎結合なシステム
    ・復元力がある
    ・管理しやすい
    ・可観測である
    ・堅牢な自動化により…

  Cloud -> Cloud Native
    Cloud Native Trail Mapを参照 ※CNCF

  コンテナ化のメリット
    1.容易なイメージ化と再現性
      アプリケーションと実行環境のイメージ化
      ※VMだと、ハイパーバイザー層の違いでイメージに若干の違いが出る。
    2.軽量なイメージ
      VMイメージと比べて軽量
      単一プロセスのみを稼動させるので、軽量OSの選定もしやすい。
    3.高速な起動と停止
      VMの起動/停止より高速
      プロセスの起動/停止相当
      高速なスケールアウトや障害時の復旧が可能

  Kubernetesのメリット
    1.高い抽象度とクラウド非依存
      LBやStorageを抽象化
      クラウド固有知識がほぼ不要
      ベンダーニュートラルな実行基
      基本的にポータビリティあり
    2.宣言的なAPIとCode
      構成情報はManifestsで管理 ※yaml形式
      Control LoopとReconciliation
    3.洗練された自動化
      障害時のセルフヒーリング ※コンテナのReplica吸うを維持し続ける。
      アプリケーションのアップグレード ※Manifestsの更新をするだけ。
      and more...
    4.豊富なエコシステムと拡張性
      多様なOSSミドルウェアをカバーしている。
      ※MySQL、CI/CD、Serverless、Service Mesh、Managed Service via など
      ※独自の処理も記述可能

  導入難易度
    1.アプリケーションのアーキテクチャ
      マイクロ/ミニサービスに適している
      VMと比較して頻繁に停止/起動する
      Service Discovery経由で通信
      ネットワークに一部制約あり ※Source IPが消失 など
    2.セキュリティと分離性
      仮想化の分離性
        runCではKernelは共有
      ネットワークの分離性
    3.Kubernetesの学習コスト
      CyberAgent内ではそれほど高くなかった。
    4.クラスタ運用のつらみ
      GKEを利用すると楽

  マネージドKubernetesサービスの選定基準
    マネージド範囲や自動化範囲を確認すること。


15:05 - 15:45 コンテナ開発プラットフォームに GKE を選択すべき 5 つの理由
Google Cloud Japan 田中 宏樹、岩成 祐樹

  1.Security
  2.Netowork
  3.Hybrid Cloud
  4.Observabilitiy
  5.Contribution

  1.Security
    セキュリティがクラウドの長所になりつつある。
    #アジリティの重要性、経費削減と並び。
    コンテナのセキュリティ?
      INFRASTRUCTURE SECURITY:インフラはコンテナを開発するのに安全か?
        Use RBAC and IAM
        プライベートクラスタと承認済みネットワーク
        Cloud Armor ※DDOS対策/WAF
        BackendConfig BETA
      SOFTWARE SUPPLY CHAIN:作成したコンテナはビルド、デプロイして問題ないか?
        CI/CDパイプラインは信頼できないデプロイを止めてくれない
        Conrainer Registry 脆弱性スキャン
        Binary Authorization
      RUNTIME SECURITY:作成したコンテナは実行して問題ないか?
        Container Optimised OS
        Runtime security partners in Cloud SCC BETA

  2.Network
    様々なGCPサービスとの統合
    Google Cloud Load Balancing
    Container Native Load Balancing BETA
      double-hop問題を解決

  3.Hybrid Cloud
    ゴール:コードをどこでも実行できる環境を整える
    どこでも=オンプレやクラウドにとらわれず。
    求められるリソースに最適な環境を選ぶ。

     GKE On-Prem BETA ※オンプレクラスタGoogle Cloud Consoleから一元管理

  4.Observabilitiy
    Logging
    Monitoring
    統合管理プラットフォーム
      DevOps/SRE
      Developer
      SecOps
    Stackdriver ※上記を提供するGCP Solution
    Stackdriver Kubernetes Monitoring BETA
    Prometheus

  5.Contribution
    Open Source is free like a puppy
    GKEの方向性
      安定性、拡張性、共存…


15:45 - 16:25 GKE を用いたレガシー システムからのリプレース事例
富士フイルム株式会社 小林 大助

  富士フィルムソフトウェアの人
  プリントビジネス関連を担当
  FUJIFILM Prints & Gifts
  →バックエンドの注文管理システムを担当

  1.プロジェクト概要
    レガシーシステムのリプレース

  2.GKE利用までの経緯
    富士フィルムの文化
      特にSeeとThinkを重要視 -> その後にPDCA
    現状分析
      モノリシックなアプリで、保守コストや運用コストが増大化。
      特に苦労しているのが下記。
        ・季節イベント ※年賀状
        ・キャンペーン ※割引最終日
      負荷量変動への対応を最優先にした。
        コンテナを使い、スケーラビリティを確保した。
    保守面を意識すれば、オーケストレーションを使いたい。
      課題
        ・何が標準なのか ※流行度、覇権争い、仕様策定中など
        ・自分達で運用できるか
      調査
        ・ニュースリリースからピックアップして確認

  3.取り組む上での課題(組織面)
    ・コンテナやオーケストレーションツールに対する周囲の理解を深めないといけない
    ・技術的優位性 など
      →技術学習、解説資料作成、説明行脚
       ※現場レベルでは味方が多かった。
    ・リスクを背負えるか
      →バックアッププランの準備、技術習得状況の説明、Googleエンジニアのバックアップ

  4.取り組む上での課題(開発面)
    ・独学+ハンズオンで基礎固め。
     ※別クラウドの利用実績があったのでなんとなく出来てくる。
    ・事前調査
      ・レガシーシステムのルール把握。
      ・効率的なシステム間連携に知識が必要。
        pub/sub連携のイベント発火条件の無駄が多かった。
        プログラムかサービス活用かの見極め。
      ・運用
        メトリクスの書き方に大分迷った。
      ・設計・設定
        Kubernetes設定記述方法
        永続データの取扱に適切なサービス選定
    ・基本設計(サービス分割)
      エラー発生時のリカバリパターンが膨大になる。
      ※小さくすればよいわけではない。
    ・商用利用に向けての課題
      マネージドサービスでカバーできる範囲の見極め、不足部分は自前で準備。
      ※監視面を自前で用意。
    ・レガシーシステムとの連携
      レガシーシステム側を変えることが難しく、新側をいじる方向で解決。

  5.効果
    スケーラビリティ確保:出来た ※ただし、今後悪化しないように管理が必要。
    保守・運用コストの改善:された
    機能改善スピードの向上:向上した

  6.取り組んでみて
    GKEの学習コストは掛かったが、それに見合うリターンはあった
    アプリ開発に集中できる環境を整えることができた
    組織の壁は高い、乗り越えるには熱意が必要
    クラウドベンダエンジニアの協力は偉大


16:55 - 17:35 コンテナによる開発と運用の進化
Google Cloud Japan 篠原 一徳、村上 大河

  製品ライフサイクル
    コンセプト→ビジネス→開発→運用→一般公開
            アジャイル  DevOps

  関連する3つのポイント
    人(ビジネス・技術)
    プロセス
    テクノロジー

  マイクロサービス
    ・機能ごとに独立したアプリケーションに分割
    ・各サービスは単一の目的をもつ
    ・分散システム、サービス間は疎結合、軽量なAPIでやり取り可能

  AsIs ToBe(Monolith to Microservice)
    ・新規サービスからやる(新規機能から抜き出す)
    ・既存のサービスを部分的に置き換える

  The Problem
    分散アーキテクチャへの移行により、
    今までのアーキテクチャ向けに最適化された方法では監視、管理、保護が困難

  4 Challenges of Microservices
    ・プロセス内コミュニケーションから、プロセス外コミュニケーションへ
      RPC+API GW
        →REST API ※OpenAPI利用や、互換性管理のためのガイドライン作成
        →gRPC ※Protocol Buffers利用や、Language Guideに従う
    ・複雑化する管理
      サービスメッシュ
    ・データサイロの解決
      データレイク
    ・アプリコード以外のコーディングを少なくする
      自動化(CI/CD)

  バージョン管理ガイド
    Google内部APIバージョニング手法を公開
    Cloud Endpoint で実現をサポート
    マイナーバージョンアップは下位互換性を持たせ、メジャーバージョンアップは下位互換性を持たせない。等

  API設計ガイド
    Google内部のAPI設計のスタンダードを公開
    Cloud Endpoint で簡単に実現

  Cloud Endpointによるマイクロサービスの実現
    API Keys
    Stackdriver logging(APIコールログとAPI Keyを紐づけて管理)
    Visualize(BigQuery + Dataポータル)

  サービスメッシュとは?
    マイクロサービス環境において、サービスディスカバリ、トラフィックコントロール
    認証・認可、メトリクス収集などの機能を担うソフトウェア
    ※アプリ自体に手を入れずに、サイドカーと呼ばれるネットワークプロキシで実現。

  Istioによるサービスメッシュ実現
    ・GoogleIBMが開発したOSS
    ・プロキシとしてEnvoyを利用

  Istioの価値
    ・トラフィックコントロール
      トラフィックスプリッティング
        バージョンごとに割り振り%を決める。 ※destinationのweight設定
    ・サービス間のセキュリティを強化
      Role Based Access Control
    ・可観測性
      Istioの監視

  データレイク
    データの流れを作り、データを一箇所に集め統合的に管理する。


17:35 - 18:15 FreakOut の広告プロダクトでの GKE 活用事例と GKE 新機能の導入について
株式会社フリークアウト 西口 次郎

  フリークアウト:広告関連プロダクトの開発・販売
  西口さん:フリークアウトのCTO

  Red(FreakOut DSP
  広告枠の買い付けを行うシステムとのこと

  ASE
  位置情報マーケティングプラットフォーム

  Red for Publishers
  アドプラットフォーム構築支援

  LayApp
  アプリエンゲージメントプラットフォーム
  アプリデベロッパーの収益機会の最大化支援

  プロダクション運用でのGKE活用
    参考URL:https://cloudplatform-jp.googleblog.com/2018/09/freakout-kubernetes-engine.html
    サービス毎にクラスタを分けている
    Cronjobを利用
    カナリアリリース環境を用意 など  
    Stackdriver
      ・Monitoring
      ・Logging
      ・Profiler
    BigQuery
      すべてのアクセスログ、アプリログを集約
      fluentd
      re:dash
      MySQLのマスタデータのインポート
    Vulnerability scanning(Beta)
    kustomize
    stern
    kubectx

  CI/CDツール
    ・Github
    ・CircleCI
    ・Cloud Build
    ・Cloud Container Registry など

  GKE新機能を使った環境構築
    ・VPC-native cluster(alias IP)
    ・Cloud NAT
    ・Network Endpoint Groups(NEGs)
    ・BackendConfig custom resource
    ・BackendConfig - Cloud Armor
    ・BackendConfig - Cloud IAP
    ・Google-managed SSL certificates

-以上-