Optimize Time to First Byte : 브라우저에 첫 바이트가 도착하는 시간인 TTFB(Time to First Byte)의 최적화 방법을 설명하는 글이다. TTFB는 서비스의 특징마다 다르기 때문에 Core Web Vitals에는 안 들어가 있지만 다른 매트릭에 영향을 주는 기본 매트릭이므로 적은 게 좋고 대략 75 퍼센타일인 800ms를 좋은 TTFB로 얘기하고 있다. TTFB는 lab 데이터보다는 실제 사용자의 데이터인 필드 데이터를 반드시 같이 봐야 하고 TTFB를 최적하 하기 위해 Server-Timing 응답 헤더로 서버에서 걸린 시간에 대한 자세한 정보를 제공할 수 있다. 결국 서버 로직의 최적화가 필요하지만, CDN을 사용하거나 마크업을 스트리밍으로 보내서 개선할 수 있고 서비스 워커가 설정에 따라 지연시간을 높일 수도 있다. 또는 서버에서 마크업을 준비하는 동안 103 Early Hints 헤더를 제공해서 필수 리소스를 브라우저가 미리 다운로드 받게 할 수도 있다.(영어)
똑똑하게 브라우저 Polyfill 관리하기 : 폴리필은 브라우저 간 API의 지원 차이를 해결하기 위한 스크립트인데 보통은 @babel/preset-env를 이용해서 타켓 브라우저에 맞는 폴리필을 생성할 수 있다. 하지만 이 경우 전체 스크립트가 커지므로 최신 브라우저에서도 불필요한 코드를 받게 되는데 Polyfill.io를 이용하면 User-agent를 보고 동적으로 폴리필을 내려줄 수 있다. Toss에서는 core-js와 browserslist를 이용해서 User-agent로 폴리필을 만드는 스크립트를 작성해서 서버에 넣거나 엣지 함수에 배포해서 운영한다고 한다.(한국어)
Concurrent React가 가져온 변화: 급하지 않은 렌더링 구분하기 : React 18에 도입된 Concurrent 렌더러를 설명한다. Concurrent 렌더러의 도입으로 이제는 렌더링을 중단할 수 있게 되어서 급한 렌더링과 급하지 않은 렌더링을 구분해서 처리할 수 있게 되었다. 급하지 않은 렌더링을 위해 변화하는 상태에 useDeferredValue와 useTransition를 사용해서 별도로 렌더링을 처리하고 중단될 수 있게 구성하는 방법을 설명한다.(한국어)
CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기 : 데브시스터즈에서 2021년 쿠키런: 킹덤이 36시간 장애가 났을 때 복구작업을 한 이야기다. CockroachDB를 쓰고 있고 충분히 준비했었지만 예상 이상으로 사용자가 늘어나면서 데이터베이스 스토리지가 차기 시작하자 확장 작업을 하던 중 설정 실수로 데이터베이스 노드의 절반 이상이 다운되었다고 한다. CockroachDB는 Raft를 사용하는데 설정 실수로 인해서 일관성을 지키지 못하게 되고 서비스 장애가 발생했다고 한다. CockroachDB의 서포트도 받았지만, Cockroach DB측에서는 복구할수 없으니 스냅샷으로 복원을 하라는 권고를 받게 되었지만 최신 데이터를 그대로 복구해야 한다고 생각하고 복구 할 수 있을거라는 생각에 CockroachDB의 저장 구조를 파보기 시작해서 저장된 파일의 파싱방법을 알아내고 여기서 데이터를 복구할 수 있다고 판단 후 CSV로 변환해서 정합성을 맞추는 작업을 반복하면서 AWS의 인스턴스를 대부분 끌어다 작업한 후에 복구를 했다고 한다.(한국어)
CockroachDB in Production : 데브시스터즈가 쿠키런 킹덤에서 데이터베이스로 CockroachDB롤 사용한 경험을 정리한 글이다. Google Spanner에서 영감을 받아 오픈소스로 만든 CockroachDB는 PostgreSQL과 호환되고 SERIALIZABLE 트랜잭션, 수형 확장성, 멀티 리전 클러스터를 지원한다. 쿠키런 킹덤 오픈 전 CockroachDB, Aurora, DynamoDB를 비교했지만, 성능이 좋으면서 확장 가능성이 높고 비용도 싸다고 판단해서 CockroachDB를 선택했다고 합니다. 관계형 데이터베이스처럼 보이지만 Key-Value 스토어이며 Range로 나누어서 Raft 알고리즘을 통해 Leaseholder, Raft Leader를 선출해서 사용하고 있다. 프로덕션에서 운영 시 주의할 점도 정리되어 있는데 국내에서 이런 규모의 CockroachDB 경험이 흔치는 않아서 참고하기 좋다.(한국어)
Ruby 3.2’s YJIT is Production-Ready : 글을 쓴 Maxime Chevalier-Boisvert가 2020년 Shopify의 Ruby & Rails Infrastucture팀에 합류하면서 매니저에게 Ruby Just-In-Time(JIT) 컴파일러를 만들 수 있다고 제안하고 매니저와 두 동료가 같이 참여하면서 CRuby의 YJIT 프로젝트가 시작되었다고 한다. 고된 작업이었지만 railsbench에서 20%의 성능을 향상키시게 되고 CRuby 코어 팀에서 초대받으면서2021년 말 Ruby 3.1의 일부로 포함되고 YJIT팀이 커지면서 Ruby 3.2에 포함되었는데 성능도 좋아졌고 프로덕션에서 사용할 수준이 되었다고 한다. 2021년에 YJIT을 C99에서 Rust로 포팅하기로 경장하고 유지보수도 쉬워졌고 이후 메모리 개선 작업으로 프로덕션에서도 쓸 수 있게 되었다고 한다.(영어)
Git security vulnerabilities announced : Git 2.39 이하 버전에서 CVE-2022-41903, CVE-2022-23521 취약점이 발견되었다. 이 두 취약점은 커밋 포매팅 메커니즘과 .gitattributes 파서에 영향을 주어 힙 쓰기와 임의의 읽기에 영향을 주어 코드 실행을 할 수 있게 하므로 즉시 업그레이드를 권고하고 있다. Git 2.39.1 이상으로 업그레이드해야 하고 업그레이드하기 어렵다면 해당 글에 나온 방법으로 위험을 줄일 수 있다.(영어)
Kubernetes resources under the hood - Part 1, Part 2, Part 3 : Kubernetes에서 리소스를 어떻게 사용하지는 설명하는 글로 주로 CPU의 request와 limit의 동작 방식을 설명하고 있다. CFS로 CPU를 스케줄링하는데 request를 설정했을 때 CFS에서 cpu share의 비율을 어떻게 계산하는지, request 설정이 스케줄 링 외에 CPU 확보에 어떤 의미가 있는지를 설명하고 스로틀링을 거는 limit 관점에서는 cpu period와 quota를 기준으로 어떤 식으로 스로틀링이 동작하는지 설명한다. 결론은 성능을 걸기 원한다면 limit을 걸지 않기를 권하고 있는데 최근에 궁금하던 부분이 이글을 통해 많이 해소되었다.(영어)
I Migrated from a Postgres Cluster to Distributed SQLite with LiteFS : Kent C. Dodds가 자신의 사이트를 PostgreSQL을 이용해서 fly.io를 이용하고 있었는데 fly.io의 Litestream와 LiteFS를 알게 되어 SQLite로 갈아타게 되었다고 한다. 이전에는 멀티리전 데이터베이스를 위해 primary 리전에 직접 write를 하고 있었는데 SQLite는 로컬에 떠 있으므로 이 방법을 쓸 수 없었고 fly.io에서 지원하는 fly-replay 응답 헤더를 통해 primary 리전에서 처리되도록 하는 방법을 사용했다. 단일 리전에서 동작하도록 마이그레이션 준비가 끝난 뒤에 LiteFS를 설정해서 fly-replay 응답 헤더를 통해 멀티 리전 처리를 할 수 있게 되었고 이 부분 외에는 멀티리전을 위한 코드의 영향은 없었다고 한다.(영어)
Docker Compose: What’s New, What’s Changing, What’s Next : Docker Compose v2가 2022년 4월에 GA가 된 후 1년이 지나 올 6월에 v1은 지원이 종료될 예정이다. 이제 docker-compose 대신 docker compose 명령어를 사용해서 v2로 전환할 수 있고 Docker Desktop의 설정에서 Compose V2를 활성화하면 docker-compose 별칭이 만들어져서 기존과 동일하게 v2를 사용할 수 있게 된다.(영어)
Sunsetting Subversion support : GitHub가 2010년부터 지원했던 버전관리 시스템 Subversion의 지원을 중단한다고 한다. 지금은 Git을 대부분 쓰지만, 그 이전에는 Subversion이 대세였으므로 GitHub에서도 Subversion을 지원했다. 지금은 개발자의 94%가 Git을 사용하고 GitHub에서 0.02%의 트래픽만 차지하고 있다고 한다. 지금부터 1년 뒤인 2024년 1월 8일부터 Subversion의 지원을 중단한다고 한다.(영어)
볼만한 링크
Bitwarden design flaw: Server side iterations : 최근 LastPass의 데이터 유출로 인해 사용자들이 다른 서비스로 옮겨가고 있는데 대표적으로 대안이 1Password와 Bitwarden이다. 하지만 Bitwarden도 LastPass와 보안 수준이 동일하다고 설명하고 있다. Bitwarden은 PBKDF2를 쓰고 20만 번 이터레이션을 돌린다고 설명(클라이언트에서 10만 번, 서버에서 10만 번)하는데 LastPass보다 2배이긴 하지만 설계결함으로 서버 측 10만 번은 암호화키가 아닌 마스터 암호 해시에만 적용되어 있어서 실제로는 LastPass와 동일한 보안 수준인 것과 마찬가지다. OWASP는 최근 권장 이터레이션을 60만 회로 변경했고 Bitwarden은 클라이언트 측 이터레이션을 35만 번으로 바꾸었지만, 이는 새 계정에만 적용된다고 한다.(영어)
Secret Key: What is it, and how does it protect you? : LastPass 사건과 관련해서 위의 Bitwarden 글을 보다가 1Password의 시크릿 키의 구조를 설명한 글을 보게 되었다. 결국 1Password든 다른 서비스든 암호화되어 저장된 데이터베이스(금고)가 유출되었을 때도(절대 유출이 없다고 할 수 없으니) 안전해야 하는데 1Password는 시크릿 키를 통해 단순히 공격을 비싸게 만드는 것이 아니라 불가능하게 만들었다고 하고 있다. 사용자의 계정 암호가 서버에 절대 전달되지 않도록 하기 위해 PAKE(password authenticated key exchange)를 사용하는데 여전히 패스워드 해시나 마찬가지인 SRP verifier가 저장된다. secret key를 사용자의 비밀번호와 합쳐져서 이 verifier 공격이 의미 없게 만들었다고 한다.(영어)
롯데헬스케어의 아이디어 탈취를 고발합니다 : 영양제 디스펜서를 만드는 알고케어란 스타트업에 롯데헬스케어에서 투자 명목으로 미팅하면서 직접 제품을 개발할 생각은 없다면 IR 발표에서 제품의 구체적인 내용을 들었지만 이후 라이센스피를 주고 직접 생산하겠다고 하다 협의가 무산된 이후 카피캣을 만들어서 CES에서 제품을 내놓았다. 이에 알고케어는 그동안의 히스토리를 정리하고 각 회의록과 녹음 파일을 공개하면서 롯데헬스케어를 고발하는 글을 올리고 법적 조치를 취하기로 했다.(한국어)
Netflix founder Reed Hastings steps down as co-CEO : Netflix의 창업자인 Reed Hastings가 CEO에서 물러난다고 발표했다. 2020년 Hastings와 공동 CEO로 Ted Sarandos를 지명했는데 이번에 COO인 Greg Peters를 CEO로 공동 CEO 체제로 운영하고 Hastings는 이사회 회장으로 참여할 것이라고 한다.(영어)
Mailchimp says it was hacked — again : 이메일 마케팅 서비스인 Mailchimp의 직원이 사회 공학 공격을 당해 공격자가 메일 침프 내부 도구에 접근해서 133개의 계정 데이터를 탈취했다고 한다. 지난 8월에도 비슷한 공격을 받고 보안 조치를 강화했다고 했지만 어떤 조치인지는 알려지지 않았다.(영어)
OpenAI and Microsoft Extend Partnership : OpenAI와 Microsoft가 파트너쉽을 확장한다고 발표했다. OpenAI는 이익 제한 회사로 계속 남아있고 Microsoft와의 파트너쉽으로 OpenAI의 신념을 버리지 않고 필요한 자본을 투자받을 수 있게 되었다.(영어)
Comments