[AWS] 젠킨스 t2.micro에서 돌리기 (feat. Swap)

'드링크히어'를 위해 VPC 생성 후 Public Subnet/Private Subnet으로 다 분리한 후 ECS, RDS 그리고 ElastiCache를 배치한 뒤 InternetGateway가 위차한 Public Subnet에 Bastion Host를 배치했다.
처음에는 어차피 Private Subnet에 위치한 RDS에 Workbench를 통해 접속하기 위해 생성했지만 어차피 노는 서버라서 Jenkins도 같이 사용하면 좋지않을까해서 Jenkins를 설치해봤다.

 

Java21과 Jenkins를 설치하고나서 free -h를 했을때 아래와 같이 약 300MB 밖에 안남은 것을 확인했고 실제로 빌드하게 종종 터지는 현상이 있었다.

타 블로그 참조 (거의 유사했음)

프리티어의 경우 아마 30GB의 디스크 용량을 제공하지만 메모리(RAM)의 경우 1G만 제공하기 때문에 메모리에 비해 RAM이 턱없이 부족했다.

애초에 젠킨스 전제조건을 보면 거의 힘들다고 보면 될 것 같았다.

 

이때 블로그를 검색해보니 Swap이라는 개념을 도입하여 디스크 메모리를 RAM 처럼 사용하는 개념이 있길래 도입해봤다.

---

 

Swap은 운영체제에서 메모리 관리의 일환으로, 물리적 메모리(RAM)가 부족할 때 디스크 공간의 일부를 임시 메모리처럼 사용하는 기능이다. AWS 환경에서도 스왑은 EC2 인스턴스의 메모리 관리를 위해 활용될 수 있다.

 

가상 메모리의 동작 원리
https://resilient-923.tistory.com/397

 

실제 설정 과정

위와 같이 설정했고 마지막에 Swap 메모리가 2Gi 추가적으로 확보된 것을 확인할 수 있다.

 

 

CPU 점유율의 급증의 원인

• I/O 연산: 디스크 I/O는 RAM에 비해 상당히 느리다. swap 영역에 데이터를 쓰거나 읽는 것은 RAM에서 직접 데이터를 처리하는 것에 비해 훨씬 오래 걸린다. 따라서, swap을 자주 사용하면 이로 인해 발생하는 I/O 연산이 CPU 부하를 증가시킨다.
  
  
• 페이지 폴트: 물리 메모리에서 페이지가 사라지고 swap 영역으로 이동하면, 해당 페이지에 접근할 때 페이지 폴트(page fault)가 발생한다. 페이지 폴트(page fault)는 프로세스가 접근하려고 하는 메모리 페이지가 물리적인 메모리(RAM)에 로드되어 있지 않을 때 발생하는 상황을 말한다. 페이지 폴트가 발생하면 운영체제는 해당 페이지를 물리 메모리에 로드해야 한다. 이런 페이지 폴트 처리도 CPU 부하를 증가시키는 원인 중 하나이다.
   

AWS에서 스왑은 RAM 부족 문제를 완화하기 위한 임시적인 해결책으로, 디스크 공간을 활용해 애플리케이션 안정성을 높이는 데 도움을 준다. 하지만 성능 저하 가능성을 고려해야 하며, RAM 확장 또는 애플리케이션 최적화와 같은 장기적인 해결책과 함께 사용하는 것이 바람직하다.