컴파일된 분산 시스템 구성

분산 시스템 구성 작업에 대한 흥미로운 메커니즘 하나를 말씀드리고 싶습니다. 구성은 안전한 유형을 사용하여 컴파일된 언어(Scala)로 직접 표현됩니다. 이 게시물에서는 이러한 구성의 예를 제공하고 컴파일된 구성을 전체 개발 프로세스에 구현하는 다양한 측면을 논의합니다.

(영어)

소개

안정적인 분산 시스템을 구축한다는 것은 모든 노드가 다른 노드와 동기화된 올바른 구성을 사용한다는 것을 의미합니다. DevOps 기술(terraform, ansible 등)은 일반적으로 구성 파일(종종 각 노드에 특정)을 자동으로 생성하는 데 사용됩니다. 또한 모든 통신 노드가 동일한 프로토콜(동일한 버전 포함)을 사용하고 있는지 확인하고 싶습니다. 그렇지 않으면 분산 시스템에 비호환성이 내장됩니다. JVM 세계에서 이 요구 사항의 한 가지 결과는 프로토콜 메시지가 포함된 동일한 버전의 라이브러리를 모든 곳에서 사용해야 한다는 것입니다.

분산 시스템을 테스트하는 것은 어떻습니까? 물론 통합 테스트로 넘어가기 전에 모든 구성 요소에 단위 테스트가 있다고 가정합니다. (테스트 결과를 런타임에 추정하려면 테스트 도중과 런타임에 동일한 라이브러리 세트도 제공해야 합니다.)

통합 테스트를 수행할 때 모든 노드의 모든 위치에서 동일한 클래스 경로를 사용하는 것이 더 쉬운 경우가 많습니다. 우리가 해야 할 일은 런타임에 동일한 클래스 경로가 사용되는지 확인하는 것뿐입니다. (다른 클래스 경로를 사용하여 다른 노드를 실행하는 것은 전적으로 가능하지만 이로 인해 전체 구성이 복잡해지고 배포 및 통합 테스트가 어려워집니다.) 이 게시물의 목적에 따라 모든 노드가 동일한 클래스 경로를 사용한다고 가정합니다.

구성은 애플리케이션과 함께 발전합니다. 우리는 버전을 사용하여 프로그램 발전의 다양한 단계를 식별합니다. 다양한 버전의 구성을 식별하는 것도 논리적인 것 같습니다. 그리고 구성 자체를 버전 제어 시스템에 배치합니다. 프로덕션에 구성이 하나만 있는 경우 간단히 버전 번호를 사용할 수 있습니다. 많은 프로덕션 인스턴스를 사용하는 경우 여러 개가 필요합니다.
버전 외에 구성 분기 및 추가 레이블(예: 분기 이름)이 포함됩니다. 이렇게 하면 정확한 구성을 명확하게 식별할 수 있습니다. 각 구성 식별자는 분산 노드, 포트, 외부 리소스 및 라이브러리 버전의 특정 조합에 고유하게 해당합니다. 이 게시물의 목적을 위해 우리는 분기가 하나만 있다고 가정하고 점으로 구분된 세 개의 숫자를 사용하여 일반적인 방법으로 구성을 식별할 수 있습니다(1.2.3).

현대 환경에서는 구성 파일이 수동으로 생성되는 경우가 거의 없습니다. 배포 중에 생성되어 더 이상 건드리지 않는 경우가 더 많습니다(그래서 아무것도 부수지 마세요). 자연스러운 질문이 생깁니다. 구성을 저장하기 위해 여전히 텍스트 형식을 사용하는 이유는 무엇입니까? 실행 가능한 대안은 구성을 위해 일반 코드를 사용하고 컴파일 시간 확인의 이점을 얻는 기능인 것 같습니다.

이 게시물에서는 컴파일된 아티팩트 내부의 구성을 표현하는 아이디어를 살펴보겠습니다.

컴파일된 구성

이 섹션에서는 정적 컴파일 구성의 예를 제공합니다. 두 가지 간단한 서비스, 즉 에코 서비스와 에코 서비스 클라이언트가 구현됩니다. 이 두 가지 서비스를 기반으로 두 가지 시스템 옵션이 구성됩니다. 한 옵션에서는 두 서비스가 모두 동일한 노드에 있고 다른 옵션에서는 서로 다른 노드에 있습니다.

일반적으로 분산 시스템에는 여러 노드가 포함됩니다. 특정 유형의 값을 사용하여 노드를 식별할 수 있습니다. NodeId:

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]]

세련된 유형

라이브러리 보기 세련된 и 내 보고. 간단히 말해서, 라이브러리를 사용하면 컴파일 타임에 확인되는 유형에 제약 조건을 추가할 수 있습니다. 이 경우 유효한 포트번호 값은 16비트 정수이다. 컴파일된 구성의 경우 개선된 라이브러리를 사용하는 것이 필수는 아니지만 구성을 확인하는 컴파일러의 기능을 향상시킵니다.

HTTP(REST) ​​프로토콜의 경우 포트 번호 외에도 서비스 경로가 필요할 수도 있습니다.

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

팬텀 유형

컴파일 타임에 프로토콜을 식별하기 위해 클래스 내에서 사용되지 않는 유형 매개변수를 사용합니다. 이 결정은 런타임에 프로토콜 인스턴스를 사용하지 않지만 컴파일러가 프로토콜 호환성을 확인하기를 원하기 때문입니다. 프로토콜을 지정하면 부적절한 서비스를 종속성으로 전달할 수 없습니다.

일반적인 프로토콜 중 하나는 Json 직렬화가 포함된 REST API입니다.

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

어디에서 RequestMessage — 요청 유형, ResponseMessage — 응답 유형.
물론 우리가 요구하는 설명의 정확성을 제공하는 다른 프로토콜 설명을 사용할 수도 있습니다.

이 게시물의 목적을 위해 우리는 프로토콜의 단순화된 버전을 사용합니다.

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

여기서 요청은 URL에 추가된 문자열이고 응답은 HTTP 응답 본문에 반환된 문자열입니다.

서비스 구성은 서비스 이름, 포트, 종속성으로 설명됩니다. 이러한 요소는 Scala에서 여러 가지 방법으로 표현될 수 있습니다(예: HList-s, 대수 데이터 유형). 이 게시물의 목적을 위해 케이크 패턴을 사용하고 다음을 사용하여 모듈을 나타냅니다. trait'ov. (케이크 패턴은 이 접근 방식의 필수 요소는 아닙니다. 단지 가능한 구현 중 하나일 뿐입니다.)

서비스 간의 종속성은 포트를 반환하는 메서드로 표현될 수 있습니다. EndPoint다른 노드의 것:

  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)
  }

에코 서비스를 생성하려면 포트 번호와 해당 포트가 에코 프로토콜을 지원한다는 표시만 있으면 됩니다. 특정 포트를 지정하지 않을 수도 있습니다. 왜냐하면... 특성을 사용하면 구현 없이 메서드(추상 메서드)를 선언할 수 있습니다. 이 경우 구체적인 구성을 생성할 때 컴파일러는 추상 메서드의 구현을 제공하고 포트 번호를 제공하도록 요구합니다. 메소드를 구현했기 때문에 특정 구성을 생성할 때 다른 포트를 지정하지 못할 수도 있습니다. 기본값이 사용됩니다.

클라이언트 구성에서 echo 서비스에 대한 종속성을 선언합니다.

  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 — 개별 효과를 결합할 수 있는 효과 유형 클래스(거의 모나드) 더 복잡한 응용 프로그램에서는 사용하는 것이 더 나은 것 같습니다. Monad/ConcurrentEffect.

이 함수 서명을 사용하여 여러 서비스를 구현할 수 있습니다. 예를 들어, 아무것도 하지 않는 서비스는 다음과 같습니다.

  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
}

이 노드에 필요한 정확한 구성 유형을 지정하고 있습니다. 특정 서비스에 필요한 구성 유형 중 하나를 지정하는 것을 잊어버리면 컴파일 오류가 발생합니다. 또한 필요한 모든 데이터와 함께 적절한 유형의 객체를 제공하지 않으면 노드를 시작할 수 없습니다.

호스트 이름 확인

원격 호스트에 연결하려면 실제 IP 주소가 필요합니다. 주소는 나머지 구성보다 나중에 알려질 수도 있습니다. 따라서 노드 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. 그리고 에코 서비스와 에코 클라이언트를 다른 노드에서 호스팅합니다.

구성 노드 XNUMX개:

단일 노드 구성

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.
}

개체는 클라이언트와 서버 모두의 구성을 구현합니다. TTL(Time-To-Live) 구성도 사용되므로 간격이 지나면 lifetime 프로그램을 종료합니다. (Ctrl-C도 작동하여 모든 리소스를 올바르게 해제합니다.)

동일한 구성 및 구현 특성 세트를 사용하여 다음으로 구성된 시스템을 만들 수 있습니다. 두 개의 별도 노드:

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'om, 클라이언트 노드는 일정 시간 후에 종료됩니다. 센티미터. 런처 앱.

일반적인 개발 프로세스

이 구성 접근 방식이 전체 개발 프로세스에 어떤 영향을 미치는지 살펴보겠습니다.

구성은 나머지 코드와 함께 컴파일되고 아티팩트(.jar)가 생성됩니다. 구성을 별도의 아티팩트에 넣는 것이 합리적일 것 같습니다. 이는 동일한 코드를 기반으로 여러 구성을 가질 수 있기 때문입니다. 다시 말하지만, 다양한 구성 분기에 해당하는 아티팩트를 생성할 수 있습니다. 특정 버전의 라이브러리에 대한 종속성은 구성과 함께 저장되며 해당 버전은 해당 버전의 구성을 배포하기로 결정할 때마다 영원히 저장됩니다.

모든 구성 변경은 코드 변경으로 이어집니다. 그러므로 각
변경 사항은 일반적인 품질 보증 프로세스에 따라 처리됩니다.

버그 트래커 티켓 -> 홍보 -> 검토 -> 관련 브랜치와 병합 ->
통합 -> 배포

컴파일된 구성 구현의 주요 결과는 다음과 같습니다.

1. 구성은 분산 시스템의 모든 노드에서 일관됩니다. 모든 노드가 단일 소스로부터 동일한 구성을 수신하기 때문입니다.

2. 노드 중 하나만 구성을 변경하는 것은 문제가 있습니다. 따라서 "구성 드리프트"가 발생하지 않을 가능성이 높습니다.

3. 작은 구성 변경이 더 어려워집니다.

4. 대부분의 구성 변경은 전체 개발 프로세스의 일부로 발생하며 검토 대상이 됩니다.

프로덕션 구성을 저장하려면 별도의 저장소가 필요합니까? 이 구성에는 액세스를 제한하려는 비밀번호 및 기타 민감한 정보가 포함될 수 있습니다. 이를 토대로 최종 구성을 별도의 저장소에 저장하는 것이 타당할 것으로 보입니다. 구성을 두 부분으로 분할할 수 있습니다. 하나는 공개적으로 액세스 가능한 구성 설정을 포함하고 다른 하나는 제한된 설정을 포함합니다. 이를 통해 대부분의 개발자는 일반 설정에 액세스할 수 있습니다. 이러한 분리는 기본값이 포함된 중간 특성을 사용하여 쉽게 달성할 수 있습니다.

가능한 변형

컴파일된 구성을 몇 가지 일반적인 대안과 비교해 보겠습니다.

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

텍스트 파일은 작은 변경 사항에도 상당한 유연성을 제공합니다. 시스템 관리자는 원격 노드에 로그인하여 적절한 파일을 변경하고 서비스를 다시 시작할 수 있습니다. 그러나 대규모 시스템의 경우 이러한 유연성은 바람직하지 않을 수 있습니다. 변경 사항은 다른 시스템에 흔적을 남기지 않습니다. 아무도 변경 사항을 검토하지 않습니다. 정확히 누가 어떤 이유로 변경을 했는지 파악하기는 어렵습니다. 변경 사항은 테스트되지 않습니다. 시스템이 분산된 경우 관리자는 다른 노드에서 해당 변경을 수행하는 것을 잊어버릴 수 있습니다.

(또한 컴파일된 구성을 사용한다고 해서 나중에 텍스트 파일을 사용할 가능성이 닫히는 것은 아닙니다. 출력과 동일한 유형을 생성하는 파서 및 유효성 검사기를 추가하는 것으로 충분합니다. Config, 텍스트 파일을 사용할 수 있습니다. 컴파일된 구성을 사용하는 시스템의 복잡성은 텍스트 파일을 사용하는 시스템의 복잡성보다 다소 적습니다. 텍스트 파일에는 추가 코드가 필요합니다.)

중앙 집중식 키-값 저장소는 분산 애플리케이션의 메타 매개변수를 배포하기 위한 좋은 메커니즘입니다. 구성 매개변수가 무엇인지, 데이터가 무엇인지 결정해야 합니다. 함수를 하나 가지자 C => A => B및 매개변수 C 거의 변경되지 않으며 데이터 A - 자주. 이 경우에 우리는 이렇게 말할 수 있습니다. C - 구성 매개변수 및 A - 데이터. 구성 매개변수는 일반적으로 데이터보다 덜 자주 변경된다는 점에서 데이터와 다른 것으로 보입니다. 또한 데이터는 일반적으로 한 소스(사용자)에서 가져오고 구성 매개변수는 다른 소스(시스템 관리자)에서 가져옵니다.

프로그램을 다시 시작하지 않고 거의 변경되지 않는 매개변수를 업데이트해야 하는 경우, 어떻게든 매개변수를 전달하고, 잘못된 값을 저장하고, 구문 분석하고 확인하고, 처리해야 하기 때문에 프로그램이 복잡해질 수 있습니다. 따라서, 프로그램의 복잡도를 줄이는 관점에서는, 프로그램 동작 중에 변경될 수 있는 매개변수의 수를 줄이는 것(혹은 그러한 매개변수를 전혀 지원하지 않는 것)이 합리적이다.

이 게시물의 목적에 따라 정적 매개변수와 동적 매개변수를 구분하겠습니다. 서비스 논리로 인해 프로그램 작동 중에 매개변수를 변경해야 하는 경우 해당 매개변수를 동적이라고 부릅니다. 그렇지 않으면 옵션은 정적이며 컴파일된 구성을 사용하여 구성할 수 있습니다. 동적 재구성의 경우 운영 체제 프로세스를 다시 시작하는 방법과 유사하게 새 매개변수를 사용하여 프로그램의 일부를 다시 시작하는 메커니즘이 필요할 수 있습니다. (실시간 재구성은 시스템의 복잡성을 증가시키므로 피하는 것이 좋습니다. 가능하다면 프로세스를 다시 시작하기 위해 표준 OS 기능을 사용하는 것이 좋습니다.)

사람들이 동적 재구성을 고려하게 만드는 정적 구성 사용의 중요한 측면 중 하나는 구성 업데이트(다운타임) 후 시스템을 재부팅하는 데 걸리는 시간입니다. 실제로 정적 구성을 변경해야 하는 경우 새 값을 적용하려면 시스템을 다시 시작해야 합니다. 가동 중지 시간 문제는 시스템마다 심각도가 다릅니다. 어떤 경우에는 로드가 최소일 때 재부팅을 예약할 수 있습니다. 지속적인 서비스 제공이 필요한 경우 구현할 수 있습니다. AWS ELB 연결 드레이닝. 동시에 시스템을 재부팅해야 할 때 이 시스템의 병렬 인스턴스를 시작하고 밸런서를 이 시스템으로 전환한 다음 이전 연결이 완료될 때까지 기다립니다. 이전 연결이 모두 종료된 후 시스템의 이전 인스턴스를 종료합니다.

이제 아티팩트 내부 또는 외부에 구성을 저장하는 문제를 고려해 보겠습니다. 구성을 아티팩트 내부에 저장했다면 적어도 아티팩트를 조립하는 동안 구성의 정확성을 확인할 기회가 있었습니다. 구성이 제어된 아티팩트 외부에 있는 경우 이 파일을 변경한 사람과 그 이유를 추적하기 어렵습니다. 얼마나 중요합니까? 우리의 의견으로는 많은 생산 시스템에서 안정적이고 고품질의 구성을 갖는 것이 중요합니다.

아티팩트 버전을 사용하면 생성 시기, 포함된 값, 활성화/비활성화되는 기능, 구성 변경에 대한 책임이 있는 사람을 결정할 수 있습니다. 물론 구성을 아티팩트 내부에 저장하려면 약간의 노력이 필요하므로 정보를 바탕으로 결정을 내려야 합니다.

찬반 양론

제안된 기술의 장단점에 대해 이야기하고 싶습니다.

장점

다음은 컴파일된 분산 시스템 구성의 주요 기능 목록입니다.

1. 정적 구성 확인. 확신할 수 있게 해준다
   구성이 정확합니다.
2. 풍부한 구성 언어. 일반적으로 다른 구성 방법은 최대 문자열 변수 대체으로 제한됩니다. Scala를 사용하면 구성을 개선하기 위해 다양한 언어 기능을 사용할 수 있습니다. 예를 들어 우리는 다음을 사용할 수 있습니다.
   기본값에 대한 특성, 객체를 사용하여 매개변수를 그룹화하면 둘러싸는 범위에서 한 번만 선언된(DRY) 값을 참조할 수 있습니다. 구성 내에서 직접 모든 클래스를 인스턴스화할 수 있습니다(Seq, Map, 사용자 정의 클래스).
3. DSL. Scala에는 DSL을 더 쉽게 만들 수 있는 다양한 언어 기능이 있습니다. 이러한 기능을 활용하고 대상 사용자 그룹에 보다 편리한 구성 언어를 구현하여 최소한 도메인 전문가가 구성을 읽을 수 있도록 하는 것이 가능합니다. 예를 들어 전문가는 구성 검토 프로세스에 참여할 수 있습니다.
4. 노드 간 무결성 및 동기화. 전체 분산 시스템의 구성을 단일 지점에 저장하는 것의 장점 중 하나는 모든 값이 정확히 한 번 선언된 다음 필요할 때마다 재사용된다는 것입니다. 팬텀 유형을 사용하여 포트를 선언하면 노드가 모든 올바른 시스템 구성에서 호환 가능한 프로토콜을 사용하고 있음을 보장합니다. 노드 간에 명시적인 필수 종속성이 있으면 모든 서비스가 연결됩니다.
5. 고품질의 변화. 공통 개발 프로세스를 사용하여 구성을 변경하면 구성에 대한 높은 품질 표준을 달성하는 것도 가능합니다.
6. 동시 구성 업데이트. 구성 변경 후 자동 시스템 배포를 통해 모든 노드가 업데이트됩니다.
7. 애플리케이션 단순화. 애플리케이션에서는 구문 분석, 구성 확인 또는 잘못된 값 처리가 필요하지 않습니다. 이렇게 하면 애플리케이션의 복잡성이 줄어듭니다. (이 예제에서 관찰된 구성 복잡성 중 일부는 컴파일된 구성의 속성이 아니라 더 큰 유형 안전성을 제공하려는 욕구에 따른 의식적인 결정일 뿐입니다.) 일반적인 구성으로 돌아가는 것은 매우 쉽습니다. 누락된 부분을 구현하기만 하면 됩니다. 부속. 따라서 예를 들어 컴파일된 구성으로 시작하여 실제로 필요할 때까지 불필요한 부분의 구현을 연기할 수 있습니다.
8. 확인된 구성. 구성 변경은 다른 변경의 일반적인 운명을 따르기 때문에 우리가 얻는 출력은 고유한 버전의 아티팩트입니다. 예를 들어 필요한 경우 이를 통해 이전 버전의 구성으로 돌아갈 수 있습니다. XNUMX년 전의 구성을 사용할 수도 있으며 시스템은 정확히 동일하게 작동합니다. 안정적인 구성은 분산 시스템의 예측 가능성과 신뢰성을 향상시킵니다. 구성은 컴파일 단계에서 고정되므로 프로덕션에서 이를 위조하는 것은 매우 어렵습니다.
9. 모듈성. 제안된 프레임워크는 모듈식이며 모듈을 다양한 방식으로 결합하여 다양한 시스템을 만들 수 있습니다. 특히, 한 실시예에서는 단일 노드에서 실행되고 다른 실시예에서는 여러 노드에서 실행되도록 시스템을 구성할 수 있습니다. 시스템의 프로덕션 인스턴스에 대해 여러 구성을 생성할 수 있습니다.
10. 테스트. 개별 서비스를 모의 개체로 대체하면 테스트에 편리한 여러 버전의 시스템을 얻을 수 있습니다.
11. 통합 테스트. 전체 분산 시스템에 대해 단일 구성을 사용하면 통합 테스트의 일부로 통제된 환경에서 모든 구성 요소를 실행할 수 있습니다. 예를 들어 일부 노드에 액세스할 수 있는 상황을 에뮬레이트하는 것은 쉽습니다.

단점 및 제한 사항

컴파일된 구성은 다른 구성 접근 방식과 다르며 일부 애플리케이션에는 적합하지 않을 수 있습니다. 다음은 몇 가지 단점입니다.

1. 정적 구성. 때로는 모든 보호 메커니즘을 우회하여 프로덕션 환경에서 구성을 신속하게 수정해야 하는 경우도 있습니다. 이 접근 방식을 사용하면 더 어려울 수 있습니다. 최소한 컴파일과 자동 배포는 여전히 필요합니다. 이는 접근 방식의 유용한 기능인 동시에 어떤 경우에는 단점이기도 합니다.
2. 구성 생성. 자동 도구로 구성 파일을 생성한 경우 빌드 스크립트를 통합하기 위해 추가 노력이 필요할 수 있습니다.
3. 도구. 현재 구성 작업을 위해 설계된 유틸리티와 기술은 텍스트 파일을 기반으로 합니다. 이러한 유틸리티/기술 중 일부는 컴파일된 구성에서 사용할 수 없습니다.
4. 태도의 변화가 필요합니다. 개발자와 DevOps는 텍스트 파일에 익숙합니다. 구성을 컴파일한다는 아이디어는 다소 예상치 못한 이례적일 수 있으며 거부를 유발할 수 있습니다.
5. 고품질의 개발 프로세스가 필요합니다. 컴파일된 구성을 편안하게 사용하려면 애플리케이션(CI/CD) 구축 및 배포 프로세스의 전체 자동화가 필요합니다. 그렇지 않으면 상당히 불편할 것입니다.

또한 컴파일된 구성의 아이디어와 관련이 없는 고려된 예의 여러 가지 제한 사항에 대해 살펴보겠습니다.

1. 노드에서 사용되지 않는 불필요한 구성 정보를 제공하면 컴파일러는 누락된 구현을 감지하는 데 도움을 주지 않습니다. 이 문제는 케이크 패턴을 버리고 보다 엄격한 유형을 사용하여 해결할 수 있습니다. 예를 들어, HList 또는 구성을 나타내는 대수적 데이터 유형(케이스 클래스)입니다.
2. 구성 파일에는 구성 자체와 관련되지 않은 줄이 있습니다. (package, import,객체 선언; override def기본값이 있는 매개변수의 경우). 자체 DSL을 구현하면 이 문제를 부분적으로 피할 수 있습니다. 또한 다른 유형의 구성(예: XML)도 파일 구조에 특정 제한을 적용합니다.
3. 이 게시물의 목적에 따라 유사한 노드 클러스터의 동적 재구성을 고려하지 않습니다.

결론

이 게시물에서 우리는 Scala 유형 시스템의 고급 기능을 사용하여 소스 코드에서 구성을 표현하는 아이디어를 탐구했습니다. 이 접근 방식은 XML 또는 텍스트 파일을 기반으로 하는 기존 구성 방법을 대체하여 다양한 애플리케이션에서 사용할 수 있습니다. 우리의 예제는 Scala로 구현되었지만 동일한 아이디어가 다른 컴파일된 언어(예: Kotlin, C#, Swift 등)로 옮겨질 수 있습니다. 다음 프로젝트 중 하나에서 이 접근 방식을 시도해 볼 수 있으며, 작동하지 않으면 텍스트 파일로 이동하여 누락된 부분을 추가하세요.

당연히 컴파일된 구성에는 고품질 개발 프로세스가 필요합니다. 그 대가로 구성의 높은 품질과 신뢰성이 보장됩니다.

고려된 접근 방식은 다음과 같이 확장될 수 있습니다.

1. 매크로를 사용하여 컴파일 타임 검사를 수행할 수 있습니다.
2. DSL을 구현하여 최종 사용자가 액세스할 수 있는 방식으로 구성을 제공할 수 있습니다.
3. 자동 구성 조정을 통해 동적 리소스 관리를 구현할 수 있습니다. 예를 들어, 클러스터의 노드 수를 변경하려면 (1) 각 노드가 약간 다른 구성을 받아야 합니다. (2) 클러스터 관리자는 새 노드에 대한 정보를 받았습니다.

감사의 말

나는 초안 기사에 대한 건설적인 비판에 대해 Andrei Saksonov, Pavel Popov 및 Anton Nekhaev에게 감사를 표하고 싶습니다.

출처 : habr.com