Cloud Native Days Winter 2025 イベントレポート

Cloud Native Days Winter 2025 イベントレポート

イベント概要

本イベントをオンラインで視聴した。

CloudNative Days Winter 2025

印象に残った内容

米軍Platform One/Black Pearlに学ぶ極限環境DevSecOps：イージス艦からF-35まで

米軍Platform One / Black Pearlに学ぶ極限環境DevSecOps - Speaker Deck

• 米軍のソフトウェアについて
  • スピードだけを重視しているわけではない
• DoD 公式の DevSecOps の教科書
  • DoD におけるソフトウェア集約型システム（兵器システム、コントロールシステム、ビジネスシステム等）に対して、DevSecOps を体系的に導入・運用するためのガイドライン
    • 重要なコンセプト
      • ソフトウェアを構成するあらゆる要素（コンパイラ、ライブラリ、ビルドツール、リポジトリ、クラウド／オンプレ環境など）はサプライチェーン
      • 開発チーム・ツール・プロセスを集めて、継続的に価値を提供するための仕組み
      • CI/CD・Infrastructure as Code (IaC)・自動化
      • 継続監視・運用・セキュリティ (Operate & Monitor)
      • 段階的／反復的な導入 (Iterative Implementation)
• Platform One
  • DoD 標準 DevSecOps プラットフォーム
• BigBank
  • 誰でもアカウントを作れるため利用できる
• Iron Bank : 強化コンテナレジストリ
  • 安全なコンテナで CI/CD も安全
  • セキュアなコンテナイメージを提供している
  • 誰にでも提供しているため、逆に全員で検証できて安全という考え
• 米海軍の事例
  • 海に浮かぶデータセンターになる
  • 1 か月海の上にいるため衛星経由の通信が必要
  • 船の上でセキュリティ対応を変更する必要がある
  • どこでもデプロイできるプラットフォームである必要がある
  • Black Pearl という DevSecOps 環境を構築
• 米軍が Cloud Native DevSecOps を推進する理由
  • 変化のスピードに対応するため
  • ソフトウェアが組織の競争力を左右する時代だから
  • セキュリティを後付けできる時代ではないから
  • 手作業に依存した運用は限界だから
  • 複雑化したシステムを安全に管理するため
  • 「止まらずに変わり続けられる」組織へ進化するため

Kubernetesと共にふりかえる! エンタープライズシステムのインフラ設計・テストの進め方大全

Kubernetesと共にふりかえる! エンタープライズシステムのインフラ設計・テストの進め方大全 - Speaker Deck

• 発表資料が非常に充実しているため、ここではポイントのみを記載する。詳しくはスライドを参照
• 説明の前提となるインフラ構成
  • パブリッククラウド上でシステム構築を行う
  • パブリッククラウドは AWS を用いる
  • コンテナオーケストレーションは、どのパブリッククラウドやオンプレミスでも利用が可能な Kubernetes を用いる
  • AWS のマネージド Kubernetes サービスである Amazon Elastic Kubernetes Service(EKS)を用いる
• インフラの基本設計とは
  • 要件定義(概要設計)とパラメータ設計の間にある工程
  • コンポーネント間がどのようにつながり、どのような協調動作を行うのかを詳細に整理する
  • これがパラメータ設計のインプットになる
• 設計の進め方
  • 接続設計
  • 耐障害性設計
  • 性能設計
  • 拡張性設計
• インフラテスト
  • V 字モデルになっており、テスト設計から結果評価までを行う
  • 考え方やテストケースの例が丁寧に説明されている
• インフラ基本設計のポイント
  • 複雑になりがちなコンポーネント間の協調動作の仕組みを詳細に理解・整理する
  • 説明責任を果たせるのがインフラエンジニアの差別化要因と考えている
• インフラテストのポイント
  • インフラ設計の内容を漏れなく確認する
  • アプリ設定にも踏み込むことで確認漏れをなくすことが重要

クラウドネイティブ時代の開発プロセス再設計 ― 速さと品質を両立するには

クラウドネイティブ時代の 開発プロセス再設計 〜速さと品質を両立するには〜 - Speaker Deck

• 開発プロセス再設計の背景
  • 開発スピードは向上したが従来の品質保証プロセスでは追いつけていない
• 課題 1: 早期 QA 参加
  • 要件段階から参加
  • 受け入れテスト作成でテスト観点を設計時点で共有
  • リグレッションテストで大きな問題発見を軽減し全体のリードタイムを短縮できた
• 課題 2: テスト自動化
  • E2E 自動テストで守りたいものを整理する
    • UI 起点ですべての部品がつながった状態で動作する
    • 最低限のユーザー体験を提供できていること
    • 部品自体の正確性は確認しない
  • その後ツールを選定し、小さく始めた
• 品質文化の醸成
  • ミッション・ビジョンを語る
    • 共感する人を味方につける
    • 特に EM やテックリードを味方につける
    • チームの目標設定に入れると動きやすくなる
  • 余白を作る
    • コストがかかっていたテストを再定義
    • 目的に合わせてテスト項目を見直し
    • 時間がかかっているタスクの見直しと効率化
    • ロードマップを作成しゴールを設定（半年や一年で見直す）
  • 仲間を作る増やす
    • ミッション・ビジョンを語って共感する人を味方につける
    • 小さな成功体験を積む
  • 成果を伝えて文化（自然に行動している）をつくる

『ゼルダの伝説　ティアーズ オブ ザ キングダム』の開発を支えたクラウド環境

• 開発環境
  • 開発機で開発している
    • 開発者の PC とつながっているためビルドした実行ファイルを開発機で確認する
    • データが大きいため職種によって取得するデータを制限している
• 内製ツール
  • 地図上に可視化する
    • ゲームパラメータ DB から情報を持ってくる
    • CI 情報から計測データ DB に格納して持ってくる
    • チケット情報を持ってくる
  • バグ報告を簡素化
    • 開発機で内製ツールで報告できるようにしている
    • PC 内のツールと Socket 通信をしてログや録画を記録する
    • チケット管理ツールでチケット AppServer がログや録画とチケット情報をチケット DB や送付ファイルオブジェクトストレージにアップロードする
• 開発フロー
  • 制作と確認を何度もまわす
• クラウド環境（3 種類）
  • CI 環境
    • オンプレミスのクラウド環境になった
    • VM を操作できるように自作ツールを作成する
      • ツールから選べば VM が自動構築される
  • Web サーバー
    • 画像掲示板
      • Kubernetes を採用
        • オーケストレーションの指示書を YAML でコミットさせる
      • ゲームプロジェクトごとに分離
      • 障害対応は手順にして自動化する
        • Kubernetes の中で自動復旧アプリを使って Pod を復旧する
        • 監視して VM を復旧
      • マルチリージョン構成
        • k8s 用にせず CI ジョブ用と一緒にしている？
    • マイルストーンごとに実装されたアイデアを全員でプレイして情報と集約を精査する
  • 開発機のクラウド
    • PC または VM と開発機は LAN でつながる
    • 開発機と VM の接続をダッシュボードから接続できるようにしている
• 自動テスト
  • 今回のバージョンは CI 環境からバグ報告数が多かった
  • CI 情報は計測・最適化の可視化のために活用した
• 動画管理
  • 動画はオブジェクトストレージにアップロードされている
  • 見たい時に最新や過去の動画が見られるように
  • 動画管理 AppServer の負荷軽減のため署名付き URL に直接アップロードするようにした
• 成果と知見
  • ゼルダの活用方法は任天堂全体のクラウド利用に繋がった
  • クラウドはソリューション（内製アプリや施策）とセット
    • クラウド環境の整備、内製ツールアプリの開発、開発の効率化・自動化対応を同じ職種のエンジニアが担当
    • 需要やゲームの仕様スケジュールをみて先回りして対応する

デザイナ目線で考えるAIを用いた新しいインシデントレスポンスの形

デザイナ目線で考えるAIを用いた新しいインシデントレスポンスの形 - Speaker Deck

• インシデント対応における課題
  • 科学的に実務の直接的な影響がある
    • 恐怖からフリーズしてしまう
    • 不安からリスクの過大評価をしてしまう
    • プレッシャーから判断劣化する
  • 一人じゃないと感じられる環境があれば恐怖・不安・プレッシャーを緩和できるのではないか
• AI を活用したアプローチ
  • Waroom を使ったアプローチ
    • Slack でのやりとりがドキュメント作成に
    • Waroom MCP を開発しインシデント対応を一緒にやるようにする
    • 修正やインシデントの Issue 作成など
• AI を使った成果
  • 懸念は解消された
    • 正確さより網羅的に列挙してくれる
    • ドキュメントを探す読む必要がない
    • 使うほど賢くなる

感想

• k8s 関連の話題も多く見られた
• 軍事関係のクラウド事情は初めて聞いたが、ソフトウェアを動かす環境が異なると対応も異なると感じた
• ゼルダの開発事情は興味深かった。内製ツールがたくさんあるのは、さすが大手ゲーム会社と感じた。300 人ほどが視聴しており人気の高さを感じた
• エンタープライズシステムのインフラ設計・テストの進め方大全はよくまとめられており、設計が初めての人にとって良さそうと感じた