오픈소스 오케스트레이션 툴 특징

참고 : https://www.oreilly.com/ideas/swarm-v-fleet-v-kubernetes-v-mesos?cmp=tw-webops-free-lp-promo_swarm_v_fleet_v_kubernetes_v_mesos_article , http://stackoverflow.com/questions/27640633/docker-swarm-kubernetes-mesos-core-os-fleet

DevOps라는 단어의 대두와 함께 소프트웨어의 개발 뿐만 아니라 서비스의 운영이 개발 프로세스에서 중요한 비중을 차지하게 됨에 따라 다양한 클라우드 인프라 오케스트레이션 툴들이 나오게 됐는데 크게 Docker 이전의 경우 상용툴로 Chef와 Puppet 이후는 Swarm, Fleet, Kubernetes 그리고 Mesos를 들 수 있을것이다.

사실 이런 툴들이 없는 전통적인 방식의 개발, 운영 시스템에 DevOps를 해야 한다면 가혹한 환경에 놓이게 될 가능성이 매우 높겠지만 이런 툴들은 언제든지 새로운 소프트웨어를 제공 할 수 있는(Continuous Delivery)환경을 만드는데 도움을 주고 있는 것 처럼 보인다.

기존의 인프라는 머신 각각에 대해 신경을 썼다면 새로운 툴들은 시스템은 언제든 문제를 일으킬 수 있다고 보고 문제가 발생한 요소를 제거하고 새로운 백업 시스템으로 교체하는 형태로 발상의 전환이 이루어진 점이 특징이라고 볼 수 있다. 물론 오케스트레이션 툴을 이용하기 위해선 기존의 어플리케이션의 설계도 맞춰서 바뀌어야 하겠지만...

오케스트레이션 툴을 통한 제로 다운 타임, 자동 장애 복구, 서비스 확장을 위한 사전 프로비저닝 된 지원 시스템 그리고 보편화 된 서로 다른 데이터센터와 지역에서의 서비스 운영이 가능해진 시스템은 전통적인 시스템과는 달리 매우 매력적으로 보이지만 각 툴에 대한 충분한 이해가 필요하다는 것을 간과해서는 안된다.

다음은 각 툴을 선택할 때 고려할만한 특징에 대해서 간략히 정리해 보았으며 컨테이너(Docker와 같은..)를 스캐줄링 할 것인지 머신(EC2 인스턴스와 같은..)을 스케줄링 할 것인지와 같은 차이가 있으며 내용은 다음과 같다.

Swarm

Docker의 표준 API를 사용하는 툴로 기존에 Docker Compose와 같은 스크립트를 이용하는 환경이라면 상대적으로 적은 리소스를 투입하여 통합할 수 있지만 복잡한 스케줄링을 위한 커스텀 인터페이스 정의가 어려워 질 수 있다. 주요 구성요소로 머신에 설치되어 컨테이너를 스케줄링 하기 위한 매니저와 에이전트가 있다.

Fleet

CoreOS의 클러스터 관리 툴로 Kubernetes와 같이 추상화 단계가 높은 툴과 비교해 로우레벨 클러스터 엔진으로 분류되며 리눅스의 init을 대체하기 위해 나온 systemd위에서 동작하는 툴이다. Fleet은 단순한 레이어를 갖으며 Kubernetes와 같은 상위 레이어의 툴의 베이스가 될 수 있다. 머신간의 통신은 Etcd를 통해 이루어지며 장애에 유연하게 대처할 수 있도록 디자인 되었다. 만약 머신중 하나가 죽는다면 해당 머신에서 스케줄링 되던 유닛(컨테이너와 같은..)은 새 머신에서 재시작 할 수 있다. 네트워크 소켓을 통해 즉각적인 컨테이너 구동이 가능하다는 장점을 가지고 있다.

Kubernetes

구글의 서비스는 모두 컨테이너 기반으로 제공되고 있으며 이것을 가능하게 하는 것이 Borg인데 Kubernetes는 구글에서 Borg를 오픈소스로 공개한 대규모 컨테이너 시스템을 스케줄링 하기 위한 툴이다. Kubernetes는 몇가지 추상화된 개념들을 제공하며 서비스 추가나 복제와 같은 확장성을 제공하고 장애에 유연한 대처가 가능한 강력한 툴이지만 어플리케이션이 이를 충족시키기 위해 재 디자인 되어야 한다. Kubernetes가 제공하는 강력한 기능이 궁금하다면 링크의 영상을 보길 추천한다.

Mesos 

아파치의 Mesos는 수백에서 수천개의 머신으로 구성된 대규모 클러스터 관리를 위해 개발 되었으며 Twitter, eBay 그리고 Airbnb와 같은 회사들이 사용하고 있다. 대규모 클러스터 구성을 기본으로 하다보니 다수의 사용자에 대한 워크로드를 지원하는 것이 특징이며 Fleet과 같이 로우 레벨 클러스터 엔진으로 분류되며 스케줄러로 Marathon, Kubernetes 그리고 Swarm과 같은 툴을 이용할 수 있다. 12개 이하의 머신 노드를 이용하는 경우라면 필요 이상으로 복잡한 솔루션이 될 수 있다.

5월 2주차 소식들..

보안

7-zip의 사용자의 권한을 취득할 수 있는 결함이 발견되어 16.00의 패치가 나왔다는 소식.. 링크

플레시 플레이어의 보안패치 소식.. 개인적으로는 사용안한지 꽤 되었지만.. 윈도와 맥은 21.0.0.242 리눅스는 11.2.202.621로 업데이트를 권장한다고.. 링크

Jenkins의 보안 패치로인해 플러그인의 파라메터 전달방식이 변경되어 플러그인들이 정상적으로 동작하지 않는 문제가 있다고.. 현재 권장되는 버전은 2.3과 LTS 1.651.2인데 보안 위협에 노출 되기는 하지만 기존 방식을 유지하는 hudson.model.ParametersAction.keepUndefinedParameters 프로퍼티에 true를 사용하거나 hudson.model.ParametersAction.safeParameters 프로퍼티에 화이트리스트 파라메터를 지정할 수 있다고.. 링크

하드웨어

웨스턴디지털의 샌디스크 인수소식.. 조만간 WD 브랜드의 SSD와 메모리스틱 들을 보게 될듯한.. 링크

소프트웨어

OS X El Capitan 10.11.4 업데이트에서 프리징 현상을 겪는 사용자가 많다는 소식.. 나만 그러는줄 알았더니 아니었.... 2015년 전반기에 발매된 13인치 레티나 맥북프로가 유독 문제가 잦은 편이라고.. 링크

파이어폭스의 테스트파일럿 프로그램에 대한 소식.. 파이어폭스에서 제공하는 시험적인 기능들을 사용해 볼수 있으며 관심 있는 분들은 다음의 링크를 참고하시면 됩니다.. 링크

Debian 프로젝트의 32-bit 구형 x86 CPU의 지원 중단 소식.. i386부터 586/686 하이브리드 타입까지가 대상이며 커널 4.3부터 686 프로세서 부터 지원하도록 변경되기 때문에 중단 대상에 포함되는 시스템을 사용중이라면 안정버전인 Jessie를 사용하라는 소식.. 링크

5월 1주차 소식들..

소프트웨어

리눅스 커널의 네트웍과 관련하여 과도한 패킷 버퍼링으로 인해 응답시간 지연과 대역폭 저하를 유발하는 Bufferbloat문제 해결을 위한 추가 패치가 커널 4.7에 포함되었다는 소식.. 안정버전 커널에도 백포트 될 것으로 보인다고.. 링크

보안

이미지 처리용 툴인 ImageMagick의 보안 결함에 대한 소식.. 특별히 제작된 이미지를 이용한 해킹 방법에 대해 정리된 ImageTragick이라는 사이트도 나온 상태이지만 패치는 아직 안된 상태이고 정책 파일을 통해 문제를 임시적으로 막는 방법까진 나온 상태.. 해당 라이브러리를 사용하는 웹 플러그인 중에 대표적인 것으로 PHP imagick, Ruby rmagick, nodejs imagemagick이 있다고.. 링크 링크

OpenSSL의 패치 소식.. 1.0.2h와 1.0.1t 버전이 나왔는데 낮은 위험의 버그들을 조합해서 좀더 큰 버그를 만들어내는 케이스가 발견되어 다수의 버그 패치가 이루어 졌다고.. 링크

SHA-1 암호화 방식의 인증 시스템의 취약성 때문에 브라우저 제작사들이 SHA-1 방식을 이용하는 사이트는 차단할 예정인데 MS의 경우 Windows 10 1주년 기념 업데이트부터 IE11과 Edge에서 SHA-1 방식을 이용하는 사이트는 더이상 자물쇠 아이콘이 나타나지 않고 내년 2월부터는 차단할 예정이라고. 구글과 모질라는 이보다 빠른 올해 7월부터 차단에 들어갈 것으로 보인다는 소식.. 링크

Spring Transaction의 Propagation과 Isolation에 대해..

참고 : http://stackoverflow.com/questions/8490852/spring-transactional-isolation-propagation , http://www.byteslounge.com/tutorials/spring-transaction-propagation-tutorial , http://www.byteslounge.com/tutorials/spring-transaction-isolation-tutorial

헷갈릴 땐 라이브러리의 소스코드의 각 타입별 주석을 참고해도 되지만 이참에 정리하자 싶어서 작성합니다. Transactional 어노테이션의 propagation과 isolation 항목에 대한 설정 정보에 대해 알아보도록 하겠습니다.

PROPAGATION

비지니스 메소드가 호출될 때 자기 자신과 내부에서 호출 된 Transaction(이하 tx)간에 어떻게 상호 작용할 것인지에 대한 상태를 정의 하는 항목으로 다음과 같은 설정들이 존재 합니다.

• REQUIRED : 해당 상태가 선언된 메소드가 실행 될 때 tx가 존재 한다면 공유해서 사용하고 그렇지 않다면 새 tx를 생성해서 사용합니다. 만약 내부에서 호출 된 메소드가 자신과 마찬가지로 REQUIRED가 선언된 상태라면 자신과 내부 tx각각은 논리적으로는 구분 되지만 물리적으로는 하나의 tx가 됩니다. 내부에서 호출 된 메소드의 tx가 롤백 된다면 자신을 포함한 물리적인 하나의 tx가 롤백 되는 구조를 만들 수 있습니다.
• REQUIRES_NEW : 해당 상태가 선언된 메소드가 실행될 때 항상 새로운 물리적인 tx를 생성하고 해당 tx가 롤백 된다고해서 물리적으로 분리된 다른 tx가 롤백 되지는 않습니다. 만약 내부적으로 새로운 tx가 시작 된다면 자신의 tx는 잠시 정지 되었다가 내부 tx가 종료된 시점에 이어서 수행되게 됩니다.
• NESTED : 자신과 내부 tx들이 하나의 물리적인 tx를 사용하지만 내부에서 호출된 NESTED tx들에 savepoint를 세팅하는 형태 입니다. 그렇기 때문에 내부의 NESTED tx중 하나가 롤백이 된다고 하더라도 자신이 롤백 되지는 않습니다. 이 기능은 JDBC savepoint를 통해 구현되기 때문에 Spring JDBC로 관리되는 tx를 사용할때만 써야 합니다.
• MANDATORY : 해당 상태가 호출될 때 열려있는 tx가 반드시 존재해야하며 그렇지 않으면 컨테이너에서 예외를 던집니다.
• NEVER : 해당 상태가 호출될 때 열려있는 tx가 반드시 존재하지 않아야 하며 그렇지 않으면 컨테이너에서 예외를 던집니다.
• NOT_SUPPORTED : 해당 상태는 tx의 범위에 포함되지 않는 것을 수행합니다. 만약 열려있는 tx가 존재 한다면 해당 tx를 잠시 멈추고 작업을 수행합니다.
• SUPPORTS : 열려있는 tx가 이미 존재한다면 해당 tx에 포함되어 수행되며 만약 열려있는 tx가 존재하지 않더라도 수행은 되지만 tx와 관계없이 처리 됩니다.

주의할 점들..

• 기본적으로 tx을 롤백 상태로 만들기 위해서는 unchecked exceptions를 필요로 하며 checked exceptions를 이용하기 위해서는 별도의 설정이 필요합니다.
• Transactional 어노테이션만 선언된 메소드(Declarative transactions)에서 동일한 Bean 내부의 다른 메소드를 직접 호출할 경우(Self-invocation) 컨테이너에 의해 Transactional 선언이 무시되기 때문에 이경우는 aspectj를 사용해서 구성해야 합니다.

ISOLATION

ACID tx 요소 중 isolation 레벨에 대한 설정으로 특정 위치의 데이터에 대해 동시 다수의 tx가 존재 할 때 해당 데이터에 어떻게 접근할 것인지에 대해 정의할 수 있습니다.

• READ_UNCOMMITTED : 여러 tx가 동시에 x라는 데이터에 접근 할 때 x에 변경이 일어난 시점과 읽는 시점에 따라 롤백 여부와 상관없이 변경된 값을 읽는 더티 리드(dirty reads)를 허용하는 상태입니다.
• READ_COMMITTED : 더티 리드의 문제는 없지만 동시에 x라는 데이터에 접근할 때 타임라인 상 A라는 tx에서 x를 읽은 후 tx가 종료 되기 전에 B라는 tx에서 x를 변경후 커밋을 하게 될 경우 A에서 x를 다시 읽는 케이스가 존재 한다면 처음 읽은 x의 값과 나중에 읽은 x의 값이 다른 문제(non-repeatable reads)가 발생하게 됩니다.
• REPEATABLE_READ : 하나의 tx에서 단일 레코드를 여러번 읽는 경우 결과가 항상 같아야 하는 상태이며 dirty reads와 non-repeatable reads 문제를 제거할 수 있습니다. 하지만 범위 스캔을 하는 경우 tx A에서 범위의 조건이 0-20 사이의 값을 읽고 tx A가 종료되기 전에 tx B에서 0-20사이에 레코드를 추가하게 된다면 tx A에서 0-20 사이의 값을 다시 읽었을 때 tx B에서 추가한 레코드(phantom records)가 포함되는 팬텀 리드(phantom reads)의 문제가 있습니다.
• SERIALIZABLE : 가장 제한적인 상태이며 읽기, 범위 스캔, 쓰기에 tx락을 거는 형태입니다. 앞서 언급한 모든 문제를 해결할 수 있지만 tx의 동시성을 허용하지 않아 퍼포먼스 패널티를 지속적으로 증가시키는 문제가 있습니다.
• DEFAULT : DBMS에서 정의된 Default Isolation 레벨에 대한 상태를 적용합니다.

각 isolation 레벨이 갖는 문제를 요약하면 다음과 같습니다.

• READ_UNCOMMITTED : dirty reads, non-repeatable reads, phantom reads
• READ_COMMITTED : non-repeatable reads, phantom reads
• REPEATABLE_READ : phantom reads

4월 4주차 소식들..

보안

인기있는 업무용 메신저인 Slack의 보안 토큰을 Github과 같은 공개된 저장소에 올려서 보안위험에 노출된 경우가 많아 Slack측에서 발견된 토큰을 폐기하고 발행자와 관련 팀 담당자에게 연락을 하고 있다고.. 주로 봇 통합 용도로 많이 사용된 것 같다는데 보안 토큰을 공개된 장소에 공유하는 건 좀.. 음.... 링크

소프트웨어

Node.js 의 6.0 버전 소식.. 5.0과 다르게 10월부터 LTS 지원을 할 예정이라고.. 추가로 ECMAScript 2015 지원 정보 챠트.. 링크 링크

Linux의 /dev/random LRNG 패치에 대한 이야기.. 기존 방식과 차이점으로 가상화 환경이나 SSD를 사용하는 환경에서도 부트 타임에 충분한 엔트로피를 제공하고 대규모 병렬 시스템에서 엔트로피 수집에 대한 충격을 제한하며 /dev/urandom과 get_random_bytes에서의 큰 성능 향상등이 고려되고 있다고.. 링크
 
Nginx 1.10 Stable 버전이 발표 되었다는 소식.. 스트림 모듈, HTTP/2, 다이나믹 모듈 지원등이 특징이라고.. 링크


기타

특허 트롤에 대응하기 위한 시스템에 대한 소식.. 미국의 발행되거나 출판된 특허에 대한 공개정보를 마이닝 해서 앞으로 나올만한 가능성이 있는 특허 정보를 조합해서 사전에 공개하는 All Prior Art 라는 시스템에 대한 이야기가.. 링크 링크

하드웨어

구글 OnHub 라우터의 IFTTT 지원 소식.. IoT와 홈오토메이션의 중심이 되지 않을까 추측은 했었는데 IFTTT를 지원하게 될 줄은... 영상 링크를 보는편이 어떤게 가능해 지는지 바로 와닿을 듯한.. 링크

AMD의 서버관련 x86과 SoC 관련 IP의 중국 라이선싱 소식.. THATIC이라는 조인트 벤처인데 중국이 반도체 관련 사업에 꽤 적극적인 모습을 보이고 있어서 어떤 형태로 칩이 나오게 될지는 모르겠지만 중국내 FAB육성과 함께 자국내 IT기업들이 서버에 사용할 제품을 만들려는 것 같아보이는데 Intel과의 라이선스 문제는 없다고 그러고 Intel에겐 새로운 경쟁자가 추가되는 상황이라 탐탁치는 않을 듯... 링크

4월 3주차 소식들..

보안

오라클의 4월 정기패치 릴리즈 소식.. 49개 제품에 139개의 결함에 대한 패치가 릴리즈 되었다고.. 링크

Git 2.7.4 이하 버전에서 원격 코드 실행 공격과 관련한 결함이 발견 되었는데 맥의 커맨드라인 툴의 최신버전에 Git이 2.6.4가 포함되어 있어 문제가 된다는 소식.. 개인적으론 Homebrew를 통해 최신 버전을 사용중인.. 링크


소프트웨어

Windows 10 패스트링에 1주년 기념 버전 기능을 포함한 레드스톤 빌드 14328이 배포됨.. 이번 빌드에서 드라이버 모델에 뭔가 변화가 있었는지 일단 AMD의 최근 디스플레이 드라이버는 화면을 제대로 드로잉하지 못하는 문제가 있고 앞전 버전부터 사운드 컨트롤쪽 문제는 여전하고.. 메인 장비가 맥북 프로라서 롤백 안하고 디스플레이 드라이버는 마소 베이직 드라이버를 쓰고 있는데 이번 버전은 드라이버 쪽에 이슈가 좀 많은 느낌이.. 링크

리눅스 커널 스케줄러의 멀티코어 환경에서 성능문제에 대한 논문을 기반으로 패치가 적용되는 배포판이 나오기 시작 했다는 소식.. 링크 링크

Reactive Java 참고 자료들..

6월에 Spring Framework 5가 나올 예정인데 Reactor 프로젝트의 스프링 적용 버전인 Spring Reactive가 포함되어 나올 예정임. Spring Framework 4.3 부터 선행 적용하기로 되서 미리 사용이 가능한데 간략히 설명하면 기존의 멀티쓰레드 방식 코드에 이벤트 루프 방식이 추가되는 형태라고 볼 수 있는.. 단적으로 Node.js의 경우는 싱글쓰레드 이벤트 루프 방식임.

Spring MVC에서 서비스 클래스 영역까지는 비동기 코드 작성에 대한 패턴들이 나와 있었는데 이제 컨트롤러까지 확장되는 추세이고 데이터소스 영역도 이미 NoSQL 데이터베이스 같은 경우 Non-block I/O를 지원하는 JDBC 드라이버들이 제작되고 있는 상황.

기존에 Java의 비동기 코드가 .NET에 비해 깔끔하지 못하다는 해외 커뮤니티의 평가가 많았는데 여기에서 모티브를 얻은 RxJava가 인기를 끌면서 RxJava의 Spring 버전인 Spring Reactive가 메인스트림에 합류하는 분위기.

선행 학습을 위해 참고한 자료들의 링크를 남깁니다.

메인 동영상은 기존의 레거시 코드를 Java 8으로 마이그레이션 하는 방법에 대한 내용을 다루는데 주로 Stream을 이용한 람다코드와 Consumer를 이용한 리소스 관리에 대한 이야기를 하고 있다. 강연 내용중에 기억에 남는 글귀가 있는데 "A good code is like a story not like a puzzle." 이라는 말이.. Spring Reactive에 대한 자료는 이곳 을 참고할 수 있고 관련자료의 슬라이드 링크를 포함하고 있다. 슬라이드 중 Reactive Web Applications에 대한 강연 영상은 이곳 에서 확인할 수 있고 서블릿에서 비동기 서블릿의 진화 과정에 대한 간략한 내용과 Reactive Stream에 대한 이야기를 담고 있다. Spring Boot와 RxJava를 이용해 RESTful API를 만드는 방법에 대한 내용은 이곳 에서 확인할 수 있고 Observable을 이용한 데이터 핸들링과 컨트롤러의 비동기 응답과 테스팅에 대한 힌트를 주고 있다. Spring Reactive의 REST 컨트롤러 구성에 대한 코드 예제는 이곳 에서 확인 가능하다.