Webship ブログに戻る

Webship エンジニアリング

あなたのウェブサーバーはインフラコストの決定です

Webship は、高スループットの Rust 配信、最新プロトコル、組み込みの保護機能、ローカル可観測性、AIネイティブ運用を 1 つのランタイムで組み合わせ、インフラチームにサーバーの数やエッジコンポーネントの数を減らす現実的な道筋を提供します。

ほとんどのインフラチームは、ウェブサーバー単体に対して支払うわけではありません。彼らが支払うのは、それを取り巻くすべてのものです:ピークトラフィック用に確保された余分な計算リソース、個別のセキュリティサービス、テレメトリエージェント、構成自動化、そしてこれらの要素を一貫して維持するために必要なエンジニアリング時間です。

それはウェブサーバーをインフラコストの決定事項にします。より速いバイナリは有用です。より小さく、より制御可能な本番システムこそが本当のビジネス成果です。

スループットは、キャパシティプランを変更する場合に重要です

Webship は、高負荷の静的配信および HTTP/1.1、HTTP/2、HTTP/3 にわたるリバースプロキシのために Rust 上に構築されています。現在の検証済み Debian 直接配信マトリックスでは、4 つの Webship ワーカーが h2c 上で中央値 1,041,848 リクエスト/秒、HTTP/3 上で 307,727 暗号化リクエスト/秒を維持しました。

別個の同時期の同一ホスト比較は、競合相手の状況を提供します。その実行では、Webship は h2c で 1,015,870 リクエスト/秒を提供し、Nginx は 192,324 リクエスト/秒でした。HTTP/3 TLS 上では、Webship が 317,138 リクエスト/秒を提供し、Envoy は 35,207 リクエスト/秒でした。すべての公表された結果は、隔離された CPU セットとゼロエラーの正確性ゲートを用いた、承認された 5 サンプルの中央値です。

これらの測定値は証拠であり、普遍的な性能保証ではありません。アプリケーションの動作、応答サイズ、TLS構成、キャッシュヒット率、ネットワーク状況、および上流のレイテンシが結果を変化させます。重要な問いは、見出しの数値がそのまま転送されるかどうかではなく、Webship があなたのワークロードをより少ないノードで、またはノードごとにより余裕を持ってサービス目標を達成できるかどうかです。

Webship ベンチマークページで、完全な方法論とすべての競合結果を確認してください。

統合は経済性が現実になるところです

従来のエッジは、Webサーバー、リバースプロキシ、TLSターミネーター、キャッシュ、WAF、レートリミッター、メトリクスエンドポイント、および別の運用APIを含むことがあります。各コンポーネントは優れている場合がありますが、組み合わせたシステムは、より多くの設定面、ネットワークの移行、アップグレード、障害モード、そして請求書を生み出します。

Webship は、静的ファイル、アプリケーションプロキシ、TLS 1.3、HTTP/3、WebTransport、キャッシング、WAF、DDoS コントロール、API シールド、レスポンスセキュリティヘッダ、可観測性、および運用管理を 1 つのデプロイ可能なバイナリに統合します。

その境界に収まるワークロードに対しては、統合によりCPUの需要以上のものを削減できます。エンジニアがインシデント時にプロビジョニング、監視、セキュリティ確保、調整しなければならないサービスの数も減らせます。Webship は、グローバルCDN、上流のスクラビングネットワーク、またはあらゆる専門的なセキュリティ製品を置き換えることを主張しているわけではありません。それは、別のサービスが必要になる前に、チームに強力なセルフホスト型の基本基盤を提供します。

AIネイティブは管理された操作を意味するべきです

インフラにチャットインターフェースを追加することは、運用の自動化ではありません。AIネイティブのウェブサーバーには、制限された制御面、明示的なポリシー、検証、監査可能性、そしてロールバックが必要です。

Webship は、構成の読み取りと検証、リクエストポリシーの説明、シャドウ変更の比較、トラフィックシナリオの実行、境界診断の検査、キャッシュエントリの管理、TLS状態の確認、承認されたランタイム安全な変更の適用またはロールバックのための認証済み Model Context Protocol 操作を公開します。

コントロールリスナーは公開トラフィック経路から隔離されており、ループバック上かTLSと強力なベアラートークンの背後にあるプライベートネットワーク上にあるべきです。ランタイムに安全なパッチは、トラフィックを中断することなく適用できます。リスナー、TLS、および認証の変更は、依然として意図的な再起動を必要とします。この区別により、すべての本番環境の変更がリスクフリーであると装うことなく、オートメーションの有用性が保たれます。

操作モデルについては、AIエージェントクイックスタート を参照してください。

セキュリティは最初の設定に属する

Webship はセキュリティベースラインから始まります:WAF検査、クライアントごとのDDoS制御、ボットチャレンジ、APIエンドポイントおよびコンテンツタイプの検証、応答セキュリティヘッダー、ドットファイル保護。これらの制御は、別のデフォルトネットワークホップを追加するのではなく、データプレーンで実行されます。

「組み込み済み」とは完成を意味するわけではありません。オペレーターは依然としてファイアウォールポリシー、シークレット、オリジンのセキュリティ、アップデート、アプリケーションのセキュリティ、およびワークロード固有のルール調整を担当します。利点は、最初のデプロイメントの段階ですでにこれらの意思決定を強制し、検査するための一貫した場所があることです。

自社のトラフィックに基づいてビジネスケースを構築する

信頼できる評価は、次の四つの質問に答えるべきです:

  1. Webship は、あなたの静的、プロキシ、WebSocket、および最新プロトコルのパス全体でリクエストの正確性を保持しますか?
  2. 代表的なトラフィック下で、持続スループット、テイルレイテンシ、CPU、およびメモリはどうなりますか?
  3. チームが依存している機能を失うことなく、いくつのエッジコンポーネントを統合できますか?
  4. オペレーターやAIエージェントは、あなたのセキュリティモデル内でポリシーを診断、検証、変更、元に戻すことができますか?

既存のエッジの隣で Webship を実行し、実稼働に近いトラフィックを再生し、ロールバックのために古いリスナーを利用可能なままにします。測定された持続可能なスループットをノード数モデルに変換し、その後、残るすべてのコンポーネントの運用コストを追加します。これにより、ベンチマークに基づく推測ではなく、正当化可能なインフラストラクチャの判断が得られます。

Webship は、導入前に経済性を試したいチーム向けに 14 日間の評価パスを提供します。まず ドキュメント を参照し、ダウンロード から署名済みビルドを選択し、現在運用しているシステムと比較して評価してください。