컨테이너 확장의 미래가 서비스 메시인 8가지 이유

F5 에코시스템 | 2018년 4월 23일

마이크로서비스는 개발 속도를 높이는 데 매우 유용하지만, 이러한 아키텍처의 복잡성은 마이크로서비스가 의존하는 서비스 간 통신에 있습니다.

현재로서는 컨테이너화된 마이크로서비스를 확장하기 위한 아키텍처 옵션이 적어도 세 가지 있습니다. 모든 확장 방식이 그렇듯 각각 프록시 기반 로드 밸런서를 토대로 합니다. 각 방식에는 저마다 해결해야 할 과제가 있습니다. 이러한 과제 중 상당수는 컨테이너 환경 내 확장이 흔히 IP 테이블에 의존하며, IP 테이블은 기존 네트워크 계층(즉, IP와 TCP)보다 상위 계층을 처리하는 능력이 제한적이라는 단순한 사실에서 비롯됩니다.

이러한 프록시는 모두 컨테이너 환경 전반에 분산된 서비스를 확장하는 동일한 핵심 기능을 제공합니다. 놀라운 점은 서비스가 일시적으로 존재하는 구성 요소라는 것입니다. 서비스를 정의하는 리소스(구성) 파일을 제외하면 실제로 존재하지 않습니다. IP 테이블 기반 확장 솔루션의 문제는 이러한 서비스가 계층 7(HTTP) 구성 요소이며, 전체 애플리케이션이 아니라 단일 API 호출의 ‘백엔드’ 역할을 하는 경우가 많다는 점입니다.

우리가 알고 있는 애플리케이션은 클라이언트 측에서 보면 하나의 통합된 구성체처럼 보일 수 있습니다. 하지만 실제로는 서로 다른 여러 분산형 마이크로서비스로 구성됩니다. 이 중 일부는 다른 서비스에서 사용하도록 설계된 순수 내부용 서비스입니다. 즉, 컨테이너화된 환경 내부에서 서비스 간 통신이 빈번하게 이루어집니다.

이러한 환경에서는 모든 것이 HTTP/HTTP2 기반 API로 이루어져 있으므로 L7(HTTP) 라우팅이 필요합니다. 또한 일관된 보안 체계와 인증, 정책 적용도 필요합니다. IP 테이블 기반 접근 방식으로는 이 중 어느 것도 구현할 수 없습니다.

늘 그렇듯이 오픈 소스가 해결사로 나섭니다. 이러한 과제를 해결하기 위해 여러 오픈 소스 서비스 메시가 등장했습니다. 많은 오픈 소스 프로젝트가 그렇듯이 이러한 서비스 메시(예: Istio)는 Aspen Mesh와 같은 프로젝트를 통해 엔터프라이즈급 솔루션을 제공하는 기능과 지원을 갖추도록 확장되고 있습니다.

이러한 확장된 노력은 조직이 컨테이너에 마이크로서비스를 배포할 때 직면하는 8가지 과제를 해결하는 데 중점을 두고 있습니다.

다음은 8가지 과제와 서비스 메시를 통해 이를 해결하는 방법입니다:

  1. 빌드 – 이 과제와 관련해 서비스 메시가 제공할 수 있는 기능은 정책을 CI/CD 도구 체인과 통합하고, 서비스 메시를 코드형 인프라로 취급할 수 있도록 선언적 구성 모델을 보장하는 것 정도로 제한적입니다.
  2. 테스트 및 통합 – 서비스 메시는 개발, 테스트, 프로덕션 등의 환경에서 일관된 정책을 보장함으로써 이 단계에 도움을 줄 수 있습니다. 일부 조직은 단계적 배포를 완전히 없애려고 합니다. 이 접근 방식은 과거에는 효과적이었지만, 배포 프로세스를 지연시키는 장애물 중 하나이기도 합니다. 이들은 서비스를 프로덕션 환경에 직접 배포하고, 장애에 대응하기 위해 트래픽 조정 및 롤백 메커니즘을 활용할 방법을 모색하고 있습니다.
  3. 버전 관리 – 서비스 메시는 기본적인 API 게이트웨이 역할을 하여 API 버전과 같은 변수에 따라 트래픽을 라우팅하고, API 버전 전환 기간에는 버전을 변환할 수도 있습니다. 특히 소비자용 앱의 경우 클라이언트 업그레이드를 항상 강제할 수 없으므로 여러 버전에 대한 요청이 들어올 수 있습니다. 서비스 메시는 이전 API 버전에 대한 요청을 최신 버전으로 변환하여 동일한 API의 여러 버전을 유지하는 데 드는 비용과 부담을 줄이는 데 도움을 줄 수 있습니다.
  4. 배포 – HTTP를 원활하게 처리할 수 있는 서비스 메시는 블루/그린 배포, 카나리 테스트 및 트래픽 조정을 지원하기에 매우 적합합니다.
  5. 로깅 – 분산 로깅은 언제나 문제가 되며, 인스턴스의 수명이 크게 달라지는 환경에서는 더욱 까다롭습니다. 서비스 메시는 로깅을 구현할 수 있는 공통의 중앙 집중식 위치를 제공할 뿐만 아니라 요청 추적과 같은 기능을 수행할 수 있게 해줍니다.
  6. 모니터링 – 확장성의 핵심에는 모니터링이 있습니다. 애플리케이션이 불가피한 서비스 장애에 대응하기 위해 특정 기능(재시도, 서킷 브레이킹 등)을 구현할 수는 있지만, 이는 애플리케이션이 짊어질 필요가 없는 부담을 안깁니다. 서비스 메시는 서비스 간 통신의 부담을 맡고 모니터링을 위한 기반을 제공합니다. 프로덕션 환경을 운영하는 것은 어렵고 장애는 불가피하므로, 목표는 프로덕션 환경에서 MTTD와 MTTR을 개선하는 데 집중하는 것입니다.
  7. 디버깅 – 시스템이 복잡할수록 디버깅도 더 어려워집니다. 서비스 메시는 근본 원인 분석을 지원하고, 분석 및 텔레메트리를 활용해 통계와 장애 사전 알림을 제공하며, 컨테이너를 종료하는 대신 격리하여 철저히 조사할 수 있도록 합니다. 이는 특히 느린 메모리 누수로 인해 장애가 발생하는 경우에 유용합니다.
  8. 네트워킹 – 네트워킹은 컨테이너에서 여전히 매우 중요하며, 복잡성이 낮은 환경에서보다 오히려 더 중요할 수 있습니다. 서비스를 네트워킹으로부터 추상화하려면 서비스 검색, SSL 및 인증서 관리, 서킷 브레이커, 재시도, 상태 모니터링 등 모든 서비스에 일일이 구현하고 싶지 않은 수많은 요소를 처리해야 합니다. 마이크로서비스의 목표는 “로컬에서 작게 코딩하는 것”이었습니다. 네트워킹 관련 기능까지 포함해야 하면 마이크로서비스가 비대해지고 아키텍처 및 기술 부채가 늘어납니다. 서비스 메시는 이러한 기능을 대신 수행하여 개발에 부담을 주지 않으면서 원하는 확장성과 보안을 제공합니다.

서비스 메시는 클라우드와 컨테이너의 현대적인 원칙을 견고한 확장성 기반과 결합한 흥미로운 진화입니다. 2018년에도 컨테이너 도입이 늘고 엔터프라이즈급 확장성과 지원에 대한 수요가 증가함에 따라 서비스 메시가 더욱 주목받을 것으로 예상됩니다.

공유

작성자 소개

Lori Mac Vittie
Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물

관련 블로그 게시물

성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5 에코시스템 | 2023. 07. 13.

성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A

F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.

TLS 검사에서 피터 파커 원칙 다루기
F5 에코시스템 | 2019. 12. 09.

TLS 검사에서 피터 파커 원칙 다루기

“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.

Venafi와 F5를 통한 머신 아이덴티티 보호
F5 에코시스템 | 2018. 12. 11.

Venafi와 F5를 통한 머신 아이덴티티 보호

‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.

마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
F5 에코시스템 | 2018. 07. 23.

마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다

물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...

내 클라우드에서 나가!
F5 에코시스템 | 2016. 10. 12.

내 클라우드에서 나가!

F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.

Shift(웹 앱) 보안 레터
F5 에코시스템 | 2015. 07. 06.

Shift(웹 앱) 보안 레터

웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.