タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
AWS、コンテナにWebアプリを置くと簡単にデプロイが完了する「App Runner」リリース。オートスケール、ロードバランス、証明書の管理などすべておまかせ
AWS、コンテナにWebアプリを置くと簡単にデプロイが完了する「App Runner」リリース。オートスケール、ロードバランス、証明書の管理などすべておまかせ AWSは、コンテナに特化したWebアプリケーション実行環境のマネージドサービス「AWS App Runner」をリリースしました。 #AWS App Runner is a fully managed container application service that makes it easy for customers to build, deploy, and run containerized web applications and APIs without container or infrastructure experience.#Developer #CloudComputing https://t.co/eMw
NGINX、商用版の重要な機能をオープンソースで無料化、オートスケールやCI/CDフックなどフルスタック化など、今後の発展についてコミットを発表
NGINX、商用版の重要な機能をオープンソースで無料化、オートスケールやCI/CDフックなどフルスタック化など、今後の発展についてコミットを発表 オープンソースのWebサーバ「NGINX」（エンジンエックス）の開発元であるF5 Networksは、オンラインイベント「F5 NGINX Sprint 2022」を開催中です。 そこでNGINX開発チームは、今後のNGIXの発展に向けて、ソースコードをMercurialからGitHubへ移行すること、有償版の機能をオープンソースへ移植して無料で利用可能にすること、単なるWebサーバ機能だけでなくCI/CD機能などを拡張することなど、3つの約束を発表しました。 GM of #NGINX @rwhiteley0 has just announced three #opensource promises that will come to life
ECS×Fargateのオートスケールをチューニングしてサービス運営費を削減した話 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、ECS×Fargateで運用しているサービスの「ターゲット追跡ServiceAutoScalling」をチューニングをしたことで、費用が約半分になるという大きな成果を残すことが出来たのでその内容を経緯と共にまとめています。 内容はざっくり下記3点です。 なぜオートスケールのチューニングをしたのか? 「ターゲット追跡ServiceAutoScalling」のチューニング方法 どんな結果になったか? なぜオートスケールのチューニングをしたのか? コネヒトではWebのアーキテクチャはほとんどECS×Fargateの基盤で動かしています。そして、オートスケールとして「ターゲット追跡ServiceAutoScalling」を使うことで、Fargateのメリットを最大限活かす形で運用コスト低くサービス運用を実現しています。 ここらの
GitLab RunnerをGCPでオートスケールさせて安く運用する - OPTiM TECH BLOG
こんにちは。Optimal Bizのサーバーサイドに関する開発を担当している伊藤です。 皆さんCIは何を利用していますでしょうか？ Optimal BizではGitLab CI/CDを利用しています。 単体テスト・ビルド・デプロイ等CIの用途は多岐にわたりますが、実際にそれらを実行するPCを必要な数だけ常に起動しておくと無駄な料金がかかってしまいます。 そこで、今回はGoogle Cloud Platform(以降、GCP)のプリエンプティブル VM インスタンスをGoogle Kubernetes Engine(以降、GKE)でオートスケールさせることで、CIリソースを格安で確保する事例を紹介します。 利用例 Optimal Bizチームの場合は「RSpecをGitLab CI/CDを使って並列実行する」で紹介した大量の単体テストを約20台のノードで並列実行するために利用しています。 ざ
こんにちは、技術部 SRE グループ アルバイトの小川です。この記事では、クックパッドでコンテナログの処理に利用している Fluentd ノードのオートスケール対応について紹介します。 クックパッドでは Amazon ECS を用いてコンテナ化されたアプリケーションをデプロイしています。クックパッドでの ECS の利用については過去の記事をご覧ください。 ECS 上で動くコンテナのログを閲覧するために、標準的には Amazon CloudWatch Logs を利用する方法があります。しかし、クックパッドではログ量やコストの問題で CloudWatch Logs は利用せず、独自のログ配送基盤を構築して運用しています。具体的には、ECS のコンテナインスタンスで実行している Fluentd から複数の Amazon EC2 インスタンスで構成される Fluentd 集約ノードにログを転送し
GitHub ActionsのワークフローをオートスケールするSelf-hosted runnerに移行した話 - Mobile Factory Tech Blog
こんにちはエンジニアのEadaedaです。 皆さんのチームではGitHub Actionsを使っていますか？ブロックチェーンチームではテストやリンター、デプロイといったワークフローをGitHub Actionsで行っています。 今まで、デプロイ以外のワークフローはGitHub-hosted runnerで実行、デプロイはSelf-hosted runnerで実行していましたが、運用していくうちに特定の環境内にあるサーバーで実行されるように仕組みを見直す必要がでてきました。このため全てのワークフローをSelf-hosted runnerに移行する対応を行いました。この記事では移行の際に見つけた便利なものや困ったことを紹介します。 Self-hosted runner GitHub Actionsでは、基本的にGitHubが用意したVMでワークフローが実行されます。このVMをGitHub-ho
Masanori Kusunoki / 楠 正憲 on Twitter: "#クラウド蓮舫 がどうして馬鹿にされてるのか分からないけど、オンプレのサーバー増設は時間がかかるけどクラウドなら時間をかけずに増設できるといいたかったのでは？会計法が硬直的で従量課金への対応が困難とか、JPKI関係がオートスケールできない設計であることは枝葉末節で"
#クラウド蓮舫 がどうして馬鹿にされてるのか分からないけど、オンプレのサーバー増設は時間がかかるけどクラウドなら時間をかけずに増設できるといいたかったのでは？会計法が硬直的で従量課金への対応が困難とか、JPKI関係がオートスケールできない設計であることは枝葉末節で
こんにちは、サーバサイドエンジニアの@Juju_62qです。 今回はタイミーで実践しているECSのオートスケール戦略についてお話ししようと思います。 TL;DR タイミーではTarget Tracking ScalingとStep Scalingを組み合わせてオートスケールをしています Target Tracking Scaling -> 通常のスケールアウト・スケールイン Step Scaling -> スパイク時のスケールアウト 2つを組み合わせることで、様々なリクエストに対し適切なリソースを用意しています タイミーのアクセス量の変化とビジネス要求 タイミーのアクセス量の変化とこれまでのオートスケール タイミーは空いた時間に働きたい人とすぐに人手が欲しい店舗・企業をつなぐスキマバイトアプリです。 したがって、仕事の募集数や働いてくださるワーカーさんの数は世の中の動向に大きく左右されます
Sidekiq のワーカーノードをオートスケールさせてEC2の稼働コストを60%削減させるまで - Qiita
「Sidekiq のワーカーノードが稼働する EC2 インスタンスをオートスケールしたい」という依頼人の願いを、匠が叶えます。 このストーリーの登場人物は以下の2人です。 依頼人 = アプリケーションエンジニア or マネジメント層（適宜文脈によって読み替えてください） 匠 = インフラエンジニア Before まずは依頼人が抱えるお悩みについて話を聞いてみることにします。 インフラ構成 依頼人のサーバ構成は、 Sidekiq では標準的な構成を採用していました（図1, 2）。 Web ノードでタスクを Redis 登録し、 Worker ノードで Redis からタスクを取り出し実行します。 Web ノードは API として外部に公開されているほか、 Sidekiq の GUI として利用しています。 各ノードは AutoScalingGroup を構成していますが、台数固定で稼働してい
こんにちは。X（クロス）イノベーション本部 ソフトウェアデザインセンター の山下です。 今回はユーザーに合わせてオートスケールするGitHub ActionsのRunnerについて紹介しようと思います。 課題と目的 公式の推奨している方法について 構築の手順 事前準備 terraformの実行 terraformファイルの作成 terraformの実行 GitHub Appにhookの設定を追加 実際に利用する場合 まとめ 課題と目的 GitHub Actionsを使ってCIを実施するのは一般的になってきています。 ISIDでもGitHub Actionsを活用してCIを実施しています。 しかし、GitHub社が提供しているrunners(GitHub-hosted runners)では困る場合があります。「GitHub Actionsでオンプレミス環境のCI/CDを実行する方法」の記事で
philips-labs/terraform-aws-github-runner でオートスケールするセルフホストランナーの構築・運用 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、生産性向上チームの @miyajan です！ この記事は、Cybozu Advent Calendar 2022 の一日目です。philips-labs/terraform-aws-github-runner を使ってオートスケールする GitHub Actions のセルフホストランナーを構築・運用している知見を書きます。 この話題については過去に発表しましたが、それから一年以上経って変更も多いため、あらためてブログ記事にしました。 背景 サイボウズには、サイボウズ社内のネットワークからしかアクセスできないシステムに依存して開発しているチームが複数あります。これらのチームが GitHub Actions を利用したいと思っても、GitHub が提供する Actions のランナーからはサイボウズ社内のネットワークにアクセスできません。このため、サイボウズ社内の開発チームが G
オートスケールするGitHub Actionsセルフホストランナー環境 tornadeの紹介 ｜Subaru Nakamura(varu3)
はじめにみなさん、GitHub Actionsは利用していますか。 先日、Github actionsのコストパフォーマンスについて検討していた以下の記事が少し話題になっていました。 この記事のデータによると、単純な料金の比較ではFargate Spotを利用してセルフホストランナーを起動するのが圧倒的にコストが低くなるということがわかります。 2022年12月現在、Fargate SpotはEKSに未対応で対応していないため、利用するためにはECSでないといけません。そのため、EKSでオートスケールするので有名な actions-runner-controller ではFargate Spotは利用できません。 そこで思いつきました。ECS上でFargate Spotを利用してオートスケールする仕組みを作れば、より安くセルフホストランナーを利用することができるのではないか、と。 初めにE
こんにちは。search infraチームのmrkm4ntrです。 我々のチームでは検索基盤としてElasticsearchクラスタをKubernetes上で多数運用しています。これらのElasticsearchクラスタを管理しているnamespaceはマルチテナントな我々のKubernetesクラスタの中で最大のリソースを要求しているnamespaceです。 一方でクラスタのサイズをピークタイムに合わせて固定していたため、そのリソース利用率は非常に低いという問題がありました。Elasticsearch EnterpriseやElastic Cloudにはオートスケーリング機能が存在するのですが、これはスケールイン/アウトのためのものではなく、ディスクサイズに関するスケールアップ/ダウンを提供するもので我々の要求を満たすものではありませんでした。 そこで今回は、HPAを用いたスケールイン/
Azure Automationを利用してSQL Databaseをオートスケールしコスト削減させた話 - ZOZO TECH BLOG
こんにちは、開発部の鶴見です。 ZOZOTOWNのリプレースを担当しています。 ZOZOTOWNリプレースですが、オンプレからクラウドに単純に置き換えるのでなく「運用が楽になる」などメリットを考えながら作り替えています。 主にデータベースは、AzureのRDBであるSQL Databaseを利用しています。 先日までSQL Databaseのパフォーマンスとコストがネックになっていました。そこでAzure Automationを利用しSQL Databaseを定期的にスケールアップ/ダウンさせリソース、コストの最適化をしました。 その方法をご紹介します。 はじめに スケールアップ/ダウンについて 多数のモデルが存在するSQL Database モデル選定 オートスケールを考える サンプル（CPUコア数変更） サンプル（クエリ発行） 参考情報（スケールアウト） サンプル（Geoレプリケーショ
【レポート】スパイクにもすぐにオートスケールするようになったAmazon Aurora Serverless v2のDeep Dive #reinvent #EMB023 | DevelopersIO
Amazon Auroraは商用データベースと同等のパフォーマンスと可用性を低コストで実現するRDBです。 2018年から自動的にキャパシティがスケーリングする Aurora Serverless が提供されていましたが、今年の re:invent でその進化版「 Aurora Serverless v2」がプレビュー公開されました。 Aurora Serverless v2 のポイントは次の2点です。 ワークロードに対してより滑らかにスケーリングするようになった Aurora の様々な高機能に対応 本レポートはその v2 の NEW LAUNCH セッションです。 セッション概要 タイトル : [NEW LAUNCH!] Amazon Aurora Serverless v2: Instant scaling for demanding workloads スピーカー : Murali
こんにちは。 GMOアドマーケティングの@zakisanbaimanです。 GCEマネージドインスタンスのオートスケールを用いる際、クールダウン期間を指定できるので実際にどんな動きをするのか確認してみます。 クールダウン期間とは インスタンス生成してから再度オートスケール指標を取得するまでの期間。デフォルトは60秒。 初期化時間よりも短過ぎても長過ぎても良くないらしく、ちゃんと初期化時間を計測して設定すべきとのこと。 公式ドキュメント「クールダウン期間」 確認したいこと アプリケーションが起動する前にクールダウン期間に入ると更にインスタンスが追加されるのか？ 結論 ヘルスチェックで「異常」となったまま、更にインスタンスは追加されない。 【パターン1】クールダウン期間 > アプリケーション起動時間 まずは通常パターン。 アプリケーション起動時間がクールダウン期間に収まる場合はどのような挙動に
Amazon ECS+Fargate まとめ (terraformを使ったクラスタ構築とオートスケール、ブルーグリーンデプロイ) - Qiita
Amazon ECS+Fargate まとめ (terraformを使ったクラスタ構築とオートスケール、ブルーグリーンデプロイ)AWSDockerECSFargateBlueGreenDeployment はじめに コンテナベースでインフラ実現するに伴って色々AWS上でのコンテナ周り調べたり、本番導入した際のまとめ的なメモです。 大雑把にこんなことを書いてます。 構成概念と基礎知識 terraformによるコードデプロイ連携でのブルーグリーンデプロイ terraformによるメトリクスベースでのオートスケーリング ECS+Fargateのインフラアーキテクチャ全体像 * AWS公式からの引用 ECSとは ECSはAWSが提供するk8sと同じようなクラスタ構成でのコンテナオケーストレーション を実現するサービス。 ECSは実際にコンテナが稼働する複数のworkerNodeとその操作・管理を担
actions-runner-controllerでself-hosted runnersをオートスケール
技術本部 サービスリライアビリティグループ（SRG）の松田です。 SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 弊社では一部のプロダクトでGitHub Enterprise Server(以下GHES)を利用しています。GHESでGithub Actionsを使いたい場合、GitHub-hosted runnersは利用できないため、self-hosted runnersを選択することになります。私が関わっているプロダクトでは、既存のCIからGitHub Actionsに移行する予定があり、開発者がカジュアルに試せる環境を用意することにしました。 公式の導入方法のとおりにself-hosted runnersを導入すると以下の課題が
はじめに平素は大変お世話になっております。 クイックガードのパー子です。 ここ 1〜2年の傾向として、弊社でも Kubernetes を扱う案件が増えてきております。 設計から構築、運用まで一貫してお任せいただくことも多いのですが、安定運用するうえでオートスケールの活用は欠かせません。 (というか、これを活用しないと Kubernetes の価値は半減です。) ところが、Kubernetes にはオートスケールの仕組みが何種類もあり、さらにプラットフォーム独自のスケーリング方式も含めると、初見者にはなかなか全貌が把握しづらいところでございます。 そこで、今回は Google Kubernetes Engine (GKE) を対象に、利用可能なすべてのスケーリング方式の概観をまとめてみました。 あくまで概観を眺めるのみに留めており、各方式の具体的な設定方法は説明しませんので、必要に応じてググ
レプリカをオートスケールさせるAmazon Aurora Auto Scalingの導入ポイントをまとめてみた | DevelopersIO
Amazon Aurora Auto Scalingを利用すると、レプリカを動的にスケールアウトできます。 導入のポイントをまとめてみました。 Amazon Auroraデータベースはリードレプリカを最大で15個まで追加できます。 Auto Scaling policyを設定することにより、利用者の多い日中はレプリカを多めに用意し、利用者の少ない夜間はレプリカを減らすといった運用が可能です。 この機能の設定ポイントを解説します。 Amazon Aurora Auto Scaling について Amazon Aurora Auto Scaling はレプリカの平均CPU使用率・接続数に応じて、レプリカをオートスケールさせるサービスです。 スケールアウト方式のため、ワークロードに応じてレプリカ数を増減させるものであり、インスタンスタイプをスケールアップさせるわけではありません。 ECS でも利
GitHub Actions & オートスケールするSelf-hosted runnerで実現する KAGのみんなのCI/CD
2023-04-18 に行われたDevOpsDays Tokyo 2023の登壇資料です。
AWSチームのすずきりょうです。 2021年5月のEC2オートスケールのアップデートで、予測スケーリング (Predictive scaling policies)がサポートされました。 EC2オートスケールを利用中の環境で予測スケールの設定を行い、予測と実績値の差から予測精度を確認する機会がありましたので、紹介させていただきます。 Amazon EC2 Auto Scaling がネイティブスケーリングポリシーとして予測スケーリングを導入 予測スケーリング設定 EC2ダッシュボード Auto Scaling グループ設定に、予測スケーリング(Predictive scaling policies) の項目が追加されました。 ポリシー作成 「Scale basee on forecast」はオフ、EC2のスケールアウトは行わず、予測精度の評価のみを行う設定としました。 オートスケールのしき
[UPDATE] Amazon Redshift Concurrency Scailing（同時実行スケーリング）が書き込みクエリをサポート、更に進化したオートスケールを実際に試してみました！ | DevelopersIO
[UPDATE] Amazon Redshift Concurrency Scailing（同時実行スケーリング）が書き込みクエリをサポート、更に進化したオートスケールを実際に試してみました！ データアナリティクス事業本部コンサルティングチームの石川です。先日、Amazon Redshift の Cluster Version 1.0.28965からConcurrency Scailing（同時実行スケーリング）が、INSERT、DELETE、UPDATE、COPYの書き込みクエリを追加サポートしました。書き込みクエリのサポートによって、ワークロードに応じて素早くスケーリングできるので、よりサーバレスのような従量課金に近い利用が可能になりました。今回はELTワークロードで最も利用頻度の高いINSERT INTO SELECTを同時60クエリで試してみます。 Concurrency Scai
![[UPDATE] Amazon Redshift Concurrency Scailing（同時実行スケーリング）が書き込みクエリをサポート、更に進化したオートスケールを実際に試してみました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/c57359b644462335214acbe5638ccb847b816942/height=288;version=1;width=512/https%3A%2F%2Fcdn-ssl-devio-img.classmethod.jp%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-redshift.png)
ImageBuilder をサポートした CloudFormation で AMI作成から EC2のオートスケール起動まで実装してみた | DevelopersIO
AWSチームのすずきです。 ImageBuilder をサポートした CloudFormationと、AMI IDをサポートした パラメータストアを利用して、 AMI作成から、EC2のオートスケール起動まで 1つの CloudFormationのスタックでの実装を試す機会がありましたので、紹介させて頂きます。 CloudFormation imagebuilder-install-kernelng-jq.yaml IAM AMIの雛形となる EC2環境で利用するIAMロール(インスタンスプロファイル)を設定します。 ImageBuilder が必須とする権限、管理ポリシー「AmazonSSMManagedInstanceCore」「EC2InstanceProfileForImageBuilder」を利用して付与します。 S3へのログ出力を利用するため、ログ出力先とするS3の設定をインライ
はじめに この記事は Amazon EKS #2 Advent Calendar 2019の６日目の記事です。 今回はEKSでオートスケールに挑戦します。 サービスを保守・運用していく中で、リソースが枯渇してサービスの継続が困難になることは避けたいです。 KubernetesではPod(コンテナ)にリソースを割り当てることができ、リソースが不足すると自動でPodを増やす機能があります。 Horizontal Pod Autoscaler ただEC2インスタンスのリソースが不足した場合は、Podのオートスケールは機能しません。(リソースがないから。。。) なので、EC2インスタンスのオートスケールも必要になってきます。 cluster-autoscalerという機能を使ってEC2インスタンスのオートスケールも設定します。 これを設定することで、リソースが必要なときのみEC2インスタンスを作成
はじめに AWSチームのすずきです。 2つの異なるCloudFormationテンプレートで設置したELB(ALB)とEC2(Amazon Linux2)。 EC2インスタンスの起動時に実行されるUserDataを利用して、ELBへの自動アタッチを行う機会がありましたので、紹介させていただきます。 構成図 設定 UserData #cloud-config packages: - jq - httpd runcmd: - export AWS_DEFAULT_REGION=ap-northeast-1 - STACK_NAME=sample-1 - INSTANCE_ID=`curl -s http://169.254.169.254/latest/meta-data/instance-id` - TARGET_GROUP_ARN=`aws cloudformation describe-
この記事は基本的にGKEでの利用を想定して解説していますが、AWS等他のプロバイダでも大きくは変わりません。適時読み替えてもらえると。 クラスタオートスケーラーの課題点 kubernetesでNodeのオートスケールは、ざっくり説明すると以下のような流れになる訳ですが・・・ Podの負荷が上がり、HPAによって新しいPodがスケジューリングされる PodをスケジューリングさせるためのNodeが不足して、新しいNodeが立ち上がる 新しいNodeにPodが立ち上がる このスケーリングには少々問題がありまして、新しいNodeがすぐに有効活用されるかと言えば、そうでも無いんですよね・・・ 時間が経つに連れて新しいNodeにもPodが増えますし、負荷も分散されて行くでしょう。しかし、すでに負荷が上がりきっている既存Nodeに配置されているPodが再スケジューリングされる訳では無いので、急なスパイク
お客さま各位 平素よりさくらインターネットに格別のご愛顧を賜り、誠にありがとうございます。 さくらのクラウドにおいて、サーバーの負荷発生時に対象サーバーのスケールアップおよびスケールアウトを自動で行うことができる機能「オートスケール」のオープンベータ版を、2022年5月26日より無料で提供開始いたします。 詳細は下記をご参照ください。 さくらインターネットでは、今後もよりよいサービスの提供が行えますよう、精一杯努めてまいります。引き続き変わらぬご愛顧を賜りますようお願い申し上げます。 オートスケール（オープンベータ版）について 概要 サーバーに負荷が発生した際に、対象サーバーのスペックアップを行う「スケールアップ」と、台数を増やす「スケールアウト」の両方を自動で行うことができる機能です。サーバーの負荷が解消されると、自動でスケールダウンやスケールインも行われます。負荷検知のトリガーは、さく
https://rakus.connpass.com/event/211175/ 『自動化大好きエンジニアLT会 - vol.3』の発表資料です。 オートスケールする GitHub Actions セルフホストランナーを構築中の知見をまとめました。Read less
ジャスミンソフト、Webアプリの超高速開発ツール「Wagby」に新版、オートスケール環境で動作 | IT Leaders
IT Leaders トップ ＞ テクノロジー一覧 ＞ 開発ツール／プラットフォーム ＞ 新製品・サービス ＞ ジャスミンソフト、Webアプリの超高速開発ツール「Wagby」に新版、オートスケール環境で動作 開発ツール／プラットフォーム 開発ツール／プラットフォーム記事一覧へ [新製品・サービス] ジャスミンソフト、Webアプリの超高速開発ツール「Wagby」に新版、オートスケール環境で動作 2019年7月17日(水)日川 佳三（IT Leaders編集部） リスト ジャスミンソフトは2019年7月17日、超高速開発ツールの新版「Wagby（ワグビィ） R8.3.0」を発表した。7月16日から提供している。新版では、サーバー台数を動的に増やすオートスケール環境でも問題なく動作するように、分散処理の仕組みを変更した。これにより、パブリッククラウドのオートスケール機能と組み合わせて利用できるよ
2021/11/29に、AWSはKarpenterというKubernetesのオートスケーラーをGAリリースしました。 Introducing Karpenter – An Open-Source High-Performance Kubernetes Cluster Autoscaler これは有料のサービスではなく、OSSとしての提供です。現在はAWSのみに対応していますが、構造上はそれ以外のクラウドプロバイダーでも使えるものになっています。 Kubernetesには、既にNodeレベルのオートスケーラーとしてCluster Autoscalerという仕組みがあります。 AWS EKSの場合は、Auto Scaling Group(ASG)の希望のサイズ(Desired Number)を増減させることで、Node(EC2)のスケールアウト・ダウンを実現します。 KarpenterはAS
カスタムメトリクスに基づいた Application Auto Scaling による Amazon ECS サービスのオートスケール | Amazon Web Services
Amazon Web Services ブログ カスタムメトリクスに基づいた Application Auto Scaling による Amazon ECS サービスのオートスケール この記事は Autoscaling Amazon ECS services based on custom metrics with Application Auto Scaling (記事公開日: 2023 年 3 月 14 日) の翻訳記事です。 Introduction Application Auto Scaling は、Amazon Elastic Container Service (Amazon ECS) サービス、Amazon DynamoDB テーブル、AWS Lambda のプロビジョニングされた同時実行などのスケーラブルな AWS サービスに向けた、リソースを自動的にスケーリングするソリ
オートスケール起動のEC2のリモート操作(Run Command)を、権限限定したIAMロールで行ってみた | DevelopersIO
AWSチームのすずきです。 AWS Systems Manager の 実行コマンド(Run Command)を利用する事で、複数インスタンスのリモート操作が可能になります。 今回、SSMドキュメントと実行対象のEC2インスタンスを限定した SSM (Run Command) 操作用のIAMロールを用意、 オートスケールで 起動した EC2インスタンス(Amazon Linux2)の セキュアなリモート操作を実現する機会がありましたので、紹介させていただきます。 構成図 AWS設定 以下のCloudFormationテンプレートを利用して、EC2、IAM、SSMの設定を実施しました。 ssm-sendcomand-ec2-autoscalling-al2.yaml AMI Amazon Linux2 (X86) の最新AMIをパラメータストアから取得して利用しました。 Parameters
月額数百円という格安料金でサーバー利用することができるとして、非常に人気のあるレンタルサーバーになります。 そんなロリポップ！に「マネージドクラウド」というサービスがあります。 急な大量アクセスによるサーバーダウンが防げるということで、大規模サイトも続々と移行しているといいます。
AWS App Runner のオートスケールは GCP Cloud Run ほど滑らかではなさそう - にゃみかんてっくろぐ
方法 同時接続数 4 で観察 AWS App Runner: 20 インスタンスも起動する GCP Cloud Run: 4 インスタンスだけ起動する 突然 20 同時接続して観察 AWS App Runner: 過半数がエラーに GCP Cloud Run: すべて正常応答 まとめ: App Runner のオートスケールは Cloud Run ほど滑らかではなさそう 補足: App Runner の裏側は Fargate タスク (2023/05/06 追記) 先日、 AWS から App Runner というサービスが発表された。すごく GCP の Cloud Run っぽい。 ただ、新規サービス作成に 5 分待たされてしまった。 東京リージョンで nginx サービス作成時間 3 回はかってみたけど - GCP Cloud Run: 25 秒、 12 秒、 8 秒 - AWS Ap
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fluentd 集約ノードのオートスケール - クックパッド開発者ブログ
ECSで通常時とスパイク時のオートスケールを運用する - Timee Product Team Blog
コスト安なCI環境を目指してオートスケールするCI環境を構築する - 電通総研 テックブログ
ElasticsearchをCPU利用率でオートスケールさせる
【GCP】オートスケールのクールダウン期間指定について
GKE のオートスケール 5種類を概観する - QG Tech Blog
予測スケールをサポートしたEC2オートスケールの予測内容を検証してみた | DevelopersIO
EKSでオートスケール ~ PodとEC2どちらも~ | monkey404
非オートスケール起動のEC2をELB(ALB)に自動アタッチさせてみた | DevelopersIO
k8s Deschedulerを使いこなしてスムーズなオートスケールを実現する - Qiita
【さくらのクラウド】新機能「オートスケール」のオープンベータ版を提供開始 | さくらインターネット
オートスケールする GitHub Actions セルフホストランナーを構築してる話
Karpenterのオートスケールを試してみました | 豆蔵デベロッパーサイト
ロリポップ！の「マネージドクラウド」 オートスケール機能でサーバーダウンを防げ！
www.asahi.com
hxxg.fanbox.cc
store.shopping.yahoo.co.jp
www.gamers.co.jp
shop.yushakobo.jp
www.sponichi.co.jp