땡글이LAB

이 글에선 JWT 토큰의 전체적인 동작 방식에 대한 내용은 다루지 않고, 암호화 알고리즘에 대해서만 다루도록 하겠습니다. JWT 토큰 암호화 알고리즘 중 대표적인 HS256, RS256에 대해서만 다루겠습니다. JWT 토큰의 전체적인 동작 방식은 'Session(세션)과 Token(토큰)의 차이는?' 포스팅을 참고해주시면 좋을 것 같습니다. 위의 포스팅에서는 대칭키 암호화 방식과 비대칭키 암호화 방식에 대해 다루고, 토큰의 구조 및 전체적인 동작 방식을 다루고 있습니다. SHA 256 알고리즘 HS256, RS256 알고리즘에서 공통적으로 쓰이는 단어인 'S256' 이라는 단어는 SHA256 알고리즘을 의미합니다. 또한, SHA256 은 데이터 무결성을 위해 사용되는 암호화 해쉬 알고리즘(함수) 입니다...

세션 불일치 문제 는 단일 서버 환경에서는 발생하지 않으므로 따로 걱정하지 않아도 된다. 하지만, 최근 웹 서비스는 대부분 수직 확장(Scale Up)이 아닌 수평 확장(Scale Out)으로 서버를 확장하기 때문에 일반적으로 다중 서버 환경일 것 이다. 이런 다중 서버 환경에서는 세션 불일치 문제가 발생할 수 있다. 기본적으로 세션은 서버의 메모리(RAM)에 저장되기 때문이다. 예를 들어, 우리가 서버를 수평적으로 확장하기 위해 A, B, C 총 3대의 서버를 설치했다고 가정하자. 이때, 로드 밸런서는 유저의 요청이 들어올 때 마다 A → B → C → A … 순서대로 요청을 분산한다고 가정하자. (이를 라운드로빈 방식이라고 한다.) 이런 환경에서 위와 같이 특정 유저의 로그인 요청이 A 서버로 전달되..

Stateless 한 프로토콜 : HTTP 우선 HTTP의 프로토콜 상태에 알아보자. HTTP 는 stateless 한 특성 때문에 각 통신의 상태는 저장되지 않는다. 하지만 서비스에서는 어떤 유저가 기능을 사용하는지 특정할 수 있어야하는데 이를 위해서 세션(Session) 혹은 토큰(Token)이 사용된다. 유저가 로그인을 시도할 때 서버 상에서 일치하는 유저 정보를 찾았다면 인증 확인의 표시로 세션이나 토큰을 발급해준다. 세션과 토큰의 가장 큰 차이점은 세션은 데이터베이스 서버에 저장된다는 것이고, 토큰은 클라이언트 측에서만 저장된다는 것이다. [ 쿠키(Cookie) + 세션(Session) ] 쿠키에 ID, PW와 같은 중요한 정보가 아닌, 인증을 위한 별개의 정보를 세션 저장소에 저장하고, 클라이..

이 책을 읽게 된 계기부터 말씀드리겠습니다. 최근 전 프로젝트를 직접 기획하고 개발하고 운영해보면서, 테스트코드의 필요성을 느끼게 되었습니다. 운영 서버에서의 에러가 발견돼서 해당 사항을 수정하고, 저녁에 Github Actions + Docker를 활용해 CI/CD 파이프라인을 통해 배포했습니다. 하지만, 빠른 시간 내에 개발해야 된다는 생각에 테스트 코드를 작성해두지 않고 기존 기능들에 대해서는 Postman을 통해 API의 유효성을 검증해왔습니다. 하지만, 운영하는 기간이 늘어날수록 매번 Postman을 이용해 테스트하는 것이 비효율적이라 느꼈습니다. 그래서 저는 테스트 코드에 대해 관심을 가지고 책을 구매하게 되었습니다. 책 읽으면서 느낀 점 책에서는 단위 테스트를 작성하는 방법에 대해 설명합니다..

예전 Java 개발자들은 데이터베이스에 접근해서 데이터를 가져오기 위해 직접 SQL문을 짰었습니다. 지금도 JPA 대신 JdbcTemplate 을 사용해보면, 얼마나 소모적인 작업인지 알 수 있습니다. 그래서 이 때에 많은 개발자들은 테이블을 객체로 매핑시켜주는 라이브러리 혹은 프레임워크를 개발하기 위해 많은 노력을 들였다고 합니다. 그럼 저희가 그 때 당시의 개발자라고 생각해보면서 먼저 객체와 테이블 간의 차이에 대해 정리해보겠습니다. [ 객체와 관계형 데이터베이스 간의 차이 ] 두 가지가 다르다는 것을 확인시켜주는 중요한 2가지 개념이 존재합니다. 상속 첫 번째로는 '상속' 개념입니다. 객체에는 상속을 할 수 있지만, 관계형 데이터베이스 테이블(이하 '테이블'이라고 칭함)에는 슈퍼타입 서브타입이 존재..

스웜 모드는 자체적으로 롤링 업데이트를 지원하며, 매우 간단하게 사용할 수 있다. 우선 롤링 업데이트를 테스트하기 위한 서비스를 생성한다. 이 서비스는 앞에서 생성한 서비스와 유사하지만 이번에는 컨테이너 생성에 사용될 이미지를 nginx:1.10 으로 설정했다. $ docker service create --name myweb2 \ --replicas 3 \ nginx:1.10 서비스가 정상적으로 생성되면, docker service update 명령어로 서비스의 이미지를 업데이트할 수 있다. docker service update 명령어를 사용하면 생성된 서비스의 각종 설정을 변경할 수 있다. 이미지를 업데이트하려면 update 명령어의 --image 옵션을 설정하면 된다. 다음 명령은 myweb2 서..

이전 포스팅에서 계속 사용해온 도커 명령어의 제어 단위는 컨테이너였다. docker run 명령어는 컨테이너를 생성하고, docker rm 명령어는 컨테이너를 삭제했던 것처럼 도커 클라이언트에서 사용하는 명령어가 제어하는 것은 컨테이너이다. 하지만, 스웜 모드에서 제어하는 단위는 컨테이너가 아닌 서비스(Service)이다! 서비스(Service)는 같은 이미지에서 생성된 컨테이너의 집합이며, 서비스를 제어하면 해당 서비스 내의 컨테이너에 같은 명령이 수행된다. 서비스 내에 컨테이너는 1개 이상 존재할 수 있으며, 컨테이너들은 각 워커 노드와 매니저 노드에 할당된다. 이러한 컨테이너들은 '태스크(Task)'라고 한다. 스웜 스케줄러(Scheduler)는 서비스의 정의에 따라 컨테이너를 할당할 적합한 노드를..

지금까지 알아본 도커 사용법은 대부분 하나의 호스트를 기준으로 한다. docker ps 명령어는 하나의 도커 엔진에 존재하는 컨테이너의 목록을 출력하며 create, run 명령어 또한 하나의 도커 엔진에 컨테이너를 생성한다. 그러나 실제로 도커를 운영환경에 적용하려면 이야기가 달라진다. 하나의 호스트 머신에서 도커 엔진을 구동하다가 CPU나 메모리, 디스크 용량과 같은 자원이 부족하면 이를 어떻게 해결할까?? 가장 간단한 답은 "매우 성능이 좋고 디스크 용량이 큰 좋은 서버를 새로 산다"이다. 하지만, 자원의 확장성 측면이나 비용 측면에서도 이것은 좋은 해답은 아니다. 자원이 부족할 때마다 성능이 좋은 서버를 살 수 없을 뿐더러 높은 가격의 서버를 사고 유지하는 비용 또한 무시할 수 없기 때문에 이를 ..