• AWS EC2 Ubuntu
• 가용 영역 : 모든 볼륨의 가용 영역이 같아야 한다.

인스턴스(준비)

1. Origin 인스턴스(테스트용)

   • 간단히 MySQL을 설치하고 test db 생성 후 값을 넣어 두었다.

     create database test;
     use test;
     create table test(
     id varchar(24),
     text varchar(20)
     );
     
     select * from test;
     insert into test values('1', '1'),('2', '2'),('3', '3');

     // 아래 명령어를 통해 해당 인스턴스가 ext인지 확인
     df -TH

2. Resize 인스턴스

   • 축소할 볼륨을 추출하기 인스턴스이다.
   • 볼륨을 생성하고 삭제한다.

3. Temp 인스턴스

   • Origin의 볼륨의 데이터를 Resize 볼륨에 복사하기 위한 작업을 진행하기 위한 인스턴스이다.

EC2 볼륨 축소 작업

1. Origin 인스턴스(원본)를 준비 후 인스턴스 정지하고 볼륨을 추출한다. (필자는 테스트로 진행하기 때문에 원본 인스턴스를 생성 후, Origin 인스턴스의 볼륨을 추출한다.) (실제 사용하는 인스턴스를 사용할 경우 해당 인스턴스의 볼륨을 스냅샷을 생성 후, 생성된 스냅샷을 통해 볼륨을 생성한다.)

2. Resize 인스턴스를 생성 후 인스턴스 중지하고 볼륨 탭에 들어가서 Resize의 볼륨을 분리합니다.

3. Temp 인스턴스 생성 후 Origin, Resize 볼륨을 연결해준다. 아래의 이미지는 Origin, Resize 볼륨을 연결 후 해당 인스턴스의 스토리지 탭에서 제대로 연결되었는지 확인할 수 있다.

4. Temp 인스턴스에 SSH 연결하고 lsblk를 통해 연결된 볼륨을 확인한다. 이때, xvdf 가 Origin 볼륨(30G), xvdg가 Resize 볼륨(20G)이다.

   lsblk

   위의 이미지에서 MOUNTPOINT 가 작업할 파티션(xvdf1, xvdg1)에 '/'로 지정되어 있다면 잘못되었기 때문에 잘 체크해준다.!! (파일 시스템을 체크할 때 마운트되어있으면 안되기 때문이다.) 아래의 작업을 진행할 때 볼륨의 타입이 disk가 아닌 part(파티션)에 작업을 진행한다.

5. 다음으로 e2fsck를 통해서 파일 시스템을 체크한다.

   e2fsck -f /dev/xvdf1

   

6. resize2fs 명령어를 통해 ext2/ext3/ext4 파일 시스템 크기를 최소한의 크기로 줄인다.

   resize2fs -M -p /dev/xvdf1

   resize2fs 옵션

   -M : 파일 시스템을 최소한의 크기로 줄임 -p : 실행이 완료되는 상태를 퍼센트 비율로 출력 위의 이미지에서 빨간 박스는 4K단위의 블록의 974729개 이다.

7. 6번의 결과 이미지에 빨간 박스 부분이 blockcount이다. 다음 작업으로 Resize 볼륨에 Origin 볼륨을 복사하기 위해서 dd 명령어를 통해 복사하기 위해 count를 계산해야 한다. 이때 bs=16M으로 진행한다.

   계산식

   blockcount * 4 / (16 * 1024) 위의 공식대로 계산하면 974729 * 4 / (16 * 1024) = 237.97094...이 나오는데 올림해서 238이다.

8. 이제 dd 명령어를 통해 블록단위로 디스크(Resize 볼륨)를 복사를 해준다.

   dd if=/dev/xvdf1 of=/dev/xvdg1 bs=16M count=238 status=progress
   // bs는 한번에 읽고 쓸 사이즈를 의미하고, count는 횟수
   // status=progress는 진행 상태를 표시

   

9. 디스크 복사가 끝나면 Resize 볼륨의 파일 시스템 크기를 조절한다.

   resize2fs -p /dev/xvdg1

   

10. e2fsck를 통해 파일 시스템을 체크한다. 파일 시스템 체크가 완료되면 Temp 인스턴스에서 수행해야 하는 작업이 완료되었다.

    e2fsck -f /dev/xvdg1

    

11. 다시 aws console로 돌아가서 Temp 인스턴스를 중지하고, Origin, Resize 볼륨을 분리하고, Origin 인스턴스에 Resize 볼륨을 연결시킨다. 이때, Origin 인스턴스가 루트 디바이스로 마운트 되어야하기 때문에 Origin 인스턴스의 루트 디바이스 이름과 동일하게 입력한다. 볼륨을 연결 후 Origin 인스턴스를 다시 시작한다. Origin 인스턴스의 스토리지 탭에서 축소된 볼륨크기를 확인 할 수 있다.

12. 다시 MySQL에 접속하여 이전 볼륨의 데이터와 동일한지 한번 확인하자

참고

• https://1mini2.tistory.com/90

카프카 브로커

카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션

• 데이터 저장, 전송

  • 프로듀서로 부터 데이터를 전달받으면 카프카 브로커는 프로듀서가 요청한 토픽의 파티션에 데이터를 저장
  • 컨슈머가 데이터를 요청하면 파티션에 저장된 데이터를 전달
  • 카프카는 메모리나 데이터베이스에 저장하지 않으며 따로 캐시메모리를 구현하여 사용하지도 않는다.
  • 카프카는 페이지 캐시를 사용하여 디스크 입출력 속도를 높였음
  • 페이지 캐시란 OS에서 파일 입출력의 성능 향상을 위해 만들어 놓은 메모리 영역을 말한다.
  • 한번 읽은 내용은 메모리의 페이지 캐시 영역에 저장시킨다.

• 데이터 복제, 싱크

  • 데이터 복제는 카프카를 장애 허용 시스템으로 동작하도록 하는 원동력
  • 파티션 단위로 이루어짐
  • 복제된 파티션은 리더와 팔로워로 구성
  • 프로듀서와 컨슈머에서 직접 통신하는 파티션은 리더, 나머지를 팔로워라 부름
  • 운영할때 2이상의 복제 개수를 정하는 것이 중요

• 컨트롤러

  • 클러스터의 다수 브로커 중 한대가 컨트롤러 역할을 함
  • 다른 브로커들의 상태를 체크하고 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배함
  • 컨트롤러역할을 하는 브로커가 장애가 생기면 다른 브로커가 컨트롤러 역할을 수행함

• 데이터 삭제

  • 다른 컨슈머가 데이터를 가져가더라도 삭제되지 않음
  • 컨슈머나 프로듀서가 데이터 삭제를 요청 할수 없음
  • 오직 브로커만이 데이터 삭제 가능
  • 삭제는 파일 단위로 이루어짐 = 이 단위를 로그 세그먼트라고 부름

• 컨슈머 오프셋 저장

  • 컨슈머 그룹은 토픽이 특정 파티션으로부터 데이터를 가져가서 처리하고 이 파티션의 어느 레코드까지 가져갔는지 확인하기 위해 오프셋을 커밋함

• 코디네이터

  • 클러스터의 다수 브로커 중 한대가 코디네이터 역할 수행
  • 컨슈머 그룹의 상태를 체크하고 파티션을 컨슈머와 매칭되도록 분배하는 역할을 함
  • 파티션을 컨슈머로 재할당하는 과정을 리밸런스라고 함

주키퍼

• 카프카의 메타데이터를 관리하는데 사용
• 카프카 클러스터로 묶인 브로커들은 동일한 경로의 주키퍼 경로로 선언해야 같은 카프카 브로커 묶음이 됨
• 한개의 주키퍼에 다수의 카프카 클러스터를 연결해서 사용할 수 있음

토픽과 파티션

• 토픽

  • 카프카에서 데이터를 구분하기 위해 사용하는 단위
  • 토픽은 1개 이상의 피티션을 소유

• 파티션

  • 프로듀서가 보낸 데이터들이 들어가 저장되는데 이 데이터를 레코드라 부름
  • 카프카의 병렬처리의 핵심
  • 그룹으로 묶인 컨슈머들이 레코드를 병렬로 처리할 수있도록 매칭됨
  • 자료구조에서 접하는 큐와 비슷한 구조 FIFO
  • 다만 큐는 데이터를 가져가면 삭제되지만 카프카는 삭제되지 않는다.

레코드

• 타임스탬프, 메시지 키, 메시지 값, 오프셋, 헤더로 구성
• 메시지 카는 메시지 값을 순서대로 처리하거나 메시지 값의 종류를 나타내기 위해 사용
• 메시지 키를 사용하면 프로듀서가 토픽에 레코드를 전송할 때 메시지 키의 해시값을 토대로 파티션을 지정하게 됨
• 메시지 값에는 실질적으로 처리할 데이터가 들어있음
• 오프셋은 0이상의 숫자로 이루어져 있으면 직접 지정할 수 없다
• 헤더는 레코드의 추가적인 정보를 담는 메타데이터 저장소 용도로 사용
• 헤더는 키/값 형태로 데이터를 추가하여 레코드의 속성을 저장하여 컨슈머에 참조할 수 있다.

• 카프카 내부에 데이터가 저장되는 파티션의 동작은 FIFIO방식의 큐 자료와 유사함
• 큐에 데이터를 보내는 것이 프로듀서
• 큐에서 데이터를 가져가는 것이 컨슈머
• 데이터 포멧은 제한 없음 => 직렬화, 역직렬화를 통해 ByteArray로 통신하기 때문
• 카프카는 상용환경에서는 최소 3대 이상의 서버에서 부산 운영하여 프로듀서를 통해 전송받은 데이터를 파일 시스템에 안전하게 기록함.
• 서버 3대 이상으로 이루어진 카프카 클러스터 중 일부 서버에 장애가 발생하더라도 데이터를 지속적으로 복제하기 때문에 안전하게 운영이 가능
• 데이터를 묶음 단위로 처리하는 배치 전송을 통해 낮은 지연과 높은 데이터 처리량도 가지게 됨.

빅데이터 파이프라인에서 카프카의 역할

• 데이터 레이크 : 데이터가 모이는 저장 공간
• 높은 처리량
  • 카프카는 프로듀서가 브로커로 데이터를 보낼 때와 컨슈머가 브로커로부터 데이터를 받을 때 모두 묶어서 전송
  • 많은 양의 데이터를 묶음 단위로 처리하는 배치도 빠르게 처리할 수 있기 때문에 대용량의 실시간 로그데이터를 처리하는 데에 적합하다.
• 확장성
  • 가변적인 환경에서 안정적으로 확장 가능하도록 설계되었음
  • 스케일 아웃, 이케일 인
  • 무중단 운영
• 영속성
  • 데이터를 생성한 프로그램이 종료되더라도 사라지지 않은 데이터 특성을 뜻함
  • 전송받은 데이터를 메모리가 아닌 파일 시스템에 저장
  • I/O 성능 향상을 위해 페이지 캐시 영역을 메모리에 따로 생성하여 사용
  • 페이지 캐시 메모리 영역을 사용하여 한번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식이기에 철히량이 높다
• 고가용성
  • 3개 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버가 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터를 처리할 수 있음
  • 프로듀서로 부터 전송받은 데이터를 다른 서버에서 데이터를 복제함

왜 3대 이상의 브로커들로 구성해야하는가?

• 1대
  • 테스트 목적으로 사용
• 2대
  • 브로커 간에 데이터가 복제되는 시간차이로 인해 일부 데이터가 유실될 가능성이 있음.
• 3대
  • 3개 중 1개의 브로커가 장애가 나더라도 지속적으로 데이터를 처리 가능

데이터 레이크 아키텍처와 카프카의 미래

데이터레이크 아키텍처는 람다아키텍처와 카파 아키텍처가 있다

• 람다 아키텍처
  • 레거시 데이터 수집 플랫폼을 개선하기 위해 구성한 아키텍처
  • 3가지 레이어로 나뉨
    • 배치 레이어 : 배치 데이터를 모아서 특정 시간, 타이밍마다 일괄 처리
    • 서빙 레이어 : 가공된 데이터를 데이터 사용자, 서비스 애플리케이션에서 사용할 수 있도록 데이터가 저장된 공간
    • 스피드 레이어 : 서비스에서 생성되는 원천 데이터를 실시간으로 분석하는 용도로 사용
• 카파 아키텍처
  • 람다 아키텍처의 단점을 해소하기 위함
  • 람다 아키텍처와 유사하지만 배치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어서 처리함.
  • 로그는 배치 데이터를 스트림으로 표현하기 적합
  • 배치 데이터를 로그로 표현헐 때는 각 시점의 배치 데이터의 변환기록을 시간 순서대로 기록함으로써 각 시점의 모든 스냅샷 데이터를 저장하지 않고도 배치 데이터를 표현할 수 있게 됨

배치데이터와 스트림 데이터

• 배치데이터

  • 초, 분, 시간, 일 등으로 한정된 기간 단위 데이터
  • 데이터를 일괄 처리하는 것이 특징

• 스트림 데이터

  • 한정되지 않은 데이터로 시작 데이터와 끝 데이터가 명확히 정해지지 않은 데이터
  • 사용자의 클릭 로그, 주식 정보, 사물인터넷의 센서 데이터를 스트림 데이터라 볼 수 있음

• 데이터 레이크

  • 카파 아키텍처에서 서빙 레이어를 제거한 아키텍처

• 젠킨스의 주요 애플리케이션에 대한 UI 보조 기능
  • 향상된 시각화
  • 파이프라인 에디터
  • 개인화
  • 깃과 깃허브를 위한 쉽고 빠른 파이프라인 설정 마법사

설치

• Jenkins 관리 > 플러그인 관리 > 설치가능(Available) > Blue Ocean검색 후 설치
• 설치가 끝나면 대시보드에 블루오션이 생긴것을 볼 수 있다.

블루오션 살펴보기

1. 블루오션 대시보드
2. 멀티브랜치 파이프라인

블루오션에서 파이프라인 생성

• 블루오션 대시보드에서 새로운 파이프라인 버튼을 클릭하고 단계에 따라 진행하면 된다. 아래 이미지에서는 토큰 입력이 없지만 있다면 토큰 생성 링크 클릭 후 생성하면 된다. 위 이미지처럼 선택 후 파이프라인 생성 클릭하면 다음 이미지와 같다. 에이전트 부분을 다음과 같이 선택하고 입력한다. 다음으로 가운데 + 버튼을 클릭하면 Build Stage를 만들 수 있다. 스테이지 이름 입력칸에 Build라고 작성 후 스텝 추가 버튼 클릭 provide를 검색해서 Provide Maven environment 선택 Maven 영역에 M3 입력 후 나머지는 그대로 놔둔다. 스텝 추가 클릭 후 Shell Script 선택 후 mvn clean install 입력 그리고 뒤로가기 화살표를 클릭해 이전 메뉴로 돌아가자(아래 이미지는 Build 스탭 다 입력 시 아래와 같음) 다음 Build 다음의 + 버튼을 클릭하고 Results라고 입력한다 스텝 추가 후 Junit 검색 후 Archive JUnit-formatted test results 선택 하고 TestResults 칸에 **/target/surefire-reports/TEST-.xml 입력한다. 뒤로가기 클릭 후 스텝 추가 클릭 후 archive 검색 > Archive the artifacts선택 > Artifacts 영역에 target/.jar 작성 뒤로가기 클릭 후 우측 상단 저장버튼 클릭 Save & run 버튼 클릭하면 레포지토리에 Jenkinsfile이 생성된 것을 확인 할 수있다.

1. 깃허브 인증을 젠킨스에 추가

• Credentials > System > Global credentials
  1. Add Credentials 클릭
  2. Kind > Secret text 선택
  3. 위처럼 값 입력 후 OK 클릭
     
• 깃허브에서 시크릿 키 발급
  1. Setting > Developer settings > Personal access tokens
  2. 다음과 같이 체크박스 체크 후 발급받기

2. 젠킨스에 깃허브 Webhooks 설정

• Jenkins 관리 > 시스템 설정 > GitHub > Add GitHub Server Credentials 부분은 위에서 만든 Credentials를 선택하고 테스트 버튼 클릭
• 테스트가 성공하면 저장 버튼 클릭

3. 새로운 깃허브 저장소 만들기

• https://github.com/jglick/simple-maven-project-with-tests
• 위의 저장소를 Fork 할것임!!

4. Jenkinsfiles 이용하기

• 위 저장소에서 포크한 레포지토리에서 Jenkinsfiles를 다음과 같이 작성 후 커밋!

  node('master') {
  checkout scm
  stage('Build') {
    withMaven(maven: 'M3'){
      if(isUnix()){
        sh 'mvn -Dmaven.test.failure.ignore clean package'
      }
      else {
        bat 'mvn -Dmaven.test.failure.ignore clean package'
      }
    }
  }
  stage('Results') {
    junit '**/target/surefire-reports/TEST-*.xml'
    archive 'target/*.jar'
  }
  }

5. 젠킨스에서 멀티브랜치 파이프라인 생성하기

• 대시보드 > New Item > multibranch-pipeline 선택
• Branch Sources 탭 클릭 > Add Source 클릭 > Github을 선택하면 아래 이미지처럼 새로운 영역이 생김
• Credentials 는 만들어 둔것을 선택하고 (Secret text는 목록에서 안뜸. 이거를 해결해야할 듯.. 그래야 7번 테스트가 잘될듯함.) Repository는 아래 이미지처럼 입력 및 선택한다
• 저장 클릭!

6. Webhooks 재등록

1. Jenkins 관리 > 시스템 설정 > Github 영역에서 두번째 고급 버튼 클릭
2. Re-register hooks for all jobs 버튼 클릭
3. 해당 레포지토리 > Settings > Webhooks 탭 아래의 이미지처럼 웹훅스가 등록된 것을 볼 수 있다.

7. 멀티브랜치 파이프라인 테스트

• 레포지토리에서 feature라는 브랜치 생성하면 젠킨스 파이프라인은 즉시 실행함.

1. 노드 블록

• 스테이지 블록, 디렉티브, 스텝이 실행될 젠킨스 에이전트를 정의한다.

  node('<parameter>') {<constituents>}

  2. 스테이지 블록

• 스테이지 블록은 같은 목적을 가진 스텝과 디렉티브의 모음이다.

  stage('<parameter>') {<constituents>}

  3. 디렉티브

• 디렉티브의 가장 큰 목적은 환경 변수, 옵션, 파라미터, 트리거, 툴을 제공해 노드 블록과 스테이지 블록, 스텝을 지원하는 것이다.

4. 스텝

• 스텝은 서술적 파이프라인을 구성하는 가장 중요한 요소

• 젠킨스에서 무엇을 할지 명령을 내리는 것

  node('master') {
    // Directive 1
    def mvnHome
  
    // Stage block 1
    stage('Preparation') { 
        // Step 1
        git 'https://github.com/jglick/simple-maven-project-with-tests.git'
        // Directive 2
        mvnHome = tool 'M3'
    }
  
    // Staage block 2
    stage('Build') {
        // Step 2
        withEnv(["MVN_HOME=$mvnHome"]) {
            if (isUnix()) {
                sh '"$MVN_HOME/bin/mvn" -Dmaven.test.failure.ignore clean package'
            } else {
                bat(/"%MVN_HOME%\bin\mvn" -Dmaven.test.failure.ignore clean package/)
            }
        }
    }
  
    // Stage block 3
    stage('Results') {
        // Step 3
        junit '**/target/surefire-reports/TEST-*.xml'
        // Step 4
        archiveArtifacts 'target/*.jar'
    }
  }

• any를 파라미터로 사용하면 모든 스테이지 노드와 스텝, 디렉티브는 임의의 젠킨스 슬레이브 중 하나에서 수행된다.

1. apt가 저장소를 사용할 수 있게 함

   sudo apt-get install apt-transport-https ca-certificates

2. 도커 공식 GPG 키 등록

   curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

   

3. 공식 저장소 추가

   sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable"

4. apt 업데이트

   sudo apt update

5. 도커 설치

   sudo apt-get install docker-ce

6. 도커 확인

   sudo docker info

   

7. 젠킨스 설치 및 실행

   docker run -d --name jenkins_dev -p 8080:8080  jenkins/jenkins:lts

8. 젠킨스 컨테이너 접속

   docker exec -it jenkins_dev bash

• [IP ADDRESS]:8080 접속 시 초기 패스워드 위치를 가르쳐줌

9. 젠킨스 초기 비밀번호

   cat /var/jenkins_home/secrets/initialAdminPassword

   

데이터 볼륨을 이용한 젠킨스 컨테이너 실행

• 컨테이너를 삭제하게 되면 jenkins_home 폴더도 같이 삭제가 된다.
• 데이터 볼륨을 이용해 젠킨스를 도커 위에서 수행하는데 더 좋은 방식이 있음.
• 데이터 볼륨이란? 데이터가 컨테이너의 라이프 사이클에 상관없이 영구적으로 저장하는 특정 폴더이다.

1. 젠킨스 컨테이너 실행

   docker run -d --name jenkins_prod -p 8080:8080 -p 50000:50000 -v jenkins-home-prod:/var/jenkins_home jenkins/jenkins:lts

• -v jenkins-home-prod:/var/jenkins_home 옵션은 jenkins-home-prod라는 이름으로 데이터 볼륨을 만들어 /var/jenkins_home 폴더에 연결한다.

2. jenkins_prod 컨테이너 내의 /var/jenkins_home 폴더의 내용을 보기 위해 다음 명령어를 실행

   docker exec -it jenkins_prod ls -lrt /var/jenkins_home

   

3. 도커 볼륨 목록 확인

   docker volume ls

   

4. 이제 영구적인 jenkins_home 폴더를 가진 젠킨스 도커 컨테이너가 생성됬음.

5. 도커 젠킨스에 접속 후 최소 비밀번호를 가져온다

   docker exec -it jenkins_prod bash
   cat /var/jenkins_home/secrets/initialAdminPassword

   

6. 초기 접속시 화면

• 위에서 확인한 비밀번호 입력 후 Continue 클릭

7. 다음 페이지로 Custimize Jenkins 화면이 나옴(Install suggested plugins 클릭)
8. 위 과정에서 설치가 끝나면 어드민 계정을 만들라는 페이지가 나옴
9. 다음 페이지로 그냥 Save And Finish 버튼 클릭
10. 환경 설정 끝!!
11. /var/jenkins_home/users 폴더내에 모든 사용자 정보가 있음
12. 이제 jenkins_prod 컨테이너를 삭제해보자

    docker kill jenkins_prod
    docker rm jenkins_prod

13. 도커 목록확인

    docker ps -a

    

• 컨테이너가 존재하지 않는 것을 볼 수 있음.

14. 볼륨 확인

• 컨테이너는 삭제됬지만 볼륨은 남아있다.

15. jenkins-home-prod 볼륨을 사용하는 새로운 젠킨스 컨테이너를 생성하자

    docker run -d --name jenkins_prod -p 8080:8080 -p 50000:50000 -v jenkins-home-prod:/var/jenkins_home jenkins/jenkins:lts

16. 다시 해당 페이지로 접속을 해보면 세팅페이지가 아닌 로그인페이지로 이동을 한다.

이미지 검색

docker search [IMAGE NAME]

이미지 다운로드

docker pull [IMAGE NAME]:[TAG]

이미지 확인

docker images

이미지 삭제

docker rmi [IMAGE NAME] -f(사용 중인 이미지 일 경우 -f를 붙이면 지워짐)

이미지 정보 확인

docker inspect [IMAGE NAME]

이미지 저장소 위치 확인

docker info

도커 용량 확인

du -sh /var/lib/docker/ #도커가 설치된 환경 용량 확인
명령어 실행 결과 : 2.0G /var/lib/docker/

du -sh /var/lib/docker/image/ # 도커 이미지에 대한 정보 저장 디렉토리
명령어 실행 결과 : 2.7M /var/lib/docker/image/

du -sh /var/lib/docker/overlay2/ # 도커 이미지의 파일 시스템이 사용되는 실제 디렉토리
명령어 실행 결과 : 2.0G /var/lib/docker/overlay2/

du -sh /var/lib/docker/containers/ # 도커 컨테이너 정보 저장 디렉토리
명령어 실행 결과 : 136K /var/lib/docker/containers/

• image 안에는 imageDB와 LayerDB가 있는데

imageDB는 LayerDB에 대한 정보를 가지고 있고 LayerDB는 overlay2라는 정보를 가지고 있음 overlay2라는 변경사항 내용은 /l에 저장되어 있음.

컨테이너 관련

다운로드한 컨테이너 생성

docker create -p 80:80 --name [CONTAINER NAME][IMAGE]

컨테이너 생성 및 실행

docker run [options] image[:TAG|@DIGEST] [COMMAND] [ARG...]

• 옵션

컨테이너 시작

docker start [컨테이너 id 또는 name]

컨테이너 재시작

docker restart [컨테이너 id 또는 name]

컨테이너 접속

docker attach [컨테이너 id 또는 name]

컨테이너 정지

docker stop [컨테이너 id 또는 name]

컨테이너 삭제

docker rm [컨테이너 id 또는 name]

실행중인 컨테이너 확인

docker ps (-a를 주면 모든 컨테이너 확인)

유용하게 쓰이는 명령어(image : tomcat)

포트포워딩으로 실행

docker run -d --name tc -p 80:8080 tomcat

컨테이너 내부 셸 실행

docker exec -it [container name] /bin/bash

컨테이너 로그 확인

docker logs tc

호스트 및 컨테이너 간 파일 복사

docker cp <path> <to container>:<path>
docker cp test.txt tc:/

docker cp <from container>:<path> <path>
docker cp tc:/test.txt ./test.txt

docker cp <from container>:<path> <to container>:<path>

도커 컨테이너 모두 삭제

docker stop `docker ps -a -q`
docker rm `docker ps -a -q`

임시 컨테이너 생성

docker run -d -p 80:8080 —rm --name tc tomcat

빌드

1. 이미지 내려받기

   docker pull ubuntu

2. 도커 파일 생성

   mkdir test
   cd test
   vi dockerfile

• 아래 코드 작성

  FROM ubuntu:latest [이미지 명]
  

RUN apt-get update [명령어 실행, 이미지를 만들 때 실행] RUN apt-get install -y net-tools [명령어 실행] RUN apt-get install -y nano [명령어 실행]

CMD ["echo", "image created”] [명령을 실행, 컨테이너가 실행 될 때 실행]

3. 빌드 하기

docker build -t my-ubuntu .

4. 이미지 확인

docker images

5. 실행

docker run -it my-ubuntu bash

## 도커 이미지 푸시

docker login docker tag my-ubuntu [docker id]/my-ubuntu[:tag] ex) :v2.0 (대괄호는 뺴고 작성) docker images docker push [docker id]/my-ubuntu

## 이미지 히스토리 확인

docker history [docker id]/my-ubuntu

• Metrics를 수집하고 모니터링 및 알람에 사용되는 오픈소스 애플리케이션
• Pull 방식의 구조와 다양한 Metrics Exporter 제공
• 시계열 DB에 Metrics 저장 -> 조회 가능(쿼리)

간단히 사용해보기

1. 설치 아래링크에서 os에 맞게 설치

   • https://prometheus.io/download/

2. 압축 풀기

   • tar xvzf prometheus-2.31.0-rc.0.darwin-amd64.tar.gz

3. prometheus.yml 수정 (scrape_configs 아래에 다음 내용 추가)

   scrape_configs:
   # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
   ...
   
   - job_name: "user-service"
    scrape_interval: 15s
    metrics_path: "/user-service/actuator/prometheus"
    static_configs:
      - targets: ["localhost:8000"]
   
   - job_name: "apigateway-service"
    scrape_interval: 15s
    metrics_path: "/actuator/prometheus"
    static_configs:
      - targets: ["localhost:8000"]
   
   - job_name: "order-service"
    scrape_interval: 15s
    metrics_path: "/order-service/actuator/prometheus"
    static_configs:
      - targets: ["localhost:8000"]

4. 실행 (포트 9090)

   • ./prometheus --config.file=prometheus.yml 실행 시 대시보드에서 http_server_requests_seconds_count를 검색

Grafana

• 데이터 시각화, 모니터링 및 분석을 위한 오프소스 애플리케이션
• 시계열 데이터를 시각화하기 위한 대시보드 제공

간단히 사용해보기

1. 설치 https://grafana.com/grafana/download?edition=oss&pg=get&plcmt=selfmanaged-box1-cta1&platform=mac
2. 실행 (포트 3000, 계정/비밀번호 : admin/admin) ./bin/grafana-server
3. 접속 후 Configuration에서 Prometheus 추가
4. Create -> import 로 DashBoard생성 https://grafana.com/grafana/dashboards/?orderBy=downloads&direction=desc
5. 위의 링크에서 맞는 대시보드를 찾아서 id값을 임포트한다
6. 기본설정과 다른 값들을 다 맞게 바꿔준다 ex) gateway_requests_seconds_count -> spring_cloud_gateway_requests_seconds_count or 서비스명 변경하면 됨

• 마이크로 서비스에 설치된 Hystrix 클라이언트의 스트림을 통합
  • 마이크로 서비스에서 생성되는 Hystrix 클라이언트 스트림메시지를 터빈 서버로 수집

Hystrix Dashboard

• Hystrix 클라이언트에서 생성하는 스트림을 시각화 (Web Dashboard)
• Hystrix Dashboard / Turbine -> Micrometer + Monitoring System

Micrometer

• https://micrometer.io/
• JVM 기반의 애플리케이션의 Metrics 제공
• Prometheus등의 다양한 모니터링 시스템 지원

Timer

• 짧은 지연시간, 이벤트의 사용 빈도를 측정
• 시계열로 이벤트의 시간, 호출 빈도 등을 제공
• @Timed 제공

사용해보기

• pom.xml

        <dependency>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-registry-prometheus</artifactId>
        </dependency>

• application.yml (info, metrics, prometheus 추가)

  management:
  endpoints:
    web:
      exposure:
        include: refresh, health, beans, busrefresh, info, metrics, prometheus

• controller (@Timed 추가)

  @GetMapping("/health_check")
  @Timed(value = "users.status", longTask = true)
  public String status(){
    return String.format("It's Working in User Service"
      + ", port(local.server.port)=" + env.getProperty("local.server.port")
      + ", port(server.port)=" + env.getProperty("server.port")
      + ", token secret=" + env.getProperty("token.secret")
      + ", token expiration time=" + env.getProperty("token.expiration_time")
    );
  }
  @GetMapping("/welcome")
  @Timed(value = "users.welcome", longTask = true)
  public String welcome(){
  //    return env.getProperty("greeting.message");
    return greeting.getMessage();
  }

Spring Cloud Sleuth

• 스프링 부트 애플리케이션을 Zipkin과 연동
• 요청 값에 따른 TraceID, SpanId 부여
• Trace와 Span Ids를 로그에 추가 가능
  • servlet filter
  • rest templete
  • scheduled actions
  • message channels
  • feign client

설치

• https://zipkin.io/pages/quickstart.html

  curl -sSL https://zipkin.io/quickstart.sh | bash -s
  java -jar zipkin.jar

• http://127.0.0.1:9411/

사용해보기

user-service

• pom.xml

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>

• application.yml

  spring:
  zipkin:
    base-url: http://127.0.0.1:9411
    enabled: true
  sleuth:
    sampler:
      probability: 1.0
  

Resilience4j

• resilience4j-circuitbreaker: Circuit breaking
• resilience4j-ratelimiter: Rate limiting
• resilience4j-bulkhead: Bulkheading
• resilience4j-retry: Automatic retrying (sync and async)
• resilience4j-timelimiter: Timeout handling
• resilience4j-cache: Result caching

간단히 사용해보기

• pom.xml

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-circuitbreaker-resilience4j</artifactId>
        </dependency>

• user-service getUserByUserId() 함수 order-service 호출하는 부분

  
  private final CircuitBreakerFactory circuitBreakerFactory;
  
  ...
  public UserDto getUserByUserId() {
  ...
  

// 주석 // List orderList = orderServiceClient.getOrders(userId);

CircuitBreaker circuitBreaker = circuitBreakerFactory.create("circuitbreaker"); List orderList = circuitBreaker.run(() -> orderServiceClient.getOrders(userId), throwable -> new ArrayList<>());

... }

## Custom 해보기

package com.example.userservice.config;

import io.github.resilience4j.circuitbreaker.CircuitBreakerConfig; import io.github.resilience4j.timelimiter.TimeLimiterConfig; import org.springframework.cloud.circuitbreaker.resilience4j.Resilience4JCircuitBreakerFactory; import org.springframework.cloud.circuitbreaker.resilience4j.Resilience4JConfigBuilder; import org.springframework.cloud.client.circuitbreaker.Customizer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration;

import java.time.Duration;

@Configuration public class Resilience4jConfig { @Bean public Customizer globalCustomConfiguration() { CircuitBreakerConfig circuitBreakerConfig = CircuitBreakerConfig.custom() .failureRateThreshold(4) .waitDurationInOpenState(Duration.ofMillis(1000)) .slidingWindowType(CircuitBreakerConfig.SlidingWindowType.COUNT_BASED) .slidingWindowSize(2) .build();

TimeLimiterConfig timeLimiterConfig = TimeLimiterConfig.custom()
  .timeoutDuration(Duration.ofSeconds(4))
  .build();

return factory -> factory.configureDefault(id -> new Resilience4JConfigBuilder(id)
  .timeLimiterConfig(timeLimiterConfig)
  .circuitBreakerConfig(circuitBreakerConfig)
  .build()
);

} }

```

• pom.xml

        <dependency>
            <groupId>org.springframework.kafka</groupId>
            <artifactId>spring-kafka</artifactId>
        </dependency>

• KafkaConsumerConfig

  @EnableKafka
  @Configuration
  public class KafkaConsumerConfig {
  
  // 접속 정보
  @Bean
  public ConsumerFactory<String, String> consumerFactory(){
    Map<String, Object> properties = new HashMap<>();
  
    properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "127.0.0.1:9092");
    properties.put(ConsumerConfig.GROUP_ID_CONFIG, "consumerGroupId");
    /*
      그룹 아이디는 카프카에서 토픽에 쌓여있는 메세지를 가져가는 Consumer 들을 그룹핑할 수 있음.
      나중에 여러개의 Consumer가 데이터를 가져갈 때 특정한 Consumer 그룹을 만들어 놓고 전달하고자 하는 그룹을 지정할 수 있음.
     */
    properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
    properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
  
  

return new DefaultKafkaConsumerFactory<>(properties);

}

@Bean public ConcurrentKafkaListenerContainerFactory<String, String> kafkaListenerContainerFactory(){ ConcurrentKafkaListenerContainerFactory<String, String> kafkaListenerContainerFactory = new ConcurrentKafkaListenerContainerFactory<>();

kafkaListenerContainerFactory.setConsumerFactory(consumerFactory());

return kafkaListenerContainerFactory;

}

}

- KafkaConsumer
```java
// 리스너를 이용해서 데이터를 가져오고 그 데이터를 데이터베이스에 업데이트 할려 함
@Slf4j
@Service
@RequiredArgsConstructor
public class KafkaConsumer {
  private final CatalogRepository catalogRepository;

  @KafkaListener(topics = "example-catalog-topic")
  public void updateQty(String kafkaMessage) {
    log.info("Kafka Message : -> {}", kafkaMessage);

    Map<Object, Object> map = new HashMap<>();
    ObjectMapper mapper = new ObjectMapper();

    try {
      map = mapper.readValue(kafkaMessage, new TypeReference<Map<Object, Object>>() {});
    }catch (JsonProcessingException e){
      e.printStackTrace();;
    }
    CatalogEntity entity = catalogRepository.findByProductId((String)map.get("productId"));

    if(entity != null){
      entity.setStock(entity.getStock() - (Integer) map.get("qty"));
      catalogRepository.save(entity);
    }
  }
}

Order-Service(Producer)

• pom.xml 동일

• KafkaProducerConfig

  @EnableKafka
  @Configuration
  public class KafkaProducerConfig {
  
  // 접속 정보
  @Bean
  public ProducerFactory<String, String> producerFactory(){
    Map<String, Object> properties = new HashMap<>();
  
    properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "127.0.0.1:9092");
    properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
    properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
  
    return new DefaultKafkaProducerFactory<>(properties);
  }
  
  @Bean
  public KafkaTemplate<String, String> kafkaTemplate(){
    return new KafkaTemplate<>(producerFactory());
  }
  

}

- KafkaProducer
```java
@Slf4j
@Service
@RequiredArgsConstructor
public class KafkaProducer {
  private final KafkaTemplate<String, String> kafkaTemplate;

  public OrderDto send(String topic, OrderDto orderDto) {
    ObjectMapper mapper = new ObjectMapper();
    String jsonInString = "";

    try {
      jsonInString = mapper.writeValueAsString(orderDto);
    } catch (JsonProcessingException e) {
      e.printStackTrace();
    }

    kafkaTemplate.send(topic, jsonInString);
    log.info("Kafka Producer sent data from Order Micro Service : {}", orderDto);

    return orderDto;
  }
}

Order-Service 가 두 개 이상일 경우

• 각각의 오더 서비스가 한번씩 실행(라운드 로빈)을 한다. -> 데이터가 동기화 되지 않는다
• Order Service에 요청된 주문 정보를 DB가 아니라 Kafka의 Topic으로 전송하고, Topic에 설정된 Kafka Sink Connect를 사용해 단일 DB에 저장

• Field

  @Data
  @AllArgsConstructor
  public class Field {
  private String type;
  private boolean optional;
  private String field;
  }

• Schema

  @Data
  @Builder
  public class Schema {
  private String type;
  private List<Field> fields;
  private boolean optional;
  private String name;
  }

• Payload

  @Data
  @Builder
  public class Payload {
  private String order_id;
  private String user_id;
  private String product_id;
  private int qty;
  private int unit_price;
  private int total_price;
  }

• KafkaOrderDto

  @Data
  @AllArgsConstructor
  public class KafkaOrderDto implements Serializable {
  private Schema schema;
  private Payload payload;
  }
  

- OrderProducer
```java

@Slf4j
@Service
@RequiredArgsConstructor
public class OrderProducer {
  private final KafkaTemplate<String, String> kafkaTemplate;

  List<Field> fields = Arrays .asList(
    new Field("string", true, "order_id"),
    new Field("string", true, "user_id"),
    new Field("string", true, "product_id"),
    new Field("int32", true, "qty"),
    new Field("int32", true, "unit_price"),
    new Field("int32", true, "total_price")
  );
  Schema schema = Schema.builder()
                        .type("struct")
                        .fields(fields)
                        .optional(false)
                        .name("orders")
                        .build();

  public OrderDto send(String topic, OrderDto orderDto) {
    Payload payload = Payload.builder()
                              .order_id(orderDto.getOrderId())
                              .user_id(orderDto.getUserId())
                              .product_id(orderDto.getProductId())
                              .qty(orderDto.getQty())
                              .unit_price(orderDto.getUnitPrice())
                              .total_price(orderDto.getTotalPrice())
                              .build();

    KafkaOrderDto kafkaOrderDto = new KafkaOrderDto(schema, payload);

    ObjectMapper mapper = new ObjectMapper();
    String jsonInString = "";

    try {
      jsonInString = mapper.writeValueAsString(kafkaOrderDto);
    } catch (JsonProcessingException e) {
      e.printStackTrace();
    }

    kafkaTemplate.send(topic, jsonInString);
    log.info("Order Producer sent data from Order Micro Service : {}", kafkaOrderDto);

    return orderDto;
  }
}

결론

• Order-Service 하고 Catalog-Service는 각각의 데이터를 사용하면서 수량 부분에 대해서 동기화시켜 주는 부분을 Kafka Topic을 사용
• Order-Service가 두개 이상일 때 디비가 서로 달라서 데이터가 동기화 되지 않는다. 그래서 주문이 들어오면 카프카로 메세지를 보내고 카프카에 저장된(토픽에 저장되어 있는) 값을 단일 데이터베이스로 읽어 오기 위해서싱크 커낵트를 연결 해서 데이터를 동기화 했음
• 응용해서 확장하고 싶으면
  • 데이터베이스에 저장되는 메시지 큐잉 서버를 이벤트 소싱이라고 해서 데이터가 전달되는 부분을 저장하는 파트와 저장된 데이터를 읽어오는 파트를 두개로 분리해서 만드는 cqrs라는 패턴을 이용하면 좀더 효율적으로 메시지징 기반의 시스템을 이용하고 시간 순서에 의해 메시지가 기록된 것을 데이터베이스에 업데이트구현할 수 있음

기본 메커니즘

select /* ordered use_hash(c) */
    e.사원번호, e.사원명, e.입사일자
    c.고객번호 , c.고객명, c.전화번호, c.최종주문금액
from 사원 e, 고객 c
where c.관리사원번호 = e.사원번호
and e.입사일자 >= '19960101'
and e.부서코드 = 'Z123'
and c.최종주문금액 >= 20000

1. Build 단계

   • 작은 쪽 테이블을 읽어 해시 테이블을 생성한다.

     아래 조건에 해당하는 사원 데이터를 읽어 해시 테이블을 생성한다. 사원번호를 해시 함수에 입력해서 반환된 값으로 해시 체인을 찾고, 그 해시 체인에 데이터를 연결한다. 해시 테이블은 PGA 영역에 할당된 Hash Area에 저장한다.

     select e.사원번호, e.사원명, e.입사일자
     from 사원 e
     where e.입사일자 >= '19960101'
     and e.부서코드 = 'Z123'

2. Probe 단계

   • 큰 쪽 테이블을 읽어 해시 테이블을 탐색하면서 조인한다.

     • 아래 조건에 해당하는 고객 데이터를 하나씩 읽어 앞서 생성한 해시 테이블을 탐색한다.
     • 즉, 관리사원번호를 해시 함수에 입력해서 반환된 값으로 해시 체인을 찾고, 그 해시 체인을 스캔해서 값이 같은 사원번호를 찾는다.

       select c.고객번호 , c.고객명, c.전화번호, c.최종주문금액, c.관리사원번호
       from 고객 c
       where c.최종주문금액 >= 20000

     • Build 단계에서 사용한 해시 함수를 Probe 단계에서도 사용하므로 같은 사원번호를 입력하면 같은 해시 값을 반환한다.
     • NL 조인과 다르지 않다.

• use_hash 힌트 사용

해시 조인이 빠른 이유

• Hash Area에 생성한 해시 테이블을 이용한다는 점만 다를 뿐 해시 조인도 조인 프로세싱 자체는 NL 조인과 같다.
• NL 조인보다 빠른 이유
  • 해시 테이블을 PGA 영역에 할당하기 때문이다.
  • 래치 획득 과정 없이 PGA에서 빠르게 데이터를 탐색하고 조인한다.
• 해시 조인과 소트 머지 조인의 성능 차이는 조인 오퍼레이션을 시작하기 전, 사전 준비 작업에 기인한다.
  • 소트 머지 조인에서 사전 준비작업은 '양쪽' 집합을 모두 정렬해서 PGA에 담는 작업
  • 해시 조인에서 사전 준비작업은 양쪽 집합 중 어느 '한쪽'을 읽어 해시 맵을 만드는 작업
• 해시 조인은 NL조인처럼 조인 과정에서 발생하는 랜덤 액세스 부하가 없고, 소트 머지 조인처럼 양쪽 집합을 미리 정렬하는 부하도 없다.

대용량 Buil Input 처리

• 분할 정복 방식

1. 파티션 단계
   • 조인하는 양쪽 집합(조인 이외 조건절을 만족하는 레코드)의 조인 컬럼에 해시 함수를 적용하고, 반환된 해시 값에 따라 동적으로 파티셔닝한다.
   • 독립적으로 처리할 수 있는 여러 개의 작은 서브 집합으로 분할함으로써 파티션 짝을 생성하는 단계다.
2. 조인 단계
   • 파티션 단계를 완료하면 각 파티션 짝에 대해 하나씩 조인을 수행한다.
   • 각각에 대한 Build Input과 Probe Input은 독립적으로 결정된다.
   • 각 파티션 짝별로 작은 쪽을 Build Input으로 선택하고 해시 테이블을 생성한다.
   • 해시 테이블을 생성하고 나면 반대쪽 파티션 로우를 하나씩 읽으면서 해시 테이블을 탐색한다.
   • 모든 파티션 짝에 대한 처리를 마칠 때까지 이 과정을 반복한다.

해시 조인 실행꼐획 제어

• 해시 조인 실행계획을 제어할 때 use_hash 를 사용
• use_hash 만 사용할 경우 옵티마이저가 Build Input을 선택하는데, 일반적으로 둘 중 카디널리티가 작은 테이블을 선택한다.
• 조인 대상 테이블이 두 개라면 leading이나 ordered 힌트를 사용하여 Build Input을 직접 선택할 수 있다.
• swap_join_inputs 힌트로 Build Input을 명시적으로 선택할 수도 있다.

  세 개 이상 테이블 해시 조인

• 조인하는 테이블이 몇 개든, 조인 연결고리를 따라 순방향 또는 역방향으로 leading 힌트에 기술한 후, Build Input으로 선택하고 싶은 테이블을 swap_join_inputs 힌트에 지정해 주면 된다.
• Build Input으로 선택하고 싶은 테이블이 조인된 결과 집합이어서 swap_join_inputs 힌트로 지정하기 어렵다면, no_swap_join_inputs 힌트로 반대쪽 Probe Input을 선택해 주면 된다.

조인 메소드 선택 기준

• 일반적인 조인 메소드 선택 기준

  소량 데이터 조인할 때 : NL 조인 대량 데이터 조인할 때 : 해시 조인 대량 데이터 조인인데 해시 조인으로 처리할 수 없을 때, 즉 조인 조건식이 등치 조건이 아닐 때 : 소트 머지 조인

• 수행빈도가 매우 높은 쿼리에 대한 기준

  (최적화된) NL 조인과 해시 조인 성능이 같으면: NL 조인 해시 조인이 약간 더 빨라도: NL 조인 NL 조인보다 해시 조인이 매우 빠른 경우: 해시 조인

• 왜 NL 조인을 선택해야 할까?

  NL 조인에 사용하는 인덱스는 영구적으로 유지하면서 다양한 쿼리를 위해 공유 및 재사용하는 자료구조다. 반면, 해시 테이블은 단 하나의 쿼리를 위해 생성하고 조인이 끝나면 곧바로 소멸하는 자료구조다. 따라서 수행시간이 짧으면서 수행빈도가 매우 높은 쿼리를 해시 조인으로 처리하면 CPU와 메모리 사용률이 크게 중가한다. 해시 맵을 만드는 과정에 여러 가지 래치 경합도 발생한다.

• 해시 조인은 아래 세가지 조건을 만족하는 SQL문에 주로 사용

  1. 수행 빈도가 낮고
  2. 쿼리 수행시간이 오래 걸리는
  3. 대량 데이터 조인할 때

• 하나의 SQL문 안에 괄호로 묶은 별도의 쿼리 블록을 말한다.

1. 인라인 뷰

   • From 절에 사용한 서브쿼리

2. 중첩된 서브쿼리

   • WHERE 절에 사용한 서브쿼리
   • 서브쿼리가 메인쿼리 컬럼을 참조하는 형태를 '상관관계 있는 서브쿼리'라 함

3. 스칼라 서브쿼리

   • 한 레코드당 정확히 하나의 값을 반환하는 서브쿼리
   • SELECT-LIST에서 사용하지만 몇 가지 예외사항을 제외하면 컬럼이 올 수 있는 대부분 위치에서 사용할 수 있다.

서브쿼리 변환이 필요한 이유

• 옵티마이저는 사용자로부터 전달받은 SQL을 최적화에 유리한 형태로 변환하는 작업, 즉 쿼리 변환부터 진행한다.
• 쿼리 변환 : 옵티마이저가 SQL을 분석해 의미적으로 동일하면서도 더 나은 성능이 기대되는 형태로 재작성하는 것을 말함.
• 서브쿼리를 참조하는 메인쿼리도 하나의 쿼리 블록이며, 옵티마이저는 쿼리 블록 단위로 최적화를 수행한다.
• SQL을 최적화할 때도 옵티마이저가 나무가 아닌 숲 전체를 바라보는 관점에서 쿼리를 이해하려면 먼저 서브쿼리를 풀어내야만 한다!

서브쿼리와 조인

메인쿼리와 서브쿼리 간에는 부모와 자식이라는 종속적이고 계층적인 관계가 존재한다. 서브쿼리는 메인쿼리에 종속되므로 단독으로 실행할 수 없다.

• 필터 오퍼레이션

  • no_unnest : 서브쿼리를 풀어내지 말고 그대로 수행하라고 옵티마이저에 지시하는 힌트
  • 기본적으로 NL 조인과 처리 루틴이 같다.(NL 조인처럼 부분 범위 처리도 가능)
  • 차이점
    1. 필터는 메인쿼리의 한 로우가 서브쿼리의 한 로우와 조인에 성공하는 순간 진행을 멈추고, 메인쿼리의 다음 로우를 계속 처리한다는 점
    2. 필터는 캐싱기능을 갖는다는 점
       • 서브쿼리 입력 값에 따른 반환 값(true or false)을 캐싱하는 기능
       • 이 기능이 작동하므로 서브쿼리를 수행하기 전에 항상 캐시부터 확인한다.
    3. 필터 서브쿼리는 일반 NL 조인과 달리 메인쿼리에 종속되므로 조인 순서가 고정된다.(항상 메인쿼리가 드라이빙 집합)

• 서브쿼리 Unnesting (= 서브쿼리 Flattening)

  • unnest 힌트 사용
  • 메인과 서브쿼리 간 계층 구조를 풀어 서로 같은 레벨로 만들어 준다.
  • 서브쿼리를 그대로 두면 필터 방식을 사용
  • Unnesting 하고 나면 일반 조인문처럼 다양한 최적화 기법을 사용할 수 있다.
  • NL 세미 조인
    • unnest, nl_sj 힌트 사용
    • NL 조인과 같은 프로세스
    • 조인에 성공하는 순간 진행을 멈추고 메인 쿼리의 다음 로우를 계속 처리한다는 점만 다르다.
  • Unnesting된 서브쿼리는 NL 세미조인 외에도 다양한 방식으로 실행될 수 있다.
  • 필터방식은 항상 메인쿼리가 드라이빙 집합이지만,
  • Unnesting된 서브쿼리는 메인 쿼리 집합보다 먼저 처리될 수 있다.

ROWNUM - 잘 쓰면 약, 잘못 쓰면 독

• 서브쿼리에 rownum을 쓰면 옵티마이저에게 "이 서브쿼리 블록은 손대지 말라"고 선언하는 것과 다름없다.
• 서브쿼리 Unnesting을 방지하려는 목적이 아니면 서브쿼리에 함부로 쓰지 말자.

• 서브쿼리 Pushing

  • 서브쿼리 필터링을 가능한 한 앞 단계에서 처리하도록 강제하는 기능
  • push_subq, no_push_subq 힌트로 제어
  • 이 기능은 Unnesting 되지 않은 서브쿼리에만 작동
  • 따라서 push_subq 힌트는 항상 no_unnest 힌트와 같이 기술해야 한다.

뷰와 조인

• 최적화 단위가 쿼리 블록이므로 옵티마이저가 뷰 쿼리를 변환하지 않으면 뷰 쿼리 블록을 독립적으로 최적화한다.
• merge 힌트를 이용해 뷰를 메인 쿼리와 머징하도록 함.
• 부분처리가 불가능한 상황에서 NL 조인은 좋은 선택이 아니다. (이런 상황에선 보통 해시 조인이 빠름)

조인 조건 Pushdown

• 메인쿼리를 실행하면서 조인 조건절 값을 건건이 뷰 안으로 밀어 넣는 기능이다.
• 'VIEW PUSHED PREDICATE'오퍼레이션을 통해 이 기능의 작동 여부를 알 수 있음.
• 이 방식을 사용하면 '건건이' 데이터만 읽어서 조인하고 Group By를 수행할 수 있다.
• 부분범위 처리가 가능하다.
• push_pred 힌트를 사용
• 옵티마이저가 머징하면 힌트가 작동하지 않으니 no_merge 힌트와 함께 사용하는 습관이 필요

스칼라 서브쿼리 조인

스칼라 서브쿼리의 특징

• Outer 조인문처럼 NL 조인 방식으로 실행된다.
• 처리과정에서 캐싱 작용이 일어난다.

  스칼라 서브쿼리 캐싱 효과

• 필터 서브쿼리 캐싱과 같은 기능이다.(조인 성능을 높이는 데 큰 도움)
• 캐싱은 쿼리 단위로 이루어진다.

  쿼리를 시작할 때 PGA 메모리에 공간을 할당하고, 쿼리를 수행하면서 공간을 채워나가며, 쿼리를 마치는 순간 공간을 반환한다.

• 많이 활용되는 튜닝 기법
  • SELECT-LIST에 사용한 함수는 메인쿼리 결과 건수만큼 반복 수행되는데, 스칼라 서브쿼리를 덧씌워서 호출 횟수를 최소화할 수 있다.

스칼라 서브쿼리 캐싱 부작용

• 스칼라 서브쿼리 캐싱 효과는 입력 값의 종류가 소수여서 해시 충돌 가능성이 작을 때 효과가 있다.
• 반대의 경우라면 캐시를 매번 확인하는 비용 때문에 오히려 성능이 나빠지고 CPU 사용률만 높게 만들며 메모리도 더 사용한다.

두 개 이상의 값 반환

• 인라인 뷰 사용
  • 뷰를 사용하면, 전체를 읽어야 하거나, 뷰가 머징될 때 Group By 때문에 부분범위 처리가 안 되는 문제가 있다.

스칼라 서브쿼리 Unnesting

• 스칼라 서브쿼리도 NL 방식으로 조인하므로 캐싱 효과가 크지 않으면 랜덤 I/O 부담이 있다.
• 그래서 다른 조인 방식을 선택하기 위해 스칼라 서브쿼리를 일반 조인문으로 변환하고 싶을 때가 있다.
• 특히, 병렬 쿼리에선 될 수 있으면 스칼라 서브쿼리를 사용하지 않아야 한다.
  • 대량 데이터를 처리하는 병렬 쿼리는 해시 조인으로 처리해야 효과적이기 때문
• _optimizer_unnest_scalar_sq 파라미터
  • true로 설정
    • 스칼라 서브쿼리를 Unnesting 할지 여부를 옵티마이저가 결정
  • false로 설정
    • 옵티마이저가 이 기능을 사용하지 않지만, 사용자가 unnest 힌트로 유도할 수 있다.

필자는 패키지 센터에 있는 깃랩을 설치였다.

Https 설정

우선 실행 중인 깃랩을 멈추고 다음과 같이 환경 변수를 세팅한다.

SSL_KEY_PATH=/home/git/data/certs/gitlab.key
SSL_DHPARAM_PATH=/home/git/data/certs/dhparam.pem
SSL_CERTIFICATES_PATH=/home/git/data/certs/gitlab.crt
SSL_SELF_SIGNED=false
GITLAB_HTTPS=true
GITLAB_HOST=domain.com
GITLAB_PORT=(your container port)

다음으로 포트 설정을 80 -> 443으로 변경

ssh 접속으로 시놀로지에 접속한다. (관리자로)

cd /usr/syno/etc/certificate/_archive/

위의 경로로 이동하면 6자리의 인증서 폴더가 있다. 인증서가 없다면 제어판 -> 인증서 에서 하나 생성해 준다.

ls -al

위의 명령어를 실행하면 언제 생성됬는지 확인 할 수있음.

cd xxxxxx

인증서 폴더로 이동하고 해당 인증서를 도커쪽 폴더로 복사한다.

# 해당 폴더가 없으면 생성해주자
mkdir /volume1/docker/gitlab/gitlab/certs
# 인증서 복사
cp -f privkey.pem /volume1/docker/gitlab/gitlab/certs/gitlab.key;\
cp -f fullchain.pem /volume1/docker/gitlab/gitlab/certs/gitlab.crt;

복사가 끝나면 복사한 폴더 쪽으로 이동하여 dhparam.pem를 생성한다

cd /volume1/docker/gitlab/gitlab/certs
openssl dhparam -out dhparam.pem 4096

dhparam.pem 생성은 엄청 오래 걸린다. 필자는 켜두고 잤음 ㅋㅋㅋ

dhparam.pem 생성이 완료 되면 깃랩을 실행 하면 https 적용이 완료 됨!!

인증서 자동 갱신

제어판 -> 작업 스케줄러 -> 예약된 작업 -> 사용자 정의 스크립트 작업 설정 탭에서 스크립트를 다음과 같이 작성

# 인증서 폴더 명 
ID="xxxxxx"

#/usr/syno/bin/synopkg stop Docker-GitLab
cd /usr/syno/etc/certificate/_archive/${ID}
SYNOLOGY_CERT=$(sudo openssl x509 -checkend 0 -in fullchain.pem)
GITLAB_CERT=$(openssl x509 -checkend 0 -in /volume1/docker/gitlab/gitlab/certs/gitlab.crt)
echo "synology cert status: ${SYNOLOGY_CERT}"
echo "gitLab cert status: ${GITLAB_CERT}"

if [ "${SYNOLOGY_CERT}" != "${GITLAB_CERT}" ]
then
echo "Action Required"
sudo \cp -f privkey.pem /volume1/docker/gitlab/gitlab/certs/gitlab.key;
sudo \cp -f fullchain.pem /volume1/docker/gitlab/gitlab/certs/gitlab.crt;
echo "GitLab restarting.."
/usr/syno/bin/synopkg restart Docker-GitLab
else
echo "no action required."
fi

echo "done."

스케줄 텝에서 다음과 같이 설정 후 확인 클릭(일요일마다 실행)

참고

• https://github.com/mschadev/synology-gitlab-ssl

Kafka Conncet 설치

• 필자는 모든 설치파일을 /Users/lee/development 경로 안에 저장했음.

  curl -O http://packages.confluent.io/archive/5.5/confluent-community-5.5.2-2.12.tar.gz
  or
  curl -O http://packages.confluent.io/archive/6.1/confluent-community-6.1.0.tar.gz
  tar xvf confluent-community-6.1.0.tar.gz
  cd  confluent-community-6.1.0
  

실행 ./bin/connect-distributed ./etc/kafka/connect-distributed.properties

- Install the JDBC Connector
  - https://docs.confluent.io/5.5.1/connect/kafka-connect-jdbc/index.html
  - 위 링크에서 Download and extract the ZIP file 클릭 후 다운로드 버튼 클릭!
- plugin 정보 추가

• confluent-community-6.1.0 폴더 내에서 code ./etc/kafka/connect-distributed.properties ```
• JdbcSourceConnector에서 mysql 사용하기 위해 드라이버 복사

mvn 의 빌드된 jar들은 .m에 다있음.
cd /Users/lee/.m2/repository/mysql/mysql-connector-java/8.0.26

 cp ./mysql-connector-java-8.0.26.jar /Users/lee/development/kafka/confluent-6.1.0/share/java/kafka

Kafka Conncet 사용

1. Kafka Connce Source 등록

• Kafka Source Conncet 등록 (포스트맨을 사용)

• 등록

  POST / http://localhost:8083/connectors
  Type application/json
  data
  {
    "name" : "my-source-connect",
    "config" : {
    "connector.class" : "io.confluent.connect.jdbc.JdbcSourceConnector",
    "connection.url":"jdbc:mysql://localhost:3306/mydb",
    "connection.user":"root",
    "connection.password":"1234",
    "mode": "incrementing",
    "incrementing.column.name" : "id",
    "table.whitelist":"users",
    "topic.prefix" : "my_topic_",
    "tasks.max" : "1"
    }
  }

• 목록

  GET / http://localhost:8083/connectors

  

• 상세 확인

  http://localhost:8083/connectors/my-source-connect/status

  

• 이제 테이블에 값을 넣을 때마다 메시지를 보내는 것을 볼 수 있음. (처음에는 바뀐 것이 없기 때문에 my_topic_users 가 없음)

  insert into users(user_id, pwd, name) values('user', '1234', 'name');
  insert into users(user_id, pwd, name) values('user2', '1234', 'name2');

  

2. Kafka Connce Sink 등록

• Kafka Sink Conncet 등록 (포스트맨을 사용)
• 등록

  POST / http://localhost:8083/connectors
  Type application/json
  data
  {
    "name":"my-sink-connect",
    "config":{
    "connector.class":"io.confluent.connect.jdbc.JdbcSinkConnector",
    "connection.url":"jdbc:mysql://localhost:3306/mydb",
    "connection.user":"root",
    "connection.password":"1234",
    "auto.create":"true",
    "auto.evolve":"true",
    "delete.enabled":"false",
    "tasks.max":"1",
    "topics":"my_topic_users"
    }
  }

• 목록 및 상세 확인은 동일함.
• Sink 등록 후 DB를 보면 테이블 하나가 생성된 것과 데이터가 들어가 있는 것을 볼 수있음. 테이블 생성이 됨 users 테이블 값 생성된 테이블 값
• 위의 이미지를 보면 users와 my_topic_users 가 동일한 데이터가 있는 것을 볼 수 있음.
• producer에서 값 보내기

  {"schema":{"type":"struct","fields":[{"type":"int32","optional":false,"field":"id"},{"type":"string","optional":true,"field":"user_id"},{"type":"string","optional":true,"field":"pwd"},{"type":"string","optional":true,"field":"name"},{"type":"int64","optional":true,"name":"org.apache.kafka.connect.data.Timestamp","version":1,"field":"created_at"}],"optional":false,"name":"users"},"payload":{"id":7,"user_id":"user5","pwd":"7777","name":"name7","created_at":1633890976000}}

  
• producer에서 값을 보내면 위의 이미지처럼 users에는 값이 들어가지 않고 my_topic_users에만 값을 들어 가는 것을 볼 수 있음
• 이유 : user 토픽으로 부터 데이터를 가져오는 게 아니라 자신이 가지고 있는 데이터를 my_topic_users에 데이터를 넣는 역할임

에러

• 만약 producer에서 값을 잘못 보내면 sink가 에러로 죽음!!
• 해결 방안으로 토픽을 삭제 해주고 다시 실행! 또는 토픽 초기화를 해주면 됨.

  토픽 삭제

• config/server.properties 에서 다음을 추가

  delete.topic.enable=true

• 카프카 재실행 후 다음 커맨드 실행

  ./bin/kafka-topics.sh --delete --bootstrap-server localhost:9092  --topic my_topic_users

• 토픽 초기화는 아래 메소드를 통해서 할 수 있는 듯 하다

Kafka Conncet 관련 메소드

- GET /connectors - return a list of active connectors
- POST /connectors - create a new connector; the request body should be a JSON object containing a string name field and an object config field with the connector configuration parameters
- GET /connectors/{name} - get information about a specific connector
- GET /connectors/{name}/config - get the configuration parameters for a specific connector
- PUT /connectors/{name}/config - update the configuration parameters for a specific connector
- GET /connectors/{name}/status - get current status of the connector, including if it is running, failed, paused, etc., which worker it is assigned to, error information if it has failed, and the state of all its tasks
- GET /connectors/{name}/tasks - get a list of tasks currently running for a connector
- GET /connectors/{name}/tasks/{taskid}/status - get current status of the task, including if it is running, failed, paused, etc., which worker it is assigned to, and error information if it has failed
- PUT /connectors/{name}/pause - pause the connector and its tasks, which stops message processing until the connector is resumed
- PUT /connectors/{name}/resume - resume a paused connector (or do nothing if the connector is not paused)
- POST /connectors/{name}/restart - restart a connector (typically because it has failed)
- POST /connectors/{name}/tasks/{taskId}/restart - restart an individual task (typically because it has failed)
- DELETE /connectors/{name} - delete a connector, halting all tasks and deleting its configuration
- GET /connectors/{name}/topics - get the set of topics that a specific connector is using since the connector was created or since a request to reset its set of active topics was issued
- PUT /connectors/{name}/topics/reset - send a request to empty the set of active topics of a connector

Kafka Broker

• 메시지를 주고 받을 때 저장되는 공간으로 Kafka Broker를 사용
• 실행 된 Kafka 애플리케이션 서버
• 3대 이상의 Broker Cluster 구성
• Zookeeper 연동 (Broker를 컨트롤해줌)
  • 역할 : 메타데이터 저장
  • Controller 정보 저장
• n개 Broker 중 1대는 Controller 기능 수행
  • Controller 역할
    • 각 Broker에게 담당 파티션 할당 수행
    • Broker 정상 동작 모니터링 관리

Kafka 설치

• https://kafka.apache.org/downloads

• tar xvf 압출을 풀 압축파일

• 실제환경에서는 멀티클러스터링을 통해서 다양하게 브로커를 구성한 다음에 안정성있는 메시지 전달할 수 구조로 구축하는 게 좋음

• 예제는 싱글 주키퍼, 싱글 카프카 두가지만 구성

Kafka 실행

• 주키퍼 실행 (port : 2181)

  ./bin/zookeeper-server-start.sh ./config/zookeeper.properties

• Kafka 실행 (port : 9092)

  bin/kafka-server-start.sh config/server.properties

Topic

• Producer가 메시지를 전송하면 Topic에 저장이 된다.

• Topic을 구독을 한 Consumer쪽으로 일괄적으로 메시지를 받음

• Topic 생성

  ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic quickstart-events --partitions 1 --replication-factor 1
  

--create : 생성 --topic : topic 명 --bootstrap-server : 연결한 카프카 서버 주소 --partitions : 생성하는 토픽의 파티션 수 --replication-factor : 생성하는 토픽의 각 파티션의 replication-factor 개수

- Topic 목록 확인

./bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

![](https://images.velog.io/images/jae_cheol/post/71cc4f64-e31d-48fa-911f-3dbe4269a282/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.44.58.png)
- Topic 정보 확인

./bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe

![](https://images.velog.io/images/jae_cheol/post/6d7753fa-9a8a-4312-880c-703bf0dac4c2/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.45.25.png)
- 메시지 생상

./bin/kafka-console-producer.sh --broker-list localhost:9092 --topic quickstart-events

![](https://images.velog.io/images/jae_cheol/post/dd0b24ee-9fa7-499c-9d70-6314e9a798f7/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.45.45.png)
- 메시지 소비

./bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic quickstart-events \ --from-beginning

![](https://images.velog.io/images/jae_cheol/post/74f01099-4ab3-47cd-ad25-b886a5fa8952/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%203.46.23.png)


---
## 에러 처리
- kafka.common.KafkaException: Failed to acquire lock on file .lock in /tmp/kafka-logs.

/tmp/kafka-logs 삭제 9092 포트 찾아서 죽이기 /tmp/kafka-logs 재생성하기

SGA vs PGA

• SGA

  • 공유 메모리 영역인 SGA에 캐시된 데이터는 여러 프로세스가 공유할 수 있다.
  • 여러 프로세스가 공유할 수 있지만, 동시에 액세스할 수 없다.
  • 동시에 액세스하려는 프로세스 간 액세스를 직렬화하기 위한 Lock 메커니즘으로 래치(Latch)가 존재
  • 데이터 블록과 인덱스 블록을 캐싱하는 DB버퍼캐시는 SGA의 가장 핵심적인 구성요소
  • 여기서 블록을 읽으려면 버퍼 Lock도 얻어야 한다.

• PGA

  • 오라클 서버 프로세스는 SGA에 공유된 데이터를 읽고 쓰면서, 동시에 자신만의 고유 메모리 영역을 갖는다.
  • 각 오라클 서버 프로세스에 할당된 메모리 영역을 PGA라 부름
  • 프로세스에 종속적인 고유 데이터를 저장하는 용도로 사용
  • 다른 프로세스와 공유하지 않는 독립적인 메모리 공간
  • 래치 메커니즘이 불필요
  • 같은 양의 데이터를 읽더라도 SGA 버퍼캐시에서 읽을 때보다 훨씬 빠름

기본 매커니즘

• 소트 머지 조인
  1. 소트 단계 : 양쪽 집합을 조인 컬럼 기준으로 정렬
  2. 머지 단계 : 정렬한 양쪽 집합을 서로 머지
• SortArea에 저장할 데이터 자체가 인덱스 역할을 하므로 소트 머지 조인은 조인 컬럼에 인덱스가 없어도 사용할 수 있는 조인 방식이다.

소트 머지 조인이 빠른 이유

• NL 조인의 치명적인 단점은 대량 데이터 조인할 때 성능이 매우 느림
• 소트 머지 조인은 Sort Area에 미리 정렬해 둔 자료구조를 이용한다는 점만 다를 ㅃ분 조인 프로세싱 자체는 NL 조인과 같다.
• 소트 머지 조인은 양쪽 테이블로 부터 조인 대상 집합을 일괄적으로 읽어 PGA에 저장한 후 조인한다.
• PGA는 프로세스만을 위한 독립적인 메모리 공간이므로 데이터를 읽을 때 래치 획득 과정이 없다.

소트 머지 조인의 주용도

• 소트 머지 조인 사용
  1. 조인 조건식이 등치(=)조건이 아닌 대량 데이터 조인
  2. 조인 조건식이 아예 없는 조인(Cross Join, 카테시안 곱)

소트 머지 조인 제어하기

• use_merge()

소트 머지 조인 특징 요약

• 조인을 위해 실시간으로 인덱스를 생성하는 것과 다름 없다.
• 조인 컬럼에 인덱스가 없는 상황에서 두 테이블을 각각 읽어 조인 대상 집합을 줄일 수 있을 떄 유리
• 스캔 위주의 액세스 방식을 사용한다.
• 하지만 모든 처리가 스캔 방식으로 이루어 지지 않음