【AWS】大規模なバッチ処理を支える技術選定
ここから、表で挙げた内容をそれぞれ解説していきます。 構築難度に関しては、関数を実装するだけで済むLambdaが最も簡単で、バッチ専用に特化されたサービスであるBatchに関しては比較的バッチ構築はしやすい印象ですが、ECSに関してはバッチに特化していないため、バッチ処理を行うようにカスタマイズする必要があります。 タイムアウト制約に関して留意すべきは、Lambdaの実行時間は15分までなので、それ以上を超える処理時間のバッチは実装できないことです。 起動•実行上のオーバーヘッドに関しては、Lambdaにはコールドスタートがあるため起動時にオーバーヘッドを考える必要があり、Batchではジョブをキューに送信して、最適化のために、ある程度のジョブがキューイングしてから実行しようするので、即時性を求める処理には不向きです。 既存バッチを移行したいケースがあると思いますが、Lambdaで動かせる
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
Amazon ECS による AWS Fargate のクロック精度のモニタリング
AWS Fargate で実行している Amazon ECS タスクのシステム時間の精度をモニタリングできるようになりました。 Fargate で動作するタイムセンシティブなワークロードの場合、これによりお客様はクロックエラーのプロキシとして使用されるクロックエラーバウンドをモニタリングし、基準時間とシステム時間の差が閾値を超えたかどうかを知ることができます。この機能は Amazon Time Sync Service を利用して、クロック精度を測定し、コンテナのクロックエラーバウンドを提供します。 クロックエラーバウンド情報は、AWS Fargate が利用可能なすべての AWS リージョンにおいて、タスクメタデータエンドポイントバージョン 4 を通じたクエリの実行に利用することができます。クロック精度とクロックエラーバウンドの詳細については、こちらのブログ記事を参照してください。
Fargate での Amazon ECS タスクのヘルスチェック失敗のトラブルシューティング
解決策 最も一般的なロードバランサーエラーのトラブルシューティング 次のエラーのいずれかが表示される場合: 「(サービス AWS-service) (ポート 8080) は、(理由 コード [502] でのヘルスチェック失敗) または [リクエストタイムアウト] のため、(target-group arn:aws:uxyztargetgroup/aws-targetgroup/123456789) で異常です」 「(サービス AWS-Service) (ポート 8080) は、(理由 ヘルスチェック失敗) のため、target-group tf-20190411170 で異常です」 次のトラブルシューティング手順を試してください。 コンテナがポート 80 にマップされている場合は、コンテナセキュリティグループがロードバランサーに対してポート 80 のインバウンドトラフィックを許可しているこ
Amazon ECS+FargateでRailsを動かす際の最適なパラメーターを考えてみる - ユニファ開発者ブログ
こんにちは、最近野菜が高いのでもやしばかり食べているWebエンジニアの本間です。 そろそろレタスが食べたい...。 さて、ここ1、2年、ユニファではAmazon ECS+AWS Fargateを使用して、Railsアプリケーションを本番運用することが増えてきました。 stagingでテストしたDockerイメージがそのまま本番で使えて安心だったり、オートスケールが簡単だったりとメリットが多く、大変便利だと感じています。 ただ、そのような環境を構築する中で、vCPU数やメモリ量、およびPumaの並行性に関するパラメーターをどうしようか毎回悩んでいたため、この辺で自分の中で整理しておこうと思います。 前提 下記を使用したWebアプリケーションを前提にします。 Amazon ECS AWS Fargate Puma Ruby on Rails MRI(CRuby) このようなシステム構成において
Amazon ECS Anywhereを使ってAWS外でもコンテナが運用できるようになったので使ってみた | DevelopersIO
5月27日にECSの機能を利用してオンプレミスでもコンテナの実行、管理を可能にするAmazon ECS Anywhereが利用可能になりました。 今回はそれを使ってUbuntu上にECSからコンテナを起動させてみたいと思います。 Amazon ECS Anywhere ECSは従来EC2やAWS FargateなどAWSが提供するコンピュートリソース上でのみ実行可能でした。 しかし、今回提供されたAmazon ECS Anywhereを使用すればオンプレミスでも今までと近い操作でコンテナの実行、管理が可能となります。 AWSが提供しているECSのコントロールプレーンに自分で用意したインスタンスを接続すればクラスターに参加できます。 EC2のECSインスタンスをオンプレミスで立ち上げてるような状態です。 仕組みとしてはSystems Manager Agentがインスタンス内で実行され、それ
ecs execute command が失敗した際に調査したこと
概要execute command を有効化させたが、 ecs execute command を実行した際にエラーが発生した為、その調査方法をまとめました。 An error occurred (InvalidParameterException) when calling the ExecuteCommand operation: The execute command failed because execute command was not enabled when the task was run or the execute command agent isn't running. Wait and try again or run a new task with execute command enabled and try again.
ECS Exec による Amazon ECS コンテナのモニタリング - Amazon Elastic Container Service
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 ECS Exec による Amazon ECS コンテナのモニタリング Amazon ECS Exec を使用すれば、最初にホストコンテナのオペレーティングシステムとやり取りしたり、インバウンドポートを開いたり、SSH キーを管理したりすることなく、コンテナと直接やり取りできます。ECS Exec を使用して、Amazon EC2 インスタンスまたは AWS Fargateで実行されているコンテナでコマンドを実行したり、シェルを取得したりできます。これにより、診断情報を収集し、エラーを迅速にトラブルシューティングすることが容易になります。例えば、開発コンテキストでは、ECS を使用して、コンテナ内のさまざまなプロセスと簡単にやり取りし、アプリケーションのトラブルシュ
Fargate の Amazon ECS タスクに対する静的 IP アドレスまたは Elastic IP アドレスの使用
AWS Fargate の Amazon Elastic Container Service (Amazon ECS) タスクに静的 IP アドレスまたは Elastic IP アドレスを使用したいと考えています。 簡単な説明 静的 IP アドレスまたは Elastic IP アドレスを Fargate タスクに直接追加することはできません。Fargate タスクで静的 IP または Elastic IP を使用するには、まず Network Load Balancer で Fargate サービスを作成する必要があります。その後、タスクの Elastic IP アドレスをロードバランサーにアタッチします。 次のいずれかのオプションを選択してください。 インバウンドトラフィック用の Fargate タスクの静的 IP アドレスを作成するには、「解決策」セクションの次の手順を実行します。 ア
ECS+Fargate の Public IP を固定 IP にしたい
やりたいこと Amazon ECS+Fargate を構築し、Public IP アドレスを割り当てています Internet Gateway へのルートを持つ Public Subnet にこれを配置してます 遊びでやってるので、Public にしてます （Private だと AWS 料金が増えるからです） この Public IP アドレスがデプロイ時に ECS タスクを作り変えるたびに変わってしまうので、これを固定させたいと考えています 調べると 2 通りのやり方がありそう Network Load Balancer（NLB）を使う NLB に Elastic IP を割り当てる ちなみに Fargate に直接 Elastic IP を割り当てることは現状できない（ECS の起動タイプが EC2 ならいける） Fargate と同じ Subnet 内に NLB を配置する NAT
AWS CDKにECSを高速でデプロイするhotswap deployments機能が追加されました
はじめに おはようございます、加藤です。先日、こちらの記事で紹介しましたが、AWS CDKは本来Cloud Formationテンプレートを生成してデプロイを行いますが、Lambda関数をデプロイする際にCloud Formationを使用せずにAWS SDKを使うことで高速にデプロイする機能が登場しました。この機能はhotswap deploymentと呼ばれます。 昨日、v1.128.0がリリースされ、hotswap deploymentにECSサービスが対応しました。また、気づいていませんでしたがStep Functionsも対応していました。 デプロイ速度 具体的にどれぐらい早くなるのか、ecs-patternsのApplicationLoadBalancedFargateServiceを使った構成で試してみました。使用したDockerfileとアプリケーションは下記のとおりです。
CodePipelineを経由した場合にtaskdefinitionに含まれる環境変数のマルチバイト値がエラー判定される - zuntan02のはてなブログ
【結論】 2020年12月末現在、CodePipelineを経由した場合にtaskdefinitionに含まれる環境変数のマルチバイト値がエラー判定される問題は回避できない。 【AWSへの問い合わせ】 現在ecsのタスク定義ファイルを手動で作成しておりますが、以下のように環境変数に全角文字を使用したいと考えております。 "environment": [ { "name": "HOGE_USE_FUGA", "value": "日本語API" }, （略）この状態のtaskdef.jsonをartifactとした場合に、 CodePipelineでは 無効なアクション設定 Failed to validate the task definition. Check the task definition in the "TaskDefinitionTemplateArtifact" param
ECS FargateでGoコンテナを起動してローリングアップデートする - My Note
はじめに アーキテクチャ GitHub ECRに登録するGoコンテナを作成する docker imageを作成 ECRにdocker imageをpushする ECS Fargateのタスクを作成する ECS Fargateのサービスを作成する ALBを作成する サービスをつくる CodePipelineを作成する Source ( GitHub ) CodeBuild CodeDeploy ローリングアップデートの実行と動作確認 ローリングアップデート 動作確認 まとめ はじめに 今回は ECS FargateでGoコンテナを起動してローリングアップデートする をテーマに書いていきます。 以前の記事でGAEにGo echoで実装したAPIをデプロイしました。 yhidetoshi.hatenablog.com 今回はこのAPIをECSのFargate上にデプロイしてコンテナをローリングア
JAWS-UG金沢 AWS無料勉強資料集
※難易度はJAWS-UG金沢 尾崎が格付けしたものです ※ハンズオンの内容を閲覧し、格付けを変更する場合があります
新サービスAWS App Runnerがローンチされたので試してみた | DevelopersIO
はい、どーも！CX事業本部の吉田です。 新サービスApp Runner 新サービスApp Runnerがローンチされましたね。 App Runner は Web アプリや API サーバの実行に必要なネットワークやロードバランサなどをフルマネージドに提供します！ パイプラインやオーケストレータについても一切考えずにお手元のコードを AWS 上で実行できて最高です✨✨ / "Introducing AWS App Runner ..." https://t.co/o7Vke20gFm 2/n — Tori Hara (@toricls) May 18, 2021 App Runnerはざっくり言うと、コンテナ化したWebアプリを簡単にデプロイできるサービス。ロードバランサやAuto Scaling、果てはソースコードリポジトリと連携したパイプラインの仕組みまで、フルマネージドで提供するサービ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TaskSet - Amazon Elastic Container Service
HealthCheck - Amazon Elastic Container Service
GitHub - aws-containers/amazon-ecs-exec-checker: 🚀 Pre-flight checks for ECS Exec
2021年コンテナ最前線〜今AWSでコンテナホストするならなにが現実解なのか？〜
アプリケーション開発者は Amazon ECS あるいは Kubernetes をどこまで知るべきか #AWSDevDay / You build it, you run it
