온프레미스에서 클라우드로 - 무중단 마이그레이션 경험기

안녕하세요 저는 프롭테크 플랫폼에서 백엔드 개발자로 근무 중인 3년차 백엔드 개발자 정정일입니다.

이번 글에서는 온프레미스 환경에서 운영되던 모놀리식 서버를 클라우드(AWS)로 이전한 경험과 그 과정에서 테라폼(Terraform)을 활용한 인프라 자동화 경험에 대해 공유하려 합니다.

배경 상황

제가 올해 3월에 팀에 합류했을 때, 대부분의 서비스는 이미 클라우드 환경에서 운영되고 있었습니다. 하지만 서비스 중 하나가 여전히 IDC에서 모놀리식 아키텍처로 운영되고 있었습니다. 이 서버는 웹 애플리케이션과 데이터베이스가 동일한 물리적 서버에 구성되어 굉장히 단순한 구조를 가지고 있었죠.

이 서버는 하드웨어 접촉 불량으로 인한 서버 다운 이슈가 간헐적으로 발생했고, 트래픽 증가에 따른 스케일링에도 제약이 있었습니다.

이런 문제들로 인해 서비스 안정성이 저하되고 운영 부담이 증가하는 상황이었습니다. 특히 하드웨어 접촉 불량으로 인한 예기치 않은 서버 다운은 사용자 경험에 굉장히 심각한 문제였습니다.

클라우드 마이그레이션 결정

여러 대안을 검토한 결과, 클라우드로의 마이그레이션이 최적의 해결책이라고 판단했습니다.

이미 기존에 대부분의 서버들은 클라우드에서 운영중이기도 했고 아래와 같은 이유로도 클라우드로의 이관이 필수적이라고 판단했습니다.

• 안정성 향상: AWS의 높은 가용성 인프라 활용
• 유연한 스케일링: 트래픽 변화에 따른 자원 조정 용이
• 통합 운영 환경: 기존 클라우드 서버들과 동일한 관리 체계 적용
• 비용 효율성: 사용한 만큼 지불하는 모델로 리소스 효율화

또 가장 큰 이유는 회사에 클라우드 관련 크래딧이 있었기 때문에 비용적인 측면도 컸습니다.

마이그레이션 과제: 무중단 전환

마이그레이션 계획 수립 시 가장 중요한 요구사항은 서비스 다운타임 최소화였습니다. 사용자 경험을 해치지 않으면서 안전하게 전환하기 위해 다음과 같은 과제를 해결해야 했습니다:

1. DNS 전파 시간 동안의 트래픽 처리: DNS 변경 후 전파가 완료될 때까지 일부 사용자는 IDC 서버로, 일부는 클라우드 서버로 접속하는 상황 발생
2. 데이터 정합성 유지: 전환 기간 동안 두 환경에서 발생하는 데이터 변경사항의 일관성 보장
3. 롤백 계획: 문제 발생 시 신속하게 원래 환경으로 복귀할 수 있는 방안 마련

무중단 마이그레이션 전략

기존에 운영중인 웹서버였기때문에 동일한 DNS 그대로 운영돼야 했습니다. 따라서 서버를 구성한다 하더라도 DNS의 Endpoint가 전파되는 시간이 존재했습니다.

저희는 DNS 전파 시간을 고려하여, 다음과 같은 전략을 수립했습니다.

1. 클라우드 환경 구축: AWS에 동일한 서버 환경을 미리 구성
2. 이중 운영: DNS 변경 후 전파 기간 동안 IDC와 클라우드 양쪽 모두에서 서버 운영
3. DNS 전환: 준비가 완료되면 DNS를 클라우드 서버 IP로 변경
4. 모니터링: 전환 과정 실시간 모니터링 및 문제 발생 시 즉시 대응
5. IDC 서버 종료: DNS 전파 완료 확인 후 IDC 서버 종료

이렇게 저희는 사용자들이 DNS 캐시 상태에 따라 자연스럽게 새 환경으로 전환되도록 하여 다운타임을 방지했습니다.

데이터 정합성 문제와 CDC 솔루션

마이그레이션 과정에서 가장 큰 기술적 과제는 데이터 정합성 유지였습니다.

저희는 클라우드의 관리형 데이터베이스로 이관할 결정을 했기때문에 기존의 IDC 로컬 DB를 계속 사용할 수 없었습니다.

그러니 IDC 서버와 클라우드 서버가 동시에 운영되는 동안, 두 환경의 데이터베이스가 동기화되지 않으면 심각한 문제가 발생할 수 있었습니다.

이 문제를 해결하기 위해 여러 대안을 검토했습니다.

1. 데이터베이스 복제(Replication): DB 자체의 복제 기능 활용
2. 애플리케이션 수준 이중 쓰기(Dual Write): 애플리케이션에서 두 DB에 동시에 쓰기
3. 메시지 큐 기반 동기화: 데이터 변경을 메시지 큐에 발행하여 동기화
4. ETL 기반 배치 동기화: 주기적 배치 작업으로 데이터 동기화
5. CDC(Change Data Capture): DB 변경 로그를 캡처하여 실시간 동기화

검토 결과, CDC 기술이 실시간성과 신뢰성 측면에서 가장 적합하다고 판단했습니다. 따라서 다음과 같이 구현했습니다.

1. CDC 구성: IDC DB의 변경사항을 실시간으로 감지하여 AWS RDS로 복제

2. 단방향 동기화: 전환 기간 동안 IDC DB → AWS RDS 방향으로만 동기화

3. 애플리케이션 설정: 전환 기간 동안 모든 서버가 IDC DB를 참조하도록 구성

4. 전환 완료 후: DNS 전파 완료 확인 후 모든 서버의 DB 참조를 RDS로 변경

5. 이후: 기존 IDC 서버 종료 및 CDC 구성 종료

이 접근 방식을 통해 DNS 전파 기간 동안 발생할 수 있는 데이터 불일치 문제를 해결했습니다.

저희는 CDC 솔루션으로는 AWS DMS를 선택했습니다. 이유로는 아무래도 AWS 환경으로의 이관이다 RDS와 가장 호환성이 좋다고 판단했습니다.

인프라스트럭처 자동화 (IaC)

클라우드 환경 구축 과정에서 인프라스트럭처 자동화(IaC)를 위해 Terraform을 도입했습니다. 다음과 같은 주요 리소스를 코드로 관리했습니다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# EC2 인스턴스 생성
resource "aws_instance" "web_server" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = var.ec2_instance_type
  subnet_id              = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.ec2_sg.id]
  key_name               = aws_key_pair.web_server_key_pair.key_name
  iam_instance_profile   = aws_iam_instance_profile.ec2_profile.name

  # 인스턴스 초기화 스크립트
  user_data = file("${path.module}/server_default_setting_example.sh")

  # 루트 볼륨 설정
  root_block_device {
    volume_type           = "gp3"
    volume_size           = 50
    delete_on_termination = true
  }
}

# RDS 인스턴스 생성 (MariaDB)
resource "aws_db_instance" "database" {
  identifier             = "example-database"
  engine                 = "mariadb"
  engine_version         = "10.6"
  instance_class         = var.rds_instance_type
  allocated_storage      = 200
  storage_type           = "gp3"
  username               = var.rds_username
  password               = var.rds_password
  db_subnet_group_name   = aws_db_subnet_group.rds.name
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  parameter_group_name   = "default.mariadb10.6"
  publicly_accessible    = true
  skip_final_snapshot    = true
  multi_az               = false
  backup_retention_period = 7
}

Terraform을 사용함으로써 얻은 이점.

1. 인프라 코드화: 모든 인프라 구성을 코드로 관리하여 버전 관리 및 변경 추적 용이
2. 재현성: 동일한 환경을 필요시 언제든지 재생성 가능
3. 문서화: 코드 자체가 인프라 구성에 대한 문서 역할
4. 자동화: 수동 작업 최소화로 인적 오류 감소

마이그레이션 실행 과정

실제 마이그레이션은 다음과 같은 단계로 진행했습니다.

1. 사전 준비

   • Terraform 코드 작성 및 테스트
   • CDC 구성 및 동기화 테스트
   • 롤백 시나리오 검증

2. 클라우드 환경 구축

   • Terraform을 통한 AWS 인프라 프로비저닝
   • 애플리케이션 배포 및 구성
   • 기능 테스트 수행

3. 데이터 동기화 시작

   • CDC 활성화
   • 초기 데이터 동기화 완료 확인
   • 실시간 복제 상태 모니터링

4. 전환 실행

   • 저부하 시간대 선택 (새벽)
   • DNS 레코드 변경
   • 양쪽 환경 모니터링
   • 트래픽 전환 상황 실시간 추적

5. 전환 완료

   • DNS 전파 완료 확인
   • 애플리케이션 DB 참조를 RDS로 변경
   • CDC 중단
   • IDC 서버 종료

결과

마이그레이션 결과, 다음과 같은 성과를 얻었습니다.

• 무중단 전환 달성: 사용자 경험 저하 없이 성공적으로 마이그레이션 완료
• 안정성 향상: 하드웨어 접촉 불량으로 인한 서버 다운 이슈 해소
• 확장성 확보: 클라우드 환경에서 필요에 따른 유연한 스케일링 가능
• 운영 효율화: 모든 서버가 클라우드 환경으로 통합되어 관리 효율성 증가

이번 마이그레이션을 통해 저는 철저한 계획의 중요성을 체감한 것 같습니다. 팀원분들과 함께 협업하여 계획을 구성하면서 문제가 발생할 가능성을 최대한 줄일 수 있었습니다.

또 Terraform을 통해 인프라 자동화를 구성해보다보니 이제까지 하나하나 직접 구성하던 자신이 바보같이 느껴질 정도로 너무 관리하기 용이했습니다. 또 한 번에 모든 것을 전환하기보다 단계적 접근이 리스크 감소에 효과적이라는 걸 다시금 느끼게 되네요.

결론

IDC에서 클라우드로의 마이그레이션은 또 하나의 도전이었지만, 열심히 준비한 계획과 적절한 기술 선택을 통해 성공적으로 완료할 수 있었습니다. 특히 CDC를 활용한 데이터 동기화 전략과 Terraform을 통한 인프라 자동화가 기억에 남네요.

이런 제 경험이 비슷한 문제를 겪고 계시는 분들께 조금이나마 도움이 됐길 바라며 이만 글을 마치겠습니다. 감사합니다.

Reference

• https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/CHAP_Source.MySQL.html
• https://docs.aws.amazon.com/ko_kr/dms/latest/userguide/Welcome.html