Re: task app 시스템 분석 > 클라우드네이티브

1. task app 시스템 분석

  1.1 클라우드 네이티브 핵심 원칙

• 컨테이너 기반(Containerized) : 모든 구성 요소가 컨테이너로 분리되어 배포·롤백·확장 편의성을 확보함.
• 마이크로서비스 구조(Microservices) : 기능 단위로 서비스가 독립 구성되어 개별 운영·개별 배포가 가능함.
• 자동화 환경(Automated DevOps) : Docker·Compose 기반 자동화를 통해 동일 환경 재현이 가능함.
• 느슨한 결합(Loose Coupling) : 서비스 간 의존성을 최소화하여 변경·확장·장애 격리가 용이함.

  1.2 시스템 구성 요소

• myfront: index.html / app.js 제공.
• mytaskapi(PHP): 태스크 목록 JSON 반환.
• myuserapi(FastAPI): 로그인·세션 처리.
• myredis: 세션 저장소 (username, useremail).
• mysql: 사용자·태스크 데이터 저장.
• myproxy: 요청 라우팅 및 도메인 연결.
• Docker Host: 모든 컨테이너 통합 실행.

  1.3 데이터 흐름

• 사용자가 gctask.com 접속 → myproxy → myfront → index.html, app.js 로드됨.
• app.js가 /task/tasks-list.php 요청을 보냄.
• myproxy가 요청을 mytaskapi로 전달함.
• mytaskapi가 Redis에 세션 정보(username, useremail)를 조회함.
  • 세션이 존재하면 → MySQL에서 해당 사용자 태스크 리스트를 조회함 → JSON 반환.
  • 세션이 존재하지 않으면 → 로그인 페이지(/login.html) 경로로 리다이렉트됨.
• 로그인 페이지에서 사용자가 email, password 입력 → /user/login으로 POST 요청됨.
• myuserapi가 MySQL에서 사용자 인증 → 성공 시 Redis에 세션 생성(setSession).

 
  1.4 시스템 특징

• 서비스 간 책임이 명확히 분리됨.
• 컨테이너 단위 배포로 관리가 간단함.
• Redis 세션 구조로 Stateless 운영 가능.
• proxy 중심의 단일 진입점 구조.

2. 클라우드 네이티브 구조 요소 분석

  2.1 서비스 단위 분리 구조를 갖춤

• 프론트엔드, 인증 API, 태스크 API, 세션 저장, 데이터 저장, 라우팅이 기능별로 완전히 분리됨.
• 각 서비스는 개별 배포·개별 확장이 가능하여 마이크로서비스 구조 원칙을 충족함.

  2.2 컨테이너 기반 운영 구조를 갖춤

• 모든 서비스는 Docker 컨테이너로 구성되어 동일한 실행 환경이 유지됨.
• 이미지 기반 운영 방식을 사용하여 이전 버전으로의 롤백을 즉시 수행함.
  • 문제 발생 시 이전 버전 이미지로 복구 가능.

• 컨테이너 복제 기반 수평 확장이 가능함
  • 동일 서비스를 여러 개 실행하여 API 처리량을 확장함.

• 서비스 신규 배포 시 초기화(run) 절차를 단순하게 수행함
  • 신규 버전을 즉시 교체 실행함.
  • 컨테이너 상태가 확인되면 기존 컨테이너를 중지함.

• Proxy가 여러 컨테이너로 트래픽을 분산하기 때문에 확장·축소 시에도 서비스 가용성이 유지됨.

  2.3 Stateless Core 설계를 갖춤

• 애플리케이션 서버는 Stateless 구조로 운영됨.
  • mytaskapi, myuserapi에서 직접 Session을 생성하지 않음.
• 세션 데이터는 Redis에 저장됨.
• 계정·태스크 데이터는 MySQL에 저장됨.
• Stateless 구조는 확장성·안정성·복구 속도를 보장하는 클라우드 네이티브 핵심 설계 방식임.

  2.4 독립 배포 및 경량 운영 구조를 갖춤.

• FastAPI, PHP API, Front는 변경 시 해당 서비스만 재배포됨.
• 운영 부담이 낮고 유지보수 효율이 높은 경량 구조가 형성됨.

3. Kubernetes(K8s) 적용성 분석

  3.1 소규모 환경에서 K8s 도입은 부적합

• 단일 서버 또는 소규모 운영 환경에서는 초기 설정 복잡도가 과도함.
• YAML 구성·컨트롤러 관리 등 운영 비용이 높음.
• 자원 소모가 커서 경량 운영 목표와 충돌함.
• Docker Compose 기반 구조로도 자동화·운영 요구사항이 충분히 충족됨.

  3.2 대규모 환경에서 K8s 도입은 적합

• 대규모 트래픽 환경에서 오토스케일링을 통한 자동 확장이 필요함.
• 롤링 업데이트를 통한 무중단 배포가 요구됨.
• 장애 자동 복구 기능이 필요함.
• 다중 노드 기반 서비스 운영 시 Kubernetes가 높은 운영 효율을 제공함.

4. 클라우드 네이티브 MSA로 평가되는 근거

  4.1 구조적 근거를 갖춤

• 기능 단위 완전 분리 구조가 적용됨.
• Docker 기반 배포 표준화를 갖춤.
• Stateless API + Redis 세션 저장 구조가 확보됨.
• Proxy 기반 서비스 게이트웨이 구성이 적용됨.
• 서비스별 독립 운영·독립 배포가 가능함.

  4.2 운영적 근거를 갖춤

• 로컬·운영 환경 간 동일 실행 환경이 유지됨.
• 모놀리식이 아닌 완전 분리형 서비스 조합이 구성됨.
• 소규모 환경에서 최적의 경량 클라우드 네이티브 아키텍처가 형성됨.

5. 운영 및 확장 관점 분석

  5.1 서비스 간 책임 분리가 명확함

• 각 서비스가 수행하는 책임 범위가 독립적이며 중복되지 않음.
  • myfront는 정적 자원 제공, myuserapi는 인증, mytaskapi는 업무 처리, myredis는 세션 저장 등
• 역할이 완전히 분리되어 기능 충돌이 없음.

  5.2 네트워크 계층 구조가 직관적으로 구성됨

• myproxy가 진입점 역할을 수행하여 외부 트래픽을 일원화함.
• 각 API 서비스로 안전하게 라우팅되는 구조가 형성됨.
• 이는 서비스 구성 변경 시 진입점이 변경되지 않아 운영 안정성이 확보됨.

  5.3 장애 격리 특성이 우수함

• 특정 서비스(myuserapi 또는 mytaskapi) 장애 발생 시 다른 서비스로 영향이 전파되지 않음.
• 컨테이너가 독립된 프로세스로 동작하므로 장애 복구가 빠르게 이루어짐.

  5.4 로그 및 모니터링 체계 확장이 용이함

• 모든 서비스가 별도 컨테이너로 구성되어 있음.
• 서비스별 로그 수집·모니터링 구성이 용이함.
• 향후 Prometheus·Grafana·Elastic Stack 연동 시 구조 변화가 거의 필요 없음.
  • 운영·모니터링·로그 분석을 위한 오픈소스 툴체인

  5.5 CI/CD 파이프라인 연결이 단순함

•  컨테이너 이미지 빌드 → 이미지 태그 발행 → 서버 pull → 재배포
•  단 3단계로 자동화가 가능함.
•  GitHub Actions·GitLab CI·Jenkins 등 어떤 CI/CD와도 바로 연결됨.

  5.6 개발 환경과 운영 환경의 완전 일치가 가능함

• 개발자가 로컬에서 docker compose up으로 실행하는 환경과 서버에서 운영 중인 환경이 이미지 단위로 동일함.
• “개발 환경에서는 되는데 서버에서 안 된다.” 문제가 구조적으로 감소함.

  5.7 서비스 확장 로드맵이 명확함

• 현재 구조를 기반으로 다음 확장이 자연스럽게 가능함.
  • API 서비스 수평 확장. 
  • myproxy를 로드밸런서로 확장.  
  • Redis 클러스터링 적용.  
  • MySQL Replication 확장.  
  • K8s로의 전환 시 서비스 단위 그대로 이전 가능.  
• 구조 자체가 장기 확장성을 내재하고 있음을 의미함.

6. 결론

• 본 시스템은 클라우드 네이티브 핵심 원칙을 충족한 Docker 기반 마이크로서비스 구조를 갖춤.
• 본 시스템은 경량 서비스부터 중규모 서비스까지 안정적으로 운영 가능.
• 구조적 완성도·확장성·운영 편의성 측면에서 일관된 품질을 확보함.
• 소규모 환경에서는 Compose 기반 운영이 적합하며, 대규모 확장 시 Kubernetes 도입이 유효함.
  • 트래픽 증가 또는 팀 규모 확장 시 Kubernetes 기반 자동화 구조로 자연스럽게 전환 가능한 아키텍처 구조를 갖춤.