오늘도 한 뼘 더

# 배경 EBS 볼륨은 할당된 용량 크기에 따라 비용이 정책 되기 때문에 과도하게 볼륨의 크기가 크다면 축소하는 것이 좋다.다만, AWS에서 볼륨의 크기를 확장하는 것은 비교적 간단하나 축소하는 작업은 꽤 복잡하기에 스토리지 용량을 작게 잡고 늘려나가는 것이 바람직하다. 이미 늘어난 스토리지를 일단 축소해야 하기에 해당 작업을 진행하였다. # 필요한 리소스 - 볼륨이 큰 기존의 인스턴스 (old)- 볼륨을 축소한 새로운 인스턴스 (new)- 복구 및 마운트를 위한 임시 인스턴스 (temp) # 볼륨 축소하여 기존 인스턴스에서 사용하기 [ 사전 작업 ]- 작업 전 기존 인스턴스에 대한 AMI를 생성하여 EBS를 복구할 수 있도록 한다.- 데이터 이관의 확인을 위한 테스트 데이터 생성 1. old..

# 배경  이전까지 AWS Lambda 함수에 작성된 코드는 개발자가 AWS Lambda 콘솔에서 직접 작성하였다.직접 Console 창을 이용하다 보니 코드가 제대로 관리되지 않는 문제가 있었다. 작성된 코드를 GitLab에서 관리하기로 하고 Lambda 함수의 코드를 다운받아 GitLab에 업로드하는 스크립트를 작성하였다.그러나 AWS Lambda의 경우 한 번 작성해 높은 코드를 변경하는 일 잦지 않아 스크립트를 언제 돌려야하는지 고민을 하던 차에 AWS CloudTrail에서 발생된 이벤트를 확인할 수 있음을 인지하고 CloudTrail과 EventBridge를 통해서 람다 함수 코드가 업데이트 될때 Jenkins에서 해당 스크립트를 돌릴 수 있도록 설정하기로 하였다.   # CloudTrail에..

# 배경  사용 중인 서버에서 도커 이미지를 빌드하면서 디스크 공간이 계속 증가하는 일이 발생하고 이로 인해 제대로 동작이 되지 않는 문제가 발생하였다. 미리 해당 서버에 대한 디스크 알림을 받고 사전에 디스크 여유 공간을 확보하면 해당 문제를 해결할 수 있다고 판단했다.그러나 CloudWatch에서는 기본적으로 현재 디스크에 대한 값을 조회하는 기능을 제공하지 않아서 CloudWatch Agent를 이용한다.   # CloudWatch Agent 설치  AWS에서 제공하는 파일을 다운로드하여서 사용하였다. (yum을 사용하여서는 도저히 설치가 되지 않아서 사용하지 못했는데 방법을 찾아봐야겠다.)$ wget https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu..

# 배경 현재 회사에서 사용하고 있는 Lambda 함수의 런타임은 node.js 14.X와 16.X인데 두 버전 모두 지원에 대한 종료가 되어 18.X로 버전을 업데이트하라는 이메일을 받았다. # 함수 업데이트 하기 ## 함수 런타임 변경 AWS Lambda > 함수 > 코드 탭 밑에 런타임 설정 편집 > 런타임 변경 >> 업데이트 진행 완료로 뜬다. ## 계층 생성 현재 회사에서 함수에 node axios를 계층으로 사용하고 있는데 이전에 사용하던 계층으로도 작동은 되었지만 버전을 같게 하면 좀 더 안정적일 것으로 생각하여 18.X 버전의 node.js 에서 axios를 설치하여 올리기로 하였다 밑의 단계는 linux 환경에서 진행하였다. 1. node js 설치하기 $ sudo apt update &..

# 배경 사용하고 있는 DB에서 문제가 생기거나 업데이트로 인해 연결이 끊겼을 때 바로 복구될 수 있도록 DB를 이중화하는 작업을 진행하고자 한다. AWS RDS를 DB서버로 사용하고 있는데 RDS에 Multi AZ를 사용하여 이중화가 가능하다고 한다. # Multi AZ의 역할 사용하고 있는 기본(primary) 인스턴스에 문제가 생기거나 재부팅을 할 때 다른 가용영역에 DB 인스턴스를 복제해 두고 그 인스턴스가 기본으로 바뀌도록 설정하는 것이다. 참고 https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/Concepts.MultiAZSingleStandby.html 다중 AZ DB 인스턴스 배포 - Amazon Relational Database..

# 배경 모든 환경에서 Dockerfile을 사용하여 코드를 배포하기 위해서 Elastic Beanstalk(이하 EB)에 Dockerfile을 사용하여 Docker Application으로 올려보기로 하였다. # Docker Application 환경 구성 Elastic Beanstalk의 구성은 이전에 진행한 방법과 다를 것이 없었다. Application을 생성할 때 플랫폼을 Docker로 선택해야 한다는 것 외에는 다 같은 방식으로 진행하였다. 2021.11.11 - [DevOps & Infra/AWS] - [AWS] ElasticBeanstalk 생성하기 [AWS] ElasticBeanstalk 생성하기 AWS ElasticBeanstalk 이란? https://docs.aws.amazon.co..

# 배경 S3에 보관 중인 데이터 중에 이전 버전이 필요 없는 것들이 있다. 만들어진 날짜 순으로 정렬해서 정리를 하려고 했는데 객체의 수가 999개를 초과하니 정렬이 불가능하다. S3에 수명 주기라는 것이 있어 이 규칙을 생성해서 정리할 수 있다고 한다. # 수명주기 규칙 생성하기 버킷 > 관리 > 수명 주기 규칙 생성 접두사 폴더나 파일명에 규칙이 있는 경우 작성해 주면 해당 폴더 및 파일에만 적용이 된다. 수명 주기 규칙 작업 현재 있는 객체들을 버전 만료로 변경하고 만료 처리된 객체들을 삭제하는 방법으로 진행하였다. 객체 생성 후 경과 일수 만들어진 지 90일이 지난 객체의 경우 버전을 만료 처리 객체의 이전 버전 영구 삭제 객체가 최신이 아닌 상태로 전환된 후 경과 일수 - 만료 상태로 변경되고..

# EC2 중지하기 aws ec2 stop-instances --instance-ids [instance ID] 인스턴스를 시작하거나 인스턴스 설정을 변경하기 위해서는 인스턴스가 완전히 중지되어야 한다. # EC2 완전히 중지 될때까지 기다리기 aws ec2 wait instance-running --instance-ids [instance ID] # EC2 시작하기 aws ec2 start-instances --instance-ids [instance ID] 인스턴스가 실행 상태로 변경 되어야 인스턴스에서 작업을 진행할 수 있다. # EC2 실행 될때까지 기다리기 aws ec2 wait stop-instances --instance-ids [instance ID] # 상태 체크 완료까지 기다리기 aws..

# 배경 Elastic Beanstalk(이하 EB)에 구성된 AutoScaling을 통해 EC2가 추가되거나 줄어들 때 원하는 패키지가 설치되어 있게 하기 위해 AMI를 생성하여 지정 해당 AMI를 지정하는 방식을 구현했다. 테스트로 진행한 방법이 실제 적용을 하려고 하는 중에 적용이 되지 않고 배포가 제대로 되지 않는 문제가 발생하였다. # 문제 이전에 테스트를 진행한 방식 그대로 적용했지만, 제대로 동작하지 않았다. EB의 구성에는 AMI가 변경된 것으로 나왔는데 인스턴스에 접근하여 확인하니 코드가 제대로 배포되지 않았고 500번 에러가 발생하는 것을 볼 수 있었다. 원인은 AMI를 잘못 생성해서 그런 것이었다. 사용하고자 하는 EC2의 인스턴스 유형과 AMI를 생성할 때 사용한 EC2의 인스턴스 ..

# 배경 ElasticBeanstalk(이하 EB)을 통해서 만들어진 EC2에서 설치한 패키지를 인스턴스를 생성할 때 그대로 사용하고 싶었다. EB의 Autoscaling 설정으로 인해서 간혹 EC2가 종료되었다가 새로 올라가는 경우가 생기는데 이럴 때 설치했던 패키지를 사용하지 못하기 때문에 패키지가 설치되어서 올라갈 수 있는 방법이 필요했다. 그러다가 인스턴스를 통해서 AMI를 생성하는 방법을 알게 되었다. # AMI 생성하기 EC2 인스턴스를 선택 후 작업에서 이미지 및 템플릿에 이미지 생성을 누르면 AMI를 생성할 수 있다. 이미지 이름과 설명, 스토리지 크기를 설정할 수 있다. 이미지 생성을 클릭하고 EC2 > 이미지 > AMI를 보면 다음과 같이 생성이 되고 있는 것을 볼 수 있다. 대기 중에..