오늘도 운영중

Laravel에서 Queue를 처음 적용할 때는 Job 코드보다 어떤 Queue Connection을 사용할지 먼저 고민하게 된다.Laravel 프로젝트에서는 별도 인프라 없이 시작할 수 있는 Database Queue가 접근하기 쉽다.Application↓jobs 테이블↓Queue Worker서비스 규모가 커지거나 Queue 처리량이 많아지면 Redis Queue도 자연스럽게 후보에 들어온다.Application↓Redis↓Queue Worker그러면 이런 질문이 생긴다.Database Queue도 잘 동작하는데 Redis로 바꿔야 할까?Redis Queue는 정확히 무엇이 다른가?Job이 얼마나 많아지면 Redis를 사용해야 할까?Redis가 무조건 더 좋은 선택일까?단순히 Redis가 메모리 기반이..

Laravel Queue를 운영할 때 Job이 정상적으로 실행되고 있다는 것만 확인하면 충분해 보일 수 있다.하지만 Queue 장애는 꼭 Worker가 완전히 멈추는 형태로만 나타나지 않는다.Job은 처리되고 있음↓그런데 대기 시간이 점점 길어짐↓사용자는 결과를 늦게 받음또는 실패한 Job은 많지 않은데 특정 Job의 실행 시간이 계속 증가할 수도 있다.이런 문제는 failed_jobs만 확인해서는 발견하기 어렵다.Queue 상태를 제대로 보려면 최소한 다음 질문에 답할 수 있어야 한다.현재 Job이 얼마나 쌓여 있는가?Job은 얼마나 오래 기다리고 있는가?얼마나 빠르게 들어오고 처리되는가?Job 하나를 처리하는 데 얼마나 걸리는가?실패와 Retry가 증가하고 있지는 않은가?Worker는 정상적으로 동작..

Laravel Queue를 운영하다 보면 Job 자체는 몇 초 만에 끝나는데 사용자가 결과를 받기까지는 몇 분씩 걸리는 경우가 있다.이럴 때 처음에는 Worker 수가 부족하다고 생각하기 쉽다.Queue가 느림↓Worker 부족?↓Worker 추가물론 Worker가 부족한 경우도 있다.하지만 Queue가 느려지는 원인은 생각보다 다양하다.Job 유입량 증가Worker 부족특정 Job 실행 시간 증가Slow Query외부 API 지연Retry 반복무거운 Job과 가벼운 Job이 같은 Queue를 사용Worker 프로세스 이상원인을 확인하지 않고 Worker만 늘리면 DB 부하가 더 커지거나 외부 API 요청이 동시에 증가하면서 오히려 상황이 나빠질 수도 있다.그래서 Laravel Queue가 밀릴 때는 단..

Laravel Queue를 운영하다 보면 결국 한 번쯤 이런 고민을 하게 된다.Worker를 몇 개 띄워야 하지?1개면 부족한가?5개면 충분한가?10개로 늘리면 더 빨라질까? 처음에는 Queue가 밀리기 시작하면 Worker 수부터 늘리고 싶어진다.Queue 대기100건↓Worker 2개↓처리 느림↓Worker 10개로 증가겉으로 보면 단순하다. Worker가 많아지면 동시에 처리하는 Job 수도 늘어나기 때문에 Queue가 더 빨리 줄어들 것처럼 보인다. 하지만 실제 운영에서는 Worker를 많이 늘린다고 무조건 좋은 것은 아니다.CPU 부족메모리 증가DB Connection 증가Slow Query 동시 실행외부 API Rate Limit 초과Redis 부하 증가같은 문제가 생길 수 있다. 특히 Que..

Laravel에서 Queue를 처음 도입할 때는 보통 하나의 Queue로 시작하게 된다.SendSmsJob::dispatch($data);GenerateExcelJob::dispatch($data);SyncProductJob::dispatch($data);별도로 Queue를 지정하지 않았다면 모두 기본 Queue에서 처리된다.default├─ SendSmsJob├─ GenerateExcelJob├─ SyncProductJob├─ SendEmailJob└─ BatchJob서비스 규모가 크지 않을 때는 이 구조만으로도 충분하다.그런데 운영하다 보면 Queue에 들어가는 작업의 성격이 점점 달라진다.문자 발송→ 최대한 빨리 처리해야 함대용량 엑셀 생성→ 1~2분 늦어져도 괜찮음외부 데이터 동기화→ 오래 걸림통..

Laravel Queue를 운영하다 보면 결국 한 번쯤 중복 처리와 동시 실행 문제를 고민하게 된다. 예를 들어 같은 사용자가 다운로드 버튼을 여러 번 눌렀다고 해보자.첫 번째 요청↓GenerateExcelJob 등록두 번째 요청↓GenerateExcelJob 또 등록 또는 Worker가 여러 개 실행 중인 상황에서 같은 데이터를 동시에 처리할 수도 있다.Worker A↓User 100 처리Worker B↓User 100 동시에 처리겉으로 보면 둘 다 "같은 Job이 여러 번 실행되는 문제"처럼 보인다. 그래서 처음에는 Laravel의 ShouldBeUnique와 WithoutOverlapping을 비슷한 기능이라고 생각하기 쉽다. 하지만 두 기능은 막으려는 문제와 동작하는 시점이 다르다. 가장 간단하게..

Laravel에서 대량 데이터를 비동기로 처리해야 할 때 가장 먼저 떠올리는 방법 중 하나가 Queue다.예를 들어 100만 건의 데이터를 처리해야 한다고 해보자.API 요청↓Queue Job 등록↓Worker에서 100만 건 처리↓완료웹 요청에서 직접 처리하지 않기 때문에 사용자 입장에서는 빠르게 응답을 받을 수 있다. 처음에는 이것만으로 충분해 보인다. 하지만 실제 운영에서는 또 다른 문제가 생길 수 있다.Job 실행 시간이 너무 길어짐Worker 메모리 증가Timeout 발생배포 중 Worker 재시작중간 실패Retry 시 처음부터 다시 처리Queue를 적용했다고 대량 데이터 처리 문제가 모두 해결되는 것은 아니다. 특히 하나의 Job이 수십 분씩 실행되기 시작하면 실패했을 때의 비용도 함께 커진다..

이전 글에서는 Deadlock(교착 상태) 에 대해 알아봤다.Deadlock은 여러 작업이 서로 상대방이 가지고 있는 자원을 기다리면서 아무도 진행하지 못하는 상태다.그런데 동시성 문제를 공부하다 보면 Deadlock과 함께 자주 등장하는 개념이 하나 더 있다.바로 Starvation(기아 상태) 이다.이름만 보면 조금 생소하지만 개념 자체는 어렵지 않다.간단하게 말하면다른 작업들은 정상적으로 실행되고 있는데 특정 작업만 계속 실행 기회를 얻지 못하는 상태다.Task A → 실행Task B → 대기Task C → 실행Task B → 대기Task D → 실행Task B → 대기...Task B는 실행할 수 있는 상태인데 계속 다른 작업에 밀리고 있다.이번 글에서는 Starvation이 무엇인지, Deadl..

백엔드 서비스를 운영하다 보면 가끔 이상한 문제가 발생한다.분명 코드에는 문제가 없어 보이는데재고가 음수가 되거나포인트가 두 번 사용되거나쿠폰이 중복 발급되거나같은 주문이 여러 번 처리되는문제가 발생하는 경우다.그리고 개발 환경에서는 아무리 테스트해도 잘 재현되지 않는다.이런 문제의 원인 중 하나가 바로 Race Condition(경쟁 상태) 이다.Race Condition은 여러 Thread나 Process, 요청이 같은 데이터에 동시에 접근하면서 실행 순서에 따라 결과가 달라지는 문제다.오늘은 Race Condition이 무엇인지, 왜 발생하는지, 그리고 Laravel 같은 실제 백엔드 서비스에서는 어떤 상황에서 발생할 수 있는지 알아보자.Race Condition이란?Race Condition은 여..

Laravel로 대량 데이터를 처리하다 보면 전체 작업이 모두 성공하는 경우만 있는 것은 아니다.예를 들어 10만 건의 데이터를 처리한다고 해보자.전체 데이터100,000건↓99,950건 성공↓50건 실패이때 고민이 생긴다.50건 때문에 전체 작업을 실패시켜야 할까?성공한 99,950건은 그대로 두어도 될까?실패한 50건만 다시 처리할 수 있을까?Queue Retry가 실행되면 10만 건을 처음부터 다시 처리해야 할까?처음 Batch 기능을 만들 때는 보통 정상적으로 처리되는 흐름에 집중하게 된다.하지만 실제 운영에서는 일부 데이터가 잘못되어 있거나, 외부 API가 일시적으로 실패하거나, 특정 데이터에서 예상하지 못한 Exception이 발생할 수 있다.특히 데이터가 많아질수록 일부 실패가 발생할 가능성..