실용주의 프로그래머(The Pragmatic Programmer) 챌린지 7일차 TIL

오늘 TIL 3줄 요약

- 동시성 / 병렬성

- 시간적 결합깨트리기 / 공유상태는 틀린 상태

- 액터, 프로세스, 그리고 칠판

TIL 날짜

- 2022-03-30

오늘읽은 범위

- 6장. 동시성

책에서 기억하고 싶은 내용

- 동시성(병행성) : 둘 이상의 코드 조각이 실행될때 동시에 실행 중인 것처럼 행동하는 것 (소프트웨어 동작 방식)

- 병렬성 : 실제로 동시에 실행되는 것 (하드웨어 동작 방식)

실제 세상은 비동기적이다

 

1. 시간적 결합 깨트리기

- 시간적 결합(temporal coupling) : 시간이나 순서에 의존하는 시간적 결합을 끊는 방법을 생각해 내야 한다.

동시성(동시에 일어나는 일들) / 순서(시간의 흐름 속에서 일들의 상대적인 위치)

활동 다이어그램 => 작업 흐름 분석으로 동시성을 개선하라

1. 동시에 수행가능한데도 동시에 하고있지 않을 활동들을 찾아내라

2. 우리 코드가 아닌 곳에서 시간이 걸리는 활동을 찾아내라

 

2. 공유 상태는 틀린 상태

- 모든 프로세스가 같은 메모리 영역에 쓰기가 가능하다 => 어느 프로세스도 자신이 보는 메모리가 일관되어 있음을 보장할 수 없다! (비-원자적 갱신)

 

원자적 갱신 방법

1. 세마포어(semaphore) : 한 번에 한 사람만이 가질 수 있는 무언가 / 리소스를 사용하기위한 조건으로 사용(lock, unlock)

- 문제점 : 진열장에 접근하는 모든 사람이 빠짐없이 세마포어를 사용해야 하므로 한 개발자가 사용하지 않고 구현하면 오류 발생 (리소스 사용을 보호할 책임을 사용자에게 전가)

2. 트랜잭션 (transaction) : 데이터베이스의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위 / 한번에 수행되어야하는 일련의 연산들

- 문제점 : 리소스 접근을 한곳으로 돌리긴 했지만 트랜잭션이 동시에 호출가능하므로 여전히 세마포어가 필요함

3. 뮤텍스 라이브러리 / Rust : 공유 리소스에 독점적으로 접근하는 것을 도와주는 라이브러리 및 언어

불규칙한 실패는 동시성 문제인 경우가 많다.

 

3. 액터와 프로세스

- 액터(actor) : 자신만의 비공개 지역 상태를 가진 독립적인 가상 처리 장치 / 우편함을 각자 하나씩 가지며, 휴면상태에 메시지가 도착하면 액터가 깨어나면서 메시지를 처리한다. 우편이 없으면 다시 휴면상태가 된다.

 

액터의 특징

1. 액터를 관리하는 것이 없다 : 실행 계획 X / 정보의 처리과정 조율 X

2. 시스템이 저장하는 상태는 메시지 / 각 액터의 지역 상태 뿐 : 메시지는 수신자가 읽는 것 외에는 확인 X, 지역상태는 액터 바깥에서 접근 X

3. 모든 메시지는 일방향 : 액터에서 답장을 받고 싶다면 처음 메시지를 보낼 때 답장받을 우편함 주소를 메시지에 포함해서 보내야 한다.

4. 한번에 하나의 메시지만 처리 : 각 메시지를 끝날 때까지 처리하고 중간에 다른일을 하지 않는다.

아무것도 공유하지 않고 비동기적으로 동시에 실행된다!

 

- 프로세스 : 더 일반적인 가상 처리기 / 운영 체제가 동시성을 지원하기 위하여 구현한다.

 

얼랭(Erlang)의 프로세스의 특징

1. 가볍다 : 한대의 컴퓨터에서 수백만개 실행가능

2. 프로세스끼리 메시지로 통신

3. 프로세스끼리 각각 격리되어 있어 상태 공유 X

4. 슈퍼비전(supervision)시스템 : 프로세스의 생애 주기를 관리 (프로세스 재시작 / 핫 코드 로딩)

 

동시에 실행되는 작업 구현 시 액터를 사용하라.

 

4. 칠판

칠판 접근 시스템 : 하나의 문제를 주제로 정하고, 그 주제에 대해 개별적으로 접근해 문제 해결에 기여하는 것

특징

1. 다른 기여자의 존재를 알 필요가 없다. 칠판에서 새 정보를 얻고, 알아낸 것을 추가한다.

2. 기여자는 저마다 다른 기능에 특화되어있으며, 서로 완전히 다른 종류일 수 있다.

3. 기여자의 참여 / 퇴장 / 작업 시간은 자유롭다.

4. 칠판에는 어느 정보든 올릴 수 있다.

자유방임주의적 동시성

 

- 린다 : 최초의 칠판 시스템

수집한 사실을 유형별 튜플로 저장 / 어플리케이션들이 새로운 튜플 작성 및 저장된 튜플을 패턴 매칭으로 조회

- 카프카(Kafka) / NATS : 메시징 시스템 but 이벤트로그의 형태로 영속성 제공 / 패턴 매칭 형태로 메시지 호출 지원

 

액터 / 칠판 / 마이크로서비스 : 비용이 많이 들고 맞춰야 하는 구성요소가 많아 배포하고 관리하기 까다롭다 하지만 시스템의 결합도를 줄여 ETC하다!

오늘 읽은 소감 / 떠오르는 생각

온라인 게임을 개발하고 있는 입장에서 가장 두려운 부분이 서버이다...ㅠㅠ

지금까지 구현했던 웹사이트들은 상호 작용이 아닌 단순 정보 게시에 그쳤기 때문에 동시성에 크게 무게를 두지 않았지만, 다대다 멀티 게임을 제작하다보니 서버를 어떻게 구현할지 걱정이 많았다. 오늘 내용을 통해 구체적인 방법은 아니지만 개념적으로 어떤방법이 좋을지 인사이트를 얻을 수 있었던 것 같다.

그리고 점점 앞부분에 나왔던 내용들이 연결되면서 책의 내용이 전체적으로 이해되기 시작한듯 하다!

궁금한 내용

258쪽의 "의사선생님, 이렇게하면 아파요. 그러면 그렇게 하지 마세요" 라는 예시가 어떤 의미인지 이해하지 못했다...

다른분들의 TIL을 읽어봐야겠다!