13 분 소요

SLASH 23 후기 :

은행 데이터플랫폼 오픈소스로 전환하기

1. SLASH 23

1.1. 참석 계기

  • 토스 유튜브를 구독하고 있어서 바로 SLASH 23 홍보 영상을 보게 되었고, 바로 참석 신청을 했다.
  • 개인적으로 토스의 SLASH는 문제 정의부터 해결까지 전반적인 과정을 공유해줘서 현업 개발자로서 문제 해결 과정을 엿볼 수 있어 좋다.
  • 해당 포스팅은 토스 SLASH 23의 데이터 엔지니어 세션 중에서 은행 데이터플랫폼 오픈소스로 전환하기를 다루며, 정보 구조화 및 공유를 목적으로 작성한다.

1.2. 데이터 엔지니어 세션

2. 은행 데이터플랫폼 오픈소스 전환하기

2.1. 문제 인식

1) 시스템 구조

  • 초기에 타 은행 시스템 구조와 동일
    • 계정계 : 은행의 거래 데이터를 다루는 시스템 (입금, 출금, 외환 등)
    • 채널계 : 비대면 채널들을 관리하는 시스템 (모바일 뱅킹, 인터넷 뱅킹)
    • 정보계 : 고객의 거래 데이터를 가지고 통계 및 분석하는 영역
  • 토스뱅크 플랫폼
    • 계정계 : Oracle → 정보계(Oracle Exa)
    • 채널계 : Kafka, MySQL, Tibero, MongoDB → 정보계(Hadoop)
    • 정보계 : Hadoop(분석) ↔ Oracle Exa(단위업무)
      • Kafka의 로그 데이터 분석, CSS Feature 관리 업무와 같은 빅데이터 영역을 위해 Hadoop 도입
      • 보고서나 단위 업무 처리 시 Oracle Exa에서 진행

2) 문제점

  • 불필요한 데이터 이동 발생
    • 보고서나 단위 업무 처리 시 Hadoop 데이터를 Oracle Exa로 보내야 함
  • 대용량 데이터 처리 시스템 2개 존재

3) 개선 방안

  • 대용량 데이터 처리 시스템을 Hadoop 하나로 통일
    • 동일 용량 대비 구축 비용이 Hadoop이 Oracle Exa보다 10배 이상 저렴
    • Oracle Exa의 정보계성 단위 업무들을 Hadoop으로 이관

4) 도전 과제

  • 가능성 : 기존 플랫폼을 무엇으로, 어떻게 대체할 것인가?
    • Oracle Exa, Scheduler, CDC 와 같은 여러 기술 컴포넌트 포함
  • 정합성 : 옮기면서 정합성을 어떻게 맞출 것인가?
    • 은행은 한국은행, 금감원과 같이 대외기관에 공시/보고 의무 있음
    • 기존 시스템과 동일한 값임을 어떻게 보장해야 할지 중요
  • 효용성 : Oracle 비용 절감 효과보다 옮기는데 발생한 비용이 더 큰가?

2.2 가능성

1) 대체 오픈 소스

  • 기존에 사용했던 솔루션들을 오픈 소스로 대체한다.
  솔루션 오픈 소스
Scheduler Scheduler Solution Airflow
Storage Oracle HDFS/KUDU
Query Engine Oracle Query Engine Impala/Spark
ETL ETL Solution Sqoop
CDC Oracle Golden Gate Debezium
  • Airflow & Github
    • 토스뱅크의 많은 서비스들은 k8s 에서 돌림
    • Helm chart를 통해 설치가 쉽고, Scale Out 이 쉬움
    • 코드로 파이프라인 작성이 가능하기에 코드 검색이 쉬움
    • Custom Operator 작성이 쉬움
  • HDFS & KUDU
    • Oracle과 달리 HDFS는 PK, Secondary Index가 지원되지 않음
    • PK를 위해 KUDU 사용 (대부분의 DW는 PK만으로도 충분)
  • Impala & Spark
    • 표준 Ansi SQL 기반 SQL 문법 제공
    • Impala : 쿼리 결과를 변수에 담아 다음 쿼리에 이용하는 로직 구현 어려움
    • Spark : Java, Python 등의 언어로 로직 작성 가능하기에 자유도 높음
    • Ranger로 접근 제어
  • Sqoop
    • ETL 솔루션 : DB 부하를 적게 주기 위해 파일 기반으로 추출
    • ETL 오픈 소스 : Query 기반으로 추출하기에 자유도는 높지만 DB 부하가 상대적으로 큼
    • 추출할 데이터 Query에 맞게 Table도 Indexing 처리 필요
  • Debezium
    • 지원 DB가 MySQL, Oracle, MongoDB 등 다양하며 안정성 높음
    • Debezium으로 Oracle CDC 구축 방안
      • Logminer : 무료, 성능 및 안정성 낮음
      • XStream API : 유료, 퍼포먼스 좋고, 2.8배 정도의 Throughput 차이
      • 라이브 환경에서 Log Switch가 DEV 환경보다 더 빈번하기에 20배 이상의 차이

2) ETL과 CDC 작업

  • ETL과 CDC 작업 시 서비스 DB에 부하를 줄 수 있음
    • Read Only Slave DB에서 ETL 작업
    • 계정계의 Oracle은 BCV DB에서 ETL 작업
    • Update 되는 테이블에 대해 updated_at 필드 추가해서 업데이트된 데이터만 ETL 해갈 수 있도록 구성

3) Airflow 선후행

  • Batch Job 을 Bit Operator 통해 선후행 설정
  • 다른 DAG의 Task들과 선후행 지정 시 Trigger가 아닌 Sensor 사용
    • 월별 작업이 일별 작업 완료 후에 실행되어야 함
  • Airflow에서 제공하는 ExternalTaskSensor 상속받아 Sensor 새로 생성
    • 선행 작업의 DAG 실행 시간(schedule interval) 변경되면 후행으로 잡은 Task Sensor의 execution date function도 전부 바꿔야 함 (관리 포인트)
    • Sensor 생성 시 Time Range를 일, 시간 단위 등으로 time slice 값 넣도록 하고, time slice 안에 실행된 선행의 Task 가 있다면 Sensor가 OK하도록 구현
  • 이기종 간 Scheduler 가 존재
    • 기존의 Scheduler의 모든 작업을 Airflow로 옮길 수 없었기 때문에 2개 존재
    • DB/File을 이용해 선행 작업 완료 시 Sync, Sensing 구현

2.3. 정합성

1) 기존 Flow

  • 원천 DB → 정보계
    • Oracle 정보계 : 원천 ETL → 공통 마트 → 리스크 마트 → 보고서 마트
    • Hadoop 정보계 : 원천 ETL → 공통 마트

2) 원천 ETL

  • 원천 DB에서 ETL 시 Snapshot 으로 수행하므로 정합성 검증 필요 없음

3) 마트 이관

  • 공통 마트 영역을 Hadoop으로 이관

  • Oracle에 적재된 공통 마트 영역 ETL → Hadoop에 적재

  • Hadoop에서 만든 마트와 정합성 체크하는 Batch 생성
    • 주기적으로 실행해서 1-2주 정도 데이터가 틀리지 않았다는 것 확인
  • Hadoop에서 만든 공통 마트 → Oracle로 ETL하는 Batch 생성
  • 후행에 걸린 마트(리스크 마트 등)는 Hadoop에서 건너온 공통 마트 참조
  • 문제 없으면 선행으로 돌던 Oracle 배치 삭제
  • 같은 방법으로 리스크 마트도 수행
    • Oracle의 리스크 마트 → Hadoop에 적재
    • Hadoop에서 정합성 Batch 주기적으로 실행
    • 문제 없으면 Oracle로 ETL 하는 Batch 생성
    • 후행에 걸린 마트(보고서 마트)는 Hadoop에서 건너온 리스크 마트 참조
    • 문제 없으면 선행으로 돌던 Oracle 배치 삭제
  • 같은 방법으로 보고서 마트도 수행
  • 모든 이관 작업 완료 시, Oracle Exa 비움

4) 정합성 Batch

  • Spark의 union, row count 활용

    • Hadoop에서 만든 마트 = new_df
    • Oracle에서 넘긴 마트 = org_df
    new_df = new_df.dropDuplicates()
new_df.count = new_df.count()
org_df.count = org_df.count()
...
total_df = new_df.unionByName(org_df, allowMissingColumns=True)
total_df = total_df.dropDuplicates()
total_df_count = total_df.count()
...
if total_df_count != new_df_count:
    print("Different Data!")
elif total_df_count != org_df_count:
    print("Different Data!")

2.4. 효용성

1) Impala 활용 시 어려움

  • Oracle에서 지원되는 Syntax가 Impala에서 지원되지 않음
    • Impala에서 암시적 형 변환이 지원 X
      • Oracle에서 Decimal 데이터 → Cast 로 직접 변경해야 함
    •   , to_date, to_char 함수 지원 X
    • Rollup, Cube, Merge Into 함수 지원 X (Impala v3.2)

2) Spark 활용

  • Spark SQL Syntax는 Oracle과 유사한 Syntax를 제공
    • 암시적 형 변환 지원 O
      • Cast 필요 없음, 소수점 처리 방식도 유사
    • Oracle 문법 대부분 지원 O
    • 단, Merge Into의 경우 Hudi, Delta Lake, Iceberg와 같은 차세대 DW 오픈소스 도입 필요

3) 이관 후 성능 향상

  • Long Running Query 시간 단축
    • 일 수신계약 집계 작업 Query : 17분 → 4분
    • 월 대외보고서 지표 집계 작업 Query : 31분 → 1분
    • 자금 만기 CF 산출 내역 Query : 41분 → 1분
  • 업무 단위별 시간 단축
    • 신용리스크 마트 : 67분 → 37분
    • ALM 마트 : 100분 → 54분
    • 공통 마트 : 40분 → 1분
    • 월 보고서 마트 : 88분 → 14분
  • 대략 5.3배 성능 향상

4) 이관 후 운영 편의성 증가

  • 재수행 자동화
    • 기존 Scheduler의 경우 재작업 불가
    • 직접 작업자가 선행 Job 재수행 → 선행 Job 끝나는 것 확인 후에 후행 Job 재수행
    • Airflow의 경우 재수행 DAG 작성해서 원하는 시기에 재수행 가능
      • start_date, end_date
      • max_active_run, concurrency
  • 중복 ETL 요청 감소
    • 정보계를 Hadoop으로 통합하면서 ETL 요청 필요 없음
  • 코드 가독성 및 검색 용이
    • Github 하나의 Repo에 Schedule 코드, Program 코드 등 모여있음

2.5. 보안 / 컴플의 요건 고려

1) 전자금융감독규정 제 29조

  • 프로그램 등록, 변경, 폐기 내용의 정당성에 대해 제 3자의 검증을 받을 것
    • Airflow 의 Batch 프로그램도 해당됨
    • 배포 전 : 제 3자 검증을 받아야 함
    • 배포 시 : 서비스 책임자의 승인이 필요함
  • 기존 Airflow 의 Helm Chart
    • git-sync가 주기적으로 코드 가져감
    • Master Branch를 막고 PR을 통해 Merge 시 제 3자 검증 가능
    • 하지만 제 3자 검증 완료 시 바로 배포되어서 서비스 책임자 승인 불가
  • GoCD Pipeline + Helm Chart
    • 제 3자 검증, 서비스 책임자 검증, 배포 이력 관리 용도로 사용
    • git-sync의 auto polling 기능 끄고 GoCD에서 제 3자, 서비스 책임자 검증 완료 시 Agent에서 git-sync 수동 호출

2) 전자금융감독규정 제 30조

  • 일괄작업은 책임자의 승인을 받은 후 수행할 것

  • Heimdall 웹 서비스 개발

    • 일괄 배치 작업 통제해주는 서비스
    • Airflow에서 관리자 권한 전부 회수하고, Heimdall에서 Airflow DAG의 on/off 요청
    • Airflow 코드 배포 → Heimdall에 일괄배치 승인 요청 → 책임자 승인 → Heimdall DB에 승인 내역 기록 → DAG 스케쥴 on

3) Sentry에서 Ranger로

  • 기존에 Impala는 Sentry를 활용해 접근 제어
    • Impala 4.x 버전부터 미지원, 관리 부족 등으로 Ranger로 변경
  • Ranger의 장점
    • Hadoop 에코시스템 사용자별 접근 제어 기능
    • 권한별 / 테이블별 컬럼 마스킹, 해싱 기능
    • 권한별 테이블 데이터 Filter 기능 (특정 컬럼만 접근)
    • Hadoop 컴포넌트 Audit 로그 제공

2.6. 토스뱅크 데이터팀의 방향성

  • 차세대 DW 시스템
    • Hudi, Iceberg 도입 준비
  • CDC 시스템 고도화
    • MongoDB와 같은 NoSQL DB의 CDC 개발 예정
  • 시스템 전환
    • Attic Project(Retired) 된 Sqoop 대체할 Nifi 도입 준비

3. 생각

  • 은행 플랫폼 전환은 전자금융감독규정에 따라 더 엄격하고 정확하게 진행해야 한다는 것을 알았고, 그 중에서도 정합성과 승인 절차가 핵심인 것 같다.
  • 대용량 처리 플랫폼을 하나로 통합하면, 비용과 성능 상 큰 이점을 가진다는 것을 느꼈다.
  • 데이터 마이그레이션 시 정합성 보장에 union, row count를 활용했는데 다른 방법이 있는지 더 찾아봐야겠다.
  • 요즘 대부분의 회사가 클라우드 전환을 하고 있어서 오픈 소스 전환 사례를 찾기 힘들었는데, 흥미로운 시간이었고 문제 해결을 위해 최적의 방법을 찾는 과정에 얼른 참여하고 싶다.

REFERENCES

참고

[Airflow] 초급편 (3)

14 분 소요

Airflow 초급 3 : 태스크 의존성 패턴, 조건에 따른 태스크 실행, 태스크 간 데이터 공유, Taskflow API

[Airflow] 초급편 (2)

5 분 소요

Airflow 초급 2 : 콘텍스트 변수, 콘텍스트 변수 전달, 템플릿 작업

[Airflow] 초급편 (1)

6 분 소요

Airflow 초급 1 : Airflow의 특징, DAG 작성 순서, 스케줄링, 디자인 원칙

[Governance] Data Catalog

6 분 소요

데이터 카탈로그 : 데이터 거버넌스, 필요성, 장점, 관련 도구