shared-dg05-coffeeQuokka/hgzero

Fork 0

mirror of https://github.com/hwanny1128/HGZero.git synced 2025-12-06 13:46:24 +00:00

ondal b98db59c7c 논리아키텍처설계

2025-10-21 13:33:34 +09:00

24 KiB

Raw Blame History

논리 아키텍처 설계서

1. 개요

1.1 목적

회의록 작성 및 공유 개선 서비스의 논리 아키텍처를 정의하고, 마이크로서비스 간 통신 전략과 클라우드 디자인 패턴 적용 방안을 제시합니다.

1.2 설계 원칙

1.2.1 마이크로서비스 설계 원칙

서비스 독립성: 각 서비스는 독립적으로 배포 가능하며, 서비스 간 직접 의존성 최소화
단일 책임: 각 서비스는 명확한 비즈니스 책임을 가지며, 하나의 도메인 영역에 집중
느슨한 결합: 이벤트 기반 통신을 통한 서비스 간 결합도 최소화
캐시 우선: Redis를 통한 성능 최적화 및 서비스 간 데이터 공유 최소화

1.2.2 통신 전략

동기 통신: 즉시 응답이 필요한 단순 조회 (REST API)
비동기 통신: 장시간 작업 및 이벤트 기반 통신 (RabbitMQ)
캐시 우선: 자주 사용되는 데이터는 Redis 캐시에서 직접 읽기
API Gateway: 모든 클라이언트 요청의 단일 진입점

1.2.3 클라우드 디자인 패턴 적용

API Gateway: 라우팅, 인증, Rate Limiting
Queue-Based Load Leveling: 부하 분산 및 비동기 처리
Cache-Aside: 성능 최적화 및 DB 부하 감소
Publisher-Subscriber: 이벤트 기반 통신
Asynchronous Request-Reply: 장시간 작업 비동기 처리
Health Endpoint Monitoring: 서비스 상태 모니터링

1.3 핵심 컴포넌트

1.3.1 클라이언트 레이어

Web Application: 브라우저 기반 SPA (Single Page Application)
Mobile Application: iOS/Android 네이티브 앱 (향후 확장)

1.3.2 API Gateway

Kong Gateway 또는 Spring Cloud Gateway
역할: 라우팅, 인증/인가, Rate Limiting, 로깅

1.3.3 백엔드 서비스 (8개)

User Service: 사용자 인증 및 권한 관리
Meeting Service: 회의 관리, 회의록 생성 및 관리, 회의록 공유
STT Service: 음성 녹음 관리, 음성-텍스트 변환, 화자 식별
AI Service: LLM 기반 회의록 자동 작성, Todo 자동 추출, 프롬프팅 기반 회의록 개선
RAG Service: 맥락 기반 용어 설명, 관련 문서 검색 및 연결, 업무 이력 통합
Collaboration Service: 실시간 동기화, 버전 관리, 충돌 해결
Todo Service: Todo 할당 및 관리, 진행 상황 추적, 회의록 실시간 연동
Notification Service: 알림 발송 및 리마인더 관리

1.3.4 인프라 컴포넌트

PostgreSQL: 각 서비스별 독립 데이터베이스
Redis: 분산 캐시 및 세션 관리
RabbitMQ: 메시지 큐 및 이벤트 버스
Azure Storage: 음성 파일 저장
Azure Speech API: STT(Speech-to-Text) 엔진
LLM API: AI 회의록 자동 작성 엔진

2. 서비스 아키텍처

2.1 서비스별 책임

2.1.1 User Service

책임: 사용자 인증 및 권한 관리

LDAP 연동 인증
JWT 토큰 발급 및 검증
사용자 프로필 관리
권한 관리

데이터:

사용자 정보 (user_db)
세션 정보 (Redis 캐시)

외부 의존성:

LDAP 서버

2.1.2 Meeting Service

책임: 회의 관리, 회의록 생성 및 관리, 회의록 공유

회의 예약 및 참석자 초대
회의 템플릿 관리
회의 시작/종료 관리
회의록 조회 및 수정
회의록 공유 설정
회의 통계 생성

데이터:

회의 정보 (meeting_db)
회의 템플릿 정보
회의록 메타데이터
회의 참석자 정보

주요 이벤트:

발행: MeetingCreated, MeetingStarted, MeetingEnded, MeetingCancelled
구독: TranscriptCreated, TodoCompleted

통신 전략:

동기: User Service (사용자 정보 조회 - Redis 캐시 우선)
비동기: STT Service (회의록 생성 요청 - Queue), Notification Service (알림 발송 - Event)

2.1.3 STT Service

책임: 음성 녹음 관리, 음성-텍스트 변환, 화자 식별

음성 녹음 시작/중지
음성 파일 Azure Storage 저장
Azure Speech API 연동 STT 처리
화자 자동 식별
텍스트 변환 결과 저장

데이터:

음성 파일 메타데이터 (transcript_db)
텍스트 변환 결과

외부 의존성:

Azure Speech API (STT 엔진)
Azure Storage (음성 파일 저장)

주요 이벤트:

구독: MeetingEnded
통신: AI Service (회의록 자동 작성 요청 - Queue)

2.1.4 AI Service

책임: LLM 기반 회의록 자동 작성, Todo 자동 추출, 프롬프팅 기반 회의록 개선

회의록 자동 작성 (구조화, 문장 다듬기, 요약)
Todo 자동 추출 및 담당자 식별
프롬프팅 기반 회의록 개선 (1Page 요약, 핵심 요약 등)
관련 회의록 자동 연결 (벡터 유사도 검색)

데이터:

AI 처리 이력 (ai_db)
비동기 작업 상태 (Redis)

외부 의존성:

LLM API (OpenAI, Azure OpenAI 등)

주요 이벤트:

구독: TranscriptCreated
통신: Todo Service (Todo 할당 요청 - Queue), RAG Service (관련 문서 검색 - 동기)

비동기 작업:

AI 일정 생성 (Asynchronous Request-Reply 패턴 적용)
AI 회의록 요약 생성

2.1.5 RAG Service

책임: 맥락 기반 용어 설명, 관련 문서 검색 및 연결, 업무 이력 통합

전문용어 자동 감지
벡터 유사도 검색을 통한 관련 문서 검색
과거 회의록 및 사내 문서에서 맥락 기반 설명 생성
용어 사전 관리

데이터:

벡터 DB (관련 문서 임베딩)
용어 사전 (rag_db)

외부 의존성:

사내 문서 저장소 (위키, 매뉴얼 등)

통신 전략:

동기: AI Service (관련 문서 검색 요청 시)

2.1.6 Collaboration Service

책임: 실시간 동기화, 버전 관리, 충돌 해결

회의록 실시간 수정 동기화 (WebSocket)
회의록 버전 관리
동시 수정 충돌 감지 및 해결
회의록 섹션 검증 완료 처리

데이터:

회의록 버전 정보 (collaboration_db)
수정 이력

주요 이벤트:

발행: TranscriptUpdated, SectionVerified

통신 전략:

WebSocket: 실시간 동기화 (클라이언트 ↔ Collaboration Service)
비동기: Notification Service (검증 완료 알림 - Event)

2.1.7 Todo Service

책임: Todo 할당 및 관리, 진행 상황 추적, 회의록 실시간 연동

Todo 생성 및 할당
Todo 진행 상황 추적
Todo 완료 처리
회의록과 Todo 실시간 양방향 연동
캘린더 연동

데이터:

Todo 정보 (todo_db)
Todo 진행 상황

주요 이벤트:

발행: TodoCreated, TodoStatusChanged, TodoCompleted
구독: MeetingEnded (AI Service를 통한 Todo 자동 추출)

통신 전략:

동기: Meeting Service (회의록 Todo 섹션 업데이트 - REST API)
비동기: Notification Service (Todo 알림 - Event)

2.1.8 Notification Service

책임: 알림 발송 및 리마인더 관리

이메일 알림 발송
SMS 알림 발송 (선택)
리마인더 관리 (회의 시작 30분 전, Todo 마감일 3일 전 등)
알림 발송 큐 처리

데이터:

알림 발송 이력 (notification_db)

외부 의존성:

SMTP 서버 (이메일)
SMS 서비스 (선택)

주요 이벤트:

구독: MeetingCreated, MeetingEnded, TranscriptCreated, TodoCreated, TodoCompleted, SectionVerified

2.2 서비스 간 통신 전략

2.2.1 동기 통신 (REST API)

사용 시나리오: 즉시 응답이 필요한 조회 작업

요청 서비스	대상 서비스	목적	캐시 전략
Meeting Service	User Service	사용자 정보 조회	Redis 캐시 우선 (TTL: 30분)
Todo Service	Meeting Service	회의록 Todo 섹션 업데이트	즉시 반영
AI Service	RAG Service	관련 문서 검색	캐시 없음 (검색 결과는 매번 변경 가능)

특징:

Cache-Aside 패턴 적용 (User 정보, Meeting 정보 등)
API Gateway를 통한 라우팅 및 인증

2.2.2 비동기 통신 (Message Queue)

사용 시나리오: 장시간 작업 또는 즉시 응답 불필요

발행 서비스	큐 이름	구독 서비스	목적
Meeting Service	transcript.creation.queue	STT Service	회의록 생성 요청
STT Service	ai.processing.queue	AI Service	회의록 자동 작성 요청
AI Service	todo.extraction.queue	Todo Service	Todo 추출 및 할당
모든 서비스	notification.queue	Notification Service	알림 발송 요청

특징:

Queue-Based Load Leveling 패턴 적용
Consumer Concurrency 조정으로 부하 분산
Dead Letter Queue를 통한 실패 메시지 관리

2.2.3 이벤트 기반 통신 (Pub-Sub)

사용 시나리오: 하나의 이벤트를 여러 서비스가 구독

이벤트	발행 서비스	구독 서비스	목적
MeetingCreated	Meeting Service	Notification Service, AI Service	회의 생성 알림, AI 분석 준비
MeetingEnded	Meeting Service	STT Service, Notification Service, Todo Service	회의록 생성, 종료 알림, Todo 추출
TranscriptCreated	STT Service	Notification Service, Meeting Service, AI Service	회의록 생성 완료 알림, 상태 업데이트, AI 분석
TodoCreated	Todo Service	Notification Service	Todo 할당 알림
TodoCompleted	Todo Service	Notification Service, Meeting Service	Todo 완료 알림, 회의록 업데이트
SectionVerified	Collaboration Service	Notification Service	검증 완료 알림

특징:

Publisher-Subscriber 패턴 적용
RabbitMQ Topic Exchange 사용
서비스 간 느슨한 결합

2.2.4 비동기 작업 처리 (Asynchronous Request-Reply)

사용 시나리오: 장시간 실행되는 작업 (1분 이상)

서비스	작업	예상 시간	상태 저장
AI Service	AI 일정 생성	30초 ~ 2분	Redis (taskId 기반)
AI Service	AI 회의록 요약 생성	1분 ~ 5분	Redis (taskId 기반)
STT Service	음성 파일 STT 변환	1분 ~ 10분	Redis (taskId 기반)

처리 플로우:

클라이언트 → API Gateway → 서비스: 작업 요청
서비스: taskId 생성 → Redis 상태 저장 (PENDING) → Queue 발행
서비스 → 클라이언트: 202 Accepted + taskId 즉시 반환
Worker: Queue 소비 → 상태 업데이트 (PROCESSING) → 작업 처리 → 상태 업데이트 (COMPLETED)
클라이언트: GET /tasks/{taskId}로 상태 폴링 또는 WebSocket Push

특징:

Asynchronous Request-Reply 패턴 적용
Redis를 통한 작업 상태 관리 (TTL: 24시간)
폴링 또는 WebSocket을 통한 결과 조회

2.2.5 실시간 통신 (WebSocket)

사용 시나리오: 실시간 협업 및 즉시 알림

사용 케이스	서비스	클라이언트
회의록 실시간 동기화	Collaboration Service	Frontend
AI 작업 완료 Push (옵션)	AI Service	Frontend

특징:

WebSocket 기반 양방향 통신
수정 델타만 전송하여 네트워크 효율 최적화
충돌 감지 및 해결 (Last Write Wins 또는 수동 병합)

3. 주요 사용자 플로우

3.1 회의 생성 및 예약 플로우

1. 사용자 → Frontend: 회의 예약 정보 입력
2. Frontend → API Gateway → Meeting Service: POST /api/meetings
3. Meeting Service:
   - 회의 정보 저장 (meeting_db)
   - MeetingCreated 이벤트 발행
4. Notification Service (구독):
   - 참석자에게 초대 이메일 발송
   - 캘린더 일정 등록
5. AI Service (구독):
   - 회의 일정 분석 준비 (비동기)
6. Frontend ← Meeting Service: 회의 정보 반환

적용 패턴:

API Gateway: 라우팅 및 인증
Publisher-Subscriber: MeetingCreated 이벤트
Queue-Based Load Leveling: 알림 발송 큐

3.2 회의 진행 및 회의록 생성 플로우

1. 사용자 → Frontend: 회의 시작 버튼 클릭
2. Frontend → API Gateway → Meeting Service: POST /api/meetings/{id}/start
3. Meeting Service:
   - 회의 상태 '진행중'으로 업데이트
   - 회의 세션 생성
   - MeetingStarted 이벤트 발행
4. STT Service:
   - 음성 녹음 시작
   - 실시간 STT 처리 (Azure Speech API)
   - 텍스트 변환 결과 저장
5. AI Service:
   - 텍스트 변환 결과 수신
   - 실시간 회의록 자동 작성 (구조화, 문장 다듬기)
6. Collaboration Service:
   - 회의록 실시간 동기화 (WebSocket)
   - 참석자 화면에 실시간 반영
7. 사용자 → Frontend: 회의 종료 버튼 클릭
8. Frontend → API Gateway → Meeting Service: POST /api/meetings/{id}/end
9. Meeting Service:
   - 회의 상태 '종료'로 업데이트
   - 회의 통계 생성
   - MeetingEnded 이벤트 발행
10. STT Service (구독):
    - 음성 녹음 중지
    - 음성 파일 Azure Storage 저장
11. Notification Service (구독):
    - 참석자에게 회의 종료 알림
12. Todo Service (구독):
    - AI Service를 통한 Todo 자동 추출 요청 (비동기)

적용 패턴:

API Gateway: 라우팅 및 인증
Publisher-Subscriber: MeetingStarted, MeetingEnded 이벤트
Queue-Based Load Leveling: Todo 추출 큐
WebSocket: 실시간 회의록 동기화

3.3 AI 기반 Todo 자동 추출 및 할당 플로우

1. Todo Service (MeetingEnded 이벤트 구독):
   - AI Service에 Todo 추출 요청 (Queue)
2. AI Service Worker:
   - 회의록 텍스트 분석
   - Todo 항목 추출 (LLM API)
   - 담당자 자동 식별
   - Todo 정보 생성
3. AI Service → Todo Service:
   - Todo 정보 전달 (Queue)
4. Todo Service:
   - Todo 생성 및 저장 (todo_db)
   - TodoCreated 이벤트 발행
   - 회의록 Todo 섹션 업데이트 (Meeting Service REST API 호출)
5. Notification Service (구독):
   - 담당자에게 Todo 할당 알림 (이메일)
   - 마감일 3일 전 리마인더 일정 생성
6. Meeting Service:
   - 회의록 Todo 섹션 업데이트
   - Redis 캐시 무효화

적용 패턴:

Publisher-Subscriber: MeetingEnded, TodoCreated 이벤트
Queue-Based Load Leveling: AI 처리 큐, Todo 할당 큐
Cache-Aside: 회의록 캐시 무효화

3.4 맥락 기반 용어 설명 플로우

1. Frontend: 회의록 작성 중 전문용어 감지 (클라이언트 측)
2. Frontend → API Gateway → RAG Service: POST /api/rag/terms/explain
3. RAG Service:
   - 용어 사전 확인
   - 벡터 유사도 검색 (과거 회의록, 사내 문서)
   - 관련 문서 추출 (최대 5개)
   - LLM을 통한 맥락 기반 설명 생성
4. RAG Service → Frontend:
   - 용어 정의
   - 맥락 기반 상세 설명
   - 실제 사용 사례
   - 관련 프로젝트/이슈
   - 과거 회의록 링크 (최대 3개)
5. Frontend:
   - 툴팁 또는 사이드 패널로 설명 표시

적용 패턴:

API Gateway: 라우팅 및 인증
Cache-Aside: 용어 사전 캐싱

3.5 AI 일정 생성 (비동기 작업) 플로우

1. Frontend → API Gateway → AI Service: POST /api/ai/schedules
2. AI Service:
   - taskId 생성 (UUID)
   - Redis 상태 저장 (PENDING)
   - Queue에 작업 메시지 발행
   - 202 Accepted + taskId 즉시 반환
3. AI Worker (비동기):
   - Queue 소비
   - Redis 상태 업데이트 (PROCESSING)
   - LLM API 호출하여 일정 생성 (1분 소요)
   - Redis 상태 업데이트 (COMPLETED) + 결과 저장
4. Frontend (폴링):
   - GET /api/ai/tasks/{taskId}를 5초마다 호출
   - status가 COMPLETED일 때 결과 획득

적용 패턴:

Asynchronous Request-Reply: 비동기 작업 처리
Queue-Based Load Leveling: AI 처리 큐
Redis: 작업 상태 관리

3.6 회의록 실시간 협업 플로우

1. 참석자 A → Frontend: 회의록 수정
2. Frontend → Collaboration Service (WebSocket): 수정 델타 전송
3. Collaboration Service:
   - 수정 권한 확인
   - 수정 이력 저장 (collaboration_db)
   - 버전 관리
   - 충돌 감지 (동일 위치 동시 수정 시)
4. Collaboration Service → 모든 참석자 (WebSocket):
   - 수정 델타 실시간 브로드캐스트
   - 수정 영역 하이라이트 (3초간)
5. 참석자 B, C Frontend:
   - 실시간으로 수정 내용 반영
6. 충돌 발생 시:
   - Last Write Wins (기본) 또는 수동 병합 UI 제공

적용 패턴:

WebSocket: 실시간 양방향 통신
Queue-Based Load Leveling: 알림 발송 큐 (수정 알림)

3.7 회의록 검증 완료 플로우

1. 참석자 → Frontend: 섹션 검증 완료 버튼 클릭
2. Frontend → API Gateway → Collaboration Service: POST /api/collaboration/sections/{id}/verify
3. Collaboration Service:
   - 검증자 정보 기록
   - 검증 상태 업데이트 (검증 완료)
   - 회의 생성자만 섹션 잠금 가능 (선택)
   - SectionVerified 이벤트 발행
4. Notification Service (구독):
   - 전체 참석자에게 검증 완료 알림 (이메일)
5. Collaboration Service → Frontend (WebSocket):
   - 검증 완료 상태 실시간 동기화
   - 검증 배지 표시 (체크 아이콘)

적용 패턴:

Publisher-Subscriber: SectionVerified 이벤트
WebSocket: 실시간 상태 동기화
Queue-Based Load Leveling: 알림 발송 큐

4. 데이터 흐름 및 캐싱 전략

4.1 데이터베이스 구성

서비스별 독립 데이터베이스: 각 서비스마다 독립적인 PostgreSQL 데이터베이스
서비스 간 데이터 공유 최소화: 캐시 또는 이벤트를 통한 데이터 공유

서비스	데이터베이스	주요 테이블
User Service	user_db	users, roles, permissions
Meeting Service	meeting_db	meetings, templates, participants, transcripts_metadata
STT Service	transcript_db	audio_files, stt_results, speakers
AI Service	ai_db	ai_tasks, ai_results, related_transcripts
RAG Service	rag_db	terms_dictionary, document_embeddings
Collaboration Service	collaboration_db	transcript_versions, edit_history, conflicts
Todo Service	todo_db	todos, todo_status_history
Notification Service	notification_db	notifications, notification_templates

4.2 캐싱 전략 (Cache-Aside 패턴)

4.2.1 캐싱 대상 데이터

서비스	캐시 데이터	TTL	무효화 트리거
User Service	사용자 프로필 정보	30분	사용자 정보 업데이트
User Service	사용자 권한 정보	1시간	권한 변경
Meeting Service	회의 기본 정보	10분	회의 정보 수정
Meeting Service	회의 참여자 목록	10분	참여자 변경
Meeting Service	회의 템플릿 목록	1시간	템플릿 생성/수정
STT Service	회의록 조회	30분	회의록 수정
Todo Service	사용자별 Todo 목록	5분	Todo 상태 변경
Todo Service	Todo 진행 상태 통계	5분	Todo 완료

4.2.2 캐시 정책

읽기 집중 데이터 (Cache-Aside):

패턴: Lazy Loading
전략: 캐시 미스 시 DB 조회 → 캐시 저장
예: 사용자 프로필, 회의 정보 조회

쓰기 빈도 높은 데이터 (Write-Through + Cache-Aside):

패턴: 업데이트 시 캐시 무효화
전략: DB 업데이트 → 캐시 삭제 → 다음 조회 시 재생성
예: Todo 상태 변경, 회의 정보 수정

캐시 무효화:

데이터 변경 시 즉시 무효화 (Cache Eviction)
TTL 기반 자동 만료
명시적 삭제 API 제공 (관리자용)

4.3 비동기 작업 상태 관리 (Redis)

작업 상태 저장:

Key: task:{taskId}
Value: { taskId, status, createdAt, startedAt, completedAt, result, errorMessage }
TTL: 24시간

상태 흐름:

PENDING: 요청 접수 직후
PROCESSING: Worker가 작업 시작
COMPLETED: 작업 성공 완료
FAILED: 작업 실패

5. 확장성 및 성능 고려사항

5.1 수평 확장 전략

5.1.1 Stateless 서비스 설계

모든 백엔드 서비스는 Stateless: 세션 정보는 Redis에 저장
수평 확장 가능: Kubernetes 기반 Pod Auto Scaling
Load Balancer: Kubernetes Service (ClusterIP)를 통한 부하 분산

5.1.2 서비스별 확장 전략

서비스	확장 전략	Auto Scaling 기준
API Gateway	수평 확장 (최소 2개)	CPU > 70% 또는 RPS > 1000
User Service	수평 확장	CPU > 70%
Meeting Service	수평 확장	CPU > 70% 또는 메모리 > 80%
STT Service	수평 확장 + Worker 증설	Queue 길이 > 100
AI Service	수평 확장 + Worker 증설	Queue 길이 > 50
Notification Service	수평 확장 + Worker 증설	Queue 길이 > 200
Todo Service	수평 확장	CPU > 70%
Collaboration Service	수평 확장 (WebSocket)	동시 연결 > 500

5.2 성능 최적화

5.2.1 캐싱 최적화

Cache Hit Rate 목표: 70% 이상
Hot Key 문제 대응: 자주 조회되는 데이터는 로컬 캐시 + 분산 캐시 병행
Cache Stampede 방지: Singleflight 패턴 적용 (동시 다발적 Cache Miss 방지)

5.2.2 데이터베이스 최적화

Connection Pool: HikariCP 설정 최적화 (maxPoolSize: 10-20)
인덱스 최적화: 자주 조회되는 필드에 인덱스 생성
Read Replica: 읽기 부하 분산 (필요 시)

5.2.3 메시지 큐 최적화

Consumer Concurrency: 서비스별 동시 처리 워커 수 조정 (3-10)
Prefetch Count: RabbitMQ Prefetch 설정 최적화
Dead Letter Queue: 실패 메시지 별도 처리

5.3 성능 목표

지표	목표
API 응답 시간 (P95)	< 500ms
회의록 생성 시간	< 2분
AI 일정 생성 시간	< 1분
Cache Hit Rate	> 70%
시스템 가용성	> 99.5%
동시 사용자 수	10,000명
동시 진행 회의 수	1,000개
일일 처리 회의 수	100,000개

6. 보안 고려사항

6.1 인증 및 인가

6.1.1 인증 전략

LDAP 연동: 사내 LDAP 서버와 연동한 사용자 인증
JWT 토큰: 인증 후 JWT 토큰 발급 (만료 시간: 1시간)
Refresh Token: 장기 세션 유지 (만료 시간: 7일)
Token 검증: API Gateway에서 JWT 토큰 검증 (모든 요청)

6.1.2 인가 전략

역할 기반 접근 제어 (RBAC): 사용자 역할에 따른 권한 관리
회의 참여자 검증: 회의 참여자만 회의록 접근 가능
회의록 작성자 권한: 수정, 삭제 권한은 작성자에게만 부여

6.2 데이터 보안

6.2.1 암호화

전송 중 암호화: HTTPS/TLS (API Gateway)
저장 시 암호화: PostgreSQL Transparent Data Encryption (TDE)
민감 정보 암호화: 사용자 비밀번호는 bcrypt 해싱

6.2.2 데이터 접근 제어

데이터베이스 접근: 서비스별 독립 계정, 최소 권한 원칙
Redis 접근: Password 인증 + ACL 설정
RabbitMQ 접근: 서비스별 독립 계정, 큐별 권한 관리

6.3 보안 모니터링

6.3.1 로깅

API Gateway: 모든 요청/응답 로깅 (사용자 ID, 엔드포인트, 응답 시간)
인증 실패 로깅: 반복적인 인증 실패 시 경고
민감 정보 마스킹: 로그에서 비밀번호, 토큰 등 마스킹

6.3.2 보안 이벤트 모니터링

이상 접근 탐지: 짧은 시간 내 과도한 요청 (Rate Limiting)
권한 없는 접근 시도: 403 Forbidden 응답 모니터링
보안 패치: 정기적인 보안 업데이트 및 취약점 점검

7. 논리 아키텍처 다이어그램

논리 아키텍처 다이어그램은 별도 파일로 작성되었습니다.

파일: logical-architecture.mmd

온라인 확인: https://mermaid.live/edit

8. 문서 이력

버전	작성일	작성자	변경 내용
1.0	2025-01-20	준호	초안 작성

24 KiB Raw Blame History

논리 아키텍처 설계서

1. 개요

1.1 목적

1.2 설계 원칙

1.2.1 마이크로서비스 설계 원칙

1.2.2 통신 전략

1.2.3 클라우드 디자인 패턴 적용

1.3 핵심 컴포넌트

1.3.1 클라이언트 레이어

1.3.2 API Gateway

1.3.3 백엔드 서비스 (8개)

1.3.4 인프라 컴포넌트

2. 서비스 아키텍처

2.1 서비스별 책임

2.1.1 User Service

2.1.2 Meeting Service

2.1.3 STT Service

2.1.4 AI Service

2.1.5 RAG Service

2.1.6 Collaboration Service

2.1.7 Todo Service

2.1.8 Notification Service

2.2 서비스 간 통신 전략

2.2.1 동기 통신 (REST API)

2.2.2 비동기 통신 (Message Queue)

2.2.3 이벤트 기반 통신 (Pub-Sub)

2.2.4 비동기 작업 처리 (Asynchronous Request-Reply)

2.2.5 실시간 통신 (WebSocket)

3. 주요 사용자 플로우

3.1 회의 생성 및 예약 플로우

3.2 회의 진행 및 회의록 생성 플로우

3.3 AI 기반 Todo 자동 추출 및 할당 플로우

3.4 맥락 기반 용어 설명 플로우

3.5 AI 일정 생성 (비동기 작업) 플로우

3.6 회의록 실시간 협업 플로우

3.7 회의록 검증 완료 플로우

4. 데이터 흐름 및 캐싱 전략

4.1 데이터베이스 구성

4.2 캐싱 전략 (Cache-Aside 패턴)

4.2.1 캐싱 대상 데이터

4.2.2 캐시 정책

4.3 비동기 작업 상태 관리 (Redis)

5. 확장성 및 성능 고려사항

5.1 수평 확장 전략

5.1.1 Stateless 서비스 설계

5.1.2 서비스별 확장 전략

5.2 성능 최적화

5.2.1 캐싱 최적화

5.2.2 데이터베이스 최적화

5.2.3 메시지 큐 최적화

5.3 성능 목표

6. 보안 고려사항

6.1 인증 및 인가

6.1.1 인증 전략

6.1.2 인가 전략

6.2 데이터 보안

6.2.1 암호화

6.2.2 데이터 접근 제어

6.3 보안 모니터링

6.3.1 로깅

6.3.2 보안 이벤트 모니터링

7. 논리 아키텍처 다이어그램

8. 문서 이력

24 KiB

Raw Blame History