네이버 HTTPS 처리 플랫폼 nFront 설명
네이버가 수백만 HTTPS 요청을 처리할 수 있는 이유
<1> 전사공통 TLS/SSL Offloading 플랫폼
<2> HAProxy를 이용한 하이퍼스케일 TLS/SSL Offloading 플랫폼 구축
<3> 하이퍼스케일 트래픽을 대응하기 위한 ALL-in-One L7 ALB
<1> 전사공통 TLS/SSL Offloading 플랫폼
1
현황
HTTP의 보안 취약
HTTPS 사용 필요
2
변경전 ?
암호화 /복호화 진행 필요
HTTPS인증 도입 시 각서버의 부하 증가
개발자 인적 리소스 필요
인증서 갱신을 놓칠 경우 장애 발생
3
동작?
클라이언트-----HTTPS-------nFront (인증서 통합관리)----HTTP 트래픽만 ----오리진서버
4
개선?
중간에서 암호화 처리하여 웹서버 부하 감소 됨. CPU 리소스 절감.
인증서 관리 편함.
보안 패치, 설정을 빠르게 적용 가능
<2> HAProxy를 이용한 하이퍼스케일 TLS/SSL Offloading 플랫폼 구축
1
HAProxy는?
HTTP기반 애플리케이션을 위한 로드 밸런싱 제공
TLS/SSL Temination 기능을 제공하는 Reverse Proxy입니다.
2
일반적으로 네트워크 상에 새로운 레이어가 추가되면 Latency 등 성능문제가 가장 큰 문제로 다가온다.
암호화 트래픽을 위한 레이어를 추가할 때에도 문제 검토
결과?
HAProxy가 Latency 부분에서 가장 좋았다.
HAProxy가 자체적으로 SSL Temination을 지원하면서 여러 개의 인증서를 관리하기 편리한 점도 있었다.
다운 타임 없이 Semless Reload가 가능하다.
이러한 이유로, 네이버는 HAProxy를 기반으로 HTTPS 트래픽을 처리하고 있다.
3
nFront 팀에서 보안적인 안정성과 성능을 모두 고려해 관리 중.
프락시 서버에 대한 CPU 튜닝 진행.
자세한 내용은 DEVIEW 2021 NAVER 암호화 트래픽을 책임지는 HTTPS 플랫폼 기술 참고
4
인증서 관리?
Chain of Trust와 연동중. 백업도 마련 중.
하이브리드 인증서도 제공
<3> 하이퍼스케일 트래픽을 대응하기 위한 ALL-in-One L7 ALB
1
수백만 요청을 처리
2
IP, 포트뿐만 아니라 URL Path , Header , Cookie 등 L7 레이어 정보를 활용해 처리했다.
3
URL Path , Header , Cookie 등 L7 레이어 정보를 가지고 있어, nFront WAF(Web Appliction Firewall)로 사용가능
4
프락시서버는 오토 스케일링 사용 = ECMP, BGP , IPVS를 이용한다.
프락시서버 수백 대 모니터링.
5
Self-Provisoning 제공
개발자가 실시간 WAF, ALB기능도 같이 활용가능
6
네이버 페이, 네이버 웹툰, 네이버 쇼핑에 적용 중.
7
로그 분석 자동화 진행 중.
8
NFRONT를 Pass상품으로 제공하는 것을 계획 중임 (2023년 1월 현재)
다음
https://brunch.co.kr/@topasvga/2954
감사합니다.