DevOps14일차 - DB(스트림 처리, 수평확장된 데이터베이스와 중복처리)

배치 작업에 따른 성능 저하 - 스트림 처리

데이터 배치작업

Data Batch Processing

사전적 의미의 Batch는 ‘일괄’, ‘묶음’을 뜻합니다. 그래서 데이터 배치작업을 데이터 일괄처리작업이라고 칭하기도 합니다. 이름에서 알 수 있듯이 유입되는 데이터를 특정량 또는 특정기간 모아서 한번에 처리한다는 의미입니다. 우리가 처리해야 할 데이터가 늘어날 수록 그 데이터를 처리하는 컴퓨터도 그만큼 성능을 소모하게 될 것이고 처리하는 시간도 늘어나게 됩니다. 일괄 작업은 최소한의 인간 상호 작용으로 실행 할 수 있으며, 자주 사용되는 프로그램을 위한 것입니다. 쉽게 말해서 배치작업은 데이터를 실시간으로 처리하는 것이 아니라 일괄적으로 모아서 한번에 처리하는 작업을 의미합니다. 예를 들어서 은행의 정산 작업의 경우 배치 작업을 통해 일괄처리를 수행하게 되며 사용자에게 빠른 응답이 필요하지 않은 서비스에 적용할 수 있습니다. 컴퓨팅 하드웨어가 비싸고 상대적으로 성능이 떨어졌을 때 이 배치작업이 컴퓨팅 초기에 매우 중요했습니다. 배치작업을 하게되면 컴퓨팅 하드웨어에 대한 자본 투자를 최대한 활용할 수 있으며 제한된 처리 능력을 업무 시간 동안 우선 순위가 높은 작업에 할당할 수 있습니다.

배치의 특징

• 대량의 데이터 처리
• 특정 시간에 프로그램 실행
• 일괄적으로 처리

배치 작업의 단점

예약된 일이 순차적으로 실행되기 때문에 앞선 프로그램의 실행이 다 끝나야지만 뒤에 등록된 데이터가 실행이 됩니다. 즉 앞단에 실행시간이 많이 필요한 응용 프로그램이 실행될 경우 컴퓨터 응답시간이 오래 걸릴 수가 있습니다. 그리고 CPU가 필요없는 시간대에도 응용 프로그램이 CPU를 점유하고 있을 수 있기 때문에 총 실행 시간도 오래 걸릴 수 있습니다. 컴퓨터 프로세스에서 시간이 오래 걸린 다는 뜻은 곧 성능 저하를 의미합니다.

배치작업으로 인한 성능저하

우리가 보통 서버의 성능저하를 겪게 되면 컴퓨터 자체의 물리적 성능향상을 위해 수직확장을 고려하곤 합니다. 하지만 대부분의 성능저하 주요 원인은 DB관련 비효율에 있습니다. 즉 성능저하의 핵심은 CPU나 메모리의 부하가 아닌 비효율적인 I/O(Input, Output) 때문입니다.

대량의 배치작업을 한꺼번에 진행하게 되면 특정시간대에 I/O가 몰리게 되어 서버에 갑작스러운 부하가 일어나 성능이 저하 될 수 있습니다. 기술의 발달로 인해 물리적인 서버의 수직확장이 가능하기는 하지만 수직확장의 기술 속도가 늘어나는 데이터의 속도를 따라가기란 결코 쉬운일이 아닙니다. DB의 성능 개선을 위해서는 DB를 효율적으로 처리하는 것이 중요합니다.

DB를 효율적으로 처리하는 방법

데이터는 계속해서 만들어지게 됩니다. 어제도 오늘도 내일도 계속해서 데이터는 생산이 됩니다. 일괄처리를 하게 된다면 어떤 의미로든 그 데이터셋은 절대 완료 되지 않습니다. 만약 데이터를 일별로 일괄처리를 한다면 입력의 변화가 하루가 지나야 반영이 됩니다. 급속한 현대사회의 사용자가 느끼기에는 너무 느릴 수 있습니다. 이러한 지체를 줄이기 위해서는 좀 더 자주 처리를 실행해야 합니다. 시간을 초단위, 밀리초 단위로 해서 데이터를 처리하거나, 또는 고정된 시간이 아닌 단순히 이벤트가 발생할 때마다 처리를 해야 합니다. 이 방법이 스트림 처리의 기본개념입니다.

데이터 배치 처리 vs 데이터 스트림 처리

데이터 처리에 있어 유연성은 그 조직에 아주 중요한 요소입니다. 프로젝트마다 다른 접근 방식이 필요하고, 각 팀은 각 사용 사례에 맞는 최적의 솔루션을 찾을 수 있는 수단을 갖추고 있어야 합니다.

데이터 스트림

데이터 스트림 처리

스트림 처리는 데이터가 생성되는 즉시 연속 스트림을 처리하는 것을 의미합니다. 스트리밍 데이터를 실시간으로 분석하는 것으로, 스트림 처리는 데이터 크기를 알 수 없고 무한하고 연속적일 때 사용이 됩니다. 말 그대로 흘러가는 데이터 줄기같은 개념입니다. 데이터를 처리하는 데 몇 초 또는 몇 밀리초 정도의 시간이 걸립니다. 스트림 처리에서 데이터 출력 속도는 데이터 입력 속도만큼 빠르며, 스트림 프로세서는 데이터를 몇 번의 패스로 처리합니다. 데이터 스트림이 연속적이고 즉각적인 응답이 필요한 경우 스트림 처리가 사용됩니다. 스트림 처리를 통해 데이터가 생성되자마자 분석 시스템에 하나씩 데이터가 공급이 됩니다. 이를 통해 거의 실시간으로 필요한 정보를 이용할 수가 있습니다.

데이터 스트림 특징

• 시간에 민감함
  테이터 스트림의 각 요서는 타임 스탬프를 전달합니다. 데이터 스트림은 시간에 민감하며 특정 시간이 지나면 중요성을 잃게 됩니다. 예를 들어, 의심스러운 움직임을 나타내는 홈 보안 시스템의 데이터는 관련성을 유지하기 위해 짧은 시간 내에 분석 및 처리되어야 합니다.
• 연속성
  스트리밍 데이터에는 시작도 끝도 없습니다. 데이터 스트림은 연속적이고 실시간으로 발생하지만 시스템 요구 사항에 따라 항상 그 순간에 실행되는 것은 아닙니다.
• 다양성
  스트림 데이터는 지리적으로 멀리 떨어져 있을 수 있는 수천 개의 서로 다른 소스에서 오는 경우가 많습니다. 소스의 불일치로 인해 스트림 데이터에는 다양한 형식이 혼합되어 있을 수 있습니다.
• 불완전성
  소스의 다양성과 데이터 전송 메커니즘의 차이로 인해 데이터 스트림에 데이터 요소가 누락되거나 손상될 수 있습니다. 또한 스트림의 데이터 요소가 순서대로 도착하지 않을 수 있습니다.
• 휘발성
  데이터 스트리밍이 실시간으로 이루어지기 때문에 스트림을 반복적으로 전송하는 것은 상당히 어렵습니다. 재전송에 대한 조항이 있지만 새 데이터는 마지막 데이터와 동일하지 않을 수 있습니다. 이로부터 데이터 스트림은 휘발성이 높습니다. 그러나 많은 최신 시스템은 데이터 스트림의 기록을 유지하므로 현재 액세스할 수 없더라도 나중에 분석할 수 있습니다.

데이터 스트림을 처리하기 위해서는

오늘날의 데이터는 IoT 센서, 서버, 보안 로그, 애플리케이션 그리고 내외부 시스템과 같은 수많은 소스에서 끊임없이 생성이 됩니다. 이렇기 때문에 데이터의 구조나 무결성을 컨트롤하고 생성된 데이터의 양이나 속도를 제어하는 것이 거의 불가능할 정도로 되었습니다. 기존의 솔루션 들은 데이터가 실행되지 전에 데이터를 수집하고 처리하도록 아키텍쳐가 구축이 되었지만 스트리밍 아키텍처는 이동 중인 데이터를 사용하고 스토리지에 보관, 강화, 분석하는 기능을 하게끔 되어 있습니다. 이러한 이유로 스트림으로 작업하는 애플리케이션에는 항상 저장과 처리하는 두가지 주요 기능이 필요합니다. 또한 스트림 데이터의 고유한 특성에 알맞는 요구사항들을 충족해야 합니다.

• 짧은 대기 시간
  스트림 프로세서는 연속적인 데이터 스트림에서 빠르게 작동해야 합니다. 이것은 데이터 스트림이 시간에 민감한 특성때문입니다. 모든 처리 지연은 데이터의 가치를 저하시키는 것과 직결이 됩니다.
• 확장성
  스트리밍 데이터의 양이 항상 같지는 않습니다. 예를 들어, 운행중인 자동차의 위치를 추적하는 시스템에서 운행 차량의 양이 많을 수도 있고 늦은 시간에는 운행하는 차량이 없을 수도 있습니다. 데이터의 양은 예측할 수 없기 때문에 프로세서는 필요한 경우 많은 양의 데이터를 처리할 수 있도록 확장되어야 합니다.
• 가용성
  스트림 프로세서는 긴 가동 중지 시간을 감당할 수 없습니다. 스트림 데이터는 연속적이며 실시간으로 도착합니다. 프로세서는 결함 내성이 있어야 합니다. 즉, 일부 구성 요소에 장애가 발생하더라도 계속 작동할 수 있어야 합니다. 또한 스트림 프로세서는 정보를 수집, 처리 및 즉시 상위 계층으로 전달하여 프레젠테이션을 수행할 수 있어야 합니다.

데이터 스트림 처리의 이점

스트리밍 데이터 처리는 새로운 동적 데이터가 지속적으로 생성되는 시나리오 대부분에서 유용
합니다. 대다수 산업 부문과 빅 데이터 사용 사례가 이에 해당합니다. 일반적으로 기업은 최소-최대 컴퓨팅 롤링 같은 기본적인 처리와 시스템 로그 수집 등 간단한 애플리케이션으로 시작합니다. 그리고 이러한 애플리케이션이 좀 더 정교한 거의 실시간 처리로 진화하게 됩니다. 초기에는 애플리케이션이 데이터 스트림을 처리하여 간단한 보고서를 생산하고, 이에 대한 응답으로 주요 측정치가 특정 임계값을 초과할 때 경보를 내보내는 간단한 작업을 수행했습니다. 현재는 이러한 애플리케이션이 기계 학습 알고리즘을 적용하고 데이터에서 심도 있는 통찰력을 추출하는 등 더욱 정교한 형태의 데이터 분석을 하는 데 사용이 됩니다.

데이터 스트림 처리의 예

• 사물 인터넷: IoT에는 센서를 사용하여 데이터를 수집하고 실시간으로 데이터 프로세서에 전송하는 수많은 장치를 포함하고 있습니다. IoT 데이터는 스트림 데이터를 생성합니다. 워치와 같은 웨어러블 건강 모니터, 가정 보안 시스템, 교통 모니터링 시스템, 생체 인식 스캐너, 연결된 가전 제품, 사이버 보안 및 개인 정보 보호 시스템은 실시간으로 데이터를 생성하고 스트리밍합니다.
• 실시간 주식 시장 모니터: 실시간 금융 데이터는 종종 스트림 형식으로 전송됩니다. 금융 데이터(예: 주가 및 시장 동향)의 처리 및 분석은 조직에 중요한 결정을 빠르게 내리는 데 도움을 줍니다.
• 활동 및 트랜잭션 로그: 인터넷은 실시간 스트림 데이터의 주요 소스이기도 합니다. 사람들이 웹사이트를 방문하거나 링크를 클릭하면 웹 브라우저는 활동 로그를 생성합니다. 신용 카드 구매와 같은 온라인 금융 거래도 실시간 조치를 위해 스트리밍 및 처리할 수 있는 시간이 긴급한 데이터를 생성합니다.
• 프로세스 모니터: 모든 회사는 내부 시스템에서 수십억 개의 데이터 포인트를 생성합니다. 기업은 이 데이터를 스트리밍하고 실시간으로 처리함으로써 시스템 상태를 모니터링하고 상황이 확대되기 전에 조치를 취할 수 있습니다. 예를 들어, 제조 회사에는 종종 조립 라인의 상태를 모니터링하고 결함을 감지하여 생산 위험을 평가하는 장치가 있습니다. 이러한 장치는 또한 시간적으로 긴급한 데이터를 스트리밍하여 중지를 모니터링하고 방지할 수도 있습니다.

이벤트

이벤트란?
이벤트란 시스템 하드웨어 또는 소프트웨어 상태가 변화다는 것을 의미합니다. 또는 중대 사건의 발생을 의미하기도 합니다. 이벤트는 시스템의 다른 부분에 이벤트가 발생했음을 알리기 위해 해당 시스템에서 보내는 메시지 또는 알림을 뜻하는 이벤트 알림과는 다릅니다.

이벤트 소스는 내부 또는 외부 입력일 수도 있고, 마우스 클릭이나 키보드 입력과 같은 사용자 또는 센서 출력과 같은 외부 소스에서 생성되거나 프로그램 로딩과 같이 시스템에서 비롯될 수도 있습니다.

이벤트 기반 아키텍처

이벤트 기반 아키텍처는 이벤트 생성자와 이벤트 소비자로 구성되어 있습니다. 이벤트 생성자는 이벤트를 감지하며 메시지로 해당 이벤트를 나타냅니다. 생성자는 이벤트 소비자 또는 이벤트 결과를 알지 못합니다.

이벤트가 감지된 후에는 이벤트 처리 플랫폼이 이벤트를 비동기식으로 처리하는 이벤트 채널을 통해 해당 이벤트 생성자에서 이벤트 소비자로 전송됩니다. 이벤트 발생 시 이벤트 소비자는 알림을 받아야 하며, 이벤트를 처리할 수도 있고 이벤트의 영향을 받기만 할 수도 있습니다.

이벤트 기반 아키텍처는 조직이 실시간으로 변화에 대응하여 의사 결정을 내릴 수 있는 유연한 시스템을 확보할 수 있도록 지원합니다. 실시간 상황 인식은 시스템의 현재 상태를 반영하는 데이터를 모두 십분 활용하면서 수동 또는 자동으로 비즈니스 결정을 내릴 수 있음을 의미합니다.

수평확장된 데이터베이스와 중복처리 (Advanced)

빅 데이터 처리에서 확장성의 중요성

빅 데이터는 더이상 인상적이거나 새로운 유행어가 아닙니다. 오늘날의 비즈니스 환경에서 많은 기업의 성공에 필수적인 요소가 되었습니다. 그리고 우리는 현재 어마어마한 양의 사용가능한 데이터 속에 살고 있습니다. 이렇게 생성되고 처리되는 데이터의 양이 기하급수적으로 증가함에 따라 많은 기업의 데이터 베이스가 직면하고 있는 데이터의 홍수로 인해 압도당하고 있습니다. 이러한 데이터 오버플로를 관리, 저장 및 처리하기 위해 폭발적인 데이터 세트를 처리하는 많은 조직에서 “데이터 스케일링” 이라는 기술이 필요하게 되었습니다. 수직확장 또는 수평확장을 통해 상당한 양의 데이터를 관리하고 이용하고 있습니다. 그리고 마이크로서비스와 클라우드 환경이 발달이 되고 하드웨어의 종속성이 줄어들면서 우리는 수평확장 기술로 컴퓨터의 클론을 만들어 가용성을 높이고 있습니다.

데이터 중복성

높은 가용성을 위해 한 컴퓨터의 클론을 만든다는 것은, 그 안에 존재하는 데이터 역시 복제되어야 함을 의미합니다. 이러한 데이터 중복 메커니즘은 가용성을 얻기 위해 필요한 작업입니다. 물론 여기에는 Trade-off가 존재합니다. 각기 다른 컴퓨터가 동일한 데이터를 갖고 있어야 한다는 점을 떠올려보세요. 이는 상당히 도전적이고 복잡한 메커니즘이 뒤따르기 마련입니다.

데이터 중복 발생의 원인

• 관리시스템 내의 소프트웨어(코딩) 품질
  데이터 중복은 조직에 긍정적이거나 부정적인 결과를 가져옵니다. 그리고 그 결과는 그 중복인 의도적인지 우발적인지에 따라 다를 수 있습니다. 우발적인 데이터 중복의 원인 중 하나는 조직의 데이터 관리 시스템 내 소프트웨어 품질때문입니다. 이로 인해 경로 오작동으로 이어질 수 있습니다. 이는 곧 데이터 관리 시스템 전체에서 적절하게 업데이트 되지 않을 수 있음을 의미하며, 알고리즘을 방해하고 데이터베이스의 불일치를 유발 할 수 있습니다.

• 백업시스템
  데이터 관리에 정보의 정확성을 평가하기 위해 여러 계층이 포함되는 경우 의도적인 데이터 중복이 발생할 수 있습니다. 조직에 백업 스토리지가 있는 경우 백업은 데이터 관리 시스템 또는 원본 데이터베이스의 문제를 완화하기 위해 정보의 복사본 역할을 합니다. 이를 위해서는 궁극적으로 정보가 손상되고 부정확하지 않도록 보호해야 합니다.

데이터 중복성의 이점

• 정보 보호 개선: 의도적인 데이터 중복성은 외부공격으로 부터 조직의 데이터를 보호함으로써 정보 보호를 강화할 수 있습니다. 또한 조직의 모든 데이터가 서로 다른 위치에 있는 경우 사이버 공격이 상당한 양의 데이터를 동시에 표적으로 삼는 것도 어렵습니다.

• 데이터 백업 생성: 데이터 중복성을 통해 조직은 스토리지 시스템의 데이터 세트 또는 사본이 손상될 때 정보를 보존할 수 있습니다. 예를 들어 데이터가 포함된 하드드라이브가 오작동하여 정보가 손실되는 경우 조직에서 동일한 정보를 클라우드에 백업할 수 있습니다.

• 데이터 엑세스 속도 향상: 조직에서 데이터를 여러 위치에 보관하는 경우 일부 저장소 위치에 다른 위치보다 쉽게 액세스 할 수 있습니다. 이를 통해 조직 내의 다양한 사용자가 여러 데이터 진입점에 엑세스하고 더 빠른 데이터 액세스 속도를 즐길 수 있습니다.

• 데이터 정확성 보장: 데이터 관리 시스템은 동일한 데이터에 대해 여러 위치를 가짐으로써 불일치를 평가하여 데이터의 정확성을 향상 시킬 수 있습니다. 다른 수준의 데이터 저장은 이후에 효율적인 품질 보증을 가능하게 할 수 있습니다.

• 정확한 분석: 상당한 양의 데이터를 저장하는 조직은 일반적으로 추세를 분석하고 회사 또는 고객을 위한 보고서를 작성하는 데 데이터를 사용합니다. 이를 위해서는 회사가 의도적인 데이터 중복을 통해 보장 할 수 있는 정확한 데이터가 필요합니다.

데이터 중복성의 문제점

• 불일치 증가: 여러 위치에서 테이터를 보존하면 정보가 모든위치에서 즉시 업데이트 되지 않는 경우 불일치가 발생할 수 있습니다. 이는 원본 저장 위치 정보가 변경되고 다른 복사본은 변경되지 않거나 한 복사본의 변경 사항이 Array 전체에 적용되지 않는 경우에 발생 할 수 있습니다.

• 데이터 손상 가능성: 데이터 손상은 저장, 전송 또는 생성과정에서 정보가 손상되거나 오류가 발생하는 경우 발생합니다. 즉 동일한 데이터의 복사본을 여러 개 저장하면 손상도리 가능성이 더 커질 수 있습니다.

• 유지 비용 증가: 데이터 중복성은 유지 관리하고 해결하는데 비용이 많이 듭니다.

  • 스토리지 : 무엇보다도 클라우드와 온프레미스를 불문하고 스토리지 블록을 저장하는 데는 비용이 들기 때문에 중복 데이터를 제거하는 것은 매우 중요합니다.
  • 네트워크: 중복 데이터 블록을 기기에서 백업 서버와 스토리지로 불필요하게 전송하면 네트워크 경로가 여러 지점에서 포화 상태가 됩니다.
  • 디바이스: 파일을 호스팅하는 디바이스든 단순히 데이터를 전달하는 디바이스든 백업 경로상의 모든 기기는 중복 데이터를 위해 프로세서 사이클과 메모리를 낭비해야 합니다.
  • 시간: 기업은 애플리케이션과 데이터를 24시간 사용할 수 있어야 하므로 백업으로 인한 성능 저하는 달갑지 않은 현상입니다. 이런 이유로 IT 관리자는 백업이 시스템 성능에 미치는 영향을 최소화하도록 일반적으로 백업 작업시간을 야간에 계획합니다. 중복 데이터는 이렇게 귀중한 시간을 낭비합니다.

• 사용할 수 없는 데이터 생성: 상당한 양의 데이터를 보관하는 회사는 일반적으로 이를 사용하여 회사 또는 고객의 시장 정보 패턴을 평가합니다. 즉 부정확한 데이터가 있는 경우 평가 결과가 부정확할 수 있습니다.

무엇보다도 데이터 중복이 생기면 무결성이 깨지기 쉽습니다. 즉 데이터의 정확성, 일관성, 유효성이 유지되기가 어렵다는 것을 의미합니다. 이로 인해 부모 데이터와 자식 데이터 간의 논리적 관계가 깨어 질 수가 있고 잦은 에러와 재개발 비용이 발생할 수가 있습니다.

데이터의 중복을 줄이는 방법

• 마스터 데이터 활용
  마스터 데이터는 데이터 관리자가 여러 시스템 또는 애플리케이션에서 공유하는 공통 비즈니스 데이터의 유일한 소스입니다. 마스터 데이터는 데이터 중복의 발생을 줄이지는 않지만 조직이 특정 수준의 데이터 중복을 적용하고 해결 할 수 있도록 합니다. 마스터 데이터를 활용하면 변경되는 경우 조직에서 단일 정보를 업데이트 할 수 있습니다. 이 시스템은 중복 데이터가 최신 상태를 유지하고 동일한 정보를 제공하도록 합니다.
• 데이터베이스 정규화
  데이터베이스 정규화는 중복제거를 보장하기 위해 데이터베이스에 데이터를 효율적으로 배열하는 작업입니다. 이 프로세스를 통해 회사의 데이터베이스에는 모든 레코드에서 유사하게 표시되고 읽는 정보가 포함됩니다. 데이터 정규화에는 일반적으로 데이터베이스의 열과 테이블을 정렬하여 종속성을 올바르게 적용합니다. 이는 IT기업 뿐만아니라 여러 일반기업에서도 SQL을 다룰 수 있는 사원을 영입하려고 하는 이유이기도 합니다. 현재 수많은 회사에 데이터 정규화에 관한 특별한 기준 세트가 있고 데이터 정규화에 대한 접근 방식들이 각각 다릅니다.
• 미사용 데이터 삭제
  데이터 중복성에 기여하는 또 다른 요소는 조직에서 더 이상 필요하지 않은 데이터 조각을 보존하는 것입니다. 예를 들어, 조직은 고객 데이터를 새 데이터베이스로 옮기고 동일한 데이터를 이전 데이터베이스에 유지할 수 있습니다. 이는 데이터 중복 및 저장 낭비로 이어질 수 있습니다. 조직은 더 이상 필요하지 않은 데이터를 즉시 삭제하여 이러한 중복을 피할 수 있습니다.
• 데이터베이스 설계
  기업은 또한 데이터 베이스에서 직접 읽을 수 있는 사내 애플리케이션으로데이터 베이스 아키텍처를 설계할 수 있습니다. 관계형 데이터베이스는 조직에 표준 필드가 있는지 확인하고 레코드를 일치시키고 테이블을 연결 할 수 있도록 합니다. 이 방법을 사용하면 조직에서 반복을 쉽게 식별하고 제거 할 수 있습니다.

데이터 중복처리

1. 데이터 중복 제거(Deduplication)

데이터 중복 제거는 중복 데이터가 스토리지 비용에 미치는 영향을 줄이는데 도움이 되는 기능입니다. 중복제거가 설정된 경우 볼륨에서 중복된 부분을 찾기 위해 볼륨의 데이터를 검사하여 볼륨의 여유 공간을 최적화 합니다. 볼륨의 데이터 세트에서 중복된 부분이 한 번 저장되며 필요한 경우 추가적인 절약을 위해 압축됩니다. 데이터 중복 제거는 데이터 충실도 또는 무결성을 손상시키지 않고 중복성을 최적화합니다.

중복제거 작업은 주로 소프트웨어 레벨에서 이루어지며, 중복되는 데이터를 파악해 처음 저장된 데이터만을 남겨두는 방식으로 진행됩니다. 중복되는 데이터가 있는 자리에는 원본 데이터의 위치만 남겨둡니다. 이렇게 중복되는 부분을 파악하기 위해 주로 블록(block) 또는 청크(chunk)라는 하나의 데이터 덩어리로 나누고, 각 블록에 고유의 해시(hash)값을 부여해 구분합니다.

데이터 중복제거 유형

앞에서 언급했듯이 데이터 중복 제거의 프로세스는 동일한 데이터의 불필요한 사본을 없애 사본 하나만 저장하는 것으로 이루어 집니다. 이러한 프로세스는 다양한 방법이 존재합니다. 아래의 내용들은 데이터중복제거 유형을 나타낸 것입니다. 지금의 단계에서 아래의 내용은 여러분들에게 어려울 수 있습니다. 이러한 유형이 있다는 정도만 알아두시고 차차 데이터에 대한 전반적인 학습이 이루어진 이 후에 다시 살펴보시기 바랍니다.

<저장 시점에 따른 유형 >
인라인 중복 제거(Inline deduplication)

인라인 처리는 수신 데이터가 스토리지 미디어에 기록되기 전에 데이터 축소가 발생하는 중복을 제거하는 데 널리 사용되는 방법 입니다. 중복 제거 도구는 일반적으로 데이터가 배치되는 위치와 방법을 제어하는 SDS(Software Defined Storage) 컨트롤러 입니다. 이 툴을 통과하는 모든 데이터는 실시간으로 스캔해서 중복을 제거합니다. 인라인 처리는 일반적으로 원래 데이터의 중복 제거가 되지 않은 데이터세트는 디스크에 기록되지 않기 때문에 시스템에 필요한 원시 디스크 용량을 줄입니다. 따라서 실행되는 쓰기 작업도 그에 따라 낮아져 디스크 마모가 줄어듭니다.

후처리 중복 제거(Post-process deduplication)

후처리는 데이터가 먼저 저장 매체에 기록된 다음 복제 및 압축 기회에 대해 분석되는 접근 방식입니다. 데이터가 저장 장치에 한번 저장된 후에만 중복 제가가 실행되기 때문에 원시 데이터 크기(데이터 축소 전)만큼 필요한 초기 용량이 있습니다. 용량 최적화 데이터는 데이터 축소 전보다 잠재적으로 더 적은 공간 요구 사항으로 저장 미디어에 다시 저장됩니다.

<데이터 분류 방식에 따른 유형>
고정 블록 중복 제거(Fixed block deduplication)

데이터를 고정된 블록 크기로 분류해 중복제거를 진행하는 것을 말합니다. 이 방식은 고정된 블록 크기로 단순화 한 해시 알고리즘을 쓰기 때문에 중복 제거 속도가 빠르고 CPU 부하가 적습니다. 하지만 모든 데이터 유형에 고정된 크기로 중복을 제거하기 때문에 중복 제거율이 떨어지는 편입니다. CPU 부하가 적은 특성으로 인해 메인 스토리지에 사용하기 적합니다.

가변 블록 중복 제거(Variable block deduplication)

데이터 유형에 맞게 블록 크기를 자동으로 나누어 분류해서 중복제거를 진행합니다. 블록 크기를 유연하게 조정할 수 있어 데이터 유형이 다양한 경우에 적합하며, 매우 높은 중복제거 효율을 보일 수 있습니다. 단, 블록 크기 파악 및 해시 처리등으로 CPU 부하가 높아 워크로드에 부담이 많은 메인 스토리지에는 적합하지 않고 백업용 스토리지에 적합합니다.

<진행 위치에 따른 유형>
소스 기반 중복 제거(Source-based deduplication)

소스 측에서 중복제거를 진행한 후 타겟에 전송하는 방식을 말합니다. 이 방식의 경우, 타겟으로 전송되는 데이터양을 크게 감소시킬 수 있고, 전반적인 백업 속도를 향상시킬 수 있습니다. 다만 중복제거를 위한 해시 생성 작업으로 인해 소스 측 CPU 리소스가 소모되고, 데이터 복구 속도가 느린 점이 있습니다. 소스 중복제거는 대역폭을 절약하여 낮은 대역폭 환경에서의 원격 백업에 특화되어 있고, SW 백업 에이전트만 설치하기 때문에 구축이 간단해 소규모 원격 사무소에 적합한 방식입니다. 부가적으로 백업 장치의 용량과 비용 효율 확보에 적합합니다.

타깃 기반 중복 제거(Target-based deduplication)

타겟 스토리지에서 진행되는 중복제거를 말합니다. 이 방식은 소스에 상관없이 타겟마다 같은 소프트웨어를 사용할 수 있고, 대부분 백업 소프트웨어와 호환된다는 장점이 있습니다. 무엇보다 소스에 리소스 부하 없이 진행되어 서비스 운용이나 복구 속도에 지장을 주지 않습니다. 다만, 소스에서 모든 데이터를 그대로 가져오기 때문에 소스 중복제거보다 리소스 활용이 많은 점이 있습니다. 해당 방식은 중복제거 작업보다 업로드 시 발생하는 리소스 비용이 낮은 경우에 특화되어 있어 소스 측 성능을 확보하기에 적합합니다. 소스 중복제거에 비해 오래된 기술로 안정적이라 대규모 데이터베이스나 일일 데이터 변경 빈도가 높은 데이터베이스 구축환경에 도입하기 적합합니다.

2. 데이터 압축(Compresstion)

데이터 압축은 한 행에 나타나는 동일한 데이터 시퀀스를 먼저 찾은 다음 첫 번째 시퀀스만 저장하고 다음의 동일한 시퀀스를 행에 나타나는 횟수에 대한 정보로 대체하여 데이터 크기를 줄이는 알고리즘 프로세스 입니다.

바이너리 수준에서 데이터 크기를 더 작게 만들면 디스크 공간이 덜 사용되므로 사용 가능한 용량에 더 많은 데이터를 저장할 수 있습니다. 압축은 데이터 세트 자체의 특성, 즉 압축 가능한 형식인지 여부와 압축 가능한 양에 따라 다릅니다. 일반적으로 압축 알고리즘을 사용하여 중복 문자열과 추가 공백을 제거한 다음 압축된 데이터를 저장 장치 내의 압축 청크에 저장합니다. 이 유형의 압축은 데이터의 손실을 일으키지 않습니다.

참고!!
데이터 무결성은 전체 수명 주기 동안 데이터의 정확성, 일관성 및 신뢰성을 나타냅니다. 생성에서 삭제까지 데이터가 변경되지 않고 신뢰할 수 있도록 유지되며 의사 결정 목적으로 신뢰할 수 있습니다.
데이터 무결성은 데이터 입력 중 오류, 소프트웨어 버그, 하드웨어 오류, 악의적인 공격 및 인적 오류를 포함하여 다양한 방식으로 손상될 수 있습니다. 데이터 무결성을 유지하기 위해 액세스 제어, 데이터 유효성 검사, 암호화, 백업 및 재해 복구 계획과 같은 조치를 취합니다.

참고!!
2 phase commit 프로토콜
2 phase commit 프로토콜은 트랜잭션이 분산 시스템의 여러 데이터베이스 또는 노드에서 원자적으로 실행되도록 하는 데 사용되는 분산 알고리즘입니다. 이 프로토콜은 참여하는 모든 노드가 트랜잭션을 커밋하거나 아무 노드도 커밋하지 않도록 합니다.
2 phase commit 프로토콜은 트랜잭션이 원자적으로 커밋되도록 보장합니다. 즉, 모든 노드가 트랜잭션을 함께 커밋하거나 중단합니다. 그러나 프로토콜에는 모든 노드가 프로토콜에 참여할 수 있어야 하므로 차단 가능성 및 가용성 감소와 같은 몇 가지 단점이 있습니다. 또한 프로토콜은 코디네이터 노드의 오류에 취약할 수 있으며 이로 인해 전체 트랜잭션이 중단될 수 있습니다.