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

[さくらのTech Day] ガバメントクラウド開発と変化と成長する組織 / sakura t...

kazeburo
November 13, 2024

[さくらのTech Day] ガバメントクラウド開発と変化と成長する組織 / sakura techday, Develop govcloud and the team

さくらのTech Day 2024/11/12

kazeburo

November 13, 2024
Tweet

More Decks by kazeburo

Other Decks in Technology

Transcript

  1. Me • 長 野雅広 (ながのまさひろ) • @kazeburo - X(Twitter) &

    GitHub • さくらインターネット株式会社 クラウド事業本部 副本部 長 / SRE室 室 長
  2. ガバメントクラウドとは • 既存の「パブリッククラウド」を活かす • セキュアかつ柔軟迅速に調達が可能 • 共通利 用 ・ 一

    括調達によるメリット • コストの可視化と評価 • 運 用 監視などベストプラクティスの共有による品質の底上げ
  3. ガバメントクラウド登録CSP(2024年) • Amazon Web Services (AWS) - 2022年登録 • Microsoft

    Azure - 2022年登録 • Google Cloud - 2022年登録 • Oracle Cloud Infrastructure- 2022年登録 • さくらのクラウド - 2023年登録 ※ 2025年度末までにすべての要件を満たす条件付き
  4. ガバメントクラウド技術要件 • 令和5年度募集の技術要件は以下に記載 https://www.digital.go.jp/procurement/3058bc41-ee8f-49bb-8f22-8def725f6f3f • 17項 目 /約300件 • 基本事項、1)コンピュート(サーバ)機能、2)ストレージ、3)データベース

    • 4)サーバレス・コンテナ関連機能、5)API関連機能、6)アプリケーション連携機能 • 7)データ分析機能、8)コードリリース機能、9)ネットワークとCDN • 10)システム運 用 管理機能、11)ユーザ管理、12)バックアップ、13)データポータビリティ・移 行 支 援機能 • 14)セキュリティ機能、15)暗号 管理とデータ保管セキュリティ、16)機械学習関連機能
  5. ガバメントクラウド技術要件 基本事項からいくつか抜粋 大 項 目 項 目 項番 要件 基本事項

    サービス全般 1 外部からネットワーク経由で提供される情報処理サービスであり、コンピュータや通信ネ ットワーク等の情報処理基盤を意識することなく、情報通信技術の便益やアプリケーショ ンを享受可能にし、サービスの利 用 結果が契約主体及び利 用 主体に定量的に明 示 できるこ と。 基本事項 サービス全般 3 災害時等において、公的に必要なサービスを優先する機能を有すること。 基本事項 サービス全般 4 いわゆるCOTS(commercial off-the-shelf)として広く提供されているサービスであ り、個別に開発されたものではないこと。 基本事項 サービス全般 7 技術的および物理的に共有されたところがなく完全に分離された複数のデータセンター 区画で「ゾーン」を構成し、冗 長 化を確保すること。 基本事項 サービス全般 10 情報資産はユーザが指 示 しない限り 日 本国内に保管されること。 基本事項 実績 15 日 本国内のデータセンターで当該クラウドサービスを 自 らが3年以上運営しているこ と。 基本事項 マネージドサービス 25 全てのマネージドサービスは、監視やログ管理等の運 用 系マネージドサービスと最初か ら連携しており、設定の詳細な操作ログや監視メトリクスが取得可能であること。
  6. ガバメントクラウド技術要件 データベース関連をいくつか抜粋 大 項 目 項 目 項番 要件 データベース

    RDB 4 RDBとしては、MySQL、PostgreSQL及びそれらの互換DBを選択でき、それらの基本機 能がマネージドサービスとして提供されること。 データベース RDB 12 いつでも 一 時停 止 でき、いつでも再起動できること。また、停 止 中は課 金 されない(デ ータ領域の課 金 は除く)データベースを提供可能なこと。 データベース RDB 16 DBでクラスター構成を組む際は技術的および物理的に別の区画(基本事項7で定義する 区画)を指定できること(例:CPUユニットや電源ユニットについて別のハードウェア やラックを指定できる)。 データベース RDB 17 DBはデータを同期させたクラスター構成を組むことができ、アクティブ側の障害時は 自 動的にスタンバイ側にフェイルオーバーすること。アクティブとスタンバイは物理的に別 の場所を指定できること。 バックアップ RDB 7 DBのバックアップは、 一 定期間(例:5分)以前のどの時点にでも戻せるかたちで (Point In Timer Restore)取得できること。 データベース RDB 9 DBのバックアップイメージは、CSPの中であれば、別のシステム、別のネットワーク、 別の環境からも利 用 できること。
  7. ガバメントクラウド技術要件 システム運 用 管理機能からいくつか抜粋 大 項 目 項 目 項番

    要件 システム運 用 管理機能 モニタリング機能 1 クラウドで利 用 する、各種サービスのリソース状況をモニタリングできる機能がマネージ ドサービスとして提供されていること。 システム運 用 管理機能 モニタリング機能 2 モニタリング機能は、コンピュートをはじめとする全てのクラウドリソースのメトリクス の取得と可視化ができること。 システム運 用 管理機能 モニタリング機能 4 モニタリング機能は、ビルトインのメトリクスの他に、独 自 のカスタムメトリクスを定義 し、 一 元的に管理できること。 システム運 用 管理機能 モニタリング機能 5 モニタリング機能は、ログの収集、分析、アラートの設定ができること。 システム運 用 管理機能 モニタリング機能 7 モニタリング機能は、ダッシュボードの作成機能を備えており、ビジュアライズできるこ と。 システム運 用 管理機能 モニタリング機能 18 最初にリリースされる時点から、すべてのサービスにおいて監視マネージドサービスでサ ービスの監視ができること。
  8. ガバメントクラウド技術要件 その他いくつか抜粋 大 項 目 項 目 項番 要件 コンピュート

    (サーバ)機能 コンピュート基本 14 OSは、Redhat Enterprise Linuxを含む複数のサポートのあるLinuxディストリビューショ ンと、無料のLinuxディストリビューション、およびWindows Serverから選択できるこ と。 コンピュート (サーバ)機能 負荷分散 2 インターネットからのリクエストを登録されているインスタンスに負荷分散する機能を利 用 できること。 コンピュート (サーバ)機能 機密コンピューティ ング環境 4 クラウド利 用 者からは完全に分離し暗号化された仮想マシンでデータの暗号化/復号が 行 えるサービスまたはサポートが提供されていること。 ストレージ オブジェクト ストレージ 5 オブジェクトストレージは、99.999999999%以上のデータ耐久性を持ち、ファイルの 永続的な保管ができること。そのための仕組みを備えること。かつ 大 規模災害対策の観 点で複数リージョン間でのレプリケーションが利 用 可能であること。 ネットワーク CDN 18 CDNサービスはグローバル10拠点以上で利 用 できること。
  9. さくらインターネットが取り組む意義 • 社会からの期待と 自 社のチャレンジ精神が合致 • ガバメントクラウドへの参 入 により、サービスの技術 水

    準およびブランディングを 強化を図る • 政府だけではなく全 方 位の利 用 に安 心 感をもたらすことで、国内パブリッククラウ ド市場の拡 大 に寄与およびシェアの拡 大 を 行 う
  10. 2チーム時代の課題 • さくらのクラウド「IaaS」チームの業務が 非 常に多岐に渡る • サーバ、ディスク、ネットワーク、アーカイブ、ISOイメージ • データベース、NFS、VPCルータ、ロードバランサ •

    シンプル監視、DNS、GSLB • オンボーディングのコストや「認知負荷」が 高 い • さくらのクラウドはリリース後13年。「安定」「保守」を 行 ってきた • 積み重ねた歴史とアメーバ状の担当範囲と特定個 人 への依存
  11. 現在: チームの分割 α β γ θ IaaS Billing IaaS Core

    Container ObjectStorage RDS Billing API IAM VPS, Tellus SRE室 NFV Monitoring 技術開発G Con fi dential Computing
  12. チーム分割の狙い • 「開発 生 産性」を向上させ、「 一人 で速くではなく、みんなで遠くへ」 • 認知負荷をさげる •

    ひとりひとり、チームが対象とするサービスを限定する • チームメンバーを5名〜10名程度にしてコミュニケーションコストを下げる • 並 行 で開発を進めることができる体制 • アメーバ状な兼務、依存の解消 • 新しいサービス開発も内部の改善も両 方 とも 行 う
  13. 取り組み1: 読書会 • 当初は「開発 生 産性向上」について学ぶのが主 目 的 • 得たもの

    • 引 用 回数も多い本書を読むことで他の本も読みやすくなった • 前提の共有、組織のイメージの統 一 • リモートワーク前提とした働き 方 で信頼貯 金 ないところから参加者の互いのことを 知る機会となった
  14. チームに 自 律性を組み込む • 役割、期待値、キャリアの明 示 化 • チーム責任者: チームのゴールの明確化

    • 開発 支 援者: 開発可視化、ふりかえりなどのファシリテーション • テックリード: チームの最終的な技術の意思決定 • EMチームの 立 ち上げ • 開発 生 産性の向上を軸に採 用 、オンボーディング、カルチャー、エンゲージメント醸 成で開発者をサポート
  15. エンジニアの変化と成 長 へ • 認知負荷の低減、 心 理的安全性の確保による働きやすさ • 国産クラウドという周囲からの期待と難易度の 高

    い開発によるやりがい • 役割、ロールの明 示 化によるリード&フォロー • 読書会から1年半、チームが動き出してから半年で 自 律的な動きが明確に
  16. 開発の主なトピック αチーム(API) 認証認可を 行 うAPI(IAM)のフェーズ1、内 部リリース完了 Python/DjangoでAPIを構築し、既存コン トロールプレーンから処理を委譲するアー キテクチャの採 用

    γチーム コンテナ化されたアプリケーションをワン ステップでにデプロイし 、 自 動的にスケー ルリングする「さくらのAppRun」をβリ リース 基盤にKubernetesとKnativeを採 用 SRE室 マネージドサービス等のログを集約し、検 索、分析できるモニタリング基盤を Apache IceburgおよびApache Trinoを活 用 し構築。メトリクスの収集、可視化サー ビスも開発中 Θチーム IaaS基盤のGo 言 語へのリプレースを段階的に進めている 信頼性、スケーラビリティの向上と共に、オブザーバビリテ ィ の改善 も 行 っている ガバメントの技術要件にはあたらな い。クラウド基盤の継続的な改善も 同時に進める
  17. SAKURA internet ࣾձΛࢧ͑Δ ύϒϦοΫΫϥ΢υɾେن໛ܭࢉࢿݯΠϯϑϥΛ Ұॹʹ࡞Γ·ͤΜ͔ʁ ソフトウェア開発、 インフラ基盤から フロントエンドまで 採 用

    強化中! さくらインターネットではエン ジ ニア採 用 を強化しています さくらインターネットは新たなアイ デ アの創出に強い熱意と情熱を持って挑戦するお客様を は じ め、私たちとつな が りのあるす べ ての 人 たちのために、未来のある べ き姿を想い描きな が ら ―「やりたいこと」を「 で きる」に変える ― あらゆるア プ ローチを “インターネッ ト”を通 じ て提供します。 詳しくはWebサイトにて、カジュアル 面 談もやってます 👉 www.sakura.ad.jp/lp/recruit-engineer/