[독서] 대규모 서비스를 지탱하는 기술

대규모 서비스를 지탱하는 기술

이번 포스팅에서는 "웹 개발자를 위한 대규모 서비스를 지탱하는 기술"을 읽은 후기를 작성하고자 합니다.

웹 개발자로 근 10년 근속했지만, 대규모 서비스 개발에 참여한 적 있냐고 물어본다면

자신있게 말할 수 있는 경험이 없습니다.

사실 그런 경험은 제가 선택하기 어려운 부분이기도 했습니다.

직접 경험이 아닌 책을 통한 간접 경험도 나름의 가치가 있을 거라고 생각해서 이 책을 읽게 되었습니다.

책에서 얻은 경험을 언젠가 써먹을 일이 있지도 않을까하여...😯

 

 

목차

1. 얻게 된 깨알 지식

이 책은 대규모 서비스에 필요한 깨알 지식이 포함되어 있습니다.

• 탐색 속도 측면에서 Memory는 Disk에 비해 10만~100만배 이상 빠르다.
• SSD는 물리적 회전의 HDD보다 훨씬 탐색이 빠르다.
• 부하에는 크게 CPU, IO 두가지 종류로 구분할 수 있다.
• MySQL의 인덱스는 B+트리 구조로 되어있다.
• DB서버는 초기화 시 캐시가 올라가지 않는다. 즉, 초기 구동시 IO효율과 20분 뒤 IO효율이 극명하다.

위 정보 이외에도 대규모 서비스와 관련된 키워드나 기술을 소개합니다.

개인적인 생각으로 어느정도 연차가 쌓였을 때(3-4년?)

읽는다면 보다 더 이해가 쉬울 수 있을 듯합니다.

관련 업에 종사하지 않거나 웹 서비스를 다뤄본 경험이 없다면

마치 IT정보 시험 공부 같은 느낌을 받을 수도 있을 것 같다는 생각이 들었습니다.🫡

 

2. 대규모 데이터 처리

결국 대규모 서비스는 대규모 데이터를 처리하는 서비스일 것입니다.

책 초반에는 대규모 데이터를 다루는데 필요한 기초 지식들을 소개함과 동시에 비교합니다.

CPU, IO, Memory, Disk, DB 등 컴퓨터 공학을 전공하였다면 알만한 내용들입니다.

잊고 있었다면, 다시 떠올리게 될 내용들도 보기 좋게 정리 되어있습니다.

 

대규모 데이터에 대한 부하 처리에 있어 CPU, IO에 대한 효율성 문제는 대두될만 합니다.

CPU는 간단하다고 말합니다. 스케일 아웃과 로드밸런서를 통한 부하 분산만 적절히 해주면 말입니다.

어려운 문제는 IO에서 발생합니다.

예를 들어 DB 입출력에 부하가 발생한다면 아래와 같은 문제가 있습니다.

• 스케일 업은 비용과 한계
• 스케일 아웃은 데이터 동기화와 같은 문제

 

IO 부하를 줄이는 기술 중 하나로는 캐시가 있다고 소개합니다.

DBMS자체의 메모리를 증가 시킬 수도 있고(대부분의 DBMS는 메모리를 캐시로 이용하기도합니다.)

DB와 커넥션을 가진 웹서버에 캐시를 둬서 실제 DB와의 IO를 줄이는 방법도 있습니다.

또한 대부분의 웹서버는 리눅스 서버로 구성될 텐데

리눅스의 페이지 캐시는 대부분의 유효 데이터를 캐시할 수 있도록 설계되어 있다고합니다.

 

 

 

 

 

 

3. 국소성

국소성이란 공간적으로 멀리 떨어져있는 두 물체는 절대 서로 직접적으로 영향을 줄 수 없다는 물리학 원리를 말합니다.

이러한 국소성 개념은 대규모 서비스 구성할 때도 사용된다고 말합니다.

물리적으로 분리된 공간에 서버를 두고 서로 다른 요청타입을 처리하는 방식이 될 수 있습니다.

 

4. MySQL과 인덱스

이 책은 MySQL을 예로 들어 대규모 서비스 구성에 알면 좋을 법한 내용들을 소개합니다.

스키마 또는 인덱스 설계가 미치는 영향이 얼마나 큰 지도 알려줍니다.

 

아래와 같은 내용은 암기해둬도 좋을 것 같습니다. 아마도 면접에서도 자주 나올 법 합니다.🤔

• B트리는 하드디스크에 적합하여 DB에서 자주 사용
• B트리는 리눅스의 블록단위로 캐싱되기 때문에 탐색도 안성맞춤이다.
• B+트리는 각 노드내에 자식노드 포인터만 가짐.
  • 마지막 리프 노드에 실제 데이터를가짐.
  • 데이터 저장에 좀더 최적화.
• Join 배제 전략: 테이블 조인 대신에 Where In 절을 이용하면 동일한 결과를 얻을 수 있다.

또한 인덱스의 효과를 알고리즘에 덧붙여 소개합니다.

인덱스 탐색은 O(logN), 선형 탐색은 O(N)의 처리량을 가집니다.

참조: https://dev.to/b0nbon1/understanding-big-o-notation-with-javascript-25mc

만약 데이터(Data Input)가 100만건이라면

속도(Time) 차이는 엄청날 것입니다.

반대로 1000건 이하라면 오히려 선형탐색 O(N)이 더 빠를 수 있습니다.

(100만 데이터에서 선형탐색은 최대 100만번. 이진탐색은 로그100만(20번))

 

그 외에도 아래와 같은 연구결과를 참고해볼 수 있습니다.

• 일반적 웹어플리케이션은 참조(읽기)가 90%이다.
• 파레토의 법칙(8대2의 법칙)은 웹어플리케이션에서도 적용될 수 있다.
  • 20%의 기능이, 80%의 부하를 차지한다.
• 쓰기가 많다면 MySQL과 같은 RDBMS를 사용하지 않는 방법을 고려
  • Key/value Storage가 쓰기에 유리하다.

 

 

 

 

 

5. 마스터1 / 슬레이브3 인 이유?

이 책에서 흥미로운 정보 중 하나 였습니다.

파티셔닝 전략에서 왜 마스터 서버1대에 슬레이브 서버 3대 일까요?

이는 1대가 고장났을 때, 신규서버 복제를 위해서는 2대가 필요하기 때문이라고 합니다.

고가용성을 위한 파티셔닝에도 많은 비용이 들겠구나.. 라고 생각했습니다.😮‍💨

 

 

6. 용도 특화형 인덱스

RDB의 인덱스는 정렬, 통계, 조인 등 범용적인 목적으로 이용됩니다.

반면 역인덱싱과 같이 용도 특화형 인덱싱 개념이 존재합니다.

자연어로 된 컨텐츠로 부터 미리 인덱스를 만들어 놓고, 검색에 특화한 것도 역인덱싱의 한 종류입니다.

 

7. 마무리

포스팅에 언급했던 소주제들 이외에도 다양한 카테고리들이 있었습니다.

알고리즘, 기획, 검색엔진 구조...등

 

특히 마지막 장에서 소개하는 "검색엔진 개발 프로젝트"는

웹 개발자라면 한번쯤 볼 만한 내용이라고 생각됩니다.