System Compleat.

고가용 서비스 - Spring Cloud - #2 Configure to Config server

Techs


(younjin.jeong@gmail.com, 정윤진)

언제나 설정은 프로세스 동작을 위한 필수 요소였다. 오래된 대부분의 서버 데몬들은 /etc/ 아래에 위치한 설정들을 필요로 했고, 이 설정들은 보통 데몬이 동작할 서버의 네트워크 정보와 같은 것들, 그리고 데몬 (또는 프로세스)의 기능을 조정하는 각종 플래그나 변수들로 이루어져 있다. 그리고 대부분의 경우 이 설정이 변경되어 적용이 필요하다면 프로세스의 재시작 또는 리로드가 필수적이다. 따라서 운영중인 서비스에 포함된 데몬의 설정 변경은 프로세스 재시작으로 인한 서비스에 순단, 또는 그 데몬의 캐시 사용 여부등에 따라 웜업(warm up)등의 작업, 그리고 필요에 따라 이중화를 통한 무중단을 고려해야 하는 등의 고급진 운영의 기술이 필요하다. 하지만 대부분의 사람들은 어려운 것 보다는 쉬운 방향으로 일을 처리하기 때문에, 서비스에 중단 시간을 사전에 공지하고 이 시간내에 설정의 변경, 프로세스의 재시작, 정상 동작의 확인과 같은 일을 수행한다. 따라서 서비스를 사용중인 사용자들은 서비스 중단을 경험하게 되는데, 이런 패턴은 고객을 위한 행동이라기 보다는 운영의 편의를 위한 방식이라고 할 수 있다. 

서버를 클라우드로 바뀌면 모든게 해결되는 줄 알던 시대가 있다. 다운 타임도 스르륵 사라지는 줄 알던 분들도 꽤 있었다. 그렇지 않다. 클라우드의 기본은 "무엇이든 언제든지 뽀개질 수 있다" 이며, 대신 "언제든 조달 가능한 리소스가 있다" 의 가치를 통해 뽀개짐을 새로운 대체재로 치환 하는 기술이 핵심이라고 할 수 있다. 따라서 모든 애플리케이션 및 서비스에 포함되는 컴포넌트는 "뽀개지면 요렇게" 의 사상을 가지고 만들어져야 궁극적인 제로 다운타임을 확보할 수 있을 것이다. 


그럼 그 "뽀개지면 요렇게" 는 어떻게 처리하는 것이 좋을까. 다음번에 자세히 소개하겠지만, Netflix 에서는 Simian Army 라는 도구를 운영한다. 이 도구가 하는 일은 무려 프로덕션 서비스에서 동작하는 서버들을 랜덤하게 죽인다. 물론 프로덕션 뿐만 아니라 새로운 서비스를 개발하거나 배포하기 전에도 테스트에 사용된다. 즉, 이 테스트를 통과하지 못하면 프로덕션에 배포될 수 없다. 우리 나라에 운영 하시는 분들은 아마 이런 구성을 상상이나 하겠는가. 잘 돌아가는 서버를 끈다니 이 무슨 천인 공노할 일인가 말이다. 라고 생각하시겠지. 다음번 소개 이전에 궁금하신 분들은 넷플릭스의 테크 블로그로. (http://techblog.netflix.com/2011/07/netflix-simian-army.html

Chaos Goriila - Netflix Simain Army

위의 이미지는 카오스 고릴라 (Chaos Gorillia) 의 이미지다. Simian Army 에서 카오스 고릴라가 하는 일은 아마존 웹 서비스의 특정 AZ(Availability Zone) 전체의 인스턴스를 다운시킨다. 즉, 데이터 센터 레벨에서의 고가용성을 프로덕션에서 테스트 한다는 말이 되겠다. 한국의 서비스 중에 이런 레벨의 고가용성을 유지하는 회사가 어디 있겠냐 말이다. 


어쨌든 애플리케이션의 설정 변경을 통한 빌드, 재배포, 그리고 이 재배포로 인해 발생하는 다운타임은 그다지 달가운 것이 아니다. 그리고 설정의 변경때마다 새로운 빌드와 새로운 배포를 해야 한다는것은, 만약 매뉴얼 작업으로 처리하고 있다면 꽤나 귀찮고 불편한 일일 것이다. application.properties 에 설정을 변경하면 새로운 jar 또는 war 를 만들어야 하고 만약 톰캣을 따로 사용하고 있다면 파일을 일단 서버에 전송한 후 특정 위치에 배치한 후 프로세스를 재시작한다. 뭐 서버 한두대 돌릴때야 별 문제 없는 방법일지도 모르지만 넷플릭스와 같이 수십, 수백, 수천대의 인스턴스가 동작하고 있는 상황이라면 어떨까. 이런건 업데이트 공지 한시간으로는 안된다. 

그리고 한가지, 아마존 닷컴이 업데이트 한다고 서비스 1시간 다운 시키면 아마 뉴스에 날거다. 주가는 떨어지고. 아마존 웹 서비스는 어떤가. 


우리는 이러한 문제가 왜 발생하는지 알아야 할 필요가 있다. 즉, 기능 업데이트를 제외하고 애플리케이션의 설정(또는 feature flag)을 바꿨기 때문에 서비스에 중단이 발생한다는 것은 사실 달가운 일이 아니라는 것이다. 그 귀찮은 배포와 프로세스 재시작이 기다리는 요단강을 하루에 수십번 넘는다는 것은 즐거운 일이 아니다. 따라서 이런 문제를 해결하기 위해, 2011년 쯤에 Heroku 를 만든 팀이 만들어낸 컨셉인 12 factor 라는게 있다. 내용은 한글로도 있으며, 페이지는 http://12factor.net 에 방문해 보면 현대의 애플리케이션이 어떻게 만들어져야 하는지에 대한 컨셉을 담고 있다. 그것 중, 오늘 이야기할 부분, 바로 설정과 관련된 핵심 그림은 아래와 같다. 

https://12factor.net/ko/build-release-run

2. Config 에서 따온 그림은 아니지만, 중요한 내용은 바로 여기에 있다. 설정과 코드는 분리 되어야 하는데, 이것이 합쳐진 것이 바로 릴리즈 라는 개념인 것이다. 이것이 왜 중요한지 간략하게 요약해 보면 다음과 같다. 

- application.properties 또는 application.yml 이라는 것이 본시 설정이지만 코드 영역에 포함 된 것이다. 

- 따라서 변경을 하면 새로 빌드해야 한다. 이것은 새로운 배포를 필요로 한다. 

- 대부분의 애플리케이션에서 프레임워크 기본 설정 외에 기능에 필요한 설정은 코드 내에 포함되는 경우가 많다. 

- 이것은 배포의 대상이 많으면 많을 수록 (예. 개발 / 테스트 / 프로덕션 환경) 서로 다른 버전의 설정이 코드에 반영되어야 하므로, 관리를 위해 다수의 repository 를 운영하게 된다. 

- 결국 코드는 seamless 하게 각 환경으로 배포될 수 없고, 이는 사람의 손과 복잡한 코드 저장소의 관리를 수행해야 하는 사태가 발생한다. 

- 이 모든것이 설정이 코드에 포함되어 있기 때문에 발생한다. 


물론 이런 문제를 방지해 주는 여러가지 기법들이 있지만, 전술했듯 사람은 쉬운 쪽으로 일을 한다. 특히 일이 급하면 더 그렇다. 설정을 따로 분리해 내는 것 보다 그냥 코드 안에 도메인이나 IP를 때려넣는 것이 더 편하다. "어? 내 PC에서는 잘 되는데...?" 


만약 설정 정보를 API 요청을 통해 한꺼번에 받아올 수 있는 웹 서비스가 있다면 어떨까. 그리고 이 웹 서비스는 코드 저장소를 설정 파일의 소스로 사용한다면 어떨까. 물론 파일 시스템을 사용할 수도 있다. 일단 이것이 오늘 소개할 스프링 클라우드 Config Server 이다. 넷플릭스에서는 Archaius (http://techblog.netflix.com/2012/06/annoucing-archaius-dynamic-properties.html) 라는 도구를 사용한다고 한다. 


스프링 클라우드에서 제공하는 Config server 에 대한 자세한 정보는 다음의 링크에서 얻을 수 있다. https://cloud.spring.io/spring-cloud-config/spring-cloud-config.html 


Config server 의 사용은 이전에 살펴본 넷플릭스 유레카와 마찬가지로 서버와 클라이언트로 구성되어 있으며, 스프링 이니셜라이저 (http://start.spring.io)를 사용한다면 매우 쉽게 사용이 가능하다. 순서는 아래와 같다. 

Spring Cloud Config Server

- http://start.spring.io 에 접근한다. 

- artifact 에 config-service 와 같은 그럴듯한 이름을 넣어준다. 

- Dependencies 에서 Config Server 를 찾아 추가한다. 


- Generate Project 를 눌러 Zip 파일을 다운로드하고, 이를 IDE 를 사용해서 연다. 

- config-service/src/main/java/com/example/ConfigServiceApplication.java 에 @EnableConfigServer 어노테이션을 추가한다. 

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;


@SpringBootApplication
@EnableConfigServer
public class ConfigServiceApplication {

public static void main(String[] args) {
SpringApplication.run(ConfigServiceApplication.class, args);
}
}

- application.properties 파일에 아래의 설정을 추가한다. 설정 파일이 위치한 코드 저장소는 github 를 사용했는데, 별도의 git 또는 파일 저장소를 사용할 수 있다. 자세한 내용은 위의 Config Server 설정 부분을 참조 

spring.application.name=config-server
spring.cloud.config.server.git.uri=https://github.com/younjinjeong/spring-cloud-event-sourcing-config
server.port=8888

- 애플리케이션을 빌드하고 실행한다. 

mvn clean package
java -jar target/config-server-0.0.1-SNAPSHOT.jar

따로 설명하지는 않았지만, 스프링 부트 애플리케이션을 구동하기 위해 별도의 WAS 를 사용하지 않았음에 주목한다. 최근 이런 Fat JAR 를 어떻게 서비스에 구동해야 하는지 여쭈어 보는 분들이 종종 계신데, 많이 목격되는 것은 다커(Docker) 를 사용하거나 Cloud Foundry 와 같은 런타임 플랫폼을 사용할 수 있다. 자세한 설명은 따로. 어쨌든 서비스가 정상동작 하는지 확인하기 위해서, 위의 github 를 사용하는 경우 다음의 링크를 통해 확인이 가능하다. https://localhost:8888/user-service/cloud

 

어쨌든 위와 같은 작업을 통해 이제 웹 요청을 통해 코드 저장소에 저장된 설정을 전달할 수 있는 서버가 준비되었다. 서버가 준비되었다면, 클라이언트를 연결해 본다. 


Config Server client 

- http://start.spring.io 로 접근 

- artifact 에 config-client 를 넣는다. 

- Dependencies 에 Config client 를 선택한다. 이외에 원하는 부트 애플리케이션을 만들기 위해 Web, Rest repo, H2 등 원하는 도구를 선택한다. 

- Generate project 를 눌러 프로젝트 파일을 다운로드 받고 압축을 해제하여 IDE 로 개봉한다. ㅎ 

- 별도의 어노테이션 추가는 필요 없지만, 설정 파일에 Config server 의 위치를 명시해야 한다. config-client/src/main/resources/bootstrap.properties 파일을 생성하고 (application.properties 가 아님에 주의) 아래와 같이 Config server 의 위치를 명시해 준다. 

spring.cloud.config.uri=http://localhost:8888
spring.application.name=config-client

- 만약 Github 나 별도의 코드 저장소를 사용한다면, config-client.properties 를 생성하고 아래와 같이 간단한 설정을 넣고 Config 서버에 연결된 코드 저장소에 push 한다. 

server.port=${PORT:9999}

- 이전에 만들어 둔 Config 서버를 시작한다. 

- 지금 생성한 config-client 애플리케이션을 시작한다. 

.   ____          _            __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v1.4.0.RELEASE)

2016-09-19 12:28:37.699 INFO 3977 --- [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: http://localhost:8888
2016-09-19 12:28:42.443 INFO 3977 --- [ main] c.c.c.ConfigServicePropertySourceLocator : Located environment: name=config-client, profiles=[default], label=master, version=afb483b02756c38f5c2ce3a3e0ad149aefe100c3
2016-09-19 12:28:42.443 INFO 3977 --- [ main] b.c.PropertySourceBootstrapConfiguration : Located property source: CompositePropertySource [name='configService', propertySources=[MapPropertySource [name='https://github.com/younjinjeong/spring-cloud-event-sourcing-config/config-client.properties'], MapPropertySource [name='https://github.com/younjinjeong/spring-cloud-event-sourcing-config/config-client.yml'], MapPropertySource [name='https://github.com/younjinjeong/spring-cloud-event-sourcing-config/application.yml']]]
2016-09-19 12:28:42.503 INFO 3977 --- [ main] com.example.ConfigClientApplication : No active profile set, falling back to default profiles: default

애플리케이션을 시작하면, 위와 같이 아름다운 Spring 아스키 이미지와 함께 메세지를 확인할 수 있는데, 내용인 즉슨 다음과 같다. 

Fetching config from server at: http://localhost:8888 

애플리케이션이 시작되면서 Config server 로 부터 설정 내용을 가져온다. 그리고 애플리케이션이 정상적으로 시작되었다면, 아래의 내용을 확인할 수 있을것이다. 

Tomcat started on port(s): 9999 (http) 

즉, 설정 파일의 내용을 스프링 애플리케이션이 참조하여 해당 애플리케이션의 포트를 9999로 설정한 것이다. 스프링 부트의 특징중 하나는 각종 설정의 오버라이드가 매우 쉽다는 점인데, 이것들은 서로 참조되는 순서가 있다. 첫번째로 참조되는 것이 바로 bootstart.properties 로, 이 파일에 있는 내용은 애플리케이션의 이름, config server 의 위치와 같이 거의 변경되지 않는 내용을 넣는다. 두번째로 참조되는 것이 이 경우에는 Config server 에 있는 설정 파일의 내용인데, 여기에서 역시 참조 순서가 있다. config server 가 참조하는 코드 저장소에 있는 설정 파일의 이름에 application.properties 가 있다면, 여기에 있는 내용은 모든 config server 를 참조하는 config client 들이 참조하는 전역 설정과 같은 것이다. 그리고 이와 함께 [application-name].properties 가 있다면, 이 application.properties 위에 설정을 merge 해서 사용한다. 이때 동일한 설정이 있다면 이기는 쪽은 애플리케이션이름.프로퍼티 파일이 되겠다. 

이러한 우선 순위 규칙에 따라 애플리케이션 설정의 참조 순서를 적용할 수 있으며, 더욱 중요한 것은 이를 통해 설정과 코드를 분리 할 수 있다는 것이다. 스프링 부트 애플리케이션은 시작할때 서버의 설정 내용을 참조하여 스스로를 설정하며, 이는 12 factor 애플리케이션의 config 부분에 취급되는 매우 중요한 내용중 하나가 되겠다. 그리고 이 포스팅에서 구체적으로 언급하지는 않지만, 각 설정 파일을 환경 별로 생성할 필요 없이 사용될 환경을 지정해서 사용하는 것도 가능하다. 이는 프로파일 이라고 불리는데, 위의 애플리케이션의 시작 로그를 살펴 보면 아래와 같은 로그가 남는것을 확인 할 수 있다. 

No active profile set, falling back to default profiles: default

따라서 여러분이 사용하는 환경 별로 test, staging, production, cloud 와 같은 형태로 구성하여 사용할 수 있다는 것이다. 


Config 에는 다소 민감한 내용들이 있을 수 있다. 이를테면 특정 애플리케이션의 패스워드, 데이터베이스 연결정보, 클라우드 서비스 공급자의 API 키와 같은 내용들이다. 이런 내용들을 보호하기 위해 암/복호화를 사용할 수도 있겠다. Config server 의 보안에 대해서는 아래의 링크를 살펴보기를 권고한다. https://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_security 


마지막으로, Config 서버는 애플리케이션의 재시작 없이 설정을 변경할 수 있는 메커니즘을 제공한다. 즉, 이미 온라인 상태에서 동작하고 있는 애플리케이션의 feature flag라던가, a/b 테스트 용도의 기능 변경과 같은 것들을 이 변경 가능한 설정에 적용할 수 있다. 적용하는 방법은 아래의 Josh 코드에서 살펴볼 수 있다. 이는 @RefreshScope 라는 어노테이션을 사용하는 것으로 가능하다. 아래의 간단한 코드는 message 라는 설정이 config repo 에 있고, 이를 즉시 변경할 수 있는 예제이다. 

@RefreshScope
@RestController
class MessageRestController {

@Value("${message}")
private String message;

@RequestMapping("/message")
String message() {
return this.message;
}
}

이렇게 구성된 코드는 설정 파일에서 (또는 config repo에서) message 로 지정된 내용을 가져와 /message 에 요청이 있을때 응답한다. 만약 예전의 방법으로 이를 구성한다면, 메세지를 변경할 때마다 (데이터베이스를 사용하던지) 아니면 설정을 수정/ 또는 코드를 수정하여 새로 빌드 후 배포해야 동작할 것이다. 하지만 Config client 에서는 이를 empty post 요청을 보냄으로서 처리가 가능하다. 이에 대한 설명은 아래의 링크를 참조한다. http://cloud.spring.io/spring-cloud-static/spring-cloud.html#_refresh_scope


유레카와 마찬가지로, config server 역시 '설정 및 적용'을 위한 하나의 마이크로 서비스 애플리케이션으로 생각할 수 있다. 이는 당연하게도 유레카 서비스와 함께 연동해서 사용할 수 있으며, 이 경우 더 좋은 가시성을 확보할 수 있다. 따라서 자바, 그중에서도 스프링을 사용하여 마이크로 서비스를 구현하려는 경우에는 바로 이 유레카와 config 서버 두개를 기본 리소스로 확보하여 마이크로 서비스 구조를 확장할 수 있는 방법을 제시한다. 


다음번에는 이렇게 구성된 서비스들 간 API 게이트웨이 및 마이크로 프락시 역할을 하는 넷플릭스의 Zuul 을 스프링 클라우드에서 사용하는 방법에 대해 소개해 보도록 하겠다. 도움이 되시길 바라며. 


(younjin.jeong@gmail.com, 정윤진) 



고가용 서비스 - Spring Cloud - #1 DNS to Eureka

Techs


(정윤진, younjin.jeong@gmail.com) 

언어와 기술의 홍수에서 살다보면 정작 뭐가 중요한지 잊어버리는 경우가 많다. 클라우드의 시대에는 이것이 점점 더 가속화 되었는데 그 대표적인 예가 운영자에게 코드를 배우도록 강요하고, 개발자에게 운영의 기술을 가지도록 하는 것이다. 게다가 클라우드 서비스 자체 뿐만 아니라 그 위에서 동작하는 수많은 새로운 도구들의 출현은 가만히 보고 있자면 숨이 막힐 지경이다. 그것들 중에 어느 포인트가 가장 재미가 있을까 생각을 해 보니, 역시 스프링 클라우드에 대해 이야기 해보는게 좋을것 같다. 

아래의 그림은 DNS가 어떻게 동작하는지 보여준다. 

http://www.thewindowsclub.com/dns-lookup


그림은 thewindowsclub.com 이라는 페이지에서 가져왔다. 예전에 그려둔게 있는것 같은데, 아무튼 없네. 

DNS는 인터넷의 시작점과 함께 존재했던 도구다. DNS를 모르는 개발자나 운영자는 없겠지만, 그것이 실제로 어떻게 동작하는지에 대해 이해하는것은 조금 다른 이야기니까 몇글자 적어보면, DNS는 일단 Domain Lookup System (또는 서비스)다. 모든 사용자 컴퓨터에 보관된 네트워크 정보는 크게 내 아이피 주소와 네트워크 마스크, 그리고 다른 네트워크로 넘어갈때 내 통신을 처리해 줄 게이트웨이의 주소, 그리고 이 DNS 서버의 주소를 기입하게 된다. 집에서 쓰는 공유기에는 편리하게도 DHCP 라는 프로토콜을 통해 이 내용들이 컴퓨터가 연결되면 자동으로 설정되지만, 대부분의 서버 네트워크에서는 이런 것들을 수동으로 설정하여 관리한다. 

어쨌든 www.mydomain.com 과 같은 주소를 브라우저에 넣게 되면 이는 네트워크 정보에 담겨져 있는 DNS 서버로 물어본다. 이때 순서가 있는데, .com .net .io 와 같은 최상위 도메인에 대한 정보를 가지고 있는 서버들을 ROOT DNS 라고 한다. 이 ROOT DNS 서버 정보들은 사전에 공개 되어 있으며, IANA 와 같은 기관에 의해 관리된다. 기본 동작은 이 ROOT 서버에 mydomain 에 관련된 정보를 어디서 찾아야 하는지 물어보고, ns.mydomain.com 과 같은 DNS 서버 주소를 찾게 되면 다시 이 ns.mydomain.com 에서 www 에 대응하는 IP 주소를 넘겨 받아 결국 www.mydomain.com 으로 직접 IP 연결을 통해 접근하게 된다. 

이 과정들은 bind9 과 같은 DNS 서버에서 recursive 라는 플래그를 통해 "내가 대신 물어봐 줄께" 를 켜거나 꺼는 방법으로 서버 관리자는 설정할 수 있다. 즉, 내 컴퓨터에 설정된 1차 및 2차 DNS 서버에서 www.mydomain.com 을 찾기위해 각각 다른 DNS 서버로 물어보는 동작을 대신 처리해 주고, 마지막 결과인 A 레코드, 즉 IP 주소만을 내 컴퓨터로 되돌려 주어 내 컴퓨터는 www.mydomain.com = IP (ex. 1.1.1.1) 과 같은 정보를 가지게 되는 것이다. 그러면 컴퓨터는 1.1.1.1 서버로 http GET 요청을 보내게 되고 해당 서버의 정보가 정확하다면 서버는 GET 요청을 처리해서 돌려주며, 이렇게 받은 데이터를 브라우저 화면에 표시하는게 브라우저에 도메인 주소를 찍을때 발생하는 동작들이다. 

일단 이러한 메커니즘이 왜 필요한지 생각해 볼 필요가 있다. 첫째로는 사람은 숫자보다는 문자를 더 잘 기억한다. 또, 그렇게 기억하는 것이 편리하다. www.amazon.com 이 54.239.25.208 보다 외우기가 쉽다. 두번째로, 어떤 사유에 의해서이건 도메인과 아이피 주소는 바뀐다. 그것이 장애에 의한 고가용성 처리를 위해서건, 단순히 서버를 KT에서 Amazon 으로 옮겨서건 간에 이름과 주소는 바뀔 수 있다. 예를 들면 내 이름은 바뀔 가능성이 매우 낮지만 (거의 없지만), 내가 사는 주소는 언제든 바뀔 수 있는 것이다. 따라서 DNS 는 이런 인터넷 상의 특정 서비스로의 접근을 위한 주소 해석 체계를 제공한다. 

이것은 인터넷에서 서비스간 연결을 위해 사용되기도 하지만, 서비스 내부에서 웹 서버가 데이터베이스 서버를 찾아갈 때 사용하기도 한다. 이 두가지는 보통 external / internal 이라는 용도로 구분하여 사용하곤 하는데, external 의 경우 www.service.com 과 같은 대표 도메인과 메일 처리를 위한 MX 레코드 등 인터넷으로 부터의 참조 목적을 위해 사용하고, internal 의 경우 db-1.service.com, web-1.service.com 과 같이 내부 리소스에 대한 정보를 제공하기 위해 사용된다. 하지만 대부분 internal 의 경우에는 DNS 를 사용하는 대신 DNS 이전에 참조 될 수 있는 /etc/hosts 를 사용하는 경우가 대부분이다. 이는 DNS 를 유지하는 것 보다 /etc/hosts 파일을 보수 하는 것이 더 쉽기 때문이다. 그 말인 즉슨, DNS 서버는 유지하고 관리하는데 추가적인 노력이 "꽤" 많이 드는 서비스 라는 것이다. 그리고 이 DNS 서비스에 등록되어 인터넷에서 "유일하게" 식별 될 수 있는 주소를 FQDN (Fully Qualified Domain Name) 이라고 하며 이는 서비스 코드 내에서 다른 서비스 참조 또는 다른 서비스에 API 요청을 수행할때 이 도메인 주소, 또는 hosts 에 등록된 주소를 사용했다. 

이전에 많이 사용하던 DNS 의 특징을 이 외에도 종합해 보면 다음과 같다. 

- 서비스가 정상적으로 동작하려면 레코드를 사전에 등록해서 사용해야 한다. 

- 최근에는 가능한 DNS 서버도 많이 있지만, 어쨌든 DNS 서버는 기본적으로 서비스에 대한 healthcheck 를 수행하지 않는다. 

- 레코드에 대한 변경이 발생하는 경우 업데이트 및 반영에 시간이 필요하다. 주로 TTL(time to live) 값을 통해 위에 설명한 "되물어보기" 를 피하기 위한 캐시 용도로 사용하는데, 만약 TTL 값이 1시간이라면 TTL 1시간 만료 직전 59분 59초에 이 요청을 수행한 클라이언트는 다음 1시간 동안 이전의 레코드를 캐시에 가지고 요청하게 된다. 즉, DNS 서버가 변경되었을때 클라이언트들에 즉시 업데이트 할 수 있는 메커니즘을 가지고 있지 않다. 

- 따라서 TTL 값을 짧게 잡으려고 하는데, 이 경우에는 DNS 서버에 심각한 부하가 발생할 수 있다. 

- 대표적으로 사용되는 bind9 의 경우 변경 사항의 업데이트를 위해서는 zone 파일의 리로드 또는 프로세스의 재시작이 필요하다. DNS 서비스 프로세스 재시작 해 본적 있는가봉가 



클라우드 이전에는 이런 구성은 사실 문제가 되는 경우가 매우 드물었다. 관리자가 서버 이전을 해야 하는데 TTL 이 기본인 1주일로 잡혀있는 것을 잊어버리고 IP 부터 변경하여 1주일 동안 서비스가 되니 마니 하는 장애 상황이 생길 정도로 말이다. 즉, 서버의 이동과 신규 추가가 발생하는 경우가 극히 계획적이고 자주 발생하지 않기 때문에 DNS를 업데이트를 자주 하지 않아도 '한번 설정하면 어지간하면 그대로 동작하는' 상태가 유지 되었던 것이다. 하지만 클라우드에서는 어떤가. 

external 의 용도로는 기존의 DNS 체계가 인터넷과 밀착되어 있기 때문에 이는 반드시 유지해야 하는 구성이다. 하지만 internal 의 경우, 오토 스케일링, 컨테이너의 사용 등으로 인해 특정 서비스에 연결된 서버의 정보가 수시로, 정말 수시로 변경되게 되고, 이에 대한 정보를 그때그때 IP 로 관리한다는 것은 말이 안되기 때문에 서비스-서버 정보를 매핑해 주는 역할이 필요하게 된다. 따라서 DNS 체계를 사용하려고 봤더니, 이게 업데이트와 업데이트의 반영을 위한 노력이 장난이 아닌것이다. 게다가 클라우드 서비스에서 서버나 컨테이너의 생성과 소멸은 지속적으로 반복되고, 그 생성과 소멸의 시점에 즉시 반영 되어야 그 의미가 있는 것이므로 종전의 DNS 를 사용하는 방법은 옳지 않다고 할 수 있다. 

이에 우리의 변태 엔지니어들 가득한 넷플릭스에서는 Simian Army의 공격에서도 살아남을 수 있는 Eureka 라는 서비스를 만들어 냈다. 이는 오픈 소스로 공개가 되어 있으므로, 아래의 링크를 참조해 보도록 하자. 

https://github.com/Netflix/eureka 



역시 그림은 나랑 안맞... 

아무튼 이 도구가 하는 역할은 Service discovery, 즉 언놈이 어떤 정보를 가지고 동작하는지에 대한 내용을 실시간으로 서비스에서 반영하는 도구다. 위의 DNS 역할은 서비스와 해당 서비스 애플리케이션이 동작하는 위치를 정보를 "요청하는 클라이언트에게만" 전해주는 정보였다. 유레카는 각 클라이언트가 자신의 정보를 유레카 서버에 보내고, 이 정보를 받은 유레카 서버는 각 클라이언트에게 업데이트된 정보를 전달해 주는 체계를 가지고 있다. 이는 다수의 데이터 센터에서 동작할 수 있어 높은 수준의 고가용성으로 지속적으로 서비스가 가능하며, 문제가 발생하여 일순간 서비스에 문제가 된 경우에도 각 클라이언트는 유레카 서버로 부터 받은 정보를 일정 시간동안 로컬에 보유하고 있어 다른 서비스에 연결하는데 문제가 되지 않는다. 

유레카는 서버와 클라이언트로 구성되고, 클라이언트는 자신의 정보를 서버에게, 서버는 클라이언트로 부터 받은 정보를 다른 클라이언트에게 전파하는 역할을 한다. 따라서 서비스 1에 더 많은 요청을 처리하기 위해 서비스를 이루는 서버 또는 컨테이너가 늘어나는 경우, 이 늘어난 컨테이너들에서 동작하는 유레카 클라이언트들은 자신이 동작하는 순간 서버에 자신의 정보를 전달하고 이 정보가 모든 클라이언트에 업데이트 되기 때문에 DNS + Load balancer 의 구성에서 보다 더 빠른 속도로 서비스-인, 서비스-아웃이 가능하다. 

이와 유사한 동작을 하는 도구들은 몇몇 있다. HashCorp의 Consul (https://www.consul.io/) 아파치 주키퍼(https://zookeeper.apache.org/) 등. Consul 의 경우에는 Cloud Foundry 에서도 Service discovery 용도로 사용되고 있는데, 이는 주로 Golang 을 사랑하는 분들에게 많이 이용되는 것 같다. Golang 에서의 Consul 을 사용한 서비스 디스커버리 예제는 이 링크에서 참조 할 수 있다. (http://varunksaini.com/consul-service-discovery-golang/


스프링 클라우드는 단순히 넷플릭스의 OSS 도구 뿐만이 아니라 다른 OSS 생태계에서 클라우드 기반 애플리케이션에 필요한 도구들을 함께 제공한다. 위에 열거한 모든 도구는 스프링 클라우드에서 제공하고 있으며, 이것이 의미하는 바는 위의 모든 도구들이 JVM 기반에서 동작할 수 있는 애플리케이션으로서 서비스에 제공될 수 있다는 의미다. 스프링 클라우드에서 Eureka 서버와 클라이언트를 구성하는 방법은 매우 간단한데, 아래의 단계로 각각 수행하면 된다. 

Eureka 서버 

- http://start.spring.io 에 접근한다. 

- artifact 에 discovery-service 라고 쓴다

- 오른쪽 Dependencies 에 Eureka Server 를 찾아 엔터를 눌러 추가한다. 

- Generate Project 를 눌러 zip 파일을 다운받고, 압축을 해제하여 프로젝트를 IDE, 이를테면 STS나 IntelliJ 와 같은 도구로 연다. 

- discovery-service/src/main/java/com/example/DiscoveryServiceApplication.java  에 @EnableEurekaServer 어노테이션을 추가한다 

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer

public class DiscoveryServiceApplication {

public static void main(String[] args) {
SpringApplication.run(DiscoveryServiceApplication.class, args);
}
}

- discovery-service/src/main/resources/application.properties 에 아래와 같이 설정을 넣어준다. STS 를 사용하거나 IntelliJ IDEA ultimate 버전을 사용한다면 다양한 eureka 관련 설정 옵션을 확인할 수 있다. 

spring.application.name=discovery-service
server.port=${PORT:8761}

eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false
eureka.server.enable-self-preservation=true


다 끝났다. Maven 이라면 mvn spring-boot:Run 을 사용하거나 IDE의 플레이 버튼을 눌러 애플리케이션을 실행하면 다음과 같은 Eureka 웹 콘솔을 확인할 수 있다. 

유레카 서버가 준비 되었으니, 클라이언트를 추가해 볼 차례다. 다른것은 그저 스프링 부트 애플리케이션을 만드는 것과 크게 다르지 않고, Dependencies 에 Discovery client 를 추가하면 된다. 

- http://start.spring.io 에 간다. 

- artifact 에 eureka-client 와 같은 애플리케이션 이름을 넣는다. 

- Devpendencies 에 eureka discovery 를 추가하고 Generate project 를 눌러 프로젝트를 다운 받아 압축을 풀고, IDE 로 연다. 

- @EnableEurekaClient 어노테이션을 추가한다. 

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;

@SpringBootApplication
@EnableEurekaClient
public class EurekaClientApplication {

public static void main(String[] args) {
SpringApplication.run(EurekaClientApplication.class, args);
}
}

- application.properties 를 수정한다. 

spring.application.name=eureka-client
server.port=${PORT:8989}

eureka.instance.hostname=${vcap.application.uris[0]:localhost}
eureka.instance.nonSecurePort=80
eureka.instance.metadataMap.instanceId=${vcap.application.instance_id:${spring.application.name}:${spring.application.instance_id:${server.port}}}
eureka.instance.leaseRenewalIntervalInSeconds = 1
eureka.instance.lease-expiration-duration-in-seconds=5
eureka.instance.lease-renewal-interval-in-seconds=10
eureka.client.registryFetchIntervalSeconds = 5

스프링 부트 애플리케이션을 실행하고 eureka 서버의 웹 콘솔로 접근해 보면 eureka-client 가 추가된 것을 확인할 수 있다. 

동일한 클라이언트 애플리케이션을 다른 포트로 구동시켜 보자. mvn spring-boot:run -Dserver.port=8980 과 같은 형태로 쉽게 설정을 오버라이드 할 수 있다. 

그러면 EUREKA-CLIENT 라는 이름의 애플리케이션에 2개의 인스턴스가 생겨난 것을 확인할 수 있다. 이때 클라이언트 애플리케이션을 끄고 웹 콘솔을 리프레시 해 보면 등록된 클라이언트들의 정보가 사라진다. 

유레카를 통해 각 클라이언트에 전파되는 정보를 확인하고 싶다면 아래의 주소로 접근해 보자. 

http://localhost:8761/eureka/apps 

<applications>
<versions__delta>1</versions__delta>
<apps__hashcode>UP_1_</apps__hashcode>
<application>
<name>EUREKA-CLIENT</name>
<instance>
<instanceId>172.30.1.24:eureka-client:8980</instanceId>
<hostName>localhost</hostName>
<app>EUREKA-CLIENT</app>
<ipAddr>172.30.1.24</ipAddr>
<status>UP</status>
<overriddenstatus>UNKNOWN</overriddenstatus>
<port enabled="true">80</port>
<securePort enabled="false">443</securePort>
<countryId>1</countryId>
<dataCenterInfo class="com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo">
<name>MyOwn</name>
</dataCenterInfo>
<leaseInfo>
<renewalIntervalInSecs>10</renewalIntervalInSecs>
<durationInSecs>5</durationInSecs>
<registrationTimestamp>1474180884996</registrationTimestamp>
<lastRenewalTimestamp>1474181029539</lastRenewalTimestamp>
<evictionTimestamp>0</evictionTimestamp>
<serviceUpTimestamp>1474180884492</serviceUpTimestamp>
</leaseInfo>
<metadata>
<instanceId>eureka-client:8980</instanceId>
</metadata>
<homePageUrl>http://localhost:80/</homePageUrl>
<statusPageUrl>http://localhost:80/info</statusPageUrl>
<healthCheckUrl>http://localhost:80/health</healthCheckUrl>
<vipAddress>eureka-client</vipAddress>
<secureVipAddress>eureka-client</secureVipAddress>
<isCoordinatingDiscoveryServer>false</isCoordinatingDiscoveryServer>
<lastUpdatedTimestamp>1474180884996</lastUpdatedTimestamp>
<lastDirtyTimestamp>1474180884463</lastDirtyTimestamp>
<actionType>ADDED</actionType>
</instance>
</application>
</applications>

이 정보들은 클라이언트가 부트될때 서버로 보내지는 정보들이며, 이는 각 유레카 클라이언트에 전파된다. 이와 같은 동작은 서비스에 어떤 애플리케이션이 얼마나 많은 숫자의 인스턴스로 동작하는지 즉각적인 확인을 가능하게 할 뿐만 아니라, 각 서비스간 연동을 위해 별도의 DNS 체계를 구축할 필요가 없다는 점이다. 유레카를 사용하는 경우, 클라이언트간 로드 밸런싱을 위해 별도의 FQDN을 사용하는 대신 http://EUREKA-CLIENT/your/api/endpoint 의 형태로 요청할 수 있기 때문이다. 

이 유레카 서비스 자체는 각 애플리케이션의 인스턴스 정보만을 공유한다. 이 자체로 "서비스 디스커버리"라는 부분의 역할에만 충실한 마이크로 서비스이며, 이 마이크로 서비스가 제공하는 기능을 통해 다른 컴포넌트들과 유기적으로 연동이 가능하다. 대표적인 것이 Zuul 과 Ribbon 인데, 이에 대해서는 다음에 다시 자세히 설명하는 걸로. 


결론적으로 이 유레카와 같은 도구는 서비스 인스턴스 (서버나 컨테이너와 같은 애플리케이션 기동의 베이스가 되는 리소스들)의 정보 매핑에 예전 레거시에서 사용하던 hosts 나 internal DNS 의 역할과 유사한 동작을 수행하지만 보다 빠르게 리소스의 상태가 변경되는 클라우드에 더욱 맞는 도구라고 할 수 있다. 그리고 이런 도구의 다양한 조합을 통해 애플리케이션의 고가용성을 구현할 수 있다. 스프링 클라우드는, 스프링 개발자라면 누구나 이니셜라이저를 통해 쉽게 유레카와 같은 도구를 사용할 수 있게 한다. 이전에도 언급했지만 Consul 과 Zookeeper 와 같은 도구 역시 스프링 클라우드에 포함되어 있다. 


다음번에는  Config server 에 대해 조금 더 살펴보는 것으로. 

(younjin.jeong@gmail.com, 정윤진) 




Diagnostics, in computer engineering - DiagnOPs

Techs


(정윤진, younjin.jeong@gmail.com) 

Apple Service Diagnostic, ASD

http://www.macrepaircentral.us/powerbook-g4-15-inch-double-layer-sd-10-2005/apple-service-diagnostic-asd.html

2013년 즈음의 일이다. 아마존 웹 서비스에서 솔루션 아키텍트라는 일을 하고 있었을 때다. 저녁에 갈매기살을 구워서 소맥이랑 먹으면 참 좋은 계절이었던 기억이 아마도 가을이었나 보다. 그런 가을날, 나는 어느 대기업의 미팅룸에서 오후 6시에 잡힌 장애 원인 분석과 관련된 미팅에 앉아있었다. 해당 대기업은 아마존 웹 서비스의 고객이었는데 어떤 모바일 서비스의 업데이트에 일반적인 3계층 구조의 서비스를 운영중이었는데 어느날 부터인가 데이터베이스 부하가 한도를 넘기 시작해서 인스턴스 타입을 가장 높은 것으로 옮긴지 얼마 되지 않는 이력을 가지고 있는 서비스였다. 오후 6시부터 미팅을 시작하는 것도 사실 뭐 썩 기쁜 순간은 아니었지만, 그 미팅 시작으로 부터 약 2시간 동안 벌어진 일은 나름 인생의 얇은 고민중의 하나가 되었다. 

회의에는 약 20여명의 엔지니어들과 두어명의 사업 담당이 있었다. 엔지니어들의 구성은 ELB (로드 밸런서) 전문 팀, EC2 (서버) 전문팀, WAS (Web application server) 전문팀, DBA팀, 애플리케이션을 개발했던 개발팀, 그리고 해당 시점의 상황을 해결하기 위해 투입된 "문제 분석" 팀이 있었다. 각각은 약 3~5 명으로 이루어져 있었으며, 회의의 시작은 문제 분석팀에서 지난 1주일간 수집한 각종 서비스 지표를 공개하고 이를 나머지 팀들과 공유하고 토론하는 형태였다. 

서비스에 발생한 문제는 이런식이었다. 밸런서에서는 내부로 포워딩한 요청에 에러가 지속적으로 발생하는 상태였고 (5xx), 인느 웹 애플리케이션 서버로 부터의 응답 지연으로 인한 것이었으며, 이는 데이터베이스로 부터의 응답에 지연이 발생하는 것이었다. 하지만 데이터베이스 팀에서는 우리의 디비 서버는 CPU 자원이 놀고 있는 상태므로 이건 데이터베이스의 문제가 아니다 라고 하는 내용의 회의가 1시간 반동안 진행되었다. 사실, 아마존 웹 서비스의 솔루션 아키텍트는 어떤 문제에 대해 고객이 스스로 문제를 찾게끔 서비스에 대한 이해를 높이는 방식으로 접근해야 한다. (아니 했었다) 따라서 나에게 질문이 돌아오기 전 까지 나는 침묵을 지킬수 밖에 없었고, 회의 시작 15분 후에 공개된 여러가지 서비스 지표에서 이미 답이 나온 것으로 내심 확정하고 있었던 나는 나머지 1시간 30분이 매우 답답할 수 밖에 없었다. 

결론부터 말하면, 문제는 주기적으로 발생하는 EBS 볼륨의 부하였다. 지금은 그런 문제가 별로 없지만 마그네틱 볼륨이 주를 이루던 때였고, 기억을 더듬어 보면 당시 4000이 최고이던 PIOPS 볼륨에 IO queue length 가 매우 높은 상태였지만 EC2 인스턴스에서는 부하 지표가 관찰되지 않는 그런 류의 성능 문제였다. 따라서 나의 권고는 EBS optimized 인스턴스를 사용할것, 필요하다면 EBS PIOPS 볼륨을 여러개 만들어 데이터베이스에 table space 를 적용할 것 여기에서 더 많은 IO가 필요하다면 EBS 볼륨 몇개를 스트라이핑 하여 table space 로 할당하여 사용하되, 주기적 백업을 절대 소흘히 하지 말 것 이었다. 

http://theevansconsultinggroup.com/2015/05/21/the-dangerous-case-of-the-endless-meeting/

이 회의에서 나는 수많은 팀의 수많은 인원들이, 그리고 해당 클라우드 서비스를 충분히 숙지한 사람들이 왜 그렇게 서로 답이 없는 회의를 길게 하는지 몰랐다. 아니 몰랐다기 보다는 이해할 수 없었다. 서비스의 흐름상 디스크 부하가 발생하면 데이터베이스의 응답이 느려지고 이는 모든 서비스의 이상을 설명할 수 있다. 하지만 각각을 담당하는 팀은 자신의 서비스에 문제가 발생했음을 부인하고 있었고 문제 해결을 위해 투입된 팀은 이 팀들에게 직접적으로 어디가 잘못되었다 하고 이야기 할 수 없는 기술적/정치적 상황에 놓여 있었던 것 같다. 


또 다른 일은 2008년 즈음의 일인것 같다. 당시엔 기본적으로 베오울프의 모델을 따르는 분자식 모델을 만드는 계산 클러스터를 모 업체의 요청에 따라 아파트형 공장에 앵글을 짜 넣어서 만들고 있었다. 이 전에 동일한 업체에서 요구했던 60대 클러스터의 성능을 기록적으로 향상 시켜주었던 전례가 있어 해당 업체의 카이스트 출신 사장님께서는 나를 전폭적으로 믿고 클러스터 구현의 용역을 맡겼다. 당시에 계산에 사용하던 툴은 가우시안과 PC Gamess 라는 툴이었는데, 원래 20초 정도 걸려야할 간단한 H2O 계산이 30분이 지나도 안끝나자 사업 진행에 큰 문제가 발생해 해결을 위해 이업체 저 업체 찾아 다녔지만 누구도 답을 주지 못했다고 했다. 그래서 지푸라기라도 잡는 심정으로 당시 개인적으로 상심하여 장돌뱅이처럼 떠돌던 나와 첫 미팅을 하게 되었고, 미팅 시작 20분여만에 답을 주었다. 

이 베오울프 아님

사장은 믿지 않았고, 내가 말한 방법으로 해결 될 수 있는지 확인하고 싶어 했다. 그러자며 나는 콘솔을 달라고 했고, 그 업체 방문전 일하던 회사에서 동일한 문제로 3주를 삽질하다 얻은 결과를 커널 컴파일 옵션에 적용했다. 멀티 코어가 처음 나오던 시절 즈음이었던 것 같은데, 아무튼 커피 한잔과 담배 한대 태울동안 컴파일은 종료되었고, 재시작 된 PC급 서버에서 계산을 돌려보라고 콘솔을 물려주고 난 5분 후 나는 사장의 동그래진 눈과 함께 이후 40분 동안 그 회사의 사업 설명을 들어야 했다. 음, 계산은 20초 정도가 정상으로 추정 했었지만 5초만에 종료 되었고 그 회사의 물리학 박사님 께서는 내가 무슨 옵션을 조정했는지 받아적고 싶어 했다. 기분 참 좋은 묘한 순간으로 기억난다. 

그런 과거로 인해 사장님은 이번에는 250대 규모로 클러스터를 확장하고 싶어했고, 그걸 나에게 맡겼다. 따라서 나는 간단한 BOINC 기반의 리눅스 클러스터를 만들었는데, 그때 기억나는 것이 하드웨어 였다. 당시 나는 검증이 되고 이미 사용중인 하드웨어를 구매하자고 했었으나, 사장은 이번에 AMD에서 새로 나오는 멀티 코어를 (쿼드 코어 초기 제품이었던 것 같다) 싸게 공급 받을수 있다고 해서 그걸 구매하려고 했다. 대당 단가 15~19만원 선의 무지막지한 가격으로 준비된 250대의 서버 같은 PC 를 구성 완료해서 시험 가동하는 순간, 나는 스스로 멋있다는 생각을 하지 않을 수 없었다. 당시 많지 않던 네트워크 부팅, 비지 박스를 사용한 언제든 업데이트 할 수 있는 자동화 구성, 각각 켜지고 꺼지는 상황을 모니터링 할 수 있고, 샘플로 주어진 H2O 계산을 주어진 큐를 통해 내려 받아 완벽히 끝내는 200여대의 아주 저렴한 기계들. 프로젝트 완료는 약 1.5주 정도 소요되었고, 나머지 0.5주는 검사에 사용했다.  

하지만 문제가 찾아왔다. 15분 이상의 작업을 수행하자, 250대중 몇대가 랜덤하게 전원이 꺼졌다. 정말 문제를 찾아내기 위해 수백번은 클러스터 설정을 변경하고 재시작하는 과정을 거쳤던 것 같다. 하지만 이 문제는 특정 서버에서만 발생하는 것이 아니었다. 또 하지만, 반드시 몇대에서는 발생하는 문제였다. 나중에 표를 그려보니 거의 모든 서버에서 발생했다. 

콘솔은 메인 컨트롤 머신에만 있었으므로 커널 패닉이 나는 순간 리모트 로깅 방법도 없었다. 하여 머신 하나가 꺼질때까지 반복적으로 계산을 돌린 결과, 역시 답을 알 수 없었다. 커널의 스택 트래이스는 얻었지만 원인을 알 길이 없었다. 문제를 사장에게 알리고, 하드웨어 점검이 필요하다고 했다. 대량으로 구매한 하드웨어에서 동시에 발생한 문제였기 때문에, 당시의 나는 소프트웨어 문제인지 하드웨어 문제인지 확신할 수 없었다. 그래서 기존에 문제가 없던 60대 중 20여대를 옮겨와 새로운 클러스터에 붙이고 돌렸지만 그 20대에서는 문제가 없었다. 즉, 동일한 소프트웨어에서 문제가 없고 새로운 하드웨어에서 같은 소프트웨어를 사용했을때 문제가 발생한 것이다. 

그 후로 나는 소프트웨어적으로 결함이 없음을 해당 회사의 엔지니어와 함께 확인하고, 그 동안 발생한 문제의 범인을 프로세서로 압축한 후 메인 보드 제작 업체와 프로세서 관련 업체에 압박을 넣어보자고 사장님께 말했다. 그리고 얼마후에 전화를 받았다. (거의 1주일 정도 간격). AMD에서 사람이 와서 프로세서가 불량임을 확인했고 전량 교체받기로 했다고, 수고 했다고. 역시 IT 세상에서는 초도 물량을 대량 구입하는 게 아니..


또 다른 기억나는 사건은 국내 텔레콤 업체의 퍼블릭 클라우드를 만들때다. 당시 SugarSync 라는 도구로 파일 관련 클라우드 서비스를 제공하고 있었는데, 이를 오픈스택의 스위프트로 바꾸는 작업을 하고 있었다. 홀로 지방의 데이터센터에 내려가 추운 환경에서 자동화 코드를 만들고 돌리고 하는 일을 반복적으로 하고 있었다. 지금이야 아마존 S3가 어떻게 만들어져 있는지 관심이 많지 않지만, 2011년 즈음만 해도 클라우드를 만드는 방법에 대해 사람들이 많은 관심을 가지고 있었을때다. 

구조적으로는 단순하게 특정 도메인에 연결된 다수의 프락시 서버가 있고, 이 프락시 서버에서는 주어진 키를 기반으로 업로드된 파일 (또는 오브젝트)을 내부의 단순 jbod 스토리지를 물고 있는 스토리지 서버에 분산 저장하는 형태로 구동 되었다. 다른 것이야 뭐 오픈스택의 패키지와 문서를 자세히 살펴 보면 알 수 있는 것이지만, 이 때 발생한 문제중의 하나는 바로 네트워크 이슈였다. 지금 생각해 보면 구조적으로 BGP v4 가 일부 가능한 L3 스위치가 기본으로 매달려 있었으므로 스토리지 서버와 프락시 서버간 iBGP 와 ECMP 를 사용한 구성을 사용하면 좋았겠지만, 뭐 기본적으로는 단순 chef 에 dhcp 를 묶어 하드웨어를 준비하는 그런 구성이었다. 당연하지만 상용 리눅스를 사용하는 것이 아니었으므로, OS 및 드라이버에 지원을 받기 보다는 가장 무난한 구성을 선택하는 쪽으로 방향을 잡고 진행중이었다. 

문제는 10Gbit Intel NIC 에서 발생했는데, 고가용성을 위해 bonding 과 함께 묶어서 사용하게 되면 간헐적으로 네트워크가 중단되는 현상이었던것 같다. (정확한 문제는 가물가물) 이때는 네트워크에 발생하는 문제가 명확했기 때문에 특정 버전의 커널과 드라이버를 바꾸는 형태로 진단을 수행했고, 결과 문제가 되지 않는 구성을 발견했다. 이때도 정말 다양한 방법으로 문제를 추적했었는데, ethtool 을 사용한 각종 파라메터 변경, 인텔 드라이버의 최신, 구버전 확인, 하드웨어의 직접 교체, 스위치에 딸린 GBIC 교체, 케이블 교체 등을 포함한다. 문제의 진단과 확인에는 서버와 연결된 네트워크 장치의 로그까지 취합하여 함께 확인했고, 결국엔 원인이 드라이버에 있음을 찾아 전체 반영했다. 이것도 일주일 정도 소요 되었던 것 같다. 

https://regmedia.co.uk/2011/03/28/arista_7050_10ge_switch.jpg

사실은 지난 15년 넘는 시간 동안 이쪽 일을 하면서 겪은 장애와 말도 안되는 해결 방법을 목격한 것은 한두번이 아니다. 2000년대 중반에 어떤 회사에서는 닷넷의 소프트웨어적으로 발생한 문제에 윈도우 서버의 모든 시스템 파일을 엎어치워 버리는 무식한 방법을 목격한 적도 있다. 당연히 문제는 해결되지 않았다. 그리고 이런 문제는 매우 다양한 곳에서 발생한다. 캐시의 효과, 디스크의 효과, 프로세서의 효과, 그리고 네트웍과 이들 위에서 돌아가는 각종 소프트웨어들, 데이터베이스 이런 것들은 언제나 문제를 발생시킨다. 이 블로그에서도 psgql의 장애 추적과 윈도우 시스템 메모리 관련 내용이 있다. 밤잠을 설쳐가면서 찾았던 문제들, 하지만 이제는 세월이 흘러 그 문제 해결의 방법이 그대로 적용되지 않을 수 있는 것들. 

진단이란, 여러가지 충분한 지표를 가지고 어떤 문제나 현상을 정상적으로 만들 수 있는 해결 방법을 내어 놓을 수 있어야 한다. 그리고 이것은 데브옵스의 시대라고 해서, 클라우드의 시대라고 해서 서비스 공급자가 다 해결해 주는 그런 양상의 문제가 아니다. 소프트웨어 내부적으로, 또 예기치 못한 새로운 종류의 하드웨어 문제로 인한 문제들. 거의 대부분의 경우는 일반적으로 알려진 문제 해결 방법 (재부팅이라던가) 이 적용되는 경우도 있지만, 그렇지 않은 경우가 더 많은 것 같다. 이는 매우 중요한 서비스 경험이고, 매우 많은 사전 지식과 경험을 요구한다. 하지만 대부분의 현장에서 문제의 해결은 지표와 데이터에 기반하기 보다는 각 개인의 경험있는 "감"에 의지하곤 한다. 이것은 그 해결이 효과를 보았다고 해도 옳은 방향은 아니라고 생각한다. 해결 방법에는 그에 걸맞는 이유가 있어야 한다. 그 이유를 얻기위한 각종 지표가 충분하지 않다면 실험을 통해서라도 그 지표를 얻는 노력이 필요하다. 그리고 조금 더, 아니 아주 많이 복잡해질 근 미래의 소프트웨어 서비스에서는 이런 일을 전문으로 하는 팀이 있어야 하지 않을까 하는 생각을 해 본다. 

DiagnOPs 라는 조직. 개발, 프로세스, 운영등 각각의 단계에서 발생하는 문제에 대해 실험과 테스트를 통해 적절한 해결 방법을 제안할 수 있는 그룹, 팀이 필요하다는 생각이다. 그리고 이 팀의 전문성은 전체 서비스에 문제가 발생하는 동안, 그 중 일부 또는 테스트 환경에서 문제를 재현하고 합당한 해결 방법을 내어놓고, 또 적용할 수 있는 실행력이 있어야 하는 팀이다. 나중에 누가 물어보면 내가 처음 만든 말이라고 해야지. 

그래서 결국 하고 싶은 말은, 이 바닥에도 Dr. House와 그의 팀이 필요하다는 말. 왜냐 하면, 거의 모든 서비스 담당자와 운영자와 개발자는 문제 발생시 거짓말을 하니까. - "우린 아무 문제가 없어요" 


생각나는대로 쓰다 보니 뭐 그냥 그렇지만, 어쨌든 이런 역할이 필요하다는 거. 진단, 분석, 올바른 해결 방법. 그리고 적용 권한. 이것들은 서비스에 대한 사전 및 사후 테스트를 통해 겹겹이 쌓인 해당 서비스에 대한 전문성이 뒷받침 될때 가능하지 않을까 생각해 본다. 

(정윤진, younjin.jeong@gmail.com) 

Cloud software engineering

Techs


(younjin.jeong@gmail.com, 정윤진) 

Meetup을 하고, 중국 두개 도시, 일본 동경, 서울에서 Pivotal Cloud roadshow 를 하고, SpringOne Platform 행사를 다녀오고 각종 회사의 내부 발표와 미팅을 하다보니 어느덧 추석을 목전에 두고 있다. 블로그 작성은 고사하고 써야하는 책 진도가 엄청 밀려서 달리고 달려도 데모의 컨셉과 구현을 병행하다 보니 혼이 나가는 것 같다. 그래도 스트레스는 풀어야겠다고 종종 PS4의 "더 디비전" 으로 지옥이 되어버린 뉴욕 맨하탄에서 악당들을 쏘곤 했다. 어쨌든, 참 시간은 화살과 같다. 


시장, 그리고 엔터프라이즈. 


위의 이미지는 아주 오래전부터 내부 직원들끼리 유머용으로 사용하던 것이다. 기술의 발전과 그 발전을 수용하는 단계에 대한 것인데, 2010년 초반 부터 시작된 거대한 패러다임 쉬프트가 이제 6년째에 접어들어 엔터프라이즈 들에게는 "Oh no" 정도의 단계에 오지 않았나 생각해 본다. 주목할 만한 것은 다른 세상의 모든, 즉 엔터프라이즈를 제외한 세상과 엔터프라이즈의 기술 도입에 대한 그래프의 모양이 다르다는 점이다. 이게 현실 세계의 타이밍에서 묘하게 재미있는 부분은, "Oh fuck" 단계에 들어서면 이전에 주구 장창 이야기 되었던 ROI 와 같은 질문은 더 이상 나타나지 않는다는 점이다. 

국내 클라우드 시장에서, 아마존 웹 서비스의 도입에 대해 이야기를 2012년, 2013년에 하다보면 거의 대부분의 엔터프라이즈 기업들이 데이터센터 운용 비용 및 서버 구매 비용이 어떻게 차이가 나는지 많이 물었다. 그리고 ROI 가 어떻게 개선되는지, 그리고 그 개선에 대한 사례가 없으면 우리는 절대 도입 못할거라고 했다. 비슷한 시기에 만났던 수많은 스타트업과 그리고 게임회사들은 한발 두발 이 기술에 다가서고 있었고 그 동안 어떤 회사들은 보유하고 있는 서버의 숫자의 3년 단위 비용 계획과 아마존 웹 서비스가 제공하는 동일 스펙의 서버 비용을 멋있는 엑셀 차트로 만들어 "아 이거 뭐야 전혀 저렴하지 않잖아" 의 결론을 내고 멀리해 왔다. 

이제 2016년 중반을 지나 말엽으로 가는 마당에 클라우드 도입 자체에 대해 부정적인 의견은 전과 같지 않다. 왜 그럴까. 그것은 애초부터 계산이 불가능했던 ROI 의 효과에 원래 무시되었던 서비스 속도, 확장성, 그리고 자동화를 통한 휴먼 에러의 제거 이런 것들에 대한 가치가 수많은 사례들을 통해 검증되었기 때문이다. 이를테면 3계층 구조의 서비스를 클라우드로 이전하는 방법에 있어 아주 간단하게는 그 모양 그대로 옮기는 것, 주로 지게차를 사용한다는 의미를 가지는 forklift 의 방식을 사용할 때와 이 3계층 구조를 구현 하는데 있어 손쉬운 확장성이 보다 더 낮은 성능의 저렴한 서버를 사용할 수 있도록 하는 구성이 주는 가격적 효과와 같은 것을 깨닫게 되는 것이다. 엔터프라이즈에서는 별로 크게 관심이 없지만, 최근 강력히 대두되는 서버리스와 같은 구조까지 가게 된다면 더 효율적이겠지만 말이다. 

위의 그림처럼 이것이 스타트업과 엔터프라이즈에 대한 문제일 뿐 아니라, 엔터프라이즈 자체도 이제 혁신을 하고 있는 엔터프라이즈와 그렇지 않은 엔터프라이즈로 나뉘고 있다. "Software is eating the world" 라는 말이 나온게 2010여년 즘이고, "Silicon Valley is coming" 이라는 말이 나온건 2015년이다. 이 5년의 차이를 공포로 "인식"하고 있는 J.P. Morgan Chase 같은 회사는 이미 소프트웨어 기술이 그들의 비지니스에 핵심이라는 것을 깨닫고 이 역량 확보를 위한 길에 투자하고 있다. 그리고, 이런 투자는 포츈 500대 기업의 대부분에서 발생하고 있으며, 이들은 아마존과 월마트, 아마존과 메이시 같은 효과에서 아마존 쪽에 서기를 원하는 기업들이다. 그리고 현재 돈을 가지고 있는 기업들이 미래 수익을 놓치지 않기 위해 하고 있는 행동들이기도 하다. 사실, 이런 접근에 최근 한국을 제외한 국가에서 이의를 제기하는 경우는 경험적으로 본적이 거의 없다. 

클라우드 서비스들을 사용이 자유로운 리소스 풀로 사용하는 것은 이제 아주 공통된 개념이다. 당장 하루에 페타바이트씩 쌓이는 데이터를 수용할 수 있는 공간은 여러 방식으로 조달할 수 있겠지만, 별도의 소프트웨어적인 또는 운영적인 노력 없이 바로 사용이 가능한 것은 이미 규모의 경제를 바탕으로 서비스를 제공하고 있는 클라우드 사업자의 서비스를 사용하는 것이 유일한 방법이다. 왜 페타바이트냐, 우린 기가바이트다 라고 하면 이건 이미 엔터프라이즈 규모로 사업을 하고 있지 않거나 그만한 데이터를 모을 수 있는 기술이 없거나 아니면 이전의 운영 방식에 따라서 매일 지우고 있거나일 것이다. 한동안 빅데이터에 대한 가장 큰 거부반응이 우리가 보유한 데이터는 크지 않아요와 비슷하달까. 어쨌든 요점은, 시대는 클라우드 서비스를 리소스 풀로 사용하는 것을 넘어 이 위에 돌아가는 데이터 및 서비스 소프트웨어를 어떻게 만드는가 하는 것에 더 관심이 많다. 즉 프로세서, 메모리, 디스크를 빨리 조달 받는 문제가 해결 되면 이 위에 원래 돌려야 했던 서비스 및 데이터 소프트웨어를 어떻게 처리하는가에 대한 부분의 노력에 관심이 더 많은 시대가 되었다. 아마존 웹 서비스의 사장님인 앤디 제시가 "Cloud is normal" 이라고 말하는데는 여러가지 의미가 있지만, 내맘대로 해석하면 클라우드를 사용하는 것은 기본이라는 말이다. 기본 다음은 무엇인가. 바로, 클라우드 기반의 데이터 운용 및 서비스 소프트웨어 구동, 그것이다. 그리고 그것은 처음부터 그랬듯이, 모든 가치가 있는 곳이다. 

위의 그래프에서 처럼, 엔터프라이즈의 기술 도입 그래프는 빠르게 상승하게 된다. 다만, 이전에 경험을 가진 "세상의 다른 기업"과 동일한 높이를 얼마나 빨리, 그리고 그들이 했던 실패의 반복 없이 어떻게 수행할 수 있을까. 바로 "세상의 다른 기업" 을 넷플릭스나 아마존으로 놓고, "엔터프라이즈"에는 GE를 놓고 보면 된다. 국내의 경우 회사마다 위의 단계가 다 조금씩 다른데, 우리 회사가 "Oh No" 까지 왔다면 이 이야기는 아마 관심이 좀 생기는 이야기가 될 것이라고 예상해 본다. 


뭣이 중헌디 

Value line 이라는 것이 있다. 이것을 대표적으로 설명할 수 있는 것은 바로 "올해 운영체제 튜닝해서 매출 증가를 이루어 회사에서 상 받으신분" 과 같은 질문이다. 대부분의 엔터프라이즈, 뭐 엔터프라이즈 뿐만 아니라 모든 기업은 그 영위하는 서비스와 돈 버는 방법이 있다. 그 서비스의 제공을 위한 운영 체제가 돈을 벌어주는 경우는 없다. 하지만 이것이 중요하지 않다고 할 수 없다. 최신으로 업그레이드 된 운영체제 위에서 견고하게 동작하는 소프트웨어는 강력하다. Value line 은 이것을 누가 어떻게 처리해야 하는지, 그리고 더 깊게는 이런 반복적이지만 쉽게 처리할 수 없었던 것들에 대한 해법이 있다면 과연 사업 성장 및 유지를 위해 어디에 가치 중점을 두어야 하는지에 대한 이야기다. 그리고 이것은 아래와 같은 몇가지 기술 요소들에 대한 고려를 해 볼 필요가 있다. 



첫째로, 그럼 운영체제 업데이트가 서비스 시스템에서 왜 힘들지만 중요한지의 여부다. 답은 간단하다. 위험. 리스크. 운영체제에 긴급한 보안 패치가 필요한 경우, 이 보안 패치를 적용함으로서 서비스에 무슨 문제가 발생할 지 모른다. 정확한 표현으로는, 그 운영체제에서 동작하는 소프트웨어가 이전 버전에서 처럼 제대로 동작할지 안할지를 모른다. 동작하지 않으면 서비스 다운이다. 그리고 이런 종류의 업데이트는 운영체제를 새로 설치하지 않으면 롤백도 쉽지 않다. 그래서 하지 않게 된다. 

하지만 사람들은 방법을 생각해 내게 되는데, 바로 배포 전 테스트를 한다. 머리가 있다면 당연히 사전에 테스트를 한다. 문제는 테스트를 하는 환경과 서비스 하는 환경이 또 다른 모양인 것이다. 사실 테스트 및 운영 환경을 분리하기 본격적으로 시작한 것도 몇년 되지 않는다. '리소스'와 '비용'의 문제 때문에 개발하던 환경이 운영환경이 되었던 사례는 수도 없이 많다. 클라우드는 이런 리소스 문제를 해결 해 왔고, 그래서 각각의 환경을 준비할 수 있었다. 

그렇지만 클라우드를 사용하는 환경임에도 불구하고 버전 업그레이드에 따른 문제는 지속적으로 발생하는데 여기에 가장 중요한 이유는 바로 소프트웨어가 가진 운영체제에 대한 의존성이다. 시스템 라이브러리, 웹 애플리케이션 서버가 제공하는 클래스 패스의 종속성, 그리고 그 시스템  라이브러리가 다시 운영 체제의 커널 버전과 가지는 의존성, 이런 문제들이 발생하고 이는 소프트웨어와 운영체제 및 그에 포함된 기타 라이브러리의 독립적인 업데이트를 보장할 수 없도록 한다. 따라서 각 배포 단계에 항상 서비스 소프트웨어 개발자가 개입하지 않으면 업데이트가 진행되지 않는 사태가 발생하게 되거나, 업데이트 후 문제가 발생하여 화재 진압이 필요하게 되는데 이것은 궁극적으로 업데이트를 꺼리는 환경을 만든다. 

이러한 업데이트를 꺼리게 되는 업무 환경은 사업에 도움이 될 것이 하나도 없다. 그래서, 이런 반복적인 운영 관리 작업을 어떻게 안전하고도 효율적으로 처리할 수 있을지에 대해 고려가 필요하고 이것은 클라우드 서비스가 제공하는 운영체제 템플릿을 교체하는 것 만으로는 여전히 해결되지 않기 때문에 소프트웨어와 운영체제, 그리고 소프트웨어가 사용하는 각종 라이브러리 업데이트 등에 대해 종전과는 다른 방식으로 처리해야 할 필요가 발생한다. 이것이 기본적으로 Immutable artifact 또는 동적 링크보다 static binary 가 대두되는 이유이며, 특정 소프트웨어 버전에 필요한 라이브러리 등에 대해 필요한 버전을 명시해야 하는 이유이기도 하다. 


둘째로 이렇게 빌드된 소프트웨어의 배포에 대한 처리다. 요즘엔 클라우드 종류보다 많은 배포 도구들이 존재한다. 오픈 소스부터 상용에 이르기까지, 선택할 수 있는 도구는 매우 다양하고 각 도구들이 제공하는 범위도 다르다. 이 모든 도구들에 대한 언급 보다는 빌드된 애플리케이션이 인터넷에 연결되어 동작하기 위해서 무엇을 해야 하는가에 대해서 조금 집중해 보기로 하자. 그리고 그것이 세상에서 많이 사용하고 있는 자바를 기준으로 하자. 

자동화 스크립트 또는 도구가 해야 할 일은 먼저 클라우드 서비스에 리소스를 준비하는 것이다. 이것은 보통 가상 머신이다. 가상 머신이 올바르게 준비되어 접근 가능한 상태가 되면, 부트 스트랩이나 또는 ssh 의 방법등을 통해 필요한 패키지를 준비하는데, 예를 들면 아파치 웹 서버나 톰캣과 같은 것이다. 그 준비가 끝나면 이제 젠킨스와 같은 도구에서 빌드된 파일을 전송하여 적절한 디렉토리에 위치시키고 웹 서비스 프로세스를 시작한다. 정상적으로 시작되고, 약간의 테스트가 끝나 동작할 준비가 되면 이 가상 머신을 로드 밸런서에 연결한다. 로드 밸런서가 신규 가상 머신에 대해 정상 동작 여부를 몇번의 테스트를 통해 점검하게 되면 서비스-인 상태가 되어 밸런싱을 수행할 수 있는 상태가 된다. 그리고 필요하다면 이 밸런서에 다시 도메인을 연결하고, 최근 추세에 따라 해당 Zone apex 및 레코드에 대한 TTL 을 짧게 준다. 이게 전부 매뉴얼 스크립트로 구성되어야 하는 것이다. 

하지만 클라우드 서비스들은 서버에 대한 커스텀 템플릿을 만들수 있는 환경을 제공한다. 따라서 매번 새로운 배포를 할 필요가 없이 해당 버전의 소프트웨어가 탑재되고, 톰켓이 이미 설치된 운영 체제를 구성하고 이를 템플릿으로 만들어 추가 웹 애플리케이션 서버가 필요할때 바로 바로 사용한다. 이것은 하나의 immutable artifact 로서 취급될 수 있지만, 문제는 그 제작의 번거로움과 서비스 업데이트 및 릴리즈, 또는 서버에 필요한 설정 변경이 필요할 때마다 새로 만들어 주어야 한다. 심지어 사용해야 하는 원본 운영체제의 버전 업데이트가 반영된 새로운 템플릿이 생기면 여기에 다시 이전에 스크립트로 했던 작업을 수행해야 한다. 그래서 다시 템플릿으로 만들어야 하고, 예를 들어 클라우드 서비스 공급자가 제공하는 오토 스케일 기능이라도 사용하고 있다면 이를 새로운 오토 스케일링 그룹 정책에 반영해 주어야 한다. 하루에 한두번이야 하겠지만, 만약 하루에 서비스가 4천번 업데이트 되는 경우라면 어쩌겠는가. 아니, 그냥 10번만 업데이트 하더라도 이것은 피곤한 일이다. 그리고 이러한 문제는 docker 이미지 생성에도 발생한다. 

언급하고 싶은 문제는 일단 이런 도구들을 다 컨테이너에 넣는것 자체가 약간 비효율이라는 것이다. 하여 스프링 부트(Spring Boot)에서는 스프링을 톰켓에서 구동하는 대신 톰켓을 스프링 부트 애플리케이션에 임베드 하는 방법을 제공한다. 이렇게 Jar 로 빌드된 파일은 java -jar 로 간단하게 실행 가능하다. 당연하지만 SERVER_PORT 와 같은 다양한 옵션 환경 변수를 운영 체제 또는 애플리케이션 시작에 적용할 수 있다는 것이다. java -jar SERVICE-001.jar 커맨드는 컴퓨터를 모르는 우리 어머니도 실행하실 수 있다. 즉, 애플리케이션 레벨에서 immutable artifact 상태로 빌드가 제공되고 이는 JVM만 돌릴 수 있는 환경이라면 동작을 보장하는 방법이 제공 된다는 것이다. 일단 여기에서 회사 위키에 적혀져 있는 500줄짜리 매뉴얼 스크립트를 copy & paste 할 필요가 없어진다. 


이렇게 동작하는 컨테이너 또는 가상 머신에 밸런서를 붙여야 한다. 여기에는 동적 서비스 디스커버리와 마이크로프락시, 그리고 클라이언트간 로드밸런싱의 기법이 오래된 DNS를 대체한다. 강력한 테스트와 한계를 넘나드는 변태적 애플리케이션 아키텍처의 구성으로 유명한 넷플릭스는 이런 도구들을 오픈소스로 제공한다. 서비스 디스커버리엔 유레카(Eureka), 마이크로 프락시 및 API GW 역활에는 줄(Zuul) 및 훼인(이름이 좀 그렇지만, Feign), 그리고 클라이언트간 로드 밸런싱에는 리본(Ribbon) 등이 있다. 유레카는 등록된 애플리케이션에 대한 연결 정보를 서비스 멤버의 모든 인스턴스에 동적으로 공유해 준다. 이렇게 공유된 정보는 API 요청에 따라 동적으로 Zuul 과 같은 도구를 통해 밸런싱 되고 프락싱된다. 아울러, 이 모든 도구들은 스프링 부트의 방법으로 스프링 클라우드 라는 이름으로 제공된다. 이것들은 모두 JVM 위에서 동작하며, Jar 단일 애플리케이션으로서 java -jar 로 구동이 가능하다. 게다가 대부분의 도구는 멀티 데이터센터 레벨로 고가용성 확보가 가능하며, 필요한 경우 암호화 처리 할 수 있다.  

경험상 이러한 동작이 의미하는 바를 개발자 분들께 전달할때, 이게 뭥미 라는 반응을 심심치 않게 본다. 대부분의 경우 고가용성은 사실 애플리케이션의 영역이라기 보다는 운영의 영역인 경우가 많았다. 다른 이야기는 차처하고 나서라도, 위와 같은 도구를 조합해서 사용하게 될때 얻어지는 효과는 기존 운영 영역에서 제공되던 기능들과는 애초에 레벨이 다르다. 예를 들어 넷플릭스의 Zuul 프락시에서는 Canary 테스트가 필요한 경우 특정 API 요청의 일부 트래픽만을 신규 버전의 백엔드에 보낼 수 있다. 즉, 새로운 버전의 배포를 이미 수행해 두고 여기에 동일한 API 요청을 "일부만" 보냄으로서 이게 정상 기능을 하는지 아닌지를 확인할 수 있다. 당연히 이것이 정상이라면 신규 버전을 확장하고 구 버전을 종료한다. 이런 기능이 제공하는 장점은 이런 제로 다운 타임 업데이트 안정성 뿐만 아니라 각종 실험이 가능해지고 이는 더 작은 위험으로 더 많은 일들을 가능하게 한다. 당연하지만, 위에 언급한 스크립트가 따로 필요없는 것은 덤이다. 넷플릭스는 이 도구를 다양한 종류 및 목적으로 트래픽 분배에 사용하고 있으며, 이는 스프링 클라우드로 구현이 되어 있고 따라서 스프링 부트의 사용 방법으로 가져다가 사용이 가능하다. 


셋째로는 최근에 많이 언급되고 있는 컨테이너다. 2013년 초에 다커를 처음 접할 기회가 있었는데, 처음 볼때 아 이거 대박 이라는 생각을 지울 수 없었다. 그 후 몇년뒤, 이건 역시 거대한 흐름을 만들고 있는 도구임에 틀림 없다. 한번 빌드로 다양한 환경에서 구동, 더 효율적인 리소스 사용, 그리고 가상 머신을 신규 배포하는 것에 비해 더 빠른 속도로 확장과 축소가 가능한 점 등등. 그런데 이 부분에 대해 생각할 필요가 있다. Day 1 에 다커는 분명 놀라운 기술이다. Day 2 에 프로덕션 반영을 생각하게 될 정도로. 하지만 현실은 역시 녹록치 않다. 랩탑에서 한두개 올려서 사용하면 분명 대단한데, 일단 수십개, 또는 그 이상 수백개 및 수천개 심지어는 수만개로 돌려야 할때는 어떨까. 현실에서는 많은 것들을 요구한다. 로그의 취합, 적절한 리소스로의 분배, 권한의 관리, 그리고 "업데이트". 예를 들어 하루에 10번 정도 (매우 적은 숫자의) 배포를 수행한다고 하면, 매일 10번 정도의 신규 다커 이미지 생성이 필요하다. 그리고 서비스 별로 약 10-30개 정도의 다커 이미지를 사용하고 있는 중인데 원본 이미지의 업그레이드가 발생하거나 업그레이드를 해야 할 필요가 있을때 이를 모두 새로 이미지로 만들고 또 이 새로운 이미지에서 각 소프트웨어가 무결하게 동작하는지 확인해야 한다. 이런 것들을 지속적으로 유지하다 보면 어느새 현실은 개미지옥. 


따라서 현실적으로 오케스트레이션의 문제를 제외하고 소프트웨어 신규 배포 및 업데이트 만을 놓고 보면 CI 파이프라인 안에 이미지를 동적으로 생성하고 보관해 주는 단계를 구성해 줄 필요가 있다. 즉, 코드가 레포에 올라가고 이렇게 올라간 신규 커밋을 테스트 도구가 받아다가 유닛 테스트 등을 하고 나서 문제가 없이 빌드 되면, 이 빌드된 앱을 다커 이미지로 생성하여 다커 레포로 올리는 단계가 필요하다는 것이다. 물론 RC 관리등의 추가 파이프라인으로 연결할 수 있겠지만, 어쨌든 이런 과정을 현재 수동으로 하고 있다면 근 미래에 이미지 관리에 난항을 겪게 될 것이다. 당연하지만, 여기에는 리모트 로깅, 권한 관리를 위한 툴 등이 빌드된 애플리케이션이 다커 이미지로 생성될때 함께 포함 되어야 한다. 즉, 다소 복잡하지만 정교한 관리가 CI 파이프라인 안에 포함 되어야 한다. 

오케스트레이션 문제를 제외 하지 않으면 문제는 더 복잡해 진다. 물론 다양한 도구들이 나와 있지만 스타트업들 조차 이 다커의 오케스트레이션 구현은 녹록치 않다. 다커의 에코시스템이 발전하는 것은 매우 좋고 선택의 옵션이 다양해 지므로 환영할 일이지만, 현재의 현실 세계에서는 누가 어떻게 이것을 관리하고, 또 다커의 철학인 '한번 빌드로 여러개의 환경에서 구동한다' 를 따라 데이터 센터나 퍼블릭/프라이빗 클라우드에 운영 환경을 준비할 것인가. 물론 각 클라우드 서비스에서는 최근 다커를 운용할 수 있는 환경을 제공한다. 위의 CI 파이프라인과 함께 서비스 업자가 제공하는 환경을 사용한다면 아마도 좋은 접근이 될 것이라고 예상한다. 다만 역시 이 경우에도 언급하고 싶은 것은 과연 이 서비스들에 대한 학습 시간, 누가 배울 것인가, 누가 운영할 것인가, 그리고 서로 다른 서비스가 수백 수천개의 컨테이너를 운용하고 있을때 태그 구분만으로 운영하기에 충분한가, 그리고 이것을 다양한 클라우드 서비스 공급자 별로 제공하는 툴을 따로 배울 것인가 하는 사항들이다. 

클라우드 서비스 공급자가 제공하거나 또는 Chef / Puppet 과 같은 도구들은 물론 인상적이고 훌륭하다. 다만 현장에서 이것들을 최신에 맞게 지속적으로 업데이트 관리해서 배포에 사용하는 경우는... 


넷째로, 마이크로 서비스 이야기를 좀 붙여야 할 것 같다. 마이크로 서비스가 가져다 주는 장점은 서로 관계 없는 기능들이 덩어리 지어 있기 때문에 발생하는 팀간 또는 사람간의 커뮤니케이션과 의존성을 줄이는데 그 목적이 있다. 이를 통해 코드의 양이 적어지고 따라서 운영 관리 및 신규 개발해야 하는 노력이 작아진다. 이는 더 빠른 개발과 배포를 가능하게 한다는 장점이 생기며, 아마존이나 넷플릭스와 같은 회사들이 취하고 있는 방법이다. 하지만 질문도 동시에 생긴다. 외부 요청은 하나인데 내부 서비스 100개에 발생하는 요청 현상, 즉 필연적으로 발생하는 fan out 은 어떻게 해결할 것인가. 현재 조인 관계로 복잡하게 얽힌 데이터 모델을 가진 데이터베이스 안에서 특정 기능들이 스토어드 프로시져로 기능하고 있는 것들은 어떻게 분산해 낼 것인가. 제로 다운타임 업데이트를 데이터베이스 레벨에서 어떻게 처리할 것인가. 각 서비스에 대한 보안 또는 싱글 사인 온등은 어떻게 처리할 것인가. 각 서비스는 서로 다른 개발 스택 또는 프레임 워크를 선택하는것이 옳은 것인가. 운영 관리 방법은 현재도 요청이 많은데 이게 마이크로 서비스로 분산되면 내가 할 일은 더 많아지는게 아닌가. 사람도 안뽑아 주는데. 

먼저 확실하게 말하고 싶은건, 언급한 모든 내용들은 해법이 있고 이는 소프트웨어 아키텍처 및 서비스 아키텍처로 접근 가능한 모델들이 존재한다. 그리고 이러한 모델들에 대해 분명히 학습해 둘 필요가 있고, 이런 경험이 뒷받침 되어야 진정 마이크로 서비스에 대한 접근이 가능할 것이다. 한가지 더 언급하고 싶은 것은, 이런 기법이나 구조를 구현하기 위한 도구들이 넷플릭스에서 만들어 둔 것이 많이 있고 이를 스프링 클라우드에 반영해 둔 것이 많다는 것이다. 

먼저 fan out의 경우, 가능하다면 다운이 발생하지 않는 거대한 캐시풀을 운용하는 방법이 있다. 거대한 캐시풀 이라는 말이 의미하는 것은 예를 들면 아파치 Geode 와 같은 인-메모리-데이터 그리드를 사용하거나, 넷플릭스의 EvCache 를 사용하거나 하는 방법으로 다수의 데이터센터에 존재하는 서버 리소스의 메모리에 중복 저장하여 요청하여 사용하는 방법이다. 예를 들면 수천만명이 로그인을 하고 난 후 발급 받은 토큰으로 다시 다른 마이크로 서비스에 접근이 필요할때 이 검증을 위해 다시 유저 서비스로 접근하지 않고 이 캐시를 사용하는 방법이 있을 수 있다. 이러한 캐시는 비단 캐시의 용도로 사용되는 것 뿐만 아니라 전체 서비스 내에서 일관성을 유지하는 방법으로 사용될 수도 있다. 인 메모리에 저장하는 방법 외에도 분산된 트랜젝션의 로깅과 이를 바탕으로 한 플레이백이 필요한 경우, 이를 테면 이벤트 소싱과 같은 방법을 사용한다면 NoSQL 이나 카프카와 같은 스트림 도구를 사용할 수도 있다. 


조인의 관계는 마이크로 서비스 구조에서는 보통 서비스간 요청으로 처리한다. 데이터베이스 안에서 조인으로 처리하던 것들을 다른 서비스에 대한 요청으로 바꾸는 것이다. 또는 반드시 조인이 필요한 경우라고 하면, 예를 들어 게임이라면 캐릭터와 아이템의 상관 관계와 같은 것들은 아마존의 다이나모 디비와 같은 도구를 사용하는 방법으로 바꿀 수 있다. 세컨드리 인덱스 구성의 변경을 통해 검색 조건에 따라 데이터를 저장함으로서 조인 관계에 대한 극복이 가능하다. 즉, 아이템으로 캐릭터를 검색할 수 있고, 캐릭터로 아이템을 검색해야 하는 조건을 굳이 조인이 아니라 인덱싱으로 처리가 가능하다는 것이다. 그리고 이런 다이나모 디비와 같은 도구의 구현을 참조한다면, 다른 NoSQL 데이터베이스를 사용할 수도 있다. 이런 형태의 데이터 베이스에 대한 구조 및 컨셉은 아마존의 CTO인 버너 보겔스박사(Dr. Werner Vogels) 가 공저한 논문 Dynamo 를 참조하면 더 자세한 정보를 얻을 수 있다. 링크는 여기. (http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) 그리고 이 논문의 아마존 버전이 다이나모 디비이며, 넷플릭스 버전의 구현이 Dynomite 다. https://github.com/Netflix/dynomite 

스토어드 프로시저와 같은 방법으로 데이터베이스 내에서 순차적으로 처리되고, 문제가 발생한 경우 롤백이 필요한 트랜젝션의 구분에 대해서는 자주 사용하는 예인 주문, 결재, 배송을 예로 들 수 있겠다. 여기에는 아마존의 Simple Work Flow 와 같은 도구의 컨셉이 사용될 수 있다. 즉 주문 서비스, 결재 서비스, 배송 서비스는 각각의 데이터 저장소를 가진 각각의 서비스로 별도로 구현되며, 이는 상품의 주문은 주문 서비스가 처리한다. 주문 서비스는 예를 들면 주문 데이터 저장을 위해 MongoDB 와 같은 저장소를 사용하고, 이를 RabbitMQ 나 SQS 같은 큐에 주문이 들어왔음을 알린다. 그럼 이 큐를 subscribe 하고 있는 "다음 프로세스를 담당하는 마이크로 서비스"인 결재 서비스는 기입된 정보를 바탕으로 데이터 저장소 없이 관계된 신용카드 트랜젝션을 처리한다. 이것이 문제 없이 끝나면 다시 RabbitMQ 나 SQS의 별도 채널을 이용하여 주문이 완료 되었다는 메세지와 함께 내용을 큐로 전달한다. 그러면 다시 배송을 담당하는 마이크로 서비스는 이 큐의 내용을 바탕으로 주문 정보를 작성하는 구조가 된다. 각 단계의 마이크로 서비스들은 로그 어그리게이션 또는 로그 스트림의 방법을 통해 처리 결과 및 에러를 취합하고, 자신의 프로세스에 이상이 발생하면 그 이상에 대해 다시 큐에 기록한다. 그러면 알림 서비스는 이 큐에 기록된 에러를 바탕으로 고객에게 어느 단계에서 문제가 발생했으니 주문을 다시 확인하라 라는 메세지를 보낼 수 있다. 

위에 설명한 방법들은 몇가지 기본적인 처리 방법들이다. 그리고 서비스에 따라 이것이 요청을 받은 즉시 처리되어야 하는지 아니면 의미 있는 시간 내에 처리가 되면 되는지에 따라 선택적으로 사용할 수 있다. 그리고 이런 것들이 가능한 이유는 클라우드 기반에서 매우 확장성 있는 메세지 큐나 캐시, 또는 데이터베이스를 구현할 수 있기 때문이다. 또한, 위와 같은 방법들은 전체 마이크로 서비스에 천편 일률적으로 사용되는 것이 아니다. 관계형 데이터베이스로 모든것을 처리하는 것이 아닌, 필요한 상황에 맞는 스토리지를 각각의 서비스가 해결할 문제에 맞도록 선택해서 사용하는 것이다. 넷플릭스는 카산드라를 많이 사용하지만, 그것으로 모든것을 처리하는 대신 EvCache 와 같은 도구를 개발했고, Dynomite 와 같은 도구도 필요했다. 중요한 것은, 마이크로 서비스는 이런 내용을 아주 기본으로 각각의 서비스를 만들고 이 서비스들에 대한 변경을 빠르게 해야 한다는 것이다. 만약 서비스를 잘못 찢어내어서 불필요한 중복이 발생했다면 이를 다시 없애고 다른 형태로 서비스에 반영할 수 있어야 하는 것이지, 무슨 처음 부터 역할을 다 구분해 놓고 팀에 쪼개서 할당하면 구현이 될거라는 방식은 절대 동작하지 않는다. 그리고 마이크로 서비스에 대한 접근에서 클라우드 오퍼레이션에 대한 이해, 즉 운영체제의 업그레이드, 라이브러리의 업그레이드 및 트러블 슈팅등과 같은 방법이 제공 되지 않는다면 이것은 분명 오퍼레이션 비용에 대한 수직 상승을 불러올 것이다. 클라우드 파운더리가 가지는 핵심 장점 중 하나가 여기에 있다. 

마이크로 서비스에 대해서 마지막으로 하고 싶은 말은, 언제 해야 하는가 이다. 기존의 모놀리틱 방식으로 개발된 애플리케이션이 충분히 작다면 마이크로 서비스를 해야 할 이유가 없다. 다시 이를 좀더 엄밀히 말하자면, 애자일 개발 방법을 이미 사용하고 있는 상태에서 해당 서비스를 개발하는 팀의 인력이 바뀌거나, 누군가 슬럼프가 갑자기 오거나 하는 별다른 문제가 없는데 속도가 떨어지고 있다면 이때를 기존 서비스에 분리가 필요한 시점이라고 볼 수 있다. 언제 무엇을 해야하는지에 대한 결정은 반드시 데이터 지표가 있어야 한다고 생각한다. 


위에 언급한 내용들에 대해 별도의 견해나 해법이 있을 수 있다. 이 글을 쓰고 있는 목적은 순전히 경험의 공유이며 이것들이 실제로 동작하는 서비스가 있고 또 기존의 서비스에서 다운타임 없이 마이그레이션 할 수 있는 방법도 있다. 그것이 바로 클라우드의 매직이 아닌가. 그리고 우리에게 필요한 것은 이런것에 집중하는 것이지, 웹 애플리케이션 설정과 업그레이드가 아니라는 것이다. 


그래서 결론은 (Pivotal) 

모든것은 비지니스다. 멀티 데이터센터 또는 멀티 클라우드를 하려는 이유가 무엇인가. 사업적으로 무중단이다. 마이크로 서비스로 구성된 넷플릭스에서 서킷 브레이커 로직이 필요한 것은 무엇인가. 특정 장애의 고립을 통한 전체 서비스 장애 확산 방지다. 데이터베이스 클러스터링을 통해 아무리 견고하게 구성해도 그것이 하나의 덩어리로 되어 있다면 서비스가 데이터베이스 장애를 데이터베이스 만으로 고립할 수 있는가? 아닐거다. 따라서 수많은 리소스를 쉽게 조달 받을 수 있는 클라우드를 기반으로 서비스에 필요한 리소스를 효율적으로 사용하고 그 위에 클라우드에 맞게 기능을 하는 서비스 소프트웨어를 얹는 것이 바로 클라우드 네이티브의 본질이다. 

마지막으로 클라우드 파운더리에 대해 언급하고 싶다. 현재 클라우드 서비스의 도입과 사용에 대해서 열기가 뜨겁다. 대부분의 경우 클라우드를 배운다는 것은 어렵다. 퍼블릭 서비스들은 각자의 운영 방식이 있고 인터페이스가 다르고 사용하는 언어가 다르다. 프라이빗 서비스 역시 마찬가지다. 이는 모든이에게 모든것을 알게하는 동시에 풀스택 개발자라는 말을 탄생시켰다고 해도 과언이 아니다. 모든이가 모든것을 아는것이 과연 가능한 일인가. 클라우드 파운드리는 이 문제를 해결한다. 개발자가 다커를 배울 필요가 없고 운영자가 개발자의 요청에 의해 데이터베이스와 네트워크를 준비하고 업데이트 때문에 곧 다가올 추석에 밤 새는 일을 없도록 한다. 위에 언급한 대부분의 운영적 문제로 발생하는 그리고 반복적으로 발생하기 때문에 새로운 서비스의 시장 공개를 더디게 하는 문제를 해결한다. 그리고 이것은, 각 클라우드 서비스를 별도로 배울 필요가 없도록 하기도 한다. Multi-AZ 에 대한 개념은 필요하지만 그것이 꼭 Multi-AZ 라는 이름으로 특정 서비스에서 사용 된다는 것을 학습하는 것은 필요 이상의 노력이다. 뒤쳐져서 갈길 바쁜 엔터프라이즈에게 스프링과 클라우드 파운더리는 value line 아래의 일에서 조직을 해방시킨다. 

쓰다보니 간만에 굉장히 장문의 글의 되었지만, 어쨌든 다음의 내용을 검색을 통해 알아보기를 강권한다. 그래도 아직 못다쓴 내용은 나중에 책으로 더. 새벽에 졸릴때 썼으므로 문장이 좀 이상한 것들은 양해를 구합니다. ㅠㅡ ㅠ 


1. 넷플릭스 오픈소스 및 넷플릭스 테크 블로그 

2. http://concourse.ci  http://ci.concourse.ci 

3. Pivotal Cloud Foundry 

4. http://start.spring.io  http://cloud.spring.io 

5. Micro services

6. https://www.youtube.com/watch?v=GTnRl_BIkzc  

7. https://run.pivotal.io 

8. SpringOne Platform 2016 videos https://www.youtube.com/watch?v=xdw_9dADM-4&list=PLAdzTan_eSPQ1fuLSBhyB4eEZF7JQM0Mx


(younjin.jeong@gmail.com, 정윤진) 

Open source serverless - what?!!

Techs


(younjin.jeong@gamil.com, 정윤진) 


이전에 AWS 에서 다닐때 했던 기획으로 10만원으로 월 10만명 사용자 받기 이런거를 해보자는 아이디어를 냈었다. 물론 아이디어를 내고 나서 퇴사하는 바람에 다른 분들이 다른 이름으로 진행 했었지만, 어쨌든 요는 무지 저렴하게 서비스를 구현해보자 라는 것이었고, 그러한 아키텍처의 중심에 '서버리스' 라고 불리는 즉 서버가 없이 구현하는 아키텍처를 그렸다. 물론 샘플로 동작하는 코드도 쓰다가 말았지만 ㅋ. 


이것이 제공하는 장점은 크게 두가지로 보는데, 하나는 '내가 관리해야 할 인프라가 별도로 없다' 라는 것이고, 두번째는 '비용이 무지막지하게 저렴하다' 라는 것이다. 그리고 이는 스타트업과 같이 사람과 돈이 귀한 조직에서 엄청난 반향을 일으키고 있다. 이 '서버리스' 아키텍처는 Lambda 를 통해 비로소 완서이 된다. 많은 사람들이 AWS 의 다른 서비스인 API Gateway 와 연동하거나, S3, Kinesis 와 같은 다른 AWS 서비스로 부터 이벤트를 받아 트리거링 되어 동작하도록 구성한다. Lambda 는 서비스가 지원하는 몇가지 언어를 사용해 코드를 만들어 올리면 이벤트에 의해 트리거 되어 60초간 해당 코드를 실행할 수 있는 일종의 플랫폼으로 보면 된다. 가격 역시 100ms 단위로 과금하기 때문에 시간당 과금하는 버추얼 머신보다 저렴하게 사용할 수 있다고 설명되는 것이 일반적이다. 



금일 소개할 내용은 바로 이 Lambda 와 유사한 형태의 도구를 오픈소스로 동작할 수 있는 새로운 것이 나타나서 포스팅한다. 단, 이것에 대해 프로덕션 도입을 하는 것은 현재로서는 추천하지 않는다. 또한 서버리스는 개인적으로 CSP 에서 제공하는 또 다른 형태의 플랫폼이고, 이것은 보통 규모의 경제를 확립한 서비스 제공자에 의해 제공이 될때 가격적 잇점이 발생할 수 있다는 점 또한 잊어서는 안된다. 많은 이들이 동의하는, 또 개인적으로도 동의하는 생각은, 서버리스 자체는 일종의 다커 신드롬과 무엇이 다른가 뭐 그런 의견이 있다. 


요약하면, 현재 인기 있거나, 인기를 얻을 가능성이 있는 도구들은 거의 대부분 인프라에 대한 별도의 작업 없이 코드를 빠르게 배포하려는 것들이며, 수많은 도구 중 하나로, 우왕 Lambda 가 오픈소스로? 이런게 나왔네 정도의 느낌으로 보시는게. 


아무리 봐도 엔터프라이즈 레벨에 당장 사용 가능한 도구는 Cloud Foundry 가 유일한듯. (기승전피) 



https://blog.leveros.com/introducing-lever-os-d10a857f210e#.dd2qiwcvz 


서버레스 컴퓨팅이 뜨거운 감자가 된지는 좀 되었다. 그리고 이게 왜 뜨거운 감자인지 알게되는건 그다지 어렵지 않다. 클라우드 기반의 애프리케이션 개발에 대한 요구는 나날이 늘어만 가고 있는데, 실제 이 요구를 수용할 수 있는 DevOps 는 시장에 많지 않다. Stack Overflow 의 설문에 의하면 개발자 대 DevOps 의 비율이 30:1 에 달한다고 한다. 다른 데이터에서는 더 심한게 70:1 이라고 말하는 곳도 있다. 어쨌든지 맞건 틀리건 간에 이런 지표들은 두 직군의 기술의 격차, 그리고 그때 그때 발생하는 운영 업무에 대한 트렌드를 보여준다고 생각한다. 


서버리스 컨셉은 이러한 문제를 해결하는데, 왜냐면 애플리케이션을 확장성 있게 개발하고 배포하는데 별도의 DevOps 가 필요 없기 때문이다. 하지만 이런 기술은 오로지 AWS, Azure, Google Cloud Platform 과 같은 클라우드 서비스 공급자에 의해서만 사용이 가능했었는데, 이는 당연하게도 해당 클라우드 서비스 공급자에 대한 락인, 그리고 로컬 머신이나 로컬 데이터센터에서는 사용할 수 없다는 문제가 있다. 


... 지금까지는. 



Lever OS 소개 


(해당 블로그에서 가져온 글이므로) 우리는 오늘 Lever OS 버전 0.1 을 발표하게 되어 매우 기쁘다. Lever OS는 오픈소스 서버리스 플랫폼으로, DevOps 가 없이도 마이크로 서비스 구조의 백엔드를 개발하고 배포할 수 있는 도구다. 이는 복잡한 인프라 구성에서 개발자들을 자유롭게 하고, 확장에 대해 투명한 뷰를 제공하는 강력한 빌딩 블록을 제공한다. 


Lever OS를 사용하면, 서버에 대해 생각할 필요가 없다. 서비스에 대해서만 생각하면 된다. Lever 는 코드를 인스턴스에 적재하여 요청에 따라 가능한 많은 노드에서 구동한다. 또한 라우팅과 로드밸런싱 트래픽을 투명하게 처리해 주기 때문에 별도의 컴파일된 리버스 프락시를 사용할 필요가 없다. 다 들어있기 때문에. 





복잡한 백엔드의 형태를 지원하기 위해 다양한 레이어를 구성하는 것도 가능하다. 각각의 서비스를 서로 다른 팀들에게 관리하도록 함으로서 다른 서비스들에 대한 서로의 책임을 한계적으로 명시할 수 있다. 또한 이 모든 것들은 내장되어 있는 RPC 시스템을 통해 연동할 수 있겠다. 



각가의 서비스는 소규모의 export function 으로 개발되어 Lever 위에 배포할 수 있다. 자바스크립트를 예로 들면, .js 파일에 export function 을 지정하고 Lever 에게 해당 자바스크립트 파일을 지정하는 형태로 동작한다. 그리고 이 function 은 서비스의 API 가 될 것이며, HTTP 를 사용하여 트리거 되어 동작한다. 


또한 Lever OS 는 오픈소스이기 때문에 이를 랩탑에서 사용할 수도 있다. 따라서 다른 서버리스 도구들과 다르게 매번 클라우드에 배포할 필요가 없어지기 때문에 로컬에서 매우 빠르게 개발 및 테스트 사이클을 사용할 수가 있다. 이렇게 개발된 코드는 일관성을 제공하기 때문에, '내 머신에서는 돌아갔는데' 타입의 버그에 대해서도 자유로울 수 있다.  



간단한 예제 코드 


"Hello, <name>!". 을 응답하는 백엔드 서비스를 만든다고 치자. Lever OS 에서는 해당 문자열을 리턴하는 JS function 을 하나 만들고 간단한 설정 파일을 구성하면 된다. 



 



배포는 다음의 커맨드로. 


$ lever deploy



이게 전부다. 이제 이 서비스를 아래의 영상에서와 같이 다양한 방법으로 호출해서 사용할 수 있다. 



본 도구에 대해서 더 궁금하다면, Lever OS 의 GitHub 페이지에 들러보면 되겠다. 


이는 Lever OS 의 최초 릴리즈다. 따라서 우리는 앞으로도 지속적으로 개선할 것이며, 이 개선에 중요한 것은 여러분의 피드백이다. 아울러 현재로서는 베타 상태이며, 문제를 경험한다면 Github 이슈 페이지에 등록해 주기 바란다. 



(younjin.jeong@gmail.com, 정윤진)