데이터 중심 애플리케이션 설계 - 1. 개요, 1장 요약

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

db를 다루는 부분에서 실무와는 별개의 이론적인 보강이 필요했고, 남은 시간에 전공지식을 좀 갖추고 싶은 맘도 있어서 구매했다. 노마드 코더의 추천으로 워낙 유명한 책이기도 해서 꼭 읽어보고 싶었는데, 면접에서 db쪽으로 워낙 부족하다는 게 드러나서 한 번 읽어보면 좋지 않을까싶어 구매했다.

여담이긴 한데 종이책을 좋아하긴 폭탄 맞을 때가 있다. 베스트셀러가 아닌 경우 서점에 보통 한 권 비치되어 있으면 감지덕지인데 이번 책은 표지 안 쪽이 구겨져있었다. 게다가 목차 part1 부분은 part2라고 적혀진 오류가 있었다. 어휴

책 요약을 하기에 앞서

앞으로 일을 하면서 전공서나 컴퓨터 교양서를 읽으면서 공부할 시간이 많을 것 같다. 물론 별개로 시험 대비를 위한 공부, 일을 위한 공부, 그 외 관심이 가는 분야의 프로그래밍 공부 등이 우선되기 때문에 책은 생각만큼 많이 읽지 못할 수 있지만, 그래도 틈틈이 읽으면서 요약 정리를 할 예정이다.

당연히 부담을 갖고 많은 양을 쏟아낼 예정은 아니고, 책마다 정해진 소주제 하나 내지 두 개의 분량을 요약해서 꾸준히 적는 게 목표다. 그렇게 해야 책을 읽는 부담도 덜고, 책을 요약해서 적는 부담도 적으면서, 읽는 부분의 지식을 잘 기록해둘 수 있을 것 같다. 물론 나중에 생각이 바뀔 수는 있지만 일단은 그렇게 가볼 예정이다.

1장. 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션

• 최근의 많은 애플리케이션은 계산 중심보다는 데이터 중심적이다. 일반적으로 데이터 중심 애플리케이션은 CPU의 성능보다는 데이터의 양, 복잡도, 데이터의 변화 속도에 더 영향을 받는다.

• 데이터 시스템이 잘 추상화된 요즘에, 데이터 중심의 애플리케이션은 아래와 같은 요소를 필요로 한다.

1. 데이터베이스
2. 캐시
3. 검색 색인
4. 스트림 처리
5. 일괄 처리

• 실제로 데이터베이스나, 큐, 캐시 등은 다른 도구로 생각하지만 일괄적으로 데이터 시스템이란 용어로 묶어 생각한다. 그 이유는 다음과 같은

1. 데이터 저장과 처리를 위한 도구는 최근에 만들어졌고, 새로운 도구는 전통적 분류에 딱 맞지 않아 경계가 흐려지고 있다.
2. 많은 애플리케이션이 단일 도구로는 데이터 처리와 저장을 모두 만족시킬 수 없다.

• 이 책은 데이터 시스템 구축을 위한 신뢰성, 확장성, 유지보수성의 의미를 명확히 하는 것으로 시작한다.

신뢰성

• 신뢰성은 애플리케이션이 잘못되더라도 지속적으로 올바르게 동작함을 의미한다.
• 여기서 결함과 장애를 구분할 수 있다. 결함은 잘못될 수 있는 일이며 이를 예측, 대처할 수 있는 시스템은 내결함성을 지녔다고 말한다.
• 장애는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 상황을 의미한다.

하드웨어 결함

• 여러 장비를 다루는 일에서 이는 늘상 일어나는 일이다. 하드웨어 결함으로 인한 장애를 줄이기 위해서는 중복을 이용한다. 디스크의 RAID 구성, 핫 스왑 가능한 CPU 사용 등이 그 예이다.

• 요즘은 데이터의 양과 애플리케이션의 계산 요구가 늘어나면서 많은 장비를 사용해 하드웨어 결함율도 증가하였다. 이에 소프트웨어 내결함성 기술을 사용하거나 하드웨어 중복성 추가로 장비 손실을 견디는 시스템을 구축 중이다.

소프트웨어 오류

• 시스템 내 체계적 요류는 예상하기 어렵고 노드 간 상관관계 때문에 시스템 오류를 더욱 많이 유발한다.

• 이와 같은 버그는 특정 상황 발생 전까지 오랫동안 나타나지 않는다. 또한 신속한 해결책이 없으며, 주의깊게 시스템 생각, 빈틈 없는 테스트, 모니터링 분석과 같은 것으로 문제 해결에 도움을 줄 수 있다.

인적 오류

• 한 연구에 따르면 운영자의 설정 오류가 시스템 중단의 주요 원인이고, 하드웨어 결함은 전체 중단의 10~15%에 그친다고 한다.

• 이처럼 사람은 미덥지 않지만 몇 가지 방법으로 인적 오류를 최소화할 필요가 있다.

1. 설계를 오류 가능성 자체를 피하게 설계한다. 잘 설계된 추상화, API, 관리 인터페이스를 사용한다.
2. 사람이 가장 많이 실수하는 장소에서 장애가 발생할 부분을 분리한다.
3. 테스트를 철저히 해라.
4. 인적 오류 복구를 최대한 빠르게 하는 방법을 마련해라.
5. 성능 지표와 오류율같은 명확한 모니터링 계책을 마련해라.
6. 조작 교육과 실습을 실행해라.

확장성

• 시스템이 안정적으로 동작해도 미래에도 안정적이란 보장은 없다.
• 확장성은 증가한 부하에 대처하는 시스템 능력을 설명하는 데 사용하는 용어이다.

부하 기술하기

• 부하는 간결하게 기술해야 한다. 이는 부하 매개변수라 부르는 몇 개의 숫자로 나타낼 수 있다. 예를 들어 웹 서버의 초당 요청 수, 데이터베이스의 읽기 대 쓰기 비율, 대화방의 동시 활성 사용자, 캐시 적중율 등이 있다.

성능 기술하기

• 부하를 기술하면 부하 증가할 때 어떤 일이 일어나는지 아래 두 가지 방법으로 조사할 수 있다.

1. 부하 매개변수를 증가시키고 시스템 자원은 변경하지 않고 유지하면 시스템 성능은 어떻게 영향을 받을까.
2. 부하 매개변수를 증가시켰을 때 성능이 변하지 않고 유지되길 원한다면 자원을 얼마나 많이 늘려야할까.

• 일괄 처리 시스템은 보통 처리량과 응답 시간에 관심을 갖는다. 응답 시간은 같은 요청에 같은 시스템이어도 매번 다르다. 따라서 단일 숫자가 아닌 분포로 생각을 해야 한다.
• 일반적으로 산술 평균보다는 백분위를 사용해서 응답 시간을 살펴본다.

부하 대응 접근 방식

• 부하 매개변수가 어느 정도 증가하더라도 좋은 성능을 유지하려면 어떻게 해야 할까?

• 사람들은 확장성과 관련해서 용량 확장과 규모 확장을 생각한다. 다수의 장비에 부하를 분산하는 아키텍처를 비공유 아키텍처라고 한다. 고사양 장비는 매우 비싸기 때문에 규모 확장에서는 적당한 사양의 장비 몇 대를 운용하는 실용적 접근이 필요하다.

• 일부 시스템은 탄력적이어서 부하 증가 감지시 컴퓨팅 자원을 자동으로 추가한다. 다만 수동으로 확장하는 시스템이 더 간단하고 예상치 못한 일이 적다.

유지보수성

• 소프트웨어 비용의 대부분은 초기 개발이 아니라 지속해서 이어지는 유지보수에 들어간다는 사실은 잘 알려져있다.
• 일반적으로 많은 사람은 소위 레거시 시트템 유지보수를 좋아하지 않는다.
• 희망적인 부분은 유지보수 중 고통을 최소화하고 레거시 소프트웨어를 직접 만들지 않게끔 설계가 가능하다. 이 원칙은 아래와 같은 세 가지 이다.

1. 운용성 : 운영팀이 시스템을 원활하게 운용하게 하라.
2. 단순성 : 시스템 복잡도를 최대한 제거해 새 엔지니어가 이해하기 쉽게 하라.
3. 발전성 : 엔지니어가 이후 시스템을 쉽게 변경할 수 있게 하라.

운용성

• 시스템이 원할하게 작동하려면 운영팀이 필수고 운영팀은 아래와 같은 작업 등을 책임진다.

1. 시스템 모니터링, 상태가 좋지 않은 서비스 복원
2. 시스템 장애, 성능 저하 추적
3. 시스템 최신화 유지
4. 미래 발생 가능 문제 예측
   ..

단순성

• 소규모 소프트웨어 프로젝트는 간단하고 표현이 풍부한 코드로 시스템 작성이 가능하지만 규모가 커지면 커다란 진흙 덩어리 같은 코드 뭉치가 생기게 된다.

• 이와 같은 복잡해진 코드 때문에 시스템 유지보수가 어려워지면 버그가 발생할 수 있고, 비용이 증가할 수 있다.

• 시스템을 단순하게 하라는 것은 기능을 줄이는 것이 아닌 우발적 복잡도를 제거하는 것이다. 이는 좋은 추상화를 통해 깔끔하고 직관적인 외관으로 세부 내용을 숨긴다.

발전성

• 시스템의 요구 사항은 끊임없이 변한다.

• 조직 프로세스 측면에서 애자일 작업 패턴은 변화에 적응하기 위한 프레임워크를 제공한다.

• 이 책에서는 대규모 프로젝트에서 민첩성을 높이는 방법을 찾고 이를 민첩성 대신 발전성이란 용어로 설명할 것이다.