jedipunkz 🚀 です 👋

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....

@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....

こんにちは。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 ではスケールしてくれませんでした。 高解像度メトリクスの利用について であれば高解像度メトリクス を利用すれば良いのではと考えました。 歴史的に...

こんにちは @jedipunkz 🚀 です。 ECS 構成をもう少しセキュアに保てる構成はないものだろうかと模索しているなかで Sysdig を見つけました。まだ導入できる目処は立っていないのですがある程度ノウハウ蓄積出来てきたのでここで検証内容等を記事にしようかと思っています。 Sysdig は幾つかのサービスが存在するのですが今回検証したのは Sysdig Serverless Security と呼ばれるモノで ECS Fargate 上のコンテナランタイムセキュリティを実践することができるサービスです。 Sysdig とは AWS のサービスにも脅威検知を行うことができるサービスが揃っているのはご存知と思います 対象 目的 技術・サービス AWS リソース 驚異検知 AWS GuardDuty また予防の観点で脆弱性診断が出来るサービスもありあす 対象 目的 技術・サービス AWS リソース セキュリティ診断 AWS Trusted Advisor ECS コンテナ 脆弱性診断 ECR Image Scan EC2 上のソフトウェア 脆弱性診断 AWS Inspector ここで気がつくと思うのですがコンテナ上の驚異検知を行うサービスが AWS には無いと思っています。 (2022/09 時点) Sysdig Serverless Security は ECS Fargate コンテナ上の脅威検知を行うサービスです。ECS Fargate 利用時にコンテナ上の脅威検知を行うサービスは他にも幾つかありますが、Sysdig はシステムコールを利用したコンテナランタイムセキュリティを実践して脅威検知・通知が行えるものになります。自分も詳しくないのですがこれを CWPP (Cloud Workload Protection Platform) と言うらしいです。ワークロードというのはクラウド上の仮想マシン・稼働中のソフトウェアを指して、CWPP はマルウェア保護、脆弱性スキャン、アクセス制御、異常検知の機能を使用してそれぞれのワークロードを保護する、ということらしいです。...

こんにちは @jedipunkz 🚀 です。 今回は CNCF にジョインした PipeCD と Datadog を用いて ECS 環境にてプログレッシブデリバリーを実現する方法について調査したので、その内容を記したいと思います。 そもそもプログレッシブデリバリーとは アプリケーションのデリバリー方法はカナリーリリースやブルーグリーンデプロイメント等がよく知られていると思います。プログレッシブデリバリーはその一歩先を行くデリバリー方式で、Prometheus や Datadog 等のメトリクスを用いて SLO (SRE の SLO と言うよりはデプロイのための指標という意味での) を元にカナリーリリースしたアプリケーションが期待した動作をしているかを確認し (プログレッシブデリバリー的にはこのフェーズを ANALYSIS という様です)、その上でカナリーリリースを完了するというフローになります。 構成 Pipecd, Piped 共に Kubernetes (EKS) クラスタ上に起動する構成 この検証ではこちらの構成を選択しました。この構成の特徴は piped は pipecd の API エンドポイントを指し示す pipecd は UI を提供 pipecd は Filestore (S3, GCS, Minio など), Datastore (MySQL, Firestore など) を利用可 (今回は Minio, MySQL を選択) piped は Target Group, ECS タスク定義等の操作を行うため ECS API へのアクセス権限が必要 piped の pipeline 上のステージで ANALYSIS という Datadog 等のメトリクスを解析する機能を有している アプリケーションレポジトリには app....