-->

자바공화국 배민도 Nest.js를 사내 공식 개발 프레임웍으로 지정했다는데..

 

 

장점

- 공식 문서 깔끔 (https://docs.nestjs.com/)
- DI, IoC, 데코레이터 등 OOP 개발에 용이
- 기능별 모듈화를 통한 직관적인 개발, 확장 가능성, 유지보수 용이한 개발 가능. -> 생산성 향상
- Typescript 기반으로 컴파일 오류 방지, 테스트 코드 작성에 용이하므로 TDD를 쉽게 적용 가능. (Express에서의 ts 세팅보다 매우 간단)
- Spring 과 유사한 UX로 추후 이벤트 플랫폼 개선시 유사한 아키텍처 구조 사용 가능.
- 아주 간단히 Swagger 초기 세팅으로 코드 수정시 자동 반영 (https://jhyeok.com/nestjs-swagger/)
- Webpack HMR로 필요한 부분만 비동기 핫 리로드 지원.
- Node Http 프레임워크 선택가능 (express, fasify ..)

 

단점

- 처음 접하면 러닝커브가 높을 수 있다.
- Express에 비해 작은 생태계, 낮은 점유율 (이지만 바짝 쫓아옴 2023.04 기준 Express 6만, Nest 5.5만 스타 - https://github.com/VanoDevium/node-framework-stars

와 이제 역전함~!


- 기획전 프론트에서 직접적인 DB 접근을 하지 않기에 ORM 사용 등에 제한적
- 동일한 기능을 위한 코드가 express보다 길다.

 

결론

프로젝트 성격에 따라 취사선택 해야 한다.

유연하고 확장성이 높은 Express는 작은 규모, 적은 기능의 어플리케이션이 적합하다.

반대로 Enterprise급, 여러 개발자가 빈번하게 기능 개발 등이 필요할 땐 Nest.js가 적합해보인다.

 

그러나 개인적으로.. 굳이 Nest.js 쓸 필요 있을까? 스타트업의 기술스택으로는 적합할 수도 있겠다. 초기 개발자가 적을 때 프/백 같이 할 수 있는 js/ts로 개발할 수 있으니. 근데 nest.js는 인력 풀이 좁아서 회사가 성장함에 따라 spring으로 바꾸는게 국룰이라 생각한다.

 

 

 

ChatGPT 피셜 :

Q) Nest.js 에서의 디버깅은 어렵다?!

A) 주로 아키텍처 및 디자인 철학의 차이로 인해 Express에 비해 Nest.js에서 디버깅이 더 어려울 수 있습니다. 다음은 Nest.js에서 디버깅이 더 어려운 것으로 간주될 수 있는 몇 가지 이유입니다.

 

  1. 추상화 계층: Nest.js는 데코레이터, 모듈 및 종속성 주입과 같은 추가 추상화 계층을 도입합니다. 이러한 추상화는 응용 프로그램 구축에 대한 체계적이고 조직적인 접근 방식을 제공하지만 오류를 추적하고 디버깅할 때 응용 프로그램의 흐름을 이해하기 어렵게 만들 수 있습니다.
  2. 복잡성: Nest.js는 프레임워크를 처음 사용하는 개발자가 탐색하고 이해하기 더 어려울 수 있는 더 복잡한 아키텍처를 가지고 있습니다. 이로 인해 학습 곡선이 길어지고 디버깅 중에 문제의 근본 원인을 찾는 것이 더 어려워질 수 있습니다.
  3. 스택 추적: 추가 추상화 및 기능으로 인해 Nest.js의 스택 추적은 때때로 Express와 같은 단순한 프레임워크에 비해 해석하기 어려울 수 있습니다. 이로 인해 오류의 원인을 정확히 찾아내기가 더 어려워질 수 있습니다.
  4. 툴링: Nest.js 에코시스템이 성장하는 동안 더 오래 사용되어 더 큰 커뮤니티가 있는 Express와 동일한 수준의 성숙한 디버깅 및 프로파일링 툴이 아직 없을 수 있습니다.

 

즉, Nest.js의 디버깅은 본질적으로 Express보다 어렵지 않습니다. 문제는 주로 프레임워크 설계의 차이와 Nest.js에서 도입한 개념에 대한 개발자의 친숙도에서 발생합니다. 개발자가 Nest.js에 더 익숙해지면 시간이 지남에 따라 디버깅이 더 쉬워집니다. 또한 Nest.js는 디버깅 프로세스 중에 개발자를 지원할 수 있는 훌륭한 문서 및 도구 지원을 제공합니다.

 

 

Nest.js와 스프링 프레임워크 그리고 그 미래에 대하여

Node.js로 웹을 시작하는 경우, 으레 대부분의 책들이 그렇지만 Express Generator를 통하여 FP로 시...

blog.naver.com

 

<참고>

- https://blog.logrocket.com/nestjs-vs-express-js/
- https://velog.io/@leo3179/Nest.js-%EB%A6%AC%EB%B7%B0
- https://velog.io/@cm961115/NestJS-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0
- https://choseongho93.tistory.com/318

 

NestJS vs. Express.js - LogRocket Blog

Compare NestJS and Express.js based on their features, architecture, community support, and more, for your Node.js project.

blog.logrocket.com

 

 

Nest.js 리뷰

Nest.js nest.js는 제가 백엔드 개발을 시작하고 가장 처음 접한 프레임워크이자 가장 많이 사용한 프레임워크입니다. 지금으로서는 이 nest.js를 통해 서버를 만드는데 익숙해졌지만, nest.js를 왜 사

velog.io

 

 

[NestJS] 알아보기

NestJS Framwork에 대해 알아보자.

velog.io

 

 

NestJS과 Express의 개념 & 비교 (차이점, 특징 등)

● NestJS란? Nestjs의 공식 사이트 Nest (NestJS)는 효율적이고 확장 가능한 Node.js서버측 애플리케이션을 구축하기 위한 프레임워크입니다. 프로그레시브 자바스크립트를 사용하고 TypeScript로 빌드되

nanbuja.com

 

https://tv.naver.com/v/33919001

 

NAVER D2

싸늘하다, 메신저에 경보가 날아와 꽂힌다 - 네이버 검색 SRE 시스템 개선기

tv.naver.com

 

발표 요약

: 장애 대응 최적화를 위한 네이버 검색엔진 시스템의 개선기 소개

 

AS IS - TO BE

[AS-IS] 배치 구조의 모니터링 시스템 [TO-BE] 스트리밍 구조의 모니터링 시스템
  • 장점:
    • 일정 주기로 데이터를 수집하고 처리하기 때문에 일괄 처리가 가능합니다.
    • 대용량 데이터를 처리할 때 적합합니다.
    • 수집된 데이터를 미리 가공하고 처리할 수 있어서 데이터 분석에 유용합니다.
    • 배치 작업은 예약 시간에 자동으로 수행될 수 있어서 운영과 관리가 편리합니다.
  • 단점:
    • 데이터 수집 주기가 길다보니 데이터 처리 결과를 빠르게 반영할 수 없습니다.
    • 대용량 데이터 처리가 일정 시간 내에 불가능할 경우, 딜레이가 발생할 수 있습니다.
    • 대규모 트래픽의 경우, 데이터 수집과 처리가 지연될 수 있습니다.
  • 장점:
    • 실시간으로 데이터를 처리할 수 있어서 대용량 데이터 처리에 용이합니다.
    • 데이터 처리 결과를 실시간으로 확인할 수 있어서 이상 상황을 빠르게 파악할 수 있습니다.
    • 데이터 수집 주기가 짧기 때문에 데이터 처리 결과를 빠르게 반영할 수 있습니다.
    • 대규모 트래픽을 처리할 수 있습니다.
  • 단점:
    • 데이터 처리를 위한 하드웨어나 소프트웨어의 설계나 운영이 복잡합니다.
    • 대용량 데이터를 처리할 때에도 일정 시간 내에 모든 데이터를 처리하지 못할 수 있습니다.
    • 데이터 처리에 필요한 인프라 및 기술적인 요구 사항이 매우 높습니다.

 

기존은 각 프로세스의 배치 주기가 있기 때문에 이상 징후를 탐지하기 위한 시간 딜레이가 의사결정을 하는데도 영향을 주며 이로 인한 사용자들에게 장애 피해 발생.

 

기존 시스템의 문제점

1.기존 경보 시스템은 라벨을 직접 생성해서 모니터링 DB에 저장하고 있으며 다시 DB를 조회해 경보를 발송하고 있었음.

→ 이를 지표수집기가 자동으로 라벨을 생성하고 시계열 데이터 베이스에 저장하여 경보 발송.

 

2.전체 경보 처리가 될 때까지 경보 발송에 지연이 생기는 구조

→ 메세지큐 도입으로 실시간 스트리밍 처리. 기존 3분까지 걸리던 파이프라인을 1분 미만으로 단축.

 

3. 사용자 요청에 따라 쿼리를 조절할 수 없는 문제, 지표가 어떤 과정으로 계산된 것인지 알기 어려운 문제 등 존재

→ 시계열 DB를 활용해서 개발 편의성 개선 및 쿼리 커스텀 기능 제공

개발 편의성 개선
- 지표 계산을 위한 로직을 고수준 쿼리에서 처리 → 간결성
- TSDB 쿼리 및 템플릿들을 테이블로 관리 → 선언성
쿼리 커스텀 기능 제공
- 사용자 요청 시점에 TSDB로부터 지표 조회 → 실시간성
- 텍스트 템플릿을 사용한 TSDB 쿼리 변형 → 유연성

 

4. 기존 텍스트 템플릿은 사용자 요청에 따라 동적 쿼리 변경을 목적으로 하지만 중복이 생길 수 있고 핸들링하기에 시간 소요가 많음.

→ Victoria Metrics의 MetricsQL을 적용하므로써 강력한 기능인 With 템플릿을 사용하여 해결

 

위의 개선이 이루어지더라도 네이버같이 수천만이 이용하는 서비스에서는 TSDB 사용시 속도저하가 일어날 수 밖에 없음..따라서 API Server와 TSDB간의 성능개선 실시

오컴의 면도날(Occam's Razor)은 복잡한 현상을 설명할 때, 그 현상을 가장 적은 가정과 개념으로 설명하려는 원칙. 즉, "가장 간단한 설명이 가장 그럴듯한 설명이다" 라는 뜻

 

 

'테크 행사' 카테고리의 다른 글

Data pipeline with Open Source Kafka  (0) 2024.10.25
KotlinConf'24 Global in South Korea  (2) 2024.10.25
World IT Show 2024  (4) 2024.10.25
PostgreSQL Meetup SEOUL  (0) 2024.10.24
인포그램 x GitLap DevOps 밋업  (1) 2024.10.24

이름

Data pipeline with Open Source Kafka

일시 2024년 6월 29일 (토) 13:00 - 18:00
장소 지티플러스 9층 CCoE
홈페이지 http://www.gtplus.co.kr/about/notice/52
일정
  • 카프카의 커넥터는 https://www.confluent.io/hub에서 다운받을 수 있음.
    free license말고 사내에선 confluent kafka를 쓰니까 commercial license까지 가능할듯? (어차피 제네럴 한 것들은 다 free임)
  • KRaft 통해 더 이상 Zookeper를 사용안해도 될 듯? 이중관리를 안해도 되고 (사실 우리가 하는건 하니고 담당팀에서 하시겠지만...)
    성능도 월등이 뛰어나다고 함. 장애 조치도 매우 빨라짐
  • 발표자료

Data_Pipeline_with_OpenSource_Kafka_20240704_v3.0.pdf
2.28MB

이름

KotlinConf'24 Global in South Korea

일시 2024년 6월 29일 (토) 13:00 - 18:00
장소 건국대학교 학생회관 2층 Prime Hall
홈페이지 https://infcon.day/session/
일정

코틀린의 공식 컨프가 아닌 국가별 커뮤니티 세션.

jetbrain이 후원하니 얘네 스티커는 많이 받게 된다. 연사에 안드로이드 개발자가 많이 참여한 것 같다. 

 

Kotlin Compiler K2가 나옴 → 프론트와 백엔드도 코틀린 컴파일러가 다르다고 함.(wasm도 가능)

Frontend Intermediate Representation (FIR) 피르라고 읽음

제약을 포함한 스마트 캐스팅이 된다. 그리고 inline Lamda에서 스마트 캐스팅이 된다!!

|| 뒤에도 상위 타입으로 추론이 됨.

 

왜 자료 흐름 프레임워크에 중점을 두나요?

  • 제어 흐름을 기술하는 것은 개발자의 주요 업무
  • 스마트 캐스트는 인지 부하를 줄여준다
    • 추가적인 언어 구성은 없음
    • 점진적인 확장 가능

 

when 구문에서만 함수형 언어의 "가드" 개념을 도입하게 됨.

이름 기반 비구조화에서 componentN 호출하지 않도록 한다고 함 (2.2부터 가능할듯)

dataarg class  라는 것이 나옴. → 기본 함수의 파라미터만 바뀔 때 오버로드 하지 않도록 기존 파라미터를 Extendable

error object  가 도입이 됨. 대신 이 유니온 타입은 에러를 담을 때만 사용할 수 있다.

 

원시타입이나 참조타입 대신 Value Class 를 사용하는 방법을 이야기함 (코틀린 1.5 이상)

객체를 생성하지 않기 때문에 오버헤드가 없음.

  • @JvmInline  어노테이션을 붙여야함. 
  • 기본 생성 함수는 equals(), toString(), hashCode() 만 존재한다.
    • copy(), componentN() 이 없다. 
  • 불변타입은 1개만 허용한다.
  • === 레퍼런스 비교를 불허한다

 

발표 자료 공유

박준수(Version Catalog) - https://speakerdeck.com/junjaboy/gradle-version-catalog-with-kts-kotlinconf24-global-v0-dot-1

김희망(Project Valhalla) - https://speakerdeck.com/esperar/project-valhalla-value-class-gimhyimang

김용욱(Kotlin 2.0) - https://speakerdeck.com/dalinaum/recap-kotlin-language-features-in-2-dot-0-and-beyond-michail-zarecenskij

이선협(Kotlin Script) - https://speakerdeck.com/kciter/kotlin-script-hwalyonghagi

권혁준(Expressive Kotlin) - https://speakerdeck.com/davidkwon7/refactoring-to-expressive-kotlin

안성용(KMP Success + androidx room) - https://speakerdeck.com/fornewid/android-jetpack-supports-kmp

곽의진(Compose Multiplatform animation & sensor) - https://speakerdeck.com/kwakeuijin/tap-it-shake-it-fling-it-sheep-it-the-gesture-animations-dance

 

이름 World IT Show 2024(WIS 2024)
일시 2024.4.17(수) – 4. 19(금), 3일간
장소 코엑스
홈페이지 https://www.worlditshow.co.kr/main/main.php
일정

 

매년 코엑스에서 진행되는 월드 IT 쇼를 갔다왔다.

삼성, LG, SKT 등 대기업부터 아주 작은 소규모 스타트업까지 다양한 기업에서 참여한다.

3일간 아무때나 부스를 돌아다닐 수 있지만 나는 주로 부대행사에 초점을 두는데 이번에 꽤 흥미로운 아이템들이 보였다.

Software 뿐만 아니라 ICT, 헬스케어, AI, 로봇 등 다양한 IT 분야의 신제품 및 솔루션들이 출품하기 때문에 소비 트렌드를 읽을 수 있고 인사이트를 넓히는데 도움이 된다.

기억에 남는 아이템들은 모바일 여권 Trip.Pass

 

그로스 해킹 올인원 서비스를 표방하는 A/B 테스트 솔루션 핵클.

핵클은 회사로 초청해서 이야기도 들어봤다.

 

카메라 설치만으로 비전/음성 기반 생체 신호를 포착해 맥박, 호흡, 심리적 스트레스를 측정하는 엠마헬스케어

 

사이버펑크에 가까웠던 안구건조증 치료기 누리아이

 

수어를 텍스트로, 텍스트를 수어로 변환해주는 바토너스

이름 PostgreSQL Meetup SEOUL #1. PostgreSQL 100% 활용법
일시 2024년 4월 17일 18:30 - 20:30
장소 삼성역 섬유연합회 2층 컨퍼런스홀 C3룸 (서울 강남구 테헤란로 518)
홈페이지 https://www.meetup.com/pgmeetupseoul/events/300140824
일정
  1. PostgreSQL Opensource에 기여하는 방법에는 코드 커밋만 있는 것이 아니라 테스트도 있다.
    어차피 postgres는 C로 만들어져서 잘 모름..PostgreSQL은 RDB가 아니라 ORDB라고 하는데 (객체 관계형 DB) 그렇게 써본 적이 없다..내가 느끼는 다른 oss rdb와 다른 점은 pg/sql로 함수 만들기가 쉽다..? 프로그래밍 하는 느낌
  2. Logical Replication은 SQL문으로 말아주기 때문에 이기종간 복제가 가능하고 Physical Replication은 저장소에 저장하기 직전 단계를 가져와 복사한다. (바이너리 레벨에서 동일)
    Fail Over는 시스템 장애시 자동으로 백업 시스템으로 전환하는 기능이다. (Slave Node에서 stand by 상태가 active로 변경되는 것)
    발표하시는 분이 엄청난 고수라는 걸 느꼈다. 세션 마치고 현장에서 질문 20~30 개를 막힘없이 대답하심
    나는 클라우드 네이티브에서의 PG사용에 대해 질문했는데 그분 답변이"Cloud Native 환경에서의 Scale in, out은 어플리케이션이나 미들레벨에서 가져가야지 DBMS 레벨에서 가져가면 안된다. "라고함. 도커 이미지로 빠르게 부팅할 수 있는 클라우드 환경과 데이터를 복제해서 정합성을 보장해야 하는 DBMS는 스케일링하는 차원이 다르기 때문인 듯..
    미들웨어를 플렉서블하게 구성해야 한다고 이해했다.
  3. PostgreSQL의 Extension중 하나인 Apache AGE 라고 하는 것에 들었다. PG는 Extension community가 매우 잘 되어 있고 활발하다고 한다. AGE를 설치하면 그래프 데이터베이스로써 사용할 수 있게 되는데 쉽게 말해 일반 RDB의 Row 형태로 보기 힘든 데이터를 그래프 형태로 데이터를 가공해 표현하는 것이다. 데이터 분석 쪽에서 유용하게 쓰일 수 있다고 생각했으나 개발자 레벨에선..? 전혀 쓸 일 없을 듯.. 아무튼 익스텐션은 잘 되어있는 걸로 

이름 Gitlab Korea 밋업 #18 - VSM으로 완성하는 DevSecOps와 SlackBot 자동화
일시 2023년 11월 28일 19시
장소 강남파이낸스센터 21층 대회의실 (개꿀)
홈페이지 https://festa.io/events/4332?q_mailing_7TZRproaY7L87HMKcwfbwHKXcbqy1uMLm8ybD=Rnv3wydphTEADua8Ni8dKQN8dJ1SxHVMRkt6fGYdBYzbcWuTRXJpjDCPm
일정

<GitLab X InfoGrab : DevOps>

1. DevOps VSM 소개
* VSM이란?
Value Stream Management

예를 들어 업무에 대한 백로그를 그루밍하고, 담당자를 할당하고, 코드 커밋을 하고, QA하고
 배포 하는 모든 일련의 과정을 보려고 하는 것임

Value Stream : 개발 생산성을 높여 지속적인 고객가치 제공을 위한 흐름, 이를 개선하는 프로세스
구글의 DORA4 에서 평가 기준을 만듦. 정량적(속도, 안정성), 정성적 평가가 존재
Gitlab Value Stream Analystic : 일에 대한 트래픽이 얼마나 몰리는지 확인할 수 있다.
Analystics Dashborad를 통해 데이터를 측정, 가시화
PR을 머지까지의 소요시간을 보고 어떠한 업무가 오래 걸릴 수 밖에 없었는지 확인 및 대비 가능하게.

warp up => 낭비(다운타임)을 줄이고 자동화(업타임)을 늘려 고객 만족 획득 기회 늘어남.
낭비 - 재작업, 반복작업, 고객에게 필요없는 고퀄작업, 오버 프로덕션, 대기시간, 불필요한 작업 등

---
GitLab을 통한 CI/CD를 이용한다면 이에 대한 플로우와 데이터를 시각화하여 보여주는 기능같음.

2. 자동화 구현 시연 
Triage 라는 봇을 활용해 MR 시에 openai api를 이용해 챗GPT가 코드 리뷰를 진행하는 과정을 데모로 진행.
정책에 의해 이슈 관리 자동화를 시도함.
라벨, due date등이 자동으로 설정

빌드, 패키지, 테스트, 보안검사 등을 파이프라인 자동화 진행을 통해 VSM 개선

Gitlab Compliance 프레임워크 : 파이프라인을 다양한 어플리케이션에 주입(유료)

 

3. 사내에서 업무 협업툴로 wiki를 사용하는만큼 노션 자동화엔 그닥 얻을 건 없었다는 점

 

밋업이 끝나고 다른 개발자 분들과 네트워킹을 했는데 재미있었다.

 

이름 OpenTRS: 프론트엔드 개발자라면 지금 바로 알아야 할 Front-End 취약점 극복 방안
일시 2023년 9월 14일 (목) 16:00 ~ 19:00
장소 더에셋빌딩 18층 (네이버D2SF) , 서울 서초구 서초대로74길 14
홈페이지 https://event-us.kr/theori/event/69964
일정

<프론트엔드 보안 위협 어떻게 극복할까?>

Part 1. Securing the Front Lines: Protecting Front-End Applications from Overlooked Vulnerabilities

  • 왜 지금 Front-End 취약점이 중요할까요?
  • Real world에서 발견된 Front-End 취약점 사례를 살펴보고
  • 대응 자동화 방안 시연(데모)합니다
  • Front-End security 에서 빼놓을 수 없는 "CSP" 에 대해서도 짚어드려요!


* nodejs 환경변수에 있는거 번들링 할 때 다 주입되나?
ex) process.env.TOKEN
* nextjs의 _buildManifest.js 안에 들어있는 routing navigation은 다 보인다.
* 디버깅을 위한 source map -> 위험하다고 하는데 외부 공개가 얼마나 위험한지?
-> apm 툴을 이용해서 source map을 넣어 디버깅하는게 best practice

* Content integrity (CSP, SRI)
-> src 태그에 integrity hash 하드코딩 하는 이유
-> 근데 로드하지 못하는 경우가 있는 리스크
-> headless browser 를 통해 먼저 스캐닝하고 시뮬레이션 해보고 가용성 확보해라.
CSP를 통한 외부 도메인으로부터 불러온 리소스 디텍션.

 

 

Part 2. How (Not) to Sandbox Node.js: vm2 Postmortem

  • vm2 라이브러리 구현을 분석하고
  • vm2 취약점의 case study를 해봅니다.
  • vm2 사용 사례와
  • vm2를 통해 OSS 의존성 및 공급망 보안 문제를 살펴봅니다


* vm 안에 어떠한 context라도 넣으면 
-> js로 만들어진 js패키지는 안전할 수 없다고 생각한다고함.
vm2를 사용하는 라이브러리를 사용하는 라이브러리 쓰면 개발자 잘못?
Q) 그럼 보안담당자가 어떻게 사전감지?
A) 현실적으로 모두 audit하는건 불가능..deploy cycle에 security가 들어가야 하는 것아닌가

Part 3. 보안적 관점에서의 Front-End 자격증명 정보 관리와 브라우저 데이터 저장소 선택의 장/단점

  • 적절한 자격 증명 정보 관리와 브라우저 데이터 저장소 선택이 중요한 이유는 무엇일까요?
  • Front-End 자격 증명 정보 관리와 브라우저 데이터 저장소 선택의 장단점을 살펴보고
  • 공격 시나리오로 인해 발생 가능한 문제(Front-End 자격증명 정보 관리 취약점)의 장단점과 해결 방안을 제시합니다.


* JWT
* cookie, local-storage, session-storage 
* XSS는 아실거고..CSRF 아시나요

'테크 행사' 카테고리의 다른 글

PostgreSQL Meetup SEOUL  (0) 2024.10.24
인포그램 x GitLap DevOps 밋업  (1) 2024.10.24
Microsoft X GitHub Roadshow 2023  (0) 2024.10.24
HashiCorp Strategy Day 2023  (4) 2024.10.24
오라클 밋업 - 올리브영 사례  (1) 2024.10.24

이름 Microsoft X GitHub Roadshow 2023 - Level Up with GitHub Copilot & Codespaces
일시 2023년 5월 15일 (월) 13:00 ~ 17:30
장소 코엑스 컨퍼런스룸 3F 300호
홈페이지 https://infcon.day/session/
일정

 

4가지 세션으로 이루어진 Github Codespaces 기반의 데모 위주 밋업이었다.

마소에서 각 세션에 대해 라이브 코딩을 진행하는 대담함을 보였으나 역시 오류 뻥뻥(...)

Microsoft는 Azure를, GitHub은 Codespaces와 Copilot을 홍보하는 자리.

 

라이브 데모 레포 : https://github.com/Azure-Samples/gh-codespaces-copilot-in-a-day-ko

Codespaces 데모 레포 : https://github.com/gh-productivity-workshops/PetSpotR

코드 버튼 클릭 후 Codespaces 탭에서 새 Codespaces를 생성하면 됨.

Codespaces는 브라우저 기반 IDE로 보임.(workspace 대신 code spaces!) 

Visual Studio Code와 같은 UI를 사용함. Extension 설치도 가능함. 별도로 로컬에 VSC를 설치하지 않아도 웹 브라우저 내에서 IDE를 사용한다는 점에서 편리해보임.

개발 자체를 Codespaces를 이용하고 Github Action등과 같은 서비스 연계, Credential도 public하게 관리하지 않는다는 것을 보여줌.

OpenAI와 Microsoft 협업으로 Azure AI라는 것을 만들어둠. ChatGPT API를 이용하는 것

Resource에 대한 정의는 json이나 yaml을 사용하지 않고 Microsoft에서 만든 bicep을 사용함. BICEP 확장자에 대한 이야기 (https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep)
GitHub Copilot을 잘 사용하기 위해선 주석을 잘 작성해야 함. 주석으로 명령을 하고  몇 초 뒤 작성코드의 예시를 뿌려줌. 그러나 작성해준 그대로의 코드를 온전히 사용한 적은 별로 없는 듯. Copilot은 완벽한 코드를 만들어주는 것이 아니라 내가 Review를 한다는 느낌으로 작성하라고 함


Codespaces 자체는 훌륭해보임(VSC user 한정). 컨테이너 환경이기 때문에 config잘 설정해두면 중복으로 설정할 필요가 없음. 즉 개발자마다 각각 개발환경을 구축할 필요가 없다는 점에서 starter kit의 역할을 해줄 수 있을듯. Docker container처럼 실행환경을 fix하는 것이 아니라 개발환경을 fix하는 것의 차이. 다만 브라우저 기반이라 사용하지 못하는 단축키가 많을 듯..?

 

이름 HashiCorp Strategy Day
일시 2023년 4월 11일 (화) 14:00 ~ 17:30
장소 양재 엘타워 6층 그레이스 홀
홈페이지 https://events.hashicorp.com/KRstrategyday2023
일정

우리 회사도 하시코프의 Vault를 사용하고 있다. 실무 적용과 관련해  Security실 김용재님이 직접 세션을 진행하였다.

하시코프의 공동창업자 겸 CTO인 '아몬 데드가' 라는 분이 직접와서 키노트를 진행한다길래 흥미가 생겨 참가하였다.

입장하자마자 다양한 다과와 음료, 샌드위치 등을 줘서 점심 못 먹고 참여한 사람이 좋아했을 듯.

메가존 클라우드 등 하시코프 제품과 연계해 솔루션을 제공하는 업체들이 각종 굿즈를 줬다. (아주 만족)

 

key note

- 다양한 클라우드 환경에서 인프라는 일관적인 접근방식을 취해야한다.
- As-is : 인프라 작업은 ticket 별로 ops의 작업을 기다려야함. 일주일씩 지나가버린다.
- To-be : ci/cd 파이프라인, api 구축 등으로 automation 하여 언제든 작업 가능.
- 자기네는 4가지 중요한 영역에 적합한 제품이 존재
Provisioning - Terraform, Packer. Packer를 통해 클라우드 플랫폼 종속성 탈피
Security - Vault(Machine to Machine), Boundary(Human to Machine)
Connectivity - Consul
Runtime - Nomad / K8S, Waypoint 

전세계 수천의 고객이 있으니 한번 츄라이 츄라이

 

Zero-trust

- 기본적으로 믿지 않는 다는 것
- Explicit authority, Default Deny Policy
- 기존의 모놀리틱 구조에서는 방화벽 안에만 있으니 웹서버의 계정, db의 계정이 그 안에 하드 코딩 되어있는 것이 괜찮았다. 허나 클라우드 환경이 되어가면서 외부 어택을 고려해야함. 
- 기본적으로 deny하고 인가된 계정만 allow 하는 것이 실용적이다.
- 또한 ip 기반으로 방화벽하던 모놀리틱 구조와는 달리 클라우드 컨테이너 환경에서는 ip만으론 변경이 잦기에 통제하기 어렵다. 따라서 identity based Control로 가야한다. 

김용재님 발표 세션
- Valut 만능 아니다.
- custom 반드시 필요하다. 현업에서 어떻게 적용해야 하는지 현실적으로 설명하심.

유튜브에 관련 영상이 올라왔다!(자막을 달아줄 법도 한데..)

 

그 뒤에 아모레퍼시픽 세션부터는 이슈 대응을 하느라 참여하지 못했다..

https://www.youtube.com/watch?v=y6vAc8bv0vE

https://www.youtube.com/watch?v=eyL6JgxEm_M

 

이름 오라클 밋업 - 폭주하는 트래픽을 오라클 클라우드로 안정적으로 처리한 올리브영 사례 알아보기
일시 2023년 3월 22일 (수) 14:00 ~ 15:00
장소 한국오라클 (아셈타워 15층)
홈페이지 https://eventreg.oracle.com/profile/web/index.cfm?PKwebID=0x823746abcd
일정

올리브영 x 오라클 밋업. 한시간 남짓 짧게 열린 밋업 세션.
* 올영 세일은 분기당 1회, 연 4회. (우리는 이제 빅 페스타 등으로 매달,,)
* 올영 인프라팀의 미션 : 올영 세일 기간 때만 인프라 확장을 통한 트래픽 감당
1. network -> 탄력적 증설 불가
2. server(ap) -> 탄력적 증설 가능
3. db -> 탄력적 증설 불가 -> 이게 문제


* 참고로 이당시 올영은 MSA가 아닌 모놀리틱 구조임.

해결 선택지도 3개
1. DB H/W 증가 -> 비싸
2. opensource DB -> 응 안돼
3. MSA 구축 -> 되겠니

mysql 처럼 Replication 구성하면 ?
1. 구성하기 위한 방법 CDC(Change data capture) -> Oracle GoldenGate
2. Replica License
3. Application 수정
- Dynamic Datasource : 동적으로 datasource 수정
- Spring AOP : @ReplicateDataSource 같이 어노테이션 만들어서 분기 처리 할 곳에 사용하기.

-Replication 적용할 때 insert/update 같은 DML 사용하면 Exception발생하니 주의.
-모든 어플리케이션에 걸지 말고 필요한 거에만 top20 적용.
-GoldenGate도 sec단위 지연 발생하니 결제 같은 critical service에서 사용하면 안됨.
-상품 전시, 리뷰, 검색, 쿠폰 등에 적용 가능.

그럼 결국 select 부하만 줄인건가? 만약 insert/update 트래픽이 늘어난다면?
-> 이커머스 특성상 트래픽의 90% 이상은 select 할 때 발생. 따라서 replication 전략이 가장 효율적



요새 OCI에 대해 저렴하게 좋은 기능을 제공한다는 평이 많다.
이번 기회에 자세하게 알아볼 수 있어서 좋았다.
실제로 우리회사는 모놀리틱 구조가 아니기 때문에 현실적으로 적용할 것은 별로 없었지만 만족한다.

'테크 행사' 카테고리의 다른 글

Microsoft X GitHub Roadshow 2023  (0) 2024.10.24
HashiCorp Strategy Day 2023  (4) 2024.10.24
[DEVIEW2023] LiveOps: 네이버앱의 실시간 운영과 크래시 핸들링 솔루션 정리  (2) 2024.10.18
DEVIEW 2023  (1) 2024.10.18
INFCON 2022  (2) 2024.10.17

일단 추천 알고리즘이 들어가기 시작하면 매우 복잡해진다. 여기선 아주 단순하게 구현할 수 있는 방법을 적어본다.

실시간으로 현재 인기 있는 게시글 상위 10개 정도를 추천하기 위해서 판단 기준이 필요하다.

  • 구매순
  • 조회순
  • 좋아요순
  • 댓글순

 

활동 로그를 이용한 실시간 적재

유저가 좋아요, 구매 등이 발생하면 이 테이블에 로그를 기록해 둔다. 

ACTIVITY_LOG_TABLE

Logical Name Physical Name Data Type Length 비고
활동로그 번호 ACTIVITY_LOG_NO number 19 PK
게시글 번호 POST_NO number 19 FK
활동 종류 ACTIVITY_TYPE varchar2 20 ORDER,
VIEW,
LIKE,
COMMENT
활동 수 ACTIVITY_CNT Int  
생성자 CREATED_BY number 19
생성일시 CREATED_AT timestamp    

Index는 POST_NO, CREATED_AT 두 컬럼을 사용한다.

유저가 게시글에 구매, 조회, 좋아요, 댓글이 달리면 기록하기 위한 테이블인데 물론 행동이 발생할 때마다 1 row씩 삽입하는 건 꽤나 비효율적일 것이다. 그래서 Redis 같은 Cache Store에 먼저 등록해 두고 일정 주기로 DB로 insert 할 수 있도록(Write-Back) ACTIVITY_CNT 컬럼을 두었다.

 

Redis 사용 전략

Value를 increment 만큼 증가시키는 HINCRBY 커맨드를 사용한다.

# 특정 사용자(77777)에 대해 views 증가
HINCRBY post:metrics:{postNo}:{userId} views 1

# 좋아요와 댓글은 삭제가 발생할 수 있다. 삭제 API 호출시에는 -1을 increment 해준다.
HINCRBY post:metrics:{postNo}:{userId} comment -1

# 모든 사용자 키 검색
KEYS post:metrics:{postNo}:*

다만 현재 키 계층구조에서 게시글 이후의 업데이트 대상 key만을 조회하려고 한다면 (모든 사용자 키 검색) 경우에 따라 사용하는 커맨드가 달라질 수 있다.

KEYS 커맨드는 Cluster Mode에서 사용할 수 없다. 정확히는 목적지 Node를 명시해야 해당 Node 에서만 탐색이 가능하다. 따라서 이 상황에서는 SCAN 명령어를 통해 조회하는 편이 낫다.

HGETALL 커맨드도 사용할 수 없고 키 조회 자체가 정책적으로 금지되어있다면 차라리 키만 SET에 담아서 DB에 insert 하고 지우는 방법도 있겠다.

# 메트릭을 저장할 Set 생성
sadd post:metrics post:metrics:{postNo}:{userId}
smembers post:metrics

 

5분 정도 주기를 설정해서 Redis에 누적된 데이터를 DB로 전송하는 스케줄링 작업을 세팅한다. 스프링 멀티모듈 사용하고 있다면 batch 모듈 만들어 작업할 수 있고 단일 작업이라 jenkins 같은 cicd 툴 이용해서 엔드포인트 호출하는 식으로 가능할 것 같다. cron 도 가능할 거고.

 

가중치를 이용한 분석 및 노출

특정 시간에 실시간 추천 게시글로 노출이 됐던 목록을 알아내려면 조회용 테이블이 따로 필요하다.

로그 테이블에 있는 데이터를 기준으로 조회 테이블에 데이터를 전부 다 넣고, 가중치에 따른 점수 계산을 실행한다.

그리고 기존 데이터는 inactive 상태로 변경한다. 

POST_METRICS_TABLE

Logical Name Physical Name Data Type Length 비고
메트릭 번호 METRICS_NO number 19 PK
게시글 번호 POST_NO number 19 FK
구매수 ORDERS number 5  
조회수 VIEWS number 5
좋아요 수 LIKES number 5  
댓글수 COMMENTS number 5  
점수 SCORE number 5,2  
상태 STATUS varchar 10 ACTIVE,
INACTIVE,
DELETE
생성자 CREATED_BY number 19
생성일시 CREATED_AT timestamp    
수정자 MODIFIED_BY number 19  
수정일시 MODIFIED_AT timestamp    

Index는 POST_NO, SCORE, CREATED_AT 를 사용한다.

 

그리고 가중치를 조절할 수 있도록 테이블을 생성하고 admin 서비스를 통해 조절하게 한다.

POST_METRICS_WEIGHT_TABLE

Logical Name Physical Name Data Type Length 비고
메트릭 번호 WEIGHT_NO number 19 PK
활동 종류 ACTIVITY_TYPE number 19 ORDER,
VIEW,
LIKE,
COMMENT
가중치 WEIGHT number 5,2  
상태 STATUS varchar 10 ACTIVE,
INACTIVE,
DELETE
생성자 CREATED_BY number 19
생성일시 CREATED_AT timestamp    
수정자 MODIFIED_BY number 19  
수정일시 MODIFIED_AT timestamp    

그리고 초기 데이터를 넣어주면 된다.

 모바일 플랫폼의 한계

기존 운영정책 방식과 장애 대응 방식의 한계점

DevOps를 활용한 Lead Time 개선 : 사용자에게 변경사항이 전달하려면 다음 배포 일정에 도달

강제 업데이트 : 사용자 친화적인 UX가 아님

예외 사항 처리, Test Code : 외부 SDK, 단말별 이슈 등으로 모든 이슈에 대응하기 어려움

 

What is LiveOps?

네이버 앱의 철학과 이를 기반으로 생성된 LiveOps 솔루션

  • 더 좋은 서비스를 빠르게 알리고 delivery 할 수 있도록 한다.
  • 보다 안정적이고 최적화된 서비스를 운영할 수 있도록 한다.
  • 사용자를 더욱 이해하고 개별 요구 사항을 충족할 수 있도록 한다.

이벤트를 Hooking하여 config에 설정한 내용을 실행시킴.  특정 타겟층만을 설정하여 해당 타겟층의 반응을 살펴보고 운영 유지 여부 결정.

Firebase remote config에서 제공하는 NRC SDK라는 솔루션의 개선버전. 미리 앱에 코드를 심어줘야하는 NRC와 달리 네이버의 NCE는 미리 코드를 심어줄 필요가 없다.

 

LiveOps Flow

크게 위의 3가지 side가 존재.

 

Core SDK NRC(Naver Remote Config) NCE(Naver Codeless Event)
Fetch / Active Interface 제공
  • 서버를 통해 data fetch 및 local fetch/active 상태관리
Data Transmission
  • 서버에서 console 상에 세팅된 값을 json 포맷으로 SDK에 전달
  • 서버 트래픽 비용 절감을 위해 ETag기반의 서버캐시 운영
Targeting 전략
  • 앱에서 주입하는 다양한 정보를 기반으로
    환경 및 사용자 대상 targeting 지원
getConfig Interface 제공
  • getConfig 함수를 이용하여 콘솔을 통해 받아온
    특정 key 값에 대한 value 값 제공
Auto Hooking & strategy
  • Event를 hooking 하여 제공되는 전략 수행
Event Blocking & Counting
  • 전략 주입 시 기존 로직 실행여부를 optional하게 설정 가능
  • 전략 수행 횟수 설정 가능

위 요소들을 가지고 웹 UI Server에서 조건식 설정. 

 

NCE(Naver Codeless Event)

Bytecode instrumentation(바이트코드 계기화)은 실행 가능한 프로그램 코드(바이트코드)에 대한 동적 분석을 수행하는 기술.

프로그램이 실행될 때 바이트코드에 추가적인 코드를 삽입하여 프로그램의 동작을 분석하거나 수정하는 것을 의미 (Scavanger의 원리)

 

LiveOps 도입 효과 및 향후 계획

LiveOps를 활용한 배포 프로세스NCE Event Hokking 시점 추가 및 전략 추가NCE Network I/O 기능 강화

  • Feature 점진적 배포
  • Feature | Rollback 프로세스
  • A/B 테스트
  • Event 후킹 시점 추가
  • Event 후킹 시 활용 가능한 전략 추가
  • Network I/O Event 후킹시 전략 추가

'테크 행사' 카테고리의 다른 글

Microsoft X GitHub Roadshow 2023  (0) 2024.10.24
HashiCorp Strategy Day 2023  (4) 2024.10.24
오라클 밋업 - 올리브영 사례  (1) 2024.10.24
DEVIEW 2023  (1) 2024.10.18
INFCON 2022  (2) 2024.10.17

이름 DEVIEW 2023
일시 2023년 2월 27일 (월) 09:00 ~ 2월 28일 (화) 16:45
장소 코엑스 브랜드볼룸
홈페이지 https://deview.kr/2023
일정 세션이 너무 많아 위 사이트에 나옴

난 2일차 28일에 참여해 아래 6개의 세션을 들었다.

전부 온라인에 공개되었다.

  1. 자바스크립트 화이트박스 암호와 
크롬 라인 메신저의 보안 강화
  2. 웨일 브라우저 오픈 소스 생존기
  3. LiveOps : 네이버앱의 실시간 운영과 크래시 핸들링 솔루션
  4. 그 여자 APP, 그 남자 SDK: Kotlin Multiplatform 적용기
  5. 런타임 데드 코드 분석 도구 Scavenger - 당신의 코드는 생각보다 많이 죽어있다.
  6. 싸늘하다, 메신저에 경보가 날아와 꽂힌다 - 네이버 검색 SRE 시스템 개선기

그중 두개를 정리해본다.

이름 INFCON 2022
일시 2022년 8월 26일 (금) 13:00 ~ 19:15
장소 코엑스 브랜드볼룸
홈페이지 https://infcon.day/session/
일정

본인은 인프런을 회사 다니면서 들어보기 시작해서 잘 모른다. 그런데 주니어 개발자들 사이에선 세션 발표자들이 마치 스타 강사를 보는 것과 같은 동경심이 느껴졌다. 규모도 상당히 크고 많은 무신사, Jetbrain 등 테크 기업들이 부스를 통해 굿즈를 전달했다. 근데 그 줄이 너무 길어서 받기 엄두가 안날 정도였다.

전체적인 분위기, 규모, 소통 등에 있어서는 괜찮을지 모르나 정작 중요한 세션은.. 동시에 여러 세션이 진행되기 때문에 인기 있는 세션은 서서 듣는 사람도 많았다. 근데 그 와중에 앉아서 조는 사람도 많더라...ㅜㅠ

인프콘 다시 보기 : https://www.inflearn.com/course/infcon2022

추천 세션 :

  • 실전! 멀티 모듈 프로젝트 구조와 설계, 김대성
  • 사이드 프로젝트 만세! - 기술만큼 중요했던 제품과 팀 성장기, 방진호

+ Recent posts