Page History
...
kotlin spring-boot-starter-webflux 템플릿으로 시작되었으며 akka 종속및 유닛테스트 종석은 다음을이용
의존성
| Code Block | ||
|---|---|---|
| ||
val scalaVersion = "2.13"
val akkaVersion = "2.7.0"
dependencies {
// Akka
implementation(platform("com.typesafe.akka:akka-bom_$scalaVersion:$akkaVersion"))
// Akka UnTyped Actor
implementation("com.typesafe.akka:akka-actor_$scalaVersion:$akkaVersion")
implementation("com.typesafe.akka:akka-stream_$scalaVersion:$akkaVersion")
// Akka Typed Actor
implementation("com.typesafe.akka:akka-actor-typed_$scalaVersion:$akkaVersion")
testImplementation("com.typesafe.akka:akka-actor-testkit-typed_$scalaVersion:$akkaVersion")
// Logging
implementation("ch.qos.logback:logback-classic:1.4.12")
implementation("com.typesafe.akka:akka-slf4j_$scalaVersion:$akkaVersion")
// TestToolKit
testImplementation("com.typesafe.akka:akka-testkit_$scalaVersion:$akkaVersion")
// JUnit
testImplementation("org.springframework.boot:spring-boot-starter-test")
testImplementation("io.projectreactor:reactor-test")
testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")
testRuntimeOnly("org.junit.platform:junit-platform-launcher")
testImplementation("org.junit.jupiter:junit-jupiter-api:5.9.3")
testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.9.3") } |
- AKKA 공식 버전은 위와같지만 2.6.x 포팅된 오픈소스인 pekko로 변환할수도있습니다.
현대 시스템에 새로운 프로그래밍 모델이 필요한 이유
액터 모델은 수십 년 전 Carl Hewitt 가 고성능 네트워크에서 병렬 처리를 처리하는 방법으로 제안했습니다. 당시에는 사용할 수 없었던 환경이었습니다. 오늘날 하드웨어 및 인프라 기능은 Hewitt의 비전을 따라잡고 능가했습니다. 결과적으로 까다로운 요구 사항이 있는 분산 시스템을 구축하는 조직은 기존의 객체 지향 프로그래밍(OOP) 모델로는 완전히 해결할 수 없는 문제에 직면하지만 액터 모델에서는 이점을 얻을 수 있습니다.
...
캡슐화의 과제¶
OOP의 핵심 기둥은 캡슐화 입니다 . 캡슐화는 객체의 내부 데이터가 외부에서 직접 접근할 수 없음을 지시합니다. 큐레이트된 메서드 집합을 호출하여서만 수정할 수 있습니다. 객체는 캡슐화된 데이터의 불변성을 보호하는 안전한 작업을 노출할 책임이 있습니다.
...
- 객체는 단일 스레드 액세스에 직면해서만 캡슐화(불변성 보호)를 보장할 수 있고, 멀티 스레드 실행은 거의 항상 손상된 내부 상태로 이어진다. 모든 불변성은 동일한 코드 세그먼트에 두 개의 경쟁 스레드가 있으면 위반될 수 있다.
- 잠금은 여러 스레드로 캡슐화를 유지하는 자연스러운 대책처럼 보이지만 실제로는 비효율적이며 실제 규모의 모든 애플리케이션에서 쉽게 교착 상태로 이어집니다.
- 잠금장치는 지역적으로 작동하며, 분산시키려는 시도도 있지만 확장 가능성이 제한적입니다.
현대 컴퓨터 아키텍처에서의 공유 메모리의 환상¶
80~90년대의 프로그래밍 모델은 변수에 쓰는 것이 메모리 위치에 직접 쓰는 것을 의미한다고 개념화했습니다(로컬 변수가 레지스터에만 존재할 수 있다는 사실을 다소 흐리게 만듭니다). 현대 아키텍처에서 - 사물을 조금 단순화하면 - CPU는 메모리에 직접 쓰는 대신 캐시 라인 에 씁니다 . 이러한 캐시의 대부분은 CPU 코어에 로컬합니다. 즉, 한 코어의 쓰기는 다른 코어에서 볼 수 없습니다. 로컬 변경 사항을 다른 코어, 그리고 다른 스레드에서 볼 수 있도록 하려면 캐시 라인을 다른 코어의 캐시로 전송해야 합니다.
...
- 더 이상 실제 공유 메모리는 없으며, CPU 코어는 네트워크의 컴퓨터가 하는 것처럼 데이터 덩어리(캐시 라인)를 서로에게 명시적으로 전달합니다. CPU 간 통신과 네트워크 통신은 많은 사람이 깨닫는 것보다 공통점이 많습니다. 메시지 전달은 이제 CPU나 네트워크 컴퓨터 간에 표준이 되었습니다.
- 공유로 표시된 변수를 사용하거나 원자적 데이터 구조를 사용하여 메시지 전달 측면을 숨기는 대신, 더욱 규율 있고 원칙적인 접근 방식은 상태를 동시 엔터티에 국한시키고 메시지를 통해 동시 엔터티 간에 데이터나 이벤트를 명시적으로 전파하는 것입니다.
호출 스택의 환상¶
오늘날 우리는 종종 호출 스택을 당연하게 여깁니다. 하지만, 호출 스택은 다중 CPU 시스템이 일반적이지 않았기 때문에 동시 프로그래밍이 그렇게 중요하지 않았던 시대에 발명되었습니다. 호출 스택은 스레드를 교차하지 않으므로 비동기 호출 체인을 모델링하지 않습니다.
...
다음으로, 액터 모델을 사용하여 이러한 과제를 어떻게 극복할 수 있는지 살펴보겠습니다.
Next :
AKKA 액터플랫폼을 활용하는 기업들
AKKA 액터모델이 국내활용 사례가 잘없어 인기있는것은 아니지만 리액티브 스트림이 활발한 글로벌 기업의 경우 많은 활용사례가 있습니다.
...