Amazon Web Services ブログ コンテナの世界での AWS Fargate の役割 2017 年、AWS は、AWS Fargate と呼ばれる大規模なコンテナを実行するサーバーレスサービスを導入しました。今日、お客様は毎週何百万ものコンテナをローンチしています。お客様が Fargate を好むのは、多くのインフラストラクチャにまつわる未分類の重労働から解放してくれるからだと繰り返し伝え聞いています。たとえば、お客様は EC2 フリートまたはコンテナランタイムのサイズ変更、スケーリング、パッチ適用、更新について責任を負う必要がなくなりました。 過去 2 年間で気付いたのは、Fargate は非常に斬新なアイデアであることから、お客様の中には大規模な AWS コンテナポートフォリオの特定のレイヤーに入れるのが難しいと感じていらっしゃる方もおられるということです。当社は、お客様
お仕事でAWS環境を構築する機会がありましたので、今回はじめてCDKを使って構築してみました。CDKで環境構築する記事はたくさんありますので全体は割愛するとして、本記事ではCDKを使ったECS(Fargate) Serviceのデプロイフローにフォーカスしてご紹介します。 バージョン $ cdk version 1.32.0 (build 9766ad6) 全体構成 全体構成としては、以下の図のようにオーソドックスなWeb3層アプリケーションの構成です。 ECS Serviceに関連する主なリソース構成を以下の図に示します。 このリソース構成のうち、緑色の線で示したリソースはインフラ管理用のCDKで管理し、オレンジ色の線で示したリソースはECS Serviceデプロイ用のCDKとしてアプリケーションのリポジトリで管理しています。 デプロイフロー デプロイフローを以下の図に示します。 Git
@laugh_k です。先週 SQUEEZE のソリューション事業のプロダクトである suitebook のインフラ環境をローンチ当初から使われていた ElasticBeanstalk ベースの環境から ECS on Fargate の環境への移設を行いました。今回はその移設がどのような検証・手順を経て行ったのかを紹介します。 背景ElasticBeanstalk 時代ElasticBeanstalk は Heroku を使うような感覚でAWS上で手軽にアプリケーションを動かせるのが魅力で、スタートアップのサービスローンチ当初にはさくっとデプロイできる感じもマッチしていました。ですが、プロダクトの成長とともに問題も多く発生していきました。 手軽に利用できる半面、Python3.6 への対応がなかなか来なかったり、Apache + mod_wsgi 以外の Web サーバが選択できなかったり
Amazon Web Services ブログ [AWS Black Belt Online Seminar] AWS Fargate 資料及び QA 公開 先日 (2019/9/25) 開催しました AWS Black Belt Online Seminar「AWS Fargate」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190925 AWS Black Belt Online Seminar AWS Fargate AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. CloudFormationでの設定は可能でしょうか ? A. Fargate を利用した ECS サービスの作成、および、タスク定義での Fargate 起動タイプとの互換性の設定については、いずれも CloudFromtionでも設定可能
CloudWatchだけでは実現できない超高速なFargateのスケール処理をCDKをつかったStep Functionsで実装しているリポジトリです。是非参考にしてみてください。 「Fargateをいかに早くスケールさせるか、そこに命をかけた男がいた…」 先日参加したセミナー（コンテナ好き4名がコンテナの魅力を喋り倒すJAWS-UGコンテナ支部に行ってきた）にそんな男がいたわけですが、その仕組を改めて動かす機会があったので、紹介します。 CloudWatchを利用しないStep Functionsを利用した爆速スケールの仕組み CDKによる環境一式のデプロイ という両面で非常に参考になるリポジトリです。そのあたり興味があるかたは是非一度この記事を読んでいただきながら皆さんの環境でためしていただきつつ、今後のStep Functionsの使い方やCDKのサンプルとして活用いただければと思い
冒頭、発表者からの参加者へEKSやKubernetesの利用について質問。会場内にはEKS使っている方がちらほら。EKS以外のKubernetes経験者もそこそこ（GKEやAKSの経験者の方なのかも？）。 サービスは3人で開発。PostgreSQLが好きなのでAurora PostgreSQLを採用。ブロックチェーン特有（イーサリアム向けのクライアントParity利用）で、EC2+EBSでの運用が辛い問題があるとのこと。 Kubernetes（EKS）ではPersistentVolume（実体はEBS）を使う、世代管理できるようにLifecycle Managerを使う工夫をしている。ただ、AZまたげないツラミがあるらしい（非推奨とも言われることもあるとのこと）。 LB配下にStateful Setsを並べる作戦というのも1つはある。Amazon Managed Blockchainに期待
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く