[Infra] 다중 서버 환경

출처: https://kr.freepik.com/free-vector/web-hosting-server-rack-isometric-icon-of-database-and-data-center-blockchain-digital-technology_4102271.htm

인터넷을 돌아다니다 사용자가 증가하면 서버를 어떻게 확장시킬지에 관한 글이 올라와있는것을 확인했다.

그냥 읽고만 넘어가기엔 너무 정리가 잘 돼있기에 내용을 다시 훑어보며 포스팅으로 녹여보고자 한다.

 

출처는 맨 밑에 접은글에 표기하였다.

---

1. 대규모 트래픽이 됐다.

사용하던 서비스가 대박이 나서 늘어난 트래픽을 서버가 견딜 수 없어한다. 이때 어떻게 해야할까?

간단하게 두 가지 방법을 통해 우리의 서버를 견고히 할 수 있을것 이다.

• 더 성능 좋은 서버로 업그레이드
• 서버를 여러대 추가로 설치

성능 좋은 서버로 업그레이드하는 방법이 Scale Up이고,

서버의 개수를 늘리는 방법이 Scale Out이다.

 

 

Scale Up

서버의 CPU나 메모리 등을 추가하여 서버 자체의 성능을 향상시키는 방법.

 

장점

• 서버의 장비만 추가 or 교체하면 되기에 구축과 설계가 간단.
• 별도의 컨트롤러나 네트워크 인프라 등 비용이 발생하지 않는다.
• 추가적인 별도의 서버가 생기는 것이 아니기에 데이터 정합성 문제가 없다.

 

단점

• 부품 업그레이드로는 성능 향상의 한계가 있다.
• 하나의 서버에서 모든 트래픽을 감당하기에 장애극복 기능이 떨어진다.
• 매번 장비 업그레이드를 할 때 마다 교체 비용이 든다.

 

 

 

 

Scale Out

서버 자체의 성능 향상이 아닌 서버의 대수를 늘리는 방법.

 

장점

• 확장에 유연하다.
• 특정 서버에 트래픽이 몰리는 것을 분산하여 부하를 막을 수 있다.
• 하나의 서버에 문제가 생겨도 다른 서버가 있으므로 가용성을 높일 수 있다.

 

단점

• 설계와 구현이 복잡하고 이에 따른 관리 비용도 증가한다.
• 데이터 불일치 문제가 발생한다.

 

이 데이터 불일치 문제가 오늘 해결할 핵심 문제다.

서버1에서 로그인 처리를 했다고 이걸 서버2에서 알고있을까?

Scale Out 방식에서는 데이터 정합성에 대한 문제를 고민해야한다.

 

 

 

 

 

---

2. 다중 서버 환경에서 Session 관리

Scale Out을 통해 서버를 늘리면 다음 그림과 같은 상태가 된다.

 

각 서버마다 세션 저장소를 각자 보유하고 있고 이를 서로 공유하지 않기에 데이터 정합성 문제가 발생한다.

 

 

개선1. Sticky Session

 

Sticky Session 방식은 사용자가 한번 사용했던 서버를 이후 요청시 계속 사용하는 것이다.

즉 로드밸런서에서 User1이 WAS1에서 세션을 생성했다는 사실을 알게되면 User1의 요청은 이후부터 WAS1로만 보내지는 것이다. 

User1은 동일한 서버만 사용하게 되기에 정합성 문제가 해결되긴 한다. 

 

하지만,

 

고정된 세션을 사용한다는 것은 특정 서버에 트래픽이 몰릴 수 있다는 것을 의미한다. Scale Out을 한 의미가 없어진다.

 

 

 

 

 

개선2. Session Clustering

한마디로 표현하면, 여러 서버들을 동기화 하는 것이다.

Tomcat 9.0 Document를 보면 톰캣이 세션 클러스터링을 구현하는 방법으로 DeltaManager를 사용하여 all-to-all 세션 복제 방식을 제안한다.

 

이렇게 한 서버의 상태를 다른 세션 저장소에서 복제하여 반영하기에 어떤 서버로 로그인 요청을 보내도 데이터 정합성 문제는 발생하지 않게된다.

 

하지만 이 방법도 문제가 있어보인다. 

 

세션 저장소에 데이터가 입력될 때 마다 모든 서버에 똑같이 반영해 줘야하기에 서버 수에 비례하여 네트워크 트래픽이 증가한다. 따라서 너무 많은 서버를 가진 상태에서는 오히려 비효율적이다.

 

 

Tomcat에서는 이를 또 개선하기 위해 BackupManager를 활용한 Primary Secondary 세션 복제 방식을 제시한다.

 

얘도 간단하게 말하자면, Primary 서버에서 다른 서버로 모든 정보를 복제하는 것이 아닌 Key만 복제하게 하고 이를 통해 세션 전체를 복제하는 것보다 메모리 사용면에서 개선을 한 것이다.

 

 

 

 

---

3. 출제자의 의도

그래서 어떤 방법을 쓰라는 것일까? 정답은 물론 없지만 사람들이 "흔히" 쓰는 방법은,

기존 서버들이 가지고 있던 로컬 세션 저장소를 사용하는 것이 아닌 제 3의 저장소를 사용하는 것이다.

 

이렇게 하면

• Sticky Session처럼 트래픽이 몰리는 현상이 일어나지 않고,
• 서버 하나에 장애가 발생해도 다른 서버로 대체 가능하여 가용성을 확보할 수 있고,
• 제 3의 통일된 스토리지에 세션을 저장하기에 데이터 정합성을 해결할 수 있다.

 

 

이때 어떤 세션 스토리지가 적당할지 요구사항을 정리해보자면,

• Read/Write가 빈번하게 이루어지기에 Disk 기반 데이터베이스는 느린 IO속도로 인해 부적합.
• In-Memory 데이터베이스를 사용한다면 메모리에서 Read/Write를 하기에 속도면에서 적합.
• 데이터베이스 전원이 끊기면 데이터가 사라지는 In-Memory 데이터베이스이지만 세션들이 사라지는 것은 다시 로그인만 하면 되기에 치명적이지 않다.

즉, In-Memory 데이터베이스를 제 3의 세션 스토리지로 활용하는 것이 좋다.

이에는 Redis와 Memcached가 있는데 Redis는 이후에 따로 포스팅 할 예정이므로 이정도만 알고 넘어가자.

 

 

 

4. JWT 연전연승?

JWT를 처음 공부할 때 이런 상황(서버가 다수 존재할 때)에서 유용하게 쓰인다고 들었는데 정말 그럴 것 같다.

 

 

 

 

 

 

참고:

https://see-one.tistory.com/4

사용자가 증가하면 서버를 어떻게 확장해야할까?

https://hyuntaeknote.tistory.com/4?category=867120 

다중 서버 환경에서 Session은 어떻게 공유하고 관리할까? - 1편 (Scale-Up / Scale-Out이란?)