지민 개발 블로그

Amazon Simple Queue Service(Amazon SQS)는 내구력 있고 가용성이 뛰어난 보안 호스팅 대기열을 제공하며 이를 통해 분산 소프트웨어 시스템과 구성 요소를 통합 및 분리할 수 있습니다. Amazon SQS는 배달 못한 편지 대기열 및 비용 할당 태그와 같은 공용 구성을 제공합니다. 또한 AWS SDK가 지원하는 모든 프로그래밍 언어로 액세스할 수 있는 일반 웹 서비스 API를 제공합니다. 보안 - Amazon SQS 대기열에 메시지를 보내고 받을 수 있는 사람을 제어합니다. 기본 Amazon SQS 관리형 서버 측 암호화(SSE)를 사용하거나 AWS Key Management Service(AWS KMS)에서 관리되는 사용자 지정 SSE 키를 사용하여 대기열에 있는 메시지의 콘텐..

Kinesis에서 Lambda를 함께 사용하는 이유 자동화된 데이터 처리: Kinesis에서 수집하는 대량의 실시간 데이터 스트림을 Lambda 함수를 통해 자동으로 처리할 수 있다. 이를 통해 복잡한 서버 관리나 데이터 처리 파이프라인 구축 없이도 데이터를 실시간으로 분석하고 반응할 수 있다. 유연성과 확장성: Lambda는 요청 수에 따라 자동으로 확장되므로, 데이터 스트림의 크기나 처리 요구가 변동되더라도 문제 없이 대응할 수 있다. 이는 데이터 볼륨이 예측 불가능하거나 급변하는 애플리케이션에 특히 유용하다. 비용 효율성: Lambda는 실행 시간에만 비용을 지불하는 모델을 따르므로, 사용하지 않는 시간에는 비용이 발생하지 않는다. 이는 대량의 데이터를 처리해야 하는 작업에서 경제적으로 매우 유리하..

전송된 정보를 수집하거나 정보를 전송할 때 사용되는 디지털 방식으로 암호화 된 일관된 신호의 흐름 짧은 대기 시간 처리를 목표로 계속해서 증분하는 방식으로 내보내지는 대용량 데이터 특징 시간순 중요성: 데이터 스트림의 각 요소에는 타임 스탬프가 포함된다. 지속적 흐름: 데이터 스트림에는 시작도 끝도 없다. 요구되는 만큼 데이터를 끊임없이 지속적으로 수집한다. 고유성: 정확한 실시간 데이터 처리가 중요하다. 비균질성: 데이터 변형을 처리할 수 있는 기능이 있어야 한다. 불완전성: 소스의 일시적인 오류는 스트리밍된 데이터 내의 요소에 손상 또는 누락을 유발할 수 있다. 사용되는 이유(중요한 이유) 무한한 데이터 볼륨: 스트림 소스로부터 생성된 데이터 볼륨은 굉장히 크기 마련이고, 이에 따라 스트리밍 데이터의..

본 게시물은 김영한 선생님의 강의를 학습하며 작성하였습니다. 두 개의 컴포넌트 annotation을 달 경우에 아래와 같은 에러 문구가 뜬다. 하나의 빈을 기대했는데 2개가 나왔다고 알려준다!! 하위 타입으로 짖어할 수도 있는데, 하위 타입으로 지정하는 것은 DIP를 위배하고 유연성이 떨어진다. 그리고 이름만 다르고, 완전히 똑같은 타입의 스프링 빈이 2개 있을 때 해결이 안된다. 스프링 빈을 수동 등록해서 문제를 해결해도 되지만, 의존 관계 주입에는 해결하는데 다양한 방법이 있다. 조회 대상 빈이 2개 이상일 때 해결 방법 @Autowired 필드 명 매칭 @Qualifier → @Qualifier 끼리 매칭 → 빈 이름 매칭 @Primary 사용 @Autowired 필드 명 매칭 autowired는 ..

본 게시물은 김영한 선생님의 강의를 학습하며 작성하였습니다. 막상 개발을 해보면, 대부분이 다 불변이고, 그래서 생성자에 final 키워드를 사용하게 된다. 🤔 그러나 생성자도 만들어야 하고, 주입 받은 값을 대입하는 코드도 만들어야 하고… 필드 주입처럼 간편하게 사용하는 방법은 없을까?! 아래 코드를 최적화하도록 해보겠다. 롬북 라이브러리 셋팅 repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot:spring-boot-starter' //lombok 라이브러리 추가 시작 compileOnly 'org.projectlombok:lombok' annotationProcesso..

본 게시물은 김영한 선생님의 강의를 학습하며 작성하였습니다. 과거에는 생성자 주입과 필드 주입을 많이 사용했지만, 최근에는 스프링을 포함한 DI 프레임워크 생성자 주입을 권장한다. “불변” 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료 시점까지 의존관계를 변경할 일이 없다. 수정자주입을 사용하면, 수정자를 public으로 열어두어야한다. 누군가 실수로 변경할 수도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다. 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에는 호출되는 일이 없다. 따라서 불변하게 걸계할 수 있다. “누락” 프레임워크 없이 순수한 자바 코드를 단위 테스트 하는 경우에 수정자 의존관계인 경우 ⭐️Final 키워드 생성자 주입을 사용하면 fin..

본 게시물은 김영한 선생님의 강의를 학습하며 작성하였습니다. 옵션 처리 주입할 스프링 빈이 없어도 동작해야 할 때가 있다. 그런데 @Autowired만 사용하면 required 옵션의 기본값이 true로 되어 있어서 자동 주입 대상이 없으면 오류가 발생한다. 자동 주입 대상을 옵션으로 처리하는 방법은 다음과 같다 @Autowired(required=false): 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨 org.springframework.lang.@Nullable: 자동 주입할 대상이 없으면 null이 입력된다. Optional: 자동 주입할 대상이 없으면 Optional.empty가 입력된다. package com.hello.core.autowired; import com.hello...

다양한 의존관계 주입 방법 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 🍪 이름 그대로 생성자를 통해서 관계를 주입하는 방법이다. 지금까지 우리가 진행했던 방식! 특징 생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다. ”불변, 필수” 의존관계에 사용 바꿀 예정이 있으면 이런식으로 하면 안된다. 수정자 주입(setter 주입) 🍪 setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입하는 방법이다. 특징 ”선택, 변경” 가능성이 있는 의존 관계에서 사용 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법이다. private MemberRepository memberRepository; private DiscountPolicy ..

본 게시물은 김영한 선생님의 강의를 학습하며 작성하였습니다. 컴포넌트 스캔과 의존관계 자동 주입 시작하기 지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 설정 정보에 직접 등록할 스프링 빈을 나열했다. 예제에서는 몇개가 안되었지만,이렇게 등록해야 할 스프링 빈이 수십, 수백개가 되면 일일이 등록하기도 귀찮고, 설명 정보도 커지고, 누락하는 문제도 발생한다. 역시 개발자는 반복을 싫어한다.(무엇보다 귀찮다) 그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 지공한다. 또 의존관계도 자동으로 주입하는 @Autowired라는 기능도 제공한다. 탐색 위치와 기본 스캔 대상 @Configuration @ComponentScan( // baseP..

본 게시물은 김영한 선생님의 강의를 학습하며 작성하였습니다. @Configuation은 singleton을 위해 존재!! package com.hello.core.singleton; import com.hello.core.AppConfig; import com.hello.core.member.MemberRepository; import com.hello.core.member.MemberServiceImpl; import com.hello.core.order.OrderServiceImpl; import org.assertj.core.api.Assertions; import org.junit.jupiter.api.Test; import org.springframework.context.annotation.A..