infrastructure.png

개요

프로젝트를 기획하면서, 웹사이트가 완전히 개발되기 전에 미리 CI/CD 프로세스를 구축하고, Production에서의 테스트를 함께 진행하면서 개발하기 위해 프로젝트의 전반적인 인프라 구조에 대해 고민을 했다. 기본적으로, 동적 데이터가 많이 없고 동적인 기능이 크게 필요하지 않은 단순 비즈니스 마케팅 사이트였기에 지난 프로젝트들에서 호스팅했던 방식과 같이 정적 웹사이트 인프라를 구성하고자 했고, 다만 여기에 주기적인 실제 사용자가 있는 웹사이트임을 고려해서 빠른 로딩 속도를 위해 CDN을 함께 구성하고자 했다. 또한, 각 호스팅 업체에서 무료로 제공해주는 도메인이 아닌 커스텀 도메인도 필요했기에 도메인도 구매하는걸로 결정했다. 앞서 말했다싶이, 진행하는 프로젝트는 백엔드 기능이 거의 필요없는 정적 웹사이트에 가까웠지만 한 가지, 헤어살롱의 인스타그램 데이터를 가져오는 것이 필요했다. 처음에는 클라이언트에서 인스타그램 api를 연결해서 사용할까 생각했지만, 클라이언트에서는 민감한 키들이 노출되기 때문에 간단하게나마 서버리스로 백엔드 인프라를 구성하고자 했다. 이 블로그 포스팅에서는 이 과정들에 대해 기록해보려한다.

AWS 인프라

AWS 인프라 구성은 생각보다 간단했다. 기존에 S3만을 이용해 정적 웹사이트 인프라 구성을 한 적이 있기에, 여기에 도메인 구매 및 CDN 연결만하면 되는 셈이었다.

간단하게 CDN과 S3의 관계 및 동작 원리를 설명하자면, 기본적으로 CDN을 설정하면 CDN은 웹사이트 방문 유저의 지역을 고려해서 가장 가까운 CDN을 선택한다. CDN은 캐시된 객체가 있는 경우 이를 그대로 가까운 거리에서 방문자에게 제공하고, 캐시된 객체가 없으면 S3에게 웹사이트 정적 파일을 요청한다. 이때, 결국은 CDN과 S3가 데이터를 주고받는 셈이 되므로 S3 또한 방문자와 가까운 거리에 위치하는 것이 좋은 선택이 될 수 있다. 첫 방문에만 이렇게 S3로부터 가져오고 이후 부터는 캐시된 객체를 제공하여 계속해서 빠른 제공이 이루어진다. 따라서, S3 버킷의 위치를 주 사용자의 위치인 호주의 시드니로 설정하기도 했다.

도메인과 관련해서는, AWS Route 53을 이용해 2년 간의 도메인을 약 28$에 구매하였고, S3 버킷 및 CDN 배포를 각각 두 개씩 joahair.com과 www.joahair.com으로 루트 도메인, 서브 도메인을 만들어 www.~를 함께 붙여서 입력하더라도 루트 도메인으로 리다이렉트 되게끔 구성했다.

Firebase 기반 서버리스 백엔드 인프라

인스타그램 api의 토큰 및 키 등 민감한 데이터들을 안전하게 노출시키지 않고 사용하기 위해, Firebase의 Cloud Functions과 Firestore를 이용해서 서버리스 인프라를 구축했다.