エンジニアおはようございます、ImageFlux開発責任者のharukasanです。3日前の4月14日、ピクシブではPawooが急にリリースされることになりまして、ここ数日はずっとPawooサーバにログインしていました。このPawooサーバ、既にピクシブの監視体制に入っており、アラート受信後インフラエンジニアが障害対応できる仕組みを整えています。リリース直後の15、16日は週末にもかかわらずアラートを受け取ることになり、サーバにはりつくことになったわけです。どんなシステムであろうとアラートを受け取ったら対応する、それが我らインフラエンジニアです。pawoo.netの構成さて、それではまずPawooの構成を見ていきましょう。digすればわかりますがpawoo.netはAWS上に構成されています。数百台以上の物理サーバを常時運用しているピクシブであっても、さすがにこんなにはやく物理サーバは用意できません。このあたりはクラウドサービスが非常に強いところです。4月に入社したばかりのインフラエンジニアnojioと、新卒2年目のkonoizがシュッと構成を用意してくれました。AWSを最大限に利用することで、作業開始から5時間くらいでインフラが整い、その日のうちにサービスリリースすることができました。DockerからはがすMastodonはDockerコンテナで簡単に起動できますが、複数インスタンスにデプロイするため、Dockerコンテナからはがして運用しています。コンテナに入っているとボリュームとかcgroupとかDocker固有のいろんな問題を考えないといけないので面倒です。「まちがってボリューム消しちゃった!」みたいなことにもなりかねません。Guideにも書いてある方法です。いうことでDockerからはがして各サービスはsystemdで管理することにしました。Webアプリケーションのサービスファイルはこんな感じになります。RDB、Redis、ロードバランサーはすべてAWSのマネージドサービスを使って構成しています。これにより、マルチAZで冗長設計がなされたデータストアをすぐに用意することができました。ALBはWebSocketにも対応しているので、ストリーミングの分散も簡単です。アップロードファイルの置き場もS3を使っています。AWSのマネージドサービスを活用することで、最速でリリースされたPawooですが、すぐに問題が起こり始めました。nginxのチューニングリリース開始当初、nginxはディストリビューションのデフォルト設定のまま動かされていましたが、エラーを返すようになったのですぐ手をいれることにしました。その後nginxはそれほど頑張って設定しなくても、うまいこと動いてくれました。このあたりは拙著ですが『nginx実践入門』に書いてあります。コネクションプールを適切な値にあわせるMastodonで使われているPostgreSQLはコネクションごとにプロセスをforkする性質をもっており、1コネクションごとに毎回プロセスが起動します。そのため、コネクションを張り直すのは非常にコストが高い処理です。これがMySQLとの最大の違いですね。APIに使うnode.jsにはコネクションプールの設定があります。これを良い塩梅の値に設定してあげましょう。インスタンス数にも注意です。負荷が高いからってアプリケーションのインスタンスを急に増やすとDBが詰まって大変なことになります(なりました)。Watchを使ってRDSへのコネクション数を監視するようにしています。コネクション数が増え続け、詰まって大変なことになったRDSですが、インスタンスのスケールアップを行い、安定稼働に持ち込むことができました。CPUのグラフを見てもメンテナンス後にガクッと下がっているのがわかります。Sidekiqのプロセス数を増やすMastodonはメッセージパッシングをSidekiqによって行っています。本来ジョブキューとして設計されているSidekiqですが、トゥート!される度にかなりの数のタスクがenqueueされることになります。リリース当初からSidekiqの処理遅延が大きな問題になっていたので、これをいかにさばくかが、大規模Mastodon運用の鍵になるといえそうです。ほかのMastodonインスタンスから更新を取得するこのうちpush、pullのキューは他のMastodonインスタンスのAPIをリクエストする必要があるため、ほかのMastodonインスタンスが応答できない状態に陥っているとかなりのキューが詰まれてしまい、defaultキューの処理も遅延させてしまいます。これを防ぐため、キューごとにSidekiqプロセスをわけて起動します。Sidekiqは起動オプションでどのキューを処理するか指定することができるので、これを利用して1台のサーバインスタンスに複数のSidekiqプロセスを立てています。サービスファイルは次のような感じです。Mastodonで最も混雑するキューはdefaultキューです。フォローされているユーザがトゥート!すると大量のタスクが一気に積まれます。このタスクを高速でさばかないとキューが詰まる状態になり、タイムラインの遅延を発生させる原因になります。Pawooでは現在defaultキューを720スレッドでさばいていますが、ここをいかに高速化するかが課題になりそうです。インスタンスタイプを調整するサービスリリース当初は、どの程度の負荷になるかわからなかったため、適当なインスタンスタイプを選択してスタートしましたが、負荷に応じて何度も調整を行っています。最初はt系のインスタンスを使っていましたが、CPUクレジットを使い切るタイミングで一時的に負荷が上昇するようになってしまったため、c4が中心の構成にしました。将来的にはスポットインスタンスを使ってコスト圧縮を図っていきたいと考えています。マストドンにコントリビュートするさて、ここまでインフラ的な側面からMastodonの改善を試みてきましたが、実際サーバを増やすよりもコードを改善した方が効果が高いところがたくさんあります。ピクシブでは複数のエンジニアがMastodonに本体にPRを作成し、改善作業を行っています。#1970今年4月に入社したばかりの新卒エンジニアもPRを送っています。その全ての改善をこの記事で触れることはできませんが、ピクシブで行った改善は今後紹介していきたいと思います。まとめPawooはまだ運用始めたばかりでこれから大きくなるサービスです。コードもすごい勢いで改善されており、インフラ構成もそれに合わせて変えていく必要があるでしょう。ピクシブではpawoo.netを立てただけでなく、引き続きMastodonの発展のためにあらゆる改善を行っていきます。2012年ピクシブ株式会社に入社。インフラチームとして画像配信、ログ解析基盤などを担当。現在はImageFluxのプロダクト責任者を務める。Reserved.スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。