ariesAriesです。私のMastodonインスタンス(結局サーバ呼びになったんでしたっけ)の構成を変更しました。ちなみに私のアカウントはこちら。sidekiq)をホスト、DBはPostgreSQLもRedisも両方マネージドサービス、という構成でした。この構成を以下のように変更しました。結果として$20ほどの節約になっています。DBをロストしてしまった時のためのコマンドがmastodonには用意されています。そのためわざわざお高いマネージドのredisを使う必要は無いと思います。自由が効くお一人様インスタンスだと特にそうかなと。いう話をヒョロワーさんから聞いたため廉価構成に変更しました。わたしは半年ほど前のインスタンス構築時、Web周りの知識なんぞほぼ無知の状態だったため、大きいガバをやらかしても復旧しやすいようにDBはお金で殴ったというわけです。変更後1日ですが、今のところサーバが止まったりなどはしていません。1GBでbuildも時間がかかりますし、更に不定期でサーバのCPU使用率が100%近くに張り付いてしまう事象が構成変更前からちょくちょく発生しています。(面倒でまだちゃんと調査しておらず......)ですので浮いたお金でt3.smallへのスケールアップを行いたいところですが、リザーブドインスタンスで買ってしまっているため変更すると損するというね......。そんな状況なので、スケールアップの代わりに障害時復旧を自動化しました。この自動化については後ほどブログ記事を書く予定です。自動復旧スクリプトが動くまでもなくインスタンスに全くアクセスできなくなる状態になり用を名なさないことが判明しました。今まで死んでいた原因もフォロワーさんの手助けによりわかりました。t3インスタンスにおいてCPUクレジットという概念が存在することは知っていましたが、EBSにも存在していたとは露知らず......。microだとdocker-composeのbuildが行えないため、swapを設定していたのが問題でした。現在はそこまで大きな損にはならないことを確認したため、大人しくmicroからsmallへとスケールアップを行い運用しております。