동물병원 관리 프로그램을
클라우드에서 운영하기.
동물병원 직원이 보호자·반려동물·방문 기록을 관리하는 프로그램, PetClinic의 운영 환경을 만들었습니다. 변경 내용을 자동으로 반영하고, 오류와 접속 증가에 어떻게 반응하는지 확인했습니다.
제가 만든 것은 프로그램이 작동할 서버 환경입니다.
기존 PetClinic 프로그램을 활용했습니다. 업무 기능을 새로 개발한 것이 아니라, AWS에서 실행하고 관리하는 환경을 구성했습니다.
어떤 점을 확인했나요?
large에서 medium으로 변경
각 5분씩 비교한 범위
다시 줄어드는 과정 확인
01프로그램이 작동할 환경 구성
화면 뒤에서 일어나는 흐름
사용자가 보호자 정보를 등록하면, 업무 처리 프로그램이 요청을 받아 데이터베이스에 저장합니다. 저는 이 요청이 전달될 길과 프로그램이 실행될 서버를 구성했습니다. 관리자 접속 경로도 일반 사용자의 경로와 구분했습니다.
구성도 읽는 법: ALB는 요청을 받는 입구, WEB은 웹 요청을 전달하는 부분, APP은 업무 처리 프로그램, Aurora는 정보를 저장하는 데이터베이스입니다.
같은 환경을 다시 만들 수 있도록 기록
설정을 화면에서 하나씩 입력하면 빠뜨리는 항목이 생길 수 있습니다. 필요한 서버와 연결 설정을 코드로 기록하고, 도구가 그 기록에 따라 환경을 만들도록 했습니다. Terraform은 기반 시설을, eksctl은 프로그램을 실행할 서버 묶음을 구성하는 데 사용했습니다.
사용한 기술과 세부 구성 보기
- Terraform: VPC, Subnet, Route Table, 보안 그룹, Bastion, Aurora
- eksctl: EKS 클러스터, Managed Node Group
- 접근 제어: Bastion 경유 네트워크 접근과 IAM·Access Entry 권한 구분
02변경 내용을 자동으로 반영
왜 필요한가요?
프로그램을 고칠 때마다 사람이 서버에 접속해 직접 교체하면 작업을 빠뜨릴 수 있습니다. 코드를 올리면 검사와 준비 작업을 거쳐 운영 환경에 반영되도록 연결했습니다. 이를 자동 배포라고 합니다.
외부 도구는 새 버전을 준비하고, 운영 환경 안의 도구가 이를 가져와 반영하게 했습니다. 외부 도구가 서버 관리 기능에 직접 접속할 경로를 추가하지 않기 위해서입니다.
사용한 기술과 직접 수행한 작업 보기
GitHub Actions는 자동 작업 도구, ECR은 실행에 필요한 파일 묶음의 저장소입니다. Argo CD는 기록한 배포 설정과 실제 실행 상태를 맞추는 도구입니다.
- GitHub Actions에서 검증·이미지 빌드와 ECR 업로드 구성
- OIDC 기반 임시 AWS 자격증명 사용
- GitOps Manifest의 이미지 태그 갱신과 Argo CD 동기화 연결
자동 작업 성공, 새 버전 교체, 실제 화면 변경을 각각 확인했습니다.
두 캡처는 구성의 동작 근거이며, 동일 커밋의 연속 화면을 의미하지 않습니다.
03더 작은 서버로도 충분한지 비교
문제와 비교 조건
처음 사용한 서버에는 자원 여유가 있었습니다. 더 작은 서버로도 같은 업무를 처리할 수 있는지 비교했습니다. 서버는 2대로 유지하고, 같은 업무를 반복하면서 서버 크기만 바꿨습니다.
- 도구: 가상 사용자로 접속을 재현하는 k6 사용. 실행 개수 자동 조절 기능을 적용하기 전 비교
- 부하: 가상 사용자 50명·100명·150명으로 각각 5분간 실행
- 업무: 보호자 생성, 반려동물 생성, 조회, 방문 등록, 최종 조회
- 업무 1회당 HTTP 요청 5건
| 가상 사용자 | large 초당 처리 요청 | medium 초당 처리 요청 | large 응답 시간 P95 | medium 응답 시간 P95 |
|---|---|---|---|---|
| 50명 | 30.24 | 30.56 | 48.66ms | 68.26ms |
| 100명 | 61.14 | 60.25 | 40.06ms | 48.42ms |
| 150명 | 90.32 | 90.21 | 58.34ms | 55.31ms |
비교한 모든 구간에서 두 구성 모두 요청 실패가 없었습니다.
표 읽는 법: 초당 처리 요청 수는 같은 시간에 얼마나 많은 요청을 처리했는지 보여줍니다. P95는 요청의 약 95%가 그 시간 안에 끝났다는 뜻입니다. 55.31ms는 약 0.055초입니다.
판단과 한계
처리량이 비슷하고 작은 서버에서도 자원이 계속 부족한 상태가 나타나지 않아 이번 검증 범위의 운영 사양으로 t3.medium 2대를 선택했습니다. medium의 응답 시간이 모든 조건에서 더 짧았던 것은 아닙니다.
각 시험은 5분입니다. 오랜 시간 사용해도 같은 결과가 나오는지, 실제 요금이 얼마나 줄어드는지까지 확인한 것은 아닙니다.
04오류를 일으켜 상태 화면에 잡히는지 확인
왜 일부러 오류를 만들었나요?
상태 화면에 ‘오류 0건’이 보여도, 실제로 문제가 없는지 수집이 안 되는지는 알 수 없습니다. 일부러 오류를 만든 뒤, 발생시킨 횟수와 화면에 기록된 건수가 맞는지 확인했습니다. WhaTap과 CloudWatch는 이런 상태를 관찰하는 도구입니다.
| 발생시킨 상황 | 확인한 반응 |
|---|---|
| 프로그램 내부 오류 요청 30회 | 요청 입구의 오류 집계 30건과 일치 (Target 5XX) |
| 없는 페이지를 찾는 요청 10회 | 해당 오류 집계 10건과 일치 (Target 4XX) |
| 실행할 곳을 찾을 수 없는 작업 생성 | 실행 대기 상태 1개 표시 (Pending) |
| 준비 상태 확인에 실패하도록 설정 | 사용할 준비가 안 된 실행본 1개 표시 (Unavailable) |
확인 범위
일부 수치는 화면에 늦게 나타났습니다. 발생 직후만 보지 않고 같은 시간대의 오류 종류와 건수를 대조했습니다. 오류가 기록되는지는 확인했으며, 담당자에게 알림이 도착하는지까지 시험하지는 않았습니다.
9월 24일 오류 검증 기록 ↗05바빠지면 프로그램 실행 개수를 자동으로 늘리기
서버 2대에서 프로그램 실행 개수 조절
한 매장에 주문이 몰리면 계산대를 더 여는 것처럼, 처리할 일이 늘면 프로그램을 여러 개 실행해 일을 나누게 했습니다. 부하가 줄면 실행 개수도 다시 줄이도록 했습니다.
계산대에 해당하는 것은 프로그램 실행본이고, 매장에 해당하는 서버는 2대로 유지했습니다. 실행 개수가 늘었다고 서버 자체가 늘어난 것은 아닙니다.
두 자동화 도구가 서로 방해하지 않도록 조정
배포 도구는 기록된 설정을 유지하려 하고, 자동 확장 도구는 부하에 따라 실행 개수를 바꾸려 합니다. 두 도구가 같은 값을 서로 바꾸지 않도록 실행 개수 조절은 자동 확장 도구에 맡겼습니다.
프로그램 4개가 기존 서버 2대에서 정상 실행됐습니다. 이번 시험에서는 서버 자체를 늘리는 기능을 도입하지 않았습니다. 실행 개수 2~4개는 시험한 범위이며, 모든 서비스에 맞는 정답은 아닙니다.
기술 담당자를 위한 설정값 보기
Pod는 Kubernetes에서 프로그램을 실행하는 단위이고, Node는 그 프로그램이 올라가는 서버입니다. HPA는 자원 사용량에 따라 Pod 개수를 조절합니다.
APP CPU Request 500m, HPA CPU 목표 70%, 최소 2개·최대 4개로 설정했습니다. 70%는 서버 전체 CPU가 아니라 Pod에 설정한 요청량을 기준으로 합니다.
Argo CD의 /spec/replicas에 ignoreDifferences와 RespectIgnoreDifferences를 적용했습니다. HPA가 조절한 개수를 배포 도구가 되돌리지 않도록 했습니다.
06배운 점과 다음 확인 과제
프로그램 실행에서 끝내지 않고, 왜 이 서버를 골랐는지, 오류가 생기면 알 수 있는지, 바빠지면 어떻게 대응하는지 확인했습니다. 결과를 설명할 때는 시험 조건과 확인하지 못한 부분도 함께 남겼습니다.
추가 검증 과제
- 오랜 시간 요청이 이어질 때도 서버 자원이 충분한지 확인
- 오류가 생겼을 때 담당자에게 알림이 도착하는지 확인
- 장애 발생 후 다시 정상 서비스를 제공하기까지 걸리는 시간 측정
- 실제 운영 시간과 전체 사용 자원을 반영한 요금 비교
이력과 기술 경험도 확인해 보세요.
교육·자격과 프로젝트 수행 범위를 정리했습니다.