Minutes of the 3rd M-CMP Workshop

[yunkon-kim]

M-CMP 제3차 워크샵 논의 사항들을 다음과 같이 정리하여 공유 드립니다.

누락되거나, 상이한 부분, 문의 사항 등이 있으신 경우 답글로 남겨주시고 논의를 진행하면 좋을 것 같습니다.

2024년도 연구 개발 대상

• 대상 CSP : AWS, GCP, NCP
• 대상 스토리지 : Object storage, RDB, NoSQL
  • 참고) CSP/DB/Storage targets and progress #41

주요 논의 사항

• Data Manager에서 DB/Storage 운영 및 관리 Feature를 제공함 (예, 신규 DB/Storage 생성, 등록 등)
  • InfraConnector/InfraManager에 의존적인 Feature임
    • 당분간, CSP API / Terraform / OpenTofu로 연구 개발 추진
    • 향후, CB추상화 API 전환 (예상 시점: 25년 상반기 정도)
  • 추상화 API를 통해 생성한 DB/Storage 또는 기보유 DB/Storage 등의 경우를 모두 고려 필요
    • 마이그레이션, 백업, 복구 모두 "클라우드-클라우드" 검증 환경임 (현 , 데이터 소스는 로컬시스템 활용)

향후 추진 업무

• 데이터 복구 백업(응용 구동중)의 정책 및 알고리즘 - ’25 년도 업무
  • 데이터 무결성 검증은 상기 업무 이후의 업무로 스케쥴링하는 것이 바람직
• 데이터 인프라 동적 성능 진단 기술 - 관련 기관간 협의

세부 참고 사항

• Terrafrom/OpenTofu를 활용해 DB/Storage 생성 및 제공하는 것으로 협의

  • 현재, 사전 설정 가이드로서 DB/Storage 생성 방법을 제공 중
    • 향후, InfraManager API를 활용하는 방향으로 대체 및 개선 예정
  • Terraform/OpenTofu 적용 계획 수립 필요: 제공 시기, API 개발 범위 등 (수립 후 공유 요망)
    • InfraManager 연동을 위해 TF configuration 개발 시 DB/Storage 관련 자원과 그 밖에 사전 준비 자원의 구분을 요청

• 실제 운영 중인 데이터의 Backup/Restore/Migration 하기 위한 메커니즘으로 개선 추진 협의

  • DB/Storage의 이중화 구조 및 상태 고려: 예) Active-active, Active-standby, 등
  • 백업, 복구, 마이그레이션별 중요도, 우선 순위 등을 고려하여 추진

• ApplicationManager와 mc-data-manager간 연계성 검토 필요

  • (Common Sense) 응용이 사용하는 데이터의 저장을 위한 스토리지 자원의 배포 및 데이터 관리
    • (Common Sense) App manager와 data manager 간 협력 아이템으로 정의
    • App manager는 Data manager가 제공하 API 활용하여 데이터 저장소 및 데이터 관리 기능을 개발
  • 쟁점 사항: 배포하는 App.과 연계되는 DB/Storage 정보 또는 API 제공 주체?
    • 주요 대상: mc-data-manager, InfraManager
    • 추후 재 논의 예정이며, 필요에 따라 스터디 PoC 등 수행
    • 재 논의 예상 일정: DB/Storage 관련 추상화 API 제공될 무렵

기타

(참고: 회의에서 다루지 못했던 사항입니다. 살펴봐 주시면 좋을 것 같습니다.)

• UI 일관성 측면: mc-data-manager UI와 M-CMP platform portal간 Look & feel 점검 필요
• API convention 및 활용성/직관성 측면: URL path, description, request/response body, 등의 점검 필요

[heedaeshin]

• Terrafrom/OpenTofu를 활용해 DB/Storage 생성 및 제공하는 것으로 협의
  • 현재, 사전 설정 가이드로서 DB/Storage 생성 방법을 제공 중
    • 향후, InfraManager API를 활용하는 방향으로 대체 및 개선 예정

---

해당 내용 아래와 같이 진행하는 것인지 확인 부탁 드립니다.

• 데모 때 진행하였던 수동 리소스 생성 방식은 Terrafrom/OpenTofu으로 일괄 생성 ( 동적 파라미터 생성 X )

[yunkon-kim]

@heedaeshin

곤란한 방향으로 결정이 된 것 같습니다;; 프로젝트 계획 상 반영되어야 하는 부분으로 보입니다. 별도로 메일 드리겠습니다.

[heedaeshin]

@yunkon-kim
회의 중에 해당 사항 보고 드렸습니다. 동적 파라미터만 들어가지 않는다면,
정적 문서 기준 PUT, DELETE API는 진행하기로 변경되었습니다.
확인하시고, 확정 내용 메일 보내주시면 감사하겠습니다.

[yunkon-kim]

@heedaeshin

결정되었으니 의견 공유 및 의사 결정을 위해 별도로 메일을 보낼 필요는 없을 것 같습니다. 빠르게 결정해 주셔서 감사합니다.

(별도로, 앞으로의 서비스 운용/관리 목표를 생각한다면, PUT 대신 POST 를 적용하시면 어떨까요?)

[heedaeshin]

@yunkon-kim post를 사용하신다는건
파라미터를 받아서 provider, region이나 bucket을 동적으로 정의해서 리소스 생성하는 내용인지 확인 부탁드립니다.

[yunkon-kim]

@heedaeshin

버킷을 동적으로 생성하는 것을 말씀드리는 사항은 아닙니다. 설계상 고려해 봐주십사 의견을 드린 부분입니다.