Quartz 4

네이버 검색광고 데이터 수집 시스템 마이그레이션

5 min read

네이버 검색광고 데이터 수집 시스템 마이그레이션

프로젝트 개요

Apps Script 기반 모놀리식 시스템을 GCP 마이크로서비스로 마이그레이션하는 학습 프로젝트

현재 시스템 (As-Is)

아키텍처

Google Sheets (Config + Data Storage)
    ↓
Google Apps Script (수집 + 처리 + 저장)
    ↓
정적 웹사이트 (데이터 표시)

기술 스택

  • 데이터 저장: Google Sheets
  • 백엔드 로직: Google Apps Script
  • API 연동: 네이버 키워드도구 API + DataLab API
  • 프론트엔드: 정적 웹사이트

수집 데이터

  1. 네이버 키워드도구 API

    • PC/모바일 검색량
    • 평균 클릭수 (PC/모바일)
    • 평균 CTR (PC/모바일)
    • 광고 개수, 경쟁도

  2. 네이버 DataLab API

    • 월별 검색 트렌드
    • 연령별 검색 비중

현재 코드 구조

// 설정 관리
var accessKey = s.getRange('B2').getValue();
var secretKey = s.getRange('B3').getValue();
var CUSTOMER_ID = s.getRange('B4').getValue().toString();
 
// 키워드 데이터 수집
function nkey(req) {
  // HMAC 서명 생성
  // 네이버 키워드도구 API 호출
  // 검색량, 클릭수, CTR, 경쟁도 반환
}
 
// 트렌드 데이터 수집
function ntrend(Req) {
  // DataLab API 호출
  // 월별 검색 트렌드 반환
}
 
// 연령별 데이터 수집
function nAgeTrend(Req) {
  // DataLab API 호출
  // 연령별 검색 비중 반환
}

문제점 분석

1. 확장성 문제

  • 스프레드시트 행/열 제한
  • 대용량 데이터 처리 어려움
  • 동시 사용자 처리 제한

2. 실시간성 부족

  • 수동 데이터 갱신
  • 배치 처리 방식
  • 사용자 요청 시 즉시 응답 불가

3. 유지보수성

  • 비즈니스 로직과 데이터가 혼재
  • 버전 관리 어려움
  • 에러 처리 및 로깅 부족

4. 사용자 경험

  • 정적 웹사이트 → 상호작용 제한
  • 실시간 필터링/정렬 불가
  • 개인화 기능 없음

목표 시스템 (To-Be)

아키텍처

Frontend (React/Vue) → API Gateway → Cloud Run Services
                                   ├── Data Collection Service
                                   ├── Data Processing Service
                                   └── Web API Service
                                            ↓
                                   Cloud Firestore

마이크로서비스 분리

  1. Data Collection Service: API 호출 및 데이터 수집
  2. Data Processing Service: 데이터 변환 및 분석
  3. Web API Service: REST API 제공
  4. Frontend Service: 사용자 인터페이스

마이그레이션 전략

Phase 1: Strangler Fig Pattern

  • 기존 Apps Script 유지
  • 신규 기능만 GCP로 구현
  • 점진적 트래픽 이전

Phase 2: 마이크로서비스 분해

  • 기능별 서비스 분리
  • 독립적 배포 가능
  • 서비스 간 API 통신

Phase 3: 완전 마이그레이션

  • 기존 시스템 단계적 제거
  • 모니터링 및 로깅 강화
  • 성능 최적화

기술 스택 비교

구분As-IsTo-Be
데이터 저장Google SheetsCloud Firestore
백엔드Apps ScriptCloud Run (Node.js/Python)
스케줄링수동/트리거Cloud Scheduler + Cloud Functions
API단일 스크립트RESTful API
프론트엔드정적 웹React/Vue (Firebase Hosting)
모니터링없음Cloud Monitoring

예상 비용 (GCP 무료 티어)

  • Cloud Functions: 200만 호출/월
  • Cloud Run: 180만 vCPU-초/월
  • Firestore: 50K 읽기, 20K 쓰기/일
  • Firebase Hosting: 10GB 저장, 360MB/일 전송

다음 단계

  1. GCP 프로젝트 설정
  2. Cloud Functions 기반 데이터 수집 서비스 구현
  3. Firestore 데이터 모델 설계
  4. 기본 웹 API 서비스 구현
  5. 프론트엔드 프로토타입 개발

작성일: 2025-11-08
프로젝트: 클라우드 아키텍처 학습 및 실습

그래프 뷰