귀염둥이의 메모

하이퍼 스레딩 (Hyper-Threading, HT) 인텔이 구현한 동시 멀티스레딩을 구현한 기술이다. 물리상 실행 장치 한 개에 가상 실행 장치 (Logical Core) 두 개를 할당해 성능을 높이려는 기술이다. 코어 한 개당 스레드가 두 개씩 추가되므로 OS는 물리적인 코어의 수 x 2로 코어의 수를 인식한다. 하이퍼 스레딩 성능 OS 상에서 멀티태스킹이 일어날 때, 대부분의 프로그램은 CPU 점유율이 몇 퍼센트에 불과할 정도로 매우 낮다(100%에 가깝게 사용하는 경우도 있음). 또한, 프로세스에 필요한 리소스 양은 진행 과정에 따라서 많기도 하고 적기도 하다. 첫 번째 그래프 2가지 작업이 시간의 흐름에 따라 하나의 프로세스에서 필요한 자원의 양을 나타냄 필요한 자원의 양이 많을 때도 있고, 적..

온프레미스 (On-Premise) SW 등의 솔루션을 클라우드와 같은 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치하여 운영하는 방식 전통적인 인프라 랙 (Rack) 네트워크 / 보안 장비 서버 스토리지 (Storage) 1. 랙 (Rack) 서버와 네트워크 장비를 수용하는 장비 IDC (Internet Data Center) 에 배치되어 있음 2. 네트워크 장비 L2 Switch : 서버가 연결되는 스위치 L3 Switch : 인터넷 회선이 연결되는 장비 (라우터 or L3 Switch) L4 Switch : 서버를 이중화 해주는 장비 (로드 밸런싱 장비 / Server Load Balancing) 3. 서버 서비스가 올라가는 장비 CPU, Memory, 디스크(HDD)를 가지고 있는 장..

파일 시스템은 구조화된 일련의 정보를 구성하는 파일과 디렉터리의 집합이다. 리눅스 시스템은 다양한 종류의 파일 시스템을 사용할 수 있다. 쉽게 말해서 파일 및 디렉터리를 저장하는 방식이다. 1) 디스크 기반 파일 시스템 (Disk-Based File System) 디스크 기반 파일 시스템은 하드디스크, CD-ROM 등을 기반으로 하는 파일 시스템이다. MINIX : UNIX의 한 갈래인 Minix에서 사용되던 파일시스템이다. 플로피 디스크 등 작은 크기의 저장소 장치로 사용되는 파일 시스템이다. EXT : 리눅스 초기 개발 시 리눅스에서 사용하기 위해 만들어진 확장 파일 시스템 (Extened File System)이다. 리눅스가 유닉스와 호환되도록 만들어졌기 때문에, 리눅스 파일 시스템도 유닉스의 파일..

REST (Representational State Transfer) 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것 자원(SW가 관리하는 모든 것)의 표현에 의해서 상태를 전달한다 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용한다 (웹의 장점을 최대한 활용할 수 있음) 자원을 URI를 통해서 명시한다 HTTP 메소드를 이용하여 자원에 대한 CRUD 연산을 적용한다 REST 구성 자원 (Resource) - URI 행위 (Verb)- HTTP 메소드 표현 (Representations) - JSON, XML ... REST의 특징 Uniform Interface URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행 HTTP 표준을 따르는 모든 플랫..

동시성(Concurrency) 동시에 실행되는 것처럼 보이는 것 논리적인 개념 싱글 코어에서 멀티 프로세스/쓰레드를 동작시키는 방식 병렬성(Parallelism) 실제로 동시에 여러 작업이 처리되는 것 물리적인 개념 멀티 코어에서 멀티 프로세스/쓰레드를 동작 시키는 방식 Single Core에서는 2개의 작업이 동시에 실행되는 것처럼 보이기 위해서, 번갈아 가면서 작업을 수행한다 다른 작업으로 바꿀 때는 내부적으로 Context Switch가 일어난다 Multi Core에서는 실제로 두 개의 작업이 동시에 처리가 된다 References https://seamless.tistory.com/42

Amazon EKS(Elastic Kubernetes Service)는 쿠버네티스를 제어하는 컨트롤 플레인(Control-Plane)을 제공하는 관리형 서비스이다. 쿠버네티스에서는 여러 컴포넌트들이 독립적이고 비동기로 동작하며 전체를 구성한다. 그래서 각각의 구성 요소를 정상적으로 동작시키기 위한 설정이나 유지, 운영 장애가 발생했을 때 대처가 까다롭다. EKS는 이러한 유지, 운영을 AWS에서 대신해준다. 쿠버네티스와 완전한 호환성을 갖고 있음 이미 구축된 쿠버네티스 클러스터에서 동작하는 애플리케이션을 수정하지 않고 동작시킬 수 있음 AWS 각종 서비스와 통합되고 있어 다른 서비스들과 연결하거나 기존 구조와 같은 환경으로 이용할 수 있다 VPC(Virtual Private Cloud)와 통합 일반적인 ..

Why Volume? 컨테이너는 기본적으로 stateless 앱 컨테이너를 사용한다. 상태가 없기 때문에 노드에 장애가 발생했을 때 다른 노드로 자유롭게 옮길 수 있는 장점을 가진다. 하지만 어떠한 이유로든 컨테이너가 실행되지 않거나 삭제되었을 때, 현재까지 저장된 데이터는 사라진다는 단점이 있다. 특성에 따라서 컨테이너에 문제가 발생하더라도 데이터 보존이 필요한 경우가 있다. 이런 상황에서 볼륨(Volume)을 사용한다. 예를 들어 MySQL 같은 DB는 컨테이너는 종료하거나 재시작했을 때 저장된 데이터가 사라지면 치명적이다. PV(Persistent Volume)를 사용하면 기존에 데이터를 저장했던 노드가 아닌 다른 노드에서 컨테이너를 재시작하더라도 데이터를 저장한 볼륨을 그대로 사용할 수 있다. 볼..

롤링 업데이트 (RollingUpdate) 디플로이먼트의 기본 배포 방법 배포된 전체 파드를 한꺼번에 교체하는 것이 아닌 일정 개수씩 교체하면서 배포하는 방식 파드를 하나씩 죽이고 새로 띄우는 순차적인 교체 방법 업데이트 프로세스 동안 두 가지 버전의 컨테이너가 동시에 실행되어서 버전 호환성 문제가 발생 가능 블루/그린 (Blue/Green) 기존에 실행된 파드 개수만큼 신규 파드를 모두 실행한다 신규 파드가 정상적으로 실행되면 한꺼번에 트래픽을 옮기는 방식 신버전과 구버전이 같이 존재하는 시간 없이 순간적인 교체 가능 롤링 업데이트보다 필요한 리소스 양이 많음 카나리 (Canary) 기존 버전을 유지한 채로 일부 버전만 신규 파드로 교체 (한꺼번에 전체 교체 X) 구버전과 신버전이 같이 존재한다 버그 ..

kubectl version : 버전 확인 kubectl cluster-info : 클러스터 정보 확인 kubectl run ~ : 단순히 파드를 실행할 때 (이미지 지정) kubectl expose ~ : 서비스를 명령어로 생성 kubectl create ~ : 컨트롤러를 명령어로 생성 kubectl apply ~ : 템플릿으로 재설정/생성 kubectl edit ~ : 동작 중인 설정을 변경할 때 사용 kubectl delete ~ : 리소스 제거 kubectl get ~ : 리소스 기본 정보 확인 kubectl describe ~ : 리소스 상세 정보 확인 kubectl explain ~ : 템플릿 속성 값 확인

레이블(Label) key-value 쌍으로 구성하며, 사용자가 클러스터 안에 오브젝트를 만들 때 메타데이터로 설정할 수 있다. 레이블이 생성된 다음에도 언제든지 수정이 가능하다. key는 쿠버네티스 안에서 컨트롤러들이 파드를 관리할 때 자신이 관리해야 할 파드를 구분하는 역할을 한다. 레이블만으로 관리 대상을 구분하기 때문에 특정 컨트롤러가 만든 파드라도 레이블을 변경하면 인식할 수 없다. 컨트롤러와 파드를 느슨하게 결합하는 특징 때문에 파드들을 유연하게 관리 가능하다. 특정 레이블을 선택할 때는 셀렉터(Selector)를 사용한다. 등호 기반은 '='또는 '==', '!=' 연산자를 사용하여 같은지 다른지 구분 가능하다. 레이블 설정 규칙 63글자를 넘지 않아야 함 시작과 끝 문자는 알파벳 대소문자 ..