목차/05. 성능·가속·가상화 기능

05성능·가속·가상화 기능성능·가속·가상화 기능

방화벽이 얼마나 빠르게, 얼마나 크게 확장되는지 를 좌우하는 기술들과, 한 장비를 여러 방화벽으로 쪼개는 가상화를 한데 모은 장입니다. 여기서는 각 기능이 무엇을 하고 어떤 원리로 성능을 끌어올리는지 를 빠짐없이 설명하고, 깊은 튜닝은 Performance Tuning 가이드나 전용 가이드로 넘깁니다.

이중화와 부하 분산 — ClusterXL

ClusterXL동일한 게이트웨이 여러 대를 묶는 소프트웨어 클러스터 솔루션입니다. High Availability 클러스터는 장애 시 백업 게이트웨이로 투명하게 페일오버 해 연결·VPN을 지키고, Load Sharing 클러스터는 모든 멤버가 활성화되어 신뢰성과 성능을 함께 높입니다.

ClusterXL 구성
ClusterXL 구성

① 내부 네트워크 ② 내부망 스위치 ③ ClusterXL을 켠 Security Gateway들 ④ 외부망 스위치 ⑤ 인터넷

대역폭 관리 — QoS

QoS정책 기반 대역폭 관리 솔루션입니다. ERP·DB·웹 같은 업무 트래픽을 우선시하고, VoIP·화상회의에 대역폭을 보장하며 지연을 통제합니다. 계층적 WFQ(Weighted Fair Queuing) 알고리즘 으로 대역폭을 정밀 배분하며, 암호화·비암호화 트래픽 모두에 동작합니다.

QoS 구성
QoS 구성

① SmartConsole ② Security Management Server ③ QoS 정책 ④ QoS 블레이드를 켠 Security Gateway ⑤ 인터넷 ⑥ 내부 네트워크

QoS는 워낙 내용이 많아 별도의 Check Point R82 QoS 관리자 가이드 로 자세히 다룹니다.

가속의 첫걸음 — SecureXL

SecureXLSecurity Gateway를 지나는 트래픽을 가속 하는 가장 기본적인 가속 기술입니다. 가속은 한 대의 Security Gateway에서든, 클러스터의 각 Cluster Member에서든, Scalable Platform의 Security Group에서든 똑같이 동작합니다.

SecureXL은 게이트웨이를 통과하는 패킷을 빠른 경로로 처리해, 같은 하드웨어에서 더 많은 트래픽을 감당하게 만드는 토대가 됩니다. 뒤에 나오는 CoreXL·Multi-Queue·HyperFlow 도 모두 SecureXL과 맞물려 동작하므로, SecureXL은 사실상 모든 성능 가속의 출발점 이라고 보면 됩니다.

더 자세한 내용은 다음을 참고하세요.

  • Performance Tuning 가이드의 "SecureXL" 절
  • sk153832 — ATRG: SecureXL for R80.20 and above (Check Point Support Center의 Advanced 접근 권한 필요)
  • sk98348 — Best Practices - Security Gateway Performance

멀티코어 성능 — CoreXL

CoreXL멀티코어 플랫폼의 Security Gateway를 위한 성능 향상 기술 입니다. CPU 코어 여러 개가 여러 작업을 동시에 처리하게 만들어 게이트웨이 성능을 끌어올립니다.

CoreXL의 가장 큰 장점은 한 장비의 처리 코어 수에 따라 성능이 거의 선형으로 확장 된다는 점입니다. 더 중요한 것은 이 성능 향상에 관리 설정이나 네트워크 토폴로지 변경이 전혀 필요하지 않 다는 것입니다 — 코어만 충분하면 추가 손질 없이 그대로 빨라집니다.

동작 원리는 이렇습니다. CoreXL을 켜면 방화벽 커널이 여러 벌로 복제 됩니다. 복제된 방화벽 커널 한 벌을 CoreXL Firewall instance 라고 부르며, 각 인스턴스는 하나의 CPU 코어에서 실행 됩니다.

  • 이 CoreXL Firewall 인스턴스들은 트래픽을 동시에 처리합니다.
  • 각 인스턴스는 완전하고 독립된 방화벽 검사 커널 입니다.
  • CoreXL을 켜면 게이트웨이의 모든 방화벽 커널 인스턴스가 같은 인터페이스를 통해, 같은 보안 정책을 적용 해 트래픽을 처리합니다.

그리고 CoreXL Firewall 인스턴스는 SecureXL 인스턴스와 함께 동작 합니다 — 두 기술이 맞물려 가속 효과를 냅니다.

더 자세한 내용은 다음을 참고하세요.

  • Performance Tuning 가이드의 "CoreXL" 절
  • sk98737 — ATRG: CoreXL (Check Point Support Center의 Advanced 접근 권한 필요)
  • sk98348 — Best Practices - Security Gateway Performance

인터페이스 큐를 여러 코어로 — Multi-Queue

Multi-Queue 는 가속에 동원할 수 있는 코어 수의 한계를 풀어 줍니다. 기본적으로 네트워크 인터페이스 하나는 트래픽 큐(traffic queue) 하나를 가지며, 그 큐 하나를 CPU 하나가 처리 합니다. 이 구조에서는 트래픽을 처리하는 인터페이스 수보다 더 많은 CPU 코어를 가속에 쓸 수 없 다는 제약이 생깁니다 — 인터페이스가 두 개뿐이면 가속에 쓰이는 코어도 사실상 두 개로 묶이는 셈입니다.

Multi-Queue는 하나의 네트워크 인터페이스에 여러 개의 트래픽 큐를 구성 해 이 한계를 넘습니다. 이렇게 하면 인터페이스 하나당 둘 이상의 CPU 코어를 가속에 동원 할 수 있어, 인터페이스 수가 적어도 여러 코어를 충분히 활용하게 됩니다.

더 자세한 내용은 다음을 참고하세요.

대용량 연결 분산 처리 — HyperFlow

HyperFlow(R81.20 이상)는 이른바 elephant flow(엘리펀트 플로우) 를 다루는 기능입니다. elephant flow란 TCP나 UDP가 맺는 대용량의 연속된 연결 로, 전송하는 총 바이트 수가 매우 큰 연결을 말합니다. 예를 들어 HTTP·HTTPS·FTP·NFS 프로토콜로 Linux ISO 같은 큰 파일을 내려받는 경우가 대표적입니다. 이런 대용량 연속 연결은 다른 데이터 세션과 비교해 네트워크 용량을 압도적으로 많이 소모 합니다.

HyperFlow가 없을 때 의 문제는 두 가지입니다. 첫째, 게이트웨이는 하나의 elephant 연결을 단 하나의 CPU 코어(하나의 CoreXL Firewall 인스턴스)로만 검사 합니다. 둘째, 게이트웨이의 CPU 사용률이 올라갈수록 처리량이 점점 떨어 집니다.

HyperFlow는 이런 elephant 연결을 여러 CPU 코어에서 병렬로 처리합니다. 핵심은 전체 검사 작업을 더 작은 작업들로 쪼개, 가용한 여러 CPU 코어에 나눠 보내는 것입니다.

다음 표는 HyperFlow가 없을 때와 있을 때 작업이 어떻게 나뉘는지를 비교한 것입니다.

HyperFlow 없이 (한 코어에서 순차 처리)HyperFlow 적용 (여러 코어로 분산)
1. Packet retrieval(패킷 수신)1. CoreXL Firewall의 Inbound 처리: a. Packet retrieval b. Inbound Streaming c. Protocol parsers d. Context Management Interface(CMI)
2. Inbound Streaming2. 내부 PPE 처리(여러 CPU 코어에서): a. Pattern Match(PM)·Hash(MD5, SHA) b. Packet transmission
3. Protocol parsers3. CoreXL Firewall의 Outbound 처리: a. Software Blade logic b. Outbound Streaming c. Routing
4. Context Management Interface(CMI)
5. Pattern Match(PM)·Hash(MD5, SHA)
6. Software Blade logic
7. Outbound Streaming
8. Routing
9. Packet transmission

이렇게 분산한 결과 HyperFlow는 다음 효과를 냅니다.

  • Threat Prevention 블레이드가 켜진 상태에서도 elephant 연결의 처리량을 높입니다 — 게이트웨이가 elephant 연결을 검사하는 시간이 줄어듭니다. 단, 이는 네트워크 인프라 자체가 병목(bottleneck)이 아닐 때 만 가능합니다.
  • CPU 코어를 자동으로 감지하고 동적으로 할당 합니다 — 게이트웨이의 주요 작업들 사이에서 코어를 알아서 나눠 줍니다.
  • CoreXL FWK 프로세스의 응답 시간을 개선 합니다 — elephant 연결을 검사하는 동안 해당 CPU 코어들의 유휴 시간이 늘어납니다.

동작에 관해 반드시 알아 둘 점이 있습니다.

더 자세한 내용은 다음을 참고하세요.

콘텐츠 적응·프록시 — ICAP·HTTP(S) Proxy

ICAP(Internet Content Adaptation Protocol)투명 프록시를 확장하는 가벼운 HTTP 유사 프로토콜 로, 보통 바이러스 검사·콘텐츠 필터에 쓰입니다. 게이트웨이는 ICAP Client(메시지를 ICAP 서버로 보내 콘텐츠 적응 요청)·ICAP Server(받은 메시지를 적응 처리)·또는 둘 다 로 설정할 수 있어, 토폴로지 변경 없이 서드파티 ICAP 장비와도 연동됩니다(단, Scalable Platforms는 ICAP Server 미지원).

HTTP/HTTPS Proxy 는 게이트웨이를 호스트 사이의 중개자로 만듭니다. 직접 연결을 막고 클라이언트↔프록시, 프록시↔목적지 두 연결로 분리 합니다. Transparent 모드는 클라이언트 설정 없이 지정 포트·인터페이스의 트래픽을 가로채 고, Non Transparent 모드는 클라이언트에 프록시 서버·포트를 설정 해야 합니다.

가상화 — VSX

VSX(Virtual System eXtension)하나의 하드웨어에서 여러 개의 가상 방화벽을 돌리는 제품입니다.

Virtual System 은 하나의 Security Gateway처럼 동작하며, 보통 특정 네트워크 하나를 보호 합니다. 패킷이 VSX Gateway에 도착하면, 게이트웨이는 목적지 네트워크를 보호하는 Virtual System으로 트래픽을 보냅 니다. 그러면 그 Virtual System이 모든 트래픽을 검사하고, 보안 정책에 정의된 규칙에 따라 허용하거나 거부 합니다.

가상 네트워크가 어떻게 동작하는지 이해하려면 물리 네트워크 환경과 가상(VSX) 환경을 비교 해 보는 것이 좋습니다. 물리 네트워크는 여러 하드웨어 부품으로 이루어지지만, VSX 가상 네트워크는 단 하나의 구성 가능한 VSX Gateway 또는 클러스터 위에 존재 하면서, 가상 부품들과 함께 여러 개의 독립된 네트워크를 정의하고 보호 합니다.

물리 네트워크 토폴로지 예시. 여러 대의 Security Gateway를 두는 일반적인 배치에서는 게이트웨이 한 대가 각각 별도의 네트워크 하나 를 보호합니다. 각 물리 Security Gateway는 경계 라우터(perimeter router)로 가는 인터페이스와, 자기가 보호하는 네트워크로 가는 인터페이스 를 갖습니다.

물리 네트워크 토폴로지
물리 네트워크 토폴로지

① 인터넷 ② 라우터 ③ Security Gateway들 ④ 네트워크

VSX 가상 네트워크 토폴로지 예시. 위와 달리, 하나의 VSX Gateway에 네 개의 Virtual System 을 배치해 여러 네트워크를 한꺼번에 보호합니다.

물리 네트워크 vs VSX 가상 네트워크
물리 네트워크 vs VSX 가상 네트워크

① 인터넷 ② 라우터 ③ VSX Gateway(각 Virtual System은 물리 게이트웨이와 동일한 보안·네트워킹 기능을 갖고, 자기가 보호하는 네트워크 하나를 오가는 패킷을 처리) ④ Warp Link(Virtual System과 Virtual Switch를 잇는 가상 인터페이스·네트워크 케이블) ⑤ Virtual Switch(모든 Virtual System을 인터넷 라우터에 연결) ⑥ 네트워크들

VSX 역시 별도의 Check Point R82 VSX 관리자 가이드 로 자세히 다룹니다.