API 게이트웨이

서버가 한 덩어리로 돌던 시절에는 입구가 하나였습니다. 주소 하나로 요청이 들어오고, 그 앞에서 누구인지 확인하고 기록을 남기면 끝이었습니다. 확인하는 코드도 한 군데에만 있었습니다.

마이크로서비스, 곧 큰 서버 하나를 기능별로 잘게 나눠 따로 돌리는 방식이 퍼지면서 입구가 여러 개가 됐습니다. 문서 서비스와 알림 서비스와 결제 서비스가 각자 주소를 갖고 각자 요청을 받습니다. 그러자 서비스마다 같은 일을 다시 해야 했습니다. 토큰이 유효한지 확인하고, 누가 무엇을 불렀는지 기록하고, 한 사람이 너무 많이 부르고 있지 않은지 세는 일입니다.

페이지덱에서 실제로 생긴 일은 이렇습니다. 태오가 로그인 토큰을 확인하는 방식을 바꾸면서 여섯 개 서비스를 차례로 고쳤는데, 반년 전에 만들어 두고 거의 손대지 않던 서비스 하나를 빠뜨렸습니다. 그 서비스만 옛 방식으로 남았고, 두 달 뒤 이미 지워진 계정의 토큰으로도 그쪽은 응답한다는 사실이 드러났습니다. 같은 코드가 여섯 벌로 흩어져 있으면 여섯 벌이 지금 같은 상태인지 확인할 방법이 없습니다.

게이트웨이는 서비스들 앞에 층을 하나 더 세웁니다. 바깥에서 오는 요청이 전부 이 층을 먼저 지나고, 여기를 통과한 것만 뒤의 서비스로 갑니다. 흩어져 있던 일을 한 자리로 모으는 것이 전부입니다.

그 층이 맡는 일은 넷으로 추려집니다.

1. 인증과 권한 확인 — 토큰이 유효한지, 이 사람이 이 자원을 만져도 되는지를 입구에서 한 번 판정합니다. 뒤의 서비스는 누가 불렀는지를 이미 확인된 값으로 건네받습니다. 규칙이 바뀌면 고칠 곳이 한 군데입니다.
2. 요청 제한 — 한 사람이 정해진 시간에 보낼 수 있는 요청 수를 묶어 둡니다. 연동한 쪽이 실수로 1초에 수천 번을 부르면 뒤의 서비스가 같이 멈추기 때문에, 분당 60회 같은 선을 긋고 넘으면 잠시 거절합니다.
3. 경로 배분 — 어느 주소로 온 요청을 어느 서비스로 넘길지 정합니다. 바깥에서는 주소가 하나로 보이고, 안에서 서비스를 쪼개거나 합쳐도 부르는 쪽 코드는 그대로입니다.
4. 기록과 관측 가능성 — 모든 요청이 한 곳을 지나니 어느 주소가 얼마나 느린지, 오류가 어디에 몰리는지를 한 화면에서 봅니다. 서비스마다 다른 형식으로 남기던 기록이 같은 형식이 됩니다.

얻는 것은 두 갈래입니다. 공통 처리가 한 벌로 줄어드는 것이 하나이고, 바깥에 드러나는 주소 구조와 안쪽의 서비스 구조가 서로 묶이지 않는 것이 다른 하나입니다. 뒤엣것 덕분에 서비스를 둘로 쪼개는 작업이 연동한 회사들에 통보 없이 끝납니다.

게이트웨이가 늘 정답은 아닙니다. 층을 하나 더 두는 값이 있기 때문입니다.

1. 두지 않기 — 서비스가 둘셋이고 부르는 쪽이 우리 웹 화면뿐이면 층을 더하는 손해가 큽니다. 게이트웨이도 서버라서 배포하고 지켜보고 장애를 받아야 합니다. 게다가 모든 요청이 지나가는 자리라 여기가 멈추면 전부 멈춥니다.
2. 로드 밸런서 — 같은 서비스를 여러 대 띄워 놓고 요청을 고르게 나눠 주는 장치입니다. 주소 앞부분을 보고 어느 서비스로 보낼지 가르는 정도까지는 이쪽으로도 됩니다. 토큰을 풀어 보거나 사람별로 횟수를 세는 것처럼 요청의 내용을 판단해야 하는 일은 하지 못합니다.
3. 공용 라이브러리 — 인증과 기록 코드를 한 덩어리로 묶어 서비스마다 가져다 씁니다. 코드는 한 벌이지만 배포 시점이 서비스마다 다르면 실제로 도는 버전은 다시 흩어집니다. 서비스들이 서로 다른 언어로 쓰였다면 라이브러리도 언어 수만큼 필요합니다.
4. 서비스 메시 — 서비스끼리 주고받는 통신을 대신 맡아 주는 층입니다. 게이트웨이가 바깥에서 안으로 들어오는 길목을 지킨다면 이쪽은 안에서 안으로 오가는 길을 맡습니다. 둘은 바꿔 쓰는 관계가 아니라 같이 두는 관계에 가깝습니다.

고르는 기준은 서비스 수보다 부르는 쪽이 누구인지입니다. 우리 화면만 부른다면 두지 않는 쪽이 오래 편하고, 바깥 회사가 붙기 시작하면 그때부터는 입구가 하나여야 합니다.

"그 검사는 서비스마다 넣지 말고 게이트웨이로 올립시다."

같은 코드가 여러 벌로 흩어지기 전에 공통 층으로 옮기자는 제안입니다.

"게이트웨이가 죽으면 전부 죽어요. 이중화부터 하고 넘어갑시다."

한 곳으로 모은 대가로 생긴 위험을 먼저 처리하자는 말입니다.

"외부 연동은 게이트웨이로만 받고 내부 호출은 직접 부르게 둡시다."

바깥에서 오는 요청과 안에서 오는 요청을 다른 길로 가르자는 뜻입니다.

페이지덱이 게이트웨이를 들인 계기는 기능 요구가 아니라 앞의 토큰 사고였습니다. 태오는 먼저 인증만 입구로 올렸습니다. 나머지는 그대로 두고 한 가지만 옮기면 문제가 생겼을 때 어디를 볼지가 분명하기 때문입니다. 두 주 뒤 요청 제한을 올렸고, 기록 형식을 맞추는 일은 그다음 분기로 미뤘습니다.

옮기지 않기로 한 것도 있습니다. 문서 하나를 누가 볼 수 있는지 판정하는 규칙은 문서 서비스에 그대로 뒀습니다. 그 판정에는 문서의 공유 설정과 소속 팀을 알아야 하는데, 그런 것까지 입구가 알기 시작하면 입구가 두 번째 서버로 자라납니다.

게이트웨이를 두면 뒤의 서비스는 보안을 신경 쓰지 않아도 된다고 여기는 경우가 많습니다. 모든 요청이 입구를 지나니 안쪽은 이미 안전한 구역처럼 보입니다. 하지만 안쪽 서비스끼리 서로를 부를 때는 입구를 지나지 않고, 운영 중에 임시로 열어 둔 내부 주소나 잘못 설정된 방화벽 규칙도 입구를 건너뜁니다. 서비스가 자기 앞에 온 요청을 스스로 한 번 더 확인하지 않으면, 안쪽에 발을 들인 누군가가 그다음부터는 아무 문을 열 수 있습니다.

게이트웨이에 처리 로직을 계속 얹는 것도 흔한 길입니다. 모든 요청이 지나가는 자리라 무엇이든 여기서 처리하면 빠르고 편해 보입니다. 그러다 응답을 합치고 값을 계산하고 예외를 처리하는 코드가 쌓이면, 쪼개려고 만든 구조 앞에 아무도 건드리지 못하는 덩어리가 다시 생깁니다. 입구는 요청을 판정하고 넘기는 데까지만 맡고, 무엇을 어떻게 계산할지는 뒤의 서비스가 쥐고 있어야 쪼갠 이유가 남습니다.