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/JWT(Json Web Toekn)\353\236\200.md" "b/Network/JWT(Json Web Toekn)\353\236\200.md" new file mode 100644 index 0000000..6b95c7e --- /dev/null +++ "b/Network/JWT(Json Web Toekn)\353\236\200.md" @@ -0,0 +1,137 @@ +# JWT(Json Web Toekn)란? + +## 등장 배경 + +> 기존의 시스템에서는 `서버(세션) 기반의 인증방식`을 사용하였다.
하지만 시스템의 규모가 커지면서 `서버 기반의 인증방식`은 한계점을 보이기 시작하였고, 이 문제점들을 보완하는 `토큰 기반의 인증 방식`이 등장하게 되었다.
그리고 최근에는 Json 포맷을 이용하는 JWT를 주로 사용한다. + +### **서버(세션) 기반 인증 시스템** + +- **서버 측**에서 사용자들의 **정보를 기억** +- 사용자들의 정보를 기억하기 위해서 **세션을 유지**하는데, **메모리 or 디스크 or DB** 등을 통해 관리 (**Sateful 서버**) +- 소규모 시스템에서는 아직도 많이 사용되고 있지만, 웹/앱 어플리케이션이 발달하면서 **몇 가지 문제점**이 보이기 시작 + 1. 사용자가 많은 사이트의 경우 세션 저장 시 **메모리 or DB를 많이 차지** + 2. 서버를 확장하기 위해 세션을 분산시키는 시스템 설계해야 함. but 이 과정은 매우 **어렵고 복잡**하다. + 3. 여러 도메인에서 **관리하기 번거로운 쿠키** (**CORS**) + +### **토큰 기반의 인증 시스템** + +- 인증받은 사용자들에게 **토큰을 발급**하고, 서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하여 **유효성 검사 실시** +- 사용자의 인증 정보를 서버나 세션에 유지하지 않고 클라이언트 측에 저장 => 서버는 완전히 **Stateless** + - 더이상 사용자가 로그인 되어있는지 안되어있는지 신경쓰지 않고 시스템 확장이 가능해진다. +- 클라이언트와 서버의 연결고리가 없어 **시스템 확장에 매우 적합(Scalability)** + - 세션의 경우 해당 사용자는 처음 로그인 했었던 서버에만 요청을 받아야 하지만, 토큰의 경우 어떠한 서버로 요청이 와도 상관이 없다. +- 쿠키를 사용하지 않으므로 쿠키 사용에 의한 취약점이 사라짐 +- 토큰에 선택적인 권한만 부여하여 발급이 가능 (**Extensibility**) + - OAuth의 경우 Facebook, Google 등과 같은 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다. +- 다양한 디바이스, 도메인에서도 토큰의 유효성 검사 진행 후 요청 처리 가능 (**CORS 문제 해결**) + - 이런 구조를 통해 assests 파일(Image, html, css, js 등)은 모두 CDN에서 제공하고, 서버 측에서는 API만 다루도록 설게할 수 있다. + +## JWT란? + +- JWT는 `Json Web Token`의 약자로 **인증에 필요한 정보들을 암호화시킨 토큰**이다. +- 세션/쿠키와 함께 모바일과 웹의 인증을 책임진다. +- 세션/쿠키 방식과 유사하게 사용자는 Access Tocken(JWT Token)을 HTTP 헤더에 실어 서버로 보내게 된다. +- Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 **Claim 기반 Web Token** + - **Claim(클레임)** 이란 사용자 정보나 데이터 속성 등을 의미 +- JWT는 토큰 자체를 정보로 사용하는 **Self-Contained 방식**으로 정보를 안전하게 전달한다 + +## JWT 구조 + +JWT는 **Header, Payload, signature** 세 가지로 나눠져 있으며, Json 형태인 각 부분은 `Base64`로 **인코딩** 되어 포함된다.
또한 각각의 부분을 이어주기 위해 `.`구분자를 사용하여 구분한다. + +![jwt구조](img/jwt구조.jpg) + +### Header + +- `alg` + - 해싱 알고리즘 방식 지정 + - 주로 HS256(SHA256) 또는 RSA를 사용하며, Signature 및 토큰 검증에 사용한다. +- `type` + - 토큰의 타입을 지정 ex) JWT + +### Payload + +토큰에서 **사용할 정보**의 조각들인 **Claim(클레임)** 이 담겨 있다. + +**Key/Value 방식**으로 이뤄져있으며 (JSON과 유사) 다수의 정보를 넣을 수 있다. + +- Register Claim(등록된 클레임) + + - **토큰 정보를 표현하기 위해 이미 정해진 종류의 데이터** + - 모두 **선택적으로 작성**이 가능하며 사용할 것을 권장 + + | 키워드 | 의미 | + | :----: | ------------------------------------------------------------ | + | iss | 토큰 발급자(issuer) | + | sub | 토큰 제목(subject) | + | aud | 토큰 대상자(audience) | + | exp | 토큰 만료 시간(expiration)
NumericDate 형식으로 되어 있어야 함 ex) 1480849147370 | + | nbf | 토큰 활성 날짜(not before)
이 날이 지나기 전의 토큰은 활성화되지 않음 | + | iat | 토큰 발급 시간(issued at)
토큰 발급 이후의 경과 시간을 알 수 있음 | + | jti | JWT 토큰 식별자(JWT ID)
중복 방지를 위해 사용하며, 일회용 토큰(Access Token) 등에 사용 | + +- Public Claim(공개 클레임) + + - **사용자 정의 클레임**으로 **공개용 정보**를 위해 사용 + - 충돌 방지를 위해 **URI 포맷**을 이용 + + `{ "https://naver.com": true }` + +- Private Claim(비공개 클레임) + + - **사용자 정의 클레임**으로 **서버와 클라이언트 사이에 임의로 지정한 정보**를 저장 + + `{ "token_type": access }` + +### Signature + +- 서명(Signature)은 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 **고유한 암호화 코드** + +- 위에서 만든 **Header**와 **Payload**의 각 값을 **BASE64**로 인코딩 하고, 그 값을 비밀키를 이용해 헤더에서 **정의한 알고리즘**으로 해싱한다.
그리고 이 값을 다시 **BASE64**로 인코딩하여 생성 + +## JWT 동작 방식 + +![jwt_process](img/jwt_process.jpg) + +1. 사용자가 ID와 PW를 입력하여 로그인 시도 +2. 서버는 사용자가 맞는지 요청을 확인 +3. secret key를 통해 **Access Token(JWT)** 을 발급 +4. JWT 토큰을 클라이언트에 전달 +5. 클라이언트에서 API를 요청할 때, 클라이언트가 `Authorization header`에 **Access token(JWT)** 을 담아서 전달 +6. 서버는 JWT Signature를 체크하고 Payload로부터 사용자 정보를 확인한 뒤 데이터를 반환 + +> [참고] 처음 사용자를 등록할 때 **Access token**과 **Refresh token**이 **모두 발급**되어야 함 + +## JWT 장단점 + +### 장점 + +사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 **별도의 인증 저장소가 필요없다** + +- URL 파라미터와 헤더로 사용 +- 수평 스케일이 용이 +- 디버깅 및 관리가 용이 +- 트래픽 대한 부담이 낮음 +- REST 서비스로 제공 가능 +- 내장된 만료 +- 독립적인 JWT + +### 단점 + +- 토큰은 클라이언트에 저장되어 데이터베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용할 수 없다. +- 더 많은 필드가 추가되면 토큰이 커진다. +- 비상태 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미칠 수가 있다. + +## 유용한 상황 + +- 회원 인증 (JWT를 사용하는 가장 흔한 시나리오) +- 정보 교류 + - JWT는 정보가 `Signature` 되어있기 때문에 두 개체 사이에서 안정성있게 정보 교환하기 좋은 방법이다. + +## 참고 + +- https://mangkyu.tistory.com/55 + +- https://elfinlas.github.io/2018/08/12/whatisjwt-01/ +- http://www.opennaru.com/opennaru-blog/jwt-json-web-token/ +- [JWT 구조 출처](https://jwt.io/) \ No newline at end of file diff --git a/Network/img/jwt_process.jpg b/Network/img/jwt_process.jpg new file mode 100644 index 0000000..648b03e Binary files /dev/null and b/Network/img/jwt_process.jpg differ diff --git "a/Network/img/jwt\352\265\254\354\241\260.jpg" "b/Network/img/jwt\352\265\254\354\241\260.jpg" new file mode 100644 index 0000000..4730e71 Binary files /dev/null and "b/Network/img/jwt\352\265\254\354\241\260.jpg" differ 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/ +