おはよう
のえすきーのシステム構成は現在、こんな感じになっています。
いろいろ動かしてますが、借りているVPSは1台だけなので、みんな1台の中に詰め込んであります。
cloudflareは、CDN（コンテンツデリバリーネットワーク）といって、主に画像が対象となりますが、たくさんの人が同じデータを要求したときに、のえすきーのサーバに何度もリクエストしないで代わりに取得しておいたデータをユーザーに提供するサービスです。
とても高速に動作するようにできていて、また、ネットワーク的にユーザーに近い場所にキャッシュサーバを置いてあって、世界中どこからアクセスしても素早くデータを返してくれます。
どういうわけか無料のサービスなので（いろんな高機能なオプションを利用すると有料になり、そこから収益がでる）、これを利用しておくと自分のサーバの負荷が軽くなって、ユーザーも応答が早くなるので、たくさんの人が使っています。
他方、とても人気があってシェアが大きく、単一の事業者がインターネットの窓口を一手に引き受けるような構造になっており、暗号化された経路の一部が筒抜けになることから、リスクや批判の対象となることもあります。
オブジェクトストレージは、ハードディスクやSSDなどのデバイス（ブロックストレージ）単位でまとまった容量を借りるのではなく、オブジェクト（ファイル）単位で必要なだけデータを保存して取り出せる保存場所を提供してくれるサービスです。
Misskeyのように、サービスの提供とともに保存容量がどんどん増えていく場合に適しているということと、容易にデータが消えてしまわないよう管理されていて、預けておけば安心して任せられるという特徴があります。
また、サービスの規模が大きくなってシステム構成が複雑になると、サーバの台数を増やしてパワーアップさせたりしますが、この時にファイルの保存場所がブロックストレージだと複数台のサーバから同じようにアクセスすることができないので、ストレージが独立しているオブジェクトストレージ非常に便利です。
のえすきーでは、Wasabiという事業者のサービスを借りており、以前はアメリカオレゴン州のサーバを使っていました。今はNTTのビルの中に設置されている東京のサーバを借りて、新規のデータはそちらに保存しています。
オブジェクトストレージへは、Misskeyの本体プログラムから保存する時のルートと、利用者がアクセスするときのルートがあり、後者はcloudflareが一番ユーザー寄りのところに設置されているため、最初に取り出してしばらくはcloudflareが大部分のアクセスを捌いています。
最初のアクセスは、ロードバランサーを通過し、リバースプロキシでアクセス認証情報を付加して、オブジェクトストレージにデータを要求します。
また、以前のデータはオレゴンにあるので、東京にアクセスして見つからなかった場合にだけオレゴンに再度アクセスするように、リバースプロキシで処理をしています。
投稿やユーザーのデータなど、重要なデータはデータベースに保存されています。
また、高頻度でアクセスするデータや、一時的な処理結果を保存しておくことで何度も計算せずに素早く応答するために、非常に高速に動作する補助のデータベースを用いています。
Misskeyの本体は、二つ同時に立ち上げてあり、ロードバランサーを通じてアクセスを分散して両方を使って動いています。
ロードバランサーは、ユーザーのアクセスを分散して負荷をバランスするための仕組みで、トラブルやメンテナンスで一部のサーバが停止していても、動いているサーバにアクセスを割り振ってエラーにならないようにしてくれるサービスでもあります。
のえすきーでは、Misskeyのサーバがメモリをどんどん使っていってしまう問題への対処として、30分に一度、片方のサーバを再起動するようにしています。
この時に、あらかじめロードバランサーに停止する予告をして再起動するサーバにアクセスが来ないようにして、再起動が終わって安定したら再開したことを伝えるように構成しました。
現在、のえすきーは小規模ですので、Misskey本体2つを同じVPS上で動作させていますが、これを複数台のサーバに分割して台数を増やすことで、ユーザーが増えても負荷を分散させて捌くことができるようになります。
VPSは、KAGOYA CLOUD VPSを借りています。
ユニクロとかの肌着の高機能素材系（エアリズムとかヒートテックとか）苦手で、コットンしか勝たん……っていつも言ってる
ということで、サーバの再起動時にエラーが出にくいように対策しましたが、効果でていますでしょうか？
どうもMisskeyの終了プロセスがおかしいようで、停止や再起動を指示するとすごく時間がかかる（時間切れして止まってる感）ため、応答できないのに動き続けていて具合が悪かったようです。
そのため、外側にアクセス制御する層（ロードバランサー）を設けて、そこで安全に切り離してからMisskeyを終了させ、安定したら再接続するような方式に切り替えました。
あれ、素で間違えてるな？？
のえすきーのデータベースサーバ、先日別のVPSに分離したんでした。なので、VPSは2台構成です。同じKAGOYAです。
データベースサーバは負荷が大きい構成要素で、全体に重くなってきたら、Misskey本体とバランスしながらパワーアップさせていかなければなりません。
メモリーを多めに割り当てられると有利なので、別のVPSにわけてしまえばそれぞれ楽になります。また、データベースは容量を食うので、ストレージの容量も欲しい。
Misskey本体のVPSは4GBメモリー、80GBストレージですが、データベースのVPSは4GBメモリー、600GBストレージになっています。
先日データベースサーバを分離した理由の一つが、このストレージ容量不足です。
データベースの中で容量が大きいトップ3は、投稿データ 23GB、ドライブの管理データ 4GB、リアクション 2GBです。
のえすきーは運用が比較的長いので、リモートのデータを多数抱えています。ローカルの利用者の分はこの中のほんの一部です。
『言ってる事分からん』でええんやで！
Misskeyは自分で設置できるサービスだし、運用の情報に飢えている人はたくさんいるので、できるだけ詳しく事情は説明しておくことにしてるけど、わからなくて支障ないからね。
@_neko_sake_ マネージドだとコスト厳しいのよね。なので、Ubuntu借りて自分でPostgreSQLインストール・運用って形です。
ぽんこつさん誕生日じゃん。おめでとう〜！ 🎂🎉
今月誕生日多いな？
.ai読めるって、Illustratorの機能をフル実装しないといけないからなあ。部分的に読めるけど、ところどころ化ける、ぐらいまでがせいぜい。Illustrator 8 形式までならいいけど。
あなたには 根性があるわ
私と一緒に(甲子園|国立競技場)を目指しましょう！
それはともかく、10分と40分の再起動、どうですか。
もうエラーでないですか。でてますか。
@121yotta iOSのSafariというのは、PWAではないということですね？（ホームに保存するやつじゃなくて、純粋にブラウザ）
再起動は10分に開始してだいたい12分になる前に終了するのと、同様に40〜42分に開始・終了されますが、この時間帯以外におきるエラーは別モノです。
そのタイミングで一度エラーが発生したあと、タスクキルするまで回復しないという症状かな？
キャッシュの挙動の違いかな……