クラウドインフラ構築記

現在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年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

    2024年12月3日
    から hiruta
    Monday Night Live Keynote with Peter DeSantis はコメントを受け付けていません

    Monday Night Live Keynote with Peter DeSantis

    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をクラウドコンピューティングのリーダーとしての地位に押し上げています。

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

    2024年10月7日
    から hiruta
    WebAssembly workloadをEKSで実行させる話をしました はコメントを受け付けていません

    WebAssembly workloadをEKSで実行させる話をしました

    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ではサポートなし

    2024年10月6日
    から hiruta
    Azure Verified Modulesで、Azure Container Appsを作成してみました。 はコメントを受け付けていません

    Azure Verified Modulesで、Azure Container Appsを作成してみました。

    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

    2024年9月23日
    から hiruta
    ServerlessDays Day1に参加しました はコメントを受け付けていません

    ServerlessDays Day1に参加しました

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

    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などポータビリティの高い実装