NGINX(コミュニティ版)

11/14(水)、NGINX MeetUp Tokyo #1 を開催します!

前回のMeetUp #0に続き、11/14(水)にNGINX MeetUp Tokyo #1 を開催します。

概要

日本のNGINXユーザー、また関心をお持ちの方に向けてNGINX最大のイベント NGINX .conf 2018 の最新情報とWeb Application Firewall機能のNGINX WAFをご紹介します。2つのセッションとセッション終了後には懇親会を用意しておりますので、NGINXを利用する方同士での交流もいただける場になっています。

これからNGINXを使ってみたいという方も、NGINXを使いこなしている方も、NGINXにご興味をお持ちの方、NGINXが大好きなかたまで皆様のご参加をお待ちしております。

なお、Meetupの内容は後日動画配信を予定しております。遠方の方は配信動画の公開をお待ち下さい。 NGINX MeetUp Japanのグループ登録も合わせてよろしくおねがいします!!

プログラム

  • 16:30~    受付

  • 17:00~17:10 オープニング & NGINX Meetup Japan 立ち上げについて

  • 17:10~17:40 講演1 NGINX .conf 2018最新情報

    概要:サイオステクノロジーの原尚史が、アトランタで2018年10月6日〜8日に開催されたNGINX .conf 2018 の最新情報をお伝えします。
    現地で入手したNGINXの最新情報をどこよりも早くお伝えいたします。 

    講師:サイオステクノロジー株式会社 イノベーティブソリューション事業企画部 原 尚史

  • 17:40~18:10 講演2 NGINX WAFについて

    概要:サイオステクノロジーのセキュリティエヴァンジェリスト 面 和毅が、NGINX WAFについてご紹介します。
    コミュニティ版とPlus製品の違いを含めてご紹介予定です。 

    講師:サイオステクノロジー株式会社 セキュリティエヴァンジェリスト 面 和毅

  • 18:10~19:00 懇親会 NGINX ノベリティ抽選会!!

※講演資料は本サイトにて後日公開予定です。

イベント参加について

以下URLよりお願い致します。

【申し込みURL】

https://nginx-mj.connpass.com/event/103617/

ソフトウェアロードバランサーによるアジャイル実現

こんにちは、サイオステクノロジーの原です。
今回は“アジャイル”をテーマに、いかにソフトウェアロードバランサーがアジャイルに向いているかについてブログに記載したいと思います。

アジャイルとは

アジャイルは従来のウォーターフォール手法(“要求仕様 – 設計 –  テスト – 実装 – 保守”といった各フェーズを順を追って着実に進めていく)と違い、
各フェーズ毎で順を追わず、柔軟に対応することで工数削減に繋がる手法です。

例えば、各データセンターへのロードバランサー導入プロジェクトがあるとします。

ウォーターフォール手法では、要求仕様フェーズでスケジュール、納期、成果物等をお客様としっかり合意を得た上で仕様書を作成し、仕様書に基づいて設計書に起こします。
設計書が完成するとロードバランサーのテストが始まり、各テスト項目がクリアした段階で実装に向かいます。
着実にフェーズをこなしていくため、正確性はありますが俊敏性は欠けています。

一方アジャイルでは、要求仕様フェーズである程度の情報が整い次第、実装に向けて各担当チームは各フェーズ(設計・テストフェーズ)に移行します。

このように各フェーズを一つずつ着実にこなしてから次フェーズに移行していく必要が無く、同時並行で各担当フェーズを進めていくことが出来ます。
また不足部分は各担当チームと柔軟に連携して改良していくことが出来るので、正確性に加えて俊敏性も実現出来る点が特徴です。

 

ソフトウェアロードバランサーでアジャイル実現

ハードウェアロードバランサーではスペックが固定されており、柔軟にスケールアウトかつスケールアップが行えず、高トラフィック時はネットワーク運用チームとの連携が必要となり、
設定変更時のトラフィックの影響範囲の調査や場合によってルール変更も必要です。そのため、設定変更の際も数時間から数日掛かるケースがあります。

しかし、ソフトウェアロードバランサーではハードウェアに依存しませんので、柔軟にスケールアウトかつスケールアップが行えるため、各チームが機敏に運用を行うことが可能となります。
またDevOpsで完結出来るため、ネットワーク運用チームとの連携は不要となり、運用者は設定変更を行う場合にも数秒で設定変更が行えます。

ソフトウェアロードバランサー としてのNGINX 

ソフトウェアロードバランサーの中でもNGINXはスケールアウト・スケールアップといったスケーラビリティに優れている以外にも、性能面でも優れています。
基盤も高スペックのものでなくても、パフォーマンスを発揮します。(2CPU core / 4GB RAMで90,000RPS 4,000 RSA SSL TPS  4,500 ECC SSL TPS 1GB スループットを実現)

ですので、トラフィック増加により無駄に運用変更を行う機会も無くなります。

下記詳細なサイジング・パフォーマンス例がございますのでご参考までに。

【サイジング・パフォーマンス例】
Sizing-Guide-for-Deploying-NGINX-on-Bare-Metal-Servers

またNGINX Plusではリアルタイムパフォーマンスモニター機能もGUIで搭載していますので、問題となっている点もすぐに解明出来、運用変更が可能です。

現在、ハードウェアロードバランサーを運用されている方は一度ソフトウェアロードバランサー NGINXを検討してみてはいかがでしょうか。
無料で評価版も30日間提供しておりますので、お気軽に下記ページからお問合せ下さい。

【評価版申請ページ】
https://nginx.sios.jp/free-trial

 

【参考URL】
https://www.nginx.com/blog/how-hardware-load-balancers-are-killing-agile-development-and-competitive-advantage/

nginx 1.15.4と1.15.5がリリースされました。

こんにちは、サイオステクノロジーの原です。

nginx.orgで2018年9月25日に1.15.4、2018年10月2日に1.15.5が公開されました。
今回のバージョンアップではSSL関連のディレクティブ機能拡充、ワーカープロセス・gRPC・error_pageディレクティブ関連のバグ修正が含まれています。

以下、リリース内容の詳細を参考訳として記載します。

nginx 1.15.4 リリース内容

<機能追加>
*)”ssl_early_data”ディレクティブでOpenSSLを使用可能。

<バグ修正>

*)ngx_http_uwsgi_moduleのバグ修正。Chris Caputoさん、ありがとう。

*)keepaliveディレクティブ文を使用すると、いくつかのgRPCバックエンドとの接続はキャッシュされない可能性があった。

*)”error_page”ディレクティブを使用して初期要求処理エラー(特にコード400のエラー)をリダイレクトすると、ソケットリークが発生することがあった

*)リクエストが “error_page”指示でリダイレクトされた場合、エラーを返すときに “return”ディレクティブ文は応答コードを変更しなかった。

*)標準エラーページとngx_http_autoindex_moduleモジュールの応答では、”bgcolor”属性が使用され、ブラウザでカスタムカラー設定を使用すると
   誤って表示されることがある。Nova DasSarmaさん、ありがとう。

<仕様変更>

*) “no suitable key share”および”no suitable signature algorithm”のSSLエラーのログレベルが「crit」から「info」に下げられました。

nginx 1.15.5 リリース内容

<バグ修正>

*)OpenSSL 1.1.0h以降を使用している場合、ワーカープロセスでセグメンテーションエラーが発生する可能性があった。バグは1.15.4でも発生していた。

*)潜在的なバグ修正。

 

【参考URL】

http://nginx.org/en/CHANGES

第1回 APIゲートウェイとしての NGINX Plusの導入

本ブログ記事は、NGINX,Inc.ブログ記事「Deploying NGINX Plus as an API Gateway, Part 1」を翻訳した内容になります。

URL:https://www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/

これは、NGINX PlusをAPIゲートウェイとしてデプロイする際の第1回のブログ記事です。

 

  • この記事では、いくつかのユースケースの詳細な設定手順を説明しています。
  • 第2回では、これらのユースケースを拡張し、プロダクションでのバックエンドAPIサービスを保護し、保護するために適用できる一連の保証措置に
    ついて検討します。

 

最新のアプリケーションアーキテクチャの中心には、HTTP APIがあります。HTTPを使用すると、アプリケーションを迅速に構築し、容易にメンテナンスすることができます。HTTP APIは、アプリケーションの規模にかかわらず、単一目的のマイクロサービスからすべてのモノリスまで、共通のインターフェイスを提供します。HTTPを使用することにより、ハイパースケールのインターネットプロパティをサポートするWebアプリケーションデリバリーの進歩を使用して、信頼性の高い高性能なAPIデリバリーを提供することもできます。

マイクロサービスアプリケーション用に優れたAPIゲートウェイの重要性の紹介については、ブログの「マイクロサービスの構築:APIゲートウェイの使用」を参照してください。

NGINX Plusは、ハイパフォーマンスの軽量リバースプロキシおよびロードバランサとして、APIトラフィックの処理に必要な高度なHTTP処理機能を備えています。これにより、NGINX PlusはAPIゲートウェイを構築するための理想的なプラットフォームとなります。このブログ記事では、一般的なAPIゲートウェイの使用例をいくつか紹介し、NGINX Plusを効率的でスケーラブル、かつ保守しやすい方法で設定する方法を示します。本番環境での基盤の完全な構成について説明します。

注記:注記のない限り、この記事のすべての情報は、NGINX PlusとNGINXコミュニティ版の両方に適用されます。

Warehouse APIの紹介

APIゲートウェイの主な機能は、バックエンドでの実装方法や展開方法に関係なく、複数のAPIに対して単一の一貫したエントリポイントを提供することです。すべてのAPIがマイクロサービスアプリケーションであるとは限りません。私たちのAPIゲートウェイは、既存のAPI、モノリス、およびマイクロサービスへ部分的に移行するアプリケーションを管理する必要があります。

このブログ記事では、在庫管理のための仮想API、「Warehouse API」を参照しています。サンプル構成コードを使用して、さまざまな使用例を示します。Warehouse APIは、JSONリクエストを消費し、JSONレスポンスを生成するRESTful APIです。しかし、JSONの使用は、APIゲートウェイとして配備された場合のNGINX Plusの制限または要件ではありません。NGINX Plusは、API自体が使用するアーキテクチャスタイルやデータフォーマットには無関心です。

Warehouse APIは、個別のマイクロサービスのコレクションとして実装され、単一のAPIとして公開されています。在庫と価格設定のリソースは、別々のサービスとして実装され、異なるバックエンドに配備されます。したがって、APIのパス構造は次のとおりです。

api
└── warehouse
   ├── inventory
   └── pricing

たとえば、現在の倉庫在庫を照会するために、クライアント・アプリケーションは/ api / warehouse / inventoryに対してHTTP GETリクエストを行います。

複数のアプリケーション用のAPIゲートウェイアーキテクチャ

NGINX設定の構成

APIゲートウェイとしてNGINX Plusを使用する利点の1つは、既存のHTTPトラフィックに対してリバースプロキシ、ロードバランサ、およびWebサーバーとして同時に機能することができることです。NGINX Plusが既にアプリケーションデリバリー・スタックに含まれている場合は、通常は別個のAPIゲートウェイを展開する必要はありません。ただし、APIゲートウェイで期待されるデフォルトの動作の一部は、ブラウザベースのトラフィックで期待される動作とは異なります。そのため、ブラウザベースのトラフィック用に既存の(または今後の)設定とAPIゲートウェイ設定を分離します。

この分離を実現するために、多目的NGINX Plusインスタンスをサポートする構成レイアウトを作成し、CI / CDパイプラインによる構成の展開を自動化するための便利な構造を提供します。/ etc / nginxのディレクトリ構造は次のようになります。

etc/
└── nginx/
   ├── api_conf.d/ ………………………………… Subdirectory for per-API configuration
   │ └── warehouse_api.conf …… Definition and policy of the Warehouse API
   ├── api_backends.conf ………………… The backend services (upstreams)
   ├── api_gateway.conf …………………… Top-level configuration for the API gateway server
   ├── api_json_errors.conf ………… HTTP error responses in JSON format
   ├── conf.d/
   │ ├── …
   │ └── existing_apps.conf
   └── nginx.conf

すべてのAPIゲートウェイ構成のディレクトリとファイル名の先頭にapi_が付きます。これらのファイルとディレクトリのそれぞれは、APIゲートウェイのさまざまな機能を有効にします。詳細については、後述します。

トップレベルAPIゲートウェイの定義

すべてのNGINX設定は、メイン設定ファイルnginx.confから始まります。APIゲートウェイ設定を読み込むために、nginx.confでhttpブロックのincludeディレクティブに、ゲートウェイ設定api_gateway.conf(直下の28行目)を含むファイルを参照するディレクティブを追加します。デフォルトのnginx.confファイルでは、conf.dサブディレクトリ(29行目)からブラウザベースのHTTP設定を引き出すためのディレクティブが使用されていることに注意してください。このブログ記事では、可読性を助け、構成の一部の自動化を可能にするために、includeディレクティブを幅広く使用しています。

 

  include /etc/nginx/api_gateway.conf; # All API gateway configuration

 

  include /etc/nginx/conf.d/*.conf;    # Regular web traffic

view rawnginx.conf hosted with ❤ by GitHub

api_gateway.confのファイルがクライアントにAPIゲートウェイとしてnginxのプラスを公開する仮想サーバーを定義します。この構成では、APIゲートウェイによって公開されたすべてのAPIが、16〜21 行目に設定されたTLSによって保護されたhttps://api.example.com/(行13)の単一エントリポイントに公開されます。この構成は純粋にHTTPS – 平文のHTTPリスナーはありません。APIクライアントは、デフォルトで正しいエントリポイントを知り、HTTPS接続を行うことが期待されます。

 

log_format api_main $remote_addr$remote_user [$time_local] “$request“‘

 

                  $status $body_bytes_sent$http_referer” “$http_user_agent“‘

 

                  ‘”$http_x_forwarded_for” “$api_name“‘;

 

 

include api_backends.conf;

 

include api_keys.conf;

 

 

server {

 

  set $api_name -; # Start with an undefined API name, each API will update this value

 

  access_log /var/log/nginx/api_access.log api_main; # Each API may also log to a separate file

 

 

  listen 443 ssl;

 

  server_name api.example.com;

 

 

  # TLS config

 

  ssl_certificate      /etc/ssl/certs/api.example.com.crt;

 

  ssl_certificate_key  /etc/ssl/private/api.example.com.key;

 

  ssl_session_cache    shared:SSL:10m;

 

  ssl_session_timeout  5m;

 

  ssl_ciphers          HIGH:!aNULL:!MD5;

 

  ssl_protocols        TLSv1.1 TLSv1.2;

 

 

  # API definitions, one per file

 

  include api_conf.d/*.conf;

 

 

  # Error responses

 

  error_page 404 = @400;         # Invalid paths are treated as bad requests

 

  proxy_intercept_errors on;     # Do not send backend errors to the client

 

  include api_json_errors.conf;  # API client friendly JSON error responses

 

  default_type application/json; # If no content-type then assume JSON

 

}

view rawapi_gateway.conf hosted with ❤ by GitHub

この設定は、静的なものです。個々のAPIとそのバックエンドサービスの詳細は24行目のincludeディレクティブで参照されているファイルで指定されています。
27行目から30行目では、ロギングのデフォルトとエラー処理について説明しています。以下の「エラーへの対処」を参照して下さい。

シングルサービスvs.マイクロサービスAPIバックエンド

いくつかのAPIは、単一のバックエンドで実装されるかもしれませんが、反復性や負荷分散の理由から、複数のAPIが存在することが通常想定されています。マイクロサービスAPIを使用して、各サービスごとで個別にバックエンドを定義します。一緒になって完全なAPIとして機能します。ここでは、Warehouse APIは複数のバックエンドを持つ2つのサービスとして展開されています。

 

upstream warehouse_inventory {

 

  zone inventory_service 64k;

 

  server 10.0.0.1:80;

 

  server 10.0.0.2:80;

 

  server 10.0.0.3:80;

 

}

 

 

upstream warehouse_pricing {

 

  zone pricing_service 64k;

 

  server 10.0.0.7:80;

 

  server 10.0.0.8:80;

 

  server 10.0.0.9:80;

 

}

view rawapi_backends.conf hosted with ❤ by GitHub

APIゲートウェイによって公開されたすべてのバックエンドAPIサービスは、すべてapi_backends.confで定義されています。ここでは、各upstreamブロックに複数のIPアドレスとポートのペアを使用して、APIコードの配置場所を示しますが、ホスト名も使用できます。NGINX Plusの加入者は、ダイナミックDNSロードバランシングを利用して、新しいバックエンドを自動的に実行時設定に追加することもできます。

Warehouse APIの定義

構成のこの部分は、まずWarehouse APIの有効なURIを定義し、Warehouse APIへのリクエストを処理するための共通ポリシーを定義します。

 

# API definition

 

#

 

location /api/warehouse/inventory {

 

  set $upstream warehouse_inventory;

 

  rewrite ^ /_warehouse last;

 

}

 

 

location /api/warehouse/pricing {

 

  set $upstream warehouse_pricing;

 

  rewrite ^ /_warehouse last;

 

}

 

 

# Policy section

 

#

 

location = /_warehouse {

 

  internal;

 

  set $api_name “Warehouse”;

 

 

  # Policy configuration here (authentication, rate limiting, logging, more…)

 

 

  proxy_pass http://$upstream$request_uri;

 

}

view rawwarehouse_api_simple.conf hosted with ❤ by GitHub

Warehouse APIは、いくつかのlocationブロックで定義されています。NGINX Plusには、リクエストURIと設定のセクションを照合するための、効率的で柔軟なシステムがあります。一般的に、リクエストは最も特定のパス接頭辞によって照合され、locationディレクティブの順序は重要ではありません。ここでは3行目と8行目に2つのパス接頭辞を定義しています。それぞれの場合、$upstream変数はupstream、インベントリサービスとプライシングサービスのバックエンドAPIサービスを表すブロックの名前にそれぞれ設定されます。

この構成の目的は、APIの定義方法と、APIの配布方法を規定するポリシーを分離することです。これを実現するため、API定義セクションに表示される設定を最小限に抑えます。各地域の適切なupstreamグループを決定した後、処理を停止、rewriteし、APIのポリシーを見つけるためにディレクティブを使用します(10行目)。

   rewriteディレクティブを使用して処理をAPIポリシーセクションに移動

このrewriteディレクティブの結果、NGINX Plusは/ _warehouseでlocation始まるURIに一致するブロックを検索します。15行目のlocationブロックは修飾子を使用して完全一致を実行し、処理を高速化します。

この段階で、私たちのポリシーセクションは非常にシンプルです。locationブロック自体は、16行目のinternalとしてマークされています。つまり、クライアントが直接リクエストを行うことはできません。$api_name変数は、それがログファイルに正しく表示されるように、APIの名前と一致するように再定義されます。最後に、リクエストは$request_uri、変更されていない元のリクエストURIを含む変数を使用して、API定義セクションで指定されたupstreamグループにプロキシされます。

APIの広範な選択と正確な定義の選択

API定義には、広範かつ正確な2つのアプローチがあります。各APIの最も適切なアプローチは、APIのセキュリティ要件と、バックエンドサービスが無効なURIを処理することが望ましいかどうかによって異なります。

warehouse_api_simple.conf、私たちは、これはどちらかの接頭辞で始まるURIは、適切なバックエンドサービスにプロキシされていることを意味ライン3および8にURIプレフィックスを定義することにより、倉庫APIのための幅広いアプローチを使用します。プレフィックスベースの位置一致では、次のURIへのAPI要求はすべて有効です。

/api /warehouse/inventory

/api/warehouse/inventory/

/api/warehouse/inventory/foo

/api/warehouse/inventoryfoo/bar

/api/warehouse/inventoryfoo/bar/

唯一の考慮点が正しいバックエンドサービスに対する各リクエストのプロキシである場合、幅広いアプローチは最も速い処理と最もコンパクトな構成を提供します。一方、正確なアプローチでは、使用可能な各APIリソースのURIパスを明示的に定義することによって、APIゲートウェイがAPIの完全なURIスペースを理解できるようになります。厳密なアプローチをとって、Warehouse APIの次の構成では、完全一致(=)と正規表現(~)を組み合わせて各URIを定義しています。

 

location = /api/warehouse/inventory { # Complete inventory

 

  set $upstream inventory_service;

 

  rewrite ^ /_warehouse last;

 

}

 

 

location ~ ^/api/warehouse/inventory/shelf/[^/]*$ { # Shelf inventory

 

  set $upstream inventory_service;

 

  rewrite ^ /_warehouse last;

 

}

 

 

location ~ ^/api/warehouse/inventory/shelf/[^/]*/box/[^/]*$ { # Box on shelf

 

  set $upstream inventory_service;

 

  rewrite ^ /_warehouse last;

 

}

 

 

location ~ ^/api/warehouse/pricing/[^/]*$ { # Price for specific item

 

  set $upstream pricing_service;

 

  rewrite ^ /_warehouse last;

 

}

view rawwarehouse_api_precise.conf hosted with ❤ by GitHub

この構成はより冗長性が担保された構成ですが、バックエンドサービスによって実装されるリソースをより正確に記述します。これには、不正なクライアントリクエストからバックエンドサービスを保護するという利点がありますが、正規表現マッチングのための追加のオーバーヘッドはわずかです。NGINX Plusは、この設定を使用すると、いくつかのURIを受け入れ、他のものを無効として拒否します。

有効なURI

 

無効なURI

/api/warehouse/inventory

 

/api/warehouse/inventory/

/api/warehouse/inventory/shelf/foo

 

/api/warehouse/inventoryfoo

/api/warehouse/inventory/shelf/foo/bbox/bar

 

/api/warehouse/inventory/shelf

/api/warehouse/inventory/shelf/ – /box/ –

 

/api/warehouse/inventory/shelf/foo/ bar

/api/warehouse/pricing/baz

 

/api/warehouse/pricing

   

/api/warehouse/pricing/baz/pub

正確なAPI定義を使用すると、既存のAPIドキュメント形式を使用してAPIゲートウェイの構成を実行できます。OpenAPI仕様(旧Swagger)からNGINX Plus API定義を自動化することが可能です。この目的のためのサンプルスクリプトは、このブログ記事のGistsに提供されています。

クライアントリクエストの書き換え

APIが進化するにつれて、クライアントの更新が急に必要になること起こります。このような例の1つは、APIリソースの名前が変更または移動された場合です。Webブラウザとは異なり、APIゲートウェイはクライアント301に新しい場所の名前を付けたリダイレクト(コード)を送信することはできません。幸いにも、APIクライアントを変更することは現実的ではない場合、クライアントリクエストを即座に書き直すことができます。

次の例では、3行目で、以前に価格設定サービスがインベントリサービスの一部として実装されていたことがわかります。このrewriteディレクティブは、古い価格設定リソースへのリクエストを新しい価格設定サービスに変換します。

 

# Rewrite rules

 

#

 

rewrite ^/api/warehouse/inventory/item/price/(.*) /api/warehouse/pricing/$1;

 

 

# API definition

 

#

 

location /api/warehouse/inventory {

 

  set $upstream inventory_service;

 

  rewrite ^(.*)$ /_warehouse$1 last;

 

}

 

 

location /api/warehouse/pricing {

 

  set $upstream pricing_service;

 

  rewrite ^(.*)$ /_warehouse$1 last;

 

}

 

 

# Policy section

 

#

 

location /_warehouse {

 

  internal;

 

  set $api_name “Warehouse”;

 

 

  # Policy configuration here (authentication, rate limiting, logging, more…)

 

 

  rewrite ^/_warehouse/(.*)$ /$1 break; # Remove /_warehouse prefix

 

  proxy_pass http://$upstream;          # Proxy the rewritten URI

 

}

view rawwarehouse_api_rewrites.conf hosted with ❤ by GitHub

途中でURIを書き直すということは、$request_uri最終的に26行目のリクエストをプロキシするときに変数を使用できなくなることを意味します(warehouse_api_simple.confの 21行目で行ったように)。これはrewrite、ポリシーセクションへのスイッチを処理するURIを保持するために、API定義セクションの9行目と14行目でわずかに異なるディレクティブを使用する必要があることを意味します。

rewriteディレクティブを使用してURIを保持しながらAPIポリシーセクションに処理を移行

エラーへの対応

HTTP APIとブラウザベースのトラフィックの主な違いの1つは、エラーがクライアントに伝達される方法です。NGINX PlusをAPIゲートウェイとして導入すると、APIクライアントに最適な方法でエラーを返すように設定されます。

最上位のAPIゲートウェイ構成には、エラー応答の処理方法を定義するセクションが含まれています。

 

  # Error responses

 

  error_page 404 = @400;         # Invalid paths are treated as bad requests

 

  proxy_intercept_errors on;     # Do not send backend errors to the client

 

  include api_json_errors.conf;  # API client friendly JSON error responses

 

  default_type application/json; # If no content-type then assume JSON

view rawapi_gateway.conf hosted with ❤ by GitHub

27行目のerror_pageディレクティブは、リクエストがいずれのAPI定義とも一致しない場合、NGINX Plusはデフォルト404(Not Found)エラーの代わりに400Bad Request)エラーを返します。この(オプションの)動作では、APIクライアントがAPIドキュメントに含まれている有効なURIのみにリクエストを行い、APIゲートウェイ経由で公開されたAPIのURI構造を不正なクライアントが検出できないようにする必要があります。

28行目は、バックエンドサービス自体によって生成されるエラーを指します。未処理の例外には、スタックトレースや、クライアントに送信したくないその他の機密データが含まれる場合があります。この構成では、標準化されたエラーをクライアントに送信することにより、さらに高度な保護が追加されます。

エラーレスポンスの完全なリストは29行目のincludeディレクティブで参照される別の設定ファイルに定義されています。このファイルは、異なるエラー形式が推奨され、30行目のdefault_type値を一致させるように変更することで変更できます。また、各APIのポリシー・セクションに別々のincludeディレクティブを組み、デフォルトをオーバーライドする異なるエラー応答のセットを定義することもできます。

 

error_page 400 = @400;

 

location @400 { return 400 ‘{“status”:400,”message”:”Bad request”}\n’; }

 

 

error_page 401 = @401;

 

location @401 { return 401 ‘{“status”:401,”message”:”Unauthorized”}\n’; }

 

 

error_page 403 = @403;

 

location @403 { return 403 ‘{“status”:403,”message”:”Forbidden”}\n’; }

 

 

error_page 404 = @404;

 

location @404 { return 404 ‘{“status”:404,”message”:”Resource not found”}\n’; }

view rawapi_json_errors.conf hosted with ❤ by GitHub

この設定を有効にすると、無効なURIに対するクライアントのリクエストは次の
レスポンスを受け取ります。

$ curl -i https://api.example.com/foo
HTTP/1.1 400 Bad Request
Server: nginx/1.13.10
Content-Type: application/json
Content-Length: 39
Connection: keep-alive

{“status”:400,”message”:”Bad request”}

認証の実装

APIを保護するための何らかの形式の認証なしでAPIを公開することは危険です。NGINX Plusには、APIを保護し、APIクライアントを認証するためのいくつかの方法があります。IPアドレスベースのアクセス制御リスト(ACL)、デジタル証明書認証、およびHTTP基本認証については、ドキュメントを参照してください。ここでは、API固有の認証方法に焦点を当てます。

APIキー認証

APIキーは、クライアントとAPIゲートウェイによって認識される共有秘密です。基本的に、長期クレデンシャルとしてAPIクライアントに発行される長くて複雑なパスワードです。APIキーの作成は簡単です。この例のように乱数をエンコードするだけです。

$ openssl rand -base64 18
7B5zIqmRGXmrJTFmKa99vcit

最上位のAPIゲートウェイ設定ファイルapi_gateway.confの 6行目には、api_keys.confというファイルが含まれています。api_keys.confには、各APIクライアントのAPIキーが含まれており、クライアント名やその他の説明で識別されます。

 

map $http_apikey $api_client_name {

 

 default “”;

 

 

  “7B5zIqmRGXmrJTFmKa99vcit” “client_one”;

 

  “QzVV6y1EmQFbbxOfRCwyJs35” “client_two”;

 

  “mGcjH8Fv6U9y3BVF9H3Ypb9T” “client_six”;

 

}

view rawapi_keys.conf hosted with ❤ by GitHub

APIキーはmapブロック内で定義されています。このmapディレクティブには2つのパラメータがあります。1番目のものは、APIキーをどこで見つけるかを定義しています。この場合apikeyは、$http_apikey変数に取り込まれたクライアントリクエストのHTTPヘッダーにあります。2番目のパラメータは新しい変数($api_client_name)を作成し、1番目のパラメータがキーと一致する行の2番目のパラメータの値に設定します。

たとえば、クライアントがAPIキー7B5zIqmRGXmrJTFmKa99vcitを提示すると、$ api_client_name変数はclient_oneに設定されます。この変数を使用して、認証されたクライアントをチェックし、より詳細な監査を行うためにログエントリに含めることができます。

mapブロックのフォーマットは、既存の資格証明ストアからapi_keys.confファイルを生成する自動化ワークフローに簡単に統合できます。APIキー認証は、各APIのポリシーセクションによって適用されます。

 

# Policy section

 

#

 

location = /_warehouse {

 

  internal;

 

  set $api_name “Warehouse”;

 

 

  if ($http_apikey = “”) {

 

      return 401; # Unauthorized (please authenticate)

 

  }

 

  if ($api_client_name = “”) {

 

      return 403; # Forbidden (invalid API key)

 

  }

 

 

  proxy_pass http://$upstream$request_uri;

 

}

view rawwarehouse_api_apikeys.conf hosted with ❤ by GitHub

クライアントは、apikeyHTTPヘッダーにAPIキーを提示する必要があります。このヘッダーが無いか空である場合(20行目)、401認証が必要であることをクライアントに伝えるレスポンスを送信します。23行目は、APIキーがmapブロック内のいずれのキーとも一致しない場合に処理します。この場合、api_keys.confの 2行目のパラメータ$api_client_nameは空の文字列に設定され、クライアントに認証に失敗した旨の403レスポンスを送信します。

この構成を使用すると、Warehouse APIはAPIキー認証を実装するようになりました。

$ curl https://api.example.com/api/warehouse/pricing/item001
{“status”:401,”message”:”Unauthorized”}
$ curl -H “apikey: thisIsInvalid” https://api.example.com/api/warehouse/pricing/item001
{“status”:403,”message”:”Forbidden”}
$ curl -H “apikey: 7B5zIqmRGXmrJTFmKa99vcit” https://api.example.com/api/warehouse/pricing/item001
{“sku”:”item001″,”price”:179.99}

JWT認証

JSON Webトークン(JWT)はますますAPI認証に使用されています。Native JWTサポートはNGINX Plus専用で、JWTを使用したAPIクライアントの認証とブログでNGINX Plusで説明されているようにJWTの検証が可能です。サンプルの実装については、第2部の「特定のメソッドへのアクセスの制御」を参照してください。

概要

一連の最初のブログでは、NGINX PlusをAPIゲートウェイとして導入するための完全なソリューションについて詳しく説明しています。このブログで解説されているファイルの完全なセットは、GitHub Gistレポから見直してダウンロードできます。

このシリーズの他の記事をチェックしてください:

  • 第2部では、悪意のあるクライアントや不正なクライアントからバックエンドサービスを保護するための高度なユースケースについて説明します。

NGINX PlusをAPIゲートウェイとして試してみるには、今すぐ無料の30日間のトライアルを開始するか、私たちにご連絡ください

Kubernetesによる負荷分散のための コミュニティ版NGINXおよびNGINX Plus Ingress Controller

この記事はNGINX,Inc.のブログ記事「NGINX and NGINX Plus Ingress Controllers for Kubernetes Load Balancing」を和訳した内容となります。

URL: https://www.nginx.com/blog/nginx-plus-ingress-controller-kubernetes-load-balancing/

マシンのクラスタ全体で、コンテナ内のマイクロサービスアプリケーションを実行して管理することは、困難な作業です。Kubernetesは、コンテナオーケストレーションのための強力なソリューションを提供することで、チャレンジを達成するのに役立ちます。フォールトトレランス、自動スケーリング、ローリングアップデート、ストレージ、サービスディスカバリ、ロードバランシングなどのいくつかの重要な機能が含まれています。

このブログ記事では、コミュニティ版NGINXまたはNGINX PlusIngressの使い方について説明します。Ingressは、HTTPトラフィック用のKubernetesロードバランシングフレームワークを内蔵しています。Ingressでは、Kubernetesクラスタ内のサービスへの外部トラフィックのルーティングを制御するルールを設定できます。Ingress Controllerは、クラスタに展開しKubernetesとロードバランサを統合するソフトウェアで、任意のロードバランサを選択できます。ここでは、Ingressを備えたマイクロサービスアプリケーションと、NGINX PlusおよびNGINX用で提供されているIngress Controllerのロードバランシングを設定する方法を説明します。

[編集者 – 以前はNGINXとNGINX Plus用に別々のControllerがありましたが、
現在両方のIngress Controllerに統合しました。]

このブログ記事では、KubernetesとIngressのHTTPロードバランシングのみを調査します。他のロードバランシングオプションの詳細については、ブログでLoad Balancing Kubernetes Services with NGINX Plusを参照してください。

注:このブログ記事で説明されている手順の詳細は、GitHubリポジトリを参照してください。この投稿はすべての必要なステップを追うものではなく、それらの指示へのリンクを提供します。

コミュニティ版NGINXおよびNGINX PlusのIngress Controllers

サンプルアプリケーションをデプロイしてロードバランシングを設定する前に、ロードバランサを選択し、対応するIngress Controllerをデプロイする必要があります。

Ingress Controllerは、特定のロードバランサとKubernetesを統合するソフトウェアです。私たちはコミュニティ版NGINXとNGINX Plusの両方のIngress Controllerを開発しました。GitHub リポジトリで利用できます。他にはサードパーティ製のものもあります。詳細については、KubernetesのGitHubリポジトリのIngress Controllersページを参照してください。

クラスタにNGINXまたはNGINX Plus Ingress Controllerを導入する方法の詳細については、GitHubリポジトリを参照してください。

サンプルマイクロサービスアプリケーション

サンプルアプリケーションは、それぞれが別々にデプロイされた複数のサービスで構成された典型的なマイクロサービス Webアプリケーションです。cafeと呼ばれるこのアプリケーションは、coffeeサービスを通じてteacoffeeを注文することができます。飲み物の好みをHTTPリクエストのURIで指定します。/ teaで終わるURIは、/ coffeeで終わるteaとURIで終わります。またアプリケーションへの接続はSSL / TLSで保護する必要があります。

以下の図は、NGINX Plusロードバランサがクライアントのリクエストを適切なサービスにルーティングする重要な役割を担い、SSL / TLSによるクライアント接続のセキュリティを確保しながら、アプリケーションを概念的に示しています。

クラスタにアプリケーションをデプロイするには、GitHubリポジトリの指示に従います。

IngressによるKubernetesロードバランシングの設定

私たちのcafeアプリでは、2つの機能を提供するためにロードバランサが必要です。

  • 要求URIに基づくルーティングパスベースルーティングとも呼ばれる)
  • SSL / TLSターミネーション

Ingressでロードバランシングを設定するには、Ingressリソースでルールを定義します。ルールは、外部トラフィックをクラスタ内のサービスにルーティングする方法を指定します。

リソースでは、それぞれ異なるドメイン名の複数の仮想サーバーを定義できます。仮想サーバーは、通常クラスタに展開された単一のマイクロサービスアプリケーションに対応しています。各サーバーについて、次のことができます。

  • 複数のパスベースのルールを指定します。リクエストURIに基づいて、
    アプリケーション内の異なるサービスにトラフィックが送信されます。
  • SSL / TLS証明書と鍵を参照してSSL / TLS終了を設定します。

Ingressの詳細については、Ingressのドキュメントページをご覧ください

cafeアプリ(cafe-ingress.yaml)のIngressリソースは次のとおりです。

1. apiVersion: extensions/v1beta1
2. kind: Ingress
3. metadata:
4.  name: cafe-ingress
5. spec:
6.  tls:
7.  – hosts:
8.    – cafe.example.com
9.    secretName: cafe-secret
10.  rules:
11.  – host: cafe.example.com
12.    http:
13.      paths:
14.      – path: /tea
15.        backend:
16.          serviceName: tea-svc
17.          servicePort: 80
18.      – path: /coffee
19.        backend:
20.          serviceName: coffee-svc
21.          servicePort: 80

行ごとに調べると、次のようになります。

  • 4行目では、リソースのcafe-ingressの名前を付けます。
  • 6-9行目で、SSL / TLS終了を設定します。
    • 9行目では、Secretリソースをその名前cafe-secretで参照しています。このリソースにはSSL / TLS証明書とキーが含まれており、Ingressリソースの前に展開する必要があります。
    • 8行目で証明書とキーをcafe.example.com仮想サーバーに適用します。
  • 11行目では、ドメイン名cafe.example.comを持つ仮想サーバーを定義します。
  • 13行目から21行目では、2つのパスベースのルールを定義しています。
    • 14-17行目で定義されているルールは、tea-svcという名前でデプロイされている、Tea Serviceのコンテナに/ tea URI とともにリクエストを分散するようにロードバランサに指示します。
    • 18行目〜21行目で定義されているルールは、クラスタ内にcoffee-svcという名前でデプロイされているCoffee Service
      コンテナに、/ coffee URI とともにリクエストを分散するようロードバランサに指示します。
    • どちらのルールも、対応するサービスのポート80に要求を分散するようにロードバランサに指示します。

IngressおよびSecretリソースをクラスタに導入する方法の詳細については、GitHubリポジトリを参照してください。

アプリケーションのテスト

NGINX Plus Ingress Controller、アプリケーション、Ingressリソース、およびSecretリソースを導入すると、アプリケーションをテストできます。

/ tea URIでteaをリクエストすると、ブラウザーにはTea Serviceによって生成されたページが表示されます。

teacoffeeのサービスが実際に飲み物を提供するだけではなく、これらサービスを
起動してコンテナやあなたのリクエストの詳細についての情報が欠損していないことが望ましいです。これらには、コンテナのホスト名とIPアドレス、要求URI、およびクライアントのIPアドレスが含まれます。ページを更新するたびに、別のコンテナから応答が返されます。

また、NGINX Plus ライブアクティビティモニタリングダッシュボードに接続して、NGINX Plusとアプリケーションの各コンテナからのリアルタイム負荷分散メトリックを参照することもできます。

Ingress Controllerの拡張

Ingressは、基本的なHTTPロードバランシング機能を提供します。ただし、アプリケーションのロードバランシング要件が複雑でIngressでサポートされていないことがよくあります。これらの要件の一部に対応するため、Ingressコントローラにいくつかの拡張機能を追加しました。このようにして、Kubernetesリソースを使用してロードバランサを構成すること(ロードバランサを直接構成するのではなく)もでき、かつ高度なロードバランシング機能を活用することもできます。

利用可能な拡張機能の完全なリストについては、GitHubリポジトリを参照してください。

さらに、Kubernetesのリソースを使用してConfig Mapsリソースまたは注釈を使用してNGINX設定カスタマイズするメカニズムを提供します。たとえば、proxy_connect_timeoutまたはproxy_read_timeoutディレクティブの値をカスタマイズすることができます。

ロードバランシングの要件がIngressおよび拡張機能でサポートされている要件がある場合は、Ingressコントローラを使用しないNGINX Plusをデプロイおよび設定するための方法を提案します。私たちのブログではNGINX Plusを使ってKubernetesサービスのロードバランシングを読むことができます。

ControllerによるNGINX Plusの利点

NGINX Plus Ingress ControllerはNGINXで得られるものに加えて、以下の利点を提供します。

  • 高度に動的な環境での安定性  – Ingressを介して公開されているサービスのPod数が変更されるたびに、Ingress Controllerは変更を反映するためにNGINXまたはNGINX Plusの設定を更新する必要があります。コミュニティ版のNGINXでは、設定ファイルを手動で変更して設定をリロードする必要があります。しかし、NGINX Plusを使用すると、オンザフライで再構成 APIを使用して、設定ファイルをリロードせずに設定を更新できます。これにより、構成リロードが頻繁に発生する場合に発生する可能性のあるメモリ使用量の増加やシステム全体のオーバーロードを防ぐことができます。
  • リアルタイム統計  – NGINX Plusは高度なリアルタイム統計を提供し、APIまたは内蔵ダッシュボードのいずれかにアクセスできます。これにより、NGINX Plusとアプリケーションがどのように実行されているかを知ることができます。
  • セッション・パーシステンス  – セッション・パーシステンスを有効にすると、NGINX Plusは同じクライアントからのすべての要求が常にスティッキクッキー方式を使用して同じバックエンドのコンテナに渡されるようにします。

概要

Kubernetesには、組み込みのHTTPロードバランシング機能があり、外部トラフィックをIngressでクラスタ内のサービスにルーティングします。コミュニティ版NGINXとNGINX Plusは、Kubernetesロードバランシングと統合され、Ingress機能を完全にサポートし、拡張ロードバランシング要件をサポートする拡張機能も提供します。

NGINX PlusとIngress Controllerを試すには、今すぐ無料の30日間のトライアル
開始するか、ライブデモをご連絡ください

***************************************************************************

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper

***************************************************************************

nginx 1.15.2リリース

2018年7月24日にコミュニティ版ホームページ(nginx.org)で1.15.2が公開されました。

以下にリリース内容の参考訳を記載します。

nginx 1.15.2 リリース内容

<機能追加>
1.ngx_stream_ssl_preread_module.に$ssl_preread_protocol変数が追加されました。

2.”reset_timeout_connection”ディレクティブを使用した時、nginxの接続は444コードでリセット
  することが可能です。

<仕様変更>
1.”httpリクエスト”、”httpsプロキシリクエスト”、”サポートされていないプロトコル”、
  ”バージョンが低い” SSLエラーのログレベルが “crit”から “info”に下げられました。

<バグ修正>
1.最初のリクエスト送信が失敗した場合、DNSリクエストは再送信されませんでした。

2. “listen”ディレクティブの後にワーカープロセスの数が指定された場合、 “listen”ディレクティブの “reuseport”パラメータは無視されてました。

3.OpenSSL 1.1.0以降を使用している場合、仮想サーバがデフォルトサーバで有効になっている場合、仮想サーバの「ssl_prefer_server_ciphers」をオフにすることはできませんでした。

4.アップストリームサーバーとのSSLセッションの再利用は、TLS 1.3プロトコルでは機能しませんでした。

*) Feature: the $ssl_preread_protocol variable in the ngx_stream_ssl_preread_module.
*) Feature: now when using the “reset_timedout_connection” directive nginx will reset connections being closed with the 444 code.
*) Change: a logging level of the “http request”, “https proxy request”, “unsupported protocol”, and “version too low” SSL errors has been lowered from “crit” to “info”.
*) Bugfix: DNS requests were not resent if initial sending of a request failed.
*) Bugfix: the “reuseport” parameter of the “listen” directive was ignored if the number of worker processes was specified after the “listen” directive.
*) Bugfix: when using OpenSSL 1.1.0 or newer it was not possible to switch off “ssl_prefer_server_ciphers” in a virtual server if it was switched on in the default server.
*) Bugfix: SSL session reuse with upstream servers did not work with the TLS 1.3 protocol.

 

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper

OpenShift Container Platform 3.10用のNGINXおよびNGINX Plusルーターの紹介

この記事はNGINX,Inc.のブログ記事「Introducing NGINX and NGINX Plus Routers for OpenShift」を和訳した内容となります。

URL: https://www.nginx.com/blog/introducing-nginx-and-nginx-plus-routers-for-openshift/

 

Red Hat OpenShiftは、主要なコンテナオーケストレーションおよび管理システムであるKubernetesの上に構築されたコンテナプラットフォームです。OpenShiftは、オープンソースプロジェクト、OpenShift Origin、および市販の製品であるOpenShift Container Platformとして利用できます。

OpenShift Container Platform 3.10の今後のリリースでは、プロダクションOpenShiftクラスタへのトラフィックを最適化するルータとして、高度な機能と完全な商用サポートを備えたソフトウェアロードバランサNGINX Plusを利用することができます。

OpenShiftは、開発者やオペレーター中心のツールをKubernetes上に追加し、セキュリティやその他統合された機能で拡張します。ルータと呼ばれるこれらの機能の1つは、OpenShiftにデプロイされたアプリケーションのエッジリクエストルーティングとロードバランシングを提供します。私たちはNGINXとNGINX PlusがOpenShiftプラットフォームと完全に統合され、それぞれがルーターとして使用できることを確認しています。

ルーターとは?

ルーターは、ルータープラットフォームの最も重要な部分の一つで、OpenShift上で実行しているアプリケーションの外部リクエストのためのエントリポイントとして機能します。ルーターの仕事は、特定のリクエストに対して適切なアプリケーションを特定し、そのアプリケーションのインスタンスにリクエストをルーティングすることです。したがって、ルーターはOpenShift上のアプリケーションにエッジ負荷分散を提供します。

ルーターは、HTTPとWebSocketトラフィックの負荷分散を行い、ルーターインスタンスとアプリケーションインスタンス間のTLSターミネーションおよびTLS接続をサポートします。さらに、ルーターはパススルーモードでTLS接続の負荷分散を行うことができます(復号化はしません)。OpenShiftには、ルーターを設定するためのRouteという特別なリソースが含まれています。

ルーターがダウンしたり正常に動作しない場合、クライアント側からアプリケーションが使用できなくなります。従って、これは、ルーターが実績のある信頼性の高い技術の上に構築されていることが不可欠であると分かります。

ルーターは、OpenShiftのプラグインが可能な部分です。つまり、OpenShiftユーザーは、要件と環境設定を満たすルーター実装を選択できます。

Kubernetes Ingressに関する注記: OpenShiftでも利用可能な組み込みのKubernetes Ingressリソースは、ルーターと同様のエッジロードバランシング機能を提供します。NGINXとNGINX Plusはどちらも、Kubernetes用のNGINX Ingress Controllerを使用してIngressリソースをサポートしています。Red Hatの現在の推奨事項として、IngressリソースはまだOpenShiftの技術プレビュー機能であり、標準のIngress機能はRouteリソースが提供するものに比べて限られているため、Routeリソースを使用することです。

NGINXおよびNGINX Plusルーター

NGINXはコンテナプラットフォームでの採用実績があり、Docker Hubからコンテナイメージを1000万回以上、Kubernnetes のIngressコントローラーを 100万回以上使用されています。私たちは、既存サービスからOpenShiftユーザーへ拡張して、我々の技術の上に構築されたルーター実装/提供されることを喜ばしく思っています。

ルーター実装の主な特長は次のとおりです。

  • Route仕様の完全サポート。NGINXルーターは、Routeリソースによって定義された機能を完全にサポートしています。
  • カスタマイズオプション。さまざまなカスタマイズオプションと追加の機能は、環境変数とRouteアノテーションを介して利用できます。これは、他のルーター実装における共通のアプローチです。
  • おなじみの運用経験。NGINX Routerは、デフォルトルーターの実装を支えるのと同じソフトウェアであるTemplate Routerソフトウェアを介してOpenShiftに統合されています。その結果、使い慣れた運用経験が得られ、デフォルトのルータ実装からの移行が容易になります。
  • NGINXのパフォーマンスと安定性。NGINXルーターを使用すると、NGINXソフトウェアの性能と信頼性を得ることができます。
  • 最新のnginxの特徴。gRPCロードバランシングのネイティブサポートなどの新機能をOpenShift Routerでも発揮されることは非常に喜ばしいことです。新しい機能がNGINXおよびNGINX Plusで利用可能になると、それらをルーターの機能に組み込むことができます。
  • オープンソース。NGINXルーターの実装は、OpenShift Originリポジトリでホストされている完全オープンソースです。
  • 高度な機能。NGINX Plus Routerを使用すると、監視APIやダッシュボードなど、NGINX Plusの追加の利点が得られます。

どうやって始めるのか

NGINXルーターはOpenShift Container Platform 3.10に含まれており、OpenShift Originプロジェクトの最新ソースですでに利用可能です。NGINX Plus RouterはGitHub repoで別途ホストされています。

まず、NGINXルーターNGINX Plusルーターのインストール手順を参照してください。

概要

NGINXとNGINX Plus Routersは、信頼性、性能、および必要な機能をOpenShiftプラットフォームの中核コンポーネント、つまりルーターとして機能を発揮します。

OpenShift Container PlatformとOpenShift Originの両方でこのフル機能のソリューションの作成に携わってくれたRed Hatに感謝します。

***************************************************************************

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper

***************************************************************************

 

サービスメッシュとは?

この記事はNGINX,Inc.のブログ記事「What Is a Service Mesh?」を和訳した内容となります。

URL: https://www.nginx.com/blog/what-is-a-service-mesh/

サービスメッシュは 、マイクロサービスアプリケーションの構成ができるインフラストラクチャ層です。これにより、サービスインスタンス間の通信が柔軟で信頼性が高く、高速になります。このメッシュは、サービスのディスカバリ、ロードバランシング、暗号化、認証と認可、サーキットブレーカーパターンのサポート、およびその他の機能を提供します。

サービスメッシュは、通常、各サービスインスタンスに対して、サイドカーと呼ばれるプロキシインスタンスを提供して実装されます。サイドカーは、サービス間の通信、監視、セキュリティ関連の懸念(個々のサービスから抽象化できるもの)を処理します。このようにして、開発者はサービス内のアプリケーションコードの開発、サポート、メンテナンスを処理し、運用担当者はサービスメッシュを維持して、アプリケーションを実行できます。

Google、IBM、Lyftの支援を受けているIstioは、現在、最もよく知られているサービスメッシュアーキテクチャです。もともとGoogleによってデザインされたKubernetesは、現在Istioにサポートされている唯一のコンテナオーケストレーションフレームワークです。

サービスメッシュには、コンポーネントサービスと機能に関する独自の用語があります。

  • コンテナ オーケストレーション フレームワーク アプリケーションインフラに次々とコンテナが追加されるにつれ、一連のコンテナを監視および管理するための別のツールである、コンテナ オーケストレーション フレームワークが不可欠になります。Kubernetesは、この市場を独占したようです。主要な競合相手であるDocker SwarmやMesosphere DC / OSでさえ、Kubernetesとの統合を代案として提示しています。
  • サービスとサービスインスタンス  具体的に言うと、開発者が作成するのはサービスではなく、サービスインスタンスのサービス定義またはテンプレートです。アプリケーションはこれらからサービスインスタンスを作成し、インスタンスは実際の作業を行います。ただし、サービスという用語は、多くの場合、インスタンス定義とインスタンス自体の両方に使用されます。
  • サイドカープロキシ  サイドカープロキシは、特定のサービスインスタンス専用のプロキシインスタンスです。他のサイドカープロキシと通信し、オーケストレーションフレームワークによって管理されます。
  • サービス・ディスカバリ インスタンスが別のサービスとやりとりする必要がある場合、他のサービスの健全で利用可能なインスタンスを見つける必要があります。コンテナ管理フレームワークは、リクエストを受信する準備ができているインスタンスのリストを保持します。
  • ロードバランシング サービスメッシュでは、ロードバランシングは一番下から機能します。サービスメッシュが管理している利用可能なインスタンスは、順に並べてリスト化され、最も負荷の軽いインスタンス(ここが負荷分散部分になります)が一番上に配置されます。
  • 暗号化 サービスメッシュは、リクエストとレスポンスを暗号化および復号化し、各サービスからその負担を取り除くことができます。サービスメッシュは、既存のパーシステントコネクションの再利用に優先順位を付け、コンピューティングリソース的に高価となる新規の接続を作る必要性を低減することで、パフォーマンスを向上させることができます。
  • 認証と承認 サービスメッシュは、アプリケーションの外部と内部の両方から行われたリクエストを認証し、検証されたリクエストのみをサービスインスタンスに送信することができます。
  • サーキットブレーカーパターンのサポート サービスメッシュは、不健全なインスタンスを分離し、それらが保証された段階で、健全なインスタンスプールに徐々に戻していくサーキットブレーカーパターンをサポートします。

サービスインスタンス、サイドカープロキシ、それらの間の相互作用など、サービスメッシュで作業を実行している部分は、サービスメッシュアプ​​リケーションのデータプレーンと呼ばれます。(名前には含まれませんが、データプレーンも処理を実行します)。でも、サービスメッシュアプ​​リケーションには、コントロールプレーンと呼ばれる監視および管理レイヤーも含まれています。

コントロールプレーンは、新しいインスタンスの作成、不健全または不必要なインスタンスの終了、監視、監視と管理の統合、アプリケーション全体のポリシーの実装、およびアプリケーション全体の正常なシャットダウンなどのタスクを処理します。コントロールプレーンは、通常、アプリケーションプログラミングインタフェース、コマンドラインインタフェース、およびアプリケーションを管理するためのグラフィカルユーザインタフェースを含むか、またはそれらに接続するように設計されています。

nginMesh、コントロールプレーン、データプレーン、サイドカープロキシとしてのNGINXを含むIstioサービスメッシュ

 

NGINXには、nginMeshと呼ばれるIstio互換のサービスメッシュがあります。このnginMeshアーキテクチャの図は、典型的なIstioコンポーネントとともに、サイドカープロキシの役割を果たすNGINXを示しています。

サービスメッシュアーキテクチャの一般的な使用例は、コンテナとマイクロサービスを使用して非常に要求の厳しいアプリケーション開発の問題を解決する場合です。マイクロサービスの先駆者には、Lyft、Netflix、Twitterなどの企業があります。これらの企業は、1時間単位で出入りする世界中の何百万人ものユーザーに、堅牢なサービスを提供しています。(Netflixが直面しているいくつかのアーキテクチャ上の課題についての詳細な説明を参照してください)。アプリケーションのニーズがそれほど厳しくない場合、より単純なアーキテクチャで十分でしょう。

サービスメッシュ・アーキテクチャーが、すべてのアプリケーション開発およびデリバリーの問題に対する答えとなることはないでしょう。建築家や開発者は非常に多くのツールを持っていますが、ハンマーはそのうちの1つに過ぎず、彼らが対処しなければならないたくさんの問題の中で、釘もまたそのうちの1つにすぎないからです。たとえば、NGINX Microservices Reference Architectureには、マイクロサービスで問題を解決するために、連続的なアプローチを提供するいくつかの異なるモデルが含まれています。

サービスメッシュアーキテクチャ(NGINX、コンテナ、Kubernetes、構造的なアプローチとしてのマイクロサービスなど)に付随する要素は、非サービスメッシュ実装で生産的に使用できます。たとえば、サービスメッシュアーキテクチャとして開発されたIstioはモジュール式に設計されているため、開発者は必要なものを選択して使えます。サービスメッシュアプ​​リケーションをいつ、完全に実装するかどうかわからなくても、これを念頭に置いて、サービスメッシュの概念を確実に理解する価値はあります。

このブログの投稿は、シリーズの最初のものになります。現在、予定されている投稿は次のとおりです:

  1. サービスメッシュとは?ー  本投稿です。
  2. サービスメッシュアーキテクチャの利点と欠点 いつサービスメッシュが正解か、代替案がより良いかもしれないかを説明します。
  3. サービスメッシュとAPIゲートウェイ  APIゲートウェイが問題の大部分を解決しうる時、サービスメッシュに直ちに移行するべき時、およびそれらをミックスしたアプローチを使用する時を示します。
  4. KubernetesとService Meshアーキテクチャ サービスメッシュを含むさまざまなアーキテクチャでKubernetesを使用する方法について説明します。
  5. サービスメッシュアーキテクチャにおけるNGINXの使用 NGINXは、サービスメッシュ・アーキテクチャ(サイドカー・プロキシIngressコントローラ、またはその両方)の中で、ロードバランシング、サービス・ディスカバリ、キャッシングなどの機能を提供しながら、いくつかの重要な役割を果たします

***************************************************************************

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper

***************************************************************************

NGINXとNGINX Plusの高性能キャッシング

この記事はNGINX,Inc.のブログ記事「High‑Performance Caching with NGINX and NGINX Plus」を和訳した内容となります。

URL: https://www.nginx.com/blog/nginx-high-performance-caching/

この投稿はAndrew Alexeevに紹介されたOwen Garrettのウェビナーからのものです。

目次

はじめに

0:00 はじめに

1:22 このウェビナーについて

2:17 コンテンツキャッシングの基本原則

2:35 基本原則

3:59 HTTPキャッシュの仕組み

7:46 NGINXキャッシュとは何か?

 

コンテンツキャッシュとNGINX

9:55 NGINXの運用

10:06 NGINXの設定

11:14 キャッシングプセス

15:32 キャッシュはHTTPのためだけではありません

17:10 何が起こっているのか理解する方法

17:38 キャッシュ・インスツルメンテーション

19:08 キャッシュ・インスツルメンテーション(続き)

20:09 キャッシュステータス

21:57 コンテンツキャッシュがNGINXでどのように機能するか

22:40 どのように動作するか

23:53 キャッシュされたコンテンツはどのように保存されるか

26:36 ディスクからのキャッシュのロード

28:07 ディスクキャッシュの管理

29:22 ディスクからのコンテンツの除去

 

キャッシュの制御

31:27 キャッシュの制御

32:30 遅延キャッシング

34:45 キャッシュ時間の制御

36:18 キャッシュ/キャッシュしない

37:25 複数のキャッシュ

39:07 クイックレビュー – なぜキャッシュ?

39:44 Page Speedはなぜ重要か?

40:46 Googleがルールを変更した

41:28 パフォーマンス低下のコスト

43:00 NGINXキャッシングでできること

45:21 最後に

 

Q&A

47:20 Byte-Rangeリクエスト

49:13 プロキシキャッシュの再検証

50:07 等しいディスク間でキャッシュを分散する

50:50 Vary ヘッダ

51:25 キャッシングプリミティブ

51:52 アップストリームヘッダーとデータ

52:13 *-Encoding ヘッダー

52:56 SPDY

53:15 Vary ヘッダー、第2ラウンド

53:45 PageSpeed

54:00 その他のキャッシュ

 

0:00はじめに

Andrew Alexeev:最新のウェビナーへようこそ。私の名前はAndrewです。NGINXは世界のウェブサイトをより速く、反応良く、簡単に拡張できるようにするため、Igor Sysoevによって書かれました。今日、NGINXはトップサイトの30%以上、インターネット上の全ウェブサイトの20%以上を占めています。[ 編集注 – この統計は2014年5月にウェブセミナーが配信されたときのものです。現在の数値は、こちらを参照してください] このウェブセミナーの内容が皆さんのお役に立ち、既存、または新規計画中のNGINX環境に当てはまれば幸いです。

 

それでは、みなさんにOwen Garrettを紹介させてください。OwenはNGINXで製品開発を担当しています。今日、Owenは、NGINXの強力なキャッシュメカニズムを適用して、同じコンテンツを何度も繰り返し生成する負荷から、アプリケーションを解放する方法について説明します。

 

1:22このウェビナーについて

スライド内文章
コンテンツキャッシングは、ウェブサイトのパフォーマンスを劇的に改善する最も有効な方法の一つです。このウェビナーでは、NGINXのキャッシング性能と使われているアーキテクチャー、デバッグ技術や応用的な設定を詳しく見ていきます。ウェビナーが終わるまでには、ご自身のニーズに合わせてコンテンツをキャッシュするために、NGINXを設定する十分な知識を得られます。

 

Owen Garrett: Andrew、ありがとう。そして皆さん、これから45分から50分間、お付き合いいただきますが、ありがとうございます。これから、コンテンツキャッシュについて、NGINXの機能をお話しし、パフォーマンスを向上させる方法をいくつか見ていきます。NGINX内で何が起きているのかをデバッグして診断するために、コンテンツキャッシュが実際にどのように機能するかを少し詳しく説明します。そして、キャッシュ可能なコンテンツに対して、NGINXの処理を細かく制御するヒントやコツをまとめてお伝えします。

 

Andrewが言ったように、これらにはすべて、中心となる同じ目的があります。アップストリームサーバーから反復するコンテンツを生成する負荷を取り除き、ビジネスが本当に必要とするアプリケーションを実行できるようにする、というものです。インターネットからのトラフィックが急増し、潜在的には上流のサーバーに障害が発生するような状況に直面しても、エンドユーザーのサービスレベルを向上させ、サービス全体としての信頼性を向上させます。

 

2:17コンテンツキャッシングの基本原則

NGINXの実装設定に入る前に、皆さんが同じ地点、同じ基本的なコア情報からスタートできるよう、コンテンツキャッシュ機能の基本的な内容を素早くおさらいしておきたいと思います。

 

2:35基本原則

コンテンツキャッシングの基本原則は、アップストリームサーバーを反復作業から開放することです。第1のユーザーがWenサイト上のコンテンツ(青いアイコンと線で示されています)を要求すると、HTTPリクエストはNGINXに転送され、そこから右側に描かれている灰色のアップストリームサーバーに転送されます。

 

レスポンスはリモートユーザーに転送されますが、キャッシュ可能な場合は(この後、その意味についてはお話しします)、すぐにNGINXがそのレスポンスのコピーを保存します。オレンジ色の別のユーザーが同じコンテンツを要求すると、NGINXはアップストリームサーバーからリクエストを構成するのではなく、ローカルキャッシュから直接配信することができます。

 

キャッシュ可能で不変なコンテンツを保存するこの基本原則は、Webブラウザに、CDNを使ったみなさんがアクセスしているサイトに、そして他のデバイス上のNGINXによって使われています。これは、リバースプロキシキャッシュとして動作します。通常は、WebコンテンツやWebアプリケーションをホストしているオリジンサーバーの横のデータセンターやクラウドに展開されます。

 

3:59 HTTPキャッシュの仕組み

オリジンサーバーは、よく知られ、理解されているHTTPレスポンスヘッダーのうちの1つ以上を使用して、コンテンツのキャッシャビリティを宣言します。もちろん、サーバーをキャッシュすることで、この動作を無視したり、上書きしたり、変更したりすることができます。しかし、構成されたコンテンツキャッシングを理解するには、コンテンツがキャッシュ可能であり、かつ変更されておらず、キャッシュされたコピーが一定の存続期間持つことについて、オリジンサーバーで宣言する方法をよく理解する必要があります。

 

コンテンツのキャッシュは、Expiresと呼ばれる単純なHTTPレスポンスヘッダーで開始されました。オリジンサーバーは何らかのコンテンツを提示し、Expiresヘッダーの日付までコンテンツが有効であると宣言します。その方法は、より効果的で柔軟な方法であるCache-Controlヘッダーにすぐに取って代わりました。

 

Expiresは、やや使いにくく、非効率的です。日付は適切にフォーマットされ、解析される必要がありますが、Cache-Controlはコンテンツキャッシュのニーズとスピードに合わせてより合理化されています。Cache-Controlはコンテンツをpublicまたはprivateのいずれかと宣言し、publicの場合はmax-age 、つまりキャッシュオブジェクトがそのコンテンツを再要求する必要が生じるまでにキャッシュできる秒数を宣言します。

 

キャッシングを直接制御する3番目のヘッダーが、X-Accel-Expiresです。このヘッダーはNGINXにとって特別で、NGINXだけがそれを理解します。上記のヘッダーの動作を無効にし、コンテンツのアイテムがキャッシュされる期間を直接正確にNGINXに伝えたい場合に使用されます。

 

コンテンツをWebブラウザに長期間キャッシュさせたい場合があるかもしれませんが、プロキシキャッシュ(NGINXはオリジンサーバーの前に置かれています)がそれらを短時間でキャッシュして、変更がより迅速に反映されて新しいクライアントに届けられます。

一方古いクライアントは、不必要にコンテンツを再要求し続けることはありません。

 

ただし、このメソッドは、最後の2つのヘッダーを使用して実装することもできます。オリジンサーバーは、コンテンツの項目が最後に変更されたかを宣言することができ、またETag(エンティティタグ)―不透明な文字列で、しばしばそのコンテンツを識別するハッシュ値―と呼ばれるものを宣言することができます。

 

クライアントは、条件付きのGETを使ったリクエストを行うことができます。リクエストには、If-Modified-SinceまたはIf-None-Matchヘッダーを含めることができます。これを行うことで、クライアントは、最後に特定の日付に変更された、または特定のETagを持つコンテンツバージョンがキャッシュされていることを宣言します。サーバーが保持している最新のバージョンとクライアントのバージョンが一致している場合、サーバーは単純に 304 Not Modifiedで応答します。これは、ネットワーク帯域幅を節約する高速なレスポンスであり、クライアントが余裕のある時に、キャッシュされたコンテンツのコピーが依然として有効かどうかを確認できるようにします。

 

これらの5つのヘッダーは、オリジンサーバーの観点から、コンテンツのキャッシュ可能性(有効性、最新性、およびETagに関しては、コンテンツ自体の詳細)を定義します。

 

7:46 NGINXキャッシュとは何か?

NGINXなどのプロキシキャッシュは、それらのヘッダーにどのくらい厳密に準拠するかを、比較的自由に解釈できます。明らかにキャッシュ可能ではないものはキャッシュするべきではありませんが、元のサーバーがキャッシュ可能であると言った場合にも、キャッシュする義務はありません。

 

基本的なNGINXのふるまいは、オリジンサーバーがキャッシュ可能とするGETおよびHEADリクエストは、すべてキャッシュするというものです。これは、レスポンス内にSet-Cookieヘッダーがないことが条件です。これは、Set-Cookieヘッダーには通常、各リクエストに固有のデータが含まれており、デフォルトではその値をキャッシュするのは適切でないためです。

 

NGINXは各リソースを特定のキー(キャッシュキー)でキャッシュします。同じキャッシュキーを生成するすべてのリクエストは、同じリソースで満たされます。デフォルトでは、キャッシュは生のURLにマップされるか、設定ではこのスライドに示された文字列[$scheme$proxy_host$uri$is_args$args]にマップされます。NGINXがコンテンツをキャッシュする際には、X-Accel-Expiresヘッダーがあれば、またはCache-Controlヘッダー、レガシーExpiresヘッダーによって、(優先順に)有効期限が定義されます。

 

NGINXを調整して、これらのヘッダーの一部をマスクしたり、元のサーバーの内容に関係なく、固定キャッシュ時間を指定することができます。参考までに、RFC 2616は、HTTPに関するプロキシキャッシュの望ましい動作を定義しています。

 

ここでは、キャッシングの普遍性と、NGINXがコンテンツをキャッシュする際のデフォルトの基本動作を簡単にお伝えしましたが、これはウェブサイトを高速化し、オリジンサーバーから負荷を減らすために、通常はキャッシュするのが安全なコンテンツです。

 

9:55 NGINXの運用

次に動作中のNGINXを少し見てみましょう。NGINXでコンテンツキャッシュを有効にする設定は、本当にごくごく簡単です。

 

10:06 NGINXの設定

設定は、NGINX設定ファイルの数行です。1つめは、ファイルがどのようにレイアウトされるか、そのキャッシュ内のオブジェクトの有効期限とそのキャッシュのサイズを宣言する特定のパラメーターセットを使ってディスク上にキャッシュを作成します。次に、2番目のproxy_cacheディレクティブはNGINXプロキシに関連付けられ、コンテンツ(結果、レスポンス)が名前付きキャッシュにキャッシュされるように指示します。

 

ここでは、oneと呼ぶキャッシュを作成しました。メタデータ用のメモリのサイズは10MBですが、キャッシュされるコンテンツのディスク上のサイズは無制限です。コンテンツがキャッシュされてから、60分間非アクティブになっている場合はNGINXの恩恵を受けています。oneと命名したキャッシュは、私たちのデフォルトのサーバーで使用されています。これら2つのディレクティブproxy_cache_pathproxy_cache、NGINXのプロキシサーバーの信頼性、一貫性のあるキャッシュを有効にするのに十分です。

 

11:14キャッシングプロセス

NGINXがリクエストを受信して​​キャッシュに問い合わせる際のプロセスは、次のように定義されます。リクエスト(このスライドの左上のボックス)を読み込み、キャッシュキーを生のURIと、そのリクエストに対応するリソースを識別するために使うその他のパラメータに組み立てることから始めます。次に、メモリ上のメタデータにアクセスしてディスク上のキャッシュをチェックし、そのリクエストに対する有効な最新のコピーがあるかどうかを確認します。

 

その場合、それはキャッシュヒットとみなされます。その後、NGINXはキャッシュから直接応答できます。NGINXが静的コンテンツを提供するのとまったく同じように、ディスクからコンテンツを提供し、キャッシュから応答します。したがって、NGINXが設計したパフォーマンス、信頼性、およびスケーラビリティのレベルを得ることができます。静的コンテンツでは、NGINXのコンテンツキャッシュからコンテンツを提供するときに、正確に同程度のパフォーマンスを得られます。

 

一方、キャッシュをチェックすると、キャッシュミスが発生する可能性があります。これは、キャッシュにコンテンツがないこと、またはキャッシュ内のコンテンツが期限切れであり、コンテンツをリフレッシュする必要があることを意味します。もっとも単純なケースでは、そのキャッシュミスは、オリジンサーバーからコンテンツを要求し、レスポンスを受信し、キャッシュ可能かどうかを確認することを意味します。

 

であれば、私たちはプロキシモードで扱われる大きなレスポンスに対してNGINXと同様にディスクにストリームします。ディスクにストリームされると、それをキャッシュにコピーし、キャッシュから直接応答します。このアプローチの課題の1つは、NGINXが同じコンテンツに対して複数のリクエストを同時に受信し、すべてがミスした場合です。

 

NGINXは通常、これらのリクエストをすべてオリジンサーバーに転送して、過負荷にする可能性があります・・・特に、レスポンスの生成に時間がかかるリクエストについては。そのため、キャッシュロックを使用することができます。このproxy_cache_lockディレクティブは、コンテンツがリフレッシュされている場合、一度に1つのリクエストだけがアップストリームサーバーに送信されるようにします。

 

したがって、私がご説明したシナリオでは、最初のリクエストはアップストリームサーバーに送られますが、同じコンテンツに対する残りのリクエストは、レスポンスが生成され、キャッシュに挿入される(すべてのリクエストが満たされる)時まで、またはproxy_cache_lock_timeoutディレクティブで設定されたタイムアウト値まで留め置かれます。つまり、コンテンツがオリジンサーバーから戻ってくるまでNGINXが十分待った時点で、リリースされたリクエストはオリジンサーバーに転送されます。

 

つまりproxy_cache_lockおよびタイムアウトを使えば、皆さんのサイトで同じコンテンツに多数のリクエストが発生している中、キャッシュでそのコンテンツの有効期限が切れた時でも、突然、複数のリクエストでオリジンサーバーに過負荷をかけることがないよう、いくつかの強力な制御が可能になります。

 

NGINXのキャッシングプロセスには、このフローチャートに完全には収まらないもう1つの要素がありますが、それはチャートのほぼすべての段階を網羅しているためです。それがproxy_cache_use_staleディレクティブで設定される機能です。いずれにしても、何らかの理由でこれらのステージのいずれかが失敗した場合、たとえばコンテンツを更新してタイムアウトが発生した場合や、アップストリームサーバーからのレスポンスが悪い場合、その他のタイプのエラーの場合、キャッシュされたコンテンツが古くてもキャッシュから直接応答する選択もできます。

 

これは、アップストリームサーバーがトラフィックで圧倒されたり、メンテナンスや致命的なエラーのために失敗した場合に、本当に強力なツールです。これによってNGINXは、エラーメッセージをクライアントに返すのではなく、キャッシュから古いコンテンツを使って、コンテンツを引き続き配信できます。

 

15:32キャッシュはHTTPのためだけではありません

NGINXでのキャッシュは、HTTPのためだけのものではありません。NGINXは、上流のWebサーバーにリクエストを転送する単なるHTTPプロキシではありません。一般に、これらの上流のWebサーバーは、FastCGIやSCGIなどのAPIとのインターフェースを確立します。NGINXは、HTTPプロキシとよく似たプロキシ方式でこれを直接行うことができます。

 

NGINXは、HTTPプロキシFastCGIプロキシuWSGIプロキシ、およびSCGIプロキシのキャッシュ技術を使用できます。すべては、HTTPプロキシとほぼ同じように動作します。キャッシュはディスクに保存されて直接応答され、これらのアップストリームサービスにプロキシする必要はありません。

 

NGINXはmemcachedサーバーとのインターフェースとして利用可能です。これはやや異なるキャッシングアプローチです。この場合、NGINXはコンテンツを直接格納せず、memcachedをプロキシとして使用し、外部エージェントに依存して必要なコンテンツをmemcachedに取り込みます。これはもう1つの便利なツールになり得ますし、必要に応じて外部サイトからmemcachedを取り込む方法はたくさんあります。したがって、これがビジネス要件であれば、これをNGINXのキャッシュを設定する方法としてみなすことができます。

 

17:10何が起こっているのか理解する方法

複数の層を持つ大規模なインフラの場合、キャッシングを行うもの、行わないもの、コンテンツを生成するもの、生成しないものと、キャッシュは潜在的に非常に複雑になる可能性があります。すると何が起こっているのか、つまりコンテンツがどこから来ているのかを追跡し、起こった問題を診断してデバッグすることは非常に難しくなり得ます。NGINXは、これを可能な限り簡単にします。

 

17:38キャッシュ・インスツルメンテーション

洗練された計測機能を使って計測器を動的に制御すれば、コンテンツがどこから来ているのか、キャッシュに格納されている場所、キャッシュ内のステータスを追跡できます。

 

最初のステップは、$upstream_cache_status変数ですが、これはNGINXが応答したリクエストごとに計算された変数です。キャッシュからのものであるかどうかは関係ありません。そして、add_headerディレクティブを使用して、継続的にその変数の値をレスポンスに加えます。従来は、その値をレスポンスのX-Cache-Statusヘッダーに入れました。そのコンテンツがどのように配信されたかを宣言し、7つの異なる値のいずれかを取ることができます。キャッシュをバイパスしたかどうか、再検証から来たかどうか、ヒットしたかどうかです。

 

これは、あなたのレスポンスがどこから来ているかを理解するための最初のステップです。ローカルのNGINXキャッシュから来ているのか、それとも上流サーバーから来ているのか?また、応答ヘッダーをさまざまな方法で調べることができます。curlのようなツールを使用してコマンドラインから実行したり、非常に一般的な対話型デバッガを使うWebブラウザ内で行うことができます。

 

もちろん、すべてのエンドユーザーに対して、その値を宣言したくない場合もあります。ヘッダーレスポンスにいつその値を挿入するかに関しては、選択的に行いたいと思われるでしょう。

 

19:08キャッシュ・インスツルメンテーション(続き)

NGINXの設定言語には、柔軟な選択を可能にします。方法はたくさんありますが、以下に、そのうちの一例を示します。リモートアドレスを取得し、localhostの場合$upstream_cache_statusは、一時変数($cache_status)に格納します。最後に、レスポンスを返すときに、一時変数をレスポンスに入れます。

 

この方法では、選択的なIPアドレスからのリクエストにのみ$upstream_cache_status変数の値が表示されます。他にも多くのことができますが、この後、コンテンツをディスクに保存する方法を見ていきます。ディスク上の位置を計算するために使用されるキーをレスポンスに入れられます。すべての種類のパラメータをレスポンスに入れて、実行中のキャッシュの診断に役立てることができます。

 

20:09キャッシュステータス

NGINXの商用バージョンであるNGINX Plusには、キャッシュのような使用例を支援する多くの追加機能があります。NGINX Plusは、モスクワのエンジニアリングチームが構築したNGINXの商業サポート版のビルドであり、正しい動作を保証するために広範な回帰テストを実行しています。

 

NGINX Plusには、NGINXをリバースプロキシやロードバランサーとして検討する企業を対象とした多くの機能があります。ロードバランシング、ヘルスチェック、高度なビデオストリーミングなどの機能です。そしてこれに関連して、NGINXで起こっていることの拡張ステータス、より良い診断、および視覚化に関する機能があります。

[編集注 – 上のスライドと次の段落は、NGINX Plus APIを参照するように更新されました。このAPIは、ここで最初に説明した別のステータスモジュールを置き換えて複製しています。]

 

デモの場合、demo.nginx.com / dashboard.htmlに飛ぶと、NGINX Plusから公開されているステータスデータをNGINX Plus APIを使って表示するページを見られます。表示されたcurlコマンドを実行すると、NGINX Plusバイナリから直接取得された生のJSONデータが表示されます(ここでは、jq各要素を独自の行に配置し、階層的にインデントしてユーティリティにパイプされます)。

 

そのJSONデータには、NGINX Plusデプロイメントの各キャッシュの状態に関するリアルタイムのデータが含まれます。これは、$upstream_cache_status変数やその他の方法でキャッシュを計測することができ、NGINXがどのようにコンテンツをキャッシュし、個々のリクエストまでドリルダウンしてそのリクエストがキャッシュから来たものか、キャッシュ内の現在のステータスを確認します。

 

21:57コンテンツキャッシュがNGINXでどのように機能するか

さて、コンテンツキャッシングを調べる方法を外部から見てきたので、内部からも見てみましょう。NGINX内ではどのように機能するのでしょうか?前述のように、NGINXのコンテンツキャッシュは、ディスク上のファイルが処理されるのと同じように機能します。静的なコンテンツを処理する際に、コンテンツキャッシュからコンテンツを提供するのと同じパフォーマンス、同じ信頼性、同じオペレーティングシステムの最適化、つまりNGINXが高く評価されているパフォーマンスが得られます。

22:40 どのように動作するか

 

コンテンツキャッシュは、パーシステントキャッシュ内のディスクに格納されます。オペレーティングシステムと連携してディスクキャッシュをメモリにスワップし、オペレーティングシステムのページキャッシュにどのようなコンテンツをメモリに保存するかのヒントを提供します。つまり、キャッシュからコンテンツを提供する必要がある場合、非常に迅速にコンテンツを配信できます。

 

キャッシュ周りのメタデータ、そこにある情報、およびその有効期限は、すべてのNGINXプロセスの共有メモリセクションに別々に格納され、常にメモリ内に存在します。したがって、NGINXはキャッシュを照会し、非常に高速にキャッシュを検索することができます。レスポンスをプルしてエンドユーザーに返す必要があるときにのみ、ページキャッシュに移動する必要があります。

 

コンテンツがキャッシュにどう保存されるのか、起動時に空のNGINXワーカープロセスにパーシステントキャッシュがどうロードされるのかを見ていきます。また、NGINXがキャッシュ上で自動的に行うメンテナンスのいくつかを見てから、特定の状況でキャッシュからコンテンツを手作業で取り除く方法をまとめましょう。

 

23:53キャッシュされたコンテンツはどのように保存されるか

コンテンツキャッシュは、proxy_cache_pathと呼ばれるディレクティブを使って宣言されていることを思い出してください。このディレクティブは、ファイルシステムにキャッシュが格納されている場所、キャッシュの名前、メタデータのメモリ内のキャッシュのサイズ、およびディスク上のキャッシュのサイズといった、多くのパラメータを指定します。この場合、ディスクには40 MBのキャッシュがあります。

 

コンテンツが格納されている場所を理解するための鍵は、キャッシュキー(NGINXが各キャッシュ可能なリソースに割り当てる一意の識別子)を理解することです。デフォルトでは、識別子はリクエストの基本パラメータ、つまりスキーム、Hostヘッダー、URI、および任意の文字列引数から組み立てられます。

 

しかし、Cookie値や認証ヘッダー、あるいは実行時に計算した値を使用したい場合は、これを拡張することができます。ことによると、あなたは米国のユーザーと英国のユーザーには、異なるバージョンを保存したいと思うかもしれません。これはすべて、proxy_cache_keyディレクティブを設定することで可能になります。

 

NGINXがリクエストを処理すると、proxy_cache_keyを計算し、その値からMD5の合計を計算します。スライドのさらに下に表示されたコマンドラインの例を使用して、ご自分でそれを複製することができます。私たちは、キャッシュキーのhttplocalhost:8002 / time.phpを取得し、それをmd5sumを介してハッシュ値を生成します。コマンドシェルからこれを実行しているときには、新しい行で同様にハッシュ値を生成しないように注意してください。

 

上記が、そのキャッシュ可能なコンテンツに対応するMD5ハッシュ値を計算します。NGINXはそのハッシュ値を使用して、コンテンツを格納するディスク上の場所を計算します。proxy_cache_path内では、1文字と2文字のディレクトリを持つ2レベルのキャッシュを指定しています。これらの文字を文字列の最後から抜き出して、4というディレクトリと9bというサブディレクトリ を作成し、キャッシュの内容(ヘッダーと少量のメタデータ)をディスク上のファイルにドロップします。

 

ご自分で、コンテンツキャッシュをテストできます。キャッシュキーをレスポンスヘッダーの1つとして出力し、md5sumを通じて聞き出し、その値に対応するハッシュを計算することができます。次に、ディスク上の値を調べて、実際にそこにあることと、NGINXがキャッシュしたヘッダーであることを確認して、これらすべてがどのように関係するかを理解できます。

 

26:36ディスクからのキャッシュのロード

コンテンツがディスクに保存されてパーシステントになったので、NGINXが起動すると、コンテンツをメモリにロードする必要があります。そうでなければ、そのディスクキャッシュを経由してメタデータを抽出し、各ワーカープロセスによって使われる共有メモリセグメントにあるメモリに、メタデータをロードする必要があります。これは、キャッシュローダーと呼ばれるプロセスを使用して行われます。

 

キャッシュローダーは起動時にスピンアップし、いったん実行されると小さな塊でディスクにメタデータをロードします。一度に100ファイル、200ミリ秒にサンドボックス化された後、50ミリ秒間一時停止した後、全キャッシュをこの方法で処理し、共用メモリセグメントに移入するまでこれを繰り返します。

 

NGINXが再起動または再設定され、共有メモリセグメントを再び初期化する必要がないかぎり、キャッシュローダーは終了して、再実行する必要はありません。非常に高速なディスクがあり、負荷が軽い場合には適切かもしれませんが、キャッシュローダーの動作を調整することもできます。もし膨大な数のファイルのキャッシュを保存していてディスクが遅く、NGINXの起動時にキャッシュローダーが過度のCPUを使用することを望まないなら、キャッシュローダーを早く実行させることもできますし、おそらく少し落ち着かせたいと思うかもしれません。

 

28:07ディスクキャッシュの管理

キャッシュがメモリに格納され、ファイルがディスクに保存されると、アクセスされないキャッシュファイルが永久に残り続ける危険性があります。NGINXは初めて出てきた時にそれらを保存しますが、ファイルに対するリクエストがなくなれば、そのファイルは何かがやってきてそれを削除するまでディスク上に残り続けます。

 

この何かとはキャッシュマネージャーです。一定期間内にアクセスされていないファイルをディスクから取り除き、キャッシュが大きすぎて宣言されたサイズをオーバーフローした場合にファイルを削除します。直近に使われた方法でそれらを削除します。この動作は、キャッシュローダーを設定するのと同じように、proxy_cache_pathディレクティブに対するパラメータを使って設定できます。

 

  • Inactive 時間のデフォルトは10分です。
  • max-sizeパラメータにはデフォルトの制限はありません。キャッシュにmax-size制限を課すと、その制限を超えることがありますが、キャッシュマネージャーが実行されると、直近で使用されたファイルを整理して、その制限の下に戻します。

 

29:22ディスクからのコンテンツの除去

最後に、ディスクからコンテンツを除去したい場合があります。あなたはファイルを見つけてそれを削除したい。以前にお話ししたテクニック(キャッシュキーの実行)を知っている場合は、比較的簡単です。ファイルシステム全体でmd5sum を通してキャッシュキーを実行するか、単に繰り返しのgrepを実行して、削除する必要のあるファイルを特定します。

 

またはNGINX Plusを使用している場合、その製品に組み込まれているキャッシュパージ機能を使用できます。キャッシュパージ機能を使用すると、リクエストから特定のパラメータを取得できます。一般にキャッシュパージリクエストであることを識別する方法として、PURGEと呼ばれるメソッドを使用します。

パージは、URIを検査し、そのURIと一致するすべてのファイルをキャッシュから削除する特別なNGINX Plusハンドラによって処理されます。URIにはアスタリスクが付いているため、ステムになります。この場合、パージ機能を使用してローカルホストのポート8001から提供されるすべてのファイルを削除しますが、もちろんサブディレクトリにも置くことができます。

 

いずれの方法を使う場合も、ディスク上のキャッシュや、rm -rfキャッシュディレクトリ全体からファイルを削除することは、常に安全です。NGINXは一瞬足りとも止まりません。ディスク上のファイルの存在を確認し続けます。見つからない場合、キャッシュミスが発生します。NGINXは次に、オリジンサーバーからキャッシュを取り出し、ディスク上のキャッシュに戻して格納します。したがって、キャッシュから個々のファイルを消去する必要があっても、常に安全で信頼性が高く安定しています。

 

31:27キャッシュの制御

ここまで、キャッシングの仕組み、NGINXでの実装を見て、静的コンテンツと同じ種類のパフォーマンスを得るためにファイルをディスクに保存する方法について深く掘り下げてきました。さて、キャッシングをもう少し賢くしていきましょう。

 

単純なサイトでは、キャッシングをオンにすることができます。一般に、パフォーマンスのレベルと必要なキャッシュ動作を維持するために必要な処理を正確に実行します。しかし、常に最適化を行う必要があり、デフォルトの動作が必要な動作と一致しないことがよくあります。

 

おそらく、オリジンサーバーが正しいレスポンスヘッダーを設定していないか、NGINX自体の内部で指定している内容を上書きしたいことが考えられます。キャッシュの動作を微調整するよう、NGINXを設定する方法はたくさんあります。

 

32:30遅延キャッシング

キャッシュを遅らせることができます。コンテンツの大部分が1時間または1日に1、2回しかアクセスされないなら、これはごく一般的な状況です。その場合、ごく少数の読者しか読まない会社のパンフレットなら、それをキャッシュするのは時間の無駄です。遅延キャッシングを使用すると、ウォーターマークを適所に置くことができます。特定の回数リクエストされた場合にのみ、このコンテンツのキャッシュバージョンが保存されます。proxy_cache_min_usesウォーターマークに届くまで、キャッシュにバージョンを保存しません。

 

これにより、よりいっそう、キャッシュするコンテンツを区別することができます。キャッシュ自体は限られたリソースで、通常はサーバーのメモリ容量によって制限されています。これは、キャッシュができるだけメモリにページされるようにするためです。そのため、しばしば特定のコンテンツを制限し、一般的なリクエストだけをキャッシュに入れたいと考えます。

 

キャッシュの再検証は、コミュニティ版NGINXとNGINX Plusに最近追加された機能です。これは、If-Modified-Since機能を修正し、NGINXがキャッシュされた値をリフレッシュする必要があるときに、そのコンテンツの新しいバージョンを取得するのに単純なGETを行わないようにします。条件付きGETを使い、「この特定の日時に変更されたキャッシュバージョンがあります」と言います。

 

オリジンサーバーは、304 Not Modifiedで応答し、あなたが持っているバージョンが依然として最新のバージョンであるということを効果的に示すことができます。これは、アップストリームの帯域幅を節約できます。オリジンサーバーは変更されていないコンテンツを再送する必要はなく、潜在的にディスクへの書き込みも節約します。NGINXはディスクへのコンタクトをストリーミングしてから、古いバージョンを上書きしてその場所に置き換える必要がありません。

 

34:45キャッシュ時間の制御

コンテンツをキャッシュする期間をきめ細かく制御できます。多くの場合、オリジンサーバーは、ブラウザに適したキャッシュヘッダーを使用してコンテンツを提供します。これは、コンテンツへの更新リクエストが比較的頻繁に行われる、長期間のキャッシュです。しかし、オリジンサーバーの直前にNGINXプロキシを置いておくと、ファイルを少し頻繁に更新して、変更をより迅速に拾うことができて良いかもしれません。

 

ブラウザのキャッシュタイムアウトを60秒から10秒に減らすと、負荷が大幅に増加しますが、NGINXのキャッシュタイムアウトを60秒から10秒に増やすと負荷が非常に小さくなります。リクエストごとに、オリジンサーバーに1分あたり5つのリクエストが追加されますが、リモートクライアントの場合は、サイト上で同様のものがアクティブなクライアントの数によって異なります。

 

したがって、オリジンサーバーが示す論理と意図を上書きすることができます。NGINXが、X-Accel-Expires、Cache-ControlまたはExpiresといった特定のヘッダーをマスクまたは無視するようにできます。またNGINXの設定で、proxy_cache_validディレクティブを使い、デフォルトのキャッシュ時間を指定できます。

 

36:18キャッシュ/キャッシュしない

オリジンサーバーがキャッシュ可能としているコンテンツをキャッシュしない場合や、NGINXに保存されているバージョンのコンテンツをバイパスしたい場合があります。The proxy_cache_bypassproxy_no_cacheディレクティブは、そのレベルの制御を実現します。

 

特定のリクエストヘッダーセット(HTTP認証など)が設定されている場合、またはリクエストパラメータが存在する場合は、キャッシュをバイパスするショートカットとして使うことができます。キャッシュをバイパスする方法は、NGINXのキャッシュを自動的に更新するか、完全にスキップして常にオリジンサーバーから取得するようにします。

 

通常、これはかなり複雑なキャッシング判断のために行います。クッキーの値と承認ヘッダーの値を細かく決定して、キャッシュするものと、元のサーバーから常に受け取るべきものと、 NGINXキャッシュに消して格納しないものをコントロールします。

 

37:25複数のキャッシュ

最後に、非常に大規模な構成の場合、いくつかの理由から、個々のNGINXインスタンス内の複数のキャッシュを調べることが必要な場合があります。サイトの性質やそのサイトのパフォーマンスの重要性に応じて、さらには各テナントが共有ホスティング環境でサインアップしている特定の計画にも応じて、NGINXプロキシ上の異なるテナントに対し、異なるキャッシュポリシーが適用される場合があります。

 

または、NGINXホスト上に複数のディスクが存在するかもしれませんが、各ディスクに個別のキャッシュを配置するのが最も効率的です。黄金ルールは、あるディスクから別のディスクへのコピー数を最小限に抑え、各ディスクにキャッシュを固定し、そのキャッシュを正しいディスクに使用する各プロキシの一時ファイルを固定することで実現できます。

 

標準的な運用では、NGINXがアップストリームプロキシからコンテンツを受け取ると、メモリに収まるほど小さくない限り、コンテンツをディスクにストリーミングします。その後、コンテンツはいったんディスクにストリームされ、キャッシュに移動します。この操作は、一時ファイル(一時ファイルが格納されているディスク)のキャッシュ上の場所が、キャッシュが格納されているディスクと同じ場合は、限りなく効率的です。

 

39:07クイックレビュー – なぜキャッシュ?

ここまでキャッシングについてお話ししてきました。NGINXが使っているメソッド、NGINX内での実装、および調整方法についてご説明しました。終わりが近づいてきましたので、そもそもコンテンツをキャッシュする理由を思い出すために簡単に振り返ってみましょう。NGINXは世界中1億1400万のWebサイトに導入されており、その導入の理由は、Webアクセラレーション機能とコンテンツキャッシュ機能です。[ 編集注 – 2014年5月にウェブセミナーが配信された時点の統計情報です ]

 

39:44ページスピードはなぜ重要か?

これらの機能で、Webサイトのスピードが向上し、エンドユーザーにはより高レベルのエクスペリエンスを提供します。そこではWebページのスピードは本当に、本当に重要です。アナリストは何年もの間ユーザーの行動を観察し、「N秒ルール」として知られる現象を見つけています。これは、平均的なユーザーが飽きてうんざりし、別のWebサイト、競合サイトに移動する前に、どれくらいならページの読み込みと描画を待つことができるか、という時間です。

 

基準が改善され、ユーザーの期待がますます高くなっているため、ユーザーの待機時間は、どんどん短くなっています。若干疑わしい数学ですが、推論すると、ユーザーの忍耐力は2016年までにマイナスレベルになると結論づけることができます。

 

40:46 Googleがルールを変更した

 

「本をめくるのと同じくらい素早く、Webでもページからページへと移動できるようにしたい」

Urs Holzle, Google

 

でも、実際にはテクノロジーが私たちを追い抜いてしまっています。Googleは数年前にGoogleのインスタント検索を導入する際に、これを図解しました。今やGoogleでは、検索ボックスに検索用語を入力すると、入力を完了する前でさえ、検索結果の候補を提示します。これは、現代インターネットにおける期待の大きな変化を示しています。Google自身が言っているように、「ユーザーは今や、書籍のページをめくるのと同様の反応を、ウェブページに期待しています」 ・・・すばやく、シームレスに、そして滑らかに。

 

41:28パフォーマンスの低下のコスト

画像内文章――――――――――

  • Google:検索機能の強化により、ページロードが0.5秒低下
    ― 広告のCTRが20%低下
  • Amazon:人工的にページロードを100ms増加
    ― 顧客収益が1%ダウン
  • Walmart, Yahoo, Shopzilla, Edmunds, Mozilla
    ― すべて収益に対する似たような影響を報告
  • Google Pagerank – ページスピードはページランクに影響する
    ― 最初の1バイトまでの時間が重要

――――――――――

そのレベルのパフォーマンスを達成できない場合は、WebサイトまたはWebサービスに与えられたKPIに重大な影響を与える可能性があります。広告のクリックスルー率でも、検索ページの読み込みに0.5秒多くかかると、広告のクリック率が20%低下したことを、Google自身が発見しました。収益でも、遅いWebページの影響を調べるため熟慮した試みの一環として、Amazonは意図的に100ミリ秒の倍数でページ負荷を増加させました。結果、影響を受けた顧客からの収益は、通常100ミリ秒の増加ごとに1%減少しました。

 

他の多くのアナリスト、ウェブサイト、調査者も、ウェブサイトのメトリクスに対して同様の影響を報告しています。ページ上の滞在時間や直帰率などです。最近、Googleは検索結果のページランクを計算するときにページスピードを考慮に入れるようになりました。重視されているように見えるのは、最初の1バイトまでの時間です。ページロードの最初の1バイトを取得するのにかかる時間が長いほど、ページランクに大きなペナルティが課されます。ウェブサイトがGoogle検索結果の3ページ、4ページ、または5ページに表示される結果、アクセスすらされないという状況に陥る可能性があるのです。

 

43:00 NGINXキャッシングでできること

画像内
NGINXキャッシングでできること

  • エンドユーザー性能を向上
  • Webインフラの統合と単純化
  • サーバー能力の強化
  • サーバー不具合と無縁に

 

NGINXのキャッシング機能を使って最初の1バイトまでの時間を短縮し、Webコンテンツをよりキビキビと反応的なものにすることで、エンドユーザーエクスペリエンスを向上させることができます。

 

NGINXを使用すると、Webインフラを統合して簡素化できます。NGINXは単なるスタンドアロンのWebキャッシュではありません。NGINXにはWebのオリジンサーバーが含まれており、FastCGIなどのAPIへのダイレクトゲートウェイが含まれています。また、NGINX Plusには、高度なエンタープライズ対応のロードバランサーとアプリケーション デリバリ コントローラを構築する機能があります。これにより、Webインフラストラクチャ内の複数の異なるネットワークコンポーネントを単一のコンポーネント(NGINXまたはNGINX Plus)に統合することができ、より信頼性が高く、デバッグしやすく、迅速なソリューションを提供します。

 

NGINXを使用すると、反復作業をアップストリームサーバーから取り除くことで、サーバーの容量を増やすことができます。実際、キャッシングできないように見えるコンテンツ(例えば、ブログサイトのトップページ)でさえ、NGINXプロキシでわずか1秒キャッシングすることにはメリットがあります。

 

100人のユーザーが同じコンテンツを同じ瞬間にリクエストすると、NGINXはそれをオリジンサーバーに対する1回のリクエストに減らし、キャッシュからそれらのユーザーにコンテンツを返します。また、そのコンテンツは確実に最新のものです。これはたいてい、ブログやそれに類するサイトでは充分以上ですが、アップストリームサーバーへの負荷や、十分な容量を管理、構成する経費の両方において、パフォーマンスに大きな違いがあります。

 

最後に、NGINXの戦略的な使い方の1つをぜひ覚えておいてください。プロキシキャッシュの「古いものを使う」機能で、アップストリームサーバーの障害知らずになることです。アップストリームサーバーが遅い場合、エラーを返す場合、何らかの障害がある場合、NGINXはローカルのキャッシュされたバージョンのコンテンツにフォールバックして、アップストリームサーバーが回復するまでそれを使い続けることができます。

 

45:21最後に

世界で最も頻繁に利用されているウェブサイトの38%は、Webアクセラレーション機能とコンテンツキャッシュ機能を目的に、圧倒的にNGINXを使用しています。[ 編集注 – この統計は2014年5月にウェブセミナーが配信されたときのものです。ここで現在の値を参照してください。] より多くのソリューションや詳細については、NGINXとNGINX Plusの機能について説明するnginx.com で、ブログや機能概要をご覧ください。また、ウェビナーのリストもご覧ください。将来のウェビナーだけでなく、このシリーズの過去のイベントからのウェビナーもすぐに追加されます。

 

これらの機能をさらに調査したいのであれば、もちろんnginx.orgnginx.comで見つかるドキュメントや解決策もありますが、ダウンロードして試してみることに勝るものはありません。オープンソース製品はnginx.orgから、または追加の負荷分散、アプリケーションデリバリ、管理、および使いやすい機能をもつ商用のサポート付き製品はnginx.comからご覧ください。

 

それでは皆さん、この時間を頂いたこと、ご清聴頂いたことに感謝します。ここにおられる皆さんにとって、このプレゼンテーションと、一通りお話ししたNGINXでのコンテンツキャッシングがお役に立ち、ヒントになるものであったなら幸いです。

 

Q&A

では、質問に移って、私たちのやり方を見ていきましょう。

 

47:20 Byte-Rangeリクエスト

Byte-Rangeリクエストについて質問があります。Byte-Rangeリクエストは、クライアントがコンテンツの一部をリクエストしたときに使用されますが、そのコンテンツのサブセットのみが必要です。例えば、それがビデオファイルで、クライアントはビデオの一部だけを必要としているとします。または、よくあるケースとしてPDFファイルだと、ユーザーはPDFファイルにインデックスを持つヘッダーを読み込んでおり、クライアントは特定のページセットをダウンロードしたいだけです。NGINXのコンテンツキャッシュでは、これはどのように動作しますか?

 

プロセスは次のとおりです。NGINXがあるリソースに対してByte-Rangeリクエストを受信し、リソース全体がすでにキャッシュに入っている場合、NGINXはクライアントからリクエストされたバイト範囲でキャッシュから応答します。そのリソースがキャッシュにない場合、NGINXはリソース全体をアップストリームサーバーに要求し、そのリソースをキャッシュに格納します。現在のところ、その時点ではNGINXはByte-Rangeリクエストに従わず、リソース全体をクライアントに返します。ほとんどの場合、それは容認できる動作です。

 

たとえば、クライアントがPDFドキュメントをダウンロードしている場合、いずれにせよ最初のリクエストはドキュメント全体に対してであり、そのドキュメントがストリーミングされている場合にのみ、クライアントは接続を打ち切り、Byte-Rangeリクエストを開始します。したがって、キャッシュされたコンテンツの場合、NGINXはByte-Rangeリクエストを受け入れます。キャッシュされていないコンテンツの場合、NGINXはアップストリームサーバーからコンテンツ全体を取得し、コンテンツ全体をその1つのインスタンスのクライアントに返します。

 

49:13プロキシキャッシュの再検証

これは、プロキシキャッシュの再検証機能に関する質問です。これは、コンテンツが変更されたかどうかを確認するため、NGINXがアップストリームサーバーに対し条件付きGETを送信する機能です。質問はこんな内容です。

 

プロキシキャッシュの再検証係数はETagまたは単にコンテンツのIf-Modified-Since日付ですか?

 

答えは、コンテンツのIf-Modified-Since日付をチェックするだけです。実践のポイントとしては、常にIf-Modified-Sinceをあなたのレスポンスに含めること、ETagをオプションとして扱うことです。ETagは、みなさんがレスポンスで扱う”last modified:最終更新日”の日付ほどには、一貫して幅広く取り扱われていないためです。

 

50:07平等なディスク間でキャッシュを分散する

最高のパフォーマンスを得るため、数台のディスク間で単一サイトのキャッシングを負荷分散することは、NGINXで可能ですか?

はい、できます。 少し作業が必要です。一般的なシナリオでは、RAIDなしで多数のディスクを設定してから、各ディスクに固定された個々のキャッシュを設定します。トラフィックに対し、追加の設定とパーティショニングが必要です。設定に手助けが必要でしたら、私たちのコミュニティにご連絡ください。具体的なリクエストに対応いたします。NGINX Plusをご利用の場合は、サポートチームにご連絡いただければ、喜んでお手伝いさせていただきます。

 

50:50 Varyヘッダー

NGINXはVaryヘッダーが要因でキャッシュヒットやキャッシュミスしますか?

 

いいえ、NGINXはVaryヘッダーを自動的に処理しません。それが問題ならば、Varyヘッダーをプロキシキャッシュキーに追加するのは簡単ですので、レスポンスを格納するのに使われる一意のキーに、Varyヘッダーの値が含まれるようにできます。それで、複数の異なるバージョンを保存することができます。

 

51:25キャッシングプリミティブ

すべてのキャッシングプリミティブとディレクティブは尊重されていますか?

 

はい、一般的には。Varyヘッダーのようないくつかの微妙なケースでは、尊重されていません。多くの場合、さまざまなキャッシュがRFCの要件をどのように解釈するかについては、ある程度の自由度があります。私たちは可能な限り、信頼性が高く、一貫性があり、設定が簡単な実装を行ってきました。

 

51:52アップストリームヘッダーとデータ

アップストリームヘッダーとデータの両方がキャッシュされていますか?

 

はい、そうです。キャッシュから応答を受け取った場合、ヘッダーはレスポンス

と同様にキャッシュされます。

 

52:13 *-Encodingヘッダー

ヘッダーの値はレスポンス本体と同様にキャッシュされていますので・・・、もしNGINXがさまざまなTransfer-Encodingの組み合わせで正しく動作しないと、私はかなり驚くと思います。Accept-Encodingは、Varyヘッダーを使用して実装されることが多いため、Varyヘッダーをキャッシュキーに入れる必要があるという以前のコメントはそこに適用されます(それをサポートしていないクライアントの場合)。

 

52:56 SPDY

SPDYのキャッシュは機能しますか?

 

もちろんです。実際にはNGINXカーネルに非常に深く絡み合っていますが、それをNGINXのフロントエンドプロキシと考えることができます。はい、SPDYはキャッシュに対して機能します。

 

53:15 Varyヘッダー、第2ラウンド

Varyヘッダーに関しては別の質問があります。確認のため、Vary-headerレスポンスとgzips を使用している場合は、Tracまたはコミュニティサイトのディスカッションを参照してください。最も一般的な方法は、Varyヘッダーをキャッシュキーに埋め込むことです。

 

53:45 PageSpeed

Q:PageSpeedはNGINXのキャッシングを使っていますか?または独自のキャッシュメカニズムですか?

 

それはPageSpeed開発者と共有する必要がある質問ですね。

 

54:00その他のキャッシュ

Q:他のコンテンツキャッシュ手法は、NGINXと比較してどうですか?

 

CDNは非常に効果的なコンテンツキャッシングソリューションです。CDNはサービスとして展開されます。コンテンツがキャッシュされる方法や、その中でどう期限切れにするかに関しては、より限定的な制御となりますが、コンテンツをエンドユーザーの近くにもっていくためには非常に効果的なツールです。NGINXは、Webアプリケーションを高速化する非常に効果的なツールであり、両方一緒にデプロイされることはよくあります。Varnishのようなスタンドアロンのキャッシュの場合はどうでしょう。これらもまた、多くの点でNGINXと似たやり方で動作し、非常に能力の高い技術です。NGINXのメリットの1つは、オリジンサーバーからアプリケーションゲートウェイ、キャッシング、およびロードバランシングを1つのソリューションにまとめて提供することです。そのため、展開が容易で、管理が簡単で、問題があればデバッグや診断が容易な、よりシンプルで統合されたインフラを実現できるのです。

 

この投稿の元になっているウェブセミナーを見るには、こちらにアクセスしてください。

NGINX Plusを試すには、今すぐ30日間無料トライアルを開始するか、当社までご連絡ください

nginx 1.15.1リリース

2018年7月3日にコミュニティ版ホームページ(nginx.org)で1.15.1が公開されました。

以下にリリース内容の参考訳を記載します。

nginx 1.15.1 リリース内容

<機能追加>
1.”upstream”ブロック内に”random”ディレクティブの記述が可能になりました。

2.”zone”ディレクティブで”hash”と “ip_hash”ディレクティブを使用する時のパフォーマンス改善を行ないました。

3.FreeBSD 12のSO_REUSEPORT_LBで”listen”ディレクティブの “reuseport”パラメータが使用出来るようになりました。

<バグ修正>
1.フロントのnginxプロキシ―サーバーでSSLが終了した場合、HTTP / 2サーバープッシュは機能しませんでした。

2. “tcp_nopush”は常にバックエンドに接続されていました 。

3.ディスクバッファリングされたリクエストボディをgRPCバックエンドに送信失敗していました。

   *) Feature: the “random” directive inside the “upstream” block.

    *) Feature: improved performance when using the “hash” and “ip_hash”
       directives with the “zone” directive.

    *) Feature: the “reuseport” parameter of the “listen” directive now uses
       SO_REUSEPORT_LB on FreeBSD 12.

    *) Bugfix: HTTP/2 server push did not work if SSL was terminated by a
       proxy server in front of nginx.

    *) Bugfix: the “tcp_nopush” directive was always used on backend
       connections.

    *) Bugfix: sending a disk-buffered request body to a gRPC backend might
       fail.

 

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper