[GN#61] 오픈소스 어플리케이션의 아키텍쳐

2020-08-31 ~ 2020-09-06 사이의 주요 뉴스들
건축가나 건축을 공부하는 사람들은 모두 다른 건물들을 보고 공부하고 그 비평을 연구하는 데 반해서, 소프트웨어 개발자들은 다른 위대한 프로그램을 잘 공부하지 않죠. 이걸 바꾸기 위해 만들어진 책이 AOSA(The Architecture of Open Source Applications) 입니다. 유명한 오픈소스가 어떻게 작성되었고, 그 개발과정에서 알게 된 교훈들을 정리해서 주니어 개발자부터 시니어들까지 모두 다양한 것들을 배울 수 있게 합니다. 이 책은 전체 내용이 무료로 공개되어서 웹에서 볼 수 있고, 1권은 번역도 나와있습니다. 마침 왜 소프트웨어 아키텍처가 중요한지 마틴 파울러가 설명한 동영상도 한글 자막버전이 올라왔으니 두 개의 링크를 묶어서 보시면 좋을 거 같아요.

월간 사용자 24억명의 페이스북은 서비스 규모에 맞게 수십만대의 서버를 운영하면서도 잦은 업데이트를 하는 것으로 유명한데요. 일주일에 100번 이상 배포가 진행되면서 서버 및 로드밸런서, 프록시등 더 많은 숫자의 머신들도 재시작이 되는데 이때 다운타임을 줄이기 위한 방법을 정리한 논문이 공개가 되었습니다. Blue/Green 배포, Rolling Updates, Hot Restart 세 가지 방식에 대해서 정리하고 여기서 발생하는 문제점들을 해결한 방식을 잘 설명하고 있어서 규모가 있는 서비스에서는 참고하시면 좋겠습니다.

오픈소스는 누구나 무료로 쓸 수 있다는 점에서 좋지만, 클라우드들이 서비스로 만들면서 오픈소스를 만드는 측이 아닌 클라우드 업체가 수익을 가져가게 되버리는 이슈가 생겼습니다. 많이 쓰시는 MySQL, MongoDB, ElasticSearch 들이 다 그런 사례인데요. 이에 Chef의 CTO는 오픈소스를 비즈니스화 할 때 Elastic/Nginx의 오픈코어 모델 보다는 RedHat 모델을 따르라고 설명하고 있습니다. 이 두 모델을 비교해서 알아두는 것은 드롭박스의 Nginx 와 Envoy 사례처럼 오픈소스 솔루션을 선택할 때 도움이 될 것 같습니다.


✓ 사내에서 슬랙을 쓰신다면 뉴스채널에 GeekNews SlackBot 을 추가하여 편하게 새 글을 받아보시고, 멤버들에게도 공유해주세요.
✓ 주위분들께 긱뉴스 위클리 - https://news.hada.io/weekly 를 추천해 주세요.
✓ 스팸함에 들어가지 않게 news@hada.io 를 주소록에 추가해주세요.
Twitter , Facebook 에서도 긱뉴스를 받아 보실 수 있습니다.
✓ 긱뉴스를 팟캐스트로 들어보세요 : 애플, 팟티에서 듣기, 팟빵, , 구글, 네이버 오디오클립, 유튜브

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


오픈 소스 어플리케이션의 아키텍쳐

건축가들은 수천개의 건물을 보고, 거장들이 만든 건물에 대한 비평들을 연구하는데요. 대다수의 소프트웨어 개발자들은 대게 직접 작성한 코드만 잘 알고, 역사적으로 위대한 프로그램들을 연구하지 않는다는 문제의식을 가지고 만든 페이지입니다. 그래서 그 분야의 전문가가 유명한 오픈 소스 어플리케이션을 하나씩 맡아 왜 이런 설계를 했는지 설명하였습니다.

대표적으로 Git, CMake, nginx, PyPy, GDB등 가장 유명한 오픈소스 프로젝트들을 다수 분석했으며. 각각의 항목을 누르셔서 웹 페이지에서 바로 보실 수 있습니다. 또한 종이책이나 PDF등으로 구매할 수 있습니다.

아래는 소개글의 전문입니다.

---

건축가들은 훈련하는 동안 수 천개의 건물들을 보고, 거장들이 만든 건물에 대한 비평들을 연구합니다. 대조적으로 대부분의 소프트웨어 개발자들은 소수의 대형 프로그램 ( 일반적으로 직접 작성한 프로그램 ) 만 잘 알고, 역사의 위대한 프로그램을 연구하지 않습니다. 결과적으로, 그들은 서로의 성공을 쌓기 보다는 서로의 실수를 반복합니다.

우리의 목표는 그걸 바꾸는 것입니다. 이 두 권의 책에서 40개의 오픈 소스 애플리케이션의 저자들은 소프트웨어가 어떻게 구성되었는지와 그 이유를 설명합니다. 각 프로그램의 주요 구성 요소는 무엇일까요? 그들은 어떻게 상호 작용할까요? 그리고 그들의 아키텍쳐는 개발 과정에서 무엇을 배웠을까요? 이런 질문에 답하면서, 이 책의 기고자들은 자신의 생각에 대한 독특한 통찰력을 제공합니다.

주니어 개발자이고 경험이 많은 동료들이 어떻게 생각하는지 배우고 싶다면 이 책들로 시작하기 좋습니다. 중급 또는 시니어 개발자이며, 다른 사람들이 어려운 디자인 문제를 어떻게 해결했는지 확인하려는 경우 이 책이 도움이 될 수 있습니다.

1권은 번역서도 있답니다~

http://aladin.kr/p/pG2qJ

처음으로 나오는 글은 '500라인, 혹은 더 적게' 라는 글인데요. 이 글들은 아키텍쳐와는 상관없지만, 500라인 안으로 웹서버나, DB나, 코드 하이라이트 같은 흥미로운 걸 만들 수 있는 글들입니다.

밑에는 본문의 내용인 오픈 소스 어플리케이션의 아키텍쳐가 나와있고, 볼륨 2개로 나눠져 있습니다. 모든 내용은 웹 페이지에서 제한없이 엑세스 할 수 있고. 만약 책으로 가지고 싶으시다거나, 돈으로 후원을 해주시고 싶으시면 PDF나 책을 구매할 수 있습니다.

구매 페이지의 특징은 '여기서 사면 우리는 얼마를 받을 수 있어'라는 걸 상세하게 적었다는 건데요. 독특한 것 같습니다.

 
[동영상] 마틴 파울러가 말하는 소프트웨어 아키텍쳐의 중요성 [번역]

마틴 파울러(Martin Fowler)가 OSCON 2015 컨퍼런스의 둘쨋날에 소프트웨어 아키텍쳐의 중요성을 14분간 강연하였는데, 여기에 자막을 붙여 번역한 영상입니다. (자막 한국어)

마틴 파울러는 GoF 중 1명인 랄프 존슨(Ralph Johnson)과 이메일로 토의한 내용을 공유하며, 기존에 통용되던 [소프트웨어 아키텍쳐] 개념의 지나친 일반화를 비판합니다. 그리고 소프트웨어 프로젝트에서 개발자들이 해당 프로젝트에 관해 공유하는 지식의 깊이가 중요하다는 점과 아키텍쳐에 관한 결정은 변경하기 어렵다는 점을 고려할 때, 아키텍쳐 설계에서 가장 중요한 것은 프로젝트의 핵심 가치를 위한 여러 결정사항들임을 지적합니다.

그리고 또 하나, 프로젝트에서 코드의 품질이 뒷전이 되는 경향에 대해서도 지적합니다. 이는 어찌 보면 당연한 것인데, 그 이유는 실제로 그 소프트웨어에 돈을 내는 고객의 입장에서는 코드의 질이 눈에 보일 리가 없기 때문이지요. 마틴 파울러는 소프트웨어의 품질은 외적 품질(External Quality)과 내적 품질(Internal Quality)로 나뉜다며, 사용자에게 노출되는 UX나 버그 같은 결함은 외적 품질이고 코드의 품질은 사용자가 볼 수 없는 내적 품질이라고 말합니다. 소프트웨어 아키텍쳐는 내적 품질과 관련된 것인데, 이는 직접 보이는 것이 아니므로 사용자 입장에서는 같은 기능이면 더 싼 쪽을 택하는 것이 당연하다는 것입니다. 하지만 내적 품질이 좋지 않은 소프트웨어는 기능 추가나 개선 등 고도화에 그만큼 큰 비용이 들게 됩니다. 반면 내적 품질이 좋은 소프트웨어는 소스 코드가 플랫폼화하기 때문에 장기적으로 볼수록 기능 추가가 쉽고 빠르게 가능하게 되지요. 마틴 파울러는 이를 ‘디자인 스태미너 가설’이라고 이름붙였습니다. 지속적인 기능 추가야말로 바로 소프트웨어 아키텍쳐가 중요한 이유라는 것이 그의 주장입니다.

강연 중간에 나왔던 칼럼의 PDF 파일:
https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

OSCON 2015 당시의 기사:
https://opensource.com/life/15/…

 
페이스북의 다운타임 없는 릴리즈 방법에 대한 논문

Zero Downtime Release: Disruption-free Load Balancing of a Multi-Billion User Website

요약 설명
- 서버는 종종 재시작 됨 : 업그레이드, 버그픽스, 보안패치
- Continuous Release 의 도입으로
ㅤ→ 페이스북의 경우 2007년에 일주일에 1번이던게, 일주일에 100번 이상 배포 진행
ㅤ→ 수백만대의 서버가 매일 재시작
ㅤ→ AWS,아틀라시안,옐프,Ebay,우버 모두 마찬가지
ㅤ→ 헬스체크가 간헐적으로 실패하게 됨
- 전통적인 배포 방법
ㅤ1. Blue/Green 배포 (AWS CodeDeploy, Kubernetes) : 두개의 머신군으로 나누고 로드밸런서가 업데이트 먼저 한쪽으로 트래픽을 이관
ㅤㅤ→ 비용이 많이 듬. 수많은 머신들이 있는 Edge에는 부적합
ㅤ2. Rolling Updates (Envoy, NGINX, Apache, Kubernetes, AWS) : 한대씩 점진적으로 업데이트 하면서 로드밸런서가 트래픽을 조정
ㅤㅤ→ 업데이트 기간동안 CPU사용량이 적어지고, 느린 이터레이션.
ㅤ3. Hot Restart (HAProxy, Envoy) : 한 머신내에서 새로운 버전의 프로세스를 띄우고 기존 프로세스 트래픽이 점차 종료되면 새 프로세스가 트래픽을 받음 (SO_REUSEPORT, CMSG, SCM_RIGHTS)
ㅤㅤ→ TCP에만 가능하고 UDP는 잘못된 라우팅 발생 가능

"어떻게 하면 릴리즈 업데이트를 다운타임 없이, 빠른 이터레이션으로, 중단없이 진행할수 있을까?"

* 페이스북의 Traffic Infrastructure
ㅤ- Edge PoP(L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)
ㅤㅤ→ 티어별로 리스타트해서 중단을 방지
ㅤㅤ→ Edge 와 Data Center 의 머신은 각각 새 ProxyGen을 띄워서 "Socket TakeOver"
ㅤㅤ→ Edge 와 Data Center 간의 "Downstream Connection Reuse"
ㅤㅤ→ Data Center 와 App Server 강의 연결은 "Partial Post Replay"

ㅤ- Socket Takeover : 새로운 프로세스를 띄워서 SCM_RIGHTS 와 CMSG로 TCP Listening , UDP VIP 소켓을 넘겨 받음
ㅤㅤ→ SCM_RIGHTS : 다른 프로세스의 File Descriptor 를 넘겨 받게 해주는 소켓 타입
ㅤㅤ→ CMSG : sendmsg() 기능으로 로컬프로세스 간에 제어 메시지를 전송할수 있게 해줌
ㅤㅤ→ UDP 기반 커넥션인 QUIC을 위해서 기존 커넥션의 경우는 새 프로세스가 기존 프로세스에게 QUIC ConnectionID를 물어서 해당 패킷을 기존 프로세스로 포워딩

ㅤ- Partial Post Replay ( App 서버 재시작 )
ㅤㅤ→ App 서버는 두가지의 워크로드가 존재 : 짧은 API 호출, 긴 HTTP POST 호출 (Upload)
ㅤㅤ→ 이 앱서버는 가용 자원이 없기 때문에 Socket Takeover 가 하는듯이 새로운 인스턴스를 띄워서 소켓 넘기는게 불가능하고, 긴 업로드 시간도 문제
ㅤㅤ→ 긴 업로드 중간에 앱서버가 업데이트 되면 프록시가 그 내용을 다 가지고 있지 않기 때문에, 해당 POST를 중단하면서 379코드와 함께 지금까지 받은 데이터를 다시 프록시로 리턴
ㅤㅤ→ 프록시는 기존 앱서버로 부터 받은 데이터와 남은 데이터를 합쳐서 다시 새 머신으로 재 전송 시도

* Zero Downtime Release의 장점
ㅤ→ Rolling Update 대비 20% 정도 높은 CPU 사용량
ㅤ→ Hot Restart 가 QUIC 패킷을 20K까지 미스라우팅 했던 거에 비해 거의 미스라우팅이 없음

ㅤ→ 페이스북 내에서 Socket TakeOver는 2013년부터, 나머지는 2015년 부터 사용 중

위 내용은 이 20분짜리 설명 동영상을 기반으로 요약한 것입니다 https://dl.acm.org/action/downloadSupplement/…
ProxyGen : 페이스북의 C++ HTTP Library https://github.com/facebook/proxygen

 
오픈소스를 비즈니스화 하는 법

클라우드 서비스들이 오픈소스를 가져다 "as a service"로 만들면서 아무런 비용도 내지 않는 상황에 최근 오픈소스들이 라이센스 변경 또는 배포 모델을 변경하는 방식으로 대응 중.
이에 대한 Chef 전 CTO의 비즈니스화 방법 조언

Elastic은 코드를 덜 오픈소스화 하는 방식으로 바꿔서 일부 컴포넌트가 독점이고, 이를 분리하기는 까다로움 ⇨ Open Core 모델
Chef 는 완전히 오픈이지만, Chef 이름을 트레이드 마크화 하고 그거는 못쓰게 변경 ⇨ Redhat 모델
ㅤ→ Chef는 기존 Open Core 모델에서 RedHat 으로 바꾼 것

Chef의 CTO였던 Adam Jacob의 조언은 오픈 코어보다 RedHat 모델이 훨씬 좋다는 것
( Chef에 한해서 일수도 있음. 그리고 그는 저 라이센스 모델 변경전에 퇴사했음 )

1) 100% 오픈소스 코드 기반의 제품을 만들 것
ㅤ→ 이렇게 하면 회사가 해당 오픈소스 코드 커뮤니티의 일부가 됨.
ㅤ→ 오픈코어 방식에서는 기존 커뮤니티 위에 있게 되고, 커뮤니티에서 도움받기는 어려워짐
ㅤ→ Adam은 13년동안 왜 상용버전의 Chef가 오픈소스 버전가 다른지를 설명해야 했음. RedHat 모델 에서는 그게 필요없음

2) 트레이드 마크로 등록하고 그 제품의 유일한 배포자가 될것. 비즈니스도 다 내꺼
ㅤ→ 이것은 Supply Chain을 회사가 가지게 된다는 것
ㅤ→ Supply Chain : 소스 버전관리, 커밋, QA, 빌드 파이프라인, 자료 호스팅, 마케팅, 영업팀 등등
ㅤ→ 즉 코드를 뺀 나머지 모든 노력을 회사가 하고 가치를 부여함

3) 대체 배포본을 만드는 사람들을 격려하고 협업 할 것
ㅤ→ 이것이 건강한 커뮤니티를 만듬

아마존이 MySQL,MongoDB,Elastic Search 등을 가져다 서비스로 만들면서 이슈가 되어서 아래처럼 라이선스 변경도 이루어지고 있습니다.

ㅤ→ CockroachDB 라이센스 변경 - 오픈소스지만 상업화는 안됨 https://news.hada.io/topic?id=7
ㅤ→ Sentry, BSL(Business Source License)로 오픈소스 라이센스 변경 https://news.hada.io/topic?id=870

드롭박스가 Nginx 에서 Envoy 로 전환한 이유 https://news.hada.io/topic?id=2625
위 글에서도 보면 Adam의 1)번 조언처럼 Nginx 는 오픈코어 모델, Envoy 는 완전한 오픈모델이어서 기여하기가 더 자유로웠다는 얘기를 해요.

 
시니어 개발자처럼 VSCode 사용하기 [번역]

VSCode 기능으로 생산성 높이기
- 멀티 커서
- Symbol 이름 일괄 바꾸기
- 행 단위 위아래 이동
- 사용자 정의 스니펫 설정 : 반복코드 자동생성
ㅤ→ 설정 파일 생성
ㅤ→ 스코프 설정
ㅤ→ 커서 이동

같은 분이 번역하신 "시니어 프론트엔드 개발자처럼 크롬 개발자도구 사용하기"
https://junwoo45.github.io/2020-07-28-chrome_devtools/

내가 시니어 개발자에게 1년간 배운 것들 https://news.hada.io/topic?id=414
시니어 엔지니어로 넘어가기 위한 기술: 코드 읽기 https://news.hada.io/topic?id=2390
Senior 소프트웨어 엔지니어의 체크리스트 https://news.hada.io/topic?id=500

 
좋은 Microcopy를 위한 팁

* Microcopy : UX에 영향을 주는, 제품/서비스에 사용하는 작은 문구들

1) 사용자에게 말하는 것처럼
ㅤ$50 was sent to Max → You sent $50 to Max
2) 대화형 요소들은 동사로 시작
ㅤThe Plans → Choose your plan
3) 사용자의 우려를 방지
ㅤYou won't be charged until your trial ends
4) 친숙한 용어 사용
ㅤAn error occurred → Something went wrong
5) 능동태 사용이 기본
ㅤA comment was made by Sophie → Sophie made a comment
6) 유용한 에러 메시지 보이기
ㅤLog in failure → We couldn't find an account with that email. Try again or Recover password
7) 반복하기 : 계속 테스트하며 수정할 것
ㅤGet Started → Start a free trial → Create account

일반적인/쉬운 영어로 글쓰는 방법 https://news.hada.io/topic?id=2716 와도 겹치는 내용이 많네요.
→ 문장은 짧게, 능동형으로, You와 We사용, 독자에게 맞는 단어 선택, 지시하는걸 두려워하지 말 것

다만 6번의 경우는 예제가 약간 문제가 있을 수도 있는게
그 이메일 주소로 가입된 계정이 없다는 것을 알려주는 것 자체도 보안 이슈가 있을 수 있습니다.
저 경우는 "계정 오류입니다. 다른 이메일 주소 또는 암호 찾기를 해보세요" 정도로 뭉뚱그리는게 맞을거 같아요.

 
Responsively - 반응형 웹페이지 테스팅 도구 오픈소스

- Instant Preview : 여러개의 폰/패드 사이즈 화면을 한번에 같이 표시
ㅤ→ 스크롤,클릭이 모든 화면에 실시간 미러링
ㅤ→ 한번에 모든 기기별 스크린샷 저장
- 윈/맥/리눅스
- 하나의 구글 크롬 Inspector 로 모든 화면에 같이 사용 가능
- 30개 이상의 주요 기기정보 내장 및 추가 가능
- Hot-Reloading 지원
- 프리뷰 레이아웃을 맘대로 조정 가능
- 크롬/FF/Edge 에서 링크를 바로 보낼수 있는 확장 제공

 
Vimac - 키보드로만 macOS 사용하기

- 크롬브라우저를 키보드로만 vi처럼 사용할수 있게 하는 Vimium 확장을 macOS에서 똑같이 구현
ㅤ→ Ctrl+Space 를 누르면 모든 컨트롤에 단축키 힌트가 보이고 키를 눌러서 선택(클릭) 가능
ㅤ→ Shift+Hint 우클릭
ㅤ→ CMD+Hint 더블클릭
ㅤ→ Ctrl+S HJKL 로 스크롤, D/U로 페이지 업다운

써보고 있는데 예전에 나온 비슷한 도구들보다 훨씬 좋은 느낌입니다. 오래 쓰고 싶은 마음이 드네요.

Vimium for Chrome https://chrome.google.com/webstore/detail/…
Vimium 단축키 설명은 https://github.com/philc/vimium/blob/master/README.md

 
타워 디펜스로 배우는 CSS FlexBox

- 몰려오는 적들을 공격하는 타워를 CSS로 위치시켜서 막아내는 게임
- 총 12개의 Wave
- display: flex 의 다양한 속성 값들 익히기
ㅤ→ justify-content : flex-start, flex-end, center, space-between, space-around
ㅤ→ align-items & align-self
ㅤ→ flex-direction : row, row-reverse, column, column-reverse

 
대규모 환경에서 레디스 캐시 성능을 높이기

레디스(Redis)는 온라인 서비스의 캐싱에 널리 쓰이는 인메모리(In-Memory) 데이터베이스입니다. 하지만 잘못 사용할 경우 예상치 못한 문제가 생기거나 심지어 큰 장애가 발생할 수도 있죠. 제가 최근에 서점에 갔다가 우연히 모 기업의 SRE팀에서 일하는 현업 엔지니어와 만났는데, 대화 중에 그 분이 “레디스는 사실 필요악이다. 언젠가는 관련 장애가 한번쯤 터질 거라고 생각하면서 써야 한다.”고 말할 정도인 모양이더라고요.

참고 - 카카오 "레디스, 잘못쓰면 망한다":
https://zdnet.co.kr/view/?no=20131119174125

참고 - 쿠팡 오류 원인은 오픈소스 '레디스 DB' 때문:
http://www.digitaltoday.co.kr/news/articleView.html?idxno=212904

이렇듯 레디스는 잘 알고 섬세하게 사용해야만 하는 물건입니다.

서론이 길었습니다. NHN에서 RedisConf 2020의 발표 내용을 바탕으로 대규모 트래픽 환경에서 레디스를 캐시로 사용할 때 성능 이슈가 발생할 수 있는 부분을 3가지 지적하고, 그 해결법을 설명한 문서를 소개합니다. (한국어)

* Cache Stampede: 캐시 공간은 한정되어 있으므로 저장된 데이터에 만료시간(TTL)을 정하는 것이 보통인데, 해당 데이터에 계속 읽기 요청이 들어오고 있을 때 캐시 만료시간이 닥치면 순간적으로 DB에 그 읽기 요청이 집중되고 그게 다시 레디스에 중복된 쓰기 요청으로 몰리게 됩니다. 이를 캐시 스탬피드(Cache Stampede)라 부르는데, 해결방법으로는 확률분포에 기반한 알고리즘으로 TTL값을 미리 갱신하거나 혹은 디바운스(Debounce, 여러 번 반복되는 이벤트 중 마지막 이벤트만 실행하기) 개념을 도입하는 방법이 있습니다.

* Hot Keys: 하나의 키에 읽기가 집중될 때도 성능이 떨어질 수 있습니다. 위 글에서는 그 대책으로 키 이름 앞에 Prefix를 붙여 여러 복제본을 만든 뒤, 그 Prefix가 붙은 복제본에 랜덤으로 읽기를 분산시키는 방법을 소개하고 있습니다.

* Compression: 크기가 큰 데이터를 레디스에 저장할 때도 성능 저하가 발생할 수 있습니다. 이때 적절한 압축을 적용하는 것만으로도 속도와 메모리 사용량에서 큰 이득을 볼 수 있습니다. 적절한 압축 방법과 비율은 상황과 환경에 따라 다를 수 있기 때문에, 이를 적용할 때는 사용 환경을 재현한 벤치마크 테스트가 필수입니다.

참고 - 위에서 언급된 확률분포 기반 알고리즘(Probablistic Early Recomputation)의 예제 코드가 나오는 글:
https://engineering.linecorp.com/ko/blog/…

 
htop 3.0 릴리즈

- 인터랙티브 프로세스 뷰어
- 원 개발자가 장기간 비활동중이라 커뮤니티가 넘겨받아 진행. 2년만에 메이저 버전업
- 주요 변경
ㅤ→ ZFS ARC 통계지원
ㅤ→ vim 스타일 키매핑 모드
ㅤ→ 리눅스 PSI* / PSS* 메트릭 지원
ㅤ→ 2개 이상의 더 작은 CPU 미터 컬럼 지원
ㅤ→ CPU 미터에서 프리퀀시 표시 가능

* PSI(Pressure Stall Information) : 메모리,CPU,IO 자원에 대한 압력(자원이 많이 할당되어 태스크에 지연이 발생되는지)에 대한 정보를 제공하는 지표
ㅤ→ 10초, 1분, 5분단위 평균 과 누적 ms 총합
ㅤ→ some (메모리,IO,CPU) : 하나 또는 그 이상의 프로세스가 자원이 부족해서 딜레이가 발생한 시간
ㅤ→ full (메모리,IO) : 모든 태스크가 자원부족으로 딜레이가 발생한 시간 (완전히 아무것도 못하는 시간)
ㅤ→ full 값이 높다면 자원부족으로 전체 처리량에 손실이 발생하고 있다는 것

* PSS(Proportional Set Size) : 프로세스가 램에서 혼자 차지하는 메모리 영역(Page)과 다른 프로세스와 공유하는 메모리 영역의 비율.
ㅤ→ 한 프로세스가 자기 혼자 100페이지를 차지하고, 다른 프로세스들과 100페이지를 공유한다면 PSS는 150

원 개발자의 Thank you to Community 메시지 https://github.com/hishamhm/htop/issues/992#issuecomment-683286672
ㅤ→ 취미로 시작해서 15년 동안 유지보수 해와서 약간 멀어졌었는데 이렇게 커뮤니티가 해줘서 고맙다고

시스템 모니터 htop 의 모든것 https://news.hada.io/topic?id=913

* Getting Started with PSI https://facebookmicrosites.github.io/psi/docs/overview

 
ActivityWatch - 나는 하루 종일 무슨 일을 할까

- 내가 컴/폰에서 어떤 행동을 하는지 모두 기록하는 트래커
- 오픈소스, 보안 우선, 크로스 플랫폼(윈/맥/리눅스/안드로이드)
ㅤ→ 어떤 앱을 얼마나 언제 사용하는지 (앱/타이틀)
ㅤ→ 브라우저 확장으로 웹에서 뭘 하는지 (자주 가는 도메인)
ㅤ→ 에디터 워쳐로 코딩을 얼마나 하는지
ㅤ→ 카테고리별로 사용을 분류
- 사용 용도
ㅤ→ 생산성 모니터링
ㅤ→ 워라밸 측정
ㅤ→ 디지털 라이프 로깅

 
2020년과 이후 JavaScript의 동향 - WebAssembly

- W3C는 wasm을 HTML, CSS 그리고 JavaScript에 이어 웹의 4번째 언어로 공식 권고
- wasm은 LLVM(컴파일러 기반 구조) 지원 언어가 모두 웹에서 사용될 수 있게 컴파일되는 Polyglot
ㅤ→ 실제로는 네이티브 코드를 웹에서 실행하게 해주는 도구에 더 가깝다
- 미래 버전에 포함될 작업
ㅤ→ Threading, Fixed-width(128-bit packed) SIMD, Rererence types, Tail calls, ECMAScript module integration
- wasm은 JavaScript에 비해 왜 더 빠를까
- 브라우저/JavaScript 엔진의 wasm 지원 동향
- Bytecode Alliance

위 글 속에 나오는 Nanoprocess 보안 모델에 관해 찾아보았습니다. 위 글에 링크된 동영상을 강연한 발표자가 그 내용을 그대로 모질라 블로그에도 올려 두셨더군요. 저는 동영상보다 글이 더 편해서, 이걸 보고 나서야 대충 이해했습니다. 결국은 세분화된 권한 부여가 핵심이네요.
https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/

 
사용자 암호 변경용 well-known URL 추가하기

- 패스워드 관리자등 사용시, 암호에 대한 변경요청을 할 때 편하게 보낼수 있는 URL을 추가하기
ㅤ→ /.well-known/change-password 를 서비스의 암호요청 페이지로 redirect(302,303,307 등 HTTP코드 사용)
- 암호 변경 페이지를 좀 더 쓰기 쉽게
ㅤ→ 기존 암호 필드에 autocomplete="current-password" 를 추가 : 패스워드 관리자가 현재 암호를 자동으로 채우게
ㅤ→ 신규 암호 필드에는 autocomplete="new-password" 를 추가 : 패스워드 관리자가 새로운 암호를 제안
- 이 스펙은 Draft 제안 상태이지만, Safari 13이 이 스펙을 지원(제안자가 애플소속)
- 이미 구글,깃헙,페이스북,트위터,워드프레스 사이트는 이 URL을 지원하고 있음

긱뉴스도 이미 지원합니다! ^_^

 
Google People + AI Guidebook 소개 및 번역

(나온지 좀 되긴 했지만) Google PAIR 팀에서 공개한 People + AI 가이드북을 번역해 보았습니다.

UX 전문가 및 제품 매니저들이 사람 중심의 AI 제품을 디자인하는데 필요한 내용들을 담고 있고, RUN이라는 가상 달리기 앱을 통해 여러 예시를 보여주고 있어 AI 기반 앱을 기획/서비스할 때 유용해 보입니다.

챕터별 제목은 다음과 같습니다:

1. 사용자 요구 + 성공 정의
2. 데이터 수집 + 평가
3. 멘탈 모델
4. 설명가능성 + 신뢰
5. 피드백 + 제어
6. 에러 + 우아한 실패

번역본 링크는 댓글을 참고해 주십시오.

https://drive.google.com/drive/folders/…

 
8월30일 CenturyLink/Level(3) 인터넷 다운상황 분석

- 어제 오후 대규모 인터넷 장애에 대한 분석
- 처음엔 CloudFlare쪽 문제로 알려졌지만, 밝혀진건 세계 최대 ISP중 하나인 CenturyLink측 장애
- 잘못된 Flowspec 업데이트로 BGP (Border Gateway Protocol)에 문제 발생
ㅤ→ Flowspec은 BGP의 확장으로 방화벽 룰이 빠르게 네트웍에 전파되도록 하는 도구
ㅤㅤ(Cloudflare는 7년전에 Flowspec 으로 장애를 낸적이 있어서 더 이상 사용하지 않는다고)
ㅤ→ 보통 1.5~2MB 정도인 BGP 업데이트가 해당 Flowspec 이 포함되면서 갑자기 20M이상으로 넘어가면서 문제 발생

- 복구에 4시간이나 걸린 이유에 대한 CloudFlare의 추측
ㅤ→ Flowspec룰 때문에 대용량 BGP 업데이트가 생기면서 라우터에 접근이 불가능 했을 것
ㅤ→ 아마도 이 Flowspec룰이 CentryLink가 아닌 그들의 고객으로 부터 나오면서 문제가 발생해서 원인 찾기가 어려웠을 것
ㅤ→ 미국시간 일요일 오전에 일이 발생했고, 게다가 CenturyLink/Level(3) 네트웍이 너무 크고 복잡해서

- 어제 이 네트웍 장애로 LoL과 PSN,Xbox Live,Steam,WoW 등의 수 많은 온라인 게임 접속이 불가

BGP는 안전한가요? https://news.hada.io/topic?id=1932

 
잘 안려진 10개의 Web API들

브라우저별로 지원이 좀 미흡하지만, 사용 가능한 API 설명과 예제들
- Fullscreen API
- Clipboard Async API
- Resize Observer API
- Image Capture API
- Broadcast Channel API
- Performance Interface API
- Battery Status API
- Network Information API
- Vibration API
- Bluetooth API

그외

- Payment Request API
- Touch Events
- Page Visibility
- Channel Messaging API

많은 API가 주로 크롬에서만 동작하긴 합니다.
현재 Firefox 에서 가능한건 Fullscreen, Image capture, Resize observer, Broadcast Channel 정도 입니다.
Bluetooth 와 Battery API는 FF/Safari 에선 지원 안하겠다고 했습니다.

https://whatwebcando.today/ 에 접속하면 현재 브라우저에서 이런 것들을 지원하는지 한눈에 보여줍니다.

 
사람들은 구글 검색을 어떻게 사용하는가

1801명 대상의 구글 검색 사용시 행동 조사 결과

1. 검색어 자동완성 사용율은 23%
2. 50%의 사용자가 9초 내에 결과를 클릭. 클릭에 걸리는 시간은 평균 14.6초
3. 9%의 사용자만 첫페이지 마지막까지 내려감
4. 15%의 사용자만 자신의 첫 검색어를 수정
5. 17%의 사용자가 다시 결과창으로 돌아옴. 5% 사용자만 같은 쿼리에 대해 여러번 돌아옴
6. 59%의 사용자가 검색에 대해 한개의 페이지만 방문. 6% 정도만 답을 찾기위해 4개 이상의 페이지 방문
7. 65%의 사용자가 10개의 Blue Link(광고가 아닌 오거닉 검색 결과 링크) 중 하나를 클릭
8. 19%의 사용자가 구글 광고를 클릭 (쿼리에 따라 다름)
9. 지역검색에 대해서는 42%의 사용자가 구글지도 에 있는 결과를 클릭
10. 제품을 검색하는 사용자의 19%가 구글 쇼핑 결과를 클릭
11. 평균적으로 3%정도의 사용자만 "People Also Ask(관련 질문)" 박스안의 내용을 사용
12. 44%의 사용자만 두번째 검색결과 페이지로 감
13. 평균적으로 검색 세션은 약 76초. 모든 검색 세션의 절반은 53초 안에 끝남

 
리눅스 커널 개발 시작하기

오라클의 리눅스 커널 개발자 Vegard Nossum가 쓴 리눅스 커널 개발 프로세스에 대한 글
커널을 개발하기 전에 필요한 선행 지식, 커널에 관한 자료들, 커널을 처음 개발할때 시작하기 좋은 곳, 메일링 패치 보내는 방법 등을 정리

 
file-type - Buffer안의 파일 타입 알아내기

- 매직넘버*로 파일타입을 감지, Promise를 리턴하는 JS라이브러리
ㅤ→ .fromBuffer : Buffer/Uint8Array/ArrayBuffer
ㅤ→ .fromFile : 경로명
ㅤ→ .fromStream : Node.js 스트림
ㅤ→ .fromTokenizer : ITokenizer - @tokenizer/http , @tokenizer/s3 등으로 원격 파일 체크
- 약 120여종의 파일타입 지원
ㅤ→ jpg/png/gif/webp/tif/bmp/ico/psd/ai/skp/avif
ㅤ→ zip/tar/rar/gz/7z/dmg/lzh
ㅤ→ mp4/mkv/webm/mov/avi/wmv
ㅤ→ mp3/ogg/flac/wav/wma/ac3
ㅤ→ pdf/epub/mobi/ps/eps
ㅤ→ exe/swf/flv
ㅤ→ rtf/docx/pptx/xlsx/odt/ods/odp
ㅤ→ ttf/otf/woff/woff2
ㅤ→ ics
ㅤ→ pcap

* 매직넘버 : 파일을 구분하기 위해 파일 앞부분에 넣어두는 특정 값들. 초기 유닉스에서는 2바이트 정도만 쓰였으나 요즘은 앞부분 여러개의 바이트를 사용하기도
ㅤ→ 자바 .class 파일은 "CAFEBABE" 로 시작
ㅤ→ GIF89a 는 ASCII코드 "GIF89a"로 시작 : 47 49 46 38 39 61
ㅤ→ JPEG 은 "FF D8" 로 시작해서 "FF D9"로 끝남
ㅤ→ 유닉스/리눅스 스크립트 파일은 "#!"
ㅤ→ PDF 파일은 "%PDF"
ㅤ→ ZIP 파일은 "PK"로 시작 - 도스용 PKZIP 개발자 Phil Katz를 따서

 
Bootstrap Icons v1.0.0 정식 공개

- Bootstrap과 함께 또는 별도로 사용가능한 아이콘 1100+개
- SVG로 되어있어서 CSS로 스타일링 가능
- MIT 라이센스
- Figma용도 별도로 배포
- 1.1.0 에서 200+개 추가하고 계속 유지보수 예정

다른 SVG 아이콘들

Teenyicons - 15x15 초소형 무료 아이콘들 587개 https://news.hada.io/topic?id=2633
Tabler icons : 24x24 고품질 무료 SVG 아이콘 550개 https://news.hada.io/topic?id=2427
Heroicons - Tailwind CSS 개발자들이 만든 아이콘 모음 226개 https://news.hada.io/topic?id=2731

 
왜 CSS ::before 는 input과 img에는 동작하지 않을까

- ::before 와 ::after 는 replaced elements에는 동작 하지 않음
ㅤ→ audio, canvas, embed, iframe, img, input, object, video
- 이 개체들은 HTML스펙상 브라우저에 의해 ::before, ::after를 다 포함해서 대체되기 때문에 동작하지 않는 것
ㅤ→ img 는 상황에 따라 동작하기도 함 (FF/크롬에서 이미지 로딩 실패시 )
ㅤ→ input 은 종류에 따라 동작하기도 함 (크롬/사파리 는 체크박스와 라디오에는 동작 )

 
OctoLinker - 깃헙에서 include문을 링크로 변환해주는 크롬확장

- GitHub에서 include/require/import 문장의 파일을 링크로 변환
- 마크다운, 이슈 및 PR, 커멘트 내용에서도 지원
- Repo 내부 및 외부 라이브러리도 연결
- 다양한 언어 및 환경 지원
ㅤ→ JavaScript, TypeScript, HTML, CSS, Java, Ruby, Rust, Python, Go, Haskell
ㅤ→ Node.js, Deno, Composer, Docker, npm, Homebrew, RubyGems, less, Sass, vim
- package.json, composer,json, Gemfile, requirements.txt 안에서도 외부 라이브러리들을 찾아서 링크 연결

 
Minglr - 컨퍼런스후 참가자 끼리의 대화를 온라인으로

- Mingling (여기저기 돌아다니면서 대화하는 것) 을 Jitsi를 이용해서 온라인으로 구현한 오픈소스
- 참여자 리스트를 보고 선택해서 대화 가능
ㅤ→ 대화하고 싶다고 선택하면 나와 대화하고 싶은 사람들 리스트에 보임. 거기서 클릭하면 대화 시작
- 자기 이름/소속 소개 및 관심 분야 기록 가능

코로나로 온라인 컨퍼런스가 많아지지만, 오프라인 참석할 때와 같은 밍글링 경험은 주기 힘든데 그걸 구현하려고 시도해본거네요.
사람이 많으면 좀 문제긴 하겠지만 괜찮은 것 같습니다.

 
bref - AWS Lambda에서 PHP 사용하기

- Composer 패키지로 제공되는 Lambda용 PHP 런타임
- Serverless 프레임워크와 연동하여 쉽게 PHP코드를 람다에 배포
- API/워커/배치프로세스/웹사이트 등 다양한 종류의 PHP 어플리케이션 가능
- Laravel, Symfony 등 프레임워크 지원
- Lambda layers 기반으로 여러 런타임 제공
ㅤ→ 간단한 함수용 php-74
ㅤ→ HTTP호스팅과 비슷한 웹사이트용 php-74-fpm
ㅤ→ 심포니/라라벨 콘솔욜 console
ㅤ→ 아직 실험적인 php-80

 
넷플릭스, 비가입자용 무료 시청 페이지 오픈

- 가입 필요없이 광고를 보면 몇몇 넷플릭스 오리지널들을 감상 가능
- 영화는 전체, 드라마는 시즌의 첫편
- 30초 광고는 스킵 가능
- 감상 가능: 기묘한 이야기, 엘리트들, 버드박스, 두 교황, 우리의 지구, 그레이스 앤 프랭키, 그들이 우리를 바라볼 때, 머더 미스터리, 보스베이비

 
JavaScript 번들러로 본 조선시대 붕당의 이해

JavaScript 모듈 표준화의 제안부터 현대 모듈 번들러 등장까지의 역사를 정리
동인(CommonJS),서인(AMD),남인(UMD),예송논쟁(ES6),노론(Grunt,Gulp),실학(TypeScript),사도세자(Webpack) 등을 이용해서 모듈 관련 흐름을 소개

재밌고 쉽게 설명한 글이네요! 도움이 되었습니다. 내용은 조선시대 붕당사로 보는 Javascript 번들러의 이해 같아요. ㅎㅎ

같이 읽어보면 좋은 글

- Node 모듈은 전쟁중 : CommonJS vs ESM https://news.hada.io/topic?id=2606

그리고 Rollup 을 이용한 빌드도구 Snowpack

- Snowpack - 웹앱을 번들러 없이 빠르게 빌드해주는 도구 https://news.hada.io/topic?id=1267
- Snowpack 2.0 릴리즈 https://news.hada.io/topic?id=2174

 
Gatus - 오픈소스 웹서비스 헬스 대쉬보드

- 서비스가 정상 작동중인지 체크하고, 보여주는 웹 대쉬보드
- Go로 작성된 도커 이미지
- Slack 으로 알림 지원, 커스텀 URL 호출가능
- 헬스체크시 body/header 설정 가능하며, GraphQL 호출도 가능