[글결] 시즌 2 개발 일지 #1: 새 아키텍처 구성

태그 글결 분류 글결

글결 프로젝트 시즌 2의 첫 개발 일지. 새로운 아키텍처 구성과 준비 과정을 공유합니다.

2025년 12월 27일 오후 7:48

글결 프로젝트 로고

서론

글결 프로젝트 시즌 2에서는 개발 일지를 써 보고자 한다. 먼저 이 글에서는 지난 11월 27일부터 시험 구동하여, 12월 17일부터 본격적으로 가동하기 시작한 시즌 2의 새로운 아키텍처 구성에 대해 다루고자 한다.

그 전에, 시즌 2에는 나 말고도 다른 팀원을 구했다는 소식을 전하고 싶다. 우연한 기회로 같은 학교의 Float5와 함께하게 되었으며, 이번에는 크롤러 등 일부 구성 요소의 작성을 담당하였다. 앞으로 함께 글결 프로젝트를 발전시켜 나가길 기대한다. 또한, 이 프로젝트에 관심이 있다면 [email protected]로 연락해 주시길 바란다.

새로운 아키텍처의 구상

먼저 시즌 1에서의 문제점을 다시 정리해 보자.

• 재파싱 불가: 시즌 1은 크롤링한 다음 바로 파싱하여 저장했기에, 파서를 수정하더라도 기존 데이터에는 반영할 수 없었으며 DB에는 text, markdown, markdown_text, raw 등 중복된 필드가 존재하여 낭비가 심했다.
• DB 확장성 부족: 시즌 1에서는 단일 MongoDB 노드가 모든 저장을 담당하여, OOM 등으로 DB가 죽는 경우도 잦았으며 데스크탑에서 구동했으므로 부담이 컸다. 마무리할 즈음에는 드라이브 용량 또한 부족해졌다.
• 이 외 메모리 누수나, 후처리 파이프라인의 비효율성

이 외에도, 업데이트나 크롤러 배포 과정에서의 불편함 등 여러 문제가 있었다. 이러한 문제를 해결하기 위해, 시즌 2에서는 다음과 같은 아키텍처를 구상했다.

• K8s와 Docker의 도입: 이들은 여러 노드를 효과적으로 관리할 수 있도록 도와주며, 일관적인 환경을 만들 수 있다.
  • 서비스의 분리: K8s 환경에서 효과적인 관리를 위해 크롤러와 링크 탐색, 메타데이터 서버 등을 분리한다.
• CI/CD의 도입: GitHub Actions 등을 사용해 배포 과정에서의 복잡함을 줄인다.
• 크롤링과 파싱의 분리: 크롤링한 원본 HTML을 저장하고, 파싱은 별도의 파이프라인에서 처리하여 재파싱이 가능하도록 한다.

이러한 구상을 바탕으로 한 시즌 2 아키텍처를 살펴보자.

FigJam으로 대충 그려진 다이어그램이지만, 전체적인 구조를 이해하는 데 도움이 될 것이다. 여기에서 C++로 작성된 것이 Float5가 담당해준 부분이며, 나머지 부분은 내가 맡은 부분이다.

아키텍처 구성 요소

• GCP Pub/Sub: 시즌 1과 마찬가지로 사용되었다. on-prem으로 Kafka 등을 구축하는 것보다 관리의 측면에서 편리하고, 비용 또한 큰 부담이 될 정도는 아닐 것이라 판단했기 때문이다.
• Cloudflare R2: S3 호환 스토리지로, 크롤링한 HTML 파일을 압축하여 저장하는 데 사용된다. S3에 비해 상대적으로 저렴한 비용과 무제한 저장 공간이 장점이다.
• K8s
  • 크롤러 (C++)
    • HTMLCrawler: Pub/Sub에서 대상(블로그 글)을 받아 HTML을 크롤링해 html-storage에 전달한다.
    • LinkFinder: Pub/Sub에서 대상(블로거)을 받아 글 목록을 크롤링해 Pub/Sub에 글 링크를 추가한다.
    • ProfileFinder: Pub/Sub에서 대상(블로그 글)을 받아 연관 블로거들을 찾아 Pub/Sub에 블로거를 추가한다.
  • 크롤러 작동을 지원 (Go)
    • html-storage: 크롤러가 크롤링한 HTML을 로컬 스토리지에 임시로 저장, 파일의 메타데이터 또한 저장하는 서비스.
    • link-kv: 링크 중복 방지 등을 위한 키-값 저장소. pebble을 사용한다.
  • 기타
    • cron-task: 주기적으로 html-storage에서 파일 개수를 조회, Hugging Face의 geulgyeol 페이지에 반영한다.
• 외부
  • archiver: html-storage에 임시로 저장된 HTML 파일을 S3-Compatible 스토리지(여기에서는 Cloudflare R2)에 .zip로 묶어 업로드
  • Parser: archiver의 zip 파일들을 받아 파싱, parquet 형식으로 변환/필터링(TBD)

쿠버네티스 클러스터의 구성

먼저 이 클러스터는 on-prem으로 구축되었으며, k3s를 사용했다. 이는 노드들의 성능을 고려한 것이다. 이 외에도 여러 구성 요소를 간단히 소개한다.

• traefik: Ingress Controller로 사용되며, 외부에서 내부 서비스로 접근할 수 있도록 한다.
  • oauth2-proxy: Github OAuth로 내부 서비스의 접근을 제한한다.
• Longhorn: 분산 스토리지 솔루션.

Prometheus와 Grafana 또한 구성했었으나, 현재는 사용하지 않고 있다.

사용되고 있는 노드들은 다음과 같다.

• RPI 4B x 2
• Vultr
  • AMD High Performance 2vCPU, 4GB RAM
  • High Frequency 1 vCPU, 2GB RAM - 곧 뗄 예정이다.
• OCI Free Tier VM x 4
  • 2대는 AMD, 2대는 ARM
  • 자주 죽어서 사실상 2-3대로 보는 것이 올바르다.

현재 문제

현재 속도는 약 15건/초 정도인데, 이는 시즌 1에서 2대 노드로 달성했던 속도보다도 느리다. 이는 아직 원인을 파악 중이지만, 나는 html-storage의 병목이나 HTMLCrawler을 ARM 노드에서 QEMU로 돌리고 있는 것이 주된 원인일 것이라고 추측하고 있다. 목표하는 성능은 노드 수에 따라 50건/초 가량을 달성하는 것이다.

향후 계획

블로그 글은 그 특성상 멀티모달 데이터셋으로 삼기에도 적절하며, 이에 관해 관심을 보여 주신 분도 계셨다. 이에 따라 멀티모달 또한 계획에 삼고 있다. 하지만 이보다 기본적인 확장 계획의 경우 필터링이다. 시즌 1의 경우만을 살펴보더라도 광고 글이나 스팸 글이 다수 포함되어 있었으며, 예상치 못하게 일찍 종료하는 바람에 필터링까지 진행하지 못했다. 시즌 2에서는 fineweb에서 적용된 것처럼 여러 필터링 기법을 수행할 것이다. 또한 합성 데이터셋 또한 당연히 고려하고 있는 부분이다. 해례 팀과도 함께하여 더욱 높은 품질의 데이터셋을 만들어나가고자 한다.

마치며

이 글에서는 글결 시즌 2의 새 아키텍처와 문제점, 향후 계획을 다루었다. 앞으로도 개발 일지를 통해 과정을 공유하고자 한다. 글결 프로젝트에 관심이 있다면 언제든지 연락해 주시길 바란다.

여담

사실은 11월 27일부터 사실상 본격적으로 가동하고 있었으나, 중간에 longhorn 스토리지가 넘쳐 이미지가 복구 불가능해져 12월 17일부터 초기 상태로 다시 시작하게 된 것이다. 당시 이미 1천만 건 가량의 데이터가 있었고, 이를 12월 17일에서 다시 복구하는 데에는 약 9일의 시간이 걸렸다. 현재는 약 1,200만 건의 데이터가 수집되었으며, 앞으로도 꾸준히 데이터를 쌓아 나갈 예정이다.

@misc{devngho202520251227geulgyeols2devlog1,
  author       = {Yu, Dongho},
  title        = {시즌 2 개발 일지 #1: 새 아키텍처 구성},
  howpublished = {\url{https://ngho.dev/posts/20251227-geulgyeol-s2-devlog1}},
  year         = {2025},
  month        = {dec},
  note         = {Accessed: 2025-12-27}
}

@misc{devngho202520251227geulgyeols2devlog1,
  author       = {Yu, Dongho},
  title        = {시즌 2 개발 일지 #1: 새 아키텍처 구성},
  howpublished = {\url{https://ngho.dev/posts/20251227-geulgyeol-s2-devlog1}},
  year         = {2025},
  month        = {dec},
  note         = {Accessed: 2025-12-27}
}