처음에는 모든 곳에 있는 모든 것을 위한 애플리케이션 이었고, 그다음에는 마이크로서비스(및 이를 가능하게 하는 컨테이너 기술)가 되었습니다. 앱을 통해 뛰어난 사용자 경험을 제공하는 데 도움이 되는 다음 혁신은 무엇일까요? 서비스 메시.
마이크로서비스 방식은 더 크고 복잡한 애플리케이션을 형성하는 데 사용되는 작고 단일 목적의 구성요소에 의존합니다. 거의 모든 것에 대한 마이크로서비스를 만들 수 있으며, 각각이 단일 기능에 집중하기 때문에 개발이 비교적 빠릅니다. 그러나 원하는 기능이 많아질수록 마이크로서비스 구성 요소를 조정하는 것이 더 복잡해집니다.
기존 애플리케이션(모놀리스 애플리케이션이라고도 함)은 개발 속도가 느리지만 장점이 있습니다. 여러 개별 기능이 하나의 프로그램에 의해 실행되므로 일반적으로 구성 요소 간의 조정이 시스템 내에 내장되어 있습니다. 코드 소스가 하나뿐이므로 기존 앱의 경우 문제 해결과 디버깅이 더 쉽습니다.
서비스 메시는 마이크로서비스 간 통신을 원활하게 하는 투명한 인프라 계층입니다 . 이를 통해 마이크로서비스로 구축된 앱은 기존 앱과 동일한 이점(예: 복원성, 관찰 가능성, 보안 등)을 얻을 수 있습니다.
모놀리스에서 마이크로서비스로의 전환은 주로 애플리케이션 팀의 민첩성과 빠른 실행에 대한 필요성으로 인해 이루어졌습니다. 대규모 애플리케이션을 여러 개의 작은 요소로 줄이면 각 팀이 전문화할 수 있습니다. 이를 통해 그들은 모놀리스의 모든 측면에 관심을 가져야 할 때보다 더 빠르게 반복 작업을 수행할 수 있었습니다.
그러나 이러한 속도와 민첩성에는 비용이 따릅니다. 복잡성이 증가합니다. 마이크로서비스는 개발을 간소화하지만, 특히 여러 개의 일시적인 구성 요소를 보호하고 조율하는 측면에서 새로운 과제를 제시합니다. 서비스 메시는 개발자가 마이크로서비스 기반 애플리케이션의 확장에 따라 복잡성을 해소할 수 있는 방법입니다 .
최근 팟캐스트 에서 Aspen Mesh 의 공동 창립자이자 CTO인 Andrew Jenkins는 다음과 같이 말했습니다. "서비스 메시 환경에서 가장 큰 변화는 앱 개발자가 해야 하는 일이 아니라 하지 말아야 할 모든 일입니다." 예를 들어, 서비스 메시의 보안 구성 요소는 인증을 제공하고 한 애플리케이션이 다른 애플리케이션을 신뢰하는지 여부를 관리합니다. 요청이 실패하면 플랫폼 운영자는 마이크로서비스를 재시도할지 중단할지 정의할 수 있는 도구를 갖습니다.
이 새로운 환경에서 개발자는 요청을 서비스 메시 계층까지 전달하는 데 집중할 수 있습니다. 마이크로서비스 간 모든 통신을 관찰하는 도구에 액세스할 수 있는 플랫폼 운영자는 앱 개발자에게 완전히 새로운 범위의 데이터와 측정 항목을 제공할 수 있습니다. "서비스 메시에서는 한 곳에서만 고장을 고치면 다른 곳에서도 고쳐집니다. Jenkins는 "동일한 일관성 스토리가 계속해서 나타납니다."라고 말합니다.
서비스 메시를 강력한 새로운 도구 상자로 생각해 보세요. 보안, 거래 처리, 암호화, 추천 엔진, 분산 추적 등을 위한 도구가 있습니다. 목록은 계속 늘어납니다. 하지만 강력한 도구라도 사용하는 방법을 모른다면 아무런 도움이 되지 않습니다. 서비스 메시를 조기에 성공적으로 도입하려면 강력한 클라우드 아키텍처 관행과 개발자를 위한 인프라 서비스 정의에 경험이 있는 플랫폼 팀이 필요합니다.
많은 조직이 서비스 메시 없이 Kubernetes 와 기타 컨테이너 기술을 성공적으로 실행하고 있습니다. 표준 쿠버네티스 구현은 내장된 배포 문제를 매우 잘 해결합니다. 그러나 규모에 따라 Kubernetes 애플리케이션은 암호화, 회로 차단, 동적 트래픽 라우팅과 같은 잘 해결되지 않은 런타임 문제를 발생시킵니다. NGINX 와 기타 컨테이너 유입 솔루션은 네트워크 트래픽이 애플리케이션으로 유입되는 즉시 이를 캡처, 형성, 제어 및 시각화하는 수단을 제공함으로써 이러한 격차를 크게 메웁니다. 하지만 개발자들이 해당 도구가 제공할 수 있는 한계에 도달하면, 서비스 메시는 컨테이너화된 마이크로서비스가 수행할 수 있는 작업에 대한 새로운 수준의 가시성을 제공할 것을 약속합니다.
현재 서비스 메시는 아직 최첨단입니다. 이미 Kubernetes를 완전히 도입하거나 Kubernetes를 사용하여 개발할 계획인 조직의 경우, 서비스 메시를 나중에 구축하는 것보다 일찍 구현하는 것이 더 쉽습니다. 쿠버네티스를 확장하고 관리 오버헤드를 최소화하려면 서비스 메시가 필요합니다.
복잡한 보안 요구 사항이 있거나 마이크로서비스에서 파생된 애플리케이션에 크게 의존하는 조직의 경우, 서비스 메시는 배포와 유지 관리를 가속화하고, 보안을 강화하며, 리소스 소비를 최적화하는 데 도움이 될 수 있습니다. 서비스 메시 환경은 가시성을 높여 애플리케이션을 최적화하는 데 사용할 수 있는 미시적, 거시적 수준의 데이터를 제공합니다.
서비스 메시는 마이크로서비스 및 컨테이너 기술의 차세대 발전입니다. 올바른 전략이 있다면 강력한 도구가 될 수 있습니다.