Barracuda 로드 밸런싱 로드 밸런싱을 위한 PHP 개발 가이드

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

위 내용은 바라쿠다 로드 밸런싱의 내용을 포함하여 바라쿠다 로드 밸런싱 PHP 개발 로드 밸런싱 가이드를 소개한 것입니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.