[TechNews] 유용한 개발 관련 아티클 및 영상 #28

 

 

1. 유용한 개발 관련 아티클 및 영상 #28

---

스프링 톰캣 스레드 풀의 동작 방식과 Connector

• 톰캣 스레드 풀의 동작 방시
  1. 첫 작업이 들어오면, core size만큼의 스레드를 생성함
  2. 유저 요청(Connection, Server socket에서 accept한 소캣 객체)이 들어올 때마다 작업 큐(queue)에 담아둠
  3. core size의 스레드 중, 유휴상태(idle)인 스레드가 있다면 작업 큐에서 작업을 꺼내 스레드에 작업을 할당하여 작업을 처리함
     1. 만약 유휴상태인 스레드가 없다면, 작업은 작업 큐에서 대기함
     2. 그 상태가 지속되어 작업 큐가 꽉 찬다면, 스레드를 새로 생성함
     3. 3번과정을 반복하다, 스레드 최대 사이즈 에 도달하고 작업큐도 꽉 차게 되면, 추가 요청에 대해선 connection-refused 오류를 반환함
  4. 태스크가 완료되면 스레드는 다시 유휴상태로 돌아감
     1. 작업큐가 비어있고 core size 이상의 스레드가 생성되어있다면 스레드를 destory함
• BIO Connector와 NIO Connector
  • BIO Connector
    • Socket Connection을 처리할 때 Java의 기본적인 I/O 기술을 사용함
    • conneciton이 닫힐 때까지 하나의 thread는 특정 connection에 계속 할당됨
    • 따라서 thread 수가 동시 접속할 수 있는 사용자의 수임
  • NIO Connector
    • I/O가 아니라 Http11NioProtocol을 사용하는데, 이는 NIO 기반임
    • NIO Connector에선 Poller라고 하는 별도의 스레드가 커넥션을 처리함
    • Poller는 Socket 들을 캐시로 들고 있다가 해당 Socket에서 data에 대한 처리가 가능한 순간에만 thread를 할당하는 방식을 사용해서 thread이 idle 상태로 낭비되는 시간을 줄여줌

 

출처: https://velog.io/@sihyung92/how-does-springboot-handle-multiple-requests

 

 

 

애플의 기업 문화 들여다보기

• 의사결정: 디자인이 기술을 이끈다
  • 디자인이 기술을 이끈다.
  • 만들라고 하면 만들어야 한다.
  • 애플은 실험을 하지 않는다. 대신 전문가의 경험과 직관을 믿는다. (interview)
  • 디자이너가 결정하고 엔지니어가 따라온다.
  • 완벽과 최고를 위해 탑다운도 나쁘지 않다.
• 커뮤니케이션: 사소한 것도 그냥 넘어가지 않고 따져묻는다.
  • 애플에서는 따지는 것이 무례하지 않다.
  • 서로에 대한 완벽을 기대한다. 색상, 단어 하나까지 그냥 넘어가지 않는다.
• 기타 등등
  • 일잘러의 기준: 논리적이고 말 잘하며, 주장이 강한 완벽주의자
  • 동기부여: 제품의 퀄리티에 대한 자부심
  • 제품 출시: 완벽한 제품이 아니면 내놓지 않는다.

 

출처: 애플에서는 단순하게 일합니다

 

 

 

유저 목록을 Redis Bitmap 구조로 저장하여 메모리 절약하기

• 특정 유저군을 타겟팅할 때 Redis의 SET 구조 대신 Bitmap 구조를 사용해 메모리를 절약할 수 있음
• 비트맵은 특정 index에 해당하는 값을 bit 단위로 저장하는 자료 구조임
• 비트 단위를 가지므로 1000만건을 입력해도 1.19MB 공간만 차지함
• 대신 상대적으로 큰 오프셋을 가지며 적은 갯수의 데이터를 보관한다면 Bitmap보다 SET에 저장할 때에 차지하는 메모리 크기가 더 작음

 

출처: https://blog.dramancompany.com/2022/10/유저-목록을-redis-bitmap-구조로-저장하여-메모리-절약하기

 

 

 

2024년 6월 30일 CentOS 7 지원종료(EOL, End Of Life)

• 레드햇은 2024년 6월 30일 CentOS 7을 지원종료(EOL, End Of Life)했고, 더이상 보안패치 등의 지원 서비스가 제공되지 않으므로, 정리가 필요함
• Cent OS란?
  • 성능과 안정성이 중요한 시스템에 사용되는 레드햇 엔터프라이즈 리눅스(RHEL)의 복제품으로, RHEL의 소스코드(설계도)를 그대로 복사해서 만들었음
  • 센트OS와 RHEL은 사실상 같은 소프트웨어며, RHEL은 유료 운영체제지만 오픈소스 소프트웨어이기 때문에 소스코드를 복사해도 문제가 되지 않음
  • 전 세계 리눅스 시스템의 26%에 센트OS가 설치되어 있을 정도로 우분투(32%)에 이어 광범위하게 사용되었는데, 우분투는 주로 개인용으로 센트OS는 주로 기업의 서버에서 사용됨
• 레드햇의 센트OS 인수
  • 센트OS는 커뮤니티에서 시작됐지만 지난 2014년 레드햇이 인수했음
  • RHEL을 복제한 오픈소스를 레드햇이 인수하는 것에 대해 당시에 말이 많았는데, 레드햇이 자신의 매출을 갉아먹는 센트OS를 죽이려고 하는 것 아니냐는 이야기가 많았음
  • 하지만 당시 레드햇은 “센트OS와 레드햇의 커뮤니티를 통합해 오픈소스 혁신을 가속화하겠다”며 개발자들을 달랬음
• 레드햇의 센트OS는 정책 변경
  • 지금까지 레드햇의 리눅스는 페도라, RHEL, 센트OS라는 삼각편대로 구성돼 있었음. 오픈소스 커뮤니티인 페도라(Fedora)에서 리눅스 소스코드를 만들면, 레드햇은 이를 기반으로 안정성 테스트와 기업을 위한 기능을 더한 RHEL을 만들었고, RHEL이 나오면 레드햇 상표를 뗀 후 센트OS로 만들어졌음
  • 즉, 페도라→RHEL→센트OS의 흐름으로, 이런 점에서 센트OS는 RHEL의 다운스트림(Downstream, 하류)이라고 불렀음. 즉, RHEL에서 내려오는 리눅스라는 의미임
  • 하지만 레드햇은 2020년 12월 센트OS를 REHL의 업스트림(Upstream,상류)으로 바꾼다고 발표했음. 즉, 페도라→ 센트OS→RHEL으로 흐름을 바꾼다는 것임
  • 이제 센트OS와 RHEL은 더 이상 같은 OS가 아니고, 호환성도 장담할 수 없게 됐음. 사실상 RHEL의 베타버전을 사용하는 셈이 됐음
• 결말
  • 센트OS를 없앤다고 해서 RHEL 복제품이 사라지는 것은 아니며, 실제로 새로운 복제품들이 등장했음
  • 그러자 레드햇은 센트OS의 깃 저장소에 RHEL 소스코드를 공유해왔는데 이를 중단까지 했음
  • 이는 오픈소스 업계에서 논란이 됐는데, 결국 센트OS 7에 대한 지원은 중단되게 됨

 

출처: https://byline.network/2024/07/0702/

 

 

 

Slack이 테스트 프레임워크를 교체하면서 AI를 활용한 이야기

• 과거에 React의 테스트 프레임워크로 사용하던 Enzyme이 더는 최신 React를 지원하지 않아서, React Testing Library로 바꾸기로 결정은 했는데 Enzyme으로 작성된 15,000개 이상의 테스트를 변환해야 했음
• 자동화를 시도했고 테스트를 AST로 변환해서 자동 변환하려고 했지만 테스트의 복잡성을 제대로 다룰 수 없어서 결국 45% 정도만 자동으로 변환하고 나머지는 수동으로 처리하도록 안내했다고 함
• 이후 AI를 사용하는 접근 방법을 연구하기 시작했고 AST와 함께 React의 DOM 트리 컬렉션을 함께 프롬프트로 제공하자 불규칙한 자동화 결과를 크게 개선할 수 있었음
• 자동 변환된 테스트의 채택률이 크게 올라서 개발자의 시간을 22% 줄일 수 있었다고 함

 

출처: https://careerly.co.kr/comments/107691?utm_campaign=user-share