MySQL 스케일링

비즈니스가 빠르게 성장하는 환경에서는 트래픽 증가, 환경 복잡, 데이터 요구 사항 증가 등이 발생할 수 있음.

스케일링이란?

스케일링(Scaling)

• 증가하는 트래픽을 지원하는 시스템의 기능.
• 시스템의 확장성이 좋은지 나쁜지에 대한 기준은 비용과 단순성으로 측정 가능. 확장 능력을 높이는데 너무 많은 비용이 들거나 복잡하면 이 문제를 해결하는데 더 많은 노력을 들일 수 있음

용량(Capacity)

• 주어진 시간 내에 수행할 수 있는 일의 양.
• 시스템의 최대 처리량이 용량과 같다고 볼 수는 없음. 실제 용량은 수용 가능한 성능을 제공하면서 달성할 수 있는 처리량으로 정의
• 거시적인 관점에서 확장성은 리소스를 추가하여 용량을 추가할 수 있는 능력을 의미.

스케일링 문제의 다양한 형태

• 데이터의 양: 너무 많은 데이터의 양은 가장 일반적인 스케일링 문제 중 하나
• 사용자 수: 각 사용자의 데이터 양이 적더라도 사용자가 많으면 데이터가 누적됨. 사용자가 많다는 것은 일반적으로 더 많은 트랜잭션, 더 복잡한 쿼리를 의미.
• 사용자 활동: 사용자가 좋아하는 새로운 기능으로 인해 사용자가 갑자기 활성화되면 부하가 증가할 수 있음. 페이지 조회수뿐만 아니라 페이지 보기를 생성하는데 더 많은 작업이 필요한 사이트가 사용되면 많은 작업이 발생할 수 있음
• 관련 데이터 세트의 크기: 사용자 간에 관계가 있는 경우 관련 사용자의 전체 그룹에 대해 쿼리 및 계산을 실행해야 함

읽기 대 쓰기 바운드 워크로드

• 데이터베이스 아키텍처 확장을 고려할 때 읽기 바인딩된 워크로드 또는 쓰기 바인딩된 워크로드 중 어느 쪽을 확장할지 검토해야 함.
• 읽기 바인딩 워크로드는 읽기 트래픽(SELECT) 양이 서버의 용량을 압도하는 워크로드.
• 쓰기 바인딩 워크로드는 DML(INSERT, UPDATE, DELETE)을 처리할 서버의 용량을 초과.

워크로드의 이해

• 데이터베이스 워크로드는 여러가지임
• 사용자의 능력, 즉 시간 경과에 따른 작업량
• 데이터베이스의 경우 일반적으로 초당 쿼리 수로 요약됨
• 워크로드의 정의 중 하나는 시스템이 수행할 수 있는 QPS(Queries Per Second). 그러나 이것에 너무 집착할 필요는 없음. 20% CPU에서 1000개의 QPS를 사용한다고 해서 항상 QPS를 더 추가할 수 있다는 것은 아님. 모든 쿼리가 동일하지는 않음
• 각각의 쿼리에는 이와 관련된 비용이 있음. 이 비용은 CPU 시간 또는 지연 시간으로 측정. 쿼리가 디스크에서 정보를 반환하기 위해 더 오래 기다리면 해당 시간에 비용이 추가.
• 워크로드는 모든 유형의 쿼리와 지연 시간이 혼합된 것. CPU의 20%에서 1000개의 QPS를 처리하는 경우 동일한 지연 시간으로 4000개의 QPS를 추가할 수 있음. 4000개의 쿼리를 추가로 도입 후 디스크 IOPS(Input/Output Operations Per Second: 저장 장치의 성능 측정 단위)에 도달하면 병목 현상이 발생하여 모든 읽기 지연 시간이 늘어남
• 읽기 대 쓰기 성능을 확인하면(3장에서 나옴) 읽기 또는 쓰기 지연 시간이 증가하고 있는지 확인 가능, 어디가 제한적인지 알 수 있음

읽기 바운드 워크로드

• 모든 데이터베이스 트래픽에 대해 하나의 소스 호스트를 사용했다고 했을 때 읽기 요청에 응답시 기능에 제한을 받을 수 있음.
• 주요 지표로는 CPU 사용률이 있음. CPU 사용률이 높다는 것은 서버가 쿼리를 처리하는 데 많은 시간을 소비하고 있음을 의미. 쿼리에서 더 많은 지연 시간이 표시됨.
• 디스크읽기 IOPS 또는 처리량도 많은 것을 볼 수 있음. 디스크를 매우 자주 읽거나 디스크에서 많은 행을 읽고 있다는 것을 나타냄
• 인덱스 추가, 쿼리 최적화, 캐싱 등으로 처음에 이를 개선할 수 있음
• 위의 방법을 모두 썼다면 읽기 바인딩된 워크로드가 남게 되며 레플리카를 사용하여 읽기 트래픽을 확장해야 함

쓰기 바운드 워크로드

• 쓰기 바인딩된 데이터베이스 로드의 몇 가지 예
  • 회원 가입이 기하급수적으로 증가
  • 전자상거래의 성수기. 주문수와 매출 증가
  • 선거철이라 선거운동 후보가 많이 뜨고 있음
• 단일 소스 데이터베이스는 한동안 수직 확장이 가능하더라도 어느 수준까지만 확장됨. 병목이 쓰기 볼륨인 경우 개별 하위집합에서 병렬로 쓰기를 수용할 수 있게 데이터를 분할하는 방법을 생각해야 함

만약 읽기, 쓰기 두 가지 유형의 성장이 모두 보인다면?

• 스키마를 면밀히 검사하고 읽기에서 더 빠르게 성장하는 테이블이 있는지, 쓰기 요구량이 증가하는 다른 하위 집합이 있는지 확인하는 것이 중요.
• 데이터베이스 클러스터를 동시에 확장하려면 많은 사고와 문제 발생. 읽기 및 쓰기를 독립적으로 확장하려면 서로 다른 기능 클러스터에서 테이블을 분리하는 것이 좋음

기능적 샤딩

• 비즈니스에서 ‘기능’을 기반으로 데이터를 분할하려면 데이터가 무엇인지 깊은 이해가 필요
• 각 테이블을 자체 ‘기능적’ 데이터베이스에 넣는다면 너무 많은 단편화로 모든 것을 악화시킬 수 있음
• 대규모 단일/혼합 데이터베이스를 합리적인 소규모 클러스터 세트로 분할하려면 아래와 같은 지침 필요
  • 엔지니어링 팀의 구조에 따라 나누면 안된다. 그 구조는 어느 순간 바뀐다
  • 비즈니스 기능에 따라 테이블을 분할한다. 계정 등록을 지원하는 테이블은 기존 고객 설정을 호스팅하는 테이블과 분리될 수 있다.
  • 데이터에 별도의 비즈니스 문제가 뒤섞이는 것을 두려워하지 않아도 된다.

읽기 풀로 읽기 스케일링

가상 IP를 사용하여 읽기 전용 레플리카에 액세스하는 애플리케이션 노드

• 레플리카를 읽기 요청을 처리하는데 사용할 수 있음
• 위의 이미지처럼 동일한 애플리케이션 노드가 가상 IP에 연결되어 해당 노드와 읽기 전용 레플리카 사이의 중간 계층 역할을 함. 증가하는 읽기 로드를 둘 이상의 호스트로 분산할 수 있음
• 일반적으로 로드 밸런서를 사용하여 읽기 레플리카로 전송되는 모든 트래픽의 중개자 역할을 하는 가상 IP를 실행함
• 이를 위한 기술로 HAProxy, 자체 호스팅을 하는 경우 하드웨어 로드밸런서, 퍼블릭 클라우드 환경에서 실행 중인 경우 네트워크 로드 밸런서가 있음

읽기 풀 구성 관리

• 로드밸런서를 사용하여 읽기 풀에 포함되거나 포함되지 않은 노드를 쉽게 관리할 수 있는 방법이 필요.
• 수동으로 관리하면 실수, 장애 등이 발생할 수 있으므로 서비스 검색 솔루션을 기술 스택의 일부로 배포하거나 클라우드 공급자의 관리형 서비스 검색 옵션을 선택하여 읽기 풀 구성을 자동으로 관리하는 것이 필요함
• 읽기 전용 레플리카를 이 읽기 풀에 적합하게 만드는 기준을 매우 구체적으로 지정해야 함.

읽기 풀에 대한 상태 확인(Health checks)

• 읽기 레플리카가 정상이고 애플리케이션에서 읽기 트래픽을 허용할 준비가 되었다고 간주하는 허용 가능한 기준이 무엇인지 고려해야 함.
• ‘데이터베이스 프로세스가 실행 중이고 포트가 응답한다’ 처럼 간단할 수도 있고 ‘데이터베이스가 실행중이고 복제 지연 시간이 30초 이하이며 읽기 쿼리가 100ms 이하의 지연 시간으로 실행되어야 한다’와 같이 복잡해질 수도 있음
• 대부분의 경우 포트 검사만 사용하여 MySQL 프로세스가 활성 상태이며 연결을 허용할 수 있는지 확인 가능

로드 밸런싱 알고리즘 선택

• 무작위: 로드 밸런서는 사용 가능한 서버 풀에서 무작위로 선택한 서버로 각 요청을 보냄
• 라운드 로빈: 로드 밸런서는 A, B, C, A, B, C 등의 반복적인 순서로 서버에 요청을 보냄
• 가장 적은 연결: 다음 연결은 활성화된 연결이 가장 적은 서버로 이동
• 가장 빠른 응답: 요청을 가장 빨리 처리한 서버가 다음 연결을 수신. 풀에 빠르고 느린 시스템이 혼합되어 있을 때 잘 작동할 수 있음. 그러나 쿼리 복잡성이 다영한 SQL에서는 까다로움
• 해시: 로드밸런서는 연결의 소스 IP 주소를 해시하여 풀의 서버 중 하나에 매핑. 동일한 IP 주소에서 연결 요청이 올 때마다 로드 밸런서는 이것을 동일한 서버로 보냄. 바인딩은 풀의 머신 수가 변경되는 경우에만 변경
• 가중치: 로드 밸런서는 다른 여러 알고리즘을 조합하여 가중치를 추가할 수 있음
• 가장 적합한 알고리즘은 워크로드에 따라 다름. 쿼리 로드가 높을 때, 스키마 변경을 수행할 때, 비정상적으로 많은 수의 서버가 오프라인 상태가 될때 등 다양한 상황에서 실험을 해봐야 함

대기열

• 쓰기 크기를 직접 조정하는 방법을 찾기 전에 대기열을 통해 쓰기 트래픽 증가를 보다 쉽게 관리할 수 있는 위치를 확인할 수 있음.
• 쓰기 요청의 일부를 대기열에 배치하고 데이터베이스에 직접 과부하를 초래하지 않는 속도로 요청을 처리할 수 있음.
• 쓰기 로드에 대기열을 적용하는 경우 대기열에 배치된 후 이러한 호출이 수행될 것으로 예상되는 원하는 시간 범위를 미리 결정하고 모니터링해야 함

샤딩으로 쓰기 스케일링

• 쿼리를 최적화하고 대기열을 이용해도 쓰기 트래픽 증가를 관리할 수 없는 경우 샤딩이 다음 옵션
• 샤딩은 더 많은 소스 호스트에서 동시에 더 많은 쓰기를 실행할 수 있도록 데이터를 각기 다른 더 작은 데이터베이스 클러스터로 분할하는 것.
• 샤딩 또는 파티셔닝에는 기능적 파티셔닝과 데이터 샤딩이 있음
  • 기능적 파티셔닝: 다른 노드를 다른 작업에 할당하는 것. 사용자 레코드를 한 클러스터에 배치하고 청구서를 다른 클러스터에 두는 예시가 있음. 이 접근방식을 통해 각 클러스터를 독립적으로 확장할 수 있음
  • 데이터 샤딩: 보편적이고 성공적인 접근 방식. 데이터를 더 작은 조각 또는 샤드로 분할하고 다른 노드에 저장함으로써 데이터를 샤딩. 블로그 서비스를 구축한다고 했을 때 1000명의 사용자가 있다면 사용자 등록 정보를 분할할 필요가 없지만 5억명의 사용자가 예상된다면 샤딩해야 함
• 필요한 부분만 샤딩할 경우 빠르게 증가하는 데이터뿐만 아니라 논리적으로 이에 속하고 정기적으로 쿼리될 데이터도 고려해야 함

분할 방식 선택

• 샤딩의 가장 중요한 과제는 데이터를 찾고 검색하는 것. 데이터를 찾는 방법은 샤딩 방법에 따라 다름.
• 가장 중요하고 빈번한 쿼리가 가능한 적은 수의 샤드를 사용하는 것이 목표.
• 이 프로세스에서 가장 중요한 부분은 데이터에 대한 파티셔닝 키를 선택하는 것. 파티셔닝 키는 각 샤드에 어떤 행을 넣을지 결정함
• 좋은 파티셔닝 키는 일반적으로 데이터베이스에서 매우 중요한 엔티티의 기본 키. 이 키가 샤딩 단위를 결정. 예를 들어 사용자 ID 또는 클라이언트 ID로 데이터를 분할할 경우 샤딩 단위는 사용자 또는 클라이언트
• 엔티티-관계 다이어그램 등을 통해 데이터 모델을 도식화하여 파티셔닝 키 후보를 찾을 수 있음.
• 연결 정도에 따라 일부 데이터 모델은 다른 모델보다 샤딩하기 쉬움

샤딩하기 용이한 모델과 여려운 모델

• 파티셔닝 키를 선택할 때는 샤드 간 쿼리를 최대한 피하면서 불균형하게 큰 데이터 청크 때문에 문제가 없을 정도로 샤드를 작게 만드는 것이 좋음

다중 파티셔닝 키

• 데이터모델이 복잡한 경우 둘 이상의 파티셔닝 키를 가질 수도 있음.
• 예를 들어 블로그 애플리케이션의 데이터를 사용자 ID와 게시물 ID로 분할해야 할 수 있음. 사용자에 대한 모든 게시물에 게시물에 대한 모든 댓글을 보고싶어 하는 경우가 있음
• 사용자별 샤딩만 하면 게시물에 대한 댓글을 찾는데 도움이 되지 않고 게시물별로만 하면 사용자의 게시물을 찾는데 도움이 되지 않음. 두가지 유형의 쿼리가 모두 필요한 경우 두가지 방식으로 샤딩해야 함

샤드 간의 쿼리

• 애플리케이션에서 단일 쿼리로 간주하는 것을 분할하고 샤드 당 하나씩 여러 개의 쿼리를 병렬로 분할하고 실행하는 것이 데이터 샤딩 구현의 어려운 부분.
  • 샤딩의 가장 중요한 과제는 데이터를 찾고 검색하는 것. 데이터를 찾는 방법은 샤딩 방법에 따라 다름.
  • 가장 중요하고 빈번한 쿼리가 가능한 적은 수의 샤드를 사용하는 것이 목표.
  • 이 프로세스에서 가장 중요한 부분은 데이터에 대한 파티셔닝 키를 선택하는 것. 파티셔닝 키는 각 샤드에 어떤 행을 넣을지 결정함
  • 좋은 파티셔닝 키는 일반적으로 데이터베이스에서 매우 중요한 엔티티의 기본 키. 이 키가 샤딩 단위를 결정. 예를 들어 사용자 ID 또는 클라이언트 ID로 데이터를 분할할 경우 샤딩 단위는 사용자 또는 클라이언트
  • 엔티티-관계 다이어그램 등을 통해 데이터 모델을 도식화하여 파티셔닝 키 후보를 찾을 수 있음.
  • 연결 정도에 따라 일부 데이터 모델은 다른 모델보다 샤딩하기 쉬움우수한 데이터베이스 추상화 계층은 이러한 문제를 완화하는데 도움이 되지만 이러한 쿼리는 샤드 내 쿼리보다 훨씬 느리고 비용이 많이 들기 때문에 보다 적극적인 캐싱도 필요함스케일링이란?
    • 증가하는 트래픽을 지원하는 시스템의 기능.
    • 시스템의 확장성이 좋은지 나쁜지에 대한 기준은 비용과 단순성으로 측정 가능. 확장 능력을 높이는데 너무 많은 비용이 들거나 복잡하면 이 문제를 해결하는데 더 많은 노력을 들일 수 있음
    용량(Capacity)
    • 주어진 시간 내에 수행할 수 있는 일의 양.
    • 시스템의 최대 처리량이 용량과 같다고 볼 수는 없음. 실제 용량은 수용 가능한 성능을 제공하면서 달성할 수 있는 처리량으로 정의
    • 거시적인 관점에서 확장성은 리소스를 추가하여 용량을 추가할 수 있는 능력을 의미.
    스케일링 문제의 다양한 형태
    • 데이터의 양: 너무 많은 데이터의 양은 가장 일반적인 스케일링 문제 중 하나
    • 사용자 수: 각 사용자의 데이터 양이 적더라도 사용자가 많으면 데이터가 누적됨. 사용자가 많다는 것은 일반적으로 더 많은 트랜잭션, 더 복잡한 쿼리를 의미.
    • 사용자 활동: 사용자가 좋아하는 새로운 기능으로 인해 사용자가 갑자기 활성화되면 부하가 증가할 수 있음. 페이지 조회수뿐만 아니라 페이지 보기를 생성하는데 더 많은 작업이 필요한 사이트가 사용되면 많은 작업이 발생할 수 있음
    • 관련 데이터 세트의 크기: 사용자 간에 관계가 있는 경우 관련 사용자의 전체 그룹에 대해 쿼리 및 계산을 실행해야 함
    읽기 대 쓰기 바운드 워크로드
    • 데이터베이스 아키텍처 확장을 고려할 때 읽기 바인딩된 워크로드 또는 쓰기 바인딩된 워크로드 중 어느 쪽을 확장할지 검토해야 함.
    • 읽기 바인딩 워크로드는 읽기 트래픽(SELECT) 양이 서버의 용량을 압도하는 워크로드.
    • 쓰기 바인딩 워크로드는 DML(INSERT, UPDATE, DELETE)을 처리할 서버의 용량을 초과.
    워크로드의 이해
    • 데이터베이스 워크로드는 여러가지임
    • 사용자의 능력, 즉 시간 경과에 따른 작업량
    • 데이터베이스의 경우 일반적으로 초당 쿼리 수로 요약됨
    • 워크로드의 정의 중 하나는 시스템이 수행할 수 있는 QPS(Queries Per Second). 그러나 이것에 너무 집착할 필요는 없음. 20% CPU에서 1000개의 QPS를 사용한다고 해서 항상 QPS를 더 추가할 수 있다는 것은 아님. 모든 쿼리가 동일하지는 않음
    • 각각의 쿼리에는 이와 관련된 비용이 있음. 이 비용은 CPU 시간 또는 지연 시간으로 측정. 쿼리가 디스크에서 정보를 반환하기 위해 더 오래 기다리면 해당 시간에 비용이 추가.
    • 워크로드는 모든 유형의 쿼리와 지연 시간이 혼합된 것. CPU의 20%에서 1000개의 QPS를 처리하는 경우 동일한 지연 시간으로 4000개의 QPS를 추가할 수 있음. 4000개의 쿼리를 추가로 도입 후 디스크 IOPS(Input/Output Operations Per Second: 저장 장치의 성능 측정 단위)에 도달하면 병목 현상이 발생하여 모든 읽기 지연 시간이 늘어남
    • 읽기 대 쓰기 성능을 확인하면(3장에서 나옴) 읽기 또는 쓰기 지연 시간이 증가하고 있는지 확인 가능, 어디가 제한적인지 알 수 있음
    읽기 바운드 워크로드
    • 모든 데이터베이스 트래픽에 대해 하나의 소스 호스트를 사용했다고 했을 때 읽기 요청에 응답시 기능에 제한을 받을 수 있음.
    • 주요 지표로는 CPU 사용률이 있음. CPU 사용률이 높다는 것은 서버가 쿼리를 처리하는 데 많은 시간을 소비하고 있음을 의미. 쿼리에서 더 많은 지연 시간이 표시됨.
    • 디스크읽기 IOPS 또는 처리량도 많은 것을 볼 수 있음. 디스크를 매우 자주 읽거나 디스크에서 많은 행을 읽고 있다는 것을 나타냄
    • 인덱스 추가, 쿼리 최적화, 캐싱 등으로 처음에 이를 개선할 수 있음
    • 위의 방법을 모두 썼다면 읽기 바인딩된 워크로드가 남게 되며 레플리카를 사용하여 읽기 트래픽을 확장해야 함
    쓰기 바운드 워크로드
    • 쓰기 바인딩된 데이터베이스 로드의 몇 가지 예
      • 회원 가입이 기하급수적으로 증가
      • 전자상거래의 성수기. 주문수와 매출 증가
      • 선거철이라 선거운동 후보가 많이 뜨고 있음
    • 단일 소스 데이터베이스는 한동안 수직 확장이 가능하더라도 어느 수준까지만 확장됨. 병목이 쓰기 볼륨인 경우 개별 하위집합에서 병렬로 쓰기를 수용할 수 있게 데이터를 분할하는 방법을 생각해야 함
    만약 읽기, 쓰기 두 가지 유형의 성장이 모두 보인다면?
    • 스키마를 면밀히 검사하고 읽기에서 더 빠르게 성장하는 테이블이 있는지, 쓰기 요구량이 증가하는 다른 하위 집합이 있는지 확인하는 것이 중요.
    • 데이터베이스 클러스터를 동시에 확장하려면 많은 사고와 문제 발생. 읽기 및 쓰기를 독립적으로 확장하려면 서로 다른 기능 클러스터에서 테이블을 분리하는 것이 좋음
    기능적 샤딩
    • 비즈니스에서 ‘기능’을 기반으로 데이터를 분할하려면 데이터가 무엇인지 깊은 이해가 필요
    • 각 테이블을 자체 ‘기능적’ 데이터베이스에 넣는다면 너무 많은 단편화로 모든 것을 악화시킬 수 있음
    • 대규모 단일/혼합 데이터베이스를 합리적인 소규모 클러스터 세트로 분할하려면 아래와 같은 지침 필요
      • 엔지니어링 팀의 구조에 따라 나누면 안된다. 그 구조는 어느 순간 바뀐다
      • 비즈니스 기능에 따라 테이블을 분할한다. 계정 등록을 지원하는 테이블은 기존 고객 설정을 호스팅하는 테이블과 분리될 수 있다.
      • 데이터에 별도의 비즈니스 문제가 뒤섞이는 것을 두려워하지 않아도 된다.
    읽기 풀로 읽기 스케일링가상 IP를 사용하여 읽기 전용 레플리카에 액세스하는 애플리케이션 노드
    • 레플리카를 읽기 요청을 처리하는데 사용할 수 있음
    • 위의 이미지처럼 동일한 애플리케이션 노드가 가상 IP에 연결되어 해당 노드와 읽기 전용 레플리카 사이의 중간 계층 역할을 함. 증가하는 읽기 로드를 둘 이상의 호스트로 분산할 수 있음
    • 일반적으로 로드 밸런서를 사용하여 읽기 레플리카로 전송되는 모든 트래픽의 중개자 역할을 하는 가상 IP를 실행함
    • 이를 위한 기술로 HAProxy, 자체 호스팅을 하는 경우 하드웨어 로드밸런서, 퍼블릭 클라우드 환경에서 실행 중인 경우 네트워크 로드 밸런서가 있음
    읽기 풀 구성 관리
    • 로드밸런서를 사용하여 읽기 풀에 포함되거나 포함되지 않은 노드를 쉽게 관리할 수 있는 방법이 필요.
    • 수동으로 관리하면 실수, 장애 등이 발생할 수 있으므로 서비스 검색 솔루션을 기술 스택의 일부로 배포하거나 클라우드 공급자의 관리형 서비스 검색 옵션을 선택하여 읽기 풀 구성을 자동으로 관리하는 것이 필요함
    • 읽기 전용 레플리카를 이 읽기 풀에 적합하게 만드는 기준을 매우 구체적으로 지정해야 함.
    읽기 풀에 대한 상태 확인(Health checks)
    • 읽기 레플리카가 정상이고 애플리케이션에서 읽기 트래픽을 허용할 준비가 되었다고 간주하는 허용 가능한 기준이 무엇인지 고려해야 함.
    • ‘데이터베이스 프로세스가 실행 중이고 포트가 응답한다’ 처럼 간단할 수도 있고 ‘데이터베이스가 실행중이고 복제 지연 시간이 30초 이하이며 읽기 쿼리가 100ms 이하의 지연 시간으로 실행되어야 한다’와 같이 복잡해질 수도 있음
    • 대부분의 경우 포트 검사만 사용하여 MySQL 프로세스가 활성 상태이며 연결을 허용할 수 있는지 확인 가능
    로드 밸런싱 알고리즘 선택
    • 무작위: 로드 밸런서는 사용 가능한 서버 풀에서 무작위로 선택한 서버로 각 요청을 보냄
    • 라운드 로빈: 로드 밸런서는 A, B, C, A, B, C 등의 반복적인 순서로 서버에 요청을 보냄
    • 가장 적은 연결: 다음 연결은 활성화된 연결이 가장 적은 서버로 이동
    • 가장 빠른 응답: 요청을 가장 빨리 처리한 서버가 다음 연결을 수신. 풀에 빠르고 느린 시스템이 혼합되어 있을 때 잘 작동할 수 있음. 그러나 쿼리 복잡성이 다영한 SQL에서는 까다로움
    • 해시: 로드밸런서는 연결의 소스 IP 주소를 해시하여 풀의 서버 중 하나에 매핑. 동일한 IP 주소에서 연결 요청이 올 때마다 로드 밸런서는 이것을 동일한 서버로 보냄. 바인딩은 풀의 머신 수가 변경되는 경우에만 변경
    • 가중치: 로드 밸런서는 다른 여러 알고리즘을 조합하여 가중치를 추가할 수 있음
    • 가장 적합한 알고리즘은 워크로드에 따라 다름. 쿼리 로드가 높을 때, 스키마 변경을 수행할 때, 비정상적으로 많은 수의 서버가 오프라인 상태가 될때 등 다양한 상황에서 실험을 해봐야 함
    대기열
    • 쓰기 크기를 직접 조정하는 방법을 찾기 전에 대기열을 통해 쓰기 트래픽 증가를 보다 쉽게 관리할 수 있는 위치를 확인할 수 있음.
    • 쓰기 요청의 일부를 대기열에 배치하고 데이터베이스에 직접 과부하를 초래하지 않는 속도로 요청을 처리할 수 있음.
    • 쓰기 로드에 대기열을 적용하는 경우 대기열에 배치된 후 이러한 호출이 수행될 것으로 예상되는 원하는 시간 범위를 미리 결정하고 모니터링해야 함
    샤딩으로 쓰기 스케일링
    • 쿼리를 최적화하고 대기열을 이용해도 쓰기 트래픽 증가를 관리할 수 없는 경우 샤딩이 다음 옵션
    • 샤딩은 더 많은 소스 호스트에서 동시에 더 많은 쓰기를 실행할 수 있도록 데이터를 각기 다른 더 작은 데이터베이스 클러스터로 분할하는 것.
    • 샤딩 또는 파티셔닝에는 기능적 파티셔닝과 데이터 샤딩이 있음
      • 기능적 파티셔닝: 다른 노드를 다른 작업에 할당하는 것. 사용자 레코드를 한 클러스터에 배치하고 청구서를 다른 클러스터에 두는 예시가 있음. 이 접근방식을 통해 각 클러스터를 독립적으로 확장할 수 있음
      • 데이터 샤딩: 보편적이고 성공적인 접근 방식. 데이터를 더 작은 조각 또는 샤드로 분할하고 다른 노드에 저장함으로써 데이터를 샤딩. 블로그 서비스를 구축한다고 했을 때 1000명의 사용자가 있다면 사용자 등록 정보를 분할할 필요가 없지만 5억명의 사용자가 예상된다면 샤딩해야 함
    • 필요한 부분만 샤딩할 경우 빠르게 증가하는 데이터뿐만 아니라 논리적으로 이에 속하고 정기적으로 쿼리될 데이터도 고려해야 함
    분할 방식 선택
• • 파티셔닝 키를 선택할 때는 샤드 간 쿼리를 최대한 피하면서 불균형하게 큰 데이터 청크 때문에 문제가 없을 정도로 샤드를 작게 만드는 것이 좋음
  다중 파티셔닝 키
  • 데이터모델이 복잡한 경우 둘 이상의 파티셔닝 키를 가질 수도 있음.
  • 예를 들어 블로그 애플리케이션의 데이터를 사용자 ID와 게시물 ID로 분할해야 할 수 있음. 사용자에 대한 모든 게시물에 게시물에 대한 모든 댓글을 보고싶어 하는 경우가 있음
  • 사용자별 샤딩만 하면 게시물에 대한 댓글을 찾는데 도움이 되지 않고 게시물별로만 하면 사용자의 게시물을 찾는데 도움이 되지 않음. 두가지 유형의 쿼리가 모두 필요한 경우 두가지 방식으로 샤딩해야 함
  샤드 간의 쿼리
  • 애플리케이션에서 단일 쿼리로 간주하는 것을 분할하고 샤드 당 하나씩 여러 개의 쿼리를 병렬로 분할하고 실행하는 것이 데이터 샤딩 구현의 어려운 부분.
  • 우수한 데이터베이스 추상화 계층은 이러한 문제를 완화하는데 도움이 되지만 이러한 쿼리는 샤드 내 쿼리보다 훨씬 느리고 비용이 많이 들기 때문에 보다 적극적인 캐싱도 필요함

 

출처- MySQL 성능 최적화(https://www.yes24.com/Product/Goods/112622445)

참고하면 좋을 블로그 - https://changhoi.kim/posts/database/rdb-scaling/