[활동/데보션 영] 데보션 테크데이 - OpenLab 성장 스토리(2) 🔥 : DEVOCEAN YOUNG 3기

👾데보션 테크 데이 2부 시작합니다👾

돌아온 데보션 테크 데이 후기 입니다 :)

2부 또한 엄청난 내용들이 많아서 벌써 긴장되네요 ㅎㅎ

 

순서는 다음과 같습니다. 

 

▲나는 왜 코프링 컨트롤러를 더이상 만들지 않게 되었나 (김경환님)

▲SQL로 프로일잘러가 되는 길, LENS (우원님)

▲Kubeflow 알아보기 (김예은님)

▲대규모 시스템 첫걸음 (최윤식님)

▲C++ 개발자가 바라보는 Rust (양유석님)

▲OpenLLM / RAG 업무 필요 사례 (이길호님)

 

그렇다면 힘차게 고고고🔥

 

준비해주신 간식과 커피

 

 

---

나는 왜 코프링 컨트롤러를 더이상 만들지 않게 되었나 

이 발표는 같은 데보션영 3기의 김경환님께서 진행하셨는데요,

저와 같은 도서 스터디이시고 무려 스터디장이십니다 👍

 

항상 여러 경험, 인사이트도 공유해주시고

스터디 내용도 깃허브에 정리할 수 있도록 전부 세팅을 해주셨어요 🙇🏻‍♀️

 

이번에 테크 데이에서 발표를 하신다는 이야기를 듣고 기대를 많이 했는데, 역시 어려운 내용이었습니다,,,,

노션에 적어둔 것을 다시 꺼내보니 "아하, 그렇군"  마인드로 적은게 눈에 보여서 ㅎㅎ

 

우선 글을 정리해두고 나중에 테크 데이 복습을 좀 진행해야겠다는 생각이 들었습니다🤭

꼭 도움이 되지 않을까 싶습니다 :)

 

아래 유튜브 링크 첨부했습니다 🔥

 

https://www.youtube.com/watch?v=6re1a60_KzU

 

 

---

코프링

spring + kotlin + open api

 

https://www.inflearn.com/pages/infcon-2023-tech-kopring?srsltid=AfmBOoq8EXnW6CWguEmr-r_t9Vxct1HmHXt48184Fl85FlYPxnKQLHNT

[INFCON Tech Series #2] 코틀린과 코프링 시작을 망설이는 당신에게 - 인프런 | 스토리

 

 

openAPI

ex ) swagger

 

** OAS (OpenAPI Specification)

프로그래밍 언어에 종속되지 않은 HTTP API를 위한 표준 인터페이스 정의

 

표준화된 포맷 : OAS는 json yaml 형식을 사용해 api를 정의

유연성 : 특정 언어나 프레임워크에 종속되지 않음

코드생성 : openAPI Generator

 

https://docs.tosspayments.com/resources/glossary/oas

OAS(Open API Specification) | 토스페이먼츠 개발자센터

 

OpenAPI Generator

API 규격을 표준화

 

Client SDK

• Spec 파일 기반으로 생성된 SDK
• 수동으로 SDK를 구성할 필요 없이 자동 생성
• 더 쉽게 Server side 의 API 호출 가능

 

Stub Server

• Spec 파일 기반으로 생성된 서버
• 기본적인 서버 코드 베이스를 자동 생성
• Spec 에 작성된 더미 Resp 자동 생성

 

https://ko.wikipedia.org/wiki/%EC%8A%A4%ED%85%81

스텁 - 위키백과, 우리 모두의 백과사전

 

 

spec file

ex : editor.swagger.io

 

client side generate

generate 방법

- npm, homebrew 등을 지원

https://openapi-generator.tech/docs/installation/

CLI Installation | OpenAPI Generator

 

/apis

- API 엔드포인트 별로 생성된 파일들이 있는 폴더

- 각 파일은 특정 API 엔드포인트에 대한 클라이언트 코드와 요청 메서드를 포함

 

/models

- API 요청 및 응답에 사용되는 데이터 모델 클래스들이 포함된 폴더

- 각 파일은 API 에서 사용되는 데이터 구조를 정의

 

코프링 컨트롤러가 필요하지 않는 이유

1. stub server 코드 생성으로 직접적인 컨트롤러 개발이 필요없음
2. 생성된 컨트롤러 부분의 코드를 오버라이드 받아 작성
3. 컨트롤러 부분을 오버라이드 받아 구성하기 때문에 비즈니스 로직에 집중할 수 있음
4. Stub server 코드 내에 Swagger UI 가 적용되어 있기 때문에 실제 봐야하는 소스코드가 더러워지지 않음

 

실제 프로젝트 적용 후기

유튜브에서 살짝 가져왔습니다

 

OpenAPI 규격을 지원하는 Spec 파일이 있을 때 이를 활용해 Client SDK 를 생성해 연동하면,

OpenAPI Generator 가 API 규격을 표준화하기 때문에, 클라이언트가 SDK 이용 Method 호출로 보다 간편하게 개발을 진행할 수 있다. 

 

Q & A

질의응답 시간도 가졌습니다 :)

 

열일하시는중

 

---

 

SQL로 프로일잘러가 되는 길, LENS

LENS 관련 소개서

 

우원님의 위의 발표는 "LENS 서비스" 에 대한 내용이었습니다.

테크 데이날 열렸던 부스 중에서 LENS 도 있었습니다!

 

위의 서비스는, 

→ 우리 회사 DB에 최적화된 생성형 AI가 빠르게 쿼리를 작성해준다면 좋지 않을까?

 

라는 필요성 및 목적을 가지고 개발되었다고 합니다.

 

확실히,,, AI가 쿼리를 작성해준다면 정말 편리할 것 같습니다 👍

 

01

 

아키텍쳐 및 LLM 사용 코드도 설명해주셨습니다🧚🏻‍♀️

쿼리를 다루어야 하는 백엔드 지망생으로서 귀가 쫑긋해지는 발표였습니다

 

프론트엔드 컴포넌트 구조

 

채팅을 입력하고 나서 LLM이 쿼리를 실행하고, 쿼리는 따로 메모리에 저장

마지막에 저장한 쿼리도 조회할 수 있는 전체 프로세스를 위한 컴포넌트 구조

 

앞으로의 방향성

유튜브에서 살짝!

 

Q & A

질의응답 시간도 가졌습니다 :)

 

무서운 질문들

 

 

---

 

Kubeflow 알아보기

 

제 기억이 맞다면, 뭔가 특별한 자격증이 있으셨던걸로,,, 타워크레인,,, WOW

그래서 아마 제가 들으면서, "오 저분 대단하다" 라고 생각했던 것 같아요 🤭

엄청난 경험을 많이 하셨던 분이었습니다!

 

위의 발표는 딥다이브 쿠버네티스 스터디를 통해 배운 내용, 그리고 그걸 바탕으로

쿠브플로우를 사용한 경험에 대해서 소개하는 내용으로 이루어졌습니다. 

 

kubeflow 에 대해서 공부하고 싶으시다면, 아래의 링크를 이용하시면 될 것 같습니다 bb 

 

https://www.kubeflow.org/docs/

Documentation

 

---

 

1. kubeflow란?

Kubernetes + ML Workflow

 

쿠버네티스 환경에서 ML 라이프 사이클의 각 단계를 다룰 수 있는 오픈소스 프로젝트

개발자, 데이터 사이언티스트, ML 엔지니어 등 모두가 모델 구축부터 테스트, 배포까지 ML 라이프 사이클의 모든 부분을 처리할 수 있도록 서비스를 제공

 

2. kubeflow components

pipeline

쿠브플로우 파이프라인

• 쿠버네티스를 사용해 이식과 확장이 가능한 ml 워크플로우를 구축, 배포하기 위한
• 컴포넌트 생성 → 파이프라인 생성 → yaml 파일 (client 생성)

https://www.kubeflow.org/docs/components/pipelines/

Kubeflow Pipelines

 

 

notebooks

 

https://www.kubeflow.org/docs/components/notebooks/

Kubeflow Notebooks

 

 

dashboard

센트럴 대시보드

 

https://www.kubeflow.org/docs/components/central-dash/

Central Dashboard

 

 

automl

 

https://www.kubeflow.org/docs/components/katib/overview/

Overview

 

 

model training

 

https://www.kubeflow.org/docs/components/training/overview/

Overview

 

 

쿠브플로우 document 에 있는 내용들을 가져와 설명해주셔서 좋았습니다 👍

기억이 안날 때는 위의 문서를 보면서 복습하면 도움이 될 것 같아요.

 

어렵도다,,,

 

3. MLOps

유튜브에서 살짝,,,

 

** 여러 클라우드 서비스에서 활용-확장이 가능하다

** 사용하는 가장 큰 목적
- ML 엔지니어, 데이터 사이언티스트, 데이터 엔지니어는 이 부분만이 아닌 서로 여러 부분을 쉽게 활용할 수 있다는 점

 

Q & A

질의응답 시간도 가졌습니다 :)

 

01

 

---

 

대규모 시스템 첫걸음

가장기대했던발표

 

사실, 데보션 테크 데이가 열린다는 이야기를 듣고 발표 리스트를 봤을 때,

"테크 데이 무조건 참석한다!!" 라고 생각했다 ㅎㅎ

가장 먼저 눈에 띄었던 발표 제목이었다 👾

 

그리고 엄청났던 것이, PPT를 100장 넘게 준비해오셨다,,,,

아마 발표 시간을 한참 넘겨서 엄청 많이 알려주고 가셨던 것으로 기억한다.

 

테크 데이 영상,, 전부 데보션 유튜브 계정에 올라가 있고, PDF 파일도 공유가 되어있어서

관심 있으신 분들은 참고해주세용~ 내용이 훨씬 많습니다 :) 

 

https://www.youtube.com/watch?v=7khCnHODJ3k

 

 

 

---

 

00. INTRO

대규모 시스템을 위한 조건

성능 : 많은 트래픽과 많은 데이터를 처리할 수 있어야 함

고가용성 : 장애 상황을 필히 마주치는데, 서비스 중단 시간 없이 시스템을 구성하고 운영할 수 있도록

확장성 : 사용자 트래픽 양과 증가에 유연하게 대처할 수 있도록 설계해야 함

 

01. SERVER

한대의 서버로만 트래픽을 처리하기가 어려워진 상황

 

*scale up

: 간단함

: 서비스를 한대의 서버에서 하고 있어서 거기서 장애가 일어나면 더이상 운영이 어려움

 

SPOF - 단일 장애지점 : 동작하지 않으면 전체 시스템이 중단되는 요소

 

*scale out

: 한대에서 에러가 나도 다른 서버에서 운영해서 고가용성 확보

: 스케일 업에 비해 복잡

 

유저데이터, 세션, 토큰 등 다양한 데이터가 사용됨

새로운 서버에서는 위와같은 데이터가 있지 않기 때문에 에러가 난다.

 

서버 상태를 무상태웹계층 으로 유지

 

영속성 저장소에 데이터들을 저장하고 필요할때 호출해서 사용하면됨.

 

02. DATABASE

CRUD 를 통해 데이터를 호출하고 가져다씀.

데이터베이스를 사용하는데에도 SPOF 가 일어날 수 있음.

 

DB도 또 따로 만들어서 고가용성 확보 가능.

 

더이상 기존 구조로 서비스를 하기 힘들어졌을 때,

성능을 높일 수 있는 방법 고민

 

DB를 복제했으니까 두대 모두 데이터가 존재.

읽기 분배,

a 에서는 CUD 실행

b에서는 R 실행

 

이런식으로 역할 나눔.

CUD 역할은 데이터 일관성 때문에 한 DB에서만 수행해야함,

→ 데이터를 나눠서 보관, **샤딩

 

 

** sharding

사실 이때, 샤딩? 하면서 내가 잘못 들은 말인 줄 알았는데, 중요한 부분이었다,,,,

 

https://aws.amazon.com/ko/what-is/database-sharding/

데이터베이스 샤딩이란 무엇인가요? - DB 샤딩 설명 - AWS

https://techblog.woowahan.com/2687/

DB분산처리를 위한 sharding | 우아한형제들 기술블로그

 

 

03. key-value store

DB 샤딩을 통해서 성능을 높여둠.

그런데 트래픽 더 많아짐. 이 상황에서 어떻게 성능을 또 높이지?

 

메모리 계층 구조에 따른 속도

 

서버와 DB 사이에 캐시레이어 를 도입.

→ 여기에도 문제있음

→ 캐시레이어 가 한대면 여기서도 SPOF 발생 가능

→

 

** 캡 정리 : cap theorem

- Consistency 데이터 일관성

- Availability 가용성

- Partition Tolerance 파티션 감내

: 두 노드 사이에 통신 장애가 발생하는 것 -> 발생해도 잘 돌아가야 한다는 것

 

1) Consistency 데이터 일관성

모든 서버에 데이터가 쓰여진다면, 일관성은 충족

그만큼 성능 저하됨.

트레이드 오프 발생

 

쿼럼 컨센서스 활용

쿼럼 - quorum :

NWR 세가지 매개변수로

사본의 개수 / 쓰기 연산에 대한 쿼럼 / 읽기 연산에 대한 쿼럼

 

위의 연산을 통해 데이터 일관성을 강하게 할지, 약하게 할지 결정

 

2) partition tolerance

모든 멀티 캐스팅 채널을 구축

: 네트워크 장애는 어디서든 발생할 수 있음

: 단점 - (영상참고)

 

가십프로토콜 활용

: 분산형 장애감지 프로토콜

 

멀티캐스팅 보다 훨씬 _________ 하게 할 수 있음

몇몇 노드랑만 연결해도 됨.

 

쿼럼 컨센서스 에 따라 연결방법 다르게 하면됨.

 

약한 쿼럼 접근 사용시, 한대 서버에서 장애 발생 경우 다른 노드가 일시적으로  _______

장애가 복구되면, 장애가 복구된 서버로 이관

 

04. Consistent Hashing

하나의 캐시에 모든 데이터를 저장하는 것이 아니라

분산해서 저장하도록

 

하나에 몰려서 부하가 일어날 수 있음

 

→ 이때 해시함수를 사용해서 고루 분산

 

ex: 서버 4대 에 분산

해시 % 4

 

서버가 추가되거나 삭제되면 대규모 리밸런싱 일어남

 

위의 문제를 해결하는 것이 consistency hashing

 

해시링이 만들어짐 → 서버와 키를 배치해서

여기서 사용되는 해시함수는 전보다 훨씬 복잡한 것 사용

 

05. GUID

티켓 서버

중앙집중형으로 한대만 사용하게 되면

auto_increment

 

티켓서버가 죽을 경우에 모든 시스템이 영향을 받기 때문에 이러한 문제를 해결하기 위해

gui 를 활용해 유효식별자를 만들어보겠습니다.

 

캐시키가 중복되지 않도록 캐시에 키를 저장하는 방법에 대해 알아보았다.

 

위의 방법을 사용해도 키의 중복이 일어날 수 있다.

 

facebook 의 경우에, 위의 서비스에서 하나의 캐시만 사용하는 것이 아니라

로직 혹은 api 별로 잘게 쪼개서 사용할 수가 있는데, 별도의 캐시를 두고 사용할 수 있다.

 

MSA 구조를 통해서 대규모 시스템을 설계하거나 (             ) 을 통해서 설계할 수도 있다.

 

모든 서비스가 자신만의 서비스 특성이 있는데, 상황에 따른 설계가 매우 중요하다.

 

트레이드 오프가 언제나 존재하기 때문에 상황에 맞게 전략을 짜서 적용해 설계를 진행해야 한다.

 

Q & A

질의응답 시간도 가졌습니다 :)

Q. MSA 아키텍처에서 2 phase commit에 단점에는 어떤게 있나요?

 

책에다나와있다고합니다

 

 

** 스터디에 사용된 도서

 

https://product.kyobobook.co.kr/detail/S000001033116

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬 - 교보문고

https://product.kyobobook.co.kr/detail/S000211656186

가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 | 알렉스 쉬 - 교보문고

 

---

 

C++ 개발자가 바라보는 Rust

Rust 와 초면인 나

 

저의 기억으로는,,, 서버 개발을 하셨다가

파이썬을 활용한 AI 개발로 가셨다고 말씀을 해주셨던 것 같습니다 

그래서 아마 Q&A 때 누군가가 익명으로 어떤 삶이 더 행복하냐고 질문하셨던 것 같아요 ㅋㅎㅋㅎ

 

사실, Rust 라는 것도 처음 들어봤고, C++ 은 대학교 1학년 2학기 때 배웠어서 전혀 기억나지 않았기 때문에

정말 발표를 듣는 것만으로도 엄청난 양의 정보를 습득할 수 있었습니다,,,,

 

살짝 인터넷에 검색해봤는데, 이런 비교 자료들이 엄청 많았습니다

다들 관심이 많나봐요, 이 주제에🔥🔥🔥

 

프로님 덕분에 알게되어 다행입니다,,

 

HOT ISSUE

 

---

 

C++ 억까 금지

충분히 안전하게 사용할 수 있는 방법 있음!

 

RUST 의 특징

메모리 안정성

       - 소유권 시스템

       - 빌림과 수명

안전한 동시성

철저한 컴파일 타임 검사

강력한 패키지 관리자(cargo)

제로 비용 추상화

안전한 포인터

매크로 시스템

 

RUST 장점

패키지 매니저 CARGO

컴파일 타임에 에러를 잡아준다

빠른 성능

간결한 코드

FFI (foreign function interface)

 

RUST 단점

빌드시간이 오래걸린다

컴파일 타임에 모든 타입을 검사해야하기 때문

 

높은 진입 장벽

트레이드, 패턴매칭, 라이프타임, enum 등 헷갈리고 가볍게 쓰기 어려운 개념을 잘 써야 빌드가 됨

 

unsafe

핵심기능으로 소개하고 있지만, c++ 과 다르지 않다

하지만 실행은 가능

 

Rust 와 c++

 

이 발표의 제목이

C++ 개발자가 바라보는 Rust    인데, 

 

발표에서 느껴지는 묘한,,, 느낌

네 맞습니다, 찐 주제는 바로 이 아래의 짤인 것 같아요 😂😂😂

 

이것이 바로 찐 결론

 

 

Q & A

질의응답 시간도 가졌습니다 :)

 

기억에남았던질문1

 

기억에남았던질문 2

 

** 스터디에 사용된 도서

 

https://product.kyobobook.co.kr/detail/S000061679532

The Rust Programming Language, 2nd Edition | Steve Klabnik - 교보문고

 

---

 

OpenLLM / RAG 업무 필요 사례

 

01 Background

GPT출시로 인한 LLM 기술이 관심 상승

다양한 OpenLLM 출시

Private LLM에 대한 관심 증가

 

02 Problem & Motivation - RAG 기술과 한계

 

RAG 등장과 사용

필요한 지식 보완

적은 리소스

보안이슈 해결

랭 체인, liamaindex 등 편리한 라이브러리 사용

커뮤니티 활성화

사내에 사용하기 적합한 기술

 

하지만 한계 존재

 

** solution

→ advanced rag

 

03 Solution - Advanced RAG 

01

 

04 Result/FutureWork

AdvancedRAG

• NaïveRAG가 가지고 있는 문제점 해결 가능
• 보안적인 이슈 해결
• LLM을 베이스로 하는 다양한 기능 제작 가능
• 여러 분야에 응용 가능
• Q&A,요약, 코딩 어시스턴트 등

 

FutureWork

• 현재 회사 프로젝트로 진행 -> Hyundai RAG 목표
• GPU사용
• 정형화 된 데이터 준비
• 다양한 기능을 하는 RAG 기반 엔진 도입
• RAFT를 통한 성능 개선

 

Q & A

질의응답 시간도 가졌습니다 :)

 

엄청난 수의 질문들

 

---

테크 데이 후기 🌸

이렇게 모든 발표를 정리해보았습니다!

정리하다가 이해가 되지 않거나 생각이 나지 않는 부분은 모두 데보션 유튜브 를 통해 다시 들으면서 적어보았습니다👍

물론 그러함에도 비어있는 부분들이 있습니다 ㅎㅎ

 

사실 2부 내용에 훨씬 어려운 내용이 많았어서 아마 당시에

듣는 것만으로도 좀 벅찼을 것이란 생각도 드는데요,,

 

이렇게 알차고 많은 내용을 준비해서 알려주신 데보션 프로님들, 데보션영분들 감사드립니다🙇🏻‍♀️

 

저도 나중에 꼭 이렇게 누군가에게 지식을 공유해줄 수 있는 사람이 되고싶네요 ㅎㅎ 

데보션영 활동은 여러모로 저에게 정말 뜻깊은 활동입니다 :)

 

012

 

 

위의 테크 데이 관련해서 자세한 강의 내용이 궁금하신 분들은

아래의 링크 참고하시면 될 것 같습니다 🫶

 

그럼 다음 글로 또 만나요 안뇽~ 

 

https://youtube.com/@devocean?si=-OvvBJ4L3nD09MuM

DEVOCEAN