Jude_log

분산된 GGR 계산 기준을 통합하고 QA/운영에서 재사용 가능한 SQL 조회 구조를 설계 ⚠️ 문제 정의GGR 산출 기준 불명확 → 담당자별 계산 방식 상이복잡한 SQL로 조회/검증 비효율대용량 데이터 조회 성능 이슈🛠️ 수행 내용Poker GGR 산출 공식 정의 및 표준화목적별 SQL 조회 구조 설계 (전체 / GGR / 기본)조회 효율 개선 (쿼리 분리, 불필요 컬럼 제거)기간 필터 및 조회 조건 정리 (성능 고려)QA/운영 공통 활용 가능한 조회 가이드 문서화📊 쿼리 요약SELECT p.Id AS PlayerID, SUM( pgs.RakeOrFee + pgs.TicketRefundFee + pgs.CipGGR - pgs.Tour..

MySQL 2026. 3. 5. 18:35

분산된 플레이어 GGR/게임 지표를 통합하고 QA/운영에서 재사용 가능한 SQL 조회 구조를 설계⚠️ 문제 정의플레이어별 GGR 산출 기준 불명확 → 담당자별 계산 방식 상이모니터링으로 실시간 확인 가능한 쿼리 설계복잡한 SQL로 조회/검증 비효율대용량 데이터 조회 성능 저하🛠️ 수행 내용역할테이블 (가칭)조인방식설명기본 플레이어 정보alias1기준 테이블플레이어 ID, 이메일, 닉네임, 국가, 사이트, 소속 유형 등플레이어 소속/에이전트alias2LEFT JOIN각 플레이어의 Agent 코드 조회게임별 통계alias3LEFT JOINPoker GGR, Casino GGR, Reward, T/O 등 핵심 수익 지표최신 개인 정보alias4OUTER APPLY조건에 따라 최신 Tag / Code(가칭) ..

MySQL 2026. 3. 5. 18:34

자동화 검증과 이중 교차 검증(Cross-Check) 체계로 QA 실시간 데이터 정합성 확보 ⚠️ 문제 정의BS(Business Service) 데이터에서 Bonus Revenue가 일부 누락되어 있어 정확한 Service Fee 검증이 필요한 상황누락 데이터는 타팀에서 관리하고 있어 단순 조회만으로는 정합성 확인 불가 🛠️ 수행 내용Bonus Revenue 역산: 시스템 산정 Fee와 Rate를 활용해 누락 보너스 값을 계산정합성 검증:내부 데이터 ↔ 외부 Bonus Revenue 데이터 비교Redash 대시보드 구축:PASS/FAIL 지표 실시간 시각화Bonus Revenue 발생 건 집중 모니터링세션별 상세 추적 필터 제공Slack 자동 알림 연동:매일 10시, Bonus Revenue 발생 건..

MySQL 2026. 3. 5. 18:29

[Guide] Redash Slack(Bot) Alert Destination 설정 및 활용 가이드 핵심 요약: Slack Bot Token을 활용한 고도화된 알림 시스템 구축 (Block Kit & Thread 지원)1. 개요: Slack(Webhook) vs Slack(Bot)기존 Webhook 방식이 단일 채널에 단순 텍스트를 던지는 방식이었다면, **Slack(Bot)**은 대화형 UI 구성과 논리적 스레드 연결이 가능합니다.기능Slack(Webhook)Slack(Bot)인증 방식Webhook URL (단일 목적지)Bot Token (권한 기반)메시지 형식Attachments (구버전)Blocks (신버전/고급 UI)스레드(Thread)지원 불가자동 지원 (배열 형태 전송 시)인터랙티브제한적완전 ..

카테고리 없음 2026. 3. 5. 18:26

PR 라벨 기반으로 변경 내역을 자동 정리하고 버전까지 계산되는 구조로 전환⚠️ 문제 정의기존 릴리즈 관리 방식 (AS-IS) 목표 구조 (To-Be)변경 사항 수동 정리 → 시간 소모 + 누락 발생버전 관리 기준 불명확 → SemVer 일관성 부족릴리즈 노트 형식 제각각 → 가독성 낮음👉 릴리즈 과정이 사람 의존적이고 비효율적인 구조PR 라벨 기반 자동 분류SemVer 자동 계산릴리즈 노트 자동 생성 (Draft)👉 정리한다 → 자동으로 생성된다 ⚙️ Release Drafter 동작 구조Release Drafter는 특정 브랜치에 코드가 Merge될 때마다 배포될 내역을 'Draft' 상태로 미리 작성 핵심 메커니즘PR Merge 발생main 브랜치 반영Draft Release 자동 업데이트동작..

Git Action 2026. 3. 5. 18:17

목적 TA-Backend / TA-Frontend 레포지토리 기반으로 Test / Prod 환경을 분리 배포하기 위한 CI/CD 구조 설계기존 SSH 기반 배포 구조를 제거하고 GitHub Actions + Self-Hosted Runner 기반으로 서버 내부 실행형 배포 구조로 전환하는 것이 핵심⚠️ 문제 정의기존 구조 한계 (AS-IS) 목표 구조 (TO-BE) SSH 기반 배포→ 서버 접속 정보 관리 필요 (보안 리스크)외부에서 배포 실행→ 실제 서버 상태와 분리됨환경 분리 미흡→ Test / Prod 혼재 가능배포 트리거 기준 없음→ 수동 개입 발생👉 결론 보안 / 자동화 / 환경 분리 모두 불완전한 구조핵심 설계방향 서버를 GitHub Actions Runner로 등록브랜치 기준 배포 ..

Git Action 2026. 3. 5. 18:15

CI/CD 외 수동 배포가 필요한 상황을 대비해 표준 운영 프로세스를 정의⚠️ 문제 정의CI/CD 자동화가 적용되지 않거나 예외 상황 발생 시 수동 배포를 수행하는 과정에서버전(Tag) 누락으로 인한 배포 이력 추적 불가latest 이미지 overwrite로 인한 롤백 어려움DB Migration 적용 순서 오류로 인한 장애 발생release ↔ main 브랜치 미동기화로 코드 불일치→ 수동 배포에 대한 표준화된 프로세스 필요🚨 주요 리스크latest 이미지 overwrite → 이전 버전 복구 불가Tag 미생성 → 배포 버전 추적 불가DB Migration 순서 오류 → 서비스 장애release / main 불일치 → 운영/개발 코드 불일치1. 전체 작업 흐름도 (Overall Workflow)개발:..

Git Action 2026. 3. 5. 18:13

컨테이너 실행 상태가 아닌 실제 서비스 응답 기준으로 의존성을 제어하기 위해 Docker Healthcheck 기반 구조를 적용MySQL (healthcheck) ↓ Backend (service_healthy) ↓ Frontend (service_healthy) ↓ Nginx Proxy (최종 트래픽 수신)⚠️ 문제 정의 (As-Is)기존에는 depends_on을 통해 컨테이너 실행 순서만 제어MySQL 초기화 이전에 Backend가 연결 시도 → Connection Refused 발생Backend 부팅 이전에 Nginx 활성화 → 502 Bad Gateway 발생실행(started) 기준 의존성으로 인해 서비스 준비 상태 보장 불가🛠️ 개선..

카테고리 없음 2026. 3. 5. 18:12