Two Scoops of Django - #30장

이번장은 배포: PaaS에 대한 내용이다.

나는 현재 특정 회사의 제품을 사용 중이라 굳이 볼 필요는 없는 장일수 있으나

혹시나 AWS, Azure 등을 활용할 수도 있으니 일단 살펴보기로 한다.

 

저자는 절대 PaaS에 종속되지 않도록 할 것을 경고한다. 호스팅 제공사에 따라 구조 변경이 생길 경우 유지보수가 매우 어려울 수 있으니 특정 벤더의 가격, 약정, 기능에 매이지 않도록 주의하라고 조언한다.

 

1. PaaS 선택하기 : 다음의 조건들을 고려할 것

 - 법적 제약 : SSL, 의료정보 포함 여부, 개인정보 데이터 보호 관련 제약 확인

 - 가격 : 관리하지 않으면 비용이 엄청나게 발생할 수 있으니 주의할 것

 - 가동 시간 : 연관된 업체의 이슈로 인해 서비스가 안될 수 있음. 자연재해나 산업 사고 등에 의해서도 발생할 수 있음. 지속 가능한 서비스 구축에 유의할 것

 - PaaS 회사의 인력 배치 : 이메일이나 이슈 티켓에 대응할 전담 인력 있는지 확인 필요.

 - 스케일링 : 스케일 업이 간단하며 빠른지, 스케일 다운도 마찬가지. 그리고 스케일 업/다운 프로세스가 자동화가 가능한지

 - 문서화 : 잘 정리되고 꾸준히 관리되는 문서를 제공하는지 확인할 것

 - 성능 저하 : 잘 동작하던 프로젝트가 갑자기 느려질 경우 원인이 다양하니 꼼꼼히 찾아볼 것

 - 지리적 요건 : 네트워크 지연 이슈를 피하기 위해 서비스하는 지역을 고려할 것

 - 회사의 안정성 : 제공하는 회사 자체의 안정성을 확인해 봐야 함

 

2. PaaS로 배포하기

 - 동일한 환경을 목표로 잡을 것 : 배포의 핵심은 개발 환경과 상용 환경을 완전히 똑같이 맞추는 것.

 - 모든 것을 자동화 : 상용 인스턴스에 업데이트를 푸시할 때 모든 단계를 손수 하는 것은 절대 좋은 방법이 아니다. 그러나 난 그리하고 있지.. ㅠㅠ 저자는 이런 환경이 너무 쉽게 실수를 유발할 수 있다고 한다. Makefiles나 Fabric을 활용할 것을 추천

 - 스테이징 인스턴스 관리 : 데모 환경 및 테스트 장소인 스테이징 환경을 잘 활용할 것

 - 백업과 롤백으로 장애 대비 : 백업으로부터 데이터베이스와 사용자 업로드 파일 복구, 이전 코드 푸시로 롤백이 가능한지 확인할 것

 - 외부 백업 유지 : 혹시나 생길 수 있는 이슈를 방지하기 위해 여러 외부 서비스에 데이터를 보관하는 것을 추천