[목 차]
이 책에 대하여 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쪽)
AD광고
AD광고
