마이크로서비스

모든 코드가 한 덩어리에 담겨 있던 시절에는 알림 문구 한 줄을 고쳐도 제품 전체를 다시 올려야 했습니다. 결제와 문서 저장과 알림이 같은 프로그램 안에 있어 서버에 올리는 묶음도 하나뿐이었습니다. 이 구조를 모놀리스라고 부릅니다.

그래서 배포일 저녁은 늘 같은 모양이었습니다. 알림 담당자가 오타 하나를 고쳐 두고도 결제 담당자의 작업이 끝날 때까지 기다렸고, 열한 시에 함께 올린 뒤 문제가 나면 누구의 변경 때문인지 찾느라 새벽까지 남았습니다. 서비스가 커질수록 한 번 올리는 데 딸린 사람이 늘어나 배포 주기는 주 단위에서 월 단위로 밀렸습니다.

마이크로서비스는 이 묶음을 풀려고 나온 구조입니다. 기능마다 프로그램을 따로 두고 각자 따로 올릴 수 있게 하면, 알림을 고친 사람은 알림만 올리고 나머지는 자기 일정을 지킵니다.

기능 단위로 프로그램을 나누고, 나뉜 것끼리는 API를 통해서만 말을 겁니다. API 는 무엇을 어떻게 주고받을지 미리 약속해 둔 창구입니다. 같은 프로그램 안이었다면 함수를 바로 불렀을 자리가 여기서는 "주문 서비스가 결제 서비스에 요청을 보내고 답을 기다린다" 는 모양으로 바뀝니다.

한 조각이 서비스로 성립하려면 네 가지를 자기 것으로 가져야 합니다.

1. 경계 — 하나의 서비스는 한 업무만 맡습니다. 결제 서비스는 결제만 알고 문서 저장은 모릅니다.
2. 데이터 — 서비스마다 데이터베이스를 따로 둡니다. 결제 서비스가 문서 쪽 표를 직접 읽으면 나눈 의미가 사라지니, 필요하면 문서 서비스에 물어서 받습니다.
3. 배포 — 올리는 시점을 서비스마다 따로 정합니다. 알림 서비스를 하루에 세 번 올리는 동안 결제 서비스는 지난달 버전으로 그대로 돌 수 있습니다.
4. 규모 — 서버 대수도 서비스마다 따로 정합니다. 문서 저장에 요청이 몰리면 그쪽만 열 대로 늘리고 결제는 두 대로 둡니다.

실제로 굴릴 때는 서비스마다 컨테이너를 만들어 올립니다. 컨테이너는 프로그램과 실행에 필요한 것을 함께 묶어 어느 기계에서나 같은 모양으로 돌게 한 단위입니다. 서비스가 스무 개로 늘고 각각이 세 대씩 쓰면 컨테이너는 예순 개가 되는데, 어디에 몇 개를 띄우고 죽은 것을 어디에 다시 띄울지는 사람이 따라갈 수 없습니다. 그래서 오케스트레이션 도구에 그 판단을 맡깁니다.

세 가지 조건 가운데 하나가 걸릴 때 이 구조로 갑니다.

첫째는 배포 속도입니다. 팀이 여럿이고 각자 다른 기능을 매일 올리고 싶은데 배포 묶음이 하나라서 서로를 기다리는 상황이면 나눌 이유가 생깁니다. 다섯 서비스로 나눈 팀은 하루에 다섯 번을 서로 상관없이 올립니다.

둘째는 수평 확장입니다. 서버 대수를 늘려 부하를 버티는 방식인데, 한 덩어리 구조에서는 어느 기능 때문에 몰리든 전체를 함께 늘려야 합니다. 검색 요청이 평소의 열 배로 뛰었을 때 검색만 열 대로 늘리고 결제는 두 대로 두면 서버 비용이 그만큼 덜 나갑니다.

셋째는 팀 구조입니다. 콘웨이의 법칙은 시스템 구조가 조직의 소통 구조를 닮는다는 관찰인데, 이 구조는 그 관찰을 거꾸로 씁니다. 팀 하나가 서비스 하나를 처음부터 끝까지 맡게 해 두면 팀 사이에 오가야 할 말이 줄어듭니다.

어디를 잘라 서비스로 만들지는 도메인 주도 설계가 다룹니다. 데이터베이스 표 모양이 아니라 업무에서 둘을 다르게 부르는지를 기준으로 경계를 긋는 방법입니다. 다만 구성원 마흔다섯 명 규모에서 처음부터 이 구조로 가는 경우는 드뭅니다. 다섯으로 나누면 배포와 감시도 다섯 벌이 필요해서, 사람이 늘기 전에 나누면 관리 비용이 먼저 옵니다.

"이번 건은 알림 서비스만 올리면 되니까 결제 쪽 배포를 기다릴 필요 없어요."

배포 묶음이 갈려 있으니 다른 팀 일정에 걸리지 않는다는 말입니다.

"그건 경계를 잘못 그은 겁니다. 기능 하나 고치는데 서비스 셋을 같이 올리고 있잖아요."

나누기는 했지만 경계가 업무와 어긋나 나눈 이점이 사라졌다는 지적입니다.

"우리 규모에서는 마이크로서비스까지 갈 필요 없고 모듈만 갈라 두죠."

지금 팀 크기에서는 나누는 비용이 얻는 것보다 크다는 판단입니다.

페이지덱은 문서 편집·검색·알림·결제 네 서비스로 나뉘어 있습니다. 태오는 검색 쪽을 맡아 하루에 두 번씩 올리지만 결제나 알림은 건드리지 않습니다. 지난달 검색이 삼십 분 멈춘 날에도 문서 편집은 그대로 돌아서 사용자 대부분은 검색창만 안 된다고 느꼈습니다.

나눈 뒤에 새로 생긴 일도 있습니다. 알림 서비스가 느려진 날에는 문서 저장은 됐지만 알림이 몇 분 늦게 가는 상태가 생깁니다. 지현은 이런 어긋남이 사용자에게 어떻게 보일지를 기획 단계에서 정해 둡니다.

마이크로서비스를 모놀리스보다 앞선 구조로 읽는 경우가 가장 많습니다. 이름이 널리 알려진 회사들이 이 구조를 쓰고 있으니 자연스러운 오해입니다. 하지만 이것은 발전 단계가 아니라 교환입니다. 배포와 확장의 자유를 얻는 대신, 같은 프로그램 안에서는 실패할 일이 없던 함수 호출이 응답이 늦거나 아예 오지 않을 수 있는 네트워크 통신으로 바뀝니다. 팀이 셋인데 서비스를 열두 개로 나누면 배포 절차와 감시 대상도 열두 벌이 되고, 장애가 나면 어디서 시작된 일인지 찾는 데 하루가 갑니다. 이 상태를 버티려면 관측성, 즉 밖에서 안의 상황을 알아볼 수 있게 만드는 장치를 먼저 갖춰야 합니다.

나눠 두면 장애가 번지지 않는다는 생각도 자주 어긋납니다. 서비스가 따로 도니 하나가 죽어도 나머지는 살아 있을 것 같지만, 다섯 서비스가 같은 데이터베이스 한 대를 보고 있으면 그 한 대가 단일 장애점입니다. 나눴다는 사실만으로 안전해지지 않으니, 멈추면 전체가 멈추는 자리를 나눈 뒤에 다시 찾아야 합니다.