[0329] 데이터베이스 - 문제 상황에 따른 해결책

학습 목표

• RDBMS와 NoSQL의 차이와 각각의 장단점을 이해할 수 있다.
• 충분한 가용성이 확보되지 않은 다양한 문제 상황을 이해하고, 상황에 따른 솔루션이 무엇인지 이해할 수 있다.
  • 다음 용어에 대한 간단한 정의를 내릴 수 있다: 인덱싱, 레플리카, 파티셔닝, 캐싱, 배치 작업, 스트림 처리
• 이벤트 기반 아키텍처를 설명할 수 있다.
• RDBMS에서 테이블을 만들 때 스키마(필드) 디자인을 할 수 있다.
• 데이터 파이프라인의 필요성을 이해할 수 있다.
  • OLTP와 OLAP의 차이를 이해할 수 있다.
  • ETL 과정을 설명할 수 있다.
  • MLOps와 DevOps의 차이를 이해할 수 있다.
• 리눅스 명령과 프로그래밍 언어를 이용해 간단한 데이터 파이프라인을 구현할 수 있다.
  • 간단한 수준의 SQL문을 사용할 수 있다.

---

낮은 검색 성능 - 인덱싱

---

• 효율적인 검색을 위한 시도
  • 데이터베이스의 핵심적인 기능은 데이터를 저장하는 것과 요청이 왔을 때 저장되어있는 데이터 중에 요청에 맞는 데이터를 찾아서 제공하는 것
  • 두 번째 경우에서 낮은 검색 성능이 나타날 때, 좀 더 효율적인 방법으로 특정 키의 값을 확인하고 제공하기 위해서 인덱스(색인)을 이용함
  • 인덱스를 사용하지 않는다면 요청받은 데이터를 찾기 위해 전체 데이터베이스를 스캔해야할 수도 있기 때문
• 메타데이터(meta data)
  • 인덱스: 데이터베이스에 저장된 기본데이터(primary data)에서 파생된 부가적인 메타데이터(데이터에 관한 구조화된 데이터)
  • 원하는 데이터의 위치를 찾는데 도움을 주는 이정표가 됨
• 데이터에 영향을 주지 않는 인덱스
  • 데이터베이스에 데이터가 추가되고 삭제될 수 있듯이, 인덱스 역시 추가되고 삭제될 수 있음
  • 인덱스의 편집사항은 데이터베이스의 내용에는 영향을 주지 않으며, 질의(Query) 성능에만 영향을 줌
• 고려사항
  • 별도의 저장공간을 확보하고 데이터에 연계된 인덱스들을 필요에 따라 설정하고 저장해야 하므로 추가적인 작업이 수반됨
  • 데이터 변경에 따라서 인덱스에 대한 수정도 연계되어 이루어져야 하므로 적절하게 인덱스를 활용하지 못하는 경우 오히려 성능저하의 문제가 발생할 수도 있음
  • 자주 사용하는 정도, 분포, 정보의 변경 주기 등 다양한 사항을 고려해 목적에 맞게 인덱스를 설정해야 함

---

많은 사용자 - 레플리카

---

• 안정적인 서비스를 제공하기 위한 시도
  • 많은 사용자가 하나의 데이터베이스에 접근하는 경우, 성능 저하가 발생할 수 있음
  • 데이터베이스의 복사본을 저장하는 각각의 노드인 레플리카(replica, 복제서버)를 활용하여 문제를 해결할 수 있음
  • 레플리카는 원본이 되는 데이터베이스와 같은 데이터를 다른 위치에 존재하는 여러 노드에 유지하는 방식임
  • 데이터의 중복성이 발생하는데, 이로 인해 얻을 수 있는 장점이 존재하며, 그에 따라 해결해야하는 문제점들 역시 존재함
• 레플리카 활용의 장점
  • 시스템 장애시에도 동작할 수 있도록 가용성 확보
    • 일부 노드가 사용불가능 상태여도 해당 데이터는 남은 다른 노드를 통해 여전히 제공할 수 있음
    • 리더가 되는 데이터베이스와 동일한 데이터를 레플리카들이 가지고 있기 때문에, 리더 데이터베이스에 장애 상황이 발생하더라도 레플리카 중 하나를 새로운 리더로 지정하고 사용자의 요청을 새로운 리더로 연결하여 서비스가 중단되는 시간을 최소화 할 수 있음
  • 읽기 쿼리 제공 장비 수를 확장해 읽기 처리량을 늘림
    • 사용자의 요청이 하나의 데이터베이스에 집중 될 경우, 데이터베이스 성능에 영향을 미칠 수 있음
    • 특히, 웹 기반 애플리케이션의 경우 쓰기 요청보다 읽기 요청의 비율이 높다는 특징이 있는데, 모든 읽기 처리 요청이 하나의 데이터베이스에 쏠리게 되면 성능 저하로 이어질 가능성이 높음
    • 데이터베이스 자체의 성능을 높여서 대처할 수 있지만, 이는 일반적으로 높은 비용을 수반함
    • 이러한 경우 레플리카를 읽기 전용 데이터베이스로 활용할 수 있음
    • 리더에서는 읽기와 쓰기를 한번에 처리하면서, 쓰기 처리가 발생할 경우 각 레플리카에도 데이터를 저장해서 동기화를 진행함
    • 레플리카는 최종적으로 리더와 같은 데이터를 가지고 있기 때문에 사용자들이 읽기 요청을 보낼 때 해당 사항을 처리할 수 있음
    • 이렇게 되면 사용자 트래픽이 각 데이터베이스로 분산되기 때문에 성능 향상에 도움이 됨
  • 지연시간 감소
    • 데이터를 저장하고 요청에 따라 제공해야 하는 데이터베이스가 데이터를 요청하는 곳과 지리적으로 멀 경우 응답시간이 늦어질 수 있음
    • 지연시간을 감소시키기 위해 레플리카의 위치를 각 지역에 분산시켜 배치할 수 잇음
    • 각 지역에 분산된 레플리카는 해당 지역에서 가까운 사용자의 요청을 처리하여 지연시간을 감소시킬 수 있음
• 레플리카 활용 시 고려해야할 사항
  • 레플리카를 활용한 데이터베이스 구조를 유지할 때 가장 중요한 것은, 모든 데이터베이스가 정확히 같은 데이터를 가지고 있게 하는 것
  • 동기식 복제(Synchronous)
    • 리더의 데이터 처리와 별개로 레플리카에서의 데이터 처리까지 모두 완료되어야만 프로세스가 진행됨
    • 레플리카와 리더 데이터베이스가 일관성있게 최신 데이터 복사본을 가지고 있는 것을 보장할 수 있음
    • 네트워크 문제 등으로 레플리카가 정상적으로 데이터처리 작업을 완료할 수 없는 경우, 응답을 받지 못한 리더 데이터베이스 역시 프로세스를 진행할 수 없음
    • 리더는 모든 쓰기를 차단하고 동기 레플리카가 회복되기를 기다리기 때문에 시스템 운영이 멈출 수 있는 위험이 있음
  • 비동기식 복제(Asynchronous)
    • 동기식 복제와 달리 리더가 레플리카의 처리 응답을 기다리지 않음
    • 리더는 레플리카에 데이터 처리를 요청한 후 자신의 작업을 완료하면 사용자의 요청에 바로 응답함
    • 연결된 모든 레플리카가 어떠한 이유로 처리를 지속할 수 없더라도 리더는 쓰기 처리를 계속할 수 있다는 장점이 있음
    • 리더 데이터베이스에 문제가 없다면, 레플리카의 상태와 무관하게 사용자에게 서비스를 계속해서 제공할 수 있음
    • 레플리카가 읽기 전용으로 이용되고 있을 경우, 사용자에게 리더와 같은 응답을 주지 못하는 경우가 발생할 수 있음
    • 데이터의 불일치가 발생하기 때문에 불일치 상태가 길어지는 경우 큰 문제가 될 수 있음
    • 리더가 잘못되고 복구할 수 없는 상황 발생 시, 팔로워에게 복제되지 못한 모든 처리가 유실될 수 있으며, 클라이언트에게는 저상 작동을 알린 이후임에도 불구하고 지속성을 보장하지 못하는 문제가 발생할 수 있음
  • 반동기식 복제(semi-sychronous)
    • 동기식 복제와 비동기식 복제의 장단점을 보완하기 위해서, 하나의 레플리카는 동기식 복제를 사용하고, 다른 레플리카들은 비동기식으로 사용하는 방법

---

대용량의 데이터 - 파티셔닝

---

• 대용량 데이터를 처리하기 위해 데이터셋을 쪼개기
  • 데이터베이스에 들어가는 데이터셋이 매우 크거나, 쿼리 처리량이 매우 높은 경우에는 단순히 복제하는 것만으로는 부족할 수 있음
  • 큰 데이터베이스를 파티션(샤딩)이라는 작은 단위로 쪼개서 활용하는 방법이 제시됨
  • 파티션은 그 자체로 작은 데이터베이스가 됨
• 파티셔닝의 목적
  • 주된 이유는 확장성 때문
  • 데이터베이스가 확장되면서 점점 대용량의 데이터베이스가 되고, 그러한 환경에 맞게 프로세스를 처리할 필요성이 생기기 때문
  • 데이터셋을 여러 디스크에 분산하의 요청에 따른 질의 부하를 여러 곳으로 분산하는 것에 그 목적이 있음
  • 많은 정보를 가진 데이터베이스에는 많은 정보에 대한 요청이 발생하고, 이때 각각의 요청을 처리하기 위한 지점이 하나뿐이라면 데이터베이스 성능에 영향을 줄 수 있음
  • 파티셔닝을 통해서 데이터베이스를 작은 범위로 나누고 요청받은 데이터에 해당하는 파티션에만 접근해서 정보를 조회할 수 있다면 성능 저하를 피할 수 잇음
• 쏠림현상(skewed) 방지를 위한 시도
  • 일반적으로 파티셔닝과 레플리카는 함께 사용됨
  • 파티션 내부를 보면 각 파티션의 복사본을 여러 노드에 저장하고 있는 것을 알 수 있으며, 이러한 방식을 사용하는 이유는 요청의 쏠림 현상을 방지하기 위해서임
  • 불균형하게 부하가 높아진 파티션을 핫스팟이라고 부르며, 이러한 문제를 피하기 위해서 파티션을 구성할 때는 데이터의 쿼리 부하를 노드 사이에 고르게 분산시킬 수 있도록 전략적으로 배치해야 함
• 고른 분포를 위한 전략
  • 레코드를 할당할 노드를 무작위로 선택하는 것
    • 기계적으로 무작위 선택을 통해 분산효과를 얻을 수 있지만, 데이터를 읽어내야할 때는 특별한 기준으로 찾을 수 없기 때문에 성능저하를 가져올 수 있음
  • 키 범위를 기준으로 한 파티셔닝을 진행하는 것
    • 데이터에 접근하기 위한 키를 일정한 기준(알파벳, 저장 날짜 등)에 따라 배치해서 파티션을 구성하는 것
    • 특정 파티션에 쏠림 현상이 발생할 수 있음
  • 키의 해시값 기준 파티셔닝
    • 쏠림 현상이 일어날 수 있는 데이터라도 해시함수를 통해 처리를 거쳐 균일하게 분산시킬 수 있음
    • 핫스팟 발생을 막을 수 있지만, 범위 쿼리 효율성이 높은 키 범위 파티셔닝의 장점을 잃어버린다는 단점이 있음

---

동일 데이터의 잦은 조회 - 캐싱

---

• 특정 데이터에 대한 반복된 요청을 효과적으로 처리하기 위한 시도
  • 임시로 복제된 데이터를 저장하는 장소로, 사용자가 더 효율적이고 빠르게 원하는 데이터에 접근할 수 있도록 하기위해 설정됨
  • 원본 데이터베이스가 제공할 수 있는 것보다 짧은 대기 시간을 제공하면서 웹 애플리케이션의 성능을 향상시킬 수 있으며, 데이터베이스의 비용을 절감할 수 있음
• 캐시 사용의 장점
  • 성능 향상
    • 데이터베이스는 기본적으로 속도보다는 데이터의 저장과 안정성에 초점을 맞추게 됨(디스크 기반 데이터 저장소)
    • 캐시의 경우에는 임시로 데이터가 저장되는 장소이기 때문에, 저장의 기능보다는 정보를 제공하는 ㅓ리 속도에 더 집중할 수 있음(인 메모리 캐시_
    • 사용자의 요청이 반복되는 데이ㅓㅌ르 ㄹ빠르게 제공하기 위해서 캐시를 활용하게 되면, 원본 데이터가 존재하는 데이터베이스에 액세스하는 것보다 훨씬 빠른 속도로 데이터를 제공하면서 전반적인 애플리케이션 환경이 개선됨
  • 비용 감소
    • 데이터베이스의 성능을 높이거나 많은 쿼리 요청을 처리하는 것은 모두 비용 상승을 수반하는 작업임
    • 캐시를 사용하게 됨으로써 원본 데이터베이스에 대한 쿼리 수를 줄이고, 데이터베이스 자체를 스케일링할 필요성을 낮추면, 성능 향상과 더불어 비용을 절감하는 효과를 낼 수 있음
• 캐시 타입
  • Cache-aside
    • 일반적으로 웹 애플리케이션에서는 읽기 작업량이 많으므로 애플리케이션을 설계할 때 캐시 보관 패턴을 사용함
    • 애플리케이션은 우선적으로 캐시에서 원하는 데이터를 검색함
    • 데이터가 캐시에 존재하지 않는다면 데이터베이스에 직접 연결하도록 코드를 구성함
    • 데이터베이스에서 직접 데이터를 확보했다면 애플리케이션은 해당 데이터를 캐시에 복사함
  • Read-through/Write-through Cache
    • 데이터베이스와 일렬로 배치되며, 애플리케이션은 뒤에 있는 데이터베이스가 아닌 캐시를 주 데이터 저장소처럼 취급함
    • 데이터의 일관성을 보장하면서, 애플리케이션의 코드를 단순화하고 원본 데이터베이스에 전달되는 요청을 최소화 할 수 있음
    • Read-through를 통해서 애플리케이션이 데이터를 읽으려 할 떄
      • 최초 데이터를 로드할 때만 캐시가 데이터베이스에 접근하며, 이후 동일 데이터는 캐시에서 처리됨
      • Cache-Aside 방식과 달리 애플리케이션이 캐시에 기록하지 않기 때문에 애플리케이션 자체의 부담을 줄일 수 있음
      • 읽기처리가 많은 워크로드에 적합한 캐시 방법
    • Write-through를 통해서 애플리케이션에 쓰기 요청이 발생하 ㄹ때
      • 우선적으로 캐시에 데이터를 추가한 뒤 데이터베이스에도 데이터를 추가하게 됨
      • 이로 인해 항상 최신 상태를 유지하면서 데이터 일관성을 보장 받을 수 있음
  • Write-behind/wirte-back Cache
    • 애플리케이션은 일단 캐시에 데이터를 저장하고, 그 후 캐시가 백그라운드에서 비동기적인 방식으로 데이터베이스에 데이터를 기록함
    • 쓰기처리가 많은 워크로드에 적합한 캐시 방법
    • 애플리케이션은 데이터베이스에 쓰기가 완료되는 것을 기다릴 필요 없이 다음 작업을 진행할 수 있으므로 사용자에게 좀 더 쾌적한 사용환경을 제공할 수 있음

---

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

---

• Data Batch Processing
  • 사전적 의미의 배치는 ‘일괄’, ‘묶음’을 뜻하며, 데이터 배치 작업을 데이터 일괄처리작업이라고 칭하기도 함
  • 유입되는 데이터를 특정량 또는 특정 기간 모아서 한번에 처리한다는 의미
  • 처리해야할 데이터가 늘어날 수록 데이터를 처리하는 컴퓨터도 그만큼 성능을 소모하게 도리 것이고 처리하는 시간도 늘어나게 됨
  • 일괄 작업은 최소한의 인간 상호 작용으로 실행할 수 있으며, 자주 사용되는 프로그램을 위한 것
  • 배치작업은 데이터를 실시간으로 처리하는 것이 아니라 일괄적으로 모아서 한번에 처리하는 작업을 의미함
  • 배치작업을 하게 되면 컴퓨팅 하드웨어에 대한 자본 투자를 최대한 활용할 수 있으며 제한된 처리 능력을 업무 시간 동안 우선 순위가 높은 작업에 할당할 수 있음
• 배치의 특징
  • 대량의 데이터 처리
  • 특정 시간에 프로그램 실행
  • 일괄적으로 처리
• 배치 작업의 단점
  • 예약된 일이 순차적으로 실행되기 때문에 앞선 프로그램의 실행이 다 끝나야지만 뒤에 등록된 데이터가 실행됨
  • 앞단에 실행시간이 많이 필요한 응용 프로그램이 실행될 경우 컴퓨터 응답시간이 오래 걸릴 수 있음
  • CPU가 필요없는 시간대에도 응용 프로그램이 CPU를 점유하고 있을 수 있기 때문에 총 실행 시간도 오래 걸릴 수 있음(성능 저하)
• 배치 작업으로 인한 성능 저하
  • 보통 서버의 성능 저하를 겪게 되면 컴퓨터 자체의 물리적 성능 향상을 위해 수직 확장을 고려하곤 하지만, 대부분의 성능 저하 주요 원인은 DB 관련 비효율에 있음
  • 즉 성능 저하의 핵심은 CPU나 메모리의 부하가 아닌 비효율적인 I/O
  • 대량의 배치작업을 한꺼번에 진행하게 되면 특정 시간대에 I/O가 몰리게 되어 서버에 갑작스러운 부하가 일어나 성능이 저하될 수 있음

---

• DB를 효율적으로 처리하는 방법
  • 일괄 처리를 하게 된다면 어떤 의미로든 그 데이터셋은 절대 완료 되지 않음

	Batch	Stream
데이터 크기	방대한 양의 미사용 데이터	개별적이거나 소수의 기록
데이터 범위	사용 가능한 모든 데이터	최신 이벤트
성능	높은 지연 시간(수시간~수일)	짧은 지연 시간(밀리초~초)
분석	대규모 데이터 세트에 복잡한 분석	간단한 분석, 실시간 응답
사용 예	은행 업무, 정산 시스템, 리포트 및 리서치	실시간 운송 추적, 실시간 미디어 송출, IoT 센서, 결제 처리 시스템, 서버 및 애플리케이션 로그

• 데이터 스트림 처리
  • 데이터가 생성되는 즉시 연속 스트림을 처리하는 것을 의미
  • 스트리밍 데이터를 실시간으로 분석하는 것으로, 스트림 처리는 데이터 크기를 알 수 없고 무한하고 연속적일 때 사용됨
  • 데이터 스트림이 연속적이고 즉각적인 응답이 필요한 경우 스트림 처리가 사용됨
  • 스트림 처리를 통해 데이터가 생성되자마자 분석 시스템에 하나씩 데이터가 공급되며, 이를 통해 거의 실시간으로 필요한 정보를 이용할 수 있음
• 데이터 스트림 특징
  • 시간에 민감함
  • 연속성
  • 다양성
  • 불완전성
  • 휘발성
• 데이터 스트림을 처리하기 위한 요구사항
  • 짧은 대기 시간
  • 확장성
  • 가용성
• 데이터 스트림 처리의 이점
  • 새로운 동적 데이터가 지속적으로 생성되는 시나리오 대부분에서 유용함
• 데이터 스트림 처리의 예
  • 사물 인터넷
  • 실시간 주식 시장 모니터
  • 활동 및 트랜잭션 로그
  • 프로세스 모니터

---

• 이벤트란?
  • 시스템 하드웨어 또는 소프트웨어 상태가 변화한다는 것 또는 중대 사건의 발생을 의미
  • 이벤트 소스는 내부 또는 외부 입력일 수도 있고, 마우스 클릭이나 키보드 입력과 같은 사용자 또는 센서 출력과 같은 외부 소스에서 생성되거나 프로그램 로딩과 같이 시스템에서 비롯될 수 있음
• 이벤트 기반 아키텍처
  • 이벤트 생성자와 이벤트 소비자로 구성되어 있음
  • 이벤트 생성자는 이벤트를 감지하며 메시지로 해당 이벤트를 나타매고, 이벤트 소비자 또는 이벤트 결과를 알지 못함
  • 이벤트가 감지된 후에는 이벤트 처리 플랫폼이 이벤트를 비동기식으로 처리하는 이벤트 채널을 통해 해당 이벤트 생성자에서 이벤트 소비자로 전송됨
  • 이벤트 발생 시 이벤트 소비자는 알림을 받아야 하며, 이벤트를 처리할 수도 있고 이벤트의 영향을 받기만 할 수도 있음
  • 이벤트 기반 아키텍처는 조직이 실시간으로 변화에 대응하여 의사 결정을 내릴 수 있는 유연한 시스템을 확보할 수 있도록 지원함
  • 실시간 상황 인식은 시스템의 현재 상태를 반영하느 ㄴ데이터를 모두 십분 활용하면서 수동 또는 자동으로 비즈니스 결정을 내릴 수 있음을 의미함