AWS 비용관리의 서막, EMR

FinOps? EMR 비용관리

비용관리의 서막, FinOps?

비용관리를 본격적으로 시작하게되는 때는 언제일까요? 비용관리에 대한 책에 감명을 받아서? 물론 FinOps에 관한 책을 추천 받았고 이런 책이 있다는 것에 대해서 놀라기도 했습니다. 본격적으로 비용관리를 체계를 갖추어 해야겠다는 생각도 같이 들었습니다. 하지만 일반적으로는 AWS 요금이 과하게 부과된 날이지 않을까 합니다. 12월의 평화로운 어느 날에 개발 팀장님께서 조용히 저를 부르셨고, 충격적인 12월의 요금을 보면서 비용관리의 필요성을 깨닫게 되었습니다.

앞서 FinOps에 관한 책을 추천 받았다고 했는데, 이 책을 기반으로 비용 관리를 해야겠다고 마음을 먹었습니다. 이 책은 마이클 풀러의 Cloud FinOps: Collaborative, Real-Time Cloud Financial Management 입니다.
책에 대한 소개글을 작성하려고 한게 아니기 때문에 간단하게 책에 대해서 읽어본 소감을 말하자면, 엄청나게 세밀하게 관리포인트를 집어주지는 않습니다. 제가 아는 내용이 많지 않아서 그럴 수도 있겠습니다. 비용관리라는 말을 듣고 어떻게 관리할 수 있을까? 에 대해서 생각해보면 나오는 개념들이 정확한 용어로 설명이 되어있기는 합니다. 나쁜 책은 아니라고 생각합니다. 실무자보다는 윗 분들이 먼저 읽었으면 합니다.

FinOps

FinOps는 Finance + DevOps가 결합된 말입니다. 클라우드 환경에서 재무와 개발/운영을 긴밀히 결합함으로써 비용을 최적화하여 관리하고 통제할 수 있도록 하는 것입니다. 클라우드 비용 최적화를 위한 베스트 프렉티스와 공통된 표준 정책으로 기술과 비즈니스, 재무 전문가를 결합함으로써 비즈니스 가치 극대화하려는 것입니다.(출처 : Bespin Global)
회사에서 비용관리를 제대로 시작하게 되면서 FinOps라는 말을 붙이지는 않았습니다. 재무에 관련된 인원을 포함하기 어려웠기 때문입니다. 대신에 비용관리에 관련된 사람들이 모였습니다. AWS의 비용 급상승에 관련된 부서의 실무자와 개발 팀장님, TA, 기획 팀장님입니다. 사실상 운영에 관련된 모든 사람이 모이게 되었습니다. 이렇게 모인 사람들과 비용에 대해서 논의했고 현재는 1차적인 최적화 작업을 완료하였습니다.

비용의 원인, EMR

다시 문제의 12월의 끝자락으로 돌아와서, 원인 파악을 해보기 시작했습니다. 원인 중 하나는 EMR 비용의 갑작스러운 증가였습니다. EMR이 무엇일까요? 구글에 검색하면 기다렸다는 듯이 AWS는 문서를 만들어 놓았습니다. 쉽게 말하자면, EMR은 AWS 위에서 Hadoop이나 그 기반 프레임워크들을 위한 빅 데이터 프레임워크 실행을 간소화하는 관리형 클러스터 플랫폼입니다. 저희의 경우 Spark를 사용하기 위해 EMR을 쓰고 있습니다.

예상되는 비용 포인트

1. 많은 고객사에 대한 대응
2. 오버 사이징된 클러스터
3. Airflow TerminateJobFlow
4. EMR Cluster 관리

첫 번째는 많은 고객사에 대한 대응이였습니다. 새롭게 오픈한 서비스로 인해 고객사가 갑자기 많이 들어오게 되었습니다. FinOps 책에 나온대로, 비용은 $사용량\times요율$ 이므로 사용량이 늘어났기 때문에 비용이 갑자기 증가될 수 밖에 없었습니다. 갑자기 늘어난 고객사를 줄일 수도 없는 노릇이므로, 다른 관리 포인트를 찾아 봤습니다.

두 번째는 오버 사이징된 클러스터였습니다. 현재 제공하고 있는 서비스들은 대부분 Airflow를 사용해서 Spark로 작업을 처리한 뒤 종료되는 구조를 가지고 있습니다. 작업을 할 때 만들어지는 클러스터들의 스펙은 대부분 동일한데, 소규모 고객사에 대해서 서비스를 할 때도 같은 스펙을 사용하고 있었습니다. 고객사의 일 평균 방문 수와 상품의 sku 수를 따져서 고객사 규모를 측정하는데, 이 기준에서 작은 고객사로 분류되는 고객사들의 클러스터 스펙을 조정해 주었습니다.

세 번째는 Airflow의 TerminateJobFlow입니다. 앞서 설명한대로, EMR 클러스터는 작업을 마치면 Airflow의 TerminateJobFlow 오퍼레이터를 이용해 작업을 종료해 클러스터를 삭제하게 됩니다. EMR은 오래 돌 수록 요금이 어마어마하게 부과되기 때문에 이런 파이프라인을 만들어 두었습니다. 그런데 가끔 이 오퍼레이터가 말을 안듣는 경우가 발생하곤 합니다. 현재의 Airflow에 있는 DAG들은 새벽에도 많이 실행되고 있습니다. 그래서 출근했을 때 새벽 내내 돌고 있는 EMR 클러스터들을 마주하게 되는 경우가 종종 있었습니다.

이런 와중에 EMR 콘솔 페이지에 나오지는 않지만 EC2 페이지에 등장하는 EMR 클러스터들이 발견되었습니다. 12월 초 부터 쌩쌩 도는 인스턴스들이었는데, 네임 태그도 달려있지 않은, 알 수 없는 것들이었습니다. 12월 초 부터 계속 돌고 있었기 때문에, 여기서 큰 비용이 발생하고 있었습니다.

그래서 이 인스턴스들이 왜 남아있는지 알기 위해서 AWS측에 문의를 넣었습니다. 몇 번의 핑퐁이 오갔고
“As you can observe above, that either the cluster didn’t finish the step it was running or the step itself didn’t get submitted to it or the TerminateJobFlows API call was not made by the Airflow workflow.”
이러한 답변과 기타 등등을 얻을 수 있었습니다. 결국 미팅을 잡고 이야기 하기로 했습니다.(참고로 보통 이런 미팅을 하게 되면 인도 출신 엔지니어와 이야기를 하게 됩니다. 저는 인도 악센트에 친숙하지 않아서 애를 많이 먹었습니다. 전화 미팅이었지만 이역만리 타국과의 통화에 감사함보다는 실시간 채팅에 더 감사하게 되었다는 후기)

AWS 측과 얘기를 한 후 추가로 알게 된 사실이 있었습니다. 그것은 VisibleToAllUsers라는 옵션이었습니다. AWS EMR에는 독특하게 모든 유저에게 클러스터를 보이는, VisibleToAllUsers이 존재합니다. 이 옵션이 체크되어 있지 않으면, 클러스터 페이지에서 해당 클러스터를 볼 수 없게 됩니다. 12월에 종료되지 않은 이 클러스터들은 이 옵션에 체크되어 있지 않은 상태로 생성이 되었고, 그래서 클러스터 콘솔 페이지에서 관리를 할 수 없었던 것이었습니다.

Airflow에서 EMR 클러스터를 생성할 때도 마찬가지입니다. VisibleToAllUsers옵션을 지정해서 클러스터를 생성할 수 있습니다. 이 옵션이 제대로 지정되지 않았고, 그래서 삭제되지 않고 관리되지 못한 인스턴스들이 발생한 것이었습니다. 12월 초에 새로운 서비스를 위한 Airflow 인스턴스를 새로 만들었는데, 이 파라미터값을 관리하는 Connection 부분이 초기화 되었던 것입니다. 당시에 인수인계다 뭐다 정신이 없었고 그런 상황에서 체크를 제대로 하지 않고 넘어갔던 것이 화근이었습니다.

아무튼 이렇게 해서 Connection에서 emr_default 부분에 VisibleToAllUsers을 true로 변경해 주었고, 클러스터 페이지에 나타나지 않는 인스턴스들은 사라지게 되었습니다. 하지만 추가 대응 방안이 필요했습니다. (AWS 측에서는 Airflow 매니지드 서비스를 이용하라고 했지만, 진심 너무 비쌉니다. 이렇게 된거 GCP로 옮기면 어떨까? Composer 참 싼데, 보고 있나 AWS?? You See Me??)

네 번째는 EMR Cluster 관리에 대한 것입니다. EMR Cluster 페이지에 직접 들어가서 삭제되지 않은 클러스터들을 일일이 보는 프로세스가 맘에 들지 않았습니다. 자동화에 집착하는 집착맨이기 때문에, 좀 더 세련된 방법을 찾고 싶었습니다. TA 분과 이야기 해 본 결과 boto3를 이용하면 클러스터에 페이지에 쉽게 접근할 수 있다는 것을 알 게 되었습니다.

boto3로 클러스터 관리하기

Boto3는 AWS에서 제공하는 파이썬 용 SDK(software development kit)입니다. boto3를 사용하면, S3나 EMR등 AWS의 다양한 서비스에 접근이 가능합니다.

boto3가 없다면 pip3 install boto3로 설치해 주시고, AWS에 로그인 해줍니다.

import boto3
from pprint import pprint

client = boto3.client('emr')

response = client.describe_cluster(ClusterId='j-xxxxxxxxxx')

pprint(response)

이렇게 입력을 해주면 해당 클러스터 아이디에 대한 값들이 쫙 나오게 됩니다. 너무 쉽죠? AWS를 쓰세요. boto3는 참 좋습니다. 대신 더럽게 비쌉니다. 이 정보들은 dictionary로 되어 있으니, 키 값을 잘 조회 해서 값에 접근하면 됩니다.

대표적인 키 값은 Cluster, Ec2InstanceAttributes, Id, Name, NormalizedInstanceHours, Status, Timeline 등입니다. 저는 TimeLine을 이용해서 생성시간과 현재시간의 차를 구한 다음, 항상 띄어놓는 분석용 EMR 시간보다 작고 5시간 이상 RUNNING하거나 WAITING하고 있는 클러스터들을 종료시킬 생각입니다. 활용방안은 다양하니 각자의 관리포인트대로 작업하시면 될 것 같습니다.

---

이렇게 해서

비용관리가 발생한 상황과, FinOps, EMR, 관리 방법에 대해서 간단하게 작성하게 되었습니다. 문제 상황부터 지금까지 우여곡절이 참 많았는데, 정리하니까 내용은 그렇게 많지 않네요. 삽질을 많이 했다는 뜻입니다. 여러분들은 부디 삽질을 최소화하시고 많은 이득을 취하시길 바랍니다. 짧막한 삽질 글을 읽어주셔서 감사합니다.