EC2 메모리 문제 해결과 Elastic IP 적용: 인스턴스 유형 변경 후 IP 문제 극복기

2023. 12. 20. 14:28ㆍProject 해축갤/인프라

728x90

상황

어제 EC2에 Spring Boot와 MySQL을 실행시키려 하니 다음과 같은 에러가 나왔습니다.

죽어버린 MySQL...

이유는 OOM(Out Of Memery) Killer 가 mysql.service를 죽였다는 것.

사실 이럴만도 한 게 기존에 쓰던 EC2의 스펙이 t4g.nano였습니다.

이 EC2 인스턴스의 스펙은 대략 다음과 같습니다

t4g.nano

AWS Gravition Processor(CPU) 2 개와 메모리 500MB짜리입니다.

여기서 주요 문제는 메모리 용량입니다.

현재 지금 돌아가고 있는 EC2의 RSS(실제 사용하는 물리 메모리양)를 보면

ps aux 를 통한 실제 사용량 측정

mysql 은 396MB, Spring Boot는 222MB 인걸 확인할 수 있습니다.

(상황 종료 후의 spring boot, mysql을 확인한 것입니다.)

 

심지어 mysql 은 새로 설치해서 실행만 한 거고 spring boot는 현재 아무런 트래픽을 받지 않는 데도 이 모양인걸 보고

제 아름다운 t4g.nano는 보내줘야 함을 알았습니.

이 문제를 해결하기 위해, t4g.micro로 인스턴스 유형을 변경했습니다. 

t4g.micro

그 결과 spring boot, mysql 둘 다 아름답게 돌아가는 것을 확인할 수 있습니다.

여기까지야 뭐 금방 해결은 했는 데 문제는 계속 생겼습니다.

인스턴스 유형 변경은 IP를 바꾼다

이게 뭔 소리가 하면 EC2의 인스턴스 유형 변경은 인스턴스 중지를 해야 가능합니다.

하지만 EC2 인스턴스는 매 실행시마다 랜덤 하게 IP를 할당받는 시스템이기에 중지 후 재가동시 새롭게 IP 를 할당받게 됩니다.

이를 모르고 그냥 GitHub에 push 했더니 CI/CD 파이프라인에서 터져버렸습니다.

그래서 에러 로그를 까보니

Connection timed out

connection timed out 에러가 났는 데이 에러는 보통 없는 ec2에 연결하려고 할 때 이와 같은 에러가 자주 나는 에러입니다.

그래서 IP 가 바뀌었나 생각하고 EC2 콘솔창을 봤더니 IP 가 바뀌어 있었습니다.

캡처를  못해서 사진이 없습니다,,, 이해를 돕기 위한 콘솔창을 봤다는,,, 사진,,,

가벼운 솔루션

사실, 간단한 해결책은 GitHub의 저장소 비밀번호(repository secrets)에 새로 할당된 EC2 호스트 주소를 업데이트하는 것입니다.

Repository Secrets

근데 이렇게 인스턴스 유형 업그레이드가 한번 있고 말만 한 일도 아니고 그렇다고 이걸 매번 이렇게 따박따박 수정한다?

하지만, 이러한 수동 업데이트가 진정으로 '자동' 배포라고 할 수 있을까 하는 의문이 들었습니다.

 

제가 테스트 코드도 짜고, CI/CD 도 다하는 이유는 뭐 생산성이라는 이유보다도 일일이 반복하기 싫어 이를 프로그램으로 짜는 건데,,,

귀찮은 일은 가능한 피하고자 하는 저로서는 이 과정도 자동화할 수 있는 솔루션을 고민하게 되었습니다

찐 솔루션 후보군

동적 IP에 대해 어떻게 대응할 것이냐 가 문제입니다.

ec2 자체의 IP 고정 할당은 안될 거니 이를 우회하거나 dns 같은 방법을 써야 합니다.

생각한 솔루션은 3가지입니다.

  1. Elastic IP
  2. Route 53
  3. CodeDeploy.

각각의 간단한 설명과 장단점을 한번 알아보죠.

  1. Elastic IP (탄력적 IP)
    • 설명: AWS의 탄력적 IP는 고정된 공용 IP 주소를 제공합니다. 이 주소는 인스턴스에 연결되어 있으며, 인스턴스를 재시작하거나 변경해도 IP 주소가 변하지 않습니다.
    • 장점:
      • IP 주소가 변경되지 않아 CI/CD 파이프라인에서 주소를 업데이트할 필요가 없습니다.
      • 쉽고 빠르게 설정할 수 있으며, 인스턴스에 바로 적용됩니다.
    • 단점:
      • 인스턴스가 중지된 상태에서 IP가 사용되지 않으면 추가 비용이 발생할 수 있습니다.
      • 고정 IP 이기 때문에 DDos, 포트 스캐닝 같은 공격을 시도하기가 쉽습니다.
    • 링크
  2. Route 53
    • 설명: AWS Route 53은 확장 가능한 도메인 이름 시스템(DNS) 웹 서비스로, 도메인 이름을 EC2 인스턴스의 IP 주소에 매핑합니다.
    • 장점:
      • 도메인 이름을 통해 인스턴스에 접근할 수 있어, IP 주소 변경에 영향을 받지 않습니다.
      • IP 주소가 변경되더라도 DNS 레코드 업데이트를 통해 쉽게 관리할 수 있습니다.
    • 단점:
      • 초기 설정이 복잡하며, 도메인 등록 및 유지 관리에 비용이 발생할 수 있습니다.
      • DNS 설정 변경이 전파되는 데 시간이 걸릴 수 있습니다.
    • 링크
  3. CodeDeploy
    • 설명: AWS CodeDeploy는 개발자가 AWS 서비스를 사용하여 애플리케이션을 자동으로 배포할 수 있도록 하는 서비스입니다.
    • 장점:
      • 인스턴스의 IP 주소가 변경되어도 배포 프로세스에 영향을 미치지 않습니다.
      • 복잡한 배포 시나리오와 자동화된 배포 프로세스를 지원합니다.
    • 단점:
      • 파이프라인을 AWS CodeDeploy에 맞게 재구성하는 데 시간과 노력이 필요합니다.
    • 링크

선택은?

솔직히 다 좋아 보이는 기술이지만 물론, 상황에 맞는 최적의 기술 선택이 중요합니다

지금 저의 상황, 즉 요구사항은 다음과 같습니다.

  1. 무료이냐 (날먹하기)
  2. 기존 시스템(GitHub Actions)을 변경하지 않아도 되냐

그래서 이를 정확히 충족하는 서비스는 Elastic IP입니다.

  1. Elastic IP는 EC2 인스턴스에 연결만 되어 있다면 요금이 나가지 않습니다.
  2. https://repost.aws/knowledge-center/elastic-ip-charges
  3. GitHub Actions의 스크립트는 수정할 게 없다.

그래서 저는 Elastic IP를 선택, 적용했습니다.

간단한 적용

우측 상단에 탄력적 IP 주소 할당 버튼을 누르고

우측 하단 할당

할당 버튼을 누르면

이렇게 Elastic IP 가 하나 생기고, 할당된 IPv4 주소를 누르면

우측 상단에 탄력적 IP 주소 연결 버튼이 있습니다.


그럼 밑 인스턴스 열에서 현재 계정에 있는 ec2 인스턴스를 연결할 수 있습니다.

연결 후 EC2 인스턴스의 콘솔창을 가게 되면

퍼블릭 IPv4 주소가 Elastic IP로 바뀐 걸 확인하실 수 있습니다!

결론

EC2 인스턴스 재가동시에는 IP 가 동적 할당됩니다.

동적 주소가 문제가 된다면 다음 솔루션들을 채택해 볼 수 있습니다.

  1. Elastic IP
  2. Route 53
  3. CodeDeploy

지금 당장은 Elastic IP를 사용합니다만,

Elastic IP 은 장점인 고정성 때문에 동시에 파생되는 보안 문제들이 있습니다.

때문에 추후에는 이를 추가적인 확장성과 보안을 위해 CodeDeploy로 변경 예정입니다.

배운 점

새삼 예전에 네트워크 엔지니어로 일하다 백엔드로 전환한 지인한테

최강의 네트워크, 인프라를 구축하기 위한 방법에 대해 물어본 적이 있는 데

돌아온 답변이 다음과 같았었습니다.

별거 없어 그냥 돈 바르면(?) 돼~

예전에는 그냥 그려려니 했는 데 새삼 오늘 EC2 업그레이드하면서 돈이 편하긴 하다(?)라는 결론을,,,

라기 보단! 최대한 해볼 거 다 해보고 결국 어쩔 수 없을 때 돈을 써야 한다라는 걸 배웠습니다! ㅎㅎ

긴 글 읽어주시느라 고생 많으셨습니다!

728x90

티스토리툴바