タスク数を 0 に変更してもオートスケーリングのスケールアウトが実行される挙動を回避するためには | DevelopersIO
困っていた内容 ターゲット追跡スケーリングポリシーを設定したオートスケーリングを ECS サービスに設定しています。 手動で ECS サービスのタスク数（必要数）を０に変更しましたが、その後スケールアウトが実施されました。 オートスケーリングの「タスクの最小数」も「0」に設定していて、ターゲットのメトリクス値も低いので、スケールアウトは実行されない認識ですが、なぜタスク数が更新されたのでしょうか。 スケールアウトを回避する方法があれば併せて教えてください。 どう対応すればいいの? スケーリングの一時停止をご利用ください。 ターゲット追跡スケーリングポリシーは、過去のメトリクス状況を含めてタスク数を調整するため、過去のリソース状況を参照し、意図しないスケーリング（タスク数の変更）が行われる場合があります。 例えば、一定の負荷があるサービスのタスク数を０に手動変更した直後は、過去のメトリクス状
既存のECS(Fargate)にALBを追加してみる | DevelopersIO
ECS(Fargate)でとりあえずタスクを立ち上げて使えるようにしてみたけど、本当はALBを前段に置いてバランシングしたいんだよねぇ。なんてことはありませんか？ ようするに今タスクIP直アクセスして使ってるやつを、こう変えたいみたいなことです。 マネジメントコンソールから変更しようと思うと、一見できなさそうに見えますが、ドキュメントにAWS CLIまたはSDKを使用してロードバランサーの設定変更できる旨が記載されています。 AWS CLI または SDK を使用して、ロードバランサーの設定を変更します。設定の変更方法の詳細については、「Amazon Elastic Containers サービス API リファレンス」の UpdateService を参照してください。 クラシックコンソールを使用したサービスの更新 - Amazon ECS UpdateService - Amazon
運用中のサービスに負荷試験を導入した事例の紹介 - KAYAC engineers' blog
SREチーム(新卒)の市川恭佑です。今回は、Tonamelという自社サービス(Web)において負荷試験を導入した事例を紹介します。 このエントリは「先送りされがちな負荷試験の導入について心理的なハードルを下げる」ことを目的としています。 そのため、事例紹介と銘打っていますが、列挙される事実の独立性よりも文脈性を優先しています。 表現が少し冗長に感じるかもしれませんが、負荷試験について距離感を感じている方は是非お付き合いください。 負荷試験を導入するに至った経緯 Tonamelは、本格的なリリースから5年以上という、比較的長い運用歴を持つサービスです。 まず、何故このタイミングで負荷試験を導入することになったのかについて、その経緯を説明します。 ポストモーテムによる気づき（文化的な土台） 今年の3月に公開されたエントリにもあるように、カヤックでは着実にポストモーテム文化が浸透しつつあります。
EKSからECSに移行して開発運用コストの削減を図る - KAYAC engineers' blog
SREチームの長田です。 今回はカヤックで運用している「まちのコイン」というプロダクトのアプリケーション基盤を Amazon EKS(以下EKS)からAmazon ECS(以下ECS)に移行したはなしをします。 まちのコインとは coin.machino.co www.kayac.com まちのコインはカヤックが運営している、デジタル地域通貨を使ってその地域のコミュニティを活性化させるサービスです。 2019年11月から実証実験を開始し、翌年2月から正式リリースされました。 2022年9月現在、20の地域に導入されています。 一般ユーザーが使用するクライアントアプリと、導入地域の運営団体が使用するブラウザ用の管理画面、 それらにAPIを提供するRailsサーバーアプリがあります。 データベースはAmazon Aurora PostgreSQL、 その他AWSのマネージドサービスを組み合わせ
ecrm - Amazon ECRから不要イメージを安全に削除するOSSを作った - KAYAC engineers' blog
SREチームの藤原です。今回は、AWSのコンテナレジストリであるAmazon ECRから、不要になったコンテナイメージを安全に削除するツールをOSSとして作った話です。 Amazon ECRのライフサイクルポリシーでは、設定によっては実際に利用中のイメージを削除してしまうことがあります 現在利用中のイメージを避けて、それ以外の不要なイメージを安全に削除できるCLIツールをOSSとして作成しました Amazon ECSとECRでのイメージ運用 カヤックでは、コンテナのオーケストレーションにAmazon ECSを主に使用しています。ECSにタスクをデプロイする場合は、イメージのタグにアプリケーションのGitリポジトリのコミットハッシュ(git log -1 --format=%Hで計算した値)を付与してAmazon ECRにpushし、タスク定義ではそのタグを含めたURLを指定しています。 例
Fluentd 集約ノードのオートスケール - クックパッド開発者ブログ
こんにちは、技術部 SRE グループ アルバイトの小川です。この記事では、クックパッドでコンテナログの処理に利用している Fluentd ノードのオートスケール対応について紹介します。 クックパッドでは Amazon ECS を用いてコンテナ化されたアプリケーションをデプロイしています。クックパッドでの ECS の利用については過去の記事をご覧ください。 ECS 上で動くコンテナのログを閲覧するために、標準的には Amazon CloudWatch Logs を利用する方法があります。しかし、クックパッドではログ量やコストの問題で CloudWatch Logs は利用せず、独自のログ配送基盤を構築して運用しています。具体的には、ECS のコンテナインスタンスで実行している Fluentd から複数の Amazon EC2 インスタンスで構成される Fluentd 集約ノードにログを転送し
CloudWatch メトリクスに ECS Fargate のタスク単位のCPU・メモリ使用量を記録してみた | DevelopersIO
はじめに アノテーション株式会社の hato です。 本記事は CloudWatch Container Insights と CloudWatch Logs のメトリクスフィルターを利用して、タスク単位のCPU・メモリ使用量を自動的に CloudWatch メトリクスに登録する方法をご紹介します。 完成図 タスク単位のCPU・メモリ使用量 Container Insights を設定すると「タスクのパフォーマンス」からタスク単位のCPU・メモリ使用率が確認できますが、過去のリソース状況を確認したい場合があります。 タスク単位のリソース状況は CloudWatch メトリクスには標準で保存されませんが、Container Insights のパフォーマンスログ にはタスク単位・コンテナ単位のリソース状況が収集されています。 そのため、CloudWatch Logs のデータをメトリクスフィ
EFSをECS Fargateにマウントする定義をCFnで書きながら理解する - Qiita
はじめに 2020年4月にAWS Fargateのプラットフォームバージョン1.4.0がリリースされ、それに伴い、ECS FargateからAmazon Elastic Filesystem（以下、EFS）が利用できるようになりました。今回これを必要とする要件があり、EFSを初めて利用することになりました。そのため、基本的な概念を整理するために記事にしました。 今回の進め方として、CloudFormation（以下、CFn）で設定が必要な要素を確認しつつ、不明点があればドキュメントを読んで理解していったので、本記事でもCFnの定義をみながらEFSの要素についてみていきたいと思います。 最終的な構成 これから順を追って各コンポーネントについてみていきますが、今回の最終的な構成としては以下のようになります。 サブネットは二つで、それぞれのサブネットにECS Fargate上でタスクが稼働してい
7年続いたサービスをEC2構成からECS構成へ乗り換えた話 - KAYAC engineers' blog
この記事は Tech KAYAC Advent Calendar 2021 の20日目の記事です。 こんにちは、バックエンドエンジニアの @commojun です。今年のTech KAYAC Advent Calendarは3度めの参戦です！よろしくお願いいたします！ 本日の記事は、昨年の記事の続きで、Amazon EC2のプロダクトをAmazon ECS構成へと乗り換えた話になります！ techblog.kayac.com 目次 目次 背景 Amazon Linuxのサポート終了 ついでにPerlのバージョンもあげた 苦労したポイント 1，デプロイ方法がめっちゃ変わる デプロイのために都度コンテナイメージを焼く 2階建て作戦 2，batchサーバどうするの問題 sqsjfr + SQS + sqsjkr 作戦 3，泥臭い戦い ecspressoの存在 非エンジニアにもわかってもらおう 「
ECSとローカル間でファイルをコピーしたり、対話形式でrun-taskやexecできるデバッグ特化のCLIツールを作りました
はじめに 2021年3月、実行中のコンテナに入ることができる「ECS Exec」がリリースされました。 これがリリースされるまで、ECSでコンテナに入る方法としては、 ECS on EC2 EC2にsshした後にdocker execする ECS on Fargate そもそもできない（Session Managerを使った非公式な方法は除く） といった状況だったため、このリリースでECS（特にFargate）でのデバッグやトラブルシューティングが一気に楽になりました。 ただ、人間欲深い生き物でして、実際にaws ecs execute-commandを使い始めると、今度は、 タスクIDをマネコン等で調べるのが手間なので対話形式で選択したい ECSとローカル間でファイルをコピーしたい（scpしたい） などの欲が新たに発生してしまいます。 「探せばそういうことができるツールがあるんじゃないの
Amazon ECS タスクのイベントとログを時系列で出す tracer を作った - KAYAC engineers' blog
SREチームの藤原です。KAYAC Advent Calendar 2021 4日目の記事です。 早速ですが Amazon ECS をお使いの皆様、何か新しく起動したい ECS タスクがあって、タスク定義を書き起こして(もしくはマネージメントコンソールで定義して)、一発で起動に成功できますか？？ ……なかなかこれが難しいんですよね。 ということで、とある ECS タスクに関連するイベントとログを全部時系列で出力するツールを書きました。どうぞご利用ください。 github.com 以下はそこに至るまでの背景です。 ECS タスクが立たない。なぜだ！ 自分は Amazon ECS を業務で使い始めて早4年になります。新規プロダクトはもちろん、かつて EC2 で動いていたワークロードもほぼ全て ECS に移行しました。 ECS デプロイツール ecspresso の開発者でもあるため、日々機能ア
[Terraform]ECS FargateでFireLensを使って複数サービスにログ出力する | DevelopersIO
こんにちは！コンサル部のinomaso(@inomasosan)です。 ECS FargateでFireLensからCloudWatch LogsやKinesis Data Firehoseへのログ出力を、Terraformでコード化したので紹介します。 検証にあたり、弊社の以下ブログを参考にしました。 そもそもFireLensって何？ FireLensは、複数のAWSサービスやAWSパートナーネットワーク(Datadog等)にログ出力することができます。 ECSタスク定義でサイドカーとして起動し、他のコンテナからログドライバーとして使用します。 コンテナイメージにはFluentdとFluent Bitを選択可能です。 今回の検証では、リソース使用率が低く、ログルータに推奨されているFluent Bitを使用します。 2021/11/6時点でFluent Bitでは、以下のAWSサービスに
![[Terraform]ECS FargateでFireLensを使って複数サービスにログ出力する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/8a77b081e14c8d61a2e80498092f8ffb9b60da03/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Fterraform-eyecatch.png)
Amazon ECS でのコンテナデプロイの高速化
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
Docker-in-Docker でお手軽 Amazon ECS Anywhere お試し環境を手に入れる | トリの部屋
『手軽に作って壊してができる ECS Anywhere お試し環境が欲しい』、あるいは『ECS Anywhere で遊んでみたい気持ちはあるけどそれだけのために Raspberry Pi を買う1気にはならない』、という方向けの記事です. TL;DR x86_64 なラップトップが手元にあるなら… VirtualBox で VM を作ればサクッと試せる ただし VM はそこそこ重い M1 Mac なみなさまは… VirtualBox は残念ながら M1 Mac 未サポート というか ARM 未サポート お金を出せば Parallels で ARM な VM を作れる2ので、それも可 💸 VMware Fusion は残念ながら記事執筆時点で ARM 未サポート というわけで、本記事では Docker-in-Docker を利用して (M1 Mac でも) ECS Anywhere する手
Amazon ECSのログストリームを見やすく階層的に整理できるawslogs設定 - Hatena Developer Blog
こんにちは。SREのid:do-su-0805です。普段はid:do_su_0805として生活しています。 この記事では、Amazon ECS（以下、ECS）でコンテナを動かすとき、ログドライバーとしてawslogsを利用してAmazon CloudWatch Logs（以下、CloudWatch Logs）にログを出力する際に、awslogs-stream-prefixというパラメータには何を設定するとよいかについて考察します。 結論から言うと、このパラメータに「コンテナのイメージタグ」を入れるようにしたところ、出力されるログストリームの/区切りの階層が見やすくなり、ログが世代別に扱いやすくなったよ、というお話です。 ECS＋CloudWatch Logs構成時のロググループとログストリームについて どのようなログストリームが構成されがちかを事例から考えてみる awslogs-strea
ECS用のCDパイプラインに対する考察
それでは、1パターンずつ構成を確認していきます。 1. 全部GitHub Actionsでやる GitHub Actionsでパイプライン全体を構築する場合は、以下の図のような構成になります。 ちなみに、GitHubのDeploymentsを使用することで、Slackと組み合わせてのChatOpsや、任意のコミットのデプロイを実行などいろいろと便利になります。 ですが、Deployments APIをパイプラインで利用するには、Actionsのトリガーの条件を変えたり、ECSへのデプロイの成否に応じてAPIを使ってDeploymentのステータスを更新したりする処理が必要になり、少々パイプラインが複雑化してしまいます。 なので、今回の趣旨とちょっとずれているため、各パターンには記載していません。 では、以下で処理を順に説明していきます。 Image Build 図中の Build Imag
ECS-Optimized Bottlerocket AMIでECS環境を構築する | DevelopersIO
中山（順）＠リカバリー中 です。 かなり久しぶりにブログを書いております。 最近全くインプットができてなかったので、リハビリを兼ねて少し前に一般提供を開始した"ECS-Optimized" Bottlerocket AMIを利用してECS環境を構築したいと思います。 The Bottlerocket AMI for Amazon ECS is now Generally Available Bottlerocketとは コンテナをホストすることに特化したLinuxベースのOSです。セキュリティや保守性の面でメリットがあります。 公式の情報はこちらからどうぞ。 Bottlerocket bottlerocket-os / bottlerocket 一般提供開始時（EKS対応時）の弊ブログ記事はこちらになります。 コンテナ実行に特化したAWS製オープンソースOS「Bottlerocket」がG
ECS コンテナインスタンスを停止すると自動起動する挙動を回避するためには | DevelopersIO
困っていた内容 コスト削減のため ECS コンテナインスタンス（EC2）を停止しましたが、いつの間にか「終了状態」になり、新しいコンテナインスタンスが起動しました。 コンテナインスタンスでは通常の EC2 のように終業時に停止して、始業時に開始するといったコスト削減はできないのでしょうか。 どう対応すればいいの? Auto Scaling を利用した自動終了・開始をお試しください。 ECS クラスターを作成する際に「EC2 Linux + ネットワーキング」を選択すると、自動的に Auto Scaling も作成されます。Auto Scaling によりコンテナインスタンスの起動数が自動的に制御されるため、EC2 を直接停止しても、自動的に終了状態になり、新しいインスタンスが作成されます。 そのため、コンテナインスタンスを特定時間だけ起動したい場合は、Auto Scaling の機能を使用
ECS Fargateのタスク定義の取得→更新→反映をShellとjqで自動化 | DevelopersIO
コンテナベースで開発作業していて、更新したコンテナイメージを、ECS(Fargate)上で稼働しているサービスに反映したいという時、ちゃんとした開発ラインならCI/CDパイプライン組んで自動デプロイするトコロですが、諸事情もありますよね？ じゃあ、と手作業でやってみるとこれが結構面倒なので、シェルにしました。 概要 サービスへの反映までに至る流れは、以下のようになります。 対象となるサービスにアタッチされているタスク定義を特定し、取得する それを基に新たなタスク定義を作成する 新たに作成したタスク定義を、元のサービスにアタッチする なお、所謂Latest運用はここでは想定していません。 では、何はさておきコードです スクリプト #!/bin/bash ECS_CLUSTER_NAME=your-cluster-name ECS_SERVICE_NAME_KEY=your-service-n
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ECS 料金 - Google 検索