feel_2

Pod Template 관리jenkins 관리 > Clouds > kubenetes > Pod Templatesdefault or Add a pod templatepod template 선택 > Add Container > container 추가 > 저장 Pipeline 형식pipeline: 우선 가장 먼저 pipeline을 선언, pipeline은 최상위 레벨이 되어야하며 { }으로 정의해야 한다.pipeline {/* insert Declarative Pipeline here */ }pipeline은 Section, Directives, Steps 또는 assignment 문으로만 구성되야 한다.sectionagent: agent를 추가할 경우에 사용 (any, none, label, node, do..

기존에 있던 lib 업로드 1. repository 생성nexus에 로그인 후, create repository 클릭maven2 (hosted) 클릭 새로 만들 repository 내용 작성 Name: 새로 만들 repository 이름Version policy: 어떤 타입의 repository를 만들 것인가Deployment policy: 배포 방법  다 기입 후 Create repository 클릭 2. Repository access Role 생성Roles > Create Role 클릭  Role 내용 작성Type: Nexus roleRole ID: Role IDRole Name: Role Name3가지 작성 후, Modify Applied Privileges 클릭 아까 만든 repository 명..

1. 이미지 다운로드 및 저장인터넷이 연결된 환경에서 필요한 도커 이미지를 다운로드합니다:docker pull :다운로드한 이미지를 tar 파일로 저장합니다:docker save -o .tar :ex) ‘nginix’ 이미지를 다운로드할 경우docker pull nginx:latestdocker save -o nginx.tar nginx:latest2. 이미지 파일 이동scp, ftp, sftp 등 파일 전송 명령어는 많다.scp를 사용한 예는 다음과 같다.scp [옵션] [파일명] [원격지_id]@[원격지_ip]:[받는위치]scp image.tar root@172.10.50.208:~3. 이미지 로딩 및 태깅폐쇄망 환경에서 tar 파일을 로드합니다:docker load -i nginx.tar로드한 이미..

현업에서 장애는 예상치 못한 곳에서 항상 발생한다.피할 수 없다면 적극적으로 예방하고, 장애 발생 시 유연하고 빠르게 대처해야 하며, 같은 장애가 재발되지 않도록 조치를 취해야 한다.현업에서의 장애 대응 프로세스는 보통 장애 탐지 및 전파장애 분류 및 해결장애 복구 및 보고장애 회고이렇게 진행된다고 보면 된다.현업에서 장애를 빠르게 감지하기 위해서는 로깅, 모니터링 등의 방법이 있는데, 장애 상황을 감지하기 위해 다양한 조건을 설정하고 모니터링을 통해 장애 확산을 방지할 수 있다.그럼 우리가 자주 볼 수 있는 장애는 어떤 것들이 있고, 어떻게 대응을 하면 좋을지 같이 살펴보자. 외부 서비스 장애 Kafka 사례: 디스크 공간 부족으로 인해 Kafka Broker를 사용할 수 없음실패 원인: Kafka 브..

목적서비스의 기본적인 성능 테스트 및 예상치 못한 병목 현상이나 장애 상황에 대비하기 위해서 진행한다. 대상 API 콘서트 대기열 시나리오 에 있는 모든 API를 대상으로 테스트를 진행한다.GETapi/v1/concertsapi/v1/concerts/{concertId}api/v1/concerts/{concertId}/datesapi/v1/concerts/dates/{concertDateId}/seatsapi/v1/users/{userId}/balanceapi/v1/reservations/{userId}POSTapi/v1/payments/payapi/v1/reservationsapi/v1/queues/tokenPATCHapi/v1/{userId}/chargeDELETEapi/v1/reservations/..

문제결제 API 쪽 비즈니스 로직의 트랜잭션 생명주기가 길다.결제 API 쪽을 한번 살펴보자.@Component@RequiredArgsConstructorpublic class PaymentFacade { private final PaymentService paymentService; private final UserService userService; private final ConcertService concertService; private final WaitingQueueService waitingQueueService; /** * 결제 요청하는 유즈케이스를 실행한다. * * @param command reservationId, userId 정보 ..

조회를 할 때 데이터가 얼마 없을 때는 상관없지만, 데이터가 수천, 수만 건의 경우 인덱스가 있냐 없냐의 따라 성능 차이가 엄청 크다고 한다.보통 인덱스는 카디널리티가 높은(중복도가 낮은) 컬럼으로 설정한다고 한다. (참고로 pk는 기본으로 인덱스로 설정되어 있음)예를 들어 주민등록번호의 경우 카디널리티가 높다고 할 수 있다.(Unique 하기 때문에)지금 나의 시나리오(콘서트 대기열)에서 인덱스 추가를 통해 성능을 개선할 수 있는 부분이 있는지 알아보자. 문제콘서트 예약 가능한 좌석을 조회하는 API 의 경우, 실제로 하나의 콘서트장에 5만명이 앉을 수 있는 대형 장소에서 하는 경우가 많다. 콘서트가 1만개만 있어도, 콘서트 좌석 조회하는 데이터는 5억개의 자리의 데이터가 들어가 있을 것이다. 원인테스..

캐시란?캐시는 자주 액세스하거나 계산 비용이 많이 드는 데이터를 일시적으로 저장하는 데 사용된다. 데이터에 액세스하는 데 걸리는 시간을 줄이고, 느린 리소스나 시스템의 로드를 줄여 성능을 향상시키는 데 도움이 된다.그럼 캐시를 사용하기 위한 적절한 데이터의 판단 기준은 무엇일까?데이터가 변경에 민감한지?데이터의 연산에 드는 비용이 비싼지?데이터의 변경이 전파가 되는지?→ 요약하자면, “잘 바뀌지 않으면서 접근할 일이 많은 데이터, 변경되더라도 다른 서비스에 큰 영향을 미치지 않는 데이터” 가 캐시에 저장하여 활용하기 적절하다.그럼 DB에서 계산 비용이 많이 드는(쿼리를 날렸을 때 시간이 오래 걸리는) 경우는 어떤 경우들이 있을까?조인이 복잡할 경우복잡한 조인 조건이 있는 여러 테이블과 관련된 쿼리, 특히..

제가 콘서트 예약시스템에서 구현한 대기열에 대한 설계에 대해서 얘기해보겠습니다. 대기열이란?대기열 시스템은 많은 사용자들이 동시에 접근하는 상황에서, 시스템의 안정성과 성능을 보장하기 위해 필수적인 요소입니다. 특히, 티켓 예매, 상품 구매, 서비스 예약 등과 같은 상황에서 대기열 시스템이 중요한 역할을 합니다.만약 1000명의 유저가 동시에 좌석 예약을 위해 요청을 보낸다면, 정해진 선착순 100명만 예약이 가능하게 하고, 나머지는 대기열에서 대기하게 됩니다.이렇게 하면 트레픽의 유량을 제어할 수 있기 때문에 서버의 부하를 줄일 수 있습니다. 대기열에 있는 유저는 일정 시간이 지나면 좌석 예약이 가능하게 되어 콘서트 좌석을 예약할 수 있습니다. 대기열 구현 방법전통적으로? 대기열을 구현하는 방식에는 크..