CI/CD란어플리케이션 개발 단계부터 배포까지 모든 단계를 자동화를 통해 효율적이고 빠르게, 사용자에게 빈번히 배포할 수 있도록 만드는 것이다. AWS로 프로젝트를 배포 후에 자잘한 수정이 있었고, 그럴 때마다 빌드를 새로 하고. jar파일을 다시 업로드해야 하는 귀찮음이 있었다. 자동 배포를 위해 CI/CD파이프라인을 구축하기로 했다. 기존 프로젝트가 있기 때문에 github에 연결해 주었다. EC2에서 빌드와 프로젝트 실행을 할 수도 있지만 빌드의 경우 서버에 많은 부담을 주기 때문에 빌드를 github actions에서 하고 넘겨줄 예정이다 job - step 설정 1. Github Repository에 올린 파일들을 불러오기연결되어 있는 Github Repository에 있는 파일을 불러오는 작업..
jjuya
약 4~5주간 MSA기반 ecommerce프로젝트를 진행했다.기획부터 개발완료 까지 개인 프로젝트로 진행했다. 개인프로젝트의 장점은 내가 프로젝트의 모든 부분을 속속들이 알고 직접 기획하고 계획해야하는 점이 아닐까 하는점이다. 프로젝트를 진행하면서 막힐때는 정말 답답함에 울고 싶었지만 포기하지 않고 자료들을 찾아보고 함께 비슷한 주제를 가지고 프로젝트를 한 동료들과의 팀 스터디를 진행하며 토론하고 질문하며 많은 인프라를 얻을수 있었던거 같다 뒤돌아보면 정말인지 정신 없이 흘러간 4주간이 아닐까 싶다. 그래서 4주간의 프로젝트를 회고해볼까 한다!회고를 하며 프로젝트에 대해 아쉬웠던점과 앞으로 어떤 방향으로 개선하면 좋을지 고민해 보기 위해 이 글을 작성한다. 프로젝트 소개프로젝트 인원 : 개인 프로젝트프..
기술적 의사 결정초기 프로젝트 설계 시, 대규모 트래픽을 처리하고 선착순 구매를 지원하는 시스템을 설계했다.그래서 추후 스케일 아웃을 고려하여 로드 밸런싱을 염두에 두고 Kafka를 선택했다. 비동기 처리를 위해 Kafka로 이벤트를 발행하고, 이를 통해 시스템의 높은 동시성을 유지하며, 트래픽 부하를 효율적으로 분산시킬 수 있도록 설계하였다. Kafka의 비동기 메시징 시스템을 활용함으로써, 결제 처리와 같은 중요한 작업을 병렬로 처리할 수 있어 시스템의 응답성과 확장성을 높일 수 있었다. 결제 로직전체 동기적으로 순차적 수행되던 로직을 kafka를 통해 비동기적으로 이벤트 발행하는 방식으로 수정했다.성능개선 결과10000건 요청 시 성능개선 확인할 수 있었다!TPS( Throughput: 초당 처리한..
Redis 캐싱프로젝트 작업 시 재고 조회를 Redis 캐싱 처리를 해서 관리하고자 한다. 선착순 구매 작업시 많은 사용자들이 재고를 조회하고 그 재고를 바탕으로 주문을 해야 하게 때문에 db에서 재고를 조회하는 대신에 인메모리 db로 동작하는 redis를 선택해 빠르게 데이터를 조회할 수 있도록 하려 한다. 캐싱 방법으로는 로컬 메모리 캐싱, 데이터베이스 캐싱등 여러 방법이 있지만 다양한 데이터 구조를 지원하고 확장성이 뛰어난 Redis를 사용해 캐싱하려 한다! 캐싱 전략캐싱 전략은 웹서비스의 시스템 향상을 기대할수 있는 중요한 기술 중 하나이다.일반적으로 캐시는 메모리를 사용하기 때문에 데이터베이스 보다 훨씬 빠르게 데이터를 응답할 수 있다.메모리는 용량이 크지 않고, 데이터베이스보다 비싸기 때문에 ..
Jmeter 테스트결제 로직을 작성한 후 Jmeter로 테스트를 해보았다.Number of Threads (사용자 수): 1000Ramp-Up Period (래핑 업 시간): 1초Loop Count (루프 카운트): 11000명의 사용자가 동시에 실행되는데 1초 동안 1000명의 사용자가 시작한다.각 사용자가 1회 반복 요청을 보내기 때문에 총 1000번 실행이 되어야 한다. Request{ "productId" : 1, "count" : 1, "addressId": null}1번의 상품을 요청 시마다 하나씩 구매한다.모든 requst가 성공하게 된다면 1000개의 재고가 감소되어야 한다.그렇다면 바로 결과 확인해 보자! 결과 확인 데이터 베이스 확인order는 999개 만들어졌는데 상..
서비스 장애 대응의 필요성MSA구조에서는 각 서비스가 독립적으로 동작하며, 서비스 간의 의존성을 최소화해야 한다.내 프로젝트에서 Order-service에서 다른 서비스로의 요청이 많다.예를 들면 user-service에 사용자 정보 요청이라던가, product-service에 상품요청을 한다.그렇다면 이 상황에서 order-service에서 요청을 보내주는 다른 서비스들에서 응답이 지연되거나 실패하는 경우 어떻게 될까?Order-service의 리소스(예: 스레드풀)가 고갈되어 전체 시스템에 영향을 미쳐 전체 서비스의 장애로 이어질 것이다. 이러한 사항들을 해결하기 위해 Circuit Breaker 패턴을 사용할 것이다Circuit Breaker 패턴 을 구현하면 장애를 빠르게 탐지하고 요청을 차단할 ..
API Gateway란?MSA 아키텍처에서 외부(클라이언트)로부터 각각의 마이크로 서비스로 진입하는 진입점입니다. API Gateway를 공통적으로 사용하여 외부에서는 각 마이크로 서비스를 몰라도 API Gateway의 라우팅을 통해 호출할 수 있습니다.또한 추가적으로 요청에대한 공통 관심사를 API Gateway에서 처리할 수 있습니다. 현재 e-commerce프로젝트에서는 인증 까지 API Gateway 가 해줄수 있게 작업할 예정이다.spring security를 설치하냐 마냐에 대해서도 계속 고민이 되는 지점인 거 같다.하지만 일단 지금시점에서는 API Gateway 에 너무 많은 역할을 부여하지 말아야 한다는 생각으로 시큐리티는 user-service에만 설치할 예정이다. API Gatewa..
Spring BatchSpring Batch는 로깅/추척, 트랜잭션 관리, 작업 처리 통계, 작업 재시작, 건너뛰기, 리소스 관리등 대용양 레코드 처리에 필수적인 기능을 제공한다. 또한 최적화 및 파티셔닝 기술을 통해 대용량 및 고성능 배치 작업을 가능하게 하는 고급 기술 서비스 및 기능을 제공한다. Spring Batch에서 배치가 실패하여 작업 재시작을 하게 된다면 처음부터가 아닌 실패한 지점부터 실행을 하게 된다. 또한 중복 실행을 막기 위해 성공한 이력이 있는 Batch는 동일한 Parameters로 실행 시 Exception이 발생하게 된다. Spring Batch vs Quartz? Scheduler?Spring Batch는 Scheduler가 아니기에 비교 대상이 아닙니다.Spring Bat..
Service Discovery란?서비스의 위치(IP, PORT) 등 저장 및 관리하는 서비스의 주소록 역할을 한다.서비스를 호출하는 쪽에서 서비스의 위치를 몰라도 요청을 전달할 수 있다. Service-Side Discovert / Client-Side DiscoveryServer-Side Discovery : Service Registry가 아닌 앞단의 Load Balancer를 통해 다른 서비스 호출Client-Side Discovery : Service Registry를 통해 서비스 호출 Eureka Server 구현1. 의존성 추가plugins { id 'java' id 'org.springframework.boot' version '3.3.2' id 'io.spring.depe..
Monolithic Architecture란?전통적인 아키텍처, 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어있는 형태모든 프로세스가 강하게 결합되어있고, 단일 서비스에 실행된다.하나의 DB로 관련 도메인의 테이블을 가지고 데이터를 저장한다. 그렇다 보니 단점이 강하게 드러나게 된다도메인 하나의 장애가 서비스 전체에 영향을 미친다각 도메인의 유지보수가 어렵다빌드. 배포시간이 길어서 생산성이 낮다 이러한 단점들을 극복하기 위해 MAS아키텍처가 등장한다 MSA(Micro Service Architecture)란?하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍MSA는 여러 도메인 각각의 독립적으로 구성되어 있는 구조이다. 각각의 서비스가 분리되어 있고..
