クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（前編）。JAWS DAYS 2014
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（前編）。JAWS DAYS 2014 大規模なオンラインサービスを支えるためのオートスケールと、サービスをすばやく進化させていくための迅速なデプロイ。クックパッドはこの2つをクラウド技術の組み合わせによって両立させています。 同社のインフラ責任者である成田氏がその仕組みやルールを、Amazonクラウドのユーザーコミュニティ主催のイベントJAWS DAYS 2014で解説しました。 本記事では、その講演内容をダイジェストで紹介します。
YAP(achimon)C::Asia Hachioji 2016 mid
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
【Unite Tokyo 2019】Unityだったら簡単！マルチプレイ用ゲームサーバ開発 ～実践編～UnityTechnologiesJapan002
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（後編）。JAWS DAYS 2014
クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側（後編）。JAWS DAYS 2014 大規模なオンラインサービスを支えるためのオートスケールと、サービスをすばやく進化させていくための迅速なデプロイ。クックパッドはこの2つをクラウド技術の組み合わせによって両立させています。 同社のインフラ責任者である成田氏がその仕組みやルールを、Amazonクラウドのユーザーコミュニティ主催のイベントJAWS DAY 2014で解説しました。 （本記事は「クックパッドのデプロイとオートスケール（前編）。JAWS DAYS 2014」の続きです） オートスケールはAmazon Auto Scalingを使わないと判断 今日の本題であるオートスケールの話をしたいと思います。 オートスケールとは一般に、トラフィックが増えたらサーバを増やしましょうね、という作業を自動化するものです
「ちょうどいい」オートスケールを実現する「ロリポップ！マネージドクラウド」、研究・技術・開発が一体となった舞台裏に迫る！ - はてなニュース
GMOペパボが正式リリースしたばかりの「ロリポップ！マネージドクラウド」は、GMOペパボ研究所の成果であるFastContainerを基盤技術として適用し、新しいアーキテクチャを作り上げました。これにより、Webサイトの負荷増大に対応してスケールする仕組みを、エンジニアではない利用者でも簡単に扱うことができます。 ロリポップ！マネージドクラウド 使う人は楽になり、基盤の開発者にとっては挑戦となる新サービス「マネージドクラウド」について、開発チームメンバーに話を聞きました。 左から、小田知央さん（おだ・ともひさ、技術部 技術基盤チーム プリンシパルエンジニア）、瀧口舞さん（たきぐち・まい、ホスティング事業部ホスティンググループ マネージドクラウドチーム リーダー）、小山健一郎さん（おやま・けんいちろう、ホスティング事業部 ホスティンググループ マネージドクラウドチーム シニアエンジニア） ※
というテーマで東京Node学園祭2015でセッションさせて頂くことになったので、先に整理/メモ的ななにかを。 （追記）以下資料で発表しました。 大規模Node.jsを支える ロードバランスとオートスケールの独自実装 http://www.slideshare.net/kidach1/nodejs-54841327 作ったもの ・スマホゲーム（マルチプレイアクション） 【公式】メザマシフェスティバル(メザフェス) | 株式会社アカツキ https://mezamashi-festival.aktsk.jp ・2D横スクロール ・マルチプレイ ・4人同時対戦 ・座標同期型 ・全国マッチング システム概要 Client： Cocos2d-x (c++) Server： API Server：Rails Websocket Server：Node.js 詳しくは スマホアプリにおけるマルチプレイア
Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationWhat you can do with signing up
![[超簡単！]kubernetesでオートスケール - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3d4322f67bdff24ab318f197f965af24a3c239d7/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU4JUI2JTg1JUU3JUIwJUExJUU1JThEJTk4JUVGJUJDJTgxJTVEa3ViZXJuZXRlcyVFMyU4MSVBNyVFMyU4MiVBQSVFMyU4MyVCQyVFMyU4MyU4OCVFMyU4MiVCOSVFMyU4MiVCMSVFMyU4MyVCQyVFMyU4MyVBQiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MDdjNDg5NTliY2E1ZmVlY2E4MGJkMDg4YWRhNTE5YTU%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbW9ua2V5ZGFpY2hhbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9N2Y0MjkyOGRkNzY2YTY0NzlkM2Y3OWU2YzNjMDM0Y2Q%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D9fac2da75cfa988d70c50a9bab6ef332)
概要 ECSはコンテナのスケールアウトとインスタンスのスケールアウトのタイミングが重要です。 よく起きる問題としては インスタンスのスケールアウトが遅くてコンテナのスケールアウトも遅くなってしまう しきい値が不適切でインスタンスがスケールアウトせず、コンテナがスケールアウトしたくてもできない で、こういった事が起きないようにしないといけません。 スケールアウトの方針 対象 方針 インスタンス インスタンスの空きリソースがコンテナ１台分だけの状態がｎ分間続いたら コンテナ コンテナの使用率がｎ%を超えたら インスタンスはもう１台もコンテナを追加するリソースがない状況になったら早めにスケールアウトします。 コンテナは一般的なやり方で使用率が高くなったらスケールアウトすればOKです。 スケールインの方針 対象 方針 インスタンス コンテナがｎ分間ずっと１台を下回ったら コンテナ コンテナの使用率
GoogleクラウドのPaaS「App Engine」を使ってオートスケールするWebサーバーをNode.jsで書いてみた
Googleが提供している「Google App Engine」は、PaaS(Platform as a Service)に分類されるクラウドサービスで、サーバーなどのインフラ設定を何もしなくてもアクセス数に応じてスケールするアプリケーションを設置できるサービスです。このGoogle App Engineの標準環境が2018年6月にNode.jsに対応したとのことで、早速Node.jsを使ってWebサーバーを設置してみました。なお、今回はmacOSを使用していますが、Windowsでも同様の手順でサーバーを設置できます。 App Engine - Build Scalable Web & Mobile Backends in Any Language | App Engine | Google Cloud https://cloud.google.com/appengine/ まず
Amazon ECSのDockerコンテナをLambdaで自前オートスケールする | DevelopersIO
ども、大瀧です。 4/9-10に行われたAWS Summit 2015 San Franciscoで正式リリース&大量アップデートが発表されたAmazon ECS、皆さん触っていますか？弊社ブログでも早速いくつかエントリーをアップしています。アップデート後の触ってみた記事はこちらです。 今回のアップデートの目玉が、待望だったコンテナスケジューラの追加です。Serviceというスケジューラが追加され、コンテナレベルHAとELB連携が容易に行えるようになりました。しかし現在のServiceにはオートスケール機能がないため、今回はそれを自前で実装した構成を紹介してみます。 ECSのServiceにはオートスケール機能がない ECSの製品ページ(日本語ページはアップデート前の情報なので、Englishに切り替えましょう)には、Serviceスケジューラの機能として以下が挙げられています。 Cont
オートスケール時のデプロイを User Data と Capistrano を使って行う（BootStrap パターン） | DevelopersIO
Auto Scaling を使った構成の場合、EC2 へのデプロイはどうやっているでしょうか？ AWS を使ってる方はご存知の方も多いと思いますが、EC2 には User Data という仕組みがあります。 User Data は、インスタンス起動時にタスクやスクリプトを実行する仕組みです。 今回この User Data を使って、自分自身のインスタンスから最新のソースを GitHub から取得してデプロイする方法についてご紹介したいと思います。 図で表すと以下のイメージですかね。 ssh localhost？ デプロイツールには Capistrano を使いますが、Capistrano は、デプロイ対象のサーバーに対してまず ssh で login を行います。 その後、サーバー上でデプロイ対象のコードの取得や、サービスの再起動をしたりしますが、 AutoScaling は自動でインスタ
おはこんばんちは!! 尾藤 a.k.a. BTO です。 メール流量とインスタンス数が完全に一致!! まずはこの図をご覧ください。 上がメール流量で、下がインスタンス数になっていますが、グラフが完全に一致しています。適切な時間に適切な台数を配置することで、サーバ代を1/4に削減することができました。今回はその話を書きたいと思います。 こちらがメールアーカイブシステムの概要です。この中で、トークナイザーとフラッシャーがワーカーになります。このワーカーが今回オートスケールする対象となります。 スポットインスタンス オートスケールの話を始める前に、まずスポットインスタンスについて説明します。 詳しい説明はAWSのページを見ていただくとして、簡単に説明すると余剰のインスタンスを激安で使用するインスタンスの事です。 価格は常に変動しており、入札で購入し、価格が上昇すると容赦なく落とされます。特徴をま
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 集約ノードにログを転送し
Knativeが発表されたので、GKEや手元のminikubeで遊んでいた。オートスケール機能について試したよ。autoscale-go/README.mdをminikubeでやった、という記録です。 GKEでもいいけど、今回はminikubeを使う。Mac上にhyperkitを使って構築するので、kubernetes/minikubeを参考にしてminikubeをhyperkitで使えるようにしておく必要があります。 Knative servingのインストール 基本的にドキュメントに従って進めればよいので割愛。 autoscale-goを試す さて、autoscale-goを試してみる。サンプルアプリをビルドしてコンテナイメージをレジストリに置くのだけど、今回はhub.docker.comに置くことにした。minikubeの場合、minikube上でビルドしてしまえばレジストリに置く必
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
AWS、Azure、OpenStackなどクロスクラウド対応の新しいPaaS「OneOps」、継続的デリバリ、オートスケール、自動復旧などを実現。米ウォルマートがオープンソースで公開
AWS、Azure、OpenStackなどクロスクラウド対応の新しいPaaS「OneOps」、継続的デリバリ、オートスケール、自動復旧などを実現。米ウォルマートがオープンソースで公開 米国の小売り大手ウォルマートストアズの開発部門であるWalmartLabsが、クロスクラウド対応でアプリケーションの継続的デリバリ、実行、運用管理などを実現するソフトウェア「OneOps」をオープンソースで公開しました。 同社はこのソフトウェアをPaaSを再定義する「PaaS 2.0」と位置づけており、クラウド上でのアプリケーションライフサイクル全体を管理するものだとしています。 OneOpsは、Perl、PHP、Ruby、Java、Goなどのさまざまな言語や、Docker、JBoss、Node.js、TomcatEE、Apache Tomcat、Apache、Couchbase、Redis、MySQL、Ra
Masanori Kusunoki / 楠 正憲 on Twitter: "#クラウド蓮舫 がどうして馬鹿にされてるのか分からないけど、オンプレのサーバー増設は時間がかかるけどクラウドなら時間をかけずに増設できるといいたかったのでは？会計法が硬直的で従量課金への対応が困難とか、JPKI関係がオートスケールできない設計であることは枝葉末節で"
#クラウド蓮舫 がどうして馬鹿にされてるのか分からないけど、オンプレのサーバー増設は時間がかかるけどクラウドなら時間をかけずに増設できるといいたかったのでは？会計法が硬直的で従量課金への対応が困難とか、JPKI関係がオートスケールできない設計であることは枝葉末節で
2秒で設定！ AWS Elastic Beanstalk によるオートスケールアウトなサーバー構築 | DX.univ
AWS Elastic Beanstalk を使用して、簡単にオートスケール対応のサーバーを構築してみよう！2秒で設定！ AWS Elastic Beanstalk によるオートスケールアウトなサーバー構築 by Tomonori Kawata in Tech — 2013/07/24 「2週間だけ使うPHPで作成したランディングページ用のサーバーを用意して欲しい。どれくらいのアクセスが来るか分からないが、サーバー費用を出来る限り抑えたいので、オートスケールで対応してほしい」 やっと新人っぽさがなくなってきたエンジニアの川田です。 前回カメラの記事を書きましたが、今回はLinuxネタに戻ろうと思います。 はじめに みなさん、Amazon Web Service（以下AWS）って使っていますか？ Web制作会社であればEC2を使ったことがある、もしくは聞いたことがあるという方が多いと思い
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
［速報］Windows Azure、モバイルサービスでiOSアプリを自動生成。オートスケール機能、Active Directory機能も追加。Build 2013（Day2）
［速報］Windows Azure、モバイルサービスでiOSアプリを自動生成。オートスケール機能、Active Directory機能も追加。Build 2013（Day2） マイクロソフトがサンフランシスコで開催中のイベント、Build 2013。2日目の基調講演はデベロッパー向けのツールとプラットフォームがテーマになりました。 2日目の基調講演から、Visual StudioとWindows Azureの新機能を中心にダイジェストで紹介しましょう。 （本記事は「［速報］マイクロソフトがASP.NETでTwitter Bootstrap、Ember.jsなどを採用。Visual StudioではCSS3の対応ブラウザをその場で確認。Build 2013（Day2）」の続きです） Mobile ServicesでiOSアプリのコードを自動生成 Windows Azure Mobile Se
こんにちは、サーバサイドエンジニアの@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を実行する方法」の記事で
この記事は Akatsuki Advent Calendar 2016 の15日目です。 はじめに 今やログ収集ソフトウェアのデファクトスタンダードとなったFluentdですが、オートスケール環境においては思わぬログの重複や欠損が発生する可能性があります。今回は私の所属するプロジェクトで行ったログ重複・欠損対策について紹介したいと思います。 前提 今回前提とするシステムは下図のような構成になっています。 ELB配下にオートスケーリンググループに属するEC2インスタンスのアプリサーバが複数台あり、各インスタンス上では Rails と Fluentd (sender) が動作しています。各アプリサーバから出力されたログは Fluentd (aggregator) により集約され、最終的に DB に保存されます。 Fluentd を利用したログ収集の構成としては一般的なものかと思います。 (バッ
Kubernetes初のバージョンアップとなる「Kubernetes 1.1」リリース。性能向上、ポッド単位のオートスケール、ロードバランサー、バッチジョブ対応など
Dockerをクラスタとして運用管理するフレームワークとしてオープンソースで開発されている「Kubernetes」。7月に最初の正式版となるバージョン1.0が登場して以来、最初のバージョンアップとなる「Kubernetes 1.1」のリリースが発表されました。 Kubernetes: Open Source Container Cluster Orchestration: Kubernetes 1.1 Performance upgrades, improved tooling and a growing community Kubernetes 1.1の主な新機能は次のように説明されています。 大幅な性能向上 非常に大規模な環境にも対応する大幅な性能向上を実現 ネットワークスループットの大幅改善 Kubernetes 1.1ではLinuxネイティブのIP tablesを利用するオプション
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
自動退役や自動ステータス変更 - オートスケールやスタンバイ機の管理のための自動化 - Mackerel お知らせ #mackerelio
オートスケールのように動的にホストを増減させたり、コールドスタンバイ機を利用している場合、都度退役処理やステータス変更処理を行う必要があります。これまではこの処理を自動化するには起動スクリプトなどで退役処理やステータス変更のためにAPIを叩く処理を独自実装する必要がありましたが、mackerel-agent v0.20.0では設定ファイルに書くだけで処理が行なわれるようになりました。 今回はその方法を紹介します。 OSシャットダウン時にホストを自動で退役させる オートスケールなどを利用している場合、ホストを自動で退役させたいこともあるでしょう。 パッケージインストールした場合はinitスクリプト用の環境変数設定ファイルに一行追記するだけで簡単に自動退役を実現できます。 環境変数設定ファイルはyum/rpmの場合は/etc/sysconfig/mackerel-agent、deb/aptの場
オートスケールする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
EC2のオートスケールが複数インスタンスタイプの混在指定に対応、廉価なスポット利用が実現しやすくなりました。 ｜ DevelopersIO
はじめに AWSチームのすずきです。 2018年11月14日のアップデートで、1つのオートスケーリンググループ設定内で複数のインスタンスタイプや購入モデル(オンデマンド/スポット)を組み合わせた設定が可能になりました。 早速試す機会がありましたので、紹介させて頂きます。 New – EC2 Auto Scaling Groups With Multiple Instance Types & Purchase Options 環境 リージョンはオレゴン(us-west2)を利用しました。 「M5#」のバリエーションが多く、AZ間のスポット価格に差異があるリージョンとしてオレゴンを利用しました。 今回のオートスケールのアップデート、東京リージョンを含むAWSの各国リージョンで利用可能です。 複数のインスタンスタイプと購入モデルを組み合わせたオートスケーリンググループ設定は、起動テンプレート(L
Google の企業向けソリューションに関する公式な情報やユーザーの事例などを、いち早く皆さんにお届けします。
![[GCP] オートスケール、Google Compute Engine へようこそ](https://cdn-ak-scissors.b.st-hatena.com/image/square/6571391198fcb45e4d7c5cab7d90e5ca2fbf4605/height=288;version=1;width=512/http%3A%2F%2F2.bp.blogspot.com%2F-7bZ5EziliZQ%2FVynIS9F7OAI%2FAAAAAAAASQ0%2FBJFntXCAntstZe6hQuo5KTrhi5Dyz9yHgCK4B%2Fs1600%2Fgooglelogo_color_200x200.png)
こんにちは。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とその操作・管理を担
概要 TerraformでECS環境の構築 - Carpe Diemでは書いてなかったオートスケールについてです。 terraform 0.7からServiceでのオートスケールにも対応したので、それを使って構築します。 環境 Ubuntu 14.04 Terraform 0.7.3 実装 完成形はこちら github.com Autoscale用のIAMの追加 Amazon ECS サービスの Auto Scaling IAM Role - Amazon EC2 Container Serviceを参考に用意します。 まずはJSONでPolicyの用意 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "application-autoscaling.amazo
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWSのオートスケールとなかよく付き合う
大規模Node.jsを支える ロードバランスとオートスケールの独自実装
大規模Node.jsを支えるロードバランスとオートスケールの独自実装（FRPもあるよ） - Qiita
[超簡単！]kubernetesでオートスケール - Qiita
ECSのオートスケール戦略 - Carpe Diem
ワーカーをオートスケールでスポットインスタンスをアジャストしてプライスを1/4にしたファクト - HDE BLOG
Fluentd 集約ノードのオートスケール - クックパッド開発者ブログ
Knativeのオートスケール機能をminikubeで試したメモ
capistrano-bundle_rsync使ったらオートスケールが高速化した話
ECSで通常時とスパイク時のオートスケールを運用する - Timee Product Team Blog
コスト安なCI環境を目指してオートスケールするCI環境を構築する - 電通総研 テックブログ
オートスケール環境におけるFluentdのログ重複・欠損対策 - Qiita
[GCP] オートスケール、Google Compute Engine へようこそ
ElasticsearchをCPU利用率でオートスケールさせる
【GCP】オートスケールのクールダウン期間指定について
TerraformでECS環境の構築【オートスケール編】 - Carpe Diem