NGINX Plus

第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日間のトライアルを開始するか、私たちにご連絡ください

ホワイトペーパー「ロードバランシングをソフトウェアに切り替える 5つの理由」

現代のITインフラ担当者は、ベアメタル、クラウド、コンテナなど様々な環境が混在する中、急激なトラフィックの増加やアプリケーションの迅速な展開といったWebサービスの課題に頭を悩ませています。Webの先進的な企業では、ハードウェアベースのアプリケーション デリバリー コントローラー(ADC)から、ソフトウェアベースのWebサーバーやロードバランサー、キャッシュサーバーに移行することでこの課題を解決しています。


現代のITシステムが求める高い柔軟性やスピード、コストパフォーマンスを満たすには、ソフトウェアが圧倒的に優位です。 このebookでは、IT責任者、ネットワーク担当者、アプリケーション開発者が、ハードウェアADCからソフトウェアソリューションに移行することで得られるメリットと優位性、ビジネスへの影響について、以下の5つの観点から解説します。


■目次■

1. 機能や性能を損なうことなくコストを劇的に削減します 

2. DevOpsへの移行にはソフトウェアベースのアプリケーションデリバリーが必要です

3. 1つのADCソリューションで、ベアメタル、クラウド、コンテナなど、どこにでも展開します 

4. アプリケーションへのニーズの変化に素早く対応します 

5. 性能に対して、意図的に制限を課したり、契約で制限を設けたりすることはありません


ダウンロード

コメントを残す

*