Stateless, Stateful 프로토콜

인터넷에 있는 모든 것들은 프로토콜에 의하여 컨트롤됩니다. 프로토콜이란 인터넷을 통해 모든 데이터가 운반될 때 직접, 혹은 간접적으로 따라야 하는 규약이나 가이드라인이죠. 

 

이 네트워크 프로토콜에도 두가지 프로토콜이 대표적인데, 바로 이번 포스팅에서 알아볼 Stateless, Stateful 프로토콜입니다. 이 둘을 프로토콜 혹은 아키텍처라고도 부르는데요. 아키텍처는 말이 어렵지만 그냥 방법론이라고 생각하시면 됩니다. 즉, Stateless, Stateful을 구현할 수 있는 다양한 방법이 있다는 얘기이죠. 

 

이번 포스팅에선 그런 방법론적인 얘기보다는 Stateless, Stateful이 각각 무엇인지, 그리고 이 둘의 차이는 무엇인지에 대해서 알아볼까합니다. 

 

 

Stateful Architecture

Stateful 애플리케이션은 인터넷 전반에 걸친 정보나 요청을 미리 수립하기위해 클라이언트의 데이터를 세션에 저장하는 구조를 가지고 있다고 묘사합니다. 

 

대표적인 Stateful 프로토콜로 TCP 3 way handshake 와 FTP 프로토콜이 있습니다. FTP에 대해서는 제가 잘 모르기 때문에... TCP 3 way handshake로 설명하자면 

 

TCP는 가상회선 연결이 수립되는 과정이라고 생각하시면 됩니다. 클라이언트는 서버한테 요청을 할 수 있는지, 서버는 클라이언트에게 응답해줄 수 있는지 확인하는 과정이라고 생각하시면 되는데요. 

 

이때 클라이언트와 서버는 SYN, ACK 이라고 부르는 패킷으로 통신을 합니다. SYN 패킷은 난수로 되어있고 ACK 패킷은 이 난수에 +1 한 값을 가지고 있습니다. 

 

이 SYN, ACK 패킷으로 3번의 과정을 통해 연결을 수립하는데요. 아래의 그림으로 보시면 이해하는데 도움이 되실겁니다. 

 

Stateful 애플리케이션은 세션에 담겨있는 정보들을 유지해야 하기 때문에 온라인 뱅킹이나 이메일 프로토콜인 SMTP에서도 주로 사용하고 있습니다. 

 

이제 Stateful 의 장단점에 대해 알아볼까요?

 

Stateful 의 장점

• Stateful 프로토콜은 하나의 세션에 저장해놓은 정보가 다음 트랜잭션에서 사용될 수 있기 때문에 성능적으로 이점을 가지고 있습니다. 
• Stateful 아키텍처는 추자겅니 보안계층을 가지고 있어서 보안적으로 훌륭히 수행할 수 있습니다. 때문에 온라인 뱅킹이나 재무적인 비즈니스 네트워크 전송에도 사용할 수 있습니다. 
• Stateful 프로토콜은 Stateful이 가진 메모리 때문에 굉장히 직관적입니다. 

음... docs에서 가져온 내용이긴 하지만 이 세번째 장점은 무슨 소리인지 잘 이해가 안가네요. 관련해서 구글링을 해봤지만 딱히 원하는 결과를 얻을 수 없었습니다. 

 

Stateful 의 단점

• 서버가 가지고 있어야하는 정보(데이터)가 많기 때문에 서버의 오버헤드가 우려될 수 있습니다. 
• 성능이 네트워크 메모리에 의존적이기 때문에 자체적으로 확장하기 힘듭니다. 

 

 

Stateless Architecture

Stateless 아키텍처는 Stateful과 반대로 세션에 정보를 저장하고 있지 않기 때문에 각각의 요청에 대해 독립적입니다. 이 프로토콜은 클라이언트와 서버가 요청왁 응답을 주고받을 때 현재의 상태대로 만들어집니다. 

 

게다가 현재 세션의 상태가 다음 트랜잭션에 유지되지 않고 독립적으로 수행됩니다. 

 

Stateless 애플리케이션은 짧은 텀을 가지고 요청을 주고 받으며 관리합니다. Stateless의 가장 대표적인 예시로는 SMS, HTTP 프로토콜, DNS 등이 있습니다. 이제 Stateless의 장단점에 대해서 알아볼까요?

 

Stateless 의 장점

• Stateless 프로토콜은 상태를 유지하거나 보존할 필요가 없기 때문에 시스템의 오작동에 대해서 빠르게 피드백할 수 있습니다. 
• 서버입장에서 자원과 저장공간을 최소화할 수 있고, 트랜잭션을 유지할 필요가 없습니다. 
• Stateless 아키텍처는 쉽게 Scale out, Scale down 할 수 있습니다. 

 

Stateless 의 단점

• 네트워크 성능이 각각의 패킷에 많은 정보를 담아야 하기 때문에 성능적으로 결점을 가지고 있을 수 있습니다. 
• Stateless 아키텍처는 데이터 저장소의 부족으로 인해 일부 기능을 수행할 수 없습니다.

 

 

Stateless와 Stateful에 대한 예시는 다른 블로그에 많이 있으니 그것을 참고하시면 더 좋을 듯 합니다. 개인적으로 보고 깔끔했다고 생각드는 블로그는 아래 링크를 걸어둘테니 참고하시길 바랍니다. 

 

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Stateful-Stateless-%EC%A0%95%EB%A6%AC

🌐 아주 쉽게 이해하는 Stateful / Stateless 차이

 

또한 해당 내용은 김영한님의 인프런 강의 "모든 개발자를 위한 HTTP 웹 기본 지식"에 수록되어있는 내용이기도합니다. 

 

저는 기존에 많이 알려져있는 내용 보다는 아래서 설명할 왜 Stateless 프로토콜을 선택해야 하는지에 대해서 말씀드리고자 합니다. 

 

우리가 Stateless 프로토콜을 선택해야 하는 이유

1. 서버에 데이터를 저장하는 관점에서

Stateless 프로토콜은 데이터를 저장하는 것이 최우선이 아닙니다. 그러므로 서버는 애플리케이션 라이프 사이클에 필요한 모든 데이터를 저장할 필요가 없다는 것이죠. 반면에 Stateful 프로토콜에서는 애플리케이션의 라이프 사이클에 해당하는 모든 데이터를 가지고 있어야 합니다. 

 

이 말은 Stateless는 보내는 데이터는 많지만 서버가 감당해야하는 저장공간은 줄어들고, Stateful은 보내는 데이터는 적지만 서버가 감당해야 하는 저장공간은 많아진다는 얘기입니다. 

 

2. 구현하기 쉬운 관점에서

Stateless 프로토콜은 요청을 처리하기 위해 더 적은 용량과 더 적은 쿼리를 요구하는데 이는 Stateless 애플리케이션이 더 적은 컴퓨터 프로세싱 파워가 요규된다는 의미이고 이는 더 쉽게 구현할 수 있다는 의미입니다. 

 

Stateful 프로토콜은 Stateless 프로토콜보다 더 많은 컴퓨터 프로세싱 파워와 저장공간을 필요로합니다. 그래서 Stateful 프로토콜은 논리적으로 무겁고 구현하기가 힘들다. 

 

3. 클라이언트-서버와 의존정도를 관점으로

Stateless 프로토콜은 서버와 클라이언트간의 의존정도가 낮습니다. 서버 입장에서 요청을 보낼 때 더 적은 짐을 질 수 있습니다. 반면에 Stateful 프로토콜에서는 서버와 클라이언트간에 높은 수준의 상호 의존관계가 형성됩니다.

 

요청을 서버로 보내기 위해서는 유저가 연결을 수립하기 전에 응답할 수 있어야 합니다. 

 

4. 서버 장애를 관리하는 관점에서

시스템 장애에 관련해서 Stateless와 Stateful 프로토콜은 서로 차이를 보여주는데, Stateless 프로토콜의 경우 서버 입장에서 현재 세션에 대한 많은 정보를 가지고 있지 않기 때문에 서버 한두개 정도 내려간다고 하더라도 데이터를 잃는 관점에서 큰 손실을 입지는 않습니다. 

 

하지만 Stateful 프로토콜에서는 현재 세션에 대한 정보를 가지고 있어야 하기 때문에 서버 한두개 내려가기 시작하면 해당 정보가 통째로 날아가는 것이기 때문에 데이터 손실적인 측면에서 봤을 때 Stateful이 좀 더 불리합니다. 

 

5. 서버 복잡도의 관점에서

최근에 서버는 연결된 기기의 클라이언트의 벌크 요청에 대한 처리를 하기위해 만들어졌고, 때문에 서버는 더 많은 처리, 더 많은 저장공간을 위해 복잡해졌습니다. 

 

서버의 복잡도 측면에서 Stateless 프로토콜은 서버가 매우 간단한 편입니다. 하지만 Stateful 프로토콜은 클라이언트의 장치를 자유롭게 하는 동시에 대부분의 책임을 서버에 맡기는 방식을 유지하기 때문에 굉장히 복잡한 편입니다. 

 

6. 확장성의 측면에서

애플리케이션이 성장함에 따라 엄청나게 많은 트래픽을 서버가 감당하게 되고 그에따른 혼잡도 때문에 현재 캐퍼시티를 확장시킬 필요가 생길것입니다. 

 

그럴 때 Stateless 프로토콜 기반 애플리케이션은 Scale up 과  Scale down이 굉장히 쉽습니다. 백엔드 서버하나 늘려주고 프론트엔드에 로드 밸런서한테 새로 추가된 서버만 부여해주면 쉽게 확장할 수 있습니다. 

 

반면에 Stateful 프로토콜은 확장에 대한 접근을 다르게 받아들여야합니다. Stateful 아키텍처를 확장하기 위해서는 서비스에 존재하는 Stateful 서버나 서비스가 추가적으로 포함되어야 합니다. 이는 Scale down도 마찬가지입니다. 

 

7. 트랜잭션의 속도 측면에서

애플리케이션의 스피드를 고려한다는 것은 어찌보면 당연한데, Stateless 프로토콜의 경우 세션의 정보를 유지하고 있지 않기 때문에 더 많은 정보를 위한 저장 플랫폼을 컨설팅 없이 동시에 다수의 세션을 처리할 수 있다는 것입니다. 

 

이는 클라이언트 입장에서 더 빠른 응답속도를 기대할 수 있습니다. Stateful 프로토콜은 이와 반대로 세션에 정보를 많이 담고 있기 때문에 하나의 요청이 끝날 때까지 스레드가 그 요청을 물고 있어야 하고 이는 더 낮은 응답속도로 이어집니다. 

 

8. 멀티태스킹의 측면에서

멀티태스킹 측면에서 Stateless는 각각의 요청이 독립적이기 때문에 멀티태스킹에 능합니다. 하지만 Stateful 프로토콜은 각각의 요청이 하나의 세션에서 굴러가기 때문에 하나의 서버가 멀티태스킹 하기가 굉장히 힘듭니다. 

 

 

 

여기까지 Stateful, Stateless에 대해서 알아봤습니다. 이번엔 크게 어렵지 않았는데 완벽히 이해가 되지는 않았던 것 같습니다. 따로 한번 다시 정리해봐야 할 듯한데... 면접준비로 다시 한번 정리해보도록 하겠습니다. 

 

기존 구글링으로 Stateless, Stateful에 대해서 검색하면 김영한님의 예시를 인용한 블로그들을 많이 볼 수 있는데 저는 그렇기 때문에 그 예시를 인용하지 않아서 글로만 봐서는 잘 이해가 안됐을 수도 있습니다. 하지만 저는 저만의 차별점을 위해 다른 방식으로 다른 관점에서 포스팅한 것이기 때문에 그 점 참고해주시기 바랍니다. 

 

이렇게 글 마무리지어보도록 하겠습니다. 오늘 하루도 즐거운 하루 되세요~

 

 

출처

https://www.spiceworks.com/tech/cloud/articles/stateful-vs-stateless/

Stateful vs. Stateless: Understanding the Key Differences - Spiceworks

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Stateful-Stateless-%EC%A0%95%EB%A6%AC

🌐 아주 쉽게 이해하는 Stateful / Stateless 차이