Migrate mastodon instance to Azure from AWS
0 likes608 views
Migrate mastodon instance to Azure service form AWS.
Migrate mastodon instance to Azure from AWS
- 1. 2020/1/25 Kirino Minato / imksooo @imksoo@mstdn.blue.wirednet.jp Mastodonをお引っ越しした話 -1-
- 2. はじめに ◼ ざっくり言えば – AWS上で構築していたMastodonインスタンスを、Azure上にお引っ越しした ◼ 理由 – Azureの勉強のため – Azureだと(略)課金が抑えられるため -2-
- 4. Azureに持って行くものとして想定したもの -4- 移行対象 移行先サービス 移行方法 備考 DNSゾーン Azure DNS Zoneレコードを手動登録後、 NSレコード切り替え メール送信 SendGrid 新規構築 ロードバランサー (URL-path routing) Azure Front Door 新規設定後、DNS切り替え CDN (静的ファイル配信) Azure Front Door 新規設定後、DNS切り替え オブジェクトストレージ (静的 ファイル保管) Azure Storage BLOB サービス停止中にazcopy 多数のオブジェクトが入ってい たため現実的じゃない…？ Dockerホスト Azure App Service (Linux Container) 新規構築 Redis Azure Cache for Redis 新規構築 DB Azure Database for PostgreSQL pg_dumpしてリストア
- 5. 想定した移行の流れ -5- 1) DBデータの引っ越し、切り替え 2) Dockerホストの構築 3) Redis/SendGridの切り替え 4) S3オブジェクト移動、CDN切替 5) AWS上のお掃除 年末年始のまとまった時間を使って作業を行う。 前提として、アクティブユーザはそこまで多くないインスタンスなので、何度もサービス停 止しても良い。 移行の順序は、手をつけやすい＆AWSのコストがかかっているところからとした。
- 6. DBデータの移行 ◼ Mastodonインスタンスを停止し、DBデータをエクスポート (pg_dump) ◼ Azure上のDBインスタンスにインポート (pg_restore) ◼ インポート処理はDBに大量のinsertとalter indexを行う – インデックスの再作成が実施されるので、テーブル行数(=保持しているトゥートの数)に比例して、数時間かかる – うちのインスタンスの場合は、最初期から稼働している＆連合先が多いため非常に多くのトゥートを保持していた ◼ Azure Database for PostgreSQLでハマったこと – デフォルトだとSSL通信を強制される – 内部的にはPgBouncerを使っているみたいな動き ▪ → MastodonのStreamingプロセスが上手くPostgreSQLと通信できずに、WebSocketを開くタイミングで failed: HTTP Authentication failed; no valid credentials available というエラーをはき続ける ▪ メッセージだけ見てもフロント側のロードバランサーの問題なのか、バックエンドのDBとの接続の問題なのか判然としな くて数週間悩んだ。 -6-
- 7. 2020/1/3 DBがAzureに -7- Mastodon鯖 t2.large Redis(ElastiCache) cache.t2.micro ロードバランサ ACM+ALB メディアファイル S3Bucket+ StaticWebHosting CDN(CloudFront) メール通知 SES 権威DNS Route53 Mastodon ユーザ SSL証明書は ACMで発行管理 Azure Database for PostgreSQL The Pacific Ocean Azure West USリージョンAWS東京リージョン Web/StreamingとDBのレイテン シが大きくなりすぎてストレフスル な状況に
- 8. Dockerホストの再構築 ◼ うちのポリシーとして、master追従はDocker Hubのイメージでやっている ◼ Azure上でDockerイメージの実行環境と言えば – Azure Kubernetes Service – Azure Container Instances – Azure App Service / Linux Containers ◼ 直近で、Azure App Service P1v2 (1core/3.5GB)でWordpressなブログを立てていてちょっと 余っていたのがあったので、Mastodonも同居させようとしてみた -8-
- 9. Azure App Service / Linux Containers で Docker-composeする ◼ あまり悪いことは言わない ◼ Azure App ServiceでDocker-composeは茨の道なので止めた方が良い – 構成に失敗した場合にログが出てこなくなる(ことが多い) – Linux ContainerはAzure Monitor統合がまだサポートされていない ▪ Log Analyticsへログ転送出来ない ▪ SSHログインなどの手が出ない – KuduもLinux Containerにはあまり手が出せなくなる ◼ 何かあっても何があったのかよく分からない -9-
- 10. 諦めてAzure VMにUbuntu入れてDocker-compose ◼ Ubuntuは良いものや。 ◼ 長時間停止してたMastodonインスタンスを起動すると、周囲のインスタンスから一気にその間 のトゥートを再送される – Sidekiqプロセスがやたらと大量のログを出力する ▪ 標準のログドライバーだと、そのままログをディスクに吐き出す (バッファリングなどは無い) – 大量のディスクI/Oで瀕死の状態になる – Azure VM D2s_v3 + Premium SSDでも Disk I/Oが足りない ▪ ログドライバーをCloudwatch Logsにして、オンメモリ＋Network I/Oにしたほうが良さそう -10-
- 11. 2020/1/5 Azure上に主要機能を持って行った -11- Azure VM (Ubuntu + Docker) Azure Cache for Redis CDN/ロードバランサ Azure Front Door メディアファイル S3Bucket+ StaticWebHosting CDN(CloudFront) メール通知 SES 権威DNS Azure DNS Zones Mastodon ユーザ Azure Database for PostgreSQL The Pacific Ocean Azure West USリージョン WebSocketをサポートしていないの でタイムラインがぶつ切り状態に SSL証明書は Front Doorで発行
- 12. Azure Front Door ◼ WebSocket通信 – Azure CDNであればサポートするがお高い ◼ SSL証明書管理 – AWS ACMに比べて発行までに時間がかかる – CNAME認証でも30分程度かかる。Domain apexの場合は、8時間程度かかる。 – Whoisのメールアドレスに承認用のメールが来るまで大体半日。 – 待っていられない。 ◼ CloudFrontとALBの良いところを併せ持っている – URL-path base routing出来る – 構成変更のデプロイはALBほどではないが、CloudFrontよりは全然早い -12-
- 13. WebSocketを通すために ◼ Azure Front Doorを使い続けられないと判断 ◼ ALB+ACMの組み合わせはやっぱり便利 – 制約) ALBは所属するVPCからルーティング可能な範囲のIPアドレスにしかフォワードできない – ALBから直接Azure VMにトラフィックを回すには、VPC-VNET間VPNを貼るしかない＝高い ◼ ALB配下に、EC2のパケットフォワーダーを立ててごまかすことにした -13- IptablesでHTTPパケットをそのまま Azure VMに転送する TCP 3000/ TCP 4000 TCP 3000/ TCP 4000 Azure West USリージョンAWS オレゴンリージョン
- 14. 2020/1/20 AWS+Azureのハイブリッド構成に -14- Azure VM (Ubuntu + Docker) Azure Cache for Redis メディアファイル S3Bucket+ StaticWebHosting CDN(CloudFront) メール通知 SES Mastodon ユーザ Azure Database for PostgreSQL The Pacific Ocean Azure West USリージョン AWS オレゴンリージョン 権威DNS Azure DNS Zones
- 15. 今後について ◼ メールのSendGrid化 – そのうちやるかもしれないけども、コストメリットが全くないのでやらないと思う ◼ S3オブジェクトのお引っ越し – 静的ファイルの切り替えは数が多すぎて現実的ではない – 当面このままにすると思う -15-