React 파이버 아키텍처 분석 : React 16에서 도입되고 계속 개선되고 있는 React의 코어 아키텍처인 파이버를 살펴보는 글이다. 사전 지식을 위해 React가 DOM을 어떻게 업데이트하는지를 설명한다. 파이버가 DOM을 업데이트할 때 Render, Reconcile, Commit, Update 단계 중 Reconcile의 파이버 코드를 따라가면서 어떻게 업데이트하는지 자세히 설명한다.(한국어)
Speeding up the dbt™ docs by 20x with React Server Components : dbt(data build tool)에서 생성하는 문서가 Angular 1로 만들어져 있고 너무 느렸기 때문에 이를 개선하기로 했다. 짧은 시간에 포팅해서 정적 웹사이트로 컴파일해야 했기 때문에 클라이언트 렌더링 대신 정적 HTML 페이지로 만들기하고 Next.js와 React Server Component로 포팅하기로 했다. angular를 React로 포팅은 금방 할 수 있었지만, 너무 큰 JSON을 import()에 사용하는 실수를 했지만 금방 해결했고 검색과 파일 트리는 해당 데이터만 내려주는 엔드포인트를 만들어서 해결했다. 정적 파일로 만들어서 .html 확장자가 없어서 생기는 문제는 trailingSlash로 해결하면서 관련된 성능 문제도 같이 해결했다. 포팅 후 속도가 10배 이상 빨라졌다고 한다.(영어)
그 밖의 개발 관련
jqlang/jq : 커맨드라인에서 JSON 데이터를 쉽게 처리해 주는 jq가 5년의 공백을 빼고 jqlang 조직으로 다시 돌아왔다. Stephen Dolan와 다른 메인테이너들도 너무 바빠서 jq 프로젝트를 관리할 수 없어서 새로운 메인테이너를 모집해서 개발을 이어받아서 시작하고 1.7rc1을 내놓았다.(영어)
Fixit 2: Meta’s next-generation auto-fixing linter : Meta에서 새로운 Python linter인 Fixit 2를 공개했다. Python에는 Flake8이 있고 Meta에서도 많이 사용해 왔고 기여도 했지만, 어려운 부분이 있었는데 새로운 린트 규칙을 추가하려면 전체를 다시 빌드해야 했고 변경 사항을 제공하지 않아서 고칠 때 어려움이 있었고 미래의 문법을 분석할 수 없어서 Python의 새로운 기능이 나와도 기다려야 했다. Flake8를 대체할 서비스도 있지만 대부분 자동 수정 기능이 없거나 모노레포 지원이 부족하거나 코드 베이스가 클 때 성능 문제가 있었다. Instagrm에서 만들었던 Fixit도 모노레포 지원이 부족했었는데 내부에서 고민한 끝에 Fixit을 새로 작성하기로 하고 Fixit 2를 만들었다. Fixit 2는 LibCST 기반으로 만들어졌고 TOML 형식으로 계층적 구성, 로컬 인-리퍼지토리 힌트 규칙 지원, 자동 수정을 지원할 수 있게 되었고 새로운 린트 규칙과 수정사항 제안도 몇 줄의 코드로 추가할 수 있게 되었다.(영어)
Building and operating a pretty big storage system called S3 : AWS S3의 VP인 Andy Warfield의 USENIX FAST 기조연설을 글로 정리한 글이다. 교수로 일하다가 S3 팀에서 일하게 되었는데 S3의 수많은 구성 요소를 각 팀이 담당하고 있어서 소프트웨어, 하드웨어, 사람으로 구성되어 있다고 할 수 있다. HDD는 비용 효율적이므로 S3에서도 많이 사용된다. 현시점에 가장 큰 HDD는 26TB인데 첫 HDD인 RDMAC이후 60억 배 저렴해 졌지만 기계식이므로 탐색시간은 150배 정도만 개선되었다. 이는 S3가 처음 출시되었을 때도 비슷한 읽기/쓰기 속도이므로 S3 설계의 핵심이 되며 이 I/O를 관리하는 것이 가장 중요하고 이를 Managing heat라고 부른다. heat는 특정 시점에 특정 디스크의 도달하는 요청 수를 말하는데 이를 잘못 관리하면 특정 디스크에 핫스팟이 발생하므로 이를 균등하게 분산하고 복제는 이 부분에서도 도움을 준다. 특히 S3에 합류한 이후 소프트웨어로만 생각하는 것으로 충분치 않고 S3라는 시스템은 이를 운영하는 조직과 사용하는 고객의 코드도 포함된다는 것을 배웠다.(영어)
HashiCorp adopts Business Source License : HashiCorp가 앞으로 모든 제품을 기존의 MPL 2.0이 아닌 Business Source License(BSL, BUSL)로 릴리스하겠다고 발표했다. 여전히 오픈소스의 힘을 믿고 있지만 OSS 프로젝트를 상업적으로 사용하면서 기여를 하지 않는 업체도 있어서 바꾼다고 했다. BSL 1.1은 특정 조건에서 소스 사용이 가능하기 때문에 대부분의 사용자는 영향이 없고 HashiCorp의 OSS 제품으로 상업적 서비스를 제공하는 경우 HashiCorp와 계약이 필요하다. BSL은 Couchbase, Cockroach Labs, Sentry, MariaDB 등이 있습니다. Confluent, MongoDB, Elastic, Redis Labs도 같은 이유로 만들고 채택한 라이센스다.(영어)
How DoorDash Migrated from StatsD to Prometheus : DoorDash에서 옵저버빌리티 도구로 StatsD를 사용하고 있었지만, 트래픽이 폭증할 때 같이 장애가 나서 정작 필요할 때 사용할 수가 없었기 때문에 Prometheus 기반 모니터링으로 마이그레이션 하기로 했다. StatsD는 Etsy에서 개발한 네트워크 데몬인데 메트릭이 손실될 가능성이 있고 메트릭 이름의 표준화가 어렵고 히스토그램 기능이 없어서 백분위수 집계가 어려워서 메트릭의 가치를 전체적으로 떨어뜨렸다. 새로운 솔루션의 요구사항으로는 오픈 소스를 이용해서 관리 효율성을 높이고 표준 이름과 태그로 거버넌스를 높이고 마이그레이션을 원활하게 하려고 셀프서비스로 자동화할 수 있어야 한다는 것이다. 마이그레이션은 인프라팀이 먼저 모니터링을 새로운 시스템으로 마이그레이션하고 서비스팀에서 Prometheus 계측과 라이브러리로 엔드포인트를 변경하는 단계로 진행했다.(영어)
Maturing your Terraform workflow : HashiCorp에서 성숙한 Terraform 워크플로를 만드는 방법을 설명한다. 클라우드 플랫폼은 내버려 두면 사용하기 어려워질 수 있으므로 플랫폼 팀에서 이를 관리해야 한다. 보통 조직이 커지면 각 팀이 테라폼 모듈을 만들어서 모듈이 많아지는 문제와 이를 공통화하면서 너무 큰 모듈이 생성되는 패턴이 발생하는데 이는 쉬운 80%의 사용사례에 집중하는 파레토의 원칙을 적용해서 간결한 모듈을 유지할 수 있다. 이렇게 만들어진 모범 사례를 장려하고 자동화를 통해 배포 속도를 높일 수 있다고 한다.(영어)
Product and Platform Engineers : 엔지니어를 프론트엔드와 백엔드로 구분하는 것은 점점 의미가 없어지고 이제는 프로덕트 엔지니어와 플랫폼 엔지니어로 구분해야 한다고 얘기하는 글이다. 프로덕트 엔지니어는 고객의 문제를 해결하는 데 집중해서 고객의 피드백을 받고 반복하면서 제품을 개선하며 고객 중심으로 생각하며 기술 선택은 목적을 달성하기 위한 수단으로 생각한다. 플랫폼 엔지니어는 제품을 만드는 인프라에 집중해서 프로덕트 엔지니어를 지원한다.(영어)
Codecov is now open source : 최근에 Sentry에 인수된 코드 커버리지 플랫폼 Codecov가 핵심 코드를 Business Source License(BUSL)로 공개하고 상용 호스팅 서비스는 종료하고 Docker Compose 기반으로 직접 실행할 수 있는 self-hosted 저장소도 함께 공개했다. 공개된 소스에는 API, 워커, 프론트엔드가 포함되어 있다. BUSL은 OSI의 승인을 받은 오픈소스는 아니라서 실제로 오픈소스는 아니다. 이 라이센스는 호스팅을 판매하는 것을 금지하고 일정 기간이 지나면 코드가 Apache 2.0 라이센스가 된다.(영어)
Comments