소프트웨어 전문지 마이크로소프트웨어 394호는 클라우드(Cloud)와 백엔드(Back-End)를 주제로 담았습니다. 이스티오, 서비스 메시, PaaS, 마이크로서비스 아키텍처 등 마소 394호의 주요 기사들을 IT조선 독자에게도 소개합니다. [편집자주]

마이크로서비스 아키텍처(Microservice Architecture, 이하 MSA)는 작은 서비스 수십, 수백 개로 이뤄진다. 그리고 수십, 수백 개의 서비스는 수천 개의 컨테이너로 배포된다. MSA를 사용하려면 수천 개의 컨테이너를 문제없이 연결하고 안정적으로 운영해야 한다.

서비스 메시(Service Mesh)는 MSA를 운영하면서 발생하는 연결, 모니터링, 보안 같은 문제를 서비스 간 통신에 끼어들어 해결하는 기술이다. 서비스의 모든 요청과 응답은 프록시 형태의 애플리케이션을 거친다. 애플리케이션에 여러 기술이 구현돼 있어, 기존 코드를 수정하지 않고 다양한 기능을 사용할 수 있다.

서비스 메시는 마치 공기처럼 존재하면서 서비스 간 요청을 자동으로 모니터링 하고, 전체 시스템의 가시성을 별다른 수고 없이 확보하는 방법이다.

프록시를 통한 요청 흐름. / 마이크로소프트웨어 394호 발췌
프록시를 통한 요청 흐름. / 마이크로소프트웨어 394호 발췌
서비스 메시는 서비스 요청을 가로채기 위해 프록시 형태로 존재한다. 웹 서버 앞에 엔진엑스(Nginx), ‘HAproxy’, ELB(Elastic Load Balancer)를 사용해 모든 요청이 해당 프록시 서버를 거치듯, 내부에서 통신할 때도 프록시 서버를 거치는 방식이다. 하나의 노드에 여러 서비스와 하나의 프록시를 사용하는 방법과 서비스마다 프록시를 하나씩 붙여서 사용하는 방법이 있다.

최근에는 프록시를 아주 적은 리소스로 동작할 수 있게 경량화해, 서비스마다 프록시를 구성하는 경우가 많다. 서비스마다 프록시를 붙이는 것을 오토바이 옆에 붙이는 보조석에 빗대어 ‘사이드 카 패턴’이라고 한다.

프록시가 어떤 방식으로 동작하는지 좀 더 자세히 알아보자. 각 서비스 앞에 프록시가 존재한다. 서비스 간 통신은 직접 이루어지지 않고 모든 요청과 응답은 서비스 앞에 존재하는 프록시를 거친다.

서비스A가 서비스B를 호출하면 서비스A 앞에 존재하는 프록시가 요청을 가로챈다. 프록시는 서비스B를 호출하기 위해 서비스B의 정보를 서비스 디스커버리에서 조회하고, 설정된 트래픽 규칙에 의해 서비스B 앞에 존재하는 프록시로 서비스A의 요청을 전달한다. 서비스B 앞에 존재하는 프록시는 전달받은 요청의 권한을 체크하고 허용된 요청이라면 서비스B로 요청을 전달한다.

서비스B의 응답 역시 프록시를 거친다. 이 과정에서 요청 시간과 응답속도, 응답코드 등을 모니터링 시스템에 전송한다.

서비스 간 통신이 암호화돼 있지 않더라도 프록시끼리는 통신을 암호화해 보안성을 높인다. 이런 모든 기능은 애플리케이션과 전혀 상관없이 동작하기 때문에 기존 애플리케이션에 라이브러리를 설치하거나 코드를 수정하지 않아도 된다.

김충섭 필자의 ‘이스티오 서비스 메시를 이용한 MSA 구축’에 대한 자세한 내용은 ‘마이크로소프트웨어 394호(https://www.imaso.co.kr/archives/3939)’에서 확인할 수 있다.


관련기사