2단계: 데이터 저장
스토리지의 기본 구성 요소
스토리지에 대해 기본적으로 알아야 하는 내용에 대해서 간략하게만 적어보겠습니다.
- 하드 디스크
- SSD보다 매우 저렴 ( 약 10배 )
- 대용량 스토리지의 근간으로 활용 중
- 읽기/쓰기 헤드가 디스크의 특정 위치로 움직인 후 적는 방식으로 매우 느림
- 최근 분산하여 읽는 방식으로 문제를 해결하는 중
- SSD
- 하드 디스크보다 비싸지만 그만큼 빠른 전송 속도
- 실제 서비스의 성능에 매우 큰 영향을 줌
- 임의 접근 메모리
- 휘발성으로 장애 시 데이터 손실
- SSD보다 1000배 가량 빠른 속도
- 매우 비싼 특징
- 부족한 CPU 캐시의 용량을 대신해 RAM을 캐시로 활용하는 중
- 네트워킹과 CPU
- 클라우드 객체 스토리지 클러스터에서는 네트워크를 통해 디스크를 분산
- 데이터의 물리적 위치 및 가용률을 분산시킴으로써 성능을 향상시키는 방식이 등장
- 데이터를 분산함으로써 얻는 내구성과 가용성, 스토리지와 소비자의 거리와 비용과의 균형을 유지해야 함
- 직렬화
- 다양한 직렬화 방법이 있으며, 트레이드오프에 집중
- 압축
- 파일의 크기를 줄일수록 검색 및 네트워크 전송에 영향을 미침
- 캐싱
- 속도, 비용, 용량의 상관관계를 잘 따지고 활용하는 기술
- 주로 디스크에서 읽어야하는 정보를 메모리에서 읽기 위해 임시 저장하는 느낌
스토리지 시스템
개인적으로 알아보고자 하는 내용에 대해서 선택적으로 적어보겠습니다.
최종 일관성 vs 강력한 일관성
이전에 몇 번 이야기 된 내용이지만, 분산 환경에서는 일관성을 유지하는게 어려운 일입니다.
여기서 최종적 일관성은 결과적으로는 일관적인 상태가 된다는 의미이며, 이는 곧 접근 시점에 일관성이 깨진 상태일 수 있다는 의미이기도 합니다. 하지만 강력한 일관성은 항상 일관적인 상태를 유지하는 특징을 가지는 성질입니다. 언제 접근하더라도 항상 일관성이 있는 상태이기 때문에 예상하지 못한 문제가 발생하지 않음이 확실한 상태입니다.
이렇게 보면 강력한 일관성이 매우 좋은 것 처럼 보이지만, 문제는 이 과정에서도 트레이드오프가 존재합니다.
분산 환경에서 강력한 일관성이 유지된다는 것은 (리더가 있는 분산 환경의 경우) 팔로워 노드가 리더 노드를 완전히 따라잡았다는 의미라고 볼 수 있습니다. 즉 리더 노드와 팔로워 노드간의 통신이 끝났다는 의미이며, 이 중간 단계에 사용자가 리더 노드의 데이터에 접근하더라도 원하는 정보를 얻지 못한다는 의미 입니다.
하지만 굳이 강력한 일관성이 필요 없다면, 접근 시점에 따라 조회되는 최근 데이터가 다를 수 있지만 최종적 일관성은 충분히 유의미 합니다. 다이나모 DB는 두 방식을 모두 지원하지만 기본값으로는 최종적 일관성을 채택하고 있고, 강력한 일관성을 사용하기 위해서는 2배 가량의 비용이 청구된다고 합니다.
파일 스토리지
파일 스토리지는 일반적으로 우리가 사용하는 파일 시스템입니다.
디렉토리라는 일종의 계층으로 이루어져 있기 때문에 각 계층에 속해있는 파일의 메타데이터가 별도로 저장되어 있으므로, 원하는 파일을 찾기 위해서는 계층을 따라 원하는 파일로 접근하는 메타데이터를 읽어 내려가야 합니다.
일단 저장되면 영구적이라는 특징이 있습니다만, 중간에 장애가 발생했을 때 아직 쓰여지지 않은 데이터는 사라집니다.
이러한 스토리지는 네트워크를 통해 활용하면 NAS의 개념으로 연결되기도 합니다.
블록 스토리지
블록 스토리지는 데이터를 블록 단위로 나누어서 저장하는 방식을 사용하여 저장하는 스토리지 입니다. 블록에 대한 정보를 가지고 있다면, 다른 서버에 블록이 저장되어 있어도 괜찮기 때문에 주로 가상화하여 사용하고 있습니다.
이러한 블록 스토리지의 개념을 사용하여 여러가지 방법론이 등장했습니다.
- RAID
- 여러 디스크를 결합하여 하나의 클러스터 형태로 구축하는 방식
- 내구성을 강화하거나, 성능을 개선 할 때 활용
- SAN
- 네트워크를 통해 가상화된 블록 스토리지 장치를 제공
- 스토리지를 별도로 구축할 수 있기 때문에 여러 서버가 하나의 스토리지에 접근 할 수 있음
- 공간을 효율적으로 활용 할 수 있음
- 확장 할 때 서버와 스토리지를 별도로 확장 할 수 있으므로 원하는 확장에 맞는 개별적인 방식을 사용 가능
- 클라우드 가상화 블록 스토리지
- AWS의 EBS와 같은 스토리지
- 기본적으로 SAN과 유사
- 스냅샷을 관리하거나 여러 리전에 쉽게 이동 및 복사 가능
- 로컬 인스턴스 볼륨
- 클라우드 제공업체에서 호스트 서버와 물리적으로 연결 된 스토리지 볼륨
- 장애 발생시 초기화 될 수 있는 문제가 있지만, 임시 저장소로 활용은 적합하며 저렴함
다음은 블록 스토리지를 사용하기에 적합한 상황입니다.
- 높은 I/O가 필요한 경우
- 높은 처리량과 낮은 지연시간이 필요한 경우
- 가상 머신과 서버 스토리지 용도로 사용 할 때
객체 스토리지
객체 스토리지에서의 객체는 특수한 파일 구조를 나타냅니다. 예를 들면 CSV, JSON, 이미지, 오디오, 비디오 등이 여기에 해당합니다.
최근의 트렌드는 클라우드를 이용한 객체 스토리지의 사용이기 때문에 AWS를 기반으로 알아보면, AWS의 S3가 객체 스토리지로 데이터를 객체 형태로 저장하도록 도와주는 클라우드 서비스입니다.
S3를 사용해보면 알 수 있지만, 디렉토리와 유사하게 /로 구분 된 경로로 데이터를 저장하는 것을 볼 수 있습니다. 하지만 실제 데이터는 계층에 따라 저장되는 것이 아닌 키-값 형태로 저장됩니다. 또한 바이너리 형식으로 단 한번 저장하여 불변적이라는 특징이 있기 때문에 추가 쓰기나 랜덤 쓰기를 지원하지 않습니다.
하지만 여기서 불변성은 다양한 장점을 줍니다. 불변함이 보장되기 때문에 객체 자체를 캐싱하여 효율을 높일 수 있고, 분산 시스템 상에서 복제나 동기화가 필요 할 때도 신뢰성을 높일 수 있습니다.
- 쓰기 확장
- S3 기준으로 AWS의 제한까지 스트림 수를 확장하여 병렬 쓰기를 통해 빠르게 업로드가 가능합니다.
- 읽기 확장
- 병렬 요청 수, 데이터 읽기에 사용되는 가상 머신 수, CPU 코어 수에 따라서 맞춤형으로 확장이 가능합니다.
데이터 엔지니어링 애플리케이션의 객체 저장소
객체 저장소는 일반적으로 대규모 배치 읽기와 배치 쓰기에 뛰어난 성능을 보입니다. 이는 곧 대규모 OLAP에 적합한 성능입니다.
객체 조회
객체를 탐색 할 때 객체 스토리지는 결국 키-값으로 이루어진 스토리지이기 때문에 디렉토리와 유사한 형태지만, 파일 스토리지와 달리 디렉토리로 구분되어있지 않음을 이야기 했습니다.
이것은 곧 S3 기준으로 버킷의 이름은 전세계에서 유일해야하고, 그 안의 파일 명은 버킷 내에서 유일해야 함을 말합니다.
그래서 S3를 사용 할 때는 디렉토리 단위의 작업은 좋은 성능을 얻지 못한다고 합니다.
객체 일관성
여기서 좀 주의깊게 본 점은 강력한 일관성을 얻는 법입니다.
사실 분산 환경에서 복제와 조회 시점의 차이 등으로 인해 강력한 일관성을 얻기 어렵다고 알고 있었는데, 이 부분을 해결하는 방안을 간략하게 적어주었습니다. 이 방법이 무조건적인 정답이라기보다, 하나의 방안으로 적고자 합니다.
- 강력한 일관성을 보장하는 데이터베이스를 구축한다.
- 객체를 쓸 때 해당 데이터베이스에 메타데이터를 저장한다.
- 조회 할 때 해당 메타데이터를 읽어오고, 그 메타 데이터에 일치하는 객체를 가져온다.
- 메타데이터가 일치하지 않으면 최신 버전이 반환 될 때 까지 반복한다.
버전 관리
지금까지는 무조건적인 데이터 적재를 해왔기 때문에 소홀했던 버전관리에 대해서 알 수 있었습니다.
클라우드 서비스의 경우에는 스토리지에 적재 된 데이터 자체에 대한 비용이 청구되기 때문에 불변성이라는 특징을 가진 객체의 특성 상 새롭게 데이터를 적재하면 이번 버전의 객체가 그대로 남아있는 특징이 있습니다. 그렇기 때문에 과거 버전에 대해 데이터를 적절하게 처리 할 필요가 있습니다.
객체 버전 관리를 켜면 버전을 규정하는 메타데이터가 추가됩니다. 기본 키 참조는 새로운 버전으로 포인터가 갱신되지만, 이전의 버전에 대한 포인터도 유지되기 때문에 가비지 컬렉터의 대상이 되지 않기 때문에 계속 남아있습니다.
데이터 엔지니어 입장에서는 스토리지 비용이 가장 큰 포인트입니다. 과거 버전이 그대로 남아서 쌓인다면 스토리지 비용은 나날이 높아 질 것이기 때문에 특정 시간이 흐르거나 일정 이상의 버전이 쌓이면 삭제하는 로직을 추가하거나, 혹은 적재 비용이 싸지만 처리 비용이 비싼 별도의 스토리지로 옮길 수 있습니다.
스토리지 클래스 및 계층
여기서는 버전 관리에서 이야기가 나왔던 스토리지 비용을 관리하기 위한 다양한 스토리지의 클래스가 등장합니다.
S3 기준으로 이야기하면 다음과 같은 클래스가 있습니다.
- S3 Standard
- 자주 액세스하는 데이터를 위해 높은 내구성, 가용성, 성능을 갖춘 객체 스토리지 입니다.
- 스토리지 비용이 높은 편이고 처리 비용은 낮은 편 입니다.
- S3 Intelligent-Tiering
- 처리 정도에 따라 자동으로 변동되어주는 클래스입니다.
- S3 Standard-IA
- Standard에 비해 스토리지 비용이 낮은 편이고 처리 비용은 높은 편 입니다.
- S3 Standard One Zone - IA
- 다른 스토리지는 객체를 기본 3개 이상의 가용영역을 사용하여 저장하지만 이 클래스는 오직 1개의 가용영역에 저장합니다.
- 비용이 약 20% 저렴합니다.
- S3 Glacier 아카이브
- 스토리지 비용이 최소화 됩니다.
- 처리비용이 매우 높기에 분기, 연 단위의 접근이 필요한 경우 유의미합니다.
캐시 및 메모리 기반 스토리지
RAM은 매우 빠르지만 휘발성이라는 특징을 가지고 있습니다. 이러한 특징은 자주 불러오는 데이터를 임시로 저장하여 캐싱에 자주 사용되도록 만들었습니다.
- 멤캐시드
- 데이터베이스의 쿼리 결과, API 호출 응답 등을 캐시하기 위해 설계 된 키-값 쌍의 저장소입니다.
- 단순한 구조만 캐싱 할 수 있습니다.
- 레디스
- 키-값 저장소로 리스트나 셋 등 복잡한 데이터 유형도 지원합니다.
- 스냅숏과 저널링을 통해 어느정도의 데이터 손실을 견딜 수 있습니다.
하둡
별도의 포스트를 남깁니다.
스트리밍 스토리지
정확히 스토리지라고 표현하는게 옳을 지 모르지만 카프카나 아마존의 키네시스 등 다양한 스트리밍 프레임워크는 장기 데이터를 보존 할 수 있습니다.
이렇게 보존 된 데이터는 과거 시점으로 되돌아가는 일종의 리플레이가 가능 한 특징을 가지게 해주었고, 이로인해 특정 시간에 걸쳐 배치 처리나 데이터 재처리를 사용 할 수 있게 되었습니다.
인덱스, 파티셔닝 및 클러스터링
별도의 포스트로 대체합니다.
그리고 조금 더 적어보면, 저자는 컬럼형 데이터베이스의 조인 성능이 발전하여 물론 비정규화의 이점이 존재하지만 필수는 아니라고 합니다.
데이터 엔지니어링 스토리지
- 데이터 웨어하우스
- 표준 OLAP 데이터 아키텍처입니다.
- 강력한 테이블 및 스키마 지원과 갱신 및 삭제 관리 기능을 제공합니다.
- 텍스트 데이터, JSON 등의 문서를 처리 할 수 있습니다만 이미지, 오디오와 같은 데이터는 다룰 수 없습니다.
- 데이터 레이크
- 가공되지 않은 원시 형태의 데이터를 저장 할 수 있습니다.
- 주로 장기보존의 개념으로 HDFS를 대체해나가고 있습니다.
- 데이터 레이크하우스
- 데이터 웨어하우스와 데이터 레이크가 합쳐진 의미로 두 특징을 모두 갖는 방향으로 발전하고 있습니다.
- 객체 스토리지에 데이터를 저장하여 다양한 형태의 데이터를 저장 할 수 있으며, 동시에 OLAP 측면의 조회도 가능합니다.
- Stream-to-Batch
- 스트리밍 데이터를 스트리밍 버퍼로 수집하고 이후에 컬럼형 객체 스토리지로 초기화 하는 등 람다 아키텍처와 유사하지만 동일한 플랫폼에서 사용 할 수 있도록 합니다.
스토리지의 주요 아이디어와 동향
- 데이터 카탈로그
- 조직 전체의 모든 데이터에 대한 중앙 집중식 메타데이터 저장소입니다.
- 운영 및 분석 데이터의 원천에서 작동합니다.
- 데이터 계통과 데이터 관계 표현을 통합하고 사용자가 데이터 설명을 편집 할 수 있도록 합니다.
- 이 과정을 카탈로그 API를 통해 메타데이터 및 갱신을 직접 처리 할 수 있습니다.
- 데이터 레이크, 웨어하우스 및 데이터베이스의 메타데이터를 자공으로 수집하여 관리해야 합니다.
- 사용자에게 데이터셋에 대한 정보를 쉽게 제공하고 위키 역할로 발전 할 수 있습니다.
- 스키마
- 예상되는 데이터 형태, 파일 형식, 정형/반정형/비정형, 데이터 유형, 대규모, 공유키 혹은 다른 데이터와의 연결 등에 따라 고려해야 합니다.
- 쓰기 스키마는 주로 데이터 웨어하우스에서 모든 쓰기에 준수해야하는 스키마입니다.
- 읽기 스키마는 읽는 시점에 스키마를 결정하는 것 입니다.
- 컴퓨팅과 스토리지의 분리
- 스토리지를 가상화하는 EBS와 같은 방법과 같은 방식이 활용 될 수 있습니다.
- 임시 컴퓨팅 리소스를 사용해서 작업을 완료 한 후에 클러스터를 삭제하는 경우도 있습니다.
- 여러 영역의 스토리지를 활용하여 내구성과 가용성을 높일 수 있습니다.
- 무복사 복제(얕은 복사)와 깊은 복사를 지원합니다.
- 데이터 스토리지 수명 주기 및 데이터 보존
- 데이터의 중요도와 접근 빈도에 따라서 스토리지를 설정하는 것이 데이터 스토리지의 수명 주기를 고려하는 것이고, 데이터를 언제까지 보관하는지에 대한 내용을 데이터 보존을 고려하는 것 입니다.
- 핫 스토리지는 접근이 많고, 스토리지 비용이 높지만 검색 비용이 낮습니다.
- 웜 스토리지는 약 월 1회 정도의 빈번하지 않지만 콜드 데이터보다 많이 접근하고, 스토리지 비용과 검색 비용이 중간 정도입니다.
- 콜드 스토리지는 분기, 연 1회 정도로 접근하며 스토리지 비용이 저렴하지만 검색 비용이 높습니다.
스터디를 통해 알게 된 내용
함께 스터디를 진행하면서 얻은 지식을 추가적으로 적어보겠습니다.
1. 어느정도 기간이 된 데이터를 어떻게 다루는지?
이번에 공부 한 내용으로는 오래 된 데이터의 경우에는 어떻게 처리하는지에 대해 스토리지 관점에서 알아보았습니다. 문득 다른 회사에서는 어떻게 처리하는지 궁금하여 질문을 했는데, 중요한 내용들을 알게 되어서 추가로 적고자 합니다.
- 개인정보 보호법이나 통신망 법을 확인해야 한다.
- 법률에 저장하는 데이터에 대해 어느정도 이후에 필수적으로 삭제해야 하는 조항이 있을 수 있다.
- 민감정보의 경우 사용자의 요청에 따라 삭제해야 할 수 있다. ( 무조건적으로 접근이 없지 않을 수 있다. )
- 요약해서 쌓아놓는 방법도 있다.
- 데이터 자체의 용량이 너무 크고, 유의미하지 않다면 현재 리포트 기준으로 필요한 정보만 정리 한 후 별도로 저장하고 삭제하는 방법도 있다.
- 스토리지를 쓴다면 AWS가 스토리지가 좀 저렴한 편
- cloudflare라는 회사는 스토리지가 공짜?!
2. 데이터 레이크라는 타입?
- 파케이의 진화버전인데 압축률이 좋고 전반적인 성능이 높은 것으로 추정 중
3. 클라우드 서비스를 선택 할 때는 여러 방면을 확인해야 한다.
스터디원 중 한 분이 “최근 회사에서 처리 플랫폼을 AWS에서 Snowflake로 바꾸었다”라는 말씀을 하셨습니다. 그리고 이 주제에 대해서 이야기를 나누었는데, AWS의 EMR을 사용 할 때 비용에 비해 관리나 성능이 아쉬운 부분이 있었다는 경험도 들을 수 있었습니다.
AWS의 경우에는 각 기능들이 각각의 플랫폼으로 구분되어 있기 때문에 필요한 것만 사용 할 수 있다는 장점이 있지만, 여러 서비스를 한번에 사용 할 때 비용이 증폭된다는 단점도 있는 것 같습니다.
4. 데이커 카탈로그
일반적으로 메타데이터를 glue나 다른 데이터베이스를 통해 관리하는데 이러한 정보를 통해 이해관계자에게 데이터베이스의 내용을 쉽게 전달하는게 쉽지 않습니다.
이전에 Datahub를 적용하려다 실패 한 경험이 있기 때문에 이러한 점에 대해서 생각한 적이 있었는데, 클라우드 서비스의 장점 중 하나가 이러한 데이터 카탈로그를 만들 수 있는 장점이 있다고 합니다.
이러한 메타데이터는 마이그레이션 할 때 스키마의 정보를 통해 쉽게 테이블을 복제 할 수 있게 해주기도하고, 메타데이터를 통해 일련의 자동화 시스템을 구축하는데에도 도움이 됨을 알게 되었습니다.
5. Athena를 쓸때는 최적화 해라
S3에 넣을 때 압축이 잘 되어 있는지, 조인 할 때는 기준 테이블을 큰 테이블로, LIKE는 %보다 정규 표현식을 사용해서, 파티셔닝을 통해 검색 범위를 좁히기 등 다양한 방법이 있다고 합니다.