Stateless(매우 중요)
개발을 진행하면서 백엔드에게 중요한 개념
무상태의, 상태가 없는
서버가 각 요청에 대한 상태 정보를 전혀 유지하지 않는 것을 의미한다.
주요특징
상태 정보 유지 없음 :
- 서버는 클라이언트의 이전 요청에 대한 정보를 유지하지 않는다
자급자족 요청 :
- 클라이언트가 서버에 요청할 때, 요청은 필요한 모든 정보를 포함해야 한다.
수평 확장성 :
- 서버가 상태 정보를 유지하지 않으므로, 여러 서버에 요청을 분산하는 것이 쉽다
유지보수 용이성 :
- 상태를 관리하지 않기 때문에, 서버 측의 복잡성이 줄어듬
이는 유지보수와 테스트가 더 쉬워진다는 것을 의미
Stateless와 Stateful의 비교
Stateful:
Stateful 시스템에서는 서버가 클라이언트와의 상호작용 상태를 기억한다. 예를 들어, 전통적인 웹 애플리케이션에서는 사용자가 로그인하면 서버가 세션을 유지하고, 이후의 요청은 그 세션 정보에 기반하여 처리된다.
Stateless:
Stateless 시스템에서는 각 요청이 독립적이므로, 로그인 정보나 상태를 서버에 저장하지 않습니다. 대신, 클라이언트가 매 요청마다 인증 정보를 포함시키는 방식으로 상태를 관리합니다.
장단점
장점 :
확장성이 뛰어나며, 서버 간의 부하 분산이 용이
유지보수가 쉽고, 서버 장애 시 빠른 복구 가능
단점 :
클라이언트 측에서 매 요청마다 필요한 정보를 포함해야 하므로, 일부 경우 성능에 영향을 줌
상태 관리를 전적으로 클라이언트에 맡기므로, 클라이언트 구현이 복잡
1. HTTP의 Stateless -> connectionless
각 요청은 독립적이며, 다른 요청과 연결되지 않는다. 각 요청을 별도로 처리하며, 이전에 처리한 요청의 정보를 기억하지 않는다
2. JWT의 Stateless
JWT의 특성에 대해 설명해주세요 -> stateless입니다
Session
서버가 상태를 가지고 있음
클라이언트는 Session Id를 갖고 있게 됨
- Session Id는 아무런 뜻이 없는 랜덤한 문자열이므로 이 자체로는 아무것도 할 수 없음
클라이언트가 Session Id를 가지고 서버에 요청을 보내면, 서버는 저장된 Session Id(Key)에 맞는 유저의 정보를 매칭시켜 유저 식별
상태?
백엔드에서 상태라는 말은 잘 쓰지 않지만, 프론트엔드에서는 정말 자주 사용함
(블록체인의 경우 '지갑'으로 상태관리를 하기도 한다, 일반적으로는 유저 정보 데이터지만, 상태 데이터가 무엇인지는 도메인마다 조금씩 다름)
상태가 있다 -> 데이터가 있다
상태가 없다 -> 데이터가 없다
프론트엔드(클라이언트)입장에서
벡엔드와 다르게 프론트엔드에서 말하는 '세션'은 유저의 로그인 상태 그자체이다
JWT(중요) -> 클라이언트가 유저 정보를 전부 가지고있음
Json Web Token - JSON 형식의 토큰!
-
클라이언트가 상태를 가지고 있음 -> 서버입장에서 Stateless
-
토큰 자체에 상태를 갖고 있음
-
요청 시 헤더에 JWT를 포함시키고, 서버가 JWT를 파싱(디코드)해서 유저 식별 후 요청을 처리
단점 : JWT는 Session Id에 비해 긴 문자열을 갖고 있으므로, JWT방식이 데이터량이 더 많음
Sha가 들어가면 단방향이다
쿠키는 헤더에 있다!!***
쿠키도 Key/value
JWT의 구조?
JWT에 포함된 데이터 자체는 "암호화된 것이 아니므로" 민감한 정보를 넣으면 안된다.
그러나, 인코딩은 데이터의 가독성을 낮추는 것일 뿐, 데이터를 안전하게 보하는 방법은 아님
따라서 JWT의 페이로드에 포함된 데이터는 누구든지 쉽게 디코딩하여 읽을 수 있다.
(몰라도 되는 지식)
Base64 vs Base64URL
Base64는 인코딩시 +,/,=를 -,_(제거)로 대체하여 에러 상활을 방지
(몰라도 되는 지식2)
그럼 왜 =는 다른 문자로 바꾸는 것이 아니라 제거 하나요?
Base64 특성상 인코딩 결과가 무조건 4의 배수로 나오게 됩니다.
결과가 4의 배수가 안될 경우 =를 넣어 4의 배수로 맞춰주는데 이를 '패딩'이라고 한다
Session에 대비해 JWT 방식의 장점 (비록 암복호화가 일반 로직에 비해서 느리긴 하지만)
-
빠른 요청 처리 속도(DB를 갔다오지 않음)
a. 서버 자체의 캐시를 사용하지 않는 경우! -> 그런데 서버 자체의 캐시를 사용하는건 좋지 않다. 왜? -
무한한 확장성
a. 가능한 이유는 Stateless라는 특성 때문이에요 -> 서버입장에서 Statelss이기 때문에 서버가 상태가 없어서
JWT입장에서 Statefull JWT가 모든 정보를 가지고 다닌다
- 서버비가 저렴할 가능성
a. 물론 저렴하지 않을 수도 있습니다. 그러나 session 방식의 단점인 stateful을 극복해야하기에 JWT 방식에 비해 비용이 더 들어갈 수 있습니다.
3. 서버의 Stateless(중요!!!!!)
서버는 하나의 커다란 함수(=메소드)!
동일한 서비스 서버들은 동일한 조건에서 동일한 리턴을 해줘야함
서버가 여러 개인 이유는 '가용성'때문
가용성?
쉽게 말하자면 '중단되지 않고 지속될 가능성'에 대한 이야기
서버가 1대만 있다면, 그 서버가 장애를 일으킬 경우 운영되고 있는 서비스가 중단
이를 '가용성이 낮다'라고 표현
하지만 서버가 여러 대 있다면, 하나의 서버가 장애를 일으키더라도 서비스는 중단 되지 않고 지속될 것이다.
가용성 100% 존재할까?
불가능하다 그래서 목표를 '고가용성'을 목표로 가진다
이를 위해 다중 서버, 데이터 복제, 로드 벨런싱, 이중화 등의 다양한 방법을 사용
S3는 매우 안전하기 때문에, 데이터 엔지니어링 할 때, 가장 첫번째로 고려해야하는 부분이 S3에 데이터를 일단 저장하고 보는 것이다.
로드 벨런싱? ( Load 부하 Balancing 균형)
서버는 유동적으로 늘어나거나 줄어들어야 한다
Load Balancer? = 대리인, 대리서버
Proxy(대리) Server이다 = 대리 서버이다
장점 : 보안이 좋다
VPC -> 가상 네트워크
Subnet(부) -> 가상 네트워크 안의 또 다른 작은 네트워크
TTL
-> Time to Live (생존기간) 이거를 설정해줄 수 가 있다.
RDBMS 이 기능을 지원하지 않는다. -> SQL
NOSQL은 있다 -> REdis, Firebase, MongDB, AWS DynamoDB
이 DB들은 TTL 기능이 있다
따라서 데이터를 저장할 때 이 데이터가 몇초동안 생존할 것인가를 세팅 가능
MYSQL -> 스케줄러를 돌려야한다 (TTL을 설정할때)
캐시(cash) -> 잠시 살아있는 데이터
노트
서버도 하나의 함수이다
4. Serverless - > 서버를 관리할 필요가 없는
즉, 개발자가 서버를 관리할 수 없고, 내부로 접속할 수도 없다
람다식 서버라고 볼 수도 있다 (딱 그것만 처리하고 없어진다)
EC2 -> 컴퓨터 한대를 리소스를 여러개로 쪼갬 (쪼개서 넣은 다음 애매하게 남은 부분을 람다로 활용)
그렇다면 누가 서버를 관리할까? AWS가 관리
AWS의 대표적인 Serverless 서비스
5. Containerless -> 컨테이너를 관리할 필요 없는
Containerless의 대표적인 예
스프링 : 컨테이너리스 프레임워크 이다
오브젝트와 의존 관계
- 클래스
- 틀
- 설계도
- 청사진
- 프로토타입
- 오브젝트
- 객체
- 실체
- 클래스의 인스턴스
- 배열
오브젝트란?
클래스의 인스턴스 혹은 배열
최상위 클래스의 이름을 Object 간지나게 지은것
- 관심사의 분리
관심사의 분리란?
- 코드를 변경에 유리하게 작성하는 것
- 중복 코드를 줄이는 것
- 재사용성을 높이는 것
멀티 쓰레딩!!
병열 쓰레딩
한개로 데이터를 처리할 때 보다 2,3개 다수로 데이터를 처리하면 처리 속도가 훨씬 빨라진다
한개로 쓰레딩을 처리하고 나서 병열 쓰레딩을 이용하여 시간이 줄어든 것을 성능개선 사항으로 이용할 수 있다.
(처음에 일부러 나쁜 기술을 사용한 후 개선사항을 그래프로 표현)
