스토리 홈

인터뷰

피드

뉴스

조회수 691

[Buzzvil People] Alan Kim, Senior Software Engineer

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요. 김진언입니다. 영어 이름은 Alan Kim 이고, 현재 버즈빌에서 클라이언트 팀의 리더를 맡고 있습니다. 저는 2002년에 병역 특례로 IT업계에서 근무를 시작했고, 첫 직장에서는 연구소 장비들에 들어가는 소프트웨어 개발을 하다가 그 뒤로 모바일 게임 포팅, 게임 서버 개발 등 지금까지 14년 동안 여러 회사에서 여러가지 업무를 해 왔습니다. 소프트웨어를 만드는 능력이 뛰어난 분들은 워낙 많기 때문에  A급 개발자라고 소개할 수는 없겠지만(^^) 컴파일러 관련 시스템 개발이나 게임, 네비게이션 시스템 등 꼭 APP개발에 국한되지 않은 다양한 경험을 해 왔기 때문에 그런 장점을 살릴 수 있는 부분에서는 나름대로 역할을 하고 있다고 생각합니다.  저는 예전부터 개발자로서 여러가지 경험을 하는 것을 중시해 왔는데요. 그러다보니 임베디드 시스템부터 게임, 게임 서버, PC 툴이나 스마트폰 관련 개발까지 다양한 분야의 경험을 쌓아올 수 있었습니다. 그런데 요즘에는 다양한 경험을 하는 것보다 어떤 개발을 하든지 간에 지켜나가야 하는 기준을 세우는 것이 중요하다는 생각을 많이 하고 있습니다. 그러다 보니 코드 자체 보다는 코드를 작성하는 방식에 대한 고민들을 많이 하게 되는 데요. 최근에는 ‘클린 코드’에 대해 많이 관심을 가지고 있습니다. 요즘에는 과거에 비해 Computing resource나 컴파일러 최적화 등이 눈에 띄게 발전해왔습니다. 따라서 무조건 효율좋은 코드를 짜기보다는 조금 효율은 부족하더라도 Readability가 잘 갖추어진 코드를 짜는게 중요하다는 생각을 하게 되었고 클린코드를 위해 고민해야 하는 모듈화 방법이나 디자인 패턴에 대해서 여러가지로 고민 중입니다. 실제로 저희 팀을 운영할때도 굉장히 강조하고 있는 부분이기도 합니다. 개발 이외의 성격적인 부분으로는 평소에 말수가 적어서 종종 과묵한 사람이라 오해받고는 하는데요. 표현력이 서툴러 말수가 적을 뿐, 다른 분들을 싫어하는 게 아니니 오해하지 않으셨으면 좋겠습니다. ^^  2. 어떻게 버즈빌에 오시게 되셨나요? 버즈빌과의 인연을 설명하려면 먼저 Jay와 슬라이드 조이라는 미국 회사를 말씀 드려야 하는데요. Jay는 인포뱅크라는 회사에서 처음 인연이 시작된 동료인데, Jay가 스타트업을 창업한 후 1년쯤 지난 시점에 저에게 연락이 와서, 같이 일해보자는 제안을 했고 그렇게 슬라이드 조이에 조인했습니다.  그 당시에 저는 인프라웨어라는 회사에서 게임 서버를 개발하고 있었는데요. Jay가 권유했던 그 시기가 마침  진행했던 프로젝트가 완료된 시점이었고, 개발자로서 이런 저런 고민을 하던 시기였습니다. 내가 개발하고 싶은 것, 배워보고 싶은 것, 도전해보고 싶은 것과 같은 부분을 현 회사에서 충족할 수 있느냐에 대한 갈등이 심했던 때 였죠. 원래 저는 직장을 선택함에 있어서 제가 정말 하고 싶은 일인지와 리스크가 크더라도 그 결과를 구성원이 함께 공유할 수 있는 구조를 가지고 있는지를 많이 고민했었는데요. 결혼을 하게 되면서 자연스레 조금 더 안정적인 직장을 찾고 싶어서 들어가게 된 곳이 인프라웨어라는 회사였습니다. 하지만 그곳에서 1년간 문제 없이 일하다보니 안정적인 점은 좋았지만 제 의견이 반영되기 힘들다는 점과 개발과정에서 소통이 중시되지 않는다는 점이 저와는 맞지 않는 부분이라고 생각하고 있었습니다. 그렇기 때문에 좋은 타이밍에 연락이 왔다 생각하여 큰 고민 없이 자연스럽게 합류하게 된 것 같습니다. 물론 미래가 불확실 할 수 있는 스타트업으로 가는 것에 대해서 가족들도 염려했지만 당시 슬라이드 조이를 이루고 있던 멤버들이 정말 훌륭하고 의견들도 잘 맞았기 때문에 슬라이드 조이로의 합류를 결정하게 되었던 것 같습니다. 그 후, 여러가지 우여곡절이 있었지만, 슬라이드 조이도 상당한 성장을 이루었고 마침 좋은 기회로 버즈빌과 합병이 되면서 지금은 버즈빌에서 클라이언트 개발팀의 리더로 근무하게 되었습니다. 3. 버즈빌에서 어떤 업무를 담당하고 계신가요? 현재 클라이언트 팀의 리더를 맡고 있지만, 슬라이드조이에서는 백엔드를 전담했었고 버즈빌에서 근무를 시작할 시점에는 광고 서버쪽을 다뤘기 때문에 아직도 약간의 서버쪽 업무를 병행해 가면서 일하고 있습니다. 차츰 앱 서버를 포함한 백엔드쪽 업무를 줄이고, 클라이언트 팀 리더로서의 업무에 주력하기 위해 일부 업무를 서버 팀 개발자에게 옮기고 있습니다. 버즈빌 클라이언트 팀의 업무가 일반적인 클라이언트 개발과 다른 점이 있다면 단순히 하나의 앱을 개발하는 것이 아니라 stable 한 SDK를 개발해야 한다는 점입니다. 여러 버즈스크린 파트너들의 다양한 개발환경에서 동작되어야 하고, 어떤 상황에서든 항상 동작되어야 하기 때문에 시스템 전반에 걸친 깊은 이해가  이 필요한 일입니다. 때문에 단순히 소프트웨어 개발자 보다는 깊이 연구하고 세밀하게 설계하는 능력을 가진 사람이 필요하고 현재 클라이언트 팀의 경우 그런 사람들로 구성이 되어있다고 생각합니다.   클라이언트 팀의 리더가 되면서 아무래도 개발 자체보다는 팀원들이 개발을 잘 할 수 있도록 하는 환경들에대해 더 많은 고민을 하고 관련 업무들을 하고 있습니다. CI(Continuous Integration)나 개발 프로세스 등 흔히 말하는 DevOps에 관련된 일들을 하고 있습니다. 뿐만 아니라 구현 방식에 대한 최종적인 방향을 결정하는 의사결정이나 개발 과제가 내려오는 과정과 개발이 완료된 과제들에 대해 외부의 팀과 커뮤니케이션이 필요한 사항들을 맡아서 관리하고 있습니다. 4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 스타트업은 한 사람, 한 사람의 목소리가 회사의 성장에 직접적으로 영향을 줄 수 있다는 점이 큰 매력이라고 생각합니다. 저의 경우에는 게임 서버 개발(수천명 규모), 자동차 관련 TF팀(수백명 규모), 스타트업 두 곳, 또 다른 게임회사(60명 규모) 등 많은 케이스의 회사에서 근무를 해 왔기 때문에 큰 차이를 직접적으로 느낄 수 있었는데요. 저에게 스타트업이란 “회사의 성장에 직접적으로 기여할 수 있는 곳” 입니다. 대부분의 회사는 규모가 커짐에 따라 어쩔 수 없이 여러가지 체계가 도입되고, 문화적으로도 경직화 되는것 같아요. 사원 개인이 회사의 의사 결정에 참여 하기는 정말 어렵고, 위로부터 내려온 결정 사항에 자신의 동의 여부와 관계 없이 일이 하는 경우가 대부분입니다. 개인의 개성은 최소화하고 회사라는 체계의 한 부품으로만 움직이게 되고요. 동기부여 없이 그에 따른 무의미한 업무가 반복되면 회사 생활이 정말 재미 없게 되는 거 같습니다. 예를 들어, 특정 Feature를 개발 함에 있어서도 왜 이 Feature에 대한 개발이 필요한지, 어떤 맥락에서 이 Feature의 구현이 중요한지에 대한 커뮤니케이션 없이 그저 과제만 주어지는 경우는 해당 업무에 대한 흥미를 떨어뜨린다고 생각합니다. 하지만 스타트업의 특성상 다른 팀과의 의사소통이 활발하게 진행될 수 있는 환경이다 보니 같은 일을 하더라도 좀 더 큰 맥락에서 파악하고 내가 하는 일에 대한 의미와 기대효과를 고민해보면서 일 할 수 있다는 것이 장점이라는 생각이 드네요. 5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요?  아마 많은 분들도 공감하시겠지만, 회사 일이란 게 혼자 하는 게 아니니만큼 같이 일하는 직원이 어떤 사람이냐에 따라서 자신의 업무에도 영향을 받게 되죠. 일에 대한 열정도 없고, 월급 생각하며 대충 일하는 직원과 같이 일하게 되면 다른 팀원들도 영향을 받게 됩니다. 안 좋은 케이스의 일을 몇 번 겪고 나니 일 할 때는 같이 일하는 사람이 어떤 사람인지에 대해 촉각을 많이 세우게 되었죠. 그런데 제가 지금 버즈빌에 근무한 지 1년 반이 넘은 것 같은데, 처음 입사할 때나 지금이나 여전히 느끼는 점은 버즈빌에는 ‘능력자들’이 정말 많다는 점입니다. 보통 회사에서는 10명 중 1명 있을까 말까 할 정도로 특출난 인재들이 한 곳에 모여있다는 그 부분이 정말 인상적이었어요. 스펙도 스펙이지만 보통 사회 초년생이라 일컫는 어린 나이 임에도 일에 대한 진지한 태도와 전문성, 빠른 일 처리 속도 등 대부분의 직원들이 ‘능력자’라 부르기에 손색이 없을 정도입니다. 그런 직원들과 매일 생활하니 저 또한 분발해야겠다는 생각과 함께 많은 의욕을 얻고 있어요.   또한 개발자로서 느끼는 버즈빌은 제가 일했었던 다른 회사들과 극명하게 차이가 있는 곳이라는 생각이 듭니다. 회사가 평등한 문화를 가지고 있다고 PR을 하는 경우가 많은데 버즈빌 만큼 실제로도 수평적인 문화를 가진 회사는 처음입니다. 개발에 관련된 여러가지 의사결정을 함에 있어서도 서로의 의견을 존중하고 워낙 뛰어난 사람들이 많다보니 서로에게 많은 것들을 배울 수 있는게 좋습니다. 저도 팀장이지만 팀원들에게 여러가지를 물어볼 때도 많고 팀원들 통해 새롭게 배우는 것들도 많구요. 이렇게 뛰어난 사람들도 많이 있고 이런 사람들 간에 서로에게 시너지를 줄 수 있는 좋은 문화를 가지고 있다는 점은 분명 다른 회사에서 찾아보기 힘든 장점이라고 생각합니다. 저는 합병을 통해 입사했기 때문에, 버즈빌이라는 회사에 기대를 많이 하고 합류하게 되었는데요. 그 점에 있어서는 200% 이상 충족되었다고 생각합니다. 구성원 한 사람 한 사람을 믿고 자신의 업무에 집중할 수 있다는 것은 저에게 있어 매우 중요한 의미이기 때문에, 현재 회사 생활이 무척 만족스럽네요. 6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 먼 미래에 대한 목표는 ‘돈 걱정 없는 편안한 노후’고요.(^^)  사실 이런 목표를 늘 생각하면서 살고 있진 않습니다. 미래보다는 현재가 중요하고 단기적인 목표에 최선을 다하는 것에 보람을 느끼는 편입니다. 당장 생각나는 목표는…혼자만의 여행일까요? 예전부터 같은 일상에 지치거나 슬럼프가 올때면 한번씩 여행을 가서 충분히 쉬고 생각도 정리하는 시간을 가졌었는데요. 버즈빌에는 다양한 국적의 직원들이 많다보니 그들의 성장환경과 문화 이야기를 들으면 저도 당장 떠나고 싶은 기분이 들 때가 있어요.  가정이 있다보니 혼자 여행을 가는게 쉽지만은 않고 지난 3월에 회사 워크샵으로 발리를 다녀 온 이후로 더욱 눈치가 보이기는 하지만, 몽골에 배낭여행을 가는게 너무 하고 싶네요. 그리고… 생각만 하고 실천을 잘 못하고 있는 부분이 있는데, ‘영어권 나라로의 이민’을 위해 기반을 마련하는 것 입니다. 영어권 나라들의 경우 대부분이 한국에 비해서 삶의 방식이 자유롭고 틀에 박힌 부분이 적다는 생각이 들더라구요. 제가 느끼기엔 아직까지 우리나라가 여유가 없고 바쁜 느낌이 강하게 들어서 좀더 여유로운 환경에서 생활해 보고 싶다는 꿈이 있습니다. 무엇보다 영어가 중요할텐데, 버즈빌에서는 많은 의사 소통을 영어로 하고 있다보니 생각해 보면 엄청 좋은 기회이지만, 아직까지 영어 사용을 적극적으로 하지 않고 있어서 다시 한번 마음을 다 잡고 시작해 봐야겠습니다.
조회수 2346

JANDI 검색엔진 도입기

이번 포스트에서는 JANDI가 검색엔진을 도입하게 된 배경과 어떤 작업을 했는지 공유하려고 합니다검색엔진 도입 배경JANDI는 사용자가 입력한 메시지를 검색하고 사용자가 올린 파일의 파일명/파일 타입을 검색하는 메시지/파일 검색 기능을 제공하고 있습니다. 데이터 저장소로 MongoDB를 사용하고 있는데 검색되는 필드에 인덱스를 걸고 정규 표현식을 이용하여 DB Like 검색(“DB는 검색을 좋아한다”아니에요;;)을 하고 있습니다.초기에는 데이터가 아담했는데, 서비스가 커감에 따라 사용자 증가하면서 생성되는 데이터도 많아졌습니다. 올 초에 데이터가 많아지면서 검색이 DB에 부하를 주고, JANDI 서비스에도 영향을 주게 되었습니다. 그래서 JANDI 서비스용 MongoDB와 검색 전용 MongoDB를 분리했는데 이는 임시방편이었고 언젠가는 꼭 검색엔진을 도입하자며 마무리를 지었습니다.시간은 흘러 흘러 4월이 되었습니다. 당시 메시지 증가량을 봤을 때 올해 안에 검색엔진을 사용하지 않으면 서비스에 문제가 될 거라고 판단이 되어 도입을 진행하게 되었습니다.검색엔진 도입의 목표는 다음과 같았습니다.현재 DB Like 검색과 비슷한 검색 품질이어도 좋다. (일정때문에)검색엔진 도입을 통해 검색이 JANDI 서비스에 영향을 주지 않도록 한다.색인을 위해서 주기적으로 JANDI의 MongoDB 데이터를 가져 와야 했지만, 이 작업이 JANDI 서비스에 큰 부하를 주지 않을 거라고 생각했습니다.검색엔진 후보로는 Solr, ElasticSearch, CloudSearch, ElasticSearch Service 가 있었는데 Solr를 선택했습니다.왜냐하면제가 경험한 검색엔진이 Solr 였습니다. 더군다나 2010년 초에 접했던 Solr 비해 많이 발전한 것 같아 개발자로서의 열정과 도전 욕구가 샘솟았습니다. SolrCloud pdf, WhyNoWarAWS에서 제공하는 검색 서비스는 많은 부분을 관리해준다는 면에서 솔깃했지만, Custom Analyzer는 적용할 수 없어서 선택하지 않았습니다.ElasticSearch에 크게 흔들렸지만 경험이없다 보니 공부하면서 프로젝트를 진행한다는 부담감이 커서 다음을 기약했습니다.작업 내용1. MongoImporter, Sharding. MongoImporter 수정현재 JANDI는 MongoDB를 데이터 저장소로 사용하고 있습니다. MongoDB의 데이터를 색인하기 위해 데이터를 검색엔진으로 가져와야 하는데 Solr에서는 DataImportHandler 기능을 제공하고 있습니다. 기본 DataImportHandler로 RDB 데이터는 가져올 수 있지만 이 외 MongoDB나 Cassandra 같은 NoSQL의 데이터를 가져오기 위해서는 따로 구현이 필요합니다. 구글신에게 물어봐서 SolrMongoImporter 프로젝트를 찾았는데 문제가 있었습니다. mongo-java-driver 버전이 낮아서(2.11.1) 현재 JANDI에서 서비스 되고 있는 MongoDB(3.0.x)의 데이터를 가져올 수 없었습니다.url: Reference compatibility MongoDB Java2.11.1에서 3.2.2로 버전을 올리고 변경된 api를 적용하는 작업, 빌드 툴을 ant에서 maven으로 변경하는 작업을 하였습니다. 마음의 여유가 된다면 P/R을 할 계획입니다.여담으로 DataImportHandler 작업과 함께 검색 schema 정하는 작업을 했는데 sub-document 형식이 필요하게 되었습니다. Solr 5.3부터 nested object를 지원한다는 article을 보았는데, nested object 지원 얘기를 보니 Solr도 text search 뿐 아니라 log analysis 기능에 관심을 가지는건 아닐까 조심스레 생각해봤습니다. (역시나… 이미 banana, silk 같은 프로젝트가 있습니다. Large Scale Log Analytics with Solr 에 관련된 이야기를 합니다.). Sharding. 그리고 Document Routing대량의 데이터를 처리하기 위해 한 개 이상의 node로 구성된 데이터 베이스에 문서를 나누어 저장하는 것을 sharding이라고 합니다. SolrCloud는 shard 생성/삭제/분리할 수 있는 API가 있고, 문서를 어떻게 나눌지 정할 수 있습니다. 어떻게 나눌지는 shard 생성 시 router.name queryString에 개발한 router 이름을 적어주면 됩니다. 그렇지않으면 Solr에서 murmur Hash 기반으로 문서를 나누는 compositeId router를 사용합니다. JANDI의 검색 기능은 Team 단위로 이루어지기 때문에 TeamId를 기준으로 문서를 나누기로 하고, compositeId Router를 사용했습니다. 실제 서비스의 문서 데이터를 색인 돌려서 각 node에 저장되는 문서 개수나 메모리/디스크 사용량을 확인했는데 다행히도 큰 차이가 나지 않았습니다.하나의 문서는 TeamId와 MessageId를 조합한 “TeamId + ! + MessageId” 값을 특정 field에 저장하고 해당 필드를 uniqueKey 지정했습니다. 간단한 수정으로 문서 분배가 되는점이 좋았고, 더 좋았던건 검색시 _route_ 를 이용해서 실제 문서가 존재하는 node에서만 검색을 한다는 점이 었습니다. 4년 전 제가 마지막으로 Solr를 사용했을 때는 사용자가 직접 shards queryString에 검색할 node를 넣어주어야 했습니다..../select?q=\*:\*&shards=localhost:8983/solr/core1,localhost:8984/solr/core1SolrCloud RoutingSolrCloud Routing2Multilevel CompositeId2. analyzer, queryParser. analyzerSolr에 기본으로 있는 text_cjk analyzer를 사용하였습니다. <!-- normalize width before bigram, as e.g. half-width dakuten combine --> <!-- for any non-CJK --> text_cjk는 영어/숫자는 공백/특수기호 단위로 분리해주고 cjk는 bigram으로 분리해주는 analyzer 입니다. analyzer는 이슈 없이 완성될 거라 생각했지만 오산이었습니다. 텍스트가 들어오면 token을 만들어주는 StandardTokenizerFactory 에서 cjk와 영어/숫자가 붙어있을 때는 분리하지 못해 원하는 결과가 나오지 않았습니다. 또한 특수기호중에 ‘.’(dot), ‘_‘(underscore)가 있을 때에도 분리하지 못했습니다.nametextInputTopic검색개선_AB1021_AB제시CD.pdfStandardTokenizerFactoryTopic검색개선_AB1021_AB제시CD.pdfCJKWidthFilterFactoryTopic검색개선_AB1021_AB제시CD.pdfLowerCaseFilterFactorytopic검색개선_ab1021_ab제시cd.pdfCJKBigramFilterFactorytopic검색개선_ab1021_ab제시cd.pdf원하는 결과topic 검색개선 ab 1021 ab 제시 cd pdf그래서 색인/검색 전에 붙어있는 cjk와 영어/숫자사이에 공백을 넣어주고 ‘.’와 ‘_‘를 공백으로 치환해주는 작업을 하였습니다. 색인은 Transform에서 처리하고 검색은 다음에 알아볼 QParserPlugin에서 처리했습니다.nametextInputTopic검색개선_AB1021_AB제시CD.pdfTransform 단계Topic 검색개선 AB 1021 AB 제시 CD pdfStandardTokenizerFactoryTopic 검색개선 AB 1021 AB 제시 CD pdfCJKWidthFilterFactoryTopic 검색개선 AB 1021 AB 제시 CD pdfLowerCaseFilterFactorytopic 검색개선 ab 1021 ab 제시 cd pdfCJKBigramFilterFactorytopic 검색개선 ab 1021 ab 제시 cd pdf※ 추가 : 검색 결과를 보여줄때 어떤 키워드가 매칭되었는지 Highlight 해야했는데, 색인하기 전에 원본을 수정을 해서 Solr에서 제공하는 Highlight를 사용하지 못하게 됐습니다. 눈 앞의 문제만 바라보고 해결하기 급급했던 저를 다시금 반성하게 되었습니다.. queryParser앞에서도 언급하였지만, 색인뿐만 아니라 검색할 때도 검색어가 입력되면 검색하기 전에 붙어있는 cjk와 영어/숫자를 분리하고 ‘.’, ‘_‘를 공백으로 치환해주는 작업이 필요합니다. Solr에서 기본으로 사용하는 LuceneQueryParserPlugin 을 수정하였습니다.@Override public Query parse() throws SyntaxError { // 수정한 코드 String qstr = splitType(getString()); if (qstr == null || qstr.length() == 0) return null; String defaultField = getParam(CommonParams.DF); if (defaultField == null) { defaultField = getReq().getSchema().getDefaultSearchFieldName(); } lparser = new SolrQueryParser(this, defaultField); lparser.setDefaultOperator (QueryParsing.getQueryParserDefaultOperator(getReq().getSchema(), getParam(QueryParsing.OP))); return lparser.parse(qstr); } QParserPlugin3. DataImportHandler manageMongoImporter에서도 얘기했지만 Solr에서는 DB 데이터를 가져오는 DataImportHandler 기능을 제공 하고 있습니다. DataImportHandler Commands를 보면 총 5개의 명령을 제공하고 있는데, 그중 색인을 실행하는 명령은 full-import와 delta-import입니다. full-import 명령은 DB의 모든 데이터를 색인 하는 것을 말합니다. 색인 시작할 때의 시간을 conf/dataimport.properties에 저장하고 이때 저장한 시간은 delta-import 할때 사용됩니다. 전체 색인한다고 말합니다. delta-import 명령은 특정 시간 이후로 생성/삭제된 데이터를 색인 하는 것을 말합니다. 특정 시간이란 full-import 시작한 시간, delta-import가 최근 종료한 시간을 말합니다. full-import와는 다르게 delta-import가 종료된 시간을 conf/dataimport.properties에 저장합니다. 증분 색인 혹은 동적 색인이라고 하는데 여기서는 증분 색인이라고 얘기하겠습니다. 두 명령을 이용하여 JANDI의 메시지/파일을 색인 하기 위한 삽질 경험을 적었습니다.. 첫 번째 삽질full-import는 현재 active인 데이터를 가져올 수 있도록 query attribute에 mongo query를 작성하고, delta-import 는 특정 시간 이후에 생성된 데이터를 가져올 수 있도록 deltaQuery attribute에 mongo query를 작성합니다. 또한 deltaQuery로 가져온 id의 문서를 가져올 수 있도록 deltaImportQuery attribute에 mongo query를 작성하고, 특정 시간 이후에 삭제된 데이터를 가져올 수 있도록 deletedPkQuery 에도 mongo query를 작성합니다.<!-- data-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> 정상적으로 동작은 했지만, 색인 속도가 실제 서비스에 적용하기 힘들 정도였습니다. 실행되는 mongo query를 확인했는데 다음과 같이 동작하였습니다.특정 시간 이후에 생성된 데이터를 색인하기 위해 약 (새로 생성된 문서개수 + 1) 번의 mongo query가 실행되었습니다. (batch size와 문서 갯수에 따라 늘어날 수도 있습니다.) 메신저 서비스 특성상 각각의 문서 크기는 작지만 증가량이 빠르므로 위 방식으로는 운영 할 수 없었습니다. 그래서 delta-import using full-import 를 참고해서 두 번째 삽질을 시작 하였습니다.. 두 번째 삽질full-imoprt 명령을 실행할 때 clean=false queryString을 추가하고 data-config.xml query attribute를 수정하는 방법으로 증분 색인 하도록 수정했습니다. 특정 시간 이후 생성된 문서를 가져오는 attribute인 deltaQuery와 deltaImportQuery 는 필요가 없어 지웠습니다.<!-- data-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> <!-- if query="" then it imports everything --> 전체 색인은 /dataimport?command=full-import&clean=true 로 실행하고, 증분 색인은 /dataimport?command=full-import&clean=false(생성된 문서)와 …/dataimport?command=delta-import&commit=true(삭제된 문서)로 실행하도록 했습니다.정상적인 것 같았지만, 문제가 있었습니다.full-import, delta-import 명령을 실행하면 conf/dataimport.properties 파일에 전체 색인이 실행한 시작 시각 혹은 증분 색인이 최근 종료한 시간이 “last_index_time” key로 저장됩니다. 첫 번째 삽질에서 증분 색인시 delta-import 명령 한 번으로 생성된 문서와 삭제된 문서를 처리했지만, full-import와 delta-import 두개의 명령으로 증분 색인이 동작하면서 생성된 문서를 처리할 때도 last_index_time이 갱신되고 삭제된 문서를 처리할 때도 last_index_time이 갱신되었습니다.예를 들면증분색인 동작이 1분마다 삭제된 문서를 처리하고, 5분마다 생성된 문서를 처리 한다고 가정해보겠습니다. 3시 13분 14초에 delta-import가 완료되어 last_index_time에 저장되고, 다음 delta-import가 실행되기 전 3시 13분 50초에 full-import가 완료되어 last_index_time이 갱신되었다면, 3시 13분 14초부터 3시 13분 50초 사이에 삭제된 문서는 처리를 못 하는 경우가 발생합니다.Solr에서 dataimport.properties에 기록하는 부분을 수정하는 방법과 전체/증분 색인을 동작시키는 Solr 외부에서 특정 색인 시간을 관리하는 방법이 있었는데 Solr를 수정하는 건 생각보다 큰 작업이라 판단되어 외부에서 관리하는 방법으로 세 번째 삽질을 시작하였습니다.. 세 번째 삽질전체/증분 색인을 주기적으로 동작 시키는 곳에서 full-import&clean=false(생성된 문서) 처리할 때 필요한 마지막으로 색인 된 문서 id와 delta-import(삭제된 문서) 처리할 때 필요한 마지막으로 색인 된 시간을 관리하도록 개발하였습니다. 증분 색인 시 full-import&clean=false를 실행하기 전에 현재 색인 된 마지막 id 조회 후 해당 id보다 큰 데이터를 처리하도록 하였고, delta-import를 마지막으로 마친 시간을 따로 저장하다가 delta-import 실행 시 해당 시간을 전달하는 방법으로 수정하였습니다.<!-- data-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> 마치며튜닝의 끝은 순정이라는 말이 있는데 IT 기술은 예외인 것 같습니다. 현재는 Solr의 기본 기능만으로 구성했지만, 고객에게 더 나은 서비스를 제공할 수 있는 시작점으로 생각하고, JANDI 서비스에 맞게 끊임없이 발전해나가겠습니다.감사합니다.참고Getting Started with SolrApache Solr 5.5.0 Reference Guide PDFApache Solr 6.1 - Analyzers, Tokenizers and FiltersRebalance API for SolrCloud issueYonik Blog#토스랩 #잔디 #JANDI #개발자 #개발팀 #개발후기 #인사이트
조회수 867

주니어 개발자가 외칩니다, "Hello, System Architecture!"

Overview주니어 개발자는 시스템 아키텍처(System Architecture) 또는 시스템 디자인(System Design)이라는 단어에 덜컥 겁부터 먹습니다. 지금 진행하고 있는 개발에만 집중하다 보니 큰 그림을 놓치고 있는 게 아닐까 란 생각이 들었죠. 조금 더 큰 그림을 보고자 공부를 시작했습니다. 문득 같은 생각을 하는 주니어 개발자 분들도 많을 것 같다고 생각했어요. 그래서 이번 글은 시스템 아키텍처에 ㅇ_ㅇ? 뀨? 하는 표정을 짓는 주니어 개발자들을 위해 썼습니다.상상의 나래: 가상의 패션 e커머스상상의 나래를 펼쳐봅시다. 패션 e커머스 서비스를 이용하는 김유저 씨가 구매한 옷이 마음에 들어 상품 리뷰를 남기고 싶어한다고요.김유저 씨는 본인의 착용 사진과 텍스트 리뷰를 작성하고 ‘리뷰 등록하기’ 버튼에 엔터를 탁! 누를 겁니다. 그런데 말이죠. 김유저 씨는 요청하고 싶은 웹서버의 IP 주소를 모르기 때문에 요청을 보낼 수가 없습니다.내 정체를 알려줘: DNS (Domain Name System)그래서, DNS(Domain Name System)에게 물어봅니다. 서버의 도메인 이름으로부터 해당 서버의 IP 주소를 알려주는 것이 바로 DNS입니다. 도메인 이름에 대한 질의를 하고, 만일 해당 도메인 이름이 DNS에 ‘A Record’ 형태로 등록이 되어 있다면 도메인 이름에 해당하는 IP 주소를 응답으로 돌려줍니다.서비스에서 자체 DNS 시스템을 가지고 있을 수 있습니다. 예를 들어 Route 53, Cloud Flare같은 서비스가 있습니다. 그렇다면 또 한 가지 의문이 생깁니다. 왜 서비스는 시스템적 부담을 안고서 자체 DNS 서버를 구축하고 있는 걸까요? 그 이유로 두 가지를 꼽을 수 있습니다.첫 번째로는 신뢰도가 높습니다. 직접 DNS Record를 관리 및 운영하기 때문입니다. 두 번째로는 보안이 우수합니다. 만약 공개하고 싶지 않은 IP 주소, 예를 들어 Database IP 주소 같은 건 공개하지 않습니다. 1)작업장소: Web Server이제 웹서버의 IP 주소를 알았으니 통신을 시도합니다. 웹서버는 웹서비스에서 필요로 하는 다양한 요청과 그에 대한 응답을 제공합니다. 클라이언트가 리뷰에 대한 사진과 텍스트를 등록하고 싶다면 웹서버에게 등록하라는 요청을 보내야 합니다.웹서버에서 요청을 받으면 사용자가 요구한 대로 사진과 텍스트를 등록하고, 그에 대한 결과 정보를 응답으로 보내줄 것입니다. 웹서버 내부에서는 그 과정에 필요한 연산을 수행합니다. 서버 개발자는 이 연산에 대한 코드를 작성하고요.센스가 없는 서버:API (Application Programing Interface)서버는 사람이 아닙니다. 센스나 재치가 없죠. 미리 정의되지 않은 요청은 대응하지 못합니다. (어버버버버 퉤! Error 404!) 그래서 약속한 요청을 보내면 약속한 방식으로 응답해줄게라고 명세를 제공합니다.약속한 요청으로 데이터를 보내면 원하는 요청에서 데이터를 정제해 잘 처리했는지, 또는 처리된 데이터를 약속한 방식(예를 들어, JSON 방식)으로 내보내죠. 웹서버는 정의된 API에 맞춰 요청과 응답을 합니다.그런데 웹서버가 수많은 요청을 받고 응답하면 과부하가 일어날 수도 있습니다. 사용자 수가 어마어마한 규모로 늘어나서 서버가 펑! 하고 터진다면, 김유저 씨는 서비스를 더 이상 이용할 수 없을 겁니다. 이용하고 싶지도 않을 겁니다!따라서, 서버가 감당하는 요청을 나누기 위해 같은 역할을 하는 서버 장비 수를 늘릴 수도 있습니다. 그러면 요청이 각기 다른 웹서버 장비에 분산되어 한 번에 감당할 수 있는 요청 수가 더욱 많아집니다.이 구역의 매니저는 나야: Load Balancer그림처럼 서버가 4대 존재하는 상황이라면, 서버 4대에 일을 적절히 분배해주는 역할이 필요합니다. 그것이 로드 밸런서(Load Balancer)입니다. 로드 밸런서가 서버에게 일을 나누는 방법론은 여러 가지가 있습니다.Random: 랜덤으로 분배하기Least loaded: 가장 적은 양의 작업을 처리하고 있는 서버에게 요청을 할당하기Round Robin: 순서를 정하여 돌아가며 작업 분배하기많이 쓰는 로드 밸런서의 종류는 Layer 4, Layer 7을 꼽을 수 있습니다.Layer 4 Load Balancer: 데이터의 내용을 보지 않고 IP주소 및 TCP/UDP 정보에 따라 단순히 분배를 해줍니다.Layer 7 Load Balancer: 서버가 하는 역할이 분리되어 있는 환경에서 데이터의 내용을 보고 각기 맞는 역할을 하는 서버에게 분배를 해줍니다.로드 밸런서는 클라이언트가 요청을 보내야 할 서버를 골라야 하는 부담을 덜어주며, 로드 밸런서에게 할당된 vIP (가상 IP)로 요청을 보내기만 하면 로드 밸런서에서 알아서 작업을 나눠줍니다. 서버에서는 적절한 로드 밸런서를 사용하면 들어오는 요청이 여러 장비에 분산되어 처리량이 늘어나고 응답 시간이 줄어드는 효과를 기대할 수 있습니다. 컨텐츠 저장소: CDN(Content Delivery Network)이제 웹서버가 클라이언트의 요청에 의해 웹페이지에 대한 응답 결과를 돌려줬습니다. 이때 클라이언트의 화면에 렌더링해야 하는 수많은 이미지가 필요합니다. 이 이미지들을 웹서버가 전부 주려면 데이터의 용량이 너무 크고, 무거워서 서버가 헥헥거리죠. (서버가 죽으면 어떻게 될까요? 클라이언트님이 경쟁사로 환승하겠죠.. 안 돼요..) 따라서 웹서버는 직접 이미지를 주는 대신 CDN(Content Delivery Network)에게 요청하라고 이야기합니다. CDN은 일반적으로 용량이 큰 컨텐츠 데이터(이미지, 비디오, 자바스크립트 라이브러리 등)를 빠른 속도로 제공하기 위해 사용자와 가까운 곳에 분산되어 있는 데이터 저장 서버입니다. 클라이언트는 용량이 큰 컨텐츠 데이터를 가까운 CDN에 요청해 멀리 있는 웹서버에서 직접 받는 것보다 빠르게 받을 수 있습니다. CDN이 동작하는 방식에는 크게 Push CDN, Pull CDN이 있습니다. Push CDN: 서버에서 컨텐츠가 업로드되거나, 변경되었을 때 모두 반영하는 방식 Pull CDN: 클라이언트가 요청할 때마다 컨텐츠가 CDN에 새로 저장되는 방식 두 방식 모두 장단점이 있습니다. Push CDN은 모든 컨텐츠를 갖고 있기에 웹서버에 요청할 일이 없지만 유지하는데 필요한 용량과 비용이 많이 필요하겠죠? Pull CDN은 클라이언트가 요청한 컨텐츠가 있으면 바로 응답하지만 그렇지 않을 땐 데이터를 웹서버로부터 가져와야 하기 때문에 서버에 요청하는 부담이 존재합니다. 컨텐츠명은 그대로인데 내용만 변경되었다면 인지하지 못하고 옛버전의 컨텐츠를 제공하죠. 그래서 Pull CDN에 들어가는 컨텐츠는 TTL(Time To Live)이 적용됩니다. TTL이란 유통기한이라고 생각하면 쉽습니다. 일정시간이 지나면 해당 데이터가 삭제되는 것이죠. 이런 방식이 적용된다면 Pull CDN의 최대 단점을 보완할 수 있습니다. 이렇게 보완이 되면 수정된 데이터에 대해서도 대응이 가능하며 서버의 용량 즉, 비용적 부담이 해소될 겁니다.소중한 내 데이터: Database서비스를 제공하다 보면 클라이언트의 소중한 정보, 이력, 상품 가격, 상품 정보 등 다양한 데이터를 저장하고, 또 제공합니다. 하지만 수많은 데이터를 웹서버에 전부 저장하고 사용하기엔 데이터의 양이 너무 많아 저장 공간도 부족하고, 데이터를 원하는 모양에 맞게 정제하기가 어렵습니다. 그래서 데이터를 저장하는 데이터베이스 서버가 따로 존재합니다.민감한 정보를 다루는 데이터베이스는 ACID라는 성질을 만족해야 하는데요.Atomicity(원자성): 데이터베이스에 적용되는 명령이 중간만 실행되지 않고 완전히 성공하거나 완전히 실패해야 한다는 것을 의미합니다. 반만 적용된 명령이 있다면 헷갈리겠죠.Consistency(일관성): 데이터베이스가 수행한 명령이 일관적으로 반영되어 있어야 한다는 의미입니다. 예를 들어 계좌에 돈을 입금했는데 잔고에 반영되지 않는다면 당황스러울 겁니다.Isolation(고립성): 데이터베이스가 수행하는 명령 도중 다른 명령이 끼어들지 못한다는 것을 의미합니다.Durability(지속성): 성공적으로 수행한 명령은 영원히 그 이후 상태로 남아있어야 한다는 걸 의미합니다. 갑자기 하루 뒤에 명령이 취소되거나 이전 상태로 롤백되면 안 됩니다. Replication (복제 / 이중화)큰 시스템에서는 똑같은 데이터베이스가 여럿 존재한다고 하는데요. 그렇다면 왜 비용적인 부담을 안으면서까지 복제 데이터베이스를 구축해놓는 걸까요? 만약에 데이터베이스가 정상적으로 동작하지 않는다면 클라이언트의 데이터를 변경하지 못하며, 클라이언트가 원하는 정보를 제공하지 못하는 불상사가 일어나게 됩니다. 글로만 써도 벌써 땀이 납니다. 그러므로 복제해놓은 데이터베이스를 얼른 마스터로 등업해 데이터 흐름에 차질이 없도록 대비해야 합니다.만약 하나의 데이터베이스가 어떤 일을 수행할 때 다른 요청들은 계속 기다려야 합니다. 그렇다면 데이터를 변경하는 데이터베이스는 하나, 읽기만 하는 데이터베이스는 여러 대가 존재해도 되지 않을까요? 바로 여기서 Master-Slave의 개념이 탄생합니다.master-slave-replicaMaster-Slave Replica (a.k.a 주인-노예)요청을 분산하기 위해서 데이터베이스를 늘리다 보면 master-slave 토픽이 등장합니다.Mater: CRUD(Create, Read, Update, Delete)가 모두 가능Slave: R(Read)만 가능Master가 데이터를 변경할 동안 읽기에 대한 요청은 Slave에게 보내집니다. 그렇게 하면 읽기 요청은 분산되어 훨씬 더 수월하고 빠른 속도로 데이터 처리가 가능할 것입니다. 만약 Master가 변경된다면 아래 계급인 Slave, Replica 데이터베이스에게도 이 정보를 전해야 합니다. 다시 말해, 자신에게 들어온 요청(Query)을 동일하게 보내 빠른 시간 안에 동기화를 시켜주죠. 하지만 동기화도 시간이 걸리는 작업이므로 무한대로 Slave Replica를 늘려 확장하기는 어렵습니다.Master-Master Replica의문이 하나 생길 겁니다. “여러 대의 Master를 두어서 변경도 가능하고, 읽기도 가능하게 하면 되지 않을까?”앞서 언급했듯이 같은 데이터의 변경 가능한 데이터베이스는 하나여야 할 것입니다. 동시에 같은 데이터를 변경했을 때 갈등을 해소하기 위한 방법론은 존재하지만, 그 방식이 복잡하고 오래 걸립니다. 안정성도 낮아지고, 효율도 떨어집니다. 그래서 Master-Slave 아키텍처를 선호하는 것이죠.Sharding그러면 같은 데이터베이스 테이블을 동시에 변경하는 건 불가능한 걸까요? 그것을 해소하기 위해 샤딩(Sharding)이라는 방법론을 사용합니다. 샤딩된 테이블은 개념적으론 하나의 테이블처럼 보이지만 사실 그 내용물이 쪼개져 있습니다. 쪼개는 방법은 여러 가지 선택할 수 있습니다만, 분명한 건 겹치는 데이터 없이 쪼갠다는 것입니다. 그래서 같은 테이블이어도 쪼개져 있다면 그 테이블에 동시에 접근해 데이터를 변경할 수 있는 것이죠.이외에 서비스별, 기능별로 쪼개어 데이터베이스를 관리하는 Federation 등 많은 데이터베이스 디자인 방법론이 존재합니다.시스템 아키텍처가 가지고 있어야 할 최소본 아키텍처요점: 시스템 아키텍쳐에서 고려해야 할 성질이렇게 간단한 시스템 아키텍처의 면면을 살펴봤습니다. 시스템 개발자라면 시스템을 디자인하면서 반드시 고려해야 할 성질들을 만날 텐데요. 위에서 소개한 내용들 역시 아래의 성질들을 충족하기 위해 탄생했다고 볼 수 있습니다.Scalability (확장성): 10만 명의 요청을 처리할 수 있는 시스템과 1000만 명의 요청을 처리할 수 있는 시스템은 다릅니다. 확장성을 고려한 시스템은 앞으로 클라이언트 수가 늘어났을 때 무리 없이 모든 요청을 처리할 수 있을 겁니다.Performance (성능): 속도와 정확성을 말합니다. 요청한 내용을 정확하고 빠르게 돌려주어야 합니다.Latency (응답 시간): 모든 요청은 클라이언트가 불편해하지 않을 정도로 빠른 시간 안에 돌려주어야 합니다.Throughput (처리량): 같은 시간 안에 더욱 많은 요청을 처리한다면 좋은 시스템입니다.Availability (접근성): 사용자가 언제든지 시스템에 요청을 보내서 응답을 받을 수 있어야 합니다. 비록 서버 장비 한두 대가 문제가 생겨 제 기능을 하지 못하더라도 사용자는 그 사실을 몰라야 합니다.Consistency (일관성): 사용자가 서버에 보낸 요청이 올바르게 반영되어야 하고, 일정한 결과를 돌려주어야 합니다. 요청을 보낼 때마다 불규칙한 결과를 돌려준다면 믿을 수 없는 서비스가 될 것입니다.결론발로 그렸나 싶을 정도의 그림과 기나긴 글을 마무리 지으며주니어 개발자로서 시스템 아키텍처를 공부하면서 느낀 점이 있다면 시스템에 대한 완벽한 대응은 없으며, 모두 장단점이 존재한다는 것입니다. (이것을 보통 trade-off라고 표현합니다.)하지만 설계하는 서비스를 잘 알고 서비스에서 무게를 둬야 할 부분을 파악한다면, 그에 맞는 시스템을 설계하고 디자인할 수 있을 겁니다. 김유저 씨도 만족시킬 수 있을 거고요. 꼬박 이틀을 밤새워서 쓴 글이 아직 시스템 아키텍처를 두려워하는 다른 주니어 개발자분들에게 도움이 되었으면 합니다. 이번에는 시스템에서 아주 기초적인 부분을 공부했으니 다음 글에선 MSA(MicroService Architecture)를 씹어봅시다! 겁이 나고 무서워도 외쳐보세요. “Hello, System Architecture!”이 세상 모든 주니어 개발자분들, 퐈잇팅입니다.참고1) 추가적인 이점에 대하여: 웹서버에서 요청을 보낼 때 database 도메인 네임으로 보낼 경우, 멀리 있는 공인 DNS 서버 (예를 들면 google public DNS server: 8.8.8.8)에 물어오는 것보다 자체 DNS 서버에 물어오는 것이 훨씬 더 빠른 속도로 응답을 받아올 수 있습니다.출처GitHub - donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.글오연주 사원 | R&D 개발2팀ohyj@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #주니어개발자
조회수 1537

IT 서비스 모니터링 제대로 잘하기

모니터링은 IT 운영의 핵심입니다. 장비의 활성화 상태에서 애플리케이션의 변화와 성능 이슈까지 언제나 실시간으로 인지와 대응이 가능해야 합니다. 서비스를 운영에 장애를 없앨 수는 없지만 좋은 모니터링 전략을 가지고 있다면 빠른 예방과 대응을 통해 고객이 불편함을 느끼지 못하게 할 수는 있습니다.  IT 운영에서의 비지니스 목표IT 서비스 모니터링 전략을 만들기 전에 우리는 우선 목표를 선정해야 합니다. 빠른 예방과 대응은 좋은 모니터링 전략의 기본 목표일 뿐입니다. 우리는 모니터링을 통해 아래와 같은 비지니스 목표를 이루어야 합니다. 브랜드 이미지 향상매출증대비지니스 개선비지니스 목표를 위한 모니터링그리고 이런 비지니스 목표를 위해서는 아래와 같은 일들을 모니터링을 통해 수행할 수 있어야 합니다. 안정적인 서비스 운영 (브랜드 이미지 향상, 매출증대)빠른 장애 대응 (브랜드 이미지 향상, 매출증대)장애 예방 (브랜드 이미지 향상, 매출증대)사용자 분석 (비지니스 개선)사용성 분석 (비니지스 개선)서비스 성능 개선 (브랜드 이미지 향상, 매출증대)현대 IT 서비스는 물리서버와 클라우드가 혼재되어 있는 인프라스트럭처 환경과 다양한 플랫폼에서 개발된 애플리케이션들이 작게 구성되어 있는 복잡한 구성을 가지고 있습니다. 뿐만아니라 서비스의 구성 또한 전 세계에 분산되어 있는 상황에서 우리는 효율적인 모니터링 전략을 만들어서 IT 서비스를 운영해야 합니다.비지니스 목표를 위한 모니터링 전략이런 체계적이고 효율적인 IT 서비스 모니터링 전략을 만들기 위해서는 아래와 같은 것들을 고려해야 합니다.1. 통합 모니터링 체계를 구축하세요.  인프라스트럭처와 애플리케이션을 모두 모니터링하여 전체 그림을 얻어야 합니다. 전체적인 그림을 모든 운영자들이 알수 있어야 체계적인 IT 서비스 운영이 가능합니다.2. 기준을 넘어서는 성능 변화가 생기면 알수 있도록 경고를 설정해야 합니다. CPU 부하율, 메모리 사용률, 누적 트랜잭션 등 다양한 상황에 대한 기준 값을 선정하고 이에 대한 알림을 받을 수 있어야 합니다. 초기 이슈 확인은 고객이 영향을 받기 저너에 문제를 해결할 수 있게 해 줍니다. 3. 사용자 관점에서 모니터링 해야 합니다. 예를 들어 TPS의 평균값만으로 서비스의 안정성을 판단해서는 안됩니다. 사용자 개개별 현황을 파악 할 수 있어야 합니다. 기업의 브랜드는 서비스 사용에 불편을 겪는 1%의 고객을 통해 내려갈 수 있습니다.4. 메트릭을 비지니스 목표와 맞출 수 있어야 합니다. 현재 서비스에 접속한 사용자 현황을 알 수 있어야 합니다. 예를 들면 동시 접속자 수를 기반으로 현재 서비스의 성능을 설명할 수 있어야 합니다. 5. 애플리케이션에서 특히 데이터베이스의 성능을 평가할 수 있어야 합니다. 많은 이슈들이 데이터베이스에서 발생합니다. 6. 애플리케이션의 코드 성능을 분석할 수 있어야 합니다. 많은 프로젝트에서 오픈소스 또는 서드파티 솔루션들이 사용되고 있습니다. 여기서 발생하는 문제들은 심각한 장애 상황을 유발할 수 있습니다.7. 모든 서비스를 분석 할 수 있어야 합니다. 몇몇 페이지가 아니라 전체 페이지를 분석 할 수 있어야 합니다. 우리는 항상 효율적인 IT 모니터링 전략을 재평가하고 새로 구축해야 합니다. 모니터링 전략을 만드는 것은 쉬운 일이 아닙니다. 하지만 모니터링 전략을 만드는 데 시간을 투자하는 것은 안정적으로 서비스를 운영하는데 있어서 매우 가치있는 일입니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1399

스타일쉐어 커머스 시스템 리빌딩 회고 1

스타일쉐어 스토어 소개스타일쉐어 스토어(이하 커머스)는 2016년 4월 출시되어 지금까지 나날이 성장하고 있습니다. 작년 초, 커머스 시스템을 리빌딩하기로 했고 현재까지 진행 중입니다. 어떤 이유로 리빌딩을 하는지, 어떤 고민을 했는지, 어떻게 진행하고 있는지 몇 자 적어보려 합니다. 이 글은 문제 인식, 목표, 계획에 대한 내용입니다.리빌딩을 결정한 이유커머스 프로젝트를 시작할 당시 커머스 시스템을 경험해본 개발자가 없었습니다. 이 상황에서 새로이 구현하기엔 위험 부담이 크다는 판단을 했습니다. 때문에 커머스 솔루션을 도입했고, 적은 비용으로 커머스 기능을 출시할 수 있었습니다. 거래량이 점점 늘어나면서 솔루션이 감당할 수 있는 한계치를 벗어나자, 예상치 못했던 기술적인 이슈가 발생했습니다. 사내 MD팀, CS팀은 물론, 입점사들과 유저들에게까지 불편한 경험을 주고 있었습니다. 개발팀은 솔루션 유지 보수와 운영 이슈에 집중했지만, 끝이 없는 문제들에 점점 지쳐갔습니다. 개발팀의 퍼포먼스는 저하되고 있었고, 새로운 기능 개발에 집중하지 못하는 상황까지 발생했습니다. 이 시점에서도 거래량과 매출은 꾸준히 늘어났으며, 더 늦기 전에 리빌딩을 진행해야겠다고 판단했습니다.리빌딩의 목표당장 눈앞에 생겨나는 문제들로, 서비스가 해결하고자 하는 본질적인 문제들에 집중하지 못하는 상황입니다. 궁극적으로 이 상황을 개선하고 싶었습니다. 그리고 선택의 기로에 섰을 때 좋은 기준을 제시하기 위해, 언제 끝날지 모르는 리빌딩이 산으로 가는 걸 막기 위해 목표를 몇 가지 세웠습니다.유지보수 및 운영 이슈에 소모되는 개발 리소스 최소화커머스 시스템과 연계되는 기능들을 공격적으로 개발할 수 있도록 함개발 리소스 대비 높은 퍼포먼스를 낼 수 있어야 함튼튼한 커머스 시스템목표 1. 유지보수 및 운영 이슈에 들이는 개발 리소스 최소화기존 솔루션의 큰 레거시는 소모될 개발 리소스의 양과 일정을 예측하기 어렵게 만들었고, 개발자에게도 큰 스트레스를 안겨줬습니다. 서비스의 성장을 방해하는 큰 걸림돌 중 하나이며, 개발팀의 움직임을 느리게 만드는 주된 원인이었습니다. 리빌딩을 완료하더라도 유지보수와 운영 이슈는 끝이 없을 테지만, 더 이상 같은 문제를 반복하고 싶지 않았습니다. 효율적인 개발 리소스 운용을 위해선 가장 신경 써야 하는 부분이라고 생각됩니다.목표 2. 커머스 시스템과 연계되는 기능들을 공격적으로 개발할 수 있도록 함기존 솔루션 레거시가 너무 복잡하여 기능을 추가하거나 개선하기 어려워 반려한 요구사항이 많았습니다. 매력적인 요구사항에도 조심스럽게 대응했습니다. 서비스 성장을 위해 다양한 시도를 해야 하는 상황인데, 기술적인 이유로 진행이 까다롭다고 말하는 게 항상 아쉬웠습니다. 개발팀에서도 좋은 기능을 공격적으로 구현하고 싶으나, 실제로도 작업하기 까다로워 항상 답답했습니다. 어떤 방법이던 괜찮으니 지금보다 훨씬 더 공격적인 기능 구현으로 서비스 성장에 좋은 영향을 주고 싶었습니다.목표 3. 개발 리소스 소모 대비 높은 퍼포먼스를 낼 수 있어야 함스타일쉐어 팀은 기존 서비스 운영과 동시에 항상 새로운 무언가를 찾으려 합니다. 개발팀은 이 움직임에 맞춰 개발 리소스를 효율적으로 운용해야 합니다. 하지만 개발 리소스는 한정적이며, 다양항 상황에 따라 유동적으로 변해 예측하기 어렵습니다. 이런 상황에서 커머스 관련 작업 시, 언제나 평균 이상의 높은 퍼포먼스를 내고 싶었습니다.목표 4. 튼튼한 커머스 시스템커머스 시스템의 장애는 매출에 직접적인 악영향을 줍니다. 어떤 작업을 하더라도 커머스 시스템은 잘 운영되어야 합니다. 높은 가용성은 개발팀의 숙명이며, 공격적인 기능 개발에도 높은 가용성을 유지하려면 더욱 신경 써야 합니다.모두 꿈에 가까운 목표들입니다. 이 목표들에 조금이라도 더 가까이 다가갈 수 있도록 노력한다면 보다 좋은 결과를 얻을 수 있을 거라 생각했습니다.현실 반영과 계획당연하게도 현실적인 부분을 생각해야 했습니다. 이미 예정된 작업들이 많아 리빌딩에 필요한 개발 리소스를 확보하기 어려웠고, 개발 성공 여부 또한 불확실해 팀원들을 설득하기 어려웠습니다. 유지보수와 운영 이슈는 끝이 없었고, 회사 방향에 따라 추가 기능 개발과 개선 작업을 진행해야 했습니다. 이 상황을 고려해 리빌딩을 성공적으로 진행할 수 있도록 계획을 세워나갔습니다.개발 리소스에 여유가 생길 때까지 서브 프로젝트로 진행기존 커머스 시스템과 리빌딩된 시스템을 동시에 운영할 수 있어야 함적절한 단위로 서비스를 나눠 안전하고 효율적으로 개발 진행계획 1. 개발 리소스에 여유가 생길 때까지 서브 프로젝트로 진행다들 리빌딩이 필요하다고 느꼈지만, 선뜻 진행하기엔 큰 부담이었습니다. 시간이 흘러 여유가 생길 때 리빌딩을 진행해도 되지만, 그땐 너무 늦을 것 같았습니다. 최대한 빨리 작업을 시작하고 싶었고, 그러기 위해선 서브 프로젝트 수준으로 진행하는 게 제일 빠른 방법이라 생각했습니다.계획 2. 기존 커머스 시스템과 연동되어 동시에 운영할 수 있도록 함리빌딩의 완료 시점을 예측하기 어려웠습니다. 때문에 기존 커머스 시스템을 운영하며 리빌딩을 진행해야만 했습니다. 그리고 리빌딩된 시스템은 점진적으로 기존 커머스 시스템을 교체해 나가야 하므로, 두 시스템이 서로 연동되어야 했습니다. 또한 리빌딩된 시스템이 잘 동작할지에 대한 확신이 없어, 언제나 후퇴 계획을 세워야 했습니다. 이런 이유로 기존 커머스 시스템의 DB와 스키마를 그대로 사용하고, 두 시스템의 로직이 서로에게 문제가 되지 않도록 조심스럽게 개발하기로 했습니다.계획 3. 적절한 단위로 서비스를 나눠 안전하고 효율적으로 개발 진행커져가는 개발팀과 복잡해져 가는 커머스 시스템을 생각하면 요즘 자주 들리는 마이크로 서비스 구조(이하 MSA)를 도입해도 되지 않을까 싶었습니다. 솔직히 이런저런 이유보다, 재미 때문에 도입해보고 싶었습니다. 처음 도입하는 구조라 조심스러웠지만, 적절한 단위로 서비스를 나눈다면 충분히 좋은 효율을 낼 수 있을 것이라 생각되었습니다. 재미와 만족은 덤이고요. 서비스를 나누는 기준은 2가지로 잡았습니다.개발 안정성/개발 속도 둘 중 어느 것에 집중해야 하는가?서비스를 사용하는 주체는 누구인가?—개발 안정성/개발 속도 둘 중 어느 것에 집중해야 하는가?개발 안정성과 개발 속도에 대해 생각한 이유는 시스템 안정성과 작업 퍼포먼스 모두 잡고 싶은 마음 때문이었습니다. MSA는 서비스 별로 다른 언어를 사용해도 괜찮다는 장점이 있습니다. 덕분에 상황 별로 각기 다른 언어를 사용할 수 있고, 이를 통해 개발 안정성 혹은 개발 속도에 잘 집중할 수 있을 것이라 기대했습니다. 나중에 기술 스택을 설명하면서 얘기를 하겠지만, 개발 안정성을 추구해야 하는 부분은 java8로, 개발 속도를 추구해야 하는 부분은 node나 python으로 구현됩니다.서비스를 사용하는 주체는 누구인가?서비스를 어떤 기준으로 나눌지 고민이 많았습니다. 처음엔 상품 관리, 주문 관리, 출고 관리 등 DB 테이블에 가까운 기준으로 나누려고 했으나, 서버 운영이 큰 부담으로 다가올 것 같다는 의견 때문에 다른 기준을 세워야 했습니다. 서비스를 사용하는 주체 별로 나누면 어떨까라는 말이 나왔고, 이 기준이라면 큰 부담이 없을 것 같았습니다. 서비스를 사용하는 주체는 유저, 관리자, 입점사, 다른 서비스 이 4가지라고 정의했고, 이에 따라 서비스를 구성했습니다.—앞서 말한 두 기준으로 나눴을 때에 대한 예시입니다.유저 커머스 서비스 (node 혹은 python)관리자 커머스 서비스 (node 혹은 python)입점사 커머스 서비스 (node 혹은 python)커머스 핵심 기능 서비스 (java8)위 두 기준 말고도 서비스 운영에 큰 부담이 없다면 상황에 맞춰 다른 기준을 세워 서비스를 나누기도 했습니다.이 고민이 끝난 후, 현실적으로 실행 가능한 계획이 나온 것 같아 만족스러웠습니다. 이 계획을 토대로 아키텍처를 구성하고 개발을 진행했습니다.마무리어떤 문제 때문에 리빌딩을 결정했고, 어떤 목표와 계획을 세웠는지 주저리주저리 적어봤습니다. 앞에서 말했듯이 리빌딩은 아직 진행 중입니다. 현재 정식 일감으로 진행되고 있고, 상황에 맞게 계획을 다시 세워 조금씩 목표에 다가가고 있습니다. 처음엔 3부로 계획했지만, 아직 리빌딩 중이란 걸 까먹고 있었나 봅니다. 이 프로젝트가 완료되기 전까진 회고록으로써 글을 계속 쓸 것 같습니다. 앞으로 풀어야 할 문제들이 많으니 하소연할 것들도 많을 거고요. 아무쪼록 다음 편에선 시스템 구성도와 기술 스택에 대해서 한번 이야기해보려 합니다.스타일쉐어 개발팀의 고민과 생각들이 부디 도움이 되었길 빕니다. :)#스타일쉐어 #개발팀 #리빌딩 #인사이트 #조언
조회수 2236

[인공지능 in IT] 네가 내 마음을 알아?

지난 2018년 3월, 고용노동부는 10월부터 발효되는 '감정노동자 보호법 개정안'을 통과시켰다. 해당 개정안은 고객의 폭언이나 폭력으로부터 스트레스를 받는 감정노동자의 인권과 업무의 질을 개선시킬 사업주 조치를 의무화하는 내용을 담고 있다. 감정노동이란, 고객을 응대하며 자신의 본래 감정과는 상관없이, 업무상 정해진 감정 표현을 연기하는 것을 일상적으로 수행하는 노동을 말한다. 예로 콜센터, 백화점 안내, 텔레마케터 등이 있다.< 감정노동자 보호를 위한 5개 금융업법 개정안 주요 내용, 출처: 동아닷컴 >이제 정부는 감정노동자의 '적응 장애'와 '우울증' 등을 업무상 질병으로 인정한다. 세계보건기구(WHO)에서 정의한 건강은 '육체적, 정신적, 사회적, 영적으로 안녕한 상태'다. 즉, 감정노동자들은 육체뿐만 아니라 정신적, 사회적으로 고통받을 수 있다는 것이다. 그들은 자동으로 저장된 말을 내뱉는 음성 안내기가 아니고, 일반 사람들처럼 똑같이 울고 웃는 사람이다. 그렇지만, 아직까지 국내에서 심리상담에 대한 정서적인 장벽은 높고, 상담 받을 수 있는 인프라도 잘 갖춰지지 않다. 감정노동자들이 실질적인 상담 도움을 받기는 어렵다는 의미다.감정노동 소식 뒤, 국내 인공지능 기술 업체 중 한 곳이 심리상담 서비스를 출시했다는 기사를 접했다. 전문 심리 상담사들이 축적한 수많은 상담 시나리오 데이터를 수집하고 구축해, 개별적이고 정확한 서비스를 제공한다는 것이 취지다. 또한, 통화 목소리를 기반으로 이를 감정 데이터로 변환시켜 정신 건강에 대한 정보와 스트레스 관리 등을 위한 맞춤형 콘텐츠를 제공하는 것이 목적이다. 정확도는 알 수 없지만, 인공지능이 인간의 감정을 인지하고 생활에 도움을 줄 수 있다는 사실만으로도 큰 의미가 있다고 생각한다.사실 필자는 몇 년 전까지 매 순간 변하는 복잡한 인간의 감정은, 인간 고유의 것이라고 생각했다. 인간은 자신의 감정을 알지 못할 때도 있고, 긍정적인 감정과 부정적인 감정을 주체하지 못하기도 한다. 아직 우리 스스로 감정에 대해 확실하게 정의할 수 없고, 통제할 수 없다. 하지만, 그럼에도 불구하고, (앞서 언급한) 심리상담 서비스처럼 여러 분야에서 기계가 인간의 감정을 이해하고, 심지어 감정 표현을 돕는 연구는 거듭되고 있다.기계와 감정의 접목은 2000년대 이전부터 시작되었다. 1995년 MIT의 피카드(Rosalind Picard) 박사가 처음으로 감성컴퓨팅이라는 용어를 사용하며, 인간의 감성을 분석하고 해석하는 기술 개발을 시작했다. 감성 컴퓨팅은 인간이 느끼는 바를 인지, 해석, 처리할 수 있는 시스템을 설계하기 위한 인공지능 기술을 연구하고 개발하는 분야다. 감정 인식은 상상 이상으로 복잡하고, 아직까지 정확하게 구현하기 힘든 어려운 기술이지만, 조금씩 그 영역을 확장하며 다양한 분야에서 사용되고 있다.아무래도 사람의 감정을 드러내는 표면적인 수단 중 가장 눈에 띄는 것이 표정일 것이다. 얼굴에 드러나는 인간의 감정은 안면 근육의 움직임을 통해 여러 표정으로 나타나기 때문이다. 여기에 영상 처리 기술을 활용하면, 기계가 인간의 감정을 분류할 수 있다. 이를 기반으로 한 감정인식은 다음의 과정으로 이루어진다.먼저 영상이나 이미지 안에서 얼굴 영역을 찾는다. 일반적으로 스마트폰 카메라 앱에서 많이 볼 수 있듯, 네모 박스 형태로 얼굴을 인식한다. 그리고 해당 박스 안에서 눈, 코, 입 등 랜드마크라고 불리는 특징점들을 찾는다. 이어서 각 특징점을 바탕으로 각각의 위치나 배치를 파악하는 프로세스를 거친다. 마지막으로 학습을 거쳐 사람의 표정을 인식할 수 있다.일반적으로 감정 쪽을 연구하고 기술을 개발하는 업체 대다수는 이러한 딥러닝 방식을 적용한다. 그리고 미리 지정한 각각의 감정 메트릭에 사용자의 표정을 맵핑하는 식으로 결과값을 도출한다. 하나 주의해야 할 점은 표정과 비교하는 감정이라는 결과값을 '확률(%)'로 산출한다. 예를 들어, 눈썹을 찌푸리고 눈이 커지면서 입을 벌리고 있으면, 감정은 '화남 95%, 놀람 20%, 슬픔 5%...' 등으로 표현하는 방식이다.< EMOTION>이외에도 톤, 크기, 템포 등 감정 변화에 따라 변하는 목소리를 분석하는 음성 인식 기술이나 몸의 특정 움직임을 분석해 감정 상태를 인지하는 동작 인식 기술 등이 있다. 특히, 음성 인식은 CS(고객 응대) 영역에서 빛을 발할 수 있다. 실시간으로 고객의 감정을 분석해 소통방식을 바꾸거나, 그들의 구매 패턴을 예측하는 데 도움을 준다.최근에는 페퍼를 비롯한 가정용 휴머노이드 로봇이 여럿 출시되면서, 감정인식 기술의 적용사례를 쉽게 찾아볼 수 있다. 이들 로봇들은 인간과 대화할 때 억양이나 표정을 인식하며, 심지어 때로는 인간의 감정을 예측하고 묻기도 한다. 물론, 아직까지 우리의 머리 속에는 기계라는 생각 때문에 상호간 자연스러운 대화나 감정을 전달하기 어렵다. 하지만 문자, 음성, 시각 등 현재도 여러 영역에서 인공지능 기술은 발전을 거듭하고 있다.< 핸슨로보틱스(hansonrobotics)의 휴머노이드 로봇 소피아(Sopjia), 출처: 핸슨로보틱스 >인간의 감정이라는 것은 하나의 영적인 매개체가 아닌, 복합적인 것이다. 결국 각 영역별 인공지능 기술이 고도화될수록 감정 인식에 적용할 수 있는 기술 또한 정교해진다는 것을 의미한다. 언젠가는 기계가 인간의 말상대가 되어주고, 함께 어려운 문제에 대해 의논할 수 있는 단계까지 이르지 않을까? 감정 노동자의 마음을 어르고 달래는 로봇이 등장할지도 모를 일이다.이호진, 스켈터랩스 마케팅 매니저조원규 전 구글코리아 R&D총괄 사장을 주축으로 구글, 삼성, 카이스트 AI 랩 출신들로 구성된 인공지능 기술 기업 스켈터랩스에서 마케팅을 담당하고 있다#스켈터랩스 #기업문화 #인사이트 #경험공유 #조직문화 #인공지능기업 #기술기업
조회수 1573

Docker Hub 이벤트를 Slack으로 받기

Docker Hub은 Docker Registry 중에 가장 돋보이지 않나 생각하는데는 다음과 같은 이유가 있다.써드파티 도구와 서비스 대부분이 Docker Hub를 우선적으로 지원한다.이미지 이름이 매우 짧다.AWS ECR: 319270577709.dkr.ecr.us-east-1.amazonaws.com/dailyhotel/myweb:1.0.1Docker Hub: dailyhotel/myweb:1.0.1단순하지만 강력한 도커 빌드 서비스를 제공한다.이 외에도 도커 허브는 장점이 많은데 도커 이미지를 도커 허브에서 빌드하거나 외부에서 docker push를 해서 도커 이미지를 레지스트리에 밀어넣으면 해당 이벤트를 Webhook로 외부에 전달해주는 기능도 그 중 하나이다. 이론적으로는 새 도커 이미지가 나올 때마다 Slack을 통해 알람을 받을 수 있다. 하지만 놀랍게도! 도커 허브는 Slack 등의 대중적인 써드 파티 서비스와의 통합 기능을 직접 지원하지 않는다. 기본적으로 도커 허브가 보내는 Webhook를 파싱해서 슬랙 등으로 보내는 서비스는 직접 구현하거나 누군가 만든 도구를 직접 설치해 사용해야 한다.구글링하면 구현체가 몇 개 나오는데 그 중 일부는 matsengrp/relay를 커스터마이징한 것이다. 다른 구현체도 있지만 matsengrp/relay가 제일 구성이 깔끔하고 커스터마이징하기 쉬웠기 때문에 이를 기반으로 더 쓸모있는 구현체를 만들기로 했다. 새로운 구현체는기존 프로젝트를 Dockerize하고소스 코드를 직접 수정하는 대신 환경변수로 설정을 제어하게 하고도커 이미지의 태그 등 중요 정보를 추가로 표시하며위트 넘치는 이미지를 추가하여 지나치게 사무적이지 않게 메시지를 구성하는데초점을 맞추었다. 그래서 나온 결과물은 다음과 같다.개인적으로는 매우 마음에 든다. Docker 이미지로 빌드했기 때문에 서비스를 띄우기도 매우 쉽다. README 문서에도 기술했듯docker run — env SLACK_URL=’https://hooks.slack.com/services/PUT/YOURS/HERE' — env RELAY_PORT=8080 — env=DEFAULT_CHANNEL=’#dev’ — env=IMAGE_URL=’https://i.giphy.com/LYDNZAzOqrez6.gif' -p 8080:8080 dailyhotel/relay이게 전부이다. IMAGE_URL 등 환경변수 대부분은 필수값도 아니어서 실제 설정은 더 간단명료하다. 도커 이미지가 간단한만큼 Kubernetes로 띄우기도 쉽다.apiVersion: v1 kind: Service metadata: name: slackrelay labels: app: slackrelay spec: ports: — name: http port: 80 targetPort: 8080 protocol: TCP selector: app: slackrelay type: LoadBalancer — - apiVersion: extensions/v1beta1 kind: Deployment metadata: name: slackrelay spec: replicas: 1 template: metadata: labels: app: slackrelay spec: containers: — name: slackrelay image: dailyhotel/relay:latest env: — name: SLACK_URL value: "https://hooks.slack.com/services/PUT/YOURS/HERE" — name: RELAY_PORT value: "8080" — name: DEFAULT_CHANNEL value: "#dev" ports: — name: slackrelay-port containerPort: 8080그래도 여전히 몇 가지 개선점이 있긴 하다. 예를 들어 슬랙의 Webhook URL 대신 API 토큰값을 설정으로 받으면 좀더 많은 기능에 접근할 수가 있다. 이러한 점은 향후 정말 필요할 때 개선해볼 생각이다.참고 자료Webhooks for automated builds는 Docker Hub가 보내는 Webhook 메시지를 기술한다. 제목만 읽으면 자동화된 빌드에만 해당하는 이야기 같지만 확인해보니 docker push로 이미지를 푸시했을 때도 동일한 메시지 포맷을 사용한다.RequestBin는 Webhooks for automated builds에서 언급한 웹 서비스인데 Webhook 개발 등에 매우 유용하다. 외부 서비스가 발송하는 HTTP 요청 메시지를 받아서 임시로 보관해준다. Webhooks for automated builds에서 기술한 메시지 포맷대로 실제로 발송되는지 확인하기에 매우 요긴했다.#데일리 #데일리호텔 #Docker #Slack #슬랙 #협업툴 #개발 #개발자 #인사이트 #꿀팁
조회수 2226

Good Developer 4 | 학습하는 개발자 -고농축 학습 자료 꿀팁

더 이상의 설명은 필요 없다.지금까지 우리는 Good Developer 시리즈는 커뮤니케이션과 나쁜 개발자의 습관을 통해 좋은 개발자가 무엇인지 알아보았다. 이번에는 좋은 개발자가 되기 위한 가장 중요한 조건 바로 학습하는 개발자에 대해 알아볼 것이다.개발자가 새로운 것을 익히고 배우는 것은 너무도 당연하다. 이것에 대해 글을 쓰는 것은 의미가 없는 것 같아서 많은 고민을 했다. 그래서 실질적으로 학습에 도움을 줄 수 있는 아주 고농축 꿀팁들을 주면 좋은 개발자가 되는데 도움이 되지 않을까 생각했다. 이번 편은 학습하는 개발자 - 고농축 학습 꿀팁 편이다.학습은 천천히, 그러나 꾸준히너무나 당연한 말을 한 번 더 하고 시작할까 한다. 개발뿐만 아니라 모든 학습이 마찬가지겠지만, 꾸준히 학습해야 하는 개발자에게 중요한 것은 학습 습관이다. 이것저것 깨작깨작 찔러보고 공부하는 깊이로는 새로운 기술들을 자신의 것으로 만들 수 없으며 오히려 시간을 낭비하는 것일 수도 있다. 하나의 기술을 배우기 시작했으면 서두르지 말고 천천히 음미하면서 학습해야 한다. 그 대신 한두 달 공부하고 끝내는 것이 아니라 충분한 깊이를 가질 때까지 꾸준히 학습하라!직장을 다녀본 사람은 알 것이다. 직장을 다니면서 따로 자기개발을 하고 학습을 하는 것이 쉽지 않다는 것을 말이다. 하지만 좋은 개발자, 더 나은 개발자가 되기 위해서라면 학습을 멈춰 서는 안된다. 그것이 개발자의 숙명이다. 그래서 개발은 정말 개발을 좋아하는 사람만이 할 수 있는 직업인 것 같다. 혹시 자신이 학습을 하는데 있어 자꾸 포기하게 되고 중단하게 된다면 이전에 썼던 '글로 배우는 코딩 1 | 포기하지 않고 끝까지 공부하는 법'편을 참고해보길 바란다.아래의 학습 정보들은 많이 알 수도 있는 정보지만, 개발자가 되려는 사람들, 잘 모르는 사람들에게는 분명히 좋은 정보가 되리라 생각한다. 알고리즘 사이트 Top 31. 백준 온라인 저지백준 저지는 1만 개 이상의 알고리즘 문제를 보유한 사이트다. 타 사이트에 비해 홈페이지 구성도 잘 되어 있고 문제도 잘 나누어져 있다.그리고 사람들이 문제들을 골라서 자신만의 문제집을 만들어서 공유하기도 한다. 또한 알고리즘 지원 언어도 60개 이상이기 때문에 어떤 언어를 공부하든 웬만해서는 문제없이 풀 수 있다.(이런 언어도 있나 싶을 정도로 많은 언어들의 채점을 지원하고 있다.)기회가 되면 언어들을 직접 세어보는 것도......Baekjoon Online JudgeBaekjoon Online Judge 프로그래밍 문제를 풀고 온라인으로 채점받을 수 있는 곳입니다. 14264 전체 문제 11797 채점 가능한 문제 9316 풀린 문제 64 채점 가능한 언어www.acmicpc.net2. 코드워즈(codewars)코드워즈는 게임 형식의 알고리즘 학습 사이트다. 약 20여 개의 언어를 지원하며, C, C++ C#, Go PHP, JAVA, Python 등 주요 언어들은 모두 지원한다. UI/UX적으로도 굉장히 구성이 잘 되어 있고 인터페이스만 익숙해지면 정말 좋은 코딩 학습 사이트다.영어 사이트이긴 하지만 어느 정도의 독해 수준이면 충분히 학습할 수 있다. 게임 형식으로 알고리즘을 풀기 때문에 정말 재미있게 알고리즘을 학습할 수 있는 사이트! 알고리즘 사이트 중 가장 추천하는 사이트다. 태그도 잘 되어 있어서 function, array, data types 별로 자신이 약한 부분을 집중적으로 학습할 수도 있다.Codewars: Train your coding skillsCodewars is where developers achieve code mastery through challenge. Train on kata in the dojo and reach your highest potential.www.codewars.com3. 프로그래머스프로그래머스는 단계적으로 알고리즘 문제를 풀어볼 수 있는데 최적화된 사이트다. 레벨 1부터 레벨 8까지 정리된 프로그래밍 알고리즘을 풀 수 있다. 지원되는 언어가 C++ 자바 파이썬 자바스크립트로 가장 많이 쓰는 언어만 지원한다는 단점이 있다.모든 문제가 한글이라서 영어가 부담되시는 분들에게는 체계적으로 부담 없이 할 수 있다. 문제를 풀고 제출하는 환경도 잘 구성되어 있어 편리성이 좋은 알고리즘 학습 사이트다. 다만, 다른 사이트 들에 비해 문제의 수가 적다는 점! 영어가 부담되고 단계별로 알고리즘 문제를 풀고 싶다면 이 사이트를 추천한다.프로그래머스동영상과 실습으로 구성된 최고의 프로그래밍 강좌를 만나세요. 프로그래머스에서는 프로그래밍 강좌, 알고리즘 문제, 프로그래밍 대회, 블록체인 자료를 만날 수 있습니다.programmers.co.kr코딩 학습 사이트 Top 51. 유데미(Udemy)엄청나게 질 좋은 강의를 엄청나게 저렴한 가격으로 이용할 수 있는 곳! 1만 원대의 강좌에서 이 정도 퀄리티의 학습 콘텐츠를 얻기는 유데미 외에서는 불가능할 것이다.(광고 글이 아니다 정말이다.) 강의의 분야와 주제도 많고(개발 외에도 여러 가지가 있다) 짧게 짧게, 5~7시간 커리큘럼의 강의들이 많아서 부담 없이 학습할 수 있는 사이트. 강의 수준도 초급부터 고급까지 다양해서 수준 있는 개발자들도 들을 강의가 많다.대부분이 영어 강의이기는 하지만 요즘 한국 강사들의 유입도 늘어서 한국 강의도 늘고 있는 추세다. 영어 자막도 제공하니 영어를 읽을 수만 있다면 강력 추천하는 학습 사이트다.글을 클릭하면 유데미 사이트로 이동합니다.2. 코드카데미(codecademy)체계적으로 코딩을 배우고 싶은데 무료로 배우고 싶다면?! 바로 코드카데미다. 동영상은 보기 귀찮고 읽으면서 단계적으로 코딩을 배우고 싶다면 코드카데미가 적격이다. 자바스크립트를 주축으로 하는 개발 도구 위주만 배울 수 있다는 단점이 있지만, 코딩을 직접 하면서 배울 수 있다는 큰 장점이 있기 때문에 동영상 강의만 보고 그냥 넘길 수 있는 다른 사이트와는 다르게 바로바로 코딩을 쓰면서 배울 수 있다. 역시 영어 학습 사이트지만 개발자가 되기 위해서 필요한 영어 실력만 가지고 있어도 충분히 학습해 나갈 수 있다.Codecademy - learn to code, interactively, for freeCodecademy is the world's most popular way to learn over 12 coding languages including HTML, CSS, JavaScript, Python, SQL, and Ruby. Sign up today and start learning to code in minutes.www.codecademy.com3. 코드스테이츠한국 최초의 코딩 부트 캠프 코드스테이츠. 코드스테이츠 입장에서 코드스테이츠를 추천하는 것이 민망해해 보일 수 있어도, 그만큼 자부심이 있다. 온/오프라인 교육이기 때문에 다른 온라인 교육 사이트보다 저렴하지는 않지만, 개발자를 꿈꾼다면 일정 금액을 투자하고 개발자가 확실히 될 수 있다는 장점이 있다.  온/오프라인에서 직접 멘토링을 받아 가면서 학습을 하고 싶다면 코드스테이츠를 강력 추천한다.온라인 학습과 오프라인 코칭으로 온라인 콘텐츠와 오프라인 교육을 둘 다 가져갈 수 있다는 장점이 있다. 코스 중간에 미니 해커톤과 실제 기업과 협업 프로젝트를 진행해 볼 수 있다는 것도 큰 장점! 단점은 다른 온라인 학습 사이트에 비해서는 가격이 어느 정도 있다.코드스테이츠 | 혁신적인 코딩 교육 부트캠프코드스테이츠(Code States)는 프로그래밍을 배우고 싶은 사람들을 위한 최상의 코딩 교육 프로그램을 제공합니다. 자바스크립트 HTML CSS를 기초로 탄탄한 이론과 실무에 최적화된 기술 스택들을 학습합니다. 주입식이 아닌 자기주도적 학습 방식으로 기존과는 차별화된 혁신적인 교육 시스템을 경험해보세요.goo.gl4. 유다시티유다시티는 가격대는 있지만 탄탄하고 검증된 커리큘럼의 온라인 학습 사이트다. 프로젝트 베이스에 과제도 탄탄하고 동영상 학습 중간중간 텍스트 자료와 퀴즈까지 적절하게 섞여 있어서 충분히 제값을 한다. 다른 온라인 학습 사이트에 비해 가격대가 있지만 그만큼 퀄리티는 훌륭하다. 가장 핫한 트렌드의 기술들도 배울 수 있고 난이도도 초급부터 고급까지 다양한 과정들이 있다.유다시티에서는 학습하기가 굉장히 편하다. 학습 시간을 적절히 쪼개서 부담 없이 학습이 가능하고 자료 또한 탄탄하다는 것이 장점! 하지만 역시 온라인 학습치고 가격은 부담이 된다.Udacity - Free Online Classes & Nanodegrees | UdacityJoin Udacity to learn the latest in Deep Learning, Machine Learning, Web Development & more, with Nanodegree programs & free online courses.www.udacity.com5. 인프런영어가 유데미가 있다면 한국어는 인프런이 있다! 다양한 수준의 프로그래밍 강의를 한국어로 들을 수 있는 온라인 학습 사이트다. 탄탄한 커리큘럼에 강좌 구성까지. 필요한 강의를 골라 들을 수 있다는 장점이 있다. 한국어 강좌다 보니 강사들과의 소통도 원활하다. 영어가 아직은 부담스럽다면 인프런에서 먼저 시작해보자!퀄리티 높은 무료 강좌도 존재하니 처음에는 무료 강좌들을 보면서 나에게 맞는지 확인해 보고 학습을 시작하면 된다. 단점은 유데미 보다는 가격이 비싸다는 점! 하지만 한국어 강의가 많다는 것 자체가 엄청난 장점이라 할 수 있겠다.인프런 - IT, 개발의 좋은 지식을 공유합니다개발, CG, 디자인 등 IT 분야의 고급 지식들을 편하고 경제적으로 학습할수 있는 공간입니다. 배우는 사람에겐 기회를, 지식공유자에겐 보상을 주는 문화를 만들어요.www.inflearn.com코딩 관련 질문을 하고 싶다면스택오버플로우(stackoverflow)스택오버플로우는 개발과 관련된 질문과 답변을 하는 사이트다. 코딩을 하다가 중간에 막혔는가? 괜찮다. 당신의 문제는 이미 선배 개발자들도 했던 고민이니 말이다. 스택오버플로우에서 how to 라는 말과 함께 당신이 궁금한 점을 물어보라 마법과 같은 일이 펼쳐질 것이다. 당신이 알고 싶어 하는 거의 모든 개발 관련된 문제들에 대한 답이 이곳에 있다.영어라서 부담스러워하지 말고 익숙해져보라. 스택오버플로우만 잘 이용해도 현재 당신이 안고 있는 개발 문제의 대부분이 해결될 것이다. 단, 이곳에서의 코드를 너무 복붙 했다가는 오히려 실력 저하가 온다는 것을 명심하기를...Stack Overflow - Where Developers Learn, Share, & Build CareersStack Overflow | The World’s Largest Online Community for Developersstackoverflow.com블로그&커뮤니티JS서울js서울은 자바스크립트에 대해 넓고 얕은 지식을 서울 사용자들에게 보급하려는 지역기반 커뮤니티다. 슬랙방을 만들어서 운영되고 있으며 자바스크립트를 이용하는 이용자라면 활동을 해보면 좋을 것이다.seoul.jsMeetups 2017.08.18(1st) Meeting Notes 2017.07.10 2017.07.19(kickoff) 2017.10.11(conference Staff Offline Meeting 1st) 2017.10.31(conference Staff Online Meeting 1) Seoul.js About Code Of Conduct Sponsors Why We Started Seoul.js Logo Call For Speaker Plan 2018 이제 폭넓게 사용되는 자바스크립트의 매력과 인사이트를 대한민국, 서울에seoul.js.orgOkky개발자들의 커뮤니티, 페이스북이 아니라 다른 페이지를 만들어서 활동하고 있는 개발 커뮤니티 중 가장 큰 규모가 아닌가 생각한다. 개발 관련된 질문도 하고 개발자와 관련된 생활, 진로, 일상들을 이야기하는 개발자 커뮤니티다. 질문을 올리면 선배 개발자들의 따끔한 조언을 얻을 수 있다.OKKY - All That DeveloperEditor's Choice 실리콘밸리를 그리다 - 24. 애자일 방법론으로 프로젝트 진행하기 Karen 10k 6일 전 [OKKY 세미나] 대용량 서비스 성능 개선 노하우 Karen 10k 6일 전 'IT업계 포괄임금제 미적용 특례지정'을 요청합니다. Good Luck 484 8일 전 [OKKY 취준 세미나] 국비 지원 학원 선택의 노하우와 효과적 학습법에 대하여 형 439 13일 전 OKKY 스팸 단어로 인한 글 등록 불가 문제 관련 공지사항 OKKY 475 29일 전 Q&A 자동로그인 코드 구현 할okky.kr조대협님 블로그이미 알만한 사람은 다 안다는 조대협님의 블로그. 개발자 블로깅은 이렇게 하느거야라는 정수를 느낄 수 있고 실제 유익한 정보들이 많이 올라온다. 유명한 개발자 블로거들이 많지만 나열하자면 지면이 길어지기에 대표적인 조대협님의 블로그를 추천한다. 개발 관련된 글, 정보를 얻고 싶다면 이곳에 들어가 보라!조대협의 블로그평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴.bcho.tistory.com
조회수 1834

Circle CI에서 rbenv를 이용해서 Ruby 2.2와 CocoaPods 0.39 버전 사용하기

최근 Circle CI에서 Ruby 버전을 2.3으로, CocoaPods 버전을 1.0으로 업그레이드함에 따라 발생하는 빌드 문제를 rbenv를 이용해서 해결한 경험을 공유합니다. 최종적으로 완성된 Gemfile과 circle.yml 파일은 마지막 섹션에서 확인하실 수 있습니다.1. CocoaPods 1.0지난 2015년 12월에 CocoaPods 1.0.0 베타 버전이 처음 공개되었습니다. CocoaPods이 1.0 버전으로 업그레이드되면서 굉장히 많은 변화가 있었는데요. 가장 큰 변화는 DSL입니다. 추상 타겟Abstract Target과 타겟 상속Target Inheritance이 새롭게 소개되면서, 0.39 버전까지 자주 사용되던 link_with 및 :exclusive => true와 같은 구문이 제거되었습니다.이에 따라 기존에 사용하던 Podfile이 CocoaPods 1.0 버전과는 호환되지 않는 문제가 발생했습니다. 이를 해결하기 위한 가장 좋은 방법은 새로운 DSL을 사용하여 Podfile을 다시 작성하는 것이지만, 꽤 많은 서드파티 라이브러리를 사용하는 StyleShare의 경우 새로운 DSL을 적용하여 빌드하면 각종 문제로 인해 빌드가 정상적으로 이루어지지 않았습니다. 4년동안 유지되고 있는 프로젝트이다보니, 레거시 Objective-C 코드와 라이브러리, 그리고 새로운 Swift 코드와 라이브러리가 혼용되어 사용되는 것도 원인 중 하나일 것입니다.따라서 StyleShare에서는 CocoaPods 0.39 버전을 사용하기로 결정을 했습니다. 하지만 최근 Circle CI에서 CocoaPods 버전을 공식적으로 1.0 버전으로 업그레이드하면서 빌드가 깨지기 시작했습니다. Circle CI 환경에서 CocoaPods 0.39 버전을 사용하려면 어떻게 해야 할까요?▲ ㅠㅠ2. Bundler를 이용해서 Gem 관리하기Bundler는 Ruby로 작성된 라이브러리들의 버전을 관리해주는 강력한 도구입니다. CocoaPods에서 Podfile에 의존성을 기재하듯, Bundler에서는 Gemfile에 의존성을 기재합니다.source 'https://rubygems.org' gem 'cocoapods', '~> 0.39' $ gem install bundler 명령어를 사용하면 Gemfile에 기재된 의존성 라이브러리들을 설치해줍니다. 이렇게 설치된 CocoaPods을 사용할 때에는 $ pod COMMAND 대신 $ bundle exec pod COMMAND 명령어를 사용해야 합니다.$ gem install bundler $ bundle install --path vendor/bundle $ bundle exec pod --version 0.39.0 3. Ruby 2.3과 CocoaPods 0.39Bundler를 사용해서 CocoaPods 0.39 버전을 사용하기만 하면 모든 문제가 해결될 줄 알았습니다. 하지만 더 큰 삽질이 남아있었는데요. 바로 Ruby 2.3 버전이 CocoaPods 0.39 버전과 호환되지 않는 것이었습니다.$ bundle exec pod install Updating local specs repositories Analyzing dependencies 신나게 $ bundle exec pod install 명령어를 실행하니, 의존성을 분석하는 듯 싶다가 갑자기 에러를 주르륵 뱉습니다. 에러 로그의 #### Error 항목을 보면 에러 메시지가 나와있습니다.NoMethodError - undefined method `to_ary’ for #이 에러 메시지로 CocoaPods GitHub 저장소의 이슈를 검색해보면 꽤나 많은 이슈가 올라와 있습니다. 이 이슈들을 보면, 모두 Ruby 버전이 2.3이라는 공통점이 있습니다. Ruby 버전을 2.2로 내렸더니 문제가 해결됐다는 댓글들도 굉장히 많고요. Circle CI의 Ruby 버전을 2.2로 낮추면 문제가 해결될 것 같습니다.Circle CI 문서 내용에 따라 circle.yml에 Ruby 버전을 기재해봅시다.machine: ruby: version: 2.2.5 그러나 Circle CI의 OS X 컨테이너에서는 Ruby 버전 변경을 지원하지 않는다고 합니다.▲ ㅠㅠ (2)4. rbenv를 이용해서 Ruby 2.2 사용하기그러다가 알게된 것이 바로 rbenv입니다. rbenv를 사용하면 여러개의 Ruby 버전을 깔끔하게 관리할 수 있게 됩니다. rbenv는 Homebrew를 사용해서 쉽게 설치할 수 있습니다.$ brew install rbenv rbenv는 ~/.rbenv 디렉토리에 안에 여러 Ruby 버전을 설치하고 관리합니다. rbenv를 설치한 뒤 가장 먼저 할 일은 환경변수 $PATH를 설정해주는 것입니다. $PATH에는 $HOME/.rbenv/shims와 $HOME/.rbenv/bin 경로가 포함되어있어야 합니다.4.1 환경변수 설정하기Circle CI에서는 환경변수를 설정하는 편리한 인터페이스를 제공합니다. 하지만, Circle CI에서 실행되는 각 명령어는 별도의 쉘에서 실행됩니다. 그말인 즉슨, 각 명령어가 실행되기 직전에 새로운 쉘이 실행되고, $PATH 환경변수를 덮어쓰는 .bash_profile이 실행된 후 명령어가 실행된다는 뜻인데요. 이렇게 될 경우 $PATH 환경변수의 가장 우선순위는 항상 /usr/local/bin이 가지게 됩니다. 그리고 같은 이유로 $ export FOO=bar와 같은 명령어도 사용할 수 없게 됩니다.1고민을 하다가 생각해낸 방법은 바로 .bash_profile의 내용을 변경(!)하는 것입니다. 그렇게 되면 우리가 원하는 $PATH를 항상 우선순위로 둘 수 있게 됩니다. 아래와 같이 환경변수를 설정하는 명령어를 .bash_profile의 가장 아랫줄에 삽입하도록 설정했습니다.machine: pre: - echo "export PATH=\$HOME/.rbenv/shims:\$HOME/.rbenv/bin:\$PATH" >> .bash_profile - echo "export RBENV_SHELL=bash" >> .bash_profile 4.2 rbenv에 Ruby 2.2 설치하기그 다음으로 할 일은 원하는 Ruby 2.2 버전을 설치하는 것입니다. $ rbenv install -l을 사용해서 설치 가능한 모든 Ruby 버전을 조회할 수 있고, $ rbenv install 2.2.5 명령어를 사용해서 2.2.5 버전을 설치할 수 있습니다.$ rbenv install -l Available versions: 1.8.5-p113 1.8.5-p114 1.8.5-p115 1.8.5-p231 ... $ rbenv install 2.2.5 이렇게 설치된 버전은 두 가지 방법으로 사용될 수 있습니다. 한 가지 방법은 시스템 전체에서 사용하는 것이고, 다른 한 가지 방법은 프로젝트 단위로 사용하는 방법입니다. 시스템 전체에서 사용하려면 $ rbenv global 2.2.5 명령어를, 프로젝트 단위로 사용하려면 $ rbenv local 2.2.5명령어를 사용합니다.global 명령어를 사용해서 Ruby 버전을 선택하면 ~/.rbenv/version 파일에 선택된 버전이 기록됩니다.$ rbenv global 2.2.5 $ cat ~/.rbenv/version 2.2.5 local 명령어를 사용하면 현재 디렉토리의 .ruby-version 파일에 선택된 버전이 기록됩니다.$ rbenv local 2.2.5 $ cat .ruby-version 2.2.5 local 명령어로 선택된 Ruby 버전은 global 명령어로 선택된 Ruby 버전보다 우선순위가 높습니다. $ rbenv version 명령어를 사용하면 현재 선택된 버전을 확인할 수 있습니다.$ rbenv version 2.2.5 (set by /project/path/.ruby-version) Circle CI에서는 편의를 위해 global 명령어를 사용해서 Ruby 버전을 선택하도록 했습니다.dependencies: pre: - brew update - brew install rbenv - rbenv install 2.2.5 - rbenv global 2.2.5 4.3 Bundler 다시 설치하기rbenv를 사용해서 새로운 Ruby 버전을 설치했기 때문에, Circle CI 시스템에서 제공하는 Gem도 다시 설치해야 합니다. 우리는 Bundler로 Gem 의존성을 관리하기로 했으므로, Bundler만 재설치합니다.$ gem install bundler --no-ri --no-rdoc $ rbenv rehash $ gem install 명령어를 실행한 후에는 $ rbenv rehash 명령어를 실행해서 executable 경로들을 재설정해주어야 합니다.4.4 ~/.rbenv 경로 캐싱하기rbenv를 사용해서 Ruby를 설치하는 과정이 굉장히 오래 걸립니다. 이 경우, Circle CI에서 제공하는 캐싱 기능을 사용해서 이 과정을 한 번만 하고 건너뛸수 있게 됩니다.dependencies: cache_directories: - ~/.rbenv 위와 같이 circle.yml를 설정해주면 컨테이너 실행시 ~/.rbenv 디렉토리가 캐시로부터 설정됩니다. 캐싱된 디렉토리를 사용하는 경우 Ruby 버전이 미리 설치되어있기 때문에 $ rbenv install시에 --skip-existing 옵션을 추가해주어서 캐싱된 버전을 재설치하지 않도록 합니다.5. 마치며최종적으로 완성된 Gemfile과 circle.yml 파일은 다음과 같습니다.Gemfilesource 'https://rubygems.org' gem 'cocoapods', '~> 0.39' circle.ymlmachine: pre: - echo "export PATH=\$HOME/.rbenv/shims:\$HOME/.rbenv/bin:\$PATH" >> .bash_profile - echo "export RBENV_SHELL=bash" >> .bash_profile xcode: version: 7.3 dependencies: cache_directories: - ~/.rbenv pre: - brew update - brew install rbenv - rbenv install 2.2.5 --skip-existing - rbenv global 2.2.5 - gem install bundler --no-ri --no-rdoc - rbenv rehash - bundle install --path vendor/bundle override: - bundle exec pod --version - bundle exec pod install https://circleci.com/docs/environment-variables/#custom ↩#스타일쉐어 #개발 #개발자 #개발팀 #후기 #일지 #인사이트
조회수 6449

Elastalert로 로그 알람 구축하기

Elasticsearch로 로그를 수집하고 추세를 분석하기는 좋지만 실시간 알람을 받으려면 X-Pack Alerting 등을 이용해야 한다. 하지만 사용자 편의성 측면에서 개선할 점이 많다. 로깅 알람 전용이 아닌 다양한 용도로 커스터마이징해서 쓸 수 있게 설계한 탓일 수도 있다. 아무튼 대안을 살펴볼 필요가 있겠다 싶어서 Yelp가 공개한 Elastalert로 알람을(도) 적용해보았다.X-Pack Alerting과 비교했을 때 Yelp/elastalert의 장점은 명확하다. 무엇보다 시나리오별로 정해놓은 패턴에 따라 알람을 작성하면 일이 쉽게 끝난다. 여덟 가지 정도의 알람 타입이 있어서 상황에 맞는 템플릿을 가져다 쿼리만 살짝 고치면 된다.“Match where there are X events in Y time” (frequency type)“Match when the rate of events increases or decreases” (spike type)“Match when there are less than X events in Y time” (flatline type)“Match when a certain field matches a blacklist/whitelist” (blacklist and whitelist type)“Match on any event matching a given filter” (any type)“Match when a field has two different values within some time” (changetype)“Match when a never before seen term appears in a field” (new_term type)“Match when the number of unique values for a field is above or below a threshold (cardinality type)예를 들어 OutOfMemoryError라는 단어가 로그에 찍혔을 때 알람을 받고 싶다면 다음과 같이 Rule 파일을 준비한다.# Alert when the rate of events exceeds a threshold # (Required) # Rule name, must be unique name: OutOfMemoryError # (Required) # Type of alert. # the frequency rule type alerts when num_events events occur with timeframe time type: frequency # (Required) # Index to search, wildcard supported index: logstash-%Y.%m.%d* use_strftime_index: true # (Required, frequency specific) # Alert when this many documents matching the query occur within a timeframe num_events: 1 # (Required, frequency specific) # num_events must occur within this amount of time to trigger an alert timeframe: hours: 1 # (Required) # A list of Elasticsearch filters used for find events # These filters are joined with AND and nested in a filtered query # For more info: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl.html filter: - query_string: query: "message: OutOfMemoryError OR log: OutOfMemoryError" # (Required) # The alert is use when a match is found alert: - "slack"기본 템플릿을 가져다가 filter에 들어갈 쿼리만 다시 작성하면 일이 끝난다. 파이썬으로 작성한 간단한 소프트웨어라 사용하기도 쉽고 Docker로 만들기도 쉽다. pip install elastalert 그 외에 경험한 특이사항만 정리하고 이 글을 끝내려 한다.Elasticsearch의 플러그인으로 작동하는 X-Pack과 달리 ElastAlert는 독립 실행 애플리케이션이다. Kubernetes 같은 환경에서는 독립 실행 애플리케이션이 더 관리하기 쉽다.알람을 추가/삭제할 때마다 도커 빌드를 하기 힘든 환경이라면 RESTful API를 지원하는 X-Pack이 편할 것이다. back-end / elastalert 같이 RESTful API를 지원하는 ElastAlert 환경이 있긴 하지만 도커 배포환경에서는 여러 모로 한계가 있다. 도커를 올렸다 내렸다 하더라도 설정이 날아가지 않게 하려면 고민이 많아진다. node 애플리케이션과 Python 애플리케이션 둘을 하나의 도커 이미지로 제공하다 보니 다른 문제도 많다. 이런 식의 구성을 구현해봤다면 무슨 이야기인지 알 것이다.ElastAlerts는 Index Aliases를 지원하지 않는다. 물론 오픈소스이니 소스코드를 고쳐서 Pull Request를 보내면 될 일이다.X-Pack Alerting과 달리 알람 메시지를 정형화했다. 알람의 메시지 포맷을 조금 고칠 수는 있지만 기본적으로는 주어진 그대로 써야 한다. 간단하게 쓰기에는 낫고 그렇지 않다면 소스코드까지 손을 대야 한다.ElastAlert는 중복 알람 처리 등의 정책을 지정할 수 있다. 알람을 하루에 수백통 넘게 받아보면 이 기능이 왜 중요한지 알게 된다.문서에서 언급하듯 Elasticsearch 5.x와 함께 쓰려면 다음과 같이 버전을 명시하는 편이 좋다. pip install elasticsearch>=5.0.0 && pip install elastalert==0.1.8테스트 환경은 elastalert-test-rule 명령어를 제공하는 ElastAlert쪽이 더 낫다. 검색 쿼리를 제대로 작성했는지 알람 설정은 맞는지 확인하기가 쉬웠다.더 읽기ElastAlert: Alerting At Scale With Elasticsearch, Part 1ElastAlert: Alerting At Scale With Elasticsearch, Part 2Originally published at Andromeda Rabbit.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #일지 #후기 #도입후기 #Elastalert #인사이트
조회수 985

오토 레이아웃(Auto Layout), 넌 누구냐!

OverviewiOS 프로그래밍을 하면서 많이 접했던 단어 중 하나는 오토 레이아웃(Auto Layout) 입니다. 스토리보드에서 화면을 만들 때 오토 레이아웃을 이용해서 뷰와 컨트롤의 크기와 위치를 지정합니다. 이미 잘 사용하고 있지만 문득 정확하게 오토 레이아웃은 무엇인지 궁금해져 이번 기회에 써 보기로 했습니다. 오토 레이아웃(Auto Layout)은?오토 레이아웃(Auto Layout)은 제약 조건(Constraints)을 이용해서 뷰의 위치를 지정하는 것입니다. 다시 말하면, 두 뷰 사이의 관계를 제약 조건이라는 것을 이용해서 뷰의 크기와 위치를 지정하는 것입니다. 너와 나의 연결 고리!오토 레이아웃은 여러 해상도를 지원하려고 이 세상에 나왔습니다. 아이폰의 크기가 다양해지면서 해상도도 달라졌는데, 다른 크기에서도 같은 화면을 똑같이 보여주기 위해 오토 레이아웃을 사용합니다. 세로 보기 화면뿐만 아니라 가로 보기 화면까지도 지원합니다. 아이폰SE 혹은 아이폰8 Plus에서도 같은 비율의 화면을 볼 수 있도록 오토 레이아웃을 사용하는 것입니다. 만약 오토 레이아웃을 사용하지 않는다면, 아이폰 기종마다 스토리보드를 만들어야 하죠. 이렇게 되면 스토리보드 파일이 많아집니다. 앱을 실행할 때 아이폰 기종을 확인하고, 그에 맞는 스토리보드를 찾아 화면을 보여주는 번거로움도 생깁니다. 위의 이미지를 보면 아이폰SE와 아이폰8, 아이폰8 Plus 브랜디 앱 화면. 기종이 달라도 보여지는 화면이 똑같다는 것을 볼 수 있습니다. 오토 레이아웃을 이용해서 하나의 스토리보드에서 모두 대응할 수 있는 것이죠.Frame Layout vs Auto Layout전통적으로 앱은 유저 인터페이스를 각 뷰의 프레임(frame)을 프로그래밍 방식으로 계산해 배치합니다. 유저 인터페이스를 배치하려면 뷰 계층의 모든 뷰에 대한 크기와 위치를 계산해야 합니다. 그리고 변경이 발생하면 영향을 받는 모든 뷰에 대해 프레임을 다시 계산합니다.Frame Layout뷰의 프레임을 프로그래밍 방식으로 정의하면 유연해집니다. 어떤 변화가 생겨도 대응할 수 있기 때문입니다. 그러나 모든 변경 사항을 직접 관리해야 하기 때문에 많은 노력이 필요합니다. 설계부터 시작하여 디버그 및 유지 관리까지 많은 것을 관리해야 합니다. 가장 효과적인 방법이지만 난이도도 많이 어려워집니다.이와 달리 오토 레이아웃은 일련의 제약 조건을 사용하여 유저 인터페이스를 정의합니다. 제약 조건은 앞서 말한 것 처럼, 일반적으로 두 뷰 간의 관계를 나타냅니다. 그런 다음 오토 레이아웃은 이러한 제약 조건을 기반으로 각 뷰의 크기와 위치를 계산합니다.Auto Layout화면에 배치하는 모습이 같기 때문에 프레임 방식을 사용해도 되고, 오토 레이아웃을 사용해도 됩니다. 둘 다 스위프트와 오브젝티브 C를 지원하기도 합니다. 각각 장단점이 있지만 가장 많이 사용하는 방법이 오토 레이아웃입니다. 빠르게 적용할 수 있고 많은 시간을 줄일 수 있기 때문입니다.스토리보드에서의 오토 레이아웃iOS 앱 개발은 스토리보드를 이용해서 화면을 만듭니다. 그래서 스토리보드가 익숙한 개발자들이 많은데, 사실은 뷰를 배치하면서 썼던 툴이 오토 레이아웃과 관련된 것이었습니다.스토리보드 오른쪽 하단에 있는 메뉴핀(Pin) 메뉴는 버튼 또는 레이블과 같은 UI 요소에 새로운 제약 조건들을 추가할 수 있습니다. 시계 방향으로 Top, Trailing, Bottom, Leading 제약 조건의 값을 입력할 수 있고, 화살표를 누르면 어떤 뷰와 관계를 가질 것인지 선택할 수 있습니다. 두 뷰와 핀 메뉴를 선택하면 같은 너비와 높이를 설정할 수 있습니다.Pin 메뉴정렬(Align) 메뉴는 다른 뷰와의 가로, 세로 정렬과 같은 정렬 제약 조건들을 추가할 수 있습니다. 정렬하고 싶은 두 뷰를 선택하여 수직 정렬, 수평 정렬을 추가할 수 있습니다.Align 메뉴맨 오른쪽 메뉴인 오토 레이아웃 이슈 툴은 오토 레이아웃 관련된 이슈들을 해결하는 옵션들을 제공합니다. 오토 레이아웃을 현재 설정된 상태로 재설정하는 옵션들입니다. 상단은 선택된 뷰와 관련된 것이고, 하단은 모든 뷰와 관련된 것입니다.Resolve Auto Layout IssuesAlign 옆에 있는 Stack 메뉴는 복잡한 제약 조건 없이 오토 레이아웃의 기능을 쉽게 뷰를 배치할 수 있도록 스택에 쌓아서 묶어주는 스택뷰를 생성합니다. 하나의 묶음으로 만들 뷰들을 선택하여 Stack 메뉴를 선택하면 스택처럼 그룹으로 됩니다. 여기서 뷰 사이의 공간과 정렬들을 설정할 수 있습니다.Stack View로 만든 간단한 뷰, 오른쪽 메뉴에 정렬과 뷰 사이의 공간을 선택할 수 있는 곳이 있습니다.스토리보드에서 뷰를 배치하고 오토 레이아웃 메뉴들을 이용하면 아래 스크린샷과 같이 제약 조건들을 볼 수 있습니다. 어떤 값을 지정하는 것이 아닌 같다는 뜻의 “=“를 이용하여 제약 조건들을 표현합니다.스토리보드에서 많이 볼 수 있는 제약 조건들(Constraints)프로그램 상의 제약 조건들스토리보드에서만 제약 조건들을 설정할 수 있는 건 아닙니다. 프로그램 상에서도 제약 조건들을 설정할 수 있습니다. 스토리보드에서 뷰를 배치한 다음, 제약 조건들을 소스 파일과 연결해서 값을 지정할 수 있습니다. 주로 어떤 변화가 일어나면 제약 조건들을 다시 설정할 때, 프로그램 상에서 값을 다시 설정합니다. 예를 들어, 데이터가 있을 땐 해당 뷰를 보여줍니다. 만약 데이터가 없으면 그 뷰가 사라지면서 그 뷰와 관련되어 있는 다른 뷰의 제약 조건들을 다시 설정하여 화면에 재배치하는 것입니다.func hideTag(_ hide: Bool) {         if hide {             self.labelTag1.isHidden = true             self.labelTag2.isHidden = true             self.constLabelTag1Top.constant = 0.0             self.constLabelTag1Height.constant = 0.0         } else {             self.labelTag1.isHidden = false             self.labelTag2.isHidden = false             self.constLabelTag1Top.constant = 15.0             self.constLabelTag1Trailing.constant = 5.0             self.constLabelTag1Height.constant = 20.0         }     } 위 소스에서 hide 값에 따라 레이블의 숨김을 설정하고 레이블의 제약 조건의 값을 재설정하는 메소드가 있습니다. 데이터가 있으면 숨김을 해제하고 제약 조건들의 값을 설정하지만, 데이터가 없으면 레이블을 숨기고 제약 조건들의 값을 0으로 설정합니다.스토리보드에서 연결한 제약 조건들을 가지고 설정할 수 있는데, 프로그램 상에서 직접 제약 조건들을 생성하여 사용할 수 있습니다. 아래의 예시는 뷰의 높이를 60으로 설정하는 코드입니다.NSLayoutConstraint(item: self.testView, attribute: .height, relatedBy: .equal, toItem: nil, attribute: .notAnAttribute, multiplier: 1.0, constant: 60) Conclusion애플에서는 개발자가 다양한 해상도에 대응할 수 있게 오토 레이아웃이라는 시스템을 개발했습니다. 스토리보드에서 쉽게 화면에 뷰를 배치할 수 있고, 별다른 기능을 추가하지 않아도 다양한 아이폰 크기에 맞춰서 대응해줍니다. 오토 레이아웃을 이용하여 멋지게 모든 아이폰과 아이패드에 대응하는 앱을 개발해보세요! 곧 산호세로 떠나 설레는 마음으로 글을 마치겠습니다. 감사합니다. :)글김주희 사원 | R&D 개발1팀kimjh3@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발팀 #개발자 #개발환경 #업무환경 #인사이트 #경험공유
조회수 2448

시뮬레이션에서의 Process Mining(프로세스 마이닝) 활용

시뮬레이션은 실제로 실행하기 어려운 실험을 간단히 행하는 모의실험을 뜻하며, 특히 컴퓨터를 이용하여 모의실험을 할 때는 컴퓨터 시뮬레이션이라고 일컬어집니다.  시뮬레이션은 특수한 하드웨어를 사용하는 3D 가상현실이나 비행 시뮬레이션 등 다양한 분야에 사용되고 있으며, 이벤트 중심의 로그를 다루는 프로세스 마이닝에서는 이산 사건 시뮬레이션을 중심으로 연구가 이뤄지고 있습니다.이산사건(discrete event) 시뮬레이션은 시간이 경과함에 따라 시뮬레이션 이 진행되는 것이 아니라 시스템 외부 혹은 내부에서 사건이 발생했을 때만 모델을 실행시킵니다. 이산사건 시뮬레이션에서 사건이란 시스템의 외부 혹은 내부에서 발생하는 추상적인 신호를 말하며, 이산 사건이란 임의의 시각에 불규칙으로 일어나는 사건을 의미합니다.이산 사건 시뮬레이션 모델을 잘 만들기 위해서는 사건 시간과 사건에 대한 정확한 기술이 필요한 데, 이를 위해 프로세스 마이닝이 사용될 수 있습니다.[그림] 프로세스 마이닝 기반의 시뮬레이션 모델 도출 (Discovering Simulation Model, Rozinat et a l., 2009)이것은 기존에 시뮬레이션 모델링이 현실 세계에서의 관찰 및 수작업에 의해 이뤄졌다면, 좀 더 쉽고 정확한 모델링을 위해서는 데이터 기반의 AS-IS 프로세스 파악에 능한 프로세스 마이닝을 사용해 볼 수 있지 않을까 하는 의문에서 출발합니다.아래 표와 같이 프로세스 마이닝과 시뮬레이션은 AS-IS 모델과 TO-BE 모델 각각의 영역에서 서로 보완하는 역할을 담당하고 있습니다. [표] 프로세스 마이닝과 시뮬레이션 단계별 역할 비교단계프로세스 마이닝 (AS-IS)시뮬레이션 (TO-BE)프로세스 설계프로세스 마이닝을 통해 도출한 실제 프로세스 모델을 바탕으로 프로세스 (재)설계다양한 대안 모델에 대한 검증 수행구현 및 실행구현하고자 하는 프로세스 모델의 표준 모델 준수 여부 확인시뮬레이션을 통해 테스트 및 검증 완료된 프로세스 모델 구현모니터링 및 분석표준 모델 준수 모니터링 및 병목 지점, 재작업 구간 분석시뮬레이션을 통한 병목 개선 구간 및 자원 수요 예측, 작업 시간 효율화 효과 분석 이러한 연구들을 바탕으로 최근에는 생산 공정 내 작업 현황 파악 및 성과 측정을 위해 생산 시스템의 이벤트 로그를 저장하고 분석하여, 제조 공정에 대한 시뮬레이션 모델 요소를 도출하려는 연구가 진행되고 있습니다. 이를 통해 프로세스 마이닝에서 찾은 병목 구간 등 문제점을 바탕으로 어떻게 개선할 것인지, 프로세스 변경 혹은 개선이 어떤 결과로 이어질지 What-if 분석을 통해 의사 결정을 위한 예측 방법이 제공되고 있습니다. 시뮬레이션 수행의 결과로 많은 수행 결과가 출력되며, 좀 더 나아가 사건과 이벤트에 대한 상세 기록들이 로그 데이터 형태로 나올 수 있습니다. 시뮬레이션이 가상 현실이라는 관점에서 현실에 대한 프로세스 마이닝 분석은 가상 현실에 대해 마찬가지로 유효합니다. 실제로 시뮬레이션 모델링을 하고 나서 시뮬레이션 모델링이 현실을 반영할 수 있도록 잘 되었는지 검증할 필요가 있는데, 시뮬레이션 로그에 대한 프로세스 마이닝 분석을 통해 해당 프로세스 모델을 도출할 수 있습니다.  얻어진 모델을 현실 세계에서 얻어진 프로세스 모델과 동일한 기준에서 비교하고 이에 대한 차이를 다시 시뮬레이션 모델이 반영하는 순환적 구조를 통해 좀 더 정확한 시뮬레이션 모델을 얻게 됩니다.  [참고 문헌]https://en.wikipedia.org/wiki/Simulation#퍼즐데이터 #개발팀 #개발자 #개발후기 #인사이트

기업문화 엿볼 때, 더팀스

로그인

/