フューチャー技術ブログ

Google Cloud Kubernetes Day セッションレポート

はじめに

こんにちは、TIG(Technology Innovation Group)/DXユニット 1所属の村田と申します!

私は現在Future IoTプロジェクトに携わっており、最近はクラウドインフラ設計構築に従事しています。

其の中で、Kubernetesは特に重要なプロダクトであると捉えているため、業務の合間を縫ってGoogle Cloud Kubernetes Dayに参加してきました。

Google Cloud Kubernetes Dayは

「コンテナを使った最新の開発アプローチを学ぶ」というスローガンで開催されているイベントです。第1回目は2019年3月に、9月3日に今回の第2回目が開催されました。

https://inthecloud.withgoogle.com/kubernetes-day-1909/register.html

セッションレポート

以下の2セッションに参加しました。それぞれについて簡単に紹介していきます。

  1. 失敗しないアプリケーションモダナイゼーションの考え方
  2. Anthosで実現するモダンなアプリケーション管理プラットフォーム

1.失敗しないアプリケーションモダナイゼーションの考え方

FUJIFILMさんとFreakOutさんの事例をベースに、アプリケーションのモダナイゼーションおよびDevOpsについてのセッションでした。

モダナイゼーションとは

  • 100人100通りの答えが返ってくるテーマである
  • 大事な要素に以下4点がある
    1. Twelve factor app
    2. マイクロサービス
    3. クラウドネイティブ
    4. クラウドの利用

パネルディスカッションパート

自己紹介

各々のPJ概要について

  • FUJIFILM Prints & Giftsのバックエンドシステムであるオーダー管理システム(以下、OMS)のモダナイゼーションについて
    • スケーラビリティに課題があったので、モダナイゼーションによるレガシーシステムのリプレイスへと踏み切った
    • その手段が「マイクロサービス化」であった
  • FreakOutの開発した広告プラットフォームであるRed for Publishersのアーキテクチャ
    • GKEを利用した広告の仕組みを構築している

アーキテクチャ選定の考え方について

  • 広告はスピードが大事なので、そこを重視してアーキテクチャ選定を行った(西口氏)
  • サーバレスは1stチョイスでもよいが、システムが複雑になってきて相互に協調し合う場合にはインフラ側に介入できる方がよいと考えGKEを選択(西口氏)

チーム編成について

  • OMSにおける組織・開発
    • 周り、特に経営層の理解を得ることが重要だった
    • 知識や実績が無かったので、失敗リスクを最小化するために、技術学習のみならず説明行脚やスタートをなるべく小さくするなど様々な手段を講じた
    • Googleカスタマーサポートの支援がなければ達成はできなかった
    • チームが連帯感を持つことが重要であった
  • Red for Publishersにおける組織・開発
    • Kubernetesのバージョンアップデートなど大規模なインフラ構成変更はSRE(2名)が中心に行っている
    • SREチームでは徐々にTerraformを導入している
    • ConfigMap修正やテーブルのスキーマ変更など日々の構成変更はDeveloper(11名)も行う

これからモダナイズしている企業に向けて

モハマド氏

  • マイクロサービス・サービスメッシュ・サーバレスなど技術スタックが揃っているため、クラウドを前提にした設計を進めると良い
  • 人材の適材適所を意識する
  • ノウハウ・経験が無い場合にはスモールスタートが良い

西口氏

  • いまはGKEの事例がたくさんあるので参考にしながら設計すると良い
  • GKEはとても良いプロダクトなのでぜひ利用すると良い

DevOps解説パート

DevOpsの重要性

DevOpsの考えを現場に持ち込むことで目標達成率が1.53倍になると言われている

Kubernetes登場による変化

アプリの変更・インフラの変更・サービスの監視がそれぞれ連続的な依存関係を持つものではなくなった

DevOpsで発生する問題点

  • 開発と運用のインセンティブが一致しない
  • 開発はAgilityを、運用はReliabilityを優先する
  • よくある問題としてあげられるのは「合理的でない安定性(Reliability)の定義」
  • 顧客は99.999999999%を求めているわけではないので、潜在的な安定性を明確に定義することが大事
  • 安定性の考え方
    • 数値の差分を説明できるかどうか、で考える
    • なぜそのレベルになるか、を言葉にできるか
  • 安定性の計測方法は「Availability = good time / total time」

まとめ

  • ソフトウェアがビジネスの中心となり、DevOpsの重要性が増している
  • Kubernetesの登場により、技術的にDevOpsの実現が容易になった
  • Opsには安定性(Reliability)が求められ、役割は以前にも増して重要になってくる

セッションの感想

第1回でも話を聞いた2つの企業の方の後日談ということで、非常に興味深くて面白かったです! 本TechBlogにも記事があがってますが、SRE本の輪読会が社内で開催され筆者も参加していたので、安定性の話などはとても理解しやすく、良い復習となりました。

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

先日のGoogle Cloud NextでもAnthosの話を聞かせてくださったSAの長谷部さんと、ハイブリッドクラウドスペシャリストの篠原さんによるセッションでした。AnthosおよびGKE On-Premについてデモも含めて詳しく説明してくださりました!!

「2025年の崖」

経産省が出したDXレポートにて言及されている単語で、2025年までにDXの種をまいておかないとDXの実現が困難になると言われている。DXの実現が達成できない場合、2025年以降日本全体で年12兆円もの損失になるとも試算されている。

主な理由には下記のようなものが挙げられる。

  • IT人材不足
  • データの爆発
  • 技術的負債の増加
    • 似たような仕組みの乱立
    • 過剰なカスタマイズ(日本では特にシステムを業務に合わせることが多い)

これから作るものはどうする?

  • Agility(敏捷性)・ Flexibility(柔軟性)・ Maintainability(保守性)の3つを満たすことが大事
  • 新しい考え方を取り入れ、モダンなアプリケーション開発へ

コンテナ基盤におけるデファクトスタンダード = Kubernetes

  • 今や国内コンテナ導入企業の65.3%が利用するコンテナオーケストレーションツール(IDCの調査による)
  • Kubernetesを本格導入する時にぶつかる問題
    1. 【問題】どこで動かすのか?
    2. 【問題】運用が大変
    3. 【問題】複数環境でのKubernetesはどう扱うのか?
    4. 【問題】足りない機能はどう補うのか?
  • 1〜4の課題を自社のエンジニアリングで突破する、というのももちろんありだが、すべての会社がこの策をとるのは困難である
  • Anthos + GCPがKubernetesをProduct Readyへ!
    1. 【答え】ハイブリッド+マルチクラウド
    2. 【答え】GKE
    3. 【答え】マネージドの管理機能で複数環境の一元管理
    4. 【答え】GCPの各種サービス

Anthos Deep Dive

オンプレミス側の構成について

  • DC(データセンター)のVMware上でKubernetesが稼働する
  • GCPのコンテナエコシステムとの連携が可能
  • GKE On-Prem論理構成
    • AdminのKubernetesが他のKubernetesを管理する構成
    • Admin Clusterの下に50のUser clusterをぶら下げることができる
    • Admin Clusterに対しては、kubectlコマンド以外にもgkectlというAdmin Cluster配下を管理するコマンドを実行可能

クラスター管理

  • 管理コンソールで一元管理が可能
  • DC側のGKE connect agentからGCPへの通信があるのみで、GCP側からポーリング等で状態をチェックするような通信はない
  • GKE On-PremではL7のLBはIstioにて制御しており、L7のIngressはL4のLBを経由する形で実現される
  • すでにMarket PlaceにはGKE On-Prem対応のものがいくつか存在しており、GCPコンソールからデプロイを行うとオンプレ側のGKEクラスタへアプリケーションがデプロイされる

ポリシー管理

  • namespaceやresource quotaを各クラスタごとに別々に管理していると大変なのでACM(Anthos Config Management)を使う
  • GitOpsに準拠しており、予め指定したrepositoryからconfigの差分を検知し取得、自動的にクラスタへ適用してくれる

サービス管理

  • Google Cloud Service Mesh (alpha)
    • 端的に言ってしまえばマネージドIstioのこと
  • アーキテクチャ構成についての説明
    • Istio公式のアーキテクチャ図とほぼ同じだが、Managed CA(元のIstioで言うところのCitadel)だったりControl Planeのサービス群がしっかりとマネージドであることが謳われている

セッションの感想

まさかGKE On-Premのデモを見られるとは思ってなかったのでとても興奮しました! オンプレ側の通信詳細については筆者のネットワーク知識不足によりついていけない場面もありましたが、今後Anthos、GKE On-Premに関わっていくあたりあたり自身の課題が浮き彫りになったのでとても良い機会となりました。

最後に

今回は2セッションの参加のみでしたが、非常に有意義に過ごすことができました! 特にAnthos、GKE On-Premについては今回はじめて具体的なアーキテクチャやデモを見ることができてとても良かったです。

Google Cloud Nextで語られていた「ハイブリッドクラウドの実現」に向けて、キープロダクトと定めているKubernetesをオンプレ側で使える準備が着々と整ってきているんだなと感じさせられました。ハイブリッドクラウドのメリットとして「オンプレ側でクラウドサービスの恩恵を最大限に享受する」というのがあると思いますが、今後もKubernetesやその他クラウドネイティブの文脈で登場する様々なプロダクト・サービスについての学びを止めてはいけないなと感じました!

今回も読んで頂きありがとうございました。良ければシェア・いいねをよろしくお願いします!


  1. 1.DXユニットとはデジタルトランスフォーメーションに関わる仕事を主に推進していくチームです。