본문 바로가기

분류 전체보기

(345)
Backnet - 관리용 인터넷 설치 ㅁ 풀어야 할 문제 인터넷에 게시하고 불특정 다수의 사용자가 액세스하는 서버(예를 들어, 웹 서버)는 관리 목적의 액세스도 같은 네트워크 인터페이스를 사용하는 경우가 많다. 그러나 높은 보안 레벨이 요구되는 경우, 신뢰할 수 있는 액세스와 그렇지 않은 액세스가 같은 네트워크 인터페이스를 사용하는 것은 피해야 하고 분리해야 하는 경우가 발생한다. ㅁ 해결/패턴 웹 서버에 여러 개의 네트워크 인터페이스를 설치하고 관리용과 서비스용 네트워크 인터페이스를 나누는 것은 일반적으로 시스템 구축과 관리에서 자주 사용되는 방법이다. 이 관리용 네트워크 인터페이스를 설치하는 것을 [백넷] 이라고 하고, 이것을 준비하게 되면 관리상의 네트워크 리스크를 줄일 수 있다. ㅁ 구현 VPN(가상 프라이빗 네트워크)에서는 EC2에..
OnDemand NAT - 유지보수 시 인터넷 설정 변경 ㅁ 풀어야 할 문제 보안 시스템에서는 각 서버의 인터넷 액세스(아웃바운드)를 막아두는 경우가 많다. 그런 경우 OS 패키지 업데이트 등 인터넷에 액세스가 필요한 유지보수 작업을 할 수 없게 된다. 해결 방법으로, 인터넷 접속용 NAT를 준비하여 NAT 경유로 인터넷에 액세스하게 하는 방법이 있다. 각 서버가 인터넷에 접속할 수 있는 조건을 NAT로 조정한다. 그러나 OS 패키지 업데이트 등의 유지보수 작업 기간만 NAT가 필요하고, 그 기간 이외에는 NAT 자원을 거의 사용하지 않아 자원을 낭비하게 된다. ㅁ 해결/패턴 원래 서버와 같은 장비는 영구적으로 계속 이용해야 하는 전제가 있었다. 일시적으로 이용하는 서버를 일시적 요금으로 운영한다는 것은 정말 어려운 일이었다. 그러나 클라우드의 가상 서버는 종..
Weighted Transition - 가중치 라운드 로빈 DNS적용을 이용한 이전 ㅁ 풀어야 할 문제 시스템 전부를 어떤 지역에서 다른 지역으로 이전해야 할 때가 있다. 예를 들어, 일반 데이터 센터에서 클라우드로 시스템을 이전하는 경우나 클라우드의 어떤 지역에서 다른 지역으로 이전하려고 하는 경우를 생각할 수 있다. 이럴 때는 시스템 도메인 명을 변경하지 않거나 시스템의 정지 없이, 가능하면 서비스에 영향을 주지 않고 이전을 하고 싶어하는 경우가 많다. ㅁ 해결/패턴 도메인 명을 변경하지 않고 전 시스템을 이전하려면, DNS 서버에서 웨이티드 라운드 로빈(Weighted Round Robin)이라는 기능을 이용해 도메인을 찾을 때 기존 시스템에서 새로운 시스템으로 변경하는 방법이 있다. 처음에는 새로운 시스템에 작은 비율을 할당하고, 문제가 없다면 천천히 할당 비율을 늘려갈 수 있다..
Web Storage Archive - 대용량 데이터 아카이브화 ㅁ 풀어야 할 문제 각 서버에서 대량으로 발생하는 로그나 백업 파일은 일정 기간 보관해야 한다. 그러나 그 때문에 대용량 디스크를 준비하는 것은 비용적으로 효율이 좋지 않고, 특히 규모가 커져가는 시스템에서는 보관할 파일 용량을 산정(Capacity Plan)하기가 쉽지 않다. 각 서버의 로그를 공유 스토리지에 저장하고 단기간 로테이션하면 각 서버의 디스크 확장을 위한 점검 시간을 없앨 수 있다. 그러나 공유 스토리지에 대해서도 위와 같은 캐퍼시트 플래닝에 대한 문제가 존재한다. ㅁ 해결/패턴 클라우드에서는 실제 용량 제한이 없는 인터넷 스토리지가 있는 경우가 많고, 이 인터넷 스토리지를 로그 저장소로 이용할 수 있다. 이 경우, 디스크 확장을 위한 점검과 사전에 Capacity Planning을 고려할..
Monitoring Integration - 모니터링 툴 일원화 ㅁ 풀어야 할 문제 시스템 운영 작업에서 모니터링(서비스/자원 감시 등)은 필수 이기 때문에 클라우드에서도 모니터링 서비스를 제공하고 잇다. 그러나 클라우드 모니터링 서비스는 가상 서버 내 (OS/미들웨어/애플리케이션 등)의 감시는 할 수 없기 때문에 다른 모니터링 시스템이 필요하다. 그렇게 되면 모니터링 시스템이 여러 대가 되고 운영(특히, 감시)가 복잡해지는 문제가 있다. ㅁ 해결/패턴 가상 서버 등은 클라우드의 모니터링으로 감시하고 OS/미들웨어/애플리케이션 등은 사용자가 구축한 모니터링 시스템을 이용하여 감시한다. 클라우드 모니터링 서비스는 API를 제공하고 있다. 그 API를 통해 별도로 구축한 모니터링 시스템에서 정보를 수집하여 클라우드를 포함한 통합 감시를 할 수 있다. ㅁ 구현 EC2에 감..
Server Swapping - 서버 이전 ㅁ 풀어야 할 문제 서버 장애가 발생하면 빨리 복구해야 한다. 장애 원인은 여러 가지가 있지만, 디스크에는 문제가 없는 경우가 많다. 그럴 때는 문제가 없는 디스크를 다른 서버에 장착하면 바로 복구할 수는 있지만, 데이터 센터 작업이나 서버의 준비, 디스크 교체 등으로 시간이 소비 된다. ㅁ 해결/패턴 클라우드에서의 서버는 가상 서버이고 교체 가능한 가상 디스크를 이용할 수 있다. 가상 서버에 장애가 발생하면, 장애가 발생한 가상 서버의 디스크를 다른 가상 서버에 장착하여 장애 복구를 할 수 있다 물리 서버와 비교하면 서버 준비와 엔지니어가 이동할 필요가 없어 짧은 시간에 복구가 가능하다. ㅁ 구현 EBS는 EC2 인스턴스와 독립적으로 존재하며, 다른 EC2 인스턴스에 장착할 수 있고 장애 발생 시 다른..
Stack Deployment - 서버 군의 템플릿화 ㅁ 풀어야 할 문제 시스템 개발이나 운영 유지 보수에 있어서 일반적으로 테스트 환경이나 스테이징 환경을 준비한다. 이 환경은 평상시에 사용하지 않아 서비스 환경과 동일한 대수의 서버를 준비하는 데에는 많은 비용이 들어간다. 가상 서버를 이용하면 비용 효율이 개선된다. 그러나 시스템이 복잡하고 가상 서버가 많은 경우, 그 환경을 만들고 관련되 가상 서버를 가동하고 정지하는 등의 작업에는 손이 많이 간다. 그렇게 되면 시간도 많이 걸리고 실수도 많아 진다. ㅁ 해결/패턴 서버 그룹을 가동하는 템플릿을 준비하여 거기에 맞춰 자동으로 한번에 가동하는 방법을 이용한다. 구축해야 하는 환경에 필요한 클라우드 컴포넌트를 템플릿에 넣어두고, 그 템플릿에 따라 환경 구축을 함으로 복잡한 시스템을 실수 없이 준비할 수 있..
Cloud DI - 변경이 많은 부분의 분리 ㅁ 풀어야 할 문제 대규모 시스템에서는 액세스 증가에 따라 서버를 증설하게 됨, 그런 경우 서버 구축에 필요한 설치나 설정을 하나하나 수작업으로 하기에는 시간이 많이 걸리고 기간 내에 끝내는 것도 어렵다. 서버 구축 자동화를 하는 방법으로 시스템 관리 툴을 사용하는 방법도 있지만, 그렇게 하려면 비용 문제가 발생한다. ㅁ 해결/패턴 가상 서버를 가동할 때 그 서버의 목적에 맞게 서버 내부 구성을 자동으로 구축해야 하는 경우가 있다. 특히, Scale Out이나 Scheduled AutoScaling 패턴을 사용하여 운영을 자동화하려고 하는 경우 요구 된다. 이런 경우 Bootstrap 패턴이 적합하지만, 외부에서 가져와야 할 정보(예를 들어, DB 접속 위치, IP 어드레스, 서버 명, 인식 번호 등)가..