DB의 꽃 옵티마이저의 실행 계획 수립

RDBMS에서 가장 복잡하면서 가장 중요한 것은 옵티마이저(Optimizer)가 쿼리를 어떻게 실행할지 실행 계획을 결정하는 부분이다.

똑같은 쿼리라 할지라도 다양한 방법과 순서로 실행 될 수 있다.

어떤 실행 계획이 좋고 어떤 실행 계획이 안 좋은지 판단하는 건 온전히 옵티마이저의 몫이지만 개발자 역시도 어떤 실행 계획으로 수행되어야 좋은지를 알아야 최적의 실행 계획을 사용할 수 있도록 옵티마이저에게 힌트를 줄 수 있기 때문에 중요하고 반드시 학습해야하는 부분이다.

사전 지식

실행 계획에 대해 자세히 살펴보기 전에 아래의 사전 지식이 있어야 한다.

쿼리 실행 절차
1. SQL을 SQL 파서가 파싱하여 파서 트리(parser tree)를 만든다.
2. 파서 트리를 기준으로 옵티마이저가 분석하여 실행 계획을 만든다.
옵티마이저의 종류
1. 규칙 기반 옵티마이저 : 이제는 안 쓰임
2. 비용 기반 옵티마이저 : 쿼리 대상 테이블의 레코드 수, 선택도 등 통계 정보를 바탕으로 비용이 가장 적을 것 같은 방향으로 실행 계획 생성 → 대부분 이 방식 옵티마이저 사용(MySQL포함)
통계 정보가 정확할 수록 좋은 실행 계획을 만들 확률이 높다.
- 통계 정보는 서비스중에도 수집되고 수정된다. innodb_stats_sample_pages 설정값은 통계 정보를 위해 분석할 인덱스 페이지의 개수(기본값:8)를 지정하는 것인데, 분석할 페이지 개수를 늘려서 더 정확한 통계 정보를 수집할 수 있지만, 수집 중에 테이블의 읽기/쓰기가 되지 않으므로 문제될 수 있다. 따라서 최대 16~24까지만 설정해야한다.
- MySQL 8.0 부터는 인덱스 말고 일반 컬럼에도 통계 정보(Histogram)를 수집하기 때문에 더 정확한 통계를 토대로 실행 계획을 수립할 수 있다.
- ANALYZE 키워드를 이용해 테이블의 통계 정보를 다시 수집할 수 있다.
EXPLAIN 키워드를 SELECT 쿼리 앞에 붙여서 실행 계획을 살펴볼 수 있다.
- INSERT, UPDATE, DELETE 쿼리는 실행 계획을 알 수 없다.

인덱스 사용중인 지 확인을 위함.

클라우드 사용시 대량의 데이터 트래픽을 기본 프리티어로 견디지 못해 서버거 자꾸 내려감.

클라우드 티어 업그레이드 할 시 비용 문제로 인한 개인 서버 사용.

온프레미스

집을 짓는다고 할 때 집을 짓기 위한 자제 구매부터 건물 도면을 그리는 작업, 시공, 건축 그리고 인테리어까지 모든 과정을 도움없이 집을 필요로 하는 사람이 혼자서 다 처리하는 방법

즉, 온프레미스란 필요한 시스템을 구축하기 위해서 하드웨어와 소프트웨어를 구입하여, 시스템 구성 상황에 맞게 환경을 구성하는 것을 말합니다. 즉 서버실과 혹은 데이터 센터와 같이 특정 공간에 IT 인프라를 구축하여 소프트웨어를 사용하는 방식입니다. 이러한 방법은 인프라를 구축하기 위한 기간이 필요하며, 상황에 따라서는 몇 개월 이상이 걸리기도 합니다. 또한 시스템을 구축하기 위한 물리적인 하드웨어 장비를 구매하는 비용이 들어가며, 부차적으로는 이를 관리 및 운용을 위한 유지보수 비용을 필요로 합니다.

클라우드 시스템

온프레미스처럼 집을 짓는다고 가정하면, 집을 만드는 과정에서 자내나 도구 혹은 전문가의 도움을 필요에 따라 제공받는 방법.
그렇기 때문에 온프레미스는 서비스를 만들기 위해 하나부터 열까지 다 알아야 하지만, 클라우드 시스템은 하나부터 다섯까지 정도만 알아도 ok

즉, 온프레미스와 클라우드 시스템의 가장 큰 차이는

서비스를 제공함에 있어 사용하는 IT 자원을 누가 관리하느냐임
온프레미스: 서비스를 공급하는 서비스 제공자가 직접적으로 IT 자원을 관리하는 주체
클라우드 시스템: 서비스를 공급하는 서비스 제공자는 IT 자원을 사용할 뿐, 대부분의 IT 자원 관리는 클라우드 서비스 제공자에게 제공받음

어떻게 보면 클라우드 시스템은

서비스에 필요한 인프라를 직접 보유하지 않고 필요할 때만 사용할 수 없을까?라는 질문에 답을 하기 위해 나온 기술

이라고 봐도 좋다.

차이점

1. 비용

클라우드 서비스가 제공되지 이전에는 IT 프로젝트를 구성하기 위해서는 온프레미스 시스템을 먼저 도입하고 프로젝트를 진행함.

일반적으로 예측된 데이터를 기준으로 인프라 지식을 갖춘 기술자가 물리적인 구성을 설계함

이때 물리적인 구성은 최대 사양을 기준으로 구성되기 때문에 실제 프로젝트 오픈 시 예측과 다른 경우가 많음 => 이로인해 불필요한 비용이 사용되는 경우가 많음

반면 클라우드 시스템의 경우 서비스에서 제공되는 옵션을 통해 시스템 사양을 실시간으로 수정해 사용이 가능

즉, 불필요한 비용이 들지 않음!

온프레미스는 한번 확정이 된 시스템 사양을 바꾸기가 어렵기 때문에 불필요한 비용이 지속적으로 낭비되지만, 클라우드 시스템은 상황에 따라 적절한 비용으로 시스템을 운용할 수 있도록 도와줌

또한 온프레미스는 물리적인 구성에 필요한 절차 및 시간을 필요로 하는데 클라우드 시스템은 가상에서 시스템을 구성할 수 있어 불필요한 절차를 없애고 쉽게 프로젝트를 구성할 수 있도록 함 => 프로젝트 초기 구성시 드는 비용을 줄여주는 효과

2. 시스템 유지 보수

일반적으로 서버 인프라는 기본 지식으로만 응대하기 어려운 부분이라 인프라에 관한 전문가가 필요함

인프라는 단순히 서버 물리적인 위치 구성 뿐만 아니라 서버 간의 흐름, 역할에 맞는 서버 배치 및 보안 관리 이슈등 여러가지 관점에서 관리되어야 하는 분야이기 때문에 한 명의 전문가가 모든 일들을 처리할 수 없음

이러한 관점에서 프로젝트는 시작부터 유지보수 단계까지 지속적으로 인프라 전문가 인원을 운용해야
또한 온프레미스는 인프라를 직접 운영하고 관리하기 때문에, 현대와 같이 IT 인프라가 점차 복잡해지는 환경에서는 유지보수가 용이하지 못합니다. 직접 인프라를 운용하는 기업들은 날이 갈수록 발전하고 복잡해지는 IT 환경 속에서 지속적으로 발생하는 인프라의 확충과 컴퓨팅 파워 및 저장능력 향상에 대한 끊임없는 책임을 지녀야 하고, 기업이 가진 자산 혹은 개인정보를 지키기 위해서 많은 노력과 비용을 투자해야 하기 때문입니다.

이때, 온프레미스는 모든 관리를 직접적으로 하기 때문에 인프라 전문들을 지속적으로 유지해야 하고 섭외하지 않은 분야의 문제가 생기는 경우 빠른 대처가 어려움. 특히 성능 이슈로 인해 서버의 증설 문제가 발생하는 경우 물리적인 시간 필요

반면 클라우드 시스템은 말 그대로 인프라에 관련된 전문가들이 항시 문제를 해결할 수 있도록 대기중이며, 어떤 이슈가 발생하더라도 응대할 수 있는 인원 및 체계가 갖춰져 있음.
또한 성능 이슈로 인한 서버 증설 문제의 경우 단 한번의 클릭으로 몇분, 몇 시간 내 해결 가능