대규모 서비스, Scalability한 서비스 관련

대규모 서비스

• 대량의 데이터를 처리하는 서비스
  • DB의 데이터 규모 : 기가바이트 ~ 테라바이트
• 보통 서버 대수로 개략적으로 파악하는 경우가 많다. 수백대 ~ 수천대의 서버
• 책에서 본 대규모 서비스 회사인 하네타 예시에서는 월간 1500만명 이상이 이용
• → 배민은 월 사용자수가 2천만명 이상

소규모 서비스와 대규모 서비스의 차이

혼자서, 소수만 이용하는 소규모 서비스에서는 대규모 서비스를 경험할 수 없다.

소규모 서비스에는 없는 대규모 서비스의 어려움이 있다.

• 확장성 Scalability : 규모적 확장성과 부하 처리
  • 간단 정의 : 서버나 DB와 같은 시스템들을 갯수를 늘리거나 성능을 높이는 규모적 확장성을 통해 부하를 처리하는 수용 능력
  • 설명 : 부하(자원 : 데이터, 메모리, cpu 등)가 있을 때 이를 다 처리할 수 있는 수용 능력으로, 애플리케이션이나 데이터베이스와 같은 시스템의 크기를 키우거나, 갯수를 늘려서 모두 다 처리하도록 하는 능력 ( 규모적 확장하여 부하를 분산하는 것 )
  • ex) Scale out 과 LoadBalancer, 샤딩, Replication
    
• 가용성 : 항상 이용 가능. 장애가 나도 빠른 대응. 전면 장애가 일어나면 안된다.
  • ex) replication, MSA
• 신뢰성 : 어떤 데이터를 검색했을 때 항상 그 결과가 반환된다는 신뢰를 얘기.
  • ex) Look aside 캐시 구조, Session Storage 같은 데이터 정합성 문제를 해결하기 위한 노력
• 성능 : 빠른 응답시간

Scalability : 규모적 확장성과 부하 처리

부하가 있을 때 이를 다 수용할 수 있는 서비스로, DB 나 서버 갯수를 늘리거나 성능을 높이거나 해서 이들을 다 처리할 수 있는 서비스이다.

부하란 것은 시스템에서 어떤 기능을 하기 위해서 필요한 자원이라고 생각한다.

예를 들어 회원가입이라는 클라이언트 요청이 들어왔을 때 스레드가 메모리에 있고, CPU 작업을 하거나 DB작업을 하고나 네트워크 통신을 하거나 이런 자원들을 부하의 예시라고 들 수 있다. 중요한것은 이러한 부하는 특정한 기준치 이하에서만 정상적으로 작동한다는 것이다

Scalability : Access 계층

외부로부터 들어오는 사용자 요청에 대한 창구와 같은 열할을 하며 외부 시스템과의 연동 역할을 한다.
ex) API Gateway, Load Balancer

Load Balancer

• 확장성 있는 분산 서버 환경에서 로드밸런서를 통해 트래픽을 분산할 수 있다.
• 4계층의 L4 로드밸런싱은 TCP, UDP를 기반으로 로드밸런싱을 수행한다.
• 7계층의 L7 로드밸런싱은 HTTP와 같은 응용 계층 프로토콜 정보를 기반으로 로드밸런싱을 수행한다. URI 같은 정보를 기반으로 프토토콜을 이해한 후 부하를 분산할 수 있다.

로드 밸런스 알고리즘

• 라운드 로빈 Round Robin: 현재 구성된 장비에 요청을 순차적으로 분산함.
  • 장점 : 들어오는 모든 요청이 모든 서버에 골고루 나눠진다.한쪽으로 쏠리지 않음.서버 낭비안됨
  • 단점 : session 데이터 관리
• 최소 접속 방식 Least Connection : 현재 구성된 장비 중 처리하고 있는 요청 수가 적은 서버로 부하를 분산함
  • 로드밸런스에서 서버로 요청을 보낼 때 각 서버에 연결된 현재 요청 수를 알 수 있다. 각 장비의 요청 수를 확인 해 현재 세션이 가장 적게 연결된 장비로 서비스 요청을 보내는 방식
  • 서비스별로 세션 수를 관리하면서 분산해주므로 각 장비에서 처리되는 활성화 세션 수가 비슷하게 분산되면서 부하를 분산하게 된다
  • 단점 : session 데이터 관리, 서버에 실제 접속한 요청 수를 세어야 한다
  • 장점 : 고르게 부하 분산. 만약에 요청이 무거운 요청, 가벼운 요청이 마구 들어올 경우 무거운 요청을 적절히 분배해줄 때는 고르게 부하 분산되서 효과가 좋을 듯 하다.

API Gateway

• 설명 : 클라이언트가 직접 서비스에 접근하지 않고, 필요한 서비스로 요청을 전달해는 창구와 같은 역할을 하는 서비스
• 기능
  1. 요청 라우팅 : 라우팅 맵을 찾아보고 어느 서비스로 요청을 보낼지 결정한다.
     • 라우팅 맵 : HTTP 메서드와 서비스의 HTTP URL을 매핑한 것이다.
     • = nginx과 같은 웹 서버의 리버스 프록시 ( 클라이언트가 리버스 프록시를 서버인 것 처럼 호출하고 리버스 프록시는 내부망에 위치한 적절한 서버로 요청을 라우팅하여 그 결과를 취합한 후 다시 클라이언트로 돌려주는 방식 )
  2. API 조합 : 클라이언트가 하나의 API요청시 여러 서비스에서 데이터를 가져와 조합한다
  3. 프로토콜 변환 : Rest API 와 내부 gRPC API 변환을 한다
• 장점
  • 애플리케이션 내부 구조를 캡슐화하는 것
    • 클라이언트는 특정 서비스를 호출할 필요없이 무조건 게이트웨이에 이야기하면 된다
  • API 게이트웨이는 클라이언트마다 최적의 API를 제공하므로 클라이언트 - 애플리케이션 간 왕복 횟수도 줄고 클라이언트 코드 역시 단순해진다
• 단점
  • 개발 병목 지점이 될 수 있다.
    • 개발자가 자신의 서비스 API 를 표출하려면 반드시 API 게이트웨이를 업데이트해야하는데, 업데이트가 오래걸린다면 여러 개발자가 줄 서서 기다릴 것이다.
      • → 문제는 여러 팀이 모두 API Gateway를 사용한다면 MSA의 철학인 서비스 별로 팀을 꾸리는 것이 사라지고, API Gateway 팀이라는 게 존재해버린다. 즉 철학과 맞지 않게 됨
      • → 해결책은 BFF ( Backends for frontends, 프론트엔드를 위한 백엔드 ) 패턴을 이용하여 클라이언트 종류별로 API 게이트웨이를 따루두고, 각 팀이 관리해야한다. ( ex) 모바일 클라이언트 팀 - 모바일 클라이언트용 API Gateway 관리 )

Scalability : Web 계층

사용자 요청에 대한 비즈니스 로직을 처리하여 응답을 준다
ex) Scale up, Sclae out

Scalability : DB 계층

비즈니스 로직에 의해 처리되는 데이터를 저장하는 역할을 한다.
ex) 샤딩, Replication

샤딩

• 샤딩 : 데이터를 여러 개의 데이터베이스에 나눠 담는 방법

  • 가장 고려해야할 것 : 샤딩 키를 어떻게 정할 것이냐

    • 샤딩 키는 데이터가 어떻게 분산될지 정하는 하나 이상의 칼럼으로 구성된다

  • 수직적 샤딩 : 연속된 데이터에 대해서 범위별로 데이터를 나누는 방법

    • ex) id

  • 수평적 샤딩 : 연속된 키나 데이터가 아니라 Category 종류에 따라서 데이터를 수평적으로 분리하는 것

    • ex) 한식, 중식, 양식

  • 단점 : 샤딩을 도입하게 되면 시스템이 복잡해지고 풀어야할 문제가 많이 생기게 된다

    1. 데이터 로컬리티
       • 연산하려는 데이터가 멀리 있을 수록 시스템 성능은 떨어진다. 비용이 높은 네트워크를 이용한 읽기
    2. 데이터의 재샤딩 문제
       • 데이터가 너무 많아져서 하나의 샤드로는 더이상 감당하기 어려울 때
       • 샤드 소진 : 샤드 간 데이터 분포가 균등하지 못해 데이터가 몇명의 샤드에만 몰려있을 때
         • 해결책 : 샤드 키를 계산하는 함수를 변경하고, 데이터를 재배치한다. 이를 consistent hashing 이라고 한다
    3. 유명 인사 문제 celebrity
       • 핫스팟 키 hotspot key 문제라고도 부르는데,
       • 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제이다
       • 예를 들어 케이티 페리, 저스틴 비버, 레이디가가 같은 유명인사가 같은 샤드에 저장되는 데이터베이스가 있다고 해보자. 이 데이터로 SNS 서비슬ㄹ 만들때 사용하게 되면, 결국 해당 샤드에는 read연산이 과부하가 걸리게 될 것이다. 이 문제를 풀려면 다시 샤드를 나눠야된다
    4. 조인과 비정규화 문제
       • 다른 샤드 간의 데이터 조인은 불가능
         • 해결책은 데이터베이스를 비정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 하는 것이다

Replication

• Replication : 한 서버에서 다른 서버로 데이터가 동기화되는 것으로. 확장성 Scalability와 가용성 Availability를 위해서 일반적으로 사용되는 기술.
• 데이터 원본은 master서버에, 사본은 slave 서버에 저장하는 방식
  • 마스터에 쓴 내용을 슬레이브가 폴링polling해서 동일한 내용으로 자신을 갱신하는 기능
• 쓰기 연산(insert, update, delete )은 master에서만, 읽기 연산은 slave 에서만.
  • 이유 : 읽기 연산의 비중이 높기 때문에 읽기용 서버를 늘리는 것
• 장점
  • 단일 고장점을 없애서 장애 대응 : 하나의 데이터베이스에 장애가 발생하더라도 다른 서버에 있는 데이터를 가져와 계쏙 서비스를 할 수 있다
    • master가 다운 : slave가 master가 됨
    • slave가 다운 : master가 한시적으로 읽기도 수행 or 다른 slave 정상 동작
  • 읽기와 쓰기가 분리되어서 부하도 분산된다. 병렬로 처리될 수 있는 쿼리 수가 늘어나므로, 성능이 좋아진다
• 단점
  - 데이터량이 많아진다.
  - 내 생각) 데이터 정합성 문제가 많아진다?? : 어떤 데이터가 업데이트되려할 때, 업데이트 요청보다 읽기 요청이 먼저 발생했다면 해당 데이터는 비정합성상태가 된다. 해결책은...?? 친구 의견으로는 프라이머리 세컨드 구조의 단순 이중화라면, 데이터 쓰기 읽기 간의 짧은 시간 발생하는 정합성 불일치 문제는 프라이머리 DB를 직접 읽도록 하면 된다고 함. 내 생각으로는 뭔가..DB가 하나인 경우에는 Exclusive lock 쓰기 잠금을 통해 쓰기 시에 읽을 수 없도록 하는 걸 분산 DB환경에서 적용해야 될 것 같은데..흠..

Extensibility

서비스에 더 많은 기능을 쉽게 추가하는 능력
-> 새로운 기능을 추가해도 이전 코드에 변경이 일어나지 않는지
-> 클래스간 결합도?

클론 코딩

• 배달의 민족, 자소설닷컴 클론 코딩
• 사람들이 많이 사용
• 소규모 → 대규모 서비스 가는 대표 앱. 어떤 부분을 고려해야할 지 좀 더 명확히 파악할 만한 자료가 많아서 선택되었다.
• 소규모 서비스에서 대규모서비스로 가는 대표적인 앱 중에 하나인데
• 그 과정에서 겪었던 시행착오나 이슈들이 지표도 많고 기록도 있고 하기 때문에
• 이러한 기록을 통해 내가 서비스의 규모를 점점 키울 때 어떤 부분을 더욱 신경써야하는 지 객관적인 수치로 알 수 있기 때문이다.

참고

책 웹 개발자를 위한 대규모 서비스를 지탱하는 기술
책 가상 면접 사례로 배우는 대규모 시스템 설계 기초
Microservices Pattern: API gateway pattern