こんばんわ、hisayukiです。
12月入ってから一度もブログを書かず、あっというまに年末に入ってしまいました・・・💦
re:Inventも終わり注目サービスもいくつかありましたが、今回真っ先に使ったサービスの紹介をしていきます!
ちなみに、設定方法だけでいいという方にはこちら
Fargate Spot
FargateでSpot Instanceが使えるようになりました!!
しかも最初から東京リージョンでも使用可能!!
これは適用するしかないでしょw
しかも、お値段70%OFF!!!
とりあえず、テスト用に使ってる環境には入れるしか無いと思ったので適用しました❗
設定方法
既存クラスタにはあまり優しくない
新規で作る場合は少し難易度下がりますが、既存クラスタに対しては優しくないです。
というかマネジメントコンソールからはほぼ出来ません
というわけで、ツラミとともに既存のクラスタへの設定方法を書いていきます。
CLIアップデート
新しい機能なのでCLIももちろんアップデートが必要です。
今回の手順はバージョン1.16.304
で行いました。
Capacity provider
まずCapacity provider、こちらも新しい機能になります。
どのインフラを使ってタスクを実行するかを選定できるようになりました。
選べるのはEC2の
新規でクラスターを作る場合に関しては、Fargateを選定することで自動的に入っているのですが、もちろん既存クラスタには何もないです。
[Create]というボタンがありますが、こちらを押すとこんな感じ
Fargateを選ぶところがありません。
公式ドキュメントでは以下の通り
既存のクラスターへの Fargate または Fargate Spot キャパシティープロバイダーの追加は、AWS マネジメントコンソール ではサポートされていません。コンソールで新しい Fargate クラスターを作成するか、Amazon ECS API または AWS CLI を使用して既存のクラスターに Fargate または Fargate Spot キャパシティープロバイダーを追加する必要があります
AWS Fargate キャパシティープロバイダーの使用
というわけで、AWS CLI で追加します。
本来ならCapacity providerだけ追加したいところですが、この後説明するCapacity Provider Strategyのデフォルト値(–default-capacity-provider-strategy)がCLIで必須入力となっております。
コマンドの詳細はこちら
Capacity Provider Strategyはこの後からでも修正できるので、一旦適当に設定で大丈夫です。
コマンド実行後は以下のように表示されます。
これで、Task実行時にFargateかFargate Spotのどちらかを選べるようになります。
ちなみに[Deactivate]を押して消してしまうと、新規であろうが既存であろうがCLIからしか再追加できません。
Capacity Provider Strategy
Capacity Providerに続き、こちらも新機能。
TaskをどのようにCapacity Providerに振っていくかという設定です。
先程のコマンドでデフォルト設定は入ってると思います。
まずはクラスターの画面の左上のボタン
すると以下のように、先ほど設定したCapacity Provider Strategyが設定されてます。
- Base:必ず動いてほしいタスク数
- この場合はFARGATE_SPOTが必ず1台は動いている必要がある設定
- Weight:Taskが増える際にどの比率で増やしていくかの対比
- この場合はTaskを6と設定すると、FARGATE_SPOTが5台動いたら、FARGATEが1台動く設定
この設定、本来はFARGATEがBase1に対して、WeightをFARGATE:1、FARGATE_SPOT:5にするのがいいと思いますw
そうすると、スケールでTaskを増やす場合に必ず動いているFargateが1台に対して、5台までSPOTでスケールしてくれます。
いつ止まってもおかしくないSPOTをBaseにするのは、止まってもさほど問題ない仕組みにしましょうw
CLIで設定値を変更する場合のコマンドも、Capacity Providerを設定するときと同じです。
上記のようにWeightをFARGATE:1に対してFARGATE_SPOT:5に修正します。
実行すると、以下のように修正がかかります。
起動しているTaskが対比と同じ状態のときは、FARGATEが優先して起動するようです。
ちなみに、同じようにコマンドでFARGATE_SPOTのみにすることも可能です。
これでCapacity Provider周りの設定は完了です。
でも、これだけでは既存TaskでFargate Spotは動きません。
次にServiceの設定です。
※Service使わずにTaskのみで動かしている場合はTaskまで飛んでOKです。
Service
Serviceもマネジメントコンソールから更新しようとしても、起動タイプを変えることが出来ません。
既存クラスターはマネジメントコンソールでサポートしていない旨が書かれてますが、Serviceについてはそもそも新規で作ること前提みたいですね。
ただ、CLIからの更新は可能です。
–capacity-provider-strategyでCapacity Provider Strategyを指定して–force-new-deploymentで強制deployさせることで既存Serviceを起動タイプ指定からCapacity Provider Strategyでの起動に切り替えられます。
コマンド実行するとServiceの更新画面がこのようになります。
※写真の都合でタスク定義を別のにしてしまいました。
こちらもクラスター同様に、FARGATE_SPOT一本にすることができます。
画面を見るとこのように、一本化されてます!
注意点としては、既存ServiceはクラスターのDefault Capacity Provider Strategyを引き継ぎません。
そのためCLIからの変更のみとなってます。
これは新規でサービス作った際も同じです。
初期段階ではその時点のクラスターのDefault Capacity Provider Strategyを引き継ぎますが、修正についてはCLIからCapacity Provider Strategyを設定した強制deployになります。
ちなみに、Capacity Provider Strategyが設定されてる状態で新規でServiceを作ると最初からこうなってます。
Task
Serviceを使わずにタスクのみを動かす場合はマネジメントコンソールからでも可能です。
Capacity Provider Strategyが設定されている場合は以下の画面が表示されます。
[Switch to launch type]を押すことで、起動タイプに切り替えることができます。
コマンドで実行する場合はこのような感じです。
–countでTask数をしていしてるので2Task起動します。
weightが1:1なので、先にFARGATE、2つ目にFARGATE_SPOTが動きます。
FARGATE_SPOTで立ち上がると以下のようにCapacity Providerに表示されます。
まとめ
使いたい人って新規だけでなく既存で運用してる人のが多いのでは?ww
まぁ、でも最初から東京リージョンで使えるだけありがたいです。
結構ハマりどころ多かったですが、やりつつ理解していくスタンスでなんとかなりました。
やっぱドキュメントを先に読むのが大事なのかもしれないです・・・
テスト環境はこれでFargateのコストを7割カットできるわけなので大きいです。
ちなみにうちは本番でもFargate Spotにしてます。
もとよりFargate1台だったのを、CPUとメモリを1段階落としてFargate Spot2台構成にしました。
現時点ではまったく落ちてないですが、今後どうなるかは不明なので通知を拾ってSlackに飛ばす運用になると思います。
コメント