3.16 API 게이트웨이와 서비스 메시

개요와 동기

하나의 프로그램을 많은 서비스로 쪼개는 순간 새로운 질문이 나타납니다. 서비스 사이의 트래픽과 바깥에서 들어오는 트래픽을 누가 책임지는가? 이 질문에 나쁘게 답하는 방법은 같은 관심사(인증, 재시도, 타임아웃, 속도 제한, 로깅)를 모든 서비스에 손으로 흩뿌리는 것이고, 잘 답하는 방법은 그런 관심사를 모든 서비스가 공짜로 상속하는 공유 계층으로 밀어 넣는 것입니다. 이 장은 그런 두 계층에 관한 것입니다. API 게이트웨이는 정문에 서서 클라이언트에서 들어오는 트래픽을 관리합니다. 서비스 메시는 서비스 사이에 서서 그들 사이를 흐르는 트래픽을 관리합니다. 둘은 서로 다른 곳에서 관련된 문제를 풀며, 둘을 혼동하는 것은 흔하고 비싼 실수입니다.

업계는 두 방향의 트래픽을 나침반 은유로 부릅니다. 남북 트래픽은 시스템의 경계를 넘는 트래픽입니다. 모바일 앱, 브라우저, 호출해 오는 파트너입니다. 동서 트래픽은 시스템 안에 머무는 트래픽입니다. 하나의 요청을 만족시키려고 서비스 A가 서비스 B를 호출하고 B가 서비스 C를 호출합니다. API 게이트웨이는 남북의 전문가이고, 서비스 메시는 동서의 전문가입니다. 이 구분을 날카롭게 유지하는 것이 이 장에서 가장 유용한 단일 아이디어입니다. 어느 도구가 어느 정책을 소유하는지 알려 주고, 같은 일을 두 번 하지 않게 해 주기 때문입니다.

큰 팀에게 이런 계층은 정책을 백 번이 아니라 한 번 시행하는 방법입니다. 인증, 전송 중 암호화, 속도 제한이 공유 계층에 있으면, 보안 수정이 백 개의 백로그를 기다리지 않고 계층을 배포하는 날 모든 서비스에 출하됩니다. 기업과 정부 환경에서는 그 중앙화가 흔히 요점입니다. 감사자는 접근이 확인되고 트래픽이 암호화되는 단일하고 입증 가능한 장소를 원하고, 공유 게이트웨이나 메시가 바로 그 정책 시행 지점을 줍니다. 이 장은 3.2장의 아키텍처 스타일, 3.3장의 분산 시스템 현실, 3.13장의 네트워킹 기본 위에 서서 이를 누가 트래픽을 처리하는지에 대한 구체적 지침으로 바꿉니다.

핵심 원칙

남북(게이트웨이)과 동서(메시)를 분리하고, 각자 자기 방향을 소유하게 하십시오.
횡단 관심사를 공유 계층으로 밀어 서비스마다가 아니라 한 번 쓰십시오.
서비스 수 때문에 서비스별 배선이 더 큰 비용일 때만 서비스 메시를 채택하십시오.
관심사마다 하나의 정책 시행 지점을 정의하십시오. 게이트웨이와 메시가 같은 일을 하게 두지 마십시오.
서비스를 얇게 유지하십시오. 플랫폼이 전송을, 서비스가 비즈니스 로직을 처리합니다.
네트워크 위치에 기반한 신뢰보다 신원 기반의 제로 트러스트 네트워킹을 선호하십시오.
메시의 운영 복잡성을 눈을 뜨고 사고, 값을 하는지 측정하십시오.

권장 사항

API 게이트웨이가 하는 일을 이해한다

API 게이트웨이는 서비스 앞에 서서 바깥세상의 모든 요청을 중개하는 단일 진입점입니다. 가장 단순하게는 똑똑한 리버스 프록시(클라이언트 요청을 받아 알맞은 백엔드로 전달하는 서버)이지만, 게이트웨이는 전달보다 훨씬 많은 일을 해서 그 이름을 얻습니다. 경로, 호스트, 헤더에 근거해 각 요청을 올바른 서비스로 라우팅합니다. 호출자를 인증(누구인지 검증)하고 요청을 인가(무엇을 할 수 있는지 확인)하여, 그 뒤의 서비스가 요청이 이미 정문을 통과했음을 신뢰할 수 있게 합니다. 속도 제한(시간당 클라이언트별 요청 상한)과 할당량(더 긴 기간의 총사용량 상한)을 시행해 시끄럽거나 악용하는 클라이언트 하나가 나머지를 굶기지 못하게 합니다.

게이트웨이는 트래픽의 모양도 바꿉니다. 요청 변환은 헤더를 다시 쓰고, 프로토콜 사이를 번역하고, 옛 클라이언트의 형식을 새 서비스의 기대에 맞게 조정합니다. API 조합은 게이트웨이가 들어온 요청 하나를 여러 서비스로 퍼뜨리고 그 응답을 하나로 엮게 해, 클라이언트가 여섯 번이 아니라 한 번 호출합니다. 버전 관리 지원은 API의 v1과 v2를 나란히 운영하고 각 클라이언트를 기대하는 버전으로 라우팅하게 해, 아무도 깨뜨리지 않고 진화할 여지를 줍니다. 이런 관심사를 엣지에 집중시키면 서비스가 비즈니스 로직에 집중하게 되고, 들어오는 모든 것을 관측하고, 보호하고, 조절할 한 곳이 생깁니다. 게이트웨이가 앞에 두는 API의 설계는 2.3장의 주제이고, 게이트웨이가 수행하는 신원 확인은 4.7장에 기댑니다.

갈라지는 클라이언트에는 프런트엔드를 위한 백엔드 패턴을 쓴다

하나의 범용 API가 웹 앱, 모바일 앱, 파트너 통합을 동시에 섬기는 경우가 많고, 모두를 조금씩 나쁘게 섬깁니다. 모바일 클라이언트는 대역폭과 배터리가 희소하므로 작은 페이로드와 적은 왕복을 원합니다. 웹 클라이언트는 더 수다스럽고 풍부한 응답을 감당할 수 있습니다. 파트너는 결코 놀라게 하지 않는 안정적인 계약을 원합니다. 프런트엔드를 위한 백엔드(BFF) 패턴은 각 부류의 클라이언트에 그 필요에 맞춘, 그 뒤의 공유 서비스 앞에 서는 자체의 얇은 게이트웨이를 주어 이 긴장을 해소합니다.

BFF는 더 좁은 청중을 가진 게이트웨이입니다. 모바일 BFF는 응답을 조합하고 다듬어 앱이 효율적인 호출 한 번을 하게 하고, 웹 BFF는 더 풍부한 모양을 노출하며, 파트너 BFF는 천천히 변하는 신중하게 버전 관리되는 계약을 지닙니다. 각 팀이 다른 팀을 기다리지 않고 자기 BFF를 진화시킬 수 있으며, 클라이언트 팀들을 서로 분리하므로 이것이 흔히 진짜 이점입니다. 비용은 더 많은 움직이는 부분과 BFF 사이에 중복된 약간의 로직이므로, 이 패턴은 클라이언트 필요가 정말 갈라지는 경우에 남겨 두십시오. 모든 클라이언트가 같은 것을 원한다면 하나의 게이트웨이가 더 단순하고 낫습니다.

서비스 메시가 하는 일을 이해한다

서비스 메시는 서비스 사이의 동서 트래픽을 관리하며, 그 서비스들이 코드를 바꾸라고 요구하지 않고 그렇게 합니다. 고전적인 메시는 사이드카 프록시(각 서비스 인스턴스 옆에서 돌며 그 모든 네트워크 트래픽을 가로채는 작은 프록시 프로세스)를 배포하여 작동합니다. 서비스는 다른 서비스와 직접 대화한다고 생각하지만, 실제로는 진짜 네트워크 호출을 처리하는 로컬 사이드카와 대화합니다. 이제 모든 요청이 플랫폼이 통제하는 프록시를 통해 흐르므로, 메시는 동기화해야 할 공유 라이브러리 없이 모든 언어의 모든 서비스에 걸쳐 동작을 균일하게 시행할 수 있습니다.

무엇을 시행합니까? 첫째, 상호 TLS(mTLS)입니다. 모든 연결의 양쪽이 인증서를 제시하고 트래픽을 암호화하므로, 서비스 간 호출이 기본으로 인증되고 비공개입니다. 둘째, 트래픽 관리입니다. 메시는 카나리 릴리스를 위해 트래픽의 작은 비율을 새 버전으로 옮기고, 테스트를 위해 헤더로 트래픽을 나누고, 트래픽을 섀도 서비스에 미러링할 수 있습니다. 셋째, 복원력입니다. 재시도, 타임아웃, 서킷 브레이킹(2.20장의 패턴)이 각 서비스에 코딩되는 대신 정책으로 설정되어 플랫폼 계층에서 적용됩니다. 넷째, 관측 가능성입니다. 모든 요청이 프록시를 통과하므로, 메시는 모든 서비스 간 트래픽에 대해 일관된 지표, 로그, 분산 추적을 내보내 9.2장의 관측 가능성 실천에 공급합니다. 서비스 작성자는 이 중 아무것도 쓰지 않고 전부를 얻습니다.

사이드카 패턴과 사이드카리스 대안을 안다

사이드카 모델은 우아하지만 공짜가 아닙니다. 이제 각 서비스 인스턴스는 메모리와 CPU를 소비하는 추가 프록시 컨테이너를 돌리고, 모든 호출이 두 번의 추가 네트워크 홉(로컬 사이드카로 들어가고 원격 사이드카에서 나옴)을 만들어 약간의 지연을 더합니다. 서비스가 몇 개일 때 이 오버헤드는 보이지 않지만, 수천 개의 파드에 걸치면 컴퓨트 청구서와 지연 예산의 실제 항목이 됩니다. 그 비용이 사이드카리스, 곧 프록시리스 접근의 물결을 이끌었습니다.

두 방향이 중요합니다. 하나는 메시 기능을 파드별 사이드카에서 노드별 프록시로 옮겨, 같은 기계의 많은 서비스가 각자 프록시를 돌리는 대신 하나를 공유합니다. 일부 격리를 오버헤드의 큰 감소와 맞바꿉니다. 다른 하나인 프록시리스 접근은 메시의 로직을 얇은 라이브러리나 런타임을 통해 서비스에 직접 내장하여, 언어별 의존성을 대가로 추가 홉을 완전히 없앱니다. 더 새로운 발전은 일부 메시 기능을 eBPF(리눅스 커널 안에서 샌드박스 프로그램을 실행하는 기술)로 운영체제 커널에 밀어 넣어, 사용자 공간 프록시보다 적은 오버헤드로 정책을 시행하고 텔레메트리를 수집할 수 있습니다. 오늘 하나의 승자에 걸 필요는 없습니다. 사이드카 세금이 실재하고, 대안이 존재하며, 플랫폼 선택이 나중에 그것들을 채택하는 길을 막아서는 안 된다는 것은 알아야 합니다. 이런 패턴은 8.3장의 컨테이너 오케스트레이션 기반 위에 있습니다.

메시가 복잡성만큼 값을 하는 때를 결정한다

서비스 메시는 강력하고 운영하기가 정말 복잡합니다. 운영할 컨트롤 플레인, 업그레이드할 프록시, 교체할 인증서, 요청이 사라질 때 디버깅할 새로운 계층을 더합니다. 이런 관심사를 서비스별, 언어별로 손으로 배선하는 비용이 메시를 운영하는 비용보다 클 만큼 서비스가 충분히 많을 때 그 복잡성을 살 가치가 있습니다. 대략의 신호는 규모와 다언어 다양성입니다. mTLS와 재시도를 위한 공유 라이브러리를 일관되게 유지하기가 악몽일, 여러 언어로 쓰인 수십, 수백 개의 서비스입니다. 그 규모에서 메시는 균일성과 입증 가능한 보안으로 본전을 뽑습니다.

서비스가 몇 개이거나, 언어가 하나이거나, 팀이 작을 때 메시는 복잡성만큼 값을 하지 못합니다. 소규모 시스템에서는 좋은 라이브러리나 프레임워크가 완전한 메시보다 훨씬 적은 운영 부담으로 mTLS, 재시도, 지표를 줄 수 있고, 평범한 게이트웨이와 합리적인 클라이언트 라이브러리가 필요한 모든 것을 덮는 경우가 많습니다. 규모가 요구하기 전에 유행이라서 메시를 채택하는 것은 갖고 있지 않은 문제를 푸는 인프라를 운영하며 1년을 쓰는 흔한 방법입니다. 게이트웨이로 시작하고, 코드나 라이브러리에 복원력 패턴을 더하고, 서비스와 언어의 수가 서비스별 접근을 더 비싸게 만들 때 메시에 손을 뻗으십시오. 클라우드와 분산 시스템 장(3.11장과 3.3장)이 거듭 돌아오는 “복잡성만큼 값을 하는가” 규율과 같습니다.

게이트웨이와 메시가 겹치는 곳에서 이중 처리를 피한다

게이트웨이와 메시는 겹치며, 팀이 스스로를 해치는 곳이 그 겹침입니다. 둘 다 재시도할 수 있고, 둘 다 타임아웃을 시행할 수 있고, 둘 다 신원을 확인할 수 있고, 둘 다 텔레메트리를 수집할 수 있습니다. 게이트웨이가 요청을 세 번 재시도하고 메시도 모든 내부 홉에서 세 번 재시도하면, 클라이언트의 재시도 한 번이 수십 번의 백엔드 호출로 폭발해 작은 끊김을 재시도 폭풍으로 바꿀 수 있습니다. 두 계층이 모두 타임아웃을 시행하는데 안쪽이 바깥쪽보다 길면, 바깥쪽은 포기하는데 안쪽은 계속 일해서 아무도 읽지 않을 응답에 노력을 낭비합니다.

해법은 적고 합의된 분명한 역할 분담입니다. 각 관심사를 정확히 한 계층에 배정하십시오. 게이트웨이는 남북 관심사를 소유합니다. 최종 사용자 인증, 외부 속도 제한과 할당량, 요청 변환, 클라이언트를 위한 API 조합입니다. 메시는 동서 관심사를 소유합니다. 서비스 간 mTLS, 내부 재시도와 서킷 브레이킹, 서비스 버전 간 트래픽 이동입니다. 관심사가 어느 쪽에든 살 수 있는 곳에서는 소유자 하나를 고르고 다른 계층은 통과하게 만드십시오. 바깥쪽 타임아웃이 그것이 기다리는 안쪽 작업보다 항상 길도록 재시도 예산과 타임아웃 계층을 설정하십시오. 목표는 모든 요청에 각 관심사를 처리하는 정확히 한 곳이 있고, 어떤 요청도 우연히 두 번 재시도, 인증, 로깅되지 않는 것입니다.

게이트웨이와 메시를 제로 트러스트의 정책 시행 지점으로 다룬다

이런 계층을 운영하는 가장 깊은 이유는 보안 아키텍처입니다. 제로 트러스트는 어떤 요청도 어디서 왔는지 때문에 신뢰되지 않는다는 원칙입니다. 모든 요청은 자기 네트워크 안에서조차 신원과 인가를 증명해야 합니다. 옛 모델은 이미 경계 안에 있는 모든 것을 신뢰했고, 이는 침해된 서비스 하나가 자유롭게 돌아다닐 수 있다는 뜻이었습니다. 제로 트러스트는 네트워크 위치 신뢰를 모든 홉의 신원 기반 신뢰로 대체하며, 게이트웨이와 메시가 그 신원을 확인하는 자연스러운 시행 지점입니다.

게이트웨이는 외부 신원의 정책 시행 지점입니다. 무엇이든 서비스에 닿기 전에 최종 사용자나 파트너를 검증합니다. 메시는 워크로드 신원의 정책 시행 지점입니다. 모든 서비스가 암호학적 신원을 얻고, mTLS가 모든 호출에서 그것을 증명하며, 정책이 어느 서비스가 어느 서비스와 대화할 수 있는지 결정합니다. 함께, 이들은 심층 방어를 줍니다. 요청이 엣지에서, 그리고 서비스 사이에서 다시 확인되므로, 한 서비스의 침해가 나머지로의 자유로운 이동을 허용하지 않습니다. 다중 클러스터와 다중 리전 배포에서 메시는 이 신원 직물을 클러스터 경계에 걸쳐 확장할 수 있어, 한 클러스터의 서비스가 로컬에서 쓰는 것과 같은 mTLS 보장으로 다른 클러스터의 서비스에 인증하고, 발자국이 퍼지는 동안에도 일관된 제로 트러스트 네트워킹을 줍니다. 여기의 신원 기반은 4.7장에 직접 연결됩니다.

장단점

접근 방식	장점	단점
API 게이트웨이	인증, 속도 제한, 조합, 버전 관리를 위한 한 곳	확장하고 고가용성을 유지해야 하는 단일 병목
프런트엔드를 위한 백엔드	각 클라이언트가 맞춤형이며 독립적으로 진화하는 API를 얻음	운영할 게이트웨이가 더 많음. BFF 사이에 로직 중복
서비스 메시 (사이드카)	코드 변경 없이 균일한 mTLS, 재시도, 관측 가능성	프록시 오버헤드, 지연, 운영할 컨트롤 플레인
사이드카리스 / 프록시리스 메시	파드별 사이드카보다 낮은 오버헤드와 지연	덜 성숙함. 약한 격리 또는 언어별 의존성
라이브러리 기반 복원력	운영이 단순. 추가 인프라 없음	언어별 중복. 규모에서 일관성 유지가 어려움
클러스터에 걸친 메시	어디서나 일관된 제로 트러스트 신원	상당한 운영 및 네트워킹 복잡성

핵심 긴장은 균일성 대 운영 비용입니다. 공유 계층은 일관성, 입증 가능한 보안, 한 번 쓰는 정책을 사 주지만, 운영하고, 확장하고, 보호하고, 디버깅해야 하는 실제 시스템이며 모든 요청의 경로에 스스로를 끼워 넣습니다. 규모와 필요로 긴장을 해소하십시오. 게이트웨이는 외부 클라이언트가 생기는 순간 거의 항상 값을 합니다. 그것이 중앙화하는 관심사는 피할 수 없는 것이기 때문입니다. 메시는 나중에, 서비스와 언어의 수가 서비스별 배선을 더 비싼 길로 만들 때 값을 합니다. 그 임계값 아래에서는 라이브러리와 평범한 게이트웨이가 비용의 일부로 이점의 대부분을 줍니다. 그 위에서는 메시의 균일성이 제 값을 합니다. 어느 방향이든 실수는 필요가 아니라 유행에 따라 채택하는 것입니다. 너무 일찍 메시는 1년의 쓸데없는 잡일이고, 너무 늦게 건너뛴 메시는 mTLS의 백 개의 일관성 없는 손수 만든 구현입니다.

팀과 논의할 질문

각 횡단 관심사(인증, 재시도, 타임아웃, 속도 제한, 암호화, 텔레메트리)를 어느 단일 계층이 소유하며, 모두가 짐작하지 않고 소유자를 말할 수 있습니까? 이것이 이중 처리를 막는 질문이며, 대부분의 팀은 명시적으로 답한 적이 없어서 답이 서비스와 작성자마다 다릅니다. 관심사의 구체적 목록을 왼쪽에 놓고 계층(클라이언트 라이브러리, 게이트웨이, 메시, 개별 서비스)을 위쪽에 놓아 함께 격자를 채우십시오. 한 관심사에 두 칸이 체크된 곳이 일어나기를 기다리는 재시도 폭풍과 타임아웃 역전입니다. 빈 행은 아무도 처리하지 않는 관심사입니다. 산출물은 정확히 한 계층이 각 관심사를 소유하고 나머지는 통과한다고 말하는, 모든 팀이 볼 수 있는 곳에 게시된 합의된 단일 표입니다. 그 표는 어떤 양의 게이트웨이나 메시 설정보다 가치가 있습니다. 두 계층이 서로 싸우지 않게 지키는 것이기 때문입니다.
서비스 메시를 정당화할 만큼 서비스와 언어 다양성이 정말 충분합니까, 아니면 갖고 있지 않은 문제를 풀려고 컨트롤 플레인을 사려는 것입니까? 메시는 진지한 운영상의 약속이며, 많은 팀에게 정직한 답은 좋은 라이브러리와 게이트웨이가 오늘 더 잘 섬길 것이라는 점입니다. 서비스의 실제 수, 쓰인 언어의 수, 중복된 네트워킹 로직이 지금 실제로 얼마나 아프게 하는지에 대한 정직한 평가를 가져오십시오. 그다음 다른 쪽도 가져오십시오. 누가 메시를 운영하고, 프록시를 업그레이드하고, 인증서를 교체하고, 요청을 잘못 라우팅할 때 호출되겠습니까? 서비스별 배선의 고통이 메시를 운영하는 비용보다 작다면 답이 있고, 그것은 기다리는 것입니다. 수십 개의 다언어 서비스에 걸쳐 일관성 없는 mTLS와 재시도 코드에 허우적댄다면 메시가 제값을 합니다. 요점은 학회 발표가 메시를 어떻게 보이게 했는지가 아니라 증거로 결정하는 것입니다.
오늘 제로 트러스트 경계는 어디에 있으며, 내부 서비스 하나가 침해되면 어떻게 됩니까? 많은 시스템이 여전히 네트워크 안의 모든 것을 신뢰하며, 이는 침해된 서비스 하나가 옆으로 이동해 다른 모든 것에 닿을 수 있다는 뜻이고, 팀은 흔히 인시던트 중에야 이를 발견합니다. 영향 범위를 정직하게 따라가 보십시오. 공격자가 서비스 하나를 장악하면 무엇을 호출할 수 있고, 무엇을 읽을 수 있고, 무엇이 막습니까? 서비스 간 호출이 어떻게 인증되고 암호화되는지에 대한 현재 답을 가져오고, 어느 호출이 mTLS로 보호되고 어느 것이 같은 네트워크에 있다는 이유의 평문 신뢰인지 구체적으로 밝히십시오. 이어지는 행동은 모든 홉의 신원 기반 접근에 대한 의도적 계획입니다. 게이트웨이가 외부 신원을, 메시나 그에 상응하는 것이 워크로드 신원을 확인해, 침해가 파국이 아니라 한정되게 합니다. 완전한 메시를 운영할 준비가 안 되었더라도, 신뢰 경계가 실제로 어디 있는지 이름 붙이는 것이 첫 정직한 단계입니다.
API 게이트웨이 계층이 지금 실패한다면 시스템의 얼마가 어두워지며, 그 실패를 그냥 가정하지 않고 테스트해 보았습니까? 게이트웨이는 너무 많은 것을 중앙화하므로 그 장애가 뒤의 모든 것을 오프라인으로 만들며, 큰 팀은 조용히 일하다 그러지 않게 될 때까지 바로 그 이유로 중복성에 투자를 덜 합니다. 경쟁하는 끌림을 저울질하십시오. 단일하고 단순한 게이트웨이는 추론하기 쉽고 운영이 싼 반면, 수평 확장되고 다중 영역인 계층은 비용이 더 들고 자체 페일오버 설정과 복잡성을 더합니다. 실제 숫자를 논의에 가져오십시오. 오늘 인스턴스가 몇 개 도는지, 몇 개 가용 영역에 걸치는지, 페일오버 시간은 얼마인지, 마지막으로 게이트웨이를 일부러 죽인 게임 데이를 한 것이 언제인지. 가동 시간 약속이나 법정 서비스 수준을 지닌 기업과 정부 플랫폼에서는 장애에 대한 계약상 또는 규제상의 위약금을 더하십시오. 중복성 없는 정문은 모든 서비스와 그 뒤의 모든 시민을 대신해 조용히 받아들인 가용성 위험이기 때문입니다.
우리 메시가 실제로 부과하는 사이드카 세금을 측정했으며, 사이드카리스와 eBPF 대안에 대한 계획이 있습니까, 아니면 눈 감고 내고 있습니까? 규모에서 파드별 프록시 오버헤드는 컴퓨트와 지연에서 더는 보이지 않는 것이 아니라 예산의 실제 항목이 되지만, 많은 팀이 비용을 측정한 적 없이 수천 개의 사이드카를 운영합니다. 긴장은 한쪽에 사이드카 모델의 성숙도와 격리, 다른 쪽에 더 새롭고 일부 격리를 내주거나 언어별 의존성을 더하는 노드별 프록시, 프록시리스 라이브러리, 커널 eBPF 접근의 더 낮은 오버헤드 사이에 있습니다. 측정된 수치를 가져오십시오. 장치군 전반의 프록시가 소비하는 메모리와 CPU, 홉당 추가된 꼬리 지연, 메시가 컴퓨트 청구서에서 차지하는 비율. 수천 개의 파드에 걸쳐 메시를 운영하는 대기업이나 예산 정밀 조사를 받는 정부 플랫폼에서 이것은 감독 기관이 결국 물을 지출 결정이므로, 세금을 알고 플랫폼 선택이 더 싼 대안을 열어 두는지 아는 것이 기본 실사입니다.
각 클라이언트 부류가 정말 자체의 프런트엔드를 위한 백엔드가 필요합니까, 아니면 실제로는 같은 것을 원하는 클라이언트를 위해 게이트웨이에 로직을 중복시키려는 것입니까? BFF 패턴은 클라이언트 팀을 분리하고 각자 맞춤 계약을 진화시키게 하지만, 새 BFF마다 운영하고, 보호하고, 동기화를 유지할 또 하나의 게이트웨이이며, 그들 사이의 중복된 로직은 조용히 유지보수 세금이 됩니다. 경쟁하는 고려는 팀 자율과 클라이언트별 효율 대 거의 동일한 많은 게이트웨이의 운영 비용과 표류입니다. 클라이언트의 필요가 정말 얼마나 갈라지는지 증거를 가져오십시오. 페이로드 크기, 왕복 횟수, 버전 관리 주기, 단일 공유 게이트웨이 아래서 한 클라이언트의 변경이 다른 클라이언트를 막았을 빈도. 클라이언트 팀이 많은 대규모 조직이나 공개 웹 앱, 모바일 앱, 파트너 통합을 동시에 섬기는 정부 플랫폼에서 정직한 질문은 갈라짐이 확산을 정당화하는가입니다. 모두 같은 모양을 원하는 클라이언트마다의 BFF는 여러 해 유지하는 값을 치를 난립이기 때문입니다.

분야별 관점

스타트업. API 게이트웨이를 출시하고 메시는 건너뛰십시오. 서비스가 몇 개이고 팀이 아주 작다면 단일 게이트웨이가 인증, 속도 제한, 조합을 처리하고, 공유 클라이언트 라이브러리가 컨트롤 플레인 비용의 일부로 mTLS와 재시도를 줍니다. 가장 희소한 자원이 엔지니어링 주의이므로, 운영할 수 없는 메시는 해자가 아니라 부채입니다. 노드 하나가 죽어도 살아남을 만큼 게이트웨이를 중복되게 유지하고, 서비스 수와 언어 다양성이 정말 질문을 강제할 때만 메시를 재검토하십시오.

소기업. 메시를 운영할 플랫폼 팀이 없으니 호스팅 플랫폼이나 게이트웨이 제품이 기본으로 주는 것에 기대십시오. 관리형 TLS, 내장 속도 제한, 직접 패치하는 것이 아닌 호스팅된 게이트웨이입니다. 선택을 사느냐 만드느냐로 구성하고 사십시오. 관리형 API 게이트웨이는 직접 운영할 엔지니어 시간보다 비용이 덜 들기 때문입니다. 내부 서비스 간 암호화를 인력을 대야 하는 프로젝트가 아니라 플랫폼이 제공하는 기능으로 다루십시오.

대기업. 많은 팀과 언어에 걸친 수백 개의 서비스에서 메시는 복잡성만큼 값을 하고, 진짜 일은 거버넌스입니다. 게이트웨이와 메시가 관심사를 이중 처리하지 않도록 하는 하나의 서면 역할 분담, 균일한 mTLS와 텔레메트리, 프록시 업그레이드와 인증서 교체를 소유하는 플랫폼 팀입니다. 감사자는 접근과 암호화의 단일하고 입증 가능한 시행 지점을 원하므로, 인터페이스를 표준화하고 정책을 팀이 다시 구현하지 않고 상속하는 것으로 만드십시오. 사이드카 세금을 실제 예산 항목으로 관리하고, 나중에 더 싼 접근에서 배제되지 않도록 사이드카리스 옵션을 열어 두십시오.

정부. 조달 규칙, 투명성, 공적 책임성이 아키텍처를 형성합니다. 게이트웨이와 메시를 규제 기관이 기대하는 제로 트러스트 백본으로 다루십시오. 모든 시민과 파트너가 정문에서 인증되고, 모든 내부 호출이 워크로드 신원으로 인증되고 암호화되며, 각 시행 지점의 감사 추적이 접근이 어디서 확인되고 트래픽이 어디서 암호화되었는지 증명합니다. 조달 규칙이 금지할 수 있는 독점 종속보다 개방형 표준과 이식 가능한 설정을 선호하고, 적절한 곳에서는 플랫폼이 각 경계를 넘을 때 시민 데이터를 어떻게 보호하는지 공개하십시오.

사례

스타트업. 열두 명 규모의 스타트업이 단일 API 게이트웨이 뒤에서 여덟 개 서비스를 운영합니다. 게이트웨이가 모든 남북 작업을 처리합니다. 토큰 확인으로 사용자를 인증하고, 무료 등급 사용자가 시스템을 압도하지 못하도록 요금제별 속도 제한을 시행하고, 수다스러운 엔드포인트 몇 개를 모바일 친화적인 단일 호출로 조합합니다. 동서 트래픽에는 의도적으로 서비스 메시를 건너뜁니다. 두 언어의 여덟 개 서비스는 컨트롤 플레인을 정당화하지 않기 때문입니다. 대신 공유 클라이언트 라이브러리와 플랫폼의 내장 인증서 관리에서 mTLS와 재시도를 얻고, 가벼운 에이전트로 추적을 수집합니다. 나중에 더 빡빡한 페이로드 필요를 가진 전용 모바일 클라이언트를 추가할 때, 기존 웹 게이트웨이 옆에 모바일 프런트엔드를 위한 백엔드를 도입합니다. 해마다 메시 질문을 재검토하고 아직 값을 할 임계값을 넘지 않았다고 올바르게 결정합니다.

대기업. 한 다국적 은행이 많은 팀과 언어에 걸쳐 수백 개의 서비스를 운영하며, 여기서는 서비스 메시가 복잡성만큼 값을 합니다. 모든 서비스가 기본으로 워크로드 신원과 mTLS를 얻으므로, 어느 팀도 암호화 코드를 쓰지 않고 모든 내부 트래픽이 인증되고 암호화되며, 이는 보안 조직과 단일하고 입증 가능한 시행 지점을 원하는 감사자를 모두 만족시킵니다. 메시는 정책으로 균일한 재시도, 타임아웃, 서킷 브레이킹을 적용하고, 카나리 릴리스를 위해 트래픽을 점진적으로 옮겨 나쁜 배포가 모두에게 닿기 전에 사용자의 1퍼센트에 닿게 합니다. API 게이트웨이 계층이 외부와 파트너 트래픽 앞에 서서 인증, 할당량, 버전 관리를 소유하며, 내부 재시도는 메시에만, 외부 속도 제한은 게이트웨이에만 있다는 단호한 서면 규칙이 있어 두 계층이 요청을 이중 처리하지 않습니다. 모든 프록시의 일관된 텔레메트리가 중앙 관측 가능성 플랫폼에 공급되어, 호출 대기 엔지니어 한 명이 수십 개 서비스 홉에 걸쳐 요청을 추적할 수 있습니다.

정부. 한 국가 세무 기관이 시민 대면 신고 플랫폼을 현대화하며 게이트웨이와 메시를 규제 기관이 요구하는 제로 트러스트 아키텍처의 백본으로 다룹니다. API 게이트웨이가 통제된 정문입니다. 모든 시민과 파트너가 거기서 인증되고 인가되며, 외부 속도 제한이 신고 마감일 급증 중 시스템을 보호하고, 옛 클라이언트 형식은 엣지에서 변환되어 레거시 통합이 계속 동작합니다. 그 뒤에서 서비스 메시가 모든 내부 서비스에 암호학적 신원을 주고 모든 호출에 mTLS를 시행하므로, 네트워크 안에 있다는 이유만으로 신뢰되는 서비스가 없고, 접근 정책은 어느 서비스가 어느 서비스를 호출할 수 있는지 명시적으로 열거합니다. 플랫폼이 복원력을 위해 여러 데이터 센터에 걸치므로, 메시는 같은 신원과 암호화 보장을 클러스터에 걸쳐 확장해 전국에 일관된 제로 트러스트 네트워킹을 줍니다. 모든 시행 지점이 감사 추적을 내보내므로, 기관은 감독 기관에 접근이 어디서 확인되고 트래픽이 어디서 암호화되었는지 정확히 증명할 수 있습니다.

비즈니스 사례: 동기, ROI, TCO

게이트웨이의 수익은 쉽게 보이고 대개 큽니다. 모든 서비스가 인증, 속도 제한, 요청 로깅을 다시 구현하는 대신, 그것들을 엣지에 한 번 만들고 모든 서비스가 상속합니다. 보안 수정이나 새 속도 제한 정책이 백 번이 아니라 한 번의 배포로 출하되어 취약점을 닫는 시간이 짧아지고, 검사할 곳이 하나이므로 모든 감사의 비용이 낮아집니다. 조합과 버전 관리 기능은 클라이언트 왕복을 줄이고 호출자를 깨뜨리지 않고 API를 진화시키게 해, 지연 비용과 팀 간 조율 세금을 모두 줄입니다. 외부 클라이언트가 있는 거의 모든 시스템에서 게이트웨이는 빠르게 본전을 뽑습니다.

서비스 메시는 총소유비용이 실재하고 지속적이므로 더 미묘한 비즈니스 사례를 가집니다. 프록시의 컴퓨트와 지연, 컨트롤 플레인을 운영하는 엔지니어, 새 계층을 디버깅하는 학습 곡선에 값을 치릅니다. 대안(mTLS, 재시도, 텔레메트리의 서비스별, 언어별 구현)이 더 크고, 더 나쁘게는 보안 간극과 장애를 만드는 방식으로 일관되지 않을 때 그 비용이 정당화됩니다. 높은 규모에서 메시는 백 개의 취약한 손수 만든 해법을 하나의 균일하고 입증 가능한 것으로 바꾸며, 수익은 더 적은 보안 인시던트, 트래픽 이동을 통한 더 빠르고 안전한 배포, 극적으로 나은 관측 가능성으로 나타납니다. 그 규모 아래에서는 정직한 계산이 흔히 라이브러리와 게이트웨이를 선호하며, 규율 있는 수는 기다리는 것입니다. 리더십을 설득하려면 게이트웨이를 그들이 이미 추적하는 지표(취약점 시정 시간, 감사 비용, API 조율 오버헤드)에, 메시를 보안 인시던트 봉쇄, 배포 안전성, 그것이 대체하는 다언어 중복의 비용에 연결하십시오.

안티패턴과 함정

필요하기 전의 메시: 서비스가 몇 개일 때 완전한 서비스 메시를 채택해, 아직 없는 문제를 풀려고 컨트롤 플레인을 사는 것.
이중 재시도: 게이트웨이와 메시가 모두 재시도해 클라이언트 호출 하나가 장애를 증폭하는 백엔드 재시도 폭풍으로 곱해지는 것.
타임아웃 역전: 안쪽 타임아웃이 바깥쪽보다 길어, 호출자는 포기하는데 피호출자는 아무도 읽지 않을 응답을 계속 작업하는 것.
모놀리스로서의 게이트웨이: 게이트웨이에 비즈니스 로직을 채워 모든 팀이 바꾸려면 조율해야 하는 공유 병목이 되게 하는 것.
단일 장애점: 중복성 없이 게이트웨이 인스턴스 하나를 운영해, 정문의 실패가 뒤의 모든 서비스를 내리는 것.
네트워크 신뢰: 경계 안의 모든 것을 안전하다고 봐, 침해된 서비스 하나가 옆으로 이동해 모든 것에 닿을 수 있는 것.
겹치는 소유권: 서면 역할 분담이 없어 같은 관심사가 우연히 두 계층에서 처리되고 어느 쪽이 권위 있는지 아무도 모르는 것.
BFF 난립: 클라이언트들이 같은 것을 원하는데 클라이언트마다 프런트엔드를 위한 백엔드를 띄워, 이득 없이 게이트웨이를 늘리고 로직을 중복시키는 것.
사이드카 세금 무시: 컴퓨트와 지연 오버헤드를 측정하지 않고 수천 개의 사이드카를 배포한 뒤 예산이 어디로 갔는지 의아해하는 것.

성숙도 모델

1단계, 시작: 서비스가 공유 계층 없이 서로 직접 대화합니다. 인증, 재시도, 타임아웃이 서비스별로 손으로 코딩되어 일관되지 않습니다. 내부 트래픽은 흔히 평문이며 네트워크에 있다는 이유로 신뢰되고, 정책을 시행하거나 트래픽을 관측할 단일한 장소가 없습니다. 결정은 반응적이며 문제가 드러날 때 서비스별로 이루어집니다.
2단계, 발전: API 게이트웨이가 외부 트래픽 앞에 서서 인증, 속도 제한, 라우팅을 중앙화하지만, 동서 관심사는 고르지 않게 채택된 공유 라이브러리가 처리합니다. 일부 서비스에는 mTLS가 있고 많은 서비스에는 없습니다. 팀들이 남북 대 동서 구분을 인식하지만 소유권은 비공식적이고 실천은 팀마다 다릅니다.
3단계, 표준화: 남북과 동서 관심사가 조직 전체에 적용되는 서면 역할 분담으로 깔끔하게 분리됩니다. 게이트웨이가 외부 신원, 할당량, 조합을 소유하고, 메시나 일관된 라이브러리 계층이 내부 mTLS, 재시도, 텔레메트리를 소유합니다. 겹침이 해소되어 어떤 관심사도 이중 처리되지 않고, 내부 트래픽은 기본으로 암호화되고 신원이 확인되며, 표준은 각 팀의 재량에 맡겨지지 않고 문서화되어 시행됩니다.
4단계, 관리: 트래픽 계층이 기준선에 대해 측정되고 통제됩니다. 컴퓨트와 홉당 꼬리 지연으로 본 사이드카 세금, 오류 예산에 대한 게이트웨이와 메시의 가용성, 재시도 증폭과 타임아웃 역전 인시던트, 내부 호출 중 mTLS 커버리지 비율, 정책 변경을 장치군 전체에 푸시하는 시간을 추적합니다. 지표가 결정을 관문으로 통제합니다. 프록시 업그레이드, 새 재시도 예산, 카나리 규칙은 직관이 아니라 기준선에 대한 데이터로 판단되고, 표준에서의 표류는 수정을 촉발합니다.
5단계, 오케스트레이션: 게이트웨이와 메시가 클러스터와 리전에 걸쳐 모든 홉에서 신원이 확인되는 성숙한 제로 트러스트 아키텍처의 정책 시행 지점입니다. 트래픽 이동이 안전한 점진적 전달을 이끌고, 관측 가능성은 균일하고 풍부하며, 조직은 값을 하는 곳에서 사이드카리스, 프록시리스, eBPF 접근을 지속적으로 평가하고 채택합니다. 트래픽 계층은 보안, 전달, 용량 계획과 통합되어 있고 규모, 언어, 위험 그림이 이동함에 따라 적응합니다.

논의를 위한 아이디어

단일 API 게이트웨이가 지금 내려간다면 몇 개의 서비스에 닿을 수 없게 되며, 정문을 중복되게 만들 계획은 무엇입니까?
시스템에서 현재 게이트웨이와 서비스(또는 라이브러리) 양쪽에서 처리되는 관심사는 무엇이며, 이중 처리되지 않음을 어떻게 입증하겠습니까?
몇 개의 서비스와 언어에서 팀이 메시가 마침내 복잡성만큼 값을 한다고 동의하겠으며, 그 선에서 얼마나 떨어져 있습니까?
공격자가 내일 내부 서비스 하나를 침해한다면, 다른 어느 서비스에 닿을 수 있으며 어떤 신원 확인이 막겠습니까?
사이드카리스나 eBPF 기반 메시 접근이 이미 플랫폼에 쓸 만큼 성숙했으며, 결정하려면 무엇을 측정하겠습니까?
갈라지는 클라이언트 각각이 정말 자체의 프런트엔드를 위한 백엔드가 필요합니까, 아니면 공유로 남을 수 있는 로직을 중복시키려는 것입니까?

핵심 요점

남북 트래픽(API 게이트웨이가 처리)과 동서 트래픽(서비스 메시가 처리)을 분리하십시오. 각자 자기 방향을 소유하며, 둘을 혼동하면 이중 처리가 생깁니다.
게이트웨이는 라우팅, 인증, 인가, 속도 제한, 할당량, 요청 변환, 조합, 버전 관리를 중앙화해 서비스가 얇게 유지되고 정책이 한 곳에 살게 합니다.
서비스 메시는 서비스 코드를 바꾸지 않고, 고전적으로는 사이드카 프록시를 통해 mTLS, 트래픽 이동, 플랫폼 수준의 재시도와 서킷 브레이킹, 균일한 관측 가능성을 줍니다.
서비스와 언어의 수가 서비스별 배선을 더 비싼 길로 만들 때만 메시를 채택하십시오. 그 아래에서는 라이브러리와 게이트웨이가 이기며, 사이드카 세금은 지켜볼 만큼 실재합니다.
게이트웨이와 메시를 제로 트러스트 아키텍처의 정책 시행 지점으로 다루고, 각 횡단 관심사를 정확히 한 계층에 배정하고, 클러스터에 걸쳐 모든 홉에서 신원을 확인하십시오.

참고 문헌과 더 읽을거리

Sam Newman, Building Microservices: Designing Fine-Grained Systems
Chris Richardson, Microservices Patterns: With Examples in Java
Lee Calcote and Zack Butcher, Istio: Up and Running
Ken Owens, Alois Reitbauer, and others; the CNCF Cloud Native Landscape and service mesh documentation
Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
Susan Fowler, Production-Ready Microservices