クラウドインフラ構築記

SRE Next 2025 Day 2 セッションメモ

すみずみまで暖かく照らすあなたの太陽でありたい

Yodobashi Cloud、開発者はアーキタイプを意識せず、Region/Multi-Regionalな構成でアプリケーションをデプロイされる。OSSミドルウェアの監視にZabbixを導入したが、監視オペレータがなじみ深い監視ツールで見れる工夫

アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化

アプリケーションの利用状況、イベントパターンによりピーク時期が変わる。今回の場合は確定申告の締め切り時期

CPU使用率でトリガーでHPAオートスケールするようにしたが、livenessProbe、ヘルスチェックでメモリ不足で失敗、サービスインのPod減、サービスイン中のPodに集中することでメモリ不足する悪循環に陥った。

リクエスト数でのトリガーにしておけば、リクエストの急増によるHPAに対応。GCの別要因でのメモリ意図せず解放されることもあるので、メモリトリガーは選択していなかったとのこと。GCだとCPUも上がるケースもある

150サービス連携を3人で運用する現場から ー 創業4ヶ月目におけるオブザーバビリティの実践

ログ監視だけでは、なにが、どこでなぜ起きているか、おきているか不明確

構造化ログ、トレースから関連したログを集約

SRE with AI：実践から学ぶ、運用課題解決と未来への展望

リクエストのトレースIDからNewrelic ログ情報を検索し、エラー原因を生成AIにまとめる

監査ログの異常、疑わしいアクティブティの分析

AWS EKS MCP Server、5xx多発したら、原因であるOMKilledを検出、CPU、Memoryの割当を調整まで行ってくれたとのこと

今はまだだが自律的にAI Agentが行動する時代がくる

大量配信システムにおけるSLOの実践 ：「見えない」信頼性をSLOで可視化

送信処理（リクエスト成功）の成功率、配信時間の達成率、リレー、SESリトライなど別要因による遅延もあるので、技術側面のSLOはとれるが、ユーザにどういう影響があるかわかりずらい

ユーザに配信が届いたか、遅延していないかのSLO

一つ一つの技術側面の成功率ではユーザにどういう影響があるかのビジネス観点のSLOを設定できないケース

Kubernetes で管理する大規模 Edge クラスタ: 200台のEVチャージャーの安定稼働を支える技術

armv7などcpu architecutureが混在するEdge DeviceにIoT Gatewayをデプロイする必要がある

Edge Deviceのmetricsをpullしてクラウド上のOpenTelemetry Collector経由でGMPに集めている

制約のあるデバイスにはnode-exporter podから収集

顧客の画像データをテラバイト単位で配信する画像サーバを WebP にした際に起こった課題とその対応策 ～継続的な取り組みを添えて～

画像変換の仕組み変える場合、ユーザ体験を損なわず、改善する工夫が必要

jpegなのに、webpとして配信しようとして表示しないなど想定しない問題も起こっていた

SREのためのeBPF活用ステップアップガイド

BCCをビルドするのに、LLVM/CLangのバージョンを指定することが推奨。12-15が安定してそう

プロセスがSIGKILLした場合のトレースポイントの原因分析

Memcacheの負荷試験時の調査

eBPF、低オーバーヘッドで高頻度トレースも性能影響最小でカーネル内部に安全にアクセスできるので、システムコール、メモリ、ネットワーク、ファイルIO監視によさそう

システム障害対応のツマミになる話

クラウドネイティブ技術、分散システムの障害対応の難しさ

あくまで障害対応は復旧ではなく、ユーザ影響の極小化が目的

クラウドの場合、クラウドプロバイダ起因でPodが入れ替わったりするので、レイテンシなどユーザ影響のある監視の重要性

Day1のセッションメモになります。

Fast by Friday: Making performance analysis fast and easy

月曜日　パフォーマンス

火曜日 問題のチェックリスト

水曜日 プロファイリング

木曜日 レイテンシ、ログ、クリティカルパス分析

金曜日 パフォーマンスエンジニアリング

https://www.oreilly.co.jp/books/9784814400072

https://www.brendangregg.com/Slides/eBPFSummit2023_FastByFriday

SRE へのサポートケースをAIに管理させる方法

少人数でSRE業務を回ししていると月100件の問い合わせでインフラ改善の工数に割り当てられない

問い合わせは、Toil

LLMはドメイン知識はもっていないので、VertexAI Agent Builder ( Gemini )で定型的な問い合わせはVertexAI Searchのデータソースに入っているドキュメントを検索、自動回答する仕組みの構築

定型的なタスクは減ることで、インフラ改善の工数に割り当てられるようになった。（時間がかかるタスクのため、総時間は減ってはいない）

今後Agent、MCPにも取り組んでいくとのこと

クラウド開発の舞台裏とSRE文化の醸成

ガバメントクラウド認定のためには、デジタル庁からの要求を満たす必要がある

業務上個人情報が扱われるのでセキュリティ、ガバナンスは重視されている

IAM、リソースからの権限管理は実装されるとのこと

オフィスビルを監視しよう：フィジカル×デジタルにまたがるSLI/SLO設計と運用の難しさ

QRでゲート認証する場合、映り込んでいるQRで永遠認証されないことがおこりうる

ものの監視でも、CUJ、ユーザ体験の整理が求められる

認証カメラ自体の監視は一定期間ハートビートを飛ばし届かないときにアラートする。（SRE NEXTで提供しているWi-FIのモニタリングも一時的にとどかないことがあるよう）

100% AI コード生成開発！ AI Agent 時代の信頼性と開発効率のためのガードレール

事前に作りたいものを与えることがポイントになる

AIが作ってきたコードはエラー、再度修正、エラーとオーバーヘッドになる。Vibe Codingでも要求使用をinstructionsに与えないと、全然違うものをつくってしまう。

エラーを気づけるようにしたいので、MCPなり利用

サービス連携の“謎解き”を可能にする Datadogによる分散トレース導入の一歩

サービス間で、trace idを連携するには、tracerのInject、Extractを利用

モニタリング統一への道のり – 分散モニタリングツール統合のためのオブザーバビリティプロジェクト

18:00からのアンカンファレンスでも議論になりましたが、監視ツールがバラバラだとそれぞれの監視している指標が違う、統一されていないとシステムの一環した監視ができない課題

対話型音声AIアプリケーションの信頼性向上の取り組み ~ Webアプリケーション以外でどうSREを実践するのか ~

インプットに対するアウトプット。タスクを細分化する工夫

WebSocketはTaskが入れ替わってしまうと通話が切断する問題があるので、drainingを伸ばす

音声アプリケーションのCUJは定量化しにくい

会話できたかどうかがユーザ体験。Trackingすることで指標化

〜『世界中の家族のこころのインフラ』を目指して”次の10年”へ〜 SREが導いたグローバルサービスの信頼性向上戦略とその舞台裏

S3は東京リージョンにあると、署名付URLを発行して画像を表示すると東京リージョンへのアクセスが発生するので海外からだとレイテンシーが高くなりユーザ体験がわるくなる

現に、Cloud Runのカスタムドメイン、カスタムドメインのホスティングがUSにあるため、東京リージョンなど特定リージョンのレイテンシが劣化することがあるので、全世界からアクセスされるアプリケーションでは世界上のユーザ体験を平等にするのは苦労がありそう

キャッシュすることでアクセスする対策

Route53 Latency base routing

Amazon CloudFront Origin Shield

システムから事業へ 〜SREが描く“その先”のキャリア〜

SRE＝事業価値の最大化に責任を負う役割、例えば、Toil削減→障害を減らすことが事業のも目的ではない

7月1日に、みのるんの二冊目の新刊が発売になりました。AWS Documentation MCP Serverなり、MCPと言っても、「Microsoft Certified Professional」ではなく、Anthropicが提唱したLLMにコンテキストを提供する標準プロトコルのことです。Amazon のランキングだと、Microsoft Certified Professionalのカテゴリに謎にランキングしいたりします

想定読者

概要とかAIエージェント、Tool Use、MCPが解決される課題から詳しく書かれているので、使っている人はもちろん、最初の一歩を踏む方にも読み進められとおもわれます

MCPの仕組み

2025/3に出たばかりのStreamable HTTPについても触れられており、原稿提出ぎりぎりまでアップデート盛り込んでいるので、最新の仕様についても理解できます

AWS Summit のCommunity Stageでもみのるんの話でもありましたが、人気すぎて聞けなかった人もいると思いますが、MCP Server、Serverだけどローカルで動くケースもあります。

MCPを実際にさわってみよう

WindowsOS使っている方もいると思いますが、WindowsOSの場合、WSL2でないとうまくいかないケースがあります

MCP Client

メジャなクライアントについて紹介されています

Strands AgentsもMCPを扱うことは可能です。Strands Agentsからmcp-imagen-goのローカルMCP Serverを介して、Imagenでイメージ生成させるなど、LLMからo3なり、別なLLMに仕事を渡すなど汎用的に利用できる可能性をもっています

セキュリティ

PayPalでもMCP Server提供されていますが、Sandbox環境を用意してローカルMCP Serverで試す必要はある。決済だと取り扱いには要注意

アクセストークンそMCP Serverの環境変数に食わせる必要の場合、アクセストークンの管理は厳重にすべき。

Aurora DSQLにアクセスするMCP ServerもAWSから公開されていますが、writeする場合はデータベースの内容消えたとかなるまえに与える権限はAWSのベストプラクティスでも言われていますが、最小権限にしておくのが無難です。MCP Serverにアクセスする場合、Auto approveしなければ、確認は聞いてきますが

MCPとA2A

MCPは、Toolとのやりとりなので、AgentとAgentを協調させたいケースは、A2Aになりそう。A2Aは、Linux Fundationに寄贈されたので、ベンダーフリー規格として利用できる

https://developers.googleblog.com/ja/google-cloud-donates-a2a-to-linux-foundation

NotebookLMで文字起こししたものになります。

AWS re:Invent 2024 キーノート詳細ブリーフィング

主題： AWSの技術革新の深層とその基盤にある文化

重要なアイデアと事実：

1. AWSの差別化要因： AWSは、カスタムシリコン、カスタムハイパーバイザー、データベース技術など、長期的な技術投資によって、クラウドコンピューティングの重要な属性を実現しています。

• “これらは単にローンチできる機能ではありません。これらはサービスに設計する必要があるものです。”

1. リーダーシップの重要性： AWSのリーダーは詳細にこだわることで、顧客のニーズを深く理解し、迅速な意思決定を可能にしています。

• “詳細を知ることで、顧客とサービスの現状を把握できます。そして、それは迅速な意思決定を可能にし、問題が発生する前に修正または予防することを可能にします。”

1. AWS Nitro System： Nitro Systemはサーバーアーキテクチャを再定義し、クラウドの構築とセキュリティ保護の方法を変革しました。

• “Nitroはセキュリティを向上させるだけでなく、ハードウェアサプライチェーンの完全性に対する私たちのアプローチに革命をもたらしました。”

1. Gravitonプロセッサ： Gravitonは、AWSがシリコンレベルで革新を起こした最初の例であり、各世代でパフォーマンスが向上しています。

• “Graviton 4は、クラウドでプロセッサを構築することについて学んできたことの集大成であり、これまでで最も強力なチップです。”

1. ストレージの分離： コンピューティングとストレージの分離により、AWSはストレージシステムの密度と管理能力の限界を克服しました。

• “コンピューティングとストレージを切り離すことで、クラウド環境で期待される高いパフォーマンスを維持しながら、回復力のあるコンポーネントを個別に拡張することができます。”

1. AIにおけるイノベーション： AWSは、AIモデルのトレーニングと推論の両方のワークロードに対応するために、TriniumやNeuronLinkなどの革新的なハードウェアとソフトウェアを開発しました。

• “Triniumは、AIワークロード向けに最適化されたシストリックアレイアーキテクチャを採用しており、従来のハードウェアアーキテクチャに比べて優位性があります。”

1. スケールアウトインフラストラクチャ： AWSは、大規模なAIクラスターを構築および運用するために、高性能で弾力性のあるネットワークファブリックとルーティングプロトコルを開発しました。

• “10 P 10 Uネットワークは、10ペタビット/秒の規模と、10マイクロ秒未満のレイテンシーで数百万台のサーバーに接続できる、最も高速で回復力のあるネットワークファブリックです。”

1. AWSの文化： AWSの文化は、セキュリティ、運用パフォーマンス、コスト、イノベーションへの揺るぎないフォーカスを維持しながら、スケールアップを可能にする重要な要素です。

• “文化とは、持っているか持っていないかのどちらかです。そして、もし持っていなければ、それを手に入れるのは難しいでしょう。”

結論：

AWS re:Invent 2024のキーノートは、スタック全体にわたるAWSの技術革新の深さと、顧客に比類のないサービスを提供するというコミットメントを強調しました。詳細へのこだわり、長期的なビジョン、継続的なイノベーションへの飽くなき探求は、AWSをクラウドコンピューティングのリーダーとしての地位に押し上げています。

引用: 上記の重要なアイデアと事実の箇条書きに、原文からの引用を含めました。

9/25 のランチ時間に、WebAssembly workloadをEKSで動かす話をしました。

スライド

ポイント

WebAssemblyは高速な処理、セキュリティが特徴であり、Fastly のCompute@Edgeなどでも利用できる。

WebAssemblyについて、tokioのwasm forkであるtokio_wasiがあるが、　full機能はつかえない。

AWS SDK for Rustも、依存関係として、tokio full featureが必要なので、wasmとしてはつかえない。

EKSで動かすための準備

containerd-shim-wasmedgeを組み込んだWorker nodeが必要。bottlerocket、Fargate Profileではサポートなし

10/5 Japan Azure User Group 14周年でAzure Verified ModulesのLTについて話されていたのを聞いて、Azure Container AppsをAzure Verified Modulesで作成してみました。

当日のAVMのセッションは公開されているようです

Bicepのコード

• main.bicep

targetScope = 'subscription'

@maxLength(7)

@description('Optional. The location to deploy resources to.')
param location string

resource coreResourceGroup 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'xxxx'
  location: location
}

module workspace 'br/public:avm/res/operational-insights/workspace:0.7.0' = {
  scope: coreResourceGroup
  name: 'workspaceDeployment'
  params: {
    name: 'workspaceProperty'
  }
}

module managedEnvironment 'br/public:avm/res/app/managed-environment:0.8.0' = {
  scope: coreResourceGroup
  name: 'managedEnvironmentDeployment'
  params: {
    // Required parameters
    logAnalyticsWorkspaceResourceId: workspace.outputs.resourceId
    name: 'amemin001'
    zoneRedundant: false
  }
}

module containerApp 'br/public:avm/res/app/container-app:0.11.0' = {
  scope: coreResourceGroup
  name: 'containerAppDeployment'
  params: {
    // Required parameters
    containers: [
      {
        image: 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'
        name: 'simple-hello-world-container'
        resources: {
          cpu: '0.25'
          memory: '0.5Gi'
        }
      }
    ]
    environmentResourceId: managedEnvironment.outputs.resourceId
    name: 'acamin001'
    location: location
  }
}

• parameter.json

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
      "location": {
        "value": "eastus"
      }
    }
}

container appsを動かすmanaged environment作る際、zoneRedundantパラメータ指定しないと、managed environment作成時にエラーになります。（InfrastructureSubnetIdが指定ないとzoneRedundantは有効にできない）

AVMデフォルトオプションがAzureの推奨設定になっていることなので、zoneRedundantがデフォルト有効ではと思われる。

途中でエラーになっても、作成できたリソースがCfnみたくロールバックすることはできなそう。Cfnでもロールバックしないオプションも対応しましたが。

実行

az

az deployment sub create --location 'australiaeast' --name 'lab01' --template-file main.bicep' --parameters parameters.json --verbose

テンプレートとパラメータを指定することもできます

リファレンス

Lab 01 – Demo: Deploying a Storage Account + Customer Managed Key Solution Using AVM modules published in the Public Bicep Registry

https://github.com/Azure-Samples/avm-bicep-labs/tree/main/labs/lab01

Azure Verified Modules

https://azure.github.io/Azure-Verified-Modules

主に、サーバレスな実行環境の話について

Day1でセッションと良かったポイント

WebAssemblyを使ったサーバレス開発の基礎の実践

https://qiita.com/remore/items/230453682b7964993f11

Cloudflare workers、Fastly Compute、CRIなどWebAssembly workloadがブラウザで動かす環境がふえてきていており、まだSocketなど未実装使えない機能もありますが、今後期待が高まると思う点

LLM Workloadでも使えるLlamaEdgeもあります。

Cloud Runで作るサーバレスアーキテクチャ三十連発

サービスメッシュ対応、GPU、DirectVPC Egressなど進化が激しい30アーキテクチャの紹介

Cloud RunからのVPCの中のリソースにつなげるには Severless VPC Connectorはスケールインしない仕様もあり、DirectVPC Egressをまず検討するのがよさそう

Global LB の下にServerless Network Enndpointをつなげる場合、default urlを無効にすることも

ghs.googlehosted.com でカスタムドメイン使う場合、東京リージョンのレイテンシー、東京・US間のレイテンシーが発生することもあり、Firebase App Hosting使うのがよさそう

Cloud service meshでCloud Run入れる場合は、Envoyが必要。Traffic DirectorでgRPCだとenvoy lessにすることもできたが、現状対応しない

Cloud Storage FUSEは、最近のGPUサポートで、LLM Worklaodを配信できるケース、モデルはイメージの外におきたいケースに有益

HTTP/2にも対応している。ラージファイルのアップロードとかにも使える

Agent BuilderからOpenAPIで、Cloud Runに処理内容を呼び出すこともできる。

AWS Lambdaを支える技術（Lambdaのunder the hood）

Cell base architecureでLambdaの実行基盤がつくられており、マルチテナントで使われる基盤なので、ワークロードの影響、障害時の範囲が最小化するシャッフルShardingまではなされていました

LWAを活用する新しいサーバレスの実装パターン

最初はLambdaで導入できても、ビジネスが拡大してきて、別のワークロードに載せ替えしやすさ、オーバーヘッドもないとのことで試してみたいかな

サーバレスAPIのパフォーマンステストとアプリの未来

curlでもAPI Testerは使えますが、属人化されてしまう

Postman、API Testerだけでなく、テスト、ドキュメント、後日ワークショップで体験したPostman FlowなどAPI Platformとしての製品

PostmanのランプアップでLoad Testのジャンルの多さがあることがわかった。

生成AIによる新しいUI/UX～サーバレスで実現するGeneratrive UIの世界～

生成AIの場合、LLMから応答を待っていたら、時間を待たされる。(Response Streaming )

Markdown形式でスライド内容をLLMから返して、スライドを自動生成

https://zenn.dev/oyashiro846/articles/0deab8230432a5

構成図書くのによく使っているdrawioは実体はXMLなので、XMLとして生成できれば構成図の生成もおこなってくれそう

開発体験が向上するチップスがたくさん

試してみたいこと

WebAssembly workloadも走ることができるFastly Computeも開発者向けの無料プランもあるのでつかってみたいかな

LWAなどポータビリティの高い実装

ServerlessDays Day2にて、5ワークショップに分かれてサーバーレス製品を実際手を動かして試しました。

Momento topic、Postman flows、Cloudflare workers、TiDBでEDAアーキテクチャを作成、S3に上げたファイルがTiDBに投入まで確認するワークショップに参加しました。

Workshop内容

構成

Postman flowsは、USリージョン、TiDBはAWS us-east1

今回の構成では、Smart placementでCloudflare workersはUSリージョンでうごいていると思われる。

実際行って詰まったところ

S3のEventBridge からの通知がデフォルトオフなのに気づかず、Momento 側に送られてなかった

PostmanのCollectionsのリクエストがデフォルト保存されないので保存しないといけない

Auto Save機能があるとのこと（BETA）

PostmanのFlowの結合が、繋がってくれないことがあった。

Postmanのログの出し方

コンポーネントについて

• Momento webhook

Momento webhookは一回は送信するが、再度送信する必要があるが、EventBridgeのRetryで対応できるか

Momento will attempt to deliver an event to your webhook one time. If an event is not received by your endpoint, the publisher is required to send the message again.

https://docs.momentohq.com/topics/webhooks/overview

• Cloudflare workers

isolatesの仕組みがあり、LambdaとかだとCold startに悩まされることはありますが、Cold startがないとされている。

V8 ↗ orchestrates isolates: lightweight contexts that provide your code with variables it can access and a safe environment to be executed within. You could even consider an isolate a sandbox for your function to run in.

https://developers.cloudflare.com/workers/reference/how-workers-works

• Postman flows

ノーコードでフローが作れて便利と思いました。

EventBridgeからMomento topicはRetryはあるが、Momento topicからPostman flowはflow内でエラーになったか知る必要はありそう

https://community.postman.com/t/retry-a-failing-request/5934/22?page=2

• TiDB

Connection Stringを払い出して、WorkerのConnectionに設定することで接続できてしまう

パブリックなエンドポイントでしたが、PrivateLinkにも対応している

https://docs.pingcap.com/ja/tidbcloud/set-up-private-endpoint-connections

まとめ

Momento topic、Postman flowの連携する方法について一通り理解することができました。

SRE Next Day1で聞いたセッションのメモになります

Reliable Systems through Platform Engineering

Becoming SRE – SREって何から始めればいいの？

Managing OS Lifecycle: A Deterministic Approach

We’ll be talking today about Managing life cycle of the operating systems in a deterministic way.

Imagine resolving all the dependencies for packages downloading. All of these packages and deploying them onto the host would take enormous amount of time. What we are proposing is changing to this mechanism which sudendra is going to work.

日本最大口座数を保有するSBI証券のAWSマイグレーションを支えたサービスとソリューション