사례2건

2건 중 1~2번째

1. IL-0440 파드가 보낸 DNS 쿼리 패킷이 노드에서 버려져 클러스터 내부 서비스의 이름 조회가 no such host 와 i/o timeout 으로 자주 실패했다

   Cybozu2024

   증상

   파드 안의 애플리케이션이 초당 수백 건씩 클러스터 내부 서비스의 이름을 조회하자 no such host 와 i/o timeout 오류가 자주 났다. 쿠버네티스 플랫폼을 쓰는 팀은 클러스터의 DNS 서버에 성능 문제가 있다고 보고 Cloud Platform 팀에 문의했다.

   DNS 조회 실패간헐적 타임아웃패킷 손실

   촉발

   MySQL 클러스터 감시 애플리케이션이 감시하는 클러스터 수가 늘어났고, 그 뒤부터 이름 조회 오류가 잦아졌다.

   원인

   용량 한계

   구성 요소

   리눅스 커널클라이언트 쪽 DNS 리졸버와 캐시

   기여 요인

   기본 설정 방치

   감지

   Cloud Platform 팀은 쿠버네티스 플랫폼을 쓰는 팀에게서 클러스터 DNS 서버에 성능 문제가 있다는 문의를 받고 알게 됐다.

   조치

   • 커널 파라미터 net.core.netdev_max_backlog 값을 늘렸다.
   • softnet 지표에 알림을 설정했다.
   • softnet 알림에 대응하는 런북을 마련했다.

   후속 조치

   • veth 인터페이스를 netkit 인터페이스로 바꿔 파드의 송신 패킷이 backlog 큐를 거치지 않고 물리 장치로 바로 가게 하는 방안을 검증한다. netkit 은 리눅스 커널 6.7 에 들어온 가상 네트워크 장치이고, Cilium 1.16 부터 쓸 수 있다.

   교훈

   netdev_max_backlog 를 늘리고 softnet 알림과 런북을 두면 같은 장애가 덜 나고, 나더라도 일찍 알아챌 수 있다. 다만 값을 늘리는 것은 근본 대책이 아니어서, 더 많은 패킷을 보내는 파드가 배포되면 backlog 큐가 다시 차고 패킷이 버려질 수 있다.

   사례 보기
2. IL-0439 블록 디바이스와 파일 시스템을 확장할 때마다 데이터베이스 접근이 한동안 느려졌다

   Cybozu2018

   증상

   SQLite 데이터베이스가 놓인 파일 시스템의 크기를 늘린 뒤 데이터베이스 접근이 한동안 느려졌다. 이 현상은 고객이 쓰는 애플리케이션의 응답 속도 저하로 나타났고, Cybozu 는 오랫동안 이 문제를 겪었다.

   지연 시간 증가

   촉발

   데이터베이스가 커져 빈 공간이 모자라자 파일 시스템이 놓인 블록 디바이스의 크기를 늘리고 그 위의 파일 시스템 크기를 늘렸다.

   원인

   소프트웨어 결함

   구성 요소

   리눅스 커널데이터베이스

   기여 요인

   –

   감지

   파일 시스템 확장 뒤 데이터베이스 접근이 느려진 것이 고객이 쓰는 애플리케이션의 응답 속도 저하로 드러났다.

   조치

   • 블록 디바이스 크기가 줄어들 때만 flush_disk() 를 부르고 늘어날 때는 페이지 캐시를 무효화하지 않도록 fs/block_dev.c 의 check_disk_size_change() 를 고치는 패치를 만들었다.
   • 이 패치를 넣은 커널을 개발 환경에서 시험한 뒤 운영 환경에 적용해 사내 문제를 풀었다.

   후속 조치

   • 자사 시스템을 받치는 OSS 의 개선에 기여하고 나중에 OS 를 올릴 때 수정 패치를 일일이 백포트하지 않으려고, 패치를 upstream Linux 커널에 넣는 작업을 했다. 패치는 v4.17 에 들어갔다.

   교훈

   Cybozu 는 소스 수정의 수고가 바뀐 줄 수에 비례하지 않는다고 했다. 이번 수정은 2천만 줄에 이르는 Linux 커널 소스에서 4줄을 더하고 2줄을 지운 것에 지나지 않았지만, 거기까지 여러 시행착오가 있었다. 코드를 쓴 의도를 모를 때는 주석이나 변경 때의 커밋 설명을 보는 것이 정석이라고도 했다.

   사례 보기

원인별2