potpro (ぽとぷろ)
Full-stuck engineer(Not Full-stack)
JS/PHP/Go/Docker/Nginxなど。技術または趣味寄りの発信ブログです。
全 85 記事MastodonサーバをVPS(x86-64インスタンス)からOracle Cloud(ARM64インスタンス)に移管しました
MastodonサーバをVPS(x86-64インスタンス)からOracle Cloud(ARM64インスタンス)に移管しました
タイトルの通り。何か問題出てくるかなと思ったら、割とスムーズに何も問題なく移管できてしまったので記事にする。
ずっと月1200円くらいのVPSで動作していた、自分のおひとり様Mastodonサーバを、前回の記事でKubernetesクラスタを作った、OCIのAmpere A1 Computeインスタンスに移管しました。
ちなみに、Mastodonサーバですがもう4年もやっていることになります。もうそんなに経つのか・・・
当然ながらMastodonブームは過ぎ去り、去っていった人もいるけれど、新しく参加した人もいるので、自分のタイムラインには話題に困らないくらいにはアクティブ人数がいると思います。
Twitterよりは活発にコミュニケーションしてます。全然今からでもWelcomeな雰囲気があると思います。
移管について
元々、Mastodonサーバはx86-64のIntel CPU(仮想)で動作している、一般的なVPSで動作していました。その時のスペックは仮想3コア/メモリ2GBとなっています。
しかし、Mastodonは結構メモリを食いまくる性質があり、メモリ2GBでも厳しいところもあります。swapは普通に上限まで使っているような状態で、さらにHDDなので、どうしてもかなり快適とまではなりませんでした。ちょっとだけもっさりしているような感じ。
これを改善するには、メモリを増やす以外は無かったかなと思います。
そのため、どこか別のクラウドにでも移管しようかと考えていました。前回の記事で知見も溜まってましたからね。
最終的に移管したサーバは、OCIのAmpere A1 Computeインスタンスです。Oracle Cloudは、前回の記事で詳しく説明していますが、4 OCPU/メモリ24GBまで無料枠があります。
今回のサーバは2 OCPU/メモリ12GBのインスタンスを使用しており、CPUは単純比較できませんが、メモリは6倍になりました。もはやオーバースペック気味です。
Oracle Cloudの無料枠でKubernetesクラスタを構築する(完全版)
このあたりに対する思いは前回の記事で書いたので割愛します。
また、将来的にFree Tierが使用できなくなったとしても、現在の価格は1 OCPU/6GBのインスタンスで$0.019/時です。
これを30日利用で換算したとしてもコストは約$13.68/月となり、今のVPSが1200円くらいなのでそこまで変わりません。それでかつメモリは3倍になるので、コスパは確実にこっちがいいと思います。
というか、こうやって見るとFree Tierじゃなくても普通にコスト安いですね。Oracle CloudはAWSやGCPと比べても全然安いです。
安定性なんかはAWSとかに劣るとしても、まあ個人でやるレベルなので、ちょっと落ちる分にはまあ構わんくらいの気持ちなので不満も無いですね。今のところ落ちたことは無いです。
元々の環境
元々、移管や管理しやすいようにWebサーバはDockerで動作していました。Mastodonは一般的なWebサービスで、
- Web/Worker: Ruby on Rails
- Streaming: Node.js(JavaScript)
- DB:PostgreSQL
- Cache等:Redis
- 検索:ElasticSearch(省略可能、省略済み)
で動作しています。自分の環境は、これに加えてNginxで振り分けることでhttps通信を追加しています。
結構重量級というか、かなりモダンな作りのWebアプリケーションと思います。
基本的に、これをそっくりそのまま、SCPでコピーして、同じようにDockerで動作するように設定します。
OSとアーキテクチャの変更
OSは変更し、CentOS7からUbuntu 20.04になりました。CentOS7を選ぶことも可能でしたが、サポートを考えて自分は新しいサーバは全部Ubuntuにしています。
Dockerで運用している場合はOSの変更はそこまで障壁にならないと考えておりましたが、実際特に問題は無いように思えます。当然ながら操作が違って戸惑うところは合ったけども。
そして、結構な問題と思われるのはアーキテクチャの変更です。今回、x86-64のIntelなCPUからAmpere AltraプロセッサなARM64アーキテクチャのインスタンスに変更されたことで、それ絡みの問題が起きることは覚悟していました。
覚悟しておりなおかつ、正直これ絡みで致命的な問題が起きたら多分自分の力では直せないな・・・とも思っていました。
・・・が、予想は反して一切問題なく動作してしまいました。
やったことはSCPでデータベースのそのままのデータごとコピーして、DockerはARM64でビルドしたイメージを使って起動しただけ、内部に手は入れてません。
しいていうなら、一部パーミッションが狂ってしまったので直したくらいで、これはアーキテクチャの問題ではなかったです。
バージョンなどは揃えているとはいえ、PostgreSQLやRedis、Nginxなどもアーキテクチャが変更されたうえで動作しています。RubyやJavaScriptに関してもそうです。
今回、MastodonのARM64のDocker Imageビルドが存在しなかったということもあり、新しくビルドをしなおして、ついでにGitHub Container Registryで公開しています。ビルドも特に問題はありませんでした。
potproject/mastodon-arm64-docker-image
Webアプリケーションはx86-64からARMになる?
この結果を踏まえて、Webアプリケーションに関しては、x86-64なアーキテクチャからARM64アーキテクチャに変更することは、そんなに難しくないものなのかなと感じました。
というにも、今回使用しているPostgreSQLやRedis、Ruby、Nginx、これらは複数のアーキテクチャで動作するようにサポートされています。これは特別なことではなく、有名なプログラミング言語やミドルウェアはそうです。
自分は、コストパフォーマンスを考えるとWebアプリケーションはみんなARMに切り替わっていくだろう、と思っています。
AWSなどでもARMのGraviton 2インスタンスなどが登場し、コストパフォーマンスの高さを売りにされています。
クラウドではありませんが、新型MacbookはIntelを捨て、ARM64アーキテクチャのApple M1チップセットに変更されました。ということは、Macbookを開発機としてやっているようなWeb系の会社は開発もARMアーキテクチャになっていくということです。
そうなると実際のサーバもARMの方が都合がいいのは間違いありません。
まあ、ここまでは大体自分の妄想も入っているので、願望も入ってます。
結局、アーキテクチャに関係なく良いものが採用されるだけという話ではありますね。
おわりに
ともかく、個人としては月1200円の出費が0になったし、スペックも上がったので考えることも減りました。何もかも良い状態です。
これからも運用はし続けていき、それでもリソースが余っているので新しいサービスでも何かやろうかな、と思っている感じです。