こんにちは、後藤です。今回は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つだけなので手軽にできます。ですがデプロイ中は新旧のタスクが混ざる状態となるた
https://jft2023.jaws-ug.jp/ の発表資料です
本日、Amazon Elastic Container Service (Amazon ECS) はタスクスケジューリングを強化し、予測不可能な負荷のスパイクに対するアプリケーションの回復性をさらに向上させました。Amazon ECS は、コンテナまたはロードバランサーのヘルスチェックに合格しなかった異常なタスクを終了する前に、正常な代替タスクを開始するようになりました。この機能の強化により、追加の作業や構成なしで、お客様のアプリケーションの回復性が向上します。 Amazon ECS はフルマネージドのコンテナオーケストレーションサービスで、非常に安全で、信頼性が高く、スケーラブルなコンテナ化アプリケーションを簡単に実行できます。お客様はアプリケーションのコンテナまたはロードバランサーのヘルスチェックを定義して、異常のあるタスクをいつ終了して新しいタスクに置き換えるべきかを Amazon
ウン十万接続のECSサービスを平和にアップデートしたい - Nature Engineering Blog
こんにちは大塚(@maaash)です。7月からCTOに復帰しました。引き続きよろしくお願いいたします。 これは第2回 Nature Engineering Blog 祭11日目のエントリです。 昨日はファームウェア・エンジニアの村田さんによる Matterでやりたかったけどできなかったこと - Nature Engineering Blog でした。 今日のお話は、話題の新製品Remo nanoやMatterとは関係ありません。 背景 先週、黒田さんが ウン十万接続のALB SSL証明書を平和に更新したい - Nature Engineering Blog を書いてくれました。 その話は ALBを二台用意して緩やかに接続を移行するようにしたら、大変平和になって僕もみんなもハッピーになった。 という話でした。ALB blue-green deploymentを使うと、ウン十万のRemoたちが
2月にバクラク事業部Platform Engineering部DevOpsチームに入社したid:itkqです。7月はLayerXエンジニアブログを活発にしよう月間 ということで、この記事では、私が入社してから中心となって進めた、ECSサービスのデプロイの改善について書いています。 バクラクのインフラ 私が所属するバクラク事業部では、バクラク請求書をはじめとする、BtoB向けのSaaSを提供しています。SaaSは主にAWS上でホストしており、サービスの大半がECS Fargateにデプロイされています。昨年、プロダクト開発をイネーブルメントするEnablingチームが発足し*1 、今後の事業成長を支えられるようなソフトウェアアーキテクチャと周辺の仕組みが発達してきています。以下の記事で述べられているように、モノレポかつサービスが多数存在します。 tech.layerx.co.jp DevOp
【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/44fc1474c22e3382588fd4b15ee70ff7f704163b/height=288;version=1;width=512/https%3A%2F%2Firet.media%2Fwp-content%2Fuploads%2F2021%2F07%2Fimg-eyecatch-aws-02-1200x630.png)
インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ
こんにちは。カミナシでソフトウェアエンジニアをしているaomanです。 私のエンジニアとしての経歴はカミナシが2社目で、前職も含めフロントエンドからバックエンドまで一通り開発はしていました。ですが、AWSなどインフラに関しては、アプリケーション開発時必要になったところを少し触ったりするくらいで、ガッツリと本格的に学んだことがありませんでした。 そんな私ですが、今回ECS Clusterの切り替え作業を先輩エンジニア監修の元一緒に行う機会をいただきました。どのようなことをしたのか、簡単にではありますがご紹介させて頂こうと思います！ ざっくり概要 カミナシのサービスでは、APIサーバーの運用にAmazon ECS（on Fargate）を利用しています。また、APIサーバーコンテナの他にいくつかのコンテナが起動しています。以下がざっくりとした図になります。1つのTask定義があり、4つのコンテ
Security-JAWS DAYSに「ECS on Fargate のセキュリティ対策は何をやるべき？ 開発者目線で考える」というタイトルで登壇しました #secjaws #secjawsdays | DevelopersIO
はじめに CX事業本部アーキテクトチームの佐藤智樹です。 今回は以下のイベント「Security-JAWS DAYS」で登壇させていただきました。 以下のSpeakerDeckで資料を公開しました。今回話しきれなかった内容として、NIST SP-800 190の中で対象外として内容の紹介やコンテナランタイムという場合の種類などについて書いたのでよければご覧ください。 登壇のモチベーション 今回の登壇ではNIST SP800-190をベースにECS on Fargateだと何をやるべきか考えてみました。これを日本中のいろんな会社で個別にやっていると時間がもったいないので、自分なりに読み解いて関連部分を切り出して対応方法を話させてもらいました。ECS on Fargateには関連ない部分と判断したものは省いたりしています。もしこの部分はこの方がよいなどあればどんどん改善していきたいので、Twi
AWS FargateにおけるAmazon ECS クラスターの効果的な分け方を様々な観点で考えてみた | DevelopersIO
はじめに AWS Fargateを使用している際に、ECSクラスターをECSサービスごとやECSタスクごとにどのように分けるかに迷うことがありました。 そこで、個人的に複数の観点からクラスターの効果的な分け方を考えてみました。 なお、この記事ではECS on EC2ではなく、ECS on Fargateのみに焦点を当てています。 ECSについて ECSの構成について簡単に説明しますと以下の3つに分かれます クラスター タスクとサービスを実行する基盤です サービス ECSクラスター内で、タスクを実行し管理します タスク タスク定義に基づいてコンテナを起動します 今回は、タスクとサービスを実行する基盤であるクラスターをどのような単位で分けるべきかを考えてみました。 一般的 一般的には、システムや環境ごとにクラスターを作成すると良いでしょう。 理由としては、２点あります。 1. リソース作成の簡
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% の低コストを実現し、
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 を作ったのは中の人っぽいので
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サービスにタグをつけます。どのサ
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内のパッケージのアップデートが面倒であれば「踏み台が
ECS on Fargate のセキュリティ対策は何をやるべき？開発者目線で考える/security-for-ecs-on-fargate-secjawsdays
以下のイベント「Security-JAWS DAYS」で発表した際の登壇資料です。 https://s-jaws.doorkeeper.jp/events/155024
MIXI でモンストサーバチームとセキュリティ室を兼務している、atponsです。 モンストサーバチームでは、モンスターストライクとは別に、モンスターストライク スタジアムというスマートフォンのアプリゲームのサーバ開発・運用を行っています。 モンスターストライク スタジアムは、モンスターストライクとプレイスタイルは同じながら、4vs4の最大8人まで同時対戦や練習モードなどを備えたアプリになっており、モンストのeスポーツ大会「モンストグランプリ」を開催する際にも利用されています。 開発体制の現状 モンスターストライク スタジアムは、初期の段階でモンスターストライクのコードから分岐する形で開発されているため、アップストリームの変更を順次取り込んでいくという仕組みで運用されています。そのため、サーバコードなどは別にあり、適宜新機能を取り込んでいきアップストリームと合わせていくという開発・運用フロ
ECSからS3をマウントしてみた
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 Mountpoint for Amazon S3 が発表されました。 Linux から直接 S3 バケットに対して読み書き機能を提供するソフトウェアです。細かく書くと、読み取りと新規ファイル作成を行うものです。 データレイクからファイルを読み取り何らかの処理をして結果ファイルをデータレイクへ戻す、みたいな処理に適切です。 処理をするアプリケーションによっては S3 API をネイティブにサポートしていないことは珍しくないはずで、その際は前後に S3 Get/Put する別処理が必要でしたが、Mountpoint for Amazon S3 によってファイルシステムとしてマウント可能になれば別処理は要らなくなります。 ただ、S3 はオブジェクトストレージであ
旧聞ですが、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
Announcing additional Linux controls for Amazon ECS tasks on AWS Fargate | Amazon Web Services
Containers Announcing additional Linux controls for Amazon ECS tasks on AWS Fargate Introduction An Amazon Elastic Container Service (Amazon ECS) task is a number of co-located containers that are scheduled on to AWS Fargate or an Amazon EC2 container instance. Containers use Linux namespaces to provide workload isolation—and with namespaces—even though containers are scheduled together in an Amaz
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
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を自分の中でどう位置付けたのかの整理記事とした。正直サービス内容には
8月15日、AmazonはElastic Observabilityを発表しました。 この新機能を使用することで、エンジニアは効果的にECSクラスターのコンポーネントを監視できます。 以下では、詳細な内容と使い方について説明します。 米クラウドコンピューティング大手のAmazon Web Services（AWS）は、8月15日、Amazon ECS（Elastic Container Service）のEC2ベースのクラスター上でアプリケーションを管理する新たなサービス「Elastic Observability for Amazon ECS」を発表した。 lastic Observability for Amazon ECSとは このサービスは、AWSのクラウドネイティブな監視ツールであるCloudWatchを活用し、ECSクラスター内のコンテナ化されたアプリケーションのメトリクスとロ
自己紹介 はじめまして、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のサービス内利用箇所の紹介から始め、 インフラ構成・デプロイ・モニ
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
【アップデート】ECS on FargateがsystemControlsをサポートし、カーネルパラメータが調整できるようになりました | DevelopersIO
CX事業部@大阪の岩田です。 8/9付のアップデートでECS on Fargateのタスク定義で指定可能なパラメータが増えました 今回のアップデートで指定可能になったパラメータは以下の2つです。 systemControls pidMode 本ブログでは上記アップデートのうちsystemControlsについてご紹介します。 systemControlsとは ECSのタスク定義ではsystemControlsというパラメータが指定可能です。このパラメータはdocker run の --sysctlオプションに相当し、Linuxカーネルの各種カーネルパラメータが設定できるパラメータとなっています。従来このパラメータはECS on Fargateでは指定できず、ECS on EC2かつOSタイプがLinuxの場合のみ指定可能でした。 指定可能なカーネルパラメータ SystemControles
本記事は 基盤デザインウィーク 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/
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
踏み台にはECSコンテナを。～ログイン有無を検知して自動停止させる～ - NRIネットコムBlog
【AWS】障害時の調査事項まとめ ～ELB・ECS・RDS～ - Qiita
改めてECSのデプロイ方法を整理する - NRIネットコムBlog
ECSのCI/CD改善と標準化の取り組み / JAWS FESTA 2023 in Kyushu
Amazon ECS が、予測不可能な負荷のスパイクに対するアプリケーションの回復性を向上
ecspressoを活用したECSデプロイの改善 - LayerX エンジニアブログ
[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
AWS、新サービス「Elastic Observability」を発表 ー ECSクラスターの可視化向上
ECSプロダクトの監視をTerraform Moduleで標準化
改めてCI/CDパイプラインを使ったECS自動デプロイの流れを整理する - NRIネットコムBlog
改めてECSサービス間通信を整理する - NRIネットコムBlog