03 Dec 2022

INDEX

• 1. What’s in New: GCP
• 2. GCP 조금 더 안전하게 사용하기 (feat. AWS)
• 3. 스타트업 온프레미스 클러스터 도입기
• 4. BigQuery 도입 후 4년
• 5. TF 모델 경량화: 모델 프루닝과 KD 학습 기법 맛보기
• 6. 22년의 State of ‘Art’: Diffusion 맛보기
• 7. 초해상도 이미지 복원
• 8. 후기

---

festa

• 11월 19일 토요일, 송도 스타트업캠퍼스에서 진행된 행사
• 부스트캠프 동기이신 분께서 발표한다 하셔서 더 흥미가 생긴 것 같다
• 클라우드나 mlops 부분은 모르는 내용이 많아서 키워드 중심으로만 작성했다

1. What’s in New: GCP

• 지각해서 제대로 듣지 못했음
• google workspace
  • workspace 에서 슬라이드 발표자 소프트라이트 기능
  • 슬라이드를 띄워놓고 슬라이드 중간에 얼굴을 띄우는 게 가능
  • grouping 가능
• google meet
  • 소그룹 채팅방
  • 자동 영상 프레임
  • 자동 회의 스크립트 (회의록?) 작성
  • slides 제어
  • 번역?
• gmail
  • 왼쪽 하단의 chat
  • 슬랙의 스레드 기능을 chat 에도 도입
  • A/B test 중
• smart canvas
  • 재사용 템플릿
• 구글에서 cloud, workspace 등을 알려주는 워크샵 같은 행사가 있다고 함
  • 딥다이브하는 세션이라고 표현했는데 뭔지 제대로 모르겠음

2. GCP 조금 더 안전하게 사용하기 (feat. AWS)

• 연사자: 당근마켓 SRE 엔지니어, GDG cloud korea organigator
• GCP, AWS 를 어떻게 더 안전하게 사용할 수 있는가
• gcp iam
  • IAM - identity and access management
    • 클라우드 서비스의 기본
    • 중요도가 높고 사고가 있을 경우 영향이 큼
    • 실수로 잘못 설정하는 경우가 많고, 트러블슈팅의 원인이 되는 경우가 빈번함
  • 요청이 빈번하지만 각 어플 별로 사용하는 서비스가 다르기에 권한 관리 부분은 자동화가 어려움
  • 개발자 클라우드 엔지니어 보안 엔지니어 간 gray 영역이 존재하는 경우가 많음
    • kms, gcs…. ?
  • who, can do what, on which resource, - ID, 무슨 리소스, 엑세스 권한
  • 누가 접근할 수 있는가?
    • google 계정, 그룹, 서비스 계정…
    • 크게 2가지. 사람의 계정, 서비스 계정
    • gcp에서 service account라고 불리는 것들
  • policy - 권한의 집합?
  • 사용자, VM, bucket
  • 외부 서비스에서 gcp를 사용할 때는?
    • 키가 노출된다면?
• service account key의 한계
  • 관리하는 것 자체가 부담임
  • key의 rotation 주기 및 방법
  • 저장 위치 - secret manager, parameter store
  • key가 있다면 모든 권한을 가질 수 있음
    • 막강한 권한을 가진 key가 유출된다면 보안 사고
• gcp workload identity federation
  • 서비스 키를 안 쓰고도 온프레미스, 또는 멀티 클라우드 워크로드에 엑세스 권한을 부여할 수 있음
  • key가 없음
    • metadata 형식의 config 파일임
    • 다른 서버에선 쓸 수 없음
    • short lived token이라 피해 최소화 가능
    • config 파일이 지정되어 있어 자동화에도 적합함
  • logging 가능, aws, azure 등 여러 provider 지원.
  • workload identity federation 을 통해 만료기간이 킨 key 없이 외부 애플리케이션이 short lived token 으로 GCP service account 를 가장(impersonate)할 수 있다
• gcp, aws iam 비교
  • GCP - AWS
    • user - user
      • 실제 사람이 사용하는 용도의 각 클라우드 서비스의 계정
    • group - group
      • 여러 user 를 논리적으로 묶은 단위
      • 권한을 부여받으면 group 의 모든 user 에 적용됨
    • service account - role
      • 사람이 아닌 애플리케이션이나 각 클라우드 서비스를 위한 계정
    • policy - role & policy
      • 특정 대상의 클라우드 서비스에 특정 행위를 할 수 있도록 하는 권한의 집합
• 그 이후로는
  • workload identity pool?
  • arn 속성?
  • aws irsa?
  • 등의 이야기가 나왔지만 내가 모르는 내용이라 생략
• WIF 를 써보는 걸 추천한다고 함

3. 스타트업 온프레미스 클러스터 도입기

• 스타트업 특유의 빠른 제품 출시
  • 품질 하락, 기술부채 증가
  • 품질을 챙기면서 릴리즈 속도를 가속화하는 방법
    • devops!
      • CI/CD, monitoring 등
        • CI/CD -> 빌드할 수 있는 서비스, 소스 받고 docker 빌드하고 push 하고 배포? - 젠킨스
  • 레거시
    • front 는 모노레포, back 은 MSA, 그리고 시스템에 의존적인 모듈들..
    • 일단 전부 빌드되게 하고, 스크립트화했음. 빌드 속도는 나중에
  • 기존 시스템이 컨테이너화 되어 있지 않고 systemd 기반임
    • systemd 기반이라는 게 정확히 무슨 의미인지
    • 그리고 서비스가 다른 서비스에 의존적임 - 순서
      • 변수가 고정적이라 빌드 시간에 종속적임 - ?
    • 의존적이어도 standalone 할 수 있게 변경함
  • 이제 빌드 성능 최적화를 고민해야 함 - test 작성이 필수
• containerize!
  • 각자 환경이 달라짐. 누군가 혹은 고객의 사정으로 인해 서버 환경이 변함
  • 시스템과 서비스 간의 환경 격리 필요
  • container runtime - service - service proxy
  • dockerfile에 필요한 패키지 목록화
  • yaml에 배포 시 필요한 변수 및 설정들 목록화
  • tip - 컨테이너 보안
• 그래도 docker compose up 하는 건 같음
  • 납품할 때마다 손으로 직접 하는 것들.. apt, yum, docker, python, go, node 등 설치
    -> 스크립트화?
  • 이걸 전부?? -> ansible 도입
    • yaml으로 호스트 정보를 정의하는데, 이걸로 설치하고 시스템 변경사항을 기록함
    • 왜 ansible? 한 번의 명령어로 동일한 결과 보장, 원래 서버 엔지니어들이 많이 썼음
    • 기존의 shell if 문을 고쳤음. yaml화 시켜서
    • 파이썬 설치, alternative 설정 등
    • 또 배워야 했지만, yaml 작성은 아주 쉽다. zsh, vim, docker runtime 까지 전부 자동화
    • ansible 트러블슈팅 - 대부분 ssh 문제임. ssh key, sudo, port 등등 확인해보길
• 근데 서버가 여러 대임..
  • 자원관리를 하나로 하고 싶어
    -> 쿠버네티스
  • 컨테이너 기반 시스템에서 여러 노드까지?
    -> 쿠버네티스
• 오히려 소잡는 칼이 아닌가 생각했음
  • 사실 기관총임. 여러 노드의 자원을 효율적으로, 각 어플의 상태관리까지
  • 여러 대의 서버에서 효율적으로
  • 언제든 다른 노드에 어플이 위치한다면? 장애가 난다면? 등.. db는?
    • replicaset 등 전부 제공
• 늘어나는 고민.
  • local-path-provisioner 에러
    • 사실 스토리지를 제공해야 하는 문제임
    • NFS?
      B2B 하는데 이걸로 충분?
      그래서 rook ceph 를 도입
  • 배포 설치 문제
    • k8s native? 를 설치하려면 manifest 가 너무 많고 설치도 힘듬.
      • 프로메테우스의 yaml.. 너무 많다
        -> HELM! 설정을 따로 패시 편하게 만든 패키지 매니저
  • 설치 문제
    • k8s 자체 설치도 문제
      -> kubespray
      • ansible 기반 provisioner
      • k8s yaml 전부 제공,,,
      • k8s 최초 provion 시 개발자 작업 거의 없음
      • 대부분 클러스터 설계사항이 yaml 에 반영됨
• 고객사마다 yaml 어떻게?
  • 인프라를 taml code로 관리
    -> 다른 인프라에선? 다른 인프라의 변동사항은?
    -> branch!

4. BigQuery 도입 후 4년

• 처음 입사했을 때 데이터팀이 없었고 GCP 도 쓰지 않았음
• 데이터 웨어하우스 툴? 데이터 레이크?
• aws redshift, snowflake, bigquery 크게 3개가 있는데
  • 빅쿼리는 완전 관리가 가능. 다른 건 노드로 관리해야 한다고 함
  • 노드 관리, 컴퓨팅 자원 관리가 없었고, 그래서 멀티클라우드를 무릎쓰고 도입함
  • 지금은 다르다. 무작정 도입하면 안됨. 멀티클라우드가 아니라면 전부 구현해야 함
  • 지금은 노드 관리 안 하는 서버리스로 가는 추세임 -> redshift 가 좋을 수 있음
  • nosql 이 메인이라면? 데이터 종류는? 관리하는 사람들이 누군지에 따라 달라질 것임
    • 인프라가 아무리 좋아도 쓰는 사람이 없으면 소용없음
    • 반대로 인프라가 미흡하면 뭘 해도 의사결정에 병목이 생김
    • 규모에 따라, 기술 문화에 따라 골라야 함
• raw 데이터가 왜 필요?
  • 개발, 데이터 담장자 간의 대표 이슈
  • 개발자 입장에선 필요 없음
  • 이걸 왜 db에, s3에 넣지..?
  • 과거 waterfall -> 에자일 이것과 비슷
    • 데이터 요구사항도 제품과 비슷하게 계속 바뀜
    • 요구에 민첩하게 반응하기 위함임
  • 데이터도 비슷함. 고정하면 바뀌기 어려운 스키마. 그래서 raw 를 수집하는 게 좋음
  • 그럼 수집된 것에서 빈 것을 메울 수 있음 유실이 없고. 그리고 데이터가 다 있으니 수집 단계가 생략된다는 장점이 있음
• 데이터 기술 부채.. 점점 쌓임
  • 눈덩이처럼 불어나고, 사람을 더 뽑아야 함
  • 기술부채가 심해지면서 데엔을 구하기 더 어려워짐
  • 중복되고, 또 어떤 데이터를 사용해야 하는지를 관리해야 했음
  • 모으기만 할 게 아니다. 체계가 필요
• 모든 데이터가 무엇인가
  • point in time recovery
  • 스냅샷+바이너리 로그 - transaction
  • 이전 상태를 추적 가능
  • 비즈니스에 따라 예외가 있지만, 모든 히스토리가 존재함
  • crud 는 현재 상태만 나타냄. 그래서 바이너리 로그 사용?
  • universal analytics, GA4 - 세션 기반에서 user property로 바뀜. user와 event - ?
• 어떻게 데이터를 빅쿼리로 보내는가
  • 데이터 저장을 gcs에 할 수도 있지만.. 이미 s3를 쓰고 있었음
  • 그래서 api를 통해 파이프라이닝 하는 방식을 채택했음
  • 비동기..? queryjob?
    • 40분 작업을 10분 이내로 단축
    • async job?
  • 쿼리 실행 권한?
• 데이터 마트 작업? 인프라 병렬로 안해도.. 파이썬에서만??
  • 빅쿼리에선 쿼리 자체가 표준 sql임
  • 아테나는 하둡 기반임.. 분석가들도 그래서 빅쿼리는 잘 씀
• crontab 쓰면되지 왜 airflow?
  • 시간에 대한 종속성을 작업에 대한 종속으로 바꿈
  • 앞의 task 가 성공해야 뒤에가 실행됨!
  • cloud composer - google. airflow 기반
  • 한 번만 해야 하는! - 멱등성
  • 빅쿼리엔 merge 라는 게 있음
    • nosql 에서 많이쓰는 듯
  • 잘못된 데이터 복구 -> raw 데이터가 있어야 함
  • backfill - 빈 데이터를 메우다 - 멱등성을 보장하면 언제 어디서든 데이터를 메울 수 있다?
• 데이터 찾기!!!!!!!
  • 데이터 수집에 논리, 운영에서 정합성, 실제론 다양한 관점을 원함. 중복데이터가 자꾸 흩어짐.. 거버넌스. 원본 데이터까지 잘 찾기, 쿼리부터..
    • 정합성 없음 -> 툴이 문제? -> 다른 툴 도입 -> 데이터 수집 -> 정합성 없음 .. 무한 반복
  • 데이터 카탈로그! - 회사의 데이터를 잘 인벤토리화, 정리하는 것
    • 메타데이터 같은
  • 이름의 규칙성을 택소노미, 수명을 관리하는 걸 거버넌스라 함
  • 빅쿼리엔 보안과 관련된 기능이 있음. 열 행에 정책을 걸 수 있음
    • 행에다 걸면? 본인 계정만 조회 가능, 엑세스 정책임!
    • iam 관련 정책과 비슷함.?
      • 관리자 group 계정, 여기에 계정을 추가.
      • 계정 거부는 있어도 정책 거부는 없다 - IAM or 빅쿼리??? - 이해 못했음
• 기타 키워드들
  • google workspace?
  • 데이터를 어떻게 유기적으로 연결?
  • 데이터팀 목표: 올바른 의사결정을 데이터로 할 수 있도록 하는 것
  • ci/cd, 그리고 CT! continuous training
  • 카테고리 이론
  • Data Lineage
  • 시간 의존성, 작업 의존성
  • 멱등성, 정합성
  • 데이터 보안, 유기적 연결, 비용 효율적 운영
• 그 뒤에 mlops, dataops, bigqueryml, 데이터 카탈로그 이런것도 나왔는데.. 잘 모르겠음

---

이 아래부터는 이제 ml/dl 쪽 내용들이다. 대부분 들어보고 아는 것들이어서 기록을 열심히 하진 않았다. 솔직히 앞부분 들으면서 좀 지쳤던 거 같다. ml/dl 파트는 그냥 재미있게 들었다.
사진 찍어놓은 게 있어서 그걸 보고 정리했다

5. TF 모델 경량화: 모델 프루닝과 KD 학습 기법 맛보기

• 부캠 동기 분께서 발표하셨음
• 경량 알고리즘
  • 모델 구조 변경
    • resnet -> squeezenet
  • 필터 변경
    • mobilenet, shufflenet
  • NAS
    • netadapt, mnasnet
• 알고리즘 경량화
  • 모델 압축
    • quantization
    • pruning
  • knowledge distillation
  • NPU
  • pocketflow, AMC
• quantization!
  • 캐스팅 할 때 오버헤드가 일어나서 오히려 느려지기도 함
    -> 지원하는 것만 해라
  • 표현력 감소..
  • quantization aware training!!
  • 3시간 내에 학습을 끝내야 한다, 이런 경우에 사용하기도 함
    이런 시간 제한이 있는 대회도 있다고 함
• pruning
  • structured pruning
    • group 단위로 pruning
      • group: channel, filter, layer …
    • dense computation 에 적합
  • unstructured pruning
    • 파라미터 각각 독립적으로 pruning
      • pruning 할 수록 network 가 점점 sparse 하게 됨
      • sparse computation 에 적합
  • ‘Learning both Weights and Connections for Efficient Neural Networks’ 라는 논문이 pruning 의 시작임
    • Neuron 의 norm 이 기준 threshold 를 넘었는가
    • masking 후 초기화하지 않음
    • 초기화하면 성능이 크게 낮아진다고 함
      • why??
• knowledge distillation
  • teacher model 의 어떤 지식을 전달?
    • feature-based knowledge
      • activation boundary
    • relation-based knowledge
      • activation 구조?
  • student model 에 어떻게 전달?
    • online distillation
      • multi gpu 를 통한 병렬 처리
    • self distillation
      • 한 네트워크 안에서 지식이 전달
  • ‘Distilling the Knowledge in a Neural Network’ - KD 의 시작. 대가 제프리 힌튼의 논문
    • soft label, distillation loss (KLDiv)
    • distillation loss 와 student loss 2개를 통해 학습하는데.. distillation loss 만 있어도 되지 않을까 싶기도 하다..
      • 모르겠음
    • softmax with temperature
      • 결과 분포를 좀 더 완만하게 하는 역할?
  • ‘Combining Weight Pruning and Knowledge Distillation For CNN Compression’ .. 등 다양한 논문이 나오고 있음
• 키워드
  • weight distribution?
  • 베어메탈

6. 22년의 State of ‘Art’: Diffusion 맛보기

• 연사자
  • 몬드리안ai - mlops 하는 회사
  • 미국에서 석박, 그럼 학사 졸업 후 바로 간 건가?
• noise?
  • input x 로부터 계산된 확률분포를 따르는 vector z 를 decoder 에 넣어 이미지를 생성함
    • GAN, VAE, flow-based model, diffusion 전부 마찬가지
• diffusion?
  • forward(diffusion), reverse(denoise)
  • noising 한 뒤 denoise 를 학습시키는 방식
    • 미세하게, 아름답게, 면밀하게
  • 현재 시점은 이전 시점에 의존한다 - markov process (이산확률과정)
  • denoise 는 diffusion 의 행동을 역전하여 따라하려 한다
    • $p_\theta (\mathbf x_{t - 1} \vert \mathbf x_t) \approx q (\mathbf x_t \vert \mathbf x_{t-1})$
      • $p(\text{denoise})$ 는 $p(\text{diffusion})$ 을 approximate
  • Encoder - $q\left(\mathbf z \vert \mathbf x\right)$
    • $q(\mathbf x_t \vert \mathbf x_{t-1}) = \mathcal N(\mathbf x_t; \ \sqrt{1-\beta_t}\mathbf x_{t-1}, \ \beta_t \text I)$
      • 왜 $\sqrt{1-\beta_t}$ 를 쓰지?
    • gaussian noise 를 계속 추가 (Fixed noise diffusion by scheduling)
  • Decoder - $p_\theta(\bar{\mathbf x} \vert \mathbf z)$
    • $p_\theta(\mathbf x_{t-1} \vert \mathbf x_t) = \mathcal N(\mathbf x_{t-1}; \ \mu_\theta(\mathbf x_t, t), \Sigma_\theta(\mathbf x_t, t))$
  • 놀랍게도 $q(x_t \vert x_{t-1})$ 이 gaussian 이면 $q(x_{t-1} \vert x_t)$ 도 gaussian 이라고 함
• DALL-E
  • 잘 몰라서 생략
  • 나중에 test2image 는 따로 공부한 뒤 정리할 생각
• Current stage: Text2Image Generation
  • disco diffusion
  • mid-journey
  • stable diffusion
• diffusion vs. GAN
  • diffusion이 더 효율적이다! delle1은 vae 기반임
  • 디퓨전의 단점이라면, GAN보다는 퀄리티가 낮다. 장점이라면 퍼즐조각처럼 픽셀을 맞춰 impainting 이 가능하다.
  • 다양성이 가장 큰 장점이다.
  • GAN 이 저물아가는 해인지는 잘 모르겠다.
• 키워드
  • text2image
  • autoagressive

7. 초해상도 이미지 복원

• dacon jin (dacon 운영진?이라고 함)
• 메가스터디
  • AI Tutor - conversational AI. 챗봇, 음성인식, 음성합성…
  • 지식 추적 분야 - DKT!
• Swin2SR
• super resolution
  • $I_x = D(I_y; \ \delta)$
    • $I_y$: 고해상도 이미지
    • $D$: Degradation mapping function
    • $\delta$: Parameters of degradation
  • $D(I_y; \ \delta) = (I_y) \downarrow_s, \ \{s\} \subset \delta$
    • classical super-resolution
  • $D(I_y; \ \delta) = (I_y \otimes \kappa) \downarrow_s + n_\zeta, \ \{\kappa, s, \zeta\} \subset \delta$
    • real-world SR
  • 이렇게 degradation 을 한 뒤 그걸 복원하는 task 같음.
• 키워드
  • bicubic?
  • huggingface - swin2sr
  • swin-transformer 에서 torch.roll 을 사용한다! - 부캠 dkt baseline 에서도 torch.roll 을 쓰는데.. 반가웠음

8. 후기

• 끝나고 센트럴파크를 걸으면서 많은 생각을 했다
  • 그때는 참 힘들었다. 지금도 힘들지만.. 차라리 몸이 아프면 아프고 말 텐데
  • 센트럴 파크는 정말 예뻤다. 팀원 분께서 꼭 가보라고 하셨다. 사실 그땐 그냥 흘려 넘겼었는데, 행사 끝나고 이대로 집 가기는 아쉬워서 들렀고,
    정말 좋았다. 한국 같지 않았다
  • 구글 지도에서 평점 높은 술집을 찾아서 가려 했는데 가보니 사라져 있었다. 인스타 계정도 사라져 있고
• 이런 것들 말고도 아쉬움이 참 많이 남는 날이었다
  • 근데 지금 기억을 갖고 이 당시로 돌아간다 하더라도
    크게 달라질 것 같진 않다.. 그래서 더 슬프다-
    나 자신이 너무 한심하다
• server side 강연은 들으면서 졸 뻔했다. 다 모르는 내용이어서
  • 클라우드와 서버, 데이터베이스, 서빙 쪽의 지식을 좀 더 함양하고 싶다. lv3 프로젝트를 하면서 저절로 길러질까?
  • 팀원들과 도커 스터디를 하고 있긴 한데 따로 더 공부해야 할 거 같다 가능하다면
• 이때 이후로 매주 토/일 요일마다 세미나를 다니려 하고 있다. 평일에도 많던데 현실적으로 가지 못 해 많이 아쉽다
  • 직접 해보지 않으면 알 수 없는 내용들을 이렇게 무료로 (거의 무료) 공유해주는데 안 들을 이유가 없다.. 한 마리의 아기새가 된 것 같은 느낌이었다
  • 지금은 청중일 뿐이지만, 언젠간 나도 괄목할 만한 성과를 내고, 이런 자리에서 발표해보고 싶다. 가능하면 좀 더 큰 무대에서-
• 미루다가 이제야 정리를 끝냈다. 이젠 미루지 말자

---

first draft: 2022.12.04 22:35