너무 느렸던 EFS

https://kiioio.com 블로그는 CRUD로 사용하는 데이터베이스가 EFS 파일시스템에 있었다. 잘못된 아키텍처로 Throughput 한계는 알고 있었지만 실제 DB 상품은 비싸서 꼼수를 부리다 탈났다.

그리고 2025-7-20 기점으로 급격하게 EFS 파일시스템이 느려졌다.
게시글이 400개 이상 되었을 때 알 수 없는 오류와 이상 현상들을 겪었고,
소스파일이 없다고하거나 데이터베이스에 락걸리거나, 게시글이 사라지는 등의 현상이다.

환경

먼저 EFS 상품은 가장 저렴한 솔루션을 사용하고 있었다.

• 사용 중인 EFS는 상대적으로 저렴한 Bursting 말고는 설정이 안되어있음.

EFS 모니터링

• Throughput 사용량만 과포화 상태로 확인된다.

대체 방안 경험

EFS 처리하는 대신 다른 솔루션으로 교체하기로 했다.
테스트 솔루션으로 Aurora DB로 이전했으나 전체적으로 잘 동작하였다. 허나 이 작은 사이트 계속 운영하기에는 비용이 높다. Digital Ocean 옮겨보기도 했으나 내가 직접 운영하는 사이트처럼 매력적이지는 않았고, 사이트의 데이터를 모두 정적 콘텐츠로 내려받아 S3으로 운영하는 방법도 생각했으나, 글 작성하고 배포하는 과정이 예상 외로 번거롭다. 무엇보다 내재된 Tag 방식과 Fuse블로그 검색 기능이 안된다는 점이 나를 괴롭게 만들었다.

다시 되돌아가 결국 EFS 사용했던 것처럼 고쳐 사용하기로 했다.

문제 원인 인식

노드 배포는 ECS 솔루션으로 사용하고 있었고 EFS 볼륨으로 붙어 다이렉트로 EFS에서 IO 처리를 담당 하였다.

문제 해결 과정

여기서 IO 처리를 EFS가 담당했으므로 ECS 노드 내부에 있는 임시 디렉토리 공간에 대신 처리하도록 유도했다.
방법은 간단한데 EFS 안에 있는 DB 파일을 ECS 임시 디렉토리로 옮겨주는 것이었다.

다만, ECS 노드가 DB로 옮긴 경우 노드는 휘발성이므로 종료 시 자동으로 안에 있는 DB가 날라간다. 이로 인한 몇 가지 노드 조치사항들 필요했다.

ECS 노드에게 취한 조치

• 노드 시작 시 EFS DB를 노드 내부의 임시 디렉토리로 옮긴다.
• 노드의 서비스 운영 시 임시 디렉토리로 가리키도록 한다.
• 노드의 서비스 종료 시그널이 발생하면 임시 디렉토리의 DB를 EFS로 옮긴다.
• 노드가 DB를 옮기는 과정에서 손실되지 않도록 무결성 검사와 지연시간을 부여한다.

ECS 서비스에 취한 조치 - 모놀리식 아키텍처로 운영

• 임시디렉토리 DB를 처리하므로 서비스를 시작하는 노드는 모놀리식으로 운영한다.
• 배포 파이프라인을 롤링 업데이트로 변경하였다.
• 오토스케일링 인/아웃을 제거하고, 문제가 생긴 경우 기존 노드의 DB를 EFS 완료한 다음에 새로운 노드를 운영하도록 하였다.

위의 조치들을 모두 취하니 놀라운 결과가 나타났다.

나가는 비용은 그대로 유지하였거나 오히려 줄어들었다. 그리고 성능은 기존에 있었던 사이트 접속의 병목이 모두 제거되었다. 그 뿐 아니라 Fuse 검색 또한 굉장히 빠릿해 만족스럽다.

모놀리식 운영이라 ECS에서는 파이프라인 자동 배포말고는 이점이 없는데 이참에 EC2로 복귀하는 것도 고려해보고 있다.