[스프링부트] 17. Session & RAID

1. 서버 내 가용 인원

• Spring 내의 Tomcat에서 PC의 성능에 따라 가용 가능한 request 객체 수를 미리 정해둠
• 예시로 50개로 가정

• Tomcat은 request pooling 기법을 사용
• 미리 사용할 수 있는 request 객체들을 생성해 두고, 요청이 들어올 때마다 할당

• 수용 가능한 개수 이상의 요청 수가 서버에 집중될 경우, waiting이 발생
• 서버 내의 처리에 따라 waiting 인원을 남기거나 접근을 거부시킬 수 있음

• 다량의 요청이 계속 들어올 경우, 서버는 RAID를 통해 똑같은 서버를 복제할 수 있음
• 실제로 컴퓨터를 늘리는 것이 아닌, 서버를 추가로 가용하기 위해 HDD를 독립적으로 구분
• 똑같은 성능에서 여러 OS 및 서버 프로세스를 가동하여 추가 인원을 가용하는 방식

RAID

복수 배열 독립 디스크(Redundant Array of Independent Disks 혹은 Redundant Array of Inexpensive Disks)는 여러 개의 하드 디스크에 일부 중복된 데이터를 나눠서 저장하는 기술이다. 디스크 어레이(disk array)라고도 한다. 데이터를 나누는 다양한 방법이 존재하며, 이 방법들을 레벨이라 하는데, 레벨에 따라 저장장치의 신뢰성을 높이거나 전체적인 성능을 향상시키는 등의 다양한 목적을 만족시킬 수 있다.

https://ko.wikipedia.org/wiki/RAID

2. RAID 내 인증의 문제

• RAID 시스템을 통해 똑같은 서버를 복제할 수 있으므로, request 또한 복제품의 개수만큼 증가
• 레이드 서버가 2개일 경우, 총 가용 가능한 인원 수는 request 50 * 2 = 100명

• 이때, RAID 서버의 한 측에 요청이 집중되는 것을 막기 위해 L4 스위치 (로드밸런서)를 사용
• 서버의 한 쪽으로만 집중되지 않고 요청이 분산되어 처리됨
• 서버가 늘어남에도 특정 서버의 과부하를 막을 수 있는 장치
• 이때, RAID 서버 내에 유저의 정보를 저장하는 session을 만들었을 경우, 문제가 발생

예시

• 클라이언트는 추가 요청 (POST, PUT 등)을 위해 L4 스위치에 접근

• L4 스위치는 무작위로 서버의 접속을 연결하므로, 해당 클라이언트를 RAID 0에 생성된 (위쪽) HTTP 서버에 연결시킴

• 해당 서버에서는 user 정보를 담은 세션 정보가 없으므로, 세션 키를 가진다 하더라도 user의 인증이 불가능
• 해결 방법이 2가지
1. 세션 정보를 서버 내에서 공유
• 클라이언트의 정보가 노출될 수 있기 때문에 보안성으로도 매우 위험함
2. 전자 서명 (인증서) 사용 : 공개 키 암호화
1. 클라이언트가 HTTP 서버에 접속
2. 서버는 HTTP 서버의 공개 키로 user 정보를 암호화
3. 암호화한 정보를 cookie를 통해 클라이언트에게 전달
4. 클라이언트는 다시 요청을 통해 HTTP 서버에 접근
5. HTTP 서버는 서버의 개인 키를 통해 user 정보를 복호화
6. 복호화가 성공한 경우, 이는 서버에서 암호화를 했다는 인증
• 클라이언트의 user 정보 신뢰 가능
• 이를 사용한 HTTP 서버를 HTTPS 서버 (HTTP-Security)

공개 키 암호화는 어떻게 작동할까요? | 공개 키 암호화 및 SSL | Cloudflare

공개 키 cryptography라고도 하는 공개 키 암호화에는 공개 키와 개인 키라는 두 가지 암호화 키가 사용됩니다. 이에 따라 TLS/SSL이 가능해집니다.

https://www.cloudflare.com/ko-kr/learning/ssl/how-does-public-key-encryption-work/