ワニスと他のリバースプロキシ
私は、VarnishをすべてのWebトラフィックのキャッシングリバースプロキシとして展開している組織と協力しています。彼らのトラフィックは、顧客が生成した動的なWebサイトの多くであり、静的な資産の通常のコレクションが横にぶら下がっています。
ワニスを好きにしようとしていますが（原則としてかなり良いアーキテクチャだと思います）、ワニスの管理や問題のトラブルシューティングに問題が発生しているので、本当に正しい選択かどうか疑問に思っています。私は過去にイカをリバースプロキシとして使用しましたが、同じ種類の役割ではないため、比較の明確な根拠がありません。
私の質問は、ワニスを生産に導入したか、代替案に対して真剣に評価した人々を対象としています。ワニスを使い続けたのですか、それとも別のリバースプロキシを使用することになったのですか。それを維持したり切り替えたりするための重要なポイントは何でしたか？また、他のものを使用した場合、最終的に何を使用しましたか？
さて、私は主にパフォーマンス上の理由から、WebサーバーでVarnishを実行していますが、その負荷分散機能も便利です。
私のユースケースは Django ベースのWebサイトの前でキャッシュすることであり、ページの読み込みパフォーマンスに驚かされます。私はほとんどのページをキャッシュから直接提供し、ほとんど問題なく大量の訪問者を処理することができます。
私がワニスを選んだ理由は、主にパフォーマンス/スケーラビリティでした。主なポイント：
- ワニスは、カーネルが仮想メモリを管理するようにしましょう。Squidは、ディスクとメモリのキャッシュを別々に保持しようとしますが、カーネルとSquidは、ディスクにページアウトする内容について少し混乱する可能性があります。
- Varnishは、独自のドメイン固有構成言語であるVCLを使用します。これは、Cを介してマシンコードにコンパイルされます。これは、構成に少なからぬロジック（条件付きヘッダーストリッピングなど）がある場合、パフォーマンス上の非常に大きなメリットです。
私の経験では、ほとんどの場合、VarnishはSquidよりも少し優れており、トラフィックの急増に対してははるかに優れています。一方、Varnishを正しく構成するには、メーリングリストのトロールが必要になります。これは、ネット上を流れるすぐに使える特定のユースケースドキュメントの数が少ないためです。 Squidの場合–主にVarnishが比較してかなり若いプロジェクトであるためです。