진화적 아키텍처

52

1부

역학

스트레이터 혹은 유틸리티 서비스는 이러한 메시지를 모니터링하며 규정을 위반한 통신이 발

생하지 않도록 방지한다. 모니터링 대신 비동기 메시지 대기열을 사용하는 방법도 있다. 각 도

메인 서비스는 협업 메시지를 대기열에 게시하고, 오케스트레이터가 해당 대기열을 수신하며

협업 대상 서비스의 유효성을 검사한다. 이러한 피트니스 함수를 지속적으로 실행하면 잘못된

통신이 발생하는 즉시 수신 서비스에서 대처할 수 있다. 일반적으로 보안 문제 또는 유해한 사

이드 이펙트가 주범인 경우가 많다.

지속 피트니스 함수의 이점은 즉시성이다. 아키텍트와 이해관계자 모두는 거버넌스 위반 시점

을 즉시 알 수 있다. 그러나 이러한 해결책은 런타임 오버헤드를 발생시킨다. 모니터링이나 메

시지 대기열을 유지하려면 작업 리소스가 필요하기 때문이다. 또한 이 정도 수준의 관찰 가능

성을 구현하면 성능과 확장성에 부정적인 영향을 미칠 위험이 있다.

피트니스 함수를 트리거 방식으로 구현하는 방법도 있다. 배포 파이프라인은 정규 케이던스에

맞추어 피트니스 함수를 호출하며 로그 파일을 수집하고 모든 통신이 이상 없는지 확인한다.

4

.

3

.

1

절에서 이러한 피트니스 함수를 실제로 구현할 것이다. 트리거 피트니스 함수의 이점은

런타임에 영향을 미치지 않는다는 것이다. 발동할 때만 실행되고 로그 레코드를 확인한다. 그

러나 보안 등의 중대한 거버넌스 문제는 대응 시간이 늦어질수록 부정적인 영향도 커진다. 이

러한 분야에 트리거 피트니스를 적용하면 안 된다.

소프트웨어 아키텍처의 ...