Swift의 분산된 Actor 소개

[kimscastle]

Tic Tac Fish

WWDC 세션 내내 Actor에 대해 이야기할 때 '동시성의 바다'라는 용어를 사용하는 것을 들을 수 있는데 Actor에 대해 생각할 때 아주 적절한 추상화라고 이야기합니다

각 Actor는 동시성의 바다에 독립적으로 존재하는 섬이고 서로의 섬에 직접 액세스하는 대신 서로 메시지를 주고받습니다 Swift에서는 섬끼리 이런 메시지를 보내는 행위가 비동기 메서드 호출 및 async/await로 구현됩니다
이는 Actor의 격리와 결합하여 Actor 기반 프로그램이 일단 컴파일되면 컴파일러가 낮은 수준의 data race에서 자유롭다는 사실을 보장하게 해줍니다

이러한 개념을 예제의 게임에 적용해보면 위와 같은 추상화를 할 수 있습니다
Swift Actor가 동시성 바다의 섬이라면 distributed Actor는 분산된 시스템의 광활한 바다에 있는 섬이라고 할 수 있죠 프로그래밍 모델에서 실제로 변한 것은 거의 없습니다 Actor는 여전히 상태를 격리하고 비동기식 메시지를 사용해야만 소통할 수 있습니다 같은 프로세스에 더 많은 distributed Actor를 참여시킬 수도 있습니다

distributed Actor와 상호 작용하는 방법을 바꾸지 않고도 잠재적으로 멀리 있을 수 있는 능력을 '위치 투명성'이라고 합니다 이는 distributed Actor가 어디에 있든 간에 동일한 방식으로 Actor와 상호 작용이 가능함을 의미합니다

사용자가 GameCell을 클릭하면 플레이어 Actor에게 동작을 생성하고 UI를 구동하는 뷰 모델을 업데이트하도록 요청합니다
이런 모든 업데이트는 스레드 안전하며 제대로 작동하죠(Actor로 구성되어있으며 해당함수가 await으로 실행)

offline player

각 팀에는 각 움직임에 대해 선택할 수 있는 이모티콘이 여러 개 있으므로 움직임 번호를 사용하여 이모티콘 문자 ID를 선택합니다 또한 일단 움직임이 생성되면 모델을 업데이트해야 합니다 이 모델은 MainActor에서 격리된 클래스이므로 이 모델의 변형은 스레드 안전합니다

사용자 MadeMove를 호출할 때는 'await'를 사용해야 합니다 마지막으로 오프라인 플레이어도 적이 움직일 때마다 호출되는 메서드를 선언합니다 여기서 해야 할 일은 뷰 모델의 업데이트입니다 그러면 게임 필드가 다시 활성화되어 인간 플레이어가 자신의 움직임을 선택할 수 있고 게임이 끝날 때까지 주기가 계속됩니다

botplayer

뷰 모델 업데이트에 대해 걱정할 필요가 없기 때문에 그냥 GameState를 추적하고 게임 움직임만 생성하죠 봇 플레이어가 좀 더 간단하기 때문에 분산 행위자로 변환을 시작하기에 좋습니다

Play with a remote AI

Tic Tac Fish 게임의 첫 번째 단계는 BotPlayer 유형을 분산 행위자로 변환하면서 동시에 여전히 로컬로만 사용하는 것입니다

BotPlayer 행위자 선언 앞에 분산 키워드를 추가할 수 있습니다 이렇게 하면 행위자가 DistributedActor 프로토콜을 자동으로 준수하게 되며 여러 가지 추가 컴파일 시간 검사를 활성화하죠 이제 컴파일러가 어떤 오류를 수정하라고 할지 알아보겠습니다 컴파일러는 BotPlayer가 사용할 수 있는 ActorSystem을 선언하지 않는다고 우리에게 알려 줍니다

모듈 전체 DefaultDistributedActorSystem typealias를 선언하거나 특정 행위자의 본문에 있는 ActorSystem typealias를 선언하여 사용할 행위자 시스템에 대해 컴파일러에 말할 수 있습니다 후자가 더 구체적이니까 이 방법을 선택합니다

분산 메서드 호출은 네트워크 경계를 넘을 수 있으므로 모든 매개 변수와 반환 값이 행위자 시스템의 직렬화 요구 사항을 준수하는지 확인해야 합니다 우리의 경우, 행위자 시스템은 Swift의 기본 직렬화 메커니즘인 Codable을 사용하고 있습니다 컴파일러는 구체적으로 다음과 같이 말합니다 ‘결과 유형 GameMove가 직렬화 요구 사항 ‘Codable을 준수하지 않습니다’

using websocket

여기서 사용할 수 있는 WebSocket 기반 샘플 행위자 시스템을 이미 준비해 뒀습니다 이 행위자 시스템을 활용하면 봇 플레이어를 서버 측 Swift 응용 프로그램으로 이동하여 모바일 게임에서 원격 참조를 분석할 수 있습니다 행위자의 경우 선언된 행위자 시스템만 LocalTesting DistributedActor 시스템에서 샘플 앱을 위해 준비했던 SampleWebSocketActorSystem으로 바꾸면 됩니다 나머지 행위자 코드는 그대로 유지됩니다

서버 측 Swift 응용 프로그램으로 이동해서 준비한 샘플 WebSocket 행위자 시스템 덕분에 매우 쉽게 구현할 수 있습니다 첫째, WebSocket 행위자 시스템을 서버 모드로 생성하여 포트에 연결하는 대신 시스템을 바인딩하고 포트를 수신합니다

일반적으로 행위자 시스템은 수신 메시지를 수신하고 로컬 분산 행위자 인스턴스를 찾기 위해 수신자 ID를 분석하려고 시도합니다 그런 다음 배치된 행위자에서 원격 호출을 실행합니다 하지만 우리가 방금 논의했듯이 우리의 봇 플레이어 ID는 사실상 꾸며냈기 때문에 시스템은 그들에 대해 알 수 없을 뿐만 아니라 스스로 올바른 유형의 행위자를 만들 가능성도 낮습니다

기존 행위자를 찾는 데 실패하면 resolveCreateOnDemand를 시도합니다 ID를 구성하는 클라이언트 코드와 서버 코드의 일부를 모두 관리하고 있기 때문에 온디맨드로 필요한 행위자를 만들어 행위자 시스템을 지원할 수 있습니다 클라이언트에서 구성한 봇 식별자는 ActorIdentity에 태그를 추가하거나 일부 인식 가능한 이름을 사용하는 등 인식 가능한 이름 지정 체계를 사용하므로 이러한 ID를 탐지하여 아직 활성화되지 않은 모든 메시지에 대해 새 봇 상대를 만들 수 있습니다

서버 구현이 완료되었으며 이제 원격 봇 플레이어로 게임을 즐길 수 있습니다 Swift run을 사용하여 명령줄에서 서버를 실행하거나 Xcode를 사용하고 서버 스킴을 선택한 다음 평소처럼 실행을 클릭하여 서버를 실행할 수도 있습니다

멀티플레이어 환경을 구축

로컬 네트워크에 접속하면 매우 민감한 개인 정보가 노출될 수 있으므로 주의하여 사용하시기 바랍니다 이번에는 이미 다른 기기에 분산되어 있는 행위자를 다루게 되므로 이제 더 이상 이전 예제에서처럼 ID만 구성할 수는 없습니다 같이 게임을 하고자 하는 다른 기기에서 특정 행위자를 찾아야 합니다 이 문제는 분산 행위자에게만 해당하는 문제는 아니며 일반적으로 서비스 검색 메커니즘을 사용하여 해결됩니다

그러나 분산 행위자의 도메인에는 코드 전체에 걸쳐 강력한 API 유형을 고수할 수 있게 해주는 API 행위자 시스템의 공통적인 패턴과 스타일이 있습니다 이를 리셉션 패턴이라고 부릅니다 호텔과 비슷하게 행위자도 알려지고 남들과 만나려면 체크인을 해야 하기 때문이죠

SampleLocalNetworkActorSystem을 위해 제가 구현한 간단한 리셉셔니스트를 살펴보겠습니다 분산 행위자 시스템의 모든 리셉셔니스트가 행위자를 발견할 수 있도록 행위자의 체크인을 지원하는 기능이죠 이어서 특정 유형의 모든 행위자 목록을 얻고 그들이 해당 시스템에서 사용 가능해지면 태그를 지정할 수 있습니다

인간 사용자가 필드 중 하나를 클릭할 때 트리거되는 @published 값으로 제공됩니다 인간 플레이어가 필드를 클릭하면 makeMove 함수가 재개되고 우리는 실행된 GameMove를 원격 호출자에게 반환하여 원격 호출을 완료합니다