コンテナ技術によるデータの継続的な⾃動更新事例の紹介 #ヤフー名古屋

コンテナ技術によるデータの継続的な ⾃動更新事例の紹介 2019年5⽉28⽇ 発表者：清⽔ 昭弘 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

⾃⼰紹介：清⽔昭弘 【所属】 テクノロジーグループ システム統括本部 サービスプラットフォーム本部 【略歴】 名古屋市出⾝、名古屋市在住。 ゲーム会社、地図会社を経て2008年より ヤフー。地図関連の開発業務に従事した 後、2018年10⽉より社内向けシステム の開発業務に従事。 チーム内ではスクラムマスター担当 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 2

⽬次 • 発表概要 • 従来のシステム • 従来の開発・デプロイ • kubernetesを利⽤したデプロイ⼿法 • kubernetesを利⽤したデータ更新 • 従来⼿法と新⼿法のメリット・デメリット • まとめ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 3

発表概要 • サーバーにライブラリとデータをインストールし て利⽤するパッケージを提供していました。 • サーバー内のデータは定期的に他のサーバーから 取得し更新する仕組みになっています。 コンテナ環境において同じ要件を満たす機能をどのよ うに提供できるのか？という事例を紹介します。 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 4

従来のシステム Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

従来のシステム 利⽤者側 プラットフォーム側 Webサーバー library 利⽤者へ提供 • ライブラリ Dataサーバー • 利⽤者側サーバーに組込むlibrary binary data • libraryは起動時にデータを⼀括読み 込み cron binary data • 社内プラットフォームとして社内利⽤ 向けのライブラリを開発・提供 • データはGeneratorサーバーで毎⽉ 作成 http Generator サーバ • 社内利⽤者側のサーバがcronで データの更新を定期的にチェック （データのハッシュコードでチェック） • 更新があればDataサーバーから取 得 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 6

従来の開発・デプロイ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

従来の⼀般的なデプロイ デプロイ 開発サイクル Source Code Developer Github Test Package Repository Open Stack Build ∞ CI/CD Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 8

従来の開発・デプロイ 問題点 • 全サーバー完了までに時間がかかってしまう • 利⽤者側でリリース作業が発⽣する • ロールバックが⼤変（∝サーバー台数） • バージョン依存のリスクがある Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 9

kubernetesを 利⽤したデプロイ Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

kubernetesを利⽤したデプロイ Dockerイメージの公開から利⽤者がデプロイするまでの流れ デプロイに利⽤するマ ニフェストはこちらか ら提供 Docker Registry Manifest .yaml httpアクセス 利⽤者のPod Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. API Pod 本番データを⽤いた E2Eテスト REST APIとデータを内包する Docker Image 11

kubernetesを利⽤したデプロイ 提供するマニフェストの例 apiVersion: apps/v1 kind: Deployment metadata: name: api-deployment labels: app: api spec: replicas: 10 ← 必要なPod数 selector: matchLabels: app: api Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. kubernetesを利⽤することで • マニフェストに必要な数を記載するだけでその 数のPod起動を保証してくれ、スケールアウト/ インが容易に可能 • マニフェストを提供することで利⽤者側は コマンドを実⾏するだけでAPIを利⽤開始でき る > kubectl apply! 12

kubernetesを利⽤した データ更新 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

タグ付けによるバージョン管理 タグ:V1 バージョン:1.0.0を設定 バージョン：1.0.0 Docker Registry タグ：V1 【提供者】 Dockerイメージに対してバージョン （1.0.0）とタグ(V1)を設定してアップロー ド 【利⽤者】 タグ（V1）を指定してイメージを取得する タグ:V1を指定して取得 利⽤者 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. ※1.0.0もV1もDockerイメージに付与するタグ 14

タグ付けによるバージョン管理 利⽤者 1.0.0 利⽤者が細かいバージョンを意識せ ずに利⽤することができます。 1.0.1 V1 定期的にイメージを 取得してPodを更新 提供者側 CI 1.0.0 1.0.1 V1 1.0.2 V1 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 提供者 定期的なPodの再作成と合わせること で、常に最新のバージョンを提供す ることができます ※タグの付け直しでロールバックも 可能 15

RollingUpdateによるPodの定期更新 manifest 1.0.0 1.0.1 バージョン 反映 1.0.2 V1 1.0.1 1.0.1 1.0.2 1.0.1 1.0.1 1.0.1 1.0.2 1.0.1 1.0.1 1.0.1 1.0.2 1.0.2 1.0.1 1.0.1 1.0.2 1.0.2 1.0.2 1.0.1 1.0.2 1.0.2 1.0.2 CronJob spec: replicas: 3 ← Pod数 常に3つ以上のPodが稼働状態に ある Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 古いPod RollingUpdate バージョン 更新 V1 1.0.1 新しいPod サービスアウト 16

RollingUpdateによるPodの定期更新 • CronJobを使って定期的にmanifestを更新する • RollingUpdateが発⽣しPodが再作成され、無停⽌でデプロイができ る • Dockerイメージの「タグとバージョンの紐付け」に変更（P15) があ れば新しいイメージに⼊れ替わる(P16) Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. Cronjob：ジョブスケジューラ 17

従来⼿法と新⼿法の メリット・デメリット Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

従来⼿法と新⼿法の⽐較 従来⼿法 • 利⽤側のサーバーにライブラリとデータを組み込んでもらう • アプリケーションと密結合 • データは外部から定期的に取得して更新する 新⼿法 • • • • ライブラリはRestAPIとして動作するコンテナ アプリケーションと疎結合 ライブラリとデータは同じコンテナ。密結合 データ更新は定期的なコンテナのアップデートで⾏う メリット 従来手法 新手法 デメリット 利用者側の環境で運用が完結する データ配信の仕組みが必要 アプリケーションとライブラリで独立してスケール管理できる 提供側がデータのバージョンを管理できる 利用者側でコンテナの管理・運用が必要 Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 19

まとめ 問題点の解消 • 全サーバー完了までに時間がかかってしまう → RollingUpdateで更新の⾃動化 • 利⽤者側でリリース作業が発⽣する → CronJobで⾃動的に定期実⾏が可能 • ロールバックが⼤変（∝サーバー台数） → 提供者側だけでロールバックが可能 • バージョン依存のリスクがある → 独⽴したコンテナ環境で動くので運⽤リスクが低い Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved. 20