Service Mesh 채택 가이드

최근 몇 년간, Service Mesh 의 채택은 기업이 마이크로서비스와 컨테이너화된 앱에 투자를 깊이함에 따라 점진적으로 주류로 이동했습니다. Cloud Native Computing Foundation의 2020년 설문조사 결과에 따르면 클라우드 네이티브 기술의 사용에 관한 다음 결론을 도출할 수 있습니다.

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

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

시사점 #3: 컨테이너의 세 가지 주요 과업은 상호 연관되어 있습니다.

목차

1. Service Mesh를 사용할 준비가 되셨나요?
2. 애플리케이션에 적합한 Service Mesh 를 선택하는 방법
 2-1. Service Mesh 를 찾는 이유는 무엇인가요?
 2-2. Service Mesh 를 어떻게 사용 할 예정이신가요?
 2-3. 선택에 영향을 미치는 요소는 무엇인가요?
3. NGINX 가 어떻게 도움을 줄 수 있나요?
 3-1. Service Mesh 아키텍처 정보
  3-1-1. Control Plane
  3-1-2. Data Plane
 3-2. NGINX Service Mesh 이점
  3-2-1. 복잡성 감소
  3-2-2. 향상된 탄력성
  3-2-3. 세분화된 트래픽 가시성
  3-2-4. 컨테이너화 된 안전한 애플리케이션
4. Service Mesh 를 사용할 준비가 되지 않으셨나요?
5. NGINX Service Mesh 를 지금 시작해보세요.

1. Service Mesh를 사용할 준비가 되셨나요?

NGINX에서는 더 이상 “Service Mesh 를 사용해야 할까?”라는 이분법적인 질문이 아니라 “언제 Service Mesh 를 사용할 준비가 되는가?”라고 생각합니다. NGINX는 프로덕션 환경에서 컨테이너를 배포하고 Kubernetes를 사용하여 조정하는 모든 사람들이 애플리케이션과 인프라의 성숙도 수준에 도달하여 Service Mesh 가 가치를 더할 수 있는 잠재력을 가지고 있다고 믿습니다.

그러나 다른 기술과 마찬가지로, 필요하기 전에 Service Mesh를 구현하는 것은 비즈니스에 가능한 이점보다 위험과 비용을 더하는 결과를 초래할 수 있습니다. NGINX는 Service Mesh 도입에 관심이 있는 고객들과 함께 이 6가지 체크리스트를 사용하여 준비 여부를 판단하고 현대화 여정에 대한 이해를 얻습니다. 여러분에게 해당되는 문항이 많을수록 서비스 메시가 가치를 더할 수 있습니다.

#1: 프로덕션 환경에서 Kubernetes에 완전히 투자하고 있습니다.

이미 프로덕션 앱을 Kubernetes로 이전했거나 컨테이너 워크로드로의 앱 이전을 테스트하기 시작했을 수도 있습니다. 장기적인 애플리케이션 관리 로드맵에는 Kubernetes가 포함되어 있습니다.

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

이미 프로덕션 앱에서 제로 트러스트 모델을 사용하고 컨테이너화된 환경에서도 해당 수준의 보안을 유지해야 하는 경우이거나, 이러한 마이그레이션을 통해 서비스 수준 보안을 강화하려는 경우입니다.

#3: 앱이 서비스의 수와 깊이 측면에서 복잡합니다.

분산된 큰 규모의 앱이 있습니다. 다수의 API 종속성이 있으며, 아마도 외부 종속성이 필요합니다.

#4: 높은 수준의 프로덕션 CI/CD 파이프라인을 갖고 있습니다.

“높은 수준”은 조직에 따라 다릅니다. NGINX는 Kubernetes 인프라와 앱을 프로그래밍 방식으로 배포하는 절차를 가리키며, Git, Jenkins, Artifactory, Selenium 등의 도구를 사용할 가능성이 높습니다.

#5: 프로덕션에 자주 배포하고 있으며, 하루에 적어도 한 번 이상 배포합니다.

대부분의 사람들이 “아니오”라고 대답하는 부분입니다. 이미 앱을 프로덕션 Kubernetes로 이전했지만, 지속적인 개정을 위해 Kubernetes를 아직 사용하지 않고 있습니다.

#6: DevOps 팀이 준비되어 있으며, 최신 앱 배포를 위한 적절한 도구를 사용하려고 합니다!

Service Mesh는 NetOps 팀이 소유할 수 있지만, 관리는 대개 DevOps팀이 클러스터 내에서 처리하며, 스택에 메시(Mesh)를 추가하기 위해 준비되어 있어야 합니다.

위의 여섯 가지 문항에 모두 “예”라고 대답하지 않았나요? 괜찮습니다! 준비가 되면 여정이 어떻게 진행될지에 대한 아이디어를 얻기 위해 계속 읽어보세요. 또한, 팀을 Service Mesh 에 대비할 수 있도록 준비하는 데 도움이 되는 내용도 확인할 수 있습니다.

2. 애플리케이션에 적합한 Service Mesh 를 선택하는 방법

Service Mesh 에 준비가 되었다고 결정한 후에도 선택할 수 있는 다양한 옵션이 있습니다. Kubernetes가 사실상의 컨테이너 오케스트레이션 표준이 되었듯이, Istio는 사실상의 Service Mesh 표준으로 간주됩니다. 실제로 Istio는 Kubernetes 네트워킹 세계의 거의 모든 문제를 해결하려는 목표 때문에 Istio가 유일한 선택인 것처럼 생각하기 쉽습니다. 그러나 Istio는 유일한 선택이 아니며, 모든 사람이나 모든 사용 사례에 적합한 선택도 아닙니다. Istio는 환경에 많은 복잡성을 추가할 수 있으며, 운영을 위해 전체 팀의 엔지니어가 필요할 수 있으며, 종종 해결하려는 문제보다 더 많은 문제를 야기할 수 있습니다.

앱에 가장 적합한 Service Mesh를 결정하기 위해, 팀과 이해 관계자들과의 전략적인 기획 세션을 권장합니다. 다음은 이러한 토론을 원활하게 진행하기 위한 대화 가이드입니다.

2-1. Service Mesh 를 찾는 이유는 무엇인가요?

다시 말해, Service Mesh가 해결해야 할 문제는 무엇인가요? 예를 들어, 조직에서는 서비스 간의 mTLS를 요구하거나 End-to-End 암호화가 필요할 수 있습니다. 이는 Ingress 트래픽을 위한 외부에서부터의 암호화와 mesh 내부에서의 Egress 트래픽을 포함합니다. 또는 새로운 Kubernetes 서비스에 대해 기업 수준의 트래픽 관리 도구가 필요할 수도 있습니다.

2-2. Service Mesh 를 어떻게 사용 할 예정이신가요?

이는 여러분이 누구냐에 따라 다릅니다.

• 개발자인 경우:
  • Kubernetes로 이동하는 레거시 앱에 보안을 추가할 계획이 있나요?
  • 네이티브 Kubernetes 앱으로 앱을 리팩토링하는 과정에서 보안을 통합할 계획이 있나요?

• 플랫폼과 인프라를 책임지는 경우:
  • CI/CD 파이프라인에 Service Mesh를 추가하여 매번 새로운 클러스터가 배포되고 구성될 때 자동으로 배포되고 구성되며, 개발자가 새로운 인스턴스를 생성할 때 사용할 수 있도록 할 계획이 있나요?

2-3. 선택에 영향을 미치는 요소는 무엇인가요?

Service Mesh가 인프라에 중립적이어야 하나요? 가시성 도구와 호환되어야 하나요? Kubernetes 네이티브인가요? 사용하기 쉬운가요? Egress와 Ingress(Ingress-Egress) 트래픽을 메시 내부의 서비스 간(East-West) 트래픽과 동일한 도구로 관리하고자 하는 미래를 보고 있나요?

이러한 질문들을 통해 요구 사항 목록을 작성할 수 있으며, 이를 기반으로 옵션을 평가할 수 있게 될 것입니다.

3. NGINX 가 어떻게 도움을 줄 수 있나요?

2020년 개발 버전으로 소개된 NGINX Service Mesh가 공식적으로 프로덕션에 준비되었음을 자랑스럽게 알려드립니다! NGINX Service Mesh는 개발자를 위해 최적화된 무료 Service Mesh로, Kubernetes 환경에서 East-West(서비스 간) 트래픽과 North-South(Egress 및 Ingress) 트래픽 모두에 대한 mTLS와 End-to-End 암호화를 구현하기 가장 가벼우며 쉬운 방법입니다. 우리는 고객들에게 고도의 유연성과 중요한 통찰력을 제공하면서도 가장 침입적이지 않은 방식으로 애플리케이션 데이터 플레인(Data Plane)을 완전히 제어할 수 있도록 자체적으로 Service Mesh를 구축했습니다.

NGINX Service Mesh는 다음과 같은 메시가 필요한 경우에 매우 유용할 것으로 생각합니다:

• 사용하기 쉬움: Service Mesh를 관리하고 이미 복잡한 Kubernetes 환경에 mTLS와 고급 트래픽 관리를 추가하기 위해 복잡한 도구 세트를 다루고 싶지 않은 경우입니다.
• 가벼움: 리소스를 소모하지 않고 성능에 영향을 주지 않는 구성 요소를 원합니다.
• 인프라에 중립적임: 모든 Kubernetes 환경에서 동일한 Service Mesh를 사용할 계획입니다.
• 생태계와 호환됨: 지연 시간을 추가하지 않고 Ingress Controller와 가시성 도구와 통합되는 Kubernetes 네이티브 서비스 메시가 필요합니다.

3-1. Service Mesh 아키텍처 정보

NGINX Service Mesh에는 두 가지 주요 아키텍처가 있습니다.

3-1-1. Control Plane

우리는 Kubernetes API 서버와의 협력을 통해 앱의 동적인 지원과 관리를 제공하는 가벼운 Control Plane을 구축했습니다. 이는 앱이 확장되고 배포됨에 따라 앱에 대응하고 업데이트하여 각 워크로드 인스턴스가 자동으로 보호되고 다른 앱 구성 요소와 통합되도록 합니다. 이를 통해 “설정하고 잊어버리고” 가치 있는 비즈니스 솔루션에 시간을 투자할 수 있습니다.

3-1-2. Data Plane

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

3-2. NGINX Service Mesh 이점

NGINX Service Mesh로부터 여러 가지 이점을 기대할 수 있습니다.

3-2-1. 복잡성 감소

NGINX Service Mesh 는 사용하기 쉽고 인프라에 중립적입니다. 이는 Kubernetes에서 Service Mesh에 대한 표준 인터페이스를 정의하는 Service Mesh Interface (SMI) 사양을 구현하며, SMI 확장을 제공하여 새로운 앱 버전을 배포할 때 최소한의 노력과 프로덕션 트래픽 중단으로 가능하게 합니다. NGINX Service Mesh는 NGINX Ingress Controller와 원활하게 통합되어 Ingress와 Egress(North-South) 트래픽 관리의 구성을 중앙 집중화하고 간소화할 수 있는 통합 데이터 플레인을 생성합니다. 이를 통해 Edge에서 Ingress와 Egress(North-South) 트래픽 관리를 서비스 간(East-West) 리버스 프록시 Sidecar 트래픽 관리와 함께 통합할 수 있습니다. 또한, 다른 메시와 달리 NGINX Service Mesh 는 NGINX Ingress Controller에 사이드카를 주입할 필요가 없으므로 Kubernetes 환경에 지연 시간과 복잡성을 추가하지 않습니다.

3-2-2. 향상된 탄력성

NGINX의 컨테이너 트래픽의 지능적인 관리를 통해, 새로 배포된 서비스 인스턴스로의 트래픽을 제한하고 시간이 지남에 따라 서서히 증가시킬 수 있는 정책을 지정할 수 있습니다. Rate Limit 및 Circuit Breaker와 같은 기능을 통해 서비스를 통해 흐르는 트래픽을 완전히 제어할 수 있습니다. 속도 조절, 서비스 품질(QoS), 서비스 제한, Blue-Green 배포, 카나리아 릴리스, 서킷 브레이커 패턴, A/B 테스트 및 API Gateway 기능을 포함한 다양한 트래픽 분배 모델을 활용할 수 있습니다.

3-2-3. 세분화된 트래픽 가시성

NGINX Service Mesh는 OpenTracing과 Prometheus를 사용하여 메트릭 수집 및 분석을 위해 계측화되어 있습니다. NGINX Service Mesh Sidecar와 NGINX Ingress Controller Pod에서 NGINX Plus API가 메트릭을 생성합니다. 내장된 Grafana 대시보드를 사용하여 밀리초 단위의 자세한 메트릭, 일일 오버레이 및 트래픽 스파이크를 시각화할 수 있습니다.

3-2-4. 컨테이너화 된 안전한 애플리케이션

개별 마이크로서비스까지 mTLS 암호화와 Layer 7 보호를 확장하고, 액세스 제어를 활용하여 애플리케이션의 토폴로지를 설명하는 정책을 정의함으로써 서비스 간 통신이 허용되는지에 대한 세밀한 제어를 제공합니다. NGINX Service Mesh는 구성 Gate 및 Governance를 포함한 고급 보안 기능을 제공하며, Ingress 및 Egress 및 서비스 간 트래픽에 대한 화이트리스트 지원을 가능하게 합니다. NGINX Ingress Controller의 NGINX Plus 기반 버전을 사용하면 내부 서비스로의 North-South 트래픽 차단 및 NGINX App Protect를 통한 Edge 방화벽 기능도 제공됩니다.

4. Service Mesh 를 사용할 준비가 되지 않으셨나요?

Service Mesh에 준비가 되지 않았다면, 아마도 Kubernetes에 새로운 사용자이거나 대규모 프로덕션 배포를 방해하는 문제가 있을 것입니다. 이는 복잡성, 보안, 가시성 및 확장성과 관련된 일반적인 Kubernetes 도전 과제를 해결하기 위해 Ingress Controller와 내장된 보안과 같은 두 개의 데이터 플레인 구성 요소를 사용하는 것에 대해 작업할 수 있는 좋은 시기입니다. “프로덕션 등급 Kubernetes로 복잡성 감소” 에서 자세한 내용을 읽어보세요.

5. NGINX Service Mesh 를 지금 시작해보세요.

NGINX Service Mesh는 완전히 무료이며 즉시 다운로드하여 10분 이내에 배포할 수 있습니다! 시작하려면 문서를 확인하고 NGINX STORE에 문의해주세요.

아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.