-
SSL
MongoDB Atlas 를 사용하다가 DocumentDB로 서버를 옮길 때 가장 처음으로 부딪힌 벽이에요. 갑자기 SSL Certification 을 다운받아서 접속하라고 하니 조금 당황스러웠지만 설정을 조금 바꿔주니 바로 접속됐어요. -
SSH
DocumentDB 는 AWS 인프라 내부에서만 접근할 수 있게 설정이 되어 있었어요. 이 문제를 해결하려면, EC2 인스턴스를 하나 켜고, SSH Tunneling을 한 다음, 그 네트워크 채널로 DocumentDB 에 접속해야 해요. 실제 배포한 뒤에는 별 문제가 없지만, 개발자들이 접근하기에 조금 귀찮은 점이 있어서 처음에는 불편했지만, 보안성 하나는 보장해주니 인프라 관리자 입장으로써 리스크를 감소시켜주는 부분이기에 오히려 좋은 기능이라고 생각해요. -
retryWrites=false
이 문제가 가장 당황스러웠어요. 서버에 배포를 정상적으로 하고, 테스트 코드들을 모두 돌려 (이 테스트 코드를 비용 문제로 인해 MongoDB Atlas에서 돌렸는데, 이 것이 나중에 돌이킬 수 없을뻔한 스노우볼로 굴러옵니다) 개발 서버에 배포하고, 개발서버에서 작동이 잘 되는 것을 확인 한 후에 프로덕션에 배포하고, 어드민페이지에서 요청하는 순간...retryable writes are not supported. set retryWrites=false ...
갑자기 이상한 버그가 생겼어요..!
일단 키워드로 검색해보니, mongoDB connection string 에 retryWrites=false로 설정해주면 해결된다는 것을 보고 설정해 주었지만, 그대로였어요. 한 시간 가량 여러 설정을 만져보다가, 공식 문서를 정독해보기로 했어요.
결국 이 문제는, 한 개의 인스턴스에만 특정 쿼리 보냄으로써 발생하는 문제였어요. (보통 수정쪽이 문제가 되었습니다) 그래서 모든 레플리카 세트에 요청을 보낼 수 있게 레플리카 세트를 설정해주니 그제서야 정상 작동을 했어요.replicaSet=rs0&readPreference=secondaryPreferred&retryWrites=false
이 이슈로 인해 느낀 점이 정말 많아요. 왜 많은 실 서비스들에서 dev 서버 stage 서버, prod 서버의 environment를 통일 시키는지 (사실 정말 당연한 거죠..ㅠㅠ) 다시 한번 뼈저리게 느꼈고요. 다음에는 왠만한 상황에서는 개발서버와 프로덕션 서버의 환경을 통일 시켜야겠다고, 그렇지 못하면 검증된 메서드들을 사용하자고 다짐했어요!
-
Cost problems
AWS DocumentDB 가 생각보다 비싸더라고요. 제일 싼 인스턴스가 t2.medium 이었던 것 같은데, 인스턴스 하나만 돌려도 한 달에 10만원정도 유지비용이 들어서 조금 부담스러웠어요.
총론
저는 항상 새로운 것을 좋아해요. 이번에도 여러 새로운 기능들을 사용해보며 시행착오들을 겪었는데, 힘들기 보단 새로운 것에 도전한다는 마음에 오히려 설렘이 가득했던 것 같아요. 앞으로는 절대 깨지면 안되는 방패와도 같은 인프라의 관리자로써 책임감과 철저함을 더욱 챙겨보기로 했어요. 결국 인프라의 꽃은, 다운타임 "0" 를 기록하는 것이니까요. 보이지 않는 곳에서 조용히.
