이번에 Next.js 프론트를 ECS Fargate + ALB 구조로 배포하면서 이상한 현상을 겪었다.컨테이너는 분명히 살아있는데 ECS는 계속 태스크를 죽이고 다시 올렸다. 증상 ECS 서비스 이벤트 로그task ... port 3000 is unhealthy in target-group ... reason: Health checks failed Amazon ECS replaced 1 tasks due to an unhealthy status. 그리고 무한 반복.태스크 → 실행됨Target group → UnhealthyECS → 태스크 교체다시 Unhealthy또 교체무한 루프 1차 의심: 컨테이너 문제?ECS Exec으로 직접 들어가서 확인했다. 200/ health /api/health 전부 ..

[ Internet ] | v[ Route53 ] | v[ ALB ] ← (여기에 WAF를 "나중에" 붙일 예정) | v[ ECS Fargate ] | v[ Spring Boot App ] 이번 글에서는 특정 기능 구현 이야기가 아니라,Spring Boot 기반 API 서버를 SaaS 구조로 설계하고 AWS 상에 배포하면서 고민했던 아키텍처 포인트를 정리해보려 한다.단순히 애플리케이션을 배포하는 것을 넘어, 멀티테넌시 구조, 무중단 배포 전략, 헬스체크 설계, 네트워크 경계 설정, 관찰성까지 고려한 “운영 가능한 구조”를 목표로 설계했다. (트래픽 분산처리는 하지 않음.)EC2 vs ECS 초기에는 EC2에 직접 배포할지, ECS를 사용할지 고민..

문제 배경SpeakNote를 GCP 환경에서 운영하던 중,GCP Billing 리포트에서 Network egress 비용이 비정상적으로 급증한 것을 확인했다.트래픽이 갑자기 폭증한 것도 아니고,기능을 대규모로 추가한 시점도 아니었기 때문에 단순 사용량 증가로 보기에는 이상한 상황이었다.조사를 진행하면서 egress 비용 증가의 원인은 하나가 아니라 여러 개라는 것을 알게 되었다.Docker 이미지 빌드 시 캐시 없이 반복 빌드되던 문제외부 AI API 연동 구조그리고 GCP 네트워크 아키텍처 자체의 문제이 글에서는아직 해결 중인 빌드/코드 레벨 이슈는 제외하고, GCP 아키텍처 재배포로 실제 비용을 줄인 과정만 정리한다. 초기 상황: “같은 서버끼리 통신하는데 왜 egress가 나가지?”SpeakNot..

SpeakNote 프로젝트의 고도화 기간 중, 기존에는 로컬로만 테스트를 돌렸었는데아무래도 운영 환경에서의 테스트도 중요할 거 같아 배포를 미리 해두기로 마음을 먹었다.다만, 1월 24일경 시작을 했는데 크레딧의 반절을 써버림.. (뭔가 단단히 잘못됨..) 한번도 이랬던 적이 없어서 우선 인스턴스를 중지 시킴. (고정 ip 와 디스크로 몇천원 결제되는게 더 나을 듯해서...) 우선 요금이 폭등하게 된 원인부터 찾으려 함. Google cloud 의 billing -> 보고서를 클릭 오잉??그룹화 기준을 날짜 > SKU 로 변경 (1월 29일날 인스턴스 중지를 시켰습니다. 나온 974는 아마도 고정 ip와 디스크 값이겠죵?)뭔지 정확히 확인하기 위해 csv 다운로드를 클릭합니다. (27일만 많이 나온..

SSH 키 등록했는데 로컬에서 접속이 안 됐던 문제 (해결까지 한 번에 정리)Compute Engine 인스턴스를 생성하면서초기 설정 화면에서 SSH 공개키를 분명히 등록했습니다.하지만 인스턴스 생성 이후, 로컬 터미널에서 다음과 같이 접속을 시도했을 때ssh user@SSH 접속이 정상적으로 이루어지지 않았습니다.즉,VM 생성 단계에서 SSH 키를 넣었음GCP 콘솔에서는 인스턴스가 정상적으로 떠 있음그런데 로컬 터미널에서는 SSH 접속 실패라는 상황이었습니다.당시 문제 상황 정리이 시점에서 확인했던 사항은 다음과 같습니다.VM에는 외부 IP가 정상적으로 할당되어 있었고방화벽에서도 22번 포트는 열려 있는 상태였으며SSH 키 자체도 로컬에 정상적으로 존재했습니다즉, 네트워크나 포트 문제라기보다는 SSH ..

Compute Engine 생성부터 전역 Load Balancer 연결까지본 글은 SpeakNote 서비스를 GCP 환경에 배포하면서Compute Engine 생성 → SSH 접속 → 서비스 실행 → Load Balancer 선택 및 설정 → 도메인 연결까지의 과정을 순서대로 기록한 글입니다.설계 배경보다는 실제로 어떤 설정을 했는지를 중심으로 정리합니다. 나중에 운영 서버는 AWS 에서 진행할 거지만,, (Upstage 와 제휴업체인걸로 알고있어서!)AWS 는 현재 start up 신청 대기 중이기 때문에, 개발 단계는 GCP 로 진행을 하려 합니다. GCP 계정 설정처음 가입하면 , First Project 라고 뜨는걸로 알고있는데, 우선 저는 프로젝트별 관리를 편안히 하기 위해 새프로젝트를 만들었..

환경 일관성과 데이터 관리의 용이성 때문에 온프레미스로 구현되고 있는 서비스의 서버에 database 를 Docker 를 이용하여 배포하고 운영하고 있습니다. 해당 Postgres 의 컴포즈 파일을 설정하다가, 계속적인 부팅 이슈가 발생하길래 그것을 수정하여 개선해보려 합니다. postgres: image: ${POSTGRES_IMAGE:-postgres:15} container_name: ${POSTGRES_SERVICE_NAME:-postgres} env_file: .env.postgres ports: - "${POSTGRES_PORT:-5432}:5432" volumes: - ${ROOT_HOST}/postgres-data:/var/lib/postg..

이번 작업에서는 Spring → FastAPI → OCR Server 구조에서 파일을 직접 전달하지 않고 공유 스토리지(NFS) 를 통해 처리하도록 아키텍처를 변경했습니다. 기존에는 FastAPI에서 파일을 /tmp에 다시 저장한 뒤 OCR 서버로 넘기는 구조였는데, 서버가 분리되고 트래픽이 늘어나면서 중복 I/O, 디스크 낭비, 관리 복잡도 문제가 커졌기에 결론적으로 서버 간 공유 마운트(NFS) 를 적용했고, 그 과정에서 발생한 실제 에러와 해결 과정을 정리하려 합니다. 파일은 Spring에서 한 번만 저장FastAPI / OCR Server는 경로만 전달받아 읽기서버 간 파일 전송 제거 NFS 패키지 설치sudo apt updatesudo apt install -y nfs-kernel-serve..

[실무 기록] 온프렘 도커 배포 실전 삽질기 (네트워크, 쿠키, 헬스체크 해결편)최근 온프렘(On-premise) 서버 환경에서 여러 마이크로서비스를 Docker Compose로 묶어 배포하며 겪은 시행착오를 정리합니다. 구성 자체는 표준적이었으나, 실제 운영 환경으로 넘어가며 네트워크 통신과 인증 유지 부분에서 예상치 못한 이슈들이 있었습니다.1. 전체 서비스 아키텍처 구성모든 서비스는 docker-compose.yml 하나로 관리하며, 동일한 Docker 네트워크(keural-network) 내에서 통신하도록 설계했습니다.Frontend: Next.jsBackend API: Spring Boot (api)AI Backend: FastAPI (fastapi)Database: PostgreSQLVecto..

이번 글은 온프레미스(on-premise) 환경에서 Docker Compose를 사용해 여러 서비스를 하나의 시스템으로 구성하면서 겪었던 실제 시행착오와 설계 결정을 정리한 기록입니다! 구성한 시스템은 다음과 같음.Next.js (프론트엔드)Spring Boot APIFastAPI (AI / OCR / Chat)PostgreSQLQdrant (Vector DB)vLLM (GPU 기반 LLM Inference)특히 이번 환경은 온디맨드 서버 제공형이라서버가 항상 켜져 있지 않고필요할 때만 기동했다가 종료되며별도 로드밸런서(Nginx 등)를 두지 않는 구조라는 제약이 있었음. 이 글에서는 아래 내용을 중심으로 정리하려 합니다.포트는 어떻게 열고 맞췄는지Docker 네트워크를 왜 하나로 묶었는지Nginx 없..

Docker SDK가상환경을 만든 후, pip install docker 입력docker 데스크탑을 켜서 docker 실행 후가상환경 접속 해 python3 [파일명] 실행한다. app.py#Flask 와 Redis를 이용한 간단한 웹 서버를 구현한 python 파일from flask import flaskfrom redis import Redis, RedisErrorimport osimport socketredis = Redis(host="redis", db=0, socket_connect_timeout=2, socket_timeout=2)app = Flask(__name__)@app.route(" /")def hello(): try: visits = redis.incr ("co..

☁️ 클라우드 컴퓨팅과 가상화 기술가상화(Virtualization) 기술은 클라우드 컴퓨팅을 가능하게 만든 핵심 기술이다.클라우드에서 자원을 효율적으로 집약하고, 다수의 사용자를 동시에 서비스하기 위해 반드시 필요하다.1. 가상화 기술이 등장한 배경초기의 컴퓨팅 환경을 생각해보자.사용자 100명 → 컴퓨터 100대 제공하지만 실제 사용률을 분석해보니실제 사용 중인 자원은 약 30대 분량에 불과함 그렇다면 이런 의문이 생긴다.“100명을 서비스하기 위해 꼭 100대의 컴퓨터가 필요할까?”“30대의 컴퓨터로 100명을 서비스할 수는 없을까?”이 질문에서 가상화 기술이 출발했다.자원 집약(Resource Consolidation)의 필요성하나의 물리적 머신을 여러 사용자가 나눠서 사용단, 사용자는 혼자 쓰는..

컨테이너(Container)컨테이너 기술은 패키징 기술이다.애플리케이션 실행에 필요한 환경을 하나로 묶어, 어디서든 동일하게 실행되도록 만든다.컨테이너 기술의 핵심 특징은 다음과 같다.샌드박스화된 런타임 환경애플리케이션 프로세스가 보호된 영역에서 동작하며, 다른 프로세스에 영향을 끼치지 않는 최소 실행 환경이다.배포가 쉬움(패키징된 환경)애플리케이션 동작에 필요한 필수 환경을 모두 포함하므로 배포가 단순하다.운영체제(OS)로부터의 독립과 한계애플리케이션을 운영체제로부터 분리하지만, 컨테이너의 OS는 호스트 OS에 종속적이므로타 OS 기반 컨테이너를 그대로 구동할 수 없다.높은 성능게스트 OS를 구동하는 오버헤드가 없기 때문에 성능이 좋다. 컨테이너의 OS는 호스트 OS에 종속적이다.호스트 OS에 따른 컨..

☁️ 클라우드 컴퓨팅(Cloud Computing, CC)1. 클라우드 컴퓨팅이란?클라우드 컴퓨팅(Cloud Computing, CC)은 인터넷을 통해 가상화된 컴퓨팅 자원(CPU, 메모리, 스토리지, 네트워크 등)을 필요할 때 즉시 제공받아 사용하는 기술이다.대표적인 특징은 온디맨드 서비스(on-demand service) 이다.즉,자신의 컴퓨터가 아닌클라우드에 연결된 원격 컴퓨터에서연산과 저장, 관리를 수행하는 방식이다.클라우드 컴퓨팅은 다음과 같이 정의할 수 있다.컴퓨팅 자원에 대해 어디서나 접근 가능한 주문형 접근 모델다수의 컴퓨팅 리소스를 가상화 기술로 통합하고이를 원격 사용자에게 서비스 형태로 제공하는 기술2. 클라우드 컴퓨팅의 핵심 특성1️⃣ 온디맨드 셀프 서비스 (On-demand Self..