웹사이트 검색

프로덕션 웹 애플리케이션 서버 설정을 개선하는 5가지 방법

소개

애플리케이션이 클라우드 서버 환경에서 가동되고 실행되면 서버 환경을 어떻게 개선하여 "작동하는 것\에서 본격적인 프로덕션 환경으로 도약할 수 있는지 궁금할 것입니다. 이 문서는 시작하는 데 도움이 될 것입니다. 클라우드 서버 환경의 웹 애플리케이션 컨텍스트에서 "프로덕션\의 느슨한 정의를 생성하고 전환을 위해 기존 아키텍처에 추가할 수 있는 몇 가지 구성 요소를 보여줌으로써 프로덕션 환경을 계획하고 구현합니다.

이 데모의 목적을 위해 단순히 웹 애플리케이션을 제공하는 이 두 서버 환경과 같이 5가지 공통 서버 설정에 설명된 것과 유사한 설정으로 시작한다고 가정해 보겠습니다.

실제 설정은 더 간단하거나 더 복잡할 수 있지만 여기에서 설명하는 일반적인 개념과 구성 요소는 모든 서버 환경에 어느 정도 적용되어야 합니다.

\프로덕션 환경\이라고 말할 때 의미하는 바를 정의하는 것부터 시작하겠습니다.

프로덕션 환경이란 무엇입니까?

일반적으로 웹 애플리케이션을 위한 서버 환경은 하드웨어, 소프트웨어, 데이터, 운영 계획 및 애플리케이션 작동을 유지하는 데 필요한 인력으로 구성됩니다. 프로덕션 환경은 일반적으로 다음 요소의 허용 수준을 최대한 고려하여 설계 및 구현된 서버 환경을 나타냅니다.

  • 가용성: 광고된 시간 동안 의도된 사용자가 애플리케이션을 사용할 수 있는 기능입니다. 가용성은 중요한 구성 요소에 충분히 심각한 영향을 미치는 모든 장애로 인해 중단될 수 있습니다(예: 버그로 인한 애플리케이션 충돌, 데이터베이스 저장 장치 장애 또는 시스템 관리자가 실수로 애플리케이션 서버 전원 끄기).

가용성을 높이는 한 가지 방법은 환경에서 단일 장애 지점의 수를 줄이는 것입니다. 예를 들어 고정 IP 및 모니터링 장애 조치 서비스를 사용하면 사용자가 로드 밸런싱 시 정상적인 로드 기사에만 액세스할 수 있습니다.

  • 복구 가능성: 시스템 장애 또는 데이터 손실이 발생한 경우 애플리케이션 환경을 복구할 수 있는 기능입니다. 중요한 구성 요소가 실패하고 복구할 수 없는 경우 가용성이 존재하지 않게 됩니다. 관련 개념인 유지보수성을 개선하면 장애 발생 시 지정된 복구 프로세스를 수행하는 데 필요한 시간이 단축되므로 장애 발생 시 가용성을 향상시킬 수 있습니다.\n
  • 성능: 애플리케이션이 평균 또는 최대 부하에서 예상대로 작동합니다(예: 합리적으로 응답함). 사용자에게 매우 중요하지만 성능은 애플리케이션을 사용할 수 있는 경우에만 중요합니다.\n

응용 프로그램의 맥락에서 방금 언급한 각 항목에 대해 허용 가능한 수준을 정의하는 데 시간을 할애하십시오. 이는 해당 응용 프로그램의 중요성과 특성에 따라 달라집니다. 예를 들어 방문자가 거의 없는 개인 블로그의 경우 블로그를 복구할 수 있는 한 간헐적인 다운타임이나 성능 저하로 인해 어려움을 겪을 수 있지만 회사의 온라인 상점은 전반적으로 매우 높은 점수를 받기 위해 노력해야 합니다. 물론 모든 카테고리, 모든 애플리케이션에 대해 100% 달성하는 것이 좋겠지만 시간과 비용의 제약으로 인해 실현 불가능한 경우가 많습니다.

(a) 하드웨어 신뢰성, 지정된 하드웨어 구성 요소가 고장이 발생하기 전 지정된 시간 동안 제대로 작동할 확률 또는 (b) 보안 요소를 언급하지 않은 점에 유의하십시오. 이는 (a) 사용 중인 클라우드 서버가 일반적으로 안정적이지만 (물리적 서버에서 실행되기 때문에) 오류 가능성이 있고 (b) 최선을 다해 보안 모범 사례를 따르고 있다고 가정하기 때문입니다. 간단히 말해, 그들은 이 문서의 범위를 벗어납니다. 그러나 안정성과 보안은 가용성에 직접적인 영향을 미칠 수 있는 요소이며 둘 다 복구 가능성의 필요성에 기여할 수 있음을 알고 있어야 합니다.

모든 애플리케이션의 다양한 요구 사항과 특성으로 인해 불가능한 프로덕션 환경 생성을 위한 단계별 절차를 보여주는 대신 기존 설정을 프로덕션 환경으로 변환하는 데 활용할 수 있는 몇 가지 유형의 구성 요소를 제시합니다.

구성품을 살펴보겠습니다!

1. 백업 시스템

백업 시스템은 데이터의 주기적인 백업을 만들고 백업에서 데이터를 복원할 수 있는 기능을 부여합니다. 또한 백업을 사용하면 사람의 실수를 비롯한 다양한 이유로 인해 발생할 수 있는 실수로 삭제하거나 원하지 않는 수정이 발생한 경우 데이터를 이전 상태로 롤백할 수 있습니다. 모든 컴퓨터 하드웨어는 잠재적으로 데이터 손실을 유발할 수 있는 특정 시점에 오류가 발생할 수 있습니다. 이를 염두에 두고 모든 중요한 데이터의 최신 백업을 유지해야 합니다.

생산에 필요합니까? 예. 백업 시스템은 복구 가능성을 달성하는 데 필요한 데이터 손실의 영향을 완화할 수 있으므로 데이터 손실 시 가용성을 지원하지만 견고한 복구 계획과 함께 사용해야 합니다. 다음 섹션에서 논의됩니다. DigitalOcean의 스냅샷 기반 백업은 디스크 쓰기 I/O가 높은 활성 데이터베이스 및 기타 애플리케이션의 백업을 만드는 데 적합하지 않기 때문에 모든 백업 요구 사항에 충분하지 않을 수 있습니다. 이러한 유형의 애플리케이션을 실행하는 경우 또는 더 많은 백업 일정 유연성을 원하면 Bacula와 같은 다른 백업 시스템을 사용해야 합니다.

위의 그림은 기본 백업 시스템의 예입니다. 백업 서버는 초기 백업이 생성되는 애플리케이션 서버와 동일한 데이터 센터에 상주합니다. 나중에 백업의 오프사이트 복사본이 다른 데이터 센터의 서버에 만들어지므로 예를 들어 자연 재해가 발생한 경우 데이터를 보존할 수 있습니다.

고려 사항

  • 백업 선택 항목: 백업할 데이터입니다. 대체 소스에서 안정적으로 재생할 수 없는 데이터는 최소한 백업하십시오.
  • 백업 일정: 전체 또는 증분 백업을 수행할 시기와 빈도입니다. 백업 일정에 영향을 줄 수 있는 활성 데이터베이스와 같은 특정 유형의 데이터 백업에 대해서는 특별히 고려해야 합니다.
  • 데이터 보유 기간: 백업을 삭제하기 전에 보관하는 기간
  • 백업을 위한 디스크 공간: 이전 세 항목의 조합은 백업 시스템에 필요한 디스크 공간의 양에 영향을 미칩니다. 압축 및 증분 백업을 활용하여 백업에 필요한 디스크 공간을 줄입니다.
  • 오프사이트 백업: 특정 데이터 센터 내에서 로컬 재해로부터 백업을 보호하려면 지리적으로 떨어진 위치에 백업 사본을 유지하는 것이 좋습니다. 위 다이어그램에서 NYC3의 백업은 이 목적을 위해 SFO1에 복사됩니다.
  • 백업 복원 테스트: 백업 복원 프로세스를 정기적으로 테스트하여 백업이 제대로 작동하는지 확인합니다.

관련 튜토리얼

  • VPS를 위한 효과적인 백업 전략을 선택하는 방법
  • Ubuntu 14.04에 Bacula 서버를 설치하는 방법
  • Rsync를 사용하여 VPS에서 로컬 및 원격 디렉토리를 동기화하는 방법
  • DigitalOcean 물방울 백업 이해

2. 복구 계획

복구 계획은 프로덕션 환경 내에서 잠재적인 실패 또는 관리 오류로부터 복구하기 위한 일련의 문서화된 절차입니다. 최소한 서버 하드웨어 오류 또는 우발적인 데이터 삭제와 같이 불가피하게 발생할 것으로 생각되는 심각한 각 시나리오에 대한 복구 계획이 필요합니다. 예를 들어, 서버 오류에 대한 매우 기본적인 복구 계획은 백업에서 응용 프로그램 데이터를 복원하기 위한 추가 절차와 함께 초기 서버 배포를 수행하기 위해 수행한 단계 목록으로 구성될 수 있습니다. 더 나은 복구 계획은 좋은 문서화 외에도 Ansible, Chef 또는 Puppet과 같은 배포 스크립트 및 구성 관리 도구를 활용하여 복구 프로세스를 자동화하고 빠르게 할 수 있습니다.

생산에 필요합니까? 예. 복구 계획은 서버 환경에 소프트웨어로 존재하지 않지만 프로덕션 설정에 필요한 구성 요소입니다. 이를 통해 백업을 효과적으로 활용할 수 있으며 필요 시 환경을 재구축하거나 원하는 상태로 롤백하기 위한 청사진을 제공합니다.

위의 다이어그램은 실패한 데이터베이스 서버에 대한 복구 계획의 개요입니다. 이 경우 데이터베이스 서버는 동일한 소프트웨어가 설치된 새 서버로 교체되며 서버 구성 및 데이터를 복원하는 데 마지막 양호한 백업이 사용됩니다. 마지막으로 앱 서버는 새 데이터베이스 서버를 사용하도록 구성됩니다.

고려 사항

  • 절차 문서: 장애 발생 시 따라야 하는 일련의 문서입니다. 좋은 출발점은 장애가 발생한 서버를 재구축하기 위해 따를 수 있는 단계별 문서를 작성한 다음 백업에서 다양한 애플리케이션 데이터 및 구성을 복원하는 단계를 추가하는 것입니다.
  • 자동화 도구: 스크립트 및 구성 관리 소프트웨어는 배포 및 복구 프로세스를 개선할 수 있는 자동화를 제공합니다. 단계별 가이드는 종종 단순히 장애 복구에 적합하지만 사람이 실행해야 하므로 자동화된 프로세스만큼 빠르거나 일관성이 없습니다.
  • 핵심 구성 요소: 애플리케이션이 제대로 작동하는 데 필요한 구성 요소입니다. 위의 예에서 애플리케이션과 데이터베이스 서버는 둘 중 하나라도 실패하면 애플리케이션을 사용할 수 없게 되므로 중요한 구성 요소입니다.
  • 단일 장애 지점: 자동 장애 조치 메커니즘이 없는 중요한 구성 요소는 단일 장애 지점으로 간주됩니다. 가용성을 향상시키기 위해 최선을 다해 단일 장애 지점을 제거하려고 시도해야 합니다.
  • 개정: 배포 및 복구 프로세스가 개선됨에 따라 문서 업데이트

3. 부하 분산

로드 밸런싱을 서버 환경에 추가하여 여러 서버에 워크로드를 분산시켜 성능과 가용성을 향상시킬 수 있습니다. 부하가 분산된 서버 중 하나에 장애가 발생하면 장애가 발생한 서버가 다시 정상 상태가 될 때까지 다른 서버에서 들어오는 트래픽을 처리합니다. 클라우드 서버 환경에서 로드 밸런싱은 일반적으로 애플리케이션의 특정 구성 요소를 실행하는 여러 서버 앞에 로드 밸런서(역방향 프록시) 소프트웨어를 실행하는 로드 밸런서 서버를 추가하여 구현할 수 있습니다.

생산에 필요합니까? 반드시 그런 것은 아닙니다. 로드 밸런싱은 프로덕션 환경에 항상 필요한 것은 아니지만 올바르게 구현된 경우 시스템의 단일 실패 지점 수를 줄이는 효과적인 방법이 될 수 있습니다. 또한 수평 확장을 통해 더 많은 용량을 추가하여 성능을 향상시킬 수 있습니다.

위의 다이어그램은 로드를 공유하기 위해 추가 앱 서버를 추가하고 두 앱 서버에서 사용자 요청을 분산시키기 위해 로드 밸런서를 추가합니다. 이 설정은 단일 앱 서버가 트래픽을 따라잡는 데 어려움을 겪고 있는 경우 성능에 도움이 될 수 있으며 애플리케이션 서버 중 하나가 실패하는 경우에도 애플리케이션을 계속 사용할 수 있도록 도울 수 있습니다. 그러나 데이터베이스 서버와 로드 밸런서 서버 자체에는 여전히 두 개의 단일 실패 지점이 있습니다.

참고: DigitalOcean 로드 밸런서는 완전 관리형 고가용성 로드 밸런싱 서비스입니다. DigitalOcean에서 애플리케이션을 실행 중인 경우 Load Balancer 서비스가 환경에 적합할 수 있습니다.

고려 사항

  • 로드 밸런싱 가능한 구성 요소: 환경의 모든 구성 요소가 쉽게 로드 밸런싱될 수 있는 것은 아닙니다. 데이터베이스 또는 상태 저장 애플리케이션과 같은 특정 유형의 소프트웨어에 대해서는 특별한 고려가 필요합니다.
  • 애플리케이션 데이터 복제: 부하가 분산된 애플리케이션 서버가 업로드된 파일과 같은 애플리케이션 데이터를 로컬에 저장하는 경우 복제 또는 공유 파일 시스템과 같은 방법을 통해 다른 애플리케이션 서버에서 이 데이터를 사용할 수 있어야 합니다. 이는 사용자 요청을 처리하기 위해 어떤 애플리케이션 서버를 선택했는지에 관계없이 애플리케이션 데이터를 사용할 수 있도록 하기 위해 필요합니다.
  • 성능 병목 현상: 로드 밸런서에 리소스가 충분하지 않거나 제대로 구성되지 않은 경우 실제로 애플리케이션 성능이 저하될 수 있습니다.
  • 단일 장애 지점: 부하 분산을 사용하여 단일 장애 지점을 제거할 수 있지만 잘못 계획된 부하 분산은 실제로 더 많은 단일 장애 지점을 추가할 수 있습니다. 로드 밸런싱은 가용성에 따라 트래픽을 전송하는 쌍 앞에 정적 IP가 있는 두 번째 로드 밸런서를 포함하여 향상됩니다.

관련 튜토리얼

  • HAProxy 및 부하 분산 개념 소개
  • Ubuntu 14.04에서 HAProxy로 SSL 종료를 구현하는 방법
  • Ubuntu 14.04에서 WordPress 및 Nginx용 레이어 7 로드 밸런서로 HAProxy를 사용하는 방법
  • Nginx HTTP 프록시, 부하 분산, 버퍼링 및 캐싱 이해
  • 첫 번째 DigitalOcean 로드 밸런서를 만드는 방법
  • 예약 IP 사용 방법

4. 모니터링

모니터링은 서비스 상태와 서버 리소스 사용 추세를 추적하여 서버 환경을 지원할 수 있으므로 환경에 대한 뛰어난 가시성을 제공합니다. 모니터링 시스템의 가장 큰 이점 중 하나는 서비스 또는 서버가 다운되거나 CPU, 메모리 또는 스토리지가 과도하게 사용됩니다. 이러한 알림을 통해 문제가 발생하는 즉시 대응할 수 있으므로 애플리케이션 가동 중지 시간을 최소화하거나 방지할 수 있습니다.

생산에 필요합니까? 반드시 그런 것은 아니지만 프로덕션 환경의 규모와 복잡성이 증가함에 따라 모니터링의 필요성이 증가합니다. 중요한 서비스와 서버 리소스를 쉽게 추적할 수 있는 방법을 제공합니다. 결과적으로 모니터링을 통해 복구 가능성을 개선하고 설정 계획 및 유지 관리를 알릴 수 있습니다.

위의 다이어그램은 모니터링 시스템의 예입니다. 일반적으로 모니터링 서버는 애플리케이션 및 데이터베이스 서버에서 실행되는 에이전트 소프트웨어에서 상태 데이터를 요청하고 각 에이전트는 소프트웨어 및 하드웨어 상태 정보로 응답합니다. 그런 다음 시스템 관리자는 모니터링 콘솔을 사용하여 애플리케이션의 전체 상태를 확인하고 필요에 따라 더 자세한 정보로 드릴다운할 수 있습니다.

고려 사항

  • 모니터링할 서비스: 모니터링할 서비스 및 소프트웨어입니다. 최소한 애플리케이션이 제대로 작동하려면 정상 실행 상태에 있어야 하는 모든 서비스의 상태를 모니터링해야 합니다.
  • 모니터링할 리소스: 모니터링할 리소스입니다. 리소스의 예로는 CPU, 메모리, 스토리지, 네트워크 사용률, 서버 전체의 상태 등이 있습니다.
  • 데이터 보존: 모니터링 데이터를 폐기하기 전에 보존하는 기간입니다. 이는 모니터링할 항목 선택과 함께 모니터링 시스템에 필요한 디스크 공간의 양에 영향을 미칩니다.
  • 문제 감지 규칙: 서비스 또는 리소스가 정상 상태인지 여부를 결정하는 임계값 및 규칙입니다. 예를 들어 서비스나 서버가 실행 중이고 요청을 처리하는 경우 정상으로 간주될 수 있는 반면 스토리지와 같은 리소스는 특정 시간 동안 사용률이 특정 임계값에 도달하면 경고를 트리거할 수 있습니다.
  • 알림 규칙: 알림을 보내야 하는지 여부를 결정하는 임계값 및 규칙입니다. 알림도 중요하지만 너무 많이 받지 않도록 알림 규칙을 조정하는 것도 마찬가지로 중요합니다. 경고 및 알림으로 가득 찬 받은 편지함은 종종 무시되어 알림이 전혀 없는 것만큼이나 쓸모 없게 됩니다.

관련 튜토리얼

  • Ubuntu 14.04에서 Nagios 4를 설치하고 서버를 모니터링하는 방법
  • Icinga를 사용하여 Ubuntu 14.04에서 서버 및 서비스를 모니터링하는 방법
  • Ubuntu에 Zabbix를 설치하고 여러 VPS 서버를 모니터링하도록 구성하는 방법
  • SNMP로 네트워크 모니터링 및 관리
  • Ubuntu 14.04에서 Sensu 모니터링, RabbitMQ 및 Redis를 구성하는 방법

5. 중앙 집중식 로깅

중앙 집중식 로깅은 일반적으로 전체 환경의 개별 서버에 로컬로 저장되는 로그를 한 곳에서 쉽게 보고 검색할 수 있는 방법을 제공하여 서버 환경을 지원할 수 있습니다. 로그를 읽기 위해 개별 서버에 로그인할 필요가 없다는 편리함 외에도 중앙 집중식 로깅을 사용하면 특정 기간 동안 로그와 메트릭을 상호 연관시켜 여러 서버에 걸쳐 있는 문제를 쉽게 식별할 수 있습니다. 또한 로컬 로그를 응용 프로그램 서버에서 자체 독립 저장소가 있는 중앙 집중식 로그 서버로 오프로드할 수 있으므로 로그 보존 측면에서 더 많은 유연성을 부여합니다.

생산에 필요합니까? 아니요. 하지만 모니터링과 마찬가지로 중앙 집중식 로깅은 규모와 복잡성이 증가함에 따라 서버 환경에 대한 귀중한 통찰력을 제공할 수 있습니다. 기존 로깅보다 더 편리할 뿐만 아니라 더 나은 가시성으로 서버 로그를 신속하게 감사할 수 있습니다.

위의 다이어그램은 중앙 집중식 로깅 시스템의 단순화된 예입니다. 로그 쉬핑 에이전트는 각 서버에 설치되며 중요한 앱 및 데이터베이스 로그를 중앙 로깅 서버로 보내도록 구성됩니다. 시스템 관리자는 단일 콘솔에서 모든 중요한 로그를 보고, 필터링하고, 검색할 수 있습니다.

고려 사항

  • 수집할 로그: 서버에서 중앙 로깅 서버로 보낼 특정 로그입니다. 모든 서버에서 중요한 로그를 수집해야 합니다.
  • 데이터 보존: 로그를 폐기하기 전에 보존하는 기간입니다. 이것은 수집할 로그 선택과 함께 중앙 집중식 로깅 시스템에 필요한 디스크 공간의 양에 영향을 미칩니다.
  • 로그 필터: 일반 로그를 구조화된 로그 데이터로 구문 분석하는 필터입니다. 로그를 필터링하면 의미 있는 방식으로 데이터를 쿼리, 분석 및 그래프로 표시하는 능력이 향상됩니다.
  • 서버 시계: 서버의 시계가 동기화되고 동일한 시간대로 설정되어 있는지 확인하여 전체 환경에서 로그 타임라인이 정확하도록 합니다.

관련 튜토리얼

  • Ubuntu 14.04에 Elasticsearch, Logstash 및 Kibana 4를 설치하는 방법
  • DigitalOcean ELK 스택 원클릭 애플리케이션 사용 방법
  • 서버 통계 추적 소개
  • Ubuntu 14.04에서 Graylog2를 설치하고 로그를 중앙 집중화하는 방법

결론

모든 구성 요소를 함께 배치하면 생산 환경은 다음과 같을 수 있습니다.

이제 프로덕션 서버 설정을 지원하고 개선하는 데 사용할 수 있는 구성 요소에 대해 잘 알고 있으므로 이를 고유한 서버 환경에 통합할 수 있는 방법을 고려해야 합니다. 물론 모든 가능성을 다루지는 않았지만 어디에서 시작해야 할지 알 수 있을 것입니다. 사용 가능한 리소스와 자체 프로덕션 목표의 균형을 기반으로 서버 환경을 설계하고 구현해야 합니다.

위와 같은 환경 설정에 관심이 있는 경우 프로덕션을 위한 빌드: 웹 애플리케이션 튜토리얼을 확인하십시오.