실패하지 않는 관측 가능성과 AIOps 데이터 기반 운영 이 책은 관측 가능성을 기반으로 분산 추적, 메트릭, 로그, 이벤트, 시스템 추적, 프로파일까지 이어지는 전 구간 관측과 데이터 구조화 전략을 통해 근본 원인 분석(RCA)의 실제 작동 원리를 체계적으로 설명한다. 프롬스케일 기반 SQL 분석, 메트릭 상관관계와 이상 탐지를 통해 장애의 범위를 좁히고, 나아가 오픈서치 기반 RAG/LLM, 벡터 임베딩/리랭킹, 에이전트 자동화, CMDB와 장애 목록 데이터 모델을 결합해 근본 원인 분석을 자동화하는 AIOps 아키텍처를 제시한다. SRE를 중심에 두고 AIOps를 보조 지능으로 활용하는 현실적인 운영 전략의 묘를 터득할 수 있다.

이 책에 대하여 x CHAPTER 1 근본 원인 분석이란 1 1.1 관측 가능성 2 __1.1.1 상관관계 5 / 1.1.2 대시보드 8 / 1.1.3 기술 스택 9 1.2 근본 원인 분석 과정 11 __1.2.1 문제 영역 식별 12 / 1.2.2 개별 요청 분석 17 / 1.2.3 하위 수준 이해 24 1.3 관측 가능성 신호 31 __1.3.1 로그 31 / 1.3.2 실사용자 모니터링 38 / 1.3.3 프로파일 49 __1.3.4 디버깅 57 / 1.3.5 이벤트 59 / 1.3.6 이상치 63 __1.3.7 근본 원인 분석 데이터 모델 64 1.4 요약 66 CHAPTER 2 근본 원인 분석의 접근법 67 2.1 14가지 상관관계 68 __2.1.1 분산 추적에서 시스템 추적으로 69 / 2.1.2 이벤트에서 추적으로 70 __2.1.3 추적에서 로그로 71 / 2.1.4 추적에서 프로파일로 71 __2.1.5 로그에서 프로파일로 72 / 2.1.6 메트릭에서 추적으로 72 __2.1.7 실사용자 모니터링에서 추적으로 73 / 2.1.8 이벤트에서 이상 탐지로 74 __2.1.9 로그에서 추적으로 74 / 2.1.10 네트워크에서 추적으로 75 __2.1.11 추적에서 메트릭으로 76 / 2.1.12 추적에서 서비스 맵으로 76 __2.1.13 서비스 맵에서 메트릭으로 77 / 2.1.14 메트릭에서 로그로 77 2.2 시각화 78 __2.2.1 폴리스탯 78 / 2.2.2 서비스 맵 79 / 2.2.3 히스토그램 80 __2.2.4 히트맵 81 / 2.2.5 시계열 차트 82 / 2.2.6 플레임 그래프 82 __2.2.7 스테이트 타임라인 83 / 2.2.8 스테이트 83 __2.2.9 추적 84 / 2.2.10 애너테이션 84 2.3 대시보드 개발 84 2.4 요약 87 CHAPTER 3 추적 중심의 관측 가능성 89 3.1 추적과 다른 신호들 90 3.2 추적의 작동 방식 91 __3.2.1 콘텍스트 94 / 3.2.2 전파자 95 / 3.2.3 추적 전파 100 __3.2.4 배기지 전파 105 / 3.2.5 오픈트레이싱 심 106 3.3 관리형 서비스의 전파 108 __3.3.1 AWS 클라우드프런트 데모 110 / 3.3.2 GCP Pub/Sub 데모 114 __3.3.3 애저 SQS 데모 121 3.4 메시지 서버의 전파 128 __3.4.1 솔러스 JMS 데모 129 / 3.4.2 팁코 JMS 데모 132 __3.4.3 MQTT 데모 134 / 3.4.4 카프카 데모 136 __3.4.5 스프링 클라우드 스트림 데모 138 3.5 EAI 서버의 전파 141 __3.5.1 추적 구현의 어려움 143 / 3.5.2 BPM 서버의 계측 144 3.6 블랙박스의 전파 144 3.7 서버 프레임워크의 전파 146 __3.7.1 미들웨어 146 / 3.7.2 마이크로서비스 패턴 147 __3.7.3 AWS 및 GCP API 서버 148 / 3.7.4 상용 관측 가능성 SDK 추적 데모 149 __3.7.5 마이크로미터 추적 데모 151 / 3.7.6 상용 관측 가능성과 오픈텔레메트리 데모 152 __3.7.7 웹소켓 데모 154 3.8 오픈텔레메트리 익스텐션 159 __3.8.1 바이트코드 계측 데모 161 / 3.8.2 익스텐션 데모 164 __3.8.3 익스텐션 디버깅 169 3.9 상용 관측 가능성의 전파 171 __3.9.1 상용 관측 가능성의 자동화 173 / 3.9.2 에이전트 카오스 177 3.10 요약 183 CHAPTER 4 산업별 근본 원인 분석 사례 184 4.1 은행의 관측 가능성 185 __4.1.1 은행 프로세스의 특성 186 / 4.1.2 은행 레거시 192 / 4.1.3 은행 데모 212 4.2 통신사의 관측 가능성 226 __4.2.1 통신사의 업무 227 / 4.2.2 통신사 오케스트레이션 서버 230 __4.2.3 통신사 아키텍처 232 / 4.2.4 주문 오케스트레이션 240 __4.2.5 네트워크 프로비저닝 245 4.3 온라인 게임의 관측 가능성 249 __4.3.1 온라인 게임 운영 250 / 4.3.2 온라인 게임 데모 252 __4.3.3 로그 254 / 4.3.4 메트릭 255 / 4.3.5 추적 256 4.4 증권사의 관측 가능성 258 __4.4.1 초저지연 애플리케이션 개발 258 / 4.4.2 초저지연 서버 사례 270 4.5 요약 272 CHAPTER 5 오픈텔레메트리 데모 274 5.1 데모 개요 275 __5.1.1 애플리케이션 276 / 5.1.2 파이프라인 277 / 5.1.3 피처 플래그 277 __5.1.4 배포 278 / 5.1.5 부하 테스트 278 5.2 SLO 278 __5.2.1 대시보드 279 / 5.2.2 가용성과 에러율 282 __5.2.3 데모의 에러 구현 283 / 5.2.4 차트 285 5.3 관측 가능성 데모 286 __5.3.1 프로파일 지원 287 / 5.3.2 오픈텔레메트리 에이전트 292 __5.3.3 오픈텔레메트리 컬렉터 292 / 5.3.4 실사용자 모니터링 294 __5.3.5 자동 계측 296 / 5.3.6 상용 관측 가능성 데모 298 __5.3.7 라이브 디버깅 299 / 5.3.8 배기지 콘텍스트 301 __5.3.9 스팬 속성 301 / 5.3.10 스팬 애너테이션 305 __5.3.11 프롬스케일 쿠버네티스 308 / 5.3.12 프롬스케일 SQL 314 5.4 요약 316 CHAPTER 6 인프라 근본 원인 분석 317 6.1 시스템 추적 319 __6.1.1 KUtrace 321 / 6.1.2 비정상적 근본 원인의 유형 325 __6.1.3 ftrace 336 / 6.1.4 ftrace의 시각화 339 / 6.1.5 시스템 유틸리티 341 6.2 커널 작동 방식과 개발 341 __6.2.1 커널의 주요 개념과 작동 방식 342 / 6.1.2 커널 개발 351 6.3 eBPF 356 __6.3.1 BCC와 bpftrace 357 / 6.3.2 PCP 367 6.4 네트워크 장애 카오스 엔지니어링 데모 373 __6.4.1 카오스 메시 구성 374 / 6.4.2 쿠버네티스 구성 376 / 6.4.3 재전송 분석 377 6.5 eBPF와 실리움 380 __6.5.1 메트릭 381 / 6.5.2 허블 383 / 6.5.3 그라파나 플러그인 386 6.6 실리움과 L7 네트워크 386 __6.6.1 골든 시그널 388 / 6.6.2 문제 감지 388 / 6.6.3 추적 연계 389 6.7 실리움 L7 네트워크 장애 데모 389 __6.7.1 구성 390 / 6.7.2 실리움 배포 391 / 6.7.3 coreapi 배포 394 __6.7.4 외부 서비스의 연계 에러 394 / 6.7.5 coreapi 에러율 증가 394 __6.7.6 추적 전파 395 6.8 실리움 추가 기능 397 __6.8.1 네트워크 정책 397 / 6.8.2 L3 정책 399 / 6.8.3 L7 정책 401 __6.8.4 멀티 클러스터와 서비스 메시 402 / 6.8.5 인그레스 403 6.9 요약 403 CHAPTER 7 인프라 이상 탐지 405 7.1 이상치 406 7.2 SQL 이상 탐지 406 __7.2.1 이상 탐지 방법 407 / 7.2.2 이상치 형태 410 7.3 머신러닝 이상 탐지 411 __7.3.1 오픈서치 데이터셋 413 / 7.3.2 이상 탐지 작업 절차 413 __7.3.3 비율 분석 416 / 7.3.4 카테고리 분석 418 / 7.3.5 모집단 분석 419 __7.3.6 패턴 분석 422 / 7.3.7 버킷 분석 422 7.4 이상 탐지 결과 분석 424 __7.4.1 결과 분석 방법 424 / 7.4.2 결과 분석 API 425 7.5 이상 탐지 구성 430 __7.5.1 오픈서치 이상 탐지 구성 데모 430 / 7.5.2 감지기 고려 사항 434 7.6 요약 435 CHAPTER 8 관측 가능성 데이터 분석 436 8.1 SQL 데이터 분석 438 __8.1.1 시간 윈도 438 / 8.1.2 누적값 계산 439 / 8.1.3 계절성 분석 440 8.2 프롬스케일 441 __8.2.1 프롬스케일 저장 과정 442 / 8.2.2 프롬스케일 메서드 442 8.3 프롬스케일 데모 444 __8.3.1 메트릭 SQL 445 / 8.3.2 메트릭 SQL 데모 446 __8.3.3 추적 SQL 451 / 8.3.4 추적 SQL 데모 452 8.4 요약 459 CHAPTER 9 관측 가능성 데이터 집계 460 9.1 프레스토 사례 461 __9.1.1 하이브 463 / 9.1.2 테이블 준비 463 / 9.1.3 프레스토 특징 464 __9.1.4 프레스토 구성 465 9.2 아파치 드루이드 사례 471 __9.2.1 드루이드 컴포넌트 472 / 9.2.2 성능 개선 476 __9.2.3 드루이드 관측 가능성 483 9.3 요약 491 CHAPTER 10 AIOps 492 10.1 개요 492 10.2 AIOps의 한계 493 __10.2.1 사례 1: 스레드풀 494 / 10.2.2 사례 2: 자바 가상머신 494 __10.2.3 사례 3: 엔진엑스 495 10.3 AIOps의 두 가지 측면 496 __10.3.1 상관관계 비교분석 496 / 10.3.2 근본 원인 분석 질의응답 497 10.4 AIOps 상관관계 497 __10.4.1 메트릭 상관관계 데모 구성 498 / 10.4.2 메트릭 상관관계 데모 실행 500 10.5 IT 운영 데이터 505 __10.5.1 대시보드 507 / 10.5.2 높은 품질의 데이터 508 / 10.5.3 CMDB 509 10.6 장애 목록 데이터 모델 512 __10.6.1 시스템 리소스 장애 514 / 10.6.2 클러스터 장애 514 __10.6.3 서버 프레임워크 장애 515 / 10.6.4 레거시 미들웨어 장애 515 __10.6.5 데이터 파이프라인 장애 519 / 10.6.6 데이터 정합성 장애 519 __10.6.7 관측 가능성 장애 521 __10.6.8 근본 원인 분석 데이터 모델과 장애 목록 데이터 모델 522 10.7 요약 523 CHAPTER 11 RAG와 MCP를 활용한 AIOps 524 11.1 랭체인 525 __11.1.1 LLM 526 / 11.1.2 프롬프트 템플릿 527 / 11.1.3 체인 527 __11.1.4 에이전트 527 / 11.1.5 도구 529 / 11.1.6 메모리 530 11.2 관측 가능성 데이터 검색을 위한 벡터 데이터베이스 530 __11.2.1 시맨틱 검색 531 / 11.2.2 오픈서치 벡터 데이터베이스 532 __11.2.3 랭체인 벡터 데이터베이스 539 11.3 오픈서치 AIOps 540 __11.3.1 오픈서치 RAG 542 / 11.3.2 관측 가능성 RAG 552 __11.3.3 근본 원인 분석 RAG 556 11.4 RAG 고급 기능 563 __11.4.1 리랭킹 563 / 11.4.2 자연어처리 567 / 11.4.3 가드레일 568 __11.4.4 RAG 데이터 관리 570 / 11.4.5 후속 처리 571 11.5 MCP 근본 원인 분석 에이전트 573 __11.5.1 MCP 573 / 11.5.2 에이전트 워크플로 580 __11.5.3 랭그래프 585 11.6 AI 관측 가능성을 위한 OpenLLMetry 596 __11.6.1 워크플로 수동 계측 599 __11.6.2 오픈텔레메트리 Gen AI 601 11.7 요약 602 맺음말 603 찾아보기 606

애플리케이션과 인프라가 직접적으로 영향을 주는 상황에서, 문제가 발생하면 양쪽을 모두 이해하고 해결책을 찾을 수 있어야 한다. 애플리케이션과 인프라 모두를 이해시키기 위해서는 SRE의 역할이 중요하며, 이를 위한 지식과 경험이 필요하다. 개발자, 아키텍트, 프로덕트 오너, 인프라 운영자를 모두 설득하고 가이드해줄 수 있는 그 역할이 바로 SRE이다. 이 책은 조직과 기술 간 차이점을 서로 이해할 수 있도록 돕고, 이를 통해 신뢰성과 관측 가능성을 향상하는 방법을 설명한다. (x쪽)

상용 관측 가능성을 사용하는 경우에는 오픈텔레메트리보다 상용 관측 가능성을 우선적으로 계측하고, 오픈텔레메트리는 낮은 우선순위로 계측하고 호환성을 유지해야 한다. 상용 관측 가능성은 x-datadog, x-dynatrace처럼 헤더에 x- 추적 콘텍스트를 지원한다. 상용 관측 가능성 에이전트가 계측하는 마이크로서비스 간에는 x-를 이해할 수 있기 때문에 전파가 가능하다. 오픈텔레메트리는 traceparent만 사용하고, x- 헤더는 사용할 수 없다. (…) 하지만 추적에 사용되는 헤더는 traceparent만이 아니고, tracestate라는 다른 헤더가 있다. (177~178쪽)

통신 업계의 주문은 다른 업계의 주문과 달리 그 과정이 역동적이다. 예를 들어 신규 활성화, 번호 이동, 추가 서비스에 대한 주문은 전자상거래 주문보다 더 복잡하다. 기업 주문은 개인 주문보다 더 복잡하다. 네트워크 장비의 설계와 구축이 필요하기 때문이다. / Saga 패턴을 사용해서 분산 트랜잭션을 처리하는 과정을 구현해보자. 팁코 주문 풀필먼트 기반의 오케스트레이션 서버를 사용해 유무선 통신사 개통 프로세스를 구현한다. 오케스트레이션 서버는 풀필먼트 규칙 및 프로세스를 정의하고, 주문 제출부터 네트워크 내 서비스 활성화에 이르는 전 과정을 자동화한다. (238쪽)

KUtrace는 시스템 추적을 지원하는 오픈소스다. KUtrace는 인프라의 추적을 지원하며, 인프라 수준의 스팬을 생성한다. 모든 시스템 콜, 인터럽트, 트랩, 콘텍스트 전환 등 유저공간과 커널공간 간의 모든 전환을 포착하고, 타임스탬프와 함께 보여준다. CPU 코어마다 초당 20만 개의 이벤트를 수행한다고 할 때, CPU 오버헤드는 0.5% 미만으로 ftrace 같은 도구보다 약 10배나 빠르다. 또한 기록된 정보는 메가바이트 커널 추적 버퍼에 기록된다. CPU, 메모리, 디스크, 네트워크 등 다양한 시스템 리소스의 지연을 확인할 수 있다. / 이벤트마다 타임스탬프 20비트와 이벤트 번호 12비트로 총 4바이트만 기록한다. 추적을 의미 있는 정보로 전환할 수 있도록 후처리를 하는데, 후처리에서 나노초 단위로 코어가 어떤 작업을 수행하는지 볼 수 있다. 또한 마커를 이용해, 커널공간이나 유저공간의 코드에 수동으로 애너테이션을 추가할 수도 있다. (321쪽)

시맨틱 검색을 사용하면 검색 문서에 임베딩을 사용하여 검색 결과의 관련성을 향상시킬 수 있다. k-NN은 점(벡터) 집합과 쿼리가 주어지면 집합에서 쿼리에 가장 가까운 점 k개를 찾는 알고리즘으로, 다른 ML 기법에 비해 비교적 간단하다. 집합의 각 벡터에 대해 쿼리의 거리를 계산하고, 그 과정에서 상위 k를 추적하는 접근 방식이다. / 이러한 접근 방식의 문제점은 확장이 어렵다는 것이다. 런타임 검색 복잡도는 O(N log k)인데, N은 벡터의 수이고 k는 가장 가까운 이웃의 수다. 집합이 수천 개의 벡터로 이루어져 있다면 문제가 없겠지만, 크기가 수백만 개로 늘어나면 눈에 띄게 달라진다. ‘정확한’ k-NN 알고리즘을 사용하면, 검색 속도를 높일 수 있지만, 더 높은 차원에서는 ‘대략적인’ 비교 방식의 알고리즘과 비슷한 성능을 보이는 경향이 있다. (531~532쪽)

예제를 보면, API 호출 후 그래프를 일시 중지하여 작업을 검토하고 승인한다. 작업이 거부되면 그래프가 해당 단계를 실행하지 못하도록 하고 다른 작업을 수행할 수 있다. 예를 들어 근본 원인 분석 에이전트의 결과를 검토 후, 기대에 미지치 못하는 경우에 리랭킹을 호출할 수 있다. (…) 다음 그림과 같이 랭그래프 워크플로는 채널과 백엔드의 애플리케이션과 연계하게 된다. 백엔드에 비해서 채널은 더 어렵고 복잡하다. 다양한 채널에서 백엔드로 전달하는 과정이 간단하지 않다. 랭그래프와 MCP를 사용해서 애플리케이션과 연계하는 것은 어려운 작업이 아니고, 대부분의 공수는 다양한 채널과 백엔드 에이전트 프레임워크와의 연계에서 발생한다. (588쪽)

AI 시대 SRE를 위한 최고의 AIOps 바이블 AI 에이전틱 코딩 시대, 소프트웨어 엔지니어링의 핵심은 코드 작성이 아니라 서비스 운영 역량이라는 과감한 주장까지 나오고 있다. 장기간 안정적으로 시스템을 운영하는 SRE의 중요성이 부각된다는 것이다. 이 책은 이러한 시대적 요구에 부응하는, AI 시대의 SRE를 위한 바이블 같은 책이다. 관측 가능성에서 AIOps까지의 긴 흐름을 따라가며, 시스템 장애를 어떻게 이해하고 설명할 수 있는지 상세하게 풀어낸다. 로그나 메트릭을 나열하는 데 그치지 않고, 관측 가능성 데이터가 실제로 근본 원인 분석에 어떻게 사용되는지에 초점을 맞춘 점이 인상적이다. 현대 IT 인프라는 애플리케이션, 미들웨어, 클러스터, 네트워크, 커널, 하드웨어가 복잡하게 얽혀 있으며, 장애 원인은 단일 지점이 아닌 신호의 상관관계 속에 숨어 있다. 이에 분산 추적, 메트릭, 이벤트와 같은 서로 다른 신호를 데이터 관점에서 구조화하고 분석하는 과정을 구체적으로 설명한다. 은행, 통신사, 온라인 게임 등 산업별 사례를 수록한 것도 큰 장점으로서, 단순한 도구 소개가 아니라 운영 데이터를 어떻게 해석하고 연결해야 하는지에 대한 사고 과정을 깨우치게 한다. 한편으로는 인프라 저수준까지 내려가 들여다보는 만큼 따라가기 만만한 책은 아니지만, 현장에서 장애 대응과 분석을 반복한 경험이 있다면, 이 책이 제시하는 관점에 공감할 지점이 많을 것이다. 이론, 도구, 알고리즘, 데이터 모델, 그리고 현장에서 바로 적용 가능한 운영 전략까지, 관측 가능성을 단순한 유행어가 아닌 실질적인 분석 도구로 이해하고 싶은 모든 엔지니어에게 좋은 길잡이가 되는 책이다. 대상 독자 ●관측 가능성을 자동화하고 AIOps를 이해하고 싶은 데이터 엔지니어 ●근본 원인을 신속하게 식별하고 해결책을 이해하고 싶은 SRE ●레거시가 많은 금융, 통신사에 근무하지만 새로운 관측 가능성을 도입하고 싶은 운영자 ●관측 가능성을 기술적으로 고도화하고 비즈니스적인 가치를 이해하고 싶은 아키텍트 ●테크 기업과 대기업의 관측 가능성 베스트 프랙티스가 궁금한 개발자 주요 내용 ●관측 가능성 신호 기반 애플리케이션/인프라 전 구간 통합 관측 ●분산 추적/스팬 메트릭과 시스템 추적(eBPF/KUtrace/ftrace)의 상관분석 ●프롬스케일 기반 메트릭/추적 SQL 분석과 데이터 구조화 전략 ●메트릭 상관관계 분석과 k-NN/RCF 기반 이상 탐지 기법 ●오픈서치 기반 이상 탐지/벡터 DB/RAG/LLM 질의응답 시스템 ●CMDB/장애 목록 데이터 모델/에이전트를 결합한 AIOps 자동화