こんにちは。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.pipecd.yaml を配置しターゲットグループ・タスク定義・ECS サービスを指し示す piped は GitHub レポジトリを参照 となっています。 ...

こんにちは。jedipunkz🚀 です。 引き続き Go を学習しています。前回の記事 ECS コンテナにログインする CLI を Go 言語で作った話 のまとめにも記したのですが Go のコードを書くアイデアとして下記をぼんやり考えていました。 ECR 脆弱性スキャンのパッケージを開発 そのパッケージを利用して Datadog のカスタムメトリクスとして送信 同様にそのパッケージを利用して ECR スキャンの CLI を作成 その紹介を軽くしたいと思います。 開発した ECR 脆弱性スキャンの Go パッケージ 開発したパッケージは https://github.com/jedipunkz/ecrscan になります。 下記のように Ecr 構造体を初期化します。 e := myecr.Ecr{} e.Repositories = [][]string{ {"image-to-scan", "latest"}, } e.Resion = "ap-northeast-1" finding, vulFindings, _ := e.ListFindings() その後 ListFindings() メソッドでスキャンします。結果、finding.FindingSeverityCounts には下記の深刻度毎のイメージに含まれている脆弱性の数が入ります。 INFORMATIONAL LOW MEDIUM HIGH CRITICAL UNDEFINED また、vulFindings には含まれている脆弱性の CVE 名 深刻度レベル (INFORMATIONAL, LOW, MEDIUM, HIGH, CRITICAL, UNDEFINED) CVE URI 説明 が入ります。 ...

こんにちは @jedipunkz 🚀 です。 今回は Go 言語で ECS コンテナにログインする CLI を作った話を書きます。 開発の経緯 自分はまだ Go 言語の初学者で学習のために開発するアイデアを探していた状態でした。そこで自分の勤めている会社で ECS Execute 機能を使ったコンテナログインの機能を開発者に提供していた事を思い出し色々調べていて「もう少し手間が省けないか？」と思い立った、という経緯で開発をはじめました。 awscli を使った ECS Execute 機能によるコンテナログイン 手間が多いと書きましたが実際に awscli を使う場合どの程度の手間があるのか簡単に記します。まず下記のコマンドを実行して $ aws ecs list-tasks --cluster <クラスタ名> --service <サービス名> taskArn が得られるので Arn から task ID を拾って、その task ID を使って $ aws ecs execute --cluster <クラスタ名> \ --task <task ID> \ -- container <コンテナ名> \ --interfactive \ --command "sh" とコマンドを実行することでコンテナにログイン出来ます。が手間が少し多いのと task ID を拾い出す作業も辛いので改善したい…。 操作画面 ということで miniecs という CLI を作ったのですが、 まずは操作している様子を貼り付けます。😷 Fuzzy Finder なインクリメンタルサーチが出来る CLI になっていて、ECS クラスタ名・ECS サービス名・コンテナ名を一部入力するとログインしたい環境が選択出来るツールになっています。 ...

こんにちは。jedipunkz🚀 です。 今回も READYFOR Advent Calendar 2021 の記事として執筆します。 今回のテーマ 前回の記事 では ECS 移行後の構成について検討する内容を記しました。Progressive Delivery を実践する上でもその一歩手前の構成と言っていいカナリーリリース構成について、今回は記していきたいと思います。 デグレしてしまっていたカナリーリリース READYFOR では AWS ECS 移行を行い ECS + CodeDeploy による Blue/Green デプロイメントを導入しました。逆に移行前までに出来ていたカナリーリリースが実施できなくなりました。とは言ってもそれまで開発者がカナリーリリースに対して求めていた主な機能はロールバックだったため、ひとまずは Blue/Green デプロイメントで事足りている状況なのですが、今後大きな機能をリリースする際にはトラヒックを徐々に寄せ影響を把握した上でリリース進めるという作業は必要になってくる可能性があります。 よって、 Progressive Delivery の一歩手前の構成を実践する 大きなリリースのための環境整備 という意味でも、一回カナリーリリース構成について検討しておこうと考えました。 環境構築 今回用意した Terraform コード 検証で作成した AWS 環境をデプロイするための Terraform コードを下記の場所に置いてあります。参考にしてください。 https://github.com/jedipunkz/tf-appmesh-ecs-canary-release (今回検証で作成したコードは業務上作成したものですが、READYFOR の OSS ポリシーに則り著作権譲渡をうけており、自らのGitHubリポジトリで公開しています。) App Mesh ECS NLB Service Discovery Envoy X-Ray といった技術要素で構成されています。 Terraform コードによるデプロイ実施 上記に記した Terraform コードを使った構成のデプロイ手順を記します。 前提として Terraform バージョン 1.0.x 系以上をローカルにインストールする必要があります。 $ # AWS クレデンシャル情報を設定 $ git clone https://github.com/jedipunkz/tf-appmesh-ecs-canary-release $ cd tf-appmesh-ecs-canary-release $ terraform plan $ terraform apply 構成 検証で構築した構成(上記の Terraform コードで構築できる) は下記になります。 ...

こんにちは。jedipunkz です。 今回は READYFOR Advent Calendar 2021 の記事として執筆します。 READYFOR では 2021 年の夏に AWS ECS へプラットフォーム移行をしました。ECS は自分達の要件を全て満たしてくれ運用コストも極小化できて更に周辺の技術も AWS 公式のものが揃っているので、とても満足している状況です。 移行を終えたばかりなので「では次のアーキテクチャは？」という話にはまだなっていないのですが、今は準備期間として余裕を持ってスケジューリングできる状態にして頂いているので、SRE チームとしては色々な技術をリサーチしている段階になります。 今現在は ECS + CodeDeploy を使って Blue/Green デプロイメントを実現しているのですが、よりモダンなデプロイ方式 Progressive Delivery について去年あたりから興味を持っていました。ただ、今までは実際に技術を触るまでには至っていなかったのでこの機会に色々と触ってみたという次第です。 今までも Blue/Green デプロイメント, Canary リリースとデプロイ方式が複数ありましたが、これらを含む継続的デリバリの次のステップと言われているのが Progressive Delivery です。2020年に Hashicorp 社の Mitchell Hashimoto 氏 が来日した際に「今一番気になっているワード」としてあげていましたのが印象的でした。 ECS を使った Canary リリース Progressive Delivery の話をする前に ECS を使った Canary リリースについて少し触れておきます。 (具体的な話についても、どこかのタイミングで記事にできればと思っています) AWS App Mesh と ECS, X-Ray を使って下記のような構成を作りました。この構成中の App Mesh の Virtual Router のルーティング情報を修正する形で Canary リリースのトラヒック操作が行えます。ECS 以前は Canary リリースを実現できていて ECS 導入によってそれがデグレした状態だったので、この構成の検証は一つの成果だったと思っていますし、今回話をする Progressive Delivery のひとつ前のステップとも考えています。 ...