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 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
당신은 현대적 Platform Ops 또는 DevOps 엔지니어입니다. 당신은 오픈 소스(그리고 아마도 일부 상업용) 도구 라이브러리를 사용하여 개발팀을 위한 새로운 앱과 컨테이너를 테스트, 배포 및 관리합니다. 당신은 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 포드를 실행하기 위해 Kubernetes를 선택했습니다. 당신은 마이크로서비스의 아키텍처와 개념을 받아들였고, 대부분 잘 작동합니다. 그러나 이 여정에서 몇 가지 속도 범프에 부딪혔습니다.
예를 들어, 새로운 클러스터, 서비스 및 애플리케이션을 빌드하고 출시할 때 트래픽을 끊지 않고 이러한 새로운 리소스를 프로덕션에 쉽게 통합하거나 마이그레이션하려면 어떻게 해야 할까요? 기존 네트워킹 어플라이언스는 DNS 레코드, 로드 밸런서, 방화벽 및 프록시에 대한 구성 변경을 구현할 때 다시 로드하거나 재부팅해야 합니다. 이러한 조정은 DNS, 로드 밸런서 및 방화벽 규칙을 업데이트하는 데 "서비스 중단" 또는 "유지 관리 창"이 필요하기 때문에 다운타임을 발생시키지 않고는 재구성할 수 없습니다. 대부분의 경우, 두려운 서비스 티켓을 제출하고 다른 팀이 승인하고 변경을 수행할 때까지 기다려야 합니다.
유지 관리 창은 팀을 도랑에 빠뜨리고, 애플리케이션 제공을 멈추고, "트래픽을 관리하는 더 나은 방법이 있어야 한다!"고 선언하게 만들 수 있습니다. 따라서 빠른 차선으로 돌아갈 수 있는 솔루션을 살펴보겠습니다.
액티브-액티브 멀티 클러스터 로드 밸런싱
여러 개의 Kubernetes 클러스터가 있는 경우 두 클러스터로 동시에 트래픽을 라우팅하는 것이 이상적입니다. 더 나은 옵션은 A/B, 카나리아 또는 블루-그린 트래픽 분할을 수행하고 트래픽의 작은 비율을 테스트로 보내는 것입니다. 이를 위해 NGINX Plus를 ngx_http_split_clients_module.
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으로 변경합니다.
다음으로, 사전 프로덕션 테스트 팀은 새로운 애플리케이션 코드가 준비되었는지 확인하고, 이를 대규모 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임을 알 수 있습니다.
그러면 12:56:30에서는 비율이 10:90으로 바뀐다.
그러면 13:00:00에 90:10으로 변경됩니다.
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 인스턴스를 추가하여 고가용성을 달성할 수 있습니다 .
Kubernetes용 NGINX 로드밸런서의 작동 스냅샷
아래 스크린샷에는 Kubernetes용 NGINX Loadbalancer가 배포되어 작업을 수행하는 모습을 보여주는 두 개의 창이 있습니다.
서비스LoadBalancer 유형 –nginx-ingress
외부 IP – NGINX Plus 서버에 연결
포트 - NodePort는 NGINX 업스트림 서버와 일치하는 443:30158에 매핑됩니다(NGINX Plus 실시간 대시보드 에 표시됨 )
로그 - Kubernetes용 NGINX 로드밸런서가 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 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
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 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
2023년 10월 25일, 미국 국립표준기술원(NIST)은 Kubernetes용 NGINX Ingress Controller에 영향을 미치는 3개의 CVE를 보고했습니다 .
CVE-2022-4886 – ingress-nginx 경로 정리는 directive를 통해 우회될 수 있음 log_format.
CVE-2023-5043 – ingress-nginx 주석 주입으로 인해 임의의 명령 실행이 발생합니다.
CVE-2023-5044 – nginx.ingress.kubernetes.io/permanent-redirect 주석을 통해 코드 주입이 발생합니다.
해당 보고서와 후속 출판물(긴급 : Kubernetes용 NGINX Ingress 컨트롤러에서 새로운 보안 결함 발견 )은 어떤 NGINX Ingress 컨트롤러가 실제로 영향을 받는지, 그리고 이러한 CVE에 설명된 취약점을 해결하는 데 누가 관여해야 하는지에 대한 혼란(및 여러 지원 문의)을 야기했습니다.
혼란은 완전히 이해할 수 있습니다. NGINX 기반 Ingress 컨트롤러가 두 개 이상 있다는 것을 알고 계셨나요? 시작으로, "NGINX Ingress Controller"라는 완전히 다른 두 프로젝트가 있습니다.
커뮤니티 프로젝트 – GitHub의 kubernetes/ingress-nginx 리포지토리에서 발견된 이 Ingress 컨트롤러는 NGINX 오픈 소스 데이터 플레인을 기반으로 하지만 Kubernetes 커뮤니티에서 개발 및 유지 관리하고 있으며 문서는 GitHub에 호스팅됩니다 .
NGINX 프로젝트 – GitHub의 nginxinc/kubernetes -ingress repo 에서 찾을 수 있는 NGINX Ingress Controller는 F5 NGINX에서 개발 및 유지 관리하며 docs.nginx.com에 문서가 있습니다 . 이 공식 NGINX 프로젝트는 두 가지 버전으로 제공됩니다.
NGINX 오픈 소스 기반(무료 및 오픈 소스 옵션)
NGINX Plus 기반(상업용 옵션)
NGINX를 기반으로 하는 다른 Ingress 컨트롤러도 있는데, Kong이 있습니다. 다행히도, 이름은 쉽게 구별할 수 있습니다. 어떤 것을 사용하는지 잘 모르겠다면 실행 중인 Ingress 컨트롤러의 컨테이너 이미지를 확인한 다음 Docker 이미지 이름을 위에 나열된 리포와 비교하세요.
위에 설명된 취약점(CVE-2022-4886, CVE-2023-5043 및 CVE-2023-5044)은 커뮤니티 프로젝트 ( kubernetes/ingress-nginx )에만 적용됩니다. NGINX Ingress Controller( nginxinc/kubernetes-ingress , 오픈소스 및 상업용)에 대한 NGINX 프로젝트는 이러한 CVE의 영향을 받지 않습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
당신은 현대적 앱 개발자입니다. 오픈 소스와 아마도 일부 상용 도구 모음을 사용하여 새로운 앱과 컨테이너를 작성, 테스트, 배포 및 관리합니다. 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 포드를 실행하기 위해 Kubernetes를 선택했습니다. 마이크로서비스의 아키텍처와 개념, Cloud Native Computing Foundation 및 기타 현대적 산업 표준을 도입했습니다.
이 여정에서 여러분은 쿠버네티스가 실제로 강력하다는 것을 알게 되었습니다. 하지만 여러분은 쿠버네티스가 얼마나 어렵고, 유연하지 않으며, 좌절스러울 수 있는지에 놀랐을 것입니다. 라우터, 방화벽, 로드 밸런서 및 기타 네트워크 장치에 대한 변경 사항과 업데이트를 구현하고 조정하는 것은 압도적일 수 있습니다. 특히 자체 데이터 센터에서는 더욱 그렇습니다! 개발자를 눈물 흘리게 만들기에 충분합니다.
이러한 과제를 어떻게 처리하는지는 Kubernetes를 어디서 어떻게 실행하는지(관리형 서비스 또는 온프레미스)와 많은 관련이 있습니다. 이 문서에서는 배포 선택이 사용 편의성에 영향을 미치는 주요 영역인 TCP 로드 밸런싱을 다룹니다.
관리형 Kubernetes를 사용한 TCP 부하 분산(일명 Easy Option)
Kubernetes용 퍼블릭 클라우드 공급자와 같은 관리형 서비스를 사용하면 지루한 네트워킹 작업의 대부분이 처리됩니다. 단 하나의 명령( kubectl apply -f loadbalancer.yaml) 으로 서비스 유형 LoadBalancer는 퍼블릭 IP, DNS 레코드 및 TCP 로드 밸런서를 제공합니다. 예를 들어, NGINX Ingress Controller가 포함된 포드에 트래픽을 분산하도록 Amazon Elastic Load Balancer를 구성하고 이 명령을 사용하면 백엔드가 변경될 때 걱정할 필요가 없습니다. 너무 쉽기 때문에 당연하게 여기실 겁니다!
온프레미스 Kubernetes를 사용한 TCP 부하 분산(일명 하드 옵션)
온프레미스 클러스터의 경우 완전히 다른 시나리오입니다. 귀하 또는 네트워킹 피어가 네트워킹 부분을 제공해야 합니다. "왜 사용자를 내 Kubernetes 앱으로 유도하는 것이 이렇게 어려울까?"라고 궁금해할 수 있습니다. 답은 간단하지만 약간 충격적입니다. 클러스터의 정문인 서비스 유형 LoadBalancer는 실제로 존재하지 않습니다.
클러스터 외부에 앱과 서비스를 노출하려면 네트워크 팀에서 티켓, 승인, 절차, 심지어 보안 검토까지 필요할 수 있습니다. 이 모든 것이 장비를 재구성하기 전에 필요합니다. 아니면 모든 것을 직접 해야 할 수도 있는데, 그러면 애플리케이션 제공 속도가 엄청나게 느려질 수 있습니다. 더 나쁜 것은 Kubernetes 서비스를 변경하지 않는 것입니다. NodePort 가 변경되면 트래픽이 차단될 수 있기 때문입니다! 그리고 사용자들이 500 오류를 얼마나 좋아하는지 우리 모두 알고 있습니다. 상사는 아마 더 싫어할 것입니다.
온프레미스 TCP 로드 밸런싱을 위한 더 나은 솔루션: Kubernetes용 NGINX 로드 밸런서
새로운 프로젝트인 Kubernetes용 NGINX 로드밸런서를 사용하면 "하드 옵션"을 "쉬운 옵션"으로 바꿀 수 있습니다 . 이 무료 프로젝트는 NGINX Ingress Controller를 감시하고 로드 밸런싱을 위해 구성된 외부 NGINX Plus 인스턴스를 자동으로 업데이트하는 Kubernetes 컨트롤러 입니다 . 매우 간단한 설계로 설치 및 작동이 간편합니다. 이 솔루션을 사용하면 온프레미스 환경에서 TCP 로드 밸런싱을 구현하여 새로운 앱과 서비스를 즉시 감지하고 트래픽에 사용할 수 있습니다. 직접 작업할 필요가 없습니다.
Architecture와 Flow
Kubernetes용 NGINX 로드밸런서는 Kubernetes 클러스터 내부에 있습니다. Kubernetes에 등록되어 nginx-ingress 서비스(NGINX Ingress Controller)를 감시합니다. 백엔드가 변경되면 Kubernetes용 NGINX 로드밸런서는 Worker IP와 NodePort TCP 포트 번호를 수집한 다음 NGINX Plus API를 통해 IP:ports를 NGINX Plus로 전송합니다 . NGINX 업스트림 서버는 로 업데이트되고 NGINX Plus는 트래픽을 올바른 업스트림 서버와 Kubernetes NodePorts로 로드밸런싱합니다. 추가 NGINX Plus 인스턴스를 추가하여 고가용성을no reload required 달성할 수 있습니다 .
Kubernetes용 NGINX 로드밸런서의 작동 스냅샷
아래 스크린샷에는 Kubernetes용 NGINX Loadbalancer가 배포되어 작업을 수행하는 모습을 보여주는 두 개의 창이 있습니다.
서비스 유형 – LoadBalancer(용 nginx-ingress)
외부 IP – NGINX Plus 서버에 연결
포트 - NodePort는 NGINX 업스트림 서버와 일치하는 443:30158에 매핑됩니다(NGINX Plus 실시간 대시보드 에 표시됨 )
로그 - Kubernetes용 NGINX 로드밸런서가 NGINX Plus로 데이터를 성공적으로 전송하고 있음을 나타냄
참고 : 이 예에서 Kubernetes 워커 노드는 10.1.1.8 및 10.1.1.10입니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
이러한 말은 대부분의 다른 산업보다 의료 기술 분야의 회사에 더 해당됩니다. 그들의 경우 "심각한 결과"에는 문자 그대로 사망이 포함될 수 있습니다. 우리는 최근에 의료 기록 보관을 펜과 종이에서 언제 어디서나 액세스할 수 있는 안전한 디지털 데이터로 전환하려는 회사의 기술 스택을 분석할 기회를 가졌습니다. 이러한 데이터는 환자 정보에서 치료 지침, 생물학적 마커, 의료 분석, 과거 기록 및 의료 팀 간에 공유되는 모든 것에 이르기까지 다양합니다.
처음부터 이 회사는 겉보기에 간단한 질문인 "케어 종사자가 실시간으로 데이터를 쉽게 기록하도록 어떻게 도울 수 있을까?"를 해결하고자 했습니다. 그러나 회사가 성장함에 따라 확장하고 데이터를 지속적으로 사용할 수 있게 해야 하는 필요성으로 인해 이 과제를 해결하는 것이 점점 더 복잡해졌습니다. 여기서는 이 회사의 기술 여정이 어떻게 Kubernetes 와 NGINX Ingress Controller를 도입하게 되었는지 설명합니다 .
기술 스택을 한눈에 보기
OS – 리눅스
컨테이너 오케스트레이션 – Microsoft Azure Kubernetes Service
네트워킹 – Kubernetes , NGINX Plus 기반 NGINX Ingress Controller
소프트웨어 개발 언어/프레임워크 – .Net
모니터링, 관찰성 및 경고 – Prometheus
모니터링 대시보드 – Grafana
로깅 – Grafana Loki
데이터베이스 – Azure SQL 서비스
애플리케이션 서버 - Azure App Service , .Net
메시징 및 스트리밍 – Azure Event Hubs
캐싱 – Redis
보안 – NGINX 앱 보호
위치 및 인프라 – 2개의 가용성 영역, 2개의 Kubernetes 클러스터, 15~20개의 노드, 60~100개의 포드
DevOps – Azure DevOps 서비스
NGINX가 해당 아키텍처에서 어떻게 적용되는지 살펴보겠습니다.
종이의 문제
정기적으로 환자 상태와 치료 정보를 수집하는 것은 의료 종사자의 핵심 임무입니다. 전통적으로 그들은 환자 정보를 종이에 기록했거나, 최근에는 노트북이나 태블릿에 기록했습니다. 몇 가지 심각한 단점이 있습니다.
의료 종사자는 하루에 수십 명의 환자와 상호 작용할 수 있으므로 치료를 제공하는 동안 자세한 메모를 작성하는 것은 일반적으로 실용적이지 않습니다. 결과적으로 근로자는 교대 근무가 끝날 때 메모를 작성하게 됩니다. 그 시점에서 정신적, 신체적 피로로 인해 일반적인 의견만 기록하고 싶어집니다.
근로자는 또한 환자 행동에 대한 세부 사항에 대한 기억에 의존해야 합니다. 부정확한 내용은 시간이 지남에 따라 정확하고 일관되게 문서화되면 더 큰 건강 문제의 진단을 용이하게 하는 패턴을 가릴 수 있습니다.
종이 기록은 단일 부서 내의 부서 간에 쉽게 공유할 수 없으며, EMT, 응급실 직원, 보험 회사와 같은 다른 기관과는 더더욱 그렇습니다. 노트북이나 태블릿이 중앙 데이터 저장소나 클라우드에 연결되지 않은 경우 상황은 크게 나아지지 않습니다.
이러한 과제를 해결하기 위해 회사는 환자 정보에 액세스하고 약물 분배와 같은 일반적인 이벤트를 기록하기 위한 단축키를 제공하는 간소화된 데이터 기록 시스템을 만들었습니다. 이러한 액세스 및 사용의 용이성 덕분에 환자 상호작용을 발생하는 대로 실시간으로 기록할 수 있습니다.
모든 데이터는 회사에서 관리하는 클라우드 시스템에 저장되며, 앱은 다른 전자 의료 기록 시스템과 통합되어 거주자 행동에 대한 포괄적인 종단적 관점을 제공합니다. 이를 통해 간병인은 더 나은 치료 연속성을 제공하고, 안전한 과거 기록을 생성하며, 다른 의료 소프트웨어 시스템과 쉽게 공유할 수 있습니다.
의사와 다른 전문가도 환자를 입원시키거나 다른 방식으로 환자와 교류할 때 이 플랫폼을 사용합니다. 환자와 함께 모든 시설로 이동하는 선호도와 개인적 필요 사항의 기록이 있습니다. 이를 사용하여 환자가 새로운 환경에서 편안함을 느끼도록 도울 수 있으며, 이는 회복 시간과 같은 결과를 개선합니다.
회사가 환자 데이터를 얼마나 오랫동안 보관해야 하는지에 대한 엄격한 법적 요구 사항이 있습니다. 이 회사의 개발자는 일반 클라우드 애플리케이션보다 훨씬 더 나은 가동 시간 SLA로 매우 높은 가용성을 제공하는 소프트웨어를 구축했습니다. 환자의 파일이 로드되지 않아서 구급차를 기다리게 하는 것은 선택 사항이 아닙니다.
차고에서 클라우드로, 그리고 쿠버네티스로의 여행
많은 스타트업과 마찬가지로 이 회사는 공동 창업자의 집에 있는 서버에서 최초의 개념 증명 애플리케이션을 실행하여 처음에 비용을 절감했습니다. 이 아이디어가 타당하다는 것이 분명해지자 회사는 데이터 센터에서 하드웨어를 관리하는 대신 인프라를 클라우드로 옮겼습니다. Microsoft 매장인 그들은 Azure를 선택했습니다. 초기 아키텍처는 Microsoft의 IIS 웹 서버를 실행하는 관리형 애플리케이션 제공 서비스인 Azure App Service의 기존 가상 머신(VM)에서 애플리케이션을 실행했습니다. 데이터 저장 및 검색을 위해 이 회사는 VM에서 실행되는 Microsoft의 SQL Server를 관리형 애플리케이션으로 사용하기로 했습니다.
클라우드에서 수년간 운영한 후, 회사는 빠르게 성장하고 확장의 어려움을 겪었습니다. 회사는 무한히 확장해야 했고, VM을 사용하면 수직이 느리고 비용이 많이 들기 때문에 수평이 아닌 수평으로 확장해야 했습니다. 이러한 요구 사항으로 인해 컨테이너화와 Kubernetes가 가능한 솔루션으로 자연스럽게 이어졌습니다. 컨테이너화를 지지하는 또 다른 요점은 회사 개발자가 중단 위험 없이 애플리케이션과 인프라에 대한 업데이트를 자주 제공해야 한다는 것입니다. 환자 기록이 여러 시간대에 걸쳐 지속적으로 추가되면서 고객이 결함으로 인해 즉시 영향을 받을 위험 없이 프로덕션에 변경 사항을 푸시할 자연스러운 다운타임이 없습니다.
회사의 논리적인 시작점은 Microsoft의 관리형 Kubernetes 오퍼링인 Azure Kubernetes Services(AKS)였습니다. 팀은 Kubernetes 모범 사례를 조사하고 AKS의 노드와 포드에서 실행되는 트래픽과 애플리케이션을 효과적으로 관리하기 위해 Kubernetes 클러스터 앞에서 실행되는 Ingress 컨트롤러가 필요 하다는 것을 깨달았습니다.
Traffic 경로는 유연하면서도 정확해야 합니다.
팀은 AKS의 기본 Ingress 컨트롤러를 테스트했지만, 트래픽 라우팅 기능이 회사 고객에게 필요한 방식으로 업데이트를 제공할 수 없다는 것을 발견했습니다. 환자 케어에 관해서는 모호함이나 상충되는 정보에 대한 여지가 없습니다. 예를 들어, 한 케어 종사자가 주황색 플래그를 보고 다른 케어 종사자가 같은 이벤트에 대해 빨간색 플래그를 보는 것은 용납할 수 없습니다. 따라서 주어진 조직의 모든 사용자는 동일한 버전의 앱을 사용해야 합니다. 이는 업그레이드와 관련하여 큰 과제입니다. 고객을 새 버전으로 전환할 자연스러운 시기가 없으므로 회사는 서버 및 네트워크 수준에서 규칙을 사용하여 다른 고객을 다른 앱 버전으로 라우팅할 방법이 필요했습니다.
이를 달성하기 위해 이 회사는 조직의 모든 사용자에게 동일한 백엔드 플랫폼을 실행하고 조직 내 인프라 계층에서 세분화된 다중 테넌시를 제공하지 않습니다. Kubernetes를 사용하면 자세한 트래픽 규칙과 함께 브라우저의 가상 네트워크 경로 및 쿠키를 사용하여 트래픽을 분할할 수 있습니다. 그러나 이 회사의 기술 팀은 AKS의 기본 Ingress 컨트롤러는 필요에 따라 고객 조직 또는 개별 사용자 수준에서 작동하는 규칙이 아닌 백분율 기준으로만 트래픽을 분할할 수 있다는 것을 발견했습니다.
기본 구성에서 NGINX Open Source를 기반으로 하는 NGINX Ingress Controller는 동일한 제한이 있으므로 회사는 세분화된 트래픽 제어를 지원하는 엔터프라이즈급 제품인 NGINX Plus를 기반으로 하는 보다 고급 NGINX Ingress Controller로 전환하기로 결정했습니다. 높은 수준의 유연성과 제어를 기반으로 Microsoft와 Kubernetes 커뮤니티의 NGINX Ingress Controller에서 권장 사항을 찾은 것은 선택을 확고히 하는 데 도움이 되었습니다. 이 구성은 포드 관리(클래식 트래픽 관리와 대조적으로)에 대한 회사의 요구 사항을 더 잘 지원하여 포드가 적절한 영역에서 실행되고 트래픽이 해당 서비스로 라우팅되도록 합니다. 때로는 트래픽이 내부적으로 라우팅되지만 대부분의 사용 사례에서는 관찰 가능성을 위해 NGINX Ingress Controller를 통해 다시 라우팅됩니다.
Here Be Dragons: 모니터링, 관찰성 및 애플리케이션 성능
NGINX Ingress Controller를 사용하면 기술팀이 개발자와 최종 사용자 경험을 완벽하게 제어할 수 있습니다. 사용자가 로그인하여 세션을 설정하면 즉시 새 버전으로 라우팅되거나 이전 버전으로 되돌릴 수 있습니다. 패치는 조직의 모든 사용자에게 동시에 거의 즉시 푸시될 수 있습니다. 소프트웨어는 클라우드 플랫폼 전반의 네트워킹에 대한 DNS 전파나 업데이트에 의존하지 않습니다.
NGINX Ingress Controller는 또한 회사의 세부적이고 지속적인 모니터링 요구 사항을 충족합니다. 애플리케이션 성능은 의료 분야에서 매우 중요합니다. 지연이나 가동 중지 시간은 특히 생사의 상황에서 성공적인 임상 치료를 방해할 수 있습니다. Kubernetes로 이전한 후, 고객들은 회사에서 알아차리지 못한 가동 중지 시간을 보고하기 시작했습니다. 회사는 곧 문제의 근원을 발견했습니다. Azure App Service는 샘플링된 데이터에 의존합니다. 샘플링은 평균 및 광범위한 추세에는 적합하지만 거부된 요청 및 누락된 리소스와 같은 사항은 완전히 놓칩니다. 또한 간병인이 체크인하고 환자 데이터를 기록할 때 일반적으로 30분마다 발생하는 사용량 급증도 표시하지 않습니다. 회사는 지연, 오류 소스, 잘못된 요청 및 사용할 수 없는 서비스에 대한 불완전한 그림만 얻었습니다.
문제는 거기서 끝나지 않았습니다. 기본적으로 Azure App Service는 저장된 데이터를 한 달 동안만 보존합니다. 많은 국가의 법률에서 요구하는 수십 년보다 훨씬 짧습니다. 더 오래 보존하기 위해 필요에 따라 데이터 저장소를 확장하는 것은 엄청나게 비쌌습니다. 게다가 Azure 솔루션은 Kubernetes 네트워킹 스택 내부를 볼 수 없습니다. NGINX Ingress Controller는 4계층과 7계층 트래픽을 처리할 때 인프라와 애플리케이션 매개변수를 모두 모니터링할 수 있습니다.
성능 모니터링 및 관찰성을 위해 이 회사는 Grafana 시각화 엔진 및 대시보드에 연결된 Prometheus 시계열 데이터베이스를 선택했습니다. Prometheus와 Grafana와의 통합은 NGINX 데이터 및 제어 평면에 미리 구워져 있으며, 기술 팀은 모든 트래픽을 Prometheus 및 Grafana 서버를 통해 전달하기 위해 작은 구성 변경만 하면 되었습니다. 이 정보는 또한 Grafana Loki 로깅 데이터베이스로 라우팅되어 로그를 분석하기 쉬워졌고 소프트웨어 팀이 시간이 지남에 따라 데이터를 더 잘 제어할 수 있게 되었습니다.
이 구성은 또한 문제 해결 및 버그 수정을 위해 매우 빈번하고 방대한 양의 데이터 샘플링이 필요한 사고에 대비하여 미래를 보호합니다. 대부분의 대형 클라우드 회사에서 제공하는 애플리케이션 모니터링 시스템으로는 이러한 유형의 사고를 해결하는 데 비용이 많이 들 수 있지만 이 사용 사례에서 Prometheus, Grafana 및 Loki의 비용과 오버헤드는 최소입니다. 세 가지 모두 안정적인 오픈 소스 제품으로 일반적으로 초기 튜닝 후 패치만 하면 됩니다.
Routing 유지: 고가용성 및 보안에 집중
이 회사는 항상 가장 민감한 데이터 유형 중 하나를 보호하기 위한 보안과 필요할 때마다 앱을 사용할 수 있도록 하는 고가용성 에 중점을 두었습니다 . Kubernetes로 전환하면서 두 가지 용량을 모두 확장하기 위해 몇 가지 변경을 했습니다.
가장 높은 가용성을 위해 기술 팀은 단일 장애 지점 없이 완전한 중복성을 위해 액티브-액티브, 멀티 존, 멀티 지오 분산 인프라 설계를 구축합니다. 팀은 두 개의 다른 지리적 지역에 듀얼 쿠버네티스 클러스터가 있는 N+2 액티브-액티브 인프라를 유지 관리합니다. 각 지리적 지역 내에서 소프트웨어는 여러 데이터 센터에 걸쳐 다운타임 위험을 줄이고 인프라의 모든 계층에서 장애가 발생할 경우 적용 범위를 제공합니다. 친화성 및 반친화성 규칙은 사용자와 트래픽을 즉시 가동 중인 포드로 다시 라우팅하여 서비스 중단을 방지할 수 있습니다.
보안을 위해 팀은 잘못된 요청과 악의적인 행위자로부터 보호하기 위해 웹 애플리케이션 방화벽 (WAF)을 배포합니다. OWASP Top 10 에 대한 보호 는 대부분 WAF에서 제공하는 기본 사항입니다. 앱을 만들 때 팀은 기본 Azure WAF와 ModSecurity를 포함한 여러 WAF를 조사했습니다. 결국 팀은 인라인 WAF와 분산 서비스 거부 (DDoS) 보호 기능이 있는 NGINX App Protect를 선택했습니다.
NGINX App Protect의 큰 장점은 NGINX Ingress Controller와 함께 배치되어 중복 지점을 제거하고 지연 시간을 줄이는 것입니다. 다른 WAF는 Kubernetes 환경 외부에 배치해야 하므로 지연 시간과 비용이 증가합니다. 아주 사소한 지연(요청당 1밀리초 추가)도 시간이 지남에 따라 빠르게 누적됩니다.
서프라이즈 사이드 퀘스트: 개발자를 위한 다운타임 없음
대부분의 애플리케이션 및 네트워킹 인프라에 대해 AKS로의 전환을 완료한 이 회사는 개발자 경험(DevEx)에서도 상당한 개선을 이루었습니다. 이제 개발자는 고객이 문제를 알아차리기 전에 거의 항상 문제를 발견합니다. 전환 이후 오류에 대한 지원 전화의 양이 약 80% 감소했습니다!
회사의 보안 및 애플리케이션 성능 팀은 자세한 Grafana 대시보드와 통합 알림을 갖추고 있어 여러 시스템을 확인하거나 다른 프로세스에서 오는 경고 텍스트 및 호출에 대한 트리거를 구현할 필요가 없습니다. 개발 및 DevOps 팀은 이제 코드 및 인프라 업데이트를 매일 또는 하루에 여러 번 제공하고 매우 세부적인 청록색 패턴을 사용할 수 있습니다. 이전에는 일주일에 한두 번 업데이트를 제공하고 사용량이 적은 시간대에 시간을 내야 했으며 이는 스트레스가 많은 제안이었습니다. 이제 코드는 준비되면 제공되고 개발자는 애플리케이션 동작을 관찰하여 영향을 직접 모니터링할 수 있습니다.
결과는 전반적으로 긍정적입니다. 소프트웨어 개발 속도가 빨라지고, 개발자의 사기가 향상되고, 생명이 더 많이 구해졌습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
저희는 2023년 1월에 NGINX Ingress Controller 의 버전 3.0을 출시했으며, 여기에는 중요한 새로운 기능과 향상된 기능이 다수 포함되었습니다. 여러분께 특히 가치 있다고 생각되는 새로운 기능 중 하나는 NGINX Ingress Controller의 NGINX Plus 에디션에서 제공되는 Deep Service Insight입니다.
Deep Service Insight는 로드 밸런서와 같은 라우팅 결정 시스템이 하나 이상의 Kubernetes 클러스터 앞에 있을 때 최적의 기능을 방해하는 제한 사항을 해결합니다. 즉, 시스템은 Ingress 컨트롤러 뒤의 클러스터에서 실행되는 개별 서비스의 상태에 대한 정보에 액세스할 수 없습니다. 이를 통해 트래픽을 정상적인 서비스가 있는 클러스터로만 라우팅하지 못하게 되어 사용자를 중단 및 오류(예: 404) 에 노출시킬 가능성이 있습니다 500.
Deep Service Insight는 NGINX Ingress Controller에서 수집한 백엔드 서비스 포드의 상태를 전용 엔드포인트에 노출하여 시스템에서 액세스하고 더 나은 라우팅 결정을 내리는 데 활용할 수 있도록 함으로써 이러한 문제를 해결합니다.
이 게시물에서는 Deep Service Insight가 해결하는 문제를 자세히 살펴보고, 몇 가지 일반적인 사용 사례에서 이 기능이 어떻게 작동하는지 설명하고, 이를 구성하는 방법을 보여드리겠습니다.
왜 Deep Service Insight가 필요한가요?
표준 Kubernetes 라이브니스, 준비성 및 시작 프로브는 클러스터에서 실행되는 백엔드 서비스에 대한 정보를 제공하지만 스택 전체에 걸쳐 더 나은 라우팅 결정을 내리는 데 필요한 통찰력을 제공하기에는 충분하지 않습니다. Kubernetes 배포가 복잡해지고 중단 없는 가동 시간에 대한 비즈니스 요구 사항이 더 시급해짐에 따라 올바른 정보가 부족하면 문제가 더 커집니다.
Kubernetes 환경을 확장할 때 가동 시간을 개선하기 위한 일반적인 접근 방식은 클러스터 앞에 로드 밸런서, DNS 관리자 및 기타 자동화된 결정 시스템을 배포하는 것입니다. 그러나 Ingress 컨트롤러의 작동 방식 때문에 Kubernetes 클러스터 앞에 있는 로드 밸런서는 일반적으로 클러스터에서 Ingress 컨트롤러 뒤에 있는 서비스에 대한 상태 정보에 액세스할 수 없습니다. Ingress 컨트롤러 포드 자체가 정상이고 트래픽을 수용하는지 여부만 확인할 수 있습니다.
반면 NGINX Ingress Controller는 서비스 상태에 대한 정보를 가지고 있습니다. 이미 HTTP , TCP , UDP 및 gRPC 서비스에 대한 주기적 수동 상태 검사를 보내고, 요청 응답성을 모니터링하고, 성공적인 응답 코드 및 기타 메트릭을 추적하여 클러스터의 업스트림 포드 상태를 모니터링합니다. 이 정보를 사용하여 일관되고 예측 가능한 사용자 경험을 제공하기 위해 서비스의 포드에 트래픽을 분산하는 방법을 결정합니다. 일반적으로 NGINX Ingress Controller는 백그라운드에서 이 모든 마법을 조용히 수행하고 있으며, 후드 아래에서 무슨 일이 일어나고 있는지 두 번 생각하지 않을 수도 있습니다. Deep Service Insight는 이 귀중한 정보를 "표면화"하여 스택의 다른 계층에서 보다 효과적으로 사용할 수 있도록 합니다.
심층적 서비스 통찰력은 어떻게 작동하나요?
Deep Service Insight는 NGINX VirtualServer 및 TransportServer 사용자 지정 리소스(각각 HTTP 및 TCP/UDP용)를 사용하여 배포하는 서비스에 사용할 수 있습니다. Deep Service Insight는 NGINX Plus API를 사용하여 Deep Service Insight에 고유한 전용 엔드포인트에서 백엔드 서비스의 개별 포드에 대한 NGINX Ingress Controller의 뷰를 공유합니다.
VirtualServer의 경우 – <IP_주소> : <포트> /probe/ <호스트 이름>
TransportServer의 경우 – <IP_주소> : <포트> /probe/ts/ <서비스_이름 >
어디
<IP_address>는 NGINX Ingress Controller에 속합니다.
<port> 는 Deep Service Insight 포트 번호(기본값 9114)입니다.
<hostname>spec.host 은 VirtualServer 리소스 필드에 정의된 서비스의 도메인 이름입니다.
<service_name>spec.upstreams.service 은 TransportServer 리소스의 필드에 정의된 서비스의 이름입니다.
출력에는 두 가지 유형의 정보가 포함됩니다.
호스트 이름 또는 서비스 이름에 대한 HTTP 상태 코드:
200 OK – 적어도 하나의 포드가 건강합니다.
418 I’m a teapot – 건강한 포드가 없습니다
404 Not Found – 지정된 호스트 이름 또는 서비스 이름과 일치하는 포드가 없습니다.
활성 상태 검사를 구성하여 NGINX Ingress Controller가 포드가 정상인지 판단하는 데 사용하는 기준을 추가로 사용자 지정할 수 있습니다. 상태 검사가 전송되는 경로와 포트, 포드가 비정상으로 간주되기 위해 지정된 기간 내에 발생해야 하는 실패 검사 수, 예상 상태 코드, 연결 또는 응답 수신 시간 초과 등을 구성할 수 있습니다. VirtualServer 또는 TransportServerUpstream.Healthcheck 리소스 에 필드를 포함합니다 .
심층적인 서비스 통찰력을 위한 샘플 사용 사례
Deep Service Insight가 특히 가치 있는 사용 사례 중 하나는 로드 밸런서가 고가용성을 위해 두 클러스터에서 실행되는 서비스로 트래픽을 라우팅하는 경우입니다. 각 클러스터 내에서 NGINX Ingress Controller는 위에서 설명한 대로 업스트림 포드의 상태를 추적합니다. Deep Service Insight를 활성화하면 정상 및 비정상 업스트림 포드의 수에 대한 정보도 전용 엔드포인트에 노출됩니다. 라우팅 결정 시스템은 엔드포인트에 액세스하여 해당 정보를 사용하여 애플리케이션 트래픽을 비정상 포드에서 정상 포드로 전환할 수 있습니다.
이 다이어그램은 이 시나리오에서 Deep Service Insight가 작동하는 방식을 보여줍니다.
고가용성 시나리오에서 클러스터에 대한 유지 관리를 수행할 때 Deep Service Insight를 활용할 수도 있습니다. 유지 관리를 수행하는 클러스터에서 서비스에 대한 포드 수를 0으로 줄이기만 하면 됩니다. 건강한 포드가 없는 경우 Deep Service Insight 엔드포인트에 자동으로 표시되고 라우팅 결정 시스템은 해당 정보를 사용하여 다른 클러스터의 건강한 포드로 트래픽을 전송합니다. NGINX Ingress Controller나 시스템에서 구성을 변경하지 않고도 효과적으로 자동 장애 조치를 받을 수 있으며, 고객은 서비스 중단을 경험하지 않습니다.
심층적인 서비스 통찰력 활성화
Deep Service Insight를 활성화하려면 -enable-service-insightKubernetes 매니페스트에 명령줄 인수를 포함하거나 Helm을 사용하는 경우 serviceInsight.create매개변수를 로 설정합니다 true.
사용자 환경에 맞게 엔드포인트를 조정하기 위해 포함할 수 있는 두 가지 선택적 인수가 있습니다.
-service-insight-listen-port <port> – Deep Service Insight 포트 번호를 기본값인 9114에서 변경합니다( <port>1024–65535 범위의 정수). Helm과 동등한 것이 매개 serviceInsight.port변수입니다.
-service-insight-tls-string <secret> – Deep Service Insight 엔드포인트의 TLS 종료를 위한 Kubernetes 비밀(TLS 인증서 및 키)( <secret>형식이 있는 문자열 <namespace>/<secret_name>). Helm과 동등한 것이 serviceInsight.secret매개변수입니다.
예: 카페 애플리케이션에 대한 심층적 서비스 통찰력 활성화
Deep Service Insight가 실제로 어떻게 활용되는지 확인하려면 NGINX Ingress Controller 설명서에서 예로 자주 사용되는 Cafe 애플리케이션 에서 이를 활성화하면 됩니다 .
NGINX 사용자 정의 리소스를 지원하고 Deep Service Insight를 활성화하는 NGINX Ingress Controller의 NGINX Plus 버전을 설치합니다.
Helm을 사용하는 경우 serviceInsight.create매개변수를 .으로 설정합니다 true.
Kubernetes 매니페스트 (Deployment 또는 DaemonSet) 를 사용하는 경우 -enable-service-insight매니페스트 파일에 인수를 포함합니다.
NGINX Ingress Controller가 실행 중인지 확인하세요.
$ kubectl get pods -n nginx-ingressNAME READY ...
ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 ...
... STATUS RESTARTS AGE
... Running 0 9d
README 의 지침에 따라 Cafe 애플리케이션을 배포합니다 .
NGINX VirtualServer 사용자 정의 리소스가 Cafe 애플리케이션에 배포되었는지 확인합니다(IP 주소는 읽기 쉽도록 생략).
$ kubectl get vs NAME STATE HOST IP PORTS AGE
cafe Valid cafe.example.com ... [80,443] 7h1m
cafe.example.com 에서 실행되는 Cafe 서비스에 대해 세 개의 업스트림 포드가 있는지 확인하세요 .
$ kubectl get pods NAME READY STATUS RESTARTS AGE
coffee-87cf76b96-5b85h 1/1 Running 0 7h39m
coffee-87cf76b96-lqjrp 1/1 Running 0 7h39m
tea-55bc9d5586-9z26v 1/1 Running 0 111m
오늘날 기업에서 비용과 위험의 균형을 맞추는 것이 가장 중요합니다. 하지만 충분한 가시성이 없다면 리소스가 효과적으로 또는 일관되게 사용되고 있는지 알 수 없습니다.
쿠버네티스는 종종 일시적이고 가변적인 양의 클러스터 리소스를 소모하는 컨테이너화된 워크로드의 복잡한 배포를 가능하게 합니다. 이는 클라우드 환경이 쿠버네티스에 매우 적합한 이유입니다. 쿠버네티스는 피크 부하를 예상하여 과도하게 프로비저닝할 필요 없이 사용한 만큼만 비용을 지불하는 가격 모델을 제공하기 때문입니다. 물론 클라우드 공급업체는 이러한 편의성에 대해 프리미엄을 청구합니다. 비용 없이 퍼블릭 클라우드의 동적 로드 밸런싱을 잠금 해제할 수 있다면 어떨까요? 그리고 온프레미스 및 퍼블릭 클라우드 배포에 동일한 솔루션을 사용할 수 있다면 어떨까요?
이제 가능합니다. Kubecost와 NGINX는 Kubernetes 사용자가 수많은 배포에서 복잡성과 비용을 줄이는 데 도움을 줍니다. 이러한 솔루션을 함께 사용하면 최적의 성능과 해당 성능 및 관련 비용에 대한 궁극적인 가시성을 얻을 수 있습니다.
Kubecost의 통찰력을 통해 성능과 보안을 높이는 동시에 Kubernetes 배포 비용을 획기적으로 줄일 수 있습니다. Kubecost로 달성할 수 있는 것의 예는 다음과 같습니다.
다른 지역의 스토리지 버킷으로 포드가 상당한 유출 트래픽을 생성하는 잘못된 구성을 식별합니다.
비용을 절감하고 성능을 개선하기 위해 멀티 클러스터 Kubernetes 환경에서 로드 밸런서와 Ingress 컨트롤러 툴링을 통합합니다.
컨테이너의 성능을 파악하여 위험 없이 비용을 절감할 수 있도록 컨테이너 크기를 올바르게 조정하세요.
NGINX는 당신에게 필요한 성능을 제공합니다
NGINX Ingress Controller는 가장 널리 사용되는 Ingress 기술 중 하나로, 지금까지 Docker Hub에서 10억 회 이상 풀을 달성했으며 , 프로덕션 환경에서 실행되는 고성능, 확장 가능 및 보안을 갖춘 최신 앱의 대명사입니다.
NGINX Ingress Controller는 Kubernetes 환경에서 NGINX Open Source 또는 NGINX Plus 인스턴스와 함께 실행됩니다. 표준 Kubernetes Ingress 리소스 와 NGINX 사용자 지정 리소스를 모니터링하여 Ingress 로드 밸런싱이 필요한 서비스에 대한 요청을 발견합니다. 그런 다음 NGINX Ingress Controller는 NGINX 또는 NGINX Plus를 자동으로 구성하여 이러한 서비스로 트래픽을 라우팅하고 로드 밸런싱합니다.
NGINX Ingress Controller는 API 게이트웨이, 로드 밸런서 및 Ingress 컨트롤러 기능을 결합하는 범용 도구로 사용하여 운영을 간소화하고 비용과 복잡성을 줄일 수 있습니다.
Kubecost가 네트워크 운영의 실제 비용을 공개합니다.
Kubecost는 Kubernetes 사용자에게 클러스터에서 각 컨테이너를 실행하는 데 드는 비용에 대한 가시성을 제공합니다. 여기에는 각 노드의 명백한 CPU, 메모리 및 스토리지 비용이 포함됩니다. 그러나 Kubecost는 이러한 기본 사항을 넘어 클라우드 공급자의 데이터 이탈 시 일반적으로 발생하는 포드당 네트워크 전송 비용을 공개합니다.
Kubecost가 올바른 작업 부하에 비용을 얼마나 정확하게 할당하는지를 결정하는 두 가지 구성 옵션이 있습니다.
첫 번째 옵션은 통합 클라우드 청구 입니다 . Kubecost는 트래픽을 처리한 노드와 관련된 네트워크 전송 비용을 포함하여 클라우드 공급자로부터 청구 데이터를 가져옵니다. Kubecost는 이 비용을 컨테이너 트래픽의 공유에 따라 해당 노드의 포드에 분배합니다.
보고된 총 네트워크 비용은 정확하지만 이 방법은 이상적이지 않습니다. 많은 포드의 경우 유일하게 중요한 트래픽은 자체 존(따라서 무료) 내에 있지만 Kubecost는 이러한 워크로드에 대한 네트워크 비용을 보여줍니다.
두 번째 옵션인 네트워크 비용 구성은 모든 트래픽의 소스와 목적지를 살펴봄으로써 클라우드 청구 통합의 이러한 한계를 해결합니다. Kubecost Allocations 대시보드는 네임스페이스, 레이블, 서비스와 같은 Kubernetes 개념과 팀, 제품, 프로젝트, 부서, 환경과 같은 조직 부문을 포함한 여러 범주에 걸친 지출 비율을 표시합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
12팩터 앱 으로 알려진 가이드라인은 10년 이상 전에 처음 발표되었습니다. 그 이후로 거의 모든 의무적 관행이 웹 앱을 작성하고 배포하는 사실상의 표준 방식이 되었습니다. 그리고 앱이 구성되고 배포되는 방식이 변경된 상황에서도 여전히 적용 가능하지만, 어떤 경우에는 앱 을 개발하고 배포하기 위한 마이크로서비스 패턴에 관행이 어떻게 적용되는지 이해하기 위해 추가적인 뉘앙스가 필요합니다.
이 블로그는 환경에서 구성 저장의 요소 3에 초점을 맞추고 있으며 다음과 같이 설명합니다.
구성은 배포 환경(12단계 앱이 배포 라고 부르는 ) 간에 달라지는 모든 것을 말합니다.
구성은 앱 코드와 엄격하게 분리되어야 합니다. 그렇지 않으면 배포마다 어떻게 달라질 수 있겠습니까?
구성 데이터는 환경 변수에 저장됩니다.
마이크로서비스로 이동하면서 이러한 지침을 여전히 준수할 수 있지만, 항상 12팩터 앱의 문자 그대로의 해석에 정확히 매핑되는 방식은 아닙니다. 환경 변수로 구성 데이터를 제공하는 것과 같은 일부 지침은 훌륭하게 이어집니다. 12팩터 앱의 핵심 원칙을 존중하는 다른 일반적인 마이크로서비스 관행은 이를 확장한 것과 더 비슷합니다. 이 게시물에서는 팩터 3의 관점에서 마이크로서비스의 구성 관리에 대한 세 가지 핵심 개념을 살펴보겠습니다.
서비스 구성을 명확하게 정의하기
구성이 서비스에 제공되는 방법
서비스를 구성으로 사용 가능하게 만들기
주요 마이크로서비스 용어 및 개념
마이크로서비스에 맞게 Factor 3을 적용하는 것에 대한 논의에 들어가기 전에 몇 가지 핵심 용어와 개념을 이해하는 것이 도움이 됩니다.
모놀리식 앱 아키텍처 – 앱 기능을 구성 요소 모듈로 분리하지만 모든 모듈을 단일 코드베이스에 포함하는 전통적인 아키텍처 모델입니다.
마이크로서비스 앱 아키텍처 - 각각 잘 범위가 정해진 작업 세트(예: 인증, 알림 또는 결제 처리)를 수행하는 여러 개의 작은 구성 요소로 크고 복잡한 앱을 빌드하는 아키텍처 모델입니다. "마이크로서비스"는 작은 구성 요소 자체의 이름이기도 합니다. 실제로 일부 "마이크로서비스"는 실제로 매우 클 수 있습니다.
서비스 – 시스템 내의 단일 애플리케이션이나 마이크로서비스를 지칭하는 일반적인 용어입니다.
시스템 – 이 블로그의 맥락에서 조직이 제공하는 완전한 기능을 생성하기 위해 함께 모이는 마이크로서비스와 지원 인프라의 전체 세트입니다.
아티팩트 – 테스트 및 빌드 파이프라인에서 생성된 객체입니다. 앱의 코드를 포함하는 Docker 이미지와 같이 여러 형태를 취할 수 있습니다.
배포 - 스테이징, 통합 또는 프로덕션과 같은 환경에서 실행되는 아티팩트의 실행 중인 "인스턴스"입니다.
마이크로서비스 대 모놀리스
모놀리식 애플리케이션에서는 조직의 모든 팀이 동일한 애플리케이션과 주변 인프라에서 작업합니다. 모놀리식 앱은 일반적으로 문서상으로는 마이크로서비스보다 간단해 보이지만 조직이 마이크로서비스로 이동하기로 결정하는 데에는 몇 가지 일반적인 이유가 있습니다.
팀 자율성 – 모놀리스에서 기능과 하위 시스템의 소유권을 정의하는 것은 까다로울 수 있습니다. 조직이 성장하고 성숙해짐에 따라 앱 기능에 대한 책임은 점점 더 많은 팀에 분산되는 경우가 많습니다. 이는 기능을 소유한 팀이 모놀리스의 모든 관련 하위 시스템을 소유하지 않기 때문에 팀 간에 종속성을 만듭니다.
"폭발 반경" 감소 - 대규모 애플리케이션을 하나의 단일 단위로 개발 및 배포하는 경우 하나의 하위 시스템에서 오류가 발생하면 전체 앱의 기능이 저하될 수 있습니다.
기능을 독립적으로 확장 – 모놀리식 앱에서 단일 모듈만 부하가 많이 걸리더라도 조직은 시스템 장애나 성능 저하를 방지하기 위해 전체 앱의 여러 인스턴스를 배포해야 합니다.
물론 마이크로서비스에는 복잡성 증가, 관찰성 감소, 새로운 보안 모델 필요성 등 고유한 과제가 있습니다. 하지만 많은 조직, 특히 대규모 또는 빠르게 성장하는 조직은 고객에게 제공하는 경험에 대한 안정적이고 신뢰할 수 있는 기반을 구축하는 데 있어 팀에 더 많은 자율성과 유연성을 제공하기 위해 이러한 과제를 감수할 가치가 있다고 결정합니다.
마이크로서비스 아키텍처에 필요한 변경 사항
모놀리식 앱을 마이크로서비스로 리팩토링하는 경우 서비스는 다음을 수행해야 합니다.
예측 가능한 방식으로 구성 변경 사항 수락
예측 가능한 방식으로 더 넓은 시스템에 자신을 알리십시오.
잘 문서화하세요
모놀리식 앱의 경우 프로세스의 작은 불일치와 공유된 가정에 대한 종속성은 중요하지 않습니다. 그러나 많은 개별 마이크로서비스의 경우 이러한 불일치와 가정은 많은 고통과 혼란을 초래할 수 있습니다. 마이크로서비스에서 변경해야 하는 많은 부분은 기술적으로 필요하지만 놀랍게도 많은 부분이 팀이 내부적으로 작업하고 다른 팀과 상호 작용하는 방식과 관련이 있습니다.
마이크로서비스 아키텍처를 적용한 주요 조직 변화는 다음과 같습니다.
동일한 코드베이스에서 함께 작업하는 대신, 팀은 완전히 분리되어 각 팀이 하나 이상의 서비스에 대해 전적으로 책임을 집니다. 가장 일반적인 마이크로서비스 구현에서 팀은 또한 "교차 기능적"으로 재편됩니다. 즉, 다른 팀에 대한 최소한의 종속성으로 팀의 목표를 완료하는 데 필요한 모든 역량을 갖춘 멤버가 있다는 의미입니다.
플랫폼 팀(시스템 전반의 상태를 담당)은 이제 단일 애플리케이션을 다루는 대신, 여러 팀이 소유한 여러 서비스를 조정해야 합니다.
툴링 팀은 다양한 서비스 소유자 팀에 툴링과 지침을 제공하여 시스템을 안정적으로 유지하는 동시에 목표를 빠르게 달성할 수 있도록 지원해야 합니다.
서비스 구성을 명확하게 정의하기
팩터 3을 확장해야 하는 마이크로서비스 아키텍처의 한 영역은 구성을 포함한 서비스에 대한 특정 중요 정보를 명확하게 정의하고 다른 서비스와 최소한의 공유 컨텍스트를 가정해야 할 필요성과 관련이 있습니다. 팩터 3은 이를 직접 다루지는 않지만, 애플리케이션 기능에 기여하는 개별 마이크로서비스가 많은 경우 특히 중요합니다.
마이크로서비스 아키텍처의 서비스 소유자로서, 귀하의 팀은 시스템 전체에서 특정 역할을 하는 서비스를 소유합니다. 귀하의 서비스와 상호 작용하는 다른 팀은 귀하의 서비스 저장소에 액세스하여 코드와 문서를 읽고 기여해야 합니다.
게다가, 소프트웨어 개발 분야에서 팀 구성원이 자주 바뀌는 것은 불행한 현실입니다. 개발자가 회사에 들어오고 나가기 때문일 뿐만 아니라 내부 조직 개편 때문이기도 합니다. 또한 주어진 서비스에 대한 책임도 종종 팀 간에 이전됩니다.
이러한 현실에 비추어 볼 때, 귀하의 코드베이스와 문서는 매우 명확하고 일관성이 있어야 하며, 이는 다음을 통해 달성됩니다.
각 구성 옵션의 목적을 명확하게 정의합니다.
구성 값의 예상 형식을 명확하게 정의합니다.
애플리케이션이 구성 값을 제공하도록 기대하는 방법을 명확하게 정의합니다.
이 정보를 제한된 수의 파일에 기록합니다.
많은 애플리케이션 프레임워크는 필요한 구성을 정의하는 수단을 제공합니다. 예를 들어, convictNode.js 애플리케이션용 NPM 패키지는 단일 파일에 저장된 완전한 구성 "스키마"를 사용합니다. 이는 Node.js 앱이 실행하는 데 필요한 모든 구성에 대한 진실의 원천 역할을 합니다.
강력하고 쉽게 발견할 수 있는 스키마를 통해 팀원과 다른 사람들이 서비스를 자신 있게 사용할 수 있습니다.
구성이 서비스에 제공되는 방법
애플리케이션에 필요한 구성 값을 명확하게 정의했다면 배포된 마이크로서비스 애플리케이션이 구성을 가져오는 두 가지 기본 소스 간의 중요한 구별도 존중해야 합니다.
구성 설정을 명시적으로 정의하고 애플리케이션 소스 코드와 함께 제공되는 배포 스크립트
배포 시점에 외부 소스가 쿼리됨
배포 스크립트는 마이크로서비스 아키텍처에서 일반적인 코드 구성 패턴입니다. 12팩터 앱이 처음 공개된 이후로 새로운 것이기 때문에 필연적으로 12팩터 앱의 확장을 나타냅니다.
패턴: 애플리케이션 옆의 배포 및 인프라 구성
최근 몇 년 동안 애플리케이션 코드와 동일한 저장소에 infrastructure (또는 이와 비슷한 이름의 변형) 라는 폴더를 두는 것이 일반적이 되었습니다 . 여기에는 일반적으로 다음이 포함됩니다.
서비스가 의존하는 인프라를 설명하는 코드로서의 인프라( Terraform 이 일반적인 예)(예: 데이터베이스)
Helm 차트 및 Kubernetes 매니페스트 와 같은 컨테이너 오케스트레이션 시스템에 대한 구성
애플리케이션 배포와 관련된 기타 파일
언뜻 보면 이는 구성과 코드를 엄격하게 분리해야 한다는 요소 3의 규정을 위반하는 것처럼 보일 수 있습니다.
사실, 애플리케이션 옆 에 배치하면 인프라 폴더가 실제로 규칙을 준수하는 동시에 마이크로서비스 환경에서 작업하는 팀에 중요한 귀중한 프로세스 개선을 가능하게 한다는 것을 의미합니다.
이 패턴의 장점은 다음과 같습니다.
서비스를 소유한 팀은 서비스 배포와 서비스별 인프라(예: 데이터베이스)의 배포도 소유합니다.
소유 팀은 이러한 요소에 대한 변경 사항이 개발 프로세스(코드 검토, CI)를 거치도록 할 수 있습니다.
팀은 외부 팀에 작업을 맡기지 않고도 서비스와 지원 인프라의 배포 방식을 쉽게 변경할 수 있습니다.
이 패턴이 제공하는 이점은 개별 팀의 자율성을 강화하는 동시에 배포 및 구성 프로세스에 추가적인 엄격성이 적용된다는 것입니다.
어떤 유형의 구성이 어디에 적용됩니까?
실제로 인프라 폴더에 저장된 배포 스크립트를 사용하여 스크립트 자체에 명시적으로 정의된 구성과 배포 시점에 외부 소스에서 구성을 검색하는 작업을 모두 관리합니다. 이를 위해 서비스에 대한 배포 스크립트를 다음과 같이 사용합니다.
특정 구성 값을 직접 정의합니다
배포 스크립트를 실행하는 프로세스가 외부 소스에서 원하는 구성 값을 찾을 수 있는 위치를 정의합니다.
서비스의 특정 배포에 특화되어 있고 팀의 완전한 통제 하에 있는 구성 값은 인프라 폴더의 파일에 직접 지정할 수 있습니다. 예를 들어 앱에서 시작한 데이터베이스 쿼리가 실행될 수 있는 시간 제한과 같은 것이 있습니다. 이 값은 배포 파일을 수정하고 애플리케이션을 다시 배포하여 변경할 수 있습니다.
이 계획의 한 가지 이점은 이러한 구성에 대한 변경 사항이 반드시 코드 검토 및 자동화된 테스트를 거쳐야 하므로 잘못 구성된 값으로 인해 중단이 발생할 가능성이 줄어든다는 것입니다. 코드 검토를 거치는 값과 주어진 시간의 구성 키 값에 대한 변경 사항은 소스 제어 툴링의 기록에서 발견할 수 있습니다.
애플리케이션이 실행되는 데 필요하지만 팀의 제어를 받지 않는 값은 애플리케이션이 배포된 환경에서 제공해야 합니다. 예를 들어, 서비스가 종속된 다른 마이크로서비스에 연결하는 호스트 이름과 포트가 있습니다.
해당 서비스는 귀하의 팀이 소유하지 않으므로 포트 번호와 같은 값에 대해 가정할 수 없습니다. 이러한 값은 언제든지 변경될 수 있으며 변경 시 일부 중앙 구성 저장소에 등록해야 합니다. 해당 변경이 수동으로 이루어지든 자동 프로세스로 이루어지든 상관없습니다. 그런 다음 해당 값에 의존하는 애플리케이션에서 쿼리할 수 있습니다.
이러한 지침은 마이크로서비스 구성을 위한 두 가지 모범 사례로 요약할 수 있습니다.
마이크로서비스 구성에서는 하드코딩된 값이나 상호 합의된 값에 의존하지 마십시오.
배포 스크립트에서 특정 값(예: 서비스가 상호 작용하는 서비스의 위치)을 하드코딩하는 것이 가장 간단해 보일 수 있습니다. 실제로 그러한 유형의 구성을 하드코딩하는 것은 위험하며, 특히 서비스 위치가 일반적으로 자주 변경되는 현대 환경에서 더욱 그렇습니다. 그리고 두 번째 서비스를 소유하지 않은 경우 특히 위험합니다.
스크립트에서 서비스 위치를 업데이트하기 위해 자신의 근면함에 의지할 수 있다고 생각할 수도 있고, 더 나쁜 경우 위치가 변경될 때 소유팀이 알려줄 것이라고 생각할 수도 있습니다. 근면함은 스트레스가 많은 시기에 종종 미끄러지고, 인간의 엄격함에 의존하면 시스템이 경고 없이 실패할 위험이 있습니다.
마이크로서비스 구성에서 해야 할 일: 서비스에 "내 데이터베이스는 어디에 있습니까?"라고 묻게 하세요.
위치 정보가 하드코딩되어 있든 아니든, 애플리케이션은 특정 위치에 있는 중요한 인프라에 의존해서는 안 됩니다. 대신, 새로 배포된 서비스는 "내 데이터베이스는 어디에 있습니까?"와 같은 시스템 내의 일반적인 소스에 질문을 하고 해당 외부 리소스의 현재 위치에 대한 정확한 답변을 받아야 합니다. 모든 서비스가 배포될 때 시스템에 등록하면 훨씬 더 간단해집니다.
서비스를 구성으로 사용 가능하게 만들기
시스템이 "내 데이터베이스는 어디에 있나요?"와 "내가 사용하는 '서비스 X'는 어디에 있나요?"라는 질문에 대한 답을 제공해야 하는 것처럼, 서비스는 배포 방법에 대해 전혀 알지 못해도 다른 서비스가 쉽게 찾아서 통신할 수 있는 방식으로 시스템에 노출되어야 합니다.
마이크로서비스 아키텍처의 핵심 구성 관행은 서비스 검색입니다. 새로운 서비스 정보를 등록하고 다른 서비스에서 액세스할 때 해당 정보를 동적으로 업데이트하는 것입니다. 마이크로서비스에 서비스 검색이 필요한 이유를 설명한 후 NGINX Open Source와 Consul을 사용하여 이를 달성하는 방법의 예를 살펴보겠습니다.
서비스의 여러 인스턴스(배포)를 동시에 실행하는 것은 일반적인 관행입니다. 이를 통해 추가 트래픽을 처리할 수 있을 뿐만 아니라 새로운 배포를 시작하여 다운타임 없이 서비스를 업데이트할 수도 있습니다. 리버스 프록시 및 로드 밸런서 역할을 하는 NGINX와 같은 도구는 들어오는 트래픽을 처리하여 가장 적합한 인스턴스로 라우팅합니다. 이는 서비스에 의존하는 서비스가 NGINX에만 요청을 보내고 배포에 대해 아무것도 알 필요가 없기 때문에 좋은 패턴입니다.
예를 들어, NGINX 뒤에서 역방향 프록시 역할을 하는 messenger 라는 서비스의 단일 인스턴스가 있다고 가정해 보겠습니다 .
이제 앱이 인기를 얻으면 어떨까요? 좋은 소식으로 여겨지지만, 트래픽이 증가했기 때문에 메신저 인스턴스가 많은 CPU를 소모하고 요청을 처리하는 데 시간이 더 오래 걸리는 반면 데이터베이스는 정상적으로 작동하는 것 같습니다. 이는 메신저 서비스 의 다른 인스턴스를 배포하면 문제를 해결할 수 있음을 나타냅니다 .
메신저 서비스 의 두 번째 인스턴스를 배포할 때 NGINX는 그것이 라이브 상태인지 어떻게 알고 트래픽을 보내기 시작합니까? NGINX 구성에 새 인스턴스를 수동으로 추가하는 것은 한 가지 접근 방식이지만, 더 많은 서비스가 확장되고 축소됨에 따라 빠르게 관리하기 어려워집니다.
일반적인 해결책은 Consul 과 같은 고가용성 서비스 레지스트리가 있는 시스템에서 서비스를 추적하는 것입니다 . 새로운 서비스 인스턴스는 배포될 때 Consul에 등록됩니다. Consul은 주기적으로 상태 검사를 보내 인스턴스의 상태를 모니터링합니다. 인스턴스가 상태 검사에 실패하면 사용 가능한 서비스 목록에서 제거됩니다.
NGINX는 다양한 방법을 사용하여 Consul과 같은 레지스트리를 쿼리하고 그에 따라 라우팅을 조정할 수 있습니다. 리버스 프록시 또는 로드 밸런서 역할을 할 때 NGINX가 트래픽을 "업스트림" 서버로 라우팅한다는 점을 기억하세요. 다음과 같은 간단한 구성을 고려하세요.
# Define an upstream group called "messenger_service"
upstream messenger_service {
server 172.18.0.7:4000;
server 172.18.0.8:4000;
}
server {
listen 80;
location /api {
# Proxy HTTP traffic with paths starting with '/api' to the
# 'upstream' block above. The default load-balancing algorithm,
# Round-Robin, alternates requests between the two servers
# in the block.
proxy_pass http://messenger_service;
proxy_set_header X-Forwarded-For $remote_addr;
}
}
기본적으로 NGINX는 트래픽을 라우팅하기 위해 각 메신저 인스턴스 의 정확한 IP 주소와 포트를 알아야 합니다 . 이 경우 172.18.0.7과 172.18.0.8 모두에서 포트 4000입니다.
여기서 Consul과 Consul 템플릿이 등장합니다. Consul 템플릿은 NGINX와 동일한 컨테이너에서 실행되며 서비스 레지스트리를 유지 관리하는 Consul 클라이언트와 통신합니다.
레지스트리 정보가 변경되면 Consul 템플릿은 올바른 IP 주소와 포트를 사용하여 NGINX 구성 파일의 새 버전을 생성하고, NGINX 구성 디렉토리에 쓰고, NGINX에 구성을 다시 로드하라고 지시합니다. NGINX가 구성을 다시 로드할 때 다운타임이 없으며 , 새 인스턴스는 다시 로드가 완료되는 즉시 트래픽을 수신하기 시작합니다.
이런 상황에서 NGINX와 같은 역방향 프록시를 사용하면 다른 서비스가 액세스할 수 있는 장소로 시스템에 등록할 수 있는 단일 터치 포인트가 있습니다. 귀하의 팀은 다른 서비스가 서비스 전체에 대한 액세스를 잃을까 봐 걱정할 필요 없이 개별 서비스 인스턴스를 관리할 수 있는 유연성을 갖습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
견고한 Kubernetes 환경을 만들고 관리하려면 네트워크 및 애플리케이션 팀 간의 원활한 협업이 필요합니다. 하지만 이들의 우선순위와 작업 스타일은 보통 상당히 다르기 때문에 충돌이 발생하여 앱 개발이 느리고 배포가 지연되며 심지어 네트워크 다운타임까지 심각한 결과를 초래합니다.
두 팀이 공통의 목표를 향해 노력하는 성공만이 오늘날의 현대적 애플리케이션이 적절한 보안과 확장성을 갖추고 제때에 제공되도록 보장할 수 있습니다. 그렇다면 각 팀의 기술과 전문성을 활용하면서 그들이 협력하도록 돕는 방법은 무엇일까요?
저희의 백서 ' Get Me to the Cluster' 에서는 네트워크팀과 애플리케이션팀이 갈등 없이 각자의 강점을 결합할 수 있도록 Kubernetes 서비스에 대한 외부 액세스를 활성화하는 솔루션을 자세히 설명합니다.
Kubernetes 클러스터에서 앱을 노출하는 방법
이 솔루션은 특히 온프레미스에서 호스팅되는 Kubernetes 클러스터에 적합하며 , 노드는 베어 메탈 또는 기존 Linux 가상 머신(VM)에서 실행되고 표준 레이어 2 스위치와 레이어 3 라우터는 데이터 센터에서 통신을 위한 네트워킹을 제공합니다. 클라우드 호스팅 Kubernetes 클러스터에는 적용되지 않습니다. 클라우드 공급자는 데이터 센터의 핵심 네트워킹이나 관리되는 Kubernetes 환경의 네트워킹을 제어할 수 없기 때문입니다.
솔루션의 세부 사항을 살펴보기 전에 Kubernetes 클러스터에서 애플리케이션을 노출하는 다른 표준 방식이 온프레미스 배포에 적합하지 않은 이유를 살펴보겠습니다.
서비스 – 동일한 앱을 실행하는 포드를 그룹화합니다. 이는 내부 포드 간 통신에 좋지만 클러스터 내부에서만 볼 수 있으므로 앱을 외부에 노출하는 데 도움이 되지 않습니다.
NodePort – 클러스터의 모든 노드에서 특정 포트를 열고 해당 앱으로 트래픽을 전달합니다. 이렇게 하면 외부 사용자가 서비스에 액세스할 수 있지만 구성이 정적이고 잘 알려진 하위 포트 번호 대신 높은 번호의 TCP 포트를 사용하고 다른 앱과 포트 번호를 조정해야 하기 때문에 이상적이지 않습니다. 또한 여러 앱 간에 공통 TCP 포트를 공유할 수 없습니다.
LoadBalancer – 각 노드에서 NodePort 정의를 사용하여 외부 세계에서 Kubernetes 노드로의 네트워크 경로를 만듭니다. AWS, Google Cloud Platform, Microsoft Azure 및 대부분의 다른 클라우드 공급자가 잘 작동하고 A서비스에 필요한 공용 IP 주소와 일치하는 DNS 레코드를 제공하는 쉽게 구성할 수 있는 기능으로 지원하기 때문에 클라우드 호스팅 Kubernetes에 적합합니다. 안타깝게도 온프레미스 클러스터에는 동일한 기능이 없습니다.
온프레미스 Kubernetes 클러스터에 대한 외부 사용자 액세스 활성화
그러면 클러스터 외부의 사용자에서 클러스터 내부의 포드로 흐르는 트래픽(북쪽에서 남쪽으로 트래픽)을 위해 특별히 설계된 Kubernetes Ingress 객체가 남습니다. Ingress는 클러스터에 대한 외부 HTTP/HTTPS 진입점을 만듭니다. 외부 사용자가 여러 서비스에 액세스할 수 있는 단일 IP 주소 또는 DNS 이름입니다. 이것이 바로 필요한 것입니다! Ingress 객체는 Ingress 컨트롤러에 의해 구현됩니다. 당사 솔루션에서는 NGINX Plus 기반의 엔터프라이즈급 F5 NGINX Ingress 컨트롤러입니다 .
솔루션의 또 다른 핵심 구성 요소가 레이어 3 라우팅 프로토콜인 Border Gateway Protocol (BGP)이라는 사실에 놀라실지도 모릅니다. 하지만 훌륭한 솔루션은 복잡할 필요가 없습니다!
Get Me to the Cluster 에 설명된 솔루션은 실제로 4가지 구성 요소로 구성되어 있습니다.
iBGP 네트워크 – 내부 BGP(iBGP)는 데이터 센터의 자율 시스템(AS) 내에서 라우팅 정보를 교환하는 데 사용되며 네트워크가 안정적이고 확장 가능한지 확인하는 데 도움이 됩니다. iBGP는 이미 대부분의 데이터 센터에서 네트워크 팀에서 지원하고 있습니다.
Project Calico CNI 네트워킹 – Project Calico 는 온프레미스 데이터 센터의 환경을 유연하게 연결하고 트래픽 흐름에 대한 세부적인 제어를 제공하는 오픈소스 네트워킹 솔루션입니다. 우리는 BGP를 활성화한 Kubernetes 클러스터에서 네트워킹을 위해 Project Calico의 CNI 플러그인을 사용합니다. 이를 통해 포드에 할당된 IP 주소 풀을 제어할 수 있어 네트워킹 문제를 빠르게 식별하는 데 도움이 됩니다.
NGINX Plus 기반 NGINX Ingress Controller – NGINX Ingress Controller를 사용하면 포드의 서비스 엔드포인트 IP 주소를 보고 트래픽 처리를 중단하지 않고 업스트림 서비스 목록을 자동으로 재구성할 수 있습니다. 애플리케이션 팀은 또한 활성 상태 검사, mTLS, JWT 기반 인증을 포함하여 NGINX Plus의 여러 다른 엔터프라이즈급 Layer 7 HTTP 기능을 활용할 수 있습니다.
NGINX Plus를 에지에서 리버스 프록시로 사용 – NGINX Plus는 Kubernetes 클러스터의 에지에서 리버스 프록시로 사용되어 데이터 센터의 스위치와 라우터와 Kubernetes 클러스터의 내부 네트워크 간의 경로를 제공합니다. 이는 Kubernetes LoadBalancer 객체를 대체하는 역할을 하며 BGP에 Quagga를 사용합니다.
이 다이어그램은 솔루션 아키텍처를 보여주며, 요청 처리 중에 데이터가 교환되는 순서가 아닌 솔루션 구성 요소가 통신하는 데 사용하는 프로토콜을 나타냅니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
AI 및 머신 러닝(AI/ML) 워크로드는 기업의 운영 및 혁신 방식에 혁명을 일으키고 있습니다. 컨테이너 오케스트레이션 및 관리의 사실상 표준인 Kubernetes 는 하이브리드, 멀티 클라우드 환경에서 확장 가능한 대규모 언어 모델(LLM) 워크로드 및 추론 모델을 구동하기 위한 선택 플랫폼입니다.
Kubernetes에서 Ingress 컨트롤러는 컨테이너화된 애플리케이션을 제공하고 보호하는 데 중요한 역할을 합니다. Kubernetes 클러스터의 가장자리에 배포되어 사용자와 애플리케이션 간의 통신을 처리하는 중심점 역할을 합니다.
이 블로그에서는 Ingress 컨트롤러와 Kubernetes용 F5 NGINX Connectivity Stack이 AI/ML 워크로드에 대한 모델 제공, 실험, 모니터링 및 보안을 단순화하고 효율화하는 데 어떻게 도움이 될 수 있는지 살펴보겠습니다 .
대규모 프로덕션에서 AI/ML 모델 배포
대규모로 AI/ML 모델을 배포할 때 즉시 사용 가능한 Kubernetes 기능과 성능은 다음과 같은 데 도움이 될 수 있습니다.
동시에 조직은 대규모 프로덕션에서 AI/ML 모델을 제공하고, 실험하고, 모니터링하고, 보호하는 데 어려움을 겪을 수 있습니다.
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용 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 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
당신은 현대적 Platform Ops 또는 DevOps 엔지니어입니다. 당신은 오픈 소스(그리고 아마도 일부 상업용) 도구 라이브러리를 사용하여 개발팀을 위한 새로운 앱과 컨테이너를 테스트, 배포 및 관리합니다. 당신은 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 포드를 실행하기 위해 Kubernetes를 선택했습니다. 당신은 마이크로서비스의 아키텍처와 개념을 받아들였고, 대부분 잘 작동합니다. 그러나 이 여정에서 몇 가지 속도 범프에 부딪혔습니다.
예를 들어, 새로운 클러스터, 서비스 및 애플리케이션을 빌드하고 출시할 때 트래픽을 끊지 않고 이러한 새로운 리소스를 프로덕션에 쉽게 통합하거나 마이그레이션하려면 어떻게 해야 할까요? 기존 네트워킹 어플라이언스는 DNS 레코드, 로드 밸런서, 방화벽 및 프록시에 대한 구성 변경을 구현할 때 다시 로드하거나 재부팅해야 합니다. 이러한 조정은 DNS, 로드 밸런서 및 방화벽 규칙을 업데이트하는 데 "서비스 중단" 또는 "유지 관리 창"이 필요하기 때문에 다운타임을 발생시키지 않고는 재구성할 수 없습니다. 대부분의 경우, 두려운 서비스 티켓을 제출하고 다른 팀이 승인하고 변경을 수행할 때까지 기다려야 합니다.
유지 관리 창은 팀을 도랑에 빠뜨리고, 애플리케이션 제공을 멈추고, "트래픽을 관리하는 더 나은 방법이 있어야 한다!"고 선언하게 만들 수 있습니다. 따라서 빠른 차선으로 돌아갈 수 있는 솔루션을 살펴보겠습니다.
액티브-액티브 멀티 클러스터 로드 밸런싱
여러 개의 Kubernetes 클러스터가 있는 경우 두 클러스터로 동시에 트래픽을 라우팅하는 것이 이상적입니다. 더 나은 옵션은 A/B, 카나리아 또는 블루-그린 트래픽 분할을 수행하고 트래픽의 작은 비율을 테스트로 보내는 것입니다. 이를 위해 NGINX Plus를 ngx_http_split_clients_module.
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 분할 클라이언트 모듈을 사용하면 다음과 같은 사용 사례를 제공할 수 있습니다.
구성 예제
키-값 구성의 예는 다음과 같습니다.
# 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임을 알 수 있습니다.
그러면 12:56:30에서는 비율이 10:90으로 바뀐다.
그러면 13:00:00에 90:10으로 변경됩니다.
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 인스턴스를 추가하여 고가용성을 달성할 수 있습니다 .
Kubernetes용 NGINX 로드밸런서의 작동 스냅샷
아래 스크린샷에는 Kubernetes용 NGINX Loadbalancer가 배포되어 작업을 수행하는 모습을 보여주는 두 개의 창이 있습니다.
참고 : 이 예에서 Kubernetes 워커 노드는 10.1.1.8 및 10.1.1.10입니다.
NGINX Plus 보안 기능 추가
쿠버네티스에서 실행되는 애플리케이션이 점점 더 개방형 인터넷에 노출됨에 따라 보안이 필요해지고 있습니다. 다행히도 NGINX Plus에는 계층화된 심층 방어 아키텍처를 만드는 데 사용할 수 있는 엔터프라이즈급 보안 기능이 있습니다.
클러스터 앞에 NGINX Plus가 있고 split_clients기능을 수행한다면, 그 존재감을 활용하고 유익한 보안 기능을 추가하는 건 어떨까요? 보안을 강화하는 데 사용할 수 있는 NGINX Plus 기능 몇 가지와 이를 구성, 테스트, 배포하는 데 사용할 수 있는 다른 문서에 대한 링크와 참조가 있습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
Kubernetes에서 인공 지능(AI) 및 머신 러닝(ML) 모델 학습 및 추론을 실행할 때 동적 확장 및 축소가 중요한 요소가 됩니다. 데이터를 수집하기 위해 고대역폭 스토리지와 네트워킹이 필요할 뿐만 아니라 AI 모델 학습에는 대부분 GPU 또는 기타 특수 프로세서에서 나오는 상당한(그리고 값비싼) 컴퓨팅도 필요합니다. 사전 학습된 모델을 활용하더라도 프로덕션에서 모델 제공 및 미세 조정과 같은 작업은 여전히 대부분의 엔터프라이즈 워크로드보다 컴퓨팅 집약적입니다.
클라우드 네이티브 쿠버네티스는 빠른 확장성을 위해 설계되었습니다. 또한 하이브리드, 멀티 클라우드 환경에서 동적 워크로드에 대한 민첩성과 비용 효율적인 리소스 사용을 제공하도록 설계되었습니다.
이 블로그에서는 Kubernetes에서 AI/ML 워크로드를 확장하는 가장 일반적인 세 가지 방법을 다룹니다. 이를 통해 다양한 환경에서 동적 확장에 대한 최적의 성능, 비용 절감 및 적응성을 얻을 수 있습니다.
Kubernetes에서 AI/ML 워크로드를 위한 3가지 확장 모달리티
Kubernetes가 작업 부하를 확장하는 세 가지 일반적인 방법은 수평적 Pod 자동 확장기(HPA), 수직적 Pod 자동 확장기(VPA), 클러스터 자동 확장기입니다.
세 가지 방법을 자세히 살펴보면 다음과 같습니다.
각 모달리티는 모델 학습 및 추론에 있어서 각자의 이점을 가지고 있으며, 아래 사용 사례를 통해 이를 알아볼 수 있습니다.
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, VPA 및 Cluster Autoscaler는 Kubernetes에서 AI/ML 워크로드를 관리하는 데 있어 서로를 보완합니다. Cluster Autoscaler는 워크로드 수요를 충족할 수 있는 충분한 노드가 있는지 확인하고, HPA는 여러 포드에 워크로드를 효율적으로 분산하며, VPA는 이러한 포드의 리소스 할당을 최적화합니다. 함께 Kubernetes 환경에서 AI/ML 애플리케이션을 위한 포괄적인 확장 및 리소스 관리 솔루션을 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
2023년 10월 25일, 미국 국립표준기술원(NIST)은 Kubernetes용 NGINX Ingress Controller에 영향을 미치는 3개의 CVE를 보고했습니다 .
해당 보고서와 후속 출판물(긴급 : Kubernetes용 NGINX Ingress 컨트롤러에서 새로운 보안 결함 발견 )은 어떤 NGINX Ingress 컨트롤러가 실제로 영향을 받는지, 그리고 이러한 CVE에 설명된 취약점을 해결하는 데 누가 관여해야 하는지에 대한 혼란(및 여러 지원 문의)을 야기했습니다.
혼란은 완전히 이해할 수 있습니다. NGINX 기반 Ingress 컨트롤러가 두 개 이상 있다는 것을 알고 계셨나요? 시작으로, "NGINX Ingress Controller"라는 완전히 다른 두 프로젝트가 있습니다.
NGINX를 기반으로 하는 다른 Ingress 컨트롤러도 있는데, Kong이 있습니다. 다행히도, 이름은 쉽게 구별할 수 있습니다. 어떤 것을 사용하는지 잘 모르겠다면 실행 중인 Ingress 컨트롤러의 컨테이너 이미지를 확인한 다음 Docker 이미지 이름을 위에 나열된 리포와 비교하세요.
위에 설명된 취약점(CVE-2022-4886, CVE-2023-5043 및 CVE-2023-5044)은 커뮤니티 프로젝트 ( kubernetes/ingress-nginx )에만 적용됩니다. NGINX Ingress Controller( nginxinc/kubernetes-ingress , 오픈소스 및 상업용)에 대한 NGINX 프로젝트는 이러한 CVE의 영향을 받지 않습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
당신은 현대적 앱 개발자입니다. 오픈 소스와 아마도 일부 상용 도구 모음을 사용하여 새로운 앱과 컨테이너를 작성, 테스트, 배포 및 관리합니다. 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 포드를 실행하기 위해 Kubernetes를 선택했습니다. 마이크로서비스의 아키텍처와 개념, Cloud Native Computing Foundation 및 기타 현대적 산업 표준을 도입했습니다.
이 여정에서 여러분은 쿠버네티스가 실제로 강력하다는 것을 알게 되었습니다. 하지만 여러분은 쿠버네티스가 얼마나 어렵고, 유연하지 않으며, 좌절스러울 수 있는지에 놀랐을 것입니다. 라우터, 방화벽, 로드 밸런서 및 기타 네트워크 장치에 대한 변경 사항과 업데이트를 구현하고 조정하는 것은 압도적일 수 있습니다. 특히 자체 데이터 센터에서는 더욱 그렇습니다! 개발자를 눈물 흘리게 만들기에 충분합니다.
이러한 과제를 어떻게 처리하는지는 Kubernetes를 어디서 어떻게 실행하는지(관리형 서비스 또는 온프레미스)와 많은 관련이 있습니다. 이 문서에서는 배포 선택이 사용 편의성에 영향을 미치는 주요 영역인 TCP 로드 밸런싱을 다룹니다.
관리형 Kubernetes를 사용한 TCP 부하 분산(일명 Easy Option)
Kubernetes용 퍼블릭 클라우드 공급자와 같은 관리형 서비스를 사용하면 지루한 네트워킹 작업의 대부분이 처리됩니다. 단 하나의 명령( kubectl apply -f loadbalancer.yaml) 으로 서비스 유형 LoadBalancer는 퍼블릭 IP, DNS 레코드 및 TCP 로드 밸런서를 제공합니다. 예를 들어, NGINX Ingress Controller가 포함된 포드에 트래픽을 분산하도록 Amazon Elastic Load Balancer를 구성하고 이 명령을 사용하면 백엔드가 변경될 때 걱정할 필요가 없습니다. 너무 쉽기 때문에 당연하게 여기실 겁니다!
온프레미스 Kubernetes를 사용한 TCP 부하 분산(일명 하드 옵션)
온프레미스 클러스터의 경우 완전히 다른 시나리오입니다. 귀하 또는 네트워킹 피어가 네트워킹 부분을 제공해야 합니다. "왜 사용자를 내 Kubernetes 앱으로 유도하는 것이 이렇게 어려울까?"라고 궁금해할 수 있습니다. 답은 간단하지만 약간 충격적입니다. 클러스터의 정문인 서비스 유형 LoadBalancer는 실제로 존재하지 않습니다.
클러스터 외부에 앱과 서비스를 노출하려면 네트워크 팀에서 티켓, 승인, 절차, 심지어 보안 검토까지 필요할 수 있습니다. 이 모든 것이 장비를 재구성하기 전에 필요합니다. 아니면 모든 것을 직접 해야 할 수도 있는데, 그러면 애플리케이션 제공 속도가 엄청나게 느려질 수 있습니다. 더 나쁜 것은 Kubernetes 서비스를 변경하지 않는 것입니다. NodePort 가 변경되면 트래픽이 차단될 수 있기 때문입니다! 그리고 사용자들이 500 오류를 얼마나 좋아하는지 우리 모두 알고 있습니다. 상사는 아마 더 싫어할 것입니다.
온프레미스 TCP 로드 밸런싱을 위한 더 나은 솔루션: Kubernetes용 NGINX 로드 밸런서
새로운 프로젝트인 Kubernetes용 NGINX 로드밸런서를 사용하면 "하드 옵션"을 "쉬운 옵션"으로 바꿀 수 있습니다 . 이 무료 프로젝트는 NGINX Ingress Controller를 감시하고 로드 밸런싱을 위해 구성된 외부 NGINX Plus 인스턴스를 자동으로 업데이트하는 Kubernetes 컨트롤러 입니다 . 매우 간단한 설계로 설치 및 작동이 간편합니다. 이 솔루션을 사용하면 온프레미스 환경에서 TCP 로드 밸런싱을 구현하여 새로운 앱과 서비스를 즉시 감지하고 트래픽에 사용할 수 있습니다. 직접 작업할 필요가 없습니다.
Architecture와 Flow
Kubernetes용 NGINX 로드밸런서는 Kubernetes 클러스터 내부에 있습니다. Kubernetes에 등록되어 nginx-ingress 서비스(NGINX Ingress Controller)를 감시합니다. 백엔드가 변경되면 Kubernetes용 NGINX 로드밸런서는 Worker IP와 NodePort TCP 포트 번호를 수집한 다음 NGINX Plus API를 통해 IP:ports를 NGINX Plus로 전송합니다 . NGINX 업스트림 서버는 로 업데이트되고 NGINX Plus는 트래픽을 올바른 업스트림 서버와 Kubernetes NodePorts로 로드밸런싱합니다. 추가 NGINX Plus 인스턴스를 추가하여 고가용성을no reload required 달성할 수 있습니다 .
Kubernetes용 NGINX 로드밸런서의 작동 스냅샷
아래 스크린샷에는 Kubernetes용 NGINX Loadbalancer가 배포되어 작업을 수행하는 모습을 보여주는 두 개의 창이 있습니다.
참고 : 이 예에서 Kubernetes 워커 노드는 10.1.1.8 및 10.1.1.10입니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
가동 중지 시간은 심각한 결과를 초래할 수 있습니다.
이러한 말은 대부분의 다른 산업보다 의료 기술 분야의 회사에 더 해당됩니다. 그들의 경우 "심각한 결과"에는 문자 그대로 사망이 포함될 수 있습니다. 우리는 최근에 의료 기록 보관을 펜과 종이에서 언제 어디서나 액세스할 수 있는 안전한 디지털 데이터로 전환하려는 회사의 기술 스택을 분석할 기회를 가졌습니다. 이러한 데이터는 환자 정보에서 치료 지침, 생물학적 마커, 의료 분석, 과거 기록 및 의료 팀 간에 공유되는 모든 것에 이르기까지 다양합니다.
처음부터 이 회사는 겉보기에 간단한 질문인 "케어 종사자가 실시간으로 데이터를 쉽게 기록하도록 어떻게 도울 수 있을까?"를 해결하고자 했습니다. 그러나 회사가 성장함에 따라 확장하고 데이터를 지속적으로 사용할 수 있게 해야 하는 필요성으로 인해 이 과제를 해결하는 것이 점점 더 복잡해졌습니다. 여기서는 이 회사의 기술 여정이 어떻게 Kubernetes 와 NGINX Ingress Controller를 도입하게 되었는지 설명합니다 .
기술 스택을 한눈에 보기
NGINX가 해당 아키텍처에서 어떻게 적용되는지 살펴보겠습니다.
종이의 문제
정기적으로 환자 상태와 치료 정보를 수집하는 것은 의료 종사자의 핵심 임무입니다. 전통적으로 그들은 환자 정보를 종이에 기록했거나, 최근에는 노트북이나 태블릿에 기록했습니다. 몇 가지 심각한 단점이 있습니다.
이러한 과제를 해결하기 위해 회사는 환자 정보에 액세스하고 약물 분배와 같은 일반적인 이벤트를 기록하기 위한 단축키를 제공하는 간소화된 데이터 기록 시스템을 만들었습니다. 이러한 액세스 및 사용의 용이성 덕분에 환자 상호작용을 발생하는 대로 실시간으로 기록할 수 있습니다.
모든 데이터는 회사에서 관리하는 클라우드 시스템에 저장되며, 앱은 다른 전자 의료 기록 시스템과 통합되어 거주자 행동에 대한 포괄적인 종단적 관점을 제공합니다. 이를 통해 간병인은 더 나은 치료 연속성을 제공하고, 안전한 과거 기록을 생성하며, 다른 의료 소프트웨어 시스템과 쉽게 공유할 수 있습니다.
의사와 다른 전문가도 환자를 입원시키거나 다른 방식으로 환자와 교류할 때 이 플랫폼을 사용합니다. 환자와 함께 모든 시설로 이동하는 선호도와 개인적 필요 사항의 기록이 있습니다. 이를 사용하여 환자가 새로운 환경에서 편안함을 느끼도록 도울 수 있으며, 이는 회복 시간과 같은 결과를 개선합니다.
회사가 환자 데이터를 얼마나 오랫동안 보관해야 하는지에 대한 엄격한 법적 요구 사항이 있습니다. 이 회사의 개발자는 일반 클라우드 애플리케이션보다 훨씬 더 나은 가동 시간 SLA로 매우 높은 가용성을 제공하는 소프트웨어를 구축했습니다. 환자의 파일이 로드되지 않아서 구급차를 기다리게 하는 것은 선택 사항이 아닙니다.
차고에서 클라우드로, 그리고 쿠버네티스로의 여행
많은 스타트업과 마찬가지로 이 회사는 공동 창업자의 집에 있는 서버에서 최초의 개념 증명 애플리케이션을 실행하여 처음에 비용을 절감했습니다. 이 아이디어가 타당하다는 것이 분명해지자 회사는 데이터 센터에서 하드웨어를 관리하는 대신 인프라를 클라우드로 옮겼습니다. Microsoft 매장인 그들은 Azure를 선택했습니다. 초기 아키텍처는 Microsoft의 IIS 웹 서버를 실행하는 관리형 애플리케이션 제공 서비스인 Azure App Service의 기존 가상 머신(VM)에서 애플리케이션을 실행했습니다. 데이터 저장 및 검색을 위해 이 회사는 VM에서 실행되는 Microsoft의 SQL Server를 관리형 애플리케이션으로 사용하기로 했습니다.
클라우드에서 수년간 운영한 후, 회사는 빠르게 성장하고 확장의 어려움을 겪었습니다. 회사는 무한히 확장해야 했고, VM을 사용하면 수직이 느리고 비용이 많이 들기 때문에 수평이 아닌 수평으로 확장해야 했습니다. 이러한 요구 사항으로 인해 컨테이너화와 Kubernetes가 가능한 솔루션으로 자연스럽게 이어졌습니다. 컨테이너화를 지지하는 또 다른 요점은 회사 개발자가 중단 위험 없이 애플리케이션과 인프라에 대한 업데이트를 자주 제공해야 한다는 것입니다. 환자 기록이 여러 시간대에 걸쳐 지속적으로 추가되면서 고객이 결함으로 인해 즉시 영향을 받을 위험 없이 프로덕션에 변경 사항을 푸시할 자연스러운 다운타임이 없습니다.
회사의 논리적인 시작점은 Microsoft의 관리형 Kubernetes 오퍼링인 Azure Kubernetes Services(AKS)였습니다. 팀은 Kubernetes 모범 사례를 조사하고 AKS의 노드와 포드에서 실행되는 트래픽과 애플리케이션을 효과적으로 관리하기 위해 Kubernetes 클러스터 앞에서 실행되는 Ingress 컨트롤러가 필요 하다는 것을 깨달았습니다.
Traffic 경로는 유연하면서도 정확해야 합니다.
팀은 AKS의 기본 Ingress 컨트롤러를 테스트했지만, 트래픽 라우팅 기능이 회사 고객에게 필요한 방식으로 업데이트를 제공할 수 없다는 것을 발견했습니다. 환자 케어에 관해서는 모호함이나 상충되는 정보에 대한 여지가 없습니다. 예를 들어, 한 케어 종사자가 주황색 플래그를 보고 다른 케어 종사자가 같은 이벤트에 대해 빨간색 플래그를 보는 것은 용납할 수 없습니다. 따라서 주어진 조직의 모든 사용자는 동일한 버전의 앱을 사용해야 합니다. 이는 업그레이드와 관련하여 큰 과제입니다. 고객을 새 버전으로 전환할 자연스러운 시기가 없으므로 회사는 서버 및 네트워크 수준에서 규칙을 사용하여 다른 고객을 다른 앱 버전으로 라우팅할 방법이 필요했습니다.
이를 달성하기 위해 이 회사는 조직의 모든 사용자에게 동일한 백엔드 플랫폼을 실행하고 조직 내 인프라 계층에서 세분화된 다중 테넌시를 제공하지 않습니다. Kubernetes를 사용하면 자세한 트래픽 규칙과 함께 브라우저의 가상 네트워크 경로 및 쿠키를 사용하여 트래픽을 분할할 수 있습니다. 그러나 이 회사의 기술 팀은 AKS의 기본 Ingress 컨트롤러는 필요에 따라 고객 조직 또는 개별 사용자 수준에서 작동하는 규칙이 아닌 백분율 기준으로만 트래픽을 분할할 수 있다는 것을 발견했습니다.
기본 구성에서 NGINX Open Source를 기반으로 하는 NGINX Ingress Controller는 동일한 제한이 있으므로 회사는 세분화된 트래픽 제어를 지원하는 엔터프라이즈급 제품인 NGINX Plus를 기반으로 하는 보다 고급 NGINX Ingress Controller로 전환하기로 결정했습니다. 높은 수준의 유연성과 제어를 기반으로 Microsoft와 Kubernetes 커뮤니티의 NGINX Ingress Controller에서 권장 사항을 찾은 것은 선택을 확고히 하는 데 도움이 되었습니다. 이 구성은 포드 관리(클래식 트래픽 관리와 대조적으로)에 대한 회사의 요구 사항을 더 잘 지원하여 포드가 적절한 영역에서 실행되고 트래픽이 해당 서비스로 라우팅되도록 합니다. 때로는 트래픽이 내부적으로 라우팅되지만 대부분의 사용 사례에서는 관찰 가능성을 위해 NGINX Ingress Controller를 통해 다시 라우팅됩니다.
Here Be Dragons: 모니터링, 관찰성 및 애플리케이션 성능
NGINX Ingress Controller를 사용하면 기술팀이 개발자와 최종 사용자 경험을 완벽하게 제어할 수 있습니다. 사용자가 로그인하여 세션을 설정하면 즉시 새 버전으로 라우팅되거나 이전 버전으로 되돌릴 수 있습니다. 패치는 조직의 모든 사용자에게 동시에 거의 즉시 푸시될 수 있습니다. 소프트웨어는 클라우드 플랫폼 전반의 네트워킹에 대한 DNS 전파나 업데이트에 의존하지 않습니다.
NGINX Ingress Controller는 또한 회사의 세부적이고 지속적인 모니터링 요구 사항을 충족합니다. 애플리케이션 성능은 의료 분야에서 매우 중요합니다. 지연이나 가동 중지 시간은 특히 생사의 상황에서 성공적인 임상 치료를 방해할 수 있습니다. Kubernetes로 이전한 후, 고객들은 회사에서 알아차리지 못한 가동 중지 시간을 보고하기 시작했습니다. 회사는 곧 문제의 근원을 발견했습니다. Azure App Service는 샘플링된 데이터에 의존합니다. 샘플링은 평균 및 광범위한 추세에는 적합하지만 거부된 요청 및 누락된 리소스와 같은 사항은 완전히 놓칩니다. 또한 간병인이 체크인하고 환자 데이터를 기록할 때 일반적으로 30분마다 발생하는 사용량 급증도 표시하지 않습니다. 회사는 지연, 오류 소스, 잘못된 요청 및 사용할 수 없는 서비스에 대한 불완전한 그림만 얻었습니다.
문제는 거기서 끝나지 않았습니다. 기본적으로 Azure App Service는 저장된 데이터를 한 달 동안만 보존합니다. 많은 국가의 법률에서 요구하는 수십 년보다 훨씬 짧습니다. 더 오래 보존하기 위해 필요에 따라 데이터 저장소를 확장하는 것은 엄청나게 비쌌습니다. 게다가 Azure 솔루션은 Kubernetes 네트워킹 스택 내부를 볼 수 없습니다. NGINX Ingress Controller는 4계층과 7계층 트래픽을 처리할 때 인프라와 애플리케이션 매개변수를 모두 모니터링할 수 있습니다.
성능 모니터링 및 관찰성을 위해 이 회사는 Grafana 시각화 엔진 및 대시보드에 연결된 Prometheus 시계열 데이터베이스를 선택했습니다. Prometheus와 Grafana와의 통합은 NGINX 데이터 및 제어 평면에 미리 구워져 있으며, 기술 팀은 모든 트래픽을 Prometheus 및 Grafana 서버를 통해 전달하기 위해 작은 구성 변경만 하면 되었습니다. 이 정보는 또한 Grafana Loki 로깅 데이터베이스로 라우팅되어 로그를 분석하기 쉬워졌고 소프트웨어 팀이 시간이 지남에 따라 데이터를 더 잘 제어할 수 있게 되었습니다.
이 구성은 또한 문제 해결 및 버그 수정을 위해 매우 빈번하고 방대한 양의 데이터 샘플링이 필요한 사고에 대비하여 미래를 보호합니다. 대부분의 대형 클라우드 회사에서 제공하는 애플리케이션 모니터링 시스템으로는 이러한 유형의 사고를 해결하는 데 비용이 많이 들 수 있지만 이 사용 사례에서 Prometheus, Grafana 및 Loki의 비용과 오버헤드는 최소입니다. 세 가지 모두 안정적인 오픈 소스 제품으로 일반적으로 초기 튜닝 후 패치만 하면 됩니다.
Routing 유지: 고가용성 및 보안에 집중
이 회사는 항상 가장 민감한 데이터 유형 중 하나를 보호하기 위한 보안과 필요할 때마다 앱을 사용할 수 있도록 하는 고가용성 에 중점을 두었습니다 . Kubernetes로 전환하면서 두 가지 용량을 모두 확장하기 위해 몇 가지 변경을 했습니다.
가장 높은 가용성을 위해 기술 팀은 단일 장애 지점 없이 완전한 중복성을 위해 액티브-액티브, 멀티 존, 멀티 지오 분산 인프라 설계를 구축합니다. 팀은 두 개의 다른 지리적 지역에 듀얼 쿠버네티스 클러스터가 있는 N+2 액티브-액티브 인프라를 유지 관리합니다. 각 지리적 지역 내에서 소프트웨어는 여러 데이터 센터에 걸쳐 다운타임 위험을 줄이고 인프라의 모든 계층에서 장애가 발생할 경우 적용 범위를 제공합니다. 친화성 및 반친화성 규칙은 사용자와 트래픽을 즉시 가동 중인 포드로 다시 라우팅하여 서비스 중단을 방지할 수 있습니다.
보안을 위해 팀은 잘못된 요청과 악의적인 행위자로부터 보호하기 위해 웹 애플리케이션 방화벽 (WAF)을 배포합니다. OWASP Top 10 에 대한 보호 는 대부분 WAF에서 제공하는 기본 사항입니다. 앱을 만들 때 팀은 기본 Azure WAF와 ModSecurity를 포함한 여러 WAF를 조사했습니다. 결국 팀은 인라인 WAF와 분산 서비스 거부 (DDoS) 보호 기능이 있는 NGINX App Protect를 선택했습니다.
NGINX App Protect의 큰 장점은 NGINX Ingress Controller와 함께 배치되어 중복 지점을 제거하고 지연 시간을 줄이는 것입니다. 다른 WAF는 Kubernetes 환경 외부에 배치해야 하므로 지연 시간과 비용이 증가합니다. 아주 사소한 지연(요청당 1밀리초 추가)도 시간이 지남에 따라 빠르게 누적됩니다.
서프라이즈 사이드 퀘스트: 개발자를 위한 다운타임 없음
대부분의 애플리케이션 및 네트워킹 인프라에 대해 AKS로의 전환을 완료한 이 회사는 개발자 경험(DevEx)에서도 상당한 개선을 이루었습니다. 이제 개발자는 고객이 문제를 알아차리기 전에 거의 항상 문제를 발견합니다. 전환 이후 오류에 대한 지원 전화의 양이 약 80% 감소했습니다!
회사의 보안 및 애플리케이션 성능 팀은 자세한 Grafana 대시보드와 통합 알림을 갖추고 있어 여러 시스템을 확인하거나 다른 프로세스에서 오는 경고 텍스트 및 호출에 대한 트리거를 구현할 필요가 없습니다. 개발 및 DevOps 팀은 이제 코드 및 인프라 업데이트를 매일 또는 하루에 여러 번 제공하고 매우 세부적인 청록색 패턴을 사용할 수 있습니다. 이전에는 일주일에 한두 번 업데이트를 제공하고 사용량이 적은 시간대에 시간을 내야 했으며 이는 스트레스가 많은 제안이었습니다. 이제 코드는 준비되면 제공되고 개발자는 애플리케이션 동작을 관찰하여 영향을 직접 모니터링할 수 있습니다.
결과는 전반적으로 긍정적입니다. 소프트웨어 개발 속도가 빨라지고, 개발자의 사기가 향상되고, 생명이 더 많이 구해졌습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
저희는 2023년 1월에 NGINX Ingress Controller 의 버전 3.0을 출시했으며, 여기에는 중요한 새로운 기능과 향상된 기능이 다수 포함되었습니다. 여러분께 특히 가치 있다고 생각되는 새로운 기능 중 하나는 NGINX Ingress Controller의 NGINX Plus 에디션에서 제공되는 Deep Service Insight입니다.
Deep Service Insight는 로드 밸런서와 같은 라우팅 결정 시스템이 하나 이상의 Kubernetes 클러스터 앞에 있을 때 최적의 기능을 방해하는 제한 사항을 해결합니다. 즉, 시스템은 Ingress 컨트롤러 뒤의 클러스터에서 실행되는 개별 서비스의 상태에 대한 정보에 액세스할 수 없습니다. 이를 통해 트래픽을 정상적인 서비스가 있는 클러스터로만 라우팅하지 못하게 되어 사용자를 중단 및 오류(예: 404) 에 노출시킬 가능성이 있습니다 500.
Deep Service Insight는 NGINX Ingress Controller에서 수집한 백엔드 서비스 포드의 상태를 전용 엔드포인트에 노출하여 시스템에서 액세스하고 더 나은 라우팅 결정을 내리는 데 활용할 수 있도록 함으로써 이러한 문제를 해결합니다.
이 게시물에서는 Deep Service Insight가 해결하는 문제를 자세히 살펴보고, 몇 가지 일반적인 사용 사례에서 이 기능이 어떻게 작동하는지 설명하고, 이를 구성하는 방법을 보여드리겠습니다.
왜 Deep Service Insight가 필요한가요?
표준 Kubernetes 라이브니스, 준비성 및 시작 프로브는 클러스터에서 실행되는 백엔드 서비스에 대한 정보를 제공하지만 스택 전체에 걸쳐 더 나은 라우팅 결정을 내리는 데 필요한 통찰력을 제공하기에는 충분하지 않습니다. Kubernetes 배포가 복잡해지고 중단 없는 가동 시간에 대한 비즈니스 요구 사항이 더 시급해짐에 따라 올바른 정보가 부족하면 문제가 더 커집니다.
Kubernetes 환경을 확장할 때 가동 시간을 개선하기 위한 일반적인 접근 방식은 클러스터 앞에 로드 밸런서, DNS 관리자 및 기타 자동화된 결정 시스템을 배포하는 것입니다. 그러나 Ingress 컨트롤러의 작동 방식 때문에 Kubernetes 클러스터 앞에 있는 로드 밸런서는 일반적으로 클러스터에서 Ingress 컨트롤러 뒤에 있는 서비스에 대한 상태 정보에 액세스할 수 없습니다. Ingress 컨트롤러 포드 자체가 정상이고 트래픽을 수용하는지 여부만 확인할 수 있습니다.
반면 NGINX Ingress Controller는 서비스 상태에 대한 정보를 가지고 있습니다. 이미 HTTP , TCP , UDP 및 gRPC 서비스에 대한 주기적 수동 상태 검사를 보내고, 요청 응답성을 모니터링하고, 성공적인 응답 코드 및 기타 메트릭을 추적하여 클러스터의 업스트림 포드 상태를 모니터링합니다. 이 정보를 사용하여 일관되고 예측 가능한 사용자 경험을 제공하기 위해 서비스의 포드에 트래픽을 분산하는 방법을 결정합니다. 일반적으로 NGINX Ingress Controller는 백그라운드에서 이 모든 마법을 조용히 수행하고 있으며, 후드 아래에서 무슨 일이 일어나고 있는지 두 번 생각하지 않을 수도 있습니다. Deep Service Insight는 이 귀중한 정보를 "표면화"하여 스택의 다른 계층에서 보다 효과적으로 사용할 수 있도록 합니다.
심층적 서비스 통찰력은 어떻게 작동하나요?
Deep Service Insight는 NGINX VirtualServer 및 TransportServer 사용자 지정 리소스(각각 HTTP 및 TCP/UDP용)를 사용하여 배포하는 서비스에 사용할 수 있습니다. Deep Service Insight는 NGINX Plus API를 사용하여 Deep Service Insight에 고유한 전용 엔드포인트에서 백엔드 서비스의 개별 포드에 대한 NGINX Ingress Controller의 뷰를 공유합니다.
어디
출력에는 두 가지 유형의 정보가 포함됩니다.
호스트 이름 또는 서비스 이름에 대한 HTTP 상태 코드:
지정된 호스트 이름 또는 서비스 이름에 대한 세 개의 카운터:
다음은 서비스의 세 개의 Pod가 모두 정상인 예입니다.
HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8 Date: Day, DD Mon YYYY hh:mm:ss TZ Content-Length: 32 {"Total":3,"Up":3,"Unhealthy":0}자세한 내용은 NGINX Ingress Controller 설명서를 참조하세요 .
활성 상태 검사를 구성하여 NGINX Ingress Controller가 포드가 정상인지 판단하는 데 사용하는 기준을 추가로 사용자 지정할 수 있습니다. 상태 검사가 전송되는 경로와 포트, 포드가 비정상으로 간주되기 위해 지정된 기간 내에 발생해야 하는 실패 검사 수, 예상 상태 코드, 연결 또는 응답 수신 시간 초과 등을 구성할 수 있습니다. VirtualServer 또는 TransportServerUpstream.Healthcheck 리소스 에 필드를 포함합니다 .
심층적인 서비스 통찰력을 위한 샘플 사용 사례
Deep Service Insight가 특히 가치 있는 사용 사례 중 하나는 로드 밸런서가 고가용성을 위해 두 클러스터에서 실행되는 서비스로 트래픽을 라우팅하는 경우입니다. 각 클러스터 내에서 NGINX Ingress Controller는 위에서 설명한 대로 업스트림 포드의 상태를 추적합니다. Deep Service Insight를 활성화하면 정상 및 비정상 업스트림 포드의 수에 대한 정보도 전용 엔드포인트에 노출됩니다. 라우팅 결정 시스템은 엔드포인트에 액세스하여 해당 정보를 사용하여 애플리케이션 트래픽을 비정상 포드에서 정상 포드로 전환할 수 있습니다.
이 다이어그램은 이 시나리오에서 Deep Service Insight가 작동하는 방식을 보여줍니다.
고가용성 시나리오에서 클러스터에 대한 유지 관리를 수행할 때 Deep Service Insight를 활용할 수도 있습니다. 유지 관리를 수행하는 클러스터에서 서비스에 대한 포드 수를 0으로 줄이기만 하면 됩니다. 건강한 포드가 없는 경우 Deep Service Insight 엔드포인트에 자동으로 표시되고 라우팅 결정 시스템은 해당 정보를 사용하여 다른 클러스터의 건강한 포드로 트래픽을 전송합니다. NGINX Ingress Controller나 시스템에서 구성을 변경하지 않고도 효과적으로 자동 장애 조치를 받을 수 있으며, 고객은 서비스 중단을 경험하지 않습니다.
심층적인 서비스 통찰력 활성화
Deep Service Insight를 활성화하려면 -enable-service-insightKubernetes 매니페스트에 명령줄 인수를 포함하거나 Helm을 사용하는 경우 serviceInsight.create매개변수를 로 설정합니다 true.
사용자 환경에 맞게 엔드포인트를 조정하기 위해 포함할 수 있는 두 가지 선택적 인수가 있습니다.
예: 카페 애플리케이션에 대한 심층적 서비스 통찰력 활성화
Deep Service Insight가 실제로 어떻게 활용되는지 확인하려면 NGINX Ingress Controller 설명서에서 예로 자주 사용되는 Cafe 애플리케이션 에서 이를 활성화하면 됩니다 .
NGINX 사용자 정의 리소스를 지원하고 Deep Service Insight를 활성화하는 NGINX Ingress Controller의 NGINX Plus 버전을 설치합니다.
NGINX Ingress Controller가 실행 중인지 확인하세요.
$ kubectl get pods -n nginx-ingressNAME READY ... ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 ... ... STATUS RESTARTS AGE ... Running 0 9dNGINX VirtualServer 사용자 정의 리소스가 Cafe 애플리케이션에 배포되었는지 확인합니다(IP 주소는 읽기 쉽도록 생략).
$ kubectl get vs NAME STATE HOST IP PORTS AGE cafe Valid cafe.example.com ... [80,443] 7h1mcafe.example.com 에서 실행되는 Cafe 서비스에 대해 세 개의 업스트림 포드가 있는지 확인하세요 .
$ kubectl get pods NAME READY STATUS RESTARTS AGE coffee-87cf76b96-5b85h 1/1 Running 0 7h39m coffee-87cf76b96-lqjrp 1/1 Running 0 7h39m tea-55bc9d5586-9z26v 1/1 Running 0 111mDeep Service Insight 엔드포인트에 액세스하세요.
$ curl -i <NIC_IP_address>:9114/probe/cafe.example.com응답 코드 는 200 OK서비스가 트래픽을 허용할 준비가 되었음을 나타냅니다(적어도 하나의 포드가 정상임). 이 경우 세 개의 포드가 모두 Up 상태입니다.
HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Day, DD Mon YYYY hh:mm:ss TZ Content-Length: 32 {"Total":3,"Up":3,"Unhealthy":0}상태 418 I’m a teapot코드는 서비스를 사용할 수 없음(모든 Pod가 비정상적임)을 나타냅니다.
HTTP/1.1 418 I'm a teapotContent-Type: application/json; charset=utf-8 Date: Day, DD Mon YYYY hh:mm:ss TZ Content-Length: 32 {"Total":3,"Up":0,"Unhealthy":3}상태 코드 404 Not Found는 지정된 호스트 이름에서 실행 중인 서비스가 없음을 나타냅니다.
HTTP/1.1 404 Not FoundDate: Day, DD Mon YYYY hh:mm:ss TZ Content-Length: 0위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
오늘날 기업에서 비용과 위험의 균형을 맞추는 것이 가장 중요합니다. 하지만 충분한 가시성이 없다면 리소스가 효과적으로 또는 일관되게 사용되고 있는지 알 수 없습니다.
쿠버네티스는 종종 일시적이고 가변적인 양의 클러스터 리소스를 소모하는 컨테이너화된 워크로드의 복잡한 배포를 가능하게 합니다. 이는 클라우드 환경이 쿠버네티스에 매우 적합한 이유입니다. 쿠버네티스는 피크 부하를 예상하여 과도하게 프로비저닝할 필요 없이 사용한 만큼만 비용을 지불하는 가격 모델을 제공하기 때문입니다. 물론 클라우드 공급업체는 이러한 편의성에 대해 프리미엄을 청구합니다. 비용 없이 퍼블릭 클라우드의 동적 로드 밸런싱을 잠금 해제할 수 있다면 어떨까요? 그리고 온프레미스 및 퍼블릭 클라우드 배포에 동일한 솔루션을 사용할 수 있다면 어떨까요?
이제 가능합니다. Kubecost와 NGINX는 Kubernetes 사용자가 수많은 배포에서 복잡성과 비용을 줄이는 데 도움을 줍니다. 이러한 솔루션을 함께 사용하면 최적의 성능과 해당 성능 및 관련 비용에 대한 궁극적인 가시성을 얻을 수 있습니다.
Kubecost의 통찰력을 통해 성능과 보안을 높이는 동시에 Kubernetes 배포 비용을 획기적으로 줄일 수 있습니다. Kubecost로 달성할 수 있는 것의 예는 다음과 같습니다.
NGINX는 당신에게 필요한 성능을 제공합니다
NGINX Ingress Controller는 가장 널리 사용되는 Ingress 기술 중 하나로, 지금까지 Docker Hub에서 10억 회 이상 풀을 달성했으며 , 프로덕션 환경에서 실행되는 고성능, 확장 가능 및 보안을 갖춘 최신 앱의 대명사입니다.
NGINX Ingress Controller는 Kubernetes 환경에서 NGINX Open Source 또는 NGINX Plus 인스턴스와 함께 실행됩니다. 표준 Kubernetes Ingress 리소스 와 NGINX 사용자 지정 리소스를 모니터링하여 Ingress 로드 밸런싱이 필요한 서비스에 대한 요청을 발견합니다. 그런 다음 NGINX Ingress Controller는 NGINX 또는 NGINX Plus를 자동으로 구성하여 이러한 서비스로 트래픽을 라우팅하고 로드 밸런싱합니다.
NGINX Ingress Controller는 API 게이트웨이, 로드 밸런서 및 Ingress 컨트롤러 기능을 결합하는 범용 도구로 사용하여 운영을 간소화하고 비용과 복잡성을 줄일 수 있습니다.
Kubecost가 네트워크 운영의 실제 비용을 공개합니다.
Kubecost는 Kubernetes 사용자에게 클러스터에서 각 컨테이너를 실행하는 데 드는 비용에 대한 가시성을 제공합니다. 여기에는 각 노드의 명백한 CPU, 메모리 및 스토리지 비용이 포함됩니다. 그러나 Kubecost는 이러한 기본 사항을 넘어 클라우드 공급자의 데이터 이탈 시 일반적으로 발생하는 포드당 네트워크 전송 비용을 공개합니다.
Kubecost가 올바른 작업 부하에 비용을 얼마나 정확하게 할당하는지를 결정하는 두 가지 구성 옵션이 있습니다.
첫 번째 옵션은 통합 클라우드 청구 입니다 . Kubecost는 트래픽을 처리한 노드와 관련된 네트워크 전송 비용을 포함하여 클라우드 공급자로부터 청구 데이터를 가져옵니다. Kubecost는 이 비용을 컨테이너 트래픽의 공유에 따라 해당 노드의 포드에 분배합니다.
보고된 총 네트워크 비용은 정확하지만 이 방법은 이상적이지 않습니다. 많은 포드의 경우 유일하게 중요한 트래픽은 자체 존(따라서 무료) 내에 있지만 Kubecost는 이러한 워크로드에 대한 네트워크 비용을 보여줍니다.
두 번째 옵션인 네트워크 비용 구성은 모든 트래픽의 소스와 목적지를 살펴봄으로써 클라우드 청구 통합의 이러한 한계를 해결합니다. Kubecost Allocations 대시보드는 네임스페이스, 레이블, 서비스와 같은 Kubernetes 개념과 팀, 제품, 프로젝트, 부서, 환경과 같은 조직 부문을 포함한 여러 범주에 걸친 지출 비율을 표시합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
12팩터 앱 으로 알려진 가이드라인은 10년 이상 전에 처음 발표되었습니다. 그 이후로 거의 모든 의무적 관행이 웹 앱을 작성하고 배포하는 사실상의 표준 방식이 되었습니다. 그리고 앱이 구성되고 배포되는 방식이 변경된 상황에서도 여전히 적용 가능하지만, 어떤 경우에는 앱 을 개발하고 배포하기 위한 마이크로서비스 패턴에 관행이 어떻게 적용되는지 이해하기 위해 추가적인 뉘앙스가 필요합니다.
이 블로그는 환경에서 구성 저장의 요소 3에 초점을 맞추고 있으며 다음과 같이 설명합니다.
마이크로서비스로 이동하면서 이러한 지침을 여전히 준수할 수 있지만, 항상 12팩터 앱의 문자 그대로의 해석에 정확히 매핑되는 방식은 아닙니다. 환경 변수로 구성 데이터를 제공하는 것과 같은 일부 지침은 훌륭하게 이어집니다. 12팩터 앱의 핵심 원칙을 존중하는 다른 일반적인 마이크로서비스 관행은 이를 확장한 것과 더 비슷합니다. 이 게시물에서는 팩터 3의 관점에서 마이크로서비스의 구성 관리에 대한 세 가지 핵심 개념을 살펴보겠습니다.
주요 마이크로서비스 용어 및 개념
마이크로서비스에 맞게 Factor 3을 적용하는 것에 대한 논의에 들어가기 전에 몇 가지 핵심 용어와 개념을 이해하는 것이 도움이 됩니다.
마이크로서비스 대 모놀리스
모놀리식 애플리케이션에서는 조직의 모든 팀이 동일한 애플리케이션과 주변 인프라에서 작업합니다. 모놀리식 앱은 일반적으로 문서상으로는 마이크로서비스보다 간단해 보이지만 조직이 마이크로서비스로 이동하기로 결정하는 데에는 몇 가지 일반적인 이유가 있습니다.
물론 마이크로서비스에는 복잡성 증가, 관찰성 감소, 새로운 보안 모델 필요성 등 고유한 과제가 있습니다. 하지만 많은 조직, 특히 대규모 또는 빠르게 성장하는 조직은 고객에게 제공하는 경험에 대한 안정적이고 신뢰할 수 있는 기반을 구축하는 데 있어 팀에 더 많은 자율성과 유연성을 제공하기 위해 이러한 과제를 감수할 가치가 있다고 결정합니다.
마이크로서비스 아키텍처에 필요한 변경 사항
모놀리식 앱을 마이크로서비스로 리팩토링하는 경우 서비스는 다음을 수행해야 합니다.
모놀리식 앱의 경우 프로세스의 작은 불일치와 공유된 가정에 대한 종속성은 중요하지 않습니다. 그러나 많은 개별 마이크로서비스의 경우 이러한 불일치와 가정은 많은 고통과 혼란을 초래할 수 있습니다. 마이크로서비스에서 변경해야 하는 많은 부분은 기술적으로 필요하지만 놀랍게도 많은 부분이 팀이 내부적으로 작업하고 다른 팀과 상호 작용하는 방식과 관련이 있습니다.
마이크로서비스 아키텍처를 적용한 주요 조직 변화는 다음과 같습니다.
서비스 구성을 명확하게 정의하기
팩터 3을 확장해야 하는 마이크로서비스 아키텍처의 한 영역은 구성을 포함한 서비스에 대한 특정 중요 정보를 명확하게 정의하고 다른 서비스와 최소한의 공유 컨텍스트를 가정해야 할 필요성과 관련이 있습니다. 팩터 3은 이를 직접 다루지는 않지만, 애플리케이션 기능에 기여하는 개별 마이크로서비스가 많은 경우 특히 중요합니다.
마이크로서비스 아키텍처의 서비스 소유자로서, 귀하의 팀은 시스템 전체에서 특정 역할을 하는 서비스를 소유합니다. 귀하의 서비스와 상호 작용하는 다른 팀은 귀하의 서비스 저장소에 액세스하여 코드와 문서를 읽고 기여해야 합니다.
게다가, 소프트웨어 개발 분야에서 팀 구성원이 자주 바뀌는 것은 불행한 현실입니다. 개발자가 회사에 들어오고 나가기 때문일 뿐만 아니라 내부 조직 개편 때문이기도 합니다. 또한 주어진 서비스에 대한 책임도 종종 팀 간에 이전됩니다.
이러한 현실에 비추어 볼 때, 귀하의 코드베이스와 문서는 매우 명확하고 일관성이 있어야 하며, 이는 다음을 통해 달성됩니다.
많은 애플리케이션 프레임워크는 필요한 구성을 정의하는 수단을 제공합니다. 예를 들어, convictNode.js 애플리케이션용 NPM 패키지는 단일 파일에 저장된 완전한 구성 "스키마"를 사용합니다. 이는 Node.js 앱이 실행하는 데 필요한 모든 구성에 대한 진실의 원천 역할을 합니다.
강력하고 쉽게 발견할 수 있는 스키마를 통해 팀원과 다른 사람들이 서비스를 자신 있게 사용할 수 있습니다.
구성이 서비스에 제공되는 방법
애플리케이션에 필요한 구성 값을 명확하게 정의했다면 배포된 마이크로서비스 애플리케이션이 구성을 가져오는 두 가지 기본 소스 간의 중요한 구별도 존중해야 합니다.
배포 스크립트는 마이크로서비스 아키텍처에서 일반적인 코드 구성 패턴입니다. 12팩터 앱이 처음 공개된 이후로 새로운 것이기 때문에 필연적으로 12팩터 앱의 확장을 나타냅니다.
패턴: 애플리케이션 옆의 배포 및 인프라 구성
최근 몇 년 동안 애플리케이션 코드와 동일한 저장소에 infrastructure (또는 이와 비슷한 이름의 변형) 라는 폴더를 두는 것이 일반적이 되었습니다 . 여기에는 일반적으로 다음이 포함됩니다.
언뜻 보면 이는 구성과 코드를 엄격하게 분리해야 한다는 요소 3의 규정을 위반하는 것처럼 보일 수 있습니다.
사실, 애플리케이션 옆 에 배치하면 인프라 폴더가 실제로 규칙을 준수하는 동시에 마이크로서비스 환경에서 작업하는 팀에 중요한 귀중한 프로세스 개선을 가능하게 한다는 것을 의미합니다.
이 패턴의 장점은 다음과 같습니다.
이 패턴이 제공하는 이점은 개별 팀의 자율성을 강화하는 동시에 배포 및 구성 프로세스에 추가적인 엄격성이 적용된다는 것입니다.
어떤 유형의 구성이 어디에 적용됩니까?
실제로 인프라 폴더에 저장된 배포 스크립트를 사용하여 스크립트 자체에 명시적으로 정의된 구성과 배포 시점에 외부 소스에서 구성을 검색하는 작업을 모두 관리합니다. 이를 위해 서비스에 대한 배포 스크립트를 다음과 같이 사용합니다.
서비스의 특정 배포에 특화되어 있고 팀의 완전한 통제 하에 있는 구성 값은 인프라 폴더의 파일에 직접 지정할 수 있습니다. 예를 들어 앱에서 시작한 데이터베이스 쿼리가 실행될 수 있는 시간 제한과 같은 것이 있습니다. 이 값은 배포 파일을 수정하고 애플리케이션을 다시 배포하여 변경할 수 있습니다.
이 계획의 한 가지 이점은 이러한 구성에 대한 변경 사항이 반드시 코드 검토 및 자동화된 테스트를 거쳐야 하므로 잘못 구성된 값으로 인해 중단이 발생할 가능성이 줄어든다는 것입니다. 코드 검토를 거치는 값과 주어진 시간의 구성 키 값에 대한 변경 사항은 소스 제어 툴링의 기록에서 발견할 수 있습니다.
애플리케이션이 실행되는 데 필요하지만 팀의 제어를 받지 않는 값은 애플리케이션이 배포된 환경에서 제공해야 합니다. 예를 들어, 서비스가 종속된 다른 마이크로서비스에 연결하는 호스트 이름과 포트가 있습니다.
해당 서비스는 귀하의 팀이 소유하지 않으므로 포트 번호와 같은 값에 대해 가정할 수 없습니다. 이러한 값은 언제든지 변경될 수 있으며 변경 시 일부 중앙 구성 저장소에 등록해야 합니다. 해당 변경이 수동으로 이루어지든 자동 프로세스로 이루어지든 상관없습니다. 그런 다음 해당 값에 의존하는 애플리케이션에서 쿼리할 수 있습니다.
이러한 지침은 마이크로서비스 구성을 위한 두 가지 모범 사례로 요약할 수 있습니다.
마이크로서비스 구성에서는 하드코딩된 값이나 상호 합의된 값에 의존하지 마십시오.
배포 스크립트에서 특정 값(예: 서비스가 상호 작용하는 서비스의 위치)을 하드코딩하는 것이 가장 간단해 보일 수 있습니다. 실제로 그러한 유형의 구성을 하드코딩하는 것은 위험하며, 특히 서비스 위치가 일반적으로 자주 변경되는 현대 환경에서 더욱 그렇습니다. 그리고 두 번째 서비스를 소유하지 않은 경우 특히 위험합니다.
스크립트에서 서비스 위치를 업데이트하기 위해 자신의 근면함에 의지할 수 있다고 생각할 수도 있고, 더 나쁜 경우 위치가 변경될 때 소유팀이 알려줄 것이라고 생각할 수도 있습니다. 근면함은 스트레스가 많은 시기에 종종 미끄러지고, 인간의 엄격함에 의존하면 시스템이 경고 없이 실패할 위험이 있습니다.
마이크로서비스 구성에서 해야 할 일: 서비스에 "내 데이터베이스는 어디에 있습니까?"라고 묻게 하세요.
위치 정보가 하드코딩되어 있든 아니든, 애플리케이션은 특정 위치에 있는 중요한 인프라에 의존해서는 안 됩니다. 대신, 새로 배포된 서비스는 "내 데이터베이스는 어디에 있습니까?"와 같은 시스템 내의 일반적인 소스에 질문을 하고 해당 외부 리소스의 현재 위치에 대한 정확한 답변을 받아야 합니다. 모든 서비스가 배포될 때 시스템에 등록하면 훨씬 더 간단해집니다.
서비스를 구성으로 사용 가능하게 만들기
시스템이 "내 데이터베이스는 어디에 있나요?"와 "내가 사용하는 '서비스 X'는 어디에 있나요?"라는 질문에 대한 답을 제공해야 하는 것처럼, 서비스는 배포 방법에 대해 전혀 알지 못해도 다른 서비스가 쉽게 찾아서 통신할 수 있는 방식으로 시스템에 노출되어야 합니다.
마이크로서비스 아키텍처의 핵심 구성 관행은 서비스 검색입니다. 새로운 서비스 정보를 등록하고 다른 서비스에서 액세스할 때 해당 정보를 동적으로 업데이트하는 것입니다. 마이크로서비스에 서비스 검색이 필요한 이유를 설명한 후 NGINX Open Source와 Consul을 사용하여 이를 달성하는 방법의 예를 살펴보겠습니다.
서비스의 여러 인스턴스(배포)를 동시에 실행하는 것은 일반적인 관행입니다. 이를 통해 추가 트래픽을 처리할 수 있을 뿐만 아니라 새로운 배포를 시작하여 다운타임 없이 서비스를 업데이트할 수도 있습니다. 리버스 프록시 및 로드 밸런서 역할을 하는 NGINX와 같은 도구는 들어오는 트래픽을 처리하여 가장 적합한 인스턴스로 라우팅합니다. 이는 서비스에 의존하는 서비스가 NGINX에만 요청을 보내고 배포에 대해 아무것도 알 필요가 없기 때문에 좋은 패턴입니다.
예를 들어, NGINX 뒤에서 역방향 프록시 역할을 하는 messenger 라는 서비스의 단일 인스턴스가 있다고 가정해 보겠습니다 .
이제 앱이 인기를 얻으면 어떨까요? 좋은 소식으로 여겨지지만, 트래픽이 증가했기 때문에 메신저 인스턴스가 많은 CPU를 소모하고 요청을 처리하는 데 시간이 더 오래 걸리는 반면 데이터베이스는 정상적으로 작동하는 것 같습니다. 이는 메신저 서비스 의 다른 인스턴스를 배포하면 문제를 해결할 수 있음을 나타냅니다 .
메신저 서비스 의 두 번째 인스턴스를 배포할 때 NGINX는 그것이 라이브 상태인지 어떻게 알고 트래픽을 보내기 시작합니까? NGINX 구성에 새 인스턴스를 수동으로 추가하는 것은 한 가지 접근 방식이지만, 더 많은 서비스가 확장되고 축소됨에 따라 빠르게 관리하기 어려워집니다.
일반적인 해결책은 Consul 과 같은 고가용성 서비스 레지스트리가 있는 시스템에서 서비스를 추적하는 것입니다 . 새로운 서비스 인스턴스는 배포될 때 Consul에 등록됩니다. Consul은 주기적으로 상태 검사를 보내 인스턴스의 상태를 모니터링합니다. 인스턴스가 상태 검사에 실패하면 사용 가능한 서비스 목록에서 제거됩니다.
NGINX는 다양한 방법을 사용하여 Consul과 같은 레지스트리를 쿼리하고 그에 따라 라우팅을 조정할 수 있습니다. 리버스 프록시 또는 로드 밸런서 역할을 할 때 NGINX가 트래픽을 "업스트림" 서버로 라우팅한다는 점을 기억하세요. 다음과 같은 간단한 구성을 고려하세요.
# Define an upstream group called "messenger_service" upstream messenger_service { server 172.18.0.7:4000; server 172.18.0.8:4000; } server { listen 80; location /api { # Proxy HTTP traffic with paths starting with '/api' to the # 'upstream' block above. The default load-balancing algorithm, # Round-Robin, alternates requests between the two servers # in the block. proxy_pass http://messenger_service; proxy_set_header X-Forwarded-For $remote_addr; } }기본적으로 NGINX는 트래픽을 라우팅하기 위해 각 메신저 인스턴스 의 정확한 IP 주소와 포트를 알아야 합니다 . 이 경우 172.18.0.7과 172.18.0.8 모두에서 포트 4000입니다.
여기서 Consul과 Consul 템플릿이 등장합니다. Consul 템플릿은 NGINX와 동일한 컨테이너에서 실행되며 서비스 레지스트리를 유지 관리하는 Consul 클라이언트와 통신합니다.
레지스트리 정보가 변경되면 Consul 템플릿은 올바른 IP 주소와 포트를 사용하여 NGINX 구성 파일의 새 버전을 생성하고, NGINX 구성 디렉토리에 쓰고, NGINX에 구성을 다시 로드하라고 지시합니다. NGINX가 구성을 다시 로드할 때 다운타임이 없으며 , 새 인스턴스는 다시 로드가 완료되는 즉시 트래픽을 수신하기 시작합니다.
이런 상황에서 NGINX와 같은 역방향 프록시를 사용하면 다른 서비스가 액세스할 수 있는 장소로 시스템에 등록할 수 있는 단일 터치 포인트가 있습니다. 귀하의 팀은 다른 서비스가 서비스 전체에 대한 액세스를 잃을까 봐 걱정할 필요 없이 개별 서비스 인스턴스를 관리할 수 있는 유연성을 갖습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
두 팀이 공통의 목표를 향해 노력하는 성공만이 오늘날의 현대적 애플리케이션이 적절한 보안과 확장성을 갖추고 제때에 제공되도록 보장할 수 있습니다. 그렇다면 각 팀의 기술과 전문성을 활용하면서 그들이 협력하도록 돕는 방법은 무엇일까요?
저희의 백서 ' Get Me to the Cluster' 에서는 네트워크팀과 애플리케이션팀이 갈등 없이 각자의 강점을 결합할 수 있도록 Kubernetes 서비스에 대한 외부 액세스를 활성화하는 솔루션을 자세히 설명합니다.
Kubernetes 클러스터에서 앱을 노출하는 방법
이 솔루션은 특히 온프레미스에서 호스팅되는 Kubernetes 클러스터에 적합하며 , 노드는 베어 메탈 또는 기존 Linux 가상 머신(VM)에서 실행되고 표준 레이어 2 스위치와 레이어 3 라우터는 데이터 센터에서 통신을 위한 네트워킹을 제공합니다. 클라우드 호스팅 Kubernetes 클러스터에는 적용되지 않습니다. 클라우드 공급자는 데이터 센터의 핵심 네트워킹이나 관리되는 Kubernetes 환경의 네트워킹을 제어할 수 없기 때문입니다.
솔루션의 세부 사항을 살펴보기 전에 Kubernetes 클러스터에서 애플리케이션을 노출하는 다른 표준 방식이 온프레미스 배포에 적합하지 않은 이유를 살펴보겠습니다.
온프레미스 Kubernetes 클러스터에 대한 외부 사용자 액세스 활성화
그러면 클러스터 외부의 사용자에서 클러스터 내부의 포드로 흐르는 트래픽(북쪽에서 남쪽으로 트래픽)을 위해 특별히 설계된 Kubernetes Ingress 객체가 남습니다. Ingress는 클러스터에 대한 외부 HTTP/HTTPS 진입점을 만듭니다. 외부 사용자가 여러 서비스에 액세스할 수 있는 단일 IP 주소 또는 DNS 이름입니다. 이것이 바로 필요한 것입니다! Ingress 객체는 Ingress 컨트롤러에 의해 구현됩니다. 당사 솔루션에서는 NGINX Plus 기반의 엔터프라이즈급 F5 NGINX Ingress 컨트롤러입니다 .
솔루션의 또 다른 핵심 구성 요소가 레이어 3 라우팅 프로토콜인 Border Gateway Protocol (BGP)이라는 사실에 놀라실지도 모릅니다. 하지만 훌륭한 솔루션은 복잡할 필요가 없습니다!
Get Me to the Cluster 에 설명된 솔루션은 실제로 4가지 구성 요소로 구성되어 있습니다.
이 다이어그램은 솔루션 아키텍처를 보여주며, 요청 처리 중에 데이터가 교환되는 순서가 아닌 솔루션 구성 요소가 통신하는 데 사용하는 프로토콜을 나타냅니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기