# parent.scss
$parent-height: 100px;
# child.scss
@import "./parent";
.card{
height: calc(100vh - #{$parent-height});
width : $parent-height;
}scss 의 변수 문법 사용해서 다른 파일에서 해당 변수를 불러올 수 있다.
일반적으로는 불러온 변수를 달러표시해서 그대로 사용하면되지만,
calc등 css함수를 사용할때는 #{} 안에 넣어줘야 정상적으로 읽힌다
본 문서는 MSA (Micro Service Architecture) 환경을 모니터링 하는데 사용하는 Jaeger(예거 또는 졔거)에 대한 문서이다.
Jaeger는 Uber에서 개발한 분산서비스 간 트랜잭션을 추적하는 오픈소스 소프트웨어이고 MSA 환경을 모니터링하는 프로젝트이다. 다양한 마이크로 서비스의 요청 경로를 추적하고, 요청 플로우를 시각적으로 확인하며 분산 트랜잭션을 모니터링할 수 있다. 이를 통해 대기시간과 성능을 최적화하고, 문제 해결을 위한 원인을 분석할 수 있다.
단어 그대로 추적이라는 뜻이고, MSA의 수가 많아지고 각 서버 간의 요청 관계가 복잡해지면서 장애 및 병목을 찾아내는 것이 어려워지고 있기 때문에 이를 추적하기 위한 개념이다. 어느 함수에서 시간을 많이 소요하는지, 어느 경우에 지연이 발생하는지 등을 확인할 수 있다. MSA 환경에서는 분산된 수많은 트랜잭션을 로깅하기 위해 Distributed Tracing이라는 개념을 이용한다.
OpenTracing API로 만들어진 언어별 구현체. OpenTracing API는 CNCF(클라우드 네이티브 컴퓨팅 재단) 산하의 프로젝트로, 애플리케이션 간 분산 추적을 위한 표준처럼 사용되는 비공식 API이다. Jaeger Client는 Deprecated되었고, OpenTelemetry SDK로 대체된다.
Jager Client가 Deprecated되면서 공식으로 사용을 권장하는 SDK이다. 위에서 설명한 OpenTracing과 비슷한 성격의 OpenCensus는 OpenTelemetry라는 CNCF프로젝트로 통합되었다. OpenTelemetry와 Jaeger는 다른 목표를 가지고 있다. OpenTelemetry는 API와 SDK를 다국어로 제공하여 응용프로그램이 프로세스에서 다양한 원격 측정 데이터를 메트릭 및 추적 백엔드로 내보낼 수 있도록 하는 것이 목표이다. Jaeger는 주로 추적 Telemetry 데이터를 수신하여 해당 데이터의 처리, 집약, 데이터 마이닝, 시각화를 제공하는 백엔드이다. OpenTracing/OpenCensus/OpenTelemetry에 대한 설명은 뒤에서 자세하게 설명한다.
UDP를 통해 전송된 Span (분산 추적에서 기본이 되는 블록 단위, 작업 단위)을 수신하는 네트워크 데몬으로 처리한후 Collector로 trace를 전송한다. 타겟 애플리케이션과 같은 호스트에 배치한다.
Agent로부터 Trace를 수신하여 처리 파이프라인을 통해 유효성 검사, index 생성/변환을 수행한후 DB에 저장한다.
DB에서 trace를 조회 후 UI구성에 필요한 API를 제공한다.
추천되는 DB는 엘라스틱서치 및 카산드라이다. 호환성이 검증된 Promscale를 통한 TimescaleDB(Postgresql 기반 time-series DB), ClickHouse(컬럼 기반 RDBMS) 와도 호환된다. ScyllaDB, InfluxDB, Amazon DynamoDB 등에 대한 지원을 위해 실험도 진행중이다.
Jaeger collector는 Trace 정보를 DB에 바로 전송하지 않고 kafka에 전송한다. Kafka는 Trace 정보를 Ingester가 데이터를 Polling하여 DB에 기록한다.
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로그를 남길 수 있다.
| 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 |
container : 데이터 조작을 다루는 컴포넌트
presentation : 화면을 다루는 컴포넌트
NPX는 그 순간 최신의 소스를 받아와서 설치 후 삭제함
NPM 전역으로 CRA를 설치후 CRA를 하면, 설치 당시의 버전으로 사용해야하고,
나중에 패키지가 업데이트 되면 새로 전역에 설치해야함
또, CRA의 의존성 패키지들을 로컬에 남겨두지 않음
npx create-react-app my-app --template typescriptyarn add -D typescript @types/node @types/react @types/react-dom @types/jest
yarn add sass
// tsconfig.js
{
"compilerOptions": {
"target": "es5",
"lib": [
"dom",
"dom.iterable",
"esnext"
],
"allowJs": true,
"skipLibCheck": true,
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
"strict": true,
"forceConsistentCasingInFileNames": false,
"noFallthroughCasesInSwitch": true,
"module": "esnext",
"moduleResolution": "node",
"resolveJsonModule": true,
"isolatedModules": true,
"noEmit": true,
"jsx": "react-jsx",
},
"include": [
"src"
]
}yarn add -D prettier eslint-config-prettier eslint-plugin-prettier eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin
yarn add @reduxjs/toolkit react-redux react-router-dom
// .eslintrc.js
module.exports = {
env: {
browser: true,
node: true,
},
extends: [
'prettier',
'eslint:recommended',
'plugin:react/recommended',
'plugin:@typescript-eslint/recommended',
'plugin:prettier/recommended',
],
parser: '@typescript-eslint/parser',
parserOptions: {
ecmaFeatures: {
jsx: true,
},
ecmaVersion: 12,
sourceType: 'module',
},
plugins: ['react', '@typescript-eslint'],
rules: {
'prettier/prettier': ['error', { endOfLine: 'auto' }],
},
};
// .prettierrc.js
module.exports = {
// String is in single quotes (')
// 문자열은 홀따옴표(')로
singleQuote: true,
// With a semicolon at the end of the code.
// 코드 마지막에 세미콜른이 있게
semi: true,
// Do not use tabs and replace them with space bars.
// 탭의 사용을 금하고 스페이스바 사용으로 대체하게
useTabs: false,
// Indentation width of 2 spaces
// 들여쓰기 너비는 2칸
tabWidth: 2,
// When you create an object or array, you also put a comma on the element or on the back of the key-value.
// 객체나 배열을 작성 할 때, 원소 혹은 key-valueㅇ의 맨 뒤에 있는 것에도 쉼표를 붙임
trailingComma: 'all',
//One line of code is maximum 80 spaces
// 코드 한줄이 maximum 80칸
printWidth: 80,
};const item = productList.find((list: productListProps) => {
return list.id === Number(id);
});
// 조건에 해당하는 요소 반환
const item2 = productList.filter((list: productListProps) => { //
return list.id === Number(id);
});
// 배열만들어서 만들어줌yarn add react-query
//index.tsx
import { QueryClient, QueryClientProvider } from 'react-query';
const queryClient = new QueryClient();
const root = ReactDOM.createRoot(
document.getElementById('root') as HTMLElement,
);
root.render(
<React.StrictMode>
<QueryClientProvider client={queryClient}>
<Provider store={store}>
<BrowserRouter>
<App />
</BrowserRouter>
</Provider>
</QueryClientProvider>
</React.StrictMode>,
);
// DashBoard.tsx 대쉬보드 컴포넌트
import axios from 'axios';
import { useQuery } from 'react-query';
import * as React from 'react';
const DashBoard = () => {
const result = useQuery(
'작명',
() =>
axios.get('https://codingapple1.github.io/userdata.json').then((a) => {
return a.data;
}),
{
refetchOnWindowFocus: false, // react-query는 사용자가 사용하는 윈도우가 다른 곳을 갔다가 다시 화면으로 돌아오면 이 함수를 재실행합니다. 그 재실행 여부 옵션 입니다.
retry: 0, // 실패시 재호출 몇번 할지
onSuccess: (data) => {
// 성공시 호출
console.log(data);
},
onError: (e) => {
// 실패시 호출 (401, 404 같은 error가 아니라 정말 api 호출이 실패한 경우만 호출됩니다.)
// 강제로 에러 발생시키려면 api단에서 throw Error 날립니다. (참조: https://react-query.tanstack.com/guides/query-functions#usage-with-fetch-and-other-clients-that-do-not-throw-by-default)
console.log(e.message);
},
},
);
return (
<div>
{result.isLoading && '로딩중'}
{result.error && '에러남'}
{result.data && result.data.name}
</div>
);
};
export default DashBoard;let [users, setUsers] = useState([]);
# 배열에 추가
setUsers(users.concat(user));
# 배열에 추가 (함수형)
setUsers((prev) => prev.concat(user));
# 배열에서 삭제
const onRemove = id => {
// user.id 가 id 인 것을 제거
setUsers(users.filter(user => user.id !== id));
};
#배열 수정
const onToggle = id => {
setUsers(
users.map(user =>
user.id === id ? { ...user, active: !user.active } : user
)
);
};#객체에 추가 #객체 업데이트
setUsers(state => {...state, key: value})
#객체에서 제거 #loadash
setUsers(state => {..._.omit(state, 'deleteKey')})
messageListRef.current?.scrollTo(0, messageListRef.current.scrollHeight);| (react) proxy 서버와 ajax요청 (fetch 또는 axios) (0) | 2021.08.26 |
|---|---|
| (React) Route 에서 parameter(state) 함께 넘기기 (0) | 2021.07.02 |
| (React) 리액트 시작하기 (0) | 2021.06.30 |
본 문서는 Git을 활용하는 클라이언트, 브랜치 전략, DevOps 등을 정리한 문서이다. 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, 비트버킷에 대한 자세한 설명은 잘 정리된 글이 있어 링크로 대체한다. 링크
앞서 말한 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 정책이다.
세번째는, GitLab-flow다. GitHub-flow가 제시하지 못한 배포, 환경, 릴리즈 및 소스통합 등 다양한 이슈에 대해 지적하고 추가적인 가이드를 제공한다. “코드를 변경하는 목적은 분명하므로 이슈로 생성해서 관리하자.” 라는 이념으로 코드 변경 사유를 투명하게 공개하는 것이 원칙이다.
위와 같은 전략을 제시한 이들을 포함해 대부분의 브랜치 전략 수립에 관한 주장에서 공통적인 부분은, 각자의 개발 환경과 상황에 맞게 적절한 브랜치 전략을 수립하라는 내용이다. 버전 관리가 필요한 애플리케이션이라 git-flow를 채택하더라도, 제시한 브랜치 중 불필요한 브랜치가 있다면 사용하지 않는 방법, 메인 브랜치를 master 브랜치 하나만 유지하는 전략을 함께 채택하는 방법 등이다. 또한, SVN의 단일 브랜치 전략은 물론, 너무 복잡하고 Depth가 깊은 브랜치 전략은 피하라는 것이 일반적인 주장이다. 즉, 상황에 맞게 브랜치 전략을 수립하되, 브랜치는 단순하게 가져가야한다.
Git으로 수행되는DevOps라는 뜻의 GitOps는 Cloud native application (클라우드 환경에서 애플리케이션을 구축, 배포, 관리 하는 접근 방식)에 DevOps를 어떻게 적용할지에 대한 방법론이다. 즉, 애플리케이션 배포와 운영에 관련된 모든 요소들을 Git에서 관리하는 것이다. 정확히는 쿠버네티스의 manifest파일을 Git에서 관리하고, 배포할 때도 Git에 저장된 Manifest로 배포하는 과정이다. (쿠버네티스, CI/CD등에 대한 기술적 지식이 부족해 간단한 설명으로 마무리합니다. )
InfoGrab에서 진행한 GitLab Global devSecOps 성숙도 조사에 대한 링크를 남기는 것으로 문서를 마무리한다. 링크
| 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 |
본 문서는 모니터링 솔루션인 프로메테우스에 대한 구조 및 구성에 대한 설명이다.
프로메테우스란 시계열 DB를 내장한 메트릭 수집, 시각화, 알림 등의 기능을 제공하는 오픈 소스 모니터링 시스템이다. pull 방식의 메트릭 수집, 시계열 데이터 저장, 전용 쿼리인 PromQl을 활용한 집계 등을 제공한다. 기본 제공하는 시각화 기능은 한계가 있어 일반적으로 Grafana라는 시각화 툴을 함께 사용한다.
Pull 방식으로 데이터를 수집하도록 노출되는 Agent. 서버들로부터 메트릭을 수집해 http endpoint를 제공한다. 프로메테우스는 해당 Endpoint로 http get 요청을 통해 수집한다. 즉, Exporter는 일종의 http 서버이고, 요청 당시의 데이터를 get method를 통해 리턴한다.
TSDB에 저장된 데이터를 PromQl을 통해 조회하고, 자체 시각화 web을 통해 조회가능. 그러나 시각화에 한계가 있어서 일반적으로 Grafana를 시각화 툴로 사용
Alert Manager를 통해 특정 룰을 설정해두고 룰에 해당되면 slack, e-mail등을 통해 알림을 받을 수 있다.
Pull방식을 사용하기때문에 메트릭에 대한 데이터를 중앙 서버로 보내지 않아도 된다. 즉, 일정 주기마다 데이터를 직접 pull 해온다.
기본적으로 프로메테우스는 Pull방식이지만, http endpoint에 접근하지 못하는 경우는 pull 방식 사용이 어렵기 때문에, 어플리케이션이 pushgateway에 메트릭을 push한후 프로메테우스는 push된 메트릭을 pull 해온다. pull을 위해 사용하는 exporter는 타겟이 있는 서버에 설치되어야 하는데, 사내망같이 폐쇄적인 곳에 있어 http 접근을 할 수 없는 경우 사용한다.
l 다차원 데이터 모델 가능
l 모든 데이터는 HTTP (Pull) 방식으로 작동. Push도 가능
l 모니터링 타겟은 YAML 파일을 통해 설정
l 클러스터링이 안됨
l 싱글 호스트이기 때문에 저장용량이 부족하면 디스크 용량을 늘리는 방법 밖에 없음
l Metric 수집 및 메모리에 저장후 일정 시간이 지나면 Local Disk에 덤프 형식으로 저장하기 때문에 오래된 data는 조회 불가능
l 100% 정확성을 보장하지 않음. 모든 메트릭을 수집하지 않고 사실상 ‘추세’ 모니터링에 적합함. 순간의 스냅샷 정보만 알 수 있음
프로메테우스는 내부적으로 time series db(이하 TSDB)를 기본으로 사용한다. TSDB는 다중 사용자 환경에서 그다지 좋은 성능을 내지 못한다는 이야기가 있다. 이문제를 해결하려면 시계열 데이터를 전문으로 다루는 DB를 사용하는 것도 좋은 방법이다. 또한 원격저장소에 있는 DB에 저장하려는 경우도 생길 수 있다.
프로메테우스는 replicate되지 않으며, long-term 메트릭에 저장에 적합하지 않다. 그래서 다양한 원격 스토리지 저장을 지원한다. 이 지원 방법 중 하나가 TimescaleDB에 저장하는 방법이다. TimescaleDB는 PostgreSQL기반으로 확장된 시계열DB이다. long-term 메트릭 저장에 적합하고, promQL과 SQL에 완벽하게 대응한다. 프로메테우스의 로컬 node에 기록된 후에 timescaleDB에 한번더 기록되기때문에 즉시 백업이 되는 셈이다. 따라서 disk에러 등에 대해 피해가 덜 생길 수 있다. TimescaleDB에서는 해당 기능을 총칭하여 PromScale이라고 부른다.
프로메테우스에서 TimescaleDB에 원격 write를 하려면 2가지 추가 모듈이 필요하다. pg_prometheus와 prometheus_postgresql_adapater이다. pg_prometheus는 timescaledb이고, 어댑터는 둘을 연결해주는 어댑터이다. 두 모듈 모두 도커로 배포되어있어 바로 실행할 수 있다. pg_prometheus를 도커를 통해 run하면 TimescaleDB에 필요한 하이퍼테이블, 스키마 등을 자동으로 생성한다. 또, 프로메테우스 설정도 일부 변경해야한다. remote_write 옵션과 remote_read 옵션의 url 을 adapter의 주소를 설정한다.
이렇게 설정을 완료한 후 도커를 통해 시스템을 띄우면 정상적으로 timescaleDB에 remote write할 준비가 완료된 것이다.
아래 그림은 위에서 설명한 내용의 구조도이다.
| 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 |
4 warnings generated.
SOLINK_MODULE(target) Release/nodejavabridge_bindings.node
ld: warning: directory not found for option '-L/Library/Java/JavaVirtualMachines/adoptopenjdk-14.jdk/Contents/Home/lib/jli'
ld: library not found for -ljli
clang: error: linker command failed with exit code 1 (use -v to see invocation)
sudo npm install java --unsafe-perm=true --allow-root| node.js JAVA 모듈 관련 이모저모 (0) | 2023.03.27 |
|---|---|
| (node.js) 노드js에서 npn install시 codec can't decode byte 0xec in position 2443: 에러 해결 (0) | 2021.07.27 |