되돌아오는 질문들 — 알림센터 설계 문답

무엇을 버려도 되는지 모르면 아무것도 살 수 없다. 편4가 이 문장으로 닫혔고, 실은 앞의 세 편이 내린 결정도 전부 같은 모양이었다. 포기할 수 있는 것을 먼저 찾아내고 그 대가로 필요한 성질을 샀다.

되돌아오는 질문은 대개 그 거래를 다시 여는 형태로 온다. 「왜 저 저장소인가」는 무엇을 포기했는지를 묻는 것이고, 「알림이 왜 늦나」는 포기한 것의 청구서가 도착했다는 뜻이며, 「이걸 왜 이렇게 만들었나」는 그 거래를 남이 납득할 수 있게 설명해 보라는 요구다.

그리고 이 질문들은 편의 경계를 지키지 않는다. 「같은 알림이 두 번 보인다」 하나가 최소 한 번 전달이라는 브로커의 성질에서도 시작하고 저장할 때 무엇을 유일하다고 보았는지에서도 시작한다. 앞의 네 편이 주제로 나뉘어 있으니 이 편은 질문이 오는 자리로 다시 세운다.

앞의 네 편이 이미 답한 것은 다시 설명하지 않는다 — 한 줄로 답하고 그 편을 가리킨다. 새로 쓰는 자리는 둘뿐이다. 앞 편이 장단점만 늘어놓고 넘어간 곳에 고르는 기준을 주는 자리, 그리고 여러 편에 걸쳐 있어 어느 편도 통째로 답하지 못한 자리다.

고를 때

여섯 갈래다. 기준은 「무엇이 더 좋은가」가 아니라 **「무엇을 내줄 수 있는가」**로 잡는다. 오른쪽 끝은 그 선택을 논증한 편이다.

여섯이 내주는 것은 사실 세 가지다

「내주는 것」 열을 성질별로 묶으면 항목이 줄어든다. 그리고 줄여 놓고 보면 이 설계가 무엇을 일관되게 포기했는지가 드러난다.

남은 둘 — 서버 분리와 멀티모듈 — 은 성격이 다르다. 이 둘이 내주는 것은 사용자가 볼 수 있는 성질이 아니라 운영과 빌드의 복잡도다. 앞의 셋은 제품의 약속을 깎아 성능을 사지만, 뒤의 둘은 팀이 감당할 몫을 늘려 격리와 경계를 산다. 그래서 뒤의 둘은 팀 규모가 작을수록 비싸고, 앞의 셋은 서비스가 작을수록 비싸다 — 알림이 하루 수천 건이면 즉시성을 내줄 이유가 없다.

조건이 바뀌면 셋이 뒤집힌다

같은 논리를 다른 도메인에 넣으면 결론이 반대로 나온다는 것을, 편4가 결제·정산을 예로 이미 보였다. 여기서는 어느 행이 뒤집히는지만 짚는다.

뒤집히지 않는 것은 서버 분리와 멀티모듈이다. 워크로드의 성격이 다르면 따로 늘려야 한다는 것과, 따로 띄운다고 해서 코드를 두 벌 만들 이유는 없다는 것은 도메인을 타지 않는다. 앞의 셋은 도메인이 정하고 뒤의 둘은 구조가 정한다.

터졌을 때

원인이 아니라 증상에서 출발하는 표다. 실제로 손에 먼저 들어오는 것이 증상이기 때문이다.

열 중 여섯이 브로커 쪽에 몰려 있는데, 이것이 비동기를 고른 대가의 실제 모양이다. 동기 호출이었다면 이 여섯은 애초에 존재하지 않고 대신 원 서비스가 함께 죽는다. 문제가 사라진 것이 아니라 사라져도 되는 자리로 옮겨 간 것이다.

소비자를 늘렸는데 지연이 그대로다

가장 자주 되돌아오는 증상이고, 증설이 듣지 않는 이유가 셋으로 갈린다. 그래서 처방보다 보는 순서가 먼저다.

셋을 순서대로 보는 이유는 증설이 유효한 경우가 셋 중 하나뿐이기 때문이다. ①이면 파티션을 먼저 늘려야 하고, ②면 늘려도 몰린 파티션은 그대로이며, ③이면 늘리는 것이 악화다. 「느리면 늘린다」가 통하지 않는 구간이 이렇게 넓다.

셋을 갈라 보려면 파티션 단위의 지표가 있어야 한다. 무엇이 느린지를 합계만 보고는 알 수 없다는 문제는 도메인을 가리지 않는데, 여러 단계를 거치는 파이프라인에서 구간별 소요를 추적하는 이야기도 관측을 다룬 글에 같은 형태로 나온다.

같은 알림이 두 번 보인다

이 증상은 원인이 두 갈래이고, 갈래에 따라 손댈 편이 다르다. 그래서 먼저 중복의 성격부터 확인한다.

전자라면 배포와 리밸런스 시각이 중복 발생 시각과 겹치는지 먼저 본다. 후자라면 시각과는 무관하게 계속 쌓이므로 그것만으로도 갈래가 갈린다.

근본 대응은 어느 쪽이든 재시도 로직을 손보는 것이 아니라 저장을 덮어쓰기로 바꾸고 유일 인덱스로 저장소가 강제하게 하는 것이다. 애플리케이션에서 「먼저 조회하고 없으면 넣는다」로 막는 방식은 두 소비자가 같은 순간에 그 조회를 통과하는 상황에서 반드시 뚫린다. 하나가 실패해도 나머지를 어떻게 마감할 것인가는 알림만의 문제가 아니어서, 여러 갈래가 병렬로 도는 구조에서 부분 실패를 마감하는 규약도 같은 자리에서 출발한다.

설명해야 할 때

근거를 말로 옮기는 자리다. 스물다섯 문답을 먼저 놓고, 한 줄로 줄이면 손해인 하나를 뒤에 뒀다. 답이 길어지는 것은 그 편의 몫이라 오른쪽 열을 따라간다.

스물다섯 중 열셋이 편3에 걸린다. 브로커가 어려워서가 아니라 비동기를 고른 순간 설명해야 할 성질이 한꺼번에 늘어나기 때문이다. 동기 호출에는 순서도 중복도 재처리도 설명할 거리가 없다.

22 — MSA로 쪼개라는 요구가 오면

22번이 한 줄로 끝나지 않는 이유는, 이 질문에 대한 답이 기술 판단이 아니라 요구의 출처를 되묻는 절차이기 때문이다.

먼저 왜 쪼개려 하는지를 확인한다. 배포가 서로 막혀서인지, 한쪽만 훨씬 크게 띄워야 해서인지, 아니면 그렇게 하는 것이 요즘 방식이라서인지에 따라 답이 완전히 달라진다.

규모가 이유라면 이미 풀려 있다. 조회 모듈과 소비자 모듈은 코드베이스를 공유해도 별개 산출물이라 따로 배포되고 따로 늘어난다. 네트워크 경계를 세우지 않고 목적을 이룰 수 있으면 그쪽이 싸다.

반대로 팀이 나뉘어 릴리스 주기가 부딪히기 시작했다면 그때는 쪼개는 편이 맞다. 쪼개서 얻는 것의 대부분은 기술적 이점이 아니라 팀이 서로를 기다리지 않는 상태이기 때문이다. 다만 넘어가더라도 모듈 경계가 깨끗하다는 전제가 필요하다. 경계가 흐린 채로 나누면 배포만 갈라지고 릴리스는 늘 함께 해야 하는 상태에 갇힌다.

정리

세 자리를 한 줄로 줄이면 이렇게 된다. 고를 때는 무엇을 내줄지 정하는 자리이고, 터졌을 때는 내준 것의 청구서를 받는 자리이며, 설명해야 할 때는 그 둘이 같은 판단이었음을 보이는 자리다.

이 시리즈 전체가 같은 구조였다. 편1이 부하와 장애가 흐르는 방향이 어긋나 있다는 것을 지형으로 보였고, 편2가 그 어긋남을 따라 선을 그었으며, 편3이 선을 그은 대가로 받은 청구서 셋을 갚았고, 편4가 남은 비대칭 위에서 담는 자리와 읽는 자리를 정했다.

되돌아오는 질문이 매번 여러 편에 걸치는 것도 그래서다. 결정 하나가 다른 편의 문제를 만들도록 되어 있으니 질문도 그 경로를 따라온다. 답이 한 편 안에서 끝나는 질문은 대체로 아직 덜 물어본 질문이다.