개요
토렌트는 유명해지기 전부터 이미 어느정도 알고 있었으나 실제 내부에서 어떻게 돌아가는지에 대해서는 별다른 관심이 없었다.
그러다가 어느순간 회사에서 토렌트 관련 프로젝트를 진행하게 되어 수집을 해볼 기회가 있었고 생각보다 많고(정말 많다...) 다양한(?) 데이터를 얻을 수 있었다. (물론 토렌트 특징 상 실제 데이터 다운로드는 하지 않고 오직 메타 데이터로만 분석했다..)
한동안 관심이 없다가 얼마전부터 다시 토렌트에 관심이 생겼고 다시 한번 아키텍처를 설계해보기로 마음먹었다.
물론 이번건은 회사로써가 아니라 개인으로써 진행하는 프로젝트이고 최근에 다른데 지출이 많아서
극단적으로 제한적인 예산으로만 아키텍처를 설계하고 구축해보았다.
요구사항
아키텍쳐를 설계하기전에 미니 프로젝트를 진행하기 위해 필요한 요구사항을 리스트해보았다.
- 가장 기본적으로 토렌트 메타 정보가 수집되고 저장되어야함
- 수집된 메타 정보에는 이름, 크기 등의 정보가 있고 분석을 위해 정보를 인덱싱하고 토큰화해서 검색할 수 있어야함
- 메타 정보를 통해 토렌트의 카테고리를 자동으로 생성할 수 있어야함
- 메타 정보를 수집하고 분석하기 위한 인프라를 저비용으로 구축해야함
이 중 3번의 경우, 규칙 기반으로 카테고리를 구분하거나 AI를 이용해서 자동으로 분류할 수 있도록 해야하는데 AI에 대한 지식은 부족하기 때문에 우선 규칙 기반으로 카테고리를 구분할 수 있도록 파이프라인을 구성
설계
가장 최소한의 아키텍처로 구상해보았는데 아키텍처라 부르기도 애매할 정도로 심플 of 심플로 구성되어 있다.
비용절감의 목적도 있고 현재 단계에서 굳이 복잡하게 아키텍처를 시작할 필요는 없다고 보기 때문이다.
각각 리전이 다른 2대의 DHT 모니터와 EK 노드로 구성되어 있다. 중간에 Logstash나 Kafka를 구성하지 않은 이유는 현재는 굳이 넣어야할 정도로 데이터의 중요도가 높지 않고 규모도 크지 않기 때문이다.
검색을 위한 웹 서버는 따로 구성하지 않고 Elasticsearch 노드에 같이 설치한 Kibana로 확인하려고 한다.
나중에 분석을 하거나 규모가 커질 경우, 이를 개선하기 위해 아키텍처를 개선할 예정이다.
클라우드
위 아키텍쳐를 구축하기 위해 다양한 클라우드를 조사해보았고 그 중 DigitalOcean, Vultra, AWS 중 최종적으로 DigitalOcean을 선택했다. DigitalOcean의 특징은 다음과 같다. 다른데와 비교해서 개인이 시작하기 가장 무난한듯하다.
DigitalOcean
장점
- 저렴한 비용 (최소 $5 시작)
- 다른데 비해 비교적 유명한 브랜드
- Droplet에 연결된 경우 공인 IP 무료 (생성만하고 연결되지 않은 경우 $4/월)
단점
- 정지된 Droplet도 과금 (찾아보니 종료하더라도 CPU, 메모리 등 자원을 여전히 점유하기 때문이라고 한다. 스냅샷을 만들고 제거하면 싸긴하다.)
- 대한민국 리전 부재
- Managed Database 비싸고 제한적이다 (원래는 이걸 쓸 계획이였다.)
비용
DigitalOcean으로 결정 후 클라우드 비용 견적을 아래와 같이 내보았다.
보다시피 매우 심플하다 못해 아키텍처라 부를만한게 없기도한 구성이지만 비용 문제와 현재 사용처를 생각해보고 결정한 구성이다.
최대 $100/월로 예산을 잡아두었기 때문에 추후 메타 데이터 저장을 위한 스토리지 증설과 분석과 추가 처리가 필요할 때 인스턴스 추가할 수도 있다. 현재도 계속 수집 중인데 Elasticsearch 인스턴스의 기본 제공되는 용량 중 60%를 채웠다.
견적
이름 | 목적 | 스펙 (CPU / 메모리) | 비용 |
ubuntu20lts-monitor-001 | 토렌트 DHT 네트워크 모니터링 | 1C/1G | $5 |
ubuntu20lts-monitor-001 | 토렌트 DHT 네트워크 모니터링 | 1C/1G | $5 |
ubuntu20lts-redis | 분석을 위한 캐싱 서버 | 1C/1G | $5 |
ubuntu20lts-es-001 | 메타데이터 저장 및 분석을 위한 Elasticsearch 서버 | 2C/4G | $24 |
쿠버네티스 어디?
DigitalOcean에서는 쿠버네티스 서비스를 사용할 수가 있는데 이 아키텍처에서는 적용하지 않았다.
굳이 DigitalOcean이라서 쿠버네티스를 사용하지 않은게 아니라 토렌트 수집 시스템 상 어떤 지역에 인스턴스를 생성하고 운영하느냐에 따라 수집되는 데이터가 다르기 때문에 쿠버네티스를 사용하지 않는게 맞다고 판단했기 때문이다.
스리슬쩍 넣는 리퍼러...
다른데 비해 비용과 제공되는 서비스를 고려해보았을 때 생각보다 맘에 든다.
일단 혼자서도 쓸 수 있을만한 납득할만한 가격이고 성능도 무난하다. 처음에 가입하면 $100 크레딧을 줘서 6개월내로 DigitalOcean 시스템이 안정적인지? 성능은 어떤지? 등 여러가지 시험겸 운영을 해보기에도 충분하다. 처음가입한게 7~8월 사이로 기억하는데 이 글을 쓰는 11월 시점에서 이제 크레딧을 다 소진하고 실제 결제를 하는 시점이다.
충분히 괜찮은 듯하니 혹시 생각이 있다면 아래 DigitalOcean 로고를 클릭하시면 됩니다. 🙂
구축 단계 및 결과
수집 시스템 구축을 위해 다음과 같은 진행해야할 프로세스 순서를 정의하고 진행해보았다.
이미 이전에도 구축을 해본 경험이 있고 작성한 코드도 기존에 만든걸 좀 더 체계적이고 효율적으로 작성한거라 구축 단계에서 발생한 이슈 중 크게 문제가 될만한건 없었다. 오히려 구축보다 검색을 위해 Elasticsearch에서 여러가지 시도함에 있어서 많은 삽질이 있었다.
- Elasticsearch 용 인스턴스 생성 및 Elasticsearch과 Kibana 설치와 연동 및 동작 테스트
- Redis 용 인스턴스 생성 및 Redis 설치 및 동작 테스트
- 작성한 수집 모니터링 프로그램을 돌리기 위한 인스턴스 생성과 설치 및 테스트
- 모니터링 인스턴스의 스냅샷을 생성 후 동일한 역할을 하는 2번째 인스턴스 생성
Kibana 대시보드 구성 화면 중 토렌트 수집 통계 (지난 7일의 통계)
앞으로는?
구축된 수집 시스템을 이용해 지속적으로 수집을 하고 분석을 진행해 볼 예정이다.
실제 토렌트의 데이터를 다운로드하는건 위험하고 어떤 데이터가 있는지 실제 모르기 때문에 하지 않고 오직 수집되는 데이터로만 어떤게 될지 한번 해보려고 한다. 보안쪽에서는 이미 많은데서 수집하고 있고 기록을 보여주는 유명한 사이트도 있기 때문에 사업적인 면으로도 크게 될만한 건 없을 것으로 예상하지만 어느 시스템을 구축을 해서 꾸준히 운영을 해본다는 경험이 필요할 것 같아서 이걸로 진행해볼까 한다.
유의미한 통계가 있으면 가끔씩 블로그에 공유할까 한다.
'아키텍처' 카테고리의 다른 글
Redpanda 짧은 도입 후기 (0) | 2023.05.30 |
---|