[GN#77] 개발자가 시도해볼 만한 프로젝트 / M1과 RISC-V

2020-12-21 ~ 2020-12-27 사이의 주요 뉴스들
개발 스킬을 향상하려고 할 때 뭔가를 밑바닥부터 직접 개발해보는 방법을 많이 추천하는데요. 막상 시작하려고 하면 어떤 걸 만들어야 할지 아이디어가 잘 떠오르지 않습니다. 이럴 때 시도해볼 만한 프로젝트를 추천하고, 관련해서 참고할 만한 자료도 같이 정리한 글이 작년에 이어서 2번째로 공개가 되었습니다. 작년엔 텍스트 에디터, 스페이스 인베이더 게임, Tiny BASIC 컴파일러, Mini OS, 스프레드 시트, 게임 에뮬레이터 등을 추천했는데요. 올해는 Ray Tracer, 키밸류 저장소, 웹 브라우저, 주식 거래 봇 등을 제안합니다.

몇 주 전에 올라온 M1칩은 왜 그렇게 빠를까? 라는 글에서 여러 개의 전용 칩이 들어간 SoC 때문이라는 얘기를 했는데, 그 후속 글인 "M1은 RISC-V의 상승을 예고한다" 에서는 이 전용 칩(코 프로세서)을 만드는 최고의 플랫폼으로 RISC-V가 유망하다는 얘기를 풀어갑니다. 거대한 명령어세트를 가진 x86계열을 고정폭 명렁어세트의 ARM이 위협하는 가운데, 극도로 제한된 명령어 세트를 가진 RISC-V 는 그 간결함과 확장성으로 차세대 코프로세서에 어울린다는 주장인데요. 어떤 방식으로 미래의 칩 경쟁이 진행될지 아주 흥미진진합니다.

유명 서비스의 오픈소스 대체제는 항상 인기가 좋습니다. 비용이나 보안등의 이슈 때문에 직접 셀프호스팅해야할 상황이 종종 있기 때문인데요. Twitch와 비슷한 서비스를 직접 운영하게 해주는 Owncast, Pocket과 비슷한 LinkAce, Auth0/Firebase Auth와 비슷한 SuperTokens 같은 것들이 소개가 되었고요. 아예 디자이너/개발자/분석가 들이 사용하는 여러 도구의 오픈소스 대체제만 모은 Open Source Stash 서비스도 참고하시기 바랍니다.


✓ 사내에서 슬랙을 쓰신다면 뉴스채널에 GeekNews SlackBot 을 추가하여 편하게 새 글을 받아보시고, 멤버들에게도 공유해주세요.
✓ 주위분들께 긱뉴스 위클리 - https://news.hada.io/weekly 를 추천해 주세요.
Twitter , Facebook 에서도 긱뉴스를 받아 보실 수 있습니다.
✓ 긱뉴스를 팟캐스트로 들어보세요 : 애플, 유튜브, 팟티, 팟빵, 구글, 네이버 오디오클립
✓ GeekCast : 최신 데이터 인프라 이해하기 (시리즈) , 실패하지 않는 뉴욕타임즈 - NYT는 어떻게 디지털화에 성공했나 (48분)

매주 월요일 아침, 지난 일주일간의 GeekNews 중 엄선한 뉴스들을 이메일로 보내드립니다.


개발자가 시도해볼만한 좀 더 도전적인 프로젝트들

사이드 프로젝트로 시도해 볼만한 것들을 리스트업
만들어보기 위해 추가로 읽어야 할 링크 및 강좌들을 정리
- Ray Tracer
- Key-Value Store Web API
- Web browser
- Stock Trading Bot

1년 전에 올라온 "개발자가 시도해볼만한 도전적인 프로젝트들" 의 2편 https://news.hada.io/topic?id=1085

관련해서 HN 댓글에서도 다양한 것들을 추천하고 있습니다 https://news.ycombinator.com/item?id=25489879
- Build a toy regex engine
- Tetris
- ION (Intuitive Ordinal Notation)
- Fantasy Sports
- Game Boy Emulator

"Build you Own X" 에도 더 많은 리스트들이 있습니다. https://news.hada.io/topic?id=850

게임 보이 에뮬레이터는 만들어보고 있는데 정말 재미있는 걸 많이 해볼 수 있습니다. CPU와 GPU가 어떻게 데이터를 주고 받을지, 인터럽트는 어떻게 구현할 지.. 등등...

https://gbdev.io/pandocs/

개발에 관심이 있으시다면 위 사이트를 쭉 한번 둘러보시는 걸 추천드려용.

https://github.com/gbdev/awesome-gbdev

더 많은 개발 정보를 찾고 싶으시면 여기를 보시는 걸 추천드립니당. 'ㅁ'! 그리고 https://github.com/ffdd270/study_emu 제가 개발중인 repo도 있는데, CPU 명령어들은 모두 구현과 C++로 테스트 케이스를 짜놔서, 혹시 구현하실 떄 막히시면 테스트 케이스를 보시면서 해결해보시는 것도 좋을 것 같습니당.

이번년도 안에 닌텐도 로고 띄우는 걸 목표로 GPU도 개발중입니당. 궁극적인 목표는 게임보이 개발을 인터렉션하게 배울 수 있는 무언가를 만들고 싶은데 =ㅁ=.. 일단 로고부터 띄우고..

 
M1은 RISC-V의 상승을 예고한다

"M1은 패러다임 이동의 시작으로 RISC-V에 도움이 되겠지만, 당신이 생각하는 그 방식은 아닐 것이다"
"M1 칩은 왜 그렇게 빠를까?" 를 쓴 엔지니어의 후속 글. RISC-V의 미래를 재미난 관점으로 예상.

M1 성능의 요인은
1. 많은 수의 디코더와 OoO 비순차 실행
2. GPU,NPU,DSP 등 여러개의 전용칩

이 글은 2번 Heterogeneous(이기종) 컴퓨팅에 대한 더 자세한 내용
전용칩들은 여러가지로 부를 수 있는데 여기선 모두 Coprocessor(보조프로세서) 로 통칭(혹은 Accelerator 라고도 부를수 있음)
- 코프로세서는 완전히 새로운 트렌드는 아님
- 1985년에 나온 Amiga 1000도 오디오/그래픽을 위한 보조프로세서가 있었고, GPU도 보조프로세서이고,
ㅤ구글의 TPU(Tensor Processing Unit) 역시 머신러닝에 최적화된 보조프로세서

[ Coprocessor 는 무엇인가 ]
- CPU와 달리 혼자 살수 없음. 보조프로세서만 넣는다고 컴퓨터가 되지 않으며, 단순히 특정 작업을 잘 하는 특수 목적 프로세서
- 초기의 예시는 인텔의 8087 Floating Point Unit(FPU). 인텔의 8086은 정수 게산은 잘했지만, 부동소수점 연산은 잘 못했음
- 정수 계산으로도 부동소수점 연산을 에뮬레이트 할수 있지만 느렸음. 이건 마치 초기의 마이크로프로세서가 덧셈/뺄셈만 할수 있고 곱셈은 못해서 여러번의 덧셈을 반복해서 곱셈을 처리한 것과 비슷.
- 즉, "복잡한 수학계산은 간단한 것을 반복함으로서 처리가 가능"
- 모든 보조프로세서가 하는 일은 이것과 마찬가지. CPU가 보조프로세서가 하는 일을 할수는 있음. 단순 동작을 반복하면 됨
- 초기에 GPU가 필요했던 이유는 수백만개의 폴리곤/픽셀에 동일한 계산을 반복하는게 CPU에선 시간이 많이 필요하기 때문

[ 데이터는 보조프로세서에서 어떻게 In/Out 하는가 ]
- 마우스/키보드/스크린을 비롯하여 GPU/FPU/Neural Engine을 포함한 모든 보조프로세서는 특정 메모리 에 접근하여 데이터를 읽고 쓰는 것과 같음
- 이 작업들은 Device Driver가 처리하므로 일반 소프트웨어 개발자들은 볼일이 없음
ㅤ→ DMA(Direct Memory Access) 컨트롤러 등이 하는 일
- DOS시절 C/C++ 에서는 포인터로 비디오 메모리 주소에 직접 접근하여 픽셀을 바꾸는게 가능했음
- 보조프로세서는 이런방식으로 동작하여, NPU,GPU,T1 등이 각자 자신들과 통신하는 주소를 가지고 있고, 비동기적으로 통신이 가능
- CPU는 Neural Engine 또는 GPU로 보낼 전체 명령을 메모리에 나열한뒤 그 주소를 Neural Engine/GPU 에 알림
- CPU가 코프로세서가 그 명령과 데이터를 처리할동안 기다릴 필요는 없으니 이때 인터럽트가 필요해 짐

[ 인터럽트의 동작 방식 ]
- 그래픽/네트워크 카드는 PC에 꼽히고 지정된 인터럽트 라인이 있음
- 이건 CPU와 직접 연결된 라인처럼 동작해서, 활성화 되면 CPU가 다른일을 내려놓고 인터럽트를 처리
- 실제로는 현재 위치와 레지스터를 메모리에 저장해서 나중에 돌아갈수 있음
- 그 다음엔 인터럽트 테이블에서 수행할 작업을 찾음. 테이블에 인터럽트 트리거시 실행할 프로그램 주소가 들어있음
- 프로그래머한테는 이런게 보이지 않고, 특정 이벤트에 등록하는 콜백함수처럼 보임. 디바이스 드라이버가 저수준에서 이런 처리를 함
- 이런 설명을 하는 이유는 보조프로세서를 사용할 때 무슨일이 일어 나는지를 알고 있어야 실제 통신할때 어떤 일이 수반되는지를 알수 있기 때문
- 인터럽트를 사용하면 많은 일이 병렬로 일어남.
ㅤ→ CPU가 마우스에 의해 중단되는 동안 응용프그램은 네트워크카드에서 이미지를 가져올수 있고, 마우스가 옮겨지고 나면 CPU는 새 좌표를 얻고, 이걸 GPU로 보내서 새 위치에 마우스 커서를 그림. GPU가 마우스 커서를 그릴때 CPU는 네트워크에서 가져온 이미지처리를 시작
- 이런 인터럽트를 사용해서 M1의 뉴럴엔진에 복잡한 기계 학습작업을 보내서 WebCam에서 얼굴을 식별할수 있음. 뉴럴엔진이 이미지데이터를 처리하기 때문에 이때 컴퓨터와 CPU는 다른 작업을 하면서 사용자에게 반응이 가능

[ The Rise of RISC-V ]
- 2010년 UC 버클리의 병렬컴퓨팅 랩은 보조프로세서를 더 많이 사용하는 방향으로 발전.
- 범용 CPU코어를 쥐어짜서는 더 이상 쉽게 성능을 늘릴수 없다는 것에서 무어법칙의 끝을 보았음
ㅤ→ 특수한 하드웨어인 보조프로세서가 필요해짐
- 클럭주파수는 열과 전력소비등 때문에 쉽게 증가시킬수 없음.
ㅤ→ 많은 디코더와 OoO 비순차 실행을 하는게 하나의 방법
ㅤ→ "M1 칩은 왜 그렇게 빠를까?" 글을 참고 https://news.hada.io/topic?id=3315

[ 트랜지스터 예산을 CPU 코어에 쓸것인가 Coprocessor에 쓸 것인가 ]
- 128코어로 늘린다고 데스크탑 시스템이 더 효율적이 되지 않음
- 80년대 초반엔 2만개의 트랜지스터 예산이 있을때 15000개를 들여서 CPU를 만들면 되었음
- CPU가 100개의 다른 작업을 한다고 할때, 그중 한개의 작업을 처리하기 위한 보조프로세서를 만들면 1000개의 트랜지스터가 필요하면, 모든 작업에 대한 보조프로세서를 다 만들면 10만개의 트랜지스터가 필요해서 예산을 초과해 버림

[ 트랜지스터가 많아지면서 전략이 변경됨 ]
- 초기설계에서는 범용 컴퓨팅에 집중해야 했지만, 요즘은 엄청나게 많은 트랜지스터들이 들어가게 되므로, 그것들로 뭘 해야할지를 알 수 없음
- 그래서 보조프로세서를 설계하는 것이 큰 일이 됨. 다양한 새 보조프로세서를 만드는 많은 연구가 진행.
- 이 연구는 멍청한 가속기상태에서 기초부터 키워야하는 경우들이 많음
- CPU와 달리 모든 단계의 명령들을 읽고 처리하는게 아니기 때문에, 메모리에 접근하거나 정리하는 방법등을 모름
- 이에 대한 해결책은 간단한 CPU를 컨트롤러로 사용하는 것
- 즉, 전체 보조프로세서들은 간단한 CPU에 의해 제어되는 특수한 가속기 회로로서 특정 작업을 가속하도록 구성됨
ㅤ→ 예를 들어 Neural Engine/Tensor Processing Unit 같은 칩은 행렬을 저장할수 있는 큰 레지스터를 조작할 수 있음

[ RISC-V 는 Accelerator 를 제어하도록 맞춤 제작 되었음 ]
- 이게 RISC-V 가 설계된 목적
- 일반적인 CPU작업을 위한 40~50개의 최소 명령어 세트를 가지고 있음
ㅤ→ x86 CPU는 1500개의 명령어 셋이 있음
- 큰 고정 명령어 세트 대신, RISC-V는 확장 개념을 중심으로 설계됨
- 모든 보조프로세서는 다르므로, 따라서 RISC-V는 코어 명령어 세트와 보조프로세서가 필요로 하는 확장명령어 세트를 가지게 구성이 가능

이게 이 글에서 설명하고자 하는 것

- Apple의 M1은 업계 전체가 보조프로세서가 지배하는 미래로 향하게 할 것
- 그리고 이 보조프로세서를 만들기 위해 "RISC-V는 퍼즐의 중요한 부분"이 될 것

[ RISC-V로 Coprocessor를 만들면 좋은 점 ]
- 칩을 만드는 것은 복잡하고 비용이 많이 드는 일
- 칩 검증을 위한 도구 구축부터, 테스트 프로그램을 실행하고, 진단 및 기타 여러가지를 하려면 많은 노력이 많이 필요.
- 이게 요즘 ARM을 사용하는 가치의 일부. 큰 에코시스템이 있기때문에 디자인을 검증하고 테스트가 가능

- 그래서, 자신만의 명령어셋을 가지는 것은 좋은 생각이 아님
- RISC-V에는 여러회사에서 도구를 만들수 있는 표준이 있고, 에코시스템이 생겨서 여러 회사가 부담을 공유할수 있음

- 이미 있는 ARM을 사용하지 않는 이유는? ARM은 범용 목적 CPU로 만들어 져서, 큰 고정 명령어세트를 가짐
- 고객의 요청과 RISC-V 와의 경쟁때문에 ARM도 2019년에 확장용 명령어 세트를 공개했음
- 하지만 여전한 문제는 처음부터 이를 위해 설계된것이 아니라는 것
ㅤ→ 전체 ARM 툴체인은 대형 ARM 명령어 세트를 구현했다고 가정
ㅤ→ 하지만 보조프로세서는 큰 명령집합을 원하거나 필요로 하지 않음
ㅤ→ 보조프로세서는 확장기능이 있는 최소 고정 기본 명령어 세트라는 아이디어 기반으로 구축된 도구의 에코시스템을 원함

- 이게 왜 유익한지는 Nvidia 의 RISC-V 사용에서 인사이트를 얻을수 있음
ㅤ→ 대형 GPU는 컨트롤러로 사용할 일종의 범용 CPU를 필요로 함
ㅤ→ FALCON : FAst Logic CONtroller 라는 칩을 만들어서 사용
ㅤ→ 저비용 고효율

- RISC-V는 작고 간단한 명령어 세트를 가지고 있기때문에 ARM을 비롯한 모든 경쟁제품을 능가
- Nvidia는 RISC-V 를 선택함으로서 더 작은칩을 최소화된 전력으로 가능하게 만듦
- 확장 메커니즘을 사용하면 필요한 작업에 맞는 명령만 추가가 가능

[ ARM은 새로운 x86이 될 것 ]
- 아이러니컬 하게도 Mac 과 PC 가 ARM으로 구동되는 미래를 볼수 있을 것
- 그러나 그 주변의 커스텀 하드웨어들은 RISC-V로 지배된 보조프로세서들이 차지할 것
- 보조프로세서가 대중화 되면서, SoC 위에는 ARM보다 RISC-V 칩들이 더 많아 질 것
- 미래는 ARM or RISC-V 가 아니라, ARM and RISC-V 가 될 것

[ ARM 은 RISC-V 보조프로세서 군단을 지휘하게 될 것 ]
- 범용 ARM 프로세서는 그래픽,암호화,비디오 압축,머신 러닝,신호처리를 담당할 RISC-V 보조프로세서 군대와 함께 중심에 있게 될 것
- UC Berkeley 의 David Patterson 교수와 그의 팀은 이러한 미래가 다가오는 것을 보고, RISC-V 를 그거에 잘 맞게 조정 했음
- 모든 종류의 특수 하드웨어 및 마이크로 컨트롤러들이 RISC-V에 큰 관심을 보이고 있으며, 오늘날 ARM이 지배하는 많은 영역이 RISC-V가 될 것

[ RISC-V를 메인 CPU로 사용하면 안될까 ? ]
- 많은 사람들이 ARM을 RISC-V 로 완전히 교체하는 것은 어떤가함
- 혹자는 RISC-V의 너무도 간단한 명령어 셋이 ARM과 x86이 주는 고성능을 제공 못할 것이라고 함

- 하지만 RISC-V를 충분히 메인프로세서로 사용 가능하고, 성능은 문제가 되지 않음
ㅤ→ 다만, ARM 처럼 고성능 RISC-V를 만들사람이 필요함
ㅤ→ 즉, 가능은 하지만 모멘텀이의 문제라는 것. MacOS와 Windows가 이미 ARM에서 실행이 되고 있음
ㅤ→ 단기적으로 MS나 Apple이 또 다른 하드웨어 전환을 위한 노력을 하지는 않을 것임

이 분 정말 글 잘쓰네요. 이것도 재미나게 읽었습니다.
RISC-V 가 또 다른 대안이 될것이라는 예상들은 많았는데,
이런식으로 보조프로세서용으로는 최고의 칩이 될수 있겠다는 관점으로는 생각을 못해봤습니다.

중국이 RISC-V에 거의 올인하다시피 하는 걸로 알고 있는데.. 정말 미래가 어떻게 될지 상상도 안되네요

점점 흥미진진해 지네요.
Intel과 AMD의 대응이 궁금해 집니다.

 
Owncast - 오픈소스 라이브 스트리밍 서버

"나만의 Twitch 셀프호스팅"
- 커스터마이징 가능한 웹 UI
ㅤ→ 비디오 플레이어 와 채팅
- RTMP 호환 가능한 방송 프로그램과 연동 (OBS,Zoom,Restream등)
- HLS Adaptive bitrate streaming 지원
- 영상과 채팅은 외부 임베딩 지원
- S3/B2 등의 외부 저장소를 이용한 스트리밍도 가능
- Docker 로 설치 가능
- Digital Ocean/Linode 의 월 $5 서버로 운영 가능

 
LinkAce - 오픈소스 북마크 아카이브 서버

- 개인이 호스트해서 사용하는 북마킹 서비스
- 자동으로 링크의 타이틀/설명 추출하고 개별 노트 작성 가능
- 북마크시 Internet Archive를 이용해서 백업 저장
- 북마클릿 및 REST API 제공
- 링크와 콜렉션은 공개/비공개 설정가능
- 다양한 필터/정렬을 제공하는 검색 기능
- AWS S3로 백업 가능
- PHP 오픈소스. 도커로 설치가능

 
SuperTokens - 오픈소스 Auth 서비스

- Auth0 / Firebase Auth / AWS Cognito 등의 오픈소스 대체제
- OAuth, 이메일/암호 로그인, 암호 찾기, 세션 관리, 이메일 인증, 소셜 로그인
주요 컴포넌트
- SuperToken Core : Java 로 만들어진 HTTP 서비스. 실제 비즈니스 로직
- Frontend SDK : 웹/iOS/Android/ReactNative 등 지원하는 로그인 UI 관련 기능
- Backend SDK / Driver : NodeJS,Flask,Golang 등 다양한 백엔드 프레임워크와 연동하여 SuperToken Core와 통신
- Database Plugin : MySQL,PostgresSQL,MongoDB,SQLite 등
- Y Combinator가 투자

 
Open Source Stash

- 디자이너/개발자/분석가들을 위한 주요 도구의 오픈소스 대체제 모음
- 카테고리별 보기 또는 검색 가능
ㅤ→ Design
ㅤ→ Communication
ㅤ→ Analytics
ㅤ→ Password Managers
ㅤ→ Wiki
ㅤ→ Word processing
ㅤ→ Collaboration
ㅤ→ Invoicing
ㅤ→ Note-taking
ㅤ→ Project Management
ㅤ→ Video
ㅤ→ Audio
ㅤ→ Email Automation
ㅤ→ CRM
ㅤ→ Social Network
ㅤ→ SEO
ㅤ→ Developer Tools
ㅤ→ Ecommerce
ㅤ→ Form Builders
ㅤ→ URL Shortners
ㅤ→ Website builders
ㅤ→ Accounting
ㅤ→ Browser

 
Luft: 10초만에 10억 데이터를 쿼리하는 데이터스토어 개발기

월 평균 이벤트 수가 100억 건이 넘는 환경에서, 빠른 시간 내에 데이터를 분석하여 유저 행동 기능 분석(Cohort)을 해줘야 하는 상황이 옴
(ex. 지난 6개월간 우리 앱에서 한 달에 10만원 이상 소비한 30대 여성 → 이들의 재방문율)

이런 환경에서 개발자가 쓰기만 했던 데이터스토어를 직접 구현하는 이야기를 담음.

# 유저 행동 분석 쿼리를 구현하기 위해서는…
- 사전에 미리 계산해놓지 않은 메트릭을 쿼리할 수 있어야 함 (+ 새로운 종류의 분석도 Re-indexing 없이 가능해야)
- 이벤트 데이터를 유저 별로 Group By할 때 High Cardinality Shuffle의 보틀넥은 적어야 함

# 기존 솔루션을 쓸까, 자체 솔루션을 만들까 고민함
- Druid는 다른 곳에서 사용중이었지만 Pre-Aggregation(계산된 값만 읽는 방식)의 한계로 기능 구현에 부적합
- Snowflake나 Redshift 등의 데이터 웨어하우스를 큰 규모로 운영할 수는 있지만, 특유의 범용성 때문에 목표 대비 너무 큰 규모의 클러스터를 운영해야되서 비쌈
- Funnel, ID 매칭 등 다양한 니즈를 커버하기 위해서는 SQL 기반 DB는 한계가 있음

# 결국 데이터스토어를 직접 만들다
- Luft = 처음부터 유저 ID 기준 Group By된 유저 행동 분석 쿼리를 빠르게 수행하는데 최적화된 데이터 스토어
- Golang을 기반으로 만들어짐
- 수십 TB 규모의 유저 데이터를 5대 이하의 노드만으로 평균 3초 ~ 최대 10초 사이에 분석
- 일반적인 RDBMS와 다르게 불변성을 가짐 (필요하다면 같은 기간의 데이터를 덮어씌움) → 심플한 클러스터 디자인, 복잡한 페이지 매니저 구현 없이 높은 성능, 원하는 데이터 저장 포맷 설계 가능

# 기술 기반 뜯어보기
- TrailDB (스토리지 엔진) - 유저 ID 파티셔닝에 최적화된 타임시리즈 이벤트 저장 Rowstore
ㅤ→ 값을 사전화시켜 그 ID만 저장
ㅤ→ 유저 이벤트를 시간순으로 정렬해 이전 이벤트 대비 늘어난 시간값, 바뀐 컬럼만 저장 (대부분의 사용자 속성은 변하지 않으므로)
ㅤ→ 인덱스 없음. 무조건 풀스캔해야 함.
ㅤ→ 근데 충격적으로 높은 압축률을 자랑 (CSV 13GB → ~TrailDB 300mb)
ㅤ→ 시간 복잡도는 O(n)이므로 공간 복잡도를 줄이면 되겠다고 생각
- LLVM (쿼리 엔진)
ㅤ→ 근데 TrailDB는 OR-AND 형식의 equals만 제공, Go에서 파싱된 쿼리를 C, C++로 전달해야 함
ㅤ→ PostgreSQL에서 쿼리를 LLVM JiT으로 컴파일한다는 것을 알게 됨
ㅤ→ 쿼리는 기능 확장이 빈번한데 C, C++로 짜면 개발 비용이 늘어나는 문제를 막을 수 있음 (Golang에서 LLVM IR만 생성해 넘기면 C, C++에서 JiT 컴파일에서 실행하면 됨)
- 연산 레이어 직접 만들기
ㅤ→ MapReduce가 많이 쓰이는데 Golang을 쓰기에 못씀
ㅤ→ Spark/Hadoop은 Long-running Job에 최적화되서 붙여봐도 성능이 잘 안나옴
ㅤ→ 이것도 직접 만듬 → https://github.com/ab180/lrmr
ㅤ→ gRPC + Protobuf + etcd 조합, 익숙한 Spark 디자인 많이 차용
ㅤ→ Resiliency를 포기하자 → 성능을 극한으로 높이면, 장애가 발생해도 처음부터 다시 해도 10초 미만
ㅤ→ 대규모 데이터 처리로 인한 버퍼 오버플로가 자주 발생 (Backpressure)하는 문제를 Pull-based Event Stream으로 변경 (Kafka, Armeria 등에서 채택)
- 샤딩 직접 구현하기
ㅤ→ 샤드 = 히스토리컬 노드
ㅤ→ 파티션의 날짜 범위를 샤딩 키값으로 사용하면?
ㅤㅤ→ 모든 쿼리에 시간이 있고 → 필터링 용이
ㅤㅤ→ 같은 시간 범위에는 비슷한 용량의 데이터가 있음 → 데이터 분산 용이
ㅤㅤ→ 분산 환경은 아름답지 않음…
ㅤㅤ→ 노드 다운되거나 새로 추가되면?
ㅤㅤ→ 저장 공간 꽉 차면?
ㅤㅤ→ 장애로 한 노드에만 쏠리면?
ㅤㅤ→ Druid의 Cost Function을 커스텀하여 파티션 날짜 범위 가깝고 겹칠수록 Cost가 높아지도록 만듬
ㅤ→ 샤드 가용성을 위해 아래의 일을 함
ㅤㅤ→ 샤드 정보에 TTL을 걸고 주기적으로 갱신 (etcd)
ㅤ→ S3에 파티션 저장, DynamoDB로 파티션 목록 관리

# 지금 프로덕션 상황
- 4대의 c5.2xlarge 인스턴스만으로 15초 내에 500GB 데이터 스캔

# 앞으로의 목표 (혹은 해야 할 일)
- 실시간 Funnel 분석을 10대 이내의 클러스터로 하고 싶음
- Spark를 지원해서 ML 연동 등을 지원하려 함
- TrailDB를 대체할 자체 컬럼스토어(Ziegel) 개발하고 있음
ㅤ→ SIMD와 멀티코어 최적화
ㅤ→ Bitmap Index로 사전에 유저 속성 기반 필터링

지금 보니까 개발자 분의 블로그 글도 있네요,
https://engineering.ab180.co/stories/introducing-luft

TrailDB는 처음 들어봤는데 요런 친구고...
https://github.com/traildb/traildb

traildb 재밌죠. https://www.youtube.com/watch?v=-oPFxSwn0lM 재미있습니다. 오래묵은 영상이지만 traildb가 그동안 바뀐게 없을거에요.

 
Hyper - 웹기반 터미널 도구

- 웹기술(Electron + xterm.js)로 만들어진 윈도우/맥/리눅스 용 터미널앱
- 빠르고 안정적이면서도, 아름답고 확장가능한 터미널을 만드는게 목표
- Node.js 모듈로 확장을 만들어 기능 확장가능 (React + Redux)
- V3 로 오면서 WebGL 적용으로 더 빨라짐

한글 입력 출력 다 잘 되고, 꽤 빠르군요.

아직 C++나 Rust로 만든 터미널 에뮬레이터 보다는 느린 느낌입니다.

거기에 WebGL을 켜면 Powerline 폰트를 쓰는 경우 문제가 있어서 더욱 속도면에서 아쉬움이 많습니다.

디자인이나 기능적인 면은 만족스럽습니다. 향후 발전을 기대하고 있습니다.

그러고보니 저도 Hyper를 꽤 오래 썼네요.
전에 올려주신 뉴스 https://news.hada.io/topic?id=3208 를 보고 Windows Terminal Preview 를 최근 몇 주는 사용하고 있는데, 이쪽도 맘에 들어서 계속 쓸 것 같습니다.

제가 쓰는 Hyper 는 탭 제목을 설정할 수 없는데, Windows Terminal Preview 는 탭 제목을 설정할 수 있어서 맘에 들어요.

 
Pace - 사이트에 자동 프로그레스바 붙이기

- Ajax / Event Lag / Doc Ready / Element 등을 자동으로 모니터링해서 웹페이지에 프로그레스바를 붙여주는 라이브러리
- 다양한 테마 제공 : 페이지 최상단 프로그레스바/카운터/코너 표시기/로딩바/센터 표시기 등
- 4kb 사이즈, 별도 의존성 없음

 
2021년을 위한 Favicon 정리

- 브라우저 스펙에 따라 수많은 파일이 필요한데, 이걸 하나로 정리
- 5개의 이미지와 한개의 JSON 파일
ㅤ→ .ico 32x32 : 예전 브라우저들
ㅤ→ .svg : 스케일링 가능, 대부분 최신 브라우저들, 다크모드도 지원
ㅤ→ apple-touch-icon 180x180 : 애플 기기용 iOS8+ 이후는 180x180 크기. 20px 정도 패딩과 배경색을 넣으면 보기 좋음
ㅤ→ manifest(JSON) : PWA 및 안드로이드 기기용
ㅤ ㅤ→ 192x192 : 홈스크린
ㅤ ㅤ→ 512x512 : PWA 로딩시 스플래시 스크린용

- 글에서는 이 5개의 아이콘을 한개의 SVG에서 만들고 최적화 하는 걸 단계별로 설명

 
FFmpeg 20주년

- 지금의 동영상 환경을 만드는데 큰 공헌을 한 ffmpeg 이 2000/12/20에 발표되어서 이제 20주년
- 처음에 개발한 사람은 QEMU,TCC,QuickJS,JSLinux를 만든 괴물급 개발자인 Fabrice Belllard (지금은 ffmpeg에서는 손을 뗌)

FFmpeg 때문에 동영상 환경이 정말 많이 발전해온거 같습니다.
이젠 EMScripten 을 통해서 ffmpeg.js 로 만들어져서 웹에서도 많이 사용되어지고 있고, 최근엔 WASM으로 포팅도 되었습니다.
그래서 아래와 같은 도구들이 만들어지는게 가능해졌고, 앞으로 웹에서의 영상제작이 더 활발해 질 것 같습니다.

Animockup - 앱/웹의 애니메이션 목업 만들기 https://news.hada.io/topic?id=1768
Screenity - 스크린/카메라 녹화용 크롬 확장 https://news.hada.io/topic?id=3298
Made it For Fun - 동영상위에 이미지/텍스트를 애니메이트 하는 도구 https://news.hada.io/topic?id=1869

개발자인 Fabrice Bellard 는 정말로 엄청난 사람인데
예전에 QuickJS 글에 달았던 소개를 복사해봅니다. https://news.hada.io/topic?id=59

~~
Fabrice Bellard 는 정말 괴물급 개발자.

1989년에 LZEXE 개발

1996년에 Harissa - Java Virtual Machine 이자 Java to C 코드 컴파일러

1997년에 2진법 표기시 파이(π)의 특정 자리수 값을 알아내는 공식 발표.
-> 앞자리를 전혀 계산하지 않는 방법으로 계산. 1조번째 자리는 "1"
https://en.wikipedia.org/wiki/Bellard%27s_formula

1998년에 TinyGL 발표 - 작고 임베드가능한 OpenGL 구현체

2000년에 FFMpeg 발표. 현재 우리가 보고있는 대부분의 동영상 플레이어가 사용중.

2000년에 가장 큰 소수를 찾는 448바이트 C코드로 IOCCC 우승. 이 소수는 2016년까지 발견된 가장 큰 소수였음.

2001년에 Tiny C Compiler 발표 - 초경량 C 컴파일러

2002년에 QEmacs 발표 - 초경량 Emacs 클론. HTML/XML/CSS2 WYSIWYG 렌더링 및 수정가능 (자체 브라우저엔진 내장)

2003년에 QEMU 발표 - 하드웨어 가상화 기능을 갖춘 CPU 에뮬레이터

2004년에 TinyCC Boot Loader 발표 - 리눅스 커널을 직접 컴파일해서 부팅이 가능한 부트로더

2005년에 DVB-T 시그널 생성기 발표 : 비싼송출기 대신 데스크탑에서 디지털티비 송출이 가능. 이건 소스코드 미공개

2009년에 π 소수점 아래 2조 7천억자리 까지 계산해서 세계 신기록세움. 자기 데스크탑으로 131일 동안 계산했다고.
-> 큰 숫자에 관심보다는 그냥 컴퓨터 프로그래밍 도전을 위해서 였다고.

2011년에 JSLinux 발표. 웹브라우저에서 실행되는 Linux 발표.

그외에도 JPG보다 압축률좋은 HEVC 기반 이미지 포맷 BPG (자바스크립트 디코더 제공해서 아무 브라우저에서나 사용가능)

4G LTE/5G NR 베이스 스테이션을 PC기반으로 저렴하게 구현했고, 이건 자신의 회사인 Amarisoft 를 통해서 상품화

하는일마다 이게 어찌 한사람이 하는 일인지 놀라울뿐인 사람.

 
DEVIEW 2020 발표자료와 영상 공개

DAY 1 (AI/ML)
- KEYNOTE - Connecting beyond technologies / 네이버
- 오픈도메인 챗봇 ‘루다’ 육아일기: 탄생부터 클로즈베타까지의 기록 / (주)스캐터랩
- 거리뷰 AI 스카우터 만들기 / 네이버 Clova CIC
- 밑바닥부터 만드는 인공지능 서빙 플랫폼 / 네이버 Clova CIC
- 스포츠 Live & VOD에 AI를 더하다!!! / 네이버 미디어Tech
- 딥러닝 기술을 이용한 검색시스템 응답시간 예측 / 네이버 Search CIC
- 사람들 사이에서 로봇 살아남기 / 네이버 LABS

DAY 2 (Front-end, Back-end, Search 외)
- GraphQL이 가져온 에어비앤비 프론트앤드 기술의 변천사 / 에어비앤비
- 어서와, SSR은 처음이지? / 네이버 Apollo CIC
- GraphQL API 까짓거 운영해보지 뭐 / 네이버 Glace CIC
- 개발 생산성 10배 높이기 : from C++ to Golang / 네이버 Search CIC
- 깃헙 4.4K 스타 billboard.js 메인테이너가 들려주는 오픈소스 개발기 / 네이버 Platform Labs
- 눈치까지 챙긴 D.I.A.+ 시스템, 싹 다 찾아드립니다. / 네이버 Search CIC

DAY 3 (For juniors, Hands-on, 오픈소스 외)
- Recoil: 왕위를 계승하는 중입니다 (새로운 React 상태 관리 라이브러리) / Automattic
- 오픈 소스 활동을 시작하기 위한 작은 가이드 / 네이버 Whale
- 성능개선 뛰어들기 (고전적 SSR 성능개선) / 네이버Search CIC
- Deno 를 통해 알아보는 Javascript 세상 이야기 / 네이버 Forest CIC
- 주니어 개발자의 도보 길찾기 서버 개발기 / 네이버 Glace CIC
- 리액트 개발이 이렇게 쉬웠나? (feat. Next.js) / 네이버 Forest CIC

 
Cortex - 머신러닝을 위한 오픈소스 배포 플랫폼

"Run inference at scale"
- TensorFlow, PyTorch, Sklearn 을 비롯한 여러 모델 지원
- AWS/GCP/Azure 등에 대규모 배포 및 Request 기반 자동 스케일링
- CI/CD 시스템과 연계
- 성능 메트릭 & 로그를 모니터링 도구들로 스트리밍
- 멀티모델 캐슁으로 다수 모델을 효율적으로 서빙
- 다운타임 없는 롤링 업데이트 지원
- A/B 테스팅을 위한 트래픽 분할

 
Google 장애#20013 (2020/12/14) 보고서 업데이트

2020/12/18 업데이트 (원인과 대응방안 추가)

#ROOT CAUSE

지난 10월부터 구글 사용자 ID서비스에 새로운 자동 스토리지 할당 시스템을 도입하였다. 일부 서비스에서는 기존 쿼터 시스템을 사용중이였으며, 사용량을 0으로 보고하고 있는 문제를 가지고 있었다. 0으로 보고된 것이 즉각적인 영향이 없었던 것은 Expire 시간이 남아있었기 때문이고 시간이 만료된 이후 User ID 서비스의 쿼터를 줄이면서 장애가 발생했다. 의도치 않은 쿼터 변경을 검증하기 위한 안전 검사 항목이 있기는 하지만 0인 시나리오를 다루지는 않았다.

계정 Database의 쿼터가 줄어들었고 Paxos leader의 쓰기가 불가능해졌고 그리고 대부분의 읽기 작업이 만료되어 인증 조회시 오류가 발생하였다.

#REMEDIATION AND PREVENTION
1. 글로벌 변경사항의 빠른 Implementaion을 방지하기 위해 쿼터 매니지먼트 오토메이션 리뷰
2. 모니터링 및 얼럿을 개선하여 잘못된 설정을 빠르게 포착
3. 내부 툴에 의해 장애 발생시 외부 커뮤니케이션을 위한 툴과 프로세스의 안정성 향상
4. User ID 서비스 데이터베이스에 대한 쓰기 오류 Resilience 구현
5. User ID 서비스 실패시 데이터 영역에 미치는 영향을 엄격한 제한하여 GCP서비스의 Resilience 개선

* 12월 14일에 있었던 장애에 대해서 상세한 보고서가 업데이트되서 읽다가 발번역해봤어요. 오류가 있으면 알려주세요. 그리고 항상 재밌게 보는 GeekNews여서 재밌는 장애관련 내용있으면 남겨보도록할께요.

 
Shotr - 맥용 스크린샷 캡처 도구

- Cmd+Shift+1 / 2 로 전체/부분 화면 캡쳐
- 쉽게 확대/축소하며 크롭 : q,w,z,cmd+1/0등 다양한 줌 단축키
- 화살표키 ↑→ 로 커서 위치의 객체 상하/좌우 크기를 잴 수 있는 줄자 기능
- Tab 키로 마우스 위치의 색상 복사
- dmg로 다운받아 설치하는 무료 도구

이런게 있었으면 했는데 찾게되었네요. 소개 감사합니다.

줄자로 객체 사이즈 재는게 꽤 편하네요. 종종 사용하게 될 듯 합니다.

 
imapapi - IMAP/SMTP 계정을 REST로 접근하기

- 이메일 계정을 REST로 접근하게 만들어주는 중계 서버
- IMAP 및 SMTP API 지원
- 사용 용도
ㅤ→ 사용자의 이메일을 받아와서 대신 처리해주는 서비스
ㅤ→ IMAP과 MIME처리를 하지 않아도 되는 가벼운 웹메일
- IMAP API는 AGPL 버전과 MIT 버전을 별도로 지원

 
NoteCalc - 사용하기 편한 노트형 계산기

- 글자가 포함된 노트중에서 수식만 빼내어서 우측에 계산해 주는 도구
- 맥/iOS용 훌륭한 계산기앱 Soulver의 오픈소스 웹버전
- 숫자만 자동 합산
- 선택 부분만 계산해서 보여주기
- 특정 라인 결과값 참조
- 변수/참조 하이라이팅
- 변수 이름 자동완성
- 벡터 와 행렬 지원
- 비트연산 및 16진수 표시
- sin,cos,pi,nth 등 내장 함수
- 단위 변환
- 자동 저장 및 공유 기능
- Rust 로 개발된 오픈소스

제가 아이폰에서 가장 잘쓰는 계산기 앱이 Soulver 인데, 웹버전이 있는지 몰랐네요.
( 지금은 iOS용 새 버전을 위해서 기존 버전은 내려가서 구입을 할수가 없고 맥버전만 구입이 가능합니다. 조만간 새 버전을 낸다고는 합니다)
https://www.acqualia.com/soulver/
정말로 대충 막 적어놓으면 우측에 계산을 해주는 신통방통한 계산기입니다.

앱스토어에서 Notepad Calculator 로 검색해보면 비슷하게 구현한 앱들이 많으니 함 써보시기 바랍니다.

아쉬운건 아이폰 Soulver 는 한글도 잘 써지는데, 이 웹버전 NoteCalc는 한글이 불가능 합니다.
오픈소스니 긱뉴스 통해서 조금 더 알려지면 누군가 수정해주시려나요? ㅎㅎ

여행 일정 메모겸 비용 계산으로 활용하면 좋겠군요. 어서 코로나가 마무리되어야......

조금 다른 이야기지만, 제가 맥에서 가장 잘 썼던 계산기 앱은 [Magic Number 2]였습니다. 유료지만 돈값은 한 것 같아요. 윈도우 같은 다른 플랫폼에서도 쓰고 싶을 정도라서…
https://apps.apple.com/kr/app/magic-number-2/id737047715

 
가끔 깨지는 빌드(flaky build)를 18분의 1로 줄이기

GitHub에서 같은 코드인데 어떤 경우에는 빌드가 깨지고 어떤 경우에는 통과하는 빌드를 flaky 빌드라고 정의하고 flaky는 해당 코드를 작성한 사람한 사람이 해결해야 하고 다른 사람한테 영향을 주지 않도록 자동화를 도입해서 flaky 빌드를 1/18로 줄였다고 한다.

GitHub 내부 CI에 flaky 빌드를 추적하고 문제 상황을 정리한 뒤에 해당 문제를 만들었을 것으로 추정되는 사람에게 할당한다.

- flaky 빌드를 추적해 보니 빈도가 달랐는데 100번 이상 실패하는 flaky 빌드는 전체의 0.4%였다. 그래서 이 0.4%에 집중하기로 했다.
- 2016년에 도입했을 때는 다음 두가지 방법으로 접근했다.
- 빌드가 끝나면 같은 커밋으로 실행된 빌드를 찾아서 결과가 다를 경우 flaky 빌드라고 표시
- 같은 빌드에서 재시도 했는데 결과가 다르면 flaky 빌드 표시
- 이 방법으로는 전체 flaky 빌드 중 25%만 구별할 수 있었다.

## 개선하기
- 3번 재실행하는 방법을 사용
1. 같은 프로세스에서 재시도한다. 이 flaky 빌드는 코드의 우연성이나 레이스 컨디션 때문에 발생한다.
2. 같은 프로세스이지만 시간이 지나서 재시도한다. 이 flaky 빌드는 시간에 관해 잘못된 가정을 했을 때 발생한다.
3. 완전히 다른 호스트에서 재시도한다. 이 flaky 빌드는 테스트 순서 의존성이나 공유 상태때문에 발생한다.

이 방법을 통해서 90%를 자동으로 탐지할 수 있게 되었다.

## 영향도 측정
우선순위를 정하기 위해 영향도를 정량화하는 방법이 필요했다.

빌드, 브랜치, 작성자, 커밋등의 정보를 이용해서 얼마나 많이 실패하고 다른 브랜치나 개발자에 영향을 주는지 영향도 점수를 매긴다.

일정 점수가 넘으면 개발자들이 수정할 수 있도록 이슈를 만들어서 개발자한테 할당한다.

저같은 경우에는 gradle의 unittest에서 flaky build 가 자주 발견되어서 아래의 솔루션들을 적용했었습니다.

* https://plugins.gradle.org/plugin/org.gradle.test-retry 플러그인을 이용하면 unittest에 대한 flaky build를 추적하는데 큰 도움이 됩니다.
* https://docs.gradle.org/current/dsl/… 을 이용하면, 일정기간 이후 새로운 프로세스에서 수행되므로 flaky build가 완화될 수 있습니다.
* gradle enterprise를 도입하면 flaky build의 추이를 쉽게 볼 수 있습니다. https://gradle.com/blog/flaky-tests/

 
TerarkDB, RocksDB 의 성능개선형 포크

- 바이트댄스가 RocksDB를 포크하여 Tail 레이턴시, 처리량, 압축을 개선한 버전
ㅤ→ 읽기 2~8배, 쓰기 2~15배 정도의 향상
- 임베디드 키밸류 저장소인 RocksDB를 그대로 교체하여 사용 가능
- 리눅스에서만 프로덕션 테스트 완료
- 기존 RocksDB 데이터를 이관가능하지만, 이관후 RocksDB로 롤백은 불가
- RocksDB v5.18.3 을 포크

관계를 잘 정리한 HN 댓글이 있어서 옮겨와 봅니다.
https://news.ycombinator.com/item?id=25518065

TerarkDB 는 RocksDB 를 ByteDance 가 포크해서 만든 개선 버전
RocksDB [1] 는 구글의 LevelDB 를 페이스북이 포크. 많은 CPU코어와 SSD 및 I/O 작업에 최적화한 것
LevelDB [2] 는 구글의 Jeffrey Dean 과 Sanjay Ghemawat 이 만든 오픈소스 디스크 키밸류 스토어. BigTable에서 영감을 받음
BigTable [3] 은 Google File System 위에 만들어진 고성능 압축 데이터 저장 시스템. 구글의 독점적인 서비스
Pebble [4] 은 CockroachDB 가 RocsDB/LevelDB 에 영감받아서 자체적으로 만든 대체제

[1] https://rocksdb.org/
[2] https://github.com/google/leveldb
[3] https://cloud.google.com/bigtable/
[4] https://github.com/cockroachdb/pebble

 
애플 실리콘이 브로드웨이에 미치는 영향

- 브로드웨이 쇼는 밖에서 보기엔 화려하고 비싸게 보이지만, 안쪽으로 가면 안그렇고 특히나 음악쪽은 더 안좋음
- 전자 음악 디자이너들의 가장 힘든 일중 하나는 키보드,기타,재생 트랙등을 구동하는 최고 가성비의 컴퓨터 장비를 찾는 것

- 지난 10년간 브로드웨이는 전통적인 오케스트라를 신디사이저/재생시스템/전자드럼 등으로 교체해왔음
- 이를 위해 $10000 ~ $12000 정도의 예산을 잡아서 신디사이저 키보드 Rigs들을 구매
ㅤ→ 좋은 키보드는 보통 $1500~$2000 사이니까 두대면 약 $4000 정도
ㅤ→ 메인 Rig이 잘못될 경우를 대비해서 두대의 Rig을 마련하니까 $4000 X 2 해서 $8000
ㅤ→ 즉 컴퓨터와 그외 다른 것들을 위해서는 예산이 $3000 정도 밖에 안남는 상황
- 예산때문에 다들 맥 Mini를 사용해 왔는데, 기존 맥 미니들은 전자 음악 디자이너들에게 병목이었음
- 최고의 사운드를 내는 샘플을 쓰고 싶지만, 성능상 불가능해서 맥미니 성능에 맞게 음질을 줄여서 사용
- 애플 실리콘은 브로드웨이 전자 음악 디자이너의 모든 것을 바꿈
- 새 M1 Mac Mini는 안정적으로 고급 샘플 라이브러리와 가상 악기를 안정적으로 사용이 가능
- 향후 M2/M3/M4 가 되면서 더 좋아질 것으로 기대
- 애플 실리콘 기기의 가성비가 브로드웨이의 사운드에 큰 영향을 미칠 것

* 참고 - Roland Keyboard Rigs https://www.roland.com/us/promos/keyboard_rigs/

영상계는 어차피 프리미어 같은 게 윈도우에서 잘 지원하고 하드웨어도 좋아서 맥 윈도우 반반 쓰는 모양이던데, 음향쪽은 다들 쭈욱 맥 쓰는 모양이더라고요. 맥 사운드 시스템이 레이턴시가 짧다고...
M1 업데이트 이후 이쪽은 드라이버 업데이트가 빨리 되나보네요.

 
우리가 .ORG를 구한 방법 : EFF의 2020년 리뷰

큰 이슈가 되었던 .ORG TLD 관리회사 PIR의 매각에 대응해서 막아낸 EFF의 올 한해 리뷰
2만7천명이 오픈레터에 사인하고, 871개의 단체들이 참여해서, 적극적으로 이 판매건이 미치는 영향들을 파악하고 알림
최종적으로 4월에 ICANN 이사회가 .ORG 판매를 거부

* 긱뉴스를 통해서 이 이슈들을 계속 팔로잉 했어서, 제가 정리했던 내용들을 모아봅니다.

1985년 시작된 최초의 TLD(Top Level Domain)는 모두 7개
.com, .int, .edu, .gov, .mil, .net, .org

1998년부터 비영리 단체인 ICANN(Internet Corporation for Assigned Names and Numbers,국제인터넷주소관리기구) 가 이를 관리중.

.com 도메인은 영리단체인 Network Solutions 가 관리했으나 현재 Verisign 이 인수.
그래서 .com 도메인은 마치 가상의 부동산 처럼 사고 파는 애셋이 되었음.

하지만 .org 는 비영리기관인 PIR 이 관리했고, $9.05 의 가격상한을 두어서
애초에 비영리기관용 도메인이었던 .org 가 예산이 빠듯한 단체들이 쉽게 이용할수 있도록 했었음.

하지만 2019년 6월 ICANN 이 .org 도메인의 가격상한을 없애 버렸음 ( .biz 와 .info 상한 없어짐 )

그러자, 천만개의 .org 도메인을 관리하는 PIR(Public Internet Registry)이 핫한 인수대상으로 등극.
PIR의 2018년 매출은 천이백억원 정도이며, 이중 절반인 600억원을 원래 소유였던 ISOC(Internet Society) 쪽에 주고 있었음.

Ethos Capital 이 $1.135B(약 1조3천억원) 에 최종 인수자가 되었음.
Ethos Capital 은 2019년에 새로 설립된 사모펀드이고, 펀드 자체에 ICANN 의 전 멤버들이 관련

그에 대응해서 Public Internet Registry를 사모펀드인 Ethos Capital 에 매각하는 것을 중단해 달라고 요청하는
https://savedotorg.org/ 가 만들어지고, CC,EFF,FSF,Internet Archive,Wikimedia,YWCA 등이 참여

PIR 매각 가격이 $1.1B라고 밝힌 것에 대해 의문이 계속 나옴
- 공개입찰도 없었음
- 시장가격 조사도 없었음
- 거래에 대해 공개된 적이 없음
- 기부금 방식의 대안에 대한 논의 없음
- 미래 성장률 고려 없는 가격 산정
- 이 건이 가지는 충격에 대한 조사도 없었음.

ICANN 이 승인 지연한 후, 캘리포니아 법무장관이 연기하면서 4번이나 지연

최종적으로 PIR 매각을 거부하게 됨

1. .org TLD를 관리하는 비영리단체 PIR이 사모펀드에 매각됨 https://news.hada.io/topic?id=912
2. ICA 가 ICANN 에 .org 관리단체 매각에 대해 항의서한 보내 https://news.hada.io/topic?id=924
3. Save.ORG - PIR 매각을 중단해달라는 서명 사이트 https://news.hada.io/topic?id=959
4. ISOC가 .org 도메인을 매각한 금액은 1조3천억원 https://news.hada.io/topic?id=993
5. .ORG Fire Sale : 어떻게 절반도 안되는 가격으로 팔렸을까 https://news.hada.io/topic?id=1012
6. ICANN이 .ORG 거래건 승인을 지연하고 추가 자료 요청 https://news.hada.io/topic?id=1090
7. 캘리포니아 법무장관이 .org 도메인 판매를 연기 https://news.hada.io/topic?id=1423
8. ICANN이 .org TLD 판매 결정을 5/4일로 다시 한번 더 연기 https://news.hada.io/topic?id=1913
9. ICANN, .ORG 판매에 대해서 거부하기로 최종 결정 https://news.hada.io/topic?id=2001

 
Ruby 3.0.0 릴리즈

- Performance, Concurrency, Typing 개선이 주 목적
- Performance: Ruby 2와 비교해 3배 향상
- MJIT
- Concurrency
- Ractor (experimental): thread-safety 걱정 없이 parallel execution
- Fiber Scheduler: event loop (non-blocking execution)
- Typing (정적 분석)
- RBS
- TypeProf

전통대로 2.7이 릴리즈된 지 딱 1년만에 릴리즈된 모양이군요.
https://news.hada.io/topic?id=1149

위 글에서 주요 기능으로 소개된 RBS이란 것은 여기에도 소개 글이 올라온 적이 있습니다. 간단히 말해서 Type Annotation을 위한 DSL인 듯.
https://news.hada.io/topic?id=2560

최근에 여기 올라왔던 아래 글을 보고 루비 온 레일즈에 관심이 생기긴 했는데, 현실은 내년 초부터 기존에 안 써봤던 언어와 프레임워크로 진행되는 업무에 투입될 예정이라 그거 공식 문서와 튜토리얼이나 간간히 보는 게 전부네요.
https://news.hada.io/topic?id=3297

 
Hotwire : HTML Over The Wire

- 최신 웹페이지를 JavaScript와 JSON 전송대신, HTML을 직접 전송해서 만드는 방식
ㅤ→ 이메일 서비스 Hey의 프론트엔드에 사용
- 빠른 페이지로딩, 서버 렌더링, SPA의 속도와 반응성을 희생하지 않으면서 서버쪽에서 다양한 언어 사용 가능

Turbo + Stimulus + Strada
- Turbo : Hotwire의 핵심. 빠른 웹앱을 만들수 있도록 기술의 모음
ㅤ→ Turbo Drive : 모든 a 링크 클릭 및 form submit 을 fetch 로 변환해서 서버에서 읽어와 body를 교체. SPA처럼 동작하게 변경
ㅤ→ Turbo Frames : 복잡한 페이지를 프레임으로 분리해서 각각 로딩 및 렌더링. iframe과 비슷하지만 한개의 DOM에서 처리되는 가상 frame
ㅤ→ Turbo Streams : 페이지 변경사항을 Websocket으로 스트림 전송
ㅤ→ Turbo Native : Turbo의 방식을 iOS/Android 하이브리드 앱에 사용 가능하게 지원
- Stimulus : Turbo가 80%를 처리하고, 나머지 부분을 처리. 최소한의 JS프레임워크
- Strada : 웹 과 네이티브를 연결해주는 Bridge. 내년에 발표 예정

Hey의 기술스택이 공개되었을 때 https://news.hada.io/topic?id=2355
프론트엔드에 Stimulus, Turbolinks 외에 α 가 더 있다고 했는데 그게 이 Hotwire 인가 보네요

 
React Server Components 발표 (RFC)

- 서버 컴포넌트는 서버에서 실행되며 클라이언트 번들크기엔 변화 없음
- DB,파일시스템,마이크로 서비스등의 서버측 데이터소스에 접근가능
- 클라이언트 컴포넌트와 심리스한 연동
- 동적으로 렌더링할 클라이언트 컴포넌트를 선택 가능해서 최소한의 렌더링 코드만 클라이언트로 전송
- 서버 컴포넌트가 리로드 되더라도 클라이언트 상태를 유지
- 점진적으로 렌더링 되며, 조금씩 클라이언트에 UI를 스트리밍 가능해서, Suspense 와 연동하면 로딩상태를 마음대로 조작이 가능하고 가장 중요한 콘텐츠만 먼저 보인 후에 나머지 부분을 로딩하는 것이 가능
- 서버와 클라이언트 코드 공유 가능

 
simple-graph : SQLite를 Graph DB로 사용하기

- Nodes 와 Edges 로 구성된 간단한 Graph DB를 SQLite로 구현
ㅤ→ Node : id를 가진 JSON 객체
ㅤ→ Edge : id값들의 페어들. 방향 및 연결 속성을 위한 추가 JSON 객체 포함
- Python 스크립트로 Atomic Transaction 제공
- Graphviz 로 시각화 가능

SQLite를 도큐먼트DB로 사용하기 https://news.hada.io/topic?id=3271
위 글에서 영감을 얻었다고