IT STUDY LOG
[데이터베이스] 02. 문제 상황에 따른 해결책 본문
# 학습 목표
- RDBMS와 NoSQL의 차이와 각각의 장단점을 이해할 수 있다.
- 충분한 가용성이 확보되지 않은 다양한 문제 상황을 이해하고, 상황에 따른 솔루션이 무엇인지 이해할 수 있다.
- 다음 용어에 대한 간단한 정의를 내릴 수 있다: 인덱싱, 레플리카, 파티셔닝, 캐싱, 배치 작업, 스트림 처리
- 이벤트 기반 아키텍처를 설명할 수 있다.
- RDBMS에서 테이블을 만들 때 스키마(필드) 디자인을 할 수 있다.
- 데이터 파이프라인의 필요성을 이해할 수 있다.
- OLTP와 OLAP의 차이를 이해할 수 있다.
- ETL 과정을 설명할 수 있다.
- MLOps와 DevOps의 차이를 이해할 수 있다.
- 리눅스 명령과 프로그래밍 언어를 이용해 간단한 데이터 파이프라인을 구현할 수 있다.
- 간단한 수준의 SQL문을 사용할 수 있다.
# 학습 내용
목차
1. 낮은 검색 성능 - 인덱싱
2. 많은 사용자 - 레플리카(복제서버)
3. 대용량의 데이터 - 파티셔닝
4. 동일 데이터의 잦은 조회 - 캐싱
5. 배치 작업에 따른 성능 저하 - 스트림 처리
6. 수평확장된 데이터베이스와 중복처리 (Advanced)
1. 낮은 검색 성능 - 인덱싱
효율적인 검색을 위한 시도
DB의 핵심적인 기능 : 1) 데이터 저장, 2) 요청 시 저장된 데이터 중 일치하는 데이터 제공
요청 시 일치하는 데이터를 제공할 때 검색 성능을 향상하기 위해 인덱스를 사용
데이터 검색에 도움을 주기 위한 메타데이터
인덱스는 DB에 저장된 기본 데이터(primary data)에서 파생된 부가적인 메타데이터(meta-data : 데이터에 관한 구조화된 데이터)
원하는 위치를 찾는데 도움을 주는 이정표 역할
데이터에 영향을 주지 않는 인덱스
인덱스의 편집 사항은 DB 내용에는 영향을 주지 않고 질의(Query) 성능에만 영향
고려사항
인덱스 추가 시 별도의 인덱스 공간 (전체 DB의 10% 내외) 필요
또 데이터 삽입, 삭제, 수정 시 인덱스의 재구성 필요
인덱스를 구성할 때는 자주 사용하는 정도, 분포, 변경 주기 등을 다양하게 고려할 필요
2. 많은 사용자 - 레플리카(복제서버)
안정적인 서비스를 제공하기 위한 시도
많은 사용자가 하나의 DB에 접근할 경우 발생하는 성능 저하를 위한 이중화
원본이 되는 DB와 같은 데이터를 다른 위치에 존재하는 여러 노드에 유지하는 방식
데이터의 중복성 발생
레플리카 활용의 장점
시스템 장애 발생 시에도 동작할 수 있도록 가용성 확보
일부 노드가 사용 불가능 상태여도 다른 노드를 통해 데이터 제공 가능
서비스 중단 시간 최소화
읽기 쿼리 제공 장비 수를 확장해 읽기 처리량을 늘림
요청이 하나의 DB에 집중될 경우 부하 증가, 성능 저하 발생
웹 기반 애플리케이션의 경우 쓰기 요청보다 읽기 요청 비율이 더 높음
DB 자체의 성능을 향상하는 것은 고비용
레플리카를 읽기 전용 DB로 활용해 MASTER(LEADER) DB에는 읽기, 쓰기를 처리하고 SLAVE(REPLICA) DB에 발생한 쓰기를 동기화해서 READ-ONLY로 활용
사용자 트래픽이 각 DB로 분산되어 성능 향상
지연시간 감소
DB가 데이터를 요청하는 곳과 지리적으로 멀 경우 응답 시간 지연 가능성
레플리카를 각 지역에 분산시켜 해당 지역에서 가까운 사용자 요청을 처리하도록 하여 지연 시간 감소
레플리카 활용 시 고려해야 할 사항
모든 DB가 정확히 같은 데이터를 가지고 있도록 해야 함
기본적으로 리더 DB에 쓰기 요청이 들어올 경우 해당 데이터는 리더 및 레플리카에 똑같이 저장되어야 함
동기식 복제(synchronous)
리더 데이터 처리와 별개로 레플리카에서의 데이터 처리까지 모두 완료되어야만 프로세스 진행
리더, 레플리카 DB가 일관성 있게 최신 데이터 복사본을 가지고 있음이 보장
네트워크 문제 등으로 레플리카가 정상적으로 데이터 처리 작업을 완료할 수 없는 경우 응답을 받지 못한 리더 DB 역시 프로세스 진행 불가하므로 시스템 운영 중단의 위험 존재
비동기식 복제 (Asynchronous)
리더가 다른 레플리카 처리 응답을 기다리지 않음
리더는 레플리카에 데이터 처리 요청 후 자신의 작업이 완료되면 사용자 요청에 바로 응답
리더 DB에 문제가 없을 경우 레플리카 상태와 무관하게 사용자에게 서비스 제공 가능
하지만, 레플리카가 Read-Only로 운영될 경우 사용자에게 리더와 일관성 있는 응답을 주지 못할 가능성 존재
데이터 불일치가 발생하므로 불일치 상태가 길어질 경우 큰 문제
리더가 잘못되고 복구할 수 없는 상황이 발생한다면 레플리카에게 복제되지 못한 데이터 유실 위험성
클라이언트에게 정상 작동을 알린 이후에도 지속성을 보장하지 못하는 문제 발생 가능성
반동기식 복제(semi-synchronous)
동기식 + 비동기식 하이브리드
하나의 레플리카는 동기식 복제 사용, 다른 레플리카는 비동기식 복 사용
정리
웹 애플리케이션 특징상(읽기 처리多) 읽기 요청 분산하는 전략은 리더의 부하를 줄일 수 있음
그러나 모든 레플리카에 동기식 복제 시도는 서비스 불안정 초래
동기식 복제의 문제점을 해결하기 위한 비동기식 복제의 경우 데이터 일관성 문제 발생
최근 DB 성능 향상으로 데이터 불일치 문제가 줄어들어 서비스 중단 보다 데이터 불일치 감수하고 일관성 유지하는 방법 택하는 경우가 많음
심화학습 키워드
다중 리더 복제
리더 없는 복제
3. 대용량의 데이터 - 파티셔닝
대용량 데이터를 처리하기 위해 데이터셋을 쪼개기
DB에 들어가는 데이터셋이 크거나 쿼리 처리량이 높은 경우 복제만은 부족
큰 DB를 파티션이라는 작은 단위로 쪼개 활용
파티션은 그 자체로 작은 DB
샤딩, 샤드라고도함
파티셔닝의 목적
확장성
DB가 확장되며 점점 대용량이 되고 그 환경에 맞게 프로세스를 처리할 필요성
데이터셋을 여러 디스크 분산 하의 요청에 따른 질의 부하를 여러 곳으로 분산
SPoF 문제 발생 가능성
파티셔닝을 통해 DB를 작은 범위로 나눠 요청받은 데이터에 해당하는 파티션에만 접근해 정보를 조회하여 성능 저하 해결
쏠림현상(skewed) 방지를 위한 시도
일반적으로 파티셔닝과 레플리카는 함께 사용됨
파티션 내부에 각 파티션의 복사본을 여러 노드에 저장해서 요청의 쏠림 현상을 방지
특정 패턴을 가진 요청에 의해 한 파티션(핫스팟)에 요청이 쏠리는 현상(skewed) 발생한다면 파티셔닝 효과가 저하
데이터 쿼리(질의) 부하를 노드 사이게 고르게 분산시킬 수 있도록 전략적 배치 필
고른 분포를 위한 전략
① 레코드를 할당할 노드를 무작위로 선택하는 것
기계적으로 무작위 선택을 통해 분산효과를 얻을 수 있지만, 데이터를 읽어내야 할 때는 특별한 기준으로 찾을 수 없기 때문에 성능저하 발생 가능
② 키 범위를 기준으로 한 파티셔닝을 진행하는 것
데이터에 접근하기 위한 키를 일정한 기준(키이름에 대해서 a to z를 확인하거나 또는 저장 날짜를 기준으로 키를 분류)에 따라 배치해서 파티션을 구성
(ex) a to z를 통해 키 범위를 설정할 경우, 단어 수가 많은 a는 크기 때문에 단독으로 분류하고, 후반부 xyz로 시작되는 단어들은 하나의 파티션으로 묶이는 형태
키 범위 기준 파티셔닝의 경우에도 특정 접근 패턴이 핫스팟을 유발하는 경우가 여전히 존재
(ex) 타임스탬프를 키로 사용해서 파티션 범위를 구성했다면, 하루치 데이터를 담당하는 특정 파티션에 쏠림 현상이 발생할 수 있음
③ 키의 해시값 기준 파티셔닝
쏠림 현상이 일어날 수 있는 데이터라도 해시함수를 통해 처리를 거쳐 균일하게 분산
핫스팟 발생은 막을 수 있지만, 역시 범위 쿼리 효율성이 높은 키 범위 파티셔닝의 장점을 잃어버린다는 단점
∴ 결과적으로 파티셔닝을 진행할 때는 각 서비스의 목적에 따라 검색 효율성을 높이는 것이 좋을지, 핫스팟 발생을 방지하는 것이 좋을지, 균형을 유지할 수 있는 적절한 방법을 구현해야 함
4. 동일 데이터의 잦은 조회 - 캐싱
특정 데이터에 대한 반복된 요청을 효과적으로 처리하기 위한 시도
임시로 복제된 데이터를 저장하는 장소로 사용자가 더 효율적이고 빠르게 원하는 데이터에 접근할 수 있도록 함
캐싱을 이용하면 원본 DB가 제공할 수 있는 것보다 더 짧은 대기 시간으로 웹 애플리케이션 성능 향상 및 DB 비용 절감 가능
캐시 사용의 장점
성능향상
DB는 기본적으로 속도보다는 데이터의 저장과 안정성에 초점(디스크 기반 데이터 저장소)
캐시의 경우에는 임시로 데이터가 저장되는 장소이기 때문에, 저장의 기능보다는 정보를 제공하는 처리 속도에 더 집중 가능(인 메모리 캐시)
따라서 사용자의 요청이 반복되는 데이터를 빠르게 제공하기 위해서 캐시를 활용하게 되면, 원본 데이터가 존재하는 DB에 액세스 하는 것보다 훨씬 빠른 속도로 데이터를 제공하면서 전반적인 애플리케이션 환경이 개선
비용감소
DB의 성능을 높이거나, 많은 쿼리(질의) 요청을 처리하는 것은 모두 고비용
캐시를 사용해 원본 DB에 대한 쿼리 수를 줄이고, DB 자체를 스케일링할 필요성을 낮추면, 성능 향상과 더불어 비용을 절감하는 효과
캐시 타입
Cache-aside
읽기 작업이 많은 웹 애플리케이션 특성상 캐시 보관 패턴을 사용
앱은 먼저 캐시에서 데이터를 검색하고, 존재하지 않을 경우 DB에 접근, DB에서 데이터를 확보한 경우 해당 데이터를 캐시에 복사
Read-through/Write-through Cache
읽기 처리가 많은 워크로드에 적합한 캐시 방법
DB 앞단에 일렬로 배치되며 애플리케이션은 DB가 아닌 캐시를 주 데이터 저장소처럼 취급
Read-through를 통해 애플리케이션이 데이터를 읽으려 하면 최초 데이터 로드할 때만 캐시가 dB에 접근하고 이후 동일 데이터는 캐시에서 처리. Cache-Aside 방식과 달리 애플리케이션이 캐시에 기록하지 않으므로 애플리케이션 부하 경감
Write-through를 통해 애플리케이션에서 쓰기 요청이 발생하면 우선 캐시에 데이터를 추가한 뒤 DB에도 데이터를 추가. 항상 최신 상태를 유지하며 데이터 일관성 보장이 가능
∴ Read-through, Write-through를 함께 사용하면 데이터 일관성을 보장하며 애플리케이션 코드를 단순화하고 원본 DB에 전달되는 요청 최소화가 가능
Write-behind/write-back Cache
쓰기 처리가 많은 워크로드에 적합한 캐시 방법
애플리케이션이 일단 캐시에 데이터를 저장
이후 캐시가 백그라운드에서 비동기적인 방식으로 DB에 데이터를 기록
∴ 애플리케이션은 DB에 쓰기가 완료되는 것을 기다릴 필요 없이 다음 작업 진행 가능하므로 사용자에게 좀 더 쾌적한 사용 환경 제공이 가능
5. 배치 작업에 따른 성능 저하 - 스트림 처리
데이터 배치작업
Data Batch Processing
데이터 일괄 처리 작업
유입되는 데이터를 특정량 또는 특정기간 모아 한 번에 처리한다는 의미
일괄 작업은 최소한의 인간 상호 작용으로 실행 가능
자주 사용되는 프로그램을 위한 것
실시간 처리가 아니라 일괄적으로 모아 한 번에 처리하는 작업
컴퓨터 하드웨어가 비싸고 상대적으로 성능이 떨어지는 경우에 배치 작업을 사용하면 컴퓨팅 하드웨어에 대한 자본 투자를 최대한 활용할 수 있으며 제한된 처리 능력을 업무 시간 동안 우선순위가 높은 작업에 할당 가능
배치의 특징
- 대량의 데이터 처리
- 특정 시간에 프로그램 실행
- 일괄적으로 처리
배치 작업의 단점
순차 실행으로 앞선 프로그램 실행이 끝나야만 뒤에 등록된 데이터가 실행되므로 실행시간이 많이 필요한 응용 프로그램이 실행될 경우 컴퓨터 응답시간이 늦을 수 있음
CPU가 필요없는 시간대에도 응용 프로그램이 CPU를 점유하고 있을 수 있으므로 총 실행 시간이 오래 걸릴 수 있음
배치작업으로 인한 성능저하
서버 성능 저하시 컴퓨터 자체 물리적 성능 향상을 위한 수직 확장을 고려하나 대체적으로 성능 저하 주요 원인은 DB 관련 비효율에 있음(Not CPU, 메모리 But 비효율적인 I/O)
대량의 배치 작업을 한꺼번에 진행하게 되면 특정 시간대에 I/O가 몰려 서버에 갑작스러운 부하 발생 가능
기술 발달로 인해 물리적인 서버 수직 확장이 가능하나 수직 확장 기술 속도가 늘어나는 데이터 속도를 따라가기는 어려움
DB 성능 개선을 위해 DB를 효율적으로 처리하는 것이 중요
DB를 효율적으로 처리하는 방법
데이터는 계속해서 만들어지므로 처리 간격을 줄이는 것(처리를 자주하는 것)이 필요
시간을 초단위, 밀리초 단위로 처리하거나 고정된 시간이 아닌 이벤트 발생 시 처리하도록 함
데이터 배치 처리 vs 데이터 스트림 처리
| batch 처리 | stream 처리 | |
| 데이터 크기 | 방대한 양의 미사용 데이터 | 개별적이거나 소수의 기록 |
| 데이터 범위 | 사용 가능한 모든 데이터 | 최신 이벤트 |
| 성능 | 높은 지연 시간(수시간에서 수일이 걸림) | 짧은 지연 시간(밀리초에서 초 단위) |
| 분석 | 대규모 데이터 세트에 복잡한 분석 | 간단한 분석, 실시간 응답 |
| 사용예 | 은행업무, 정산시스템, 리포트 및 리서치 | 실시간 운송추적, 실시간 미디어 송출 IoT센서, 결제처리 시스템 서버 및 애플리캐이션 로그 |
데이터 처리 방식에는 각각 장단점이 있기 때문에 유연하게 프로젝트마다 다른 접근 방식으로 각 사용 사례에 맞는 최적의 솔루션을 찾아야 함
데이터 스트림
데이터 스트림
데이터 스트림 처리
데이터가 생성되는 즉시 연속 스트림 처리
스트리밍 데이터를 실시간 분석
데이터 크기를 알 수 없고 무안하고 연속적일 때 사용
데이터 처리에 몇 초, 몇 밀리초 소요
데이터 출력 속도는 데이터 입력 속도만큼 빠름
데이터 스트림이 연속적이고 즉각적인 응답이 필요할 경우 스트림 처리 사용
데이터가 생성되자마자 분석 시스템에 하나씩 데이터 공급
실시간으로 필요한 정보 이용 가능
데이터 스트림 특징
시간에 민감함
테이터 스트림의 각 요서는 타임 스탬프를 전달
데이터 스트림은 시간에 민감하며 특정 시간이 지나면 중요성을 잃게 됨
(ex) 의심스러운 움직임을 나타내는 홈 보안 시스템의 데이터는 관련성을 유지하기 위해 짧은 시간 내에 분석 및 처리되어야 함
연속성
스트리밍 데이터에는 시작과 끝이 없음
데이터 스트림은 연속적이고 실시간으로 발생하지만 시스템 요구 사항에 따라 항상 그 순간에 실행되는 것은 아님
다양성
스트림 데이터는 지리적으로 멀리 떨어져 있을 수 있는 수천 개의 서로 다른 소스에서 오는 경우가 많음
소스의 불일치로 인해 스트림 데이터에는 다양한 형식이 혼합되어 있을 수 있음
불완전성
소스의 다양성과 데이터 전송 메커니즘의 차이로 인해 데이터 스트림에 데이터 요소가 누락되거나 손상될 수 있음
스트림의 데이터 요소가 순서대로 도착하지 않을 수 있음
휘발성
데이터 스트리밍이 실시간으로 이루어지기 때문에 스트림을 반복적으로 전송하는 것은 상당히 어려움
재전송에 대한 조항이 있지만 새 데이터는 마지막 데이터와 동일하지 않을 수 있음
많은 최신 시스템은 데이터 스트림의 기록을 유지하므로 현재 액세스 할 수 없더라도 나중에 분석가능
데이터 스트림을 처리하기 위해서는
오늘날 데이터는 IoT 센서, 서버, 보안 로그, 애플리케이션, 내외부 시스템과 같이 수많은 소스에서 끊임없이 생성되므로 데이터의 구조나 무결성을 제어하고 생성된 데이터 양이나 속도 제어하는 것이 거의 불가능
기존의 솔루션의 경우 데이터 실행 전에 데이터를 수집하고 처리하도록 아키텍처가 구축되었으나, 스트리밍 아키텍처는 이동 중인 데이터를 사용하고 스토리지에 보관, 강화, 분석하는 기능을 하게끔 되어있음
스트림으로 작업하는 애플리케이션은 항상 저장, 처리 두가지 주요 기능이 필요함
짧은 대기 시간
데이터 스트림이 시간에 민감하므로 스트림 프로세서는 연속적인 데이터 스트림에서 빠르게 작동해야 함
처리 지연은 데이터의 가치를 저하
확장성
스트리밍 데이터의 양이 항상 같지는 않음
(ex) 운행 중인 자동차의 위치를 추적하는 시스템에서 운행 차량의 양이 많을 수도 있고 늦은 시간에는 운행하는 차량이 없을 수도 있음
데이터의 양은 예측할 수 없기 때문에 프로세서는 필요한 경우 많은 양의 데이터를 처리할 수 있도록 확장되어야 함
가용성
스트림 프로세서는 긴 가동 중지 시간을 감당할 수 없음
스트림 데이터는 연속적이며 실시간으로 도착하므로 프로세서는 결함 내성이 있어야 함
즉, 일부 구성 요소에 장애가 발생하더라도 계속 작동할 수 있어야 함
또한 스트림 프로세서는 정보를 수집, 처리 및 즉시 상위 계층으로 전달하여 프레젠테이션을 수행할 수 있어야 함
데이터 스트림 처리의 이점
대다수 산업 부문과 빅데이터 사용 사례 등 새로운 동적 데이터가 지속적으로 생성되는 경우 유용
데이터 스트림 처리의 예
사물 인터넷
IoT에는 센서를 사용하여 데이터를 수집하고 실시간으로 데이터 프로세서에 전송하는 수많은 장치를 포함
IoT 데이터는 실시간으로 데이터를 생성하고 스트리밍(웨어러블 건강 모니터, 가정 보안 시스템, 교통 모니터링 시스템, 생체 인식 스캐너, 연결된 가전제품, 사이버 보안 및 개인 정보 보호 시스템 등)
실시간 주식 시장 모니터
실시간 금융 데이터는 종종 스트림 형식으로 전송
금융 데이터(예: 주가 및 시장 동향)의 처리 및 분석은 조직에 중요한 결정을 빠르게 내리는 데 도움
활동 및 트랜잭션 로그
인터넷은 실시간 스트림 데이터의 주요 소스
사람들이 웹사이트를 방문하거나 링크를 클릭하면 웹 브라우저는 활동 로그를 생성
신용 카드 구매와 같은 온라인 금융 거래도 실시간 조치를 위해 스트리밍 및 처리할 수 있는 시간이 긴급한 데이터를 생성
프로세스 모니터
모든 회사는 내부 시스템에서 수십억 개의 데이터 포인트를 생성하며 데이터를 스트리밍하고 실시간으로 처리함으로써 시스템 상태를 모니터링하고 상황이 확대되기 전에 조치가 가능
(ex) 제조 회사의 조립 라인의 상태를 모니터링하고 결함을 감지하여 생산 위험을 평가하는 장치
이벤트
이벤트란?
시스템 하드웨어 or 소프트웨어의 상태가 변화하는 것 혹은 중대 사건의 발생을 의미
vs. 시스템의 다른부분에 이벤트가 발생함을 알리기 위해 해당 시스템에서 보내는 메시지나 알림을 뜻하는 이벤트 알림과는 다른 개념
이벤트 소스는 내부, 외부 입력일 수 있고 마우스 클릭, 키보드 입력과 같은 사용자 또는 센서 출력과 같은 외부 소스에서 생성되거나 프로그램 로딩과 같이 시스템에서 비롯될 수도 있음
이벤트 기반 아키텍처
이벤트 기반 아키텍처는 조직이 실시간으로 변화에 대응하여 의사 결정을 내릴 수 있는 유연한 시스템을 확보할 수 있도록 지원
실시간 상황 인식은 시스템의 현재 상태를 반영하는 데이터를 모두 십분 활용하면서 수동 또는 자동으로 비즈니스 결정을 내릴 수 있음을 의미
구성
이벤트 생성자 : 이벤트 감지해 메시지로 해당 이벤트를 나타내며 이벤트 소비자 또는 이벤트 결과를 알지 못함
이벤트 소비자 : 이벤트 감지 이후 이벤트 처리 플랫폼이 이벤트를 비동기식으로 처리하는 이벤트 채널을 통해 해당 이벤트 생성자에서 이벤트 소비자로 전송. 이벤트 발생 시 이벤트 소비자는 알림을 받아야 하며, 이벤트를 처리할 수도 있고 이벤트의 영향을 받기만 할 수도 있음
6. 수평확장된 데이터베이스와 중복처리 (Advanced)
빅 데이터 처리에서 확장성의 중요성
데이터 오버플로를 관리, 저장, 처리 하기 위해 데이터 스케일링이라는 기술 대두
수직 확장 or 수평 확장을 통해 많은 양의 데이터를 관리 및 이용
마이크로서비스와 클라우드 환경이 발달 되고 하드웨어 종속성이 줄며 수평 확장 기술로 컴퓨터 클론을 만들어 가용성을 향상
데이터 중복성
컴퓨터 클론은 안에 존재하는 데이터도 복제되어야함을 의미하며 데이터 중복 메커니즘은 가용성을 향상
데이터 불일치 등의 단점 또한 존재함
데이터 중복 발생의 원인
의도적, 우발적 데이터 중복에 따라 초래하는 결과가 다름
1. 관리 시스템 내의 소프트웨어(코딩) 품질
우발적 중복 원인으로 오작동 발생 가능
데이터 관리 시스템 전체에 적절하게 업데이트 되지 않을 수 있으며 알고리즘 저해와 DB 불일치 유발 가능
2. 백업 시스템
데이터 관리를 위한 의도적 중복
데이터 관리 시스템, 원본 DB 문제 완하를 위한 데이터의 복사본
데이터 중복성의 이점
정보 보호 개선
의도적인 데이터 중복성은 외부공격으로 부터 조직의 데이터를 보호함으로써 정보 보호 강화 가능
또 조직의 모든 데이터가 서로 다른 위치에 있는 경우 사이버 공격이 상당한 양의 데이터를 동시에 표적으로 삼기 어려움
데이터 백업 생성
데이터 중복성을 통해 조직은 스토리지 시스템의 데이터 세트 또는 사본이 손상될 때 정보를 보존 가능
예를 들어 데이터가 포함된 하드드라이브가 오작동하여 정보가 손실되는 경우 조직에서 동일한 정보를 클라우드에 백업 가능
데이터 엑세스 속도 향상
조직에서 데이터를 여러 위치에 보관하는 경우 일부 저장소 위치에 다른 위치보다 쉽게 액세스 가능
이를 통해 조직 내의 다양한 사용자가 여러 데이터 진입점에 액세스 하고 더 빠른 데이터 액세스 속도 향상 가능
데이터 정확성 보장
데이터 관리 시스템은 동일한 데이터에 대해 여러 위치를 가짐으로써 불일치를 평가하여 데이터의 정확성을 향상
다른 수준의 데이터 저장은 이후에 효율적인 품질 보증을 가능
정확한 분석
상당한 양의 데이터를 저장하는 조직은 일반적으로 추세를 분석하고 회사 또는 고객을 위한 보고서를 작성하는 데 데이터를 사용하며 이를 위해서는 회사가 의도적인 데이터 중복을 통해 보장할 수 있는 정확한 데이터가 필요
데이터 중복성의 문제점
불일치 증가
여러 위치에서 테이터를 보존하면 정보가 모든위치에서 즉시 업데이트 되지 않는 경우 불일치가 발생 가능
원본 저장 위치 정보가 변경되고 다른 복사본은 변경되지 않거나 한 복사본의 변경 사항이 Array 전체에 적용되지 않는 경우에 발생
데이터 손상 가능성
데이터 손상은 저장, 전송 또는 생성과정에서 정보가 손상되거나 오류가 발생하는 경우 발생
동일한 데이터의 복사본을 여러 개 저장하면 손상될 가능성이 더 증가
유지 비용 증가
데이터 중복성은 유지 관리하고 해결하는데 비용이 많이 듦
> 스토리지 : 클라우드와 온프레미스를 불문하고 스토리지 블록을 저장하는 데는 비용이 들기 때문에 중복 데이터를 제거하는 것은 매우 중요
> 네트워크 : 중복 데이터 블록을 기기에서 백업 서버와 스토리지로 불필요하게 전송하면 네트워크 경로가 여러 지점에서 포화됨
> 디바이스 : 파일을 호스팅하는 디바이스든 단순히 데이터를 전달하는 디바이스든 백업 경로상의 모든 기기는 중복 데이터를 위해 프로세서 사이클과 메모리를 낭비해야 함
> 시간: 기업은 애플리케이션과 데이터를 24시간 사용할 수 있어야 하므로 백업으로 인한 성능 저하는 달갑지 않음/ 이런 이유로 IT 관리자는 백업이 시스템 성능에 미치는 영향을 최소화하도록 일반적으로 백업 작업시간을 야간에 계획
사용할 수 없는 데이터 생성
상당한 양의 데이터를 보관하는 회사는 일반적으로 이를 사용하여 회사 또는 고객의 시장 정보 패턴을 평가
즉 부정확한 데이터가 있는 경우 평가 결과가 부정확할 수 있음
데이터 무결성 손상
데이터의 정확성, 일관성, 유효성 유지가 어려워 잦은 에러와 재개발 비용 발생 가능성
데이터의 중복을 줄이는 방법
마스터 데이터 활용
마스터 데이터는 데이터 관리자가 여러 시스템 또는 애플리케이션에서 공유하는 공통 비즈니스 데이터의 유일한 소스
마스터 데이터는 데이터 중복의 발생을 줄이지는 않지만 조직이 특정 수준의 데이터 중복을 적용하고 해결할 수 있도록 함
마스터 데이터를 활용해 변경되는 경우 조직에서 단일 정보를 업데이트
이 시스템은 중복 데이터가 최신 상태를 유지하고 동일한 정보를 제공
데이터베이스 정규화
정규화는 데이터 중복제거를 보장하기 위해 데이터베이스에 데이터를 효율적으로 배열하는 작업
정규화를 통해 회사의 데이터베이스에는 모든 레코드에서 유사하게 표시
데이터 정규화에는 일반적으로 데이터베이스의 열과 테이블을 정렬하여 종속성을 제거
현재 수많은 회사에 데이터 정규화에 관한 특별한 기준 세트가 있고 데이터 정규화에 대한 접근 방식들이 각각 다름
미사용 데이터 삭제
조직에서 더 이상 필요하지 않은 데이터를 보존하지 않는 것
데이터베이스 설계
데이터베이스 아키텍처를 관계형 데이터베이스(조직에 표준 필드가 있는지 확인하고 레코드를 일치시키고 테이블을 연결할 수 있도록 해줌)로 설계한다면 조직에서 반복을 쉽게 식별하고 제거 가능
데이터 중복처리
1. 데이터 중복 제거(Deduplication)
중복 데이터가 스토리지 비용에 미치는 영향을 감소
중복 부분을 찾아 해당 볼륨 데이터 검사하고 볼륨의 여유 공간을 최적화
데이터 중복제거는 데이터 충실도, 무결성을 손상시키지 않고 중복성을 최적화
주로 소프트웨어 레벨에서 이루어지며 중복 데이터를 파악해 처음 저장된 데이터만을 남기는 방식으로 진행
중복 데이터가 있는 자리에는 원본 데이터의 위치 표시
중복 부분을 파악하기 위해 주로 블록(block) 또는 청크(chunk)라는 하나의 데이터 덩어리로 나누고 각 블록에 고유의 해시 값을 부여해 구
데이터 중복제거 유형
- 저장 시점에 따른 유형
| 인라인 중복 제거(Inline deduplication) | 후처리 중복 제거(Post-process deduplication) | |
| 특징 | - 수신 데이터가 스토리지 미디어에 기록되기 전에 데이터 출소가 발생하는 중복을 제거하는데 사용되는 방법 - SDS 컨트롤러라는 중복 제거 도구를 통해 실시간으로 통과하는 데이터를 스캔해 중복 제거 - 일반적으로 원래 데이터 중복 제거가 되지 않는 데이터 세트가 디스크에 기록되지 않기 때문에 원시 디스크 용량 최적화 가능 - 실행되는 쓰기 작업도 낮아져 디스크 마모 감소 |
- 데이터가 먼저 저장 매체에 기록된 다음 복제, 압축 기회에 대해 분석 - 저장 장치에 한 번 저장된 후에만 중복 제거가 실행되므로 원시 데이터 크기만큼 필요한 초기 용량이 존재 - 용량 최적화 데이터는 데이터 제거 전보다 잠재적으로 더 적은 공간 요구사항으로 저장 미디어에 다시 저 |
- 데이터 분류 방식에 따른 유형
| 고정 블록 중복 제거(Fixed block deduplication) | 가변 블록 중복 제거(Variable block deduplication) | |
| 특징 | - 데이터를 고정된 블록 크기로 분류해 알고리즘을 통해 중복 제거 - 중복 제거 속도가 빠르고 CPU 부하가 적어 메인 스토리지에 사용 적합 - 모든 데이터 유형에 고정된 크기로 중복을 제거하므로 중복 제거율이 떨어지는 편 |
- 데이터 유형에 맞게 블록 크기를 자동으로 분류해 중복 제거 - 블록 크기를 유연하게 조정할 수 있어 데이터 유형이 다양한 경우 적합하며 중복제거 효율이 좋음 - 블록 크기 파악이나 해시 처리 등으로 CPU 부하가 높아 워크로드 부담이 많은 메인 스토리지에는 부적합하고 백업용 스토리지에 적합 |
- 진행 위치에 따른 유형
| 소스 기반 중복 제거(Source-based deduplication) | 타깃 기반 중복 제거(Target-based deduplication) | |
| 특징 | - 소스 측에서 중복제거를 진행한 후 타겟에 전송하는 방식 - 타겟으로 전송되는 데이터양을 크게 감소시킬 수 있으며 전반적인 백업 속도 향상 가능 - 중복 제거를 위한 해시 생성 작업으로 CPU 부하가 늘고 데이터 복구 속도가 느린 편 - 대역폭을 절약해 낮은 대역폭 환경에서 원격 백업에 특화되어있으며 SW 백업 에이전트만 설치하므로 구축이 간단해 소규모 원격 사무소에 적합 - 백업 장치의 용량과 비욜 효율 확보에 적합 |
- 타겟 스토리지에서 진행되는 중복 제거 - 소스에 상관없이 타겟마다 같은 소프트웨어 사용이 가능하며 대부분의 백업 소프트웨어와 호환된다는 장점 - 리소스 부하 없이 진행되어 서비스 운용이나 복구 속도에 지장 주지 않음 - 소스에서 모든 데이터를 그대로 가져오기 때문에 리소스 사용 많음 - 중복 제거 작업보다 업로드 시 발생하는 리소스 비용이 낮은 경우에 적합 - 소스 중복 제거에 비해 오래된 기술로 안정적이므로 대규모 DB나 일일 데이터 변경 빈도가 높은 DB 구축환경에 도입하기 적합 |
2. 데이터 압축(Compresstion)
한 행에 나타나는 동일 데이터 시퀀스를 먼저 찾은 후 첫번째 시퀀스만 저장하고 다음의 동일한 시퀀스를 행에 나타나는 횟수에 대한 정보로 대체해 데이터 크기를 줄이는 알고리즘 프로세스
바이너리 수준에서 데이터 크기를 더 작게 만들면 디스크 공간 절약이 가능하므로 사용 가능한 용량에 더 많은 데이터 저장 가능
압축은 데이터 세트 자체의 특성, 즉 압축 가능한 형식인지 여부와 압축 가능한 양에 따라 다름
일반적으로 압축 알고리즘을 사용해 중복 문자열과 추가 공백을 제거 후 압축된 데이터를 스토리지 내 압축 청크에 저장
이 유형으로 압축할 경우 데이터 손실 없음
'devops bootcamp 4 > 개발 및 배포' 카테고리의 다른 글
| [데이터베이스] 03. 데이터 파이프라인 (0) | 2023.03.30 |
|---|---|
| [데이터베이스] 01. 데이터베이스 기초 (0) | 2023.03.29 |
| [WAS와 Web Server] 04. CORS (0) | 2023.03.27 |
| [WAS와 Web Server] 03. nginx Web Server와 웹 호스팅 (1) | 2023.03.24 |
| [WAS와 Web Server] 02. 정적 웹사이트와 동적 웹사이트 (0) | 2023.03.24 |
