[B! aws][ecs] yukungのブックマーク

ECSのオートスケール戦略 - Carpe Diem

概要 ECSはコンテナのスケールアウトとインスタンスのスケールアウトのタイミングが重要です。よく起きる問題としてはインスタンスのスケールアウトが遅くてコンテナのスケールアウトも遅くなってしまうしきい値が不適切でインスタンスがスケールアウトせず、コンテナがスケールアウトしたくてもできないで、こういった事が起きないようにしないといけません。スケールアウトの方針対象方針インスタンスインスタンスの空きリソースがコンテナ１台分だけの状態がｎ分間続いたらコンテナコンテナの使用率がｎ%を超えたらインスタンスはもう１台もコンテナを追加するリソースがない状況になったら早めにスケールアウトします。コンテナは一般的なやり方で使用率が高くなったらスケールアウトすればOKです。スケールインの方針対象方針インスタンスコンテナがｎ分間ずっと１台を下回ったらコンテナコンテナの使用率

yukung 2017/10/20

リンク

[AWS]ECSとALBを使ったパスに従ったルーティング | DevelopersIO

コンニチハ、千葉です。 ALBのパスベースルーティングを利用すると、URLに従ったターゲットグループ(インスタンスのグループ)へルーティングできます。ECSも、こちらのパスベースルーティングに対応しているため試して見ました。【新機能】新しいロードバランサー Application Load Balancer（ALB）が発表されましたメリット振り分けのイメージです。このように1つのALB、1つのECSクラスター上で、ECSサービス(コンテナ群)に対しパスルーティングを行えます。これの応用ですが、以下のような構成も可能です。 Classicロードバランサー時代アプリケーションを分けるには、アプリケーションごとにロードバランサーを用意する、または1つのロードバランサーとアプリケーションごとにポートを用意するという構成しかありませんでした。大きなメリットしてALBでは、ロードバランサー1

yukung 2017/08/10

リンク

Amazon EC2 Container Service(ECS)の概念整理 - Qiita

概念図とりあえずECSに出てくるエンティティがそれぞれどんな多重度で関連しているのかをまとめてみました。ここからはそれぞれのエンティがどんな概念なのかを解きほぐしていきたいと思います。図1 概念図 Serviceが中心 ECSは平たく言うとクラスター（＝複数EC2インスタンスの集合）の上で Dockerコンテナを使って、 Serviceを動作させるものです。図2 例えばの構成上図は、 Front Service (裏にいるAPIをCallしてWEB UIを提供するもの） API Service （ビジネスロジック、DBへの読み書きをRESTful APIで提供するもの）と言う２つのService で構成されるWEBアプリケーションの例です。 ECSで言うServiceは、Serviceは利用者から見た「サービス」よりも一段階か二段階細かいもので、APIサーバーとか、フロントサ

yukung 2017/07/18

リンク

production環境でRailsアプリをdockerコンテナとしてECSで運用するために考えたこと - Qiita

実際には、まだ本当の本番環境では運用できてなくて開発用のステージングで運用が開始できたぐらいで、他にもやること一杯あるんだけど、ある程度知見が溜まったのでまとめておく。ちなみに、規模はそんなに大きくないがデータ量は多いアプリケーションで運用環境はAWSのECSを想定しており、現時点で普通のEC2ノードとコンテナで並行稼動している。 docker-swarmなりで自前でコンテナプールを構築してもいいのだが、そうするとサービスディスカバリとか考えなければいけないことが増えるので、後回しにしている。 (注: かなりサービス固有の事情が含まれるため、もし参考にされる方が居たとしても、そのままの形では適用できない可能性が高い) 追記: RailsアプリのためのDockerfileとdocker-compose.ymlのサンプル - Qiita コンテナ化のモチベーション CentOSのお守りからの

yukung 2017/07/14

リンク

ECS を利用したオフラインジョブの実行環境 - クックパッド開発者ブログ

技術部の鈴木 (id:eagletmt) です。クックパッドでは以前からアプリケーションの実行環境として Docker を利用していましたが、最近は徐々に Amazon EC2 Container Service (ECS) を利用し始めています。去年の時点での Web アプリケーションのデプロイ手法 *1 や、最近 ECS を利用してどう Web アプリケーションをデプロイしているか *2 については紹介したことがあるので、今回は定期的なバッチ処理やジョブキューを介して非同期に実行されるようなオフラインの処理について、どのような環境を構築しているか紹介したいと思います。 Docker を使う前 Docker を利用し始めるより前から社内では kuroko2 *3 というジョブ管理システムが稼動しており、複数のアプリケーションから利用されていました。 kuroko2 は定期的にジョブを