스프링부트 클러스터화 하기 by kotlin

Spring Boot Cloud

SpringBoot Cloud는 쿠버가 표준화 되기전까지 마이크로 서비스 아키텍처를 지원하는 매력적인 장치가 많이있었으나

쿠버클러스터 내에서도 상호연동해 더 매력적인 요소가 될수도 있겠지만~ 애매하게 겹치는 부분때문에  비슷한요소를 Java기반에 서버를 하나더 운영해야한다는 것은 부담이 될수 있습니다.

쿠버도입시 대체가능한 Spring Boot Cloud요소

• 쿠버는 사실상 표준이 되었으며~ 쿠버등장이전 Spring Cloud가 지원하는 장치는 매력적임에 분명합니다. 

파편화된 모놀리스

때때로 "파편화된 모놀리스"라고 불리는 안티 패턴도 있습니다. 서로 독립적으로 빌드되고 배포되는 여러 서비스가 있지만, 공유 클러스터, 서비스 API 호출에 대한 공유 코드 및 종속성 또는 공유 데이터베이스 스키마와 같이 이를 매우 위험하게 만드는 긴밀한 결합이 있습니다. 코드와 배포 단위의 물리적 분리로 인해 자율성에 대한 잘못된 감각이 있지만, 한 서비스의 구현 변경 사항이 다른 서비스의 동작으로 누출되어 문제가 발생할 가능성이 높습니다.

이런 상황에 처한 조직은 종종 여러 서비스의 배포를 중앙에서 조정하려고 시도하여 대응하는데, 이때는 마이크로서비스의 주요 이점을 잃고 비용을 떠안게 됩니다. 실제로 분리할 수 없는 것들을 별도로 빌드하고 배포하는 중간 상태에 있습니다. 어떤 사람들은 이렇게 하고, 어떤 사람들은 이를 작동하게 만들지만, 이는 권장할 만한 일이 아니며 신중하게 관리해야 합니다.

• 싱글톤 확장
  • 단일어플리케이션에서 싱글톤패턴으로 작성된 기능은 중복수행을 하게됩니다. 이 모듈이 일정산이고 중복작동하면 비즈니스의 치명적인 결함을 가져올수 있습니다.
• 세션확장
  
  • 어플리케이션이 수평확장되지만 어플리케이션간 정보를 공유하지 못함으로 세션을 중앙관리할 외부장치를 도입하게 됩니다.
• 단일지점 병목
  • RDB단일지점 병목현상이 빠르게 증가합니다. 이때도 Nosql을 포함 다양한 외부장치를 도입하게 됩니다.

모놀리식 확장의 대부분의 문제는 설계없이 즉각 도입한 장치를 사용하고 파편화된 저장소를 계속 만들어가면서  파편화되는 모놀리식을 양산하는데 있으며 마치 이것이

마이크로 서비스의 확장으로 착각하는 경우가 있습니다.

Akka Cluster의 경우 모놀리식으로도 구성이 가능하며 필요하면 분리작동 시킬수 있습니다. 여기서는 모놀리식이란 표현보다 StandAlone으로 작동도 하고 필요하면 특정기능을 분산배치할수도 있는

AkkaCluster의 특징을 살펴보겠습니다.

AkkaCluster 마이크로서비스 특징

경계를 구분하고 분산처리가능 한 클러스터 시스템이 StandAlone 로 구성이 가능하며, 필요하면 특정 기능만 독립적으로 분리 작동시킬수도 있습니다.

전통적인 모놀리식이 확장됨에 따라 어떠한 요소가 필요로하게 되는지 먼저 살펴보겠습니다.

모놀리식으로 구성후 코드의 변경없이 단일지점처리/분산처리를 구성요소 변경만으로 확장할수 있는것이 AkkaCluster의 장점입니다.

모놀리식의 가장 큰장점은 로컬에서 전체가 작동되며 디버깅도 가능하다란 점입니다. 이 지점이 개발을 가속화하는 모놀리식의 특징중 하나입니다.

로컬 디벙깅이 가능하다란점은 유닛테스트로 확장할수도 있다란점이며, 모놀리식의 장점을 잃은 파편화된 모놀리식은 대부분 디버깅능력과 함께 유닛테스트 방법까지 함께 잃게되는 단점이있습니다.

클라우드의 발전과 함께 PaaS를 채택해 로컬에서 수행못하게 되는 경우도 있을수 있지만  로컬에서 AllinOne 작동되고 디버깅되는 StandAlone 방법을 먼저 준비하고

클러스터화된 멀티노드를 유닛테스트 할수 있는 방법까지 살펴보겠습니다.

SpringBoot에 AkkaCluster 탑재하기

AkkaConiguration 작성

• 단일로 작성된 어플리케이션에 akka.conf를 적용시키면서 동일저장소 다른 역할의 Role을 수행할수 있습니다.
• 액터의 구성은 DI가 아닌 계층형 구조를 따르게 됩니다. Cluster 역할을 할 MainStage(with AkkaClusterSystem)를 이 단계에서 생성합니다.
  • AkkaSystem이 만든 객체를 RestAPI가 사용하게끔 하려면 이 곳에서 코드작성해 API에서 이용할수 있습니다.

전체코드 : https://github.com/psmon/kopring-reactive-labs/tree/main/KotlinBootReactiveLabs/src/main/kotlin/org/example/kotlinbootreactivelabs/config

MainStage작성

• AbstractBehavior를 상속받는 일반적인 TypedActor를 생성합니다.
  • 지정되는 템플릿은 처리가능한 이벤트 유형입니다.

전체 코드 : https://github.com/psmon/kopring-reactive-labs/tree/main/KotlinBootReactiveLabs/src/main/kotlin/org/example/kotlinbootreactivelabs/actor

MultiNode Runner 작성

 전체 작동을 확인을 할수 있는 장치를 초기에 준비하지 못해 각각 개발된 서비스가 통합되기전 개선활동을 확인을 못하는데 있으며 이 부분은 개발가속도를 느리게 하는 마이크로서비스의 단점이 될수도 있습니다.

MultiNode를 로컬에서 구성해 상호연동을 확인하는것은 중요하며 도커의 등장으로 이 부분은 이제 더이상 단점이 아닌 마이크로서비스를 채택했을때 필수로 해야하는 영역이 되었습니다.

• DockerCompose를 이용 멀티 작동을 준비해야하는것은 필수이며, AkkaCluster를 Multi Mode로 작동시킬수도 있습니다.
• CI/CD를 위해 자신이 작성한 어플리케이션의 도커빌드및 이미지 최적화는 이제 누구에게 맡기는 것이 아닌 개발Self의 영역이 되었습니다.
  • 도커가 확산되기 전, 그 분야에 전문가에게 빌드스크립트 요청을 하는경우도 있었겠지만  선택이 아닌 필수입니다.

전체코드 : https://github.com/psmon/kopring-reactive-labs/blob/main/KotlinBootReactiveLabs/DOCKER.MD

Gradle Multi Runner

### Standalone

``` shell
./gradlew bootRun -PserverPort=9090 -PclusterConfig=standalone
```

### Seed Node
``` shell
./gradlew bootRun -PserverPort=9090 -PclusterConfig=lighthouse
```

### Node1
``` shell
./gradlew bootRun -PserverPort=9091 -PclusterConfig=cluster1
```

### Node2
``` shell
./gradlew bootRun -PserverPort=9092 -PclusterConfig=cluster2
```

build.gradle.kts

tasks.named<org.springframework.boot.gradle.tasks.run.BootRun>("bootRun") {
    doFirst {
        val args = mutableListOf<String>()
        if (project.hasProperty("serverPort")) {
            args.add("-Dserver.port=${project.property("serverPort")}")
        }
        if (project.hasProperty("clusterConfig")) {
            args.add("-DCluster=${project.property("clusterConfig")}")
        }
        if (args.isNotEmpty()) {
            jvmArgs = args
        }
    }
}

Akka가 SpringBoot에 통합될수 있는 이유는 Akka는 프레임워크가 아니라 툴킷으로 분류되며 , Spring이 제공하는 스레드 영역이아닌

독립구성되고 분리된 영역에서 작동되며 자바 비동기처리 활용하면서 상호연동될수 있습니다.

초반 구성하는것에 다소 손이 많이가 초기 셋팅과정에 난이도가 있지만 이제 클러스터에서 유용한 장치들을 몇가지 살펴보겠습니다.

SigleTone Cluster

단일 어플리케이션에서 단 하나만 작동시켜야하는 싱글톤 패턴을 이용하는 DI는 유용합니다. 단일 시스템내에서 단하나만 작동하기때문입니다.

하지만 이것을 복수개의 어플리케이션으로 확장했을때 클러스터내에서 단 하나만 작동하도록 하려면 배치시스템으로 분리하거나 독립구성을 해야합니다.

Akka 싱글톤 클러스터는 작성한 코드가 단 하나의 노드에서만 작동되도록 보장을 하고~ 해당 노드가 Crash되었을때 대체 노드로 작동이 변경이되는 2중화 기능도 자연스럽게 적용할수 있습니다.

이러한 기능을 분리하기위해 기존작성된 코드를 그대로 유지할수 있으며~ 필요한것은 단지 클러스터 배치옵션을 지정하는것 뿐입니다.

Cluster Config

# cluster1.conf
  akka.cluster {
    seed-nodes = ["pekko://ClusterSystem@127.0.0.1:2551"]
    roles = ["seed", "helloA", "shard"]
  }
pekko.cluster.singleton {
  # The actor name of the child singleton actor.
  singleton-name = "singleton"
  # Singleton among the nodes tagged with specified role.
  # If the role is not specified it's a singleton among all nodes in the cluster.
  role = "helloA"
}

# cluster2.conf
akka.cluster {
    seed-nodes = ["pekko://ClusterSystem@127.0.0.1:2551"]
    roles = ["helloB", "shard"]
  }

• 싱글톤 기능을 수행하는 역할노드가 helloA 라고 지정하는것으로 싱글톤클러스터 기능은 해당노드에서만 작동되며~ 나머지 노드에서는 해당 기능을 이용할수 있습니다.
• Seed노드는 일반적으로 주키퍼와 같은 기능을 수행하는 Discovery역할을 하는 노드로 도메인로직 없는 노드를 지정하는것이 권장되며 여기서는 자기자신에게 Seed역할을 부여함으로 2Node로만 Cluster 테스트 수행이 가능합니다.

Cluster UnitTest

• ActorTestKit은 유닛테스트 환경에서 AkkaSystem의 환경을 동일하게 구동합니다. 
• 설정파일을 통해 각각 다른 역할을 수행하는 멀티노드를 구성할수 있게됩니다.

유닛테스트 코드작성

    @Test
    fun testSingleCluster(){

        var givenInItCount = 5

        val testProbe = nodeA.createTestProbe<CounterState>()
        val testProbe2 = nodeB.createTestProbe<CounterState>()

        val sigleton1:ClusterSingleton = ClusterSingleton.get(nodeA.system())

        var proxy1:ActorRef<CounterCommand> = sigleton1.init(SingletonActor.of(CounterActor.create("singleId"), "GlobalCounter"))

        val sigleton2:ClusterSingleton = ClusterSingleton.get(nodeB.system())

        var proxy2:ActorRef<CounterCommand> = sigleton2.init(SingletonActor.of(CounterActor.create("singleId"), "GlobalCounter"))

        proxy1.tell(Increment(3))

        proxy1.tell(GetCount(testProbe.ref()))

        testProbe.expectMessage(CounterState(3 + givenInItCount))

        proxy2.tell(Increment(2))

        proxy2.tell(GetCount(testProbe2.ref()))

        testProbe2.expectMessage(CounterState(5 + givenInItCount))
    }

• 카운트를 증가하고~ 현재 카운트를 알려주는 단순한 액터를 싱글톤 클러스터화 했습니다.
• 각각 다른노드가 카운트를 증가시키고 값을 획득하더라도 ~ 단일지점의 상태서비스를 이용했기때문에 글로벌 카운트 서비스를 이용할수 있게됩니다..

이 장치가 활용될수 있는곳

• DB저장이 사용자 이벤트발생마다 CRUD를 하게되면~ 단일지점 DB의 높은 성능이 필요하게되며 파멸시나리오가 될수 있습니다. 단일지점으로 이벤트를 모아 안정적인 벌크처리를 할시이용될수 있습니다. ( Akka의 FSM Actor와 연계 )
• 외부 API를 이용하는경우 동시성보다는 호출 제약에 걸리는 경우가 많습니다. 이때 호출제약을 호출자에서 고려하지 않고 Max에 도달하면 호출금지 제약에 걸려 API호출을 못할수도 있습니다. 외부연동 API 특히 LLM사용시 호출 토큰모니터링을 할시 단일지점 컨트롤이 가능하게 됩니다. ( AkkaStream의 Throlle와 연계 ) 
• 시간단위 배치 일단위배치등 별도의 배치시스템없이 라이트한 단일지점 스케줄러가 필요할시 이용할수 있으며, 싱글톤 Role은 복수개로 운영될수 있지만 단 하나만 작동하기때문에 이중화 구성도 자연스럽게 구축됩니다.

SpringBoot API에서이용

• SpringBoot Reactive가 이용되었기때문에 Webflux-Mono 객체와 연결되었으며 API에서는 다음 두가지 액터 함수를 이용해 API에서 이용할수 있습니다.
  • Tell : Fire And Forgot 기법으로 이벤트를 전송합니다.  
  • Ask Pattern : 해당 액터에게 응답을 요구할때 이용되며 CompleteableFuture및 Await(코틀린인경우)를 이용해 응답을 받을수 있습니다.

분산처리 Shard활용

싱글턴 클러스터는 클러스터내에 단하나만 작동시키는 기능으로 분산처리보다는 단일지점 처리를 보장하는 기능이였다고 하면

Shard는 아카클러스터내에 분산객체 처리를 할수 있게됩니다.

설정

pekko.cluster.sharding {
  guardian-name = sharding
  role = "shard"
  number-of-shards = 100
}

• key기반으로 분산배치가 자동지원되며~ 해시테이블기법으로 보통 분산되며 role에 부여권 어플리케이션에서 이 기능이 수행됩니다.
• number-of-shard  : 분산처리할 객체수를 의미합니다. 만약 노드가 2개라고 하면 50,50 으로 분산처리 될수 있습니다. 이 수치는 연결된 DB의 분산저장 동시처리량에 따라 전략적으로 튜닝할수 있습니다.

여기서는 분산저장을 배제하고 단순한 카운팅기능을 가진 객체만 클러스터내에 분산배치및 분산처리를 시도 해보겠습니다.  

분산저장은 별도 전략이 필요한 Part로 여기서 다루지는 않겠습니다.

분산처리 객체 생성

# AkkaConfiguration
        // ClusterSharding
        if (selfMember.hasRole("shard")) {
            logger.info("My Application Role shard")
            for (i in 1..100) {
                val entityId = "test-$i"
                var typeKey = EntityTypeKey.create(CounterCommand::class.java, entityId)
                var shardSystem = ClusterSharding.get(mainStage)
                shardSystem.init(Entity.of(typeKey, {
                    entityContext -> CounterActor.create(entityContext.entityId) }
                ))
            }
        }

• 분산처리 가능 카운팅 액터 100개가 , shard role을 가진 node로 분산생성됩니다.
• 이 기능은 redis의 분산저장및 kafka의 mailbox queue도 내장되어 있으며 해당장치의 메시지딜러버리 Once를 대체용도는 아니며 AkkaCluster가 Inmem에서  StateFull 개발방식을 이용해 단일지점 병목을 부하분산처리할수도 있는 기능을 가지고 있음을 의미합니다.
• 외부 장치(kafka,redis) 와 Stream으로 연동을 하고 더 세부적인 분산처리가 필요할시 확장할수 있습니다.
  • 외부 API호출은 kafka,redis와 같은 장치로 할수 있는것이 아닙니다. 
  • 처리량을 높일때 가장 큰비용은 DB, 분산저장에 유리한것은 Nosql, KeyValu로 빠르게 접근할수 있는것은 Redis입니다. Akka는 외부장치를 대체하는것이 아닌 Perditence장치및 중간 브로커로 다양하게 활용합니다. 

Shard객체 테스트

• 각각 다른노드에서 카운트를 증가시키고 값을 검증하는 코드로~ entityID가 어딘가에 shard role을 가진 어플리케이션에서 배치되겠지만 , 다른 노드(Region)에서도 같은 entityID를 객체인경우 하나의 객체를 다루는것처럼 분배된 상태를 증가또는 획득할수 있습니다. 

이 테스트는 목업으로 작동되는 것이 아닌 실제 Remote객체를 이용한 클러스터내 어플리케이션은 PeerToPeer 방식이 이용되며 네트워크 프로그래밍을 할필요없이 작동됩니다.

단지 actor를 클러스터로 작동시키는 remote를 정의하는 코드만 있습니다.  ( DNS Discovery또는 쿠버 Discovery 이용시 hostname을 0.0.0.0 으로 지정할수 있습니다. - 위치투명성)

actor{   
   provider = "cluster"
  }
  remote.artery {
    canonical {
      hostname = "127.0.0.1"
      port = 2551
    }
  }

• netty가 과거에는 기본전송 계층이였으나 artery를 기본계층으로 채택된듯하며 전송계층을 더 성능좋은 장치로 변경도 가능합니다..

객체직렬화

자바의 객체를 로컬에서만 이용하는 경우 메모리 참조만 하면되기때문에 직렬화/역직렬화 과정이 필요없습니다.

하지만 네트워크로 전송되거나 DataBase에 자바객체를 담기위해서는 직렬화 과정이 필요하며 JackSon을 이용하거나 경량화를 위해 바이너리 객체 또는 구글 프로토콜 버퍼를 이용할수도 있습니다.

리모트 객체도 더 빠른 객체가 등장하면 전송계층을 포함 데이터변환 객체등이 고정되는것이 아니라 선택할수 있는것이 Akka의 장점중 하나입니다.

    serializers {
      jackson-json = "org.apache.pekko.serialization.jackson.JacksonJsonSerializer"
      jackson-cbor = "org.apache.pekko.serialization.jackson.JacksonCborSerializer"
      proto = "org.apache.pekko.remote.serialization.ProtobufSerializer"
    }

    serialization-bindings {
      "org.example.kotlinbootreactivelabs.actor.PersitenceSerializable" = jackson-json
    }

Shard 객체 API에서 이용

• 유닛테스트가 완료되면~ 유닛테스트 된 코드를 그대로 spring boot api 에 담기만 하면 됩니다.

akka http가 액터모델과 상호작용하는 기능을 제공해 더 편리하긴하지만~ 이것때문에 웹프레임워크(playframework)를 교체하는것은 akka를 전면채택했을때 고려사항이며 

스프링부터 API레벨에서 액터모델을 활용하는 개발 style이 다소 불편해 보일수 있지만~ 다양한 외부장치를 혼합해 분산처리를 하려는 패턴보다 더 심플해질수 있습니다.

메시지 브로커에서 일반적으로 지원하는 pub/sub 방식도 akka내부에서 지원하며 여기서는 설명이 생략되었으나~

swagger및 샘플클라이언트를 통해 유닛테스트및 기능작동 확인을 할수 있습니다.

분산처리 PUBSUB

• SSE(Simple Sent Event)를 이용해 구독(sub)을 하고
• API 액터모델을 이용해 발행(pub)을 할수 있습니다.

전체코드 : https://github.com/psmon/kopring-reactive-labs/tree/main/KotlinBootReactiveLabs/src/main/kotlin/org/example/kotlinbootreactivelabs/actor/cluster