멀티 서비스 구조의 개념
멀티 서비스 구조는 여러 개의 서비스 서버와 클라이언트를 통해 다양한 요청과 응답을 동시에 처리하는 구조를 의미한다. ROS2에서는 서비스 통신 방식이 비동기로 동작하며, 여러 서비스가 병렬로 실행될 수 있도록 설계된다. 이 구조는 다중 서비스 요청을 효율적으로 처리할 수 있게 해주며, 분산 시스템에서 특히 유용하다.
멀티 서비스 구조에서는 각 서비스가 독립적으로 정의되고, 이를 여러 노드가 각각 클라이언트로서 요청하거나 서버로서 응답할 수 있다. 이로 인해 복잡한 로봇 시스템에서 여러 모듈이 상호작용하며 동작할 수 있다.
설계 원칙
멀티 서비스 구조 설계를 위해 다음과 같은 설계 원칙이 필요하다.
1. 서비스 정의의 일관성
여러 서비스가 서로 상호작용할 때, 서비스 메시지 형식이 일관성을 유지해야 한다. ROS2에서는 각 서비스마다 요청(Request)과 응답(Response) 메시지를 정의하는데, 이 메시지 구조는 서비스 간 데이터 교환을 용이하게 만들어야 한다.
예를 들어, 두 개의 서비스가 서로 다른 형식의 응답 메시지를 사용하면, 이를 연계하는 노드는 각 서비스에 맞는 변환 작업을 추가로 수행해야 한다. 이러한 비효율성을 줄이기 위해서는 데이터 구조를 미리 정의하고 일관된 포맷을 유지하는 것이 중요하다.
2. 병렬 처리와 서비스 큐 관리
ROS2의 서비스는 비동기적으로 요청과 응답을 처리할 수 있으므로, 여러 클라이언트에서 동시다발적으로 요청이 들어오더라도 서버에서 이를 병렬로 처리할 수 있는 구조를 마련해야 한다. 이때 중요한 것은 각 서비스가 요청을 처리하는 순서를 관리하는 것이다.
일반적으로 서비스는 큐를 사용하여 요청이 들어온 순서대로 처리된다. 병렬 처리가 필요한 경우 스레드 풀(Thread Pool)을 활용하여 동시에 여러 요청을 처리할 수 있다.
3. 타임아웃 처리
멀티 서비스 구조에서 중요한 또 다른 개념은 서비스 요청에 대한 타임아웃 설정이다. 각 서비스는 네트워크 지연, 처리 시간 초과 등의 이유로 응답을 제때 제공하지 못할 수 있다. 따라서 클라이언트에서는 각 서비스 호출에 타임아웃을 설정하여, 일정 시간이 지난 후에도 응답이 없으면 예외 처리를 해야 한다.
타임아웃 설정을 통해 특정 서비스가 응답하지 않을 경우, 다른 백업 서비스로 전환하거나 로컬에서 처리하는 방식 등을 고려할 수 있다.
4. 부하 분산
다수의 서비스가 동시에 요청을 받는 상황에서, 특정 서비스가 과도하게 많은 요청을 처리하게 되는 경우 부하 분산 전략을 사용하여 시스템 성능을 최적화할 수 있다. 부하 분산 전략에는 요청을 여러 서비스 서버로 분산하거나, 요청이 많을 때 새로운 서버 인스턴스를 동적으로 생성하는 방식이 있다.
부하 분산을 효과적으로 구현하려면 각 서비스의 요청 수와 처리 시간을 모니터링하고, 부하가 일정 수준을 초과하는 시점에 자동으로 새로운 서버를 추가하는 방식이 필요하다.
5. 서비스의 종속성 관리
멀티 서비스 구조에서 서비스 간의 종속성을 관리하는 것이 매우 중요하다. 특정 서비스가 다른 서비스의 결과를 기반으로 동작해야 할 경우, 서비스 간의 종속성이 발생하게 된다. 이러한 종속성을 관리하지 않으면, 서비스 간 교착 상태나 처리 순서의 문제로 인해 시스템이 불안정해질 수 있다.
예시: 두 서비스 간의 종속성
- 서비스 A는 센서 데이터를 처리하고, 서비스 B는 서비스 A에서 처리된 데이터를 받아 추가적인 계산을 수행해야 한다고 가정하자. 이때 서비스 B는 서비스 A가 완료된 후에만 정상적으로 동작할 수 있다. 이러한 구조에서는 서비스 A의 응답이 정상적으로 완료되었는지 확인하고, 그 결과를 서비스 B로 전달하는 로직이 필요하다.
이런 상황에서는 서비스 호출이 완료되기 전에 다른 서비스가 작동하지 않도록 요청을 적절히 순서대로 처리하거나, 특정 서비스가 응답하지 않을 경우 대체 서비스를 호출할 수 있는 방법을 마련해야 한다.
종속성 관리 전략
서비스 간의 종속성 문제를 해결하기 위한 몇 가지 전략을 고려할 수 있다.
- 비동기 호출과 콜백: 비동기 호출과 콜백을 통해 서비스 A가 완료된 후에만 서비스 B를 호출하도록 설정할 수 있다.
- 결과 캐싱: 서비스 A의 결과가 자주 변경되지 않는다면, 그 결과를 캐싱하여 서비스 B가 바로 사용할 수 있게 한다.
- 에러 처리 및 예외 대응: 서비스 A가 실패했을 때의 대체 서비스 호출이나 예외 상황에 대한 대응 로직을 마련한다.
6. 상태 관리와 모니터링
멀티 서비스 구조에서 각 서비스의 상태를 실시간으로 모니터링하는 것이 필요하다. 서비스가 비정상적으로 종료되거나, 오랜 시간 동안 응답하지 않는 경우 이를 감지하여 즉각적인 대응이 가능하도록 해야 한다. 이를 위해 상태 모니터링 시스템을 구축하여 서비스의 동작 상태를 지속적으로 확인할 수 있는 시스템이 필요하다.
서비스 상태 모니터링
ROS2에서 서비스 상태를 모니터링하기 위해 사용할 수 있는 도구로는 ros2 service 명령어가 있다. 이 명령어를 통해 현재 활성화된 서비스 목록과 해당 서비스의 상태를 실시간으로 확인할 수 있다. 또한, 서비스가 특정 조건을 만족하지 않거나 오류가 발생한 경우 알림을 받도록 설정할 수 있다.
# 활성화된 서비스 확인
ros2 service list
서비스 상태를 표현한 다이어그램
7. 서비스 호출 패턴
멀티 서비스 구조에서 중요한 또 하나의 요소는 서비스 호출 패턴이다. 각 서비스는 서로 독립적으로 동작할 수 있지만, 시스템의 요구 사항에 따라 다양한 호출 패턴을 사용할 수 있다.
1. 동기 호출
동기 호출은 클라이언트가 서비스 요청을 보내고, 그 응답이 도착할 때까지 대기하는 방식이다. 이 방식은 처리 결과가 바로 필요할 때 유용하지만, 서비스 응답 시간이 길어지면 클라이언트의 응답성도 저하될 수 있다.
// 동기 호출 예시
auto result = client->async_send_request(request);
if (result.get()->success) {
// 응답 처리
}
2. 비동기 호출
비동기 호출은 서비스 요청을 보낸 후 즉시 반환되며, 응답은 나중에 콜백을 통해 처리된다. 이를 통해 클라이언트는 서비스 응답을 기다리지 않고 다른 작업을 계속 수행할 수 있다. 멀티 서비스 구조에서는 비동기 호출이 자주 사용된다.
// 비동기 호출 예시
auto future = client->async_send_request(request);
if (future.wait_for(std::chrono::seconds(10)) == std::future_status::ready) {
// 응답이 도착하면 처리
}
3. 병렬 호출
병렬 호출은 여러 서비스에 동시에 요청을 보내고, 각 서비스가 응답할 때까지 독립적으로 처리하는 방식이다. 이 방식은 여러 서비스가 서로 독립적일 때 유용하며, 모든 응답을 수집한 후 후속 작업을 수행하는 방식으로 확장될 수 있다.
// 병렬 호출 예시
auto future1 = client1->async_send_request(request1);
auto future2 = client2->async_send_request(request2);
// 두 응답을 모두 기다림
if (future1.wait_for(timeout) == std::future_status::ready &&
future2.wait_for(timeout) == std::future_status::ready) {
// 두 서비스 응답 처리
}
4. 순차 호출
순차 호출은 한 서비스의 결과를 다음 서비스의 입력으로 사용하는 방식이다. 이 방식은 서비스 간에 종속성이 있을 때 사용되며, 처리 순서를 보장해야 할 때 유용하다.
// 순차 호출 예시
auto result1 = client1->async_send_request(request1);
if (result1.get()->success) {
auto result2 = client2->async_send_request(result1.get()->output);
if (result2.get()->success) {
// 두 번째 서비스 응답 처리
}
}
8. 실제 응용 사례
멀티 서비스 구조는 로봇 시스템, 분산 시스템, 클라우드 기반의 로봇 서비스와 같이 여러 노드가 상호작용하는 환경에서 응용된다. 예를 들어, 자율 주행 차량의 제어 시스템에서는 여러 센서 데이터를 수집하고, 그 데이터를 처리하는 다양한 서비스들이 동시에 호출된다. 각 서비스는 특정한 작업을 담당하며, 멀티 서비스 구조를 통해 병렬로 작업이 처리된다.
또한, 물류 로봇에서 경로 계획 서비스와 장애물 감지 서비스는 서로 다른 노드에서 동작하며, 이들은 병렬적으로 호출되어 로봇의 실시간 경로 수정에 사용된다. 이때 경로 계획 서비스는 장애물 감지 결과를 반영하여 새로운 경로를 계산하고, 로봇에게 명령을 전달하게 된다.
9. ROS2 서비스와 액션의 차이점
ROS2 서비스와 액션은 유사한 개념으로 보일 수 있지만, 둘 사이에는 중요한 차이점이 있다. 서비스는 요청에 대한 즉각적인 응답을 요구하는 반면, 액션은 비동기적으로 장시간에 걸쳐 작업을 수행하고, 그 동안 상태와 피드백을 제공한다.
서비스와 액션 비교
| 특성 | 서비스 | 액션 |
|---|---|---|
| 요청-응답 | 즉각적인 응답 | 장기적인 작업 수행 |
| 상태 피드백 | 없음 | 작업 상태 및 피드백 제공 |
| 비동기 처리 | 가능 | 비동기 처리 기본 |
| 용도 | 짧은 작업 | 장기 작업 (예: 경로 계획, 로봇 이동) |
멀티 서비스 구조에서 서비스와 액션을 조합하여 사용할 수 있으며, 서비스는 빠르게 처리해야 하는 요청에, 액션은 상대적으로 긴 작업에 적합하다.
10. 멀티 서비스 구조 설계 시 고려 사항
멀티 서비스 구조를 설계할 때 여러 요소를 고려해야 한다. 각 서비스가 독립적으로 동작하더라도, 시스템 전체의 성능과 안정성을 유지하기 위해 다음과 같은 요소를 신중하게 다루어야 한다.
1. 처리 시간과 병목 현상
여러 서비스가 동시에 요청을 처리할 때, 특정 서비스가 과도한 요청을 받거나 처리 시간이 길어지면 병목 현상이 발생할 수 있다. 이를 방지하기 위해 각 서비스의 처리 시간을 모니터링하고, 병목이 발생하는 부분을 최적화해야 한다.
또한, 일부 서비스는 처리 시간이 짧고 다른 서비스는 상대적으로 긴 경우가 많다. 예를 들어, 센서 데이터 처리는 비교적 빠르게 완료되지만, 경로 계획이나 최적화 서비스는 시간이 많이 소요될 수 있다. 이러한 서비스 간의 처리 시간 차이를 고려하여 비동기 방식이나 멀티스레딩을 적극 활용하는 것이 중요하다.
2. 오류 처리 및 복구 전략
멀티 서비스 구조에서 중요한 또 하나의 요소는 오류 처리이다. 서비스가 실패했을 때 이를 감지하고 적절한 대응을 해야 한다. 예를 들어, 특정 서비스가 시간 초과로 응답하지 않으면 백업 서비스를 호출하거나, 예외 처리를 통해 시스템의 안정성을 유지할 수 있는 로직을 마련해야 한다.
복구 전략에는 여러 가지 방법이 있다: - 자동 재시도: 실패한 요청을 자동으로 다시 시도하는 방법. - 대체 서비스: 특정 서비스가 실패할 경우 대체 서비스를 호출하는 방법. - 서비스 종료 및 재시작: 비정상적으로 동작하는 서비스를 종료하고 재시작하는 방법.
3. 서비스 간 의존성 분석
복잡한 멀티 서비스 구조에서는 서비스 간의 의존성을 미리 분석하고, 이를 고려한 설계를 해야 한다. 예를 들어, 서비스 A의 응답이 완료되기 전에 서비스 B가 호출될 수 없도록, 서비스 간의 호출 순서를 명확하게 정의해야 한다. 이를 위해 의존성 그래프를 작성하여 각 서비스 간의 상호작용을 시각화하고, 처리 순서를 체계적으로 관리할 수 있다.
이와 같이 의존성 그래프를 통해 서비스 간의 관계를 정의하고, 특정 서비스가 실패했을 때 어떤 영향을 미치는지 시뮬레이션할 수 있다.
4. 리소스 관리
여러 서비스가 동시에 실행되면 시스템의 리소스(CPU, 메모리, 네트워크 대역폭 등)가 소모되기 때문에, 각 서비스의 리소스 사용을 주기적으로 모니터링하고 관리해야 한다. 특히 로봇 시스템에서는 제한된 하드웨어 리소스 내에서 여러 작업을 처리해야 하므로, 리소스가 한정된 상황에서도 안정적으로 동작할 수 있도록 최적화가 필요하다.
5. 서비스의 분산 처리
멀티 서비스 구조에서는 서비스가 여러 노드에서 분산되어 실행될 수 있다. 이 경우 네트워크를 통한 통신 지연, 데이터 동기화 문제 등을 해결해야 한다. 이를 위해 ROS2의 DDS(Data Distribution Service) 기반 통신 방식을 활용하여 분산 서비스 간의 데이터 공유 및 동기화를 최적화할 수 있다.
분산 처리를 고려할 때는 다음과 같은 요소들을 관리해야 한다: - 네트워크 대역폭 사용량 최적화: 여러 노드 간의 통신이 빈번하게 이루어지는 경우, 네트워크 사용량을 줄이기 위한 압축 또는 데이터 필터링 기법을 도입한다. - 데이터 일관성 유지: 분산된 서비스 간의 데이터 동기화가 중요하다. 이를 위해 데이터 일관성 규칙을 정의하고, 네트워크 지연으로 인한 데이터 충돌을 방지해야 한다. - 장애 복구: 분산 환경에서 특정 노드가 다운되거나 네트워크가 끊겼을 때 복구 절차를 정의하여, 시스템이 중단되지 않고 계속 동작할 수 있도록 해야 한다.
11. 멀티 서비스 구조 구현 예시
멀티 서비스 구조를 구현하는 과정에서는 여러 가지 기술적 선택이 필요하다. ROS2에서 멀티 서비스 구조를 구현할 때 자주 사용하는 방법 중 하나는 비동기 서비스 호출을 기반으로 한 설계이다. 여기서는 두 개 이상의 서비스를 병렬로 호출하고, 그 결과를 종합하여 처리하는 예시를 다룬다.
예시 코드: 두 서비스 병렬 호출
#include "rclcpp/rclcpp.hpp"
#include "example_interfaces/srv/add_two_ints.hpp"
using AddTwoInts = example_interfaces::srv::AddTwoInts;
using namespace std::chrono_literals;
class MultiServiceClient : public rclcpp::Node {
public:
MultiServiceClient() : Node("multi_service_client") {
client1_ = this->create_client<AddTwoInts>("service1");
client2_ = this->create_client<AddTwoInts>("service2");
if (!client1_->wait_for_service(5s) || !client2_->wait_for_service(5s)) {
RCLCPP_ERROR(this->get_logger(), "서비스에 연결할 수 없다.");
return;
}
auto request1 = std::make_shared<AddTwoInts::Request>();
request1->a = 1;
request1->b = 2;
auto request2 = std::make_shared<AddTwoInts::Request>();
request2->a = 3;
request2->b = 4;
auto future1 = client1_->async_send_request(request1);
auto future2 = client2_->async_send_request(request2);
rclcpp::spin_until_future_complete(this->get_node_base_interface(), future1);
rclcpp::spin_until_future_complete(this->get_node_base_interface(), future2);
RCLCPP_INFO(this->get_logger(), "서비스1 결과: %d", future1.get()->sum);
RCLCPP_INFO(this->get_logger(), "서비스2 결과: %d", future2.get()->sum);
}
private:
rclcpp::Client<AddTwoInts>::SharedPtr client1_;
rclcpp::Client<AddTwoInts>::SharedPtr client2_;
};
int main(int argc, char **argv) {
rclcpp::init(argc, argv);
rclcpp::spin(std::make_shared<MultiServiceClient>());
rclcpp::shutdown();
return 0;
}
이 코드는 두 개의 서비스 서버에 동시에 요청을 보내고, 두 개의 응답을 각각 받아 처리하는 예시이다. 이를 통해 ROS2에서 멀티 서비스 구조를 효율적으로 구현할 수 있다.