개요

본 문서는 AresDB에 대한 개요, 특징, 아키텍쳐 등에 대해 설명한 문서이다. 

AresDB란?

Ares DB는 빅데이터 처리를 위한 고성능 데이터베이스 시스템으로, 높은 확장성과 성능을 제공하는 분산형 데이터베이스 시스템이다. Ares DB는 대용량 데이터 처리 및 분석을 위한 목적으로 설계되었다. Ares DB는 시계열 집계 기능을 갖춘 GPU 기반 실시간 분석 DB이다.

아키텍처 - 시스템 구성

Ares DB는 대부분의 데이터를 메모리(RAM)에 저장하여 CPU를 사용한 데이터 수집과 디스크를 통한 데이터 복구를 처리한다. 쿼리 시점에 데이터를 메모리에서 GPU 메모리로 전송하여 GPU에서 병렬 처리한다. 아래 그림처럼 메모리 저장소,메타 데이터 저장소, 디스크 저장소로 구성된다.

https://www.uber.com/blog/aresdb/
https://www.uber.com/blog/aresdb

 

 

아키텍처 - 테이블

  1. 테이블
    1. 대부분의 관계형 DBMS와 달리, AresDB에는 데이터베이스 및 스키마가 없다. 모든 테이블은 동일한 인스턴스에서 동일한 범위에 속한다. 테이블은 Dimension table과 Fact Table로 나뉜다
  2. Dimension Table
    1. 엔티티의 현재 속성을 지정한다. 일반적인 정보를 저장하는 테이블이고, 뒤에서 설명한 Fact 테이블과 달리 시간 저장되지 않기 때문에 항상 일정한 크기에 의해 제한되는 테이블이다.
  3. Fact Table
    1. 시계열 이벤트의 스트림을 저장한다. 실시간 이벤트를 저장하고 시간이 연관되어 시간별로 테이블을 쿼리하는게 일반적이다.

아키텍처 - 특징

  1. 분산 아키텍처
    1. 여러 대의 서버에 데이터를 분산하여 저장하고 처리하는 분산형 아키텍처를 가지고 있다. 이를 통해 빅데이터 처리에 필요한 고성능과 높은 확장성을 제공한다.
  2. 열 지향 저장
    1. 데이터를 열 단위로 저장하는 열 지향(columnar) 저장 방식을 사용한다. 이를 통해 빠른 쿼리 처리와 압축 기능을 제공하여 데이터 처리 성능을 향상시킨다.
  3. 분산 데이터 처리
    1. 분산 데이터 처리를 위한 기능을 제공한다. 데이터를 여러 개의 노드에 분산하여 처리하므로 데이터 처리 성능을 높이고, 장애 대응을 향상시킨다.
  4. 데이터 복제와 장애 허용성
    1. 데이터의 복제 기능을 제공하여 데이터의 안정성을 확보하고 장애에 대비할 수 있다. 노드의 장애가 발생하더라도 데이터의 손실 없이 서비스를 지속할 수 있다.
  5. 다양한 데이터 모델 지
    1. 다양한 데이터 모델을 지원. 관계형 데이터, 시계열 데이터, 그래프 데이터 등 다양한 형태의 데이터를 처리할 수 있다.

장점

  1. 대용량 데이터 처리 및 분석에 효과적인 고성능 데이터베이스 시스템으로 빠른 데이터 처리와 확장성이 뛰어나다.
  2. 분산 아키텍처와 데이터 복제 기능을 통해 높은 안정성과 가용성을 제공한다.
  3. 다양한 데이터 모델을 지원하여 다양한 분야에서 활용이 가능하다.

단점

  1. Ares DB는 고성능 데이터베이스 시스템으로써, 일반적인 작은 규모의 애플리케이션에는 오버 스펙으로 인한 부담이 될 수 있다.
  2. 사용 및 관리가 복잡할 수 있으며, 높은 수준의 기술적 지식이 필요할 수 있다.
  3. 현재의 높은 확장성과 성능은 빅데이터 처리와 분석을 필요로 하는 고급 사용자에게 적합하며, 일반적인 사용자에게는 과도한 기능과 복잡성이 될 수 있다.


GPU 관련 특징

 

  1. 병렬 연산
    1. GPU를 활용한 병렬 연산 능력을 활용하여 데이터 처리 작업을 가속화할 수 있다.
  2. 고성능 쿼리 처리
    1. GPU를 활용하여 복잡한 쿼리 작업을 고성능으로 처리할 수 있다. 예를 들어, 대용량 데이터 집합에 대한 빠른 집계, 그룹화, 정렬, 필터링 등의 작업을 GPU를 통해 효율적으로 처리할 수 있다.
  3. 실시간 데이터 처리
    1. GPU를 사용하여 Ares DB는 대용량 데이터의 실시간 처리를 지원할 수 있다. 높은 처리량과 낮은 레이턴시를 갖는 GPU는 데이터베이스에서 실시간 분석 및 처리가 필요한 경우에 효과적으로 사용될 수 있다.
  4. 확장성
    1. 분산 아키텍처를 기반으로 하며, GPU를 활용한 병렬 처리를 통해 높은 확장성을 제공한다. 새로운 GPU 노드를 추가하여 시스템의 확장이 가능하며, 데이터 처리 성능을 유연하게 확장할 수 있다.

AQL

ares DB는 일반적인 SQL을 사용하지 않는다. JSON 형태의 AQL을 사용하여 프로그래밍에 친숙한 쿼리를 작성하는 것이 특징이다. 

 

SELECT count(*) FROM trips GROUP BY city_id WHERE status = ‘completed’ AND request_at >= 1512000000

SELECT count(*) FROM trips GROUP BY city_id

위 쿼리를 AQL로 표현하면 아래와 같다.

{
  "table": "trips",
  "dimensions": [
    {
      "sqlExpression": "city_id"
    }
  ],
  "measures": [
    {
      "sqlExpression": "count(*)"
    }
  ]
}

JSON 형태의 AQL은 SQL 인젝션 보안 문제에 대한 걱정없이 쉽게 작성이 가능하고, 조작할 수 있다. 또한 이런 형태는 다양한 프로그래밍 코드에서 친숙하게 사용되고 조작될 수 있다.

소스 코드 리뷰

  1. 기본적인 DB연결, 스키마 정의, 데이터 추가, 데이터 조회
#include <ares/ares.hpp>  // Ares DB 헤더 파일을 포함.

int main() {
  // Ares DB 인스턴스를 생성.
  ares::Ares ares;

  // 데이터베이스에 연결.
  ares.connect("localhost", 8888); // 호스트와 포트를 지정.

  // 데이터 스키마를 정의.
  ares::Schema schema;
  schema.addIntegerField("id"); // id 필드를 정수형으로 추가.
  schema.addStringField("name"); // name 필드를 문자열 형태로 추가.

  // 데이터베이스에 스키마를 등록.
  ares.createTable("my_table", schema); // "my_table"이라는 테이블명으로 스키마를 등록.

  // 데이터를 추가.
  ares::Row row1; // 데이터를 나타내는 Row 객체를 생성.
  row1["id"] = 1; // Row 객체에 필드와 값을 지정.
  row1["name"] = "Alice";
  ares.insert("my_table", row1); // "my_table" 테이블에 Row 객체를 추가.

  // 데이터를 조회.
  ares::Query query;
  query.select("*").from("my_table").where("id = 1"); // "my_table"에서 id가 1인 데이터를 조회.
  ares::ResultSet result = ares.query(query); // 쿼리를 실행하고 결과를 ResultSet 객체로 받음.

  // 조회 결과를 출력.
  for (const ares::Row & row: result) {
    std::cout << "id: " << row["id"].getInt() << ", name: " << row["name"].getString() << std::endl;
  }

  // 데이터베이스 연결을 종료.
  ares.disconnect();

  return 0;
}

 

  1. GPU 연산을 활용한 데이터 처리
#include <ares/ares.hpp>
#include <cuda_runtime.h>

// Ares DB에서 GPU를 사용하여 데이터 처리하는 예시 함수
void processWithGPU() {
  // Ares DB 데이터베이스 인스턴스 생성
  ares::AresDB aresDB;

  // GPU 메모리 할당
  float * gpuData;
  cudaMalloc((void ** ) & gpuData, sizeof(float) * 1000);

  // GPU 커널 실행
  myGpuKernel << < 1, 256 >>> (gpuData, 1000);

  // GPU에서 데이터를 가져와서 Ares DB에 저장
  cudaMemcpy(aresDB.getMutableDataPtr(), gpuData, sizeof(float) * 1000, cudaMemcpyDeviceToHost);

  // GPU 메모리 해제
  cudaFree(gpuData);

  // Ares DB 데이터 처리 작업 수행
  aresDB.processData();

  // 결과 처리
  // ...
}

 

 





'Research' 카테고리의 다른 글

PWA 개념과 react에 PWA 적용하기  (0) 2023.02.21
WEB 3.0이란?  (1) 2023.02.17
Jager(예거)에 대해서  (1) 2022.12.26
Git 활용 방법과 브랜치 전략  (1) 2022.11.30
Prometheus(프로메테우스) 개념 및 timescaleDB로 변환  (0) 2022.11.30

 

  • 개요

본 문서는 PWA ( progressive web app )에 대해 조사한 문서이다. 기본 개념, 리액트 웹에 적용하는 방법 등에 대해 설명한다. 

 

  • PWA란? 

PWA는 우리가 웹 브라우저로 접속해서 보는 웹 기반 기술로 만든 ‘앱’이다. 웹 기술로 앱을 만드는 방법은 다양하게 연구되고 있다. 우리에게 친숙한 HTML,CSS,JS, React 등으로 구현가능하고, 심지어 기존 웹을 웹인걸 눈치채지 못하게 앱처럼 만들 수 있는 기능이다. 즉, 네이티브 앱 개발없이 앱을 빠르게 개발할 수 있다는 장점이 있다. 또한, 푸시 알림이나 오프라인 지원 같은 네이티브 앱만의 장점을 전부 제공할 수 있다.

 

  • 사례

우리가 많이 사용하는 사이트 중에도 PWA를 많이 찾아볼 수 있다. 본인도 구글 챗 등의 웹 앱을 PWA로 추가해서 데스크톱앱으로 사용하고 있다. 또, 트위터가 대표적이다. 트위터 사이트에 접속하면 홈화면에 트위터앱을 추가할 수 있다. 웹 사이트 북마크를 저장하는 것처럼 보이지만, 브라우저 창은 숨겨져 앱과 거의 동일한 사용경험을 제공한다. 또, os에 상관없이 한번의 개발로 동일한 경험을 제공한다. 

구글 앱들, 스타벅스, 핀터레스트, 워싱턴포스트, 우버 등도 PWA를 지원한다.

 

  • 네이티브 vs PWA

 

네이티브 앱은 보통 전용 앱으로 개발한다. 요즘은 Flutter와 같은 멀티 플랫폼 언어도 등장하고 있지만, 이 들도 네이티브 앱에 대해 어느정도 알아야 개발할 수 있다. 그러나 PWA는 웹 개발자가 쉽게 앱 개발 (정확히는 앱 사용 경험을 주는 웹앱 ) 을 할 수 있다.

 

  • 장점

 

  • 앱스토어 출시를 위한 비용이 발생하지 않는다.
  • 설치 과정이 필요 없다
  • 개발 비용이 저렴하다.
  • 반응형 웹일 경우 이는 앱에서도 잘 작동한다.
  • 부드럽고 가볍다.
  • 일반적인 웹사이트와 달리 오프라인에서도 동작한다.
  • 검색엔진에 노출된다.
  • 푸시 기능 사용이 가능하다.
  • 구성 요소

PWA를 구성하기 위해서는 크게 3가지 작업이 필요하다.

  • https or localhost
  • service worker
  • manifest.json
  • 적용

 

현재 본인이 리액트로 개발중인 솔루션에 PWA를 간단하게 적용해보았다. 앞서 말한 3가지를 잘 설정하면 어렵지 않게 적용할 수 있다. localhost 환경이기때문에 1번은 생략한다. 

  • service worker 등록
    •  npx create-react-app my-app --template cra-template-pwa
    • 위 코드를 통해 pwa 신규 프로젝트를 생성 후 서비스를 새로 개발하거나, 기존 프로젝트의 root 폴더에 service-worker.js 파일과 serviceWorkerRegistration.js 파일을 그대로 가져와 사용도 가능하다. 직접 서비스 워커 파일을 만들어 사용해도 되지만, 똑똑한 분들이 미리 만들어둔 파일을 사용하면 편리하다. 파일의 코드 내용은 생략한다.

 

  • 필요한 모듈을 설치한다.
  • manifest.json 파일 설정한다.
  • 프로젝트 실행 및 PWA 적용
  1. “yarn add ~” or “npm install ~”
  2. React 프로젝트를 빌드 후 serve 한다. ( npx serve -s build ) 
  3. yarn start / npm start 등의 개발 모드의 실행으로는 PWA를 설정할 수 없다. 반드시 빌드 후 production 모드로 serve한 웹으로 접속해야 활성 가능하다.
  4. 웹에 접속 후 개발자도구 – lighthouse – pwa 체크 후 검증
  5. 아래와 같은 축하 메세지를 받으면 PWA 적용이 완료된 것이다. ( 적용이 가능한 사이트로 인정받은 것이다.)
  6.  
  7. 웹 사이트의 주소창 옆 버튼을 순차로 클릭하면 PWA 웹앱을 데스크톱 앱처럼 활성이 된 것을 확인할 수 있다.
  8. 모바일에서는 아이폰 기준 홈화면에 추가를 누르면 홈화면에 앱 아이콘이 추가되고, 이를 실행하면 주소창 없는 PWA를  실행 가능하다. 



  • Next Plan

본 문서는 PWA의 개요와 기본 적용만 다루었다. 이후 개발을 진행하면서 push 알림과 같은 네이티브 앱의 기능들을 스터디하고 적용해볼 것이다. 네이티브 기능들을 잘 다루고 활용하고 이를 서비스에 잘 활용하면 더욱 좋은 사용자 경험을 만들 수 있다는 기대감과 웹 개발자로서 더 의미 있는 개발을 많이 할 수 있을거라 생각이 든다.



 




 

'Research' 카테고리의 다른 글

AresDB  (0) 2023.04.19
WEB 3.0이란?  (1) 2023.02.17
Jager(예거)에 대해서  (1) 2022.12.26
Git 활용 방법과 브랜치 전략  (1) 2022.11.30
Prometheus(프로메테우스) 개념 및 timescaleDB로 변환  (0) 2022.11.30

 

웹 3.0은 기본적으로 웹 2.0의 핵심인 읽기와 쓰기를 넘어 “소유”의 개념이 더해진 것이다. “탈중앙화된 관리자 개입이 없는 웹”이라고 할 수 있다.

데이터의 저장과 사용, 소유가 사용자에게 주어지는 완전히 개인화된 인터넷 환경을 만들 수 있다는 개념이다.

웹 2.0의 문제

  • 구글, 페이스북, 우버, 에어비엔비 등 WEB 2.0의 대표기업들은 그들의 서비스를 위해 ‘플랫폼’이라는 이름으로 폐쇄적인 네트워크 모델을 구축했다. 개인이 정보를 Read , Write, Publish 할 수 있고 이를 통해 정보는 전파되었고, 이는 곧 소셜미디어 시대의 시작이 되었다.개인 정보가 굉장한 자산이고 이는 엄청난 수익으로 연결된다는 것을 알게 된 기업들은 데이터를 대량으로 적재하기 시작하게 된다. 개인정보 데이터를 사유화하여 독점하고 이를 이용한 서비스모델을 구축하고 , 수익을 창출했다.소셜미디어의 “재미와 편의성”을 “개인 정보 및 보안”과 Trade off 한 결과를 초래하였다.

이러한 문제를 해결하기 위한 “탈중앙화” 개념은 오래전부터 있었지만, 이를 실현할 기술이 없었고 

WEB 3.0에서는 블록체인, 분산원장, NFT 등 이를 실현할 기술이 등장했다.

 

웹 3.0의 등장

  • 플랫폼을 제공하는 기업에 종속되지 않고 컨텐츠에 대한 소유권은 기업이 아닌 사용자가 소유
  • 데이터 분산 저장을 통한 보안성 향상
구분 web 1.0 web 2.0 web 3.0
특징 비교적 탈중앙화 중앙화 탈중앙화
컨텐츠 생성 및 소유 생성, 소유 X (Static) 생성O, 플랫폼 기업 소유 생성O, 사용자 소유

수익 모델 - 사용자 정보로 플랫폼 기업이 수익 창출 사용자의 참여로 수익 배분
인증 / 보안 ID / PW  ID / PW / 기타 인증 가상자산, 프라이빗 키
핵심 기술 WWW, 쿠키 빅데이터, 클라우드 블록체인, NFT, 메타버스

 

  • 플랫폼을 제공하는 기업에 종속되지 않고 컨텐츠에 대한 소유권은 기업이 아닌 사용자가 소유
  • 데이터 분산 저장을 통한 보안성 향상

웹 3.0의 블록체인

  • ‘가트너’의 하이퍼 사이클에 따르면 블록체인은 환멸기를 지나 성숙기로 향하는 중
  • 기술 자체에 대한 관심을 지나 실제 적용 가능한 영역에 투자가 집중되는 단계

웹 3.0의 분산 원장 기술

  • 네트워크에 참여하는 모든 사용자가 모든 거래 내역 등의 데이터를 분산, 저장하는 기술이다. 블록들을 체인 형태로 묶은 형태이기 때문에 블록체인이 되었다. 
  • 블록체인에서 ‘블록’은 개인과 개인의 거래(P2P)의 데이터가 기록되는 장부가 된다.
  • 이런 블록들은 형성된 후 시간의 흐름에 따라 순차적으로 연결된 ‘사슬(체인)’의 구조를 가지게 된다. 
  • 모든 사용자가 거래내역을 보유하고 있어 거래 내역을 확인할 때는 모든 사용자가 보유한 장부를 대조하고 확인해야 한다.

웹 3.0의 NFT

  • 대체 불가능 토큰으로 데이터, 자산의 거래 내역과 소유권을 저장한다. 해당 데이터, 자산, 디지털 작품은 누구나 복제하고 저장가능하다. 디지털 자산은 이미지, 영상, 음악 등이 될 수 있다. NFT는 블록체인에 제작자가 고유 식별자를 처음 입력하는 시점에 생성(민팅)된다. 트위터의 경우 NFT 이미지의 소유자만 프로필이미지로 등록 가능하게 했고, 복제된 이미지를 직접 업로드할 경우 실소유주가 아니란걸 알 수 있다.
{
    name: "이름",
    image: "ipfs://QmPZKvdf9boGsJL2CmMKadsfa2dfFFDfds39zVz96NxkEjBTDMxZoqJHWrEnP",
    description: "설명"
}
디지털 자산의 주소를 ipfs에 저장하기때문에, url 자체에 대한 보안 우려는 줄어듬
Http로 저장된 주소도 사용가능하지만 지양해야함

 

IPFS

    • https 이후의 차세대 통신 프로토콜로 주목 받는 기술이다. '분산 해시 테이블(DHT: Distributed Hash Tables)' '비트토렌트(BitTorrent)' '깃(Git)' '자체 인증 파일시스템(SFS: Self-Certified File systems)' 등 기존에 개발된 P2P 요소 기술을 종합한 분산 파일 시스템이다. 핵심 원리만 차용했을뿐 블록체인 기술은 아니다. https는 클라이언트 : 서버 = 1:1 관계를 가지지만, ipfs는 조각화되고 분산 저장된 데이터를 hash값(고유 id)을 통해 node에게 요청하고 없다면 다른 노드에게 요청하는 방식 ( 수소문(?) 해서 찾아가는 방식)
    • http(s) : 찾는 ‘주소'를 시스템에 전달하여 데이터 식별
    • ipfs : 찾는 ‘대상’을 시스템에 전달하여 데이터 식별

 

WEB 2.0 어플리케이션의 대체로 등장한 WEB 3.0 어플리케이션

마케팅 용어인 WEB 3.0

&ldquo;실리콘 밸리가 &lsquo;월가&rsquo;로부터 투자 유치를 이어나가기 위한 유행, 마케팅 용어일 뿐이다"

 

준비해야할 미래

  • WEB 3.0은 아직 모호하지만, 미래 WEB의 목표인 것은 확실하다.
  • 중앙집중적이고 독점적인 WEB 2.0의 문제를 해소하기 위한 합리적인 주장이면서 목표이다.
  • 아직까지는 뜬구름 잡는 마케팅 용어이지만, 이 목표를 위한 변화는 이미 시작되었다.
  • 한순간에 탈중앙화가 이루어지고 WEB 3.0이 도래하진 않지만, 이러한 패러다임은 반드시 다가올 것 이기때문에 준비 해야한다.

 

'Research' 카테고리의 다른 글

AresDB  (0) 2023.04.19
PWA 개념과 react에 PWA 적용하기  (0) 2023.02.21
Jager(예거)에 대해서  (1) 2022.12.26
Git 활용 방법과 브랜치 전략  (1) 2022.11.30
Prometheus(프로메테우스) 개념 및 timescaleDB로 변환  (0) 2022.11.30

개요

본 문서는 MSA (Micro Service Architecture) 환경을 모니터링 하는데 사용하는 Jaeger(예거 또는 졔거)에 대한 문서이다.

Jaeger란

 

Jaeger는 Uber에서 개발한 분산서비스 간 트랜잭션을 추적하는 오픈소스 소프트웨어이고 MSA 환경을 모니터링하는 프로젝트이다. 다양한 마이크로 서비스의 요청 경로를 추적하고, 요청 플로우를 시각적으로 확인하며 분산 트랜잭션을 모니터링할 수 있다. 이를 통해 대기시간과 성능을 최적화하고, 문제 해결을 위한 원인을 분석할 수 있다.

Tracing이란

단어 그대로 추적이라는 뜻이고, MSA의 수가 많아지고 각 서버 간의 요청 관계가 복잡해지면서 장애 및 병목을 찾아내는 것이 어려워지고 있기 때문에 이를 추적하기 위한 개념이다. 어느 함수에서 시간을 많이 소요하는지, 어느 경우에 지연이 발생하는지 등을 확인할 수 있다. MSA 환경에서는 분산된 수많은 트랜잭션을 로깅하기 위해 Distributed Tracing이라는 개념을 이용한다.

구조 및 특징

 

  • 기본 구조

 

Jaeger Client(deprecated)

OpenTracing API로 만들어진 언어별 구현체. OpenTracing API는 CNCF(클라우드 네이티브 컴퓨팅 재단) 산하의 프로젝트로, 애플리케이션 간 분산 추적을 위한 표준처럼 사용되는 비공식 API이다. Jaeger Client는 Deprecated되었고, OpenTelemetry SDK로 대체된다.

OpenTelemetry SDK (recommended)

Jager Client가 Deprecated되면서 공식으로 사용을 권장하는 SDK이다. 위에서 설명한 OpenTracing과 비슷한 성격의 OpenCensus는 OpenTelemetry라는 CNCF프로젝트로 통합되었다. OpenTelemetry와 Jaeger는 다른 목표를 가지고 있다. OpenTelemetry는 API와 SDK를 다국어로 제공하여 응용프로그램이 프로세스에서 다양한 원격 측정 데이터를 메트릭 및 추적 백엔드로 내보낼 수 있도록 하는 것이 목표이다. Jaeger는 주로 추적 Telemetry 데이터를 수신하여 해당 데이터의 처리, 집약, 데이터 마이닝, 시각화를 제공하는 백엔드이다. OpenTracing/OpenCensus/OpenTelemetry에 대한 설명은 뒤에서 자세하게 설명한다.

Jaeger Agent

UDP를 통해 전송된 Span (분산 추적에서 기본이 되는 블록 단위, 작업 단위)을 수신하는 네트워크 데몬으로 처리한후 Collector로 trace를 전송한다. 타겟 애플리케이션과 같은 호스트에 배치한다.

Jaeger Collector

Agent로부터 Trace를 수신하여 처리 파이프라인을 통해 유효성 검사, index 생성/변환을 수행한후 DB에 저장한다.

Jaeger Query

DB에서 trace를 조회 후 UI구성에 필요한 API를 제공한다.

Storage (DB)

추천되는 DB는 엘라스틱서치 및 카산드라이다. 호환성이 검증된 Promscale를 통한 TimescaleDB(Postgresql 기반 time-series DB), ClickHouse(컬럼 기반 RDBMS) 와도 호환된다. ScyllaDB, InfluxDB, Amazon DynamoDB 등에 대한 지원을 위해 실험도 진행중이다.

 

  • Kafka 구조

Jaeger Ingester

Jaeger collector는 Trace 정보를 DB에 바로 전송하지 않고 kafka에 전송한다. Kafka는 Trace 정보를 Ingester가 데이터를 Polling하여 DB에 기록한다.

OpenTracing / OpenCensus / OpenTelemetry

 

  • OpenTracing

 

  • OpenCensus

 

  • OpenTelemetry (OTel)

특징

  • High Scalability 고려해서 설계됨
  • OpenTracing과 OpenTelemetry을 지원함
  • Modern Web UI (React 개발)
  • Cloud Native Deployment
  • Zipkin과의 역호환성도 지원
  • Topology Graphs
  • System Architecture, Deep Dependency Graph
  • Sampling

샘플을 활용한 실습

Jaeger의 도커 이미지 실행 및 HotROD 라는 샘플 코드를 이용해 테스트환경 실습이 가능하다.

 

$ docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latest

 

위 명령어로 Jaeger를 실행하면 localhost:16686에 Jaeger웹 서비스가 실행된다. 

$ git clone https://github.com/jaegertracing/jaeger
$ cd jaeger/examples/hotrod
$ go run ./main.go all

위 명령어로 HOT ROD 샘플을 실행시키고 localhost:8080에 접속하면 4가지 버튼이 있는 웹 서비스가 실행된다. HotROD는 jaeger에서 제공하는 데모 어플리케이션이고, OpenTracing API를 사용했다. 

HotROD는 여러 마이크로 서비스가 별도 port로 실행되어 간단한 MSA환경으로 동작한다. 8080에 frontend, 8081에 customer, 8082에 driver, 8083에 route라는 이름의 서비스가 각각 실행된다.

 

 

좌측이 Jaeger를 실행한 모습, 우측이 HotROD를 실행한 모습이다. 8080 frontend 서비스에 접속하여 각 버튼을 클릭하면 요청을 하고, 해당 요청에 대해 Jaeger에서 확인할 수 있다.

 * HotROD외에 실제 서비스에 적용하려면, spring boot의 Jaeger Dependency를 이용하여 Jager로그를 남길 수 있다.

 

'Research' 카테고리의 다른 글

AresDB  (0) 2023.04.19
PWA 개념과 react에 PWA 적용하기  (0) 2023.02.21
WEB 3.0이란?  (1) 2023.02.17
Git 활용 방법과 브랜치 전략  (1) 2022.11.30
Prometheus(프로메테우스) 개념 및 timescaleDB로 변환  (0) 2022.11.30

개요

본 문서는 Git을 활용하는 클라이언트, 브랜치 전략, DevOps 등을 정리한 문서이다. Git 자체에 대한 설명, 사용법에 대한 내용은 포함하지 않는다.

GitHub과 GitLab , Git의 효율적인 사용을 위한 클라이언트 

Git을 사용해 버전관리, 소스관리를 하는 사용자라면 필연적으로 듣게 되는 것이 GitHub과 Gitlab이다. 두 서비스 모두 Git을 더 스마트하고 효율적으로 사용하기 위한 웹기반 Git의 3rd party 클라이언트 제품이다. 

GitHub과 Gitlab의 차이를 설명할 때 보통 Gitlab이 GitHub의 확장판, dev ops기능이 추가된 GitHub 등으로 설명되곤 한다. 또, Gitlab은 MIT 라이센스로 코드를 공개함과 동시에 GitHub와 거의 유사한 화면을 구현해 많은 사용자를 끌어들였다. 이후 프로젝트 관리, CI/CD, 패키지 저장소 등의 기능을 추가하여 단순 코드 관리만이 아닌 소프트웨어 개발 전체 라이프사이클을 커버하는 서비스로 발전했다. 

하지만 GitHub도 프로젝트 관리 기능을 강화했고, CI/CD (GitHub action) 및 패키지 저장 기능도 추가해 무료로 서비스하고 있다. 

이외에 컨플루언스 및 지라로 유명한 아틀라시안이 운영중인 비트버킷, SVN제품으로 알려진 tortoisesvn의 tortoiseGit 등 많은 제품이 출시, 서비스 되고 있지만, GitHub가 점유율이 가장 높고, Gitlab이 뒤를 따르며 양분화 하는 추세로 보인다.

GitHub와 Gitlab의 기본적인 소스관리 및 devops외에, Git 도입시 의사결정하는데 중요한 역할을 할 것으로 예상 되는 부분은 “클라우드형 vs 자체 서버구축형”이다. GitHub는 원격저장소에 클라우드 형식으로 올리는 방식이고, Gitlab도 클라우드형식을 지원 하기는 하지만 일반적으로 중앙 서버에 repo를 설치하여 관리하는 방식으로 많이 사용한다. 그리고 비용적인 측면도 크게 작용할 것으로 보인다. GitHub는 실무에서 서비스를 위해 사용한다면 유료결제는 필수이지만, Gitlab는 무제한의 프로젝트 생성과 타 서비스에 비해 매우 큰 10GB의 단일 프로젝트용량을 제공한다. GitHub, GitLab, 비트버킷에 대한 자세한 설명은 잘 정리된 글이 있어 링크로 대체한다. 링크

각 프로젝트에 맞는 Git 브랜치 전략 선택

앞서 말한 GitHub , Gitlab 등 Git 클라이언트 선택도 중요하지만, 그보다 각 상황에 맞는 Git 사용방법론, 정책 수립이 더 중요하다고 생각된다. 특히 브랜치 전략이 실제 업무 및 개발에 있어 중요한 요소인 것 같다. 브랜치 전략에는 정답이 없지만, 통상적인 개발 플로우를 정리하여 제시한 방법론이 존재한다.

이제는 잘 사용하지 않는 SVN은 단일 브랜치 전략을 사용한다. 모든 상황을 제어하는 브랜치가 단 한개이기 때문에 배포버전과 개발버전, Test버전 등이 모두 뒤섞여 관리 자체가 힘들다. 단순히 소스 코드 공유 및 merge툴 정도이다. 이후 Git이 등장하면서 Git 의 브랜치 전략이 등장하는데, Git-flow, GitHub-flow, Gitlab-flow다. 세가지 모두 Git의 브랜치를 어떻게 하면 효율적으로 사용하고 이를 개발 라이프사이클에 잘 녹여낼지 제안하는 방법들이다.

Git-flow는 feature – develop – release – hotfix – master로 브랜치를 구성하는 개발 모델이고, 이는 표준처럼 여길 정도로 대표적인 워크플로우이다. 이 전략은 웹, 앱 등을 가리지 않고 채택되어왔지만, Git-flow를 처음 고안한 nvie라는 개발자는 “ 애플리케이션은 일반적으로 롤백되지 않으며, 지속적으로 서비스를 제공하기에 소프트웨어를 다양한 버전으로 지원할 필요가 없다. 당신의 팀이 소프트웨어를 지속적으로 제공한다면 GitHub-flow 같은 간단한 워크플로우 채택을 제안한다.” 라고 말했다. 즉, Git-flow는 버전 관리가 필요한 앱이나 솔루션, 혹은 public API에 적합한 전략이다. 웹 애플리케이션에서 고려할 전략이 아니다.

두번째로, GitHub-flow다. Git-flow가 가진 가장 큰 문제는 너무 복잡한 브랜치 프로세스이다. GitHub-flow는 Git-flow의 복잡성을 제거하고, 브랜치는 master 하나를 두는 방식을 사용한다. master를 제외한 브랜치는 다른 개발자들에게 맡기기 때문에 복잡한 정책이 필요하지 않다. 또, 웹 애플리케이션처럼 상시 배포가 가능한 프로세스에 적합 방법이다. 아래는 GitHub-flow 정책이다.

 

  • master는 언제든지 배포가 가능하다.
  • 새로운 프로젝트는 master를 기반으로 별도 브랜치를 생성하여 작업을 진행한다.
  • 브랜치는 로컬에 commit하고, 정기적으로 원격 브랜치에 push한다.
  • 피드백이나 도움이 필요하거나, 코드 병합할 준비가 되었다면 pull request를 만든다.
  • 다른 사람이 변경된 코드를 검토한 뒤 승인하면 master에 병합한다.
  • 병합된 master는 즉시 배포할 수 있으며, 배포 해야만 한다.

 

세번째는, GitLab-flow다. GitHub-flow가 제시하지 못한 배포, 환경, 릴리즈 및 소스통합 등 다양한 이슈에 대해 지적하고 추가적인 가이드를 제공한다. “코드를 변경하는 목적은 분명하므로 이슈로 생성해서 관리하자.” 라는 이념으로 코드 변경 사유를 투명하게 공개하는 것이 원칙이다. 

위와 같은 전략을 제시한 이들을 포함해 대부분의 브랜치 전략 수립에 관한 주장에서 공통적인 부분은, 각자의 개발 환경과 상황에 맞게 적절한 브랜치 전략을 수립하라는 내용이다. 버전 관리가 필요한 애플리케이션이라 git-flow를 채택하더라도, 제시한 브랜치 중 불필요한 브랜치가 있다면 사용하지 않는 방법, 메인 브랜치를 master 브랜치 하나만 유지하는 전략을 함께 채택하는 방법 등이다. 또한, SVN의 단일 브랜치 전략은 물론, 너무 복잡하고 Depth가 깊은 브랜치 전략은 피하라는 것이 일반적인 주장이다. 즉, 상황에 맞게 브랜치 전략을 수립하되, 브랜치는 단순하게 가져가야한다.

GitOps , Git을 활용한 DevOps

Git으로 수행되는DevOps라는 뜻의 GitOps는 Cloud native application (클라우드 환경에서 애플리케이션을 구축, 배포, 관리 하는 접근 방식)에 DevOps를 어떻게 적용할지에 대한 방법론이다. 즉, 애플리케이션 배포와 운영에 관련된 모든 요소들을 Git에서 관리하는 것이다. 정확히는 쿠버네티스의 manifest파일을 Git에서 관리하고, 배포할 때도 Git에 저장된 Manifest로 배포하는 과정이다. (쿠버네티스, CI/CD등에 대한 기술적 지식이 부족해 간단한 설명으로 마무리합니다. )

GitLab Global DevSecOps 성숙도 조사

  InfoGrab에서 진행한 GitLab Global devSecOps 성숙도 조사에 대한 링크를 남기는 것으로 문서를 마무리한다. 링크

 

'Research' 카테고리의 다른 글

AresDB  (0) 2023.04.19
PWA 개념과 react에 PWA 적용하기  (0) 2023.02.21
WEB 3.0이란?  (1) 2023.02.17
Jager(예거)에 대해서  (1) 2022.12.26
Prometheus(프로메테우스) 개념 및 timescaleDB로 변환  (0) 2022.11.30

1      개요

문서는 모니터링 솔루션인 프로메테우스에 대한 구조 및 구성에 대한 설명이다.

 

2      프로메테우스란

 

프로메테우스란 시계열 DB를 내장한 메트릭 수집, 시각화, 알림 등의 기능을 제공하는 오픈 소스 모니터링 시스템이다. pull 방식의 메트릭 수집, 시계열 데이터 저장, 전용 쿼리인 PromQl을 활용한 집계 등을 제공한다. 기본 제공하는 시각화 기능은 한계가 있어 일반적으로 Grafana라는 시각화 툴을 함께 사용한다.

3      구조 및 특징

Exporter

Pull 방식으로 데이터를 수집하도록 노출되는 Agent. 서버들로부터 메트릭을 수집해 http endpoint를 제공한다. 프로메테우스는 해당 Endpointhttp get 요청을 통해 수집한다. , Exporter는 일종의 http 서버이고, 요청 당시의 데이터를 get method를 통해 리턴한다.

 

PromQl & Visualization

TSDB에 저장된 데이터를 PromQl을 통해 조회하고, 자체 시각화 web을 통해 조회가능. 그러나 시각화에 한계가 있어서 일반적으로 Grafana를 시각화 툴로 사용

 

Alert Manager

Alert Manager를 통해 특정 룰을 설정해두고 룰에 해당되면 slack, e-mail등을 통해 알림을 받을 수 있다.

Pull방식

Pull방식을 사용하기때문에 메트릭에 대한 데이터를 중앙 서버로 보내지 않아도 된다. , 일정 주기마다 데이터를 직접 pull 해온다.

 

Push Gateway

기본적으로 프로메테우스는 Pull방식이지만, http endpoint에 접근하지 못하는 경우는 pull 방식 사용이 어렵기 때문에, 어플리케이션이 pushgateway에 메트릭을 push한후 프로메테우스는 push된 메트릭을 pull 해온다. pull을 위해 사용하는 exporter는 타겟이 있는 서버에 설치되어야 하는데, 사내망같이 폐쇄적인 곳에 있어 http 접근을 할 수 없는 경우 사용한다.

 

 

 

4      장점

 

l  다차원 데이터 모델 가능

l  모든 데이터는 HTTP (Pull) 방식으로 작동. Push도 가능

l  모니터링 타겟은 YAML 파일을 통해 설정

 

5      단점

 

l  클러스터링이 안됨

l  싱글 호스트이기 때문에 저장용량이 부족하면 디스크 용량을 늘리는 방법 밖에 없음

l  Metric 수집 및 메모리에 저장후 일정 시간이 지나면 Local Disk에 덤프 형식으로 저장하기 때문에 오래된 data는 조회 불가능

l  100% 정확성을 보장하지 않음. 모든 메트릭을 수집하지 않고 사실상 추세모니터링에 적합함. 순간의 스냅샷 정보만 알 수 있음

 

6      TSDB -> TimescaleDB

프로메테우스는 내부적으로 time series db(이하 TSDB)를 기본으로 사용한다. TSDB는 다중 사용자 환경에서 그다지 좋은 성능을 내지 못한다는 이야기가 있다. 이문제를 해결하려면 시계열 데이터를 전문으로 다루는 DB를 사용하는 것도 좋은 방법이다. 또한 원격저장소에 있는 DB에 저장하려는 경우도 생길 수 있다.

프로메테우스는 replicate되지 않으며, long-term 메트릭에 저장에 적합하지 않다. 그래서 다양한 원격 스토리지 저장을 지원한다. 이 지원 방법 중 하나가 TimescaleDB에 저장하는 방법이다. TimescaleDBPostgreSQL기반으로 확장된 시계열DB이다. long-term 메트릭 저장에 적합하고, promQLSQL에 완벽하게 대응한다. 프로메테우스의 로컬 node에 기록된 후에 timescaleDB에 한번더 기록되기때문에 즉시 백업이 되는 셈이다. 따라서 disk에러 등에 대해 피해가 덜 생길 수 있다. TimescaleDB에서는 해당 기능을 총칭하여 PromScale이라고 부른다.

 

프로메테우스에서 TimescaleDB에 원격 write를 하려면 2가지 추가 모듈이 필요하다. pg_prometheusprometheus_postgresql_adapater이다. pg_prometheustimescaledb이고, 어댑터는 둘을 연결해주는 어댑터이다. 두 모듈 모두 도커로 배포되어있어 바로 실행할 수 있다. pg_prometheus를 도커를 통해 run하면 TimescaleDB에 필요한 하이퍼테이블, 스키마 등을 자동으로 생성한다. , 프로메테우스 설정도 일부 변경해야한다. remote_write 옵션과 remote_read 옵션의 url adapter의 주소를 설정한다.

이렇게 설정을 완료한 후 도커를 통해 시스템을 띄우면 정상적으로 timescaleDBremote write할 준비가 완료된 것이다.

아래 그림은 위에서 설명한 내용의 구조도이다.

 

'Research' 카테고리의 다른 글

AresDB  (0) 2023.04.19
PWA 개념과 react에 PWA 적용하기  (0) 2023.02.21
WEB 3.0이란?  (1) 2023.02.17
Jager(예거)에 대해서  (1) 2022.12.26
Git 활용 방법과 브랜치 전략  (1) 2022.11.30

+ Recent posts