메시지 큐 기초

호출하는 쪽과 처리하는 쪽을 시간적으로 떼어내기 위해서입니다.

두 번째가 큐의 고유한 값입니다. 초당 1만 건이 몰려도 소비자가 초당 1천 건만 처리할 수 있다면, 동기 호출로는 실패하지만 큐가 있으면 시간을 늘려 전부 처리합니다.

세 번째도 중요합니다. 동기 호출에서 상대가 죽으면 그 요청은 사라지지만, 큐에 넣었으면 상대가 복구된 뒤 처리됩니다.

흔한 실수: 성능을 위해 쓴다고만 답하는 것. 전체 처리 시간은 오히려 늘어납니다. 짧아지는 것은 사용자가 기다리는 시간입니다. 그리고 그 대가로 즉시 결과를 알 수 없게 됩니다.

세 번째가 실무에서 가장 흔한 오용입니다. 서비스 두 개 사이의 단순한 조회에 큐를 두면 응답을 되받기 위한 구조를 또 만들어야 하고, 그것은 그냥 동기 호출보다 복잡합니다.

큐를 도입하면 함께 따라오는 것들도 있습니다.

흔한 실수: 결합도를 낮추려고 모든 통신을 큐로 바꾸는 것. 흐름이 보이지 않아 장애 때 어디까지 진행됐는지 알기 어려워집니다.

유실될 수 있는 구간이 세 곳입니다. 각각을 막아야 합니다.

세 번째가 가장 흔한 원인입니다. 메시지를 받자마자 완료로 표시하고 처리 중에 죽으면 그 메시지는 사라집니다. 처리가 끝난 뒤 표시해야 합니다.

첫 번째에서는 DB 쓰기와 발행을 묶는 문제가 함께 옵니다. 커밋과 발행 사이에 죽으면 데이터는 있고 이벤트는 없으므로, 이벤트도 같은 트랜잭션에 저장해 두고 별도 프로세스가 발행하는 구조를 씁니다.

흔한 실수: 유실을 0으로 만들려는 것. 대가는 지연과 처리량입니다. 어떤 데이터는 유실을 감수하는 편이 합리적이고, 그 판단이 먼저입니다.

쌓인다는 것은 처리 속도가 유입 속도보다 느리다는 뜻입니다. 원인을 나눠 봅니다.

네 번째와 다섯 번째가 자주 놓치는 원인입니다. 전체 랙만 보면 원인이 안 보입니다.

첫 번째의 한계가 중요합니다. 파티션 수가 소비자 수의 상한이라, 파티션 4개에 소비자 10대를 붙이면 6대는 아무것도 하지 않습니다.

흔한 실수: 랙 숫자만 보고 판단하는 것. 건수보다 따라잡는 데 걸릴 시간이 실제 지표입니다. 100만 건이 쌓였지만 처리 속도가 유입의 두 배면 곧 사라지고, 1만 건이지만 처리가 더 느리면 계속 늘어납니다.