diff --git "a/ETC/CI, CD\353\236\200.md" "b/ETC/CI, CD\353\236\200.md" new file mode 100644 index 0000000..1f556c6 --- /dev/null +++ "b/ETC/CI, CD\353\236\200.md" @@ -0,0 +1,62 @@ +# CI/CD란 + +## 요약 + +> 애플리케이션의 개발 단계를 자동화하여 짧은 주기로 고객에게 애플리케이션을 제공하는 방법 + +## CI/CD가 나온 배경 + +- 모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기위해 나타난 개념 +- 분업과 협업의 과정에서 코드의 Merge 과정은 까다롭고, 테스트하는데 큰 자원을 소비되게 된다. 이 문제를 해결하기 위해 도입 +- 개발 브랜치가 일정 기간 이상 이용되면, 통합의 어려움은 커지고 충돌 해결에 들어가는 시간이 길어지고 오류 발생 위험이 커진다.
이러한 단점을 극복하고자 변동 내용의 반영 빈도를 늘리는 **자동화**가 등장 + +## CI의 정의 + +- **지속적인 통합(Continuous Integration)** +- 어플리케이션의 **새로운 코드 변경 사항**이 정기적으로 **빌드 및 자동 테스트** 되어 공유 레포지토리에 **통합(병합)**하는 것 +- 개발자를 위한 자동화 프로세스(여러명의 개발자간의 코드 충돌을 방지하기 위한 목적) +- 자동화된 테스트에서 **동작을 확인**하고 변경으로 인해 문제가 생기는 부분이 발견되면 CI를 통해 빠르게 수정 가능 +- 버그를 신속히 찾아 해결하고 소프트웨어 품질 개선, 새로운 업데이트의 검증 및 릴리즈 시간 단축시키는 것이 핵심 목표 + +### CI를 만드는 데 필요한 4가지 규칙 + +- 모든 소스 코드가 있고 누구나 현재 소스(및 이전 버전)를 얻을 수 있는 단일 장소 유지할 것 +- 누구나 단일 명령을 사용하여 소스에서 시스템을 빌드할 수 있도록 빌드 프로세스를 자동화 할 것 + +- 단일 명령으로 언제든지 시스템에서 우수한 테스트 모음을 실행할 수 있도록 테스트 자동화할 것 +- 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것 + +> 이 중 가장 중요한 것이 **테스팅 자동화**!!
지속적인 통합을 하기 위해서는 무엇보다 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있어야만 한다. + +## CD의 정의 + +- **지속적인 서비스제공(Continuous Delivery)** or **지속적인 배포(Continuous Deployment)** + - **지속적인 서비스제공(Continuous Delivery)** + - 공유 레포지토리로 자동으로 Release 하는 것 + - 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포 가능 (**수동적 배포**) + - 프로덕션 환경으로 배포할 준비가 되어 있는 **코드베이스를 확보**하는 것이 목표 + - **지속적인 배포(Continuous Deployment)** + - 프로덱션 레벨까지 자동으로 deploy 하는 것 + - 애플리케이션을 프로덕션으로 릴리스하는 작업을 **자동화** + - 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 애플리케이션을 **자동으로 실행**할 수 있는 것을 의미 +- 간단히 말하면 **배포 자동화 과정** +- 서버가 많을 경우 개발자가 일일이 배포를 진행하지 않아도 되므로, 리소스가 낭비되지 않는다. + +![CI/CD flow](https://www.redhat.com/cms/managed-files/styles/wysiwyg_full_width/s3/ci-cd-flow-desktop_edited_0.png?itok=TzgJwj6p) + +## CI/CD 종류 + +- Jenkins +- CircleCI +- TravisCI +- Github Actions + +등.. + +## 참고 + +- https://www.youtube.com/watch?v=0Emq5FypiMM&t=10s + +- https://www.redhat.com/ko/topics/devops/what-is-ci-cd +- https://devuna.tistory.com/56 +- https://www.martinfowler.com/articles/originalContinuousIntegration.html \ No newline at end of file diff --git a/Network/Nginx.md b/Network/Nginx.md new file mode 100644 index 0000000..26bf701 --- /dev/null +++ b/Network/Nginx.md @@ -0,0 +1,133 @@ +# Nginx + +## Nginx란? + +간단하게 말하면 **트래픽이 많은** 웹사이트의 **확장성을 위해 개발된 경량 웹 서버**이다. + +Nginx가 등장하기 전에는 Apache를 웹서버로 많이 사용하였지만 1999년 이후 컴퓨터 보급이 증가하면서 하나의 서버에 동시에 몰리는 커넥션이 많아졌다. 이 때 하나의 서버에 몰린 커넥션이 너무 많아 더 이상 커넥션을 형성하지 못하는 문제가 발생(=**C10K 문제**)했는데 이것을 해결하기 위해 등장했다. + +Nginx는 요청에 응답하기 위해 **비동기 이벤트 기반**으로 더 **적은 자원의 사용**으로 **가벼움과 높은 성능**을 목표로 한다. 또한, Apache보다 동작이 단순하고 전달자 역할만 하기 때문에 **동시접속 처리에 특화**되어 있다. + +클라이언트로부터 요청을 받았을 때 요청에 맞는 정적 파일을 응답해주는 HTTP Web Server로 활용되기도 하고, Reverse Proxy Server로 활용하여 WAS 서버의 부하를 줄일 수 있는 로드 밸런서로 활용되기도 한다. + +> 🔎 **비동기 처리 방식 vs 동기 처리 방식** +> +> - 동기(Synchronous) : A가 B에게 데이터를 요청했을 때, 이 요청에 따른 응답을 주어야만 A가 다시 작업 처리가 가능 (하나의 요청, 하나의 작업에 충실) +> - 비동기(Asynchronous) : A의 요청을 B가 즉시 주지 않아도, A의 유휴시간으로 또 다른 작업 처리가 가능한 방식 + +> 💡 **비동기 이벤트 기반(Event-Driven) 방식의 특징** +> +> - **요청을 하나의 Event**라 보고 **Event Handler로 관리**를 하기 때문에 **메모리의 낭비가 적다** +> - 부하에 대한 예측 가능성을 제공한다 + +## Reverse Proxy + +리버스 프록시(Reverse Proxy)란 중계 기능을 하는 서버로, 클라이언트와 웹서버 사이에 존재하는 서버이다. + +클라이언트가 서버를 호출할 때 직접 서버에 접근하는 것이 아니라 리버스 프록시 서버를 호출하게 되고, 리버스 프록시 서버가 웹서버에게 요청을 하고 응답을 받아 클라이언트에 전달한다. + +웹서버 앞에서 클라이언트 요청을 대신 받는 역할을 수행하다 보니 클라이언트는 직접적으로 실제 서버에는 통신할 수 없다는 특징을 가지게 된다. + +그렇다보니 몇가지의 큰 이점이 주어지게 된다. + +### 1. 로드밸런싱 + +서버에 가해지는 **부하를 분산해주는 역할**로, 이용자가 많아서 발생하는 요청이 많을 때 기존 하나의 서버에서 이를 모두 처리하도록 성능을 높이는 것(`Scale up`)이 아니라 **여러대의 서버를 이용하여 요청을 처리**(`Scale out`)한다. 이때 서버의 로드율과 부하량 등을 고려하여 **적절하게 서버들에게 분산 처리하는 것**을 **로드 밸러싱**이라고 한다. + +하나의 서버가 멈추더라도 서비스 중단 없이 다른 서버가 서비스를 계속 유지할 수 있는 **무중단 배포가 가능하다**는 장점이 있다. + +### 2. 보안 + +외부 사용자로부터 내부망에 있는 서버의 존재를 숨길 수 있다. + +모든 요청은 리버스 프록시 서버에서 받기 때문에 실제 서버의 IP 주소를 필요로 하지 않으며, DDos와 같은 공격이 들어와도 Nginx를 공격할 뿐 실제 서버에는 공격이 들어온는 것을 막을 수 있다. + +### 3. 캐싱 + +NGINX는 콘텐츠를 캐싱할 수 있어 결과를 더 빠르게 응답하여 성능을 높일 수 있다. + +## Apache와의 비교 + +nginx와는 다르게 **프로세스 기반 접근 방식**으로 하나의 스레드가 하나의 요청을 처리하는 구조를 가진다. (환경에 따라 Prefork 방식과 Worker 방식 선택 가능) + +이 구조는 클라이언트 하나당 스레드 하나를 사용하기 때문에 클라이언트가 많아질수록 계속해서 스레드가 생성되게 된다. 즉, 메모리 낭비가 심하고 문맥 교환 시 비용이 든다. 또한, 프로세스가 blocking 되면 요청을 처리하지 못하고 이전 요청을 처리하기 전까지 대기상태가 된다. + +그러나 Nginx는 비동기식 구조이기 때문에 모든 클라이언트의 요청을 **병렬로 처리**한다. **싱글 프로세스**이며 event는 쓰레드가 아닌 event Handler가 처리한다.
따라서 쓰레드의 사용이 적으므로 Nginx의 서버 자원 활용 능력이 더 좋다고 할 수 있다. + +## Nginx 기본 환경 설정 + +Nginx는 환경 설정 텍스트 파일로 여러 가지 값을 지정해 Nginx 설정을 할 수 있도록 지원한다. + +> Nginx의 메인 설정 파일 경로는 `/etc/nginx/nginx.conf` + +```nginx +user nginx; +worker_processes 1; + +error_log /var/log/nginx/error.log warn; +pid /var/run/nginx.pid; + +events { + worker_connections 1024; +} +http { + include mime.types; + server { + listen 80; + location / { + root html; + index index.html index.htm; + } + } +} +``` + +1. Core 모듈 + + 코어 모듈은 대부분 환경 설정 파일의 최상단에 위치하며 한번만 사용할 수 있다. nginx의 기본적인 동작 방식을 정의한다. + + - `user` : Nginx 프로세스가 실행되는 권한 + - `worker_processes` : NGINX 프로세스 실행 가능 수 + + - `pid` : NGINX 마스터 프로세스 ID 정보가 저장 + +2. events + + 주로 네트워크 동작에 관련된 설정하는 영역으로, 비동기 이벤트 처리 방식에 대한 옵션을 설정한다. + + - `worker_connections` : 하나의 프로세스가 처리할 수 있는 커넥션의 수 + +3. http 블록 + + 웹서버에 대한 동작을 설정하는 영역으로, server 블록과 location 블록의 루트 블록이다. + +4. server 블록 + + 하나의 웹사이트를 설정하는 데 사용된다. 가상 호스팅의 개념으로 http 블록 안에서만 사용할 수 있다. + +5. location 블록 + + server 블록 내에서 특정 URL을 처리하는 방법을 정의한다. + +### Reverse Proxy 설정 + +```nginx +http { + server { + listen 80; + location / { + proxy_pass http://127.0.0.1:8081; + } + } +} +``` + +/ 경로로 요청이 들어왔을 때 (하위 경로도 포함) `proxy_pass`로 프록시 서버로 전달하도록 한다. + +## 참고 + +- https://velog.io/@kimjiwonpg98/Nginx-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EA%B5%AC%EC%B6%95#-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98-%EC%A2%85%EB%A5%98 + +- https://www.youtube.com/watch?v=6FAwAXXj5N0 +- https://kanoos-stu.tistory.com/entry/Nginx +- https://prohannah.tistory.com/136 \ No newline at end of file diff --git "a/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" "b/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" new file mode 100644 index 0000000..e627822 --- /dev/null +++ "b/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" @@ -0,0 +1,156 @@ +# 프로그램, 프로세스, 스레드 + +> - 프로그램이란 특정 작업을 수행하기 위한 실행파일이다. 실행파일을 클릭했을 때 메모리 할당이 이루어지고, 이 메모리공간으로 코드가 올라간다. 이 순간부터 프로세스이다. +> - 프로세스는 OS로부터 자원을 할당받는 실행되고 있는 프로그램의 인스턴스이다. 각각 독립된 메모리 영역(Code, Data, Stack, Heap 구조) 등을 할당받는다. +> - 스레드는 프로세스의 가장 작은 실행단위로, 프로세스가 할당받은 자원을 이용한다. 프로세스 내에서 각각 stack과 PC 레지스터만 따로 할당받고 Code, Data, Heap 영역은 프로세스 내에 쓰레드끼리 공유하면서 실행된다. +> - 스레드를 사용하면 응답시간 단축, 빠른 통신과 비용적음, 빠른 문맥 교환, 시스템 처리량을 향상시킬 수 있지만, 스레드의 자원 공유는 동기화 문제에 신경을 써야하며 멀티스레드 프로그래밍은 구현과 디버깅이 어렵다는 문제점이 있다. + +## 프로그램(Programe)이란? + +- **특정 작업을 수행하기 위해** 작성된 일련의 지침을 포함하는 **실행 파일** + +- 컴퓨터의 주 메모리에 저장되지 않고, 디스크 또는 컴퓨터의 **보조 메모리에 저장**된다. + +- 프로그램은 주 메모리에서 읽고 커널에 의해 실행된다 + + ex) chrome.exe (웹 페이지 보기), notepad.exe (텍스트 파일 편집) + +- **특징** + - **수동적(정적) 개체(passive entity)**. 실행할 명령어 그룹을 저장.
당장 실행파일을 열어보면 다양한 명령어가 적혀있는 것을 알 수 있다. 이러한 명령어를 그룹으로 모아저 저장하는 것이 프로그램! + - 수동으로 **삭제할 때까지 메모리에 저장**된다. + - 프로그램은 **실행 없이 어떤 작업도 수행 불가능.** + +## 프로세스(Process)란? + +> program is in execution (실행 중인 프로그램) + +- 메모리에 올라와 **실행되고 있는 프로그램의 인스턴스(독립적인 개체)** + +- 프로그램이 실행되는 실행 단위 + +- 프로그램 실행 중에 생성되어 **주 메모리에 load**된다. + + ex) google 크롬 아이콘을 더블 클릭하면 크롬 프로그램을 실행하는 프로세스가 시작된다. + +- **특징** + + - **능동적(동적) 개체(active entity)**. 응용 프로그램의 목적을 수행함 + - **수명이 매우 제한적**. 작업이 완료되면 종료된다. + - 프로세스에는 OS로부터 **실행에 필요한 자원을 할당**받는다.
ex) 파일 디스크립터(file descriptors), 네트워크 포트, cpu시간, 메모리 영역(Code, Data, Stack, Heap 구조) + - 여러 프로세스가 동일한 프로그램과 관련될 수 있다.
ex) 메모장 프로그램의 여러 인스턴스 실행 가능 (각 인스턴스 = 프로세스) + - 프로세스에 대한 정보는 **PCB(Process Control Block)**에 저장된다. + +### PCB(Process Control Block) + +> 특정 프로세스에 대한 중요한 정보를 저장하고 있는 운영체제의 자료구조 + +- 사용자가 프로세스를 생성할 때마다 운영체제는 해당 프로세스에 해당하는 PCB를 생성한다. + +- **[PCB]에 저장되는 정보** + +| 이름 | 정의 | +| -------------------------------------- | ------------------------------------------------------------ | +| 프로세스 식별자 (Process-Id, PID) | 프로세스 식별 번호 | +| 프로세스 상태 (Process state) | new, ready, running, waiting, terminated 등의 상태를 저장 | +| 프로세스 우선순위 (Process Priority) | 수명, 소비한 자원 등으로 우선순위 나눔
숫자 값이 작을수록 해당 프로세스의 우선 순위 증가 | +| 회계정보 (Accounting Information) | 사용된 CPU 양과 시간, 시간 제한, 계정 번호 등 제공 | +| 프로그램 카운터 (Program Counter, PC) | 프로세스가 다음에 실행할 명령어의 주소 저장 | +| CPU 레지스터 (CPU Registers) | 인터럽트 발생 or 프로세스 간 문맥 교환 발생 시 임시 정보 저장. | +| PCB 포인터 (PCB Pointers) | 프로세스 상태가 ready인 다음 PCB 주소 저장 | +| 열린 파일 목록 (List of Open Files) | 프로그램이 실행되는 동안 필요한 모든 파일 정보 저장 | +| I/O 상태 정보 (I/O status Information) | 프로세스에 할당된 입출력 장치 목록 저장 | + +## 프로세스 상태 (Process State) + +![프로세스_상태도](https://github.com/KJY97/Note/blob/main/img/OS/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4_%EC%83%81%ED%83%9C%EB%8F%84.png?raw=true) + +- **New** : 프로세스가 생성중인 상태 + +- **Running** : CPU를 잡고 명령어(instruction)를 수행중인 상태 +- **Ready** : CPU를 기다리는 상태 (다른 조건을 다 만족하고 CPU만 얻으면 되는 상태를 의미) +- **Blocked(wait, sleep)** : CPU를 주어도 당장 명령어(instruction)을 수행할 수 없는 상태 + - Process 자신이 요청한 event(예: I/O)가 즉시 만족되지 않아 이를 기다리는 상태 + - ex) 디스크에서 file을 읽어와야 하는 경우 +- **Terminated** : 수행(execution)이 끝난 상태 + +## 프로그램과 프로세스 차이점 + +| | 프로그램 | 프로세스 | +| --------- | ------------------------------------------------ | -------------------------------- | +| 정의 | 프로그래밍 목표를 달성하기 위해 정렬된 작업 그룹 | 실행 중인 프로그램 | +| 상주 위치 | 디스크 or 보조 메모리 | 주 메모리 | +| 개체 유형 | 정적, 수동적 개체(passive entity) | 동적, 능동적 개체(active entity) | +| 자원 관리 | 명령어 저장을 위한 메모리만 필요 | 리소스 요구사항이 매우 높음 | +| 수명 | 수명이 길다. (삭제 전까지 저장됨) | 수명이 짧고 매우 제한적 | + + + +## 스레드(Thread) + +> 프로세스 내의 실행 흐름 + +![스레드](https://i0.wp.com/javaconceptoftheday.com/wp-content/uploads/2014/11/ThreadsAndProcesses.png?w=1200) + +- 프로세스의 **실행 가능한 가장 작은 단위** + +- 프로세스는 동시에 실행되는 여러 스레드를 가질 수 있다. + + - 이러한 프로세스를 경량 프로세스(Lightweight Process) 라고도 부른다. + +- **분류** + + | User Threads | Kernal Threads | + | ----------------------- | --------------------- | + | 사용자에 의해 구현 | OS에 의해 구현 | + | 구현이 쉬움 | 구현 복잡 | + | 종속 스레드로 설계 | 독립 스레드로 설계 | + | 문맥 교환 시간이 짧음 | 문맥 교환 시간이 길다 | + | 하드웨어 지원 필요 없음 | 하드웨어 지원 필요 | + +### 멀티 스레딩 + +**하나의 프로세스를 다수의 실행 단위로 구분**하여 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 **수행 능력을 향상시키는 것** + +- 즉, 하나의 프로그램에 동시에 여러개의 일을 수행할수 있도록 해주는 것 +- 하나의 프로세스 내 **메모리와 자원을 공유**한다. +- 메모리의 **code, data, heap 영역은 공유**하고, **stack과 PC 레지스터는 따로 할당**받는다. + - **각 스레드는 독립적으로 수행**되어야 하기 때문. +- **장점** + - **응답시간 단축** : 여러 스레드로 분할되면 하나의 스레드가 실행을 완료될 때 즉시 출력 반환 가능 + - **빠른 통신** : 동일한 메모리 영역을 공유해서 여러 쓰레드 간 통신이 원활함 + - **빠른 문맥 교환** : 프로세스에 비해 캐시 메모리를 비울 필요가 없기 때문. + - **시스템 처리량 향상** : 각 스레드 기능을 하나의 작업으로 간주하면서 단위 시간당 완료되는 작업 수 증가함 +- **문제점** + - **동기화 문제** + - 공유하는 자원에 동시에 접근하는 경우, 프로세스와 달리 **데이터와 힙 영역**을 공유하기 때문에 어떤 쓰레드가 다른 쓰레드에서 사용중인 변수나 자료 구조에 접근하여 엉뚱한 값을 읽어오거나 수정할 수 있다. 따라서 동기화가 필요! + - 동기화를 통해 작업 처리 순서와 공유 자원에 대한 접근을 컨트롤할 수 있다. 그러나 불필요한 부분까지 동기화를 하면 과도한 lock으로 인해 병목 현상이 병목 현상이 발생해 성능 저하 가능성 높다. + - 구현이 어려움 + - 테스트, 디버깅하기 어려움 + - 하나의 스레드의 문제가 발생하면 전체 프로세스에 영향을 끼침 +- 사용 사례 + - 영상통신 : 영상을 받아 화면에 출력하는 작업과 영상을 생성하여 보여주는 작업이 동시에 발생 + - 웹 브라우저 : UI를 처리하는 작업과 표시할 데이터를 가져오는 작업이 동시에 발생 + - 게임 : 그래픽을 실행하는 작업과 UI를 그리는 서버통신을 담당하는 소켓 작업이 동시에 발생 + +## 프로세스와 스레드 차이점 + +| | 프로세스 | 스레드 | +| -------------- | ------------------ | -------------------------------------- | +| 정의 | 프로그램이 실행 중 | 프로세스의 세그먼트 | +| 프로세스 타입 | 중량 프로세스 | 경량 프로세스 | +| 종료 시간 | 많은 시간 소요 | 적은 시간 소요 | +| 생성 시간 | 많은 시간 소요 | 적은 시간 소요 | +| 문맥 교환 시간 | 많은 시간 소요 | 적은 시간 소요 | +| 메모리 공유 | 비공유 | 공유. 단, stack과 PC 레지스터는 비공유 | + + + +## Reference + +- https://javaconceptoftheday.com/differences-between-program-vs-process-vs-threads/ +- https://www.guru99.com/program-vs-process-difference.html#3 +- https://binaryterms.com/process-control-block-pcb.html +- https://www.geeksforgeeks.org/thread-in-operating-system/?ref=lbp +- https://www.guru99.com/difference-between-process-and-thread.html +- https://goodgid.github.io/What-is-Multi-Thread/ +