さまざまな用途・環境で使われるNGINX――マルチクラウドにはKubernetesで環境を共通化
NGINXはさまざまなLinuxサーバーにインストール可能で、オープンソースの構成管理ツールAnsibleを使ったインストールの自動化にも対応。また、GitHubにはそのロールが公開されている。
NGINXの環境をDocker化して、自分のPCをはじめ、クラウドのテスト環境、本番環境などさまざまな場所に展開できる。Docker向けに作成したコンテナを公開するDocker Hubにも公式イメージがアップされており、公式のDockerfileも公開されている。
また、開発において、コードをコミットして、JenkinsやGitLabなどでテストをしたあと、ステージングや本番に反映していくといった、一連のCI/CDの局面でも何らかの形でNGINXは関わってくる。
「NGINXをアプリケーションサーバー側で使う場合もあれば、その手前にNGINXを置いてリバースプロキシとして使う場合もあるでしょう。商用版ならセキュリティを高める認証やWebアプリケーションファイアウォールなど高度な機能やサポートも提供可能です。キャッシュの機能もあるので、CSSやjsファイル、写真や動画をキャッシュして、一番近いところからアクセスしてもらうことも可能です」と鈴木氏は述べ、身近な例として、Netflixの動画配信ワークロードについて触れた。
さらに鈴木氏は、NGINXが広く採用される理由として、競合サービスと比較すると同時接続処理やメモリ使用量が優れていることや、商用版は帯域幅やvCPUによるライセンスや制限がないことを説明。加えて、AWS環境やAzure環境でのオートスケールにも対応したツールも公開されており、これを使ってリバースプロキシのバックエンドを自動的に追加する仕組みを構築できるとした。
最近のアプリケーション提供環境として、パブリッククラウドやベアメタルサーバーでのバーチャルマシン以外に、Kubernetesなどのコンテナプラットフォームの利用が進んでいる。Kubernetesの環境においても、「NGINX Ingress Controller」を使うことでNGINXにて外部からのアクセスを制御できるようになる。GCPには、Google Kubernetes Engine（GKE）でのNGINX Ingress Controllerのコミュニティドキュメントが公開されている。
鈴木氏は「GKEの標準ではL7のロードバランサーが起動しますが、NGINXのパラメーターをつけると、L4のロードバランサーが設定され、L7が担う処理はNGINXにおまかせする仕組みを構築できます。TCPとUDPはクラクラウド側のL4、そのあとのドメインやパスの制御についてはNGINX Ingress Controllerを通して設定できるようになります」と説明した。
AzureでもKubernetesの環境を作ると同様にロードバランサーが作られ、その後の処理はNGINXに任せられるようになる。
- Azure Kubernetes Service (AKS) でイングレス コントローラーを作成する
- How Kubernetes Ingress and LoadBalancer resources work together
このように、URLやホストなどによって、本番やテスト環境、異なるバージョンのアプリケーションなど、Kubernetes内のPodにあるサービスへのルーティングを設定できる。
鈴木氏はユーザーコミュニティのイベント「F5/NGINX Community！」で披露されたカカクコムの利用例について触れ「オンプレミスのKubernetes環境でドメインやパスの振り分けに利用されています。アノテーションの中に『server-snippets, location-snippets』というものがあり、これにすでにお持ちのNGINXの設定をserver/locationブロックに適用して利用されています」と説明した。
さまざまな条件による外部通信の制御にはNGINX Ingress Controllerを活用
NGINX Ingress ControllerではHTTP、gRPC、WebSocketのリバースプロキシを同時に設定可能で、HTMLヘッダーやコンテンツの中身をチェックする「Active Health Checks」機構も利用できる。加えて、アプリケーションごとにJWT・OpenIDベースの認証機能を持たせることも可能だ。
また、アプリケーションの新しいバージョンがKubernetes環境に、旧バージョンがAWS環境にあり、それぞれを区別して振り分けたい場合など、NGINX Ingress ControllerのExternalNameという設定を利用して実現できる。
「組織によってGCPを使う部署、AWSを使う部署、Azure環境を使う部署がそれぞれ存在する場合もあるでしょう。ExternalNameを使えばうまくルーティングの制御ができます。コンピューターパワーが必要な場面など、データセンターの物理環境にも振り分けが可能です。新しいバージョンをリリースする際、まずは1割の人だけに新バージョンにアクセスさせてエラー率やバグを見るようなweightの設定もできます」と鈴木氏。
さらに、マルチクラウドやオンプレミス環境に設置したAPIもNGINX Controller 3.0を活用することで管理ができる。各環境にエージェントを設置してControllerからURLリライトやレート制限、端末ごとの認証・制限などの設定、管理を可能にする仕組みだ。
続いて鈴木氏は、監視運用という視点でのNGINX活用についての説明に移った。NGINXはインフラ・サービス監視ツールの「Prometheus」のインテグレーションもあるので、そこでログを取得・監視することもできる。「F5/NGINX Community！」のイベントでは、NGINXにて処理中コネクション数のメトリクスを利用してPrometheusで監視したログを、Kubernetes環境にあるPodのオートスケーリングの指標にした、ウォンテッドリーの事例が発表された。
「アプリケーションがどのように使われているか、レスポンスタイムはどれくらいか、といった状態を把握する際にも使えます。Datadogなどのエージェントにも対応しているので、簡単に2～3行の設定をすると、グラフィカルなダッシュボードで監視可能です。複数台の合計値や平均値なども見ることができ、NGINX Controllerから好みのパラメーターを取り出してオリジナルのダッシュボードに展開することも可能です」と鈴木氏は話す。
NGINXの導入、活用方法、監視運用まで説明した鈴木氏はこのあと、先ほど紹介したExternalNameによる振り分けのデモンストレーションを実施した。
デモンストレーションは、GKE上に用意したKubernetesクラスターと、Amazon EC2インスタンスに置いたWebページを振り分けるもの。ExternalNameにはAWSのURLを指定する。「https://gke-v2.example.com/」はGKEへ、「https://aws-v2.example.com/」はAmazon EC2インスタンスに向ける設定で、5分ほどで設定が完了した。
さらにAzureのKubernetes環境における同様のデモンストレーションも行われた。
デモンストレーションについて鈴木氏は「サービスの実態はGKEに、ちょっと作って試したいものはAWSに置いておく場合にも使えます。AzureにもKubernetesサービスがあるので同じように設定できます。このようにKubernetesなら、NGINXの設定をうまく使うことで、マルチクラウド環境が手軽に利用可能です。振り分けたあとにBasic認証や、JWT認証の処理を入れることもできますよ」と解説を加え、セッションを締めくくった。
お問い合わせ
NGINX (Part of F5)
