서버를 다루는 일은 초보 개발자에게 여간 신경 쓰이는 일이 아니다. 리눅스 시스템을 만지는 것만으로 어색한 감이 있는데 한 번의 명령어 실수로 실서비스가 중단되거나 실서비스의 데이터를 날려버릴 수 있는 어마어마한 위험을 감수해야 하기 때문이다. 사실 고급(?) 개발자들도 실제 서비스가 구동되고 있는 서버에 작업을 할 때는 비슷한 감정을 가지지 않을까도 생각해본다. 물론 그들의 고급 방식을 이용함으로써 감당해야 할 위험은 초보들의 그것보다는 낮겠지만 말이다.
썰타임은 7월에 대형 서버를 마련했다. 꾸준히 들어오는 평범한 트래픽에 대비한 것이라기보다 순간순간 폭주하는 이용자들의 편의를 고려한 결정이었다. 새 서버를 마련했으니 당연히 서버를 이전해야 했다. 예전부터 데이터베이스 서버를 따로 두지 않았기 때문에 이번 기회에 데이터베이스 서버를 파일 서버와 분리하기로 했다. 따라서 데이터베이스에 대해선 마땅히 추가 작업이 필요하지 않았다.
문제는 파일 서버였다. 근처에 문의를 해본 결과 NFS 마운트(mount)라는 기능을 사용하면 두 서버의 파일을 동기화할 수 있다는 결론을 얻을 수 있었다. 구서버는 CentOS 5의 최신 버전(아마 .10쯤 되었던 것 같다.)을 쓰고 있었고 새 서버는 Ubuntu 12.04를 사용하고 있었기 때문에 NFS 설치법이 조금 달랐다. CentOS 5의 경우 HowtoForge의 《Setting Up An NFS Server And Client On CentOS 5.5》를 참고했고 Ubuntu 12.04의 경우 DigitalOcean의 《How To Set Up an NFS Mount on Ubuntu 12.04》를 참고했다.
생각보다 단순한 작업이었고 양 서버에서 설정했던 디렉토리가 서로 동기화를 맞추면서 무리없이 돌아가고 있는 것 같았다. 그러나 NFS 클라이언트에서 파일 쓰기를 하려고 하니 권한이 없다는 메시지가 자꾸 떴다. 루트(root) 계정으로는 문제가 없었다. 그래서 구글링을 했다.
문제는 서로 다른 계열의 리눅스 OS를 사용할 때 UID와 GID의 기본 설정이 호환이 되지 않는 것이었다. OpenUse의 《NFS mounts, UIDs and GIDs mismatches》 스레드를 참고해서 문제를 해결할 수 있었다.
마지막으로 도메인의 DNS 설정을 바꿨다. 이미 두 서버에서 동일한 DB와 동일한 파일 구조에서 애플리케이션이 구동되고 있으므로 DNS가 어느 서버를 가리키고 있든지 사용자가 서버 이전을 체감할 여유는 없었다. 사실은 DNS 설정을 한 번 잘못하는 바람에 1시간 정도 접속이 안 되긴 했다. 그래도 그 정도면 선방했다. 고 생각한다.
'CODE' 카테고리의 다른 글
워드프레스를 재설치할 때는 꼭 기존의 데이터베이스를 날려주자 (0) | 2014.10.31 |
---|---|
nginx 프록시 사용시 URI 파라미터 그대로 넘기기 (0) | 2014.10.30 |
PHP file_get_contents에서 올바르지 못한 HTTP response 무시하고 response 받기 (0) | 2014.10.29 |
모바일 앱 서버에서 페이스북 그래프 API를 사용해 사용자 인증하기 (0) | 2014.10.13 |
Laravel과 Intervention을 연동할 때 Intervention 설치하는 방법 (0) | 2014.09.21 |
파이썬, 학교에서 자바를 제치다 (0) | 2014.07.21 |
Ubuntu 12.04에서 LEMP(Linux, nginx, MySQL, PHP) 설정 무난하게 갖추기 (0) | 2014.07.17 |
와이파이(WiFi)에는 아무런 뜻도 없다 (0) | 2014.06.24 |
1970년부터 2012년까지 여성에게 수여된 전공별 학사 학위 비율 (0) | 2014.06.17 |
Angular.js에서 fade-in, fade-out 트랜지션 애니메이션 설정시 position: absolute 하지 않아도 되는 꿀팁 (0) | 2014.05.30 |