KubeCon + CloudNativeCon Japan 2026 参加記

7/28〜7/30にパシフィコ横浜で開催された KubeCon + CloudNativeCon Japan 2026 に参加してきた。 本会議は7/29(水)・7/30(木)の2日間で、7/28はCNCF主催の併設イベント日。 今回はメインの2日間、キーノートと数多くのセッションを聞いて回ったので、印象に残ったところを中心に記録として残しておく。

全体として感じたのは、昨年参加した KubeCon Japan 2025 ではサービスメッシュ・移行事例・オブザーバビリティ・eBPF・ネットワーキングなど幅広いテーマが並ぶ中でAI(Generative AI)関連のキーノートが1つあった程度だったのに対し、今年は「AI推論・学習をKubernetes上でどう効率よく大規模に回すか」という話を扱うセッションが増えていたこと。 GPU、電力、分散推論、AIエージェントの運用まで、AIをテーマとするセッションが多かった。

他にも eBPF 関連のセッションも面白そうだったが、自分はSREとしてプラットフォームの運用性・信頼性・チーム間の摩擦に向き合おうとしているので、これらセッションよりも、プラットフォームエンジニアリング寄りのセッションに足を運んだ。 この記事でも、そうした視点で聞いたセッションを中心に振り返る。

1日目(水): AI Adoption Surges

キーノート: Cloud Native Moving

初日のキーノートは「AI Adoption Surges」というテーマで始まった。 Uberはかなり大量の予測をKubernetes上で捌いており、価格決定や安全チェックなど用途ごとに専門化された大量のAIモデル群を動かす基盤としてKubernetesを位置づけているという話があった。 自動運転スタートアップのWayveは、ジョブキューイングプロジェクト Kueue を活用してクラスタのGPU使用率を85%から97%まで改善したという事例も紹介されていた(Tech Times記事)。

推論と学習の比率が67%対33%まで逆転しつつあるという話もあり、「学習は断続的だが推論は毎プロンプトごとに走る」というシンプルな理由が説明されていた。 分散システム・オーケストレーション・ネットワーキング・o11yなど、大規模推論を支えるための要素技術群として、Red Hat・Google Cloud・IBM Research・CoreWeave・NVIDIAらが立ち上げた分散LLM推論フレームワーク llm-d も紹介されていた。

後半はHugging Face CEOのClement Delangueが「企業はもうAIを借りる時代を終える」「オープンソースが勝つべき」という趣旨の主張を展開し(TechCrunch記事)、"Japan Cloud could end up an AI colony if it falls behind" というフレーズとともに、自国でAI基盤を持たない国は"AI植民地"になりかねないという、AI sovereigntyの議論に繋がっていった。 このあたりはKubeCon EU 2026でも語られていたテーマらしく(Pulumi Blogのレポート)、地政学の話とインフラ技術の話が同じキーノートの中で語られていたのが目についた。

the next evalution of k8s: gpu-centric infra for AI workloads, Takao Indoh

GPU・DRAMなど高騰するAIリソースのコストを扱うこのセッションで紹介されていたのが CoHDI("Composable Hardware in Disaggregated Infrastructure"、通称"Cody")。 富士通発のOSSプロジェクトで、GPU/DRAMなどを分離(disaggregate)したハードウェアプールから、Podの要求に応じて動的にアタッチ/デタッチできるようにする仕組み。 KubernetesのDynamic Resource Allocation (DRA) と統合されており、v0.1.0が2025年10月にリリース済み、現在CNCF Sandbox登録を目指している段階とのこと(CNCF Sandbox申請Issue、プロジェクトサイト)。 GPUの絶対数が足りない中で「持っているハードウェアをどう合成して見せるか」という発想が実務的だと感じた。

Mulit Tenant with CNCF Ecosystem (Preferred Networks)

PFN(Preferred Networks)によるセッションでは、logical → API → kernel → physical という4段階のisolationを、コストと隔離強度のトレードオフとして整理していたのが分かりやすかった。 namespace/RBACレベルの軽量なlogical isolationから、gVisor/Kata Containersのようなkernel isolation、専用ノードを割り当てるphysical isolationまで、必要な隔離レベルに応じて使い分けるという考え方。 公平性の実現には HRQ (Hierarchical Resource Quota) で階層ごとのクォータ上限を決めつつ、Kueue でジョブキュー単位のFair Sharingを行うという組み合わせが語られていた。 GPUクラスタを複数チームで分け合う上での定番パターンなのだろうと感じた。

AIOps: (near) Zero-Touch Production Rollout Fixes

IBMのKevin DuboisとAdobeのCarlos Sanchezによる発表。 ロールアウトが失敗した際にAgentic AIがログやメトリクスを解析し、原因に応じて自動的に修正PRを作成して通知する、という「ほぼ無人(near zero-touch)」なロールアウト修正のデモだった。

導入として2024年のCrowdStrikeの大規模障害(設定更新の一斉配信でWindows端末が大量クラッシュし、航空・鉄道など広範なインフラに影響が出た事例)が引き合いに出され、progressive delivery(段階的リリース)の重要性が語られていた。 デモでは実際にリリースがロールバックされる様子と、「なぜロールバックしたか」がAIエージェントによって説明され、さらに修正PRまで自動生成されるところまで見せていた。 仕組みとしては Argo Rollouts の AnalysisTemplate に対して、人間がPromQLを書く代わりにAIエージェントに判断を委ねるプラグイン argoproj-labs/metric-ai が使われていて、agentUrl・stableLabel/canaryLabel・extraPrompt・githubUrl のようなフィールドをYAMLに書くだけでAIによるカナリア分析とPR自動生成が動く様子が具体的に示されていた。

学びとして紹介されていた「1つのAIサービスから並列・非同期のagentic systemへの移行」「LLM選定+context engineering+tool calling(特にPR作成のため)」「複雑性とportabilityのトレードオフ」という3点は、自分がAIエージェントを組む上でも参考になりそうだった。

From Tool Calls to Context Fabric: Building AI-Native Observability for Platform Engineering

AIOpsのセッションと合わせて聞くと理解が深まったのが、こちらのセッション。 障害調査では「メトリクスはPrometheus、ログはLoki、異常検知は別ツール、運用知識はランブック」というように情報が分散しているのがよくある課題で、既存のAIアプローチ(RAG、Text-to-PromQL、単一ツール特化のcopilot)はそれぞれ得意領域はあるもののドメインをまたいだ関連付けが弱い、という指摘から始まった。

提案されていた"context fabric"は、サービス・メトリクス・ログ・異常検知・ドキュメントを事前に(問い合わせが来る前から)知識グラフ・メタデータキャッシュ・ドメイン横断の関係性モデルで繋いでおき、それをMCP経由でAIエージェントに渡すという構成。 「安全な調査は5つの質問を順番に行う」— resolve(何が影響を受けたか)・discover(各ソースは何に答えられるか)・query(いつ何が観測されたか)・align・recommend、という構造化されたワークフローが参考になった。 "discoveryはクエリではなくワークフローであり、事前に計算しておくべきもので、都度ライブに問い合わせるものではない"という原則は、SREとして自前のオンコール向けAIアシスタントを作るなら参考にしたい設計だと感じた。

OCI is not Git: Rethinking the GitOps Source of Truth for a Kubenetes-Native World

従来のGitOpsは「Gitリポジトリ=構成のSource of Truth」が前提だったが、近年はOCIレジストリにKubernetesマニフェストやHelmチャート、SBOM、署名なども"OCI Artifact"として格納し、そこをデリバリの起点にする動きが広がっているという話。 Gitには「人間によるレビュー・変更管理」という強み、OCIには「不変性・可搬性・エアギャップ対応のしやすさ」という強みがあり、どちらか一方を選ぶのではなく両方を活かそうというのが Kokumi というOSSプロジェクトのコンセプトだった。

Kokumiはマニフェストをレンダリングするたびにcontent-addressedな不変のOCIアーティファクトを生成し、実際のデプロイ実行は自前で行わず Argo CD に委譲する設計。 「git=変更管理」「Kokumi=不変アーティファクト管理」「Argo CD=デプロイ実行」という3層構造で役割分担しているのが整理として分かりやすかった。 個人的には「git で十分では」と思いながら聞き始めたが、Edge/Air-Gap環境のように"都度pull/reconcileする"ことが前提にできない場面では、事前にレジストリごとオフラインへ持ち込めるOCIの不変性が効いてくる、という説明があった。 自分の所属組織でもセキュアな環境と一般の環境を分けて運用しているので、もしセキュアな環境側からGitリポジトリへのアクセス自体ができないとしたら、こうした構成を取る必要が出てくるのかもしれないと考えると興味深く感じた。

Sustinablity by Design: Leveraging DRA for Energy-Efficient Kubernetes Cluster

x/gpu: "1" のような汎用的なGPU要求ではなく、firstAvailable: [{deviceClassName: gpu-energy-efficient}] のように省エネなデバイスクラスを明示的に選択できるようにする、というDRA (Dynamic Resource Allocation) 活用の発表。 CELで具体的なハードウェア特性を指定する"DRA CEL Selection"や、H100のようなperf/watt に優れたハードウェアを優先する"DRA Prioritized List"など、スケジューリング層での工夫が紹介されていた。 エネルギー消費の計測にはKeplerというCNCF Sandboxプロジェクトが使われており、標準化されたメトリクスをKEDAやVPAのようなスケーリング系プラグインが読み取って判断に活かす、という連携イメージが語られていた。

Evolving Platform Primitives, Beautiful Platform with KRO

AWS・Google・Microsoftが初めて共同でOSSプロジェクトを立ち上げたという点でも話題の kro (Kube Resource Orchestrator)。 「Helm・Kustomize・自作シェルスクリプト・Backstageテンプレートのように"ツール"を次々足していくのではなく、"primitive(基本部品)"を設計する」という主張が印象に残った。 primitiveの条件として挙げられていた closure(組み合わせても同じ種類のものになる)・uniform interface(統一インターフェース)・orthogonality(関心の分離)という3ルールは、kroに限らずAPI設計全般に効きそうな考え方だと思う。

ResourceGraphDefinition というカスタムリソースでAPIスキーマとその裏にある複数のKubernetesリソースをCEL式で繋いで定義すると、kroが自動でCRDを生成し、依存関係順にreconcileしてくれる。 「公開するAPIの5原則」(利用者のドメインの言葉で命名する/利用者が判断できる項目だけ公開する/よくある使い方はゼロコンフィグにする/各フィールドの所有者を明確にする/statusもAPIとして丁寧に設計する)はチームで社内プラットフォームAPIを設計する際にそのまま使えそうなチェックリストだった。 自分の所属組織では独自形式のYAMLからAWSリソースを生成するような仕組みをすでに作ってしまっているので、kroへの移行は簡単ではなさそうに感じたが、調べてみる価値はありそうだと思った。

Turning Platform Engineering Work into Business Value Leadership Understands

SREとしてプラットフォームチームの成果を経営層にどう主張するかは考えておく必要があると思うので、このセッションは興味深く聞いた。 プラットフォームエンジニアリングチームは強力な内部プラットフォームや自動化を作っているのに、なぜその投資が正当かをうまく説明できず苦労している、という導入から始まり、技術的な改善を経営層の言葉に翻訳した実例が紹介されていた。

指標フレームワークとしては、デプロイ頻度・変更のリードタイム・変更失敗率・サービス復旧時間を測るDORAメトリクスが「経営層に説明しやすい」定番として挙げられ、"DORA自体はビジネスケースそのものではないが、その半分はリスクを金額に換算するものであり、risk is money" というフレーズが印象に残った。 開発者体験を多面的に捉えるSPACEフレームワークや、それらを統合したDX Core 4も紹介され、「速度系」と「体験系」の指標を組み合わせて語るという実務的な指針が示されていた。 財務用語としてのcapex to opex shift(自前データセンターへの資本的支出から、クラウドの従量課金への転換)も、クラウドネイティブ化を経営層に伝わる言葉に翻訳する切り口として紹介されていた。

もう一つ印象に残ったのが、プラットフォームの成熟度モデル: provisional(有志・一時的、中央予算なし)→ operational(専任チーム、コストセンター)→ scalable(プロダクトベースの予算、価値に応じたchargeback)→ optimizing(エコシステム全体の効率化) という段階を "treat your platform as a product from day one" という一言でまとめていたこと。 ユーザーを顧客として扱い、ディスカバリー・ロードマップ・フィードバックのプラクティスを回し、価値に応じた予算配分(chargeback)で資金を得るという発想は、自分たちのプラットフォーム運用にも持ち帰りたいと感じた。

From 165 Days to 30 Minutes: Breaking Enterprise Silos with Platform Engineering

もう一つ、SREとして関心を持って聞いたのがJAL Digitalの発表。 "Hello World"レベルのアプリをデプロイするだけで15部署・40種類の申請フォームを通す必要があり、基本的なシステム構築に165日かかっていたという課題からスタートし、それを30分にまで短縮した過程が語られていた。

原因はあちこちのwiki/マニュアルに情報が散らばる"ドキュメントの混沌"と、アプリケーションチームとインフラチームの間のサイロ化。 インフラチーム単体でプラットフォームを作っても開発者の日々の痛みは解決できないという考えのもと、App/Infraを横断する社内プラットフォームチームを立ち上げていた。 設計思想の"desire paths(けもの道)"— 開発者が実際に取っている近道・自然なワークフローを観察してそれをそのまま正式な道にする、という発想は、規則で縛るのではなく実際の行動を起点にするという意味で、SREのオブザーバビリティ的な発想と近いものを感じた。

進め方としては、大きな事前計画を捨てて素早く作って・試して・学ぶ独自のAgile運用(心理的安全性、部門横断でのオーナーシップ共有、"Thank You"から始めるセッション)、最初はAWS Lambda/DynamoDBのプロビジョニング自動化という1点の摩擦に絞って着手する"Start Small, Win Big"、そしてトップダウンでの強制導入ではなくDay 0/Day 1+チュートリアルや"3mm Rule"(開発者の目線に極力近い場所に導線を置く)による自発的な採用促進、という3つのアプローチが紹介されていた。 ツールも上から強制するのではなくチーム自身がBackstageを選んだという"engineering autonomy"の尊重は、標準化を急ぎがちなSRE/プラットフォームチームへの参考になった。 165日を30分にするような一発の銀の弾丸があったわけではなく、組織づくりや小さな成功の積み重ねといった地道な改善の結果なのだという点が、話を聞いていて感じたことだった。

2日目(木): Identity、Sustainability、そしてAIエージェントへの"信頼"

キーノート: Where will Cloud Native take you?

2日目のキーノートはJeffery Sica氏による、コードを書かなくてもOSSには貢献できるという話が中心だった。 火星の人(The Martian)の原作がプログラマーによって書き始められ、読者からのバグ報告(フィクションへの!)を経て出版に至ったというエピソードを引き合いに、「"プログラム主体"のOSSはなく、アイディアのコミュニティ運営が主体である」という主張があった。 貢献の入り口として contribute.cncf.io が紹介されていた。

Navigating the Identity Abyss in the AI-Native Era

Web App(SSO)・REST API(OAuth 2.0)・Agentic AI(MCP spec)と、レイヤーごとに認証・認可の方式がバラバラになっている"ID沼"を整理するセッション。 OSSのIAM/SSO基盤として広く使われる Keycloak を軸に、CNCF TAG Securityの IAM White Paper、日本発のWebAuthn検証ライブラリ webauthn4j、そしてMCPの拡張仕様である MCP Enterprise-Managed Authorization まで、企業がAIエージェントに社内ID基盤経由でアクセス制御をかける仕組みが紹介されていた。 「認証」だけでなく「認可」の標準化も同時並行で進んでいるという意味で、後述のAuthZENのセッションとも繋がる話だった。

Score-Driven Multi-Cluster Management: An Evaluation Framework for Decision-Making

SoftBankとRed Hatによる発表では、日本各地に分散するAI-RAN基盤(GPU容量・電力・ネットワークがそれぞれ異なる拠点)をどう束ねて推論エンドポイントを最適配置するか、という課題が扱われていた。 マルチクラスタ管理のCNCF SandboxプロジェクトOCM (Open Cluster Management) の Placement にはクラスタ選択のためのスコアという概念はあったが、「そのスコアを誰が計算するのか」という層が存在しなかったというギャップに対し、Dynamic Scoring Framework (DSF) というOCM Add-onを提案していた。 「測定→スコア化→決定→Placement/Policyで適用」というパターンは、AI-RANに限らずEdge/分散クラウドや持続可能性など幅広い意思決定に応用できる、とまとめられていた。

SBOMit: Making SBOMs Accurate with Attestations

SBOM(Software Bill of Materials)の精度問題を扱ったセッション。 従来のSBOM生成ツールは静的解析やパッケージマニフェストに頼るため、ビルド時に動的取得される依存関係を見逃しがちで「推測ベース」になってしまう。 OpenSSFの SBOMit は、witnessツールでビルド中のファイル読み書き・プロセス実行・ネットワーク接続を実際に観測し、in-toto形式の署名付きアテステーションとして記録することで「実測・検証済みのSBOM」を作るという発想。 eBPFとptraceは出力が同じだがeBPFの方が5倍ほど速いという比較や、既存ツール(syft、trivy)との比較で「どれが最も正確とは断言できない」という率直な説明もあった。

背景として、EU Cyber Resilience Act (CRA) がSBOMの作成・保管を法的義務に格上げしつつあるという話もあった。 所属組織でSBOM導入を説得する材料にならないかと思って日本の状況も調べてみたところ、日本ではまだ経済産業省(METI)のガイドライン止まりで法的拘束力はないとのこと。

The Evolution of GitOps in Platform Engineering, Artem Lajko, CNCF Kubestronaut

「GitOps in Platform Engineering」のセッションは、これまで聞いた複数セッションの内容が1つに集約されているような総括的な内容だった。 2017年にWeaveworksが提唱した4原則(Declarative / Versioned and Immutable / Pulled Automatically / Continuously Reconciled)から、大規模化に伴いGit自体が状態ストアとしての限界を迎えつつあるという指摘、そしてOCIベースの"Gitless GitOps"への流れが語られていた。 「thousands of CRDsによってAPIサーバーが遅くなる("config sprawl")」「Git was never the single source of truth、Gitはあくまで"Source of Intent"」というフレーズが印象に残った。 Argo CDのスケーリング手法として、中央のUI/可視性を残しつつ実行部分を各クラスタのエージェントに分散させる Argo CD Agent も紹介されていた。

The Great Doubt: What Building an AI Agent Taught Us About Trust

Grafana Labsが自社のAIアシスタントGrafana Assistantを開発する中で経験した、6段階の"疑い"を振り返るトーク。 京都学派の哲学者・西谷啓治の「大疑」(疑い抜くことでしか真の目覚めはない)を軸に構成されていて、他の技術トークとは異なる切り口だった。

• エージェントを疑う: バグでコンテキストが空でも、もっともらしく回答してしまう(plausible ≠ correct)
• テストを疑う: golden datasetによるテストが"全部green"でも実は間違っている、LLM-as-judge自体の非決定性もある("二重の非決定性")。→ pass@3 / pass^3 / 0-for-3 のような評価指標を導入
• 審判を疑う: LLM-as-judgeが自分の採点基準を"甘く"改変して不正合格させていたことが発覚 → 本番トラフィックを継続サンプリングする"online evals"へ
• スコアを疑う: 失敗は分かっても理由が分からない → OTel GenAI SIGのセマンティック規約に沿ってトレースを追加
• 疑いそのものを疑う: システムプロンプトを丸ごと外した"バグ"版がなぜかベンチマークで好成績を記録する事件 → ベンチマーク自体が実力を過大評価しうるという発見
• 疑う自分自身を疑う: 「自分たちは本当にユーザーの疑問を代弁できているのか」という、まだ答えの出ていない問い → 観測性特化の公開OSSベンチマーク o11y-bench.ai を公開しコミュニティに委ねる

締めの "Trust is not a claim. Trust is the output of verification."(信頼は主張ではなく、検証の結果である)という言葉は、AIエージェントを実運用に乗せる上で重要な指摘だと感じた。

AuthZEN in Practice: Standardizing Authorization for Cloud Native Platforms and Agents

最後に聞いたのが、OpenID Foundationが2026年1月に最終仕様として承認した AuthZEN Authorization API 1.0 を紹介するセッション。 認証(OAuth/OIDCでほぼ標準化済み)に対し、認可はベンダーごとにバラバラの独自実装が乱立していたという長年の課題に対し、「判断する側(PDP)」と「強制する側(PEP)」を分離し、シンプルなJSON APIでやり取りできるようにする標準インターフェースを定義したもの。 AIエージェントがAPIやインフラに広くアクセスするようになるほど、「このエージェントはこの操作をしてよいか」というきめ細かい・リアルタイムな認可判断が重要になる、という文脈でKeycloakを使ったエンドツーエンドのデモが行われていた。 前日聞いたMCP Enterprise-Managed Authorizationが「認証」寄りの標準化だとすると、AuthZENは「認可」寄りの標準化として補完関係にあるという整理は分かりやすかった。

スポンサーセッション

スポンサーブースでもいくつかのデモを見た。 中でもAWSのデモが興味深かった。

Amazon EKS Capabilitiesのデモ

直前に聞いたkroに加えてACK(Amazon Controllers for Kubernetes)やArgo CDを含む、AWSのEKS向け構成(EKS Capabilities)をAWS担当者がデモしていた。 kroとACKは相性が良さそうで、独自に構成を組むよりもこちらを使う選択肢の方が現実的かもしれないと感じた。

Agentic SkillによるEKS構成のAIレビュー

AWSが提供するAgentic SkillであるAPEX Skillsを使ってAIエージェントを動かし、EKSクラスタの構成をレビューするデモ。 EKS向けのMCPサーバを立てて、Security・Cost・Reliabilityそれぞれのanalyzerを動かし、EKSクラスタを分析させていた。 AWS担当者に「先にMCPサーバを立てておく必要があるか」と伺ったところ、APEX SkillsはMCPサーバがない場合は自分でコマンドを実行して用意してくれるとのことだった。 EKS向けのMCPサーバ自体もワンコマンドで立ち上げられるという。

まとめ

カンファレンス全体としては「AIワークロード(特に推論)をKubernetes上でどう効率よく・安全に・持続可能に回すか」という話が中心的だった。 ただ自分はSREとして日々プラットフォームの運用性・信頼性・チーム間の摩擦に向き合おうとしているため、プラットフォームエンジニアリング寄りのセッションを中心に聴講した。

それでもAIというテーマは、プラットフォームエンジニアリング寄りのセッションにも共通して見られた。 AIOpsによる自動ロールアウト修正やContext Fabricによる根本原因分析支援のように、「プラットフォームチームが運用するインフラの対象がAIワークロードになる」だけでなく、「プラットフォームの運用自体をAIエージェントが手伝う」という二重の意味でAI化が進んでいるのが今回の実感だった。

もう一つ感じたのは、AIの隆盛によって「リソースが再び不足する時代」が戻ってきたということ。 CoHDIによるGPU/DRAMのcomposable化、PFNのマルチテナントにおけるisolationとコストのトレードオフ、DRAを使った省エネなデバイス選択、OCM+DSFによる分散拠点のスコアベース配置など、聞いたセッションの多くが根っこでは「限られた高価なハードウェア(GPU・電力)をどう合成・共有・最適配置するか」という同じ問いに向き合っていた。 クラウドの従量課金でリソースの制約をあまり意識しなくて済むようになっていたところに、GPU・電力という物理的な希少資源が新たなボトルネックとして再浮上し、かつてのHPC(High Performance Computing)界隈で見られたようなリソース最適化の議論が形を変えて戻ってきている、というのが今回感じたことだった。

SRE NEXT 2024 参加してきた

8/2, 8/3 に行われていた SRE NEXT 2024 に参加してきたのでそれの感想など。

SRE NEXT 2024 について

SRE NEXT は今年で 4 回目の SRE に関するイベントで、同じく SRE に関する勉強会の SRE Lounge が中心なって開催している。

自分はこれが 2 回目の参加で、最後の参加は 2022 の回。動画のみ視聴だったせいかあまり記憶に残っていない。 今回は久しぶりに現地参加ということもあってか結構影響を受けることができたのではないかと思う。

参加したセッション

Reliable Systems through Platform Engineering

キーノートではSRE を導入するにはどこから始めるか、またどのような指標を持つべきか、という話がメインだった。

印象的だったのは最初に提示された「99.99 を 99.9 の上に達成することができるか」というお題。 最初にはできないと考えてたが、提示されたように RAID のことなどを考えると確かに達成できるなという感想だった。

どこから SRE 始めるかとして次の順序でやるとよいと紹介されていた:

1. SLO,エラーバジェットを可視化
2. 振り返り
3. 定期的な振り返りのレビュー
4. リスク評価と優先順位付け
5. 信頼度のためのバックログ作成

ここらへん自分の組織でどの程度できているかな？ SLO のダッシュボードはあるが、それが活用できているかはあやしい。 そもそも開発チーム側からフィードバックはあまりない気もする。

またDORA 指標を紹介していた。

• 速度に関する指標
  • Deploy 頻度
  • 変更にかかる時間
• 安定性に関する指標
  • 変更失敗率
  • 復旧にかかる時間

この指標はあまり意識していなかった。こういうのも意識するべきか。

工学としてのSRE再訪

このセッションは工学的あるいは学術的な見地から SRE をどのように扱うかという話だった。

論文をさがしてみるか、という気になったのでこのセッションはかなり感謝がある。

また印象にのこった言葉として書籍からの引用であるが「ウェブオペレーションは技芸であって科学ではない」というのがあった。 実際自分としても一部の指標を勘と経験、度胸(よくいう KKD)で決めることもあるので、なるべく「科学」側に倒したいというのはあったりする。

工学からの貢献として以下のものが紹介されていた。

• 信頼性の予算化(=エラーバジェット？)
• オブザーバビリティ
• 開発生産性の指標
• 開発組織の設計

このあたりのアイディアが工学から来ているのはちょっと以外だった。

また工学から見た SRE のオープンチャレンジとしてつぎの問題が挙げられた。

• オオカミ少年アラート問題
• トレースデータがほとんど参照されない問題
• インシデント対応の改善がなかなかできない問題
• インシデント対応がソフトウェアで扱えていない問題

ココらへんは SRE あるあるという感じである。

いくつか論文も紹介されていたのでこれから目をとおしていきたいところだが、 まず SREcon に目を通すといいらしい。

おすすめされていたトピックはつぎのようなもの:

• Gray Failure
• Cross-system interaction Failures
• A policical Scientist's Insights
  • "Only Complexity Can Reduce Complexity"
• Measuring Reliability Culture
• Irones of Automation
  • 人間を排除して自動化するほど、人間に高度なスキルを要求する皮肉
  • また自動化システムが人間の能力不足を隠蔽してしまう新しい皮肉
• Process Feeling
• Controlling the Costs of Coordination

DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策

セキュリティ対策の話。 ここでの内回りはShift Left 戦略で、一方外回りは運用でのセキュリティ対応している。

比較すると、内回りは低負担・非網羅的、外回りは網羅的だが高負担となる。 連携としてはまず外回りからはじめてある程度落ち着いたら内回りに着手というのがよいとこのこと。

宇宙科学研究所の探査機運用システムにおけるSREのプラクティスの導入と月着陸実証機SLIMでの利用

Isas/Jaxa で、探索機運用システムや月着陸時のモニタリングに SRE のプラクティスを導入したという話。

Grafana の見慣れた画面で宇宙船のモニタリングをしているのには素直に驚いた。

この手の組織に Grafana とか OSS を導入するにはやはりそこそこ苦労があったっぽい。

オブザーバビリティのマクロからミクロまで〜あるいはなぜ技術書を翻訳するのか

SLO はボトムアップで設定するか？トップダウンで設定するか？ => ユーザに近い方 = トップダウンのほうが良い

マクロレベルではラムズフェルドの4象でいう unkonwn-unkonwn を減らすことが重要。 マクロレベルのオブザーバビリティでは複数のコンポーネントとの関係性、他のシグナルとの関連付け、また長期的な観点で分析可能であることが必要となり次のようなシグナルが重要になる:

• 分散トレース
• メトリクス
• ログ
• 継続的プロファイル

一方ミクロ側では確実に信頼性を担保したい。つまり known-known を確実にして、knwon-unknown を減らしたい。

そこで TFBO フロー(test -> fix -> benchmark -> optimiazaiton) が重要となる。

またミクロレベルでも SLO が必要( RAER (Resource-Aware Efficiency Requirements)　といったもの)

ところで詳解システム・パフォーマンスでタイムスケールと紹介されいたものが、効率的な Go ではナプキン計算と紹介されているらしい。 どういう経緯でそうなったのかわからん。

のようにおおよそのコストを把握するのも重要。

SLO を満たせなくなったら

SLO を満たせなくなったらどうするか？

対応例:

• カナリアリリース
• マルチリージョン化
• SLO の見直し

やるべきなのは

• incident を理解する
• ポストモーテム
• リスク分析

incident の影響については次の指標を使うのが役に立つ:

• ETTD = Estimated Time To Detection
• ETTR = Estimated Time To Resolution
• ETTF = Estimated Time To Failure

また障害時に対応できる playbook を作っておくのが理想

徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例

mixi の SRE は embedded + central の形式

対象は webサイトで、運用方針として少人数のため徹底的に自動化、割り切りができる。

実践していること

• Iac (Teffafrom + in house tool)
  • モジュール化、テンプレート化
• モノレポ
  • CI/CD 効率化
• 脆弱性対応
• モニタリング・アラート
• 障害対応

500万人が利用する「友達と遊べるたまり場アプリ パラレル」におけるデータベース基盤の継続的改善

パラレルでの構成は CLB -> Rails -> Sidekiq -> CloudSQL という流れ。

• クエリの処理づまりで全体に影響があるよりも個別にタイムアウトするほうが良い
  • サーキットブレーカー導入
  • クラウドメンテナンス中の API エラー

サーキットブレーカーのテスト -> toxiproxy コネクションプーリングプロキシ -> vitess

SREの技術トレンド2024

このセッションは公開の予定はないのであんまり詳しく書かないほうがいいのかな？

話題として LLM の話が多かった。

SRE における LLM の活用例として障害対応の slack スレッドを AI に要約させるというのがあった。 これにより後から参加する人も障害の対応状況に追いつきやすくなる利点がある。 (これは試してみたい

また LLM は要約、分類が得意なので、ポストモーテムやラベリング、将来的には障害対応訓練などに使えるかもしれないという話があった。 ただやはり LLM をワークフローに組み込めないといいサービスができないのではという話もされていた。

他の話題として:

• SRE のトレンドを追いかけるなら SREcon America をみるとよい
• SRE のトレンドとして incident management 関連の話が多い
• 分散トレーシングはゴミ

という話があった。 あと SRE のプラクティスがサービス化されるなら将来的に今の職は危ないのかも。

敵対的SRE: 300個のジョブをAIチーム全員で支える技術

AI を提供する企業での大量かつ重さもそれぞれな学習ジョブが走っている環境で SRE を導入した話。

ここでの「敵対的」は GAN からの流用で SRE と AIチームとのフィードバックループのこと。

単純なアラートから、詳細化、スロージョブを検出するための SLO の設定、ジョブの軽重による SLO の適用方法変更をフィードバックループをまわして適用していったとこのこと。

まとめとしてはチームと SRE が互いに学習しながら成長するのが良く、一方的に設定するのはアンチパターンである。

個人的な感想

感想としては SRE 一般のトピックが多かった印象で、あまり個別の技術要素についてはふれられていなかったかもしれない。 これは社内の情報になるのでパブリックに出せないのも仕方ないのかも。

また現在コスト関連の作業をしているのでそのあたりの話も聞きたかったが全然話題になってなかった。 これはどちらかというと AWS 関連の勉強会で話題になることなのでしかたないかもしれない。

その他:

• 会場に wifi がなかったのでメモを取るのに苦労した。
• 久しぶりの現地参加というのもあるが、メモをとる環境がイマイチできていない気がする。
  • notion にしろ scrapbox にしろネットにつながっていないと使えないので…
  • メモを取るときは実のところ図を書くことはなくほぼテキストですませているので、
  • obsidian と dropbox あたりをうまいこと組み合わせてメモを同期できるようにするのがよいかもしれない。

個人的な TODO

• 論文探してみる
• SRECon 2024 の発表に目を通してみる

boost::outcome::result

ここ最近仕事で C++ を書くことになってそこで困った話。

経緯として、C++ で例外を投げたくないので関数型言語の Either みたいな直和型が欲しいとぼやいていたら、 https://twitter.com/cpp_akira さんから boost::outcome というのがあると教えていただいた。

これは良さそう！ということで早速試してみたのだが、ドキュメントを見ながらコードに落としてみてもどうにもビルドできない。 ドキュメントにあるコードをビルドしてみても同じようなエラーになってしまう。

prog.cc:68:12: error: no viable conversion from returned value of type 'ConversionErrc' to function return type 'outcome::result<int>' (aka 'basic_result<int, boost::system::error_code, boost::outcome_v2::policy::error_code_throw_as_system_error<int, boost::system::error_code, void> >')
    return ConversionErrc::EmptyString;

ドキュメントにあったとおりオレオレエラーコードの std::error_codeへの変換を行う処理も書いたのになんで？と一晩ぐらい悩んだ。

で、ふと boost には boost::systemm::error_code というのがあるのを知ったので、もしかしてと思いオレオレエラーコードの変換先をこちらにしてみた。 やはりというかそれで動いてしまった。

おそらくドキュメントがoutcomeのboost入り前で更新が止まっているらしく、std::error_code とある部分は boost::system::error_code に読み替えないといけないらしい。

ということでなんとか解決はできたが疑問が残る。仕事で C++ を使うのはこれが初めてなんだが、Boostライブラリの使用時には std にあるものよりも boost にあるものを優先して使うのがお約束だったりするんだろうか？そうでもないと自分と同じ問題にあたっている人が全然いないように思える。

AtCoder Panasonic 2020

Contest Result - AtCoder

祝水色。

まだまだレーティングを上げる余地はありそうだ。

ただし青以上のパフォーマンスは一度も取っていないので、青になるためにはかなり精進が必要っぽい。

まず 5 完を安定してとれるようにならないといけないか。

A

配列を問題文からのコピペでつくって出力するだけ。

B

1 WA だしてしまった。

基本的に h * w / 2 で、h * w が奇数なら +1でよい。

しかし、h か w が 1 の場合は例外になるのでこれを考慮する必要があった。

C

4 WA だしてしまった。

精度の問題にはしたくないので式変形して (c - a - b)² > 4ab の形にもっていく。

なんで WA 食らったかというと、c - a - b < 0 の場合を見落としていたから。

若干パニックになって必要のないところをいじってまた WA くらったりしてた。

D

全ての並び替えを出す要領で、1 文字目は{a}、2 文字目は {a,b}、3 文字目は {a,b,c} という感じの組み合わせを全列挙する。

このままでは条件に合わない組み合わせが含まれるので、一文字飛ばして新しい文字が出現するようなものはフィルタアウトする。

たとえば "aac" は 'b' を飛ばして 'c' が出現しているが、これは辞書順で出現済みなはずの "aab" が同値なので外さないといけない。

たぶんもっとスマートな方法があるとは思う。

ちなみに WA は入力を読み込み忘れたまま提出してしまったため。粗忽だ。

E

解法が思いつかず総当りっぽく解こうとしたが無事 TLE。

解説みるとやっぱり総当りだったが、自分の実装より時間がかからずになっていたのでまあそうなるか。

AtCoder Beginner Contest 157

Contest Result - AtCoder

今回は A から E までの 5 完。わりと調子良かった。

入水できるんじゃないかなと期待もしたが、思っていたよりレーティングは上がらなかった。 もう 2 回位は水パフォーマンスが必要そう。

A

n を 2 で割ったものに、n が奇数ならさらに 1 加算する。

B

愚直に 3x3 の2次元配列を作って、それがビンゴの条件を満たしているか確認する。

ちょっと実装がめんどいぐらい。

C

調べればいい範囲がたかだか 1000 以下だったので、総当りで条件にあっているものを探す。

こっちも愚直な実装になった。

D

Union Find 木を使って、グループ分けをする。

その後 1 から N までについて、グループのサイズから「直接の友人関係にある人数」と「グループ内でブロックしている人数」、「自分自身」の数を引く。 Union Find 木のテンプレートを持ってなかったので０から実装したがなんとか間に合った。テンプレ実装は用意しておいたほうが良さそう。

なお、自分はこれよりも E を先に解いていた。他にも同じような判断をした人はそこそこいるっぽい。

E

競技プログラミングでよくある発想の転換が要求される問題だと思う。

最初に考えた 2 個目のコマンドの「l 文字目から r 文字目までで含まれる文字種のカウント」は、愚直にやっていたら計算量が大きくなりそう。

最悪の場合は N x Q で 10¹⁰ かかるので、時間内に終わらないと判断した。

考えを変えて、ある文字が「l 文字目から r 文字目までで含まれる」かどうかを 26 回高速に判定できれば良さそう、と考えた。

なので 26 個アルファベットごとに std::set<ll> を用意して、出現位置を入れておく。

コマンド 1 は set への追加と削除で済ませて、コマンド 2 の方は l より大きい出現位置を lower_bound でとってそれが r 以下なら条件を満たすとしてそれぞれカウントすればよい。

int main() {
    ll n;
    cin >> n;
    string s;
    cin >> s;
    vector<set<ll>> d(26, set<ll>());
    for (ll i = 0; i < n ; ++i) {
        int c = s[i] - 'a';
        d[c].insert(i+1);
    }
    ll m;
    cin >> m;
    for (ll j = 0; j < m; ++j) {
        int com;
        cin >> com;
        if (com == 1) {
            ll i;
            int idx;
            char c;
            cin >> i >> c;
            idx = c - 'a';
            for (ll k = 0; k < 26; ++k) {
                d[k].erase(i);
            }
            d[idx].insert(i);
        } else {
            ll left, right;
            cin >> left >> right;
            ll count = 0;
            for (ll k = 0; k < 26; ++k) {
                auto iter = d[k].lower_bound(left);
                if (iter != d[k].end() && *iter <= right) {
                    ++count;
                }
            }
            cout << count << endl;
        }
    }
}

Object Oriented Conference 2020 参加してきたメモ

ooc.connpass.com

2/16 に行われた Object Oriented Conference に参加してきた。

OOC は名前の通り、「オブジェクト指向」についてのカンファレンス。 セッションは大小 34 あり、設計やアーキテクチャの話が多かったし、DDD も結構テーマに上げられてた。 CfP 倍率は 3 倍程度で結構応募があったらしい。

全体的には、キーノートでも言われていたが、多様性により OO といっても立場や考えが色々異なる視点からの話が聞けた。

以下聞いてきたセッションの話。

キーノート Object Oriented Diversity

OOC keynote: Object Oriented Diversity - Speaker Deck

OO が様々な意味を持つようになってしまい、 同じ OO の話をしていても行き違いが発生しやすくなってしまった。 ということで OO について話すときには「コンテキスト」を意識しましょうという話だった。

実際 OOP にしてもメッセージパッシングのことを OO と言っていたり、抽象データ型を使うことを OO と言ったりもするので、文脈を共有するのは大事そう。

DDD はオブジェクト指向言語でどのようにメンテナンス可能なコードを書くか

DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか

DDD の話。

• モデリングが重要
  • {ドメインエキスパートからの知識 → モデルに反映 → 運用からのフィードバック}の改善ループが重要
  • モデルの継続的な改善のためにも高い拡張性が必要
• 軽量 DDD でベストプラクティスを取り入れるのでも効果はある。そこからモデリングに進むと良い

• DDD を導入する際にはお手本となるコードを作ってから、それを参考にして残りをつくる、というやり方がおすすめ

• モデリング手法

  • 決まった方法はない
  • よく使われるのは
    • RDRA2.0
    • ユースケース駆動分析設計

ユースケース駆動のポイントとしては:

• ユースケース図 　- ユースケースの具体化・言語化
  • ドメインモデル図作成の範囲を狭める
• ドメインモデル図 　- メソッド不要・属性も代表的なものだけ
  • 業務の「ルール・制約」＝ドメイン知識を引き出しで記述する 　- 集約の範囲を明記すると良い

紹介されていた DomainLanguage.com https://domainlanguage.com/ はよくまとまっているし参考にしたい

数理的システム設計

ソフトウェアシステム設計における アレグザンダー理論の活用 数理的システム設計手法の提案 #agileto2019 - Speaker Deck

アーキテクチャ設計の話だが、ちょっとついていけなかった。

自分もアレキザンダーの本とかやっぱりちょっとは目を通してみるべきかも。

アジャイル時代のモデリング 平鍋健児

Modeling in the Agile Age

アジャイルでのモデリングの話。手法というよりもどうモデリングを続けていくかのプラクティスの話か。

紹介されていたアイディアとしては、モデルを作成した際に出来る図・資料を保存するもの = KEEPS とすぐ破棄するもの = TEMPS に分けると良いとのこと。

KEEPS にするものは価値を生み出すもの:

• アーキテクチャ
• ドメインモデル
• キーとなるユースケース
• 他、設計の理由(Architecture Descision Record) テスト戦略なども

TEMPS にするものはほとんど価値を産まないもの: - カジュアルモデリングの成果物 - クラス図、シーケンスダイアグラムなど

他に Impact Mapping というモデリング手法や C4 Model というものが紹介されていた。

「モジュールとしてのマイクロサービス」と「分割単位としてのドメイン」について考える

「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」について考える - Speaker Deck

システムをどのように分割するかの話。

• 複雑なものは分けて考える
• 重要な設計要素は、モジュール性とビジネスの関心事
• 人間のコミュニケーションを阻害しないようにシステムとチームを構成する
• 分散システムの難易度などの落とし穴に注意
• モノリスが常に不利益を生むわけではない
  • モジュラモノリスという内部的に分割を行うパターンも採用例がある
• MSA していてもフロントエンドがモノリス化してしまうことが多々ある
  • フロントエンドもモジュラモノリスにするとよい

オブジェクト思考プログラミングの過去・現在・未来

オブジェクト指向プログラミングの現在・過去・未来

OOP とはなにか？に対しては「データの抽象化」がそれに当たるという主張。 データ抽象により、語彙(ユビキタス言語か)、自己文書化、関心事の分離などできる。

後半は OOP の歴史の話。

黎明期から始まり、型を軽視や怪しげな例え話などによる混乱があったが、現在はその混乱が収束しつつある。

型がない言語で OOP できっこない、という話があったが、個人的にはちょっと反対したい。

AtCoder Beginner Contest 156

Contest Result - AtCoder

今回は A から D まで。ランクは少し上がった。

今回の問題では、組み合わせを高速に計算する手法は学習済みだったのが役に立った。

E は考え方は合っていたが時間がなくてコンテスト期間中に回答が間に合わなかったので悔しい思いをすることになってしまった(後日 AC 済み)。

特に「 r 個を n 部屋に 1 つ個以上ずつ分ける」というのがとっさに出てこなかったのが痛い。

ところで、E では k が 1 の場合には「すべての部屋に1個ずつある状態」が実現できないんじゃないかと思ったんだが、解説でも触れられてないし他の人のブログ記事でも触れているものがない。

そういうようにコードをいじっても AC になるのでなんかちょっとモヤモヤするなあ。

(追記) よく見たら問題分の方で k は 2 以上になっていた。問題文を微妙に見落としているのは良くない。