PHP·WAS와 웹 애플리케이션 실행 계층

01정적 문서와 서버 측 프로그램 실행의 경계

• 정적정적 웹 서버는 저장된 바이트를 선택하여 응답한다.
• 동적동적 애플리케이션에서는 URL·메서드·입력값·사용자 상태를 받아 프로그램이 결과를 계산하고 DB나 외부 API를 호출한 뒤 HTML 또는 JSON을 만든다.
• PHP클라이언트는 PHP 원본 코드를 받아 실행하는 것이 아니라 서버에서 생성한 결과를 받는다. PHP 처리 연결이 잘못되어 원본 파일을 정적으로 내보내면 비밀 코드·설정이 노출될 수 있으므로 확장자 이름만으로 실행을 보장하지 않는다.
• 워커웹 프레임워크는 라우팅·입력 처리·템플릿·응답 객체를 제공하는 라이브러리 계층이고 애플리케이션 서버는 소켓·워커·프로토콜과 프로세스 생애를 관리한다.
• Nginx·PHP-FPMNginx 앞단, PHP-FPM 또는 Python 앱 서버, 프레임워크 코드, DB의 각 역할을 나누면 어느 설정이 무엇을 바꾸는지 명확해진다.
• WAS의 역할WAS라는 표현은 애플리케이션 실행 기능을 포함한 서버를 가리키지만 제품과 문맥에 따라 범위가 다르다.
• 언어 실행기와 앱 서버특정 언어의 실행기와 모든 종류의 웹 프로그램을 동일하게 취급하지 않는다.

02CGI와 FastCGI에서 요청 한 건이 실행되는 순서

• CGI전통적 CGI는 웹 서버가 외부 프로그램을 요청에 맞춰 실행하고 환경 변수와 표준 입력으로 요청 정보를 전달하며 프로그램의 표준 출력에서 응답을 받는 인터페이스다.
• DB프로그램이 끝나면 그 실행 상태도 끝나므로 매 요청 프로세스 생성 비용이 생기고 메모리 캐시나 DB 연결을 유지하기 어렵다.
• FastCGI·워커FastCGI는 워커를 계속 실행하고 소켓을 통해 여러 요청을 전달하여 실행 생애를 요청 한 건보다 길게 유지한다.

  • PHP-FPM은 이 워커 풀을 관리한다.
• Nginx·SCRIPT_FILENAMENginx가 SCRIPT_FILENAME 같은 파라미터와 요청 정보를 보내면 FPM 워커가 해당 스크립트를 실행해 응답을 반환한다.
• PHPFPM 소켓의 소유권과 웹 서버 계정, PHP 코드의 읽기 권한, 실행 제한과 풀 크기가 각기 다른 조건이다.

03PHP 요청 변수·출력과 FPM 풀 설정

• GET 입력의 자료형PHP에서 $_GET은 쿼리 문자열에서 파싱된 입력이며 입력이 존재하지 않거나 배열 형태일 수 있다는 점까지 처리해야 한다.
• HTML 출력 인코딩문자열을 HTML에 출력할 때 htmlspecialchars 같은 문맥에 맞는 인코딩을 사용하면 <와 & 등이 태그로 해석되는 것을 줄일 수 있다.
• SQL 매개변수화SQL에는 별도의 prepared statement가 필요하므로 HTML 인코딩이 SQL 안전성까지 제공하지 않는다.
• 풀FPM 풀은 실행 사용자·그룹, Unix 소켓 또는 TCP listen, 워커 관리 방식과 최대 자식 수를 정한다.
• PHP·워커pm.max_children은 동시 처리 가능한 PHP 워커의 상한과 관련되지만 무조건 크게 하면 메모리와 DB 연결을 소모한다.
• CLI·FPM 설정 차이PHP CLI의 php.ini와 FPM의 설정 경로가 다를 수 있으므로 명령행 php -v 결과와 웹 런타임의 설정을 같은 것으로 단정하지 않는다.
• display_errorsdisplay_errors는 응답으로 내부 오류를 노출할지, log_errors는 기록할지의 구분이다.

<?php
$input = $_GET["name"] ?? "learner";
$name = is_string($input) ? $input : "learner";
header("Content-Type: text/html; charset=utf-8");
echo "<p>Hello, " . htmlspecialchars($name, ENT_QUOTES, "UTF-8") . "</p>";
?>

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

04WSGI callable의 입력·헤더·본문

• WSGIWSGI는 Python 서버와 동기 애플리케이션 사이의 호출 규약이다.
• environ·start_response서버가 environ과 start_response를 넘겨 호출하고 앱은 상태와 헤더를 start_response로 알린 뒤 바이트열들을 생산하는 iterable을 반환한다.
• environenviron은 요청 메서드·경로·서버 정보 등과 입력 스트림을 담는다.
• 본문문자열 str을 그대로 본문 항목으로 반환하는 것과 UTF-8로 인코딩된 bytes를 반환하는 것은 다르다.

  • 아래 예시는 body 길이를 바이트 수로 계산한다.
• Content-Length한글 문자 수와 전송 바이트 수가 같지 않을 수 있으므로 Content-Length를 len(원문문자열)로 계산하면 잘못된다.
• DB동기 요청이 DB 응답을 기다리는 동안 해당 워커는 그 일을 처리 중이다.
• 워커여러 프로세스·스레드 워커를 둘 수 있지만 각 워커의 메모리 상태와 DB 연결 수가 늘어난다는 비용도 함께 고려한다.

def application(environ, start_response):
    body = "안녕하세요\n".encode("utf-8")
    start_response("200 OK", [
        ("Content-Type", "text/plain; charset=utf-8"),
        ("Content-Length", str(len(body))),
    ])
    return [body]

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

05ASGI의 이벤트와 await가 동시성을 만드는 위치

• ASGI·scopeASGI 애플리케이션은 scope, receive, send를 받는 비동기 callable이다.
• scopescope는 연결이나 요청의 정보이고 receive는 들어오는 이벤트, send는 응답 이벤트를 전달한다.
• 헤더·본문HTTP 응답은 시작 이벤트로 상태·헤더를 보내고 본문 이벤트로 내용을 보낸다.

  • 같은 인터페이스 계열에서 WebSocket과 lifespan 같은 프로토콜 생애도 표현할 수 있다.
• awaitawait는 기다리는 동안 이벤트 루프가 다른 작업을 진행할 기회를 준다.
• async·DB하지만 async def 안에서 동기 DB 호출이나 큰 CPU 계산을 그대로 실행하면 그 구간 동안 루프를 막을 수 있다.

  • 비동기라는 이름이 모든 코드를 병렬로 빠르게 만들지는 않는다.
  • 비동기 드라이버, 제한된 thread pool, CPU 작업 분리를 요구에 맞게 선택한다.
• DB프록시·앱·DB의 timeout과 최대 연결 수도 한 요청 흐름에서 맞물린다.

async def application(scope, receive, send):
    if scope["type"] != "http":
        return
    await send({"type": "http.response.start", "status": 200,
                "headers": [(b"content-type", b"text/plain")]})
    await send({"type": "http.response.body", "body": b"hello\n"})

교육용 예시. 결과와 주소는 설명용이며 실제 시스템에서 실행한 기록이 아니다.

09연결된 계층을 함께 관찰하기

• DB웹 서버에서 보이는 오류가 실행기 연결 실패, 애플리케이션 예외, DB 연결 고갈 중 어디에서 시작됐는지 구분한다.
• timeout·동시 처리 수각 계층의 시간 제한과 동시 처리 수가 어긋나면 대기열과 재시도가 누적될 수 있다.
• 설정·자격증명 분리환경별 설정과 비밀값은 소스 코드와 분리하고, 운영 응답에 상세 예외 화면을 노출하지 않는다.
• 정적배포 후에는 정적 경로뿐 아니라 실제 프로그램 실행과 데이터 접근이 필요한 대표 요청도 확인한다.

10PHP 요청이 DB 결과로 응답되는 과정

• Nginx·PHPNginx가 PHP 요청을 PHP-FPM에 전달하는 구성을 가정한다.
• NginxNginx는 요청 경로와 설정에서 실행할 스크립트 경로 및 FastCGI 매개변수를 만들고 TCP 또는 Unix 소켓으로 FPM에 전달한다.
• FPM 실행과 DB 질의FPM의 작업자가 PHP 코드를 실행하고, 필요하면 별도 DB 연결을 이용해 매개변수화된 질의를 보낸다.
• DB·본문DB 결과를 받은 코드는 응답 본문과 헤더를 만들고 FastCGI 응답을 통해 웹 서버에 돌려준다.
• 웹 서버와 PHP 런타임웹 서버가 PHP 소스를 자체적으로 실행하는 구성과 혼동하지 않는다.
• FastCGIFastCGI 소켓에 연결할 권한과 PHP 작업자가 스크립트·업로드 경로에 접근할 권한은 다른 조건이다.
• SCRIPT_FILENAMESCRIPT_FILENAME 등의 경로 매핑이 잘못되면 파일이 존재해도 실행 대상을 찾지 못할 수 있다.
• 정적소스 파일이 정적 응답으로 노출되는 매핑 오류는 기능 실패보다 큰 정보 노출로 이어질 수 있다.
• 공개 경로와 실행 경로공개 경로와 실행 경로의 관계를 검토하고, 모든 파일 확장자를 무조건 실행기로 넘기는 규칙처럼 예상 범위가 넓은 구성을 피한다.

1. HTTP 요청동적 페이지에 해당하는 경로를 요청한다.
2. FastCGI 요청스크립트 경로와 요청 정보를 전달한다.
3. 매개변수화 질의PHP 코드가 필요한 데이터를 요청한다.
4. 질의 결과행·오류·트랜잭션 결과를 반환한다.
5. 실행 응답작업자가 헤더와 본문을 생성해 반환한다.
6. HTTP 응답클라이언트에 상태와 본문을 보낸다.

11처리량과 대기열을 함께 읽기

• 작업자·DB 연결 예산요청이 느릴 때 웹 서버의 연결 수만 늘리면 실행기나 DB의 병목은 그대로일 수 있다. FPM 작업자가 모두 바쁘면 새 요청이 기다리고, 작업자마다 DB 연결을 요구하면 DB 연결 한도에 먼저 도달할 수도 있다. 작업자 수를 늘릴 때는 작업자당 메모리와 DB 연결 예산을 함께 계산한다.
• 외부 I/O와 워커 대기외부 API나 느린 파일 I/O로 작업자가 붙잡혀 있는 상황과 CPU 계산으로 바쁜 상황도 다른 대책이 필요하다.
• 계층별 오류 연결웹 서버의 502·504, FPM 연결·작업자 로그, 애플리케이션 traceback, DB의 연결·잠금 상태를 같은 요청과 시각으로 연결한다.
• ASGIASGI 환경에서도 블로킹 함수를 무심코 호출하면 이벤트 루프의 진행을 막을 수 있고, WSGI와 ASGI는 단순히 빠른 버전·느린 버전으로 나뉘지 않는다.
• 동시성실행 인터페이스, 서버의 동시성 모델, 코드의 입출력 방식이 함께 처리 특성을 결정한다.
• 상세 오류의 노출진단용 상세 오류는 내부 기록에 남기고 외부 응답에서는 민감한 경로와 질의를 드러내지 않는다.