> For the complete documentation index, see [llms.txt](https://leehyokyun.gitbook.io/openbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leehyokyun.gitbook.io/openbook/2-13..md).

# 2-13. 세션

Web HttpSession의 정합성 관점에서 바라보는 세션의 본질에 대하여

### 1. 세션 정합성을 유지하기 위한 두가지 관점

한 사용자의 세션 정보는 단순히 로그인 정보를 유지한다는 방향을 넘어, 특정 서버에서 사용자의 방문 여부를 확인하고 이에 대한 정합성을 확보한다는 관점에서 바라보는 것이 올바르겠다.

이때, 세션 정합성을 유지하고자 하는 설계 관점은 두가지로 나눌 수 있다.

* 동일 도메인의 다수의 서버(WAS)에서의 특정 사용자 ession 정보를 어떻게 유지할 것인가(정보의 유지)
* 서로 다른 도메인(WAS)에서의 사용자 Session 정보를 어떻게 유지할 것인가(두 도메인간의 정합성 비교)

즉, 세션 정보를 동일한 도메인에서 이루어지는 요청들 사이에서 유지할 것인지, 서로 다른 도메인에서 이루어지는 요청들 사이에서 유지할 것인지에 따라 설계 방향은 달라질 수 있다.

### 2. Sticky Session

말 그대로, 세션을 한 서버에 계속 유지하고자 하는 방법으로, 동일한 사용자의 요청에 대해 로드 밸런싱이 동일한 서버에 전송하는 전략이다.

도메인이 동일할 경우 활용하기 적합한 전략이며, 구현이 쉽고 간단하다. 그러나 동일한 도메인 서버에서 이루어지는 요청 중, 단순히 로그인한 사용자의 정보를 유지하고 이에 대한 정합성을 유지하기 위해 부하 분산없이 동일한 서버 요청으로 전송하는 것은 위험 부담이 그만큼 클 수 밖에 없다. 또한 부하 분산이 이루어지지 않아, 특정 서버에 트래픽이 몰릴 경우 세션 정합성을 유지하는 비용보다 서버 운용에 대한 비용이 비효율적으로 커진다.

### 3. Session Clustering

Sticky Session의 비효율적인 문제와 트래픽 분산에 대한 문제를 보완하고자, 로드 밸런싱의 본질은 그대로 유지하되 세션 정보를 모든 서버(WAS)에 공유하고자 하는 전략이다.

한 유저가 특정 서버에 로그인(방문)을 하였고, 이에 대한 정보를 모든 서버에 복사하는 것이 핵심이다. 그만큼 복사 비용 및 쓰기 비용이 늘어나며, RAM에 저장하는 특성 상 5KB 기준(5MB/1000명, 50MB/10000명 등)으로 세션의 메모리 점유율을 가정해도 무시할 수 없는 정도의 대응 방안 정립이 필요하겠다.

만약 이러한 복사/쓰기 비용보다 세션 정합성 유지에 대한 중요성이 크다면 이러한 클러스터링 전략을 고려해볼 수 있겠다.

### 이 외.

분산 환경에서 세션 정보의 정합성을 유지하거나, 유지가 힘들다면 이에 대한 수용 범위를 지정하고 Polling에 근거한 정합성 유지 전략을 취하는 등 환경에 따라 적절한 세션 정합성 유지 방안을 생각해두는 것이 필요하겠다.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://leehyokyun.gitbook.io/openbook/2-13..md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.