"클라우드를 이용한 데이터 마이그레이션" 프로젝트를 진행할 때 가장 중요한 핵심 기술은 aws의 dms였다.
dms는 "Data Migration Service"의 약자로, 주로 기업들이 데이터의 가용성과 확장성을 위해
클라우드로 이주시킬 때 사용된다.
구글링을 하다 보면 EC2 -> RDS로의 마이그레이션이 가장 많았는데,
우리는 이것 뿐만 아니라 완전한 on-premise 환경에서 RDS로의 마이그레이션을 구현해 보고 싶었다.
dms를 수행하기 위해서는 출발지와 목적지 서버에 접근하기 위한
Source Endpoint와 Target Endpoint를 생성해야 한다.
EC2에서의 마이그레이션은 참고 자료가 많기도 했고,
같은 aws에서 제공하는 서비스이므로 큰 어려움 없이 성공할 수 있었다.
그런데 on-premise(Window, Ubuntu)에서의 마이그레이션은
Endpoint를 만드는 과정에서 문제가 발생했다.
방화벽도 해제하고 3306(MySQL) 포트도 열린 것을 확인했지만,
계속해서 서버를 찾을 수 없다는 오류가 발생했다.
문제를 파악하기 위해 처음부터 다시 시도해보기도 하고 여러 번 검토를 해보았으나,
동일한 방식에서 EC2로의 Endpoint 생성은 성공했기 때문에 생성 방법 자체에는 문제가 없다고 생각했다.
그렇다면 어떤 하나의 차이점이 두 환경에서의 Endpoint 생성 성공 여부를 갈랐는지
생각해 볼 필요가 있었고, 결국 ip 접근 방식에 문제가 있었다는 것을 알게 되었다.
우선 EC2는 aws 내부에서 public ip를 부여받기 때문에
외부에서 접근하는데 아무 문제가 없었다.
하지만 on-premise 환경은 공유기를 한 번 거치는 과정에서 서버의 public ip가 private ip로 변환되기 때문에,
ipconfig나 ifconfig로 나오는 192.xxx... ip는 아무 소용이 없는 것이었다.
생각해보면 정말 단순한 문제였는데, 이걸로 며칠을 머리싸맨 게 좀 허무했다,,,,,,,,ㅎ
결론은 공유기의 포트포워딩을 해주면 해결되는 일이었다.
현재 private ip의 특정 포트를 포워딩해주면 내 on-premise 서버의 public ip를 확인할 수 있고,
이 ip로 Endpoint를 생성하면 미리 포워딩해두었던 private ip의 포트로 연결 되어
서버의 위치를 확인할 수 있게 된다.
다만 이 방식은 여러 번거로움이 있었다.
먼저 공유기의 설정을 직접 바꿀 수 없는 상황이라면 아무것도 진행할 수 없다.
프로젝트 회의를 주로 학교에서 진행했는데, 학교 공유기는 통신사도 알 수 없고
함부로 건드릴 수 없어 역할을 분담해 각자 집에서 진행해야 했다.
또한 private ip는 동적으로 할당되기 때문에, 한 번 포트포워딩을 해두었던
공유기와 연결이 끊겼다가 다시 연결되면 private ip 주소가 변경되어
포트포워딩을 매번 새로 해야 하는 번거로움이 있었다.
결론적으로 이 문제를 해결하면서 전공에서 배웠던 네트워크 지식을 좀 더 깊게 이해하게 되었고
클라우드 서버(EC2)의 편리함과 소중함도 더욱 깨닫게 되었다!