금융 분야의 컴플라이언스 요구사항을 충족하면서도 효율적인 머신러닝 운영을 달성한 사례를 다룹니다.
기존 ML 서버의 문제점
- 비표준화된 개발 및 배포: 각 서버가 표준화 없이 개발되고 배포되어 ML 모델 이식에 어려움이 있었습니다.
MLOps 도입의 필요성
- 재사용 가능한 Feature Store 체계 구축: 일관된 데이터 피처를 관리하고 재사용할 수 있는 시스템이 필요했습니다.
- 유연한 리소스 활용 환경: 모델 특성에 맞춰 리소스를 효율적으로 사용할 수 있는 환경이 요구되었습니다.
- 표준화 및 자동화된 배포 환경: ML 모델 서빙에 필요한 개발 및 배포 과정을 표준화하고 자동화하여 효율성을 높이고자 했습니다.
AWS 도입 배경
- 다양한 관리형 서비스 제공: AWS는 다양한 관리형 서비스를 통해 인프라 구축 시간을 단축하고 비즈니스 로직 개발에 집중할 수 있게 합니다.
- 초기 비용 절감 및 유연한 리소스 사용: 오토스케일링 등을 통해 초기 비용을 절감하고 리소스를 유연하게 사용할 수 있습니다.
MLOps 데이터 흐름
-
Private Zone (카카오페이 자체 IDC):
- 하둡 데이터 플랫폼: 가명처리된 분석용 데이터와 철저한 접근제어를 거친 서빙용 데이터를 관리합니다.
- ML 모델 소비 서버: App Zone에 위치하여 모델을 활용합니다.
-
Public Zone (AWS):
- 모델 서빙: Apache Airflow를 통해 S3 스테이징 영역을 거쳐 Redis에 적재된 온라인 피처를 사용합니다. 모든 요청은 모델 프록시 서버를 통해 처리되며, 이 서버는 요청 전처리, 온라인 피처 조회, 서킷 브레이커 등의 역할을 수행합니다.
- 모델 개발: 분석 DB에서 S3로 데이터를 적재하고, Amazon Athena를 통해 쿼리로 조회합니다. Sagemaker Studio에서 노트북을 통해 모델을 개발하며, Feast를 사용하여 기존에 만들어진 피처 세트를 재사용하고 Athena로 직접 조회할 수 있습니다.
- 모델 학습 파이프라인: AWS Step Function을 통해 자동 학습이 이루어지며, 결과물은 S3 및 Sagemaker Model Registry에 저장됩니다. 모델 성능 평가 후 서비스에 배포됩니다.
데이터 보안
-
분석용 데이터: 식별자는 가명처리되며, 각 피처들도 집계 및 범주화를 거쳐 비식별 처리됩니다. AWS 저장소에서는 3개월이 지나면 자동으로 삭제되도록 설정되어 있습니다. Athena Workgroup 및 IAM Role을 통해 접근 권한이 설정되며, 쿼리 감사 로그를 남겨 강력한 권한 제어가 이루어집니다.
-
서빙용 데이터: Security Group을 통해 백엔드 서버만 접근 및 통신할 수 있으며, IAM을 통해 사용자가 직접 접근하여 조회하는 것은 원천 차단됩니다. AWS 저장소에는 최근 2일 데이터만 저장하고 이전 데이터는 영구 삭제하여 보안을 강화합니다.