AWS Design Pattern/운영 유지 보수 패턴 (7) 썸네일형 리스트형 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 어드레스, 서버 명, 인식 번호 등)가.. Bootstrap - 부팅 설정의 자동 수집 ㅁ 풀어야 할 문제 서버 이미지에서 서버를 만드는 방법, 즉 Stamp패턴을 적용할 때 어느 정도의 빈도로 서버 이미지를 가지고 올 것인가는 운영 효율에 있어서 자주 거론되는 문제다 Stamp 패턴에서는 미들웨어부터 애플리케이션까지 전부 설정이 끝난 상태에서 서버를 가동하면 그대로 사용이 가능한 서버 이미지를 만들 수 있다. 이런 때 가상 서버의 가동은 굉장히 빠르지만, 미들웨어 중 하나를 업데이트해야 하거나 애플리케이션 설정을 바꿔야 할 때는 서버 이미지를 다시 만들어야 한다. ㅁ 해결/패턴 클라우드에서는 쉽게 서버 이미지를 만들 수 있으며, 가동할 때 파라미터를 설정할 수 있다. 이 기능을 사용하여 서버 구성에 필요한 파라미터를 전달하여 서버를 가동할 때 필요한 설정을 서버가 전달받아 설치, 가동, .. 이전 1 다음
