[SRE kaigi 2025] ガバメントクラウドに向けた開発と変化するSRE組織のあり方 / Development for Government Cloud and the Evolving Role of SRE Teams

Transcript

1. SAKURA internet Inc. Masahiro Nagano @kazeburo ガバメントクラウドに向けた開発と 変化するSRE組織のあり 方 SRE Kaigi 2025/01/26
2. Me • 長 野雅広 (ながのまさひろ) • @kazeburo X(Twitter) & GitHub • さくらインターネット株式会社 クラウド事業本部 副本部 長 ／SRE室 室 長 • mixi, livedoor(LINE), mercari を経て 2021年から現職 東京ニューイヤーハーフマラソンで 走 りました
3. Me • 2006年 mixiに転職した時点か らデータセンターに 行 かない 「Webアプリケーション運 用 エ ンジニア」 • 2015年11 月 にメルカリにてSRE チームを 立 ち上げ • 日 本におけるSREのはしり
4. 本 日 のアジェンダ • さくらインターネットではクラウドサービスプロバイダ(CSP)として 自 社パブリッ ククラウドをガバメントクラウドの多数の技術要件に適合させるプロジェクトを進 めています。この発表では 大 きなチャレンジをする開発組織におけるSREの 一 つの 事例としてお話しします • アジェンダ • ガバメントクラウドとは何か、さくらインターネットの取り組み • さくらインターネット SRE室のあり 方 とその変化 • チャレンジする組織にとってのSREとは
5. ガバメントクラウド • デジタル庁が整備する、政府全体で共通利 用 するクラウドサービス基盤 • 既存の「パブリッククラウド」を活かし、柔軟迅速にセキュアなシステム基盤の 調達を可能とする • 政府や 自 治体アプリケーション開発を現代的なものとし、国 民 に利便性の 高 い サービスをいち早く提供することにつなげる • ガバメントクラウド対象クラウドサービスはデジタル庁にて認定 • デジタル庁から出ている技術要件を満たす必要がある
6. ガバメントクラウド技術要件 • 令和5年度募集の技術要件 • 17項 目 ／約300件の技術要件を「全て」満たす必要がある • 基本事項、(1)コンピュート（サーバ）機能、(2)ストレージ、(3)データベース、 (4)サーバレス・コンテナ関連機能、(5)API関連機能、(6)アプリケーション連携機能、 (7)データ分析機能、(8)コードリリース機能、(9)ネットワークとCDN、 (10)システム運 用 管理機能、(11)ユーザ管理、(12)バックアップ、 (13)データポータビリティ・移 行 支 援機能、(14)セキュリティ機能、 (15)暗号 管理とデータ保管セキュリティ、(16)機械学習関連機能 • 要件のリストは以下のURLから参照可能 https://www.digital.go.jp/procurement/3058bc41-ee8f-49bb-8f22-8def725f6f3f
7. ガバメントクラウド技術要件 基本事項からいくつか抜粋 大 項 目 項 目 項番 要件 基本事項 サービス全般 1 外部からネットワーク経由で提供される情報処理サービスであり、コンピュータや通信ネ ットワーク等の情報処理基盤を意識することなく、情報通信技術の便益やアプリケーショ ンを享受可能にし、サービスの利 用 結果が契約主体及び利 用 主体に定量的に明 示 できるこ と。 基本事項 サービス全般 3 災害時等において、公的に必要なサービスを優先する機能を有すること。 基本事項 サービス全般 4 いわゆるCOTS（commercial off-the-shelf）として広く提供されているサービスであ り、個別に開発されたものではないこと。 基本事項 サービス全般 7 技術的および物理的に共有されたところがなく完全に分離された複数のデータセンター 区画で「ゾーン」を構成し、冗 長 化を確保すること。 基本事項 サービス全般 10 情報資産はユーザが指 示 しない限り 日 本国内に保管されること。 基本事項 実績 15 日 本国内のデータセンターで当該クラウドサービスを 自 らが３年以上運営しているこ と。 基本事項 マネージドサービス 25 全てのマネージドサービスは、監視やログ管理等の運 用 系マネージドサービスと最初か ら連携しており、設定の詳細な操作ログや監視メトリクスが取得可能であること。
8. ガバメントクラウド技術要件 データベース関連から抜粋 大 項 目 項 目 項番 要件 データベース RDB 4 RDBとしては、MySQL、PostgreSQL及びそれらの互換DBを選択でき、それらの基本機 能がマネージドサービスとして提供されること。 データベース RDB 12 いつでも 一 時停 止 でき、いつでも再起動できること。また、停 止 中は課 金 されない（デ ータ領域の課 金 は除く）データベースを提供可能なこと。 データベース RDB 16 DBでクラスター構成を組む際は技術的および物理的に別の区画（基本事項７で定義する 区画）を指定できること（例：CPUユニットや電源ユニットについて別のハードウェア やラックを指定できる）。 データベース RDB 17 DBはデータを同期させたクラスター構成を組むことができ、アクティブ側の障害時は 自 動的にスタンバイ側にフェイルオーバーすること。アクティブとスタンバイは物理的に別 の場所を指定できること。 バックアップ RDB 7 DBのバックアップは、 一 定期間（例：5分）以前のどの時点にでも戻せるかたちで （Point In Timer Restore）取得できること。 データベース RDB 9 DBのバックアップイメージは、CSPの中であれば、別のシステム、別のネットワーク、 別の環境からも利 用 できること。
9. ガバメントクラウド技術要件 システム運 用 管理機能から抜粋 大 項 目 項 目 項番 要件 システム運 用 管理機能 モニタリング機能 1 クラウドで利 用 する、各種サービスのリソース状況をモニタリングできる機能がマネージ ドサービスとして提供されていること。 システム運 用 管理機能 モニタリング機能 2 モニタリング機能は、コンピュートをはじめとする全てのクラウドリソースのメトリクス の取得と可視化ができること。 システム運 用 管理機能 モニタリング機能 4 モニタリング機能は、ビルトインのメトリクスの他に、独 自 のカスタムメトリクスを定義 し、 一 元的に管理できること。 システム運 用 管理機能 モニタリング機能 5 モニタリング機能は、ログの収集、分析、アラートの設定ができること。 システム運 用 管理機能 モニタリング機能 7 モニタリング機能は、ダッシュボードの作成機能を備えており、ビジュアライズできるこ と。 システム運 用 管理機能 モニタリング機能 18 最初にリリースされる時点から、すべてのサービスにおいて監視マネージドサービスでサ ービスの監視ができること。
10. ガバメントクラウド技術要件 その他抜粋 大 項 目 項 目 項番 要件 コンピュート (サーバ)機能 コンピュート基本 14 OSは、Redhat Enterprise Linuxを含む複数のサポートのあるLinuxディストリビューショ ンと、無料のLinuxディストリビューション、およびWindows Serverから選択できるこ と。 コンピュート (サーバ)機能 負荷分散 2 インターネットからのリクエストを登録されているインスタンスに負荷分散する機能を利 用 できること。 コンピュート (サーバ)機能 機密コンピューティ ング環境 4 クラウド利 用 者からは完全に分離し暗号化された仮想マシンでデータの暗号化/復号が 行 えるサービスまたはサポートが提供されていること。 ストレージ オブジェクト ストレージ 5 オブジェクトストレージは、99.999999999%以上のデータ耐久性を持ち、ファイルの 永続的な保管ができること。そのための仕組みを備えること。かつ 大 規模災害対策の観 点で複数リージョン間でのレプリケーションが利 用 可能であること。 ネットワーク CDN 18 CDNサービスはグローバル10拠点以上で利 用 できること。
11. さくらインターネットがガバメントクラウドに参 入 する意義 • 外部環境の変化 • 経済安全保障の確保の観点から「クラウド」のサプライチェーン強化およびデータ 主権の重要性がうたわれ、国家戦略として国産クラウドベンダーが求められる • 急激な為替変化、デジタル貿易 赤 字 • 社会からの期待と 自 社の戦略が 一 致 • ガバメントクラウドへの参 入 により、政府だけではなく、企業を含む より多くお客様の利便性の向上 • クラウドサービスの技術 水 準、開発体制の強化
12. 開発体制 • 豊かなバックグラウンドを持つエンジニアが集結 • 新卒としてさくらインターネットに 入 職し、クラウドの開発をリードするメンバー • クラウドサービスプロバイダ、メガベンチャー、スタートアップから多数 • 開発組織の変化と成 長 • 技術に真 に向き合い「保守」を 行 なってきた 文 化に「変化」が加わる • 急激な組織の成 長 を 支 えるためエンジニアリングマネージャの体制も並 行 で構築
13. バックエンドチーム(2023.11) 15 人 IaaS Billing VPS Tellus さくらのクラウド さくらのクラウド バックエンドチーム クラウド基盤 構築運 用 基盤ユニット
14. 進化するチーム • ガバメントクラウドの技術要件をベースに、オンボーディングや 認知負荷の低減を 目 的にチームを分割 • ひとりひとり、1チームが担当する技術領域を限定する • チームメンバーは5〜10名程度としてコミュニケーションコストを低く抑える • オーナー、テックリードなど役割、ロールの明 示 • アメーバ状な兼務、依存の解消 • 並列で開発を進めることができる
15. バックエンドチーム(現在) α β γ θ IaaS Core Container ObjectStorage RDS Billing API/IAM SRE室 NFV Monitoring 技術開発G Con fi dential Computing VPS Tellus バックエンドチーム 開発組織 支 援 EMチーム クラウド基盤 構築運 用 基盤ユニット
16. 開発の主なトピック αチーム(API) 認証認可を 行 うAPI(IAM)のシステム刷新 Python/DjangoでAPIを構築し、既存コン トロールプレーンから処理を委譲するアー キテクチャの採 用 γチーム コンテナ化されたアプリケーションをワン ステップでにデプロイし 、 自 動的にスケー ルリングする「さくらのAppRun」をβリ リース 基盤にKubernetesとKnativeを採 用 SRE室 マネージドサービス等のログを集約し、検 索、分析できるモニタリング基盤を Apache IceburgおよびApache Trinoを活 用 し構築。メトリクスの収集、可視化サー ビスも開発中 Θチーム IaaS基盤のGo 言 語へのリプレースを段階的に進めている 信頼性、スケーラビリティの向上と共に、オブザーバビリテ ィ の改善も 行 っている ガバメントの技術要件にはあたらない。クラウド基盤の継続的な改善も同時に進める
19. SRE室のあり 方 とその変化
20. SRE室 • さくらインターネット クラウド事業本部 SRE室 • クラウド事業本部の範囲 • VPS、さくらのクラウド、専 用 サーバPHY / サポート、ネットワーク、データセンター • 2022年7 月 に 立 ち上げ。 立 ち上げ時メンバー3 人 • 2025年1 月 現在、メンバーは9 人 • 東京 支 社所属 5 人 、 大 阪本社所属 3 人 、福岡オフィス所属 1 人 でフルリモート
21. なぜSRE室 • さくらのクラウドの 大 規模な障害をきっかけとして設 立 を提案 • オブザーバビリテ ィ 、ポストモーテムの取り組みがより評価される 文 化を作る • 各部署、各メンバーにてDevOps/SREの取り組みはされており、それを交換するも のではなく、強化することが狙い • 社内での期待値のズレをなくすのが最初の課題 • 「 自 動化をやってくれるチーム？」「何してくれるの？」の声 • 発 足 と同時に Mission、 Vision、Valueを策定し、全社に共有
22. SRE室のMission、Vision、Value • Mission • クラウドサービスの信頼性を 高 めることにより、お客様や社会のDXをしっかり 支 える • Vision • 社内でのSREの実践を広め、お客様への価値提供を 行 う • さくらのサービスそのものの信頼性向上、それにより価値向上を 目 指す • さくら社員がEnabling SREとして、お客様・社外のサービスの信頼性向上に携わる
23. SRE室のMission、Vision、Value • Value • 決め事をつくるのではなく、 一 緒に” 手 を動かして”信頼性向上の 文 化をつくる • SRE室のエンジニアだけがSREsではない • SRE室のエンジニアがEmbedded SRE / Enabling SREとしてSREの取り組みを拡 大 させていく • 開発・運 用 チームとの密なコミュニケーション • 期待値にズレ、お 見 合いを防ぐ • You build it, you run it • 開発/運 用 の両者が共通のゴールをもって、運 用 性に優れたソフトウェアを開発する
24. SRE室の業務(当初) • SRE as a Service • Kubernetes基盤の開発 • Enabling SRE • ポストモーテムの導 入 • SLI/SLOの活 用 • さくらのクラウドの機能開発 • ロードバランサ、VPCルータ、DNSアプライアンス
25. 成果と期待とのギャップ • SRE室の機能開発「では」サービスの安定化で 一 定の成果 • DNSへの 水 責め対策 • オブザーバビリテ ィ 強化 • 開発チームのSREの実践に進めない • SRE as a Serviceの開発はするものの利 用 拡 大 に課題
26. ボトルネックを探す • 各開発、運 用 チームとの協働 (Valueに 立 ち戻る) • 各サービスの担当エンジニアとの密なコミュニケーション、 一 緒に 手 を動かす • ミーティングに参加、課題となっているタスクを共同で 行 う • 新規サービス開発にクラウドサービスを利 用 する「ドックフーディング」により、 サービスの課題を 自 分事に
27. 見 えてきた課題 • チームではなく「個 人 」の集まりの 色 合いが強い • オブザーバビリテ ィ 、ポストモーテム、データが有効に活 用 できる 「チーム」を作る必要 • 顧客に向き合う「アジャイル 文 化」、新しい機能を継続してリリースする「開発 生 産性」向上に取り組む • SRE室の領域を積極的に広げる
28. チームビルディング 支 援 • 一 定の利 用 があるプロダクトを抱えているが、チケットへの返答やオペミス が重なっているチームに対して、SRE室が「チームビルディング」を 支 援 • チームに 入 り、チームメンバーとの雑談会を通して課題の把握 • 朝会、定例を 行 いコミュニケーション経路の確保 • 特定の個 人 によらないissueの解決、障害対応 • Blamelessなふりかえり
29. 「開発 生 産性」を学ぶ • 「LeanとDevOpsの科学」から読書会の開催 • 開発チームのリーダーとSRE室メンバーで開催 • 読書会から得られた価値 • 言 葉( 言 語)の共通化と課題の明確化 • Four Keys、チームトポロジー • メンバー同 士 の相互理解・信頼感の醸成
30. SRE室の業務の拡 大 • SRE as a Service • Kubernetes基盤の開発、モニタリング基盤 • CI/CD基盤 • チームビルディング・Enabling SRE • ポストモーテムの導 入 • アジャイルカルチャーの 支 援（チームビルディング、開発 生 産性向上） • さくらのクラウドの機能開発 • ロードバランサ、VPCルータ、DNSアプライアンス • OSS(usacloud, Terraform Provider)の開発 NEW NEW NEW NEW
31. ガバメントクラウド本認定に向けて • 2023年11 月 、「2025年度末までに技術要件を全て満たすことに前提に」 ガバメントクラウドの認定取得 • 開発 生 産性のさらなる向上、多数のサービスを並 行 並列で開発する必要 • 締切のある開発、開発の可視化 • SRE室でも新しい機能開発を 行 う • 一 部外部の会社との協業があり、開発 支 援 • 絶対数としての開発者不 足 。エンジニア採 用 が急務に
32. バックエンドエンジニア採 用 支 援 • 各開発チームのリーダーの負荷低減 • 業務負荷が 高 いと候補者と「会わない」選択をしがちと推測 • どれだけ候補者の 方 と会うことできるかが採 用 に結びつく • バックエンドのソフトウェアエンジニアの採 用 においては、 書類選考から１次 面 接までSRE室のメンバーが 行 う • マネジメントのボトルネック化はすぐに顕在化することが予想でき、 EMの採 用 も同時並 行 で進 行
33. 開発状況の可視化 • 定期的にデジタル庁に開発の進捗についての報告を 行 う必要 • 担当エンジニアの「感覚」ではない、説明ができる進捗が求められる • Notionにてタスクのリスト化と簡易な 見 積もりをデータベース化 • タスクリストの管理 方 法の策定から各チームへの説明と協 力 の依頼
34. SRE室の業務の再拡 大 • SRE as a Service • Kubernetes基盤の開発 • CI/CD基盤、IaC 支 援 • エンジニア採 用 （新卒・中途） • チームビルディング・Enabling SRE • ポストモーテムの導 入 • アジャイルカルチャーの 支 援（チームビルディング、開発 生 産性、可視化） • さくらのクラウドの機能開発・ガバメントクラウド認定に向けた開発 • ロードバランサ、VPCルータ、DNSアプライアンス、モニタリングサービス • ガバメントクラウド機能：メッセージキュー、イベントルーティング、協 力 会社 支 援 • OSS(usacloud, Terraform Provider)の開発 NEW NEW NEW NEW
35. SRE室メンバー増加 • それぞれ異なるバックグラウンドをもったメンバーが集まる • 主にWebサービスの開発をおこなってきたソフトウェアエンジニア • さくらインターネットでの様々な経験を持つソフトウェアエンジニア • アルムナイ、新卒 • さくらのクラウドに加え、社内の別のサービスの開発 支 援
36. SRE室の業務(現在) • SRE as a Service • Kubernetes基盤の開発 • CI/CD基盤、IaC 支 援 • エンジニア採 用 （新卒・中途） • チームビルディング・Enabling SRE • ポストモーテムの導 入 • アジャイルカルチャーの 支 援（チームビルディング、開発 生 産性、可視化） • さくらのクラウドの機能開発・ガバメントクラウド認定に向けた開発 • ロードバランサ、VPCルータ、DNSアプライアンス、モニタリングサービス • ガバメントクラウド機能：メッセージキュー、イベントルーティング、協 力 会社 支 援 • OSS(usacloud, Terraform Provider)の開発 • Tellus、 高 火力 シリーズの開発 NEW
37. 果たして私たちはSREなのか • 一 般的に「SRE」の領域ではない業務が多くを占める • 「ガバメントクラウド」という条件下ではあるが、開発や開発 支 援の業務が多く を占める。加えて、2026年以降もサービスの開発は終わらない • より顧客に向き合う開発をしていく • SREという名称と部署の内外の期待値を合わせるのが困難になってきた
38. SREを超えて • 2025年2 月 から「テクノロジーオフィス」に名称変更 • 「SREグループ」と「Expertグループ」を設置により広く活動を 行 う • Expertグループは事業に関わる重要な業務、緊急性の 高 い課題を解決する • SREグループはSREを 支 える機能・仕組みの開発、SREのプラクティス・ 文 化を広める • ミッションは変わらない • 「クラウドサービス、システムの信頼を 高 め、新しい価値を 生 み出すことにより、お客 様や社会のDXをしっかり 支 える」
39. 「テクノロジーオフィス」のVision • エンジニア、お客様が信頼し、 新しい価値を創造し続けるプラットフォームを提供する • SREの 文 化を社内に根付かせ、その活動により社内・お客様からの信頼を得る • 高 難易度、緊急度の 高 い課題に対して、チャレンジができる基盤醸成
40. チャレンジする組織にとってのSREとは
41. SREが 行 うこと、 目 指すところ • WHAT • 信頼性をエンジニアリング（ 工 学）として扱えるようにする • なんども繰り返すことのシステム化、 自 動化 • さまざまな測定を 行 う • 「信頼性」について合意を得て、期待値を合わせる • WHY • 高 い頻度の変更と、お客様に対する機能の信頼性を両 立 させる
42. SREの背景 • VUCA時代（先 行 きが不透明で、将来の予測が困難な状態） • インターネットのサービスでは市場やお客様のニーズを継続的に捉えていかなかれ ば 生 き残れない • ハイパフォーマンスな企業では、新機能のリリースを１ 日 に数回〜 十 数回実施、 フィードバックを得てサービスを変化させる • チャレンジを継続的に 行 い、成 長 していかなければならない時代、 それを 支 えるのがSREというプラクティスであり、 文 化
43. チャレンジする組織にとってのSREとは • SREは「変化と成 長 」を 支 える。 自身 も「変化と成 長 」していく • 「変化と成 長 」を 心 地よく楽しめることがチャレンジにつながる
44. まとめ
45. まとめ • ガバメントクラウドとは何か、さくらインターネットの取り組み • さくらインターネット SRE室のあり 方 とその変化 • チャレンジする組織にとってのSREとは
46. SAKURA internet ࣾձΛࢧ͑Δ
    ύϒϦοΫΫϥ΢υɾେن໛ܭࢉࢿݯΠϯϑϥΛ
    Ұॹʹ࡞Γ·ͤΜ͔ʁ
    ソフトウェア開発、 インフラ基盤から フロントエンドまで 採 用 強化中! さくらインターネットではエン ジ ニア採 用 を強化しています さくらインターネットは新たなアイ デ アの創出に強い熱意と情熱を持って挑戦するお客様を は じ め、私たちとつな が りのあるす べ ての 人 たちのために、未来のある べ き姿を想い描きな が ら ―「やりたいこと」を「 で きる」に変える ― あらゆるア プ ローチを “インターネッ ト”を通 じ て提供します。 詳しくはWebサイトにて、カジュアル 面 談もやってます 👉 www.sakura.ad.jp/lp/recruit-engineer/
47. おわり ご意 見 、ご感想を X(Twitter)・直接・テレパシーなどなどで 伺えると嬉しいです