26F12a2

Young-Kyoo Kim·2026년 2월 11일

시스템 진단 및 트러블슈팅 회의록

1. 회의 배경 및 목적

1.1 진단의 필요성

운영 안정화: 성능 개선보다 안정성 확보가 최우선
사전 예방: 잠재적 이슈 조기 발견 및 해결
체계적 접근: 정기적 헬스체크와 상시 모니터링 구분

1.2 진단 도구 종류

헬스체크 스크립트: 정기 점검용 (월 1회, 분기 1회)
MC Browse: 실시간 트러블슈팅용 (장애, 업그레이드 시)
MC Admin Profile: 상세 성능 분석용 (특정 이슈 발생 시)

벤더 설명:

"health Check and everything is more generic, like once a month, 
like once a quarter thing, whereas MC Browse can be used when 
there's a failure, or they're doing upgrade, or, like those 
edge cases, like, it's an easy monitoring to pool."

2. 진단 스크립트 실행 결과

2.1 실행 개요

실행 시기: 2026년 2월 3일
대상 클러스터: Pool 0 (54개 노드)
검출 결과: 6개의 Warning/Error 사항

회의 내용:

"So they ran couple of the scripts that we suggested. 
And of course, like, they're most interested in performance for us."

2.2 발견된 이슈 목록

주요 이슈

Transparent Huge Pages (THP) 설정 불일치
IOMMU 설정 관련
Go Routine 급증 (Node 38)
LDAP 동기화 에러
기타 사소한 설정 이슈들

3. 이슈 #1: Transparent Huge Pages (THP) 설정

3.1 문제 상황

현상: 특정 노드 1대에서 THP 설정이 유지되지 않음
영향도: 성능 저하 가능성 (치명적이지는 않음)
발생 범위: 54개 노드 중 1개 노드만 해당

발견 과정:

"We will critical aside from that, yeah, transparent, huge pages 
being the OS level... So the top one there, I see that almost 
all the time. Within our own cluster, we have the red flag 
every time... the transparent, huge pages that is also a 
performance issue."

3.2 기술적 분석

THP 설정 레벨

질문: THP는 OS 레벨인가, 컨테이너 레벨인가?

벤더 답변:

"That's what I thought, because we're setting the transparent 
huge pages, is that the OS level? So either it's not set 
correctly at the OS level or the container, because that 
setting for transparent huge pages could be defined at any time"

진단 방법

컨테이너 내부 확인

"We can always go into the container and try to see what 
the computer sees... I don't know which profile they're 
reading these value out"

OS 레벨 확인
- Proc 파일 시스템 체크
- 실제 설정값 확인

설정 지속성 문제

POD 재시작으로 해결 안 됨: OS 레벨 설정 문제일 가능성
특정 노드만 발생: 다른 모든 노드는 정상

기술 논의:

"For some reason that one note, it's getting caught like 
it's not sticking... if you restarted just the container 
on that node, would it pick that up? Typically, there's no..."

3.3 해결 방안

옵션 1: 무시

근거: 다른 모든 노드 정상, 성능 영향 미미
권장 상황: 다른 모든 상태가 양호한 경우

벤더 의견:

"I would say it's probably just it can be ignored... 
if the rest of it's [normal]"

옵션 2: 노드 재부팅

근거: OS 레벨 설정 재적용
리스크: 재부팅 중 서비스 영향

옵션 3: 개별 확인 및 수동 설정

방법:
1. 컨테이너 내부 진입
2. 실제 인식 값 확인
3. 필요 시 수동 설정

3.4 추가 조사 계획

벤더 측: 내부적으로 진단 메커니즘 확인 예정

회의 내용:

"어떻게 진단이 되는지 내부적으로 확인 예정"

4. 이슈 #2: IOMMU 설정

4.1 문제 상황

현상: IOMMU 설정 권고사항 표시
영향도: 성능 최적화 관련
조치 필요성: 인프라 팀 판단 필요

4.2 해결 방안

고객사 의견: 인프라에서 적용해도 무방
주의사항: 노드 재기동 필요

회의 내용:

"(SK) IOMMU 설정은 인프라에서 적용해도 무방하다는 의견을 
받았음 (다만 노드 재기동 필요)"

5. 이슈 #3: Go Routine 급증 (Node 38)

5.1 문제 상황 상세

발견된 증상

노드: Node 38
정상 수치: 약 8,000개 Go routine
급증 수치: 120,000개 Go routine (15배 증가)
발생 시점: 오전 9시~9시 15분 사이
이후 상태: 높은 수준에서 유지 (다시 내려가지 않음)

회의 중 관찰:

"Go routines could mean that this particular node, there's 
a process stock allocating Go routines... you see, I mean, 
we were not able to find a CPU widget on your graph, but 
you see memory is not spiking... the Go routine, it spiked, 
and then it stayed."

그래프 패턴 분석

"whatever happened at nine, yeah, something clearly at 
nine triggered, yeah, and then it stopped and kept stable. 
So it's definitely, could be a variety of things, but 
obviously something at 915, some schedule, process, 
some product started"

5.2 기술적 분석

Go Routine의 특성

경량성: Go routine은 매우 가볍고 비용이 적음
Green Thread: 실제 OS 스레드가 아닌 가상 스레드
메모리 효율: 각 Go routine은 소량의 바이트만 할당

벤더 설명:

"in Go, Go routines are super cheap, yeah, very, very cheap 
to cheaper than threads. So in the Go run time, every time 
you start go routine, it's just kind of like an allocation 
in memory. Just take some bytes"

영향도 평가

긍정적 지표 (문제 없음):
1. 메모리 사용량: 급증하지 않음
2. CPU 사용량: 스파이크 없음
3. 안정적 유지: 추가 증가 없이 일정 수준 유지

회의 중 분석:

"Memory didn't grow. So it's not like an ongoing issue. 
So memory is not skyrocketing. In go you can spawn 10 million 
Go routines, and they're quite cheap."

부정적 지표 (주의 필요):
1. 지속적 높은 수준: 원래대로 돌아가지 않음
2. 원인 불명: 무엇이 트리거했는지 불확실
3. 잠재적 누수: 시간 경과 시 문제 발생 가능성

5.3 추정 원인

가능성 1: 스케줄된 작업

타이밍: 오전 9시 업무 시작 시간
특성: 일회성 대량 작업
예시: 배치 작업, 스캐너, 힐링 프로세스

가능성 2: 특정 파일 액세스

패턴: 동일 파일 반복 읽기
효과: Go routine 생성 증가

가능성 3: Go Routine Leak (누수)

정의: 코드 특정 상황에서 Go routine이 해제되지 않음
증거: 메모리 증가 없음 → 누수 가능성 낮음

벤더 평가:

"So it's not like it's not like hot, right when it will 
span it out of control, but whatever that server decided 
to do, the spike under Go routines, and then it just 
[stayed down]. So I don't think it's an ongoing problem per se."

5.4 진단 방법: MC Admin Profile

Profile 도구 소개

기능: 시스템 상태 15초간 덤프
대상: CPU, 메모리, Go routine
목적: 어디서 Go routine이 생성되는지 Stack Trace 확인

실행 방법:

mc admin profile [alias] --type goroutine

벤더 설명:

"so if you see, look at the interesting circle, it just 
profiles 10 seconds, right? So the default is 15 seconds, 
because profile kind of like taxes the system. It slows 
down... now that file, if you upload it, subnet engineers 
can actually tell you what is the reason"

Profile 옵션

CPU Profile: CPU 사용 패턴
Memory Profile: 메모리 할당 패턴
Go Routine Profile: Go routine 상태 (권장)
Full Profile: 모든 메트릭

주의사항:

"profile kind of like taxes the system. It slows down"

→ 프로파일링 자체가 시스템에 부하를 줌

결과 분석

업로드: Subnet 엔지니어에게 전달
분석: Stack Trace를 통해 코드 어느 지점에서 생성되는지 파악
해결: 근본 원인 규명 후 조치

5.5 상관관계 분석

CPU 상관관계

관찰: CPU 스파이크 없음
의미: Go routine이 대기 상태 (Wait)
결론: 계산 작업을 수행하지 않음

메모리 상관관계

관찰: 메모리 증가 없음
의미: 누수(Leak)가 아닌 대기(Wait) 상태
결론: 즉각적인 위험 없음

기술적 설명:

"if each one of them was doing something, it would be 
concerning. So that's why CPU memory correlation, it shows 
like there was no [spike] and even that metric you could 
see at nine, there was like a spike"

5.6 권장 조치

즉시 조치 (우선순위: 중)

MC Admin Profile 실행
- 타입: Go routine
- 타이밍: 가능한 빨리
- 목적: 근본 원인 파악
결과 파일 벤더 전달
- Subnet 엔지니어 분석 의뢰
- Stack Trace 검토

지속 모니터링 (우선순위: 고)

트렌드 관찰
- Go routine 수 계속 증가하는지
- 안정적으로 유지되는지
성능 지표 확인
- CPU 사용률
- 메모리 사용률
- 응답 시간

장기 대응 (우선순위: 저)

패턴 재발 시 코드 수정 필요
현재는 즉각적 위험 없음

6. 이슈 #4: LDAP 동기화 에러

6.1 문제 상황

발생 빈도 및 패턴

기간: 최근 일주일
발생 횟수: 2회 (4일 동안 동일 에러)
증상: 정책 동기화 실패, IDP 보정 작업 미실행
발생 시간: 불규칙 (자정 등 특정 시간 아님)

고객사 보고:

"identical error took place in four days, and normally 
we would put it to subnet, but now that we're have 
experts here, maybe [we can investigate]"

에러 내용

"it's not syncing with your policies. It's not syncing 
IDP correction using LDAP or OIDC"

6.2 추정 원인 분석

원인 1: Clock Drift (시간 불일치) - 최우선 의심

설명:

LDAP 서버와 클러스터 간 시간 불일치
노드 간 시간 동기화 실패

중요성:

"the only thing I can think of is there a Clock drift? 
Clock drift between nodes, between the LDAP, the LDAP, 
is there a clock drift between the LDAP server and 
the cluster... authentication? They have to be in the 
same time, right?"

기술적 배경:

인증 시스템은 시간 기반 토큰 사용
시간 불일치 시 인증 실패
NTP (Network Time Protocol) 이슈 가능성

벤더 확인:

"NTP issue, right? Yep."

원인 2: 네트워크 타임아웃

설명:

특정 Pool에서 응답 지연
LDAP 서버 접근 시 타임아웃

벤더 질문:

"It could just be a timeout from that pool. You know, 
what's your what's your sync rate?"

원인 3: TLS 설정 변경

질문:

"or did your LDAP change its TLS, its TLS?"

설명:

LDAP 서버의 TLS 인증서 갱신
TLS 버전 변경
보안 정책 업데이트

원인 4: Bind 이슈

과거 경험:

"if it's A bind issue that we spent hours debugging"

설명:

LDAP Bind (연결) 설정 문제
인증 정보 불일치
권한 설정 문제

원인 5: 동기화 주기(Sync Rate) 부적절

동기화 빈도가 너무 높거나 낮음
LDAP 서버 부하와 관련

6.3 진단 방법

현재 테스트 방법의 한계

고객사 현황:

"when you're testing LDAP connections, are you always 
doing it through the browser? [Yes,] normally, web browser"

한계점:

브라우저 기반 테스트만 수행
실제 애플리케이션 접속 패턴과 다름
STS (Shared Token Service) 접속 시나리오 검증 안 됨

권장 진단 도구: 커맨드 라인 스크립트

벤더 제공 예정:

"we have a script we can give you that'll let you test 
that from command line as well. That grabs the token 
and the secret, so you can actually test that as well 
without having to go in."

스크립트 기능:

토큰 및 시크릿 획득
실제 애플리케이션 접속 패턴 시뮬레이션
STS를 통한 LDAP 인증 테스트

장점:

"[for] applications are going to be coming in using 
the shared Token Service... Typical program."

6.4 추가 조사 항목

체크리스트

NTP 동기화 상태
- 모든 노드 시간 확인
- LDAP 서버 시간 확인
- NTP 서버 설정 검증
네트워크 연결성
- LDAP 서버 응답 시간 측정
- 타임아웃 설정 확인
- 방화벽 규칙 검토
TLS/SSL 설정
- 인증서 유효기간 확인
- TLS 버전 호환성 검증
- Cipher Suite 설정 확인
LDAP 서버 로그
- 에러 발생 시점 로그 확인
- Bind 시도 기록 분석
- 인증 실패 패턴 파악
동기화 설정
- Sync Rate 확인
- 정책 동기화 빈도 검토
- 타임아웃 설정 최적화

6.5 해결 방안

단기 조치 (1주일 내)

커맨드 라인 스크립트 적용
- 벤더 제공 스크립트 수령
- 다양한 시나리오 테스트
- 에러 재현 시도
Clock Drift 확인
- NTP 서버 설정 검증
- 모든 노드 시간 동기화 확인
- LDAP 서버와 시간 차이 측정
네트워크 진단
- LDAP 서버 응답 시간 측정
- 네트워크 경로 확인
- 패킷 로스 체크

중기 조치 (1개월 내)

모니터링 강화
- LDAP 동기화 상태 실시간 모니터링
- Alert 설정 (동기화 실패 시)
- 로그 자동 수집 및 분석
설정 최적화
- Sync Rate 조정
- 타임아웃 값 튜닝
- 재시도 정책 수립

장기 조치

LDAP 이중화 검토
Failover 메커니즘 구축
정기 헬스체크 자동화

7. MC Browse 고도화

7.1 기능 개선 사항

기존 MC Browse의 한계

제한적인 UI/UX
정보 표시 부족
엔터프라이즈 요구사항 미충족

새로운 MC Browse 특징

업그레이드 배경:

"because there are so many things that's upgraded and 
the UI is like, UX is completely different... I think 
the reason that MC Bros is upgraded is because there 
were some requests or customer pieces that we saw, 
you know, that enterprise will be able to help."

개선 영역:
1. 모든 노드 및 디스크 모니터링

"remember like there was a new feature in MC AI store, 
MC that you can literally monitor, like all the nodes 
and disks"

글자 하나하나 모니터링 가능
- 노드별 상세 정보
- 드라이브별 성능 편차
- 실시간 상태 업데이트
성능 편차 확인 용이
- Outlier 탐지
- 이상 노드 식별
- 성능 비교 분석

엔터프라이즈 고객 요청 반영:

"엔터프라이즈 고객의 요청으로 MC의 진단 관련 UI/UX가 
대폭 개선되었으며, 이를 통해 성능 편차를 확인하거나 
모니터링하는 것이 훨씬 쉬워졌음"

7.2 활용 시나리오

시나리오 1: 업그레이드 시

단계:
1. 업그레이드 전 상태 스냅샷
2. 업그레이드 진행
3. MC Browse로 실시간 모니터링
4. 이상 징후 즉시 탐지
5. 업그레이드 후 검증

시나리오 2: Pool 확장 시

단계:
1. 기존 Pool 상태 확인
2. 새 노드 추가
3. 리밸런싱 모니터링
4. 성능 균형 확인

시나리오 3: 장애 대응 시

단계:
1. 장애 노드 식별
2. 상세 로그 확인
3. 드라이브 상태 점검
4. 복구 작업 모니터링

7.3 가이드 제공 계획

벤더 계획:

"give them a couple of scenarios, guidances, like, 
they upgrade, what do they see? What do they do for 
like, stuff like that, or even fully expansion... 
we can, like, just drop down those things and share 
it with them. Doesn't have to be done this week"

제공 예정 자료:
1. 시나리오별 사용 가이드
2. 화면 설명 및 해석 방법
3. 일반적인 패턴 및 이상 징후
4. 고객 사례 기반 Best Practice

7.4 릴리즈 일정

최신 버전: 조만간 릴리즈 예정
포함 내용: 개선된 UI/UX, 엔터프라이즈 기능

회의 중 언급:

"개선된 버전은 조만간 Release될 예정임"

8. 성능 메트릭 분석 결과

8.1 Latency (지연 시간)

측정 결과

평균 Latency: 25ms
평가: 매우 양호

기술적 해석:

"the average is consistent with the 40 gigabit... 
it's strange that it's closer to that single server 
also is very low."

맥락:

다양한 API 호출 분산 고려
40Gbps 대역폭 환경
일관된 성능 유지

8.2 Throughput (처리량)

측정 결과

평균 대역폭: 40Gbps
환산: 초당 6~7GB
일관성: 매우 높음

샘플링 특성:

"right now this, the metrics will always report the 
last 30 seconds only, so it's going to be a tougher 
metric to choose the system"

참고 데이터:

100Gbps 환경: 80~90GB/s 기록 사례
현재 40Gbps 환경에서 최적 성능

8.3 Error Rate (에러율)

400계열 에러

비율: 전체 요청 대비 약 3%
원인: 주로 클라이언트 측 이슈
- 권한 없음 (Access Denied)
- 존재하지 않는 객체 호출 (Object Not Found)
- 기타 클라이언트 오류
위험도: 낮음 (정상 범위)

기술 설명:

"400 text servers tend to be either access denied or 
object not found to be some other reason, like services 
and available [or] Max tower Out something else"

500계열 에러

비율: 0.00x % (매우 낮음)
원인: 내부 서버 에러
- 노드 간 통신 문제
- 요청 거부 상황
위험도: 문제 없는 수준

중요성:

"error actually is internal errors. It's something 
happening between nodes that one didn't want to take 
a request for some reason"

모니터링 필요성:

500계열은 시스템 장애 전조 증상
집중 모니터링 필요
현재는 건강한 상태

누적 기간

POD 재기동 이후: 약 70일간 누적 데이터
신뢰성: 충분한 샘플 기간

8.4 리소스 사용률

CPU & Memory

현재 사용률: 약 15%
평가: 매우 낮음
이유: 네트워크 대역폭 우선 사용 애플리케이션

기술적 배경:

"현재 메모리 사용량이 낮은 이유는 네트워크 대역폭 대비 
부하가 높지 않기 때문이며, 접속 수가 급증할 경우 연결 당 
최대 64MB까지 버퍼를 사용하면서 메모리 수치가 상승할 수 있음"

버퍼 메커니즘

연결당 최대: 64MB 버퍼
동적 할당: 접속 수 증가 시 메모리 사용 증가
현재 상태: 낮은 부하로 인한 낮은 사용률

9. 헬스체크 vs 트러블슈팅 비교

9.1 구분 기준

항목	헬스체크	트러블슈팅 (MC Browse)
목적	정기 점검	실시간 문제 해결
빈도	월 1회, 분기 1회	필요 시 즉시
시점	예방적	사후 대응적
범위	전체 시스템	특정 이슈 집중
상세도	일반적	매우 상세
도구	진단 스크립트	MC Browse, MC Admin Profile

9.2 상호 보완적 활용

정기 헬스체크

일정: 매월 또는 분기별
목적: 잠재적 문제 조기 발견
결과: 전반적 시스템 상태 파악

실시간 트러블슈팅

트리거:
- 장애 발생
- 업그레이드 진행
- Pool 확장
- 성능 이상
도구: MC Browse
결과: 즉각적 문제 해결

10. 액션 아이템

10.1 즉시 실행 (1주일 내)

벤더 측

MC Browse 시나리오 가이드 작성
- 업그레이드 시나리오
- Pool 확장 시나리오
- 장애 대응 시나리오
- 화면 해석 방법
LDAP 테스트 스크립트 제공
- 커맨드 라인 스크립트
- 사용 설명서
- 테스트 시나리오
THP 진단 메커니즘 확인
- 내부 조사
- 결과 공유

고객사 측

Node 38 Go Routine 이슈
- mc admin profile 실행 (goroutine 타입)
- 결과 파일 벤더 전달
- 추가 모니터링 설정
LDAP 동기화 진단
- NTP 설정 확인
- 모든 노드 시간 동기화 검증
- LDAP 서버 시간 확인
- 커맨드 라인 스크립트 테스트
THP 설정 이슈
- 특정 노드 재부팅 검토
- 컨테이너 내부 설정 확인
- OS 레벨 설정 검증

10.2 단기 (2주일 내)

벤더 측

진단 도구 패키지 제공
- 헬스체크 스크립트 업데이트
- 자동화 스크립트 개발
- 결과 해석 가이드
모니터링 대시보드 템플릿
- 핵심 메트릭 대시보드
- Alert 설정 가이드
- Grafana 템플릿

고객사 측

정기 헬스체크 체계 수립
- 월간 헬스체크 일정 수립
- 담당자 지정
- 보고 체계 구축
MC Browse 활용 체계
- 시나리오별 사용 절차 수립
- 운영팀 교육
- 로그 관리 체계

10.3 중기 (1개월 내)

공동 작업

모니터링 체계 고도화
- 실시간 Alert 시스템 구축
- 자동 리포팅 체계
- 예측적 유지보수 체계
문제 대응 프로세스 정립
- 단계별 대응 절차
- 에스컬레이션 체계
- 벤더 지원 요청 프로세스

11. 위험 관리

11.1 모니터링 필요 항목

고위험 (즉시 대응 필요)

500계열 에러율 급증
Go Routine 지속 증가
Latency 급격한 상승
노드 다운

중위험 (주의 관찰 필요)

400계열 에러율 증가 추세
THP 설정 불일치
LDAP 동기화 간헐적 실패
메모리 사용률 증가 추세

저위험 (정기 점검으로 충분)

CPU 사용률 변화
드라이브 사용률
네트워크 대역폭 활용도

11.2 Alert 임계값 (권장)

메트릭	경고(Warning)	심각(Critical)
Latency	> 50ms	> 100ms
500 에러율	> 0.1%	> 1%
Go Routine 증가	> 200%	> 500%
메모리 사용률	> 70%	> 85%
CPU 사용률	> 70%	> 85%

12. 교훈 및 Best Practices

12.1 진단 관련

정기적 헬스체크: 월 1회 이상 필수
즉각적 트러블슈팅: MC Browse 활용
상세 분석: MC Admin Profile 활용

12.2 이슈 대응

메모리 상관관계: 문제 심각도 판단의 핵심
CPU 상관관계: 실제 영향도 파악
시간 패턴 분석: 근본 원인 규명

12.3 모니터링

500계열 집중: 시스템 장애 전조
400계열 추세: 클라이언트 문제 파악
성능 지표 일관성: 안정성 지표

13. 다음 단계

13.1 1주일 내

Node 38 프로파일 분석 결과 공유
LDAP 이슈 근본 원인 규명
MC Browse 가이드 수령

13.2 2주일 내

정기 헬스체크 체계 구축
모니터링 대시보드 완성
Alert 시스템 가동

13.3 1개월 내

전체 진단 체계 안정화
운영팀 역량 강화
예방적 유지보수 체계 확립

문서 버전: 1.0
최종 수정일: 2026년 2월 6일
다음 리뷰: 2026년 2월 13일 (주간 진행상황 회의)

부록: 주요 명령어 및 도구

MC Admin Profile

# Go Routine 프로파일
mc admin profile [alias] --type goroutine

# CPU 프로파일
mc admin profile [alias] --type cpu

# 메모리 프로파일
mc admin profile [alias] --type memory

# 전체 프로파일
mc admin profile [alias]

MC Browse

# MC Browse 실행
mc browse [alias]

# 특정 버킷 확인
mc browse [alias]/[bucket-name]

헬스체크 스크립트

# 진단 스크립트 실행 (벤더 제공 예정)
./health-check.sh

# 결과 확인
cat health-check-results.txt

Young-Kyoo Kim

engineer

이전 포스트

26F12a1

다음 포스트