9일

• https://news.hada.io/topic?id=19618
  • 이전에 BigData Project를 구현하면서 유사한 아이디어를 사용한적이 있음.
  • spartial vector 로 문서를 인덱스(TF-IDF) 해두고 이 vector 의 cosine 유사도를 빠른 시간안에 찾아야 했음.
    • cosine 유사도를 얻기 위해서는 대량의 연산이 필요함
    • 하지만 hash와 cosine 유사도의 특징을 이용해서 이를 훨씬 적은수의 xor 연산으로 전환 할수 있었음.
    • xor 는 대부분 CPU 에서 아주 빠르게 연산할수 있음.
  • cosine 유사도는 결국 두 벡터가 가르키는 지점이 얼마나 가까운가가 핵심임
  • 따라서 공간을 하나의 평면으로 나누고 두 그룹으로 나누면 같은 그룹에 속하는 두 벡터가 다른 그룹에 속한 벡터보다 가까울 확률이 높음
    • 물론 아주 가까이 있어도 서로 다른 두 그룹으로 나누어 질수도 있음.
    • 하지만 여러개의 임의의 평면으로 공간을 나누면 같은 그룹에 속하는 수가 많을수록 높은 cosine 유사도를 가질 확률이 높음
  • 한 평면으로 나누어지는 그룹은 1bit 로 표현이 가능함.
    • 따라서 64bit 에는 64개의 평면으로 나눈 그룹의 데이터를 보관 가능함.
    • 64개의 평면으로 나누어진 모든 그룹이 같을 확률은 ¹⁄₂^64 임
      • 이 정도라면 왠만한 Data에서는 충분한 분할임.
      • 더 높은 정밀도가 필요하다면 같은 그룹의 데이터 끼리 cosine 유사도를 평범한 방법으로 다시 계산하거나, 64bit 를 하나 더 추가 하면 됨.
  • xor연산은 두 bit가 같다면 0 다르다면 1 을 표현함
    • 64bit 를 xor 하는 연산과 1bit 를 xor 연산하는 것은 사실상 같은 CPU cycle 이 소모됨
    • 추측이지만 수십개의 float 곱셉과 덧셈을 처리하는 것보다는 확실히 빠를것이 분명함.
      • 예외) GPU는 다를수 있음.
  • 이 사실들을 조합해서 수백만개의 문서의 consine 유사도를 수초 내에 연산할수 있었음
    • 생각보다 굉장히 잘되서, cosine 유사도가 높은 문서를 찾았더니 copy & paste 를 한 문서만 보여주는 탓에 코드가 오작동하는것으로 오해한 해프닝이 있었음.

12일

• https://news.hada.io/topic?id=19698
  • 굉장히 흥미로운 아이디어
  • 하루에 사용할수 있는 시간이 정해져 있는 SNS
  • Time zone 문제가 있지만, 매순간 도착하는 news feed 가 없고 시간 집중적으로 메세지가 교환됨
  • 나도 만들어 보면 어떨까?
    • 나라면, 이렇게 만들었을듯.
      • timezone 은 1주일에 한번만 변경 가능
      • timezone 을 바꾸면 해당 timezone 밖에서 작성된 글은 볼수 없음.
        • 자신이 쓴 글만 예외 임
        • 다른사람이 내 글에 달아군 댓글까지는 볼수 있음.
      • Reaction은 emoji 전체를 쓸수 있으면 어떨까 함
      • news feed 는 자신이 follow 한 사람만
        • random 한 누군가를 만나기 위해서는 명시적으로 random feed, 지역별 feed, 관심사별 feed 등을 방문해야 함.
        • “모두가 광장에서 소리치기” 보다 “local pub에서 소문 듣기”에 가까웠으면 좋겠음.
      • 추천 알고리즘 없음.
      • AI를 살짝 끼워 넣어서, 반응을 보고 싶을듯.
        • https://news.hada.io/topic?id=15869
        • “연결되어 있다는 느낌”을 위해 SNS 를 한다면 반대할 이유가 없지 않을까?
        • 소규모로 다 나눠져 있는 것의 보완책도 될것 같고…

19일

• prometheus 는 왜 total 과 count 를 이용해서 rate, avg 등을 계산하는 것이 대부분일까?
  • 중간에 metric을 유실하더라도 정보가 누락 되지 않기 때문이다.
    • 평균 = 기간내 합계 / 기간내 갯수
    • total 과 count 를 가지고 있다면 기간의 시작점과 종료점만으로 합계와 갯수를 알수 있다.
      • 기간내 합계 = 종료점 total - 시작점 total
      • 기간내 갯수 = 종료점 count - 시작점 count
    • 따라서 중간에 metric 이 수집되지 않거나 유실되더라도 정보가 누락되지 않는다.
  • 더 적은 연산, 저장소 접근으로 평균, 증가량 등을 계산 할수 있다.
    • 평균은 모두 합한후 갯수로 나눠야 한다.
    • total 을 기록하고 있다면, 제일 처음값과 제일 마지막 값만 읽어 처리 할수 있다.
  • 다만, 중간에 reset(total 을 다시 0 부터 세기) 를 한다면 처리가 약간은 복잡해진다
    • 중간 값이 누락되었을떄의 처리가 곤란해진다.
    • counter reset 에 대한 대비를 해야한다.

26일

• 배포의 형태
  • software engineer 간에도 “배포” 라고 부르는 것의 차이가 존재 한다.
  • 각자가 가진 배경이 다르고 제품에 특성에 따라 다르다.
  • 내가 겪어본 배포는 다음과 같은 종류들이 있다.
    • 작성한 web application server binary를 server machine 에서 실행 시키는 것
      • 영어로는 주로 “deployment” 라고 하는것 같다.
      • 방법은 여러가지다.
      • eg) container를 k8s 에 배포, php 를 ftp 로 upload 한뒤 nginx reload 를 하는것.
    • 실행 가능한 package를 사용자에게 전달하는 것
      • 영어로는 주로 “release” 라고 하는것 같다.
      • eg) compile 된 binary 를 github release page 에 게시, 완성된 게임을 CD 에 담아 배송, 앱스토어에 앱 게시.
    • 제품의 source code를 사용자에게 전달하는것
      • 위의 실행 가능 package를 전달하는 것과 유사하지만, 완성된 바이너리가 아닌 소스코드 그 자체를 전달 하는 것.
      • 주로 script 나 tool 등에서 보이는 패턴
      • 사용자가 직접 일부를 수정 해야 하는 경우에 자주 보임
  • 명확하게 딱 구분해서 단어를 사용하는 것은 아니고 섞어 쓰거나 하는 경우가 많다.
  • “배포”의 형태에 따라서 git branch 정책을 다르게 해야 하거나, CI/CD 의 개념이 달라 지는 경우가 많다.