Kubernetes 앱에 적합한 Service Mesh를 선택하는 방법

최근 몇 년 동안 조직이 마이크로서비스 및 컨테이너화된 앱에 대한 투자를 심화함에 따라 Service Mesh 채택이 최첨단에서 주류로 꾸준히 이동했습니다. Cloud-Native 기술 사용에 대한 Cloud Native Computing Foundation의 2020년 설문 조사를 통해 다음과 같은 결론에 도달했습니다.

목차
1. 시사점: Service Mesh 채택이 빠르게 증가하고 있습니다.
2. 시사점: 컨테이너 사용 증가는 더 많은 조직에서 고급 트래픽 관리 및 보안 도구를 필요로 하며 잠재적으로 Mesh의 이점을 누릴 수 있음을 나타냅니다.
3. 시사점: 컨테이너의 세 가지 주요 과제는 서로 연관되어 있습니다.
4. Service Mesh를 사용할 준비가 되셨습니까?
  4-1. 프로덕션 환경을 위한 Kubernetes에 완전히 투자했습니다.
  4-2. 제로 트러스트 프로덕션 환경이 필요하고 서비스 간에 상호 TLS(mTLS)가 필요합니다.
  4-3. 귀하의 앱은 서비스의 수와 깊이 모두에서 복잡합니다.
  4-4. 성숙한 프로덕션 CI/CD 파이프라인이 있습니다.
  4-5. 최소한 하루에 한 번 프로덕션에 자주 배포하고 있습니다.
  4-6. DevOps 팀은 최신 앱 배포에 적합한 도구를 사용할 준비가 되었습니다!
5. 앱에 적합한 Service Mesh를 선택하는 방법
  5-1. 1단계: Service Mesh를 찾는 이유는 무엇입니까?
  5-2. 2단계: Service Mesh를 어떻게 사용합니까?
  5-3. 3단계: 선택에 영향을 주는 요소는 무엇입니까?
6. NGINX가 도움이 되는 방법
  6-1. 아키텍처 정보
  6-2. NGINX Service Mesh 이점
7. Service Mesh를 사용할 준비가 되지 않았습니까?

1. 시사점: Service Mesh 채택이 빠르게 증가하고 있습니다.

2. 시사점: 컨테이너 사용 증가는 더 많은 조직에서 고급 트래픽 관리 및 보안 도구를 필요로 하며 잠재적으로 Mesh의 이점을 누릴 수 있음을 나타냅니다.

3. 시사점: 컨테이너의 세 가지 주요 과제는 서로 연관되어 있습니다.

4. Service Mesh를 사용할 준비가 되셨습니까?

NGINX에서는 더 이상 “Service Mesh를 사용해야 합니까?”라는 이진(binary) 질문이 아니라고 생각합니다. 대신 “언제 Service Mesh를 사용할 준비가 될까요?” 프로덕션 환경에 컨테이너를 배포하고 Kubernetes를 사용하여 이를 오케스트레이션하는 사람은 누구나 Service Mesh가 가치를 추가하는 앱 및 인프라 성숙도 수준에 도달할 가능성이 있다고 믿습니다.

그러나 다른 기술과 마찬가지로 Service Mesh가 필요하기 전에 구현하면 비즈니스에 얻을 수 있는 이점보다 더 큰 위험과 비용이 추가될 뿐입니다. 우리는 준비 상태를 확인하고 현대화 여정을 이해하기 위해 Service Mesh 도입에 관심이 있는 고객과 함께 이 6가지 체크리스트를 사용합니다. 귀하에게 맞는 진술이 많을수록 Service Mesh가 가치를 더할 것입니다.

4-1. 프로덕션 환경을 위한 Kubernetes에 완전히 투자했습니다.

프로덕션 앱을 이미 Kubernetes로 이동했든 컨테이너 워크로드로의 앱 마이그레이션 테스트를 막 시작했든 장기 애플리케이션 관리 로드맵에는 Kubernetes가 포함됩니다.

4-2. 제로 트러스트 프로덕션 환경이 필요하고 서비스 간에 상호 TLS(mTLS)가 필요합니다.

이미 프로덕션 앱에 대해 제로 트러스트 모델에 의존하고 있으며 컨테이너화된 환경에서 해당 수준의 보안을 유지해야 하거나 서비스 수준 보안을 강화하기 위한 강제 기능으로 마이그레이션을 사용하고 있습니다.

4-3. 귀하의 앱은 서비스의 수와 깊이 모두에서 복잡합니다.

대규모 분산 앱이 있습니다. 여러 API 종속성이 있으며 외부 종속성이 필요할 가능성이 큽니다.

4-4. 성숙한 프로덕션 CI/CD 파이프라인이 있습니다.

“성숙”은 조직에 따라 다릅니다. 우리는 이 용어를 Git, Jenkins, Artifactory 또는 Selenium과 같은 도구를 사용하여 프로그래밍 방식으로 Kubernetes 인프라 및 앱을 배포하는 절차에 적용합니다.

4-5. 최소한 하루에 한 번 프로덕션에 자주 배포하고 있습니다.

여기에서 대부분의 사람들이 “아니오”라고 답합니다. 앱을 프로덕션 Kubernetes로 옮겼지만 지속적인 수정이라는 꿈의 목표를 위해 아직 Kubernetes를 사용하고 있지는 않습니다.

4-6. DevOps 팀은 최신 앱 배포에 적합한 도구를 사용할 준비가 되었습니다!

Service Mesh가 NetOps 팀에서 소유할 예정이더라도 DevOps 팀이 클러스터 내에서 관리를 처리하는 경우가 많으며 스택에 Mesh 추가를 처리할 준비가 되어 있어야 합니다.

6개 문항에 모두 “예”라고 대답하지 않았습니까? 괜찮아! Service Mesh를 위해 팀을 준비하기 위해 할 수 있는 일을 포함하여 준비가 된 후 여정이 어디로 향할 것인지에 대한 아이디어를 얻으려면 계속 읽으십시오.

5. 앱에 적합한 Service Mesh를 선택하는 방법

Service Mesh를 사용할 준비가 되었다고 결정한 후에도 여전히 선택할 수 있는 폭이 매우 다양합니다. Kubernetes가 사실상의 컨테이너 오케스트레이션 표준이 된 것처럼 Istio는 종종 사실상의 Service Mesh 표준으로 간주됩니다. 사실, Istio가 널리 보급되어 있을 뿐만 아니라 Kubernetes 네트워킹 세계의 거의 모든 문제를 해결하는 것을 목표로 하기 때문에 Istio가 유일한 선택이라고 생각하기 쉽습니다. 건전한 자급자족의 위험을 무릅쓰고 Istio가 유일한 선택이 아니며 모든 사람 또는 모든 사용 사례에 적합한 선택도 아님을 알려드립니다. Istio는 환경에 많은 복잡성을 추가하고 전체 엔지니어 팀이 이를 실행해야 할 수 있으며 종종 해결하는 것보다 더 많은 문제가 발생하게 됩니다.

어떤 Service Mesh가 앱에 가장 적합한지 명확히 하려면 팀 및 이해 관계자와 함께 전략적 계획 세션을 수행하는 것이 좋습니다. 다음은 이러한 토론을 촉진하는 데 도움이 되는 대화 가이드입니다.

5-1. 1단계: Service Mesh를 찾는 이유는 무엇입니까?

즉, Service Mesh가 해결해야 하는 문제는 무엇입니까? 예를 들어 조직에서 서비스 간에 mTLS를 의무화하거나 edge인(Ingress 트래픽의 경우) 및 Mesh 내(egress 트래픽의 경우)를 모두 포함하는 종단 간 암호화가 필요할 수 있습니다. 또는 새로운 Kubernetes 서비스를 위한 엔터프라이즈급 트래픽 관리 도구가 필요할 수도 있습니다.

5-2. 2단계: Service Mesh를 어떻게 사용합니까?

이것은 당신이 누구인지에 달려 있습니다.

개발자인 경우:
- Kubernetes로 이전되는 레거시 앱에 보안을 추가할 계획입니까?
- 앱을 기본 Kubernetes 앱으로 리팩토링할 때 보안을 통합하시겠습니까?

플랫폼 및 인프라를 담당하는 경우:
- Service Mesh를 CI/CD 파이프라인에 추가하여 모든 새 클러스터와 함께 자동으로 배포 및 구성되고 개발자가 새 인스턴스를 만들 때 사용할 수 있도록 하시겠습니까?

5-3. 3단계: 선택에 영향을 주는 요소는 무엇입니까?

Service Mesh는 인프라에 구애받지 않아야 합니까? 가시성 도구와 호환됩니까? Kubernetes Native? 사용하기 쉬운? Mesh 내 service-to-service(east-west) 트래픽과 동일한 도구를 사용하여 edge에서 Ingress 및 Egress(north-south) 트래픽을 관리하려는 미래가 보입니까?

이러한 질문을 해결하고 나면 옵션을 평가할 때 사용할 확실한 요구 사항 목록을 갖게 됩니다.

6. NGINX가 도움이 되는 방법

2020년 개발 릴리스로 도입된 NGINX Service Mesh가 공식적으로 프로덕션 준비가 되었음을 발표하게 되어 기쁩니다! NGINX Service Mesh는 무료이며 개발자를 위해 최적화되었으며 east-west(service-to-service ) 트래픽과 north-south(Ingress 및 Egress) 모두에 대해 Kubernetes에서 mTLS 및 종단 간 암호화를 구현하는 가장 가볍고 쉬운 방법입니다. 우리는 가장 방해가 되지 않으면서도 고급 유연성과 중요한 통찰력을 제공하는 방식으로 애플리케이션 데이터 플레인을 완전히 제어할 수 있기를 원하기 때문에 자체 Service Mesh를 구축했습니다.

다음과 같은 Mesh가 필요한 경우 NGINX Service Mesh를 좋아할 것입니다.

사용하기 쉬운. Service Mesh를 관리하고 이미 복잡한 Kubernetes 환경에 mTLS 및 고급 트래픽 관리를 추가하기 위해 복잡한 도구 세트를 사용하고 싶지 않습니다.

경량. 리소스를 소모하거나 성능에 영향을 미치지 않는 구성 요소를 원합니다.

인프라에 구애받지 않습니다. 모든 Kubernetes 환경에서 동일한 Service Mesh를 사용할 계획입니다.

귀하의 생태계와 호환됩니다. 대기 시간을 추가하지 않고 Ingress Controller 및 가시성 도구와 통합되는 Kubernetes Native Service Mesh가 필요합니다.

6-1. 아키텍처 정보

NGINX Service Mesh에는 두 가지 주요 구성 요소가 있습니다.

Control Plane

Kubernetes API 서버와 협력하여 앱에 대한 동적 지원 및 관리를 제공하는 경량 Control Plane을 구축했습니다. 각 워크로드 인스턴스가 자동으로 보호되고 다른 앱 구성 요소와 통합되도록 확장 및 배포할 때 앱에 반응하고 업데이트하므로 “설정하고 잊어버리고” 귀중한 비즈니스 솔루션에 시간을 할애할 수 있습니다.

Data Plane

NGINX Service Mesh의 진정한 별은 완전히 통합된 고성능 Data Plane입니다. NGINX Plus의 기능을 활용하여 가용성과 확장성이 뛰어난 컨테이너화된 환경을 운영하는 당사의 Data Plane은 다른 Sidecar가 제공할 수 없는 수준의 엔터프라이즈 트래픽 관리, 성능 및 확장성을 시장에 제공합니다. 프로덕션 수준의 서비스 메시 배포에 필요한 원활하고 투명한 로드 밸런싱, 리버스 프록시, 트래픽 라우팅, ID 및 암호화 기능을 제공합니다. NGINX Plus 기반 버전의 NGINX Ingress Controller와 함께 사용하면 단일 구성으로 관리할 수 있는 통합 Data Plane을 제공합니다.

6-2. NGINX Service Mesh 이점

NGINX Service Mesh에서 몇 가지 이점을 기대할 수 있습니다.

복잡성 감소

NGINX Service Mesh는 사용하기 쉽고 인프라에 구애받지 않습니다. Kubernetes의 Service Mesh에 대한 표준 인터페이스를 정의하는 SMI(Service Mesh Interface) 사양을 구현하고 프로덕션 트래픽에 대한 최소한의 노력과 중단으로 새 앱 버전을 롤아웃할 수 있는 SMI 확장을 제공합니다. NGINX Service Mesh는 또한 NGINX Ingress Controller와 기본적으로 통합되어 service-to-service(east-west) 리버스 프록시를 사용하여 edge에서 ingress 및 egress(north-south) 트래픽 관리 구성을 중앙 집중화하고 간소화할 수 있는 통합 data plane을 생성합니다. sidecar 트래픽 관리. 그리고 다른 mesh와 달리 NGINX Service Mesh는 NGINX Ingress Controller에 sidecar를 삽입할 필요가 없으므로 Kubernetes 환경에 대기 시간과 복잡성이 추가되지 않습니다.

회복 탄력성 향상

컨테이너 트래픽의 지능형 관리를 통해 트래픽을 새로 배포된 Service 인스턴스로 제한하고 시간이 지남에 따라 천천히 늘리는 정책을 지정할 수 있습니다. 속도 제한(Rate limiting) 및 회로 차단기(circuit breaker)와 같은 기능을 통해 Service를 통해 흐르는 트래픽을 완전히 제어할 수 있습니다. rate shaping, QoS, service throttling, blue-green 배포, canary 릴리스, 회로 차단기 패턴, A/B testing 및 API Gateway 기능을 비롯한 강력한 트래픽 분산 모델을 활용할 수 있습니다.

고급 트래픽 관리로 Kubernetes의 복원력을 개선하는 방법 가이드 문서에서 자세히 알아볼 수 있습니다.

세분화된 트래픽 인사이트

NGINX Service Mesh는 OpenTracing 및 Prometheus를 사용하여 메트릭 수집 및 분석을 위해 계측됩니다. NGINX Plus API는 NGINX Service Mesh Sidecar 및 NGINX Ingress Controller 파드(Pod)에서 메트릭을 생성합니다. 내장된 Grafana 대시보드를 사용하여 millisecond, day-over-day overlays 및 트래픽 급증에 대한 세부 정보로 메트릭을 시각화합니다.

Kubernetes에서 가시성(Visibility)을 개선하는 방법에서 자세히 알아볼 수 있습니다.

안전한 컨테이너화된 앱

mTLS 암호화 및 Layer 7 보호를 개별 마이크로서비스까지 확장하고 액세스 제어를 활용하여 애플리케이션의 토폴로지를 설명하는 정책을 정의하여 서로 통신할 권한이 있는 Service를 세부적으로 제어할 수 있습니다. NGINX Service Mesh는 구성 게이팅 및 거버넌스, ingress 및 egress, service-to-service 트래픽에 대한 허용 목록 지원을 비롯한 고급 보안 기능을 지원합니다. NGINX Plus 기반 버전의 NGINX Ingress Controller를 사용하면 내부 Service에 대한 north-south 트래픽의 기본 차단과 NGINX App Protect를 통한 Edge 방화벽도 사용할 수 있습니다.

7. Service Mesh를 사용할 준비가 되지 않았습니까?

아직 Mesh를 사용할 준비가 되지 않았다면 Kubernetes를 처음 접하거나 대규모 프로덕션 배포를 방해하는 차단 장치에 부딪힐 것입니다. 지금은 복잡성, 보안, 가시성 및 확장성과 관련된 일반적인 Kubernetes 문제를 해결하기 위해 2개의 Data Plane 구성 요소(Ingress Controller 및 built-in security)를 사용하는 작업을 하기에 좋은 시기입니다. 프로덕션 등급 Kubernetes로 복잡성 감소에서 자세한 내용을 확인 할 수 있습니다.

Kubernetes 앱에 적합한 Service Mesh를 선택하는 방법

1. 시사점: Service Mesh 채택이 빠르게 증가하고 있습니다.

2. 시사점: 컨테이너 사용 증가는 더 많은 조직에서 고급 트래픽 관리 및 보안 도구를 필요로 하며 잠재적으로 Mesh의 이점을 누릴 수 있음을 나타냅니다.

3. 시사점: 컨테이너의 세 가지 주요 과제는 서로 연관되어 있습니다.