진화를 위한 디자인
혁신적인 디자인은 지속적인 혁신의 핵심입니다.
모든 성공적인 애플리케이션은 시간이 지남에 따라 변경됩니다. 버그가 수정되거나, 새 기능이 추가되거나, 새로운 기술이 도입되거나, 기존 시스템이 확장 가능하고 복원력 있게 만들어집니다. 애플리케이션의 모든 부분이 긴밀하게 결합된 경우에는 변경 내용을 시스템에 도입하기 매우 어렵습니다. 애플리케이션의 한 부분이 변경되는 경우, 다른 부분이 중단되거나 전체 코드베이스에서 변경 내용이 파급될 수 있습니다.
이 문제는 모놀리식 애플리케이션으로 제한되지 않습니다. 애플리케이션은 서비스로 분해될 수 있지만, 여전히 시스템을 엄격하며 불안정하게 만드는 일종의 긴밀한 결합을 나타낼 수 있습니다. 하지만 서비스가 발전하도록 설계되면, 팀은 혁신하며 지속적으로 새로운 기능을 제공 가능합니다.
여기에 나열된 많은 고려 사항을 해결해 주는 마이크로 서비스는 혁신적 디자인을 달성하기 위한 유용한 방법이 되고 있습니다.
권장 사항
높은 응집력 및 느슨한 결합 적용. 서비스는 논리적으로 함께 속하는 기능을 제공하는 경우 응집력이 있습니다. 다른 서비스를 변경하지 않고도 한 서비스를 변경할 수 있다면, 서비스가 느슨하게 결합됩니다. 일반적으로 높은 응집력은 하나의 함수를 변경하기 위해서는 모든 관련 함수가 한 서비스에 상주하는 다른 관련 함수의 변경이 필요함을 나타냅니다. 서비스를 업데이트하기 위해 다른 서비스에 관한 조정된 업데이트가 필요한 경우, 이는 서비스가 응집력이 없다는 신호일 수도 있습니다. 이러한 경계를 식별하는 것이 DDD(도메인 기반 디자인)의 목표 중 하나입니다.
도메인 지식을 캡슐화합니다. 클라이언트가 서비스를 사용하는 경우 도메인의 비즈니스 규칙 적용에 대한 책임은 클라이언트에 있지 않습니다. 대신, 서비스는 해당 책임에 속해있는 모든 도메인 지식을 캡슐화해야 합니다. 그렇지 않은 경우, 모든 클라이언트가 비즈니스 규칙을 적용해야 하며, 결국 도메인 지식은 애플리케이션의 여러 부분에 걸쳐 분산됩니다.
비동기 메시징을 사용합니다. 소비자와 메시지 생산자를 분리하는 방법이 비동기 메시징입니다. 생산자는 메시지에 응답하거나 특정 작업을 수행하는 소비자에 종속되지 않습니다. 생산자가 메시지를 사용하는 사람조차 모르게 하기 위해 게시/하위 아키텍처를 사용할 수 있습니다. 새 서비스는 생산자를 수정하지 않고도 메시지를 쉽게 사용 가능합니다.
도메인 지식을 게이트웨이에 빌드하지 마세요. 요청 라우팅, 프로토콜 변환, 부하 분산 또는 인증 등의 마이크로 서비스 아키텍처에서 게이트웨이가 유용할 수 있습니다. 그러나 게이트웨이는 이러한 종류의 인프라 기능으로 제한해야 합니다. 과도한 종속성이 발생하지 않게 하기 위해, 도메인 지식을 구현하지 않아야 합니다.
열린 인터페이스를 노출합니다. 서비스 사이에 사용자 지정 변환 레이어를 만들지 않도록 합니다. 대신 서비스는 API를 노출하기 위해 잘 정의된 API 계약을 사용해야 합니다. API의 버전을 지정하여 이전 버전과의 호환성을 유지하면서 API를 발전할 수 있도록 해야 합니다. 이를 통해, 업데이트에 의존하는 모든 업스트림 서비스에 관한 업데이트를 조정하지 않고도 서비스 업데이트가 가능합니다. 공용 서비스는 RESTful API를 노출하기 위해 HTTP를 사용해야 합니다. 성능상의 이유로, 백 엔드 서비스는 RPC 스타일 메시징 프로토콜을 사용 가능합니다.
서비스 계약에 관해 디자인하고 테스트합니다. 서비스가 잘 정의된 API를 노출하는 경우 이러한 API를 고려해서 개발을 수행하고 테스트를 진행할 수 있습니다. 이를 통해, 모든 종속 서비스를 회전하지 않고도 개별 서비스를 개발 및 테스트 가능합니다. (물론 실제 서비스에 대한 통합 및 부하 테스트는 계속 수행합니다.)
피트니스 기능을 사용합니다. 최적의 솔루션에 가깝거나 동떨어져 있는지 확인하기 위해, 피트니스 기능이 결과를 측정합니다. 피트니스 기능은 시간이 지남에 따라 변경이 발생하는 경우, 아키텍처 특성을 보호하는 데 도움이 됩니다. 피트니스 기능은 아키텍처 특성에 관한 객관적인 무결성 평가를 제공하는 메커니즘입니다. 메트릭, 단위 테스트, 비정상 상황 엔지니어링 등의 다양한 메커니즘이 평가에 포함될 수 있습니다. 예를 들어, 설계자는 페이지 로드 시간을 중요한 특성으로 식별할 수 있습니다. 그런 다음, 페이지 로드 시간을 테스트하고 연속 통합의 일부로 테스트를 실행하는 적합성 함수가 워크로드에 있어야 합니다.
추상 인프라를 도메인 논리와 분리. 메시징 또는 지속성 등의 인프라 관련 기능과 도메인 논리가 혼합되지 않도록 하세요. 그렇지 않은 경우, 도메인 논리를 변경하기 위해서는 인프라 계층에 대한 업데이트가 필요하며, 반대의 경우도 마찬가지입니다.
교차 절단 문제를 별도의 서비스로 오프로드합니다. 예를 들어, 몇 가지 서비스가 요청을 인증해야 할 경우, 이 기능을 자체 서비스로 이동할 수 있습니다. 그런 다음, 인증 서비스를 사용하는 다른 서비스를 건드리지 않으면서 해당 인증 서비스를 개선할 수 있습니다(예: 새 인증 흐름 추가).
서비스를 독립적으로 배포합니다. DevOps 팀이 단일 서비스를 애플리케이션의 다른 서비스와 독립적으로 배포할 수 있는 경우, 업데이트는 더욱 빠르고 안전하게 발생할 수 있습니다. 버그 픽스와 새로운 기능은 좀 더 규칙적으로 롤아웃될 수 있습니다. 애플리케이션 및 릴리스 프로세스 모두를 독립 업데이트를 지원하도록 디자인합니다.