Mastodonで利用しているObjectStorageの遅さをどうにかしようとした(3)

前回の記事に書いていない内容(主にObject Storageからの配信部分)があり、最近そこへ変更を加えて、ブログを更新しようとして書いていなかったことに気づいたので別の記事として残します。 現在のますとどんちほーでのファイル配信部分現在はストレージを変更して以前よりも高速で安定するようになったので、アップロード ダウンロード共に別のプロセスを挟む必要性は薄れましたが、間に別のプロセスを挟む構成の方が変更が楽(変更部分を吸収して移行時の停止時間を減らせる)なのでこの構成にしています。

Mastodonで利用しているObjectStorageの遅さをどうにかしようとした(2)

前回の後解決したのですが書き忘れていたので 前回はminioを利用しようとし、失敗してしまったので、こちらのブログを参考に一度ローカルにアップロードし、それをリモートに転送するようにすることにしました。 今回は簡単なプログラムを書くことで定期的にローカルからリモートへ反映させるようにし、0byteのファイルは転送せず削除するようにするついでに重いsyncコマンドの実行を回避することで数分おきに同期することを可能にしました。 Mastodon側は今はメデイアのアップロードに非同期に処理されるv2を利用するようになり、その部分で不具合を生じたためこれはv2のAPIの中身をv1に書き換えることで解決しました。

Mastodonで利用しているObjectStorageの遅さをどうにかしようとした(1)

ますとどんちほーでは画像等を保存するObjectStorageに料金と安定性からScalewayを利用しています ところが最近これの調子が悪く、画像のアップロードに何分も待たされる状態が続いているのでそれをどうにかしようとして失敗した話です(別の方法も試すつもりなのでそれはそのうち書きます) minio gatewayがキャッシュをしてくれるという話があったのでそれを使うことにしました これの設定自体はminioのドキュメントの通りに設定するだけで、nginxを利用することでhttps経由でのアクセスも手間はかかりませんでした。 Mastodonの設定も変更し、使える状態にしてからアップロードの動作を確認すると、その遅さは全く改善されず、minioのキャッシュについて調べていると

ますとどんちほーにDDoS攻撃が来た時の話

2018/11/18の話ですが書いていなかったので。 11月18日の夜中から19日にかけて記録できた限りでは最大2.5Gbps程度の攻撃でした。 CloudFlareを通していたため、当初はここの設定変更のみで対処可能と考えていましたが、実IPが漏れていて、そこへ攻撃が来ていました。 IPアドレスが漏れた原因として考えられるもの OGPの表示のためのリクエストがメインのサーバーから直接送られていた ActivityPubの連合への送信もメインのサーバーから直接送られていた