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

by kazeburo

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Me • 長野雅広(ながのまさひろ) • @kazeburo (X, GitHub, mixi2) • さくらインターネット株式会社クラウド事業本部副本部長テクノロジー室(旧SRE室)ファウンダー • mixi、livedoor (現 LINEヤフー) 、 mercariを経て2021年から現職コロナ禍でランニングをやりはじめ、ハーフマラソン・フルマラソンにも挑戦してます

Slide 3

Slide 3 text

Agenda • 国産クラウド「さくらのクラウド」とは • ガバメントクラウドの取り組みの現在地 • 国産クラウド「さくらのクラウド」のアーキテクチャ • チーム構造とアーキテクチャの変遷 • 変化と信頼性とプロダクト

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

“さくらのクラウド” • 2011年11 月 15 日 IaaS型クラウドとしてサービス開始 • 15年目に入りました • 仮想サーバ、ストレージ、ネットワークを中心とするIaaS型クラウドとして提供開始 • DNS、仮想ルータ、ロードバランサ、RDBMSなどマネージメントサービスも順次展開 • 特徴 • ソブリニティ（データ主権、技術主権、運営主権） • わかりやすい料金体系(データ転送量による従量課金なし、為替の影響を受けない)

Slide 6

Slide 6 text

“さくらのクラウド” • リージョンは東京と北海道” 石狩”の2拠点 • ゾーンは東京2ゾーン、石狩3ゾーン • 各ゾーンを閉域網で接続、オンプレミスや他社CSPとも接続できるネットワークサービスも展開

Slide 7

Slide 7 text

ガバメントクラウド認定* • 2023年「ガバメントクラウド整備のためのクラウドサービス」に認定* • 国産クラウドとしては唯一の認定 • 2025年度末までに”技術要件”を全て満たすことを前提に認定 • ガバメントクラウド認定の狙い • クラウド最適化、モダンなアプリケーション開発というデジタル庁の狙いはさくらインターネットの中長期の取組みとも合致 • IaaS型のクラウドから、フルスペックのクラウドプラットフォームとして進化させ、モダンなクラウドサービスに適合する

Slide 8

Slide 8 text

クラウドサービスの進化年抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化

Slide 9

Slide 9 text

クラウドサービスの進化とITシステムの変化 • クラウドの進化を前提にITシステムのアーキテクチャは大きく変化 • インフラ基盤の抽象化により、具体的な課題の解決にフォーカス • 高いレベルのサービス統合によるITシステムの統制の実現 • 宣言的なアプローチ • 生成AIの普及によって支援が得られやすい上記のようなアーキテクチャの選択機会がさらに増加、加速する

Slide 10

Slide 10 text

「IaaS型クラウドサービス」の立ち位置年抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化

Slide 11

Slide 11 text

「IaaS型クラウドサービス」の立ち位置年抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化 IaaS型クラウドサービス

Slide 12

Slide 12 text

Slide 13

Slide 13 text

「フルスペック・クラウドプラットフォーム」へ • さくらのクラウドは、クラウドを前提としたアーキテクチャに必要な主要コンポーネントを揃えるフルスペックのクラウドプラットフォームを目指す • 濃淡はあれど、抽象度/統合度の高いサービスへ移行は間違いなく進む • これまでのサービス、やり方では広い顧客の課題を解決することができない • ガバメントクラウドの技術要件はクラウドでITシステムを作る上での必要な機能のサブセットをうまく選択している • 技術要件を満たし、正式な認定を得ることが「入口」

Slide 14

Slide 14 text

「フルスペック・クラウドプラットフォーム」へ年抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化 IaaS型クラウドサービス

Slide 15

Slide 15 text

「フルスペック・クラウドプラットフォーム」へ年抽象度/統合度 2006 2010 2015 2020 2025 IaaS(仮想サーバ) マネージドサービス(DB) コンテナ/Kubernetes サーバレス AI/機械学習 SaaS・業界特化 IaaS型クラウドサービスガバメントクラウド技術要件

Slide 16

Slide 16 text

ガバメントクラウド • デジタル庁が整備する、政府全体で共通利用するクラウドサービス基盤 • 既存の「パブリッククラウド」を活かし、柔軟迅速にセキュアなシステム基盤の調達を可能とする • 政府や自治体アプリケーション開発を現代的なものとし、国民に利便性の高いサービスをいち早く提供することにつなげる • ガバメントクラウド対象クラウドサービスはデジタル庁にて認定 • デジタル庁から出ている技術要件を満たす必要がある

Slide 17

Slide 17 text

ガバメントクラウド技術要件 • 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

Slide 18

Slide 18 text

開発進捗デジタル庁ウェブサイトで公開される

Slide 19

Slide 19 text

開発進捗 • 9 月末時点で80%を超える技術要件を充足 • デジタル庁からの評価 • 2025年9 月末時点の進捗状況を確認した結果、体制及び計画の見直しが必要となる開発項目があることを確認しましたが、開発計画全体には影響なく、引き続き進捗状況を注視し確認を行っていくこととします。 • 年内の技術要件の充足に向けて最大のパフォーマンスをもって開発

Slide 20

Slide 20 text

リリースした機能・サービス( 一部) 機能名概要サービス・ウェブサイトの稼働情報「さくらのクラウド」の各サービスおよび各種サイトの稼働状況を表示するサービスです。 AppRun コンテナイメージから簡単にアプリケーションをデプロイし、自動的にスケーリングできるマネージドサービスです。シンプルMQ ソフトウェアコンポーネント間でのデータの送受信ができるマネージド型のメッセージキューサービスです。シンプル通知メールや Webhook※1 を利用して、簡単に通知を送信できるサービスです。 Webhook は Slack、Discord、Microsoft Teams、IFTTT、および Zapier で利用可能です。 EventBus イベント検知サービスとジョブスケジュールサービスを統合したマネージドサービスです。スケジュールトリガーを利用して、自動的にジョブを実行可能となります。シークレットマネージャお客さまのシークレット情報を管理・保管するためのサービスです。 KMS （Key Management Service）暗号のライフサイクル管理を行うためのサービスです。

Slide 21

Slide 21 text

リリースした機能・サービス( 一部) 機能名概要 APIゲートウェイ Web API のルーティング / リクエスト･レスポンス変換 / 認証認可を行うマネージドサービスです｡ NoSQL パフォーマンスを犠牲にすることなくスケーラビリティと高可用性を実現した、Apache Cassandra 互換のマネージドデータベースサービスです。クラウドHSM HSM（Hardware Security Module）※2 のリソースをクラウド上で提供するサービスです。モニタリングスイートシステム監視を行うためのプラットフォームです。「さくらのクラウド」およびその他のクラウド、オンプレミス等の多様な環境を一元管理し、可視化することが可能となります。 Work fl ows 「さくらのクラウド」上に、ワークフローを実行する基盤を提供するサービスです。ワークフローを用いて、反復実行するための特定操作をYAML（YAML Ain ’ t Markup Language）で定義することが可能となります。マイグレーションサービス（移行ツール） VMware環境から「さくらのクラウド」への移行を効率的に行うためのツールです。

Slide 22

Slide 22 text

リリースした機能・サービス( 一部) • 認証認可(IAM) • SSO連携 • 専有ストレージ • プレミアムサポート（さくらのクラウド） • DNS プライベートホストゾーン • サービスエンドポイントゲートウェイ • PITR(データベース) • 暗号化 BYOK対応 • 高火力 VRT (GPUプラン)

Slide 23

Slide 23 text

「さくらのクラウド」のアーキテクチャ 2年間で数多くの機能・サービスの開発を実現できた背景

Slide 24

Slide 24 text

「さくらのクラウド」のアーキテクチャのキーワード

Slide 25

Slide 25 text

「垂直統合モデル」「多層アーキテクチャ」

Slide 26

Slide 26 text

垂直統合・自前主義 • さくらインターネットのビジネスモデルの特徴 • データセンターの所有から開発、運用サポートまで自社一貫で担う • 垂直統合で事業の成長と顧客への提供価値の最大化 ͘͞ΒͷϨϙʔτ౷߹ใࠂॻ2025 ͘͞ΒͷϨϙʔτ౷߹ใࠂॻ

Slide 27

Slide 27 text

さくらのクラウドの垂直統合モデル ϗετ ෺ཧαʔό ωοτϫʔΫ ετϨʔδ データセンター基盤システム(API, Controller, Database, MQ) 仮想ネットワークハイパーバイザ 7. 7. 7. 7. 7. 7. 7. 7. 課金システム

Slide 28

Slide 28 text

さくらのクラウドの垂直統合モデル ϗετ ෺ཧαʔό ωοτϫʔΫ ετϨʔδ データセンター基盤システム(API, Controller, Database, MQ) 仮想ネットワークハイパーバイザ 7. 7. 7. 7. 7. 7. 7. 7. 課金システム Linux + KVM、QEMUを自社ソフトウェアで制御

Slide 29

Slide 29 text

さくらのクラウドの垂直統合モデル ϗετ ෺ཧαʔό ωοτϫʔΫ ετϨʔδ データセンター基盤システム(API, Controller, Database, MQ) 仮想ネットワークハイパーバイザ 7. 7. 7. 7. 7. 7. 7. 7. 課金システム Open vSwitchを制御するソフトウェアを開発し、ネットワークを作成制御 Linux + KVM、QEMUを自社ソフトウェアで制御

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

さくらのクラウドの垂直統合モデル • IaaS基盤ソフトウェアの機能や運用最適化を行い、ビジネスモデルにあったプランの作り込みが可能 • 逆に作り込みが必要とも言え、そのコストは小さくない • 自社外の変化に影響されにくい、強靭なサプライチェーン • ライセンス形態の変更やOSSプロジェクトの運営による影響を受けにくい • 変化を起こしていくためのモメンタムを維持しなければならない

Slide 33

Slide 33 text

多層アーキテクチャデータセンター・仮想ネットワーク・ハイパーバイザ基盤システム(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

Slide 34

Slide 34 text

多層アーキテクチャデータセンター・仮想ネットワーク・ハイパーバイザ基盤システム(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の制御など多数のソフトウェア

Slide 35

Slide 35 text

多層アーキテクチャデータセンター・仮想ネットワーク・ハイパーバイザ基盤システム(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の制御など多数のソフトウェア

Slide 36

Slide 36 text

多層アーキテクチャデータセンター・仮想ネットワーク・ハイパーバイザ基盤システム(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の制御など多数のソフトウェア

Slide 37

Slide 37 text

さくらのクラウドに含まれる「サービス」 • アプライアンス・サービス • 1台以上のVMにソフトウェアを自動構成し、顧客のプライベートネットワークに接続 • ミドルウェア・ソフトウェアの運用監視をマネージドで提供する • 例：データベース、VPNルータ、ロードバランサ(アプライアンス) • 共通サービス(グローバルサービス) • 複数台のVM(サービスホスト)にソフトウェアを構成。共有リソースとして顧客に払い出す • 複数のリージョンに分散して可用性を担保するサービスもあり • 例：DNS(アプライアンス)、GSLB、エンハンスドロードバランサ、コンテナレジストリ

Slide 38

Slide 38 text

多層アーキテクチャ例 • IaaS基盤の上にVMがあり、VMの上にアプライアンス、アプライアンスの上に共通サービス、共通サービスの上に別のサービスが層となり重なっている • 例1: データベースアプライアンスを共通サービスのリソース管理に利用 • 例2: エンハンスドLBはVIPフェイルオーバー機能DNSを利用 • ただし、サービス間の依存ループはNG • 依存がループすると障害時に復旧が不可能 • ポリシー、サービスのレイヤーを定め、循環依存を回避

Slide 39

Slide 39 text

多層アーキテクチャを志向する理由 • プラットフォーム共通化による開発パフォーマンスの向上 • クラウド開発者もクラウドネイティブを意識 • 車輪の再発明を防ぐ • ドッグフーディングによる品質、機能改善 • チーム間、サービス間でフィードバックループを回す • サービスだけではなくOSSとして開発提供するTerraform Providerも自社活用

Slide 40

Slide 40 text

チーム構造とアーキテクチャの変遷

Slide 41

Slide 41 text

2023年のさくらのクラウド開発体制 • ガバメントクラウド認定前(2023年)のクラウド開発チーム • ソフトウェア開発で10 人強 • クラウドの多様なサービス、レイヤーをアメーバ状のチームで担当 • メンバーが少ない、固定される状況では意思疎通がしやすい • オンボーディング、ノウハウ共有に長時間かかる認知負荷が高い

Slide 42

Slide 42 text

“開発生産性”へのチャレンジ • ガバメントクラウド認定のためには、短期間で多くの開発を並行で走らせる必要。圧倒的に足りない開発生産性 • 「ガバメントクラウドのための体制」ではなく「ガバメントクラウドを契機にサービスを改善し続ける体制に」 • チーム、メンバーの変化と成長をこの取り組みの最も大きな成果としたい

Slide 43

Slide 43 text

チーム分割と担当機能の責任を明示 • 機能単位でのチーム分割、担当機能にチームで責任を持つ • 技術要件から何をサービスとして開発を行うのか、どうつくるのかを責務とする • 4+1チームへの分割 • API開発チーム、データベース・課金チーム • コンテナ実行基盤チーム、IaaS基盤チーム • テクノロジー室 (監視、SDK、暗号化、共通サービス系)

Slide 44

Slide 44 text

チーム分割と担当機能データセンター・仮想ネットワーク・ハイパーバイザ基盤システム(API, IAM) 7. 7. 7. 7. 7. 7. 顧客VM アプライアンス 7. 7. 7. 7. "1* 共通サービス課金 Controller, DB, MQ "1* "1* • 4+1チームへの分割 • API開発チーム • データベース・課金チーム • コンテナ実行基盤チーム • IaaS基盤チーム • テクノロジー室 (共通サービス系)

Slide 45

Slide 45 text

チーム体制の狙い • いわゆる「逆コンウェイ戦略」 • これまでのアメーバ状の組織で作られるサービスは密結合で開発のスループットを上げることができない • 機能単位、扱う技術でのチーム分割し、開発全体の並列性を改善する • 多層アーキテクチャとうまく合致させ、強化する

Slide 46

Slide 46 text

アーキテクチャ上の課題と変化 • モノリシックなコントロールプレーンの存在 • サービス開始当初から存在し、さくらのクラウドのリソースの多くを制御する基盤 • 多層アーキテクチャもIaaSのコントロールプレーンに最終的に依存してしまう • ハードウェア・ネットワークとも密結合で開発、検証、テストの上でもボトルネック • コントロールプレーンからの機能分割・依存の削減 • IAM(認証認可)を大幅に強化するにあたり、コントロールプレーンから認証認可機能を切り出し • 新規サービスの一部ではコントロールプレーンに密結合させず、IAM、課金システムなどとAPIで疎に結びつくアーキテクチャの採用

Slide 47

Slide 47 text

開発チームの”今” • ソフトウェア開発に関わるメンバーは 10 人程度から100 人以上に拡大 • 2025年度後半に入り、毎月のリリースが当初の3-4倍行えるように大きく変化・成長

Slide 48

Slide 48 text

変化と信頼性とプロダクト

Slide 49

Slide 49 text

2026年度以降のさくらのクラウドの開発 • 2025年度末でガバメントクラウド技術要件を満たす開発は区切られる • 技術要件を満たしたからといって、顧客の課題を解決できるクラウドプラットフォームになれるわけではない • 技術要件はスタートラインに立つため • 機能の高度化に加え、非機能要件・信頼性がより重要となる

Slide 50

Slide 50 text

提供価値に基づいた体制 • 機能サービス・利用技術だけではなく、提供価値・責務に基づいたチームの編成・ロール明示を検討 • ユーザ価値の最大化と顧客視点のサービス開発部門 • サービス提供に共通して必要とされる実行基盤とインフラ開発のプラットフォーム部門 • 組織全体の技術的整合性、品質の観点から技術的な意思決定の支援を行う部門 • アーキテクチャへも影響させていく (逆コンウェイ戦略)

Slide 51

Slide 51 text

サービスは”誰か”のプラットフォームとなる • 要件を満たす機能の提供から提供価値にチームの目線を変化させたい • 社内外問わず、チームが提供しているサービスの利用者はそのサービスを用いて新しい価値を生み出す • 利用者の行動にポジティブな影響を与えるプラットフォームを全チームが志向する

Slide 52

Slide 52 text

メンタルモデル、アーキテクチャ、責務を明確にして揃える

Slide 53

Slide 53 text

ミルクレープはどこから食べても美味しい

Slide 54

Slide 54 text

提供価値に基づいた体制への期待 • スケーラビリティ・ポータビリティの獲得 • 様々なデプロイメントの要望に応えるアーキテクチャの実現 • サービスと顧客の課題を解決できるスケーラビリティ • 変化と変化を支える信頼性の獲得 • 価値を生み続けるためサービスを変化し続ける • 変化と高い信頼性の両立

Slide 55

Slide 55 text

非機能要件・信頼性に向けて • 社会からの期待を背景に信頼性がこれまでとは異なるレベルで求められる • 顧客の課題解決を継続的に担い続けるためサービスを変化し続ける • チャレンジを継続的に行い、チームもプロダクトも成長していかなければならない。SREはそれを支えるプラクティス • “You buid it, you run it.” • 運用できないソフトウェアは作らない

Slide 56

Slide 56 text

まとめ

Slide 57

Slide 57 text

まとめ • 国産クラウド「さくらのクラウド」とは • ガバメントクラウドの取り組みの現在地 • 国産クラウド「さくらのクラウド」のアーキテクチャ • チーム構造とアーキテクチャの変遷 • 変化と信頼性とプロダクト

Slide 58

Slide 58 text

まとめ • リリースから15年目に入ったさくらのクラウドは大きく進化していきます • 顧客価値ファーストに根差した組織、サービス開発を志向していきます • 国産クラウドの開発にこれからも注目をいただけると幸いです

Slide 59

Slide 59 text

EoS.