서비스 메쉬(service mesh)란?

서비스 메쉬(Service Mesh)란 오픈소스 프로젝트 Istio처럼, 애플리케이션의 다양한 부분들이 서로 데이터를 공유하는 방식을 제어하는 방법입니다. 서비스 간 커뮤니케이션을 관리하는 다른 시스템들과 달리, 서비스 메쉬는 애플리케이션에 구축된 전용 인프라 계층입니다. 이 가시적인 인프라 계층은 서로 다른 애플리케이션 부분이 얼마나 원활하게 상호작용하는지를 기록할 수 있으므로, 더 쉽게 커뮤니케이션을 최적화하고 애플리케이션 확장에 따른 다운 타임을 방지할 수 있습니다.

애플리케이션의 각 부분인 '서비스'는 다른 서비스를 활용하여 사용자들이 원하는 기능을 제공합니다. 온라인 소매 애플리케이션 사용자는 구매를 할 경우 해당 아이템의 재고가 있는지를 알아야 합니다. 그러므로 해당 업체의 인벤토리 데이터베이스와 커뮤니케이션하는 서비스는 제품 웹 페이지와 커뮤니케이션해야 하며, 이 웹 페이지는 사용자의 온라인 장바구니와 커뮤니케이션해야 합니다. 비즈니스 가치를 추가하기 위해 이 소매업체는 사용자에게 인앱(in-app) 제품 추천을 제공하는 서비스를 구축하게 됩니다. 이 새로운 서비스는 제품 태그 데이터베이스와 커뮤니케이션하여 제품을 추천하고, 또한 제품 페이지에서 필요로 하는 재사용 가능하며 유동적인 부분이 많은 동일한 인벤토리 데이터베이스와도 커뮤니케이션해야 합니다.

현대적인 애플리케이션은 이와 같은 원리로 각각 특정한 비즈니스 기능을 수행하는 서비스 네트워크로 분류됩니다. 기능을 실행하기 위해 서비스는 여러 개의 다른 서비스들로부터 데이터를 요청해야 할 수 있습니다. 하지만 소매업체의 인벤토리 데이터베이스처럼 일부 서비스에 요청이 과도하게 몰릴 경우엔 어떻게 될까요? 여기서 한 서비스에서 다음 서비스로 요청을 전송하여 모든 구성 요소의 작동 방식을 최적화하는 서비스 메쉬를 도입합니다.

마이크로서비스 아키텍처를 통해 개발자는 애플리케이션 서비스 전체를 재배포할 필요 없이 손쉽게 변경할 수 있습니다. 다른 아키텍처에서의 애플리케이션 개발과 달리 개별 마이크로서비스는 자체 툴과 코딩 언어를 선택할 수 있는 유연성을 갖는 소규모 팀에 의해 구축됩니다. 기본적으로 마이크로서비스는 독립적으로 구축되고 서로 커뮤니케이션하며, 장애가 개별적으로 발생하므로 애플리케이션 전체의 운영 중단으로 확대되지 않습니다.

서비스 간 커뮤니케이션이 바로 마이크로서비스를 가능하게 하는 핵심입니다. 커뮤니케이션을 통제하는 로직은 서비스 메쉬 레이어 없이 각 서비스에 코딩될 수 있습니다. 그러나 커뮤니케이션이 복잡해질수록 서비스 메쉬의 중요성은 더욱 커집니다. 마이크로서비스 아키텍처에 구축된 클라우드 네이티브 애플리케이션의 경우에는 서비스 메쉬 방식으로 대량의 개별 서비스를 정상 애플리케이션으로 구성합니다.

서비스 메쉬는 애플리케이션 실행(runtime) 환경에 새로운 기능을 도입하지 않습니다. 아키텍처 내의 애플리케이션에는 요청이 A지점에서 B지점으로 전달되는 방식을 지정하는 룰이 항상 필요합니다. 서비스 메쉬의 차이점은 개별 서비스로부터 서비스 간 커뮤니케이션을 통제하는 로직을 통해 인프라 계층에 추상화한다는 점입니다.

이를 위해 서비스 메쉬는 네트워크 프록시의 배열로서 애플리케이션에 구축됩니다. 프록시는 엔터프라이즈 IT에서 많이 사용되는 개념으로, 업무용 컴퓨터에서 이 웹 페이지에 액세스하고 있다면 프록시를 사용했을 것입니다.

1. 이 페이지에 대한 사용자의 요청이 발송되면 사용자의 회사 웹 프록시가 먼저 이를 수신합니다.
2. 요청이 프록시 보안 조치를 통과하면 이 페이지를 호스팅하는 서버로 전송됩니다.
3. 다음으로 이 페이지가 프록시로 돌아가서 다시 보안 조치를 수행합니다.
4. 그 후 최종적으로 프록시에서 사용자에게 전송됩니다.

서비스 메쉬에서는 요청이 자체 인프라 계층의 프록시를 통해 마이크로서비스 간에 라우팅됩니다. 이러한 이유로 서비스 메쉬를 구성하는 개별 프록시는 서비스 내부가 아니라 각 서비스와 함께 실행되므로 'sidecar'라고도 합니다. 각 서비스에서 분리된 이러한 sidecar 프록시들이 모여 메쉬 네트워크를 형성합니다.

sidecar 프록시는 마이크로서비스와 나란히 위치하며 다른 프록시로 요청을 라우팅합니다. 이러한 sidecar들이 모여 메쉬 네트워크를 형성합니다.

서비스 메쉬 없이 각 마이크로서비스는 서비스 간 커뮤니케이션을 통제하는 로직으로 코딩해야 하기 때문에 개발자들이 비즈니스 목표에 집중하지 못하게 됩니다. 또한 서비스 간 커뮤니케이션을 통제하는 로직이 각 서비스 내부에 숨겨져 있기 때문에 커뮤니케이션 장애를 진단하기가 더 어려워집니다.

애플리케이션에 추가되는 모든 새로운 서비스 또는 컨테이너에서 실행되는 기존 서비스의 새로운 인스턴스는 커뮤니케이션 환경을 복잡하게 하고 새로운 장애 지점을 유발합니다. 복잡한 마이크로서비스 아키텍처 내에서 서비스 메쉬 없이는 문제가 발생한 지점을 찾아내기가 거의 불가능합니다.

이는 서비스 메쉬가 서비스 간 커뮤니케이션의 모든 부분을 성능 메트릭으로 캡처하기 때문입니다. 시간이 경과함에 따라 서비스 메쉬에서 볼 수 있는 데이터는 서비스 간 커뮤니케이션에 대한 룰에 적용할 수 있으며 보다 효율적이고 안정적으로 서비스 요청을 전달할 수 있습니다.

예를 들어, 서비스에 장애가 발생한 경우 서비스 메쉬는 재시도가 성공하기까지 소요한 시간에 대한 데이터를 수집할 수 있습니다. 특정 서비스의 장애 시간에 대한 데이터가 집계되면 해당 서비스를 재시도하기 전까지 최적의 대기 시간을 결정하는 룰을 작성하여 시스템이 불필요한 재시도로 인해 과부하되지 않도록 합니다.

마이크로서비스를 구축하는 경우, 비즈니스 요구 사항을 충족하기 위해 신속한 확장 및 새로운 기능 추가와 같은 특정한 요구 사항이 필요할 수 있습니다. 마이크로서비스 아키텍처는 시작했을 때와 비교하면 매년 상당히 다른 형태를 띠게 될 것입니다. 우선 마이크로서비스 내에 구축된 라이브러리는 운영 중단을 최소화하면서 서비스 간 커뮤니케이션을 처리할 수 있습니다. 마이크로서비스의 잠재력을 실현하고자 한다면 단순히 규모와 기능을 확장하는 것이 장기적인 해결책이 되지 않습니다. 시간이 지나면서 서비스가 수많은 요청으로 과부하되어 문제가 발생할 수 있고, 개발자들은 각 서비스에 대한 요청 로직을 코딩하는 데 더 많은 시간을 소비하게 됩니다.

서비스 메쉬를 활용하면 다음을 실현할 수 있습니다.

• 개발자들이 서비스를 연결하는 대신 비즈니스 가치를 추가하는 일에 집중할 수 있습니다.
• Jaeger를 통해 분산된 요청 추적은 서비스와 함께 가시적인 인프라 계층을 형성하므로 문제를 손쉽게 인식하고 진단할 수 있습니다.
• 서비스 메쉬는 장애가 발생한 서비스로부터 요청을 재라우팅할 수 있기 때문에 다운 타임 발생 시 애플리케이션 복구 능력이 향상됩니다.
• 시스템 성능 메트릭을 통해 실행(runtime) 환경에서 커뮤니케이션 최적화 방법을 제안할 수 있습니다.

Red Hat® OpenShift® Service Mesh에서 서비스 메쉬를 실험하면서 미래를 위한 계획을 시작해 보세요. 서비스 메쉬에서 네트워크화된 마이크로서비스에 대한 행동 기반 인사이트와 제어 기능을 갖춘 마이크로서비스 기반 애플리케이션을 단일한 방식으로 연결하고, 관리하고, 관찰할 수 있습니다. OpenShift Service Mesh는 Red Hat OpenShift에서 비용 없이 사용할 수 있습니다.

Red Hat Ansible Automation Platform의 자동화 메쉬 구성 요소는 자동화 확장을 위해 단순하고 신뢰할 수 있는 메쉬 프레임워크를 제공합니다. 자동화 메쉬는 유연한 다방향 커뮤니케이션 계층을 통해 조직의 운영 능력을 전 세계적인 규모로 향상해 줍니다. 대기 시간, 연결 디스럽션, 네이티브 피어링 기능에 덜 민감하므로 신뢰성이 강화되어 현재 출시된 다른 어떤 자동화 플랫폼보다도 넓은 범위에서 향상된 신뢰성을 활용할 수 있습니다. TLS 인증 및 암호화, 부가적인 액세스 제어 등 보안 기능을 제공하는 Red Hat Ansible Automation Platform에서 엔터프라이즈 전체의 IT 자산을 최대한 활용하고 가능성의 한계를 넓혀 보세요.