MSPサービスを支える Infrastracture as Code（IaC）の これまでとこれから ソフトバンク株式会社 法人事業統括 クラウドエンジニアリング本部 PaaSエンジニアリング第2統括部 サービス開発部 DevOps2課 嵯峨 毅郎(Saga Takeo)

• 2019年ソフトバンク株式会社に入社後、MSPサービス立ち上げプロジェクトに参画 し、基幹部分となるCI/CDパイプラインを開発（後に特許取得） • ブロックチェーンを活用したサービス化検討にも従事 • 資格試験「LinuC」の監修 • プライベートでは音楽家の顔を持ち、自主レーベルで複数のアルバムを リリース。プロとの共演もあるが、収支はいつも赤字 • （エンジニア活動用SNSアカウントは）ないです Saga Trio ”Teal”(2019) Sustainable PoP (2021) Toward Wired (2022) Cyberia Layer:03 After Hours(2020) Cyberia Layer:04 (2022) ほぼDM連絡用の インスタアカウント ここ最近のリリース の自己紹介

アジェンダ 1. ソフトバンク、クラウド事業やってます 2. 我々が注力するMSP（Managed Service Provider）について 3. MSPを推進するための課題が２つ 4. Infrastructure as code （IaC）のトライアンドエラー 5. サービスとして他社に売ろう（CNAP・DevOps基盤） 6. 現在の課題 7. まとめ＋メッセージ

１．ソフトバンク、クラウド事業やってます

ソフトバンクの提唱する成長戦略 • 通信事業をコアとして • 情報テクノロジーを活用した • 顧客のDX支援ビジネスに注力 5

２．ソフトバンクのManaged Service Providerサービス アセスメント システムデザイン プロビジョニング インテグレーショ ン モニタリング オペレーション マネジメント ライフサイクル マネジメント ITライフサイクルの提供 導入から運用までフルサポート 1. Azure/AWS/GC の提供 Azure/AWS/GCをPAYG(従量課金)ビジネスモ デルで提供します。 2. クラウドマネージドサービスの提供 DevOps、自動化、クラウドネイティブ アプ リケーション設計、構築を提供し、IaaS、 PaaS、SaaSなどのソリューション設計に Azureの優れた機能を活用して、お客様のビジ ネスをご支援します。 また、柔軟なPAYG(従量課金)ビジネスモデル を採用することで、共通のサポート、プロビ ジョニング、課金エクスペリエンスをワンス トップで提供します。 6 MSPサービス

３．MSPビジネスを拡大するための課題が２つ （2018) Infrastructure as code (IaC)の導入 • パブリッククラウドは低コスト路線なので、構築や運用に工数をかけられない （クラウドコストと人件費のバランスの問題、人手をかけたら負け） Expert MSP認定の取得 • 我々がクラウドソリューションに注力していることを知ってもらわなければいけない • 我々がクラウドを使いこなせることを第三者に証明してもらわなければいけない

４-1．IaC実現のためのCI/CDパイプラインを開発 初期型が完成（2019年9月） Azure環境 SB Azure運用基盤 用サブスクリプション Azure環境 ユーザセルフ用サブスクリプション マネージド（管理）用サブスクリプション ITSMC Azure Monitor Azure Service Health Log Analytics/OMS 踏み台 その他環境 MSPプロバイダ (SB) 顧客 顧客環境 メールサーバ 踏み台 ユーザ マネージドサービス システムフロー Azure Security Center Azure Advisor Azure Cost Management CMP用Azure運用基盤 顧客テナント ダッシュボード/コスト管理/セキュリティ/プロビ ジョニング/オーケストレーション/サービスカタログ /リソースモニタリング/ガバナンス Partner Center コスト情報取得 通知 メール通知 通知 通知 監視 通知 監視 監視 通知 EAA connecter 社内請求 システム マネージド（サービス）用サブスクリプション Backu p DB Migrate Migrate Automatio n ・・ ・ ・・ ・ ・・ ・ ・・ ・ Policy ログ保管 Ansible Jenkins Ansible Inspec Inspec ThirPartyのCMP

IaCな基盤がそれっぽく動き喜んでいたが、 ここで気づく ぜ ん ぜ ん わ か ら な い 俺 た ち は 雰 囲 気 で CI/CD を や っ て い る ※自主規制

IaCを学び、パイプラインをブラッシュアップ

4-2．CI/CDパイプラインの一連の流れを整理した スタート マネージド(管理)用サブスク ソフトバンク環境 開発環境用サブスク 運用管理サブスク マネージド(サービス)用 サブスク ステージング 本番環境 SB(開発 者) 開発用 VDI 踏み 台 ① EAA経由で 踏み台にログ イン ② 開発用VDIに ログイン ③ ステージング コード作成& 展開テスト ⑤ 人がコードマー ジ承認 ⑦ コードの 構文テスト ⑨ Ansible(SB )で リソース(Stg) を プロビ ⑩ InSpec(SB) で リソース(Stg) を プロビテスト ⑪ vNet Peering(St g)をプロビ ⑫ Ansible(顧 客)でリソース (Stg)を 構築(OS以 上) ⑬ InSpec(顧 客)でリソース (Stg)を 単体結合テス ト ⑭ SB/顧客で UAT ④ Githubのステー ジングリポジトリ にプルリク ⑥ Githubから Jenkinsに webhook ⑧ コードの静的解 析 エンド(リリース) ⑮ 開発用VDIに ログイン ⑯ 本番コード作 成 ⑱ 人がコードマー ジ承認 ⑳ コードの 構文テスト ㉒ Ansible(SB)で リソース(本番)を プロビ ㉓ InSpec(SB)で リソース(本番)を プロビテスト ㉔ vNet Peering(本 番)をプロビ ㉕ Ansible(顧 客)でリソース (本番)を構築 (OS以上) ㉖ InSpec(顧 客)でリソース (本番)を単体 結合テスト ㉗ SB/顧客で UAT ⑰ Githubの本番 リポジトリにプルリ ク ⑲ Githubから Jenkinsに webhook ㉑ コードの静的解 析 ① ②, ⑮ ③, ⑯ ④, ⑰ ⑤, ⑱ SB(承認者) ⑥, ⑲ ⑦, ⑧⑳, ㉑ ⑨,⑪ ⑩ Ansible(SB ) InSpenc(SB ) Ansible(顧 客) InSpenc(顧 客) ⑫ SB/顧客 (承認者) Peering Peering ⑬ ⑭ ㉒,㉔ ㉓ ㉕ ㉖ ㉗ リソース(Stg) リソース(本 番) コード取得 CI/CD結果 を通知 アラート を通知

4-3．CI/CDパイプラインで顧客環境のインフラ構築を自動化 手動で１日かけて行われていた構築作業を1時間に削減 Azure環境 顧客環境 Azure環境 顧客用サブスクリプション Azure Monitor Log Analytics/OMS 作業端末 Jenkins サーバ Ansible ソフトバンク MSP運用基盤 用サブスクリプション Inspec GitHub ARM Slack 顧客独自の 環境 Webhook

開発したCI/CDパイプラインを駆使して Expert MSP認定を取得 本当大変だった… https://www.softbank.jp/biz/blog/business/articles/202004/msp_certification/

4-4．CI/CDパイプラインで特許を出願（後に取得） ねらい ・開発した技術で競合他社をけん制する…意味はあまりない ・後程取得された特許で我々が訴えられるリスクを避ける ・「発明者」に自分の名前が掲載されて士気が高まる ・会社からお金がもらえる ちょっとだけ

4-5．課題：IaaSの管理は何かと面倒だと気づく(2019年度末) 若手社員がJenkinsを使いながらキレていたので慌ててヒアリングして発覚 Azure環境 作業端末 Jenkins サーバ Ansible ソフトバンク MSP運用基盤 用サブスクリプション Inspec GitHub ARM Slack ウイルス対策・脆弱性対策・アップデート サーバのチューニング・障害対策・同時実 行数・OSの混在するワークフローが作れ ない etc.. Third PartyのCIツールを使おう ・SaaS使った方が安定しそう ・エンジニアの稼働をサービスの高度化に 集中させられそう

4-6．当時の比較表：SaaSを使った方が良いと判断した。 具体的な数字が出てくる本項はミスリードになる可能性があるのでマスクするが、 我々の利用状況ではCircleCIの方がかなり安くなった。 ※１：当時GitHub Actionにも注目していたが、GAされたばかりで不安があったため導入は見送られた ※２：WindowsサーバでJenkinsを作ればWin対応もできたがCentOS一台で運用していたためこの結果となった ※２ ※１

開発者 ソフトバンク DevOps環境 顧客環境 ユーザセルフ用サブスクリプション マネージド（管理）用サブスクリプション マネージド（サービス）用サブスクリプション 承認者 (開発マネージャ/案件PM) CircleCI GitHub ① Pull Request AWX (Ansible) AKS DB (PaaS) リバプロ兼 Inspecサーバ Linux VM Windows VM ② Merge ③ Webhook (HTTPS) ⑤ AWX REST API実行 (HTTPS) Azure Firewall AAG (L7) ⑥ Playbook実行 (SSH/WinRM) Private IP にNAT SSH WinRM ④ リソースプロビジョニング 4-7．CircleCI導入後の環境（2020年Q1） ※ここでTerraformの導入も同時に検討したが、まだ我々の要求するレベルまでAzureに対するTerraform機能は充実しておらず、2022年から対応した

4-8．CircleCIに切り替えたメリットは大きかった GUIでJobごとに実行結果が可視化される。 他にもメリットはたくさん ・Windows/Linuxを組み合わせたワークフローを楽に組める Macは一度も使ったことない ・Orbが充実しており各クラウドへのリソースデプロイを時短。AWS/GCへの拡張も特に問題なかった ・GitHubのグループを活用してワークフローの承認をリーダークラスの社員に制限 ・SSHでビルドを実行中の環境にログインしてデバッグできるのが地味に助かる ・Artifactが便利。Terraform Planの内容をArtifactで出して問題なければデプロイする などなど プロジェクト名

4-9：CI/CDパイプラインが安定したことでMSPのサービス 拡張に注力できるようになった（2020-2022） ■Azure Virtual Desktop（旧WVD）専用サービスの開発 ・AVD PoCサービス（Plan A/B） - Plan A：とりあえずAVDを使いたい人向け - Plan B：本番環境での利用を見据え、オンプレ環境との接続など 実利用を想定した作りこみをして検証したい顧客向け ■マルチクラウド対応（AWS/GC） ■プランの適用範囲の拡張でより多くの顧客にMSPを提供可能に

4-10．課題：CI/CDパイプラインは使いこなすハードルが高い パラメーターシート作成 構築チーム作業 運用チーム作業 顧客からの作業依頼 ヒアリングシート受領 json/yaml資源生成 顧客リポジトリ最新化＆格納 PullRequest作成 PullRequest承認＆マージ ワークフロー承認 ワークフロー実行 動作確認 必ず人が介在 すべき作業 CI/CDで実行 特に作業負荷が 大きく 熟練度にも依存 手動作業 自動化済み 見積もり作成 json/yaml資源生成 ・当初はCI/CD関連ツールに全社員が習熟することを目指し、GUIを提供することを避けていた。 ・しかし、手順書通りの作業をすることに慣れたオペレータに対して、json/yaml形式のファイルと、GitHub、 CircleCIを使いこなし、エラー発生時には実行環境上のエラーを調査することを求めるのは難しかった。

見積もり作成 パラメーターシート作成 json/yaml資源生成 構築チーム作業 運用チーム作業 顧客からの作業依頼 ヒアリングシート受領 json/yaml資源生成 顧客リポジトリ最新化＆格納 PR作成 PR承認＆マージ ワークフロー承認 ワークフロー実行 動作確認 見積もりアプリ で効率化 運用支援アプリを 新規開発し効率化 手動作業 自動化済み 4-11．対策：作業を簡易に実施するアプリを作成して支援 必ず人が介在 すべき作業 CI/CDで実行

4-12．開発した運用支援アプリの見た目

23 担当領域の拡大 不慣れな インフラコード化 →コードの肥大化 ・複雑化 新たな手法 の学習 インフラ担当者 アプリ開発者 • 困難なフルスタックエンジニア調達 • 追いつかない社内エンジニア育成 部門責任者の 悩みの種 ５-1．IaCの気づき｜ ”技術と学習の崖” が想像以上に高い 困っているのは我々だけじゃないはず → これは売れる…かもしれない

© SoftBank Corp. All Rights Reserved. 24 Infrastructure as Low Codeを実現！ クラウドネイティブ・ アプリケーションプラットフォーム CNAP

25 インフラ知識が乏しいアプリケーション開発者が セルフサービスで、わずか数時間で準備できるしくみ ドメイン名など 最低限の 固有の設定値 入力 アプリ開発者 基本構成 パッケージ RDB パッケージ 投入 CNAP 生成 数種類の標準化されたパッケージから 必要なパッケージを選択 構築作業を自動化 “事前検証済み”の環境を いつでもご利用可能 本番稼働後の頻繁なアップデー ト運用もソフトバンクが実施 ※CNAPについての解説はこちらを参考にしてください

５-2．CI/CDパイプラインを含むDevOps基盤を提供する マネージド(管理)用サブスク SB環境 開発環境用サブスク 運用管理サブスク マネージド(サービス)用 サブスク ステージング 本番環境 SB(開 発者) 開発用 VDI 踏 み 台 スタート ① EAA経由で 踏み台にログ イン ② 開発用VDIに ログイン ③ ステージング コード作成& 展開テスト ⑤ 人がコードマー ジ承認 ⑦ コードの 構文テスト ⑨ Ansible(SB) で リソース(Stg) を プロビ ⑩ InSpec(SB) で リソース(Stg) を プロビテスト ⑪ vNet Peering(Stg )をプロビ ⑫ Ansible(顧 客)でリソース (Stg)を 構築(OS以 上) ⑬ InSpec(顧 客)でリソース (Stg)を 単体結合テス ト ⑭ SB/顧客で UAT ④ Githubのステー ジングリポジトリ にプルリク ⑥ Githubから Jenkinsに webhook ⑧ コードの静的解 析 エンド(リリー ス) ⑮ 開発用VDIに ログイン ⑯ 本番コード作 成 ⑱ 人がコードマー ジ承認 ⑳ コードの 構文テスト ㉒ Ansible(SB) で リソース(本 番)を プロビ ㉓ InSpec(SB)で リソース(本番)を プロビテスト ㉔ vNet Peering(本 番)をプロビ ㉕ Ansible(顧 客)でリソース (本番)を構築 (OS以上) ㉖ InSpec(顧 客)でリソース (本番)を単体 結合テスト ㉗ SB/顧客で UAT ⑰ Githubの本番 リポジトリにプルリ ク ⑲ Githubから Jenkinsに webhook ㉑ コードの静的解 析 ① ②, ⑮ ③, ⑯ ④, ⑰ ⑤, ⑱ SB(承 認者) ⑥, ⑲ ⑦, ⑧ ⑳, ㉑ ⑨, ⑪ ⑩ Ansible( SB) InSpenc (SB) Ansible( 顧客) InSpenc (顧客) ⑫ SB/顧 客 (承認 者) Peering Peering ⑬ ⑭ ㉒, ㉔ ㉓ ㉕ ㉖ ㉗ リソース (Stg) リソース(本 番) コード 取得 CI/CD 結果を 通知 アラー トを通 知 DevOps・CI/CDなどを導入したい顧客に対し、その設計構築を代行する ※下図はイメージ図です。実際に提供している基盤ではありません

６．現在の課題：クラウドネイティブな世界に ついていけない仕組みと人 ◼ 社内ルールに則った業務プロセスがIaCに都合が悪いことがある • 人が作業をする前提のプロセス • 承認行為がワークフローと一体化する必要がある ◼ IaCは複雑。適応した人間とそうでない人間で二極化が進む • 適応できない人間はアラートメッセージすら確認しない →極力仕組みをシンプルにする • Terraformを共通言語として、ARMなど特定クラウドで 利用する機能を廃止してシンプル化 →人を育てる →イケてる人を雇う

７．最後にメッセージ ・CNAPのパートナーを募集しています - All in OneなK8S基盤構築・運用サービスです。ご利用いただき フィードバックをいただけるパートナーを探しています。 是非興味がある方はお声掛けください。 ・IaCに興味がある、自分の腕を試したいエンジニアを募集しています - IaCを高度化していき、MSPサービスのカバレッジを拡げていくにあたり、 腕に自信のあるエンジニアが必要です。

ソフトバンクではさらなる事業拡大のため キャリア採用を実施中です ソフトバンク キャリア採用 詳細はこちら