워드프레스에 글을 올렸는데 새로고침하자 사라졌다. 다시 누르면 돌아온다. 글이 숨바꼭질을 하는 건 아니다. Auto Scaling으로 EC2가 두 대가 된 뒤라면, 요청을 받은 서버마다 서로 다른 데이터베이스를 읽고 있을 수 있다.
Auto Scaling 후 글이 보였다 안 보이는 이유는?
Auto Scaling 그룹은 필요에 따라 EC2 인스턴스 수를 조절한다. ALB는 등록된 대상들로 요청을 보낸다. 여기까지는 요청을 어느 서버가 처리할지의 문제다. 이미 실행 중인 서버에서 새로 쓴 글을 다른 서버의 DB로 복사하는 기능은 아니다.
예를 들어 EC2 A와 B에 워드프레스와 MySQL을 각각 설치했다고 하자. A에서 ID 7번 글을 쓰면 A의 DB에는 글이 있고 B의 DB에는 없다. 다음 요청이 A로 가면 보이고 B로 가면 보이지 않는다. 두 인스턴스가 모두 healthy여도 이 차이는 남는다. 헬스 체크는 지정한 경로의 응답을 확인하지, 두 DB의 글 목록을 비교하지 않기 때문이다.
AMI로 같은 서버 구성을 시작하더라도 생성 시점의 구성과 그 뒤에 각 서버에서 바뀌는 데이터는 다르다. 이미지를 한 번 더 만들어 배포하는 방식으로는 계속 발생하는 글쓰기 차이를 해결할 수 없다.
어느 EC2의 DB에 글이 있는지 어떻게 확인할까?
먼저 ALB 대상 그룹에 등록된 워드프레스 인스턴스가 둘 이상이고, 모두 트래픽을 받을 수 있는 상태인지 본다. 그다음 각 인스턴스에서 워드프레스가 연결하는 DB 호스트를 확인한다. A는 자기 로컬 MySQL, B는 B의 로컬 MySQL을 가리킨다면 서로 다른 저장소다. 연결 설정을 확인할 때 비밀번호나 접속 문자열 전체를 화면·로그에 남기지는 말자.
읽기 전용으로 같은 글을 조회해 보면 차이가 더 분명하다. 테이블 접두사는 설치마다 다르므로 아래 wp_posts는 실제 접두사에 맞춰 바꾼다.
SELECT ID, post_title
FROM wp_posts
WHERE ID = 7;| 조회 위치 | ID 7번 글 |
|---|---|
| EC2 A의 로컬 DB | 배포 점검 |
| EC2 B의 로컬 DB | 없음 |
이 표는 원리를 보여 주는 예시 데이터다. 실제 AWS 계정에서 나온 결과로 오해하면 안 된다. 두 DB에 같은 조회를 했는데 결과가 다르다면 ALB가 글을 지웠다기보다 서로 다른 DB를 번갈아 읽는지 먼저 확인할 근거가 된다. 반대로 두 서버가 처음부터 같은 DB를 바라본다면 캐시나 다른 저장 위치를 살펴야 한다.
공유 DB로 바꾸면 무엇이 해결되고 무엇은 남을까?
두 워드프레스 인스턴스의 DB 연결을 하나의 외부 MySQL로 모으면, 어느 EC2가 요청을 받아도 같은 글 데이터를 조회한다. Amazon RDS 같은 별도 DB가 한 선택지다. 핵심은 제품 이름보다 두 앱이 같은 저장소를 읽고 쓴다는 사실이다.
기존 로컬 DB가 둘이라면 연결 주소만 바꾸고 끝낼 수는 없다. 어느 데이터를 기준으로 옮길지 정하고 백업한 뒤, 쓰기 중단 또는 전환 절차를 거쳐 새 DB를 확인해야 한다. 양쪽에서 서로 다른 글이 이미 작성됐다면 단순 복사로 덮어쓰지 말고 충돌을 먼저 정리한다. 운영 중이라면 이 과정이 그림 한 장보다 훨씬 중요하다.
또 공유 DB는 글 데이터의 위치를 맞추는 해결책이다. EC2 디스크에만 저장한 업로드 파일이나 각 서버 메모리에 둔 세션까지 자동으로 공유되지는 않는다. 글은 보이는데 첨부 이미지가 한쪽에서만 보인다면 저장 경계를 다시 나눠 확인해야 한다.
핵심 요약
Auto Scaling은 서버 수를 조절하고 ALB는 요청을 분산한다. 둘 중 어느 것도 EC2별 로컬 MySQL의 새 글을 자동 동기화하지 않는다. 글이 새로고침마다 달라진다면 대상 상태를 확인한 뒤 각 인스턴스의 DB 연결과 같은 글의 조회 결과를 비교하자. 두 앱을 공유 DB로 옮길 때는 기존 데이터 충돌과 업로드 파일처럼 DB 밖에 남은 상태도 함께 점검해야 한다.
