웹 개발자 스터디

빈 스코프 싱글톤 기본 스코프 스프링 컨테이너의 시작과 종료까지 유지 됨 프로토타입 스프링 컨테이너가 생성과 의존관계 주입까지만 관여 웹 관련 스코프 request 웹 요청이 들어오고 나갈때 까지의 스코프 session 쉡 세션이 생성되고 종료될 때까지의 스코프 application 서블릿 컨텍스와 같은 범위로 유지되는 스코프 프로토타입 스코프 싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리 프로토타입 스코프는 종료 메서드가 호출되지 않음 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문..

구성 수집기 데이터 수집 스토리지 분리된 데이터를 저장 색인기 검색이 용이하게 수집된 데이터를 분리 검색기 사용자의 질의를 통해 데이터를 검색 인덱스 하나의 인덱스에는 하나의 타입만 존재 HTTP의 RESTful api 사용하여 CRUD 처리 RDBMS의 데이터베이스 엘라스틱서치를 분산 환경으로 구성하면 하나의 인덱스는 여러 노드에 분산 저장 됨 GET 데이터 조회 POST 인덱스 업데이트, 데이터 조회 PUT 데이터 생성 DELETE 데이터 삭제 HEAD 인덱스 정보 조회 인덱스의 샤드 수를 조절하여 대용량 데이터 분산 처리 elasticsearch.yml cluster.name 클러스터 이름 설정 node.name 노드명 설정 path.data 인덱스 저장 경로 path.log 노드와 클러스터에서 생..

producer input의 file 수 마다 인스턴스 개수 생성 (타입으로 구분) OUTPUT의 IF문을 통해 각 타입으로 구분 파이프 라인에서 WORKER수 조정(pipeline.workers: 1,pipeline.batch.size: 1) 분산 처리 및 배치 처리 설정 바이너리 폴더 여러개 실행 (한 로그스테이시당 몇개의 타입을 처리 할지 고려) 현재는 타입 별로 1대 예상 참고 자료 : https://www.elastic.co/guide/en/logstash/current/tuning-logstash.html GROK pattern 참고 자료 : https://github.com/logstash-plugins/logstash-patterns-core/blob/main/patterns/ecs-v1/..

Kafka(카프카) - 대용량 데이터 튜닝(고려 사항) 브로커는 주로 3개로 구성 토픽은 특정 상황 고려하여 구성 파티션과 컨슈머 그룹 개수, 리플리케이션 3 키 값 이용해서 넣을 경우 미리 파티션 정해야함(도중 추가시 매핑 테이블 변경으로 동일 파티션으로 메시지 가지 않을 수 있음) 로그 보관 혹은 삭제 여부 및 기간 마지막 오프셋만 필요할 경우 로그 컴팩션 기능 활용 로그 컴팩션 기능 : 메시지의 키값을 기준으로 마지막 데이터만 보관 JVM 힙 메모리 사이즈 처리량 효율을 위한 파티션 배치 여부 분 당 처리 하기 때문에 배치가 효율적으로 예상(2.4버전이상 스티키 파티션) batch_size 옵션 등 설정 프로듀서 부하 발생 시 압축 고려 부하 테스트 결과 프로듀서에서보단 컨슈머쪽으로 인한 lag 발..

빈 생명주기 콜백 시작 스프링 빈의 간단한 라이프 사이클 객체 생성 의존관계 주입 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 줌 스프링 빈의 이벤트 라이프 사이클 스프링 컨테이너 생성 스프링 빈 생성 의존관계 주입 초기화 콜백 빈이 생성되고 , 빈의 의존관계 주입이 완료된 후 호출 사용 소멸전 콜백 빈이 소멸 스프링 종료 객체의 생성과 초기화를 분리하는 것이 좋음 각자의 역할에 집중하는 것이 좋음(SRP - 단일 책임 원칙)⇒ 단순 작업의 경우 같이 처리하는 것이 효율 적일 수도 있음 ⇒ 무거운 작업이 있을 경우 인터페이스 InitializingBean, DisposableBean..

다양한 의존관계 주입 방법 생성자 주입 생성자를 통해서 의존관계를 주입 생성자 호출시점에 딱 1번만 호출되는 것이 보장 불변과 필수 의존관계에 사용 생성자가 1개만 존재하면 @Autowired를 생략해도 자동 주입이 됨(스프링 빈만 해당) setter 주입 setter 메서드를 통해서 의존관계를 주입 선택, 변경 가능성이 있는 의존관계에 사용 주입대상이 없을 경우에 대비하여 @Autowired(required = false)로 지정 필드 주입 필드에 바로 의존관계를 주입 외부에서 변경하기 어렵기 때문이 추천하지 않는 방식 => 테스트하기 어려움 일반 메서드 주입 일반 메서드를 통해서 주입 받을 수 있음 잘 사용하지 않음 옵션처리 자동주입 대상 옵션처리 @Autowired(required=false) : ..

카프카 기초 ------------------------------------------------------------------------------ [카프카의 개념] 실시간 분산 스트리밍 플랫폼 => 메시지 브로커 producer, consumer 가 존재하여 로그를 처리 producer, consumer의 커플링을 약하게 해줌 큐와 비슷한 개념인 토픽이 존재 ------------------------------------------------------------------------------- [토픽] 데이터가 들어가는 공간 여러개 존재 가능 producer가 데이터를 넣고 consumer가 데이터를 가져가 사용 =>consumer는 오래된 순서대로 데이터를 가져감 consumer가 가져가더..

컴포넌트 스캔과 의존관계 자동 주입 컴포넌트 스캔 설정 정보 없이 자동으로 스프링 빈을 등록 해주는 기능 설정 파일에 @ComponentScan 사용 excludeFilters를 사용하여 특정 클래스를 제외 가능 @Component 어노테이션이 붙은 클래스를 스캔하여 스프링 빈으로 등록 => ("빈 이름")으로 수동적으로 빈 이름 지정 가능 의존 관계를 위해서 @Autowired를 이용해 자동 의존 주입을 이용해야 함 @Autowired 의존 관계주입을 자동으로 주입 해주는 기능 타입이 같은 빈을 찾아 주입 탐색 위치와 기본 스캔 대상 탐색 위치 @ComponentScan의 옵션으로 basePackages를 이용해 시작 위치를 지정할 수 있음 basePackagesClasses를 통해 클래스 지정 후 해..

웹 애플리케이션과 싱글톤 웹 애플리케이션은 보통 여러 사용자가 동시에 요청을 함 동시 요청시 때 마다 매번 객체를 생성하지 않음 순수한 DI 컨테이너는 객체를 호출할 때 마다 계속해서 생성 => 과도한 트래픽이 발생할 경우 메모리 낭비 심함 => 싱글톤을 이용해 1개만 생성하여 공유 하도록 함 싱글톤 패턴 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴 일반적으로 static 영역에 instance를 미리 하나 생성하여 올려두고 getter를 통해서만 받을 수 있게 한다. 혹시라도 생성하지 못하게 생성자는 private으로 막는다. 스프링 컨테이너는 모든 빈 객체를 싱글톤 패턴으로 관리 함 #문제점 구현하는데 코드 자체가 많이 들어감 DIP 위배 (구체 클래스에 의존) OCP 위배할 가..

권한(permission) - 권한 유닉스에서 권한은 읽기,쓰기,실행 으로 제한 권한의 대상은 파일, 디렉토리 - rw-rw-r-- 1 owner group 0 Dec 10 22: 10 samp.txt - : type을 의미 rw-rw-r-- : access mode를 의미 각 3개씩 3등분 가능 첫번째 분할 : owner access 권한 두번째 분할 : group access 권한 세번째 분할 : other access 권한 r : read, w : write, x : execute owner group : 각각 owner,group를 의미 - chmod chmod : access mode를 변경할 수 있음 chmod (u,g,o)(+,-)(r,w,x)(파일명) 디렉토리에서 x는 접속 여부를 의미