데이터 중심 애플리케이션 설계, 마틴 클레프만 지음. OREILLY.

서비스의 중심이 데이터가 되고 있다.

점점 커지는 데이터 관리의 중요성

트위터, 유투브, 넷플릭스, 인스타그램. 전 세계 사람들이 사용하는 대규모 서비스의 공통점은 데이터가 곧 경쟁력이 된다는 점이다. 데이터로부터 새로운 발견을 하고, 그 발견을 제폼에 녹여내서 사용자에게 유용한 서비스를 제공한다.
다들 말하는 유투브의 알고리즘도, 넷플릭스의 추천 영상도 모두 데이터에서 나온다. 나와 다른 사람들의 시청 기록을 저장해두었다가 잘 가공한다. 가공한 결과를 통해 수많은 콘텐츠 중 어떤게 가장 흥미로울지 필터링해서 보여준다.
고도화된 기술을 쓰지 않더라도 일단 데이터양이 불어나면 신경쓸게 많아진다. 사용자가 아무리 많아도 서버가 죽지 않아야한다. 죽지 않을뿐만 아니라 '납득할만한' 속도로 사용자 요청을 처리해야한다. 한국인이라면 트위터에서 메인 피드를 불러오는데 30초만 걸려도 당장 새로고침을 하거나 페이지를 나가버릴 것이다.

계산 중심적 vs. 데이터 중심적

책의 머리말에 이런 단어가 나온다. Compute-intensive, data-intensive.

데이터 양, 데이터 복잡성, 데이터가 변하는 속도 등, 데이터가 주요 도전 과제인 애플리케이션을 데이터 중심적 애플리케이션이라고 한다. 반대로 CPU 사이클이 병목인 경우 계산 중심적이라고 한다.

데이터가 주요 도전 과제인 애플리케이션은 이해하기 쉽다. 우리가 지금 사용하는 대부분의 서비스가 여기에 속하기 때문이다. 앞서 말한 트위터, 유투브, 넷플릭스, 인스타그램 모두 다. 계산 중심적 애플리케이션은 어떤게 있을까? 스택오버플로우에 검색해보면 이런 예시가 나온다.

• 소수 찾기: 매우 큰 정수(BigInteger) 나눗셈이 필요함
• 2000!과 같은 큰 수의 팩토리얼 계산: 매우 큰 정수 곱셈이 필요함

아, 이제 구분이 좀 되기 시작한다. 확실히 이런 연산에서는 데이터보단 CPU 성능이 큰 문제가 될 것이다.

이 책에서는 데이터 중심적 애플리케이션 설계를 다룬다. 1부에서는 이와 관련된 기본 개념을 다루고 2부에서 본격적인 얘기를 한다. 3부에서는 파생 데이터를 만드는 시스템을 설명한다.

잘 만들어진 서비스의 3가지 조건

1부 1장에서는 데이터 중심 애플리케이션의 기본 요구사항 3가지를 소개한다. 이 책 전체를 통해 달성하고자 하는 목표이기도 하다. 신뢰성, 확장성, 유지보수성이다. 데이터 중심 애플리케이션이라면 이 3가지 요건을 잘 갖추고 있어야 한다.

신뢰성

무언가 잘못되더라도 지속적으로 '올바르게' 동작해야 한다. 어떤 동작이 '올바른' 동작인지는 책에서 정의하고 있다. 대부분 우리가 사용하고 있는 서비스처럼 '잘 굴러가야'한다는 내용을 담고 있다.

결함(fault) vs. 장애(error)

결함과 장애는 다르다. 원래 시스템의 사양에서 벗어났지만 어쨌든 시스템이 돌아가고 있다면 결함이 생긴 것이다. 하지만 시스템 전체가 멈췄다면 장애가 발생했다고 말한다. 신뢰성은 모든 장애를 막을 수 있음을 의미하지 않는다.

책에서 든 예시로는 갑자기 블랙홀이 지구와 충돌하는 경우가 있었다. 이런 장애는 그 누구도 막을 수 없다. 신뢰성 있는 애플리케이션이라도 일어날 수 있는 모든 장애를 막을 수는 없다. 다만 복구 가능한 결함의 종류가 많을수록 신뢰성이 올라갈 뿐이다.

결함의 종류

1. 하드웨어 결함 2. 소프트웨어 결함 3. 인적 결함

하드웨어 결함은 물리적인 기계 오류가 일어나서 생긴 결함이다. 하드웨어 결함은 괜찮다. 전파되지 않기 때문이다. 서버실 컴퓨터 1대가 기계적 원인으로 인해 멈췄다고 해서 그 옆에 있는 컴퓨터도 따라서 죽지 않는다.

소프트웨어 결함이라면 말이 달라진다. 소프트웨어 결함은 전파된다. 시스템 소프트웨어의 한쪽이 잘못되었다면 그 영향이 다른쪽에도 미쳐서, 새로운 문제가 발생할 확률이 높다. 간단하게 우리가 코딩할 때 하나를 고치면 다른쪽에서 터지는 그런 상황을 상상하면 된다.

인적 결함은 대부분의 비율을 차지한다. 인간이 하는 일이 이렇게 허점이 많다. 가장 대표적으로 서버실 에어컨을 꺼버린다거나,,, 시스템 설정을 잘못 건드리거나,, 이런 일들이 있다.

확장성

부하가 증가할 때 시스템이 잘 대처하는 능력. 확장성은 단순히 1차원적 성격이 아니다. 예를 들어 '프로그램 A는 확장성이 없어서 별로다.'라고 간단하게 말할 문제가 아니란거다. '부하가 이정도로 늘었을 때 프로그램 A는 이만큼 대처할 수 있다.'는 식으로 서술하는게 맞다. 즉, 확장성을 측정하기 위해 전세계인이 동의한 아주 strict한 기준이 없다. 상황에 달린 것이다.

부하 기술 방식, 성능 기술 방식

그래서 확장성에 대해 얘기하려면 먼저 시스템에 걸리는 부하와 시스템의 성능을 서술할 수 있어야 한다. 책에서도 이를 먼저 얘기한 다음, 확장성에 대한 이야기를 본격적으로 시작한다.

Scaling-up vs. Scaling-out
Scaling-up (용량 확장): 장비 자체의 성능을 높임. 어떻게? 더 고오급 장비를 사면 된다. vertical scaling이라고도 한다.
Scaling-out (규모 확장): 장비에 부하를 분산시킴. 어떻게? 장비를 여러대 사면 된다. 그러면 장비 하나에 집중되는 부하가 분산된다. horizontal scaling이라고도 한다.

유지보수성

앞선 2가지 성격이 컴퓨터가 좀 더 잘 일하게 하는 방식과 관련이 있다면 유지보수성은 인간의 삶의 질 향상과 관련이 깊다. 유지보수성에는 3가지 측면이 있다: 운용성, 단순성, 발전성.

운용성, 단순성, 발전성

• 운용성: 운영의 편리함. 관리자가 운영을 편하게 실수 없이 할 수 있는 방향으로 만들어야 한다. 또한 반복되는 일을 쉽게 수행하게 해야 한다.

• 단순성: 복잡도를 관리해야 한다. 컴퓨터 세계에서 복잡도를 줄이는 방식은 주로 추상화를 통해 구현된다. 책에서도 추상화 내용을 이후에 다룰 예정이라고 한다.

• 발전성: 변화가 쉽게 만들어야 한다. 유연성, 수정 가능성, 적응성이라고도 부른다.

즉, 유지보수성은 시스템이 관리하기 편리하고 이후에 쉽게 바꿀 수 있는지를 다룬다.

다음 장에서는

2장 데이터 모델과 질의 언어 부분에서는 데이터 모델의 중요성에 대해 다룬다. 데이터 모델을 어떻게 만드느냐에 따라 문제에 접근하는 방식 자체가 달라지기 때문이다. 예를 들어, MySQL을 썼을 때와 몽고DB를 썼을 때 사용자의 구매 이력을 불러오는 방식에는 큰 차이점이 있다. 이런 식이다.