핵심 설계 사항
- 웹 서버 다중화
- DB서버 다중화
- 비용 효율적 콘텐츠 배포
https://velog.io/@joshua_s/AWS-%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EC%82%AC%EC%9D%B4%ED%8A%B8-%EA%B5%AC%EC%84%B1
이 링크에 적혀있는 부분은 끝냈다고 가정한다.
ELB를 이용한 웹서버 다중화
구성방법
OS환경을 셋업하고 CMS를 인스톨 했다면 가상 AMI를 이용하여 가상서버 여러대를 셋업한다. 
AMI를 만드는 것은 인스턴스를 우클릭 후 이미지 생성한 후 내용을 입력하면 된다. 그 후 인스턴스를 생성할 때는 EC2-> 이미지 -> AMI로 이동후 생성된 AMI에 우클릭 후 시작을 누르면 된다.
이렇게하면 같은 환경을 반복해서 사용하는 경우에 작업을 간소화 할 수있다.
필요한 수의 웹서버를 만든 후 ELB를 연계하여 다중화 구성을 설정한다.
로드 밸런서 생성을 누르고 로드 밸런서를 생성한다.
이 이후에 로드벨런서를 엔드포인트로 지정하여 접속하고 라우트 53을 이용하여 ELB의 CNAME과 사용할 도메인 이름을 연결 시킨다.
후에 EC2 인스턴스와 ELB를 연결하면 끝이다.
AutoScaling을 이용하여서 ELB와 연결하는 방법역시 괜찮은 방법입니다~
ELB설정시 유의사항
1. ELB용과 웹서버용으로 각각 다른 보안 그룹을 마련해야 한다.
ELB는 어디서든지 인터넷 연결이 되게끔 HTTP, HTTPS가 설정되어 있다. 하지만 웹서버는 ELB로부터 요청만 맏아들이도록 트래픽 소스를 ELB보안그룹 한정으로 해야한다.
2. 세션 유지 기능의 유무
세션을 유지하는 기능을 이용해 복잡한 기능을 지닌 애플리케이션을 제공하는 웹사이트들이 많아졌기 때문에 웹 서버간 공유하는 구조를 마련하지 않으면 항상 같은 웹서버에 유지시켜야만 한다.
3. HTTPS처리
ELB는 SSL터미네이션을 제공하여서 SSL 인증서 확인 및 암복호화 처리기능을 제공한다 물론 ACM을 이용하여 아마존에서 인증서를 설치하여서 Route 53과 연결하는 방법도 있다.
4. 웹 서버의 정상동작 감시
헬스 체크를 이용해 부하가 걸리지 않은 정도로 설정하여 정상동작을 확인한다. 보통은 기본 설정값으로도 충분하지만 시험이나 운영시에 검출 오작동이 발생한다면 수치를 조절해야한다.
5. 타임아웃 설정
웹서버에 분산시킨 후 일정한 시간 응답이 없으면 ELB를 절단 HTTP504를 반환하는 작업이다. 오래 걸리더라도 응답을 보고싶으면 응답시간을 길게 설정하면 된다.
RDS를 이용한 DB 다중화
RDS 구성방법
RDS를 구성하는 방법은 총 2가지이다. 하나는 EC2인스턴스에 RDBMS를 설치하는 방법과 아마존 RDS를 이용하는 방법이 있다. EC2인스턴스를 이용하면 자유롭게 OS와 RDBMS를 선택, 설정할 수 있다. 하지만 직접 관리를 해야한다. RDS를 이용하면 패치와 백업이 자동화 되어 있어 운영의 번거로움이 줄어든다. 하지만 OS에 접속할 수 없는등 단점이 존재한다. 이용목적에 따라 선택을 해야한다.
Amazon RDS를 이용한 다중화 방법
VPC를 하나 만들고 VPC속에 두개의 서브넷을 만들면 된다.
이제 RDS 설정 화면에서 DB 서브넷 그룹을 작성한다. DB의 서브넷은 두 가용영역에 각각 만들어야 하고 이것을 그룹화 한다.
RDS를 구성하기 위해 데이터 베이스 생성을 클릭하여 원하는 DB를 선택한다. 그 후 대기 인스턴스를 On시키면 다른 가용영역에 인스턴스가 생성된다.
이후에 VPC에서 만들어둔 DB 서브넷 그룹을 이용하면 된다.
이후에 보안 그룹을 설정하면 끝이다.
이렇게하면 마스터와 스탠바이 2대가 동시작동 하기 때문에 이중화 구성을 하지 않은 경우의 2배의 금액이 발생하게된다. 하지만 장애가 발생하여도 데이터가 소실되지 않는다. 또한 장애 발생시 자동으로 스탠바이가 마스터로 되고 마스터가 사용하던 서브넷에 스탠바이 서버가 새롭게 만들어진다. 별도의 작업이 필요없다. 다만 DB접속은 장애 복구 이후에 자동으로 연결되도록 사전에 설정해야한다.
RDS 사용시 유의사항
1. 적절한 스냅샷 생성
RDS는 자동백업과 수동 스냅샷 백업 방법을 지원합니다. 자동 백업은 간단하지만 1~35일의 데이터 보존기간이 있습니다. 영구적으로 저장하려면 스냅샷을 이용하여 복구용으로 만들어 두는 것이 좋습니다.
2.AWS 메인터넌스
RDS는 몇달에 한번꼴로 마이너 버전업이 자동실행되어 30분간 정지한다. 자동 업그레이드를 No로 설정하면 버전업이 수행되지 않는다. 하지만 취약점 대응으로 인한 강제 업그레이드가 이루어지는 경우가 있다. 메니지먼트 콘솔에서 RDS 메인 터넌스를 실시하는 시간대를 제한할 수 있다
기본적으로 스탠바이가 먼저 메인터넌스가 된후
마스터가 메인터넌스가 된다.
3. 멀티-AZ를 이용히 갱신 처리에 시간이 길어진다
마스터에 업데이트한 데이터를 스텐바이에 동기화 시키는 처리의 시간이 소요된다. 이경우 마스터는 다음 처리를 실시할 수 없다. 영향을 받는 것은 업데이트 처리뿐이므로 그다지 문제가 되지는 않는다.
정적 콘텐츠 배포
방문자가 많은 정적 콘텐츠 제공에는 많은 비용이 들게 된다. 대량의 트래픽을 처리하려면 고성능의 웹 서버가 필요하다. 이것을 EC2를 이용하면 다운로드 통신량에 따라 종량 과금이 부과된다. 이런 정적 콘텐츠 전달비용을 줄이려면 CloudFront와 S3를 사용하면 된다.
CloudFront는 세계 각지에 배치된 서버에 콘텐츠를 캐시하고 전달한다. 캐시에 히트한 경우 웹서버와 DB에 접속하지 않으므로 서버의 부하를 낮춰 운영 비용을 줄일 수 있다.
사용방법
ex) index.html을 참조한다.
개발자는 배포할 컨텐츠에 대해 index.html의 URL 설정에서 클라우드 프론트 도메인을 지정한다. 이렇게하면 브라우저는 클라우드 프론트에서 컨텐츠를 가져온다. 클라우드 프론트에 캐시되지 않은경우 오리지널 ELB로 가지러간다. 액세스한 데이터는 클라우드 프론트에 캐시된다. 이후 같은 컨텐츠는 클라우드 프론트가 캐시된 컨텐츠를 배포한다.
이후에 정적 컨텐츠는 S3에 저장한다. S3에 파일을 저장하면 파일 단위 접속용 URL이 성선되는데 이것을 이용해 정적 컨텐츠 저장소로 사용한다. 이후 클라우드 프론트의 참조 분리 기능을 이용하여 동적 컨텐츠는 ELB, 정적 컨텐츠는 S3에서 가져올 수 있도록 한다.
주의 사항
1. URL 와일드 카드를 지정하여 정적 컨텐츠와 동적 컨텐츠를 구별할 수 있어야한다.
2. CloudFront 사용시 컨텐츠의 디렉터리 구성과 파일 네이밍 규칙도 함께 고려해야한다.
