[개발생각] 아파치 카멜 사용 후기
아파치 카멜을 본격적으로 써봤다. 스프링배치를 사용하려고 했는데, 이런저런 이유로 아파치 카멜을 사용하게 됐고, 후기를 남겨본다 카멜 vs 스프링배치 카멜은 DSL방식의 이벤트의 흐름을 정의하고, 이벤트의 라우팅을 쉽게 해주는 여러 컴포넌트를 제공하기에, 실시간성 이벤트 처리에 적합하다. 스프링배치는 청크단위 배치사이즈단위의 롤백처리라던가 재처리등을 할수있고, 이런 기능등을 활용하여 좀더 대용량처리에 적합하게 사용할수있다는 장점이 있지만, 실시간성 처리 (즉, 실시간으로 바로바로 처리를 해야하고, 최악의 경우는 문제가 되는 데이터처리는 스킵하면서, 실시간 처리를 해야할수도있는 경우)에는 다소 무거운, 그리고 러닝커브가 많은 솔류션으로 이해했다. 내가 카멜을 도입한 부분은 위에 말한 장점을 살리기 위한..
[개발생각] REDIS vs RDB 안전성에 대해서..
참, 막연한 두려움인것일까?, 고정관념인 것일까? REDIS는 뭔가 불안전하고, RDB는 안전하다고 느끼는 것.. 서비스를 만들때, RDB 대신, 성능을 위해서 REDIS에 값을 넣고 조회하는 방법을 많이 사용한다.그런데, 이때 꼭 불안한 마음이 들긴한다.. REDIS 죽으면 어떻하지??RDB에도 저장을 해둬야하나? write-back이라고 하는데,캐시에 먼저 저장해두고, 적절하게 후에 rdb등에 백업해서 저장해두는 방법도 많이 쓴다. 엄밀히 말하면, RDB가 REDIS보다 더 안전한것인가?라는 의문이 들긴한다.RDB도 복제타이밍이나, 커밋/설정등에 따라 유실이 될수가 있다.완벽하게 완전무결한 솔류션은 아니다.다만 복제디비를 유지할수있어서, 문제가 있을때,바로 슬레이브 디비가 구동될수있다 정도랄까?!..
[개발생각] 온라인 사용자에게만 통계가 필요한 경우
가입유저가 많은 서비스에서 홈화면에 접속한 유저에 대한 어떤 데이터를 보여줘야하는 경우에 어떻게 시스템을 설계할수 있을까? 가장 쉬운방법은,배치프로세스를 만들고, 해당 배치에서 가입유저대상으로 데이터를 일정주기로 수집하여, 미리 데이터를 데이터베이스에 만들어둔다.그리고, 사용하는 시점에는 데이터베이스의 단순 조회를 통해 서비스되도록 설계하는 방법이다. 하지만, 만약 수집데이터를 수집하기위해 외부API를 호출해야하고, 해당 외부API의 호출량이 정해져있는 (유료,TPS) API라면,이야기가 좀 달라진다.(*자체 데이터를 통해 통계데이터를 만드는경우라면, 이야기는 좀틀리다, 빅데이터 플랫폼(스파크,하둡등)을 통해 얼마든지 다른 해결책이 있다) 홈화면에 접속한 유저에게만 보여줘야하는 데이터를 위해,가입..
[개발생각] 캐시 스탬피드
캐시 스탬피드를 실무에서 겪었던때는 다음 티스토리팀에 다닐때, 처음으로 겪어봤다. 그때는 이게 왜이러지 하고 그냥 넘겼었는데...지금 생각하니 참 무지했다. ㅠ 캐시를 사용할때, 캐시가 있으면, 캐시된값을 전달하고, 캐시가 없으면, 디비등에서 조회하여 캐시를 만들고, 해당값을 전달하는 방식으로 코딩을 자주 한다. 여기서 중요한점은, 동시성이 중요한 시스템에서는 (대량 트래픽 서비스), 캐시가 없는 시점에 디비를 조회하는 행위를 여러 요청이 동시에 할수가 있다는 점이다. 캐시가 없는 시점에 캐시를 만드는 경우, 락을 걸지않는 이상, 캐시를 만드는 행위를 동시에 여러 요청들이 수행하게 된다. 여기서 중복 조회 이슈가 발생하게 된다. 엄밀히 보면, 하나의 요청만 디비를 조회하고, 캐시를 만들면 되는 건데,..
[개발생각] 내가 생각하는 개발자란?
초등학교 2학년 겨울쯤에 컴퓨터 프로그래머가 되기로 마음먹었고, 그 마음이 현재까지 한번도 변하지 않았었다.. 내가 가장 잘할수있다고 생각되는 부분이 컴퓨터 프로그래머, 개발자라고 생각했고, 그 생각은 아직도 변하지 않았다.현재도 딱히 다른걸 잘할수있다고도 생각이 들지 않는다.(사진,기타,게임 뭐 깔짝깔짝하긴했는데... 흥미나 실력이 잘 늘지를 않더라 ㅋㅋ) 하지만, 개발에 대해서의 마음가짐은 누구보다도 진심이라고 생각한다. 내가 만드는 서비스에 대해서,한번도 대충 만든다거나, 이정도면 됐다라고 생각하지 않았다.계속 발전시키고, 수정하기 위해서 고민했던것은 분명하다. 예전에 면접을 본곳에서 면접자가 이런이야기를 한적이 있다."엄청 예전일인데, 그당시 개발한 내용을 상당히 디테일하게 설명을 하시는군요,..
[개발생각] 게시판 JPA로 구현할때, 정해야 할것들
예전에 신입 개발자 뽑을때, 게시판 만들기 코딩 과제 많았다고 하던데, 왜인지 알겠다 ㅋㅋ.. 간만에 게시판을 만들어봤는데, 정말 어렵다. 구현이? 아니.. 대량의 호출에도 느려지거나 허무하게 죽지않을 정도로 성능이 나도록 만드는게 정말 어렵다. 어렵다기 보다, 고민 포인트가 정말 많았다. 우선 고민 포인트 몇가지가 있었다. 1) JPA의 관계설정을 사용해야할까? 게시판은 게시판, 포스트, 포스트의 댓글, 그리고 댓글의 댓글등, OneToMany, ManyToOne 의 관계설정이 많이 들어간다. 관계설정을 통해, cascade설정을 하여, 데이터의 저장/삭제등의 동기화를 일관적으로 맞추고, 관계설정에 따라, 알아서 댓글 또는 대댓글등을 불러올수있기에, 상단한 매력으로 다가온다.. 하지만, 편한만큼, 조..
[개발생각] StructuredTaskScope에 대해서
와.. 항상 코틀린이 문법적으로 더 깔끔하다고 생각했는데.. StructuredTaskScope 보고, 그렇지만은 안다는걸 느꼈다.. 코틀린을 하면서, 어렵고 난해하다고 생각하는 부분/기능이 코루틴이였다. 그 개념을 이해하는데, 정말 시간이 걸렸다. 이해한거같은데, 모르겠고, 모르겠는데, 이해되는 부분도있고 하는 애매한 상태가 오래됬는데, 관련 코틀린책을 3번 정도 읽으니, 이해를 마침내 되었다. 그래도 코루틴에서 난해한 부분이 "구조화된 동시성"에 대한 기능에 대한 이해였다.이해는 되지만, 사용법이 깔끔하지 않다고 할까? 특히 코드 블럭이 중첩되는 경우에 "구조화된 동시성"에 따른 동작 흐름을 판단하는건 많이 복잡했다. DB 트랜잭션 전파(Propagation)와도 비슷한 맥락이랄까? ㅋ 암튼, 코..
