리버스 프록시

서버를 인터넷에 그대로 내놓던 시절에는 서비스 하나에 주소 하나가 따라붙었습니다. 문서 서비스를 3000번 통로에 띄우고 검색 서비스를 4000번에 띄우면 사용자에게 알려 줄 주소가 두 개가 됩니다. 서비스가 다섯이면 다섯입니다.

주소만 늘어나는 것이 아니었습니다. 암호화 인증서를 서비스마다 따로 넣어 석 달에 한 번씩 다섯 곳을 갱신하고, 어디까지 허용할지 정한 규칙도 다섯 곳에 같은 내용으로 적어 둡니다. 한 곳에서 빠뜨리면 그 서비스만 조용히 뚫려 있습니다. 배포할 때도 걸렸습니다. 서버 주소가 사용자 쪽에 알려져 있으니 서버를 새 장비로 옮기려면 사용자에게 주소가 바뀐다고 알려야 했습니다.

리버스 프록시는 앞에 한 겹을 세워 이 문제를 풉니다. 바깥에서 오는 요청을 전부 이 한 곳이 받고, 받은 요청을 뒤쪽 서버로 넘깁니다. 사용자는 뒤에 서버가 몇 대인지도 어디에 있는지도 모릅니다. 프록시라는 말은 대리인이라는 뜻인데, 사용자를 대리하는 보통의 프록시와 방향이 반대라서 리버스가 붙었습니다. 이쪽은 서버를 대리합니다.

요청이 들어오는 입구를 한 곳으로 모으는 데서 나머지가 따라옵니다.

1. 입구가 하나가 됩니다. 사용자가 아는 주소는 하나이고, 프록시가 경로를 보고 뒷단을 고릅니다. /api 로 오면 문서 서비스로, /search 로 오면 검색 서비스로 넘기는 식입니다. 서비스를 하나 더 붙일 때 사용자 쪽에 알릴 것이 없습니다.
2. 뒷단이 감춰집니다. 내부 주소와 통로 번호가 밖에서 보이지 않으니 공격 대상이 프록시 한 곳으로 줄어듭니다. 뒤쪽 서버는 외부 접속을 아예 받지 않도록 막아 둘 수 있습니다.
3. 암호화를 한 곳에서 끝냅니다. 전송 구간을 암호화하는 표준인 TLS의 인증서를 프록시에만 넣어 두면 갱신도 한 번입니다. 프록시와 뒤쪽 서버 사이는 내부망이라 평문으로 주고받아도 되고, 뒤쪽 서버는 암호화를 신경 쓰지 않습니다.
4. 공통 처리를 앞에서 합니다. 한 번 만든 결과를 재사용하려고 저장해 두는 캐싱, 일정 시간에 받을 요청 수를 제한하는 요청 제한, 응답 압축, 접근 기록 남기기가 여기 붙습니다. 뒤쪽 서비스 다섯 곳에 같은 코드를 넣는 대신 한 곳에 설정으로 둡니다. 규칙을 바꿀 때 배포가 필요한 곳도 한 곳뿐입니다.
5. 뒷단을 바꿔도 앞이 흔들리지 않습니다. 서버를 새 장비로 옮기거나 대수를 늘릴 때 프록시가 가리키는 곳만 고치면 됩니다. 사용자 쪽 주소는 그대로입니다.

앞에 한 겹을 세운다는 점이 같은 부품이 여럿이라, 무엇을 고르느냐는 그 겹이 무엇까지 하느냐로 갈립니다.

1. 로드 밸런서는 요청을 여러 서버에 나눠 보내는 것이 목적입니다. 실무에서 쓰는 도구는 대개 둘을 같이 하기 때문에 이름이 섞여 쓰이는데, 서버가 한 대여도 리버스 프록시는 필요하고 로드 밸런서는 필요하지 않습니다.
2. API 게이트웨이는 여러 서비스의 입구를 하나로 모으면서 인증과 요금제별 사용량, 규격 판 관리까지 맡습니다. 리버스 프록시가 하는 일을 포함한 더 두꺼운 층이라, 외부 개발자에게 창구를 여는 제품에서 씁니다.
3. CDN은 이미지나 스크립트 같은 자원을 사용자에게 가까운 거점에서 내려 줍니다. 프록시보다 더 앞에 놓여 정적 자원을 먼저 처리하고, 나머지 요청만 프록시로 흘려보냅니다.
4. 아무것도 두지 않고 DNS로 나누는 방법도 있습니다. 도메인 이름을 주소로 바꿔 주는 체계인데, 서비스마다 다른 이름을 붙여 각 서버로 바로 보내는 식입니다. 붙일 것이 없어 가장 간단하지만 위의 다섯 가지를 전부 포기하게 됩니다.

"이건 리버스 프록시 설정에서 잡으면 되니 서비스 코드는 안 건드려도 됩니다."

공통 처리라서 앞단 한 곳에서 끝난다는 판단입니다.

"인증서가 프록시에만 있으니 뒤쪽 서버는 평문으로 받습니다."

암호화가 어디서 끝나는지를 확인해 주는 말입니다.

"프록시가 한 대뿐이면 거기가 죽으면 전부 죽습니다."

입구를 모은 대가로 생긴 단일 고장점을 지적하는 말입니다.

페이지덱에서는 태오가 서비스를 셋으로 나눈 뒤 이 층을 넣었습니다. 그전에는 문서, 검색, 알림이 각자 다른 주소로 열려 있었고 인증서 갱신이 석 달마다 세 번씩 돌아왔습니다. 한 번은 검색 쪽 갱신을 놓쳐 브라우저 경고가 떴고, 그날 문의가 40건 들어왔습니다.

프록시를 세운 뒤에는 인증서가 한 장으로 줄었습니다. 경로로 뒷단을 갈라 놓으니 서비스를 넷째로 붙일 때 프록시 설정에 한 줄을 더하는 것으로 끝났습니다. 대신 프록시가 멈추면 전부 멈추는 구조가 되어, 두 대를 띄워 한 대가 죽어도 다른 한 대가 받도록 바꿨습니다.

프록시와 리버스 프록시를 같은 것으로 보는 경우가 가장 많습니다. 이름이 거의 같고 하는 일도 중계라서 그렇습니다. 그런데 누구를 대리하는지가 반대입니다. 보통의 프록시는 사용자 쪽에 서서 사용자를 대리하고, 회사 안에서 직원들의 접속을 한 곳으로 모아 걸러 내는 자리에 놓입니다. 리버스 프록시는 서버 쪽에 서서 서버를 대리합니다. 이걸 섞어 두면 방화벽 규칙을 반대 방향으로 짜게 되고, 막아야 할 쪽을 열어 두는 설정이 나옵니다.

한 겹을 세우면 빨라진다고 읽는 것도 흔합니다. 캐싱과 압축을 앞에서 해 주니 그렇게 보입니다. 하지만 요청은 한 단계를 더 거치게 되고 그만큼 지연이 붙습니다. 캐시에 걸리는 요청에서는 이득이 훨씬 크지만, 매번 뒷단까지 가야 하는 요청에서는 프록시가 없을 때보다 느립니다. 그리고 입구가 하나라서 프록시가 멈추면 전부 멈춥니다. 앞단을 두는 결정에는 그 앞단을 두 대 이상으로 두는 결정이 같이 옵니다.