3年間、個人が AWS 上で Misskey サーバーを動かしてみた話
この記事は「バーチャルケモミミ Advent Calendar 2025」の5日目です。
あらすじ
私、アイザックは、「ぶいちゃ.social」という Misskey サーバーを AWS で運用しており、まもなく3年が経とうとしています。
IaC によるクラウド構成管理の簡易化と、AWS のマネージドなサービスにより、運用時の煩わしい管理コストがほぼありません。
ただ個人で AWS を使うには、金銭的コストが大きくなりがちです。
本記事では ぶいちゃ.social の基盤に AWS をどのように使っているか、金銭的コストをどのように抑えているかなどを書いていきます。
AWS をフルに活用した ぶいちゃ.social 基盤
マルチ AZ による冗長化を設定し、一部 AZ で障害が発生しても他 AZ によって十分にカバーできるようにしているつもりです。
東京リージョン（ap-northeast-1）の場合、AZ は次の3つがあります。
- ap-northeast-1a
- ap-northeast-1c
- ap-northeast-1d
この3つをフルに使う設定にしておくというのがミソで、サービスによっては AZ 2つだけ設定している場合に1つの AZ で障害が発生すると、冗長化が無くなり不安定になるという事象が発生するそうです。
なので、ぶいちゃ.social は3つの AZ を設定しているわけです。これによる金銭的コストは基本的にかからないはずなので、やるだけです。
またセキュリティ周りにも力を入れています。IAM Identity Center を活用したワークロードの分離、セキュリティグループや IAM ポリシーによる強固な通信制御を行っており、攻撃される隙を極力減らせているはずです。
ぶいちゃ.social 基盤の変遷
2022年12月、シンプルな構成からスタート
ぶいちゃ.social の基盤は2022年12月に構築・運用を開始しました。
運用開始当時は、Auto Scaling で EC2 を管理させ、ALB と CloudFront を通る、巷のプロダクション環境でもよくあるシンプルな構成でした。
2023年7月初旬、利用者爆増によるスケールアップ
忘れもしない2023年7月2日（アイザックの誕生日！）、当時の Twitter でユーザーに対する大規模な使用制限が行われ、Twitter の多くのユーザーが Fediverse に居場所を求めました。
VRChat ユーザーに限定している弊サーバーにも多くのユーザーが雪崩れ込み、EC2 と RDS に設定したスペック不足で不安定になりました。（朝起きたら身内しか居なかったはずの TL に大量に人が溢れているのを見て、非常に驚いたのを覚えています。）
EC2 は AutoScaling を組んでいましたが、最大数を少なめにしていたためにスケールアウトが止まって、各サーバーの負荷が高まる状態になっていました。 RDS は冗長な構成にしていなかった上に、インスタンスタイプも低く、バーストできずに負荷に耐えられなくなっていたと記憶しています。
それで EC2 インスタンスの数を増やしスペックも上げ、RDS の方もインスタンスタイプを上げることで、正常化しました。
2023年7月中旬、CloudFront の料金が高すぎるため、CDN を Cloudflare に変更
数日間コストを監視していましたが、CloudFront の料金、特に転送料が全体の半分を占めており、このままだと金銭的コストで押し潰されることに気付きました。
そこで転送料が異常に低いという Cloudflare を検討し、CDN として利用することに決めました。
つまり次のような構成になります。
ALB 側は 443 ポートで待ち受けており、またセキュリティグループで Cloudflare の IP アドレスからのみのリクエストを受け付けています。Cloudflare 側もオリジンとは TLS でのみ接続するよう強制しています。
これで Cloudflare と ALB 間をセキュアにしています。
2024年1月、ECS on EC2 に移行
年末年始の空いた時間を活用して ECS を勉強し、ついでに ぶいちゃ.social で ECS を使うように基盤を変更しました。これにより EC2 インスタンスで複数のコンテナを動かし、コスト最適化を図れるようになりました。
また移行時のダウンタイムゼロを実現しました！既存の AutoScaling はそのままに、ECS の環境を用意して、移行時は Route53 のレコードを変更して1日ほど並行で運用することで実現しました。
そして2025年12月現在もこの構成で動き続けています。
ぶいちゃ.social 基盤の今後は？
RDS のコスト改善
RDS のコスト改善について考えています。RDS は（基本的に）面倒なデータベースのチューニングや管理が不要で、素晴らしいサービスです。しかし、長く運用するには金銭的コストの改善は必須です。
手としては次を検討しています。
- リザーブドインスタンスを契約する
- 長期的に運用することが決まっているなら、リザーブドインスタンスを検討するべきでしょう
- プラン次第で変わりますが、2割くらい安くできるはずです
- （ぶいちゃ.social は何年運用するのか自分でも分かっておらず、まさか3年運用するとは思っていませんでした...）
- EC2 上にデータベースを立てて、自前で運用する
- 面倒なデータベースのチューニングや管理、バックアップの仕組みの整備をしなければなりません...
他のクラウドへの移行の検討
そして長期的には金銭的コストの観点から AWS 以外のクラウドに移ることも検討しています。（運用コストの観点では AWS が一番低くて最高だと思っています）
AWS はアメリカの企業であり、サービス利用料の単価はアメリカドルです。つまり為替の影響を強く受け、ドル高円安になると最悪な状況になります。
なので日本円で料金計算されるような日本のクラウド、さくらのクラウドとかを検討しています...検討していましたが、個々のサービスの料金が高くて断念しました。
何か良い移行先があったら教えてください🥺
おうちサーバーへの移行の検討
パブリッククラウドを脱しておうちサーバーに移すのもアリです。自前でデータベース管理するとなると、金銭的コストと管理コストのバランス的に、おうちクラウドでやっても良いんじゃないかと思えてくるからです。
最近は中古のミニ PC を購入し、Proxmox による仮想化環境を作って3台の Ubuntu Server で Kubernetes クラスタを作って、いろいろ 遊んで 勉強しています。
懸念点は次の通りです。
- ネットワーク、電源などの単一障害点がありがち
- ネットワークについては回線を複数引くとか、無停電電源装置を用意するとかして多少緩和できるとは思いますが、結局金銭的・運用コストが上がりそうです
- AWS にあるようなマネージドで強力なサービスが使用できない
- （お金さえ払えば）まるで無限にスケールするインフラは、おうちには作れません
- 負荷が一定以上かかったらスケールするとかできず、自分で物理的なコンピュートリソースを用意するしかない
まとめ
個人で AWS を使ってみるのは純粋に楽しいですし、面白いです。新しい技術をガンガン取り入れて、個人で運用するサービスに取り入れたりして勉強することができます。
何より AWS の利用に払うのは自分のお金ですから、常にコストダウンの道を探り続けることになります。
この3年間そうしてきて、いろんなことを学ぶことができ、仕事にも活かすことができたと思っています。
何度も書いているように、お金が飛ぶのがネックです。安定するまでは毎日コストのビューを眺め、クラウド破産しないかドギマギしていました。
予算を設定し、異常な課金にすぐ気付けるようにしましょう。
読んでいただきありがとうございました。今後も ぶいちゃ.social をよろしくお願いします！
明日は kazu0617 さんの記事です！
変更履歴
- 2025-12-05 00:00頃、公開
- 2025-12-05 00:45頃、構成図など追加
Discussion