クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。

2025年5月25日
から hiruta
Obserivability Pipeline Query Language Session recap はコメントを受け付けていません

Obserivability Pipeline Query Language Session recap

KubeCon EU 2024 LondonのObjserivability Pipeline Query Language Sessionのre:capです。5/20 Kubernetes Meetup Tokyo Vo.70で話した内容です。

youtubeにセッション動画はすでに上がっています

Unix-based pipeline

入力のテキストファイルを処理するのに、使われている伝統的なパイプライン。現在でもログ処理なのに利用するケースがある

ログから、なんとかErrorを抽出してログ数をカウントするワンコマンドを、find、grep、sort、uniqをパイプで繋いでログ調査で利用する

Spunk Search Processing Language SPL

クエリを宣言的に記載できる。グラフなどUIで見やすい

Prometheus

Prometheousのメリットとしては、同じpromQLで時系列のデータ推移を確認できる。ContainerだとStatelessワークロードが大多数を占めるので、動いているContainerが次々変わるので、サーバーに依存するような監視では対応仕切れなくなると考える。

時系列データを取り扱う、pull型でアプリケーションから値を取得するので、Zabbixなどに比べて負荷になりにくい

ツールの乱立

Splunk、Sumo Logic、Datadog Log Explorer、Elastic ESQLの例を上げて、それぞれのクエリによって、検索オプションが異なっていて、ベンダーロックインになる問題がある。

SQL

SQLへの回帰。近年だと、非構造されていないデータにも

データウェアハウスではSQLで主流

SQLのメリット

PromQLに比べると順番、フィルタのフローを持たないといけないが、サブクエリ

標準化について

完璧な仕様で標準化することは適切ではない。Open Telmetryも優れた収集実績があってことから誕生した

SQLは50年使い続けている技術でもあり、今後も生き残る。構文が最終的にどうなるかはわからなく、可観測データにアクセスできる単一の言語が求められていると最後に話されてました。

2026年8月1日
から hiruta
Google Cloud Next Tokyo Day2 はコメントを受け付けていません

Google Cloud Next Tokyo Day2

Google Cloud Next Day2のメモになります。

基調講演

TPU、Axion、ストレージ、ネットワーク　Virgo NetworkまでAIワークロードで要求されるインフラが利用できる

Agent Platformに構成コンポーネントの話の中で、Agent RegistryがSkillをサポート、Model Armorが不正プロンプトをブロック

90%がダークデータ。そのままだと活用できていない。

Gov Tech 東京パートでは、災害時自治体サイトにはスパイクなリクエストが想定して、スケーラブルなインフラが求められる。Cloud Spanner

docomoパートでは、億レベルのデータからエージェントで個々のユーザへのマーケティングの活用をGemini Enterpriseで活用を進めている

最後に、セキュリティ。CodeMender

高度化する AI ワークロードを支える Google Cloud の AI インフラストラクチャ最新動向

GKE Inference Gateway、ClaudeなどのMaaSの基盤でも使われている。euリージョンが混んでいた場合は、usリージョンにルーティング。最近のClaude、globalモデルも提供していた

Pod Snapshot、ready になるまでfuse使った場合に比べて、1/5になる。Pod Snapshot自体はGCSにあるので、ノードがリプレースされた場合でも影響ない

BigQuery で始める AI エージェントのフィードバックループ

手順、検証済みクエリ、カスタム条件を入れることで正しく答えてくれる

Agent Runtime、GKE、Cloud Run Agentデプロイすべきか（G-genブースにて）

基調講演でも話していたが、Agent Registryに登録して、Gemini Enterpriseから利用するエージェントを利用するケースは、Agent Runtime。Cloud Runでも、Instance、Sandboxなり、エージェント実行できる環境は揃ってきている。Self-hosted LLMをデプロイするケースは。GKE、Cloud Run GPUになりそうな感じかな

AI の回答に責任を持てるか? LLM とナレッジグラフで実現する検証可能な意思決定

AI、もっともらしい回答をすることがある。結論に至るにはナレッジグラフでやれせることで、LLMは文書化することで回答の揺らぎが改善する

AI エージェント時代のクラウド インフラ設計ガイドラインの重要性

Cloud Run GPU で実現するゼロスケール AI 推論

Cloud Run GPUで使っているL4、NVIDIA RTX PRO 6000について

Cloud Run jobs、通常7日実行することができるが、GPU使うとservice同様上限1hに制限される

worker Poolsで推論必要な時にCloud Run GPUを呼び出す
Gemma 4 ModelにGCSに配置してCloud Run GPUが起動させる。GCSにおいて、SDKで取得するのが一番高速

Cloud Run GPU、cacheなり使っても、cold startは避けられないので、Worker poolsから非同期で必要な時に推論させるなりするパターンが一つの選択肢になりそう。

Cloud Run worker pools で実現する「運用負荷最小・コントロール最大・費用 90% 削減」の Pull 型メッセージング基盤

Push型、スパイク要件があると連携先に負荷がかかり、Cloud Run functionsがスパイクリクエスト分スケールするのでコストが激増する可能性もある。
また、Push型だとサブスクリプションに入れるところを止めないとメンテナンス時ロストしないように考慮しないといけない

Pull型だと送れる流量を制御可能
Pull型は常駐、バッチはコスト、24h絶え間なく送られてくるので課題がある。

Pull型、メッセージが送信されるまで順次処理されるので再開時とか時間かかることがある。

2026年7月30日
から hiruta
Google Cloud Next Tokyo Day1 はコメントを受け付けていません

Google Cloud Next Tokyo Day1

7/30、31、Google Cloudの基幹イベントであるGoogle Cloud Next Tokyoが開催される。7/30の基調講演、セッション、Developer Stage、ブースでのミニセッションのレポートになります

基調講演

AIエージェントは検証フェーズから本番フェーズに。TPU8t/8iのAIチップから実行基盤、モデルまでフルスタックAIでGoogle Cloudで利用できる。チャットベースはすでに過去の異物。自律型エージェントでどのツールを使うべきかセキュリティは最優先。データもAI ready

Gemini Enterpriseもデータレジデンスで国内対応。エージェント開発もローコードからADKまで揃えている

SREはAIに任せるべきか。ブレイドがDatadogで出した答え

クリティカルなアラートはメトリクス、トレース、ログみて、影響範囲調査とか一時対応手動だと大変

暗黙知をコンテキストに変える。スキルとかのルール化。ログ、メトリクス一元的にリードできないとエージェントで調査も難しい

調査エージェントを自作、SaaSのものを使うか、自作はかゆいところまで届くが、データが陳腐するとエージェントの回答にも影響あるので運用コストが高くなるので、適所適所で利用する

ソフトウェアの先へ: Anthropic が示す次世代エンタープライズ AI

最近OpenAIのテスト中のモデル閉じられた環境をでて外部のサイトにアクセスしたインシデントとかありますが、安全にAI利用するようにする取り込み

Opus 5、方向性を丁寧に案内する必要があったが、細かくマイクロマネージしない方がいい

コーディングでなく、周りの検証、レビュー、リーガル、セキュリティがボトルネックになってきている
計画より、PoC、レビューの拡充、コーディングより問題定義できるスキルセットの重要、組織のフラットなど業務ワークフローを変えていく必要がある

メルカリのグローバルアプリで挑んだAlloyDB運用と課題解決の実践記

既存DBを活かして類似検索ができる
ScaNNインデックス、Automatic index maintenanceの自動化
古いEmbeddingをバッチで削除

Read Poolを使うかPrimary選択するか意識しない実装
透過的にクエリを振り分けるインターフェースを用意。クエリに応じてルーティングする。

バッファプール暖気していないとパフォーマンス劣化するので投入前にウォームアップクエリを流す

Managed Connection Poolingに移行にするチップスが紹介された。

使いこなそう！VPC Service Control

どこからアクセスしているかでていくか制御はIAMだけでは難しい

境界でアクセス制御するサービスになる。

VPC Service Controlでサービス境界を設定
dry-runで大きな変更する場合の影響調査することを推奨

Agent Development Kit 2.0がGA！10分で新たな機能や仕組みを解説

ADK 2.x、宣言的にワークフロー実装できたり、より柔軟にプログラミングベース、Agentをscopeを制限できるようになっている

Dynamic workflows、多用するとコード可読性悪くなるので最小限にして、　Graph-base workflowsにすることがよさそう

スキーマにより、エージェント間のデータ入出力がしやすくなっている

A2UI

悪意のデータを送りつけても、A2UIだとデータに入力するデータを制限することで安全なエージェントを作るポイントになる

VPC Service Connectで実現する今どきのシンプルかつセキュアなサービス接続

VPC Service Connect、AWSだとVPC Lattice相当で接続エンドポイントだけでVPC間でセキュアで公開できる

PSC Subnetがサービス提供側にパケット入っていくと　Double NATで変換してサービス提供に流れていく

PSC SubnetのCIDRだけは被らないようにしないといけない

サービス提供側はNLBなりALBが必要になる。

PSC Endpoint、リージョナルリソースなのでリージョン障害等で通信できなくなる
PSC Backendで、サービス利用者でもLBでリージョン可用性を高めることができる。

PSC neg、ヘルスチェックがないが、Composite healthでリージョン障害を検知できる

Agent Runtimeから社内リソースにアクセスするとかのケースにPSC Interface PSC-I

AI開発ツールのエンタープライズ展開➖OpenTelmetryとGoogle Cloudで実現するトレーサビリティと可視化

LLMは確率論なので都度回答が異なることがある。従来とは別の方法で可観測性の仕組みが必要になる

オブザーバビリティは調査時間も速くなる。結果だけをレポートしてもらい、解決法だけ人間が確認できる。
AIエージェントの非定型な行動パターンには可観測性も重要

2026年7月19日
から hiruta
SRE NEXT Day2 はコメントを受け付けていません

SRE NEXT Day2

基調講演

デザイン、物のデザインから、中身がよくわからないものをどう目的するインタラクションデザイン、ユーザの体験をどうするかフォーカスに入ってきた

デザイン、理解しないと、本質的なものを作れない、SREでも仕様を理解しないと作り上げられないものに当てはまりそう

仮説を作って、確かめることをしない 基盤検討する場合もPoCなり、裏どりとかするプロセスにも当てはまりそう

サンプリングは統計学である: 数理的根拠に基づき、オブザーバビリティのコストと精度を両立する

母集団が偏りがあるのか均一性があるのか、どれくらいの誤差が発生するのか、ブレの範囲に95%入っているサンプリングの精度につながる サンプリング、長い間のウィンドウにすることで少ないサンプリングでも誤差少なくなる

しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践

サーバーインフラリソースに異常なくても、外部要因でクライアントでエラーになっていることがある。クライアントの環境に依存するケースにもなっているので原因特定が難しくなる

サーバーインフラリソースに異常なくても、外部要因でクライアントでエラーになっていることがある。クライアントの環境に依存するケースにもなっているので原因特定が難しく

End-to-Endで考える信頼性 — LINEアプリにおけるクライアント開発×SRE連携の実践

コンテンツキャッシュ切れて、サイトアクセスできない場合もキャッシュさせる 表示するキャッシュがない場合、ローカルに最低限のコンテンツを持つ fallbackコンテンツを表示する

Slido でQA取り上げてくれた内容になりますが、外部リソース取るケースもサーキットブレイカーで外部リソース取る際長く待たせるのではなく、トルツメするなりして応答レスポンス劣化を防ぐ工夫も。主要導線でなければトルツメされても問題ないケースもある

月間400万ジョブを支えるGitHub Actions self-hosted runnerの信頼性

大規模で運用しているSelf Hosted Runnerのジョブ、API rate limitとか、node poolのIO性能違うことでジョブ時間がばらけてしまった。node pool、キャッシュ持っていないケースもあると変更ありそう

2026年7月19日
から hiruta
AWS CDK Confernece 2026で、”cdk8sとhelm、どちらを選ぶべきか”のタイトルで登壇しました。 はコメントを受け付けていません

AWS CDK Confernece 2026で、”cdk8sとhelm、どちらを選ぶべきか”のタイトルで登壇しました。

2026年7月18日開催のcdk8sとhelm、どちらを選ぶべきか？のタイトルで登壇してきました。

AWS CDK Conferneceとのイベントの通り、AWS CDKを実際使っている知見、AWS CDKの深層に迫るセッションにいたるまで、濃い内容のイベントでした。オープンスペースで一時間ほど、AWS CDKの困りごとをライブQAで回答してくれるものもありました。

Q　L2 Consturcts使っていても、一部機能でAWS CDKのカスタムリソースを使うケースがありますが、カスタムリソースを使うと、Lambdaが作成される。LambdaのRuntimeはEOLを迎えるのでアップデートしてくださいと通知がくることがある。カスタムリソースのLambdaについてはユーザの守備範囲外なのであっぷでーとしていいか？

登壇のなかで触れたCDKのKubernetesManifestやHelmChartも、CloudFormationのカスタムリソース、つまりLambda（kubectlLayer)がつくられる。叩く先のAPIが、IPv4のみなので、IPv6 EKS Clusterの場合、Interface Endpointなりが必要になる。kubectlLayer、クラスタバージョンによって更新する必要がある。

A アップデートしてかまわない

Q CloudFormation Express Modeはバックグラウンドで安定化処理がされる。本番環境でつかっていいか

A 開発環境にとどめておいたほうがいい。　（セッションでもエラーになったとかで使わない話もありました）

登壇した内容について話したいとおもいます。

セッション”cdk8sとhelm、どちらを選択すべきか？”

発表では、Kubernetes マニフェストの運用する際のしずらさ、運用する上で非機能的なことをかんがえたり、マルチプロダクトで運用する場合は、ガバナンスも考える必要があることから、cdk8s、helmの特長、EKS環境で検証した構成、この際のポイントについて話しました。

CDK Conference初登壇

CfP経由のオフライン登壇は初の経験でした。なんとか最後まで成し遂げることができました。

実際検証環境で確認することからしたので、仕組みもより理解できたと思います。

2026年7月13日
から hiruta
SRE NEXT 2025 Day1 はコメントを受け付けていません

SRE NEXT 2025 Day1

Day1で気になったセッションについて感想

Reslilence Reliabiliy

    データセンターでサーバ群で構成されている。一部が故障しても、顧客に影響していない。すぐ対応しないといけないかの問いがあったが、目的が達成できているのであればいいとの話。Reslient

    ABEMAにおけるIncident Management再設計

    インシデントの仕組みはつくっても、だれかがよしなにしてしまう、振り返りがまわらない

    AI-native時代の信頼性を育てる、インシデント学習と改善ループの実践

    エラーの度に手動の対応で行っていた。表面的な改善のみでジリジリ根本な原因が悪化していってしまった 決済とか信頼性求められることもあるので共通SLOにしていると高いSLOを信頼性ここまで高くしないところも高くなってしまう

    PR単位で使い捨てるカイポケコネクトのpreview環境の設計と運用

    機能開発を加速、リリーストレイン方式だと環境占有とか課題、検証作業を分離並列化

    SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践例

    開発者は、コーディングからAIの出力を検証するところに移ってきた

    仕様駆動開発は仕様を固めるまで実装させるように強制させる

    AI活用でPRの限界。PRの廃止。モブプラグラミングの過程でリアルタイムレビュー

    低コストなログ基盤を支えるアーキテクチャ 〜Grafana Lokiの設計思想〜

    indexからオブジェクトストレージS3のchunkの場所を探して取ってくる。 chunkを全て読み込む必要がある。小さいインデックスすることでchunkを圧縮できるが、スキャン処理のcpuのトレードオフがある https://grafana.com/docs/loki/latest/community/design-documents/labels/

    カーディナリティ高いクエリはフルスキャンになり、Readerの負荷がたかまることがある。

    Loglineに今後全文検索とか期待できそう。

    AIと共生する開発者プラットフォーム：バクラクのモノレポ×マイクロサービス基盤

    どこまでデプロイできているかService consoleで一元で確認できるようにして認知負荷の削減

    datadog、GitHubとか個別に取得するより、Service consoleでコンテキスト集めてコンテキストトークン削減

    「ちゃんとやっている」は独りよがりだった ― 不安に寄り添うインシデント対応へ 

    経験者が実業務から抜けたあと、システム目線の指標でうまくまっているようにみえた、CSからの問い合わせでじつは顧客目線で対応されてないのでは。システム目線、情報共有、顧客へのフォロが後手で、システム目線の指標ではわからない課題があった。経験者はよしなにしていたルール以外のことももしていたも実業務担当者にはされていない。セキュリティを含め、インシデントは、今どんな状態か最終結果出る前でにCSとしては知りたいので、Communicationは大事と感じ、Day2のキーノートでも顧客目線で対応する重要性が語られたのでDay2に繋がるセッション

    2025年9月23日
    から hiruta
    作って学ぶFastly ComputeベースのリアルタイムアプリケーションとMCP入門 はコメントを受け付けていません

    作って学ぶFastly ComputeベースのリアルタイムアプリケーションとMCP入門

    Fastly

    認証をエッジでするメリットをDay1で聞いたのち、Day2で実際リアルタイムアプリケーションをfastly computeまでデプロイするまでワークショップを行いました。

    ユースケース

    ああYamagoya 2023 : 行動ログ収集API サーバの Fastly Compute 移行 ~ 高スケーラビリティ、高信頼性、高メンテナンス性を目指して ~

    日経のFastly Compute移行について メンテ負荷↓、トラフィック多いところでも使っている 設定ファイルは属人化からプログラムにすることでメンテナンス負荷さげる


    Yamagoya 2023 : パネルディスカッション 後編 「Climbers Talk: Fastly Compute の歩き方」

    QRコード生成はサーバー側で動的に生成 スパイクトラフィックがくるのでFastlyで幸せになったユースケース

    ワークショップ

    https://gist.github.com/remore/6e23a99ff06f754b0a881bc8493db0ca

    WebAssembly のファイルシステムアクセスの制限ももちろんあり

    SSE(Server-Sent-Events)とイベントソース

    イベント毎にリクエスト

    ブラウザではGETでstreamしますが、curl -X POSTをしてもリアルタイムにUTC（協定世界時）での1970年1月1日0時0分0秒から現在までの経過時間を永遠表示します。

    以下は応用課題でPOSTに対応させたコード。一部Claude Codeを利用

    addEventListener("fetch", event => event.respondWith(handleRequest(event)))

const htmlText = `
<html>
<body>
Latest message:<div id="main"></div>
<script>
class FetchEventSource {
  constructor(url, options = {}) {
    this.url = url;
    this.options = options;
    this.controller = null;
    this.onmessage = null;
    this.onerror = null;
    this.onopen = null;
  }

  async connect() {
    this.controller = new AbortController();

    try {
      const response = await fetch(this.url, {
        method: this.options.method || 'GET',
        headers: {
          'Accept': 'text/event-stream',
          'Cache-Control': 'no-cache',
          ...this.options.headers
        },
        body: this.options.body,
        signal: this.controller.signal
      });

      if (!response.ok) {
        throw new Error("HTTP " + response.status);
      }

      if (this.onopen) this.onopen();

      const reader = response.body.getReader();
      const decoder = new TextDecoder();
      let buffer = '';

      while (true) {
        const { done, value } = await reader.read();
        if (done) break;

        buffer += decoder.decode(value, { stream: true });
        const lines = buffer.split('\n');
        buffer = lines.pop() || '';

        let eventData = {};
        for (const line of lines) {
          if (line.trim() === '') {
            if (eventData.data !== undefined) {
              if (this.onmessage) {
                this.onmessage({ data: eventData.data });
              }
            }
            eventData = {};
          } else if (line.startsWith('data:')) {
            eventData.data = line.slice(5).trim();
          } else if (line.startsWith('event:')) {
            eventData.event = line.slice(6).trim();
          }
        }
      }
    } catch (error) {
      if (error.name !== 'AbortError' && this.onerror) {
        this.onerror(error);
      }
    }
  }

  close() {
    if (this.controller) {
      this.controller.abort();
    }
  }
}

const evtSource = new FetchEventSource("/stream");
evtSource.onmessage = (e) => {
  document.getElementById("main").innerHTML = e.data;
};
evtSource.connect();
</script>
</body>
</html>
`;

async function handleRequest(event) {
  const req = event.request;
  const url = new URL(req.url);
  if (url.pathname === "/stream") {
    const backendResponse = await fetch("https://fastly.com");
    const filteredStream = streamFilter(backendResponse.body);
    return new Response(filteredStream, {
      headers: new Headers({ "Content-Type": "text/event-stream" }),
    });
  } else {
    return new Response(htmlText, {
      headers: new Headers({ "Content-Type": "text/html; charset=utf-8" }),
    });
  }
}

function delay(ms) {
  return new Promise(function (resolve, reject) {
    setTimeout(resolve, ms);
  });
}

const streamFilter = (inputStream) => {
  const encoder = new TextEncoder();
  const inputReader = inputStream.getReader();
  return new ReadableStream({
    async pull(controller) {
      return inputReader.read().then(async ({value: chunk, done: readerDone}) => {
        await delay(2000);
        controller.enqueue(encoder.encode("event:message\ndata:"+Date.now()+"\n\n"));
        if (readerDone) {
          //controller.close();
        }
      });
    }
  });
}

    実行イメージ

    pushpinとfanout

    fanoutでリアルタイムで双方向するものを体験した。

    https://www.fastly.com/documentation/guides/concepts/real-time-messaging/fanout

    fanout機能はデフォルトで無効されています。このドキュメントだと30日のTrialで有効にして頂く必要あり。本日のワークショップではCustomer IDに対して有効にしてもらった。

    https://www.fastly.com/documentation/guides/concepts/real-time-messaging/fanout

    MCP Server

    MCP Serverを立てるだけならfanoutは無効で動く。

    https://www.fastly.com/blog/building-an-actually-secure-mcp-server-with-fastly-compute

    Delete Serviceしたと、再度fastly compute publishした場合、fastry.tomlのservice_idを空にしないとデプロイできない

    ローカルでMCP Serverのデバッグに有益なinspector

    https://github.com/modelcontextprotocol/inspector

    Fastly Computeにデプロイ後、Claude Codeに登録

    claude mcp add test-mcp-server -- uvx "mcp-proxy" "--transport" "streamablehttp" "https://xxxxxxxxxxxxx.edgecompute.app/mcp"

    2025年7月13日
    から hiruta
    SRE Next 2025 Day2 はコメントを受け付けていません

    SRE Next 2025 Day2

    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が入れ替わったりするので、レイテンシなどユーザ影響のある監視の重要性

    2025年7月12日
    から hiruta
    SRE Next 2025 Day1 はコメントを受け付けていません

    SRE Next 2025 Day1

    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削減→障害を減らすことが事業のも目的ではない

    2025年7月2日
    から hiruta
    やさしいMCP入門を読んでみて はコメントを受け付けていません

    やさしいMCP入門を読んでみて

    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