운영 비용을 볼 때 함께 확인할 시스템 구성
운영 비용을 볼 때는 인스턴스의 크기 외에도 확인할 것이 있었습니다. 이벤트를 대비해 유지하는 용량, 더 이상 사용하지 않는 자원, 배치 실행 방식, 여러 저장소에 복제된 데이터가 비용과 연결돼 있었습니다.
당시 비용 검토 메모를 바탕으로 각 항목에서 무엇을 확인할지 정리했습니다. 특정 방식이 항상 더 큰 절감 효과를 낸다고 보기보다, 실제 사용량과 과금되는 항목을 연결해서 보는 것이 먼저입니다.
서비스와 환경별 비용 구분
총액만 보면 어떤 변경 때문에 비용이 늘었는지 알기 어렵습니다. 서비스와 환경, 사용하는 자원 종류별로 나누고 같은 기간의 사용량을 함께 봐야 합니다.
AWS에서는 비용 할당 태그로 이런 구분을 할 수 있습니다. 다만 리소스에 태그를 붙이는 것과 비용 보고서에서 쓰도록 활성화하는 것은 별도입니다. 태그가 빠진 자원이나 여러 서비스가 공유하는 자원도 있으므로, 태그별 합계만으로 전체 비용을 설명할 수 있는지 확인해야 합니다.
피크 대비 용량과 평소 사용량
이벤트 트래픽을 대비해 둔 용량이 평소에는 얼마나 필요한지 비교할 수 있습니다. 하지만 평균 CPU 사용률이 낮다는 이유만으로 서버를 바로 줄일 수는 없습니다. 장애 시 남겨야 할 용량, 처리 대기열, 시작에 걸리는 시간도 함께 봐야 합니다.
자동 확장도 설정에 따라 동작합니다. EC2 Auto Scaling 그룹은 원하는 용량을 유지하고 최소·최대 범위 안에서 조정합니다. 부하가 줄더라도 최소 용량을 높게 유지하면 그 아래로 줄지 않으며, 확장 정책 없이 그룹만 만든다고 트래픽에 맞춰 자동으로 변하는 것은 아닙니다.
따라서 자동 확장의 유무만으로 비용을 설명하기보다, 어떤 조건에서 어느 범위까지 조정할 수 있는지를 확인해야 합니다.
미사용 자원과 남겨 둘 자원
테스트용 인스턴스나 오래된 데이터가 계속 비용을 만들 수 있습니다. 정리하기 전에는 현재 트래픽뿐 아니라 정기 배치, 복구 절차, 보관 목적에서도 사용하는지 확인해야 합니다.
사용 흔적이 없다는 것과 삭제해도 된다는 것은 다릅니다. 소유자와 사용 목적을 확인하고, 보관이 필요한 데이터와 실행을 중지할 수 있는 자원을 나눠 검토하는 편이 좋습니다. 인스턴스를 중지하더라도 남아 있는 디스크 등 다른 항목의 비용이 이어질 수 있습니다.
배치 일정과 자원 사용량
서비스 요청과 무거운 배치가 겹치면 같은 자원을 두고 경쟁할 수 있습니다. 일정 조정은 부하를 분산하는 방법이지만, 실행 시간을 옮겼다는 사실만으로 비용이 줄었다고 볼 수는 없습니다.
같은 수의 서버를 같은 시간 동안 유지했다면 인스턴스 비용은 그대로일 수 있습니다. 필요한 최대 용량을 줄였는지, 실행 시간이 짧아졌는지, 과금되는 처리량이 줄었는지를 실제 사용 내역으로 확인해야 합니다. 업무상 완료 시한과 데이터 갱신 지연도 함께 고려할 부분입니다.
복제 데이터와 동기화 비용
DB·검색 인덱스·캐시는 같은 데이터라도 서로 다른 조회 목적을 가질 수 있습니다. 중복이라는 이유만으로 하나를 없애면 조회 성능이나 복구 방식에 영향을 줄 수 있습니다.
검토할 부분은 현재도 그 복제본이 필요한지, 전체 동기화를 반복해야 하는지, 보관 범위를 줄일 수 있는지입니다. 변경분 동기화 역시 삭제·재처리·복구까지 지원할 수 있어야 하므로 구현과 운영 비용을 함께 비교해야 합니다.
변경 후 확인
비용을 비교할 때는 요청량과 데이터량, 비교 기간이 달라졌는지부터 확인합니다. 자원을 줄인 뒤 오류율이나 지연, 배치 완료 시간이 나빠지지 않았는지도 봐야 합니다.
비용 항목을 사용 목적과 연결해 두면 줄일 수 있는 부분과 유지해야 할 부분을 설명하기 쉬워집니다. 리소스를 줄이는 작업과 시스템 구성을 바꾸는 작업 모두, 같은 서비스 수준을 유지하는지 확인하면서 판단할 필요가 있습니다.