elasticsearch

엘라스틱서치가 쉬웠던 이유

제목이 너무 도발적인가? 지금 이순간에도 대규모, 대용량 환경에서 성능 등의 문제로 골머리 썩는 분들에겐 죄송(..) 하지만 엘라스틱을 데이터 분석툴로 활용하는 입장에서는 쉬우니 쉽다고 할 수 밖에. 처음 접한 건 작년 여름, 데이터 분석 서비스를 제공하는 logz.io를 통해서였다. 사실 데이터 분석 분야에서 엘라스틱이라는 오픈소스가 유행이라는 얘기는 들어왔지만, IDS 등 사실

허술함을 가장한 애자일(느슨한 서비스)

서비스 개발자라면 한번쯤은 이런 생각을 해 봤을 겁니다. 페이스북은 그렇게 많은 사용자의 요청을 어떻게 처리할까? 알리바바는 광군제 하루에만 27조 이상의 매출이 나고 있는데 이런 미친듯한 주문 트렌젝션은 어떻게 처리할까? 위챗은 8억명의 Active 사용자가 있다고 하는데 이들 메시지는 어떻게 지체 없이 전달될까? 물론 다양한 분산 기술과 캐쉬, 수만 또는 수십만대 이상의

조직 문화를 소프트웨어 개발 조직답게 만들어가기

정확히 이러한 문화를 뭐라 불러야 할지 모르겠다. 기민한 개발조직으로 만들려고 혹은 시장에서 도태되지 않기 위한 간절한 변화의 노력으로 지난 2년간 만들어낸 우리 조직[1]의 개발 문화에 대한 이야기다. 뭉뚱그려 말하면 애자일이라 할 수 있겠으나 애자일이라는 말의 쓰임이 너무나 다양하게 쓰여지고 있어 의미를 얼마나 전달할까 싶다.  아무튼 일을 해나가는 과정속에서

[입 개발] 전문가는 계속 공부하는 사람이다. – 김창준님의 개발자 실력 평가 어떻게 할 것인가 후기

안녕하세요. 입개발 CharSyam입니다. 둘째가 100일을 넘어서 저녁 약속 없는 신데렐라 시간을 하다가, 김창준님이 “개발자 실력 평가 어떻게 할 것인가?” 에 대해서 강의하신다고 해서 마님에게 애교를 부리면 허락을 받고 세미나를 들으러 왔습니다. 평소 입개발자는 입개발의 단계를 올리기 위해서 부단히 노력해야 하며, 혀로 키보드 치기, 입에 발린 소리하기등을 연습해야 하는데, 개발자 실력

내 서버에는 누가 들어오는걸까? (실시간 user-agent 분석기)

Desktop 및 스마트폰의 대중화로 다양한 OS와 브라우저들을 사용하게 되었다. 이때, 내가 운영하는 웹서버에 들어오는 사람들은 무슨 기기로 접속을 하는 것일까? 혹여 특정 OS의 특정 브라우저에서만 안되는 버그를 잡기 위해 몇일밤을 고생하며 겨우 수정했는데… 과연 그 OS의 브라우저에서는 접속은 하기나 하는걸까? (ㅠㅠ)  만약, 접속 사용자의 Device 정보를 알고있다면 고생하며 버그를 잡기

대용량 환경에서 그럭저럭 돌아가는 서비스 만들기

이번 글은 지난 주에 국내 모 인터넷 커머스 회사에 강의 했던 발표 자료 입니다. 발표 주제는 제가 중국에서 1년 몇개월 정도 지내면서 경험한 것들에 대한 정리입니다. 아직도 국내 많은 분들이 중국에 대해 불편한 시각을 많이 가지고 계시고, 기술, 제품의 완성도 측면에서 한국 보다 떨어진다고 생각하시는 분들이 많이 있습니다. 하지만 알리바바

마이크로서비스

마이크로 서비스는 왜 점점 더 각광을 받을 수 밖에 없을까?

예언자처럼 말했다. 확실히 그럴 가능성이 높기 때문이다. 주식처럼 살 수 있다면 마이크로 서비스가 늘어난다에 여유 재산을 다 쏟아 부어도 좋다. 그런 확신이 어디에서 비롯된 것인지 여러분과 공유하는 것이 이 글의 주제다. 마이크로 서비스는 사업 전개 속도의 문제 현재 내 직업 일상은 비즈니스 속도를 높이는 일이다. 단언컨대 소프트웨어를 잘 활용하면 굴뚝

JAVA 8 에서 케이크 패턴(Cake Pattern)을 사용해보자

지난 글에서 의존성 주입(Dependency Injection)에 대한 이야기를 했었다. 이번 글에서는 다른 방식의 의존성 주입인 케이크 패턴을 소개한다. 스칼라의 케이크 패턴에 대한 자세한 내용은 여기를 참고 바란다. 케이크 패턴 스칼라의 케이크 패턴을 자바에서 사용해보자. 케이크 패턴은 의존성 주입의 한 방법이다. 자바 8에서는 인터페이스가 구현 코드를 담은 디폴트 메소드를 가질

테스트 용이성(Testability) 향상을 위한 DI(Dependency Injection)

이전 포스팅 BDD(Behaviour-Driven Development)에 대한 간략한 정리에서 같이 다루려고 했던 내용이다. 하나의 클래스를 테스트하기 위해서는 그 클래스가 사용하는 다른 클래스의 실제 구현이 필요하거나 테스트 대상 클래스가 사용하는 데이터베이스 등에 대한 외부 환경이 구성되어 있어야 하는 경우가 있다. 하지만 테스트 환경에서 이를 모두 구성하는 것은 현실적으로 쉽지 않고,

이 버그는 개발한 너의 잘못이야?

조용하던 사무실에 난데 없이 이런 고성이 터져 나옵니다. 필시 운영 중인 서비스나 배포된 앱에서 심각한 문제가 발생하였습니다. 이 프로그램 누가 만들었어!!! 이번 글은 최근 페이스북에 한 분이 질문하신"개발자가 실수로 버그를 만들었습니다. 여러분이 상사라면 어떻게 하시겠습니까?" 글에 대해 필자의 생각을 정리해 보았습니다. 이 버그는 개발한 너의 잘못이야? 특정

REST API 날짜/시간 표현 정하기

2달전 제 뒤에 앉아았는 개발자님께서 왜 알아보기 어렵게 날짜를 숫자로 사용해야하냐고 의문을 가진 적이 있다. API를 처음 구성할 때 참고했던 API가 사용했다는 이유로, spring 400에러 응답에서도 long 형태의 시간표현을 한 사례, Timezone과 DB처리에서 장점이 있다는 이유로 적용했던 Unix Time형태의 날짜 표현방식이 문제가 될 수도 있다는 생각이 들었다. 그렇게 불편하다면 한번

BDD (Behaviour-Driven Development)에 대한 간략한 정리

BDD와 테스트 용이성에 대해서 간단히 정리가 필요해서 하는 김에 포스팅으로 올린다. 한 번에 하려고 했는데 생각보다 양이 많아서 우선 BDD에 대해서만 정리한다. BDD가 TDD만큼 유명세를 타지는 않은 거 같은데 현업에서 두 가지 모두 사용해본 경험상 BDD를 선호한다. 여기서 BDD는 Behaviour-Driven Development의 약자고 TDD는 Test-Driven Development의 약자다. 어차피 BDD가