AI시대, 데이터 레이크의 진화 (강준범 과장/효성인포메이션시스템)

Deep Learning IO의 특성은 매우 빈번한 Small IO에 대한 요청에 있습니다. 하나의 큰 파일을 분석하는 게 아니라 데이터셋을 잘게 쪼개서 딥러닝 IO를 일으키는 구조로 되어있습니다. 그러다 보니 Small IO에 대한  IOPS가 딥러닝에서는 가장 중요하다고 말씀드릴 수가 있습니다.
데이터레이크 입장에서 보면, 파일이 어떤 데이터 노드에 저장이 되어 있는지를 찾기 위한 메타 데이터의 오버헤드를 가장 그 최소화할 수 있는 구조를 가지고 있어야 합니다.”
진행자 : 고우성 PD/토크아이티 (wsko@talkit.tv, https://talkit.tv/)
게스트 : 강준범 과장/효성인포메이션시스템 (his-skchoi@hyosung.com)
기업의 데이터를 한 곳에 저장해 놓는 ‘데이터 레이크’라는 개념이 2011년도에 나온 이래로 많은 기업이 하둡 기반의 데이터 레이크를 현재도 사용하고 있습니다.
데이터 레이크 초창기인 10년 전과 비교해 볼 때 가장 큰 워크로드의 변화는 AI를 활용하기 위한 데이터 저장과 분석, 이 수요가 굉장히 급속하게 증가한 것입니다.
이번 잇터뷰에서는 AI 활용을 위해서 기존과 다른 어떤 속성이 데이터 레이크에서 중요해지고 있으며 이에 따라 데이터 레이크는 어떻게 진화해나가고 있는지를 효성인포메이션시스템 강준범 과장을 모시고 알아보겠습니다. 먼저 기존의 하둡 기반 데이터 레이크에 어떤 이슈가 있는지를 알아보겠습니다.

 

1. 하둡 기반 데이터 레이크가 만든 데이터 분석 사일로

강준범 : 처음에는 기업에서는 정형데이터 기반의 분석 인사이트를 얻기 위해서 좌측에 보시는 것처럼 정형데이터 기반의 정보계 시스템, 데이터 웨어하우스 환경을 구축했습니다.

 

데이터 레이크의 진화_효성 1
Hadoop 기반 초창기 데이터 레이크 아키텍처

 

더 나아가서 비정형·반정형 데이터를 분석하기 위해서 우측과 같이 NoSOL DB와 Hadoop Cluster를 도입하게 되었습니다. 그리고 일반 파일을 저장하기 위해서 NAS와 SAN 스토리지를 도입하게 되었는데요. 이렇게 Hadoop 기반의 초창기 데이터 아키텍처를 수립하다 보니 결과적으로 데이터를 모으기 위해서는 너무나 다양한 저장소가 발생하게 되었습니다.
고우성 : 저장소가 하나가 있는 게 아니라 여러 가지입니까?
강준범 : 네 맞습니다. 정형데이터를 수집하기 위한 DW라고 말씀드리는 데이터 웨어하우스 저장소가 있고요. 비정형 데이터와 반정형을 저장하기 위해서 NoSOL DB, Hadoop 환경이 따로 있습니다. 그리고 일반 파일을 저장하는 NAS와 SAN이 있습니다. 결과적으로 이렇게 다양한 저장소가 발생하게 됨으로 인해서 데이터 중복, 데이터 사일로가 발생을 하게 되고 각각의 데이터 간의 연관관계에 도출하는 데 굉장히 어려움이 발생하게 되었습니다.
고우성 : 그럼 분석할 때 상관관계 분석이 힘들었다는 것 아닙니까?
강준범 : 거의 힘들었다고 말씀드릴 수가 있습니다. 그리고 인프라 담당자 측면에서 보면 추가로 기하급수적으로 증가하는 비정형·반정형 데이터를 저장하기 위해서 데이터 레이크, Hadoop을 구축했는데 Hadoop 데이터 노드의 증설에 대한 이슈가 점점 나오기 시작합니다. 그 비용에 대한 문제가 될 수도 있고 유지 보수나 체계에 대한 문제가 여기에 해당합니다.

 

AI 데이터 분석을 위해서는 대량의 데이터를 사일로 없이 가성비 좋게 저장하되 빠르게 병렬로 분석을 할 수 있는 인프라가 필요할 것입니다.

 

2. 고성능 병렬파일 시스템 & 오브젝트 스토리지

강준범 : 데이터 사일로를 방지하기 위해서 오브젝트 스토리지 기반의 단일저장소 기반으로 되어진 차세대 데이터 레이크 아키텍처에 대해서 말씀을 드리겠습니다.
과거에는 오브젝트 스토리지를 약간의 백업 용도 아카이빙 용도로 많이 사용하셨다면, 요즘에는 오브젝트 스토리지를 데이터 레이크 1차 저장소로 많이 사용하고 계시는데요. 그 이유 중 하나로 AWS의 역할이 가장 컸다고 말씀드릴 수 있습니다.
고우성 : Amazon S3 말씀이십니까?
강준범 : 네, 맞습니다. 아마존에서 S3를 출시하면서 다양한 퍼블릭 환경에 분석 도구들을 출시했는데요. 출시된 분석 도구들이 S3 API를 통해서 오브젝트 스토리지와 연동이 되어 이제 차세대 데이터 레이크 아키텍처를 수립하게 되었습니다.
그로 인해 다양한 온프레미스(On-premise) 환경의 분석 도구 벤더들이 S3 API를 지원하게 되고 스토리지 벤더들은 동일한 형태의 오브젝트 스토리지에 S3 API를 지원하는 형식으로 새로운 제품을 출시하게 되었습니다. 차세대 데이터 레이크의 1차 저장소로 오브젝트 스토리지, 즉 S3 컴펙터블 오브젝트 스토리지가 자리 잡게 된 상황입니다.

 

데이터 레이크의 진화_효성 2
차세대 고성능 데이터 레이크 아키텍처

 

고우성 : 통합되는 건 좋은데 빠른 분석이 필요할 때가 있지 않습니까? 그런데 오브젝트 스토리지는 느리지 않습니까?
강준범 : 굉장히 좋은 부분을 말씀을 해주셨습니다. 점차 고성능의 분석 환경이 도입되면서 많은 고객사에서 기존 1차 저장소라고 말씀드렸던 오브젝트 스토리지와 연동을 시켰습니다. 그런데 이렇게 해보니 스토리지 단에서 병목 현상이 발생하게 된 겁니다.
스토리지가 성능을 받쳐주지 못해서 고성능 분석 환경의 리소스가 펑펑 놀게 되는 현상이 발생하게 되었는데요. 이런 문제점을 해결하기 위해서 차세대 고성능 데이터 레이크 아키텍처에는 병렬 분산파일 시스템을 추가로 포지셔닝하게 되었습니다.
고우성 : 고성능 병렬파일 시스템요?
강준범 : 네, 맞습니다. 그래서 이런 고성능 병렬파일 시스템이 분석 환경과 더 나아가서는 다수 분석가의 데이터를 서브해줄 수 있는 컨테이너 환경까지, 유기적으로 지원하게 됨으로써 결과적으로 차세대 고성능 데이터 레이크 아키텍처가 완성되었다고 말씀드릴 수 있습니다.

 

기업의 일반 워크로드와 달리 AI 워크로드와 프로세스만의 속성들은 어떤 것이 있으며 이것들은 어떤 문제를 발생시키고 있을까요?

 

3. AI 데이터 분석 이슈 : 데이터 복제, Small IO

강준범 : AI Data Pipelines라고 하면 아래의 장표에서 보시는 것처럼 어떤 데이터를 가지고 와서 그 데이터를 클렌징 작업과 전처리 과정을 거친 뒤, 그 데이터셋을 기반으로 모델이 학습하고, 학습된 모델을 기반으로 이제 검증하게 됩니다.
검증이 완료된 모델로 이제 미래를 예측하거나 고객의 인사이트를 도출하기 위한 추론작업을 거치게 되는데요. 이런 추론작업이 끝나게 되면 활용되었던 모델과 모델학습에 사용됐던 데이터들은 비교적 비용 효율적인 스토리지로 아카이빙되어서 백업됩니다.
이런 일련의 과정들이 현재 구축이 되어 있는 ‘AI DAta Pipelines의 데이터 저장소 구조다’라고 말씀드릴 수 있습니다.

 

데이터 레이크의 진화_효성 3
AI DAta Pipelines의 저장소

 

고우성 : 이 장표를 보니까 구간마다 Data Copy가 발생하는데, 이렇게 다 데이터를 복제해야만 되는 겁니까?
강준범 : 네, 맞습니다. 왜냐하면 현재 구축된 이런 일련의 과정들을 수행하기 위해서는 다양한 도구들이 필요하게 되는데요. 각각의 도구들은 자신의 업무 프로세스를 수행하기 위해서 자기의 상태에 최적화되어 있는 스토리지를 선택해서 도입하고 있습니다.
어떤 경우에는 공유가 필요한 NAS 스토리지가 필요할 거고요. 모델을 돌릴 때는 IOPS에 특화된 스토리지가 필요할 것입니다. 또 비용 효율적으로 백업을 위해서는 오브젝트 스토리지가 필요할 것입니다.
이런 일련의 과정을 거치면서 스토리지마다 지속해서 Data Copy가 일어날 수밖에 없는 구조입니다. 결과적으로 Data Copy가 일어남에 따라 스토리지의 자원 낭비와 데이터 분석이라는 목적을 이루기까지 즉, 데이터 분석가가 데이터가 복제될 때까지 기다리는 시간적인 리소스 낭비가 발생할 수밖에 없는 것이 현재 데이터 파이프라인의 문제라고 말씀드릴 수가 있습니다.
고우성 : 그게 엄청난 오버헤드를 주는 거네요.
강준범 : 맞습니다. Deep Learning IO의 특성은 매우 빈번한 Small IO에 대한 요청에 있습니다. 하나의 큰 파일을 분석하는 게 아니라 데이터셋을 잘게 쪼개서 딥러닝 IO를 일으키는 구조로 되어있습니다. 그러다 보니 Small Files IO, 결과적으로 IOPS가 딥러닝에서는 가장 중요하다고 말씀드릴 수가 있습니다. 저장소 입장에서 보면, 파일이 어떤 데이터 노드에 저장이 되어 있는지를 찾기 위한 메타 데이터의 오버헤드를 가장 그 최소화할 수 있는 구조를 가지고 있어야 합니다. 그래야 딥러닝 IO 프로세스에 적합한 저장소’라고 말씀드릴 수 있습니다.

 

데이터 레이크의 진화_효성 4
Deep Learning IO

 

 

AI 데이터 파이프라인 구간별로 발생하는 데이터에 대한 물리적 복제로 인한 오버헤드는 메타데이터를 활용해서 줄일 수 있다고 하였습니다. 그런데 AI 워크로드는 Small IO가 빈번히 발생하는 특성이 있는데 이에 따라 메타 데이터에 대한 병목이 발생할 수 있지 않을까요?

 

4. 메타 데이터 병목 해결하는 HCSF 고성능 병렬파일 시스템

강준범 : 일반적인 병렬파일 시스템의 경우, 메타데이터 노드와 데이터가 저장되는 스토리지 노드가 분리되어 있는 구조로 이루어져 있습니다. 처음 도입할 당시에는 성능 이슈나 별다른 문제점을 발견하실 수가 없으실 겁니다. 왜냐면 최적화된 상태로 그 도입을 했기 때문입니다.
하지만 방대하게 증가하는 데이터를 저장하면서 고객사에서 가용 저장 공간을 증가시키기 위해 스토리지 노드를 점차 증가하게 될 것입니다.
스토리지 저장소는 늘어났지만 데이터가 어떤 노드에 저장되어 있는지 찾기 위해 필요한 메타데이터 노드는 증설이 안 됐기 때문에, 결과적으로 파일을 찾기 위해 필요한 메타데이터 노드에서 병목 현상이 발생할 수밖에 없는 구조입니다.
이런 구조 때문에 일반적인 병렬파일 시스템에서는 노드가 늘어나면 늘어날수록 메타 데이터를 찾는 데 있어 성능 저하가 일어나고, 이런 성능저하는 스토리지의 성능 저하로 이루어지게 됩니다.

 

데이터 레이크의 진화_효성 5
AI/HPC 환경을 위한 고성능 데이터 레이크 저장소 – MetaData 관리

 

고우성 : 기존 타사의 병렬파일 시스템들이 방금 말씀하신 메타데이터 이슈를 생각하지 못한 채 시작한 이유가 무엇이라고 생각하세요?
강준범 : 일단 타사의 병렬파일 시스템 같은 경우에는 그 시작 자체가 일반적인 NAS 스토리지를 베이스로 변형하여 확장된 개념이라고 말씀드릴 수가 있습니다.
하지만 저희 효성의 HCSF 제품의 경우에는 애초에 AI 분석을 위한 목적으로만 설계가 되어 만들어진 제품이다 보니 이런 문제점을 다 해결한 제품이라고 말씀드릴 수가 있는 것입니다.
우측 화면에 보시는 바와 같이 노드가 증설됨에 따라 메타데이터 역할을 해주는 메타데이터 서버 역할을 해주는 노드도 함께 증설될 수 있는 것입니다. 결과적으로 MSA(Micro Service Architecture)를 내부적으로 채택하고 있어 좀 더 손쉽게 확장이 가능하고 성능 저하가 없는 노드 증설에 따라서 선형적으로 성능 향상이 이루어질 수 있는 제품이라고 말씀드릴 수 있습니다.
고우성 : PoC를 했을 때 고객들의 반응은 어떤가요?
강준범 : 일단 첫 번째로 가장 놀라시는 부분은 IOPS입니다. 고객사에서 고성능 분석을 위해서 저희 제품으로 간단하게 PoC 진행했는데 타사 대비 IOPS가 정말 눈에 띌 정도로 차이가 있었습니다.
고우성 : 오, 얼마인데요? 몇 배인가요?
강준범 : 네, 몇 배 이상입니다. 고객분께서 체감하시면서 ‘정말 깜짝 놀랄 정도의 IOPS의 성능 추이를 보였다’고 피드백을 주실 정도였습니다. IOPS에 특화된 그리고 Throughput도 굉장히 높은 제품이라고 말씀드릴 수 있습니다.

 

궁금한 점이 있는 분들은 효성인포메이션시스템 강준범 과장에게 메일로 상담 문의를 하실 수 있습니다.
※상담 메일 : his-skchoi@hyosung.com

 


 

이후 내용은 아래▼ 영상을 통해 확인하실 수 있습니다.

 

 


 

◼ 콘텐츠 & 웨비나 문의 : marketing@talkit.tv, 02-565-0012
Copyright ⓒ 토크아이티 All rights reserved. 무단 전재 및 재배포 금지.