はじめに こんにちは、ブランドソリューション開発本部バックエンド部SREブロックの小林(@mirai_kobaaaaaa)です。普段はWEARやFAANSというサービスのSREとして開発、運用に携わっています。 WEARではAmazon ElasticKubernetes Service(以下、EKSと呼ぶ)を用いて複数システムのインフラ基盤を構築・運用しています。その中の1つとして、ワークフロー処理の実行基盤が存在しています。本記事では、そのワークフロー実行基盤が抱えていた課題と、それらをどのように解決したのかを紹介します。また、付随して得られたメリットについても紹介いたします。 目次 はじめに 目次 WEARにおけるワークフロー ワークフロー処理内容 ワークフロー実行基盤の構成 ワークフロー実行基盤の課題 コスト内訳の調査 過剰なPodスペック Fargate実行時間の増大 ワーク


AnnouncingAWS Fargate forAmazon ECS Powered byAWS Graviton2 ProcessorsAWS Fargate forAmazon Elastic Container Service (Amazon ECS) powered byAWS Graviton2 Processors, is now generally available.AWS Graviton2 processors are custom built byAmazon Web Services using 64-bit Arm Neoverse cores and Graviton2-powered Fargate delivers up to 40% improved price/performance at 20% lower cost over com

Containers Deep Dive onAmazon ECS Cluster Auto Scaling Introduction Up until recently, ensuring that the number of EC2 instances in your ECS cluster would scale as needed to accommodate your tasks and services could be challenging. ECS clusters could not always scale out when needed, and scaling in could impact availability unless handled carefully. Sometimes, customers would resort to custom to

ちょいとした用途において、カジュアルにFargateの起動/停止を繰り返して、気ままに負荷全開かけていたら、あまりの違和感にCPU割り当てについて調査することにしました。 最近こんなことばっかやってる気がしますが、気に食わんかったからムカムカ解消に書くしかないんや。半分くらいブラックボックス与太話な感じで夜露死苦です。 はじまり とある処理を全開でFargateにやらせて、cpu=1024(100%), 2048(200%), 4096(400%) でどのくらい RPS (requests per second) でるかを計測していると、想定通りならほぼ比例でRPSが伸びるはずが、全然そうならないパティーンに遭遇。 並列過剰やエラー・バグ起因ではないことをほぼ確させた上で、まさかCPUガチャじゃあるまいなと試したら、まんまCPUガチャでしたということで、EC2からある話ではありますが、現在


結論 下記「背景」のようなケースの場合は、ecspressoまたは類似ツールを使ったほうが事故は少ない コンテナやAWSやっていき勢、PoCなど速度が必要なケースはAWS Copilotを使ってみて慣れていくのはアリ というより、双方のツールは目指すところが全然違うので比較対象として論じること自体にちょっと無理がある 前提本稿で記載している「ECS」は「ECS on Fargate」であり、「ECS on EC2」ではありません。 双方のツールを軽く触れて書いた記事なので、細かい機能について把握していないものもあると思います。 背景 これまでいくつかのAWSを使用したプロジェクトのインフラ管理にTerraformをオールインワンツールとして採用してきました。 しかし、システムの規模が大きくなるにつれてTerraformではどうしても取り回しの鈍さが出てくるケースが増えてきたため、アプリケ

FireLens forAmazon ECS では、タスク定義パラメータを使用してログをAWS サービスや AWS PartnerNetwork (APN) の宛先にルーティングし、ログを保存および分析できます。AWS PartnerNetwork は、プログラム、専門知識、リソースを活用して顧客向けサービスの構築、マーケティング、販売を行うパートナーのグローバルコミュニティです。詳細については、「AWS Partner」を参照してください。FireLens は Fluentd および Fluent Bit と連携しています。Fluent Bit イメージ用にAWS を提供していますが、Fluentd や Fluent Bit のイメージはご用意いただいたものを使用することもできます。 デフォルトでは、Amazon ECS は、Firelens コンテナを使用するコンテナより前に
概要AWS Fargate の起動が遅くてつらいことが多く、イメージサイズを減らせば速くなるんだろうか、ということを調べてみた。 結果 「起動時間」には以下の構成要素が含まれていると推測する。 ENI の Allocate (10秒程度) コンテナイメージの Pull (かかる時間のほとんど) コンテナの起動(Firecrackerの起動?) IAM 関連の処理AWS のネットワークはだいたいリソースサイズによってパフォーマンスが設定されているものがほとんどなので、Fargate も同様であると考えられる。 そのため、リソースが大きければそのぶんイメージの Pull にかかる時間は短縮されると考えられる。 Fargate のネットワークの性能については、計測された記事があった。 今回、各10回ほど繰替えし計測を行なったが、起動時間の変化はほとんどなかったため、イメージはキャッシュされて

「なんか同じタスク定義から別々のECSサービス作成されてるけど、これなんなん?」 「しゃーないやん、ターゲットグループ1つしか登録できへんねんから」 待望のアップデートです! Amazon ECS(EC2とFargate両方)において、ECSサービスに複数のターゲットグループをアタッチできるようになりました!Amazon ECS サービスで複数のロードバランサーターゲットグループのサポートを開始 従来、ECSサービスに対してターゲットグループが1つしか登録できないために複数のロードバランサーを紐付けできなかったのが、複数登録できるようになりました。 ECSサービスを1つにまとめることで運用面でもランニング費用面でもメリットがありますが、逆に利用上注意が必要な点も多いので、そのあたりも合わせてお伝えいたします。 ECSサービスに対してターゲットグループが1つ制限だったときの辛い点 例えば、

こんにちは! UZOU でエンジニアしてます @hatappiです。 Speee では週に1回社内のエンジニアが集まるエンジニア TGIF を開いています。 コンテンツは持ち回りの LT や飛び入り LT 、業務連絡などを行っており様々な事業部のエンジニアが集まる場になっています。 お酒ではないですが、お菓子や飲み物が用意されていて、ゆったり楽しめる場になっています!! 先月は私の番がまわってきたのでプライベートのサービスで使い始めた Fargate についての話をしました。 Fargate は去年のAWS re:Invent 2017 でお披露目されて、AWS Summit Tokyo 2018 後の7月に東京リージョンにきました。 今回は Fargate を使ってある程度知見がたまったので、実際に UZOU で使ってみたらどうなるかといったLTをしました。 発表時の資料はこちらです


若者言葉を無理に使って白い目で見られるDockerおじさんの西川です。 re:Inventで発表されたFargateはECSをいじる者としてはとても気になります。aws.amazon.com ECSクラスタを構成するクラスタインスタンス(ECS用語ではコンテナインスタンス)の管理から全く開放されるのです! マジヤバくね?(こういうところですね) ということで、AWSサポートから情報を頂きつつ、手を動かして試してみました。 前提知識:そもそもECSが何をするものなのかDockerが何か、ECSが何かというところはこちらの記事を参考にしていただけると良いかと思います。 コンテナを使う動機 なぜDocker(コンテナ)が期待されるのか - QiitaAmazon EC2 Container Service(ECS)の概念整理 - Qiita Fargateは何をしてくれて、私は何をしなくて

1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く