CODT2022_エンタープライズ向けクラウドサービス仮想サーバ基盤開発のリリースサイクル改善 / CODT2022_Improvement of release cycle for development of virtual server infrastructure for enterprise cloud services

© NTT Communications Corporation All Rights Reserved.
エンタープライズ向け 
クラウドサービス 
仮想サーバ基盤開発の 
リリースサイクル改善 
NTTコミュニケーションズ株式会社 
PS本部 DPS部クラウドプラットフォーム部門 
ソフトウェアアーキテクト 
佐野成(@say3no) 

View Slide

ソフトウェアアーキテクト 
佐野　成(@say3no) 
自己紹介 
2

View Slide

IaaSの運用がつらい！ 
3

View Slide

最新の技術使ってイケイケになりました！ 
みたいな登壇がしたい！！！！！ 
4

View Slide

が、出来ない… 
 
5

View Slide

が、出来ない… 
そんな風になりたい… 
6

View Slide

今日お話するのはそんな事を願う 
日本の伝統的企業の地道な改革のお話です 
7

View Slide

● SDPFってなに/OpenStackと私たち 
 
● ここがつらいよIaaS 
 
● 義務を小さく権利を大きく 
8
● 問題1. リポジトリとデプロイシステムとのシームレスな結合が　　　出
来ていない 
● 問題2. 結合環境が足らない 
 
● 問題3. 自動テストのカバレッジが低い 
目次 
リリースサイクルの
改善
● リリースサイクルの改善後の話 
 
● クロージング 
{ 
{ 
{ 
背景と動機
おわりに

View Slide

 
 
9
来ていない 
 
目次 
改善
 
{ 
{ 
{ 
背景と動機
おわりに

View Slide

© NTT Communications Corporation All Rights Reserved. 10

View Slide

仮想サーバー ∈ Smart Data Platform 

View Slide

仮想サーバーの規模感 
● 2016年より仮想サーバーを提供 
○ サービス提供 7年目 
○ 当初ECL2.0というサービス群の中の 
1つとして提供された 
○ 現在はSmart Data Platform(SDPF)  
というクラウドサービス群の1つ 
 
 
● 世界13拠点に展開 
○ HV総数約 3,500 台 
○ VM総数約 35,000 台 
○ 最大拠点で 660 台のHV 
 
● ８人で内製開発を続けている 
 
13
https://ecl.ntt.com/en/service-status/

View Slide

SDPFの仮想サーバ基盤はOSS:OpenStackを利用している 
14
VM一丁！
ワークロードのため
計算機資源が欲しい
[POST] /servers 
VM一丁おまち!
クラウドコンピューティングのための
OSS。用途ごとに様々なコンポーネン
トがある。以下は一部。
コンピュートイメージ高可用性
NW
IAM
ブロックストレージ

View Slide

自チーム担当はNova/Cinder/Glance/Masakari 
15
VM一丁！
[POST] /servers 
VM一丁おまち!
コンピュートイメージ高可用性
NW
IAM
ブロックストレージ
クラウドコンピューティングのための
OSS。用途ごとに様々なコンポーネン
トがある。以下は一部。

View Slide

APIの裏側では物理サーバー(Hypervisor)にVMが生えている 
16
VM一丁！
[POST] /servers 
VM一丁おまち!
User
nova-comptue
OS (Host)
Hypervisor
libvirtd
kernel
kvm
virsh
qemu
OS (Guest)
User
● OpenStack レイヤの前段にApacheが立っている
● Nova は最終的に物理マシンの上に VM(qemu)を生やす
● OpenStack/ホストOS/Hypervisorの新陳代謝は必要不可欠
コンピュート
Others
Internal API

View Slide

新陳代謝はサービス継続のための義務やらないと詰む 
17
OpenStack libvirt qemu Ubuntu
Mitaka 0.10.2 <= 16.04(2024-04)
Queens 1.2.9 <= 2.1.0 16.04(n/a) 18.04(2028-04)
Ussuri 4.0.0 <= 2.11.0 <= 18.04(n/a)
20.04(2030-04)
● OpenStack/ホストOS/Hypevisorは、 
SDNチームのプロダクトやStorage チームのプロダクトとも依存している 
 
● 彼らは彼らでサービス継続のためのアップデートが必須であることも多いため、 
彼らの都合にも併せてホストOSバージョンアップ等は進めていかなければならない 
(今回は割愛） 
 
● Hypervisorなどの物理製品の保守契約上、 
規定以上の新しいホストOSがインストールも必要 
ホストOS
Hypervisor
(プロセッサ)
ゲストOS
(VM)
SDN関連 Storage関連

View Slide

新陳代謝の方法論；Spiral Update Plan 
18
OpenStack とホストOS を交互に Update していく計画  
● Intelのチックタックみたいに  
ディストリビューションから長期サポートが提供されるものを選ぶ
 
● アップデートの必要回数は少なくなるように
 
OpenStack libvirt qemu Ubuntu
Mitaka 0.10.2 <= 16.04(2024-04)
Queens 1.2.9 <= 2.1.0 16.04(n/a) 18.04(2028-04)
Ussuri 4.0.0 <= 2.11.0 <= 18.04(n/a)
20.04(2030-04)
ホストOS
Hypervisor
(プロセッサ)
ゲストOS
(VM)
これまで、OpenStack Juno -> Mitaka  
ホストOS Ubuntu 14 -> 16/ RHEL 7.4 -> 7.6 を実施してきた
 
順当にいけば次は OpenStack Mitaka -> Queens だが…
 

View Slide

義務としてのバージョンアップ関連タスク(新陳代謝)が重すぎる 
VS開発チーム  
 
 
サービス継続のための義務  
● 次のOpenStack verup 対応  
● 次のホストOS verup 対応  
● その次の OpenStack verup 対応  
● その次のホストOS verup 対応  
● 差し込みのCPU脆弱性対応  
● … 
 
いい感じにやっていきするためのタスク 
● 物件費を下げる  
● 収容効率を上げる  
● 新API/サービス開発  
● 新ゲストOS開発  
● … 
 
19
8人:
👨👨👨👨👨👨👨👨 
次のホストOS verup 対応
重要
緊急
次のOpenStack verup 対応

View Slide

義務ではないけどやっていきたい諸タスクに取りかかれない 
 
 
● … 
 
● … 
 
20
8人:
👨👨👨👨👨👨👨👨 
重要
緊急
物件費を下げる
収容効率を上げる
新API/サービスの
開発

View Slide

赤を縮小させて 
 
 
● … 
 
● … 
 
21
8人:
👨👨👨👨👨👨👨👨 
次のホストOS
verup 対応
重要
緊急
次の
OpenStack
verup 対応
開発

View Slide

赤を縮小させて青を大きくしたい 
 
 
● … 
 
● … 
 
22
8人:
👨👨👨👨👨👨👨👨 
次のホストOS
verup 対応
重要
緊急
次の
OpenStack
verup 対応
開発

View Slide

どうすれば？ 
23

View Slide

チームの生産性を上げるには？👊👊👊 
①人数を増やす！！！！！😤😤😤 
● 今の倍雇用して、生産性２倍増！！！！！！！！ 
②さらに稼働時間を増やして個人の生産力を強化！！！！！😉😉😉 
● 全メンバー定型勤務時間の1.5倍の時間の残業をしてもらおう！！！！ 
仕事量 = 人数 × 稼働時間！！！！
ウォーズマン理論により生産性は従来の３倍！
プロダクトの圧倒的成長💪😤💪！！！！
今日も銀の弾丸パワーに圧倒的感謝🙏🙏🙏ウオオ
24

View Slide

👨 
25

View Slide

👨 <(...) 
26

View Slide

 
 
27
来ていない 
 
目次 
改善
 
{ 
{ 
{ 
背景と動機
おわりに

View Slide

問題1. リポジトリとデプロイシステムとのシーム
レスな結合が出来ていない 
28

View Slide

リリースサイクルに見る義務タスクのデカさ要因分析 
29
変更
結合
検証
リリース
RED
①変更結果が即座に結合されない。リポジトリとデプロイ
システムとのシームレス結合が出来ていない 
 
②結合先の Staging 環境が少ないため、様々な 
バージョンの組み合わせを並行して検証できない。また、
連携チームや自チーム内でマシンタイムの 
調整が必要になる 
 
③手動テストが多い/OpenStackのE2E試験コンポーネン
トであるTempestがメンテナンスできていない/テストポリ
シーが整備されていない 
 
 
GREEN

View Slide

● 検証環境にデリバリーするための前作業。  
● ある区間や目標の間に加えたら、Ansibleにもreposの変更をすべて反映させる  
● デプロイメントシステムで競合が起きないように調整しながら行う人手の作業 
● repo 毎にAnsibleの書きっぷりや変数管理に差分があることもあり、認知負荷も低くない 
変更を加えてからデプロイメントシステムとの調整が都度必要 
30
repo
repo
repo
…
roles repo
inventory
repo
Others
OpenStack
Hypervisor
/Storage
VS Team
Auth Team
SDN Team
GUI Team
Staging
各自が 
変更の追加 
変更の山を整理 
Shipための 
ブランチワークや
タギング 

View Slide

repo
repo
…
Container
Regsitory
Tag info
Workflows
for Container
Regsitory
repo
repo
repo
…
Deployment Interfaceの統一: Container Registry 
Container Registry の導入によって  
 
● ReposはDeploySystemの詳細を隠蔽し、Ansible は
Reposの詳細を隠蔽した  
 
● 各reposとAnsibleの結合度を大きく下げた  
 
● GitHub workflow, Container Registory を統一的イン
ターフェース  
 
● デプロイメントとの結合が統一されたことによってデ
プロイメントの抽象度が上がる  
 
● repos のデベロッパの責務は、インターフェースに
従ってコンテナをpushすること  
31
roles repo
inventory
repo
roles repo
inventory
repo

View Slide

変更とデプロイメントとのシームレスな結合;継続的デリバリー 
● reposの数が多いので地味に大変だったタスク  
● Ansible の責務はコンテナのデリバリだけではないため、まったくかかずらう必要がなくなったわけではな
い 
● しかし、それでも多くのトイルを削減できた  
32
repo
repo
repo
…
roles repo
inventory
repo
Others
OpenStack
Hypervisor
/Storage
VS Team
Auth Team
SDN Team
GUI Team
Staging
各自が 
変更の追加  Container
Regsitory

View Slide

問題2. 結合環境が足らない 
33

View Slide

34
変更
結合
検証
リリース
RED
 
 
 
 
GREEN

View Slide

● 変更とデプロイメントシステムとの結合がシームレスになると、  
次はStagingリリースの頻度を増やすことができるようになる  
● 様々な状態の組み合わせをどんどんリリースして検証したいが、  
Stagingには限りがありマシンタイムの調整コストが増えていく  
 
roles repo
inventory
repo
Staging
Container
Regsitory
Staging環境の数が並行検証できる上限 
35

View Slide

無限にStaging環境が存在したらいいのになあ！ 
36
願うだけ Staging 環境が
あればいいのに…
roles repo
inventory
repo
Staging
Container
Regsitory
Staging Staging Staging Staging
● 変更とデプロイメントシステムとの結合がシームレスになると、
 
次はStagingリリースの頻度を増やすことができるようになる
 
● 様々な状態の組み合わせをどんどんリリースして検証したいが、
 
Stagingには限りがありマシンタイムの調整コストが増えていく
 
● StagingはPRODの相似として作られており、新規構築には多くの
計算機資源と維持管理コストが必要 

View Slide

ん？計算機資源…？ 
37

View Slide

APIの裏側では物理サーバー(Hypervisor)にVMが生えている 
38
VM一丁！
[POST] /servers 
VM一丁おまち!
● OpenStack レイヤの前段にApacheが立っている
● Nova は最終的に物理マシンの上に VM(qemu)を生やす
● OpenStack/ホストOS/Hypervisorの新陳代謝は必要不可欠
User
nova-comptue
OS (Host)
Hypervisor
libvirtd
kernel
kvm
virsh
qemu
OS (Guest)
User
コンピュート
Others
Internal API

View Slide


View Slide

なければ作る！ 
40

View Slide

仮想的なStaging環境を用意する試み; SDPF VS on SDPF VS 
41
Others
OpenStack
Hypervisor
/Storage(VM)
VS Team
Auth Clone
SDN Clone
Virtual
Staging
● Staging のサブセットとしての  
OpenStack on OpenStack を開発する営み  
 
● Nested VM のため性能はお察し  
 
● しかし性能検証以外の用途では十分に機能する  
 
● Terraform で SDPF にVMを構築  
 
● 新規拠点構築のための ansible をブラッシュアップす
る機会にもなった  
 
roles repo
inventory
repo

View Slide

検証環境の並列化による開発体験の向上 
42
roles repo
inventory
repo
Container
Regsitory
Virtual
Staging
Staging
● 各メンバは検証環境のマシンタイムをそれほど気にせずにいられるようになった  
● 気軽に変更をpushし、レジストリに登録された新しいイメージは検証環境にリリースされる  
● 漸進的な結合の実現が開発体験を大きく改善  
● 開発のフローは状態遷移から、結合範囲を拡大していく作業へ  
Virtual
Staging
Virtual
Staging
Virtual
Staging

View Slide

reposの変更をPRODへデリバリーする作業とは  
1. 変更を加える 
2. 一つ外へデリバリーする  
3. デリバリー先での結合検証をする  
4. 検証をパスすれば、一つ外へ  
5. 検証に失敗すれば、一つ内へ  
● 各メンバはLABのマシンタイムをそれほど気にせずにいられるようになった  
● 気軽に変更をpushし、レジストリに登録された新しいイメージは即座にLAB0にリリースされる  
● 漸進的な結合の実現が開発体験を大きく改善  
● 開発のフローは状態遷移から、結合範囲を漸進的に拡大していく作業へ  
リリースの高速化と漸進的なデリバリー 
PROD(ALL)
PROD(JP3)
Staging
Virtual
Staging
Repos
43

View Slide

問題3. 自動テストのカバレッジが低い 
44

View Slide

45
変更
結合
検証
リリース
GREEN
RED
 
 
 
 

View Slide

reposの変更をPRODへデリバリーする作業とは  
1. 変更を加える 
2. 一つ外へデリバリーする  
3. デリバリー先での結合検証をする  
4. 検証をパスすれば、一つ外へ  
5. 検証に失敗すれば、一つ内へ  
 
● 結局 3. 4. 5 が高速で出来ないとどうしようもない  
 
● 検証にかかる時間を短くするために手動テストを減らしていく必要がある  
リリースサイクル高速化≒検証のフィードバックループの高速化 
PROD(ALL)
PROD(JP3)
Staging
Virtual
Staging
Repos
46

View Slide

● Test Sizes の考え方のベースにあるのは
Google Testing blog の Small,Medium,Large区
分 
 
● Others の Medium が手動なのも問題だが… 
 
 
テストとサービスのマトリクス 
47
Small Medium Large
Others unittest,rspec, 手動 Jest,手動
OpenStack tox,unittest,pytest Tempest Tempest,手動
ホストOS N/A Goss,手動 Goss,metricbeat,手動
ホストOS
Hypervisor
(プロセッサ)
ゲストOS
(VM)
Others

View Slide

分 
 
 
● Large 手動テストの共通項はTempestをうまく活
用出来ていないことも理由の一つ  
48
Small Medium Large
Others unittest,rspec, 手動 Jest,手動
OpenStack tox,unittest,pytest Tempest Tempest,手動
ホストOS N/A Goss,手動 Goss,metricbeat,手動
ホストOS
Hypervisor
(プロセッサ)
ゲストOS
(VM)
Others

View Slide

Tempestってなに？ 
49

View Slide

OpenStackの論理アーキテクチャ 
50
https://docs.openstack.org/install-guide/get-started-logical-architecture.html
 

View Slide

OpenStackの論理アーキテクチャ 
51
よくわかんないけ
ど複雑そう
https://docs.openstack.org/install-guide/get-started-logical-architecture.html
 

View Slide

Q. Tempestって何？ 
 
● 複雑な状態,複雑なコンポーネントが結合しあうOpenStackでは横断/結合を
軸としたテストを専門のコンポーネントが必要 
○ OSSの結合テストとしても組み込まれている
○ Tempest 自体も複雑で、使いこなすのは難しいと言われている
 
● APIテスト、シナリオテスト、ストレステストなどカバー範囲は広い 
 
● 我々もサービス開始当初から Tempest を利用している 
52
へー
A. OpenStack のテストのためのコンポーネント 

View Slide

Q. Tempestって何？ 
53
人と歴史の
マリアージュ
しかし、現在は秘伝のタレ化しており 
　　　　継続的にメンテナンスできる状況ではない 
A. OpenStack のテストのためのコンポーネント 
 
● 複雑な状態,複雑なコンポーネントが結合しあうOpenStackでは横断/結合を
軸としたテストを専門のコンポーネントが必要 
○ OSSの結合テストとしても組み込まれている
○ Tempest 自体も複雑で、使いこなすのは難しいと言われている
 
● APIテスト、シナリオテスト、ストレステストなどカバー範囲は広い 
 
● 我々もサービス開始当初から Tempest を利用している 

View Slide

Tempestの手の内化とCI/CDとの結合 
 
● OpenStackを開発するフローになるべく寄
せていくことに 
● SDPFが蓄積したOpenStackへの機能追加
をよりUpstreamにコントリビュートしやすい
体制を構築 
 
■これまでの道のり  
 
1. Tempest の習熟 
2. 秘伝のタレTempestの理解/再利用  
3. 独自シナリオの実装  
4. CI/CDとの結合 
5. 既存の手動試験の実装  
時間はかかったものの、  
複利を考えるとよい投資になった  
nova
cinder
glance
Repos
PUSH
tempest
OpenStack Test VM
Self-hosted runner
● Unit Test
● Tempest
roles repo
inventory
repo
Container
Regsitory
Virtual
Staging
Staging
54

View Slide

分 
 
 
● Large 手動テストの共通項はTempestをうまく活
用出来ていないことも理由の一つ  
55
Small Medium Large
Others unittest,rspec, 手動 Jest
OpenStack tox,unittest,pytest Tempest Tempest
ホストOS N/A Goss,手動 Goss,metricbeat
ホストOS
Hypervisor
(プロセッサ)
ゲストOS
(VM)
Others

View Slide

56
変更
結合
検証
リリース
RED
①変更結果が即座に結合されない。ている。 
リポジトリとデプロイシステムとのシームレス結合が出来
ていない出来ている。 
 
②結合先の Staging 環境が少ない十分存在するため、
様々なバージョンの組み合わせを並行して検証できな
い。できている。また、連携チームや自チーム内でマシン
タイムの調整が必要になる頻度が減った。 
 
③手動テストが多い少ない。 
OpenStackのE2E試験コンポーネントであるTempestがメ
ンテナンス出来ていない出来ている。 
GREEN

View Slide

 
 
57
来ていない 
 
目次 
改善
 
{ 
{ 
{ 
背景と動機
おわりに

View Slide

リリースサイクルの高速化の仕組みを調べて改
善してみました！ 
58

View Slide

いかがでしたか？ 
59

View Slide

義務ではないけどやっていきたい諸タスクに取りかかれない 
 
 
● … 
 
● … 
 
60
8人:
👨👨👨👨👨👨👨👨 
重要
緊急
開発

View Slide

赤を縮小させて青を大きくしたい 
 
 
● … 
 
● … 
 
61
8人:
👨👨👨👨👨👨👨👨 
次のホストOS
verup 対応
重要
緊急
次の
OpenStack
verup 対応
開発

View Slide

現在 
62

View Slide

赤いタスクが縮小し青いタスクが出来るようになってきた 
 
 
● … 
 
● … 
 
63
8人:
👨👨👨👨👨👨👨👨 
次のホストOS verup
対応
重要
緊急
次のOpenStack verup
対応
可観測性
の向上
式年遷宮
新API/サービス
の開発

View Slide

赤いタスクが縮小し青いタスクが出来るようになってきた 
 
 
● … 
 
● … 
 
64
8人:
👨👨👨👨👨👨👨👨 
次のホストOS verup
対応
重要
緊急
次のOpenStack verup
対応
可観測性
の向上
式年遷宮
新API/サービス
の開発
リリースサイクル
が早くなり、見え
てきた別の問題
もある

View Slide

さいごに 
● リリースサイクルを改善してくことで、「やっていき」へ投資できるようになった 
○ 可観測性への投資や式年遷宮など
 
 
● プロダクトを継続的に成長させるために重要な点は、 
人や歴史にロバストな要素を育んでいくこと 
○ 方針やポリシー、開発文化、アーキテクチャを継続的に成長させていくこと
○ どういうポリシーでリリースサイクルを回すのか
 
● 今後もSDPF VS開発チームは成長していくと思います 
○ 興味のある方は声をかけてみてください、一緒に楽しい開発をやっていきましょう
65

View Slide

おわり 
66

View Slide

CODT2022_エンタープライズ向けクラウドサービス仮想サーバ基盤開発のリリースサイクル改善 / CODT2022_Improvement of release cycle for development of virtual server infrastructure for enterprise cloud services

CODT2022_エンタープライズ向けクラウドサービス仮想サーバ基盤開発のリリースサイクル改善 / CODT2022_Improvement of release cycle for development of virtual server infrastructure for enterprise cloud services

NTT Communications

More Decks by NTT Communications

Other Decks in Technology

Featured

Transcript