Choizz Lately

1. 대칭키(AES, DES)암호화와 복호화에 같은 키를 사용a와 b는 미리 동일한 비밀키를 공유a는 이 비밀키를 사용해 원본 메시지를 암호화하여 b에게 보냄b는 전달받은 암호문을 자신이 가지고 있던 동일한 비밀키로 복호화하여 원본 메시지를 확인1.1 장점속도가 매우 빠름. → 암호화/복호화 과정의 계산이 단순1.2 단점키 배송 문제(key distribution problem)암호화 통신을 시작하기 전에, 송신자와 수신자가 어떻게 안전하게 동일한 비밀키를 공유할 것인가에 대한 문제키가 중간에 탈취되면 모든 암호문이 해독될 수 있음키 관리 어려움통신해야할 상대방이 많아지면, 각 상대방마다 별도의 키를 만들어야함2. 공개키 / 비대칭키(RSA, ECC..)암호화와 복호화에 서로 다른 키를 사용하는 방식2...

안녕하세요!오늘의 포스팅은 AttributeConverter를 이용하여 여러 카테고리를 하나의 칼럼에 저장한 내용입니다. 1. AttributeConverter란?엔티티의 특정 필드 타입을 데이터베이스 컬럼 타입으로 변환하거나 그 반대의 변환을 수행할 때 사용하는 인터페이스입니다.주로 ENUM, 값 객체 등 커스텀 타입을 DB에 원하는 형태로 저장하거나 데이터를 암호화하여 저장해야 할 경우 사용됩니다.2. AttributeConverter 사용 이유저의 프로젝트에서 주요 상품인 영양제는 여러 성분이 포함되어 있어 여러 카테고리에 포함될 수 있습니다.예를 들어, '종합 비타민'이라는 상품은 '피로', 혈액순환', '항산화' 등 여러 카테고리를 가질 수 있습니다. 카테고리가 단순 분류를 위한 것이고 여러 ..

안녕하세요! 이번 포스팅은 제가 팀 프로젝트를 개선하면서 적용한 외부 API 통신 시 시스템의 안정성을 높여주는 서킷 브레이커(Circuit Breaker)와 벌크헤드(Bulkhead) 패턴에 대한 내용입니다. 1. 서킷 브레이커, 벌크헤드가 필요한 이유1.1 장애 전파 방지 및 서버 리소스 보호 외부 API 통신 시, 외부 시스템이 느려지거나 장애가 발생하면, 비즈니스 서버의 응답이 지연되거나 실패할 수 있습니다.예를 들어, 카카오페이 결제 API를 호출한다고 가정할 때, 카카오페이 API가 일시적으로 응답하지 않거나 오래 걸릴 경우, 비즈니스 서버 시스템이 외부 API의 응답을 대기하게 됩니다. 결국, 요청이 계속 쌓이다 사용자는 계속 응답을 대기하고 서버의 리소스는 고갈될 것입니다. 1.2 빠른 ..

안녕하세요!이번 포스팅은 정기 결제 승인 테스트를 할 당시, DB 커넥션 풀(HikariCP) 부족 문제 해결과 관련한 내용입니다. 정기 결제 승인 Mock 서버저는 정기 결제 승인 테스트를 하기 위해서 결제 승인 Mock 서버를 만들었습니다.정기 결제 승인까지 걸리는 지연 시간을 2~5초 정도로 랜덤으로 설정을 하고 테스트를 진행했습니다.네이버 클라우드 서버에서 애플리케이션을 실행시킨 후 로컬에서 Cloudflare Tunnel을 통해 승인 Mock 서버와 통신을 했습니다. 1. 테스트 환경 및 승인 로직테스트 환경: VUser = 100, CPU = 2.0GB, Mem = 4GB테스트 도구: Locust 우선, 외부 API 통신을 위해 WebClient 설정을 해주었습니다. 결제 승인 과정은 시간..

1. 주요 차이점1.1 데이터 전송 방식 및 위치GET : https://www.test.com/search?name=choizz&age=20- URL의 쿼리 스트링을 통해 데이터를 전송- ?뒤에 key=value 형태로 노출- &로 연결=> URL에 데이터가 그대로 드러나므로, 민감한 정보 전송에는 부적합하고 전송할 수 있는 데이터의 양이 제한적POST: - 요청 본문에(Request Body) 데이터를 담아 전송=> URL에 노출되지 않아 비교적 안정성이 높고, 데이터의 양에 제한이 없음1.2 보안성GET :- URL에 데이터가 노출, 북마크, 브라우저 히스토리, 서버 로그에 그대로 기록됨- 스니핑 등의 공격을 당할 경우 데이터 탈취 쉬움POST: - 요청 본문에 포함되므로 GET에 비해 상대적으로 ..

1. Statelessness(무상태성)란?서버가 클라이언트의 상태 정보를 저장하지 않고, 각 요청은 독립적으로 처리되도록 하는 아키텍처 설계 방식 2. 장점1. 서버 확장 용이 (Scalability)서버가 클라이언트의 상태를 저장하지 않기 때문에, 서버 간 상태 공유가 필요 없음서버를 수평적으로 확장하기 쉽고, 로드밸런싱에도 유리2. 단순한 서버 설계세션, 쿠키 등 사용자 상태 관리를 위한 로직이 필요 없어 서버 구현이 단순해짐장애 복구 시에도 상태 복원 부담이 적음3. 높은 안정성과 신뢰성각 요청이 독립적이기 때문에, 이전 요청이 실패해도 전체 흐름에 영향을 주지 않음클라이언트-서버 간의 의존성이 낮아져 유지보수가 쉬워짐4. 캐싱 처리 용이요청 결과가 클라이언트 상태에 의존하지 않기 때문에, 동일한..

안녕하세요!이번 포스트는 Spring에서 어떻게 JSESSIONID 쿠키로 구분하는지를 포스팅하려고 합니다!컨트롤러에서 직접적으로 JSESSIONID 쿠키를 사용하지 않는데 어떻게 세션을 구분하여 찾는지 알아보겠습니다. 1. 서블릿 컨테이너 Session 사용과 조회우선 Spring에서 세션을 사용하는 방식의 간단한 예제를 보여드리겠습니다. 세션 생성 및 저장우선, 세션을 만들고 데이터를 저장합니다.request.getSession()이 호출되면 스프링 부트에 내장된 톰캣이 다음을 수행합니다.- 요청에 JSESSIONID 쿠키가 있는지 확인- 없으면, 새로운 HttpSession 객체와 고유한 세션 ID를 생성하고, 이 ID를 JSESSIONID 쿠키로 만들어 응답에 추가.- 있으면, 기존 HttpSes..

1. 쿠키와 세션의 차이1.1 데이터 저장쿠키: 클라이언트(브라우저)세션: 서버1.2 생명 주기쿠키: 브라우져를 닫아도 만료 기간 설정에 따라 유지 가능세션: 브라우저를 닫으면 기본적으로 삭제, 서버에서 시간 조절 가능1.3 보안쿠키: 클라이언트에 저장되어 변조, 탈취에 취약- pc와 네트워크 전송 구간에서 정보 탈취 가능- 한 번 훔치면 평생 사용 가능 세션: 서버에 저장되어 상대적으로 안전 1.4 데이터 크기쿠키: 약 4kb세션: 서버 설정에 따라 제한 없음 1.5 성능쿠키: 요청마다 헤더에 포함되므로, 크기가 크면 네트워크 부하세션: 세션 id만 주고받으므로 네트워크 부하는 적지만, 서버 부하 발생 2. 로그인 방식2.1 쿠키 로그인/로그아웃종류- 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유..

안녕하세요!이번 포스트는 저번 포스트에 이어서 Spring Batch를 활용하여 정기 결제 프로세스를 개선하는 내용을 다루려고 합니다! 1. 왜 Spring Batch를 사용해야 했는가?Spring Batch(이하 '배치')는 대용량 데이터 처리에 최적화된 프레임워크입니다.로깅, 트랜잭션 관리, 작업 재시작, skip, 리소스 관리 등등 다양한 기능을 제공합니다.또한 배치에서 제공하는 스키마를 통해 Job과 Step에 대한 정보를 알 수 있습니다.그리고 Quartz와 결합하여 스케쥴링도 가능하며, AWS Lamda를 사용에서 스케쥴링 처리도 가능합니다. 저는 정기 결제 상품이 많을 경우, 배치의 청크(Chunk) 단위로 트랜잭션을 관리하는 것이 데이터 처리에 효율적일 것이라고 판단했습니다.청크 단위뿐만..

1. Scoket이란?애플리케이션 레벨(유저 모드)에서 OS(커널)에 접근할 수 있도록 프로토콜을 추상화한 인터페이스리눅스 시스템에서 파일(file)처럼 다뤄지며(메모리상 자료구조), 파일 디스크립터(File Descriptor)를 통해 관리개발자는 소켓을 열고, 특정 주소에 연결하고, 데이터를 쓰고 읽는 방식으로 네트워크 프로그래밍을 할 수 있음.소켓은 '파일'이 아니지만, OS가 '파일처럼' 다룰 수 있게 해주는 '파일 디스크립터'를 통해 접근하는 통신 객체파일 디스크립터 (File Descriptor):운영체제(OS)가 자신이 관리하는 파일이나 입출력 자원(소켓, 파이프 등)에 붙이는 고유한 번호표(정수 값)프로그램은 이 번호표를 통해 특정 파일이나 소켓에 접근하여 데이터를 읽거나 쓸 수 있음2. ..