Pipeline
운영자가 어드민에서 자료를 골라 변환 버튼을 누르면, 어드민이 변환 솔루션을 직접 호출해 이미지와 PDF를 만드는 기능이었습니다. 한 건씩 걸면 늘 됐습니다. 그런데 한 번에 수백 건을 걸면 되는 것과 안 되는 것이 섞였고, 무엇이 안 됐는지도 남지 않았습니다. 제가 왜 대량에서만 깨지는지를 여덟 단계로 나눠 조사해 문제 20건을 뽑고, 접수와 처리를 끊는 변환 시스템을 따로 만들었습니다.
운영자가 자료를 하나씩 걸면 변환은 늘 됐습니다. 그런데 한 번에 수백 건을 걸면 되는 것과 안 되는 것이 섞이고, 무엇이 안 됐는지는 아무도 몰랐습니다. 운영자가 다시 걸어도 또 일부만 됐습니다. 같은 기능인데 규모가 커지는 순간 다르게 굴었습니다.
| 한 건씩 걸 때 | 수백 건을 한 번에 걸 때 | |
|---|---|---|
| 변환 결과 | 건 상관없이 다 됩니다 | 되는 것과 안 되는 것이 섞입니다 |
| 걸리는 시간 | 한 건에 10초에서 30초 | 서로 밀려 60초를 넘기고 끊깁니다 |
| 안 됐을 때 | 운영자가 화면에서 바로 압니다 | 무엇이 안 됐는지 아무 데도 안 남습니다 |
| 다시 걸면 | 그대로 됩니다 | 또 일부만 되고, 부하만 더 늘어납니다 |
한 건씩 걸 때 안 보이던 것이 수백 건에서 드러납니다. 누가 무엇을 해서 다음이 어떻게 되는지 한 단계씩 이어보면 이렇습니다.
마지막 단계가 첫 단계로 돌아갑니다. 시스템이 힘들 때 운영자가 더 세게 누르는 방향으로 도는 고리였습니다. 게이트웨이 타임아웃 한도를 늘리는 건 이 고리 중 한 칸을 잠시 미루는 것뿐이라, 제가 구조를 건드리는 쪽으로 갔습니다.
10% 미만
어드민에 504가 쏟아지는 동안 변환 솔루션 서버 CPU
서버가 터질 듯이 돌다 뻗은 게 아닙니다. 과부하로 생긴 일이 아니었습니다
60ms
어드민이 6건을 동시에 던졌을 때 솔루션이 전부 끝낸 시간
여섯 건이 다 같이 끝납니다. 솔루션이 줄을 안 세우고 다 받는다는 뜻입니다
11건
솔루션이 60초를 넘기기 시작하는 동시 호출 수
한 코어를 나눠 쓰며 다 같이 느려지므로 묶음이 통째로 끊깁니다
504 가 대량으로 나면 보통 서버가 감당을 못 하고 있다고 봅니다. 그런데 변환 솔루션 서버는 그 시간 내내 CPU 가 10% 를 넘지 않았습니다. 미친 듯이 돌다가 뻗은 게 아니라 거의 놀고 있었습니다. 솔루션이 올라간 IIS 가 코어 하나만 쓰도록 잡혀 있어서, 요청은 그 한 코어에 다 몰리고 나머지 코어는 그대로 남아 있었습니다. 그래서 증설은 답이 아니었습니다. 장비를 늘려도 IIS 는 여전히 코어 하나만 씁니다. 여기에 IIS 스레드가 다 차서 뒤의 요청이 밀린 것도 겹쳤다고 봅니다. 이 부분은 확인하지 못해 추정으로 남겨둡니다.
제가 변환이 도는 과정을 여덟 단계로 나누고, 단계마다 무엇이 잘못될 수 있는지를 코드와 실제 운영 기록으로 확인했습니다. 여기에 개발자가 감춰둔 화면을 열어 운영자가 600건을 한꺼번에 돌리면 어떻게 되는지를 가정한 시나리오도 하나 더 봤습니다.
| 뿌리 | 건수 | 결과 |
|---|---|---|
| 어드민이 변환 솔루션에 한 번에 몇 건을 보낼지 아무도 정해두지 않았다 | 3 | 해결 |
| 게이트웨이가 60초에 연결을 끊으면 어드민이 하려던 나머지 단계가 통째로 사라졌다 | 4 | 해결 |
| 어드민은 변환이 실패하면 기록을 아무 데도 남기지 않았다 | 4 | 해결 |
| 운영자가 버튼을 한 번 누르면 이미지 변환과 PDF 변환이 한 호출에 붙어 나갔다 | 4 | 해결 |
| 어드민이 재변환할 때 지우고 새로 넣는데, 넣기가 실패해도 예외가 안 나 멀쩡하던 자료까지 사라졌다 | 2 | 해결 |
| 어드민 화면이 운영자에게 사실과 다른 상태를 보여줬다 | 3 | 2건 해결, 1건 일부 |
제가 번호순으로 훑지 않고 뿌리별로 묶은 게 이 단계에서 가장 중요했습니다. 하나씩 찾아 고치는 게 아니라 구조를 바꿔서 그 문제가 생기던 상황 자체를 없애는 방향이었기 때문에, 묶어서 봐야 무엇이 왜 풀리는지가 보입니다.
다섯 번째가 조사에서 제일 급했습니다. 자료가 실제로 없어지는 자리는 여기 하나뿐이었습니다. 재변환은 이미 잘 되어 있는 자료에 하는 작업인데, 넣기가 실패해도 코드가 예외를 안 던지고 오류 코드만 담아 정상으로 끝나서 데이터베이스가 되돌릴 계기를 못 얻습니다. 지운 것만 확정되고 그 자료는 다시 성공할 때까지 서비스에서 빈 상태로 보입니다.
접수
어드민의 요청을 받아 작업 목록에 적고 바로 응답한다. 이 자리에서 솔루션을 부르지 않는다
처리
워커가 적어 둔 작업을 꺼내 솔루션을 부른다. 어드민 요청과 떨어져서 돈다
유량 제어
워커가 솔루션에 동시에 거는 호출 수를 정한 값 안으로 묶는다
기록
변환 시스템이 작업이 아니라 시도 단위로 남긴다. 실패한 시도도 남는다
넷은 서로를 대신하지 않습니다. 접수와 처리를 떼어놓고 상한을 안 걸면 여전히 들어온 만큼 그대로 솔루션으로 나가고, 셋을 다 갖춰도 시도 단위로 안 남기면 무엇이 왜 실패했는지는 그대로 모릅니다. 앞의 연쇄에서 한 칸만 막아서는 고리가 안 끊어지기 때문에 넷을 같이 갖춰야 했습니다.
운영자 ──▶ 어드민 ──▶ 게이트웨이 ──▶ 변환 솔루션
동기 호출 · 600건 60초에 끊음
게이트웨이가 끊으면 → 어드민이 하려던 뒷일이 전부 사라짐어드민 ──▶ 접수 ──▶ 작업 테이블
│ 워커가 SKIP LOCKED 로
│ 한 건씩 집어간다
▼
워커 N ──▶ 변환 솔루션
│
▼
배달 ──▶ API 서비스 (요청자가 준 주소)
게이트웨이가 끊어도 → 워커는 계속 돈다어드민은 작업 행만 남기고 즉시 끝납니다. 운영자가 몇 건을 넣든 어드민의 응답 시간은 접수에 걸리는 시간뿐이고, 변환은 워커가 자기 속도로 가져갑니다. 제가 게이트웨이 타임아웃을 없앤 게 아니라 결과를 잃지 않는 위치로 옮긴 것에 가깝습니다. 솔루션에 동시에 거는 호출 수는 워커 스레드 수로 정해지고, 작업 목록에서 나가는 길이 워커 하나뿐이라 어드민 말고 다른 채널이 붙어도 솔루션이 받는 양은 그대로입니다.
전에는 변환 요청이 어드민 화면에서만 들어왔습니다. 운영자가 화면에서 버튼을 눌러야 시작되고, 그 화면을 거치지 않은 변환은 결과가 적힐 자리도 없었습니다. 어드민 화면이 유일한 입구이자 유일한 저장 경로였습니다. 처리를 별도 서비스로 떼어낸 김에, 어느 쪽에서 불러도 변환이 되게 바꿨습니다.
| 전 | 후 | |
|---|---|---|
| 입구 | 변환 요청이 어드민 화면에서만 들어온다 | 채널 키를 가진 쪽이면 어디서든 접수할 수 있다. 채널은 자격증명에서 정해지고 요청자가 고칠 수 없다 |
| 결과 받기 | 어드민이 자기가 부른 응답을 그 자리에서 읽는다 | 채널이 접수할 때 결과 받을 주소를 같이 준다. 변환 시스템은 그 주소로 보내주기만 한다 |
| DB 반영 | 결과를 적는 코드가 어드민 화면 안에 있다 | 그 코드를 API 서비스로 꺼냈다. 어느 채널이 요청했든 결과가 이 한 곳으로 모인다 |
셋 중 뒤의 둘이 이 절 다음에 나오는 배달 API 와 API 서비스입니다. 채널을 늘리려면 결과를 어디로 보낼지와 그것을 누가 적을지가 같이 풀려야 해서, 세 자리를 따로 고칠 수가 없었습니다.
채널은 접수할 때 쓰는 키에서 정해집니다. 요청 본문에도 채널 이름이 있지만 그건 자기 신고라, 키와 어긋나면 접수가 거절합니다. 이 값이 작업과 묶음에 남고 중복 차단 키 앞에도 붙습니다. 채널마다 자료 번호 체계가 달라서 같은 번호가 다른 자료일 수 있기 때문입니다.
지금 등록된 채널은 하나입니다. 다만 늘릴 자리를 만들어 둔 것과, 늘릴 때마다 변환 시스템을 고쳐야 하는 것은 다릅니다. 설정에 키를 한 줄 더 적으면 되도록 해뒀습니다.
접수하고 바로 응답하는 순간, 요청한 쪽은 변환이 언제 끝나는지 모르게 됩니다. 물어보러 오는 길은 열어 뒀지만, 그것만 두면 채널마다 폴러를 하나씩 만들어 붙여야 합니다. 그래서 변환이 끝나면 변환 시스템이 요청한 쪽을 불러주는 길을 더했습니다. 이 콜백을 배달이라고 부릅니다. 접수할 때 주소를 준 건은 변환 시스템이 보내주고, 안 준 건은 요청한 쪽이 조회로 물어 갑니다.
여기서 정할 게 하나 더 있었습니다. 변환이 끝났을 때 누구를 부를지를 누가 아느냐입니다.
요청자가 어느 채널인지 변환 시스템이 가려서, 채널마다 정해둔 수신 API 를 부릅니다.
바뀌면 채널이 늘 때마다 변환 시스템에 분기가 붙습니다. 어느 채널이 수신 주소를 바꾸면 변환 시스템을 고치고 배포 일정까지 맞춰야 합니다.
채널이 접수할 때 변환이 끝나면 이 주소를 불러 달라고 같이 넘깁니다. 변환 시스템은 그 주소를 그대로 부르고 자기 일을 마칩니다.
바뀌면 변환 시스템은 손대지 않습니다. 주소를 바꾸려는 채널이 자기가 넘기는 값만 바꾸면 됩니다.
변환 시스템이 채널을 가려 분기하면, 채널이 늘 때마다 분기가 붙고 어느 채널이 수신 주소를 바꿀 때마다 제가 변환 시스템을 고치고 배포 일정을 맞춰야 합니다. 주소를 요청서에 담게 하면 변환 시스템은 결과가 어디로 가는지 모르는 채로 남습니다. 모르는 편이 낫습니다. 몰라야 채널이 늘어도 안 고칩니다.
결과를 적는 코드가 원래 어드민 화면 안에 묻혀 있었습니다. 그래서 어드민 화면을 거치지 않은 변환은 적힐 자리가 없고, 그 행이 안 생기면 후처리가 시작되지 않아 변환은 끝났는데 화면에는 아무것도 안 뜹니다. 그 저장 로직을 화면에서 떼어내, 이미 돌고 있던 API 서비스에 엔드포인트 하나로 올렸습니다.
어드민 안에도 받는 자리를 만들 수 있었지만 성격이 다릅니다. 어드민은 사람이 화면으로 쓰는 것이고 이 자리는 변환 시스템이 부르는 창구라, 배포 주기도 열어야 하는 망도 다릅니다. 어드민을 배포하느라 잠깐 내리는 동안에도 변환은 계속 돌고 결과는 받아야 합니다. 이미 도는 프로젝트에 엔드포인트가 하나 느는 것이라 배포 대상도 늘지 않았습니다.
접수와 처리를 끊고 나면 조회가 따로 필요해집니다. 기록은 쌓기만 해서는 밖에서 볼 수 없으니 읽어 내주는 자리가 있어야 합니다. 그래서 변환 시스템 안의 경계가 셋입니다. 결과를 받아 어드민 DB 에 적는 일은 이 시스템 밖, API 서비스가 합니다.
convert/ 변환 시스템 하나. 서비스로 더 쪼개지 않았다├── accept/ 접수. 작업 행을 넣고 끝난다. 솔루션을 부르지 않는다├── process/ 처리. 워커가 작업을 집어 솔루션을 부르고 결과를 배달한다├── query/ 조회. 읽기만 한다. 상태를 바꾸는 포트가 아예 없다├── store/ 저장소 어댑터. 경계 셋이 이걸 거쳐 같은 테이블을 본다└── domain/ 묶음, 작업, 시도
셋을 각각 별도 서비스로 쪼갤 수도 있었습니다. 그 선택은 하지 않았습니다. 셋이 같은 저장소를 보는데 서비스만 셋으로 나누면 운영 대상만 늘고 얻는 게 없습니다. 물량이 그만큼 크지도 않았습니다.
process/ 예로 처리 경계를 연 것├── schedule/ 워커. 주기마다 스스로 돈다├── web/ 밖에서 들어오는 자리├── service/ in 포트 구현├── port/in/ 이 경계가 할 수 있는 일└── port/out/ 이 경계가 쓸 수 있는 것. 여기서 권한이 갈린다
셋 다 같은 모양이고, 갈리는 건 port/out 에 무엇이 들어 있느냐입니다. 조회 경계에는 조회 포트 셋만 있습니다. 상태를 바꾸는 포트가 아예 없으니, 조회 경로에서 상태를 바꾸는 코드는 리뷰어가 아니라 컴파일러가 막습니다.
게이트웨이가 504를 줬다고 해서 솔루션의 변환이 실패했다는 뜻은 아닙니다. 게이트웨이가 기다리기를 그만뒀을 뿐, 솔루션은 그 뒤로도 변환을 끝냅니다. 그래서 제가 실패로 보내지 않고 자리를 둘 두었습니다. 먼저 짧게 다시 시켜 보는 재시도 대기, 그 여력이 다 떨어지면 캐시로 결과만 묻는 결과 미확정입니다.
둘을 가른 이유는 솔루션에 시키는 일이 다르기 때문입니다. 재시도는 변환을 처음부터 다시 시키는 것이고, 확인은 캐시로 묻기만 해서 새 변환을 만들지 않습니다. 오래 걸리는 자료를 계속 재시도로 찌르면 부하만 늘고 또 504를 받습니다. 그래서 여력이 남았을 때는 짧게 다시 시키고, 소진되면 묻기만 하는 쪽으로 옮깁니다.
확인 한도를 넘기면 추적을 포기한 것으로 남기는데, 이것도 실패와는 갈라 둡니다. 실패는 안 됐다는 게 확인된 것이고, 추적 포기는 됐는지 안 됐는지 모르는 것입니다. 둘을 섞으면 실제로는 있는 결과를 없는 것으로 보고 버리게 됩니다.
문제 어드민이 변환 솔루션을 동기로 호출했습니다. 요청을 받은 스레드가 응답까지 붙잡혀 있어서, 게이트웨이가 60초에 끊으면 어드민이 그 뒤에 하려던 일이 전부 사라졌습니다.
해결 변환 처리를 어드민 안에 두지 않고 별도 서비스로 떼어냈습니다. 어드민은 작업 행을 넣고 바로 끝납니다.
왜 어드민은 화면 수정으로 수시로 배포되는 쪽이라, 안에 두면 배포할 때마다 진행 중인 변환이 끊깁니다. 결정적인 건 어드민이 여러 파드로 뜬다는 점입니다. 파드마다 처리가 돌면 동시 호출 상한을 걸어도 파드 수만큼 곱해져 유량 제어가 성립하지 않습니다.
문제 변환 시스템을 떼고 나니 이 시스템이 어드민 DB 를 봐도 되는지를 정해야 했습니다. 보게 하면 결과를 그 자리에서 바로 적을 수 있어 훨씬 간단합니다.
해결 안 보기로 했습니다. 변환 시스템은 자기 테이블 셋만 봅니다. 어드민 DB 에 적는 일은 결과를 받은 API 서비스가 합니다. 스키마와 계정도 갈라 뒀습니다.
왜 어드민 소유 테이블을 바깥 배치가 직접 고치는 것이 조사에서 나온 문제 중 하나였습니다. 그게 문제라고 적어 놓고 같은 모양을 새로 만들 수는 없었습니다. 계정을 가른 건 문서로 약속하는 대신 권한이 막게 하려는 것입니다. 변환 시스템은 이렇게 변환됐다는 사실만 전하고, 그걸 어느 칸에 어떻게 적을지는 API 서비스가 정합니다.
문제 운영자가 같은 자료를 두 번 걸면 솔루션이 같은 변환을 두 번 합니다. 조회해서 없으면 등록하는 방식으로는 같은 순간에 들어온 두 요청을 막지 못합니다.
해결 진행 중일 때만 값이 붙는 컬럼 하나에 유일 인덱스를 걸었습니다. 종료 상태로 가면 그 값을 비웁니다.
왜 유일 인덱스는 빈 값의 중복을 허용합니다. 그래서 값을 비우는 것만으로 진행 중인 것만 유일하다는 규칙이 DB 레벨에서 강제됩니다. 정작 까다로웠던 건 키를 언제 푸느냐였습니다. 성공이든 실패든 종료 상태면 다 풀어서 재변환을 막지 않습니다. 다만 결과 미확정은 종료가 아니라 계속 붙들고 있습니다. 솔루션이 아직 변환을 돌리고 있을 수 있는데 키를 풀면, 같은 자료가 다시 접수되어 같은 일을 두 번 시킵니다.
문제 게이트웨이가 504 를 주면 변환 시스템은 그 작업이 실패한 것인지 알 수 없습니다. 응답을 못 받았을 뿐, 솔루션은 변환을 끝냈을 수도 있습니다.
해결 504 를 실패로 보내지 않고 두 단계로 나눴습니다. 먼저 짧은 간격으로 몇 번 다시 시켜 보고, 그 여력이 다 떨어지면 결과 미확정으로 옮겨 이제는 캐시로 결과만 묻습니다. 물어도 끝내 답이 없으면 추적 포기로 남깁니다.
왜 응답을 못 받은 것과 작업이 실패한 것은 다릅니다. 둘을 같게 다루면 이미 끝난 작업을 다시 돌리거나, 끝나지 않은 작업을 끝난 것으로 처리하게 됩니다. 두 단계로 나눈 건 재시도와 확인이 솔루션에 시키는 일이 다르기 때문입니다. 재시도는 변환을 처음부터 다시 시키는 것이고, 확인은 캐시로 묻기만 해서 새 변환을 만들지 않습니다. 오래 걸리는 자료를 계속 재시도로 찌르면 부하만 늘고 또 504 를 받습니다.
문제 운영자가 어드민 화면에서 30건을 걸면, 어드민이 변환 시스템의 진행률 API 를 몇 초마다 불러 진행바를 그립니다. 진행바는 어드민 화면에 있지만 그 숫자를 무엇으로 셀지는 변환 시스템이 정합니다. 변환이 끝난 것만 세면, 결과를 아직 아무 데도 안 보낸 건까지 완료가 됩니다. 진행바는 30 중 30 인데 정작 서비스 화면에는 이미지가 아직 안 뜹니다.
해결 변환 시스템이 그 건에 대해 자기 할 일이 남았는지로 셉니다. 결과를 보낼 주소를 받았으면 보내주기까지가 할 일이고, 주소가 없으면 변환이 끝난 것이 곧 할 일의 끝입니다. 그래서 변환 시스템이 내주는 완료 수는 변환에 성공한 수에서 아직 안 보낸 수를 뺀 값입니다.
왜 완료를 더 뒤로 잡을 수도 있습니다. 실물 이미지가 서비스 화면에 떴는지까지요. 그게 운영자가 진짜 궁금한 것이기도 합니다. 그런데 그건 어드민 DB 값이라 변환 시스템이 아예 볼 수가 없습니다. 볼 수 없는 것을 완료 기준으로 삼으면 그 칸은 영영 안 채워집니다. 그래서 자기가 한 일까지만 세고, 그 뒤는 어드민 화면이 자기 값으로 보여주게 뒀습니다.
앞의 판단이 무엇을 어디에 둘지의 문제였다면, 여기는 다 만들어 놓고 돌려보면서 하나씩 나온 것들입니다. 워커가 둘 이상이 되는 순간, 그리고 그중 하나가 죽는 순간 에 생기는 일이 대부분입니다.
워커 인스턴스가 여럿이면 같은 작업을 동시에 집어갑니다.
처리 워커가 FOR UPDATE SKIP LOCKED 로 작업 행을 선점합니다. 다른 워커가 잠근 행은 기다리지 않고 건너뜁니다.
왜 큐 미들웨어를 따로 들이지 않고도 인스턴스가 몇이든 중복 없이 나눠 가집니다. 기다리지 않는다는 게 핵심이라, 장수 많은 파일 한 건이 도는 동안에도 다른 워커는 줄 서지 않고 다음 건을 가져갑니다.
워커가 한 번에 여러 건을 집어두면 뒤쪽 건은 자기 차례가 올 때까지 처리 중 딱지만 답니다.
처리 워커가 한 번에 한 건만 집습니다.
왜 미리 집어두면 아래의 좀비 판정이 기다린 시간까지 처리 시간으로 세어, 시작도 안 한 건을 되돌립니다. 한 건씩 집으면 선점 시각이 곧 처리 시작 시각이라 판정 기준이 건당 최대 소요 하나로 줄어듭니다.
워커가 작업을 집은 채로 죽으면 그 행은 처리 중인 채로 박제됩니다. 아무도 다시 집지 않습니다.
처리 처리 중인 채로 정해둔 시간을 넘긴 행을 유지보수가 대기로 되돌립니다. 다음 워커가 그걸 집어갑니다.
왜 기준값은 건당 최대 소요보다 넉넉히 잡았습니다. 짧게 잡으면 멀쩡히 돌던 건을 죽은 것으로 보고 되돌려, 솔루션에 같은 일을 두 번 시킵니다.
좀비 복구가 되살린 건을 다른 워커가 집어간 사이, 원래 워커가 뒤늦게 결과를 저장하면 그 위에 덮어씁니다.
처리 워커가 저장 직전에 그 행을 다시 잠가서 읽고, 아직 자기 것인지 확인합니다. 이 자리에서는 SKIP LOCKED 를 쓰지 않습니다.
왜 선점과 확인은 같은 잠금처럼 보이지만 건너뛰었을 때 뜻이 반대입니다. 선점에서 건너뛰는 건 남이 가져갔으니 다음 걸 본다는 뜻이라 맞지만, 확인에서 건너뛰면 확인을 못 했다는 것이 내 것이 맞다로 통과해버립니다.
워커를 주기 실행으로 돌렸더니, 요청이 안 끊기고 들어오는 동안 실제로 도는 워커가 하나로 줄었습니다.
처리 주기 실행을 걷어내고 워커마다 무한 루프를 돌립니다. 집을 게 있으면 처리하고 없으면 잠깐 자고 다시 봅니다.
왜 틱에는 시작과 끝이 있습니다. 빈 손을 본 워커는 그 틱에서 나가는데 다시 띄울 기회는 틱이 끝날 때뿐이고, 작업이 계속 들어오면 틱이 안 끝납니다. 틱이 안 끝나니 요약 로그를 찍을 자리도 없어 눈에 띄지도 않습니다.
워커가 여럿이면 같은 결과를 두 번 배달할 수 있습니다.
처리 배달은 선점과 처리를 나누지 않고 한 트랜잭션 안에서 끝냅니다. 잠금이 배달이 끝날 때까지 유지됩니다.
왜 변환은 한 건에 길게는 65초라 선점을 먼저 커밋하고 건별로 끊어야 하지만, 배달은 API 호출이라 훨씬 짧습니다. 짧은 김에 한 트랜잭션에 두면 상태를 하나 더 만들지 않고 중복 배달을 막을 수 있습니다.
배포하려고 서버를 내리면 그때 돌던 변환이 끊깁니다.
처리 워커가 종료 신호를 받으면 새 작업을 더 집지 않고, 이미 집은 한 건만 끝내고 내려갑니다.
왜 한 건이 보통 10초에서 30초라 배포할 때 기다리는 시간도 그만큼입니다. 접수한 요청은 DB 에 남아 있어 다시 떠도 이어서 돌지만, 이미 솔루션을 부른 건은 끝내고 내려가는 편이 쌉니다.
한 건이 터지면 그 워커가 같이 돌던 나머지까지 되돌아갑니다.
처리 작업 한 건마다 트랜잭션을 끊습니다.
왜 묶음이 통째로 실패하던 것이 원래 문제였으므로, 새로 만든 쪽에서 같은 모양을 다시 만들면 안 됐습니다.
한 덩어리로 붙어 있던 접수·호출·저장을 세 자리로 갈랐습니다. 어드민은 접수만 하고, 변환 시스템이 정한 상한 안에서 솔루션을 부르고, 결과는 배달받은 API 서비스가 적습니다.
| 전 | 후 | |
|---|---|---|
| 요청 | 어드민 스레드가 솔루션 응답까지 붙잡혀 있다 | 작업 행만 남기고 즉시 끝난다 |
| 동시 호출 수 | 부르는 쪽이 정한다. 화면에서 부르면 브라우저가 여는 6개 | 워커 스레드 수가 곧 상한이다 |
| 연결이 끊기면 | 결과도 실패 기록도 남지 않는다 | 워커는 계속 돌고, 시도마다 요청과 응답 원본이 남는다 |
| 504 판정 | 실패로 단정한다 | 미확정으로 두고 솔루션에 다시 물어 수렴시킨다 |
| 같은 자료 재요청 | 조회해서 없으면 등록이라 동시 요청을 못 막는다 | 진행 중인 건만 유일하도록 DB 가 막는다 |
| 결과 저장 | 저장 로직이 어드민 화면 안에 묻혀 있다 | 배달받은 API 서비스가 적는다 |
| 요청할 수 있는 곳 | 어드민 화면뿐 | 접수 주소를 아는 채널이면 된다 |
한 줄로 줄이면 요청자가 기다리는 시간과 작업이 끝나는 시간이 서로를 붙잡지 않게 된 것입니다. 처음에 잡았던 증상, 한 건은 되는데 수백 건은 안 되던 것이 여기서 사라집니다. 운영자가 몇 건을 넣든 나가는 양은 워커가 정하기 때문입니다.
남은 하나는 주의 등급인데, 제가 짠 코드만으로는 끝낼 수 없는 것입니다. 변환된 실물이 언제 다 됐는지를 어떻게 통보받을지는 바깥과 정해야 합니다. 제가 안 한 것과 못 하는 것을 갈라 적어두지 않으면 다음 사람이 같은 자리를 다시 팝니다.
504 를 보고 서버가 부족하다고 판단했다면 장비를 늘렸을 겁니다. 그런데 그 서버는 CPU 가 10% 도 안 치고 있었습니다. 과부하로 뻗은 게 아니라, 코어 하나만 쓰도록 잡아둔 설정과 몇 건을 동시에 보낼지 아무도 안 정한 구조가 만나서 난 일이었습니다. 늘려야 할 것은 장비가 아니었습니다. 고치기 전에 무엇이 어떻게 깨지고 있는지부터 연쇄로 그려본 게 그래서였습니다.
제가 정작 가장 오래 붙잡은 건 성능이 아니라 모르는 상태를 어떻게 다룰 것인가였습니다. 어드민과 변환 시스템과 솔루션이 각각 다른 프로세스로 도는 이상, 한쪽이 상대의 결과를 확인하지 못하는 순간이 반드시 생깁니다. 그때 임의로 성공이나 실패로 밀어버리면 데이터가 어긋납니다. 판정을 미루는 상태를 하나 두는 비용이, 잘못 판정한 데이터를 나중에 사람이 되돌리는 비용보다 훨씬 쌉니다.