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

저번 포스트에서는 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..

이번에는 PRE_BUILD 단계에서 발생한 빌드오류를 해결해 보자 1. 빌드 오류 파악하기 1-1. 오류 파악 열심히 S3 관련 문제를 해결했더니 이번에는 아래와 같은 PRE_BUILD 단계에서 에러가 발생했다. COMMAND_EXECUTION_ERROR: Error while executing command: aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin {ecr 리포지토리 주소}. Reason: exit status 1 1-2. 빌드 로그 분석하기 조금 더 정확히 보기위해 빌드 로그를 확인했다. 아무래도 이번에는 IAM 권한관련 에러인것 같다. (ECR 권한에러) [Cont..

이번에는 2편에 이어서 Step4 배포 스테이지와 Step5 검토를 작성한다. 1. Step4: 배포 스테이지 추가 1-1. 배포 스테이지 추가 Step3에서 다음을 누른다면 아래와 같은 배포 스테이지 추가 화면으로 이동된다. 1-2. 배포 공급자 선택 배포 공급자 하단의 박스를 눌러서 Amazon ECS를 선택해 준다. 1-3. 배포 스테이지 추가하기 이전에 만든 ECS 클러스터를 선택하고 서비스도 선택한다. 여기서 중요한게 이미지 정의 파일인데 이것때문에 배포시 오류가 발생했다. (배포단계를 설명할 때 오류 해결사항을 적도록 하겠다.) 2. 검토 2-1. 검토하기 이 단계에서는 지금까지 작성한 내용들을 하나하나 검토한다. 4단계까지 전부 확인했을때 문제가 없다면 하단의 "파이프라인 생성" 버튼을 누른..

M1에서는 ECR에 AWS의 푸시명령어를 입력하면 오류가 발생한다. 이 글을 작성하게 된 이유는 Local환경에서 이미지를 빌드해서 ECR로 넣은 다음 ECS에서 배포를 했는데 계속해서 오류가 발생했다. 이에 해결방법을 찾은 것을 기록한다. 제목에 대해 바로 확인하고 싶은 분들은 목차 1은 건너뛰면 된다. 1. 이미지 배포 오류 발생 1-1. AWS에서 ECS에 서비스 생성을 완료해서 배포를 했다. 1-2. ECS로 배포하던 도중 계속해서 배포가 실패했다. 2. AWS CloudWatch에서 에러로그 확인 2-1. 계속 배포도중 발생하는 오류가 뭔지 확인하기 위해 CloudWatch로 이동했다. 2-2. 오류로그 확인 아래와 같은 오류였다. exec /usr/bin/java: exec format err..

이번 포스트에서는 ECS 클러스터, ECS 서비스, ECS 태스크 정의를 생성하고 사용해 보자 ECS 클러스터에 대해서 설명하자면 ECS클러스터는 그 자체로는 아무런 역할을 하지 못한다. 클러스터 내부에 EC2가 생성되어야 비로소 클러스터의 역할을 하게 되는 것이다. 이를 위해 ECS클러스터 생성을 할때는 EC2생성을 동시에 설정하게 된다. 그리고 ECS 클러스터 내부에는 ECS서비스 생성해서 기동시켜줘야하는데 이 서비스는 ECS 태스크를 관리해주는 서비스다. 즉, 세팅 순서는 ECS 클러스터 -> 태스크 정의 -> 서비스 생성이다. 1. ECS 클러스터 생성하기 1-1. 클러스터 생성 ECS 메뉴 우측의 "클러스터 생성" 버튼을 클릭한다. 1-2. 클러스터 구성 작성 여기서는 클러스터 이름과 기본 네임..