この投稿は「ConoHa Advent Calendar 2022」の5日目の記事です。
突然だが、僕はDiglaWorks（つまりはここ）のサイト（Wordpress）、Mastodonのインスタンス、NextCloudをメモリ1GBを単一のVPSで管理している。
アクセス数が普段あまり多くないこともあり、少なくとも自分の場合だと意外と1GBでの運用維持が可能である。
さて、世の中は色々と大変である。色々な機材の価格が高くなりつつあるし、テクノロジー方面から逸れれば自分はスパゲッティを2束茹でて、あえるタイプのソースと混ぜて食べるのが好きなのだが、非結束なソレですら若干じわじわと上がり始めて危機感を感じている。
「余剰」となる部分のカットは誰もがやらざるを得ない状況だし、そもそもそんな状況が起きなくても積極的にカットするのは生きていくうえで結構大事である。個人で「スケーリングしなくちゃ……！」と慌てる機会が訪れるのは人それぞれだし（自分の場合は一度も起きたことがない）、他にも例えば「このはちゃんのカレンダーを買いたいから低コストで抑えたい」などプライベートな事情もあるだろう。
しかしただメモリをスケールダウンすれば容易にOut of Memoryとなり、OOM Killerが大切なプロセスを狩りに来るかもしれない。……というか、昔はしょっちゅうOOM KillerがMySQLを狩って大変だった（その節はご迷惑をおかけしました）。
そのため、自分が行った手法についても同時に説明する。
免責事項
当記事は自分の知見を述べたものであり、どんな環境にでも適合するわけではないと思っている。特に後半部はシステムのパラメーターを操作する。その結果、あなたの環境では逆効果になってしまうことも十分想定できる。
今回の記事で述べた内容を実行して損害等が発生した場合でも、手倉テイムは一切責任を負わない。バックアップやスナップショット大事。
（可能であれば）VPS割引きっぷを使う
ConoHa VPSには数か月分を一括で前払いする、「VPS割引きっぷ」という制度がある。
自分の個人サイトなど、長期間にわたって維持することが確定しているのであれば、「VPS割引きっぷ」を使って数か月分を一気に払っておけばある程度安くできる。
月額は確かにコストを抑えられるように見えるが、大抵のサブスクリプションサービスがそうであるように一括で払ったほうが若干安価だし、予算も立てやすい。
時々割引キャンペーンを行っているようなので、そのタイミングで割引きっぷを確保しておくのがいいかもしれない。
しかしながら、払うコストが減ったからといってVPS内の負荷も減るわけではない。そのため、以下に自分が行っているあれこれを記載しておく。
……なお余談だが、お得であるということが分かっていながらも、筆者はVPS割引きっぷをこれまで一度も使ったことがない。そもそも年間ずっと使っているサービスにも年額のほうが割安と分かっているのに月額で払ってしまうタイプである。どうにかして来年以降はその辺りも改善したい。
2023年4月25日追記: 結局2GBに増やした+きっぷを使うようにした
2023年3月1日よりVPS割引きっぷがリニューアルされ、「SSLセット」「シンプル」の二種となった。さらに「1か月」のプランが新設されたことで、月額で使う場合において安価に運用できるようになった。
一か月は絶対稼働させる、という人は割引きっぷがお得である（サービス維持調整費がかかるようになったので、月によっては若干の変動があるが……）。
実は記事の投稿後、サーバーリソースを2GBに増強することが必要だと判断し、2GBプランへスケールアップした。元々1GB環境での動作を前提としたチューニングを行っていたので、結果的にサイトのパフォーマンスも上がる高い効果を記録した。
結果的にこの記事の意義の一部が薄れたが、某Blueの値段（そもそも増強を決断した理由は……明記しなくても皆察するだろう）+これまでの運用用途を考えればそれでも安いのでよしとする。
稼働するアプリケーションは厳選する
これはサーバーの分散、メンテナンス性の向上という面でも重要である。色々同時に動けばそれだけリソースを消費するし、例えDocker等でコンテナ化したとしても、メンテナンスがかなり複雑になる。
そのため「CMSでなく静的ページジェネレーター等を用いる」など、用途に合わせて運用を工夫すべきである。
そもそもVPS上に設置するということは「全くその意図がなくとも、誰かがそこを訪れる可能性もある」ということでもあるし、根拠として適切かどうかは置いておいて、ファイヤーウォールや認証試行ログもそのリスクというものを証明している。
世の中の情勢等もあり、簡単に外出先から自宅のネットワークにセキュアにアクセスする環境も整ってきており、必ずしもVPSが必要という場面はサイトの公開等、永続的な用途に限られると思われる。また、セキュリティの観点からもパブリックな場で実験やテストを行うのは好ましくない。
なのでまずは「本当にネット上に置く必要があるのか」から考えるべきだし（サーバーに長時間負荷がかかるようなものならなおさら）、用途によってはNASや自宅サーバー、それどころかWSL等の仮想マシンが最適だというケースもある。
節約の第一歩である「選択と厳選」はソフトウェアの世界でもあてはまる。まずはここから始めると、気づいていなかった脆弱性やバグも見つけられるかもしれない。
Mastodonで「連合」をあまり組まない
某大手SNSの買収に伴う騒動がきっかけで、先月からまた人気が再燃しているように思うMastodon。この記事を読んでいる人の中にも、VPSの導入目的としてMastodonを挙げる人が数人はいるのではないだろうか？
各自でそれぞれのインスタンス（サーバー）を持ち、管理者がルールまで制定できるのが大きな特徴であり、またそれらのインスタンス同士が繋がり「連合」が組まれるのもまた特徴である（それが相手先でポリシー面の都合等からドメインブロックが行われトラブルに発展するケースもあるが……）。
しかしながら、Mastodonはメモリをかなり消費する。当然.env.productionでスケーリング設定などをしているが、それでもSwapfileの半分以上を消費している。
やりとりするインスタンスが増えれば、それだけ負荷も上昇する。用途次第では承認制アカウント（フォロワーを手動で承認する形式、🔒マークが付与されるが「非公開」ではない）に設定する、Mastodonのミッションに反するとして推奨はされていないが、LIMITED_FEDERATION_MODE等での運用等も検討すべきである。
ただしLIMITEDにすれば、当然ながら外部のインスタンスからフォロー不可になることは留意されたい。そのため、自分のインスタンスではいわゆる「おひとりさま」であることもあり、LIMITEDは有効にしていない。
さて、Mastodonには「連合リレー」という機能がある。……が、これは迂闊に導入してはいけない。なぜならリレーサーバーを通した先に万が一相手先にユーザー数を持った、かつ画像や動画が頻繁にやりとりされるサーバーがいた場合、サーバー監視のディスク使用量アラートがすごい勢いで届くことになる（経験談）。
サーバーごとにモデレーション等のルールは異なるということもあり、多数のサーバーと「とりあえず」で繋がるのはMastodonの考え方としてもあまり適切とは言えない……ように思う。
「中小規模のサーバーが連合のコンテンツを見つけるのを助けます」と説明に書かれている通り、連合リレーはあくまで「気が合うコミュニティとデータをやり取りする」程度に抑えるべきである。
……と、厳しいことを書き連ねたが、「Mastodonのインスタンスを自分で持つ」というのはサーバー管理者の腕前が試されるという点でなかなか楽しい。
また、ActivityPubというプロトコルを基に作られているということは、今後低リソースなサーバーでも軽快に動作する互換かつ軽量なプロジェクトや、特定コンテンツに特化したプロジェクト（PixelFedなど）も作れる、選択できる、つまり必ずしもMastodonである必要はない、ということである。
色々と大変だとは思うが、「運営元の方針やポリシーに振り回されない」「自分で方針やポリシーをコントロールできる」体験は他では味わえない、そしてネット黎明期に誰もが熱狂した（らしい）体験なので、誰かのインスタンスに参加するのもいいが、是非自分で運営することにも挑んでみてほしい。
余談だが、1GBのVPSだとMastodonがビルドがOOMでコケるので2GB以上を推奨する（自分はDocker Hub上のプリビルド済みイメージを引っ張ってくることで解決）。
メモリ圧縮を使う
ここ近年のモダンなOSでは既定で有効になっている機能、それがメモリ圧縮である。圧縮した上でなるべくメモリ内に保持し、長らく使われていないRAM上のデータからSwapに逃がすのである。
その仕様上、若干パフォーマンスに影響があるかもしれないが（特にCPU負荷）、あまり速度を重視しないサイトでは大きな効果を発揮すると思う（高い応答性が期待される環境では使うべきでなく、大人しくスケールアップが適切である）。また、当然ながらSwapへのI/Oアクセス回数を大幅に減らせることが期待できるため、若干インフラ・ハードウェアチームへの罪悪感が薄れる。
この方法については、Ubuntu公式ブログの「Raspberry Pi 4の2GBモデルでUbuntu Desktopを使う」方法を参考にした。
実際にこの手法を自分のRaspberry Pi 4 2GBモデルで運用してみたが、それまでGNOMEを立ち上げた時点でギリギリ、Codeを立ち上げるとハングアップしかねないような状態だったのが緩和された（少し記事の趣旨としてはズレるが、それでもデスクトップ環境としてガッツリ使いたいのであれば4GBモデル以上をおススメする）。
そのため「これはサーバーでも使えるかも……」と思い、ConoHa VPSのホストCPUのスペックを信じVPSにも設定した……というわけである。
使い方としてはzswap.enabled=1をカーネルのブートパラメーターに追加するだけである（grubのdefaultを弄るのが一番早い）。これだけでも効果を期待できるが、コンプレッサーの形式や圧縮手法を工夫することで、さらなる効果を見込める。説明や設定手法は参考にしたページや、ArchWikiを参照されたい。
おわりに
以上、駆け足で自分の運用Tipsを述べてきた。低メモリーな環境で動作するよう工夫することはどんな環境でも動くシステムを組み上げる一歩であると共に、一度挑むと極限までチューニングしたくなる「沼」である。
自分でも今回述べたTipsがベストプラクティスであるとは思っていない。今後も適宜色々試行錯誤し、快適な低コスト・低メモリ運用を続けていきたいと思う。
ところで2021年カレンダーの12月のこのはちゃん可愛すぎません？？？？？？？（カレンダー所持者にしか分からないアレ）
アイキャッチ画像: 「部屋の黒いサーバーラック」（Manuel Geissinger）
