NoSQL과 클라우드 컴퓨팅 인프라

앞 노트의 하둡이 파일을 나눠 담는 쪽이었다면 이 노트는 레코드를 나눠 담는 쪽입니다. 관계형 데이터베이스가 수십 년 잘 쓰이다가 빅데이터에서 한계를 만난 자리, 그 자리를 메운 NoSQL의 갈래, 그리고 이 모든 것이 실제로 올라가는 클라우드까지가 1과목의 인프라 부분입니다. 문항은 「어떤 요구사항에 어떤 저장소·서비스 모델이 맞는가」로 나오므로, 이름보다 무엇을 포기하고 무엇을 얻었는가를 잡아 두어야 합니다.

스케일 업과 스케일 아웃

데이터가 늘어 감당이 안 될 때 늘리는 방법이 둘입니다.

관계형 데이터베이스가 주로 스케일 업 쪽인 이유가 있습니다. 조인과 트랜잭션이 여러 대에 걸치면 급격히 비싸지기 때문입니다. 한 대 안에서는 두 테이블을 붙이는 것이 메모리 안의 일이지만, 두 대에 나뉘어 있으면 네트워크를 오가는 일이 됩니다.

CAP 이론 — 셋 중 둘

CAP 이론은 분산 데이터 저장소가 다음 셋을 동시에 만족할 수 없고 최대 둘까지만 가질 수 있다는 원리입니다.

핵심은 셋이 대등하지 않다는 것입니다. 여러 대로 흩어 놓은 이상 네트워크는 언젠가 끊기므로 P는 고를 수 있는 것이 아니라 주어진 조건입니다. 그래서 실제 선택은 「끊겼을 때 무엇을 할 것인가」 하나로 좁혀집니다.

• CP를 고른다 — 끊긴 쪽에는 답을 주지 않는다. 틀린 값을 주느니 응답을 멈춘다. 잔액·재고처럼 값이 어긋나면 안 되는 곳.
• AP를 고른다 — 일단 답을 준다. 옛 값일 수 있지만 나중에 맞춰진다. 타임라인·조회수처럼 잠깐 어긋나도 되는 곳.

이 「나중에 맞춰진다」를 결과적 일관성(eventual consistency)이라 부릅니다. 관계형 쪽의 ACID(원자성·일관성·고립성·지속성)에 대비되는 NoSQL 쪽의 성질을 BASE라 묶는데, 기본적으로 가용하고(Basically Available) 상태가 확정되지 않을 수 있으며(Soft state) 결국은 일관돼진다(Eventually consistent)는 뜻입니다.

CA는 사실상 분산이 아닌 한 대짜리 시스템의 자리입니다. 「가용성과 일관성을 모두 갖춘 분산 데이터베이스」라는 보기가 나오면 그것이 오답입니다.

NoSQL 네 갈래

NoSQL은 고정된 스키마와 조인에 기대지 않고 수평 확장을 우선한 저장소를 묶어 부르는 말입니다. 「SQL을 안 쓴다」가 아니라 「관계형 모델만 쓰지는 않는다」에 가깝습니다. 데이터를 담는 모양으로 넷으로 갈립니다.

키-값과 문서가 헷갈리는데 기준은 하나입니다 — 값 안을 들여다보고 조건을 걸 수 있는가입니다. 키-값 저장소에게 값은 그냥 덩어리라 「나이가 30 이상인 것」을 못 찾지만, 문서 저장소는 문서 안의 필드로 질의할 수 있습니다.

// 키-값: 키를 알아야 꺼낸다
db.set("user:1001", '{"name":"민서","age":31}');
db.get("user:1001");

// 문서: 값 안의 필드로 조건을 건다
db.users.find({ age: { $gte: 30 } }, { name: 1 });

그래프가 답이 되는 자리도 분명합니다. 「친구의 친구가 좋아한 상품」처럼 관계를 여러 단계 따라가는 질의가 나오면 그래프입니다. 관계형으로 하면 단계마다 조인이 하나씩 붙어 단계가 늘수록 급격히 느려집니다.

관계형과 무엇이 다른가

「넣기 전에 정한다」와 「읽을 때 해석한다」의 차이가 실무에서 가장 크게 느껴지는 자리입니다. 관계형은 형식에 안 맞는 데이터를 애초에 못 넣게 막아 품질을 지키는 대신, 형식이 바뀔 때마다 스키마를 고쳐야 합니다. NoSQL은 그 반대로 일단 받아 두고 해석은 읽는 쪽에 미룹니다 — 앞 노트에서 본 Variety에 대한 답이 이것입니다.

그래서 NoSQL이 관계형보다 낫다는 문장은 답이 아닙니다. 계좌 이체처럼 여러 표가 한꺼번에 맞아떨어져야 하는 일에는 여전히 관계형이 맞습니다.

클라우드 서비스 모델 셋

무엇을 남이 관리하고 무엇을 내가 관리하는가로 갈립니다.

외우는 대신 경계선이 어디에 그어졌는지를 보면 됩니다. 위에서 아래로 갈수록 선이 내려가고, 내가 손댈 수 있는 범위와 손대야 하는 범위가 함께 줄어듭니다. 「운영체제 패치를 직접 해야 하는가」가 IaaS와 PaaS를 가르는 가장 빠른 물음입니다.

배치 모델 셋

빅데이터에서 하이브리드가 자주 답이 되는 이유가 있습니다. 개인정보가 든 원본은 사내에 두고, 가명 처리한 데이터로 도는 모델 학습만 퍼블릭의 GPU를 잠깐 빌려 쓰는 구성이 흔하기 때문입니다.

빅데이터와 인공지능

마지막으로 이 둘의 관계를 한 문단으로 정리합니다. 인공지능은 방법이고 빅데이터는 재료입니다. 딥러닝 기법 자체는 수십 년 전에 나왔지만 널리 쓰이게 된 것은 학습시킬 데이터가 쌓이고 그것을 감당할 분산 인프라와 GPU가 생긴 뒤입니다. 반대 방향도 성립합니다 — 이미지·음성·텍스트 같은 비정형 데이터는 사람이 일일이 볼 수 없어 오래 방치됐는데, 인공지능이 그것을 자동으로 해석해 주면서 비로소 값을 갖게 됐습니다.

여기서 나오는 문장이 하나 있습니다. 데이터가 늘면 성능이 오르지만 무한히 오르지는 않습니다 — 같은 성질의 데이터를 더 넣는 것보다 편향을 줄이고 품질을 높이는 편이 나은 구간이 곧 옵니다. 「데이터가 많을수록 무조건 좋은 모델이 된다」는 보기는 오답 표시입니다.

연습 문제

1. 스케일 아웃에 대한 설명으로 옳은 것은?
   ① 한 대의 CPU와 메모리를 키우는 방식이다
   ② 기계 대수를 늘려 처리 능력을 확장한다
   ③ 관계형 데이터베이스가 가장 잘 어울리는 확장 방식이다
   ④ 확장할수록 단일 장애점이 커진다

   ②. ①은 스케일 업입니다. 조인과 트랜잭션이 여러 대에 걸치면 비싸지므로 관계형은 대체로 스케일 업 쪽이고, 대수를 늘리는 쪽은 한 대가 서도 나머지가 돕니다.
2. CAP 이론에 대한 설명으로 옳은 것은?
   ① 셋을 모두 만족하는 분산 시스템을 설계할 수 있다
   ② 네트워크 분할은 설계자가 고를 수 있는 선택지다
   ③ 분할이 일어나는 이상 일관성과 가용성 중 하나를 포기해야 한다
   ④ 관계형 데이터베이스는 CAP의 적용 대상이 아니다

   ③. 여러 대로 흩어 놓은 이상 네트워크는 언젠가 끊기므로 P는 주어진 조건이고, 남는 선택은 끊겼을 때 응답을 멈출지(CP) 옛 값이라도 줄지(AP)입니다.
3. 은행이 계좌 잔액을 다루는 분산 저장소를 고릅니다. 노드 사이가 끊겼을 때 옛 잔액을 보여 주느니 응답을 멈추는 쪽을 택했습니다. 이 선택은?
   ① CA
   ② CP
   ③ AP
   ④ BASE

   ②. 일관성을 지키려 가용성을 포기한 것이므로 CP입니다. ④는 선택지가 아니라 AP 계열 저장소가 갖는 성질의 이름입니다.
4. 「친구의 친구가 최근에 구매한 상품」처럼 관계를 여러 단계 따라가는 질의가 잦습니다. 가장 알맞은 저장소 갈래는?
   ① 키-값
   ② 문서
   ③ 컬럼 패밀리
   ④ 그래프

   ④. 단계를 따라가는 질의가 그래프의 자리입니다. 관계형이나 다른 갈래로 하면 단계마다 조인이 하나씩 붙어 단계가 늘수록 급격히 느려집니다.
5. 사용자마다 갖는 필드가 제각각인 프로필을 저장하고, 「가입일이 올해이고 관심사에 여행이 든 사용자」처럼 값 안의 필드로 조건을 걸어야 합니다. 알맞은 갈래는?
   ① 키-값
   ② 문서
   ③ 그래프
   ④ 관계형

   ②. 값 안을 들여다보고 조건을 걸 수 있는 것이 문서 저장소이고, 필드가 제각각이어도 됩니다. 키-값은 값이 덩어리라 키를 알아야만 꺼냅니다.
6. 운영체제 패치와 미들웨어 설치는 제공자가 맡고, 나는 애플리케이션 코드와 데이터만 관리합니다. 어느 서비스 모델입니까?
   ① IaaS
   ② PaaS
   ③ SaaS
   ④ 온프레미스

   ②. 경계선이 운영체제 아래가 아니라 애플리케이션 아래에 그어졌습니다. IaaS라면 운영체제 패치가 내 일이고, SaaS라면 애플리케이션도 내 것이 아닙니다.
7. 빅데이터와 인공지능의 관계에 대한 설명으로 옳지 않은 것은?
   ① 대량의 학습 데이터가 쌓이면서 딥러닝이 실제로 쓰이게 됐다
   ② 인공지능은 비정형 데이터를 해석해 그 데이터에 값을 만들어 준다
   ③ 학습 데이터를 늘리면 모델 성능이 한계 없이 계속 오른다
   ④ 분산 인프라와 GPU는 대량 학습을 가능하게 한 조건이다

   ③. 같은 성질의 데이터를 더 넣는 것으로는 곧 한계가 옵니다. 그 구간에서는 양보다 편향을 줄이고 품질을 높이는 편이 낫습니다.

인프라를 묻는 문항은 거의 언제나 무엇을 포기했는지를 답으로 갖고 있습니다. 스케일 아웃은 조인의 편함을, CP는 가용성을, NoSQL은 넣기 전 검증을, PaaS는 운영체제를 만질 자유를 포기한 것입니다. 요구사항 문장에서 「포기해도 되는 것」을 먼저 찾으면 보기 넷 중 남는 것은 대개 하나입니다.