리버스 프록시 개선하기
들어가며
앞서 ‘웹 성능 진단하기’에서는 성능 향상을 위해서 프론트단에서 무엇을 해야 할지에 대해서 고민해보았다고 할 수 있다. 하지만 성능을 단지 ‘웹’으로 한정짓지 않고 어플리케이션 전체로 본다면 성능 향상을 위해서 고민해볼 수 있는 포인트들이 여러가지가 존재한다. 특히 API 서버의 경우에는 앞서 살펴보았던 ‘웹 성능 진단하기’에서의 것들은 사실 쓸 수 있는 것들이 없다.
그래서 이번 학습 주제인 ‘리버스 프록시 개선하기’를 정리하기에 앞서 어플리케이션 전체의 성능 향상관점에서 무엇들을 고민해 볼 수 있는지 포인트들을 잠깐 짚어보자.
웹
불필요한 다운로드를 제거
불필요한 작업을 지연로딩
다양한 압축 기술을 통해 각 리소스의 전송 인코딩을 최적화
스크립트 병합하여 요청수 최소화
스크립트 크기를 최소화하여 패킷 크기 자체를 줄임
서버
웹 프로토콜 최적화
캐싱을 활용하여 요청 수 최소화
어플리케이션 로직 개선
데이터베이스 SQL 최적화로 디스크 I/O 개선
만약 운영중인 서비스의 성능 향상을 고민해본다면 처음부터 접근 자체를 어떤 포인트들을 성능 개선의 타겟으로 삼을지 부터가 중요하다고 생각하는데, 그러한 포인트들을 이번 강의때 학습할 수 있었다. 서버 입장에서는 내부 로직이야 당연한 것이고 캐싱을 통해서 요청 수를 최소화 한다던가 sql 최적화와 같은 것들이 성능 개선의 포인트가 될 수 있겠다. 정리해두자.
캐싱을 통한 요청수 최소화
어플리케이션 로직 개선
SQL 최적화
1. nginx 특징
이 챕터에서 강사님이 전달코자 했던 내용은 리버스 프록시 서버의 성능 튜닝 포인트는 ‘클라이언트와의 커넥션을 어떻게 효율적으로 관리할 것인지’라는 것이었다. 하지만 그 이전에 nginx 자체의 특성에 대한 이해가 더 기본적이고 중요하다고 생각되어서 찾아봤고, 아래 딱 한 문장으로 정리가 되었다.
동시 request만큼 멀티스레드로 처리하는 아파치와는 달리 event handler가 loop를 돌면서 싱글 스레드로 이를 요청받아 worker process로 request를 넘겨주기 때문에 Context Swich에 따른 불필요한 자원낭비를 피할 수 있다는 것이다.
즉, nginx는 싱글 프로세스 스레드로 이벤트 구동에 의한 넌블로킹(Non-Blocking) 처리를 하므로 처리속도가 매우 빠릅니다. 그러나 넌블로킹 처리에 따라 프로그램의 제어가 이벤트 핸들러(Event Handler)로 넘어왔다고는 해도 실제 데이터를 읽고 쓰는건 OS(커널) 내에 있는 시스템 호출 프로그램과 하드웨어 사이에서 실행되므로, 해당 처리가 너무 길어지면(I/O 시간이 길어지면) 결국 시스템 호출 큐에 요청이 많이 쌓여 성능이 저하될 수 있습니다.
이런 사전 지식을 기반으로 nginx의 성능 튜닝 포인트는 ‘클라이언트와의 커넥션을 어떻게 효율적으로 관리할 것인지’라는 것이 소챕터의 핵심이었다.
2. HTTP 1.1 vs HTTP 2
HTTP 1.1과 HTTP 2.0의 가장 큰 차이는 클라이언트의 요청과 서버의 응답이 비동기 방식으로 이뤄지는 멀티플렉싱이 가능해졌다는 점이다. 한 커넥션에 여러 개의 메세지를 동시에 주고 받을 수 있다는 것이 멀티플렉싱의 핵심이다. 강의에서는 도식화된 그림을 통해서 더 상세히 배우긴 했지만 나중에 기회가 되면 더 자세히 공부해볼 생각이다.
아무튼 강의에서는 11번가와 네이버쇼핑을 비교하며 HTTP 1.1을 사용하고 있는 11번가의 속도와 HTTP 2를 사용하고 있는 네이버쇼핑의 비교를 통해서 실제로 화면이 누가 더 깔끔하게 렌더링 되는지를 보여주었다. 확실히 네이버가 더 깔끔했다.
아래는 강의에서 사용된 HTTP 2의 flow 이다.
인터넷을 돌아다니던 중 아래의 그림이 http 1.1 과 http 2 비교를 잘 해둔 것 같아서 가져왔다.
Last updated
