개발자취

오랜만에 하나 정리해본다. 우선 JWT를 들어봤고 다들 사용해 봤겠지만 왜 사용하는지 또는 흐름이 어떤지도 모르고 사용하는 사람도 있지 않을까? 싶어서 정리해본다. 일딴 jwt 찾아보면 생김새는 AAAAA.BBBBB.CCCCC 이렇게 . 을 기준으로 3개로 나눠져있는데 순서대로 헤더.페이로드.서명인데 주호 헤어에는 토큰의 타입와 알고리즘이, 페이로드에는 토큰에 담을 정보, 서명에는 헤더와 페이로드의 인코딩값을 합친값과 비밀키로 조합해서 만들어진 값이라고 보면된다. 대충 이런느낌으로 그려봤다.. jwt 파서 사이트를 이용해보면 알겠지만 헤더와 페이로드는 단순히 base64방식으로 암호화하기때문에 누구라도 내용을 확인할수있다. 그래서 난 처음 jwt를 사용했을때 아니 왜? 누구나 확인하고 알수있는거면 왜? ..

신규 MSA프로젝트를 진행하면서 고민됐다. 이벤트 발행은 어떻게 해야하고 어떻게 받아야할까? 필요한 이벤트를 달라고 요청을 하고 이벤트로 받아야 하나? 이벤트가 날라오면 필요한 정보를 요청해야하나? 이렇게 생각했는데 생각해보니 이러면 기존 프로젝트는 메세지를 발행하는데 메세지에 특정목적이 생겨버린꼴... 그리고 저렇게 3, 4 번의 과정의 경우 저게 분리가 맞을까? 기존 서비스가 죽으면 신규 프로젝트도 같이 죽는데?? 분리가 맞아? 틀린 방법이였다. 에초에 메시지큐에는 회원가입함, 상품을 수정함, 배송을 시작함 등과같은 발행하는 프로젝트 입장에서 메세지를 발행하고 구독하는 서비스는 알아서 필요한 데이터를 가져다 쓰는것이다. 서로 간섭이 없고 두 서비스중 하나가 죽는다고해서 같이 죽는게 아닌 상황이 되버린..

신규 프로젝트를 들어가며 MSA설계를 하게됐는데.. 어디까지, 어느정도 분리해야하는지 자연스럽게 고민하게 됐다. 신규 프로젝트에 각각의 서비스를 서브도메인으로 분리한후 서브도메인으로 분리해야하나? 처음엔 각 서비스별로 DB를 두고 별도로 운영하는게 좋지않을까? 생각했다. 근데 이게 과연 맞을까? 서비스의 용도를 고려하지않은 설계였다. 프로젝트 A의 경우 트레픽이 많지 않을것으로 예상되었기에 이렇게 진행하는것은 아니라고 판단. 프로젝트 A의 경우 DB를 굳이 나눌 필요가 없다고 판단되었다. 다만 트래픽이 많을것으로 예상되는 서비스3의 경우는 따로 분리해서 서비스하는게 맞다고 결론이 났다. 단순히 MSA를 위한 무조껀적인 분리가 아닌 상황에 따라 범위를 정하고 기술적으로 나누지말고 서비스의 성격, 서비스의 ..

Pub / Sub 패턴 메시징 모델 중의 하나로 발생(publish)과 구독(Subscribe) 로 개념화한 형태 발행자와 구독자는 서로에 대한 정보 없이 특정 주제(토픽 or 채널)를 매개로 송수신 graph LR subgraph Messaging Middleware Topic end Publisher --메시지 발행--> Topic --메시지 구독--> Subscriber 메시지 미들웨어 사용의 장점 비동기: 통신의 비동기 처리 낮은 결합도: 송신자와 수신자가 직접 서로 의존하지 않고 공통 미들웨어에 의존 탄력성: 구성원들간에 느슨한 연결로 인해 일부 장애가 생겨도 영향이 최소화 됨 메지싱 미들웨어 제품들: kafka, RabbitMQ, ActiveMQ 등등 Redis Pub/Sub 특징 메시지가 큐..

캐시 적중(Cache Hit): 캐시에 접근해 데이터를 발견 캐시 미스(Cache Miss): 캐시에 접근했으나 데이터를 발견하지 못함 캐시 삭제 정책(Eviction Policy): 캐시의 데이터 공간 확보를 위해 저장된 데이터를 삭제 캐시 전략: 환경에 따라 적합한 캐시 운영 방식을 선택할 수 있음 캐시 전략 Cache-Aside(Lazy Loading) 항상 캐시를 먼저 체크하고, 없으면 원본(ex: DB)에서 읽어온 후에 캐시에 저장 장점: 필요한 데이터만 캐시에 저장되고, Cache Miss가 있어도 치명적이지 않음 단점: 최초 접근이 느림. 업데이트 주기가 일정하지 않기 때문에 캐시가 최신 데이터가 아닐 수 있음. graph LR Application --1. 읽기 시도--> Cache App..

두 WAS를 띄었을때 JSESSIONID의 값이 다를것인데 graph LR 브라우저 --> 로드발란서 --> 서버1 로드발란서 --> 서버2 @GetMapping("/login") public String login(HttpSession session){ return session.getId(); }세션 아이디를 리턴하게 코드를 짜고 포트 8080과 8081로 따로 WAS를 띄워봤다. 다른 세션ID를 가지고 있다. 세션공유가 안되고있다. Redis사용하기 이런 분산환경에서 redis를 사용한다면? graph LR 브라우저 --> 로드발란서 --> 서버1 --> Redis 로드발란서 --> 서버2 --> Redis 아니 근데 RDB를 사용안하는 이유는? 과연 관계형 데이터 모델이 필요할까? 영속성이 필요한..

목적 : read를 Write 도 하는 Primary한테 부하가집중되는 걸 Secondary로 분산시키는게 주된 목적임. 4.4버전에서 새로생긴 옵션 - 해치드 리드: 각각 샤드에 두번의 요청을 동시에 보내고 둘중 먼저오는 요청을 기준으로 반환을함으로 더 빨리 처리 가능함. 종류: Primary : 무조껀 Primary로 읽기 요청 PrimaryPreferred: 가능하면 Primary에서 읽고 없으면 Secondary로 요청 Secondary: 무조껀 Secondary로 읽기 요청 SecondaryPreferred: 가능하면 Secondary에서 읽고 없으면 Primary로 요청 Nearest: 평균 Ping 시간을 기반으로 지연율이 가장 낮은 멤버로 요청 Secondary 문제점 : 복제가 완료되지않..

기본적으로 적게 검증하고 자주 쓰기 방식의 일관성 모델을 사용하므로 업데이트시 제이터가 즉시 쓰여지지는 않지만 최종적으로는 정확한 결과를 보장한다. Single Document Transaction Replica Set Member Shared Cluster Shard Single Document 원자성 보장 다양한 데이터 타입을 하나의 데이터 객체에 담긴다. Single Document의 크기는 16MB를 초과하지 않느다. Transaction 권장하진 않지만 기능적으로는 존재함 Replica Set Member 동일한 데이터를 여러 맴버에 저장 HA구성 Shared Cluster Shard 데이터 분산이 되어 샤드같에 동일한 데이터를 갖지 않도록 제어

Strings 가장 기본적인 데이터 타입 바이트 배열을 저장 바이너리로 변관할 수 있는 모든 데이터를 저장 가능 최대크기 = 512MB 명령어 기능 예제 SET 특정 키에 문자열 값을 저장 SET say hello GET 특정 키에 문자열 값을 부름 GET say INCR 특정 키에 값을 Integer로 취급하며 1증가 INCR mycount DECR 특정 키에 값을 Integer로 취급하며 1증가 DECR mycount MSET 여러 키에 대한 값을 한번에 저장 MSET key1 value1 key2 value2 MGET 여러 키에 대한 값을 한번에 부름 MGET key1 key2 Lists Linked-list 형태의 자료구조 Queue와 Stack으로 사용할수있음 명령어 기능 예제 LPUSH 리스트..

Redis 사용하는 이유 손쉽게 사용할수있는 In-memory 저장소 높은 성능 다양한 활용성 세션 관리나 캐시 정의 Storage: 데이터 저장소 (데이터 관점) DataBase: 전통적인 DBMS의 역할을 수행한다. NoSQL Middleware: 어플리케이션이 이용할 수 있는 유용한 기능을 제공하는 소프트웨어 장점 아주 빠른 저장소로 활용 분산된 서버들간의 커뮤니케이션 내장된 자료구조를 활용한 기능 구현 In-Memory DB 란 ? 일반적으로 DB는 디스크에 저장하는데 레디스는 메모리(RAM)에 저장한다. 따라서 아주 빠르다. 대신 비싸다. 메모리는 휘발성인데? 지워져서 안되는 중요데이터가 아닌 지워져도 큰 문제가 없는 로그인 세션데이터나 캐시같은 용도로 사용된다. 데이터 저장 구조 DB관점에서의..