[개요] 아파치 하둡 3.1.0
여는 글 최근 아파치 하둡 3.1.0의 출시로 HDFS 의 Erasuere Coding 외에 분산 자원 관리자인 YARN에 특히 실용적인 기능들이 적용되었는데, 어떠한 기능들인지 차근차근 소개하겠습니다. 먼저, 공식 사이트에 게시 된 개요로부터 시작 하겠습니다. 개요 이 글에서는 주요 변경 사항에 대한 간략한 개요를 제공합니다. * YARN 기반에서 장기 실행 서비스들을 native와
여는 글 최근 아파치 하둡 3.1.0의 출시로 HDFS 의 Erasuere Coding 외에 분산 자원 관리자인 YARN에 특히 실용적인 기능들이 적용되었는데, 어떠한 기능들인지 차근차근 소개하겠습니다. 먼저, 공식 사이트에 게시 된 개요로부터 시작 하겠습니다. 개요 이 글에서는 주요 변경 사항에 대한 간략한 개요를 제공합니다. * YARN 기반에서 장기 실행 서비스들을 native와
여는 글 최근 재미나게 본 영화인 Ready Player One 의 한 컷으로 글을 시작합니다. 이 영화에서 처럼 저와 독자분들께서도 자신의 인생에서 보지 못한 것을 볼 수있는 통찰력을 갖게 되기를 희망합니다. 독서 시간 : 3분 | 발췌... 글의 제목에서 알 수 있듯이, 이 글은 Spark Streaming 입문서가 아닙니다. 솔직히 이 글은 Spark 및
Desktop 및 스마트폰의 대중화로 다양한 OS와 브라우저들을 사용하게 되었다. 이때, 내가 운영하는 웹서버에 들어오는 사람들은 무슨 기기로 접속을 하는 것일까? 혹여 특정 OS의 특정 브라우저에서만 안되는 버그를 잡기 위해 몇일밤을 고생하며 겨우 수정했는데… 과연 그 OS의 브라우저에서는 접속은 하기나 하는걸까? (ㅠㅠ) 만약, 접속 사용자의 Device 정보를 알고있다면 고생하며 버그를 잡기
마이크로서비스
예언자처럼 말했다. 확실히 그럴 가능성이 높기 때문이다. 주식처럼 살 수 있다면 마이크로 서비스가 늘어난다에 여유 재산을 다 쏟아 부어도 좋다. 그런 확신이 어디에서 비롯된 것인지 여러분과 공유하는 것이 이 글의 주제다. 마이크로 서비스는 사업 전개 속도의 문제 현재 내 직업 일상은 비즈니스 속도를 높이는 일이다. 단언컨대 소프트웨어를 잘 활용하면 굴뚝
2달전 제 뒤에 앉아았는 개발자님께서 왜 알아보기 어렵게 날짜를 숫자로 사용해야하냐고 의문을 가진 적이 있다. API를 처음 구성할 때 참고했던 API가 사용했다는 이유로, spring 400에러 응답에서도 long 형태의 시간표현을 한 사례, Timezone과 DB처리에서 장점이 있다는 이유로 적용했던 Unix Time형태의 날짜 표현방식이 문제가 될 수도 있다는 생각이 들었다. 그렇게 불편하다면 한번
최근에는 개발을 할때 단순히 기능만 동작하는 코드를 만드는 것뿐만 아니라 읽기 좋은 코드, 유지보수하기 좋은 코드 등을 만들기 위해 많은 노력을 한다. 이를 위해 코드 리뷰 등을 통해 동료 개발자들이 직접 검토하는 경우도 있지만 정형화된 패턴에 대해서는 소스 코드를 분석해주는 도구를 이용할 수 있다. 이러한 것을 코드 정적 분석이라고 한다.
마이크로서비스
한 친구가 이렇게 요청했다. 아래와 같이 바꿔보면 개발자들 사이에서 흔히 들을 수 있는 패턴이다. OOO 공부하게 책 하나 추천해주세요. 내 동료 장재휴는 이렇게 말했다. 진짜 공부하고 싶으세요? 그러면 팝잇에 있는 글이 제일 좋아요. (돈 들일 필요도 없는데...) 공교롭게 질문을 받기 직전에장재휴가 나에게 말했다. 사람들이 팝잇에 올라온 마이크로 서비스 글이 정말
개발자
책을 읽다가 전에 써둔 글이 떠올라 찜찜했다. 이글을 쓰는 현재 시각 무려 328개의 페이스북 좋아요를 기록하고 있는 아키텍트는 필요없다, 아키텍처를 이해하는 전문가가 필요할 뿐[1]에 대한 것이다. 서울대 공대 교수들이 지적하는 아키텍트 부재 연말부터 축적의 시간이란 책을 다시 펼쳤다. 현재까지 반 정도[2]밖에 읽지 않았지만, 아키텍트 부재를 대한민국의
마이크로서비스
지난 해 썼던 마이크로 서비스 구축 경험 공유 그리고, 김 형준님 시각으로 쓰여진 Micro Service, Docker로 할 수 밖에 없었던 사연에 빠진 내용을 써서 공유하고 싶다. 쓰기에 앞서 독자 입장에서 어떤 효용이 있을까 의심스러워 몇 가지 질문을 해본다. * 다른 이의 경험은 얼마나 전달될까? 또, 전달 여부는 무엇으로 확인할 수 있을까?
요즘은 AWS ( Amazon Web Service ), GCP ( Google Cloud Platform ), Azure 를 이용하면 쉽고 저렴하게 테스트 환경 구축할 수 있습니다. 그러나, 개인적으로 틈틈히 테스트 환경을 구축하는 경우에, 장시간 인스턴스를 죽이지 않아서 생각지도 않은 과금눈탱이을!? 맞아 본 분들이 많을 겁니다. 저같이 매달 카드명세서를 꼼꼼이 보지 않거나, Invoice 메일을 무시하다 보면 거지꼴을 못면합니다.
중국 이커머스 최대 행사인 쐉쓰이(双十一)때 11월11일 0시가 되자마자 매출이 급상승함과 동시에 이벤트가 미친듯이 순식간에 몰려드는 것을 보고, 일 년 전 밤을 지새우며 O2O 시스템을 Event driven 방식으로 바꾸느라 고생했던 순간이 떠올랐다. 쐉쓰이의 분위기는 동료가 쓴 글인 개발자가 바라본 중국 쇼핑 축제 쐉쓰이(광군제)에 생생하게 나타나 있다. 실제
사람마다 자기만의 이야기가 있다. 이제 공유할 이야기는 이제 막 모델링을 시작한 개발자 이야기다. 그는 북경에서 무려 특급 열차高铁로 7시간 떨어진 곳에 근무하는 원격 개발자이고, 내가 매우 좋아하는 중국 개발자[1]다. 얼마 전 그는 새로운 서비스 개발 착수 미팅을 하려고, 북경에 방문했다. 그 때, 한 시니어 개발자가 그에게 작년처럼 그냥