├── Infra ├── README.md ├── images │ ├── docker1.png │ ├── docker2.png │ ├── docker3.png │ ├── docker4.png │ ├── docker5.png │ ├── docker6.png │ ├── microsolution.png │ └── container_image.png ├── Virtualization.md ├── Container.md ├── msa.md ├── Kubernetes.md └── Docker.md ├── Database ├── README.md ├── MysqlEngine.md └── Commit&Rollback.md ├── Network ├── README.md ├── HTTP&HTTPS.md ├── SSL.md └── OSI_7_Layer.md ├── OS ├── images │ ├── mutex.png │ └── semaphore.png ├── memory.md ├── ProcessControl.md ├── virtualMemory.md ├── IPC.md ├── Scheduling.md ├── Transaction.md ├── MemoryAllocation.md ├── CriticalSection-detail.md ├── Semaphore&Mutex.md ├── Thread.md ├── Paging&Segmentation.md ├── Synchronization.md ├── Semaphore&Mutex-detail.md ├── DeadLock.md └── Process.md ├── SoftwareEngineering ├── images │ ├── scrum.png │ ├── burndown_chart.png │ ├── scrum_process.png │ ├── sprint_backlog.jpg │ └── product_backlog.jpg └── Agile.md ├── Spring ├── Bean.md ├── AspectOrientedProgramming.md └── IoC&DI.md ├── Java ├── Generic.md └── OOP.md ├── System └── Compiler.md ├── DesignPattern └── Builder.md ├── DataStructure └── ArrayVSList.md └── README.md /Infra/README.md: -------------------------------------------------------------------------------- 1 | # Infra 2 | -------------------------------------------------------------------------------- /Database/README.md: -------------------------------------------------------------------------------- 1 | # Database 2 | -------------------------------------------------------------------------------- /Network/README.md: -------------------------------------------------------------------------------- 1 | # Network 2 | -------------------------------------------------------------------------------- /OS/images/mutex.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/OS/images/mutex.png -------------------------------------------------------------------------------- /Infra/images/docker1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/Infra/images/docker1.png -------------------------------------------------------------------------------- /Infra/images/docker2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/Infra/images/docker2.png -------------------------------------------------------------------------------- /Infra/images/docker3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/Infra/images/docker3.png -------------------------------------------------------------------------------- /Infra/images/docker4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/Infra/images/docker4.png -------------------------------------------------------------------------------- /Infra/images/docker5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/Infra/images/docker5.png -------------------------------------------------------------------------------- /Infra/images/docker6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/Infra/images/docker6.png -------------------------------------------------------------------------------- /OS/images/semaphore.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/OS/images/semaphore.png -------------------------------------------------------------------------------- /Infra/images/microsolution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/Infra/images/microsolution.png -------------------------------------------------------------------------------- /Infra/images/container_image.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/Infra/images/container_image.png -------------------------------------------------------------------------------- /SoftwareEngineering/images/scrum.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/SoftwareEngineering/images/scrum.png -------------------------------------------------------------------------------- /SoftwareEngineering/images/burndown_chart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/SoftwareEngineering/images/burndown_chart.png -------------------------------------------------------------------------------- /SoftwareEngineering/images/scrum_process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/SoftwareEngineering/images/scrum_process.png -------------------------------------------------------------------------------- /SoftwareEngineering/images/sprint_backlog.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/SoftwareEngineering/images/sprint_backlog.jpg -------------------------------------------------------------------------------- /SoftwareEngineering/images/product_backlog.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/gwanhyeon/CodingInterviewSummary/HEAD/SoftwareEngineering/images/product_backlog.jpg -------------------------------------------------------------------------------- /Spring/Bean.md: -------------------------------------------------------------------------------- 1 | ## Bean 2 | - Spring IoC 컨테이너에 의해 라이프 사이클이 관리되는 객체를 일컫는다. 3 | - `BeanFactory`에서 bean을 생성하고 관리한다. 4 | - `BeanFactory`는 스프링 설정 파일(`applicationContext.xml`)에 등록된 `bean`객체를 생성하고 관리한다. -------------------------------------------------------------------------------- /OS/memory.md: -------------------------------------------------------------------------------- 1 | # Memory (메모리) 2 | > 메모리는 목적에 따라 사용되는 영역이 다르다. 3 | 4 | ## Heap (힙) 5 | - 파일로부터 읽어들인 데이터나 네트워크 상에서 수신한 데이터를 저장할 때와 같이 `필요한 만큼만 확보`해 사용하는 메모리 영역 6 | - 필요가 없어지면 해제한다. 7 | 8 | ## Stack(스택) 9 | - `프로그램 실행 중` 이용하는 변수의 내용을 `일시적으로 저장`하는 메모리 영역 10 | - `프로그램의 한 단위(함수 등)`가 시작될 때 자동적으로 확보되고 처리가 종료되면 자동으로 해제된다. 11 | - 스택영역 변수는 `LIFO` 형식으로 저장된다. 12 | - 사용할 수 있는 스택 영역의 용량이 정해져 있어 이를 넘을 경우 `Overflow`가 발생한다. -------------------------------------------------------------------------------- /OS/ProcessControl.md: -------------------------------------------------------------------------------- 1 | ## 프로세스 제어 2 | 3 | ### 프로그램 상태어(PSW: Program Status Word) 4 | - 인터럽트로 인해 중단된 프로그램의 상태나 연산의 종료 상태를 저장해두는 레지스터(CPU 내부에 존재) 5 | - 영어 단어를 표현할 수 있는 정도의 용량(64bit)이므로 'word'를 사용함. 6 | 7 | ### 프로세스 제어 블럭(PCB: Process Control Block) 8 | - 각 프로세스의 CPU 상태(Context 등)나 프로세스 상태를 저장해 두는 메모리 영역을 일컬음. 9 | 10 | ### 컨텍스트 스위치(Context Switch) 11 | - 인터럽트로 인해 프로세스를 전환할 때 OS가 컨텍스트를 PCB에 저장하고 복원하는 것을 말함. 12 | - 컨텍스트 스위치때 약간의 오버헤드가 발생함. 13 | -------------------------------------------------------------------------------- /OS/virtualMemory.md: -------------------------------------------------------------------------------- 1 | # Virtual Memory (가상 메모리) 2 | > 메인 메모리보다 큰 기억 영역을 제공하는 장치 3 | 4 | ## 물리 메모리 5 | - 컴퓨터에 `실제 장착`되어 있는 메모리를 가리킴. 6 | - OS가 다룰 수 있는 메모리의 용량은 정해져 있지만, 물리 메모리가 그 최대 용량을 다 갖고 있는 것은 아니다. 7 | 8 | ## 가상 메모리 9 | > 물리적인 메모리 공간 10 | - `하드디스크` 안에 `페이징 파일(스왑 파일)`을 작성해 이 파일과 물리 메모리를 합쳐 `가상의 메모리 영역`으로 간주한다. 11 | - 따라서 물리 메모리의 용량을 초과한 메모리를 다룰 수 있다. 12 | 13 | ## 메모리 스왑 14 | - 메모리 용량이 부족할 때 `물리 메모리`와 `페이징 파일` 사이에서 메모리 상의 `프로세스`를 일시적으로 `교환`하는 것. 15 | - 우선 순위가 낮은 프로세스를 페이지 파일로 저장해 점유하고 있는 메인 메모리를 해제한다. 16 | - 스왑은 하드디스크에 자주 액세스하므로 퍼포먼스 저하가 일어난다. 17 | -------------------------------------------------------------------------------- /Spring/AspectOrientedProgramming.md: -------------------------------------------------------------------------------- 1 | ## Aspect-Oriented Programming 2 | - 관점 지향 프로그래밍 3 | - DI가 어플리케이션 모듈간 결합도를 낮춘다면, AOP는 어플리케이션 전체에 사용되는 기능을 `재사용`하기 위한 것. 4 | - OOP에서 바라보던 관점을 다르게 해 부가기능적 측면에서 보았을 때 `공통 요소를 추출`하는 것 5 | 6 | ### OOP vs AOP 7 | - OOP : 비지니스 로직의 모듈화 8 | - 모듈화 단위의 핵심은 비지니스 로직 9 | - 예) A 도메인에 대한 A 서비스, B 도메인에 대한 B 서비스,.. 10 | - AOP : 인프라 혹은 부가기능의 모듈화 11 | - 대표적 예) 로깅, 트랜잭션, 보안 등 12 | - 각각 모듈들의 주 목적 외 필요한 부가적인 기능들. 13 | - 예) A 서비스와 B 서비스에서 공통적으로 사용되는 기능들. 14 | 15 | ### 참고 16 | - [이동욱님 블로그](https://jojoldu.tistory.com/71) -------------------------------------------------------------------------------- /OS/IPC.md: -------------------------------------------------------------------------------- 1 | ## IPC(Inter Process Communication) 2 | > 프로세스 간 통신 3 | 4 | - 프로세스끼리 다른 메모리 공간을 참조하기 때문에 서로 어떤 데이터를 갖고 있는지 알 수 없다. 5 | - 따라서 OS에는 `프로세스 끼리 통신`하는 기능이 마련되어 있다. 6 | 7 | ### Pipe(파이프) 8 | - 여러 개의 `프로세스 입출력`을 연결하는 장치를 '파이프'라 한다. 9 | - 파이프는 `fork`한 부모-자식 프로세스 간에 사용된다. 10 | - fork: unix 계열 OS에서 시스템 콜에 의해 프로세스를 복사하는 것을 의미. 복사된 쪽이 자식 프로세스이다. 11 | 12 | ### Named PIPE(이름 붙은 파이프) 13 | - 파이프에 이름을 붙여 부모-자식 프로세스가 아니어도 프로세스 간 통신을 할 수 있게 핟나. 14 | - 기능은 일반 파이프와 같다. 15 | 16 | ### Message Queue(메세지 큐) 17 | - `프로세스` 끼리 OS의 메세지 기능을 사용해 1:1로 통신할 수 있다. 메세지를 넣는 장소를 `Message Queue`라 한다. -------------------------------------------------------------------------------- /Database/MysqlEngine.md: -------------------------------------------------------------------------------- 1 | ## MySQL Storage Engine 2 | - 대표적으로 MyIsam과 InnoDB를 사용 3 | 4 | ### MyIsam Engine 5 | - 데이터는 디스크에서 Index와 Key만 메모리에 적재해서 사용한다.  6 | - Transaction을 지원하지 않고 테이블 단위 Lock 을 지원한다. 7 | - 따라서 특정 테이블의 여러 세션에서 데이터를 변경하려 하면 Lock 기준이 테이블이기 때문에 무조건 대기하므로 성능 저하가 일어난다. 8 | - 저사양 서버를 위해 고안된 방법으로 Data Size와 Key, Index를 압축해서 사용한다. 그렇기 때문에 Index가 필요한 검색 기능이 추가된 테이블을 사용하기에 부적절하다. 9 | 10 | ### InnoDB Storage Engine 11 | - Transaction을 지원한다. Concurrency Control이 가능하고 행 단위 잠금으로 데이터 변경 작업 시 다른 사용자가 테이블에 접근할 수 있다. 12 | - 메모리에 Index, Data가 모두 적재되기 때문에 메모리 버퍼 크기가 DB 성능에 많은 영향을 끼친다. 13 | - 따라서 MyIsam보다 더 고사양의 서버를 요구한다. 14 | 15 | #### 참고 16 | - https://wedul.site/449 -------------------------------------------------------------------------------- /OS/Scheduling.md: -------------------------------------------------------------------------------- 1 | # Scheduling(스케쥴링) 2 | - CPU가 `여러개의 프로세스`를 처리할 때 `CPU를 할당할 순서`를 정하는 것. 3 | 4 | ## Preemptive Scheduling(선점형 스케쥴링) 5 | - `OS`가 실행 가능 상태인 Process(Task)에게 CPU 사용권을 할당하고 `강제적으로 프로세스를 전환`해 관리하는 것 6 | - 현재는 선점형 스케쥴링 방식을 많이 사용한다. 7 | 8 | ### Round Robin Scheduling(라운드 로빈 방식) 9 | - 선점형 스케쥴링 10 | - 프로세스가 `기다리고 있는 순서`대로 일정 `시간`씩 CPU를 할당해, 시간이 초과한 프로세스를 맨 마지막으로 돌리는 방식 11 | 12 | ## Non-Preemptive Scheduling(비선점형 스케쥴링) 13 | - `실행 중인 Process`가 처리를 수행하지 않는 시간을 `자발적으로 해제`해 다른 Process와 동시에 실행할 수 있도록 하는 것. 14 | 15 | ### Priority Scheduling(우선 순위 방식) 16 | - 비선점형 스케쥴링 17 | - OS가 프로세스의 우선순위를 정해 우선순위가 높은 프로세스부터 실행해 나가는 방식. 18 | - 많은 OS가 이 방식을 택함. 19 | - [데드락](/OS/DeadLock.md)이 발생할 수 있음. 20 | 21 | -------------------------------------------------------------------------------- /Java/Generic.md: -------------------------------------------------------------------------------- 1 | ## Generic 2 | 3 | ### 제네릭을 사용하는 이유 4 | > 컬렉션이 담을 수 있는 타입을 컴파일러에 알려주기 위한 것. 5 | 6 | **1. 타입 안정성** 7 | - `의도하지 않은 타입의 객체`가 저장되는 것을 막고, 다른 타입의 객체가 반환되는 것을 막아준다. 8 | - 제네릭 지원 전에는 `Object` 객체를 `형변환` 했으므로 런타임 에러가 발생했지만 제네릭 사용시 `컴파일 에러`를 발생시킨다. 9 | 10 | **2. 불필요한 형변환을 줄여줌** 11 | - 타입을 미리 명시해 다른 타입의 객체가 저장되지 않아 객체를 사용할 시 형변환을 할 필요가 없다. 12 | 13 | ### 참고 14 | - [Java - Don't use raw types](https://kodakyung.github.io/2019/01/28/Programming-Java-EffectiveJava-2019-01-28-Java-Don-t-use-raw-types/) 15 | - [Java - Use bounded wildcards to increase API flexibility](https://kodakyung.github.io/2019/01/31/Programming-Java-EffectiveJava-2019-01-31-Java-Use-bounded-wildcards-to-increase-API-flexibility/) 16 | -------------------------------------------------------------------------------- /OS/Transaction.md: -------------------------------------------------------------------------------- 1 | ## 트랜잭션 (Transaction) 2 | - 하나의 논리적 기능을 실행하는 명령어의 집합을 트랜잭션(`Transaction`)이라고 한다. 3 | - 한 작업의 단위, 한꺼번에 모두 수행되어야할 일련의 연산을 의미한다. 4 | - `DataBase`에도 함께 쓰이는 개념이다. 5 | 6 | ### Transaction의 성질 (ACID) 7 | - `Atomicity`(원자성) 8 | - 모두 반영되던가, 실패한다면 모두 반영되지 않아야한다. 9 | - `Consistency`(일관성) 10 | - 트랜잭션을 성공적으로 완료한다면 언제나 일관성 있는 상태여야 한다. 11 | - `Isolation`(독립성, 격리성) 12 | - 둘 이상의 트랜잭션이 동시에 실행되는 경우 서로의 트랜잭션 연산에 끼어들 수 없다. 13 | - 수행 중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다. 14 | - `Durablility`(영속성, 지속성) 15 | - 성공적으로 수행한 트랜잭션의 결과는 시스템이 고장나도 영구적으로 반영되어야한다. 16 | 17 | ## OS의 Transaction 18 | - 완료(Commit) : 성공적으로 실행 19 | - 철회(Abort) : 성공적으로 실행하지 못함. 20 | - 복구(Roll Back) : 철회된 트랜잭션에 의해 변경된 데이터를 복구함. -------------------------------------------------------------------------------- /OS/MemoryAllocation.md: -------------------------------------------------------------------------------- 1 | # Memory Management 2 | > 메모리 확보와 해제 3 | 4 | ## Allocation (할당) 5 | - OS가 프로세스나 데이터의 `메모리 영역`을 확보하는 것. 6 | - 확보한 메모리 영역은 처리 종료 시 `해제`해야한다. 7 | 8 | ## Relocation (재배치) 9 | - `한 번 확보`한 메모리 영역의 `위치를 변경`하는 것. 10 | - 실행 중인 프로그램의 위치를 변경하는 것을 `Dynamic Relocation(동적 재배치)`라 한다. 11 | - 가상 메모리 상의 주소를 물리 메모리 주소로 변환할 때 동적 재배치가 일어난다. 12 | 13 | ## Garbage Collection (가비지 컬렉션) 14 | - `힙` 영역이 `가득 차서` Access 할 수 없을 때 불필요한 메모리 영역을 자동으로 해제한다. 15 | 16 | ## Compaction (메모리 집약) 17 | - `단편화된 메모리`(내/외부 단편화)의 `미사용 영역`을 모아서 연속으로 이용할 수 있도록 `메모리 영역`을 만드는 것. 18 | - 사용 중인 프로세스를 `스왑 아웃`해 임시로 보관한 뒤 다시 `스왑 인`해야 하기 때문에 `Dynamic Relocation` 기능이 필요하다. 19 | 20 | ### 참고 21 | - [Memory Partioning ~ Memory Compaction](https://cenenh.tistory.com/65) -------------------------------------------------------------------------------- /OS/CriticalSection-detail.md: -------------------------------------------------------------------------------- 1 | ## 임계 영역(Critical Section) 2 | - `공유 자원`에 `접근`하는 프로세스 내부의 코드 영역. 3 | - 한 프로세스의 임계 영역이 수행 중일 때 다른 프로세스가 같은 공유 자원을 사용하는 임계 영역을 수행한다면 문제가 발생할 수 있다. 4 | - 따라서 한 번에 한 프로세스만 접근해 사용한다. 5 | - 임계 영역을 들어오는 진입 영역(entry section), 나가는 부분인 퇴출 영역(exit section), 나머지 영역(remainder section)으로 구분된다. 6 | 7 | ## 임계 영역의 조건 8 | ### 상호 배제(Mutual Exclusion( == Mutex)) 9 | - 한 프로세스가 자신의 임계 영역 내에서 실행되는 동안, 다른 프로세스가 같은 공유 자원을 사용하는 자신의 임계 영역에서 실행될 수 없는 것. 10 | 11 | ### 진행 (Progress) 12 | - 임계 영역을 실행 중인 프로세스가 없고 자신의 임계 영역으로 진입하려는 프로세스가 있다면, 나머지 영역에서 실행 중이지 않은 프로세스들만 임계 영역으로 진입하기 위해 요청할 수 있다. 13 | - 이는 무기한 연기될 수 없다. 14 | 15 | ### 한정된 대기 (Bounded waiting) 16 | - 프로세스가 자신의 임계 영역에 진입하기 위해 요청을 한 뒤, 그 요청이 허가될 때까지 다른 프로세스들이 자신의 임계 영역에 진입하도록 허용하는 횟수의 제한이 있어야한다. 17 | 18 | ## 임계 영역 해결 방안(동기화) 19 | - 하드웨어 기반 동기화와 소프트웨어 기반 동기화로 나뉜다. 20 | - 대표적인 소프트웨어 기반 동기화 기법으로 상호 배제(`Mutex`), 세마포어(`Semaphore`), 모니터(`Monitor`) 등이 있다. -------------------------------------------------------------------------------- /OS/Semaphore&Mutex.md: -------------------------------------------------------------------------------- 1 | ## Process Synchronous(프로세스의 동기) 2 | 3 | ### 배타 제어 4 | - `여러 개의 Process`가 File이나 Database에 동시에 액세스하면 `데이터의 무결성`이 손상될 수 있다. 5 | - 따라서 처리가 끝날 때까지 `하나의 프로세스`에 `자원을 독점`시키는 것이 필요하며, 이를 `배타 제어`라 한다. 6 | 7 | ### 세마포어 (Semaphore) 8 | - `정해진 수 이상의 프로세스`가 공유 자원에 `동시에 액세스`하지 않도록 `카운터`를 사용해 제어하는 장치를 의미한다. 9 | - OS는 세마포어의 P조작(획득)과 V조작(해제)로 '통행 가능', '통행 불가' 두 상태를 관리한다. 10 | - 데드락을 피하기 위한 방법 중 하나 11 | 12 | #### 예시 13 | - 세마포어 카운터 초기값을 2로 하고, 공유 자원에 접근 하는 프로세스가 A, B, C가 있는 경우 14 | - 프로세스 A, B가 P 조작해 카운터가 0이 되면 프로세스 C는 공유자원에 접근할 수 없다. 15 | - 프로세스 처리가 끝나고 V조작으로 해제하면 카운터가 다시 1 이상이 되어 프로세스 C가 접근할 수 있다. 16 | 17 | ### 뮤텍스 (Mutex) 18 | - 세마포어의 `카운터 초기값`이 `1`인 경우과 같다. 19 | - 즉 한번에 `하나의 프로세스`만 공유 자원에 액세스 할 수 있다. 20 | - 데드락을 피하기 위한 방법 중 하나 21 | 22 | > [자세한 설명](/OS/Semaphore&Mutex-detail.md) 23 | 24 | ### 크리티컬 섹션(Critical Section) 25 | - 프로그램 중 `배타 제어가 필요한 부분`을 일컫는다. 26 | - P 조작부터 V 조작까지의 처리에 해당한다. 27 | 28 | > [자세한 설명](/OS/CriticalSection-detail.md) -------------------------------------------------------------------------------- /System/Compiler.md: -------------------------------------------------------------------------------- 1 | # 컴파일러란? 2 | 3 | > 특정 프로그래밍 언어로 쓰여 있는 문서를 다른 프로그래밍 언어로 옮기는 프로그램 4 | 5 | > 소스 코드에서 목적 코드로 옮기는 과정을 함 6 | 7 | > 소스 프로그램을 읽어서 즉시 결과를 출력하는 인터프리터와는 구분됨 8 | 9 | 10 | 11 | # 컴파일러의 실행 단계 12 | 13 | 1) **구문 분석** : 소스 코드 파일을 읽어 개별 문법요소 단위로 자른 후, 추상 구문 트리를 생성. 문법에 맞지 않는 소스 코드는 사용자에게 알려줌. 14 | 15 | 16 | 17 | 2) **최적화** : 추상 구문 트리를 분석하여 최적화 수행. 도달할 수 없는 코드를 식별하거나 상수 표현식을 미리 계산하거나 루프 풀기 등을 진행 18 | 19 | 20 | 21 | 3) **코드 생성** : 최적화된 구문 트리로부터 목적 코드를 생성. 목표 코드가 기계어일 경우, 레지스터 할당, 연산 순서 바꾸기 등 하드웨어에 맞는 최적화가 진행 22 | 23 | 24 | 25 | 4) **링킹** : 목적 코드가 기계어일 경우, 여러 라이브러리 목적 코드를 묶어 하나의 실행 파일을 생성. 26 | 27 | 28 | 29 | # iOS에서의 Linker Flag 30 | 31 | > 서드 파티 라이브러리를 사용할 때 쓰는 build setting 32 | 33 | * **ObjC** : Objective-C 클래스나 카테고리로 정의된 라이브러리에 속한 객체 파일들을 모두 적재해주는 플래그 34 | 35 | * **all_load** : linker가 Object-C Code가 있는지 상관 없이 모든 라이브러리의 객체를 로드하라는 플래그 36 | 37 | * **force_load** : 뒤에 라이브러리 경로가 붙음. 해당 라이브러리만 강제로 로드하라는 플래그 38 | 39 | 40 | 41 | [참고](http://blog.naver.com/PostView.nhn?blogId=sokm83&logNo=220970336898&parentCategoryNo=&categoryNo=12&viewDate=&isShowPopularPosts=false&from=section) -------------------------------------------------------------------------------- /Network/HTTP&HTTPS.md: -------------------------------------------------------------------------------- 1 | # HTTP란? 2 | 3 | <**H**yper**T**ext **T**ransfer **P**rotocol> 4 | 5 | * 인터넷에서 사용하는 웹 서버와 사용자의 인터넷 브라우저 사이에 문서를 전송하기 위한 통신 규약 6 | 7 | * 포트번호 80번 8 | 9 | 10 | 11 | # HTTPS란? 12 | 13 | <**H**yper**T**ext **T**ransfer **P**rotocol over **S**ecure Socket Layer> 14 | 15 | ### 16 | 17 | * 소켓 통신에서 일반 텍스트를 이용하는 대신에 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화합니다. 따라서 데이터의 암호화를 통해 보안성을 강화 및 보호하고 있습니다. 18 | * 포트번호 443번 19 | * 암호화는 Transport 계층에서 이루어지게 됩니다. 20 | 21 | 22 | 23 | # HTTP와 HTTPS의 차이? 24 | 25 | HTTP는 네트워크 보안이 되어 있지 않습니다. 그래서 네트워크상에서 정보를 누군가가 마음대로 보고, 수정할 수 있습니다. 26 | 27 | 이와 달리 HTTPS는 네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록 **HTTP를 암호화**합니다. 이를 위해 HTTPS는 추가적인 인증 절차를 요구하며, 복호화 없이 HTTPS의 정보를 중간에서 볼 수 있는 방법은 아직까지 존재하지 않습니다. 28 | 29 | ### 30 | 31 | 32 | 33 | # HTTP와 HTTPS의 사용자 입장에서의 장단점? 34 | 35 | - HTTP는 HTTPS에 비해 더 빠릅니다. 36 | - HTTP는 변조 가능성을 항상 유의해야 합니다. 37 | - HTTPS는 인터넷을 이용하는데 매우 안전합니다. 38 | 39 | 40 | 41 | 42 | 43 | # HTTP와 HTTPS의 공급자 입장에서의 장단점? 44 | 45 | - HTTP로 민감한 정보를 다룰 때 항상 변조, 해킹 가능성을 유의해야 합니다. 46 | 47 | - HTTP는 HTTPS보다 트래픽이 적게 발생합니다. 그래서 더 적은 비용으로 유지가 가능합니다. 48 | 49 | - HTTPS는 설치 및 인증서를 유지하는데 추가 비용이 듭니다. 50 | 51 | -------------------------------------------------------------------------------- /DesignPattern/Builder.md: -------------------------------------------------------------------------------- 1 | # 빌더(Builder) 패턴 2 | 3 | >**복잡한 객체의 생성을 그 객체의 표현과 분리하여, 생성 절차는 항상 동일하되 결과는 다를 수 있게 만드는 패턴** 4 | 5 | > 객체의 구성요소들을 요소별로 분리한 뒤, 개별 요소들에 대한 값을 조합하여 하나의 객체를 생성함. 조합하는 방법의 구체적인 방법은 빌더를 통해 결정함. 6 | 7 | => 메서드의 호출 결과로 자신의 객체 참조를 돌려줌. 8 | 9 | 10 | 11 | ** 많은 생성 요소를 한번에 넣어 체이닝 형식으로 만들어줄 수 있음. 12 | 13 | ** return type을 Builder로 해야 함. 14 | 15 | 16 | 17 | # 구조 18 | 19 | * **Director** : 객체 생성 방식에 대한 책임을 짐. ConcreteBuilder를 인자로 받아 필요 동작 수행 20 | * **Builder** : 객체를 생성하는 추상 인터페이스 21 | * **ConcreteBuilder** : Builder의 구현 클래스. 객체 생성 결과에 대한 구체적인 구현 책임. 22 | * **Product** : Builder를 이용해서 Director가 만들어낸 최종 객체 23 | 24 | ![img](https://t1.daumcdn.net/cfile/tistory/9999204B5A3753AF03) 25 | 26 | # 사용하는 이유? 27 | 28 | 1. 불필요한 생성자를 만들지 않고 객체 생성 29 | 2. 데이터의 순서에 상관 없이 객체 생성 30 | 3. 사용자 입장에서 명시적이고 이해하기 쉽게 생성 31 | 32 | 33 | 34 | # 사용하기 좋은 경우 35 | 36 | 1. 여러 요소를 갖는 복잡한 객체를 생성할 필요가 있을 때 37 | 2. 어떤 객체를 여러 가지 방법으로 생성할 필요가 있을 때 38 | 39 | 40 | 41 | # 빌더 vs 추상 팩토리 42 | 43 | * 주로 복잡한 객체 생성 || 객체의 단순함, 복잡함 상관없음 44 | * 여러 단계를 거쳐 마지막 단계에서 객체 반환 || 한 단계로 객체를 생성하여 즉시 반환 45 | * 빌더를 통한 여러 가지 방법으로 객체 생성 || 한 가지 방법으로 객체 생성 46 | * 한 가지 타입의 특정 객체 생성에 초점 || 같은 종류의 여러 가지 객체 생성에 초점 -------------------------------------------------------------------------------- /Infra/Virtualization.md: -------------------------------------------------------------------------------- 1 | ## 전가상화(Full Virtualization) 2 | 3 | 가상머신의 운영체제에서의 구조를 살펴보면, 4 | 5 | Guest OS -> Hypervisor -> Hardware 6 | 7 | 의 구조를 가지고 있다. 8 | 9 | 하드웨어 위에 Hypervisor가 존재하고, Guest OS가 그 위에 설치 된다. 그럼 Guest OS가 Hypervisor를 통해서 Hardware와 신호를 주고 받는다. 10 | 11 | Redhat OS 12 | Windows OS => Hardware 13 | Mac OS 14 | 15 | 의 구조를 생각해보면된다. 16 | 17 | 예를 들어, Redhat Windows, Mac OS에서 덧셈과 뺄셈의 연산을 하드웨어에게 요청한다고 생각해보자. 18 | 하드웨어는 이것들을 이해하기 위해서 특히, 가상화된 GUEST OS가 하드웨어 위에 올라가는데, 그 OS가 무엇이든간에 하드웨어는 OS가 내리는 명령을 알아들을 수 있어야한다. 19 | 20 | 1. Hypervisor는 OS 들에게 자원을 나눠주며, 조율한다. 21 | 2. OS들의 커널을 번역해서 하드웨어에게 알려준다. 22 | 23 | 24 | 25 | ## 반가상화(Half Virtualization) 26 | 27 | Redhat OS (번역기) 28 | Windows OS (번역기) => Hardware 29 | Mac OS (번역기) 30 | 31 | 각 OS의 명령어에다가 번역기를 달아서, 각 Guest OS에 있는 명령들을 모두 하나의 번역으로 바꾸어서 Hardware에게 전달하게 된다. 32 | 이것들을 실행하기 위해서는 OS마다 각각의 커널딴을 건드리면서 수정을 해야한다. 33 | 윈도우 같은경우는 오픈소스로 이루어져있지 않기 때문에, 커널을 수정할 수 없다. 하지만, 리눅스는 오픈소스로 모든 커널이 제공되기 때문에 커널딴을 직접적으로 운영 및 수정을 할 수 있다. 결국 GuestOS를 수정한다는 말이다. 34 | ### 하지만? Windows는? 35 | 오픈소스로 제공되지 않는다. 그러면 이것들을 수정 할 수 없다는 말인가? 36 | 아니다. Xen에서 제공하는 툴로 전부 다 가능하다. 반 가상화에서는 Hypervisor는 번역을 제공하지 않는가? 그렇다. 37 | 자체적으로 커널에 번역을 변경하였으니, Hypervisor는 단지 가상화 OS들에게 자원을 어떻게 배분할 것인가? 하는 관리적인 문제들만 다루면 된다. 38 | 39 | 40 | -------------------------------------------------------------------------------- /OS/Thread.md: -------------------------------------------------------------------------------- 1 | # 스레드(Thread)란? 2 | 3 | **어플리테이션 실행의 가장 기본 단위** 4 | 5 | - 프로세스 내에서 각각 Stack만 따로 할당 받고 Code, Data, Heap 영역은 공유 6 | - 시스템 스레드, 사용자 스레드, 이벤트 스레드 등이 있다. 7 | - 시스템에서 생성하고 관리하며, 어플리케이션의 첫번째 스레드는 시스템 스레드이다. 8 | - 사용자 스테드는 메인스테드 외에 애플리케이션에서 명시적으로 생성한 스레드이다. 9 | - 사용자 인터페이스를 화면에 표시하는 애플리케이션에서의 메인스레드는 이벤트 스레드라 부른다. 10 | - 이벤트 스레드는 마우스 클릭이나 키 입력 들이 있다. 11 | 12 | ## 선점형 스레딩 13 | - 동시에 돌릴 수 있는 스레드 수는 컴퓨터에 있는 코어 개수로 제한된다. 14 | - OS에서는 아무때나 스레드 실행을 멈추고 다른 스레드를 실행시킬 수 있다. 15 | - 위와 같은 방법을 선점형 스레딩(Preemptive Threading)이라한다. 16 | 17 | ## 협력형 모델(Cooperative model) 18 | - 반대로 어떤 스레드가 멈추고 다른 스레드로 돌아가려면 강제가 아닌 명시적인 행동이 필요한 경우. 19 | 20 | ## 컨텍스트 스위칭(Context Switching) 21 | - 다른 스레드가 시작될 수 있도록 한 스레드를 멈추는 것. 22 | 23 | 24 | # 멀티 스레딩이란? 25 | 26 | - 하나의 응용프로그램을 여러 개의 스레드로 구성하고 각 스레드가 하나의 작업을 처리하도록 하는 것 27 | 28 | 29 | 30 | ## 멀티 스레드 동기화 문제 31 | 32 | 스레드 간의 자원 공유는 전역 변수를 이용하므로 함께 사용할 때 충돌이 발생할 수 있음 33 | 34 | 35 | 36 | ## 멀티 프로세스 대신 멀티 스레드를 사용하는 이유? 37 | 38 | **자원의 효율성이 높아지고 처리 비용 및 응답 시간이 줄어든다.** 39 | 40 | > 같은 메모리를 사용하므로 메모리 이용 효율이 올라간다. 41 | 42 | 43 | * 프로세스를 생성하여 자원을 할당하는 시스템 콜이 줄어듦. 44 | * 프로세스 간의 문맥 교환시 CPU 레지스터 교체뿐만 아니라 RAM과 CPU 사이의 캐시 메모리에 대한 데이터까지 초기화되므로 오버헤드가 큼 45 | * Stack 이외의 모든 메모리를 공유하기 때문에 스레드 간의 통신 비용이 더 적음 46 | * 문맥 교환시 Stack 영역만 처리하기 때문에 스레드 간의 전환 속도가 더 빠름 -------------------------------------------------------------------------------- /DataStructure/ArrayVSList.md: -------------------------------------------------------------------------------- 1 | ## Array(배열) 2 | - `같은 자료형`을 가진 데이터를 그룹핑해 효과적으로 관리하는 데이터 스트럭처. 3 | - `메모리`에 `순차적`으로 데이터를 저장한다. 4 | - `인덱스`를 이용한 데이터 `조회`가 빠르다. 5 | - 데이터 크기가 컴파일시 결정되어 크기를 `변경`할 수 없다. 6 | - 데이터 `삭제`시 `빈 공간`으로 남기 때문에 메모리를 낭비할 수 있다. 7 | 8 | ```java 9 | // java 10 | int[] arr = {1, 2, 3, 4}; 11 | // 배열의 삭제 메소드가 존재하지 않음. 12 | arr.length(); // 4 13 | // 0 등 프로그래머가 의미상 삭제하는 코드를 작성하더라도 길이는 4로 고정되어있다. 14 | ``` 15 | 16 | ## List(리스트) 17 | - 같은 자료형, `순서가 있는 엘리먼트`들의 모임이라는 특징은 배열과 같다. 18 | - 하지만 배열과 다르게 `삭제`하더라도 `빈공간`을 허용하지 않는다. 19 | - 순서가 있지만 메모리에 순차적으로 적재되어 있는지 아닌지는 구현된 `언어별 라이브러리`마다 다른다. 20 | - 리스트에 `인덱스`는 존재하지만 일반적으로 메모리상 순서의 의미보다는 `몇번째 데이터`인지를 의미한다. 21 | 22 | ```java 23 | // java 24 | List list = new ArrayList<>(); 25 | for (int i = 1; i <= 4; i++) { 26 | list.add(i); // 1, 2, 3, 4 저장 27 | } 28 | list.size(); // 4 29 | 30 | list.remove(0); // index 0에 위치한 데이터 삭제 31 | list.size(); // 3 32 | ``` 33 | 34 | ## Java에서의 List 35 | ### ArrayList 36 | - 내부 구현이 `Array(배열)`로 되어 있다. 37 | - 크기를 동적으로 변경할 수 있지만 `내부적으로 배열`이기 때문에 변경되는 크기에 따라 `배열의 재할당`이 일어난다. 38 | - 따라서 인덱스로 인한 `조회` 성능이 좋으며 삽입, 삭제의 성능이 떨어진다. 39 | 40 | ### LinkedList 41 | - 내부 구현이 `Linked List(연결리스트)`로 되어 있다. 42 | - 연결리스트란 각 노드가 데이터와 포인터를 가지고 한줄로 연결되어 있는 방식이다. 43 | - 따라서 탐색할때 head 부터 시작하며 `O(n)` 시간복잡도를 가진다. 44 | - `get(index)` 메소드가 구현되어 있지만 내부적으로 head부터 탐색하기에 탐색 성능이 떨어진다. 45 | - `삽입`, `삭제`가 빈번한 경우 사용하는 것이 좋다. 46 | 47 | ### 참고 48 | [생활코딩 - Data Structure (자료구조) 중 리스트](https://opentutorials.org/module/1335/8636) -------------------------------------------------------------------------------- /Spring/IoC&DI.md: -------------------------------------------------------------------------------- 1 | ## IoC(Inversion of Control) 2 | - `제어의 역전`, 프로그램의 제어 흐름 구조가 바뀌는 것. 3 | - 일반적으로 main() 메소드부터 프로그램의 각 오브젝트가 다른 오브젝트를 호출하며 프로그램의 흐름을 결정한다. 4 | - 이와 다르게 오브젝트가 자신이 사용할 오브젝트를 정하지 않고 위임하는 것이 IoC이다. 5 | 6 | ### 라이브러리 vs 프레임워크 7 | - 라이브러리는 라이브러리를 사용하는 애플리케이션 코드가 직접 흐름을 제어한다. 8 | - 프레임워크는 반대로 `어플리케이션 코드가 프레임워크에 의해 사용`된다. 9 | - 즉 어플리케이션 코드는 프레임워크가 짜놓은 틀에서 `수동적`으로 동작한다. 10 | 11 | ### Spring에서의 IoC 12 | - 객체가 자신과 함께 작동하는 객체를 `생성자`, `팩토리 메소드 인자`, `프로퍼티`로만 받는 프로세스가 IoC이다. 13 | 14 | ## DI (Dependency Injection) 15 | - `의존성 주입` 16 | - 객체간 의존성을 자신이 아닌 `외부에서 주입`하는 개념. 17 | - 의존성이란 객체와 객체의 `결합 관계`이다. 18 | - A 객체에서 B 객체를 사용한다면 A 객체 내부에서 `new`로 B 객체를 생성하는데 이를 의존 관계라 한다. 19 | - 즉 객체의 인스턴스를 `외부에서 생성 받는 것`을 의존성 주입이라한다. 20 | - 제어권이 프레임워크로 넘어갔기 때문에(IoC) DI의 사용이 가능하다. 21 | 22 | ### Spring의 DI 방법들 23 | 1. `Constructor`를 통한 의존성 주입 24 | 2. `Setter`를 통한 의존성 주입 25 | 3. `@Autowired` 어노테이션을 통한 의존성 주입 26 | - setter와 같은 역할을 자동으로 수행한다. 27 | - `Immutable Object`를 생성하기 위해 생성자를 통한 의존성 주입을 권장하는 편이다. 28 | 29 | ### 참고 30 | - [Jbee Devlog](https://asfirstalways.tistory.com/334) 31 | - [기계인간 Jogn Grib](https://johngrib.github.io/wiki/spring-ioc/?fbclid=IwAR0qXjkEPjGecqDkKHoQM3iuawkOI98sotXyhomJRIHiKh3LHFyvY-yA6wI#di%EB%A5%BC-%ED%95%98%EB%8A%94-3%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95) 32 | - [dmz 개발창고](https://mo-world.tistory.com/entry/IOC%EC%99%80-DI-%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC-%EC%8A%A4%ED%94%84%EB%A7%81-%EA%B0%9C%EB%85%90-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%84%A4%EB%AA%85) 33 | 34 | -------------------------------------------------------------------------------- /Java/OOP.md: -------------------------------------------------------------------------------- 1 | # OOP(Object Oriented Programming) 2 | > 객체 지향 프로그래밍의 설계 원칙 3 | 4 | ## SOLID 원칙 5 | 6 | ### 단일 책임 원칙(SRP, Single Responsibility Principle) 7 | - 객체는 `단 하나의 책임`만 가져야 한다. 8 | - 책임이란? 해야하는 것, 할 수 있는 것, 해야하는 것,.. 9 | - 책임 분리 : 한 클래스에 단 하나의 책임만 수행하도록 해 `Immutable Class`를 지향한다. 10 | - 책임이 많을 수록 클래스 내부에 서로 다른 역할을 수행하는 코드끼리 `강결합`할 가능성이 높다. 11 | 12 | ### 개방-폐쇄의 원칙(OCP, Open Closed Principle) 13 | - `확장`에 대해서는 `개방(open)적`이며 `변경`에 대해서는 `폐쇄(Close)`되어야 한다. 14 | - **즉 기존의 코드를 변경하지 않으며 기능을 추가할 수 있도록 설계가 되어야 한다.** 15 | - 해당 원칙을 적용하기 위해 적용하는 방법은 `상속(is-a)`과 `컴포지션(has-a)`이 있지만 컴포지션을 추천한다. 16 | - 상속은 상위 클래스가 변하면 하위 클래스에 끼치는 영향이 크기 때문이다. 17 | 18 | ### 리스코프 치환 원칙(LSP, Liskov Substitution Principle) 19 | - 자식 클래스는 최소한 자신의 `부모 클래스에서 가능한 행위`를 수행할 수 있어야 한다. 20 | - **LSP를 만족한다면 부모 클래스의 인스턴스 대신 자식 클래스의 인스턴스로 대체해도 프로그램의 의미가 변하지 않는다.**(ex- `List l = new ArrayList<>();`) 21 | - LSP를 만족시키는 방법 중 하나는 부모 클래스의 메소드를 `Override`하지 않는 것이다. 22 | 23 | ### 인터페이스 분리 원칙(ISP, Interface Segregation Principle) 24 | - `인터페이스`를 클라이언트에 특화되도록 `분리`시키는 설계 원칙 25 | - **클라이언트는 자신이 이용하지 않는 기능에는 영향을 받지 않아야 한다.** 26 | - 단일 책임 원칙과 밀접한 관계가 있다. 27 | 28 | ### 의존 역전 원칙(DIP, Dependendy Inversion Principle) 29 | - 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하기 보다는 변화하기 어려운 것, **거의 변화가 없는 것에 의존하라는 것.** 30 | - 클래스간 의존 관계란 ? 한 클래스가 어떤 기능을 수행하려고 할 때 `다른 클래스`의 서비스가 `필요`한 경우 31 | - ex) A 클래스 내부에 `new` 연산자로 B 클래스가 생성되어 있는 경우. 32 | - DIP 만족시키는 방법 : 어떤 클래스가 의존 관계를 맺을 때 구체적인 클래스보다는 `인터페이스`나 `추상 클래스`와 `의존 관계`를 맺도록 한다. 33 | - DIP를 만족하는 설계는 `DI` 기술로 변화를 쉽게 수용하는 코드를 작성할 수 있게 된다. 34 | 35 | ### 참고 36 | - https://gmlwjd9405.github.io/2018/07/05/oop-solid.html 37 | - https://velog.io/@dpudpu/2 38 | -------------------------------------------------------------------------------- /OS/Paging&Segmentation.md: -------------------------------------------------------------------------------- 1 | # Memory Mapping 2 | > 물리 메모리와 가상 메모리의 대응 3 | - OS가 물리 메모리와 가상 메모리 사이에 프로그램이나 데이터를 대응 시키는 것을 `Mapping`이라 한다. 4 | 5 | ## Paging (페이징) 6 | - `고정 길이` 페이지 단위(4KB)로 매핑을 수행하는 기법. 7 | - 논리(가상)메모리는 `페이지(Page)`라 불리는 고정 크기 블록, 물리 메모리는 `프레임(Frame)`이라 불리는 페이지와 같은 크기의 고정 크기 블록으로 나눈 뒤 `페이지 테이블`에서 페이지-프레임을 매핑해 관리하는 기법 8 | - 프로세스의 일부만 메모리에 로드한 뒤 나머지는 보조기억장치에 둔다. 9 | - `고정 크기`이므로 **연속적인 물리 메모리가 아니더라도 원하는 크기의 프레임을 사용할 수 있다.** 10 | - 고정 크기 이므로 외부 단편화를 해결할 수 있지만 내부 단편화가 발생한다. 11 | - 페이지 아웃 : 물리 > 가상 메모리 12 | - 페이지 인 : 물리 < 가상 메모리 (우선 순위 높은 페이지를 물리 메모리의 페이지 프레임에 전송) 13 | - 페이징이 번번히 일어나는 것은 `Thrashing(스레싱)`이라 하는데 이는 CPU 이용 효율 저하의 원인이 된다. 14 | - Page Fault(페이지 폴트) : 물리 메모리에 페이지 프레임이 없으면 발생하는 인터럽트 15 | 16 | ## Segmentation (세그먼테이션) 17 | - `가변 길이` 세그먼트 단위로 매핑을 수행하는 기법. 18 | - 가상메모리를 `서로 크기가 다른 논리적 단위`인 세그먼트로 분할하고 메모리를 할당해 주소 변환을 한다. 19 | - `각각의 세그먼트`들은 `연속적인 공간`에 저장되어 있다. 20 | - 세그먼트들의 크기가 다르기 때문에 메모리를 페이징 기법처럼 분할해 둘 수 없고, `메모리에 적재될 때` 빈 공간을 찾아 `할당`한다. 21 | - Mapping을 위해 세그먼트 테이블이 필요하다. 22 | - 하나의 세그먼트 단위로 통제하기 때문에 내부 단편화가 발생하지 않는 대신 외부 단편화가 생길 수 있다. 23 | - 세그먼테이션이 빈번하게 일어나면 Fragmentation(프레그먼테이션)이 발생해 Compaction(메모리 집약)을 수행해야한다. 24 | 25 | ### 페이징과 세그먼테이션의 예(x86) 26 | - 메모리 레이아웃과 같이 `커널-스택-공유라이브러리-힙-BSS-데이터-코드` 각각 영역으로 나눈 기술을 `세그먼테이션`이라 한다. 27 | - 각각 다른 크기를 논리적 블록으로 연속해 배치한다. 28 | - 각 영역의 기능, 권한, 필요한 공간의 크기가 모두 달라 세그먼테이션으로 분할해 메모리를 관리하는 것. 29 | 30 | 31 | - 어셈블리 코드가 모두 각각 동일한 크기로 할당되는 것이 `페이징` 기법이다. 32 | 33 | 34 | - x86은 세그먼테이션으로 메모리 전체 레이아웃을 분할하고, 프로세스가 요구하는 작업을 동일한 크기로 쪼개 페이지 단위로 단위를 처리한다. 35 | 36 | 37 | ### 참고 38 | - https://m.blog.naver.com/s2kiess/220149980093 39 | - https://sycho-lego.tistory.com/10 40 | -------------------------------------------------------------------------------- /OS/Synchronization.md: -------------------------------------------------------------------------------- 1 | ## 동기화(Synchronization) 2 | - `레이스 컨디션` 상황을 막기 위해 프로세스/스레드들에 하나의 자원에 대한 처리 `권한`을 주거나 `순서`를 조정해주는 기법이다. 3 | - `다중 스레드` 환경에 공유되는 자원이 있다면 필수적으로 고려해야한다. 4 | - 프로세스의 경우 OS 레벨에서 공유 자원 문제를 처리해주지만 한 프로세스 내에서 실행되는 여러 개의 스레드들은 공유 자원에 대해 동기화 문제를 고려해야한다. 5 | - 스레드 동기화는 모니터(`Monitor`)와 세마포어(`Semaphore`)로 구성된다. 6 | - 사용하는 시스템이나 언어에서 `어느쪽을 지원`하는지에 따라 선택해서 사용한다. 7 | - Java는 기본적으로 모니터를 지원한다. 8 | - 스레드 동기화는 공유 자원에 접근하기 위해 자물쇠의 획득과 해제에 비용이 든다. 따라서 라이브러리를 별도로 만드는 편이다. 9 | - ex) Java의 `StringBuffer`, `StringBuilder` 10 | 11 | ### 모니터(Monitor) 12 | - 상호 배제 자물쇠(mutual exclusion lock)로 보호되는 루틴의 집합을 일컬음 13 | - 자물쇠를 획득하기 전까지 모니터에 속하는 루틴을 실행할 수 없다. 14 | - 즉 한 모니터에 한 스레드씩 실행되며, 다른 스레드들은 실행중인 스레드가 자물쇠를 놓아줄 때까지 기다려야한다. 15 | - 모니터에 속하는 스레드가 다른 이벤트 발생을 기다리기 위해 스스로 멈추면 다른 스레드가 모니터로 진입할 수 있다. 16 | - 대기중인 스레드가 이벤트가 발생했다는 연락을 받으면 스레드가 깨어나서 자물쇠를 재획득하게 된다. 17 | 18 | ### 세마포어(Semaphore) 19 | - 세마포어는 모니터와 비슷하지만 더 간단하다. 20 | - 공유 자원을 보호하기 위한 자물쇠만 있다. 21 | - 스레드에서 공유자원을 사용하기 위해 자물쇠를 획득해야한다. 22 | - 자물쇠를 쥐고 있는 스레드에서 놓아주기 전까지 그 자원을 획득하려는 스레드는 막히게된다. 23 | - 자물쇠를 놓아주는 순간 자물쇠를 획득하려고 대기하던 스레드가 그 자물쇠를 획득한다. 24 | - 가장 기본적인 방식의 세마포어를 상호 배제(mutual exclusion, 줄여서 뮤텍스 mutex라 부름) 세마포어라 한다. 25 | 26 | ### 모니터와 세마포어의 차이 27 | - 모니터가 자물쇠의 획득과 해제를 모두 자동으로 처리해줘서 쓰기에 간단하다. 28 | - 세마포어는 획득한 자물쇠를 해제하는 작업을 일일이 해줘야한다. 29 | 30 | ### 경쟁 상황(레이스 컨디션, Race Condition) 31 | - `공유 자원`에 여러 프로세스/스레드가 동시에 접근하기 위해 `경쟁`하는 상태를 뜻한다. 32 | - ex) OS에서 CPU 점유율 등 33 | - `동기화 처리`를 제대로 하지 않으면 의도하지 않은 잘못된 결과가 나올 수 있다. 34 | 35 | > [전문](https://kodakyung.github.io/2019/07/17/OS-%EB%8F%99%EA%B8%B0%ED%99%94-Synchronization-%EC%99%80-%EC%9E%84%EA%B3%84-%EC%98%81%EC%97%AD-Critical-Section/) -------------------------------------------------------------------------------- /OS/Semaphore&Mutex-detail.md: -------------------------------------------------------------------------------- 1 | ## 세마포어(Semaphore) 2 | 3 | ![semaphore](images/semaphore.png) 4 | 공유된 자원에 여러 프로세스, 쓰레드가 동시에 접근하면서 문제가 발생하는데, 공유된 자원 속 하나의 데이터는 한번에 하나의 프로세스만 접근 할 수 있도록 제한해 두어야할 필요성이 잇는데, 이를 위해 고안된 것이 Semaphore(세마포어)이다. 즉, 한 프로세서가 사용하고 있는 동안에 세마포어를 세워서 다른 프로세서를 대기시키고 사용이 끝나면 해제시키는 방법으로 사용한다. 5 | 6 | ### Example) 7 | 8 | 하나의 공간에는 하나의 사람만이 들어갈 수 있습니다. 단, 이때 Key를 사용하여 그 공간에 접근이 가능합니다. 여러 사람들이 동시에 그 하나의 공간에 접근한다는것은 불가능하다는 말입니다. A,B,C,D 라는 사람이 그 공간에 들어가서 Task를 실행할 때 A라는 사람이 먼저 공간에 Key를 가지고 들어갔다고 가정하겠습니다. 그러면 B,C,D의 사람은 A라는 공간에 들어가기 위해 대기를 하게 되겠지요? 이사람들은 키를 가지고 있지 않습니다. 그러면 A라는 사람이 Task를 모두 수행한 후, 방에 나오면서 다음사람인 B에게 Key를 건내주게 되면서 B라는 사람은 그 공간에서 Task를 수행 할 것입니다. 9 | 계속해서 C,D라는 사람은 위와 같은 과정을 반복하게 됩니다. 방이 4개이면 열쇠도 4개이고 한사람이 들어갈때마다 방과 열쇠의 갯수가 1개씩 감소하게된다. 뮤텍스와 다르게 같은 방의 개수와 Key를 가져야한다. 10 | 간단히 말해, 빈 방의 열쇠의 갯수이다. 11 | 12 | ## 뮤텍스(Mutex) 13 | 14 | ![mutex](images/mutex.png) 15 | 16 | 17 | 쓰레드들 간에 공유가 배제되는 객체, 공유된 자원이 데이터를 여러 쓰레드가 접근하는것을 막는 것이다. 파일과 같은 공유 자원이 수행 중 오직 한 프로그램이나 스레드에게만 소유되어야 할 필요가 있을 때 그 자원에 대한 뮤텍스 객체를 생성시킨다. 뮤텍스가 비신호 상태이면 프로그램은 자원을 점유하여 사용한 후 이를 반환하고, 다른 프로그램 또는 다른 스레드가 자원을 사용 중 18 | 즉, 뮤텍스가 신호 상태이면 대기 상태로 들어가 끝나기를 기다린다. 뮤텍스는 여러 면에서 크리티컬 섹션(임계영역)과 비슷하고, 대신 사용할 수도 있지만 이름을 가질 수 있다는 점에서 크리티컬 섹션(임계영역)보다 우월하다. 19 | 간단히 말해, 방에 들어가기 위한 열쇠의 갯수이다. 20 | 21 | ### Example) 22 | 23 | 24 | 총 하나의 공간과 4명(A,B,C,D)가 있다고 가정하겠습니다. 그 중에 A라는 사람만 Key가 있다고 가정하겠습니다. Mutex에서는 무조건 1개의 Key만 가질 수 있습니다. 25 | 공간에 들어갈 수 있는 열쇠를 A가 가지고 있다면 A가 나와야지만 그 공간을 이용할 수 있습니다. 26 | 27 | 28 | # 세마포어와 뮤텍스의 차이점 29 | 30 | - 뮤텍스는 Key가 항상 1개이며, 세마포어는 Key를 여러개 가질 수 있습니다. 31 | - 세마포어는 뮤텍스가 될 수 있지만, 뮤텍스는 세마포어가 될 수 없다. 32 | - 세마포어는 파일시스템 상 파일형태로 존재, 뮤텍스는 프로세스 범위이다. 33 | - 세마포어는 소유할 수 없는 반면, 뮤텍스는 소유할 수 있습니다. 34 | - 뮤텍스의 경우, 뮤텍스를 소유하고 있는 쓰레드가 이 뮤텍스를 해제할 수 있습니다. 35 | - 세마포어의 경우, 세마포어를 소유하고 있지 않은 쓰레드도 이 세마포어를 해제할 수 있습니다. 36 | 37 | 38 | -------------------------------------------------------------------------------- /OS/DeadLock.md: -------------------------------------------------------------------------------- 1 | ## 교착 상태(Dead Lock) 2 | > 두 스레드가 서로 상대방이 쥐고 있는 자물쇠가 풀리기만을 기다리면서 서로 가로막고 있는 상황. 3 | 4 |
5 | 6 | - 두개의 서로 다른 스레드에서 서로 상대방이 필요로 하는 자원에 대한 락을 가지고 있는 경우에 발생 7 | - 멀티 프로그래밍 환경에서 한정된 자원을 사용하려고 경쟁하는 상황(`Race Condition`)에서 발생할 수 있다. 8 | 9 |
10 | 11 | - 프로세스가 자원을 요청했을 때 바로 사용할 수 없는 경우 프로세스는 대기 상태가 된다. 12 | - 대기 상태에서 프로세스들이 실행 상태로 변경될 수 없는 경우를 일컫는다. 13 | - 예를 들면 `Process1`과 `Process2`가 각각 `Resource A, B`를 얻어야 한다면, `P1`이 `A`를 선점하고 `P2`가 `B`를 선점한다면 두 프로세스는 무한정 기다리게 된다. 14 | 15 |
16 | 17 | - 보통 해결 방법은 한 스레드를 강제로 종료 시키는것 18 | - 가장 좋은 해결책은 데드락이 일어날 상황을 피하는 것이다. 19 | 20 | ### 데드락의 발생 조건 21 | - 상호 배제(Mutual Exclusion) 22 | : 자원은 한번에 한 프로세스만 사용할 수 있다. 23 | - 점유 대기(Hold and wait) 24 | : 최소 하나의 자원을 점유하고 있으면서 다른 프로세스에 할당되어 사용하고 있는 자원을 추가로 점유하기 위해 대기하는 프로세스가 있어야한다. 25 | - 비선점(No Preemption) 26 | : 다른 프로세스에 할당된 자원은 사용이 끝날 때까지 강제로 뺏을 수 없다. 27 | - 순환 대기(Circular wait) 28 | : 대기하고 있는 프로세스들은 순차적으로 앞의 프로세스가 점유한 자원에 대기하며 마지막 프로세스는 첫번째 프로세스가 점유한 자원을 요구한다. 29 | 30 | ### 데드락의 처리 31 | #### 예방(Prevention) 32 | : 교착 상태 발생 조건을 제거해 해결하는 방법. 33 | 34 | - 상호 배제 부정 35 | : 여러 프로세스가 공유 자원을 사용하도록한다. 36 | - 점유 대기 부정 37 | : 프로세스가 실행되기 전에 필요한 모든 자원을 할당하낟. 38 | - 비선점 부정 39 | : 자원을 점유하고 있는 프로세스가 다른 자원을 요구할 때 점유하고 있는 자원을 반납하고 요구한 자원을 사용하기 위해 기다리게한다. 40 | - 순환대기 부정 41 | : 자원에 고유한 번호를 할당해 번호 순서대로 자원을 요구하도록 한다. 42 | 43 | #### 회피(Avoidance) 44 | : 교착 상태가 발생하면 피하는 방법. 45 | 46 | - 은행원 알고리즘(Banker's Algorithm) 47 | : 프로세스가 자원을 요구할 때 시스템은 자원을 할당한 후에도 안정 상태인지 사전에 검사한다. 48 | : 안정상태에 있는 경우 자원을 할당하고 그렇지 않으면 다른 프로세스들이 자원을 해지할 때까지 대기한다. 49 | 50 | #### 탐지(Detection) 51 | : 자원 할당 그래프를 통해 교착 상태를 탐지한다. 52 | 53 | - 자원 요청할 때마다 탐지 알고리즘을 실행하기 때문에 오버헤드가 발생한다. 54 | 55 | #### 회복(Recovery) 56 | : 교착 상태를 일으킨 `프로세스를 종료`하거나, 할당된 `자원을 해제`해 회복하는 방법. 57 | 58 | - 프로세스 종료 59 | - 교착 상태의 프로세스를 모두 중지한다. 60 | - 교착 상태가 제거될 때까지 한 프로세스씩 중지한다. 61 | - 자원 선점 62 | - 교착 상태의 프로세스가 점유하고 있는 자원을 선점해 다른 프로세스에세 할당해 해당 프로레스를 일시 정지 시킨다. 63 | - 우선 순위가 낮은 프로세스, 수행된 횟수가 적은 프로세스 등을 위주로 프로세스 자원을 선점한다. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # IT Coding interview preparation 2 | 3 | ## Proceeding 4 | ### Infra 5 | - [Docker](/Infra/Docker.md) 6 | - [MSA (vs Monolithich, vs SOA)](/Infra/msa.md) 7 | - [Virtualization](Infra/Virtualization.md) 8 | - [Container](/Infra/Container.md) 9 | - [Kubernetes](/Infra/Kubernetes.md) 10 | 11 | ### OS 12 | - [Process](/OS/Process.md) 13 | - [Thread](/OS/Thread.md) 14 | - [Preemptive vs Non-Preemptive Scheduling](/OS/Scheduling.md) 15 | - [Process Control](/OS/ProcessControl.md) 16 | - [Semaphore & Mutex & Critical Section](/OS/Semaphore&Mutex.md) 17 | - [Semaphore & Mutex(detail)](/OS/Semaphore&Mutex-detail.md) 18 | - [Critical Section(detail)](/OS/CriticalSection-detail.md) 19 | - [DeadLock](/OS/DeadLock.md) 20 | - [Synchronization](/OS/Synchronization.md) 21 | - [Transaction](/OS/Transaction.md) 22 | - [IPC(Inter Process Communication)](/OS/IPC.md) 23 | - [Memory - Heap & Stack](/OS/memory.md) 24 | - [Virtual Memory](/OS/virtualMemory.md) 25 | - [Memory Allocation & Relocation](/OS/MemoryAllocation.md) 26 | - [Paging & Segmentation](/OS/Paging&Segmentation.md) 27 | 28 | ### Database 29 | - [Transaction(Commit&Rollback)](/Database/Commit&Rollback.md) 30 | - [MySQL MyIsam vs InnoDB](/Database/MysqlEngine.md) 31 | 32 | 33 | ### SoftwareEngineering 34 | - [Agile](/SoftwareEngineering/Agile.md) 35 | 36 | ### Network 37 | - [HTTP&HTTPS](/Network/HTTP&HTTPS.md) 38 | - [SSL](/Network/SSL.md) 39 | - [OSI 7 Layer](/Network/OSI_7_Layer.md) 40 | 41 | ### DesignPattern 42 | - [Builder](/DesignPattern/Builder.md) 43 | 44 | ### System 45 | - [Compiler](/System/Compiler.md) 46 | 47 | ### Spring 48 | - [Bean](/Spring/Bean.md) 49 | - [IoC(Inversion of Control) & DI(Dependency Injection)](/Spring/IoC&DI.md) 50 | - [AoP(Aspect-Oriented Programming)](/Spring/AspectOrientedProgramming.md) 51 | 52 | ### DataStructure 53 | - [Array vs List](/DataStructure/ArrayVSList.md) 54 | 55 | ### Java 56 | - [OOP](/Java/OOP.md) 57 | - [Generic](/Java/Generic.md) 58 | 59 | ## Intended 60 | 61 | * Design Pattern 62 | * Cloud 63 | * DevOps 64 | * etc.. 65 | 66 | ## Mark-down rules 67 | 68 | * One Day, One Commit 69 | -------------------------------------------------------------------------------- /Network/SSL.md: -------------------------------------------------------------------------------- 1 | # SSL(`Secure Socket Layer`)이란? 2 | 3 | `Certificate Authority(CA)`라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용 4 | 5 | **클라이언트와 서버 간에 공유하는 암호화키를 가지고 암호화된 데이터가 송수신되는 방식** 6 | 7 | HTTP 프로토콜 상위에 통신시 보안을 위한 SSL 관련 프로토콜이 있는 것임. 8 | 9 | 10 | 11 | # SSL의 암호화 - 대칭키 12 | 13 | > 암호화를 할 때 사용하는 일종의 비밀번호는 키(key) 14 | 15 | **동일한 키로 암호화와 복호화를 같이 할 수 있는 방식의 암호화 기법** 16 | 17 | 18 | 19 | * 단점 : 암호를 주고 받는 사람들 사이에 대칭키를 전달하는 것이 어렵다. 대칭키가 유출되면 암호가 무용지물이다. 20 | 21 | 22 | 23 | # SSL의 암호화 - 공개키 24 | 25 | **두 개의 키를 가져, A키를 암호화하면 B키로 복호화할 수 있고 B키로 암호화하면 A키로 복호화할 수 있는 방식** 26 | 27 | > * 두 개의 키 중 하나를 비공개키(private key, 개인키, 비밀기), 다른 하나를 공개키(public key)로 지정 28 | > * 비공개키는 자신만 가지고 있고, 공개키를 타인에게 제공 29 | > * 타인은 제공 받은 공개키를 이용해서 정보를 암호화 30 | > * 비공개키를 이용해서 암호화된 정보를 복호화 31 | > * 공개키가 유출되더라도 비공개키를 모르면 정보를 복호화할 수 없기 때문에 안전함 32 | 33 | 34 | 35 | ### 전자 서명 36 | 37 | > * 비공개키의 소유자는 비공개키를 이용해서 정보를 암호화 38 | > * 공개키와 함께 암호화된 정보를 전송 39 | > * 전송받은 곳에서 공개키를 이용해서 암호화된 정보를 복호화 40 | > 41 | > => 데이터를 제공한 사람의 신원을 보장하는 것임. 42 | 43 | 44 | 45 | # SSL 인증서 46 | 47 | **클라이언트와 서버 간의 통신을 제 3자가 보증해주는 전자화된 문서** 48 | 49 | > * 클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 이 인증서 정보를 전달함. 50 | > 51 | > * 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증함. 52 | 53 | 54 | 55 | * 이점 56 | 57 | : 통신 내용이 공격자에게 노출되는 것을 막을 수 있음. 58 | 59 | : 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 판단할 수 있음. 60 | 61 | : 통신 내용의 악의적인 변경을 방지할 수 있음. 62 | 63 | 64 | 65 | # CA 66 | 67 | **클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할** 68 | 69 | > CA(Certificate authority), Root Certificate : 이 역할을 하는 민간 기업 70 | 71 | > CA를 통해서 인증서를 구입해서 제공하면 브라우저의 주소창이 안전 표시를 해줌. 72 | 73 | 74 | 75 | # SSL 인증서의 내용 76 | 77 | 1. 서비스의 정보(인증서를 발급한 CA, 서비스 도메인 등) 78 | 2. 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법) 79 | 80 | => CA는 자신의 공개키를 이용해서 서버가 제출한 인증서를 암호화함. 81 | 82 | 83 | 84 | # TLS(`Transport Layer Security Protocol`)란? 85 | 86 | SSL과 같음. Netscape에서 SSL이 발명되었고, 이것이 점차 폭넓게 사용되어 표준화 기구인 IETF의 관리로 변경되면서 이름이 바뀌었음. TLS 1.0은 SSL 3.0을 계승함. 87 | 88 | 89 | 90 | # 요약 91 | 92 | * SSL이란 HTTP 프로토콜 위에서 클라이언트와 서버가 통신할 때 암호화를 하는 프로토콜이 있는 방식 93 | * 공개키 방식이란 비공개키 하나와 공개키 하나를 만들어, 정보를 보내는 쪽에서 공개키로 암호화해서 보내면 비공개키로 복호화하는 방식. (비공개키를 모르면 복호화를 할 수 없어 안전함) 94 | * 클라이언트가 서버에 접속하면 서버에서 인증서를 보내줌. 인증서는 서버의 비밀키로 암호화되어 있음. 클라이언트는 인증서에 들어있는 공개키로 정보를 복호화함. 복호화가 되면 서버를 신뢰할 수 있게 됨. -------------------------------------------------------------------------------- /Infra/Container.md: -------------------------------------------------------------------------------- 1 | - [Kubernetes](/Infra/Kubernetes.md) 2 | - [Docker](/Infra/Docker.md) 3 | 자세한 쿠버네티스와 도커의 내용은 위 링크에서 자세하게 살펴보실 수 있습니다. 4 | 5 | # 컨테이너란 무엇인가? 6 | 사전적 의미로 컨테이너는 어떤 물체를 격리하는 공간을 뜻한다. 클라우드 분야에서 컨테이너는 다음과 같은 의미를 갖는다. **컨테이너는 애플리케이션과 애플리케이션을 구동하는 환경을 격리하는 공간을 뜻한다** 사실 컨테이너 기술은 새로운 개념이 아닌, 약 10여 년 전에 리눅스에 내장된 기술이다. 7 | 8 | # 컨테이너를 사용하는 이유는 무엇인가? 9 | 10 | 서버 장비들은 컴퓨팅 환경을 소프트웨어로 구현한 가상머신(VM: Virtual Machine)을 사용한다. 이 서버들은 다수의 운영체제를 동시에 실행하기 위해 하이퍼바이저가 필요하고, 그 상위 계층에 Guest OS가 각각 설치된 가상머신들을 구동시킨다. 11 | 반면에 컨테이너로 구성된 서버는 하이퍼바이저를 사용하지 않고 CPU, RAM, Disk, Network과 같은 운영체제의 자원을 필요한 만큼 격리하여 컨테이너에 할당한다. 12 | 13 | ![container_image](./images/container_image.png) 14 | 15 | # 컨테이너의 장점 16 | 17 | * 컨테이너는 효율성이 높다 18 | 19 | 기업들은 실제 애플리케이션 서비스를 안정적으로 운영하기 위해 1개의 가상머신에 1개의 서비스를 구동하는것이 권장. 20 | 하지만, 해당 애플리케이션이 가상머신의 모든 자원을 사용하는 것이 아니기 때문에 유휴 자원이 생겨서 성능적 오버헤드가 발생할 수 있다. 21 | 반면 컨테이너의 경우, 운영체제의 자원을 공유하기 때문에 애플리케이션 실행시 필요만큼만 자원을 할당한다. **즉, 서버 전체 자원을 효율적으로 사용 할 수 있다.** 22 | 23 | 24 | 25 | * 컨테이너는 신속성이 높다 26 | 27 | 기업들은 서비스 추가 및 확장을 위해 가상머신을 추가로 배포해야하는 상황이 생기는데, 이때 비용과 시간이 많이 소요된다.(최소 몇 GB) 28 | 하지만, 컨테이너의 경우 구조적으로 Guest OS가 없기 때문에 용량이 MB 단위로 작다. 컨에티너는 배포에 드는 시간이 수초 밖에 안걸린다는 엄청난 장점을 갖고 있다. 29 | 30 | * 라이센스 비용이 절감된다. 31 | 32 | 가상화 서버의 경우 가상머신의 개수 만큼 Guest OS의 EnterPrise용 라이센스 비용이 발생하는데, 컨테이너 서버의 경우에는 Host OS1대의 라이센스 비용만 발생하여 비용적으로 매유 효율적이다. 또한, 추가로 많은 서버를 구축해야할 시에, 가상화 서버와 컨테이너 서버 사이의 라이센스로 인해 발생하는 비용의 차이는 엄청날 것이다. 33 | 34 | # 컨테이너 단점 35 | 36 | * 무리한 자원 할당 37 | 가상 머신의 경우 할당된 자원 내에서 가상머신이 운영되므로, 안정적으로 운영 할 수 있다. 하지만, 컨테이너는 OS커널을 공유하기 때문에 하나의 컨테이너가 무리하게 자원을 사용하게 되는 경우가 발생한다. 자원 할당량을 사전에 지정시켜 줄 수 있지만, 이런 상황이 발생하면 컨테이너는 장애가 발생한다. 이때 컨테이너의 장애가 발생할 때 **쿠버네티스로** 해결이 가능하다. 38 | 39 | # 컨테이너의 응용 40 | 41 | * 개발 환경 이전 솔루션 42 | 43 | 44 | * 마이크로 서비스화 솔루션 45 | 기업에서 운영하는 애플리케이션은 하나의 큰 덩어리처럼 구성되어 있기 때문에 용량이 매우 큽니다. 이런 애플리케이션은 배포할 때 오랜 시간이 소요되고, 때로는 작은 부분의 수정사항이 애플리케이션 전체에 장애를 유발할 수 있습니다. 이런 거대한 애플리케이션을 기능별로 나누어 변경과 조합이 가능하게 한 것을 **마이크로 서비스(Micro Service)** 이다. 46 | 47 | ![microsolution](./images/microsolution.png) 48 | 49 | * 마이크로 서비스 장점 50 | 51 | 마이크로 서비스를 구성할 때 컨테이너를 사용하면 하나의 애플리케이션을 기능 혹은 서비스 단위로 신속하게 배포할 수 있다. 52 | 또한, 컨테이너는 기본적으로 독립적인 구조이기 때문에 하나의 변경사항이 분리된 다른 기능들에게 영향을 미치지 않는다. 53 | 54 | 55 | 56 | ### Reference 57 | https://developer.ibm.com/kr/cloud/2019/02/01/easy_container_kubernetes/ 58 | 59 | https://developer.ibm.com/kr/cloud/2019/02/01/easy_container_kubernetes/ 60 | 61 | http://bongbonge.tistory.com/entry/컨테이너-기술에-대한-이해 62 | -------------------------------------------------------------------------------- /Infra/msa.md: -------------------------------------------------------------------------------- 1 | # MSA(Micro Service Architecture) 2 | 3 | ## 모놀리스 아키텍처(Monolithic Architecture) 4 | - `모든 업무 로직`이 `하나의 애플리케이션` 형태로 패키지 되어 서비스되고 애플리케이션에서 사용하는 `데이터 또한 한 곳`에 모인 데이터를 참조하여 서비스하는 형태 5 | - 단점: 비즈니스 변화가 빠르고 수시로 앱을 변경해서 사용해야하는 환경에서는 하나의 앱으로 `유연`하게 대처하기 어려움. 6 | - 프로그램의 일부만 수정해도 관련없는 기능들까지 전부 다시 빌드해 배포해야함. 연속성을 위한 2중화 3중화 장비들에도 순차적으로 배포하고 재기동하는 시간, 노력이 듬. 7 | 8 | ## 마이크로 서비스 아키텍처(MSA, MicroService Architecture) 9 | - 간단히 말하면 단일 어플리케이션을 `작은 어플리케이션`으로 `나누어 서비스` 하는 것. 10 | 11 | ### 마이크로 서비스 아키텍처의 개념 12 | - 아주 작은 단위의 서비스들을 실행할 수 있도록 구성하기 위한 `서비스 중심`의 아키텍처. 13 | - 마이크로 서비스 아키텍처는 소프트 아키텍처 구성 중 하나의 스타일 14 | - `마이크로 서비스`로 이루어져 있음 15 | - 서비스와 데이터가 분할되어 작은 서비스들이 여러 `독립적 형태`로 `서비스를 제공` 16 | - 필요에 따라 서로 `참고`해 사용되기도 함. 17 | - 애플리케이션 기능뿐만 아니라 `데이터까지 분리`해 격리된 독립된 환경으로 구성된다는 것이 차이점 18 | 19 | ### 마이크로 서비스 아키텍처와 모놀리스 아키텍처의 차이점 20 | #### 모놀리스 아키텍처 21 | - 하나의 어플리케이션에 데이터가 연결된 구성이 일반적. 22 | - **따라서 크기가 클수록 변경과 배포가 쉽지 않은 구조** 23 | - `단일 어플리케이션`이기 때문에 클라이언트의 요청에 대한 `처리 반응 속도`가 아주 중요 24 | - 데이터 조회에 대한 부하나 이를 처리하는 앱에 문제가 생긴다면 시스템이 동작하지 않게 됨. 25 | - 이를 대응 하기 위해 `로드 밸런서`, `2중화` , `3중화`, `백업 및 복구 방안`이 아주 중요 26 | - `환경 구성`을 위해 `많은 시스템 리소스`를 투자함 27 | - **시스템 부하를 분석해 하드웨어 스케일업 과정과 앱의 빠른 대응과 데이터 조회의 성능 개선을 위한 튜닝 활동들이 아키텍트들의 주 관심** 28 | #### 마이크로 서비스 아키텍처 29 | - 마이크로 서비스 아키텍처는 보다 `수평적`으로 `유연성`과 `탄력성`을 가짐. 30 | - 하지만 많은 서비스를 관리하고 제어하는 `에코시스템`의 역할이 중요하고 31 | - `자동화`, `시각화`가 고려되지 않으면 오히려 운영 측면에서 리스크가 증가함. 32 | 33 | ## 서비스 지향 아키텍처(SOA, Service Oriented Architecture) 34 | - 대규모 시스템 환경에서 업무 처리 단위를 데이터 중심이 아닌 `전체 시스템을 중심`으로 설계하는 아키텍처 스타일 35 | - MSA가 주목받기 전부터 주로 사용 36 | - 서비스 단위로 개발하여 호출 가능한 상태로 만듦, 따라서 `중복`되는 프로세스나 업무들을 피할 수 있음. 37 | ### 마이크로 서비스 아키텍처와 서비스 지향 아키텍처의 차이점 38 | #### 공통점 39 | - `비즈니스 변화 대응`을 위한 서비스 중심의 아키텍처 40 | - 기능 중심의 모듈 재사용보다 상위 수준의 `서비스 수준에서의 재사용성` 초점 41 | 42 |
43 | 44 | - SOA : 비즈니스 측면에서의 서비스 재사용성 강조 45 | - 많은 서비스의 `공유`를 위해 `ESB(Enterprise Service Bus)` 서비스 채널에서 서비스를 공유, 재사용 46 | - MSA : 한가지 작은 서비스에 집중 47 | - 서비스를 공유하지 않고 `독립`되어 실행하는 것을 지향함 48 | 49 | #### 차이점 50 | - 서비스의 상대적 크기와 관심사, 오너십, 기술 구조 51 | 52 | 1. 서비스의 상대적 크기와 관심사 53 | - SOA : `비즈니스`에 집중 54 | - MSA : `작은 서비스 하나`에 집중. 55 | 2. 서비스 오너십 측면 56 | - SOA : 비즈니스 프로세스의 흐름을 알아야 하기 때문에 업무, 공통 기능 개발팀, 개발팀 간 `상호 협업`이 필수 57 | - MSA : `하나의 작은 팀`에서 관리, 개발-운영-오너십, 권한까지 관리 58 | 3. 서비스 공유 정도의 차이 59 | - SOA : 되도록 `많은 서비스 공유` 지향 > 재사용성을 높여 비용을 절감하고 품질을 높이는데 초점 60 | - MSA : `공유 최소화` 지향 > 서비스간 결합도를 낮추어 변화에 능동적으로 대응하기 위한 민첩성에 초점 61 | 4. 기술 방식의 차이 62 | - SOA : 공통의 서비스를 EBS라는 `공통 채널`에 모아 사업 측면에서 공통 서비스 형식으로 서비스를 제공 63 | - MSA : 각각 독립된 서비스가 필요에 따라 노출된 `REST API`를 사용 -------------------------------------------------------------------------------- /Infra/Kubernetes.md: -------------------------------------------------------------------------------- 1 | 2 | - [Container](/Infra/Container.md) 3 | 4 | - [Docker](/Infra/Docker.md) 5 | 6 | 자세한 컨테이너와 도커의 내용은 위 링크에서 자세하게 살펴보실 수 있습니다. 7 | 8 | 9 | 10 | # 쿠버네티스란? 11 | 12 | 13 | 14 | 컨테이너가 엄청 많아지면 관리와 운영이 어려워져서 오히려 운영상의 효율성이 떨어진다. 이때, 쿠버네티스(Kubernetes)를 사용하여 해결해주는 도구의 역할을 한다. 15 | 16 | *쿠버네티스는 컨테이너 오케스트레이션 플랫폼 중 하나로, 구글이 자사 서비스를 위해 개발했던 오픈소스* 17 | 18 | 19 | 20 | * 컨테이너 플랫폼 21 | 22 | * 유명한 컨테이너 플랫폼으로는 ****Docker**** 가 있음. 23 | 24 | * 마이크로서비스 플랫폼 25 | 26 | * 이식성 있는 클라우드 플랫폼 27 | 28 | 29 | 30 | # 쿠버네티스 장점 31 | 32 | 33 | 34 | * 무중단(Fault tolerance-FT) 서비스를 제공 35 | 36 | 쿠버네티스를 사용하게되면 점진적인 업데이트를 제공하기 때문에 서비스를 중단하지 않고도 애플리케이션을 업데이트 할 수 있음. 37 | 38 | 또한, 쿠버네티스는 자가 회복(Self Healing)기능이 있기 때문에 특정 컨테이너에 갑작스러운 장애가 발생하더라도 *곧바로 복제 컨테이너를 생성해서 서비스를 유지* 할 수 있다. 39 | 40 | 41 | 42 | * Vendor Lock In 해결 43 | 44 | 45 | 46 | 고객이 A사의 클라우드를 사용하다가 B사의 클라우드로 환경을 이전하고 싶을 때, 서로 다른 업체(Vendor)의 클라우드 제품간에 호환문제가 발생하여 이전하기 어려운 상황을 Vendor Lock In이라고 한다. **쿠버네티스는 도커 컨테이너 기반으로 하는 오픈소스 이기 때문에 사용자들이 특정 업체에 종속되지 않고 클라우드 환경** 들을 이전 할 수 있다. 47 | 48 | 49 | 50 | # 쿠버네티스의 특징 51 | 52 | 53 | 54 | ## Kubernetes는 컨테이너 관리 표준 55 | 56 | ### 컨테이너를 효과적으로 배포할 수 있는 툴 57 | 58 | - Container 자체를 묶으면 너무 low level로 묶이기 때문에 pod을 이용 59 | 60 | - 여러 개의 컨테이너는 하나의 Pod이라는 단위로 묶음 61 | 62 | - Pod내 내에서 컨테이너들을 IP와 스토리지를 공유 63 | 64 | 65 | 66 | ## Kubernetes가 없는 컨테이너 환경 67 | 68 | - 각 컨테이너가 독립적으로 실행 69 | 70 | - 각자 다른 IP/NETWORK로 통신 71 | 72 | - 서로 다른 노드에 설치될 수도 있음. 73 | 74 | - 컨테이너끼리 디스크 자원을 공유할 수 없음 75 | 76 | 77 | 78 | ## Kubernetes 아키텍쳐 79 | 80 | - Kubernetes Master가 Kubernetes Node들을 관리 81 | 82 | ### Kubernetes Node 특징 83 | 84 | 1. 여러 개의 Pod를 갖고 있음 85 | 86 | 2. Kubelet을 갖고 있음 - Master API Server와 통신 87 | 88 | 3. cAdvisor를 갖고 있음. 89 | 90 | 4. Kube-Proxy를 갖고 있음 - Pod들간의 통신을 할 때 컨테이너 이름을 기준으로 통신을 할 수 있게 해줌 91 | 92 | 93 | 94 | ## Kubernetes Master 특징 95 | 96 | - API Server를 갖고 있음 97 | 98 | - Contoller Manager를 갖고 있음 99 | 100 | - etcd를 갖고 있음 101 | 102 | - 모든 메타 정보를 갖고 있음 103 | 104 | ## Kubernetes Ingress 105 | 106 | ### Ingress 107 | 108 | - L7 로드밸런서 - L7와 L4 달리 패킷의 유무를 볼 수 있음. 109 | 110 | - URI 기반으로 서비스 별 라우팅 111 | 112 | - 서비스 앞 단에 위치 - 하나의 Ingress는 많은 서비스를 관리 113 | 114 | - Google Cloud의 로드 밸런서 115 | 116 | 117 | 118 | ### Reference 119 | 120 | https://developer.ibm.com/kr/cloud/2019/02/01/easy_container_kubernetes/ 121 | 122 | 123 | 124 | https://developer.ibm.com/kr/cloud/2019/02/01/easy_container_kubernetes/ 125 | 126 | 127 | 128 | http://bongbonge.tistory.com/entry/컨테이너-기술에-대한-이해 129 | -------------------------------------------------------------------------------- /OS/Process.md: -------------------------------------------------------------------------------- 1 | # 프로세스란? 2 | 3 | 프로그램의 명령어와 정적 데이터가 메모리에 `적재`되면 생명이 있는 `프로세스`이다. 4 | 5 | => `실행 중인 프로그램` 6 | 7 | 8 | 9 | * 프로그램 10 | 11 | > 보조 기억장치(하드디스크, SSD)에 존재하며, 실행되기를 기다리는 명령어(코드)와 정적인 데이터의 묶음 12 | 13 | 14 | 15 | # 어떻게 여러 개의 프로세스가 동시에 실행될 수 있을까? 16 | 17 | > 하나의 CPU(프로세서)는 한 순간에 하나의 프로세스만 실행할 수 있다. 18 | 19 | `운영체제`가 매우 빠르게 CPU가 실행할 프로세스를 교체하고 있기 때문이다. 20 | 21 | 22 | 23 | # 프로세스는 어떻게 구성되어 있을까? 24 | 25 | 프로세스에 대한 정보는 **프로세스 제어블록(PCB, Process Control Block)** 또는 **프로세스 기술자(process descriptor)**라고 부르는 자료구조에 저장됨. PID, 프로그램 정보, 상태, 순위 등을 저장하고 있음. 26 | 27 | 28 | 29 | * **PID(Process IDentification)** 30 | 31 | > 운영체제가 각 프로세스를 식별하기 위해 부여된 프로세스 식별번호 32 | 33 | * **프로세스 상태** 34 | 35 | > 실행 중이거나 대기 중인지 36 | 37 | * **프로그램 카운터** 38 | 39 | > CPU가 다음으로 실행할 기계어가 저장된 메모리 주소를 가리키는 값 40 | 41 | * **스케줄링 우선순위** 42 | 43 | > 여러 개의 프로세스가 CPU에서 실행되는 순서 44 | 45 | * **권한** 46 | 47 | > 프로세스가 접근할 수 있는 자원을 결정하는 정보 48 | 49 | * **프로세스의 부모와 자식 프로세스** 50 | 51 | > 모든 프로세스는 부모 프로세스를 복제해서 생성됨. 이 계층관계는 트리를 형성함. (최초로 생성되는 init 프로세스 제외) 52 | 53 | * **프로세스의 데이터와 명령어가 있는 메모리 위치를 가리키는 포인터** 54 | 55 | * **프로세스에 할당된 자원들을 가리키는 포인터** 56 | 57 | * **실행 문맥** 58 | 59 | > 프로세스가 실행 상태에서 마지막으로 실행한 프로세서의 레지스터 내용. 프로세스가 교체될 때 연속적으로 실행된 것처럼 하기 위해 갖고 있음. 60 | 61 | 62 | 63 | 64 | 65 | # 프로세스가 접근할 수 있는 메모리 공간 66 | 67 | ![](https://t1.daumcdn.net/cfile/tistory/2453685056EEACBE22) 68 | 69 | 70 | 71 | 72 | 73 | # 프로세스는 어떻게 관리될까? 74 | 75 | 운영체제는 프로세스를 교체하고 재시작할 때 오류가 발생하지 않도록 프로세스의 상태를 `실행(running)`, `준비(ready)`, `블록(block)` 상태로 분류하고 프로세스들을 `상태전이(state trasition)` 를 통해 체계적으로 관리함. 76 | 77 | 78 | 79 | 1. 사용자가 프로그램을 실행하면 프로세스가 생성되고 준비리스트에 추가됨. 80 | 81 | 2. 프로세스는 프로세서(CPU)가 사용 가능한 상태가 되면 할당 받음. 82 | 83 | 3. 준비 상태에서 실행 상태로 상태전이됨(`디스패칭(dispatching)`) 84 | 85 | 4. 프로세스는 실행 상태에서 CPU를 이용해 연산 후 자발적으로 반납하고 작업이 끝나지 않았으면 `다시 준비상태` 에 들어감. 86 | 87 | 5. 프로세스를 다시 사용하기 전에 입출력이 완료되기를 기다려야 하는 상황이면 완료될 때까지 자신을 `블록` 함. 88 | 89 | 90 | 91 | # 프로세스가 CPU를 독점하는 경우를 방지하기 위해 어떻게 할까? 92 | 93 | 운영체제는 하드웨어적으로 `인터럽팅 클록` 을 주기적으로 발생시켜 프로세스가 **특정 시간 간격동안** 만 실행할 수 있도록 함. 운영체제는 강제로 실행중인 프로세스의 CPU 제어권을 뺏고 프로세스는 준비 상태로 상태전이됨. 94 | 95 | 96 | 97 | 98 | 99 | # 문맥 교환(Context Switching)이란? 100 | 101 | => CPU가 인터럽트 요청에 의해 현재 처리중인 프로세스의 PCB(문맥)을 따로 저장하고 다음 우선순위의 PCB를 가져오는 것 102 | 103 | CPU는 동시에 여러 프로세스를 처리하는 것이 아니라 IO인터럽트나 시스템 콜에 의해 여러 프로세스를 교체하며 처리함. 104 | 105 | 106 | 107 | # 문맥교환의 절차 108 | 109 | 1. **인터럽트/시스템 호출** : 운영체제에서 프로세스 스케줄러에 의해 인터럽트 발생 110 | 2. **커널 모드 전환** : 프로세스가 실행되는 사용자 모드에서 커널 모드로 전환 111 | 3. **현재 프로세스 상태 PCB 저장** : 기존 실행되는 프로세스 정보를 PCB에 저장 112 | 4. **다음 실행 프로세스 로드** : PCB에 있는 다음 실행 프로세스 상태 정보 복구 113 | 5. **사용자 모드 전환** : 커널 모드에서 사용자 모드로 전환하여 프로세스 실행 114 | 115 | 116 | 117 | * dispatch, timeout 등 실행 상태가 전이되는 과정에서 발생함 118 | 119 | 120 | 121 | # 시분할 처리(time-sharing)란? 122 | 123 | 시간을 쪼개어 하나의 처리 장치에서 두 개 이상의 처리를 가능하게 함 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | -------------------------------------------------------------------------------- /Network/OSI_7_Layer.md: -------------------------------------------------------------------------------- 1 | # OSI 7 계층이란? 2 | 3 | * 개방형 시스템 상호연결(`Open System Interconnection`) 모델 4 | * 네트워크에서 통신이 일어나는 과정을 7단계로 나눈 표준 5 | 6 | ![](https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcScoYPnLyRhdeidfIT_7pSf_j8oAgMuPBlrcm1HQ4P8oaY0n_NqUA) 7 | 8 | 9 | 10 | # 나눈 이유? 11 | 12 | * 통신이 일어나는 과정을 단계별로 파악하기 위해 13 | * 표준화를 통해 장비별로 포트나 프로토콜의 문제를 줄여 비용 절감 14 | * 엔지니어의 전반적인 설계와 문제해결의 이해를 도와 효율적인 업무를 수행하도록 15 | 16 | 17 | 18 | # 캡슐화 19 | 20 | * 데이터를 전송할 때 각각의 층마다 인식할 수 있는 `헤더`를 붙이는 것 21 | * **디캡슐레이션** : 데이터를 전송한 후 계층을 올라가면서 헤더가 벗겨지는 과정 22 | * 2계층에서는 오류제어를 위해 꼬리 부분에 씌워짐 23 | 24 | 25 | 26 | # PDU(Process Data Unit) 27 | 28 | * **각 계층에서의 전송되는 단위** 29 | * 1계층은 PDU라고 하지 않음, 단지 신호의 흐름 30 | * 2계층 - `Frame`, 3계층 - `Packet`, 4계층 - `Segment` 31 | 32 | 33 | 34 | # 1계층 : 물리 (Physical) 35 | 36 | * 주로 **전기적, 기계적, 기능적인 특성**을 이용해서 통신 케이블로 데이터를 전송하게 됨. 37 | 38 | * 사용되는 통신 단위는 `비트` (1 / 0, On / Off) 39 | 40 | * 데이터를 **전기 신호로 변환**해서 `전송`만 함. 41 | 42 | * 어떤 데이터인지는 신경쓰지 않음. 43 | 44 | * `케이블, 리피터, 허브`를 통해 데이터를 전송함. 45 | 46 | * 기본적인 물리적 연결기의 전기적 명세를 정하고 네트워크의 두 노드를 물리적으로 연결시켜 주는 신호방식을 다룸. 47 | 48 | 49 | 50 | > 전선, 전파, 광섬유, 동축케이블, 도파관, PSTN, Repeater, DSU, CSU, Modem 51 | 52 | 53 | 54 | # 2계층 : 데이터 링크 (DataLink) 55 | 56 | - 물리 계층을 통해 송수신되는 정보의 **오류와 흐름을 관리**함. 57 | 58 | - 통신에서의 **오류를 찾고 재전송** 하는 기능 59 | 60 | - `MAC 주소` 를 가지고 통신 61 | 62 | - 전송되는 단위는 프레임(`Frame, 비트의 모음`) : **주소와 제어정보**를 가짐. 63 | 64 | - `브리지, 스위치` 장비 이용 65 | 66 | 67 | 68 | > **이더넷**, Token Ring, PPP 69 | 70 | 71 | 72 | > **포인트 투 포인트(Point to Point) 간 신뢰성 있는 전송을 보장하기 위한 계층** 73 | > 74 | > HDLC, ADCCP (point to point 프로토콜) 75 | > 76 | > 패킹 스위칭 네트워크, LLC, ALOHA (근거리 네트워크용 프로토콜) 77 | 78 | 79 | 80 | > 네트워크가 만들어질 때부터 맥 주소가 정해져 있음. 81 | > 82 | > 주소 체계는 계층이 없는 단일 구조 83 | 84 | 85 | 86 | # 3계층 : 네트워크 (Network) 87 | 88 | * 다중 네트워크 링크에서 **패킷(`Packet`)** 을 발신지로부터 목적지로 전달할 책임을 가짐 89 | * 전송 단위는 패킷(`Packet`) 90 | * 중계 노드를 통하여 전송하는 경우 어떻게 중계할 것인가를 규정함. `경로 설정`을 함. 91 | * 논리적인 주소 구조(IP)를 네트워크 관리자가 직접 할당함. 계층적임. 92 | 93 | * `라우터, L3 스위치` 장비 이용 94 | 95 | 96 | 97 | ### 라우팅 98 | 99 | * 데이터를 목적지까지 가장 안전하고 빠르게 전달하도록 함. 100 | 101 | 102 | 103 | > IP, ICMP, IGMP 104 | 105 | 106 | 107 | # 4계층 : 전송 (Transport) 108 | 109 | * 발신지에서 목적지 즉, 종단 간(End-to-End)에 신뢰성 있고 정확한 데이터 전송을 담당함. 110 | * 전송 단위는 세그먼트(`Segment`) : 종단 간의 `에러 복구와 흐름 제어`를 담당 111 | 112 | * 패킷들의 전송이 유효한지 확인하고 실패한 패킷은 다시 보내는 등 `신뢰성 있는 통신을 보장`함. 113 | 114 | * 상위 계층이 데이터 전달의 유효성이나 효율성을 신경쓰지 않도록 함. 115 | 116 | * 포트를 열어서 응용 프로그램들이 데이터를 전송할 수 있게 함. 117 | 118 | * 데이터를 하나로 합쳐 5개층에 던짐. 119 | 120 | 121 | 122 | > **TCP**(Transmission Control Protocol), **UDP**(User Datagram Protocol) 123 | 124 | 125 | 126 | 127 | 128 | # 요약(..to be continued) 129 | 130 | 131 | 132 | * OSI 7계층에는 물리, 데이터 링크, 네트워크, 전송, 세션, 표현, 응용 계층이 있습니다. 133 | * 1계층인 물리 계층은 케이블, 허브나 리피터를 이용하여, 데이터를 전기 신호로 바꿔주는 역할을 합니다. 134 | * 2계층인 데이터 링크 계층은 브리지나 스위치를 이용하여, 전송되는 데이터의 오류와 흐름을 관리합니다. 이 때 MAC 주소를 이용하여 데이터를 전송합니다. 135 | * 3계층인 네트워크 계층은 라우터를 이용하여, 여러 개의 노드를 지날 때 경로를 정해서 패킷을 목적지까지 가장 빠른 길로 전송합니다. IP 프로토콜이 가장 대표적으로, IP 주소를 부여하고, 전송시 에러 발생을 신경 쓰지 않습니다. 136 | * 4계층인 전송 계층은 실제 데이터의 전송을 담당합니다. TCP와 UDP 프로토콜이 대표적으로, TCP는 데이터 전송시 에러가 발생하면 에러 부분을 재전송합니다. 따라서, 신뢰성 있는 데이터 전송을 보장합니다. 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | -------------------------------------------------------------------------------- /Database/Commit&Rollback.md: -------------------------------------------------------------------------------- 1 | # 1. What is transaction Processing? 2 | 3 | 데이터베이스의 상태를 바꾸는 기능을 수행하기 위한 작업의 단위 4 | 5 | # 2. What is Commit and Rollback in a database? 6 | 7 | ## Commit 8 | 9 | * 작성한 쿼리문에서 Update, Delete, Insert를 수행했을 때, 그 쿼리문 수행결과를 확정 10 | 11 | 12 | ## Rollback 13 | 14 | * commit 이전에 수행 15 | * 쿼리문 수행결과에 대해 번복을 함. 즉, 쿼리문 수행 이전으로 원상복구 16 | 17 | # 3. Why do we need transactions? 18 | 19 | * A라는 사람이 B에게 100,000원을 송금한다고 생각해보자. 20 | 21 | A 계좌에서는 *100,000원* 이 출금이 될것이고, B 계좌에는 *100,000원* 이 입금이 될것이다. 22 | 23 | 만약, 입금하는 도중에 여러 작업들이 동시에 이루어진다면 어떻게 될까? 24 | ``` 25 | A 계좌에서 출금이 성공 26 | B의 계좌에 입금하는 도중 오류 발생한다면? 철A 계좌에서는 이미 천원이 줄었으나, B 받은 돈이 없는 상황이 발생한다. 27 | ``` 28 | 특히 금융권에서는 더욱더 이러한 일이 절대 발생하면 안된다는 생각을 하게 될것이다. 29 | 30 | 이때, 우리는 트랜잭션의 중요성을 깨닫게된다. 31 | 32 | A 계좌에서 출금, B 계좌에 입금 하는 기능을 하나의 트랜잭션으로 관리해야 한다. 33 | 34 | * 왜 트랜잭션으로 관리해야할까? 35 | 36 | 하나의 트랜잭션으로 관리하면, B 계좌에 입금하는 기능이 실패했을 경우, A 계좌에 돈이 다시 입금이 이루어진다. 37 | 이때, A계좌에 돈이 다시 입금이 이루어지는 과정을 *Rollback* 이라고 한다. 38 | 39 | 40 | 만약, 이러한 오류가 발생하지 않고 정상적으로 A의 계좌에서 출금이 되고 B의 계좌에서 입금이 정상적으로 되었다면 이것의 개념을 *Commit* 이라고 한다. 41 | 42 | 43 | # What if many transactions are competing? 44 | 45 | 여러개의 트랜잭션이 경쟁을 하게 된다면 우리는 여러개의 트랜잭션이 동시에 실행되는 상황을 고려해야한다. 46 | 47 | 특정 트랜잭션이 수정 후 아직 커밋을 하지 않았는데, 다른 트랜잭션이 그 레코드에 접근할 수도 있다. 이러한 경우에 발생 할 수 있는 상황은 3가지이다. 48 | 49 | ### Dirty Read 50 | 51 | ``` 52 | 트랜잭션 A가 어떤 값을 1에서 2로 변경하였고, 아직 커밋하지 않은 상황에서 트랜잭션B가 같은 값을 읽는다면 트랜잭션 B는 2를 읽을 것이다. 이 때 A가 롤백된다면 트랜잭션B는 잘못된 값을 읽은 것이 된다. 53 | ``` 54 | > 아직 수정 중인 데이터에 접근을 허용할 경우 발생하는 데이터 불일치 55 | 56 | 57 | 58 | ### Non-Repeatable Read 59 | 60 | ``` 61 | 트랜잭션 A가 값 1을 읽은 이후 A는 같은 쿼리를 실행할 예정이면, 그 사이에 트랜잭션 B가 값 1을 2로 바꾸고 커밋하게 되면서 A는 같은 쿼리 두번을 날렸으나, 두 쿼리의 결과가 다르게 되는 문제가 발생한다. 62 | ``` 63 | 64 | 65 | > 한 트랜잭션에서 같은 쿼리를 두번 실행했을 때 발생하는 데이터 불일치이다. 앞서 설명한 Dirty Read에 비해서는 발생 확률이 좀 적은데 하나의 트랜잭션에서 두개를 수행해야된다는 전제 조건이 깔리게 된다. 66 | 67 | 68 | 69 | 70 | ### Phantom Read 71 | ``` 72 | 트랜잭션 A가 어떤 조건을 사용하여 특정 범위의 값들 [0,2,4,6,8]을 읽었다. 이후 A는 같은 쿼리를 실행할 예정인데, 그 사이에 트랜잭션 B가 같은 테이블에 값[1,3,5]을 추가하고 커밋을 수행한다면 A는 같은 쿼리를 다시 실행했지만 두번째 결과는 [1,2,3,4,5,6,8]을 얻는다. 73 | ``` 74 | > 한 트랜잭션에서 일정 범위의 레코드를 두번 이상 읽을 때 발생하는 데이터 불일치이다. 앞서 설명한 문제점들 보다 발생 확률이 가장 적다. 75 | 76 | # How to resolve transaction confliction problems? 77 | 78 | ### 트랜잭션 격리수준 79 | 80 | 트랜잭션 격리 수준은 총 4가지이다. 81 | 수준(Level)이 높을수록 성능은 떨어지므로, 높은 격리 수준을 채택하는 것이 항상 좋은 방법은 아니다. 적절한 수준을 채택하는 것이 좋다. 82 | 83 | ### Level0 - Read Uncommited 84 | 85 | 다른 트랜잭션이 커밋하지 않은 레코드에 접근이 가능하다. 가장 낮은 수준의 트랜잭션 격리이다. 그래서 앞서 언급한 3가지 문제가 모두 발생한다. 그러나 *성능은 가장 뛰어나다.* 86 | 87 | ### Level1 - Read Commited 88 | 89 | 항상 커밋된 레코드만 읽는다. 그러므로 아직 커밋되지 않는 레코드를 읽다가 발생하는 Dirty Read는 방지된다. 하지만 나머지 두가지 문제는 예방할 수 없다. *대부분의 DBMS에서 기본적으로 채택하고 있는 방식으로 알려져 있다.* 90 | 91 | ### Level2 - Repeatable Read 92 | 93 | 특정 트랜잭션이 읽은 레코드에 대하여 그 트랜잭션이 끝날 때까지 다른 트랜잭션이 수정/삭제하는 것을 방지한다. 한 트랜잭션에서 같은 쿼리를 두번 실행했을 때 결과가 다른 문제인 Non-Repeatable-Read가 예방된다. *하지만 특정 범위를 지정한 것도 아니고, 레코드 생성을 방지한 것은 아니므로 Phantom Read는 예방할 수 없다.* Oracle에서 종종 사용하는 SELECT ... FOR UPDATE 구문이 이 방식이다. 94 | 95 | ### Level3 - Serializable Read 96 | 97 | 어떤 트랜잭션이 여러개의 레코드를 조회할 때, 그 트랜잭션이 끝날 때까지 조회 범위에 새로운 레코드를 조회/생성/수정/삭제 하는 것을 방지한다. *모든 동시성 관련 문제를 예방할 수 있으나, 성능이 가장 안좋다.* 98 | 99 | ### Reference 100 | 101 | [https://preamtree.tistory.com/154](https://preamtree.tistory.com/154) 102 | 103 | [https://it-sungwoo.tistory.com/57](https://it-sungwoo.tistory.com/57) 104 | 105 | [https://trustall.tistory.com/36](https://trustall.tistory.com/36) 106 | 107 | -------------------------------------------------------------------------------- /SoftwareEngineering/Agile.md: -------------------------------------------------------------------------------- 1 | 2 | # 애자일(Agile)이란? 3 | 4 | 5 | 6 | 폭포수모델과 다르게 단방향적인 개발 모델이 아니라, 짧은 주기를 가지고 눈에 보이는 결과물을 만들어내며 클라이언트와 소통한다. 7 | 8 | 그 다음 주기에서는 수정사항을 반영하여 계획하고, 개발을 수행한다. 이런식으로 주기를 계속반복하여 최종적으로 클라이언트가 원하는 제품에 가장 근접하게 개발할 수 있도록 하는것이 애자일이다. 9 | 10 | 11 | 12 | 13 | 14 | # 애자일 방법론 15 | 16 | 17 | 18 | 종류에는 스크럼, 칸반, XP 등 여러 방식이 존재하며, 각자 다른 목적에 특화되어 있음. 19 | 20 | 21 | 22 | 23 | 24 | # 스크럼 방법론(Scrum) 25 | 26 | 27 | 28 | 유지보수보다는 개발에 초점이 맞추어진 애자일 방법론이다. 29 | 30 | Exmaple) 미식축구 횡대 자세 31 | 32 | 33 | 34 | # 스크럼 프로세스(Scrum Process) 35 | 36 | 37 | 38 | ![scrum](./images/scrum.png) 39 | 40 | 41 | 42 | # 제품 백로그(Product Backlog) 43 | 44 | 사용자를 조사하여 구현해야 할 사항을 정의한 문서 45 | 46 | 다양한 요구명세가 있고, 우선순위로 나누어져 있음. 47 | 48 | 이것의 관리자는 "제품 책임자(Product Owner)"가 수정 삭제 가능 49 | 50 | 제품 책임자는 하나의 스프린트가 끝나면 제품을 백로그 업데이트하여 스프린트 회의때 제시 51 | 52 | 53 | 54 | # 제품 백로그(Product Backlog) 작성법 55 | 56 | - 우선 순위 있는 요구명세(구현에 대한 디테일 한 명세는 필요 없음) 57 | 58 | - 요구 삽입, 수정, 삭제 가능 59 | 60 | - 우선순위 순으로 백로그 작성 61 | 62 | 63 | 64 | # 제품 백로그(Product Backlog) 문서 65 | 66 | ![product_backlog](./images/product_backlog.jpg) 67 | 68 | 69 | 70 | # 스프린트 백로그(Sprint Backlog) 71 | 72 | - 제품 책임자와 스크럼팀이 모여 하는 스프린트 회의시 결정되는 것으로, 요구사항을 테스크로 구체화 한 문서이다. 73 | 74 | - TDD 주도 계획이 포함되어야 한다. 75 | 76 | - 원칙상 수정 불가능 77 | 78 | 79 | 80 | # 스프린트 백로그(Sprint Backlog) 문서 81 | 82 | ![sprint_backlog](./images/sprint_backlog.jpg) 83 | 84 | 85 | 86 | # 스프린트 백로그 번다운 차트(Sprint Backlog Burndown Chart) 87 | 88 | 89 | 90 | ![burndown_chart](./images/burndown_chart.png) 91 | 92 | 93 | 94 | - X축 = 스프린트 구성 일자 95 | 96 | - Y축 = 잔여 작업량 97 | 98 | - 스프린트가 종료에 가까워 질수록 작업량은 감소한다. 99 | 100 | - Task 진행 상태를 추적 할 수 있다. 101 | 102 | # 스크럼 구성원 103 | 104 | 105 | > 제품 책임자 (Product Owner) : 클라이언트와 스크럼 팀 사이에서 의견을 취합하여 제품의 특성과 기능을 정의하여 백로그를 작성하고, 출시 일자와 내용을 결정한다. 수익성에 대한 책임이 있고 시장 가치에 따라 구현할 특성과 기능에 우선순위를 부여한다. 106 | 107 | > 스크럼 마스터 (Scrum Master) : 팀이 완전히 생산적이고 기능적이게 움직일 수 있도록 보장해 준다. 외부에서 간섭하고 방해하는 장애물을 제거하여 팀을 보호하고 스크럼 프로세스가 준수되도록 보장한다. 일일 스크럼, 스프린트 계획 및 리뷰회의에 참석한다. 108 | 109 | > 이해 관계자 : 제품에 관련되어 있으나 생산과 제품 제공에 대한 책임은 없는 사람들을 말한다. 110 | 111 | > 스크럼 팀 (Scrum Team) : 스크럼에서 제품의 생산에 참여하는 인원을 말한다. 개발자, 디자이너 등등이 모여 구성원을 이루고 있다. 112 | 113 | # 스크럼 프로세스 114 | 115 | ![scrum_process](./images/scrum_process.png) 116 | 117 | - 1. 제품 책임자가 이해관계자와 프로젝트 관계자들의 의견을 취합하여 제품 백로그 작성 118 | - 2. 스프린트 계획 미팅 진행 (스프린트 목표 설정, 스프린트 백로그 작성) 119 | - 3. 스프린트 주기동안 제품 제작 (일일 스탠드업 회의 진행하여 팀원간 정보 공유) 120 | - 4. 스프린트 종료 시 모든 이해관계자가 모인 자리에서 회의 진행 121 | - 5. 스프린트 회고 122 | - 6. 다시 1번으로 돌아가서 반복 123 | 124 | # 일일 스크럼 회의 125 | 126 | 15분간 회의하며, 전체팀원이 모여 진척 상황을 공유한다 127 | 128 | # 제품 백로그 추정 단위 129 | 130 | - Idea Time : 간섭 방해 없다고 가정시, 한 사람이 사용가능한 시간의 양 131 | - Calendar Time : 작업 시간을 예상하며 측정하는 기존 방식 132 | 133 | # 스프린트 계획 134 | 135 | 스프린트 계획 회의, 스프린트 리뷰, 스프린트 회고 회의 136 | 137 | 스프린트 계획 회의시 제품 책임자는 최신 버전의 제품 백로그 (지난 스프린트때 만든 결과물을 가지고 이해관계자의 의견을 취합하여 수정사항을 업데이트한 백로그)를 지참하여야 한다. 138 | 139 | 참여자: 스크럼 팀원, 제품 책임자, 스크럼 마스터가 참여 140 | 141 | > 제품 백로그로 부터 항목 선정 및 논의 142 | > 항목을 작업 가능한 태스크로 분할 143 | > 각 태스크에 대한 작업량 추정 144 | > 팀 역량이 남아있는 동안 다음 항목에 대해 반복 145 | > 팀 역량이 모두 할당되면 스프린트 계획 종료 146 | 147 | # Risk Buffer 148 | 149 | 예상치 못한 일의 발생, 팀원의 역량 부족으로 인한 시간 초과 등에 대비해 남겨 두는 예비 150 | 시간 자원 151 | 152 | # 스프린트 원칙 153 | 154 | 1. 스프린트 기간 중에는 비즈니스 우선순위를 바꾸지 않음(요구 사항 변경 허용하지 않음) 155 | 2. 다음 스프린트 시작 전 백로그에 작성하여야 하며, 진행 중인 스프린트에 대한 변경은 이루어 져서는 안된다. 156 | 3. 스프린트가 비정상 종료 될 경우는 변경을 저지할 수 없는 경우 157 | 4. 모든 팀원들이 공유하여야 하고, 제품 책임자가 결정한다. 158 | 5. 모든 스프린트는 같은 길이를 유지하여야 한다. 159 | 6. 반드시 스프린트를 연속적으로 운영하며, 정해진 시간안에 끝내야 한다. 160 | 7. 스프린트는 제 때 홍보하고, 규칙적으로 설정하고 따라야 한다. 161 | 162 | 163 | # 릴리즈 스프린트 164 | 165 | 모든 스프린트는 실행 가능한 제품의 일부 완성을 목표로 한다. 스프린트 완료 후 손질 작업은 릴리즈 스프린트에서 수행하며, 스트레스 테스트, 성능 테스트, 사용성 테스트와 문서 작업을 완료한다. 166 | -------------------------------------------------------------------------------- /Infra/Docker.md: -------------------------------------------------------------------------------- 1 | # Docker 2 | 3 | ## 도커란 무엇인가? 4 | 5 | 2013년 INC에서 출시한 오픈 소스 컨테이너 6 | AWS, Google Clud Platform, MS Azure 클라우드 서비스 공식 지원 7 | 8 | ## 왜 도커를 사용 할까? 9 | 10 | - 복잡한 리눅스 환경에서 컨테이너로 묶어서 실행이 가능하다. 11 | - 개발, 테스트, 서비스 환경을 하나로 통일하여 효율적으로 관리 할 수 있다. 12 | - 컨테이너(이미지)를 전 세계 사람들과 공유가 가능하다. => 리눅스 커널에서 제공하는 컨테이너 기술을 이용 13 | - Docker Hub를 제공한다. 14 | - 컨테이너는 가상화보다 훨씬 가벼운 기술 15 | 16 | ## 가상 머신과 도커 17 | 18 | - 컴퓨터 안에서 컴퓨터를 만들어내기 위한 시도(1960년대에 가상화 개념이 등장) 컴퓨터 성능이 좋아지면서 PC에서도 흔히 사용 19 | - 서버의 성능이 향상됨에 따라 서버가 Task수행을 하지않은 경우가 더 많아지게되었음. 그래서 서버의 Task를 더욱 더 사용 시킬 수 있는 방법을 찾아내다가, 서버에 가상 머신을 여러개 띄워서 일을 더시키기로 하였음. 20 | 21 | - 서버가 많아짐에 따라 서버자체를 가상머신에 집어 넣어서 돌리기로하여 가상 머신에 각종 서버프로그램, DB등을 설치하여 애플리케이션이나 웹사이트를 실행 22 | 23 | - 미리구축한 가상 머신 이미지를 여러 서버에 복사하여 실행하면 이미지 하나로 서버를 계속 만들어 낼 수 있음 => 가상화기술 24 | 25 | - 가상화 기술을 이용하여 서버를 임대해주는 클라우드 서비스 26 | ## 가상머신의 문제점 27 | 28 | OS 컴퓨터 전체를 만들어 버리므로, 각종 성능 손실이 발생 29 | 인텔, AMD는 CPU 안에 가상화 기능을 넣기 시작 30 | 31 | ## 가상머신 문제점 해결 32 | 호스트와 커널을 공유하는 반 가상화 기술이 등장한다. 33 | 34 | ![docker1](images/docker1.png) 35 | 36 | 가상 머신은 완전한 컴퓨터 -> 항상 게스트 OS를 설치해야함 37 | 이미지 안에 OS가 포함 되기 때문에 이미지 용량이 커짐 38 | 네트워크로 가상화 이미지 부담스러움 39 | 오픈소스 가상화 소프트웨어는 OS 가상화에만 주력하므로 => 배포 관리 기능 부족 40 | 41 | ## 리눅스 컨테이너 42 | 43 | 컨테이너 안에 가상공간을 만들지만, 실행 파일을 호스트에서 직접 실행 44 | 리눅스 커널의 cgroups와 namespaces가 제공하는 기술 45 | 가상화가 아닌 격리 46 | ![docker1](images/docker2.png) 47 | 48 | 도커는 리눅스 컨테이너를 사용한다. 49 | - 초기에는 LXC(Linux Container)를 기반으로 구현 50 | - 버전 0.9부터는 LXC를 대신하는 libcontainer를 개발하여 사용 51 | - 실행 옵션으로 선택 가능 52 | 53 | ## 도커의 특징 54 | 도커는 게스트 OS를 설치하지 않음 55 | - 이미지에 서버 운영을 위한 프로그램과 라이브러리만 격리해서 설치 56 | - 이미지 용량이 크게 줄어듦 57 | - 호스트와 OS 자원(시스템 콜)을 공유 58 | 도커는 하드웨어 가상화 계층이 없음 59 | - 메모리 접근, 파일 시스템, 네트워크 전송 속도가 가상 머신해 비해 월등히 빠름 60 | - 호스트와 도커 컨테이너 사이의 성능 차이가 크지 않음(오차 범위 안) 61 | 이미지 버전 관리도 제공하고 중앙 저장소에 이미지를 올리고 받을 수 있음(push / pull) 62 | - Github와 비슷한 형태로 도커이미지를 공유하는 Docker Hub제공(Github 처럼 유료 저장소도 제공) 63 | - 다양한 API 를 제공하여 원하는 만큼 자동화 가능 개발과 서버 운영에 매우 유용 64 | 65 | ## 도커 이미지란? 66 | 이미지는 서비스 운영에 필요한 서버 프로그램, 소스 코드, 컴파일된 실행 파일을 묶은 형태 67 | (저장소에 올리고 받는건 이미지) 68 | 69 | ## 도커 컨테이너란? 70 | 컨테이너는 이미지를 실행한 상태 71 | 이미지로 여러 개의 컨테이너를 만들 수 있음 72 | 73 | - 운영체제로 비유하면 이미지는 실행 파일이고, 컨테이너는 프로세스 74 | 75 | ## 도커는 이미지의 바뀐 부분을 어떻게 관리하지? 76 | 유니온 파일 시스템 형식(aufs, btrfs, devicemapper) 77 | ![docker3](./images/docker3.png) 78 | 79 | 도커는 베이스 이미지에서 바뀐 부분만 이미지로 생성한다. 80 | 컨테이너로 실행할 때는 베이스 이미지와 바뀐 부분을 합쳐서 실행 81 | Docker Hub 및 개인 저장소에서 이미지를 공유 할때 바뀐 부분만 주고 받는다. 82 | 83 | ## 서비스 운영 환경과 도커 84 | 85 | ![docker4](./images/docker4.png) 86 | 87 | 서비스 운영 환경을 이미지로 생성한 뒤 서버에 배포하여 실행 88 | 서비스가 업데이트되면 운영 환경 자체를 변경하지 않고, 이미지를 새로 생성하여 배포 89 | 클라우드 플랫폼에서 서버를 쓰고 버리는 것과 같이 Immutable Infrastructure도 서비스 운영 환경 이미지를 한번 쓰고 버림. 90 | 91 | 92 | 93 | ## Immutable Infrastructure 94 | 95 | 호스트 OS와 서비스 운영 환경(서버 프로그램, 소스 코드, 컴파일 된 바이너리)을 분리 96 | 한 번 설정한 운영 환경은 변경하지 않는다(Immutable) 97 | 98 | ## Immutable Infrastructure 장점 99 | 100 | - 편리한 관리 101 | 102 | 1. 서비스 환경 이미지만 관리하면 된다. 103 | 2. 중앙 관리를 통한 체게적인 배포와 관리 104 | 3. 이미지 생성에 버전 관리 시스템 활용 105 | 106 | - 확장성 107 | 1. 이미지 하나로 서버를 계속 찍어낼 수 있음 108 | 2. 클라우드 플랫폼의 자동확장(Auto Scaling)기능과 연동하여 손쉽게 서비스 확장 109 | 110 | - 테스트 111 | 1. 개발자 PC,테스트 서버에서 이미지를 실행만 하면 서비스 운영 환경과 동일한 환경이 구성된다. 112 | 2. 테스트 간편 113 | 114 | - 가볍다 115 | 1. 운영체제와 서비스 환경을 분리하여 가볍고(Lightweight)어디서든 실행 가능한(Portable)환경 제공 116 | 117 | 118 | ## 도커의 요약 119 | 120 | ![docker5](./images/docker5.png) 121 | 도커의 고래는 컨테이너를 싣고 다니는 고래 122 | 고래는 서버에서 여러 개의 컨테이너(이미지)를 실행하고 이미지 저장과 배포(운반)을 의미한다. 123 | 도커(Docker)는 부두 노동자를 뜻하고 컨테이너를 다루는 도커의 기능과 비슷함 124 | 125 | ![docker6](./images/docker6.png) 126 | 127 | 도커는 서비스 운영 환경을 묶어서 손쉽게 배포하고 실행하는 경량 컨테이너 기술 128 | 129 | ### Reference 130 | 131 | https://www.slideshare.net/pyrasis/docker-fordummies-44424016 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | --------------------------------------------------------------------------------