1인 DevOps의 고가용성, 작업 효율을 고려한 AWS 비용 최적화 작업 내역

작년 8월에 레벨스로 이직하고 주로 FinOps 비용 절감 관련으로 일을 많이 했다. 그래서 나름 많이 줄이기도 했었고. (자세한 비용을 공개하기는 어렵고..) 관련 작업 내역을 공유한다.

 

먼저 1인 DevOps로 3가지 '축'을 항상 고려한다. 인프라 운영은 비용, 고가용성, 작업 효율이 중요 요소다. 일반적으로 비용을 감소하면 장애 위험이 증가하는 경우가 많다. 그리고 비용 관련 리소스를 삭제하는 것은 작업 난이도가 있고(생성은 쉽고 삭제는 어렵다) 시간이 많이 소요된다.

 

무작정 비용을 줄이거나 반대로 운영 안정성을 증가한다는 명분하에 과도한 인프라 투자는 바람직하지 않다. 적절한 선택이 필요하다. 무엇이든 균형을 잡는 것(중도)이 가장 어렵고 가치있는 일이다.

 

한자로 가운데 '중'은 바람이 불어도 깃발이 쓰러지지 않고 사람이 힘을 써서 깃발을 잡고 있는 것을 형상화하였다고 한다. 적절한 균형을 지키는 것은 참으로 어려운 일이다.

 

특히 1인 DevOps로 10개 EKS 클러스터 업그레이드 + 장애 처리 등 많은 업무들이 있다. 어떤 것이 중요한 일인지 선정하는 것이 매우 중요하다. 그리고 비용을 줄이기 위하여 개발자 도움이 필요한데, 개발자들도 바쁘기 때문에 적절한 협조를 구하기 쉽지 않다. 

 

스타트업은 10% ~ 20% 비용 절감보다 10배, 100배 성장이 훨씬 중요한 조직이다.

 

이러한 제약 사항에서 실행한 작업을 공유해 본다.

 

현황

. 9개 서비스 EKS + 1개 테스트 EKS(나의 장난감)

. Seoul Region Only

. 비용 레포트는 MSP 파트너 통해서

 

CloudCraft 이용한 AWS 리소스 가시화

. 현재 시점의 AWS Resource 리스트를 가져와서 자동으로 그림까지 그려준다.

. 눈으로 보는 효과가 강력하다. 눈으로 보면서 필요없거나 중복된 리소스를 찾아서 줄이는 작업을 반복 실행하고 있다.

. 1인 1년 구독료가 $500, 저렴하다. 현재 구독 중.

. 아쉬운점 :

   AWS MSK, SageMaker, PCA 등 안 보여주는 것이 있다. 

   여러 계정이 같이 사용하는 리소스(TGW, PCA)는 별도 표시 혹은 전체 구성도로 보여주면 좋을 듯

 

KRR, Kubernetes Resource Recommender

. 현재 사용량 기반으로 Resource Requests, Limits 설정을 추천(Recommend) 한다.

. CLI 기반이라 설치, 실행이 쉽고 빠르다.

. 실제 사용량 고려없이 Request 1 core, 0.5 core 할당한 파드들 많다. 실제 사용량은 그보다 훨씬 작다. (참고로 cpu는 limit 설정하지 않는다.)

. 전체 노드의 물리 CPU, Memory의 할당 가용 용량 대비 Request 설정량, 실 사용량(cpu 20%, memory 70% ~ 80%)을 적절히 관리하려고 한다.

. 아쉬운점 :

  리소스 수정을 주기별로 자동으로 해주면 좋을 듯

  리소스 수정은 파드 리스타트가 필요한데 1.27부터 알파 기능인 파드 재시작 없이 In-place Resource Resize 리소스 수정이 가능하면 좋을 듯

 

파드 로그 검색 시스템 ES to Loki

. 기존 ES를 Loki로 변경

. ES 실행에 필요한 무거운 파드 리소스를 Loki 사용해서 비용을 많이 줄일 수 있었다.

. S3 사용해서 스토리지 비용도 많이 줄였다.

. 아쉬운점 :

  아무래도 성능은 차이나는데, 튜닝해서 그리 나쁘지는 않은 듯(로그 용량이 그리 크지 않아서 그런 것 같기도 하고)

 

개발 환경 DataDog to Prometheus, Grafana 변경

. DDog 라이센스 비용 + AWS Data Transfer, CloudWatch 비용 절감

. 헬름 Prometheus Stack 사용하면 설치도 편리하고 그라파나 쿠버네티스 대시보드도 이쁘다.

. 아쉬운점 :

  운영 환경은 변경 못함. 이미 힘들게 만든 대시보드 옮기기 어렵다.

  당장 1달 메트릭만 조회해도 프로메테우스는 느리다. 반면 DDog은 3개월 이상 1년도 빠르다.

 

Daily AWS 비용 Slack 공유

. MSP 업체의 비용 관련 데이터를 API 조회해서 매일 데이터를 슬랙 채널로 전송한다.

. 개발자 + 재무팀 비용 관련 Awareness 향상

. 아쉬운점 : 

  실시간이 아닌 3일 지난 데이터만 조회 가능하다. MSP 없으면 AWS API 직접 찔러서 실시간으로 조회 가능하다고 한다. 

  (MSP 없이 직접 계약하는 신선한 발상이다.)

 

그리고

 

Ingress Group 사용해서 LB 공통 사용

. 작업도 쉽고 효과도 크고

. 내가 이직하고 처음 실시한 작업일만큼 Low Hanging Fruit 이다.

. 2월부터 부과되는 Public IP 비용도 같이 줄어들었다.

 

RI, SP 최적화

. Coverage 80%, Utilization 100% 정도 유지하려고 한다.

 

모든 AWS 리소스 최적화

. 수량을 줄이고(3 Read Replicas to 2 Read Replicas), 인스턴스 사이즈 줄이는 것은 끊임없이 수행 중

 

Dev 환경 Single NAT G/W 

. Dev 환경은 EKS 노드를 단일 AZ 사용해서 Data Transfer 비용은 증가를 막는다.

. 테라폼으로 리소스를 생성하다 보니 과도하게 만드는 경우가 많았다. 처음 설계 시 속도와 신중함 사이에서 균형이 필요하다. 일반적으로 신중하게 만드는 것이 2번 작업하지 않게 한다.

 

CloudHSM to AWS KMS

. KMS도 FIPS 140-2 Levels 3 인증 받았다.

 

Karpenter Consolidation 옵션 적용

. GracefulShutdown, Probe, 이중화 등 잘되어 있으면 노드를 교체해도 별 문제 없는 듯

. 파드의 기본은 VM과 다르게 '항상 죽을 수 있다' 이니 대비만 하면 된다.

 

Spot 인스턴스

. 개발은 Spot 전체 사용, 운영 노드 중 일부 배치 작업 역시 spot 사용

 

사내 FinOps 문화

. 재무 + 개발 + DevOps 정기 미팅

  재무팀과 인프라 비용 관련으로 처음 미팅할 때 서로 용어를 몰라 어색하고 답답했는데, 여러번 만날 수록 많이 나아졌다. 이제 도움도 많이 받고.

 

. C Level 관심

  엔지니어의 주요한 가치 중 하나가 비즈니스 성공이니 비용도 마땅하게 주요한 관심이다.

 

엄청 일을 많이 했다고 생각했는데 막상 정리하면 크게 없다.

 

그리고 여전히 Trust Advisor에 최적화해야할 EC2 인스턴스 수량이 많다. 대부분이 EKS로 옮기지 못한 EC2다. 이전을 못하는 것이 많이 아쉽다.

 

FinOps, 비용 절감 관련 내용은 어렵다기 보다는 많이 알고 있는 상식적인 내용을 귀찮아하지 않고 꾸준히 하는 것이 필요하다. 곧 자동화가 가능한 영역이 많다는 의미다. (이미 Cost Optimizer, Trust Advisor 도 있고.) 물론 AWS 솔루션은 부족한 부문이 있기에 부족한 부문을 채워서 사업을 만들어도 사업성이 있을 것 같다.(1인 기업하고 싶다) 문제는 회사 비용을 줄이는 것이 내 비용을 줄이는 것으로 생각하게 만드는 동기부여가 필요한 것 같다.