✅ 제목: Iceberg 기반 데이터 레이크하우스 아키텍처 도입기 1 - Apache Iceberg를 선택한 이유

1. 서론

사이버 보안분야의 문제 해결을 위해선 다양한 형태의 데이터가 필요합니다. 에스투더블유 (S2W)는 오랜 기간 동안 다크웹, SNS 등 수많은 소스로 부터 다양한 형태의 데이터를 수집 및 분석하고 있습니다. 수집되는 데이터는 대부분 비정형 데이터 형태로 수집이 되기 때문에, 분석가가 제대로 활용할 수 있게 모든 데이터를 가공하여 정형화 하는 과정을 거칩니다.

본 글에서는 다양하게 수집되는 데이터 중 대용량 압축 파일 내 전체 데이터를 실시간 & 병렬로 분석할 수 있는 시스템 설계과정과 결과에 대해 다룹니다.

2. 초기 구조는 어떤 방식이었고, 왜 변화가 필요했나?

2-1. 수십 기가 단위의 압축 파일의 실체

다크웹 & 딥웹 등을 통해 유독 대용량 압축파일로 공유되는 데이터들이 있습니다. 이러한 데이터는 특정 시스템에 대한 해킹자료, 각종 로그 정보, 혹은 이미 유출된 정보에 대한 재 패키징 등 다양한 목적으로 배포됩니다. 해당 유형의 데이터는 아래와 같은 특징을 가집니다.

• 압축 파일 내 복잡한 트리구조를 가진 폴더로 구성됨
• 파일 내부 다양한 형태의 확장자 (jpg, txt, docx, etc)를 가진 파일이 복합적으로 포함되어 있음
• 폴더의 구조와 파일이 특정 패턴을 가지는 경우가 있음
• 압축 파일 및 파일 내부에 “DRM / 암호화” 등 수집 컨택스트를 함께 저장해야 접근 가능한 데이터가 포함되어 있음

2-2. 원본을 보존하기 위한 초기 데이터레이크 설계

출처: ETL vs ELT (https://aws.amazon.com/ko/compare/the-difference-between-etl-and-elt/)

유포되는 데이터에는 수많은 사이버 보안에 위협이 되는 정보를 포함하고 있기때문에, 데이터의 원본을 저장하는 것은 중요한 일입니다. 다만, 압축 파일의 데이터 특성으로 인해 수집단계에서 실시간으로 정형화를 하여 데이터를 선별하여 저장하는 것은 미처 정형화하지 못한 데이터의 로스로 이어질 수 있다고 판단하였습니다. 이를 방지하기 위해 저희는 ETL이 아닌 ELT 방식으로 “최대한 원본을 보전하는 방향”으로 시스템을 설계하였습니다.

2-3. 데이터 정형화 프로세스

(대용량 압축파일에 대한 데이터 정형화 프로세스)

대용량 압축 파일 내 기존 분석시스템을 통해 정형화된 데이터는 상기 절차를 통해 인덱스엔진에 저장됩니다:

1. 원시데이터 수집: 압축 형태의 데이터를 그대로 저장하고, 수집 시점의 부가 메타데이터 정보 (e.g., 압축파일의 유형, 비밀번호, 수집 위치 등)도 함께 저장합니다.

2. 데이터 분석: 각 수집된 압축 파일에 대해 분석에 필요한 일부 정보를 특정 파일에서 추출하여 정형화 합니다.

3. 데이터 조회: 애플리케이션 및 분석가가 정형화된 데이터에 접근 가능하도록 인덱스를 구성하여 제공합니다.

즉, 사전에 정의된 분석 (데이터 정형화) 모듈을 통해 수집 직후 필요한 데이터를 미리 뽑아 저장하는 구조로 초기 파이프라인을 설계하였습니다.

2-4. 새로운 요구사항

분석에 필요한 파일만 효율적으로 추출하여 저장하는 방식은 속도, 공간 측면에서 매우 효율적이었습니다. 인덱싱에 필요한 값비싼 스토리지를 많이 사용하지 않고, 분석에 의미있는 데이터를 빠르게 제공하였습니다.

사내 서비스가 고도화 됨에 따라 데이터 파이프라인에서 충족해야 할 새로운 요구사항이 생겼습니다.

분석 시스템 고도화 대응: 분석 시스템이 고도화되는 속도를 따라가지 못했습니다. 분석 모듈은 다양한 이유로 고도화가 됩니다. 기존에 보지못했던 패턴이 새롭게 발견 된 경우, 분석 모듈의 성능 향상으로 데이터의 추출 능력이 올라 간 경우, 신규 파싱 로직이 반영된 경우 등 다양한 이유로 분석 모듈이 고도화 됩니다. 분석 모듈이 고도화 되면 기존에 정형화를 했던 데이터는 폐기하고, 신규 모듈로 기존 데이터를 분석해야합니다. 현 구조에서는 매번 압축 해제가 필요해 분석 속도가 저하되며 상당한 IO 오버헤드가 발생하는 문제가 생겼습니다.

개별 파일에 대한 접근성: 정형화된 형태의 데이터는 원시데이터에 비해 많은 정보가 유실됩니다. 정형화된 데이터는 핵심 정보만 포함하므로, 실제 분석 시 원시데이터에 대한 접근이 중요합니다. 초기 시스템에선 이러한 데이터를 확보하기 위해선 대용량 압축파일을 다시 해제하여 전달해야하므로, 데이터 접근성이 상당히 떨어졌습니다.

2-5. Small file problem

사내 요구와 분석 성능 개선을 위해 개별 파일 단위로 조회, 검색, 다운로드를 지원할 필요가 있었고 이를 해결하기 위해 압축 파일을 해제해 모든 개별 파일을 저장하는 방식을 고려했습니다.

이 방식의 장점은 다음과 같습니다:

1. 개별 파일에 대한 접근성 향상: 필요한 파일만 빠르게 조회 가능 (예: PDF 파일만 선택 처리)

2. 분석 파이프라인 단순화: 압축 해제는 제외하고 파일을 파싱하는 코드만 작성하면 됨

하지만, 현재 구조를 유지하면서 단순하게 압축 해제 후 저장을 하기엔 기술적으로 풀어야 할 문제가 발생했습니다. 가장 큰 문제는 빅데이터 시스템에서 주로 발생하는 Small file problem (출처)입니다. Small file problem은 하둡, S3 기반 Object 스토리지, ext4 파일시스템 등 다양한 저장소에서 일반적으로 발생하는 문제입니다.

분산 객체 저장소를 예시로 해당 문제가 왜 발생하는지 설명드리겠습니다.

MinIO는 Erasure Coding을 기반으로 데이터를 여러 블록(data shard)과 복원용 블록(parity shard)으로 분산 저장합니다. 이때 각 블록은 자신이 어떤 객체에 속하는지 식별할 수 있도록 별도의 메타데이터를 포함해야 하며, 이로 인해 파일 수가 많아질수록 메타데이터 블록 또한 기하급수적으로 증가하게 됩니다.

예를 들어 EC(4,2) 구성의 경우, 하나의 객체를 4개의 데이터 샤드와 2개의 패리티 샤드로 쪼개어 총 6개의 파일 단위로 저장합니다. 이때 각 샤드는 자신이 속한 객체를 식별할 수 있도록 별도의 메타데이터를 보유하게 되며, 이 메타데이터는 파일 시스템 상에서 inode 혹은 별도의 구조로 저장됩니다. 작은 파일이 많아질 경우, 메타데이터(특히 inode)의 수가 기하급수적으로 증가하면서 파일 시스템의 inode 자원 고갈, 디스크 IOPS 병목, 메타데이터 캐시 사용량 증가 등 여러 문제가 발생합니다. 예를 들어 1KB짜리 파일을 10만 개 저장한다고 가정하면, 실제 데이터는 100MB 수준이지만, EC(4,2) 구성에서는 6개의 샤드가 생기므로 메타데이터는 약 153.6MB에 달하게 됩니다. 이처럼 오히려 데이터보다 메타데이터가 더 큰 상황이 벌어지며, 이는 작은 파일이 많을수록 더 심각해집니다.

즉, 현 데이터 저장/분석 구조를 유지하며 단순히 압축을 풀어서 저장하는 방식은 확장성이 있는 방향이 아니라고 판단했습니다.

3. 다양한 대안 중, 왜 Iceberg가 최적의 선택이었나?

새로운 아키텍처는 실시간 분석이 필요한 사이버 보안 데이터를 다루기 위해선 단순 저장이 아닌 분산성과 쿼리 가능성, 유연한 인덱싱 구조를 가져가야합니다. 새로운 아키텍쳐 구성을 위해 먼저 필수 요구사항과, 개편을 통해 추가로 달성해야 할 목표를 설정했습니다.

📌 신규 아키텍처 요구사항

위 요구사항을 충족시키는 기술스택에 대해 검토한 결과는 아래와 같습니다.

📌 기술 스택 비교

다양한 기술스택을 검토하였고 운영 유지보수와 확장성 그리고 기능의 다양성을 기준으로 Iceberg를 선택하게 되었습니다. 사내 하둡기반 에코시스템을 보유하고 있어 Hbase도 물망에 올랐습니다. Hbase는 row key에 대한 검색은 상당히 빠르고 row key 설계에 따라 성능 최적화를 할 수 있습니다. 다만, column에 대한 쿼리 시 스캔이 필요하므로 요구사항을 중족하지 못했습니다. 또한 RBAC 적용 및 클러스터 관리에 러닝커브와 관리가 상대적으로 까다로워 최종 드랍되었습니다.

Iceberg도 만능은 아니며 도입 시 여러 문제가 예상되었습니다. 

• 외부 스토리지에 의존적이라 외부 스토리지 유형에 따라 성능 테스트가 필요 함
• Iceberg 설계 (파티션 구조 등)에 따라 성능이 달라질 수 있다는 점
• 단일 파일접근에 있어 불필요한 IO 발생이 있을 수 있다는 점 (Parquet 파일 조회 등)
• Iceberg 운영을 위해 별도 데이터베이스를 운영해야하는 점
• 데몬 형식이 아니라 별도 관리 애플리케이션을 제작하여 사용해야하는 점
• 인덱스 엔진의 부재로 인해 부분 스캔 기반 검색을 해야하는 점 (Parquet 의존적)

Iceberg에 대한 기술 검토 과정에서 여러 제약사항이 존재했습니다. 크게 1) 별도 운영 공수를 감내 2) 실시간 인덱싱 포기 두가지를 포기하고 나머지 요구사항을 충족시키는 것을 목표로 했습니다. 특히 후자에 대해선 애플리케이션/분석가의 요구사항에 따라 “파이프라인을 자유롭게 구성하는 것”으로 풀 수 있다고 판단하였습니다.

저희는 이러한 의사결정을 통해 최적의 솔루션은 Iceberg라는 판단을 하였습니다.

다음 칼럼에서는 <Iceberg 기반 데이터 레이크하우스 아키텍처 도입기 2편>, Iceberg를 실제로 도입하는 과정에서 마주한 이슈들과 그 해결 과정을 심도 있게 다룰 예정입니다.

🧑‍💻 칼럼 작성자: S2W KE팀

👉 AI 기술 문의하기: https://s2w.inc/ko/contact

*S2W의 생성형 AI 플랫폼 SAIP에 대해 더 알고 싶다면, 아래에서 자세한 내용을 확인해 주세요.