Skip to content
isdnetworks
Go back

이름으로 리소스를 판단하지 않는다

클라우드 리소스를 재귀적으로 감사해 비용 최적화 후보를 뽑았다. 이름에 임시가 들어간 데이터베이스와 사양이 큰 데이터베이스와 참조가 안 보이는 엔드포인트 셋을 정리 후보로 보고했는데 셋 다 틀렸다.

Table of contents

Open Table of contents

정반대였던 실제 용도

보고를 받은 쪽에서 실제 용도를 알려 줬다. 이름이 임시인 데이터베이스는 테스트 서버가 상시로 쓰고 있었다.

사양이 큰 쪽은 과대 프로비저닝이 아니라 오히려 용량이 부족해 증설을 검토 중이었고 참조가 안 보이던 엔드포인트는 데이터 레이크 구성의 일부였다. 셋 다 내 판단과 정반대였다.

낡은 이름과 간접 참조

이름이 임시인 이유는 처음 만들 때 임시였기 때문일 것이다. 계속 쓰게 됐는데 이름만 안 바뀐 것이고 이름은 만들 때의 의도이고 용도는 지금의 사실이다.

엔드포인트가 미사용으로 보인 것은 직접 참조가 없었기 때문인데 데이터 처리 작업과 데이터베이스 정의와 쿼리 워크그룹이 그 위에 얹혀 있었다. 그 작업들이 내부망 데이터베이스에 접근해야 해서 그 엔드포인트가 필요했고 참조가 간접적이라 자동 감사에 안 보였다.

이름이 준 단서

여기서 흥미로운 것이 하나 나왔는데 데이터 처리 작업의 대상 이름이 임시라는 이름의 인스턴스를 가리키고 있었다. 즉 이름이 임시인 리소스가 다른 파이프라인의 상시 입력원이었다.

이름이 판단 근거가 아니라 후보를 좁히는 힌트일 뿐이라는 것이 여기서 분명해졌다. 그래서 이름이나 인스턴스 크기만으로 삭제나 축소를 제안하지 않기로 규칙을 세웠다.

무엇으로 판단하는가

그러면 무엇으로 판단하는지도 정했다. 실제 연결과 트래픽 지표를 보고 그 리소스를 대상으로 하는 작업과 설정을 찾아 참조 관계를 확인하며 소유자에게 용도를 확인한다.

셋 다 필요한데 특히 마지막이 그렇다. 자동 감사는 소유자 확인을 못 하므로 후보만 뽑고 판단은 사람이 해야 한다. 내가 처음에 결과를 정리 목록처럼 보고한 것이 문제였고 확인이 필요한 후보 목록으로 냈어야 했다.

바뀐 보고 형식

정정을 받고도 하나가 남았는데 데이터 처리 작업의 마지막 수정이 오래됐다는 점이었다. 수정이 오래됐다고 안 도는 것은 아니고 잘 도는 코드는 원래 안 고치므로 실행 빈도는 별도 확인이 필요하다고 미결로 적었다.

이 정정이 없었으면 셋을 정리했을 것이고 테스트 서버가 죽고 파이프라인이 끊기며 용량 부족이 심해지고 데이터 레이크 접근이 막혔을 것이다. 그래서 감사 결과를 근거와 확인 필요 항목과 확인 전에는 정리하지 않는다는 문장까지 함께 내는 형식으로 바꿨다.

정리


Share this post on:

Previous Post
뼈대 비교로 공통 뽑기
Next Post
검색 결과와 DB가 다를 때