[Spring] 대용량 시스템에 대한 이해

웹의 기본 아키텍처

MySQL 맛보기 (1)

• 클라이언트
• 웹서버
  • HTML,CSS,JavaScript 같은 정적인 데이터를 처리
• 웹 어플리케이션 서버
  • 데이터 베이스에 저장되어있는 데이터처럼 동적으로 변하는 데이터들을 처리
• 데이터베이스

왜 데이터베이스가 병목일까?

스케일 아웃 & 스케일 업

	스케일업	스케일 아웃
특징	서버 사양을 업그레이드	서버의 갯수를 늘림 -> 분산
유지보수 및 관리	쉬움	여러 노드에 적절히 부하분산 필요
확장성	제약이 있음	스케일업에 비해 자유로움
장애복구	서버가 1대, 다운타임이 있음	장애 탄력성이 있음

• 같은 입력에 대해서는 항상 같은 결과를 반환
• 이를 위해 서버가 여러개여도 하나의 데이터 베이스를 바라보게 만들어야함
• 데이터 베이스는 서버에 비해서 데이터라는 상태를 관리하고 있어 서버보다 스케일 아웃 비용이 훨씬 많이 듦
• 현대 서버 아키텍처는 상태관리를 데이터베이스에 위임하고, 서버는 상태관리를 하지 않는 방향으로 발전
• 또한 스케일 아웃 외에도 데이터베이스는 디스크의 접근해서 가져오기 때문에 메모리에 있는 데이터를 사용해 응답을 처리하는 서버보다 느림
• 서버와 데이터 베이스는 네트워크로 연결되어 있기 때문에 네트워크 상황에 따라서도 속도가 달라짐
  • 위와 같은 이유로 병목현상이 생김

대용량 시스템이 어려운 이유

• 하나의 서버로 감당하기 힘들어 대부분 여러개의 서버 또는 데이터베이스를 사용함
• 여러개의 서버에서 유입되는 데이터의 일관성을 보장할 수 있어야함
• 코드 한 줄이 데이터에 미치는 영향범위가 굉장히 큼
• 여러 서비스들이 얽혀있어, 시스템 복잡도가 상당히 높음

MySQL

• 데이터 베이스는 결국 서버다.
• 클라이언트는 json을 통해 서버에게 데이터를 달라고 요청하는 것과 같이
• 서버는 MySQL에 데이터를 요청한다

• 전달 받은 요청을 위와 같은 순서로 데이터를 탐색하고 돌려줌
• MySQL 엔진은 두뇌
• 엔진 안에서는 다음과 같은 로직으로 처리된다.
  • 쿼리파서 -> 전처리기 -> 옵티마이저 -> 쿼리 실행기
    • 쿼리파서
      • SQL을 파싱하여 Syntax Tree 을 만듬
      • 이 과정에서 문법 오류 검사가 이루어짐
    • 전처리기
      • 쿼리파서에서 만든 Tree를 바탕으로 전처리 시작
      • 테이블이나 컬럼 존재 여부, 접근권한 등 Semantic 오류 검사
        • 쿼리파서, 전처리기는 컴파일 과정과 매우 유사하다.
        • 하지만 SQL은 프로그래밍 언어처럼 컴파일 타임때 검증 할 수 없어 매번 구문 평가를 진행
          • 서버쪽에서 동적으로 SQL 요청문이 와서 검증이 안됨
    • 옵티마이저
      • 쿼리를 처리하기 위한 여러 방법들을 만들고, 각 방법들의 비용정보와 테이블의 통계정보를 이용해 비용을 산정
      • 테이블 순서, 불필요한 조건 제거, 통계정보를 바탕으로 전략을 결정 (실행 계획 수립)
      • 옵티마이저가 어떤 전략을 결정하느냐에 따라 성능이 많이 달라진다.
      • 가끔씩 성능이 나쁜 판단을 해 개발자가 힌트를 사용해 도움을 줄 수 있다.
    • 쿼리실행기
      • 옵티마이저가 결정한걸 쿼리실행기가 역할을 가져감
      • 이 때 Handler API를 사용해 스토리 엔진에 요청함
      • 이를 핸들러 요청이라고 함
• 스토리지 엔진은 판단을 수행 동작
  • 디스크에서 데이터를 가져오거나 저장하는 역할
  • MySQL 스토리 엔진은 플러그인 형태로 Handler API만 맞춘다면 직접 구현해서 사용할 수 있다.
  • InnoDB, Mylsam 등 여러개의 스토리 엔진이 존재
  • 8.0 대 부터는 InnoDB 엔진을 디폴트로 사용

• MySQL에는 소프트 파싱이 없다.
• 하지만 5 버전까지는 쿼리캐시가 있었다.
• 쿼리캐시는 SQL에 해당하는 데이터를 저장하는 것
• 쿼리캐시는 데이터를 캐시하기 때문에 테이블의 데이터가 변경 되면 캐시의 데이터도 함께 갱신시켜줘야함

• Oracle 에는 소프트 파싱이 존재
• 실행계획까지만 캐싱
• 하지만 모든 SQL과 맵핑해 데이터까지 캐싱하지는 않음 (힌트나 설정으로 가능하긴 함)

• MySQL의 쿼리캐시, Oracle의 소프트 파싱 모두 성능 최적화를 위해 캐시라는 기술을 도입한 사례
• 그러나 캐시의 범위가 다르다.
• 캐시를 도입할 때는 항상 만료정책을 고려해야한다.
• 쿼리캐시는 소프트 파싱에 비해 조회성능은 더 높지만 캐시 데이터 관리에 더 높은 비용이 들어감

정규화 / 비정규화

• 중복을 최소화해 데이터를 구조화하는 프로세스를 정규화라고 한다.
• 테이블 설계관점에서 조회와 쓰기를 다르게 봐야한다.

정규화	반정규화(비)
중복을 제거하고 한 곳에서 관리	중복을 허용
데이터 정합성 유지가 쉬움	데이터 정합성 유지가 어려움
읽기시 참조 발생	참조없이 읽기 가능