AWS Summit Japan 2025 > Day2 Community Stage での登壇資料です。発表時間は20分間。 選定が難しくなっている2025年現在において、多少でもヒントになればと思います。 スライド内のリンク一覧 -

本記事は ブログ書き初めウィーク 4日目の記事です。 📝 3日目 ▶▶ 本記事 ▶▶ 5日目 📅 はじめに Fargateメンテナンスと向き合うモチベーション Fargateメンテナンスとは? Health Dashboard Fargateメンテナンスはどのように適用されるのか? スタンドアロンタスクは廃止される サービスタスクの置き換え手順 手動適用 自動適用 適用単位と時間 タスク置き換え時の通知設定 さいごに はじめに こんにちは。加藤です。 最近、Fargateメンテナンスの運用を「手動適用」から「自動適用」に任せる運用に改善しました。本ブログ記事では、改善対応の中で調査したFargateメンテナンスの特徴について書いていきたいと思います。 Fargateメンテナンスと向き合うモチベーション 早速ですが、皆さんはAWS Fargateを運用されていますでしょうか? aws.a
前記事 AWS ECS Fargate Autoscaling の実戦的な基礎知識 の続きというか派生的なところで、こんな監視項目がこんな理由でえぇんちゃうん、という基礎知識的なお話です。 当ブログでは『監視よければ全てヨシ!』という格言を推していますので、監視の仕込みをサボっている人は今からでも頑張っていきましょう。 はじめに もともと書くつもりでいた本タイトルは、公式からこのドキュメントが出たことで、ゴミ箱行きかと思いました。 推奨アラーム – Amazon CloudWatch > Amazon ECS んが、まぁ所詮はドキュメントということで、ここではもう少し実戦に寄り添う形でまとめていければと思います。 あったら嬉しい監視項目をカテゴリごとに整理しつつ、その理由やら補足情報によって、楽しく監視できるようにしていきたいところです。合わせて読みたいところとしては、この辺もどうぞ。 ミ
ECS を利用すると「タスクロール」と「タスク実行ロール」というものが出てきます。名前が似ている上に、どのように設定するのが良いか分かりづらかったので調べたことをメモ。 目次 タスクロール タスク実行ロール 番外編:EC2 起動タイプのコンテナインスタンスの IAM ロール まとめ タスクロール コンテナで利用される IAM ロールです。コンテナの中のアプリケーションから AWS のサービスを利用する場合にこのロールを設定します。 たとえば、コンテナの中のアプリケーションから S3 を利用する場合にはここを設定します。アプリケーションから AWS サービスを利用しない場合は「なし」で良いです。EC2 インスタンスに設定する IAM ロールのコンテナ版をイメージすると理解しやすいと思います。 詳細は タスク用の IAM ロール - Amazon Elastic Container Servi
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス:ALB or ECS Service 共有 or 1環境毎 アクセスログ:ALB or WEBサーバー ECS / EKS デプロイ:Blue/Gr
こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回はタイミーで実践しているECSのオートスケール戦略についてお話ししようと思います。 TL;DR タイミーではTarget Tracking ScalingとStep Scalingを組み合わせてオートスケールをしています Target Tracking Scaling -> 通常のスケールアウト・スケールイン Step Scaling -> スパイク時のスケールアウト 2つを組み合わせることで、様々なリクエストに対し適切なリソースを用意しています タイミーのアクセス量の変化とビジネス要求 タイミーのアクセス量の変化とこれまでのオートスケール タイミーは空いた時間に働きたい人とすぐに人手が欲しい店舗・企業をつなぐスキマバイトアプリです。 したがって、仕事の募集数や働いてくださるワーカーさんの数は世の中の動向に大きく左右されます
本日、Amazon Elastic Container Service (Amazon ECS) はタスクスケジューリングを強化し、予測不可能な負荷のスパイクに対するアプリケーションの回復性をさらに向上させました。Amazon ECS は、コンテナまたはロードバランサーのヘルスチェックに合格しなかった異常なタスクを終了する前に、正常な代替タスクを開始するようになりました。この機能の強化により、追加の作業や構成なしで、お客様のアプリケーションの回復性が向上します。 Amazon ECS はフルマネージドのコンテナオーケストレーションサービスで、非常に安全で、信頼性が高く、スケーラブルなコンテナ化アプリケーションを簡単に実行できます。お客様はアプリケーションのコンテナまたはロードバランサーのヘルスチェックを定義して、異常のあるタスクをいつ終了して新しいタスクに置き換えるべきかを Amazon
こんにちは、後藤です。今回はAWS構成における踏み台についての記事です。 データベースなどのインターネットに繋げたくないリソースに踏み台リソース経由でアクセスさせることは、セキュリティ設計としてよくある構成だと思います。 今回はその踏み台リソースに「ユーザーログイン有無を検知して自動停止する」ロジックを組み込んだ方法を共有します。 また、一般的によく用いられるのはEC2だと思いますが、今回はECS on Fargate(以降はFargateと略)を使います。しかも自動停止ロジックにLambdaを使いません!!コンテナの中で完結させます。 踏み台を設計する時に気になること そもそも踏み台について設計する際に何が気になるのでしょうか。それはOS管理負担と自動停止です。 踏み台にEC2を用いるとOSパッチ適用などの運用コストが発生します。業務系サーバでないのに心労が重なるのはなるべく避けたいとこ
こんにちは。梅原です。 今日はECSのデプロイタイプについて改めて整理します。 ECSのデプロイ方法は3つあります。 ローリングアップデート Blue/Greenデプロイ 外部デプロイ の3つです。 この記事ではローリングアップデートとB/Gデプロイについて流れをおさらいします。 ECSの前段にALBを置いた構成を例にします。 ローリングアップデート ローリングアップデートの流れを見る B/Gデプロイ B/Gデプロイの流れを見る ローリングアップデートとB/Gデプロイの比較 最後に ローリングアップデート ローリングアップデートとは、稼働中のECSタスクをそのまま新しいタスクに置き換える方法です。一番オーソドックスなデプロイ方法なのではないでしょうか。 ECSのみでデプロイすることができ、設定箇所も主に後述する2つだけなので手軽にできます。ですがデプロイ中は新旧のタスクが混ざる状態となるた
エンタープライズ企業が新しいクラウドサービスを導入する時には、自社のセキュリティ基準を満たせていることを確認するのが通例である。「セキュリティチェックシート」と呼ばれるエクセルシートを利用して一点一点チェックしていくことが多い。(この質問票で聞かれる内容が個社ごとにばらばらで、システム導入時に双方の負担になってしまっているのを標準化してなんとかできないかと思うことはあるが、この記事ではそこには触れない。) よくあるのが、「アンチウィルスソフトウェアをサーバーにインストールしていること」というチェック項目だ。明快な質問のように見えるが具体で実現するためには色々考えなければいけないことがある。標準的なサーバー構成、つまり、ハードウェアがあって、その中でOSが稼働していて、その上でアプリケーションが動いているというシンプルな構成であれば良いのだが、クラウドインフラを使い倒すようになった今ではマイ
CX事業本部@大阪の岩田です。この記事はDeveloper Zoneのセッション「Amazon ECS deployment circuit breaker を使った自動ロールバック」のレポートとなります。ECSのデプロイまわりに興味のある方は是非セッションのURLからデモをご視聴下さい。 セッション概要 ECS デプロイ時、起動に成功しない ECS サービス配下のタスク群を自動でロールバックさせるための設定や実際のロールバックの様子をご覧いただきます。 スピーカー アマゾン ウェブ サービス ジャパン株式会社 アカウントソリューションアーキテクト 竹本 将気氏 URL Amazon ECS deployment circuit breaker を使った自動ロールバック セッション内容 Amazon ECS deployment circuit breakerとは ECSサービスのデプロイ
デプロイサーキットブレーカーは、タスクが定常状態に到達したかどうかを判断する、ローリング更新メカニズムです。デプロイサーキットブレーカーには、デプロイが失敗した場合に、 COMPLETED 状態のデプロイに自動的にロールバックするオプションがあります。 サービスデプロイの状態が変わったとき、Amazon ECS はサービスデプロイ状態変更イベントを EventBridge に送信します。これにより、サービスデプロイの状態を監視するためのプログラムによる方法がもたらされます。詳細については、「Amazon ECS サービスデプロイ状態変更イベント」を参照してください。デプロイを開始するための手動アクションを実行できるように、eventName が SERVICE_DEPLOYMENT_FAILED の EventBridge ルールをを使用して作成および監視することをお勧めします。詳細につい
As stated in the official ECS Exec documentation, ECS Exec today doesn’t support read-only containers. The SSM agent requires that the container file system is able to be written to in order to create the required directories and files. Therefore, making the root file system read-only using the readonlyRootFilesystem task definition parameter, or any other method, isn’t supported. This limitation
Amazon Elastic Container Service (Amazon ECS) は、コンテナ化されたワークロードに柔軟なスケジューリング機能を提供する共有状態のオプティミスティックな並列システムです。Amazon ECSスケジューラはAmazon ECS API と同じクラスターの状態情報を利用して、適切な配置を決定します。 Amazon ECS は、長時間実行されるタスクおよびアプリケーションにサービススケジューラを提供します。バッチジョブまたは単一実行タスクに対してスタンドアロンタスクまたはスケジュールされたタスクを手動で実行することもできます。ニーズに最適なタスクを実行するためのタスク配置戦略や制約を指定できます。例えば、タスクを複数のアベイラビリティーゾーンにまたがって実行するか、単一のアベイラビリティーゾーン内で実行するかを指定できます。さらに、オプションとして、独自
こんにちは、つくぼし(tsukuboshi0755)です! ECSのデプロイタイプには、ローリングアップデートとブルー/グリーンデプロイの2種類が存在します。 最近ECSを触っている中で、上記2つの違いについて調べる機会があったので、本記事でまとめてみたいと思います! ローリングアップデート 概要 コンテナ全体では稼働状態を維持しながら、一部のコンテナを順々にアップデートし、徐々に更新する事でシステムをデプロイする手法。 具体例 ①ローリングアップデート開始時点 ②コンテナAをアップデートする。コンテナBはまだアップデートが始まっていないため、稼働状態は維持される。 ③コンテナAのアップデート後に、コンテナBをアップデートする。アップデート済のコンテナAがあるため、稼働状態は維持される。 メリット ECSのみで設定が完結するため、シンプルな構成になる 稼働コンテナ数は一定のため、コストが安
こんにちは。こむろです。 今年の札幌の夏はハードモードだ(湿気と暑さ) この先生きのこるためにエアコンが投入されました。 はじめに クラウドネイティブなアプリケーションを設計・構築・運用している皆さんは、普段どのようにアプリケーションやインフラの更新作業を行っているでしょうか。 順次インスタンスやコンテナを切り替えていくRolling Update?それとも環境を複製してDNS Routingの切り替えによるBlue-Green Deploymentでしょうか。他にも様々な方法があるかと思いますが、今回もまたBlue-Green Deploymentにおける実際の現場で発生した事象について報告したいと思います。 あまりネット上にもこういった情報が出てこないようなのですが、皆さんこういった問題は軽々とクリアされているのでしょうか。自分がポンコツなだけなのかととても不安にかられるばかりです。
はじめに Amazon ECS は、コンテナを動かしうまく管理するためのコンテナオーケストレーションサービスです。新たなバージョンのコンテナをデプロイするときに、いろいろなデプロイの方法が取れますが、ECS 側で用意されているデプロイ戦略が3種類あります Rolling Update : Service の中で稼働しているタスクを少しずつ順繰りアップデートする方式 Blue/Green Deployment : 新たな環境である Green 環境を用意して、LB レイヤーで切り替える方式 External Deployment : 外部のサードパーティの何かでデプロイをコントロールする方式 こちらの Document に記載があります。 : https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-types.htm
SREチームの藤原です。今回はAmazon ECSのサービス内のタスクを定期的に再起動することで、日々のメンテナンスコストを削減する話です。SRE連載 3月号になります。 3行でまとめ ECS Fargateのタスクは時々再起動が必要 人間が対応するのは面倒 Step Functionsを定期実行して常に新鮮なタスクに入れ換えて予防しよう ECS Fargateのタスクは時々再起動する必要がある ECS Fargateでサービスを運用していると、数ヶ月に一度ほどの頻度でこのようなお知らせがやってきます。 [要対応] サービス更新のお知らせ - AWS Fargate で実行されている Amazon ECS サービスの更新が必要です [Action Required] Service Update Notification - Your Amazon ECS Service Running
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く