こんにちは、後藤です。今回はAWS構成における踏み台についての記事です。 データベースなどのインターネットに繋げたくないリソースに踏み台リソース経由でアクセスさせることは、セキュリティ設計としてよくある構成だと思います。 今回はその踏み台リソースに「ユーザーログイン有無を検知して自動停止する」ロジックを組み込んだ方法を共有します。 また、一般的によく用いられるのはEC2だと思いますが、今回はECS on Fargate(以降はFargateと略)を使います。しかも自動停止ロジックにLambdaを使いません！！コンテナの中で完結させます。 踏み台を設計する時に気になること そもそも踏み台について設計する際に何が気になるのでしょうか。それはOS管理負担と自動停止です。 踏み台にEC2を用いるとOSパッチ適用などの運用コストが発生します。業務系サーバでないのに心労が重なるのはなるべく避けたいとこ
はじめに 現在はAWSで構築されたシステムの運用保守業務に携わっており、その一環として障害調査を行うことが多々あります。 少しは経験値が上がったため、障害が発生した際に初動で確認する事項をまとめてみました。 インフラ基盤観点で障害調査を行うさいの参考になれば幸いです。 前提条件 当システムの構成は以下となっているため、それに即した調査項目となっています。 ALB/NLB・ECS・RDSを利用している ECSはEC2上で実行している（Fargateでは利用していない） ECSクラスター（以下クラスター）の自動スケーリング設定をしている ECS サービス（以下サービス）の自動スケーリング設定をしている RDSはAuroraを利用している また、障害は予期せぬコンテナの停止を想定しています。 NLB/ALBの調査事項 メトリクス 初めにロードバランサーのメトリクスからターゲットの状態を確認します
Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用 / YAPC::Hiroshima 2024
https://fortee.jp/yapc-hiroshima-2024/proposal/1e9fbacd-5a50-43ef-87f1-490e85448f17
こんにちは。梅原です。 今日はECSのデプロイタイプについて改めて整理します。 ECSのデプロイ方法は3つあります。 ローリングアップデート Blue/Greenデプロイ 外部デプロイ の3つです。 この記事ではローリングアップデートとB/Gデプロイについて流れをおさらいします。 ECSの前段にALBを置いた構成を例にします。 ローリングアップデート ローリングアップデートの流れを見る B/Gデプロイ B/Gデプロイの流れを見る ローリングアップデートとB/Gデプロイの比較 最後に ローリングアップデート ローリングアップデートとは、稼働中のECSタスクをそのまま新しいタスクに置き換える方法です。一番オーソドックスなデプロイ方法なのではないでしょうか。 ECSのみでデプロイすることができ、設定箇所も主に後述する2つだけなので手軽にできます。ですがデプロイ中は新旧のタスクが混ざる状態となるた
この記事は何？ 最近、生成AIブームで「Pythonの簡単なチャットアプリを作ってみる」機会が増えたのではないでしょうか。 特に、Streamlitという便利なライブラリを使えば、Reactなどが書けなくても簡単にフロントエンドをPythonで作ることができます。 開発端末のローカルやCloud9などでこれを動かすのは簡単なのですが、いざ他の人にも使ってもらおうとするとクラウド上にデプロイする必要があります。 しかし、アプリをコンテナに固めてAWSにデプロイ！ といった王道の作業をGUIで分かりやすく解説する記事が意外と少なかったので、初心者向けハンズオンとしてまとめてみます。 ハンズオンの概要 作成するアーキテクチャ 作業環境 端末：Macbook（Appleシリコン） ブラウザ：Google Chrome コードエディター：VS Code Python：3.9以降のバージョン 注意事項
https://jft2023.jaws-ug.jp/ の発表資料です
本日、Amazon Elastic Container Service (Amazon ECS) はタスクスケジューリングを強化し、予測不可能な負荷のスパイクに対するアプリケーションの回復性をさらに向上させました。Amazon ECS は、コンテナまたはロードバランサーのヘルスチェックに合格しなかった異常なタスクを終了する前に、正常な代替タスクを開始するようになりました。この機能の強化により、追加の作業や構成なしで、お客様のアプリケーションの回復性が向上します。 Amazon ECS はフルマネージドのコンテナオーケストレーションサービスで、非常に安全で、信頼性が高く、スケーラブルなコンテナ化アプリケーションを簡単に実行できます。お客様はアプリケーションのコンテナまたはロードバランサーのヘルスチェックを定義して、異常のあるタスクをいつ終了して新しいタスクに置き換えるべきかを Amazon
【30歳/完全未経験/独学】webアプリを作製しました【Golang, Next.js, MySQL, Docker, GitHub Actions CI, AWS Fargate on ECS】 - Qiita
完成物 ER図 画面遷移図 figma, 原寸画像 AWS構成図 ※備考※ GitHub Actions CIは構築済みです。 GitHub Actions CD, apiのprivate subnet化にも取り組んでいます。 EC2インタンスは通常時停止です。 技術選定理由 プログラミング、IT業界ともに未経験で着手し独学で作りました。 Go 比較対象：JAVA、Ruby、Python、PHP コンパイラ言語であり実行速度が高速である 静的型付けであり、コンパイル前にバグを発見しやすい 静的型付けかつ記述自由度が低いことから、以下２点を利点と考えた 開発を中長期まで続けた際にも、加筆・改修しやすい 他人のコードを読んだ際に学びやすい Javaも多少書いてみたが、簡素にかけるGoの方がしっくりきた SHOWROOM、IRIAM、Twitch、AbemaTVといった動画配信サービスにも採用さ
この記事について みなさん、ECS利用していますか！？ AWSでコンテナを使うのなら、ECSですよね！?(kubernetesわからない勢) ECSはタスクという単位で、アプリケーションを実行させます。 そして、タスクの中にコンテナが１つ以上稼働します。 タスクはタスク定義から作成されます。タスク定義はタスクの金型的な存在です。 また、タスク定義はJSONファイル（以後taskdef.json)として運用することが一般的です。 このtaskdef.jsonを実運用する際に迷うポイントがあります。 それは以下のどちらの方法にするかです。 – 方法① : 各環境ごとにtaskdef.jsonを用意する – 方法② : 各環境でtaskdef.jsonを共用する ①,②について、それぞれの詳細/メリット・デメリットについて洗い出しをして、どちらを採用すべきかについての見解を述べていきます。 あく
![[ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media](https://cdn-ak-scissors.b.st-hatena.com/image/square/6dda3fa59c84ecf7bd086d3ed685fc0451c945fa/height=288;version=1;width=512/https%3A%2F%2Firet.media%2Fwp-content%2Fuploads%2F2021%2F07%2Feyecatch-aws-logo-1200x630.png){kind=logo}
インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ
こんにちは。カミナシでソフトウェアエンジニアをしているaomanです。 私のエンジニアとしての経歴はカミナシが2社目で、前職も含めフロントエンドからバックエンドまで一通り開発はしていました。ですが、AWSなどインフラに関しては、アプリケーション開発時必要になったところを少し触ったりするくらいで、ガッツリと本格的に学んだことがありませんでした。 そんな私ですが、今回ECS Clusterの切り替え作業を先輩エンジニア監修の元一緒に行う機会をいただきました。どのようなことをしたのか、簡単にではありますがご紹介させて頂こうと思います！ ざっくり概要 カミナシのサービスでは、APIサーバーの運用にAmazon ECS（on Fargate）を利用しています。また、APIサーバーコンテナの他にいくつかのコンテナが起動しています。以下がざっくりとした図になります。1つのTask定義があり、4つのコンテ
TL;DR TypeORMで発生していたスロークエリを改善 スロークエリを改善したらECSの負荷も減少 はじめに スロークエリを改善したら、ECSコンテナ側の負荷も下がってなんでだろ？と思ったので記事にしようと思います。 環境 TypeORM v0.3.20 Node.js v18.x バックエンドインフラ ECS on Fargate => Amazon Aurora MySQL 負荷改善の前と後 まずはどのくらい改善したのかを示します。 この時ECSコンテナ8台動いてました。(4vCPU 8GBMem) 改善前 改善後 改善前と改善後は一日前の同じ時間帯のものです。 ちゃんと動いてるのか不安になるくらい下がってました笑 どのような対応をしたのか スロークエリの出ていたクエリでMySQLの実行計画を確認しました。 TypeALL,index, Using Filesort等はなかったので
AWS ECS Fargateは1分間にいくつまで数えられるか-Linux/ARM64とLinux/X86_64の性能比較
AWS Graviton2 プロセッサは、64 ビットの Arm Neoverse コアを使用してアマゾンウェブサービスがカスタムビルドしたもので、Graviton2 を搭載した Fargate は、同等のインテル x86 ベースの Fargate に比べて、最大 40% の料金性能向上と 20% の低コストを実現し、
Amazon ECSのデプロイにecspressoを使うとビルド・デプロイの境界やアプリ･インフラのIaC境界が明確になる ~ fujiwara-ware OSS ~ | DevelopersIO
クラスメソッドは2024年に5つのOSSに対して支援を実施しました 当方が推薦した @fujiwara さん作による Amazon ECSのデプロイツールである ecspressoが選定されたので、簡単に紹介します。 継続的デリバリーの責任範囲を明確にするecspresso ecspresso(「エスプレッソ」と発音します)はAWSのコンテナサービスAmazon ECSのデプロイツールです。 ECSでのデリバリーを思い出してみましょう。 ECSのデリバリーは、新しいコンテナイメージのビルドと、新しいコンテナイメージのデプロイの2つのフェーズに分かれている ECSのデプロイは、タスク定義を更新し、サービスの参照するタスク定義を更新すること 頻繁に更新されるアプリケーションに対して、VPCやALBといったインフラストラクチャの更新頻度は低く、この2つの更新のライフサイクルは大きく異なる 以上を
pull requestを利用したいい感じのECS feature環境管理方法を考えた - Nealle Developer's Blog
はじめに SREチームの大木です。スノボの季節がもう終わりかけており、さみしい限りです。 feature staging環境*( 以下 feature環境 )自体のライフサイクルや管理をどうするか問題、なかなかどこも苦労していると思いますが、その中で今回それなりにいい感じの回答を出せたと思うので共有したいと思います。 *呼び方はpre-staging環境、pull request環境、テスト環境などいろいろありそうですが、私たちはfeature環境と呼んでいます。 どこが「いい感じ」なのかというと、PRのラベル付与によって環境の生成/削除を制御できる点です。PR画面上で楽々とfeature環境の管理ができたり、PR一覧からどのブランチでfeature環境が立っているかが分かりやすくなります。 feature環境について feature環境を当社のプロダクトであるPark Directの開発
Amazon ECS の古いタスク定義を断捨離する "tdtidy" という隙間家具 OSS を作った | はったりエンジニアの備忘録
自分は Amazon ECS のデプロイに ecspresso を利用することが多いのですが、頻繁にデプロイする環境だと 1 年で数百を超えるタスク定義が作られます。直近の数世代はロールバックする可能性があるので残しておきたいのですが、さすがに数か月前のリビジョンに戻すことはないため不要なものは断捨離したいと思っていました。 そういうリクエストが多かったのか、以前はタスク定義を非アクティブにすることしかできませんでしたが、今年の 2 月についに削除できるようになりました。 Amazon ECS が非アクティブなタスク定義リビジョンの削除をサポート さらに AWS が管理する Containers Roadmap のプロジェクトを眺めてみると、Issue #1967 でタスク定義にライフサイクルを追加してほしいというリクエストが挙がっていました（この Issue を作ったのは中の人っぽいので
EC2インスタンスの踏み台を用意したくない こんにちは、のんピ(@non____97)です。 皆さんはEC2インスタンスの踏み台を用意したくないと思ったことはありますか? 私はあります。 VPC上のRDS DBインスタンスやRedisクラスター、OpenSearch Service ドメインなどのリソースに接続したい場合、Site-to-Site VPNやClient VPN、Direct Connectがなければ踏み台(Bastion)が必要になります。 踏み台へのアクセス方法は以下のようなものがあります。 直接SSH SSMセッションマネージャー EC2 Instance Connect そして、踏み台となるリソースとして採用される多くがEC2インスタンスだと考えます。EC2インスタンスの場合、OS周りの面倒をみる必要があります。OS内のパッケージのアップデートが面倒であれば「踏み台が
AWS Fargate、Amazon ECSの起動と停止を自動化できる無料ツールを紹介します | DevelopersIO
はじめに 弊社が提供する無料のAWS運用かんたん自動化ツール「opswitch」を使って、夜間や土日祝日などの使わない時間帯に開発環境のAWS Fargate、Amazon ECSを停止させる方法を紹介します。プログラムなどの知識はなくても、Webの操作だけで設定を行えます。Fargateを例に説明をすすめます。ECS(ECS on EC2)の場合は「タスクの作成」が少し違いますので補足をご覧ください。 準備 ユーザーガイド opswitchを開始するを参考に以下の初期設定を完了させてください。 opswitchのアカウント作成 opswitchアカウントの初期設定 ユーザー属性情報登録 組織作成 AWSアカウント連携作成 タスクの作成 それではFargateを起動させるタスクから作成します。 Management Consoleでタスク数を変更したいECSサービスにタグをつけます。どのサ
ECS on Fargate のセキュリティ対策は何をやるべき？開発者目線で考える/security-for-ecs-on-fargate-secjawsdays
以下のイベント「Security-JAWS DAYS」で発表した際の登壇資料です。 https://s-jaws.doorkeeper.jp/events/155024
MIXI でモンストサーバチームとセキュリティ室を兼務している、atponsです。 モンストサーバチームでは、モンスターストライクとは別に、モンスターストライク スタジアムというスマートフォンのアプリゲームのサーバ開発・運用を行っています。 モンスターストライク スタジアムは、モンスターストライクとプレイスタイルは同じながら、4vs4の最大8人まで同時対戦や練習モードなどを備えたアプリになっており、モンストのeスポーツ大会「モンストグランプリ」を開催する際にも利用されています。 開発体制の現状 モンスターストライク スタジアムは、初期の段階でモンスターストライクのコードから分岐する形で開発されているため、アップストリームの変更を順次取り込んでいくという仕組みで運用されています。そのため、サーバコードなどは別にあり、適宜新機能を取り込んでいきアップストリームと合わせていくという開発・運用フロ
旧聞ですが、2023/11/13からAmazon ECSが冪等なタスク起動をサポートし、副作用無しに再試行、複数回呼び出せるようになりました。 現時点では、以下のECS APIが冪等性をサポートしています。 CreateService CreateTaskSet RunTask 冪等性を実現する場合、主に次の2通りがあります。 複数回呼び出される前提で、アプリを冪等に実装 一度しか呼び出されない前提で、アプリをシンプルに実装 Amazon SQSを例に取ると、at least onceなスタンダードキューが前者で、exactly onceなFIFOが後者です。 今回のECSアップデートは後者です。ECSタスクの冪等起動対応により、ライブラリ･フレームワークの力を借りながら頑張って冪等に実装していたタスクを、シンプルに実装できるようになることがで期待できます。 ポイント 重要なポイントを述べ
本記事は 基盤デザインウィーク 8日目の記事です。 🌈 7日目 ▶▶ 本記事 ▶▶ 9日目 💻 はじめに ecscheduleとは 「スケジュールされたタスク」 Amazon EventBridgeについて 構成図 コード体系 ecschedule.yaml target.json 構築手順 0. 前提 1. 必要リソース構築(dev) 2. ecschedule dump(dev) 3. 設定ファイルの修正 4. ecschedule apply(prod) 検証中にハマったポイント 1. ecschedule dumpコマンドが成功しない 2. 別リージョンからtfstateの読み込みは出来ない 3. サブコマンドからリソース削除が出来ない まとめ はじめに こんにちは、加藤です。 以前ecspressoについての記事を書きました☕️ tech.nri-net.com 今回はecs
２年半近く前に書いた AWS ECS Fargate のCPU性能と特徴 | 外道父の匠 の続編になります。 そんなに楽しくはないけど、知っておいて損はない、くらいの調査と考察になります:-) 前口上 ちょうど１年前に FARGATE のリソース天井が上がりました。今回は、ほぼそれを区切りにした結果になっていると思います。 AWS Fargate でコンピューティングとメモリのリソース構成が 4 倍に増加 vCPU 条件と Availability Zone を変え、３タスクずつ起動し、出現したCPUモデルをメモっていきました。ついでに軽量ベンチマークとして前回同様 OpenSSL speed をカマしておきました。 関係ないけどコンテナイメージは amazonlinux:2 です。では結果をどうぞ。 出現CPUモデル CPUアーキテクチャを選べるので、それぞれについて。 ECS Farg
Amazon ECS now provides enhanced stopped task error messages for easier troubleshooting - AWS
Amazon ECS now provides enhanced stopped task error messages for easier troubleshooting Amazon Elastic Container Services (Amazon ECS) now makes it easier to troubleshoot task launch failures with enhanced stopped task error messages. When your Amazon ECS task fails to launch, you see the stopped task error messages in the AWS Management Console or in the ECS DescribeTasks API response. With today
Amazon Elastic Container Service (Amazon ECS) and AWS Fargate now integrate with Amazon Elastic Block Store (EBS), allowing you to easily provision and attach EBS volumes to Amazon ECS tasks running on both AWS Fargate and Amazon Elastic Compute Cloud (EC2) using Amazon ECS APIs. This capability makes it easier for you to deploy storage and data intensive applications such as ETL jobs, media trans
Amazon ECS provides the ability to restart containers without requiring a task relaunch - AWS
Amazon ECS provides the ability to restart containers without requiring a task relaunch Amazon Elastic Container Services (Amazon ECS) now improves container resiliency by giving you the ability to define a flexible container restart policy for restarting individual containers locally, without requiring a full task relaunch. With local container restarts, Amazon ECS can recover your containers fro
CodeDeployで更新するECS ServiceをCDK管理して詰んだ話 - Uzabase for Engineers
はじめに 皆様こんにちは、ソーシャル経済メディア「NewsPicks」(Media Infrastructureチーム)エンジニアの北見です。 先日、↓ の記事を書かせて頂きました。 tech.uzabase.com 前回では CDK の良さをメインに紹介しましたが、今回は上手く使えずにドはまりしてしまった例をご紹介します。 ことの始まり ある日、チームメンバーからこんな報告があがってきました。 「CDKのバージョン上げたのですが、cdk deployで失敗しちゃうんですよね。これ分かります?」 xxx-cluster-stack failed: Error: The stack named xxx-cluster-stack failed to deploy: UPDATE_ROLLBACK_COMPLETE: Resource handler returned message: "Re
Gamedev in Lisp. Part 1: ECS and Metalinguistic Abstraction - cl-fast-ecs by Andrew
Gamedev in Lisp. Part 1: ECS and Metalinguistic Abstraction In this series of tutorials, we will delve into creating simple 2D games in Common Lisp. The result of the first part will be a development environment setup and a basic simulation displaying a 2D scene with a large number of physical objects. It is assumed that the reader is familiar with some high-level programming language, has a gener
AWS App Runner 振り返り 2023～決別・ECSを使うぞ～ - koudenpaのブログ
AWS Containers Advent Calendar 2023の4日目です。 qiita.com AWS App RunnerはAWSで手軽にコンテナを動かせるサービスで、2021年にGAしてから緩やかに使用しつつ所感を書いてきた。 AWS App Runner はおもちゃなのでそれ以上の用途には使ってはならない - koudenpaのブログ Laravel を AWS App Runner で動かしてみる - koudenpaのブログ AWS App Runner 振り返り 2022 - koudenpaのブログ 去年のAWS App Runnerのカレンダー | Advent Calendar 2022 - Qiitaではサービス内容の振り返りをしたのだが、今年は記事のタイトルにも書いた通りApp Runnerを自分の中でどう位置付けたのかの整理記事とした。正直サービス内容には
自己紹介 はじめまして、ENECHANGEの@rubita_isi です。 普段はWEBアプリケーションのバックエンドやインフラの開発や運用を担当しています。 この記事では、AWS上に構築された膨大なWEBアプリケーションをElasticBeanstalkからECSに移行する際に、 監視をTerraform Moduleで標準化した件について、その背景や具体的な内容についてお話しします。 ECS移行について ElasticBeanstalkからECSへの移行 ENECHANGEでは、WEBアプリケーションをAWSのElasticBeanstalkで運用していました。 しかし、ElasticBeanstalkを利用する場合、ホストOSやアプリケーション言語のバージョンが頻繁にサポート終了を迎え、その度に対応が必要でした。 また、ebextensionやplatform hookの仕組み・仕様
[アップデート]Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました #AWSreinvent | DevelopersIO
[アップデート]Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました #AWSreinvent ついにECS on Fargateでコンテナランタイムのセキュリティ対策ができるようになりました！Fargate利用者は全員必見のアップデートです！ こんにちは。AWS事業本部トクヤマシュンです。 本日より、Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました！！ 当機能はECS on Fargate、ECS on EC2のどちらにも対応しています！！ (2023/11/29追記：ECS on EC2は現在プレビュー機能のようです。) 立ち位置としては、これまでAmazon GuardDuty EKS Runtime MonitoringとしてEKSのみに提供されてきた機能が、 Runti
![[アップデート]Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました #AWSreinvent | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/f099104aaa09df58f234f4f90b04b2f5cefbb675/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F11%2Feyecatch_reinvent-2023-newservice-update.png)
Solrのクラウド移行 -AWS ECS Fargateの事例- - LIVESENSE ENGINEER BLOG
はじめに 技術部インフラグループの春日です。 2024年現在、弊社が運営している マッハバイト は一部を除いてオンプレからクラウドへの移行が完了しました。 本記事では移行対象の1つであった Apache Solr に関する総括をします。 今回のプロジェクトでは移行自体を最優先とするため、スコープを以下に定めていました。 Apache Solrから他の検索エンジンへは乗り換えない アプリケーション側の改修は向き先の変更だけに留める Apache Solr自体のバージョンUP対応はしない 運用負荷を軽減できる形の構成変更を加える 移行スピードと移行後の運用コストとの天秤 新たに運用しないといけなくなるコンポーネントはなるべく増やさない モニタリングや監視の精度はなるべく落とさない 上記を踏まえ、以降の節ではApache Solrのサービス内利用箇所の紹介から始め、 インフラ構成・デプロイ・モニ
Announcing software version consistency for Amazon ECS services | Amazon Web Services
Containers Announcing software version consistency for Amazon ECS services Introduction Container image tags offer a user-friendly way to manage and keep track of different versions of container images. However, they also present a security risk to organizations due to their mutable nature. Without protections in place, a container image tag can be changed in a container image repository to point
AWS Fault Injection Simulator の Amazon ECS に関する新機能のお知らせ | Amazon Web Services
Amazon ECS タスクにフォールトインジェクションを行う仕組み 次の図は、AWS FIS が Amazon ECS タスクにフォールトインジェクションをどのように行うかを表現しています。AWS FIS は AWS Systems Manager SSM Agent を使って、フォールトインジェクションを実行しています。Amazon ECS タスク内で、サイドカーとして SSM Agent を動かすことで、AWS FIS がフォールトインジェクションを実行できるようにしています。これにより、Systems Manager の Run Command 経由で様々な障害試験を行うことで、潜在的な問題を発見し改善しやすくなります。AWS FIS のフォールトインジェクションを行うために、ECS のタスク定義に、SSM Agent のサイドカーを追加する必要があります。 ウォークスルー 次のス
本記事は 【コンテナウィーク】 1日目の記事です。 💻 告知記事 ▶▶ 本記事 ▶▶ 2日目 📱 こんにちは。梅原です。 皆さんはCI/CDパイプラインやってますか。昨今はパイプラインファーストという考え方もあり、ソースコードの変更反映をトリガーにテストやビルド、デプロイまで自動でやることは多いのではないでしょうか。 今回はAWSでCI/CDパイプラインを実現するためのサービスであるCodeシリーズ（CodeCommit、CodeBuild、CodeDeploy、CodePipeline）を使ってECSへ自動デプロイする流れを見ていきます。 AWSでCI/CDパイプラインを実現するために そもそもCI/CDパイプラインは、継続的インテグレーション/継続的デリバリーの略で、これまで手動でしていたテストやビルド、デプロイ作業を自動化･高速化するために使われるものです。 CI/CDパイプライ
ECS on Fargate 1.4.0で「ResourceInitializationError」を解決する方法 - Uzabase for Engineers
こんにちは。ソーシャル経済メディア「NewsPicks」で検索システムを開発しております崔（ちぇ）です。 弊社の検索システムはAWS EC2（Elastic Compute Cloud、以下、EC2）で動いていました。それを昨年、Amazon ECS（Elastic Container Service、以下、ECS）に移行しました。前回のブログでは、移行のために調べた「アプリケーションをコンテナ化するベストプラクティス」をまとめましたので、ご興味ある方は読んでいただけると嬉しいです。 tech.uzabase.com 今日は、ECS on Fargateのタスク起動に手こずった話をしてみようと思います。タイトル通りFargate 1.4.0 で発生しうる ResourceInitializationError の解決方法について述べるのですが、「まさに今それにハマってた！」という方はぜひ読
Djangoの非同期タスク処理用ECS Serviceをスケールインから保護するためにECS Task Protectionを使う - Nealle Developer's Blog
はじめに SREの大木 ( @2357gi )です。最近美味しいお茶漬けを探しています。 今回は非同期タスクの処理を行うECS Serviceのオートスケーリングをいい感じにした話です。 非同期タスクが大量に積まれた際に、それを実行するworkerを柔軟にスケールアウトさせたいですよね。ただ、スケールインする際に処理中のタスクどうするの？中断されちゃったりしない？みたいな課題があると思います。 そこに対して、ECS Task Protectionを使用することによりいい感じにすることができたので紹介したいと思います。 関連技術はだいたい以下の通りです。 Django Celery ECS Service Auto Scaling (ECS Service) 背景 Park DirectのバックエンドはAPIを提供するbackend-api(Django)と非同期タスクの処理をおこなうwor
本記事は 基盤デザインウィーク 7日目の記事です。 🌈 6日目 ▶▶ 本記事 ▶▶ 8日目 💻 こんにちは、梅原です。 皆さんはコンテナオーケストレーションサービスであるAmazon ECS使ってますでしょうか。今回はECSのサービス間通信の方法4つについてお話します。 ECSサービス間通信についてとその4つの方法 1. Elastic Load Balancer Elastic Load Balancerまとめ 2. ECS Service Discovery ECS Service Discoveryまとめ 3. AWS App Mesh AWS App Meshまとめ 4. ECS Service Connect ECS Service Connectまとめ 4つの方法比較 最後に ECSサービス間通信についてとその4つの方法 昨今、マイクロサービスという言葉をよく聞きますが、E
Rustベースで開発されたECSゲームエンジン「Arete Engine」正式発表。データ指向&ユニファイドメモリを活用し、大量のオブジェクトが存在するシーンも高速動作
新たなゲームエンジン「Arete Engine」バージョン0.1がリリース Entity Component Systemを活用するRustベースのゲームエンジン ユニファイドメモリを使い、フレームごとの処理負荷を軽減 2023年11月10日（現地時間）、Arete Gamesはゲームエンジン「Arete Engine」のバージョン0.1をリリースしました。 We’ve officially released v0.1 of Arete Engine (and a game demo). Arete Engine is a new type of unified-memory game engine centered on performance. v0.1 announcement: https://t.co/e7X5yLnRKe v0.1 download: https://t.co/
カナリアリリースに関連のある部分を図に起こしたものが以下です。 ECSクラスターの中にあるサービスに対してターゲットグループを設定し、ALBからのリクエストをタスクに割り振っています。 デプロイはGitHub ActionsのWorkflow Dispatchを使用し、ボタン押下で実行できます。このプロセスはDockerイメージをビルド、Amazon Elastic Container Registry（以下、Amazon ECRと表記）にイメージをプッシュし、Amazon ECSのタスク定義を更新すると自動的にタスクのローリングアップデートが走る仕組みを使用しています。 余談ですが、クーポンサービスでは以前Spring Boot 2.6を採用していました。 Spring Bootの3系へのアップグレードについては記事「出前館クーポンサービスでのサーバーアプリケーションのSpring Bo
本記事は 【コンテナウィーク】 3日目の記事です。 💻 2日目 ▶▶ 本記事 ▶▶ 4日目 📱 はじめまして、2021年キャリア入社の加藤です。 Amazon ECSのデプロイツールであるecspressoを用いて複数環境にECSデプロイを実施してみようと思います。 業務でTerraformを使用する機会が多いので、ecspressoと連携させ、より実践的な使い方を試します。 ecspresso とは ecspressoはfujiwara氏が公開しているECSのデプロイツール(OSS)です。 github.com 設計思想として 「ECSのデプロイに関わる最小限のリソースのみを管理するツール」と書かれており、ECSデプロイに特化したツールであることが分かります。 ecspressoの管理対象は「ecspressoの設定ファイル」「ECSサービスの設定ファイル」「ECSタスク定義の設定フ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
踏み台にはECSコンテナを。～ログイン有無を検知して自動停止させる～ - NRIネットコムBlog
【AWS】障害時の調査事項まとめ ～ELB・ECS・RDS～ - Qiita
改めてECSのデプロイ方法を整理する - NRIネットコムBlog
【AWSコンテナ入門】簡単なPythonアプリをECSにデプロイしてみよう！ - Qiita
ECSのCI/CD改善と標準化の取り組み / JAWS FESTA 2023 in Kyushu
Amazon ECS が、予測不可能な負荷のスパイクに対するアプリケーションの回復性を向上
[ECS] タスク定義ファイル(taskdef.json)の運用について考える | iret.media
スロークエリを改善したらECSの負荷が爆下がりした話(TypeORM)
AWS CDKでECS Fargate Bastionを一撃で作ってみた | DevelopersIO
モンスターストライク スタジアムをAmazon EC2からAmazon ECS Fargateに移行しました
Amazon ECSタスクを冪等に起動できるようになりました | DevelopersIO
Scheduled tasks(ECS)をecscheduleで管理してみた - NRIネットコムBlog
続・AWS ECS Fargate のCPU性能と特徴 2023年版 | 外道父の匠
Amazon ECS and AWS Fargate now integrate with Amazon EBS
ECSプロダクトの監視をTerraform Moduleで標準化
改めてCI/CDパイプラインを使ったECS自動デプロイの流れを整理する - NRIネットコムBlog
改めてECSサービス間通信を整理する - NRIネットコムBlog
Amazon ECSにおけるカナリアリリースの実現
ecspressoとTerraformを連携させて複数環境にECSデプロイしてみた - NRIネットコムBlog