Cloud Application 기본 개념

이 글은 2025년 학습 기록을 블로그 형식으로 정리한 백필 노트입니다.

1. 웹 애플리케이션 인프라 운영

(1) 서비스 플랫폼 및 아키텍처 유지보수

• 3-Tier 구조: DMZ / APP / DB 영역으로 VPC 분리
• API Gateway
  • 사외 서비스: DMZ VPC의 공인 IP + 도메인 접속
  • 사내/사외/모바일 서비스: API Gateway 통해 분기 처리

(2) Web & WAS 구성

• Web (정적 컨텐츠): Apache 서버 + VirtualHost 구성
• WAS (동적 컨텐츠): Wildfly 서버 + 세션 클러스터링 (Scale-out 가능)

(3) DB 구성

• DBaaS(EPAS): Active-Standby 이중화, Storage 수준 데이터 동기화
• 운영 안정성 및 무결성 확보

(4) 가용성/확장성

• VM 기반 Auto-Scaling
• L7 라우팅 & 부하 분산 기능 제공

---

2. AS-IS vs TO-BE 전환 (Monolith → MSA)

(1) AS-IS (기존 Monolith)

• Frontend & Backend 구분 없이 개발
• VM 환경 WebLogic 기반, JDK 7, JSP + Spring + Mybatis
• 세션 관리: 미들웨어 WebLogic Session Clustering
• 배치: VM Crontab + Java 배치 프로그램
• DB: Oracle 11g
• 문제점: 빌드·배포 시 전체 서비스에 영향, Scale 확장 시 시간 소요, DevOps 자동화 체계 부족

(2) TO-BE (MSA Cloud Native)

• Frontend/Backend 분리, Vue.js + Spring Boot/Cloud + JPA/Mybatis
• Containerization → Kubernetes 배포
• 세션 관리: Redis Cluster 사용
• 배치: K8S Cronjob/Job + Spring Batch 기반 On-demand 처리
• DB: Oracle 19c RAC (성능 향상)
• 요청 부하 제어: Spring Cloud Client-side Load Balancer
• 특징: 빠른 Scale-in/out, 빈번한 배포 가능, 모듈 단위 관리

---

3. 인프라 현대화 전환

• 기존 인프라: Virtual Server + WebLogic 10 + JDK 7
• 현대화 후:
  • Kubernetes (K8S)
  • API Gateway + Load Balancer
  • Web: Nginx
  • WAS: Embedded WebFlux, Tomcat
  • JDK 17
  • DevOps 기반 자동 빌드·배포 체계

---

4. 애플리케이션 현대화 전환

(1) 기존 방식

• WAR/JAR 다수 배포 → 전체 서비스 영향
• DevOps 기반 빌드·배포 시간 길음
• 작은 코드 수정에도 불편

(2) 전환 방식

• Frontend 별도 분리 (HTML, CSS, JS, Images)
• Backend → Spring Boot/Cloud 서비스 (MSA)
• Batch → Spring Boot/Batch + K8S Cronjob/Job
• 특징:
  • 서비스 단위로 독립적 빌드·배포
  • 빠른 Scale-in/out
  • 코드 수정 반영 용이

---