FargateTweetこんにちは。インフラエンジニアの永井(shnagai)です。今回は、ターゲット追跡ServiceAutoScallingを使い、ECS×fargateで運用しているサービスのスパイク対策と費用削減に取り組んだのでその内容をまとめています。内容はざっくり下記4項目について書いています。ターゲット追跡ServiceAutoScallingとは何か?どんな結果になったか?抱えていた課題コネヒトでのWebのアーキテクチャはほとんどがECS×Fargateの基盤で動かしています。ECSのバックエンドをEC2からFargateに移行したタイミングで、大きく下記2点のメリットは享受していました。EC2を意識しないことでの運用コスト削減オートスケールの容易さですが、サービス運用にあたりまだ下記のような課題がありました。1FargateのコストがEC2リザーブドインスタンスに比べて費用が高い2オートスケールは容易になったが、平均50sくらい起動にバッファが必要なので、瞬間的なスパイクに対する瞬発力が弱い今回この2つの課題に対して、ターゲット追跡ServiceAutoScallingを本格導入することで解決することに成功したのでどのようなアプローチをしていったかについて紹介します。キャパシティプランニングに対する考え方の変化アプリケーションの実行環境としてクラウド利用やコンテナ化が進んできたことで、スケールアウトやスケールアップが容易になったことを背景として、昔のようなピークトラフィックに耐えうるキャパシティを事前に用意しておくようなアーキテクチャは、私達のような小・中規模のウェブサービスでは選択しなくてもよい時代になりました。サービスの可用性を高く保つのはインフラエンジニアとしての本分なのでそこは保ちつつ、クラウドは従量課金なので、ユーザが多いときには多くのリソースを構え少なくなったらリソースを最小化するというより動的なキャパシティコントロールをすることがそのまま費用削減につながります。同じ品質のサービスを提供するのであれば費用は少ない方がいいに決まっており、費用削減もサービス運用に大きな意味を持つと思っています。コネヒトの最近の話を少し振り返ると、下記のような流れをたどっています。負荷に応じてタスク数を動的にコントロール。最小数を小さくして夜間とピーク時で3倍程のタスク数の差が出る。ターゲット追跡ServiceAutoScallingとは何か?ここからは、今回活用したターゲット追跡ServiceAutoScallingについて紹介します。(起動するコンテナ数)を動的にコントロールしてくれる機能です。実はこれまでもスパイク時のオートスケール用には使っていたのですが、今回スケールインもこの機能に任せる設定を入れて、負荷が低い状態の時に費用削減するようなアプローチを取りました。使っているのですがこの挙動が少し理解出来なかったので検証時に調べてみました。端的に言うと、指定した値に収束するようにタスク数をコントロールするような挙動になります。40%という値を設定したとすると具体的に下記のような挙動になります。裏側では、CloudWatchAlarmがセットされて下記のような設定がされていました。設定のポイントここから設定のポイントを書いていきます。スケールの数を設定サービス内のタスクのスケールイン/アウトの幅をまず設定します。スケールアウトの最大値なのでこの数以上にはタスク数は増えないターゲット追跡するメトリクスを指定スケーリングポリシーには、「ターゲット追跡」と「ステップスケーリング(任意のCWAを指定)」があり、今回は「ターゲット追跡」を使う場合の設定について書きます。ターゲット追跡の対象と出来るのは下記3つです。今回の目的だとOffどんな結果になったか?最後にこのターゲット追跡ServiceAutoScallingを導入してどのような結果が出たかを紹介します。1FargateのコストがEC2リザーブドインスタンスに比べて費用が高いという課題に対しては、1日平均のタスク起動数が25%程削減出来ました!!従量課金なので、Fargateの利用料金が25%削減しています。2オートスケールは容易になったが、平均50sくらい起動にバッファが必要なので、瞬間的なスパイクに対する瞬発力が弱いという課題に対しても解決策を見つけることが出来ました。ゆうことかというと、ターゲット追跡のしきい値を緩めたことでリソースに余裕のある状態でスケールアウトが走るので、例えばpush通知で急激にリクエストスパイクする際もレイテンシ悪化なくスケールアウト出来るようになりました。これまでは、CPU60%超えで発動というような強めの設定をしていたので、スケールアウトする際にはすでにリソースがかつかつで既存のタスクが死んでいくというような状況だったので、スケールアウトで収束するまでに時間が少しかかっていたということに改めて気づきました。実は、スケールアウト時に間に合わずレスポンスタイム悪化すると使えないなと思っていたのですが、レイテンシに全く影響のでない抑えめのしきい値の最適値を見つけ、現在はこのような波形で動的にタスク数が制御されています。(設定後一度もアラートは鳴ってません)ちなみに、導入時は、ピーク時間帯が毎日不安で、最適なタスク数と追跡するしきい値1週間は張り付いてリソース状況を観察していました。コネヒトでは一緒に成長中のサービスを支えるために働く仲間を探しています。興味もたれた方は、是非気軽にオンラインでカジュアルにお話出来るとうれしいです。16:16Tweet関連記事2022-04-20ECS×Fargateのオートスケールをチューニングしてサービス運営費を削減した話こんにちは。インフラエンジニアの永井(shnagai)です。今回は...2021-05-18家族ノートを支えるBigQuery+StepFunctionsで作るデータレイクこんにちは。インフラエンジニアの永井(shnagai)です。ECSで2019年に導入した新機能こんにちは。インフラエンジニアの永井(shnagai)です。slackを用いたDDL自動実行フローを構築しましたこんにちは!MLエンジニアの野澤(@takapy0210)です。Fargateを本番運用した所感こんにちは。インフラエンジニアの永井(shnagai)です。(2)書いたメンバーid:taxa_programid:katsutomu0124id:sasashuuuid:NahomiTakahashiid:toc8id:yoshitaka465id:yanamuraid:ryoutakaya3623id:azuki_mihomihoid:takflifeid:nagaisid:aboy_perryid:laugh_kid:connehito-mkashiwagiid:tommy_kwid:itosho525id:su-kun1899id:ohayoukenchanid:satoshieid:plane25id:connehitoid:fortkleお問い合わせコネヒト株式会社Wantedly引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。