본문 바로가기

분류 전체보기

(345)
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..
Deep Health Check 패턴 - 시스템 상태 확인 ㅁ 풀어야 할 문제 로드 밸런서의 상태 확인 기능을 이용하면 로드 밸런서에 연결되어 있는 서버의 상태를 확인하고 처리를 분배할 수 있음 웹 서버, 프락시 서버, AP 서버, DB 서버의 구성에서 웹 서버 앞에 로드 밸런서가 있는 경우 로드 밸런서는 웹 서버의 상태를 확인하고 상태가 좋지 않은 웹 서버를 분리시킬 수 있으나 프락시 서버와 AP 서버, DB 서버 등 그 뒤에 위치하는 서버의 상태를 로드 밸런서는 파악할 수 없다. ㅁ 해결/패턴 클라우드의 로드 밸런서가 가진 상태 확인 기능을 이용해 PHP나 자바 서블릿 등의 동적 페이지(프로그램)을 확인하게 설정 그 프로그램으로 웹 서버, 프락시 서버와 AP 서버, DB 서버 등의 동작을 확인하고, 그 결과를 로드 밸런서에 넘김 ㅁ 구현 AWS의 로드밸런서 ..
Floating IP 패턴 - IP Address의 동적 이동 ㅁ 풀어야 할 문제 서버를 패치하거나 서버를 업그레이드 할 때 서버의 정비 필요함 이와 같은 서버의 정지 시간을 최소화 하기 위하여 웹 서버의 경우 DNS 구조를 이용해 서버 변경 가능하다. 하지만 그런 경우 일반적으로 TTL(Time to Live) 값보다 서버가 변경되는 시간을 짧게 할 수 없어서 즉시 변경하려는 구성에 적합하지 않음 ㅁ 해결/패턴 기존 물리 서버의 경우, 서버 정지에 대비하여 예비 서버를 준비해 놓음. 서비스용 서버가 정지한 후 예비 서버를 가동하여 (서비스용 서버의) IP Address 설정 시 서비스용 서버를 대신하여 처리가 가능 클라우드에서는 서버 이미지를 준비해두면 필요할 때 필요한 가상 서버를 가동 가능 또한 IP 어드레스를 지정하는 API도 있으므로 서버의 가동부터 IP ..
Multi-DataCenter 패턴 - 데이터 센터 레벨의 이중화 ㅁ 풀어야 할 문제 서버 장애를 고려할 때 가용성을 높이는 데 Multi-Server 패턴이 적절하지만 데이터 센터 레벨의 장애를 고려 시 Multi-Server로는 대처할 수 없다. 데이터 센터 레벨의 장애를 고려할 때 여러 곳의 데이터 센터를 이용할 필요가 있다. 그러나 충분한 거리를 둔 데이터 센터를 여러 곳 확보하고 거기에 시스템 이중화를 위해 미리 하드웨어를 구입하는 것은 규모가 큰 대기업에서도 쉬운 일은 아니다. 또 데이터 동기화나 데이터 센터가 통신을 고려해 고속 전용선을 구성할 필요가 있고 이 또한 Data Center 이중화를 방해하는 요인이다. ㅁ 해결/패턴 클라우드 서비스를 제공하는 데이터 센터는 여러 곳이 있고 각 데이터 센터간의 전용선이 구성되어 있다. 사용자마다 이용하는 데이터 ..
Multi-Server 패턴 - 서버 이중화 ㅁ 풀어야 할 문제 가용성을 높이기 위해 서버 내의 디스크 Raid를 구축하며, 네트워크 계층은 이중화 회선을 준비한다. 서버 역시, 이중화를 위해 여러 대의 물리 서버를 준비하는 방법이 있으며 이를 위해 서버 장비뿐 만 아니라 로드 밸런서 등 이중화에 필요한 기기 준비가 필요하다. ㅁ 해결/패턴 가상 서버 여러 대를 배치하고 클라우드 서비스로 제공되는 로드 밸런서를 이용해 적절히 부하를 분산(로드 밸런서)한다. 이 것을 Multi-Server라고 하며 OnPremise에서도 가능하며 많이 사용하지만 클라우드에서는 훨씬 환경을 구성하기 용이하다. ㅁ 구현 AWS의 로드 밸런스 서비스 [ELB]를 이용하여 EC2의 처리 요청을 일단 ELB에서 받고 ELB에 연결된 EC2에 적절히 처리를 분배 ELB에는 상..