50〜10万人のユーザー向けのHttpdサーバー最適化
現在、AWS EC2インスタンスm5.24xlargeがあります。
- 96 vCPU
- 384 RAM
- 25ポンドのネットワーク
現在5万人以上の同時ユーザーがオンラインでいると予想しています。cloudflareにレイヤーを追加しましたが、問題はApacheでserver reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers settingを引き続き取得することですerror_log。
この種のトラフィックを処理するためのApacheの最適な設定は何ですか？
あなたはそれを間違っていると思います。 1つの巨大なメガインスタンスを実行する代わりに、ロードバランサーの背後で小さなインスタンスのフリートを実行するを実行する必要があります。たとえば、m5.24xlarge with24 xm5.xlarge、理想的には、スポットインスタンスを持つ自動スケーリンググループコストを節約します。
いくつかの理由は次のとおりです。
大きなインスタンスが失敗したり、メンテナンスが必要になると、ウェブサイト全体がダウンします。同じことが小さなインスタンスの1つに発生した場合、容量の1/24しか失われません。
トラフィックが変化したときに容量を追加したり削除したりできます。たとえば、需要が少ない週末または夜間に一部のインスタンスを自動的にシャットダウンします。お金を節約します。
失敗したインスタンスのリカバリを自動化したり、スポットインスタンスを使用してさらにお金を節約したりできます。
アプリケーションを少し再設計する必要があるかもしれないと述べました。たとえば、現在同じインスタンスでdatabaseが実行されている場合は、それをAWS Auroraに移動して、すべてのインスタンスで使用できるようにする必要があります。
filesystemについても同じです。アプリがユーザーデータをローカルに保存している場合は、共有ファイルシステムを導入する必要があります。 AWS EFS-Elastic File System。
いくつかの作業が含まれていますが、水平方向にスケーリングすることの大きなメリット（より小さなワーカーを追加してジョブを実行する）と垂直方向（単一のワーカーをどんどん大きくする）があります。
それが役に立てば幸い:)
非常に大きなWebサーバーインスタンスでスケールアップすることは実際に可能です。
Httpdの警告が示唆するように、MPMを調整する必要があります。まずMPMを選択します。イベントは素晴らしくパフォーマンスが良いですが、モジュールによってはpreforkが必要になる場合があります。
MaxRequestWorkers は、以前はMaxClientと呼ばれていました。あなたの記憶が許す限りこれを増やしてください。たとえば、 MaxClient値をapacheで計算する簡単な手順を考えてみますか？ 350 GBのメモリを使用できると仮定します。その他の諸経費。 topからのプロセスごとのRSSで除算します。それが50 MBで、結果が7000を超えるとしましょう。これがMaxRequestWorkersでの最初の推測です。 ServerLimitもこれより大きくする必要があります。10000を試してください。
負荷がかかっている状態でのユーザーの応答時間を監視して、その動作を確認します。 50,000人の同時ユーザーは、リクエストに対応するためにそれほど多くのワーカーを必要としない場合がありますが、アプリケーションによって大きく異なります。
物事を監視しながら、次のチューニング変更実験を計画します。おそらくThreadsPerChildを増やすと、プロセス数が少なくなり、それに応じてメモリ使用量が減ります。
50kは、より多くのオペレーティングシステムで、デフォルトの一時的なポート範囲を超えています。すべてのトラフィックが同じロードバランサーのIPとポートからのものである場合は、それを回避する方法を検討してください。