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) 

© NTT Communications Corporation All Rights Reserved. ソフトウェアアーキテクト  佐野　成(@say3no)  自己紹介 
2

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

© NTT Communications Corporation All Rights Reserved. 11 仮想サーバー ∈
Smart Data Platform 

© NTT Communications Corporation All Rights Reserved. 12 仮想サーバー ∈
Smart Data Platform 

© NTT Communications Corporation All Rights Reserved. 仮想サーバーの規模感  • 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/

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

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

© NTT Communications Corporation All Rights Reserved. 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

© NTT Communications Corporation All Rights Reserved. 新陳代謝はサービス継続のための義務やらないと詰む  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関連

© NTT Communications Corporation All Rights Reserved. 新陳代謝の方法論；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) SDN関連 Storage関連これまで、OpenStack Juno -> Mitaka   ホストOS Ubuntu 14 -> 16/ RHEL 7.4 -> 7.6 を実施してきた   順当にいけば次は OpenStack Mitaka -> Queens だが…  

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

© NTT Communications Corporation All Rights Reserved. 義務ではないけどやっていきたい諸タスクに取りかかれない  VS開発チーム  
    サービス継続のための義務   • 次のOpenStack verup 対応   • 次のホストOS verup 対応   • その次の OpenStack verup 対応   • その次のホストOS verup 対応   • 差し込みのCPU脆弱性対応   • …    いい感じにやっていきするためのタスク  • 物件費を下げる   • 収容効率を上げる   • 新API/サービス開発   • 新ゲストOS開発   • …    20 8人: 👨👨👨👨👨👨👨👨  次のホストOS verup 対応重要緊急次のOpenStack verup 対応物件費を下げる収容効率を上げる新API/サービスの開発

© NTT Communications Corporation All Rights Reserved. 赤を縮小させて  VS開発チーム  
    サービス継続のための義務   • 次のOpenStack verup 対応   • 次のホストOS verup 対応   • その次の OpenStack verup 対応   • その次のホストOS verup 対応   • 差し込みのCPU脆弱性対応   • …    いい感じにやっていきするためのタスク  • 物件費を下げる   • 収容効率を上げる   • 新API/サービス開発   • 新ゲストOS開発   • …    21 8人: 👨👨👨👨👨👨👨👨  次のホストOS verup 対応重要緊急次の OpenStack verup 対応物件費を下げる収容効率を上げる新API/サービスの開発

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

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

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

© NTT Communications Corporation All Rights Reserved. • 検証環境にデリバリーするための前作業。  
• ある区間や目標の間に加えたら、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ための  ブランチワークやタギング 

© NTT Communications Corporation All Rights Reserved. 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

© NTT Communications Corporation All Rights Reserved. 変更とデプロイメントとのシームレスな結合;継続的デリバリー  • 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

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

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

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

© NTT Communications Corporation All Rights Reserved. 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

© NTT Communications Corporation All Rights Reserved. 仮想的な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

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

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

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

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

© NTT Communications Corporation All Rights Reserved. • 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) SDN関連 Storage関連 Others

の考え方のベースにあるのは Google Testing blog の Small,Medium,Large区分    • Others の Medium が手動なのも問題だが…    • 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) SDN関連 Storage関連 Others

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

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

© NTT Communications Corporation All Rights Reserved. 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

の考え方のベースにあるのは Google Testing blog の Small,Medium,Large区分    • Others の Medium が手動なのも問題だが…    • 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) SDN関連 Storage関連 Others

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

© NTT Communications Corporation All Rights Reserved. 義務ではないけどやっていきたい諸タスクに取りかかれない  VS開発チーム  
    サービス継続のための義務   • 次のOpenStack verup 対応   • 次のホストOS verup 対応   • その次の OpenStack verup 対応   • その次のホストOS verup 対応   • 差し込みのCPU脆弱性対応   • …    いい感じにやっていきするためのタスク  • 物件費を下げる   • 収容効率を上げる   • 新API/サービス開発   • 新ゲストOS開発   • …    60 8人: 👨👨👨👨👨👨👨👨  次のホストOS verup 対応重要緊急次のOpenStack verup 対応物件費を下げる収容効率を上げる新API/サービスの開発

© NTT Communications Corporation All Rights Reserved. 赤いタスクが縮小し青いタスクが出来るようになってきた  VS開発チーム  
    サービス継続のための義務   • 次のOpenStack verup 対応   • 次のホストOS verup 対応   • その次の OpenStack verup 対応   • その次のホストOS verup 対応   • 差し込みのCPU脆弱性対応   • …    いい感じにやっていきするためのタスク  • 物件費を下げる   • 収容効率を上げる   • 新API/サービス開発   • 新ゲストOS開発   • …    63 8人: 👨👨👨👨👨👨👨👨  次のホストOS verup 対応重要緊急次のOpenStack verup 対応可観測性の向上式年遷宮新API/サービスの開発

© NTT Communications Corporation All Rights Reserved. 赤いタスクが縮小し青いタスクが出来るようになってきた  VS開発チーム  
    サービス継続のための義務   • 次のOpenStack verup 対応   • 次のホストOS verup 対応   • その次の OpenStack verup 対応   • その次のホストOS verup 対応   • 差し込みのCPU脆弱性対応   • …    いい感じにやっていきするためのタスク  • 物件費を下げる   • 収容効率を上げる   • 新API/サービス開発   • 新ゲストOS開発   • …    64 8人: 👨👨👨👨👨👨👨👨  次のホストOS verup 対応重要緊急次のOpenStack verup 対応可観測性の向上式年遷宮新API/サービスの開発リリースサイクルが早くなり、見えてきた別の問題もある

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

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

More Decks by NTT Communications

Other Decks in Technology

Featured

Transcript