🥇分散システムのコンパイルされた構成

分散システムの構成を操作するための興味深いメカニズムを XNUMX つ説明したいと思います。構成は、安全な型を使用してコンパイル言語 (Scala) で直接表現されます。この投稿では、そのような構成の例を示し、コンパイルされた構成を開発プロセス全体に実装するさまざまな側面について説明します。

(英語)

導入

信頼性の高い分散システムを構築するということは、すべてのノードが正しい構成を使用し、他のノードと同期することを意味します。 DevOps テクノロジー (terraform、ansible など) は通常、構成ファイル (多くの場合各ノードに固有) を自動的に生成するために使用されます。また、すべての通信ノードが同一のプロトコル (同じバージョンを含む) を使用していることを確認したいと考えています。そうしないと、分散システムに非互換性が組み込まれてしまいます。 JVM の世界では、この要件の XNUMX つの結果として、プロトコルメッセージを含む同じバージョンのライブラリをどこでも使用する必要があります。

分散システムのテストについてはどうでしょうか? もちろん、統合テストに進む前に、すべてのコンポーネントに単体テストがあることを前提としています。 (テスト結果を実行時に推定するには、テスト段階と実行時に同一のライブラリのセットを提供する必要もあります。)

統合テストを使用する場合、多くの場合、すべてのノードのどこでも同じクラスパスを使用する方が簡単です。実行時に同じクラスパスが使用されるようにするだけです。 (異なるクラスパスを使用して異なるノードを実行することは完全に可能ですが、これにより全体の構成が複雑になり、デプロイメントおよび統合テストが難しくなります。) この記事では、すべてのノードが同じクラスパスを使用することを前提としています。

構成はアプリケーションとともに進化します。私たちはバージョンを使用して、プログラム進化のさまざまな段階を識別します。構成の異なるバージョンも識別するのは論理的だと思われます。そして、設定自体をバージョン管理システムに置きます。運用環境に構成が XNUMX つしかない場合は、単純にバージョン番号を使用できます。多くの実稼働インスタンスを使用する場合は、いくつかのインスタンスが必要になります。
構成ブランチと、バージョンに加えて追加のラベル (ブランチの名前など)。このようにして、正確な構成を明確に識別できます。各構成識別子は、分散ノード、ポート、外部リソース、およびライブラリのバージョンの特定の組み合わせに一意に対応します。この記事では、ブランチが 1.2.3 つだけあり、ドットで区切られた XNUMX つの数字 (XNUMX) を使用して通常の方法で構成を識別できると仮定します。

最近の環境では、構成ファイルが手動で作成されることはほとんどありません。多くの場合、それらはデプロイメント中に生成され、その後は触れられなくなります (そのため、何も壊さないでください）。当然の疑問が生じます。なぜ設定を保存するために依然としてテキスト形式を使用するのでしょうか? 実行可能な代替案は、構成に通常のコードを使用し、コンパイル時チェックの恩恵を受ける機能のようです。

この投稿では、コンパイルされたアーティファクト内の構成を表すというアイデアを検討します。

コンパイルされた構成

このセクションでは、静的にコンパイルされた構成の例を示します。エコーサービスとエコーサービスクライアントという XNUMX つの単純なサービスが実装されています。これらXNUMXつのサービスをベースに、XNUMXつのシステムオプションを組み立てます。 XNUMX つのオプションでは、両方のサービスが同じノードに配置され、別のオプションでは、異なるノードに配置されます。

通常、分散システムには複数のノードが含まれます。何らかのタイプの値を使用してノードを識別できます 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)

ファントムの種類

コンパイル時にプロトコルを識別するには、クラス内で使用されない型パラメーターを使用します。この決定は、実行時にプロトコルインスタンスを使用しないという事実によるものですが、コンパイラーにプロトコルの互換性をチェックしてもらいたいと考えています。プロトコルを指定することで、不適切なサービスを依存関係として渡すことができなくなります。

一般的なプロトコルの XNUMX つは、Json シリアル化を使用した REST API です。

sealed trait JsonHttpRestProtocol[RequestMessage, ResponseMessage]

どこ RequestMessage - リクエストの種類、 ResponseMessage — 応答タイプ。
もちろん、必要な記述の正確さを提供する他のプロトコル記述を使用することもできます。

この投稿では、プロトコルの簡略化されたバージョンを使用します。

sealed trait SimpleHttpGetRest[RequestMessage, ResponseMessage]

ここで、リクエストは URL に追加される文字列であり、レスポンスは HTTP レスポンスの本文で返される文字列です。

サービス構成は、サービス名、ポート、依存関係によって記述されます。これらの要素は、Scala ではいくつかの方法で表現できます (たとえば、 HList-s、代数データ型)。この投稿では、Cake パターンを使用し、モジュールを次のように表します。 trait'ov。 (Cake パターンは、このアプローチの必須要素ではありません。これは、単に可能な実装の XNUMX つです。)

サービス間の依存関係は、ポートを返すメソッドとして表現できます。 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)
  }

エコーサービスを作成するために必要なのは、ポート番号と、ポートがエコープロトコルをサポートしていることを示すことだけです。特定のポートを指定しない場合もあります。理由は次のとおりです。特性を使用すると、実装せずにメソッドを宣言できます (抽象メソッド)。この場合、具体的な構成を作成するときに、コンパイラーは抽象メソッドの実装とポート番号を提供することを要求します。このメソッドを実装しているため、特定の構成を作成するときに、別のポートを指定できない場合があります。デフォルト値が使用されます。

クライアント設定では、エコーサービスへの依存関係を宣言します。

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

依存関係はエクスポートされたサービスと同じタイプです echoService。特に、エコークライアントでは同じプロトコルが必要です。したがって、XNUMX つのサービスを接続する場合、すべてが正しく動作することを確認できます。

サービスの実施

サービスを開始および停止するには関数が必要です。 (サービスを停止する機能はテストには重要です。) 繰り返しますが、そのような機能を実装するにはいくつかのオプションがあります (たとえば、構成タイプに基づいてタイプクラスを使用できます)。この投稿では、Cake パターンを使用します。クラスを使用してサービスを表現します 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](()))
  }

（Cm。ソースコード、他のサービスが実装されている - エコーサービス, エコークライアント
и ライフタイムコントローラー.)

ノードは、いくつかのサービスを起動できるオブジェクトです (リソースのチェーンの起動は Cake パターンによって保証されます)。

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

このノードに必要な構成の正確なタイプを指定していることに注意してください。特定のサービスに必要な構成タイプの XNUMX つを指定するのを忘れた場合、コンパイルエラーが発生します。また、必要なデータをすべて備えた適切なタイプのオブジェクトを提供しない限り、ノードを開始することはできません。

ホスト名解決

リモートホストに接続するには、実際の IP アドレスが必要です。アドレスが構成の残りの部分よりも後で判明する可能性があります。したがって、ノード ID をアドレスにマップする関数が必要です。

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

この関数を実装するにはいくつかの方法があります。

デプロイメント前にアドレスがわかった場合は、次のコードを使用して Scala コードを生成できます。
アドレスを指定してビルドを実行します。これにより、テストがコンパイルされて実行されます。
この場合、関数は静的に認識され、マッピングとしてコードで表現できます。 Map[NodeId, NodeAddress].
場合によっては、実際のアドレスはノードが起動した後でしか分からないことがあります。
この場合、他のノードよりも前に実行される「検出サービス」を実装することができ、すべてのノードがこのサービスに登録して他のノードのアドレスを要求します。
修正できれば /etc/hosts、その後、事前定義されたホスト名を使用できます（たとえば、 my-project-main-node и echo-backend）これらの名前をリンクするだけです
導入時に IP アドレスを使用します。

この投稿では、これらのケースについては詳しく検討しません。私たちのために
おもちゃの例では、すべてのノードが同じ IP アドレスを持つことになります。 127.0.0.1.

次に、分散システムの XNUMX つのオプションを検討します。

すべてのサービスを XNUMX つのノードに配置します。
また、エコーサービスとエコークライアントを別のノードでホストします。

の設定 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.
}

オブジェクトはクライアントとサーバーの両方の構成を実装します。有効期間設定も使用されるため、間隔が経過すると、 lifetime プログラムを終了します。 (Ctrl-C を押しても機能し、すべてのリソースが正しく解放されます。)

同じ構成および実装特性のセットを使用して、以下から構成されるシステムを作成できます。 XNUMX つの別々のノード:

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 が含まれます。このスキームのおかげで、ポート番号を XNUMX 回だけ指定するだけで、常に正しいポートを参照することが保証されます。

XNUMXつのシステムノードの実装

この構成では、同じサービス実装を変更せずに使用します。唯一の違いは、異なるサービスのセットを実装する XNUMX つのオブジェクトがあることです。

  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
  }

最初のノードはサーバーを実装しており、サーバーの構成のみが必要です。 XNUMX 番目のノードはクライアントを実装し、構成の別の部分を使用します。また、両方のノードでライフタイム管理が必要です。サーバーノードは停止するまで無期限に実行されます。 SIGTERMああ、しばらくするとクライアントノードが終了します。 Cm。ランチャーアプリ.

一般的な開発プロセス

この構成アプローチが開発プロセス全体にどのような影響を与えるかを見てみましょう。

構成は残りのコードとともにコンパイルされ、アーティファクト (.jar) が生成されます。構成を別のアーティファクトに置くのが理にかなっているようです。これは、同じコードに基づいて複数の構成を使用できるためです。ここでも、さまざまな構成ブランチに対応するアーティファクトを生成することが可能です。ライブラリの特定のバージョンへの依存関係は構成とともに保存され、そのバージョンの構成のデプロイを決定するたびに、これらのバージョンは永久に保存されます。

構成の変更はコードの変更に変わります。したがって、それぞれ
この変更は通常の品質保証プロセスでカバーされます。

バグトラッカーのチケット -> PR -> レビュー -> 関連ブランチとマージ ->
統合 -> 導入

コンパイルされた構成を実装すると、主に次のような結果が生じます。

構成は、分散システムのすべてのノードにわたって一貫性があります。すべてのノードが単一のソースから同じ構成を受信するためです。
XNUMX つのノードのみで構成を変更するのは問題があります。したがって、「構成のドリフト」が発生する可能性はほとんどありません。
構成に小さな変更を加えることがより困難になります。
ほとんどの構成変更は開発プロセス全体の一部として発生し、レビューの対象となります。

運用環境設定を保存するには別のリポジトリが必要ですか? この設定には、アクセスを制限したいパスワードやその他の機密情報が含まれる場合があります。これに基づいて、最終構成を別のリポジトリに保存することが合理的であると思われます。構成を XNUMX つの部分に分割できます。XNUMX つはパブリックにアクセス可能な構成設定を含み、もう XNUMX つは制限された設定を含みます。これにより、ほとんどの開発者が共通の設定にアクセスできるようになります。この分離は、デフォルト値を含む中間特性を使用することで簡単に実現できます。

可能なバリエーション

コンパイルされた構成をいくつかの一般的な代替構成と比較してみましょう。

ターゲットマシン上のテキストファイル。
一元化されたキーと値のストア (etcd/zookeeper).
プロセスを再起動せずに再構成/再起動できるプロセスコンポーネント。
アーティファクトとバージョン管理の外部に構成を保存します。

テキストファイルは、小さな変更に関して大きな柔軟性を提供します。システム管理者はリモートノードにログインし、適切なファイルに変更を加えてサービスを再起動できます。ただし、大規模システムの場合、そのような柔軟性は望ましくない場合があります。加えられた変更は他のシステムに痕跡を残しません。誰も変更をレビューしません。正確に誰がどのような理由で変更を行ったのかを判断することは困難です。変更はテストされません。システムが分散されている場合、管理者は他のノードに対応する変更を加えるのを忘れる可能性があります。

(コンパイルされた構成を使用しても、将来的にテキストファイルを使用できる可能性がなくなるわけではないことにも注意してください。出力と同じ型を生成するパーサーとバリデーターを追加するだけで十分です。 Config、テキストファイルを使用できます。コンパイルされた構成を持つシステムの複雑さは、テキストファイルを使用するシステムの複雑さよりも若干少ないことがすぐに分かります。テキストファイルには追加のコードが必要です。)

集中化されたキーと値のストアは、分散アプリケーションのメタパラメーターを配布するための優れたメカニズムです。何が構成パラメータであり、何が単なるデータなのかを判断する必要があります。関数を持たせましょう C => A => B、およびパラメータ C めったに変更されないデータ A - 頻繁。この場合、次のように言えます。 C - 設定パラメータ、および A - データ。構成パラメータは、一般にデータよりも変更頻度が低いという点でデータとは異なるようです。また、通常、データは XNUMX つのソース (ユーザー) から取得され、構成パラメータは別のソース (システム管理者) から取得されます。

めったに変更されないパラメータをプログラムを再起動せずに更新する必要がある場合、何らかの方法でパラメータを渡し、保存、解析、チェックし、不正な値を処理する必要があるため、プログラムが複雑になることがよくあります。したがって、プログラムの複雑さを軽減するという観点からは、プログラムの動作中に変更できるパラメーターの数を減らす (またはそのようなパラメーターをまったくサポートしない) ことが合理的です。

この記事では、静的パラメーターと動的パラメーターを区別します。サービスのロジックでプログラムの動作中にパラメーターを変更する必要がある場合、そのようなパラメーターを動的と呼びます。それ以外の場合、オプションは静的であり、コンパイルされた構成を使用して構成できます。動的再構成の場合、オペレーティングシステムのプロセスが再起動されるのと同じように、新しいパラメータを使用してプログラムの一部を再起動するメカニズムが必要になる場合があります。 (私たちの意見では、システムの複雑さが増すため、リアルタイムの再構成は避けることをお勧めします。可能であれば、プロセスの再起動には標準の OS 機能を使用することをお勧めします。)

動的再構成を検討させる静的構成の使用に関する重要な側面の XNUMX つは、構成の更新後にシステムが再起動するまでにかかる時間 (ダウンタイム) です。実際、静的構成を変更する必要がある場合は、新しい値を有効にするためにシステムを再起動する必要があります。ダウンタイムの問題は、システムによって重大度が異なります。場合によっては、負荷が最小限に抑えられるときに再起動をスケジュールできます。継続的なサービスを提供する必要がある場合は、次のように実装できます。 AWS ELB 接続のドレイン。同時に、システムを再起動する必要がある場合は、このシステムの並列インスタンスを起動し、バランサーをそれに切り替えて、古い接続が完了するのを待ちます。すべての古い接続が終了した後、システムの古いインスタンスをシャットダウンします。

ここで、アーティファクトの内部または外部に構成を保存する問題を考えてみましょう。構成をアーティファクト内に保存すると、少なくともアーティファクトのアセンブリ中に構成の正確さを検証する機会が得られます。構成が制御対象の成果物の範囲外にある場合、誰がこのファイルに変更を加えたのか、またその理由を追跡するのは困難です。それはどれくらい重要ですか? 私たちの意見では、多くの実稼働システムでは、安定した高品質の構成を持つことが重要です。

アーティファクトのバージョンにより、アーティファクトがいつ作成されたか、どのような値が含まれているか、どの機能が有効化/無効化されているか、および構成の変更の責任者を判断できます。もちろん、構成をアーティファクト内に保存するにはある程度の労力が必要なため、情報に基づいた決定を下す必要があります。

長所と短所

提案された技術の長所と短所について詳しく説明したいと思います。

利点

以下は、コンパイルされた分散システム構成の主な機能のリストです。

静的構成チェック。確実に確認できるようになります
構成は正しいです。
豊富な設定言語。通常、他の構成方法は最大でも文字列変数の置換に限定されます。 Scala を使用する場合、構成を改善するために幅広い言語機能を利用できます。たとえば、次のように使用できます
デフォルト値の特性、オブジェクトを使用してパラメータをグループ化すると、外側のスコープ内で XNUMX 回だけ宣言された vals (DRY) を参照できます。構成内で直接任意のクラスをインスタンス化できます (Seq, Map、カスタムクラス）。
DSL。 Scala には、DSL の作成を容易にする言語機能が多数あります。これらの機能を利用して、ターゲットユーザーグループにとってより便利な構成言語を実装して、少なくともドメインの専門家が構成を読み取れるようにすることができます。たとえば、スペシャリストは構成レビュープロセスに参加できます。
ノード間の整合性と同期性。分散システム全体の構成を XNUMX か所に保存する利点の XNUMX つは、すべての値が XNUMX 回だけ宣言され、必要なときに再利用できることです。ファントムタイプを使用してポートを宣言すると、ノードがすべての正しいシステム構成で互換性のあるプロトコルを使用していることが保証されます。ノード間に明示的な必須の依存関係があると、すべてのサービスが確実に接続されます。
高品質な変更。共通の開発プロセスを使用して構成を変更することで、構成についても高い品質基準を達成することができます。
構成の同時更新。構成変更後の自動システム展開により、すべてのノードが確実に更新されます。
アプリケーションの簡素化。アプリケーションは、解析、構成チェック、または不正な値の処理を必要としません。これにより、アプリケーションの複雑さが軽減されます。 (この例で見られる構成の複雑さの一部は、コンパイルされた構成の属性ではなく、より優れた型安全性を提供したいという要望による意識的な決定にすぎません。) 通常の構成に戻すのは非常に簡単です。不足しているものを実装するだけです。部品。したがって、たとえば、コンパイル済みの構成から開始し、本当に必要になるまで不要な部分の実装を延期することができます。
検証済みの構成。構成の変更は他の変更の通常の運命に従うため、取得する出力は一意のバージョンを持つアーティファクトになります。これにより、たとえば、必要に応じて以前のバージョンの構成に戻すことができます。 XNUMX 年前の構成を使用することもでき、システムはまったく同じように動作します。安定した構成により、分散システムの予測可能性と信頼性が向上します。構成はコンパイル段階で固定されるため、本番環境でそれを偽装することは非常に困難です。
モジュール性。提案されたフレームワークはモジュール式であり、モジュールをさまざまな方法で組み合わせてさまざまなシステムを作成できます。特に、一実施形態では単一ノードで実行するようにシステムを構成し、別の実施形態では複数ノードで実行するようにシステムを構成することができる。システムの実稼働インスタンス用にいくつかの構成を作成できます。
テスト中。個々のサービスをモックオブジェクトに置き換えることにより、テストに便利なシステムのいくつかのバージョンを取得できます。
統合テスト。分散システム全体を単一の構成にすることで、統合テストの一環として、制御された環境ですべてのコンポーネントを実行できるようになります。たとえば、一部のノードがアクセス可能になる状況をエミュレートするのは簡単です。

短所と制限

コンパイルされた構成は他の構成アプローチとは異なるため、一部のアプリケーションには適さない場合があります。以下にいくつかの欠点を示します。

静的構成。場合によっては、すべての保護メカニズムをバイパスして、運用環境の構成を迅速に修正する必要があります。このアプローチでは、さらに困難になる可能性があります。少なくとも、コンパイルと自動デプロイメントは依然として必要です。これは、このアプローチの便利な特徴であると同時に、場合によっては欠点でもあります。
構成の生成。構成ファイルが自動ツールによって生成された場合、ビルドスクリプトを統合するために追加の作業が必要になる場合があります。
ツール。現在、構成を操作するように設計されたユーティリティとテクニックはテキストファイルに基づいています。このようなユーティリティ/テクニックのすべてがコンパイルされた構成で利用できるわけではありません。
態度の変化が必要です。開発者と DevOps はテキストファイルに慣れています。構成をコンパイルするというアイデア自体が、多少予期せぬ、珍しいものであり、拒否される可能性があります。
高品質な開発プロセスが必要です。コンパイルされた構成を快適に使用するには、アプリケーションの構築とデプロイのプロセス (CI/CD) を完全に自動化する必要があります。そうしないとかなり不便になります。

コンパイルされた構成の概念とは関係のない、考慮された例のいくつかの制限についても詳しく説明します。

ノードで使用されない不要な構成情報を提供すると、コンパイラーは欠落している実装の検出に役立ちません。この問題は、Cake パターンを放棄し、より厳密なタイプを使用することで解決できます。たとえば、 HList または、構成を表す代数データ型 (ケースクラス)。
構成ファイル内に、構成自体に関係のない行があります: (package, import,オブジェクト宣言; override defはデフォルト値を持つパラメータを表します)。独自の DSL を実装すると、これを部分的に回避できます。さらに、他のタイプの構成 (XML など) もファイル構造に特定の制限を課します。
この記事では、同様のノードからなるクラスターの動的再構成については考慮していません。

まとめ

この投稿では、Scala 型システムの高度な機能を使用してソースコードで構成を表現するというアイデアを検討しました。このアプローチは、xml またはテキストファイルに基づく従来の構成方法の代わりとして、さまざまなアプリケーションで使用できます。この例は Scala で実装されていますが、同じアイデアを他のコンパイル言語 (Kotlin、C#、Swift など) に移すことができます。次のプロジェクトのいずれかでこのアプローチを試して、うまくいかない場合は、テキストファイルに進み、不足している部分を追加してください。

当然のことながら、コンパイルされた構成には高品質の開発プロセスが必要です。その代わりに、構成の高品質と信頼性が保証されます。

検討されたアプローチは次のように拡張できます。

マクロを使用してコンパイル時のチェックを実行できます。
DSL を実装すると、エンドユーザーがアクセスできる方法で構成を提示できます。
自動構成調整を使用して動的なリソース管理を実装できます。たとえば、クラスター内のノードの数を変更するには、(1) 各ノードがわずかに異なる構成を受け取る必要があります。 (2) クラスターマネージャーは新しいノードに関する情報を受け取りました。

感謝

草案記事に対する建設的な批判をしてくださった Andrei Saksonov、Pavel Popov、Anton Nekhaev に感謝したいと思います。

出所： habr.com

コンパイルされた分散システム構成

導入

コンパイルされた構成

一般的な開発プロセス

可能なバリエーション

長所と短所

利点

短所と制限

まとめ

感謝

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル