【ITニュース解説】Actors in Go: How lockstep Runs One Actor in Your Program and in Tests

Go言語は、goroutine（軽量なスレッドのようなもの）とchannel（goroutine間の通信路）を使って並行処理を簡単に記述できる強力な機能を持つ。しかし、これらの基本的なツールだけでは、複雑な並行アプリケーションを開発する際にいくつかの課題に直面する。例えば、複数のgoroutineが同じデータにアクセスする際のデータの所有権、channelがメッセージでいっぱいになったときの挙動、予期せぬエラー（パニック）でgoroutineが停止したときの再起動方法、そして最も重要なのが、これらの複雑なシステムのテスト方法である。

このような課題を解決するアプローチの一つが「Actorモデル」であり、「lockstep」はGo言語でこのActorモデルを実現するためのフレームワークである。lockstepを使うと、開発者は「Actor」と呼ばれる独立したコンポーネントを作成し、goroutineとchannelを直接意識することなく、より安全でテストしやすい並行システムを構築できる。lockstepのバージョン0.2.0が2026年11月1日にリリースされた。

lockstepのActorは、型付けされたメッセージ、容量制限のあるメールボックス、Actorの監視機能、タイマーといった要素を持つ。Actorは、アプリケーション内でワーカーgoroutineのプール上で実行される。さらに、同じActorのコードをテスト環境でも動かすことができ、そこでは独自の仮想時計やネットワークを持つシミュレーション環境で実行される。このシミュレーションでは「シード値」という一つの数字が、メッセージが処理される全ての順序を決定する。これにより、テストの再現性が極めて高くなる。

具体的な例として、在庫が一つだけあるお店をActorとして実装してみる。この「お店」Actorは、在庫数というデータを自身で管理し、購入リクエスト（Buyメッセージ）や販売数の問い合わせ（Soldメッセージ）を受け付ける。Actorは一度に一つのメッセージしか処理しないため、在庫数を変更する際に、複数のgoroutineが同時にデータにアクセスすることによって発生する競合を防ぐための「排他ロック」のような複雑な仕組みは不要になる。実際のお店が商品を渡す前に支払いを行うように、このお店Actorも、支払い処理を開始する前に商品を在庫から減らす（予約する）ことで、たとえ複数の購入リクエストが同時に来ても、同じ商品が二重に販売されることを防ぐ。

Actorがネットワーク通信のような時間のかかる処理を直接行うと、Actorがブロックされてしまい、その間メールボックスに溜まったメッセージが処理されなくなる。これを避けるため、lockstepでは「エフェクト」という仕組みを提供する。例えば、カード決済のような外部サービスとの連携はlockstep.Doという関数を使ってエフェクトとして開始する。lockstep.Doはすぐに制御を返し、Actorはブロックされない。支払いプロバイダからの応答があった後、その結果は再びActorへのメッセージとして届けられ、Actorは後続のターンでそのメッセージを処理する。

このエフェクトの仕組みにより、Actorのコードには厳格なルールが課される。Actorは、メッセージ処理中にブロックしてはならない、goroutineを直接起動してはならない、システムの時間（壁時計）を直接参照してはならない、グローバルな乱数を使ってはならない、といったルールである。時間や乱数、I/Oは全てlockstepランタイムを通して行われる。これにより、ランタイムがそれら全てを制御できるため、後述するシミュレーション環境でそれらを異なる形で再現できるようになる。lockstep-vetというGoのコードアナライザは、これらのルールが守られているかを自動的にチェックし、違反があれば警告する。

アプリケーション内でlockstepを使用する場合、lockstep.New()でActorを実行するエンジンを起動し、lockstep.SpawnでActorを生成する。メッセージの送信にはlockstep.Sendを使い、返信が必要な場合はlockstep.Askを使って返信を待つ。アプリケーションの実行中、Actorのメッセージ処理（ターン）は、デフォルトでCPUのコア数に応じて設定されたワーカーgoroutineのプールで並行して実行される。ただし、一つのActorに対するターンは決して重ならないため、データの整合性が保たれる。

lockstepの真価は、その強力なテスト機能にある。sim.Simulateを使うことで、テストコードを「シード値」ごとに何回も実行できる。それぞれの実行は、まっさらなシミュレーション環境で行われる。シミュレーション環境では、時間は仮想的に進み、ネットワーク遅延もシード値によって決定される。実際の支払いAPIのような外部サービスへの呼び出しは、s.HandleEffectで登録されたテスト用のハンドラによって模擬される。これにより、現実世界で起こりうる様々なメッセージの到達順序や遅延パターンをシード値を変えるだけで網羅的にテストでき、本番環境でしか発見しにくいような複雑なバグも事前に見つけ出すことが可能になる。テスト中に特定のシード値で問題が発生した場合、そのシード値を使って同じ実行を正確に再現できるため、デバッグも容易になる。

Actorが管理するデータは通常メモリ上に保持されるため、アプリケーションが再起動すると失われる。重要なデータを永続化する必要がある場合、lockstepはlockstep/persistパッケージで「永続Actor」の機能を提供する。これは「イベントソーシング」という手法に基づいている。Actorの状態変更を直接行うのではなく、Handleメソッドで「イベント」を生成し、そのイベントをApplyメソッドで現在の状態に適用する。lockstepはこれらのイベントをジャーナル（ログ）に書き込み、それがディスクに永続化されてから状態を更新する。これにより、システムが再起動しても、ジャーナルに記録されたイベントを読み込み、それらを順番に適用することで、以前の状態を正確に復元できる。テスト環境でも、シミュレートされたディスク上でこの永続化の動作を確認できる。

lockstepは、メッセージの順序や障害発生時の挙動の正確性が極めて重要となるシステム、例えば分散合意、データレプリケーション、金融台帳、在庫管理システムといった分野で特に役立つ。また、リトライやフェイルオーバーが必要なサービス、長期間にわたって状態を保持する多数のワーカーを持つワークフローにも適している。一方で、多数のコアから同時に単一のデータを頻繁に更新する必要があるようなケースには向かない。Actorはメッセージを一つずつ順次処理するため、同時更新にはオーバーヘッドが生じるからである。また、状態を持たない単純なリクエスト・レスポンスサービスでは、Actorモデルの導入自体が過剰な複雑さをもたらす可能性がある。現在のlockstepは、一つのプログラムプロセス内で動作し、異なるマシン間での通信（リモート処理やクラスタリング）はサポートされていない点にも留意が必要である。

lockstepはGo 1.26以降で利用可能であり、go get github.com/hmdsefi/lockstep@v0.2.0コマンドで導入できる。このフレームワークは、Go言語で堅牢でテストしやすい並行アプリケーションを構築するための強力な選択肢となるだろう。