히포

1. diskpart로 접속

• 시작 → 프로그램 및 파일 → cmd 검색
• cmd에서 아래 명령어 입력

  > diskpart

  

2. 디스크 리스트 출력

• 디스크 상태창에서 현재 본인이 사용하고 있는 하드디스크, SSD, USB 등을 출력

  > list disk

  

3. 디스크 선택

• USB 디스크는 디스크 1번임으로 disk 1을 선택

  > sel disk 1

  

4. 선택한 디스크를 청소

• 디스크 1을 선택한 후에 clean 명령어를 통해 디스크 용량 문제를 해결

  > clean

  

5. 선택한 디스크를 청소후 출력

6. 디스크 볼륨 설정

• 시작 → 프로그램 및 파일 검색 → 컴퓨터 관리 → 디스크 관리
• 디스크 1에 파티션이 할당 되지 않을 것을 확인 할 수 있음
  

  

7. 새 단순 볼륨을 통해 USB 디스크 파티션 할당

8. 디스크 포맷

• 새 단순 볼륨을 클릭한 후 아래의 그림이 나올 때까지 다음(N)을 클릭해도 상관없음
  

  

9. 완료

• Little's law에 의해 동일한 부하에서 응답시간 또는 지연시간이 낮을 수록 시스템 처리량이 높아짐
• 정해진 자원 내에서 시스템 성능을 높이기 위해 튜너들이 어플리케이션이나 SQL의 응답시간을 줄이는 노력을 하게 되는 것
• 성능 개선의 핵심은 응답시간을 낮추는 것
• 기존 Little's Law 법측을 활용하여 시스템의 성능 이론에도 동일하게 적용
• Little's law의 규칙을 기반으로 성능을 향상하려고 한다면, 낮은 response time을 만드는 것이 최우선임 → "Low response time makes high throughput"

시스템의 성능 측정 Little's law

1. Active users -> 실제 사용자 수
2. TPS : 초당 트랜잭션(Transactions per Second)
3. Response time -> 응답 시간

   Active users = TPS * Response time

   

시스템의 성능 측정 Little's law의 이해

• 1명의 사용자가 시스템에 요청을 보낼 때 응답이 1초에 처리 → 초당 처리건수(TPS)는 1건
• 초당 처리건수(TPS)가 1건이면 2명이 요청하였을 때 응답 시간은 2초가 발생
• 1명이 요청을 보낼 때 응답이 0.5초에 처리 → 초당 처리 건수(TPS)는 2건
• 2명이 요청을 보낼 때 응답이 0.5초에 처리 → 초당 처리 건수(TPS)는 4건
  
  
  

TPS(초당 트랜잭션)와 Response 계산

• 시스템 처리량(TPS을 계산하는 공식으로 변환 → 시스템 처리량은 사용자 수에 비례하고, 응답시간에 반비례

  TPS = Active users / Response time

• 응답시간(Response)으로 계산하는 공식으로 변환 → 응답시간은 사용자 수에 비례하고 시스템 처리량에 반비례

  Response time = Active users / TPS

  
  
  

스토리지 성능 컨셉에 맞게 변환

• Thread → I/O 부하를 일으키는 주체
• Latency(지연시간) → 스토리지의 응답시간
• IOPS(Input Output Operations per Second) → 초당 입출력 오퍼레이션 건수로 스토리지의 처리량

  IOPS = Threads / Latency

  
  
  

※ 기존 Little's law (리틀의 법칙) 개념

• Little's law (리틀의 법칙)는 고정 시스템에서 고객의 장기 평균 수가, 장기 평균 유효 도착률에 고객이 시스템에서 소비하는 평균 시간을 곱한 것
• John Little이 정리한 법칙으로 Little's Law의 규칙

  # L -> 상점에 있는 평균 고객 수
  # λ(람다) -> 대기열에 있는 사람 수
  # W -> 상점에 머무르는 시간
  L = λ W

1. GitOps를 도입하기 전과 GitOps를 도입한 후의 kubernetes의 배포 방식 차이

2. GitOps란

2.1. 개발자의 코드가 실제 서비스로 반영되기까지 많은 과정을 거쳐야함

1. Repository에 Push 후 CI를 통해 Docker Image로 빌드
2. Container Registry(ex: DockerHub)로 업로드
3. Kubernetes에 배포 방법 선택 후 kubernetes cluster에 배포
   

2.2. GitOps를 도입하기 전의 문제화 해결 과정

1. 사람마다 선호하는 배포 방식이 제각각이고 여러 소스(원천)로부터 Manifest가 변경됨
2. 이미지 태그를 1.1로 업데이트하여 배포했는데, 누군가가 1.0 버전의 Manifest 파일로 배포했다면 문제가 발생 가능
3. 여러 사람이 배포하기에 배포한 담당자를 파악하기 힘들고, 다시 1.1 버전으로 배포진행해야함
4. Manifest를 가져오는 소스를 Git Repository 한 곳으로 통일하는 방식으로 문제에 해결
5. Git Repository에 존재하는 Manifest 파일과 Kubernetes cluster에 존재하는 리소스의 현재 상태를 계속 비교하며 Sync 작업을 수행
6. 현재 Manifest에 정의한 리소스가 생성되지 않았으면, 생성하고, 일치하지 않는 경우 Spec에 맞도록 복구 작업을 수행
7. 모든 과정을 자동으로 진행하기에 사람이 배포에 개입할 여지를 최소화 → 더 이상 배포를 Imperative 방식이 아닌 Declarative 방식으로 수행
   
   
   

3. 단일 진실의 원천(Single source of truth; SSOT)이란

• 단일 진실의 원천은 "오직 진실(결과)이 오직 한가지의 원천(이유)에서 발생"하는 것을 의미
• 단일 진실의 원천에 대한 예시로, 어떤 아이가 울고 있으면(결과) 그것은 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문(이유)이라고 가정
  1. 넘어져서 우는 것도 아니고 혼나서 우는 것도 아니라 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문에 우는 것
  2. 반대로 아이스크림을 제대로 들고 있으면 항상 웃고, 아이가 웃는다면 이유는 칭찬을 받아서도 아니고 과자를 먹어서도 아니고 오직 아이스크림을 떨어뜨리지 않았기 때문임
     

     

     
     
     
     

4. 소프트웨어 배포 관점에서 단일 진실의 원천

4.1. 단일한 방법으로의 소프트웨어 배포

• 어떤 소프트웨어를 개발하여, 운영 환경에 반영할 때 다양한 방법을 통해서 배포 가능
• 예를 들어, 자바 WAR 파일을 운영 환경의 Tomcat 서버에 배포를 한다고 했을 때, scp를 이용하여 파일을 배포할 수도 있고 S3에 파일을 올려놓고 운영 서버에서 그것을 다운 받을 수도 있음
• 자동으로 배포를 하고 싶으면 ansible이나 chef 같은 툴을 이용하여 소프트웨어를 배포 가능
• 소프트웨어를 배포 방법이 다양하면 문제가 발생할 소지가 많아짐 → 사람마다 배포하는 방법이 달라 human error가 증가하게 될 수 있고 다양한 배포 방법이 서로 충돌할 여지 발생 가능
• 배포에서 충돌이 발생하는 human error 문제를 해결하기 위해서 GitOps는 소프트웨어 배포 과정을 체계적으로 관리하고 자동화하기 위해 모든 배포 정의를 한 곳에서 관리하고 한가지 방법으로 배포하는 것을 추구
  

4.2. 항상 원천(Git Repository)의 상태를 완벽히 반영하는 배포

• 위 아이스크림과 아이의 예시에서 아이가 아이스크림의 상태를 완벽하게 반영한다고 할 수 있음 → 아이스크림을 들고 있으면 아이는 울지 않고 아이스크림을 떨어뜨리면 아이가 울기 때문.
• 소프트웨어 배포 관점에서 보자면, 아이스크림은 배포 작업 정의서(어떻게 소프트웨어를 배포할지 기술한 문서)를 의미하고 아이는 실제 배포된 상태를 의미
• GitOps에서는 배포상태의 모습을 항상 Git Repository과 동일하게 맞출려고 노력

• “단일 진실의 원천(Single source of truth; SSOT)” 방법을 통해 얻을 수 있는 3가지 장점.
  1. 현재 배포환경의 상태를 쉽게 파악 가능 → 배포환경에 들어가서 상태를 파악할 필요 없이 Git Repository(배포 작업서)만 확인하면 쉽게 파악 가능
  2. 빠르게 배포 가능 → 단일한 방법으로 소프트웨어를 배포하여 표준화 시켰기 때문에 쉽게 배포 자동화 가능(빠르고 지속적인 배포를 가능)
  3. 안정적으로 운영 환경에 배포 가능 → 배포할 때 운영 환경에서 발생할 수 있는 human error를 최소화(배포를 관장하는 사람은 Git Repository의 내용만 잘 확인하면 문제 X)

• GitOps는 Git 저장소를 단일 진실의 원천으로 사용
  

  

• 쿠버네티스와 같이 선언형 (declarative description)명령은 Git 저장소(Git Repository)에 원하는 배포 형태를 선언하기만 하면 운영에 반영하기 쉬움
  
  
  

5. GitOps 방식의 이점

1. Manifest가 위치한 Repository만 신경쓰면 됨 → Manifest Repository에 권한이 있는 인원만 배포 과정에 참여할 수 있으며, Manifest 파일 변경 이력이 Git에 그대로 남기 때문에 추적이 용이
2. 배포 과정 단순화 가능 → 터미널에서 'kubectl' 명령어를 실행하거나, 스크립트를 수정하는 등의 작업이 없어지기 때문에 더욱 빠르고 자주 배포 가능
3. 사람의 부주의로 발생할 수 있는 Human Error을 줄일 수 있음
4. 서비스 업데이트는 해당 Manifest파일을 수정해서 Repository에 Push하는 것으로 실현하고, 새 버전에 문제가 있는 경우, 'git revert'를 해서 이전으로 쉽게 돌아갈 수 있음
   
   
   

6. GitOps에서 요구하는 원칙

• GitOps는 특정 소프트웨어나 프로덕트가 아닌 철학 혹은 방법론에 더 가까움

6.1. 선언형 배포 작업 정의서

• 배포 방법이 명령형 방식으로 정의된 것이 아니라 배포된 상태가 어떤 모양을 가져야 할지 선언되어 있는 방식으로 정의가 되어 있어야 함
• 사용자가 배포의 원하는 상태 (desired state)를 선언적으로 정의
• Git 저장소에 단일 진실의 원천 조건을 만족 가능
• 배포 작업 정의서가 선언형으로 되어 있으면 더 쉽게 배포할 수 있으며 문제 발생시, 롤백하기도 쉬움
• 장애 등으로 인해 손상된 배포 환경을 자가 치유하기 유리
  

6.2. Git을 이용한 배포 버전 관리

• Git에 모든 배포에 관련된 정보가 정의되어 있어야 함
• 각 버전이 Git 저장소에 기록이 되어야함
• 사용자는 쉽게 예전 버전으로 롤백을 하거나 새로운 버전으로 업그레이드 가능
  

6.3. 변경 사항 운영 반영 자동화

• 사용자는 Git 저장소에 선언형 정의서를 저장하게 되면 실제 배포가 일어나는 작업은 자동으로 이루어져야함
• 책임지는 주체가 ArgoCD와 같은 배포 주체(deploy operator)가 됨
• 자동으로 하는 경우 human error를 줄이고 지속적 빌드/배포를 가능하게 만듬
  

6.4. 자가 치유 및 이상 탐지

• 사용자가 원하는 배포 상태 (desired state)를 작성하게 되면 실제 배포 환경이 그에 맞게 유지되고 있는지 책임지는 것 또한 배포 주체(deploy operator)가 됨
• 배포를 관장하는 소프트웨어가 주체가 되어 현재 배포 상태를 확인하고 Git 저장소의 변경 사항 등이 없는지를 체크하여 운영 환경에 반영하는 역할을 함
• 원칙들을 가지고 소프트웨어를 배포하는 모든 Agent를 우리는 GitOps의 구현체 (Deploy Operator)라 부름.
• 현재 GitOps의 구현체로 ArgoCD 뿐만 아니라 Weaveworks flux, Codefresh, Jenkins X 등 다양한 소프트웨어들이 존재
  

• 애플리케이션 개발 단계를 자동화하여 애플리케이션 개발을 보다 짧은 주기로 고객에게 제공하는 방법
• 새로운 코드 통합으로 인해 개발 및 운영팀에서 발생하는 문제를 해결하는 솔루션
• CI/CD는 애플리케이션 통합, 테스트, 제공, 배포에 이르는 라이프사이클 전체에 걸쳐서 지속적인 자동화와 모니터링을 제공
• CI → 빌드/테스트 자동화
• CD → 배포 자동화

1. CI (Continuous Integration)

• Continuous Integration(지속적인 통합)의 약자
• 개발자를 위한 자동화 프로세스를 의미

• CI (Continuous Integration) 구축
  1. 애플리케이션 코드 변경사항이 정기적으로 빌드/테스트
  2. 공유 저장소에 병합되어 여러명의 개발자가 동시에 프로그램을 개발할 경우 서로 충돌할 수 있는 문제를 해결

2. CD (Continuous Delivery & Continuous Deployment)

• Continuous Delivery(지속적인 서비스제공), Continuous Deployment(지속적인 배포)의 약자
• 개발자들이 애플리케이션에 적용한 변경사항이 버그테스트를 거쳐 저장소에 자동 업로드 되는 것을 의미

• Continuous Delivery 의미를 가진 CD 구축
  1. 운영팀은 애플리케이션을 이 저장소에서 실시간 운영 환경으로 배포 가능
  2. 개발팀과 운영팀의 가시성 및 커뮤니케이션 문제를 해결해 줄 수 있음

• Continuous Deployment 의미를 가진 CD 구축
  1. 지속적인 배포로 개발자의 변경사항을 저장소에서 고객이 사용 가능한 운영환경까지 자동으로 릴리즈할 수 있음
  2. 애플리케이션 수동 배포 프로세스로 인한 프로세스 과부하 문제를 해결 가능

• 블록스토리지와 파일스토리지는 OS에서 동작
• 오브젝트 스토리지는 어플리케이션에서 동작
  
  
  

스토리지 유형에 따른 서로 다른 특징을 비교

파일스토리지

• 폴더(Directory)와 파일(File)로 이루어지는 논리적 계층구조를 갖는 스토리지 → 가장 일반적인 저장소 유형
• 각 파일(File)은 폴더(Directory)에 종속되며 폴더(Directory)도 다른 폴더(Directory)에 종속 가능
• 파일스토리지에서 파일은 폴더(Directory)별로 저장되어, 언제든지 꺼내어 수정 및 변경 가능
• 파일스토리지에서 파일을 찾으려면 어느 경로에 있는지 알고 있어야함
• 파일스토리지의 규모가 작은 경우 파일을 인덱싱하는데 어렵지 않지만, 규모가 큰 경우 파일을 인덱싱하는데 많은 시간과 노력이 소모
• NAS, DAS에서 사용 → 가장 오래되고 널리 사용되는 데이터 스토리지 시스템
  

  

• 파일 스토리지를 케비넷으로 생각하면 이해하기 쉬움
  1. 각각의 파일철들이 케비넷별로 저장되어있고 언제든 꺼내어 수정하거나 변경 가능
  2. 파일철을 찾으려면 어느 케비넷이 있는지 알고 있어야함
  3. 케비넷에 파일철이 많지 않다면 분류하고 정리하는데 큰 문제가없지만, 파일철들이 계속해서 늘어나면 늘어날수록 점점 분류하고 정리하는 데 많은 노력이 필요

• 파일 스토리지를 주차 타워로 표현하여도 이해하기 쉬움
  1. 주차 타워는 내 차를 타기 위해서는 주차타워가 한번 돌아가야함
  2. 주차가 많아지면 많아질수록 주차 타워가 깊어짐 → 차를 찾기가 힘듦

• 파일스토리지의 문제
  1. 파일스토리지에 파일을 저장하면 생성 날짜, 수정 날짜 및 파일 크기 등 첨부되는 메타데이터가 제한적
  2. 파일스토리지의 조직 스키마는 데이터 양이 늘어나면서 문제 발생 가능
  3. 파일과 폴더를 계속 추적하기 위해 파일 시스템에 대한 자원 요구가 증가해 성능이 떨어짐
  4. 파일스토리지의 구조적 문제는 단순히 파일 시스템에서 사용할 수 있는 저장 공간을 늘리는 것으로 해결 불가능
  5. 파일스토리지는 규모의 측면에서 잠재적인 문제가 있음에도, 업무 현장 및 중대형 기업에서 사용하는 개인용 컴퓨터와 서버에서 잘 사용
  6. 파일 스토리지는 일반적으로 하드 드라이브 및 네트워크 연결 스토리지(NAS) 시스템에 사용
     
     
     

블록스토리지

• 블록스토리지는 정해진 블록 안에 데이터를 저장
• 블록 스토리지는 데이터를 고정된 크기의 '덩어리' 또는 '블록'을 시퀀스로 처리 → 각각의 파일이나 오브젝트를 여러 블록에 분산 가능(cf. 파일 스토리는 파일을 하나의 데이터 단위)

• 블록스토리지는 블록들을 연속적으로 저장할 필요 X
  1. 사용자가 데이터를 요청할 때마다, 기본 스토리지 시스템에 데이터 블록을 병합하여 사용자의 요청을 처리
  2. 가장 편리한 곳에 블록을 저장 가능하기에 효율성이 매우 높음
  3. 데이터 블록은 고유 식별자를 부여
  4. 일부 데이터는 Linux 환경에 저장하고, 일부는 Windows 장치에 저장 가능
  5. 계층 구조가 필요하지 않아 블록은 서로 독립적으로 존재 가능

• 블록 스토리지는 읽어야 할 데이터의 경로가 하나만 있는 것이 아니기 때문에 데이터를 매우 빠르게 검색 가능 → 같은 파일의 데이터를 여러 디스크에서 읽을 수 있는 디스크 배열과 유사
• 블록 스토리지는 저장 영역 네트워크(SAN) 저장소에 사용
• 블록 스토리지는 파일 스토리지 시스템이 구축되는 기반으로 사용
• 대부분의 애플리케이션에서 오브젝트스토리 또는 파일스토리지에서 사용되고, 오브젝트스토리지와 파일스토리지를 구축하는 상위 계층으로 블록스토리지를 사용
• SQL에서 테이블을 만들때 각 칼럼별로 저장할 데이터를 설정 → 데이터 삽입도 설정한 값 범위안에서 저장
• 블록스토리지가 파일스토리지와 다른점은 파일스토리지는 1개의 경로만 갖는데 반하여 블록스토리지는 여러개의 경로를 가질 수 있음
• 낮은 IO(Input/Output) latency로 RDB와 같은 데이터베이스에 사용하기 적합
  

  

• BlockStorage를 주차장으로 표현하면 이해하기 쉬움
  1. 주차장이 꽉차면 더 이상 주차 불가능
  2. 더 이상 주차할 공간이 없으면 필요한만큼 주차장을 늘려놓아야합니다.

• 블록스토리지의 동작 원리 예시
  1. 블록스토리지는 컴퓨터의 C드라이브, D드라이브와 유사 → 맨처음 파티션을 나누어주고 그 공간안에서 사용 가능
  2. C드라이브와 D드라이브를 네트워크를 통해서 공유하고 여러 사용자가 해당 드라이브를 참조하는것과 유사 → 공유는 할 수 있지만 OS와의 연결은 한번에 1개만 가능
  3. 블록 스토리지는 데이터를 사용자의 환경에서 분리해 이를 쉽게 활용 가능 → 다양한 환경 전반에 분산하도록 설정
  4. 데이터 요청되면 기본 스토리지 소프트웨어가 데이터 블록을 다시 조합해 사용자에게 제공

• 블록 스토리지의 장점
  1. 단일 데이터 경로에 의존하지 않으므로 신속하게 검색 가능
  2. 각 블록은 독립적으로 존재하며 파티션으로 분할 가능 → 서로 다른 운영 체제에 액세스 가능
  3. 사용자는 자유롭게 데이터를 설정 가능 → 운영체제에 영향 X
  4. 데이터를 효율적이고 안정적으로 저장 가능 → 사용과 관리도 간편
  5. 대규모 트랜잭션을 수행하는 기업과 대용량 데이터베이스를 배포하는 기업에서도 원활하게 동작
  6. 더 많은 데이터를 저장해야 할수록 블록 스토리지를 사용하는 것이 더 유리

• 블록스토리지의 한계
  1. 블록 스토리지는 비용이 많이 발생
  2. 메타데이터를 처리하는 기능이 제한적
  3. 애플리케이션 또는 데이터베이스 수준으로 메타데이터를 다루어야함 → 비효율적
  4. 개발자나 시스템 관리자의 업무 부담이 늘어남
     
     
     

오브젝트 스토리지

• 오브젝트 스토리지는 '오브젝트(Object)'로 불리는 각각의 데이터 단위가 개별 단위로 저장되는 데이터 저장소 유형 → 오브젝트 스토리지 볼륨은 모듈 단위로 동작
• 오브젝트 스토리지는 물리적 제약이 없기 때문에 원하는 만큼 공간을 확장 가능

• 오브젝트 스토리지의 단일 리포지토리는 각각 독립적인 리포지토리로 아래 요소를 보유
  1. 데이터
     • 데이터는 오브젝트라 불리는 개별 단위로 나뉨
     • 서버의 블록이나 폴더에 파일을 보관하는 대신 단일 리포지토리에 보관
  2. 오브젝트가 분산 시스템에 존재하도록 허용하는 고유 식별자
     • 오브젝트 이름이 색인 테이블에서 '키' 역할 가능
     • 오브젝트 스토리지 시스템은 찾고 있는 오브젝트의 키(이름)만 알고 있으면 색인 테이블을 사용하여 빠르고 쉬운 검색이 가능
  3. 데이터를 설명하는 메타데이터를 보유
     • 메타데이터는 사용 기간, 개인 정보/보안 및 액세스 비상 대책 등 중요한 내용이 포함
     • 메타데이터 내용은 매우 상세 기록 가능 (영상 촬영 위치, 사용된 카메라 기종, 각 프레임에 출연한 배우 이름 등의 정보를 저장 가능)

• 오브젝트 스토리지는 논리적인 스토리지
  1. 오브젝트 스토리지는 S3나 Cloud Sotrage에서 폴더(Directory)를 만들거나 다른 버킷(bucket)으로 파일을 옮긴다고 하여 물리적인 변화가 있는 것이 아님 → 사용자에게 옮긴 것처럼 보여줌
  2. 오브젝트 스토리지는 키 값(Key Value)과 데이터(Data)만 저장
  3. 오브젝트는 PDF, 비디오, 오디오, 텍스트, 웹사이트 데이터나 기타 다른 파일 유형 등 모든 데이터 유형을 사용 가능
  4. 파일 스토리지와 달리, 오브젝트는 폴더(Directory) 계층 구조 없이 단일한 평면(flat) 구조로 저장

• 오브젝트 스토리지는 RESTFul Protocol(HTTP)를 이용 가능 → Get과 Post로 요청을 하면 원하는 파일을 받을 수 있음 (모든 언어로 HTTP API 사용 가능)
• 파일에 대해 가지고 있는 정보가 적기 때문에 파일이 아무리 많아져도 블록스토리지나 파일스토리지에 비해서 빠르게 작동
  

  

• Object Storage를 발렛으로 알아서 주차하는 것으로 표현하면 이해하기 쉬움
  1. 강남이나 판교에서 발렛 맡기면, 주차장의 공간을 효율적으로 사용하여 주차해줌
  2. 주차하는 기술도 일반적인 경우와 다르지만, 공간의 낭비가 하나도 없도록 주차를 해줌

• 오브젝트 스토리지 예시
  1. 발렛을 맡길때 자동차(데이터) 세워 두고 번호표만 전달해 줌
  2. 어디에 주차되어있는지 알 필요 X

• 오브젝트 스토리지 장점
  1. 평면 주소 지정 체계는 개별 오브젝트에 대한 접근이 빠르고 쉽다는 것을 의미
  2. 오브젝트는 정적 데이터에 적합한 스토리지 시스템 → 민첩성과 평면적 속성으로 인해 초대용량의 데이터로 확장 가능
  3. 비정형 데이터를 저장하기에도 좋음
  4. 오브젝트 스토리지는 클라우드 기반 저장소에서 일반적 → 확장하기도 쉬우므로 퍼블릭 클라우드 스토리지에 매우 적합
  5. 매우 높은 확장성과 신뢰성을 바탕으로 콘텐츠의 관리, 처리 및 배포에 사용
  6. 공간을 효율적으로 사용하기에 비용적으로 저렴함 → 사용만큼 비용을 지불하면 되므로 비용 효율적
  7. 사용만큼 비용을 지불하면 되므로 비용 효율적

• 오브젝트 스토리지 단점
  1. 파일 수정이 불가능 → 한번에 오브젝트 작성을 완료해야함
  2. 오브젝트 스토리지는 전통적인 데이터베이스와 잘 연동 X
  3. 파일이 수정될때 트랜잭션을 통해 일관성을 유지하기가 힘들기 때문에 덮어쓰는 방법을 이용
  4. 이미지나 동영상같이 수정이 잘 일어나지 않는 정적인 데이터를 호스팅할때 사용
  5. 내구성이 블록스토리지에 비해 떨어지기때문에 내구성이 중요한 데이터는 처리하기 힘듦
  6. 오브젝트 작성에 노력이 필요함
  7. 오브젝트 스토리지 API를 사용하여 애플리케이션 작성에 노력이 필요함
     

• 페이로드(payload)는 전송되는 데이터를 의미
• 데이터를 전송할 때, 헤더와 메타데이터, 에러 체크 비트 등과 같은 다양한 요소들을 함께 보내어, 데이터 전송의 효율과 안정성을 높히게 됨
• 보내고자 하는 데이터 자체를 의미하는 것을 페이로드라고 함
  
  
  

실생활 예시

• 우리가 택배 배송을 보내고 받을 때, 택배 물건이 페이로드
• 송장이나 박스, 뾱뾱이와 같은 완충재 등등은 부가적인 것으로 페이로드가 아님
  
  
  

위키피디아에 이해하기 좋은 예시

• json으로 보는 실제 데이터에서의 payload는 아래의 json에서 “data” 부분만 해당
• 그 이외의 데이터들은 전부 통신을 하는데 있어 용이하게 해주는 부차적인 정보들

  {
    "status" :
    "from": "localhost",
    "to": "http://melonicedlatte.com/chatroom/1",
    "method": "GET",
    "data":{ "message" : "There is a cutty dog!" }
  }

  
  
  

Payload 참고 그림

※ 참고) 페이로드(payload)의 유래

• 운송업에서 비롯된 것으로 지급(pay)해야 하는 적화물(load)을 의미
• 예를 들어, 유조선 트럭이 20톤의 기름을 운반한다면 트럭의 총 무게는 차체, 운전자 등의 무게 때문에 기름의 무게보다 더 무겁게 된다.
• 모든 무게를 운송하는데 비용이 발생하지만, 고객은 오로지 기름의 무게에만 비용을 지급
  ‘pay-load’란 말이 나온 것
  

• HLS 스트리밍은 적응형 비트 스트리밍(Adaptive bitrate streaming) 기술
• 비디오가 HLS로 인코딩되면 여러 대역폭 및 해상도로 여러 파일이 만들어짐
• 파일은 mpg2_ts 코덱을 사용하여 인코딩
• 스트림은 화면 크기와 사용 가능한 대역폭에 따라 M3u8 색인 파일을 사용하여 실시간으로 클라이언트에 매핑
  
  
  

M3U8 파일을 열고, 편집하고, 변환하는 방법

• M3U8 파일 확장명을 가진 파일은 UTF-8 인코딩 오디오 재생 목록 파일
• 미디어 파일의 위치를 설명하기 위해 오디오 및 비디오 플레이어에서 모두 사용할 수 있는 일반 텍스트 파일 → 하나의 M3U8 파일은 인터넷 라디오 방송국의 온라인 파일에 대한 참조를 제공 가능
• 컴퓨터에 다른 음악 파일을 만들어 자신만의 음악이나 일련의 비디오를 재생 목록 생성 가능
• M3U8 파일은 절대 경로, 상대 경로 및 URL을 사용하여 특정 미디어 파일 및 / 또는 미디어 파일의 전체 폴더를 참조 가능
• 주석으로 M3U8 파일의 다른 텍스트 정보를 표시 가능
• M3U8 파일과 유사한 M3U도 UTF-8 문자 인코딩을 사용할 수 있지만 다른 문자 인코딩도 포함 가능
• .M3U8 파일 확장명은 파일이 실제로 UTF-8 문자 인코딩을 사용하고 있음을 나타냄
  
  
  

M3U8 파일을 여는 방법

• M3U8 파일은 Windows의 메모장을 포함한 대부분의 텍스트 편집기에서 편집하고 읽을 수 있음
• 메모장에서이 M3U8 파일을 열면 파일 참조만 읽을 수 있음
• 텍스트 편집기가 미디어 플레이어 또는 미디어 관리 소프트웨어 프로그램과 동일하지 않기 때문에 음악 파일을 실제로 재생 불가능

1. 메모장에 M3U8 파일 내용

• VLC, Apple의 iTunes, Windows Media Player 및 Songbird는 M3U8 파일을 열고 사용할 수있는 프로그램의 몇 가지 예
• Linux에서 M3U8 파일을 여는 방법은 XMMS
  

  

  
  

2. VLC에서 Open한 M3U8 파일

VLC로 열면 텍스트 파일에서 참조 된 모든 음악 파일을 수집하여 재생을 위해 미디어 플레이어에 로드

3. 온라인에서 Open한 M3U8 파일

• M3U8 파일을 온라인으로 열 수있는 빠른 방법은 HSLPlayer.net을 이용
• 컴퓨터나 다른 장치에 M3U8 파일이 저장된 경우 웹 사이트는 작동 X
• M3U8 파일에 대한 URL이 있고 참조하는 파일이 온라인 상태인 경우에만 HSLPlayer.net을 사용 가능
• HSLPlayer.net을 이용하면 M3U8 파일 생성 가능 → VLC에 많은 파일을로드하는 경우 미디어> 파일에 재생 목록 저장 (옵션을 사용하여 M3U8 파일을 생성 가능)
  
  
  

M3U8 파일을 변환하는 방법

• M3U8을 MP4나 MP3 또는 다른 미디어 형식으로 변환하려면 M3U8 파일이 일반 텍스트 파일이라는 것을 이해 필요 → M3U8 파일은 재생할 수있는 텍스트는 포함 X
• M3U8이 언급하는 오디오 또는 비디오 파일을 MP4 to AVI 변환기 나 WAV to MP3 변환기와 같은 다른 오디오 / 비디오 파일 형식으로 변환하거나 변환 할 수있는 파일 변환기가 필요
  
  
  

• 운영체제의 페이지 교체 알고리즘 중 하나
• 페이지를 교체할 때 가장 오랫동안 사용되지 않은 페이지를 교체 대상으로 삼는 기법

LRU Cache

• LRU Cache는 캐시에 공간이 부족할 때 가장 오랫동안 사용하지 않은 항목을 제거하고 새로운 녀석을 배치하는 형식으로 동작
• LRU Cache의 사용 관점 → '오랫동안 사용되지 않은 항목은 앞으로도 사용되지 않을 가능성이 높기에, 가장 오랫동안 참조되지 않은 녀석을 캐시에서 제거하자'
• LRU Cache를 통해 캐시 메모리의 히트율을 높이는 것은 입증됐으며, 현재 가장 많이 사용되는 알고리즘 중 하나임

구현 방식

• LRU Cache 의 구현은 Double Linked List를 이용
• Head에 가까운 데이터일수록 최근에 사용된 데이터
• Tail에 가까울 수록 오랫동안 사용되지 않은 데이터로 간주
• 새로운 데이터를 삽입할 때, Tail 값을 가장 먼저 삭제시키고 Head에 데이터를 삽입
• 캐시에 적재된 어떤 데이터를 사용한 경우, 해당 데이터를 Head로 옮겨 가장 최근에 사용된 값임을 표시 → 삭제 우선순위에서 멀어짐
• 캐시 교체 시간 복잡도 → O(1)

LRU Cache 순서 방식 도식화

참고 자료

• https://velog.io/@haero_kim/LRU-Cache-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0