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

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

VultrとLinodeの比較

それぞれ東京リージョンのものについて触れます。 料金比較は長くなるので下の方に書いておきました Vultrのメリット Windowsが利用可能(ライセンス料がかかるため料金は倍近くなります) Firewallが利用可能 プライベートネットワークを複数に分割可能 CPUの性能がLinodeより僅かに高め Snapshot機能があり、簡単にバックアップを取得可能 日本語の情報がlinodeより多く(古いものもそこそこ混じっているものの)

ScalewayのBaremetalのベンチマーク

ベータ期間中に借りたときのベンチマーク結果です(ベータ終了後の価格だとVultrのBaremetalの方が良いかも...?) Beta用のプランなのでこれと同一のスペックのものは見当たりませんでした CPU:Intel Xeon E3 1240v6 RAM:32GB Disk:250GB

ObjectStorage比較メモ

オブジェクトストレージの比較です。 S3/GCSは複雑なので省略 カッコ内の円表記はこの記事を書いている時点のレートを参考に雑に切り上げたり切り捨てたりしたもので、正確ではありません また、それぞれの料金は2019/08/07の時点で確認したものとなります 2019/10/29

Golangのwasmを別スレッドで非同期に実行

Goのwasmでの実行が少し前に試したときにうまく行かなかった理由がメモリを1GBも確保して溢れている事がわかり(こちらの記事を偶然見つけ)、実行にはできたのですが、長時間かかる処理を行うとサイトが丸ごと固まってしまいました。 WebAssemblyは同一スレッドで動く事が原因と判明し、WebWorkerを使えば非同期に実行が可能でした Golang側で非同期に処理を行っても(go func利用)同期実行されてしまうので複数スレッドで実行する場合はJavaScript側で複数のWebWorkerを動かす必要がありそうでした。 動かした時のコードを残しておきます <

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

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