[Review] 대용량 서비스를 지탱하는 기술 책 정리

in Review on Review, Book



대용량 서비스를 지탱하는 기술 책을 보고 정리한 글입니다.

대용량 서비스를 지탱하는 기술

책의 내용을 요약 및 정리합니다.

CHAPTER 2 대규모 데이터 처리의 어려운 점

  • 데이터의 흐름 : 디스크에서 데이터를 로드해서 메모리에 저장, 메모리에 저장된 데이터를 cpu가 패치, 메모리에서 패치된 명령은 보다 빠른 캐시메모리에 캐싱된다
    (디스크 -> 메모리 -> 캐시메모리 -> cpu) 각 단계별 속도에서는 차이가 많이 난다
  • 대규모 데이터는 메모리 내에서 계산할 수 없다.
  • 디스크에 있는 데이터를 검색 -> 디스크는 느리다(약 10~100만배 정도 차이) I/O에 많은 시간이 걸린다.
  • 전송속도에서도 100배 이상 차이가 난다.

부하는 크게 2가지로 분류된다

  1. cpu 부하
    • 같은 구성의 서버를 늘리고 로드밸런서로 분산
    • 웹, AP 서버, 크롤러 등
  2. I/O 부하
    • DB
    • 대규모 데이터

CHAPTER 3 OS캐시와 분산

OS에는 디스크 내의 데이터에 빠르게 액세스할 수 있도록 하는 구조가 갖춰져 있다.
OS는 메모리를 이용해서 디스크 액세스를 줄인다 원리를 알고 이를 전제로 애플리케이션을 작성하면 OS에 상당부분을 맡길 수 있다.
그 원리가 바로 OS캐시이다 리눅스의 경우 페이지 캐시, 파일캐시, 버퍼캐시라고하는 캐시 구조를
갖추고 있다.

가상 메모리 구조는 논리적인 선형 어드레스를 물리적인 물리 어드레스로 변환하는 것이다.
선형 어드레스 -> 페이징 구조 -> 물리 어드레스
(스왑은 가상 메모리를 으용한 기능중 하나로 물리 메모리가 부족할 때 2차 기억장치(주로 디스크)를 메모리로
간주해서 외형상의 메모리 부족을 해소하는 원리다.)

가상 메모리 구조가 존재하는 가장 큰 이유는 물리적인 하드웨어를 OS에서 추상화 하기 위해서다.

  • 가상메모리
    • 프로세스에서 메모리를 다루기 쉽게 하는 이점을 제공한다.
    • OS가 커널 내에서 메모리를 추상화하고 있다.
    • 페이지 OS가 물리 메모리를 확보/관리 하는 단위
  • OS는 확보한 페이지를 메모리상에 계속 확보해두는 기능을 갖고 있다.
    1. 1번 프로세스 요청 -> 페이지
    2. 메모리에 한번 쓰기(읽어낸 블록을 메모리에 쓴다.)
    3. 프로세스에 가상 어드레스로서 알려준다.
    4. 프로세스가 해당 메모리에 엑세스(사용)
    5. 1번 프로세스 요청이 종료 되어도 3번을 남겨준다.
    6. 2번 프로세스 요청이 들어오면 페이지를 사용할 수 있으므로 디스크를 읽으러 갈 필요가 없게된다.
    7. 즉, 커널이 한 번 할당한 메모리를 해제하지 않고 계속 남겨두는 것이 페이지 케시이다.
  • 정리 리눅스의 페이지 캐시
    • 디스크의 내용을 일단 메모리에 읽어들인다.
      -> 페이지가 작성된다.
    • 작성된 페이지는 파기되지 않고 남는다.
      -> 페이지 캐시
    • 예외의 경우를 제외하고도 모든 I/O에 투과적으로 작용
      -> 디스크의 캐시를 담당하는 곳(VFS)
  • VFS
    • 리눅스에는 여러 파일 시스템이 있는데 (ext3,ext2 …) 이 디바이스 드라이브가 실제로
      하드 디스크등을 조작한다 파일 시스템 위에는 VFS(가상 파일 시스템)이라는 추상화 레이어가 있다.
      그 인터페이스를 통일하는 것이 VFS의 역할이다. VFS또한 페이지 캐시 구조를 지니고 있다.
      따라서 어떤 디스크를 읽더라도 반드시 동일한 구조로 캐싱된다.

  • 메모리 : 2GB , 파일 4GB 캐싱이 가능한가?
    YES, OS는 블록 단위로 캐싱한다. 디스크 상에 배치되어있는 4KB 블록만을 캐싱

    페이지 = 가상 메모리의 최소단위

CHAPTER 4 DB 스케일아웃 전략

  • 분산을 고려한 MySQL운용의 포인트
    1. OS 캐시의 활용
      • 전체 데이터 크기에 주의
        -> 데이터량 < ‘물리 메모리’ 를 유지
        -> 메모미가 부족할 경우에는 증설
        • int 32비트 : 4바이트, 문자열 8비트 -> 1바이트
      • 스키마 설계가 데이터 크기에 미치는 영향을 고려
    2. 인덱스를 적절하게 설정하기
    3. 확장을 전제로 한 설계
  • 인덱스의 중요성
    • 인덱스 = 색인
    • MySQL의 인덱스는 기본적으로 B+트리 이다.
      • 외부기억장치 탐색 시에 seek 횟수를 최소화 하는 트리구조
      • O(n) -> O(log n)
    • 복수 칼럼에 동시에 인덱스를 태우고자 할 경우는 복합 인덱스를 사용해야만 한다.
    • explain 명령 속도에유의해서 보자
  • MySQL의 레플레이션 기능
    • 마스터/슬레이브 구성
    • 참조 쿼리는 슬레이브로, 갱신 쿼리는 마스터로
    • O/R 매퍼로 제어한다.
  • 마스터/슬레이브의 특징
    • 참조계열 쿼리는 확장
      • 서버를 늘리기만 하면 된다.
      • 단, 대수를 늘리기보다도 메모리에 맞추는 것이 중요
    • 마스터는 확장하지 않는다.
      • 갱신계열 쿼리가 늘어나면 험난해진다.
      • 단, 웹 애플리케이션은 대부분의 경우 90% 이상이 참조쿼리
      • 마스터 부하는 테이블 분할이나 다른 구현 등으로 연구
    • 마스터/슬레이브의 다중화
      • 기본은 4대가 1세트 (멀티 1대, 슬레이브 3대)
      • 멀티마스터
        • 상호간 레플리케이션
        • 전환 타이밍에 따라 동기가 맞지 않을 위험이 남아있다.