본문 바로가기

AWS Design Pattern

 (46)
CloudHub 패턴 - VPN 지점 설치 ㅁ 풀어야 할 문제 여러 지점 간의 VPN 접속을 풀 메쉬 토폴로지(Full Mesh Topology)형으로 구축하면, 지점이 늘어남에 따라 각 지점 VPN 라우터 설정도 복잡해지고 유지보수 비용도 늘어난다. 이 문제를 해결하기 위해 스타 토폴로지(Star Topology)형으로 VPN을 구축하면, 각 지점의 VPN 라우터는 VPN 허브에 접속만 하면 된다. 그러나 VPN 허브에 장애가 발생하면 모든 VPN 접속에 영향을 주기 때문에 VPN 허브의 가용성이 가장 중요하다. ㅁ 해결/패턴 기존 VPN 허브는 가용성을 높이기 위해 VPN에 이용하는 통신 기기를 이중화하는 등 높은 초기 비용이 들었다. 또한 VPN 접속 이용량에 상관없이 장비 유지에 대한 고정 비용이 발생하여 비용 효율이 좋지 않았다. 클라우..
Web Proxy 패턴 - 고가의 Web Application Firewall 의 효율적 활용 ㅁ 풀어야 할 문제 전자상거래 사이트 등 중요한 개인정보(신용카드 정보 등)를 사용하는 웹 사이트는 보안 강화를 위해서 WAF(Web Application Firewall)를 도입하는 경우가 있다. 그러나 클라우드 에서의 시스템은 작은 규모로 구축된 시스템이 많고, 대부분의 경우 WAF 도입은 고려하지 않는다. 또한, 스케일 아웃/인에 따른 서버의 추가 및 삭제를 고려한 시스템이 많은데, 그런 때는 필요한 라이선스 수를 알 수 없기 때문에 WAF 도입은 어렵다. ㅁ 해결/패턴 기존에는 서버 대수를 결정하고 준비하기 때문에 도입하는 WAF 대수도 정해져 있어 특별히 문제는 없었다. 그러나 시간 단위로 서버의 추가/삭제가 이루어질 수 있는 클라우드 환경에서는 그 서버에 WAF를 도입하는 것은 비현실적이고, ..
Multi Load Balancer 패턴 - 복수 로드 밸런서 설치 ㅁ 풀어야 할 문제 웹 애플리케이션을 멀티 디바이스에서 사용해야 하는 경우 PC나 휴대폰, 스마트 폰에서 액세스해야 한다. 그 때 액세스 디바이스별로 SSL이나 세션 분배 등의 설정을 해야 하는데, EC2 인스턴스 자체에 그런 설정을 하게 되면 서버가 늘어나거나 설정 변경 시의 작업이 정말 번거로워진다. ㅁ 해결/패턴 웹 애플리케이션을 호스팅하고 있는 가상 서버 그룹에 대해 설정이 다른 여러 대의 가상 로드 밸런서를 할당하여 문제를 해결 할 수 있다. 결국, 서버에 설정을 하지 않고 각 디바이스에서의 액세스를 가상 로드 밸런서를 경유하도록 변경할 수 있게 된다. 예를 들어, 세션이나 상태 확인, HTTPS 등의 설정이 그것이다. ㅁ 구현 하나의 Ec2에 여러 대의 ELB(가상 로드 밸런서)를 할당한다. ..
Operation Firewall 패턴 - 기능별 액세스 제한 ㅁ 풀어야 할 문제 대규모 시스템이 되면 개발 보수 조직이 많이 존재한다. 예를 들어, 시스템 개발을 하는 회사, 로그 분석이나 운용 감시를 하는 회사 등으로 나뉘는 경우가 이에 속한다. 방화벽 룰을 기능별 그룹으로 정의한 경우, 액세스 대상이 변경되거나 액세스 자체를 제한하려고 할 때는 그때 그때 기능별로 그룹화된 룰을 변경해야 한다. 설정에 시간도 많이 걸리고 각각의 조직이 어느 서버에 액세스 할 수 있는지를 일원적으로 관리할 수 없다. ㅁ 해결/패턴 기존 장비는 전용 장비를 이용하고 룰도 기능별로 정리하여 적용(관리)하는 경우가 많았다. 클라우드에서는 방화벽은 가상화 되어 있어 보다 유연하게 설정할 수 있다. 룰을 그룹화하고 그룹 단위로 설정하거나 서버에 적용할 수 있다. 이 그룹이라는 단위를 조직..
Functional Firewall 패턴 - 단계적 액세스 제한 ㅁ 풀어야 할 문제 방화벽을 이용한 계층적 액세스 제한은 기존 시스템에서도 통상 해왔던 보안 대책이다. 그러나 액세스 제한 룰이 많아지면 방화벽의 설정도 많아져 복잡해지고 거기에 따른 운영 비용도 높아진다. 또한 방화벽 룰의 그룹화가 불가능한 경우 유지보수도 복잡해지고 실수할 가능성도 높아진다. ㅁ 해결/패턴 기존 방화벽은 전용 장비를 사용해 그룹화하지 않고 룰을 관리하는 경우가 많았다. 그룹화가 가능하다고 해도 서버 단위로 쉽게 적용하기는 어려웠다. 클라우드에서는 방화벽에 대해서도 가상화 되어 있어 보다 유연하게 설정할 수 있게 되어 있다. 그리고 룰을 그룹화하여 그룹 단위의 설정이나 각 서버로의 적용이 가능한 것도 있다. 이 그룹 단위를 기능별(웹이 DB 등)로 하게 되면 기능에 관한 설정을 그룹 내..
Backnet - 관리용 인터넷 설치 ㅁ 풀어야 할 문제 인터넷에 게시하고 불특정 다수의 사용자가 액세스하는 서버(예를 들어, 웹 서버)는 관리 목적의 액세스도 같은 네트워크 인터페이스를 사용하는 경우가 많다. 그러나 높은 보안 레벨이 요구되는 경우, 신뢰할 수 있는 액세스와 그렇지 않은 액세스가 같은 네트워크 인터페이스를 사용하는 것은 피해야 하고 분리해야 하는 경우가 발생한다. ㅁ 해결/패턴 웹 서버에 여러 개의 네트워크 인터페이스를 설치하고 관리용과 서비스용 네트워크 인터페이스를 나누는 것은 일반적으로 시스템 구축과 관리에서 자주 사용되는 방법이다. 이 관리용 네트워크 인터페이스를 설치하는 것을 [백넷] 이라고 하고, 이것을 준비하게 되면 관리상의 네트워크 리스크를 줄일 수 있다. ㅁ 구현 VPN(가상 프라이빗 네트워크)에서는 EC2에..
OnDemand NAT - 유지보수 시 인터넷 설정 변경 ㅁ 풀어야 할 문제 보안 시스템에서는 각 서버의 인터넷 액세스(아웃바운드)를 막아두는 경우가 많다. 그런 경우 OS 패키지 업데이트 등 인터넷에 액세스가 필요한 유지보수 작업을 할 수 없게 된다. 해결 방법으로, 인터넷 접속용 NAT를 준비하여 NAT 경유로 인터넷에 액세스하게 하는 방법이 있다. 각 서버가 인터넷에 접속할 수 있는 조건을 NAT로 조정한다. 그러나 OS 패키지 업데이트 등의 유지보수 작업 기간만 NAT가 필요하고, 그 기간 이외에는 NAT 자원을 거의 사용하지 않아 자원을 낭비하게 된다. ㅁ 해결/패턴 원래 서버와 같은 장비는 영구적으로 계속 이용해야 하는 전제가 있었다. 일시적으로 이용하는 서버를 일시적 요금으로 운영한다는 것은 정말 어려운 일이었다. 그러나 클라우드의 가상 서버는 종..
Weighted Transition - 가중치 라운드 로빈 DNS적용을 이용한 이전 ㅁ 풀어야 할 문제 시스템 전부를 어떤 지역에서 다른 지역으로 이전해야 할 때가 있다. 예를 들어, 일반 데이터 센터에서 클라우드로 시스템을 이전하는 경우나 클라우드의 어떤 지역에서 다른 지역으로 이전하려고 하는 경우를 생각할 수 있다. 이럴 때는 시스템 도메인 명을 변경하지 않거나 시스템의 정지 없이, 가능하면 서비스에 영향을 주지 않고 이전을 하고 싶어하는 경우가 많다. ㅁ 해결/패턴 도메인 명을 변경하지 않고 전 시스템을 이전하려면, DNS 서버에서 웨이티드 라운드 로빈(Weighted Round Robin)이라는 기능을 이용해 도메인을 찾을 때 기존 시스템에서 새로운 시스템으로 변경하는 방법이 있다. 처음에는 새로운 시스템에 작은 비율을 할당하고, 문제가 없다면 천천히 할당 비율을 늘려갈 수 있다..

티스토리툴바