CDN77 での NGINX とアップストリーム サーバー間のトラフィックのログ記録

実行しているプラットフォームに関係なく、ログ記録は、ビッグ データ処理、統計、監査、クライアント レポート、トランザクション、およびクライアントとサーバーの通信や発生する可能性のある問題のデバッグにとって、中核的な要件となることがよくあります。

このブログでは、デバッグにおけるログの役割について説明します。ログは、インターネット通信でよくあるさまざまな問題を特定するための究極のツールを提供します。

クライアントと Web サーバー間の通信をログに記録すると、ブラウザーのバージョン、クライアントのネットワーク、アクセスされているファイルに関連する可能性のある問題のデバッグに非常に役立ちます。 しかし、それで終わりではありません。 ログに記録する内容は、プラットフォームと要件に応じて無限に存在します。

NGINXのログアーキテクチャ

リバース プロキシ、ロード バランサ、またはコンテンツ配信ネットワーク (CDN) を実行すると、クライアントとサーバー間の通信フローに別のノードが追加されます。 リバース プロキシのようにデータを操作する中間サーバーでは、予期しない問題が発生することがよくあります。

リバース プロキシとして、NGINX はクライアントからの接続を終了し、サーバーへの新しい接続を作成することにより、クライアントから Web サーバー (または他のアプリケーション サーバー) への接続を 2 つの個別の接続に変換します。 2 つの接続に「分割」すると、ログ記録用の 2 つの別個のコンテキストも作成され、NGINX はそれらのログ記録を多少異なる方法でサポートします。

• クライアントとリバース プロキシ間のトラフィックについては、NGINX はエラー ログとアクセス ログの両方を提供します。これらは、エラーではない処理イベントとアクションを記録します。

  error_logディレクティブを使用してエラー ログを有効にし、ログに記録するエラーの重大度レベルを設定できます。

  access_logディレクティブを使用してアクセス ログを有効にします。 関連するlog_formatディレクティブを使用すると、ログに含まれる情報の種類とログ エントリの形式をカスタマイズできます。 ログはファイル、syslog、またはその両方に書き込むことができます。

• リバース プロキシと Web サーバーまたはアプリケーション サーバー (NGINX ではアップストリーム サーバーと呼びます) 間のトラフィックについては、NGINX はエラー ログをサポートします。 ただし、このトラフィックのアクセス ログはサポートされていません。

  プロキシ サーバーとアップストリーム サーバー間のエラー以外のイベントを確認する唯一の方法は、エラー ログの重大度レベルをdebugに設定することです。 この設定の欠点は、膨大な量のデータが記録されることです。 これにより、リクエストの処理速度が低下し、ストレージがすぐにいっぱいになる可能性のある非常に大きなファイルが作成されます。 (デバッグのサポートはデフォルトでは有効になっていないため、 configureコマンドで--with-debug引数を指定して NGINX を再コンパイルする必要があることに注意してください。)

当社のアップストリームログソリューション

CDN プロバイダーとして、リバース プロキシ サーバーやクライアントと適切に通信していないアップストリーム サーバーに遭遇することがよくあります。 エラー ログ内のデバッグレベルのメッセージは、アップストリーム サーバーの問題を修正するために必要な情報を必ずしも提供しません。

解決策はすぐに明らかになりました。リバース プロキシとアップストリーム サーバー間の通信から必要な情報だけを収集する機能を追加して、アップストリーム アクセス ログを生成するというものです。

基本的な考え方としては、アップストリーム サーバーにリクエストが行われるたびに、NGINX が関数を呼び出すようにすることです。 これにより、アップストリーム ロギングに関連するすべてのロジックを関数自体にプログラムできるようになります。

標準のngx_http_upstream_module はアップストリーム リクエストを処理するため、関数を呼び出すためにこれが必要です。 モジュールは現在そのような機能をサポートしていないため、必要に応じてコールバックを有効にするようにパッチを適用しました。

ログ記録自体は、私たちが作成した別のモジュールで処理され、パッチを適用したアップストリーム モジュールに追加したログ コールバック機能を使用します。 新しいモジュールは、ログ機能を設定するための新しいupstream_logディレクティブを定義します。 このディレクティブはaccess_logディレクティブと同じパーサーを使用するため、データをファイルに書き込むことも、ソケットを使用して syslog サーバーに送信することもできます。

NGINX が起動時にnginx.confのupstream_logディレクティブを読み取ると、次の 2 つの関数が呼び出されます。

• ngx_http_upstream_log_set_logは、ディレクティブを解析し、内部的にngx_log_set_logを使用してログ構造自体 ( ngx_log_t ) を準備します。
• ngx_http_upstream_log_init （設定後のステップ）は、メインのログ機能をアップストリームモジュールに登録します。

こうすることで、リクエストを上流にプロキシする必要があるときに、すべてが準備されます。 アップストリーム モジュールはアップストリーム サーバーへの接続を開始し、パッチはログ機能が呼び出されてリクエストの詳細がログに記録されるようにします。

ログ形式はアップストリーム モジュールにハードワイヤードされています。 log_formatディレクティブを使用して構成のサポートを追加するオプションはまだありますが、このユースケースでは必要ありません。

上流から記録された値

ログ機能は、アップストリーム サーバーへの接続が閉じられた直後に呼び出されます。 その引数は現在処理中のリクエスト ( ngx_http_ request_t構造体) へのポインターであり、これにより関数は構造体内のすべてのデータにアクセスしてログに記録できるようになります。 アップストリームフィールド ( ngx_http_upstream_tへのポインタ) には、アップストリーム要求に関するデータが含まれているため、特に重要です。 私たちが特に興味を持っているのは、以下の点です。

• オリジンレスポンスステータスコード
• リクエストの期間
• レスポンスまたはホストヘッダーのHTTPヘッダーの値

リクエスト構造全体にアクセスできるため、さまざまな情報をログに記録できるため、モジュールに柔軟性がもたらされます。

遭遇した問題

当初、この機能はngx_http_core_moduleに実装されました。 これはプロトタイプとしては十分でしたが、将来のアップデートや変更を複雑にする可能性があるため、あまりクリーンなソリューションではありませんでした。 最終的に、アップストリーム ログ ソリューションで説明されているように、アップストリーム ログ機能をスタンドアロン モジュールに分離しました。

もちろん、実装上の問題もいくつかありました。 最も顕著なのは、いくつかの場所でngx_str_t文字列を誤って処理したことです。たとえば、 ngx_snprintfの代わりに C ライブラリ関数sprintfが使用されていました。 これにより、アップストリーム ログに未定義のデータが書き込まれたり、ワーカー スレッドでセグメンテーション エラーが発生したりする可能性があります。 このような問題は、Valgrind や AddressSanitizer などのツールを使用して徹底的にデバッグおよびテストを行った結果、解決されました。

CDN77 で使用される NGINX の機能

CDN77 が NGINX を使用する主な理由は、そのキャッシュ機能のためです。 CDN サーバーは、クライアントと Web サーバー (上流サーバー) の間に導入されるノードであり、クライアントの要求を渡し、上流サーバーに適切なファイルを要求します。 ファイルがキャッシュされると、同じ場所から同じファイルを要求している他のユーザーに配信されます。

「ローカルで提供されるファイル」は、リクエストを受け取ったときに NGINX がサーバーのディスクからファイルを提供できるようにするために使用している機能の 1 つです。

安全なキャッシュには、いくつかの追加機能と構成が必要です。 コンテンツを適切に保護するために、SSL (0-RTT 付き TLS 1.3) または特定の IP アドレスに対して生成できる安全なトークンを使用します。

私たちが使用するその他の機能には、クライアント向けのカスタム エラー ページ、OCSP ステープリングのデフォルトの NGINX 実装、必要な PHP プロセスの数を減らすための PHP 用 FastCGI などがあります。

結論

アップストリーム ロギングは、さまざまな問題のデバッグに役立ち、今後も役立つだけでなく、NGINX のコア機能をさらに深く掘り下げる素晴らしい機会を提供し、私たちが取り組んでいる他の多くのプロジェクトを簡素化しました。

CDN77について

CDN77 により、世界中でコンテンツ配信がより良く、より便利になります。 当社は 30 を超えるデータセンターを保有しており、世界中でコンテンツを効果的にキャッシュして配信することができます。 これには、Web サイトの静的コンテンツ、ソフトウェア配布、ビデオ オン デマンド (VoD)、専用のストリーミング エンジンを使用した HLS や MPEG‑DASH などのさまざまなプロトコルによるライブ ストリーミングが含まれます。

CDN77 の使用開始は非常に簡単、迅速、かつ簡単です。 無料トライアルにサインアップし、CDN リソースを作成し、生成された CDN URL またはカスタマイズされたCNAMEレコードを使用して、Web サイトまたはストリーミング ソリューションに統合します。 すべての機能、設定、および可能なカスタム ソリューションにより、CDN77 はお客様の要件を満たします。