원저자: Adam Charnock
원본 링크: PHP 로드 밸런싱을 위한 히치하이커 가이드
번역: Koda는
대규모 웹 애플리케이션을 실행할 때 대규모 웹 서버를 실행한다는 의미로 사용되었습니다. 귀하의 응용 프로그램이 많은 수의 사용자를 끌어들이기 때문에 서버에 더 많은 메모리와 프로세서를 추가해야 합니다.
오늘날 '대형 서버' 모델은 사라지고 다양한 로드 밸런싱 기술을 사용하는 다수의 소형 서버로 대체되었습니다. 이는 하드웨어 비용을 최소한으로 유지하는 보다 실현 가능한 접근 방식입니다.
과거 '대형 서버' 모델에 비해 '더 작은 서버'의 장점은 두 가지 측면에서 반영됩니다.
즉, 서버가 다운되면 로드 밸런싱 시스템은 다운된 서버에 대한 요청을 중단하고 대신 정상적으로 실행 중인 다른 서버에 부하를 분산시킵니다. . 우수한.
서버를 확장하는 것이 더 쉽습니다. 여러분이 해야 할 일은 로드 밸런싱 시스템에 새 서버를 추가하는 것뿐입니다. 애플리케이션을 중단할 필요가 없습니다.
따라서 이 기회를 활용하십시오. :) 물론 단점은 애플리케이션 개발이 좀 더 복잡하다는 것입니다. 이것이 바로 이 기사에서 다룰 내용입니다.
이 시점에서 여러분은 '하지만 내가 로드 밸런싱을 사용하고 있는지 어떻게 알 수 있지?'라고 자문할 수도 있습니다. '. 이 질문에 대한 가장 솔직한 대답은 아마도 로드 밸런싱 시스템을 사용하고 있지 않으며 시스템에서 이를 고려할 필요가 없다는 것입니다. 대부분의 경우 애플리케이션이 충분히 커지면 로드 밸런싱을 명시적으로 제안하고 설정해야 합니다. 그러나 웹 호스팅 회사가 고객 애플리케이션에 대해 이러한 로드 밸런싱을 수행하거나 아래 설명된 대로 자체적으로 수행하는 경우가 가끔 있습니다.
아래 내용을 계속하기 전에 이 문서에서는 주로 PHP의 로드 밸런싱에 대해 설명한다는 점을 지적하고 싶습니다. 나중에 데이터 로드 밸런싱에 대해 글을 쓸 수도 있지만 지금은 기다려야 합니다.
웹사이트 대신 "웹 애플리케이션"을 계속 언급한다는 점에 유의하세요. 이는 '웹 애플리케이션'이 단순한 정적 콘텐츠만 표시하는 웹사이트가 아니라 종종 서버 측 프로그래밍 및 데이터베이스를 포함하는 복잡한 사이트임을 구별하기 위한 것입니다.
1. PHP 파일 첫 번째 질문은, 소규모 서버가 많은 경우 PHP 파일을 모든 서버에 어떻게 업로드합니까? 참고할 수 있는 방법은 다음과 같습니다:
모든 파일을 각 서버에 개별적으로 업로드합니다. 이 방법의 문제점은: 20개의 서버가 있다고 가정하면 업로드 프로세스 중에 쉽게 오류가 발생하고 업데이트 시간이 매우 길어진다는 것입니다. 빠릅니다. 서로 다른 서버에 서로 다른 버전의 파일이 있을 수 있습니다.
'rsync'(또는 이와 유사한 소프트웨어)를 사용하면 로컬 디렉터리의 파일과 여러 원격 호스트의 디렉터리를 동기화할 수 있습니다.
버전 제어 소프트웨어(예: Subversion)를 사용합니다. 이것은 제가 가장 좋아하는 방법입니다. 이를 통해 코드를 매우 잘 유지할 수 있으며, 애플리케이션을 게시할 때 각 서버에서 svn update 명령을 실행하여 동기화할 수 있습니다. 또한 이 접근 방식을 사용하면 서버를 이전 버전의 코드로 전환하는 것이 더 쉬워집니다.
파일 서버를 사용하십시오(NFS가 이에 적합할 수 있습니다). 물론, 파일 서버가 다운되면 모든 사이트를 사용할 수 없게 됩니다. 이때 복원하려면 더 많은 비용을 지출해야 합니다.
어떤 방법을 선택하느냐는 귀하의 요구 사항과 귀하가 보유한 기술에 따라 다릅니다. 버전 제어 시스템을 사용하는 경우 업데이트 명령을 동시에 실행하여 모든 서버의 코드를 업데이트하는 방법을 계획할 수 있습니다. 그러나 파일 서버를 사용하는 경우 서버가 다운되는 경우 요청 실패를 방지하기 위해 일부 오류 복구 메커니즘을 구현해야 합니다.
2. 파일 업로드 서버가 하나만 있는 경우 파일 업로드는 문제가 되지 않습니다. 하지만 서버가 여러 개인 경우 업로드된 파일을 어떻게 저장해야 할까요? 파일 업로드 문제는 서버 간 PHP 파일 저장과 유사합니다. 다음은 몇 가지 가능한 해결 방법입니다.
파일을 데이터베이스에 저장합니다. 대부분의 데이터는 이진 데이터를 저장할 수 있습니다. 파일 다운로드를 요청하면 액세스 데이터는 바이너리 데이터와 해당 파일 이름 및 유형을 사용자에게 출력합니다. 이 솔루션을 사용하기 전에 데이터베이스가 파일을 저장하는 방법을 고려해야 합니다. 이 접근 방식의 문제점은 데이터베이스 서버가 다운되면 파일을 사용할 수 없게 된다는 것입니다.
업로드된 파일을 파일 서버에 저장합니다. 이전 소개와 마찬가지로 모든 웹 서버에서 공유할 파일 서버를 설치해야 합니다. 업로드된 모든 파일을 여기에 업로드하면 모든 웹 서버에서 사용할 수 있습니다. 단, 파일 서버가 다운되면 이미지 파일 다운로드가 중단될 수 있습니다.
각 서버에 파일을 전송하는 고유한 업로드 메커니즘을 설계하세요. 이 접근 방식에는 단일 파일 서버나 데이터베이스 솔루션의 단점이 없지만 코드가 더 복잡해집니다. 예를 들어, 여러 서버에 업로드하는 동안 서버가 다운되면 어떻게 하시겠습니까?
데이터베이스를 사용하여 업로드된 파일을 저장하지만 파일 캐싱 메커니즘을 설계하는 것이 좋은 솔루션입니다. 서버는 파일 다운로드 요청을 받으면 먼저 해당 파일이 캐시 시스템에 있는지 확인하고, 발견되면 캐시 시스템에서 해당 파일을 다운로드하여 파일 시스템에 캐시합니다.
3. 세션
PHP의 세션 처리에 익숙하다면 기본적으로 세션 데이터를 서버의 임시 파일에 저장한다는 것을 알고 있을 것입니다. 또한 이 파일은 요청한 서버에만 있지만 후속 요청은 다른 서버에서 처리될 수 있으며 이로 인해 다른 서버에서 새 세션이 생성됩니다. 이로 인해 로그인한 사용자에게 항상 다시 로그인하라는 메시지가 표시되는 등 세션이 자주 인식되지 않습니다.
제가 권장하는 해결책은 세션 데이터를 데이터베이스에 저장하기 위해 PHP에 내장된 세션 처리 메커니즘을 다시 설정하거나 사용자의 요청이 동일한 서버로 전송되도록 자신만의 메커니즘을 구현하는 것입니다.
4. 구성
이 주제는 특별히 PHP와 관련된 것은 아니지만 언급할 필요가 있다고 생각합니다. 클러스터된 서버를 실행할 때 서버 간에 구성 파일을 동기화 상태로 유지하는 방법을 갖는 것이 좋습니다. 구성 파일이 일관되지 않으면 문제 해결이 어려울 수 있는 매우 이상하고 간헐적인 동작이 발생할 수 있습니다.
버전 관리 시스템을 사용하여 개별적으로 관리하는 것이 좋습니다. 이렇게 하면 다양한 프로젝트 설치에 대해 다양한 PHP 구성 파일을 저장할 수 있고 모든 서버 구성 파일을 동기화 상태로 유지할 수도 있습니다.
5. 로깅
구성 문제와 마찬가지로 로깅도 PHP에만 관련된 것이 아닙니다. 하지만 서버를 건강하게 유지하는 것은 여전히 매우 중요합니다. 적절한 로깅 시스템이 없으면 PHP 코드에서 오류가 발생하기 시작하는지 어떻게 알 수 있습니까? (시스템이 작동 중일 때 항상 display_errors 설정을 끄지 않습니까?)
로깅
을 구현할 수 있는 몇 가지 방법이 있습니다.
섬기는 사람. 이것이 가장 쉬운 방법입니다. 각 시스템은 하나의 파일만 기록합니다. 장점은 간단하고 구성이 거의 필요하지 않다는 것입니다. 그러나 서버 수가 증가함에 따라 각 서버의 로그 파일을 모니터링하는 것이 매우 어려워집니다.
공유에 로깅 이 접근 방식은 여전히 각 서버에 로그 파일을 갖고 있지만 공유 메커니즘을 통해 중앙 파일 서버에 저장되므로 로그를 더 쉽게 모니터링할 수 있습니다. 이 솔루션의 문제점은 파일 서버를 사용할 수 없는 경우 간단한 로그 쓰기 문제로 인해 결국 전체 애플리케이션이 중단된다는 것입니다.
로깅 서버에 로깅 syslog와 같은 로깅 소프트웨어를 사용하여 모든 로그를 중앙 서버에 쓸 수 있습니다. 이 방법에는 더 많은 구성이 필요하지만 가장 강력한 솔루션도 제공합니다.
phpv 추가: 또 다른 중요한 점은 데이터베이스 관리인데, 여기에는 많은 내용이 포함될 수 있으므로 작성자는 이를 작성하지 않았습니다.