가상 면접 사례로 배우는 대규모 시스템 설계 기초 리뷰 :: 마이구미

이 글은 "가상 면접 사례로 배우는 대규모 시스템 설계 기초" 라는 책을 리뷰한다.
본인은 백엔드 개발자가 아닌 프론트엔드 개발자이다.
책 링크 - http://www.yes24.com/Product/Goods/102819435

 

 

백엔드 개발자가 아니라 시스템 설계에 대한 지식은 많이 부족한 상태이다.

그래도 관심은 항상 많고 학습을 열심히 하고 있다.

그러던 중 이 책은 제목부터 흥미로웠다.

가상 면접 사례로 배우는... 

 

그리고...

페이스북의 뉴스 피드를 설계하시오, 유튜브를 설계하시오, 구글 드라이브를 설계하시오 등과 같은 매혹적인 문장들이 있다.

혹하지 않을 수 없다고 생각한다.

 

실제로도 제목과 설명은 단순히 어그로가 아니였다.

책의 내용의 흐름은 실제로 면접자과 면접관의 인터뷰 상황속에서 진행된다.

상황의 진행은 4단계로 분류되어 흘러간다.

 

• 1단계 - 문제 이해 및 설계 범위 확정
• 2단계 - 개략적 설계안 제시 및 동의 구하기
• 3단계 - 상세 설계
• 4단계 - 마무리(추가로 논의할 만한 질문)

 

위 4단계는 자연스럽게 연결되고 흥미로웠고 배울게 굉장히 많았다.

오랜만에 정말 재밌게 읽은 책이다.

대부분의 책은 목표 페이지를 정해놓고 여러번에 걸쳐 읽는다.

이 책은 목표 페이지를 훨씬 넘겨버리는 일이 계속 발생했을 정도로 재밌게 술술 읽었다.

 

디테일한 것까지는 이해할 수 없었으나, 어느 정도의 그림은 이해할 수 있을 정도로 잘 설명해주고 있다.

대규모 시스템 설계를 할 기회는 흔치 않겠지만, 읽어보면 좋은 책이라고 생각한다.

---

 

정말 많은 지식들이 있지만, 몇가지만 남겨보려한다.

 

CAP 정리(브루어의 정리)

CAP 는 다음으로 분류된다. 

 

• 일관성(Consistency) - 모든 클라이언트는 언제나 같은 데이터를 봐야한다.
• 가용성(Availability) - 클라이언트는 장애가 발생해도 항상 응답을 받을 수 있어야한다.
• 파티션 감내(Partition tolerance) - 장애가 발생해도 시스템은 계속 동작해야한다.

 

CAP 정리는 세 가지 요구사항을 만족하는 분산 시스템은 존재하지 않음을 증명한 정리이다.

두 가지를 충족하려면 나머지 하나는 반드시 희생되는 것을 의미한다.

 

세 가지 요구사항 가운데 두 가지를 만족하는 CP, AP, CA 시스템으로 분류된다.

분산 시스템에서 파티션 감내는 피할 수 없기 때문에 실세계에서는 CP, AP 시스템만 존재한다.

 

왜 일관성이나 가용성을 희생해야하는가? 예를 들면 다음과 같다.

 

세 대의 복제 노드 n1, n2, n3 에 데이터를 복제하여 보관하는 상황이 있다.

그 중 n3에 장애가 발생하여 n1, n2 와 통신할 수 없다.

이러한 상황에서 n1, n2 에 전달 못한 n3 데이터가 존재한다면, n1와 n2 는 오래된 사본을 가지고 있다.

 

가용성 대신 일관성을 선택한다면(CP 시스템) 데이터 불일치 피하기 위해 n1와 n2 에 쓰기 연산 중단해야한다.

그렇게 되면 가용성 깨지게 된다. (데이터 일관성을 양보할 수 없는 시스템은 주로 은행권으로 볼 수 있다.)

 

반대로 가용성을 선택한다면(AP 시스템), 읽기 및 쓰기 연산을 계속 허용해야해서 신선하지 못한 데이터를 반환할 위험은 있다.

 

UUID

uuid 는 고유 식별자로 일반적으로 우리가 사용하는 형태는 128bit 의 수로 32개의 문자와 4개의 하이픈으로 구성되어있다.

ex) 400cafdc-9ea3-4eaf-9ea8-bab8e10dbce2

 

기존에는 별 생각없이 사용하곤 했다.

하지만 단점으로는 시간순으로 정렬할 수 없고, 64bit 이 요구사항이라면 맞지 않다.

다른 접근 방향으로는 트위터 스노플레이크 접근법 존재한다.

 

301 와 302 상태 코드의 차이

두가지 모두 리디렉션 응답 상태 코드이다.

주로 단축 URL 에서 사용될 수 있다.

 

301 Permanently Moved - 리소스가 영구적으로 Location 헤더에 반환된 URL 로 이전되었다는 응답이다.

302 Found - 리소스가 일시적으로 이동했다는 의미로 Location 헤더에 반환된 URL 에 의해 처리되어야 한다는 응답이다.

 

301 상태 코드는 설명 그대로 "영구적" 으로 응답이 브라우저에 캐시된다.

서버 부하를 줄일 수 있다.

하지만 트래픽 분석이 필요하다면 캐시가 되지 않는 302 상태 코드를 써야한다.