jedipunkz 🚀 です 👋

自分は Platform Enabler/SRE として従事しています。また AI 関連のアップデートは2025年に入っても属に更新されています。2025年初頭においては自分たちの分野でも AI 関連の利用に関して様々な模索がある状況だと思われますが、Ahthoropic 社が提唱した MCP (Model Context Protocol) がもたらすインパクトはアプリケーションに限定されずインフラ領域のソフトウェアにも大きなメリットをもたらすと思って観測しています。 この記事では、MCP の概要とどう実装するのかの学習、またどう我々のような Platform Enabler/SRE にとっての活用例があるかを考察していきたいと思っています。 MCP の概要 MCP (Model Context Protocol) は、AI モデルと外部システム間のやり取りを効率化するプロトコルで JSON-RPC でやりとりします。ユーザーの自然言語入力を基に、AI アシスタントが MCP サーバーを通じてファイル操作やデータ処理を実行します。 最近 OpenAI 社もこの Anthropic 社の MCP をサポートするというニュースが流れ、途端に注目を集める状況になってきました。 処理の流れ ここはあくまでの一例です。Assistant の実装でいかようにも出来ると思います。 +-------------+ +-----------+ +------------+ +--------+ | User Prompt | <-----> | Assistant | ---> | MCP Server | | AI API | +-------------+ (1),(5) +-----------+ (3) +------------+ +--------+ | ^ | (2),(4) | +----------------------------------+ (1) ユーザからの入力を Assistant が受け取る (2) Assistant はユーザからの自然言語を LLM に問い合わせ。その際に LLM に外部機能を定義 (JSON-RPC(MCP サーバが受け取る)) (3) Aasistant は MCP Server に JSON-RPC でクエリ送信しレスポンスを得る (4) Assistant は MCP Server から得たレスポンスを再び LLM に送信し自然言語としてユーザに返す内容を生成してもらう (5) Assistant はユーザに自然言語で結果を応答する 前提 MCP 学習を目的にしているので、ここでは話を簡潔にするため Linux Filesystem を操作する MCP Server を書き、理解していきます。 ...

jedipunkz です。VPC Lattice が ECS に対応したという情報が https://aws.amazon.com/jp/about-aws/whats-new/2024/11/amazon-vpc-lattice-elastic-container-service/ にあがりました。この対応を Terraform を使って構成して検証してみるのが今回の目的になります。 今回検証で用いたコード 検証コードは下記に置いておきました。 https://github.com/jedipunkz/vpclattice-ecs-playground 概要 構成の概要としては下記です。(Mermaid 記表でうまく描けていませんが) VPC1, VPC2 に跨る形で VPC Lattice Service Network が配置 VPC2 上の何者か (例で EC2) が VPC1 上の ECS に接続可能 その際は VPC Service Network を介して VPC Lattice Service がエンドポイントとして受ける (うまく描けてない) という事は今まで複数の VPC 間で ECS のエンドポイントを共有しようとすると VPC1, VPC2 とで VPC Peering を張る VPC1 上の Private Subnets 上で ALB を構築して ECS Service に接続する という構成が必要でしたが、VPC Lattice を使えばそれらが不要になる、という事です。 今回検証した構成 今回使った Terraform コードで構築した構成は下記です。各 AWS リソースの関係図になっています。 特徴としては ...

OpenTelemetry を使って AWS (X-Ray, Cloudwatch Logs) にトレースとログを計装する事に興味があったので調べた内容を記そうと思います。 構成 今回検証してみた構成は下記の様な構成です。AWS を用いた場合 ECS や EKS, Lambda で Go アプリを起動する事が通常ですが、今回は docker-compose で検証しました。ただ ECS, EKS に置き換えるのは比較的簡単だと思います。 trace post PutTelemetryRecords +--------+ +----------------+ +-----------------+ | Go App | -+-> | Otel Collector | ---> | AWS X-Ray | +--------+ | +----------------+ +-----------------+ | +----------------+ +-----------------+ +-> | Fluent-Bit | ---> | Cloudwatch Logs | +----------------+ +-----------------+ PutLogEvents ログとトレースの紐づけ ログは Cloudwatch Logs へ、トレース情報は AWS X-Ray へ転送しますが、このログとトレースを紐付けると、運用する上で追跡が容易になります。この紐づけは AWS の場合は簡単で下記の要件を満たせば紐づけがされます。 ...

自宅のルータについても可観測性を向上して普段の運用に役立てています。例えば長期スパンでのネットワーク通信料の推移や CPU, Mem 使用率、あとハードウェアの温度の推移などを観測しています。 今までは Prometheus の Node Exporter を使ってホストの情報を Prometheus Server に提供していたのですが、自分で Go で Prometheus Exporter を書いて運用するにようになったので、それについてまとめます。 Grafana の可視化情報 下記が可視化された情報です。CPU, Mem やネットワーク送信量、またハードウェアの温度を可視化して運用しています。 ソース置き場 結論になりますが下記にソースを置いています。 https://github.com/jedipunkz/linux-tiny-exporter ネットワーク送信・受信メトリクスを説明 実際にはこのコードでは CPU 使用率, Memory 使用率, Disk IO, Network トラヒック, ハードウェア温度を取得・提供しているのですが、ここでは例としてネットワークトラヒックに関するメトリクスを Prometheus Server に提供するコードを説明しようと思います。 パッケージのインポート Prometheus のクライアントライブラリから2つのパッケージをインポートしています。 “github.com/prometheus/client_golang/prometheus”: これは Prometheus の基本的なクライアントライブラリで、メトリクスを定義、収集、エクスポートするための機能を提供します。 “github.com/prometheus/client_golang/prometheus/promhttp”: これは Prometheus の HTTP サーバーとクライアントのためのライブラリで、HTTP 経由でメトリクスを公開するためのハンドラを提供します。 "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promhttp" ネットワークトラヒックに関する構造体定義 ここからは Internal Packege のコード解説です。 NetCollector という構造体が定義しています。この構造体は、ネットワークインターフェースごとの受信バイト数、送信バイト数、受信パケット数、送信パケット数の差分を保持します。~Diff はそれぞれの値の差分を保持します。前回のスクレイプ（データ収集）からの変化を表します。 type NetCollector struct { receivedBytesDiff *prometheus.Desc transmitBytesDiff *prometheus.Desc receivedPacketsDiff *prometheus.Desc transmitPacketsDiff *prometheus.Desc lastReceivedBytes map[string]float64 lastTransmitBytes map[string]float64 lastReceivedPackets map[string]float64 lastTransmitPackets map[string]float64 } コンストラクタ NewNetCollector 関数は、新しい NetCollector インスタンスを作成します。この関数では、各メトリクスの差分を表す prometheus.Desc オブジェクトを作成し、それらを NetCollector 構造体の対応するフィールドに設定します。また、前回のスクレイプ時の各メトリクスの値を保持するマップも作成します。 ...

@jedipunkz です。今まで自宅では PPPoE 接続をして Global IPv4 アドレスを取得して自宅にマイクラサーバーを外部公開しその接続を使って各端末でオンラインゲームやインターネットをしていました。ただ、IPoE 接続すると混雑時間を回避出来ると聞いていたので (これについては後術します)、普段のゲームや各端末のインターネット接続は IPoE 接続を利用しマイクラサーバーは PPPoE で公開、と出来ないかと考えました。IPoE は IPv4 over IPv6 のトンネリング接続するたため IPoE だけでは IPv4 Global IP アドレスによるサーバー公開は不可能だからです。 ここでは VyOS を使ってその両者を満たす接続の設定方法を記します。 要件 PPPoE して Global IPv4 を取得しサーバーを外部に提供 (その際に Dynamic DNS を利用 (自宅は Cloudflare)) サーバー以外の端末のトラヒックは IPoE 接続した経路に流す 回線はNTT フレッツ想定 (自分の場合は Asahi-net, IPv6 接続オプションあり, その他でも可) ISO イメージをビルド VyOS は Stable のバージョンは有償バージョンでないとダウンロード出来ませんがビルドすれば ISO イメージが作れます。その方法を記します。 2023/12 時点で最新の Stable バージョン 1.3.4 を指定 適当な Linux 端末でビルドしましたが Docker を利用できればどこでも良さそう git clone -b equuleus https://github.com/vyos/vyos-build cd vyos-build/ docker run --rm -it --privileged -v $(pwd):/vyos -w /vyos vyos/vyos-build:equuleus bash ./configure --architecture amd64 --build-type release --version 1.3.4 sudo make iso ビルドが完了すると build/ ディレクトリ配下に iso イメージが出来上がっているはずです。 ...

こんにちは。jedipunkz です。 今回は、kubectl プラグインを開発したことがなかったので、Go の学習と合わせてためしに1つ作ってみたのでその内容を記したいと思います。 開発した kubectl plugin: kubectl-fuzzy-login 下記が今回開発した kubectl プラグインです。 https://github.com/jedipunkz/kubectl-fuzzy-login 何が出来るか 下記のキャプチャをご覧頂くと一目瞭然だと思います。 Kubernetes のポッドとコンテナをインクリメンタルサーチしつつ選択し、最終的にコンテナにログイン出来るプラグインになっています。コンテナがサイドカー構成になっていた場合は、そのうちのどのコンテナにログインするかもインクリメンタルサーチ出来ます。なお、このプラグインは Go で開発しました。 インストール方法 Krew を利用している場合は下記の操作でインストールできます。Krew が事前にインストールされている必要があります。 git clone https://github.com/jedipunkz/kubectl-fuzzy-login.git kubectl krew install --manifest=./kubectl-fuzzy-login/krew/fuzzy-login.yaml マニュアル操作でインストールする場合は下記です。 git clone https://github.com/jedipunkz/kubectl-fuzzy-login.git cd kubectl-fuzzy-login go build cp kubectl-fuzzy-login /your/bin/path 使用方法 オプション無しで、全 Namespaces を対象に検索・ログインする オプションを使用しない場合は下記のように実行します。 kubectl fuzzy login まず Pod を選択します。Pod 名の一部を入力することでインクリメンタル・ファジー検索出来ます。その Pod に複数のコンテナ (サイドカー) がある場合、更にコンテナをインクリメンタルサーチ出来ます。最終的にコンテナを選択し Enter ボタンを押すことでコンテナにログイン出来ます。ただしコンテナイメージにシェルが入っていない場合は入ることが出来ません。 シェル指定 また下記のように -s オプションでデフォルトのシェルを指定することもできます。 kubectl fuzzy login -s /bin/bash Namespace 指定 Namespace を -n オプションで指定することもできます。 ...

こんにちは。jedipunkz🚀 です。 以前こちらの PipeCD 検証の記事 で Progressive Deliver について調査したのですが、Kubernetes でこの Progressive Delivery を実現する方法を調べておきたいなと思って手元の Macbook 上で検証してみたのでその際の手順を記そうかと思います。 Progressive Delivery の概要 ここで概要だけ記しておきます。Canary リリースは新しいデプロイメントをある程度の割合だけリリースし、徐々にリリースを進行させるデプロイ方式ということはご存知だと思いますが、Progressive Delivery はその過程で 新しいデプロイメントの統計情報を得る 予め定義したデプロイ成功定義に対して条件満たしているかを過程毎にチェックする チェック OK であれば次の過程にデプロイを進める 予め定義した幾つかのデプロイ過程を全て終えるとデプロイ完了となる というステップを経ます。 用いるソフトウェア Kubernetes で Progressive Delivery を実現するには下記のソフトウェアを用いる事が可能です。 また今回の手順は MacOS を前提に記します。 Argo Rollouts Prometheus Istio Kubernetes (今回は Minikube を使いました) 事前の準備 Istio Istio をダウンロードします。 curl -L https://istio.io/downloadIstio | ISTIO_VERSION=17.2 sh - Istio を Minikube にデプロイします。 cd istio-17.2 istioctl install --set profile=demo -y Kubernetes Namespace default で起動した Pod が自動的に Envoy サイドカーを取得するように設定します。 ...

こんにちは @jedipunkz 🚀 です。 普段仕事で AWS ECS を使っていて Autoscallng Group によってアプリケーションを据えケールさせて運用していますが、運用している中でより高速にオートスケール出来ないものだろうか？と思うシチュエーションが何回か発生し、対応方法について模索していました。 実際に発生したシチュエーション 下記はコンテナ毎の CPU 使用率です。1分未満の間に急激にアクセスが増えコンテナの CPU 使用率が 100% に達し (実際には vCPU に基づいて 200% となっている)、ECS Service のヘルスチェックに Fail して、コンテナが落ち、新しいコンテナは起動するものの、アクセス不可に耐えられず、コンテナ停止と起動を繰り返すといった状況でした。 Autoscaling Policy, Cloudwatch Metrics Alarm の調整 まず最初に考えたのが下記の値の調整です。 aws_app_autoscaling_policy の cooldown 値 aws_cloudwatch_metric_alarm の period 値 具体的には 60sec となっていた値を 10sec などに変更しました。これによって 60sec のインターバルでしきい値計算してスケールさせていたところを 10sec にインターバルを縮めつつスケールさせる。つまりより迅速にスケールさせることで上記のシチュエーションに耐えられるのではと考えました。 ですが、結果は NG でした。 下記は Cloudwatch Metrics の様子です。データはプロットされているものの、データ不足 という状態に陥っている事がわかります。 実際に ECS はこの設定をした Metrics Alarm ではスケールしてくれませんでした。 高解像度メトリクスの利用について であれば高解像度メトリクス を利用すれば良いのではと考えました。 ...