Week 10

Week 10
: DBMS, Servlet, Session, Cache

✍️ 7월의 첫 째 주 멘토링!
이번 주 기록은 현생에 치여 시간을 보내다 보니 멘토링 당일에 작성하지 못했다. (사실 게으른거다.)
그리고 JSP 책을 다 읽어보려고 했지만 생각보다 이해되지 않는 부분도 많아서 다 읽지 못했다. (정말 게으른거다.)

그래서 반성의 시간을 조금 가지고 멘토링한 내용을 늦게나마 기록해보려고 한다. 이번 시간에는 웹 프로그래밍의 기초가 되는 Servlet, DBMS, Session, Cache 등에 대해서 다시 정리해보자!

---

1. JSP Output Buffer

JSP 는 기본적으로 요청에 대한 결과를 클라이언트에게 바로 응답하지 않고 버퍼라는 메모리에 결과를 쌓아두었다가 한 번에 응답하는 방식으로 동작한다. (이전 java.io 관련 Stream 과 Buffer 에 대해서 공부했던 개념과 유사하다.) 
Buffer 를 이용하므로써 얻을 수 있는 장점은 IO 처리에서의 Buffer 와 비슷하다고 볼 수 있는데, 다음 내용을 살펴보자.

📍 성능 향상
요청이 들어올 때 마다 응답하는 방식보다 응답을 모아서 한번에 처리하는 것이 여러 방면에서 유리한 것으로 공부했다. 그 이유는 요청에 대한 결과를 응답 할 때 마다 데이터를 내보내는 작업 자체가 많은 자원을 소모하게 되는데, 이를 각각의 요청이 들어올 때 마다 처리하는 방법은 반복적으로 소모되는 자원을 절약 할 수 있기 때문이다.

📍 유연한 데이터 수정
Buffer 를 사용하지 않고 요청마다 응답하게 된다면 해당 응답에 대한 결과값을 다시 서버 측에서 수정 할 수 없다. 그 이유는 서버 측에서 응답을 하는 순간 응답의 결과값에 대한 제어권을 상실하기 때문이다.
JSP 의 응답 결과는 HTTP 통신 그 자체이기 때문에 Buffer 를 사용하지 않는다면 HTTP Header 혹은 Body 에 있는 정보 중 수정하고자 하는 정보는 수정하지 못하고 그대로 통신이 이루어진다. 때문에 클라이언트에서 잘못된 HTTP 패킷 정보 때문에 예외 상황이 발생 할 수 있다.
만약 Buffer 를 사용하게 된다면 Buffer 로 지정된 메모리만큼 응답 결과를 쌓아 놓을 수 있고, 매 요청마다 바로 응답하지 않기 때문에 Buffer 에 속한 응답 결과값을 수정하거나 변경 할 수 있다. 이를 통해서 클라이언트에게 응답할 데이터의 잘못된 정보나 에러 등을 사전에 서버 측에서 잡을 수 있다.

[서블릿/JSP] JSP 출력 버퍼란

 

2.  Cookie, Session

쿠키와 세션은 모두 서버 측에서 클라이언트의 상태를 확인하고, 이를 통해 연속적인 작업을 수행하기 위한 용도로 사용된다.
이를 이해하기 위해서는 HTTP 프로토콜의 특성을 먼저 파악하고 있어야 하는데, HTTP 프로토콜은 Stateless, Connectionless 특성을 가진다. 즉, HTTP 통신을 하는 서버와 클라이언트는 서로의 상태를 알 수 없고, 요청에 의해 서버와 클라이언트가 연결되고(3-Way Handshake) 서버 측에서 응답을 하게 되면 HTTP 통신은 둘의 연결을 끊어버린다.(4-Way Handshake)

정적 데이터만을 응답하던 과거의 웹 서비스들이 클라이언트의 상태, 권한에 따라 동적으로 데이터를 응답해줘야 하는 요구사항이 늘어나면서 이러한 HTTP 특성을 해결하고자 쿠키와 세션이 만들어지고, 이를 이용해서 서버는 클라이언트의 상태를 확인하고 이에 맞는 동적 데이터를 응답 할 수 있게 되었다.

여기서 쿠키란 HTTP 패킷에 Key : Value 한 쌍으로 구성된 플레인 텍스트 데이터의 일종이다. 클라이언트의 웹 브라우저의 웹 스토리지에 저장하며, 서버에서는 해당 쿠키를 통해 클라이언트의 상태를 확인 할 수 있다. 다만 쿠키는 1) 클라이언트 측에서 저장된다는 점과 2) 플레인 텍스트로 저장된다는 점에서 보안에 취약하다.

이런 쿠키의 문제점을 극복하기 위해 세션이 등장하게 되는데, 세션은 클라이언트 정보를 서버 측 세션 스토리지에 저장하므로써 쿠키가 가지고 있는 보안의 문제를 해결 할 수 있게 되었다. 하지만 클라이언트의 요청이 늘어나면서 서버에서 보관해야 하는 세션의 양도 자연스럽게 늘어났는데, 이는 서버의 과부하 문제로 이어질 수 있다.

 

3.  Session Clustering

먼저 클러스터와 클러스터링이라는 개념을 이해하고 있어야 한다.
✔️ Cluster : 개별적으로 작동하는 컴퓨터를 연결하여 하나의 시스템처럼 작동하게끔 한 집합.
✔️ Clustering : Cluster라는 집합이 하나의 시스템처럼 작동 할 수 있게끔 하는 행위 그 자체.

이제 세션에 대해서 다시 한 번 살펴보자. 세션은 클라이언트의 정보 등을 서버 측에서 보관하고 있다.
이 때, 대용량 트래픽에 대응하기 위해서 서버의 규모를 스케일 아웃 방식을 채택하게 되면서 세션의 정합성 문제가 발생 할 수 있다.
그 이유는 A 클라이언트의 요청이 무조건 a 서버로만 간다는 보장이 없기 때문에, A 클라이언트의 요청이 b 서버로 간다면 b 서버에서는 A 클라이언트에 대한 정보를 알지 못하기 때문에 해당 클라이언트의 세션을 또 만들어야 한다.

이러한 문제점을 해결하기 위해서 Session Cluster 라는 방법을 이용해서 서버의 세션을 하나로 뭉쳐 A 클라이언트의 요청이 어떤 서버로 가더라도 서로 클라이언트의 세션 정보를 공유하고 있기 때문에 불필요한 작업을 여러 번 수행 할 필요가 없어지게 되었다.
Session Cluster 는 여러가지 방법으로 구현 될 수 있는데, 해당 방법들을 알아보자.

📍 Sticky Session
서버에 세션이 보관된 클라이언트는 해당 서버로만 요청을 보낼 수 있도록 한 Session Clustering 방법이다.
이 전에 L4 / L7 Switch 에 대해서 공부 했는데, 이 때 L7 Switch는 HTTP 프로토콜의 패킷을 확인하고 이를 특정 기준에 부합한다면 기준에 맞는 서버로 로드 밸런싱 해준다는 것을 공부했다. 이를 통해 추론 할 수 있는 것은 서버는 클라이언트의 세션을 만들고 나면 해당 세션 ID를 쿠키로 만들어 클라이언트에게 응답하고, 클라이언트는 이 때 받은 세션 ID 쿠키를 매요청마다 보내는데, 쿠키는 HTTP Body 에 담겨져 있다는 것을 생각해본다면 Sticky Session 방식이 L7 Switch를 통해서 로드 밸런싱되어 자신의 세션이 속한 서버에게만 요청이 간다는 것을 알 수 있다.
하지만 이러한 Sticky Session 방식은 여러 대의 서버가 있을 때 많은 클라이언트 요청이 하나의 서버에서 세션이 만들어져 해당 서버에게만 로드 밸런싱 된다면 해당 서버의 과부하는 물론이고 나머지 서버들의 자원이 사용되지 않게 된다는 단점이 있다.

📍 All-to-All Session
WAS 에서 지원해주는 방법 중 하나인 All-to-All Session 방식은 각 서버에서 만들어진 모든 세션을 나머지 서버에게 모두 공유한다. 
모든 서버에서 세션을 공유하기 때문에 Sticky Session 방식과 달리 클라이언트의 요청이 어떤 서버로 가던지 각 서버는 클라이언트의 상태를 파악 할 수 있다.
하지만 해당 세션 클러스터링은 서버를 추가하면 추가 할 수록 세션을 공유해야 하는 서버가 늘어나 이에 대한 자원 낭비가 O(N) 만큼 늘어난다는 단점이 있다.

📍 Session Storage Server
비즈니스 로직을 수행하는 서버에서 세션을 직접 보관하지 않고 별도의 세션 스토리지 서버를 구축하고, 각 서버들은 세션을 확인 할 때 세션 스토리지 서버를 통해서 확인하여 모든 서버에서 세션 상태를 공유 할 수 있는 방법을 말한다.
세션을 보관하는 별도의 서버를 구축하므로써 서버에서 세션에 대한 부담을 줄일 수 있고, 무엇보다 각각의 서버가 세션을 세션 스토리지 서버를 통해서 공유하기 때문에 정합성 문제를 해결 할 수 있게 되었다. 하지만 세션 스토리지 서버가 모종의 이유로 다운되면 연결된 모든 서비스 시스템도 사용 할 수 없는 상태가 된다. 때문에 이를 해결하기 위해서 최소 두 개의 세션 스토리지 서버를 구축하고, A 세션 스토리지 서버가 다운되면 해당 권한 등을 B 세션 스토리지 서버가 승격받아 서비스를 계속해서 유지 할 수 있도록 구현한다.
이러한 세션 스토리지 서버는 주로 InMemory(Redis, MemCache 등)에 세션을 저장하게 되는데, 디스크에 세션 정보를 저장하고 이를 읽는 작업보다 더 빠르게 작업 할 수 있기 때문이다. (디스크에 세션 정보를 저장한다면 IO 작업을 추가적으로 수행해야 하기 때문에 작업 속도가 느려질 수 밖에 없다.)

 

4.  JDBC

Java Database Connectivity.
Java 애플리케이션에서 데이터베이스와 통신 할 수 있도록 규약을 정해 놓은 Java API이다.
JDBC는 JDBC 드라이버가 필요한데, 각 데이터베이스 제품마다 사용하는 쿼리나 내부 구조가 달라 Java 애플리케이션에서 연결하고자 하는 데이터베이스의 드라이버를 JDBC에서 읽어 어떤 데이터베이스 제품을 쓸 것인지 명시해주어야 한다.
즉, JDBC 드라이버들은 Java 애플리케이션의 요청을 사용하고자 하는 데이터베이스 제품이 이해 할 수 있는 프로토콜로 변환하는 클라이언트 사이드 어댑터 역할 을 한다.
(서버와 데이터베이스의 관계를 살펴보면 서버는 데이터베이스에게 데이터를 요청하는 입장이고, 데이터베이스는 서버의 요청에 응답하는 입장이기 때문에 이 때는 서버는 클라이언트 입장이 된다.)
이 때, Class.forName() 메소드를 이용하므로써 컴파일한 JDBC 드라이버를 JDBC에 명시한다.

 

5.  Connection Pool

먼저 Connection 이란 서버와 데이터베이스 사이를 연결한 객체를 의미한다. Connection 을 통해서 Statement 를 이용해 데이터를 요청하고 응답 할 수 있다. 과거에는 이러한 Connection 을 매 요청마다 새로 생성하고, 응답하면 사라지는 구조로 작동 했다. 하지만 Connection 객체를 생성하는 작업 자체가 많은 자원을 사용하는데, 이러한 작업을 모든 요청 때 마다 반복하면 자원이 낭비되기 때문에 이러한 낭비를 막고자 Connection Pool 이 등장하게 된다.
Connection Pool 은 WAS 가 실행하면서 설정된 값에 맞게 Connection 을 생성하고, 이들을 Connection Pool 이라는 영역에 보관하게 된다. 이제 클라이언트 요청이 들어오게 되면 해당 요청에 Connection 하나를 할당하고, 해당 요청의 통신이 마무리 되면 할당된 Connection 은 다시 Connection Pool 에 반환된다.

이러한 Connection Pool 은 메모리 상황에 맞게 Connection 생성 갯수를 제한하고, 미리 Connection 객체를 만들기 때문에 서버 - 데이터베이스 간의 연결을 위한 자원을 절약 할 수 있다.

 

6.  Thread Pool

과거 CGI 프로그래밍 방식은 하나의 요청이 들어오면 새로운 프로세서를 할당하기 때문에 이로 인한 서버 부하나 자원 낭비가 심했다. 이를 해결하기 위해서 Java 진영의 Servlet 이 등장하게 되고, 이러한 Servlet 은 JVM 위에서 하나의 스레드로 동작하기 때문에 CGI 프로그래밍 방식에서 낭비되는 자원을 절약 할 수 있게 되었다.
Thread Pool 도 Connection Pool 과 비슷한데, 미리 설정된 값에 맞게 Thread 를 메모리에 만들어놓고, 클라이언트 요청이 들어오면 해당 요청에 Thread 하나를 할당한 뒤, 요청에 대한 통신이 끝나면 (연결이 끊어지면) Thread 를 반환한다.

이러한 방식을 이용할 때, 요청이 들어올 때 마다 Thread 를 새로 만들지 않아도 되기 때문에 자원의 낭비를 막을 수 있다.

---

💥 Prepared Statement 성능과 보안