본문 바로가기

AWS Design Pattern/동적 컨텐츠 처리 패턴

 (9)
Schedule Scale Out - 스케줄에 의한 서버 증감 ㅁ 풀어야 할 문제 클라우드 환경에서 구축된 웹 서비스는 많은 트래픽 처리를 할 때 Scale Out 패턴이 효과적 그러나 부하 상태를 보고 수동으로 가상 서버를 추가하거나 가상 서버의 부하 상태에 따라 자동으로 인스턴스를 추가하거나 할 경우, 급격하게 많은 액세스 발생 시 상황에 맞춰 인스턴스를 가동하지 못할 수 있음. ㅁ 해결/패턴 순간적으로 액세스가 급증하는 타이밍을 알 경우 스케줄링 된 스케일 아웃이 효과적 Scale Out 패턴과 기본 구성은 비슷하나, 스케일 아웃하는 타이밍을 시간 지정하여 실행하는 것이 주요 특징 사전에 스케일 아웃을 완료하는 것으로 트래픽 급증에 만전의 태세로 대응할 수 있으며 직전에 스케줄링이 실행되어 불필요한 비용을 줄일 수 있다. ㅁ 구현 AWS의 AutoScaling..
Cache Proxy - 캐시 설치 ㅁ 풀어야 할 문제 높은 부하에 대한 대책으로 웹/AP 서버를 여러 대 사용하면 비용 부담이 많아짐 예산이 적을 경우 웹/AP 서버 수를 늘리지 않는 방법을 생각해야 함 ㅁ 해결/패턴 웹 시스템 성능을 높이는 대표적인 방법은 콘텐츠를 캐시화하는 방법이 있다. 이 방법은 변경이 많이 없는 정적 콘텐츠나 동적 콘텐츠를 웹/AP 서버 상위에서 캐시하여 캐시 기간이 끝날 때까지 배포 성능이 좋은 상위 캐시 서버로 콘텐츠 배포를 하는 방법 클라우드에서는 가상 서버를 쉽게 구축할 수 있어 캐시 서버가 없는 시스템에도 간단하게 도입이 가능 ㅁ 구현 EC2에 Varnish 등 많이 사용되는 캐시 서버 소프트웨어를 사용하여 캐시 서버로 사용 - 웹/AP 서버 앞에 Varnish 등의 캐시 서버 소프트웨어를 둠 - 캐시 ..
Rewrite Proxy - URL 변경 Proxy 설치 ㅁ 풀어야 할 문제 부하 대책의 하나로 정적 콘텐츠를 인터넷 스토리지나 콘텐츠 딜리버리 서비스에 올려두는 방법이 있다. 그러나 정적 콘텐츠 액세스 위치를 인터넷 스토리지로 변경해야 하고 컨텐츠 내의 URL 갱신이나 웹 서버 필터 설정 등 기존 시스템을 변경해야 함 ㅁ 해결/패턴 기존 시스템을 변경 없이 액세스 위치를 바꾸는 방법으로 프락시 서버를 사용하는 방법이 있다. 콘텐츠를 저장하고 있는 서버 앞에 프락시 서버를 두고, 정적 콘텐츠의 액세스 위치를 인터넷 스토리지나 콘텐츠 딜리버리 서비스로 변경 한다. ㅁ 구현 아파치나 Nginx 등 많이 사용되는 소프트웨어를 사용하여 프락시 서버를 구축하고 기존 시스템 앞 단에 설치한다. - ELB와 (정적 콘텐츠를 저장한) S3 사이에 Nginx 등 컨텐츠 내용을..
URL Rewriting - 정적 콘텐츠 이전 ㅁ 풀어야 할 문제 웹 서비스를 가상 서버로 제공하는 경우, 액세스 수가 많아지면 가상 서버의 수를 늘리거나 가상 서버의 사양을 올려 부하에 대응 그러나 액세스의 대부분은 정적 콘텐츠에 대한 요청이 많아 정적 컨텐츠의 액세스를 어떻게 분산시킬 것인지가 큰 문제이다. ㅁ 해결/패턴 정적 콘텐츠의 액세스 분산 방법으로 인터넷 스토리지를 이용하는 방법이 있다. 그렇게 하면 가상 서버를 증가시키거나 사양을 높이지 않아도 부하에 대한 대책을 세울 수 있다. 이 방법을 이용하려면 정적 콘텐츠의 URL을 인터넷 스토리지 URL로 변경해야 하지만 정적 콘텐츠를 직접 수정하는 방법 외에 웹 서버의 필터 기능을 이용해 배포 시 URL을 변경할 수 있다. 또 인터넷 스토리지에서 배포하는 대신 콘텐츠 배포 서버에서 콘텐츠를 ..
State Sharing - 상태 정보 공유 ㅁ 풀어야 할 문제 동적 콘텐츠를 생성할 때 사용자 고유의 상태를 가진 상태 정보(HTTP 세션 정보)를 이용하는 일이 많다. 그러나 로드 밸런서 아래 여러 대의 웹/AP 서버를 동작시킬 때 각 웹/AP 서버에 상태 정보를 가지도록 하면, 서버 장애나 서버 수를 의도적으로 줄일 때 상태 정보에 손실이 발생하는 경우가 있다. ㅁ 해결/패턴 이 패턴은 스케일 아웃 구성에서 상태 정보를 유지하기 위한 것으로 서버를 늘렸을 경우는 상태 정보 유지, 서버가 줄었을 경우는 (장애 포함) 상태 정보 손실을 방지 상태 정보를 안정성 좋은 공유 디스크 스토어(메모리/디스크)에 놓고 여러 대의 서버에서 그 정보를 참조하여 서버에 상태 정보를 가지지 않고 상태 정보 보유가 가능하다 새로운 서버가 추가되어도 공유 데이터 스토..
NFS Replica - 공유 콘텐츠 복사 ㅁ 풀어야 할 문제 NFS를 이용해 여러 대의 서버 간 파일 공유 시 공유하는 서버 수가 늘어나 액세스 빈도가 증가함에 따라 NFS 성능 저하 발생 가능 ㅁ 해결/패턴 각 서버에 가상 디스크를 개별적으로 준비하고 NFS 서버의 공유 파일을 복사해 둠 그렇게 하면 각 서버는 가상 디스크를 참조 전용 Replica로 사용할 수 있음 ㅁ 구현 각 EC2 인스턴스의 가상 디스크인 EBS에 NFS 서버의 파일을 복하. 각 EC2 인스턴스에서 EBS의 파일을 읽어오면 NFS 서버에 액세스 하는 것보다 높은 성능으로 참조 가능 - EC2에 NFS 서버를 구축하고 공유 파일을 올려둠 - Auto Scaling으로 가동하는 EC2(웹 서버)는 먼저 NFS 서버를 마운트 하고 NFS 서버 내용을 EBS에 복사 - 각 EC..
NFS Sharing - 공유 콘텐츠 이용 ㅁ 풀어야 할 문제 여러 대의 서버에 부한 분산한 경우 콘텐츠 동기화가 필요 마스터 서버에서 슬레이브 서버에 정기적으로 단방향 동기는 간단하지만, 동기화 지연이 문제가 될 수 있다. 또 슬레이브 서버에 쓰기가 발생하면 마스터 서버나 다른 슬레이브 서버에 반영되지 않는 문제가 남음 ㅁ 해결/패턴 여러 대의 서버 사이에서 실시간으로 같은 콘텐츠의 읽고 쓰기를 가능하게 함 공유 콘텐츠를 저장할 마스터 가상 서버를 NFS 서버로 하고 슬레이브 서버를 NFS 클라이언트로 함 ㅁ 구현 - NFS 서버를 EC2에 구축 - 공유해야 하는 컨텐츠를 NFS 서버에 배치 - 스케일 아웃한 서버 군에서 NFS 서버의 콘텐츠를 참조하게 함 ㅁ 장점 - 공유 콘텐츠를 NFS에 두는 것으로 실시간 동기화가 가능 - NFS를 마운트..
Clone Server 패턴 - 서버 클론 ㅁ 풀어야 할 문제 스케일 아웃 구성은 일반적인 방법이지만, 작은 규모로 만들어진 시스템은 처음부터 여러 대의 서버로 서비스 제공하도록 구성되어 있지 않음 그런 경우 부하 대책이 필요하게 되었을 때 시간이 많이 소요됨 ㅁ 해결/패턴 부하 분신이 고려되지 않은 시스템을 간단히 부하 분산이 가능한 시스템으로 변경 이미 존재하는 서버를 마스터로 하여 추가할 서버의 서버 이미지를 생성 후 서버 이미지는 콘텐츠 동기 및 데이터베이스 접속 설정을 해 둠 이렇게 하면 서버 이미지를 가동하는 것으로 스케일 아웃에 의한 부하 분산이 구현됨 ㅁ 구현 로드 밸런서 서비스 [ELB]와 서버 이미지 [AMI]를 이용 부하 분산이 가능하게 콘텐츠 동기 등을 한 클론용 AMI를 만들고, 부하가 많아지면 클론용 AMI로 EC2 인스..

티스토리툴바