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

[kmu-leeky]

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

[kmu-leeky]

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

[kmu-leeky]

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

[Chaewon14]

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

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

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

[kmu-leeky]

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

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

[kmu-leeky]

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

[Kim-Yul]

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

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

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

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

[kmu-leeky]

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

[Kim-Yul]

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

listUP.pdf

[kmu-leeky]

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

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

[kmu-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코드작성 단계까지는 크게 어렵지 않을 것 같습니다.

[kmu-leeky]

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

[Chaewon14]

교수님 S3 버킷 리스트 코드 작성 완료했습니다!

• 버킷 용량에 따른 내림차순 정렬한 ordered_bucket_list
• Glacier 대상 버킷만 모아놓은 go_to_Glacier_list

두 리스트 모두 s3_bucket_list.txt 파일에 작성되도록 하였습니다.
s3_bucket_list.txt

아래는 추가적으로 보완할 부분입니다.

1. 용량 단위은 일단 MB로 변환해놨는데, 너무 큰 용량은 GB로 표시할까 싶습니다.
2. Glacier 대상이 되는 기간은 일단 6개월로 정해놓고 코드를 작성했는데, 나중에 수정이 용이하도록 변수로 바꿀 예정입니다.
3. 최근에 엑세스한 날짜가 없는 버킷은 제가 'N/A'라는 임의의 값을 넣어놨으며, Glacier 대상 버킷 리스트에 포함시켰습니다.
   (실제 Glacier로 옮기는 작업을 진행하기 전에 해당 go_to_Glacier_list를 슬랙에 올려 주인에게 알릴 것이기 때문입니다.)

[kmu-leeky]

오케이. 좋네요.

다들 s3 버킷 보고 keep 되어야 하는 파일 있으면 미리 알려주고.
6개월 기준으로 glacier 로 보내는것 좋아요.
현재 S3 의 버킷별 사이즈는 그래도 최소한 한달에 한번 정도는 리포트가 되면 좋을것 같아요.
이때 조만간 glacier 로 가는 리스트는 별도로 보여주면 좋겠네요.
구체적인 동작방식은 채원 학생과 유림학생이 잘 상의해서 결정해주고, 이슈에 공유해서 의견 들어보고 구현해봅시다.

[Chaewon14]

네 유림님과 상의해보았습니다.

일단 cloud-usage처럼 모든 S3 버킷에 대한 리스트를 한달에 한번씩 슬랙에 알림으로 올리고, 그중 6개월이 지난 버킷 리스트는 따로 조만간 glacier로 보낼거라고 2달에 한번씩 알리면 어떨까 싶습니다.
그러면 사용자가 glacier 보내고 싶지 않은 버킷은 백업 또는 새로 액세스하여 각자 관리하도록 하고, 5일 뒤에 해당 변경 사항이 적용된 glacier 보낼 버킷 리스트를 확인 후 실제로 glacier로 옮기는 작업을 하는 것이 좋을 것 같습니다.

즉 과정을 다시 요약하면,
그냥 알림은 1달에 한번, glacier로 보낼거라는 알림은 2달에 한번, 5일 뒤 변경사항 적용해서 실제 glacier로 이동 입니다.

[kmu-leeky]

오케이. 제가 보기에는 괜찮은것 같아요.
예를 들어 매달 1일에는 S3 사용량 보고가 오고
매 짝수달 1일에는 glacier 로 보내는 리스트가 오고, 매 짝수달 6일 에는 다시 한번 최종적으로 glacier 로 보내는 리스트가 오고, 짝수달 7일 정도에 glacier 로 보내는 작업을 하면 될것 같네요.

혹시 위의 계획에 이슈가 있을것 같은 사람은 이야기를 해주면 좋고, 괜찮아 보인다면 이모티콘 표시해주면 적절히 해당 방향으로 진행해 나갈수 있을것 같아.

[Chaewon14]

• S3 사용량 보고 알림 (매달 1일)
• Glacier 이동 예정 알림 (매 짝수달 1일) (5일 뒤 이동 예정 메시지 포함)
• 최종적으로 Glacier로 보내는 버킷 리스트 (매 짝수달 6일)

그럼 이렇게 람다함수 3개 생성 진행하겠습니다!
교수님 그리고 glacier로 실제로 전송하는 작업 또한 수동이 아닌 코드로 구현해야하는 부분일까요?

[kmu-leeky]

네 그럼요. glacier 이동 도 코드로 구현. 대략적으로 sequence 를 생각해보면, glacier 로 이동할 파일 리스트를 S3 에 저장해두면 람다 서비스에서 해당 파일을 읽어와서 glacier 옮기는 명령 수행. 해당 작업 수행 후 결과를 슬랙으로 전송 하는 방식이면 좋을것 같아요.

[Chaewon14]

교수님 제 생각에는 아래의 시퀀스가 좋아보이는데 어떠실까요?

1. glacier 이동할 버킷 리스트 슬랙에 알림 + 5일 뒤 이동 예고
2. 5일동안 해당 버킷이 glacier로 이동하길 원하지 않으면 최근 엑세스 날짜 업데이트함으로써 변경사항有
3. glacier로 이동할 버킷 최종 리스트 슬랙에 알림 + 다음날 이동 예고
   (혹여 1번 알림을 못 봤을 수도 있으므로 한번 더 예고 알림 역할)
4. 다음날 최종최종 리스트를 또 업데이트해서 해당 버킷 리스트로 glacier 실제 이동 작업 진행
5. 이동 결과 슬랙에 전송

이렇게 하면 두 번의 예고와 두 번의 변경사항 업데이트가 이루어지게 됩니다.
그래서 이와 같은 시퀀스대로라면, S3에 버킷 리스트를 저장해서 람다로 불러오는 것보다는 마지막 실제 이동 작업을 진행하는 람다 함수에서 버킷 리스트를 한 번 더 업데이트해서 이동 작업을 진행하는 것이 더 좋을 것같다고 생각합니다.

[kmu-leeky]

네 채원학생. 새로운 계획 좋아보여요. 이렇게 해서 한번 만들어봅시다.

[Kim-Yul]

• S3 사용량 보고 알림 (매달 1일)
• Glacier 이동 예정 알림 (매 짝수달 1일) (5일 뒤 이동 예정 메시지 포함)
• 최종적으로 Glacier로 보내는 버킷 리스트 (매 짝수달 6일)

현재 S3 사용량을 보고 하는 람다 함수 작성 완료했습니다.
작성한 결과의 가독성이 굉장히 떨어져서 해당 부분만 보완하고, 곧이어 glacier 이동 예정 알림으로 작성할 예정입니다.

아래 결과물처럼 출력되어 정렬만 깔끔하게 하고 다음 작업을 진행할 예정입니다!
spotrank-figure 187.89 GB 2022-07-13
dl-converted-models 78.28 GB 2022-06-16
jg-inf-compiled-model 67.54 GB 2022-12-30
jg-twitter 62.47 GB 2023-03-22
ids-datamining 29.28 GB 2023-06-12
ayci 28.87 GB 2022-11-06
sagemaker-subean 7.24 GB 2022-05-24

[kmu-leeky]

오케이. 좋아요. 코드는 작성되는대로 같이 review 후에 반영해봅시다.

[Kim-Yul]

현재 결과물 출력까지 정리 완료하여 cloud-usage에 한 번 출력한 상황입니다.
seoul 리전에 usage-s3_bucket_list라는 이름으로 만들어 두었으며, 매월 1일 오전 10시마다 알림이 오도록 설정완료 해두었습니다.
review 이후 수정 사항 있으면 반영하겠습니다.

앞으로는 glacier로 이동 예정인 리스트를 보내는 lambda를 작성할 예정입니다.
glacier로 이동 예정인 목록에는 최근 액세스한 날짜를 찾을 수 없거나(N/A), 액세스한 지 6개월 이상이 넘은 버킷이 대상이 됩니다.

[Kim-Yul]

go_to_glacier-list lambda까지 완료되어 정리합니다.

작업 내용

1. s3 버킷 리스트

• seoul 리전에 usage-s3_bucket_list 라는 이름으로 만들어 두었으며, 매월 1일 오전 10시마다 알림이 오도록 설정되었습니다.

2. go to glacier 버킷 리스트

• seoul 리전에 usage-old_s3_bucket_list 라는 이름으로 만들어 두었으며, 짝수달 1일 오전 10시 5분마다 알림이 오도록 설정되었습니다.
• 6개월 이상되거나 최근 액세스한 날짜를 찾을 수 없는 s3 버킷이 대상이 되어 이동됩니다.
• 이 lambda는 이후 짝수달 6일 오전 10시에 다시 한 번 더 작동하여 실제로 이동될 리스트를 알림으로 보냅니다.

추후 작업

앞으로 진행할 작업은 짝수달마다 glacier에 옮겨지기로 예정된 버킷이 자동으로 glacier로 넘어갈 수 있도록 자동화하는 것입니다.
해당하는 리스트를 어떻게 옮길지에 대해서는 고민하고 있습니다.
우선 glacier로 넘기는 작업이 자동화가 되는 것에 맞추어 리스트 옮기는 방법에 대해 생각해볼 예정입니다.
glacier로 이동하는 예상 시간은 짝수달 6일 오전 10시 30분입니다.

현재까지 작업된 내용 review 부탁드립니다.

[kmu-leeky]

유림학생. 잘 진행하고 있네요. 코드의 경우 review 가능 하도록 pull request 를 만들어볼래요? 그래야 함께 코드 리뷰하기도 편할것 같아요.