bigdata aws 계정의 실제 과금 내용에서 기본적으로 나가는 항목들 파악 및 해당 비용 절감 방안 논의

[hyu-leeky]

bigdata 계정에서 매일 과금 되는 내용을 보면 기본적으로 과금되는 내용이 항상 포함됨.
내용 별로 해당 금액을 방지할 수 있는 방안을 논의해보면 좋을듯 함

[hyu-leeky]

의견 제시는 다들 해주지만 세부적인 과금 내역에 대한건 @Chaewon14 이 챙겨주면 좋을것 같아요.

[hyu-leeky]

S3 에 많은 파일이 있는데 삭제를 한건 삭제를 하고, 저장할 가치가 있다고 판단되는건 glacier 로 옮기기

[Chaewon14]

교수님, 좀전에 유림님과 함께 이번 비용 절감에 대한 방안을 논의해보았습니다.

1. cloud-usage 알림 속 bigdata 계정에서 매일 과금되는 내용 분석
2. 해당 과금 내역을 각 서비스 범주별로 그룹화하여 세부적으로 파악
3. 전체적으로 훑어보면서 불필요한 과금을 줄일 수 있는 방안 논의
4. 특히 S3 버킷 항목을 분석하여 각 사용자(연구실 사람들)에게 물어보기도 하고, 주인이 없거나 옛날에 사용됐던 파일 등을 분류함으로써 삭제할 건 삭제하고, 저장할 가치가 있다고 판단되는 데이터는 glacier에 이동

위와 같은 흐름으로 진행할 계획입니다.
현재 유림님과 함께 분업하여 cloud-usage 알림을 분석하고 그룹화하는 1,2단계를 시작하려하는데, 그전에 교수님께 먼저 보고드립니다.

[hyu-leeky]

네 좋습니다. 이렇게 진행을 해주면 좋을듯 해요.
참조 차원에서 S3 의 경우 연구실에서 전에 S3 버킷안에 있는 파일들을 리스트업 하기 위한 코드를 만들었어요.
이걸 사용하면 어떤 버킷에 어떤 파일이 얼마나 있는지 알수 있어요.

https://github.com/workdd/KMU-s3-delete

[hyu-leeky]

stopped 된 계정들에 대한 정리 필요
특히 snapshot 에 대한 정리가 필요해 보임

[Kim-Yul]

현재 1, 2단계 작업을 진행하여 그룹화까지 파악하였습니다.
지금까지 한 작업에서는 슬랙에 올라오는 알리미를 기준으로 작성하였기에 소유자를 파악하지는 않았습니다.

앞으로는 최근 올려주신 stopped된 계정을 파악하기 위해 사용자를 파악할 수 있는 리스트를 추가적으로 작성할 계획입니다.

1. cloud-usage 알림 속 bigdata 계정에서 매일 과금되는 내용 분석
2. 해당 과금 내역을 각 서비스 범주별로 그룹화하여 세부적으로 파악
3. 그룹화한 리스트 + 사용자 리스트 => 시각적으로 파악할 수 있는 리스트 작성
4. 리스트로 훑어보면서 불필요한 과금, 혹은 사용하지 않는 계정을 줄이는 논의
5. S3 사용자 및 사용하는 파일 분류 후 저장할 데이터는 glacier로 이동

다음과 같이 진행할 계획입니다.
snapshot도 3번 과정을 통해서 정리할 수 있을 것으로 판단됩니다.
채원님과 이야기해보았고, 3번을 시작하기에 앞써 교수님께 보고드립니다.

[hyu-leeky]

오케이. 좋네요. 2번이 완료되었다면 해당 내용을 텍스트도 괜찮으니 공유해줄래요?
많이 보기 어렵다면 3번에 이야기한것 처럼 시각화를 해도 될것 같은데, 그냥 텍스트로만 봐도 충분히 이해할 수 있지 않을까 해요.

[Kim-Yul]

현재 2번까지 작성된 리스트를 PDF로 보내드립니다.
말씀하신대로 표로 정리해도 깔끔할 것 같아 텍스트로 정리하여 완료해보겠습니다.

listUP.pdf

[hyu-leeky]

오케이. 잘 정리했네요. 3번은 굳이 필요없을듯 하고, 각각의 과금 아이템 별로 실제로 어떤 서비스에서 어떻게 사용했기에 과금이 되었는지 확인해보면 좋을것 같아요.
만약에 실제 우리 계정에서 서비스가 남아서 과금이 되고 있다면 어떤 서비스에서 불필요하게 남아있는지 직접 확인해보는것도 좋을것 같아요.

최종적으로 각 아이템별로 조치 방안이 나오는것도 좋을것 같아요. 다만 대부분의 아이템들은 고정적으로 나가는 항목일수 있을것 같기는 해요. 그런것들은 억지로 줄일 필요는 없을것 같구요.

[hyu-leeky]

우선 과금의 비율이 큰것 부터 하나씩 해결해 봅시다.
S3 데이터 처리 하는 모듈은 오전에 이야기 나눈 방향대로 해결 할 수 있을듯 하니, 별도의 이슈를 만들어서 해당 기능을 구현해보면 될듯 해요.
S3 처를 마친 후 stopped 되어 있는 인스턴스에 대한 처리 방안, ebs volume 처리 방법, snapshot 처리 방안등도 함께 고민해봅시다.

[Kim-Yul]

면담 후 받은 조언을 채원님과 이야기하였습니다.
기존에 하고 있던 작업보다 S3가 우선이라고 파악되어 S3를 먼저 진행하기로 하였고, 저희끼리 이야기 해본 계획은 다음과 같습니다.

1. S3의 용량이나 가장 최근에 액세스된 날짜를 파악할 수 있는 리스트 출력 코드 작성하기
2. 리스트를 통해 적절한 기간을 산출하고, 해당 기간보다 오래된 버킷은 glacier로 이동하기 (슬랙에 사전안내)
3. glacier로 옮겨진 데이터 중 사용하지 않는 데이터 영구 삭제

우선 현재 상의한 큰 그림은 위의 내용과 같습니다. 그리고 앞으로 저희는 1번부터 진행해보려고 합니다.

1-1. 모든 버킷에서 (S3의 버킷 이름, 용량, 가장 최근에 액세스된 날짜(혹은 기간)) 3가지 정보를 읽어와 전체 버킷 정보 확인하는 코드 작성
1-2. 적절한 기간을 변수로 잡고, 해당 기간보다 오래된 버킷 정보를 확인하는 코드 작성
1-3. 오래된 버킷 정보를 적절한 기간에 맞추어 자동으로 glacier로 옮기는 코드 작성

부가설명.
1번의 경우 용량에 따른 내림차순으로 확인할 수 있게 하려 합니다.
2번의 경우 정리해야 하는 데이터를 확인하기 쉽게 코드로 작성해두려고 합니다.
1번~3번의 경우 알리미처럼 특정한 기간이 지난 이후 검토하는 방식으로 진행하면 좋을 것 같습니다. 만약 6개월을 적절한 기간으로 두었다면, 액세스하지 않은 지 6개월된 버킷이 생길 때마다 해당 작업이 이루어지는 게 아니라, 2개월에 한 번(예시) 해당 내용을 검토하여 진행하는 것이 바람직할 것이라 생각합니다.

현재는 1-1. 작업을 하기 위해 이전에 올려주신 https://github.com/workdd/KMU-s3-delete 를 참고할 계획입니다!

[Chaewon14]

부재중인 유림님을 대신해서 제가 지금 현재 1-1. "S3 버킷 리스트 코드 작성"을 하고 있습니다.
지난번에 올려주신 KMU-s3-delete 코드를 참고했는데, 현재까지 버킷명/용량/최근액세스한날짜 까지 출력하기까지는 완료했습니다.

("jupyter-system-","sungsoo-", "sungsu-" )로 시작하는 5개의 버킷은 버킷 자체에 오류가 있어 예외처리만 하고 넘겨놨습니다.)

그리고 최근 액세스한 날짜 데이터가 없는 버킷도 있었는데(N/A로 표현된 부분) 이는 정렬하기 어려울 거같아 별도의 조치가 필요할 것 같습니다.

아무튼 이 다음으로는 각 버킷 항목을 용량 크기 내림차순으로 정렬하고,
마지막으로 액세스한 기간이 6개월로 넘어가면 Glacier 이동 대상 버킷으로써 별도의 리스트로 출력하려 합니다.

AWS 버킷 데이터를 불러와서 코드로 작성하는 과정에서 예상치 못한 오류들로 인해 시간이 좀 걸렸지만, 1-1코드작성 단계까지는 크게 어렵지 않을 것 같습니다.

[hyu-leeky]

오케이. 좋아요. S3 버킷의 경우 이상한 에러가 나서 삭제가 안되는 경우도 가끔 있더라구요. 용량의 경우 표시할때는 human-readable format (GB 혹은 MB 형태) 으로 표시 추가해주는것도 좋을것 같아요. 둘이서 만든 계획 좋으니 이대로 진행해봅시다.