[컴] '빈 서트'의 엔지니어들을 위한 커리어 조언

인터넷의 아버지 / 조언 / 시니어 엔지니어 / 조언 / 일을 잘하는 법 / 명언 / 태도 / 자세

빈서트의 엔지니어들을 위한 커리어 조언

• Vint Cerf

• “If you really want to do something big, get help, and preferably from people who are smarter than you are.”

• “만약 정말로 큰 일을 이루고 싶다면, 도움을 받아라. 가능하면 너보다 똑똑한 사람들로부터 받아라.”

• “Be humble, because unless you approach things with the understanding that you really don’t know exactly how to make it all work, you may overlook possibilities.”

• “겸손하라. 당신이 모든 것이 어떻게 작동하는지 정확히 모른다는 것을 이해하고 접근하지 않으면, 가능성을 놓칠 수도 있다.”

• “Listen to other people. I tell my engineers that if they know I’m about to do something stupid, they have to tell me, so I don’t do it. And if they knew and didn’t tell me, that’s going to be reflected in their end-of-year fitness report. When you’re in a position of responsibility and authority, people may assume you’ve already figured out where the hazards are, but you may not have.”

• “다른 사람들을 들어라. 내 엔지니어들에게 그들이 내가 어떤 어리석은 짓을 하려는 것을 안다면, 반드시 내게 말하라고 한다. 그래서 내가 그것을 하지 않도록 합니다. 그리고 만약 그들이 알았는데 말하지 않았다면, 그것은 그들의 연례 평가에 반영될 것이다. 책임과 권한을 가진 위치에 있을 때, 사람들은 네가 이미 위험지역을 파악했다고 가정할 수 있지만, 실제로는 그렇지 않을 수 있다.”

• “Try hard to stay on good terms with everybody. Civility is an important property, and burning bridges is generally a bad idea; you never know who you’re going to work with again, who you might work for, or who might work for you.”

• “모두와 좋은 관계를 유지하기 위해 노력하라. 정중함(Civility)은 중요한 가치이며, 다리를 태우는 것은 일반적으로 좋지 않은 생각이다. 너는 미래에 누구와 함께 일할지, 누구의 일을 할지, 또 누가 너를 위해 일을 할 지 알 수 없다.”

• “You can learn something from virtually everybody. One example: I was being driven in a limousine in Palm Springs by a white-haired guy. And I remember thinking, ‘This poor guy, it’s too bad. Here he is driving a limo. It’s nine o’clock at night. He ought to be just out there on the links playing golf and having a nice time.’ We struck up a conversation, and I find out that he actually did retire—from being the chief financial officer of one of the largest insurance companies in Chicago. He got bored playing golf, so he decided to drive a limo three times a week because he knew he was going to meet interesting people.”

• “거의 모든 사람으로부터 무언가를 배울 수 있다. 한 가지 예를 들자면: 나는 팜스프링스에서 흰머리 노인이 운전하는 리무진에 타고 있었다. 그리고 ’가난한 사람이 참 안됐다. 여기서 리무진을 운전하고 있네. 밤 9시인데. 그는 골프를 치며 즐거운 시간을 가져야 하는데’라고 생각했다. 우리는 대화를 나누면서 알게 되었는데, 실제로 그는 최대 규모의 시카고 보험 회사의 최고 재무 책임자로부터 은퇴한 사람이었다. 그는 골프를 치는 것이 심심해서 일주일에 세 번 리무진을 운전하기로 결정했다. 왜냐하면 그는 흥미로운 사람들을 만나게 될 것이라는 것을 알고 있었기 때문이다.”

see Also

1. 상위 1% 엔지니어의 7가지 간단한 습관 | GeekNews

Reference

1. Vint Cerf’s Career Advice for Engineers - IEEE Spectrum

[컴] 쿨링 팬

시피유 쿨러 , fan cooler / cpu cooler / system fan / 쿨링팬, 공랭, 쿨러 팬

쿨링 팬

녹투아(Noctua) 가 유명한 듯, 다만 비싸다.

ref. 1 에 나온 추천 브랜드

• NOCTUA : 다나와 통합검색
• ARCTIC : 다나와 통합검색
• DEEPCOOL : 다나와 통합검색

ref. 2 에 나온 브랜드

• Phanteks GLACIER : 다나와 통합검색

ref. 3 에 나온 브랜드

• Thermalright : 다나와 통합검색
• PCCOOLER PALADIN : 다나와 통합검색

쿨러를 고를때 고려사항

• 풍량
• 소음
• 풍압
• 가격

Reference

1. 아틱 p12 / 녹투아 a12x25 소음 및 성능차이 큰가요 > 공랭/수랭쿨러 | 퀘이사존 QUASARZONE, 2020-04
2. 가격상관x 수냉쿨러 추천 부탁드립니다. > 공랭/수랭쿨러 | 퀘이사존 QUASARZONE, 2023-05-28
3. 3만원 이하, 싱글타워 공냉 쿨러좀 봐주세요 > 공랭/수랭쿨러 | 퀘이사존 QUASARZONE, 2023-05-27
4. 13500에 쿨러 추천좀 부탁드립니다 > 공랭/수랭쿨러 | 퀘이사존 QUASARZONE, 2023-05-27
5. | 퀘이사존 QUASARZONE

[컴] JunoDB 의 overview

주노 / 페이팔 디비 / 대규모 / 처리 / 대용량 처리 디비 

JunoDB 의 overview

paypal 에서 자신들이 사용하던 NoSQL DB 를 open source 로 공개했다.

여기선 ref.1 의 내용을 정리한다.

• 사실상 paypal 의 모든 core back-end service 가 JunoDB에 의존하다.
• JunoDB 를 이용해서, application 들은 data 를 효과적으로 저장하고, cache 를 해서 RDS 와 다른 서비스들에 대한 빠른 access 와 부하를 줄일 수 있다.
• 단일 스레드 C++ 프로그램으로 시작
• 이후 동시성이 높고 멀티코어 친화적인 Golang으로 재작성
• 인메모리의 짧은 TTL(Time To Live) 데이터 저장소
  --> 에서 긴 TTL을 지원하는 영구 데이터 저장소로 발전
• 온디스크 암호화와 전송 중 TLS를 통해 향상된 데이터 보안을 제공
• 데이터 재분배(data redistribution)를 통한 빠른 확장(quick scaling)
• 현재, 시스템 가용성이 99.999%에 달하는 JunoDB
• 매일 3,500억 건의 요청을 처리.(평균 초당 40,510건)

Juno DB 사용하는 경우

• 캐싱
• Idempotency 로 사용 : 여러 요청이 와도 오직 하나의 동작만 하도록
• counter : 특정 자원의 한도를 정하고 사용할 수 있게 해준다.
• SoR(System of Record, 기록시스템) : 영구적인 기록은 아니지만, 몇년정도의 장기적인 기록을 위해 사용한다.
• latency bridging
  • JunoDB의 빠른 클러스터간 복제(replication)는, Oracle 처리중의 복제 지연들 해결해준다.
  • 그래서 거의즉시(near-instant)적으로 모든 곳에서 일관된 읽기를 가능하게 해준다.
  • latency bridging 기술은 “계정/사용자 생성 과 결제 처리를 위한 멀티 데이터 센터 active-active processing” 에서 사용돼서 높은 가용성, 신뢰성, 읽기확정성(read sacling)을 보장해 준다.

JunoDB Architecture: A High-Level Overview

JunoDB 는 매끄럽게 함께 작동하는 3개의 중요 component들로 구성돼 있다.

1. JunoDB client library : 이것은 DB를 사용하는 Client 쪽에서 사용하는 library
2. JunoDB proxy :
   • JunoDB proxy instance들은 load balancer 에 의해 제어된다.
   • client 의 request들과 다른 site들로 부터의 replication traffic 을 받는다.
   • 각각의 proxy 는 모든 JunoDB storage server instance들에게 연결되고,
   • 각 request 를 storage server instance들의 group 으로 전달한다.
   • 이 group은 shard mapping 을 기반으로 만들어져 있다.
   • ETCD에서 유지된다. 이 ETCD는 JunoDB cluster 설정(configurations)들을 저장하는 data store 다.
3. JunoDB storage server
   • JunoDB storage server instance들은 proxy 로 부터 오는 작업 요청들을 수락하고 RocksDB 를 이용해서 memory 또는 영구 저장소(persistent storage)에 data 를 저장한다. 각 storage server instance 는 shard들의 집합을 담당해서 원활하고, 효과적인 data 저장과 관리를 보장한다.

Scalability 달성

PayPal 은 십수년전에 지속적인 빠른 고객 및 결제 건수의 성장을 지원하기 위해, application layer 에서 horizontally scale 되는 마이크로서비스들의 구조로 변경했다. 그래서 키-값 저장소로 지속적으로 인바운드 연결 수가 증가했다.

필요한 규모를 처리하기 위한 상용 또는 오픈 소스 솔루션이 제공되지 않았기 때문에, 직접만들었다.

분산 key-value store들에서 2가지 주요한 scaling 요구를 처리한다.

1. 성장하는 클라이언트 연결 수를 수용하여, 원활한 액세스와 시스템 응답성을 보장합니다.
2. 데이터 양과 액세스 속도가 증가함에 따라 데이터 증가을 처리하고 효율적인 읽기 및 쓰기 처리량(throughput)을 보장한다.

Scaling for Client Connections

• 가로 연결 확장을 용이하게 하기 위해 proxy 기반 아키텍처가 선택되었다.
• 이 구성에서 클라이언트는 가벼워서 모든 저장 노드와 연결을 설정할 필요가 없다.
• 클라이언트 연결이 한도에 도달하는 경우, 추가적인 프록시를 간단히 추가할 수 있다.
• 이 방법은 약간의 지연을 초래할 수는 있지만, 확장성에 매우 효과적인 해결책을 제공한다.

데이터 크기에 대한 Scaling 과 Access 처리량

• 데이터 크기가 커짐에 따라, 효율적인 저장 및 검색을 보장하기 위해 ‘데이터 파티셔닝’ 방식을 통해 데이터를 여러 storage nodes 또는 servers에 분산하는 것이 필수적이다.
• JunoDB는 일관된 해싱을 활용하여 고정된 파티션(샤드)을 효과적으로 분할하며, 이러한 샤드는 샤드 맵을 사용하여 물리적인 저장 노드에 할당된다.
• 클러스터 내 노드 수가 ‘추가’ 또는 ’제거’로 인해 변경될 때는 오직 적은 수의 샤드만 다른 저장 노드로 재할당되어야 한다. 또한, 각 샤드 내에, 마이크로 샤드(micro-shard)를 도입했다. 이 micro-shard는 데이터 재분배의 기본 구성 요소로 작용한다.
• 전체 샤드 수는 충분히 크고 클러스터의 수명 동안 일정하게 유지되어야만 한다.
• 실무에서는 일반적으로 1,024개의 샤드를 사용한다. 샤드 맵은 사전에 생성되어 ETCD에 저장된다.
• 샤드 맵의 변경은 데이터 재분배 처리(data redistribution process)를 일으킨다.
• 우리의 효율적인 데이터 재분배 과정은 JunoDB 클러스터를 빠르게 점진적으로 확장하여 트래픽 성장에 대응할 수 있게 한다.
• 현재, 대규모 JunoDB 클러스터는 200개 이상의 저장 노드로 구성될 수 있다. 이것은 하루에 1000억 건 이상의 요청을 처리한다.

고가용성 (Ensuring Availability)

• JunoDB storage node들은 논리적인 grid 로 구성된다.
• 각 열(column)은 zone이고, 각행(row)은 storage group 이다.
• 데이터는 shard로 partitioned되고 storage group에 할당된다.
• 저장 그룹 내에서 각 샤드는 quorum protocol 에 기반해서 다양한 zone으로 동기적으로(synchronously) replicated 된다.

quorum protocol 은 저장 그룹 내에서 값에 대한 합의(consensus)를 도출하기 위해 사용한다. 데이터 일관성을 보장하기 위해 다음 2가지 rule을 준수해야 한다.

quorum protocol :

1. read quorum(R)과 write quorum(W)의 합이 존의 수(N)보다 커야 합니다: W+R > N.
   • 이는 read quorum이 데이터의 가장 최신 버전을 포함하는 노드를 적어도 하나 이상 포함하도록 보장합니다.
2. write quorum은 존(zone) 수의 절반보다 많아야 합니다: W > N/2.
   • 이는 동시에 두 개의 쓰기 작업이 동일한 키에 대해 수행되는 것을 방지합니다. 일반적으로 PayPal은 5개 zone, read quorum 3, write quorum 3의 구성을 사용합니다.

노드 오작동이 발생하는 경우, JunoDB의 장애 조치 프로세스는 자동적이고 즉각적으로 이루어지므로 리더를 다시 선출하거나 데이터를 재분배할 필요가 없습니다.

프록시는 연결이 끊기거나 읽기 시간 초과를 통해 노드 장애를 감지할 수 있으며, 일반적으로 읽기 시간 초과가 100밀리초 이하로 구성됩니다.

JunoDB는 동일한 행/그룹 내에서 두 번 이상 장애가 발생하지 않는 한 클러스터에서 여러 노드 장애를 견딜 수 있습니다.

또한, 이러한 설계를 통해 다운타임 없이 소프트웨어 또는 OS 업그레이드와 같은 유지보수 목적으로 전체 영역을 오프라인으로 전환할 수 있습니다.

Cross-data center replication between clusters

데이터센터 간 복제도 구현, 각 클러스터의 proxy들 사이의 데이터를 비동기적으로 복제 하도록 해서 구현했다.

Performance at Scale

• JunoDB는 가장 부하가 높은 시점에서(the most demanding workloads)도 한 자릿수 밀리초의 응답 시간과 원활한 사용자 경험을 유지하도록 해준다.
• 애플리케이션이 성능 저하 없이 선형 확장성(linear scalability)을 달성할 수 있도록 지원하여, 높은 처리량과 짧은 지연 시간을 제공한다.
• junodb/juno_performance_bench.md at main · paypal/junodb · GitHub

High security

• JunoDB 시스템은 ‘전송 중인 데이터’(in transit)와 ‘미사용 데이터’(at rest)를 모두 보호하도록 설계
• 전송 중 데이터 보안을 위해 TLS 가 활성화 되어 있다.
  • 클라이언트 <–> proxy 사이
  • 다른 데이터 센터에 위치한 proxy 사이(데이터 복제를 할 때)
• 페이로드 암호화는 클라이언트 또는 proxy 수준(스토리지 서버 외부)에서 수행되어 동일한 데이터가 여러번 암호화되는 것을 방지한다. 이상적으로는, 암호화는 클라이언트 측에서 수행돼야만 하지만, 클라이언트가 실행하지 않는 경우 proxy는 메타데이터 플래그를 통해 이를 감지하고 암호화를 수행한다.
• 스토리지 서버가 받아서 스토리지 엔진에 저장되는 모든 데이터는 암호화되어 유휴 상태에서의 보안을 유지(maintain security).
• Key management module
  • TLS, 세션, 암호화 키 배포를 위한 인증서를 관리하고
  • 키 교체(key rotation)를 용이하게 하기 위해 사용된다.

junodb 빌드방법

• https://www.paypalobjects.com/junodb/junodb_Server_Build.mp4
• https://www.paypalobjects.com/junodb/junodb_Docker_Build.mp4
• https://www.paypalobjects.com/junodb/junodb_client_sdk.mp4

See Also

1. https://github.com/paypal/junodb/tree/main

Reference

1. Unlocking the Power of JunoDB: PayPal’s Key-Value Store Goes Open-Source | by Yaping Shi | The PayPal Technology Blog | May, 2023 | Medium

[컴] window 11 에서 조만간 바뀌는 내용

 

윈도우즈 / 윈도우 사용하는 이유 / 왜 윈도우 / 개발 하기 더 좋은

window 11 에서 조만간 바뀌는 내용

대략 글을 보면 연말쯤에는 release 되지 않을까 싶긴한데, 일단 preview 에서는 어느정도 경험할 수 있는 듯 하다. 개인적으로 windows 를 계속 써야 하는 이유가 생긴듯 하다.

• Windows Copilot 라는 것을 도입
• Bing chat plugin들을 윈도우 어플리케이션에서도 사용할 수 있게 할 것이다.
• AI개발을 지원하기 위한 Hybrid AI loop을 도입
  • windows AI library 를 발표
    사용가능한 머신러닝 모델들과 API들의 선별된 집합
    AI 개발을 쉽게 할 수 있게 도와줄 것이다.
  • ONNX runtime 가 gateway 가 될 것이다.
• Dev Home 을 도입, 모든 개발자의 생산성 향상을 위해.
  • 이것은 store 에서 다운로드 받을 수 있다.
  • 오픈소스라고 한다. 아마도 github 에서도 받을 수 있을 듯.
  • ONNX runtime 가 gateway 가 될 것이다.
  • winget
  • Dev Drive 라는 새로운 파일시스템 도입
    Resilient File System 에 기반한다.
    Microsoft Defender for Antivirus 새로운 성능모드랑 함께 사용했을 때, 빌드 타임 file I/O 부분에서 30% 파일시스템 향상
• 새로운 AI 요소들을 도입
  • GitHub Copilot X : 당연히 유료다.
  • Windows terminal 에 GitHub Copilot X 이 들어간다고 한다. GitHub Copilot X 유저만 사용가능한 듯.
  • WinDBG 같은 다른 개발도구에서의 Copilot 도입을 추진중.

ONNX runtime, Olive

Olive 는 툴체인이다. 다양한 윈도우들과 다른 기기들에 대한 model들을 최적화 하는 부담을 덜어줄 것이다. 이 툴체인은 model 압축, 최적화, compilation 과 관련된 최신 기술을 담고 있다.

ONNX runtime 을 통해서, third-party 개발자들이, 우리가 내부적으로 windows에서 AI 모델들을 실행하기 위해 사용하는 것과 같은 tool들을 사용할 수 있게 해준다.

ONNX runtime 이 모델들을 기기에서 실행하든, cloud 에서 실행하든 같은 api 를 사용하게 해준다.

그리고, 원할 때는 local 을 사용하고, 또 필요하면 cloud 의 resource 를 쓰는 등의 작업을 할 수 있다.

[컴] Rust, Go, JVM, c#, node, python, elixir에서 메모리 사용

 

메모리 / memory cosumption / runtime memory 사용량

Rust, Go, JVM, c#, node, python, elixir에서 메모리 사용

• How Much Memory Do You Need to Run 1 Million Concurrent Tasks? | Piotr Kołaczkowski

글은 많은 concurrent task 를 실행할때의 메모리를 얼마나 사용하는지를 확인한다. Rust, Go, JVM, c#, node, python, elixir 에 대한 비교를 한다.

글에서 사용하는 프로그램은 다음처럼 동작한다.

• N 개의 concurrent task 를 launch 하고,(task 의 수는 argument 로 전달된다.)
• 각 task가 하는 일 없이 그냥 10초를 기다리다 끝난다.
• 그리고 모든 tasks 들이 끝나면, program 은 종료된다.

[컴] LLM 의 학습에는 pretraining 이 중요하다.

대규모 언어 모델

LLM 의 학습에는 pretraining 이 중요하다.

• [2305.11206] LIMA: Less Is More for Alignment

다음 글은 위의 내용을 정리 한 것이다.

Large Language Model(LLM) 들은 2가지 stage 를 거쳐서 학습하게 된다.

1. general-purpose representations(범용 표현)을 배우기 위한, raw text 로 하는 ‘unsupervised pretraining’.
2. ‘대규모 명령어 튜닝(large scale instruction tuning)’ 과 ‘강화학습(reinforcement learning)’ 을 통해 end tasks 와 사용자 선호도에 더 잘 일치하게 한다.(to better align)

‘강화학습’ 또는 ‘인간선호도에 대한 모델링’ 없이 LIMA 를 훈련해서, 이 2개의 step 중 어느것의 중요성이 더 높은지 확인하는 작업을 했다.

LIMA

standard supervised 학습을 하고 그 loss 로 응답이 미세조정된, 6500만 parameter의 LLaMa 언어모델

이 훈련된 LIMA 가 놀라운 성능을 보여줬다.

훈련 데이터(training data)에 있는 단지 몇안되는 예시들 통해서, 특정 응답 형식들을 따르는 법을 학습해서 놀라운 성능을 보여줬다. 이 훈련데이터는 ’여행 일정을 계획하는 것’에서부터 ’대체 역사를 추측하는 것’에 이르는 복잡한 질문들을 포함하고 있다.

통제된 사람들을 대상으로 한 연구에서 LIMA 로 부터나온 응답들은

• GPT-4 에 비해 case의 43% 에서 동등하거나 더 선호되는 것으로 나타났다.
• Bard 와 비교할 때는 58% 의 case 에서 동등하거나 더 선호됐고,
• DaVinci003에서는 65% 의 case 에서 동등하거나 더 선호됐다.

이 결과들은 다음 사실을 강력히 시사한다.

• LLM 의 거의 모든 지식들이 pretrainning 과정에서 학습(learn) 되고,
• model 들이 고품질의 결과를 생산하도록 가르치기 위해서는 오직 제한된 명령어 튜닝 데이터(limited instruction tuning data) 만 있으면 된다는 것

[컴] 암호화 hash 알고리즘

 

crptographic hashes

암호화 hash 알고리즘

SHA1 은 이제 사용하지 않는 것이 낫다고 한다. ref. 1 의 자료만 보면, 2017년 이후는 SHA-3 를 사용하는 것이 안전해 보인다.

ref. 1 에서 걸어놓은 링크는 google이 ‘6500 CPU years and 110 GPU years’ 를 사용해서 SHA1 의 collision 을 발견했다는 내용이다. 자세한 내용은 다음 링크를 보면 알 수 있다.

• Google Online Security Blog: Announcing the first SHA1 collision

commitment scheme

hash 가 사용되는 곳중 하나는 Commitment scheme 이다.

예를 들면, 내가 특정값을 만들고, 그 값(myval)을 누군가에게 맞춰보라고 할 때, 상대방은 내가 그 사람이 맞춘후에 값을 바꿔버릴 것을 의심할 수 있다. 그런 것을 방지하기 위해 hash(myval) 를 하고, 그 값을 상대방과 공유한다. 그리고 나서 상대방에게 맞춰보라고 하고, 그 사람이 선택을 한 이후, 내 값을 공개한다. 그리고 내가 공개한 값을 hash 를 돌려서, 우리가 공유했던 hash 값과 같은 것을 확인해서, 내가 값을 바꾸지 않았다는 것을 증명할 수 있다.

Entropy

암호학에서 특정 password 에 대한 entropy 의 단위는 bits 이다. log2 로 계산된다. 만약 ‘동전던지기’의 경우는 ’앞’, ‘뒤’ 2개뿐이니, log_{2}2 = 1 bit 가 된다. 자세한 내용은 ref. 2 를 확인하자.

References

1. Lifetimes of cryptographic hash functions
2. Security and Cryptography · the missing semester of your cs education