MSA에서 Zipkin을 사용하여 분산추적 로깅을 구현해 보자 이벤트를 사용해서 데이터베이스의 정합성 보장 문제는 해결했지만 아직 이 과정들을 전부 로그를 통해서 추적하는 것은 적용시키지 못했다. 로그가 정말 중요한 만큼 zipkin을 사용하여 제대로 로그를 추적해 보도록 하자. 이번 포스트에서는 ZIpkin을 활용하여 MSA 환경에서 분산 로그 추적을 구현하는 과정을 단계별로 설명한다. 1. ECR 리포지토리 생성하기 ECR(Elastic Container Registry)은 AWS에서 제공하는 Docker 컨테이너 이미지를 저장하기 위한 서비스다. 여기서는 Zipkin 이미지를 위한 저장소를 만드는 방법을 설명한다. 1-1. Zipkin 이미지를 저장할 AWS ECR 생성 zipkin 용 reposi..

이번에는 ECS의 배포 오류(환경 변수 주입 오류)를 해결하는 과정을 설명한다. 이전에는 url, username, password라는 환경변수를 Secrets Manager에서 읽어오지 못하는 문제가 발생했었는데 이번에는 특정 키를 직접 찾아서 참조하는 방식에 대해서 알아본 후에 적용해서 오류를 해결했다. 1. Secrets Manager의 secret에서 특정 키만 참조하는 방식 설명 1-1. secret의 키 참조방식 조금 조사를 해본 결과 Secrets Manager에 만든 보안 암호(secret)의 특정 키를 참조하는 방법은 다음과 같다. ARN 뒤에 콜론(:)을 추가하고 키 이름을 명시해야 한다. 이후 맨 뒤에::을 붙여준다. 예시: arn:aws:secretsmanager:region:acc..

지난번에는 ECS의 태스크 정의를 생성했다. 이번에는 이 태스크를 사용해서 ECS의 서비스를 만들어 보도록 하자 태스크의 컨테이너에는 내가 주입해 준 환경변수가 들어갈 테니 springboot는 이 내용을 db연결할 때 잘 가져다 사용할 것이다. 1. ECS 클러스터 업데이트하기 1-1. ECS 클러스터 업데이트 이제 방금 생성한 태스크 정의를 적용시켜 보도록 하자 ECS 클러스터로 들어온 다음 우측의 "서비스 업데이트"를 클릭한다. 1-2. 패밀리(태스크 정의) 변경하기 아래와 같이 "패밀리" 구성을 클릭해서 이전 포스트에서 만든 "태스크 정의"를 선택해 준다. 맨 하단으로 가서 "업데이트" 버튼을 클릭한다. 2. SpringBoot에서 application.yaml 설정하고 ECS 배포하기 2-1. ..

저번 포스트에서는 AWS의 Secret을 만들었으니 이번에는 이것을 ECS에 연결해 보도록 하는 작업을 진행할 텐데 IAM정책부터 ECS의 태스크 정의까지 해보도록 한다. 1. IAM 역할 설정하기 먼저, ECS 태스크가 Secrets Manager에 접근할 수 있도록 ecsTaskExecutionRole IAM 역할에 권한을 부여해야 한다. 이 역할은 ECS 태스크가 다른 AWS 서비스와 상호 작용할 때 필요한 권한을 제공하는 역할이다. 1-1. IAM 콘솔 접속 AWS 관리 콘솔에 로그인한 후, IAM 서비스 페이지로 이동한다. 1-2. 역할 선택 대시보드 페이지 좌측의 메뉴에서 '역할' 섹션을 클릭해서 들어간다. 아래와 같은 페이지가 나올 텐데 여기서 ecsTaskExecutionRole을 검색한다..

ALB를 적용시킨 ECS의 동작원리 이전 포스트에서 배포를 완료하고 실행했는데 ALB의 DNS주소 뒤에 8081포트를 입력하고 접속하니 접속이 불가능했는데 아무런 포트를 입력하지 않고 접속하니 잘 동작했다. 이에 ALB(Application Load Balancer)를 적용시킨 ECS(Elastic Container Service)의 동작원리를 알아보고 이 포스트를 작성한다. 1. ALB 리스너 포트 설정 ALB의 리스너 포트를 80으로 설정하면, ALB는 클라이언트로부터 80 포트에서 들어오는 요청을 수신한다. 클라이언트는 이 경우 ALB의 DNS 주소만 입력하여 접속할 수 있다 (예: http://ALB-DNS-Address/). 아래와 같이 80 포트를 ALB의 리스너 포트로 설정한 상황이다. 2...

저번 포스트에서는 Deploy단계에서 S3에서 이미지를 불러와서 오류가 발생했던 부분을 수정했었다. 이번에는 그 다음에 새롭게 발생한 ECS 실행 오류를 해결한다. 1. 배포오류 (Memory 부족 문제) 1-1. 오류 파악 저번 포스트에 이어서 빌드를 진행했더니 아래와 같이 배포단계에서 무한로딩이 발생했다. 계속 진행중이 떠서 답답해서 ECS 클러스터에 들어가서 확인해 봤다. 아래와 같이 배포에서 실패한 작업이3번이었다. 1-2. 이벤트 메시지 확인 이벤트의 메시지를 확인해봤더니 다음과 같았다. "Amazon ECS가 recipia-member-service 서비스의 요구 사항을 충족하는 컨테이너 인스턴스를 찾지 못했음을 나타낸다." 특히, 가장 근접한 매치인 컨테이너 인스턴스 15ce592c56944..

열심히 빌드오류를 수정해서 고쳤다. 근데 근데!! 이번에는 Deploy 배포단계에서 오류가 생겼다 당장 해결해보도록 하자 1. 배포 오류 파악하기 1-1 .오류 파악 아래와 같이 Deploy에서 빨갛게 실패라고 나왔다... 1-2. 아래의 오류가 발생했다. Unable to access the artifact with Amazon S3 object key 'recipia-member-git-n/BuildArtif/IejGhqN' located in the Amazon S3 artifact bucket 'codepipeline-ap-northeast-2-555139989952'. The artifact object key is not found. 1-3. 오류 해석 이 오류는 AWS CodePipeline..

저번 포스트에서는 PRE_BUILD단계의 오류를 해결했다. 이번 포스트에서는 그 다음 BUILD 단계에서 발생한 오류를 해결해 보자 1. BUILD단계의 오류 파악하기 1-1. 오류 파악 PRE_BUILD오류를 해결했더니 이번에는 BUILD 에서 오류가 발생했다. 오류 로그를 바로 확인했다. 1-2. 오류 로그 확인 #5 [2/2] ADD build/libs/member-0.0.1-SNAPSHOT.jar member-api.jar #5 ERROR: failed to calculate checksum of ref moby::z5ufilzi940gpc8hp3lj0ypj8: failed to walk /var/lib/docker/tmp/buildkit-mount237631583/build/libs: lstat..