Azure SPS 정보 제공을 위한 실제 운영 환경 통합

[ty-kim7]

https://github.com/ddps-lab/research-issues/issues/657 이슈 관련 추가 개발되어 수집되고 Azure SPS를 Front에 반영하기 전 사전 작업 필요

필요 작업

• (초기 랜딩) s3://spotlake/latest_data/latest_azure.json file에 정보 추가,
• (쿼리 데이터) spotlake-timestream-query 람다 함수 내 쿼리문 수정 (https://github.com/ddps-lab/spotlake-query 최신화 필요)

[krtaiyang]

Azure SPS 정보 제공 Task:

• 신규 query_selector / upload_timestream / submit_batch_sps 개발 (CW로그 스트림, timestream table 모두 테스트 인스턴스를 생성 했음)
• 데이터 비교 func 'compare_sps' 개발 (SPS 관련 신규 데이터 추가)
• spotlake-timestream-query 람다 함수 내 쿼리문 수정
• FE 코드 수정 및 로컬 테스트

[krtaiyang]

개발중 기록 필요한 이슈:

1. AWS timestream 테이블에 데이터 업로드 시, 일부 컬럼 예를 들어 IF, PRICE등 정보는 double 형식임, 기존 결측치 처리는 '-1'로 설정 한 이슈도 double 형식 때문이었습니다.
2. AWS Cloudwatch put_log API 중 logEvents 변수 요구는, list형식내, dict로 전송 필요합니다.

예시:
[{
        'timestamp': int(now.timestamp()) * 1000,
        'message': f'message-aaa'
}]

3. if dataframe(pandas)는 비지원 합니다. 공백 df 판단 시는 아래 처럼 코딩 추천합니다.if dataframeis not None and not dataframe.empty:

[kmu-leeky]

태양아. 이게 어떤 상황인지 모르겠는데, 문제가 있고 해결책이 있다는 거야?
그렇다면 새로운 이슈를 만들어서 CR 을 만들어서 머지를 하는게 좋을것 같아.

그리고 이 문제가 전에 모니터링 채널에서 에러 왔던 내용과 같은건가? 그건 아닌것 같기도 하고.

요즘에 미팅을 많이 못했는데, 현재 상황을 조금 정리해줄래? 필요하면 줌 미팅을 한번하자.
당분간 연구실은 온라인 모드로 진행 될듯 하나.

[krtaiyang]

태양아. 이게 어떤 상황인지 모르겠는데, 문제가 있고 해결책이 있다는 거야?
그렇다면 새로운 이슈를 만들어서 CR 을 만들어서 머지를 하는게 좋을것 같아.
그리고 이 문제가 전에 모니터링 채널에서 에러 왔던 내용과 같은건가? 그건 아닌것 같기도 하고.

해당 문제들은 모두 본 이슈 "Azure SPS 정보 제공을 위한 실제 운영 환경 통합"를 개발하는 중에 로컬 테스트에서 발생했던 이슈들이고, 해결뒤 위 글을 남겼습니다.
일전 slack통해 보낸 알람 관련 이슈들 이지만, 기존 코드의 이슈가 아닌 신규 개발에 발생된 이슈라, 공유에 좀 애매하였습니다, 지금 개발한 본 이슈 신규 기능 모두 테스트 완료후 PR를 만들어 review를 요청하려고 했었습니다.

요즘에 미팅을 많이 못했는데, 현재 상황을 조금 정리해줄래? 필요하면 줌 미팅을 한번하자.
당분간 연구실은 온라인 모드로 진행 될듯 하나.

네엡, 현재 상황을 우선 정리하고 공유드리겠습니다. 필요 시 줌 미팅도 가능합니다. 토요일에 한국 들어가고, 한 기간 동안 조카를 챙겨야하니 당분간 온라인 모드 진행도 가능합니다.

[krtaiyang]

최근 정리 내용:
1.기존 Azure 수집 모듈을 중단하지 않고 정보 충돌을 방지하며, 기존 모듈의 구조를 학습하고 원활하게 활용하기 위해, query_selector / upload_timestream / submit_batch 등의 기존 모듈을 직접 수정하는 대신, 신규 메서드를 생성하여 개발하고 있습니다. 또한, 사용된 AWS 서비스에도 별도의 테스트 환경을 구축하여 개발을 진행 중입니다.

2.최근 개발 상황을 공유드리자면, 진행 중인 내용은 본 Task를 참고하시면 됩니다.
#522 (comment)

고민:
기존 Azure 수집 모듈은 1시간에 1번 수집이고, 신규 SPS 정보 수집은 10분에 1번 수집중이라,
timestream의 갱신도 10분에 1번으로 모든 수집된 정보를 업로드 예정입니다.
(timestream의 작용은 spotlake에서 query할때 기존 정보를 조회할때 이용합니다.)

신규 timestream 업로드에는 새로운 컬럼과 해당 정보가 추가됩니다. 기존 데이터는 SPS 정보가 없습니다.

CASE 1:
신규 데이터를 기존 테이블에 직접 보낸다. 그럼 기존 1시간에 1번 timestream 업로드 로직은 중지함. 10분에 한 번 업로드로 변경.
CASE 2:
새로운 테이블을 만들어 수집. 그럼 기존 1시간에 1번 업로드는 잠시 유지, 10분에 한 번 업로드하고, spotlake는 신규 테이이블을 쿼리로 변경.

혹시 해당 부분대해 충돌과 호환을 참고하여 신규 업로드 작업을 어떻게 진행해야 하는 것에 대해 추천한 방안 있으실까요?

@ty-kmu 님 @합니당.

[kmu-leeky]

오케이. SPS 데이터 수집은 잘 되고 있는것으로 판단되고.
이제 SpotLake 시스템에서 보여주기 위한 작업을하고 있는 것으로 판단된다.

그렇게 하기 위해서는 Timestream DB 에 SPS 데이터의 업데이트가 필요한데, 주기에 관련된 고민인것으로 보인다.

만약에 10분에 한번씩 업데이트를 한다면 1번 케이스가 맞을것 같아. 굳이 시스템을 복잡하게 할 필요는 없을것 같아.

그런데 그 전에 우리가 azure 데이터셋도 제법 오랫동안 다운로드 하고 있고, 다운 받은 데이터도 많으니 이걸 분석해서 매 10분마다 의미있는 데이터 변화가 있는지를 먼저 살펴보자.

https://leeky.me/publications/spot-interrupt-visible.pdf

논문에서 그림 4를 보면 데이터가 변하는 주기를 보여주거든. 전반적으로 azure 와 gcp 의 경우 그렇게 자주 변하지는 않거든.
그래서 실제로 10분에 한번씩 수집해도 의미있는 변화가 없을수도 있겠다는 생각이 든다.

지금까지 다운로드 받은 전체 데이터를 가지고 다양한 시나리오에서 다중 노드 SPS 값이 얼마나 자주 변하는지 한번 봐볼까?
이건 research-issues 리포에서 새로운 이슈를 하나 만들어서 하면 좋겠다. 이건 @ty-kmu 이가 메인으로 해서 진행해보면 좋겠다.

[ty-kim7]

네 교수님, https://github.com/ddps-lab/research-issues/issues/690 에서 해당 부분 진행해보겠습니다.

@krtaiyang 저도 기존 데이터와의 연속성과 운영 환경 구성부분에서 1번 케이스가 더 좋다고 생각합니다.
구현의 경우 기존 Azure의 데이터가 수집되고 있는 spotlake db의 azure 테이블에 삽입되게 구성하시면 될 것같습니다. Timestream의 경우 별도의 Alter Table 구문 없이 새로운 컬럼 데이터를 포함해 Insert 하면 자동으로 해당 시점부터 컬럼이 생성되어 저장 되기 때문에 충돌 이슈는 없을 것 같습니다. (테스트는 spotlake-test db에서 진행)

[krtaiyang]

https://github.com/ddps-lab/spotlake-query/pull/15
spotlake-timestream-query 람다 함수 내 쿼리문 수정 PR입니다.