데이터센터프로그래밍26(1)

26-Storage(이론)

🐶 지난 시간에 배운 내용

• Stateless application
  : 메모리 or 디스크 or 파일 or 데이터베이스에 대한 정보를 저장하는 곳이 없는 것
  : request(요청)을 받았을 때, 과거의 기록을 기반으로 대응하는 것이 아닌, 때마다 새로운 요청으로 처리하는 것
• Stateful application
  : request가 들어오면, 과거의 이력을 기반으로 해서 응답이 바뀔 수 있음
  : 메모리 or 디스크 or 파일 or 데이터베이스에 대한 정보를 저장하고, 요청을 받았을 때 응답할 때 기존(과거)의 정보들을 활용하여 응답을 만들어 주는 것

🟤 오늘 공부할 내용

• volume이 무엇인지?
• volume의 중요성?
  : 컨테이너가 죽으면, 안에 있는 모든것이 사라지기 때문에 컨테이너 밖에 무언가 대처를 해야지 컨테이너가 죽더라도 작업하던 데이터가 살아있을 수 있음
  : 컨테이너가 수명이 있기 때문에 컨테이너가 죽었다가 살아날때 데이터가 보존되어야 할 때
  : 컨테이너들의 정보교환 가능
• volume의 타입들이 무엇인지?
• volume을 언제 사용하는지?

🟤 Storage가 무엇인지?

• 도커와 같은 컨테이너를 기반으로 해서 쿠버네티스가 관리를 하는 것
• 컨테이너 안에 있는 것들은 컨테이너가 사라지면 모든 것이 사라짐
• 컨테이너가 비정상종료를 당하게 되면, 컨테이너 안에 저장하는 행위들을 못할 수 있음. 이런경우, replication or Deployment Controller가 쿠버네티스의 경우, pod을 다시 부활을 시켜줌
• 문제는.. 임시로 만들어져 있는 컨테이너 or pod에 있는 것들이 작업을 하다가 중지가 되면 날라가는 경우가 발생함
• 😀 따라서, 수명이 임시적이고 죽었다 살아날 수 있는 컨테이너로 부터 데이터를 보고할 필요가 있음
• 컨테이너가 비정상적으로 살았다-죽었다, 죽었다-살았다 할 수 있는 있는 점을 감안하여 데이터는 여기로부터 분리되어 보관이 되어야함
• 컨테이너들이 정보를 공유하는 경우가 필요함. 실제로 동작할 때, 개별 컨테이너들이 각각 독립적으로 서로 interaction도 없이 동작한다는 것은 넌센스임.
• 😀 따라서, 컨테이너들은 정보를 공유하게 되어있음. 그때, 어떠한 형태로든 파일의 성격을 띄는데 물리적으로는 컴퓨터 메모리 or 디스크 or 데이터베이스를 사용하여 파일형태의 정보를 공유할 필요가 있음
• 😀 👏 따라서, (1) 컨테이너들이 죽었다-살아난다 살았다-죽었다가 함 (2) 컨테이너들이 정보를 공유할 필요가 있음. 1-2번 이유로 의해 volume, 즉 Storage를 사용함

🟤 왜 Storage인가?

• (1) Data persistency(지속가능한 데이터) 컨테이너가 죽더라도 데이터가 보관이 되어야함
• (2) Shared resources 복수의 컨테이너들이 데이터들을 주고받아야(교환, 공유(메모리 or 디스크 or 파일 or 데이터베이스)해야함)함

🟤 volume이 무엇인가?

• Storage들을 기술적으로 구현하기 위해 volume을 사용함
• 도커에서도 yaml 파일을 만들때, volume을 사용했었음. 젠킨스를 공부할때, volume을 만들어서 젠킨스의 데이터베이스 정보를 그곳에 저장했었음. 2개 이상의 젠킨스가 공유, 밖에서 정보를 볼 수 있었음.
• volume은 도커와 쿠버네티스에서 operation과 기본컨셉은 거의 동일함
• 😀 따라서, volume은 대부분 directory 형태로 띄게 만드는것을 확인 했었음. 컨테이너가 위치한 곳에 같은 node안에 있을 수 있고, 원격으로 떨어질 수 있음(물리적인 위치가 중요하지 않음).
• 😀 즉, directory한 형태로 volume을 정의한 것을 볼 수 있었음
• volume은 다양한 형태로 존재 할 수 있음 (directory가 위치하는 곳, medium 정의할 수 있음: 크게 나누면 컴퓨터 메모리를 사용하는 메모리인지, 파일형태인지? 데이터베이스인지?) 그리고 어떤 컨텐츠를 저장할 것인지(주로 다루는 데이터는 테이블 형태임)

🟤 Types of volumes

• awsElasticBlockStore (아마존이 제공하는 volume)
• azuerDisk (마이크로소프트 azuer data disk)
• azuerFile (마이크로소프트 azuer file volume과 연동)
• cephfs (오픈소스, 클라우드 컴퓨팅 프로그램들이 본인의 디스크를 가상화함)
• cinder (OpenStack이라고 부르는 클라우드 컴퓨터 SW의 volume과 연결할 수 있음)
• configMap (configuration 데이터 중심으로 가져옴)
• emptyDir (pod이 node에 배정이 되어 cration 될때, 만들어지는 임시저장 공간: 컨테이너가 문제가 발생하여 죽더라도, pod 전체가 node에서 없어지지 않음. 즉, 컨테이너는 죽더라도 pod안에 있는 컨테이너들은 사용가능)
• 참고 : https://kubernetes.io/docs/concepts/storage/

🐶 Storage를 크게 3가지로 구분

• (1) 입력으로 줘야하는 데이터에 대한 Storage는 특성이 다룰 수 있음
• (2) 운영중에 사용하는 데이터 Storage도 다룰 수 있음
• (3) 작업을 마친후, final 형태로 받거나, 작업이 끝난 상태에서 인수해야하는 데이터의 형태도 다룰 수 있음

🟤 emptyDir

• 기본적인 쿠버네티스의 저장 방법
• node에 pod이 배정이 되고, emptyDir를 volume으로 정의하면, 다시 생기면서 pod과 함께 동일하게 감
• 이름이 emptyDir인 이유는 디렉토리 처럼되어있기 때문, file structure, file system와 같이 컴퓨터 디스크에 저장하면 디렉토리 아키텍쳐를 따름. pod이 살아났을 때, 비워있다가 중간에
  채워진다는 것은 어딘가에서 가져오는 것보다는 pod이 살아나면서 필요한 데이터들을 생성하거나, 스스로 가져와서 저장하는 형태가 됨. 결국, pod과 수명을 같이하니, 작업이 마쳐지기 전에 다른곳으로 결과가 전달이 되어야함 (임시용도)
• pod과 수명을 같이하는 것이지, 컨테이너와 수명을 같이 하는 것이 아님!
• 😀 따라서, pod 안에 있는 컨테이너들이 접속 & 공유가 가능함. pod 안에 컨테이너가 죽더라도 emptyDir의 정보는 살아있음 (pod과 수명을 같이 한다는 점이 장점임)
• pod 안의 컨테이너들은 읽고, 쓰는 것들이 가능함. 의미있는 것으로 pod들을 하나로 묶었고, 컨테이너들이 있으니 이들끼리 정보를 주고받는데 디렉토리 volume 사용하는 것에 문제가 없음. pod 안에 컨테이너들이 살아나는 시점에서 쓰고, 읽고 하는것들 그리고 pod이 끝났을 때, 없어져도 되거나 어딘가에 저장하는 것들 모두 emptyDir 로 할 수 있음
• 그러나, pod 자체가 node로 부터 죽는 일이 벌어지면, 사라짐

🟤 emptyDir 일부 용도

• 디스크 기반의 병합 종류와 같이 스크레치 공간 (임시용도)
• 충돌로부터 복구하기 위해 긴 계산을 검사점으로 지정 (긴 계산을 할 때)
• 웹 서버 컨테이너가 데이터를 처리하는 동안 컨텐츠 매니저 컨테이너가 가져오는 파일을 보관
• 👏 node가 무엇인가에 따라 disk or SSD or network storage가 될 수 있음 (지정가능)
• 👏 컴퓨터 메모리에 쓰기 때문에 빠름