https://github.com/ONE0x393/sb-blue-front-demo

https://github.com/dongmin0204/softbank_final_fe

https://softbank-final-fe.vercel.app/

AWS Infrastructure

Knative로 확인할 수 있는 기본 메트릭

<aside>

1. 대시보드(모니터링)에 표시할 매트릭 구조 정리

🔹 함수(Function) 단위 매트릭

• 총 요청 수 (Total Requests)
• 성공률 (Success Rate)
  • 성공 횟수
  • 실패 횟수
• 앱 처리 시간 (Latency)
• 큐 관련 매트릭
  • 큐 깊이 (Queue Depth)
  • 큐에 추가된 작업 수
  • 큐 대기 시간
  • 작업 처리 시간
  • 재시도 횟수
• 리소스/오토스케일링 메트릭
  • 현재 파드 수
  • 목표 파드 수
  • 생성 중인 파드 수
  • 목표 동시성(Target Concurrency)
  • 평균 동시성(Stable)
  • 순간 동시성(Panic)
  • 패닉 모드 여부(0/1)
  • 초과 용량(Excess Capacity)

🔹 시스템 단위 매트릭

• 일단 Grafana 기본 대시보드 사용
• 향후 커스텀 대시보드로 대체 예정

</aside>

<aside>

2. 테넌트(Tenant) / 인증 / URL 정책

🔹 Tenant 설계

• tenant는 UUID 기반이 유력

  → “간지 + 충돌 없음”으로 UUID 선호

• 각 유저가 만든 함수는 해당 유저만 실행 가능하게 할지?

  → 인증키(Access Key) 방식 사용 예정 (❓ 어떤 인증 방식? API Key? JWT? IAM-like?)

🔹 버추얼호스트 구조

1. 전체 Knative 도메인

<https://runna.haifu.cloud>

1. 함수 그룹(서브도메인)

<https://process-image.runna.haifu.cloud/{custom-path}>

1. 함수 단위 endpoint

<https://process-image.runna.haifu.cloud/api/img>

🔹 네임스페이스 구조

• namespace = tenant_id + function_id
• function_id = UUID
• function_name은 별칭으로 사용

</aside>

<aside>

3. Knative + API Server 패턴

현재 구조

모든 함수 실행 요청은 무조건 API 서버 → Knative로 전달됨

(참고: 11/30 Meeting 문서)

논의 결과

• API 서버의 역할 = 함수 생성/배포/삭제(Deploy lifecycle)

• 실제 함수 실행 요청은 API 서버를 거치지 않고 Knative URL로 직접 보내게 하는 방향 가능

  → Knative가 함수 활성화(URL 발급) → Pod 한 대 Standby

  → 유저가 해당 URL 직접 호출

예시

• Lambda(URL) + API Gateway(URL/list, /health)와 유사한 패턴
• health check는 pre-defined image에서 지원 가능 </aside>

<aside>

4. Redis Queue 관련 논의

현재 요청 흐름

User Request
   ↓ (curl)
Redis Queue
   ↓
Knative Serving

논의 포인트

• Redis Queue를 어디에 둘 것인가?

  → API 서버 앞단? Knative 앞단? 별도 Worker? (❓ 정리 필요)

• Redis가 단순 큐(비동기)인지, rate limit 용인지 목적 명확화 필요 (❓)

• 서버리스 함수 실행을 백엔드에서 받을 것인지, k8s-run 노드에서 받을 것인지 정의가 필요!! </aside>

<aside>

5. 함수 관리 로직 정리

• 함수 Save → DB에 함수 메타정보 저장
• 함수 Deploy
• 함수 Delete

(❓ 함수 버전관리할지? 삭제 정책 확정 필요)

</aside>

<aside>

</aside>