개발자로 홀로 서기

[네트워크] REST API

Mommoo — Sun, 8 Aug 2021 05:14:48 +0900

안녕하세요.

오늘은 REST API에 대해서 포스팅 합니다.

REST 아키텍쳐를 웹 아키텍쳐중 하나인 HTTP 프로토콜과 동일 선상에서 해석하는 자료가 많았습니다.

재밌는 사실은 REST 창시자인 로이 필딩은 HTTP에 대해 전혀 언급하지 않았으며 순수하게 REST 시스템을 구성하는 방법에 대해서만 소개 하였습니다.

이번 포스팅의 목적은 웹과 무관한 REST 시스템을 본질을 이해하고, HTTP 프로토콜을 이용한여 REST 시스템을 설계하는 방법에 대해 이해하는 것 입니다.

REST

REST는 간단하게 말하자면, 존재하는 자원의 식별하고 제어하는 방법론 입니다.

REST 에서 정의 하는 자원에 대한 정의를 알아보고 자원의 제어와 자원의 표현은 무엇인지 알아봅시다.

자원 (Resource)

자원이란 일이 처리되는 비용을 의미합니다.

REST 는 소프트웨어 아키텍쳐 이므로 컴퓨터의 자원을 의미합니다.

컴퓨터의 자원은 CPU가 수행하는 명령, 하드디스크에 저장되는 파일들, 메모리에 저장되는 데이터들을 의미합니다.

REST는 컴퓨터 자원을 사용하여 처리하는 한 단위의 작업을 식별할 수 있어야 합니다.

REST는 자원을 식별 할 수 있는 식별자가 필요합니다. 예를든다면 TIMESTAMP 나 UUID 같은 중복되지 않는 정보들을 식별자로 사용할 수 있습니다.

자원의 제어 (Resource Methods)

자원의 제어 는 흔히 CRUD 라 부르는 생성, 읽기, 변경, 삭제 행위를 자원에 수행하는것을 의미합니다.

이때 제어 방법은 일관적인 인터페이스로 구성되어야 합니다. 이는 소프트웨어의 API 처리 법칙을 정하면 일관적이게 규칙을 따라야 한다는 것입니다. 예를들어 웹 기반(HTTP)의 시스템에서 자원의 변경을 POST 메소드로 한다면(PUT이 더 어울릴지라도) 자원의 변경은 POST 메소드로 일관적이게 처리해야 한다는 점입니다.

자원의 표현 (Resource Representation)

자원의 표현은 조회한 순간의 자원 상태를 의미합니다. REST 시스템의 자원의 표현은 자기 서술적인(self-descriptive) 메시지와 HATEOAS(hypermedia as the engine of application state)로 구성됩니다. 이는 데이터를 설명하는 메타 데이터, 다음 자원으로의 이동을 안내하는 하이퍼 텍스트 등이 포함 되는 데이터를 의미합니다. REST 시스템은 클라이언트가 자원의 표현만 보더라도 이해되는 것을 목표로 합니다.

웹 기반(HTTP)의 REST

많은 자료들이 설명하고 있는 REST 시스템은 HTTP 기반으로 구성된 REST 시스템 입니다.

HTTP 기술을 통해 REST 시스템을 어떻게 구현하는지 알아봅시다.

자원의 식별

HTTP는 REST 시스템이 요구하는 자원의 식별을 URI의 정의로 처리합니다.

자원은 명사로 커뮤니케이션을 하기 때문에 많은 웹 기반 REST 시스템 선구자들은 URI을 명사구로 표현함으로써 자원을 나타내려고 노력했습니다.

다음과 같은 URI 표기법을 따릅니다.

URI의 세그먼트는 동사가 아닌 명사 사용.
- users/mommoo/name (O)
- users/mommoo/getName (X)

만약 컨트롤 자원이라면 예외적으로 동사구 허용.
- users/mommoo/name/duplicate (중복 이름 검사 API)

자원의 관계가 표시되도록 작성.
- users/mommoo/devices/android-phone
위 예시는 유저 목록중 Mommoo를 의미하고, Mommoo가 가지고 있는 디바이스들을 의미하며, 디바이스들중 안드로이드 폰을 의미합니다.

자원의 제어

HTTP는 자원의 제어를 HTTP Method로 표현합니다. 대표적으로 POST, GET, PUT, DELETE 4개의 Method를 사용 합니다.

자원을 URI로 식별하고 URI에 행위를 붙여줌으로써 자원을 제어합니다.

아래는 자원 제어의 예시입니다.

GET users/mommoo/name (이름을 조회합니다.)

POST users/mommoo/name (이름을 등록합니다.)

PUT users/mommoo/name (이름을 수정합니다.)

DELETE users/mommoo/name (이름을 삭제합니다.)

자원의 표현

HTTP는 자원의 표현을 HTTP 응답 메시지로 구현합니다.

REST 자원의 표현의 특징인 self-descriptive과 HATEOS를 만족하기 위해 ContentType 또는 커스텀 HTTP 헤더에 메타데이터 명시, 데이터에 링크를 포함하는 등의 기법을 사용합니다.

응답 예시는 https://slides.com/eungjun/rest#/79/0/1 참고해주세요.

REST-FUL

REST 시스템의 구성 요소는 다음과 같이 6개로 구성됩니다.

Client-Server

Stateless

Cacheable

Unitform-Interface

Layered-System

Code on demand (optional)

위 6가지 항목을 만족하는 HTTP REST 시스템을 구현한다고 가정할때, Unitform-Interface 항목을 제외한 나머지 항목들은 자연스럽게 구현이 되거나 조금만 신경을 쓴다면 어렵지 않게 구현할 수 있습니다.

왜 Unitform-Interface 항목은 제외가 됬을까요? Unitform-Interface를 제공하기 위해 수행해야할 특징 중 self-descriptive과 HATEOS는 HTTP 시스템에서 자연스럽게 처리 되지 않기 때문입니다.

사실 self-descriptive과 HATEOS 속성은 데이터가 독립적으로 자생하기 위해 필요한 요소들이라 볼 수 있습니다. 그렇다보니 HTTP 서버 스펙을 구현할 때 데이터 독립적인 요소들까지 챙기지 않는 경우도 많습니다. 하지만 REST의 철학을 따르므로 REST 시스템이라 부르고 있습니다.

REST의 구성요소를 완벽하게 지키지 않은 REST 시스템을 구분하기 위해서인지 REST의 구성요소 (특히 Unitform-Interface)를 완벽하게 지킨 REST 시스템을 REST-FUL 시스템이라 부르고 있습니다.

로이 필딩은 REST 시스템의 규칙을 하나라도 제공하지 않는다면 REST 시스템이 아니라고 주장합니다.

정리하자면 REST 시스템으로 소개 되고 있는 시스템은 Unitfor-Interface의 self-descriptive 와 HATEOS가 지켜지지 않는 경우도 많으며, 나머지 항목까지도 완벽히 구현한 시스템을 REST-FUL 하다고 표현 합니다.

REST-API

API는 컴퓨터의 자원 제어 방법의 집합입니다.

그렇다면 REST-API는 REST 시스템의 자원 제어 방법의 집합으로 정의할 수 있습니다.

한단계 더나아가 REST-FUL API는 REST의 구성요소를 완벽히 따른 시스템의 자원 제어 방법의 집합이라 정의 할 수 있겠습니다.

오늘 포스팅은 여기까지 입니다.

읽어주셔서 감사합니다.

참고문헌

https://restfulapi.net/

그런 REST-API로 괜찮은가?

Uploaded by Notion2Tistory v1.1.0

[데이터베이스] 인덱스(INDEX)

Mommoo — Sat, 31 Jul 2021 23:48:06 +0900

안녕하세요.

오늘은 데이터베이스 인덱스 개념에 대해 설명합니다.

인덱스란

인덱스(INDEX)는 DBMS의 검색 속도를 높이기 위한 기술 입니다.

DBMS는 데이터를 순차적으로 쌓으므로, 특정 데이터를 찾기 위해서는 데이터의 FULL-SCAN인 순차 탐색(O(N))이 필요합니다.

DBMS는 특정 데이터를 특별한 자료 구조로 쌓아 탐색 속도를 개선할 수 있는 기능을 제공합니다. 해당 기능을 인덱스라 부르고 쌓은 데이터들을 인덱스 테이블이라 부릅니다.

인덱스는 책의 목차와 비유할 수 있습니다. 우리가 책의 목차를 참고하여 필요한 내용으로 곧 바로 넘어가드시, DBMS도 인덱스 테이블에서 특정 인덱스를 찾아 필요한 행 데이터를 바로 가져옵니다.

인덱스 테이블

인덱스 테이블은 데이터를 조회할 때 사용되는 특정 컬럼의 데이터로 구성됩니다.

인덱스 테이블 에 포함된 데이터를 WHERE 문으로 조회를 하면 인덱스 테이블을 통해 ROW-ID를 빠르게 구한 뒤 단번에 행 데이터를 조회 할 수 있습니다.

인덱스 테이블 탐색

인덱스 테이블의 핵심은 빠른 조회 성능입니다. 이를 위해 인덱스 테이블은 탐색 트리 자료구조 중 하나인 B+트리 자료구조로 데이터를 저장합니다. 탐색 트리는 O( $log_2N$ ) 성능의 빠른 조회를 할 수 있는 특징이 있습니다.

그렇기에, 데이터 FULL-SCAN[O(N)]성능에 비해, 압도적인 빠른 조회를 할 수 있는 장점 이 있습니다.

B+트리 포스팅을 참고해주세요.

인덱스 테이블 생성

TABLE을 생성 할 때, PRIMARY_KEY를 지정한 컬럼은 자동적으로 PRIMARY_KEY를 기준으로 인덱스 테이블이 생성됩니다.

만약 다른 컬럼을 인덱스 테이블을 생성하고 싶다면, 직접 생성해야 합니다.

인덱스 장점

인덱스의 장점은 곧 B+트리 자료구조의 장점과 일맥상통 합니다.

빠른 조회

인덱스 테이블은 메모리에 저장되어 있는 B+트리 자료구조 입니다.

메모리는 한정적인 자원이기 때문에 DBMS는 인덱스로 지정한 컬럼 데이터와 ROW-ID로 구성된 최소한의 노드로 B+트리를 구성합니다.

ROW-ID는 파일에 저장되어 있는 행 데이터를 가져올 수 있는 정보입니다.

여기에서 알 수 있는 재미있는 특징이 하나 있습니다. 데이터 FULL-SCAN이 느린이유는 순차탐색인 이유도 있지만, 빈번한 파일IO도 많은 영향을 미칩니다.

반면에 빠른 메모리 조회로 행 아이디를 찾는 인덱스 방식은 최소한의 파일IO를 사용합니다. 최소한의 파일IO는 더욱 빠른 탐색 속도를 가능하게 합니다.

데이터 정렬

만약 인덱스된 컬럼으로 정렬 명령을 내린다면 정렬 비용을 아낄 수 있습니다.

B+트리 구조상 조회된 데이터를 가져오기만 해도 정렬된 데이터를 획득할 수 있기 때문입니다.

인덱스 단점

지금까지의 설명만 보자면 인덱스 기능은 매우 훌륭한 기능 같습니다만, 그에 못지 않은 단점도 존재합니다. 대표적으로 아래와 같은 단점이 존재합니다.

인덱스 테이블 유지 비용 (B+트리 유지비용)

인덱스 테이블 추가 공간 비용

인덱스 테이블 유지 비용

B+트리의 중요한 특징 중 하나는 균형 이진 트리를 구성한다는 점 입니다. 노드의 삭제, 삽입시 트리 균형을 위해 트리 구조를 재구성 하는 비용이 발생합니다. 더군다나 탐색 이진 트리의 업데이트는 삭제 + 삽입 과정이 발생하므로 2배의 비용이 발생하게 됩니다.

위에서 살펴본 B+트리의 특징이 인덱스 테이블에도 똑같이 적용됩니다.

즉, O( $log_2N$ )으로 빠르게 조회가 가능하지만 삽입, 삭제, 업데이트 작업은 노드의 위치 탐색 비용 + 트리 재구성 비용 이 발생하게 됩니다.

DBMS는 트리 재구성 비용이라도 아끼기 위해 노드 삭제를 진행하지 않습니다. 대신 해당 노드에 사용하지 않는다는 마킹만 진행합니다. 그로인해 DBMS의 삭제, 업데이트 명령은 노드의 위치 탐색 비용만 발생하게 됩니다.

인덱스 테이블 추가 공간 비용

인덱스 테이블의 노드 삭제를 하지 않음으로써, 트리 재구성 비용을 아낀 전략은 유효해 보입니다. 하지만 이 역시도 다른 문제가 존재합니다.

그 문제는 바로, 인덱스 테이블이 거대해짐에 따라, 트리의 높이가 깊어지는 문제 입니다.

이는 테이블의 행 개수 보다 많은 개수의 저장공간을 필요로 합니다.

하지만 더욱 결정적인 문제는 트리 높이에 따른 성능으로 인해 인덱스 테이블 의 깊은 높이는 DBMS 성능을 점진적으로 내린다는 점 입니다.

결론적으로, 미 사용 노드를 트리에서 제거함으로써 높이 최적화가 필요함 을 알 수 있습니다. DBMS는 트리 높이 최적화를 수행하는 명령을 제공합니다. 해당 명령을 주기적으로 수행함으로써 전체적인 DBMS 성능을 높일 수 있습니다.

인덱스 생성 전략

위에서 살펴본 인덱스의 단점을 통해, 다음과 같은 결론을 도출 할 수 있습니다.

조회보다 삽입, 삭제, 업데이트가 더 많이 발생하는 테이블은 인덱스 기능이 오히려 단점이 될 수 있습니다.

또한 인덱스를 설정할 때는 유의할점이 몇개 존재합니다.

Cardinality 체크

인덱스를 구성할 땐, 컬럼의 Cardinality 를 고려하여 생성해야 합니다.

Cardinality 란 값의 분산도를 의미합니다. 다르게 표현하자면 값이 형태가 얼마나 다양하게 나올 수 있느냐의 척도입니다. 만약 (Y, N) 2가지 값으로만 구성된 컬럼을 인덱스로 설정하는 것은, 1700 페이지로 구성된 책에 목차가 2개만 존재하는것과 마찬가지 효과 입니다.

그렇기에 행 데이터가 최대한 많이 분류될 수 있는 컬럼으로 인덱스를 생성해야 효과적입니다.

조회 조건 빈번도 체크

당연한 얘기일 수 있겠지만, 조회 조건으로 자주 사용되는 컬럼일수록 인덱스 조건에 부합합니다.

아래의 항목은 간단한게 체크해볼 수 있는 리스트 입니다.

조건절에 자주 등장하는 컬럼

LIKE 검색보다는 = 으로 검색하는 컬럼

ORDER BY 절에서 자주 사용되는 컬럼

JOIN으로 자주 사용되는 컬럼

지금까지 살펴본 내용을 요약하자면 다음과 같습니다.

인덱스는 B+트리 구조를 통해 조회 성능을 올리는 기능입니다.

데이터 FULL-SCAN은 빈번한 파일IO 작업을 통한 순차탐색으로 매우 느린 반면에 인덱스는 메모리에 저장된 트리 탐색을 통해 파일의 위치를 획득하여 파일IO 작업을 최소화 합니다.

인덱스는 조회 성능을 높이고 삽입, 삭제, 업데이트 성능을 낮추는 트레이드 오프 기능 이므로 조회가 주된 목적인 테이블일 수록 유리합니다.

인덱스는 조회가 주된 목적인 테이블일 수록 유리합니다.

인덱스 테이블의 높이는 점점 깊어지므로, 주기적인 정리가 필요합니다.

인덱스를 생성할 때는 Cardinality와 조회 조건 빈번도 체크가 필요합니다.

오늘 포스팅은 여기까지 입니다.

읽어주셔서 감사합니다.

Uploaded by Notion2Tistory v1.1.0

[자료구조] B 트리

Mommoo — Thu, 29 Jul 2021 02:49:11 +0900

안녕하세요.

오늘은 B 트리 에 대해 포스팅 합니다.

B 트리 는 이진 탐색 트리의 일종으로 탐색 성능을 높이기 위해 균형있게 높이를 유지하는 균형 트리 입니다.

균형 이진 탐색 트리는 대표적으로 RedBlackTree, AVL 트리 같은것이 있습니다. 두 트리가 독특한 규칙으로 높이를 유지 하는것처럼 B 트리도 자신만의 규칙이 존재합니다.

특이한점은, 이진 트리가 아니라는 점 입니다. 규칙에 따라 노드의 자식 노드 개수는 2개 이상이 될 수 도 있습니다.

B 트리 장점

B 트리의 장점은 크게 3가지가 존재합니다.

균형 트리

데이터 로드 효율성

균형 트리의 장점은 이진 탐색 트리 에서도 살펴봤다시피, 노드들이 한쪽으로 치우쳐 연결 리스트의 형태가 되는것을 방지하여 검색 효율을 높일 수 있다는 장점이 있습니다.

데이터 로드 효율성 측면은 대량의 데이터로 트리를 구성할 때, 진가를 발휘합니다.

데이터가 많은경우 메모리에 트리 구조를 유지하기 보다는 외부장치에 데이터를 저장해야 합니다. 각 노드의 값을 파일로 저장한 후, 파일 정보만 저장하고 있다면 메모리에서도 충분히 트리를 유지할 수 있게 됩니다.

외부장치에서 데이터를 읽어올때 데이터가 크던 작던 블럭 크기 만큼 읽어옵니다. 즉 노드의 데이터를 특정 블럭 크기 만큼 지정하여 저장 할 수 있다면 효율적으로 데이터를 읽어올 수 있다는 장점이 생깁니다.

B 트리 구성 방법

B 트리 만의 독특한 구성 규칙이 존재합니다. 이해를 위해서 모든 규칙은 맨 마지막에 정리하고, 중요한 조건순으로 차근차근 알아가봅시다.

N차 B 트리

B 트리를 구성할 때, 가장 중요한 조건은 노드가 최대 몇개의 데이터를 가질 수 있느냐 입니다.

만약 최대 3개의 자료를 가질 수 있다고 정의하면, 노드 자식 개수는 최대 4개를 가질 수 있습니다. 이때 최대 자식 개수를 사용하여 4차 B 트리 라고 표현 합니다.

즉 일반화 해본다면, 하나의 노드가 최대 M개의 자료를 가질 수 있다면 최대 자식 노드 개수는 M+1이 되므로 M+1차 B 트리 입니다.

왜 최대 자식 노드 개수가 M+1 이냐구요? 아래 B 트리 삽입 에서 살펴봅시다!

N차 B 트리는 노드의 최대 자료수는 N-1 이며, 최대 N개의 자식노드를 가질 수 있습니다.

B 트리 탐색

B 트리 탐색은 탐색 노드와 특징을 이용합니다.

특정 노드의 범위 위치를 찾은 후 아래의 자식 노드로 이동합니다.

아래의 과정은 0016 값을 찾는 과정입니다.

루트 노드에서 0016 값의 범위 위치를 찾습니다. (0015 < 0016)

다음 노드에 0016 값이 존재하는지 찾아봅니다. 존재하지 않으므로 0016 값의 범위 위치를 찾습니다. (0016 < 0017)

다음 노드는 리프노드 이므로 해당 노드에 값이 존재하지 않는다면 트리에 값이 존재하지 않음을 알 수 있습니다. 0016 값이 있으므로 탐색을 종료합니다.

B 트리 삽입

B 트리의 차수를 정할 때 홀수냐 짝수냐에 따라 알고리즘이 조금 다릅니다. 홀수가 조금 더 계산하기 편하므로 홀수로 설명하겠습니다.

3차 B 트리 를 예시로 들어봅시다. (노드의 최대 자료 개수는 2개)

삽입의 핵심은 노드 분열 작업 입니다.

아래의 삽입 과정은 최초 노드 분열이 발생하는 과정입니다.

01~02 번 삽입 과정은 루트 노드에 빈자리가 존재하여 자리를 찾아 삽입 합니다.
- 데이터 저장 순서는 오름 차순으로 저장합니다.

03번은 0011 을 루트 노드에 넣을 자리가 없는 경우 입니다.
- 이때 B 트리 핵심 과정 중 하나인 노드 분열이 발생합니다.
- 03-2. 루트 노드의 값들과 넣을 값을 포함하여 중간 값을 찾습니다. (홀수 차수를 고른것이 이때 편합니다.)
- 03-3. 중간 값 0005 값을 부모 노드로 올리고, 왼쪽 값들과 오른쪽 값들을 자식 노드로 각각 구성하여 연결합니다.

아래의 과정에서 발생하는 노드 분열도 한번 살펴보시죠.

04번 삽입은 탐색 노드 특징을 이용하여 리프노드 까지 도달합니다.
- 리프노드에 자리가 비었으므로, 0017값이 그대로 저장됩니다.

05-01. 0022 값의 자리를 탐색하여 리프 노드 까지 도달했습니다.
- 05-01. 하지만, 리프 노드엔 자리가 없습니다. 노드 분열과 마찬 가지로 중간 값을 찾습니다.
- 05-02. 중간 값을 부모 노드로 이동시킵니다. (노드 분열이 발생합니다.)
- 05-02. 남은 값들은 각각 노드로 구성하여 중간 값 왼쪽, 오른쪽 자식노드로 연결합니다.

위 예시와 같이 리프노드에 공간이 부족할 때, 부모 노드로 중간 값을 옮기는 노드 분열를 수행하면 재밌는 특징이 생깁니다.

규칙1. 노드의 자료가 최대 N개 라면, 해당 노드의 자식 노드 개수는 항상 N+1 입니다.

규칙2. 모든 리프 노드들은 항상 같은 레벨에 위치하게 됩니다.

규칙3. 노드의 자료가 최대 N개 라면, 리프 노드가 분열 할때 항상 중간 값으로 분열 하므로 노드의 자료 개수는 [N/2]~N개가 보장 됩니다.
[3/2] ⇒ 2 (올림연산 입니다.)

마지막으로 아래의 노드 분열을 이해 하실 수 있다면, 트리 삽입 과정을 이해 하실 수 있습니다.

B 트리 삭제

B 트리의 삭제는 크게 두가지 케이스로 나누어 생각 해볼 수 있습니다.

리프 노드에서 값 삭제.

리프 노드가 아닌 중간 노드에서 값 삭제.

리프 노드에서 삭제

이 경우에도 크게 3가지 경우로 나뉩니다.

리프 노드에서 값을 삭제 하더라도 최소 유지 개수 ([N/2]) 조건에 만족하는 경우.

리프 노드에서 값을 삭제 할 때, 최소 유지 개수를 만족하지 못하지만 바로 옆 형제 노드들 중 최소 유지 개수 보다 많아 값을 빌려올 수 있는 경우.

리프 노드에서 값을 삭제 할 때, 최소 유지 개수를 만족하지 못하고 옆 형제 노드들도 최소 유지 개수만 가지고 있어 값을 빌려올 수 없는 경우.

리프 노드에서 바로 삭제.

리프 노드가 최소 유지 개수를 만족하는 경우 바로 삭제가 가능합니다.

형제 노드에서 값을 빌려 오는 경우.

리프 노드의 형제 노드에서 빌려야 할 값을 찾습니다.
- 오른쪽 형제 노드라면 형제 노드중 최대값.
- 왼쪽 형제 노드라면 형제 노드중 최소 값.

리프 노드의 부모 노드에서 리프 노드와 형제 노드를 동시에 가리키고 있는 값을 찾습니다.

리프 노드에서 값을 삭제 후, 부모 노드에서 찾은 값을 리프노드로 내려주고 빌린 형제 노드 값을 부모 노드 찾은 값 자리에 넣습니다.

형제 노드에서도 값을 빌릴 수 없는 경우.

삭제할 리프 노드와 형제 노드를 병합 합니다. 병합 노드도 최소 개수 조건을 만족 시키기 위해 부모 노드에서 값 하나를 내려줍니다.

부모 노드도 최소 개수 조건을 만족하지 않는다면, 1번 과정을 리프 노드 대신 부모 노드로 치환하여 수행합니다.

만약 병합된 노드가 최대 개수를 넘는다면, 중간 값을 찾아 병합 노드의 부모 노드로 값을 넘겨줍니다.

중간 노드에서 삭제

해당 경우도 3가지로 나눌 수 있습니다.

최소 개수 보다 많아 값을 빌려올 수 있는 자식 노드가 존재하는 경우.

여유있는 자식 노드가 없지만, 부모 노드가 최소 개수보다 많은 경우.

자식 노드도, 부모 노드도 여유가 없는 경우.

자식 노드에게 값을 빌려오는 경우.

값을 빌려올 자식 노드의 값을 찾습니다.
- 왼쪽 자식 노드라면 최소 값을 찾습니다.
- 오른쪽 자식 노드라면 최대 값을 찾습니다.

타겟 노드의 값을 지우고, 해당 자리를 찾은 자식 노드의 값으로 대체 합니다.

여유있는 자식 노드는 없지만, 부모 노드가 여유가 있는 경우.

노드의 삭제 값의 자식 노드들을 합병합니다.

자식노드, 부모노드 둘다 여유가 없는 경우.

노드의 삭제 값의 자식 노드들을 병합합니다.

노드의 형제 노드와 부모노드를 대상으로 병합을 진행합니다.

만약 병합 노드가 최대 개수를 초과 한다면 중간 값을 추출해 병합 노드의 부모노드로 이동시킵니다.

B+트리

B 트리의 단점은 순회?

Warning!! 주관적인 생각이 섞여 있습니다.

B 트리 는 자료 순회가 단점이라는 글이 많습니다. B 트리도 트리 구조이기 때문에 트리 순회와 똑같은 시간복잡도가 걸립니다. 그렇기에 단점이라 할 수는 없습니다.

많은 자료들이 단점이라 오해(?)하는 이유는 트리 순회를 개선한 B+트리의 존재 유무 때문이 아닐까 생각이 듭니다.

리프 노드들을 모든 노드의 값이 포함되도록 처리

B+ 트리의 순회 연산의 개선 포인트는 리프 노드들의 구조에 있습니다.

다음의 예시를 보면, 리프 노드들은 모든 값들을 포함하고 있고 연결리스트 형태를 구성하고 있습니다.

리프 노드의 위 노드들은 검색을 위해 유지하고 있는 모습입니다.

특정 범위를 순회하고 싶다면, 손쉽게 특정 리프 노드에서 차례대로 순회 할 수 있습니다.

빠른 검색-삽입-삭제 + 범위 검색 이 필요한 관계형 데이터베이스가 해당 자료구조를 사용하고 있습니다.

B 트리의 삽입, 삭제 과정을 단번에 이해하긴 어려운거 같습니다.

더군다나 트리의 특정 스냅샷 기준으로 설명했기 때문에 높이가 큰 트리인 경우에는 설명한 개념에 더해 재귀 개념 까지 합산하여 이해를 해야 하기 때문에 더 어려운거 같습니다.

B 트리 특징들을 살펴보면서 항상 만족했던 조건들을 다시 정리해보면 아래와 같습니다.

N차 B 트리는 노드의 최대 자료수는 N-1 이며, 자식노드는 최대 N개.

노드의 자료가 최대 N개 라면, 해당 노드의 자식 노드 개수는 항상 N+1.

노드의 자료가 최대 N개 라면, 노드의 자료 개수는 [N/2] ~ N개. (루트 노드 제외)

모든 리프 노드들은 항상 같은 레벨에 위치한다.

오늘 준비한 포스팅은 여기까지 입니다.

읽어주셔서 감사합니다.

[네트워크] OSI 7계층

Mommoo — Mon, 26 Jul 2021 02:27:10 +0900

안녕하세요.

오늘은 OSI 7계층에 대해 간략하게 소개합니다.

OSI 7 Layer

OSI 7계층 이란 네트워크 통신을 수행할 때, 처리되어야 할 작업을 순차적으로 7단계로 처리 하는 과정을 의미합니다.

계층을 나누어 처리함으로써, 필요한 작업들은 독립적인 모듈로 처리 됩니다. 이는 디버깅이 용이하고 모듈간 교체 및 확장등이 자유롭다는 장점이 존재합니다.

OSI 1~3 계층은 하드웨어 영역으로써, 각 층마다 매칭되는 하드웨어 장치가 존재합니다. 따라서, 해당 계층의 역할들은 하드웨어가 실질적으로 수행하는 역할 입니다.

OSI 4~7 계층은 소프트웨어 영역이며, 4~6 계층은 OS가 7계층은 우리가 사용하는 프로그램이 해당 계층의 역할을 수행합니다.

다음 이미지는 OSI 7계층 구성도 입니다.

Physical Layer

네트워크 통신은 서로 멀리 떨어져 있는 지점끼리 데이터를 주고 받을 수 있습니다. 데이터 통신은 아날로그 신호(주파수)로 최초 전달 되고 디지털 데이터로 변환되어 해석하는것을 의미합니다.

물리 계층(Physical Layer)은 이러한 아날로그 신호(주파수)를 디지털 신호로 변경해주는 역할을 수행합니다.

물리 계층의 역할은 여러 하드웨어의 조합으로 수행됩니다. 아날로그 신호를 디지털 테이터로 변환하는 주된 역할은 NIC(Network Interface Controller)란 하드웨어가 수행합니다. 흔히 네트워크 카드, 랜 카드로 불립니다.

Data-Link Layer

네트워크 통신은 여러 프로그램이 동시적, 지속적으로 수행 할 수 있습니다. 이때, 컴퓨터는 들어온 데이터를 식별하기 위한 라벨링 작업이 필요합니다. 이러한 행위를 프레임화 라고 부릅니다.

데이터 링크 계층(Data-Link Layer)은 프레임화를 진행하고, 만들어진 프레임을 상위 계층 또는 하위 계층에 전달 합니다.

결론적으로, 해당 계층은 두가지 역할로 정리할 수 있습니다.

프레임화 (데이터 라벨링)

흐름제어 (상위 계층 또는 하위 계층으로 프레임 전달)
3계층, 1계층도 하드웨어 영역이므로 인접한 네트워크 장비에 데이터를 전송하는것을 의미합니다.

해당 계층의 역할을 수행하는 대표적인 하드웨어는 위에서 언급한 NIC 입니다. 해당 계층의 역할을 전문적으로 수행하는 브릿지, 스위치 같은 장비들도 존재합니다.

Network Layer

물리 계층의 아날로그 신호는 거리가 먼 지점까지 전달되지 않습니다.

신호를 세게 하는 리피터라는 장비를 사용 할 수 있지만, 이는 특정 지점에 전달 하기 보다 무분별하게 전파하기 때문에 효율이 떨어 집니다.

이를 해결하기 위해 사용되는 장비는 바로 라우터 입니다. 무분별하게 전파하는 리피터와는 다르게 라우터는 내장된 라우팅 알고리즘을 통해 전달 할 수 있는 가장 가까운 라우터 까지의 경로를 결정하고 이를 테이블로 저장합니다. 해당 행위를 라우팅 이라 표현 합니다.

경로가 결정되면 전달해야할 데이터를 다음 라우터에게 맡깁니다. N개의 라우터가 지속적으로 정보를 전달을 하면서 최종 목적지 까지 전달하는 방법을 포워딩 이라 표현 합니다.

이때, 정보를 전달 받은 라우터는 본인이 최종 목적지 인지 여부와 응답 데이터를 다시 출발지 라우터로 보내기 위한 데이터가 필요합니다. 즉 전달해야 하는 데이터는 출발지 정보, 목적지 정보가 부가적으로 필요 하며 해당 정보는 IP 라는 정보로 처리합니다. 전달 데이터에 IP 정보를 붙인 데이터를 패킷 이라 부릅니다.

정리하자면 해당 계층은 3가지 역할을 수행합니다.

2계층에서 넘어온 데이터를 패킷으로 만들거나, 수신된 패킷 데이터를 해석합니다.

다음 라우터의 경로를 찾기 위한 라우팅을 진행합니다.

패킷 전달의 역할을 다음 라우터에게 위임하는 포워딩을 진행합니다.

해당 계층에 대표적인 하드웨어는 위에서 언급했던 라우터 이며 우리가 집에서 흔히 사용하는 공유기도 라우터의 역할을 어느정도 수행 합니다.

Transport Layer

데이터 통신은 여러 프로그램이 동시에 지속적으로 수행되고 있습니다.

그렇기에 특정 데이터가 어떤 프로그램과 관련이 있는지 식별할 수 있어야 합니다.

식별하기 위해 포트번호 라는 데이터가 사용됩니다.

전송 계층(Transport Layer)은 하위 계층에 데이터를 전달 할때 데이터에 포트번호를 붙이며, 하위 계층으로 부터 데이터를 전달 받을 때도 포트번호 를 통해 데이터를 식별합니다.

또한 데이터 통신 프로토콜에 따른 알고리즘이 수행됩니다. 대표적인 예로 TCP, UDP 프로토콜이 존재합니다.

TCP 통신이 제공하는 연결지향, 흐름제어, 오류검출 및 회복 등이 해당 계층에서 수행됩니다.

해당 계층의 역할은 운영체제 커널에 소프트웨어적으로 구현되어 있습니다.

정리하자면 해당 계층은 크게 2가지 역할을 수행합니다.

포트번호를 통한 데이터 식별 작업.

데이터 통신 프로토콜에 따른 알고리즘 수행.

Session Layer

Warning! 해당 계층은 작성자가 정확히 이해하지 못했습니다.

세션 계층(Session Layer)의 주된 목표는 각 프로그램의 네트워크 통신 상태 관리와 동기화 입니다.

상태 관리는 데이터 통신 프로토콜 알고리즘이 가지는 특성들을 수행하기 위해 필요한 처리를 의미합니다. 예를들어 TCP 프로토콜은 연결 수립, 종료와 같은 상태 등을 처리합니다.

동기화란 전송 계층에서 올라온 또는 응용 계층 에서 내려온 데이터를 안정적으로 상위 또는 하위 계층으로 전달하는 역할을 수행합니다. 데이터가 성공적으로 전달된 지점까지 내부적으로 마킹해두며, 데이터 전달에 문제가 발생하면 마킹한 지점부터 오류지점까지 데이터 복구 절차가 수행됩니다.

해당 계층 역할도 운영체제가 수행합니다.

Presentation Layer

표현 계층(Presentation Layer)은 하위 계층이 전달한 데이터를 어플리케이션이 해석 할 수 있도록 데이터를 디코딩 하거나, 데이터 전달을 효율적으로 수행하기 위해 데이터를 인코딩 한 뒤 하위 계층으로 전달합니다.

다음은 표현 계층이 수행하는 대표적인 예시 입니다.

SSL 프로토콜에서 처리되는 암, 복호화 처리

데이터 압축및 해제 처리

데이터 포맷(UTF-8 과 같은)에 따른 인코딩, 디코딩 처리

해당 계층 역할 역시 운영체제가 수행합니다.

Application Layer

응용 계층(Application Layer)은 요구사항을 처리하기 위해 네트워크 통신을 이용한 데이터의 송-수신이 발생하는 가장 마지막 영역 입니다.

운영체제는 전송 계층에서 제공하는 API를 활용하여 네트워크 통신을 가능토록 API를 제공하는데, 이를 소켓 API라 부릅니다.

해당 계층은 소켓 프로그래밍을 통해 데이터를 송신 및 수신을 수행합니다.

재밌는 특징은 각 프로그램이 개별적으로 데이터 규격을 만들어 통신 할 수 있습니다. 데이터의 인코딩 및 디코딩을 각 프로그램이 자체적으로 수행할 수 있기 때문입니다.

프로그램이 대표적으로 사용하는 데이터 규격은 HTTP 프로토콜 방식이 있으며 작은 단위로는 JSON, XML과 같은 데이터 규격도 존재합니다.

해당 계층의 역할은 개발된 프로그램이 수행합니다.

TCP/IP 모델의 등장

독립적인 모듈을 구성하는것은 정답이 존재하지 않습니다. 나뉘어진 모듈이 서로 심하게 의존하는 경우 모듈의 결합도가 높다고 하며, 모듈이 너무 작은 단위로 구성 된 경우 응집도가 떨어진다고 합니다. 이러한 특징들은 소프트웨어적 가치를 하락시키는 요인입니다.

OSI 7계층은 대표적인 네트워크 통신 규격으로 사용 되고 있지만, OSI 7계층역시 결합도가 높고, 응집도가 낮은 모듈들이 존재합니다.

그 대상 계층들은 응용 계층, 표현 계층, 세션 계층 입니다. 따라서 현대적인 네트워크 통신 규격인 TCP/IP 모델 은 다음과 같이 정의 되었습니다.

TCP/IP 모델의 네트워크 엑세스 계층은 데이터 링크 계층 + 물리 계층 으로 나누어서 표현하기도 합니다.

반면에 응용 계층, 표현 계층, 세션 계층 들은 응용 계층 하나로 통합 되었습니다.

TCP/IP 모델의 각 계층 역할도 OSI 7계층의 역할과 동일합니다.

몇몇 모듈이 독립적으로 수행되던 역할이 하나의 모듈이 통합 수행 한다고 이해하면 될거 같습니다.

오늘 포스팅은 여기까지 입니다.

읽어주셔서 감사합니다.

Uploaded by Notion2Tistory v1.1.0

[운영체제] 뮤텍스와 세마포어

Mommoo — Sun, 25 Jul 2021 05:39:00 +0900

소프트웨어를 개발하다 보면, 공유되어야 할 자원이 존재할 수 있습니다.

공유자원은 서로 다른 두 태스크가 각자 처리를 마친 후, 결과가 하나로 취합되어야 하는 경우에 필요합니다.

하나로 취합하는 경우, 상호 배제 개념이 중요합니다.

싱글 테스크 와 멀티 테스크

싱글 태스크(싱글 프로세스 + 싱글 스레드) 프로그램이면 문제가 되질 않습니다. 두 태스크는 순차적으로 처리되므로, 공유자원의 동시성 문제가 존재하지 않기 때문입니다.

반면에 멀티 태스크(멀티 프로세스 또는 멀티 스레드) 프로그램이면 문제가 발생할 수 있습니다. 두 태스크가 동시적으로 처리되면서 공유자원이 예기치 못한 결과로 취합될 수 있기 때문입니다.

다음은 은행 입-출금 기능이 싱글 태스크, 멀티 태스크로 구현된 예시입니다.

싱글 테스크

보유 금액: 50,000 (공유 자원)

입금 태스크

현재 보유된 금액을 조회. (50,000)

입금할 금액을 확인 (10,000)

입금 처리. (50,000 + 10,000)

출금 태스크

현재 보유된 금액을 조회. (60,000)

출금할 금액을 확인 (20,000)

출금 처리. (60,000 - 20,000)

최종 보유금액은 40,000(40,000) 이 됩니다.

멀티 테스크

보유 금액: 50,000 (공유 자원)

입금 테스크

현재 보유된 금액을 조회 (50,000)

입금할 금액을 확인 (10,000)

입금 처리. (50,000 + 10,000)

최종 보유금액은 60,000(40,000) 이 됩니다.

출금 테스크

현재 보유된 금액을 조회 (50,000)

출금할 금액을 확인 (20,000)

출금 처리. (50,000 - 20,000)

임계영역

위 예시에서 살펴봤다시피,

멀티 태스크 프로그램을 개발하면, 공유자원을 사용하는 부분을 순차적으로 처리하도록 보장해야 합니다. 이때, 순차적으로 처리해야 하는 부분을 임계영역 이라 일컫습니다.

임계영역 이 순차적으로 처리될 수 있게 하는 방법은 크게 2가지가 있습니다.

뮤텍스(Mutex)

세마포어(Semaphore)

뮤텍스

자원의 선점을 통해, 순차 처리를 수행하는 방법입니다.

이때, 선점될 자원은 하나의 객체로 처리 되며 이를 Lock 또는 Key 라고 부릅니다.

하나의 태스크가 임계 영역을 진입할 때, Lock을 획득하고 진입 하는 방식입니다. 이렇게 되면 다른 태스크들은 Lock을 획득 할 수 있을때 까지 줄지어서 기다리게 됩니다.

Lock을 획득한 태스크가 임계 영역을 처리하고 나면 Lock을 반납하게 됩니다. 그 후, 대기하던 태스크들 중 하나가 Lock을 획득하여 임계 영역을 수행하게 됩니다.

뮤텍스는 단일 공유 자원 처리에 적합

만약 각 태스크가 공유 자원이 2개 이상 필요한 경우는 어떨까요?

각 자원에 대한 Lock 을 생성하고 태스크에 두개의 Lock 에 대한 처리가 필요하게 됩니다.

이는 공유 자원 추가로 인해 변경 사항이 모든 테스크에 반영되어야 하므로, 유지보수를 어렵게 만드는 요인이 됩니다.

또한 공유 자원 개수가 많아 지면 분기 처리도 복잡하고 어려워 지는 문제도 발생합니다.

세마포어

뮤텍스의 다중 공유 자원 처리에 대한 단점을 보완한 방법입니다.

세마포어는 하나의 자원에 대한 락킹 개념보다 조금더 나아가, 자원 사용 카운팅 기법으로 순차 처리를 보장하는 방법입니다.

테스크가 임계 영역을 진입할 때, 진입 가능한 숫자를 참고합니다.

자원 사용 카운팅이 0보다 크다면, 테스크가 임계 영역을 집입하고 자원 사용 카운팅을 하나 감소시킵니다.

만약, 자원 사용 카운팅이 0이라면 테스크는 추가 카운팅이 생길 때 까지 대기하게 됩니다.

데드락

앞서 살펴본 2가지 방법은 널리 사용되고 있는 기본적인 개념입니다.

하지만, 공유 자원을 2개 이상 사용하는 임계 영역을 처리하는 경우 교착 상태가 발생할 수 있습니다.

공유 자원 A, B 가 있다고 가정할 때, 다음의 뮤텍스 방법은 교착 상태 즉, 데드락이 발생할 수 있습니다.

TASK-1

Locking(A)

Locking(B)

TASK-2

Locking(B)

Locking(A)

위 예시는 TASK-1은 공유 자원 B의 락이 해제 되길 기다리고 있으며, 반대로 TASK-2는 공유 자원A가 해제 되길 기다리고 있습니다. 이는 결국 무한정 대기하게 되는 데드락이 발생하게 됩니다.

세마포어 기법도 마찬가지로 적용됩니다.

데드락 해결 방법

해결 방법은 여러 가지가 존재하며, 상황에 맞게 처리하는것이 중요합니다.

타임아웃 설정
자원의 대기 타임아웃을 설정하여 교착 상태에 빠진 테스크중 하나를 타임아웃으로 포기하게 하는 방법 입니다.

진입 순서 일치
공유자원의 임계영역 진입 처리 순서를 동일하게 하여 자원 요청 방향이 원형을 이루지 않도록 처리하는 방법입니다.

정리

뮤텍스는 하나의 락 객체를 통해 임계 영역이 하나의 태스크만 처리할 수 있도록 고안된 방법입니다.

세마포어는 공유자원 접근 가능 카운트를 정의해, 정의한 수 만큼 태스크가 처리할 수 있도록 고안된 방법입니다.

공유 자원을 2개 이상 사용하는 임계영역은 데드락이 발생 할 수 있으므로, 유념해야 합니다.

세마포어의 카운팅을 1로 하면 뮤텍스와 같은 효과를 누릴 수 있습니다.

Uploaded by Notion2Tistory v1.1.0

[운영체제] 스레드

Mommoo — Thu, 22 Jul 2021 00:16:08 +0900

안녕하세요.

오늘은 스레드에 대해 포스팅 합니다.

프로세스 포스팅을 읽고 오시면 좀 더 쉽게 읽으실 수 있습니다.

CPU 스레드

CPU 하드웨어를 평가할 때 참고하는 많은 정보들이 있습니다.

대표적으로는 아래의 두정보가 있습니다.

코어 수

스레드 수

코어 수는 컴퓨터 데이터인 이진수를 계산 할 수 있는 계산기의 갯수 입니다. 이는 하드웨어적인 개념 입니다.

스레드 수는 이진수를 계산 할 수 있는 능력입니다. 이는 소프트웨어적인 개념 입니다.

보통은 코어 수가 곧 스레드 수 입니다. 하지만 인텔이 개발한 하이퍼스레딩 같은 기술을 접목하면 각 코어당 2개의 스레드를 사용 할 수 있습니다.

정리하자면 코어 수의 두배인 스레드 를 사용할 수 가 있습니다.

하지만 이해가 잘 안갑니다. 계산기는 하나 인데 어떻게 2배의 처리 능력을 가질 수 있는것일까요?

아래의 프로세스 2개가 존재한다고 가정해봅시다.

프로세스

이름	걸리는 시간	데이터
A	10초	1111111111
B	4초	0000

1코어 1스레드는 두 프로세스를 마치는 시간은 14초 입니다.

A 프로세스가 선 처리되던 (11111111110000)

B 프로세스가 선 처리되던 (00001111111111) 간에 총 처리 시간은 같습니다.

하지만 B 프로세스의 처리 결과를 기다리는 사용자가 느끼는 경험은 많이 다릅니다.

첫번째 경우는 B 프로세스가 처리 될 때까지 걸린시간은 14초 입니다.

반면에 두번째 경우는 4초가 걸렸습니다.

이렇게, 처리시간이 긴 프로세스가 존재하면 상대적으로 다른 프로세스들이 늦게 끝나게 되는 경우가 발생하게 되고 이는 사용자가 여러가지 프로그램을 동시적으로 처리하는데 어려움을 느낄 수 있다는 것입니다.

반면에 1코어 2스레드는 어떻게 처리할까요? 아래와 같이 처리합니다.

10101010111111

CPU 입장에서 총 처리시간은 1스레드와 같은 14초입니다.

하지만 B프로세스는 8초가 걸리게 됩니다. 최악의 경우인 14초 보다 거의 2배 가량 감소하게 되었습니다.

더군다나 이렇게 나누어 처리하게 된다면 여러가지 프로그램이 동시적으로 조금씩 처리되고 사용자 입장에서는 여러 프로그램이 버벅임 없이 처리되는것을 경험하게 됩니다.

정리하자면, 스레드는 데이터를 병렬로 처리하는 능력을 의미합니다.

이 때, 착각하면 안되는 것은 CPU 입장에서는 총 처리 시간은 변함없다는 점 입니다.

CPU 하드웨어 입장에서 총 처리 시간을 줄이는 방법은 코어 갯수를 늘리는 방법 뿐입니다.

프로세스 스레드

CPU 스레드는 일을 처리할 수 있는 능력이라 소개했습니다. 운영체제는 프로세스를 CPU 스레드에게 할당하는 작업을 합니다.

CPU가 2개의 스레드를 제공한다고 가정 할 때, 프로세스를 2개만 처리하는 것으로 착각 할 수 있습니다. 이는 잘못된 개념이며 쉽게 설명하자면, 2개의 계산기가 있고 여러 사람(=프로세스)이 돌려 사용하는것을 의미합니다.

위에서 소개한 예시처럼 컴퓨터는CPU 스케줄링 을 통해 여러 프로세스들을 N개의 CPU 스레드 에 일을 돌아가면서 할당 합니다.

이때, 운영체제가 정의하는 스레드 의 개념은 프로세스 내부의 작업 단위로 사용됩니다.

특정 프로세스가 CPU에게 선택받는다고 해서, CPU는 무조건적으로 일을 진행하지 않습니다. 예를 들어, 해당 프로세스가 IO 인터럽트가 걸려있으면 CPU는 해당 프로세스 를 처리하지 않고 대기 큐에 보내 버리지요.

프로세스 입장에서는 억울 할 수 있습니다. IO 인터럽트 처리 다음에도 해야할 일이 많을 수도 있을테니깐요. 이 때, 다중 스레드를 이용하면 해당 이슈를 개선할 수 있습니다.

A 스레드는 IO 인터럽트를 처리하게 하고, B 스레드는 CPU가 진행 할 수 있는 일을 처리하게 했다고 가정해봅시다.

CPU는 해당 프로세스를 선택했을 때, 스레드 단위로 살펴보게 되고 처리할 수 있는 스레드가 있다면 해당 작업을 진행하게 됩니다.

정리하자면, 다중 스레드로 프로그래밍을 진행하게 된다면 CPU에게 일을 처리 받을 확률이 높아짐을 의미합니다.

프로세스 스레드 특징

프로세스 는 CODE, DATA, STACK, HEAP 영역을 가지게 됩니다.

STACK은 명령어가 수행되기 위한 작업 공간입니다.

스레드의 개별 STACK

프로세스 내부에 스레드를 만들게 되면 각 스레드는 개별 STACK 영역을 가지게 됩니다.

즉, 스레드가 3개인 프로세스는 3개의 STACK 공간을 가지게 되는것이지요.

이러한 개별 스택 공간을 통해 CPU는 독립적인 단위로 처리하는것이 가능해집니다.

스레드간 통신

프로세스의 CODE, DATA, HEAP 영역은 스레드 끼리 공유하게 됩니다.

그로인해, 스레드간 데이터 통신은 프로세스간 데이터 통신보다 쉽게 처리할 수 있는 특징이 있습니다.

자바와 같은 프로그래밍 언어를 이용해 코딩해보면 서로 다른 스레드를 처리 할 때, 특정 변수등을 같이 사용할 수 있습니다.

프로세스간 데이터 통신은 파일 통신(소켓 통신)이 베이스가 되어야 합니다.

하지만, 데이터를 공유한다는 것은 그만큼 동기화 문제가 발생할 확률로 높습니다.

멀티 프로세스 방식과 멀티 스레드 방식

프로그램을 만들 때, CPU에게 최대한 많은 일 처리를 받기 위해 사용하는 방식은 크게 두가지 입니다.

멀티 프로세스 프로그래밍

멀티 스레드 프로그래밍

멀티 프로세스 방식은 루트 프로세스가 존재하고, 일처리를 다수의 자식 프로세스에게 나누어 처리하여 취합하는 방식입니다.

장점은 독립성을 보장받을 수 있다는 점 입니다.

하나의 프로세스가 문제가 생기더라도 다른 프로세스에게 영향을 주지 않습니다.

단점은 데이터 통신에 많은 자원을 소비한다는 점입니다. 컨텍스트 스위칭에 따른 성능 저하가 대표적입니다.

멀티 스레드 방식은 하나의 프로세스 에 다수의 스레드(스택)에게 나누어 처리한 후 취합하는 방식입니다.

장점은 데이터 통신이 상대적으로 쉽고, 빠르고, 비용이 적습니다.

단점은 데이터를 공유하기 쉬우므로, 동기화 문제가 빈번하게 발생 할 수 있고 특정 스레드가 문제가 생기면 전체 프로세스에 영향을 줄 수 있습니다.

오늘 포스팅은 여기까지 입니다.

읽어주셔서 감사합니다.

[운영체제] 프로세스

Mommoo — Wed, 21 Jul 2021 03:36:07 +0900

안녕하세요.

오늘은 프로세스에 대해 포스팅합니다.

프로그램과 프로세스

컴퓨터에서 프로그램 이란 단어는 매우 많이 사용되고 있습니다.

반면에 프로세스 라는 용어는 생각보다 생소합니다. 운영체제에서는 두가지 단어의 개념을 구분해서 사용할 줄 알아야 합니다.

프로그램

하드디스크에 저장되어 있는 일련의 데이터 덩어리를 파일 이라고 일컫습니다. CPU가 해석하고 수행할 수 있는 명령어 데이터로 구성된 파일을 프로그램 이라고 합니다. 이미지 파일과 같은 순수 데이터는 프로그램이라 할 수 없습니다.

프로세스

하드디스크에 저장되어 있는 프로그램 을 CPU가 수행하기 위해서는 하드디스크에 위치한 데이터를 메모리로 옮기는 작업이 필요합니다. 메모리에 옮겨진 일련의 데이터 덩어리를 프로세스 라고 일컫습니다.

정리하자면 프로세스 는 프로그램 이 메모리에 옮겨진 데이터 덩어리를 의미합니다.

그러므로 프로세스 는 실행 중인 프로그램 이라고도 불립니다.

프로세스 구조

사실 프로세스가 프로그램 데이터 그대로 메모리에 복사되는건 아닙니다.

OS가 프로그램 을 분석하여, 아래와 같은 프로세스 구조를 만듭니다.

CODE

하드디스크에서 읽어온 프로그램 데이터가 저장되는 영역입니다.

CPU가 명령어를 수행하기 위해 사용됩니다.

DATA

프로세스 가 수행되면서 필요한 데이터들이 저장되는 영역입니다.

OS가 프로그램 을 분석하면서 사전에 정의할 수 있는 데이터만 저장됩니다.

프로세스 가 수행(함수와 같은)되면서 생성되는 데이터들은 사전에 저장하지 못합니다.

STACK

프로세스 의 명령어가 수행될 때 필요한 공간으로 사용됩니다.

함수의 콜스택 지역변수 데이터들이 적재됩니다.

HEAP

STACK 은 공간을 사용한 후 데이터가 소멸 됩니다.

반면에 HEAP 공간은 데이터가 소멸되지 않습니다. 소멸시키기 위해서는 추가적인 소멸 명령어가 필요합니다.

CODE, DATA와 다르게 필요한 공간을 미리 계산할 수 없는 STACK 과 HEAP은 임의의 크기가 정해진 공간을 같이 사용합니다. 따라서, STACK 또는 HEAP 메모리 사용량이 매우 많아지면 여유 공간이 없어 문제가 발생할 수 있습니다. STACK 공간을 과도하게 사용할 때는 StackOverflow, HEAP 공간을 과도하게 사용할 때는 OutOfMemery(OOM) 과 같은 에러가 발생할 수 있습니다.

프로그램 제어 블록(PCB)

컴퓨터는 하나의 프로세스만 수행하지 않고 여러 프로세스를 수행합니다.

그렇기에 메모리에는 많은 프로세스 들이 위치해 있습니다.

CPU는 어떻게 무수히 많은 프로세스 중에 특정 프로세스를 찾아내는 걸까요?

또 필요한 정보들을 취득하거나 저장하는 건 어떻게 하는 걸까요?

우리가 책을 읽을 때, 원하는 컨텐츠를 빠르게 찾기 위해서는 목차를 사용합니다.

CPU도 마찬가지로 프로세스 목차를 사용합니다.

이에 OS는 PCB 단위로 프로세스 목차를 구성하여 CPU에게 제공합니다.

PCB는 CPU가 프로세스를 수행하기 위해 필요한 데이터로 구성되어 있습니다.

PID(Process IDentification)

OS는 각 프로세스를 식별하기 위해 번호를 부여합니다. 이 식별 번호가 바로 PID 입니다.

포인터

CPU가 큐와 같은 공간에서 프로세스를 효율적으로 찾을 수 있도록 도와주는 정보입니다.

프로세스 상태

OS는 무수히 많은 프로세스를 정해진 절차대로 처리합니다. 해당 정보는 그 절차를 판단하기 위해 사용됩니다.

프로세스 상태에 따라 정해진 절차대로 수행하는 것을 프로세스 스케줄링 이라 부르며 프로세스 스케줄러 라는 프로그램이 수행합니다.

아래에서 자세히 다룰 예정입니다.

프로그램 카운터

해당 프로세스에서 CPU가 다음으로 실행할 명령어 위치를 가리키는 값입니다.

레지스터 정보

레지스터 는 쉽게 말해, 데이터를 저장할 수 있는 임시 공간입니다.

CPU가 프로세스를 처리하면서 필요한 데이터를 저장하고 읽는 용도로 사용합니다.

프로세스 스케줄링

현대 OS는 시분할 시스템을 제공합니다.

채팅을 하면서 동시에 음악을 들을 수 있는 이유는 CPU가 빠른 속도로 번갈아가면서 프로세스를 수행하기 때문입니다.

특정 프로세스가 CPU로 처리되기 위한 과정은 아래와 같습니다.

프로세스의 상태는 크게 5가지가 존재합니다.

생성 상태

프로그램을 메모리로 가져와 프로세스 제어 블록(PCB) 생성이 완료된 상태입니다.

준비 상태

실행을 기다리는 모든 프로세스가 자기 차례를 기다리고 있는 상태입니다.

실행될 프로세스는 CPU 스케줄러가 선택합니다.

실행 상태

선택된 프로세스가 타임 슬라이스를 얻어 CPU를 사용하는 상태입니다.

기존 수행되던 PCB가 준비 상태 또는 대기 상태로 넘어가면서 문맥 교환 오버헤드가 발생합니다.

대기 상태

실행 상태에 있는 프로세스가 입출력과 같은 인터럽트가 발생되면 완료될때까지 기다리는 상태입니다.

CPU가 키보드와 마우스 같은 입출력 장치의 처리를 기다리면서 생기는 병목현상을 방지합니다.

입출력 처리가 완료되면 해당 PCB를 준비 상태로 보냅니다.

문맥 교환(Context Switching)

CPU는 여러 프로세스를 특정 시간마다 번갈아 가면서 수행합니다.

요리 중 다른 요리를 하게 되면 기존 재료들을 냉장고에 넣고 새 재료를 배치하는 것처럼 CPU도 프로세스 교체 수행을 위한 준비가 필요합니다..

프로세스 를 교체할 때 CPU는 아래와 같은 과정이 필요합니다. (A 프로세스에서 B 프로세스로 교체된다고 가정합니다.)

A 프로세스의 정보를 A PCB 에 저장한다.

B 프로세스의 정보를 B PCB 로부터 가져온다.

이러한 준비시간을 CPU가 일을 하지 못하는 낭비시간이라 생각하여 오버헤드라 부릅니다.

문맥 교환 오버헤드를 개선하고자, 프로세스 교체 타임 슬라이스를 너무 길게 잡아도 프로세스 동시성 처리가 나빠질 수 있기 때문에 적당한 수준의 타임 슬라이스를 잡는 것이 중요합니다.

오늘 준비한 내용은 여기까지입니다.

읽어주셔서 감사합니다.

[네트워크] HTTPS 프로토콜

Mommoo — Fri, 16 Jul 2021 04:09:07 +0900

안녕하세요.

오늘은 HTTPS 통신 에 대해 포스팅 합니다.

HTTPS 통신 은 데이터를 암호화 하여 통신하도록 설계되어 보안적인 요소가 강화된 HTTP 통신 입니다.

HTTPS 통신 은 HTTP 통신 과 다르게 서버가 제공하는 SSL 인증서 라는 요소가 추가되었으며, 이를 통해 클라이언트는 필요한 서버의 정보를 취득하고 신뢰성을 판단합니다.

데이터 암호화

HTTPS 통신 방법에 앞서, 간단하게 데이터 암호화 개념을 살펴보면 좋습니다.

암호화 란 평문을 암호문으로 변경하는것을 의미합니다.

반대로 복호화 는 암호문을 평문으로 변경하는것을 의미합니다.

평문: 사람이 이해할 수 있는 데이터

암호화는 어떤 특정 데이터를 사용하여 수행하는데, 이 특정 데이터를 암호키 라고 부릅니다.

암호화는 크게 두가지 방식이 있습니다.

대칭키 방식

공개키 방식

대칭키 방식

대칭키 방식은 말그대로 암호키 가 대칭임을 의미 합니다.

암호화 할때도, 복호화 할때도 똑같은 1개의 암호키 를 사용하는 것이 특징입니다.

통신 하려는 대상 서로가 암호키 를 알고 있으면 매우 유용합니다.

하지만 불특정 다수와 통신을 하기 위한 안전한 암호키 전달이 무척 어렵습니다.

해커가 중간에 암호키 를 취득 해버리면 데이터를 암호화 하는게 의미가 없기 때문입니다.

Q. 암호키 도 암호화 해서주면 안되나요? A. 암호화 를 하기위해서는 무조건 최초로 평문으로된 암호키 를 넘겨주어야만 합니다. 암호키 를 암호화 해버리면 클라이언트는 복호화 를 할 수 있는 키를 모르기 때문입니다.

공개키 방식

공개키 방식은 암호키 가 두가지 존재합니다.

공개키

비공개키(개인키, 비밀키)

대칭키 방식 과는 다르게 암호화 할때 공개키를 사용했으면 복호화 는 비밀키 를 사용해야 합니다.

반대로, 암호화 할때 비밀키 를 사용했다면 복호화 는 공개키 로만 가능합니다.

공개키 방식의 장점

공개키 방식 은 대칭키 방식 의 키를 안전하게 전달하기 어려운 단점을 어느정도 해소 하였습니다.

서버가 개인키 를 소유하고 있고, 불특정 다수에게 공개키 를 전달합니다.

이때, 해커가 공개키 를 획득 할 수 있고 그로인해 서버가 내려주는 데이터 를 해석은 할 수 있지만 클라이언트에게 공격하지는 못합니다.

예를들어, 서버가 클라이언트에게 A의 장소 를 알려줬습니다. 이때 해커는 공개키 를 취득해 복호화 하여 내용을 읽었고 클라이언트에게 B의 장소 로 속이고 싶습니다.

해커가 데이터를 변경하더라도 서버가 가지고 있는 비밀키 를 알아야 클라이언트가 속을 수 있는 암호문 을 만들 수 있습니다.

해커가 임의로 암호문을 만들어버리면 클라이언트는 공개키 로 복호화에 실패할것이고, 결국 클라이언트에게 공격하지 못하는 상황이 발생합니다.

물론 클라이언트가 서버의 서비스를 이용 못하는건 있습니다. 하지만 공격 받지 않는것이 핵심입니다.

반대로 클라이언트가 서버로 데이터를 보낼 때는 공개키 로 데이터를 암호화 하여 보냅니다.

해커는 공개키 만알고 있기 때문에 클라이언트 데이터를 읽지 못합니다. 왜냐면 공개키 방식 은 공개키 로 암호화 를 하면 비밀키 로만 복호화 를 진행할 수 있기 때문입니다.

정리하자면 공개키 방식 은 클라이언트로 하여금 데이터가 변경되지 않음을 보장할 수 있고 안전하게 데이터를 서버로 보낼 수 있는 장점이 있습니다.

공개키 방식의 단점

하지만 공개키 방식도 한계가 존재합니다. 클라이언트 → 서버로 데이터를 암호화 해서 보내는건 문제가 되지 않습니다. 해커가 읽지도 못하니깐요.

하지만 서버 → 클라이언트로 보내는 데이터는 해커가 읽을 수 있습니다. 만약 데이터가 민감한 개인 정보같은게 포함되어 있다면 해커가 읽는것만으로도 피해가 생길 수 있기 때문입니다.

또한 공개키 방식 은 대칭키 방식 보다 암-복호화 속도가 느립니다.

SSL 인증서

HTTPS 통신 에서는 서버가 SSL 인증서 를 제공한다고 언급했습니다.

이 SSL 인증서는 크게 두가지 역할을 수행합니다.

서버 본인이 신뢰할 수 있는 서버임을 증명하는 수단.

서버가 제공하는 공개키를 전달.

SSL 인증서 는 서버의 신뢰성을 판단할 수 있는 수단이라 했는데, 다짜고짜 클라이언트에게 SSL 인증서 를 내밀면 신뢰할 수 있을까요?

예를들어, 모르는 사람이 다가와서 나 믿을 수 있는 사람이야 라고 말하면 여러분을 믿을 수 있으신가요?

그렇기에 SSL 인증서 의 신뢰성을 대신 보장하는 제 3자가 존재합니다.

그 3자를 CA(Certificate authority) 혹은 Root Certificate 라 일컫는 기업들입니다.

해당 기업들은 세계적인 기업으로써, 신뢰성이 엄격하게 공인된 기업들만 CA로써, 참여할 수 있습니다.

이러한 기업은 SSL 인증서 를 신청한 기업들이 신뢰성있는 기업인지 평가한 후 발급을 진행합니다.

CA 기업들은 잘 알려진 기업들로써, HTTPS 통신을 지원하는 클라이언트(대표적으로 브라우저)들은 CA 리스트 를 보유하고 있습니다. 그렇기에, 클라이언트는 SSL 인증서 를 받은 후 정보를 읽어 CA 리스트 대조를 통해, CA 가 발급한 SSL 인증서 의 유무를 판단하고 신뢰성을 평가합니다.

CA 가 발급하지 않은 SSL 인증서 는 클라이언트가 신뢰성을 낮게 평가합니다.

SSL 인증서 암호화

SSL 인증서는 비공개키 방식 으로 암호화하여 클라이언트에게 전달됩니다.

이때, 암호화 를 수행하는 대상은 서버가 아닌, CA 에서 자체적으로 소요한 비밀키 를 통해 암호화 를 진행합니다.

즉 SSL 인증서 를 서버에서도 변조하여 클라이언트에게 공격할 수 없습니다. 비밀키 를 모르기 때문입니다.

CA 의 공개키는 이미 널리 알려진 정보로써, 클라이언트가 CA 리스트 와 함께 공개키 도 보유하고 있습니다. 그렇기에 위에 앞서 언급한 공개키 방식 장점을 잘 활용하고 있다고 볼 수 있습니다. SSL 인증서 가 위조되지 않음을 보장받을 수 있기 때문입니다.

SSL 인증서에 포함된 공개키

SSL 인증서엔 공개키가 포함되어 있는데 이는, CA 의 공개키가 아닙니다. 서버가 클라이언트와 보안 통신을 하기위해 서버가 직접 생성한 공개키 입니다.

서버가 CA 에게 SSL 인증서 의 발급 신청을 할 때, 몇몇 서버 데이터를 전달하는데 필수적으로 공개키 도 전달이 되어야 합니다.

뒤에 설명할 SSL 통신 에서는 클라이언트가 SSL 인증서 를 통해 서버의 공개키 를 취득하고, 비공개 방식 으로 보안 통신하는 절차가 있기 때문에 필수적으로 필요합니다.

SSL 통신

공개키 방식 으로 통신을 하면, 서버 → 클라이언트로 데이터를 내려줄땐 조금 문제가 될 순 있지만, 어느정도 감안하고 보안 통신 방법으로 사용할 수 있을거 같습니다.

하지만, 큰 단점이 있는데요.

그것은 바로 공개키 방식은 암호화 복호화 하는 과정이 느리다 라는 것 입니다.

웹통신이 느리면, 문제가 될 수 있기 때문에 SSL 통신 은 상대적으로 빠른 대칭키 방식 으로 메인 통신을 진행합니다.

하지만, 대칭키는 공격자가 알면 너무나도 쉽게 데이터를 변조하여 대상을 속일 수 있기 때문에 매우 위험합니다. SSL 통신은 어떻게 이런 이슈들을 해결했을까요?

SSL 통신 방법

결론적으로 말하자면, SSL 통신은 공개키 방식 과 대칭키 방식 둘 다 사용합니다.

SSL 통신은 다음의 아이디어를 사용합니다.

공개키 방식 으로 서버와 함께 작성된 대칭키 를 서로에게 전달합니다. 이때 중간 공격자는 서버의 개인키 를 알고있지 않는한 내용을 복호화하지 못하여 데이터 해독이 불가능 합니다.

이렇게 서로 안전하게 대칭키 가 전달되었다면, 암-복호화가 빠른 대칭키 로 데이터 통신을 합니다.

SSL 통신 절차

TCP와 같은 연결지향 프로토콜은 크게 아래의 과정을 거칩니다.

악수(HandShake)

데이터 전송(세션)

세션 종료

SSL 통신도 결국 TCP위에서 동작하므로, 위 과정과 같습니다만, 세부적인 내용이 조금 다릅니다.

SSL 통신은 TCP의 핸드쉐이크 (SYN → SYN ACK → ACK) 과정이 이루어 진 후에, SSL 통신이 시작됩니다. (악수 → 데이터 전송 → 세션 종료)

악수(HandShake)

Client Hello (클라이언트가 서버에 접속합니다. )
- 서버에게 평문 문자열 Client Hello 를 전송합니다.
- 서버에게 대칭키 를 만들 수 있는 랜덤 데이터를 평문으로 전송 합니다.

Server Hello (서버가 Client Hello 를 받은 후, 클라이언트에게 응답합니다.)
- 클라이언트에게 평문 Server Hello 를 전송합니다.
- 클라이언트에게 대칭키 를 만들 수 있는 랜덤 데이터를 평문으로 전송합니다.
- 제일 중요한 SSL 인증서 를 전송합니다.

클라이언트의 SSL 인증서 신뢰성 판단
- 서버에게 받은 SSL 인증서 를 보유하고 있는 CA 리스트를 통해 복호화 합니다.
- 복호화 에 성공하였다면, 해당 서버를 신뢰할 수 있다고 판단합니다.

서버에 대칭키 전송 (SSL 핸드쉐이크의 핵심 목적 입니다.)
- 클라이언트는 본인이 만든 랜덤 데이터와 서버에서 받은 랜덤 데이터를 이용하여, 대칭키 를 구성합니다.
- 해당 대칭키를 SSL 인증서 에 포함되어 있는 서버 공개키로 암호화 하여 서버에게 전송합니다.

핸드쉐이크 종료
- 클라이언트와 서버가 서로 대칭키 를 안전하게 전달 받은 후, 통신 준비가 되었다는 신호와 함께 핸드쉐이크가 종료됩니다.

데이터 전송(세션)

서버와 클라이언트가 데이터를 서로 주고 받고 하는 단계입니다. 서로 안전하게 전달받은 대칭키 를 사용하여, 암-복호화를 빠르게 진행합니다.

세션종료

데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려줍니다.

오늘 준비한 포스팅은 여기까지 입니다. 읽어주셔서 감사합니다.

Uploaded by Notion2Tistory v1.1.0

[자료구조] 이진탐색트리

Mommoo — Mon, 12 Jul 2021 01:33:29 +0900

안녕하세요.

오늘은 이진 탐색트리 에 대해 포스팅 합니다.

이진 탐색트리 란

이진 탐색트리 는 이진 탐색(Binary Search)의 아이디어를 채용한 자료구조 입니다.

이진 탐색은 원소가 정렬되어 있다는 조건아래, 정렬된 특징을 이용해 반씩 쪼개가며 검색을 합니다.

그러므로, 검색 횟수가 획기적으로 낮아지는 특징이 있습니다.

이는, 이진 탐색트리도 똑같이 원소가 정렬된 형태로 지니고 있어야 하고 반씩 쪼개가며 검색을 할 수 있는 구조를 갖추고 있어야 함을 의미합니다.

그러면... 이진 탐색 사용하면 되는거 아닌가요?

그렇다면, 이진 탐색트리는 이진 탐색을 사용하는 배열 자료구조보다 나은점이 무엇일까요?

아시다 시피, 배열은 조회에 강점이 있는 자료구조 입니다. 그렇다 보니, 검색만 한다고 가정할 때는 트리 구조가 굳이 필요하지 않습니다.

하지만, 원소가 삽입/삭제 될 수 있다고 가정하면 어떨까요? 배열 자료구조는, 삽입/삭제 될 Index 를 찾은 후, 그 Index 뒤에 위차한 원소들을 한칸씩 전부 뒤로 이동해야 하는 수고가 존재합니다. 또한, 배열공간이 모자라, 배열 크기를 증가시키거나 혹은 공간이 너무 남아, 축소 시키는 작업은 덤으로 발생할 수 있습니다.

그에 반면에, 트리 구조는 참조(포인터)만 변경해주면 되므로, 원소의 대량 이동이 필요 없고, 공간 복잡도를 신경안써도 되는 장점이 있습니다. 그렇다보니, 삽입/삭제 연산이 한번이라도 존재한다면, 이는 삽입이 연속적으로 N번 발생할 수도 있다는 의미이므로 굳이 배열 자료구조를 사용할 필요가 없습니다.

사실 조회 자체도 이진 탐색 구조상 트리 도 특정 노드의 Index 검색이 아닌, 특정 노드로부터 순차대로 검색하는 구조이므로 배열이랑 크게 차이가 없습니다.

예를들어, 연결 리스트는 특정 Index 노드 검색 시간복잡도는 O(n)이지만, 전체 순회를 할 때는 각 노드의 참조값을 순차대로 탐색하므로 각 노드의 검색 시간이 O(1) 입니다.

결론적으론, 이진 탐색트리가 더 보편적으로 사용될 수 있다고 말할 수 있겠습니다.

이진탐색을 위한 트리 구조

이진 탐색트리 는 트리에 어떤식으로 데이터의 구조를 형성하길래, 이진 탐색이 가능한걸까요?

아래와 규칙으로 데이터를 쌓기 때문입니다!

규칙만 봐서는 이해가 어렵습니다. 아래의 예시 이미지와, 삽입과정 설명을 보시는걸 추천합니다!

루트 노드가 비었다면, 삽입 노드를 루트 노드로 채웁니다.

루트 노드가 존재한다고 가정할 때, 삽입 노드의 값과 비교하여 삽입 노드의 값이 작으면 루트 노드의 오른쪽, 크면 오른쪽으로 이동합니다.

이동시, 노드가 비었다면 삽입 노드로 채웁니다.

만약 노드가 존재한다면, 2번~3번 과정을 반복합니다.

이진 탐색트리 순회

이진 트리는 대표적인 DFS 순회방법 3가지가 있습니다.

전위 순회(pre-order traversal)

중위 순회(in-order traversal)

후위 순회(post-order traversal)

이때, 중위 순회를 이용하면 정렬된 원소의 목록을 획득 할 수 있습니다.

위 예시를 중위 순회를 해보면 다음과 같은 원소의 목록을 얻을 수 있습니다.

1 > 2 > 3 > 4 > 5 > 7 > 9

따라서, 해당 트리 구조는 트리 정렬 알고리즘 으로도 사용되며,

이진 탐색트리를 제공하는 프로그래밍 API 에서는 정렬을 이용한 기능을 제공하는 경우가 많습니다.

ex) Java Collection API: TreeMap, TreeSet 은 이진 탐색 트리 구조로 트리를 쌓습니다. 따라서 특정 값들이 정렬로 보관되어 있고, 정렬특징을 이용하는 메서드들이 존재합니다.

이진 탐색트리 검색

예시의 이진 탐색트리 에서 4 노드를 검색한다고 가정해봅시다.

첫번째로 만나는 노드는 5 입니다. 검색노드가 5 보다 작으므로, 왼쪽으로 이동합니다.

두번째로 만나는 노드는 3 입니다. 검색노드가 3 보다 크므로, 오른쪽으로 이동합니다.

세번째로 만나는 노드는 4 입니다. 검색노드와 일치 하므로 해당 노드를 리턴 합니다.

Q. 4 의 존재유무를 검색 해보는건 의미가 있을거 같은데, 어차피 똑같은 값인 노드를 리턴하는게 의미가 있을까요? A. 노드는 꼭 하나의 값을 가진 자료형이 아닙니다. 예를들어 아래의 노드의 자료형을 구성한다고 생각해봅시다. 이때 4 로 검색하면 아래의 노드가 리턴 되고 리턴된 노드에서 제공하는 정보를 활용할 수 있습니다.

{
  "name": "Mommoo",
  "job": "Developer",
  "value": 4
}

이진 탐색트리 삽입

이진 탐색트리 에 노드를 넣는 순서는 다음과 같다고 가정합니다.

5, 3, 1, 4, 7, 9, 2

위에서 설명한 규칙대로 삽입과정을 거칩니다.

검색과 마찬가지로 이동하며, 자리를 찾아 노드를 저장합니다.

이진 탐색트리 삭제

이진 탐색트리의 검색/삽입 연산과 달리 삭제는 조금 복잡합니다.

고려해야 할 케이스를 3개로 나눌 수 있습니다.

삭제할 노드가 말단 노드인 경우(자식노드가 없는 경우)

삭제할 노드의 자식 노드가 1개인 경우

삭제할 노드의 자식 노드가 2개인 경우

삭제할 노드가 말단 노드인 경우

해당 경우는 간단합니다. 삭제할 노드만 삭제해주면 됩니다.

아래의 예시는 2 노드를 지웁니다.

삭제할 노드의 자식 노드 1개인 경우

이 경우도 어렵지 않습니다. 삭제할 노드의 자식들의 트리 구조 규칙은 삭제할 노드의 조상으로 부모를 바꾸더라도 규칙이 깨지지 않기 때문입니다.

이래의 예시는 7 노드를 지웁니다.

삭제할 노드의 자식 노드가 2개인 경우

이 경우가 살짝 복잡합니다. 삭제할 노드의 자리에 대신 채울 노드를 찾아야 하는 과정이 필요합니다.

대신 채울 노드를 찾는 방법은 2가지 존재합니다.

삭제할 노드의 왼쪽 서브 트리에서 최대 값 노드

삭제할 노드의 오른쪽 서브 트리에서 최소 값 노드

아래의 예시는 20 노드를 삭제할 때, 서브 트리에서 위 방법으로, 노드를 찾아 대체합니다.

이진 탐색트리 시간 복잡도

검색/삽입 시간복잡도

위에서 검색/삽입 연산을 살펴보시면 아시겠지만, 모든 원소를 탐색하지 않는것이 특징입니다.

최악의 경우는 트리의 높이 만큼 탐색하는 경우라 볼 수 있겠습니다.

따라서 높이가 H 인경우의 검색/삽입의 시간 복잡도는 O(H) 입니다.

하지만, 시간복잡도는 원소의 개수로 표기할 때, 조금 더 좋은 표현이라 할 수 있습니다.

H 를 원소의 개수 N 으로 표현해볼 수 없을까요?

이진 트리는 대개, 원소의 개수가 N 이면 $log_2N$ 으로 치환 가능합니다.

이진 검색트리 구조가 완전 이진 트리라 가정할 때의 경우로 한정적이긴 합니다. 그래서 최악의 경우로 규정짓는 빅오 표기법으로는 애매하긴 합니다.

따라서, 검색/삽입 연산의 시간복잡도는 $O(log_2N)$ 으로 표기 가능합니다.

삭제 시간복잡도

삭제 시간복잡도는 왜 따로 다룰까요?

검색/삽입과 동일하게 다룰 수 없는 찜찜한 구석이 있지 않았나요?

네 맞습니다. 삭제할 노드의 자식 노드가 2개인 경우 에는 추가 연산이 있기에 시간 복잡도를 다시 따져봐야 할거 같습니다.

검색 시간복잡도는 O(H) 로 삭제할 대상을 검색하는 것도 동일하게 시간이 소모됩니다.

이때, 삭제할 노드가 단말 노드, 삭제할 노드의 자식 노드가 1개 인 경우는 지우거나 참조값만 붙여주면 되므로, O(1) 의 시간이 소모된다고 볼 수 있습니다. 따라서 총 시간 복잡도는 O(H + 1) → O(H) 라 할 수 있겠네요.

그렇다면 우리가 궁금한 삭제할 노드의 자식 노드가 2개 인 경우는 어떨까요?

검색 후, 대체할 노드만 찾는다면 대체 노드의 참조값만 바꿔주면 되므로 O(1) 입니다.

그말은, 대체할 노드를 찾는게 얼마나 걸리는지에 따라 시간 복잡도가 규정 된다는 점입니다.

생각해보자면, 대체할 노드를 찾는것도 결국 탐색이 필요합니다. 다만 Full-Tree 가 아닌 Sub-Tree 에서의 검색이지요. 시간복잡도를 간단하게 정의해본다면 O(H-K) 정도가 될것입니다.

K 는 탐색을 시작할 높이 값입니다.

시간복잡도는 최악의 경우를 생각해야 하므로, 최악의 경우의 K는 0 이 되는 경우가 있겠네요.

이 경우는 루트를 지운다는 의미입니다.

결국 서브트리를 탐색하는 시간복잡도도 O(H) 라 생각할 수 있겠습니다.

정리해보자면, 아래의 작업이 필요합니다.

삭제 노드를 탐색 O(H)

대체 노드를 찾기 위한 서브 트리를 탐색 O(H)

참조값 변경 O(1)

따라서 삭제 연산의 시간 복잡도는 O(H + H + 1) → O(2H) → O(H) 라 볼 수 있습니다. 위에서 N으로 치환한것과 마찬가지로 $O(log_2N)$ 으로 표기 가능하겠습니다.

결론적으로 탐색/삽입/삭제 시간복잡도는 전부 동일하게 $O(log_2N)$ 라고 정의할 수 있습니다.

이진 탐색트리 사용시 고려할 점

중복값 처리 (주관적 의견. 뇌피셜 주의보!)

지금까지 보여드린 예시는 중복값이 없는 예시입니다. 이진 탐색트리 는 중복값을 허용하면 안된다는 자료가 많이 보이는거 같습니다.

현실적으로 중복값이 충분히 나올 수 있는지라, 중복값 비허용 규칙은 너무 잔인하다고 느꼈습니다.

제가 짧게 연구 해봤을때, 중복값을 노드의 왼쪽에 배치할 것인지, 오른쪽에 배치할 것인지만 정하고 배치하면 무리없이 동작합니다.

다만, 중요한것은 중복의 개수만큼 끝까지 내려간 후, 연결되어야 한다는 점입니다.

아래의 예시에서 왼쪽의 경우는 안됩니다. 트리 규칙이 깨지게 됩니다.

다만 중복의 개수가 많아지면, 트리의 높이가 너무 커지게 되고 시간복잡도가 비약적으로 올라가게 될것입니다.

그렇다보니, 다음과 같은 아이디어도 좋을거 같습니다.

단순히 값만 정의된 노드라면, 노드에 카운팅을 추가.

특정 자료형으로 정의된 노드라면, 해당 노드를 여러개 저장할 수 있는 자료구조를 감싼 wrapper 노드로 트리를 구성.

다만 추가 공간을 쓰게 되는 단점은 있는거 같습니다.

한쪽으로 쏠린 트리

이진 검색트리 의 시간복잡도는 $O(log_2N)$ 이라 소개드렸는데, 사실 최악의 경우는 O(N)이 나오게 됩니다.

Q. 빅오 표기법은 최악의 시간인 경우로 표기해야 하므로, 이진 탐색트리 의 연산 시간복잡도는 O(N) 아닐까요? A. 엄밀히 따지자면 O(N)이 맞습니다. 빅오표기법의 약점은 빈번도를 체크 하지 못합니다. 100번에 1번 나오는 경우의 수 때문에 최악의 경우로 시간을 규정하는게 제대로 된 측정값 일까요? 그렇기에 퀵소트도 $O(n^2)$ 이라 하지 않고, 대체적으로 측정되는 $O(Nlog_2N)$ 이라고 표기합니다.

간단한 예로, 정렬된 순서로 요소가 들어가게 된다면 아래와 같은 트리 구조로 구성되게 됩니다.

1, 2, 3, 4, 5

해당 구조는 트리 라기보다, 연결 리스트 의 구조로 잡혀있습니다.

높이가 낮을 수록 성능에 유리한 이진 검색트리가 이렇게 개수만큼 높이가 쌓이게 되면, 검색/삽입/삭제는 선형 연산이 되버립니다. 선형 연산이기 때문에 시간 복잡도는 O(N) 이 됩니다.

5를 찾으려면 5번 탐색 이 필요하네요.

균형 이진 탐색트리

이진 탐색트리 는 완전 이진트리 구조로 쌓여야, 요소 개수 N개의 대비 최소 높이가 됩니다.

그렇다면, 요소를 어떤 순서로 삽입 하더라도, 강제적으로 완전 이진트리 구조로 되게끔 규칙을 만들면 어떨까요!?

그러한 알고리즘을 추가한 이진 탐색트리 를 균형 이진 탐색트리 라 부르며, 대표적은 구현체는 AVL 트리 , 레드 블랙 트리 등이 있습니다.

오늘 포스팅은 여기까지 입니다.

뇌피셜인 부분도 있으니, 주의해서 읽어주셨으면 합니다.

읽어주셔서 감사합니다.

[자료구조] 트리(Tree)

Mommoo — Sat, 10 Jul 2021 01:43:12 +0900

Tree 란

안녕하세요.

오늘은 자료구조 트리(Tree)에 대해 포스팅 합니다.

필수적으로 알아야 할것들만 정리하였습니다.

트리구조에 대해 대략적으로 설명하므로, 특정 용어나 개념들은 따로 찾아봐야 합니다.

트리(Tree) 란

위 본문의 그림과 같이 노드 와 간선으로 이루어진 것을 그래프(Graph) 라고 합니다.

트리는 이러한 그래프 의 일종 입니다. 아래의 규칙을 따르는 그래프를 트리라고 일컫습니다.

사실 규칙을 외울 필요는 없고, 이런 형태구나 정도로 기억하면 될 거 같습니다.

트리 규칙

특정 노드는 오직 하나의 조상 노드와 N 개의 자식 노드와 연결됩니다.
- 특정노드에서 조상노드, 자식노드는 레벨의 차이가 반드시 1이어야 합니다.
- C 노드는 하나의 조상 노드인 A와 2개의 자식 노드인 G , H와 연결됩니다.

여러 노드가 한 노드를 가리킬 수 없습니다.
노드와 노드를 잇는 길(간선)이 하나만 존재합니다.

또한 트리는 다음과 같은 특징들을 가집니다.

높이

트리는 루트로 부터 레벨 을 셀 수가 있는데 이때 최대 레벨의 값을 높이라 부를 수 있습니다.

따라서, 예제의 트리의 높이는 3입니다.

말단 노드(리프 노드)

자식이 없는 노드를 말단 노드 또는 리프 노드라 일컫습니다.

형제 노드

같은 부모를 가지는 노드들을 형제(sibling)노드라 부릅니다.

서브 트리

트리안에서 특정 범위를 묶어 하나의 작은 트리를 구성 할 수 있습니다.

예제 트리의 빨간 박스, 파란 박스 와 같은 예시처럼 묶을 수 있으며 이를 서브 트리라 일컫습니다.

이진트리 (Binary Tree) 란

트리의 특정 노드는 자식의 개수를 제한 없이 가질 수 있는데요.

이때, 최대 2개의 자식 노드만 가질 수 있다 는 조건을 추가한것을 이진트리라고 부릅니다.

쉽게 말해, 노드가 왼쪽 자식 과 오른쪽 자식을 갖는 특징을 가집니다.

예제의 트리도 이진트리라 부를 수 있습니다.

이진트리구조를 갖추면, 해당 구조가 제공하는 연산의 이점들이 존재합니다.

예를들면, 노드의 개수를 알면 높이를 알 수 있습니다.

레벨(N)당 노드의 개수는 2^N 이기 때문입니다.

대표적으로 사용되는 연산은 탐색입니다.

너무나도 유명한 이진 탐색 트리 를 구성할 수 있습니다.

특정 조건이 추가된 이진 트리들이 있습니다.

완전 이진트리

모든 레벨에서의 노드가 꽉차 있어야 합니다.
예외적으로, 마지막 레벨에서의 노드는 꽉차 있지 않아도 되지만 왼쪽에서 차례대로 채워져야만 합니다.
예시 트리도 완전 이진트리 입니다.
예시 트리에서 N 만 없애거나, (M, N) 을 없애거나, (L, M, N)을 없앤 케이스도 완전 이진트리입니다.

전 이진트리

특정 노드의 자식이 0개 또는 2개로만 구성되어 있는 트리를 의미합니다.
예시 트리에서 (G, H)를 없애거나, (E, F, K, L, M, N)을 없앤 케이스를 전 이진트리로 볼 수 있습니다.

포화 이진트리

모든 말단 노드가 같은 높이에 있어야 합니다.
- 예를들어, (E, F, K, L, M, N)을 없앤 케이스를 전 이진트리형태는 말단 노드인 B가 다른 말단 노드인 G와 레벨이 동일하지 않습니다.
마지막 레벨에서 노드의 개수가 최대가 되어야 합니다.
예시 트리도 포화 이진트리라 부를 수 있습니다.

이진 탐색트리

노드의 자식은 아래의 규칙을 따릅니다.
- 오른쪽 노드의 값 < 현재 노드의 값 < 왼쪽노드의 값
값을 이용한 규칙을 통해 구조를 쌓으면 추후 이진 탐색을 사용할 수 있습니다.

다음 포스팅에서 자세히 다룰 예정입니다.

이진트리 순회

이진트리를 연산하기 위해서는 순회는 빼놓을 수 없습니다. 방문하지 않으면 값을 알 수 없기 때문입니다.

순회는 많이 알려진 방법인 너비우선탐색(BFS), 깊이우선탐색(DFS) 으로 나눌 수 있습니다.

너비우선탐색(BFS)

레벨순으로 차례대로 탐색합니다.

예시 트리를 기준으로 설명드리자면, 아래와 같이 탐색합니다.

Root > A > B > C > D > E > F > G > H > I > J > K > L > M > N

깊이우선탐색(DFS)

탐색 방법 3가지가 존재합니다.

기본적으로 왼쪽 자식 노드에서 오른쪽 자식 노드로 순회를 한다고 가정(B -> C)하고 현재 노드(A)가 방문되는 순서를 기억하면 좋습니다.

전위 순회 (pre-order traversal)
- 현재 노드(A)가 첫번째로 방문 됩니다.
- B ->C는 고정이므로 첫번째로 방문되려면 맨 앞에 배치 되어야 합니다.
- A -> B -> C
중위 순회 (in-order traversal)
- 현재 노드(A)가 중간에 방문 됩니다.
- B -> A -> C
후위 순회 (post-order traversal)
- 현재 노드(A)가 마지막에 방문 됩니다.
- B -> C -> A

위 예시는 서브 트리가 존재하지 않는 트리인 경우 입니다.

만약 서브 트리가 존재한다면 어떻게 방문할까요?

이때는 서브 트리를 하나의 노드라 생각하고 방문합니다.

다음의 트리를 이용하여 전위 순회로 알아봅시다.

해당 예시의 서브 트리는 (B, D, E) 입니다.

STEP1: 서브 트리를 하나의 노드(BB)로 치환하여 전위 순회를 진행합니다.(A -> BB -> C)

STEP2: BB도 트리이므로 내부적으로 순회를 똑같이 진행합니다. (B -> D -> E)

STEP3: 서브 트리 순회 결과를 치환한 노드BB에 반영합니다. (A -> B -> D -> E -> C)

최초 분문의 예시를 각 방법으로 순회 하면 다음과 같습니다. (ROOT의 위치를 살펴보세요.)

전위 순회 : ROOT > A > C > G > H > D > I > J > B > E > K > L > F > M > N

중위 순회 : G > C > H > A > I > D > J > ROOT > K > E > L > B > M > F > N

후위 순회 : G > H > C > I > J > D > A > K > L > E > M > N > F > B > ROOT

오늘 준비한 내용은 여기까지 입니다.

읽어주셔서 감사합니다.