Workers Browser Rendering API enters open beta : Cloudflare에서 Workers Browser Rendering API의 오픈 베타를 시작했다. Workers Browser Rendering API를 이용하면 Cloudflare의 워커에서 헤드리스 브라우저를 사용할 수 있고 Puppeteer를 워커에서 사용할 수 있도록 제공하고 있으므로 워커에서 Puppeteer API를 그대로 사용할 수 있다.(영어)
그 밖의 개발 관련
State of Node.js Performance 2023 : Node.js의 성능을 벤치마킹한 글인데 다른 런타임과 비교한 것은 아니고 Node.js의 16, 18, 20 버전 간의 성능 차이를 테스트했다. 벤치마크 제품을 Node.js internal benckmark, 자체적으로 만든 nodej-sbench-operations, HTTP 서버로 나누어 테스트했다. 테스트 레포도 제공하고 있어서 직접 확인해 볼 수 있으며 파일시스템, Event, HTTP, 모듈, 스트림, 버퍼 등으로 나누어 각 버전에서 어떻게 성능이 차이가 나는지를 비교해 준다.(영어)
장애는 UTC 기준 3월 8일 6:03에 시작되어 16:44에 처음으로 주요 서비스를 다시 운영하기 시작했고 9일 8:58에 모든 지역 모든 서비스를 운영하기 시작했고 10일 6:25분 과거 데이터를 채운 후 완전히 해결되었다.
장애 대응 팀은 10명의 선인 엔지니어링 리더, 70명의 현지 장애 지휘관, 450~750명의 장애 대응자로 구성된 비상 운영 센터를 운영했고 장애 해결까지 4교대 근무를 했다.
실시간 텔레메트리 데이터가 가장 중요했기에 데이터의 정상적인 수집과 처리를 복구하는 데 먼저 집중했고 서비스 복구후 과거 데이터를 복구했다.
장애 원인은 systemd의 보안 업데이트가 여러 VM에 자동으로 적용되면서 systemd-networkd가 재시작되면서 Kubernetes CNI 플러그인(Cilium)이 관리하는 라우팅 테이블을 systemd-networkd가 삭제하면서 노드가 오프라인 상태가 되었다.
정상적인 부팅 절차에서는 systemd-networkd를 먼저 시작하고 CNI 플러그인이 라우팅 테이블을 설치하기 때문에 새로 부팅하거나 재부팅된 노드에서는 해당 현상이 재현되지 않아서 문제 확인이 어려웠다.
보안 업데이트는 기본 OS 이미지의 레거시 보안 업데이트 채널이 활성화되어 있었기 때문에 자동으로 업데이트가 적용되었다. OS 이미지를 최소한으로 사용했기에 기존에 이런 업데이트가 거의 없었기에 놓쳤던 부분이다.
각 리전에 있는 인프라는 의도적인 설계상 집적접인 네트워크 연결이 전혀 없었음에도 자동 업데이트가 UTC 6:00~7:00 사이의 윈도우로 설정되어 있었기 때문에 비슷한 시간에 여러 리전에 걸쳐서 장애가 발생하는 원인을 찾기가 쉽지 않았고 이렇게 간접적으로 연결되었다는 것을 생각하지 못했기에 초기 대응에서 원인을 찾지 못했다.
레거지 보안 업데이트 채널을 비활성화해서 자동 업데이트가 되지 않게 하고 systemd-networkd가 라우팅 테이블을 변경하지 않도록 수정했다.
Datadog을 오랫동안 Ubuntu를 사용했고 Kubernetes로 마이그레이션 하면서도 Ubuntu를 계속 사용했다. 최신 LTS를 사용하는 것이 목표이지만 보통 새 버전이 다 오면 몇 달 동안 기다리다가 테스트를 시작한다.
Ubuntu 22.04sms 2022년 6월에 테스트를 시작해 2022년 11월부터 프로덕션에 점진적 적용을 시작했다.
Ubuntu 20.04는 systemd v245를 사용하고 Ubuntu 22.04는 v249를 사용한다.
systemd v248에서 알지 못하는 IP 규칙을 플러시 하는 새 동작이 추가되고 v249에서 이를 옵트아웃 할 수 있는 설정이 추가된 뒤 v248, 247에 백포트되었다.
Ubuntu 22.04에 이 새로운 systemd-networkd 동작이 포함되어 있었지만, 앞에 글에서 얘기한 대로 systemd-networkd를 시작한 뒤에 라우팅 규칙을 추가하므로 문제가 되지 않았다.
2023년 3월 7일 Ubuntu 레포지토리에 systemd의 취약점 패치가 등록되고 이 패치를 설치하면 systemd의 구성 요소가 모두 재시작된다. 2022년 말 Ubuntu 22.04를 적용하기 시작한 뒤로 systemd 패치는 없었기 때문에 systemd-networkd 재시작으로 발생하는 문제를 이전에 발견하지 못했다.
같은 CVE이 패치가 Ubutun 20.04에 포함된 systemd v245에도 적용되었지만 여기서는 IP 규칙이 플러시 되지 않으므로 Ubutun 20.04를 사용하는 노드는 영향을 받지 않았다.
무인 업그레이드를 위해 Ubuntu 기본값을 사용하고 UTC 6:00, 18:00 두 번 1시간의 윈도우를 통해서 업그레이드를 실행하고 있다.
이는 서버가 실행된 뒤에 systemd-networkd가 재시작된 경우에만 발생하기 때문에 노드마다 차이가 있었다. Google Cloud에서는 UTC 3월 7일 18:50부터 패치가 적용된 systemd를 사용할 수 있던 것으로 보여 그 이전에 업데이트가 실행된 노드는 영향을 받지 않앗따.
AWS, Azure, Google Cloud를 모두 쓰기 때문에 클라우드마다 설정이 약간 다르지만, Cilium이 Pod 네트워킹을 대체할 수 있도록 IP 규칙이 구성되어 있다.
systemd-networkd가 재시작 되면서 이 규칙이 플러시되었기 때문에 클라우드마다 약간 다르지만 네트워크 문제가 발생했다.
AWS는 헬스 체크 문제를 감지하고 인스턴스를 종료하고 재시작했기에 바로 복구 되었지만 Google Cloud와 Azure는 네트워크만 끊어졌고 인스턴스는 괜찮았기 때문에 API를 통해 직접 재시작해서 복구했다. 이때문에 당애시에는 Google Cloud와 Azure가 더 심각한 상황이라고 판단했지만 Google Cloud와 Azure는 재시작할 때 디스크까지 같이 복구 되었지만 AWS는 인스턴스가 종료되면서 로컬 디스크의 데이터도 잃었기 때문에 이후 복구가 훨씬 어려웠다.
Building and deploying MySQL Raft at Meta : Facebook이 semisynchronous 복제 프로토콜을 이용해서 다른 리전에 복제본을 이용하고 있었으나 구성도 복잡하고 관리가 어려워서 많은 문제를 일으킨다는 것을 깨닫고 Raft 합의 알고리즘을 도입했다. Apache Kudu를 기반으로 한 MySQL용 Raft 구현인 kuduraft를 오픈소스로 공개했다. 프라이머리가 Raft로 binlog에 쓰고 Raft가 binlog를 팔로어/리플리케이터에 보내게 된다. MySQL Raft를 통해 MySQL 서버가 프로모션과 멤버십을 처리하도록 했기 때문에 운영상의 어려움이 크게 줄어들었다고 한다.(영어)
Using OCI artifacts to distribute security profiles for seccomp, SELinux and AppArmor : Kubernetes에서 Security Profiles Operator(SPO)를 사용하면 보안 기능인 seccomp(secure computing mode), SELinux, AppArmor을 관리할 수 있는데 이때 클러스터에 기본 프로파일을 관리하고 애플리케이션에 연결해서 사용할 수 있습니다. 그동안은 기반 프로파일을 관리하는데 어려움이 있었지만 SPO 0.8.0부터는 OCI 아티팩트 기본 프로파일을 지원할 수 있게 되었다. 같이 제공되는 spoc 명령어를 사용해서 OCI 프로파일을 레지스트리에 등록하는 방법도 설명한다.(영어)
볼만한 링크
The Dangers of Google’s .zip TLD : 최근 Google에서 .zip 최상위 도메인을 공개했는데 보안 커뮤니티에서 .zip 도메인의 위험성을 제기하고 있다. 도메인에서 @ 앞부분은 아이디/패스워드를 넣는 사용자 정보로 인식하므로 슬래시(/)와 유사한 U+2215(∕)를 사용하면 https://google.com∕search@bing.com같은 도메인이 google.com으로 간다고 생각할 수 있지만 실제로는 bing.com으로 가게 된다. 다음과 같이 한눈에 구별하기 어려운 zip 파일의 피싱 주소를 만들 수 있다.(영어)
1Password is finally rolling out passkey management : FIDO 얼라이언스에서 만든 passkey를 1Password에서 지원하기 시작했다. 6월 6일부터 오픈 베타로 사용해 볼 수 있으며 저장된 passkey는 디바이스 간 동기화가 된다. passkey를 이용하면 비밀번호 없이 디바이스의 생체 인식 인증을 사용해서 로그인할 수 있다.(영어)
Lyft’s secret plan to take control of its maps — and its future : 차량 공유 서비스인 Lyft가 기존에 사용하던 Google Maps 대신 OpenStreetMap을 사용하기로 했다고 한다. 운전자는 Google Maps의 네비게이션으로 넘어가는 경우가 많았기에 비용도 달라지거나 경험 개선에도 한계가 있었기에 자체 네비게이션 경로로 상당한 비용을 줄일 수 있다고 판단했다고 한다. 2019년 OpenStreetMap이 충분히 좋아졌다고 판단하고 이를 사용해서 픽업을 더 쉽게 하고 라이딩 등의 경험을 개선할 수 있도록 적용하고 있다고 한다.(영어)
Comments