IT's 잡탕찌개 블로그

DB 혹은 server를 개발하다보면 UUID란 말을 한번쯤은 들어봤을 것이다.
이번 포스팅에서는 UUID란 무엇이고 그 외 추가적인 내용을 알아보자.

UUID란?
UUID란 범용 고유 식별자(Universally Unique Identifier)의 약자이다.
간단하게는 다른 리소스중에서 해당 리소스를 고유하게 식별해주는 값 이라고 생각하면 된다.

이렇게만 보면 기본적으로 ID를 auto increment해주는 것과 차이가 없다고 생각할 수도 있다.
일반적인 ID와는 어떠한 점에서 차이가 있을까?

우선 UUID는 주로 분산 컴퓨팅 환경에서 사용되는 식별자로, 중앙 관리 시스템에서 순차적으로 일련번호를 부여하는 것이 아니더라도 고유한 값을 보장할 수 있어야 하기때문에 탄생하게 되었다.
- 물론 UUID 역시 완벽하게 고유성을 보장하지는 못한다.

UUID의 구조
UUID는 128 bit(16byte)로 구성된다.
UUID는 32자리의 16진수로 표시되는데 여기서 각 8-4-4-4-12 자리마다 의미하는 내용이 다르다.

UUID의 종류
UUID는 버전이 여러개 존재하는데( 1 ~ 5 ) 대표적으로 1, 4 버전이 많이 사용된다.
1 버전의 경우 UUID 생성을 timestamp를 기준으로 생성하며,
4 버전의 경우 무작위 랜덤 생성을 통해 UUID를 발급한다.


UUID의 하이픈(-)을 제거해도 괜찮은가?
UUID를 발급 받으면 해당 문자열에는 하이픈이 포함되어 있다. 굳이 문자열 길이를 더 늘린상태로 활용해야할 필요가 있을까? 우선 UUID에 하이픈이 포함되는 것이 국제 표준이며 유일성을 보장받을 수 있다.
다만 하이픈을 없앤다고 해도 유일성이 깨지는 확률이 상당히 낮다

우리는 rpgoramming을 하면서 thread라는 말을 자주 듣게 된다.
이번 포스팅에서는 thread란 무엇인지에 대해서 간단하게 알아보자.

thread란 ?
thread는 어떠한 program 내부에서, 특히 process 내에서 실행되는 흐름을 의미한다.
일반적으로 하나의 program은 하나의 process를 생성하지만 하나의 process안에서는 여러개의 thread를 생성, 실행할 수 있다.
이러한 실행 박식을 multithread라고 한다.

process와 thread의 차이
multithread와 multiprocess는 여러 흐름이 동시에 진행된다는 점에선 같다고 볼 수 있다.
(multiprocess : 여러 program이 동시에 실행되는 상태)
다만 multiprocess는 각 process가 독립적으로 실행되며 특정 process가 실행되기 위해선 context switching을 통해 cpu를 점유해야 한다.
반면 multithread의 경우 동일한 process내에서의 작업 흐름이므로 특정 메모리를 공유하며 이로 인해 동일 process내의 다른 thread가 cpu를 점유할 때 context switching이 발생하지 않는다.

multithread의 장점
multithread의 장점은 cpu가 여러개인 환경에서 각각의 thread가 cpu를 하나씩 점유하면 작업 처리 속도가 훨씬 빨라진다는 것이다.

multithread의 단점
다만 multithread의 단점도 여러가지가 존재하는데 우선 특정 thread 간의 실행 순서에 대해서 알수가 없다는 것이다.
간단한 예로 여러 thread가 특정 변수의 값을 1씩 증가시키는 경우 code 상에서는 단 1줄로 변수값을 1증가시키지만, 실제 기계어 레벨에서 살펴본다면 레지스터에 대한 작업 단위로 구분할 수 있고 thread의 cpu점유가 어떻게 되는지에 따라서 변수의 값이 증가하지 않을 수도 있다.
이러한 순서 보장이 안되기 떄문에 여러가지 문제가 발생할 수 있고 이를 해결하기 위한 구현 난이도가 높아진다.

thread의 종류
thread는 해당 thread를 지원하는 주체에 따라서 2가지로 구분된다.

user level thread
사용자 스레드는 kernel 영역 상위의 app영역에서 지원되며 일반적으로는 사용자 라이브러리를 통해서 구현된다.
사용자 라이브러리는 스레드의 생성 및 스케줄링에 대해 관리기능을 제공한다.
동일한 메모리 영역에서 스레드가 생성 및 관리 되므로 속도가 빠른 장점이 있지만, 시스템 호출 등의 요청이 있을 시 다른 스레드들이 유휴상태에 빠지게 되는 단점이 있다.
이는 kernel이 process 내부의 thread를 인식하지 못하기 때문에 process를 대기상태로 전환시키기 때문이다.

kernel level thread
kernel level thread는 OS가 지원하는 thread 기능으로 구현되며, kernel이 thread의 생성, 스케줄링을 담당한다. thread가 system call등으로 중단되더라도, kernel은 process내의 다른 thread를 중단시키지 않고 실행시켜준다.

thread data
thread는 두가지 data가 존재한다. thread자체의 기본 ata는 실행과 관련된 data를 지니며, 자신만의 고유한 thread id, PC(program counter), register, stack을 지닌다.
code, data, file등의 자원은 process의 자원을 사용하며 동일 process하의 다른 thread들과 공유한다.
기본 data외의 특정 thread에만 필요한 정보들이 필요한 경우도 존재하는데,
이러한 data는 (TSD)thread specific data라고 부른다.
예를 들면 각 thread 별로 처리하는 transaction 이 다를 경우 이에 대한 transaction id를 기억해야한다.
그 외의 예로는 TLS(thread local storage) 등등이 있다.

참고-
https://ko.m.wikipedia.org/wiki/%EC%8A%A4%EB%A0%88%EB%93%9C_(%EC%BB%B4%ED%93%A8%ED%8C%85)

우리는 개발을 하면서 process라는 말을 자주 접한다. 이번 포스팅에서는 process란 무엇인가를 포함해서 다양한 내용을 다뤄 볼 것이다.

process란 무엇인가?
process는 컴퓨터에서 연속적으로 실행되고 있는 program을 의미하며
종종 cpu scheduling 대상인 task와 동일한 의미로 사용된다.
process는 program 그 자체 또는 program의 상태가 memory 상에서 실행되는 작업 단위를 지칭한다.
- program A를 여러개 실행하면 여러개의 process가 생성된다.

process의 구조
process의 구조는 크게 아래와 같이 구분된다.
. text : 컴파일 된 code 가 저장된느 영역
. data : 전역변수 및 초기화된 data가 저장되는 영역
. heap : code 상에서 동적으로 생성되는 ata가 저장되는 영역
. stack : 함수 콜스택, 지역변수 등이 저장되는 영역

process의 상태와 그에 대한 설명
process는 아래와 같은 상태를 가진다.
. create
- proces를 생성하는 상태
. running
- process가 cpu를 점유하고 관련 명령어들을 실행 중인 상태
. ready
- process가 CPU를 사용하고 잇지는 않지만 점유를 준비중인 상태.
. waiting
- process가 특정 input 혹은 signal을 기다리는 상태.
. terminated
- process가 종료된 상태


process의 상태 변화
하나의 program이 실행되면 그에 대응하는process가 생성되어 준비 리스트에 들어간다.

그 후 이미 준비 리스트에 있던 다른 process가 CPU를 할당받아 떠나면 순차적으로 앞으로 나아간다.

process가 겪는 상태 변화는 아래와 같다

. dispatch : ready -> running

. block : running -> blocked

. wakeup : blocked -> ready

. timeout : running -> ready

process mode

process는 두가지의 mode가 존재한다. 각각 UserMode와 KernelMode이다.

우선 간단하게 알아둘 것으로는 운영체제는 기본적으로 가상 메모리를 user 영역과 kernel 영역으로 구분한다.

 kernel 영역은 kernel, kernel 확장기능, 대부분의 장치 driver를 실행하기 위한 예비 공간이다.

반면, user 영역은 모든 사용자 모드의 application들이 동작하는 영역으로 해당 메모리는 필요할 때 Paging 처리 될 수 있다.

User 영역의 process는 일반적으로 고유한 가상 메모리 영역에서 실행되며, 다른 process의 메모리에 접근할 수 없다.

참고 -
https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4

proxy server 란?

. client가 자신을 타 network service에 간접적으로 접속할 수 있게 해준다.

 - server, client 사이에서 대리자로써 통신을 중계해준다.

 - LAN -> WAN의 요청을 대리 수행

. client의 요청내용을 캐싱함으로써 불필요한 요청 및 연결, 전송시간 절감 등의 이점이 있다.

reverse proxy server란?

.  proxy server와는 반대의 개념으로 client의 요청을 한대 이상의 server에 요청을 전달한다.

 - WAN -> LAN의 요청을 대리 수행

. reverse proxy 장비내에 있는 웹 service를 외부로 노추시키지 않는 장점이 있다.

Zero Trust Model이란?

. 말 그대로 믿지못하고 끊임없이 확인한다는 의미의 모델.

. 접근하려는 모든 것에 대한 접근권한을 부여하기 이전에 인증확인을 해야한다는 것.

 - 실제 사용자가 맞는지, 어떻게 접근을 요청했는지, 안전한 접근인지 등등

. 해당 model은 기존 레거시 시스템에는 적용하기가 다소 난해하다.

. 새로 구현하는 cloud service등에 적용하면 좋다.

. 관련 키워드 : OAuth

동기화 기법과 관련하여 Thread가 Lock이 걸리는 경우는 두가지가 존재한다.

Dead lock과 Live lock 두가지이다.

Dead lock [ Process 간에도 발생 가능. ]

 - Thread A가 A Resource를 획득 후 Thread B가 B Resource 를 획득.

 - 그 후 Thread A가 B Resource를 요청

 - 그 후 Thread B가 B Resource 해제를 하기전에 A Resource를 요청

 - 서로 물고 물리는 광계가 되며 Thread A, B 모두 Resource를 얻지 못한다.

 - 두 Thread가 Lock 경쟁을 하므로 다음 작업 진행 불가.

Live lock [ Process 간에도 발생 가능. ]

 -Thread A가 Resource A를 획득

 - Thread A가 Resource A를 획득한 후 시간이 오래걸리는 작업을 진행

 - 혹은 Thread A가 작업 종료 시 Resource A를 반환하지 않은 경우

 - Thread B가 Resource A에 대하여 요청을 한 후 계속 대기하는 경우가 발생한다.

Dead lock 방지

 - Resource의 할당과 해제순서를 잘 지킨다.

 - 주기적으로 Deadlock 상태를 확인한다.

Live lock 방지

 - Resource  점유에 대한 시간 제한을 둔다.

 - 가능한 임계영역을 작게 구성한다.

Single point of failure의 약자.

여러 요소 중 특정 system이 공장난 경우 전체 시스템이 멈춰버리는 경우를 의미

예

. Mobile Game의 경우 Mapping DB가 고장나 User의 계정 정보를 찾지 못하는 경우

. App 구동 시 version 확인을 못하여 Game 실행이 안되는 경우.

. Game Logic 중 무한 포문 혹은 dead lock에 걸리는 경우.

Dead reckoning이란?

1. 서버에서 특정 객체 혹은 Data에 대해서 과도하게 보내지 않게 하기 위한 방법

2. 주로 실시간 시뮬레이션이 요구되는 게임에 적용한다.

Dead Reckoning 예시

1. 간단한 물리 공식을 통한 위치 계산

 -> 현재 위치 = 이전 위치 + (속도 * 시간)

이해한 바로는 서버가 매 순간마다 특정 Data의 최신 정보를 보내서 갱신하는 것이 아니라

해당 Data가 따르는 혹은 속한 규칙을 통해 최신정보를 어느정도 유추함으로써 패킷 송수신을 줄이는 방법이다.

즉, 일종의 보간 기법을 서버에 적용하는 개념이다.

이 방법의 장점은 단순히 패킷수를 줄인다는 측면도 있지만 좀 더 자연스러운 시뮬레이션을 보여줄 수 있다는 것이다.

클라이언트는 특정 행동이나 키입력 패킷을 받은 후 시뮬레이션을 하며 추가 패킷을 받기전까지

지연없는 시뮬레이션을 수행할 수 있기때문에 패킷 손실등에서 발생할 수 있는 시뮬레이션 오차가 줄어든다.