RoadRunner: PHP는 죽도록 만들어지지 않았습니다. Golang이 도와줍니다.

헤이 하브르! 우리는 Badoo에서 활동하고 있습니다 PHP 성능 작업, 우리는 이 언어로 상당히 큰 시스템을 가지고 있고 성능 문제는 비용 절감 문제이기 때문입니다. XNUMX년 이상 전에 우리는 이를 위해 PHP-FPM을 만들었습니다. 처음에는 PHP용 패치 세트였으며 나중에 공식 배포판에 들어갔습니다.

최근 몇 년 동안 PHP는 큰 발전을 이루었습니다. 가비지 수집기가 개선되고 안정성 수준이 높아졌습니다. 오늘날 아무 문제없이 PHP에서 데몬과 수명이 긴 스크립트를 작성할 수 있습니다. 이를 통해 Spiral Scout는 더 발전할 수 있었습니다. RoadRunner는 PHP-FPM과 달리 요청 간에 메모리를 정리하지 않으므로 추가적인 성능 향상을 제공합니다(이 접근 방식은 개발 프로세스를 복잡하게 만들지만). 현재 이 도구를 실험하고 있지만 아직 공유할 결과가 없습니다. 그들을 기다리는 즐거움을 더하기 위해, Spiral Scout의 RoadRunner 발표 번역본을 게시합니다.

기사의 접근 방식은 우리에게 가깝습니다. 문제를 해결할 때 PHP와 Go를 가장 많이 사용하여 두 언어의 이점을 얻고 다른 언어를 선호하지 않습니다.

즐기십시오!

지난 XNUMX년 동안 목록에 있는 회사를 위한 애플리케이션을 만들었습니다. 행운 500, 사용자가 500명 이하인 비즈니스에 적합합니다. 지금까지 우리 엔지니어들은 PHP를 중심으로 백엔드를 개발해 왔습니다. 그러나 XNUMX년 전 우리 제품의 성능뿐만 아니라 확장성에도 큰 영향을 미친 무언가가 있었습니다. 우리는 기술 스택에 Golang(Go)을 도입했습니다.

거의 즉시 우리는 Go를 통해 최대 40배의 성능 향상으로 더 큰 애플리케이션을 구축할 수 있다는 사실을 알게 되었습니다. 이를 통해 기존 PHP 제품을 확장하고 두 언어의 이점을 결합하여 개선할 수 있었습니다.

Go와 PHP의 조합이 실제 개발 문제를 해결하는 데 어떻게 도움이 되는지, Go와 PHP가 관련된 일부 문제를 제거할 수 있는 도구로 어떻게 바뀌었는지 알려드리겠습니다. PHP 죽어가는 모델.

일상적인 PHP 개발 환경

Go를 사용하여 죽어가는 PHP 모델을 되살리는 방법에 대해 이야기하기 전에 기본 PHP 개발 환경을 살펴보겠습니다.

대부분의 경우 nginx 웹 서버와 PHP-FPM 서버의 조합을 사용하여 애플리케이션을 실행합니다. 전자는 정적 파일을 제공하고 특정 요청을 PHP-FPM으로 리디렉션하는 반면 PHP-FPM 자체는 PHP 코드를 실행합니다. 덜 인기 있는 Apache와 mod_php 조합을 사용하고 있을 수 있습니다. 그러나 조금 다르게 작동하더라도 원리는 동일합니다.

PHP-FPM이 애플리케이션 코드를 실행하는 방법을 살펴보겠습니다. 요청이 들어오면 PHP-FPM은 PHP 하위 프로세스를 초기화하고 요청 세부 정보를 상태(_GET, _POST, _SERVER 등)의 일부로 전달합니다.

PHP 스크립트 실행 중에는 상태가 변경될 수 없으므로 새로운 입력 데이터 세트를 얻는 유일한 방법은 프로세스 메모리를 지우고 다시 초기화하는 것입니다.

이 실행 모델에는 많은 이점이 있습니다. 메모리 소비에 대해 너무 걱정할 필요가 없으며 모든 프로세스가 완전히 격리되어 있으며 그 중 하나가 "종료"되면 자동으로 재생성되고 나머지 프로세스에는 영향을 미치지 않습니다. 그러나 이 접근 방식에는 애플리케이션을 확장하려고 할 때 나타나는 단점도 있습니다.

일반 PHP 환경의 단점 및 비효율

전문 PHP 개발자라면 프레임워크를 선택하여 새 프로젝트를 시작할 위치를 알고 있을 것입니다. 종속성 주입 라이브러리, ORM, 번역 및 템플릿으로 구성됩니다. 물론 모든 사용자 입력을 하나의 개체(Symfony/HttpFoundation 또는 PSR-7)에 편리하게 넣을 수 있습니다. 프레임워크는 멋지다!

그러나 모든 것에는 대가가 있습니다. 모든 엔터프라이즈 수준 프레임워크에서 단순한 사용자 요청이나 데이터베이스 액세스를 처리하려면 최소한 수십 개의 파일을 로드하고 수많은 클래스를 만들고 여러 구성을 구문 분석해야 합니다. 그러나 최악의 경우 각 작업을 완료한 후 모든 것을 재설정하고 다시 시작해야 한다는 것입니다. 방금 시작한 모든 코드가 쓸모 없게 되어 더 이상 다른 요청을 처리하지 않게 됩니다. 다른 언어로 글을 쓰는 프로그래머에게 이것을 말하면 그의 얼굴에 당황하는 것을 보게 될 것입니다.

PHP 엔지니어들은 영리한 지연 로딩 기술, 마이크로프레임워크, 최적화된 라이브러리, 캐시 등을 사용하여 수년 동안 이 문제를 해결할 방법을 모색해 왔습니다. 하지만 결국에는 여전히 전체 애플리케이션을 재설정하고 다시 시작해야 합니다. (번역자 주: 이 문제는 프리로드 PHP 7.4에서)

Go를 사용하는 PHP는 하나 이상의 요청에서 살아남을 수 있습니까?

cron 작업, CSV 파서, 대기열 차단기와 같이 몇 분 이상(최대 몇 시간 또는 며칠) 지속되는 PHP 스크립트를 작성할 수 있습니다. 그들은 모두 동일한 시나리오에 따라 작동합니다. 작업을 검색하고 실행하고 다음 작업을 기다립니다. 코드는 항상 메모리에 상주하므로 프레임워크와 애플리케이션을 로드하는 데 필요한 추가 단계가 많기 때문에 귀중한 밀리초를 절약할 수 있습니다.

그러나 수명이 긴 스크립트를 개발하는 것은 쉽지 않습니다. 오류가 발생하면 프로세스가 완전히 종료되고 메모리 누수 진단이 짜증나며 F5 디버깅이 더 이상 불가능합니다.

PHP 7이 출시되면서 상황이 개선되었습니다. 신뢰할 수 있는 가비지 수집기가 등장했고, 오류를 처리하기가 더 쉬워졌으며, 이제 커널 확장이 누출되지 않습니다. 사실, 엔지니어는 여전히 메모리에 주의하고 코드의 상태 문제를 인식해야 합니다(이러한 사항을 무시할 수 있는 언어가 있습니까?). 그럼에도 불구하고 PHP 7은 우리를 위해 준비된 놀라움이 적습니다.

수명이 긴 PHP 스크립트로 작업하는 모델을 가져와서 HTTP 요청 처리와 같은 보다 사소한 작업에 적용하여 각 요청에 대해 처음부터 모든 것을 로드할 필요를 없앨 수 있습니까?

이 문제를 해결하려면 먼저 HTTP 요청을 수락하고 매번 죽이지 않고 하나씩 PHP 워커로 리디렉션할 수 있는 서버 애플리케이션을 구현해야 했습니다.

우리는 순수한 PHP(PHP-PM) 또는 C 확장(Swoole)을 사용하여 웹 서버를 작성할 수 있다는 것을 알고 있었습니다. 그리고 각 방법에는 고유한 장점이 있지만 두 옵션 모두 우리에게 적합하지 않았습니다. 우리는 더 많은 것을 원했습니다. 우리는 단순한 웹 서버 이상이 필요했습니다. 우리는 PHP의 "어려운 시작"과 관련된 문제로부터 우리를 구할 수 있는 솔루션을 얻을 수 있기를 기대했습니다. 동시에 특정 애플리케이션에 맞게 쉽게 조정하고 확장할 수 있습니다. 즉, 애플리케이션 서버가 필요했습니다.

Go가 도움이 될까요? 우리는 언어가 애플리케이션을 단일 바이너리로 컴파일하기 때문에 가능하다는 것을 알고 있었습니다. 크로스 플랫폼입니다. 자체적이고 매우 우아한 병렬 처리 모델(동시성)과 HTTP 작업을 위한 라이브러리를 사용합니다. 마지막으로 수천 개의 오픈 소스 라이브러리 및 통합을 사용할 수 있습니다.

두 가지 프로그래밍 언어 결합의 어려움

먼저 두 개 이상의 응용 프로그램이 서로 통신하는 방법을 결정해야 했습니다.

예를 들어, 우수한 도서관 Alex Palaestras, PHP와 Go 프로세스 간에 메모리 공유가 가능했습니다(Apache의 mod_php와 유사). 그러나이 라이브러리에는 문제 해결을 위해 사용을 제한하는 기능이 있습니다.

우리는 소켓/파이프라인을 통해 프로세스 간의 상호 작용을 구축하기 위해 보다 일반적인 다른 접근 방식을 사용하기로 결정했습니다. 이 접근 방식은 지난 수십 년 동안 신뢰할 수 있는 것으로 입증되었으며 운영 체제 수준에서 잘 최적화되었습니다.

먼저 프로세스 간 데이터 교환과 전송 오류 처리를 위한 간단한 바이너리 프로토콜을 만들었습니다. 가장 간단한 형태로 이 유형의 프로토콜은 다음과 유사합니다. 넷스트링 с 고정 크기 패킷 헤더 (이 경우 17바이트) 패킷 유형, 크기 및 데이터 무결성을 확인하기 위한 이진 마스크에 대한 정보가 들어 있습니다.

우리가 사용한 PHP 측에서 팩 기능, Go 측면에서 라이브러리 인코딩/바이너리.

하나의 프로토콜로는 충분하지 않은 것 같았고 호출 기능을 추가했습니다. PHP에서 직접 net/rpc go 서비스. 나중에 Go 라이브러리를 PHP 애플리케이션에 쉽게 통합할 수 있었기 때문에 개발에 많은 도움이 되었습니다. 이 작업의 결과는 예를 들어 다른 오픈 소스 제품에서 볼 수 있습니다. 고리지.

여러 PHP 작업자에 작업 분산

상호 작용 메커니즘을 구현한 후 작업을 PHP 프로세스로 전송하는 가장 효율적인 방법에 대해 생각하기 시작했습니다. 작업이 도착하면 애플리케이션 서버는 작업을 실행할 무료 작업자를 선택해야 합니다. 작업자/프로세스가 오류와 함께 종료되거나 "종료"되면 이를 제거하고 대체할 새 프로세스를 생성합니다. 작업자/프로세스가 성공적으로 완료되면 작업을 수행할 수 있는 작업자 풀로 반환합니다.

활성 작업자 풀을 저장하기 위해 다음을 사용했습니다. 버퍼링된 채널, 예기치 않게 "죽은" 작업자를 풀에서 제거하기 위해 작업자의 오류 및 상태를 추적하는 메커니즘을 추가했습니다.

결과적으로 우리는 바이너리 형식으로 제시된 모든 요청을 처리할 수 있는 작동하는 PHP 서버를 얻었습니다.

애플리케이션이 웹 서버로 작동하기 시작하려면 들어오는 HTTP 요청을 나타내는 신뢰할 수 있는 PHP 표준을 선택해야 했습니다. 우리의 경우 그냥 변환 Go to format의 net/http 요청 PSR-7오늘날 사용 가능한 대부분의 PHP 프레임워크와 호환됩니다.

PSR-7은 변경할 수 없는 것으로 간주되기 때문에(기술적으로는 그렇지 않다고 말하는 사람도 있음) 개발자는 원칙적으로 요청을 글로벌 엔터티로 취급하지 않는 애플리케이션을 작성해야 합니다. 이것은 수명이 긴 PHP 프로세스의 개념과 잘 맞습니다. 아직 이름이 지정되지 않은 최종 구현은 다음과 같습니다.

로드러너 소개 - 고성능 PHP 애플리케이션 서버

우리의 첫 번째 테스트 작업은 API 백엔드였는데, 이는 주기적으로 예측할 수 없게 폭발합니다(평소보다 훨씬 더 자주). 대부분의 경우 nginx로 충분했지만, 예상되는 부하 증가에 대해 충분히 빠르게 시스템 균형을 맞출 수 없었기 때문에 정기적으로 502 오류가 발생했습니다.

이 솔루션을 대체하기 위해 2018년 초에 첫 번째 PHP/Go 애플리케이션 서버를 배포했습니다. 그리고 즉시 놀라운 효과를 얻었습니다! 우리는 502 오류를 완전히 없앴을 뿐만 아니라 서버 수를 XNUMX/XNUMX로 줄여 많은 비용을 절약하고 엔지니어와 제품 관리자의 골칫거리를 줄일 수 있었습니다.

올해 중반까지 솔루션을 개선하고 MIT 라이센스로 GitHub에 게시하고 이름을 지정했습니다. 로드 러너, 따라서 놀라운 속도와 효율성을 강조합니다.

RoadRunner가 개발 스택을 개선하는 방법

신청 로드 러너 Go 측에서 미들웨어 net/http를 사용하여 요청이 PHP에 도달하기 전에 JWT 확인을 수행하고 Prometheus에서 전역적으로 WebSocket 및 집계 상태를 처리할 수 있었습니다.

내장된 RPC 덕분에 확장 래퍼를 작성하지 않고도 PHP용 Go 라이브러리의 API를 열 수 있습니다. 더 중요한 것은 RoadRunner를 사용하여 새로운 비 HTTP 서버를 배포할 수 있다는 것입니다. 예제에는 PHP에서 핸들러 실행이 포함됩니다. AWS 람다, 신뢰할 수 있는 대기열 차단기 생성 및 추가 gRPC 우리의 응용 프로그램에.

PHP 및 Go 커뮤니티의 도움으로 솔루션의 안정성을 개선하고 일부 테스트에서 애플리케이션 성능을 최대 40배까지 향상했으며 디버깅 도구를 개선하고 Symfony 프레임워크와의 통합을 구현했으며 HTTPS, HTTP/2, 플러그인 및 PSR-17.

결론

일부 사람들은 여전히 ​​PHP가 느리고 다루기 힘든 언어로 워드프레스용 플러그인을 작성하는 데만 적합한 구식 개념에 사로잡혀 있습니다. 이 사람들은 심지어 PHP에 한계가 있다고 말할 수도 있습니다. 응용 프로그램이 충분히 커지면 더 "성숙한" 언어를 선택하고 수년 동안 축적된 코드 기반을 다시 작성해야 합니다.

이 모든 것에 대해 대답하고 싶습니다. 다시 생각하십시오. 우리는 당신만이 PHP에 대한 제한을 설정했다고 믿습니다. 평생을 한 언어에서 다른 언어로 전환하거나 필요에 맞는 언어를 찾거나 언어를 도구로 생각하기 시작할 수 있습니다. PHP와 같은 언어의 결함이 실제로 성공의 이유일 수 있습니다. Go와 같은 다른 언어와 결합하면 한 언어만 사용하는 것보다 훨씬 더 강력한 제품을 만들 수 있습니다.

여러 가지 Go 및 PHP를 사용하여 작업한 결과 우리는 Go 및 PHP를 좋아한다고 말할 수 있습니다. 우리는 다른 것을 위해 하나를 희생할 계획이 없습니다. 반대로 우리는 이 이중 스택에서 더 많은 가치를 얻을 수 있는 방법을 찾을 것입니다.

UPD: RoadRunner의 제작자이자 원본 기사의 공동 저자를 환영합니다. 라케시스

출처 : habr.com