코뮤(COMMU)

[알고리즘 개념] DP(Dynamic Programming), 대체 뭘까

코뮤(commu) — Thu, 7 Nov 2024 22:56:10 +0900

오랜만에 알고리즘 공부를 다시 시작하고 있다.

그런데... 다 잊었다! 다시 복습해보자!

1. 동적 계획법(Dynamic Programming, DP)란?

큰 문제를 작은 문제로 나누어 푸는 방식이다.

문제를 풀기 위해 작은 문제의 결과를 저장해두고, 같은 문제를 다시 풀 필요가 없도록 한다.

동적 계획법은 보통 재귀적 문제 해결에서 사용되는데, 단순히 재귀만 사용하는 것보다 훨씬 효율적이다.

재귀는 큰 문제를 풀기위해 동일한 작은 문제를 반복해서 호출하는 방식인데,

DP는 이미 계산한 값은 저장해두고 재사용하므로, 동일한 계산을 반복하지 않는다.

2. 왜 동적 계획법을 사용할까?

일반적인 재귀방식은 같은 계산을 여러 번 반복하여 비효율적이다.

예를 들어, 피보나치 수열을 재귀로 계산할 때, fibonacci(5)를 계산하기 위해 fibonacci(3) 과 fibonacci(4)가 필요하고,

fibonacci(3)을 구하기 위해 다시 fibonacci(1)과 fibonacci(2) 를 계산해야한다.

이렇게 되면 같은 값을 여러 번 반복해서 계산하는 것과 다름이 없어진다.

동적 계획법은 중복 계산을 피함으로써 시간 복잡도를 줄여주고, 효율적인 문제 해결이 가능하도록 한다.

이는 특히 큰 수를 다루는 문제나 복잡한 계산이 반복되는 문제에서 유용하다.

3. DP의 두 가지 주요 방식

동적 계획법에는 탑다운(Top-Down) 방식과 바텀업(Bottom-Up) 방식, 두 가지 접근 방법이 있다.

1. 탑다운(Top-Down) 방식

탑다운 방식은 보통 메모제이션(Memoization)과 함께 사용된다.
큰 문제를 작은 문제로 나누어 해결하고, 각 작은 문제의 결과를 저장해두는 방식이다.
예를 들어, 재귀적으로 함수를 호출하면서 계산된 결과를 배열이나 객체에 저장해 중복 계산을 방지한다.

2. 바텀업(Bottom-Up)방식

바텀업 방식은 보통 반복문을 사용하여 작은 문제부터 차례대로 풀어나간다.
작은 문제를 먼저 해결한 후, 그 결과를 차례차례 이용해서 큰 문제를 해결하는 방식이다.
보통 배열이나 테이블을 이용해 작은 문제부터 결과를 저장하고, 최종적으로 큰 문제를 해결한다.

4. 그래서, 이거 언제 필요할까?

동적 계획법이 필요한 알고리즘 문제는 보통 최적 부분 구조와 중복되는 부분 문제라는 특징을 가진다.

최적 부분 구조
- 문제를 작은 문제로 나누어 풀 수 있을 때, 작은 문제들의 결과로 큰 문제를 풀 수 있는 구조
중복되는 부분문제
- 동일한 작은 문제를 여러 번 계산하게 될 때 중복되는 계산을 피하고 효율을 높이기 위해 사용

5. 예시는? - 피보나치 수열

사실 내가 풀다가 온갖 시간초과에,, 런타임 에러를 만난게 바로 이 피보나치 수열 문제였다.

단순히 재귀로만 풀다가 문제한테 뺨맞고 gpt 의 손을 빌렸다.

피보나치 수열은 매우 간단하지만, DP를 설명하기 정말 좋은 예시다.

피보나치 수열에서 n 번째 수는 이전 두 수의 합으로 정의된다.

function fibonacci(n) {
  if (n <= 1) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

위 함수는 중복된 계산이 많아서 비효율적이다.

만약 fibonacci(5)를 계산해야한다면, fibonacci(3)을 두 번이나 계산해야하는 셈이다.

function fibonacci(n, memo={}) {
	if (n <=1 ) return n;
    if (memo[n]) return memo[n];
    
    memo[n] = fibonacci(n-1, memo) + fibonacci(n-2, memo);
    return memo[n];
}

여기서는 중복 계산이 발생하지 않는다.

너무 좋다.

위는 탑-다운 방식으로 메모제이션을 사용해서 풀었다.

function fibonacci(n) {
  if (n <= 1) return n;

  let dp = [0, 1]; // 초기값 설정: dp[0] = 0, dp[1] = 1

  for (let i = 2; i <= n; i++) {
    dp[i] = dp[i - 1] + dp[i - 2]; // 이전 두 값을 더해서 저장
  }

  return dp[n]; // 최종적으로 n번째 피보나치 수 반환
}

이렇게 풀면 바텀업 방식으로, for 문을 돌면서 작은 것들을 계속 더해가는 방식이다.

만약 자신이 아는 것을 테스트해보고 싶은 개발자라면,

아래 프로그래머스 문제를 풀어보는 것도 정말 추천한다!

https://school.programmers.co.kr/learn/courses/30/lessons/12945/solution_groups?language=javascript

AWS Document DB 오프라인 세미나 후기

코뮤(commu) — Mon, 23 Oct 2023 22:57:17 +0900

세미나, 왜 신청했는가!

2023.10.23 에 진행되는 AWS Document DB 세미나에 참여하고 왔다.

현재 우리 회사에서 MongoDB 나 DocumentDB를 사용하고 있는 것은 아니었으나,

NoSQL인 DynamoDB 를 쓰고 있고, 새롭게 시스템 구축이 필요할 때 Dynamo와는 다른 NoSQL 선택지가 어떤 것이 있을지

궁금해서 세미나에 신청했다.

강사님의 강사력(?)도 너무 좋았고, 내용도 일반 강의에서는 골라 듣기 어려운 실무적인 내용이 많이 들어있어서

이제 막 여러 DB를 사용해보기 시작한 나에게는 너무나 유익했던 시간이었다.

(업무시간 빼고 5시간 투자할 가치가 충분했습니다. 다들 츄라이 츄라이)

아래는 강의 세션을 들으면서 내가 기록했던 것들이다.

지식 습득용보다는, 이런 내용들로 세미나 세션이 흘러갔구나~ 하고 보면 좋을 것 같다.

자주 등장한 키워드

Sharding
Schemaless
Secondary index

Why Document Store DB?

샤딩과 Secondary index

왜 NoSQL 진영에서 Document Store DB를 가장 많이 사용할까? 에 대한 답변이다.

NoSQL 데이터베이스 시스템은 일반적으로 데이터의 확장성 측면에서 샤딩을 쉽게 처리할 수 있다.

하지만 다른 Document Store DB 는 다른 NoSQL DB 들과 다르게 Secondary index 를 지원한다.

대표적으로 카산드라와 같은 NoSQL 은 Secondary index 를 지원하지 않는다.

결국 Document Store DB는 관계형 데이터베이스 수준의 B+트리로

Secondary index 를 지원하는 거의 유일한 구조이기 때문에 많이 선택되는 선택지이다.

유연한 json 지원

데이터의 converting 이 필요없음
json 을 의 key를 컬럼 하나하나처럼 사용하는 것은 document store db 가 거의 유일함

비정규화 데이터 모델

기존 RDB는 스키마가 변경됨에 따라 유연하게 대응하기가 쉽지 않음
조회 조건을 다양하게 써야하는 상황에서 유리

"Schemaless 하다"

강사님이 계속해서 강조했던 키워드이다.

이는 장점이 아닌 특징으로, 이 특징 때문에 얻는 이점과, 단점을 명확하게 알고 선택해야한다.

관계형 DB는 고정적인 스키마를 사용하고 있어 테이블의 컬럼과 데이터 타입이 정해져있다.

이는 Storage에 저장될 때는 값들만 저장되고 있다는 의미이다.

하지만 Schemaless 한 특징을 가지고 있는 NoSQL 은 무조건 필드 명과 value 를

같이 디스크에 저장해야한다. 이는 곧 저장 사이즈가 커진다는 의미이다.

저장 사이즈가 커진다? 어? 이거 읽고 쓸 때 IO 가 더 늘어나겠네?

맞다. DB 인스턴스에서 성능을 결정하는 주 원인은 IO 이다.

우리가 index 를 설정하는 이유도 read query 하나를 위해 할당되는 IO 를 줄일 수 있기 때문인데,

저장 사이즈가 늘어남으로 인해 증가되는 IO... 이거 무조건 Trade Off 라는 생각을 해야한다.

=> 결론

: 성능이냐, 편리성이냐를 잘 고려해야한다.

30초 꿀팁!

컬럼명 가능한 작게 잡으세요...^~^

저장공간 뿐만 아니라 성능 자체도 올라갑니다.

unique id 따로 잡지 말고, _id 라는 머신 제너레이트되는 유니크한 데이터 항목을 사용하세요!

데이터가 추가될 때 _id 라는 12바이트 짜리 항목이 새로 생성되는데, 이를 이용하면 12바이트를 줄일 수 있습니다.

DocumentStore Data Model

이 단계가 잘못되면, 서비스에 문제가 생기고 데이터를 다시 쌓아야한다고 하셨다.

모델링 방식은 크게 embedded 방식과 reference 방식이 있다.

embedded data model

Document store 계열 DB를 사용하는데에 올바른 모델링이 맞음
서브 도큐먼트를 변경할 때 lock 문제가 발생함.
- 즉, 동시성 처리가 힘들어짐.

reference data model

분리되어 있으므로 서브 도큐먼트 수정이 가능해짐.
join 과정이 필요함. 만약 mongoDB 기준이면 lookup 을 이용해서 join 해야하는데,
join 이 너무 과도하면 차라리 RDB 선택하는게 더 나음.

=> 결론

: 모델링 잘해야합니다. Access pattern 에 대한 분석이 무엇보다 중요해요.

이 모델에 대한 설명 이후 실제 예시를 통해 어떤 식으로 모델링을 하면 좋을지에 대한 얘기가 이어졌다.

인상적이었던 부분은,
같은 N:M 관계일 때도 그 숫자, 패턴에 의해 임베디드를 선택할지, 레퍼런스를 선택할지가 분명하게 갈린다는 점이었다.

(정말.. 케바케 그 자체. 경험과 통찰력이 참 중요해보였다.)

우리 회사 서비스 중 일부가 RDB에서 NoSQL 로 넘어가면서 수없이 구조를 뒤엎었다.

솔직히 나는 내가 아직 이 기술에 대한 이해가 부족해서 그런가보다... 하고 생각했었는데,

이 부분에서 많은 위안을 얻었다. 정답은 없고, 정답에 가까워지는 길만 무수하게 존재했었던 거구나!

이건 당연하게 겪었어야할 시행착오였구나..! 라는 생각을 하면서 마음이 편안(?)해졌다.

DocumentDB Architecture

AWS Aurora 와 동일한 아키텍처(Mongo DB와는 다른 아키텍처이다.)
완전 관리형
- 고가용성 내장
- 백업 기본
- 내구성 기본 제공
- 모니터링 및 알람
확장성
- 몇 분 내 컴퓨팅 확장
- 스토리지 및 IO 자동 확장
MongoDB API 호환

DocumentDB 는 크게 컴퓨트 레이어와 스토리지 레이어로 분리될 수 있다.

컴퓨트 레이어는 API, Query processor, Caching 등의 역할을,

스토리지 레이어는 logging, storage 의 역할을 담당한다.

(이러한 구조는 트래픽에 따라 필요에 맞춰 증설, 축소 시키기 편리하기 때문이라고 한다.)

이 밖에도 복제는 없으나 복제 지연은 있는 신기한 DocumentDB 의 특징, 샤딩을 위한 Elastic Cluster 등

다양한 설명이 이어졌다.

강사님이 실제 설계 단계에서의 잘못된 판단이 실제 서비스의 장애로 이어졌던 경험을 얘기해주시는데,

이거 남일 같지가 않았다. ㅠㅅㅠ

쿼리의 중요성 판단과 서비스의 액세스 패턴을 파악하고 분석하는 일은 DBA 의 업무가 아닌

개발자의 몫이 맞는 것 같다.

나는 설계 단계에서 어디까지 우리 서비스를 이해하고 분석할 수 있는가? 하며 자기 반성의 시간도 짧게 가졌다.

좋은(훌륭한) 샤드 키 설정 방법도 나오고, DocumentDB 와 MongoDB 의 비교 세션도 있었다.

해당 키워드에 평소 관심이 있었거나 궁금해졌다면 서칭해보길 바란다.

예전 운영체제 시간에 들었던 것만 같은 내용(dirty page)들도 있었다. 개인적으로 너무 재밌었다.

정말 유익하고도 훌륭한 시간이었으니, 기회가 있으면 신청해보길 바라며 이만 포스팅을 마치겠다!

[Docker] 도커를 활용하는 클라우드 서비스

코뮤(commu) — Tue, 8 Aug 2023 22:42:29 +0900

해당 포스팅은
"원티드 프리온보딩 백엔드 8월 코스" 를 수강하며 강의 내용을 정리해본 것입니다.

문제가 있는 내용이거나 오류가 있다면 댓글로 남겨주시면 감사하겠습니다.

컨테이너 오케스트레이션 툴

GCP
- GKE
AWS
- EKS
- ECS

위와 같은 서비스들이 이미 상용화 되어있다.

컨테이너 오케스트레이션의 기능

컨테이너 클러스터링

여러 대의 노드를 하나의 클러스터로 묶어, 애플리케이션을 분산하여 실행하고 자원을 효율적으로 활용하는 기능.
여러 대의 물리적인 또는 가상의 서버를 하나의 시스템처럼 동작하게 하는 기술
컨테이너를 실행하는 호스트의 자원을 효율적으로 분배, 컨테이너가 안정적으로 실행 되도록 함.
여러 대의 컨테이너를 묶어 하나의 서버처럼 사용할 수 있도록 지원함.

서비스 디스커버리

컨테이너를 자동으로 발견하고, 서비스 이름과 IP 주소 등을 관리하여 애플리케이션 간의 연결을 관리하는 기능

자동 스케일링

애플리케이션의 트래픽 양에 따라 자동으로 컨테이너 수 조절
자원 사용량을 최적화 하고 가용성을 보장함

로드 밸런싱

여러 대의 노드에서 실행 중인 컨테이너들을 조절하여, 트래픽을 균등하게 분배함

롤아웃과 롤백

새로운 버전의 애플리케이션을 롤아웃 하고, 이전 버전으로 롤백하는 기능

자동 복구

컨테이너나 노드의 장애 시 자동으로 복구함.

모니터링과 로깅

보안과 네트워크 관리

대표 적인 컨테이너 오케스트레이션 툴/서비스

도커 스웜

쿠버네티스가 등장하기 전까지 가장 대중적인 컨테이너 오케스트레이션 도구 중 하나였다.

간단하게 작동하고, 설정이 쉽다는 장점이 있다.

쿠버네티스

Gmail, Youtube 등의 다양한 웹 서비스가 있고, 대용량 트래픽을 감당해야했다.

이를 감당하기 위해 쿠버네티스 프로젝트를 시작했고, 실 서비스에 적용했다.

오픈소스 기반이고, 구글에서 설계했지만 현재는 리눅스 재단이 관리한다.

대규모 프로젝트에 적합하다.

대표적인 기능은 스케일링, 서비스 디스커버리 기능이다.

가장 기능이 풍부하고 널리 사용되는 컨테이너 오케스트레이션 프레임워크이다.

GKE

구글 클라우드 플랫폼에서 제공하는 쿠버네티스 기반의 관리형 컨테이너 오케스트레이션 서비스이다.

EKS

Amazon AWS 에서 제공하는 관리형 쿠버네티스 서비스이다.

EKS 는 쿠버네티스 기반으로 구축되어 있고, 사용자는 쿠버네티스 API를 사용해 EKS 클러스터를 관리할 수 있다.

ECS

AWS에서 제공하는 관리형 컨테이너 오케스트레이션 서비스이다.

도커 컨테이너를 실행하기 위한 기능을 제공하고 있다.

(EKS 보다 훨씬 간소화 되어있다.)

[Docker] DockerHub에 내 이미지를 올려보자! (feat. docker-compose)

코뮤(commu) — Thu, 3 Aug 2023 22:11:49 +0900

해당 포스팅은
"원티드 프리온보딩 백엔드 8월 코스" 를 수강하며 강의 내용을 정리해본 것입니다.

문제가 있는 내용이거나 오류가 있다면 댓글로 남겨주시면 감사하겠습니다.

Dockerfile syntax

아래는 Dockerfile 에서 사용하는 여러 키워드들이다.

FROM: 베이스 이미지 선정
WORKDIR: work directory 선정
COPY: 복사할 파일 선정
RUN: 실행할 명령어
ENTRYPOINT: 컨테이너가 시작할 때 실행할 명령어

도커이미지를 도커 허브에 올려보자!

이미지 생성은 아래의 명령어로 할 수 있다.

docker build -t my-httpd .

만약 이렇게 만들어진 이미지를 도커 허브에 올리고 싶다면, 이미지 이름은 아래 규칙을 따라야한다.

[Docker Hub 사용자명]/이미지명:[태그명]

예시 - 사용자명은 eunbiiim 이라는 가정!

이렇게 이미지를 만들고 나면, docker login 을 해주자!

docker login

이후 push 를 해주면 된다.

docker push [이미지이름]

만약 login 없이 push 를 하게 된다면, 당연하게도 access 가 deny 된다. 주의하자!

만약 성공적으로 push 되었다면, dockerhub > 자신의 프로필에서 내 이미지를 확인할 수 있을 것이다.

도커 네트워크

docker network ls

위 명령어로 네트워크 리스트를 확인해볼 수 있다.

디폴트로 bridge, host, none 이 있다.

bridge: 기본 네트워크 드라이버로, 동일한 도커 호스트에서 컨테이너간의 통신을 맡는다.
host: 호스트의 네트워크를 직접 사용한다.
overlay: 서로 다른 도커 호스트의 컨테이너 간 통신을 도와준다.

이번 원티드 실습에서는 bridge 를 주로 보게 될 것이다.

docker network inspect bridge

해당 네트워크에 대해 좀 더 자세하게 보고 싶다면, inspect 키워드를 이용하면 된다.

위 명령어의 bridge 대신 host, overlay 등등 네트워크의 이름을 넣으면 된다.

Docker-compose

만약 여러 개의 컨테이너를 빌드하고, 실행해야한다면 어떻게 해야할까?

컨테이너가 늘어나면 늘어날 수록 관리포인트는 커질 것이다.

이를 한번에 관리할 수 있도록 해주는 것이 바로 docker-compose 이다.

우선 아래 명령어로 네트워크를 만들어주자.

docker network create wordpress_net

docker \
run \
    --name "db" \
    -v "$(pwd)/db_data:/var/lib/mysql" \
    -e "MYSQL_ROOT_PASSWORD=root_pass" \
    -e "MYSQL_DATABASE=wordpress" \
    -e "MYSQL_USER=docker_pro" \
    -e "MYSQL_PASSWORD=docker_pro_pass" \
    --network wordpress_net \
mysql:latest

위의 명령어를 실행하면, mysql 이미지를 가져와 실행해 줄 것이다.

다음으로, 아래 명령어를 실행해 워드프레스 컨테이너도 실행시켜주자.

docker \
    run \
    --name app \
    -v "$(pwd)/app_data:/var/www/html" \
    -e "WORDPRESS_DB_HOST=db" \
    -e "WORDPRESS_DB_NAME=wordpress" \
    -e "WORDPRESS_DB_USER=docker_pro" \
    -e "WORDPRESS_DB_PASSWORD=docker_pro_pass" \
    -e "WORDPRESS_DEBUG=1" \
    -p 8000:80 \
    --network wordpress_net \
wordpress:latest

정상적으로 실행되었다면, 아래 명령어를 실행한 후 실행되고 있는 두 개의 컨테이너들이 보일 것이다.

docker ps

그런데... 이렇게 길고 복잡한 명령어를 컨테이너를 만들고 실행할 때마다 적어줘야할까?

헬파티! 헬파티! 커맨드 라인이 여러 줄이면 관리하기 너무 힘들고, 타이핑 하기도 너무나.. 귀찮다.

이럴 때, docker-compose 를 쓰면 된다.

docker-compose 란?

도커 컨테이너를 일괄적으로 정의하고 제어하는 도구
설정 파일을 도커 CLI로 번역하는 역할

아래와 같은 yml 파일이 있다고 가정할때,

docker compose 명령어를 이용해서 컨테이너 관리를 손쉽게 할 수 있다.

version: "3.0"

services:
  db:
    image: mysql:latest
    volumes:
      - ./db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: root_pass
      MYSQL_DATABASE: wordpress
      MYSQL_USER: docker_pro
      MYSQL_PASSWORD: docker_pro_pass
  
  app:
    depends_on: 
      - db
    image: wordpress:latest
    volumes:
      - ./app_data:/var/www/html
    ports:
      - "8000:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: docker_pro
      WORDPRESS_DB_PASSWORD: docker_pro_pass

이런 yml 파일을, 아래 명령어로 실행시켜주자!

docker compose -f [파일 이름] up --build

(build 옵션은 시작하기 전 이미지를 먼저 생성하라는 옵션이다.)

docker compose file

좀 더 자세하게 알아가보자,

version
services : 컨테이너들의 정의가 들어간다.
- 실행하려는 컨테이너들을 정의하는 역할
- 이름, 이미지, 포트 매핑, 환경 변수, 볼륨 등을 포함
- 해당 정보를 가지고 컨테이너를 생성하고 관리
- image: 컨테이너를 생성할 때 쓰일 이미지 지정
- build: 정의된 도커파일에서 이미지를 빌드해 서비스의 컨테이너를 생성하도록 함.
- environment : 환경변수 설정
- command: 컨테이너가 실행될 때 수행할 명령어(docker run 명령어의 마지막 커맨드와 동일)
- depends_on: 컨테이너 간의 의존성 주입.
- ports: 개방할 포트 지정, docker run 명령어의 -p 와 같다.
- expose: 링크로 연계된 컨테이너에게만 공개할 포트 설정
- volumes: 컨테이너에 볼륨 마운트
- restart: 재시작 정책
  - no: 재시작 x
  - always: 외부 영향에 의해 종료되었을때 항상 재시작
  - on-failure: 오류가 생겨 종료되었을 때만 재시작
network : 이 컨테이너들이 공유할 network 를 정의한다. (지정해주지 않아도 [이름_default]으로 하나 만들어준다.)
volumn
config
secret

그만 알아보자.

공식문서 가져와!

(추가로, 나는 docker-compose 로 알고 있었는데, 요즘은 docker compose 로 쓰더라...

강사님이 말씀해주셨는데, docker-compose 가 docker compose 로 흡수되었다고 한다.

뜻밖의 인수합병... )

오늘 이렇게 dockerhub 에 내 이미지를 올리는 방법과 docker-compose 의 사용에 대해 알아보았다.

한번 다 경험해봤던 건데도 다시 한번 들으니 새롭다.

다음 사이드플젝은 꼭 도입해봐야겠다! 오늘도 즐거웠습니다!

[Docker] Docker 의 기본 개념과 사용법

코뮤(commu) — Tue, 1 Aug 2023 22:47:53 +0900

해당 포스팅은
"원티드 프리온보딩 백엔드 8월 코스" 를 수강하며 강의 내용을 정리해본 것입니다.

문제가 있는 내용이거나 오류가 있다면 댓글로 남겨주시면 감사하겠습니다.

Docker 를 설명해보자.

open platform
어플리케이션을 인프라에서 분리
신속하다
인프라를 어플리케이션을 관리하는 것처럼 관리할 수 있음
코드 배포에 용이하다.

도커는 결국 컨테이너 기반 가상화 도구이다.

애플리케이션을 컨테이너 단위로 격리하여 실행하고 배포하는 기술인 것이다.

그럼 여기서, 컨테이너란 무엇일까?

컨테이너란 무엇인가?

가상화 기술 중 하나로,

호스트 운영체제 위에 여러 개의 격리된 환경을 생성한다.

그럼 꼬리 질문으로, 가상화 기술은 무엇일까?

가상화 기술이란?

하나의 물리적인 컴퓨터 자원을 가상적으로 분할하여 여러 개의 가상 컴퓨터 환경을 만들어 내는 기술이다.

이를 통해 물리적인 컴퓨터 자원을 더욱 효율적으로 사용할 수 있고,

서버 운영에 있어 유연성과 안정성을 제공한다.

하이퍼 바이저란?

가상머신을 생성하고 구동하는 소프트웨어로,

OS에 자원을 할당 및 조율하고 OS들의 요청을 번역해 하드 웨어에 전달하는 역할을 했다.

vmware, virtual box 등의 프로그램이 이 하이퍼바이저 방식을 채택한 프로그램인데,

예전 학교 다닐 때도 가상머신을 여러 개 띄우려면 항상 렉이 걸려 고생했었다.

도커는 하이퍼바이저에서 리소스를 많이 잡아먹던 게스트 OS 를 없애고,

도커 엔진 위에 바로 애플리케이션을 올려 더 가볍게 여러 애플리케이션을 실행할 수 있게 해준다.

Docker 의 기본 개념과 구조

도커 데몬

도커 엔진의 핵심 구성 요소
도커 호스트에서 컨테이너를 관리하고 실행
컨테이너 생성, 시작, 중지, 삭제 작업 수행
컨테이너 이미지 관리
외부에서 이미지 다운로드, 빌드 작업 수행

도커 클라이언트

docker 데몬과 상호작용
docker 명령어를 사용하면 docker daemon 으로 보내 실행

도커 오브젝트

도커 이미지
- 도커 컨테이너를 만들기 위한 읽기전용 템플릿
도커 컨테이너
- 한 도커 이미지의 실행 가능한 인스턴스
- 애플리케이션을 실행하기 위한 모든 파일과 설정 정보 포함하는 패키지

도커 레지스트리

도커 이미지를 관리하고 저장하는곳
Docker Hub, AWS 레지스트리 등

이해를 좀 더 쉽게 해보자!

App Store 를 Docker Hub 라고 이해하고,

Program 은 Image,

Process 는 Container 라고 이해하면 조금 더 잘 와닿는다.

Docker 사용법

(설치는 되어있다고 가정함미다)

https://hub.docker.com/_/httpd

httpd - Official Image | Docker Hub

Quick reference Supported tags and respective Dockerfile links 2.4.57, 2.4, 2, latest, 2.4.57-bookworm, 2.4-bookworm, 2-bookworm, bookworm 2.4.57-alpine, 2.4-alpine, 2-alpine, alpine, 2.4.57-alpine3.18, 2.4-alpine3.18, 2-alpine3.18, alpine3.18 Quick refere

hub.docker.com

docker hub 에 이미 올려져있는 httpd 이미지를 가져오자!

docker pull httpd

이미지 목록을 확인하고 싶을때는 아래 명령어로 확인가능하다.

docker images

이미지를 실행시키고 싶다면, 아래와 같은 명령어를 입력하면 되는데, 옵션이 참 많다.

자세하게 알아보려면 역시 공식 문서를 찾아보자.

docker run httpd
docker run --name secondContainer httpd
docker run -p 8888:80 -v [마운트 될 로컬 경로]:/usr/local/apache2/htdocs httpd

-p 는 publish 옵션이고, -v 는 volumn 매칭 옵션이다.

docker ps
docker ps -a

실행중인 도커 컨테이너는 위와 같은 명령어로 확인 가능하다.

docker stop [container id]

실행 중인 컨테이너 id를 이용해서 도커 컨테이너를 중지시킬 수 있다.

docker 컨테이너를 삭제하려면 아래 명령어를 사용하면 된다.

docker rm [container id]

이미지는 아래와 같이 삭제할 수 있다.

docker rmi [image id]

컨테이너에 접속해 컨테이너 명령어를 치려면 exec 를 사용하면 된다.

docker exec -it [container id] /bin/sh

Dockerfile 을 활용해보자!

FROM httpd:latest
COPY  index.html /usr/local/apache2/htdocs/index.html
EXPOSE 80

위 DockerFile 을 이용해서 이미지를 만들어보자.

아래 명령어로 이미지를 빌드할 수 있다.

docker build -t my-httpd .

-t 옵션은 태그로, 뒤에 오는 문자열이 태그의 이름이다. 가장 뒤의 . 은 DockerFile의 위치이다.

. 이라는 뜻은 현재 경로에 DockerFile 이 있다는 뜻이다.

직접 빌드를 했으면, docker images 명령어를 통해 내가 만든 이미지를 확인할 수 있다!

내가 만든 이미지는 이전에 했던 것 처럼,

docker run [이미지 이름]

명령어를 통해 실행시킬 수 있다.

추가 자료 - Container Lifecycle

docker 에서 run 은 create 와 start 가 연속적으로 이루어지는 동작이다.

모종의 이유로 stop 되었을 경우, 다시 생성할 필요없이 start 하면 된다.

VScode 에서 파일구조를 그려보자! (file-tree-generator)

코뮤(commu) — Tue, 1 Aug 2023 12:12:35 +0900

여태껏 README.md 파일에 파일 구조를 옮겨 적을 때

tree 명령어를 쳐서 나온 결과물을 그대로 복붙해왔었다.

이번에 서버팀 내에서 typescript template 제작을 맡게 되었는데,

내 템플릿의 구조를 설명할 때, 좀 더 편리하고 예쁘게 파일 구조를 알릴 수 있는 방법이 없을까 찾아보다가

발견한 vscode extension 이다.

file-tree-generator

vscode 의 extenstions 탭에서 file-tree-generator 를 검색하자.

바로 저 확장프로그램이다. 설치해주도록 하자!

이제 내가 구조를 표현하고 싶은 폴더에서 우클릭을 하고, Generate to Tree 를 선택해주자.

그럼 아래와 같은 결과물을 얻을 수 있다.

icon 을 on/off 할 수 있는 기능이 있는데,

나는 개인적으로 아이콘이 있는게 훨씬 좋아보였다.

해당 내용을 복사/붙여넣기 하여 자유롭게 쓰면된다.

추가로, 노션에다 붙여넣으면 아래와 같이 예쁘게 표현된다.

여러 문서를 작성할 때, 큰 도움이 될 것 같다!

[ DB ] 아키텍처 설계, 어떻게 들어가야할까?

코뮤(commu) — Fri, 11 Nov 2022 12:50:15 +0900

최근 한빛미디어에서 나온 데이터베이스 첫걸음이라는 책을 읽고 있다.

이 책을 읽으며 내가 기록하고 싶은 것들을 기록해나가겠다.

나는 현재 회사에서 서버 이전 작업중이다.

그러면서 기존 db를 전부 분리하고, table 설계를 다시 하는 등의 작업을 예상하고 있다.

그래서 이 책을 집어들었다.

아키텍처는 어떻게 우리에게 왔는가 - 아키텍처의 역사

사실 아키텍처라는 단어 자체가 굉장히 추상적이다.

이를 이해하기 위해 역사를 좀 되짚어보자.

stand-alone 구조

초기에는 DB 서버가 네트워크에 접속하지 않고 독립되어 동작했다.

이러한 구성에서는 DBMS(데이터베이스 미들웨어)와 애플리케이션 소프트웨어는 같은 DB 서버에서 동작한다.

그렇기 때문에 내가 DB를 쓰고 싶으면, 물리적으로 그 DB에 가야지만 사용할 수 있었다.

클라이언트/서버 구조

드디어 네트워크를 이용해 데이터베이스 서버 1대에 복수 사용자 단말이 접속하기 시작했다.

서버에서는 DBMS가 동작하고, 클라이언트에서는 업무 애플리케이션이 동작하는 분업체계가 마련된 것이다.

Web 3계층

클라이언트/서버 구조에서는 클라이언트에 설치되어 있는 애플리케이션이 각기 다르다는 문제점이 있었다.

이 애플리케이션은 버전 관리, 버그 수정 버전을 배포하는데 엄청난 비용이 필요하다.

때문에 비즈니스 로직을 실행하는 애플리케이션을 서버에서 관리해 비용을 절감하기 시작했다.

Web 3 계층은 이를 위해 제시된 것이다.

Web 3계층의 3가지 계층은 아래와 같다.

웹 서버 계층
애플리케이션 계층
데이터베이스 계층

웹 서버는 클라이언트로부터 접속 요청을 받아 처리를 애플리케이션 서버에 넘기고 그 결과를 반환한다.

애플리케이션 계층은 요청을 받는 역할을 웹 서버 계층해 한정해 애플리케이션 계층과 데이터베이스 계층의 보안을 높인다.

가용성과 확장성, 어떻게 높일까?

이번 카카오 사태를 보면서 우리 회사에서도 가용성에 대해 다시한번 생각해보게 되었다.

가용성을 높이려면 '심장전략' 과 '신장전략' 을 먼저 고려해야한다.

심장전략은 고품질 소수전략으로, 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제한다.

신장전략은 저품질 다수전략으로, '사물은 언젠가 망가진다' 라는 생각을 전제로 여분을 준비한다. 물량 작전인 것이다.

나는 학생 때 볼펜이 고장날 때를 대비해서 항상 여분을 들고다녔다. 물량 작전이다.

하지만 세탁기가 고장날 때를 대비해 세탁기 여분을 준비해놓진 않는다. 뭐, 이런 것이다!

클러스터?

신장 전략처럼 동일한 기능의 컴포넌트를 병렬화하는 것을 '클러스터링'이라고 한다.

이러한 클러스터들의 구성으로 시스템의 가동률을 높이는 것을 'Redundancy(여유도)를 확보한다' 또는

'다중화' 라고 칭한다.

단일 장애점? (SPOF)

다중화되어있지 않아 시스템 전체 서비스의 계속성에 영향을 주는 컴포넌트를 단일 장애점이라고 한다.

쇠사슬의 강도는 가장 약한 고리의 강도로 결정된다는 말 처럼,

단일 장애점의 신뢰성이 시스템 전체의 가용성을 결정한다.

DB 서버의 다중화 - 클러스터링

이제 드디어 DB와 관련된 얘기를 해보겠다.

DB는 데이터를 보존해야하는 영속 계층이기 때문에, 다중화에 대해 고민이 더욱 더 필요하다.

데이터는 항상 갱신되기에 다중화를 유지하는 중에 '데이터 정합성'도 중요하게 의식해야한다.

기본 다중화

가장 간단한 다중화 구성은 DB 서버만 다중화하고, 저장소는 하나만 두는 구성이다.

이는 저장소가 1개라 정합성을 신경쓸 필요가 없다.

DB 서버가 2대지만,

이 두 대를 동시에 실행하는 Active-Active 와 하나는 실행, 하나는 대기 시켜놓는 Active-Standby 중 선택해야한다.

+ 현재 Active-Active 를 지원하는 DB는 Oracle과 DB2 뿐이라고 한다.

DB 서버와 데이터의 다중화 - 리플리케이션

DB서버와 저장소 세트를 복수로 준비하는 것이다.

리플리케이션은 저장소와 db 서버가 동시에 사용불능일 때 다른 세트가 존재한다면

서비스를 계속하게 하는것이 가능해 가용성이 매우 높은 아키텍처이다.

이 단단함 덕분에 재난 복구 계획으로 이용되는 경우도 있다.

리플리케이션에서 중요한 점은 Active 측 저장소의 데이터와 Standby 저장소와의 동기화다.

항상 최신화하지 않으면 데이터 정합성을 유지할 수 없다.

성능을 추구하는 다중화 - Shared Nothing

복수의 서버가 1대의 디스크를 사용하는 구성을 Shared Disk 라고 부른다.

이 구성의 Active-Active 구성은 DB 서버를 늘려도 어느 순간 한계가 온다.

DB 서버 대수가 증가할 수록 이 서버간 정보 공유를 위한 오버헤드가 커지기 때문이다.

이를 해결하기 위한 아키텍처로 고안된 것이 'Shared Nothing' 이다.

아무것도 공유하지 않는다는 의미로, 네트워크 외의 자원을 모두 분리하는 방식이다.

구글은 이를 '샤딩'이라고 칭한다. 어디서 많이 들어본 단어다.

아키텍처를 고르는 것은 시스템이 어떤 요건을 충족시켜줘야하는지에 따라 달라지기 때문에

그 요건을 결정하지 않으면 아키텍처도 결정할 수 없다는걸 기억하자.

"개발자의 글쓰기" 후기 - 저도 잘 쓰고 싶어요

코뮤(commu) — Wed, 9 Nov 2022 12:18:57 +0900

점심시간, 출퇴근 시간에 책을 잡고 읽기 시작했다.

오늘은 약 일주일간 내 출퇴근 시간을 책임졌던 "개발자의 글쓰기"에 대한 내 생각, 중요한 것들을 정리해보려고 한다.

http://www.yes24.com/Product/Goods/79378905?pid=123487&cosemkid=go15700131051712730&gclid=CjwKCAjwtp2bBhAGEiwAOZZTuBwSw0KSlvSlbWnW04wA_S8D6vRQ6Xu3FmKtCGert4btoog0XKMqFhoCbCcQAvD_BwE

개발자의 글쓰기 - YES24

오직 개발자를 위한 글쓰기의 모든 것을 담았다!이 책은 개발자의 글쓰기 능력을 종합적으로 향상하기 위한 책이다. 코드 안에서는 함수와 변수 이름을 짓는 것부터 주석 쓰는 법, 에러 메시지

www.yes24.com

이 책을 도서관에서 집게된 것은 책의 제목보다는 소제목 격인 '변수 네이밍부터' 라는 문구에 이끌렸기 때문이다.

당시(사실 아직도) 나는 내 이름 짓기 실력에 자신이 없었다.

물론 코드만 잘 돌아간다면야 뭐가 문제가 되겠느냐 하는 사람들도 있겠지만, 난 아름다운 코드를 작성하고 싶었다.

코드 한 줄을 짜더라도 최대한 간결하지만서도 추후 이 코드를 볼 누군가도 납득이 가게끔 짜고 싶었다.

하지만 아직 내가 많은 코드를 작성해보지 않아서 그랬는지, 이름 짓기에 생각보다 시간을 많이 할애하고 있었다.

여전히 새로운 변수를 생성할 때, 새로운 함수, 클래스, 파일이 생길 때 고민했다.

아직도 내 브라우저 책갈피 순서 첫번째는 변수명을 지어주는 사이트다.

이 자리를 빌어 감사합니다...(https://www.curioustore.com/#!/)

내 변수명 짓기 방법은 규칙이 없었다. 없었기에 중구난방했다.

이 책을 읽고 난 후 난 내 나름의 가이드를 세울 수 있었던 것 같다.

책을 읽으며 내가 납득이가고 보편적으로 동의할만한 내용들을 머릿속에 차곡차곡 심었다.

내 나름대로 정의내린 것중 기억에 남는 것은 아래와 같다.

중요한 것은 표기 자체가 아닌 그렇게 쓰는 이유

코드의 네이밍 컨벤션은 영어 표기법을 상속받음

유명한 파스칼 표기법과 카멜 표기법은 영어의 대문자 표기원칙을 상속받은 것이다.

영어의 대문자 표기 원칙은

중요하거나 크거나 특정한 것을 가리키거나 제목에 해당하는 명사는 첫 글자를 대문자로 작성하고,

그런 명사들이 이어질 때는 첫 글자를 모두 대문자로 쓰고,

명사나 관사가 아닌 동사, 형용사는 모두 소문자를 쓴다.

따라서 인터페이스나 클래스같은 객체의 틀은 첫 글자를 대문자로 쓰는 파스칼 표기법을 이용하고,

함수, 변수는 카멜 표기법으로 작성해야겠다고 규칙을 정했다.

물론 여태껏 클래스는 파스칼, 함수와 변수는 카멜 표기법을 고집하면서 코드를 썼었지만,

남들이 으레 그러하듯이 나도 별 생각 없이 쓴 것 같은데, 책에서 영어 표기법과 함께 말해줘 더 와닿았던 것 같다.

검색하기 쉬운 이름으로 짓자

내가 이 책의 목차 중에서 가장 공감했던 부분이 이 부분이었다.

코드에서 주석은 중요하지만, 만약 주석없이 이름만으로도 그 동작을 예측할 수 있다면 더할나위 없이 좋을 것이다.

나는 현재 IDE 에서 제공하는 바로가기 기능을 이용해 여러 변수들이 어디에서부터 왔고, 어떤 동작을 하는지 파악하고 있지만

그것은 그 변수의 존재를 알 때나 가능한 일이다.

만약 특정 기능을 하는 함수를 내가 어딘가에 구현해 놨는데, 도저히 어디에 있는지 잘 모르겠다면?

답은 검색 뿐이다.

그런데 내가 그 기능을 하는 함수를 a 라고 정말 성의없이 정의해놨다면, 난 아마 꼼짝없이 그 기능을 처음부터 다시 구현해야할 것이다.

뭐 물론 극단적인 예시지만,

변수명을 정할 때 보편적인 시각에서 '이런 기능은 이렇게 검색할 것이다' 라는 생각을 하고 짓는 것과

그렇지 않을 때의 변수명은 크게 달라지지 않을까 생각한다.

책의 후반부는 개발 블로그에 대한 내용이 이어진다.

나도 현재 블로그를 운영하는 입장에서, 집중하지 않을 수가 없었다.

그 중 집중하며 봤던 부분은 기술 블로그의 4중류, 저, 술, 편, 집 이라는 파트이다.

해당 파트를 읽고 포스팅하는 글의 구분이 명확해졌다.

구분	내용	종류
저	직접 경험하고 실험한 과정이나 결과	개발기, 도입기, 적용기
술	어떤 것을 분석하여 의미를 풀이하고 해석한 것	기술 소개, 용어 분석, 에러 해결 방법 등
편	산만하고 복잡한 자료를 편집해 질서를 부여한 것	프로그램 설치/설정 방법, 튜토리얼, 세미나 후기, 책 리뷰
집	여러 사람의 견해나 흩어진 자료를 한데 모아 정리한 것	명령어 모음, 팁, 규칙

사실 이 블로그는 2019년부터(내가 학생일 때부터) 학교 수업의 복습용도로, 에러 해결 키노트로, 여러 학습 용도로 마구잡이로 써왔다.

글도 정제되어 있지 않고, 아마 틀린 내용도 많을 것이다.

여태까지 난 블로깅을 하면서 어차피 내가 볼건데 뭐 라는 생각을 주로 했던 것 같다.

퀄리티가 좋은 글들, 실제 독자들에게 도움이 될만한 글은 아니었다고 생각한다.

그래서 이 블로그는 원래의 목적(?) 처럼 잡다하게 정제되어있지 않은 지식을 담는 용도로 쓰고,

새롭게 기술블로그라고 칭할 수 있을 만한 퀄리티의 포스팅을 뿜어내는 블로그를 파볼까 한다.

(저, 술, 편, 집이 명확한 블로깅)

아직 정확하게 일정은 잡히지 않았다만, 블로그를 새로 시작한다면 공지를 드리도록 하겠습니다 'ㅅ'

[ 모던 자바스크립트 스터디 ] Ajax

코뮤(commu) — Sun, 6 Nov 2022 00:46:58 +0900

Ajax?

Ajax(Asynchronous Javascript and XML) 란 자바스크립트를 사용하여 브라우저가 서버에게 비동기 방식으로 데이터를 요청하고,

서버가 응답한 데이터를 수신하여 웹페이지를 동적으로 갱신하는 프로그래밍 방식을 말한다.

Ajax는 브라우저에서 제공하는 Web API 인 XMLHttpRequest 객체를 기반으로 동작한다.

XMLHttpRequest는 HTTP 비동기 통신을 위한 메서드와 프로퍼티를 제공한다.

이전 웹페이지는 완전한 HTML 을 서버로 부터 받아 웹 페이지 전체를 처음부터 다시 렌더링하는 방식으로 동작했다.

화면 전환시 웹 페이지 전체를 처음부터 다시 렌더링 했어야했던 것이다.

Ajax 는 이런 전통적인 패러다임을 전환했다.

JSON

JSON.stringify

객체를 json 으로 직렬화

JSON.parse

JSON 포맷 문자열을 객체로 변환(역직렬화)

XMLHttpRequest

자바스크립트를 사용해 HTTP 요청을 전송하려면 XMLHttpRequest 객체를 사용한다.

XMLHttpRequest 객체 생성

XMLHttpRequest 객체는 XMLHttpRequest 생성자 함수를 호출해서 생성한다.

이는 브라우저에서 제공하는 Web API 라서 브라우저 환경에서만 정상적으로 실행된다.

const xhr = new XMLHttpRequest();

XMLHttpRequest 객체의 프로퍼티 / 메서드

중요한 것만 보자.

XMLHttpRequest 객체의 프로토타입 프로퍼티

readyState : HTTP 요청의 현재 상태 나타내는 정수.

status : HTTP 요청에 대한 응답 상태 나타내는 정수.

statusText : HTTP 요청에 대한 응답 상태 나타내는 문자열 ex) "OK"

responseType : HTTP 응답 타입 ex) document, json ,text ...

response : HTTP 요청에 대한 응답 몸체

XMLHttpRequest 객체의 이벤트 핸들러 프로퍼티

onreadystatechnage : readyState 프로퍼티 값이 변경된 경우

onerror : HTTP 요청에 에러 발생 경우

onload : HTTP 요청 성공적으로 완료한 경우

XMLHttpRequest 객체의 메서드

open : HTTP 요청 초기화

send : HTTP 요청 전송

abort : 이미 전송된 HTTP 요청 중단

setRequestHeader : 특정 HTTP 요청 헤더값 설정

XMLHttpRequest 객체의 정적 프로퍼티

DONE : 서버 응답 완료 (4)

HTTP 요청 전송

XMLHttpRequest.prototype.open 메서드로 HTTP 요청 초기화
XMLHttpRequest.prototype.setRequestHeader 메서드로 HTTP 요청의 헤더값 설정
XMLHttpRequest.prototype.send 메서드로 HTTP 요청 전송

const xhr = new XMLHttpRequest();

xhr.open('GET', '/users');

xhr.setRequestHeader('content-type', 'application/json');

xhr.send();

HTTP 요청 처리

서버가 전송한 응답을 처리하려면 XMLHttpRequest 객체가 발생시키는 이벤트를 캐치해야한다.

XMLHttpRequest 는 onload, onerror 와 같은 이벤트 핸들러 프로퍼티를 갖는다.

이 이벤트 핸들러 프로퍼티 중에서 HTTP 요청의 현재 상태를 나타내는 readystatechange 이벤트를 캐치해 응답을 처리할 수 있다.

const xhr = new XMLHttpRequest();

xhr.open('GET', '원하는 url');


xhr.send();

xhr.onreadystatechange = () => {
	if (xhr.readyState !== XMLHttpRequest.DONE) return;
    
    if (xhr.status === 200) {
    	console.log('완료');
    } else {
    	console.error('Error', xhr.status);
    }
}

readystatechange 대신 HTTP 요청이 성공적으로 완료된 경우 발생하는 load 이벤트를 캐치해도 좋다.

[ 모던 자바스크립트 스터디 ] REST API

코뮤(commu) — Sat, 5 Nov 2022 23:50:44 +0900

REST 는 HTTP를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정한 아키텍처고,

REST API는 REST를 기반으로 서비스 API를 구현한 것을 의미한다.

REST API의 구성

REST API 는 자원(Resource), 행위(verb), 표현(Representations) 의 3가지 요소로 구성된다.

REST는 자체 표현 구조로 구성되어 REST API 만으로 HTTP 요청의 내용을 이해할 수 있다.

구성요소	내용	표현 방법
자원	자원	URI
행위	자원에 대한 행위	HTTP 요청 메서드
표현	자원에 대한 행위의 구체적 내용	페이로드

REST API 설계 원칙

두가지만 알고 있으면 된다.

URI 는 리소스를 표현하는데 집중하고, 행위에 대한 정의는 HTTP 요청 메서드를 통해 하는 것.

URI는 리소스 표현

리소스를 식별할 수 있는 이름은 동사보다는 명사를 사용한다.

리소스에 대한 행위는 HTTP 요청 메서드로 표현

주로 5가지 요청 메서드(GET, POST, PUT, PATCH, DELETE 등)을 사용해 CRUD를 구현한다.

이후엔 예제가 나온다.