서버가 두 대면
방도 둘로 갈라집니다.

01

연결 목록은 서버마다 따로입니다.

각 서버는 자기에게 연결된 사용자만 알고 있습니다. 이것은 설계 실수가 아니라 연결이라는 것이 특정 서버와 맺어지는 관계이기 때문에 생기는 당연한 결과입니다. 서버를 늘리는 순간 방이 갈라지는 문제는 규모를 키울 때 반드시 만나게 되며, 서버 한 대로 잘 돌던 코드가 두 대에서 깨지는 대표적인 이유입니다.

02

브로커는 지금 있는 사람에게 퍼뜨립니다.

브로커를 켜면 한쪽 서버가 받은 메시지를 다른 서버들에게 전달하고, 각 서버가 자기에게 붙은 사람에게 내보냅니다. 이 방식은 빠르지만 그 순간 연결돼 있는 대상에게만 닿습니다. 지금 듣고 있지 않은 사람을 위해 메시지를 들고 있어 주지는 않는다는 점이 이 장치의 성격입니다.

03

저장소는 나중에 온 사람을 담당합니다.

끊겨 있던 사용자가 다시 붙었을 때 그동안의 메시지를 받으려면 어딘가에 남아 있어야 합니다. 그 역할은 브로커가 아니라 저장소가 맡습니다. 화면에서 두 장치를 따로 켜고 끌 수 있게 만든 이유는, 하나만으로는 해결되지 않는다는 점을 직접 확인하게 하기 위해서입니다.

04

실시간 전달과 나중 복구는 다른 문제입니다.

많이 쓰는 브로커를 붙여 놓고 메시지 유실이 해결됐다고 생각하기 쉬운데, 그 둘은 다루는 시점이 다릅니다. 지금 퍼뜨리는 일과 나중에 다시 읽을 수 있게 하는 일을 같은 장치에 맡기려 하면 어느 쪽도 제대로 되지 않습니다. 이 구분이 이 화면에서 가장 중요한 내용입니다.

05

같은 방 이름을 모든 서버가 알아야 합니다.

서버들이 메시지를 주고받으려면 어느 방에 대한 이야기인지 같은 규칙으로 이름을 만들어야 합니다. 서버마다 다른 방식으로 이름을 지으면 브로커를 붙여도 서로의 메시지를 알아보지 못합니다. 화면에서는 이 부분을 이미 맞춰진 것으로 두고 있습니다.

06

다시 읽으면 겹칠 수 있습니다.

저장소에서 놓친 메시지를 다시 읽어 올 때 이미 받은 것이 섞여 들어올 수 있습니다. 그래서 받는 쪽은 같은 메시지가 두 번 와도 화면에 한 번만 반영되도록 만들어야 합니다. 메시지마다 고유한 번호가 필요한 이유이고, 그 번호는 전달을 다룬 첫 편에서 본 것과 같은 역할을 합니다.

07

경로를 위치로 표시합니다.

메시지가 지금 어느 지점에 있는지를 값으로 들고 있어서, 실패한 경우에도 어디까지 갔다가 멈췄는지 화면에 남습니다. 전달 실패를 결과로만 표시하면 무엇을 고쳐야 할지 알 수 없는데, 멈춘 지점이 곧 빠진 장치를 가리킵니다.

08

서버 한 대에서는 드러나지 않습니다.

이 문제의 성가신 점은 개발 환경에서 재현되지 않는다는 것입니다. 서버를 한 대만 띄우고 시험하면 모든 사용자가 같은 메모리를 공유하므로 아무 장치 없이도 잘 동작합니다. 실제로 서버를 늘린 뒤에야 드러나고, 그 시점에는 이미 코드가 그 전제 위에 쌓여 있습니다. 규모를 키울 계획이 있다면 처음부터 서버 간 전달을 가정하고 짜는 편이 나은 이유입니다.

09

붙는 서버를 고정하는 방법도 있습니다.

같은 방의 사용자를 항상 같은 서버로 보내면 이 문제를 피할 수 있습니다. 다만 그러면 특정 서버에 부하가 몰리고, 그 서버가 죽었을 때 그 방 전체가 영향을 받습니다. 문제를 없애는 대신 다른 제약을 얻는 선택이라, 방의 크기와 서버 구성에 따라 어느 쪽이 나은지 달라집니다. 이 화면은 고정하지 않는 쪽을 전제로 합니다.