26S05o

QK·2일 전

네. 지금 상황이라면 “GPU node를 당장 기존 Compute Cluster에 join시키는 것”을 1차 목표로 잡지 않는 것이 좋습니다.
오히려 GPU node 단독 검증 → GPU SW stack 검증 → 외부망을 통한 Compute 연동 → Private망 개통 후 K8s 편입 → Storage/RDMA → E2E 성능 순으로 가는 것이 리스크가 가장 낮습니다.

특히 현재 구조에서 가장 먼저 짚어야 할 것이 하나 있습니다.

ConnectX-6가 외부망, Intel E810이 private망이라는 NIC 배치는 향후 GPUDirect RDMA / AIStor S3 over RDMA를 하려는 경우 재검토가 필요합니다.

NVIDIA Network Operator의 현재 문서상 GPUDirect RDMA는 NVIDIA ConnectX/BlueField 계열 NIC를 대상으로 하며, RHEL 10.2 + Kubernetes 1.32~1.36도 지원 조합에 포함됩니다. (NVIDIA Docs)
반면 AIStor의 RDMA 자체는 RDMA-capable NIC를 요구하고 ConnectX-6 이상을 권장하지만, GPU memory까지 직접 연결하는 GPUDirect RDMA 경로라면 GPU↔NVIDIA NIC가 핵심입니다. (MinIO AIStor Documentation)

따라서 저는 아래처럼 진행하는 것을 추천합니다.

1. 전체 구축/검증 로드맵

전체적으로는 다음 6단계로 잡겠습니다.

                    ┌───────────────────────────────┐
                    │       GPU Server / B300 x8    │
                    │                               │
                    │  B300 x 8                     │
                    │       │                       │
                    │  PCIe / NVLink / NVSwitch     │
                    │       │                       │
                    │  ConnectX-6 ── External NET   │
                    │  Intel E810 ── Private NET    │
                    └──────────────┬────────────────┘
                                   │
             ┌─────────────────────┼─────────────────────┐
             │                     │                     │
       [External Network]    [Private Network]      [Management]
             │                     │
       Compute Cluster        Storage Cluster
       API access             AIStor

Phase 0 — 인프라/하드웨어 수령 검증

↓

Phase 1 — GPU Node OS/NIC/PCIe 기본 검증

↓

Phase 2 — NVIDIA Driver/GPU/NCCL/Burn-in

↓

Phase 3 — vLLM 단독 구동 + Compute Cluster 연동

↓

Phase 4 — Private Network 구축 + Compute/Storage 연결

↓

Phase 5 — AIStor / RDMA / GPUDirect RDMA 검증

↓

Phase 6 — E2E 성능 / 장애 / 안정성 검증

2. Phase 0 — 인프라로부터 노드 받은 직후

이 단계에서는 아직 Kubernetes에 join하지 않습니다.

목표는:

"이 서버 자체가 정상인가?"

입니다.

2-1. Hardware inventory

먼저 다음을 확보합니다.

dmidecode
lscpu
free -h
lsblk
lspci -nn
lspci -nn | grep -Ei 'nvidia|mellanox|ethernet|vga|3d'

GPU:

nvidia-smi

단, NVIDIA driver가 아직 없다면:

lspci -nn | grep -i nvidia

로 PCIe enumeration부터 확인합니다.

NIC:

lspci -nn | grep -Ei 'ethernet|mellanox|intel'
ip -br link
ip -br addr

특히 다음을 기록해 두는 것이 좋습니다.

항목확인
GPU 개수8
GPU PCIe BDF각각 기록
GPU SKUB300
NVLink/NVSwitchtopology 확인
ConnectX-6PCIe BDF / firmware
E810PCIe BDF / firmware
CPUmodel/socket/core
NUMAGPU ↔ CPU ↔ NIC affinity
RAMcapacity/speed
NVMedevice/firmware
BIOSversion
BMCversion
OSRHEL 10.2
Kernelexact version
containerdversion

3. Phase 1 — OS + PCIe + NIC 기본 테스트

이 단계에서 성능 테스트를 하지 말고 정상 동작 여부만 확인합니다.

3-1. NUMA topology

B300 8장에서는 상당히 중요합니다.

numactl -H
lscpu -e
lspci -tv

그리고 가능하면:

nvidia-smi topo -m

결과를 저장합니다.

예를 들어 이상적인 형태는:

        GPU0 GPU1 GPU2 GPU3 GPU4 GPU5 GPU6 GPU7
GPU0     X   NV   NV   NV   SYS  ...
...
NIC0    PIX  PIX  ...
NIC1    SYS  SYS

여기서 중요한 것은:

GPU ↔ NIC의 PCIe locality

입니다.

4. NIC 검증

ConnectX-6

ethtool -i <cx6-interface>
ethtool <cx6-interface>

Mellanox/NVIDIA 계열이면:

mlxconfig -d <device> q
mlxlink -d <device>

등을 확인합니다.

Intel E810

ethtool -i <e810-interface>
ethtool <e810-interface>

그리고:

ip -d link show <interface>

5. NIC firmware도 반드시 baseline을 잡아야 합니다

GPU/RDMA POC에서 의외로 많이 걸리는 부분입니다.

다음 정보를 표로 남겨두세요.

BIOS
BMC
GPU firmware
ConnectX-6 firmware
Intel E810 firmware
RHEL kernel
NVIDIA driver
CUDA
NCCL
GPU Operator
Network Operator
containerd
Kubernetes
Cilium

이 버전을 POC 기준선(baseline)으로 freeze하는 것을 권합니다.

6. Phase 2 — NVIDIA Driver / GPU 검증

여기부터 GPU software stack을 설치합니다.

현재 NVIDIA Network Operator 26.7 계열은 RHEL 10.2 + Kubernetes 1.32~1.36을 지원하고, ConnectX-6의 Ethernet/RoCE도 지원 대상으로 명시하고 있습니다. (NVIDIA Docs)

따라서 향후 현재 사용 중인 K8s 1.33 계열과도 방향은 맞습니다.

6-1. GPU Driver

먼저 standalone node에서 driver를 설치합니다.

확인:

nvidia-smi
nvidia-smi -L

8장이 모두 나와야 합니다.

예:

GPU 0: NVIDIA B300
GPU 1: NVIDIA B300
...
GPU 7: NVIDIA B300

7. GPU 기본 테스트

PCIe

nvidia-smi -q

특히:

  • PCIe Gen
  • PCIe width
  • BAR1
  • ECC
  • temperature
  • power
  • clocks
  • memory

확인.

GPU memory

CUDA sample 또는 간단한 CUDA test로:

GPU memory allocation
GPU → memory copy
memory bandwidth

확인합니다.

8. GPU Burn-in

여기서는 단순히 nvidia-smi가 된다고 PASS하지 않는 게 좋습니다.

최소:

Test A — 1 GPU

GPU0 100%

Test B — 8 GPU 동시

GPU0~GPU7 100%

Test C — 장시간

최소:

1h

가능하면:

4h

그리고 production acceptance라면:

8~24h

까지.

관찰할 항목:

GPU temperature
GPU power
GPU utilization
GPU memory utilization
ECC error
XID error
PCIe error
GPU reset
kernel error

특히:

dmesg -T | grep -Ei 'NVRM|Xid|AER|PCIe'

를 계속 확인합니다.

9. NVLink / NVSwitch 검증

B300 8-GPU라면 상당히 중요합니다.

nvidia-smi topo -m

그리고 NCCL 테스트를 합니다.

10. NCCL Test

이건 GPU 서버 acceptance test에서 필수로 넣는 것을 추천합니다.

대표적으로:

all_reduce
all_gather
broadcast
reduce_scatter

특히:

8 GPU AllReduce

를 봅니다.

테스트 축:

GPUMessage
21MB ~ 1GB
41MB ~ 1GB
81MB ~ 1GB

그리고:

latency
bandwidth
algorithm bandwidth
bus bandwidth

를 기록합니다.

11. Phase 3 — vLLM standalone

이 단계에서도 Kubernetes에 join하지 않아도 됩니다.

GPU node에서 먼저:

vLLM
  ↓
B300 x8
  ↓
model

을 검증합니다.

vLLM 자체가 정상 동작하는지부터 확인합니다.

최근 NVIDIA의 vLLM 26.07 문서에서도 Blackwell B200/B300 대상 NVFP4 MoE 최적화 등이 별도로 언급되고 있으므로, 사용하려는 실제 모델/quantization 조합을 별도로 검증하는 것이 좋습니다. (NVIDIA Docs)

12. vLLM 테스트

처음에는 작은 모델부터:

7B
14B
32B
70B

순으로 테스트하고,

최종 목표 모델을 올립니다.

측정:

기본

model load time
GPU memory
GPU utilization

Inference

TTFT
TPOT
ITL
request latency
tokens/sec
output tokens/sec

concurrency

1
2
4
8
16
32
64
128

식으로 올립니다.

13. 이 시점에서 Compute Cluster와 연동

여기서 중요한 포인트입니다.

Private network가 아직 없다면 GPU node를 Compute Cluster에 억지로 join시키지 않아도 됩니다.

대신:

Compute Cluster
       │
       │ External Network
       ▼
ConnectX-6
       │
       ▼
GPU Node
       │
       ▼
vLLM

형태로 API-level integration을 먼저 할 수 있습니다.

예:

Compute Cluster application
        ↓
http://<GPU-node-IP>:8000
        ↓
vLLM OpenAI API
        ↓
B300 x8

이렇게 하면 "GPU compute가 기존 cluster에서 호출 가능한가?"를 먼저 검증할 수 있습니다.

14. 이때 반드시 테스트할 것

Functional

Compute → vLLM
  • connection
  • authentication
  • model discovery
  • completion
  • chat completion
  • streaming
  • timeout
  • retry

Performance

Compute cluster에서:

1 request
10
100
1000

식으로 부하를 줍니다.

그리고:

TTFT
TPOT
tokens/sec
concurrency
HTTP latency
network bandwidth
CPU
GPU utilization
GPU memory

를 동시에 봅니다.

15. Phase 4 — Private Network 구성

이제 인프라에서 private network가 준비되면 여기부터 진짜 cluster integration을 시작합니다.

현재 구조를 제가 이해한 그림은:

                Compute Cluster
                     │
                  bond1
                     │
               Private Network
                     │
                ┌────┴────┐
                │         │
           Storage      GPU Node
           Cluster
             bond1       E810

이 형태입니다.

여기서 GPU node는:

E810 → Private network
CX6  → External network

가 됩니다.

16. 가장 중요한 설계 결정

여기서 반드시 결정해야 합니다.

Option A

E810
  ↓
K8s private network
  ↓
Compute + Storage

그리고:

CX6
  ↓
External network
  ↓
vLLM API

Option B

CX6
  ↓
RoCE/RDMA private fabric
  ↓
AIStor

그리고:

E810
  ↓
K8s private network

GPUDirect RDMA까지 목표라면 B에 가까운 구성이 더 적절합니다.

왜냐하면 GPUDirect RDMA의 핵심은:

GPU
 ↓
PCIe P2P
 ↓
NVIDIA NIC
 ↓
RoCE
 ↓
Storage

이기 때문입니다.

NVIDIA 문서에서도 GPUDirect RDMA는 지원 GPU와 NVIDIA ConnectX/BlueField NIC 조합을 요구합니다. (NVIDIA Docs)

따라서 현재처럼

GPU
 │
 ├── ConnectX-6 → External
 │
 └── E810      → Private

이라면,

E810 private망으로 AIStor까지 일반 TCP 통신은 가능하지만, GPU Direct RDMA를 하려는 경우에는 구조적인 제약이 생길 가능성이 높습니다.

이건 POC 초기에 반드시 결정해야 합니다.

17. Private Network 기본 테스트

E810 연결 후에는 먼저 K8s를 올리지 말고 network 자체를 검증합니다.

GPU node:

ip addr
ip route
ip neigh

Compute node:

ping <GPU-private-IP>

Storage node:

ping <GPU-private-IP>

다음:

GPU ↔ Compute
GPU ↔ Storage

각각:

ping
MTU
TCP
bandwidth
packet loss

검증.

18. MTU는 반드시 확인

RoCE를 할 계획이면 특히 중요합니다.

예:

ip link show

그리고:

ping -M do -s <size> <peer>

로 MTU를 검증합니다.

가능하면:

MTU 1500
MTU 9000

중 실제 설계값을 확정합니다.

한쪽만 jumbo frame인 상태가 가장 위험합니다.

19. iperf3

최소:

GPU Node ↔ Compute
GPU Node ↔ Storage

를 테스트합니다.

예:

iperf3 -s

반대쪽:

iperf3 -c <server> -P 1
iperf3 -c <server> -P 4
iperf3 -c <server> -P 8

그리고:

1 stream
4 streams
8 streams
16 streams

을 비교합니다.

여기서 중요한 것은 단순 bandwidth뿐 아니라:

packet loss
retransmission
CPU utilization
NIC utilization

입니다.

20. RDMA는 별도로 검증

Private network가 RoCE로 구성된다면:

ibv_devices
ibv_devinfo
rdma link
rdma dev

확인.

그리고:

perftest
 ├── ib_write_bw
 ├── ib_read_bw
 ├── ib_send_bw
 ├── ib_write_lat
 └── ib_read_lat

등으로 검증합니다.

21. RoCE fabric 검증

이 부분은 일반 Ethernet 테스트와 별개입니다.

확인:

RoCEv2
PFC
ECN
DSCP/PCP
DCB
QoS
MTU
switch buffer

특히 PFC를 사용한다면:

RDMA traffic
       ↓
lossless queue
       ↓
PFC

가 제대로 구성됐는지 확인해야 합니다.

여기서 기존 Cilium/K8s traffic에 영향을 주지 않는지도 반드시 검증해야 합니다.

22. Phase 5 — Storage Cluster / AIStor 연동

여기서는 두 단계로 나누는 것을 추천합니다.

Stage 1 — TCP

먼저:

GPU Node
   │
 E810
   │
Private Network
   │
AIStor

에서 일반 S3/TCP 성능을 측정합니다.

Stage 2 — RDMA

그 다음:

GPU
 ↓
GPUDirect RDMA
 ↓
NIC
 ↓
RoCE
 ↓
AIStor

를 검증합니다.

AIStor의 현재 RDMA 문서에서는 RoCE v2를 사용하려면 end-to-end lossless fabric과 PFC 등이 필요하다고 명시하고 있습니다. (MinIO AIStor Documentation)

23. 여기서 AIStor 테스트를 3개로 분리하세요

Test A — S3/TCP

GPU Node
   ↓ TCP
AIStor

Test B — S3/RDMA

GPU Node
   ↓ RDMA
AIStor

Test C — GPU Direct

GPU memory
   ↓
NIC
   ↓
RoCE
   ↓
AIStor

이렇게 분리해야 합니다.

그렇지 않으면 문제가 생겼을 때:

GPU 문제인지 / NIC 문제인지 / RDMA 문제인지 / AIStor 문제인지

구분이 안 됩니다.

24. AIStor Storage 성능 테스트

최소:

GET
PUT
multipart upload
large object
small object
concurrent objects

를 테스트합니다.

예를 들어:

ObjectConcurrency
1 MB1/16/64/256
64 MB1/16/64
1 GB1/4/16/64
10 GB1/4/16

측정:

MB/s
GB/s
IOPS
latency
CPU
NIC
GPU utilization
AIStor disk latency
AIStor network

25. GPUDirect Storage/AIStor를 한다면 추가 검증

여기서는 단순히:

ibv_devinfo = OK

만으로 PASS하면 안 됩니다.

확인해야 할 것이:

GPU ↔ NIC PCIe P2P
IOMMU
ACS
BAR1
nvidia_peermem
RDMA device
GPU/NIC affinity

입니다.

AIStor 문서도 GPU S3 over RDMA의 경우 GPU-to-NIC peer-to-peer DMA와 NVIDIA GPU/RDMA 지원을 요구합니다. (MinIO AIStor Documentation)

26. Phase 6 — 최종 E2E Test

최종적으로는 실제 workload와 최대한 비슷하게 만듭니다.

User / Application
       │
       ▼
Compute Cluster
       │
       │ API
       ▼
vLLM
       │
       ▼
B300 x8
       │
       │ RDMA / TCP
       ▼
AIStor
       │
       ▼
Storage

27. E2E 테스트 시나리오

Test 1 — inference only

Compute → vLLM → GPU

측정:

TTFT
TPOT
tokens/sec
QPS
GPU utilization

Test 2 — inference + model loading

AIStor
 ↓
GPU
 ↓
vLLM

측정:

model load time
storage throughput
GPU utilization
network

Test 3 — concurrent inference

Compute
 ↓
vLLM
 ↓
8 GPU

concurrency:

1
2
4
8
16
32
64
128
256

까지 올려봅니다.

28. Test 4 — Storage + inference 동시 부하

이게 실제 운영에서는 상당히 중요합니다.

             ┌── inference
Compute ─────┤
             └── model/data access
                    ↓
                  AIStor

동시에:

AIStor PUT/GET
+
vLLM inference

를 발생시킵니다.

이때:

GPU utilization
NIC utilization
AIStor latency
vLLM TTFT
vLLM TPOT

가 서로 영향을 주는지 봅니다.

29. Test 5 — Network saturation

예:

25G
50G
100G
200G

환경에 맞게 최대 bandwidth까지 올려봅니다.

특히 NIC bandwidth가 증가하면서 vLLM latency가 얼마나 영향을 받는지가 중요합니다.

30. Test 6 — 장애 테스트

POC에서 반드시 넣는 것을 추천합니다.

GPU

GPU reset
GPU process crash
GPU XID

Network

CX6 link down
E810 link down
network packet loss
RoCE congestion

AIStor

AIStor node unavailable
network path unavailable

vLLM

pod restart
container restart
model reload

Compute

client restart
connection timeout
retry

31. 특히 중요한 장애 시나리오

실제 운영에서는 다음이 중요합니다.

Compute
   │
   ▼
vLLM
   │
   ▼
GPU

중간에 vLLM이 죽으면:

HTTP timeout
retry
connection reset

이 발생합니다.

따라서 Compute 측에서:

timeout
retry
backoff
circuit breaker

를 검증해야 합니다.

32. 제가 보는 가장 중요한 Risk 8개

Risk 1 — NIC 역할이 잘못 잡힐 가능성 ★★★★★

현재:

CX6 → External
E810 → Private

인데 GPUDirect RDMA가 목표라면 재검토가 필요합니다.

가장 먼저 결정해야 합니다.

Risk 2 — GPU Node를 너무 빨리 기존 K8s에 join

추천하지 않습니다.

왜냐하면:

GPU driver
CUDA
NCCL
CNI
RDMA
Network Operator
GPU Operator
Cilium

문제가 한꺼번에 섞입니다.

따라서:

Standalone → Network → GPU → vLLM → Storage → K8s

순서가 좋습니다.

Risk 3 — OS/Driver 버전

특히 GPU Operator / Network Operator / CUDA / driver 조합입니다.

현재 Network Operator 26.7 기준으로 RHEL 10.2와 K8s 1.32~1.36이 지원되므로 현재 환경과의 방향은 맞지만, 실제 B300 + 해당 driver/CUDA 조합은 POC에서 고정해서 검증해야 합니다. (NVIDIA Docs)

Risk 4 — RoCE는 "NIC만 연결하면 되는 것"이 아님

NIC
+
switch
+
PFC
+
ECN
+
DSCP
+
MTU
+
routing

전체가 맞아야 합니다.

AIStor도 RoCE 환경에서 end-to-end lossless fabric을 요구합니다. (MinIO AIStor Documentation)

Risk 5 — Cilium과 RDMA traffic 충돌

현재 Cilium이:

Native routing
BGP
ECMP
Gateway API

를 사용하고 있으므로 K8s 일반 traffic과 RDMA fabric을 논리적으로 분리하는 것을 권합니다.

즉:

K8s traffic
   ↓
Cilium / E810

RDMA traffic
   ↓
RoCE / dedicated NIC

구조가 가장 깔끔합니다.

33. Risk 6 — MTU mismatch

예:

GPU 9000
  ↓
Switch 9000
  ↓
Storage 1500

이면 일반 TCP에서는 일부 동작하더라도 RDMA에서 문제가 훨씬 심각해질 수 있습니다.

34. Risk 7 — GPU/NIC PCIe topology

8-GPU B300에서는 단순히:

GPU 8개
NIC 1개

가 중요한 게 아닙니다.

어떤 GPU가 어떤 NIC/PCIe root complex와 연결되는지가 중요합니다.

반드시:

nvidia-smi topo -m

와 NUMA topology를 기준으로 benchmark 해야 합니다.

35. Risk 8 — 성능 테스트가 "최고값" 위주가 되는 것

예를 들어:

Peak bandwidth = 180Gbps

가 나왔다고 성공한 것이 아닙니다.

실제 운영에서는:

P99 latency
P99.9 latency
GPU utilization
network utilization
storage latency
error rate

가 훨씬 중요합니다.

36. 최종적으로 PASS/FAIL 기준을 이렇게 잡는 것을 추천

영역PASS 기준
Hardware모든 GPU/NIC/PCIe 정상
GPU Driver8 GPU 정상 인식
GPU Burn장시간 XID/ECC 오류 없음
NVLinktopology 정상
NCCL8GPU expected BW 달성
vLLMmodel load/inference 정상
Compute→vLLMAPI 안정적
Private Networkpacket loss 0
Network목표 BW 달성
RDMAibv/perftest 정상
RoCEPFC/ECN 정상
AIStor TCP목표 throughput
AIStor RDMA목표 throughput
GPUDirectGPU memory direct path 확인
E2E목표 TPS/latency
Failure장애 후 recovery 정상

37. 제가 추천하는 실제 작업 순서

실제로 현장에서 작업한다면 저는 아래 순서로 진행하겠습니다.

[DAY 1]
GPU Server HW inspection
        ↓
BIOS/BMC/FW
        ↓
RHEL 10.2
        ↓
NIC basic test
        ↓
GPU PCIe enumeration

[DAY 2]
NVIDIA Driver
        ↓
nvidia-smi
        ↓
8 GPU validation
        ↓
GPU burn-in

[DAY 3]
CUDA
        ↓
NCCL
        ↓
NVLink/NVSwitch
        ↓
8GPU NCCL benchmark

[DAY 4]
vLLM
        ↓
single request
        ↓
concurrency
        ↓
long-run test

[DAY 5]
Compute Cluster
        ↓
External network
        ↓
vLLM API
        ↓
E2E API test

[PRIVATE NETWORK READY]

[DAY 6]
E810 private network
        ↓
GPU ↔ Compute
        ↓
GPU ↔ Storage
        ↓
MTU
        ↓
iperf3

[DAY 7]
RDMA
        ↓
RDMA device
        ↓
perftest
        ↓
RoCE PFC/ECN

[DAY 8]
AIStor TCP
        ↓
AIStor RDMA
        ↓
GPU Direct RDMA

[DAY 9~10]
vLLM + AIStor
        ↓
E2E performance
        ↓
stress
        ↓
failure/recovery

38. 그리고 가장 중요한 "구축 전략"

저라면 이번 POC에서는 Kubernetes Join을 마지막 쪽으로 미룹니다.

즉,

① 먼저 Bare-metal GPU validation

RHEL
 ├─ NVIDIA Driver
 ├─ CUDA
 ├─ NCCL
 ├─ GPU Burn
 ├─ CX6
 └─ E810

② 그 다음 vLLM

vLLM
 ↓
B300 x8

③ 그 다음 Compute integration

Existing Compute
       ↓
     HTTP
       ↓
    vLLM

④ Private Network 개통

GPU
 │
E810
 │
Private
 ├── Compute
 └── Storage

⑤ RDMA

GPU
 │
CX6
 │
RoCE
 │
AIStor

⑥ 마지막에 Kubernetes

Existing Compute K8s
        │
        │ private
        ▼
     GPU Node
        │
        ├── GPU Operator
        ├── Network Operator
        ├── Cilium
        └── vLLM

이렇게 가는 것이 좋습니다.

특히 지금 CX6가 외부망이고 E810이 private망이라는 사실 때문에, GPU → Storage → GPUDirect RDMA를 최종 목표로 한다면 네트워크 설계를 먼저 확정한 후 장비를 물리는 것을 강하게 권합니다. CX6를 단순히 외부 API용 NIC로 사용하고 E810을 AIStor용 private NIC로 쓰는 구성이라면, TCP 기반 GPU↔AIStor 연동은 가능하지만 NVIDIA GPUDirect RDMA라는 최종 목표와는 맞지 않을 수 있습니다.

참고로 AIStor의 최근 RDMA build는 RDMA fabric이 없으면 TCP로 동작하므로, 초기 TCP 검증과 이후 RDMA 검증을 분리해서 진행하는 전략도 가능합니다. (MinIO)

원하시면 다음 단계로 제가 이걸 실제 POC 수행용 "GPU Node 구축/검증 체크리스트" 형태로 만들어서, 각 단계별로 설치 명령어 → 확인 명령어 → Prometheus/Grafana metric → PASS/FAIL 기준 → 예상 장애 → rollback 방법까지 넣은 Excel 형태의 테스트 시나리오로 구성해드릴 수 있습니다.

profile
QK
engineer
이전 포스트

26S05h

다음 포스트

26S05p

0개의 댓글