마이크로서비스를 10개 띄우는 순간, 새로운 종류의 문제가 시작된다. service-a가 service-b의 IP를 어떻게 알 것인가, service-b가 갑자기 5xx를 뱉으면 service-a는 얼마나 빨리 재시도해야 하는가, 통신을 모두 mTLS로 암호화하려면 인증서는 누가 발급·회전하는가, 새 버전을 10%만 트래픽 받게 하려면 어디서 라우팅을 갈라야 하는가. 이 모든 문제를 애플리케이션 코드 안에서 풀면 코드가 비즈니스 로직보다 인프라 코드로 더 두꺼워진다. 서비스 메시는 이 문제를 코드 밖 사이드카 프록시로 옮긴 답이다. SAP 시험은 AWS의 세 가지 옵션 — Cloud Map·ECS Service Connect·App Mesh — 의 차이를 시나리오로 자주 묻는다.
이 글에서는 서비스 메시가 왜 생겨났는지, 사이드카 프록시가 어떻게 트래픽을 가로채는지, 세 서비스가 책임을 어떻게 나누는지를 본다. 그리고 mTLS·카나리·서킷 브레이커 같은 메시 기능이 실제로 어떻게 구현되는지, App Mesh EOL 발표(2024) 이후 어떤 대안이 표준이 되어가는지를 다룬다. 어제까지 본 ECS·EKS·Fargate 위에 마이크로서비스 10개를 띄웠다면 다음 자연스러운 질문이 "그들 간 통신은 어떻게 안전·관찰 가능하게 만드는가"이고, 오늘이 그 답이다.
모놀리식 애플리케이션에서 함수 호출은 같은 프로세스 안에서 일어난다