[OpenStack] OpenStack Placement 벤치마크: 대규모 자원 할당 성능 분석

OpenStack Placement 벤치마크를 처음 제대로 돌려본 건, 스케줄러가 이상하게 느려지는 순간 때문이었습니다. VM 몇 대 수준에서는 티가 안 나는데, 컴퓨트 노드 수가 늘고 자원 요청(Resource Request)이 복잡해지면 갑자기 API 응답이 늘어지고, 결국 사용자는 “왜 인스턴스 생성이 이렇게 오래 걸리죠?”라고 묻게 되거든요. 저도 처음엔 Nova Scheduler(노바 스케줄러) 쪽만 의심했었는데, 실제로 뜯어보니 Placement 서비스가 병목으로 보이는 구간이 있더라고요. 그래서 이번 글에서는 OpenStack Placement 벤치마크를 어떤 식으로 설계하고, 무엇을 봐야 하며, 결과를 어떻게 해석해야 하는지 제 경험 기준으로 정리해보겠습니다.

특히 자원 할당 성능, OpenStack 인프라, Placement 서비스를 운영 관점에서 보고 싶은 분들께 도움이 될 겁니다. 숫자를 지어내는 식의 벤치마크는 의미가 없어서, 이번 글은 재현 가능한 테스트 절차와 해석 포인트 위주로 풀어보겠습니다. 혹시 운영 환경에서 “CPU는 남는데 스케줄링이 느리다” 같은 경험 있으신가요? 여기서 중요한 포인트가 바로 Placement입니다.

Placement 서비스, Nova Scheduler, 데이터베이스, 컴퓨트 노드가 연결된 전체 벤치마크 아키텍처 개요입니다.

1. 왜 OpenStack Placement 벤치마크가 중요한가

쉽게 말해 Placement는 “이 요청을 만족할 수 있는 자원이 어디에 있나”를 빠르게 찾는 역할을 합니다. 예전에는 자원 조회 로직이 여러 군데 흩어져 있어서 복잡했는데, Placement가 그 책임을 상당 부분 분리해줬죠. 문제는 조회 대상이 커지면, 즉 Resource Provider(리소스 프로바이더, 자원 제공 주체) 수가 많아지고 Traits(트레이트, 자원 특성)나 Aggregate(애그리게이트, 그룹화 정보) 조건이 겹치면 성능 특성이 확 달라진다는 게 핵심이더라고요.

제가 직접 해보니 단순 조회는 꽤 잘 버티는데, 아래 조건이 섞이면 체감 성능이 달라졌습니다.

• 컴퓨트 노드가 많아져 Resource Provider 수가 크게 증가한 경우
• NUMA, PCI passthrough, SR-IOV 같은 추가 조건이 붙는 경우
• 동시 API 요청이 몰리는 경우
• Inventory(인벤토리, 제공 가능한 자원량)와 Allocation(할당 상태) 갱신이 계속되는 경우

운영에서는 이게 곧 사용자 경험으로 이어집니다. 인스턴스 생성 지연, 오토스케일 지연, 배치 작업 실패로 연결될 수 있거든요. 그래서 OpenStack Placement 벤치마크는 단순한 성능 놀이가 아니라, 실제 운영 여유치(headroom)를 확인하는 절차라고 보는 게 맞습니다.

2. Placement 서비스 핵심 개념 정리

저도 처음엔 용어 때문에 좀 헷갈렸는데, 이 부분만 정리되면 뒤가 훨씬 쉬워집니다.

2-1. Resource Provider와 Inventory

Resource Provider는 CPU, RAM, DISK 같은 자원을 제공하는 대상입니다. 보통 컴퓨트 노드가 대표적이지만, 구조상 더 세분화된 단위도 가능합니다. Inventory는 “이 노드가 얼마나 제공 가능한가”에 대한 정보고, Allocation은 “그 중 얼마가 이미 사용 중인가”에 가깝습니다.

2-2. Trait와 Aggregate

Trait는 특성 태그라고 생각하면 편합니다. 예를 들어 SSD, 특정 CPU 기능, 가상화 확장 여부 같은 성격을 표현할 때 씁니다. Aggregate는 여러 Resource Provider를 묶는 논리 그룹입니다. Availability Zone과 비슷하게 느껴질 수 있는데 쓰임은 조금 다르죠.

2-3. Allocation Candidate

벤치마크에서 자주 보게 되는 개념입니다. Allocation Candidate(할당 후보)는 요청 조건을 만족하는 자원 조합 후보인데, 결국 스케줄링 전에 “가능한 곳 리스트”를 만든다고 보면 됩니다. 이 후보 계산이 커질수록 Placement 서비스의 응답 시간도 영향을 받습니다.

3. 벤치마크 설계: 뭘 측정해야 의미가 있나

여기서 제일 많이 하는 실수가, 단순히 초당 요청 수만 보는 겁니다. 물론 Requests Per Second(RPS, 초당 요청 수)도 중요하지만, 운영 관점에서는 그것만 보면 안 되더라고요. 저는 보통 아래 항목을 함께 봅니다.

1. 응답 시간 분포: 평균보다 P95, P99 같은 꼬리 지연(tail latency)이 더 중요합니다.
2. 동시 요청 처리량: 단일 요청보다 burst 상황을 봐야 합니다.
3. 오류율: 5xx 응답, 타임아웃, 충돌 응답 여부를 확인합니다.
4. DB 부하: Placement 자체보다 백엔드 DB가 먼저 한계에 닿는 경우가 많습니다.
5. 스케줄링 체감: Placement API만 빠르고 실제 인스턴스 생성은 느릴 수도 있습니다.

벤치마크 시나리오도 분리하는 게 좋습니다. 제가 추천하는 기준은 이렇습니다.

• 단순 조회 시나리오: traits 없이 기본 자원만 요청
• 조건부 조회 시나리오: trait, aggregate, resource class 조건 추가
• 대규모 후보 시나리오: 후보군이 매우 많도록 구성
• 갱신 혼합 시나리오: allocation/inventory 업데이트와 조회를 동시에 수행

사실 운영 장애는 마지막 시나리오에서 많이 튀어나옵니다. 읽기만 있는 테스트는 예쁘게 나오는데, 쓰기와 섞는 순간 이야기가 달라지거든요.

리소스 프로바이더 토폴로지와 요청 흐름, 후보 계산 경로를 보여주는 구성 다이어그램입니다.

4. 홈랩 기준 실전 벤치마크 환경 구성

제 홈랩에서도 완전히 똑같은 운영 환경을 만들 수는 없었지만, 패턴을 확인하는 데는 충분했습니다. 중요한 건 절대적인 숫자보다 병목이 어디서 시작되는지를 보는 겁니다.

4-1. 테스트 전 체크리스트

• Placement API 엔드포인트 접근 가능 여부 확인
• 테스트용 프로젝트와 인증 토큰 준비
• 백엔드 DB 상태 확인
• 벤치마크 중 로그 레벨을 너무 과하게 올리지 않기
• 테스트 시간대 분리: 운영 트래픽과 겹치지 않게

4-2. 기본 확인 명령

source admin-openrc.sh
openstack endpoint list --service placement
openstack resource provider list
openstack --os-placement-api-version 1.0 resource provider list

CLI가 환경마다 조금 다를 수 있어서, 저는 먼저 엔드포인트와 인증이 정상인지부터 확인합니다. 여기서 막히면 뒤 테스트는 전부 헛수고가 되더라고요. 삽질 좀 했습니다 ㅎㅎ

4-3. API 직접 조회 예시

export TOKEN=$(openstack token issue -f value -c id)
export PLACEMENT_URL=$(openstack endpoint list --service placement -f value -c URL | head -n 1)

curl -s -H "X-Auth-Token: ${TOKEN}" \
     -H "OpenStack-API-Version: placement 1.0" \
     "${PLACEMENT_URL}/resource_providers" | jq .

이렇게 직접 보면 중간 계층 없이 Placement 서비스의 응답만 확인하기 좋습니다. 벤치마크는 가능하면 레이어를 나눠서 보세요. Nova까지 한 번에 보면 편하긴 한데, 원인 분리가 어려워집니다.

4-4. 간단한 부하 스크립트 예시

제가 자주 쓰는 방식은 Python(파이썬)으로 요청 수, 동시성, 헤더를 명시하는 간단한 스크립트를 먼저 만드는 겁니다. 전문 부하도구를 써도 되지만, 초기에 API 동작 확인은 직접 짠 스크립트가 오히려 빠를 때가 많습니다.

import os
import time
import statistics
import concurrent.futures
import requests

TOKEN = os.environ["TOKEN"]
PLACEMENT_URL = os.environ["PLACEMENT_URL"].rstrip("/")
HEADERS = {
    "X-Auth-Token": TOKEN,
    "OpenStack-API-Version": "placement 1.0",
}
URL = f"{PLACEMENT_URL}/allocation_candidates?resources=VCPU:2,MEMORY_MB:4096,DISK_GB:20"


def fetch():
    start = time.perf_counter()
    r = requests.get(URL, headers=HEADERS, timeout=10)
    elapsed = time.perf_counter() - start
    return r.status_code, elapsed


def run(total=100, workers=10):
    results = []
    with concurrent.futures.ThreadPoolExecutor(max_workers=workers) as ex:
        futures = [ex.submit(fetch) for _ in range(total)]
        for f in concurrent.futures.as_completed(futures):
            results.append(f.result())

    latencies = [elapsed for status, elapsed in results if status == 200]
    errors = [status for status, _ in results if status != 200]

    print("total=", len(results))
    print("success=", len(latencies))
    print("errors=", len(errors))
    if latencies:
        print("avg=", round(statistics.mean(latencies), 4))
        print("max=", round(max(latencies), 4))


if __name__ == "__main__":
    run(total=300, workers=30)

이 스크립트는 아주 기본형입니다. 운영에서 쓰려면 요청 경로를 더 나누고, P95/P99 계산도 붙이고, 결과를 파일로 남기면 좋습니다.

5. 단계별 OpenStack Placement 벤치마크 진행 방법

이제 실제 진행 순서입니다. 여기서는 벤치마크 결과를 왜곡하지 않도록, 시나리오를 점진적으로 키우는 방식이 좋습니다.

1. 기준선(Baseline) 측정
   아무 조건 없는 조회부터 시작합니다. Resource Provider 수가 적은 상태에서 먼저 응답 시간을 봅니다.
2. 조건 추가
   Trait와 Aggregate 조건을 하나씩 늘려봅니다. 어떤 조건이 급격한 지연을 만드는지 확인합니다.
3. 동시성 증가
   workers 값을 점진적으로 올립니다. 갑자기 10배로 올리면 원인 파악이 힘듭니다.
4. 데이터 규모 증가
   리소스 프로바이더와 할당 데이터를 늘린 상태에서 다시 측정합니다.
5. 읽기/쓰기 혼합
   조회만이 아니라 할당 갱신 요청과 함께 테스트합니다.

여기서 중요한 포인트! 한 번에 하나씩만 바꾸세요. 저도 예전에 노드 수, 동시성, 조건을 한꺼번에 바꿨다가 뭐가 원인인지 한참 못 찾았거든요.

5-1. allocation_candidates 요청 예시

curl -s -H "X-Auth-Token: ${TOKEN}" \
     -H "OpenStack-API-Version: placement 1.0" \
     "${PLACEMENT_URL}/allocation_candidates?resources=VCPU:4,MEMORY_MB:8192,DISK_GB:40" | jq .

5-2. trait 조건 포함 예시

curl -s -H "X-Auth-Token: ${TOKEN}" \
     -H "OpenStack-API-Version: placement 1.0" \
     "${PLACEMENT_URL}/allocation_candidates?resources=VCPU:4,MEMORY_MB:8192&required=CUSTOM_SSD" | jq .

5-3. 결과 저장 예시

for w in 1 5 10 20 30; do
  echo "workers=${w}" >> placement-bench.txt
  python3 placement_bench.py --workers ${w} --total 200 >> placement-bench.txt
  sleep 2
done

실제로 써보니까 중간중간 쿨다운을 조금 넣는 게 결과 해석에 편했습니다. 연속 폭격만 하면 캐시, DB 커넥션, 시스템 부하가 뒤섞여서 패턴이 흐려질 수 있거든요.

터미널에서 Placement API 벤치마크를 실행하는 장면과 요청 흐름을 시각화한 이미지입니다.

6. ⚠️ 실제로 겪은 문제와 트러블슈팅

이 섹션은 진짜 중요합니다. 벤치마크는 돌렸는데 결과를 믿을 수 없는 경우가 생각보다 많거든요.

6-1. 인증 토큰 만료

장시간 테스트에서 은근 자주 나옵니다. 처음엔 성능 저하인 줄 알았는데, 알고 보니 중간부터 401이 섞이더라고요. 그래서 저는 토큰 재발급 루틴을 넣거나, 테스트 시간을 짧게 끊어서 돌립니다.

6-2. DB가 먼저 병목이 되는 경우

Placement 서비스만 보고 있으면 놓치기 쉽습니다. API 프로세스 CPU는 여유 있는데 응답 시간이 늘어난다면, DB 슬로우 쿼리(slow query)를 꼭 보셔야 합니다. 특히 후보 계산 관련 조회가 커지는 구간에서 차이가 보일 수 있습니다.

6-3. 로그 레벨 때문에 성능이 왜곡되는 경우

디버그 로그를 켜고 벤치마크 돌리면, 그 자체가 부하가 됩니다. 저도 “왜 오늘따라 이렇게 느리지?” 했다가 로그 설정부터 다시 봤던 적이 있습니다. 디버깅과 성능 측정은 분리하는 게 맞습니다.

6-4. 캐시 효과로 첫 번째와 두 번째 결과가 다른 경우

이건 꽤 흔합니다. 첫 실행과 반복 실행 결과를 구분해서 기록해두세요. 워밍업(warm-up) 구간을 따로 두는 이유가 있습니다.

7. 검증과 결과 해석: 숫자보다 패턴을 보세요

벤치마크 결과를 볼 때 저는 보통 세 가지 질문을 던집니다.

1. 동시성이 올라갈 때 지연 시간이 선형적으로 늘어나는가?
2. 특정 조건(trait, aggregate)에서만 갑자기 악화되는가?
3. Placement API 응답 시간과 실제 인스턴스 생성 지연이 같이 움직이는가?

예를 들어 평균 응답 시간은 괜찮아 보여도, P99가 튄다면 운영 체감은 이미 나빠졌을 수 있습니다. 반대로 수치가 조금 높아도 일관되게 유지되면 운영상 더 다루기 쉽습니다. 결국 중요한 건 안정성 있는 자원 할당 성능입니다.

제가 직접 해보니 결과 해석은 아래 순서가 제일 실용적이었습니다.

• API 응답 시간 분포 확인
• 오류율 확인
• DB와 서비스 프로세스 리소스 사용량 확인
• 실제 스케줄링 체감과 비교

grep -E "avg|max|errors|workers" placement-bench.txt

가능하다면 결과는 시각화해두세요. 작은 차이도 그래프로 보면 패턴이 보입니다. 특히 worker 수 증가에 따른 지연 변화는 선 그래프로 보면 바로 감이 오더라고요.

응답 시간, 오류율, 동시성 변화가 한눈에 보이는 벤치마크 결과 대시보드 이미지입니다.

8. 정리와 다음 단계

OpenStack Placement 벤치마크는 단순히 API를 두드려보는 테스트가 아닙니다. 대규모 OpenStack 인프라에서 실제 스케줄링 여유치를 확인하고, 병목이 Placement 서비스 자체인지, DB인지, 아니면 상위 스케줄링 로직인지 구분하는 과정에 가깝습니다. 처음엔 좀 복잡해 보여도, 시나리오를 잘게 나누고 한 번에 하나씩 바꾸면 훨씬 명확해집니다.

이번 글의 핵심만 다시 묶어보면 이렇습니다.

• 평균값보다 분포를 보세요. 특히 꼬리 지연이 중요합니다.
• 조회와 갱신을 분리해서도 보고, 섞어서도 보세요.
• Placement만 보지 말고 DB와 실제 스케줄링 체감도 함께 보세요.
• 결과 숫자보다 병목이 시작되는 패턴을 찾으세요.

다음 글에서는 Nova Scheduler(노바 스케줄러)와 Placement 서비스의 상호작용을 조금 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 API 응답 시간 분석 방법이 있다면 같이 보셔도 흐름이 잘 연결될 겁니다. 혹시 지금 운영 중인 환경에서 Placement 성능이 의심된다면, 오늘 소개한 최소 구성 벤치마크부터 먼저 돌려보세요. 생각보다 빨리 단서가 나옵니다. 드디어 됐다! 하는 순간이 오더라고요 🎉

벤치마크 시나리오별 관찰 포인트와 튜닝 우선순위를 요약한 인포그래픽입니다.

FAQ: 자주 묻는 질문

Q1. Placement API만 빠르면 스케줄링도 무조건 빠른가요?

그건 아닙니다. Placement는 중요한 구성요소지만 전부는 아니거든요. Nova Scheduler, MQ, DB, 하이퍼바이저 상태까지 같이 봐야 합니다.

Q2. 작은 환경에서도 벤치마크가 의미가 있나요?

네, 있습니다. 절대 수치보다 패턴을 보는 데 의미가 큽니다. 홈랩에서도 병목 시작 지점을 찾는 연습이 충분히 됩니다.

Q3. 어느 수치가 정상인가요?

환경마다 다르기 때문에 단일 기준을 말하기는 어렵습니다. 그래서 더더욱 동일 환경에서 조건별 상대 비교가 중요합니다.

Q4. 튜닝은 어디부터 시작하면 될까요?

제 경험상 무작정 서비스 파라미터부터 건드리기보다, 요청 패턴 분리, DB 관찰, 후보 계산이 무거운 조건 파악부터 하는 게 훨씬 효율적이었습니다.