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을 사용하지 않는일이 없길 바란다.
오늘날 네트워크 기술은 널리 활용되고 있고, 전용 네트워크 어플라이언스 장비들을 가상화 네트워크에서 동작 시키기 위한 NFV(Network Function Virtualization) 기술이 각광을 받고 있습니다. NFV는 기존 장비들을 동일한 성능에서 지원한다라는 전제 조건이 있습니다. 일반적으로 우리가 Native환경에서 어떤 프로그램을 사용하는 것과 가상화 환경에서 사용할 경우에는 Performance의 Gap이 존재하게 됩니다.
DPDK는 Intel에서 개발한 고성능 패킷 처리 소프트웨어로 고속 패킷 처리를 위한 라이브러리와 드라이버를 제공하고 NFV의 네트워크 성능을 높이기 위한 핵심 기술입니다.
DPDK의 특징:
기존 Kernel에서 네트워크 패킷을 처리하는 방식과는 다르게 응용 어플리케이션이 User Space의 DPDK 라이브러리를 사용하여 직접 엑세스한다는 점이 특징입니다.
즉, 응용 어플리케이션을 특정 CPU core에 할당하여 가장 높은 우선 순위로 실행하고, Kernel을 거치지 않고 직접 네트워크 카드의 패킷을 처리하게 되면 네트워크 성능을 비약적으로 향상 시킬 수 있습니다.
이런 장점을 갖고 있는 DPDK도 단점은 존재합니다.
DPDK를 이용하는 응용 어플리케이션을 적용할 경우에는 아래의 사항을 고려해야 합니다.
옆에 계신 정모 부장님이 요 근래에 Batch 관련 가이드를 준비하고 계신다. 모듈당 N개의 Batch 프로그램이 있다고 하면, 각각 Executable 형태로 제공하는 것이 좋을 것인가? 아니면 관리적 측면에서 Grouping 하여 제공하는 것이 좋을 것인가에 대한 의견이 분분하다.
이런 경우에는 각 모듈별로 하나의 Batch 프로젝트를 구성하고 수행해야 할 Job Method 호출을 캡슐화(Encapsulation) 하는 것에 대해서 공감대가 형성되었다.
지인의 지인이 지인일 확률이 높은 이유는 무엇일까? 한 사람이 일반적으로 몇 명이나 알고 있을까? 이 질문에 대해 미국인과 일본인을 대상으로 설문조사가 실시되었다고 한다. 그 결과 평균 지인 수는 미국인은 200–300명, 일본인은 150명 정도였다.
스몰 월드 효과란 모르는 사람을 최종 목표로 설정하고 지인만을 이용하여 연락을 취할경우 5–6명을 거치면 목표 인물에 도달할 수 있다는 실험 결과에서 나온 개념이다.
친구와 지인은 어떻게 정의할 수 있을까? 어떤 사람은 술잔을 주고 받으면 친구라 여길 것이고, 어떤 사람은 인사만 나누는 사이면 친구라 여길 것이다.
이처럼 관계에 대한 정의는 사람마다 주관적일 것이다. SNS는 이런 제약에서 자유롭다. 관계 형성 및 유지의 부담, 경제 합리성에서 자유롭기 때문이다.
Clustering = a와 b와 지인, b와 c와 지인인데, a도 c를 안다면 클러스터링 규모가 커짐 클러스터링 규모가 클수록 몇개의 특이한 링크 지점간의 path길이가 단축되는 것을 스몰 월드 효과라고 정의함.
의외로 우리는 좁은 세상에 살고 있으므로, 서로서로 감기 조심 합시다.
좀 오래된 얘기지만 버지니아 대학에서 만든 “The Oracle of Bacon(http://oracleofbacon.org)”사이트가 있다.
이 사이트는 일종의 영화배우에 대한 데이터베이스이다. 영화에 출연한 배우이름을 입력하면 Bacon Number를 알려준다.
Bacon Number의 의미는 영화배우 “케빈 베이컨”과 함께 영화에 출연했는지에 대한 여부와 출연 횟수를 기준으로 둘 사이의 거리를 측정하고 그 배우가 케빈 베이컨까지 몇 단계만에 연결이 되는지를 나타내는 수이다.
헝가리의 수학자 폴 에르되시(Paul Erdos)는 세계 각국의 수학자들과 공동 연구를 하였고 발표한 논문은 약 1500편이다.
이 정보를 기준으로 에르되시 제자들은 에르되시에게 0이라는 수를 공동 저자에겐 1, 공동 저자들과 함께 공동 연구한 저자들은 2 ….. 이렇게 수를 계속 지정해보았더니 유명한 수학자들 대부분은 2~5사이의 에르되시 넘버가 나왔다고 한다. 이 아이디어는 관계에 적용될 수 있고, 페이스북이 재밌게 이 문제를 풀어냈다. 일하는 곳에서도 이 아이디어는 적용된다.
니콜라스 크리스태키스, 제임스 파울러의 <행복은 전염된다="">의 책에서는 행복과 불행도 전염된다고 한다. 시뮬레이션을 해보면, 프로젝트 참여자가 하는 말과 행동은 관계를 통해 파도처럼 물결치며 나아간다. 그리고 대략 ½/3단계의 관계까지 영향을 미친다.
얼핏 보기에는 이런 효과들은 별로 중요하게 보이지 않을 수도 있다. 수학적으로 분석한 연구결과를 보면, 관계자의 행복이 나에게 영향을 미치는 정도가 ½/3단계(약15%/10%/6%), 불행은 약50%/25%/15%라고 언급하고 있다.
결국, 프로젝트 참여자들간에는 알게모르게 서로간에 주기적으로 자극을 주고 있다. 그것이 행복이든 불행이든…
-오늘 불행의 자극을 준 나…