최근에 친절한 SQL 튜닝이라는 책으로 사내 스터디를 진행하게 되었는데, 이번에는 간단하게 내용을 정리하고 조만간 깃허브 블로그로 이전 후에 다시 한 번 정리를 해야할 것 같습니다. 아직 1장이지만 걱정했던 것보단 책이 비유와 함께 설명을 쉽게 해줘서 잘 읽히고 있어 다행이네요...

SQL 처리 과정

SQL은 구조적, 집합적, 선언적 질의 언어로 사용자가 작성한 SQL은 옵티마이저를 통해 최적의 실행 계획으로 프로시저로 작성된다.

SQL 최적화

최적화 = 파싱 + 최적화 + 로우 소스 생성

1. 파싱 : 사용자로부터 전달 받은 SQL을 SQL 파서가 파싱을 진행한다.
   • 파싱 트리 생성 : SQL 문의 개별 구성 요소 분석 및 파싱 트리 생성
   • Syntax 체크 : 문법상의 오류 확인
   • Semantic 체크 : 의미상의 오류 확인 (존재하지 않는 테이블이나 컬럼을 사용하는지 혹은 권한이 부족한지)
2. 최적화 : 옵티마이저가 미리 수집한 시스템 및 오브젝트 통계정보를 바탕으로 실행 경로를 생성해서 비교한 후 가장 효율적인 하나를 선택
   • 쿼리를 실행하기 위한 실행 계획 후보군 선정
   • 데이터 딕셔너리에 미리 수집해둔 오브젝트 통계 및 시스템 통계 정보를 이용해 각 실행 계획의 예상 비용 산정
   • 최적 비용을 나타내는 실행 계획 선택
3. 로우 소스 생성 : 로우 소스 생성기가 실행 경로를 실제 실행 가능한 코드 또는 프로시저 형태로 포맷팅 하는 단계

실행 계획과 비용

예상 실행 계획을 통해 옵티마이저가 선택한 실행 계획이 어떻게 작성되었는지 확인할 수 있고, 해당 경로와 비용을 근거로 적합한 테이블과 인덱스를 결정할 수 있다.

실행 비용은 쿼리 수행 시간 동안 발생할 것으로 예상 되는 I/O 횟수 및 예상 소요 시간으로 어디까지나 예상치이기 때문에 실측과는 차이가 존재한다.

옵티마이저 힌트

SQL 옵티마이저가 항상 최선의 선택을 하는 것은 아니고, 복잡한 SQL일수록 실수가 발생할 가능성이 높기 때문에 개발자가 직접 옵티마이저 힌트를 사용해 통계 정보에 담을 수 없는 데이터나 업무 특성 등을 활용해 더 효율적인 액세스 경로를 선택할 수 있다.

소프트 파싱과 하드 파싱

라이브러리 캐시 : 옵티마이저가 최적화를 통해 생성한 내부 프로시저를 캐싱해두는 공간

1. SQL 파싱
2. 파싱된 SQL이 라이브러리 캐시에 존재하는지 확인
3. 존재하는 경우(cache-hit) 해당 로우 소스 재사용, 존재하지 않는 경우(cache-miss) 로우 소스 생성 과정 수행

cache-hit의 경우를 소프트 파싱, cache-miss의 경우를 하드 파싱이라고 한다.

하드 파싱의 경우 옵티마이저가 쿼리를 최적화 하기 위해 아래와 같은 정보들을 사용해 다량의 CPU 연산을 처리해야 한다.

• 테이블, 컬럼, 인덱스 구조에 관한 정보
• 오브젝트, 시스템 통계
• 옵티마이저 관련 파라미터

I/O 작업에 비하면 큰 작업은 아니지만, 적은 연산은 아니기에 캐싱 전략을 사용해 효율적으로 처리한다.

URL

scheme://호스트/리소스의 위치
http://www.server.com/resource/abcd.gif

브라우저(클라이언트)가 필요로 하는 리소스를 찾을 수 있게 리소스의 위치를 가리키는 식별자로

이를 통해 HTTP 및 다른 프로토콜을 통해 접근할 수 있다.

URL 문법

스킴(HTTP, FTP, SMTP 등)에 따라 문법이 조금씩 달라지긴 하지만

대부분의 문법은 일반적으로 아래와 같이 9개의 컴포넌트로 나뉜다.

<스킴>://<사용자명>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>

이 모두를 사용하는 URL은 거의 없고, 핵심 컴포넌트는 스킴, 호스트, 경로다.

스킴

스킴은 URL을 사용하는 애플리케이션에게 어떤 프로토콜을 사용해 리소스를 요청할지 알려준다.

주로 http, ftp, rtsp, smtp 같은 프로토콜이 있고 알파벳으로 시작해야 하며

대소문자를 구분하지 않고 URL의 다른 컴포넌트와 : 로 구분한다.

호스트와 포트

www.host.com:80

호스트는 리소스를 호스팅 하고 있는 장비와 리소스에 접근할 수 있는 장비를 나타내는 컴포넌트로

호스트를 통해 장비에 접근하고 포트를 통해 접근한 장비에서 실행 중인 서버에 접근할 수 있다.

사용자 이름과 비밀번호

ftp://name:password@ftp.abc.def/ghj

서버가 가지고 있는 데이터에 접근을 허용하기 위해 요구하는 컴포넌트로 주로 FTP에서 사용되며

사용자 이름과 비밀번호를 요구하지 않는다면 굳이 사용할 필요는 없다.

경로

리소스가 서버의 어떤 경로에 있는지 알려주는 컴포넌트로 계층적 파일 시스템 경로와 유사한 구조를 가지며

'/' 문자를 기준으로 경로 조각으로 나뉘고, 각 경로 조각은 파라미터 컴포넌트를 가질 수 있다.

파라미터

ftp://exam.ex/e;type:d
ftp://exam.ex/e;type:d/test;type:b

애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는 데 사용하는 컴포넌트로

이름/값 쌍의 리스트로 URL의 다른 컴포넌트와 ';' 문자로 구분한다

질의 문자열

http://www.server.com/data/check?id=1234&name=test

데이터베이스 같은 서비스들이 요청받을 리로스 형식의 범위를 효율적으로 좁히기 위해 사용하는 컴포넌트로

URL에서 물음표(?)와 물음표의 우측에 오는 질의 컴포넌트로 구성된다.

질의 컴포넌트는 이름=값 쌍 형태를 가지고 있고 각각의 질의 컴포넌트는 '&'로 구분한다.

프래그먼트

http://www.server.com/index.html#test

리소스의 특정 부분을 가리킬 수 있는 컴포넌트로 용량이 큰 텍스트의 특정 절을 가리키거나

HTML 문서의 특정 이미지나 일부분을 가리킬 수 있고 URL의 오른쪽에 # 문자에 이어서 온다.

일반적으로 HTTP 서버는 일부가 아닌 전체를 다루기 때문에 클라이언트가 서버에 프래그먼트를 전달하는 것이 아닌

클라이언트가 서버에게 전체 리소소를 받아 프래그먼트를 사용해 일부분을 보여준다.

단축 URL

리소스 안에 있는 리소스를 간결하게 기술하는 데 사용할 수 있는 방식의 URL

상대 URL

기저 URL : http://www.server.com/index.html
상대 URL : ./test.html
사용 예시 : <a href = "./test.html">
새로운 절대 URL :http://www.server.com/test.html

이전까지 살펴본 URL은 절대 URL로 리소스에 접근하기 위해 필요한 모든 정보를 갖고 있다면

상대 URL은 모든 정보를 담고 있지 않기 때문에 기저(base)라는 다른 URL을 사용해 필요한 정보를 얻어야 한다.

상대 URL만으로는 리소스에 접근할 수 있는 온전한 URL을 알 수 없지만

기저 URL에 스킴과 호스트 등의 컴포넌트가 모두 포함되어 있어 이를 참고해 온전한 URL을 얻을 수 있다.

위와 같은 과정으로 기저 URL을 얻어 절대 URL이 만들어진다.

URL 확장

브라우저가 사용자가 URL을 빠르게 입력할 수 있게 지원하는 자동완성 기능이다.

naver를 입력하면 호스트명에 자동으로 'www.'과 '.com'을 붙여서 'www.naver.com'을 만들어주는

단순한 휴리스틱만 사용하는 호스트 명 확장 방식과

과거에 사용자가 방문했던 URL 기록을 저장해 두고 이를 사용해 입력에 따른 선택 목록을 보여주는

히스토리 확장 방식이 있다.

미래

URL은 주소이지 실제 이름이 아니기 때문에 리소스가 특정 시점에 어떤 곳에 위치하고 있다는 것을 알려줄 뿐이라

리소스가 옮겨지면 더 이상 사용할 수 없는 URL이 되어버리고 기존 URL이 가리키고 있던 객체를 찾을 수 없다.

이런 문제를 예방하기 위해서는 객체의 위치와 상관없이 그 객체를 가리키는 고유한 실제 이름을 사용하는 것으로

그러한 방법이 바로 이전에 간단하게 살펴봤던 URN이다. (PURL)

하지만 주소 체계를 바꾸는 표준화 작업은 매우 큰 작업이기 때문에 많은 시간이 필요하고

이러한 작업이 긴급하진 않기 때문에 앞으로 당분간은 URL이 계속 사용될 것이다.

HTTP

웹 서버로부터 대량의 정보를 빠르고, 간편하고, 정확하게 웹 브라우저로 옮길 수 있게 해주는 프로토콜

신뢰성 있는 데이터 전송 프로토콜을 사용해 전송 중 손상되거나 꼬이지 않음을 보장하기 때문에

사용자는 정보를 얻는 것에 있어서 걱정할 필요가 없고

개발자는 전송 중 발생할 결함이나 약점에 대한 걱정 없이 개발에만 집중할 수 있다.

웹 클라이언트와 서버

웹 서버는 웹 콘텐츠가 존재하는 곳으로 클라이언트와 HTTP 프로토콜로 의사소통한다.

클라이언트가 서버에게 HTTP 요청을 보내면

서버는 요청된 데이터를 HTTP 응답으로 돌려준다.

https://www.naver.com/index.html

우리가 크롬이나 엣지 같은 브라우저(클라이언트)를 통해 위의 주소로 요청을 보내는 경우

https://www.naver.com

위의 서버에 index.html를 찾아달라는 HTTP 요청을 보낸 것이고

서버는 클라이언트가 요청한 데이터와 타입, 길이 등의 정보를 담아 HTTP 응답을 돌려준다.

리소스

리소스는 웹 서버가 관리하고 제공하는 웹 콘텐츠의 원천이다.

대표적으로 텍스트, HTML, 이미지, 동영상 등의 웹 서버 파일 시스템의 정적 파일이 있고

요청에 따라 콘텐츠를 생산하는 프로그램 같은 동적 콘텐츠 리소스 등이 있다.

또한, 웹 게이트웨이, 검색엔진, 데이터베이스 검색 등 모두 리소스가 될 수 있다.

즉, 종류에 상관 없이 모두 리소스가 될 수 있다.

미디어 타입

MIME(Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장)

HTTP는 웹에서 전송되는 수천 가지 데이터 타입을 다루기 위해

전송되는 객체 각각에 MIME 타입이라는 데이터 포맷 라벨을 붙인다.

웹 서버는 모든 HTTP 객체 데이터에 MIME 타입을 붙여 클라이언트에게 객체를 전달하고

클라이언트는 MIME 타입을 보고 다룰 수 있는 객체인지 확인할 수 있다.

Content-type : image/jpeg

text/html
image/gif

MIME 타입은 위와 같이 주 타입/부 타입 형태로 이루어진 라벨이다.

URI (Uniform Resource Identifier, 통합 자원 식별자)

리소스를 고유하게 식별하고 위치를 지정할 수 있는 식별자로

이를 통해 클라이언트는 관심 있는 리소스를 지목할 수 있다.

http://www.shop.com/items/book.jpg

위의 URI를 해석하면

HTTP 프로토콜을 사용해 www.shop.com으로 이동해

items/book.jpg라는 리소스를 가져오라는 것이다.

URI는 URL과 URN 두 가지가 있다.

URL (Uniform resource locator, 통합 자원 지시자)

http://www.shop.com/items/book.jpg
http://www.shop.com/index.html
http://www.shop.com/get?item=1234

가장 흔한 형태의 리소스 식별자로 특정 서버의 한 리소스에 대한 구체적 위치를 서술한다.

대부분 scheme, 서버의 주소, 웹 서버의 리소스 세 부분으로 이루어진 표준 포맷을 따른다.

scheme : 리소스에 접근하기 위해 사용되는 프로토콜로 HTTP, FTP 등이 있다.

URN (Uniform resource Name)

리소스에 대한 위치에 영향받지 않는 고유한 이름으로

리소스의 위치가 옮겨지더라도 URN이 변하지 않는 한 접근할 수 있다.

트랜잭션

HTTP 트랜잭션은 클라이언트가 서버로 보내는 요청 명령과 서버가 클라이언트에 돌려주는 응답 결과로 구성되어 있다.

HTTP 요청 메시지는 다음과 같이 명령과 URI를 포함하고

GET /items/book.jpg HTTP/1.0
Host: www.shop.com

HTTP 응답 메시지는 다음과 같이 트랜잭션의 결과를 포함하며

HTTP/1.0 200 OK
Content-type: image/jpeg
Content-length: 4321

이러한 두 메시지를 하나의 HTTP 트랜잭션이라고 한다.

메서드

서버에게 특정 동작을 취하게 할 수 있게 지원하는 여러 가지 종류의 요청 명령이다.

상태 코드

서버가 클라이언트에게 요청이 성공했는지 실패했는지 혹은 추가 조치가 필요한지 알려주는 세 자리 숫자

메시지

단순한 일반 텍스트로 이루어진 줄 단위의 문자열로 요청 메시지와 응답 메시지를 말한다.

시작줄  GET /items/book.jpg HTTP/1.0

헤더  Accept: text/*

시작줄  HTTP/1.0 200 OK

헤더  Content-type: image/jpeg
헤더  Content-length: 4321

본문 This is Content!

위와 같이 시작줄, 헤더, 본문으로 이루어져 있다.

시작줄 : 무엇을 해야 하는지 혹은 무슨 일이 일어났는지 나타낸다.

헤더 : 0개 이상 존재할 수 있으며 각 헤더 필드는 쌍점(:)으로 구분되어 하나의 이름과 값으로 구성된다.

본문 : 어떤 종류의 데이터든 들어갈 수 있는 메시지 본문으로 웹 서버로 데이터를 보내거나 클라이언트에 데이터를 반환할 때 사용한다.

TCP 커넥션

TCP/IP

TCP와 IP가 층을 이루는 패킷 교환 네트워크 프로토콜로

HTTP는 애플리케이션 계층의 프로토콜로 네트워크 통신의 세부사항에는 신경을 쓰지 않기 때문에

대중적이고 신뢰성 있는 인터넷 전송 프로토콜인 TCP/IP를 사용한다.

TCP는 다음과 같은 기능을 제공한다.

• 오류 없는 데이터 전송
• 데이터를 언제나 보낸 순서대로 도착하게 보장
• 언제든 어떤 크기로든 보낼 수 있는 조각나지 않는 데이터 스트림

TCP/IP는 각 네트워크와 하드웨어의 특성을 숨기고,

어떤 종류의 컴퓨터와 네트워크라도 서로 신뢰성 있는 의사소통을 하게 해 준다.

개념상 위와 같이 HTTP 프로토콜은 TCP 위의 계층이고

HTTP는 자신의 메시지 데이터를 전송하기 위해 TCP를 사용하는 것이다.

접속 / IP 주소 / 포트 번호

HTTP가 서버에 메시지를 전송하기 위해서는 IP 주소와 포트 번호를 사용해

클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 한다.

IP 주소가 친구네 집 전화번호라면

친구의 집(IP 주소)에 전화해 친구(포트 번호)를 바꿔 달라는 것과 비슷하다.

즉, 서버의 컴퓨터에 접근해 웹 서버가 사용 중인 포트까지 접근해야 실제 웹 서버와 통신이 가능한 것이다.

1. 브라우저는 서버의 URL에서 호스트 명을 추출
2. 서버의 호스트 명을 IP로 변환
3. URL에 포트번호가 있다면 추출, 없으면 80이 기본값
4. 웹 서버와 TCP 커넥션 생성
5. 서버에 HTTP 요청
6. 서버가 브라우저에 HTTP 응답 반환
7. 커넥션이 닫히면 브라우저가 문서를 보여준다.

위와 같은 과정을 통해 우리가 브라우저의 주소창에 URI를 입력하면 페이지가 보이게 된다.

웹의 구성요소

프록시

보안, 애플리케이션 통합, 성능 최적화 등을 위한 중요한 구성요소 중 하나다.

클라이언트와 서버 사이에 위치해

클라이언트의 모든 HTTP 요청을 받아 대부분 요청을 수정해 서버에 전달하는

사용자를 대신해 서버에 접근하는 역할을 수행한다.

모든 웹 트래픽의 흐름 속에서 신뢰할 만한 중개자 역할을 하기 때문에

주로 보안을 위해 사용하거나 요청과 응답 필터링 등에 사용된다.

캐시

자신을 거쳐 가는 문서들 중 자주 찾는 문서의 사본을 저장하는 곳으로

클라이언트의 다음 요청에 같은 문서를 요청하면 캐시가 갖고 있는 사본을 받을 수 있어

멀리 떨어진 웹 서버보다 가까운 캐시에서 빠르게 문서를 받을 수 있다.

게이트웨이

다른 서버들의 중개자로 동작하는 서버로, 주로 HTTP 트래픽을 다른 프로토콜로 변환할 때 사용한다.

항상 자신이 실제 리소스를 갖고 있는 진짜 서버인 것처럼 요청을 다루기 때문에

클라이언트는 자신이 실제 서버와 통신하는 것이 아니라 게이트웨이와 통신하는 것을 알 수 없다.

예를 들면, 클라이언트가 HTTP 요청을 HTTP/FTP 게이트웨이에 보내면

해당 요청을 FTP 프로토콜로 처리해 다시 클라이언트에 HTTP 응답을 반환한다.

터널

두 커넥션 사이에 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션으로

주로 HTTP 데이터가 아닌 것을 HTTP 연결을 통해 전달하고자 할 때 사용된다.

에이전트

사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램으로

사람의 통제대로 동작하거나 혹은 통제 없이 동작하는 자동화된 에이전트도 있다.

예를 들어, 스파이더라는 에이전트는 스스로 웹을 돌아다니며

검색엔진의 DB 같은 유용한 웹 콘텐츠 보관소를 만든다.