리뷰

[도서리뷰] 가상 면접 사례로 배우는 대규모 시스템 설계 기초

nooblette 2023. 8. 23. 22:33

목차

    도서 정보

     

    가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24

    “페이스북의 뉴스 피드나 메신저, 유튜브, 구글 드라이브 같은 대규모 시스템은 어떻게 설계할까?”IT 경력자라도 느닷없이 대규모 시스템을 설계하려고 하면 막막하다고 느낄 수 있다. 특히나

    www.yes24.com

    배경

    사실 이 책은 어떤 특별한 계기를 통해 읽었다기보다는, 책 내용이 괜찮다고 추천을 받아 한번 읽어보자는 가벼운 마음으로 읽기 시작하였다. 처음에는 가벼운 마음으로 읽기 시작했지만 책 내용이 생각보다 방대하면서 어렵기도 했고, 복잡한 사례들 위주로 소개를 해서 읽는데에 어려움을 겪었다. 하지만 주변에 이 책을 읽는 중이라고 얘기했을때 다들 좋은 책이라고 긍정적인 신호를 보냈을 뿐만 아니라, 사례들 자체는 (어렵지만) 흥미를 유발하는 사례들 위주로 구성되어있어 즐거운 마음으로 읽었다. (여담이지만 회사에 요즘 이 책을 읽는중이라고 얘기했더니 이직 준비중이냐는 반문을 받았다 😅)

    내용

     책 초반에는 대규모 시스템의 기본적인 기능 확장 방법(수평적 확장과 수직적 확장)을 소개하였고 중후반으로 흘러가며, youtoube/facebook/cloud service 등 일상에서 흔하게 접할 수 있는 빅테크 기업들의 (특정 서비스에 대한) 다양한 유형의 대규모 시스템을 설계하는 방법에 대해 면접을 진행중인 면접자와 면접관의 대화하는 방식으로 풀어냈다. 이러한 대화 속에는 첫번째 설계안으로부터 개선사항을 탐색 및 발견하고 설계를 개선하며 고도화를 하는 과정이 포함되어있어, 책을 읽으면서 어떤 개선사항이 있고 어떻게 개선할 수 있을지 그 방법을 고민하며 읽을 수 있었다.

     하지만 이러한 면접 대화 내용과 분석 프로세스는 단순 설계 면접 뿐만아니라, 개발 업무시에도 적용하면 서비스를 개발하고 운영하는데 좋을 것 같아 큰 도움이 되었다. 책에서 소개한 가상 면접 프로세스(= 작업 단계)는 다음과 같다.

    작업 단계
    1. 문제 이해 및 설계 범위 확장
      1. 기능적 요구사항과 비기능적 요구사항 정의
    2. 개략적 설계안 제시 및 동의 구하기
    3. 상세 설계
    4. 개발 진입(개발 업무시)

    가장 기억에 남았던 사례로는 대규모 Cloud 서비스가 있었는데, 그 중 Cloud Drvie 설계시에 위의 작업 단계를 적용해보자면 다음과 같다.

     

    클라우드 드라이브 설계
    1. 문제 이해 및 설계 범위 확정
      1. 문제 이해
        1. 주요기능 : 파일 업로드, 수정, 삭제, 다운로드, 단말별 동기화, 알림(notification)
        2. 모바일 앱, 웹을 모두 지원
        3. 파일은 암호화하여 저장
        4. 파일 크기 : 10 GB제한
        5. 예상 사용자 : DAU(일간 능동 사용자)기준 1천만
      2. 기능적 요구사항과 비기능적 요구사항 정의
        1. 기능적 요구사항
          1. 파일 추가 방식 : drag and drop
          2. 파일 다운로드
          3. 파일 갱신 이력 조회
          4. 파일 공유
          5. 단말별 파일 동기화
          6. 파일 편집/삭제시 알림처리
        2. 비기능적 요구사항
          1. 강한 일관성
          2. 빠른 동기화 속도
            1. 네트워크 대역폭 최적화(모바일 데이터 플랜을 사용하는 사용자라면 네트워크를 많이 사용하는것에 좋은 사용경험을 느끼지 못할 것)
            2. 규모확장성, 대용량 트래픽도 처리가 가능해야함
            3. 높은 가용성
    2. 개략적 설계안 제시 및 동의 구하기
    3. 상세 설계
    4. 개발 진입(개발 업무일 경우)

    SNS(instagram, facebook etc..) Feed 서비스 설계에 대한 챕터 또한 인상 깊게 읽었다. 처음 이 챕터에 대한 소개만 읽고 본문을 읽기 전에, 피드 서비스를 어떻게 설계하면 좋을 고민해봤을때 내가 생각한 설계 방식은 단순하게 다음과 같았다.

    1. 사용자가 팔로우하고 있는(혹은 친구 관계인) 사용자의 목록 조회
    2. 1번단계에서 조회한 사용자들이 발행한 글을 조회
    3. 2번단계에서 작성한 글을 시간순으로 정렬하여 피드에 노출

    사용자가 적거나 피드에 노출되는 발행하는 글의 양이 적은 경우 즉, 소규모 서비스에서 위와 같은 방식은 큰 문제가 없을 것이다. 하지만 서비스가 국제적으로 인기가 있어 사용자가 5천만명이 넘어가고, 1초마다 100만건의 글이 발행된다면, 한 사용자가 팔로우하는 사용자가 1만명(책에서는 핫키(hotkey) 문제로 소개했다)을 넘어간다면, 위와 같은 방식으로 피드 서비스에 발행된 글 목록을 노출하는데에는 latency가 커지거나 DB 접근이 많이 필요하다는 등 한계가 있을 것이다.

     

    이러한 개선사항(= latecny, DB connection 등..)에 대해 책은 Kafka와 같은 이벤트 스트리밍 플랫폼을 소개하였다.

    가령, 한 작성자가 새로운 글을 발행했다고 하자. 그렇다면 이 작성자를 팔로우 하고 있는 사람의 피드에는 다음과 같은 순서로 글이 노출될 것이다.

    1. 작성자를 팔로우하고 있는(혹은 친구 관계인) 사용자의 목록 조회
    2. 1번단계에서 조회한 사용자들의 서버에 topic 발행
    3. 작성자를 팔로우하고 있는 사람은 피드 서비스에 접속하였을때 2번 단계에서 발행된 topic들을 consume

    내가 생각했던 설계 방식에 비해 DB 접근은 단 1번만 일어날 수 있도록 개선 되었고, 글 발행시에는 작성 후 topic 발행만 하면 되므로 Feed에서 발생하는 문제로부터 격리도 될 수 있다.

    물론 오랜 시간동안 접속하지 않은 휴면 사용자가 있을 경우, 불필요한 서버 리소스를 낭비한다는(접속하지 않는 서버에 topic을 지속적으로 발행) 문제도 있겠지만 두가지 방법 중 상황에 맞게 적절한 방식을 선택하면 된다.

     

    실제로 1번단계에서 작성자를 팔로우하고 있는 사용자가 1억명을 넘어간다면 팔로우 목록 조회를 하는데 시간이 오래 걸릴 것이다. 이런 이슈에 대해 facebook과 같은 대규모 SNS의 feed 서비스는 특정 팔로우수를 threshold로 두어 그 수를 넘기 전까지는 2안을, 넘는다면 1안을 채택한다고 설명해주었다.(은탄환은 없다)

     

    이처럼 현실감 넘치는 사례들을 기반으로 읽다보니 어려운 내용일지라도 흥미를 갖고 계속 읽게 되었고, 평소 생각해보지 못했던 다양한 문제에 대해 고민해볼 수 있었으며, 업무 작업 진행 방법에 대해서도 고민해볼수 있는 계기가 되었다.

    후기

    특별하지 않은 계기로 읽기 시작했지만, 다 읽고난 후에는 특별한 간접 경험들을 얻을 수 있었던 것 같다. 비록 책 내용이 어려워서 술술 읽힌다거나 쉽게 이해되지 않고, 읽는데 시간이 조금 더 걸렸지만 충분히 좋은 시간이였던 것 같다. 만일 기본적은 개발 지식을 충분히 갖고 있으며 새로운 고민을 해보고 싶다면 읽어보면 좋을 것 같다.

     

    저작자표시