🗓 어떻게 읽었나

힘들었다. 책 난이도 때문은 아니다. 오히려 지난번에 읽었던 데이터 중심 애플리케이션 설계에 비하면 훨씬 쉬운 책이었다. 그럼에도 힘들었던 이유는 평일 내내 오피스 출근 + 퇴근 후 운동 + 다른 프로젝트 및 스터디를 병행하면서 읽었기 때문이다. 하지만 이번 경험으로 시간을 쪼개서 아껴 쓰는 법을 배울 수 있지 않았나 싶다.

• 기간: 2022.08.20 - 2022.11.27
• 분량: 총 15장, 약 300페이지
• 방식: 둘째 주 제외, 1주에 1장씩.
• 누구와: J2KB에서 모은 스터디원들과.

솔직히 다른 분들과 함께 한 스터디가 아니었다면 완주하지 못했을 것 같다.😇🥲 다음번에는 좀 더 시간을 아껴서 잘 써야겠다.

💭 기억에 남는 내용

시리즈 글을 보면 알 수 있듯이, 각 챕터별로 서비스 하나를 정해서 처음부터 설계하는 식으로 구성된 책이다. 스터디원들도 공감한 내용인데 초반 내용보다 후반 내용이 재밌다. 초반에는 시스템 설계를 위한 이론적인 내용이 주를 이루지만 그런 내용은 모두 추진력을 얻기 위함이었고 후반부에서 '알림 시스템 설계', '채팅 시스템 설계'와 같이 딱 봐도 재밌어보이는 내용이 나오기 때문이다. 설계에 대한 내용은 컴퓨터공학과 수업에서 다루지 않기 때문에 + 실제 서비스가 비슷하게 생겼을거란 생각에 정말 재밌게 읽었다.

2개 이상 챕터에서 공통적으로 나온 내용

2개 이상 서비스에서 공통적으로 사용되는 컴포넌트나 기법, 혹은 주제가 있었다. 이를 정리해보면... 무려 6개나 된다.

개략적 규모 추정

2장에서 처음 소개 되고, 나머지 대부분의 장에서 등장한다.
어떤 설계가 요구사항에 적합한지 보기 위해, 일반적인 성능 수치를 가정하고 사고 실험을 하여 추정치를 계산하는 것 을 의미한다. 즉, 내가 만들 서비스가 대략 어느정도의 리소스를 잡아먹고 어느정도의 성능을 낼 것인지를 추정해보는 작업이다.

Stateful vs. Stateless 웹서버

• 1장. 규모 확장성: 웹서버가 stateless 해지면 수평적 규모 확장이 쉬워지고 로드밸런서의 부담도 줄어든다.
• 12장. 채팅 시스템 설계: 하지만 여기서는 고정 세션이 필요하다. "각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 하기 때문이다."
• 결론: 뭐든 그렇지만 case-by-case다. 알아서 잘 사용해보자.^^

처리율 제한 장치

• 4장. 처리율 제한 장치: 첫 등장
• 11장. 뉴스 피드 시스템 설계: 인증되지 않은 사용자가 피드를 발행하는걸 막기 위해 사용했다.
• 사실 어뷰징 방지 목적으로 대부분의 서비스에서 사용되고 있을 컴포넌트다.

HeartBeat 알고리즘

• 6장. 키-값 저장소 설계: 노드에서 다른 노드로 주기적으로 자신의 상태 전파.
  • 분산 환경에서 누가 죽었는지 판단하기 위해 사용했다.
• 12장. 채팅 시스템 설계: 클라이언트에서 서버로 주기적으로 자신의 상태 전파.
  • 유저 접속 정보('접속 중', '오프라인', ...)를 알리기 위해 사용했다.

안정 해시 알고리즘

• 5장. 안정 해시 설계: 첫 등장
  • 아마존 다이나모 DB, 아파치 카산드라 클러스터, 디스코드 등 실제 애플리케이션에서 널리 쓰인다고 했다.
• 6장. 키-값 저장소 설계: 데이터 파티셔닝을 위해
  • 어떤 데이터가 어떤 파티션에 저장될 지 효과적으로 결정하는 기법으로 소개되었다.
• 9장. 웹 크롤러 설계: HTML 다운로더 서버의 부하 분산을 위해
  • 크롤링을 위해 각 사이트의 HTML를 다운로드하는 서버가 필요한데, 이 서버의 부하 분산을 위해 사용되었다.

롱 폴링

• 12장. 채팅 시스템 설계: 클라이언트 - 서버 간 통신.
  • 웹소켓은 이런 양방향 시스템일 때 필요하다.
• 15장. 구글 드라이브 설계: 파일이 변경되었음을 알리기 위해 서버 to 클라이언트 통신.
  • 양방향 통신이 필요없기 때문에 굳이 웹소켓을 쓸 필요는 없다.

해시 값 비교

• 6장. 키-값 저장소 설계: 해시 트리(=머클 트리)
  • 영구적 장애가 발생했을 때, 변경된 부분만 동기화할 수 있도록 어디가 변경되었는지 확인할 때 사용했다.
• 15장. 구글 드라이브 설계: 여러명이 동시에 편집해서 파일 하나의 복사본이 여러개 생긴 경우, 중복된 파일 블록을 빠르게 제거하기 위해 사용했다.

⭐️ 제 점수는요..

대략 4.2점/5점 정도? 이유는 다음과 같다.

좋은점

주제의 신선함

위에서 언급했듯, 책 내용 자체가 대학교 강의에서 쉽게 들을 수 있는 내용이 아니다. 물론 개별 서비스에 대한 설계는 유투브에 치면 잘 나오지만, 이걸 체계적으로 묶고 초반 빌드업을 통해 독자들을 이해시키기 위한 책이 있다는 사실에 꽤 높은 점수를 주고 싶다.

일관성 있고 깔끔한 설명

책 중간중간에 그림이 많이 나온다. 설계 관련 내용은 그림이 없으면 이해하기 쉽지 않은 경우가 있는데, 직관적이고 깔끔한 그림 덕분에 이해가 한층 수월했다. 각 그림에 대한 설명도 구체적이어서 좋았다.
후반부 각 서비스별 설계 파트는 대부분 개략적 규모 추정 - 전체적인 설계 - 세부 컴포넌트 설계 순서로 진행되었다. 전체를 먼저 보고 부분을 보는 구성 덕분에 이해하기 쉬웠던 것 같다. 좋은 개발자의 덕목 중 하나인 '일관성 있게 처리하기' 도 잘 지켜줘서 마음에 들었다.

수많은 레퍼런스

각 장이 끝날 때마다 참고 문헌과 링크를 걸어놓았다. 책 마지막 장은 사실 15장이 아닌 16장인데, 여기서는 더 읽어볼만한 글이나 블로그 링크를 잔뜩 소개하고 있다. 아직 다 읽어보진 못했지만 시간이 된다면 더 읽어보고 싶다.

개선점

후반부에서 종종 있었던 제목 낚시

'구글 드라이브 설계' 라고 제목을 지어놓았길래 '오 드디어 구글 드라이브의 공유 문서 동시 편집 기능을 뜯어볼 수 있는건가!!'하고 설렜는데 막상 이 내용만 쏙 빼놓았다던가(그래서 15장은 대충 읽었고 포스팅도 스킵해버렸..다는 핑계를 대어본다.;), '유투브 설계' 라는 제목을 하고선 사실상 '비디오 업로드 시스템 설계'에 대한 내용만 적어놓는 등 제목 낚시를 한 장이 좀 있다. 11장 뉴스 피드 시스템 설계에선 이런 말을 했을 정도..ㅋㅋ

👥 스터디 후기

• 인원: 3명

특정 프레임워크나 언어에 대한 스터디가 아니라서 아무도 관심을 주지 않으면 혼자 할 각오로 모집한 스터디였는데, 의외로 2분이나 신청해주셨다. 게다가 다들 의욕적으로 참여해주셔서 많은 자극을 받을 수 있었다.

꽤 괜찮은 방법 발견

처음에는 이렇게 진행했다.

각자 1주일 분량 공부해서 정리 글 적고, 스터디 발표 당일 사다리타기를 통해 발표자 정하기

그런데 이런 단점이 있었다.

• 한 사람만 자꾸 걸린다. (실제로 3주인가 4주 연속 걸린 분이 계셨다.)
• 학습을 위한 스터디가 아닌 정리를 위한 스터디가 된다.
• 스터디 당일에는 서로 배운걸 공유한다기보다, 발표자만 바쁜 스터디가 된다.

그래서 이렇게 바꿔보았다.

각자 1주일 분량 공부해서 새롭게 알게 된 점, 어려웠거나 이해 못 한 부분, 추가 내용 정리하기. 새롭게 알게 된 점은 최대한 간단히 적고 스터디 당일에 어려웠거나 이해 못 한 부분, 추가 내용 위주로 서로 의견 나누기.

결과는 꽤 좋았는데

• 두번째 항목이 없었더라면 뭔가 애매하고 두리뭉술하게 이해하고 넘어갔을만한 내용도 확실히 짚고 넘어갈 수 있었고
• 추가 내용에 직접 코드를 적어서 진행한 프로젝트나 정오표, 이번 장과 관련된 흥미로운 글 등을 소개하면서 활발한 공유가 이루어졌다.

딱 3~4명 같은 소수 인원에서 진행하기 괜찮은 방법인 것 같다.

🌞 결론

• 시스템 설계에 대한 설명 방식과 구성 자체가 꽤 좋았던 책.
• 바쁜 일정에 두꺼운 책 끝까지 읽고 싶다면 스터디도 괜찮다.