SpotLake & Sandevistan 기능 추가 #479
Comments
|
유림아. 이 작업 잘 챙겨주길 바란다. frontend 작업은 @j-myeong 학생과 함께 수행하고. |
|
네 알겠습니다. 말씀해주신 부분 유념하여 작업 진행하겠습니다. |
|
|
지난 주 진행한 미팅 내용과 앞으로 작업할 내용에 대하여 정리하였습니다. 현재 백엔드에서 진행할 큼직한 작업은 MaxInstance 열 추가 및 Sandevistan 을 이용한 인스턴스 추천 탭 생성 입니다. MaxInstance 열 추가 작업기존 방식
진행 방식위 내용을 참고하여 앞으로 MaxInstance 열을 추가하기 위해 다음과 같이 작업을 진행할 예정입니다.
Sandevistan 작업
Azure SPS 열 추가정명님께 해당 내용 전달하였으며, SPS 값은 아직 정해지지 않았다는 등의 표시를 반영해두고, 실제로 SPS 값이 구해지면 수정하기로 진행하였습니다. 정리
추가로 생각해 볼 부분
|
|
미팅 이후 MaxInstance 값을 구하는 오버헤드를 고려하여 좀 더 간결하게 시나리오를 구상하였습니다. 다만 가능한 시나리오일지 오버헤드 확인이 필요해보입니다. 수정 시나리오 (TSDB 와 SQLite 활용)현재 SPS를 구하고 있는 collector 2개는 각각 수집한 데이터를 S3에 업로드 하고 있습니다.
실험적인 내용랜딩 화면에서 TSDB 에 기본값을 지정하여 쿼리를 보내면 얼마나 큰 오버헤드가 들 것인지 파악이 필요합니다. 생각하기에 이 오버헤드가 상당히 클 것으로 파악되지만, 실제로 어떤지 확인해보고자 합니다. 만약 오버헤드가 너무 크다면, 따로 랜딩 화면을 위한 json 파일을 업로드할 계획입니다. 이 부분은 TSDB 데이터와 새로운 람다 함수를 이용하여 업로드합니다. 수정된 내용에서 확인이 필요한 부분SQLite는 raw data가 버킷에 업로드 될 때마다 최신 값을 가지고 있기 때문에, 이를 이용하여 TSDB에 변경된 부분만 파악하여 업로드를 진행하고자 합니다. 따라서 기존 싱글노드 데이터를 수집하고 있는 사이트 도메인 분리Spotlake 와 Sandevistan 의 사이트는 분리하는 것이 좋을 것 같습니다. 그러나 TSDB 의 데이터는 공용으로 사용하는 것이 좋을 것 같은데, 분리하는 게 좋을지 의견 여쭈어봅니다. 정리수정 시나리오에서는 TSDB 와 SQLite 를 수정하여 Spotlake 와 Sandevistan 에 필요한 데이터 정제 작업을 진행할 예정입니다. 이후 TSDB 를 이용하여 사용자의 쿼리를 처리합니다. Sandevistan의 경우 TSDB에 데이터를 쿼리해서 가져온 후 안정성 계산하여 반환하는 것을 람다로 진행할 수 있을 것 같습니다. 저는 우선 TSDB에 랜딩 화면용 쿼리를 보냈을 때 오버헤드를 파악할 예정입니다. 위의 시나리오가 어떠신지 확인 부탁드립니다. |
|
위 내용 중 실험적인 내용을 진행해보았고, 보완할 필요가 있어서 수정 시나리오를 작성합니다. 랜딩 화면에서 TSDB에 기본값을 지정하여 쿼리를 보내는 것이 우선 2가지 이유로 어려울 것 같습니다. 따라서 시나리오 수정이 필요하고, 다음과 같은 시나리오를 생각해보았습니다. 위와 같은 작업을 진행해도 괜찮을까요? 우선 |
Sandevistan API 작업 환경 결정이전 이슈에서 Sandevistan 작업 환경은 아직 결정하지 못하였기에 전달해드리지 못하였지만, 로컬 환경에서 작업해보니 대략 21초 정도 소요되는 것 같아 1분이 넘는 긴 작업이 될 것 같지 않기에 구체적인 시나리오를 구상하지 않았지만, 쿼리 버튼을 누르면 사용자의 조건을 받아
위 과정의 소요 시간을 약식으로 확인하던 중 TSDB와 랜딩 화면의 데이터가 다르다는 것을 우연히 알게 되었습니다. 실제 작업을 진행할 때는 TSDB 내의 데이터를 이용할 예정이라 큰 문제가 되지 않을 것 같지만, 한 번쯤 검토하는 것이 좋을 것 같아 따로 이슈를 만들어 트래킹합니다. #481 또한 Sandevistan의 기존 코드가 앞으로 변경될 TSDB 쿼리를 이용한 로직에 최적화될 수 있도록 수정이 필요해보입니다. 이 내용은 다른 이슈에서 트래킹 진행하도록 하겠습니다. #482 참고사항
위 표는 가용영역이 많은 t 패밀리의 몇 개의 인스턴스를 추려 sandevistan 결과를 확인해 볼 때 소요된 시간 결과입니다. 쿼리의 경우 최대 길어도 10초 내였기에 여기서는 쿼리보다 sandevistan 작업 중에 소요되는 시간에 집중하여 확인해봅니다. 우선 안정성 스코어를 계산하는 것은 순차적으로 진행할 경우 모든 가용영역을 확인해보기 때문에 시간 소요가 제법 크게 나타납니다. 이 부분은 병렬 처리를 진행하여 시간을 단축할 예정입니다. 이외 비용과 가중치 계산의 경우 대부분 긴 시간이 소요되지 않기 때문에 무시할 수 있을 정도로 짧다고 생각하여 sandevistan의 기능을 구현하기 위해서는 안정성 스코어 계산을 병렬 처리하는 것에 신경을 써야 할 것 같습니다. |
TSDB 쿼리 응답시간 측정지난 미팅에서 TSDB의 쿼리가 상당히 오래걸린다는 이야기를 전해드렸는데, 이러한 이유에 대하여 간단하게 정리하여 전달드립니다. 우선 TSDB 에 직접 쿼리를 보내 응답시간을 측정해보았습니다.
기간 데이터 쿼리는 예를 들어 11월 1일부터 11월 3일까지를 3일치 데이터로 두고 확인해보았던 것이며, 기간 + 이전 데이터 쿼리는 11월 1일과 가까운 가장 빠른 날짜를 추가로 찾아 가져온 데이터를 의미합니다. 해당 데이터 값은 수집하고 있는 약 800개의 인스턴스 타입 중 극히 일부인 25개의 인스턴스만 이용하여 쿼리를 보내고 그 값을 통계로 낸 것입니다. 확인하다시피 쿼리문의 응답 시간 자체는 굉장히 짧습니다. 이전 미팅 때 8초 정도 걸렸던 것과는 전혀 다른데, 이는 데이터 쿼리를 가져오고 사용할 수 있게 전처리하는 과정의 시간이 포함되었던 것입니다. 초반에 API에서 진행하는 전처리를 이용하여 데이터를 가공하였기에 전처리 시간이 추가로 6 ~ 8초 정도 소요되었고, 이로 인해 최종적으로 8 ~ 10초 내의 쿼리 응답시간이 소요되었던 것이며, 이 내용을 미팅 때 전해드린 것이었습니다. 실제 쿼리 응답으로 오는 데이터의 일부는 다음과 같습니다. {'Data':
[
{'NullValue': True},
{'ScalarValue': '8.2944'},
{'ScalarValue': 'use2-az2'},
{'ScalarValue': 'us-east-2'},
{'ScalarValue': 'm6a.metal'},
{'ScalarValue': 'aws_values'},
{'ScalarValue': '2024-11-03 00:20:00.000000000'},
{'ScalarValue': '3.1'},
{'ScalarValue': '3'},
{'ScalarValue': '2.0'}
]
},이러한 Data가 쿼리에 해당된 행만큼 나오게 되며, 이를 for문으로 시퀀스하게 돌며 전처리를 진행하고 있었기 때문에 오랜 전처리 시간이 소요되었다고 생각합니다. 추가로 전달할 사항 |
저런 데이터가 얼마나 (몇개) 들어오길래, 8초씩 걸린다는 건가? 수치를 조금 더 자세히 적어주면 좋겠다. |
|
확인해보니 제가 사용한 인스턴스 타입이 위 전처리 과정에서 많은 오버헤드를 보이고 있어 8초라는 시간이 걸렸던 것 같습니다. 1일치 데일터
위 1일치 데이터를 확인하였을 때, 데이터의 전체 개수와 상관 없이 t4g 가 압도적으로 많은 전처리 시간을 소요하고 있었습니다. 그에 반해 1393개로 제가 선택한 인스턴스 타입에서 가장 많은 데이터 수를 쿼리해 가져왔을 때는 t4g에 비해 평이한 결과를 보여주었습니다. 이러한 점은 3일치 데이터와 7일치 데이터에서 두드러지며, 데이터 수와 관계 없이 갑자기 전처리 시간이 길게 소요될 때도 있었습니다. 3일치 데이터
7일치 데이터
코드를 살펴보았을 때는 모두 시퀀스하게 이루어지고 있기 때문에 저 역시 데이터 수와 연관되어 있다고 생각하였으나, 위의 결과를 보았을 때는 전혀 그렇지 않다는 것을 확인할 수 있었습니다. 제 생각에서는 특정 코드에서 t4g 같은 인스턴스 타입을 처리할 때 오래 걸리는 것이라고 추측되는데 이 부분에 대해서는 Spotlake API 코드를 자세하게 보며 내용 확인하여야 알 수 있을 것 같습니다. |
|
데이터 처리를 다양한 인스턴스 타입에서 해봤다는 건가? 그렇게 까지 할 필요는 없을것 같은데.. |
|
말씀해주셨던 대로 실제 데이터는 복잡하게 저장되어 있지 않기 때문에 전처리 코드에서 문제가 발생하는 것으로 추측됩니다. 결과의 원인을 파악하기 위해서는 전처리 과정을 따라가며 확인해보는 수밖에 없을 것 같습니다. 코드 분석하면서 원인을 파악해보겠습니다. |
|
전처리를 하는 목적이 뭐야? 세부적으로 어떻게 구현되어 있는지 보기 전에, 어떤 작업을 하는 전처리인지 알면 분석이 빠르지 않을까 해. |
|
Spotlake의 쿼리를 담당하는 API 에서 전처리를 진행하는 이유는 쿼리 응답으로 받아오는 데이터를 JSON 형식으로 변형하여 웹페이지에 띄우기 위해서입니다. 쿼리 응답으로 받아오는 데이터의 일부 {'Data':
[
{'NullValue': True},
{'ScalarValue': '8.2944'},
{'ScalarValue': 'use2-az2'},
{'ScalarValue': 'us-east-2'},
{'ScalarValue': 'm6a.metal'},
{'ScalarValue': 'aws_values'},
{'ScalarValue': '2024-11-03 00:20:00.000000000'},
{'ScalarValue': '3.1'},
{'ScalarValue': '3'},
{'ScalarValue': '2.0'}
]
},데이터 처리로 변환되는 JSON 형식 {
"id":"232",
"OndemandPrice":"13.2192",
"AZ":"1",
"Region":"sa-east-1",
"InstanceType":"m6a.metal",
"time":"2024-11-02 06:20:00",
"SpotPrice":"1.32",
"SPS":"3",
"IF":"2.0"
},측정한 전처리 시간은 쿼리 응답으로 받아오는 데이터의 일부를 JSON으로 처리하는 과정의 시간에 대하여 측정한 것입니다. 약식으로 확인했을 때는, 각 ScalarValue에 대하여 OndemandPrice나 AZ, Region 같은 값을 매칭하여 시퀀스하게 처리하는 작업이 진행되는 것 같았습니다.
이 부분에 대한 답변으로는 이전 값과 비교하였을 때, 변화가 없었기 때문에 TSDB에 반영되지 않았다고 할 수 있을 것 같습니다. 즉, 데이터의 개수가 적을 수록 데이터 값이 많이 변하지 않아 TSDB에 반영되지 않은 것입니다. |
|
저걸 변형하는데 저렇게 오랜 시간이 걸리는게 상식적으로 이해가 안되는데.. 추가적인 다른 쿼리가 들어가는건가. 유림이가 파악하기 어려우면 경환이가 옆에서 조금 도와주는게 좋겠다. |
|
위의 시간이 오래걸리는 원인에 대하여 파악하였습니다. 1일치 데이터
3일치 데이터
7일치 데이터
데이터 정정이전에 공유해드렸던 데이터 중 전처리 과정에서 오래 걸렸던 이유우선은 근본적으로 raw_data를 JSON으로 전처리하는 과정에서 든 오버헤드는 매우 작았습니다. 즉, 이전에 쿼리 응답으로 받아오는 데이터를 JSON으로 변환하는 데 들었던 소요 시간은 약 0.1초였습니다. 그래서 수 초의 시간을 들었던 부분을 찾아보고자 세부적으로 파악해보니, TSDB 응답 데이터인 Page Iterator를 읽기 위해서는 반드시 AWS와 네트워크 통신이 연결되어야 하고, 이로 인해 첫 연결은 반드시 네트워크 지연시간이 발생하여 오버헤드가 발생합니다. spotlake API 에서 쿼리문을 보내고 응답을 가져와 읽는 부분의 코드는 아래와 같습니다. page_iterator = paginator.paginate(QueryString=query_string)
for page in page_iterator:
_parse_query_result(page)코드를 설명하자면, 데이터 결과 분석위 데이터에서 데이터 개수가 적음에도 불구하고, 위 시간을 단축하기 위해서는 네트워크 지연시간을 줄이는 해결책을 찾아봐야 할 것 같습니다. 이 부분에 대해서는 조사한 후 다시 업데이트 하겠습니다. |
|
처음 Network connection 시간이 수초가 걸린다면 tsdb 쿼리 시간이 무조건 저렇게 오래 걸린다는 이야기인가? 그것도 이상한것 같은데.. 그냥 tsdb 에 바로 쿼리를 보내봤어? sql 사용해서. paginator 가 일반적인 쿼리 방식인지, 지금 데이터가 많아서 오래 걸리는지 등에 대해서 조금 더 자세한 분석이 필요하기는 하겠다. |
|
tsdb에 직접 쿼리를 보냈을 때, 처음 보낸 쿼리는 콜드스타트로 인해 7초 정도 걸리고, 바로 다시 보냈을 때는 2.8초 정도 걸렸습니다. 쿼리 방식에 대해서 찾아보았는데, boto3를 이용하여 tsdb의 데이터 가져오기 위해서는 paginator와 query 2가지 방법이 있는데, 실상은 같은 함수입니다. query 함수를 이용하면 paginator를 내부적으로 실행하기 때문에 데이터가 많아서 오래 걸린다고 하시는 말씀은 TSDB 자체에 저장되어 있는 데이터 양을 말씀하시는 것일까요? 아니면 데이터 쿼리할 때의 읽어봐야 하는 데이터 개수가 많은 것을 의미하실까요? 어떤 것을 말씀하시는 것인지 잘 모르겠습니다. |
|
tsdb 쿼리 시간이 원래 그렇게 오래 걸리는 건가. 일반적인 db 가 쿼리 보내는데 응답시간이 그렇게 길지는 않을텐데. 수십, 수백 밀리초 정도여야 하지 않을까 해서. 데이터가 많다는 건 둘다. 스캔해야 하는 데이터양이 많거나, 리턴되는 데이터 양이 많거나. |
|
tsdb 에 지금부터 15분전 time의 데이터를 time으로 정렬하여 10개의 데이터를 가져오려고 할 때, 처음 시도하면 약 5초였는데 계속 반복적으로 시도하니(5번 이상) 0.6초 정도로 줄어들었습니다. tsdb 자체에 콜드스타트가 있는 것이 아닐까 싶습니다. 이때 스캔한 데이터는 346개의 행이였습니다. |
|
성능이 막 좋지는 않네. 다들 이정도의 성능이 나오는지 한번 찾아보래? 깨끗한 데이터 베이스를 만들어서 실험해볼수도 있고, 다른 사람이 시간 측정한 결과 (아마도 기술 블로그?) 에서도 확인 가능할것 같아. |
|
쿼리에 2초-5초가 걸리는 가장 근본적인 원인은 아래 사진에서 나타납니다.
Memory에 데이터가 올라와 있는 시간은 단 12시간으로, 12시간 이전에 write된 모든 데이터는 메모리가 아니라 magnetic storage에 저장되어 있습니다. 때문에 Query 작업 시 magnetic storage에서 데이터를 가져오기 때문에 오랜 시간이 걸리는 것으로 판단됩니다. 추가로, 근본적으로 Timestream의 성능 자체가 좋지 않은 것 같습니다. 구글링해봤을 때, 쿼리에 0.3-1.0초가 걸린다는 레딧의 글을 하나 발견했습니다. https://www.reddit.com/r/aws/comments/125zrbo/timestream_query_speed/ 이런 사용자 경험과 더불어, 타 TimeseriesDB 회사들의 자체 비교 블로그 포스팅 글들이 여럿 있습니다. 먼저, 이전에 Jira에서 TimescaleDB에서 Timestream과의 성능 비교 블로그 포스팅을 공유드렸던 내용이 있습니다.
Timestream 비교 내용은 없지만, 위에서 이야기드린 TimescaleDB를 비교 대상으로 포함한 블로그 포스팅 역시 존재합니다. https://github.com/ddps-lab/research-issues/issues/50#issuecomment-1165220445
|
|
memory retention period 를 많이 줄여놨구나. 이 부분은 비용이 들어가는 부분이라 어쩔수 없기는 하다. |
현재 이슈에서 Sandevistan 기능 추가를 위해 작업 내용을 정리합니다.
싱글노드 페이지에 Max Instance 열 추가
아래 탭에 Max Instance를 추가하여 각 인스턴스 타입, 리전, az 별로 몇개의 인스턴스까지 안정적으로 가용 가능한지 max instance를 개수를 띄웁니다.
새로운 탭을 생성하여 Sandevistan 의 멀티 노드 안정성 데이터 추가
위의 탭에 멀티 노드 안정성을 확인할 수 있도록 Sandevistan 기능을 추가합니다.
이후 어떻게 작업할 것인지 정리 후 진행하겠습니다.
The text was updated successfully, but these errors were encountered: