13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] OpenStack 네트워크

  • [OpenStack] OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드

    [OpenStack] OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드

    목차

    OpenStack VXLAN 오버레이 네트워크 성능 벤치마크 가이드

    OpenStack VXLAN 환경에서 성능이 얼마나 나오는지 궁금하신 분들 많으실 겁니다. VM은 잘 뜨는데, 막상 테넌트 네트워크를 여러 개 나누고 나면 트래픽 처리량이 생각보다 안 나오거나, 지연시간이 튀는 경우가 있거든요. 저도 처음엔 “VXLAN이면 그냥 캡슐화 하나 더 되는 거니까 조금만 느리겠지” 정도로 생각했는데, 실제로 홈랩과 운영 비슷한 구조에서 만져보니 **MTU, 오프로딩(offloading, NIC 하드웨어 처리), OVS(Open vSwitch, 가상 스위치) 경로**에 따라 체감이 꽤 달라지더라고요.

    이번 글에서는 OpenStack VXLAN 기반 오버레이 네트워크를 어떻게 벤치마크하면 좋을지, 그리고 Neutron VXLAN 환경에서 테넌트 격리와 처리량을 어떤 기준으로 봐야 하는지 정리해보겠습니다. 숫자를 지어내는 벤치마크 글은 의미가 없으니까, 이 글은 재현 가능한 측정 방법과 해석 기준에 초점을 맞췄습니다. 지금 OpenStack 네트워크 튜닝 중이시라면 꽤 바로 써먹으실 수 있을 거예요.

    컨트롤러, 컴퓨트 노드, 테넌트 네트워크, 터널 엔드포인트가 보이는 OpenStack VXLAN 개요 이미지입니다.

    1. 왜 OpenStack VXLAN 성능 벤치마크가 중요한가요?

    쉽게 말해 VXLAN(Virtual Extensible LAN, 가상 확장 LAN)은 물리 네트워크 위에 가상 네트워크를 하나 더 얹는 방식입니다. 멀티테넌트 환경에서는 정말 편하거든요. VLAN ID 제한에 덜 묶이고, 테넌트별 네트워크를 유연하게 분리할 수 있으니까요. 근데 여기서 중요한 포인트가 있어요. 편리함과 성능은 항상 같은 방향으로 가지는 않는다는 점 말이에요.

    • 캡슐화(encapsulation, 패킷을 한 번 더 감싸는 작업) 오버헤드가 생깁니다.
    • MTU 설정이 맞지 않으면 단편화(fragmentation, 패킷 쪼개짐)로 성능이 무너질 수 있습니다.
    • OVS나 Linux bridge 경로에 따라 CPU 사용률이 크게 달라집니다.
    • east-west traffic(이스트-웨스트 트래픽, VM 간 내부 통신)과 north-south traffic(노스-사우스 트래픽, 외부와의 통신)을 나눠서 봐야 합니다.

    실제로 써보니까 성능 저하 자체보다 더 무서운 건 병목 지점을 모른 채 감으로 튜닝하는 상황이었어요. 이게 제일 오래 갑니다. 삽질 좀 했습니다 ㅎㅎ

    2. OpenStack VXLAN과 Neutron VXLAN 개념, 쉽게 정리해보겠습니다

    OpenStack 네트워크에서 VXLAN은 보통 Neutron(뉴트론, OpenStack 네트워크 서비스)의 오버레이 메커니즘으로 사용돼요. 각 컴퓨트 노드는 터널 종단점 VTEP(VXLAN Tunnel Endpoint, VXLAN 터널 끝점) 역할을 하고, 테넌트 네트워크 트래픽을 UDP 기반 VXLAN 패킷으로 캡슐화해 전달합니다.

    2-1. 데이터 경로를 이해하면 벤치마크 포인트가 보입니다

    1. VM에서 패킷이 나갑니다.
    2. 가상 NIC를 통해 보안 그룹과 가상 스위치를 통과합니다.
    3. 로컬 브리지에서 VXLAN 캡슐화가 이뤄집니다.
    4. 물리 underlay(언더레이, 실제 네트워크)로 전송됩니다.
    5. 상대 노드에서 디캡슐화(decapsulation, 캡슐 해제) 후 대상 VM으로 들어갑니다.

    여기서 성능 포인트는 명확해요. 가상 스위치 처리, 터널 캡슐화, 물리 NIC, MTU 이 네 군데를 봐야 합니다.

    2-2. VLAN과 VXLAN 비교

    항목 VLAN VXLAN
    격리 방식 L2 태그 기반 오버레이 터널 기반
    확장성 상대적으로 제한적 멀티테넌트 확장에 유리
    설계 복잡도 비교적 단순 터널, MTU, 오프로딩 고려 필요
    성능 변수 상대적으로 적음 캡슐화 오버헤드 영향 있음
    OpenStack 활용 Provider network에 자주 사용 Tenant network에 자주 사용

    벤치마크를 할 때는 “VXLAN이 느리다”가 아니라, 어떤 경로에서 얼마나 손실이 생기는지를 봐야 합니다.

    3. 벤치마크 설계: 오버레이 네트워크 성능을 정확히 측정하려면

    제가 직접 해보니 벤치마크가 실패하는 가장 흔한 이유는 측정 항목이 너무 단순하다는 거였어요. `iperf3` 한 번 돌려보고 끝내면, 그건 네트워크 테스트라기보다 순간 샘플에 가까우니까요.

    3-1. 최소 측정 항목

    • 처리량(throughput, 초당 전송량): TCP/UDP 각각 확인
    • 지연시간(latency, 왕복 시간): ping 또는 fping으로 확인
    • 패킷 손실(packet loss): UDP 테스트에서 특히 중요
    • CPU 사용률: 컴퓨트 노드의 `ovs-vswitchd`, `qemu-kvm`, `softirq` 확인
    • MTU 일관성: 인스턴스, TAP, 브리지, 물리 NIC가 연결되는지 확인

    3-2. 테스트 시나리오

    1. 같은 컴퓨트 노드 내 VM 간 통신
    2. 다른 컴퓨트 노드 간 VM 통신
    3. 같은 테넌트 네트워크 내 다수 VM 동시 통신
    4. 서로 다른 테넌트 간 격리 검증
    5. floating IP 또는 router를 통한 외부 통신

    여기서 두 번째와 세 번째가 핵심이에요. 첫 번째만 보면 터널 영향이 덜 보일 수 있거든요. 반대로 크로스-노드(cross-node, 노드 간) 테스트를 해보면 오버레이 네트워크 성능 차이가 확실히 드러납니다.

    4. 실전 구현: OpenStack VXLAN 테스트 환경 준비

    이제 실제로 측정 가능한 구조를 만들어보겠습니다. 예시는 OpenStack CLI 기준으로 적겠습니다. 배포판은 다양하지만, 개념은 거의 비슷해요.

    4-1. 테넌트 네트워크 생성

    openstack network create demo-vxlan-net
openstack subnet create demo-vxlan-subnet \
  --network demo-vxlan-net \
  --subnet-range 10.10.10.0/24

openstack router create demo-router
openstack router add subnet demo-router demo-vxlan-subnet

    환경에 따라 외부 네트워크 연결도 필요합니다.

    openstack router set demo-router --external-gateway public

    4-2. 테스트용 인스턴스 2대 이상 배치

    openstack server create vxlan-test-1 \
  --flavor m1.small \
  --image ubuntu \
  --network demo-vxlan-net \
  --key-name mykey

openstack server create vxlan-test-2 \
  --flavor m1.small \
  --image ubuntu \
  --network demo-vxlan-net \
  --key-name mykey

    여기서 가능하면 서로 다른 컴퓨트 노드에 올리는 게 좋아요. 스케줄러 힌트나 가용성 영역을 활용하면 더 명확하게 분리할 수 있습니다.

    4-3. ML2 VXLAN 설정 확인

    배포 환경마다 파일 위치가 다를 수 있지만, 핵심은 ML2 plugin(ML2 플러그인)과 VXLAN 타입 드라이버가 활성화되어 있는지에요.

    [ml2]
type_drivers = flat,vlan,vxlan
tenant_network_types = vxlan
mechanism_drivers = openvswitch,l2population

[ml2_type_vxlan]
vni_ranges = 1001:2000

    `l2population`은 브로드캐스트/플러딩을 줄이는 데 도움이 되는 기능으로 잘 알려져 있어요. 대규모 환경일수록 의미가 커집니다.

    Neutron ML2 설정, VNI 범위, 각 컴퓨트 노드의 VXLAN 터널 연결 관계를 보여주는 이미지입니다.

    4-4. MTU 확인은 꼭 하셔야 합니다

    VXLAN은 추가 헤더가 붙기 때문에 underlay MTU보다 tenant MTU를 조금 보수적으로 잡는 경우가 많아요. 이 부분을 놓치면 `iperf3`는 애매하게 나오고, 대용량 전송에서만 문제가 재현되기도 합니다. 저도 처음엔 보안 그룹만 의심했는데, 결국 MTU 문제였던 적이 있었어요.

    ip link show
ip addr
ping -M do -s 1472 <target_ip>

    `-M do`는 경로 MTU를 강제로 확인할 때 유용해요. 패킷 크기를 조금씩 조정해보면 어디서 단편화가 발생하는지 감이 옵니다.

    5. 성능 측정 방법: iperf3, ping, 시스템 지표를 같이 보세요

    5-1. 기본 처리량 측정

    테스트 VM 한쪽에서는 서버를 띄우고, 다른 쪽에서는 클라이언트로 붙습니다.

    # server
iperf3 -s

# client
iperf3 -c 10.10.10.20 -t 30 -P 4

    여기서 `-P 4`처럼 병렬 스트림(parallel stream, 동시 세션)을 주는 이유는 단일 세션만으로는 경로 활용도를 다 못 볼 수 있기 때문이에요.

    5-2. UDP와 손실률 확인

    iperf3 -c 10.10.10.20 -u -b 1G -t 30

    UDP는 대역폭을 강제로 밀어붙이니까 손실과 지터(jitter, 지연 변동폭)를 보기 좋아요. 다만 숫자만 보고 “실사용도 이렇다”고 단정하면 안 돼요. 어디까지나 한계 구간을 찾는 용도에 가깝습니다.

    5-3. 지연시간과 격리 검증

    ping -c 20 10.10.10.20

openstack network create isolated-net
openstack subnet create isolated-subnet \
  --network isolated-net \
  --subnet-range 10.20.20.0/24

    서로 다른 테넌트 네트워크에서 직접 통신이 안 되는지 확인해보세요. 테넌트 격리는 보안 기능이자 성능 분석의 기준선이에요. 격리가 흐트러지면 벤치마크 이전에 설계부터 다시 봐야 합니다.

    5-4. 호스트 측 관찰 포인트

    top
htop
sar -n DEV 1
ip -d link show
ovs-vsctl show
ovs-ofctl dump-ports br-tun

    성능이 기대보다 안 나오는데 VM 내부는 멀쩡하다면, 호스트의 softirq나 OVS 포트 카운터를 같이 봐야 해요. 근데 여기서 중요한 건, 네트워크만 보지 말고 CPU를 같이 보라는 점이에요. 오버레이는 생각보다 CPU 영향을 받거든요.

    6. ⚠️ 트러블슈팅: 실제로 자주 막히는 지점

    이 섹션은 정말 중요해요. 제가 홈랩에서 OpenStack 네트워크 만질 때 제일 오래 잡아먹은 부분들이거든요.

    6-1. MTU 불일치

    • 증상: TCP는 되는데 대용량 전송에서 처리량이 애매하게 떨어짐
    • 원인: VXLAN 캡슐화 헤더를 고려하지 않은 MTU 설정
    • 해결: 인스턴스 NIC, TAP, `br-int`, `br-tun`, 물리 NIC까지 경로 전체 MTU 점검

    6-2. 오프로딩 설정 이슈

    • 증상: CPU 사용률이 과하게 올라가고 처리량이 들쭉날쭉함
    • 원인: NIC offload와 가상화 경로 조합 문제
    • 해결: `ethtool -k`로 현재 상태를 보고 변경 전후 비교 측정
    ethtool -k eth0

    이건 환경마다 정답이 달라요. 무조건 켜라, 무조건 꺼라 식으로 가면 위험해요. 그래서 반드시 변경 전후를 같은 조건으로 비교해야 합니다.

    6-3. 보안 그룹과 conntrack 병목

    • 증상: 연결 수가 늘면 응답이 갑자기 무거워짐
    • 원인: stateful filtering(상태 기반 필터링)과 connection tracking 부담
    • 해결: 테스트 시나리오를 단순화하고, 보안 정책 영향도 분리해서 확인

    6-4. 같은 노드와 다른 노드 성능 차이

    같은 컴퓨트 노드 안에서는 생각보다 잘 나오는데, 다른 노드로 넘어가는 순간 성능이 달라지는 경우가 많아요. 이럴 때는 거의 대부분 터널 경로 또는 물리 underlay를 의심하게 됩니다.

    VM 간 iperf3 측정, 호스트 CPU 사용률, MTU 점검 포인트가 함께 보이는 실전 운영 이미지입니다.

    7. 검증과 결과 해석: 숫자보다 중요한 것

    벤치마크 결과를 볼 때 저는 보통 아래 순서로 해석해요. 숫자 하나만 보고 결론 내리면 나중에 꼭 후회하더라고요.

    1. 같은 노드와 다른 노드 간 격차가 큰가
    2. TCP와 UDP 결과 차이가 과도한가
    3. 지연시간 평균보다 편차가 큰가
    4. 호스트 CPU 사용률이 병목처럼 보이는가
    5. 테넌트 수 증가 시 성능 하락 패턴이 급격한가

    예를 들어 처리량이 조금 낮아도 지연시간이 안정적이고 손실이 적다면, 실서비스에서는 충분히 좋은 결과일 수 있어요. 반대로 순간 최대 처리량이 높아도 CPU가 포화되고 지터가 심하면 운영 입장에서는 불안한 구조죠.

    검증 항목 좋은 신호 주의 신호
    처리량 반복 측정 시 편차가 작음 테스트마다 편차가 큼
    지연시간 평균과 최대값 차이가 적당함 간헐적 스파이크 발생
    패킷 손실 UDP 부하에서도 통제 가능 부하 시 급격히 증가
    CPU 사용률 여유가 있음 ovs-vswitchd 또는 softirq 집중
    격리 상태 테넌트 간 통신 차단 명확 정책 누락 또는 라우팅 혼선

    오버레이 네트워크 성능은 결국 설계와 운영 습관의 결과물이에요. 그래서 결과 보고서에는 숫자만 넣지 말고, 테스트 조건도 같이 남기시는 걸 권장합니다. 다음에 다시 비교할 때 진짜 큰 도움이 돼요.

    OpenStack VXLAN 벤치마크 결과와 지연시간 처리량을 보여주는 대시보드 이미지

    처리량, 지연시간, CPU 사용률을 함께 보여주는 OpenStack VXLAN 벤치마크 결과 시각화 이미지입니다.

    8. 정리와 다음 단계: OpenStack 네트워크 튜닝은 이렇게 이어가시면 됩니다

    정리해보면 OpenStack VXLAN 벤치마크에서 중요한 건 단순 최고 속도가 아니에요. Neutron VXLAN 환경에서 테넌트 격리가 제대로 되는지, 크로스-노드 트래픽이 안정적인지, MTU와 OVS 경로가 일관적인지, 그리고 호스트 CPU가 어디서 쓰이는지를 같이 봐야 합니다.

    제가 직접 해보니 가장 효과가 컸던 접근은 이것이었어요.

    1. 같은 노드와 다른 노드 결과를 분리해서 기록합니다.
    2. TCP, UDP, ping을 각각 따로 봅니다.
    3. 문제가 보이면 MTU와 오프로딩부터 확인합니다.
    4. 그 다음에 보안 그룹, conntrack, underlay를 봅니다.

    이 순서로 가면 삽질을 꽤 줄일 수 있어요. 드디어 됐다! 싶은 순간이 오거든요.

    OpenStack VXLAN 성능 최적화 체크리스트와 비교 요약 인포그래픽

    MTU, 오프로딩, OVS, 테넌트 격리, 처리량 검증 항목을 한눈에 정리한 요약 인포그래픽입니다.

    자주 묻는 질문

    Q1. VXLAN이면 무조건 VLAN보다 느린가요?

    무조건 그렇지는 않아요. 캡슐화 오버헤드는 있지만, 실제 체감은 NIC 성능, CPU, OVS 구성, underlay 품질에 따라 달라집니다.

    Q2. 벤치마크는 어떤 도구부터 쓰면 좋을까요?

    가볍게는 `ping`, `iperf3`, `sar`, `ethtool`, `ovs-vsctl` 정도면 시작하기 좋아요. 도구보다 중요한 건 같은 조건으로 반복 측정하는 습관입니다.

    Q3. 테넌트 격리는 어떻게 검증하나요?

    서로 다른 테넌트 네트워크에 VM을 두고 직접 통신 가능 여부, 라우터 연결 여부, 보안 그룹 정책을 분리해서 확인하시면 돼요.

    다음 글에서는 Open vSwitch 기반에서 `br-int`, `br-tun`, provider network 경로를 좀 더 깊게 파서, 어디서 병목이 생기는지 보는 방법을 다뤄볼 예정입니다. 이전 글에서 다룬 Linux 네트워크 기본기와 함께 보시면 훨씬 이해가 잘 될 거예요.

  • [클라우드 보안] OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략

    [클라우드 보안] OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략

    목차

    [클라우드 보안] OpenStack 보안 그룹 취약점과 Floating IP 보안 강화 전략

    OpenStack 운영하다 보면 제일 많이 방심하는 지점 중 하나가 바로 보안 그룹(Security Group, 가상 방화벽 정책)과 Floating IP(플로팅 IP, 공인 IP를 인스턴스에 동적으로 붙이는 기능) 조합이에요. 저도 홈랩이랑 사내 테스트 환경에서 처음 이 구조를 만졌을 때는 “보안 그룹만 잘 걸어두면 끝 아닌가?” 싶었는데, 실제로 뜯어보면 그렇지 않더라고요. 특히 OpenStack 보안 그룹 취약점이라고 검색해서 들어오신 분들이라면, 단순히 룰 몇 개 추가하는 수준이 아니라 연결 상태(state), NAT(Network Address Translation, 네트워크 주소 변환), 정책 권한까지 같이 봐야 한다는 게 핵심이에요.

    이번 글은 2014년에 공개된 OpenStack Security Note OSSN-0020에서 다뤄진 Floating IP 분리 후 기존 NAT 연결이 살아남는 문제, 그리고 2022년 이후에도 논의된 특정 Floating IP 지정 시 외부 네트워크 게이트웨이 IP와 충돌할 수 있는 운영 리스크를 바탕으로 정리했어요. 즉, 새로운 미확인 이슈를 다루는 게 아니라, 실제로 문서화된 동작과 운영상 취약 지점을 기준으로 Floating IP 보안 전략을 재구성한 분석입니다.

    보안 그룹, Neutron 라우터, 외부 네트워크, 인스턴스 사이의 트래픽 흐름을 한눈에 보여주는 개요 이미지가 들어갈 자리입니다.

    1. 왜 이 이슈를 다시 봐야 하나요

    공식 보안 노트 OSSN-0020은 Neutron L3 agent 환경에서 Floating IP를 해제해도 이미 맺어진 연결(established connection)은 바로 끊기지 않을 수 있다고 설명해요. 쉽게 말해, 운영자는 “공인 IP를 떼었으니 외부 접근도 끝났다”고 생각했는데, 실제 세션은 계속 살아 있는 상황이 생길 수 있다는 뜻이거든요.

    이게 위험한 이유는 장애 대응이나 침해 대응 때 판단을 잘못하게 만들기 때문이에요. 예를 들어 외부에서 SSH가 붙어 있던 인스턴스에서 이상 행위가 발견돼서 Floating IP만 급하게 떼는 경우가 있잖아요. 저도 예전에 비슷하게 대응했다가, “어? 왜 세션이 안 죽지?” 하고 한참 봤던 적이 있어요. 나중에야 알았는데 보안 그룹 정책과 Floating IP 분리만으로 세션 종료가 보장되지 않는다는 게 핵심이었거든요.

    2. OpenStack 보안 그룹 취약점, 쉽게 말해 뭐가 문제인가요

    보안 그룹(Security Group)은 Neutron 포트에 붙는 가상 방화벽이에요. 기본적으로 Ingress(인그레스, 외부에서 안으로 들어오는 트래픽)는 막고, Egress(이그레스, 내부에서 바깥으로 나가는 트래픽)는 허용하는 구성이 많아요. 문서 기준으로도 보안 그룹은 포트 단위로 적용되고, 여러 그룹이 붙으면 룰은 가산적(additive)으로 합쳐진답니다.

    문제는 여기서 Floating IP가 끼어들 때 생겨요. Floating IP는 인스턴스 NIC에 공인 IP를 직접 꽂는 느낌이라기보다, 대개 Neutron 라우터의 NAT 경로를 통해 외부와 연결돼요. 그래서 정책을 바꿨다고 해서 이미 형성된 세션이 운영자가 기대하는 순간에 깔끔하게 정리되는 건 아닐 수 있다는 뜻이에요.

    정리하면 OpenStack 보안 그룹 취약점은 단순히 “룰이 뚫린다”가 아니라, 다음처럼 여러 층에서 나타나요:

    • 상태 기반 연결 잔존: Floating IP를 떼어도 기존 세션이 남을 수 있어요.
    • 과도한 권한: 특정 public IP를 사용자가 직접 지정하게 두면 외부 네트워크와 충돌 가능성이 생겨요.
    • 예외 기능 남용: allowed-address-pairs나 port_security 예외를 잘못 쓰면 정책 의미가 흐려져요.
    • 운영 착시: 콘솔에서 “분리됨”으로 보여도 실제 통신은 곧바로 끊기지 않을 수 있어요.

    3. 공식 문서 기준으로 봐야 할 핵심 포인트

    항목 확인된 사실 운영 의미
    OSSN-0020 Floating IP 분리 후 기존 NAT 연결이 남을 수 있음 침해 대응 시 FIP 분리만으로 종료 판단하면 위험
    보안 그룹 기본 동작 포트 단위 적용, 룰은 가산적 적용 인스턴스 단위로만 생각하면 누락이 생겨요
    Neutron 정책 create_floatingip:floating_ip_address 권한을 정책으로 제어 가능 특정 공인 IP 직접 지정 권한을 축소할 수 있어요
    Allowed Address Pairs 특정 조건에서 원격 그룹 기반 제한을 우회할 수 있다는 경고 존재 예외 기능은 최소화해야 해요
    정책 파일 형식 JSON 정책 파일은 deprecated, YAML 권장 하드닝 작업은 policy.yaml 기준으로 정리하는 게 안전해요

    제가 직접 문서랑 버그 토론을 다시 읽어보니, 많은 분이 “이게 CVE냐 아니냐”에만 집중하시더라고요. 근데 운영자 입장에서는 그보다 지금 내 클라우드에서 어떤 권한과 어떤 연결이 실제로 남느냐가 훨씬 중요해요. 특히 Floating IP 보안은 네트워크 설계, 테넌트 권한, 대응 절차를 같이 봐야 실수가 줄어들거든요.

    4. 실전 구현: Floating IP 보안 강화 체크리스트

    4-1. 현재 노출 범위부터 확인하기

    처음엔 화려한 정책부터 만지지 마시고, 현재 어떤 인스턴스가 외부로 열려 있는지부터 봐야 해요. 이 단계 건너뛰면 진짜 자주 꼬여요.

    openstack floating ip list
openstack server list --long
openstack port list --server <SERVER_NAME>
openstack security group list
openstack security group rule list <SECURITY_GROUP_NAME>

    여기서 확인할 건 세 가지예요:

    1. 어떤 인스턴스에 Floating IP가 붙어 있는지
    2. 해당 포트에 어떤 보안 그룹이 붙어 있는지
    3. 0.0.0.0/0 같은 광범위 Ingress 규칙이 있는지

    4-2. 보안 그룹을 최소 허용(Least Privilege)으로 다시 자르기

    SSH, HTTPS처럼 꼭 필요한 포트만 열고, 출발지 IP도 가능한 한 좁게 잡는 게 가장 실효성 있어요. 기본처럼 들리지만 체감 효과가 정말 크거든요.

    openstack security group create web-tight
openstack security group rule create web-tight \
  --ingress --ethertype IPv4 --protocol tcp --dst-port 22 \
  --remote-ip 203.0.113.10/32
openstack security group rule create web-tight \
  --ingress --ethertype IPv4 --protocol tcp --dst-port 443 \
  --remote-ip 0.0.0.0/0

    운영 환경이면 22번도 bastion host(배스천 호스트, 점프 서버) 대역으로 더 좁히는 걸 권해요. 저도 처음엔 귀찮아서 넓게 열었다가, 나중에 로그 뒤지면서 후회했거든요.

    Floating IP 보안 강화를 위한 OpenStack 보안 그룹 최소 허용 구성 다이어그램

    실전 구현 단계에서 보안 그룹을 최소 허용 형태로 재구성하는 흐름을 설명하는 이미지가 들어갈 자리입니다.

    4-3. 특정 Floating IP 직접 지정 권한 줄이기

    Neutron 정책 문서를 보면 create_floatingip:floating_ip_address 권한을 따로 제어할 수 있어요. 이게 중요한 이유가 있거든요. Launchpad에 2022년 등록된 논의에서는, 사용자가 특정 IP를 수동 지정할 때 외부 네트워크의 게이트웨이 IP와 같은 값을 요청할 수 있는 운영 리스크가 지적됐어요. 이건 문서상 “무조건 취약점”으로 확정된 CVE는 아니지만, 운영 사고로 번질 수 있는 위험한 설계 포인트가 맞아요.

    그래서 실무에서는 보통 임의의 공인 IP 지정 권한을 일반 사용자에게 열어두지 않는 쪽이 낫더라고요.

    # /etc/neutron/policy.yaml
create_floatingip: "(rule:admin_only) or (role:member and project_id:%(project_id)s)"
create_floatingip:floating_ip_address: "rule:admin_only"
update_floatingip: "(rule:admin_only) or (role:member and project_id:%(project_id)s)"
delete_floatingip: "(rule:admin_only) or (role:member and project_id:%(project_id)s)"

    이렇게 하면 일반 테넌트 사용자는 Floating IP 자체는 할당받되, 특정 공인 IP를 집어서 요청하는 행위는 막을 수 있어요. OpenStack 보안 강화 관점에서 생각보다 효과가 커요.

    4-4. 예외 기능 점검하기: Port Security와 Allowed Address Pairs

    여기서 많이 놓치는 게 Port Security(포트 보안)예요. 어떤 포트가 --disable-port-security 상태면 보안 그룹 기대치가 달라질 수 있거든요. 그리고 OpenStack API 문서에는 allowed-address-pairs를 특정 방식으로 쓰면, 같은 보안 그룹을 쓰는 포트들에 대해 source IP 제한 성격의 룰 우회가 가능하다는 경고도 있어요.

    openstack port show <PORT_ID> -f yaml
openstack port list --long
openstack port set --enable-port-security <PORT_ID>

    물론 실제 적용 전에는 LB(Load Balancer, 로드밸런서), VRRP, VIP 같은 예외 설계가 있는지 꼭 확인하셔야 해요. 이 부분 모르고 일괄 적용하면 서비스가 바로 흔들려요. 저도 HA 테스트하다가 VIP가 안 떠서 한참 봤던 기억이 있네요.

    4-5. 침해 대응 절차는 “FIP 분리”로 끝내지 않기

    이 부분이 제일 중요해요. OSSN-0020 기준으로는, Neutron L3 agent 환경에서 Floating IP를 분리해도 기존 연결이 남을 수 있거든요. 그러니까 의심 세션 차단이 목적이라면 절차를 이렇게 가져가야 한다는 뜻이에요:

    1. 인스턴스 상태 확인
    2. 필요 시 인스턴스 정지 또는 종료
    3. 그 다음 Floating IP 분리
    4. 재기동 후 필요한 보안 그룹만 재적용
    openstack server stop <SERVER_NAME>
openstack server remove floating ip <SERVER_NAME> <FLOATING_IP>
openstack server start <SERVER_NAME>

    환경에 따라 완전 종료 대신 격리 네트워크로 포트를 옮기는 방식도 쓰지만, 최소한 Floating IP만 떼고 끝났다 판단하는 건 위험해요.

    5. ⚠️ 실제 운영에서 자주 겪는 문제와 해결법

    • 문제 1: 보안 그룹 룰은 지웠는데 세션이 살아 있어요.
      해결: 기존 연결 추적 상태를 의심해야 해요. 긴급 대응이면 인스턴스 정지/격리까지 포함해 절차를 바꾸는 게 안전해요.
    • 문제 2: 특정 테넌트가 이상한 공인 IP를 요청해요.
      해결: create_floatingip:floating_ip_address 권한을 축소하고, 직접 지정 대신 자동 할당만 허용하세요.
    • 문제 3: 포트 보안 예외 때문에 정책 검증이 안 맞아요.
      해결: port_security_enabled, allowed_address_pairs, 보안 그룹 바인딩 상태를 같이 점검하세요.
    • 문제 4: “기본 보안 그룹이 있으니 괜찮겠지”라고 생각해요.
      해결: 기본 그룹은 출발점일 뿐이에요. 워크로드별 전용 그룹으로 분리하는 게 맞아요.

    혹시 이런 경험 있으신가요? 콘솔에는 아무 문제 없어 보이는데 실제 네트워크는 다르게 움직이는 상황이요. OpenStack 네트워킹은 특히 이런 “보이는 상태와 실제 데이터 플레인 상태의 차이”가 자주 나타나거든요.

    6. 검증: 강화 후 무엇을 확인해야 하나요

    설정하고 끝내면 안 돼요. 검증이 없으면 보안은 그냥 희망사항이거든요.

    openstack floating ip list --long
openstack security group rule list web-tight
openstack port show <PORT_ID> -f yaml
openstack server show <SERVER_NAME>
    1. Floating IP가 정말 필요한 인스턴스에만 붙어 있는지 확인하세요.
    2. 보안 그룹 Ingress 규칙이 최소 범위인지 다시 봐요.
    3. Port Security가 예외 없이 켜져 있는지 점검해요.
    4. 의심 인스턴스는 FIP 제거 후 기존 세션이 끊겼는지 운영 절차로 검증하세요.

    추가로 가능하다면 FWaaS(Firewall-as-a-Service, 서비스형 방화벽)나 외부 방화벽 계층을 같이 두는 것도 좋아요. 보안 그룹만으로 모든 걸 해결하려고 하면 경계 보안이 얇아져요. 특히 클라우드 보안은 “한 겹 더”가 생각보다 큰 차이를 낸다고 느껴봤거든요.

    OpenStack 보안 그룹 취약점 대응 후 Floating IP 보안 검증 결과 대시보드

    적용 전후로 외부 노출 범위가 어떻게 줄었는지 보여주는 결과 검증 이미지가 들어갈 자리입니다.

    7. 운영 기준으로 정리하는 Floating IP 보안 원칙

    원칙 권장 여부 이유
    모든 VM에 Floating IP 부여 비권장 공격 표면이 불필요하게 넓어져요.
    특정 공인 IP 직접 지정 허용 제한 권장 외부 네트워크와 충돌할 여지를 줄일 수 있어요.
    보안 그룹 최소 허용 구성 강력 권장 실수 범위를 가장 확실하게 줄여요.
    Port Security 예외 최소화 강력 권장 정책 일관성이 깨지는 걸 막아요.
    침해 대응 시 인스턴스 정지 포함 권장 기존 연결 잔존 위험에 대응할 수 있어요.

    제가 직접 운영하면서 느낀 건, Floating IP 보안은 네트워크 팀 일만도 아니고, 클라우드 플랫폼 팀 일만도 아니라는 거예요. 권한 정책, 라우팅/NAT 동작, 테넌트 가이드, 대응 플레이북이 같이 맞물려야 드디어 안정된다는 느낌이 들어요. 드디어 됐다 싶을 때도 꼭 한 번 더 검증하는 게 좋거든요.

    8. 자주 묻는 질문과 마무리

    Q1. Floating IP를 떼면 외부 접근은 즉시 끝나는 것 아닌가요?

    그렇지 않아요. 최소한 OSSN-0020에서 설명된 Neutron L3 agent 동작 기준으로는 기존 연결이 남을 수 있거든요.

    Q2. 이 이슈가 곧바로 최신 CVE라는 뜻인가요?

    그건 아니에요. 이 글은 공식 보안 노트와 문서화된 동작, 그리고 운영상 재현 가능한 위험 지점을 분석한 글이거든요.

    Q3. 가장 먼저 적용할 한 가지는 뭔가요?

    제라면 특정 Floating IP 직접 지정 권한 제한과 0.0.0.0/0 Ingress 축소부터 하겠어요. 체감 효과가 정말 커요.

    OpenStack 보안 그룹 취약점과 Floating IP 보안 대응 전략 요약 인포그래픽

    보안 그룹 최소 허용, 정책 권한 제한, 포트 보안 점검, 대응 절차 개선을 요약한 인포그래픽이 들어갈 자리입니다.

    정리해보면, OpenStack 보안 그룹 취약점을 볼 때 핵심은 “보안 그룹 룰이 있느냐”가 아니라 “그 룰이 실제 연결 종료와 권한 통제까지 보장하느냐”예요. Floating IP는 정말 편해요. 근데 편한 만큼 공격 표면도 넓어지거든요. 이번 기회에 외부 노출 인스턴스 목록, 보안 그룹 예외, policy.yaml 권한까지 한 번에 점검해보시면 좋겠어요.

    다음 글에서는 OpenStack 보안 강화 관점에서 RBAC(Role-Based Access Control, 역할 기반 접근 제어)와 프로젝트별 네트워크 분리 전략도 이어서 다뤄볼 계획이에요. 이전 글에서 다뤘던 bastion 구조와 함께 보시면 더 이해가 잘 될 겁니다.

  • [OpenStack] OpenStack Octavia 성능 벤치마크: 실제 환경 부하 테스트 분석

    [OpenStack] OpenStack Octavia 성능 벤치마크: 실제 환경 부하 테스트 분석

    목차

    OpenStack Octavia 성능 벤치마크: 실제 환경 부하 테스트 분석

    OpenStack Octavia 성능이 궁금할 때 제일 답답한 부분이 뭔지 아시나요? 문서는 분명 있는데, 막상 실제 환경에서 로드 밸런서 벤치마크를 해보면 숫자보다 병목 지점이 더 크게 보인다는 점입니다. 저도 홈랩과 사내 검증 환경에서 여러 번 테스트했었는데, 처음엔 단순히 가상머신 사양만 올리면 해결될 줄 알았습니다. 근데 실제로 써보니까 그게 다가 아니더라고요. 네트워크 경로, Amphora(앰포라, Octavia가 생성하는 로드 밸런서 인스턴스), 백엔드 응답 시간, health monitor(헬스 모니터) 간격까지 다 영향을 줍니다. 이번 글에서는 OpenStack Octavia 성능을 볼 때 어떤 항목을 기준으로 벤치마크를 잡아야 하는지, 그리고 제가 현장에서 자주 보는 병목 포인트를 기준으로 OpenStack 부하 테스트 방법을 정리해보겠습니다.

    1. 왜 OpenStack Octavia 성능 벤치마크가 중요한가

    로드 밸런서가 느리면 애플리케이션이 느린 것처럼 보입니다. 그래서 팀 내부에서 원인 분석을 시작하면 웹 서버를 의심하고, DB를 의심하고, 나중에 가서야 LB를 보는 경우가 많거든요. 사실 여기서 중요한 포인트는 Octavia는 단순 기능 확인만으로 끝내면 안 된다는 점입니다.

    • North-South traffic(외부에서 내부로 들어오는 트래픽) 집중 시 병목이 생길 수 있습니다.
    • Listener(리스너), Pool(풀), Member(멤버) 구성 방식에 따라 처리 경향이 달라집니다.
    • SSL termination(SSL 종료)를 LB에서 처리하면 CPU 사용량이 확 올라갑니다.
    • 백엔드가 느린 경우에도 LB 지표만 보면 정상처럼 보일 수 있습니다.

    쉽게 말해, Octavia 벤치마크는 단순히 "초당 몇 요청"만 보는 테스트가 아니라 어디서 밀리는지 찾는 과정이라고 보시면 됩니다.

    OpenStack Octavia 성능 테스트 전체 아키텍처 다이어그램

    OpenStack Octavia 성능 테스트에서 클라이언트, 로드 밸런서, 백엔드 서버, 모니터링 경로가 어떻게 연결되는지 보여주는 개요 이미지입니다.

    2. Octavia 구조를 먼저 이해해야 벤치마크가 보입니다

    저도 처음엔 헷갈렸는데, Octavia는 그냥 API만 있는 게 아니라 뒤에서 실제 트래픽을 받아주는 구성이 따로 있습니다. 많이 쓰는 방식은 Amphora provider(앰포라 프로바이더) 기반입니다. 이 방식은 로드 밸런서 생성 시 전용 인스턴스를 띄워서 트래픽을 처리하죠.

    2-1. 핵심 구성요소

    구성요소 역할 성능 관점 체크 포인트
    Listener 클라이언트 요청 수신 프로토콜, 포트, TLS 종료 여부
    Pool 백엔드 서버 그룹 알고리즘, 세션 분산 방식
    Member 실제 백엔드 인스턴스 응답 시간 편차, NIC 성능
    Health Monitor 상태 점검 체크 간격, timeout, 과민 탐지 여부
    Amphora 트래픽 처리 인스턴스 vCPU, 메모리, 네트워크 경로

    여기서 자주 하는 오해가 하나 있습니다. 백엔드 서버가 빠르면 LB도 빠를 거다라고 생각하는 건데요, 실제로는 LB가 먼저 CPU saturation(포화) 상태에 들어갈 수 있습니다. 특히 TLS를 넣는 순간 체감 차이가 꽤 큽니다.

    2-2. 벤치마크에서 꼭 나눠 봐야 하는 항목

    1. L4 성격의 단순 전달 테스트
    2. HTTP/HTTPS 요청 처리 테스트
    3. Keep-Alive(연결 재사용) 유무 비교
    4. 동시 접속 수 증가에 따른 지연 시간 변화
    5. 백엔드 응답 지연이 LB에 주는 영향

    이렇게 쪼개서 봐야 "Octavia가 느린지", 아니면 "뒤 서버가 느린지"가 구분됩니다.

    3. 테스트 전제 조건: 같은 조건으로 반복 가능하게 만들기

    로드 밸런서 벤치마크는 재현성이 생명입니다. 제가 직접 해보니 테스트할 때마다 부하 발생 위치가 조금씩 달라져서, 조건을 정리하지 않으면 결과 해석이 거의 불가능하더라고요.

    • 백엔드 서버 수는 고정합니다.
    • 응답하는 콘텐츠 크기를 일정하게 맞춥니다.
    • 클라이언트와 LB 사이 네트워크 구간을 동일하게 둡니다.
    • 테스트 도구와 동시성 수준을 기록합니다.
    • 모니터링 수집 주기를 맞춥니다.

    아래처럼 아주 단순한 HTTP 응답 서버를 두고 시작하면 비교가 편합니다.

    python3 -m http.server 8080

    물론 실서비스와 완전히 같지는 않지만, 1차로 LB 자체 오버헤드만 보기에 좋습니다. 그다음에 Nginx(엔진엑스, 웹 서버)나 실제 애플리케이션으로 넘어가면 되죠.

    4. OpenStack Octavia 성능 측정을 위한 실전 구성

    이제 실제로 구성해보겠습니다. 환경마다 네트워크 이름이나 서브넷 이름은 다르겠지만, 흐름은 거의 비슷합니다.

    4-1. 로드 밸런서 생성

    openstack loadbalancer create --name lb-octavia-bench --vip-subnet-id private-subnet
openstack loadbalancer listener create --name listener-http --protocol HTTP --protocol-port 80 lb-octavia-bench
openstack loadbalancer pool create --name pool-http --lb-algorithm ROUND_ROBIN --listener listener-http --protocol HTTP
openstack loadbalancer member create --subnet-id private-subnet --address 10.0.0.21 --protocol-port 8080 pool-http
openstack loadbalancer member create --subnet-id private-subnet --address 10.0.0.22 --protocol-port 8080 pool-http
openstack loadbalancer healthmonitor create --delay 5 --timeout 3 --max-retries 3 --type HTTP pool-http

    여기서 ROUND_ROBIN(라운드 로빈)은 가장 무난한 시작점입니다. 처음엔 이게 뭔가 싶었는데, 비교 기준점으로 쓰기엔 제일 편하더라고요.

    4-2. Floating IP 연결 후 확인

    openstack loadbalancer show lb-octavia-bench
curl -I http://<VIP_OR_FLOATING_IP>

    이 단계에서 응답 헤더가 안정적으로 오는지 먼저 확인합니다. 벤치마크 전에 기본 동작부터 체크해야 삽질을 줄일 수 있습니다.

    OpenStack Octavia 성능 벤치마크용 Listener Pool Member 구성 이미지

    Listener, Pool, Member, Health Monitor 구성이 어떻게 연결되는지 보여주는 중간 구성 이미지입니다.

    4-3. 부하 테스트 도구 실행

    도구는 여러 개가 있지만, 저는 보통 wrk나 ab(ApacheBench, 아파치벤치)처럼 간단한 것부터 봅니다. 처음부터 너무 복잡하게 들어가면 결과 해석이 어려워지거든요.

    wrk -t4 -c100 -d60s http://<VIP_OR_FLOATING_IP>/
ab -n 10000 -c 100 http://<VIP_OR_FLOATING_IP>/

    중요한 건 숫자 자체보다 아래 항목입니다.

    • Latency(지연 시간) 분포가 급격히 튀는지
    • Requests/sec(초당 요청) 변화가 안정적인지
    • Socket errors(소켓 에러)나 timeout이 생기는지
    • 백엔드 서버 간 분산이 고르게 되는지

    5. 측정 중 같이 봐야 하는 모니터링 포인트

    OpenStack Octavia 성능을 제대로 보려면 LB만 보면 안 됩니다. 이건 정말 많이들 놓치시는데요, 최소한 아래 지표는 같이 봐야 합니다.

    1. Amphora 인스턴스 CPU 사용률
    2. Amphora 네트워크 송수신량
    3. 백엔드 인스턴스 CPU와 응답 시간
    4. Neutron(뉴트론, OpenStack 네트워크) 경로 이상 여부
    5. 에러 로그와 health monitor 상태 변화

    제가 실무에서 자주 보는 패턴은 이렇습니다. 클라이언트 측 처리량은 안 올라가는데, LB CPU가 먼저 꽉 찹니다. 또는 LB는 멀쩡한데 특정 백엔드 한 대만 응답이 늦어서 전체 지연이 길어집니다. 그래서 OpenStack 부하 테스트는 항상 다층으로 봐야 합니다.

    openstack loadbalancer amphora list
openstack loadbalancer amphora show <AMPHORA_ID>
openstack loadbalancer status show lb-octavia-bench

    상태 조회를 반복하면서 부하 순간에 멤버 변동이 있는지도 봐두면 좋습니다. health monitor가 너무 예민하면 정상 서버가 빠졌다가 다시 붙는 현상도 생기거든요.

    6. ⚠️ 실제로 많이 겪는 문제와 해결 포인트

    여기서는 제가 삽질 좀 했던 부분 위주로 적어보겠습니다. 문서만 보면 금방 될 것 같았는데, 실환경에서는 생각보다 변수 많습니다.

    6-1. TLS 종료를 넣자마자 처리량이 떨어지는 경우

    이건 꽤 흔합니다. HTTPS listener를 활성화하면 암복호화 비용이 생기니까요. 해결 방향은 단순합니다.

    • 우선 HTTP 기준 성능을 먼저 확인합니다.
    • TLS 적용 후 CPU 사용량 증가 패턴을 비교합니다.
    • 인증서 체인 구성과 cipher suite(암호군) 정책을 과도하게 잡지 않았는지 봅니다.

    6-2. 백엔드 분산이 고르지 않은 경우

    애플리케이션이 Keep-Alive 연결을 길게 유지하면 라운드 로빈 체감이 생각보다 덜 날 수 있습니다. 이런 경우는 짧은 테스트와 긴 테스트를 따로 보세요.

    6-3. health monitor가 정상 서버를 자꾸 제외하는 경우

    timeout과 delay가 너무 타이트하면 일시적인 지연만 있어도 멤버가 빠집니다. 특히 디스크 I/O가 순간적으로 튀는 백엔드에서 자주 보입니다.

    문제 증상 의심 포인트 우선 확인할 것
    응답 지연 급증 Amphora CPU 포화 LB 인스턴스 자원 사용률
    간헐적 5xx 백엔드 응답 불안정 멤버별 로그, health monitor
    분산 불균형 연결 재사용 영향 테스트 방식, 세션 유지 여부
    처리량 정체 네트워크 경로 병목 MTU, overlay 네트워크, 보안 정책

    ⚠️ 경고: LB 성능이 안 나온다고 바로 Octavia 설정부터 뒤집지 마세요. 실제로는 백엔드 애플리케이션 응답 패턴이 원인인 경우가 더 많았습니다.

    OpenStack Octavia 성능 부하 테스트 모니터링 대시보드 이미지

    부하 테스트 중 Amphora CPU, 네트워크 사용량, 응답 지연이 함께 보이는 모니터링 화면을 설명하는 이미지입니다.

    7. 결과는 어떻게 해석해야 하나

    이제 결과를 봐야 하는데, 여기서도 함정이 있습니다. 단일 숫자 하나로 결론 내리면 안 됩니다. 제 경험상 아래 순서로 보면 훨씬 덜 헷갈립니다.

    1. 에러 없이 테스트가 끝났는지 확인
    2. 지연 시간이 동시성 증가에 따라 선형적으로 늘어나는지 확인
    3. 특정 시점부터 급격히 꺾이는 구간이 있는지 확인
    4. 그 시점의 Amphora와 백엔드 상태를 대조

    예를 들어 이런 식으로 해석할 수 있습니다.

    • 초반부터 지연이 높다: 네트워크 경로나 백엔드 초기 응답 문제 가능성
    • 중간까지 안정적이다가 급락한다: LB 또는 백엔드 자원 포화 가능성
    • 에러 없이 처리량만 정체된다: 연결 수, 커널 튜닝, 테스트 클라이언트 한계도 의심

    제가 직접 해보니 결국 의미 있는 벤치마크는 비교 기준이 있는 테스트였습니다. HTTP 대 HTTPS, Keep-Alive on/off, 멤버 2대 대 4대, health monitor 완화 전후처럼요. 이런 비교가 있어야 Octavia 최적화 포인트가 보입니다.

    7-1. 검증 체크리스트

    • ✅ VIP 응답 정상
    • ✅ 백엔드 분산 정상
    • ✅ 부하 중 health monitor 오탐 없음
    • ✅ 테스트 반복 시 결과 경향 유사
    • ✅ LB와 백엔드 병목 구분 가능

    8. 정리: OpenStack Octavia 성능 최적화는 이렇게 접근하시면 됩니다

    OpenStack Octavia 성능을 높이려면 무조건 사양부터 올리는 접근보다, 어떤 레이어가 병목인지 먼저 나누는 게 훨씬 중요합니다. 저도 예전엔 수치만 보고 튜닝했었는데, 나중에 보니 health monitor 설정 하나가 더 큰 영향을 준 적도 있었습니다. 그래서 지금은 항상 기준선 측정 – 변경 – 재측정 순서로 갑니다.

    • 기준선 만들기: HTTP 단순 응답으로 시작
    • 변수 분리: TLS, 동시성, 멤버 수를 하나씩 변경
    • 모니터링 병행: Amphora와 백엔드 지표를 같이 확인
    • 해석 중심: 최대 처리량보다 지연과 에러 패턴을 우선 확인

    혹시 이런 경험 있으신가요? LB는 멀쩡해 보이는데 서비스는 느리고, 팀마다 서로 자기 쪽은 문제 없다고 하는 상황이요. 이럴 때 Octavia 벤치마크를 체계적으로 잡아두면 원인 분석 속도가 확실히 빨라집니다. 다음 글에서는 Octavia 최적화 관점에서 health monitor, TLS 종료, 백엔드 연결 유지 전략을 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 Neutron 네트워크 점검 방법과 같이 보시면 더 도움이 될 겁니다.

    OpenStack Octavia 성능 최적화 전후 비교 요약 이미지

    벤치마크 결과를 해석하는 핵심 포인트와 튜닝 전후 비교 항목을 한눈에 보여주는 요약 이미지입니다.

    9. 자주 묻는 질문 FAQ

    Q1. Octavia 벤치마크는 어떤 도구로 시작하는 게 좋나요?

    A. 저는 wrk나 ab처럼 단순한 도구부터 시작하는 편입니다. 복잡한 시나리오는 나중에 넣어도 늦지 않습니다.

    Q2. 처리량보다 지연 시간을 더 봐야 하나요?

    A. 네, 특히 운영 환경에서는 평균 처리량보다 tail latency(상위 지연 구간)와 에러 발생 시점이 더 중요하더라고요.

    Q3. OpenStack 부하 테스트에서 가장 먼저 의심할 곳은 어디인가요?

    A. LB 단독보다는 네트워크 경로와 백엔드 응답 패턴을 먼저 함께 보시는 걸 권합니다.

    벤치마크 준비 항목, 모니터링 포인트, 자주 묻는 질문을 정리한 마무리 요약 이미지입니다.