Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

기술 뉴스 #223 : 23-06-01

웹개발 관련

  • 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, 모듈, 스트림, 버퍼 등으로 나누어 각 버전에서 어떻게 성능이 차이가 나는지를 비교해 준다.(영어)
  • Bcrypt at 25: A Retrospective on Password Security : 비밀번호 해싱 함수인 Bcrypt를 1997년에 David Mazières와 함께 만든 Niels Provos가 25년을 맞이하여 비밀번호 보안에 대한 회고를 적은 글이다. 이 글을 통해 비밀번호 해시 함수의 발전 과정과 지금의 상황을 엿볼 수 있다.(영어)

    • 1970년대 켄 톰슨과 데니스 리치가 개발한 Unix에서 crypt라는 강력한 암호 해싱 기능을 도입. 이후 솔트와 DES 암호를 반복하는 기능 등이 개발됨
    • 보안과 공격에 대한 우려로 Bcrypt를 개발했고 David Mazières가 적응형 해싱(adaptive hashing)을 고안하고 운 좋게 협력해서 구현할 기회를 얻음.
    • 1997년 6월 OpenBSD 2.1의 일부로 소개되고 1999년 USENIX에서 발표해 암호 보안에 큰 영향을 미침
    • 과거에는 비밀번호 데이터베이스를 도난당하는 게 흔한 일이었고 crypt의 도입으로 비밀번호를 일반 텍스트로 저장하지 않게 됨
    • 공격자들은 사전 공격, 무차별 대입 등으로 비밀번호를 추측하고 저장된 해시를 비교해서 비밀번호를 찾아냄.
    • bcrypt가 비밀번호 보안의 중요한 혁신이 될거라고 생각하지 못했지만 빈번한 데이터 유출 사고로 비밀번호 해싱 알고리즘의 단점이 드러나고 컴퓨팅 계산 능력의 발전에 저항할 수 있게 설계된 bcrypt의 동기를 강조하게 됨
    • David Mazières는 적응형 해싱을 도입해서 컴퓨팅 성능이 발전함에도 발맞춰 견고성을 유지할 수 있게 됨.
    • 새로운 알고리즘 개발도 촉진해서 PBKDF2, script로 확장대고 2013년에는 bcrypt의 대안으로 Argon2의 탄생으로 이어짐
    • 대규모 인터넷 서비스에서는 리소스를 최적화해야 하므로 과도한 메모리 요구 없이도 강력한 보안을 제공하는 bcrypt가 여전히 유리함.
    • 오늘날 클라우드의 도입으로 데이터는 원격에 더 많이 저장되며 무차별 대입 등의 공격보다는 취약점을 악용하거나 내부자를 감염시켜서 데이터를 유출하는 일이 더 많아짐.
    • 이제 보안은 기술적인 문제가 아니라 인적 요소와 기존 보안 기술을 채택하는 데 드는 비용의 문제가 되었다.

인프라 관련

  • 2023-03-08 Incident: Infrastructure connectivity issue affecting multiple regions : 지난 3월에 Datadog에서 발생했던 대규모 장애에 대한 포스트모텀이 올라왔다.(영어)

    • 장애는 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가 라우팅 테이블을 변경하지 않도록 수정했다.
  • 2023-03-08 Incident: A Deep Dive into the Platform-level Impact : 위 Datadog 장애의 플랫폼 레벨 영향을 더 깊게 살펴보는 포스트모텀이다.(영어)

    • 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 파일의 피싱 주소를 만들 수 있다.(영어)

    • https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1.27.1.zip
    • https://github.com/kubernetes/kubernetes/archive/refs/tags/v1.27.1.zip

IT 업계 뉴스

  • 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이 충분히 좋아졌다고 판단하고 이를 사용해서 픽업을 더 쉽게 하고 라이딩 등의 경험을 개선할 수 있도록 적용하고 있다고 한다.(영어)

프로젝트

  • ChartGPT : 프롬프트를 입력하면 차트를 그려준다.
  • Chat UI : Hugging Face에서 SvelteKit으로 만든 HuggingChat의 인터페이스를 오픈소스로 공개했다.

버전 업데이트

2023/06/01 23:08 2023/06/01 23:08
Response : No Trackback , No Comment

Comments

« Previous : 1 : 2 : 3 : 4 : 5 : ... 1653 :