TerraformでFargateのSidecarを実現しよう - Tech Blog - Recruit Lifestyle Engineer
こんにちは！リクルートライフスタイルの共通クラウド基盤でリードクラウドアーキテクトをしている須藤です。 この記事は AWS Advent Calendar 2018 の2日目の記事です！( リクルートライフスタイル Advent Calendar 2018 2日目の記事でもあります) リクルートライフスタイルの共通クラウド基盤では、サービスごとにアカウントを払い出して、サービス開発者がその環境を構築する、というスタイルです。クラウドアーキテクトチームはCCoE(Cloud Center of Excellence)であり、TerraformやFargateを使いたい、という開発者に対しては、ペアプログラミングやアーキテクチャレビューなど、規範的・助言的な活動を通して成長しあっていく、という活動をしています。 当然、re:Invent 2018で発表された トランジットゲートウェイ や AW
Amazon ECS にデーモンスケジューリングが追加
Amazon Elastic Container Service (Amazon ECS) は今回、新しいデーモンスケジューリングストラテジーを導入し、ECS クラスター内で選択したインスタンスセット内のインスタンスすべてに対してデーモンタスクを自動で実行できるようになります。 デーモンタスクとは、ロギング、モニタリング、またはアプリケーションコードを実行するタスクのバックアップのような共通サポート機能を付与するために、クラスター内のそれぞれのインスタンスにタスクがデプロイされたマイクロサービスをビルドするときに使用されるパターンのことです。 これまでは、これらを確保するために、デーモンタスクは Auto Scaling テンプレートに結び付いた複雑なスクリプトの実行を要するクラスター内のインスタンスセットにデプロイされていました。ユーザーは代わりに各アプリケーションタスクの一部としてデー
Amazon ECSとKubernetesの統合サービスディスカバリー | Amazon Web Services
Amazon Web Services ブログ Amazon ECSとKubernetesの統合サービスディスカバリー 本日（訳注：2018年5月31日）から、Amazon Elastic Container Service（Amazon ECS）およびKubernetesによって管理されるサービスの統合サービスディスカバリーを活用することができます。私たちは最近、Amazon Route 53 Auto Naming（オートネーミング）APIを使用してサービス名のレジストリを作成および管理することにより、コンテナ化されたサービスの発見と相互接続を容易にするECSサービスディスカバリーを導入しました。サービス名は、一連のDNSレコードセットに自動的にマップされます。これにより、コード内でサービスを名前（backend.example.comなど）で参照可能となり、実行時にサービスのエンドポ
Running AWS Fargate with virtual-kubelet | Amazon Web Services
AWS Open Source Blog Running AWS Fargate with virtual-kubelet 中文版 AWS Fargate is a new compute engine that allows you to run containers without having to provision, manage, or scale servers. Today, Fargate is natively integrated with Amazon Elastic Container Service (ECS). Since we announced Fargate at re:Invent 2017, many customers have told us that they were very interested in using Fargate to r
Amazon ECS にサービスディスカバリーを導入
Amazon Elastic Container Service (Amazon ECS) に統合サービスディスカバリーが加わり、コンテナ化したサービス同志がディスカバー、接続しやすくなりました。 以前は、サービスが互いにディスカバーして接続できるように、独自のサービスディスカバリーシステムを構成して実行するか、すべてのサービスをロードバランサーに接続する必要がありました。現在は、ECS コンソール、AWS CLI、または ECS API を使用して、コンテナ化したサービスのサービスディスカバリを簡単に選択できるようになりました。 Amazon ECS は、Route 53 Auto Naming API を使用してサービス名のレジストリを作成および管理します。名前は自動的に一連の DNS レコードにマップされるので、エイリアスでサービスを参照し、このエイリアスを実行時に自動的にサービスの
Amazon ECS Console でコンテナサービス Auto Scaling のターゲット追跡が可能に
今後は、Amazon ECS コンソールから直接、コンテナ化したサービスに対するターゲット追跡ポリシーを使用して、サービス Auto Scaling をセットアップできるようになりました。ターゲット追跡で「Average CPU Utilization」、「Request Count Per Target」など、サービスのロードメトリックを選択する場合は、ターゲット値を設定することで、Auto Scaling がターゲット値を保持するためにサービスの稼動タスクの数を調整します。 以前は、ステップの拡大ポリシーを使用して Amazon ECS を自動的に拡大することができましたが、それには、スケーリングの調整をトリガーするメトリックスで CloudWatch アラームを作成および管理する必要があります。
スポットインスタンスを効率的に管理するSpotinstを使おう - ABEJA Tech Blog
みなさん、AWSのスポットインスタンスは使っていますか？ スポットインスタンスを使えばオンデマンドインスタンスの約70-80%引きでEC2を利用でき、大きなコスト削減が出来ます。 しかし、スポットインスタンスは価格変動が起きるとインスタンスが停止したりするリスクがありますよね？ その辺りのリスクをヘッジしてくれるのがSpotinstというサービスになります。 Spotinstは価格変動によるリスクヘッジだけじゃないメリットがたくさんあるので紹介したいと思います。 Spotinstは何個かサービスがあるのですが、その中のElastigroupという機能を主に説明していきます。 結論 先に結論書いておきます。 かなり安いから使わない理由は無いです。Pricingの項目を参照ください。 Elastigroupとは spotinst.com トレンド分析 Elastigroupは独自の予測アルゴリ
新しいマネージドコンテナサービスAWS Fargateの価格は高いか安いか？ECS/Fargateのコスト最適化を考えてみよう - Qiita
m5シリーズであれば価格は性能と線形なので、たとえばm5.24xlargeでも倍率は同じx2.11になるためとりあえず比較しやすい上記に絞りました。 最新世代のm5やr4と比べて、おおむね２倍強の価格です。 Fargate高くない！？ と思ったアナタ。ちょっと待ってください。 ECS Cluster AutoScaling構成との比較 多くの場合、ECSではそのメリットを享受するためにAutoScaling構成を取ります。たとえば、 MemoryReservation >= 60% で Scale-out MemoryReservation < 30% で Scale-in と設定するとしましょう1。この場合、実際に確保されるメモリ容量の割合は6割を超えません。 簡単のため、ECSでのリソース利用率はvCPU・メモリともに上記の中央値である45%程度であると仮定しましょう。 Fargate
ECSのオートスケール戦略 - Carpe Diem
概要 ECSはコンテナのスケールアウトとインスタンスのスケールアウトのタイミングが重要です。 よく起きる問題としては インスタンスのスケールアウトが遅くてコンテナのスケールアウトも遅くなってしまう しきい値が不適切でインスタンスがスケールアウトせず、コンテナがスケールアウトしたくてもできない で、こういった事が起きないようにしないといけません。 スケールアウトの方針 対象 方針 インスタンス インスタンスの空きリソースがコンテナ１台分だけの状態がｎ分間続いたら コンテナ コンテナの使用率がｎ%を超えたら インスタンスはもう１台もコンテナを追加するリソースがない状況になったら早めにスケールアウトします。 コンテナは一般的なやり方で使用率が高くなったらスケールアウトすればOKです。 スケールインの方針 対象 方針 インスタンス コンテナがｎ分間ずっと１台を下回ったら コンテナ コンテナの使用率
Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ | Amazon Web Services
Amazon Web Services ブログ Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ 本日よりAmazon EC2 Container Registry (Amazon ECR)で利用可能になったライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。 Amazon ECRはフルマネージドのDockerコンテナレジストリで、同時に何百ものプルを捌くための典型的なスケールの問題を心配することなく、Dockerコンテナイメージを保存し管理しデプロイすることができます。スケールの意味する所として、Amazon ECRを活発に利用している開発チームはしばしばたくさんのコンテナイメージのバージョンによってレポジトリが埋め尽くされていることを発見すること
Amazon ECS ScheduledTaskで実現するスマートなDockerベースのバッチ実行環境 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 コネヒトでは、開発環境に続き、続々と本番サービスにもDockerを導入しています。 今回は、中々運用が大変なcronでスケジュール管理するような定期的なバッチ処理を、Amazon ECSのScheduledTaskを使ってDocker駆動な環境で構築した話です。 他の方法との比較やどのように実現しているのかについて紹介したいと思います。 今回対象とするバッチの種類 今回対象とするバッチ処理は、俗に言うスケジュール系のバッチ処理で、毎日00時00分や10分毎にサイクル起動等、事前に定義した時間に正確に動くことが期待されているものです。 ※ジョブキュー形式のバッチだと、AWS BatchやEBのWorkerもしくは、SQS + Cron on EC2で処理するほうがスマートかと思います。 実行方式の選定 上記要件のバッチを実現する基
GitHub - ExpediaGroup/c3vis: Visualize the resource utilisation of Amazon ECS clusters
Helps visualize the resource reservation of Amazon ECS clusters. Deploying software as “containers” promises to solve many problems with regards to interoperability of environments, speed to deploy, and cost reduction. But understanding where our software lives now becomes more difficult both for development and operations teams. This is due to the fact that it is quite laborious to find the infor
ECS運用のノウハウ - Qiita
関連記事 マイクロサービスを支えるインフラアーキテクチャ (AWS Dev Day 2019登壇資料) ECSデプロイツールを公開しました ECSにおけるログの取り扱いを別ページに移動させました 設計 基本方針 基盤を設計する上で次のキーワードを意識した。 Immutable infrastructure 一度構築したサーバは設定の変更を行わない Infrastructure as Code インフラの構成をコードで管理 (Terraformを採用) Serverless architecture 無駄にサーバを増やさない アプリケーションレイヤに関して言えば、Twelve Factor Appが参考になる。コンテナ技術とも親和性が高い。 ECSとBeanstalk Multi-container Dockerの違い 以前に記事を書いたので、詳しくは下記参照。 Dockerコンテナデプロイ
「JAWS-UG コンテナ支部 入門編 #4」に参加して ECS の事例を聞いてきた - kakakakakku blog
3/30(木) に参加して既に3週間もたってしまったけど，ECS の事例を聞きたいなと思って「JAWS-UG コンテナ支部 入門編 #4」に参加してきた．今回は「入門編」だったので，僕のレベル的にちょうど良いなと思った．あと JAWS 系のイベントは “19-21時” でサクッと終わるため，集中して学んで帰れるのも嬉しいポイントだと思う． jawsug-container.connpass.com Docker と Docker Hub の操作と概念 @zembutsu 技術（コンテナ）と仕様（Docker） dockerd → containerd → runC → Linux Kernel 通常の Linux では /sbin/init が PID 1 だけど，コンテナの中で httpd など，起動しているプロセスが PID 1 になる コンテナホストから見ると，その httpd は
コンテナ支部の＃４にいってきた - smallpalace's blog
こんにちは。smallpalaceです。 3末にJAWS-UGのコンテナ支部の#4に行ってきましたので備忘録です。 https://jawsug-container.connpass.com/event/51776/ ハッシュタグ：#jawsug_ct https://twitter.com/search?f=tweets&vertical=default&q=#jawsug_ct&src=tyah あとで↓こちらで配信されると言っていました。 https://crash.academy/ --- 前佛さん CLIなどの話 http://docs.docker.jp/ コンテナは技術、Dockerは使用 DockerHubが中継点 コマンドでコンテナとイメージを操作 技術と仕様 技術はコンテナ、仕様は使用 環境が異なる問題を解決 すべての依存関係をパッケージ化してコンテナとして動かす Li
構築でつまづかないためのECS+ALB構成ベストプラクティス(2016年版) | 技術畑 | 情報畑でつかまえて
構築でつまづかないためのECS+ALB構成ベストプラクティス(2016年版) 本記事ではECS-optimized AMIを使った構築を前提とし、つまずきやすいポイントにフォーカスしてECS+ALB構成でのベストプラクティスをご紹介します。
AWS Solutions Architect ブログ
本日私達はBloxという新しいオープンソースプロジェクトをAmazon ECSチームから発表しました。これによって、ECS上にカスタムスケジューラや他のツールを開発することができます。Bloxの目標は、カスタムスケジューラ、ダッシュボード、その他の拡張を作ることをシンプルにするためのツールを提供することで、皆さんの特定のユースケースの要件に合わせることができます。 ECSは先日、イベントストリームが利用可能になったこともアナウンスしており、これによってECSコンテナインスタンスとタスクの状態変化が[cloudwatch_events]に送られます。スケジュールワークフローを開発するお客様はしばしばECSクラスタで生成されたイベントを受け取り、この状態を手元に保存して、ローカルのクラスタの状態を使って操作を行います。Bloxにはこの機能とローカルのクラスタの状態をREST APIで提供するc
Amazon ECSでAuto Scaling | Amazon Web Services
Amazon Web Services ブログ Amazon ECSでAuto Scaling Amazon EC2 Container Service (Amazon ECS)のClusterを自動的にスケールさせる方法はありましたが、本日Auto ScalingとAmazon CloudWatchのAlarmに追加された新機能により、ECSのServiceにScaling Policyを利用することができます。ServiceのAuto Scalingにより、需要が高まった時にスケールアウトさせて高い可用性を実現したり、需要が下がったらServiceとClusterをスケールインさせることでコストを最適化するのを、全て自動でリアルタイムに行うことができます。 この記事では、Clusterを需要に合わせて自動的にリサイズさせつつ、この新しい機能がどうやって利用できるかをお見せします。 Se
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JAWS-UGコンテナ支部 入門編 #4 で登壇しました #jawsug_ct | 技術畑 | 情報畑でつかまえて
SpotFleet+ECS+ALB構成を試したら気持ち良かったからAWSLambdaで痒いところをさらに気持ち良く | 技術畑 | 情報畑でつかまえて