Service Discovery Server와 Git을 이용한 Configuration Server

서론

이제 실제로 Spring-cloud 를 이용해서 마이크로서비스 아키텍처 스타일의 애플리케이션을 만드는 방법에 대해서 정리를 할까 한다.

우선은 전체 구조에서 가장 근간이 될 Service Discovery Server와 Cofiguration Server 로 시작해 보자.

Configuration Server 는 이전 포스트에서 한 번 정리를 한 적이 있으니 이번에는 Git을 이용해서 설정하는 법에 대해서만 정리할 예정이다.

이 포스트에서 사용된 소스를 실행하기 위한 부분이나 필요사항은 아래와 같다.

gradle에 대한 기본 사용법 (버전 2.9와 2.10에서 확인했다)
IDEA 15(이클립스에서도 될 것으로 보이나 테스트는 못해봤다)
spring-io dependency-management-plugin : 0.5.4.RELEASE
spring-io : 2.0.1.RELEASE
spring-boot : 1.3.1.RELEASE
git(local git, github) 에 대한 기본 지식
git repository : https://github.com/roadkh/blog-cloud-sample.git

Gradle 과 Git은 나도 능숙하게 쓰는 편은 아니므로 혹시 문제가 있으면 알려주시기를...

전체 소스는 아래와 같이 확인이 가능하다.

  git clone https://github.com/roadkh/blog-cloud-sample.git
  git checkout blog_01

프로젝트 Gradle 구성

설정하는 부분에 대한 설명은 이전 포스트를 참고하기 바란다. 해당 포스트와 전체적으로 같다.

다만 settings.gradle 파일만 아래와 같이 변경되었다.

rootProject.name = 'blog-cloud'

['client', 'server', 'api'].each {
    def projectDir = new File(rootDir, it)

    // 만약 그룹디렉터리가 없으면 생성한다.
    if( !projectDir.exists() ) {
        projectDir.mkdirs()
    }

    // 모듈 그룹 디렉터리 하위에 디렉터리가 있으면 서브프로젝트로 등록한다.
    projectDir.eachDir { dir ->
        include ":${it}-${dir.name}"
        project(":${it}-${dir.name}").projectDir = new File(projectDir.absolutePath, dir.name);
    }
}

server 디렉터리에 configuration과 discovery 디렉터리를 생성하자.
이제 Refresh All Gradle projects를 한다. (Eclipse에서는 import project 에서 gradle 프로젝트를 통해 프로젝트를 추가할 수 있다)

이렇게 하면 :server-configuration 프로젝트와 :server-discovery 프로젝트가 생성된다.

Service Discovery Server로 Eureka 서버 구성

Spring-cloud 프로젝트에는 Service discovery server로 Consul, Eureka 등 여러 가지가 있다. Netflix OSS 프로젝트를 이용해서 구성하기로 했으니 Eureka를 이용해서 구성을 해보고자 한다.

앞에서 생성한 discovery 디렉터리로 이동해서 build.gradle을 생성하고 아래와 같이 입력한다.

apply plugin: 'spring-boot'

dependencies {
    compile 'org.springframework.cloud:spring-cloud-starter-eureka-server'
}

이제 적당한 패키지를 생성하고 그 안에 스프링부트 메인 클래스를 생성하자.
(com.road.pilot.blog.server.discovery 패키지에 DiscoveryServerApplication으로 생성했다)
해당 클래스에는 두 개의 어노테이션이 필요하다.
스프링부트 애플리케이션으로 만들기 위한 @SpringBootApplication 과 Eureka Server로 만들기 위한 @EnableEurekaServer 를 추가해준다. 여기까지 하면 기본 작업은 완성이다.
전체 소스의 내용은 아래와 같다.

@SpringBootApplication
@EnableEurekaServer
public class DiscoveryServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(DiscoveryServerApplication.class, args);
    }
}

이제 프로그램을 실행해보자. 실행이 잘 된다. 뭔가 오류가 올라가지만, 우선은 무시하자.
아마도 8080 포트(또는 8761)로 실행이 되었을 것이다.
접속을 해보면 아래와 같은 모습을 볼 수 있다.

일단 위와 같은 상태에서도 사용은 가능한 것으로 보인다. 실제로 클라이언트를 만들고 접속해보면 정상적으로 서비스가 등록된다. 다만, 콘솔을 보고 있으니 무언가 계속해서 오류가 올라간다.

java.lang.UnsupportedOperationException: Backup registry not implemented.
 at com.netflix.discovery.NotImplementedRegistryImpl.fetchRegistry(NotImplementedRegistryImpl.java:15) ~[eureka-client-1.1.147.jar:1.1.147]
 at com.netflix.discovery.DiscoveryClient.fetchRegistryFromBackup(DiscoveryClient.java:1811) [eureka-client-1.1.147.jar:1.1.147]

2016-01-16 21:22:36.236 ERROR 5647 --- [pool-9-thread-1] com.netflix.discovery.DiscoveryClient    : Can't get a response from http://localhost:8761/eureka/apps/
Can't contact any eureka nodes - possibly a security group issue?

com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused
 at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:184) ~[jersey-apache-client4-1.11.jar:1.11]
 at com.sun.jersey.api.client.filter.GZIPContentEncodingFilter.handle(GZIPContentEncodingFilter.java:120) ~[jersey-client-1.13.jar:1.13]
 at com.netflix.discovery.EurekaIdentityHeaderFilter.handle(EurekaIdentityHeaderFilter.java:28) ~[eureka-client-1.1.147.jar:1.1.147]

물론 com.netflix.discovery 패키지에 대해서 모든 로그를 OFF 시켜버리면 해결이 된다.

위와 같은 현상은 왜 발생하는 것일까? 기본적으로 Eureka 서버는 Replication 을 기본으로 설계되어있는 것으로 보인다. 따라서 최소 두 개의 Eureka 서버를 만들고, Eureka 서버들끼리 서로를 등록하고 관리하게 되어있다는 것이다. 그렇다면 하나만 사용할 수는 없는 것일까?

/src/main/resources 폴더에 application.yml 을 생성하고, 약간의 설정을 추가해보겠다.

application.yml 의 Eureka 관련 설정은 아래와 같다.

eureka:
  client:
      registerWithEureka: false 
      fetchRegistry: false

registerWithEureka(properties에서는 register-with-eureka) 와 fetchRegistry(properties에서는 fetch-registry) 를 모두 false 로 바꾸고 실행하면 아까 보던 오류는 더는 나오지 않는다. 그러나 페이지를 띄워보면 또 오류가 발생할 것이다.

그렇다면 원래 설계된 대로 두 대의 Discovery 서버를 설정해 보려고 한다.
여기서 spring profile을 이용할 생각이다. spring.profile.active가 peer1 인 경우와 peer2 인 경우로 해서 두 대의 Discovery 서버를 띄울 수 있도록 할 생각이다.

/src/main/resources 폴더에 application-peer1.yml 과 application-peer2.yml 을 생성하자.

server:
  port: 8761

spring:
  application:
    name: 'discovery'
  profiles:
    active: peer1

eureka:
  instance:
    hostname: peer1
    preferIpAddress: true
    leaseExpirationDurationInSeconds: 90 #default
    leaseRenewalIntervalInSeconds: 30    #default
    metadataMap:
          instanceId: ${spring.application.name}:${spring.application.instance_id:${random.value}}
  client:
      registerWithEureka: true
      fetchRegistry: true
      service-url:
        defaultZone: http://localhost:8762/eureka/

server:
  port: 8762

spring:
  application:
    name: 'discovery'
  profiles:
    active: peer2

eureka:
  instance:
    hostname: peer2
    preferIpAddress: true
    leaseExpirationDurationInSeconds: 90 #default
    leaseRenewalIntervalInSeconds: 30    #default
    metadataMap:
          instanceId: ${spring.application.name}:${spring.application.instance_id:${random.value}}
  client:
      registerWithEureka: true
      fetchRegistry: true
      service-url:
        defaultZone: http://localhost:8761/eureka/

port를 8761와 8762로 해서 두 대의 Eureka Server를 실행할 수 있도록 했다.
VM 파라미터에 -Dspring.profiles.active=peer1, -Dspring.profiles.active=peer2 를 각각 주고 실행해보자. 처음 실행하는 쪽에는 약간의 오류가 발생하겠지만, 두 대가 모두 올라오고 나면 그 뒤로 오류는 없어진다.

대신 다음과 같은 내용을 로그에서 확인할 수 있다.

2016-01-16 21:45:27.125  INFO 7021 --- [pool-8-thread-1] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_DISCOVERY/127.0.1.1:discovery:433b7810ff29e44253031b19332d9f0f: registering service...
2016-01-16 21:45:27.132  INFO 7021 --- [pool-8-thread-1] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_DISCOVERY/127.0.1.1:discovery:433b7810ff29e44253031b19332d9f0f - registration status: 204

양쪽 로그를 보면 주기적으로 계속해서 저런 로그들이 올라간다.

약 1분 정도 기다렸다가 포트 8761와 8762 에 접속해서 확인해보면 아래와 같이 등록된 인스턴스가 보인다.

이제 옵션을 잠시 보자.
eureka.instance의 항목을 먼저 보자(괄호 안은 properties를 사용할 경우).

preferIpAddress(prefer-ip-address) : 기본은 false 값이다. false 일 경우에는 hostname 을 이용해서 서비스 등록이 이루어진다. 위의 그림의 127.0.1.1 대신에 hostname이 입력된다.
leaseRenewalIntervalInSeconds(lease-renewal-interval-in-seconds): Heartbeat을 보내는 주기이다. 기본값은 30초이다.
leaseExpirationDurationInSeconds(lease-expiration-duration-in-seconds) : 서버는 인스턴스로부터 마지막 heartbeat을 받은 이후에 여기 설정된 시간이 지나도록 heartbeat이 오지 않으면 해당 인스턴스를 제거한다. 이 부분은 기회가 된다면 다른 포스트를 통해서 한번 확인을 해 볼 생각이다. 기본값은 90초다.
metadataMap.instanceId : 여러 개의 인스턴스를 띄워야 할 때 instanceId가 동일하면 대시보드의 정보가 계속 추가되는게 아니라 업데이트되는 현상이 있다. 그래서 random.value를 추가하는 것으로 해결했다(스프링 문서에도 그렇게 처리를 하고 있다)

현재는 다른 인스턴스가 없이 Discovery 서버가 서로에게 인스턴스로 등록되고 있다. 그런데 서버 두 대를 띄우고 나서 대시보드 페이지에 접속해보면 매우 한참 후에 인스턴스가 모두 올라온다.(보통은 1분~1분 30초)
이 부분은 정확하지는 않지만, 스프링 클라우드 문서를 보면 Eureka Server가 정상적으로 서비스 인스턴스에 대해 처리를 할 수 있는 것은 인스턴스, 서버, 클라이언트가 모두 같은 Metadata를 캐싱한 순간부터라고 한다. 따라서 최소 3번의 Heartbeat이 필요하다고 한다.
실제로 클라이언트를 이용해서 보면 실제로 클라이언트가 Ribbon 등을 이용하여 라우팅할 때 정상적으로 되려면 꽤 시간이 필요하다. 위 설정에서 leaseRenewalIntervalInSeconds 을 줄인다면 이 지연시간을 꽤 줄일 수 있지만, 대신 자주 heartbeat을 하게 되므로 필요한 용도에 맞게 이 부분을 조절해 줄 필요가 있다.

Git 을 이용한 Configuration Server 구성

Configuration Server에 대해서는 이전에 한 번 정리한 적이 있다.
이전 포스트에서는 로컬 저장소를 이용하는 방법을 사용했었는데, 해당 방법에는 약간의 문제가 있었다. 지금까지 확인한 문제점은 아래의 두 가지였다.

싱크의 문제 : 로컬 저장소의 파일을 이용하는 경우에는 파일의 내용이 바뀌어도 Configuration Server에 질의 내용으로 얻는 설정에는 변경이 일어나지 않는다. 즉, 설정이 바뀌면 Configuration Server를 재시작해야만 변경된 설정이 질의 가능했다.
프로퍼티의 분리 문제 : 이 부분은 정확히 설명하기가 좀 힘들고 재연도 어떻게 해야 할지 막막하긴 한데, 프로젝트를 진행하는 중에 일부 클라이언트의 설정이 Configuration Server에 설정된 내용을 가져오거나 그 반대의 경우가 발생했다. 이 부분은 내가 기본 폴더인 resource 폴더를 이용했기 때문에 발생한 문제인 것으로 보이지만, 어쨌건 뭔가 명확하지 않다는 부분은 문제점이 될 것으로 보인다.

그래서 이번에는 git 을 이용하는 방법을 이용해보고자 한다.

로컬에 있는 git 저장소를 이용하는 방법을 통해서 간단히 알아보겠다.

로컬에 git 저장소를 하나 만들고 Configuration Server의 bootstrap.yml에 아래와 같이 설정을 해 보았다.

spring:
  application:
    name: 'config-server'
  profiles:
    active: 'cloud'
  cloud:
    config:
      server:
        git:
          uri: /home/road/media/Dev/workspace/pilot/blog-cloud/blog-cloud-sample-config/ #local git 설정

우선은 확인을 위해 http://localhost:8888/test/default 로 접속해보았다. 아직 configuration 용으로 만들어진 어떤 파일도 없으므로 내용에는 기본 설정 정보 정도만 나온다.
로컬의 git 저장소에 test.yml 이라는 파일을 하나 만들고 적당한 프로퍼티를 추가했다.
예를 들어 test.message='This is test' 와 같은 내용을 추가했다.
그리고 commit을 한 후에 다시 접속해서 확인을 해보니 아래와 같았다.

즉, Commit 만 하면 Configuration Server의 재시동이 없이도 즉각적으로 반영된다는 이야기이다. 이 부분이 git 을 이용하게 될 경우의 장점이라 하겠다.
private git 을 이용하는 경우에는 uri, username, password 를 이용해서 설정할 수 있고, public git을 이용하는 경우에는 uri를 configuration이 있는 곳으로 설정해주면 된다.

Remote Git을 이용하는 것이 여러 가지 면에서 가장 좋겠지만, 한 가지 단점은 속도가 약간 느리다는 점이다. github 이나 bitbucket 등의 서비스를 연결해보니 약간의 지연이 발생을 한다. 하지만 Configuration Server의 용도는 보통 Application이 올라오는 순간에 한번 읽는 것이므로 약간의 지연이 큰 치명타는 아닐 것으로 보인다. 운영 중 설정변경에 대해 RefreshScope을 이용해서 처리하는 경우에는 약간의 영향을 받을 수 있을 테지만 말이다.

Configuration Server를 Discovery Server에 등록하기

이제 Configuration Server를 Discovery Server에 등록하자.

build.gradle 에 compile('org.springframework.cloud:spring-cloud-starter-eureka')을 추가하고 gradle을 refresh 해서 dependency를 설정한다.

다음으로 ConfigurationServerApplication 에 @EnableDiscoveryClient 어노테이션을 추가한다.

이제 Configuration Server에 application.yml(또는 application.properties)를 만들고 아래처럼 설정하자.
설정 내용은 이전 Discovery Server의 peer1, peer2와 크게 다르지는 않다. (이 설정을 그냥 bootstrap.yml 에 넣어도 된다)

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/
  instance:
    preferIpAddress: true
    leaseRenewalIntervalInSeconds: 30
    leaseExpirationDurationInSeconds: 90
    metadataMap:
      instanceId: ${spring.application.name}:${spring.application.instance_id:${random.value}}

이제 Discover Server를 모두 실행한 후에 Configuration Server를 실행해보자.
실행하고 30초 정도를 기다리면 registration 관련된 로그가 올라온다.

이제 Discovery Server에 접속해서 확인하면 아래와 같은 화면을 볼 수 있다.

이제 Configuration Server 가 등록되었다.
다른 클라이언트들이 이제 이를 이용할 수 있게 되었고, Discovery Server의 Dashboard에서 상태를 확인할 수 있다.

결론

사실 Discovery Server와 Configuration Server는 이를 이용할 수 있는 Client 들이 있어야만 한다.
별로 효율적인 구성이 아니어서 정리하지는 않았지만, Discovery Server도 Configuration Server를 이용하도록 bootstrap.yml 을 설정하고 Configuration Server를 먼저 띄운 후에 Discovery Server를 후에 띄우고, 그 이후에 Heartbeat을 이용해서 Configuration Server를 Discovery Server에 등록되도록 구성하는 방법도 있다.

다음번에 기회가 된다면 실제로 Client 들을 만들고 오늘 정리한 내용을 이용하는 것에 대해서 정리를 해볼까 한다.

이 포스트에서 정리된 전체 소스는 https://github.com/roadkh/blog-cloud-sample 의 blog_01 branch에서 확인해 볼 수 있다.

경력 개발자의 자기소개서에 대해서...

갑자기 뜬금없이 이런 글을 쓰다니 무슨 생각이야? 라고 생각하시는 분들이 있을지도 모르겠네요. 뜬금없음에 대한 변명은 잠시 접어두고 일단 오늘 쓰려고 하는 글을 시작해볼까 합니다. 개발자로 대충 16년을 그럭저럭 보내왔습니다. 시대적 상황으로 5년 차쯤에 대리로 처음 팀장을 시작했으니, 일반 개발자로 산 시간보다는 어쨌건 프로젝트 또는 팀의 리더로 산 시간이 더 많았던 것 같습니다. 그 기간 동안 남들보다 좀 심하게 회사를 많이 옮겨 다니다 보니 꽤 많은 면접을 볼 수 있는 경험이 있었고, 또 옮긴 회사가 대부분 팀을 리빌딩하는 곳이었다 보니 꽤 많은 채용절차에 관여할 기회가 있어서 어린 나이부터 비교적 많은 이력서를 검토했고 면접관으로도 여러 사람을 만날 수 있었습니다. 처음 면접을 보러 다니던 시절의 제 이력서의 자기소개서는 항상 "19XX년 봄 XX업계에 종사하시던 아버님과 집안일에 헌신적인 어머니의 유복한 가정에 1남 1녀의 막내로..." 로 시작되었습니다 (이 문장에 향수를 느끼시는 분들 많으실 거예요. ^^). 경력이 5년이 넘은 어느 날 도대체 이 문장을 왜 써야 하느냐는 의문이 생겨서 조금 바꾸긴 했습니다만, 그 뒤로도 꽤 오랜 세월을 이런 자기소개서가 항상 제 이력서에 붙어있었죠. 요즘 누가 저런 식으로 자기소개서를 써? 라고 생각하시는 분들 많으실 거로 생각해요. (대신 요즘은 대학 시절의 봉사활동이나 해외연수 이력이... 뭐 어차피 그놈이 그놈입니다.) 저런 자기소개서를 써야 한다는 것이 어디서 어떻게 시작된 것인지는 몰라도 회사를 그만두기 전인 2년 전까지도 약간의 표현은 다를지 모르지만 비슷한 문장으로 시작하는 자기소개서를 이력서에 첨부해서 보내는 지원자들을 볼 수 있었습니다. 이제 제가 뜬금없는 이런 글을 쓰게 된 이유를 밝히고 계속 진행해야겠네요. 블로그에 올릴 글을 준비하는 일이 생각보다 힘들어요. 블로그에 올리려고 준비한 주제에 맞는 소스를 작업하고 거기에 글을 입히다 보면 가끔

road..道..みち

이 블로그 검색