mobile background
NGINX Ingress/Gateway Fabric 에서 구현가능한 기술 / 사용사례 소개 61
프로필 이미지
관리자
2025-01-21
조회 13

처음으로 Kubernetes를 설정하는 많은 조직은 Kubernetes 커뮤니티에서 개발하고 유지 관리하는 NGINX Ingress 컨트롤러( kubernetes/ingress-nginx )로 시작합니다. 그러나 Kubernetes 배포가 성숙해짐에 따라 일부 조직은 NGINX를 데이터 플레인으로 유지하면서 고급 기능이 필요하거나 상업적 지원을 원한다는 것을 알게 됩니다.

한 가지 옵션은 F5 NGINX( nginxinc/kubernetes-ingress ) 가 개발하고 유지 관리하는 NGINX Ingress Controller로 마이그레이션하는 것입니다 . 여기서는 두 프로젝트 간의 차이로 인해 발생할 수 있는 몇 가지 복잡한 문제를 피할 수 있도록 전체적인 지침을 제공합니다.

이러한 옵션이 어떻게 다른지 잘 모르시겠습니까? 저희 블로그에서 Ingress Controller 선택 가이드, 4부: NGINX Ingress Controller 옵션을 읽어보세요.

이 게시물의 나머지 부분에서 두 프로젝트를 구별하기 위해 Kubernetes 커뮤니티( kubernetes/ingress-nginx )에서 유지 관리하는 NGINX Ingress Controller를 "커뮤니티 Ingress 컨트롤러"라고 하고 F5 NGINX( nginxinc/kubernetes-ingress )에서 유지 관리하는 NGINX Ingress 컨트롤러를 "NGINX Ingress 컨트롤러"라고 합니다.

커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션하는 방법에는 두 가지가 있습니다.

  • 옵션 1: NGINX Ingress 리소스를 사용하여 마이그레이션하기
    이는 최적의 솔루션입니다. NGINX Ingress 리소스는 프로덕션 등급 Kubernetes 환경에 필요한 광범위한 Ingress 네트워킹 기능을 지원하기 때문입니다. NGINX Ingress 리소스에 대한 자세한 내용은 NGINX Ingress Controlle r을 사용한 고급 Kubernetes 배포 웨비나를 시청하세요 .
  • 옵션 2: Kubernetes Ingress 리소스를 사용하여 마이그레이션
    이 옵션은 표준 Kubernetes Ingress 리소스를 사용하여 Ingress 부하 분산 규칙을 정의하려는 경우 권장됩니다.


옵션 1: NGINX Ingress 리소스를 사용하여 마이그레이션

이 마이그레이션 옵션을 사용하면 표준 Kubernetes Ingress 리소스를 사용하여 루트 기능을 설정하고 NGINX Ingress 리소스를 사용 하여 구성을 개선하여 기능을 향상시키고 사용 편의성을 높일 수 있습니다.

NGINX Ingress 리소스( VirtualServer, VirtualServerRoute , TransportServer , GlobalConfiguration 및 Policy ) 에 대한 사용자 정의 리소스 정의(CRD)를  사용하면 구성의 다양한 부분에 대한 제어를 다양한 팀(예: AppDev 및 보안 팀)에 쉽게 위임할 수 있으며, 구성 안전성과 유효성 검사도 더욱 강화할 수 있습니다.


SSL 종료 및 HTTP 경로 기반 라우팅 구성

spec이 표는 표준 Kubernetes Ingress 리소스의 필드 에 있는 SSL 종료 및 Layer 7 경로 기반 라우팅 구성을 specNGINX VirtualServer 리소스의 필드와 매핑합니다. 두 리소스의 구문과 들여쓰기는 약간 다르지만 동일한 기본 Ingress 기능을 수행합니다.


* 표 내용 

 -  쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스

apiVersion: networking.k8s.io/v1kind: Ingress
metadata:
  name: nginx-test
spec:
  tls:
    - hosts:
      - foo.bar.com
      secretName: tls-secret
  rules:
    - host: foo.bar.com
      http:
        paths:
        - path: /login
          backend: 
            serviceName: login-svc
            servicePort: 80
        - path: /billing
            serviceName: billing-svc
            servicePort: 80
apiVersion: networking.k8s.io/v1kind: VirtualServer
metadata:
  name: nginx-test
spec:
  host: foo.bar.com 
  tls:
    secret: tls-secret
  upstreams:
    - name: login
      service: login-svc
      port: 80
    - name: billing 
      service: billing-svc
      port: 80
  routes: 
  - path: /login
    action:
      pass: login 
  - path: /billing 
    action: 
      pass: billing

TCP/UDP 부하 분산 및 TLS 패스스루 구성

커뮤니티 Ingress 컨트롤러를 사용하면 Kubernetes ConfigMap API 객체가 TCP 및 UDP 서비스를 노출하는 유일한 방법 입니다 .

NGINX Ingress Controller를 사용하면 TransportServer 리소스는 TCP/UDP 및 TLS Passthrough 로드 밸런싱을 위한 광범위한 옵션을 정의합니다. TransportServer 리소스는 GlobalConfiguration 리소스와 함께 사용되어 인바운드 및 아웃바운드 연결을 제어합니다.

자세한 내용은 블로그의 NGINX Ingress 리소스에서 TCP, UDP 및 TLS 패스스루 서비스 지원을 참조하세요.


커뮤니티 Ingress 컨트롤러 주석을 NGINX Ingress 리소스로 변환

프로덕션 수준의 Kubernetes 배포에서는 카나리아 및 블루그린 배포, 트래픽 제한, 인그레스-이그레스 트래픽 조작 등을 포함한 고급 사용 사례를 구현하기 위해 기본 Ingress 규칙을 확장해야 하는 경우가 많습니다.

커뮤니티 Ingress 컨트롤러는 Kubernetes 주석 으로 이러한 사용 사례 중 많은 부분을 구현합니다 . 그러나 이러한 주석 중 많은 부분은 매우 구체적인 NGINX Ingress 리소스 정의와 관련된 사용자 지정 Lua 확장으로 빌드되었으며 결과적으로 안정적이고 지원되는 프로덕션 환경에서 고급 기능을 구현하는 데 적합하지 않습니다.

다음 섹션에서는 커뮤니티 Ingress 컨트롤러 주석을 NGINX Ingress 컨트롤러 리소스로 변환하는 방법을 보여줍니다.

  • 카나리아 배포
  • 교통 통제
  • 헤더 조작
  • 프록싱 및 로드 밸런싱
  • mTLS 인증
  • 세션 지속성(NGINX Plus 전용)


카나리아 배포

프로덕션 컨테이너 워크로드에 빈번한 코드 변경을 푸시하더라도 기존 사용자에게는 계속 서비스를 제공해야 합니다. Canary 및 Blue‑Green 배포를 통해 이를 수행할 수 있으며, NGINX Ingress Controller 데이터 플레인에서 이를 수행하여 프로덕션 등급 Kubernetes 환경에서 안정적이고 예측 가능한 업데이트를 달성할 수 있습니다.

이 표는 카나리아 배포를 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 의 필드를 보여줍니다 .

커뮤니티 Ingress 컨트롤러는 다음 우선순위에 따라 카나리아 주석을 평가합니다.

  1. nginx.ingress.kubernetes.io/canary-by-header
  2. nginx.ingress.kubernetes.io/canary-by-cookie
  3. nginx.ingress.kubernetes.io/canary-by-weight

NGINX Ingress Controller가 이를 동일한 방식으로 평가하려면 NGINX VirtualServer 또는 VirtualServerRoute 매니페스트에 해당 순서대로 나타나야 합니다


* 표 내용 

 -  쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스

nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"
matches:- conditions:
  - header: httpHeader
      value: never
  action:
    pass: echo 
  - header: httpHeader
      value: always
  action:
    pass: echo-canary
action:
  pass: echo
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"
nginx.ingress.kubernetes.io/canary-by-header-value: "my-value"
matches:- conditions:
  - header: httpHeader
      value: my-value
  action:
    pass: echo-canary 
action:
  pass: echo
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-cookie: "cookieName"
matches:- conditions:
  - cookie: cookieName
      value: never
  action:
    pass: echo 
  - cookie: cookieName
      value: always
  action:
    pass: echo-canary
action:
  pass: echo
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-weight: "10"
splits:- weight: 90 
  action:
    pass: echo
- weight: 10 
   action:
     pass: echo-canary

교통 통제

애플리케이션이 본질적으로 일시적이어서 오류 응답을 반환할 가능성이 더 높은 마이크로서비스 환경에서 DevOps 팀은 회로 차단 및 속도 및 연결 제한과 같은 트래픽 제어 정책을 광범위하게 사용하여 애플리케이션이 정상적이지 않거나 예상대로 작동하지 않을 때 오류 조건이 발생하지 않도록 합니다.

이 표에서는 속도 제한 , 사용자 정의 HTTP 오류 , 사용자 정의 기본 백엔드 및 URI 재작성을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 의 필드를 보여줍니다 .


* 표 내용 

 -  쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스

nginx.ingress.kubernetes.io/custom-http-errors: "code"

nginx.ingress.kubernetes.io/default-backend: "default-svc"
errorPages:- codes: [code]
    redirect:
      code: 301
      url: default-svc
nginx.ingress.kubernetes.io/limit-connections: "number"
http-snippets: |    limit_conn_zone $binary_remote_addr zone=zone_name:size;
routes:
- path: /path
    location-snippets: |
      limit_conn zone_name number;
nginx.ingress.kubernetes.io/limit-rate: "number"
nginx.ingress.kubernetes.io/limit-rate-after: "number"
location-snippets: |    limit_rate number;

    limit_rate_after number;
nginx.ingress.kubernetes.io/limit-rpm: "number"
nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier"
rateLimit:    rate: numberr/m

    burst: number * multiplier
    key: ${binary_remote_addr}
    zoneSize: size
nginx.ingress.kubernetes.io/limit-rps: "number"
nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier"
rateLimit:    rate: numberr/s

    burst: number * multiplier
    key: ${binary_remote_addr}
    zoneSize: size
nginx.ingress.kubernetes.io/limit-whitelist: "CIDR"
http-snippets: |
server-snippets: |
nginx.ingress.kubernetes.io/rewrite-target: "URI"
rewritePath: "URI"

표에 표시된 대로, 이 글을 쓰는 시점에서 NGINX Ingress 리소스에는 다음 네 가지 커뮤니티 Ingress 컨트롤러 주석을 직접 변환하는 필드가 포함되어 있지 않으며, 스니펫을 사용해야 합니다. Policy 리소스를 사용하여 네 가지 주석에 대한 직접 지원은 NGINX Ingress Controller의 향후 릴리스에서 계획되어 있습니다.

  • nginx.ingress.kubernetes.io/limit-connections
  • nginx.ingress.kubernetes.io/limit-rate
  • nginx.ingress.kubernetes.io/limit-rate-after
  • nginx.ingress.kubernetes.io/limit-whitelist

헤더 조작

HTTP 헤더를 조작하는 것은 많은 사용 사례에서 유용합니다. 왜냐하면 HTTP 트랜잭션에 관련된 시스템에 중요하고 관련성 있는 추가 정보가 포함되어 있기 때문입니다. 예를 들어, 커뮤니티 Ingress 컨트롤러는 AJAX 애플리케이션에서 사용되는 CORS( 크로스 오리진 리소스 공유 ) 헤더를 활성화하고 설정하는 것을 지원하는데, 여기서 브라우저의 프런트엔드 JavaScript 코드가 백엔드 앱이나 웹 서버에 연결됩니다.

이 표는 헤더 조작을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 의 필드를 보여줍니다 .


* 표 내용 

 -  쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스

nginx.ingress.kubernetes.io/enable-cors: "true"nginx.ingress.kubernetes.io/cors-allow-credentials: "true"

nginx.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For" 

nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS"

nginx.ingress.kubernetes.io/cors-allow-origin: "*"

nginx.ingress.kubernetes.io/cors-max-age: "seconds"
responseHeaders:  add: 
    - name: Access-Control-Allow-Credentials
      value: "true" 
    - name: Access-Control-Allow-Headers
      value: "X-Forwarded-For"
    - name: Access-Control-Allow-Methods
      value: "PUT, GET, POST, OPTIONS"
    - name: Access-Control-Allow-Origin
      value: "*"
    - name: Access-Control-Max-Age
      value: "seconds"

프록싱 및 로드 밸런싱

특정 사용 사례에 따라 NGINX Ingress Controller에서 구성하고 싶을 수 있는 다른 프록싱 및 로드 밸런싱 기능이 있습니다. 이러한 기능에는 프록시 연결에 대한 로드 밸런싱 알고리즘 설정과 타임아웃 및 버퍼링 설정이 포함됩니다.

이 표에서는 사용자 정의 NGINX 부하 분산 , 프록시 시간 초과 , 프록시 버퍼링 , 서비스의 클러스터 IP 주소 및 포트에 대한 라우팅 연결upstream 에 대한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 필드의 명령문을 보여줍니다 .


* 표 내용 

 -  쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스

nginx.ingress.kubernetes.io/load-balance
lb-method
nginx.ingress.kubernetes.io/proxy-buffering
buffering
nginx.ingress.kubernetes.io/proxy-buffers-numbernginx.ingress.kubernetes.io/proxy-buffer-size
buffers
nginx.ingress.kubernetes.io/proxy-connect-timeout
connect-timeout
nginx.ingress.kubernetes.io/proxy-next-upstream
next-upstream
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout
next-upstream-timeout
nginx.ingress.kubernetes.io/proxy-read-timeout
read-timeout
nginx.ingress.kubernetes.io/proxy-send-timeout
send-timeout
nginx.ingress.kubernetes.io/service-upstream
use-cluster-ip

mTLS 인증

서비스 메시는 클러스터 내부의 분산 애플리케이션이 상호 인증을 통해 안전하게 통신하는 엄격한 제로 트러스트 환경에서 특히 유용합니다. 클러스터에 들어오고 나가는 트래픽(북-남 트래픽)에 동일한 수준의 보안을 적용해야 하는 경우는 어떨까요?

외부 연결의 최종 시스템이 유효한 인증서를 제시하여 서로를 인증할 수 있도록 Ingress Controller 계층에서 mTLS 인증을 구성할 수 있습니다.

이 표는 클라이언트 인증서 인증 과 백엔드 인증서 인증을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX 정책 리소스 의 필드를 보여줍니다 .


* 표 내용 

 -  쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스

nginx.ingress.kubernetes.io/auth-tls-secret: secretName
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
ingressMTLS:   clientCertSecret: secretName
   verifyClient: "on"

   verifyDepth: 1
nginx.ingress.kubernetes.io/proxy-ssl-secret: "secretName"
nginx.ingress.kubernetes.io/proxy-ssl-verify: "on|off"
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "1"
nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2"
nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "DEFAULT"
nginx.ingress.kubernetes.io/proxy-ssl-name: "server-name"
nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on|off"
egressMTLS:   tlsSecret: secretName

   verifyServer: true|false

   verifyDepth: 1

   protocols: TLSv1.2

   ciphers: DEFAULT

   sslName: server-name

   serverName: true|false

세션 지속성(NGINX Plus 전용)

이 표는 NGINX Plus 기반 NGINX Ingress Controller에서만 사용되는 NGINX 정책 리소스 의 필드를 보여주며 , 세션 지속성 (친화성)을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당합니다.

커뮤니티 인그레스 컨트롤러NGINX Ingress 컨트롤러
nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "cookieName"
nginx.ingress.kubernetes.io/session-cookie-expires: "x"
nginx.ingress.kubernetes.io/session-cookie-path: "/route"
nginx.ingress.kubernetes.io/session-cookie-secure: "true"
sessionCookie:  enable: true

  name: cookieName

  expires: xh

  path: /route

  secure: true

옵션 2: Kubernetes Ingress 리소스를 사용하여 마이그레이션

커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션하는 두 번째 옵션은 표준 Kubernetes Ingress 리소스에서 주석 과 ConfigMap 만 사용 하고 잠재적으로 마스터/미니언 "‑스타일 처리에 의존하는 것입니다. 이렇게 하면 모든 구성이 Ingress 객체에 유지됩니다.

참고:spec 이 방법을 사용하는 경우 Ingress 리소스의 필드를 변경하지 마세요 .

주석이 있는 고급 구성

다음 표는 NGINX Ingress Controller에서 지원하는 주석에 직접 해당하는 커뮤니티 Ingress 컨트롤러 주석을 간략하게 설명합니다.


* 표 내용 

 -  쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스

nginx.ingress.kubernetes.io/configuration-snippet: |
nginx.org/location-snippets: |
없음
nginx.ingress.kubernetes.io/load-balance1
nginx.org/lb-method
기본:

 

random two least_conn
nginx.ingress.kubernetes.io/proxy-buffering: "on|off"
nginx.org/proxy-buffering: "True|False"
proxy_buffering
nginx.ingress.kubernetes.io/proxy-buffers-number: "number"nginx.ingress.kubernetes.io/proxy-buffer-size: "xk"
nginx.org/proxy-buffers: "number 4k|8k"nginx.org/proxy-buffer-size: "4k|8k"
proxy_buffers
proxy_buffer_size
nginx.ingress.kubernetes.io/proxy-connect-timeout: "seconds"
nginx.org/proxy-connect-timeout: : "secondss"
proxy_connect_timeout
nginx.ingress.kubernetes.io/proxy-read-timeout: "seconds"
nginx.org/proxy-read-timeout: "secondss"
proxy_read_timeout
nginx.ingress.kubernetes.io/proxy-send-timeout: "seconds"
nginx.org/proxy-send-timeout: "secondss"
proxy_send_timeout
nginx.ingress.kubernetes.io/rewrite-target: "URI"
nginx.org/rewrites: "serviceName=svc rewrite=URI"
rewrite
nginx.ingress.kubernetes.io/server-snippet: |
nginx.org/server-snippets: |
없음
nginx.ingress.kubernetes.io/ssl-redirect: "true|false"
ingress.kubernetes.io/ssl-redirect: "True|False"
없음 2

1 커뮤니티 Ingress 컨트롤러는 Lua를 사용하여 일부 부하 분산 알고리즘을 구현합니다. NGINX Ingress 컨트롤러는 모든 것에 대한 동등한 것이 없습니다.

2 HTTP 트래픽을 HTTPS로 리디렉션합니다. 커뮤니티 Ingress 컨트롤러는 Lua 코드로 이를 구현하는 반면 NGINX Ingress 컨트롤러는 기본 NGINX if조건을 사용합니다.

다음 표는 NGINX Plus 기반 NGINX Ingress Controller에서 지원하는 주석에 직접 해당하는 커뮤니티 Ingress 컨트롤러 주석을 간략하게 설명합니다.


* 표 내용 

 -  쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스

nginx.ingress.kubernetes.io/affinity: "cookie"nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name"
nginx.ingress.kubernetes.io/session-cookie-expires: "seconds"
nginx.ingress.kubernetes.io/session-cookie-path: "/route"
nginx.com/sticky-cookie-services: "serviceName=example-svc cookie_name expires=time path=/route"

참고: NGINX Plus 기반의 NGINX Ingress Controller에는 커뮤니티 Ingress 컨트롤러가 전혀 지원하지 않는 기능( 활성 상태 확인 , JSON 웹 토큰(JWT)을 사용한 인증 등)에 대한 추가 주석이 있습니다 .

ConfigMaps를 사용한 글로벌 구성

다음 표는 커뮤니티 Ingress 컨트롤러 ConfigMap 키를 직접 대응하는 NGINX Ingress 컨트롤러 ConfigMap 키에 매핑합니다. 소수의 ConfigMap 키 이름이 동일하다는 점에 유의하세요. 또한, 커뮤니티 Ingress 컨트롤러와 NGINX Ingress 컨트롤러는 모두 다른 컨트롤러에 없는 ConfigMaps 키를 가지고 있습니다(표에 표시되지 않음).


* 표 내용 

 -  쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스

disable-access-log
access-log-off
error-log-level
error-log-level
hsts
hsts
hsts-include-subdomains
hsts-include-subdomains
hsts-max-age
hsts-max-age
http-snippet
http-snippets
keep-alive
keepalive-timeout
keep-alive-requests
keepalive-requests
load-balance
lb-method
location-snippet
location-snippets
log-format-escape-json: "true"
log-format-escaping: "json"
log-format-stream
stream-log-format
log-format-upstream
log-format
main-snippet
main-snippets
max-worker-connections 
worker-connections
max-worker-open-files
worker-rlimit-nofile
proxy-body-size
client-max-body-size
proxy-buffering
proxy-buffering
proxy-buffers-number: "number"
proxy-buffer-size: "size"
proxy-buffers: number size
proxy-connect-timeout
proxy-connect-timeout
proxy-read-timeout
proxy-read-timeout
proxy-send-timeout
proxy-send-timeout
server-name-hash-bucket-size
server-names-hash-bucket-size
server-name-hash-max-size
server-names-hash-max-size
server-snippet
server-snippets
server-tokens
server-tokens
ssl-ciphers
ssl-ciphers
ssl-dh-param
ssl-dhparam-file
ssl-protocols
ssl-protocols
ssl-redirect
ssl-redirect
upstream-keepalive-connections
keepalive
use-http2
http2
use-proxy-protocol
proxy-protocol
variables-hash-bucket-size
variables-hash-bucket-size
worker-cpu-affinity
worker-cpu-affinity
worker-processes
worker-processes
worker-shutdown-timeout
worker-shutdown-timeout

요약

사용자 지정 NGINX Ingress 리소스 또는 주석 및 ConfigMaps가 있는 표준 Kubernetes Ingress 리소스를 사용하여 커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션할 수 있습니다. 이전 옵션은 더 광범위한 네트워킹 기능을 지원하므로 프로덕션 등급 Kubernetes 환경에 더 적합합니다.


프로필 이미지
관리자
2025-01-20
조회 2


마이크로서비스는 현재 많은 주목을 받고 있습니다. 기사, 블로그, 소셜 미디어 토론, 컨퍼런스 프레젠테이션. 이들은 Gartner Hype cycle 에서 과장된 기대의 정점으로 빠르게 향하고 있습니다 . 동시에, 소프트웨어 커뮤니티에는 마이크로서비스를 새로운 것이 아니라고 일축하는 회의론자들이 있습니다. 반대론자들은 이 아이디어가 SOA의 리브랜딩일 뿐이라고 주장합니다. 그러나 과대광고와 회의론에도 불구하고, 마이크로서비스 아키텍처 패턴은 상당한 이점을 가지고 있습니다  . 특히 복잡한 엔터프라이즈 애플리케이션의 민첩한 개발과 제공을 가능하게 하는 데 있어서 그렇습니다.

이 블로그 게시물은 마이크로서비스 설계, 구축 및 배포에 대한 7부작 시리즈의 첫 번째입니다 . 접근 방식과 보다 전통적인 모놀리식 아키텍처 패턴 과의 비교에 대해 알아봅니다 . 이 시리즈에서는 마이크로서비스 아키텍처의 다양한 요소를 설명합니다. 마이크로서비스 아키텍처 패턴의 이점과 단점, 프로젝트에 적합한지 여부, 적용 방법에 대해 알아봅니다.

먼저 마이크로서비스를 사용해야 하는 이유를 살펴보겠습니다.

모놀리식 애플리케이션 구축

Uber와 Hailo와 경쟁하기 위한 새로운 택시 호출 애플리케이션을 빌드하기 시작했다고 가정해 보겠습니다. 몇 가지 예비 회의와 요구 사항 수집 후 Rails, Spring Boot, Play 또는 Maven과 함께 제공되는 생성기를 사용하거나 수동으로 새 프로젝트를 만듭니다. 이 새 애플리케이션은 다음 다이어그램과 같이 모듈 식 육각형 아키텍처를 갖습니다.

모듈식이지만 여전히 모놀리식 아키텍처는 샘플 마이크로서비스 애플리케이션의 기반으로 사용됩니다.

애플리케이션의 핵심은 서비스, 도메인 객체 및 이벤트를 정의하는 모듈에 의해 구현되는 비즈니스 로직입니다. 핵심을 둘러싼 것은 외부 세계와 인터페이스하는 어댑터입니다. 어댑터의 예로는 데이터베이스 액세스 구성 요소, 메시지를 생성하고 사용하는 메시징 구성 요소, API를 노출하거나 UI를 구현하는 웹 구성 요소가 있습니다.

논리적으로 모듈식 아키텍처를 가지고 있음에도 불구하고, 애플리케이션은 모놀리스로 패키징되고 배포됩니다. 실제 형식은 애플리케이션의 언어와 프레임워크에 따라 달라집니다. 예를 들어, 많은 Java 애플리케이션은 WAR 파일로 패키징되어 Tomcat이나 Jetty와 같은 애플리케이션 서버에 배포됩니다. 다른 Java 애플리케이션은 자체 포함 실행 파일 JAR로 패키징됩니다. 마찬가지로 Rails 및 Node.js 애플리케이션은 디렉토리 계층으로 패키징됩니다.

이 스타일로 작성된 애플리케이션은 매우 일반적입니다. IDE와 다른 도구는 단일 애플리케이션을 빌드하는 데 중점을 두고 있기 때문에 개발하기 쉽습니다. 이러한 종류의 애플리케이션은 테스트하기도 간단합니다. 애플리케이션을 실행하고 Selenium으로 UI를 테스트하기만 하면 엔드투엔드 테스트를 구현할 수 있습니다. 모놀리식 애플리케이션도 배포하기 쉽습니다. 패키지된 애플리케이션을 서버에 복사하기만 하면 됩니다. 로드 밸런서 뒤에서 여러 복사본을 실행하여 애플리케이션을 확장할 수도 있습니다. 프로젝트의 초기 단계에서는 잘 작동합니다.


거대한 지옥을 향해 행진하다

불행히도, 이 간단한 접근 방식에는 엄청난 한계가 있습니다. 성공적인 애플리케이션은 시간이 지남에 따라 커지고 결국 거대해지는 경향이 있습니다. 각 스프린트 동안 개발팀은 몇 개의 스토리를 더 구현하는데, 물론 이는 많은 줄의 코드를 추가한다는 것을 의미합니다. 몇 년 후에는 작고 간단한 애플리케이션이 괴물 같은 모놀리스 로 성장할 것입니다 . 극단적인 예를 들자면, 저는 최근 수백만 줄의 코드(LOC) 애플리케이션에서 수천 개의 JAR 간의 종속성을 분석하는 도구를 작성하고 있던 개발자와 이야기를 나누었습니다. 저는 그러한 괴물을 만들기 위해 수년에 걸쳐 많은 개발자가 협력했을 것이라고 확신합니다.

애플리케이션이 크고 복잡한 모놀리스가 되면 개발 조직은 아마도 엄청난 고통에 빠질 것입니다. 애자일 개발 및 제공을 시도하면 좌초될 것입니다. 가장 큰 문제 중 하나는 애플리케이션이 엄청나게 복잡하다는 것입니다. 한 명의 개발자가 완전히 이해하기에는 너무 큽니다. 결과적으로 버그를 수정하고 새로운 기능을 올바르게 구현하는 것이 어렵고 시간이 많이 걸립니다. 게다가 이것은 하향 나선이 되는 경향이 있습니다. 코드베이스를 이해하기 어려우면 변경 사항이 올바르게 적용되지 않습니다. 결국 괴물 같고 이해할 수 없는 큰 진흙덩어리가 생깁니다 .

애플리케이션의 엄청난 크기도 개발 속도를 늦출 것입니다. 애플리케이션이 클수록 시작 시간이 길어집니다. 예를 들어, 최근 설문 조사에서 일부 개발자는 시작 시간이 12분에 달한다고 보고했습니다. 애플리케이션이 시작하는 데 40분이나 걸린다는 일화도 들었습니다. 개발자가 애플리케이션 서버를 정기적으로 다시 시작해야 한다면 하루 중 많은 시간을 기다리는 데 보내게 되고 생산성이 저하됩니다.

대규모 복잡한 모놀리스 애플리케이션의 또 다른 문제는 지속적인 배포에 대한 장애물이라는 것입니다. 오늘날 SaaS 애플리케이션의 최첨단 기술은 하루에 여러 번 변경 사항을 프로덕션에 푸시하는 것입니다. 복잡한 모놀리스에서는 전체 애플리케이션을 다시 배포하여 어느 한 부분을 업데이트해야 하기 때문에 이를 수행하기가 매우 어렵습니다. 앞서 언급한 긴 시작 시간도 도움이 되지 않습니다. 또한 변경의 영향은 일반적으로 잘 이해되지 않기 때문에 광범위한 수동 테스트를 수행해야 할 가능성이 높습니다. 결과적으로 지속적인 배포는 거의 불가능합니다.

모놀리식 애플리케이션은 서로 다른 모듈에 상충되는 리소스 요구 사항이 있는 경우에도 확장하기 어려울 수 있습니다. 예를 들어, 한 모듈은 CPU 집약적 이미지 처리 로직을 구현할 수 있으며 이상적으로는 Amazon EC2 Compute Optimized 인스턴스 에 배포될 수 있습니다 . 다른 모듈은 메모리 내 데이터베이스일 수 있으며 EC2 Memory-optimized 인스턴스 에 가장 적합할 수 있습니다 . 그러나 이러한 모듈은 함께 배포되므로 하드웨어 선택에 타협해야 합니다.

모놀리식 애플리케이션의 또 다른 문제는 안정성입니다. 모든 모듈이 동일한 프로세스 내에서 실행되기 때문에 메모리 누수와 같은 모든 모듈의 버그가 잠재적으로 전체 프로세스를 중단시킬 수 있습니다. 게다가 애플리케이션의 모든 인스턴스가 동일하기 때문에 해당 버그는 전체 애플리케이션의 가용성에 영향을 미칩니다.

마지막으로, 모놀리식 애플리케이션은 새로운 프레임워크와 언어를 채택하는 것을 극도로 어렵게 만듭니다. 예를 들어, XYZ 프레임워크를 사용하여 작성된 200만 줄의 코드가 있다고 가정해 보겠습니다. 새로운 ABC 프레임워크를 사용하도록 전체 애플리케이션을 다시 작성하는 것은 (시간과 비용 측면에서) 매우 비쌉니다. 해당 프레임워크가 상당히 더 뛰어나더라도 말입니다. 결과적으로 새로운 기술을 채택하는 데 큰 장벽이 생깁니다. 프로젝트를 시작할 때 선택한 기술에 얽매이게 됩니다.

요약하자면, 성공적인 비즈니스에 중요한 애플리케이션이 있는데, 개발자가 거의 없거나 전혀 이해하지 못하는 괴물 같은 모놀리스로 성장했습니다. 재능 있는 개발자를 고용하기 어렵게 만드는 쓸모없고 비생산적인 기술을 사용하여 작성되었습니다. 애플리케이션은 확장하기 어렵고 신뢰할 수 없습니다. 결과적으로 민첩한 애플리케이션 개발 및 제공이 불가능합니다.

그러면 이에 대해 무엇을 할 수 있을까요?


마이크로서비스 - 복잡성 해결

Amazon, eBay, Netflix 와 같은 많은 조직은 현재 마이크로서비스 아키텍처 패턴 으로 알려진 것을 채택하여 이 문제를 해결했습니다 . 단일의 괴물 같은 모놀리식 애플리케이션을 빌드하는 대신, 애플리케이션을 더 작고 상호 연결된 서비스 세트로 분할하는 것이 아이디어입니다.

서비스는 일반적으로 주문 관리, 고객 관리 등과 같은 고유한 기능이나 기능을 구현합니다. 각 마이크로서비스는 비즈니스 로직과 다양한 어댑터로 구성된 자체 육각형 아키텍처를 갖춘 미니 애플리케이션입니다. 일부 마이크로서비스는 다른 마이크로서비스나 애플리케이션의 클라이언트에서 사용하는 API를 노출합니다. 다른 마이크로서비스는 웹 UI를 구현할 수 있습니다. 런타임에 각 인스턴스는 종종 클라우드 VM 또는 Docker 컨테이너입니다.

예를 들어, 앞서 설명한 시스템의 가능한 분해는 다음 다이어그램에 표시되어 있습니다.

각 마이크로서비스가 RESTful API를 제공하는 샘플 승차 서비스 앱에 대한 마이크로서비스 아키텍처

이제 애플리케이션의 각 기능 영역은 자체 마이크로서비스로 구현됩니다. 게다가 웹 애플리케이션은 더 간단한 웹 애플리케이션 세트(예: 택시 호출 예에서 승객용과 운전자용)로 분할됩니다. 이를 통해 특정 사용자, 장치 또는 특수 사용 사례에 대해 고유한 경험을 배포하기가 더 쉬워집니다.

각 백엔드 서비스는 REST API를 노출하고 대부분의 서비스는 다른 서비스에서 제공하는 API를 사용합니다. 예를 들어, Driver Management는 Notification 서버를 사용하여 이용 가능한 운전자에게 잠재적인 여행에 대해 알립니다. UI 서비스는 웹 페이지를 렌더링하기 위해 다른 서비스를 호출합니다. 서비스는 비동기 메시지 기반 통신을 사용할 수도 있습니다. 서비스 간 통신은 이 시리즈의 후반부에서 더 자세히 다룹니다.

일부 REST API는 운전자와 승객이 사용하는 모바일 앱에도 노출됩니다. 그러나 앱은 백엔드 서비스에 직접 액세스할 수 없습니다. 대신 API Gateway 라는 중개자를 통해 통신이 중재됩니다 . API Gateway는 로드 밸런싱, 캐싱, 액세스 제어, API 측정 및 모니터링과 같은 작업을 담당하며 NGINX를 사용하여 효과적으로 구현할 수 있습니다 . 이 시리즈의 후속 기사에서는 API Gateway에 대해 다룹니다 .

Y축에 마이크로서비스로 기능 분해된 '스케일 큐브'

마이크로서비스 아키텍처 패턴은 The Art of Scalability라는 훌륭한 책에서 확장성의 3D 모델인 Scale Cube 의 Y축 확장에 해당합니다 . 다른 두 가지 확장 축은 로드 밸런서 뒤에서 애플리케이션의 여러 동일한 사본을 실행하는 것으로 구성된 X축 확장과 요청의 속성(예: 행의 기본 키 또는 고객의 ID)을 사용하여 요청을 특정 서버로 라우팅하는 Z축 확장(또는 데이터 분할)입니다.

애플리케이션은 일반적으로 세 가지 유형의 확장을 함께 사용합니다. Y축 확장은 이 섹션의 첫 번째 그림에서 위에 표시된 대로 애플리케이션을 마이크로서비스로 분해합니다. 런타임에 X축 확장은 처리량과 가용성을 위해 로드 밸런서 뒤에서 각 서비스의 여러 인스턴스를 실행합니다. 일부 애플리케이션은 Z축 확장을 사용하여 서비스를 분할할 수도 있습니다. 다음 다이어그램은 Trip Management 서비스가 Amazon EC2에서 실행되는 Docker와 함께 배포될 수 있는 방법을 보여줍니다.

Docker 컨테이너에 배포되고 로드 밸런서가 프런트 엔드로 사용되는 승차 대여 서비스를 위한 샘플 마이크로서비스 앱

런타임 시 Trip Management 서비스는 여러 서비스 인스턴스로 구성됩니다. 각 서비스 인스턴스는 Docker 컨테이너입니다. 고가용성을 위해 컨테이너는 여러 Cloud VM에서 실행됩니다. 서비스 인스턴스 앞에는 요청을 인스턴스에 분산하는 NGINX와 같은 로드 밸런서가 있습니다 . 로드 밸런서는 캐싱 , 액세스 제어 , API 미터링 및 모니터링 과 같은 다른 문제도 처리할 수 있습니다 .

마이크로서비스 아키텍처 패턴은 애플리케이션과 데이터베이스 간의 관계에 상당한 영향을 미칩니다. 다른 서비스와 단일 데이터베이스 스키마를 공유하는 대신 각 서비스에는 자체 데이터베이스 스키마가 있습니다. 한편으로 이 접근 방식은 엔터프라이즈 전체 데이터 모델이라는 개념과 맞지 않습니다. 또한 종종 일부 데이터가 중복됩니다. 그러나 마이크로서비스의 이점을 얻으려면 서비스당 데이터베이스 스키마가 있어야 하며, 느슨한 결합을 보장하기 때문입니다. 다음 다이어그램은 예제 애플리케이션의 데이터베이스 아키텍처를 보여줍니다.

라이드 서비스를 위한 샘플 마이크로서비스 애플리케이션의 데이터베이스 아키텍처

각 서비스에는 자체 데이터베이스가 있습니다. 게다가 서비스는 필요에 가장 적합한 데이터베이스 유형인 소위 폴리글롯 지속성 아키텍처를 사용할 수 있습니다. 예를 들어, 잠재적 승객과 가까운 운전자를 찾는 운전자 관리에서는 효율적인 지오쿼리를 지원하는 데이터베이스를 사용해야 합니다.

표면적으로 마이크로서비스 아키텍처 패턴은 SOA와 유사합니다. 두 접근 방식 모두 아키텍처는 일련의 서비스로 구성됩니다. 그러나 마이크로서비스 아키텍처 패턴에 대해 생각하는 한 가지 방법은 웹 서비스 사양 (WS-*)과 엔터프라이즈 서비스 버스(ESB)의 상용화 및 인식된 짐이 없는 SOA라는 것입니다. 마이크로서비스 기반 애플리케이션은 WS-*보다는 REST와 같은 더 간단하고 가벼운 프로토콜을 선호합니다. 또한 ESB 사용을 매우 피하고 대신 마이크로서비스 자체에 ESB와 유사한 기능을 구현합니다. 마이크로서비스 아키텍처 패턴은 또한 정식 스키마 개념과 같은 SOA의 다른 부분을 거부합니다.


마이크로서비스의 이점

마이크로서비스 아키텍처 패턴은 여러 가지 중요한 이점이 있습니다. 첫째, 복잡성 문제를 해결합니다. 그렇지 않으면 괴물 같은 모놀리식 애플리케이션을 일련의 서비스로 분해합니다. 기능의 총량은 변경되지 않지만 애플리케이션은 관리 가능한 청크 또는 서비스로 분할됩니다. 각 서비스에는 RPC 또는 메시지 구동 API 형태의 잘 정의된 경계가 있습니다. 마이크로서비스 아키텍처 패턴은 실제로 모놀리식 코드 기반으로는 달성하기 매우 어려운 수준의 모듈성을 적용합니다. 결과적으로 개별 서비스는 개발 속도가 훨씬 빠르고 이해하고 유지 관리하기가 훨씬 쉽습니다.

둘째, 이 아키텍처는 각 서비스가 해당 서비스에 집중하는 팀에 의해 독립적으로 개발될 수 있도록 합니다. 개발자는 서비스가 API 계약을 준수하는 한, 의미 있는 기술을 자유롭게 선택할 수 있습니다. 물론 대부분의 조직은 완전한 무정부 상태를 피하고 기술 옵션을 제한하고 싶어할 것입니다. 그러나 이러한 자유는 개발자가 더 이상 새 프로젝트를 시작할 때 존재했던 쓸모없는 기술을 사용할 의무가 없다는 것을 의미합니다. 새 서비스를 작성할 때 현재 기술을 사용할 수 있는 옵션이 있습니다. 게다가 서비스가 비교적 작기 때문에 현재 기술을 사용하여 오래된 서비스를 다시 작성하는 것이 가능해집니다.

셋째, 마이크로서비스 아키텍처 패턴은 각 마이크로서비스를 독립적으로 배포할 수 있도록 합니다. 개발자는 자신의 서비스에 로컬한 변경 사항의 배포를 조정할 필요가 없습니다. 이러한 종류의 변경 사항은 테스트가 완료되는 즉시 배포할 수 있습니다. 예를 들어 UI 팀은 A/B 테스트를 수행하고 UI 변경 사항을 빠르게 반복할 수 있습니다. 마이크로서비스 아키텍처 패턴은 지속적인 배포를 가능하게 합니다.

마지막으로, 마이크로서비스 아키텍처 패턴은 각 서비스를 독립적으로 확장할 수 있도록 합니다. 각 서비스의 용량 및 가용성 제약 조건을 충족하는 인스턴스 수만 배포할 수 있습니다. 게다가 서비스의 리소스 요구 사항에 가장 잘 맞는 하드웨어를 사용할 수 있습니다. 예를 들어, EC2 Compute Optimized 인스턴스에 CPU 집약적 이미지 처리 서비스를 배포하고 EC2 Memory-optimized 인스턴스에 인메모리 데이터베이스 서비스를 배포할 수 있습니다.


마이크로서비스의 단점

프레드 브룩스가 거의 30년 전에 썼듯이, 만병통치약은 없습니다. 다른 모든 기술과 마찬가지로 마이크로서비스 아키텍처에는 단점이 있습니다. 단점 중 하나는 이름 자체입니다. 마이크로서비스 라는 용어는 서비스 크기에 지나치게 중점을 둡니다. 사실, 일부 개발자는 매우 세분화된 10~100 LOC 서비스를 구축하는 것을 옹호합니다. 작은 서비스가 더 바람직하지만, 이는 목적을 달성하기 위한 수단이지 주요 목표가 아니라는 점을 기억하는 것이 중요합니다. 마이크로서비스의 목표는 민첩한 애플리케이션 개발 및 배포를 용이하게 하기 위해 애플리케이션을 충분히 분해하는 것입니다.

마이크로서비스의 또 다른 주요 단점은 마이크로서비스 애플리케이션이 분산 시스템이라는 사실에서 발생하는 복잡성입니다. 개발자는 메시징 또는 RPC를 기반으로 프로세스 간 통신 메커니즘을 선택하고 구현해야 합니다. 게다가 요청의 대상이 느리거나 사용할 수 없을 수 있으므로 부분적 실패를 처리하는 코드도 작성해야 합니다. 이 모든 것이 로켓 과학은 아니지만 모듈이 언어 수준의 메서드/프로시저 호출을 통해 서로를 호출하는 모놀리식 애플리케이션보다 훨씬 더 복잡합니다.

마이크로서비스의 또 다른 과제는 분할된 데이터베이스 아키텍처입니다. 여러 비즈니스 엔터티를 업데이트하는 비즈니스 트랜잭션은 꽤 일반적입니다. 이러한 종류의 트랜잭션은 단일 데이터베이스가 있기 때문에 모놀리식 애플리케이션에서 구현하기가 쉽습니다. 그러나 마이크로서비스 기반 애플리케이션에서는 서로 다른 서비스가 소유한 여러 데이터베이스를 업데이트해야 합니다. 분산 트랜잭션을 사용하는 것은 일반적으로 옵션이 아니며, CAP 정리 때문만은 아닙니다 . 오늘날의 확장성이 뛰어난 많은 NoSQL 데이터베이스와 메시징 브로커에서 지원되지 않습니다. 결국 개발자에게 더 어려운 이벤트적 일관성 기반 접근 방식을 사용해야 합니다.

마이크로서비스 애플리케이션을 테스트하는 것도 훨씬 더 복잡합니다. 예를 들어, Spring Boot와 같은 최신 프레임워크를 사용하면 모놀리식 웹 애플리케이션을 시작하고 REST API를 테스트하는 테스트 클래스를 작성하는 것이 간단합니다. 반면, 서비스에 대한 유사한 테스트 클래스는 해당 서비스와 해당 서비스에 종속된 모든 서비스를 시작해야 합니다(또는 최소한 해당 서비스에 대한 스텁을 구성해야 합니다). 다시 말하지만, 이는 로켓 과학이 아니지만 이를 수행하는 것의 복잡성을 과소평가하지 않는 것이 중요합니다.

마이크로서비스 아키텍처 패턴의 또 다른 주요 과제는 여러 서비스에 걸쳐 변경 사항을 구현하는 것입니다. 예를 들어, A, B, C 서비스에 대한 변경이 필요한 스토리를 구현한다고 가정해 보겠습니다. 여기서 A는 B에 종속되고 B는 C에 종속됩니다. 모놀리식 애플리케이션에서는 해당 모듈을 변경하고 변경 사항을 통합한 다음 한 번에 배포할 수 있습니다. 반면, 마이크로서비스 아키텍처 패턴에서는 각 서비스에 대한 변경 사항의 롤아웃을 신중하게 계획하고 조정해야 합니다. 예를 들어, 서비스 C를 업데이트한 다음 서비스 B를 업데이트하고 마지막으로 서비스 A를 업데이트해야 합니다. 다행히도 대부분의 변경 사항은 일반적으로 하나의 서비스에만 영향을 미치고 조정이 필요한 여러 서비스 변경은 비교적 드뭅니다.

마이크로서비스 기반 애플리케이션을 배포하는 것도 훨씬 더 복잡합니다. 모놀리식 애플리케이션은 단순히 기존 로드 밸런서 뒤에 있는 동일한 서버 세트에 배포됩니다. 각 애플리케이션 인스턴스는 데이터베이스 및 메시지 브로커와 같은 인프라 서비스의 위치(호스트 및 포트)로 구성됩니다. 반면, 마이크로서비스 애플리케이션은 일반적으로 많은 수의 서비스로 구성됩니다. 예를 들어, Hailo에는 160개의 다양한 서비스가 있고 Netflix에는 600개가 넘는 서비스가 있습니다( Adrian Cockcroft [편집자 - Hailo는 MyTaxi에 인수되었습니다.]) . 각 서비스에는 여러 개의 런타임 인스턴스가 있습니다. 구성, 배포, 확장 및 모니터링해야 하는 움직이는 부분이 훨씬 더 많습니다. 또한 서비스가 통신해야 하는 다른 서비스의 위치(호스트 및 포트)를 검색할 수 있도록 하는 서비스 검색 메커니즘(나중 게시물에서 논의)도 구현해야 합니다. 기존의 문제 티켓 기반 및 수동 운영 방식은 이 수준의 복잡성으로 확장할 수 없습니다. 결과적으로, 마이크로서비스 애플리케이션을 성공적으로 배포하려면 개발자가 배포 방법을 더 잘 제어하고 높은 수준의 자동화가 필요합니다.

자동화에 대한 한 가지 접근 방식은 Cloud Foundry 와 같은 기성형 PaaS를 사용하는 것입니다 . PaaS는 개발자에게 마이크로서비스를 배포하고 관리할 수 있는 쉬운 방법을 제공합니다. IT 리소스 조달 및 구성과 같은 우려 사항으로부터 개발자를 보호합니다. 동시에 PaaS를 구성하는 시스템 및 네트워크 전문가는 모범 사례와 회사 정책을 준수하도록 할 수 있습니다. 마이크로서비스 배포를 자동화하는 또 다른 방법은 본질적으로 자체 PaaS를 개발하는 것입니다. 일반적인 시작점 중 하나는 Docker와 같은 기술과 함께 Kubernetes 와 같은 클러스터링 솔루션을 사용하는 것입니다. 이 시리즈의 후반부에서는 캐싱, 액세스 제어, API 측정 및 마이크로서비스 수준에서 모니터링을 쉽게 처리하는 NGINX Plus와 같은 소프트웨어 기반 애플리케이션 제공 접근 방식이 이 문제를 해결하는 데 어떻게 도움이 될 수 있는지 살펴보겠습니다.


요약

복잡한 애플리케이션을 구축하는 것은 본질적으로 어렵습니다. 모놀리식 아키텍처는 단순하고 가벼운 애플리케이션에만 적합합니다. 복잡한 애플리케이션에 사용하면 엄청난 고통을 겪게 될 것입니다. 마이크로서비스 아키텍처 패턴은 단점과 구현 과제에도 불구하고 복잡하고 진화하는 애플리케이션에 더 나은 선택입니다.

이후 블로그 게시물에서는 마이크로서비스 아키텍처 패턴의 다양한 측면에 대한 세부 사항을 살펴보고 서비스 검색, 서비스 배포 옵션, 모놀리식 애플리케이션을 서비스로 리팩토링하는 전략과 같은 주제를 논의하겠습니다.



위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기

프로필 이미지
관리자
2025-01-17
조회 1


최신 앱은 현재 평균 앱 포트폴리오의 절반을 조금 넘는 수준인데, 2020년에는 29%에 불과했습니다. 1 이러한 앱은 보다 빠른 배포와 자동 확장을 위해 컨테이너에서 실행되는 경우가 많으며, 컨테이너 자체도 여러 환경에서 실행될 가능성이 높은데, 대부분 조직(88%)이 최소 두 가지 앱 배포 모델을 사용하고 약 40%가 여섯 가지를 사용하기 때문입니다. 2 그러나 최신 앱을 점점 더 다양한 환경에서 실행하면 안정적인 보안과 연결성이 복잡해집니다.


쿠버네티스 오케스트레이션의 장단점

Kubernetes는 가장 인기 있는 컨테이너 오케스트레이션 시스템으로, 84%의 조직이 사용하거나 평가 중이며 66%가 프로덕션에서 사용하고 있습니다. 3 Amazon Elastic Kubernetes Service(EKS)는 설문 조사에 참여한 조직의 절반 이상이 사용하는 가장 인기 있는 컨테이너 오케스트레이션 플랫폼입니다. 4

EKS는 AWS 서비스와의 기본 통합, 자동 확장 및 리소스 프로비저닝을 통한 비용 효율성, Kubernetes 제어 평면의 자동 패치를 제공하는 관리형 서비스로, AWS나 온프레미스 데이터 센터에서 Kubernetes를 쉽게 실행할 수 있습니다.

쿠버네티스 오케스트레이션은 수많은 이점을 제공하지만, 어려움이 없는 것은 아닙니다. Red Hat의 연구에 따르면 많은 조직이 컨테이너 기반 쿠버네티스 환경을 보호하는 복잡성에 여전히 어려움을 겪고 있으며, 89%가 지난 12개월 동안 적어도 하나의 관련 보안 사고를 보고했습니다. 5 조직의 3분의 2 이상이 쿠버네티스 보안 문제로 인해 배포가 지연되거나 느려졌다고 보고했습니다. 6 쿠버네티스 환경이 여러 클라우드 또는 온프레미스 위치에 걸쳐 있는 경우 보안과 일관성을 유지하기 어렵습니다. Amazon EKS에서 실행하든 다른 환경에서 실행하든 컨테이너화된 앱을 일관되게 보호할 수 있는 솔루션이 필요합니다.


Kubernetes 연결 및 보안을 간소화합니다.

F5 NGINX를 사용하여 Amazon EKS를 포함한 모든 환경에서 Kubernetes 앱과 마이크로서비스를 확장, 관리 및 보호합니다. 온프레미스와 여러 클라우드에서 일관된 연결성과 보안을 제공하여 복잡성을 줄이는 동시에 실시간 가시성을 제공합니다.

Amazon EKS의 Ingress Controller로 NGINX를 사용하면 클러스터 간에 앱 연결을 관리할 수 있습니다. NGINX는 로드 밸런싱, 자동 확장, AWS Lambda와 같은 AWS 서비스와도 통합되어 AWS 환경에 원활하게 추가할 수 있습니다. 또한 AWS가 인프라를 보호하는 동안 앱과 데이터에 대한 보안을 제공하여 공유 책임 모델의 일부를 충족하는 데 도움이 됩니다.

NGINX는 부하 분산 및 SSL 종료를 통해 Kubernetes 배포를 프로덕션 수준으로 만들어 성능을 개선하고, 가동 시간을 늘리고, 보안을 강화합니다. 지속적인 인증 및 권한 부여, 액세스 제어, 종단 간 암호화, 계층 7 OWASP 및 DoS 보호, 실행 가능한 통찰력을 통해 엣지에서 클라우드까지 위협을 완화합니다. NGINX를 사용하여 Kubernetes 앱에 대한 제로 트러스트 보안을 활성화할 수도 있습니다.

NGINX는 보안 문제 및 출시 시간과 같이 일반적으로 보고된 여러 Kubernetes 과제를 해결합니다. 셀프 서비스 기능을 통해 개발팀은 보안 위험을 추가하지 않고도 앱을 더 빠르게 출시할 수 있습니다. Kubernetes 앱과 함께 NGINX를 사용하면 도구 확산을 줄이고 일관성을 높이며 앱 상태와 성능에 대한 더 나은 통찰력을 제공하여 여러 환경에서 복잡성을 완화할 수도 있습니다.


어디에서나 Kubernetes를 간소화하고 보안하세요

Amazon EKS에서 Kubernetes 배포와 함께 NGINX를 사용하면(그리고 다른 곳에서 실행하는 경우) 안전하고 간소화된 앱 연결로 운영을 간소화하고 가동 시간을 늘릴 수 있습니다. AWS Marketplace 에서 NGINX를 30일 동안 무료로 사용해 보거나 AWS에서 사용할 수 있는 다른 많은 F5 솔루션을 알아보세요.



위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요


전문가에게 상담받기

프로필 이미지
관리자
2025-01-17
조회 9

Kubernetes 생태계에서 애플리케이션 연결을 진화시키는 획기적인 제품인 NGINX Gateway Fabric 1.3.0의 출시를 발표하게 되어 기쁩니다. NGINX Gateway Fabric은 앱, 서비스 및 API 연결을 간소화하고 단순화하도록 설계된 통합 애플리케이션 제공 패브릭인 Kubernetes 도구의 새로운 범주를 개척합니다. 이 도구는 Kubernetes 클러스터에서, Kubernetes 클러스터로, Kubernetes 클러스터 내에서 앱 및 서비스 연결을 지원하도록 설계되어 가장 인기 있는 Ingress 컨트롤러 및 서비스 메시 사용 사례를 하나의 통합 도구로 효과적으로 결합하는 동시에 복잡성을 줄이고 가용성을 개선하며 대규모로 보안과 가시성을 제공합니다. 이번 출시를 통해 오픈 소스 모델에서 Kubernetes 스택 번들에 포함될 완벽하게 지원되는 상용 버전으로 전환합니다.


NGINX Gateway Fabric 1.3.0은 애플리케이션 성능을 최적화하고 시스템 동작에 대한 심층적인 통찰력을 제공하도록 설계된 다양한 강력한 기능을 도입합니다.


NGINX Gateway Fabric 1.3.0의 주요 기능은 다음과 같습니다.

1. GRPCRoute 지원: 애플리케이션에 대한 효율적이고 저지연 gRPC 통신을 지원하여 기존 HTTP REST API와 함께 gRPC 트래픽을 원활하게 관리할 수 있습니다.

2. OpenTelemetry 추적: 애플리케이션 성능에 대한 가시성을 높이기 위한 내장형 추적 지원을 제공합니다. 특정 경로에 대한 추적을 쉽게 구성하고 활성화할 수 있어 시스템을 압도하지 않고도 귀중한 통찰력을 수집할 수 있습니다.

3. 클라이언트 설정 정책: 바디 크기 제한, 타임아웃, keepalive 설정과 같은 클라이언트 설정에 대한 사용자 친화적인 정책을 통해 NGINX 동작에 대한 세부적인 제어를 제공합니다. 게이트웨이 수준에서 적절한 기본값을 설정하는 동시에 애플리케이션별 요구 사항에 대한 경로 수준 재정의를 허용합니다.

NGINX의 입증된 데이터 플레인을 Gateway API 프레임워크에 통합함으로써 NGINX Gateway Fabric은 빠르고 안정적이며 안전한 Kubernetes 앱 및 서비스 연결을 보장합니다. NGINX Gateway Fabric 1.3.0의 기능과 이점에 대해 자세히 알아보려면 F5 DevCentral의 기술 릴리스 블로그를 읽어보세요 .



위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기


프로필 이미지
관리자
2025-01-17
조회 1

F5 NGINX의 NGINX Ingress Controller는 Prometheus operator ServiceMonitorCRD와 결합되어 Helm을 사용하여 NGINX Ingress Controller 배포에서 메트릭을 훨씬 더 쉽고 빠르게 수집할 수 있습니다. NGINX Ingress Controller helm 차트는 이제 기존 Prometheus 및 prometheus-operator 인프라를 즉시 활용할 수 있는 기능을 지원하여 NIC를 배포하고 메트릭을 바로 활용할 수 있습니다 Prometheus ServiceMonitor. 이 문서에서는 NGINX Ingress Controller helm 차트가 무엇 ServiceMonitor인지, 어떻게 설치하는지, 그리고 이러한 특정 설정을 정의하기 위해 NGINX Ingress Controller helm 차트를 어떻게 사용할 수 있는지 안내합니다.


프로메테우스 서비스 모니터

Prometheus ServiceMonitor 사용자 정의 리소스 정의(CRD)를 사용하면 동적 서비스 집합을 모니터링하는 방법을 선언적으로 정의할 수 있습니다. 모니터링되는 서비스는 Kubernetes 레이블 선택기를 사용하여 정의됩니다. 이를 통해 조직은 메트릭이 노출되는 방식을 제어하는 규칙을 도입할 수 있습니다. 이러한 규칙에 따라 새 서비스가 자동으로 검색되고 Prometheus는 시스템을 재구성할 필요 없이 메트릭을 수집하기 시작합니다. ServiceMonitorPrometheus Operator의 일부입니다. 이러한 리소스는 Prometheus에서 스크래핑할 모니터링 대상을 설명하고 관리합니다. Prometheus 리소스는 필드를 ServiceMonitor사용하여 에 연결됩니다 ServiceMonitor Selector. Prometheus는 스크래핑을 위해 표시된 대상을 쉽게 식별할 수 있습니다. 이를 통해 ServiceMonitorKubernetes 클러스터의 리소스를 활용하여 NGINX Ingress Controller와 같은 솔루션을 모니터링할 수 있는 제어력과 유연성이 향상됩니다. 작업을 더 쉽게 하고 NGINX Ingress Controller에 대한 기본 제공 메트릭을 제공하기 위해 최근에 Prometheus ServiceMonitor헬름 차트에 사용할 수 있는 기능을 추가했습니다. 이를 통해 NGINX Ingress Controller를 배포한 직후에 Prometheus가 스크래핑을 시작할 수 있도록 메트릭을 활성화하는 것이 매우 쉽습니다. 이 기능을 사용하려면 메트릭 수집을 위해 특별히 만든 두 번째 서비스를 추가해야 합니다 ServiceMonitor. 이 서비스는 "첨부"됩니다. 이를 통해 Prometheus 운영자에게 어떤 서비스를 모니터링해야 하는지(메타데이터의 레이블 사용) 알려서 무엇을 어디에서 스크래핑해야 하는지 알 수 있습니다. 배포 또는 헬름 파일의 일부인 경우 NGINX Ingress Controller에 대한 서비스가 어떻게 보일지에 대한 예:


apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-servicemonitor
  labels:
    app: nginx-ingress-servicemonitor
spec:
  ports:
  - name: prometheus
    protocol: TCP
    port: 9113
    targetPort: 9113
  selector:
    app: nginx-ingress

위의 내용은 배포의 일부가 될 것입니다. 라벨, 앱:은 Prometheus 메트릭 스크래핑 nginx-ingress-servicemonitor을 위해 "연결"합니다 . 아래는 위의 서비스로 연결되는 serviceMonitor샘플입니다 .serviceMonitornginx-ingress-servicemonitor


apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: nginx-ingress-servicemonitor
  labels:
    app: nginx-ingress-servicemonitor
spec:
  selector:
    matchLabels:
      app: nginx-ingress-servicemonitor
  endpoints:
  - port: prometheus

Prometheus 리소스를 만들어야 하는데, 이 리소스는 리소스를 찾도록 구성되어 serviceMonitorPrometheus가 메트릭을 위해 스크래핑할 엔드포인트를 빠르고 쉽게 알 수 있도록 합니다. 아래 예에서 이 리소스는 Prometheus에 사양에 따라 모니터링할 항목을 알려줍니다. 아래에서 를 모니터링하고 있습니다 spec.serviceMonitorSelector.matchLabels:. Prometheus가 모든 네임스페이스에서 matchLabels를 찾고 있음을 알 수 있습니다 . 이는 NGINX Ingress Controller helm 차트 및 Helm에서 배포할 리소스 app.nginx-ingress-servicemonitor와 일치합니다 .serviceMonitor


apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  labels:
    prometheus: prometheus
spec:
  replicas: 1
  serviceAccountName: prometheus
  serviceMonitorNamespaceSelector:  {}
  serviceMonitorSelector:
    matchLabels:
      app: nginx-ingress-servicemonitor
  resources:
    requests:
      memory: 500Mi

다음은 다양한 부분을 연결하는 다이어그램입니다. ServiceMonitor 다이어그램그림 1: 서비스-모니터 개체 관계


Prometheus, prometheus-operator 및 Grafana 설치

전체 배포를 설치하기 위해 를 사용할 것입니다 prometheus-community/kube-prometheus-stack. 이렇게 하면 prometheus, prometheus-operator 및 Grafana가 설치됩니다. 또한 격리를 위해 모니터링 네임스페이스에 설치하도록 지정할 것입니다. helm으로 설치하는 방법은 다음과 같습니다.helm install metrics01 prometheus-community/kube-prometheus-stack -n monitoring --create-namespace


Prometheus 리소스 생성 및 설치

Prometheus와 Prometheus CRD가 클러스터에 설치되면 Prometheus 리소스를 만들 수 있습니다. 이를 미리 배포하면 Helm 차트에서 사용할 레이블로 Prometheus 설정을 "사전 배관"할 수 있습니다. 이 접근 방식을 사용하면 Prometheus가 자동으로 NGINX Ingress Controller를 찾고 메트릭을 스크래핑하도록 할 수 있습니다. Prometheus 리소스는 NGINX Ingress Controller를 설치하기 전에 배포됩니다. 이렇게 하면 prometheus-operator배포 후 NGINX Ingress Controller를 자동으로 선택하고 스크래핑하여 메트릭을 빠르게 제공할 수 있습니다.


apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  namespace: default
  labels:
    prometheus: monitoring
spec:
  replicas: 1
  serviceAccountName: prometheus
  serviceMonitorNamespaceSelector:  {}
  serviceMonitorSelector:
    matchLabels:
      app: nginx-ingress-servicemonitor
  resources:
    requests:
      memory: 500Mi

위의 예는 기본적인 예입니다. 핵심 부분은 spec.serviceMonitorSelector.matchLabels우리가 지정한 값입니다. 이 값은 우리가 helm 차트로 NGINX Ingress 컨트롤러를 배포할 때 사용할 것입니다. 우리는 Prometheus 메트릭을 바로 제공하고 싶습니다. 그렇게 하기 위해 NGINX Ingress 컨트롤러 helm 차트를 사용할 것입니다.


NGINX Ingress Controller 헬름 values.yaml변경

values.yamlHelm 차트에 대한 파일을 검토할 수 있습니다 . Prometheus를 활성화하고, 필요한 서비스를 만들고, serviceMonitor리소스를 만드는 데 필요한 필수 요소가 있으므로 집중하고 싶은 Prometheus 섹션이 있습니다. Prometheus 섹션에서 여러 설정을 볼 수 있습니다. prometheus.service prometheus.serviceMonitorHelm 차트를 사용할 때 필요한 서비스와 serviceMonitor를 생성하기 위해 위의 두 설정을 모두 활성화할 것입니다. 다음은 서비스를 활성화하고, enable하고 serviceMonitor, 섹션에서 레이블을 정의하는 특정 섹션입니다 serviceMonitor.


`servicemonitor` support was recently added to the NGINX Ingress controller helm chart. 
prometheus:
  ## Expose NGINX or NGINX Plus metrics in the Prometheus format.
  create: true

  ## Configures the port to scrape the metrics.
  port: 9113

  secret: ""

  ## Configures the HTTP scheme used.
  scheme: http

  service:
    ## Requires prometheus.create=true
    create: true

  serviceMonitor:
    create: true
    labels: { app: nginx-ingress-servicemonitor } 

위의 값들을 분리해보면 다음과 같습니다.


prometheus:
  ## Expose NGINX or NGINX Plus metrics in the Prometheus format.
  create: true

Helm에 NIC Prometheus 엔드포인트를 활성화할 것을 알립니다. 필요한 경우 포트, 스킴 및 비밀을 추가로 정의할 수 있습니다. 값을 prometheus.service.createtrue로 설정하면 Helm이 NIC ServiceMonitor 서비스를 자동으로 생성합니다.


service:
    ## Creates a ClusterIP Service to expose Prometheus metrics internally
    ## Requires prometheus.create=true
    create: true

마지막으로 .을 만들어야 합니다 serviceMonitor. 이를 true로 설정하고 올바른 레이블을 추가하면 Prometheus 리소스와 일치하는 레이블이 생성되어 추가됩니다.


serviceMonitor:
    ## Creates a serviceMonitor to expose statistics on the kubernetes pods.
    create: true
    ## Kubernetes object labels to attach to the serviceMonitor object.
    labels: { app: nginx-ingress-servicemonitor } 

레이블은 서비스 이름으로 다시 연결됩니다 { app: nginx-ingress-servicemointor }. 레이블: 요약하자면 Prometheus를 활성화하면 NIC의 Prometheus 익스포터 기능이 노출됩니다. 서비스 객체를 정의합니다. 이것이 Prometheus ServiceMonitor가 NIC Prometheus 익스포터 엔드포인트를 검색하는 방법입니다. serviceMonitor 객체를 정의합니다. 이것은 Prometheus ServiceMonitor에 이것을 모니터링하라고 말합니다.


이제 NGINX Ingress Controller를 설치할 수 있습니다 helm.

를 수정한 후에 values.yaml는 NGINX Ingress 컨트롤러를 설치할 수 있습니다. helm install nic01 -n nginx-ingress --create-namespace -f values.yaml .NGINX Ingress 컨트롤러를 배포한 후에는 Prometheus 대시보드를 열고 상태 메뉴로 이동할 수 있습니다. 거기에서 대상 및 서비스 검색 뷰로 이동할 수 있습니다. Prometheus가 새 ServiceMonitor 리소스를 찾으면 엔드포인트를 스크래핑하고 Prometheus 대시보드에서 즉시 수집되는 메트릭을 수집하기 시작합니다.

프로메테우스 서비스 발견그림 2: Prometheus 서비스 검색

프로메테우스 목표그림 3: 프로메테우스 타겟

Prometheus NGINX 쿼리그림 4: Prometheus NGINX 쿼리

helm과 Prometheus와 같은 네이티브 Kubernetes 도구를 사용하면 NGINX Ingress Controller가 배포 시작 시 메트릭 수집을 훨씬 더 쉽게 만들어 "즉시 사용 가능한 메트릭"을 제공할 수 있음을 알 수 있습니다. prometheus-operator를 설치하는 데 대한 참조 문서는 다음과 같습니다 . https://prometheus-operator.dev/ https://github.com/prometheus-operator/prometheus-operator



위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기

프로필 이미지
관리자
2025-01-17
조회 2


Kubernetes Gateway API의 준수 구현인 NGINX Gateway Fabric에 대한 최신 소식을 공유하게 되어 기쁩니다. 최근 여러 가지 흥미로운 새로운 기능과 개선 사항이 포함된 1.2.0 버전으로 업데이트했습니다. 이 릴리스는 플랫폼의 기능을 향상하고 사용자의 요구 사항을 충족하는 데 중점을 두고 있습니다. F5 NGINX Plus 지원을 포함하고 가장 수요가 많은 사용 사례를 포괄하도록 API 표면을 확장했습니다. 이러한 개선 사항이 모든 사용자에게 더 나은 경험을 제공하고 사용자가 목표를 보다 효율적으로 달성하는 데 도움이 될 것이라고 믿습니다.

그림 1: NGINX Gateway Fabric의 설계 및 아키텍처 개요

NGINX Gateway Fabric 1.2.0 개요:

  • NGINX Plus 지원 – NGINX Gateway Fabric은 이제 데이터 평면에 대해 NGINX Plus를 지원하여 가용성이 개선되고 자세한 측정항목과 실시간 관찰 대시보드가 제공됩니다.
  • BackendTLSPolicy – TLS 검증을 통해 NGINX Gateway Fabric은 백엔드 애플리케이션의 신원을 확인하여 악성 애플리케이션에 의한 연결 하이재킹 가능성을 방지합니다. 또한 TLS는 클러스터 내의 트래픽을 암호화하여 클라이언트와 백엔드 애플리케이션 간의 안전한 통신을 보장합니다.
  • URLRewrite – NGINX Gateway Fabric은 이제 Route 객체에서 URL 재작성을 지원합니다. 이 기능을 사용하면 원래 요청 URL을 쉽게 수정하고 더 적절한 대상으로 리디렉션할 수 있습니다. 이렇게 하면 백엔드 애플리케이션이 API 변경을 거치더라도 클라이언트에 노출하는 API를 일관되게 유지할 수 있습니다.
  • 제품 원격 측정 – 이제 NGINX Gateway Fabric에 제품 원격 측정이 제공되므로, 환경에서 제품을 사용하는 방법에 대해 알아가면서 인프라의 운영 효율성을 더욱 개선하는 데 도움을 줄 수 있습니다. 또한, 회의 중에 커뮤니티와 이러한 통찰력을 정기적으로 공유할 계획입니다.

아래에서 새로운 기능을 자세히 살펴보겠습니다.


NGINX Gateway Fabric 1.2.0의 새로운 기능은 무엇입니까?


NGINX 플러스 지원

NGINX Gateway Fabric 버전 1.2.0이 NGINX Plus를 지원하여 출시되어 사용자에게 많은 새로운 이점을 제공합니다. 새로운 업그레이드를 통해 사용자는 이제 추가 Prometheus 메트릭, 동적 업스트림 재로드 및 NGINX Plus 대시보드를 포함하여 배포에서 NGINX Plus의 고급 기능을 활용할 수 있습니다. 이 업그레이드를 통해 환경에 대한 NGINX에서 직접 지원을 받을 수 있는 옵션도 제공됩니다.


추가 Prometheus 메트릭

NGINX Plus를 데이터 플레인으로 사용하는 동안 NGINX Open Source에서 일반적으로 얻는 메트릭과 함께 추가적인 고급 메트릭이 내보내집니다. 몇 가지 주요 내용으로는 http 요청, 스트림, 연결 등에 대한 메트릭이 있습니다. 전체 목록은 NGINX의 Prometheus 내보내기 도구를 확인하여 편리한 목록을 볼 수 있지만 내보내기 도구는 NGINX Gateway Fabric에 꼭 필요한 것은 아닙니다. Prometheus 또는 Prometheus 호환 스크래퍼를 설치하면 이러한 메트릭을 관찰 스택으로 스크래핑하고 아키텍처 내에서 일관된 계층을 사용하여 대시보드와 알림을 빌드할 수 있습니다. Prometheus 메트릭은 HTTP 포트 9113을 통해 NGINX Gateway Fabric에서 자동으로 사용할 수 있습니다. Pod 템플릿을 업데이트하여 기본 포트를 변경할 수도 있습니다. 간단한 설정을 원하시면 GitHub 페이지를 방문하여 Prometheus를 배포하고 구성하여 수집을 시작하는 방법에 대한 자세한 내용을 확인할 수 있습니다. 또는 메트릭만 보고 설정을 건너뛰고 싶다면 다음 섹션에서 설명하는 NGINX Plus 대시보드를 사용할 수 있습니다. 클러스터에 Prometheus를 설치한 후 백그라운드에서 포트 포워딩을 실행하여 대시보드에 액세스할 수 있습니다.kubectl -n monitoring port-forward svc/prometheus-server 9090:80

NGINX Gateway Fabric 연결을 사용한 Prometheus Graph 허용

그림 2: NGINX Gateway Fabric 연결이 수락된 것을 보여주는 Prometheus 그래프


위의 설정은 기본 NGINX Open Source를 데이터 플레인으로 사용하는 경우에도 작동합니다! 그러나 NGINX Plus가 제공하는 추가 메트릭은 볼 수 없습니다. 클러스터의 크기와 범위가 커짐에 따라 NGINX Plus 메트릭이 용량 계획 문제, 인시던트, 심지어 백엔드 애플리케이션 오류를 신속하게 해결하는 데 어떻게 도움이 될 수 있는지 살펴보는 것이 좋습니다.


동적 업스트림 리로드

NGINX Plus와 함께 설치 시 NGINX Gateway Fabric에서 자동으로 활성화되는 동적 업스트림 다시 로드를 통해 NGINX Gateway Fabric은 NGINX 다시 로드 없이 NGINX 구성을 업데이트할 수 있습니다. 전통적으로 NGINX 다시 로드가 발생하면 기존 연결은 이전 작업자 프로세스에서 처리하는 반면 새로 구성된 작업자는 새 연결을 처리합니다. 모든 이전 연결이 완료되면 이전 작업자가 중지되고 NGINX는 새로 구성된 작업자만 사용하여 계속 진행합니다. 이런 방식으로 NGINX 오픈 소스에서도 구성 변경이 우아하게 처리됩니다. 그러나 NGINX에 부하가 많이 걸리는 경우 이전 작업자와 새 작업자를 모두 유지하면 리소스 오버헤드가 생성되어 특히 NGINX Gateway Fabric을 최대한 간소하게 실행하려는 경우 문제가 발생할 수 있습니다. NGINX Plus에서 제공하는 동적 업스트림 다시 로드는 NGINX Gateway Fabric에서 자동으로 사용할 구성 변경에 대한 API 엔드포인트를 제공하여 다시 로드 프로세스 중에 이전 작업자와 새 작업자를 처리하기 위한 추가 리소스 오버헤드의 필요성을 줄임으로써 이 문제를 우회합니다. NGINX Gateway Fabric을 더 자주 변경하기 시작하면 재로드가 더 자주 발생합니다. 현재 NGF 설치에서 재로드가 얼마나 자주 또는 언제 발생하는지 궁금하다면 Prometheus 메트릭을 살펴보세요 nginx_gateway_fabric_nginx_reloads_total. 문제에 대한 전체적이고 심층적인 내용은 Nick Shadrin의 기사를 여기에서 확인하세요 ! 다음은 Prometheus 대시보드에서 NGINX Gateway Fabric을 두 번 배포한 환경에서 메트릭의 예입니다.

NGINX Gateway Fabric이 포함된 Prometheus 그래프는 총 재로드를 수행합니다.

그림 3: NGINX Gateway Fabric 재로드 총량을 보여주는 Prometheus 그래프


NGINX 플러스 대시보드

이전에 언급했듯이 Prometheus 설치 또는 관찰 스택 없이 NGINX Plus 메트릭을 빠르게 볼 수 있는 방법을 찾고 있다면 NGINX Plus 대시보드는 인시던트를 해결하고 리소스 용량을 주시하는 데 사용할 수 있는 성능 메트릭을 실시간으로 모니터링합니다.대시보드는 NGINX Plus에서 바로 제공하는 모든 메트릭에 대한 다양한 보기를 제공하며 내부 포트에서 쉽게 액세스할 수 있습니다.대시보드 기능이 어떤지 직접 빠르게 살펴보려면 demo.nginx.com에서 대시보드 데모 사이트를 확인하세요.NGINX Gateway Fabric 설치에서 NGINX Plus 대시보드에 액세스하려면 포트 포워딩을 통해 로컬 머신의 포트 8765로 연결을 전달할 수 있습니다. kubectl port-forward -n nginx-gateway 8765:8765그런 다음 선호하는 브라우저를 열고 주소창에 http://localhost:8765/dashboard.html을 입력합니다.

NGINX 플러스 대시보드

그림 4: NGINX Plus 대시보드 개요


백엔드TLSPolicy

이 릴리스에는 오랫동안 기다려온 BackendTLSPolicy 지원이 추가되었습니다 . BackendTLSPolicy는 NGINX Gateway Fabric과 애플리케이션 간에 암호화된 TLS 통신을 도입하여 통신 채널의 보안을 크게 향상시킵니다. 다음은 신뢰할 수 있는 인증 기관(CA)에 대해 서버 인증서를 검증할 때 TLS 암호 및 프로토콜과 같은 설정을 지정하여 정책을 적용하는 방법을 보여주는 예입니다. BackendTLSPolicy를 사용하면 사용자가 NGF와 백엔드 간의 트래픽을 보호할 수 있습니다. 최소 TLS 버전과 암호 제품군을 설정할 수도 있습니다. 이를 통해 악성 애플리케이션이 연결을 하이재킹하는 것을 방지하고 클러스터 내의 트래픽을 암호화합니다. 백엔드 TLS 종료를 구성하려면 먼저 사용하려는 CA 인증으로 ConfigMap 을 만듭니다. 내부 Kubernetes 인증서 관리에 대한 도움말은 이 가이드를 확인하세요 .


kind: ConfigMap
apiVersion: v1
metadata:
  name: backend-cert
data:
  ca.crt: 
         < -----BEGIN CERTIFICATE-----
       -----END CERTIFICATE-----
          >

secure-app다음으로, 서비스를 타겟으로 하고 이전 단계에서 만든 ConfigMap을 참조하는 BackendTLSPolicy를 만듭니다 .


apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: backend-tls
spec:
  targetRef:
    group: ''
    kind: Service
    name: secure-app
    namespace: default
  tls:
    caCertRefs:
    - name: backend-cert
      group: ''
      kind: ConfigMap
    hostname: secure-app.example.com


URL 다시 쓰기

URLRewrite 필터를 사용하면 들어오는 요청의 원래 URL을 수정하여 성능에 전혀 영향을 미치지 않고 다른 URL로 리디렉션할 수 있습니다. 이 기능은 백엔드 애플리케이션이 노출된 API를 변경하지만 기존 클라이언트에 대한 이전 버전과의 호환성을 유지하려는 경우에 특히 유용합니다. 또한 이 기능을 사용하여 클라이언트에 일관된 API URL을 노출하는 동시에 다른 API URL을 사용하여 요청을 다른 애플리케이션으로 리디렉션하여 클라이언트의 편의성과 성능을 위해 여러 다른 API의 기능을 결합한 "경험" API를 제공할 수 있습니다. 시작하려면 NGINX 게이트웨이 패브릭에 대한 게이트웨이를 만들어 보겠습니다. 이를 통해 HTTP 리스너를 정의하고 최적의 성능을 위해 포트 80을 구성할 수 있습니다.


apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cafe
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

HTTPRoute 리소스를 만들고 요청 필터를 구성하여 /coffee에 대한 모든 요청을 /beans로 다시 작성해 보겠습니다. 백엔드가 처리할 /latte 접두사를 포함하도록 다시 작성된 /latte 엔드포인트를 제공할 수도 있습니다("/latte/126"이 "/126"이 됨).


apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: coffee
spec:
  parentRefs:
  - name: cafe
    sectionName: http
  hostnames:
  - "cafe.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplaceFullPath
          replaceFullPath: /beans
    backendRefs:
    - name: coffee
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /latte
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: coffee
      port: 80

HTTP 재작성 기능은 클라이언트 측의 엔드포인트와 백엔드와 매핑되는 방식 간의 유연성을 보장하는 데 도움이 됩니다. 또한 한 URL에서 다른 URL로 트래픽을 리디렉션할 수 있어 특히 콘텐츠를 새 웹사이트나 API 트래픽으로 마이그레이션할 때 유용합니다. NGINX Gateway Fabric은 경로 기반 재작성을 지원하지만 현재는 경로 기반 리디렉션을 지원하지 않습니다. 이 기능이 환경에 필요한지 알려주세요 .


제품 원격 측정 (Telemetry)

우리는 1.2 릴리스의 일부로 수동적으로 피드백을 수집하는 메커니즘으로 제품 원격 측정을 포함하기로 결정했습니다. 이 기능은 환경에서 다양한 메트릭을 수집하여 24시간마다 데이터 수집 플랫폼으로 전송합니다. PII는 수집되지 않으며 수집되는 전체 목록은 여기 에서 확인할 수 있습니다 . 우리는 원격 측정 기능에 대한 완전한 투명성을 제공하기 위해 최선을 다하고 있습니다. 수집하는 모든 필드를 문서화하고 코드로 수집하는 내용을 검증할 수 있지만, 항상 완전히 비활성화할 수 있는 옵션이 있습니다. 커뮤니티 회의 에서 커뮤니티와 함께 수집한 통계를 기반으로 흥미로운 관찰 결과를 정기적으로 검토할 계획 이므로 꼭 들러주세요!

자원

NGINX Gateway Fabric 1.2.0의 전체 변경 사항은 릴리스 노트를 참조하세요 . NGINX Plus로 Kubernetes용 NGINX Gateway Fabric을 사용해 보려면 오늘 무료 30일 평가판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의하세요 . 참여하고 싶거나, 앞으로 나올 내용을 보고 싶거나, NGINX Gateway Fabric의 소스 코드를 보고 싶다면 GitHub 에서 저희 리포지토리를 확인하세요 ! 월요일 오전 9시 태평양/오후 5시 GMT에 2주마다 커뮤니티 회의가 있습니다. 회의 링크, 업데이트, 일정 및 메모는 NGINX Gateway Fabric 회의 일정 에 있습니다 . 링크는 항상 GitHub readme에서도 사용할 수 있습니다.



위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기


프로필 이미지
관리자
2025-01-17
조회 5


쿠버네티스에서 인공 지능(AI) 및 머신 러닝(ML) 워크로드를 실행하는 주요 이점 중 하나는 Ingress Controller를 통해 들어오는 모든 요청에 대한 중앙 제어 지점을 갖는 것입니다. 로드 밸런서 및 API 게이트웨이 역할을 하는 다재다능한 모듈로, 쿠버네티스 환경에서 AI/ML 애플리케이션을 보호하기 위한 견고한 기반을 제공합니다.

통합 도구인 Ingress Controller는 보안 및 성능 측정을 적용하고, 활동을 모니터링하고, 규정 준수를 의무화하는 데 편리한 터치포인트입니다. 더 구체적으로, Kubernetes 환경에서 Ingress Controller에서 AI/ML 애플리케이션을 보호하면 이 블로그에서 살펴보는 몇 가지 전략적 이점이 있습니다.


중앙 집중식 보안 및 규정 준수 제어

Ingress Controller는 Kubernetes 클러스터에 대한 게이트웨이 역할을 하므로 MLOps 및 플랫폼 엔지니어링 팀이 보안 정책을 시행하기 위한 중앙 집중식 지점을 구현할 수 있습니다. 이를 통해 포드별 또는 서비스별로 보안 설정을 구성하는 복잡성이 줄어듭니다. Ingress 수준에서 보안 제어를 중앙 집중화하면 규정 준수 프로세스가 간소화되고 규정 준수 상태를 관리하고 모니터링하기가 더 쉬워집니다.

통합 인증 및 권한 부여

Ingress Controller는 모든 AI/ML 애플리케이션에 대한 액세스에 대한 인증 및 승인을 구현하고 시행하는 논리적인 위치이기도 합니다. 강력한 인증 기관 관리를 추가함으로써 Ingress Controller는 Kubernetes를 위한 제로 트러스트(ZT) 아키텍처를 구축하는 핵심이기도 합니다. ZT는 매우 귀중한 독점 데이터에서 실행되는 민감한 AI 애플리케이션의 지속적인 보안 및 규정 준수를 보장하는 데 필수적입니다.

속도 제한 및 액세스 제어

Ingress Controller는 속도 제한을 시행하여 DDoS 공격이나 과도한 API 호출과 같은 남용으로부터 애플리케이션을 보호하기에 이상적인 곳으로, 이는 공개 AI/ML API에 필수적입니다. 모델 도난 및 데이터 유출과 같은 새로운 AI 위협이 증가함에 따라 속도 제한 및 액세스 제어를 시행하는 것이 무차별 대입 공격으로부터 보호하는 데 더욱 중요해지고 있습니다. 또한 적대자가 비즈니스 로직을 남용하거나 가드레일을 탈옥하여 데이터를 추출하고 학습을 모델링하거나 정보에 가중치를 두는 것을 방지하는 데 도움이 됩니다.

웹 애플리케이션 방화벽(WAF) 통합

많은 Ingress Controller는 노출된 애플리케이션과 서비스를 보호하기 위한 기본 요소인 WAF와의 통합을 지원합니다. WAF는 OWASP 10과 같은 일반적인 웹 취약성과 공격에 대한 추가 보안 계층을 제공합니다. 더욱 중요한 점은 적절하게 조정하면 WAF가 AI/ML 애플리케이션을 겨냥한 보다 집중적인 공격으로부터 보호한다는 것입니다. 지연 시간과 성능이 중요한 AI/ML 앱의 주요 고려 사항은 WAF로 인해 발생할 수 있는 잠재적인 오버헤드입니다. 또한 AI/ML 앱에서 효과적이려면 WAF를 모니터링 및 관찰 대시보드와 알림 구조를 위해 Ingress Controller에 긴밀하게 통합해야 합니다. WAF와 Ingress Controller가 공통 데이터 플레인을 공유할 수 있다면 이상적입니다.


결론: AI/ML 아키텍처 계획 초기에 Ingress Controller 포함

Ingress Controller는 AI/ML 앱을 위한 Kubernetes 애플리케이션 배포에서 매우 중요한 위치를 차지하기 때문에 AI/ML 애플리케이션을 설계하는 과정에서 해당 기능을 포함하는 것이 가장 좋습니다. 이를 통해 기능 중복을 완화하고 AI/ML 애플리케이션 요구 사항에 따라 확장 및 성장할 Ingress Controller에 대한 더 나은 결정을 내릴 수 있습니다. MLOps 팀의 경우 Ingress Controller는 보안을 최우선 순위로 두고 많은 중요한 플랫폼 및 운영 기능에 대한 중앙 제어 지점이 됩니다.

NGINX 시작하기

NGINX는 사용자의 요구 사항을 충족하고 Kubernetes 플랫폼의 보안, 확장성, 관찰성을 향상시키는 데 필요한 포괄적인 도구와 빌딩 블록 세트를 제공합니다.



위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요


전문가에게 상담받기

프로필 이미지
관리자
2025-01-17
조회 1


AI 및 머신 러닝(AI/ML) 워크로드는 기업의 운영 및 혁신 방식에 혁명을 일으키고 있습니다. 컨테이너 오케스트레이션 및 관리의 사실상 표준인 Kubernetes 는 하이브리드, 멀티 클라우드 환경에서 확장 가능한 대규모 언어 모델(LLM) 워크로드 및 추론 모델을 구동하기 위한 선택 플랫폼입니다.

Kubernetes에서 Ingress 컨트롤러는 컨테이너화된 애플리케이션을 제공하고 보호하는 데 중요한 역할을 합니다. Kubernetes 클러스터의 가장자리에 배포되어 사용자와 애플리케이션 간의 통신을 처리하는 중심점 역할을 합니다.

이 블로그에서는 Ingress 컨트롤러와 Kubernetes용 F5 NGINX Connectivity Stack이 AI/ML 워크로드에 대한 모델 제공, 실험, 모니터링 및 보안을 단순화하고 효율화하는 데 어떻게 도움이 될 수 있는지 살펴보겠습니다 .

대규모 프로덕션에서 AI/ML 모델 배포

대규모로 AI/ML 모델을 배포할 때 즉시 사용 가능한 Kubernetes 기능과 성능은 다음과 같은 데 도움이 될 수 있습니다.

  • AI/ML 애플리케이션 릴리스 수명 주기를 가속화하고 단순화합니다.
  • 다양한 환경에서 AI/ML 워크로드 이동성을 지원합니다.
  • 컴퓨팅 리소스 활용의 효율성과 경제성을 개선합니다.
  • 확장성을 제공하고 프로덕션 준비 상태를 달성합니다.
  • 비즈니스 SLA를 충족하도록 환경을 최적화합니다.

동시에 조직은 대규모 프로덕션에서 AI/ML 모델을 제공하고, 실험하고, 모니터링하고, 보호하는 데 어려움을 겪을 수 있습니다.

  • 복잡성이 증가하고 도구가 확산되면서 조직이 온프레미스, 클라우드 및 엣지에서 Kubernetes 환경을 구성, 운영, 관리, 자동화하고 문제를 해결하기가 어려워졌습니다.
  • Pod 오류 및 재시작, 자동 크기 조정, 매우 높은 요청률 등의 동적 이벤트로 인한 연결 시간 초과 및 오류로 인해 사용자 경험이 저하됩니다 .
  • 집계된 보고와 세부적이고 실시간이며 과거 기록된 지표가 부족하여 복잡한 Kubernetes 환경에서 성능 저하, 가동 중지 시간, 문제 해결 속도가 느리고 어렵습니다.
  • 기존 보안 모델은 느슨하게 결합된 분산 애플리케이션을 보호하도록 설계되지 않았기 때문에 하이브리드, 멀티 클라우드 Kubernetes 환경에서 사이버보안 위협에 노출될 위험이 큽니다 .

F5 NGINX Ingress Controller 와 같은 엔터프라이즈급 Ingress 컨트롤러는 이러한 과제를 해결하는 데 도움이 될 수 있습니다. Ingress 컨트롤러, 로드 밸런서, API 게이트웨이 기능을 결합한 하나의 도구를 활용하면 Kubernetes를 어디에서 실행하든 규모에 맞게 더 나은 가동 시간, 보호 및 가시성을 달성할 수 있습니다. 또한 복잡성과 운영 비용을 줄여줍니다.


NGINX Ingress Controller는 LLM 애플리케이션에 대한 OWASP Top 10 사이버 위협을 완화하고 DoS 공격으로부터 AI/ML 워크로드를 방어하는 데 도움이 되는 F5의 업계 선도적인 Layer 7 앱 보호 기술 과 긴밀하게 통합될 수도 있습니다 .

AI/ML 워크로드를 위한 Ingress 컨트롤러의 이점

Ingress 컨트롤러는 다음 기능을 통해 프로덕션에서 AI/ML 워크로드의 배포 및 실행을 간소화하고 효율화할 수 있습니다.

  • 모델 제공 – Kubernetes 기본 부하 분산, 자동 확장, 속도 제한 및 동적 재구성 기능을 사용하여 중단 없이 앱을 제공합니다.
  • 모델 실험 – 블루-그린 및 카나리아 배포와 A/B 테스트를 구현하여 다운타임 없이 새로운 버전과 업그레이드를 출시합니다.
  • 모델 모니터링 – 앱 상태와 성능에 대한 더 나은 통찰력을 얻기 위해 모델 메트릭을 수집, 표현 및 분석합니다.
  • 모델 보안 – 앱을 사이버보안 위협으로부터 보호하기 위해 사용자 ID, 인증, 권한 부여, 역할 기반 액세스 제어 및 암호화 기능을 구성합니다.

Kubernetes용 NGINX Connectivity Stack에는 NGINX Ingress Controller 와 F5 NGINX App Protect가 포함되어 AI/ML 애플리케이션을 실행하는 Kubernetes 클러스터와 온프레미스 및 클라우드에서 사용자 간에 빠르고 안정적이며 안전한 통신을 제공합니다. 모든 Kubernetes 환경에서 모델 제공, 실험, 모니터링 및 보안을 간소화하고 간소화하여 클라우드 공급자와 사전 패키징된 Kubernetes 오퍼링의 기능을 향상시키고 규모에 따라 더 높은 수준의 보호, 가용성 및 관찰성을 제공합니다.

Kubernetes를 위한 NGINX Connectivity Stack 시작하기

NGINX는 사용자의 요구 사항을 충족하고 Kubernetes 플랫폼의 보안, 확장성 및 가시성을 향상시키는 데 필요한 포괄적인 도구와 빌딩 블록 세트를 제공합니다.



위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기

프로필 이미지
관리자
2025-01-17
조회 1

당신은 현대적 Platform Ops 또는 DevOps 엔지니어입니다. 당신은 오픈 소스(그리고 아마도 일부 상업용) 도구 라이브러리를 사용하여 개발팀을 위한 새로운 앱과 컨테이너를 테스트, 배포 및 관리합니다. 당신은 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 포드를 실행하기 위해 Kubernetes를 선택했습니다. 당신은 마이크로서비스의 아키텍처와 개념을 받아들였고, 대부분 잘 작동합니다. 그러나 이 여정에서 몇 가지 속도 범프에 부딪혔습니다.

예를 들어, 새로운 클러스터, 서비스 및 애플리케이션을 빌드하고 출시할 때 트래픽을 끊지 않고 이러한 새로운 리소스를 프로덕션에 쉽게 통합하거나 마이그레이션하려면 어떻게 해야 할까요? 기존 네트워킹 어플라이언스는 DNS 레코드, 로드 밸런서, 방화벽 및 프록시에 대한 구성 변경을 구현할 때 다시 로드하거나 재부팅해야 합니다. 이러한 조정은 DNS, 로드 밸런서 및 방화벽 규칙을 업데이트하는 데 "서비스 중단" 또는 "유지 관리 창"이 필요하기 때문에 다운타임을 발생시키지 않고는 재구성할 수 없습니다. 대부분의 경우, 두려운 서비스 티켓을 제출하고 다른 팀이 승인하고 변경을 수행할 때까지 기다려야 합니다.

유지 관리 창은 팀을 도랑에 빠뜨리고, 애플리케이션 제공을 멈추고, "트래픽을 관리하는 더 나은 방법이 있어야 한다!"고 선언하게 만들 수 있습니다. 따라서 빠른 차선으로 돌아갈 수 있는 솔루션을 살펴보겠습니다.


액티브-액티브 멀티 클러스터 로드 밸런싱

여러 개의 Kubernetes 클러스터가 있는 경우 두 클러스터로 동시에 트래픽을 라우팅하는 것이 이상적입니다. 더 나은 옵션은 A/B, 카나리아 또는 블루-그린 트래픽 분할을 수행하고 트래픽의 작은 비율을 테스트로 보내는 것입니다. 이를 위해 NGINX Plus를 ngx_http_split_clients_module.

NGINX Plus 다이어그램이 있는 K8s

HTTP Split Clients 모듈은 NGINX Open Source에서 작성되었으며 요청 비율을 키에 따라 분산할 수 있습니다. 이 사용 사례에서 클러스터는 NGINX의 "업스트림"입니다. 따라서 클라이언트 요청이 도착하면 트래픽이 두 클러스터로 분할됩니다. 클라이언트 요청을 결정하는 데 사용되는 키는 사용 가능한 NGINX 클라이언트입니다 $variable. 즉, 모든 요청에 대해 이를 제어하려면 $request_idNGINX에서 모든 수신 요청에 할당한 고유 번호인 변수를 사용합니다.

분할 비율을 구성하려면 각 클러스터에 할당할 백분율을 결정합니다. 이 예에서 K8s Cluster1을 프로덕션용 "대형 클러스터"로 사용하고 Cluster2를 사전 프로덕션 테스트용 "소형 클러스터"로 사용합니다. 스테이징용 소규모 클러스터가 있는 경우 90:10 비율을 사용하고 소규모 클러스터에서 트래픽의 10%를 테스트하여 대규모 클러스터에 새 변경 사항을 롤아웃하기 전에 모든 것이 제대로 작동하는지 확인할 수 있습니다. 너무 위험해 보이면 비율을 95:5로 변경할 수 있습니다. 사실, 0~100% 사이에서 원하는 비율을 선택할 수 있습니다.

대부분의 실시간 프로덕션 트래픽의 경우 두 클러스터가 동일한 크기인 50:50 비율을 원할 것입니다. 하지만 클러스터 크기나 기타 세부 정보에 따라 다른 비율을 쉽게 제공할 수 있습니다. 비율을 0:100(또는 100:0)으로 쉽게 설정하고 다운타임 없이 전체 클러스터를 업그레이드, 패치, 수리 또는 교체할 수 있습니다. NGINX split_clients가 라이브 클러스터로 요청을 라우팅하는 동안 다른 클러스터에서 문제를 해결합니다.

# Nginx Multi Cluster Load Balancing
# HTTP Split Clients Configuration for Cluster1:Cluster2 ratios
# Provide 100, 99, 50, 1, 0% ratios  (add/change as needed)
# Based on
# https://www.nginx.com/blog/dynamic-a-b-testing-with-nginx-plus/
# Chris Akker – Jan 2024
#
 
split_clients $request_id $split100 {
   * cluster1-cafe;                     # All traffic to cluster1
   } 

split_clients $request_id $split99 {
   99% cluster1-cafe;                   # 99% cluster1, 1% cluster2
   * cluster2-cafe;
   } 
 
split_clients $request_id $split50 { 
   50% cluster1-cafe;                   # 50% cluster1, 50% cluster2
   * cluster2-cafe;
   }
    
split_clients $request_id $split1 { 
   1.0% cluster1-cafe;                  # 1% to cluster1, 99% to cluster2
   * cluster2-cafe;
   }

split_clients $request_id $split0 { 
   * cluster2-cafe;                     # All traffic to cluster2
   }
 
# Choose which cluster upstream based on the ratio
 
map $split_level $upstream { 
   100 $split100; 
   99 $split99; 
   50 $split50; 
   1.0 $split1; 
   0 $split0;
   default $split50;
}

위의 구성을 추가하거나 편집하여 필요한 비율(예: 90:10, 80:20, 60:40 등)에 맞게 조정할 수 있습니다.

참고: NGINX에는 스트림 컨텍스트에서 TCP 연결을 위한 것도 있는데 Split Clients module, 이는 HTTP가 아닌 트래픽에 사용할 수 있습니다. 이는 HTTP 요청 대신 새로운 TCP 연결을 기준으로 트래픽을 분할합니다.

NGINX Plus 키-값 저장소

사용할 수 있는 다음 기능은 NGINX Plus 키-값 저장소 입니다 . 이것은 다양한 데이터 저장 사용 사례에 사용할 수 있는 NGINX 공유 메모리 영역의 키-값 개체입니다. 여기서는 위 섹션에서 언급한 분할 비율 값을 저장하는 데 사용합니다. NGINX Plus를 사용하면 NGINX를 다시 로드하지 않고도 모든 키-값 레코드를 변경할 수 있습니다. 이를 통해 API 호출로 이 분할 값을 변경하여 동적 분할 함수를 만들 수 있습니다.

우리의 예를 기준으로 보면 다음과 같습니다.

{“cafe.example.com”:90}

이 KeyVal 레코드는 다음과 같이 읽힙니다.
키는 "cafe.example.com" 호스트 이름이고
값은 분할 비율에 대해 "90"입니다.

NGINX 구성 파일에 분할 비율을 하드 코딩하는 대신 키-값 메모리를 사용할 수 있습니다. 이렇게 하면 NGINX에서 정적 분할 값을 변경하는 데 필요한 NGINX 재로드가 제거됩니다.

이 예에서 NGINX는 분할 비율에 90:10을 사용하도록 구성되어 있으며, 큰 Cluster1은 90%를 차지하고 작은 Cluster2는 나머지 10%를 차지합니다. 이는 키-값 레코드이므로 구성을 다시 로드하지 않고도 NGINX Plus API를 사용하여 이 비율을 동적으로 변경할 수 있습니다 ! 분할 클라이언트 모듈은 변경하자마자 바로 다음 요청에서 이 새로운 비율 값을 사용합니다.

KV 레코드를 생성하려면 50/50 비율로 시작하세요.

NGINX Plus에 API 명령을 보내어 KeyValue 저장소에 새 레코드를 추가합니다.

curl -iX POST -d '{"cafe.example.com":50}' http://nginxlb:9000/api/8/http/keyvals/split

KV 레코드를 변경하고 90/10 비율로 변경합니다.

HTTP PATCH 메서드를 사용하여 메모리에서 KeyVal 레코드를 업데이트하여 KeyVal 분할 비율을 90으로 변경합니다.

curl -iX PATCH -d '{"cafe.example.com":90}' http://nginxlb:9000/api/8/http/keyvals/split

다음으로, 사전 프로덕션 테스트 팀은 새로운 애플리케이션 코드가 준비되었는지 확인하고, 이를 대규모 Cluster1 에 배포하고 비율을 100%로 변경합니다. 그러면 모든 트래픽이 Cluster1 로 즉시 전송되고 트래픽 중단, 서비스 중단, 유지 관리 기간, 재부팅, 다시 로드 또는 많은 티켓 없이 새로운 애플리케이션이 "라이브" 상태가 됩니다. 선택한 시점에 이 분할 비율을 변경하려면 API 호출이 한 번만 필요합니다.

물론, 90%에서 100%로 쉽게 이동할 수 있다는 것은 비율을 100:0에서 50:50(또는 0:100)으로 쉽게 변경할 수 있다는 것을 의미합니다. 따라서 핫 백업 클러스터를 보유하거나 새로운 리소스로 클러스터를 수평적으로 확장할 수 있습니다. 풀 스로틀로 최신 소프트웨어, 하드웨어 및 소프트웨어 패치로 완전히 새로운 클러스터를 구축하여 단 하나의 연결도 끊지 않고 일정 기간 동안 애플리케이션을 배포하고 트래픽을 마이그레이션할 수도 있습니다!


사용 사례

동적 키-값 저장소 와 함께 HTTP 분할 클라이언트 모듈을 사용하면 다음과 같은 사용 사례를 제공할 수 있습니다.

  • 액티브-액티브 로드 밸런싱 – 여러 클러스터에 대한 로드 밸런싱을 위해.
  • 액티브-패시브 로드 밸런싱 – 기본, 백업, DR 클러스터 및 애플리케이션에 대한 로드 밸런싱을 위해 사용됩니다.
  • A/B, 블루-그린 및 카나리아 테스트 – 새로운 Kubernetes 애플리케이션과 함께 사용됩니다.
  • 수평적 클러스터 확장 – 준비가 되면 더 많은 클러스터 리소스를 추가하고 비율을 변경합니다.
  • 히트리스 클러스터 업그레이드 – 한 클러스터를 사용하는 동안 다른 클러스터를 업그레이드, 패치 또는 복구할 수 있는 기능입니다.
  • 즉각적인 장애 조치 - 한 클러스터에 심각한 문제가 있는 경우 비율을 변경하여 다른 클러스터를 사용할 수 있습니다.


구성 예제

키-값 구성의 예는 다음과 같습니다.

# Define Key Value store, backup state file, timeout, and enable sync 
keyval_zone zone=split:1m state=/var/lib/nginx/state/split.keyval timeout=365d sync;

keyval $host $split_level zone=split;

그리고 이것은 cafe.example.com 애플리케이션 구성의 예입니다:

# Define server and location blocks for cafe.example.com, with TLS
server {
   listen 443 ssl;
   server_name cafe.example.com; 

   status_zone https://cafe.example.com;
      
   ssl_certificate /etc/ssl/nginx/cafe.example.com.crt; 
   ssl_certificate_key /etc/ssl/nginx/cafe.example.com.key;
   
   location / {
   status_zone /;
   
   proxy_set_header Host $host;
   proxy_http_version 1.1;
   proxy_set_header "Connection" "";
   proxy_pass https://$upstream;   # traffic split to upstream blocks
   
   }

# Define 2 upstream blocks – one for each cluster
# Servers managed dynamically by NLK, state file backup

# Cluster1 upstreams
 
upstream cluster1-cafe {
   zone cluster1-cafe 256k;
   least_time last_byte;
   keepalive 16;
   #servers managed by NLK Controller
   state /var/lib/nginx/state/cluster1-cafe.state; 
}
 
# Cluster2 upstreams
 
upstream cluster2-cafe {
   zone cluster2-cafe 256k;
   least_time last_byte;
   keepalive 16;
   #servers managed by NLK Controller
   state /var/lib/nginx/state/cluster2-cafe.state; 
}

업스트림 서버 IP:포트는 Kubernetes용 NGINX 로드밸런서 에서 관리합니다 . 이 새로운 컨트롤러는 NGINX Plus API를 사용하여 NGINX Plus를 동적으로 구성합니다. 자세한 내용은 다음 섹션 에 나와 있습니다 .

인기 있는 모니터링 및 시각화 도구 인 Grafana를 사용하여 시간에 따른 HTTP 분할 트래픽을 살펴보겠습니다 . NGINX Prometheus Exporter ( njs 기반 )를 사용하여 모든 NGINX Plus 메트릭을 내보내고, 이를 Grafana에서 수집하여 그래프로 표시합니다. Prometheus와 Grafana를 구성하는 방법에 대한 자세한 내용은 여기에서 확인할 수 있습니다 .

그래프에는 4개의 업스트림 서버가 있습니다. Cluster1 에 2개, Cluster2 에 2개 입니다 . HTTP 로드 생성 도구를 사용하여 HTTP 요청을 생성하고 NGINX Plus로 보냅니다.

아래 세 개의 그래프에서 그래프 시작부분의 분할 비율은 50:50임을 알 수 있습니다.

LB 업스트림 요청 다이어그램

그러면 12:56:30에서는 비율이 10:90으로 바뀐다.

LB 업스트림 요청 다이어그램

그러면 13:00:00에 90:10으로 변경됩니다.

LB 업스트림 요청 다이어그램

Prometheus와 Grafana의 작동 구성은 Kubernetes용 NGINX Loadbalancer GitHub 저장소 에서 찾을 수 있습니다 .


동적 HTTP 업스트림: Kubernetes용 NGINX 로드밸런서

NGINX Plus API와 Kubernetes 컨트롤러용 NGINX Loadbalancer를 사용하여 정적 NGINX Upstream 구성을 동적 클러스터 업스트림으로 변경할 수 있습니다 . 이 무료 프로젝트는 NGINX Ingress Controller를 감시 하고 TCP/HTTP 로드 밸런싱을 위해 구성된 외부 NGINX Plus 인스턴스를 자동으로 업데이트하는 Kubernetes 컨트롤러 입니다 . 설계가 매우 간단하고 설치 및 작동이 간단합니다. 이 솔루션을 사용하면 Kubernetes 환경에서 TCP/HTTP 로드 밸런싱을 구현하여 새 앱과 서비스를 즉시 감지하고 트래픽에 사용할 수 있습니다. 다시 로드할 필요가 없습니다.


Architecture & Flow 

Kubernetes용 NGINX 로드밸런서는 Kubernetes 클러스터 내부에 있습니다. Kubernetes에 등록되어 NGINX Ingress Controller( ) 서비스를 감시합니다 . Ingress 컨트롤러가 변경되면 Kubernetes용 NGINX 로드밸런서는 Worker Ips와 NodePort TCP 포트 번호를 수집한 다음 NGINX Plus API를nginx-ingress 통해 IP:ports를 NGINX Plus로 전송합니다 .

NGINX 업스트림 서버는 재로드가 필요 없이 업데이트되고, NGINX Plus는 트래픽을 올바른 업스트림 서버와 Kubernetes NodePorts로 로드 밸런싱합니다. 추가 NGINX Plus 인스턴스를 추가하여 고가용성을 달성할 수 있습니다 .

NGINX 로드밸런서가 동작하는 다이어그램


Kubernetes용 NGINX 로드밸런서의 작동 스냅샷

아래 스크린샷에는 Kubernetes용 NGINX Loadbalancer가 배포되어 작업을 수행하는 모습을 보여주는 두 개의 창이 있습니다.

  1. 서비스LoadBalancer 유형 –nginx-ingress
  2. 외부 IP – NGINX Plus 서버에 연결
  3. 포트 - NodePort는 NGINX 업스트림 서버와 일치하는 443:30158에 매핑됩니다(NGINX Plus 실시간 대시보드 에 표시됨 )
  4. 로그 - Kubernetes용 NGINX 로드밸런서가 NGINX Plus로 데이터를 성공적으로 전송하고 있음을 나타냄

NGINX Plus 윈도우

참고 : 이 예에서 Kubernetes 워커 노드는 10.1.1.8 및 10.1.1.10입니다.


NGINX Plus 보안 기능 추가

쿠버네티스에서 실행되는 애플리케이션이 점점 더 개방형 인터넷에 노출됨에 따라 보안이 필요해지고 있습니다. 다행히도 NGINX Plus에는 계층화된 심층 방어 아키텍처를 만드는 데 사용할 수 있는 엔터프라이즈급 보안 기능이 있습니다.

클러스터 앞에 NGINX Plus가 있고 split_clients기능을 수행한다면, 그 존재감을 활용하고 유익한 보안 기능을 추가하는 건 어떨까요? 보안을 강화하는 데 사용할 수 있는 NGINX Plus 기능 몇 가지와 이를 구성, 테스트, 배포하는 데 사용할 수 있는 다른 문서에 대한 링크와 참조가 있습니다.

  • IP 차단/허용 목록 – 소스 IP 주소에 따라 액세스를 제어합니다. NGINX Docs의 IP 주소 동적 거부 목록 페이지 에서 Plus API를 사용하여 동적 IP 차단/허용 목록에 NGINX Plus 키-값 저장소를 사용하는 방법에 대한 구성 가이드를 찾을 수 있습니다 .
  • 속도 제한 - 애플리케이션, API 엔드포인트 및 미디어 다운로드에 대한 TCP 연결 수, HTTP 요청 및 대역폭 사용량을 제어합니다. NGINX를 사용한 속도 제한에 대한 자세한 내용은 NGINX Docs의 Limiting Access to Proxied HTTP Resources 와 블로그 게시물 Rate Limiting with NGINX and NGINX Plus 및 Dynamic Bandwidth Limits Using the NGINX Plus Key-Value Store를 참조하세요 .
  • GeoIP2 동적 모듈 - 소스 IP 주소에 따라 위치 메타데이터를 수집합니다. NGINX Docs의 지리적 위치에 따른 액세스 제한 페이지 에서 이에 대해 자세히 알아보세요 .
  • JWT 및 OpenID Connect(OIDC) 모듈 – 업계 표준 프로토콜로 사용자 액세스를 제어합니다. 이에 대한 자세한 내용은 NGINX Docs의 Setting up JWT Authentication 페이지에서 확인할 수 있습니다.
  • NGINX App Protect – 기존 및 진화하는 위협으로부터 보호하는 가볍고 지연 시간이 짧은 웹 애플리케이션 방화벽 입니다.




위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기


프로필 이미지
관리자
2025-01-17
조회 1

Kubernetes에서 인공 지능(AI) 및 머신 러닝(ML) 모델 학습 및 추론을 실행할 때 동적 확장 및 축소가 중요한 요소가 됩니다. 데이터를 수집하기 위해 고대역폭 스토리지와 네트워킹이 필요할 뿐만 아니라 AI 모델 학습에는 대부분 GPU 또는 기타 특수 프로세서에서 나오는 상당한(그리고 값비싼) 컴퓨팅도 필요합니다. 사전 학습된 모델을 활용하더라도 프로덕션에서 모델 제공 및 미세 조정과 같은 작업은 여전히 대부분의 엔터프라이즈 워크로드보다 컴퓨팅 집약적입니다.

클라우드 네이티브 쿠버네티스는 빠른 확장성을 위해 설계되었습니다. 또한 하이브리드, 멀티 클라우드 환경에서 동적 워크로드에 대한 민첩성과 비용 효율적인 리소스 사용을 제공하도록 설계되었습니다.

이 블로그에서는 Kubernetes에서 AI/ML 워크로드를 확장하는 가장 일반적인 세 가지 방법을 다룹니다. 이를 통해 다양한 환경에서 동적 확장에 대한 최적의 성능, 비용 절감 및 적응성을 얻을 수 있습니다.


Kubernetes에서 AI/ML 워크로드를 위한 3가지 확장 모달리티

Kubernetes가 작업 부하를 확장하는 세 가지 일반적인 방법은 수평적 Pod 자동 확장기(HPA), 수직적 Pod 자동 확장기(VPA), 클러스터 자동 확장기입니다.

세 가지 방법을 자세히 살펴보면 다음과 같습니다.

  • HPA – 애플리케이션에 인스턴스나 Pod 복제본을 추가하는 것과 동일하여 확장성, 용량, 처리량을 더 높여줍니다.
  • VPA – 더 높은 컴퓨팅 및 메모리로 더 높은 용량을 제공하기 위해 포드 크기를 조정하는 것과 같습니다.
  • 클러스터 자동 확장기 – 포드의 현재 리소스 수요에 따라 Kubernetes 클러스터의 노드 수를 자동으로 늘리거나 줄입니다.

각 모달리티는 모델 학습 및 추론에 있어서 각자의 이점을 가지고 있으며, 아래 사용 사례를 통해 이를 알아볼 수 있습니다.


HPA 사용 사례

많은 경우 분산형 AI 모델 학습 및 추론 워크로드는 수평적으로 확장할 수 있습니다(즉, 학습 프로세스 또는 요청 처리를 가속화하기 위해 더 많은 포드를 추가). 이를 통해 워크로드는 HPA의 이점을 얻을 수 있으며, CPU 및 메모리 사용과 같은 메트릭 또는 워크로드와 관련된 사용자 지정 및 외부 메트릭을 기반으로 포드 수를 확장할 수 있습니다. 워크로드가 시간에 따라 달라지는 시나리오에서 HPA는 최적의 리소스 활용을 보장하기 위해 포드 수를 동적으로 조정할 수 있습니다.

쿠버네티스에서 AI 워크로드를 수평적으로 확장하는 또 다른 측면은 로드 밸런싱입니다. 최적의 성능과 적시에 요청을 처리하려면 들어오는 요청을 여러 인스턴스 또는 포드에 분산해야 합니다. 이것이 HPA와 함께 사용할 수 있는 이상적인 도구 중 하나가 Ingress 컨트롤러 인 이유입니다 .


VPA 사용 사례

AI 모델 학습 작업은 종종 리소스 집약적이어서 상당한 CPU, GPU 및 메모리 리소스가 필요합니다. VPA는 이러한 리소스 할당을 동적으로 조정할 수 있습니다. 이를 통해 각 포드가 학습 워크로드를 효율적으로 처리할 수 있는 충분한 리소스를 확보하고 할당된 모든 포드가 계산을 수행할 수 있는 충분한 컴퓨팅 용량을 확보할 수 있습니다. 또한 메모리 요구 사항은 대규모 모델을 학습하는 동안 상당히 변동될 수 있습니다. VPA는 필요에 따라 메모리 할당을 늘려 메모리 부족 오류를 방지하는 데 도움이 될 수 있습니다.

기술적으로 HPA와 VPA를 함께 사용하는 것은 가능하지만, 서로 다른 방식(즉, 수평 대 수직)으로 동일한 작업 부하를 확장하려고 할 수 있으므로 충돌을 피하기 위해 신중하게 구성해야 합니다. 각 자동 확장기의 경계를 명확하게 정의하여 서로 충돌하지 않고 보완하도록 하는 것이 중요합니다. 새로운 접근 방식은 두 가지를 서로 다른 범위로 사용하는 것입니다. 예를 들어, HPA는 작업 부하에 따라 여러 포드에 걸쳐 확장하고 VPA는 HPA에서 설정한 제한 내에서 각 포드의 리소스 할당을 미세 조정하는 데 사용합니다.


클러스터 자동 확장기 사용 사례

클러스터 오토스케일러는 AI/ML 워크로드의 수요를 충족하기 위해 클러스터 전체에서 사용 가능한 컴퓨팅, 스토리지 및 네트워킹 인프라 리소스의 전체 풀을 동적으로 조정하는 데 도움이 될 수 있습니다. 현재 수요에 따라 클러스터의 노드 수를 조정함으로써 조직은 거시 수준에서 로드 밸런싱을 수행할 수 있습니다. 이는 AI/ML 워크로드가 예측할 수 없이 상당한 컴퓨팅 리소스를 요구할 수 있으므로 최적의 성능을 보장하는 데 필요합니다.


HPA, VPA 및 클러스터 자동 확장기에는 각각 역할이 있습니다.

요약하자면 Kubernetes 자동 확장이 작동하고 AI 워크로드에 도움이 되는 세 가지 방법은 다음과 같습니다.

  • HPA는 다양한 요청 속도를 처리해야 하는 엔드포인트에 서비스를 제공하는 AI 모델을 확장합니다.
  • VPA는 AI/ML 워크로드에 대한 리소스 할당을 최적화하고 과도한 프로비저닝 없이 효율적인 처리를 위해 각 Pod에 충분한 리소스가 확보되도록 보장합니다.
  • 클러스터 자동 스케일러는 리소스 집약적 AI 작업을 수용할 수 있도록 클러스터에 노드를 추가하거나 컴퓨팅 수요가 낮으면 노드를 제거합니다.

HPA, VPA 및 Cluster Autoscaler는 Kubernetes에서 AI/ML 워크로드를 관리하는 데 있어 서로를 보완합니다. Cluster Autoscaler는 워크로드 수요를 충족할 수 있는 충분한 노드가 있는지 확인하고, HPA는 여러 포드에 워크로드를 효율적으로 분산하며, VPA는 이러한 포드의 리소스 할당을 최적화합니다. 함께 Kubernetes 환경에서 AI/ML 애플리케이션을 위한 포괄적인 확장 및 리소스 관리 솔루션을 제공합니다.



위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요



전문가에게 상담받기