Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.
RetroTech 팟캐스트 44BITS 팟캐스트

기술 뉴스 #236 : 23-12-16

웹개발 관련

  • Maglev - V8’s Fastest Optimizing JIT : 2021년까지 V8의 실행 계층은 인터프리터인 Ignition과 최적화 컴파일러인 TurboFan이 있어서 모든 JavaScript 코드를 Ignition 바이트 코드로 먼저 컴파일한 후 실행한다. 실행하면서 동작 방식을 추적해서 메타데이터와 바이트 코드를 최적화 컴파일러에 제공해서 인터프리터보다 훨씬 빠르게 실행되는 고성능 머신 코드를 생성한다. Ignition과 TurboFan 간의 속도 차이가 크기 때문에 2021년 Sparkplug라는 JIT를 도입해서 성능을 개선했지만, 한계가 있었기에 훨씬 빠른 코드를 생성할 수 있도록 최적화 JIT Maglev를 도입했다. Maglev는 Sparkplug와 TurboFan 사이의 간극을 메우기 위해 도입되었다.(영어)
  • Introducing StyleX : Meta에서 표현력, 결정성, 안정성, 확장성을 갖춘 스타일링 시스템인 StyleX를 오픈소스로 공개했다. StyleX는 CSS-in-JS의 개발자 경험을 컴파일 도구를 사용해서 CSS 성능과 확장성을 지원할 수 있도록 설계되었다. 그래서 표현형 CSS 하위집합을 지원하며 유틸리티 클래스나 라이브러리를 학습할 필요 없이 스타일을 원자적 CSS 클래스 명으로 변환해서 최적화하며 파일/컴포넌트를 넘어서 스타일을 합칠 수 있고 타입을 지원해서 프로퍼티와 값을 세밀하게 제어할 수 있다. StyleX는 컴파일 타임과 런타임 모두에서 빠르게 설계되었다. 이 StyleX는 Facebook.com을 React로 다시 구축할 때 스타일에 더 나은 무언가가 필요하다는 것을 깨닫고 만들기 시작했고 Meta에서 Facebook, WatsApp, Instagram, Threads 등에서 수년간 사용하면서 발전시켜 오다가 이제 오픈소스로 공개한 것이다.(영어)
  • PandaCSS와 함께 CSS-in-JS의 미래로 : 기존에 styled component를 사용하고 있었지만, PandaCSS로 바꾸게 된 배경을 설명한다. styled component를 잘 사용하고 있었지만 사용하지 않는 스타일이 번들에 포함되고 동적 기능으로 인한 성능 저하 문제가 있었고 디자인 시스템을 직접 만들기는 어려웠다고 한다. PandaCSS는 디자이너와 공유하는 토큰을 쉽게 정의할 수 있고 컴포넌트 레시피로 재사용이 쉽고 정적인 CSS를 지원해서 프레임워크를 타지 않는 장점이 있다. 한편 빌드타임에 코드를 생성하므로 토큰/레시피를 수정하면 다시 생성해 주어야 하고 다양한 방법을 지원하므로 팀에서 사용하려면 표준을 정하는 것이 좋다고 한다.(한국어)
  • v0 is now open for everyone. : Vercel이 만든 프롬프트를 입력해서 UI 컴포넌트를 생성해 주는 서비스인 v0이 이제 모두가 사용할 수 있도록 열렸다.(영어)
  • Introducing Learn Performance : web.dev에서 웹 성능에 관심이 있는 사용자를 대상으로 따른 웹페이지를 만든다는 것의 기술적 세부 사항을 설명하는 학습 코스인 Learn Performance의 초기 버전을 공개했다.(영어)

그 밖의 개발 관련

  • Merge vs. Rebase vs. Squash : HashiCorp의 Mitchell Hashimoto가 Git에서 Merge, Rebase, Squash에 관한 질문을 많이 받아서 자기 생각을 정리한 글이다. 셋 중의 하나가 정답이라고 말하는 건 틀렸다고 생각하고 각 전략이 필요한 상황이 있다고 생각한다. Merge와 Merge 커밋이 히스토리를 가장 잘 표현한다고 생각하기에 Merge를 선호하며 모든 커밋이 빌드할 수 있으면서 커밋이 많을수록 bisect가 좋아지기에 하나의 커밋에 변경이 많은 것은 싫어하고 한 커밋은 +50/-50 정도가 가장 좋다고 생각한다. 하지만 이렇게 하려면 모두가 이 규칙을 잘 따라야 하는데 보통 쉽지 않기에 OSS에서 PR에 WIP 커밋이 많지만 대부분 작은 차이이고 PR이 하나의 목표만 있다면 Squash를 사용하는데 이때도 Git/GitHub의 기본 스쿼시 메시지가 아니라 다시 작성하는 편이다. 변경 사항이 많은 WIP가 많은 경우 rebase를 통해 적당히 스쿼시하고 순서도 조정해서 관리한다. 그리고 50개 이상의 커밋을 대규모로 인터랙티브 리베이스를 할 때 GUI가 편하다는 걸 깨달아서 Tower를 사용하고 있다.(영어)
  • Java의 미래, Virtual Thread : 우아한형제들에서 Virtual Thread(Project Loom)이 JDK 19부터 얼리 엑세스로 포함되고 JDK21에서 정식 기능이 되면서 스터디한 결과를 공유했다. 스레드를 사용할 때 더 많은 요청을 처리하면서 컨텍스트 스위칭 비용을 줄이기 위해 훨씬 가벼운 Virtual Thread의 구조와 동작 원리를 보여주고 다른 델인 Thread, Kotlin Coroutine, Reative와 비교해서 성능이 얼마나 차이 나는지도 보여준다.(한국어)
  • Something's been bothering me about TDD : TDD만으로 좋은 시스템 설계를 할 수 있다고 생각하지 않는다는 글에 TDD를 만든 Kent Beck이 직접 "TDD는 디자인 필요성을 대체하지 않는다"고 설명하며 TDD가 제공하는 이점은 인터페이스 디자인에 대한 즉각적인 피드백과 인터페이스 디자인 결정과 구현 디자인 결정의 분리라고 댓글을 달았다.(영어)
  • SQLite JSONB has landed : SQlite에 JSONB가 도입되었다.(영어)

인프라 관련

  • Upgrading GitHub.com to MySQL 8.0 : GitHub.com이 성장하면서 단일 MySQL에서 아키텍처를 발전해 오고 있었는데 1,200개 이상의 MySQL 호스트를 8.0으로 업그레이드한 과정이다.(영어)

    • SLO에 영향을 주지 않으면서 업그레이드하기 위해 계획, 테스트, 업그레이드에 1년이 넘게 걸렸다.
    • MySQL 5.7의 수명이 거의 종료됨에 따라 8.0 으로 업그레이드 해야 했다.
    • GitHub의 MySQL 인프라 구성

      • 1,200개 이상의 호스트로 구성되어 있고 Azure와 베어 메탈 호스트의 조합
      • 300TB 이상의 데이터를 저장하고 50개 이상의 데이터베이스 클러스터에서 초당 5,500만 건의 쿼리를 처리
      • 각 클러스터는 primary와 replicas를 이용한 고가용성 구성
      • 수평/수직 샤딩을 모두 활용하여 데이터가 파티셔닝 되어 있음
      • 대규모 도메인 영역을 위해 수평 샤딩 된 Vitess 클러스터도 있음
    • SLO/SLA를 준수하면서 업그레이드해야 하지만 모든 장애를 미리 고려할 수는 없으므로 중단없이 MySQL 5.7로 롤백할 수 있어야 한다. 다양한 워크로드가 있으므로 클러스터를 원자단위로 업그레이드하고 해야하고 혼합 버전을 오랫동안 운영해야 했다.
    • 2022년 7월부터 업그레이드 준비를 시작했다.
    • MySQL 8.0의 설정값을 결정하기 위해 벤치마크했고 두 버전을 운영해야 했기에 도구와 자동화가 두 버전을 모두 처리할 수 있어야 했다.
    • 모든 애플리케이션의 CI에 MySQL 8.0을 추가해서 CI에서 5.7과 8.0을 같이 실행했다.
    • 업그레이드 전략

      • replicas를 먼저 업그레이드하고 트래픽을 받도록 한 뒤 모니터링하면서 교체해 나가고 5.7은 롤백을 위해 띄워두었지만, 트래픽은 안 가게 함
      • Replica 토폴로지를 조정해서 8.0 primary가 5.7 primary를 복제하도록 구성하고 8.0 replicas 아래에는 5.7 세트와 8.0 세트로 구성해서 8.0만 트래픽을 처리하도록 함
      • Primary를 직접 업그레이드하지 않고 페일오버를 통해 MySQL 8.0 Replica가 Primary로 승격되도록 함
      • 백업이나 비 프로덕션을 위한 MySQL로 모두 업그레이드.
      • 롤백할 필요가 없다는 걸 확인 후 5.7 서버를 모두 제거
  • Why We Created the Argo Project : Argo 프로젝트를 Jesse Suen, Alexander Matyushentsev와 시작했던 Hong Wang이 처음에 왜 Argo 프로젝트를 시작했는지를 정리했다.(영어)

    • 셋은 Applatix라는 스타트업에서 만났는데 2016년 Applatix에서 DevOps 솔루션을 구축해서 컨테이너와 퍼블릭 클라우드를 통해 Jenkins보다 나음 경험을 제공하고자 했다.
    • Kubernetes를 알게 되고 Kuberntes 네이티브로 만들어야 한다는 것을 깨닫고는 Argo Workflows를 시작하게 되었다.
    • 2017년에는 Kubernetes에 CRD가 나오면서 이 CRD를 사용하기로 결정하고 Argo Workflows 2.0을 재작성하게 된다.
    • Intuit가 Kubernetes로 이전하는 작업을 원활하게 수행할 팀을 찾다가 Applatix를 인수하기로 결정했고 Argo Workflows 팀은 하루 빨리 대규모로 테스트하고 싶어졌다.
    • 하지만 바로 Intuit에 Kubernetes 클러스터와 네임스페이스가 너무 많았지만 이를 관리할 도구는 없다는 걸 깨달았다.
    • 처음부터 멀티 클러스터 지원이 필요했고 더 쉽게 오케스트레이션 하려면 단일 컨트롤 플레인이 필요했기에 Argo CD를 만들게 되었고 플랫폼 팀과 애플리케이션 팀이 협업해서 역량을 강화하기 위해 GUI 중심으로 만들기로 결정하게 된다.
    • Intuit에서 점점 Kubernetes로 운영하면서 장애의 50%정도가 배포때 발생하고 복구하는게 걸리는 시간(MTTR)을 단축하는데 실패했다는 걸 깨닫게 된다.
    • 이 문제 해결을 위해 블루/그린과 카나리 배포 전략을 소개하게 하고 Argo Rollouts를 만들게 되었다.
  • A deep dive into CPU requests and limits in Kubernetes : Kubernetes에서 CPU 스케쥴링은 기본적으로 CFS(Completely Fair Scheduler)에 의해서 이루어지고 1.10에서 Beta로 도입되고 1.26에서 Stable이 된 CPU Manager에서 기본 정책인 none을 사용하면 CFS가 CPU를 스케쥴링한다. CPU Manager의 정책을 static으로 설정하면 Linux CPUSets를 사용하게 된다. 이때 Guaranteed QoS 클래스에 할당된 Pod은 요청한 CPU 코어에 독점적인 엑세스를 얻게 되고 해당 코어는 공유 풀에서 제거된다. 이 독점적 코어 사용은 다른 Pod에만 적용되고 시스템 데몬에는 적용되지 않으므로 시스템 데몬에도 따로 CPU를 할당해야 한다. 그래서 static 정책은 컨텍스트 전환에 민감한 워크로드에 유용하지만 다른 컨테이너에 영향을 줄 수 있다.(영어)
  • Atlantis Hardening and Review Fatigue : DoorDash에서 Terraform 코드를 관리하기 위해서 Atlantis를 사용해서 자동화한 과정이다. Atlantis에서 Pull Request 승인을 받지 않으면 terraform apply를 할 수 없는데 실제로는 악의적 코드를 가져올 수도 있고 승인 요건을 우회할 수도 있고 Atlantis 설정으로 허용한 프로바이더를 지정해서 관리할 수 있다. 그리고 리뷰 피로감을 줄이기 위해 Conftest와 OPA를 사용해서 일부 변경 사항은 승인 없이 할 수 있도록 하고 사람이 봐야 하는 변경만 승인이 필요하게 할 수 있다.(영어)
  • Kubernetes V1.27 : Safeguarding Pod with MemoryThrottlingFactor : Kubernetes 1.27에 도입된 메모리 스로틀링 기능을 설명한다. 메모리 request와 limit으로 메모리를 제한하고 관리할 수 있지만 1.27은 request와 limit 간의 차이를 기본 스로틀링 계수(기본값은 0.9)로 계산해서 memory.high를 설정한다. memory.high에 가까워지면 메모리 스로틀링이 동작해서 메모리를 관리한다. 정확히 스로틀링이 동작하는 방식도 궁금한데 그 부분까지는 이글에는 나와 있지 않다.(영어)
  • Set and scale service level objectives in Grafana Cloud: Introducing Grafana SLO : Grafana Labs 내부에서 SLA에 맞게 알림을 설정했지만, 너무 많은 오경보가 생겼고 이를 개선한 과정을 통해 Grafana SLO를 Grafana Cloud에 출시했다.(오픈소스 제품은 아님) SLO를 통해 UI에서 SLI를 설정하고 관리할 수 있다.(영어)
  • Open source forkers stick an OpenBao in the oven : OpenTofu 운영자 중 한 명이면서 DevOps 관련 스타트업인 Scalr의 공동창업자이자 CEO인 Sebastian Stadil가 HashiCorp Vault의 포크인 OpenBao 프로젝트를 공개했다. Terraform의 라이센스 변경으로 OpenTofu가 생겼듯이 Vault도 같은 이유로 포크해서 OpenBao를 만든 것이다. OpenBao는 Linux 재단의 인큐베이팅을 받고 있고 IBM 개발자들이 엣지 컴퓨팅 이니셔티브인 LF Edge를 통해 프로젝트를 주도하고 있으면 아직 IBM에 공식 승인이 있었던 것은 아니다.(영어)

볼만한 링크

  • Why We’re Dropping Basecamp : Duke 대학이 10년 동안 프로젝트 관리 플랫폼인 Basecamp를 사용해 왔지만, 현재 사용 수준과 Basecamp의 모회사인 37signals 경영진의 폐해로 인해 올해 12월 종료 후 구독을 갱신하지 않을 거라고 밝혔다. Basecamp는 2여 년 전 고객의 이름으로 인종차별 했던 게 알려지면서 쟁점이 되었지만 37signals는 내부 토론을 차단했는데 Duke 대학에서도 당시에 논의했지만 계속 Basecamp를 사용하기로 했다. 올여름 내부에서 37signals의 CTO인 DHH가 대학 입학 시 인종에 대해 고려하지 않는 대법원판결을 축하는 글Meta에선 정치를 하지 않는다는 글을 통해 다시 Basecamp 사용에 대한 검토를 다시 하게 되었다고 한다. DHH는 다양성, 형평성, 포용성(Diversity, Equity, and Inclusion, DEI)를 확고히 자리 잡은 운동이라고 하며 이후 시위를 폭동이라고 하며 사실을 왜곡하고 있고 그가 원하는 글을 쓸 수 있지만 Duke 대학도 Duke 대학의 의견이 있고 선택할 수 있다고 얘기한다. Duke 대학은 도서관이기 때문에 인류가 만들 수 있는 최악이 무엇인지 알고 있고 직장 관행이나 문화가 초래한 해약도 알고 있으며 이는 본받아야 할 모델이 아니라고 얘기한다.(영어)
  • Introducing Gemini: our largest and most capable AI model : Google DeepMind에서 새 대규모 언어 모델인 Gemini를 발표했다. 이 모델은 가장 성능이 뛰어난 Gemini Ultra, 다양한 업무에서 확장할 수 있는 Gemini Pro, 온디바이스 작업에 효율적인 Gemini Nano로 나뉘어져 있다.(영어)
  • Audiobox: Generating audio from voice and natural language prompts : 원하는 음성이나 음향 효과에 대한 프롬프트를 입력해서 소리를 생성할 수 있는 모델인 Audiobox를 Meta에서 공개했다.(영어)
  • 트위치 한국 서비스 철수에 담긴 경고: 콘텐츠 다양성 훼손과 인터넷의 파편화, 발신자종량제 상호접속고시 폐지로 망중립성 복원해야 : Twitch가 전 세계와 비교해 10배가 넘는 '망 사용료'를 이유로 한국에서 사업 철수함에 따라 망 중립성 훼손에 관해서 오픈넷이 낸 보도자료이다. 국내에서 엄청난 인터넷 접속료를 감당할 수 있는 대형 플랫폼만 살아남을 수 있게 되어 콘텐츠 다양성이 훼손될 것이고 과거 논의할 기회가 있었지만, 해외 플랫폼과 비교해 역차별론으로 흘러가면서 제대로 논의할 기회를 얻지 못했다.(한국어)
  • 신입 프론트엔드 개발자가 공유하는 소소한 취준팁 : 비전공자로 2년 정도 교육과 프로젝트, 해커톤, 인턴쉽 등의 경험을 쌓은 뒤에 본격적인 취업 준비를 하면서 300회가 넘게 지원하면서 취업까지 성공한 뒤 그동안 경험을 정리한 글이다. 이력서는 주변 사람들에게 피드백 받고 읽는 사람 입장에서 고민해서 작성하고 과제 할 때는 해당 부분을 질문했을 때 어떻게 대답할지를 고민하면서 작성했다고 한다. 면접은 많이 볼수록 경험이 쌓이니까 가능한 한 많이 지원해 보라고 하고 있고 면접 장소에 좀 일찍 가서 컨디션이랑 복장 관리를 한 뒤에 면접하라는 팁도 제공하고 있다. 오랫동안 맘고생도 심했겠지만, 고민을 많이 하면서 준비했다는 게 느껴지는 글이다.(한국어)
  • CIA가 CTO를 신설한 이유는 : 미국 바이든 정부의 CIA 국장인 윌리엄 번스는 사상 처음으로 CTO 직책을 신설하고 낸드 물찬다니(Nand Mulchandani)를 CTO로 임명했다. 낸드 물찬다니는 실리콘 밸리에서 네 개의 기업을 창업하고 매각한 연쇄 창업가로 국방부의 인공지능센터에 부임한 뒤 CIA의 CTO까지 오르게 되었다. 백악관의 CTO는 오바마 정부에서 처음 신설하고 트럼프 정부에서 꽃을 피웠는데 이번에 CTO를 뽑은 CIA 국장은 이제 기술 자체가 경쟁과 분쟁의 영역이 되고 있어서 국가 안보에 영향을 미치게 되었다고 얘기했다.(한국어)

IT 업계 뉴스

프로젝트

  • Ghostty : Mitchell Hashimotor가 만드는 터미널 에뮬레이터.
  • Cody : Sourcegraph에서 만든 AI 코딩 어시스턴트로 VS Code, JetBrains, Neovim을 지원한다. 2024년 2월까지는 무료로 사용할 수 있다.
  • GitHub Unwrapped : React로 비디오를 만드는 Remotion 프로젝트에서 2023년 GitHub의 활동으로 비디오를 만들어 주는 사이트를 공개했다.
  • MRR Counter with linear() : CSS linear() easing 함수로 숫자가 돌아가면서 표시되는 애니메이션을 보여주는 예제 코드
  • markdown-it-github-alerts : GitHubdl 마크다운 blockquote에서 Note, Tip, Caution 등을 표시해 주는 기능을 구현한 markdown-it 플러그인
  • System Design 101 : "가상 면접 사례로 배우는 대규모 시스템 설계 기초" 1, 2권의 저자인 Alex Xu가 복잡한 시스템을 시작 자료를 이용해서 쉽게 설명하는 저장소를 공개했다.
  • Vault Benchmark : Vault가 어느 정도의 트래픽을 안정적으로 받아주는지 테스트할 수 있는 벤치마크 도구로 HashiCorp가 만들었다.

버전 업데이트

2023/12/16 21:59 2023/12/16 21:59