본문 바로가기

AWS Design Pattern

 (46)
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 인스..
Scale Out 패턴 - 서버 수의 동적 증감 ㅁ 풀어야 할 문제 웹 서비스의 과도한 트래픽 요청을 처리하기 위해 높은 사양의 서버를 통해 처리 능력을 높이는 방법을 Scale Up이라 함, 하지만 일반적으로 높은 사양의 서버는 사양이 올라감에 따라 처리 단가가 올라가며 서버 사양에 제한이 있어 무제한으로 높은 사양으로 만들 수 없음 ㅁ 해결/패턴 같은 사양의 서버를 여러 대 배치하고 높은 트래픽 요청을 처리하는 방법을 Scale Out이라고 함 여러 대의 가상 서버를 가동하고 로드 밸런서를 이용해 각 가상 서버에 부하를 분산 시스템에 따라서 매주 또는 매일 시간 단위로 트래픽이 급격하게 증감, 따라서 클라우드에서는 그렇게 변동이 심한 트래픽 양에 맞춰 처리를 담당하는 가상 서버의 수를 동적으로 구현하는 것이 쉽다. ㅁ 구현 로드 밸런서 서비스 [E..

티스토리툴바