Part 3에서는 AWS 특정 리전의 서비스가 중단된다는 가정 하에 진행하며, 장애 상황으로는 EC2 및 MySQL의 접근 불가를 설정하였습니다.
이후, Route 53을 활용한 자동 Failover가 되는 것을 확인하고,
DR 상황에서의 RTO(복구 시간 목표)와 RPO(복구 시점 목표)를 측정하여 본 글을 마무리하도록 하겠습니다.
글은 아래 순서로 진행됩니다.
1. Route 53 Failover 설정
2. DR 테스트 계획
3. DR 테스트 수행 및 결과 확인
1. Route 53 Failover 설정
DR 테스트 시에는 AWS의 특정 리전이 장애상황이라고 가정할 예정으로 AWS Global 장애는 아니므로 Route 53을 통한 장애조치 시나리오를 구성할 예정이므로 Route 53의 장애조치 설정을 알아보겠습니다.현재 외부(Cafe24)에서 구매한 도메인의 네임서버는 Route53의 네임서버로 설정되어있습니다.
Route 53의 "상태 검사"와 "트래픽 정책"을 통해 아래와 같이 장애조치 설정을 구성할 수 있습니다.
상태 검사
- 도메인 이름으로 하며, ALB의 이름을 넣습니다.
- 경로는 index.html이나 다른 것도 상관 없으나, 여기서는 select.jsp라는 것을 사용합니다.
- 조금 더 빠르게 장애상황을 체크 할 수 있도록 요청 간격을 10초(1초에 1번 확인), 실패 임계값을 1로 설정합니다.
트래픽 정책
- 기본 : 위에서 생성한 상태 검사를 선택하고, 엔드포인트로는 AWS의 ALB를 선택합니다.
- 보조 : 보조의 상태검사는 별도로 하지 않으며, 엔드포인트는 Azure의 Application Gateway의 Public IP를 넣습니다.
해당 생성 이후 "정책 레코드를 생성하여 호스팅 영역에 추가합니다.
"Applied"가 되면 정상적인 상태이므로 호스팅 영역에도 아래와 같이 잘 표시가 되면 설정은 완료되었습니다.
도메인(yamistudy.store)를 nslookup 하였을 때 AWS ALB의 IP와 동일한 것을 호출하는 것을 확인 할 수 있습니다.
Route 53에서 Azure로 잘 전환이 되는지 확인하기 위해서는 EC2를 모두 종료 또는 Tomcat을 중지시키면 간단하게 확인 할 수 있습니다.
2. DR 테스트 계획
DR 테스트는 아래와 같이 진행할 계획을 수립하였습니다.
-
서비스 정상 확인
-
지속적인 데이터 삽입 / Insert.jsp 호출하는 Script 실행(로컬)
-
웹 서비스 호출 / Curl yamistudy.store/select.jsp 호출(로컬)
-
DB Replication 확인 / show slave status(Slave : Azure Mysql)
-
-
DR 선언
-
서비스 중지(AWS EC2의 Tomcat 중지)
-
-
RTO, RPO 확인
-
RPO : 데이터 중 test_data 컬럼의 AWS -> Azure로의 변경된 시점의 시간차이 확인
-
RTO : 200OK에서 Fail 이후 첫 200 OK 시간 확인.
-
-
원복
-
AWS 서비스 기동(AWS EC2의 Tomcat 실행)
-
원복 확인
-
-
종료
서비스 정상 확인을 위한 스크립트는 아래와 같습니다.
아래 코드는 insert.jsp로 ROOT 하위에 생성하였으며, 구분을 짓기 위해 AWS EC2 1, 2 / Azure VM 1, 2 삽입하는 데이터명이 다르게 구성하였습니다.
유의할 점은 DB URL부분에 AWS에는 RDS의 URL을, Azure는 Mysql의 URL을 넣어야 합니다.
<%@ page import="java.sql.*" contentType="text/html;charset=utf-8"%>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>AWS - WEB02 - 10.20.156.155</title>
</head>
<body>
<h2>AWS - WEB02 - 10.20.156.155</h2>
<%
String DB_URL = "jdbc:mysql://[AWS-Azure-DB-Connection URL]/[DB명]?serverTimezone=UTC";
String DB_USER = "계정명";
String DB_PASSWORD= "패스워드";
Connection conn = null;
PreparedStatement pstmt = null;
try {
Class.forName("com.mysql.cj.jdbc.Driver");
conn = DriverManager.getConnection(DB_URL, DB_USER, DB_PASSWORD);
String sql = "INSERT INTO dr_test(test_data) VALUES ('AWS - 02')";
pstmt = conn.prepareStatement(sql);
pstmt.executeUpdate();
%>
<%
out.println("✅ MySQL Insert Success!");
} catch(Exception e){
out.println("⛔ 오류 발생: " + e.getMessage());
e.printStackTrace();
} finally {
if (pstmt != null) try { pstmt.close(); } catch (SQLException e) { e.printStackTrace(); }
if (conn != null) try { conn.close(); } catch (SQLException e) { e.printStackTrace(); }
}
%>
</body>
</html>
3. DR 테스트 수행 결과 및 확인
10:36 DR 선언-
서비스 정상 확인
-
지속적인 데이터 삽입 / Insert.jsp 호출하는 Script 실행(로컬)
-
웹 서비스 호출 / Curl yamistudy.store/select.jsp 호출(로컬)
-
DB Replication 확인 / show slave status(Slave : Azure Mysql)
-
-
DR 선언
-
서비스 중지(AWS EC2의 Tomcat 중지)
-
-
서비스 정상 및 RTO, RPO 확인
-
WEB 호출 정상 확인(Azure VM의 서비스명이 표시됨)
-
Route 53의 상태 검사 현황(AWS 비정상 / Azure 정상)
-
RPO : 33초
-
장애 발생 전 마지막 데이터 인입 시각 : 10:36:34 / AWS - 02
-
장애 복구 후 첫 데이터 인입 시각 : 10:37:07 / Azure - 02
-
-
-
RTO : 36초
-
DR 선언 전 마지막 정상 시간 : 10:36:29
-
DR 선언 후 최초 실패 시간 : 10:36:30
-
DR 선언 후 최초 정상 시간 : 10:37:06
-
-
-
원복
-
AWS 서비스 기동(AWS EC2의 Tomcat 실행)
-
원복 확인
-
29번 행부터는 AWS 서비스로 전환된 것을 확인 할 수 있습니다.
-
-
결론
- DB의 경우는 Azure로 전환된 시점 이후의 데이터는 AWS에 존재하지 않기 때문에 추후 재 복제가 필요합니다.
- Azure는 자동 장애조치를 위해서는 DNS이외에 Traffic Manager를 사용해아하지만, AWS는 Route 53에서 레코드 등록 및 장애조치가 가능합니다.
- Multi Cloud DR은 비용적으로 비쌀 수 있지만, 하나의 CSP에 종속되지 않아 더 안전한 서비스를 제공할 수 있습니다.
