핑계라면 핑계겠지만, 개발 일정에 쫓겨가며 부랴부랴 개발을 하고 있던 시절이 있었다. 최대한 노력하며 보기 좋고 깔끔한 코드를 짜고자 했지만, 일이 터지고 말았다. 로컬에서 개발과 테스트를 마친 후, 개발서버에 배포를 했는데 프론트앤드 개발자분에게 바로 메신저가 왔다. 'API 응답이 안오는데요? 제품 로그인이 안되네요.' 나는 로그인쪽을 수정하지 않았기에 내가 원인이 아닐 거라는 생각만 가지고 원인 파악을 들어갔다. (대체 누구야 라는 건방진 생각도 했다지) 로그를 까고 보니 서버는 기동조차 하지 못하고 기동중에 죽어버렸던 것이다. 마지막 서버 로그를 확인해보니 StackOverFlowError 무한참조... 어쩌고... 로그를 내면서 내가 구성한 서비스들끼리에 순환 참조 관계를 그림으로 나타내주었는데..

새로운 서비스들을 도입하면서 여러 설정을 위해 변경하고 배포하는 과정을 계속적으로 작업하다 잘못 배포가 되어 이전 버전으로 Rollback 해야 할 일이 생겼다. 예전부터 공부했던 것처럼 Kubernetes는 컨테이너 오케스트레이션 툴로 컨테이너의 관리가 용이하고 더불어 Deployment라는 타입은 이름에서도 유추되다 싶이 배포에 대한 추적을 관리하고 다시 되돌리는 Rollback기능을 할 수 있다. 사실 실제로 해볼만한 일이 없었다가 이번에 잘못 배포된 버전을 이전 버전으로 배포하기 위해 Rollback 해야 할 일이 있었는데, 우리는 Kubernetes package 관리용으로 오픈소스 helm을 사용하고 있었다. Helm Rollback 방식을 확인해보자 Rollback의 중요성 Rollback을..

현재 프로젝트에서는 관제서버의 다양한 메트릭 데이터를 조회하기 위해서 시계열 데이터 베이스인 Prometheus를 사용하고 있었다. 점차 프로젝트를 SaaS Service로 전환하기 위해 모든 모듈과 서비스의 Scale out 구조를 고민하고 있는데 기존에 Prometheus는 Scale out 구조가 감안되지 않았기 때문에 Scale out 할 수가 없었고, 그로 인해 우리는 Cortex 라는 오픈소스를 도입하게 되었다. 이에 알람을 울려주는 Alertmanager도 다시 연동하게 되었고, 연동하면서 겪었던 어려움들과 이슈들을 어떻게 대응했지는 정리해보고자 한다. (다시 생각하면 정말 끔찍했다.) Work Flow Cortex Alertmanager가 알람을 등록하고 알람이 울려 Client에게 울리기..