분류 전체보기

Redis OOM 장애

거의 1년만에 아티클을 작성하게 되었는데, 오랜만에 작성하게된 아티클의 주제는 제가 직접 겪어본 Redis OOM으로 인한 장애에 대해서 공유를 해보고자합니다. 해당 아티클의 순서는 아래의 순서로 전개될 예정입니다.Redis OOM이 일어나게 된 배경Redis 아키텍처 돌아보기단기적인 장애 대응 방법최종적인 장애 대응 방법, 그리고 회고글 마무리Redis OOM 장애가 일어나게 된 배경제가 운영하던 백엔드의 API 일부 중에는 Redis를 적극 활용하여 대용량 데이터를 프로세싱하여 클라이언트에게 추천 데이터를 반환해주는 로직이 하나 있었습니다.그리고 API 서버는 ECS 환경에서 운영되어 트래픽이 늘어나거나, 혹은 CPU, MEM 사용량을 관측하여 일정 임계치를 넘어가면 태스크의 개수를 스케일 아웃하도록..

Docker File System (Overlay2)

얼마전 회사에서 트러블슈팅을 진행하면서 docker exec 명령어를 이용해서 container의 bash쉘을 연 다음에, 바로 컨테이너 내부의 파일을 변경한 적이 있었습니다. 그런데 저는 여기서 의아한 부분이 하나 있었습니다. 과연 Docker 컨테이너 내부의 파일을 저렇게 바로 변경해도 되는가? 였습니다. 이에 대해서 공부를 하던 중에, Ubuntu의 docker는 기본적인 파일시스템으로 Overlay2를 채택하고 있었고, 또한 Overlay2 스토리지 시스템의 특징으로 인해서 컨테이너 내부의 파일을 바로 변경한다고 해서, 근간이 되는 image의 레이어가 훼손되지는 않는다는 것을 알게되었습니다. Overlay2 스토리지 시스템에 대해서 공부한 내용들을 이 포스트를 통해서 공유드려볼까 합니다. 1. ..

엘리스 3차 프로젝트 후기 (feat. 엘리스 AI트랙의 끝)

오랜만에 글을 쓰게 되었습니다. 최근에 엘리스 3차 프로젝트를 하느라 글을 못 쓰고 있던 상황이었는데, 얼마 전에 엘리스 3차 프로젝트가 끝남과 동시에 수료를 하게 되었습니다. 따라서 이번에는 엘리스 3차 프로젝트 후기 및 수료에 대한 소감에 대해서 글을 써보려고합니다. 1. 3차 프로젝트의 팀 구성 엘리스 AI 트랙의 3차 프로젝트는 4월 15일 부터 5월 20일 까지 진행되었습니다. 팀은 4월 15일 정도에 발표가 되었는데, 정말 다행스럽게도(?) 제가 평소에 이 분이랑 같이 팀으로 활동하면 정말 좋겠다... 싶은 분들이 많이 계셔서 이번엔 진짜 엄청난게 나오겠는데? 라는 생각을 무의식적으로 하게되었습니다. 저희 팀은 6인 팀으로, 프론트엔드 3명, 백엔드 3명 이렇게 구성이 되었습니다. 프론트엔드에..

Kubernetes 워커노드의 OOM에 의한 클러스터 장애

이번 글에서는 Kubernetes 워커노드에 OOM이 발생하여 모든 워커노드가 연쇄적으로 장애를 일으키는 바람에 쿠버네티스 클러스터가 통째로 먹통이된 사건에 대해서 다뤄볼까합니다. 0. 상황 현재 저는 엘리스파크 라는 토이프로젝트를 진행중에 있습니다. 그리고 엘리스파크의 백엔드를 쿠버네티스 환경에서 운영중이며, 동시에 엘리스파크의 백엔드를 빌드시키는 젠킨스 서버를 모두 쿠버네티스 위에서 운영중에 있습니다. 제가 운영중이던 쿠버네티스 환경은 아래와 같습니다. Amazon EKS (Kubernetes v1.22) 각 워커노드는 t3.medium 인스턴스로 운영중에 있었음 (vcpu 2 + 4Gi Memory) 단일 노드그룹에 워커노드는 min size = 2, desired size = 2, max size..