액티비티펍 네트워크의 결함 내구성 문제

지난번 짧은 휴가를 마치고 돌아오는 길에 액티비티펍 네트워크의 부하 내구성 문제를 마주쳐 먼 거리를 돌아오는 길이 그리 지루하지 않았다는 이야기를 소개했습니다. 한국어권 액티비티펍 네트워크는 릴레이를 통해 여러 서버가 서로 연결되어 있는데 액티비티펍 서버들은 사용자들의 직접적인 요청에 의한 서버 사이의 통신에 제약이 별로 없지만 서버들이 서로 간접적인 통신을 하지는 않기 때문에 X(구 트위터) 처럼 중앙화된 서비스처럼 다른 사용자를 쉽게 발견하기는 어렵습니다.

특히 한국어권 사용자들은 대대로 이런 작은 서비스를 사용하는데 익숙하지 않아 다른 사용자들을 발견하기 쉽지 않은 특징 때문에 서비스를 사용하기 어려워 하는 것 같아 보입니다. 이런 특징을 완화하기 위해 릴레이 서버라는 것이 있는데 액티비티펍 프로토콜 호환 서비스를 릴레이에 등록하면 각 서버 사용자가 직접 요청하지 않아도 릴레이에 연결된 각 액티비티펍 호환 서비스들로부터 공개된 글을 서로 다른 서버에 항상 전달해 다른 사용자들을 발견하기 쉽게 만들어 줍니다.

그런데 당시 X(구 트위터)가 갑자기 단위 시간 당 사용량을 제한해 서비스를 계속해서 사용할 수 없게 된 사용자들이 갑작스레 액티비티펍 네트워크에 나타났고 이들이 갑자기 쏟아내는 글이 평소의 액티비티펍 네트워크가 감당할 수 있는 양을 한참이나 초과해 네트워크 전체에 문제를 일으킵니다. 규모가 큰 서버는 문제가 두드러지지 않았지만 규모가 작은 서버는 릴레이를 통해 들어오는 페더레이션 타임라인이 늦게 처리되어 실시간으로부터 큰 차이가 나기 시작했는데 제가 겪은 가장 긴 딜레이는 실시간 페더레이션 타임라인으로부터 9시간 차이가 난 것입니다. 9시간 차이 난 상태가 한참이나 지속되자 혹시 이거 협정표준시와 한국표준시 차이로 생기는 문제가 아닐지 의심해봤을 정도입니다.

알고 보니 릴레이에 연결된 모든 서버는 사실 릴레이에 연결된 모든 서버가 릴레이로 뿜어내는 모든 메시지를 처리할 수 있는 처리량을 갖추고 있어야 이렇게 네트워크가 붐비는 상황에 문제를 겪지 않을 수 있었습니다. 평소에 릴레이 서버는 서로 떨어져 있어 직접적인 요청을 통한 통신 외에는 서버 간에 사용자를 발견하기 어려운 액티비티펍 네트워크의 특징이자 단점을 보완해 주지만 지난번 처럼 네트워크 사용량이 갑자기 늘어나는 상황에서는 한 서버의 사용량 증가를 릴레이에 연결된 모든 서버로 전파하는 일종의 DDoS 역할을 하게 됩니다.

개인적으로 이런 현상은 액티비티펍 프로토콜의 설계 결함이라고 생각합니다. 페더레이션에는 크고 작은 여러 규모의 서버가 있을 수 있는데 이들이 릴레이에 묶여 있다면 좋은 생각은 아닌 것 같지만 처음부터 릴레이 전체의 처리량을 견딜 수 있어야 한다는 제한을 걸거나, 릴레이에 묶인 서버 중 일부의 사용량이 늘어나더라도 이를 곧이곧대로 릴레이에 연결된 모든 서버에 전파하는 대신 우선순위를 매겨 릴레이에서 처리할 수 있는 수준으로 트래픽을 조정하는 메커니즘이 당연히 필요하다고 봅니다. 가령 한 서버에서 릴레이에 메시지를 보내기 전에 릴레이에 연결된 다른 서버로부터 직접 팔로잉 관계에 있는 계정의 메시지를 우선 처리한다든지 하는 식으로 이전 사용자들의 사용 경험을 망가뜨리지 않는 선에서 중요한 메시지를 우선 처리하고 나머지 메시지는 전체 네트워크 사용량이 감소할 때 릴레이를 통해 전송해 부하 상황을 완화할 수 있지 않을까 싶었습니다.