OpenLiteSpeed を放棄し、古き良き Nginx に戻りました

2017 年以来、暇なときは (笑)、同僚のエリック バーガーがヒューストン地域の天気予報サイトであるSpace City Weatherを主催するのを手伝っています。これはホスティングの興味深い課題です。通常、SCW は 10,000 ～ 15,000 人のユニーク訪問者に対して 20,000 ～ 30,000 ページ ビューを処理しますが、これは最小限の作業で比較的簡単に処理できる負荷です。しかし、厳しい気象現象が発生すると、特にハリケーンがメキシコ湾に潜む夏には、サイトのトラフィックが 12 時間で 100 万ページビュー以上に急増することがあります。このレベルのトラフィックを処理するには、もう少し準備が必要です。

非常に長い間、私はSSL 終端用のHAProxy 、オンボックス キャッシュ用のVarnish Cache 、および実際の Web サーバー アプリケーション用のNginxで構成されるバックエンド スタックで SCW を実行しました。これらはすべて、負荷の大部分を吸収するためにCloudflareによって前に置かれていました。(このセットアップについては、より詳細な詳細を知りたい人のために、数年前に Ars で詳しく書きました。) このスタックは完全に実戦テストされており、私たちが投入したトラフィックをすべて飲み込む準備ができていましたが、煩わしいほど複雑でもありました。 、対処すべき複数のキャッシュ層があり、その複雑さにより、問題のトラブルシューティングが予想以上に困難になりました。

そこで、2 年前の冬のダウンタイム中に、私は複雑さを解消し、ホスティング スタックを単一のモノリシック Web サーバー アプリケーションOpenLiteSpeedに減らす機会を利用しました。

古いものを捨て、新しいものを取り入れる

OpenLiteSpeed (友達の間では「OLS」) については、WordPress ホスティングに関するディスカッションで何度も言及されること以外はあまり知りませんでした。また、SCW が WordPress を運営しているため、興味を持ち始めました。OLS は、特に WordPress が関与している場合に、統合されたキャッシュで多くの賞賛を得ているようです。Nginx に比べてかなり速い と言われていました。そして、率直に言って、同じスタックを 5 年ほど管理した後、私は状況を変えることに興味を持ちました。OpenLiteSpeedでした！

対処すべき最初の重要な調整は、OLS が主に実際の G​​UI を介して設定されることであり、これに伴うすべての厄介な潜在的な問題 (セキュリティ保護する別のポート、管理する別のパスワード、バックエンドへの別のパブリック エントリ ポイント、PHP の増加) が伴うということでした。管理インターフェイス専用のリソース）。しかし、GUI は高速で、公開する必要のある設定はほとんど公開されていました。既存の Nginx WordPress 構成を OLS 言語に変換することは良い適応訓練であり、最終的には管理コンソールを隠し、概念的に安全な状態に保つための許容可能な方法としてCloudflare トンネルに落ち着きました。

もう 1 つの主要な調整は、WordPress 用の OLS LiteSpeed Cache プラグインでした。これは、WordPress 自体が OLS およびその組み込みキャッシュとどのように対話するかを構成するために使用する主要なツールです。これは、構成可能なオプションが何ページにもわたる大規模なプラグインであり、その多くはQuic.Cloud CDN サービス(OpenLiteSpeed とその有料兄弟であるLiteSpeedを作成した会社である LiteSpeed Technology によって運営されています) の利用促進に関係しています。

OLS で WordPress を最大限に活用するには、プラグインに時間をかけて、どのオプションが役に立ち、どのオプションが不利になるかを判断する必要がありました。(当然のことかもしれませんが、キャッシュを積極的に使いすぎると、愚かな問題に巻き込まれる方法がたくさんあります。) 幸いなことに、Space City Weather は、非常にキャッシュを備えた非常にアクティブなサイトであるため、Web サーバーの優れた実験場を提供します。フレンドリーなワークロードだったので、私はかなり満足できる開始構成を練り出し、古代の神聖な儀式の言葉を唱えながら、カットオーバー スイッチをオンにしました。HAProxy、Varnish、Nginx は沈黙し、OLS が負荷を引き継ぎました。