📌 신뢰적 데이터 전송의 원리

슬라이딩 윈도우

고정 사이즈의 윈도우가 이동하면서 윈도우 내에 있는 데이터를 이용해 문제를 풀이하는 알고리즘을 말합니다. 

배열이나 리스트의 요소의 일정 범위의 값을 비교할때 사용하면 매우 유용합니다. 

원래 네트워크에서 사용되던 알고리즘을 문제풀이에 응용한 경우라고 할 수 있습니다.

Go Back N

GBN에서 송신자는 송신한 패킷에 대한 확인 응답 없이, 최대 N개의 패킷을 전송할 수 있습니다.

이를 크기가 N인 윈도우로 표현합니다. (N은 흐름제어와 혼잡제어에 의해 조정된다.)

송신한 패킷이 올바르게 수신측에 도착하여 확인 응답을 받으면, 윈도우는 앞으로 이동하고 다음 패킷을 전송합니다.

이를 슬라이딩 윈도우 프로토콜(sliding-window protocol)이라고 부릅니다.

Selective Repeat

Selective Repeat 프로토콜은 손실 되거나 손상된 패킷에 대해서만 재전송 합니다.

GBN처럼 윈도우 크기만큼 패킷들을 전송하지 않는다. 즉, 불필요한 재전송을 하지 않습니다.

GBN 수신자는 누적확인 응답을 하지 않는다. 순서번호가 앞서는 패킷이 도착하면 그대로 수신합니다.

📌 TCP

TCP

TCP (전송 제어 프로토콜)는 두 개의 호스트를 연결하고 데이터 스트림을 교환하게 해주는 네트워크 프로토콜입니다.

3 way handshake

3-way-handshake는 신뢰적인 데이터 전송을 보장하기 위해 3개의 패킷을 주고 받으며 사전 연결 설정을 수립하는 과정입니다.

4 way handshake

4개의 특별한 패킷을 주고 받으며 TCP 연결을 해제하는 방법입니다.

TCP 빠른 재전송

타임아웃에 의한 재전송의 문제점은 타임아웃의 주기가 때때로 길다는 점입니다.

다행히도 송신자는 중복 ACK 수신을 통해 타임아웃이 일어나기 전에 송신된 패킷이 손실되었음을 인지할 수 있습니다.

수신자는 순서가 올바르지 않은 세그먼트를 수신하면, 마지막으로 올바르게 수신된 세그먼트에 대한 ACK를 송신측에 전송합니다.

송신자가 만약 같은 세그먼트에 대해 3개의 중복된 ACK를 수신하게 되면

해당 ACK에 해당하는 세그먼트가 손실되었음을 인지하게 재전송을 하게됩니다.

이는 타임아웃에 상관없이 이루어지므로 빠른 재전송이라고 할 수 있습니다.

Congestion control

네트워크 혼잡을 줄이기 위해 패킷 송신 속도 즉, 송신측의 윈도우 크기를 조절하는 것을 말합니다.

네트워크가 혼잡해지면 지연이 커지고 패킷 손실이 발생합니다.

패킷이 지연되거나 손실되면 재전송이 이루어지는데, 이렇게 되면 네트워크는 더욱 혼잡해집니다.

Flow control

송신자가 패킷을 보내는 속도가 수신자가 수신버퍼에서 패킷을 읽어드리는 속도보다 빠른경우
수신 버퍼에 오버플로우가 일어나 패킷을 수신할 수 없는 상황이 발생합니다.

이를 방지하기 위해 송신자가 패킷 송신 속도를 조절하는 것. 즉 송신측의 윈도우 크기를 조절하는 것을 flow control이라고 합니다.

UDP

TCP와 달리 UDP는 연결 지향형이 아니고, 신뢰적인 데이터 전송을 보장하지 않습니다.

단지 체크섬을 통해 수신된 패킷의 오류 여부 정도만을 알 수 있습니다.

하지만 UDP는 TCP에 비해 기능이 별로 없기 때문에 적은 오버헤드로 빠른 전송이 가능 합니다.

따라서 일정 전송 요구량이 있고, 조금의 데이터 손실을 허용하는 스트링 애플리케이션에 어울립니다.

DNS 서버도 UDP를 사용합니다.

UDP의 장단점

UDP의 장점은 비연결형 서비스이므로 TCP에 비해 속도가 빠르며 네트워크 부하가 적습니다.
또한, 1:1, 1:N, N:N 통신이 가능합니다.

단점으로는 데이터의 신뢰성이 없습니다.

UDP 체크섬

UDP 체크섬은 UDP 세그먼트의 오류 검출을 위해 사용되는 것 입니다.

체크섬은 송신할 세그먼트를 16비트 단위로 나누고, 모두 더한 다음 1의 보수를 취해서 만들어 집니다.

이 체크섬을 세그먼트와 같이 전송 합니다.

수신자는 수신된 세그먼트에 대해 동일한 방식으로 체크섬을 만들고 
헤더의 체크섬과 일치 하는지 비교함으로써
수신된 세그먼트의 오류를 검출할 수 있습니다.

전송 후 대기 프로토콜

전송후 대기 프로토콜은 패킷을 전송하고 그 패킷에 대한 수신 확인 응답을 받고나서, 다음 패킷을 전송하는 방식 입니다. 

이러한 방식은 네트워크 링크 이용률이 낮아 속도가 느리다는 단점이 있습니다.

파이프라인 프로토콜

파이프라이닝 프로토콜은 전송한 패킷에 대한 수신 확인 응답을 받지 않고도, 

여러 개의 패킷을 연속으로 전송하여 링크 이용률과 전송 속도를 높이는 프로토콜 입니다. 

📌 DNS

DNS

DNS는 도메인 네임을 IP 주소로 변환해주는 프로토콜이자 계층형 구조로 구현된 분산 데이터베이스 입니다.

호스트가 도메인 네임에 대한 IP 주소를 요청하면 DNS는 계층 질의를 통해 IP 주소를 얻어다가 줍니다. 

만약 로컬 DNS에 해당 IP 주소가 캐싱되어 있다면 바로 받습니다.

빠른 응답을 제공하기 위해 DNS는 UDP 기반으로 동작하고 DNS 서버들은 요청 정보를 캐싱해둡니다.

DNS 작동 방식

사용자가 웹 브라우저에서 도메인 이름을 입력합니다.

브라우저는 해당 도메인을 DNS 서버에 보내서 IP 주소를 요청합니다.

DNS는 IP주소를 찾아서 브라우저에 보내고, 브라우저는 IP주소를 통해 서버에 요청을 보냅니다.

DNS 질의 종류

재귀적 질의는 도메인 네임에 해당하는 IP주소를 통해 DNS가 다른 DNS에게 재귀적으로 IP 주소를 물어보는 것을 뜻합니다.

반복적 질의는 IP 주소를 찾기 위해 반복적으로 질의하는 것입니다.

로컬 DNS가 루트 DNS에게 IP주소를 물어봤는데 없으면 TLD DNS에게 물어보고 또 없으면 
authoriative DNS에 반복적으로 물어보는 것을 예시로 들 수 있습니다.

DNS 서버에게 IP 주소를 요청할 때, UDP를 사용하는 이유

DNS는 신뢰성보다 속도가 더 중요한 서비스이기 때문에 연결 설정에 드는 비용이 없는 UDP를 사용합니다.

DNS는 연결 상태를 유지할 필요가 없고, TCP보다 많은 클라이언트를 수용할 수 있는 UDP를 사용합니다.

DNS 레코드

DNS 서버는 데이터베이스 서버의 한 유형이며, 클라이언트로부터 질의를 받았을 때 그에 맞는 데이터를 응답해야 합니다. 

데이터베이스의 한 항목(row)을 DNS 서버에서는 리소스 레코드라고 부릅니다.

- A
    - IP 주소와 도메인 주소를 매핑할 때 사용하는 레코드입니다.
- CNAME
    - 기존 도메인에 별명을 붙인 레코드입니다.
- TXT
    - 텍스트를 입력할 수 있는 레코드입니다.
    - 개인 프로젝트에서 무료 SSL 인증서를 등록하는 과정에서 사용하였습니다.

DB 세션

• 데이터베이스 세션이란 데이터베이스 접속을 시작으로 여러 작업을 수행한 후 접속 종료까지의 전체 기간을 의미합니다.
• 세션 안에는 여러 개의 트랜잭션이 존재할 수 있고, 여러 곳에서 데이터베이스를 접속할 경우, 많은 세션이 동시에 연결될 수 있습니다.

트랜잭션

• 트랜잭션이란 데이터베이스 내에서 하나의 그룹으로 처리되어야 하는 명령문들을 모아 놓은 작업 단위입니다.

Commit

• Commit이란 Transaction의 처리 과정을 데이터베이스에 정상적으로 처리하겠다고 확정하는 명령어입니다.
• Commit을 수행하면 하나의 트랜잭션 과정을 종료하게 됩니다.

Rollback

• Rollback이란 작업 중 문제가 발생했을 때, Transaction의 처리 과정에서 발생한 변경 사항을 취소하고, Transaction 과정을 종료시켜 Transaction으로 처리가 시작되기 이전의 상태로 되돌리는 명령어를 의미합니다.
• 이전 COMMIT한 곳까지만 복구합니다.

Auto Commit 설정

• DDL문에는 CREATE, ALTER, DROP과 같은 명령어들이 있는데 이들 모두는 자동으로 COMMIT을 실행합니다.

트랜잭션의 성질 ACID

• ACID는 하나의 transaction의 안전성을 보장하기 위해 필요한 성질입니다. 각각은 Atomicity, Consistency, Isolation, Durability를 의미합니다.
• Atomicity는 원자성으로 한 Transaction의 연산들이 모두 성공하거나, 반대로 전부 실패되는 성질을 말합니다.
  • 하나의 거래에서 계좌 출금과 입금은 모두 성공하거나 전부 실패해야 합니다.
• Consistency는 일관성으로 Transaction의 이전과 이후, 데이터베이스 상태는 이전과 같이 유효해야 한다는 성질입니다.
  • 제약 조건 중 모든 고객은 반드시 이름이 있어야 한다는 제약이 있다면 이름 없는 새로운 고객 추가 쿼리 같은 것은 일관성이 유지되지 않는 쿼리입니다.
• Isolation은 격리성으로 모든 Transaction은 다른 Transaction으로부터 독립되어야 한다는 뜻입니다.
• Durability은 지속성으로 하나의 Transaction이 성공적으로 수행되었다면, 해당 Transaction에 대한 로그가 남아야하는 성질을 말합니다.
• 만약 런타임 오류나 시스템 오류가 발생하더라도, 해당 기록은 영구적이어야 합니다.

트랜잭션 격리 수준

• Transaction의 격리 수준(Isolation Level)이란 여러 Transaction이 동시에 처리될 때, 특정 Transaction이 다른 Transaction에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 여부를 결정하는 것입니다.
• 트랜잭션의 격리 수준은 수준이 높은 순서대로 SERIALIZABLE, REPEATABLE READ, READ COMMITTED, READ UNCOMMITED가 존재합니다.

트랜잭션 격리 수준 READ UNCOMMITTIED

• READ UNCOMMITTED는 커밋하지 않은 데이터 조차도 접근할 수 있는 격리 수준입니다.
• 다른 트랜잭션의 작업이 커밋 또는 롤백되지 않아도 즉시 보이게 됩니다.
• 어떤 트랜잭션의 작업이 완료되지 않았는데도, 다른 트랜잭션에서 볼 수 있는 부정합 문제를 Dirty Read라고 합니다.

Dirty Read

• 어떤 트랜잭션의 작업이 완료되지 않았는데도, 다른 트랜잭션에서 볼 수 있는 부정합 문제를 Dirty Read라고 합니다.
• Dirty Read 상황은 시스템에 상당한 버그를 초래할 수 있기 때문에 MySQL을 사용한다면 최소한 READ COMMITTED이상의 격리 수준을 사용해야 합니다.

트랜잭션 격리 수준 READ COMMITTED

• READ COMMITTED는 커밋된 데이터만 조회할 수 있습니다.
• REPEATABLE READ에서 발생하는 Phantom Read에 더해 Non-Repeatable(반복 읽기 불가능) 문제까지 발생합니다.

READ COMMITTED에서 발생할 수 있는 Non-Repeatable Read(반복 읽기 불가능)

• READ COMMITTED에서 반복 읽기를 수행하면 다른 트랜잭션의 커밋 여부에 따라 조회 결과가 달라질 수 있는 것을 반복 읽기 불가능이라고 합니다.
• 하나의 트랜잭션에서 동일한 데이터를 여러 번 읽고 변경하는 작업이 금전적인 처리와 연결되면 문제가 생길 수 있습니다.

트랜잭션 격리 수준 REPEATABLE READ

• RDBMS는 변경 전의 레코드를 백업해두어서 변경 전과 변경 후의 데이터가 모두 존재합니다. 이걸 MVCC(Multi-Version Concurrency Control, 다중 버전 동시성 제어)라고 부릅니다.
• 이를 통해 서로 다른 트랜잭션 간에 접근할 수 있도록 고유한 트랜잭션 번호가 존재하는데, 백업 레코드에서는 어느 트랜잭션에 의해 백업되었는지 트랜잭션 번호를 함께 저장합니다.
• REPEATABLE READ는 MVCC를 이용해 한 트랜잭션 내에서 동일한 결과를 보장하지만, 새로운 레코드가 추가되는 경우에 부정합이 생길 수 있습니다.
• REPEATABLE READ는 어떤 트랜잭션이 읽은 데이터를 다른 트랜잭션이 수정하더라도 동일한 결과를 반환할 것을 보장합니다.

유령 읽기

• 유령 읽기란 다른 트랜잭션에서 수행한 작업에 의해 레코드가 안보였다 보였다 하는 현상을 의미합니다.
• 트랜잭션이 끝나기 전에 다른 트랜잭션에 의해 추가된 레코드가 발견될 수 있는 현상을 의미합니다.
• 유령 읽기는 잠금이 사용되는 경우에 발생할 수 있습니다.
• 일반적으로 MySQL의 REPEATABLE READ에서는 Phantom Read가 발생하지 않습니다.

쓰기 잠금과 읽기 잠금

• 쓰기 잠금은 SELECT ... FOR UPDATE 구문으로 사용합니다.
• 읽기 잠금은 SELECT FOR SHARE 구문을 사용해야 합니다.
• 락은 트랜잭션이 커밋 또는 롤백될 때 해제됩니다.

트랜잭션 격리 수준 SERIALIZABLE

• 가장 엄격한 격리 수준으로, 이름 그대로 트랜잭션을 순차적으로 진행시킵니다.
• 여러 트랜잭션이 동일한 레코드에 동시 접속할 수 없으므로 어떠한 데이터 부정합 문제도 발생하지 않습니다.
• 하지만, 트랜잭션이 순차적으로 처리되어야 하므로 동시 처리 성능이 떨어집니다.

오라클에서는 READ COMMITTED를 기본으로 사용하고 MYSQL에서는 REPEATABLE READ를 기본으로 사용합니다

DB 동시성 제어(Concurrency Control)

• 동시성 제어란 동시에 실행되는 여러 개의 트랜잭션이 작업을 성공적으로 마칠 수 있도록 트랜잭션의 실행 순서를 제어하는 기법입니다.
• 트랜잭션의 직렬성을 보장하고, 데이터의 무결성 및 일관성을 보장하여 줍니다.

동시성 제어를 하지 않은 경우 발생하는 문제점

갱신 손실 문제

• 하나의 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어씀으로써 갱신이 무효화가 되는 것을 의미합니다.
• 두 개의 트랜잭션이 한 개의 데이터를 동시에 갱신할 때 발생합니다.

DB 락(Lock)

• Lock이란 트랜잭션 처리의 순차성을 보장하기 위한 방법으로 데이터의 무결성과 일관성을 지키기 위해 Lock을 사용합니다.

Lock의 종류

• Shared Lock(공유 락) : 공유락은 데이터를 변경하지 않는 읽기 명령에 대해 주어지는 락입니다.
• Exclusive Lock(베타 락) : 데이터에 변경을 가하는 명령들에 대해 주어지는 락으로 다른 세션이 해당 자원에 접근하는 것을 막습니다.
• Update Lock(업데이트 락) : 데이터를 수정하기 위해 베타 락을 걸기전에 데드 락을 방지하기 위해 사용되는 락입니다.
• Intent Lock(내제 락) : 내제 락은 사용자가 요청한 범위에 대한 락을 걸 수 있는지 여부를 빠르게 파악하기 위해 사용되는 락입니다.

Blocking

• 블로킹은 Lock간의 경합이 발생해서 특정 트랜잭션이 작업을 진행하지 못하고 멈춰선 상태를 말합니다.
• 베타-베타, 베타-공유 간에 블로킹을 발생시킬 수 있습니다.

DB 데드락

• 데드락은 교착상태라고 하며 교착상태는 두 트랜잭션이 각각 Lock을 설정한 다음 서로의 Lock에 접근하여 값을 얻어오려고 할 때 이미 각각의 트랜잭션에 의해 Lock이 설정되어 있기 때문에 양쪽 트랜잭션 모두 영원히 처리가 되지 않게 되는 상태를 말합니다.

데이터베이스 장애의 유형

• 트랜잭션 장애 : 트랜잭션의 실행 시 논리적인 오류로 발생할 수 있는 에러 상황(잘못된 데이터 입력, 데이터의 부재, 오버플로우, 자원의 한계 초과 요청)
• 시스템 장애 : H/W 시스템 자체에서 발생할 수 있는 에러 상황
• 미디어 장애 : 디스크 자체의 손상으로 발생할 수 있는 에러 상황

DB 회복

• 데이터베이스를 장애가 발생했던 이전의 상태로 복구시켜서 일관된 데이터베이스 상태를 만드는 것을 의미합니다.

REDO, UNDO

• REDO는 무언가를 다시 하는 것이고, UNDO는 무언가를 되돌리는 것입니다.
• 둘 다 복구를 하지만, REDO는 복구를 할 때 사용자가 했던 작업을 그대로 하지만, UNDO는 사용자가 했던 작업을 반대로 진행합니다.

체크포인트 회복 기법

• 회복 기법을 간단하게 하기 위해서 사용하는 방법이 체크포인트 회복 기법입니다.
• 체크 포인트 이전에 커밋 기록이 있는 경우 아무 작업이 필요 없고,
• 체크 포인트 이후에 커밋 기록이 있는 경우 REDO를 진행하고
• 체크 포인트 이후에 기록이 없는 경우 UNDO를 진행합니다.

MySQL InnoDB의 기본 트랜잭션 고립 수준

• REPEATABLE READ입니다.

쿠버네티스 환경 구축 3단계 (1)

쿠버네티스

쿠버네티스는 컨테이너 애플리케이션을 분산 환경에서 운용 관리하기 위한 오케스트레이션 툴이다. (단어 하나씩 뜯어봤는데도,, 말이 어려워서 기억하기 위해..)

결과적으로는 온프레미스 환경에서 쿠버네티스를 사용할 것이지만, 일단 Azure를 사용해서 클라우드 환경에서 쿠버네티스를 사용해 보겠다!

컨테이너 이미지 빌드와 공개

전체적인 흐름

컨테이너 애플리케이션을 개발하고 운용할 때의 흐름을 알고, 순서대로 진행해 보겠다.

1. 개발 환경 준비
   Azure를 실행하기 위해서 IDE나 로그인 등을 해야함
2. 컨테이너 이미지의 작성 및 공유
   컨테이너를 동작시키려면 애플리케이션을 움직이기 위한 것들이 이미지로 있어야 한다. 필요한 것들로는 바이너리, OS, 네트워크 같은 설정들을 이야기 한다.
   만약 도커일 경우에는 Dockerfile이라는 텍스트 파일에 구성을 기술하고, 이것을 빌드하면 빌드된 것을 실행 환경에서 이용 가능한 레포지토리로 공유한다.
   (마치 로컬에서, github에 커밋을 하고 다른 컴퓨터에서 pull해서 사용하는 느낌이였다.)
3. 클러스터 작성 (실제 환경 작성)
   실제로 컨테이너 애플리케이션을 작동시키는 서버를 구축해야 한다. 개발 환경이나 테스트 환경에서는 로컬 머신으로 작동시키지만, 서비스 공개할려면 클라우드 서비스를 사용하든지, 실제 서버 컴퓨터(온프레미스) 환경이 있어야 한다.

[ 1번의 진행과정 ]

쿠버네티스 클러스터

쿠버네티스 클러스터란, 쿠버네티스가 분산 환경에서 여러 대의 서버나 스토리지와 같은 컴퓨팅 리소스가 네트워크로 연결된 환경에서 각각 다른 역할을 가지면서 서로 협조해 가며 컨테이너 애플리케이션을 실행시키는 것을 의미한다.

쿠버네티스 클러스터를 만들려면 여러 대의 서버나 가상 머신에 쿠버네티스를 설치하고 네트워크 설정 등을 해야 한다.

클러스터를 쉽게 운용하기 위해서 먼저 Azure 컨테이너 서비스를 이용해보겠다!

1. 먼저 Azure에 개인 계정을 만들어야 된다. (나는 건국대학교 학생 계정을 이용해서 1년 무료로 사용할 수 있다고 해서 학교 계정을 사용하였다)
2. Azure 포털 사이트에서도 cli 창을 띄울 수 있었는데, 리눅스 명령어도 익힐 겸 Azure CLI 명령을 설치해서 할 수 있었다. (사이트에서 MSI 인스톨러로 다운받았다.)
3. 만약 Azure에 로그인을 하면 cmd창을 켜서 az login을 입력하면, redirect페이지가 나오고 로그인이 된다.

4. Azure의 서비스를 이용하기 위해 리소스 프로바이더도 할당한다.

Azure 리소스 프로바이더를 활성화해야 하는 이유
Azure에서 리소스 프로바이더를 활성화해야 하는 이유는 해당 리소스를 생성하고 관리, 조작하기 위해서이다. Azure의 각각의 서비스는 Azure Resource Manager(ARM)이라는 것에 의해서 관리되는데, 리소스 프로바이더는 이 ARM에서 각각의 서비스에 대한 API 엔드포인트를 제공한다.

그래서 Azure 리소스를 만들거나 관리하려면 해당 리소스 유형에 대한 프로바이더가 활성화되어 있어야 한다.

예를 들어서 Azure Virtual Machines를 만들려면 Microsoft.Compute 리소스 프로바이더가 필요하다. 이 프로바이더는 Virtual Machine과 관련된 API 엔드포인트를 제공해서, 가상 머신의 생성, 삭제, 업데이트 등의 작업을 수행할 수 있도록 한다.

여기서는 Microsoft.Network, Storage, Compute, ContainerService 모두 활성화시켰다.

kubectl 명령

쿠버네티스 클러스터를 조작하려면 GUI를 사용해도 되는데, 일반적으로는 명령으로 조작한다고 한다.

명령으로 조작하기 위해서는 kubectl을 사용한다. kubectl 명령은 쿠버네티스 클러스터의 상태를 확인하거나 구성을 변경하기 위한 것이다. 개발을 하는 클라이언트 머신에 설치하면 된다.

나는 Window이기 때문에 쿠버네티스 페이지에 있는대로 따라하였다.

Install and Set Up kubectl on Windows

(몇번 잘못 입력한 다음에... 성공)

그럼 kubectl과 az 명령은 각각 언제 필요?

지금 명령만 2개를 설치했는데, 두 명령은 차이가 있다. kubectl 명령은 쿠버네티스 클러스터 안에서 움직이는 컨테이너 애플리케이션을 조작하는 것이고, az 명령은 Azure를 사용해서 쿠버네티스 클러스터 자체의 구축이나 삭제 등을 하는 것이다.

설치가 하다가 오래걸려서.. 2단계는 내일 써보겠다!

서버를 도커를 사용해서 배포해야 한다, 도커를 사용하면 신세계를 경험할 수 있다. 이러한 말만 많이 듣고, 정작 배포할 때는 배포파일을 명령어로 EC2로 이동시켜서 실행해 본 경험 밖에 없어서 도커에 대한 개념을 알고 배포까지 해보려고 한다.

먼저, 이 글은 도커에 대한 개념을 공부한 내용이다.

도커의 정의

도커란 개발자가 컨테이너화된 애플리케이션을 빠르게 빌드, 테스트 및 배포할 수 있게 해주는 가상화 도구 라고 한다.

이 말만 들어서는 정의 안에 너무 모르는 말들이 많았다. 가상화, 컨테이너에 대한 용어부터 알고 가겠다.

가상화

가상화란 하나의 물리적 서버 호스트에서 여러 개의 서버 운영 체제를 게스트로 실행할 수 있게 해주는 아키텍쳐이다.

내 물리적 서버는 현재 윈도우를 사용하고 있는데, 우분투나 다른 운영체제를 사용해야 할 경우가 생긴다. 그 때 가상화라는 것을 사용하는 것이다.

가상화가 필요한 이유는 서버의 성능을 나누어서 사용하기 위해 필요하다. 하나의 서버를 나누어서 성능을 분산시키고, 분산된 서버들은 각기 다른 서비스를 수행한다. 즉, 내가 여러 서비스를 실행하고 싶을 때, 컴퓨터를 여러 대 사는게 아니라 하나의 서버에서 서버를 여러 개 쓰는 효과를 누리게 된다.

가상화를 통해서 사용자가 많은 서비스에는 많은 자원을 할당해주고, 적은 서비스에는 적게 할당해 줄 수 있다.

이런 가상화를 구현해주는 기술은 Hypervisor라는 가상화 기술을 사용한다. Hypervisor는 여러 개의 운영체제를 하나의 Host OS에 생성해서 사용할 수 있게 해주는 소프트웨어이다. 여러 개의 운영체제는 하나 하나가 가상머신 이라는 단위로 구별이 된다.

그럼 Hypervisor는 os들에게 자원도 나누어주고, os들이 요청하는 커널 번역해서 하드웨어에게 전달도 해준다. Hypervisor에 의해 생성되고 관리되는 운영체제는 guest 운영체제라고해서, 각 guest 운영체제는 완전히 독립된 공간과 시스템 자원을 할당받아서 사용하게 된다.

그럼 위에서 얘기했던 도커를 사용하는 이유랑 같은거 같다. 그럼 가상화의 어떠한 단점 때문에 도커가 나오게 된 것일까?

가상화를 사용하는 툴은 Virtual Box나 VMWare 같은 것들이 있다. 근데 이러한 가상화 툴의 단점은 Hypervisor를 반드시 거쳐야 하므로 일반 호스트에 비해서 성능 손실이 발생한다. 그리고 가상머신에 guest 운영체제를 사용하기 위한 라이브러리, 커널 등을 전부 포함해서 배포할 때 크기도 커진다.

즉, 가상머신을 완벽한 운영체제를 생성할 수 있는 장점이 있긴 하지만, 성능이 떨어지고 용량 문제도 생기는 것이다.

이를 해결하기 위해 나온 것이 컨테이너의 개념이다.

컨테이너

컨테이너란 가상화된 공간을 생성하기 위해서 리눅스 자체 기능을 사용해서 프로세스 단위의 격리환경을 만든다. 여기서 격리 환경을 컨테이너라고 하게 된다.

컨테이너의 사전적 의미는 어떤 물체를 격리하는 공간으로 이걸 소프트웨어에서 사용할 때는 파일 시스템+격리된 자원 + 네트워크를 사용할 수 있는 독립된 공간이라는 의미로 가져온다.

우리가 아는 컨테이너는 스프링에서 자주보던 서플릿 컨테이너나 IoC 컨테이너, Bean 컨테이너 같은 것들이다. 이런 컨테이너들은 컨테이너에 담긴 것들의 라이프 사이클을 관리해준다. 어떤 것들을 생성하고, 운영하고, 제거까지 컨테이너가 관리해주는 것이다.

그럼 도커에서의 컨테이너란 이미지의 목적에 따라서 생성되는 프로세스 단위의 격리환경으로 프로세스의 생명 주기를 관리하는 환경을 제공해준다.

컨테이너 안에는 애플리케이션을 구동하는데 필요한 라이브러리와 실행 파일만 존재해서 이미지로 만들게 되면, 이미지 용량도 매우 적다. 여기서 이미지란 컨테이너를 만드는 데 필요한 모든 지시사항과 dependency를 포함하는 템플릿으로 ‘컨테이너를 만들어주는 틀’이라고 생각하면 된다.

이 컨테이너를 다루는 기술 중 하나가 도커가 되는 것이다. (도커 이외에도, Red Hat Openshit, ECS, 이런 것들이 있다고 한다..)

Q> 그럼 컨테이너를 왜 써야 하는가?
A> 이미지의 실행, 배포가 빨라지고 Host와의 격리를 통해서 독립된 개발을 할 수 있다.

여기서 도커는 컨테이너 기술에 여러 기능을 추가한 오픈소스 프로젝트인 것이다.

도커

그럼 컨테이너를 도커는 어떻게 관리하는 것일까? 도커는 Docke Engine을 통해서 컨테이너를 관리할 수 있다. 도커 엔진은 유저가 컨테이너를 쉽게 사용할 수 있게 하는 주체로 컨테이너의 라이프 사이클을 관리해주고 이미지, 볼륨, 네트워크 까지 관리해준다.

그래서 최근 자바 프로젝트는 SpringBoot + Docker + EC2 조합으로 환경을 구성한다고 한다. 그럼 도커 시스템을 구축하고 배포하는 방법을 보겠다.

도커를 통해서 배포하기

먼저 도커를 설치해야 한다. 나는 도커 데스크톱까지 설치해주었다.

그리고 테스트할 SpringBoot 프로젝트를 만들었다. 해당 프로젝트에 Dockerfile을 만들어서 설정을 해주면 된다. 제일 간단한 설정만 따와서 해보았다.

FROM amazoncorretto:11
COPY build/libs/*.jar dockerpr-0.0.1-SNAPSHOT.jar
ENTRYPOINT ["java", "-jar", "dockerpr-0.0.1-SNAPSHOT.jar"]

해당 설정을 해준 뒤, Docker Image를 만들어야 한다. Intellij에서 터미널에서 제일 루트 위치에서 실행시켜주면 된다.

docker build -t jakeheon/dockerpr

그리고 docker images로 도커 이미지가 생성되었는지 확인하면 된다. (잘 안되어서 몇 번 하다보니까 이미지가 잔뜩 생겼다.. 오류는 docker에 로그인을 하지 않았거나(docker login) 파일 위치가 잘못되었거나 하는 경우였다)

그리고 Container를 실행해준다. Host Port와 Container Port를 연결할려고 port를 2개 입력하였다.

docker run -d -p 8080:8080 jakeheon/dockerpr

해당 컨테이너가 실행되고 있음을 명령어로 확인할 수 있다.

docker ps

그리고 http://localhost:8080에도 잘 접속된다. 그리고 도커 허브 사이트에 이미지를 푸쉬하면 된다.

docker push jakeheon/dockerpr

EC2에서는 똑같이 해주면 된다.

docker를 설치하고, docker를 실행하고, 도커 허브에 있는 이미지를 풀하면 된다.

그리고 이미지를 실행하면 된다.

그냥 github처럼 우리가 github에 push한 걸 ec2에서 받아오는 느낌과 같다.

[참고 링크]
https://devfoxstar.github.io/java/springboot-docker-ec2-deploy/
https://selfish-developer.com/entry/가상화-기술의-유형

https://youtu.be/IiNI6XAYtrs

암달의 법칙은 컴퓨팅 시스템에서 시스템을 설계할때 고려해야 할 중요한 개념이다. 

우리는 컴퓨터의 한 측면의 개선이 전체 성능을 개선 크기에 비례하여 증가시킬 것으로 기대하지만, 실제로는 그렇지 않다.

그럼 5배정도 빠르게는 할 수 있을까? 80/speedup + 20 = 20이 되어야 하는데 그렇게 될려면 speedup이 무한대가 되어야한다. 실제로 불가능하다는 이야기이다.

컴퓨터 성능에서 제일 많은 부분을 차지하는 것은 응답시간과 처리량이다. (response time, throughput)

그냥 모든 기계를 생각해도 비슷할 것이다. 기계가 일을 하는데 걸리는 시간. 즉, 일 하나를 하는데 얼마나 많은 시간이 걸리느냐랑 주어진 시간동안 얼마나 많은 일을 하느냐. 

이 2가지가 컴퓨터의 성능을 결정한다. 

성능(performance)는 응답시간(response time)이 짧을 수록 좋을 것이다. 즉 서로 반비례 관게인 것이다. 

예를 들어서, 동일한 일을 수행하는데 A 컴퓨터는 10초가 걸리고, B 컴퓨터는 15초가 걸린다고 가정하자. 

그럼 A컴퓨터가 B컴퓨터보다 성능이 1.5배 좋다라고 생각할 수 있다. 

결국 CPU performance를 측정한다는 것은 CPU time을 기준으로 performance를 측정한다.

CPU Time은 어떻게 구할까?

CPU Time = CPU Clock Cycles X Clock Cycle Time = CPU Clock Cycles / Clock Rate

해당 식을 어떤 의미인지 확인해보자.

한 Clock당 시간을 Clock Cycle Time이라고 하고, 그럼 총 Cycle을 구하면 CPU Time을 구할 수 있으니까 CPU Clock Cycles(사이클 수)를 곱해주면 전체 시간이 나오게 된다. 

Clock Cycle Time, 즉 한 Clock당 시간은 Clock Rate의 역수이다. 

그럼 위의 식에서 CPU Time이 나오는데, CPU Time은 Performance와 반비례 관계라고 했다. 그럼 Performance를 향상시킬 수 있는 방법은 무엇일까? (CPU Time을 작게 만들 수 있는 방법)

- clcok cycles의 수를 줄인다.

- clock rate를 늘린다. = cycle time을 줄인다.

- 그런데 늘 위의 방법을 한다고 다 빨라지는건 아니다. Clock Rate를 증가시키다보면 CPU Clock Cycles가 증가할 수도 있고 이런 문제가 생긴다. (서로 trade off가 있다)

조금 더 자세히 Clock Cycles를 살펴보자. 

Clock Cycles = Instruction Count X Cycles per Instruction(CPI)
즉, Clock Cycle은 명령어의 갯수 X 명령어당 필요한 Cycle의 수.

여기서 instruction 1개당 필요한 cycle 수가 CPI이다. 그럼 다음과 같은 식이 나온다. 

Instruction Count는 알고리즘을 어떻게 짜느냐, 어떤 ISA를 갖고 있느냐, compiler에 따라 개수가 바뀐다.

하나의 cycle당 하나의 명령어를 처리한다고 생각할 수 있는데, 그게 아니라 하나의 명령어도 여러 cycle로 걸린다.

그래서 Instruction에 따라서 몇 cycle이 필요한지, 명령어에 따라 다르다. (CPI가 다 다르다)

Average CPI(Average Cycles Per Instruction)는 CPU 하드웨어에 의해 결정되고 다른 instruction을 가지면 다른 CPI를 가지게 된다. 

이제는 CPI에 대해서 더 자세히 알아보겠다. 

Clock Cycles은 총 사이클 도는데 걸리는 시간이라고 했다. 그리고 명령어마다 필요한 cycle이 다르다.

따라서, CPI에 Instruction개수를 곱한 값들의 합이 Clock Cycles이 된다.

CPI는 명령어 타입마다 다르기 때문에,CPI와 Instruction count는 다 다르기 때문에 저렇게 다 곱해서 더해야지 정확한 Clock Cycles의 값이 나오게 되는 것이다.

그럼 평균값도 똑같다.

CPI의 평균 값은 Clock Cycles을 총 Instruction Count로 나누어주면 된다(그냥 위의 계산의 반대이다.)

여기서 Instruction Count / 총 Instruction Count 를 Relative Frequency라고 한다. 그럼 해당 명령어가 총 명령어에 사용된 비율을 알 수 있다.