🖥 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델
✏️ '서버리스' 용어 그대로 서버가 없는 것을 의미하는 것은 아니다.
단지 인프라 관리 작업을 클라우드에게 위임함으로써 서버를 고려하지 않고 서비스를 개발할 수 있도록 해주는 아키텍쳐이다.
🔖 용어 정리
서버
서버와 웹 서버
서버도 컴퓨터! 클라이언트에게 네트워크를 통해 정보와 서비스를 제공하는 컴퓨터
처음에 서버 라는 단어를 들었을때 왠지모르게 거창하게 들렸지만, 서버 도 컴퓨터 이다. 단지 서버로서의 기능을 하는 컴퓨터 일뿐이다. 우리가 컴퓨터를 사용할때는 주로 다른 서비스 회사들의 서버 로 부터 정보를 받는 클라이언트 의 입장에서 사용하기 때문에 서버 라는 의미가 크게 와닿지 않았던 것 같다.
그렇다면 웹 서버 의 의미도 자연스럽게 생각할 수 있다. 웹 서버 는 웹 서비스를 제공해주는 컴퓨터 이다. 웹 서비스 를 위해서는 무엇이 필요한지 생각해보면 된다. 우선 사용자에게 보여줄 페이지 이미지 등의 HTML/CSS/JS .png .jpg 와 같은 정적 파일들이 필요할거고, 사용자의 요청을 처리할 수 있는 Flask Spring 등의 웹 프레임워크 로 작성된 application.py Application.java 와 같은 웹 애플리케이션 이 필요할 것이다. 이렇게 웹 서비스 에 필요한 리소스들이 존재하고 웹 애플리케이션 이 실행되는 컴퓨터가 웹 서버 이다.
웹 서버 소프트웨어
가장 많이 사용되는 웹 서버 로는 Nginx Apache HTTP Server 가 있다. 분명 앞에서 웹 서버 도 하나의 컴퓨터라고 했는데, 웹 서버 를 구축하기 위해서는 왜 Nginx Apache 와 같은 프로그램을 추가적으로 설치해야할까? Flask 애플리케이션과 페이지 이미지 파일 들만 있어도 클라이언트에게 서비스를 제공하고 요청을 처리하는데 어려움이 없는데 말이다🤔
혼란을 피하기 위해 Nginx Apache 를 정확히 말하면, 이들은 웹 서버웹 서버 소프트웨어 로 웹 서버에 설치되는 소프트웨어다. 이런 소프트웨어를 설치하는 이유는 서버로 오는 클라이언트의 요청을 효과적으로 분배 하기 위해서다. Flask Spring 으로 작성된 웹 애플리케이션 에는 실질적으로 요청을 처리 하는 로직들이 구현되어 있고 실행을 통해 클라이언트의 요청을 처리한다. Nginx Apache 와 같은 웹 서버 소프트웨어 는 다수의 클라이언트로부터 서버로 들어오는 요청을 처리할 수 있도록 요청을 분산 시켜주는 역할을 한다. 지금이야 실제로 서비스 되고 있는 웹 애플리케이션이 아니기 때문에 웹 서버 에 정적 파일 들을 올려두고 웹 애플리케이션 을 실행시켜 접속하는 것이 문제될 것이 없지만, 다수의 클라이언트들이 사용하는 서비스라면 많은 요청 에 대한 부담이 클 것이다. 따라서 웹 서버 에 웹 서버 소프트웨어 를 설치하여 서버로 들어오는 요청들을 처리하고 관리한다.
웹 서버 구축
🔨 웹 서버 구축 과정 (Nginx)
[1] 웹 서버로 사용할 EC2 인스턴스 생성
[2] Nginx 설치
[3] index.html 파일 업로드
[4] Nginx 설정 파일 확인
├── /etc/nginx/nginx.conf
└── /etc/nginx/sites-enabled/default
[5] 도메인 구매
└── DNS 설정: EC2 인스턴스의 IP 입력
[6] Nginx 에 도메인 설정
└── /etc/nginx/conf.d/www.conf 파일 생성
[7] HTTPS 프로토콜을 위한 SSL 인증서 발급
├── 인증서 발급 기관을 통해 발급
└── BARISIGN / * Let's Encrypt
[8] 인증서 설치
├── 인증서 설치 환경 만들기 (Certbot 사이트 가이드 문서 참고)
├── 인증서 설치
└── 설치 후 Nginx 설정 파일 변경 사항 확인하기
└── /etc/nginx/conf.d/www.conf 에 ssl_certificate 내용 추가됨 확인이렇게 정리해놓으니 절차가 그리 많지 않다고 느껴지지만 그건 기분 탓이다🤯 직접 EC2 라는 클라우드 컴퓨터 를 만들고, 웹 서버 소프트웨어를 설치 하고 SSL 을 발급받기 위해 가이드라인을 뒤져보고.. 중간중간 설정 파일들과 출력 결과를 확인해야 하는 일은 덤! 생각보다 손이 정~말 많이 간다. 이런 작업들이 숙달된 개발자라면 직접 서버를 구축하는데 어려움이 없겠지만, 서버를 처음 구축해보는 개발자들은..🤪 기능 구현하기도 바쁜데 배포를 위한 서버의 설정들까지 하나하나 신경써야 하는게 어려울 것이다. 그래서 나온것이 서버리스 모델이다.
서버리스
서버리스 아키텍처를 구축하기 위해 사용하는 서비스와 구축 과정을 정리했다. 나는 배포할때 EC2 또는 EB 환경 에 정적 파일 들과 웹 애플리케이션 을 모두 올려뒀었다. 하지만 클라우드 컴퓨팅 기술이 도래하면서 인프라 서비스들이 분리됐고, 이런 변화에 맞춰 맞춰 배포 환경을 MSA 방식으로 구축하는 추세이다. 따라서 프론트엔드 와 백엔드 을 분리해서 개발하고 배포함으로써 결합도를 줄이고 각각의 관리를 수월하게 할 수 있도록 하는게 트랜드이다. 그래서 이번 실습에서도 프론트엔드 와 백엔드 각각 서버리스 모델을 만드는 과정을 진행한다.
🌱 사용 서비스
S3
정의 클라우드 저장소 정적 웹 호스팅
사용 이유
웹 서비스에 필요한 정적 페이지들을 업로드할 수 있고, 정적 웹 호스팅 기능을 통해 클라이언트에게 페이지를 전달할 수 있다.
CloudFront
정의 글로벌 콘텐츠 전송 네트워크 S3의 내용을 세계에 분포되있는 엣지 서버에 캐싱
근접한 엣지 서버에 콘텐츠 요청
사용 이유
-
특정 리전에 위치한 S3에는 전세계 사람들이 접근할 수 없으므로, S3의 내용을 글로벌 리전에 위치한 엣지 서버들로 캐싱함으로써 사용자들의 접근성을 높이고 빠른 속도로 콘텐츠를 제공한다. -
CloudFront를 사용하면 WAF 기능을 사용 가능하다. ElasticBeanstalk 에서도 WAF를 사용하기 위해 앞단에 CloudFront를 놓고 사용한다. -
S3는 콘텐츠를 요청하는 건수당 요금이 부과되지만 CloudFront는 무료다.
Certificate Manager
정의 SSL/TLS 인증서 프로비저닝, 관리, 배포 서비스
사용 이유
도메인에 대한 HTTPS 인증서를 생성해준다.사설 기관에서의 인증서 발급은 비용이 부담된다.
WAF
정의 웹 애플리케이션 방화벽
사용 이유
DDos, SQL Injection 과 같은 웹 보안 공격을 예방할 수 있다.
Route 53
정의 DNS 서비스
사용 이유
AWS 인프라 구축 시에는 도메인을 발급받은 기관의 네임서버를 사용하는 것 보다 AWS의 네임서버를 사용함으로써 통일성을 유지할 수 있고, DNS에 정보를 변경하고 로드하는 속도가 더 빠르다.
🕸 서버리스 프론트엔드 구성도
🔨 서버리스 프론트 구축 과정
[1] S3 생성
├── 파일(index.html) 업로드
├── 버킷 엑세스 권한 퍼블릭 설정
├── 객체 엑세스 권한 '모든 사람 읽기' 허용
└── 객체 URL 확인
[2] S3 정적 웹 사이트 호스팅 기능 활성화
└── 버킷 웹 사이트 엔드포인트 URL 확인
[3] CloudFront 생성
├── Origin domain: S3 endpoint
└── Default root object: index.html
[4] Certificate Manager 에서 SSL/TLS 인증서 발급
└── 발급 완료 후, CloudFront 에서 CNAME & 발급된 인증서 설정
[5] WAF 생성
├── Resource type: CloudFront distributions
├── Add AWS resources: CloudFront
└── Configure metrics: Enabled sampled requests
[6] IP 차단 룰 추가 (Block rule)
├── IP sets 생성
├── WAF > Web ACLs > Rules > Add rules(Add my own rules and rule groups)
└── Rule type: IP set
[7] SQL 인젝션 룰 추가 (Block rule)
├── WAF > Web ACLs > Rules > Add rules(Add my own rules and rule groups)
├── Rule type: Rule builder
└── Statement
├── Inspect: All query parameters
├── Match type: Contains SQL injection attacks
└── Text transformation: URL decode, Lowercase
[8] Route53 생성 - DNS 이전, from 가비아 to Route53
├── 호스팅 영역 생성
├── 도메인 이름: abc.com
└── 유형: 퍼블릭 호스팅 영역
[9] 가비아 네임서버 설정
├── 도메인 관리 툴
└── 네임서버 설정: Route53의 4개의 NS 주소 입력 (맨 뒤의 . 제거)
[10] Route53 레코드 추가
├── 레코드 이름: www.abc.com
├── 레코드 유형: CNAME
└── 값: CloudFront 도메인 이름참고문서
📌 Apache vs Nginx 어떤 서버가 적합한지 비교 설명 - 웹인스토리
