ROSAでF5 NGINX Ingress Controlを配置する構成と利点

はじめに

前回、AWSのOpenShiftのサービスであるROSA with HCPを利用したシステムの構成とアーキテクチャを構築する上での注意点を示しました。今回は、ROSA with HCP周辺のネットワーク構成にフォーカスして、利用したサービスとサービスの組み合わせについて説明します。
本検証では、Private領域に配置したROSA上でコンテナアプリケーションを稼働させていて、インターネットからアクセス可能なWebアプリケーションとなっています。ROSA単体でもコンテナのWebアプリケーションは可能ですが、今回はいくつかのAWSサービスを組み合わせてネットワークを構成しています。

インターネットからVPCのPrivateサブネットへのアクセス経路の構成

インターネットからアプリケーションにアクセスするゲートウェイ部分は、AWSが提供するマネージドサービスを最大限活用しました。Amazon CloudFrontによるコンテンツ配信、AWS WAFによるウェブアプリケーションファイアウォール、AWS ShieldによるDDoS攻撃からの保護、Amazon API GatewayによるAPIエンドポイントの管理等、スケーラビリティやセキュリティを容易に確保できるような構成を採用しています。
API GatewayからPrivateサブネット上のサンプルWebアプリケーションに接続するためにAWS PrivateLinkを経由しています。

ROSA with HCP周辺リソース構成

ROSA with HCP内のリソース配置について説明します。コンテナアプリケーションは、Deploymentの定義に基づき、ROSA with HCPの外にあるECRからコンテナイメージを取得し、Podとして起動させています。
KubernetesにおいてPodの集合（アプリケーション）にアクセスする際は、通常、その前段に配置された「Service」を経由してアクセスします。これは、PodのIPが動的に変わるため、安定したエンドポイントとしてServiceを用いるのが一般的だからです。ROSA with HCP環境において、外部からKubernetesクラスタ内のServiceへアクセスするには、NLB, ALB, Ingress, LoadBalancer Service など複数の選択肢があります。その中で今回は、F5 NGINX Ingress Controllerを使用する構成を採用しました。
ROSA with HCPでIngressを作成するとIngressClassやコントローラの実装に応じて、AWSのElastic Load Balancing (ELB) の一種であるNetwork Load Balancer（NLB）がプロビジョニングされることが一般的です。F5 NGINX Ingress Controllerを使用する場合は、AWSのNLBやALBと併用し、Ingress Controller（NGINX）をKubernetesクラスタ内にDeploymentやDaemonSetとしてデプロイします。この構成により、外部からのアクセスをNLB経由で受け取り、NGINXを通じてクラスタ内の各サービスにルーティングする構成が一般的です。本構成は次の通りです。

F5 NGINX Ingress Controllerを配置する利点

レイヤ4（TCP/UDP）ベースの通信に対しては、AWSが提供するNLBを利用することで、シンプルかつ高性能な負荷分散が可能です。一方で、HTTPやHTTPSといったレイヤ7（アプリケーション層）の通信において、より細かなルーティングや制御が必要な場合には、F5が提供するNGINX Ingress ControllerのようなL7対応のIngress Controllerを利用するのが有効です。NGINX Ingress Controllerは、KubernetesやOpenShift環境において広く利用されているオープンソースソフトウェア（OSS）であり、ホスト名やパスに応じたルーティング、パスのリライト（書き換え）、TLS終端、リクエスト制御など、アプリケーション層での柔軟なトラフィック制御が可能です。また、1つのIngress Controllerで複数のNamespace（OpenShiftにおけるプロジェクト）へのルーティングも設定できるため、マルチテナント環境にも適しています。具体的には、次のような利点が挙げられます。

• 高度なルーティング機能

  • パスベース、ホストベースのルーティングが可能になります。例えば、/apiはサービスAへ、/webはサービスBへという制御が可能です。
  • カスタムヘッダ、クッキーなどの属性に基づいたルーティングが可能です。

• 柔軟なTLS/SSL終端

  • 複数のSNI対応証明書を扱えます。
  • 無料の TLS 証明書を提供する認証局「Let's Encrypt」との統合やACMEプロトコルでの自動証明書管理が可能です。

• レートリミットやWAFの拡張性

  • F5版やPlus版のNGINXではWAF機能（ModSecurity連携）やレートリミット機能が利用できます。
  • セキュリティポリシーをきめ細かく定義できます。

• PodやServiceの疎結合化

  • KubernetesやOpenShift内部の変更（Podのスケーリングや再起動など）をIngressが吸収するため、外部との結合度を下げられます。
  • アプリ側の変更をIngress設定だけで反映が可能です。

• カスタムリクエスト制御

  • C言語と組み合わせることが多い、軽量で高速なLuaスクリプトや設定で柔軟に対応できます。

本検証で、F5 NGINX Ingress ControllerをOpenShiftのリソースとしてデプロイするために使用していたマニフェストから、該当部分を抜粋します。

sample.yaml

apiVersion: charts.nginx.org/v1alpha1
kind: NginxIngress
metadata:
  name: nginx-ingress
  namespace: nginx-ingress
spec:
  controller:
    image:
      pullPolicy: IfNotPresent
      repository: nginx/nginx-ingress
      tag: 3.4-ubi
    ingressClass:
      name: nginx
    kind: deployment
    nginxplus: false
    replicaCount: 3
    serviceAccount:
      imagePullSecretName: ""
    service:
      type: LoadBalancer
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: nlb
        service.beta.kubernetes.io/aws-load-balancer-internal: "true"
        service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: red-hat-managed=true,NLBName=${NLB_NAME}
...

F5 NGINX Ingress Controller を導入する際の主な技術的注意点は以下の通りです。

• スケーラビリティの確保
  NGINXはアプリケーション層（L7）でリクエストを処理するため、トラフィックが増加するとボトルネックになる可能性があります。これに対応するためには、Horizontal Pod Autoscaler（HPA）による自動スケーリングの設定や、DaemonSetで各ノードに常駐させて分散配置する構成が検討されます。ワークロードの特性やトラフィックパターンに応じて使い分けが必要です。トラフィックの変動に応じてスケールさせた場合HPAを使用します。CPUやリクエスト数に基いて、自動的にPodのレプリカ数を増減させ、クラスタ内で効率的に分散処理を行えます。クラスタノード毎にIngressを必ず立てたい場合、DaemonSetを使用して、すべてのノードに NGINX Ingress Controller を配置します。各ノードでIngressが動作し、ノード毎のローカル通信により低レイテンシーの応答が期待できます。NLBと組み合わせる場合、ターゲットグループに全ノード（または各ノード上のPodのIP）を登録する必要があります。小規模な構成や開発環境の場合、Deploymentのみで固定数のレプリカを定義するシンプルな構成が適しています。スケーリング要件が少ない場合に有効です。

• 証明書の自動管理
  Let's Encrypt などの無料証明書を自動で取得・更新するために、cert-manager と ACME プロトコルを統合するのが一般的です。これにより、TLS証明書の運用負荷を大幅に軽減できます。

• ログの可視化と監視連携
  NGINX のアクセスログやエラーログは、運用上重要な情報源となります。これらを ELK スタックや Datadog などのモニタリング基盤に連携させることで、トラフィック状況や障害の兆候をリアルタイムで把握できます。

• ヘルスチェックの設定
  AWSのNLBはデフォルトでTCPレベルのヘルスチェックを使用します。そのため、NGINXがリッスンしているポートがTCPレベルで正しく応答している必要があります。HTTPやHTTPSレベルでのより詳細なチェックを行いたい場合は、NLBのターゲットグループ設定を調整する必要があります。

F5 NGINX Ingress Controllerを配置することで、アプリケーションレベルのルーティング、セキュリティ強化、運用の柔軟性など多くのメリットがあります。一方で、NGINX自体がL7処理を担うため、スケーラビリティやモニタリング、証明書のライフサイクル管理など、設計・運用面での工夫も必要です。