서비스 메시와 기존 API Gateway는 분산 시스템 내에서 네트워크 트래픽을 관리하는 데 있어 고유한 역할을 합니다. 서비스 메시는 마이크로서비스 간의 내부 통신에 중점을 두어 애플리케이션 코드를 변경하지 않고도 트래픽 관리, 부하 분산, 옵저버빌리티를 세밀하게 제어할 수 있습니다. 반면, API Gateway는 외부 클라이언트를 위한 중앙 엔트리 포인트 역할을 하며, 클라이언트용 API의 인증, 권한 확인, 요청 라우팅 등의 작업을 처리합니다.
서비스 메시는 분산 시스템 내의 마이크로서비스에 네트워크 연결, 보안, 옵저버빌리티를 제공하는 전용 인프라 레이어입니다. 부하 분산, 회로 차단, 트래픽 이동, 재시도 메커니즘과 같은 서비스 간 통신 복잡성을 추상화하는 방식으로 작동합니다.
서비스 메시를 정의하려면 먼저 마이크로서비스를 정의해야 합니다. 마이크로서비스의 작동 방식을 모르는 경우 서비스 메시를 설명하는 것은 마치 비행기에 대해 모르는 사람이 일등석과 일반석을 비교하는 것과 같습니다. 서비스 메시는 마이크로서비스 기반 애플리케이션의 실행을 더 원활하게 만들기 위해 개발된 기술이지만, 오히려 복잡성을 높인다고 주장하는 사람들도 있습니다.
마이크로서비스 이해하기
마이크로서비스는 애플리케이션을 느슨하게 결합된 작은 구성요소, 즉 '서비스'로 분할하는 소프트웨어 애플리케이션 아키텍처에 대한 최신 접근 방식입니다. 이 마이크로서비스들이 모여 전체 애플리케이션의 기능을 제공합니다. 이 접근 방식은 모든 기능을 하나의 소프트웨어에 통합하는 기존의 '모놀리식' 애플리케이션 아키텍처와 대조적입니다.
Netflix는 마이크로서비스의 대표적인 사례로 잘 알려져 있습니다. 10년 전, Netflix는 하나로 통합된 거대한 소프트웨어 애플리케이션이었습니다. Netflix의 모든 기능은 하나의 거대한 코드베이스 안에 존재했습니다. 문제는 애플리케이션의 한 부분을 수정하려면 전체를 다시 배포해야 했다는 점으로, 바쁘고 상업적으로 중요한 소프트웨어에는 바람직하지 않은 상황이었습니다.
마이크로서비스 아키텍처로 전환한 후 콘텐츠 관리부터 계정 관리, 플레이어 등에 이르기까지 Netflix의 각 영역은 각각 독립적인 마이크로서비스로 존재합니다. 사실, 좀 더 세밀하게 보면, 이 각 영역 자체도 여러 개의 마이크로서비스로 구성되어 있습니다. 개발자는 각 마이크로서비스에서 독립적으로 작업할 수 있습니다. 다른 마이크로서비스에 미치는 영향을 걱정하지 않고 변경, 확장 또는 재구성할 수 있습니다. 이론적으로, 하나의 마이크로서비스가 실패하더라도 나머지 애플리케이션 전체가 함께 다운되지는 않습니다(단, 예외적인 경우는 있을 수 있음).
서비스 메시란 무엇일까요?
마이크로서비스 아키텍처의 개념을 염두에 두고, 마이크로서비스 기반 애플리케이션을 안정적으로 운영하려 할 때 발생할 수 있는 몇 가지 도전 과제를 생각해 보세요. 애플리케이션을 독립적인 서비스로 분리할 수 있다는 점에서 혁신적인 아키텍처이지만, 그와 함께 여러 어려움이 따릅니다.
특히 마이크로서비스 간의 통신은 마이크로서비스가 다른 마이크로서비스의 위치를 파악하고, 어떻게 통신해야 하는지, 관리자에게 앱 내부에서 무슨 일이 일어나고 있는지 알릴 수 있는 메커니즘이 없다면 문제가 될 수 있습니다. 예를 들어, Netflix의 스트리밍 마이크로서비스는 가입자의 계정 정보를 어디에서 찾아야 하는지 어떻게 알 수 있을까요? 바로 이 지점에서 서비스 메시가 등장합니다. 그러나 서비스 메시를 선호하지 않는 사람들을 고려하면, 이를 위해 반드시 서비스 메시가 꼭 필요한 것은 아니라는 점을 짚고 넘어가는 것이 중요합니다.
서비스 메시는 네트워크를 통해 마이크로서비스 간의 통신을 관리하는 인프라 레이어입니다. 앱 내부의 서비스 요청을 제어합니다. 서비스 메시는 일반적으로 암호화와 같은 보안 기능과 함께 서비스 검색, 장애 복구, 부하 분산을 제공합니다.
서비스 메시는 어떻게 작동하나요?
서비스 메시의 역할은 마이크로서비스 기반 시스템에 보안, 옵저버빌리티, 안정성을 더하는 것입니다. 이를 위해 각 마이크로서비스에 연결되는 ‘사이드카’ 프록시를 사용하며, eBPF 기반의 ‘비사이드카’ 서비스 메시도 존재합니다. 사이드카는 OSI 스택의 레이어 7에서 작동합니다. 애플리케이션이 컨테이너 기반인 경우 사이드카는 각 컨테이너 또는 가상 머신(VM)에 연결됩니다. 그런 다음 프록시는 ‘데이터 영역’과 ‘제어 영역’에서 작동합니다.
데이터 영역은 사이드카 프록시 옆에서 실행되는 서비스로 구성됩니다. 각 서비스/사이드카 쌍에서, 서비스는 애플리케이션의 비즈니스 로직을 처리하고, 프록시는 해당 서비스와 시스템 내 다른 서비스들 사이에서 중간 역할을 합니다. 사이드카 프록시는 서비스로 들어오고 나가는 모든 트래픽을 처리합니다. 또한 상호 전송 계층 보안(mTLS)과 같은 연결 기능을 제공하여, 요청/응답 메시지 흐름에서 각 서비스가 서로의 인증서를 검증할 수 있게 합니다.
제어 영역은 관리자가 서비스 메시와 상호 작용하는 영역입니다. 프록시 설정 및 제어를 담당하고, 서비스 메시의 관리를 처리하며, 프록시를 설정하고 조정하는 방법을 제공합니다. 관리자는 제어 영역을 통해 접속 제어 정책을 적용하고 마이크로서비스 간에 전송되는 메시지에 대한 라우팅 룰을 정의합니다. 제어 영역은 마이크로서비스 옵저버빌리티와 관련된 로그 및 기타 데이터를 내보낼 수도 있습니다.
서비스 메시의 데이터 영역과 제어 영역을 함께 사용하면 다음과 같은 이점을 얻을 수 있습니다.
보안 - 인증 및 권한 확인과 같은 보안 정책을 마이크로서비스에 배포하고, 마이크로서비스 간의 통신을 자동으로 암호화합니다. 서비스 메시는 제어 영역을 통해 보안 정책을 관리, 모니터링, 적용할 수 있습니다.
안정성 - 제어 영역에서 사이드카 프록시를 통해 마이크로서비스 간의 통신을 관리하고, 프로세스 내 서비스 요청의 안정성을 개선합니다. 또한 서비스 메시는 안정성을 강화하고 고가용성(HA)을 제공하기 위해 장애 관리와 부하 분산을 처리할 수 있습니다.
옵저버빌리티 - 시스템 소유자에게 마이크로서비스가 어떻게 작동하고 있는지 보여줍니다. 서비스 메시는 ‘과부하 상태’이거나 장애 리스크가 있는 마이크로서비스를 식별할 수 있습니다. 서비스 메시의 제어 영역은 마이크로서비스와 기타 애플리케이션 구성요소 간의 상호 작용에 관한 텔레메트리 데이터를 수집합니다.
쿠버네티스와 서비스 메시 통합 작업
널리 채택된 컨테이너 오케스트레이션 플랫폼인 쿠버네티스는 마이크로서비스 관리에 중요한 역할을 합니다. 서비스 메시를 쿠버네티스와 통합하면 쿠버네티스 생태계에서 실행되는 마이크로서비스의 제어, 보안, 옵저버빌리티가 향상됩니다. 쿠버네티스는 Istio 및 Linkerd와 같은 서비스 메시와 결합되어 자동 서비스 검색, 부하 분산, 장애 복구를 지원합니다. 쿠버네티스와 서비스 메시의 오픈 소스 특성으로 인해 기업은 광범위한 커뮤니티와 클라우드 네이티브 애플리케이션을 지원하기 위해 지속적으로 발전하는 풍부한 툴 세트를 활용할 수 있습니다. 기업은 컨테이너 관리의 토대로 쿠버네티스를 사용하고 이를 서비스 메시와 결합함으로써 서비스 간 통신에 대한 가시성을 높이고, 서비스 상호 작용의 지연 시간을 줄이고, 전반적인 시스템 안정성을 개선할 수 있습니다.
서비스 메시 vs 마이크로서비스
마이크로서비스와 서비스 메시는 혼동하기 쉽습니다. 마이크로서비스는 마이크로서비스 기반 시스템을 구성하는 개별 구성요소입니다. 서비스 메시는 이러한 구성요소들을 연결할 수 있습니다. 이름에서 알 수 있듯이, 서비스 메시는 마이크로서비스 위에 연결 패브릭처럼 놓여 있습니다. 다시 말해, 서비스 메시는 마이크로서비스 기반 애플리케이션을 구동하는 상호 연결과 관련 로직을 관리하기 위해 구현할 수 있는 ‘패턴’입니다.
서비스 메시가 필요한 이유는 무엇일까요?
모놀리식 애플리케이션은 규모가 커지고 복잡해질수록 성능과 관리가 어려워집니다. 이럴 때 애플리케이션을 마이크로서비스 단위로 나누는 것이 합리적입니다. 이러한 접근 방식은 애자일, DevOps, CI/CD(지속적인 통합 및 배포)와 같은 최신 애플리케이션 개발 방법론과 잘 맞습니다. 테스트 및 운영 분야의 소프트웨어 개발 팀과 파트너는 개별적인 독립 마이크로서비스를 위한 새로운 코드에 집중할 수 있습니다. 이는 일반적으로 소프트웨어와 전체 비즈니스 측면에서 가장 효율적인 방법입니다.
그러나 마이크로서비스 애플리케이션의 서비스 수가 늘어나면 모든 연결을 관리하는 것이 점점 어려워질 수 있습니다. 이해관계자들은 각 서비스가 다른 서비스와 어떻게 연결되고 상호작용해야 하는지 파악하는 데 어려움을 겪을 수 있습니다. 서비스 상태 모니터링이 어려워지고 있습니다. 수십 또는 수백 개의 마이크로서비스가 연결되고 감독되기 때문에 안정성도 문제가 될 수 있습니다.
서비스 메시는 개발자가 인프라의 전용 레이어에서 서비스 간 통신을 처리할 수 있도록 함으로써 이러한 문제를 해결합니다. 개발자는 수백 개의 연결을 한 번에 하나씩 처리하는 대신 제어 영역의 프록시를 통해 전체 애플리케이션을 관리할 수 있습니다. 서비스 메시는 효율적인 관리 및 모니터링 기능을 제공합니다.
한 마디로, 서비스 메시의 핵심 장점은 다음과 같습니다.
마이크로서비스 간 통신 간소화
통신 오류를 보다 쉽게 탐지하고 이해할 수 있도록 지원
암호화, 인증, 권한 확인으로 앱 보안 강화
새로운 마이크로서비스의 더 빠른 개발, 테스트, 배포를 통해 앱 개발 가속
서비스 메시 도전 과제
그러나 서비스 메시는 그 자체로 어려움을 초래할 수 있습니다. 예를 들어, 서비스 메시의 레이어는 인프라, 유지 관리, 지원 등이 필요한 시스템의 또 다른 요소가 됩니다. 이는 리소스 고갈로 이어질 수 있으며, 전체 네트워크와 하드웨어 성능에 영향을 미칠 수 있습니다. 사이드카 프록시를 추가하면 이미 복잡한 환경이 더 복잡해질 수 있습니다. 사이드카를 통해 서비스 호출을 실행하면 단계가 추가되어 애플리케이션 속도가 느려질 수 있습니다. 여러 마이크로서비스 아키텍처 간 통합 작업과 관련된 문제가 있을 수 있습니다. 서비스 메시의 관리와 서비스 간 메시지에도 불구하고, 네트워크는 여전히 관리가 필요합니다.
자동화를 통해 서비스 메시의 지연 시간 단축
서비스 메시의 주요 문제 중 하나는 서비스 통신을 처리하는 프록시 레이어가 추가되어 지연 시간이 증가할 수 있다는 것입니다. 그러나 Istio 및 Linkerd와 같은 서비스 메시에는 이러한 지연 시간 문제를 완화하는 자동화 기능이 탑재되어 있습니다. 서비스 메시는 지능형 트래픽 관리와 자동화된 재시도를 통해 통신 경로를 간소화하고 지연을 최소화할 수 있습니다. 또한, Istio는 Envoy를 사용해 라우팅 결정을 최적화함으로써 자동화를 활용해 잠재적인 네트워크 병목 현상을 우회함으로써 서비스 간 응답 속도를 높입니다. 이를 통해 지연 시간이 중대한 문제가 될 수 있는 대규모 클라우드 네이티브 환경에서도 애플리케이션이 고성능을 유지할 수 있습니다. 오픈 소스 커뮤니티의 지속적인 업데이트와 최적화를 통해, 최신 서비스 메시는 최소한의 오버헤드로 최신 트래픽 관리 기능의 균형을 맞출 수 있게 되었습니다.
결론
서비스 메시는 마이크로서비스로 성공을 달성하는 데 도움이 될 수 있습니다. 이 기술은 서비스와 관련 관리 기능 간의 통신을 처리하는 데 필요한 인프라 레이어를 제공합니다. 올바른 방식으로 구축된 서비스 메시는 마이크로서비스 기반 애플리케이션과 시스템에 보안, 안정성, 옵저버빌리티를 제공합니다.
FAQ
서비스 메시 아키텍처는 보안 통신과 데이터 보호를 보장하는 다양한 기능을 제공함으로써 마이크로서비스 내 보안을 강화합니다. 주요 보안 기능 중 하나는 서비스 간 암호화된 통신을 지원하는 상호 TLS(mTLS)입니다. 또한 서비스 메시는 세분화된 접속 제어 정책을 지원하므로 관리자는 서비스 수준에서 접속 권한을 정의하고 적용할 수 있습니다.
서비스 메시를 구축하는 것은 처음에는 복잡해 보일 수 있지만, 장기적인 이점이 초기 복잡성보다 더 큽니다.
요구사항과 인프라에 맞는 서비스 메시 솔루션을 선택하세요. 각 서비스 메시에는 고유한 기능과 통합 작업이 있으므로 구체적인 요구사항에 따라 평가하세요. 서비스 메시를 비프로덕션 환경이나 일부 마이크로서비스에 제한적으로 배포하여 기본 설정부터 시작하세요. 기업의 요구사항에 따라 접속 제어 정책, 트래픽 라우팅 룰, 애플리케이션 보안 설정을 정의하세요.
서비스 메시의 안정성과 성능에 대한 확신이 생기면, 점차적으로 더 많은 마이크로서비스와 환경에 롤아웃합니다. 피드백, 성능 지표, 진화하는 요구사항에 따라 서비스 메시 설정을 지속적으로 반복하고 개선합니다.
요구사항에 가장 적합한 서비스 메시를 결정할 때 고려해야 할 몇 가지 요소는 다음과 같습니다.
커뮤니티 지원: 유용한 리소스, 문서, 커뮤니티 중심의 기여를 제공할 수 있는 활발한 커뮤니티 지원을 갖춘 서비스 매시를 선택하세요.
사용 편의성: 직관적인 툴, 명확한 문서, 사용자 친화적인 인터페이스를 제공하여 도입과 지속적인 유지 관리를 간소화하는 솔루션을 선택하세요.
기능 세트: 각 서비스 메시의 기능을 평가하고 요구사항에 부합하는지 확인하세요. 트래픽 관리 기능, 옵저버빌리티 툴, 보안 기능을 찾아보세요.
호환성: 서비스 메시가 컨테이너 오케스트레이션 플랫폼 및 클라우드 환경을 비롯한 기존 인프라와 호환되는지 확인합니다.
성능 및 확장성: 예상되는 워크로드를 처리하고 인프라 성장에 따라 확장할 수 있는 솔루션을 선택하세요.
고객이 Akamai를 선택하는 이유
Akamai는 온라인 비즈니스를 지원하고 보호하는 사이버 보안 및 클라우드 컴퓨팅 기업입니다. 시장을 대표하는 보안 솔루션, 탁월한 위협 인텔리전스, 글로벌 운영팀이 어디서나 기업 데이터와 애플리케이션을 보호하기 위한 심층적 방어 기능을 제공합니다. Akamai의 풀스택 클라우드 컴퓨팅 솔루션은 세계에서 가장 분산된 플랫폼에서 성능과 경제성을 제공합니다. 글로벌 기업들은 비즈니스 성장에 필요한 업계 최고의 안정성, 확장성, 전문성을 제공하는 Akamai를 믿고 신뢰합니다.
