@Async 을 활용하기 위해 쓰레드 관련 설정 정보를 추가한다.

 

@Configuration
@EnableAsync
public class AsyncConfig {
    private final int CORE_POOL_SIZE = 3;
    private final int MAX_POOL_SIZE = 10;
    private final int QUEUE_CAPACITY = 100_000;

    @Bean(name = "eventHandlerTaskExecutor")
    public Executor threadPoolTaskExecutor(){

        ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();

        taskExecutor.setCorePoolSize(CORE_POOL_SIZE);
        taskExecutor.setMaxPoolSize(MAX_POOL_SIZE);
        taskExecutor.setQueueCapacity(QUEUE_CAPACITY);
        taskExecutor.setThreadNamePrefix("Executor-");

        return taskExecutor;
    }
}

 

이벤트 관련 Dto Class 를 만들며 이를 Postfix로 -Event 로 하여 만들었다

 

@Getter
@Setter
@Builder
@NoArgsConstructor(access = AccessLevel.PRIVATE)
@AllArgsConstructor
public class InviteAccountEvent {
	,,,
}

 

EventListener 관련 클래스를 정의하여 내가 보내고자 하는 큐를 이벤트로 잡아 보낸다.(@TransactionPhase.AFTER_COMMIT 중요)

 

@RequiredArgsConstructor
@Component
public class AccountEventListener {

    private final SqsAccountPublisher accountPublisher;

    @Async(value = "eventHandlerTaskExecutor")
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void sendInviteMail(InviteAccountDetailEvent event) {
        accountPublisher.inviteAccountDetail(event);
    }
}

 

실제 Event를 Publish하는 Service Class 를 확인해 보자면

 

@RequiredArgsConstructor
@Transactional
@Service
public class AccountManageService { 

	private final ApplicationEventPublisher publisher;
    
    public void method(InviteAccountEvent request) {
    	publisher.publishEvent(request);
    }
}
반응형

수많은 도커 컨테이너중 특정 prefix로 시작하는 컨테이너만 제거 하고 싶을 때 사용되어지는 명령어를 정리했다.

 

sh "docker rmi -f \$(docker image ls | egrep '서비스명' | awk '{print\$3}')"
반응형

'Docker' 카테고리의 다른 글

docker 관련 정리  (0) 2023.02.15

CloudFront를 사용하여 AWS S3에 접근하는 것이 직접적으로 S3에 연결하는 것보다 좋은 이점이 몇가지 있다.

1. 성능 및 속도 향상: CloudFront는 캐싱 및 콘텐츠 전송 네트워크(CDN)를 제공하여 전 세계 사용자에게 빠른 성능을 제공한다. 사용자가 가장 가까운 위치에 있는 엣지 로케이션에서 콘텐츠를 제공하기 때문에 지연시간이 줄고 성능이 향상된다.

2. 보안 향상: CloudFront는 HTTPS를 통해 콘텐츠를 안전하게 전송할 수 있다. 또한 AWS WAF와 통합하여 보안을 강화 할 수 있다.

3. 확장성: CloudFront는 높은 확장성을 제공한다. 전 세계적으로 수천 개의 엣지 로케이션을 보유하고 있어, 사용자 트래픽이 증가해도 성능에 영향을 미치지 않는다.

4. 비용절감: CloudFront는 요청당 요금제를 적용하기 때문에 트래픽이 적은 경우에는 비용이 크게 증가하지않으며, 또한 캐싱을 통해 S3에서 직접 콘텐츠를 제공하는 것보다 비용을 줄일 수 있다. 

5. 고급 기능 제공: CloudFront는 다양한 기능을 제공하여 콘텐츠 제공을 더욱 효율적으로 관리할 수 있다. 예를 들어 캐싱 제어, 요청 라우팅, 사용자 정의 도메인 설정 등의 기능을 활용할 수 있다. 

CloudFront 서비스에 배포생성을 클릭하면

 

CloudFront의 Origin domain을 클릭하면 등록된 버킷 리스트 목록이 나열되며 이때 위에서 설정한 S3를 연동한다. 또한 원본 엑세스의 설정 정보를 원본 엑세스 제어설정(권장)으로 표기한다.

Create new OAC 를 통해 아래와 같이 생성한다

설정 탭에서 가격분류는 아래와 같이 설정하며 또한 사용자 정의 SSL은 기존에 등록되어있는 것을 활용한다.

위의 정보를 통해 배포 생성 버튼을 클릭하게 되면 아래와 같이 S3의 버킷 정책을 업데이트 하라는 문구와 함께 정책 복사 버튼이 존재하고 이를 복사하여 연결한 S3 버킷 권한으로 이동하여 버킷 정책 편집을 통해 복사한 정책을 붙여넣는다

아래는 위에서 언급한 버킷 정책 편집 화면이다.

 

Route53 설정을 통해 특정 도메인 이름으로 접근 가능하게 설정을 해보도록 하자

우선 호스팅 영역 페이지에 들어가 레코드 생성 버튼을 통해 별칭을 통한 트래픽 라우팅 대상 설정 및 등록을 아래와 같이 하게 되면 Route53의 설정한 도메인으로 CloudFront 접속이 가능하게 된다.

 

위의 배포 선택 부분은 앞서 CloudFront의 배포 탭으로 가자면 도메인 이름으로 xxxx.cloudfront.ne t이 보이는데 이를 입력해주면 된다.

 

반응형

AWS LB는 크게 세가지 타입으로 설정하게 되어있으며 ALB(Application Load Balancer), NLB(Network Load Balancer), GLB(Global Load Balacer) 가 있다.

 

1. ALB

  • OSI 모델에 Layer 7 계층에서 동작
  • HTTP/HTTPS 로드 밸런싱: ALB는 HTTP 및 HTTPS 트래픽을 처리하도록 설계 되었으며 고급 라우팅 기능을 제공
  • 콘텐츠 기반 라우팅: ALB는 콘텐츠 기반 라우팅을 지원하며 요청의 콘텐츠를 기반으로 라우팅 할 수 있다.(호스트 기반 라우팅 및 경로 기반 라우팅)
  • SSL 종료: ALB는 SSL 연결을 종료할 수 있어 백엔드 서버로부터 SSL 처리를 분리 할 수 있다.

2. NLB

  • OSI 모델에 Layer 4 계층에서 동작
  • TCP/UDP 로드 밸런싱: NLB는 TCP 및 UDP 트래픽을 처리하도록 설계되었다.
  • NLB는 고정 IP 주소를 제공하여 클라이언트가 로드 밸러서에 연결 할 수 있다. 이는 고정된 IP 주소가 필요한 응용 프로그램에 적합
  • 고 처리량 및 낮은 지연: NLB는 고 처리량과 낮은 지연을 위해 설계뙤었으며 종종 극단적인 성능이 필요한 응용 프로그램에 사용

3. GLB (Global Accelerator):

  • 글로벌 로드 밸런서: GLB는 여러 AWS 리전에 걸쳐 응용 프로그램을 배포할 수 있는 글로벌 서비스입니다.
  • 애니캐스트를 사용한 IP: GLB는 애니캐스트 IP 주소를 사용하여 트래픽을 최적의 AWS 엔드포인트로 라우팅합니다. 이는 건강 상태, 지리 및 라우팅 정책을 기반으로 합니다.
  • 고정 애니캐스트 IP: GLB는 클라이언트가 전 세계적으로 연결하는 데 사용되는 정적 애니캐스트 IP를 제공하며 자동으로 최적의 엔드포인트로 트래픽을 전달합니다.
  • 내장 DDoS 방어: GLB에는 내장된 DDoS(분산 서비스 거부) 방어 기능이 포함되어 있습니다.

요약하면, ALB 응용 계층에서 사용되며, NLB 전송 계층에서 처리량을 제공하며, GLB 글로벌로 여러 AWS 리전에 트래픽을 분산시키기 위한 서비스입니다. 선택은 특정 응용 프로그램 요구 사항 처리해야 하는 트래픽 종류에 따라 다를 있습니다.

 

반응형

1. VPC 생성

VPC > Your VPCs > Create VPC를 통해 VPC를 생성한다.

 

2. IPv4 CIDR은 보통 VPC는 /16 prefix, public subnet 같은 경우 /20, private subnet 같은 경우 /22 로 나뉘며 그 이유는 앞단인 public subnet 영역 에서 훨씬 많은 외부접근이 발생할 수 있기 때문에 auto scailing을 통해 ip대역을 원할히 할당하기 위해 prefix를 좀더 널럴하게 잡는다고 한다.

 

3. DR(Disaster Recovery) 를 위해 2AZ 안에 2 Tier의 Subnet 영역을 두고자 하며 각각의

네이밍은 {Service Name}-{Profile}-{AZ}-{public/private}-subnet(예, sample-develop-a-public-subnet)으로 짓는다.

 

4. VPC > Subnets > Create Subnet을 통해 Subnet 생성을 하며 필자는 2 tier 로 구성하기에

4개의 서브넷 영역을 생성했다.(2pub/2pri)

 

5. pub1, pub2 subnet 영역을 하나의 라우팅 테이블에 묶고 pri1, pri2 subnet 영역을 하나의 라우팅 테이블에 묶는다.

최초 VPC 생성시 Default Routing Table이 생성되고 이를 필자는 pub1, pub2 를 묶는데 썼으며 추가로 pri1, pri2 서브넷 영역을 묶기위해 Route Table을 별도로 생성하였다.

 

 

6. private subnet 과 public subnet에 각각 ec2 인스턴스를 셋팅한다. public subnet 영역에는 ec2 ami로 amzn-ami-vpc-nat-2018.03.0.20220705.1-x86_64-ebs(이미지 이걸로 안할시에 -> ec2 인스턴스를 nat용으로 사용못함) 를 사용하여 ec2 인스턴스를 nat용으로도 사용하고자 한다. private subnet 영역에는 ami로 amazon default image를 사용하여 t2 medium으로 올렸다.

 

7. bastion host란 private subnet에 올린 ec2에  접근 할 수 있는 방법이 오직 bastion host 로만 관리하는 것이며 이경우 보안과 통신 로그를 일괄적으로 관리할 수 있는 편리함이 보장된다. public subnet에 올린 ec2 인스턴스를 bastion으로 사용하기 위해 기존 private subnet을 묶은 {Service Name}-{Profile}-private-rt 에 Edit routes 로 모든 나가는 목적지를 아래와 같이 public 영역에 위치한 ec2 인스턴스의 아이디를 입력한다.

 

8. public subnet을 묶은 {Service Name}-{Profile}-public-rt 은 외부로 통신해야하기 때문에 Internet Gateway를 우선적으로 생성한다.

 

9. 생성한 Internet gateway를 앞서 생성한 {Service}-vpc에 Attach to VPC 메뉴를 통해 붙인다.(안붙이게 되면 routing table에서 이용할 수 없다)

 

10. 앞서 8번에서 언급한  {Service Name}-{Profile}-public-rt 에 앞서 만든 Internet gateway를 연결한다.

 

11. public 영역에 위치한 ec2 인스턴스와 private 영역에 위치한 ec2 인스턴스에 접근하기 위해선 각각의 Security Group의 Inbound rule 과 outbound rule 에 설정을 해야 하는데 우선 private 영역에 위치한 보안그룹의 inbound와 outbound의 설정 정보는 routing table에 등록되어있는 정보를 토대로 외부로 나아가기때문에 outbound를 모두 all로 표기했으며 inbound는 아래와 같이 ssh만 설정하였다.

 

12. public 영역에 위치한 ec2 인스턴스의 Security Group 은 아웃바운드는 모든 트래픽 허용으로 했으며 inbound 의 source 타겟을 Security Group 도 target으로 할 수 있어 private 영역에 위치한 ec2인스턴스의 security group을 소스로 설정했다. 아래는 그 설정 정보이다.

 

13. 또한 public subnet 영역에 위치한 ec2인스턴스를 nat 용도로 사용해야하기 때문에 원본/대상 확인 비활성화 작업을 해야하며 아래와 같이 진행하면 된다.

14. 정상적으로 nat용도로 활용되는지를 확인하려면 우선 가까운 영역부터 즉 private ec2 에서 public ec2 인스턴스로 핑을 날려보고 

아래와 같이 명령어로 정상적으로 작동 되는지 확인한다.

$ sudo yum update -y

 

* perm key의 권한은 600으로 안해줄시에 SSH 커넥션시에 에러가 발생한다.

 

15. 핑은 VPC 내의 Subnet을 묶는 Default Routing table을 통해 다른 서브넷에 있는 ec2 인스턴스끼리 서로 통신할 수 있지만 IGW를 통해 외부 연결을 하려면 반드시! private subnet을 묶은 routing table에 public subnet에 올린 ec2인스턴스를 등록을 꼭 해줘야한다.

 

https://dev.classmethod.jp/articles/access-private-subnet-ec2-via-ec2-bastion-host/

 

반응형

Marketplace 에서 해당 플러그인 설치 후

 

View -> Tool Windows -> Persistence 클릭

 

 

Persistence 탭이 활성화 됨을 알 수 있다.

반응형

표준 주제와 FIFO 주제가 있으며

표준 주제 같은 경우 매월 첫 1백만 개 Amazon SNS 요청은 무료이다.

 

 

표준 주제를 생성하여 아래와 같이 Amazon SNS 를 등록한다.

 

등록한 Amazon SNS내의 구독생성을 통해 SQS 를 생성한다. 

 

 

등록하는 화면은 아래와 같다

 

반응형

Sonarqube를 도입하시는 분들에게 이 글이 가이드가 되기를 바란다.

 

우선 intellij를 사용하는 개발자는 intellij에서 제공되는 툴인 Sonarlint + Sonarqube를 설정할 수도 있겠지만 

 

다른 페이지에서 언급한 docker-compose로 Sonarqube를 올리게 되면 로그인 페이지가 나오게 되며

 

 

초기 비밀번호는 admin/admin이다, 로그인을 하게 되면 projects 탭을 통해 들어간 페이지에서 Create Project 버튼을 통해

 

검사하고 싶은 패키지의 값을 입력하면 된다. 필자는 Manually를 클릭했다.

 

다음은 Project 생성에 관련된 부분인데 검사하고싶은 패키지의 이름을 적으면 된다

 

이렇게 Set Up을 통해 넘어가게 되면 어떻게 분석해야 될지에 대한 선택 부분이 나오며 젠킨스의 파이프라인을 통해 소나큐브를 통한 분석을 할지 또는 깃헙액션을 통해서일지 등등 다양한 설정을 할 수 있으며 필자는 아래 위치한 Locally를 설정해 보고자 한다. 

 

다음은 토큰 발급과정과 Gradle 명령어를 통해 Sonarqube를 실행하는 부분에 대해 다뤄진다.

 

 

위에 sonarqube의 버전이 3.5.x 로 되어있으나 필자가 생성한 project의 gradle버전이 8.2 여서 호환성 문제가 발생하였고 해당이슈는 링크를 달아뒀다. 때문에 plugin의 버전을 변경하였으며 다음은 build.gradle의 설정 부분인데 다음과 같이 필자는 설정하였다.

 

plugins {
    ,,,
    id 'org.sonarqube' version "4.0.0.2929"
    ,,,
}

,,,

dependencies {
    ,,,
    // https://mvnrepository.com/artifact/org.codehaus.sonar/sonar-plugin-api
    compileOnly group: 'org.codehaus.sonar', name: 'sonar-plugin-api', version: '5.1'
}

,,,

sonar {
    properties {
        property 'sonar.host.url', [소나큐브가 올라간 서버 IP:Port]
        property 'sonar.login', [발급한 token값]
        property 'sonar.language', 'java'
        property 'sonar.projectVersion', '1.1.0-SNAPSHOT'
        property 'sonar.sourceEncoding', 'UTF-8'
        property 'sonar.coverage.jacoco.xmlReportPaths', '${buildDir}/reports/jacoco/test/jacocoTestReport.xml'
        property 'sonar.exclusions', '**/test/**, **/Q*.java, **/*Doc*.java, **/resources/**'
        property "sonar.projectKey", [발급한 ProjectKey 지금같은경우 sample]
        property "sonar.sources", "src/main"
        property "sonar.tests", "src/test"
    }
}

 

이 글이 소나큐브를 이용하는 분들에게 도움이 되길 바란다.

반응형

+ Recent posts