Lettuce는 synchronous, asynchronous, reactive usage를 지원하는 scalable thread-safe한 Redis Java client 입니다.
lettuce — IntroductionLettuce is a scalable thread-safe Redis client for synchronous, asynchronous and reactive usage. Multiple threads may… redis.paluch.biz
Micro Service Architecture(MSA)를 적용하면서, 앞단의 Gateway의 Discovery영역에 redis로부터 active instance를 read하는 부분에서 Jedis를 사용하였지만 Jedis는 Multiple threads상에서 connection pool 성능이 생각보다 만족스럽지 않았고 차선책으로 Lettuce를 사용하였고 결과는 만족스럽습니다.
요즘 주위에 애자일(특히 스트럼)로 프로젝트를 진행하는 곳이 많아지고 있지만, 대부분은 실패로 마무리 됩니다. 이유는 무엇일까? 방법론을 올바르게 숙지하지 못해서? 아니면 팀 문화가 따라주지 않아서? 아래의 내용은 개인적인 생각임을 미리 밝혀둡니다. 저는 “사기(士氣)”의 문제라고 생각합니다. 스크럼을 이용할 경우 아래의 장점들을 취할 수 있습니다.
위의 장점들은 그냥 만들어지는 것이 아닙니다. 스크럼의 근본 취지는 work 시간에 제한을 두고 최대한 생산성을 끌어내는 것이 핵심입니다. 추정을 통해 작업 시간을 정하고 스프린트를 진행하게 됩니다. 만약, 추정이 틀렸다면 인공적으로 만들어진 스프린트를 완수하기 위해서 과부하가 걸리던지 프로세스를 속이는 플래닝을 해야 합니다. (스프린트의 변경은 수많은 미팅을 통해야 하지요)
틀린 추정이 빈번해지고 이런 상황들이 계속 발생하게 되면 사업쪽은 기술쪽이 목표를 놓치고 있다고 생각할 것이고 기술쪽은 사업쪽이 목표를 변경하고 있다라고 생각할 수 있습니다. 이렇게 되면 양쪽다 사기가 꺽이게 됩니다.
그리고, 진척 사항의 시각화로 인해 개발팀은 컨트롤을 받고 있다 혹은 도구가 된 것 같다라는 느낌을 받을 수 있고 이 또한 사기에 영향을 주게 됩니다. 그렇다고 여유로운 스프린트를 수행하게 되면 관리의 리스크에 직면하게 됩니다. 스크럼의 규약이 우리팀에는 적합하지 않다라는 판단이 들었습니다. 우리는 다시 생각할 필요가 있습니다. 애자일이 나오게 된 배경이 무엇이었는지에 대해서… 개인적으로 느낀 스크럼에 대한 대안으로 칸반을 고려하게 되었습니다.
칸반 프로세스는 스크럼에 비해 단촐합니다. 칸반을 이용하게 됨으로써 스프린트 플래닝이 사라지게 되었고 PO(사업팀)에서는 “To Do”만 관여하게 되고 나머지 보드는 기술팀이 관리를 하게 됩니다.
즉, “To Do”의 일거리가 개발팀으로 push 되는 것이 아닌 pull하는 당김 방식으로 업무가 흐르게 됩니다.
칸반으로 작업의 흐름을 보기 위해 Asana를 활용합니다. (얼마전에 Kanban view 기능이 추가됨) 팀간의 Communication은 Glip을 활용합니다.
회의를 최대한 줄이고 Online 커뮤니케이션을 통해 해결하려고 합니다. 칸반에서는 Work-In-Process (WIP)의 제약을 지키는 것이 핵심입니다.
스크럼의 경우에는 스프린트별 작업량을 제한하지만 칸반은 작업 구간별 작업량을 제한하게 됩니다. 능동적인 팀일 경우에는 이는 큰 생산성으로 다가 옵니다.
칸반은 스크럼에 비해 규칙이 작습니다. 그렇기 때문에 개선하는 노력이 필요합니다.
onem2m release 2가 published 되었다. 관련하여 webinar가 진행됨. 등록은 이곳에서 => https://www.brighttalk.com/webcast/11949/226333
Websocket proxy가 필요한 케이스가 생겼다. 일반적으로는 독립된 proxy server를 통해 지원하면 되지만, Servlet단에서 지원을 해야 하는 상황이다. 아래의 그림처럼 제공되는 것이 중간의 Gateway를 통해 Communication이 되어야 하는 상황이다.
가장 편하게 할 수 있는 방법은 jetty-proxy library를 이용하는 방법이다.
이미 구현체가 존재하기 때문에, 필요한 부분만 customizing하여 Servlet으로 등록하면 된다.
Cloud Computing의 발전으로 인해 과거와는 달리 더 이상 많은 인력이 필요없게 되는 것 같다. 구글 트렌드에서 “programmer”와 “software engineer”의 검색량을 2004년 부터 현재까지 추출해보았다.
점점 검색량이 줄어들고 있다. 예전에는 리눅스 전문가, DB 전문가, Backend 전문가, Frontend 전문가 등등이 필요했지만, 이제는 적은 인력으로 충분히 해결 가능하다.
이런 현상이 발생한 이유중에 하나는 “Serverless” 일 것이다. (아직 초창기이긴 하지만…) Serverless는 서버가 없다라는 의미가 아니고, 관리해야 할 Server가 0으로 수렴한다는 의미이다.
즉, 서비스 단위의 코드를 개발하고 배포에 집중하겠다라는 기술이라고 볼 수 있다. 이런 점이 기존의 PaaS와 대비되는 특징이다.
다가올 Serverless의 시대에도 예전의 전문가라는 직종이 남아있을지 의문이다.
우리는 어떤 준비를 해야 할까?
MQTT Broker를 선정시 고려할 사항을 정리합니다. MQTT는 서비스 품질(QoS)에 대해서 3가지 레벨의 신뢰성을 제공합니다. 일반적으로는 QoS 0를 선택하고, Application Level에서 처리하고 있습니다.
MQTT 보안에는 크게 Authentication, Authorization 부분과 Network 그리고 Payload 검증 부분으로 나눠집니다.
MQTT Broker를 사용하는 Subscriber의 Backend server가 같은 기능을 갖는 여러대로 구성되는 Case가 존재합니다. 이럴 경우 Subscriber Server 앞단에 HAProxy를 이용해서 한대의 서버만 message를 받도록 할 것인지, 아니면 Broker에서 제공하는 Exclusive 기능을 이용할 것인지 고려해야 합니다.
그 외에, Integration 부분도 고려해야 합니다.
현재 진행중인 프로젝트는 폐쇄적이다. 다시말하면 폐쇄망 환경이다. Maven의 Central Repository는 꿈도 꾸지 못하는 환경이다. 내부 Nexus를 통해서 3rd party library를 지원해야 한다. 이런 환경에서 굳이 Maven을 사용해야 하는지에 대해서 의구심을 가지는 사람들이 있다. Ant와 Maven중 어느 것이 더 나은가?는 논쟁거리이지만, 본 글에서는 몇 가지의 차이점을 명확히 하고자 한다.
Ant는 고전이다. 빌드 프로세스로서는 훌륭하다.
Maven은 Apache Turbine 프로젝트의 빌드를 단순화하기 위해서 탄생했다. Apache Turbine 프로젝트는 여러 프로젝트마다 Ant 빌드와 Jar파일들이 있었고 이런 환경들이 빌드를 복잡하게 만들었고 프로젝트가 점차 커져감에 따라 프로젝트를 관리하고 빌드하는 표준 방법이 필요하게 되었기 때문에 Maven이 세상에 나왔다.
끝으로, Ant는 오랫동안 자바 빌드의 최고 자리를 지켜왔고 여러 곳에서 현재도 널리 쓰이고 있다. 반면에 Maven은 프로젝트 관리 플랫폼 그 이상이다. 빌드 관리 작업을 간단하게 해주고 프로젝트 사이의 공통 인터페이스를 조성하는 것을 도와준다. Maven은 빌드 도구 그 이상의 것(a set of standards, 공통 인터페이스, Life cycle, standard repository, layout..,)을 포함하고 있다.
폐쇄망 환경에서 Library 등록이 귀찮다는 이유로 Maven을 사용하지 않는일이 없길 바란다.