[AWS/Node] 3. DB 선택 (AWS dynamo DB)

day 3

AWS dynamo DB 를 연동 해보자. 1

DB 의 선택

• 이제 실제로 API 에 디비를 연결해보자.
• 그런데 어떤 디비에 연결할지 고민해보자.
• 항상 학교, 학원에서는 아마도 스키마부터 알려주려할 것이다.
• 나는 그러한 접근이 낡았다고 본다.
• SQL을 무작정 알려준 뒤 디비의 차이점을 이야기 한다는 것은 단풍나무와 떡갈나무의 상세한 차이를 외우게 한 다음 이게 왜 다른지를 나중에 알려준다는 것이라고 보기 때문이다.
• 거의 모든 플랫폼들 회사들이 클라우드를 쓰는 상황에서 아직도 디비를 배우는 순서가 sql 부터라고 한다면 너무 뻔하지 않은가.
• 여러분이 어떤 회사에서 어떤 데이터베이스를 사용하냐에 따라 RDB sql 을 안 쓸 수도 있다는 전제가 빠져있다고 본다.
• 그래서 먼저 CAP (Consistency, Availability, Partition tolerance) 를 살펴보고 내가 사용할 정보가 어떤 성질에 더 적합한지를 이해하고 가야한다고 본다.

1. CAP

• CAP 참고 : https://itwiki.kr/w/CAP_%EC%9D%B4%EB%A1%A0
• CAP 이론은 각각의 단어들의 첫 대문자를 조합한 것이다.
• CAP 이론에 따르면 일반적인 데이터베이스들은 C, A, P 3개중 2개를 선택해야한다고 한다.
• 내가 사용할 디비가 매우 트랜잭션이 작고(1분에 1회) 실제 비용도 매우 작다면 CAP 중 취사 선택은 딱히 의미가 없다. 왜냐하면 CAP 이론 자체가 반드시 2개만 지원하고 다른 하나를 무조건 버린다는 의미가 아니기 때문이다. 셋 중 하나는 지원을 하기는 하는데~ 또는 셋 중 하나는 지원이 어려워서 구현을 직접 하던가~ 라는 의미로 받아들이면 된다.

C : Consistency (일관성)

• 여기나 저기나 같은 항목이면 같은 값이 나와야 한다.

일관성이다. 프랑스에서 설탕이 무엇인지 물어보나 한국에서 설탕이 무엇인지 물어보나 같은 것을 가리키는 것을 말한다.
무엇을 지칭(행 / 필드)하던 동일한 대상에 대해서는 항상 같은 값이 보장되어야 한다.
AWS dynamo DB 에서 read unit 과 관련해서는 이러한 기능을 강력한 일관된 읽기 (Strongly Consistent Reads)로 이야기 한다.
반대로 C가 다소 부족해도 괜찮은 경우를 최종적 일관된 읽기 (Eventually Consistent Reads)라고 이야기 한다.

A : Availability (가용성)

• 어디서나 읽기 쓰기가 가능하다. 일부 노드가 터져도 다른데는 영향이 없어야 한다.

가용성은 접하지 못한 용어일 수 있다. 쉽게 말하면 언제든지 사용할 수 있냐이다.
특정 row 나 특정 테이블에 문제가 생겨도 다른 데이터를 쓸 수 있도록 할 것이냐 고려해 볼 수 있다.
인터넷이 빵빵한 현재를 살아가는 우리는 어느 곳에서 언제 접속을 하건 웹에 1초이내 접속하니 가용성을 이해하기 어려울 수 있다.
그러나 실제로는 인터넷 기지국 또는 중개국이 멀거나 돌이나 산이 가로막고 있으면 전파가 전달되기 어려워 서비스 지연(물리적인 속도)이 발생될 수 있다.
AWS 에서 리전별로 AZ 를 두는 이유중 하나인데, 이러한 지연을 최소화하고 시스템의 고가용성(HA)을 확보하면 화재나 갑작스런 문제에 대응함과 동시에 실 사용자와 가까운 AZ에서 서비스를 대응함으로써 지리적 접근성을 확보할 수 있다.

P : Partition tolerance (분할 내성)

• 데이터가 안오거나 시스템이 터져도 전체 시스템의 동작에는 영향이 없어야 한다.

얘는 앞의 C, A 와는 좀 다른데 데이터의 관점에서 보는 것이 아니라 일종의 내결함성(Fault tolerance)을 이야기 한다.
네트워킹이 될 수도 있고, 시스템이 될 수도 있는데 주로 설명해 놓은 곳 보면 다 네트워킹만 본다.
갑자기 내결함성이라는 말이 나오니 헷갈릴 수 있는데 쉽게 풀어 말하면 어딘가 파이프가 터져서 물이 새기는 하는데 공정 자체는 정상적으로 돌기는 한다이다.
물론 극단적 예시이고 실제로 크리티컬하고 지속되며 앞으로 큰 문제일 경우에는 내결함성이 있는 개발도 하되 테스트 코드를 통해 품질에 대한 보증과 개선을 할 필요는 있다.
역시 쉽게 말하면 파이프 보수공사이다.
P를 허용한다는 것은 파이프가 지속적으로 새는 것은 아니고, 가끔 샐 수는 있긴 한데, 1초에 10만 리터가 이동하는 파이프에서 1-2시간에 한번 꼴로 200 ml 쯤 간혹 새기는 하는데 파이프 자체 확인 결과 녹이 슨 것도 아니고 단단해서 앞으로 200 년은 부서지지 않을 것이다 뭐 그런식으로 볼 수 있다.
시스템 자체에 문제까지는 아니고 가끔 통신 문제나 시스템 오류가 발생할 수는 있어도 모든 시스템에 에러가 나진 않고 뻗지도 않는 것이다.

CAP 이론에서는 상기 C, A, P 중 2가지를 선택한 디비 유형을 이야기한다.
그러나 뭐 셋중에 반드시 둘 만 쓸 수 있다 이런 것이 아니라서 일부 설명글들을 보면 CAP 가 틀렸다던가, 올드 하다던가 이야기가 많다.
그냥 이런 것도 있구나 하고 반드시 읽고 넘어가자.

2. PACELC

• 그래서 나왔다. PACELC
• CP, AP 시스템으로써는 최신 분산 시스템을 설명하기는 좀 그렇다.

솔직히 나는 그렇다고 PACELC 가 또 완벽한 설명을 하고 있다고 보지는 않는다. 여튼 보자.

• PACELC 참고 : https://itwiki.kr/w/PACELC_%EC%9D%B4%EB%A1%A0
• Partition-Availability-Consistency-Else-Latency-Consistency (PACELC) 다른 설명 필요없이 그냥 이게 내용이긴 하다.
• Partition 상황인 경우 Availability / Consistency 아닌 경우 Latency / Consistency중 하나를 선택한다. 심플하다.

장애 상황에서 가용성과 일관성은 항상 같이 존재할 수 없다.
쉽게 이야기 해서 화재가 나서 A 시스템의 서버 B가 5시간정도 꺼져있었다.
가용성을 고려한다면, A 시스템은 화재에도 정상 동작을 해야하므로 서버 B의 동기화하지 못한 데이터는 같은 시스템내 동기화가 필요한 서버에 갱신해주지 못한다.
마찬가지로 역인 상황도 발생한다. 그러나 A 시스템은 정상 동작해야하므로 일관성은 처음에는 지켜지지 않을 수 있다.
화재가 나기전 B 서버로 홍길동씨가 프로필 수정을 하였으나 프로필 수정 정보가 B2 서버등 백업 서버나 동기화 서버에 갱신 직전 불이 나면 수정된 프로필은 갱신되지 않는다.
화재가 진압되고 서버가 다시 올라갈 경우, 시스템 동기화를 통해 최종적으로는 수정이 되기는 할 것이다.
이러한 경우 가용성은 챙기고 일관성은 있기는 해도 화재 진압 5시간동안은 일관성을 챙길 수는 없는 것이다.

반대로 일관성을 고려한다면 일부 가용성은 포기할 수 있다.

앞서 Availability / Consistency 는 이야기 하였으므로 Latency만 보도록 하자.

L : Latency (지연)

정상 상황에서 요청시 얼마나 걸리는지이다.
매우 작은 스키마에 대해서는 사실 지연이 없다.
쓰기 시간은 상황에 따라 다소 걸릴 수 있다.
쓰기 시간을 기다려서 항상 일관성 있는 값을 보여줄지, 기다리지 않고 바로 값을 보여줘서 현재는 다소 일관성이 없더라도 최종적으로는 일관된 값이 언젠가는 나오도록 구성할지 고민할 수 있다.
AWS dynamo DB 에서 read unit 과 관련해서는 이러한 기능을 강력한 일관된 읽기 (Strongly Consistent Reads) / 최종적 일관된 읽기 (Eventually Consistent Reads)라고 이야기 한다.
물론 쓰기 지연도 포함한다. (캐싱 포함한 시스템 전체를 이야기할 경우)

3. AWS dynamo DB 선택

앞서 몇가지 시스템 분류에 대해 살펴 보았다.
우리가 사용할 디비는 단순하다. 조인이 필요하지 않은 예제이고 일관성까지 고려할만큼 중요한 데이터를 다루지는 않는다.
또한 연습이므로 비용이 무료이거나 저렴해야한다.

• 일관성이 다소 필요하지는 않으나 응답 속도는 어느정도 필요하다. (연습을 빨리하고 자야하니까)

PA (Partition / Availability) / EL (else / Latency)

• join 이 필요하지 않다

RDB 는 고려하지 않는다. (No SQL 기반이 join 이 불가능하지는 않다.)

• 해당 소스 테스트는 AWS lambda 를 통해 배포될 것이다.

별도의 온프레미스 디비 서버를 구축할 필요없이 같은 연습 AWS 계정으로 디비를 만들자.

• 비용

AWS RDS 나 AWS document 는 서버가 올라가므로 서버 사용 비용을 지불해야한다.
이는 디비 사용 비용이 아니라서 사용을 안하더라도 서버 비용이 나간다. 때문에 요청 비율 대비 비용이 불필요하게 많다.

 

따라서 이번에는 AWS dynamo DB 를 연동하여 day2 의 API 를 붙여보고자 한다.

 

• CAP / PACELC 이 무엇인지 훑어 본다.
• 끝!