�ݺ�ߣ

Editor's Notes

• #1: 안녕하세요. 삼성생명의 데이터 레이크하우스 구축 여정 발표를 진행 하게된 이광식이라고 합니다.
• #2: 우선 삼성생명의 ADW가 무엇인지 말씀 드리겠습니다. ADW는 시중에 나와있는 데이터 레이크처럼 내/외부 데이터를 쌓고 데이터 분석이나 머신러닝 등을 수행하는 시스템입니다. 이 데이터 레이크를 구축할 때 고려한 저희의 환경을 말씀 드리자면 점차 커져 가는 내/외부 데이터를 통합 분석하기 위해 마이데이터가 본격 적재되는 시점에 맞춰 데이터 레이크가 빠르게 구축되어야 하는 반면 인력은 주니어 중심이고 개인정보 보안을 간과할 수 없었습니다. 그래서 저희는 내부인력으로 빠르게 구축하고 운영은 최소화 하지만 핵심기술은 내재화 하고 기술을 육성하고자 했습니다. 나아가 중요 시스템 신고 또한 자체 진행하는것으로 결정했습니다. 끝으로 데이터 레이크 형태에 트랜잭션 기능, 데이터 권한 관리를 더한 레이크하우스 형태로 구축하기로 하였습니다.
• #3: ADW는 구축의 핵심 목표를 세가지로 정했습니다. 첫째, 속도입니다. ADW는 정해진 기간과 인력으로 직접 구축하기로 결정한 만큼 속도 확보가 중요했습니다. 이를 위해 AWS 의 다양한 매니지드 서비스 기반으로 아키텍처를 수립하고 인프라를 구축 운영하는데 CDK에 기반을 두었습니다. 둘째, 기술력 확보 입니다. AWS의 기술에 도움을 받기로 했지만 핵심 기술은 내재화 하고 내부 인력들을 육성하기 위해 노력했습니다. 셋째, 거버넌스 입니다. 금융사에서 구축하는 클라우드 시스템인 만큼 보안 준수와 데이터 권한 관리에 많은 노력을 기울였고 끝으로 데이터 품질을 확보하고 클라우드 사용 비용을 최소화 하기 위해 노력했습니다. 앞으로 이 3가지 핵심 목표들을 하나씩 살펴보며 얻은 lesson & learned를 공유하고자 합니다.
• #4: 첫째, 속도에 관한 여정을 말씀 드리겠습니다.
• #5: 앞서 말씀드린것 처럼 AWS 매니지드 서비스 기반으로 아키텍처를 수립하였습니다. 아키텍처의 핵심은 데이터 규모에 따라 확장 가능한 형태로 서버리스 기술들을 대거 사용하여 구성했습니다. 이와 관련된 아키텍처 설계 특징 4가지를 설명 드리겠습니다. 첫째, 기술 레버리지 입니다. 만약 지금의 시스템을 On-Prem에서 하둡 기반으로 구축하려면 필요한 장비, 전문성을 보유한 인력 등 비용과 시간이 많이 발생하게 됩니다. 이를 AWS의 다양한 매니지드 서비스를 조합하여 구축함으로써 빠른 속도와 보장된 품질로 구축 할 수 있었습니다. 둘째, 언어 입니다. 저희는 내부에 많지 않은 엔지니어와 싸이언티스트들 보유하고 있습니다. 이들의 공통점은 파이썬으로 업무를 수행하는데 불편함이 없어 파이썬 기반으로 기술스택을 통일하는 선택과 집중을 했습니다. 따라서 왼쪽 그림에서 MWAA, Glue ETL, Sagemaker 모두 파이썬으로 작업할것을 염두해 두고 설계 하였습니다. 그 결과 엔지니어 업무와 사이언티스트 업무를 넘나드는 협업에서 불편함이 최소화 되고 있습니다. 셋째, 비용입니다. 저희는 서버리스 기술 중심으로 시스템을 구성하였는데요. 서버리스라는 이름에 걸맞게 서버가 켜져있어 발생하는 과금이 최소화 되게 운영되고 있습니다. 이 구조에서는 ETL이나 쿼리 조회가 발생할때만 과금이 발생하고 평시에는 부담할 서버비용이 최소화 됩니다. 소규모 데이터 레이크로 시작하는 기업에서 유리할 것 같습니다. 끝으로 확장성입니다. 데이터 레이크의 핵심에 해당하는 SQL Engine의 경우 저희는 Amazon Athena로 선택 했습니다. Amazon Athena의 근간이 되는 오픈소스 Presto를 활용하여 차후 EKS, EMR등으로 얼마든지 시스템을 확장할수 있다는 확신이 있어 이렇게 정하게 되었습니다.
• #6: 저희는 파이썬 버전의 CDK로 100% 인프라를 구축한 덕분에 3달만에 인프라를 완성하였습니다. CDK가 익숙하신 분들도 있겠지만 생소하신 분들을 위해 부연설명을 드리자면 AWS의 S3, KMS와 같은 리소스를 프로그래밍을 통해 보다 빠르고 안전하게 생성하는 도구입니다. 예를 들자면 CDK로 S3 버킷 생성 코드를 한번 짜두면 앞으로 S3 버킷을 또 만들일이 있으면 빠르게 생성 할 수있습니다. 또한 저희는 CDK로 구축하면서 자연스럽게 거버넌스 정책도 적용하였습니다. S3 버킷을 만들때 KMS 키 없이는 파일 기록이 되지 않게 Bucket Policy를 필수적으로 설정하게 만들어 보안 위협을 미연에 방지하는 식입니다. 이런식으로 CDK로 만들어 지는 모든 리소스에 필요한 보안요소를 고려하고 있습니다.
• #7: 둘째, 기술력 확보 과정을 말씀 드리겠습니다.
• #8: 저희는 모든 데이터를 Athena에 쌓을때 Iceberg 테이블 포맷으로 적재했고 현재 30테라바이트 이상 운영 하고 있습니다. Iceberg를 도입한 목적은 금융권의 다양한 정합성 요구사항을 맞추기 위해 ACID 트랜잭션 사용이 필수적이라고 판단했습니다. 즉 update/upsert/delete 쿼리가 바로 athena에서 실행 가능하다는 점입니다. 예를 들어 개인정보를 지워야 하는 분리/파기 요건이 발생하면 어떻게 처리해야 할까요? Iceberg가 없다면 delete 쿼리가 직접 실행 가능하지 않기 때문에 임시 테이블을 만들어 select insert 형식으로 우회해서 지워야 하는데 이는 성능 측면에서도 구현 측면에서도 효율적이지 않습니다. 반면 iceberg를 쓰면 delete 쿼리를 직접 호출하여 athena에서 쉽고 정확하게 지울 수 있습니다. 또한 부가적으로 데이터 파티셔닝을 자동화 할 수 있기 때문에 빅데이터 테이블 관리요소가 하나 줄어듭니다. 금융권이 그 어떤 다른 업권보다도 개인정보 보호를 중요하게 다룬다고 생각합니다. 따라서 Athena를 쓰시는 분들이 있다면 Iceberg 도입은 적극 추천 드립니다.
• #9: 저희는 S3나 Athena에 있는 데이터를 다룰때 Pandas를 주력으로 활용합니다. 시중에 S3나 Athena의 데이터를 접근 할 수 있는 오픈소스는 많이 있습니다. 그러나 실 사용에서는 CSV와 같은 형식이 있는 데이터를 불러오는데 그치지 않고 이후 EDA 등으로 데이터를 조작할 일이 많다는 점입니다. 저희의 경우 AWS SDK for pandas 패키지를 활용하여 데이터 사이언티스트는 Sagemaker에서 Pandas Dataframe으로 불러와 EDA를 합니다. 데이터 엔지니어는 내부 테스트 결과 10GB 미만의 데이터 ETL은 Spark 보다 빠르고 비용효율적이라 이 방식으로 Glue ETL을 개발하고 있습니다. 이는 스파크같은 부팅 시간이 없고, Glue 파이썬 쉘 모드에서 최소 DPU를 1/16~1로 튜닝할수 있기 때문에 유용합니다. 이를 통해 데이터 사이언티스트/엔지니어 모두 만족하며 작업을 하고 있습니다.
• #10: 저희는 ETL 엔진을 자체 개발하여 표준 데이터파이프라인을 확보하고 있습니다. 여기서 엔진은 Airflow, Glue, Validation 엔진으로 구성되어 있습니다. ETL 엔진은 MWAA와 Glue ETL 실행시에 파이썬 패키지 형태로 추가 되어있습니다. ETL을 개발하시는 분들은 AirFlow나 Glue Job 개발시에 Engine API를 조합하여 사용합니다. 이렇게 엔진을 개발하게된 목적이자 장점 2가지를 말씀 드리겠습니다. 첫째, 기술 난이도 감소입니다. 이 방식은 팀에 주니어가 많거나 수행사와 일을 하게 되면 장점을 가집니다. Airflow에서 Dag실행을 통해 번거로운 Glue Job을 자동으로 생성해주거나 Glue ETL 개발 시 테이블 명세를 자동으로 읽어 평균 3줄 정도의 코딩으로 아테나 적재를 수행합니다. 또한 Iceberg 방식의 적재, 성능이 필요한 Spark 병렬 처리 등과 같은 기술을 엔진에서 지원해 주어 API 사용자는 쉽게 ETL 개발을 할 수 있습니다. 둘째, ETL 프로세스 표준화 입니다. 분리/파기 비지니스 로직도 엔진 내에 담아두어 정합성을 보장합니다. 예를 들어 Glue Job마다 분리/파기 로직이 흩어져 있으면 관리가 힘들뿐더러 이건 잠재적인 Risk가 될 수 있습니다. 또한 엔진을 통해 파이프라인을 구성하기 때문에 데이터 검증 의무적용과 같은 프로세스도 쉽게 적용 할 수 있습니다.
• #12: 저희는 자체 개발한 파이썬 패키지인 바람을 활용하여 내부 사용자의 Glue나 Sagemaker 작업을 도와주고 있습니다. 시중에 boto3라는 훌륭한 파이썬 패키지가 있지만 엔터프라이즈 환경에서 활용하기에 기능이 조금 더 필요했습니다. 예를 들면 여러 개의 파일이 들어있는 S3 디렉토리를 boto3로 지우려면 어떻게 해야 할까요? Boto3에서 메서드 하나로 지우면 좋겠지만 실제로는 재귀함수 형식으로 코드를 여러줄 짜야지 동작합니다. 이처럼 다양한 내부에서 필요했던 요구사항에 맞춰 코드 스니펫들을 모아서 제공하다 보니 자연스럽게 바람이 만들어지게 되었습니다. 클라우드라는 구름을 보다 편리하게 움직이게 도와주는 바람이 되고자 하는 작명입니다.
• #13: 셋째, 거버넌스 확보 과정입니다.
• #14: 저희는 자체 인력만으로 금융감독원 중요시스템을 통과했고 이 과정에서 Security Hub의 많은 도움을 받을 수 있었습니다. Security Hub에 대해 간략히 설명 드리자면 이미 존재하는 아마존의 다양한 보안 서비스들, 예를 들어, Guard Duty, Cloud Trail, VPC 등의 보안 로그 리포트를 포탈 형태로 통합하여 볼 수 있는 서비스 입니다. 이를 통해 중요시스템 통과 시 안전성 확보 조치내역 대부분을 체크 할 수 있었으며 오픈 이후에도 24시간 365일 모니터링 하는 용도로 요긴하게 쓰고 있습니다. 현재 저희는 보안항목 84% 준수를 하고 있는데 이는 회사마다 설정하는 정책 범위 등에 따라 달라질 수 있는 부분이기 때문에 절대적인 수치가 아니라는 점 참고 부탁 드립니다.
• #15: 저희는 레이크 포메이션 기반으로 전체 데이터의 권한을 관리하고 있습니다. 이 방식은 나름 삼성 보안조직에서도 만족하는 구성인데요. 저희는 개인정보 민감도에 따른 데이터 등급제를 시행하고 있습니다. 개인정보가 민감할수록 1등급에 가깝고 덜 민감할수록 3등급에 가까운 식입니다. 이렇게 만들어진 등급을 사용자들은 퍼미션 셋 그룹 단위로, 데이터는 테이블이나 컬럼에 등급 태그를 부여하여 접근을 관리합니다. 왼쪽의 그림으로 예를 들자면 2등급을 가진 사용자 그룹은 2~3등급의 데이터는 접근할 수 있는 반면 1등급 데이터는 불가능해집니다. 이렇게 등급 태그를 통해 관리하면 일일이 사용자 한명 한명 데이터 하나 하나에 직접적인 권한을 부여하는것 보다 경우의 수를 대폭 줄일수 있기 때문에 관리가 단순하고 직관적이게 됩니다.
• #16: 저희는 전체 ETL 파이프라인에 품질 검증 자동화를 적용하였습니다. 저희는 S3에 있는 CSV를 Athena로 적재하는 파이프라인이 대부분입니다. 따라서 이 파이프라인을 한데 묶어 S3에서 먼저 CSV 품질을 체크하고 통과하면 Athena 적재, 통과하면 Athena로 다시 품질검증을 하게끔 벨리데이션 엔진으로 파이프라인을 표준화 하였습니다. 품질 체크는 예를 들자면 컬럼 순서나 컬럼 갯수, 널 체크 등의 다양한 품질 정합성 요소를 검증합니다. 또한 품질 수행 결과는 자동으로 기록되며 실패시 알람을 보내고 이티엘이 중지되는 다소 엄격한 방식으로 운영되고 있습니다.
• #17: 비용 최적화는 1회성으로 끝나는 행위가 아닌 지속적으로 모니터링 하고 필요한 부분을 개선해 나가야 하기 때문에 거버넌스 요소라고 생각합니다. 저희 회사 뿐만 아니라 타사에도 도움이 되지 않을까 해서 소개 드립니다. 혹시 파레토 법칙을 아십니까? 짧게만 설명 드리면 소위 80대 20 법칙이라고도 불리는데 클라우드에서 발생하는 전체 작업의 20%의 영역에서 전체 비용의 80%가 발생할 가능성을 말합니다. 제 과거 경험상 백엔드 서버, 데이터레이크가 등이 모두 여기에 해당했습니다. 이런 케이스에서는 20% 영역을 개선하는 것으로 전체 비용이 좌우됩니다. 저희의 경우 이 방식으로 Sagemaker를 쓰고 나서 노트북을 종료하지 않는다던가, 전체 Glue Job을 summary하여 병목을 찾기도 했고, 에어플로우의 스케줄러가 hang이 걸리는 현상들을 발견하여 튜닝하였습니다. 그결과 월간 비용의 약 20%를 절감할수 있었습니다.
• #18: 결론을 말씀 드리겠습니다.
• #19: 앞서 소개드린 핵심 목표를 기준으로 회고를 해보겠습니다. 첫째, 속도 측면에서는 3개월에 걸쳐 인프라를 구축하고 나머지 3개월로 엔진을 개발하고 데이터를 채워넣어 6개월 만에 레이크하우스를 구축하였습니다. 신기술이 쏟아지는 지금 시대에는 데이터 레이크 구축이 한번으로 끝나지 않을수 있습니다. 저희는 앞으로도 신규과제에 필요한 신기술을 적급 도입할수 있는 속도를 확보했다고 생각합니다. 둘째, 핵심 기술을 확보하기 위해 Iceberg, Engine, Baram을 개발하였고 이를 통해 내부 사용자들이 빅데이터를 보다 쉽게 다루고 최신 AWS 도구를 쉽게 활용할 수 있게 만들었습니다. 결국 내부 인력들의 역량을 향상하여 전문가로 기르고 좋은 도구를 제공해줘야 좋은 성과로 이어질꺼라 생각합니다. 셋째, 자체 인력으로 거버넌스 체계를 수립하여 금융감독원 중요시스템을 통과 하는 등 직접적인 노력을 했습니다. 클라우드 데이터레이크는 다양한 Risk가 잠재되어 있다고 생각합니다. 정보보안, 비용, 데이터 품질 등 요소 하나하나가 중요한데 저희는 능동적으로 Risk에 대응하여 이 위협을 최소화 하고자 합니다.
• #20: 끝으로 저희가 데이터 레이크 구축을 진행하며 얻은 일부를 공유 드리고자 합니다. ETL/EDA용 파이썬 패키지인 바람 입니다. 공식 PyPi 레파지토리에 등록되어있고 Glue ETL이나 Sagemaker 등에서 바로 사용하실 수 있으니 관심있는 분들은 써보시면 좋을 것 같습니다. 저희가 대단한것을 만들어서 공유드린다 라는 개념 보다 오픈소스로 공론화 하여 보다 많은 사람 들이 같은 고민과 해결책을 공유할 수 있었으면 하는 바람입니다.
• #21: 발표를 준비하며 문득 규칙을 따르되 과감하라 라는 나이키 공동 창업자의 말이 떠올랐습니다. 이 말이 어쩌면 금융권 내에서 기술과 비지니스를 다루는 데 있어 당연하지만 타협하지 말아야 하는 요소가 아닌가 생각합니다. 규칙을 안 따르고 과감하긴 쉽고, 규칙을 따르다 보면 과감함은 잃어버리기 쉽기 때문입니다. 저를 비롯한 금융업권 모두가 쉽지 않겠지만 규칙은 지키면서 더욱 과감하게 시도하다 보면 반드시 더 나은 금융 서비스와 기술을 만들어내지 않을까 기대하며 이상 발표 마치겠습니다.
• #22: 발표 경청해주셔서 감사합니다.