개요 최근 EKS로 인프라를 마이그레이션하면서, 수많은 챌린지를 진행하고 있습니다. 초기에는 EKS 구축에만 많은 리소스를 사용하고 있었지만, 현재는 어느정도 쿠버네티스가 익숙해졌고 EKS를 이용하여 다수의 어플리케이션이 배포된 상태입니다. 이렇게 EKS를 이용해 여러 서비스들이 배포된 상황이긴 하지만, 매번 설계한 아키텍처에서 마음에 들지 않는 부분이나 개선되었으면 좋을 부분들이 점점 눈에 띄고 있는 상태입니다. 이번 게시글에서는 사용에 직접적인 문제는 없지만, 개선되어야할 부분 중 하나인 Niginx Ingress Controller의 단일 장애점(SPOF, Single Point Of Failure)에 대한 개선기를 작성해보고자 합니다. 먼저 알아보기 1️⃣ Ingress 인그레스(Ingress)는..
개요 일반적인 스타트업은 성공 가능성을 빠르게 검증하는 것을 최우선으로 삼곤 한다. 이 과정에서 보안적인 측면은 종종 후순위로 밀리는데, 이는 나중에 큰 문제를 초래하게 될 수 있다. 만약, 서비스 중인 비즈니스에서 Access Key가 노출되어 중요한 데이터가 외부에 공개되거나, 사용자 정보가 탈취당하는 상황이 발생한다면 어떻게 해야할까? 단순히 AWS 고객센터에 메일을 전달하고 답변을 기다리는 것만으로는 충분하지 않을 것이다. 이러한 긴급한 상황에서는 명확한 대응 정책이 필요하게 된다. 이런 문제를 예방하고 효과적으로 관리하기 위해서는 ISMS와 같은 인증을 통한 체계적인 정보보호 관리가 필요하게 된다. 이번 게시글에서는 정보보호 관리 체계인 ISMS에 대한 기본 개념과 클라우드 인프라 관점에서 필요..
개요 Terraform과 같은 Infrastructure as Code(IaC) 도구를 사용한다면, 대규모 인프라를 효츌적으로 관리할 수 있다. 그러나, 단일 Terraform 프로젝트로 대규모 인프라를 관리하게 된다면, 많은 리소스들이 하나의 코드 베이스에 포함되어 관리가 복잡해질 수 있다. 이로 인해 코드의 가독성이 떨어지고, 유지보수가 어려워질 뿐만 아니라 재사용성 또한 감소하게 된다. Terraform Module을 사용하게 된다면 이러한 문제를 해결할 수 있게 된다. 이번 게시글에서는 모듈이란 무엇인지, 어떻게 Terraform Module을 사용할 수 있는지에 대해 알아보도록하자. Terraform Module Terraform Module은 코드 베이스를 논리적으로 분리하여 각각의 인프라 리..
개요 일반적으로, 우리는 AWS와 같은 클라우드 서비스 제공업체의 콘솔을 통해 인프라 리소스를 관리하고 있을 것이다. 소규모 프로젝트나 모놀리식의 간단한 프로젝트를 구성하였을 때에는 이런 접근 방식은 문제가 되지 않을것이다. 그러나 프로젝트 규모가 확장되어 수많은 부하 분산 시스템을 구성하거나, 접근 가능한 사용자를 관리하기 위한 여러 Rule을 정의하거나, 멀티 컨테이너 환경을 구성하기 시작하는 등 복잡한 요구사항이 지속적으로 발생할 때, AWS 콘솔을 이용하여 인프라를 관리하는 것은 많은 시간이 소모될 것이고, 자신이 어떤 설계를 하였는지 잘 기억나지 않을 것이다. 더욱이, 운영 환경과 개발 환경을 별도로 구성하게 된다면, 동일한 행위를 반복하게 될 것이고, 또 다른 스테이지 구현이 필요하게 된다면,..
서론 최근, AWS에서 운영되고 있는 EC2 인스턴스 기반의 서비스를 Kubernetes 기반의 AWS EKS로 마이그레이션하는 작업을 진행하고 있다. 기존 방식에서는 수동으로 EC2 인스턴스를 관리하면서 발생하는 복잡성과, 세부적인 AutoScaling 설정의 어려움이 많은 리소스를 소모하고 있었으며, 특히 지속적인 통합 및 배포(CI/CD)에 대한 부분이 많이 미흡하였다. 이러한 과정에서 멀티 컨테이너 환경에서 지속적인 통합 및 배포(CI/CD)를 어떻게 효율적으로 구성할 수 있는지에 대한 고민을 진행하게 되었다. 이전까지는 AWS ECS와 CodePipeline을 중심으로 한 CI/CD를 구성하였지만, Kubernetes 환경에서는 Argo CD라는 도구를 이용하여 지속적인 배포(CD) 과정을 관리..
📝 서론 최근 사내 인프라를 분석하던 중, 모든 서비스들이 가상 사설 네트워크인 VPC를 기반으로 분리되어 관리하고 있는 것을 알게되었다. 일반적으로 VPC는 사설 네트워크 인프라로, Public IP를 통하지 않으면 외부 AWS 리소스를 접근할 수 없는 것으로 알고 있는데, 일부 AWS 리소스가 다른 VPC의 AWS 리소스를 Private IP를 통해 사용하고 있는 것으로 확인하였다. 어떤 이유로 이런 동작이 가능한 것인지 조사해보니, VPC Peering 을 통해 다른 VPC에 속한 리소스들과 마치 동일한 VPC 내부에 있는 것처럼 통신이 가능하다는 것을 알게 되었다. 이번 글에서는 VPC Peering을 사용하기 위한 가장 기초적인 토대가 되는 VPC에 대해 살펴보고, Terraform을 이용하여 ..
서론 Terraform을 사용하면서 CLI를 잘못 사용하여 .tfstate파일에 배포된 정보가 반영되지 않거나, AWS Management Console에서 생성한 리소스를 놓치고 배포하게 될 상황을 겪었을 것이다. 그럴때마다 마주하는 ‘already exist …’ 에러를 AWS Management Console에서 수동으로 삭제하는 것 대신, Terraform CLI를 이용해 이미 존재하는 AWS 리소스를 Terraform 파일에 정의된 속성에 맞게 수정하는 작업을 진행할 예정이다. 위와 같은 에러는 AWS 리소스가 계정 내에서 고유한 이름으로 존재하는 서비스에서 발생하는데, 주로 ECR 저장소, S3 버킷과 같은 서비스에서 많이 볼 수 있다. 그렇다면, 어떻게 작업해야 이런 문제 상황을 해결할 수 ..
이전 작성한 게시글에서는 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 라는 에러가 발생하였다. 상세한 에러 메시지를 확..
