NGINX Plus

NGINX R17がリリースされました

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

2018年12月11日にNGINX Plus R17がリリースされました。
今回のリリースではTLS1.3のサポート、レート制限のメソッド追加、stream/zone_syncモジュールの更新となります。

以下、詳細を和訳し記載します。

——————————————————————————————————————————————–

  • ssl_protocolsディレクティブのTLSv 1.3パラメータを用いたTLS1.3のサポート 
  • 2段階レート制限のサポート。過度のリクエストに対して最初に遅延しつつ、最終的には拒否されます。
  • JSON Webトークン(JWT)モジュールへのEd25519およびEd448暗号アルゴリズムのサポートが追加されました。
  • auth_jwt_key_requestディレクティブでOpenID Connectを使用している場合、アイデンティティプロバイダ(IdP)から直接JSON Webキー(JWK)を取得する機能を追加されました。
  • 新しいproxy_socket_keepaliveディレクティブにより、NGINX Plusとプロキシされたサーバの間でTCP keepaliveを有効にすることができます
  • keepalive_timeoutディレクティブは、アイドル状態のHTTPキープアライブ接続がNGINX Plusとプロキシされたサーバ間で開いたままになる時間を制御します
  • streamモジュールのproxy_requestsディレクティブは、そのサーバへの新しいUDP「セッション」を開始する前に、NGINX Plusからプロキシされたサーバに送信されるパケットの数を定義します
  • zone_syncモジュールは、zone_sync_ssl_server_nameディレクティブを使用してサーバー名検証のためのクラスタノードに接続するときにSNIを使用してサーバー名を渡すことができるようになりました

    以下、NGINX Java Scriptモジュールが更新されました。

    • 引数オブジェクトのサポート
    • 非整数分数のサポート
    • 追加時間メソッドのサポート:console.time()およびconsole.timeEnd()
    • 変数と関数を再宣言出来るようになりました。
    • TCP/UDPアプリケーション用のNGINX streamモジュールとの統合は入力トラフィック変更するためのsend()メソッドなど、様々なreturn関数を使用出来るようにリファクタリングされました。また出力トラフィックはコールバックを介して利用できるようになりました。

——————————————————————————————————————————————–

以下、原文を記載します。

——————————————————————————————————————————————–

NGINX open source build 1.15.7, 11 December 2018

NGINX Plus R17 is a feature release:

  • Support for TLS 1.3 using TLSv1.3 parameter to ssl_protocols directive
  • Support for two stage rate limiting with the new delay= parameter; excessive requests are initially delayed and then ultimately rejected
  • Added support for the Ed25519 and Ed448 cryptographic algorithms to the JSON Web Token (JWT) module
  • Ability to fetch JSON Web Keys (JWK) directly from identity provider (IdP) when using OpenID Connect with the new auth_jwt_key_request directive
  • New proxy_socket_keepalive directive allows TCP keepalives to be enabled between NGINX Plus and the proxied server
  • New keepalive_timeout directive controls how long an idle HTTP keepalive connection will stay open between NGINX Plus and the proxied server
  • New proxy_requests directive for the stream module defines how many packets will be sent from NGINX Plus to the proxied server before starting a new UDP “session” to that server
  • The zone_sync module can now pass the server name using SNI when connecting to cluster nodes for server name verification with new zone_sync_ssl_server_name directive
  • The NGINX JavaScript module has been updated:
    • Support for arguments objects
    • Support for non-integer fractions
    • Support for additional time methods: console.time() and console.timeEnd()
    • Variables and functions can now be redeclared
    • Integration with the NGINX Stream module for TCP/UDP applications has been refactored to use various return functions, including a send() method for modifying ingress traffic. Egress traffic is now available through a callback.

——————————————————————————————————————————————–

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 PlusのAPIゲートウェイソリューション

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

今回はNGINX PlusのAPIゲートウェイ機能に焦点を当てたいと思います。

 

APIゲートウェイとは

Web APIを用いたクラウドインテグレーションを行なう為に必要となるアーキテクチャです。

企業ネットワーク内にデプロイされているアプリケーションとパブリッククラウドサービスとの間
にゲートウェイとして機能し、全ての通信はこのAPIゲートウェイを介して行ないます。

例えば、通常はクライアントからバックエンドの各マイクロサービスのAPIを数回に渡って
呼び出すことが必要であり、クライアント側で各マイクロサービスのAPIを管理する必要が
ありました。
このAPIゲートウェイを導入することにより、クライアントはAPIゲートウェイに対して1回だけ
APIを呼び出すだけで、後はAPIゲートウェイが各マイクロサービスのAPIの呼び出しを肩代わり
してくれます。

APIゲートウェイの使用例

下記の表はAPIゲートウェイとしてのNGINX Plusが外部ソースからのAPIリクエストを管理し、
内部サービスにルーティングするための要件を満たす方法を示しています。

  APIゲートウェイ要件 NGINX Plusソリューション
コアプロトコル REST(HTTPS)、gRPC HTTP、HTTPS、HTTP / 2、gRPC
その他のプロトコル TCP-borneメッセージキュー WebSocket、TCP、UDP
リクエストルーティング リクエストは、サービス(ホストヘッダー)、APIメソッド(HTTP URL)、およびパラメーターに基づいてルーティングされます ホストヘッダー、URL、およびその他の要求ヘッダーに基づいた非常に柔軟なリクエストルーティング
APIライフサイクルの
管理
従来のAPIリクエストの書き換え、廃止予定のAPIへの呼び出しの拒否 要求に直接ルーティングまたは応答するための包括的な要求書き換えと豊富な意思決定エンジン
脆弱なアプリケーションの保護 APIとメソッドによるレート制限 送信元アドレス、要求パラメータを含む複数の基準によるレート制限。バックエンドサービスへの接続制限
オフロード認証 着信要求の認証トークンの検査 JWT、APIキー、外部認証サービス、OpenID Connectなどの複数の認証方法のサポート
変化するアプリケーショントポロジの管理 構成変更を受け入れ、青緑のワークフローをサポートするためのさまざまなAPIの実装 エンドポイントを特定するためのAPIとサービスディスカバリーの統合 ブルーグリーンデプロイメントやその他のユースケース用にAPIを編成できます

NGINX PlusではWebトラフィックを容易に管理出来、プロトコル(HTTP/2, HTTP, FastCGI, uwsgi)を変換し、一貫した設定とモニタリングGUIの提供が可能です。

NGINX PlusのAPIゲートウェイ機能

NGINXコミュニティ版はもとはHTTP(Web)トラフィックのゲートウェイとして開発されており、設定されているプリミティブはHTTPリクエストの観点から表現されています。
NGINX Plusではより複雑なAPIをマップし、多くの一般的なAPIゲートウェイタスクを処理します。

NGINX PlusによるAPIゲートウェイの各処理方法の詳細については以下のリンクを参照下さい。

【参考URL】

https://www.nginx.com/blog/consolidating-your-api-gateway-and-load-balancer-with-nginx/

2018年 ロードバランサー価格・パフォーマンス比較:NGINX Plus vs F5 BIG-IP

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

今回はNGINX PlusとF5 BIG-IP ロードバランサーの機能、価格比較をテーマに記事を掲載していきます。

 

前回(2016年)に機能、価格比較をしましたが、この2年間でNGINX Plusはもちろんのこと、F5 BIG-IPの
ロードバランサーの機能・パフォーマンスも進化しています。
特にパフォーマンスが進化している点としては以下挙げられます。

  • HTTPリクエスト/秒(RPS)
  • SSL / TLSトランザクション/秒(TPS)
  • HTTPスループットはギガビット/秒(Gbps)

上記点を考慮し、F5 BIG-IP 製品群のパフォーマンスメトリックを比較していきます。

NGINX Plus vs F5 BIG-IP i2600

[Dell R330ハードウェアスペック]
Intel Xeon 4110 @ 2.1GHz 8Core およびIntel XL710 2×40 Gbeネットワーク・インターフェース・カード

 

  F5 BIG-IP i2600 NGINX Plus(Dell R330)
コスト
ワンタイムハードウェアコスト $19,175 $2,200
年間8×5サポートとソフトウェアの
サブスクリプション費用
$2,300 $2,500
総費用(1年目) $21,475 $ 4,700 
(78%節約)
総費用(3年目) $26,075 $ 9,700 
(63%節約)
総費用(5年目) $30,675 $11,700
(59%節約)
パフォーマンスメトリック
HTTP RPS 350,000 350,000
SSL / TLS TPS 2,500 14,000 1(5.6x)
スループット(Gbps) 10 40(4x)

1 OpenSSL 1.0.2dの使用

NGINX Plus vs F5 BIG-IP i5600

[Dell R630ハードウェアスペック]

Intel Xeon E5-2699 v4 @ 2.2 GHzデュアル22コアとデュアルIntel XL710 2×40 Gbeネットワーク・インターフェース・カード

 

  F5 BIG-IP i5600 NGINX Plus(Dell R630)
コスト
ワンタイムハードウェアコスト $53,000 $10,000
年間8×5サポートとソフトウェアの
サブスクリプション費用
$9,540 $3,500
総費用(1年目) $62,540 $13,500
(78%節約)
総費用(3年目) $81,620 $20,500
(75%節約)
総費用(5年目) $100,700 $27,500
(73%節約)
パフォーマンスメトリック
HTTP RPS 1.1M 1.2M(1.1x)
SSL / TLS TPS 20,000 61,000(3.1x)1
スループット(Gbps) 60 70(1.2x)

1 OpenSSL 1.0.2dの使用

結論

同等スペックのF5 BIG-IPと比較した結果、NGINX Plusではトータルコストも大幅に削減し、かつSSL / TLS TPSでの性能向上が顕著に表れています。

F5 BIG-IPは20年以上にわたりIT業界を牽引してきました。
しかし、今日ではハードウェアアプライアンスからクラウドネイティブなソリューションへの移行を検討する
企業も増えてきています。

そのソリューションの選択肢としてNGINX Plusのソフトウェアベースのロードバランサーを採用し、コスト面と
性能面で恩恵を受けています。

この機会に社内のアプリケーションデリバリーを見直してみてはいかがでしょうか?

 

NGINX Plus(30日間)評価版の申し込みにつきまして、絶賛受付中です。
是非お気軽にご連絡下さい。

評価版申請ページはこちら

 

【参考記事】
NGINX Plus vs. F5 BIG-IP: 2018 Price-Performance Comparison

NGINX R16がリリースしました。

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

2018年9月5日にNGINX Plus R16がリリースされました。
今回のリリースではクラスタ機能の追加、UDPパケットの新たなプロトコルにも対応し、
更なるNGINXインスタンス可用性と拡張性が高まりました。

以下、詳細を和訳し記載します。

——————————————————————————————————————————————–

  • モジュールを使用したクラスタでのレート制限のサポートzone_sync
  • モジュールを使用してクラスタ内のキーバリューストアをサポートzone_sync
  • キーバリューストアモジュールのタイムアウトのサポート
  • randomロードバランシングアルゴリズムを2つの選択肢のオプションでサポートします。
    2つの選択肢を使用する場合、least_timeまたはleast_conn2つの負荷分散の決定に使用できます
  • streamクライアントからの複数のUDPパケットを新たにサポートし、拡張されたUDP負荷分散(モジュール)OpenVPN、VoIP、VDIなど、より複雑なUDPプロトコルをサポートします。
  • プロキシプロトコルv2(PPv2)ヘッダーのサポート、およびヘッダー内のカスタムTLV値の検査機能
  • AWS PrivateLinkのサポート、AmazonのVPCへのセキュアなトンネル作成技術
  • OpenIDの接続のリファレンス実装で、不明なセッショントークンをサポートするように拡張されました
  • TCP / IP streamプロキシを使用してトラフィックを転送する場合のSSL / TLSとその他のプロトコルを区別する新しい変数が追加されました。($ssl_preread_protocol
  • 新しい暗号化セッション動的モジュールが利用可能になりました。
  • NGINX JavaScriptモジュールが更新されました:
    • 各HTTPリクエストに関連付けられたリクエスト属性とレスポンス属性の両方にアクセスするための単一のobject()が追加されました。
    • 新しい言語サポート:bytesFrom()padStart()padEnd()getrandom()getentropy()、およびバイナリリテラル

——————————————————————————————————————————————–

以下、原文を記載します。

——————————————————————————————————————————————–

NGINX open source build 1.15.2, 5 September 2018

NGINX Plus R16 is a feature release:

  • Support for rate limiting in a cluster using zone_sync module
  • Support for key-value store in a cluster using zone_sync module
  • Support for timeouts in key-value store module
  • Support random load balancing algorithm with option of two choices. When using use two choices, least_time or least_conn can be used for the load balancing decision between the two choices
  • Enhanced UDP load balancing (stream moddule) with new support for multiple UDP packets from the client. Support more complex UDP protocols such as OpenVPN, VOIP, and VDI.
  • Support for the Proxy Protocol v2 (PPv2) header, and the ability to inspect custom TLV values in the header
  • Support for AWS PrivateLink, Amazon’s technology for creating secure tunnels into a VPC
  • The OpenID Connect reference implementation has been extended to support opaque session tokens
  • New $ssl_preread_protocol variable to distinguish between SSL/TLS and other protocols when forwarding traffic using a TCP (stream) proxy
  • New Encrypted-Session dynamic module available
  • The NGINX JavaScript module has been updated:
    • There is now a single object (r) to access both request and response attributes associated with each HTTP request.
    • New language support: bytesFrom()padStart()padEnd()getrandom()getentropy(), and binary literals

——————————————————————————————————————————————–

NGINX Plusを使用したAWS Auto Scalingグループ内の負荷分散

本ブログ記事は、NGINX,Inc.ブログ記事「Load Balancing AWS Auto Scaling Groups with NGINX Plus」を翻訳した内容になります。

URL:https://www.nginx.com/blog/load-balancing-aws-auto-scaling-groups-nginx-plus/

 

クラウドの最も有益な機能の1つは、コンピューティングインスタンスの数を自動的にスケーリングする機能です。AWS Auto Scalingを使用すると、Auto Scalingグループ内のEC2インスタンスの数を、スケジュールまたはリクエスト数に基づいて手動または自動で変更できます。Auto Scalingは、現在のワークロードのインスタンス数を適切な数に調整することで、コストを削減します。さらに、Auto Scalingは失敗したインスタンスを再起動し、アプリケーションの可用性を与えます。

Auto Scalingを使用する場合は、負荷分散が重要です。AWSは、Auto Scalingグループのインスタンスのロードバランシングを提供します。これは、AWSサービスのロードバランサ(Elbu Load Balancer(ELB))(正式にはクラシックロードバランサ、アプリケーションロードバランサ(ALB))はAuto Scalingと統合されています。NGINX Plusは、AW​​Sを含むあらゆるクラウド環境に高度なクラウドロードバランシングを提供し、AWS Auto Scaling グループをサポートします。

組み込みのAWSクラウドロードバランサの代替または追加としてNGINX Plusを
選択する主な理由は3つあります。

  1. NGINX Plusは、ELBおよびALBには欠けている複数の高度な機能を提供します。
  2. AWSロードバランサ(特にALB)の価格設定モデルは複雑で、コストを予測することは困難です。NGINX Plusのプライシングは、当社から直接NGINX Plusサブスクリプションを購入するか、または事前構築されたNGINX PlusインスタンスをAWS Marketplaceから実行され、設定された
    時間単価で請求される為、コスト予測も容易です。
  3. NGINX Plusはプラットフォーム固有のAPIに結びついていないため、複数のクラウドプラットフォーム間でロードバランシング設定を再利用できます。

NGINX PlusがAWSの組み込みソリューションとどのように比較され、どのように連携しているかを確認するには、ELBALBのブログ記事をご覧ください。

このブログ記事では、NGINX PlusをロードバランシングAuto Scaling グループに
設定する2つの方法を示し、各方法を使用することが理に適った時を説明します:

  1. ELBの前でNGINX Plusを使用する
  2. NGINX、Inc.が提供する統合ソフトウェアでNGINX Plusを使用する

このブログ記事を読んだら、AWSにNGINX Plusを導入して、Auto Scalingグループの高度な負荷分散を提供する準備が整います。

サンプルAWSオートスケーリング環境

サンプルアプリケーション環境とNGINX Plusを使用してAuto Scalingグループの負荷分散を行う2つの方法を示しています。当社のバックエンドWebアプリケーションは、ポート80で公開されているバックエンド1とバックエンド2の2つのサービスで構成されています。サービスごとに複数のアプリケーションインスタンスからなるAuto Scalingグループがあります。ロードバランサは、リクエストURIに基づいてクライアントのリクエストを適切なバックエンドにルーティングします。

  • / backend-oneへのリクエストは、バックエンド1に行きます。
  • / backend-twoのリクエストは、バックエンド2に行きます。

アプリケーションのAuto Scalingグループを(自動または手動で)スケールするときは、新しいアプリケーションインスタンス数を反映するようにロードバランサの設定を更新する必要があります。AWSサービスのロードバランサはこれを自動的に行います。NGINX Plusでは、上記の方法(ELBの前にNGINX Plus、統合ソフトウェアでNGINX Plus)のいずれかを使用して、スケーリングイベントを構成に伝播する必要があります。

スケーリングイベントにレスポンスしてNGINX Plusの設定を更新する別の方法は、外部のサービスレジストリを使用することです。NGINX Plusは、ConsulなどのDNSインターフェイスを提供するサービス検出システムとの統合をサポートしています。このブログ記事では、外部システムの利用に頼らず、セットアップと利用が
簡単なソリューションに焦点を当てています。

ELBの前でNGINX Plusを使用する

Auto ScalingグループとELBをすでに使用している場合は、図に示すように、NGINX Plusの高度な機能をアプリケーションに取り込む最も簡単な方法は、
NGINX PlusをELBクラウドロードバランサの前に配置することです。

この場合、NGINX Plusは1つまたは複数のELBのプロキシ/ロードバランサとして機能します。高度なルーティング機能を使用して、NGINX PlusはリクエストURIに基づいて適切なELBにリクエストを転送します。その後、ELBは、Auto Scalingグループ内のインスタンスの1つにリクエストを渡します。この構成では、ELBはスケーリングのサポートを提供します。

ここにNGINX Plusの設定があります。

resolver 169.254.169.253 valid=10s;

upstream backend-one {
   zone backend-one 64k;
   server DNS-name-of-ELB-for-Backend-One resolve;
}

upstream backend-two {
   zone backend-two 64k;
   server DNS-name-of-ELB-for-Backend-Two resolve;
}

server {
   listen 80;

   location /backend-one {
       proxy_set_header Host $host;
       proxy_pass http://backend-one;
   }

   location /backend-two {
       proxy_set_header Host $host;
       proxy_pass http://backend-two;
   }
}

  • このresolverディレクティブは、NGINX Plusが内部ELBインスタンスのDNS名を解決するために使用するDNSサーバを定義します。ここでは、AWS DNSサーバのIPアドレスです。
  • 2つのupstreamブロックを作成します。1つは、サービスに対応する自動スケーリンググループごとに1つ、バックエンド1とバックエンド2です。Auto Scalingグループは、トラフィックを負荷分散するELBのDNS名で識別します。
  • このresolveパラメータを使用して、名前を定期的に再解決するようにNGINX Plusに指示します。頻度は、前項で説明したリゾルバ指示に有効なパラメータによって設定されます。 ここでは、ELBのIPアドレスが頻繁に変更されるため、10秒に設定します。
  • zoneディレクティブは解決されたIPアドレスを格納する(ここでは64キロバイトまで)のメモリを割り当てます。
  • serverポート80でリッスンする仮想サーバを定義します。locationブロックは、NGINX Plusに、バックエンド1 Auto ScalingグループのELBに/バックエンド1のリクエストを渡し、バックエンド2 Auto ScalingグループのELBに/バックエンド2をリクエストします。

ご覧のとおり、特にELBを既に使用している場合は、この方法をセットアップして使用するのが簡単です。ただし、いくつかの欠点があります。

  • 制限されたロードバランシングオプション。NGINX Plusはリクエストをバックエンドインスタンスに直接渡すのではなくELBに渡すので、ロードバランシングを実行しているのはELBです。このため、NGINX Plusのより洗練されたロードバランシングアルゴリズムやセッションパーシステンスオプションを利用することはできません。
  • 冗長性。NGINX Plusはロードバランシングを行うことができるので、ELBは冗長化されています。これは、Auto Scalingとネイティブに統合されているためです。
  • 限られたプロトコルのサポート。NGINX Plusとは異なり、ELBはWebSocketとUDPをサポートしていません。

次の方法はELBに依存せず、結果としてこれらの欠点もありません。

統合ソフトウェア(nginx-asg-sync)でのNGINX Plusの使用

この方法では、NGINX Plusとともに追加の統合ソフトウェア(nginx-asg-sync)をインストールします。ソフトウェア(nginx-asg-sync)はAuto Scalingグループを常に監視します。スケーリングイベントが発生したことを確認すると、バックエンドインスタンスをNGINX Plus設定に追加または削除します。図に示すように、nginx-asg-syncは、AW​​S Auto Scaling APIを使用してAuto Scalingグループの変更について学習します。

統合ソフトウェアを使用するには、以下のステップを実行します。

  1. AWS APIへのアクセスを設定する
  2. 統合ソフトウェアをインストールする
  3. NGINX Plusを設定する
  4. 統合ソフトウェアの設定

この手順では、バックエンドのAuto Scalingグループがすでに存在することを前提としています。これらはまた、NGINX PlusがAmazon Linux AMI上で動作していると仮定します。

ステップ1 – AWS APIへのアクセスを設定する

Auto Scaling APIとの通信は認証されるので、nginx-asg-syncの認証情報を提供する必要があります。AWSはIAMロールを使用して資格情報を処理するので、起動する前にNGINX Plusインスタンスのロールを作成する必要があります。段階的な手順については、AW​​SドキュメントのAmazon EC2のIAMロールを参照してください。

  1. IAMロールを作成し、定義済みのAmazonEC2ReadOnlyAccessポリシーをそのロールに添付します。このポリシーは、EC2 APIへの読み取り専用アクセスを許可します。
  2. NGINX Plusインスタンスを起動するときに、このIAMロールをインスタンスに追加します。

ステップ2 – 統合ソフトウェア(nginx-asg-sync)を
インストールする

統合ソフトウェア(nginx-asg-sync)をインストールするには、オペレーティングシステム用のパッケージをnginx-asg-sync GitHubリポジトリからダウンロードし、NGINX Plusが実行されているインスタンスにインストールします。

  • Amazon Linux、CentOS、およびRHELの場合:
  • $ sudo rpm -i package-name.rpm
  • Ubuntuの場合:
  • $ sudo dpkg -i package-name.deb

完全なインストール手順については、GitHub のドキュメントを参照してください。

ステップ3 – NGINX Plusを設定する

統合ソフトウェア(nginx-asg-sync)は、オンザフライの再構成およびライブアクティビティモニタリング API を使用してNGINX Plusの設定を更新します。ソフトウェアが正常に動作するためには、これらのAPIを設定し、必要な上流グループを宣言する必要があります。

  • オンザフライでの再構成とライブアクティビティの監視のためのAPIエンドポイントを設定します。統合ソフトウェアは、これらのエンドポイントを使用して、上流グループからバックエンドインスタンスを追加および削除します。
  • upstream Auto Scalingグループごとにブロックを作成します。※nginx-asg-syncはスケーリングイベントに応じて自動的に追加したり
     削除したりするので、ブロック内にサーバを定義しないでください。

次の例は、シンプルなWebアプリケーションの構成を表しています。

upstream backend-one {
   zone backend-one 64k;
   state /var/lib/nginx/state/backend-one.conf;
}

upstream backend-two {
   zone backend-two 64k;
   state /var/lib/nginx/state/backend-two.conf;
}

server {
   listen 80;

   status_zone backend;

   location /backend-one {
       proxy_set_header Host $host;
       proxy_pass http://backend-one;
   }

   location /backend-two {
       proxy_set_header Host $host;
       proxy_pass http://backend-two;
   }
}

server {
   listen 8080;

   root /usr/share/nginx/html;

   location = / {
       return 302 /status.html;
   }

   location = /status.html {}

   location /status {
       access_log off;
       status;
   }

   location /upstream_conf {
       upstream_conf;
   }
}

  • ELBの例では、Auto Scalingグループに対応する2つの上流グループ(バックエンド1バックエンド 2)を宣言しています。ただし、nginx-aws-syncによってサーバーが追加されるため、ここでは上流グループにサーバーを追加しません。このstateディレクティブは、動的に構成可能なサーバーのリストが格納されているファイルの名前を指定し、NGINX Plusの再起動後も運用を持続できるようにします。
  • serverポート80でリッスンする仮想サーバを定義します。ELBの例とは対照的に、NGINX Plusは/ backend-oneの リクエストをバックエンド1グループのインスタンスに直接渡し、/ backend-twoを直接2つのグループのバックエンドインスタンスににリクエストします。
  • 2番目の仮想サーバーはポート8080でリッスンし、NGINX Plus APIを構成します。
    • オンザフライAPIは、127.0.0.1:8080 / upstream_confにあります。
    • status APIは127.0.0.1:8080/statusにあります

ステップ4 – 統合ソフトウェア(nginx-asg-sync)を設定する

統合ソフトウェアは、/ etc / nginxフォルダーのaws.yamlファイルで構成されています。アプリケーションの場合、次の構成を定義します。

region: us-west-2
upstream_conf_endpoint: http://127.0.0.1:8080/upstream_conf
status_endpoint: http://127.0.0.1:8080/status
sync_interval_in_seconds: 5
upstreams:
– name: backend-one
  autoscaling_group: backend-one-group
  port: 80
  kind: http
– name: backend-two
  autoscaling_group: backend-two-group
  port: 80
  kind: http

  • このregionキーは、アプリケーションを配備するAWSリージョンを定義します。
  • upstream_conf_endpointそしてstatus_endpointキーはステップ3で設定されたnginxのプラスAPIエンドポイントで定義します。
  • このsync_interval_in_secondsキーは同期間隔を定義します。nginx-asg-syncは、5秒ごとに更新をスケーリングします。
  • このupstreamsキーは、上流グループのリストを定義します。
    上流グループごとに以下を指定します。

    • name – ステップ3のupstreamブロックで指定した名前。
    • autoscaling_group – 対応するAuto Scalingグループの名前。
    • port – バックエンドサービスが公開されているポート。
    • kind – トラフィックNGINX Plusのプロトコルは、httpのバックエンドアプリケーションへの負荷分散を行います。 アプリケーションがTCP / UDPを使用する場合は、代わりにstreamを指定してください。

aws.yamlファイルを編集した後、ソフトウェアを再起動します。

$ sudo restart nginx-asg-sync

ロードバランシングとスケーリングのテスト

上記の手順では、アプリケーション用のAuto Scalingグループの負荷分散をNGINX Plusに設定しました。これでテストが出来ます。NGINX Plusは/ backend-one URIを持つリクエストをバックエンド1グループのインスタンスに配布し、/ backend-2 URIを使用してバックエンド2グループのインスタンスにリクエストします。

Auto Scalingグループの規模を拡大すると、NGINX Plusがどのように新しいインスタンスを取得するのかがわかります。まず、NGINX Plusインスタンスのポート8080の/status.htmlにあるライブアクティビティ監視ダッシュボードにアクセスします。[Upstream]タブでは、Auto Scalingグループのインスタンスが表示されます。

次に、Auto Scalingグループの容量を変更して、バックエンド1グループを3つから5つに拡大します。新しいインスタンスが起動されると、nginx-asg-syncはそれらをNGINX Plus設定に追加します。間もなく、新しいインスタンスがダッシュボードに表示されます。

NGINX Plusの高可用性化

これまでのところ、NGINX Plusのインスタンスは1つだけです。ただし、高可用性のためには、NGINX Plus自体のAuto Scalingグループを作成し、NGINX Plusインスタンスの前でELBを使用することをお勧めします。ELBの代わりに、Route 53を使用してトラフィックをNGINX Plusインスタンスにルーティングできます。ELBによる配備の図は次のようになります。

正しい方法を選択する

Auto Scalingグループの負荷分散のためにNGINX Plusを設定する方法はどれですか?表は、2つを簡単に比較しています:

 

 

ELBの前にNGINX Plusを配置して
利用

NGINX Plusと統合ソフトウェアを利用

利点

シンプルな構成と追加のソフトウェアのインストールは不要です。

ELBメソッドによる制限なしで、すべてのNGINX Plus
機能が利用出来ます。

短所

サポートされているプロトコルを含め、使用できるNGINX Plusの機能の数を制限されます。ランニングコストと待ち時間が増加します。

統合ソフトウェアのインストールと構成が必要です。

概要

欠点が許容できる場合は、この方法を使用してください。

NGINX Plusの機能を最大限に活用するには、この方法を使用します。

概要

AWS Auto Scalingは、アプリケーションインスタンスの数をリクエストレベルに合わせて調整できるという利点があります。NGINX Plusは、AWS Auto Scalingグループと共に使用できる高度なロードバランシング機能を提供します。

AWS Auto ScalingグループでNGINX Plusを試してみてください。無料の30日間のトライアルを今すぐ開始するか、デモをご希望の場合はお問い合わせください

第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

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

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

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