Racon

1. 롤링 배포 (Rolling Deployment)설명:점진적 업데이트: 전체 시스템을 동시에 업데이트하지 않고, 시스템의 일부 인스턴스에서만 새 버전을 점진적으로 배포합니다.작업 방식: 기존 인스턴스를 하나씩 교체하면서 새로운 버전을 배포하고, 전체 시스템이 새 버전으로 완전히 전환될 때까지 계속됩니다.장점:무중단 배포: 전체 시스템이 항상 운영 중이므로 서비스 중단 없이 배포할 수 있습니다.리소스 효율적: 한 번에 전체 시스템을 업데이트할 필요가 없으므로 리소스를 절약할 수 있습니다.단점:상태 불일치: 새로운 버전과 기존 버전이 동시에 운영되기 때문에, 버전 간의 호환성 문제를 주의해야 합니다.문제 발견 시 롤백 어려움: 문제가 발생하면 이미 업데이트된 인스턴스와 업데이트되지 않은 인스턴스가 혼재하..

Pub/Sub이란? 메시징 모델 중의 하나로 발행(Publish)와 구독(Subscribe) 역할로 개념화 한 형태 발행자와 구독자는 서로에 대한 정보 없이 특정 주체(토픽 or 채널)을 매개로 송수 Messaging Middleware 사용의 장점 비동기 : 통신의 비동기 처리 낮은 결합도 : 송신자와 수신자가 직접 서로 의존하지 않고 공통 미들웨어에 의존 탄력성 : 수정원들간에 느슨한 연결로 인해 일부 장애가 생겨도 영향이 최소화됨 Messaging Middleware 제품들 : Kafka, RabbitMQ, ActiveMQ Redis의 Pub/Sub 특징 Message Queue에 저장 되지 않음 온라인으로 떠있는 Subscriber에게만 메시지가 전송된다. Kafka의 컨슈머 그룹 같은 분산 처리..

캐싱(Caching) Cache : 성능 향상 을 위해 값을 복사해놓는 임시 기억 장치 Cache에 복사본을 저장해놓고 읽음으로서 속도가 느린 장치로의 접근 횟수를 줄임 Cache의 데이터는 원본이 아니며 언제든 사라질 수 있다 캐시의 적용 네트워크 지연 감소 서버 리소스 사용감소 병목현상 감소 원칙 : 더 빠르고 값사게 가져올 수 있다면 캐시를 사용한다. 캐싱 관련 개념들 캐시 적중 (Cache Hit) : 캐시에 접근해 데이터를 발견함 캐시 미스(Cache Miss) : 캐시에 접근했으나 데이터를 발견하지 못함 캐시 삭제 정책(Eviction Policy) : 캐시의 데이터 공간 확보를 위해 저장된 데이터를 삭제 캐시 전략 : 환경에 따라 적합한 캐시 운영 방식을 선택 할 수 있음(Cache-Asid..

세션관리를 위한 서버의 역할 세션 생성 : 요청이 들어 왔을때 세션이 없다면 만들어서 응답에 set-cookie로 넘겨줌 세션 이용 : 요청이 들어왔을때 세션이 있다면 해당 세션의 데이터를 가져옴 세션 삭제: 타임아웃이나 명시적인 로그아웃 API를 통해 세션을 무효화함 모든 요청에 대해서 Cookie를 파싱해 확인하고, 세션 생성 시에는 set-cookie 값가지 설정해야 위 동작을 쉽게 해주는 Spring Boot 도구 - HttpSession 세션을 손쉽게 생성하고 관리할 수 있게 해주는 인터페이스 UUID로 세션 ID를 생성 JSESSIONID라는 이름의 Cookie를 설정하여 내려줌 ex) @GetMapping("/hello") public String hello(HttpSession sessio..

Session 정의 네트워크 상에서 두 개 이상의 통신장치간에 유지되는 상호 연결 연결된 일정 시간 동안 유지되는 정보를 나타냄 적용 대상에 따라 다른 의미를 가짐 Web 로그인 세션 Web 상에서 특정 유저가 로그인했음을 나타내는 정보 브라우저는 Cookie를, 서버는 해당 Cookie에 연관된 세션 정보를 저장 유저가 로그아웃 하거나 세션이 만료될 때 까지 유지되어 유저에 특정한 서비스 가능 Web 로그인 과정 분산 환경에서의 세션 처리 Server는 세션 정보를 저장 해야 함 Server가 여러 대라면 최초 로그인한 Server가 아닌 Server는 세션 정보를 알지 못함 세션 정보를 Server간에 공유할 방법이 필요(Session Clustering) 분산 환경에서의 세션 처리 - RDB 사용시..

동시성 제어 방법 게시물에 컬럼을 추가를 통한 구현 비관적 락, 낙관적 락 구성 조회시 컬럼만 읽어오면됨(장점) 쓰기시 게시물 레코드에 대한 경합이 발생(병목 발생) 하나의 자원(게시물)을 두고 락 대기 같은 회원이 하나에 게시물에 대해 여러번 좋아요를 누를수있음(문제 발생) 테이블 추가를 통한 구현 낙관적락, 비관적락 으로 해결 하기 힘들때 구성 조회시 매번 count쿼리 연산(병목 발생) 쓰기시 경합없이 인서트만 발생(장점) 회원정보등 다양한 정보 저장 가능(장점) 위 방법 중 병목 발생 1 > 2 -> 쓰기 지점의 병목은 하나의 레코드를 점유 하고 있다. 2 > 1 -> 조회 지점의 병목은 카운트 쿼리를 매번 읽는다. 병목 해결 방법 이전에 프로세스에 대한 성질을 우선 이해한다. 좋아요 수는 높은 ..

비관적 락/PESSIMISTIC 동시성 제어를 위한 가장 보편적인 방법 락을 통한 줄세우기 단점 락을 통한 동시성 제어는 불필요한 대기 상태를 만듬 동시성이 빈번하지 않은 쿼리로 인해 다른 쿼리가 대기 된다. 낙관적인락/ Optimistic Lock 동시성 이슈가 빈번하지 않길 기대하고, 어플리케이션에서 제어한다. 단점 실패에 대한 처리를 직접 구현해야 한다. CAS(Compare And Set)을 통해 제어 Compare/비교 그리고 Set/설정 비교해서 맞으면 설정 틀리면 설정 안한다. 예) 이름 잔액 버전 홍길동 1000 1 트랜잭션_1 READ_홍길동 잔고 -> 1000, (1) 트랜잭션_2 READ_홍길동 잔고 -> 1000, (1) 트랜잭션_1 UPDATE(홍길동 잔고 -100), (2) WH..

트랜잭션을 테스트 해보기 위해서 다른 SQL편집기를 열어서 테스트 해야한다. 테스트 방법 START TRANSACTION; 트랜잭션을 실행한다. QUERY문 실행 SELECT .... FOR UPDATE를 해야 쓰기락이 걸린다. 완료후 COMMIT한다. 트랜잭션 및 락 상태 확인 락 상태 확인 SELECT * FROM performance_schema.data_locks WHERE LOCK_TYPE = 'RECORD'; 여러 ROW가 출력되는 이유는 여러 락이 동시에 잡혀서 그런다. LOCK_MODE가 X 는 쓰기락이 잡혀있다라는 뜻이다. INDEX_NAME : 어느 인덱스에 락이 잡혀있는지 출력된다. LOCK_DATA : Index VALUE 트랜잭션이 상태 확인 SELECT * FROM informa..

동시성 제어를 위한 가장 보편적인 방법 락을 통한 줄세우기 (순차적인 실행) 중요_1! 락을 통해 동시성을 제어할 때는, 락의 범위를 최소화 하는 것이 중요 락을 유지 하는동안 다른 트랜잭션 또한 대기 하게 되고 그러면 서버 성능이 낮아 진다. 최악의 경우에는 단일 쓰레드와 같은 효과를 볼수 있다. Connection Pool을 관리 하는 경우에 Connection Pool 고갈이 발생할수 있다. MySQL에서 락의 범위를 잡는 방법 MySQL에서는 트랜잭션의 커밋 혹은 롤백시점에 잠금이 풀린다. 즉. 트랜잭션이 곧 락의 범위 이다. MySQL에서 락의 범위를 줄인다. == 하나의 트랜잭션을 최소화 한다 예) S3 업로드가 트랜잭션에 추가가 되어 있다 S3 업로드 하는 중에도 트랜잭션이 유지 되므로 S3..

설명 여러개의 타입(콘텐츠, 미디어) 별 통계,정산 하는 추상 팩토리 패턴 생성 // 통계 인터페이스 interface 통계 { fun 작업1() } // 정산 인터페이스 interface 정산 { fun 작업2() } // 콘텐츠통계 class 콘텐츠통계 : 통계 { override fun 작업1() { println("콘텐츠통계 작업1") } } // 미디어통계 class 미디어통계 : 통계 { override fun 작업1() { println("미디어통계 작업1") } } // 콘텐츠정산 class 콘텐츠정산 : 정산 { override fun 작업2() { println("콘텐츠정산 작업2") } } // 미디어정산 class 미디어정산 : 정산 { override fun 작업2() { prin..