안녕하세요. 아이들나라 Backend 유충민입니다.
아이들나라는 현재 여러 AWS 계정에서 운영 중인 기존 서버와 신규 서버들을 관리하기 위한 비용을 절감하고 운영 효율성을 높이기 위해 노력하고 있습니다. 이를 위해 아이들나라는 모든 서버를 한 개의 AWS 계정으로 이관하는 작업을 진행 중입니다. 이 경험을 통해 얻은 노하우와 서버 이관의 전 과정에 대한 경험을 바탕으로, 우리는 기존 서버 환경을 보다 효율적으로 최적화하고 안정성 있는 새로운 환경으로 옮기는 경험을 살펴보려고 합니다. 이 서버 이관 프로세스를 통해 아이들나라는 더 나은 서비스를 제공하고 사용자들에게 더 편리하고 안정적인 환경을 제공할 계획입니다.
이관 전 기존 서비스 파악
서버 이관 전 기존 서버의 구성을 동일하게 신규 계정으로 구성을 해야하기 때문에 기존 서버의 구성을 파악할 때는 다양한 측면을 고려하여 정보를 수집하는 것이 중요합니다. 기존 서버 구성을 파악할 때 다음 사항들을 고려합니다.
1. 하드웨어 및 네트워크 구성
•
서버의 하드웨어 사양 (CPU, 메모리, 저장 공간 등)
•
네트워크 구성 및 연결 상태
•
서버의 IP 주소, 호스트명, 도메인 정보
2. 환경 및 스크립트
•
서버에 설치된 운영 체제의 버전과 구성(리눅스, 윈도우 등), 서버 시간(UTC, KST등)
•
사용 중인 파일 시스템 및 디스크 구성 파악
•
환경 변수, PATH 설정, 로케일 등의 시스템 환경
•
배치 스크립트, 실행 스크립트, 자동화된 작업 스크립트 등
3. 소프트웨어 및 미들웨어
•
미들웨어 및 프레임 워크의 버전과 구성 확인
•
서비스로 동작 중인 애플리케이션의 목록과 버전 정보 확인
•
외부(타 부서/타 회사 등) 접근 여부 확인
4. 보안 및 권한
•
방화벽 설정, 포트 번호, SSL/TLS 인증서 및 보안 설정 확인
•
사용자 권한 및 그룹 설정, 접근 제어 목록(ACL) 확인
5. 데이터베이스 및 스토리지
•
데이터베이스 시스템의 종류, 버전, 데이터 스키마 파악
•
스토리지 구성과 사용 중인 디스크의 용량, 가용성 확인
6. 로그, 모니터링
•
서버에서 생성되는 로그 파일의 위치, 포맷, 로깅 수준 파악
•
모니터링 도구의 사용 여부와 설정 정보 수집
파악했으면 옮겨보자
이관한 서버 중 하나로 예시를 들어보겠습니다. 아이들나라에서는 사용자의 연령과 관심사에 기반해 콘텐츠를 추천해 주는 추천 서버를 운영하고 있습니다. 이 서버는 기존에는 다른 팀에서 관리되고 있던 서버였습니다.
서버는 EC2(Auto Scaling) standalone 구성으로 운영 되었고 서버 실행을 위한 스크립트 파일들이 프로젝트 내에 존재하며, 빌드 관리는 Maven을 사용하고 있었습니다.
서버 실행을 위한 스크립트 파일들이 프로젝트 내에 존재했습니다. 또한, 빌드 관리는 Maven을 사용하고 있었으며, CI/CD 파이프라인은 별도로 설정되어 있지 않았습니다. 추천서버는 S3를 사용하여 파일 저장, Elasticache로 캐싱, EBS로 스토리지, 그리고 RDS로 데이터베이스를 운영하고 있었습니다.
아이들나라에서는 Gradle 빌드 도구와 Kubernetes(K8s)를 활용하고 있으며, CI/CD 파이프라인은 GitHub Actions와 ArgoCD를 이용하여 구성되어 있습니다. 이에 따라 기존 추천 서버 프로젝트를 먼저 Gradle로 마이그레이션하고, GitOps 작업을 수행했습니다.
1. 프로젝트 설정
•
Gradle 프로젝트 초기화gradle init
◦
프로젝트 루트 디렉터리에서 터미널 또는 명령 프롬프트를 열고 다음 명령을 실행합니다
◦
이 명령은 기본적인 Gradle 빌드 스크립트와 설정 파일을 생성해 줍니다.
•
기존 Maven 프로젝트의 의존성과 플러그인 설정을 Gradle 스크립트로 변환합니다.
◦
dependencies, queryDsl 등의 설정은 수동으로 Gradle 스크립트에 작성해야 합니다.
•
설정 파일 수정
◦
application.yaml 및 로깅 설정과 같은 구성 파일 아이들나라 환경에 맞게 수정합니다.
•
GitOps 설정 및 생성
◦
아이들나라에서 사용중인 GitOps 방식으로 환경 구성을 관리하기 위한 설정을 작성합니다.
2. 서버 구성
•
DB, 스토리지, 미들웨어 접근을 확인합니다.
•
추천 서버는 EC2에 볼륨마운트가 되어 파일을 사용중이었습니다. Kubernetes 클러스터에 PV로 EFS 설정을 한 후 동작을 확인하였습니다.
3. 서버 확인
•
API 동작 검증
◦
cURL 테스트 및 동작 테스트를 통해 기존 서버와 신규 서버 간의 응답 값 비교를 수행합니다.
◦
GET 및 POST 요청/응답 값 비교를 통해 데이터 일치성을 확인합니다.
◦
응답 속도 체크 및 데이터 정합성을 확인합니다.
•
스케줄러 동작을 확인
◦
서버 시간을 확인하여 시스템 시간 설정의 정확성을 검증합니다.
◦
스케줄러가 예정된 시간에 정상적으로 동작하는 지 확인합니다.
•
모니터링 도구를 사용하여 서버 및 애플리케이션 로그를 모니터링하고 오류 메시지를 찾아내어 분석합니다.
4. 트래픽 전환
DNS 레코드를 직접 변경하는 대신 로드 밸런서 또는 프록시 서버를 활용하여 트래픽을 전환하는 것을 권장합니다. 이는 서버 간의 통신 및 성능을 사전에 확인하고, 이슈가 발생할 경우 롤백이 가능하게 해줍니다.
이처럼 설정을 먼저 완료하고 정상 동작을 확인한 후에 DNS 레코드를 변경함으로써 안정성과 신뢰성을 확보할 수 있습니다.
문서화, 비상 대응 및 롤백
기존 서비스를 파악하고 신규로 구축한 후에도 예상치 못한 문제가 발생할 수 있습니다. 이러한 문제가 발생하기 전에 최소화하고 빠르게 대처하기 위해서는 철저한 문서화, 신속한 비상 대응, 그리고 효과적인 롤백 전략이 필수입니다.
여기까지 되었다면 준비는 끝..!!
성공을 위해 기도합니다. 