- 공개 이벤트 스트림 덕분에 Twitter에서는 만들기 어려운 전체 소셜 그래프 지도를 블루스카이에서는 1,300만 사용자 규모로 구성할 수 있었음
- 수집 파이프라인은
bsky.network의 WebSocket firehose에서 팔로우·언팔로우만 걸러 SQLite에 저장하며, 당시follows테이블은 5억 행 이상·약 30GB였음 - 1,300만 노드와 5억 엣지를 배치하려고 Zig 기반 멀티스레드 force-directed layout 엔진 Andromeda를 만들었지만, 대형 소셜 그래프에서는 지역 구조가 뭉개지는 한계가 드러남
- GGVec 임베딩과 UMAP을 조합해 더 많은 중간 구조를 얻고, UMAP의 점 겹침은 Andromeda로 몇 틱 더 시뮬레이션해 조밀한 클러스터를 다듬음
- 최종 지도는 2024년 11월 7일 기준 필터링 후 770만 노드를 표시하며, 봇 링·국가별 클러스터·고팔로워 미디어/정책 계정 군집을 탐색할 수 있음
블루스카이 전체 네트워크 지도가 가능했던 이유
- Twitter는 전체 데이터를 이용할 수 없고 스크래핑도 어렵고 불법적일 수 있어 전체 지도를 만들기 어려움
- BlueSky는 필요한 데이터를 얻을 수 있으며, 2024년 몇 달 동안 크게 성장함
- 성장 배경에는 Twitter와 사용자 기반의 지속적 충돌, 2024년 10월 브라질의 Twitter 차단이 있음
- 결과물은 aurora.ndimensional.xyz에서 인터랙티브 지도로 탐색할 수 있음
- WebGPU를 사용하므로 데스크톱 Chrome/Chromium이 필요함
팔로우 그래프 수집 방식
- 전체 활동 대신 팔로우 그래프만 사용해 작업 범위를 줄임
- 각 팔로우는 무방향 엣지 하나로 취급됨
- 서로 맞팔이면 두 개의 엣지가 생겨 사실상 가중치가 두 배가 됨
- BlueSky는 AT Protocol 기반이며, 사용자가 자신의 PDS(personal data server)를 직접 호스팅할 수 있도록 설계됨
- 실제 수집은 BlueSky 팀이 운영하는
bsky.networkrelay의 WebSocket firehose를 사용함- 메인
*.bsky.socialPDS와 인덱싱을 요청한 독립 PDS의 이벤트를 집계함 - 전체 네트워크 이벤트가 실시간으로 스트리밍되며, 현재 약 초당 500개 이벤트 수준임
- 이 중 팔로우와 언팔로우만 필터링해 로컬 SQLite 데이터베이스에 저장함
- 메인
- 초기에는 인덱서를 fly.io에 배포하고 litestream으로 AWS S3에 데이터베이스를 실시간 복제했지만, 월 40달러 비용 때문에 홈 서버 운영으로 바꿈
- 이후 systemd 서비스, logrotate, tmux 모니터, TailScale을 조합해 집의 System76 데스크톱에서 운영함
- 작성 시점에 BlueSky는 1,300만 사용자를 넘었고,
follows테이블은 5억 행 이상, 디스크 사용량은 약 30GB였음
1,300만 노드 그래프의 계산 병목
- 그래프 레이아웃에는 여러 방법이 있지만, 여기서는 물리 시뮬레이션처럼 동작하는 force-directed layout이 출발점임
- 모든 노드는 서로 밀어내는 힘을 가짐
- 엣지는 소스와 타깃 사이를 당기는 힘을 만듦
- 각 시뮬레이션 틱에서 노드별 순힘을 계산하고 온도 파라미터로 스케일해 이동시킴
- 병목은 그래프 크기 자체보다 n-body problem의 계산 복잡도에 있음
- 단순 알고리듬은 한 틱에
O(n^2) + O(e)가 필요함 - 수백만 노드 규모에서는 GPU로도 현실적이지 않음
- 단순 알고리듬은 한 틱에
- 일반적인 force-directed 엔진처럼 Barnes-Hut 최적화를 쓰면
O(n log(n)) + O(e)로 줄어듦- 먼 노드의 효과를 근사하는 대가가 있음
- quadtree 구축과 질의는 계층적이라 GPU에서 노드 힘을 쉽게 계산하기 어려움
- 병렬화를 위해 quadtree를 4개 또는 16개로 나눠 각 틱 시작 시 병렬 재구축하고, 스레드별로 노드 범위를 나눠 힘을 계산함
- 각 노드의 순힘은 각 quadtree가 주는 힘과 들어오고 나가는 엣지가 주는 힘의 합임
- 사용 가능한 CPU를 거의 오버헤드 없이 활용할 수 있음
Andromeda와 force-directed 방식의 한계
- Zig로 멀티스레드 force-directed graph layout 엔진 Andromeda를 만들고, GTK4와 OpenGL로 GUI를 구성함
- Andromeda는 Gephi와 ForceAtlas2 논문의 영향을 크게 받음
- 대규모 그래프 시각화에서는 그래프가 변하는 모습을 보며 시뮬레이션 파라미터를 동적으로 조절하는 상호작용성이 중요함
- 불투명하고 반복 시간이 긴 도구로는 좋은 결과를 얻기 어려움
- Andromeda에는 “natural slider”라는 UI 위젯도 있음
- 새 그래프, 새 엔진 버전, 새 파라미터를 다룰 때 적절한 값 범위를 미리 알기 어려운 문제를 줄이기 위한 장치임
- 값 범위를 e의 거듭제곱 단위로 동적으로 조정함
- 2의 거듭제곱은 너무 작고 10의 거듭제곱은 너무 크다고 판단함
- 2024년 9월의 500만 BlueSky 사용자 스냅샷에 ForceAtlas2 레이아웃을 적용하자 큰 클러스터의 질량과 밀도는 보였지만, 전반적으로 덩어리진 형태가 강했음
- 대부분의 노드는 슈퍼클러스터 주변의 넓고 구분 어려운 영역에 흩어짐
- 몇십 개의 작은 커뮤니티, 주로 국가 단위 커뮤니티만 뚜렷하게 분리됨
- 2024년 2월 200만 계정 버전을 공개했을 때도 전역 뷰에는 흥미가 있었지만 로컬 뷰에는 실망이 있었음
- 사용자가 자신의 계정을 찾아도 주변 계정을 알아보지 못하는 경우가 있었음
- 2D 평면 배치만으로 전체 네트워크 연결 구조를 완전히 포착하기는 어려움
UMAP, 색상, 최종 지도
- 그래프 레이아웃은 차원 축소로도 볼 수 있어, 1,300만 × 1,300만 인접 행렬을 2차원 평면에 투영하는 문제로 다룰 수 있음
- t-SNE와 UMAP은 2차원 시각화에 강한 비선형 차원 축소 기법임
- UMAP에 BlueSky 행렬을 직접 넣기에는 홈 서버 규모에서 너무 큼
- 대신 사용자별 32차원 정도의 임베딩을 만들고 그 결과를 UMAP에 넣음
- 오픈소스 노드 임베딩 도구로 nodevectors를 선택했고, 미공개 GGVec 알고리듬이 대규모 그래프에서 병렬 성능이 가장 좋아 보였음
- 2024년 9월 500만 노드 스냅샷의 임베딩은 5분 만에 생성됨
- 첫 UMAP 이미지는 추가로 10분 만에 얻음
- Andromeda의 덩어리진 결과보다 더 많은 중간 구조가 나타남
- UMAP은 일부 클러스터를 너무 조밀하게 만들어 점이 겹치는 문제가 있었음
- 원본 차원에서 동일한 점을 목표 차원에서도 같은 위치에 두는 순수 차원 축소 목적에는 자연스러운 동작임
- 하지만 계정별 프로필 사진을 가까운 줌에서 보여주는 지도에는 적합하지 않았음
- UMAP 내부도 마지막 단계에서 가중 k-최근접 이웃 그래프에 대한 force-directed layout을 사용함
- UMAP은 계산 제약 때문에 샘플링을 사용하므로 모든 노드가 Barnes-Hut 방식처럼 근사적으로라도 서로 반발하지 않음
min_dist파라미터가 대규모 그래프에서 점 간 분리를 일관되게 제어하지 못한다고 판단함
- 겹침 문제는 UMAP 출력을 Andromeda에 넣고 반발력 방정식을 조정해 몇 틱 더 실행하는 방식으로 완화함
- 조밀한 클러스터에서도 노드가 층처럼 겹치지 않고 채워짐
- 다음 버전에서는 UMAP이 만든 그래프의 원시 가중치에 접근해 Andromeda의 병렬 quadtree와 UMAP 논문의 힘 방정식을 직접 결합해 보려 함
- 색상은 UMAP 결과에 HDBScan을 적용하는 대신, 임베딩 공간에서 k-means 클러스터링을 수행해 부여함
- 각 클러스터에 hue를 할당함
- 각 점은 가장 가까운 세 클러스터 중심을 이용해 hue를 보간함
- PCA 기반 색상보다 로컬 구조를 더 잘 드러내고, 가까이서 보면 얼룩진 스테인드글라스 같은 질감을 줌
- hue는 0에서 1 사이의 단일 float이며, hsluv 색공간으로 RGB에 매핑함
- 모든 노드의 채도는 일정하게 유지함
- 밝기는 사용자 팔로워 수의
log10으로 스케일해 큰 계정은 밝은 별처럼, 팔로워가 적은 계정은 흐리게 보이게 함 - 큰 계정을 실제로 더 크게 렌더링하는 방식은 대형 그래프에서 지나치게 복잡해져 제외함
- 2024년 11월 7일 기준 전체 네트워크 지도는 팔로우 5만 초과 계정, 팔로우 5개 미만이면서 팔로워 5명 미만인 계정을 제외해 770만 노드로 구성됨
- 고팔로워 미디어·정책·논평 계정의 뚜렷한 줄무늬가 배경의 관련 낮은 그룹과 구분됨
- 아이슬란드 클러스터도 원거리와 근거리, 프로필 사진 수준에서 확인됨
- 봇 링도 명확히 드러남
- 다음 기능으로는 현재 화면에 보이는 계정들의 게시물 타임라인을 접을 수 있는 사이드바로 추가하려 함
- 새로운 종류의 소셜·밈 탐색 도구로 발전시키는 것이 목표임