데이터 중심 애플리케이션 설계

p.xvii

하둡, 스파크 같은 오픈소스 대용량 분산 데이터 처리 솔루션은 집단 지성의 힘으로 수년에 걸쳐 발전했고 이 글을 쓰는 시점에는 이미 성숙 단계에 접어들었다. 이제는 시스템 운영에 있어 단순한 장비 장애나 데이터 이전 및 확장 등의 고민은 확실히 크게 줄었다. 하지만 시스템 설계자, 개발자, 운영자의 입장에서 현장에서 느끼는 불안감은 전혀 줄지 않았다. 이 불안감이 대체 어디서 오는 것일까?

 

이런 규모의 데이터를 빠르게 생성하고 유지하기 위해서는 매우 복잡한 여러 시스템을 거쳐야 한다. 이 복잡한 시스템들은 대개 여러 조직에 걸쳐 있을 뿐 아니라 각 시스템이 항상 정상적으로 동작한다고 보장할 수 없다. 장애에 대응하기 위해 전력을 다하더라도 오직 예측 가능한 상황만이 미리 대응 가능할 뿐 예측하지 못하는 상황은 언제든지 생긴다. 혹시 문제가 발생한다 해도 서비스와 시스템에 관련된 모든 사람이 모든 시스템을 잘 알고 대응하기는 사실상 불가능하다. 낙관적으로 생각해서 모든 관련 시스템을 꿰똟고 있는 전문가가 있어 이런 문제를 알아서 해결해 준다고 치자. 그러나 이 전문가도 결국 사람이다. 인공지능이 완전히 사람을 대체하기 전에는 사람이 전혀 개입하지 않는 시스템은 없다. 사람은 언제나 실수를 하게 마련이고 때로는 그 실수가 전체 시스템을 마비시킬 가능성도 적지 않다. 또한 성숙한 오픈소스와 훌륭한 개발자들이 작성한 코드가 모든 작업 부하에 잘 작동한다는 보장이 없기 때문에, 시스템 설계와 솔루션 선택은 사람의 직관에 의존할 수밖에 없다.

 

p.7

결함(fault)은 장애(failure)와 동일하지 않다. 일반적으로 결함은 사양에서 벗어난 시스템의 한 구성 요소로 정의되지만, 장애는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우다. 결함 확률을 0으로 줄이는 것은 불가능하다. 따라서 대개 결함으로 인해 장애가 발생하지 않게끔 내결함성(fault-tolerant) 구조를 설계하는 것이 가장 좋다.

 

반직관적이지만 이러한 내결함성 시스템에서 경고 없이 개별 프로세스를 무작위로 죽이는 것과 같이 고의적으로 결함을 일으켜 결함률을 증가시키는 방법은 납득할 만하다. 실제로 많은 중대한 버그는 미흡한 오류 처리에 기인한다. 고의적으로 결함을 유도함으로써 내결함성 시스템을 지속적으로 훈련하고 테스트해서 결함이 자연적으로 발생했을 때 올바르게 처리할 수 있다는 자신감을 높인다. 넷플릭스의 카오스 몽키(Chaos Monkey)가 이런 접근 방식의 한 예다.

 

p.11

확장성은 증가한 부하에 대처하는 시스템 능력을 설명하는 데 사용하는 용어지만 시스템에 부여하는 일차원적인 표식이 아님을 주의하자. "X는 확장 가능하다" 또는 "Y는 확장성이 없다" 같은 말은 의미가 없다. 오히려 확장성을 논한다는 것은 "시스템이 특정 방식으로 커지면 이에 대처하기 위한 선택은 무엇인가?"와 "추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까?" 같은 질문을 고려한다는 의미다.

 

p.14~15

보고된 서비스 평균 응답 시간을 살피는 일은 일반적이다. 하지만 '전형적인' 응답 시간을 알고 싶다면 평균은 그다지 좋은 지표가 아니다. 얼마나 많은 사용자가 실제로 지연을 경험했는지 알려주지 않기 때문이다.

 

일반적으로 평균보다는 백분위(percentile)를 사용하는 편이 더 좋다. 응답 시간 목록을 가지고 가장 빠른 시간부터 제일 느린 시간까지 정렬하면 중간 지점이 중앙값(median)이 된다. 예를 들어, 중간 응답 시간이 200밀리초면 요청의 반은 200밀리초 미만으로 반환되고 나머지 반은 그보다 오래 걸린다는 뜻이다.

 

p.20~21

시스템을 단순하게 만드는 일이 반드시 기능을 줄인다는 의미는 아니다. 우발적 복잡도(accidental complexity)를 줄인다는 뜻일 수도 있다. 모슬리와 마크스는 우발적 복잡도를 소프트웨어가 풀어야 할 (사용자에게 보이는) 문제에 내재하고 있지 않고 구현에서만 발생하는 것으로 정의했다.

 

우발적 복잡도를 제거하기 위한 최상의 도구는 추상화다. 좋은 추상화는 깔끔하고 직관적인 외관 아래로 많은 세부 구현을 숨길 수 있다. 또한 좋은 추상화는 다른 다양한 애플리케이션에서도 사용 가능하다. 이러한 재사용은 비슷한 기능을 여러 번 재구현하는 것보다 더 효율적일 뿐만 아니라 고품질 소프트웨어로 이어진다. 추상화된 구성 요소의 품질 향상이 이를 사용하는 모든 애플리케이션에 도움이 되기 때문이다.