회원 수 120만 명인 내 커뮤니티 중 하나가 너무 늦게 확장(scale)을 시도했던 재미있는 이야기가 하나 있습니다.
SkyscraperCity는 건축, 도시 환경, 대도시 구조물에 전념하는 세계 최대 규모의 커뮤니티 중 하나입니다. 상당한 수준의 도시 개발과 관련된 대형 구조물이 있는 세계의 각 지역은 자체 섹션을 가지고 있습니다. 당연히 이 커뮤니티 안에는 사진이 대량으로 공유되고 있는데, 그 이유는 커뮤니티 회원들이 논의 중인 고층 건물을 보여주고 이야기하는 것을 정말, 정말 좋아하기 때문입니다.
문제는 우리가 예상했던 곳에서 발생하지 않았습니다.
문제가 이미지 처리와 첨부 파일 확장에서 늦게 발생했던 것은 아닙니다. 그것은 이미 알려진 요인이었고, 플랫폼은 이를 처리하도록 구축되어 있었습니다.
문제는 서로 다른 대도시 지역 수가 증가하면서 발생했습니다. 대륙, 국가, 주(州), 그리고 마지막으로 도시를 기반으로 한 개별 카테고리, 하위 카테고리, 하위-하위-하위 카테고리가 하나씩 추가될 때마다, 그 안에는 수 많은 동네(neighborhoods)가 존재할 수 있었습니다. 커뮤니티의 정보 아키텍처가 각 지역이 활성화되는 것을 플랫폼이 처리할 수 있는 능력을 넘어서 확장되었습니다. 플랫폼은 모든 카테고리들의 무게에 짓눌려 있었고, 성능은 극도로 느려졌습니다. 페이지에서 페이지로 이동하는 것조차, 아니 글 하나를 작성하는 것조차 고통스러울 정도였습니다.
해당 플랫폼은 노드 트리를 기반으로 카테고리를 구성한 오래된 XenForo 커스텀 빌드였습니다. 구조의 일부로 수백, 수천 개의 개별 카테고리를 처리하도록 설계되지 않았습니다. 그 방식으로는 각 노드가 상당한 리소스를 차지하므로, 특정 지점의 노드 수가 많을수록 플랫폼은 불안정해졌습니다. 나는 좀 더 시각적으로 설명하기 위해 커뮤니티에 이 상황을 《스타트랙: 더 넥스트 제너레이션》의 특정 에피소드에 비유했습니다. 그 에피소드에서는 웜홀 엔진이 공간/시간의 구조에 너무 자주 구멍을 내어, 교통량이 많은 지역의 공간을 약화시키는 것을 발견하게 됩니다.
수많은 카테고리(하위-하위-하위-하위 카테고리 등)가 인기 있는 우주 지역에서 수백 개의 웜홀 드라이브가 활성화되어 해당 지역의 붕괴를 초래하는 것과 동일한 방식으로 플랫폼 안정성에 "손상"을 일으키고 있었습니다.
해결책은 연방(Federation)의 것과 크게 다르지 않았습니다. 즉, 속도를 줄이고 구멍을 제한하는 것이었죠. 우리는 정보 아키텍처를 전면적으로 재검토하여 하위 레벨 카테고리를 많이 통합하고 상위 레벨 카테고리 중 일부도 통합했으며, 시스템은 안정화되었습니다.
물론 이 문제는 Discourse에서는 발생하지 않습니다. Discourse는 카테고리를 하나의 거대한 구조 트리가 아닌 일급 컨테이너(first-class containers)로 훨씬 더 잘 처리하기 때문입니다. 원할 경우 균사체 네트워크나 초공간 통로라고 불러도 됩니다. 하지만 이것은 확실히 내가 경험한 가장 대표적인 사례 중 하나로, 너무 일찍 확장했고, 타격이 올 것이라고 예상하지 못한 곳에서 문제가 발생한 경우입니다.
