3. 서버를 만들었습니다.
● 처음엔 '당연히' 잘 동작합니다.
● 서비스 개선을 위해 서버를 수정합니다.
● 하지만 '당연히' 문제가 생깁니다.
○ 서버에서 문제를 바로 고칩니다.
○ 문제가 더 커집니다.
○ 유저가 떠납니다.
○ 아... 망했어요.
● 그래서 테스트 환경을 만드는 것이 중요합니다.
별로 설득력은 없지만...
4. 어제까지 우린...
● 테스트는 보통 다음과 같이 진행해 왔습니다.
○ 실제 서비스 환경과 같은 형태를 하나 더 만듭니다.
○ IP 주소나 도메인 네임을 바꿔 접속합니다.
■ beta.killerjoe.com 또는 설정 파일의 IP주소 수정
■ 윈도우에선 hosts 파일을 수정하기도 했죠.
○ beta에서 테스트를 진행합니다.
○ 테스트가 끝나면 실제 서버로 데이터를 복제합니다.
○ 실제 서버에 업로드하고 다시 테스트를 진행합니다.
■ 설정 파일등에 수정했던 내용을 다시 복원합니다.
■ ...심지어 클라이언트도 다시 받아야 합니다.
● 테스트 대상자가 많으면 많을 수록 잘 진행하기가 정말 어렵습니다. 그리고 무엇
보다...
6. 앞으론 이렇게.
● 서버를 지정할 때 IP 대신 도메인 네임으로
○ 왜요?
■ 도메인 네임으로 서버를 접속하게 하면 DNS 수정을 통해 테스트 환경으
로의 접속이 용이.
■ 테스트 대상이 되는 사용자에게 베타에 접속하기 위해 설정파일을 수정
해 달라느니, 별도의 배치 파일을 배포하는 등의 복잡한 절차를 없앨 수
있습니다.
■ 아이폰과 같은 기기는 베타 서버에 접속하기 위한 베타 버전 클라이언트
를 일일히 배포하는 일이 만만치 않습니다. 해보신 분은 아실 듯...
○ DNS가 안될 수도 있으니 IP 지정하는게 낫지 않나요?
■ 그 정도면 애초에 정상적인 서비스나 테스트가 안될겁니다.
7. 서버 환경 구성
Test
Real
Server #1 Server #2
MySQL
Master
MySQL
Slave
mongoDB
Master
mongoDB
Slave
Server
MySQL
mongoDB
Fake
AP
Fake DNS
AP
DNS
8. 이렇게
● Fake AP에 접속시,
○ Fake AP는 Fake DNS를 가리키고 있으므로, 해당 AP에 접속한 사용자도 Fake
DNS를 사용하게 됨.
■ 사용자 디바이스 내의 DNS cache등의 잠재적인 문제가 있을 수도 있으
나, AP를 바꿔가며 테스트 해봐도 괜찮음.
○ Fake DNS는 리얼 환경에서 사용중인 도메인에 대해 전부 테스트 환경의 서버
를 가리키도록 설정되어 있음.
■ 서버들도 도메인 네임을 통해 DB 및 기타 서버를 가리키게 해야 구성하기
가 용이함.
9. 결론
● 실제로 해보니 편합니다.
○ 아이폰/아이패드 등 설정을 변경하기 힘든 기기에서도 손쉽게 테스트 환경에
접속할 수 있어 좋습니다.
○ 테스트 대상자도 덜 귀찮습니다.
● 테스트 세트가 많아져도 부담이 적습니다.
○ Alpha / Beta / Gamma 또 뭐 있죠?
○ 아무튼 Fake AP와 Fake DNS 세트만 추가하면 끝.
○ 게다가 요즘 무선 공유기 무척 쌉니다. ( 2만원 초반대 )
● 꼭 해보세요!
