처음에는 임팔라로 이관하는 방법을 생각, 하지만 임팔라는 암시적 형 변환이 지원되지 않아서 숫자형 변수를 하려면 dicimal로 꼭 캐스팅을 해줘야함. 그래서 많은 쿼리에 캐스트를 해줘야했고 몇 지원안되는 함수 때문에 마이그레이션 비용이 컸음
반면 스파크는 암시적 형 변환이 지원되고 오라클 문법 대부분 지원됨(단, Merge Into는 delta Lake, Hudi, IceBerg와 같은 스토리지 필요→100개 넘는 배치 프로그램 바꾸는데 1명의 개발자가 1달도 안걸리는 등 임팔라 대비 비용 축소
토스뱅크에서는 GoCD를 통해서 제3자검증, 서비스/배포 책임자 검증, 배포 이력 관리를 하고 있다
앞으로 방향성
차세대 DW 시스템(후디, 아이스버그 등)
CDC 시스템 고도화(noSQL CDC 구축 예정)
스쿱을 대체할 Nifi 도입 준비
Kafka 이중화로 다양한 장애 상황 완벽 대처하기
토스증권에서 카프카가 어떻게 활용되는지
사용자에게 실시간으로 제공하는 거래소정보, 로그, 분석 등에 카프카를 활용하고 있음
카프카 자체가 가용적으로 디자인된 아키텍처이고 모니터링으로 대응 프로세스를 통해 클러스터의 일부 노드 장애는 극복이 가능하지만 IDC 전면 장애의 경우에는 IDC 이중화가 안되어 있다면 치명적임
증권사는 IDC 장애에 대응하도록 메인 IDC와 떨어진 IDC에 DR(Disaster REcovery)를 구축해야함
DR은 보통 Active-Standby로 구성함 Standby가 장애시 Active로 전환
하지만 장애 상황이 발생했음에도 Standby를 잘 관리해주지 않으면 버전문제나 장애가 해결이 안되는 경우가 발생하기 때문에 토스증권에서는 평소에도 Active-Active로 이중화 구성해서 사용중
카프카의 STATE의 일관성을 어떻게 유지할지 고민해보고 이중화를 구성하는 것이 포인트
이중화를 통해 양쪽 IDC로 유저의 트래픽이 각 50%씩 나눠 가지고 있음
특이한 건 한쪽 IDC만 컨슈머가 존재함→메세지 미러링을 통해서 전체 합치면 메세지양이 200%가 되기때문에 컨슈머가 양쪽에 붙으면 두 배 중복해서 소비하는 상황을 방지하기 위해서
모니터링
클러스터에 발생하는 메트릭 정보를 프로메테우스로 수집하고 타노스 룰러를 이용해서 정의한 조건이 충족되면 알림을 주는 방식으로 모니터링 구현
클러스터 로그는 엘라스틱서치를 통해 에러 로그 발생을 엘라스틱얼럿으로 받고있다
현재 시계열 데이터의 이상 징후를 탐지하는 머신러닝 모델도 개발하고 있음
대규모 로그 처리도 OK! Elasticsearch 클러스터 개선기
토스증권에서는 하루 수십억건 로그를 엘라스틱서치로 검색하고 분석하고있음
일일 6TB, 약53억 건
90일 리텐션 570TB, 4800억 건
거의 대부분 로그 검색과 분석은 최근 보름 이내의 로그를 대상으로 하기에 Hot-Warm 아키텍처로 도입해서 운영하기로 함→Hot Node보다 3배 더 큰 디스크를 가진 Warm Node를 구성 후 생성된 지 오래된 인덱스는 Warm 이동하도록 인덱스 생명주기 관리 정책을 구성함, 90일 리텐션 설정
엘라스틱 서치 튜닝
점점 적재되는 양이 많아지면서 클러스터 내부 오류가 잦아짐
매무 많은 Fielddate 메모리 사용
빈번한 Long GC 발생
Stop the World
인덱스 맵핑에서 일부 필드 설정에 필드데이터 옵션을 잘못 사용한 경우
mapping Explosion
입력으로 들어오는 json key가 많으면 동적으로 스키마를 업데이트하는 과정에서 리소스를 많이 사용해 클러스가 불안정해짐
따라서 동적 필드 매핑을 사용하지 말고 구조화되지 않은 문자열이 들어가는 필드는 text타입, 그 외에는 keyword, numeric등으로 맵핑되도록 하는 것이 중요
엘라스틱서치가 불안정해지면 맨먼저 인덱스 맵핑을 봐주는 것이 좋다 그 다음으로 샤드를 살펴봐야한다
프라이머리 샤드를 더 늘린다면 샤드가 특정Node에 쏠리지 않게 샤드의 수를 Hot 노드의 배수로 설정하는게 좋음
로그스태시에서 벡터로 전환
로그스태시는 JVM기반으로 시스템 자원을 많이 사용함, 파이프라인이 늘어나면 날수록 메모리를 많이 사용하게됨→경량화 필요
vector
fluentd
다양한 유즈케이스가 있는 fluentd지만 로그 가공이 로그스태시나 벡터에 비해 불편하다는 판단에서 최근 급성장하고 있는 vector로 선택
벡터는 로그스테시처럼 코드로 유연하게 작성할 수 있다는 강점
공식 홈페이지의 메뉴얼이 잘되어있음
프로메테우스로 로그파이프라인 모니터링을 쉽게 구현 가능
최근 급격히 관심을 받으며 스타수로 플루언트디를 넘어섬
데이터센터 확장
각 IDC마다 클러스터를 복제해서 사용한다는 것은 비용이 크게 증가함에 따라서 IDC 간에 하나의 클러스터를 구축할 수 있는 방법에 대해서 고민
노드들이 빈번하게 통신하는데 데이터 센터 간의 네트워크 레이턴시가 높으면 클러스터 전체적으로 성능저하가 발생해 엘라스틱 서치에서는 권장하지 않음
가까운 IDC간의 레이턴시 정도면 조금의 지연보다 비용절감으로 오는 효과가 더 크다는 판단
느낀점
카카오 사태를 반명교사 삼아 DR에 대해 대처하기 위해서 많은 준비를 한 것 같다. 꼭 그 사태때문만이 아니라 원래부터 증권이나 뱅크쪽은 DR에 대해 더 다른 도메인보다 중요하긴 하지만….
왜 다른 오픈소스가 아니라 이 오픈소스여야하는지 이유를 들어 설명하는 부분이 좋았다. 어떤 트레이드오프 때문에 선택했는 지를 각자의 회사마다 개인마다 다르기 때문에 지금 어떤 것이 가장 최우선인지 중요한 가치가 무엇인지에 더 집중해야겠다.
