[ray] Ray Core의 Lock Contention 해결: Publisher의 비동기 처리 도입

PR 링크: ray-project/ray#63983 상태: Merged | 변경: +214 / -10

들어가며

Ray Data의 워크로드에서 스케줄링 루프가 심각한 Lock Contention을 겪고 있다는 사실이 프로파일링을 통해 확인되었습니다. 특히 Publish 관련 락이 전체 스케줄링 시간의 약 17.4%를 점유하고 있었는데, 이는 Python 스레드에서 직접 Pubsub 로직을 호출하면서 발생하는 병목이었습니다. 본 PR은 이 문제를 해결하기 위해 PublisherInterface를 데코레이터 패턴으로 감싸, 모든 Pubsub 작업을 C++ IO 스레드로 위임(Offload)하는 최적화를 수행합니다.

코드 분석

1. PostingPublisher 도입 (src/ray/pubsub/posting_publisher.h)

핵심 변경 사항은 PostingPublisher 클래스의 도입입니다. 기존의 동기식 호출을 io_service_.post를 통해 비동기 작업으로 전환했습니다.

// Before: 직접 호출 (동기)
// After: PostingPublisher를 통한 비동기 post
void Publish(rpc::PubMessage pub_message) override {
  const auto channel_type = pub_message.channel_type();
  io_service_.post(
      [inner = inner_, pub_message = std::move(pub_message)]() mutable {
        inner->Publish(std::move(pub_message));
      },
      PublishEventName(channel_type));
}

이 구조는 PublisherInterface를 구현하는 데코레이터 패턴을 사용하여, 기존 Publisher 로직을 수정하지 않고도 호출 스레드를 분리할 수 있게 합니다.

2. CoreWorkerProcess에서의 적용 (src/ray/core_worker/core_worker_process.cc)

CoreWorker가 생성될 때 기존의 Publisher 대신 PostingPublisher를 사용하도록 변경되었습니다.

// Before
auto object_info_publisher = std::make_unique<pubsub::Publisher>(...);

// After
auto object_info_publisher = std::make_unique<pubsub::PostingPublisher>(
    std::make_shared<pubsub::Publisher>(...), io_service_);

왜 이게 좋은가

성능 개선 수치

worker_scaling_5000_actors 테스트 결과, 스케줄링 스레드의 락 대기 시간이 15.7%에서 7.8%로 약 50% 감소했습니다. 또한, ActorTaskSubmitter::SubmitTask의 큐 대기 시간도 16% 개선되는 등 전반적인 시스템 응답성이 향상되었습니다.

교훈

1. Lock Contention의 분리: 고빈도 호출이 발생하는 Pubsub 로직을 메인 스레드에서 분리하여 IO 스레드로 넘기는 것만으로도 메인 루프의 병목을 크게 완화할 수 있습니다.
2. 데코레이터 패턴의 활용: 기존 비즈니스 로직을 건드리지 않고 PublisherInterface를 래핑하여 비동기성을 주입하는 방식은 유지보수성과 확장성 측면에서 매우 우수합니다.
3. 테스트의 중요성: 리뷰 과정에서 논의되었듯, 단순히 성능만 개선하는 것이 아니라 ObjectLostError와 같은 엣지 케이스를 재현하는 테스트를 추가함으로써 시스템의 안정성을 보장하는 것이 필수적입니다.

리뷰어 피드백 분석

리뷰어 edoakes는 특정 함수만 비동기로 처리하는 대신, Publisher 전체를 래핑하여 일관된 비동기 인터페이스를 제공할 것을 제안했습니다. 이는 향후 Pubsub 로직을 별도 스레드로 완전히 분리하려는 장기적인 로드맵과도 일치하며, 코드의 복잡도를 낮추는 좋은 설계 결정이었습니다.

참고 자료

• https://pytorch.org/docs/stable/generated/torch.compile.html
• https://github.com/ray-project/ray

⚠️ 알림: 이 분석은 AI가 실제 코드 diff를 기반으로 작성했습니다.