스토리 홈

인터뷰

피드

뉴스

조회수 2848

웹 플러그인 개발기 - iframe의 재발견

채널 웹 플러그인을 개발하며 겪은 문제들과 우리 팀의 해결책을 소개합니다. 채널 웹 플러그인은 SDK의 형태로 고객사 웹사이트에 붙어서 고객이 매니저와 대화할 수 있는 인터페이스를 제공합니다. 이 글을 쓰고 있는 당시 약 2300개의 채널이 개설되었고, 하루 약 180만 명의 일반 유저가 웹사이트에 붙은 저희 플러그인을 보고 있습니다.플러그인은 고객사 웹사이트 (이하 호스트 웹사이트라고 함) 의 HTML 도큐멘트에 붙어서 실행됩니다. 이 말은 실행 환경 (자바스크립트, CSS, DOM 환경 등) 을 우리가 컨트롤하지 못한다는 것을 의미합니다. 이것이 일반적인 웹서비스와 플러그인 개발의 가장 큰 차이점이고 사실상 많은 이슈들은 이 차이로부터 기인합니다. 또 이것에 대응하기 위해 프레임워크의 선택부터 개발, 배포에 이르기까지 훨씬 신경 써야할 부분이 많았습니다. 이 글에서는 그 중 호스트 웹사이트와의 실행 환경 공유에 따른 문제들을 자바스크립트와 CSS로 나누어 나열하고 iframe 을 이용하여 해결한 과정에 대해 설명하겠습니다.채널 홈페이지에 웹 플러그인이 붙은 모습1. 자바스크립트와 관련된 이슈1-1. 네임스페이스 공유에 따른 충돌 문제브라우저에서 자바스크립트는 글로벌 네임스페이스를 공유합니다. 이 속성 때문에 플러그인에서 window 를 접근해서 수정한다던가 글로벌로 객체를 정의해서 사용하면 호스트 웹사이트에 영향을 미칠 수 있습니다. 이 문제는 코딩할 때 아래 항목을 주의하는 정도로 큰 비용 없이 방지할 수 있습니다.플러그인의 최상위 네임스페이스를 만든다.(ex. window.CHPlugin)플러그인에서 사용하는 모든 객체는 최상위 네임스페이스 아래에 정의되도록 한다.(ex. window.CHPlugin.outObject)window 객체에 접근할 때는 수정하거나 추가하는 부분이 없도록 주의한다.(ex. [removed] = function(){}와 같은 코드는 사용하면 안 됨. 기존에 [removed] 이벤트가 날아감)사용하는 라이브러리들 중에 window에 바인딩하는 것이 없는지 체크하고 있으면 직접 수정하여 모듈화한다. (ex. lodash는 기본적으로 window 에 _ 객체를 생성함)이건 사실 플러그인이 아니더라도 주의해야하는 거죠..1-2. 에러로 인한 오동작 가능성더 어려운 문제는 바로 예측하기 어려운 오동작의 가능성이 있다는 것입니다. 호스트 웹사이트에서 동작하는 자바스크립트에서 에러가 날 경우 플러그인의 동작에도 영향을 미칠 수 있으며, 반대로 플러그인에서 에러가 발생해서 호스트 웹사이트의 코드 실행을 멈출 수 있다는 것입니다. 양방향으로 영향을 미칠 수 있는 것이죠. 특히 후자의 경우는 우리의 실수로 고객사의 서비스에 피해를 끼칠 수 있으니 쉽게 넘길 문제는 아닙니다.아이디어 1: try/catch를 적절히 처리한다?이를 해결하기 위해 가장 쉽게 생각할 수 있는 방법으로는 호스트 웹사이트 쪽에서 try/catch를 적절하게 처리하도록 가이드를 하는 방법입니다. 예를 들어 플러그인 코드의 바깥 쪽에 try/catch처리를 하고 호스트 웹사이트의 자바스크립트에도 적당하게 처리를 하면 되지만 이 방법은 현실적으로 어려움이 있습니다. 우리의 타겟 고객사들은 일반 쇼핑몰들이고 이들은 대부분 개발자가 없거나 쇼핑몰 빌더를 이용해 만들어진 사이트들이기 때문에 개발력이 없는 경우가 많습니다. 또 설사 개발력이 있다 하더라도 플러그인을 붙이기 위해 가이드할 것이 너무 늘어나는 문제가 있죠.아이디어 2: 자바스크립트 실행 순서를 강제한다?생각해볼 수 있는 또 다른 방법은 호스트 웹사이트의 코드와 플러그인 코드의 실행 순서를 명확히 정해서 한 방향의 영향이라도 차단하는 것입니다. 예를 들어 플러그인 코드가 호스트 웹사이트의 코드보다 항상 먼저 실행되도록 고객사에게 가이드한다면 우리의 코드는 항상 문제 없이 실행될 것이고 호스트 웹사이트에서 에러가 발생하더라도 영향을 받지 않을 것입니다. 하지만 이 방법 역시 마음에 들지 않았는데요 양방향의 영향을 모두 차단하지는 못하기 때문입니다. 그리고 더욱 큰 문제는 플러그인은 한 번 실행되고 끝나는 단순한 스크립트가 아니라 계속해서 실행이 되는 애플리케이션이기 때문에 사실상 소용이 없습니다.2. CSS와 관련된 이슈채널 웹 플러그인은 UI도 포함합니다. 플러그인의 DOM이 호스트 웹사이트에 붙어있기 때문에 플러그인의 스타일을 정의하는 CSS도 호스트 웹사이트에 Inject 되어야합니다. 호스트 웹사이트의 CSS와 플러그인의 CSS가 같은 스코프에 존재하기 때문에 우리가 의도한 스타일이 제대로 표현되지 않을 가능성이 있습니다. 실제로 이 문제는 런칭 초기에 우리를 가장 괴롭혔던 문제입니다. 쉽게 생각해볼 수 있는 방법은 아래와 같습니다.플러그인의 CSS에 네임스페이스를 둔다.(플러그인 CSS가 호스트 웹사이트 CSS에 주는 영향을 차단함)CSS 의 우선순위를 이해하고 플러그인 CSS의 우선순위가 항상 높도록 처리한다. (CSS Specificity 링크 참조)하지만 위처럼 처리하더라도 모든 경우에 대해 해결이 되는 것은 아닙니다. 주된 이유는 우리가 개발을 할 때 모든 CSS 속성을 정의하지 않기 때문입니다. 플러그인에서 정의하지 않은 속성을 호스트 웹사이트에서 사용한다면 호스트 웹사이트의 스타일이 적용될 것입니다. 또 특수한 경우이긴 하지만 만약 호스트 웹사이트에 !important 가 적용되어 있다면 그 속성이 덮어씌워지게 됩니다.!important는 사용하지 맙시다..ㅜ아이디어: 스타일 Normalizing?여기에서 의미하는 Normalizing은 모든 DOM 엘리먼트에 가능한 모든 CSS 속성의 기본값을 정의하는 것을 의미합니다. 크로미움을 기준으로 모든 CSS 속성 목록은 이 곳을 참조하시면 됩니다. 이것을 바탕으로 normalize.css를 만들어 적용했습니다.이 방법을 적용한 이후로는 스타일이 오버라이딩되는 문제는 어느 정도 해결되었습니다. 물론 !important에 대한 대응은 여전히 되지 않지만요. 그런데 예상하지 못한 부작용이 발생했는데 첫번째는 디버깅할 때 크롬 인스펙터가 도저히 사용하지 못할 정도로 느리다는 것입니다. 두번째는 CSS가 inheritance 가 안 되고 기본 엘리먼트 셀렉터의 우선순위가 높아서 직접 코딩해야하는 CSS가 2~3배는 길어지는 불편함입니다. 위 두 이유로 개발 피로도가 상당히 높아져서 머지 않아 다른 방법을 알아보게 되었습니다.3. iframe 도입위에 나열한 문제들을 해결할 수 있는 아이디어로 iframe을 리서치하게 되었습니다. 사실 iframe은 최근 웹서비스에서는 잘 사용하지 않기도 하고, 보통은 사용하지 않는 것을 권장하기도 하죠. 따라서 저희 팀에서도 처음에는 고려사항이 아니었는데요 우리와 유사하게 채팅 인터페이스를 제공하는 인터콤에서 iframe 을 적용한 것으로부터 아이디어를 얻어왔습니다.원래 목적에 맞게 사용하지 않으면 독이 됩니다.iframe은 HTML 도큐멘트 안에서 또 다른 도큐멘트를 임베드합니다. iframe 내에 있는 도큐멘트는 호스트 도큐멘트와 자바스크립트 스코프가 분리되어 있고, CSS가 적용되는 스코프 역시 분리되어 있습니다.이런 속성 때문에 위에 나열한 문제들을 원천 차단할 수 있습니다. 자바스크립트 스코프가 분리되어 있기 때문에 글로벌 네임스페이스에 접근해도 호스트 웹사이트에는 전혀 영향이 없고, 자바스크립트의 에러로 인해 다른 쪽 자바스크립트까지 실행을 멈추는 오동작을 막을 수 있습니다. CSS 역시 Normalizing 을 하지 않더라도 호스트 웹사이트와 플러그인은 완벽히 분리가 됩니다.4. iframe 의 단점iframe을 도입하여 1, 2번에 나열한 문제들은 해결했지만 그에 따른 작은 문제들도 발생했습니다. 첫번째는 iframe도입 시 가장 먼저 고민해야할 부분인데 바로 3rd-party cookie 문제입니다. iframe 안에서 로드되는 도큐멘트는 3rd-party 컨텐츠로 인식합니다. IE에서는 기본 설정이 3rd-party cookie 허용을 하지 않기 때문에 쿠키를 사용해서 인증을 구현한 경우 문제가 될 수 있습니다.두번째는 도큐멘트가 분리됨에 따라 발생하는 코딩상의 여러 불편함들입니다. 여기에서는 범위를 벗어나 더 자세하게는 설명하지 않겠지만 도큐멘트가 분리되니 조금 더 신경써야할 것들이 있었습니다.저희 팀의 경우 쿠키 인증 방식이 아닌 토큰 형태의 인증도 지원을 하고 있었기 때문에 첫번째는 크게 문제되지 않았고 두번째 문제도 얻는 이득에 비하면 불편함을 감수하는 편이 훨씬 좋다는 판단이 들어서 도입을 결정했습니다.마무리플러그인 개발을 시작할 당시에 우리 팀은 웹 SDK 형태의 프로젝트 개발 경험이 없었습니다. 리서치를 해도 플러그인 개발과 관련된 아티클이나 리소스 그리고 보일러플레이트 프로젝트도 많지 않았습니다. 프레임워크, 아키텍쳐를 선택하는 것부터 프로젝트를 구성하는 것부터 개발, 배포 및 운영에 이르기까지 일반적인 웹서비스를 개발할 때와 조금 다른 고민들을 해왔던 것 같습니다. 앞으로 저희가 해 온 고민을 공유하려고 합니다. 저희와 같은 플러그인, SDK 형태의 제품을 개발하고 계신 분들에게 도움이 되었으면 좋겠습니다.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1657

"코인원 중심에서 '보안'을 외치다." - 보안전략기획팀 정지원

‘보안팀'을 생각했을 때 어떤 단어들이 떠오르시나요? 조금은 무시무시하지만 우람한 팔뚝, 강력한 눈빛, 태평양같은 어깨를 소유한 영화배우 ‘마요미' 마동석님이 떠오르네요. 코인원에서도 무시무시한 매의 눈으로 코인원 크루가 자리를 비울때 화면잠금이 되었는지 확인하는 ‘정요미'가 있습니다. 바로 코인원 보안을 책임지는 보안전략기획팀의 지원님이에요. 코인원 크루의 보안뿐만 아니라 고객들의 소중한 자산을 지키는 코인원의 수문장, 지원님을 만나볼까요?Q. 안녕하세요, 코인원의 ‘프로 화면잠금러'를 만나뵙게되어 정말 영광입니다.네, 저 또한 영광입니다. 제가 이전에 자리를 잠깐 비울때 화면잠금을 하지 않았는데요, 이렇게 영혼까지 털릴줄 몰랐습니다. ‘화면잠금도 모르면서 보안을 어떻게 논하느냐’ 라고들 하셔서 사죄의 의미로 커피를 쏘게 되었습니다. 이후 다시 이런 일이 없도록 스스로에게 다짐했을 뿐만 아니라 화면잠금 안하신 크루가 있는지 없는지 열심히 찾고 있습니다. (걸리기만 해 아주…-_-)Q. ‘프로 화면잠금러’로 오해하실 수도 있는 독자분들을 위해 ‘진짜’ 지원님 소개 부탁드릴게요:)안녕하세요, 코인원 보안본부 내 보안전략기획팀에서 근무하고 있는 정지원입니다. 코인원의 보안본부는 대내외 각종 보안 위협으로부터 선제적으로 대응할 수 있도록 Action Plan을 수립하고 실행하여 코인원의 모든 서비스와 자산을 보호하는 역할을 하고 있어요. 크게 보안전략기획팀, 개인정보보호팀, 보안운영팀으로 나뉘어 집니다.이 중에서 보안전략기획팀은 주로 대/내외 보안 트렌드를 파악하며 거래소 보안전략을 수립하고, 우선순위를 설정하고 조정하여 실행하고 있습니다. 더불어 코인원의 기존 서비스와 앞으로 출시될 신규 서비스의 보안 위험을 식별할 수 있도록 분석하고 대응방안을 마련하죠. 철저한 보안으로 코인원이 고객들에게 신뢰받을 수 있는 거래소가 되기 위해 최선을 다하고 있습니다.Q. 코인원을 이용하는 고객분들이라면 정말 궁금할 것 같아요. 코인원에 보관되어 있는 제 자산, 정말 안전하게 보관되어 있나요?“코인원 고객들의 자산은 100% 안전합니다" 라는 말 대신 “코인원 보안팀은 단 1%의 취약점도 허용하지 않기 위해 정말 최선을 다하고 있습니다" 라고 말씀드리고 싶어요.개인적으로 “고객의 자산은 100% 안전합니다.” 또는 “100% 완벽한 보안” 이라는 말은 성립할 수 없다고 생각해요. 취약점이 발생할 가능성은 언제나 있다고 생각하고, 그것이 1%의 가능성이라고 할지라도 해결방안을 고민해서 현실적인 대책을 세우고 실행해나가야 한다고 생각합니다.현재 코인원에서는 *DID(Defense In-Depth)의 개념으로 계층화된 보안 시스템(Multi-Layered Security)을 구축하고 발생할 수 있는 보안 위협에 대비합니다. 성을 공략하는 게임을 예를 들어 볼게요. A라는 성은 10m의 성벽 1개가 있고 B라는 성은 1m의 성벽 10개가 있다고 가정할께요. 성벽을 우회해서 성에 도착하기까지 어디가 시간이 더 걸릴까요?코인원은 마치 여러 개의 성벽처럼 계층화된 보안 방안을 구현, 거래소에 적용하고 있어요. 적용했다고 끝난게 아닙니다. 계속해서 모니터링 하면서 좋은 점과 나쁜 점을 모아놓고 좋은 점은 더 좋게, 나쁜 점은 개선할 수 있도록 재기획하고 실행합니다. 보다 더 안전하게 고객의 자산을 보호할 수 있는 방법을 고민하고 적용하고 있어요. *여기서 잠깐 DID(Defense In-Depth, 심층방어)란? 여러 계층의 보안 제어가 정보 기술(IT) 시스템 전반에 걸쳐 배치되는 정보 보증 개념입니다. 보안 제어가 실패하거나 시스템의 수명주기 동안 인력, 절차적, 기술적 및 물리적 보안 측면을 포괄 할 수있는 취약점이 악용되는 경우를 대비하여 다수의 방어 중복성을 제공하기 위한 것입니다.Q. 현재 코인원에서 진행하고 있는 보안정책은 어떤것들이 있을까요? 간단하게 소개해주세요.코인원 보안정책 중 몇가지를 소개해 드리자면, 코인원은 콜드월렛 보관 비중을 85%로 유지하여 고객자산을 보다 안전하게 보호하려고 노력하고 있습니다. 이는 사단법인 한국블록체인협회 권고 사항인 70% 보다 높은 비중이죠.또한 IT전문 보안 기업 SK infosec의 체계적인 보안관제 서비스를 제공받고 있습니다. 사이버 침해 위협을 실시간으로 감시하고 SK infosec이 보유한 방대한 위험 정보 데이터 베이스에 기반하여 고도화된 위협에 대응하고 있습니다. 마지막으로 이번에 새로 사이버 보안 기업 티오리(THEORI)의 전문적인 보안 컨설팅을 받게 되었습니다. 티오리는 미국 오스틴에 본사를 둔 기업으로 카네기멜론대학 해커팀(PPP) 핵심 멤버들이 설립한 사이버 보안 R&D 기업인데요, 데프콘(DEFCON) 같은 유명한 국제해킹방어대회에서 항상 상위권에 랭크되고는 합니다. 이렇게 검증된 역량을 바탕으로 Pen-Test(모의해킹)을 통해 코인원의 보안 아키텍쳐를 점검하고, 발생 가능한 모든 침해 시나리오를 상정하여 이에 대비하기 위한 자문을 진행할거에요.이외 다수의 테크니컬한 부분은 영업비밀(?) 입니다. (와하하하)Q. 콜드월렛을 잘 모르실 수도 있는 독자분들을 위해서 자세한 설명 부탁드려요. 또한 85%까지 비중을 유지하는것이 왜 중요한가요?먼저 콜드월렛에 대한 설명을 드릴게요. 콜드월렛은 핫월렛과 달리 네트워크가 연결되지 않은 물리적으로 분리된 저장 공간을 말합니다. 콜드월렛에 보관한다는 의미는 고객의 암호화폐 자산을 침해 또는 해킹 위협으로부터 원천적으로 차단된 별도의 장소에 보관한다는 뜻입니다. 그런일이 있어서는 안되겠지만, 사이버 침해가 발생한다고 가정할 경우 고객의 피해를 최소화할 수 있는 안전 장치에요. 블록체인 협회에서는 70%이상을 콜드월렛에 보관하는 것을 권고하고 있는데요. 저희는 협회에서 권고하기 이전부터 자체적으로 월렛 관리 정책을 만들고 그에 따라 콜드월렛을 운영해왔습니다. 참고로, 85%로 유지하는 이유는 거래소 비즈니스적으로 병목현상이 일어날 수 있는 부분을 방지하기 위한 적정 수준이라고 답할 수 있겠네요.보안팀은 무시무시하지 않아요, 부드럽습니다! (그윽한 눈빛을 발사하는 지원님)Q. 거래소 보안 전문가로서 막중한 책임감을 갖고 계실 것 같아요. 코인원 입사 후에 가장 기억에 남았던 혹은 어려움을 겪었던 에피소드가 있을까요?코인원의 보안 수준을 어떻게 하면 제1금융권 수준까지 끌어올릴 수 있을까에 대한 고민이 매우 컸습니다. 블록체인과 암호화폐 업계가 굉장히 폭발적으로 성장해왔는데요. 폭발적으로 성장하는 속도를 따라잡을 수 있도록 보안 및 인프라팀에서 무수한 노력을 해왔어요. 짧은 시간내에 보안 인프라를 효율적으로 구축할 수 있을지 치열하게 진행했던 회의들이 생각나네요. 코인원의 많은 크루들이 노력해주시고 도와주신 덕분인지 현재까지 코인원에서는 단 한건의 해킹사고도 발생하지 않았습니다. 최근에 생각나는건 금번 NH농협은행과의 재계약에서 보안 요구사항과 점검에 대한 실사가 많았는데 다행이 보안요건을 충족하며 재계약한 것이 생각나네요.Q. 지원님은 앞으로 보안본부에서 어떤 꿈을 이뤄나가고 싶으세요?글로벌 회사를 보면 유명한 보안팀들이 있어요. 예를 들어 구글에는 ‘프로젝트 제로(Project Zero)’라는 팀이 있는데, 이 팀은 ‘제로데이(0-day)’ 공격을 대비하기 위한 팀이에요. 제로데이 공격은 알려지지 않은 취약점을 발견해서 이에 대처하기 전 무방비 상태인 점을 악용하는 사이버 공격 방법이에요. 프로젝트 제로는 제로데이 공격 위협을 사전에 해소하기 위해 자사 제품 뿐만 아니라 타사 제품까지 연구하고 취약점이 발견된다면 해당 회사에 전달해서 대처할 수 있게 합니다. 또 다른 예로 야후에 “패러노이즈(Paranoids)”를 들 수 있겠네요. 야후의 모든 제품은 패러노이즈의 승인 없이는 론칭되지 않습니다. 전문성이 뛰어나지 않다면 가능하지 않은 케이스죠.저는 보안을 위해서라면 편집증적인 집착도 용서가 된다고 생각하는데요, 암호화폐 거래소 뿐만 아니라 블록체인 전반적인 영역에 대해 전문성을 발전시켜 궁극의 편집증 환자가 되는게...(?) 아 이게 아니고, 글로벌 유수의 보안팀들과 어깨와 나란히 하고 싶습니다.Q. 마지막으로 묻겠습니다. 지원님에게 ‘화면잠금' 이란?(인터뷰에서까지 영혼이 털리네요...) 회사 메신저에 제 프로필을 보시면 “화면잠금 털린 보안어린이”라고 되어 있습니다. 슬프네요 흑. 농담이구요, 어떤 일이던지 기본부터 충실해야 한다는 초심을 찾을 수 있었던 계기도 되었고 또 의도하지 않았지만 코인원 크루들이 보안은 어려운게 아니구나 라는 인식으로 바뀌게 된 계기가 된 것 같습니다. 수많은 보안 캠페인을 기획하고 시행했지만 지금처럼 크루들에게 여운이 남아있던 적이 없던 것 같아요. 앞으로 쉽지만 누구나 할 수 있는 보안 캠페인을 고민해 볼께요. (좋은 아이디어 주시면 제가 커피를 쏩니다!)충성! 단결! 필승! 오늘도 보안은 안전합니다 :-)언제나 보안을 최우선으로 고려하고, 원칙을 지키며 건전한 암호화폐 시장을 만들기 위해 지원님은 오늘도 24시간 365일 보안에 대한 고민을 풀가동하고 있습니다. 코인원을 이용하는 고객들의 안전한 거래를 위해 끊임없이 노력하는 보안전략기획팀에 많은 응원 부탁드립니다!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트 #기업문화 #조직문화 #팀원소개 #인터뷰
조회수 3155

eventlet을 활용한 비동기 I/O 프로그래밍

안녕하세요. 스포카 크리에이터팀 문성원입니다. 현대적인 프로그래밍 환경에서 네트워크는 더는 특정 직군의 개발자만 접하는 분야가 아닙니다. 그런 만큼 대량의 요청을 네트워크를 통해 송수신하는 프로그램이 생각보다 성능이 나오지 않는 경우를 경험하신 분들도 많으실 겁니다. 물론 스포카 개발팀도 예외는 아니었습니다. 그래서 오늘은 저희의 이러한 경험과 그 해결책-eventlet을 통한 비동기 I/O(Asynchronous I/O)-에 대해 소개합니다.Why우선 스포카 개발팀에서 겪었던 문제부터 시작하죠. 얼마 전 페이스북(facebook)의 FQL(Facebook Query Language)를 통해 정보를 수집해서 이를 활용하는 기능을 작성해야 했습니다. 기존의 함수들은 필요할 때마다 FQL을 요청하는 방식이었고 당연히 이건 너무 느렸죠. 그래서 생각한 것이 “하루의 일정 시간마다 대량의 FQL 요청을 보내서 필요한 정보를 미리 갱신시켜놓자.”였습니다. 여기까진 좋았죠. 이때 제가 작성한 코드의 얼개를 살펴보면 대강 이렇습니다.# 페이스북 계정들을 가져와서 반복하면서for account in FacebookAccount.query:    account.update() #FQL을 보내자.view rawgistfile1.py hosted with ❤ by GitHub그런데 문제가 있었습니다. 기존의 FQL을 보내는 FacebookAccount.update()는 FQL요청이 완료될때까지 멈추고 기다립니다. 대부분의 FQL요청이 2, 3초 정도 걸린다고 했을 때 이러한 지연은 매우 치명적입니다. 대안이 필요했고 자연스레 떠오른 것이 서두에 소개한 비동기 I/O(Asynchronous I/O)였습니다.Asynchronous과거 일부 고급 서버 개발자만 알고 있는(혹은 알아야 하는) 기술로 치부되던 ‘비동기(Asynchronous)’란 개념은 2000년대 들어 등장한 Ajax(Asynchronous JavaScript and XML)의 성공 이후 많은 개발자에게 강한 인상을 줬습니다. 사용자는 HTTP 요청이 끝날 때까지 멈추어 있는 하얀 화면으로부터 해방되었고, 다양하고 많은 요청과 응답들이 자연스럽게 서버로 흘러들어 가서 나왔습니다. 개발자들의 이러한 경험과 통찰은 이후 node.js와 같은 플랫폼의 등장에도 많은 영향을 끼쳤습니다.다시 문제로 돌아가죠. 그렇다면 이러한 비동기에 관한 개념은 위의 상황을 어떻게 해결할 수 있을까요? 문제의 원인부터 다시 살펴봅시다. 2, 3초 정도씩 걸리는 FQL 요청이 문제일까요? 물론 요청이 매우 빨리 처리된다면 별도의 처리 없이도 저 코드는 문제없이 동작합니다. 하지만 현실적으로 이런 I/O의 속도를 빠르게 하는데에는 물리적으로 한계가 있습니다. 오히려 여기에서 주목해야 할 점은 ‘2, 3초’ 보다 ‘기다린다’라는 점입니다. FacebookAccount.update() 같은 경우, I/O가 처리되는 동안 CPU는 하던 일을 멈추고 문자 그대로 기다리게 됩니다. 만약 CPU가 멈추지 않고 다른 요청을 보낸다면 어떨까요? 이렇게 말이죠.비동기만으로는 부족하다?이러한 아이디어는 그동안 많은 개발자가 대량의 I/O를 다루는 올바른 방식으로 여겨왔습니다. 하지만 보통 이러한 비동기 I/O를 통한 구현은 동기식 I/O와는 좀 다른 형태를 띠게 됩니다. 이렇게 말이죠.# http://docs.python.org/library/asyncore.html#asyncore-example-basic-http-clientimport asyncore, socketclass HTTPClient(asyncore.dispatcher):    def __init__(self, host, path):        asyncore.dispatcher.__init__(self)        self.create_socket(socket.AF_INET, socket.SOCK_STREAM)        self.connect( (host, 80) )        self.buffer = 'GET %s HTTP/1.0\r\n\r\n' % path    def handle_connect(self):        pass    def handle_close(self):        self.close()    def handle_read(self):        print self.recv(8192)    def writable(self):        return (len(self.buffer) > 0)    def handle_write(self):        sent = self.send(self.buffer)        self.buffer = self.buffer[sent:]client = HTTPClient('www.python.org', '/')asyncore.loop()view rawgistfile1.py hosted with ❤ by GitHub불행하게도, 이 경우 기존에 사용하던 urllib2대신 HTTP 요청을 처리하는 핸들러를 이처럼 재작성 해야합니다. 거기에 FacebookAccount.update()의 호출 방식마저 바뀔 수 있죠. 더군다나 콜백(Callback) 투성이의 코드는 유지보수가 쉬어 보이지도 않습니다. 여러모로 손이 많이 가는 상황이죠.결국, 기존 코드를 최대한 수정하지 않으면서도, 어느 정도 성능은 보장되는 그런 해결책이 필요했습니다. 그런 해결책이 있을까요? 다행히도 그렇습니다.What저희가 해결책으로 택한 eventlet은 Python(정확히는 CPython)에서 코루틴(Coroutine)을 지원하기 위해 만들어진 greenlet을 이용해 작성된 네트워크 관련 라이브러리입니다. 생소한 용어가 갑자기 튀어나와서 놀라셨을지도 모르니 우선 eventlet에 대해 설명하기 전에 앞에 나온 용어들을 찬찬히 한번 살펴보죠.코루틴과 greenlet먼저 코루틴(Coroutine)부터 살펴보죠. 전산학도라면 누구나 그 이름을 한번은 들어봤을 도널드 카누쓰(Donald Knuth)는 자신의 저서 The Art of Computer Programming에서 코루틴을 다음과 같이 설명합니다.Subroutines are special cases of more general program components, called “coroutines.” In contrast to the unsymmetric relationship between a main routine and a subroutine, there is complete symmetry between coroutines, which call on each other.코루틴은 우리가 잘 알고 있는 서브루틴(Subroutine)과 달리 진입점(Entry Point)이 여러 개일 수 있습니다. 쉽게 이야기하면 실행을 멈췄다가(Suspend) 재개(Resume)할 수 있다는 점인데요. 이 특성을 살리면 우리가 익히 아는 스레드(Thread)처럼 쓸 수 있게 됩니다. 다만 스레드와 달리 코루틴은 비선점적(Non-Preemptive)이기때문에 코드의 흐름을 전적으로 사용자가 제어할 수 있습니다.하지만 불행히도 모든 언어에서 이런 코루틴이 지원되진 않습니다. greenlet은 이런 코루틴을 CPython에서 지원하기 위해 작성된 라이브러리입니다.eventlet코루틴을 통해 스레드를 대체할 수 있다는 점에 주목한 사람들은 greenlet을 통해 유용한 네트워크 라이브러리를 만들어냈습니다. eventlet도 그 중 하나죠. 잠시 eventlet의 소갯글을 봅시다.Eventlet is a concurrent networking library for Python that allows you to change how you run your code, not how you write it.위에서 볼 수 있듯이 eventlet은 사용성에 중점을 두었습니다. 기존의 블로킹 I/O 스타일의 프로그래밍에 익숙한 개발자들도 쉽게 비동기 I/O의 장점을 얻을 수 있게끔 하는 게 목적이죠.특히 저희가 주목한 점은 eventlet의 멍키패치 기능입니다. 멍키패치는 본래 동적 언어에서 런타임에 코드를 고쳐서 별도의 파일 변경 없이 본래 소스의 기능을 변경하는 것을 말합니다. eventlet은 eventlet.monkey_patch 메서드를 통해 표준 라이브러리의 I/O 라이브러리를 논블러킹으로 동작하게끔 변경해서 코루틴에 적합하게 만듭니다.How앞서 소개한 eventlet.monkey_patch를 이용하면 실제로 고칠 부분은 정말로 적어집니다. 다음 코드가 eventlet을 이용해 변경한 전부입니다.import eventleteventlet.monkey_patch() #표준 라이브러리를 변환# 여러가지 import를 하고...pool = eventlet.GreenPool()# 페이스북 계정들을 가져와서 반복하면서for account in FacebookAccount.query:    # 코루틴들에게 떠넘기자.    pool.spawn_n(FacebookAccount.update, account)        pool.waitall()view rawgistfile1.py hosted with ❤ by GitHub정말 적죠? 조금만 구체적으로 살펴보죠. 우선 eventlet.monkey_patch는 socket이나 select등의 Python 표준 라이브러리를 eventlet.green 패키지안에 정의된 코루틴 친화적인 모듈들로 바꿔치기 합니다.# from eventlet/pathcer.pydef monkey_patch(**on):    """Globally patches certain system modules to be greenthread-friendly.    The keyword arguments afford some control over which modules are patched.    If no keyword arguments are supplied, all possible modules are patched.    If keywords are set to True, only the specified modules are patched.  E.g.,    ``monkey_patch(socket=True, select=True)`` patches only the select and     socket modules.  Most arguments patch the single module of the same name     (os, time, select).  The exceptions are socket, which also patches the ssl     module if present; and thread, which patches thread, threading, and Queue.    It's safe to call monkey_patch multiple times.    """        accepted_args = set(('os', 'select', 'socket',                          'thread', 'time', 'psycopg', 'MySQLdb'))    default_on = on.pop("all",None)    for k in on.iterkeys():        if k not in accepted_args:            raise TypeError("monkey_patch() got an unexpected "\                                "keyword argument %r" % k)    if default_on is None:        default_on = not (True in on.values())    for modname in accepted_args:        if modname == 'MySQLdb':            # MySQLdb is only on when explicitly patched for the moment            on.setdefault(modname, False)        on.setdefault(modname, default_on)            modules_to_patch = []    patched_thread = False    if on['os'] and not already_patched.get('os'):        modules_to_patch += _green_os_modules()        already_patched['os'] = True    if on['select'] and not already_patched.get('select'):        modules_to_patch += _green_select_modules()        already_patched['select'] = True    if on['socket'] and not already_patched.get('socket'):        modules_to_patch += _green_socket_modules()        already_patched['socket'] = True    if on['thread'] and not already_patched.get('thread'):        patched_thread = True        modules_to_patch += _green_thread_modules()        already_patched['thread'] = True    if on['time'] and not already_patched.get('time'):        modules_to_patch += _green_time_modules()        already_patched['time'] = True    if on.get('MySQLdb') and not already_patched.get('MySQLdb'):        modules_to_patch += _green_MySQLdb()        already_patched['MySQLdb'] = True    if on['psycopg'] and not already_patched.get('psycopg'):        try:            from eventlet.support import psycopg2_patcher            psycopg2_patcher.make_psycopg_green()            already_patched['psycopg'] = True        except ImportError:            # note that if we get an importerror from trying to            # monkeypatch psycopg, we will continually retry it            # whenever monkey_patch is called; this should not be a            # performance problem but it allows is_monkey_patched to            # tell us whether or not we succeeded            pass    imp.acquire_lock()    try:        for name, mod in modules_to_patch:            orig_mod = sys.modules.get(name)            if orig_mod is None:                orig_mod = __import__(name)            for attr_name in mod.__patched__:                patched_attr = getattr(mod, attr_name, None)                if patched_attr is not None:                    setattr(orig_mod, attr_name, patched_attr)        # hacks ahead; this is necessary to prevent a KeyError on program exit        if patched_thread:            _patch_main_thread(sys.modules['threading'])    finally:        imp.release_lock()view rawgistfile1.py hosted with ❤ by GitHub이렇게 바꿔치기된 eventlet.green안의 모듈들은 I/O에 의해 블럭되는 경우 다른 코루틴에 제어권을 넘기는 식으로 지연을 방지합니다.다른 대안들사실 이러한 목적으로 사용되는 라이브러리는 eventlet만 있는 것은 아닙니다. gevent는 eventlet에서 영향을 받았지만, libevent를 기반으로 하여 더욱 나은 성능과 성숙한 인터페이스를 갖추고 있습니다. 저희처럼 libevent의 설치에 제한이 있는 환경이 아니라면 이쪽을 살펴보셔도 좋습니다.만약 이벤트 주도적 프로그래밍(Event-Driven Programming)에 흥미가 있으신 분은 Twisted역시 좋은 대안이 될 수 있습니다.#스포카 #개발 #개발자 #인사이트 #꿀팁
조회수 12599

Jekyll을 이용하여 github에 블로그 만들기

티스토리에서 여러 불편함들을 느껴 깃헙 블로그로 갈아타려고 한다. 자유도가 높아보여 티스토리에 블로그를 개설했으나 오히려 글이 노출되는 디자인이나 (줄간격, 글씨 크기 등등) 기존 테마를 변경하기에 불편했다. 결정적으로 gist 스크립트를 삽입했을 때 미리보기가 안돼서 고민 끝에 깃헙 블로그를 선택했다. 워드프레스도 개설해봤지만 왠지 모르게 마음에 안들어서 깃헙 블로그로 갈아타기로 마음먹었다. 그 후에 이것저것 알아보니 내 마음에 쏙 드는 요소들이 많았다.마음에 드는 부분git을 이용해 커밋, 푸시로 글을 포스팅함. 그 덕분에 블로그에 대한 모든게 로컬에 있고 모든 글들을 로컬에서 관리 할 수 있음.마크다운을 이용하여 글 작성. 글과 html을 마음대로 오갈 수 있어서 좋음. 마크다운 에디터가 없었다면 불편했겠지만 세상은 넓고 좋은 에디터는 많다..! 다만 이미지 삽입에서는 좀 불편.다른 웹 프로젝트처럼 웹스톰에서 블로그 관리 가능. 인텔리 제이를 사랑하는 나로서는 이 부분 또한 큰 장점.아무튼 이런 이유로 깃헙 블로그로 갈아타기로 결정. 구글링을 통해서 깃헙 블로그를 개설하는 방법에 대해 잘 정리해놓은 블로그를 찾았다. 놀부 블로그를 참고하여 깃헙 블로그를 개설했다. 아래에는 내가 보기 편하도록 더 간략하게 정리해보았다.깃헙 블로그 만들기 (Mac OS X)1. Jekyll 설치터미널에서 아래 명령어 입력으로 설치. $ sudo gem install jekyll2. 설치한 Jekyll을 이용하여 블로그 생성블로그를 만들고자 하는 위치에서 아래 명령어로 생성.$ jekyll new [github사용자명].github.com블로그 생성후 생성된 위치로 이동하여 아래의 명령어 실행 후 브라우저에서 http://localhost:4000으로 접속하면 로컬에 생성된 블로그를 볼 수 있음.$ jekyll serve --watch3. github에 온라인 저장소 만들기위에서 생성한 블로그 이름과 동일한 이름([github사용자명].github.com)으로 github에 온라인 저장소를 생성. 그 후 로컬에 있는 블로그와 만들어준 저장소를 remote 해주면 끝.$ git init$ git remote add origin [저장소URL]$ git add .$ git commit -m "Initialize Blog"$ git push origin master생성된 블로그는 http://[github사용자명].github.com으로 접속하면 볼 수 있다. 처음 생성하는 경우 몇 분의 시간이 걸리는 경우도 있다고 함.포스팅하기글은 _post 파일 안에 YYYY-MM-DD-[글 제목].markdown 형식으로 파일명을 지정하여 생성한 후 커밋, 푸시하면 업로드됨.테마 적용하기테마를 직접 만들기에는 시간이 너무 많이 소요되니 인터넷에 공유되어있는 테마를 사용하면 좋다. 테마를 적용하는 부분에서 여러모로 애를 먹었는데 제일 쉬운 방법은 테마가 올라가있는 저장소를 포크하여 [github사용자명].github.com으로 이름을 바꾸는게 제일 쉽다. 내 블로그는 심플한 테마를 적용하였다.다른 테마들은 Jekyll Themes 사이트에서 찾아볼 수 있다. 훨씬 이쁘고 좋은 테마들도 많음.Jeykll 더 알아보기Jeykll 공식 번역 사이트에서 몇 개의 문서를 읽어보면 더 다양하게 활용해 볼 수 있다. _config.yml파일이나 _post, _include, _layout 파일 정도는 기본으로 살펴보아야 함.#트레바리 #개발자 #안드로이드 #앱개발 #Jeykll #백엔드 #인사이트 #경험공유
조회수 2149

모니터링 하지 않는 DevOps 조직은 없다.

출처: https://www.pagerduty.com/blog/devops-monitoring-tools/DevOps 와 모니터링 사용자의 변화DevOps는 이제 너무나 익숙해진 용어입니다. 이미 아마존, 넷플릭스, 페이스북과 같은 우리가 사용하는 많은 서비스들이 DevOps 조직을 가지고 있으며 우리나라에서도 엔터프라이즈 IT 기업들의 운영 조직들은 DevOps로 조직이 변화해가고 있습니다. 그리고 이와 함께 모니터링 서비스에도 변화가 생기고 있습니다. DevOps 이전까지 모니터링 서비스들은 운영팀의 소유였습니다. 개발자들이 서비스를 개발하고 나면 서비스의 안정화까지 운영팀에서는 어플리케이션 성능 분석 모니터링을 위주로 사용하고 어플리케이션이 안정화 되고 나면 급박한 이상 상황에 대비하여 인프라 모니터링을 사용하게 됩니다. 이 모든것은 운영팀의 업무였습니다.  하지만 비지니스의 변화 속도가 빨라지고 서비스의 업데이트가 더이상 이벤트가 아닌 일상이 되어 가면서 기업의 운영팀은 모니터링을 통해 개발 내역을 확인하고 개발팀은 모니터링을 통해 피드백을 받아들이는 구조로 변화해 가고 있습니다. 결국 DevOps에서는 운영팀과 개발팀 모두가 모니터링에 관심을 가지게 됩니다.  DevOps ToolchainDveOps Toolchain은 PLAN - CREATE - VERIFY - PACKAGE - RELEASE - CONFGURE - MONITOR의 연속입니다. 그리고 MONITOR 는 다음번 PLAN을 위한 데이터를 제공해 줄 수 있어야 합니다. 기업이 DevOps를 구체화된 프로세스로 정립하기 위해서는 다양한 도구들을 도입해야 합니다. Toolchain의 모든 스테이지에는 개발과 운영이 의견을 나누고 자동화해나갈 수 있는 다양한 도구들이 제공 되고 있습니다. 이는 모니터링에서도 마찬가지 입니다. 출처: http://blog.launchdarkly.com/devops2/DevOps for MonitoringDevOps에서 모니터링은 인프라스트럭처에서 어플리케이션 뿐만 아니라 로깅과 비지니스까지 매우 넓은 범위를 모니터링 하게 됩니다. DevOps 팀은 인프라와 어플리케이션의 상관관계를 알 수 있어야 하며 지나간 데이터는 물론이고 현재의 데이터를 실시간으로 분석할 수 있어야 합니다. DevOps 조직에서 사용하는 모니터링은 크게 아래와 같이 나눌 수 있습니다.Infrastructure and Network Monitoring서버, 라우터, 스위치를 포함한 Infrastrucre와 Network 전반에 대한 모니터링을 제공합니다. Nagios, Zabbix 와 같은 오픈소스 기반의 솔루션이 많이 제공되고 있습니다. 해외 서비스로는 DataDog 이 유명하며 국내에서는 WhaTap 이 Infrastructure 모니터링을 제공하고 있습니다. DataDog은 대규모 서버를 한눈에 볼수 있는 벌집 구조의 데시보드로 유명합니다. Application Performance Monitoring어플리케이션  성능 모니터링은 고객의 트랜잭션을 분석하는 동적 분석 도구 입니다. 웹 서비스를 운영하는 과정에서 성능 이슈가 발생하는 경우 해당 지점을 찾는 용도로 사용됩니다. 신속한 버그 추적과 재발 방지를 위해서도 사용될 수 있으며 최소 응답시간을 지속적으로 유지하기 위한 필수 서비스입니다. 좀더 능동적으로 APM을 사용한다면 발생 빈도가 높은 메소드를 분석하여 코드 리팩토링에 사용 할 수도 있습니다. 오픈소스로는 네이버의 핀포인트 와 와탭의 CTO가 커미터로 참여하고 있는 스카우터 가 있습니다. 해외에서는 New Relic, AppDynamics 가 유명하며 국내에는  WhaTap 이 APM 서비스를 제공하고 있습니다. 와탭의 트랜잭션 분포도는 APM 서비스중 데이터 분석 간격이 가장 짧은 것으로 알려져 있습니다.Log Analysis로그 분석은 플랫폼에서 제공하는 시스템 로그를 분석하거나 커스터마이징된 로그 데이터를 분석하는 도구입니다. 로그 분석을 통해 시스템의 결함을 미리 알아낼 수도 있으며 비지니스 데이터를 분석할 수 도 있습니다. Splunk, Elastic, PaperTrail, Logstash,  Loggly,  Logentries,  SumoLogic 과 같은 벤더를 통해 서비스를 제공받을 수 있습니다. 결론DeveOps는 개발과 운영이 만들어 가는 문화이기도 하지만 많은 도구의 도움을 받아서 진행해야 하는 프로세스이기도 합니다. 모니터링 서비스는 개발과 운영이 함께 서비스를 개선할 수 있게 해주는 중요한 도구입니다. 많은 모니터링 도구들이 DevOps를 지원하고 있습니다. 다양한 모니터링 도구와 서비스를 잘 이용한다면 DevOps 조직을 더욱 탄탄하게 만들고 비지니스도 빠르게 성장시킬수 있을 것입니다. 출처: https://blog.appdynamics.com/engineering/5-challenges-for-a-successful-enterprise-devops-model/관련 글https://techbeacon.com/10-companies-killing-it-devops10 companies killing it at DevOpsTop companies have made the move to DevOps and serve as the framework for others ready to make the move. Is your company ready for a DevOps...techbeacon.com https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr10+ Deploys Per Day: Dev and Ops Cooperation at FlickrCommunications and cooperation between development and operations isn't optional, it's mandatory. Flickr takes the idea of "release early, release often" to an…www.slideshare.net https://en.wikipedia.org/wiki/DevOps_toolchainDevOps toolchain - Wikipediaen.wikipedia.org http://blog.launchdarkly.com/devops2/DevOps 2.0Decoupling feature rollout from code deployment and the rise of user-centered deploymentsblog.launchdarkly.com https://aws.amazon.com/ko/devops/what-is-devops/데브옵스란 무엇입니까? – Amazon Web Services(AWS)aws.amazon.com #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 2871

타다 클라이언트 개발기

앞서 종합 모빌리티 플랫폼인 타다의 시스템 설계를 위한 많은 고민과 기술적 결정들에 대해서 서버팀에서 소개한 바 있습니다. 이번 글에서는 타다 서비스를 출시하기까지 타다 모바일 클라이언트를 개발하는 과정에서 내린 클라이언트 팀의 전략적 결정들과, 타다 클라이언트를 개발하는데 사용한 기술들을 공유합니다.시작 전 상황3달 반의 개발 기간: 타다는 VCNC가 SOCAR에 인수되면서 개발하게 된 서비스입니다. 빠르게 시장에 뛰어들어서 선점하는 것이 무엇보다 중요했기에 시간과의 싸움은 필수적이었습니다. 프로젝트는 6월에 시작되었고 1.0 출시는 추석 연휴 직전인 9월 중순으로 결정되었습니다. VCNC에서 오프라인 운영은 처음이었기 때문에 차량을 실제로 운행해보면서 사용성 경험을 테스트할 필요가 있었습니다. 그래서 8월 초에 사내 테스트용 알파 버전을 출시하기로 했습니다.클라이언트 팀 통합: 비트윈 때는 Android/iOS 팀이 나뉘어 있었습니다. 회사 인수 과정에서 발생한 조직 개편으로 인해 타다 클라이언트 개발자는 5명으로 이루어졌습니다. 전부터 다른 OS 개발도 경험하고 싶던 적극적이고 열정적인 5명의 멤버들은 과감하게 팀을 통합해서 Android/iOS을 함께 개발하기로 했습니다.3개의 앱 개발: 타다의 서비스를 위해서는 Android/iOS, 라이더/드라이버 총 4개의 앱을 제작해야 합니다. 하지만 시간과 일정을 고려했을 때 4개의 앱을 다 제작하기는 무리라고 판단을 했습니다. iOS에서는 내비게이션 앱을 사용 중에 드라이버 앱으로 손쉽게 전환하는 기능을 제공할 수 없고 내비게이션 앱으로 경로 안내를 요청하는 것도 제한적이기 때문에 iOS 드라이버 앱은 제작하지 않기로 했습니다.무에서 시작한 프로젝트: 타다는 코드 베이스가 없는 empty repository에서 시작했습니다. 언어도 바뀌었고 레거시 코드와도 엮이고 싶지 않았기 때문에 비트윈에서 어떠한 라이브러리도 가져오지 않고 전부 새로 만들기로 했습니다.클라이언트 팀의 5명의 정예 용사들. by Sam코드 아키텍처 - RIBs프로젝트가 시작되고 기획이 진행되는 동안 3주의 시간을 기반 작업에 쓰기로 했습니다. 가장 먼저 진행한 것은 코드 아키텍처 정하기입니다. 당시에 제가 SAA(Single-Activity Application)에 관심을 가지고 있었는데, 때마침 Google I/O 2018의 세션 중 Modern Android development: Android Jetpack, Kotlin, and more 에서도 비슷한 언급이 나와서 팀에 제안했고, 본격적으로 조사를 해보았습니다. 팀원들이 조사를 진행해보니 Uber, Lyft, Grab 등 굴지의 모빌리티 서비스 회사들이 전부 SAA 기반으로 앱을 개발했다는 것을 알게 되었습니다. 무거운 리소스인 지도를 중심으로 화면이 구성되기에 반복적인 지도 리소스 할당/해제를 피하기 위한 필연적인 선택으로 보입니다. 큰 기업들이 수년간 서비스를 하며 문제를 느끼고 내린 선택인 만큼 저희도 따라가기로 결정했습니다. 비트윈 때 Activity Stack으로 인해 굉장히 고통을 겪은 적이 있는지라 SAA를 원하는 공감대도 있었고요.SAA로 개발을 하기로 정한 이후에는 어떤 프레임워크를 사용해서 개발할지를 고민했습니다. 여러 개의 오픈소스를 비교할 때 Android/iOS 간의 통일된 아키텍처로 개발할 수 있는지를 가장 중점적으로 보았습니다. 대부분의 팀원이 한쪽 OS에만 익숙하기 때문에 초보임에도 빠르게 적응하고 개발하려면 비즈니스 로직을 구현하는 부분이 통일되어 있어야 한다고 생각했습니다. Uber의 RIBs는 저희의 이런 요구를 가장 잘 충족했습니다. 거기에 데이터의 scope와 전달 방식 명확해서 side-effect 없이 개발할 수 있다는 점, 그로 인해 효율적으로 협업이 가능하고 여러명이 개발한 RIB 을 레고 조립하듯 합쳐서 기능을 완성할 수 있다는 점에서 RIBs를 선택하게 되었습니다.RIBs는 아키텍처를 이해하는 것 자체가 굉장히 난해합니다. 오픈소스 상으로 공개가 되지 않은 부분들도 있어서 저희의 입맛에 맞게 변형하는 데 매우 많은 시간을 할애했습니다. RIBs와 관련한 내용은 Nate(김남현)가 Let'Swift 2018에서 발표한 RxRIBs, Multiplatform architecture with Rx 의 영상 및 발표자료를 참조하세요.추후 RIBs를 상세하게 다루는 포스팅을 해보도록 하겠습니다.서버와의 통신 프로토콜새로운 서버 API가 생길 때마다 해당 API의 명세를 문서화하고 전달하는 것은 굉장히 불편한 일입니다. 또한 문서를 작성할 때나 클라이언트에서 모델 클래스를 생성할 때 오타가 발생할 수도 있습니다. 타다에서는 서버 클라이언트 간 API 규약을 Protocol Buffer를 사용해서 단일화된 방법으로 정의하고 자동화하기로 했습니다. 모든 API의 url은 .proto 파일 이름으로 정형화되어 있고 POST body로 Params 객체를 JSON으로 serialization 해서 보내면 Result JSON이 응답으로 옵니다. 서버가 새로운 API를 개발할 때 .proto 파일만 push 하면 클라이언트에서 스크립트를 돌려서 Model 객체를 생성하고 해당 객체를 사용해서 호출만 하면 되는 아주 간단하고 편한 방식입니다.참고로 타다의 서버군에 대한 설명은 타다 시스템 아키텍처에 기술되어 있습니다.기반 작업타다는 빈 repository에서 시작한 깔끔한 프로젝트였기 때문에 Base 코드와 내부 라이브러리들을 전부 새로 개발했습니다.API Controller, gRPC Controller서버와의 통신에 필요한 모듈들을 개발했습니다. 모든 API는 Rx의 Single과 Completable로 wrapping 되어 있습니다.RIBs가장 자주 사용하는 Router 패턴들을 wrapping.Android에서 구현이 공개되어 있지 않은 ScreenStack 구현.SAA이므로 Android에서 Activity가 아닌 화면 단위의 로깅을 구현.Router의 기초적인 화면 Transition을 구현RIB 뼈대 코드용 template 파일 제작Prefs(Android)/Store(iOS)타다에서는 DB를 사용하지 않고 key-value store로만 데이터를 저장합니다. Android SharedPreference와 iOS UserDefaults의 wrapper를 만들었습니다. Object를 serialization 해서 저장하는 기능, Rx 형태의 getter, cache layer, crypto layer 등이 구현되어 있습니다.Design SupportAndroid에서 drawable을 생성하지 않고 layout.xml 상에서 border, corner-radius, masking을 쉽게 설정하기 위해서 제작했습니다.ButterKtAndroid에서 View Binding 처리를 위해 개발했습니다. 비슷한 기능을 하는 Kotter Knife, Kotlin Android Extension이 가지고 있는 lazy binding 문제를 해결하고 싶었고 가능하면 Butter Knife와 달리 apt 없이 동작하는 라이브러리를 만들고 싶었습니다. 이와 관련된 저희의 생각은 여기에 David(김진형)이 상세하게 기록해 두었습니다. 코드도 공개되어 있으니 잘 활용해 보시길 바랍니다.ToolsModel CompilerPBAndK, swift-protobuf를 수정해 .proto 파일을 저희가 원하는 형태의 kotlin data class와 swift codable struct로 변환하는 스크립트를 구현했습니다.Import ResourceUI/UX 팀에서 작업해서 Google Drive File Stream으로 공유하는 리소스를 프로젝트에 sync 하는 스크립트입니다. 타다에서는 기본적으로 벡터 포맷(Android xml, iOS pdf)을 사용하고 Android에서 벡터로 표현이 안되는 이미지들은 png를 사용합니다. 또한 애니메이션을 위한 Lottie json 파일도 사용합니다. 현재는 Android 용으로만 스크립트가 구현되어 있고 리소스를 프로젝트 내의 각각의 res 폴더에 sync 하는 기능과 svg로 전달받은 벡터 파일을 Android xml 형식으로 변환하는 기능을 포함합니다.sync Lokalise타다에서는 Lokalise로 문자열 리소스를 관리합니다. strings.xml, Localizable.strings 파일로 다운받아서 프로젝트에 sync 하는 스크립트 입니다.Code Template & Settings개발 편의를 위한 간단한 Android Studio Code Template과 코드 통일성을 위한 idea settings를 공유합니다.사용된 기술들OS 공통Firebase: Analytics, Crashlytics, Messaging, Storage 등 다양한 용도로 Firebase를 활용하고 있습니다.gRPC, ProtoBuf: 서버에서 실시간 Event를 받기 위해서 사용합니다.RIBs: 타다의 기반 아키텍처 입니다.Lottie: 애니메이션 요소를 표현하기 위해 사용합니다.Semver: 앱의 버전은 Semantic Versioning 규약을 따라 정의합니다. 버전을 파싱하고 관리하기 위해서 Nate(김남현)가 Kotlin 버전과 Swift 버전의 라이브러리를 제작하고 공개했습니다.Braze: CRM(Customer Relationship Management) 툴인 Braze는 유저를 타게팅해서 전면팝업을 띄우거나 푸시 알림을 발송하기 위해 사용합니다.TeamCity, Fastlane, Beta: CI/CD를 위해서 개발 초기에는 Jenkins를 사용했습니다. 출시 대응을 빠르게 하기 위해서 parallel build 및 우선순위 컨트롤을 하고 싶었는데 Jenkins의 Parallel build가 원하는 대로 동작하지 않아서 현재는 TeamCity로 이전했습니다. Beta를 사용해서 모든 브랜치의 빌드를 배포해서 QA 팀에서 테스트할 수 있게 했습니다. 출시용 빌드는 Android의 경우 아직은 수동 업로드를 하고 있고 iOS의 경우 Fastlane으로 배포합니다.git-flow: Git branching model로는 git-flow를 사용합니다. Branch의 종류에 따라서 TeamCity에서의 빌드 우선순위가 결정됩니다.AndroidKotlin: 당연한 선택이겠죠? 타다의 모든 소스 코드는 Fork 해서 수정한 RIBs의 클래스들을 제외하면 전부 Kotlin으로 구현되어 있습니다.AndroidX: 타다 개발을 시작하는 순간에 AndroidX가 공개되었습니다. 기존 Support Library를 사용하게 되면 언젠가는 migration 해야 할 것이기 때문에 알파 버전임에도 불구하고 처음부터 사용하기로 했습니다. ConstraintLayout, PagingLibrary, Material Component, KTX 등 다양한 Component를 사용합니다.Retrofit, OkHttp: 서버와의 HTTP 통신을 위해서 사용합니다.RxJava: 클라이언트 팀은 Rx 없이는 개발할 수 없을 정도로 적극적으로 Rx를 활용합니다.AutoDispose: Rx subscription을 dispose 하기 위해서 사용합니다. 관련해서 도움이 될만한 글을 읽어보시는 것을 추천합니다. Why Not RxLifecycle?RxBinding: View 이벤트를 Observable 형태로 바꿔주는 RxBinding은 굉장히 유용합니다.Moshi: JSON 라이브러리입니다. Kotlin data class와의 호환을 위해서 Gson 대신 선택했습니다.Glide: 이미지 로딩을 위해서 사용합니다.Detekt: Kotlin을 위한 static code analyzer 입니다. Detekt의 extension을 통해 ktlint도 활용하고 있습니다.Dagger: RIBs는 Dependency injection을 기반으로 합니다. RIBs에선 어떠한 DI system이든 사용할 수 있게 Builder가 분리되어 있습니다. RIBs에서는 Dagger로 설명이 되어 있고 저희도 마찬가지로 Dagger를 사용합니다.ThreeTen Backport: Java8의 날짜 및 시간 라이브러리인 JSR-310의 Java SE6 & 7을 위한 backport 라이브러리입니다. 문자열 파싱 및 시간 연산을 위해 사용합니다.iOSSwift: Kotlin과 마찬가지로 당연한 선택입니다. Swift4.2의 CaseIterable Swift5의 Result 등 항상 최신 버전의 Swift를 사용합니다.RxSwift: 역시나 reactive programming은 필수입니다.RxCocoa, RxGesture: iOS에서도 역시 모든 뷰 이벤트는 Rx 형태로 감지합니다.SnapKit: AutoLayout DSL을 제공하므로 코드상에서 편하게 Constraint를 조절할 수 있습니다.Moya/RxSwift, Alamofire: Http 서버와의 통신을 위해 추상화된 네트워크 라이브러리인 Moya를 사용합니다. 역시나 Rx로 wrapping 된 버전을 사용하고 있습니다.Codable: Swift4부터 제공된 프로토콜로 JSON Encoding, Decoding으로 사용중입니다.Hero: RIBs의 Router가 attach/detach 될 때의 Transition을 처리하는데 이용합니다.Kingfisher: 이미지 로딩을 위해서 사용합니다.KeychainAccess: Access Token 같은 중요 정보를 안전하게 저장하기 위해 사용합니다.Swiftlint: SwiftLint는 fastlane action으로 실행해서 code validation을 합니다.출시 후의 회고짧은 시간에 여러 개의 앱을 만들기 위해서는 시간 및 인원을 아주 효율적으로 배분해야 했습니다. 각 OS의 기존 개발자들이 먼저 프로젝트 기반을 닦는 동안 나머지는 스터디를 진행했습니다. 차량 운영 경험을 쌓는 것이 알파 테스트의 목적이었으므로 일정에 맞추기 위해 드라이버 앱도 개발해야 하는 Android로만 알파 버전을 개발했습니다. 대신에 iOS 알파 버전은 서버팀 YB(김영범)가 아주 빠르게 웹앱으로 개발해주었습니다(1.0은 Native입니다.). 알파 버전의 스펙도 호출-하차까지의 시나리오 외의 다른 부가 기능은 전부 제외했습니다.회사 구성원들이 전부 처음 도전하는 분야였기에 기획을 포함해서 모두가 지속적인 변화에 대응해야 했습니다. 특히 사내 테스트를 시작한 직후 실제 운영을 해보며 깨닫고 변경한 기획 및 UX가 상당히 많았습니다. 개발적으로는 익숙하지 않은 아키텍처인 RIBs를 이해하며 개발하는 것이 생각 이상으로 난도가 높았고 개발하는 중간에도 큰 리팩터링을 여러 번 해야 해서 힘들었습니다. 이러한 이유들로 1.0 출시도 시작 전 상황에서 언급한 것보다 2주 정도 미뤄졌습니다.실제 타다 프로젝트 타임라인하지만 저희는 성공적으로 타다를 출시했습니다! 아래는 팀 내에서 출시를 회고하며 나왔던 몇몇 의견입니다.OS 간 아키텍처가 통일되어서 한 명이 같은 기능을 두 OS 전부 개발할 때 굉장히 효율적이다. 비즈니스 로직의 경우 정말로 Swift <-> Kotlin간 언어 번역을 하면 되는 정도.결과적으로 앱 개발 순서를 굉장히 잘 정했다. 한쪽을 먼저 빠르게 개발하고 문제점을 느껴보며 정비해 나가니까 프로젝트 후반부에 빠른 속도로 기능을 개발하는 데 도움이 되었다. 큰 수정을 양쪽 OS에 하지 않아도 됐던 게 좋았다.짧은 기간 개발했음에도 앱 퀄리티가 굉장히 만족스럽다. 매 상황에서 기술적 선택, 인원 배분 등 경험에서 우러나온 아주 적절한 판단들을 했다고 생각한다.각자 독립적으로 개발하던 기능들이 쉽게 합쳐지고 큰 문제없이 잘 동작하는 하나의 앱이 되는 과정이 정말 신기했다. 아키텍처 설계에 쓴 많은 시간이 결코 아깝지 않았다.마치며아직 저희가 하고 싶고 도전해야 하는 과제들은 무궁무진합니다. 그 중 간략히 몇 가지를 소개합니다.테스트 코드 작성: 시간과의 싸움 속에서 테스트 코드 작성을 지금까지 미뤄왔습니다. RIBs의 Interactor 에 구현된 비즈니스 로직은 반드시 테스트 되어야 합니다.OS 간 구조 통일: 같은 화면임에도 OS 간 작업자가 다른 경우 많은 파편화가 일어났습니다. 1순위로 RIB tree 및 Interactor의 비즈니스 로직 통일하는 작업을 진행하고 있습니다. AlertController 같은 공통적인 컴포넌트들도 최대한 포맷을 통일하려는 작업을 지속해서 진행할 예정입니다.iOS DI: RIBs에서 Android에선 Dagger를 활용해서 쉽게 Builder 구현이 가능하지만, iOS에서는 좋은 방법이 없어서 수동으로 DI를 해결하고 있었습니다. 그래서 Uber가 개발 중인 Needle을 적용하려고 관심 있게 보고 있습니다.네트워크 에러 handling 개선: 중첩돼서 뜨는 Alert를 해결하는 것, global 하게 에러를 처리하는 좋은 구조 찾기 등의 이슈가 있습니다.String Resource 관리: 개발하면서 생성하고 아직 Lokalise에 동기화하지 않은 리소스 키를 체크해서 빌드 오류를 발생시키려고 합니다. 또한 iOS에서 "some_key".localize 형태의 extension으로 번역을 코드상에서 불러오는데 key 값 오타가 나면 런타임에서만 오류를 알 수 있습니다. 따라서 String resource를 enum 형태로 관리하려고 합니다.그 외 50여 가지나 되는 팀원들이 하고 싶은 백로그 목록이 여러분을 기다리고 있습니다. 타다가 성공적으로 런칭할 수 있었던 것은 훌륭한 팀원들이 있었기 때문입니다. 앞으로 저희와 함께 좋은 서비스를 만들어 나갈 멋진 분들의 많은 관심 바랍니다.
조회수 1130

에잇퍼센트와 함께한 2016년

2016년 4월에 에잇퍼센트에 합류해서 2016년을 에잇퍼센트와 함께 보냈다. 1년을 다 채운건 아니지만 에잇퍼센트의 성장과 발전에 개발자로서 어떤 기여를 했는지 한 번 정리해 보려고 한다. 나에게 있어서는 물론이고 에잇퍼센트에도 의미가 있을 것이다.1. 대출 개설 내역 신용평가사 공유대출자에게 대출이 실행되면 이 내역을 신용평가사의 시스템으로 공유하는 것을 개발했다. 에잇퍼센트에서 받은 대출 내역이 공유되면 타 금융권에서 대출 개설 내역을 확인할 수 있으므로 추가 대출이 쉽게 이루어지지 않을 것이다. 우리의 고객은 대출자도 있지만 투자자도 있다는 측면에서 투자자의 소중한 투자금을 안전하게 지켜내기 위한 안전 장치 중 하나가 될 수 있다.  2. 성능 개선에잇퍼센트는 빠르게 성장하고 있는 스타트업이다. 스타트업이 비즈니스적으로 빠른 실행을 하며 달리다 보면 성능의 벽에 부딪힐 때가 있는데 마침 내가 합류하고 얼마 되지 않은 시점이었다. 주로 우리의 개발 환경인 Python Django 코드를 개선하는 방향으로 진행을 했고 추후에는 사용자 브라우저단 성능 개선도 진행했다. Python Django 코드 개선에 대한 자세한 내용은 내가 쓴 블로그 포스팅에서 확인할 수 있다.3. 서버 인프라 서울 이전에잇퍼센트는 서버 인프라로 Amazon Web Services(이하 AWS)를 사용하고 있다. 서비스를 처음 시작할 때에는 AWS 도쿄 리전이 가장 가까운 곳이어서 도쿄 리전을 사용하고 있었다. 그러다가 2016년이 되어 서울 리전이 생겼고 도쿄 리전에 비해 네트워크도 빠르고 비용도 저렴해서 사용하지 않을 이유가 없었다. 그래서 도쿄 리전에서 서울 리전으로 이전하는 작업을 진행했다. 밤샘 작업을 함께 해준 개발팀원들에게 고맙다는 얘기를 다시 한번 하고 싶다.그 날의 풍경과 작업 기록, 그리고 django-storages 서울 리전 연동에 대한 글까지 남겨두었다.4. Python Django 버전 업그레이드에잇퍼센트에 합류했을 때 Python 3.4 , Django 1.8을 사용하고 있었고 Python 3.5 Django 1.9로 버전 업그레이드를 진행했다. 버전 업을 하면서 발견된 큰 문제는 없었고 Django admin 의 UI 에 flat 디자인이 적용되어 화면이 이뻐졌다. 내가 직접 한 건 아니지만 화면이 이뻐졌다고 다들 좋아해 준 기억이 난다.참고로 현재의 최신 버전은 Python 3.6 Django 1.10이다.5. 테스트 개선개발을 빠르게 하는 것도 중요하지만 안정적으로 잘 동작하는 것도 그에 못지않게 중요하다. 안정적인 서비스 개발과 운영을 위해 테스트가 중요하다. 특히나 돈을 다루는 금융회사라면 더욱 중요한 것이 테스트이기에 에잇퍼센트 개발팀에도 테스트는 매우 중요하다. 테스트 코드를 잘 작성해야 하고 테스트 코드가 실제 코드를 얼마나 커버하는지에 대한 측정도 필요하다. 에잇퍼센트는 코드를 개발해서 push 하고 pull request를 할 때마다 travis를 통해서 테스트를 수행하고 커버리지를 측정하고 있다. 커버리지 측정을 처음 시작할 때와 비교해보면 기존 대비 10% 포인트 가량 커버리지가 올라갔다. 커버리지가 떨어지면 pull request를 승인하지 않는 것을 정책으로 가져가고 있다.테스트 수행 시 커버리지 측정과 함께 PEP8 준수 확인, migration 체크, 템플릿 검증 등을 하도록 개선했다. 또한 기존에는 테스트 수행 시 sqlite3을 DB로 사용했는데 개선 후에는 실제로 사용하고 있는 PostgreSQL을 사용하도록 했다. 성능을 위해 raw SQL을 사용하는 경우가 가끔 있는데 이때 테스트가 제대로 안 되는 문제를 개선할 수 있었다.6. 개발 환경 개선유지 보수가 용이하고 효율적으로 개발하기 위한 환경을 만들기 위해 노력했다. smarturls, django-debug-toolbar, factory boy 등의 패키지를 적용했으며 로컬 서버 외에 개인별로 배포해서 테스트할 수 있는 서버 환경을 만들어서 테스트를 용이하게 했다. django 설정 분리, 모델 분리, 상수 분리 등의 리팩토링도 진행했다.7. NH핀테크 오픈플랫폼 적용 (진행 중)NH 농협 은행에서 제공하는 API를 사용해서 금융 관련 작업을 자동화하고 효율화하려고 한다. NH에서 요구하는 정보보호 및 보안 기준에 맞춰 시스템을 정비하고 만들어 나가는 중이다. 올해 상반기 안에 API 연동이 되어 에잇퍼센트에 NH핀테크 오픈플랫폼이 알맞게 녹아들어 가기를 기대해본다.8. 서비스 개선에잇퍼센트의 서비스적인 개선도 몇 가지 진행했다.- 채권 상세 페이지 개선 : 투자한 채권에 대한 지급 현황, 지난 내역을 볼 수 있게 되었다.- 로그인 상태 유지 : 기본 30분 로그인이 유지되고 30일 유지를 선택할 수 있게 되었다.- Ada 챗봇 연동 : 금융권 챗봇 중 유일하게 학습하는 Ada가 서비스와 연동하기 위한 개발을 진행했다.1~7번까지의 작업은 주로 눈에 보이지 않거나 개발팀 내부적인 개선이었고 8번은 사용자에게 바로 보이는 서비스적인 개선이었다. 위에 언급한 것 외에 코드 리뷰를 열심히 한 것이 기억에 남는다. 코드 리뷰를 통해 유지보수가 용이하고 효율적인 코드를 만들어 나가고 싶었다. 어떤 코드가 유지보수가 용이하고 효율적인지 리뷰를 통해 토론하고 배워나가는 과정이 나뿐만 아니라 개발팀 모두에게 도움이 되었으리라 본다.개인적으로는 이음에서 Ruby on Rails로 개발을 재밌게 하다가 에잇퍼센트에서의 Python Django를 사용한 개발로의 도전과 전환이었다. 새로운 언어를 접하고 배워나가는 과정 또한 개발자에게는 즐거움이 아닐까 싶다. Ruby, Python 둘 다 엄청나게 잘 하는 건 아니지만 기회가 되면 Ruby와 Python 각각의 장단점을 비교해보는 것도 재미있을 것 같다.2016년은 내가 2006년 첫 회사에 들어간 지 10년이 된 해였다. 10년 전 신입 사원 시절에는 서비스적인 개선을 주로 하고 다른 팀원에게 도움을 주기보다 내 할 일에만 충실했었다. 10년이 지난 지금 작년 한 해를 이렇게 돌아보니 서비스에 직접적인 개선도 하고 다른 팀원들이 개발을 더 잘할 수 있도록 환경을 만들고 도움을 주는 데에도 제법 역할을 했다는 생각이 든다. 나 자신이 엄청나게 변화한 건 아니지만 10년이 헛된 시간은 아니었다는 생각이 들어서 내심 뿌듯하다.2016년을 이렇게 정리하고 보니 2017년에는 더 잘 해야겠다는 생각이 든다. 에잇퍼센트 모든 구성원들과 함께 엄청나고 멋지게 성장해 보고 싶다. 화이팅!2016년 처럼 올해도 해맑게 화이팅!#8퍼센트 #에잇퍼센트 #조직문화 #기업문화 #2016년 #돌아보기 #스타트업개발자 #개발자
조회수 1043

[사람이 서비스다] #4 JD, 안드로이드앱 개발 담당

셀잇은 기존 중고거래 시장에서 이용자들이 겪는 불편과 불안감을 해소하기 위해 등장한 서비스라는 자부심을 가지고 구매자와 판매자를 잇는 접점이 되고자 합니다. 이를 위해 서비스를 기획하고 실행하는 저희 구성원들에 대한 이야기를 간간히 들려드리고자 합니다. 좋은 서비스든 아이디어든 결국 사람이 하는 일이니까요-저희가 어떤 생각을 품고 어떤 마음가짐으로 살아가는지에 대해 진솔하게 풀어보고자 합니다. 이 청년들의 이야기, 한 번 들어보실래요? Interviewee: JD (제이디, 개발팀 / 안드로이드앱 개발 담당)Interviewer: Austin (오스틴, 마케터)  우선 자기소개부터 간단히 해주시죠. 흔해 빠진 소개일랑 집어치우고! 최대한 자신을 우리에게 알려봐요! 정~ 뭐라고 쓸지 모르겠으면 자기 이름으로 삼행시라도 해보세요. 우선 저에게 이런 귀찮은 일을 안겨준 브라이언에게 감사의 인사를 전하는 바입니다. 덕분에 독무대에 이어 다시 한번 불면증에 시달리게 되었어요. 그건 브라이언에게 개인적으로 앙갚음(?)을 해주시고, 본인 소개부터 해주세요. 저도 바쁘답니다. 안녕하십니까? 저는 전남 해남의 작은 시골 마을에서 2남 중 장남으로 태어나 안드로이드 개발을 하고 있는 JD라고 합니다. 원래는 게임 개발이 하고 싶어서 프로그래밍 공부를 시작하였지만 어쩌다 보니 앱을 개발하고 있네요. (뭐, 뭐지? 이 ‘신입사원의_패기.wav’ 같은 느낌은?) 그럼 현재 셀잇에서 개발자로 일하시겠군요. 그럼 본인이 하는 일 중에서 이건 나만의 스페셜티다! 하는 부분은 무엇인가요? 당연히 안드로이드 개발입니다. 우리 회사에서 저 밖에 못하는 거죠~(찡긋) (찡...찡긋?) 하하하;; 네네 그렇군요. (셀잇이 잘 되는 이유가 이거였군. 정상적인 놈이 없는...) 그게 다인가요? 개발하시다가 잘 안풀리거나 열 받을 때는 어떻게 하나요? 자세한 건 ‘영업비밀’이니까- 전 안풀리면... 음- (한참을 생각한다)잠을 잡니다. (역시 오늘도 산으로 가는건가…) 아…(포기한 듯) 얼마나 자나요? 한 20분 정도 짧게 자요. 사실 잔다기보다는 자는 척을 하면서 생각을 하는거죠. 읭? 굳이 자는 척을 해야 될 필요가 있나요? 그냥 대놓고 생각하면 안되는건가요? 안됩니다! 온전한 집중을 위해서 자는 척을 해야 해요. (정적) 인터뷰 하는 중에 월드시리즈까지 끝나버렸네요... 올해 모든 야구가 끝나버렸어요 ㅠ (후우... 내가 이걸 왜 시작했을까...) 그럼 일 얘긴 그만하고(더 할 수도 없겠어;;) 업무 외의 시간에는 주로 뭘 하시나요? 듣자하니 야구를 좋아하는 것 같은데- 야구를 봅니다. 한국 야구는 기아를 응원하고, 메이저리그는 한국 선수들이 진출한 팀들을 응원하고 있어요. 주말에는요? 주말이면 아침에 일어나서 메이저리그 두 경기 정도 보고 오후에는 한국 야구를 보면서 하루를 보냅니다. 이제 야구 시즌도 다 끝나서 다가오는 겨울이 두렵습니다ㅠ 차라리 야구선수로 전향하시는게- 만약 실력이 문제라면 사회인 야구팀이라도 해보시는건요? 그건 돈도 많이 들고, 일단 귀찮고-부상 위험도 크고, 일단 귀찮고-그냥 친구랑 캐치볼 하는 것으로 만족합니다. 그리고 일단 귀찮고- 커피나 한 잔 하실래요? 커피나 마시면서 다른 얘기로 넘어가죠~ 괜찮습니다. 저는 카페인 마시면 안되서- 아, 그럼 그냥 계속 하죠. (여자랑은 술 마시고 나랑은 커피도 안 마시냐?-_- 쳇, 근데 이해되네...) 중고에 대해서 어떻게 생각하세요? 중고를 바라보는 가치관 같은게 있으시면 말씀해 주세요. 제가 환경 문제에 관심이 많습니다. 중고거래가 보편적으로 활성화 된다면 상대적으로 공산품의 생산량이 줄어들게 되고, 이는 지구의 자연 환경에 도움이 되지 않을까 합니다. (응? 뭔가 익숙한데?) 제가 예전에 쓴 글을 보신건가요?… 네~ 꼭 중고 거래가 활성화되서 지구 환경을 지켜주세요… 그럼 마지막으로 셀잇에서 이루고 싶은 것은 무엇인가요? 주로 컴퓨터 부품들을 중고 거래를 이용해 구매했던 적이 있는데요. 항상 직거래를 했지만 정상 작동하는지 불안했던 기억이 있습니다. 집에 와서 컴퓨터에 장착해 보고서야 안심을 하곤 했었는데, 셀잇을 이용하면 최소한 이런 걱정 없이 믿고 안심하며 거래할 수 있는 서비스로 자리 잡을 수 있었으면 합니다. 아니 이건 셀잇이 나아갈 방향이고~ 저는 제이디 본인 개인의 목표에 대해서 물은거예요. 셀잇이 곧 저입니다. 화, 화이팅...! (후우...) 이런 자리가 부끄럽죠? 가슴 속에 뜨거운 뭔가가 있는게 보이지만 굳이 밝히지 않으시겠다면 앞으로 안드로이드 앱을 통해 그 뭔가를 제가 찾아보겠습니다. (빨리 끝내려 애쓴다;;) 인터뷰는 이 정도로 마치는 것으로 하고~ 셀잇에서 칭찬하고 싶은 사람 한 명만 꼽아주세요. 이유도 함께 말해주세요. 전 네이쓴을 칭찬하고 싶습니다. 특유의 친화력과 유머러스함으로 주변 사람들을 기분 좋게 만들어주는 아주 훌륭한 팀원이기 때문입니다. 로봇입니까? 네? 아닙니다. 그럼 오늘 수고하셨습니다. 아! 최근에 셀잇 앱 2.0이 배포됐는데 감회가 남다를 것 같 같은~ 어떠세요? 딱히 이렇다할 소감은 없습니다만 이용자분들이 이전보다 더 편하게 서비스를 이용할 수 있었으면 하는 바람입니다. (로봇 맞네...) 넵- 수고하셨습니다. (하아... 네이쓴이라... 다음엔 우주로 가겠구만...)#셀잇 #번개장터 #인터뷰 #팀소개 #팀인터뷰 #팀원소개 #기업문화 #조직문화 #회사문화 #사내문화
조회수 2423

A/B Testing 도구인 Optimizely 사용법

웹 서비스를 운영하다 보면 준비하는 과정에서 정말 많은 고민이 오갑니다. 컨텐츠의 배치, 헤드 카피, 인터랙티브.. 하지만 어떤 요소가 조금 더 사용자의 반응을 이끌어내는지 정확히 알 수 없습니다. 이런 부분들을 ‘직감’이나 ‘경험’으로 막연하게 자기 자신과 타인에게 주장하고 있지는 않나요?그렇다면 두 가지 혹은 그 이상의 시안들을 직접 시험대에 올려 각각 더 좋은 것을 선택하는 것은 어떨까요?A/B 테스팅에 관련한 유명한 일화가 하나 있습니다. 1497년, Vasco da gama는 최초로 유럽에서 아프리카 남부를 거쳐 인도까지 항해한 인물입니다. 그가 인도를 발견하고 귀항했을 때 160명의 원정대원 중 100명이 괴혈병으로 사망하는 사건이 있었습니다. 그만큼 괴혈병은 항해하는 선원들의 공포 대상이었죠. 그로부터 약 300년 뒤, 영국의 의사인 James Lind는 괴혈병의 치료법을 알기 위해 실험군을 나누어 각각 다른 음식으로 실험을 진행했습니다.실험은 다음과 같습니다. 괴혈병에 걸린 12명의 선원을 선정하여 그 중 10명에게는 보통 음식을 주고, 두 사람에게는 매일 라임 과즙을 마시게 하였습니다. 6일 후 라임 과즙을 마신 선원 두 명만이 괴혈병에 완벽히 치료된 모습을 보였습니다. James Lind가 실험하기 전에는 단순히 ‘감귤류 과일이 괴혈병에 좋다.’, ‘괴혈병으로 죽어가는 찰나에 잡초를 먹고 다시 살아났다.’ 라는 이야기만이 난무했었고 직접적인 치료법을 제시한 사람은 James Lind가 최초였습니다. 비타민C가 발견된 것이 1928년임을 고려하면, 이 당시에는 비타민C 이라는 개념이 없었기 때문에 James Lind의 실험은 후에 많은 선원의 목숨을 괴혈병으로부터 지켜주는 사례가 됩니다.괴혈병이 해적보다 더 무서웠던 대항해시대에 보통 음식(A)과 라임(B)을 이용해 선원들을 모두 구했던 영국 해군의 현명한 대처법에서 우리의 웹 서비스를 더욱 더 활성화 시키는 지혜를 얻어야 합니다.Optimizely?Optimizely는 웹서비스를 운영하면서 A/B Testing 수행을 원하시는 분들에게 적합한 서비스입니다. Optimizely를 사용하기 전에 A/B 테스팅에 대한 정보가 필요하다면 A/B 테스팅에 관련한 JC Kim님의 글( A/B Testing에 대한 기초적인 정보들 )을 먼저 읽어보시는 것을 추천합니다.Optimizely는 단순히 A/B 테스트의 진행과 그 통계 결과만 제공하는 것이 아니라, 테스트를 진행하는 동안의 모든 준비 과정에서 사용자들에게 도움을 주고 있습니다. 오늘은 그 Optimizely의 핵심 기능 및 활용법에 대하여 알아보겠습니다. Optimizely는 유료 서비스이지만 30일 동안의 Free Trial을 제공해주므로 그 기간 동안 충분히 이 서비스의 모든 것을 체험할 수 있습니다.Optimizely는 세계적인 대형 기업들이 이용하는 서비스로, 이들은 이미 Optimizely를 통해 각각 컨텐츠들에 대한 사이트 접속자들의 반응을 체크하고 있습니다. 대표적인 회사로 Starbucks, Salesforce, MTV, The Walt Disney Company, ABC 등이 있습니다.그렇다면 왜 많은 기업들이 A/B Testing에 집중하고 있고, Optimizely를 이용하는 걸까요?더 정확한 데이터를 추출하려는 노력.메일링 리스트를 수집하는 등의 폼 입력/전송을 하는 비율을 구하는 경우, 혹은 메인 페이지에서 다른 세부페이지로 이동하는 이용자 비율을 나타내기 위해 목표(Goal)을 나타냅니다. 목표한 골에 A 버전(기존안/Original) 이용자가 더 많이 들어갔는지, B 버전(새로 작성한 안/Variation)이 효과적이었는지를 테스트 할 수 있습니다.이처럼 Goal에 도달하는 행위를 ‘Conversion’이라 표현합니다. 방문자 수 대비 Conversions 수치를 비교한 Conversion rate를 비교하면 A/B 시안 중에 더 효과적인 결과를 수치와 그래프, 특히 “기준을 이길 수 있는 확률”(Chance to beat baseline)을 철저하게 계산해 결과를 명확하게 진단할 수 있습니다. 말 그대로 Goal과 Conversion Rate 수치로 사용자가 승자를 판단하는 것이 아니라, 수치공식을 통해 B 버전이 기존안(A버전)을 확실하게 이겼는지 아닌지를 파악해줍니다.더 자세히 알고싶은 부분은 해당 값을 구하는 통계공식이 있는 링크를 참고해주세요.정말 쉬운 실험요소 변경.Optimizely를 이용하면 여러분이 복잡한 CSS나 Javascript 기술이 없어도 쉽게 A/B 테스팅을 진행할 수 있습니다. Optimizely에서는 실험군의 요소를 마우스 클릭 몇 번으로 손쉽게 바꿀 수 있습니다. 가령 B 버전에 A 버전과 다른 문서 배치를 하거나 배경화면, 이미지, 폰트, 버튼 속의 문구 등도 별도의 코딩 절차 없이 Optimizely 실험페이지 내에서 변경할 수 있다는 말이죠. 또한 실시간으로 CSS를 변경하여 적용하거나 Javascript도 적용할 수 있습니다. 마치 ‘나모 웹 에디터’ 나 ‘드림위버’ 같은 인터페이스로 파워포인트 내의 요소를 다루듯 쉽게 바꿀 수 있습니다.위치와 크기를 Drag & Drop 으로 쉽게 움직이게 할 수 있습니다.웹사이트에 적용된 이미지 또한 로컬에 있는 파일 혹은 웹에 있는 이미지로 대체할 수 있습니다.텍스트도 곧바로 변경할 수 있고 HTML을 직접 대체해서 끼워 넣을 수 있습니다.참 쉽죠?간단한 설치위처럼 변경했던 시험요소들을 저장하려면 복잡하고 긴 코드를 다시 원래 파일에 붙여 넣어야 할까요? 그렇지 않습니다. Optimizely는 변경한 컨텐츠 정보를 간단한 자바스크립트 코드로 ‘Optimize’ 해 주기 때문에 단 몇줄만 추가해주면 원하는 결과가 나옵니다.확장성유명한 아티스트 두 명이 콜라보레이션 하는 상상을 해보죠. 각자의 개성을 살려 새로운 결과물들을 창조해내지요. 물론 그들의 궁합이 잘 맞아야 한다는 전제가 있습니다. 하지만 다행히도 Optimizely와 연동되는 서비스들은 궁합이 잘 맞는 편입니다. Optimizely는 A/B 테스팅에 관한 자료에 집중하고 있기 때문에, 조금 더 디테일한 자료(Analytics, Heatmap)는 욕심내지 않고 기타 많은 서비스와 연동합니다.Optimizely와 연동되는 서비스는 다음과 같습니다.AnalyticsGoogle AnalyticsKISSmetricsMixpanelOmniture SiteCatalystHeatmapClickTaleCrazyegg위 서비스 중 하나라도 이용 중이시라면, Optimizely와 어떤 부분이 연동이 되는 지 살펴보세요.마치며페이지 두 개를 접속자들에게 무작위로 나누어 배포해서 반응을 트래킹하는 기술은 흔할지도 모릅니다. 하지만 Optimizely를, 그리고 연동되는 다양한 서비스들을 이용하면 조금 더 세밀하고 확실한 데이터를 얻을 수 있습니다. 정말로 나의 웹 서비스에 필요한 것이 ‘잡초’인지 ‘레몬’인지 알고 싶다면 지금 당장 시작해보세요.#스포카 #기획 #A/B테스트 #A/BTest #꿀팁 #인사이트 #조언
조회수 1598

HBase 설정 최적화하기 - VCNC Engineering Blog

커플 필수 앱 비트윈은 여러 종류의 오픈 소스를 기반으로 이루어져 있습니다. 그 중 하나는 HBase라는 NoSQL 데이터베이스입니다. VCNC에서는 HBase를 비트윈 서비스의 메인 데이터베이스로써 사용하고 있으며, 또한 데이터 분석을 위한 DW 서버로도 사용하고 있습니다.그동안 두 개의 HBase Cluster 모두 최적화를 위해서 여러 가지 설정을 테스트했고 노하우를 공유해 보고자 합니다. 아랫은 저희가 HBase를 실제로 저희 서비스에 적용하여 운영하면서 최적화한 시스템 구성과 설정들을 정리한 것입니다. HBase를 OLTP/OLAP 목적으로 사용하고자 하는 분들에게 도움이 되었으면 좋겠습니다. 아래 구성을 최적화하기 위해서 했던 오랜 기간의 삽질기는 언젠가 따로 포스팅 하도록 하겠습니다.HBaseHBase는 Google이 2006년에 발표한 BigTable이라는 NoSQL 데이터베이스의 아키텍처를 그대로 따르고 있습니다. HBase는 뛰어난 Horizontal Scalability를 가지는 Distributed DB로써, Column-oriented store model을 가지고 있습니다. 사용량이 늘어남에 따라서 Regionserver만 추가해주면 자연스럽게 Scale-out이 되는 구조를 가지고 있습니다. 또한, Hadoop 특유의 Sequential read/write를 최대한 활용해서 Random access를 줄임으로 Disk를 효율적으로 사용한다는 점을 특징으로 합니다. 이 때문에 HBase는 보통의 RDBMS와는 다르게 Disk IO가 병목이 되기보다는 CPU나 RAM 용량이 병목이 되는 경우가 많습니다.HBase는 많은 회사가 데이터 분석을 하는 데 활용하고 있으며, NHN Line과 Facebook messenger 등의 메신저 서비스에서 Storage로 사용하고 있습니다.시스템 구성저희는 Cloudera에서 제공하는 HBase 0.92.1-cdh4.1.2 release를 사용하고 있으며, Storage layer로 Hadoop 2.0.0-cdh4.1.2를 사용하고 있습니다. 또한, Between의 데이터베이스로 사용하기 위해서 여러 대의 AWS EC2의 m2.4xlarge 인스턴스에 HDFS Datanode / HBase Regionserver를 deploy 하였습니다. 이는 m2.4xlarge의 큰 메모리(68.4GB)를 최대한 활용해서 Disk IO를 회피하고 많은 Cache hit이 나게 하기 위함입니다.또한 Highly-Available를 위해서 Quorum Journaling node를 활용한 Active-standby namenode를 구성했으며, Zookeeper Cluster와 HBase Master도 여러 대로 구성하여 Datastore layer에서 SPOF를 전부 제거하였습니다. HA cluster를 구성하는 과정도 후에 포스팅 하도록 하겠습니다.HDFS 최적화 설정dfs.datanode.handler.countHDFS에서 외부 요청을 처리하는 데 사용할 Thread의 개수를 정하기 위한 설정입니다. 기본값은 3인데 저희는 100으로 해 놓고 사용하고 있습니다.dfs.replicationHDFS 레벨에서 각각의 데이터가 몇 개의 독립된 인스턴스에 복사될 것 인가를 나타내는 값입니다. 저희는 이 값을 기본값인 3으로 해 놓고 있습니다. 이 값을 높이면 Redundancy가 높아져서 데이터 손실에 대해서 더 안전해지지만, Write 속도가 떨어지게 됩니다.dfs.datanode.max.transfer.threads하나의 Datanode에서 동시에 서비스 가능한 block 개수 제한을 나타냅니다.과거에는 dfs.datanode.max.xcievers라는 이름의 설정이었습니다.기본값은 256인데, 저희는 4096으로 바꿨습니다.ipc.server.tcpnodelay / ipc.client.tcpnodelaytcpnodelay 설정입니다. tcp no delay 설정은 TCP/IP network에서 작은 크기의 패킷들을 모아서 보냄으로써 TCP 패킷의 overhead를 절약하고자 하는 Nagle's algorithm을 끄는 것을 의미합니다. 기본으로 두 값이 모두 false로 설정되어 있어 Nagle's algorithm이 활성화되어 있습니다. Latency가 중요한 OLTP 용도로 HBase를 사용하시면 true로 바꿔서 tcpnodelay 설정을 켜는 것이 유리합니다.HBase 최적화 설정hbase.regionserver.handler.countRegionserver에서 외부로부터 오는 요청을 처리하기 위해서 사용할 Thread의 개수를 정의하기 위한 설정입니다. 기본값은 10인데 보통 너무 작은 값입니다. HBase 설정 사이트에서는 너무 큰 값이면 좋지 않다고 얘기하고 있지만, 테스트 결과 m2.4xlarge (26ECU) 에서 200개 Thread까지는 성능 하락이 없는 것으로 나타났습니다. (더 큰 값에 관해서 확인해 보지는 않았습니다.)저희는 이 값을 10에서 100으로 올린 후에 약 2배의 Throughput 향상을 얻을 수 있었습니다.hfile.block.cache.sizeHBase 의 block 들을 cache 하는데 전체 Heap 영역의 얼마를 할당한 것인지를 나타냅니다. 저희 서비스는 Read가 Write보다 훨씬 많아서 (Write가 전체의 약 3%) Cache hit ratio가 전체 성능에 큰 영향을 미칩니다.HBase 에서는 5분에 한 번 log 파일에 LruBlockCache (HBase 의 Read Cache) 가 얼마 만큼의 메모리를 사용하고 있고, Cache hit ratio가 얼마인지 표시를 해줍니다. 이 값을 참조하셔서 최적화에 사용하실 수 있습니다.저희는 이 값을 0.5로 설정해 놓고 사용하고 있습니다. (50%)hbase.regionserver.global.memstore.lowerLimit / hbase.regionserver.global.memstore.upperLimit이 두 개의 설정은 HBase에서 Write 한 값들을 메모리에 캐쉬하고 있는 memstore가 Heap 영역의 얼마만큼을 할당받을지를 나타냅니다. 이 값이 너무 작으면 메모리에 들고 있을 수 있는 Write의 양이 한정되기 때문에 디스크로 잦은 flush가 일어나게 됩니다. 반대로 너무 크면 GC에 문제가 있을 수 있으며 Read Cache로 할당할 수 있는 메모리를 낭비하는 것이기 때문에 좋지 않습니다.lowerLimit와 upperLimit의 두 가지 설정이 있는데, 두 개의 설정이 약간 다른 뜻입니다.만약 memstore 크기의 합이 lowerLimit에 도달하게 되면, Regionserver에서는 memstore들에 대해서 'soft'하게 flush 명령을 내리게 됩니다. 크기가 큰 memstore 부터 디스크에 쓰이게 되며, 이 작업이 일어나는 동안 새로운 Write가 memstore에 쓰일 수 있습니다.하지만 memstore 크기의 합이 upperLimit에 도달하게 되면, Regionserver는 memstore들에 대한 추가적인 Write를 막는 'hard'한 flush 명령을 내리게 됩니다. 즉, 해당 Regionserver이 잠시 동안 Write 요청을 거부하게 되는 것입니다. 보통 lowerLimit에 도달하면 memstore의 크기가 줄어들기 때문에 upperLimit까지 도달하는 경우는 잘 없지만, write-heavy 환경에서 Regionserver가 OOM으로 죽는 경우를 방지하기 위해서 hard limit가 존재하는 것으로 보입니다.hfile.block.cache.size와 hbase.regionserver.global.memstore.upperLimit의 합이 0.8 (80%)를 넘을 수 없게 되어 있습니다. 이는 아마 read cache 와 memstore의 크기의 합이 전체 Heap 영역 중 대부분을 차지해 버리면 HBase의 다른 구성 요소들이 충분한 메모리를 할당받을 수 없기 때문인 듯합니다.저희는 이 두 개의 설정 값을 각각 0.2, 0.3으로 해 놓았습니다. (20%, 30%)ipc.client.tcpnodelay / ipc.server.tcpnodelay / hbase.ipc.client.tcpnodelayHDFS의 tcpnodelay 와 비슷한 설정입니다. 기본값은 전부 false입니다.이 설정을 true로 하기 전에는 Get/Put 99%, 99.9% Latency가 40ms 와 80ms 근처에 모이는 현상을 발견할 수 있었습니다. 전체 요청의 매우 작은 부분이었지만, 평균 Get Latency가 1~2ms 내외이기 때문에 99%, 99.9% tail이 평균 Latency에 큰 영향을 미쳤습니다.이 설정을 전부 true로 바꾼 후에 평균 Latency가 절반으로 하락했습니다.Heap memory / GC 설정저희는 m2.4xlarge가 제공하는 메모리 (68.4GB)의 상당 부분을 HBase의 Read/Write cache에 할당하였습니다. 이는 보통 사용하는 Java Heap 공간보다 훨씬 큰 크기이며 심각한 Stop-the-world GC 문제를 일으킬 수 있기 때문에, 저희는 이 문제를 피하고자 여러 가지 설정을 실험하였습니다.STW GC time을 줄이기 위해서 Concurrent-Mark-and-sweep GC를 사용했습니다.HBase 0.92에서부터 기본값으로 설정된 Memstore-Local Allocation Buffer (MSLAB) 을 사용했습니다. hbase.hregion.memstore.mslab.enabled = true #(default)hbase-env.sh 파일을 다음과 같이 설정했습니다. HBASE_HEAPSIZE = 61440 #(60GB) HBASE_OPTS = "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps"GC log를 Python script로 Parsing해서 STW GC 시간을 관찰하고 있습니다. 지금까지 0.2초 이상의 STW GC는 한 번도 발생하지 않았습니다.그 밖에 도움이 될 만한 설정들hbase.hregion.majorcompactionHBase는 하나의 Region에 대해서 여러 개의 StoreFile을 가질 수 있습니다. 그리고 주기적으로 성능 향상을 위해서 이 파일들을 모아서 하나의 더 큰 파일로 합치는 과정을 진행하게 됩니다. 그리고 이 과정은 많은 CPU usage와 Disk IO를 동반합니다. 그리고 이때 반응 속도가 다소 떨어지게 됩니다. 따라서 반응 속도가 중요한 경우에는, 이 Major compaction을 off-peak 시간대를 정해서 manual 하게 진행하시는 것이 좋습니다.저희는 사용자의 수가 상대적으로 적은 새벽 시간대에 crontab 이 실행시키는 script가 돌면서 전체 Region에 대해서 하나하나 Major Compaction이 진행되도록 하였습니다.기본값은 86,400,000 (ms)로 되어 있는데, 이 값을 0으로 바꾸시면 주기적인 Major Compaction이 돌지 않게 할 수 있습니다.hbase.hregion.max.filesizeHBase는 하나의 Region이 크기가 특정 값 이상이 되면 자동으로 2개의 Region으로 split을 시킵니다. Region의 개수가 많지 않을 때는 큰 문제가 없지만, 계속해서 데이터가 쌓이게 되면 필요 이상으로 Region 수가 많아지는 문제를 나을 수 있습니다. Region 수가 너무 많아지면 지나친 Disk IO가 생기는 문제를 비롯한 여러 가지 안 좋은 점이 있을 수 있기 때문에, split 역시 manual 하게 하는 것이 좋습니다. 그렇다고 Table의 Region 수가 너무 적으면 Write 속도가 떨어지거나 Hot Region 문제가 생길 수 있기 때문에 좋지 않습니다.HBase 0.92.1 에서는 기본값이 1073741824(1GB)로 되어 있는데, 저희는 이 값을 10737418240(10GB)로 늘인 후에 manual 하게 split을 하여 Region의 개수를 조정하고 있습니다.hbase.hregion.memstore.block.multipliermemstore의 전체 크기가 multiplier * flush size보다 크면 추가적인 Write를 막고 flush가 끝날때까지 해당 memstore는 block 됩니다.기본값은 2인데, 저희는 8로 늘려놓고 사용하고 있습니다.dfs.datanode.balance.bandwidthPerSec부수적인 설정이지만, HDFS의 Datanode간의 load balancing이 일어나는 속도를 제한하는 설정입니다. 기본값은 1MB/sec로 되어 있지만, 계속해서 Datanode를 추가하거나 제거하는 경우에는 기본값으로는 너무 느릴 때가 있습니다. 저희는 10MB/sec 정도로 늘려서 사용하고 있습니다.dfs.namenode.heartbeat.recheck-intervalHDFS namenode에만 해당되는 설정입니다.Datanode가 응답이 없는 경우에 얼마 후에 Hadoop cluster로부터 제거할 것인지를 나타내는 값입니다.실제로 응답이 없는 Datanode가 떨어져 나가기까지는 10번의 heartbeat가 연속해서 실패하고 2번의 recheck역시 실패해야 합니다. Heartbeat interval이 기본값인 3초라고 하면, 30초 + 2 * recheck-interval 후에 문제가 있는 Datanode가 제거되는 것입니다.기본값이 5분으로 되어 있는데, fail-over가 늦어지기 때문에 사용하기에는 너무 큰 값입니다. 저희는 문제가 있는 Datanode가 1분 후에 떨어져 나갈 수 있도록 이 값을 15,000 (ms) 으로 잡았습니다.Read short-circuitRegionServer가 로컬 Datanode로부터 block을 읽어올 때 Datanode를 통하지 않고 Disk로부터 바로 읽어올 수 있게 하는 설정입니다.데이터의 양이 많아서 Cache hit이 낮아 데이터 대부분을 디스크에서 읽어와야 할 때 효율적입니다. Cache hit에 실패하는 Read의 Throughput이 대략 2배로 좋아지는 것을 확인할 수 있습니다. OLAP용 HBase에는 매우 중요한 설정이 될 수 있습니다.하지만 HBase 0.92.1-cdh4.0.1까지는 일부 Region이 checksum에 실패하면서 Major compaction이 되지 않는 버그가 있었습니다. 현재 이 문제가 해결되었는지 확실하지 않기 때문에 확인되기 전에는 쓰는 것을 추천하지는 않습니다.설정하는 방법은 다음과 같습니다. dfs.client.read.shortcircuit = true #(hdfs-site.xml) dfs.block.local-path-access.user = hbase #(hdfs-site.xml) dfs.datanode.data.dir.perm = 775 #(hdfs-site.xml) dfs.client.read.shortcircuit = true #(hbase-site.xml)Bloom filterBloom filter의 작동방식에 대해 시각적으로 잘 표현된 데모 페이지HBase는 Log-structured-merge tree를 사용하는데, 하나의 Region에 대해서 여러 개의 파일에 서로 다른 version의 값들이 저장되어 있을 수 있습니다. Bloom filter는 이때 모든 파일을 디스크에서 읽어들이지 않고 원하는 값이 저장된 파일만 읽어들일 수 있게 함으로써 Read 속도를 빠르게 만들 수 있습니다.Table 단위로 Bloom filter를 설정해줄 수 있습니다.ROW와 ROWCOL의 두 가지 옵션이 있는데, 전자는 Row key로만 filter를 만드는 것이고, 후자는 Row+Column key로 filter를 만드는 것입니다. Table Schema에 따라 더 적합한 설정이 다를 수 있습니다.저희는 데이터 대부분이 메모리에 Cache 되고 하나의 Region에 대해서 여러 개의 StoreFile이 생기기 전에 compaction을 통해서 하나의 큰 파일로 합치는 작업을 진행하기 때문에, 해당 설정을 사용하지 않고 있습니다.결론지금까지 저희가 비트윈을 운영하면서 얻은 경험을 토대로 HBase 최적화 설정법을 정리하였습니다. 하지만 위의 구성은 어디까지나 비트윈 서비스에 최적화되어 있는 설정이며, HBase의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.
조회수 3218

야놀자 앱은 왜 자동실행 되나요?

pluu 04 JUL 2018저는 야놀자 CX서비스실의 Android 파트에서 레이아웃 깎기와 Kotlin과 새로운 Android 기술을 전파하는 노현석입니다. 야놀자에 합류하고서 경험한 가장 독특한 케이스에 대해서 이야기해 보려고 합니다.시작은 물음표부터언제부터인가 야놀자앱을 설치하거나 업데이트하면 앱이 자동으로 실행된다는 리뷰가 들어오기 시작했습니다.네?! 그게 무슨 말이에요?안드로이드 개발을 시작한 이래로 처음 들어보는 내용이라, 원인도 정확한 해결책도 떠오르지 않는 그런 리뷰였습니다. 그래서 자연스럽게 브라우저를 켜서 구글에 검색을 먼저 해봤습니다. Android, Auto Start, Install 등 다양한 검색 결과로 일정한 패턴의 내용을 확인할 수 있습니다.  Intent Action 관련 내용android.intent.action.PACKAGE_ADDEDandroid.intent.action.PACKAGE_CHANGEDetc.Broadcast Receiveretc.일반적으로 안드로이드 앱이 설치 및 업데이트될 때 발생하는 이벤트(이하 Broadcast)를 받는 방법에 대한 설명이 많습니다. Broadcast는 배터리 변화, 전화 여부, 와이파이 등 시스템의 상태 변화를 감지하거나 서비스 내부적에서 이벤트를 전달하기 위해 사용합니다. ???? 실질적인 해결책은 되지 않지만, 범위를 좁혀서 찾아볼 포인트로 Intent 의PACKAGE관련 액션을 포커스로 잡았습니다. 하지만, 야놀자앱에서는 마케팅 성과 측정을 위해com.android.vending.INSTALL_REFERRER를 광고 트래킹 SDK에서 사용하는 것 이외에는 별도의 작업을 하지는 않습니다. 그러나, 이를 알 리가 없는 사용자는야놀자 앱이 일으키는 문제라고 인지하기 쉽습니다.  일차적으로, 어느 경로를 통해서인지는 모르지만 누군가가 야놀자 앱을 실행하는 것이라고 생각했습니다.야놀자 앱 사용자의 기기에 설치된 모든 앱 리스트를 받아올 수도 있고, 리퍼럴에 따른 앱 실행경로를 모두 수집할 수도 있지만, 단순히 버그를 찾기 위해 사용자의 동의 없이 정보를 수집할 수는 없기 때문에 장기전으로 돌입하게 되었습니다. 하지만 동일한 리뷰는 계속되었고 여전히 뚜렷한 해결책이 없는 채로 시간이 흘러갔습니다.  저 재현되는데요증상이 나타나지만 재현은 되지 않고, 재현 경로를 단기간에 파악하기는 어려운 과제였습니다. 한두 명에 불과하던 제보가 시간이 지날수록 Android 파트의 목을 조르듯이 점점 유입되는 횟수가 늘어만 갔습니다. 그런데 어느 날, 다른 팀의 분께서저 재현되는데요라는 한 줄기의 빛과 같은 언급을 해주셨습니다.믿고 싶지 않은 일이 현실이 되었다네? 그게 … 정말로 일어났습니다.이제부터가진짜시작역시버그는재현이되어야제대로잡을수있겠죠! 저에게는재현되는 단말이 있어요!Android에서 디버깅을 할 수 있는 다양한 수단이 있습니다. 이번 사례의 경우는Log혹은Dump를 확인해보는 선택지가 있습니다.Log민감한 정보라고 판단되는 부분은 모자이크했습니다.앱 설치 후 광고 SDK가 수집하는 것으로 보이는 Log에는 다양한 항목들이 나열되는 것을 볼 수 있습니다. 이때 설치한 앱의 정보가 SDK를 통해 특정 API로 전송되는 것도 확인할 수 있습니다. 하지만 Log는 Log일 뿐입니다.  Dumpsys이렇게 Log만으로 추적이 어려울 때, 추가적으로 시스템의 상태를 얻어내 디버깅 할 수 있는 방법이 있는데 바로dumpsys입니다. dumpsys는 Android 단말에서 실행되며 시스템 서비스에 대한 다양한 정보를 제공하는 도구입니다. ADB(Android Debug Bridge)를 사용하여 dumpsys를 호출 시 해당 단말에서 실행 중인 모든 시스템 서비스에 대한 정보를 가져올 수 있습니다. 간단하게 말하면 배터리의 잔량, 메모리 소비량, 네트워크 통신 상태 등을 명령어로 확인할 수 있습니다. dumpsys의 기능에 대해서는 방대한 설명이 필요하므로, 자세한 내용은 아래 링크로 대체합니다.  Android Developers ~ dumpsyshttps://android.googlesource.com/platform/frameworks/native/+/master/cmds/dumpsys/dumpsys.cppActivity DumpDumpsys 에서 좀 더 Activity 와 관련된 정보를 얻기 위해서는 아래의 명령어를 적용해볼 수 있습니다.// Activity Log Dump adb shell dumpsys activity activities 결과를 확인해봅니다. 아래와 같은 Activity 의 활동 이력을 얻을 수 있습니다.Activity Dump에 나타난mCallingPackage값으로 야놀자 앱을 시작시킨 앱의 패키지를 확인할 수 있습니다. 해당 패키지를 실제 Play Store에서 확인해본 결과, 사진 보정 필터앱으로 유명한카메라 앱중 하나였습니다.???? 야놀자와는 전혀 연관성이 없는 앱인데, 호출하고 있네요… ????Process ID// 애플리케이션의 Process ID 취득 adb shell ps Activity Dump에서 확인한mCallingUid는u0a423였는데, 이는 Activity를 호출한 uid 값을 가리킵니다. 실제로 Process 가 호출되는 Application ID도 카메라 앱에서 호출한 ID 정보와 일치합니다.대상 앱 자료 분석단순하게는 APK 를 분석하여 추측하는 방법이 있습니다. Android Studio 에서 제공되는Analyze APK기능을 이용하여 해당 앱에서 사용되는 서비스의 정보를 파악할 수 있습니다. 이 방법을 이용하여 문제의 앱이 사용하는 광고 SDK 서비스에서 패키지 설치/제거 관련 Broadcast Receiver를 수집하는 것을 확인 할 수 있습니다.패키지 관련 Broadcast인android.intent.action.PACKAGE_ADDED, android.intent.action.PACKAGE_REMOVED를 앱이 사용하는 것은 잘못된 것이 아닙니다. 예를 들어 런처 앱의 경우 단말기 내부의 앱 정보가 변경되었다는 이벤트를 이용하여 화면 렌더링 및 동작을 변경하는 처리를 할 수 있습니다 해당 광고 SDK의 경우에는 앱을 설치 및 실행하는 것으로 사용자에게 포인트 및 여러 혜택을 제공할 것이라고 예상할 수 있습니다.개인적인 의견으로는 사용자의 액션과 상관없이 동작하는 부분에 대해서는 분명히 Android 의 개선도 필요하다고 생각됩니다. 이런 정상 동작과 어뷰징은 아슬아슬한 경계에 있지만, 자칫 어뷰징으로 이어지는 경우 서비스의 품질이 떨어지게 되면서 사용자와 개발사 모두에게 좋지 않은 경험을 줄 뿐입니다.설마 이것도 되려나?동일 패키지명이번 포스팅을 작성하게 된 카메라 앱과 야놀자 서비스 사이에 특별한 관계가 없다면, 왜 이런 현상이 발생하는지 고민해봤습니다. SDK도 연결하지 않았다면, 앱을 추적할 수 있는 유일한 키는패키지명이지 않을까라는 생각으로 패키지명만 야놀자 앱과 동일한 샘플 앱으로 테스트해봤습니다.동일 재현 성공!!그럼… 해결… 끝?많은 사람들에게 이름이 널리 알려진 여러 서비스에서조차 이번 포스팅에서 다룬 내용과 같은 현상이 발생하고 있습니다. 발생 유무에 따른 차이점이나 현상의 인과 관계를 명확히 판단하기엔 아직 정보가 많이 부족합니다. 그리고 이번 분석에서 발견한 문제의 앱을 비롯하여 또 다른 제2, 제3의 앱들이 등장할 거란 가능성도 배제할 수 없는것이 현재 상황입니다. 슬프게도 아직 이 현상은 지금도 계속되고 있으며, 불편을 호소하는 리뷰가 등록되어 서비스 전체의 이미지와 평점을 갉아먹고 있습니다. 안드로이드 생태계가 사용자 및 서비스 제공자에게 더 유익한 방향으로 나아갔으면 하는 바람을 담아 작성했습니다.도움 주신 분동일 증상을 발견하고, 단말을 빌려주신 R&D SF팀 전호숙님같이 추적해주신 R&D CX 서비스실 유관종님Dump/Log 관련 조언을 주신 Wind River의 차영호님 (????????????)국어가 많이 부족한 저를 도와주신 리뷰어 ???????????? R&D CX 서비스실 강미경님, 송요창님, 유관종님, 유용우님, 이미혜님이번 현상 추적에 도움을 주신 분들에게 감사함을 전합니다.#야놀자 #개발자 #개발팀 #문제해결 #버그수정 #안드로이드 #인사이트 #경험공유
조회수 1114

Vue, 어디까지 설치해봤니?

Overview새로운 사용환경 구축에 도전하는 건 개발자의 운명과도 같습니다. 오늘은 여러 장점을 가지고 있는 Vue (프론트엔드 자바스크립트 프레임워크)를 도전해보겠습니다. Vue는 다른 프레임워크에 비해 가볍고, 개발하기에 편합니다. 그럼 우선 Vue를 설치합시다! Vue 설치CDNhttps://unpkg.com/vue 주소를 script 태그에 직접 추가 Vue.js 파일다운개발용, 배포용 버전을 다운 받아 script 태그에 추가개발용 버전은 개발에 도움이 되는 모든 경고를 출력하기 때문에 개발 중에만 사용하고, 실제 서비스에서는 배포용 버전으로 사용해야 한다. NPM 설치규모가 큰 프로젝트 경우 컴포넌트별 독립적으로 관리할 수 있는 싱글 파일 컴포넌트 방식 추천 Vue를 설치하는 방법은 여러 가지가 있습니다. 각자 특성에 맞게 편리한 방법으로 설치해주세요. 이번 글에서는 싱글 파일 컴포넌트 방식을 사용할 것이므로 NPM vue-cli 를 설치해 프로젝트를 구성하겠습니다. # vue-cli 전역 설치, 권한에러시 sudo 추가 $ npm install vue-cli -global vue-clivue-cli를 사용하면 뷰 애플리케이션을 개발하기 위한 초기 프로젝트 구조를 쉽게 구성할 수 있습니다. 다만, 싱글 파일 컴포넌트 체계를 사용하려면 .vue 파일을 웹 브라우저가 인식할 수 있는 형태의 파일로 변환해 주는 웹팩(Webpack)이나 브라우저리파이(Browserify)와 같은 도구가 필요합니다. vue-cli 설치 명령어 vue init webpack : 고급 웹팩 기능을 활용한 프로젝트 구성 방식. 테스팅,문법 검사 등을 지원vue init webpack-simple : 웹팩 최소 기능을 활용한 프로젝트 구성 방식. 빠른 화면 프로토타이핑용vue init browserify : 고급 브라우저리파이 기능을 활용한 프로젝트 구성 방식. 테스팅,문법 검사 등을 지원vue init browserify-simple : 브라우저리파이 최소 기능을 활용한 프로젝트 구성 방식. 빠른 화면 프로토타이핑용vue init simple : 최소 뷰 기능만 들어간 HTML 파일 1개 생성vue init pwa : 웹팩 기반의 프로그레시브 웹 앱(PWA, Progressive Web App) 기능을 지원하는 뷰 프로젝트여러 설치 명령어 중에 특성에 맞는 초기 프로젝트를 생성하세요. 1) vue init webpack 실행# 해당 프로젝트 폴더에서 실행 $ vue init webpack   # 현재 디렉토리에서 프로젝트 생성 여부 ? Generate project in current directory? (Y/n) # 프로젝트 이름 ? Project name (vue_ex) # 프로젝트 설명 ? Project description (A Vue.js project) # 프로젝트 작성자 ? Author (곽정섭 ) # 빌드 방식 ? Vue build (Use arrow keys) # vue-router를 설치 여부 ? Install vue-router? (Y/n) # 코드를 보완하기 위해 ESLint를 사용 여부 ? Use ESLint to lint your code? (Y/n) # ESLint 사전 설정 선택 ? Pick an ESLint preset (Use arrow keys) # 단위 테스트 섧정 ? Set up unit tests (Y/n) # 테스트 러너 선택 ? Pick a test runner (Use arrow keys) # Nightwatch로 e2e 테스트를 설정 여부 ? Setup e2e tests with Nightwatch? (Y/n) # 프로젝트가 생성 된 후에`npm install`을 실행해야합니까? ? Should we run `npm install` for you after the project has been created? (recommended) (Use arrow keys) 2) 고급 웹팩 기능을 활용한 프로젝트 구성 방식으로 설치3) 설치완료4) package.json 파일에 설정된 라이브러리 설치$ npm install 5) 개발모드 실행# 해당 프로젝트 폴더에서 실행(소스수정시 자동 새로고침) $ npm run dev 6) http://localhost:8080/ 브라우저 실행7) Yeah, You got it!!!!추가 도구: Vue Devtools(크롬 확장 플러그인)Vue Devtools(크롬 확장 플러그인)은 Vue를 사용할 때, 브라우저에서 사용자 친화적으로 검사하고 디버그할 수 있습니다.크롬 개발자 도구에 Vue 탭이 추가됨ConclusionVue를 설치하는 여러 방법 중 고급 웹팩 기능을 활용한 프로젝트 구성을 알아봤습니다. 다음 글에서는 Vue 인스턴스 및 디렉티브(지시문) 사용법을 다뤄보겠습니다.참고설치방법 — Vue.js 글곽정섭 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #Vue

기업문화 엿볼 때, 더팀스

로그인

/