Tag: Amazon ECS

この記事は Under the hood: Amazon Elastic Container Service and AWS Fargate increase task launch rates を翻訳したものです。 2015 年以降、数十万人の開発者がクラスター管理のオーケストレーションサービスとして Amazon Elastic Container Service (Amazon ECS) を選択しています。開発者はミッションクリティカルなアプリケーションのライフサイクルを、最初のデプロイから新バージョンのコードのロールアウト、トラフィックレベルの変化に対応した自動スケーリングまで Amazon ECS に託しています。 これらの長期間実行を前提とするアプリケーションのタスクと並んで、Amazon ECS はスタンドアロンのタスクの起動にも使用されます。スタンドアロンのタスクは、スケジュール実行やイベントトリガーで実行されるコンピューティングジョブです。また、キューに格納された作業に応じて実行される AWS Batch のジョブである場合もあります。Amazon EC2、AWS Fargate、および Amazon ECS Anywhere で管理されるオンプレミスハードウェア全体で、Amazon ECS は毎秒数千ものアプリケーションのタスクとバッチのタスクを起動します。過去 1 年間で、AWS は Amazon ECS を利用されるお客様のタスクの起動レートを引き上げてきました。タスクの起動レートの引き上げにより、デプロイ、スケール、バッチワークロードの高速化が可能になります。

こんにちは、Solutions Architect の安田です。 そろそろ暖房のいらない日も増えてきて春を感じる今日この頃。 皆さんは、いかがお過ごしでしょうか。 さて、今回は、私の所属する ISV/SaaS ソリューション本部では主に国内のパッケージベンダーや SaaS ビジネスを展開するお客様の支援を行っています。今回は私のチームが取り組んでいる Office Hour という施策について、実際にいただいている質問の例も併せてご紹介したいと思います

Amazon Elastic Container Service (Amazon ECS) 上でコンテナワークロードを実行しているお客様は、AWS Fargate を利用するか、Amazon ECS-optimized AMI を用いて Elastic Compute Cloud (EC2) を利用するか、選択できます。これまでにお客様から寄せられた要望 (issue #176) の中には、独自の ECS Amazon Machine Image (AMI) を作成できるようにしてほしい、というものがありました。 本日、私たちは ECS-optimized AMI Build Recipes をオープンソースプロジェクトとして公開しました。そのビルドスクリプトでは、HashiCorp 社の packer レシピを使用して AMI をビルドします。

AWS Japan ソリューションアーキテクトの堀内です。 先日 11/2(火) に CloudNative Days Tokyo 2021 （以降、CNDT2021）の Co-Located ハンズオンイベント にて、 “Security for Developers – DevSecOps on AWS” と “Amazon EKS Observability Workshop” の2つのハンズオンイベントを開催いたしました。

AWS Black Belt オンラインセミナー「CON246 ログ入門」を公開します。 視聴は YouTube から、資料閲覧は SlideShare から可能です。 このセッションでは、コンテナを利用する上で必要となるログの取り扱いについて、ログの目的に応じたAWS各種サービスとのインテグレーション方法、Amazon ECS, Amazon EKS 環境からどのようにログを取得するのか、その取得方法についてご紹介します。 セッションは9分ほどの長さになります。 本資料や動画を通じて、より一層みなさまのコンテナワークロードが進むことを楽しみにしております。 今回の YouTube は AWS Black Belt オンライン AWS コンテナサービスシリーズの YouTube の再生リストにも追加しております。 また、AWS Black Belt Online Seminar 全体の資料は以下のとおりです。 AWS Black Belt Online Seminar オンデマンド動画 コンテンツ 一覧 AWS サービス別資料 （すべての過去資料が閲覧できます） 本記事、プレゼンテーション作成およびスピーカーはいずれも、ソリューションアーキテクトの成尾 (なりお) が担当しました。

AWS Black Belt オンラインセミナー「CON245 Configuration & Secret Management 入門」を公開します。 視聴は YouTube から、資料閲覧は SlideShare から可能です。 このセッションでは、アプリケーションを構成するコンポーネントのうち「設定」とはどのようなものか、Amazon ECS, Amazon EKS それぞれの環境で動作するコンテナからどのように設定を取得し利用するか、そのいくつかの選択肢と特徴についてご説明いたします。 セッションは7分ほどの長さになります。 本資料や動画を通じて、より一層みなさまのコンテナワークロードが進むことを楽しみにしております。 今回の YouTube は AWS Black Belt オンライン AWS コンテナサービスシリーズの YouTube の再生リストにも追加しております。 また、AWS Black Belt Online Seminar 全体の資料は以下のとおりです。 AWS Black Belt Online Seminar オンデマンド動画 コンテンツ 一覧 AWS サービス別資料 （すべての過去資料が閲覧できます） 本記事、プレゼンテーション作成およびスピーカーはいずれも、ソリューションアーキテクトの成尾 (なりお) が担当しました。

この記事は A deep dive into Bottlerocket ECS Updater を翻訳したものです。 先月 (2021 年7 月)、Amazon Elastic Container Service (Amazon ECS) に最適化された Bottlerocket AMI の一般提供を発表しました。この記事では、Bottlerocket ECS Updater に焦点を当ててみたいと思います。Bottlerocket ECS Updater は ECS クラスターにインストールできるサービスで、Bottlerocket のコンテナインスタンスを最新の状態に保つことができます。 サービスの仕組みを詳しく説明する前に、Bottlerocket でアップデートがどのように適用されるかを説明する必要があります (Bottlerocket の GitHub リポジトリ に 詳細が記載されていますのでご参照ください)。Bottlerocket のアップデートは、一般的なオペレーティングシステムで慣れ親しんだものとはかなり異なっています。一般的なオペレーティングシステムでは、個々のソフトウェアコンポーネントを 1 つずつアップデートすることができますが、Bottlerocket はオペレーティングシステム全体を一度にアップデートします。

AWS Black Belt オンラインセミナー「Amazon ECS Deep Dive」と題しまして、「CON207 Auto Scaling in ECS」と「CON307 ECS Capacity Providers」の 2 つのセッションを公開します。 視聴は YouTube から、資料閲覧は SlideShare から可能です。 CON207 Auto Scaling in ECS YouTube / SlideShare CON307 ECS Capacity Providers YouTube / SlideShare CON207 Auto Scaling in ECS CON307 ECS Capacity Providers CON207 では、Amazon Elastic Container Service (Amazon ECS) における Auto Scaling […]

AWS Black Belt オンラインセミナー「CON303 Amazon Elastic Container Service − EC2 / Fargate Spot ことはじめ」を公開します。 視聴は YouTube から、資料閲覧は SlideShare にてご覧いただけます。 本セッションでは、Amazon Elastic Computing Cloud(EC2) の空きキャパシティを活用してオンデマンド料金に比べ最大 90% の割引料金でご利用いただける EC2 スポットインスタンス、そして通常の Fargate 料金の最大 70% 割引でご利用いただける Fargate Spot を Amazon Elastic Container Service (Amazon ECS) と組み合わせて活用していくことをご検討中のエンジニアの方に向けて、スポットリソースの特徴や注意点を短い動画やスライドでご紹介いたします。また、スポットリソースを組み合わせる上で関連する、 Amazon ECS のキャパシティやスケーリングを管理するための重要な概念である Amazon ECS Cluster Auto Scaling / Capacity Providers についても紹介しています。 EC2 […]

この記事は Autoscaling Amazon ECS services based on custom CloudWatch and Prometheus metrics (記事公開日: 2021 年 2 月 26 日) を翻訳したものです。 イントロダクション クラウドネイティブアプリケーションにとって、水平方向のスケーラビリティは非常に重要な要素です。Amazon ECS にデプロイされたマイクロサービスは、Application Auto Scaling サービスを利用して、観測されたメトリクスデータに基づいて自動的にスケーリングします。Amazon ECS は、サービスに属するタスクが消費する CPU とメモリのリソースに基づいてサービスの使用率を測定し、このデータを ECSServiceAverageCPUUtilization と ECSServiceAverageMemoryUtilization という名前の CloudWatch メトリクスとして送信します。Application Auto Scaling は、これらの事前定義されたメトリクスをスケーリングポリシーと組み合わせて使用し、サービスのタスク数をメトリクスに応じてスケールすることができます。しかしながら、サービスの平均的な CPU とメモリの使用量だけでは、いつ、どの程度までスケーリングアクションを実行すべきかの信頼できる指標とはならないユースケースがいくつかあります。受信した HTTP リクエストの数、キュー/トピックから取得したメッセージの数、実行したデータベーストランザクションの数など、アプリケーションの他の側面を追跡するカスタムメトリクスが、スケーリングアクションのトリガーとしてより適している場合があります。 Application Auto Scaling は、事前定義されたメトリクスだけでなく選択した CloudWatch カスタムメトリクスに基づいてサービスをスケーリングすることもサポートしています。お客様は、プログラミング言語やプラットフォームに適した AWS SDK のいずれかを使用して、アプリケーションから CloudWatchに カスタムメトリクスデータを送信することができます。加えて、2020 […]