이번 포스트에서는 RDS로 생성한 PostgreSQL 데이터베이스를 개발 중이던 SpringBoot 프로젝트와 연동해 보도록 하자 1. Gradle 의존성 추가하기 1-1. 의존성 추가하기 SpringBoot 프로젝트에서 postgreSQL을 사용하기 위해 Gradle에 의존성을 추가한다. // postgreSQL runtimeOnly 'org.postgresql:postgresql' 1-2. 주의사항 Gradle 의존성을 추가했다면 꼭 프로젝트에서 Gradle을 reload 해줘야 한다. 좌측의 코끼리를 누르거나 우측의 Gradle 버튼을 클릭해서 새로고침을 해주도록 하자 그래야 의존성을 다운로드해서 추가한다. 좌측의 dependency 폴더 하단에 아래와 같이 추가가 되었다면 잘 다운받은 것이다. 2..

자바의 "추상화"의 개념을 알아보고 스프링을 이것을 어떻게 사용하는지 알아보자 📌 서론 항상 추상화를 사용하고 있지만 누군가 "그래서 대체 추상화가 뭔데?"라고 물어볼때마다 바로바로 떠오르지 않았고 많은 고민을 해야했다. 이런 점에서 알지도 못하면서 사용하고 있다는 점에 답답함이 느껴져서 정리를 시작했다. 1. 추상화(Abstraction)의 기본 개념 추상화란? 추상화는 복잡한 시스템을 단순화하는 프로그래밍 기술이다. 이는 개발자가 복잡한 내부 작업을 몰라도 기능을 사용할 수 있게 해준다. 왜 필요한가? 복잡한 시스템을 이해하고 사용하기 위해서는 많은 시간과 노력이 필요하다. 추상화를 통해 이러한 복잡성을 줄이고, 빠르게 그리고 안전하게 시스템을 사용할 수 있다. 실생활 예시 예를 들어, 자동차를 운전..

요즘 실전 인프라 구축을 해보면서 기초지식이 많이 부족하다는 것을 느껴 YouTube에 AWS 관련 세미나를 검색해서 보던 중 내용이 너무 좋아서 기초를 다지기에 완벽하다고 느껴져서 감상하며 봤던 내용들을 기록으로 남긴다. 모든 정보와 이미지와 자료는 아래의 AWS 공식 세미나에서 캡처하거나 가지고 왔다. 문종민 솔루션즈 아키텍트께서 만들어 주신 PPT의 내용을 보며 캡처를 해서 설명을 이어가도록 한다. (따로 허가받지는 않아서 혹시 PPT 이미지 사용이 문제가 된다면 바로 비공개로 전환하도록 하겠습니다.) https://www.youtube.com/watch?v=1zzBgCRDqeo 1. AWS의 가용영역 가용 영역이란 하나 또는 복수개의 데이터 센터(datacenter)로 구성되어진 완전히 독립적인 ..

ALB의 포트설정 이슈 해결 : 동적 vs 명시적의 차이점 기존의 ECS 서비스에서는 호스트 포트를 0(동적 포트 할당을 위함)으로 설정하고 컨테이너 포트는 8081로 연결시키는 "태스크 정의"를 만들고 ALB를 적용시켰다. 이렇게 적용시켰을때 퍼블릭 IPv4주소(DNS)로 웹 url로 접근했을 때는 접속이 불가능했다. 그런데 새롭게 태스크 정의를 만들었는데 이때는 호스트의 포트를 0이 아닌 8081로 정해(동적 포트매핑)서 만들었더니 웹 url에 퍼블릭 IPv4 DNS주소로 접속이 가능했다. 이에 이것들이 대체 무슨 차이가 있어서 이런 결과가 발생한 것인지 것인지 궁금해서 알아봤다. 1. 차이점 파악하기 1-1. 기존 ECS 태스크 정의 "컨테이너 포트 매핑" 확인 기존의 정의에서는 호스트 포트를 0으..

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..