분산 시스템의 컴파일 가능한 구성

이 게시물에서 우리는 분산 시스템 구성을 처리하는 흥미로운 방법을 공유하고 싶습니다.
구성은 유형이 안전한 방식으로 Scala 언어로 직접 표현됩니다. 구현 예가 자세히 설명되어 있습니다. 전체 개발 프로세스에 대한 영향을 포함하여 제안의 다양한 측면이 논의됩니다.

(러시아어로)

개요

강력한 분산 시스템을 구축하려면 모든 노드에서 정확하고 일관된 구성을 사용해야 합니다. 일반적인 솔루션은 텍스트 배포 설명(terraform, ansible 등)과 자동으로 생성된 구성 파일(종종 각 노드/역할 전용)을 사용하는 것입니다. 또한 각 통신 노드에서 동일한 버전의 동일한 프로토콜을 사용하고 싶을 수도 있습니다(그렇지 않으면 비호환성 문제가 발생하게 됩니다). JVM 세계에서 이는 최소한 메시징 라이브러리가 모든 통신 노드에서 동일한 버전이어야 함을 의미합니다.

시스템 테스트는 어떻습니까? 물론 통합 테스트에 앞서 모든 구성 요소에 대한 단위 테스트를 거쳐야 합니다. 런타임 시 테스트 결과를 추정하려면 모든 라이브러리의 버전이 런타임과 테스트 환경 모두에서 동일하게 유지되는지 확인해야 합니다.

통합 테스트를 실행할 때 모든 노드에서 동일한 클래스 경로를 갖는 것이 훨씬 쉬운 경우가 많습니다. 배포 시 동일한 클래스 경로가 사용되는지 확인하면 됩니다. (다른 노드에서 다른 클래스 경로를 사용할 수 있지만 이 구성을 표현하고 올바르게 배포하는 것이 더 어렵습니다.) 따라서 작업을 단순하게 유지하기 위해 모든 노드에서 동일한 클래스 경로만 고려합니다.

구성은 소프트웨어와 함께 발전하는 경향이 있습니다. 우리는 일반적으로 다양한 버전을 식별하기 위해 버전을 사용합니다.
소프트웨어 진화의 단계. 버전 관리에서 구성을 다루고 일부 레이블을 사용하여 다양한 구성을 식별하는 것이 합리적으로 보입니다. 프로덕션에 구성이 하나만 있는 경우 단일 버전을 식별자로 사용할 수 있습니다. 때로는 여러 프로덕션 환경이 있을 수 있습니다. 그리고 각 환경마다 별도의 구성 분기가 필요할 수 있습니다. 따라서 다양한 구성을 고유하게 식별하기 위해 구성에 분기 및 버전 레이블이 지정될 수 있습니다. 각 분기 레이블 및 버전은 분산 노드, 포트, 외부 리소스, 각 노드의 클래스 경로 라이브러리 버전의 단일 조합에 해당합니다. 여기서는 다른 아티팩트와 동일한 방식으로 단일 분기만 다루고 구성을 1.2.3개 구성 요소 XNUMX진수 버전(XNUMX)으로 식별합니다.

최신 환경에서는 구성 파일이 더 이상 수동으로 수정되지 않습니다. 일반적으로 우리는
배포 시 구성 파일 및 절대 만지지 마세요 나중에. 그렇다면 구성 파일에 왜 여전히 텍스트 형식을 사용하는지 질문할 수 있습니다. 실행 가능한 옵션은 구성을 컴파일 단위 내에 배치하고 컴파일 시간 구성 유효성 검사의 이점을 활용하는 것입니다.

이번 포스팅에서는 컴파일된 아티팩트에 구성을 유지하는 아이디어를 살펴보겠습니다.

컴파일 가능한 구성

이 섹션에서는 정적 구성의 예를 설명합니다. 두 가지 간단한 서비스인 에코 서비스와 에코 서비스 클라이언트가 구성 및 구현됩니다. 그런 다음 두 서비스가 모두 포함된 두 개의 서로 다른 분산 시스템이 인스턴스화됩니다. 하나는 단일 노드 구성용이고 다른 하나는 XNUMX개 노드 구성용입니다.

일반적인 분산 시스템은 몇 개의 노드로 구성됩니다. 노드는 다음과 같은 유형을 사용하여 식별할 수 있습니다.

sealed trait NodeId
case object Backend extends NodeId
case object Frontend extends NodeId

또는

case class NodeId(hostName: String)

심지어

object Singleton
type NodeId = Singleton.type

이러한 노드는 다양한 역할을 수행하고 일부 서비스를 실행하며 TCP/HTTP 연결을 통해 다른 노드와 통신할 수 있어야 합니다.

TCP 연결의 경우 최소한 포트 번호가 필요합니다. 또한 클라이언트와 서버가 동일한 프로토콜을 사용하는지 확인하고 싶습니다. 노드 간의 연결을 모델링하기 위해 다음 클래스를 선언해 보겠습니다.

case class TcpEndPoint[Protocol](node: NodeId, port: Port[Protocol])

어디에 Port 그냥 Int 허용된 범위 내에서:

type PortNumber = Refined[Int, Closed[_0, W.`65535`.T]]

세련된 유형

만나다 세련된 도서관. 즉, 다른 유형에 컴파일 시간 제약 조건을 추가할 수 있습니다. 이 경우 Int 포트 번호를 나타낼 수 있는 16비트 값만 허용됩니다. 이 구성 접근 방식에는 이 라이브러리를 사용할 필요가 없습니다. 그냥 너무 잘 어울리는 것 같아요.

HTTP(REST)의 경우 서비스 경로가 필요할 수도 있습니다.

type UrlPathPrefix = Refined[String, MatchesRegex[W.`"[a-zA-Z_0-9/]*"`.T]]
case class PortWithPrefix[Protocol](portNumber: PortNumber, pathPrefix: UrlPathPrefix)

팬텀형

컴파일 중에 프로토콜을 식별하기 위해 우리는 유형 인수를 선언하는 Scala 기능을 사용합니다. Protocol 수업에서는 사용하지 않는 것입니다. 소위 말하는거다 팬텀 유형. 런타임에는 프로토콜 식별자 인스턴스가 거의 필요하지 않으므로 저장하지 않습니다. 컴파일하는 동안 이 팬텀 유형은 추가적인 유형 안전성을 제공합니다. 잘못된 프로토콜로 포트를 전달할 수 없습니다.

가장 널리 사용되는 프로토콜 중 하나는 Json 직렬화를 사용하는 REST API입니다.

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

어디에 RequestMessage 클라이언트가 서버에 보낼 수 있는 기본 메시지 유형입니다. ResponseMessage 서버로부터의 응답 메시지입니다. 물론 원하는 정밀도로 통신 프로토콜을 지정하는 다른 프로토콜 설명을 만들 수도 있습니다.

이 게시물의 목적을 위해 우리는 프로토콜의 더 간단한 버전을 사용할 것입니다:

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

이 프로토콜에서는 요청 메시지가 URL에 추가되고 응답 메시지가 일반 문자열로 반환됩니다.

서비스 구성은 서비스 이름, 포트 모음 및 일부 종속성으로 설명될 수 있습니다. Scala에서 이러한 모든 요소를 ​​표현하는 방법에는 몇 가지 방법이 있습니다(예: HList, 대수 데이터 유형). 이 게시물의 목적을 위해 우리는 케이크 패턴을 사용하고 결합 가능한 조각(모듈)을 특성으로 나타낼 것입니다. (케이크 패턴은 이 컴파일 가능한 구성 접근 방식의 요구 사항이 아닙니다. 이는 아이디어의 가능한 구현 중 하나일 뿐입니다.)

케이크 패턴을 다른 노드의 끝점으로 사용하여 종속성을 표현할 수 있습니다.

  type EchoProtocol[A] = SimpleHttpGetRest[A, A]

  trait EchoConfig[A] extends ServiceConfig {
    def portNumber: PortNumber = 8081
    def echoPort: PortWithPrefix[EchoProtocol[A]] = PortWithPrefix[EchoProtocol[A]](portNumber, "echo")
    def echoService: HttpSimpleGetEndPoint[NodeId, EchoProtocol[A]] = providedSimpleService(echoPort)
  }

에코 서비스에는 포트만 구성하면 됩니다. 그리고 이 포트가 에코 프로토콜을 지원함을 선언합니다. 특성이 추상 메서드 선언을 허용하기 때문에 지금은 특정 포트를 지정할 필요가 없습니다. 추상 메소드를 사용하는 경우 컴파일러는 구성 인스턴스에서 구현을 요구합니다. 여기서는 구현을 제공했습니다(8081) 구체적인 구성에서 건너뛰면 기본값으로 사용됩니다.

에코 서비스 클라이언트 구성에서 종속성을 선언할 수 있습니다.

  trait EchoClientConfig[A] {
    def testMessage: String = "test"
    def pollInterval: FiniteDuration
    def echoServiceDependency: HttpSimpleGetEndPoint[_, EchoProtocol[A]]
  }

종속성은 다음과 같은 유형을 가집니다. echoService. 특히 동일한 프로토콜이 필요합니다. 따라서 이 두 가지 종속성을 연결하면 올바르게 작동할 것이라고 확신할 수 있습니다.

서비스 구현

서비스를 시작하고 정상적으로 종료하려면 기능이 필요합니다. (서비스를 종료하는 기능은 테스트에 매우 중요합니다.) 또한 주어진 구성에 대해 이러한 기능을 지정하는 몇 가지 옵션이 있습니다(예를 들어 유형 클래스를 사용할 수 있음). 이 게시물에서는 케이크 패턴을 다시 사용하겠습니다. 다음을 사용하여 서비스를 표현할 수 있습니다. cats.Resource 이미 브라케팅 및 리소스 릴리스를 제공합니다. 리소스를 얻으려면 구성과 일부 런타임 컨텍스트를 제공해야 합니다. 따라서 서비스 시작 기능은 다음과 같습니다.

  type ResourceReader[F[_], Config, A] = Reader[Config, Resource[F, A]]

  trait ServiceImpl[F[_]] {
    type Config
    def resource(
      implicit
      resolver: AddressResolver[F],
      timer: Timer[F],
      contextShift: ContextShift[F],
      ec: ExecutionContext,
      applicative: Applicative[F]
    ): ResourceReader[F, Config, Unit]
  }

어디에

• Config — 이 서비스 시작기에 필요한 구성 유형
• AddressResolver — 다른 노드의 실제 주소를 얻을 수 있는 기능이 있는 런타임 개체(자세한 내용은 계속 읽으세요).

다른 유형은 다음에서 유래합니다. cats:

• F[_] — 효과 유형(가장 간단한 경우 F[A] 그냥 될 수있다 () => A. 이 게시물에서 우리는 cats.IO.)
• Reader[A,B] — 함수의 동의어입니다. A => B
• cats.Resource — 획득 및 해제 방법이 있습니다.
• Timer — 수면/시간 측정 가능
• ContextShift - 아날로그 ExecutionContext
• Applicative — 실제 함수 래퍼(거의 모나드)(결국 다른 것으로 대체할 수 있음)

이 인터페이스를 사용하여 몇 가지 서비스를 구현할 수 있습니다. 예를 들어, 아무것도 하지 않는 서비스는 다음과 같습니다.

  trait ZeroServiceImpl[F[_]] extends ServiceImpl[F] {
    type Config <: Any
    def resource(...): ResourceReader[F, Config, Unit] =
      Reader(_ => Resource.pure[F, Unit](()))
  }

(참조 소스 코드 다른 서비스 구현을 위한 — 에코 서비스,
에코 클라이언트 및 수명 컨트롤러.)

노드는 몇 가지 서비스를 실행하는 단일 객체입니다(리소스 체인 시작은 케이크 패턴에 의해 활성화됩니다).

object SingleNodeImpl extends ZeroServiceImpl[IO]
  with EchoServiceService
  with EchoClientService
  with FiniteDurationLifecycleServiceImpl
{
  type Config = EchoConfig[String] with EchoClientConfig[String] with FiniteDurationLifecycleConfig
}

노드에서는 이 노드에 필요한 정확한 구성 유형을 지정합니다. 컴파일러는 우리가 불충분한 유형으로 객체(케이크)를 만드는 것을 허용하지 않습니다. Config 유형. 또한 완전한 구성을 제공하지 않으면 노드를 시작할 수 없습니다.

노드 주소 확인

연결을 설정하려면 각 노드에 대한 실제 호스트 주소가 필요합니다. 구성의 다른 부분보다 나중에 알려질 수도 있습니다. 따라서 노드 ID와 실제 주소 간의 매핑을 제공하는 방법이 필요합니다. 이 매핑은 다음과 같은 함수입니다.

case class NodeAddress[NodeId](host: Uri.Host)
trait AddressResolver[F[_]] {
  def resolve[NodeId](nodeId: NodeId): F[NodeAddress[NodeId]]
}

이러한 기능을 구현하는 방법에는 몇 가지가 있습니다.

1. 배포 전에 실제 주소를 알고 있으면 노드 호스트 인스턴스화 중에 실제 주소로 Scala 코드를 생성하고 나중에 빌드를 실행할 수 있습니다(컴파일 시간 확인을 수행한 다음 통합 테스트 도구 모음 실행). 이 경우 매핑 기능은 정적으로 알려져 있으며 다음과 같이 단순화될 수 있습니다. Map[NodeId, NodeAddress].
2. 때로는 노드가 실제로 시작될 때 나중에 실제 주소를 얻거나 아직 시작되지 않은 노드의 주소가 없는 경우도 있습니다. 이 경우 다른 모든 노드보다 먼저 시작되는 검색 서비스가 있을 수 있으며 각 노드는 해당 서비스에서 자신의 주소를 알리고 종속성을 구독할 수 있습니다.
3. 수정할 수 있다면 /etc/hosts, 사전 정의된 호스트 이름(예: my-project-main-node 및 echo-backend) 배포 시 이 이름을 IP 주소와 연결하면 됩니다.

이 게시물에서는 이러한 사례를 더 자세히 다루지 않습니다. 실제로 우리의 장난감 예에서는 모든 노드가 동일한 IP 주소를 갖습니다. 127.0.0.1.

이 게시물에서는 두 가지 분산 시스템 레이아웃을 고려해 보겠습니다.

1. 모든 서비스가 단일 노드에 배치되는 단일 노드 레이아웃.
2. 서비스와 클라이언트가 서로 다른 노드에 있는 두 개의 노드 레이아웃.

에 대한 구성 단일 노드 레이아웃은 다음과 같습니다:

단일 노드 구성

object SingleNodeConfig extends EchoConfig[String] 
  with EchoClientConfig[String] with FiniteDurationLifecycleConfig
{
  case object Singleton // identifier of the single node 
  // configuration of server
  type NodeId = Singleton.type
  def nodeId = Singleton

  /** Type safe service port specification. */
  override def portNumber: PortNumber = 8088

  // configuration of client

  /** We'll use the service provided by the same host. */
  def echoServiceDependency = echoService

  override def testMessage: UrlPathElement = "hello"

  def pollInterval: FiniteDuration = 1.second

  // lifecycle controller configuration
  def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 requests, not 9.
}

여기서는 서버와 클라이언트 구성을 모두 확장하는 단일 구성을 만듭니다. 또한 일반적으로 클라이언트와 서버를 종료하는 라이프사이클 컨트롤러를 구성합니다. lifetime 간격이 지나갑니다.

동일한 서비스 구현 및 구성 세트를 사용하여 두 개의 개별 노드가 있는 시스템 레이아웃을 생성할 수 있습니다. 우리는 단지 창조하기만 하면 된다 두 개의 별도 노드 구성 적절한 서비스를 통해:

XNUMX개 노드 구성

  object NodeServerConfig extends EchoConfig[String] with SigTermLifecycleConfig
  {
    type NodeId = NodeIdImpl

    def nodeId = NodeServer

    override def portNumber: PortNumber = 8080
  }

  object NodeClientConfig extends EchoClientConfig[String] with FiniteDurationLifecycleConfig
  {
    // NB! dependency specification
    def echoServiceDependency = NodeServerConfig.echoService

    def pollInterval: FiniteDuration = 1.second

    def lifetime: FiniteDuration = 10500.milliseconds // additional 0.5 seconds so that there are 10 request, not 9.

    def testMessage: String = "dolly"
  }

종속성을 어떻게 지정하는지 살펴보세요. 현재 노드의 종속성으로 다른 노드가 제공하는 서비스를 언급합니다. 프로토콜을 설명하는 팬텀 유형이 포함되어 있으므로 종속성 유형을 확인합니다. 그리고 런타임에는 올바른 노드 ID를 갖게 됩니다. 이는 제안된 구성 접근 방식의 중요한 측면 중 하나입니다. 이는 포트를 한 번만 설정하고 올바른 포트를 참조하고 있는지 확인하는 기능을 제공합니다.

두 개의 노드 구현

이 구성에서는 정확히 동일한 서비스 구현을 사용합니다. 전혀 변화가 없습니다. 그러나 우리는 서로 다른 서비스 세트를 포함하는 두 개의 서로 다른 노드 구현을 만듭니다.

  object TwoJvmNodeServerImpl extends ZeroServiceImpl[IO] with EchoServiceService with SigIntLifecycleServiceImpl {
    type Config = EchoConfig[String] with SigTermLifecycleConfig
  }

  object TwoJvmNodeClientImpl extends ZeroServiceImpl[IO] with EchoClientService with FiniteDurationLifecycleServiceImpl {
    type Config = EchoClientConfig[String] with FiniteDurationLifecycleConfig
  }

첫 번째 노드는 서버를 구현하며 서버 측 구성만 필요합니다. 두 번째 노드는 클라이언트를 구현하며 구성의 또 다른 부분이 필요합니다. 두 노드 모두 수명 사양이 필요합니다. 이 사후 서비스 노드의 목적을 위해 다음을 사용하여 종료될 수 있는 무한한 수명을 갖습니다. SIGTERM, 에코 클라이언트는 구성된 유한 기간 후에 종료됩니다. 참조 스타터 애플리케이션 자세한 내용은.

전반적인 개발 과정

이 접근 방식이 구성 작업 방식을 어떻게 변경하는지 살펴보겠습니다.

코드로서의 구성이 컴파일되어 아티팩트를 생성합니다. 구성 아티팩트를 다른 코드 아티팩트와 분리하는 것이 합리적으로 보입니다. 동일한 코드 기반에 다양한 구성을 가질 수 있는 경우가 많습니다. 물론 다양한 구성 분기의 여러 버전이 있을 수도 있습니다. 구성에서 특정 버전의 라이브러리를 선택할 수 있으며 이는 이 구성을 배포할 때마다 일정하게 유지됩니다.

구성 변경은 코드 변경이 됩니다. 따라서 동일한 품질 보증 프로세스가 적용되어야 합니다.

티켓 -> 홍보 -> 검토 -> 병합 -> 지속적 통합 -> 지속적 배포

접근 방식에는 다음과 같은 결과가 있습니다.

1. 구성은 특정 시스템의 인스턴스에 대해 일관성이 있습니다. 노드 간 연결이 잘못될 수 있는 방법은 없는 것 같습니다.
2. 하나의 노드에서만 구성을 변경하는 것은 쉽지 않습니다. 로그인해서 일부 텍스트 파일을 변경하는 것은 무리인 것 같습니다. 따라서 구성 드리프트 가능성이 줄어듭니다.
3. 작은 구성 변경은 쉽지 않습니다.
4. 대부분의 구성 변경 사항은 동일한 개발 프로세스를 따르며 일부 검토를 통과합니다.

프로덕션 구성을 위해 별도의 저장소가 필요합니까? 프로덕션 구성에는 많은 사람의 손이 닿지 않는 곳에 보관하고 싶은 민감한 정보가 포함될 수 있습니다. 따라서 프로덕션 구성을 포함하고 액세스가 제한된 별도의 저장소를 유지하는 것이 좋습니다. 구성을 두 부분으로 나눌 수 있습니다. 하나는 프로덕션의 가장 개방적인 매개변수를 포함하고 다른 하나는 구성의 비밀 부분을 포함합니다. 이를 통해 대부분의 개발자는 매우 민감한 항목에 대한 액세스를 제한하면서 대다수의 매개변수에 액세스할 수 있습니다. 기본 매개변수 값이 있는 중간 특성을 사용하면 이를 쉽게 수행할 수 있습니다.

변화

다른 구성 관리 기술과 비교하여 제안된 접근 방식의 장단점을 살펴보겠습니다.

우선, 제안된 구성 처리 방법의 다양한 측면에 대한 몇 가지 대안을 나열하겠습니다.

1. 대상 컴퓨터의 텍스트 파일입니다.
2. 중앙 집중식 키-값 저장소(예: etcd/zookeeper).
3. 프로세스를 다시 시작하지 않고도 재구성/다시 시작할 수 있는 하위 프로세스 구성 요소입니다.
4. 아티팩트 및 버전 제어 외부 구성입니다.

텍스트 파일은 임시 수정 측면에서 어느 정도 유연성을 제공합니다. 시스템 관리자는 대상 노드에 로그인하여 변경한 후 간단히 서비스를 다시 시작할 수 있습니다. 이는 더 큰 시스템에는 좋지 않을 수 있습니다. 변경 사항 뒤에 흔적이 남지 않습니다. 변경 사항은 다른 사람의 눈으로 검토되지 않습니다. 변화의 원인이 무엇인지 알아내는 것은 어려울 수 있습니다. 테스트되지 않았습니다. 분산 시스템의 관점에서 관리자는 다른 노드 중 하나의 구성을 업데이트하는 것을 잊어버릴 수 있습니다.

(그런데 결국 텍스트 구성 파일을 사용하기 시작해야 한다면 동일한 결과를 생성할 수 있는 파서 + 유효성 검사기만 추가하면 됩니다. Config 유형을 입력하면 텍스트 구성을 사용하기에 충분합니다. 이는 또한 컴파일 시간 구성의 복잡성이 텍스트 기반 구성의 복잡성보다 조금 더 작다는 것을 보여줍니다. 왜냐하면 텍스트 기반 버전에서는 몇 가지 추가 코드가 필요하기 때문입니다.)

중앙 집중식 키-값 저장소는 애플리케이션 메타 매개변수를 배포하는 데 좋은 메커니즘입니다. 여기서 우리는 구성 값으로 간주하는 것이 무엇인지, 데이터만 무엇인지 생각해 볼 필요가 있습니다. 주어진 함수 C => A => B 우리는 일반적으로 거의 변하지 않는 값을 호출합니다. C "구성", 자주 변경되는 데이터 A - 데이터를 입력하면 됩니다. 구성은 데이터보다 먼저 기능에 제공되어야 합니다. A. 이 아이디어를 고려하면 구성 데이터와 단순한 데이터를 구별하는 데 사용할 수 있는 변경 빈도가 예상된다고 말할 수 있습니다. 또한 데이터는 일반적으로 하나의 소스(사용자)에서 가져오고 구성은 다른 소스(관리자)에서 가져옵니다. 초기화 과정 이후에 변경될 수 있는 매개변수를 처리하는 것은 애플리케이션의 복잡성을 증가시킵니다. 이러한 매개변수의 경우 전달 메커니즘, 구문 분석 및 유효성 검사, 잘못된 값 처리를 처리해야 합니다. 따라서 프로그램 복잡성을 줄이려면 런타임 시 변경될 수 있는 매개변수 수를 줄이는 것이 좋습니다(또는 아예 제거하는 것도 좋습니다).

이 게시물의 관점에서 우리는 정적 매개변수와 동적 매개변수를 구별해야 합니다. 서비스 로직이 런타임 시 일부 매개변수를 드물게 변경해야 하는 경우 이를 동적 매개변수라고 부를 수 있습니다. 그렇지 않으면 정적이며 제안된 접근 방식을 사용하여 구성할 수 있습니다. 동적 재구성을 위해서는 다른 접근 방식이 필요할 수 있습니다. 예를 들어, 분산 시스템의 개별 프로세스를 다시 시작하는 것과 유사한 방식으로 시스템의 일부가 새 구성 매개변수를 사용하여 다시 시작될 수 있습니다.
(저의 겸손한 의견은 시스템의 복잡성을 증가시키기 때문에 런타임 재구성을 피하는 것입니다.
프로세스 재시작에 대한 OS 지원에 의존하는 것이 더 간단할 수 있습니다. 하지만 항상 가능하지는 않을 수도 있습니다.)

때때로 사람들이 (다른 이유 없이) 동적 구성을 고려하게 만드는 정적 구성 사용의 중요한 측면 중 하나는 구성 업데이트 중 서비스 가동 중지 시간입니다. 실제로 정적 구성을 변경해야 하는 경우 새 값이 적용되도록 시스템을 다시 시작해야 합니다. 가동 중지 시간에 대한 요구 사항은 시스템마다 다르므로 그다지 중요하지 않을 수도 있습니다. 중요한 경우에는 시스템을 다시 시작할 수 있도록 미리 계획을 세워야 합니다. 예를 들어 다음을 구현할 수 있습니다. AWS ELB 연결 드레이닝. 이 시나리오에서는 시스템을 다시 시작해야 할 때마다 시스템의 새 인스턴스를 병렬로 시작한 다음 ELB를 해당 인스턴스로 전환하고 기존 시스템이 기존 연결 서비스를 완료하도록 합니다.

버전이 지정된 아티팩트 내부 또는 외부에서 구성을 유지하는 것은 어떻습니까? 아티팩트 내부에 구성을 유지한다는 것은 대부분의 경우 이 구성이 다른 아티팩트와 동일한 품질 보증 프로세스를 통과했음을 의미합니다. 따라서 구성의 품질이 좋고 신뢰할 수 있다고 확신할 수 있습니다. 반대로 별도의 파일에 구성하면 해당 파일을 변경한 사람과 이유에 대한 추적이 없음을 의미합니다. 이것이 중요합니까? 우리는 대부분의 생산 시스템에서 안정적이고 고품질 구성을 갖는 것이 더 낫다고 믿습니다.

아티팩트 버전을 통해 생성 시기, 포함된 값, 활성화/비활성화되는 기능, 구성의 각 변경을 담당한 사람을 확인할 수 있습니다. 아티팩트 내부에 구성을 유지하려면 약간의 노력이 필요할 수 있으며 이는 디자인 선택입니다.

장단점

여기서 우리는 제안된 접근 방식의 몇 가지 장점을 강조하고 몇 가지 단점을 논의하고 싶습니다.

장점

완전한 분산 시스템의 컴파일 가능한 구성 기능:

1. 구성의 정적 확인. 이는 유형 제약 조건에 따라 구성이 정확하다는 높은 수준의 확신을 제공합니다.
2. 풍부한 구성 언어. 일반적으로 다른 구성 접근 방식은 최대 변수 대체으로 제한됩니다.
   Scala를 사용하면 광범위한 언어 기능을 사용하여 구성을 더 좋게 만들 수 있습니다. 예를 들어 특성을 사용하여 기본값을 제공하고 개체를 사용하여 다른 범위를 설정할 수 있습니다. vals는 외부 범위(DRY)에서 한 번만 정의됩니다. 리터럴 시퀀스나 특정 클래스의 인스턴스를 사용하는 것이 가능합니다(Seq, Map등).
3. DSL. Scala는 DSL 작성자를 적절하게 지원합니다. 이러한 기능을 사용하면 보다 편리하고 최종 사용자에게 친숙한 구성 언어를 설정할 수 있으므로 최소한 도메인 사용자는 최종 구성을 읽을 수 있습니다.
4. 노드 전체의 무결성과 일관성. 전체 분산 시스템을 한 곳에서 구성할 때의 이점 중 하나는 모든 값이 엄격하게 한 번 정의된 다음 필요한 모든 곳에서 재사용된다는 것입니다. 또한 안전한 포트 선언을 입력하면 가능한 모든 올바른 구성에서 시스템 노드가 동일한 언어를 사용하도록 할 수 있습니다. 노드 간에는 명시적인 종속성이 있으므로 일부 서비스를 제공하는 것을 잊기 어렵습니다.
5. 높은 품질의 변경. 일반적인 PR 프로세스를 통해 구성 변경 사항을 전달하는 전반적인 접근 방식은 구성에서도 높은 품질 표준을 설정합니다.
6. 동시 구성 변경. 구성 자동 배포를 변경할 때마다 모든 노드가 업데이트되도록 합니다.
7. 애플리케이션 단순화. 애플리케이션은 구성을 구문 분석 및 검증하고 잘못된 구성 값을 처리할 필요가 없습니다. 이는 전체 애플리케이션을 단순화합니다. (구성 자체에 약간의 복잡성 증가가 있지만 이는 안전에 대한 의식적인 절충입니다.) 일반적인 구성으로 돌아가는 것은 매우 간단합니다. 누락된 부분을 추가하기만 하면 됩니다. 컴파일된 구성으로 시작하고 추가 부분의 구현을 나중에 연기하는 것이 더 쉽습니다.
8. 버전이 지정된 구성. 구성 변경이 동일한 개발 프로세스를 따르기 때문에 결과적으로 고유한 버전의 아티팩트를 얻게 됩니다. 필요한 경우 구성을 다시 전환할 수 있습니다. XNUMX년 전에 사용했던 구성을 배포할 수도 있으며 이는 정확히 동일한 방식으로 작동합니다. 안정적인 구성은 분산 시스템의 예측 가능성과 신뢰성을 향상시킵니다. 구성은 컴파일 타임에 수정되며 프로덕션 시스템에서는 쉽게 변조될 수 없습니다.
9. 모듈성. 제안된 프레임워크는 모듈식이며 모듈은 다양한 방식으로 결합될 수 있습니다.
   다양한 구성(설정/레이아웃)을 지원합니다. 특히 소규모 단일 노드 레이아웃과 대규모 다중 노드 설정이 가능합니다. 여러 생산 레이아웃을 갖는 것이 합리적입니다.
10. 테스트. 테스트 목적으로 모의 서비스를 구현하고 이를 유형 안전 방식의 종속성으로 사용할 수 있습니다. 모의품으로 교체된 다양한 부품을 갖춘 몇 가지 다른 테스트 레이아웃을 동시에 유지 관리할 수 있습니다.
11. 통합 테스트. 때때로 분산 시스템에서는 통합 테스트를 실행하기가 어렵습니다. 전체 분산 시스템의 안전한 구성을 입력하기 위해 설명된 접근 방식을 사용하면 단일 서버에서 모든 분산 부분을 제어 가능한 방식으로 실행할 수 있습니다. 상황을 흉내내는 것은 쉽습니다
    서비스 중 하나를 사용할 수 없게 된 경우.

단점

컴파일된 구성 접근 방식은 "일반" 구성과 다르며 모든 요구 사항에 적합하지 않을 수 있습니다. 컴파일된 구성의 몇 가지 단점은 다음과 같습니다.

1. 정적 구성. 모든 응용 프로그램에 적합하지 않을 수도 있습니다. 어떤 경우에는 모든 안전 조치를 우회하여 생산 시 구성을 신속하게 수정해야 할 필요가 있습니다. 이 접근 방식은 더 어렵습니다. 구성을 변경한 후에는 컴파일 및 재배포가 필요합니다. 이것이 특징이기도 하고 부담이기도 하다.
2. 구성 생성. 일부 자동화 도구에서 구성을 생성하는 경우 이 접근 방식에는 후속 컴파일이 필요합니다(결과적으로 실패할 수 있음). 이 추가 단계를 빌드 시스템에 통합하려면 추가 노력이 필요할 수 있습니다.
3. 악기. 오늘날 텍스트 기반 구성에 의존하는 도구가 많이 사용되고 있습니다. 그들 중 일부
   구성이 컴파일되면 적용되지 않습니다.
4. 사고방식의 전환이 필요합니다. 개발자와 DevOps는 텍스트 구성 파일에 익숙합니다. 구성을 컴파일한다는 아이디어가 그들에게는 이상하게 보일 수도 있습니다.
5. 컴파일 가능한 구성을 도입하기 전에 고품질 소프트웨어 개발 프로세스가 필요합니다.

구현된 예제에는 몇 가지 제한 사항이 있습니다.

1. 노드 구현에서 요구하지 않는 추가 구성을 제공하는 경우 컴파일러는 누락된 구현을 감지하는 데 도움이 되지 않습니다. 이 문제는 다음을 사용하여 해결할 수 있습니다. HList 또는 특성 및 케이크 패턴 대신 노드 구성을 위한 ADT(케이스 클래스).
2. 구성 파일에 몇 가지 상용구를 제공해야 합니다. (package, import, object 선언;
   override def기본값이 있는 매개변수의 경우). 이 문제는 DSL을 사용하여 부분적으로 해결될 수 있습니다.
3. 이 게시물에서는 유사한 노드 클러스터의 동적 재구성을 다루지 않습니다.

결론

이 게시물에서 우리는 유형이 안전한 방식으로 소스 코드에서 직접 구성을 표현하는 아이디어에 대해 논의했습니다. 이 접근 방식은 XML 및 기타 텍스트 기반 구성을 대체하여 많은 애플리케이션에서 사용될 수 있습니다. 우리 예제가 Scala로 구현되었음에도 불구하고 다른 컴파일 가능한 언어(Kotlin, C#, Swift 등)로 번역될 수도 있습니다. 새 프로젝트에서 이 접근 방식을 시도해 볼 수 있으며, 잘 맞지 않는 경우 기존 방식으로 전환할 수 있습니다.

물론 컴파일 가능한 구성에는 고품질 개발 프로세스가 필요합니다. 그 대가로 고품질의 견고한 구성을 제공할 것을 약속합니다.

이 접근 방식은 다양한 방식으로 확장될 수 있습니다.

1. 매크로를 사용하여 구성 유효성 검사를 수행하고 비즈니스 논리 제약 조건이 실패하는 경우 컴파일 타임에 실패할 수 있습니다.
2. 도메인 사용자 친화적인 방식으로 구성을 나타내기 위해 DSL을 구현할 수 있습니다.
3. 자동 구성 조정을 통한 동적 리소스 관리. 예를 들어, 클러스터 노드 수를 조정할 때 (1) 노드가 약간 수정된 구성을 얻도록 하고; (2) 클러스터 관리자는 새 노드 정보를 수신합니다.

감사

이 게시물의 초안을 보다 명확하게 만드는 데 도움이 되는 영감을 주는 피드백을 주신 Andrey Saksonov, Pavel Popov, Anton Nehaev에게 감사의 말씀을 전하고 싶습니다.

출처 : habr.com