[JS] 12. 쿠키&세션 인증의 한계

Apr 03, 2025

Contents

🚀 서버 확장과 인증 문제 해결: 개발자의 접근 방식 🔹 1. 서버 확장의 필요성 🔹 2. 부하 분산을 위한 로드 밸런서 도입 🔹 3. 세션 기반 인증의 문제점 ⚠️🔹 4. JWT(Json Web Token) 기반 인증 방식으로 전환 🔑🔹 5. 쿠키 & 세션을 활용한 해결 방법 🔹 6. 결과 및 기대 효과 🎉

🚀 서버 확장과 인증 문제 해결: 개발자의 접근 방식

서비스가 성장하면서 사용자 수가 증가하고, 이에 따라 서버의 확장이 필요해졌다. 개발자로서 우리는 이러한 변화에 대비하여 서버 확장 및 인증 방식을 개선해야 한다.

🔹 1. 서버 확장의 필요성

📌 문제 발생: 사용자가 증가하면서 기존 단일 서버의 처리 용량이 한계에 도달했다.

🔍 문제 분석

request 객체는 풀링(pooling)되어 재사용되며, 서버의 성능에 따라 동시 접속 가능 수가 결정된다.

동시 접속자 수가 증가하면, 기존 서버의 리소스가 부족해지고 응답 속도가 느려진다.

✅ 해결 방법:

동일한 서버를 추가하여 부하를 분산.

설정을 번거롭게 수정하지 않기 위해 RAID 방식으로 기존 서버를 복제하여 배포.

결과적으로 여러 서버를 운영하며 더 많은 요청을 처리할 수 있도록 개선.

🔹 2. 부하 분산을 위한 로드 밸런서 도입

📌 문제 발생: 다중 서버 환경에서 사용자 요청을 특정 서버에 집중시키면 부하가 한쪽으로 쏠리는 문제가 발생.

🔍 문제 분석

특정 서버에만 요청이 집중되면 성능 저하 및 장애 가능성이 커진다.

클라이언트의 요청을 균등하게 분산할 필요가 있다.

✅ 해결 방법:

L4 로드 밸런서를 도입하여 트래픽을 적절히 배분.

각 서버의 상태를 지속적으로 모니터링하여, 부하가 적은 서버로 트래픽을 전달.

이를 통해 특정 서버에 과부하가 걸리는 것을 방지하고, 전체 시스템의 안정성을 향상.

🔹 3. 세션 기반 인증의 문제점 ⚠️

📌 문제 발생: 서버가 여러 대가 되면서 기존의 쿠키 & 세션 인증 방식이 정상적으로 작동하지 않음.

🔍 문제 분석

사용자가 로그인하면, 해당 서버에 세션이 저장됨.

이후 요청이 다른 서버로 전달될 경우, 해당 서버에는 로그인 정보가 없어 인증 실패.

다중 서버 환경에서는 세션 동기화가 필요하지만, 이는 성능 저하 및 관리 복잡성을 초래.

🚨 결과:

동일한 서비스 내에서도 사용자 경험이 불안정해지고, 인증 관련 오류가 발생.

✅ 기존 해결책:

세션 클러스터링: 모든 서버가 공유할 수 있는 중앙 세션 저장소(Redis, DB 등)를 활용.

Sticky Session: 동일한 사용자의 요청을 항상 같은 서버로 전달하도록 설정.

❌ 하지만, 이러한 방식은 추가적인 인프라 비용과 복잡성을 초래할 수 있음.

🔹 4. JWT(Json Web Token) 기반 인증 방식으로 전환 🔑

📌 새로운 해결 방법: 기존 세션 기반 인증 방식 대신, JWT(Json Web Token) 인증 방식 도입.

🔍 JWT 방식의 작동 원리

사용자가 로그인하면, 서버가 유저 정보를 암호화하여 서명된 JWT 토큰을 발급.

사용자는 이후 요청 시 JWT를 포함하여 전송, 서버는 이를 검증하여 인증 수행.

🔐 암호화 방식:

대칭키 암호화: 하나의 비밀키를 사용하여 암호화 및 복호화.

비대칭키 암호화: 공개키와 개인키를 활용하여 서명 및 검증.

✅ JWT의 장점:

세션 저장소 불필요: 서버 간 인증 정보를 공유할 필요 없이, 각 요청에 포함된 JWT로 인증 가능.

확장성 우수: 서버를 추가하거나 변경해도 JWT를 통해 인증을 유지할 수 있음.

보안성 강화: 토큰에 서명이 포함되어 있어 변조 여부를 쉽게 검증 가능.

▶️ JWT를 활용하면, 다중 서버 환경에서도 로그인 상태를 유지하며 안정적인 인증이 가능.

🔹 5. 쿠키 & 세션을 활용한 해결 방법

📌 쿠키 & 세션 방식도 다중 서버 환경에서 사용할 수 있음.

✅ 가능한 해결책:

Sticky Session (세션 고정화):

로드 밸런서가 특정 사용자의 요청을 항상 동일한 서버로 보내도록 설정.
세션 데이터가 분산되지 않아 기존 방식 그대로 사용 가능.
하지만, 특정 서버에 부하가 집중될 가능성이 있음.

세션 공유 (Session Replication):

Redis, Memcached 등 외부 저장소를 이용하여 세션을 여러 서버에서 공유.
서버가 다수라도 세션 정보를 모든 서버에서 접근 가능.
하지만, 추가적인 인프라 비용과 네트워크 오버헤드가 발생할 수 있음.

데이터베이스 기반 세션 저장:

세션 정보를 중앙 데이터베이스에 저장하고, 모든 서버에서 참조 가능하도록 설정.
다중 서버 환경에서 안정적인 세션 공유 가능.
하지만, DB 부하가 증가할 수 있음.

✅ 결론:

세션 기반 인증을 유지하면서 다중 서버 환경을 지원하려면 Sticky Session 또는 세션 공유 방식(Redis 등)을 도입하면 가능.

하지만 확장성과 관리 효율성을 고려하면 JWT 방식이 보다 효과적.

🔹 6. 결과 및 기대 효과 🎉

✅ 결과:

로드 밸런서를 통한 부하 분산으로 서버 확장 효과 극대화.

JWT 기반 인증을 통해 서버 간 인증 정보 동기화 문제 해결.

또는 세션 공유 방식(Redis, DB 저장 등)을 도입하여 기존 세션 기반 인증 유지 가능.

전체적인 서비스 안정성과 확장성이 향상됨.

💡 결론:

다중 서버 환경에서는 세션 기반 인증과 JWT 기반 인증 모두 적용 가능, 단 각 방식의 장단점을 고려해야 함.

확장성과 유지보수성을 고려하면 JWT가 유리, 하지만 기존 인프라를 유지하면서 세션 기반 인증을 활용하는 방법도 존재.

이를 통해 보다 안정적인 서비스 운영이 가능.

내가 작성한 정리글


서버는 request 객체를 pooling해서 가지고 있는다 (미리 만들어 놓고 재사용)

서버의 하드웨어 사양에 따라 pooling해서 가지고 있는 request객체의 수가 다르다

이 request의 수가 서버의 동시 접속자 처리량이다

내 서버의 접속자 처리량을 늘리기 위해 서버를 1개 더 추가한다

이 때 서버의 설정을 다시 만지기 힘들기 때문에 그냥 서버를 복제한다(레이드 RAID)

이제 서버가 2개이기 때문에 앞 단에 진입 포인트를 할 장치가 필요하다(L4)

이제 이 장치가 요청을 받으면 서버의 사용량을 비교해 요청을 나눠 준다

이렇게 서버가 2개로 나눠진 상태에서 쿠키&세션 인증의 문제가 발생한다

A유저는 B1서버에 로그인을 하였다

A유저는 사용자 정보 페이지를 요청한다

이 요청이 B2서버로 간다

B2서버에는 A유저에 대한 정보가 세션에 없다

A유저는 로그인을 했지만 응답으로 에러가 날라온다

서버가 여러 개가 있다면 인증 정보를 공유하기 힘들기 때문에 쿠키&세션 인증으로는 해결하기 힘들다

이때 사용자의 정보를 암호화 서명하는 방식이 나타났다

대칭키로 암호화 해도 되고

비대칭키로 암호화 해도 된다

이제 A유저는 암호화된 데이터를 들고 다니면서 인증을 하면 된다

GPT가 정리한 글 1

서버 확장과 인증 문제 해결 과정

Request 객체 풀링

서버는 request 객체를 미리 생성하여 풀링(pooling)해두고 재사용한다.

서버의 하드웨어 사양에 따라 풀링할 수 있는 request 객체의 개수가 다르다.

즉, 서버가 한 번에 처리할 수 있는 동시 접속자 수는 request 객체의 수와 밀접한 관계가 있다.

서버 확장 (스케일 아웃)

서버의 접속자 처리량을 늘리기 위해 동일한 서버를 하나 더 추가한다.

서버 설정을 다시 조정하기 어려우므로 기존 서버를 그대로 복제하는 방식(RAID)을 사용한다.

이제 서버가 2개가 되어 부하 분산이 필요하다.

로드 밸런싱 (L4 장치 도입)

클라이언트의 요청이 들어오는 진입 지점(Entry Point)이 필요하다.

L4 로드 밸런서를 통해 두 개의 서버에 적절하게 요청을 분배한다.

로드 밸런서는 각 서버의 사용량을 비교하여 트래픽을 나눠준다.

쿠키 & 세션 인증 문제 발생

A 유저가 B1 서버에 로그인하여 세션이 생성되었다.

이후 A 유저가 사용자 정보 페이지를 요청했으나, 이 요청이 B2 서버로 전달되었다.

그러나 B2 서버에는 A 유저의 세션 정보가 없어 인증 문제가 발생한다.

즉, 다중 서버 환경에서 쿠키 & 세션 방식의 인증이 원활하지 않다.

인증 정보 공유 문제 해결 (JWT 도입)

여러 서버에서 인증 정보를 공유하기 어려우므로, 사용자의 정보를 암호화하여 직접 관리하는 방식이 필요하다.

사용자의 정보를 암호화하고 서명하여 전달하는 방식을 사용한다.

암호화 방법은 두 가지가 있다:

대칭키 암호화: 서버 간 공유된 하나의 비밀키로 암호화 및 복호화 수행.
비대칭키 암호화: 공개키와 개인키를 활용하여 서명 및 검증 수행.

이제 A 유저는 암호화된 인증 데이터를 보유하고 있으며, 요청 시 이를 활용하여 인증을 진행한다.

Contents

JavaScript

[JS] 12. 쿠키&세션 인증의 한계

최재원

Apr 03, 2025

Contents

🚀 서버 확장과 인증 문제 해결: 개발자의 접근 방식

🔹 1. 서버 확장의 필요성

📌 문제 발생: 사용자가 증가하면서 기존 단일 서버의 처리 용량이 한계에 도달했다.

🔍 문제 분석

request 객체는 풀링(pooling)되어 재사용되며, 서버의 성능에 따라 동시 접속 가능 수가 결정된다.

동시 접속자 수가 증가하면, 기존 서버의 리소스가 부족해지고 응답 속도가 느려진다.

✅ 해결 방법:

동일한 서버를 추가하여 부하를 분산.

설정을 번거롭게 수정하지 않기 위해 RAID 방식으로 기존 서버를 복제하여 배포.

결과적으로 여러 서버를 운영하며 더 많은 요청을 처리할 수 있도록 개선.

🔹 2. 부하 분산을 위한 로드 밸런서 도입

📌 문제 발생: 다중 서버 환경에서 사용자 요청을 특정 서버에 집중시키면 부하가 한쪽으로 쏠리는 문제가 발생.

🔍 문제 분석

특정 서버에만 요청이 집중되면 성능 저하 및 장애 가능성이 커진다.

클라이언트의 요청을 균등하게 분산할 필요가 있다.

✅ 해결 방법:

L4 로드 밸런서를 도입하여 트래픽을 적절히 배분.

각 서버의 상태를 지속적으로 모니터링하여, 부하가 적은 서버로 트래픽을 전달.

이를 통해 특정 서버에 과부하가 걸리는 것을 방지하고, 전체 시스템의 안정성을 향상.

🔹 3. 세션 기반 인증의 문제점 ⚠️

📌 문제 발생: 서버가 여러 대가 되면서 기존의 쿠키 & 세션 인증 방식이 정상적으로 작동하지 않음.

🔍 문제 분석

사용자가 로그인하면, 해당 서버에 세션이 저장됨.

이후 요청이 다른 서버로 전달될 경우, 해당 서버에는 로그인 정보가 없어 인증 실패.

다중 서버 환경에서는 세션 동기화가 필요하지만, 이는 성능 저하 및 관리 복잡성을 초래.

🚨 결과:

동일한 서비스 내에서도 사용자 경험이 불안정해지고, 인증 관련 오류가 발생.

✅ 기존 해결책:

세션 클러스터링: 모든 서버가 공유할 수 있는 중앙 세션 저장소(Redis, DB 등)를 활용.

Sticky Session: 동일한 사용자의 요청을 항상 같은 서버로 전달하도록 설정.

❌ 하지만, 이러한 방식은 추가적인 인프라 비용과 복잡성을 초래할 수 있음.

🔹 4. JWT(Json Web Token) 기반 인증 방식으로 전환 🔑

📌 새로운 해결 방법: 기존 세션 기반 인증 방식 대신, JWT(Json Web Token) 인증 방식 도입.

🔍 JWT 방식의 작동 원리

사용자가 로그인하면, 서버가 유저 정보를 암호화하여 서명된 JWT 토큰을 발급.

사용자는 이후 요청 시 JWT를 포함하여 전송, 서버는 이를 검증하여 인증 수행.

🔐 암호화 방식:

대칭키 암호화: 하나의 비밀키를 사용하여 암호화 및 복호화.

비대칭키 암호화: 공개키와 개인키를 활용하여 서명 및 검증.

✅ JWT의 장점:

세션 저장소 불필요: 서버 간 인증 정보를 공유할 필요 없이, 각 요청에 포함된 JWT로 인증 가능.

확장성 우수: 서버를 추가하거나 변경해도 JWT를 통해 인증을 유지할 수 있음.

보안성 강화: 토큰에 서명이 포함되어 있어 변조 여부를 쉽게 검증 가능.

▶️ JWT를 활용하면, 다중 서버 환경에서도 로그인 상태를 유지하며 안정적인 인증이 가능.

🔹 5. 쿠키 & 세션을 활용한 해결 방법

📌 쿠키 & 세션 방식도 다중 서버 환경에서 사용할 수 있음.

✅ 가능한 해결책:

Sticky Session (세션 고정화):

로드 밸런서가 특정 사용자의 요청을 항상 동일한 서버로 보내도록 설정.
세션 데이터가 분산되지 않아 기존 방식 그대로 사용 가능.
하지만, 특정 서버에 부하가 집중될 가능성이 있음.

세션 공유 (Session Replication):

Redis, Memcached 등 외부 저장소를 이용하여 세션을 여러 서버에서 공유.
서버가 다수라도 세션 정보를 모든 서버에서 접근 가능.
하지만, 추가적인 인프라 비용과 네트워크 오버헤드가 발생할 수 있음.

데이터베이스 기반 세션 저장:

세션 정보를 중앙 데이터베이스에 저장하고, 모든 서버에서 참조 가능하도록 설정.
다중 서버 환경에서 안정적인 세션 공유 가능.
하지만, DB 부하가 증가할 수 있음.

✅ 결론:

세션 기반 인증을 유지하면서 다중 서버 환경을 지원하려면 Sticky Session 또는 세션 공유 방식(Redis 등)을 도입하면 가능.

하지만 확장성과 관리 효율성을 고려하면 JWT 방식이 보다 효과적.

🔹 6. 결과 및 기대 효과 🎉

✅ 결과:

로드 밸런서를 통한 부하 분산으로 서버 확장 효과 극대화.

JWT 기반 인증을 통해 서버 간 인증 정보 동기화 문제 해결.

또는 세션 공유 방식(Redis, DB 저장 등)을 도입하여 기존 세션 기반 인증 유지 가능.

전체적인 서비스 안정성과 확장성이 향상됨.

💡 결론:

다중 서버 환경에서는 세션 기반 인증과 JWT 기반 인증 모두 적용 가능, 단 각 방식의 장단점을 고려해야 함.

확장성과 유지보수성을 고려하면 JWT가 유리, 하지만 기존 인프라를 유지하면서 세션 기반 인증을 활용하는 방법도 존재.

이를 통해 보다 안정적인 서비스 운영이 가능.

내가 작성한 정리글


서버는 request 객체를 pooling해서 가지고 있는다 (미리 만들어 놓고 재사용)

서버의 하드웨어 사양에 따라 pooling해서 가지고 있는 request객체의 수가 다르다

이 request의 수가 서버의 동시 접속자 처리량이다

내 서버의 접속자 처리량을 늘리기 위해 서버를 1개 더 추가한다

이 때 서버의 설정을 다시 만지기 힘들기 때문에 그냥 서버를 복제한다(레이드 RAID)

이제 서버가 2개이기 때문에 앞 단에 진입 포인트를 할 장치가 필요하다(L4)

이제 이 장치가 요청을 받으면 서버의 사용량을 비교해 요청을 나눠 준다

이렇게 서버가 2개로 나눠진 상태에서 쿠키&세션 인증의 문제가 발생한다

A유저는 B1서버에 로그인을 하였다

A유저는 사용자 정보 페이지를 요청한다

이 요청이 B2서버로 간다

B2서버에는 A유저에 대한 정보가 세션에 없다

A유저는 로그인을 했지만 응답으로 에러가 날라온다

서버가 여러 개가 있다면 인증 정보를 공유하기 힘들기 때문에 쿠키&세션 인증으로는 해결하기 힘들다

이때 사용자의 정보를 암호화 서명하는 방식이 나타났다

대칭키로 암호화 해도 되고

비대칭키로 암호화 해도 된다

이제 A유저는 암호화된 데이터를 들고 다니면서 인증을 하면 된다

GPT가 정리한 글 1

서버 확장과 인증 문제 해결 과정

Request 객체 풀링

서버는 request 객체를 미리 생성하여 풀링(pooling)해두고 재사용한다.

서버의 하드웨어 사양에 따라 풀링할 수 있는 request 객체의 개수가 다르다.

즉, 서버가 한 번에 처리할 수 있는 동시 접속자 수는 request 객체의 수와 밀접한 관계가 있다.

서버 확장 (스케일 아웃)

서버의 접속자 처리량을 늘리기 위해 동일한 서버를 하나 더 추가한다.

서버 설정을 다시 조정하기 어려우므로 기존 서버를 그대로 복제하는 방식(RAID)을 사용한다.

이제 서버가 2개가 되어 부하 분산이 필요하다.

로드 밸런싱 (L4 장치 도입)

클라이언트의 요청이 들어오는 진입 지점(Entry Point)이 필요하다.

L4 로드 밸런서를 통해 두 개의 서버에 적절하게 요청을 분배한다.

로드 밸런서는 각 서버의 사용량을 비교하여 트래픽을 나눠준다.

쿠키 & 세션 인증 문제 발생

A 유저가 B1 서버에 로그인하여 세션이 생성되었다.

이후 A 유저가 사용자 정보 페이지를 요청했으나, 이 요청이 B2 서버로 전달되었다.

그러나 B2 서버에는 A 유저의 세션 정보가 없어 인증 문제가 발생한다.

즉, 다중 서버 환경에서 쿠키 & 세션 방식의 인증이 원활하지 않다.

인증 정보 공유 문제 해결 (JWT 도입)

여러 서버에서 인증 정보를 공유하기 어려우므로, 사용자의 정보를 암호화하여 직접 관리하는 방식이 필요하다.

사용자의 정보를 암호화하고 서명하여 전달하는 방식을 사용한다.

암호화 방법은 두 가지가 있다:

대칭키 암호화: 서버 간 공유된 하나의 비밀키로 암호화 및 복호화 수행.
비대칭키 암호화: 공개키와 개인키를 활용하여 서명 및 검증 수행.

이제 A 유저는 암호화된 인증 데이터를 보유하고 있으며, 요청 시 이를 활용하여 인증을 진행한다.

Contents