박철우의 블로그

이 글은 원 저자 Jakob Jenkov의 허가로 포스팅된 번역물이다.

원문 URL : http://tutorials.jenkov.com/java-concurrency/concurrency-models.html

 컨커런트 시스템들의 구현에는 각각 다른 컨커런시 모델이 사용될 수 있다. 컨커런시 모델은 다수의 쓰레드가 주어진 작업을 완료하기 위해 어떤 식으로 협력하는지를 명시한다. 컨커런시 모델들은 처리할 작업들을 각각 다른 방식으로 분배하고, 쓰레드들도 마찬가지로 다른 방식으로 소통하고 협력한다. 이 컨커런시 모델 튜토리얼은 이 시점에(2015년) 가장 널리 사용되는 컨커런시 모델들에 대해 다소 더 깊게 다룰 것이다.

컨커런시 모델과 분산 시스템의 유사성

 여기에 기술된 컨커런시 모델들은 분산 시스템에서 사용되는 아키텍처들과 유사하다. 컨커런트 시스템에서 각 쓰레드들은 서로 소통한다. 분산 시스템에서 각 프로세스들은 서로 소통한다(각각 다른 컴퓨터에서). 쓰레드와 프로세스는 사실상 상당히 닮아있고, 때문에 서로 다른 컨커런시 모델들이 분산 시스템 아키텍처들과 비슷하게 보이는 것이다.

물론 분산 시스템은 네트워크 장애나 원격 컴퓨터 혹은 프로세스의 다운 혹은 기타 여러가지 문제들로 인한 추가적인 부담을 가지고 있다. 하지만 큰 규모의 서버에서 돌아가는 컨커런트 시스템은 CPU의 장애, 네트워크 카드의 문제, 디스크의 문제나 기타 등등의 상황으로 비슷한 문제점을 경험하기도 한다. 이런 문제가 발생할 확률은 더 낮을 수도 있지만, 이론적으로 여전히 발생할 수 있다.

컨커런시 모델과 분산 시스템 아키텍처에는 유사한 점이 있기에, 이들은 종종 서로에게서 어떤 발상이나 방안을 차용할 수 있다. 예를 들자면, 워커 쓰레드들 사이의 작업 작업 분산에 대한 모델은 분산 시스템의 로드밸런싱 모델과 비슷하다. 로깅, 페일오버, 작업의 멱등성(idempotency) 혹은 기타 등등과 같은 에러 핸들링 기술에서도 마찬가지이다.

페러럴 워커

 첫번째 컨커런시 모델은 내가 페러럴 워커라 칭하는 모델이다. 요청 작업(incoming jobs)은 각각 다른 워커에 할당된다. 페러럴 워커 컨커런시 모델의 다이어그램은 다음과 같다.

페러럴 워커 컨커런시 모델에서 델리게이터는 요청 작업을 워커들에게 분배한다. 각 워커는 완전한 한 작업을 맡아서 완수한다. 워커들은 병행 처리로 수행되며, 각각 다른 쓰레드에서, 가능한대로 다른 CPU에서 작동된다.

만일 자동차 공장에서 페러럴 워커 모델이 구현된다면, 각 자동차 한 대에 하나의 워커가 할당되어 생산될 것이다. 워커는 자동차 생산을 위한 스펙을 가지며, 한 생산의 처음부터 끝까지 모두 처리하게 된다. 페러럴 워커 컨커런시 모델은 컨커런시 모델 자바 어플리케이션에서 가장 널리 사용된다(변화하고 있지만). 자바 패키지 java.util.concurrent 의 많은 컨커런시 유틸리티들이 이 모델로 구성되어 있다. 자바 엔터프라이즈 에디션 어플리케이션 서버의 디자인에서 이 모델의 구조를 추적해 볼 수 있다.

페러럴 워커의 강점

페러럴 워커 컨커런시 모델의 강점은 쉽다는 것이다. 병행 처리를 늘리기 위해 당신은 그저 워커를 추가하기만 하면 된다.

예를 들어, 당신이 웹 크롤러를 구현한다고 하면 당신은 다수의 워커를 이용해 페이지를 크롤링 할 수 있고, 어떤 워커의 크롤링 시간이 짧은지(성능이 뛰어난지) 알 수 있다. 데이터를 다운로드하는 시간동안 대기하는 시간이 길고, 때문에 CPU 당 하나의 쓰레드는 너무 적다. 웹 크롤링은 IO에 치중한 작업이기 때문에 다수의 쓰레드를 필요로 하며, 페러럴 워커 컨커런시 모델을 활용한다면 당신은 CPU / core 당 수 개의 쓰레드로 작업하게 될 것이다.

페러럴 워커의 약점

 페러럴 워커 컨커런시 모델에는 그 단순한 구조 아래 몇 가지 약점이 숨어있다. 여기서 가장 분명한 약점에 대해 설명한다.

공유 상태(shared state)는 복잡해진다.

현실적으로, 페러럴 워커 컨커런시 모델은 위의 일러스트보다는 다소 복잡하다. 공유된(shared) 워커는 공유된 데이터 - 메모리나 데이터베이스의 - 로 자주 접근할 필요가 있는데, 이것이 어떻게 페러럴 워커 컨커런시 모델을 복잡하게 만드는지 다음의 다이어그램이 보여준다. 

공유 상태는 작업 큐(queues)와 같은 통신 메카니즘 안에 있다. 공유 상태는 비지니스 데이터, 데이터 캐시, 데이터베이스 커넥션 풀이나 기타등등 이 될 수 있다. 페러럴 워커 컨커런시 모델 안에서 이 공유 상태는 복잡해지기 시작한다. 쓰레드들은 공유된 데이터에 접근할 때, 한 쓰레드가 데이터를 변경하면 다른 쓰레드들이 이 사실을 알 수 있도록 해야한다(데이터의 변경은 쓰레드를 실행하는 CPU 캐시에 묶여있지 않고 메인 메모리에 저장되어야 한다). 쓰레드는 경합 조건(race condition), 데드락 상태, 그리고 다른 많은 공유 상태 컨커런시의 문제점을 피해야 한다.

이에 더하여, 쓰레드가 공유 데이터 구조에 접근하기 위해 다른 쓰레드의 작업이 끝나기를 기다리는 동안 병행화 상태를 잃어버리게 된다. 하나 혹은 다수의 쓰레드 집단든 주어진 시간에만 데이터에 접근할 수 있는데, 이로 인해 많은 컨커런트 데이터 구조는 블록 상태에 놓인다. 이 현상은 공유 데이터 구조에 대한 경합을 불러온다.  높은 경합은 본질적으로 공유 데이터 구조에 접근하는 코드 실행의 serialization으로 이어진다.

요즘의 non-blocking 컨커런시 알고리즘은 경합을 줄이고 성능을 향상시키지만, non-blocking 알고리즘의 구현은 쉽지 않다. 이에 대한 또다른 대안은 지속형 데이터 구조이다. 지속형 데이터 구조는 데이터의 수정에 있어서 항상 자신의 이전 버전을 보존한다. 때문에 다수의 쓰레드가 같은 (지속형)데이터 구조를 가리키고 여기에 한 쓰레드가 데이터를 변경하는 상황이 되면 데이터를 변경하는 쓰레드는 변경된 새로운 데이터 구조를 참조하게 되고 나머지 쓰레드들은 변경 이전의 데이터 구조에의 참조를 유지하게 된다. 스칼라 프로그래밍은 여러가지 지속형 데이터 구조를 지니고 있다. 지속형 데이터 구조는 공유 데이터 구조에의 동시 접근에 대한 명쾌한 해결책이 되지만, 이 데이터 구조는 뜻대로 작동되지 않는 경향이 있다. 가령, 지속형 데이터 구조의 한 리스트 데이터에 새 데이터가 추가되면, 새 데이터는 리스트의 상단(head)에 오게 되고 이에 대한 레퍼런스를 반환한다(그리고 이 데이터는 나머지 리스트 데이터를 참조한다). 여기서 이 새 데이터에 대한 레퍼런스를 가진 쓰레드는 리스트에 데이터를 추가한 쓰레드이며, 나머지 쓰레드들은 앞서 설명했듯 데이터가 추가되기 이전의 리스트에서 첫번째 데이터를 참조한다. 이 쓰레드들은 리스트 데이터의 변경을 알 수 없으며 새로운 데이터를 볼 수 없다.

이런 지속형 데이터 리스트는 링크드 리스트로 구현된다. 유감스럽게도 링크드 리스트는 현대의 컴퓨터에서 제대로 작동하지 않는다. 데이터 리스트의 각 데이터는 각각의 객체이며, 이들은 컴퓨터 메모리 각지에 위치할 수 있다. 현대의 CPU는 순차적인 데이터 접근에 훨씬 빠르게 작동하는데, 때문에 현대의 하드웨어에서는 배열로 구현된 리스트에서 훨씬 나은 성능을 보인다. CPU 캐시는 더 큰 배열 덩어리들을 적재할 수 있으며, 캐시가 한 번 로드되면 이 데이터에 다이렉트로 접근할 수 있다. 메인 메모리에 산발적으로 적재되는 링크드 리스트로는 불가능한 방식이다.

비상태(stateless) 워커

 공유 상태는 시스템의 다른 쓰레드들에 의해 변경될 수 있다. 때문에 워커는 이에 접근할 때 최신 상태를 유지하기 위해 반드시 상태를 다시 읽는 작업이 필요하다. 워커는 이 상태를 자신의 내부에 유지하지 않기 때문에, 공유 상태가 메모리에 있는지 외부 데이터베이스에 있는지는 문제가 되지 않는다. 이를 비상태(stateless)라 부른다.

특히 외부 데이터베이스 환경에서, 필요할 때마다 데이터를 다시 읽는 작업은 성능 저하의 요인이 될 수 있다.

작업 순서의 비 결정성

 페러럴 워커 모델의 또다른 약점은 작업 실행 순서가 정해지지 않는다는 것이다. 어떤 작업이 먼저 실행될지 혹은 마지막에 실행될지 보장할 수 있는 방법은 없다. 작업 A 는 작업 B 보다 먼저 할당될 수 있고, 작업 B 는 작업 A 보다 먼저 실행될 수도 있다.

어셈블리 라인

 두 번째 컨커런시 모델은 어셈블리 라인 컨커런시 모델이다. 내가 이 이름을 택한 이유는 이 이름이 이전부터 '페러럴 워커' 의 비유에 어울렸기 때문이다. 혹자는 플렛폼이나 커뮤니티에 따라 이 모델을 반응형 시스템, 혹은 드리븐 시스템이라 부르기도 한다. 어셈블리 라인 컨커런시 모델의 다이어그램은 다음과 같다.

워커들은 공장의 조립 라인과 같이 놓인다. 이 모델에서 각 워커는 한 작업의 일정 부분만을 담당한다. 한 워커의 작업이 끝나면 워커는 작업을 다음 워커에게 전달한다.

각 워커는 각자 자신들의 쓰레드에서 작동하며, 다른 워커들과의 상태 공유는 발생하지 않는다. 이 모델은 '비공유' 컨커런시 모델으로 참조되기도 한다.

어셈블리 라인 컨커런시 모델을 이용하는 시스템은 주로 non-blocking IO 모델을 사용하기 위해 구현된다. non-blocking IO란 한 워커가 파일을 읽는다거나 네트워커 커넥션에서 데이터를 읽는 등과 같은 작업을 시작할 때 이 워커는 IO 호출이 끝나기를 기다리지 않는다는 것을 의미한다. IO 작업의 처리는 느리기 때문에 IO 작업이 끝나기를 기다리는 것은 CPU 시간을 낭비하는 일이다. CPU는 IO 작업이 처리될 동안 다른 작업을 수행할 수 있다. IO 작업이 끝나면, IO 작업 결과 - 읽어들인 데이터나 쓰여진 데이터 상태와 같은 - 를 다른 워커에게 전달한다.

non-blocking IO 에서 IO 작업은  워커들간의 작업 경계를 결정한다. 한 워커는 IO 작업이 시작될 때까지 가능한 모든 시간을 다른 작업에 쓰고, IO 작업을 시작해야 할 때가 되면 작업을 내려놓고 IO 작업을 수행한다. IO 작업이 끝나면 어셈블리 라인의 다음 순서에 있는 워커가 나머지 작업을 이전 워커와 같은 방식으로 처리하기 시작한다. 그리고 또 다음 IO 작업을 수행할 때가 되면 작업을 내려놓고 IO 작업을 수행한다.

이론적으로는 워커는 이런 방식으로 작동하는데, 실제로는 작업들은 단 하나의 어셈블리 라인에 놓이지는 않는다. 대부분의 시스템이 하나 이상의 작업을 수행하는 일이 가능하기 때문에, 작업들은 그 필요성에 따라 워커에서 워커로 흘러간다. 실제로 하나 이상의 가상 어셈블리 라인이 동시에 발생할 수 있다. 다음 다이어그램은 그 모습을 나타낸 것이다.

작업들은 동시 수행을 위해 하나 이상의 워커로 전달될 수도 있다. 예를 들어, 한 작업은 작업 실행자(executor)와 작업 로거(logger) 둘에게 전달되는 일이 가능한다. 다음 다이어그램이 이를 보여주는데, 세 어셈블리 라인이 하나의 같은 워커에게 작업을 전달한다.

어셈블리 라인은 이보다 복잡해질 수도 있다.

반응형, 이벤트 주도 시스템

어셈블리 라인 컨커런시 모델을 사용하는 시스템은 반응형 시스템, 혹은 이벤트 주도 시스템이라 불리기도 한다. 이 시스템의 워커들은 시스템에 발생하는 이벤트에 반응하는데, 시스템 밖에서부터 발생해 들어온 이벤트나 다른 워커로부터 발생한 이벤트에도 반응한다. 이벤트는 HTTP 요청이나 메모리로 로딩된 어떤 파일 또는 기타 등등일 수도 있다.

이 글을 쓰는동안, 몇가지 흥미로운 반응형/이벤트 주도 플렛폼이 등장하였다. 향후에는 더 많은 것들이 출현할 것이다. 유명한 몇가지는 다음과 같다.

• Vert.x

• Akka

• Node JS(Javascript)

개인적으로 Vert.x 가 매우 흥미롭다

액터 vs 체널

액터와 체널은 어셈블리 라인(혹은 반응형/이벤트 주도) 모델의 두 가지 비슷한 예이다.

액터 모델에서 각 워커는 액터(actor)라 불린다. 액터는 다른 액터들에게 직접 메세지를 보낼 수 있다. 메세지는 비동기적으로 처리된다. 액터들은 하나 혹은 하니 이상의 어셈블리 라인 작업 공정을 구현하기 위해 사용된다. 다음이 그 다이어그램이다.

채널 모델이서 워커는 다른 워커들과 직접 통신하지 않는다. 대신 워커는 메세지(이벤트)를 다른 채널으로 보낸다(publish). 다른 워커들은 채널을 통해 메세지를 수신하며, 메세지를 보낸 워커는 이 사실을 모른다. 이 모델의 다이어그램은 다음과 같다.

지금의(이 글을 쓰는 시점의)  채널 모델은 이보다 더 유연해졌다. 한 워커는 어셈블리 라인의 다른 워커들 중 어떤 워커가 작업을 수행할지 알 필요가 없다. 워커가 알아야 할 것은 단지 작업(혹은 메세지 또는 기타등등)을 어떤 채널로 보낼 것인가이다. 채널의 작업을 수신하는 워커들(listeners)은 채널로 작업을 보내는 워커에게 아무런 영향을 주지 않으면서 작업을 받거나 받지 않거나 할 수 있다. 이는 워커들간의 좀 더 약한 결합(a somewhat looser coupling)을 가능하게 한다.

어셈블리 라인의 강점

페러럴 워커 모델과 비교하여 어셈블리 라인 컨커런시 모델은 몇가지 강점이 있다. 여기 이 강점들을 소개한다.

공유 상태가 없다

 워커들간의 공유 상태가 없다는 사실은 공유 상태로의 동시 접근이 야기하는 동시성 문제점들을 생각할 필요가 없다는 것을 의미한다. 이것은 워커를 구현하기 훨씬 용이하게 한다. 당신은 마치 한 쓰레드로 작업하는 듯이 워커를 구현할 수 있다. - 기본적으로 싱글쓰레드 구현이다.

스테이트풀 워커

 워커는 다른 워커들이 자신의 데이터에 접근하지 않는다는 것을 알기에, 자신의 상태를 지속적으로 유지할 수 있다(stateful). 여기서 자신의 상태란, 워커가 자신의 작업을 위해 접근해야 하는 메모리상의 데이터를 의미한다. 오직 자신의 쓰기(writing) 작업만이 외부 저장소 시스템으로 데이터를 돌려보낼 수 있다. 때문에 스테이트풀 워커는 흔히 스테이트리스 워커보다 신속하게 작업을 처리할 수 있다.

더 나은 하드웨어 적합성

 싱글쓰레드 코드는 컴퓨터 내부의 하드웨어 워커들에 보다 적합하다는 이점이 있다. 첫째로, 당신은 보통 싱글쓰레드에서 코드를 실행할 때 더 최적화된 데이터 구조와 알고리즘을 만들 수 있다. 둘째로, 싱글쓰레드 스테이트풀 워커는 앞서 언급한대로 메모리에 데이터를 캐싱할 수 있다. 데이터가 메모리에 캐시될 때, 데이터는 쓰레드를 실행하는 CPU에 캐시될 확률이 더 높아진다. 이것은 캐시된 데이터로의 접근을 보다 빠르게 만든다.

나는 어떤 코드가 컴퓨터 내부의 하드웨어의 동작 방식으로부터 자연스럽게 이점을 얻을 때, 이를 하드웨어 적합성(hardware conformity)이라 부른다. 어떤 개발자들은 이를 mechanical sympathy 라 부르기도 한다. 나는 '하드웨어 적합성'이라는 말을 더 좋아하는데, 왜냐하면 컴퓨터에서 기계적인 부분은 매우 적고, 'sympathy' 라는 말은 이 문맥에서 'matching better'의 비유로 사용되기 때문이다. 'conform' 이라는 말이 의미를 더 잘 전달한다고 생각한다. 어쨌든, 이건 사소한 부분이고, 당신이 선호하는 용어를 쓰면 된다.

작업 순서를 정의할 수 있다.

 어셈블리 라인 컨커런시 모델에 따르면 작업 순서를 보장하는 컨커런트 시스템을 구현하는 일이 가능하다. 작업 순서를 정의하면 언제든지 지금 시스템의 작업 상태를 논리적으로 추정하는 일이 훨씬 쉬워진다. 뿐만 아니라, 워커로 들어오는 작업을 모두 기록할 수도 있다(logging). 이 기록은 어떤 케이스의 시스템 장애(system fails)에서든 시스템의 상태를 재건하는 일에 쓰일 수 있다. 작업들은 정확한 순서로 기록되며, 이 순서는 작업 순서의 보장으로 이어진다. 다음 다이어그램을 보자. 

보장된 작업 순서를 구현하는 일이 쉬운 것은 아니지만 가능한 일이다. 당신이 이를 구현한다면 백업, 데이터 재저장, 데이터 복재, 기타등등의 작업들이 놀라울 정도로 단순해진다. 이 모든 것은 로그 파일로 이루어질 수 있다.

어셈플리 라인의 약점

 어셈블리 라인 컨커런시 모델의 주요 약점은 작업 실행이 자주 다수의 워커에게로, 게다가 프로젝트의 클래스 파일들에게 분산된다는 점이다. 이 현상은 주어진 작업이 정확히 어떤 코드에서 실행되는지 보기 어렵게 만든다.

코드를 작성하기도 더 어려워질 수 있다. 워커 코드는 자주 콜백 핸들러로 작성되는데, 많은 중첩 콜백 핸들러가 작성된 코드는 개발자를 콜백 지옥에 빠뜨린다. 콜백 지옥은 쉽게 말해 수많은 콜백 중 어떤 코드가 실행되는지 추적하기 어려운 상황을 의미하는데, 이는 또한 각 콜백이 필요한 데이터로 확실히 접근하는지도 알기 어렵게 만든다.

이런 점들에서는 페러럴 워커 컨커런시 모델이 더 쉬운 경향이 있다. 당신은 워커 코드를 열고 실행되는 코드를 처음부터 끝까지 완전히 읽을 수 있다. 물론 페러럴 워커 코드 또한 많은 클래스들을 뒤덮을 수는 있지만, 그 실행 순서를 읽어내기는 더 쉽다.

함수형 병렬성

 함수형 병렬성은 요 근래(2015) 많이 언급되는 세 번째 컨커런시 모델이다.

항수형 병렬성의 기본적인 발상은 함수 호출을 이용해 프로그램을 구현하는 것이다. 마치 어셈블리 라인 컨커런시 모델에서와 같이, 각 함수들은 서로에게 메세지를 보내는 '대리인' 이나 '액터' 로 보일 수 있다. 한 함수가 다른 함수를 호출할 때, 이 동작은 메세지를 보내는 것과 유사하다.

함수로 전달된 모든 파라미터들은 복사되고, 때문에 파라미터를 전달받는 함수 밖에서 데이터를 접근할 수 있는 것은 없다. 이 이 복사는 본질적으로 공유 데이터에 대한 경합 조건을 피하기 위함이다. 이는 함수 실행을 원자적인 작업(atomic operation)과 유사하게 만든다. 각 함수 호출은 다른 함수 호출로부터 독립적으로 실행된다. 함수 호출이 독립적으로 이루어질 때, 각 함수는 독립적인 CPU 에서 실행된다. 이것은 함수형으로 구현된 알고리즘이 다수의 CPU에서 병렬적으로 실행될 수 있음을 의미한다.

자바 7 에서 우리는 java.util.concurrent 패키지를 얻었다. 이 패키지에는 ForkAndJoinPool 이 포함되어 있는데, 이것은 당신이 함수형 병렬성과 유사한 것을 구현하도록 해준다. 자바 8 에는 페러럴 스트림(streams)이 있는데, 이것은 당신이 거대한 컬렉션의 반복의 병렬 처리를 도와줄 수 있다.

ForkAndJoinPool 에 비판적인 개발자들이 있다는 사실을 기억하라. 함수형 병렬성의 어려운 부분은 어떤 함수가 병렬로 처리되는지 알기 어렵다는 점이다. 다수의 CPU에 걸친 조직화된 함수 호출은 오버헤드를 야기한다. 이 오버헤드를 위해 함수에 의해 수행되는 작업의 단위는 정확한 크기여야 한다. 매우 작은 함수 호출을 병렬로 처리하려 한다면 이 작업은 싱글 CPU의 싱글쓰레드 작업보다 느려질 수 있다.

내가 아는 바에 의하면, 당신은 반응형, 이벤트 주도형 모델을 이용해 알고리즘을 구현할 수 있고, 함수형 병렬성에 의한 것과 유사한 작성의 분해를 이뤄낼 수 있다. 이벤트 주도형 모델을 이용한다면 병렬 처리를 정확하게 컨트롤 할 수 있다(내 생각에). 더하여, 오버헤드를 발생시키며 다수의 CPU에 작업을 나누는 일은 오직 현재 시스템에서 그 하나의 task(그 작업을 실행하는 프로그램)만이 실행되고 있을 때만 타당한 것이다. 하지만 만약 이렇지 않고 그 task 외에 다른 task들이 시스템에서 실행되고 있다면(웹서버, 데이터베이스 서버 그리고 기타 등등 과 같은), 한 싱글 task를 병렬 처리하는 의미가 없다. 컴퓨터의 다른 CPU들은 어쨌든 다른 task의 작업을 위해 바쁘가 돌아가고 있기 때문에, 함수형 병렬 작업으로 그들을 방해할 이유가 없는 것이다. 당신에게 주로 도움이 될만한 것은 어셈블리 라인 컨커런시 모델이다. 왜냐하면 이 모델은 오버헤드를 줄여주고(싱글쓰레드로 순차적으로 실행되기에), 하드웨어의 작업과 조화롭게 작동하기 때문이다.

어떤 컨커런시 모델이 가장 좋을까?

그래서, 최고의 컨커런시 모델은 어떤 것일까?

흔히 있는 일이지만, 정답은 당신의 시스템이 어떤 일을 하느냐에 달렸다. 당신의 작업이 자연히 병렬 처리, 독립되고 공유 상태가 없는 쪽을 요구한다면, 당신은 페러럴 워커 모델을 이용할 수 있다. 많은 작업들이 자연스럽게 병렬 처리를 요구하지는 않고 또 독립적이지 않은데, 이런 종류의 시스템들에서는 어셈블리 라인 컨커런시 모델의 강점이 크다고 믿는다. 그리고 페러럴 워커보다 더 나을 것이다. 모든 어셈블리 라인 코드를 직접 작성할 필요는 없다. Vert.x 와 같은 플렛폼에 코드의 많은 부분이 구현되어 있다. 개인적으로 Vert.x 와 같은 플렛폼에서 돌아가는 디자인을 찾을 것이다. Java EE 는 더이상 우위에 있지 않다. 내가 보기에는.

이 글은 원 저자 Jakob Jenkov의 허가로 포스팅된 번역물이다.

원문 URL : http://tutorials.jenkov.com/java-concurrency/costs.html

이 글은 원 저자 Jakob Jenkov의 허가로 포스팅된 번역물이다.

원문 URL : http://tutorials.jenkov.com/java-concurrency/benefits.html

멀티쓰레딩이 그 위험요소에도 불구하고 여전히 사용되는 이유는 얻을 수 있는 장점이 있기 때문이다. 그 중 몇가지는 다음과 같다.

• 향상된 자원 활용성
• 상황에 따른 더 간단한 프로그램 디자인
• 프로그램의 반응성 향상

향상된 자원 활용성

로컬 파일 시스템의 파일을 읽고 처리하는 어플리케이션을 생각해보자. 디스크에서 파일을 읽는 데에 5초가 소요되고, 이를 처리하는 데에는 2초가 소요된다. 2개의 파일을 가공한다면 다음과 같은 시간이 소요된다.

  5 seconds reading file A
  2 seconds processing file A
  5 seconds reading file B
  2 seconds processing file B
-----------------------
 14 seconds total

읽기 작업에서는, 디스크가 데이터를 읽는 것을 기다리는 데에 CPU의 시간 대부분을 소모한다. 이 시간동안 CPU는 일하지 않는다. 이건 다른 것이 될 수 있다. 작업의 순서를 바꾼다면, CPU의 효율성은 더 나아질 수 있다.

  5 seconds reading file A
  5 seconds reading file B + 2 seconds processing file A
  2 seconds processing file B
-----------------------
 12 seconds total

CPU는 첫 번째 파일이 읽혀지길 기다린다음 두 번째 파일을 읽기 시작한다. 두 번쨰 파일이 읽혀지는 동안, CPU 프로세스들은 첫 번째 파일을 처리한다. 여기서, 디스크에서 파일이 읽히는 동안 CPU는 거의 놀고 있다는 점을 기억하라.

보통의 경우, CPU는 입출력을 기다리는 동안 다른 작업을 할 수 있는데, 이건 디스크 입출력 뿐만 아니라 네트워크 입출력 혹은 사용자의 입력의 경우도 마찬가지이다. 네트워크와 디스크 입출력은 CPU와 메모리 입출력보다 상당히 느리다.

상황에 따른 더 간단한 프로그램 디자인

 당신이 싱글쓰레드 어플리케이션에서 위와 같은 작업 순서로 읽기와 처리 작업을 직접 한다면, 각 파일에 대한 읽기/처리 작업 상태를 계속 파악하고 있어야 할 것이다. 한 파일에 대한 읽기/쓰기 작업을 두 개의 쓰레드에게 각각 맡긴다면, 이 쓰레드들은 디스크가 파일을 읽어올 때까지 블록 상태에 놓일 것이다. 이 디스크의 작업을 기다리는 동안, 다른 쓰레드들은 파일의 이미 읽혀진 부분들에 대한 처리 작업을 위해 CPU를 사용할 수 있다. 이 과정은 디스크가 파일을 읽어 메모리에 적재하기 위해 계속해서 가동되는(kept busy at all times) 결과를 낳는다. 이건 디스크과 CPU 모두에게 더 효율적인 운용 방법이 된다. 각 쓰레드는 한 파일에만 집중할 수 있기에, 이는 또한 프로그램에게도 더 쉬운 것이다.

프로그램의 반응성 향상

 싱글쓰레드를 멀티쓰레드로 바꾸는 또다른 목적은 어플리케이션의 더 나은 반응성을 위해서이다(to achieve a more responsive). 몇 포트로 사용자의 요청을 받는 서버 어플리케이션을 생각해보자. 하나의 요청이 오면 어플리케이션은 이를 처리하고 대기 상태로 돌아간다(listening). 이런 서버의 동작은 다음과 같다.

 
  while(server is active){
    listen for request
    process request
  }

한 요청이 처리되는 데에 긴 시간이 소요되면, 그동안 다른 새로운 클라이언트의 요청을 받을 수가 없다. 서버가 요청 대기상태여야만 클라이언트의 요청은 처리될 수 있다.

이를 대체할 수 있는 디자인은 요청 대기 쓰레드가 워커 쓰레드에게 요청을 맡기고 자신은 즉각 대기 상태로 돌아가는 형태가 될 수 있다. 워커 쓰레드는 요청을 처리하고 클라이언트에게 결과를 전송한다. 이 디자인은 다음과 같다.

  while(server is active){
    listen for request
    hand request to worker thread
  }

이 디자인에서 서버 쓰레드는 더 빠르게 대기 상태로 회귀할 것이고, 클라이언트들은 서버에게 요청을 보낼 수 있다. 서버의 반응성이 향상된 것이다.

데스크톱 어플리케이션의 경우도 같다. 당신의 클릭 버튼이 긴 작업 시간을 요구한다면, 그리고 이 작업의 쓰레드가 윈도우나 버튼을 업데이트하는 쓰레드라면, 어플리케이션은 이 작업 동안 반응할 수 없는 상태에 될 것이다. 여기서 이 작업이 워커 쓰레드로 전달된다면 워커 쓰레드가 작업을 처리하는 동안 윈도우 쓰레드는 유저의 요청을 받을 수 있다. 워커 쓰레드가 작업을 마치면 윈도우 쓰레드에게 신호를 보낸다. 윈도우 쓰레드는 어플리케이션 윈도우에 작업 결과를 업데이트한다. 워커 쓰레드가 존재하는 프로그램 디자인의 반응성은 보다 향상될 것이다.

이 글은 원 저자 Jakob Jenkov의 허가로 포스팅된 번역물이다.

원문 URL : http://tutorials.jenkov.com/java-concurrency/index.html

 오래전 컴퓨터는 단일 CPU로 가동되고 한번에 한 프로그램만 실행할 수 있었다. 후에 멀티태스킹이 가능한 컴퓨터가 출현하였고, 여러 프로그램(작업 or 프로세스)을 동시에 실행하는 일이 가능해졌다. 사실 이 멀티태스킹은 엄밀히 말하면 '동시에' 실행되는 것이 아니었다. 여러 프로그램이 하나의 CPU를 공유하였고, 오퍼레이팅 시스템이 프로그램들 사이에서 아주 짧은 시간을 두고 포커스를 전환(switching)하는 원리였다.

멀티태스킹의 출현은 소프트웨어 개발자들에게 새로운 과제를 주었다. 하나의 프로그램이 더이상 CPU의 시간과 메모리, 리소스를 독점할 수 없게 되었고, '좋은 프로그램(A "good citizen" program)'이란 다른 프로그램들이 CPU의 자원을 활용할 수 있도록, 사용한 자원을 해제할 수 있는 것이어야 한다. 

지금의 멀티태스킹은 다수의 쓰레드가 같은 프로그램 안에서 실행되는 것이다. 한 쓰레드의 실행은 한 CPU가 실행중인 하나의 프로그램이라 할 수 있다. 당신이 한 프로그램을 실행하는 멀티쓰레드를 가질 때, 이것은 마치 다수의 CPU가 하나의 프로그램을 실행하는 것과 같은 일이 된다.

 어떤 프로그램들에게 멀티쓰레딩은 성능 향상에 있어 훌륭한 방법이 된다. 그러나, 멀티쓰레딩은 멀티태스킹과 다르고, 더 어려운 일이기도 하다. 하나 이상의 쓰레드는 한 프로그램 안에서 실행될 수 있고, 이런 이유로 읽기와 쓰기 작업이 같은 메모리에 동시에 발생된다. 이 현상은 싱글쓰레드 프로그램에선 보지 못했던 에러를 뱉어낼 수 있다. 이러한 에러들 중 몇몇은 싱글 CPU 머신에서는 좀처럼 보이지 않는데, 왜냐하면 이런 경우에는 두개의 쓰레드가 '동시에' 실행되는 일은 절대로 일어나지 않기 때문이다. 요즘의 컴퓨터는 멀티코어 CPU를 가지고 나오며, 아예 CPU 자체가 두 개 이상인 것들도 존재한다. 이것이 의미하는 바는 별개의 쓰레드들이  별개의 코어 혹은 CPU에서 동시에 실행될 수 있다는 것이다.

만일 하나의 쓰레드가 어떤 하나의 메모리 영역을 읽는데 다른 쓰레드가 이 영역에 쓰기 작업을 한다면, 첫번째 쓰레드가 읽게 되는 값은 어떤 것일까? 쓰기 작업 이전의 값? 두번째 쓰레드가 쓰기 작업을 마치고 난 다음의 값? 두가지가 섞인 어떤 값? 아니면, 두 쓰레드가 동시에 한 메모리 영역에 쓰기 작업을 한다면? 이 작업 뒤에는 어떤 값이 남겨질까? 첫번째 쓰레드의 값? 두번째 쓰레드의 값? 두 값이 섞인 값?

적절한 예방책이 없다면 이런 상황은 얼마든지 가능하며, 그 결과는 예상할 수 없을 것이다. 이 결과는 때에 따라 바뀔 수 있는 것이다. 때문에 개발자가 적절한 예방책을 숙지하는 것은 중요한 일이다 - 적절한 예방책을 숙지하는 일이란, 메모리, 파일, 데이터베이스 기타 등등 과 같은 공유된 자원을 쓰레드가 어떻게 접근하는지 컨트롤하는 방법을 배우는 것이다. 이것이 이 자바 컨커런시 튜토리얼이 다루는 토픽 중 하나이다.

자바의 멀티쓰레딩과 컨커런시

 자바는 개발자가 멀티쓰레딩을 쉽게 사용할 수 있게끔 만들어진 초기의 언어들 중 하나였다. 자바는 애초부터 멀티쓰레딩 능력을 가지고 있었는데, 때문에 자바 개발자들은 위에서 설명한 문제점들을 자주 직면한다. 이것이 내가 이 자바 컨커런시 코스(trail)를 작성이는 이유이다. 내가 그랬던 것처럼, 자바 개발자라면 누구나 이 코스에서 도움을 받을 수 있다.

이 코스는 주로 자바에서의 멀티쓰레딩에 관하여 다룰 것이지만, 멀티쓰레딩에서의 문제점들 중 몇가지는 멀티태스킹이나 분산처리 시스템 환경에서 발생되는 문제점들과 비슷하다. 때문에 멀티태스킹과 분산처리 시스템에 대한 레퍼런스도 존재할 것이다. 이런 이유로 '멀티쓰레딩' 보다는 '컨커런시' 가 더 어울린다.

2015년, 그리고 이후의 자바 컨커런시

 자바 컨커런시 서적이 처음 쓰여지고 자바 5 컨커런시 유틸리티가 배포된 이래로 컨커런트 아키텍처의 세계에는 많은 일들이 있었다. Vert.x와 Play / Akka and Qbit 과 같은 새로운, 비동기적인 'shared-nothing' 플랫폼과 API들이 나왔다. 이 플랫폼들은 스탠다드 자바/JEE의 쓰레딩 컨커런시 모델과는 다른 컨커런시 모델을 사용한다. 새로운 non-blocking 컨커런시 알고리즘이 발표되었고, LMax Disrupter 와 같은 새로운 non-blocking 툴들이 우리의 툴킷에 추가되었다. Fork/Join 프레임워크와 함께 새로운 함수형 프로그래밍 병행 구조가 자바 7 과 자바 8 의 컬렉션 스트림 API에 소개되었다.

나는 이 모든 새로운 개발물들과 함께 이 컨커런시 튜토리얼을 업데이트한다. 그러니까, 이 튜토리얼은 진행중 에 있다. 새 튜토리얼은 시간이 허락될 때면 언제든 개재될 것이다.

 초기의 아스키는 각 문자를 7비트로 표현하여 총 128개의 문자를 처리할 수 있었다. 그리고 후에 추가적인 문자를 지원해야 할 필요가 있어 여기에 1비트를 추가한 확장 아스키(extended ASCII)가 등장한다. 8비트를 사용하는 이 확장 아스키는 256개의 문자를 표현할 수 있다. 처리해야 할 문자의 종류가 지금처럼 다양하지 않았던 시절, 문자 표현은 이 아스키만으로 충분했다. 오늘날의 글로벌 커뮤니케이션이 예상되지 않았던 시기의 일이다. 이 때는 영어, 아랍어, 중국어 등 다양한 언어가 한 문서에 존재하는 일은 흔치 않았다.

세상에는 수많은 종류의 언어를 사용하는 사람들이 존재하고, 이들 중 라틴계열 문자를 사용하지 않는 사용자는 거의 절반 이상이 될 것이다. 이렇게 다양한 사용자에 대응하는 소프트웨어를 개발하는 데 있어 오직 자신이 사용하는 언어만을 취급한다면 이는 사려깊지 못한 일이다.

이러한 이유로 모든 언어를 수용할 수 있는 문자셋의 필요성이 대두되어 탄생한 것이 유니코드이다. 유니코드는 모든 문자에 대해 각각의 유니크한 번호를 부여하였는데, 이를 코드 포인트라 한다. 유니코드의 이점 중 하나는 처음 256개의 코드는 ISO-8859-1 과 동일하다는 것이다. 고로, 이는 아스키와 동일하다. 그리고 널리 쓰이는 문자들 중 절대 다수의, 엄청나게 많은 문자들이 단 2바이트만으로 표현될 수 있다(Basic Multilingual Plane, BMP). 이제 문자셋에 접근하기 위해 필요한 인코딩에 대해 이야기한다. 여기서는 UTF-8, UTF-16 에 대해 다룰 것이다.

메모리 관련

어떤 종류의 문자가 얼마만큼의 바이트를 필요로 하는가

UTF-8:

1 바이트: 표준 아스키

2 바이트: 아랍, 히브리, 대부분의 유럽계(조지안 문자를 제외한)

3 바이트: BMP

4 바이트: 모든 유니코드 문자

UTF-16:

2 바이트: BMP

4 바이트: 모든 유니코드 문자

여기서 BMP 에 속하지 않은 문자들에는 고대 문자, 수학/음악 기호, 중국/일본/한국 문자 중 몇몇 드물게 보이는 문자들이 포함된다.

만약 대부분의 작업에 아스키 문자를 사용한다면 UTF-8은 메모리에 있어 확실히 더 나은 효율성을 제공한다. 그러나 비 유렵계 문자를 사용한다면, UTF-16 이 UTF-8보다 최대 1.5배 나은 메모리 효율성을 보인다. 이런 사항은 웹페이지나 큰 사이즈의 워드 문서와 같은 거대한 양의 텍스트를 처리할 때 성능에 영향을 줄 수 있다.

인코딩에 있어

UTF-8: 표준 아스키(0-127)와 UTF-8 코드는 완전히 동일하다. 이는 기존 아스키 텍스트의 호환성을 고려해야 할 때 UTF-8이 이상적으로 꼽히는 이유가 된다. 이 밖에 다른 문자들은 2-4 바이트를 필요로 한다. 이 문자들에 대한 처리는 각 바이트의 일부 비트를 예약하는 방법으로 수행되는데, 이는 멀티 바이트 문자의 일부임을 나타내기 위함이다. 특히 아스키 문자와의 충돌을 피하기 위해 각 바이트의 첫 번째 비트는 1이다.

UTF-16: UTF-16의 BMP 문자 표현법은 단순하게도 코드 포인트로 이루어진다. 이에 비해 BMP 외 문자에 대한 표현은 좀 더 복잡한데, 여기에는 surrogate pairs 라 불리는 방법을 이용한다. 유니코드의 2바이트 기본 범위(BMP) 영역을 넘어선 문자들을 Supplementary Characters 라 하는데, surrogate pairs는 이 문자들을 표현하기 위해 도입된 방법이다. surrogate pairs는 두 쌍의 2바이트를 이용하여 2바이트를 넘어서는 문자를 표현한다. 이 2바이트 코드는 BMP 범위에 포함되지만, 유니코드 표준에 의해 BMP 문자가 아님을 보장받는다. 그리고 UTF-16은 기본 단위를 2바이트로 가지기 때문에 엔디안의 영향을 받는다. 이를 보완하기 위해 엔디안을 나타내는 데이터 스트림의 시작부에 예약된 바이트 순서 마크가 위치한다. 고로 엔디안이 지정되어 있지 않은 UTF-16 입력을 읽을 때는 이를 확인할 필요가 있다.

이처럼 UTF-8과 UTF-16은 서로 호환되지 않는다. 입출력을 처리할 때는 어떤 인코딩을 사용하고 있는지 정확히 알 필요가 있다. 

프로그래밍에서의 고려사항

Character 와 String 데이터 타입: 사용하는 프로그래밍 언어에서 어떤 방식으로 인코딩을 하는지가 중요하다. raw 바이트를 비 아스키 문자로 출력하려고 한다면 문제가 발생할 수 있다. 또한 사용하는 문자 타입이 UTF 기반이라고 해도 이것이 알맞는 UTF 문자열을 보장해주지는 않는다. 문자열은 적합하지 않은 바이트 시퀀스를 허용할 수 있다. 일반적으로 이러한 처리에는 UTF를 제대로 지원하는 라이브러리가 사용된다. 어떤 경우든 입출력에 기본 인코딩이 아닌 다른 인코딩을 사용하려 한다면 먼저 컨버팅 작업을 수행하야 할 것이다.

권장되는 인코딩 방식: 어떤 UTF 방식을 사용할지 결정해야 할 경우에는 대부분 작업 환경의 표준을 따르는 것이 최선의 선택이 된다. 예를 들어, 웹 환경에서는 UTF-8이, 다른 자바 환경에서는 UTF-16이 권장된다.

라이브러리 지원: 사용중인 라이브러리가 어떤 인코딩을 지원하는가? 흔치 않는 경우에 발생하는 이슈에 대해서도 커버할 수 있는가? 1-3바이트 문자는 흔히 등장하기 때문에, UTF-8 라이브러리는 대부분 4바이트 문자를 정확하게 지원한다. 그러나 UTF-16을 지원한다고 알려진 모든 라이브러리가 surrogate pairs 를 제대로 지원하지는 않는다. (surrogate pairs가 등장하는 경우는 실제로 매우 드물기 때문이다)

문자 카운팅: 유니코드에는 결합 문자들이 존재한다. 예를 들어 코드 포인트 U+006E (n), U+0303(틸드 부호) 는 ñ을 표현한다. 그런데 코드 포인트 U+00F1 이 표현하는 것도 ñ 이다. 이들은 동일한 문자로 보이지만, 단순한 카운팅 알고리즘은 전자에 대해 2를 반환하고, 후자에 대해서는 1를 반환할 것이다. 이것은 잘못된 것이 아니다. 하지만 괜찮은 결과도 아닐 수 있다.

일치성 비교: A, А, Α. 이 A는 모두 같아 보인다. 그러나 앞에서부터 하나는 라틴, 하나는 키릴, 나머지 하나는 그리스 문자이다. 또 이런 경우도 있다. "C, Ⅽ". 하나는 문자이고 다른 하나는 로마 숫자이다. 이것들 외에도 위에서 언급한 결합 문자열 등 여러가지 고려사항이 있다.

Surrogate pairs: 위에서 언급했으므로 패스.