国産クラウドを支える設計とチームの変遷 “技術・組織・ミッション”

国産クラウドを支える設計とチームの変遷
“技術・組織・ミッション”
アーキテクチャConference 2025

Transcript

1. 2025/11/20 Masahiro Nagano @kazeburo 国産クラウドを 支 える設計とチームの変遷 “技術・組織・ミッション” アーキテクチャConference 2025
2. Me • 長 野雅広(ながのまさひろ) • @kazeburo (X, GitHub, mixi2) • さくらインターネット株式会社 クラウド事業本部 副本部 長 テクノロジー室(旧SRE室)ファウンダー • mixi、livedoor (現 LINEヤフー) 、 mercariを経て2021年から現職 コロナ禍でランニングをやりはじめ、 ハーフマラソン・フルマラソンにも挑戦してます
3. Agenda • 国産クラウド「さくらのクラウド」とは • ガバメントクラウドの取り組みの現在地 • 国産クラウド「さくらのクラウド」のアーキテクチャ • チーム構造とアーキテクチャの変遷 • 変化と信頼性とプロダクト
5. “さくらのクラウド” • 2011年11 月 15 日 IaaS型クラウドとしてサービス開始 • 15年 目 に 入 りました • 仮想サーバ、ストレージ、ネットワークを中 心 とするIaaS型クラウドとして提供開始 • DNS、仮想ルータ、ロードバランサ、RDBMSなどマネージメントサービスも順次展開 • 特徴 • ソブリニティ（データ主権、技術主権、運営主権） • わかりやすい料 金 体系(データ転送量による従量課 金 なし、為替の影響を受けない)
6. “さくらのクラウド” • リージョンは東京と北海道” 石 狩”の2拠点 • ゾーンは東京2ゾーン、 石 狩3ゾーン • 各ゾーンを閉域網で接続、 オンプレミスや他社CSPとも接続できる ネットワークサービスも展開
7. ガバメントクラウド認定* • 2023年 「ガバメントクラウド整備のためのクラウドサービス」に認定* • 国産クラウドとしては唯 一 の認定 • 2025年度末までに”技術要件”を全て満たすことを前提に認定 • ガバメントクラウド認定の狙い • クラウド最適化、モダンなアプリケーション開発というデジタル庁の狙いはさくらインター ネットの中 長 期の取組みとも合致 • IaaS型のクラウドから、フルスペックのクラウドプラットフォームとして進化させ、モダン なクラウドサービスに適合する
8. クラウドサービスの進化 年 抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化
9. クラウドサービスの進化とITシステムの変化 • クラウドの進化を前提にITシステムのアーキテクチャは 大 きく変化 • インフラ基盤の抽象化により、具体的な課題の解決にフォーカス • 高 いレベルのサービス統合によるITシステムの統制の実現 • 宣 言 的なアプローチ • 生 成AIの普及によって 支 援が得られやすい上記のようなアーキテクチャの選 択機会がさらに増加、加速する
10. 「IaaS型クラウドサービス」の 立 ち位置 年 抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化
11. 「IaaS型クラウドサービス」の 立 ち位置 年 抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化 IaaS型クラウド サービス
12. 「IaaS型クラウドサービス」の 立 ち位置 年 抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化 IaaS型クラウド サービス
13. 「フルスペック・クラウドプラットフォーム」へ • さくらのクラウドは、クラウドを前提としたアーキテクチャに必要な主要コ ンポーネントを揃えるフルスペックのクラウドプラットフォームを 目 指す • 濃淡はあれど、抽象度/統合度の 高 いサービスへ移 行 は間違いなく進む • これまでのサービス、やり 方 では広い顧客の課題を解決することができない • ガバメントクラウドの技術要件はクラウドでITシステムを作る上での必要な機 能のサブセットをうまく選択している • 技術要件を満たし、正式な認定を得ることが「 入口 」
14. 「フルスペック・クラウドプラットフォーム」へ 年 抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化 IaaS型クラウド サービス
15. 「フルスペック・クラウドプラットフォーム」へ 年 抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化 IaaS型クラウド サービス ガバメント クラウド技術要件
16. ガバメントクラウド • デジタル庁が整備する、政府全体で共通利 用 するクラウドサービス基盤 • 既存の「パブリッククラウド」を活かし、柔軟迅速にセキュアなシステム基盤の 調達を可能とする • 政府や 自 治体アプリケーション開発を現代的なものとし、国 民 に利便性の 高 い サービスをいち早く提供することにつなげる • ガバメントクラウド対象クラウドサービスはデジタル庁にて認定 • デジタル庁から出ている技術要件を満たす必要がある
17. ガバメントクラウド技術要件 • 17項 目 ／約300件の技術要件を「全て」満たす必要がある • 基本事項、(1)コンピュート（サーバ）機能、(2)ストレージ、(3)データベース、 (4)サーバレス・コンテナ関連機能、(5)API関連機能、(6)アプリケーション連携機能、 (7)データ分析機能、(8)コードリリース機能、(9)ネットワークとCDN、 (10)システム運 用 管理機能、(11)ユーザ管理、(12)バックアップ、 (13)データポータビリティ・移 行支 援機能、(14)セキュリティ機能、 (15)暗号 管理とデータ保管セキュリティ、(16)機械学習関連機能 • ※令和5年度募集の技術要件 • リストは以下のURLから参照可能 https://www.digital.go.jp/procurement/3058bc41-ee8f-49bb-8f22-8def725f6f3f
18. 開発進捗 デジタル庁ウェブサイトで公開される
19. 開発進捗 • 9 月 末時点で80%を超える技術要件を充 足 • デジタル庁からの評価 • 2025年9 月 末時点の進捗状況を確認した結果、体制及び計画の 見 直しが必要とな る開発項 目 があることを確認しましたが、開発計画全体には影響なく、引き続き 進捗状況を注視し確認を 行 っていくこととします。 • 年内の技術要件の充 足 に向けて最 大 のパフォーマンスをもって開発
20. リリースした機能・サービス( 一 部) 機能名 概要 サービス・ウェブサイトの稼働情報 「さくらのクラウド」の各サービスおよび各種サイトの稼働状況を表 示 するサービスです。 AppRun コンテナイメージから簡単にアプリケーションをデプロイし、 自 動的にスケーリングできるマネージドサー ビスです。 シンプルMQ ソフトウェアコンポーネント間でのデータの送受信ができるマネージド型のメッセージキューサービスで す。 シンプル通知 メールや Webhook※1 を利 用 して、簡単に通知を送信できるサービスです。 Webhook は Slack、Discord、Microsoft Teams、IFTTT、および Zapier で利 用 可能です。 EventBus イベント検知サービスとジョブスケジュールサービスを統合したマネージドサービスです。スケジュールト リガーを利 用 して、 自 動的にジョブを実 行 可能となります。 シークレットマネージャ お客さまのシークレット情報を管理・保管するためのサービスです。 KMS （Key Management Service） 暗号 のライフサイクル管理を 行 うためのサービスです。
21. リリースした機能・サービス( 一 部) 機能名 概要 APIゲートウェイ Web API のルーティング / リクエスト･レスポンス変換 / 認証認可を 行 うマネージドサービスです｡ NoSQL パフォーマンスを犠牲にすることなくスケーラビリティと 高 可 用 性を実現した、Apache Cassandra 互換の マネージドデータベースサービスです。 クラウドHSM HSM（Hardware Security Module）※2 のリソースをクラウド上で提供するサービスです。 モニタリングスイート システム監視を 行 うためのプラットフォームです。 「さくらのクラウド」およびその他のクラウド、オンプレミス等の多様な環境を 一 元管理し、可視化するこ とが可能となります。 Work fl ows 「さくらのクラウド」上に、ワークフローを実 行 する基盤を提供するサービスです。 ワークフローを 用 いて、反復実 行 するための特定操作をYAML（YAML Ain ’ t Markup Language）で定義す ることが可能となります。 マイグレーションサービス （移 行 ツール） VMware環境から「さくらのクラウド」への移 行 を効率的に 行 うためのツールです。
22. リリースした機能・サービス( 一 部) • 認証認可(IAM) • SSO連携 • 専有ストレージ • プレミアムサポート（さくらのクラウド） • DNS プライベートホストゾーン • サービスエンドポイントゲートウェイ • PITR(データベース) • 暗号化 BYOK対応 • 高火力 VRT (GPUプラン)
23. 「さくらのクラウド」のアーキテクチャ 2年間で数多くの機能・サービスの開発を実現できた背景
24. 「さくらのクラウド」の アーキテクチャのキーワード
25. 「垂直統合モデル」 「多層アーキテクチャ」
26. 垂直統合・ 自 前主義 • さくらインターネットのビジネスモデルの特徴 • データセンターの所有から開発、運 用 サポートまで 自 社 一 貫で担う • 垂直統合で事業の成 長 と顧客への 提供価値の最 大 化 ͘͞ΒͷϨϙʔτ౷߹ใࠂॻ2025 ͘͞ΒͷϨϙʔτ౷߹ใࠂॻ
    
27. さくらのクラウドの垂直統合モデル ϗετ
    ෺ཧαʔό ωοτϫʔΫ ετϨʔδ データセンター 基盤システム(API, Controller, Database, MQ) 仮想ネットワーク ハイパーバイザ 7. 7. 7. 7. 7. 7. 7. 7. 課 金 システム
28. さくらのクラウドの垂直統合モデル ϗετ
    ෺ཧαʔό ωοτϫʔΫ ετϨʔδ データセンター 基盤システム(API, Controller, Database, MQ) 仮想ネットワーク ハイパーバイザ 7. 7. 7. 7. 7. 7. 7. 7. 課 金 システム Linux + KVM、QEMUを 自 社ソフトウェアで制御
29. さくらのクラウドの垂直統合モデル ϗετ
    ෺ཧαʔό ωοτϫʔΫ ετϨʔδ データセンター 基盤システム(API, Controller, Database, MQ) 仮想ネットワーク ハイパーバイザ 7. 7. 7. 7. 7. 7. 7. 7. 課 金 システム Open vSwitchを制御する ソフトウェアを開発し、 ネットワークを作成制御 Linux + KVM、QEMUを 自 社ソフトウェアで制御
30. さくらのクラウドの垂直統合モデル ϗετ
    ෺ཧαʔό ωοτϫʔΫ ετϨʔδ データセンター 基盤システム(API, Controller, Database, MQ) 仮想ネットワーク ハイパーバイザ 7. 7. 7. 7. 7. 7. 7. 7. 課 金 システム Open vSwitchを制御する ソフトウェアを開発し、 ネットワークを作成制御 Linux + KVM、QEMUを 自 社ソフトウェアで制御 データセンター、 ハードウェアの 自 社運 用
31. さくらのクラウドの垂直統合モデル ϗετ
    ෺ཧαʔό ωοτϫʔΫ ετϨʔδ データセンター 基盤システム(API, Controller, Database, MQ) 仮想ネットワーク ハイパーバイザ 7. 7. 7. 7. 7. 7. 7. 7. 課 金 システム Open vSwitchを制御する ソフトウェアを開発し、 ネットワークを作成制御 Linux + KVM、QEMUを 自 社ソフトウェアで制御 データセンター、 ハードウェアの 自 社運 用 IaaS基盤のコントロール プレーンは 自 社開発・運 用
32. さくらのクラウドの垂直統合モデル • IaaS基盤ソフトウェアの機能や運 用 最適化を 行 い、ビジネスモデルにあった プランの作り込みが可能 • 逆に作り込みが必要とも 言 え、そのコストは 小 さくない • 自 社外の変化に影響されにくい、強靭なサプライチェーン • ライセンス形態の変更やOSSプロジェクトの運営による影響を受けにくい • 変化を起こしていくためのモメンタムを維持しなければならない
33. 多層アーキテクチャ データセンター・仮想ネットワーク・ハイパーバイザ 基盤システム(API, Controller, Database, MQ) 7. 7. 7. 7. "1* 共通サービス 課 金 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 仮想マシン 7. 7. 7. アプライアンス "1* 7. 7. 7. SaaS
34. 多層アーキテクチャ データセンター・仮想ネットワーク・ハイパーバイザ 基盤システム(API, Controller, Database, MQ) 7. 7. 7. 7. "1* 共通サービス 課 金 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 仮想マシン 7. 7. 7. アプライアンス "1* 7. 7. 7. SaaS APIや物理HWの制御など 多数のソフトウェア
35. 多層アーキテクチャ データセンター・仮想ネットワーク・ハイパーバイザ 基盤システム(API, Controller, Database, MQ) 7. 7. 7. 7. "1* 共通サービス 課 金 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 仮想マシン 7. 7. 7. アプライアンス "1* 7. 7. 7. SaaS IaaS基盤上でマネジメント サービスを構築 APIや物理HWの制御など 多数のソフトウェア
36. 多層アーキテクチャ データセンター・仮想ネットワーク・ハイパーバイザ 基盤システム(API, Controller, Database, MQ) 7. 7. 7. 7. "1* 共通サービス 課 金 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 7. 仮想マシン 7. 7. 7. アプライアンス "1* 7. 7. 7. SaaS 「さくらのクラウド」上で 様々なサービスを組み合 わせ、SaaSを構成 IaaS基盤上でマネジメント サービスを構築 APIや物理HWの制御など 多数のソフトウェア
37. さくらのクラウドに含まれる「サービス」 • アプライアンス・サービス • 1台以上のVMにソフトウェアを 自 動構成し、顧客のプライベートネットワークに接続 • ミドルウェア・ソフトウェアの運 用 監視をマネージドで提供する • 例：データベース、VPNルータ、ロードバランサ(アプライアンス) • 共通サービス(グローバルサービス) • 複数台のVM(サービスホスト)にソフトウェアを構成。共有リソースとして顧客に払い出す • 複数のリージョンに分散して可 用 性を担保するサービスもあり • 例：DNS(アプライアンス)、GSLB、エンハンスドロードバランサ、コンテナレジストリ
38. 多層アーキテクチャ例 • IaaS基盤の上にVMがあり、VMの上にアプライアンス、アプライアンスの上に 共通サービス、共通サービスの上に別のサービスが層となり重なっている • 例1: データベースアプライアンスを共通サービスのリソース管理に利 用 • 例2: エンハンスドLBはVIPフェイルオーバー機能DNSを利 用 • ただし、サービス間の依存ループはNG • 依存がループすると障害時に復旧が不可能 • ポリシー、サービスのレイヤーを定め、循環依存を回避
39. 多層アーキテクチャを志向する理由 • プラットフォーム共通化による開発パフォーマンスの向上 • クラウド開発者もクラウドネイティブを意識 • 車 輪の再発明を防ぐ • ドッグフーディングによる品質、機能改善 • チーム間、サービス間でフィードバックループを回す • サービスだけではなくOSSとして開発提供するTerraform Providerも 自 社活 用
40. チーム構造とアーキテクチャの変遷
41. 2023年のさくらのクラウド開発体制 • ガバメントクラウド認定前(2023年)の クラウド開発チーム • ソフトウェア開発で10 人 強 • クラウドの多様なサービス、レイヤーを アメーバ状のチームで担当 • メンバーが少ない、固定される状況では意思疎通 がしやすい • オンボーディング、ノウハウ共有に 長 時間かかる 認知負荷が 高 い
42. “開発 生 産性”へのチャレンジ • ガバメントクラウド認定のためには、短期間で多くの開発を並 行 で 走 らせる 必要。圧倒的に 足 りない開発 生 産性 • 「ガバメントクラウドのための体制」ではなく「ガバメントクラウドを契機 にサービスを改善し続ける体制に」 • チーム、メンバーの変化と成 長 をこの取り組みの最も 大 きな成果としたい
43. チーム分割と担当機能の責任を明 示 • 機能単位でのチーム分割、担当機能にチームで責任を持つ • 技術要件から何をサービスとして開発を 行 うのか、どうつくるのかを責務とする • 4+1チームへの分割 • API開発チーム、データベース・課 金 チーム • コンテナ実 行 基盤チーム、IaaS基盤チーム • テクノロジー室 (監視、SDK、暗号化、共通サービス系)
44. チーム分割と担当機能 データセンター・仮想ネットワーク・ハイパーバイザ 基盤システム(API, IAM) 7. 7. 7. 7. 7. 7. 顧客VM アプライアンス 7. 7. 7. 7. "1* 共通サービス 課 金 Controller, DB, MQ "1* "1* • 4+1チームへの分割 • API開発チーム • データベース・課 金 チーム • コンテナ実 行 基盤チーム • IaaS基盤チーム • テクノロジー室 (共通サービス系)
45. チーム体制の狙い • いわゆる「逆コンウェイ戦略」 • これまでのアメーバ状の組織で作られるサービスは密結合で開発のスループットを 上げることができない • 機能単位、扱う技術でのチーム分割し、開発全体の並列性を改善する • 多層アーキテクチャとうまく合致させ、強化する
46. アーキテクチャ上の課題と変化 • モノリシックなコントロールプレーンの存在 • サービス開始当初から存在し、さくらのクラウドのリソースの多くを制御する基盤 • 多層アーキテクチャもIaaSのコントロールプレーンに最終的に依存してしまう • ハードウェア・ネットワークとも密結合で開発、検証、テストの上でもボトルネック • コントロールプレーンからの機能分割・依存の削減 • IAM(認証認可)を 大 幅に強化するにあたり、コントロールプレーンから認証認可機能を切り出し • 新規サービスの 一 部ではコントロールプレーンに密結合させず、IAM、課 金 システムなどとAPIで 疎に結びつくアーキテクチャの採 用
47. 開発チームの”今” • ソフトウェア開発に関わるメンバーは 10 人 程度から100 人 以上に拡 大 • 2025年度後半に 入 り、毎 月 のリリースが 当初の3-4倍 行 えるように 大 きく変化・成 長
48. 変化と信頼性とプロダクト
49. 2026年度以降のさくらのクラウドの開発 • 2025年度末でガバメントクラウド技術要件を満たす開発は区切られる • 技術要件を満たしたからといって、顧客の課題を解決できるクラウドプラッ トフォームになれるわけではない • 技術要件はスタートラインに 立 つため • 機能の 高 度化に加え、 非 機能要件・信頼性がより重要となる
50. 提供価値に基づいた体制 • 機能サービス・利 用 技術だけではなく、提供価値・責務に基づいたチームの 編成・ロール明 示 を検討 • ユーザ価値の最 大 化と顧客視点のサービス開発部 門 • サービス提供に共通して必要とされる実 行 基盤と インフラ開発のプラットフォーム部 門 • 組織全体の技術的整合性、品質の観点から技術的な意思決定の 支 援を 行 う部 門 • アーキテクチャへも影響させていく (逆コンウェイ戦略)
51. サービスは”誰か”のプラットフォームとなる • 要件を満たす機能の提供から提供価値にチームの 目 線を変化させたい • 社内外問わず、チームが提供しているサービスの利 用 者はそのサービスを 用 いて新しい価値を 生 み出す • 利 用 者の 行 動にポジティブな影響を与えるプラットフォームを 全チームが志向する
52. メンタルモデル、アーキテクチャ、責務を明確にして揃える
53. ミルクレープはどこから 食 べても美味しい
54. 提供価値に基づいた体制への期待 • スケーラビリティ・ポータビリティの獲得 • 様々なデプロイメントの要望に応えるアーキテクチャの実現 • サービスと顧客の課題を解決できるスケーラビリティ • 変化と変化を 支 える信頼性の獲得 • 価値を 生 み続けるためサービスを変化し続ける • 変化と 高 い信頼性の両 立
55. 非 機能要件・信頼性に向けて • 社会からの期待を背景に信頼性がこれまでとは異なるレベルで求められる • 顧客の課題解決を継続的に担い続けるためサービスを変化し続ける • チャレンジを継続的に 行 い、チームもプロダクトも成 長 していかなければ ならない。SREはそれを 支 えるプラクティス • “You buid it, you run it.” • 運 用 できないソフトウェアは作らない
56. まとめ
57. まとめ • 国産クラウド「さくらのクラウド」とは • ガバメントクラウドの取り組みの現在地 • 国産クラウド「さくらのクラウド」のアーキテクチャ • チーム構造とアーキテクチャの変遷 • 変化と信頼性とプロダクト
58. まとめ • リリースから15年 目 に 入 ったさくらのクラウドは 大 きく進化していきます • 顧客価値ファーストに根差した組織、サービス開発を志向していきます • 国産クラウドの開発にこれからも注 目 をいただけると幸いです
59. EoS.