코딩

h2 - 데이터 베이스 연결

기웅99 — Wed, 23 Oct 2024 17:57:01 +0900

cmd창에서

1. h2폴더에 진입,

2. bin 폴더에 진입,

3. ./h2.sh 명령어로 h2실행

4. 프로젝트 properties 작성

spring.jpa.hibernate.ddl-auto=create
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

spring.datasource.username=sa
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.url=jdbc:h2:tcp://localhost/~/test

5. 웹으로 H2에 접속 (H2 Console클릭)

6. 웹으로 H2 Console에 접속후 연결

h2데이터 베이스

React로 aws에서 EC2로 배포하기

기웅99 — Mon, 16 Sep 2024 03:31:46 +0900

local

npm run build

sudo npm install -g serve

로컬에서 dist파일 EC2로 옮긴후

EC2

# 시스템의 패키지 목록을 최신 상태로 업데이트합니다.

sudo apt update

# npm 패키지 관리자를 설치합니다.

sudo apt install npm

# Node.js 18.x의 설치 스크립트를 다운로드하고 실행하여 NodeSource 저장소를 추가합니다.

curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -

# Node.js와 npm을 설치합니다. Node.js 18.x 버전과 함께 최신 npm이 설치됩니다.

sudo apt-get install -y nodejs

# 전역적으로 serve 패키지를 설치합니다. serve는 정적 파일을 서빙하는 도구입니다.

sudo npm install -g serve

# /home/ubuntu/dist 경로의 정적 파일을 포트 4000에서 서빙합니다.

serve -s /home/ubuntu/dist -l 4000

# `nohup`을 사용하여 `serve`를 백그라운드에서 실행합니다. # `&`는 백그라운드 실행을 의미하며, `nohup.out` 파일에 로그가 기록됩니다.

nohup serve -s /home/ubuntu/dist -l 4000 > nohup.out 2>&1 &

(%주의사항% 반드시 dist파일 안에서 실행하여 spring의 nohup.out파일과 겹치지 않도록 실행)

Docker를 이용한 Spring boot 서버 배포하기

기웅99 — Sun, 15 Sep 2024 00:17:52 +0900

프로젝트 폴더에 Dockerfile 생성 후 작성

FROM openjdk:17
ARG JAR_FILE=build/libs/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["nohup","java","-jar","/app.jar","&"]

FROM openjdk:17:
- openjdk 버전 17을 기본 이미지로 사용합니다. 이 이미지는 자바 애플리케이션을 실행할 수 있는 환경을 제공합니다.
ARG JAR_FILE=build/libs/*.jar:
- ARG는 빌드 시 사용할 변수를 정의하는 명령입니다. 여기서는 JAR_FILE이라는 이름의 변수를 정의하고, build/libs/ 폴더에 있는 모든 .jar 파일을 가리키도록 설정했습니다.
COPY ${JAR_FILE} app.jar:
- COPY는 호스트 파일 시스템에서 도커 이미지 내부로 파일을 복사하는 명령입니다. ARG에서 정의한 ${JAR_FILE} 경로의 파일을 이미지 내부의 app.jar로 복사합니다.
ENTRYPOINT ["nohup","java","-jar","/app.jar","&"]:
- 도커 컨테이너가 시작될 때 실행할 명령을 정의합니다. 여기서는 nohup 명령을 사용하여 자바 애플리케이션을 백그라운드에서 실행합니다.
- nohup: 터미널이 종료되더라도 프로세스가 계속 실행되도록 합니다.
- &: 프로세스를 백그라운드에서 실행하게 만듭니다.

docker build -f Dockerfile -t nurim_b/20240914 .

로 도커 이미지 생성

docker images

로 이미지 확인

docker tag <기존 레포지토리 이름>:<기존 태그> <사용자이름>/<레포지토리 이름>:<변경할 태그>

로 태그 변경 (변경할 레포지토리 이름에 dockerhub에서 생성한 레포지토리 이름을 넣는다)

docker push <사용자이름>/<레포지토리 이름>:<태그>

%%%%%도커 실행%%%%

docker run -d -p 8080:8080 <레포지토리 이름>:<태그>

docker run:
- Docker 컨테이너를 생성하고 실행하는 명령어입니다.
-d:
- "detached" 모드로 컨테이너를 실행합니다. 이 모드에서는 컨테이너가 백그라운드에서 실행되고, 터미널에 제어를 반환합니다. 즉, 컨테이너가 백그라운드에서 실행되며, 터미널은 즉시 사용 가능한 상태가 됩니다.
-p 8080:8080:
- 포트 포워딩을 설정합니다. 왼쪽의 포트(8080은 호스트 머신의 포트)와 오른쪽의 포트(8080은 컨테이너의 포트)를 연결합니다. 즉, 호스트 머신의 8080 포트에 대한 요청이 컨테이너의 8080 포트로 전달됩니다.

aws 도커 이미지를 불러와 실행시키기

우선 EC2에서 도커 이미지를 불러오기전에 도커를 다운 받아야 한다.

sudo apt update
//apt 업데이트
sudo apt install docker.io
//도커 다운
sudo apt install docker-compose
//도커 컴포즈 다운

만약 도커 로그인시 문제가 된다면

sudo usermod -aG docker $USER

로 도커 실행권한을 조정

exit로 나온후 다시 접속하여 로그인

docker pull <레지스토리 명>/<이미지 명>:<태그>

로 이미지 다운로드 후

docker run -d -p 8080:8080 kiwoong487/nurimhub:nurim_B

로 실행

하지만

The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64/v3) and no specific platform was requested

라는 에러가 발생했다

결론부터 말하자면

로컬에서 빌드한 이미지가 linux/arm64/v8 이므로, 이를 linux/amd64 플랫폼 형태의 이미지로 새롭게 빌드해야 한다

docker build --platform linux/amd64 -f <도커 파일명> -t <사용자명>/<레포지토리이름>:<이미지 명> .
docker build --platform linux/amd64 -f Dockerfile -t kiwoong487/nurimhub:b_20240914 .

그 후

docker run --platform linux/amd64 -d -p 8080:8080 kiwoong487/nurimhub:b_20240914

로 실행

doker ps //실행중인 컨테이너 확인

이미지 삭제: docker rmi <image_name_or_id>
실행중인 컨테이너 확인: docker ps
중지된 컨테이너 확인: docker ps -a
해당 컨테이너 삭제: docker rm <container_id>
로그 보기: docker logs <container_id_or_name>
최근 로그 보기: docker logs --tail <number> <container_id_or_name>
실시간 로그 보기: docker logs -f <container_id_or_name>
최근 로그와 실시간 로그 조합: docker logs --tail <number> -f <container_id_or_name>

Spring-boot 기초 Dependencies

기웅99 — Mon, 8 Apr 2024 17:03:39 +0900

    //h2
    runtimeOnly 'com.h2database:h2'
    //mysql
//  runtimeOnly 'com.mysql:mysql-connector-j'
    //JDBC, JPA
    implementation 'org.springframework.boot:spring-boot-starter-data-jdbc'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    //Lombok
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    //SpringBoot starter
    developmentOnly 'org.springframework.boot:spring-boot-devtools'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    //validation
//  implementation 'org.springframework.boot:spring-boot-starter-validation'
    //oauth2.0
//  implementation 'org.springframework.boot:spring-boot-starter-oauth2-client'
    //jwt
//  compileOnly group: 'io.jsonwebtoken', name: 'jjwt-api', version: '0.11.2'
//  runtimeOnly group: 'io.jsonwebtoken', name: 'jjwt-impl', version: '0.11.2'
//  runtimeOnly group: 'io.jsonwebtoken', name: 'jjwt-jackson', version: '0.11.2'
    //spring security
//  implementation 'org.springframework.boot:spring-boot-starter-security'
//  testImplementation 'org.springframework.security:spring-security-test'
    //QueryDsl
//  implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
//  annotationProcessor "com.querydsl:querydsl-apt:5.0.0:jakarta"
//  annotationProcessor "jakarta.annotation:jakarta.annotation-api"
//  annotationProcessor "jakarta.persistence:jakarta.persistence-api"
    //Swagger3
//  implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.2.0'
    //S3 AWS
//  implementation 'org.springframework.cloud:spring-cloud-starter-aws:2.2.6.RELEASE'
    // spring boot 애플리케이션을 모니터링하고 관리하는 데 도움이 되는 운영 환경용 기능들
//  implementation 'org.springframework.boot:spring-boot-starter-actuator'
    // 애플리케이션 메트릭을 수집하기 위한 간단하고 일관된 API를 제공하는 메트릭 퍼사드 라이브러리
//  runtimeOnly 'io.micrometer:micrometer-registry-prometheus'

주석이 없는 라이브러리들은 기초 라이브러리

SpringBoot - actuator + Prometheus + Grafana

기웅99 — Fri, 29 Mar 2024 19:11:36 +0900

Spring Boot - Actuator 설정

dependencies :

// spring boot 애플리케이션을 모니터링하고 관리하는 데 도움이 되는 운영 환경용 기능들
implementation 'org.springframework.boot:spring-boot-starter-actuator'
// 애플리케이션 메트릭을 수집하기 위한 간단하고 일관된 API를 제공하는 메트릭 퍼사드 라이브러리
runtimeOnly 'io.micrometer:micrometer-registry-prometheus'

application.yml :

## Spring Boot 액추에이터의 웹 엔드포인트 중 어떤 것들을 노출할 것인지 지정
management:
  endpoint:
    metrics:
      enabled: true
    prometheus:
      enabled: true
    logfile:
      enabled: true
  endpoints:
    web:
      exposure:
        include: logfile, metrics, prometheus
  metrics:
    tags:
      application: ${spring.application.name}
#    #   HTTP 요청의 처리 시간을 자동으로 측정하여 Metric으로 수집하도록 지정
#      server:
#        request:
#          autotime:
#            enabled: true

prometheus.yml :

/opt/homebrew/etc/

global:
scrape_interval: 10s

evaluation_interval: 10s

scrape_configs:
  - job_name: "prometheus"
    static_configs:
    - targets: ["localhost:9090"]

로 설정 되어있는 파일을

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "nurim-monitoring"
    metrics_path: '/actuator/prometheus'
    static_configs:
    - targets: ["localhost:8080"]

로 변경후 brew services restart prometheus 명령어 실행(prometheus 서버 실행)

global : 전역 설정을 정의하는 섹션
- scrap_interval : 목표 서버에서 메트릭을 가져오는 간격
- evaluation_interval : 프로메테우스에서 규칙 평가 및 알람 생성을 실행하는 간격
scrip_configs : 수집 대상 및 대상별 구성을 정의하는 섹션
- job_name : 프로메테우스에서 해당 작업을 식별하는 데 사용되는 이름
  - metrics_path : 메트릭 엔드포인트의 경로 지정
  - static_configs : 대상 서버를 정의하는 섹션
    - targets : 메트릭을 수집할 서버

http://127.0.0.1:9090/ 로 접속하여 Prometheus에 데이터가 잘 수집되고 있는지 확인

잘 수집 되고 있는지 확인 되었다면 Grafana연동하기

home brew로 grafana설치

brew services start grafana 명령어 실행(그라파나 서버 실행)

http://localhost:3000 접속

접속 후 Data sources를 prometheus로 설정 후

대쉬보드를 넣어 마무리 하면된다.

EC2 그라파나 설치 및 포트 확인

# adduser, libfontconfg1 설치 
sudo apt-get install -y adduser libfontconfig1 musl

# grafana 다운로드 
wget https://dl.grafana.com/enterprise/release/grafana-enterprise_10.4.2_amd64.deb

# grafana 설치 
sudo dpkg -i grafana-enterprise_10.4.2_amd64.deb

# 실행 
sudo systemctl enable grafana-server.service
sudo systemctl start grafana-server.service
혹은
sudo service grafana-server start 

# 실행 상태 확인 
sudo service grafana-server status

#포트 확인
netstat -tulpn

EC2 - prometheus 설치 및 실행

-- 다운로드
wget https://github.com/prometheus/prometheus/releases/download/v2.45.1/prometheus-2.45.1.linux-amd64.tar.gz

-- 압축해제
tar xzvf prometheus-2.45.1.linux-amd64.tar.gz

-- 압축을 푼 폴더로 이동
cd prometheus-2.45.1.linux-amd64/

-- 해당 파일 수정
vim prometheus.yml

프로메테우스 유저 생성(root로 돌리는데 할 필요가 있나?)
groupadd -r prometheus
useradd -r -g prometheus -s /sbin/nologin -d /home/prometheus/ -c "prometheus Daemons" prometheus
chown -R prometheus:prometheus -R /home/prometheus/

-- system 으로 이동
cd /etc/systemd/system

-- prometheus 서비스 파일 생성
sudo vim prometheus.service
-- prometheus 서버 설정--------
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=root
restart=on-failure
ExecStart=/home/ubuntu/prometheus/prometheus-2.45.1.linux-amd64/prometheus \
		--config.file=/home/ubuntu/prometheus/prometheus-2.45.1.linux-amd64/prometheus.yml \
        --storage.tsdb.path=/var/lib/prometheus \
        --web.console.templates=/home/ubuntu/prometheus/prometheus-2.45.1.linux-amd64/consoles \
        --web.console.libraries=/home/ubuntu/prometheus/prometheus-2.45.1.linux-amd64console_libraries \
        --web.listen-address=0.0.0.0:[포트번호] \
        --web.external-url=

[Install]
WantedBy=multi-user.target

-- 서비스 재시작--------------
sudo systemctl daemon-reload
sudo systemctl start prometheus
sudo systemctl status prometheus
출처: https://byeongkwandev.tistory.com/2 [BK-DEV:티스토리]
//설정 안할시 이걸로 시작
nohup ./prometheus > prometheus.log 2>&1 &

-- 프로메테우스 서비스 상태 확인
sudo systemctl status prometheus.service

보안처리 !!!

프로메테우스 포트 변경 (prometheus.args)

프로메테우스 토큰 추가(prometheus.yml)

acturator 포트변경 및 엔드포인트 변경

Spring-boot-3 Actuator

기웅99 — Tue, 26 Mar 2024 00:22:18 +0900

aws에서 서버를 구매하기 전에 내가 지금 만든 어플리케이션이 얼만큼의 리소스를 사용중인지 확인하고 서버를 구매하고 싶어

spring boot에서 지원하는 라이브러리 중 Spring boot Actuator는 html과 JMX를 이용하여 서버를 모니터링 하고 관리할 수 있는 기능을 제공한다.

Spring boot Actuator

Html과 JMX를 이용하여 서버를 모니터링 하고 관리하 수 있는 라이브러리

// spring boot 애플리케이션을 모니터링하고 관리하는 데 도움이 되는 운영 환경용 기능들
implementation 'org.springframework.boot:spring-boot-starter-actuator'

build.gradle의 dependencies에 해당 코드를 추가한 후

## Spring Boot 액추에이터의 웹 엔드포인트 중 어떤 것들을 노출할 것인지 지정
management:
  endpoints:
    web:
      exposure:
        include: '*'

properties.yml에 해당 내용을 넣어서 http://{server}:{port}/actuator에 접속하면 서버의 상태를 확인 할 수 있게 끔 json형식으로 데이터가 노출 되는 것을 확인 할 수 있다.

spring-boot-starter-actuator 는 내부적으로 micrometer 라이브러리를 사용하고, auto configuration을 위한 라이브러리리(spring-boot-actuator-autoconfigure)를 포함하는걸 알 수 있다.

핵심 라이브러리인 micrometer-core 의 내용을 살펴보면 spring boot 가 구동되는 application 의 health, info, metric 정보들을 수집하는 역할을 하는 binder 클래스들이 아주 많이 구현되어 있는걸 알수 있습니다.

즉 spring boot 에서 cache를 사용하고 있다면 cache 관련 정보를 수집하는 클래스를 micrometer 라이브러리에서 이미 제공하고 있으며, kafka 를 사용하고 있다면 kafka 관련 정보를 수집하는 클래스를 micrometer 라이브러리에서 이미 제공하고 있습니다. 즉 자주 쓰는 대부분의 기능들에 대해 micrometer 에서 정보를 수집하는 binder 를 이미 제공하고 있습니다.

spring boot 는 자동설정을 지원해주기에 아래처럼 spring-boot-actuator-autoconfigure 라이브러리에서 정보를 수집할수 있도록 bean 으로 등록해주고 있습니다.

Spring-boot-actuator를 처음 시작해 보면 노출되는 내용이 몇개 없다.

도움되는 데이터는 "health"데이터지만 행당 링크에 들어가보면 사실 up이라는 글자만 노출되고 다른 데이터는 노출 되지않는다.

그래서 도움이 되는 데이터를 얻기 위해선 end-point를 설정해 줄 필요가 있다.

health: {
- href: "http://localhost:8080/actuator/health",
- templated: false
},

의존성 라이브러리의 소스코드를 봤을때는 엄청 많은 정보들을 지원해주는 것 같았는데, 막상 실행해서 결과를 보면 위와 같이 몇 개 안보여주는것으로 되어 있습니다. actuator 에서는 java version, OS 버전 과 같은 다양한 정보를 제공해주는데 이런 정보는 누구에게나 open 되면 보안상 좋지 않기에, spring boot 에서는 default 설정으로는 위와 같이 2~3개로 제한시켜져 있기 때문입니다.

이제 설정을 변경해서 더 많은 정보를 보여주도록 해보겠습니다.

Spring-boot-actuator의 End-Point 설정

우선 spring 이 제공하는 endpoint 가 어떤게 있는지 알아봅시다.

아래에 주요 endpoint 에 대해 적어봤습니다. 이 보다 더 많은 endpoint가 있으며

더 자세한것은 아래 링크에서 확인해보세요.

beans	등록된 bean 목록 제공
caches	cache 사용중이라면 cache 관련 정보 제공
conditions	spring auto configuration 에 의해 bean으로 등록된것과 그렇지 않은 것의 상세 이유를 제공
health	application이 구동중인지, application과 연동되는 다른 서비스(DB, message queue)가 구동중인지 여부 제공
info	application 의 대략적인 정보
metrics	cpu, mem, thread count 등의 모니터링용 메트릭 정보
logger	로거 설정 확인 실시간 로그 레벨 변경 제공
quartz	quartz 라는 스케줄링 관련 라이브러리를 사용하고 있다면, quartz 관련 정보를 상세히 제공

여기서 내가 현재 내가 필요한 정보는 metrics의 정보가 필요하다.

endpoint 활성화설정, 노출 설정

먼저 알아야 할것은 각 endpoint 는 enable/disable (활성화 여부)과 expose ( 노출 여부 ) 라는 2가지 설정을 할 수 있으며 2가지 모두 켜진 상태여야 외부로 노출이 됩니다.

즉 enable/disable 을 통해 spring boot 내부적으로 특정 endpoint 의 정보를 수집하는걸 설정할 수 있으며,

expose 설정을 통해 최종적으로 web 이나 jmx ( = java 모니터링 관련 프로토콜/스펙) 에 해당 정보가 보이는걸(=노출) 설정할 수 있습니다.

둘 중 하나라도 off 이면 노출이 되지 않습니다.

include는 노출에 포함할 endpoint,

exclude 는 노출에 제외할 endpoint 라는 뜻입니다.

나는 현재 metrics데이터만 필요하므로 metrics를 제외하고는 별다른 데이터를 활설화 시키지도 노출 시키지도 않겠다.

## Spring Boot 액추에이터의 웹 엔드포인트 중 어떤 것들을 노출할 것인지 지정
management:
  endpoints:
    enabled: false
    web:
      exposure:
        include: loggers, metrics

모든 정보를 활성화/노출 시키고 싶을 때는

## Spring Boot 액추에이터의 웹 엔드포인트 중 어떤 것들을 노출할 것인지 지정
management:
  endpoints:
    web:
      exposure:
        include: '*'

정리

enabled : 활성회 (true= 활성화, false= 비활성화)

include : 노출

exclude : 비노출

*actuator를 통해 application의 다양한 정보를 확인할 수 있고, 특정 endpoint에서는 실시간으로 변경도 가능하게 해주지만 보안상의 문제가 있을 수 있으므로 spring security 혹은 이와 유사한 방법으로 보안 위험을 해결 하도록 해야한다.

## Spring Boot 액추에이터의 웹 엔드포인트 중 어떤 것들을 노출할 것인지 지정
management:
  endpoints:
    enabled: false
    web:
      exposure:
        include: loggers, metrics
  endpoint:
    auditevents:
      cache:
        time-to-live: 10s

cache를 설정해 준다면 정해진 시간동안 정보를 가져오지 않게 cache에 저장된 데이터만 가져온다(새로고침 해도 데이터가 변경안됨)

다음과 같이 설정을 완료한 경우 아래와 같은 데이터를 볼 수 있다.

{

"_links": {

"self": {

"href": "http://localhost:8080/actuator",

"templated": false

"beans": {

"href": "http://localhost:8080/actuator/beans",

"templated": false

"caches-cache": {

"href": "http://localhost:8080/actuator/caches/{cache}",

"templated": true

"caches": {

"href": "http://localhost:8080/actuator/caches",

"templated": false

"health-path": {

"href": "http://localhost:8080/actuator/health/{*path}",

"templated": true

"health": {

"href": "http://localhost:8080/actuator/health",

"templated": false

"info": {

"href": "http://localhost:8080/actuator/info",

"templated": false

"conditions": {

"href": "http://localhost:8080/actuator/conditions",

"templated": false

"configprops": {

"href": "http://localhost:8080/actuator/configprops",

"templated": false

"configprops-prefix": {

"href": "http://localhost:8080/actuator/configprops/{prefix}",

"templated": true

"env": {

"href": "http://localhost:8080/actuator/env",

"templated": false

"env-toMatch": {

"href": "http://localhost:8080/actuator/env/{toMatch}",

"templated": true

"loggers": {

"href": "http://localhost:8080/actuator/loggers",

"templated": false

"loggers-name": {

"href": "http://localhost:8080/actuator/loggers/{name}",

"templated": true

"heapdump": {

"href": "http://localhost:8080/actuator/heapdump",

"templated": false

"threaddump": {

"href": "http://localhost:8080/actuator/threaddump",

"templated": false

"metrics": {

"href": "http://localhost:8080/actuator/metrics",

"templated": false

"metrics-requiredMetricName": {

"href": "http://localhost:8080/actuator/metrics/{requiredMetricName}",

"templated": true

"scheduledtasks": {

"href": "http://localhost:8080/actuator/scheduledtasks",

"templated": false

"mappings": {

"href": "http://localhost:8080/actuator/mappings",

"templated": false

}

서버 모니터링

기웅99 — Thu, 21 Mar 2024 21:00:13 +0900

앱 어플리케이션 서버를 돌리면서 서버의 CPU사용량 및 메모리 사용량을 시각적으로 정보를 전달 받기 위해 서버 모니터링 시스템이 필요하다고 느꼈다.

물론 AWS에서 제공하는 모니터링 방식이 있지만 추후에 도커를 추가할 경우 각 컨테이너마다 자세한 모니터링을 위해 추가해보겠다..

각 아키텍쳐를 조사하던 중 사람들이 많이 쓰는 프로그램 3가지를 알게되었다.

Grafana : grafana는 prometheus에 query하여 데이터를 가져옵니다. (Front-end 역활)

Prometheus : 각 서비스(Django, Mincreft Server, Ec2 server...등등)의 데이터를 저장하는 데이터베이스이다.

pull 방식은 각 서비스 에서 직접 metrics를 가져오는 방식이고, push 방식은 각 서비스가 Prometheus에 metrics를 업로드 하는 방식이다. (Back-end 역활)

Kibana : Kibana는 데이터의 형태를 만들고, Elastic Stack을 탐색할 수 있게 하는 시각화 및 관리 서비스이다.

# Elastic Stack이란 데이터 분석에 필요한 모든 유형의 데이터를 실시간으로 검색, 분석 및 시각화할 수 있는 Elastic 사 의 오픈소스 데이터 분석 플랫폼.

Kibana로 다음과 같은 역활을 할 수 있다.

검색, 관찰, 데이터 보호
kibana는 document 검색에서 log 분석, 보안 취약성 찾기와 같은 기능에 access할 수 있는 portal이다.
데이터 분석
숨은 insight를 찾고 차트, 그래프 등에 발견한 내용을 시각화 한 뒤 대시보드를 구성한다.
Elastic Stack 관리, 모니터링 및 보안
data를 관리하고, Elastic Stack cluster의 상태를 모니터링하고, 어떤 사용자가 어떤 기능에 access 할 수 있는지 제어한다.

CPU 코어, 스레드 개념 정리

기웅99 — Thu, 21 Mar 2024 14:30:32 +0900

AWS에서 어플리케이션 서버를 돌리기 전에 내가 돌릴 어플리케이션 서버의 성능에 맞는 인스턴스를 선택해야 한다. 그러므로

CPU의 코어와 스레드의 개념을 정리해 보겠다.

CPU(Cental Processing Unit)

CPU는 컴퓨터의 없어서는 안될 핵심적인 부품이다. '연산처리장치' 또는 '중앙처리장치' 즉 사람의 장기에 비유하자면 뇌에 해당된다.

그 중 코어와 스레드는 컴퓨터 사용자가 꼭 알아야할 컴퓨터 스펙이다.

CPU는 오랜 시간동안 계속 변화해 왔지만 '기억', '연산', '제어'이 세 기본동작은 변함없다.

우선 이 세개의 기본동작을 살펴 보겠다.

- [기억] Processor Register : ALU에 필요한 데이터 또는 오퍼랜드(Operand)를 제공하고 저장한다.

- [연산] ALU (산술 논리 장치) : 프로세서가 산술 및 비트 논리 연산을 수행할 수 있다.

- [제어] Control Unit (제어장치) : ALU, 레지스터 등 구성장치를 통해 명령을 수행한다.

* 명령어가 중앙처리장치(CPU)에 의해 실행될 때, 연산을 수행 하는데 필요한 데이터 혹은 데이터 주소를 오퍼랜드(operand)라 한다.

또한 CPU는 명령 주기(Insturction Cycle)라고 알려진 일련의 단계를 따른다.

- fetch : 컴퓨터 메모리에서 명령을 가져온다.

- Decode : 수행할 명령을 판별한다.

- Execute : 명령을 수행한다.

대부분의 최신 CPU는 메모리, 마이크로컨트롤러(MCU) 또는 SoC(System on Chip)와 같은 다른 구성장치와 함께 집적회로 칩(IC, Integrated Chip)에 포함되어 있다. 또한 일부 CPU는 실행 중에 발생하는 열을 줄이고 프로그램 명령 실행 속도를 높이기 위해, 하나의 칩 안에 2개 이상의 CPU를 가지는 멀티 코어 프로세서(Multi-Core Processor)를 사용한다.

프로세서 (Processor)

프로세서는 프로그램 명령을 수행하기 위한 논리회로를 말한다.

프로세스 (Process)

메모리에 적재되어 실행 중이거나 대기 중인 프로그램을 프로세스라 합니다.

* 프로세스는 create, running, ready, waiting, terminated의 5개의 상태로 나눠집니다.

프로그램 (Program)

컴퓨터에서 사용자가 원하는 목적을 달성하기 위해 목적에 맞게 특정 작업을 수행하는 일련의 명령어들의 집합이다. 즉, OS에서 얘기하는 프로그램은 컴퓨터에서 실행중인 모든 종류의 소프트웨어 프로그램들을 의미합니다.

CPU의 사양을 살펴 보면, 보통 CPU의 코어와 스레드는 2Core 4Thread, 4Core 4Thread, 8Core 16Thread...라고 표시되어 있다. 이것은 해당 CPU의 코어와 스레드의 갯수를 나타내는 것이다. 코어와 스레드의 갯수는 많으면 많을수록 성능이 우수한 CPU이다.

코어(Core)

코어란 말 그대로 CPU의 핵심, 중심 이라는 뜻이며 CPU에게 요구되는 계산을 담당하는 연산처리 장치이다.

과거에는 CPU가 끊임없이 계속해서 연산을 수행하지는 않았다. 한번 연산을 수행한 후에는 연산을 수행하지 않고 쉬는 기간이 있었다.

하지만 발전을 통해 CPU를 구조화 함으로써 프로세서가 쉬지않고 연산을 수행 할 수 있도록 만들어졌다.

실제로 하나의 코어가 두가지 프로세스를 같이 수행 할 수 없다.

하나의 프로세서에 2개 이상의 코어를 가지고 두가지 이상의 연산을 아주 짧은 시간 나누고 번갈아 일을 처리 함으로써 사용자가 두가지 일을 동시에 처리하게 느끼게 되는 것이다.

(프로세서가 하나의 프로세스를 처리하고 나서, 쉬는 기간에 다른 프로세스를 처리할 수 있도록 구조화 한 것)

이때 코어가 번갈아 가며 일을 처리할 수 있게 프로세스를 잘게 나눈 실행의 단위를 '스레드'라고한다.

스레드(Thread)

Core가 할 수 있는 최소한의 작업 단위이자 도구

보통 1개의 코어에 2개의 스레드가 있으면 운영체제는 스레드0과 스레드1을 번갈아 가며 작업한다.('스위칭')

정리하자면 코어란 하드웨어 입장에서 본 물리적 코어를 의미하며, 스레드란 운영체제 입장에서 본 논리적 코어를 의미한다.

DB백업

기웅99 — Tue, 19 Mar 2024 16:05:18 +0900

aws에서 RDS로 DB인스턴스를 사용중일때 백업 방법이 두가지 있다.

1. DB 인스턴스 생성시 자동 백업도 같이 활성화 시킨다.

2. DB백업을 하고 싶을때 수동으로 스냅샷을 생성해 백업 시킨다.

주의사항

1. 스냅샷을 활용하여 DB를 복원 시키는 작업을 할때 기존에 사용하던 DB인스턴스를 해당 스냅샷으로 되돌리는 것이 아닌 새로운 인스턴스가 생성된다.

2. Automated backup을 이용하여 DB를 백업할때 '가장 빠른 복원 시간'은 내가 복원 할 수 있는 가장 이전 시간이고 해당 시간보다 뒤로 복원이 불가능하다. '최근 복원 가능 시간'은 내가 복원 할 수 있는 가장 이후 시간이고 해당 시간보다 앞으로 복원이 불가능하다.

'가장 빠른 복원 시간' = Min

'최근 복원 가능 시간' = Max

3. 자동 백업 보존 기간은 1일~35일 정도 이며 장기간 보존을 위해서는 수동으로 스냅샷을 생성하여 보존을 할 수 있다.

S3를 이용한 백업

S3를 이용한 백업으로는 수동으로 스냅샷을 만들어 S3로 내보내기를 사용한다.

주의사항

1. 무조건 스냅샷을 만들어야한다. 스냅샷은 무조건 새로운 DB를 만들어야 한다.

-aws에서 제공하는 기능으로는 DB를 만들고 데이터만 이전하는 기능은 없다.

2. 개발 데이터 복원 요청시 스냅샷으로 DB를 만들고 추출 해야한다.

-개발자가 개발해 추출해야한다.

3. 스냅샷을 S3로 보관하는 이유는?

-특수하게 장기 보관이 필요할 경우

-S3에서 보관하는 것도 새 DB를 만들고 추출 해야한다.

-데이터만 추출하는 경우는 없다.

좀 귀찮은 방법으로는 Exal에서 DB를 연동시켜 데이터를 보관하는 방법도 있지만 데이터를 DB에 자동으로 넣는 방식이 살짝 번거롭다.

BackUp의 일방적인 3가지 도구로는 백업, 스냅샷, 복제 이다.

BackUp은 총 4가지 유형으로 구분된다.

전체 백업 : 전체 백업을 완전한 가족 사진 앨범으로 생각하십시오.그것은 특정 가족 휴가의 모든 그림을 포함하여 모든 세부 사항을 캡처합니다.

증분 백업 : 증분 백업은 기존 앨범에 새 사진을 추가하는 것과 같습니다.여기에는 마지막 가족 여행 이후 찍은 사진 만 포함되어 공간과 시간을 절약합니다.

차동 백업 : 다양한 가족 휴가 중에 찍은 사진 모음으로 차별화 백업을 그림으로 표시하십시오.각 차별화 백업에는 특정 여행의 모든 새로운 사진이 포함되어 조직을 단순화합니다.

연속 데이터 보호 (CDP) : CDP는 매 초마다 사진을 찍는 마법 카메라와 같습니다.매 순간을 포착하여 기억을 놓치지 않도록합니다.특정 순간을 기억해야 할 때 CDP 카메라에 저장됩니다.

데이터 백업 개념

BackUp = 백업은 데이터 복제를 하는 행동, 데이터 복제의 의미

Replica = 레플리카는 데이터를 이전하는 행위이다.

AWS에서 제공하는 기능 중 Amazon RDS 읽기 전용 복제본이 있다.

https://aws.amazon.com/ko/rds/features/read-replicas/

예를 들어 백업은 복구에 초점이 있다. 쉽게 말하면, 백업을 그대로 쓰는게 아니라 백업을 읽어서 오리지널로 다시 쓰는 것에 초점이라면, Replica의 경우는 그 자체를 그대로 쓰는 것에 초점이 맞춰져 있다는 것이다

Replication이란?

Replication은 말그대로 복제를 뜻하며 2대 이상의 DBMS를 나눠서 데이터를 저장하는 방식이다.

여기서 2대 이상의 DBMS는 Master / Slave 구성을 해야한다.

요즘은 Slave라고 부르지 않기 때문에 Source서버 / Replica서버로 나눠서 부른다.

기존 DB

위 사진처럼 한 DB서버에서 모든 CRUD처리를 하게 된다면 나중에 사용자가 많아질 때 DB서버 하나가 많은 Query를 처리하기 힘든 상황이 오므로 Replication을 쓰게된다.

Replication DB서버를 사용한 사진

따라서 위 사진과 같이 Query의 대부분을 차지하는 Select를 다른 DB서버에 넘겨주는 방식으로 Replication방식이 나오게 되었다.

결제 API

기웅99 — Mon, 18 Mar 2024 22:13:45 +0900

우선 결제 API를 만들기 위해선 원래라면 직접 모든 카드사와 계약을 맺고, 결제를 관리하고, 정산 받는 업무를 관리를 해야한다.

작은 개인 사업자가 직접 모든 카드사와 계약을 맺는 것은 어렵기 때문에 PG사와 한 번 계약을 맺으면 여러 카드사, 은행 등 금융기관과 간편하게 거래를 할 수 있고 약속된 정산일에 한 번에 매출액을 정산 받을 수 있다. 카드사마다 다른 매출액 지급일에 혼란을 없애고, 현금흐름을 쉽게 파악할 수 있게 해준다.

PG를 이용하기 전

PG사란?

Payment Gateway의 줄임말로 '결제를 위한 관문'이라는 뜻이다.

PG사는 카드결제, 간편결제, 계좌이체, 가상계좌(무통장입금), 상품권결제, 휴대폰결제 등 다양한 결제 방식을 사용할 수 있게 연결해주는 역할을 하고 온라인 결제를 대신해 주기 때문에 PG사는 결제대행사, '전자결제 지급대행사'라고도 불린다.

PG를 이용한 후

PG결제 흐름

고객이 상점에서 물건을 구입하면, 서버에서 PG로 결제 요청을 보낸다. PG는 결제 요청을 카드사, 은행과 같은 결제 기관으로 보내서 승인을 받고, 그 결과를 상점에게 전달해요. 확실히 금액이 지불됐다는 걸 확인한 상점은 물건을 고객에게 전달해요. 그럼 고객은 물건값을 결제기관에 지불하고, 결제기관은 PG사에게 정산해주고, PG사는 상점에게 정산해줘요.

보기에는 간단해 보이지만 카드사 마다 다른 형식의 결제를 요청하고 다른 형식의 결제 결과를 반환해 줘서 PG사를 이용을 안한다면 상당히 번거로운 작업이 반복될 것이다. 하지만 PG사를 이용한다면 일관된 요청과 일관된 결과를 반환 받을 수 있어 개발에 용이하다.

PG사를 활용한 결제 흐름

여기 이 여러 PG사를 모아 간단하면서 한번에 제공해 주는 서비스가 바로 포트원이다.