Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MSPサービスを支えるIaCのこれまでとこれから

 MSPサービスを支えるIaCのこれまでとこれから

2023年3月16日に開催された「SoftBank Tech Night Fes 2023」の講演資料です。

ソフトバンク株式会社の法人事業統括では、クラウドを活用したDXソリューションを加速させるため、Azure/AWS/Google Cloud を活用したMSPサービスを内製で開発・リリースしました。2019年にリリースした本サービスではより高度なInfrastructure as Code(IaC)実現のための絶え間ない試行錯誤があり、今もその途中です。本セッションでは現在も続くIaCへのチャレンジについて、3年間の歩みと学びを共有させていただきます。これからIaC・DevOps・CI/CDといった手法にチャレンジする方々の参考になれば幸甚です。

■関連リンク
・クラウドネイティブ・アプリケーションプラットフォーム(CNAP)
https://www.softbank.jp/biz/services/platform/msp-service/cnap/

・ソフトバンクaPaaS領域への挑戦
https://speakerdeck.com/sbtechnight/sohutobankuapaasling-yu-hefalsetiao-zhan

■作成者
嵯峨 毅郎(さが たけお)
ソフトバンク株式会社
法人事業統括 クラウドエンジニアリング本部 PaaSエンジニアリング第2統括部 サービス開発部 DevOps2課
担当課長

■SoftBank Tech Nightについて
ソフトバンク株式会社のエンジニア有志が開催するテックイベントです。
各分野のエキスパートが、日頃培った技術や事例、知見について発信しています。
イベントは開催スケジュールはconnpassをご確認ください。
https://sbtechnight.connpass.com/

SoftBank Tech Night Fes 2023公式サイト
https://www.softbank.jp/biz/events/tech-night-fes-2023/

SoftBank Tech Night

March 16, 2023
Tweet

More Decks by SoftBank Tech Night

Other Decks in Technology

Transcript

  1. アジェンダ 1. ソフトバンク、クラウド事業やってます 2. 我々が注力するMSP(Managed Service Provider)について 3. MSPを推進するための課題が2つ 4.

    Infrastructure as code (IaC)のトライアンドエラー 5. サービスとして他社に売ろう(CNAP・DevOps基盤) 6. 現在の課題 7. まとめ+メッセージ
  2. 2.ソフトバンクのManaged Service Providerサービス アセスメント システムデザイン プロビジョニング インテグレーショ ン モニタリング オペレーション

    マネジメント ライフサイクル マネジメント ITライフサイクルの提供 導入から運用までフルサポート 1. Azure/AWS/GC の提供 Azure/AWS/GCをPAYG(従量課金)ビジネスモ デルで提供します。 2. クラウドマネージドサービスの提供 DevOps、自動化、クラウドネイティブ アプ リケーション設計、構築を提供し、IaaS、 PaaS、SaaSなどのソリューション設計に Azureの優れた機能を活用して、お客様のビジ ネスをご支援します。 また、柔軟なPAYG(従量課金)ビジネスモデル を採用することで、共通のサポート、プロビ ジョニング、課金エクスペリエンスをワンス トップで提供します。 6 MSPサービス
  3. 3.MSPビジネスを拡大するための課題が2つ (2018) Infrastructure as code (IaC)の導入 • パブリッククラウドは低コスト路線なので、構築や運用に工数をかけられない (クラウドコストと人件費のバランスの問題、人手をかけたら負け) Expert

    MSP認定の取得 • 我々がクラウドソリューションに注力していることを知ってもらわなければいけない • 我々がクラウドを使いこなせることを第三者に証明してもらわなければいけない
  4. 4-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
  5. IaCな基盤がそれっぽく動き喜んでいたが、 ここで気づく ぜ ん ぜ ん わ か ら な

    い 俺 た ち は 雰 囲 気 で CI/CD を や っ て い る ※自主規制
  6. 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結果 を通知 アラート を通知
  7. 4-5.課題:IaaSの管理は何かと面倒だと気づく(2019年度末) 若手社員がJenkinsを使いながらキレていたので慌ててヒアリングして発覚 Azure環境 作業端末 Jenkins サーバ Ansible ソフトバンク MSP運用基盤 用サブスクリプション

    Inspec GitHub ARM Slack ウイルス対策・脆弱性対策・アップデート サーバのチューニング・障害対策・同時実 行数・OSの混在するワークフローが作れ ない etc.. Third PartyのCIツールを使おう ・SaaS使った方が安定しそう ・エンジニアの稼働をサービスの高度化に 集中させられそう
  8. 開発者 ソフトバンク 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年から対応した
  9. 4-9:CI/CDパイプラインが安定したことでMSPのサービス 拡張に注力できるようになった(2020-2022) ▪Azure Virtual Desktop(旧WVD)専用サービスの開発 ・AVD PoCサービス(Plan A/B) - Plan

    A:とりあえずAVDを使いたい人向け - Plan B:本番環境での利用を見据え、オンプレ環境との接続など 実利用を想定した作りこみをして検証したい顧客向け ▪マルチクラウド対応(AWS/GC) ▪プランの適用範囲の拡張でより多くの顧客にMSPを提供可能に
  10. 4-10.課題:CI/CDパイプラインは使いこなすハードルが高い パラメーターシート作成 構築チーム作業 運用チーム作業 顧客からの作業依頼 ヒアリングシート受領 json/yaml資源生成 顧客リポジトリ最新化&格納 PullRequest作成 PullRequest承認&マージ

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

    PR承認&マージ ワークフロー承認 ワークフロー実行 動作確認 見積もりアプリ で効率化 運用支援アプリを 新規開発し効率化 手動作業 自動化済み 4-11.対策:作業を簡易に実施するアプリを作成して支援 必ず人が介在 すべき作業 CI/CDで実行
  12. 23 担当領域の拡大 不慣れな インフラコード化 →コードの肥大化 ・複雑化 新たな手法 の学習 インフラ担当者 アプリ開発者

    • 困難なフルスタックエンジニア調達 • 追いつかない社内エンジニア育成 部門責任者の 悩みの種 5-1.IaCの気づき| ”技術と学習の崖” が想像以上に高い 困っているのは我々だけじゃないはず → これは売れる…かもしれない
  13. © SoftBank Corp. All Rights Reserved. 24 Infrastructure as Low

    Codeを実現! クラウドネイティブ・ アプリケーションプラットフォーム CNAP
  14. 25 インフラ知識が乏しいアプリケーション開発者が セルフサービスで、わずか数時間で準備できるしくみ ドメイン名など 最低限の 固有の設定値 入力 アプリ開発者 基本構成 パッケージ

    RDB パッケージ 投入 CNAP 生成 数種類の標準化されたパッケージから 必要なパッケージを選択 構築作業を自動化 “事前検証済み”の環境を いつでもご利用可能 本番稼働後の頻繁なアップデー ト運用もソフトバンクが実施 ※CNAPについての解説はこちらを参考にしてください
  15. 5-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などを導入したい顧客に対し、その設計構築を代行する ※下図はイメージ図です。実際に提供している基盤ではありません
  16. 6.現在の課題:クラウドネイティブな世界に ついていけない仕組みと人 ◼ 社内ルールに則った業務プロセスがIaCに都合が悪いことがある • 人が作業をする前提のプロセス • 承認行為がワークフローと一体化する必要がある ◼ IaCは複雑。適応した人間とそうでない人間で二極化が進む

    • 適応できない人間はアラートメッセージすら確認しない →極力仕組みをシンプルにする • Terraformを共通言語として、ARMなど特定クラウドで 利用する機能を廃止してシンプル化 →人を育てる →イケてる人を雇う