📝 서론 최근 사내 인프라를 분석하던 중, 모든 서비스들이 가상 사설 네트워크인 VPC를 기반으로 분리되어 관리하고 있는 것을 알게되었다. 일반적으로 VPC는 사설 네트워크 인프라로, Public IP를 통하지 않으면 외부 AWS 리소스를 접근할 수 없는 것으로 알고 있는데, 일부 AWS 리소스가 다른 VPC의 AWS 리소스를 Private IP를 통해 사용하고 있는 것으로 확인하였다. 어떤 이유로 이런 동작이 가능한 것인지 조사해보니, VPC Peering 을 통해 다른 VPC에 속한 리소스들과 마치 동일한 VPC 내부에 있는 것처럼 통신이 가능하다는 것을 알게 되었다. 이번 글에서는 VPC Peering을 사용하기 위한 가장 기초적인 토대가 되는 VPC에 대해 살펴보고, Terraform을 이용하여 ..
서론 올해 8월, 글또 8기의 마지막 글을 작성한 이후, 9기를 시작하기 전까지 단 하나의 글도 작성하지 않았다. 8기를 시작했을 때의 목표는 꾸준한 글쓰기였지만, 마지막 글을 작성한 이후로 아무것도 작성하지 않음으로써, 그 목표를 성실하게 이루지 못했다는 사실을 깨닫게 되었다. 8기를 마무리하고, Node.js 강의 자료를 작성하거나 강의도 촬영하는 등 많은 시간을 할애하는 작업들이 있었다 보니 그동안 글쓰기를 멀리하고 있던 것 같다. 하지만, 이러한 일정 속에서도 과연 “정말로 글을 작성할 여유 시간이 없었을까?” 라는 질문을 자신에게 던져보게 되었지만, 그렇지 못했다는것을 바로 깨닫게 되었다. 이러한 고민 끝에, 다시금 글쓰기 습관을 형성하기 위해 글또 9기를 지원하게 되었고, 5개월이라는 길지만 ..
서론Nest.js를 이용하여 여러 프로젝트를 진행하였다. 매 프로젝트마다 TypeORM, Mongoose 등 다양한 ORM을 이용하여 프로젝트를 진행하였는데, 여러 Nest.js 프로젝트들을 살펴보던 중 Prisma를 도입한 프로젝트가 상당히 많은 것을 확인하게 되었고, 도대체 어떤 장점이 있길래 기존 ORM을 대체하여 Prisma를 도입하였는지 궁금하게 되었다. 그래서, Prisma는 다른 ORM과 어떤 장단점이 존재하는지 확인해보고, 학습하게된 내용을 하나씩 정리하는 것을 목표로 글을 작성해보고자 한다.ORM(Object Relational Mapping)ORM(Object Relational Mapping)은 이름 그대로 객체(Object)와 관계형 데이터베이스(RDB, Relation Databa..
서론 이전 게시글에서는 도메인 주도 개발 (DDD)을 위해 Event Storming을 진행하였다. 그러나, 도출된 이벤트를 바탕으로 코드를 구현하는 과정을 처음 겪으면서 도메인 주도 개발을 진행하다보니 많은 시간을 소모하게 되었다. 레이어드 아키텍처를 이용하여 프로젝트를 진행하였지만, 외부 의존성을 어떻게 관리할 것인지, 유연한 설계를 위해 어떻게 코드를 구성하는 것이 가장 효과적인지에 대한 고민은 계속하게 되었다. 그리고, 현재 상황에서 가장 큰 고민은 모든 비즈니스 로직이 Service 계층에 존재하고, 다양한 유틸 라이브러리에 대한 의존성이 모든 계층을 통틀어서 더욱 커지게 되는 것이었다. 이러한 문제를 해결하기 위해 다양한 아키텍처 패턴을 고려하고 있었는데, 그중에서 Clean Architect..
서론 최근 다양한 소프트웨어 개발 방법론에 대해서 탐구하고 있었다. 테스트 주도 개발(TDD, Test-Driven Development), 행동 주도 개발(BDD, Behavior-Driven Development)등의 개발 방법론을 살펴보던 중, 도메인 주도 설계(DDD, Domain-Driven Design)에 대한 내용을 찾아 보게되었는데, 소프트웨어의 복잡성을 줄이고, 비즈니스 로직의 이해를 향상시킬 수 있다는 것으로 알게 되었다. 소프트웨어의 복잡성을 어떤 방법으로 줄일 수 있는지에 대해 많은 관심이 있었는데, 다른 개발 방법론 보다 도메인 주도 설계에 대해 필요성을 더욱 느끼게 되어 가장 우선적으로 찾아보기 시작했다. 이번에는 그 도메인 주도 설계에 대해 찾아본 내용을 간략하게 정리하여, ..
서론 Terraform을 사용하면서 CLI를 잘못 사용하여 .tfstate파일에 배포된 정보가 반영되지 않거나, AWS Management Console에서 생성한 리소스를 놓치고 배포하게 될 상황을 겪었을 것이다. 그럴때마다 마주하는 ‘already exist …’ 에러를 AWS Management Console에서 수동으로 삭제하는 것 대신, Terraform CLI를 이용해 이미 존재하는 AWS 리소스를 Terraform 파일에 정의된 속성에 맞게 수정하는 작업을 진행할 예정이다. 위와 같은 에러는 AWS 리소스가 계정 내에서 고유한 이름으로 존재하는 서비스에서 발생하는데, 주로 ECR 저장소, S3 버킷과 같은 서비스에서 많이 볼 수 있다. 그렇다면, 어떻게 작업해야 이런 문제 상황을 해결할 수 ..
서론해당하는 프로젝트를 시작하기에 앞서 이전까지는 웹 소켓을 이용해 채팅 기능, 사용자 위치 갱신 기능 등 다양한 기능을 구현하였다. 그러나, 새로운 프로젝트를 진행하던 중 웹 소켓 하나의 기능을 위해 별도의 EC2 또는 ECS 인스턴스를 실행할 경우 비용이 증가할 것으로 판단하였다. 이에 따라, 웹 소켓 기능만 서버리스로 구현한다면 트래픽이 발생하는 경우에만 비용이 발생하므로, 효율적인 비용 관리가 가능할 것이라고 생각하였다. 따라서, 웹 소켓을 어떻게 서버리스로 구현할 수 있는지에 대해 탐구하게 되었다.WebSocket웹 소켓은 MDN 페이지에 설명된 것처럼, 지속적으로 클라이언트와 서버간의 통신을 가능하게 하는 프로토콜이다.클라이언트가 서버에 연결하면, 해당 연결은 유지되며 서버는 원하는 때에 클라..
서론2021년 하반기부터 2023년 2월까지 진행한 1일 1커밋을 벗어난 이야기이다. 1일 1커밋을 진행하면서 어떤 것을 경험하였고, 어떤 성장을 하였는지 그리고 어째서 1일 1커밋에서 벗어났는지에 대해 이야기하고자한다. 1일 1커밋을 시작한 이유와 과정Back-end 개발을 시작하고 개인 공부를 하던 중, “공부를 하는 습관을 가져야겠다”라는 막연한 생각을 한 적이 있었다. 그당시 많은 블로그에서 1일 1커밋을 지속하면서 많은 개발 지식을 습득하고, 꾸준하게 성장할 수 있는 습관을 가지게 되었다는것을 보게되었다. 그런 게시글을 보며 1일 1 커밋을 도입하게 된다면 나의 부족한 부분을 채우며 좋은 경험을 가져갈 수 있을것이라 생각하였고, 그렇게 1일 1커밋을 시작하게 되었다. 1일 1커밋을 겪으며우선 1..
이전 작성한 게시글에서는 Serverless Framework의 배포 과정 중 발생한 오류 상황과 그 해결 방법에 대해 작성한적이 있었다. 간단히 요약하자면, Serverless Framework의 배포 과정이 강제로 종료되면 AWS CloudFormation의 Stack이 비정상적으로 생성될 수 있고, 이 상태에서 다시 배포를 시도하면 “Stack … does not exist” 오류 메시지가 발생하게 된다. 이전 글을 작성한 후 겪었던 오류 상황과 해결 방법, 그리고 동일한 문제가 발생하지 않도록 수정하는 방법을 정리하여 Serverless Github Issue에 제출하였는데, Repo 관리자와 수정 방안에 대해 의견을 나눈 뒤, Pull Request에 대한 요구를 받게 되었다. 그렇게 오픈 소스..
Serverless Framework를 이용한 작업을 진행하던 중, 갑작스럽게 배포가 진행되지 않는 상황이 발생하였다. 특이하게도 Nest.js 프로젝트의 코드 작업을 하지않고, Serverless의 설정값을 변경하던 중 발생하게 된 상황이라 더욱 이상하게 느껴졌다. 어떤 이유로 이런 에러가 발생하였는지 확인해보고, 어떤 해결 방안이 존재하는지 파헤쳐보도록 하겠다. 문제 상황 Nest.js 프로젝트의 코드 작업을 마무리하고, serverless.yml 파일에 정의된 속성값들을 수정하여 Lambda의 경량화를 진행하고 있던 와중 Service를 AWS Lambda에 배포하려 할 때, Stack prac-websocket-dev failed to deploy 라는 에러가 발생하였다. 상세한 에러 메시지를 확..
