#커머셜 | Explore Tumblr Posts and Blogs

pignose-barn · 7 years

Text

데이터(Data)와 분석(Analysis)에는 어떤 일이 벌어지고 있느뇨?

오랜만에 블로그 포스팅을 하는 것 같습니다. 오래전에 쓴 영양가 없는 글들도 많이 정리해서 이번에 새로운 컨텐츠 들을 많이 채워보겠습니다.

이번 블로그 주제는 데이터(Data)와 분석(Analysis)인데요 많은 분들이 관심가지고 있고 또 앞으로도 한동안은 이 스코프에 있는 산업군은 근심걱정이 없기도 해서 많은 주니어분들과 타 직종에 계신분들이 자주 관심가지고 보실 것 같습니다.

들어가기 앞서

이 글에서는 빅데이터에 대해서 거론하지 않습니다.

이 글에서는 데이터 사이언스 기술에 대해서 거론하지 않습니다.

이 글의 작성자는 전문가가 아닙니다.

들어가며

서비스 개발에 종사하시는 많은 부류의 개발자 분들은 대부분 데이터베이스(Database)라는 것을 들어보셨을 겁니다. 보통 서비스에 있는 동적 데이터와 사용자의 상태를 세션(Session)으로 관리하되 이를 스토어(Store)로 연결하고자 데이터베이스를 서비스와 연결하여 사용하는 것이 일반적이지요.

여러분이 많이 들어보신 MySQL, MSSQL, Oracle, DB2, CosmosDB, PostgreSQL, MariaDB 등이 이러한 관계형 데이터베이스(RDBMS)가 되겠습니다.

<그림 1.1 여러분이 사랑해주시는 우리의 MySQL 찡...>

참고로 여기서 MySQL을 “마이에스큐엘” 이라고 발음하시는 분들이 많으신데요 현업에서는 “마이시퀄"이라고 부르는 경우가 많습니다. PostgreSQL 또한 “포스트그레스큐엘”이 아닌 “포스트그레스퀄"이라고 부르는 경우가 많습니다.

보통 우리는 서비스단에 이러한 RDBMS를 연결할 때, RDBMS가 있는 부분을 지속 레이어 혹은 퍼시스턴스 레이어(Persistence Layer)라 부릅니다.

<그림 1.2 서비스에서 구분되는 계층들>

물론 서비스 단에서 DB를 사용할 때는 데이터 무결성(데이터과 일관적이고 정확함을 보증)해야 하고 또 만약 데이터 처리에 문제가 생겨도 이를 대처할 수 있어야합니다. (*폴트톨러런스) 위의 것들을 지원하기 위한 목적을 가진 데이터베이스를 일반적으로 우리는 OLTP (Online transaction processing) 라고 부릅니다.

위 설명이 다소 복잡할 수 있어서 아래에서는 사례를 하나 들어드려 보겠습니다. 여러분이 만약 여행사 API를 이용하여 사용자가 돈을 결제하면 여행사 등록을 하는 시스템을 만들어보겠습니다. 서비스 프로세스에서 처리할 것은 아래와 같습니다.

사용자가 특정 여행사에 신청을 넣고 크레딧을 사용

서버에서 여행사 API에 접근하여 정원 초과여부, 사용자 등록정보를 바탕으로 유효성 체크등을 거쳐 올바를 경우 다음 단계 진행

사용자의 크레딧 DB에 요금이 있는지 확인

사용자의 크레딧 DB에서 크레딧을 차감 (DB 작업)

여행사 API에 접근하여 예약 처리

예약이 성공적으로 성사 됨을 사용자에게 알림

위 시나리오대로 구현 하면 일반적인 경우에는 서버의 장애는 발견되지 않는다고 생각할 수 있을 텐데 여기에는 심각한 문제들이 여럿 있습니다. 아래는 여기서 발생할 수 있는 장애 시나리오를 간단하게 나열해봤습니다.

여행사 API에서 에러를 보내는 경우 (a. 여행사 서버 문제, b. 유효성 검증 이후 잠깐의 처리시간동안 다른 사용자가 예약을 진행한 경우 등)

사용자가 동시적인 예약처리로 인해 크레딧 체크 이후 크레딧이 줄었을 경우

서버의 장애로 인해 예약처리를 수행하지 못했을 경우 (서버의 재배포, 서버의 다운 등)

세상은 항상 논리적이고 완벽하지 않기 때문에 우리는 이런 의도치 않은 사항을 예방해야 합니다. 다행스럽게도 우리에게는 트랜잭션(Transaction)이 있기에 위의 문제를 아름답게 해결 할 수 있습니다.

<그림 1.3 트랜잭션의 방식에 대한 그림>

트랜잭션의 원리는 비교적 간단합니다.

트랜잭션 컨텍스트를 정의하고 (Begin transaction 혹은 savepoint) 그 컨텍스트 안에 있는 처리들을 마지막에 반영(Commit)하거나 취소(Rollback) 하실 수 있습니다. Auto Commit이 설정되있지 않으면 서버에서 피치 못하게 처리 응답을 못할 경우 데드맨스위치와 유사하게 자동으로 취소(Rollback)합니다.

우리는 아까의 시나리오를 트랜잭션을 이용하여 아래처럼 처리 할 수 있습니다.

사용자가 특정 여행사에 신청을 넣고 크레딧을 사용

서버에서 여행사 API에 접근하여 정원 초과여부, 사용자 등록정보를 바탕으로 유효성 체크등을 거쳐 올바를 경우 다음 단계 진행

트랜잭션 시작

사용자의 크레딧 DB에 요금이 있는지 확인

사용자의 크레딧 DB에서 크레딧을 차감 (DB 작업)

여행사 API에 접근하여 예약 처리

만약 이 과정중 어떤 에러라도 있다면 트랜잭션 취소(Rollback)

트랜잭션 종료 및 반영(Commit)

예약이 성공적으로 성사 됨을 사용자에게 알림

물론 위의 시나리오에서도 사용자가 동시적으로 크레딧을 결제할 경우는 막을 수 없습니다.

이를테면 동시간대에 2개 이상의 트랜잭션이 동시에 작동하여, 5만원의 크레딧 중 한곳은 5만원을 사용하고 또 한곳은 3만원을 사용하여 둘중 하나는 취소되어야 함에도 불구하고 두 처리 모두 조회단계에서 5만원이 조회되고 처리 단계는 그 이후 수행되기에 총 8만원이 소진되는 현상 (이때도 둘 중 어떤 트랜잭션이 먼저 실행되었냐에 따라 잔금이 2만원이 남아버리기도 하는 엄청난 사태)

이를 완벽하게 처리하고자 한다면 비관적 동시성 제어 처리를 위해 읽기 락을 걸거나 다중 체크를 통해 결제를 보장해야 합니다. 일단 이 설명은 모두와 나를 위해 생략합니다!

우리는 한때 RDBMS와 트랜잭션만을 이용해서도 서비스 제공하기에는 큰 지장이 없었습니다. (물론 확장성과 가용성은 여기서 빼도록 합시다!)

여기까지 읽으셨다면 아래 문서도 같이 살펴보세요

관계 - 데이터베이스 (위키피디아)

DBMS는 어떻게 트랜잭션을 관리할까? (Naver D2)

OLTP와 OLAP (devkingsejong's dev life)

클라우드 환경에서 새로운 ACID, BASE 그리고 CAP (미물의 개발 세상)

커넥션 풀 (Connection Pool)

커넥션 풀 (Connection Pool - DBCP) 없이는 당장에는 서비스 테스트에 큰 문제가 없겠지만 서비스를 런칭하고 유저가 다수 붙으면 차차 문제가 발생하기 시작합니다.

데이터베이스를 모니터링 해보면 Current 커넥션은 요동치기 시작하며 데이터베이스는 불필요한 CPU Latency를 가지게 됩니다. 여러분의 서비스는 홈페이지 처음 입장 시 DB에서 사용자 세션 정보를 가지고오고 (이를테면 메모리 스토리지에서), 추가적으로 메인 페이지의 최신뉴스를 DB에서 가져온다고 치자면 여러분은 DB에 2개의 쿼리 요청(트랜잭션)을 시도하게 됩니다.

유저의 세션 정보 조회 쿼리

최신 뉴스를 가져오는 쿼리

보통 유저의 세션 정보를 가져오는 처리와 최신 뉴스를 가져오는 처리는 기능상으로 분리되기 때문에 서로 다른 DB 커넥션이 발생하게 되는데 이를 그림으로 표현하면 아래와 같습니다.

<그림 2.1 유저 별 트랜잭션 별 쿼리 생성>

문제는 각 요청 별로 DB에 커넥션을 새로 얻어와서 (그림상의 빨간부분) 쿼리를 진행하는데 커넥션을 얻어오는 과정이 오래걸리기 때문에 사용자는 그동안 대기하게 되며 또 이러한 처리는 DB 서버에 있어서도 어느정도 CPU 연산이 필요하기에 전체적으로 비효율적으로 작업이 돌아가게 됩니다.

<그림 2.2 커넥션 풀의 관리>

위의 그림처럼 커넥션 풀을 이용할 경우 서버가 초기에 커넥션을 커넥션 풀에 설정된 용량 (Max connection)만큼 연결해놓고 사용자가 실제로 트랜잭션을 진행 할 때는 이렇게 미리 연결된 커넥션을 잠시 빌려 사용하고 돌려주는(Release) 하는 방식으로 돌아가기 때문에 실제로 DB에는 커넥션이 안정적으로 유지되고 또 CPU 부하가 줄어들게 됩니다.

커넥션 풀에 대한 정보를 모아봤습니다!

DB Connection Pool에 대한 이야기 (안녕 프로그래밍)

Commons DBCP 이해하기 (Naver D2)

확장성 그리고 고 가용성

여러분이 신입에서 조금씩 걸어 올라오다 보면 서비스를 준비하는 단계에서 무결성(일관성과 정확성, 원자성 등) 다음으로 확장성과 가용성이 굉장히 중요한 요소인 것을 점차 느끼게 되는데 둘에 대한 간략한 설명은 아래와 같습니다.

확장성(Scalability): 사용자가 많아지고(커넥션, 트랜잭션 증가) 처리해야 할 데이터의 양이 많아 지면서(인덱스 증가, 카디널리티 증가, 스캔용량 증가) 물리적인 서버의 성능을 향상 스킬 수 있는 능력이나 방법.

가용성(Availability): 주어진 환경에서 어떠한 문제(서비스의 장애) 없이 유지시킬 수 있는가에 대한 정도. (i.e 가동률)

만약 여러분이 서비스를 잘 만들고 라이브 서비스로 오픈 했는데 하루만에 DB 서버가 뻗고 (일반적인 장애 혹은 스팩 자체의 문제) 이를 복구하는데도 수시간이 걸린다면 가용성이 심각한 문제가 있는 것이게 됩니다. 또한 서비스의 성능이 느려 이를 개선하는데에 있어 시간적 비용이나 공간적 비용(서버공간 추가, 서버 이전), 인적비용(마이그레이션 담당자 투입, DBA 투입, 서버엔지니어 투입)이 발생한다면 확장성이 낮은 것이지요.

DBMS 종류마다 이러한 가용성, 확장성을 SW 레벨에서 지원하기 위한 기능도 있으며 이런 차이 때문에 많은 데이터 관련 엔지니어나 종사자들이 많은 공부를 하고 있습니다.

확장성을 깊게 들여다보며

<그림 3.1 확장성에 대한 간단한 그림 (scale-out 측면)>

아까는 확장성에 대해 간단하게만 서술 했는데 이번에는 조금 더 깊이있게 얘기해 보겠습니다. 데이터베이스 서버가 느려 이를 확장하는 경우 간단하게 두개로 나뉘게 됩니다.

SW 레벨에서의 확장 (논리적인 확장)

HW 레벨에서의 확장 (물리적인 확장)

당연하게도 HW쪽이 비용과 시간은 더 많이 소모되겠죠.

SW 레벨에서의 확장을 하는 케이스 사실 확장이라 칭하기보다 최적화가 더 맞는 말일 듯 합니다. 보통 로그테이블이 많이 쌓여서 로우가 추가될 때마다 인덱싱도 느리고 또 서치를 해도 불필요하게 스캔 코스트가 많이 들기 때문에 테이블 파티셔닝을 하게 됩니다.

HW 레벨에서의 확장은 경우의 수가 많습니다만 크게 아래와 같이 또 한번 분류 할 수 있습니다.

수직 확장의 측면(Scale-up)

수평 확장의 측면(Scale-out)

<그림 3.2 수직확장(scale-up)과 수평확장(scale-out)에 대한 설명>

수직 확장은 쉽게 얘기하여 서버 자체의 성능을 늘리거나 처리 방식을 개선하여 알고리즘을 효율적으로 돌아가게 하는 등으로 개선이 필요한 인스턴스 자체를 조정하는 것이라 보면 됩니다.

수평 확장은 그와 다르게 서버의 수를 늘려 분산을 하거나 스캔 대상의 파일을 쪼개어 분산하거나 혹은 연산 프로세싱 만을 분산하는 등 하나의 커다란 문제를 쪼개어 해결하는 것으로 초점이 맞춰져 있습니다.

수직 확장의 경우에는 보통 서버의 스팩을 올리거나, 랜 공사를 해서 데이터 서버가 사용하는 랜 성능을 키운다거나 디스크를 증설하여 저장공간을 키우는 형태로 보통 서버가 정지됩니다.

수평 확장은 클러스터를 구성하여 서버 노드를 늘리거나, 디스크 노드를 늘리거나 마이크로 서버를 띄워 프로세싱을 맡기는 등의 처리를 통하여 성능을 늘리며 보통 이런 처리가 무정지로 이루어지거나 Write Lock만을 통하여 진행합니다.

확장성의 경우 이렇다 저렇다 얘기가 많지만 주관적으로 수평확장이 수직확장에 비해 안전하고 요금 측면에서 효율적이며 각종 위험에 대하여 안전합니다. (Fail-over, Multi region)

수평 확장을 통하여 데이터를 분산 할 경우 샤딩(Sharding 혹은 Horizontal Partitioning)을 하게 되는데 이를 통해 데이터의 저장소를 분배하고 실제로 데이터를 수집하고 집계 할 때, 리더 역할을 하는 컴퓨터에 조회 요청을 보내고 리더 컴퓨터에서 분산된(샤딩된) 데이터를 각각의 목적 노드에서 추출하고 집계하여 반환하게 됩니다. 물론 이런 리더-컴퓨터 구성처럼 미들티어(Middle-tier) 형태로 작동하는 것도 있지만 Hibernate Shards와 같이 어플리케이션 레벨에서 동작하는 경우도 있으며 이마저도 아닌 데이터베이스 자체에서 지원하는 케이스도 있습니다.

<그림 3.3 파티셔닝에 대한 간단한 설명 그림>

가용성을 깊게 살펴보며

이번에는 아까 말씀드린 가용성을 깊게 살펴봅시다.

가용성은 다시말해 “서버가 얼마나 안정적으로 오랫동안 운영되고 있나"를 알려주는 성질입니다. 서버가 정지되는 시간(다운타임)을 최소화 하는 것이 궁극적으로 고 가용성을 제공하는 방법입니다.

수직 확장의 경우에는 이런 처리가 다소 난해한 요소로 자리 잡고 있습니다. 서버 자체가 문제가 발생 할 때 이를 대체 해 줄 수 있는 서버가 존재하지 않으면 마땅한 방법이 없기 때문인데 이 때문에 별도의 모니터링이나 대리자(Proxy)를 두게 됩니다.

수직 확장의 경우에도 데이터 디스크와 데이터서버를 분리하고 데이터서버 앞에 로드밸런서를 붙여 상태검사(Health Check)이후 문제가 발생하면 후차 데이터베이스 (Secondary or Slave or Stand by)를 활성화(Idle, Promote to master)하여 자동으로 정상화 합니다. 이렇다 하더라도 데이터센터가 지역적으로 한곳에 있다면 천재지변이 발생할 경우 서비스는 다운됩니다.

후후.. 이제 조금만 더 읽으면 끝납니다! 복습 차원에서 아래 관령 링크를 살펴보세요!

분산 데이터베이스와 성능 (DBGuide)

NHN의 안과 밖: Sharding Platform (Naver D2)

DFS: Not a Distributed Database

어떤 분산 파일 시스템을 사용해야 하는가? (Naver D2)

클러스터와 리플리케이션의 차이가 뭔가요?

<그림 4.1 slave 관점에서의 failover 예시>

Fail-over 전략에 대해서도 워낙 다양하기에 여기서 모든 것을 설명 드릴 수는 없고, 기회가 되면 추가 포스팅을 하고 링크를 이곳에 연결해드리겠습니다.

조금 특이한 fail-over 전략으로는 데드맨 스위치(Deadman switch)가 있습니다. 전략이라기 보다는 일반적인 fail-over가 이에 근거하여 돌아간다라고 설명드릴 수 있을 것 같은데요 DB 앞에 Load Balencer가 붙어 이상점을 감지하여 레플리카를 대체하건 M-M 구성에서 Master의 이상점을 감지하여 승격과정을 거치건 둘 이상의 노드간에 약속된 패킷과 발송 시간을 정하여 그것이 도착하지 않으면 이상으로 감지하여 데드맨 스위치가 켜지는 방식입니다.

퍼포먼스

서비스의 안정성이 가장 중요하지만 두번째로 중요한 것은 성능입니다. 사용자는 점점 즉각적이고 신속한 응답을 바라고 있고 우리는 더 많은 양의 정보를 바탕으로 질 높은 정보 얻어 다른 업체와 경쟁해야 합니다.

퍼포먼스(Performance)를 향상시키는 전략도 여러가지가 있습니다.

일반적으로는 Explain과 slow query 로그 분석을 통해 쿼리 플랜을 최적화 하는 것이 있으며 이는 많은 비용이 들지도 않습니다. 물론 이것도 방법론이 많습니다. (커버링 인덱스를 사용하거나 컬럼 자체의 인덱스를 관리하는 관점, recency score를 두거나 등)

두번째는 튜닝(Tuning)이 있습니다. 너무 당연하겠지만 제일 효율적인 성능을 위해서는 서비스에 특성이 맞게 DB가 세팅되고 돌아가야 합니다. 서비스에 맞게 스토리지 엔진 타입을 바꾸거나 인덱스를 새롭게 설정하거나 인덱스 알고리즘을 바꾸거나, 압축 방식을 바꾸거나 버퍼 캐시를 수정하는 등의 방법이 있습니다.

세번째는 서비스 분산 아키텍처를 설계하실 수도 있습니다. 여기서 부터는 비용이 눈에띄게 발생하게 됩니다. 서비스의 특성에 따라 정형화된 데이터를 하나의 데이터소스에서 관리하고 싶다면 DW(Data warehouse)를, 비정형화 정형화 관계없이 여러 방식으로 데이터 플로우를 구축해야 한다면 하둡 레이어를, 비정형화 데이터를 관계처리 없이 사용하고자 한다면 MongoDB를, 수많은 데이터를 K-V(Key-Value) 형태로 확장성있게 분산기반 위에서 가져오고 싶다면 카산드라를 고려하실 수도 있습니다. 이러한 선택의 경우에는 각 요구사항에 여러 제품군이 있으며 각각의 대조군을 각 플랜에 맞게 테스트 하신 후 사용하시는 것을 권장합니다.

네번째는 서비스에 맞게끔 추가 서비스를 붙여 데이터 처리 플로우를 개선하는 방법이 있습니다. 여기서 부터는 하나의 데이터베이스 서비스가 아닌 다양한 서비스를 연구하고 조합해야 합니다. 예를들어 성능이 피크타임에 치솟고(보통 스파이크 친다고 합니다.) 데이터 삽입이 많이 발생하지만 관계형 쿼리를 많이 사용하지 않는 서비스에서는 (채팅 서비스: 챗봇, 메시지등의 대화형 서비스)에서는 nosql이나 앞단에 queue를 붙인 서비스를 고려하실 수 있습니다. 읽기 빈번하고 수정이 간간히 발생한다면 Redis나 Memcached 캐시 레이어를 앞단에 붙이는 구성을 고려 해 보실 수도 있습니다. 서비스 작업에 즉시성이 요구되지 않는다면 MapReduce를 통한 배치 방식을 고려하실 수도 있습니다.

NoSQL, DW, RealtimeDB, Serverless QueryEngine, Graph Database?!!!!?!

* 경고

모든 자료가 그렇듯이 모든 데이터베이스 엔진 혹은 쿼리 엔진의 장단점을 딥 다이브하여 검증하지 못하기 때문에 이 포스트를 통해 “우리 서비스는 ~~에 맞겠다" 라는 평가자료로 쓰일 수 없습니다. HDD를 주의 해주세요.

필자도 이런 부분에 전문가가 아니고 모든 레이어를 다 사용할 정도로 프로젝트의 규모가 거대하지도 않기 때문에 사실상 프로덕션에 적용해보지 않고 내리는 막연한 평가에 불가합니다.

1. NoSQL (Not only SQL)

전통적인 RDBMS 서비스를 이용하면서 생긴 불편사항들 (복잡한 관계 구조로 인해 생긴 제약들 - 분산, 열 용량 제약, 테이블 용량제약, 확장제약, 스키마로 인한 데이터 형식제약 등)을 벗어나고자 관계에 얼메여 있지 않은, 그리고 SQL외에 다른 표현식을 지원하는 새로운 데이터베이스가 나오게 되었는데 이를 NoSQL (Not only SQL)이라 부릅니다.

NoSQL 데이터베이스는 여러 종류가 있는데 일반적으로 RDBMS 처럼 기본 구조는 같은데 세부적으로 각각의 기능이 차이가 나는 것이 아니라 정말 핵심 기술부터 그 기능이 다른 종류들이 많습니다.

일반적으로 알려진 데이터베이스로는 MongoDB, Cassandra, HBase, Redis 등이 있으며 클라우드 환경에서는 AWS DynamoDB, Google Cloud BigTable 등이 있고 IBM도 DB2에서 NoSQL을 부분적으로 지원한다고 하는데 제가 사용안해봐서 잘 모르겠습니다.

NoSQL은 ACID를 지원하기 어렵습니다. 따라서 이를 완전히 지원해야하는 서비스에 적용하기 어렵습니다. CAP 이론으로 볼 때 보통 확정성(Scalability)을 위해 일관성(Consistency)을 보장하지 않습니다.

요새의 NoSQL에서는 GraphQL 지원을 하나 둘 하기 시작하여 이를 사용하기를 고려하는 업체에서는 테스트를 진행해보는 것이 좋을 것 같습니다.

각각의 NoSQL별 차이점이 존재하는데 간략히 작성하면 아래와 같습니다.

MongoDB

라이센스: GNU AGPL v3.0 (Free, and Commercial), Open source

업체: MongoDB Inc

리플리케이션: 지원 (M-S)

샤딩: 지원 (해시기반)

주관적 내용: 몽고 디비는 AGPL 라이센스를 가지고 있는데 (물론 커머셜 라이센스도 있습니다.) AGPL 라이센스는 상업적으로 사용이 가능하지만.. 모든 소스코드를 공개해야 하는 의무가 있습니다. (GPL의 경우 서버 통신을 하는 경우 회피 할 수 있는데, AGPL은 얄짤없이 공개해야 합니다.) 이는 사업에 있어 많이 고민해야 할 항목입니다. 그 밖에 기술적으로는 몽고 디비 파일이 깨지는 이슈라던가 복잡한 조인 구현 코드가 거의 살인급 코드라 그런 부분만 감당이 가능하면 사용하는 데 큰 지장은 없다고 봅니다. (겁나 겁주고 사용해도 좋다로 끝내는 훈훈함)

Cassandra

라이센스: Apache License 2.0 (Free), Open source

업체: Apache Software Foundation

리플리케이션: 지원 (replication_factor)

샤딩: 지원 (해시기반)

주관적 내용: 카산드라는 분산을 지정하는 옵션이 비교적 간단하고 이를 설정해 놓기만 해도 고가용성 분산 서비스로 동작되어 상당히 편리하긴 하지만 트랜잭션도 미지원, Secondary Index는 Range쿼리를 미지원 추가 Index 미지원 등등의 Trade Off 해야할 사항이 있으니 도입 시 충분히 검토해야 합니다.

HBase

라이센스: Apache License 2.0 (Free), Open source

업체: Apache Software Foundation

리플리케이션: 지원

샤딩: 지원

주관적 내용: 하둡 스택을 사용하는 업체라면 안쓸 이유가 더 없을 정도로 워낙 범용적으로 사용 되는 엔진입니다. HBase를 사용하는 이유야 뭐 하둡 분산파일시스템(HDFS) 위에 존재하는 거대한 데이터에서 빠르게 원하는 데이터를 뽑아낼 때 이기 때문에 특징이 뚜렷하다고 볼 수 있습니다. 당연하겠지만 HBase를 사용하기 위해서는 기본적인 하둡스택의 이해는 필요하기 때문에 진입장벽은 상대적으로 높습니다. 신기한 것은 HBase에서는 TTL을 지원하기 때문에 데이터의 만료시간을 관리할 수 있습니다. 마지막으로 HBase는 secondary index를 지원하지 않습니다. 따라서 일반적으로 RDBMS에서 사용하는 복잡한 관계 쿼리를 구현하실 수 없습니다.

Redis

라이센스: BSD 3-Clause (Free and Commercial), Open source

업체: Salvatore Sanfilippo

리플리케이션: 지원 (M-S)

샤딩: 미지원 (어플리케이션 레벨에서 Hash를 통해 지원해야 함)

주관적 내용: Redis는 인메모리 캐시 DB이기 때문에 역할군이 뚜렷합니다. 우선 안타까운 점은 Redis는 싱글 쓰레드 기반으로 설계되어 있습니다. 따라서 Redis 명령 중 일부는 블러킹을 걸도록 동작하기 때문에 프로덕션 레벨에서 운영할 때 치명적일 수 있습니다. Redis도 클러스터를 통한 분산과 센티넬을 통한 Fail-over를 제공하고 있으며 K-V, Hash, List, Set 등의 자료구조를 가지고 있습니다. RDB랑 AOF라는 연동 방식을 가지고 있는데 둘 모두 많은 수의 데이터를 관리하고 있다면 레디스 재시작에 많은 시간이 소요 될 수 있습니다. (저장의 경우 childProcess를 fork하여 진행합니다. // AOF는 rewrite의 경우에만 이렇게 동작합니다.) 같은 캐시 DB 레벨에 있는 Memcached랑 비교해보면 대부분의 응답속도와 성능의 경우 크게 차이는 없습니다. Redis는 replication에 에러에 대해서 처리 에러를 핸들링 할 수 있으며 동시에 여러 리플리케이션 구현이 가능합니다. 또한 아까 말씀드렸듯 Redis는 Memcached와 비교하였을 때 많은 데이터 타입을 제공하고 있는 장점을 가지고 있습니다. 다만 Flush 호출시 Memcached 동작방식과 전혀 다르기 때문에 블럭킹이 걸려 때문에 많은 양의 데이터를 Flush 할 경우 서비스 자체 동작에 문제가 발생할 수 있습니다. 그 밖에도 Redis는 Memcached에 비해 기존 저장된 데이터 유지를 위한 기능이 많습니다.

Memcached

라이센스: BSD 3-Clause (Free), Open source

업체: Danga_Interactive

리플리케이션: 지원 (repcached)

샤딩: 미지원 (어플리케이션 레벨에서 Hash를 통해 지원해야 함)

주관적 내용: Memcached는 Redis와 마찬가지로 인메모리 캐시 DB 영역에서 존재하고 있습니다. Redis와는 다르게 메모리 본연의 목적에 맞는 간단한 K-V 형태입니다. Redis와 비교 할 경우 크게 Flush all의 동작방식이 다르며 Memcached에서 훨씬 빠르게 동작합니다. (Memcached에서는 실제로 데이터 Flush를 일으키지 않고 timestamp를 기록하고 있다가 나중에 GET 되었을 때 이를 비교하여 삭제합니다.) 따라서 이러한 차이점이 오히려 동작처리에 있어 의도치 않을 실행을 하는 경우도 있습니다. Memcached에서는 flush all에 expired time을 옵션으로 줄 수 있는데 사전에 flush all로 삭제했다 하더라도 이후 flush all [exptime] 옵션을 통해 아직까지 삭제되지 않은 데이터를 재생 시킬 수 있습니다. (물론 exptime에 의해 언젠가는 삭제됩니다.)

DynamoDB

라이센스: 유료 라이센스 (요금보기)

업체: Amazon Web Service (AWS)

리플리케이션: 지원 (Server-less 구성, 자체 내결함성 지원)

샤딩: 지원 (Server-less 구성, 자체 분산)

주관적 내용: DynamoDB는 AWS에서 제공하는 클라우드 환경 베이스의 NoSQL DB 입니다. 여기서 큰 특징은 DynamoDB는 Server-less 환경이기 때문에 용량, 물리적 스팩 제한이 없으며 용량 크기, 사용자가 지정한 처리량(Through-put)에 맞게 알아서 확장되고 클러스터로 관리됩니다. 따라서 가용성, 확장성에 있어서 사용자로 하여금 귀찮은 ��업이 많이 생략되며 Server-less이기 때문에 초기에 많은 비용이 나갈 우려가 사라집니다. 또한 Secondary index 지원을 Global, Local로 각각 지원하고 있습니다. 다만 관리형 서비스라 그런지 갑자기 많은 처리량이 발생할 때 DynamoDB에서 즉시 처리량을 늘릴 수 없는 문제, 그리고 이렇게 높아진 처리량을 다시 낮추는 경우에도 마찬가지로 제약이 있습니다. 따라서 이런 문제를 해결할려면 Warming up 작업을 해야하고 이로 인해 불필요한 비용이 발생할 수 있습니다. 마지막으로 놀라운 점이 하나 있는데 DynamoDB에서는 트랜잭션을 지원하기 위한 Java 코드가 올라와 있습니다.

Cloud Datastore

라이센스: 유료 라이센스 (요금보기)

업체: Google Cloud Platform (GCP)

리플리케이션: 지원 (Server-less 구성, 자체 내결함성 지원)

샤딩: 지원 (Server-less 구성, 자체 분산)

주관적 내용: Google Cloud Datastore는 AWS DynamoDB보다 약 4년정도 일찍 나온 서비스입니다. 가장 큰 차이로는 당연하게도 요금청구 방식이 다릅니다. (AWS DynamoDB는 Throughput 단위 청구, Google Cloud Datastore는 요청당 과금) 완전 정량적 과금이라 초기 비용이 적게 드는 합리적인 구성이지만 DynamoDB와 비교 할 때 요청이 많아질 수록 Google Cloud Datastore 요금이 더 비쌉니다. (읍읍 당신 누구야!?) 다만 secondary index라던지 Query 지원(GQL)이라던지 탈 NoSQL 요소들이 다분해서 이를 알고 사용하면 정말 유용하지만 신은 완벽을 내리지 않았다는 말이 증명되듯 이런 좋은 기능들에 대한 자료가 한없이 부족한 상태입니다.

Cloud Firestore

라이센스: 유료 라이센스 (요금보기)

업체: Google Cloud Platform (GCP) Firebase

리플리케이션: 지원 (Server-less 구성, 자체 내결함성 지원)

샤딩: 지원 (Server-less 구성, 자체 분산)

주관적 내용: 최근에 새롭게 출시된 (베타로) 데이터베이스로 필자는 Google Cloud Datastore와 대체 어떤 차이가 있는지 많이 혼동 되었습니다. 엄밀하게 Google Cloud Firestore의 경우에는 Firebase의 불편함 점 (Query의 불편함, 데이터 계층적 문제 등)을 보완하기 위한 부분이 있으며 Firebase의 목적 (Web, App의 지원)을 상속받기 때문에 Google Cloud Datastore 차이가 있습니다. (더군다나 Cloud Firestore는 Realtime을 지원합니다!) 따라서 Firebase Realtime Database와 비교하는 것이 더 바람직합니다. Cloud Firestore는 Firebase 및 Cloud Function 과 같은 GCP 제품을 호환할 수 있게 만들어 졌습니다.

2. DW (Data Warehouse)

예전에는 컴퓨터 하드웨어의 컴퓨팅 파워도 약했고 그렇기 때문에 수많은 데이터를 빠르게 분석 할 수 있는 환경도 여건도 없었습니다. 오늘 날에서는 컴퓨팅 파워도 높아졌고 또한 컴퓨팅 유닛도 굉장히 저렴해졌으며 가상화 기술과 분산 기술도 나날히 높아졌기 때문에 분산 환경에서 데이터를 실시간 분석하는 것이 가능해졌습니다. DW는 보통 OLAP을 위해 사용됩니다.

3. Realtime DB

Realtime DB는 실시간성 특징을 데이터베이스에 녹여 얻어낸 결과물이라 볼 수 있습니다. 일반적인 특징으로는 데이터베이스에서 수정이 발생하면 이를 클라이언트에 푸시하여 동기화 하는 기능이 들어가 있습니다. 대게의 Realtime DB는 NoSQL 기반이기 때문에 ACID를 요구하는 서비스에서 적용하기는 어렵습니다. 보통 실시간성이 요구되는 게임(진짜로 정말로 실시간 DB로 게임을 만드는 사례들이 있습니다.), 메시지 플랫폼(채팅, 챗봇, CS 등)에서 사용됩니다.

대표적인 Realtime DB 종류

Firebase Realtime DB

Cloud Firestore

RethinkDB

Druid (검토가 필요함)

4. Serverless query engine

Serverless라는 얘기는 서버가 진짜로 없는게 아니라 사용자 (엔지니어)에 있어서 서버가 가려져 있고 또 그것을 알 필요가 없도록 관리되고 있는 완전 관리형 서비스 입니다. 보통 이런 Serverless DB는 Cloud 환경에서 제공되고 있으며 해당 환경에 파일시스템(FS)에 쿼리를 요청하면 거기에 최적화된 코어 유닛의 서버를 런치하여 연산을 분산하기 때문에 상당히 빠른 쿼리 조회 시간을 제공합니다. 다만 코어 유닛의 조작이 불가능 하기 때문에 Scale 조정을 통해 성능을 개선 할 수 없습니다.

대표적인 Serverless query engine의 종류

AWS Athena

AWS Spectrum (*반 Serverless라고 해야 할듯 합니다.)

AWS DynamoDB

Google BigQuery

Google Cloud Datastore

Firebase Realtime Database

5. Query engine

데이터베이스라고 불리우긴 어려우나 분명 쿼리를 통해 집계, 조건 등을 이용하여 결과 데이터를 산출하는 엔진을 칭합니다. 보통 따라붙는 수식어가 “Interactive Query”이며 공용 분산 파일시스템에서 데이터 레이크(Data lake) 역할을 하고 그를 조회하여 결과데이터를 뽑는 엔진을 Query engine이라 부릅니다.

대표적인 Query engine 종류

앞서 거론한 모든 Serverless query engine

Apache Impala

Apache Hive

Apache Pig

Apache Drill

IBM BigSQL

Apache Tajo

Facebook Presto

6.Graph Database

최근에 자주보이는 데이터베이스입니다. 필자는 새롭게 나오는 논문을 살펴보는 스타일은 아닌지라 이것이 어디에서 따와서 점차 출시되고 있는지 잘 모르겠습니다. DAG(Directed Acyclic Graph) 기반의 그래프 데이터베이스 형태로 출시되고 있습니다.

대표적인 Graph Database의 종류

SQL Server 2017

Teradata Aster

SAP HANA

Neo4j

DynamoDB Titan (검증 후 재 업데이트 예정)

Apache S2Graph

참고하거나 연관 된 포스팅 목록

Amazon Redshift: Performance Tuning and Optimization (Slideshare)

오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다. (Slideshare)

[야생의 땅: 듀랑고] 서버 아키텍처 - SPOF 없는 분산 MMORPG 서버 (Slideshare)

Apache Cassandra 톺아보기 - 1편 (NHN-Enter Toast)

Apache Cassandra 톺아보기 - 2편 (NHN-Enter Toast)

Apache Cassandra 톺아보기 - 3편 (NHN-Enter Toast)

Dremel: Interactive Analysis of Web-Scale Datasets (Research at Google)

Kafka New Producer API를 활용한 유실 없는 비동기 데이터 전송 (SK플래닛 기술 블로그)

구글 클라우드 데이터스토어에서 스트롱 컨시스턴시와 이벤츄얼 컨시스턴시의 균형잡기 (nurinamu‘s the BLACK BOOK)

[분산캐시] Redis 와 memcache의 flush는 왜 다를까? (Charsyam's Blog)

ZooKeeper를 활용한 Redis Cluster 관리 (Naver D2)

Memcached의 확장성 개선 (Naver D2)

글로벌 분산 데이터베이스 Spanner (Naver D2)

왜 레진코믹스는 구글앱엔진을 선택했나 (Slideshare)

카카오 “레디스, 잘못쓰면 망한다" (ZDNet Korea)

Apache spark 소개 및 실습

#데이터베이스 #분석아키텍처 #개발 #서버 #백엔드 #engineering

3 notes · View notes