The value of the JCB partnership
二桁を超えるクレジット関連サービスが稼働中のGKEにおいて、年数• MONDAY 8 MAY
回のアップグレードを習慣化した手法の紹介
TH株式会社 ジェーシービー
デジタルソリューション開発部 主査
平松 淳也

1

Speakers
略歴●2009年〜2020年までメーカーのソフトウェア開発部門に所属 (アプリ・インフラ・サポート)
○○○
○

●

ビジネスプロセスマネジメントの可視化
モバイルプラットフォーム
チャットボット
ブロックチェーンサービス基盤

The value of the JCB partnership

2020年〜ジェーシービーに所属○ デジタルプラットフォーム構築 / 運用
○ マルチリージョン構成のサービス基盤構築• MONDAY 8TH MAY
クラウドベースの新プラットフォームの立ち上げ期より参画、プラットフォーム開発・運用に従事

株式会社ジェーシービー
デジタルソリューション開発部 主査
Platform 構築・運用担当

平松 淳也
2

What’s JCB「Issuer」
国際カードブランドとして、自社での個人・法人カード発行のほか、金融機関およびその関連会社とフランチャイズ契約を締結
し、 JCB カードの発行拡大を図っています。

「Acquirer」
国内すべての加盟店との契約を自社で担う「シングルアクワイアリング」の強みを活かし、国内最大級の加盟店ネットワークを構築・維持しています。

The value of the JCBpartnership「Brand Holder」• MONDAY 8TH MAY

JCB は、1981年より独自の海外展開を開始した日本発唯一の国際カードブランドです。
世界中で JCB カードを利用できる加盟店ネットワークを展開するとともに、国内外のパートナーとJCB カードの発行を拡大しています。

3

JCBで取り組むGKEの活用
The value of the JCB partnership• MONDAY 8TH MAY

4

JCB Digital Enablement Platform (JDEP)
GKE / CSM をコア技術とした、サービス（ APL）の高速開発を可能とする Platform を構築
CloudNative なソリューションで構成されており、 APL開発に自由度を持たせた Agility あるシステム開発を実現

CloudIAM

Cloud
DNS

Cloud Resource
ManagerSaaS

CloudLogging

GKE(Google Kubernetes Engine) Cluster
APL-A

APL-B

APL-C

(NameSpace)(NameSpace)(NameSpace)

Cloud NAT

The value of the JCB partnership
Cloud Service Mesh

KeyManagement•Service
MONDAY 8TH MAY

既存システムCloudSpanner

Pub/
Sub

BigQueryPartnerInterconnect

On-Premises
Data Center

Shared Service
Public Clouds5

チーム体制Design
ビジネス部門＋システム部門

APL-B

APL-A

APL-C

Team B

Team ATeam C…

…

The value of the JCB partnership
QA

システム部門• MONDAY 8TH MAY

SRE

ArchSec

JDEP (JCB Digital Enablement Platform)
Platform Team

6規模●

アクティブ参画者数 : 480 名 (2024/6現在)○●

PJ メンバー / サービス数の推移

マルチテナント○○●

2020年発足時は 30 名
JCBの様々な業務システム → サービス数 : 17
うち、本番稼働サービス : 10

全体トラフィック :日中帯で合計約 180〜280 RPS

The value of the JCB partnership• MONDAY 8TH MAY

今後更なるサービスの開発・稼働を予定

7

当初の設計、スモールスタートフェーズ
The value of the JCB partnership• MONDAY 8TH MAY

8

GKE構成●●●Shared GKE モデルを採用
各環境・リージョン毎にシングルクラスタ
Namespace でサービスを分離、 Managed Service の利用は各アプリプロジェクトで管理
Dev環境

QA環境

開発
機能テスト

外接テスト

Stage環境
性能テスト
障害テスト

Production環境
顧客提供

GKE 大阪リージョン
GKE 東京リージョン
A ServiceNamespace

B ServiceNamespace

GKE 東京リージョン
A ServiceNamespace

B Service
Namespace

GKE 東京リージョン
A ServiceNamespace

B Service
Namespace

GKE 大阪リージョン
GKE 東京リージョン
A Service
Namespace

The value of the JCB partnership

C ServiceNamespace

A ServiceProject

B ServiceTH• MONDAY
Project 8 MAY

C Service Project

C ServiceNamespace

A Service
Project

C Service Project

C Service
Namespace

B Service
Project

A Service
Project

C Service Project

releaseB Service
Namespace

C Service
Namespace

B Service
Project

A Service
Project

B Service
Project

C Service Project9アップグレード頻度の検討●●

GKE は本家 k8s のリリースサイクルに合わせて年 3回程度のマイナーアップグレード
Regular チャンネルにリリースされて、標準で 14ヶ月程度サポートされる→ 細かくアップグレードするか、まとめて複数アップグレードしていくかを選択可能

Pros

細かくアップグレード

まとめて複数アップグレード

毎回の変更インパクトが小さい

同一バージョンを長期間利用可能

The value of the JCB partnershipCons

心理的負担の軽減

十分な準備期間

リグレッションテスト工数増大

ビッグバンリリースで変更差分が大きくなる

リリースが重なることで調整コスト増

アップグレード作業の長時間化

TH• MONDAY 8 MAY

10アップグレード頻度の検討
GKE は本家 k8s のリリースサイクルに合わせて年 3回程度のマイナーアップグレード
Regular チャンネルにリリースされて、標準で 14ヶ月程度サポートされる●●→ 細かくアップグレードするか、まとめて複数アップグレードしていくかを選択可能

Pros

細かくアップグレード

まとめて複数アップグレード

毎回の変更インパクトが小さい

同一バージョンを長期間利用可能

The value of the JCB partnershipCons

心理的負担の軽減

十分な準備期間

リグレッションテスト工数増大

ビッグバンリリースで変更差分が大きくなる

リリースが重なることで調整コスト増

アップグレード作業の長時間化

TH• MONDAY 8 MAY❏❏

リリース頻度を高めることで、障害変更率・サービス復旧時間が結果的に改善される可能性
アップグレードの習慣化をプロジェクトに根付かせ、環境変化に対する心理的ハードルを下げる
11

心理的負担を軽減することの重要さ
Infrastructure as Code（IaC）において、オートメーション恐怖症と呼ばれる心理的な理由から自動化による環境変更ができなくなってしまう現象がある。
⇨ 変更頻度が少なくなり、「何かが壊れそう」と感じてしまうことが一因と言われている。
IaCとは厳密には異なるが、 Kubernetes の様な複雑なコンポーネントのアップグレードには心理的な負荷がかかることが懸念されるため、心理的負担をかけない方針を重視した。

The value of the JCB partnership• MONDAY 8TH MAY

https://logmi.jp/tech/articles/324822 より引用

12

アプリチームにはあらかじめ方針を共有●DevOps○○●

リグレッションテストの自動化を推奨
検証環境アップグレード前後の負荷がけ⇨ Gatling or JMater + Datadog エージェントを Ansible で組み込んだテスト用 VM を提供

SRE○Common Project

各サービス毎に CUJ / SLI を定め、アップグレード前後の SLO を確認■ Datadog Monitor / Dashboard

The value of the JCB partnership
GKE ProjectCompute Engine
Compute Engine

Kubernetes
Engine• MONDAY 8TH MAY

13初期のアップグレードプロセス● 手作業での Blue / Green アップグレード
当時は公式の手順がサージアップグレードのみであったため、 Blue / Green 相当となるように手作業で実施
1. GKEアップグレード後バージョンの新規クラスタを作成
2. 既存クラスタから新規クラスタに全てのワークロードを 1つずつ手作業で順番に移動○ ノード単位で Cordon○ Drain で移動

コントロールプレーン（kube-system ns）
managermanagermanager
podv1
pod
pod

managermanagermanager
podv2
pod
pod

ノードプール v1v1
APL
managermanager
Pod
podpod新旧バージョン
を移行時に同時に浮かべる

ノードプール v2v2
APL
managermanager
Pod
podpod移動

The value of the JCB partnership
APL
managermanager
Pod
podpodAPLmanagermanager
Pod
podpod⇨ 初期段階：開発サービスが少ない• MONDAY 8TH MAY●●

チーム間の連絡・合意形成が容易
アップグレードで移行する Pod 数も少なく、作業時間も 1日で収まっていた14

規模拡大につれて見えてきた課題と対処
The value of the JCB partnership• MONDAY 8TH MAY

15

課題1：コミュニケーションコスト
サービスチーム数増加に伴い、コミュニケーションコストが増加、確認漏れも懸念に
昔（2021年）

2024年

サービスチームは2, 3個→ コミュニケーション面での課題はなかった

サービスチームは17個→ 全てのチームと密に連携を取り、正確にアップグレードを進めることが困難に

この日にStage環境のGKEアップグレードを実施するので、負荷掛けお願いします

この日にStage環境のGKEアップグレードを実施するので、負荷掛けお願いします・・・(何もしてない)

The value of the JCB partnership
了解です

サービスメンバ

Platformメンバ(アップグレード当日)(アップグレード当日)
負荷掛け完了しました(アップグレード当日)
負荷掛け完了しました
負荷掛け完了しました

サービスメンバ
了解です、GKEアップグ• MONDAY 8TH MAY
レード開始します(アップグレード当日)
負荷掛け完了しました

Platformメンバ(アップグレード当日)
リージョン閉塞完了しました

リージョン閉塞/負荷掛けは全て完了している？アップグレード開始していいのか？
16課題2：アプリ準備作業の統制
オンライン・バッチ・ Webアプリ・ API・東阪 Active・メンテナンス影響の極小 etc… と様々なサービス・要因が増えてきて、各アプリのアップグレード前準備状況を取りまとめることが困難に以前（2021年）

2023年

オンライン・バッチのみ→ 要件も大きなものはなく、アプリごとの準備状況の確認も容易だった

複数種類のアプリ要因が複雑に絡み合う→ 調整が困難になり、アップグレード予定日の確定も思った通りに設定できないこともあった

リトライ処
理あり

メンテナ東阪会員決済サービス
Active ンス極小

バッチ起動時
業務効率化
間を避ける
…

The value of the JCB partnership
SLO確認

オンラインWebAPI• MONDAY 8TH MAY

バッチ

オンライン

バッチ
17

規模拡大への対策●

Google Workflows によるオートメーション化⇨PF からの通知・APL の対応連絡を組み込むことでチーム間コミュニケーションの省力化を実現⇨各作業の責任チームを明確にし、組織のスケールに対応●

GKE 標準の Blue / Green アップグレード + 途中キャンセルが出来るようになった(2022年にGA)⇨これまで手作業で実施ていたステップが1コマンドで実現
Workflows.yaml
コントロールプレーン（kube-system ns）① コントロールプレーンを形成する Pod を VUP①

managermanagermanager
pod
v1
pod
pod

The value of the JCB partnershipmanagermanagermanager
podv2
pod
pod

② 新ノードプール(v2)を作成②ノードプール v1v1
APL
managermanager
Podpodpod

ノードプール v2v2③

APL
managermanager
Pod
podpod• MONDAY 8TH MAY
APLmanagermanager
Podpodpod③

APL
managermanager
Podpodpod③ 全APL Podを移動(Cordon & Drain)

さらに作業を手動→自動化④ 旧ノードプール(v1)を削除※ GKE の機能追加で②〜④が自動化

18

Google Workflowsフロー詳細
●

処理の流れ
○

●

事前準備フェーズ開始 → 全アプリの準備完了を受信 → アップグレード実行

責任分界点の明確化○

プラットフォーム / アプリプロジェクトの責任範囲で完全分割

事前準備フェーズ
事前に Workflows
起動を予約

GoogleForms

アップグレード実行

Platform Tools Project

Cloud
Pub/Sub

作業開始

CloudFunctions

事前準備の必要ないAPL はPF Project にて Webhook 応答The value of the JCB partnership

GoogleChat

APL Projects

Cloud Scheduler

GoogleWorkﬂows

APL Projects

APL Projects
全てのアプリの事前準備
完了応答がきたら、自動でアップグレード実行

Workflows 進捗をチャットで共有

TH• MONDAY 8 MAY

CloudPub/Sub

CloudFunctions

APL メンバー

GKE Project
各 APL の事前準備
今後、準備の自動化余地を残す

GoogleChatGoogle
Chat
Kubernetes
Engine19

Google Workflowsフロー詳細
●

処理の流れ
○

●

事前準備フェーズ開始 → 全アプリの準備完了を受信 → アップグレード実行

責任分界点の明確化○

プラットフォーム / アプリプロジェクトの責任範囲で完全分割⇨ 各チーム間の密なコミュニケーションが不要に

事前に Workflows起動を予約

GoogleForms

Platform Tools Project

CloudPub/Sub

作業開始

Cloud
Functions

事前準備の必要ないAPL はPF Project にて Webhook 応答

The value of the JCB partnership

GoogleChat

APL Projects

Cloud Scheduler

GoogleWorkﬂows

APL Projects

APL Projects
全てのアプリの事前準備完了応答がきたら、自動でアップグレード実行

Workflows 進捗をチャットで共有

TH• MONDAY 8 MAY

CloudPub/Sub

CloudFunctions

APL メンバー

GKE Project
各 APL の事前準備
今後、準備の自動化余地を残す

GoogleChat[PF] 責任分界点 [APL]

GoogleChat
Kubernetes
Engine20

事前準備一例●●

Stage 環境での各アプリ平常時同様の負荷がけの実施
Stage / Production 環境でのリージョン閉塞○○●

PFチーム構築の自動閉塞ツール(上長承認⇨実行)を用いて実施
リージョン閉塞はトラブル時にも有効なオートメーション処理で、閉塞ツールそのものの安全性担保という目的も兼ねている

バッチ起動時間の変更 (アップグレード作業時間を避ける、等 )→ これらの事前作業の統制を各チームにお任せすることで、チーム間のコミュニケーションコストを削減

The value of the JCB partnership• MONDAY 8TH MAY

21

効果・まとめ
The value of the JCB partnership• MONDAY 8TH MAY

22

当日作業のストーリーポイント●PF○

従来手作業で1つずつコマンドを実行していた工数が Google Workflows を利用することで大幅削減
■
■
■

●

The value of the JCB partnership

APL○とはいえ Workflows が無事に進捗していることを確認するため、待機は必要
アップグレード前後のメトリクス監視
APLの事前準備が円滑に進むよう促したり基本工数は変わらない■❏

正常性確認・負荷がけ等、各チームで実施する範囲の作業に変更なし• MONDAY 8TH MAY

規模が増えても PF工数が増えない仕組みが実現できている

23

現場の声
GKE のアップグレードを新プロセスにて複数回実施● PFメンバー○

操作手番が削減され、オペミスも大分予防できると感じた。
実際、オペミス削減効果も出ている。

○

状態確認等の細かい作業手番が削減でき、作業に対して 心の余裕 ができた。

● APLメンバー○ 1回目は情報伝達にミスが発生したことからコミュニケーションコストはかかってしまったが、 2回目以降は改善。不満はほぼ解消された。

The value of the JCB partnership○

過半数を超えるチームから、今までと工数が減った・もしくは変わらなかったという回答を得られた。
• MONDAY 8TH MAY❏

過渡期の伝達ミスによるコスト増はあったものの、全体的な意見としては概ね良好❏

何より、作業者の心理的安全性が高まったという狙い通りの効果が得られた

24

まとめ
スモールスタートから規模拡大していく中で、アップグレードを高頻度かつ定期的に実施できるプロジェクト体制とプロセスを整備-

プロジェクト全体に定期的なアップグレードを習慣付け-

アップグレードに対する心理的ハードルを下げる

サービスが増えても工数が単純増加しないアップグレードプロセスを確立

The value of the JCB partnership-

責任分界点の整理-自動化と新機能の活用• MONDAY 8TH MAY

作業工数をかけることなく、心理的安全性を高めて年に複数回のこまめなアップグレードを推進することができた
25

Thank you.
We arebusiness
The valueof hiring
the JCBforpartnership

Let's develop together with JCB!

• MONDAY 8TH MAY

26