서비스 메시는 애플리케이션의 서비스 간 모든 통신을 처리하는 소프트웨어 계층

컨테이너화된 마이크로서비스로 구성

애플리케이션이 확장되고 마이크로서비스의 수가 증가함에 따라 서비스의 성능을 모니터링하기가 점점 어려워지고 있음. 

서비스 메시는 서비스간 연결을 관리하기 위해 모니터링, 로깅, 추적, 트래픽 제어와 같은 새로운 기능을 제공

각 서비스의 코드와 독립적이므로 네트워크 경계를 넘어 여러 서비스 관리 시스템에서 작동

서비스 메시는 왜 필요한가요?

현대적 애플리케이션 아키텍처에서는 독립적으로 배포 가능한 소규모 마이크로서비스 모음으로 애플리케이션을 구축할 수 있습니다. 팀별로 개별 마이크로서비스를 구축하고 코딩 언어 및 도구를 선택할 수 있습니다. 하지만 애플리케이션 코드가 제대로 작동하려면 마이크로서비스가 통신해야 합니다.

애플리케이션 성능은 서비스 간 통신의 속도와 탄력성에 따라 좌우됩니다. 개발자는 서비스 전반에서 애플리케이션을 모니터링하고 최적화해야 하지만, 시스템의 분산된 특성 때문에 가시성을 확보하기가 어렵습니다. 애플리케이션이 확장됨에 따라 통신을 관리하기가 훨씬 더 복잡해집니다.

서비스 메시 도입에는 두 가지 주요 동인이 있으며, 이에 대해서는 다음에 자세히 설명하겠습니다.

마이크로서비스에 대해 읽어보기 »

서비스 수준 관찰성

더 많은 워크로드와 서비스가 배포됨에 따라 개발자들은 모든 요소가 연동하여 작동하는 방식을 이해하는 데 어려움을 겪습니다. 예를 들어 서비스 팀은 다운스트림 및 업스트림 종속성에 대해서 알고 싶어합니다. 애플리케이션 계층에서 서비스와 워크로드가 통신하는 방식에 대한 가시성을 높이길 원합니다.

서비스 수준 제어

관리자는 어떤 서비스가 서로 통신하고 어떤 작업을 수행하는지를 제어하고자 합니다. 관리자는 마이크로서비스 아키텍처 내에서 서비스의 동작, 정책 및 상호 작용에 대한 세밀한 제어 및 거버넌스 기능을 원합니다. 보안 정책 적용은 규제를 준수하는 데 필수적입니다.

서비스 메시를 사용하면 어떤 이점이 있나요?

서비스 메시는 분산 애플리케이션 내에서 복잡한 서비스 간 통신을 처리하는 중앙 집중식 전용 인프라 계층을 제공합니다. 다음으로 AWS는 서비스 메시와 관련하여 몇 가지 이점을 제공합니다.

서비스 검색

서비스 메시는 자동화된 서비스 검색을 제공하여 서비스 엔드포인트 관리의 운영 부하를 줄입니다. 서비스 레지스트리를 사용하여 메시 내의 모든 서비스를 동적으로 검색하고 추적합니다. 서비스는 위치나 기반 인프라에 관계없이 서로를 원활하게 찾고 통신할 수 있습니다. 필요에 따라 새 서비스를 배포하여 빠르게 확장할 수 있습니다.

로드 밸런싱

서비스 메시는 라운드 로빈, 최소 연결 또는 가중치 로드 밸런싱과 같은 다양한 알고리즘을 사용하여 요청을 여러 서비스 인스턴스에 지능적으로 분산합니다. 로드 밸런싱은 리소스 활용도를 높이고 고가용성 및 확장성을 보장합니다. 성능을 최적화하고 네트워크 통신 병목 현상을 방지할 수 있습니다.

트래픽 관리

서비스 메시는 요청 라우팅 및 트래픽 동작을 세밀하게 제어할 수 있는 고급 트래픽 관리 기능을 제공합니다. 여기 몇 가지 예가 있습니다.

트래픽 분할

들어오는 트래픽을 서로 다른 서비스 버전 또는 구성 간에 분할할 수 있습니다. 메시는 일부 트래픽을 업데이트된 버전에 전달하므로 변경 사항을 제어하고 점진적으로 적용할 수 있습니다. 이를 통해 원활한 전환이 가능하며, 변경으로 인한 영향을 최소화할 수 있습니다.

미러링 요청

기본 요청 흐름에 영향을 주지 않으면서 분석을 위해 테스트 또는 모니터링 서비스에 트래픽을 복제할 수 있습니다. 요청을 미러링하면 서비스가 프로덕션 트래픽에 영향을 미치지 않으면서 특정 요청을 처리하는 방법을 파악할 수 있습니다.

카나리 배포

대부분의 사용자가 기존의 안정적인 버전을 계속 사용하면서 일부 사용자 또는 트래픽을 새 서비스 버전에 전달할 수 있습니다. 노출이 제한되므로 실제 환경에서 새 버전의 동작과 성능을 실험해 볼 수 있습니다.

보안

서비스 메시는 상호 TLS(mTLS) 암호화, 인증 및 권한 부여와 같은 보안 통신 기능을 제공합니다. 상호 TLS를 사용하면 서비스 간 통신에서 ID를 검증할 수 있습니다. 트래픽을 암호화하여 데이터 기밀성과 무결성을 보장하는 데 도움이 됩니다. 또한 권한 부여 정책을 적용하여 특정 엔드포인트에 액세스하거나 특정 작업을 수행하는 서비스를 제어할 수 있습니다.

모니터링

서비스 메시는 포괄적인 모니터링 및 관찰성 기능을 제공하여 서비스의 상태, 성능 및 행동에 대한 인사이트를 도출할 수 있습니다. 모니터링은 문제 해결 및 성능 최적화도 지원합니다. 사용할 수 있는 모니터링 기능의 예는 다음과 같습니다.

• 지연 시간, 오류율, 리소스 사용률과 같은 지표를 수집하여 전체 시스템 성능을 분석합니다.

• 분산 추적을 수행하여 여러 서비스 전반에서 요청의 전체 경로와 시간을 확인할 수 있습니다.

• 감사, 디버깅 및 규정 준수를 위해 로그에 서비스 이벤트를 캡처합니다.

서비스 메시는 어떻게 작동하나요?

서비스 메시는 개별 서비스에서 서비스 간 통신을 제어하는 로직을 없애고 통신을 자체 인프라 계층으로 추상화합니다. 여러 네트워크 프록시를 사용하여 서비스 간 통신을 라우팅하고 추적합니다.

프록시는 조직의 네트워크와 마이크로서비스 간의 중간 게이트웨이 역할을 합니다. 서비스로 들어오고 나가는 모든 트래픽은 프록시 서버를 통해 라우팅됩니다. 개별 프록시는 개별적으로 실행되지만 논리적으로 각 서비스의 옆에 있기 때문에 사이드카라고도 합니다. 이들 프록시가 함께 서비스 메시 계층을 구성합니다. 

서비스 메시 아키텍처에는 컨트롤 플레인과 데이터 영역이라는 두 가지 주요 구성 요소가 있습니다.

데이터 영역

데이터 영역은 서비스 메시의 데이터 처리 구성 요소입니다. 여기에는 모든 사이드카 프록시와 해당 기능이 포함됩니다. 서비스가 다른 서비스와 통신하려는 경우 사이드카 프록시는 다음과 같은 작업을 수행합니다.

1. 사이드카가 요청을 가로챕니다.

2. 요청을 별도의 네트워크 연결로 캡슐화합니다.

3. 소스 프록시와 대상 프록시 간에 안전하고 암호화된 채널을 설정합니다.

사이드카 프록시는 서비스 간의 로우레벨 메시징을 처리합니다. 또한 회로 차단 및 요청 재시도와 같은 기능을 구현하여 복원력을 높이고 서비스 기능 저하를 방지합니다. 로드 밸런싱, 서비스 검색, 트래픽 라우팅과 같은 서비스 메시 기능이 데이터 영역에 구현됩니다.

제어 영역

컨트롤 플레인은 서비스 메시의 중앙 관리 및 구성 계층 역할을 합니다.

관리자는 컨트롤 플레인을 사용하여 메시 내에서 서비스를 정의하고 구성할 수 있습니다. 예를 들어 서비스 엔드포인트, 라우팅 규칙, 부하 분산 정책 및 보안 설정과 같은 파라미터를 지정할 수 있습니다. 구성이 정의되면 컨트롤 플레인은 서비스 메시의 데이터 영역에 필요한 정보를 배포합니다.

프록시는 구성 정보를 사용하여 들어오는 요청을 처리하는 방법을 결정합니다. 또한 구성 변경 사항을 수신하고 동작을 동적으로 조정할 수 있습니다. 서비스를 다시 시작하거나 중단하지 않고 서비스 메시 구성을 실시간으로 변경할 수 있습니다.

서비스 메시 구현에는 일반적으로 컨트롤 플레인에 다음 기능이 포함됩니다.

• 메시 내의 모든 서비스를 추적하는 서비스 레지스트리

• 신규 서비스 자동 검색 기능 및 비활성 서비스 제거 기능

• 지표, 로그, 분산 추적 정보와 같은 텔레메트리 데이터의 수집 및 집계

Istio는 무엇인가요?

Istio는 주로 Kubernetes와 함께 작동하도록 설계된 오픈 소스 서비스 메시 프로젝트입니다. Kubernetes는 대규모 컨테이너식 애플리케이션을 배포하고 관리하는 데 사용되는 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다.

Istio의 컨트롤 플레인 구성 요소는 자체적으로 Kubernetes 워크로드로 실행됩니다. 하나의 IP 주소를 공유하는 밀결합된 컨테이너 세트인 Kubernetes 포드를 사이드카 프록시 설계의 기반으로 사용합니다.

Istio의 계층 7 프록시는 기본 서비스와 동일한 네트워크 컨텍스트에서 또 다른 컨테이너로 실행됩니다. 이 위치에서 포드를 통과하는 모든 네트워크 트래픽을 가로채고, 검사하고, 조작할 수 있습니다. 하지만 기본 컨테이너를 변경할 필요도 없고 이런 작업이 이루어진다는 사실조차 알 필요가 없습니다.

Kubernetes에 대해 읽어보기 »

오픈 소스 서비스 메시 구현의 문제점은 무엇인가요?

다음은 Istio, Linkerd 및 Consul과 같은 오픈 소스 플랫폼과 관련한 몇 가지 일반적인 서비스 메시 문제입니다.

복잡성

서비스 메시에는 추가 인프라 구성 요소, 구성 요구 사항 및 배포 고려 사항이 수반됩니다. 학습 곡선이 가파르기 때문에 개발자와 운영자가 특정 서비스 메시 구현을 사용하는 데 필요한 전문 지식을 습득해야 합니다. 팀을 교육하려면 시간과 리소스가 소요됩니다. 조직은 팀이 서비스 메시 아키텍처의 복잡성을 이해하고 이를 효과적으로 구성하는 데 필요한 지식을 갖추도록 해야 합니다.

운영 오버헤드

서비스 메시는 데이터 영역 프록시와 컨트롤 플레인 구성 요소를 배포, 관리 및 모니터링하기 위한 추가 오버헤드를 유발합니다. 예를 들어 다음을 수행해야 합니다.

• 서비스 메시 인프라의 높은 가용성 및 확장성 보장

• 프록시의 상태 및 성능 모니터링

• 업그레이드 및 호환성 문제 해결

전체 시스템의 성능에 미치는 영향을 최소화하려면 서비스 메시를 신중하게 설계하고 구성하는 것이 중요합니다.

통합 문제

서비스 메시에서 필요한 기능을 수행하려면 서비스 메시가 기존 인프라와 원활하게 통합되어야 합니다. 여기에는 컨테이너 오케스트레이션 플랫폼, 네트워킹 솔루션 및 기술 스택의 기타 도구가 포함됩니다.

복잡하고 다양한 환경에서 다른 구성 요소와의 호환성 및 원활한 통합을 보장하는 것은 어려울 수 있습니다. API, 구성 형식 및 종속성을 변경하려면 지속적인 계획과 테스트가 필요합니다. 스택의 어느 위치에서든 새 버전으로 업그레이드해야 하는 경우에도 마찬가지입니다.