서비스 인프라 확장성과 모니터링 설계 - 100-hours-a-week/KTB4-13th-wiki GitHub Wiki

북적북적 AI 서버를 운영 환경에 배포한다고 할 때의 배포 단위, 확장 방식, 장애 대응, 모니터링 계획이다.

설계의 출발점은 둘이다.

AI 서버는 무상태다. 대화도, 추천 카드도, 추천 목록도 저장하지 않는다. 추천 조건과 최근 대화를 요청마다 받아 처리하므로 어느 인스턴스로 요청이 가도 결과가 같다. 트래픽이 늘 때 바꿀 것은 EC2 대수뿐이고 세션 고정도 필요 없다.

임베딩은 자체 서빙한다. 외부 임베딩 API가 검색 지연의 대부분을 차지하고 처리량이 쿼터에 묶이는데, 자체 서빙으로 바꾸면 지연이 99배 빨라진다(4-1). 한국어 검색 품질이 앞서는 오픈 모델을 API로는 살 수 없기도 하다. 그래서 임베딩 컨테이너는 후속 과제가 아니라 V1 배포 구성에 포함된다. 모델은 e5-small을 잠정으로 두고 bge-m3와 비교해 확정한다.

(예: 여러 모델 서비스 인스턴스와 로드밸런서 구성, 오토스케일링 정책 등)

한 컨테이너에 섞으면 챗봇의 대기가 검색 처리를 밀어내고, 임베딩 추론이 검색 응답을 잡아먹는다. 스케일 신호도 셋 다 달라서(1-6) 셋을 나눈다.

규모와 피크 산식은 클라우드 파트 문서를 따르고, 방문당 AI 호출 수만 우리 API 기준으로 넣었다. 실사용 데이터가 생기면 교체한다.

3년 차 피크에서도 조회 경로는 10 rps 안팎이다. 챗봇은 다르다. 초당 3턴이면 턴당 LLM 2회라 호출이 분당 360회 나가므로, 인스턴스 수가 아니라 외부 LLM API 쿼터와 예산(3개월 36만 원)이 실제 상한이다. 인프라가 할 일은 그 상한을 넘기 전에 429로 막고 예산 소진 속도를 보이게 하는 것이다.

클라우드 파트의 1단계 구성에 맞춘다. 오케스트레이터 없이 AI EC2 한 대에서 Docker Compose로 컨테이너를 띄운다.

flowchart TB
    subgraph APP["App EC2 · 클라우드 파트"]
        BE["Nginx · Backend · MySQL"]
    end
    subgraph AIEC2["AI EC2 1대 · Docker Compose"]
        NGX["nginx<br/>경로 라우팅"]
        SYNC["api-sync<br/>① /search · ④ /feed<br/>⑥ /profile · ⑧ /health"]
        GEN["api-gen<br/>③ /chat"]
        EMB["embedding<br/>② /embeddings · CPU"]
        PG[("postgres + pgvector<br/>데이터는 EBS")]
        REP["replicator"]
        ING["ingest job<br/>실행할 때만"]
    end
    LLM["외부 LLM API"]
    BE -->|"ai.internal · 서비스 토큰"| NGX
    NGX -->|"③ 경로"| GEN
    NGX -->|"나머지 경로"| SYNC
    SYNC --> EMB
    GEN --> EMB
    ING --> EMB
    SYNC --> PG
    GEN --> PG
    ING --> PG
    REP -->|"읽기 전용"| BE
    REP -->|"단방향 복제"| PG
    GEN --> LLM

• BE는 사설 IP 대신 고정 내부 도메인(ai.internal)으로 부른다. V2에서는 같은 이름이 내부 ALB를 가리키므로, 호스트를 바꾸거나 늘려도 BE 설정이 바뀌지 않는다.
• AI EC2는 외부에 공개하지 않고, 보안 그룹은 BE(V2에는 내부 ALB) 요청만 받는다. /embeddings는 내부 전용이라 nginx에 열지 않고, 인증이 없는 /health도 이 네트워크 제한으로 막는다.

상시 컨테이너의 메모리 합계는 약 2.8GB로 추정한다(embedding 1.4GB만 실측). 그래서 AI EC2는 메모리 4GB 이상, 디스크 gp3 30GiB로 잡는다. GPU는 두지 않는다. e5-small은 CPU로 151 docs/s가 나와 CPU 컨테이너로 충분하다.

V1은 AI EC2 한 대라 분산할 대상이 없고, 확장은 V2에서 한다. 먼저 postgres와 replicator를 AI EC2에서 떼어내 각각 한 대씩 둔다. DB는 한 벌이어야 하고 복제기는 중복 실행이 금지라, 호스트째 복제하면 안 되는 컨테이너다. 그다음 내부 ALB와 Auto Scaling Group을 붙인다. 넓히는 방향은 두 가지다.

• A. 같은 구성을 여러 대: AI EC2를 통째로 복제하고 앞에 내부 ALB를 둔다. 경로 판단은 각 호스트의 nginx가 계속 맡는다.
• B. 역할별로 나눠서: 조회군과 생성군을 다른 EC2에 두고 ALB가 경로를 보고 갈라 보낸다. 두 군이 각각 Auto Scaling Group을 갖고, embedding은 양쪽에 둔다.

방향 A 구성:

flowchart TB
    BE["백엔드"]
    ALB["내부 ALB<br/>ai.internal"]
    subgraph ASGA["AI EC2 Auto Scaling Group · 같은 구성 n대"]
        A1["EC2 1<br/>nginx · 조회 · 생성 · 임베딩"]
        A2["EC2 2<br/>같은 구성"]
    end
    DATA[("데이터 EC2 1대<br/>postgres + pgvector")]
    REP["복제기 EC2 1대 · 고정"]
    BE --> ALB
    ALB --> A1
    ALB --> A2
    A1 --> DATA
    A2 --> DATA
    REP -->|"읽기 전용"| BE
    REP -->|"단방향 복제"| DATA

지금 우리 규모에서는 A가 맞는다. 부족한 것이 용량이 아니라 이중화이기 때문이다(4-2).

V1은 고정 구성이다. 자동 확장 없이, 부하가 몰리면 앱이 서비스 토큰 단위로 429와 Retry-After를 돌려준다. DB와 LLM 예산을 지키는 최후 방어선이다. V1 피크는 AI 경로를 모두 합쳐 0.1 rps 안팎이라(1-2) 이 구성으로 충분하다.

V2 확장 후에는 컨테이너가 아니라 EC2 대수를 늘린다.

• 생성군에 CPU를 쓰지 않는 이유: 요청이 외부 API 응답을 기다리는 동안 CPU는 놀기 때문에, CPU가 60%에 닿기 전에 동시 연결이 먼저 찬다.
• 생성군 최대 4는 서버 한계가 아니라 LLM API 쿼터에 맞춘 값이다. 쿼터를 넘으면 EC2를 늘려도 503만 늘어난다.

무상태라도 EC2 사이에 공유되어야 하는 것이 있다.

장애가 나도 에러를 내는 대신 기능을 줄여 정상 응답하는 축소 동작이 API마다 정해져 있다. 인프라는 그 동작이 실제로 나오게 하고, 얼마나 자주 나오는지를 지표로 만든다.

V1에 남는 약점은 두 가지다. AI EC2가 죽으면 대신 받을 호스트가 없고, 배포 중에 AI 요청이 끊긴다. 둘 다 V2에서 확장하면 해소된다. V1은 3주짜리 초기 운영이라 이 위험을 안고 간다.

상태 검사. GET /health의 status가 ok·degraded면 정상으로 보고, down(503)일 때만 트래픽에서 뺀다. degraded는 일부 구성 요소만 죽은 상태라 호스트를 빼면 줄어든 기능조차 못 준다. 복제 지연은 판정에 쓰지 않는다. 복제가 밀리면 멀쩡한 호스트가 전부 동시에 빠지기 때문이다.

배포. V1은 바뀐 컨테이너만 다시 만든다(Recreate). 그 사이 해당 경로가 잠깐 끊긴다. 이미지 태그는 Git 커밋 해시이고, 롤백은 이전 태그로 다시 올린다. V2에서 확장한 뒤에는 호스트를 하나씩 교체하는 롤링으로 바꿔 이 단절을 없앤다.

(예: 응답 시간, Throughput, 에러 로그 등과 Grafana 대시보드 구성안).

목표는 실측에서 역산했다. 검색 200ms는 임베딩 자체 서빙(5.8ms)을 전제로 한 값이고, 챗봇 8초는 실측 한 턴 약 6초에 여유를 둔 값이다.

BE 원본에서 AI DB로 넘어오는 데이터의 허용 지연이다. 이 값이 복제 감시의 판정선이다.

복제가 끊겨도 응답은 모두 정상 200으로 나가서, /health의 replication_lag_seconds 말고는 감지할 방법이 없다.

모든 지표는 CloudWatch로 모은다(3-3).

flowchart LR
    APP["AI EC2의 컨테이너들"] -->|"사용자 정의 지표 · 요청마다 값"| CW["CloudWatch"]
    AGENT["CloudWatch 에이전트"] -->|"호스트 CPU · 메모리 · 디스크"| CW
    APP -->|"JSON 로그 · X-Request-Id"| LOG["CloudWatch Logs<br/>14일 보관"]
    CW --> DASH["대시보드 4장"]
    CW --> ALARM["CloudWatch Alarm → Discord"]

• V1은 팀 공통 모니터링인 CloudWatch 하나로 모은다. 별도 수집 서버가 없으므로 앱이 지표를 CloudWatch로 직접 보내고, 호스트 자원은 CloudWatch 에이전트가 모은다.
• p95·p99를 보려면 요청마다 값을 올려야 한다. 평균이나 합계로 줄여 올리면 CloudWatch가 백분위를 계산하지 못한다.
• 로그는 JSON 한 줄로 남긴다. 필드는 시각, X-Request-Id, 엔드포인트, 상태 코드, 지연, 축소 여부, 임베딩·LLM 소요 시간, 토큰 수다. 대화 원문·검색어·이미지는 남기지 않는다.
• 엔드포인트는 경로만 남기고 쿼리스트링은 버린다. ④ 피드가 GET이라 user_id와 category·match_score_min 같은 취향 필터가 URI에 실린다. 애플리케이션 로그는 경로만 기록하고, ALB 액세스 로그처럼 URI 전체를 남기는 계층은 쿼리 마스킹을 켜거나 보관 기간을 따로 잡는다. 검색어를 남기지 않기로 한 것과 같은 이유다.
• X-Request-Id는 BE가 붙여 보내고, 없으면 AI가 만들어 응답 헤더로 돌려준다. BE 로그와 AI 로그를 이 키로 잇는다.

알림은 CloudWatch Alarm으로 만들어 Discord로 보낸다. 채널과 임계값은 보류(팀 논의 후 확정)이고, 아래 수치는 AI 파트 잠정안이다.

(가능하다면)

2026-09-09 개발기(Apple Silicon 10코어, CPU, torch 스레드 4)에서 고정 질의 30개 × 3회, 도서 256건으로 쟀다. 예열은 제외했다.

LLM(외부 API)은 카드 3장 생성이 p95 4,858ms이고, 턴당 토큰은 입력 398·출력 516이다.

• gemini-embedding-001은 제외한다. 3,072차원은 pgvector 인덱스 한도(2,000)를 넘고, 쿼리 왕복만으로 검색 목표 200ms를 넘긴다.
• e5-small은 지연·처리량·메모리 모두 여유가 크다. 다만 동시성을 1→4→8로 올리면 175→230→159 RPS로 4에서 꺾여, 컨테이너 수로 늘려야 한다.
• bge-m3는 품질 기대가 높지만 처리량이 8분의 1이다. 결정은 실제 카탈로그의 recall@10으로 하고, 그때까지 e5-small을 잠정값으로 쓴다.

1-2의 3년 차 피크와 위 실측으로 계산했다.

결론: 처리량만 보면 3년 차 목표(V1의 약 220배)까지도 AI EC2 한 대의 컨테이너 한 벌로 감당된다. 먼저 닿는 한계는 LLM API 쿼터·예산과 DB이고, 진짜 상한은 처리량이 아니라 가용성이다. 호스트가 한 대라 그 한 대가 죽으면 전부 멈추므로, 확장(1-5)의 값어치는 용량이 아니라 이중화에 있다.

위 실측은 개발기 기준이라, 배포 환경 값은 MVP 배포 전에 이 테스트로 다시 잰다. 도구는 k6를 쓰고, 스테이징은 운영과 같은 EC2 사양·컨테이너 구성으로 맞춘다. LLM은 모의 서버(앱 자체 한계 측정)와 실제 API(응답 시간 측정, 예산 소량 사용) 두 번 돌린다.

E는 적재 배치와 검색이 같은 임베딩 컨테이너를 쓰기 때문에 넣었다. 밀어낸다면 적재에 속도 제한을 걸거나 트래픽이 적은 시간대로 옮긴다.

(예: "사용자 100배 증가 시에도 대응 가능하도록 OOO를 구성하여 서비스 중단 없이 확장 가능").

이 정도 수준으로 두는 이유는 규모와 팀에 맞추기 위해서다. 3년 차 목표에서도 AI 피크가 20 rps 안팎이라 쿠버네티스·멀티 리전·상시 GPU를 지금 들이면 얻는 것보다 운영 부담이 크다. 대신 응답 시간의 병목이던 외부 임베딩 호출을 우리 호스트 안으로 들여 우리가 늘릴 수 있는 자원으로 바꾸고, 각 API의 축소 동작·복제 허용 지연·예산 상한을 전부 지표로 만들어, 문제가 생겼을 때 사용자 응답이 아니라 대시보드에서 먼저 보이게 하는 데 집중했다.