IT뉴스 스크랩

대규모 트래픽하면 언급되는 이야기들

  • 유저의 트래픽
  • 트래픽이 1차적으로 접근하는 인프라
  • 인프라가 트래픽을 전달해 줄 시스템
  • 시스템의 프로세싱으로 발생하는 로그
  • 시스템을 수정하고 로그를 검색하는 관리 도구

1. 인프라 (Infrastructure)

[!NOTE] 기사 요약

  • 배어메탈 장비를 IDC에 넣었다.
  • 다수의 장비를 Docker Orchestration으로 운용하기 위해 fleet를 구축해두었다. 근데 여러 노드 중 하나가 죽었다. 보통은 죽은 노드에서 실행되던 컨테이너가 여유가 있는 다른 노드에 떠야 한다.
  • 그러나 fleet에 등록된 모든 컨테이너가 꺼졌다 켜졌다 하는 파도타기를 시작했다. IDC로 달려가서 배어메탈 장비에 직접 접근해 fleet 연동을 끊고 컨테이너를 수동으로 올려서 조치하려고 했다. 플랫폼 서버가 접근 제어를 deny all을 기반으로 allow list를 만들어서 운영한다는 걸 뒤늦게 깨달았다.
  • 지금이라면 서버 쪽의 outbound 지점을 하나로 묶고, static IP를 구매해서 public IP를 하나로 만들어야 했다

베어메탈(Bare Metal) 장비와 IDC

  • 상황: 클라우드(AWS 등)가 아닌 물리 서버를 직접 데이터 센터에 입주시켜 사용.
  • 기술 해설:
    • IDC (Internet Data Center): 서버를 보관/운영하기 위한 전용 건물. 전력, 냉방, 네트워크를 제공.
    • 베어메탈: 가상화 계층(OS 가상화)이 없는 순수 물리 서버.
    • 사용 이유: 가상화 오버헤드가 없어 최고의 성능을 낼 수 있고, 대규모 운용 시 클라우드 비용을 절감할 수 있음.

Docker Orchestration과 ‘파도타기’ 현상

  • 상황: 서버 관리 도구(Fleet)가 죽은 노드의 컨테이너를 다른 노드로 옮겼으나, 과부하로 인해 다른 노드들도 연쇄적으로 다운되는 현상 발생.
  • 기술 해설:
    • Docker (도커): 애플리케이션을 실행 환경과 함께 패키징(컨테이너)하는 기술.
    • Orchestration (오케스트레이션): 다수의 컨테이너를 배포, 관리, 확장하는 기술 (예: Kubernetes, 과거의 Fleet).
    • Fleet: CoreOS의 초기 클러스터 관리 도구(현재는 거의 사용 안 함).

접근 제어(ACL)와 Outbound IP

  • 상황: 보안을 위해 특정 IP만 허용(Allow List)했으나, 서버들이 나가는(Outbound) IP가 제각각이라 통신 차단됨.
  • 해결: 서버들의 나가는 통로를 하나로 묶어 단일 고정(Static) IP를 사용해야 외부 연동 및 보안 관리가 수월함.

시스템

[!NOTE] 기사요약

mongodb 배어메탈 서버에 용량이 가득 찼던 이슈

  • 1TB SSD가 꽂혀 있는 배어메탈 서버하나를 통으로 쓰는 게임이었음. 근데 이게 가득 차서 replication을 만들어 해결하려고 했으나 master node에 전체 용량의 40% 이상의 여유가 있어야 가능했음. 그래서 rsync로 로컬에 data 폴더 전체를 복사했다.그걸 10TB로 이전시켜 IDC에 갖다 넣음

redis를 db처럼 쓰던 시스템에 생긴 참사

  • redis cluster가 나오기 전의 설계였는데, codis라는 걸 사용한 서버가 있었음. 근데 64GB 클러스터의 메모리가 꽉 차서 게임이 터짐.
  • 원인: sentinel, proxy, 나머지 노드의 분배를 위해 3개의 그룹과 여러 데이터 노드로 나눈 다음에, 128GB 클러스터를 늘려서 서비스를 다시 복구함.
  • 이후 게임의 업데이트를 위해서 서버를 잠시 중단시킬 떄는 Codis 코드 전체의 foreground save 이후에 dump.rdb 파일 백업과 현재 메모리 상태를 체크하는 괒어을 추가함

MongoDB 용량 초과와 복제(Replication) 실패

  • 상황: 디스크가 100% 차서 DB 복제(Replication)를 위한 임시 공간(Oplog) 확보 실패.
  • 해결: DB 자체 기능 대신 rsync 명령어로 데이터를 물리적으로 복사하여 이전.
  • 기술 해설:
    • MongoDB: 유연한 문서 지향(NoSQL) 데이터베이스. 게임 데이터나 로그 저장에 주로 사용.
    • Rsync: 리눅스/유닉스 환경에서 파일과 디렉토리를 네트워크로 동기화(전송)하는 강력한 유틸리티.

Codis와 메모리 부족(OOM)

  • 상황: Redis 클러스터 도입 전, Codis를 사용해 여러 Redis를 묶어 쓰던 중 메모리가 가득 차 서비스 중단.
  • 기술 해설:
    • Redis: 데이터를 디스크가 아닌 메모리(RAM) 에 저장하는 초고속 DB. 주로 캐시나 세션 저장소로 사용.
    • Codis: Redis 공식 클러스터 기능이 나오기 전, 여러 Redis 노드를 하나처럼 쓰게 해주던 프록시(Proxy) 도구.

Foreground Save (서비스 중단 후 저장)

  • 상황: 메모리가 꽉 차면 백그라운드 저장(BGSAVE) 시 메모리가 부족해 실패함.
  • 해결: 서비스를 잠시 멈추고(Foreground), 전체 데이터를 디스크에 저장(dump.rdb) 및 백업하는 절차를 추가하여 데이터 유실 방지.

로그

[!NOTE] 기사요약

  • 보관, 검색할 수 있는 시스템을 만드는 게 중요함
  • 연 3억 쓰던 Redshift를 없애고 elasticSearch를 도입한 일
  • 데스크탑 한대에 RAM을 꽉 채워 넣고, 거기에 elasticSearch를 구축해서 2년치 로그만 검색이 가능한 시스템을 구축. 검색하는데 7초~2분 걸림.

Redshift에서 Elasticsearch로 전환

  • 상황: 단순 로그 검색용으로 고비용의 Redshift를 쓰다가, 검색에 특화된 Elasticsearch로 교체하여 비용 절감.
  • 기술 해설:
    • Redshift: AWS의 대용량 데이터 웨어하우스. 복잡한 분석에 적합하며 비용이 높음.
    • Elasticsearch: 텍스트 검색 및 분석 엔진. 로그 검색, 실시간 모니터링에 표준처럼 쓰임.

고용량 RAM 데스크탑 활용

  • 전략: Elasticsearch는 메모리를 많이 소모함. 클라우드 고사양 인스턴스 대신, 일반 데스크탑에 RAM을 가득 채워 저렴하게 ‘로그 검색 전용 머신’을 구축. (가성비 최적화)

관리도구

[!NOTE] 기사요약

  • 프로메테우스, 그라파나??

프로메테우스(Prometheus) & 그라파나(Grafana)

서버 모니터링의 사실상 표준(De facto standard) 조합.

  • Prometheus (수집가):
    • 역할: 서버의 CPU, 메모리, 네트워크 트래픽 등 각종 지표(Metric)를 주기적으로 수집하고 저장.
    • 특징: 시계열 데이터베이스(TSDB) 기반으로 변화 추이 기록에 최적화.
  • Grafana (화가):
    • 역할: Prometheus가 수집한 데이터를 가져와 보기 좋은 그래프, 차트, 대시보드로 시각화.
    • 용도: 장애 발생 시점 파악, 리소스 사용량 실시간 관제.

읽은 사이트: https://yozm.wishket.com/magazine/detail/3006/

results matching ""

    No results matching ""