스토리 홈

인터뷰

피드

뉴스

조회수 1438

스타일쉐어에서 이미지 분류하기 (시작 편) feat.ML

안녕하세요.스타일쉐어에서 백엔드 개발을 하고 있는 김동현입니다.작년 11월 스타일쉐어에서 뷰티에 관련된 사진들을 따로 모아서 보여줄 피드.바로 뷰티피드 라는 것을 만들었습니다. 하지만 피드를 만드는 과정이 순탄치 만은 않았는데요.그간의 과정과 얻었던 경험들을 공유하고자 합니다.들어가기에 앞서혹시 설명을 하다 보면 스타일쉐어에서만 사용되는 단어가 있을 수 있다는 생각이 들어 단어에 대한 공유를 먼저 드리고자 합니다.스타일쉐어에서는 이를 “피드”라 칭합니다.스타일쉐어에서는 이를 “스타일”이라 칭합니다.여러 가지 카테고리 중에서 왜 뷰티인가요?기존의 서비스에서는 유저들이 올리는 스타일에 대한 카테고리가 없어서 유저들이 보고 싶어 하는 스타일들을 쏙쏙 뽑아서 보여줄 수 없는 상황이었지만 “내가 보고 싶은 것들만 볼 수 있었으면 좋겠다”라는 유저들의 니즈는 계속 올라가고 있었습니다.서비스 특성상 1020 유저들이 많이 있었고 하루 동안 올라오는 스타일에 대해서 사람이 직접 카테고리를 하나하나 나눠봤을 때 가장 활발하게 대화가 이루어지고 반응이 좋고 충성도도 높은 카테고리가 바로 뷰티였습니다.뷰티만이라도 따로 보여줄 수 있도록 해보자그럼 어떻게 뷰티에 관련된 게시물들을 뽑아낼 건가요?올라오는 스타일들 중에서 뷰티라는 속성을 찾아내어 분류하는 방법으로 두 가지의 제안이 나왔습니다.1. 사람이 직접 뽑아낸다.2. 요즘 뜨고 있는 딥러닝을 이용해서 뽑아낸다.처음엔 사람이 직접 모니터링 해볼까? 라는 이야기가 나왔었습니다.당장이라도 시작 할 수 있다는 점과 높은 정확도를 가졌다는 장점이 있기 때문이였죠.하지만 주말 관계없이 4000~6000개씩 올라오는 스타일들을 상시 모니터링하고 모두 검토해야 하는 상황이 너무 막막하게 느껴졌습니다. 관련 업무를 하시는 분의 업무 만족도는 낮을 것이 당연하기도 했지만 그럴만한 인적자원이 충분하지 않았습니다.그래서 요즘 뜨고 있는 딥러닝을 이용해보자는 방향으로 일이 진행되었습니다. 게다가 요즘 딥러닝으로 Image Classification 하는데에 있어서 정확도가 사람을 넘어섰다는 이야기도 결정에 한몫을 했답니다.딥러닝으로 분류하기로 결정했다! 근데 트레이닝 셋은?딥러닝을 하시는 분들이 애용하는 사이트인 캐글만 가보아도 문제와 트레이닝 셋이 잘 정리되어있기에 개발자는 어떻게 하면 잘 예측할 수 있을까에 대한 고민만 했으면 되었었습니다. 하지만 당연하게도 실제 필드에서 처리해야 하는 문제와 그에 대한 트레이닝 셋은 존재하지 않았습니다.우선 딥러닝으로 분류하기로 결정을 하였으니 서비스에서 뷰티라는 카테고리 안에 넣을 소카테고리를 나누었고 다음과 같았습니다.* 눈 화장 관련* 입술 화장 관련* 얼굴 화장 관련* 헤어* 화장품* 발색* 네일그래도 태양 아래 새로운 것은 없다 라는 말처럼 비슷한 것들이 존재할까 하고 찾아보았으나…https://www.kaggle.com/openfoodfacts/openbeautyfactshttp://www.antitza.com/makeup-datasets.htmlㅇ…없잖아?!그렇습니다. 공개된 것은 없던 새로운 것이었습니다. 위의 소카테고리들을 모으는 방법을 모색해야 했습니다.위에서 언급했듯이 잉여 인적자원이 없었기 때문에 몇만 개의 데이터를 모을만한 데이터를 모으는 일은 저를 포함해서 개발자 2명이서 진행을 했었습니다.그래서 결국 뷰티 피드는…성.공.적.다행히도 잘 마무리되었습니다. 화자 되고 있는 딥러닝 기술을 실제로 사용해볼 수 있어서 좋았고 팀원들도 이게 되는구나, 다른 것도 해볼 수 있겠다 라는 피드백을 많이 받았고 저 또한 개발을 하면서도 이게 된다고? 하는 반응이 제일 많았던 것 같습니다. 물론 앞으로 모델을 계속 개선해나가야겠지만요.사실 딥러닝을 거의 처음 공부하는 수준에 가까웠고 초반에 우왕좌왕 하기도 많이 했었는데 믿고 기다려줬던 스타일쉐어 팀원 분들 덕분에 잘 마무리될 수 있었던 것 같습니다.분류와 트레이닝 셋에 대한 좀 더 자세한 글은 다음 포스팅 (분류 편)에서 찾아뵙겠습니다.#스타일쉐어 #개발팀 #개발자 #개발후기 #경험공유 #인사이트
조회수 838

크로키닷컴을 소개합니다 #5

지그재그 채용 페이지>> https://career.zigzag.kr오늘은 지그재그 서비스를 위해 각자의 파트에서 이끌어주시는 개발자 두 분! Dev. 팀의 정수님, 형래님과 함께 활발히 채용 중인 [백엔드 개발자]에 대해 파헤쳐 보도록 하겠습니다 :-)Chapter 1. 저를 소개합니다!Q. 정수님, 형래님 반갑습니다! 지난 인터뷰를 통해 궁금한 포지션으로 백엔드 개발자가 선정되었는데요! 인터뷰이로 선정된 간단한 소감과 자기소개를 부탁드립니다.정수, 형래 네.. 좋네요.(기뻐하지 않으시는군요! 저희의 예상과 다르게..)형래 일단은 왜 제가 첫 번째로 인터뷰이가 되지 않았는지 굉장히 서운하게 생각하고요.(웃음) 그래도 지그재그에서 이런 인터뷰를 해보는구나 싶네요.정수 저는 전형적인 부끄러움이 많은 개발자라서요. 부담도 많이 가고, 긴장되네요. '잘해야 되겠다.'라는 생각이 마구 듭니다.(웃음)형래 저는 자기소개를 준비해 왔어요! 사실 제가 6-7년 전부터 사용하고 있는 건데요, 저를 '줄기세포 개발자'라고 표현합니다. 줄기세포가 아무 데나 이식이 된다고 하더라고요. 그래서 저를 개발이 필요한 곳에 가져다 두면 개발을 하고, 매니징이 필요한 곳에 가져다 두면 매니징도 하다가.. 인프라가 필요한 곳에 가면 인프라도 해요. 가리지 않고 다 해서 다른 사람들이 물어보면 '줄기세포 개발자'라고 말하고 다닙니다.우리의 소중한 디에네이 형래님정수 저는 지그재그의 Z결제라는 기능에서 주문과 결제, 물건을 받아보기까지의 과정을 책임지고 있어요. 좋은 개발자가 되기 위해서는 공부가 필수라고 생각하는데요, 개발 기술뿐만 아니라 본인이 만들어가는 제품과 서비스에 대해서도 항상 열심히 공부해야 된다고 생각합니다. 지금 담당하고 있는 업무도 결제 서비스에 대한 지식이 사실상 전무한 상태에서 시작했는데, 많이 찾아보고 공부도 하면서 열심히 만들어가고 있어요.형래 제가 담당하고 있는 역할에 대해서도 말씀드릴게요. Z결제 쪽은 정수님께서 맡아주고 계시고, 저는 그 외에 지그재그 서비스 전반에 있어서 사용자의 UX를 개선하거나 쇼핑몰을 연동하는 등의 서버 개발을 담당하고 있어요.Q. 정수님은 크로키닷컴 초창기 멤버이셨다가 재입사를 하신 거고, 형래님은 K모 대기업을 다니시다가 지그재그에 합류하셨다고 들었어요. 두 분 다 지그재그를 선택하신 특별한 이유가 있었나요?정수 처음 입사했던 건 2012년이었어요. 그땐 지그재그 서비스가 아닌 다른 서비스들을 개발할 때였고요. 그때 한창 스타트업 열기가 모락모락 피어오를 때였는데, 스타트업에서 새로운 걸 해보겠다는 도전정신을 가지고 합류하게 됐고 거의 2년 가까이 함께 했었던 것 같아요. 그러다가 창업을 하려고 떠났었는데, 그 후 몇 년 만에 크로키닷컴이 지그재그 서비스를 오픈하고 급격하게 성장하고 있더라고요. 함께 일했었던 기억도 너무 좋았고, 지그재그라는 서비스도 앞으로 할 수 있는 것들이 많을 것 같아 너무 매력적으로 다가왔던 것 같아요. 그래서 2018년에 다시 합류해서 열심히 다니고 있습니다.형래 저는 우연히 쟈니님(CEO), 정훈님(COO)과 저녁을 먹었었는데, 그때 얘기해주셨던 지그재그 서비스가 너무 궁금하고 직접 경험해보고 싶었어요. 사실 대기업을 퇴사하게 된 이유가 스타트업을 창업해보고자 했거든요, 물론 잘 안됐지만.. 그때 저는 '잘 되는 스타트업은 어떻게 해서 잘 될 수 있었을까?'라는 궁금증이 항상 있었어요. 저녁을 같이 먹으면서 두 분이 지그재그 서비스에 대해 말씀해 주셨을 때 두 분의 엄청난 열정과 확신이 느껴졌고, 저도 그 두 분 못지않은 열정을 지닌 사람이라는 것을 보여주고 싶다는 생각이 들었어요. 그래서 저녁 먹은 다음날인가? 바로 연락드렸어요, 합류하겠다고.(웃음) 저는 자신 있었거든요.지그재그 개발팀의 컨피던스(오 그런 비하인드가 있었군요! 그럼 실제로 입사 후에 경험한 지그재그 팀은 어떠셨나요?)형래 지그재그 팀은 다른 회사들과는 약간 다르게, 극단적으로 사용자의 편의성에 치중해요. 음.. 고객의 입장에서 봤을 땐, 업자의 욕심이 느껴지지 않는다고 해야 하나? 직접 와서 겪어보니 역시나 그랬고요. 이러한 마인드가 우리 서비스에 긍정적인 효과를 많이 가지고 온다고 생각합니다.(그럼 정수님은 이전의 회사의 모습과 지금의 회사의 모습이 어떻게 달라졌다고 느끼시나요?)정수 처음은.. 5명이었을 때였어요. (지금은 무려 97명!) 지금이나 그때나 모두 열정이 넘치는 건 같아요. 다만 방향성이 다른 에너지죠. 예전에는 서비스가 빨리 좋은 반응을 얻지 못하면 회사가 망할 수도 있다는 위기의식을 가지고 소수의 멤버들과 더 끈끈하게 열정을 가지고 하루하루에 임하는 느낌이었어요. 반면에, 지금은 지그재그 팀이 그동안 쌓아온 탄탄한 기반을 바탕으로 새로 도전해볼 수 있는 다양한 과제들이 훨씬 더 많이 기다리고 있고, 그 과제들을 하나씩 함께 해결해나갈 팀원들도 많아져서 그 에너지가 나날이 더 커지는 것 같아요. Q. 두 분의 경력을 합쳐보니 240개월 이더라고요! 그만큼 다양한 회사를 경험해보셨을 것 같은데요. 유독 지그재그 팀만이 지닌 특이한 점이 있다면 소개해주세요!항상 열정 넘치는 Dev. 팀!형래 이전 회사들은 사실 경험이 많은 사람들만 뽑았어요. 아무래도 경험이 많이 쌓이다 보면 점점 더 나에게 편하고 익숙한 방식을 찾아 문제를 해결하려는 유혹에 빠지기가 쉬운 것 같아요. 물론 경험이 쌓여도 새로운 것에 대해 계속 공부하고 고민하시는 분들도 많이 계시지만, 절대 쉬운 일은 아니죠. 근데 지그재그 팀에는 비록 경험은 조금 적은 편인 분들이 많이 있어도, 옆에서 보고 있으면 항상 열정이 넘치는 사람들이에요. 매 순간 공부를 하려고 하거든요. '어떻게 하면 내가 성장할 수 있을까?'라고 생각하는 사람들이 대부분이라 개인적으로 신기하기도 합니다. 정수 저는 급성장하고 있는 회사에서 일해본 건 지그재그 팀이 처음이에요. 생소하기도 하고, 지루할 틈이 없어요.(웃음) 지금도 매우 빠르게 성장하고 있습니다.Chapter 2. 우리는 이렇게 일해요!Q. 두 분은 파트 내에서 추구하는 특별한 업무 방식이 있으신가요?형래 결함을 최대한 앞 단계에서 찾자! 이게 저희 팀 콘셉트이에요. 설계 단계에서 찾은 오류를 의논해서 해결하고 나면 훨씬 손이 덜 들거든요. 아무리 바쁘더라도 Scrum 을 꼭 진행하고 있습니다. 또, 개발하고 있는 서비스에 대한 품질도 더욱 높이기 위해서 Iteration 작업도 새로 제안해서 정착 단계에 있어요.(파트 매니저로서는 중요하게 강조하는 업무 방식이 따로 있나요?)형래 각 팀원이 하나의 일을 맡으면, 그분을 최대한 안 괴롭히는 게(?) 제 원칙이에요. 팀원들이 일에 집중할 수 있게끔 도와주는 게 매니저의 가장 큰 일이라고 생각하거든요. 그러다 보니 다른 팀 팀원 분들이 커뮤니케이션적인 부분에서 약간 불편해하셔서, 그 부분을 해결하기 위해 요즘 가장 노력하고 있어요.정수 저희는 기록을 강조하고 있어요. 지금 저희 파트에서는 결제라는 새로운 기능을 개발하고 있다 보니까 기록을 남기지 않고 그냥 일을 진행하다 보면 혼선이 생기기 마련이거든요. 다 같이 붙어서 만들고 있으니, 기록을 하면서 개발하는 걸 강조하고 있습니다.(그렇다면 두 분은 파트의 팀워크를 향상하기 위해 노력하고 계시는 부분이 있을까요?)정수, 형래 음 팀워크는.. 법카에서 나온다? 농담이고요. (웃음)형래 조금 식상한 얘기일 수도 있는데, 저는 각자 role이 다르다고 생각해요. 제가 윗사람이고 팀원들이 아랫사람인 것이 아니라, 전 매니징 하는 역할을 가지고 있고 팀원들은 또 다른 각자의 역할을 가지고 있는 거라고요. 그렇게 각자 역할이 다른 거라고 항상 말씀드리면, 팀원들도 평소에 본인의 의견을 좀 더 자유롭게 이야기할 수 있는 것 같고 결과적으로 좀 더 책임감을 가지고 일할 수도 있고 재미도 느끼는 것 같아요. 다만 제가 팀원들이랑 나이차가 좀 나는 바람에.. 아무래도 어려워하시는 분도 계셔서 앞으로 더 많이 노력해야 할 것 같네요. 제가 제대할 때 태어나신 분도 계시거든요.(웃음) 정수 저희 파트에서는 태스크마다 다른 팀원과 짝을 지어서 같이 진행하는 방식을 적용해보고 있어요.그중에서 특히나 강조하는 건 '각자의 장단점이 다르니 서로의 장점을 잘 활용하고 단점을 보완해주자'는 건데요, 그러기 위해 여러 시도들을 해보면서 경험을 쌓아가는 중입니다. Q. 지그재그에서 겪는 백엔드 개발자로서 좋은 점과 어려운 점이 있으신가요?정수 보통 큰 회사에서는 개발자가 서비스의 시작부터 끝까지 모두 경험해볼 수 있는 기회가 흔하지는 않은 것 같아요. 그런데 지그재그 팀에서는 처음 기획 단계부터 함께 참여하고 만들어나가는 경험을 해볼 수 있어요. Z결제도 마찬가지였고요. 앞으로도 새로 도전해나가야 하는 과제들이 많아서, 본인이 주도적으로 이끌어서 개발할 수 있는 기회가 많은 게 가장 좋은 점인 것 같아요.형래 어려운 점은 우리가 아직은 메타 서비스에서 커머스로 변화해가는 과정이다 보니, 서비스에 우리만의 색깔을 담아내거나 편의성을 맞춰나가는 부분이 어려운 것 같아요. 하지만 날이 지날수록 점점 맞춰지고 있는 것 같아요, 그만큼 회사가 성장하고 있다는 거겠죠? 아! 그리고 우리는 typescript와 node.js라는 기술을 사용하고 있는데, 아직 많이 사용되는 기술은 아니라 경험해보지 않은 분들은 어려워하실 수 있지 않을까 싶어요. 그래도 새로운 기술에 대해 거부감 없이 호기심을 가지고 적극적으로 배우려고 하시는 분이라면, 지그재그 팀이 사용하는 기술도 금방 익혀서 사용하실 수 있을 거예요. 저도 입사하고 나서 많이 배웠거든요.(웃음)열심히 작업 중이신 형래님! (Feat. 형래님 얼굴이 그려진 텀블러)Chapter 3. Dev. 팀은 이런 분을 찾아요!Q. Dev. 팀에서 찾는 백엔드 개발자는 어떤 분인지 설명 부탁드려요!정수, 형래 우선, 우리 회사는 실험적인 회사이기 때문에 개발에 재미를 붙이고 일하실 수 있는 분이면 좋겠어요. 그리고 기술에 대한 근본적인 이해가 필요한 것 같아요. 그 언어의 특징이 무엇이고, 본인이 왜 이 언어를 사용했는지에 대해 설명해줄 수 있어야 한다고 생각하거든요. 혹은 자기가 만든 프로젝트를 얼마나 깊이 있게 고민해보고 만들었는가에 포커스를 많이 둡니다. 솔직히 말씀드리면, 차이가 나요! 깊이 있게 고민하면서 만들어보신 분들은 이미 몇 년이 지난 프로젝트라고 하더라도 바로 어제 일처럼 설명을 잘하시거든요.Q. 백엔드 개발자 예비 지원자분들께 하고 싶은 말씀이 있으신가요?형래 사실 인터뷰에서 떨어지는 건 본인의 실력이 부족해서라기 보다는, 회사의 성향과 맞지 않아서인 확률이 매우 커요. 그러니 인터뷰 때 너무 긴장하지 마시고, 편하게 본인의 모습을 어필해주셨으면 좋겠어요. 서류 지원도 편하게 해 주셨으면 좋겠고요, 각자의 fit이 지그재그와 잘 맞는지 확인하는 하나의 절차니까요.정수 형래 님이 아까 말씀하신 것 중에, 우리 팀은 '실험적인 시도를 하는 회사'라고 하셨잖아요. 현재보다 더 나은 시스템을 만들기 위한 노력 중에 하나라고 봅니다. 항상 지금에 만족하지 않고 더 나은 시스템을 구현하기 위해 노력하고 있거든요. 본인이 더 나아가고 싶은 길이 있다면 저희 회사와 정말 잘 맞을 거예요!Chapter 4. 마무리Q. 2020년 두 분의 목표가 있으신가요?정수, 형래 좋은 분들을 많이 영입하자!형래 저는 벌써 세 분이나 소개해서 모셔왔는데요, 더 열심히 노력할 예정입니다. 그리고 개인적인 목표는 건강을 유지하자는 겁니다. 더 건강해지는 것은 바라지도 않아요..정수 저도! 작년에는 많이 아팠어요.형래 그리고 회사에 초코류 간식이 많아서, 제 건강을 위해 건자두 같은 자연식품(?) 위주로 많이 사다주시면 제 건강에 많은 도움이 되지 않을까 싶은 소소한 바람입니다.(웃음)Relations팀: 건...ㅈㅏ..두... for.... 형ㄹㅐ.. 정..수...님....Q. 다음으로 인터뷰를 진행했으면 하는 팀이 계신가요? 궁금한 팀이 있으면 말씀해주세요!정수, 형래 마케팅 팀이요. 우리 회사 마케팅 팀이 워낙 잘하고 계시는 것 같다고 입사 전부터 느꼈거든요. 팀에서 어떻게 일하시는지 궁금해요!지그재그에서는 백엔드 개발자를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 [email protected] 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [백엔드 개발자] 포지션을 소개합니다!이런 일을 합니다.이런 분을 모십니다.이 중 하나라도 가능하시다면 더더욱 좋아요 :)지원 방법채용 절차혜택과 복지   더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기
조회수 1427

AWS, Kubernetes 그리고 WAF

모니터링을 지속적으로 강화하다 보니 사용자 약관에 어긋나게 행동하는 주체가 눈에 띄기 시작한다. 특정 시간대에 판매 목록을 긁어가려고 시도하는 크롤러가 대표적이다. 비정상적인 서비스 이용을 탐지한 건 좋은데 이를 어떻게 차단할지가 또 고민이다. 차단 방법이야 많지만 가급적유지보수가 쉽고현재 서비스 구조에 살짝 얹기만 하면 되는그런 멋진 구조가 없을까 잠시 조사를 해보았다. 결론적으로는 현재 우리의 구조에선 1시간만 작업하고 펑펑 놀아도 되는 그런 방법은 없었다. 하지만 조금만 더 참고 기다리면 꽤 괜찮은 접근방법이 있을 것도 같더라. 우선 현 상황을 보자면 우리의 인프라는 주로Kubernetes가 서비스의 90% 이상을 통제하며웹 서비스는 주로 AWS ELB를 통해 인터넷 망에 노출한다.그러니 이론상으로는 AWS의 WAF, 그러니까 Web Application Firewall을 이용하면 손 안대고 코 풀기가 딱이다. 하지만 문제가 하나 있으니!!!AWS WAF는 ELBv2 그러니까 Application Load Balancer만 지원하는데 Kubernetes 1.5.x는 ELBv1만 지원한다. AWS WAF가 L4 로드밸런서인 ELBv1을 지원하던가 Kubernetes가 AWS ELBv2도 External Load Balancer로 선택가능하게 지원하던가 해야 Kubernetes + AWS ELB + WAF를 조합할 수 있다. 이 문제만 해결되면 금방 적용가능한 구성이라 매우 땡긴다. 설사 Kubernetes이 ELBv2는 지원하되 WAF 연동을 지원하지 않더라도 이를 수행하는 Kubernetes 플러그인을 개발하는 건 이틀이면 충분하지 싶다.왜 WAF인가?그러고 보니 여태 왜 이런 구성이 제일 낫다고 생각하는지 설명하지 않았다. 웹애플리케이션 방화벽을 구현하는 방법이야 AWS WAF 말고도 많지만 이러한 구성에는 분명한 장점이 있는데IP 평판 목록을 수집해서 한데 정리하는 서비스를 AWS가 제공하기 때문에 내가 이걸 구현한다고 시간낭비할 필요 없고매우 간단한 구조라서 처음 설치하고 설정하는데 30분에서 1시간이면 족하고Classless Inter-Domain Routing (CIDR) 표기법을 지원하므로 특정 아이피 대역을 막는 건 일도 아니며무엇보다 내가 관리하는 평판 목록도 쉽게 추가할 수 있다.이러니 “굳이 다른 솔루션을 찾아서 생고생해야 하나?”라는 생각이 들 수밖에 없다.다른 읽을꺼리How to Import IP Address Reputation Lists to Automatically Update AWS WAF IP Blacklists: AWS WAF의 구조와 WAF를 CloudFront에 적용하는 방법을 설명한다.AWS WAFがALB(Application Load Balancer)で利用出来るようになりました: AWS WAF를 ELBv2에 적용하는 방법을 설명한다.Akamai — Protect your organization with a web application firewall.Originally published at Andromeda Rabbit.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트
조회수 730

챗봇과 인공지능 머신러닝 - Part 2/2

지난 시간에 이어 오늘은 챗봇에게 지능을 주는 방법에 대해 알아본다. 공부를 해보시면 아시지만 공부란 어느정도 양이 많아지면 가속이 붙는다는 것을 학창시절에 경험 하셨을 것이다. 즉, 공부를 잘하는 사람은 조금만 해도 더 잘한다. 아무것도 아는게 없는 상황이라면 무조건 머리에 넣는 것도 방법이다. 물론 그 후에는 외운 지식의 의미에 대해 깊은 사고가 필요하지만.  챗봇한테도 이런 사람에 통하는 방식이 그대로 적용된다.지도학습은 규칙이나 사례를 구조화된 형식으로 표현하고 이를 컴퓨터에 입력해 놓는 방식이다. 단점은 한 분야의 지능을 다른 분야에 재사용할 수 없기 때문에 분야별로 다시 개발해야 한다는 데 있다. 아! 주입식 교육의 한계.한편, 자율학습은 인간의 뇌처럼 컴퓨터도 동일하게 데이터간의 연결 상태와 강도로 지식을 보유하도록 하는 방식이다. 이 방식의 대표적인 예가 인공 신경망(Artificial Neural Network)으로 스스로 학습할 수 있다는 점이 가장 큰 장점이다. 대량의 데이터에서 스스로 특징을 추출한다. 최근에는 딥러닝(Deep Learning)이라는 방법을 이용하여 자연어 인식, 영상인식, 음성 인식 등에서 과거엔 손도 못 대던 일을 하고 있다.인공신경망 활용을 위한 두 가지 조건인공신경망의 장점을 살리기 위해선 두 가지 큰 장벽을 넘어야 한다. 첫째는 자율학습 알고리즘을 개발하는 것이다. 둘째는 필요한 양질의 데이터를 대규모로 확보하는 것이다. 인공신경망 개발툴은 구글이나 마이크로소프트 등이 무료로 공개하고 있으므로 데이터 공학자, 프로그래밍 전문가, 응용수학자, 기획자 등과 함께 팀을 구성하면 개발을 시작할 수 있다. 그러나 실제에 있어서 가장 큰 난관은 두 번째로 지적한 대규모 데이터의 확보에 있다. 데이터를 가진 자가 승자라는 말이 있을 정도로 데이터가 중요하지만 이를 확보하는 것은 쉽지 않다. 학습 알고리즘이 있어도 데이터의 질이 떨어지거나 데이터의 수량이 적다면 자율학습이 제대로 될 수 없기 때문이다. 아! 머리에 든게 충분히 있어야 딥러닝이 가능하다.기술력보다는 기획력이 중요한 챗봇챗봇은 텍스트 형식의 글자를 통해 사람과 기계가 소통하는 방법이므로 앞에서 언급한 머신러닝 기술 중 자연어 처리(NLP)와 자연어 인식(NLU)이 필요해진다. 아! 정말 알아야 할 게 많다. 간단히 설명하면 NLP에는 형태소분석, 구문분석이 포함되고 NLU는 여기에 사용자 의도 해석과 실제 상황처리가 필요한 문맥이해까지 포함된다. 누구나 알다시피 조사, 접사 등이 발달한 한국어는 텍스트 처리가 영어에 비해 쉽지 않다고 한다. 로봇한테 사람처럼 말귀를 알아듣게 하는 작업이란 이렇게 어려운 일이다.실무에서의 챗봇 서비스는 기술력도 중요하지만 어떤 컨텐츠를 가지고 어떻게 서비스 할지에 대해 더 고민해야 한다. 역시 대화란 사람에 대한 이해가 중요한 만큼 초기단계에서 좋은 데이터 축적을 위해 규칙기반의 룰을 잘 선정하고 이를 머신러닝 기법과 잘 융합하는 유연성이 필요하다. 또 데이터 크기가 작을 때에는 딥러닝 보다 SVM(Support Vector Machine)류의 머신러닝이 더 좋은 성능을 보인다. 또 오버피팅 문제로 인해 학습 시 많은 데이터 사용이 꼭 성능증가로 이어지지도 않는다. 오히려 도메인 지식과 기획력 및 간단한 세션관리로도 좋은 품질의 챗봇을 만들 수 있다고 본다. 아울러 초기기술을 계속적으로 축적하면서 차근차근 지속적으로 업그레이드 해 나간다면 누구나 그 컨텐츠 영역에서 훌륭한 챗봇 친구를 얻을 것이다.맺는말이상으로 간단하게 챗봇에 대해 지극히 개인적인 의견을 올려봤다. 깊이 들어가면 한이 없는 분야지만 제 4차 산업혁명을 맞이하여 필연적으로 우리와 함께 살아갈 수밖에 없는 스마트폰 안에 있는 로봇인 챗봇에 대해 모든 사람들이 더욱더 관심을 가졌으면 한다.
조회수 4543

오픈소스 라이브러리를 사용해보자, CocoaPods! (KOR)

Overview개발 도중 내용이 복잡하거나 소스가 길면 종종 오픈소스 라이브러리를 사용합니다. 쉽게 원하는 기능을 구현할 수 있기 때문이죠. 그렇다면 오픈소스 라이브러리는 어떻게 앱에 가져와서 사용할까요? 바로 ‘CocoaPods(이하 코코아팟)’을 쓰면 됩니다.What is CocoaPods?코코아팟의 공식 웹사이트에서는 코코아팟을 이렇게 소개하고 있습니다.“CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects”“코코아팟은 스위프트와 오브젝티브-C 코코아 프로젝트를 위한 의존성 매니저(dependency manager)다.”즉, ‘개발자가 편리하게 사용할 수 있게 오픈소스 라이브러리를 프로젝트와 연결해주는 환경 또는 도구’를 말합니다. 이로 인해 다양한 장점을 가지고 있는데요. 우선 코코아팟은 개발자가 개발한 앱에 라이브러리를 추가, 삭제, 업데이트 등의 관리를 할 수 있습니다. 예를 들어, 네트워크 관련 라이브러리를 개발자가 직접 개발하지 않고, Alamofire 라이브러리를 코코아팟으로 앱에 연결해 사용하는 것입니다. 둘째, 라이브러리 버전을 직접 지정하여 사용할 수 있어 업데이트 버전이 나와도 지정한 버전을 계속 사용할 수 있다는 점입니다. 만약 새로운 버전에 맞춰 개발할 준비가 되면 그때 업데이트를 하면 됩니다.CocoaPods에서 facebook을 검색하면 관련된 다양한 라이브러리가 나옵니다.How to use Cocoapods?1.코코아팟 설치하기개발한 앱에 사용할 오픈소스 라이브러리를 찾았다면 코코아팟을 설치해 앱과 연결해봅시다. 먼저 코코아팟을 설치하고 터미널 프로그램을 열어 아래와 같은 명령어를 입력합니다.$ sudo gem install cocoapods 그리고 CocoaPods Master Specs repository에 있는 Podspec file를 컴퓨터에 다운로드합니다. –verbose 명령어를 이용해 현재 진행 상황을 터미널에서 볼 수 있게 합니다.$ pod setup --verbose 이제 코코아팟을 사용할 준비가 되었습니다. Xcode에서 간단한 프로젝트를 만들고 끝냅니다. 이번 글에서는 관광명소를 보여주는 목록 앱을 예제로 만들겠습니다.2.라이브러리 연결하기터미널 프로그램을 이용해 방금 전 만든 프로젝트 경로로 이동하고, Podfile을 만들어 앱에 필요한 라이브러리를 설정합니다. Podfile을 만드는 방법이 두 가지입니다. 첫 번째는 pod init 명령어를 이용해 코코아팟이 기본 틀이 있는 파일을 생성하게 하는 것입니다. 두 번째는 개발자가 직접 빈 파일을 만들어 설정하는 방법입니다. 이번 글에서는 pod init 명령어를 사용하겠습니다. (편리합니다.)$ pod init podfile이 생성된 것을 확인할 수 있습니다.이제 Podfile을 열어 우리가 사용할 라이브러리를 세팅하고 코코아팟 공식 사이트에 접속합니다. 사용하고자 하는 라이브러리를 검색하고 이름 옆 클립보드 아이콘에 마우스 포인터를 올려보세요. Podfile에 복사할 텍스트가 나타날 겁니다. 이 텍스트를 복사하여 Podfile에 붙이고 저장합니다. 이 글에선 URL에서 가져올 이미지를 다루기 위해 SDWebImage 라이브러리를 사용하겠습니다.완성된 Podfile의 모습위의 Podfile을 잠시 설명하자면 프로젝트의 배포 타겟은 iOS 9.0 입니다. ‘use_frameworks!’ 은 코코아팟을 통해 프로젝트에 추가할 라이브러리가 스위프트로 작성되어 있고, 프레임워크를 사용할 것이기 때문에 꼭 추가해야 하는 문장입니다. 라이브러리 옆의 숫자는 4.3 그리고 4.4 이전까지 라이브러리 버전을 사용하겠다는 뜻 입니다. 최소한의 설정을 맞췄으니, 저장하고 다음 명령어를 실행합니다.$ pod install --verbose pod install 완료 후 xcworkspace 파일이 추가된 것을 확인할 수 있습니다.Pod 설치가 완료되면 xcworkspace 파일이 생성된 것을 확인할 수 있습니다. Xcworkspace 파일은 쉽게 말해서 프로젝트들의 컬렉션(collection of projects)입니다. 기존에 제작한 프로젝트(Original project)와 pods 프로젝트(Pods project)를 함께 묶는데, 이 pods 프로젝트 하나로 모든 라이브러리를 관리할 수 있습니다. 기존 프로젝트는 이 pods 프로젝트를 의존하기 때문에 xcodeproj 파일을 열면 연결된 라이브러리들에 대한 정보가 없어서(혹은 발견하지 못해서) Xcode 프로그램이 에러를 발생시킵니다. 그러므로 코코아팟으로 pod을 설치했을 때, 프로젝트는 xcworkspace 파일을 열어 개발해야 연결한 라이브러리들을 잘 사용할 수 있습니다.3.라이브러리 사용하기이제 연결한 라이브러리를 사용해봅시다.1) 예제에서는 SDWebImage 라이브러리를 이용해 URL 이미지 주소로 ImageView에 이미지를 설정하도록 코드를 추가하겠습니다.테이블뷰(UITableViewController) 컨트롤러를 이용해 목록으로 관광명소 이름, 설명, 이미지를 보여줄 것입니다. 관광명소 이름, 설명, 이미지에 맞게 데이터 모델을 만들고 스토리보드에서 UI를 디자인합니다. 테이블뷰 컨트롤러 파일을 새로 생성해서 이 소스 파일에서 라이브러리를 연결해서 기능을 구현해봅시다. 먼저 라이브러리를 이 소스에 연결하도록 import 명령어를 입력합니다.AttractionTableVC.swift import SDWebImage 그리고 아래와 같이 tableView(tableView:cellForRowAtIndexPath:) 함수에 코드를 작성합니다.2)override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> AttractionTableViewCell {         // Table view cells are reused and should be dequeued using a cell identifier.         let cellIdentifier = "AttractionTableViewCell"         guard let cell = tableView.dequeueReusableCell(withIdentifier: cellIdentifier, for: indexPath) as? AttractionTableViewCell else {             fatalError("The dequeued cell is not an instance of AttractionTableViewCell.")         }         let attraction = attractions[indexPath.row]                  // . . .         cell.attractionLabel.text = "\(indexPath.row). \(attraction.nameWithDescription)"         cell.attractionImage.sd_setImage(with: attraction.photoURL, completed: nil)                 // . . .                 return cell     } SDWebImage 라이브러리를 쓴 이유는, URL 이미지 주소를 이용해서 관광명소 이미지를 보여주고 싶었습니다. 하지만 UIImage에 바로 URL 주소를 사용할 수 없었고, Data 형식으로 변환한 다음 사용해야 했습니다. 라이브러리를 안 쓴 다면 아래와 같은 소스를 작성해야 했을 겁니다.// return UIImage which is set from url data     private func imageFromUrl(url: URL) -> UIImage {         var photo = UIImage()          do {             let imageData = try Data.init(contentsOf: url)             photo = UIImage(data: imageData)!             return photo         } catch {             print(error.localizedDescription)             return photo         }     } 하지만 위에서 만든 소스를 SDWebImage 라이브러리를 이용하면 아래처럼 딱 하나의 명령문으로 줄일 수 있습니다.cell.attractionImage.sd_setImage(with: attraction.photoURL, completed: nil) 소스 길이가 확연히 줄어들었습니다. 이외에도 GIF 지원, asynchronous image downloader 등 SDWebImage 라이브러리 GitHub 페이지로 접속하면 자세한 기능들을 만날 수 있습니다.CocoaPods Error브랜디의 앱 프로젝트를 클론해서 작업하면 종종 코코아팟 관련 오류로 당황했던 적이 있습니다. 몇 가지 에러의 해결 방법들을 소개하겠습니다.1.“/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/sqlite3.h” not found”-> 대부분의 오류들은 코코아팟을 다시 설치하면 거의 다 해결됩니다.$ sudo gem install cocoapods$ pod install –verbose2.“Could not build module firebase core” Error-> project’s temp file 삭제 (~/Library/Developer/Xcode/DerivedData — Xcode->Preference->Location에 위치함)우선 위의 폴더 경로를 먼저 찾아 Finder로 여세요. 그 다음에 Xcode를 종료해 안전하게 삭제해야 합니다.-> ProjectName, .xcworkspace 삭제-> Podfile.lock 파일과 Pods 폴더 삭제-> $ pod install –verbose-> 새로 생성한 ProjectName.xcworkspace 실행하여 다시 빌드하기-> 그래도 안 된다면?—> $ pod update(or) —> $ pod –version 체크(or) —> $ pod repo update—> Podfile에 ‘Firebase’ 주석 처리—> $ pod install (old Firebase가 제거된다)—> Podfile에 ‘Firebase’ 주석 해제—> $ pod install (new Firebase 설치)—> 해결 완료!Conclusion이제는 새로운 기능을 개발하거나 소스를 수정할 땐 코코아팟에서 관련 라이브러리를 찾아봅니다. 마음에 드는 라이브러리는 곧바로 개발하고 있는 앱 프로젝트에 연결해 적용하기도 하고요. 자신의 언어로 순수하게 소스를 개발하는 것도 좋지만, 좋은 도구를 활용하는 것도 업무에 도움이 될 겁니다. 혹시 마음에 드는 라이브러리 찾으셨다면 저에게도 알려주세요. 코코아팟을 사용하는 iOS 개발자가 되신 걸 축하드립니다!주석 1)각 라이브러리의 GitHub 페이지에서는 소스를 연결하는 자세한 방법들을 소개하고 있다.2)attractions 배열에 미리 만들어 놓은 관광명소 데이터들을 저장한다. 배열에서 선정한 하나의 관광명소 데이터 정보를 이용해 각 테이블 뷰 셀에 알맞게 설정한다. 여기서 테이블 뷰 셀에 있는 attractionImage(UIImageView)에 URL 주소로 이미지를 설정하면 된다.참고문헌 swift3 - Error: Could not build Objective-C module ‘Firebase’ - Stack OverflowGoogle 그룹스An Introduction to CocoaPods (Route 85) - YouTube글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 1130

AWS Batch 사용하기

OverviewAWS Batch는 배치 컴퓨팅 작업을 효율적으로 실행할 수 있게 도와줍니다. 배치 작업량과 리소스 요청을 기반으로 최적의 리소스 수량 및 인스턴스 유형을 동적으로 프로비져닝합니다. AWS Batch에서는 별도의 관리가 필요 없기 때문에 문제 해결에 집중할 수 있습니다. 별도의 추가 비용은 없습니다. 배치 작업을 저장 또는 실행할 목적으로 생성된 AWS 리소스(인스턴스 등)에 대해서만 비용을 지불하면 됩니다. 이번 포스팅에서는 간단한 튜토리얼로 AWS Batch 사용 방법을 크게 11개의 Step으로 알아보겠습니다. 이렇게 진행하겠습니다.AWS에서 제공하는 Dockerfile, fetch&run 스크립트 및 myjob.sh 다운로드Dockerfile를 이용하여 fetch&run 스크립트를 포함한 Docker 이미지 생성생성된 Docker 이미지를 ECR(Amazon Elastic Container Registry)로 푸쉬간단한 샘플 스크립트(myjob.sh)를 S3에 업로드IAM에 S3를 접속 할 수 있는 ECS Task role 등록Compute environments 생성Job queues 생성ECR을 이용하여 Job definition 생성Submit job을 통해 S3에 저장된 작업 스크립트(myjob.sh)를 실행하기결과 확인 STEP1. AWS에서 제공하는 Dockerfile, fetch&run 스크립트 및 myjob.sh 다운로드AWS Batch helpers페이지에 접속합니다.    2. /fetch-and-run/에서 Dockerfile, fetchandrun.sh, myjob.sh 다운로드합니다.STEP2. Dockerfile을 이용하여 fetch&run 스크립트를 포함한 Docker 이미지 생성Dockerfile을 이용해서 Docker 이미지를 빌드합니다.잠시 Dockerfile의 내용을 살펴보겠습니다.FROM amazonlinux:latestDocker 공식 Repository에 있는 amazonlinux 의 lastest 버젼으로 빌드RUN yum -y install which unzip aws-cliRUN을 통해 이미지 빌드 시에 yum -y install which unzip aws-cli를 실행ADD fetch_and_run.sh /usr/local/bin/fetch_and_run.shADD를 통해 Dockerfile과 같은 디렉토리에 있는 fetch_and_run.sh를 /usr/local/bin/fetch_and_run.sh에 복사 WORKDIR /tmp컨테이너가 동작할 때 /tmp를 기본 디렉토리로 설정USER nobody컨테이너 실행 시 기본 유저 설정 ENTRYPOINT [“/usr/local/bin/fetch_and_run.sh”]컨테이너 실행 시 /usr/local/bin/fetch_and_run.sh를 call shell에 docker 명령을 통해 이미지 생성shell : docker build -t fetch_and_run . 실행하면 아래와 같은 결과가 출력됩니다.[ec2-user@AWS_BRANDI_STG fetch-and-run]$ docker build -t fetch_and_run . Sending build context to Docker daemon 8.192kB Step 1/6 : FROM amazonlinux:latest latest: Pulling from library/amazonlinux 4b92325dc37b: Pull complete Digest: sha256:9ee13e494b762db41b9db92a200f6784b78da5ac3b0f974fb1c38feb7f636474 Status: Downloaded newer image for amazonlinux:latest ---> 81bb3e78db3d Step 2/6 : RUN yum -y install which unzip aws-cli ---> Running in 1f5293a2294d Loaded plugins: ovl, priorities Resolving Dependencies --> Running transaction check ---> Package aws-cli.noarch 0:1.14.9-1.48.amzn1 will be installed --> Processing Dependency: python27-jmespath = 0.9.2 for package: aws-cli-1.14.9-1.48.amzn1.noarch --> Processing Dependency: python27-botocore = 1.8.13 for package: aws-cli-1.14.9-1.48.amzn1.noarch --> Processing Dependency: python27-rsa >= 3.1.2-4.7 for package: aws-cli-1.14.9-1.48.amzn1.noarch --> Processing Dependency: python27-futures >= 2.2.0 for package: aws-cli-1.14.9-1.48.amzn1.noarch --> Processing Dependency: python27-docutils >= 0.10 for package: aws-cli-1.14.9-1.48.amzn1.noarch --> Processing Dependency: python27-colorama >= 0.2.5 for package: aws-cli-1.14.9-1.48.amzn1.noarch --> Processing Dependency: python27-PyYAML >= 3.10 for package: aws-cli-1.14.9-1.48.amzn1.noarch --> Processing Dependency: groff for package: aws-cli-1.14.9-1.48.amzn1.noarch --> Processing Dependency: /etc/mime.types for package: aws-cli-1.14.9-1.48.amzn1.noarch ---> Package unzip.x86_64 0:6.0-4.10.amzn1 will be installed ---> Package which.x86_64 0:2.19-6.10.amzn1 will be installed --> Running transaction check ---> Package groff.x86_64 0:1.22.2-8.11.amzn1 will be installed --> Processing Dependency: groff-base = 1.22.2-8.11.amzn1 for package: groff-1.22.2-8.11.amzn1.x86_64 ---> Package mailcap.noarch 0:2.1.31-2.7.amzn1 will be installed ---> Package python27-PyYAML.x86_64 0:3.10-3.10.amzn1 will be installed --> Processing Dependency: libyaml-0.so.2()(64bit) for package: python27-PyYAML-3.10-3.10.amzn1.x86_64 ---> Package python27-botocore.noarch 0:1.8.13-1.66.amzn1 will be installed --> Processing Dependency: python27-dateutil >= 2.1 for package: python27-botocore-1.8.13-1.66.amzn1.noarch ---> Package python27-colorama.noarch 0:0.2.5-1.7.amzn1 will be installed ---> Package python27-docutils.noarch 0:0.11-1.15.amzn1 will be installed --> Processing Dependency: python27-imaging for package: python27-docutils-0.11-1.15.amzn1.noarch ---> Package python27-futures.noarch 0:3.0.3-1.3.amzn1 will be installed ---> Package python27-jmespath.noarch 0:0.9.2-1.12.amzn1 will be installed --> Processing Dependency: python27-ply >= 3.4 for package: python27-jmespath-0.9.2-1.12.amzn1.noarch ---> Package python27-rsa.noarch 0:3.4.1-1.8.amzn1 will be installed --> Processing Dependency: python27-pyasn1 >= 0.1.3 for package: python27-rsa-3.4.1-1.8.amzn1.noarch --> Processing Dependency: python27-setuptools for package: python27-rsa-3.4.1-1.8.amzn1.noarch --> Running transaction check ---> Package groff-base.x86_64 0:1.22.2-8.11.amzn1 will be installed ---> Package libyaml.x86_64 0:0.1.6-6.7.amzn1 will be installed ---> Package python27-dateutil.noarch 0:2.1-1.3.amzn1 will be installed --> Processing Dependency: python27-six for package: python27-dateutil-2.1-1.3.amzn1.noarch ---> Package python27-imaging.x86_64 0:1.1.6-19.9.amzn1 will be installed --> Processing Dependency: libjpeg.so.62(LIBJPEG_6.2)(64bit) for package: python27-imaging-1.1.6-19.9.amzn1.x86_64 --> Processing Dependency: libjpeg.so.62()(64bit) for package: python27-imaging-1.1.6-19.9.amzn1.x86_64 --> Processing Dependency: libfreetype.so.6()(64bit) for package: python27-imaging-1.1.6-19.9.amzn1.x86_64 ---> Package python27-ply.noarch 0:3.4-3.12.amzn1 will be installed ---> Package python27-pyasn1.noarch 0:0.1.7-2.9.amzn1 will be installed ---> Package python27-setuptools.noarch 0:36.2.7-1.33.amzn1 will be installed --> Processing Dependency: python27-backports-ssl_match_hostname for package: python27-setuptools-36.2.7-1.33.amzn1.noarch --> Running transaction check ---> Package freetype.x86_64 0:2.3.11-15.14.amzn1 will be installed ---> Package libjpeg-turbo.x86_64 0:1.2.90-5.14.amzn1 will be installed ---> Package python27-backports-ssl_match_hostname.noarch 0:3.4.0.2-1.12.amzn1 will be installed --> Processing Dependency: python27-backports for package: python27-backports-ssl_match_hostname-3.4.0.2-1.12.amzn1.noarch ---> Package python27-six.noarch 0:1.8.0-1.23.amzn1 will be installed --> Running transaction check ---> Package python27-backports.x86_64 0:1.0-3.14.amzn1 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package                              Arch   Version            Repository                                                                           Size ================================================================================ Installing:  aws-cli                              noarch 1.14.9-1.48.amzn1  amzn-main 1.2 M  unzip                                x86_64 6.0-4.10.amzn1     amzn-main 201 k  which                                x86_64 2.19-6.10.amzn1    amzn-main  41 k  Installing for dependencies:  freetype                             x86_64 2.3.11-15.14.amzn1 amzn-main 398 k  groff                                x86_64 1.22.2-8.11.amzn1  amzn-main 1.3 M  groff-base                           x86_64 1.22.2-8.11.amzn1  amzn-main 1.1 M  libjpeg-turbo                        x86_64 1.2.90-5.14.amzn1  amzn-main 144 k  libyaml                              x86_64 0.1.6-6.7.amzn1    amzn-main  59 k  mailcap                              noarch 2.1.31-2.7.amzn1   amzn-main  27 k  python27-PyYAML                      x86_64 3.10-3.10.amzn1    amzn-main 186 k  python27-backports                   x86_64 1.0-3.14.amzn1     amzn-main 5.0 k  python27-backports-ssl_match_hostname                                       noarch 3.4.0.2-1.12.amzn1 amzn-main  12 k  python27-botocore                    noarch 1.8.13-1.66.amzn1  amzn-main 4.1 M  python27-colorama                    noarch 0.2.5-1.7.amzn1    amzn-main  23 k  python27-dateutil                    noarch 2.1-1.3.amzn1      amzn-main  92 k  python27-docutils                    noarch 0.11-1.15.amzn1    amzn-main 1.9 M  python27-futures                     noarch 3.0.3-1.3.amzn1    amzn-main  30 k  python27-imaging                     x86_64 1.1.6-19.9.amzn1   amzn-main 428 k  python27-jmespath                    noarch 0.9.2-1.12.amzn1   amzn-main  46 k  python27-ply                         noarch 3.4-3.12.amzn1     amzn-main 158 k  python27-pyasn1                      noarch 0.1.7-2.9.amzn1    amzn-main 112 k  python27-rsa                         noarch 3.4.1-1.8.amzn1    amzn-main  80 k  python27-setuptools                  noarch 36.2.7-1.33.amzn1  amzn-main 672 k  python27-six                         noarch 1.8.0-1.23.amzn1   amzn-main  31 k Transaction Summary ================================================================================ Install 3 Packages (+21 Dependent packages) Total download size: 12 M Installed size: 51 M Downloading packages: -------------------------------------------------------------------------------- Total 1.0 MB/s | 12 MB 00:12 Running transaction check Running transaction test Transaction test succeeded  Running transaction   Installing : python27-backports-1.0-3.14.amzn1.x86_64                    1/24   Installing : python27-backports-ssl_match_hostname-3.4.0.2-1.12.amzn1    2/24   Installing : python27-setuptools-36.2.7-1.33.amzn1.noarch                3/24   Installing : python27-colorama-0.2.5-1.7.amzn1.noarch                    4/24   Installing : freetype-2.3.11-15.14.amzn1.x86_64                          5/24   Installing : libyaml-0.1.6-6.7.amzn1.x86_64                              6/24   Installing : python27-PyYAML-3.10-3.10.amzn1.x86_64                      7/24   Installing : mailcap-2.1.31-2.7.amzn1.noarch                             8/24   Installing : python27-ply-3.4-3.12.amzn1.noarch                          9/24   Installing : python27-jmespath-0.9.2-1.12.amzn1.noarch                  10/24   Installing : python27-futures-3.0.3-1.3.amzn1.noarch                    11/24   Installing : python27-six-1.8.0-1.23.amzn1.noarch                       12/24   Installing : python27-dateutil-2.1-1.3.amzn1.noarch                     13/24   Installing : groff-base-1.22.2-8.11.amzn1.x86_64                        14/24   Installing : groff-1.22.2-8.11.amzn1.x86_64                             15/24   Installing : python27-pyasn1-0.1.7-2.9.amzn1.noarch                     16/24   Installing : python27-rsa-3.4.1-1.8.amzn1.noarch                        17/24   Installing : libjpeg-turbo-1.2.90-5.14.amzn1.x86_64                     18/24   Installing : python27-imaging-1.1.6-19.9.amzn1.x86_64                   19/24   Installing : python27-docutils-0.11-1.15.amzn1.noarch                   20/24   Installing : python27-botocore-1.8.13-1.66.amzn1.noarch                 21/24   Installing : aws-cli-1.14.9-1.48.amzn1.noarch                           22/24   Installing : which-2.19-6.10.amzn1.x86_64                               23/24   Installing : unzip-6.0-4.10.amzn1.x86_64                                24/24   Verifying  : libjpeg-turbo-1.2.90-5.14.amzn1.x86_64                      1/24   Verifying  : groff-1.22.2-8.11.amzn1.x86_64                              2/24   Verifying  : unzip-6.0-4.10.amzn1.x86_64                                 3/24   Verifying  : python27-pyasn1-0.1.7-2.9.amzn1.noarch                      4/24   Verifying  : groff-base-1.22.2-8.11.amzn1.x86_64                         5/24   Verifying  : aws-cli-1.14.9-1.48.amzn1.noarch                            6/24   Verifying  : python27-six-1.8.0-1.23.amzn1.noarch                        7/24   Verifying  : python27-dateutil-2.1-1.3.amzn1.noarch                      8/24   Verifying  : python27-docutils-0.11-1.15.amzn1.noarch                    9/24   Verifying  : python27-PyYAML-3.10-3.10.amzn1.x86_64                     10/24   Verifying  : python27-botocore-1.8.13-1.66.amzn1.noarch                 11/24   Verifying  : python27-futures-3.0.3-1.3.amzn1.noarch                    12/24   Verifying  : python27-ply-3.4-3.12.amzn1.noarch                         13/24   Verifying  : python27-jmespath-0.9.2-1.12.amzn1.noarch                  14/24   Verifying  : mailcap-2.1.31-2.7.amzn1.noarch                            15/24   Verifying  : python27-backports-ssl_match_hostname-3.4.0.2-1.12.amzn1   16/24   Verifying  : libyaml-0.1.6-6.7.amzn1.x86_64                             17/24   Verifying  : python27-rsa-3.4.1-1.8.amzn1.noarch                        18/24   Verifying  : freetype-2.3.11-15.14.amzn1.x86_64                         19/24   Verifying  : python27-colorama-0.2.5-1.7.amzn1.noarch                   20/24   Verifying  : python27-setuptools-36.2.7-1.33.amzn1.noarch               21/24   Verifying  : which-2.19-6.10.amzn1.x86_64                               22/24   Verifying  : python27-imaging-1.1.6-19.9.amzn1.x86_64                   23/24   Verifying  : python27-backports-1.0-3.14.amzn1.x86_64                   24/24 Installed:   aws-cli.noarch 0:1.14.9-1.48.amzn1        unzip.x86_64 0:6.0-4.10.amzn1   which.x86_64 0:2.19-6.10.amzn1   Dependency Installed:   freetype.x86_64 0:2.3.11-15.14.amzn1   groff.x86_64 0:1.22.2-8.11.amzn1   groff-base.x86_64 0:1.22.2-8.11.amzn1   libjpeg-turbo.x86_64 0:1.2.90-5.14.amzn1   libyaml.x86_64 0:0.1.6-6.7.amzn1   mailcap.noarch 0:2.1.31-2.7.amzn1   python27-PyYAML.x86_64 0:3.10-3.10.amzn1   python27-backports.x86_64 0:1.0-3.14.amzn1   python27-backports-ssl_match_hostname.noarch 0:3.4.0.2-1.12.amzn1   python27-botocore.noarch 0:1.8.13-1.66.amzn1   python27-colorama.noarch 0:0.2.5-1.7.amzn1   python27-dateutil.noarch 0:2.1-1.3.amzn1   python27-docutils.noarch 0:0.11-1.15.amzn1   python27-futures.noarch 0:3.0.3-1.3.amzn1   python27-imaging.x86_64 0:1.1.6-19.9.amzn1   python27-jmespath.noarch 0:0.9.2-1.12.amzn1   python27-ply.noarch 0:3.4-3.12.amzn1   python27-pyasn1.noarch 0:0.1.7-2.9.amzn1   python27-rsa.noarch 0:3.4.1-1.8.amzn1   python27-setuptools.noarch 0:36.2.7-1.33.amzn1   python27-six.noarch 0:1.8.0-1.23.amzn1   Complete! Removing intermediate container 1f5293a2294d  ---> 5502efa481ce Step 3/6 : ADD fetch_and_run.sh /usr/local/bin/fetch_and_run.sh  ---> 1b69173e586f Step 4/6 : WORKDIR /tmp Removing intermediate container a69678c65ee7  ---> 8a560dd25401 Step 5/6 : USER nobody  ---> Running in e063ac6e6fdb Removing intermediate container e063ac6e6fdb  ---> e5872fd44234 Step 6/6 : ENTRYPOINT ["/usr/local/bin/fetch_and_run.sh"]  ---> Running in e25af9aa5fdc Removing intermediate container e25af9aa5fdc  ---> dfca872de0be Successfully built dfca872de0be Successfully tagged awsbatch-fetch_and_run:latest docker images 명령으로 새로운 로컬 repository를 확인할 수 있습니다.shell : docker images [ec2-user@AWS_BRANDI_STG fetch-and-run]$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE fetch_and_run latest dfca872de0be 2 minutes ago 253MB amazonlinux              latest              81bb3e78db3d        2 weeks ago         165MB STEP3. ECR에서 repository 생성아래는 ECR 초기 화면입니다.fetch_and_run이란 이름으로 Repository 생성합니다. 3. Repository 생성이 완료되었습니다.STEP4. ECR로 빌드된 이미지를 pushECR에 docker login후 빌드된 Docker 이미지에 태그합니다. shell : aws ecr get-login --no-include-email --region ap-northeast-2 빌드된 docker 이미지에 태그하세요.shell : docker tag fetch_and_run:latest 000000000000.dkr.ecr.ap-northeast-2.amazonaws.com/fetch_and_run:latest 태그된 docker 이미지를 ECR에 push합니다.shell: docker push 000000000000.dkr.ecr.ap-northeast-2.amazonaws.com/fetch_and_rrun:latest 아래는 ECR fetch_and_run Repository에 푸쉬된 Docker 이미지입니다.STEP5. 간단한 샘플 스크립트(myjob.sh)를 S3에 업로드아래는 간단한 myjob.sh 스크립트입니다.#!/bin/bash date echo "Args: $@" env echo "This is my simple test job!." echo "jobId: $AWS_BATCH_JOB_ID" sleep $1 date echo "bye bye!!" 위의 myjob.sh를 S3에 업로드합니다.shell : aws s3 cp myjob.sh s3:///myjob.sh STEP6. IAM에 S3를 접속할 수 있는 ECS Task role 등록Role 등록 화면에서 Elastic Container Service 선택 후, Elastic Container Service Task를 선택합니다.AmazonS3ReadOnlyAccess Policy를 선택합니다.아래 이미지는 Role에 등록 하기 전 리뷰 화면입니다.Role에 AmazonS3ReadOnlyAccess가 등록된 것을 확인합니다.STEP7. Compute environments 생성AWS Batch 콘솔에서 Compute environments를 선택하고, Create environment 선택합니다.Compute environment type은 Managed와 Unmanaged 두 가지를 선택할 수 있습니다. Managed는 AWS에서 요구사항에 맞게 자원을 관리해주는 것이고, Unmanaged는 직접 자원을 관리해야 합니다. 여기서는 Managed를 선택하겠습니다.Compute environment name을 입력합니다.Service Role을 선택합니다. 기존 Role을 사용하거나 새로운 Role을 생성할 수 있습니다. 새 Role을 생성하면 필수 역할 (AWSBatchServiceRole)이 생성됩니다.Instnace Role을 선택합니다. 기존 Role을 사용하거나 새로운 Role을 생성할 수 있습니다. 새 Role을 생성하면 필수 역할(ecsInstanceRole)이 생성됩니다.EC2 key pair에서 기존 EC2 key pair를 선택합니다. 이 key pair를 사용하여 SSH로 인스턴스에 접속할 수 있지만 이번 글의 예제에서는 선택하지 않겠습니다.Configure your compute resources Provisioning Model은 On-Demand와 Spot이 있습니다. 차이점은 Amazon EC2 스팟 인스턴스를 참고해주세요. 여기서는 On-Demand를 선택합니다.Allowed instance types에서는 시작 인스턴스 유형을 선택합니다. optimal을 선택하면 Job queue의 요구에 맞는 인스턴스 유형을 (최신 C, M, R 인스턴스 패밀리 중) 자동으로 선택합니다. 여기서는 optimal을 선택하겠습니다.Minimum vCPUs는 Job queue 요구와 상관없이 Compute environments에 유지할 vCPU 최소 개수입니다. 0을 입력해주세요.Desired vCPUs는 Compute environment에서 시작할 EC2 vCPU 개수입니다. Job queue 요구가 증가하면 필요한 vCPU를 Maximum vCPUs까지 늘리고 요구가 감소하면 vCPU 수를 Minimum vCPUs까지 줄이고 인스턴스를 제거합니다. 0을 입력해주세요.Maximum vCPUs는 Job queue 요구와 상관없이 Compute environments에서 확장할 수 있는 EC2 vCPU 최대 개수입니다. 여기서는 256을 입력합니다.Enable user-specified Ami ID는 사용자 지정 AMI를 사용하는 옵션입니다. 여기서는 사용하지 않겠습니다.Networking VPC Id 인스턴스를 시작할 VPC를 선택합니다.Subnet을 선택합니다.Security groups를 선택합니다.그리고 EC2 tags를 지정하여 생성된 인스턴스가 이름을 가질 수 있게 합니다. Key : Name, Value : AWS Batch InstanceCreate을 클릭해 Compute environment를 생성합니다.아래 이미지는 생성된 Compute environment입니다.STEP8. Job queues 생성AWS Batch 콘솔에서 Job queues - Create queue를 선택합니다.Queue name을 입력합니다.Priority는 Job queue의 우선순위를 입력합니다. 우선순위가 1인 작업은 우선순위가 5인 작업보다 먼저 일정이 예약됩니다. 여기서는 5를 입력하겠습니다.Enable Job queue가 체크되어 있어야 job을 등록할 수 있습니다.Select a compute environment에서 Job queue와 연결될 Compute environment을 선택합니다. 최대 3개의 Compute environment를 선택할 수 있습니다.생성된 Job queue, Status가 VALID면 사용 가능합니다.STEP9. ECR을 이용하여 Job definition 생성AWS Batch 콘솔에서 Job definitions - Create를 선택합니다.Job definition name을 입력하고 이전 작업에서 만들 IAM Role을 선택하세요, 그리고 ECR Repository URI를 입력합니다. 000000000000.dkr.ecr.ap-northeast-2.amazonaws.com/fetch_and_runCommand 필드는 비워둡시다.vCPUs는 컨테이너를 위해 예약할 vCPU의 수, Memory(Mib)는 컨테이너에 제공할 메모리의 제한, Job attempts는 작업이 실패할 경우 다시 시도하는 최대 횟수, Execution timeout은 실행 제한 시간, Ulimits는 컨테이너에 사용할 사용자 제한 값입니다. 여기서는 vCPUs는 1, Memory(MiB)는 512, Job Attempts는 1로 설정, Execution timeout은 기본값인 100 그리고 Limits는 설정하지 않습니다.vCPUs: 컨테이너를 위해 예약할 vCPU의 개수Memory(Mib): 컨테이너에 제공할 메모리의 제한Jop attempts: 작업이 실패할 경우 다시 시도하는 최대 횟수Execution timeout: 실행 제한 시간Ulimits: 컨테이너에 사용할 사용자 제한 값User는 기본값인 nobody로 선택 후, Create job definition을 선택합니다.Job definitions에 Job definition이 생성된 것을 확인할 수 있습니다.STEP10. Submit job을 통해 S3에 저장된 작업 스크립트(myjob.sh)를 실행하기AWS Batch 콘솔에서 Jobs를 선택합니다. Job을 실행할 Queue를 선택하고 Submit job을 선택합니다.Job run-time1)Job name을 입력합니다.2)Job definition을 선택합니다.3)실행될 Job queue를 선택합니다.Environment Job Type을 선택하는 부분에서는 Single을 선택합니다. Array 작업에 대한 자세한 내용은 어레이 작업 페이지를 참고해주세요.Job depends on은 선택하지 않습니다.자세한 내용은 작업 종속성 페이지를 참고해주세요.Environment Command에서 컨테이너에 전달할 명령을 입력합니다. 여기서는 [“myjob.sh”, “30”] 를 입력해주세요. vCPUs, Memory, Job attempts와 Execution timeout은 job definition에 설정된 값을 가져옵니다. 이 Job에 대한 설정도 가능합니다.Parameters를 통해 job을 제출할 때 기본 작업 정의 파라미터를 재정의 할 수 있습니다. Parameters에 대한 자세한 내용은 작업 정의 파라미터 페이지를 참고해주세요.Environment variables는 job의 컨테이너에 환경 변수를 지정할 수 있습니다. 여기서 주의할 점은 Key를 AWS_BATCH로 시작하면 안 된다는 것입니다. AWS Batch에 예약된 변수입니다.Key=BATCH_FILE_TYPE, Value=script Key=BATCH_FILE_S3_URL, Value=s3:///myjob.shSubmit job을 선택합니다.Job이 Submitted 된 화면입니다.Dashboard를 보시면 Runnable 상태로 대기 중인 것을 확인할 수 있습니다.STEP11. 결과 확인CloudWatch > Log Groups > /aws/batch/job에서 실행 로그를 확인할 수 있습니다.Conclusion간단한 튜토리얼로 AWS Batch를 설정하고 실행하는 방법을 알아봤습니다.(참 쉽죠?) 다음 글에서는 AWS Batch의 Array 또는 Job depends on등의 확장된 기능들을 살펴보겠습니다. 참고1) AWS Batch – 쉽고 효율적인 배치 컴퓨팅 기능 – AWS2) AWS Batch 시작하기 - AWS Batch3) Amazon ECR의 도커 기본 사항 - Amazon ECR글윤석호 이사 | 브랜디 [email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 1571

[Tech Blog] PhantomJS를 Headless Chrome(Puppeteer)로 전환하며

버즈빌에서는 모바일 잠금화면에 내보내기 위한 광고 및 컨텐츠 이미지를 생성하기 위한 PhantomJS 렌더링 서버를 다수 운영하고 있습니다. 일반적으로 PhantomJS는 웹페이지 캡쳐에 많이 쓰이지만, 기본적으로 headless하게 웹페이지를 렌더링하고 캡쳐할 수 있다는 특성 때문에 동적인 이미지 생성에도 많이 활용됩니다. 버즈빌의 렌더링 서버는 200개 이상의 컨텐츠 프로바이더로부터 실시간으로 잠금화면 컨텐츠 이미지를 생성하고 있어 분당 수백 건의 이미지를 안정적으로 생성하는 것이 가능해야 합니다.  렌더링 서버의 스케일링 이슈를 해결하기 위해 버즈빌에서는 여러 대의 렌더링 서버를 둬서 횡적으로 확장을 함과 동시에, 개별 서버 내에서도 리소스 사용률을 높이기 위해 Ghost Town이라는 라이브러리를 작성해 PhantomJS 프로세스 풀을 구성하여 사용하고 있었습니다(Scaling PhantomJS With Ghost Town ) 한편, 시간이 지나면서 잠금화면에서 렌더링하는 이미지 템플릿의 종류가 다양해지고, emoji 및 여러 특수문자를 표현하기 위해 렌더링 서버에 여러 폰트(대표적으로 Noto Sans CJK)를 설치해야 하는 요구사항이 추가됐는데, PhantomJS에서 폰트 렌더링이 일관적이지 않은 문제가 발생했습니다. 동일한 템플릿이지만 폰트가 비일관적으로 렌더링되고 있는 모습 이 문제의 정확한 원인은 결국 찾지 못했지만 PhantomJS의 이슈였거나 시스템 상에 폰트가 시간이 지나면서 추가 설치됨에 따라 font cache가 서버마다 일관되지 않은 상태가 되었기 때문인 것으로 짐작하고 있습니다. 다른 워크로드와 마찬가지로 렌더링 서버도 최초에는 packer를 이용해 일관되게 이미지를 빌드하고 업데이트하려고 했지만, 자주 기능이 추가되거나 배포되는 서비스가 아니기에 서버를 오래 띄워놓고 수동으로 유지보수를 한 케이스들이 누적되어 더 이상 packer를 이용해 시스템이나 폰트를 최신 상태로 유지하는 것이 어려운 상태였습니다. 모든 눈꽃송이가 자세히 보면 조금씩 다르게 생겼다는 것에서 비롯된 snowflake, 즉 배포된 서버들이 시간이 지남에 따라 조금씩 다른 상태가 된 것입니다. 평소에는 문제가 없어 보이지만, 추가적인 확장성이 필요해 scale out을 하거나 새로운 템플릿을 개발해 배포를 하면 문제가 발생하는 상황이었습니다. 사실 더 큰 문제는 PhantomJS 프로젝트가 더 이상 관리되지 않는다는 점이었습니다. 2017년 Google Chrome 59버전부터 Headless Chrome이 내장되기 시작하였고, 곧바로 Node API인 puppeteer가 릴리즈 되어, 현시점에서 가장 많이 쓰이는 렌더링 엔진을 손쉽게 headless로 사용할 수 있는 환경이 되었습니다. 때문에 PhantomJS 관리자가 사실상의 중단을 선언하였고, 2018년에는 최초 개발자에 의해 프로젝트가 아카이브 되었습니다. 프로젝트가 업데이트되지 않는 것은 템플릿에 최신 CSS 스펙을 사용하지 못한다는 것을 의미하고, 버그 수정도 되지 않기에 어플리케이션의 유지보수가 굉장히 어려워짐을 의미합니다. 현재까지의 문제점을 정리하면 아래와 같습니다.  자주 배포되지 않는 서비스 특성으로 인한 서버들이 snowflake화 되는 현상(특히 폰트) PhantomJS의 개발 중단으로 인해 버그 픽스 및 최신 CSS 속성 사용이 어렵게 되고, 향후 유지보수나 새로운 템플릿 개발이 어려워짐  해결방안은 명확했습니다. 첫번째 문제를 해결하기 위해서는 어플리케이션과 폰트가 설치된 시스템을 통째로 컨테이너로 만들고, CI/CD 파이프라인을 통해 지속적으로 빌드하여 snowflake화 되지 않도록 하면 됩니다. 사실 최초에 packer를 이용해 AMI 이미지를 생성하도록 구성이 되어있었기에, 매 배포마다 AMI를 새로 생성하고 지속적으로 렌더링 서버를 배포하는 환경이기만 했으면 snowflake를 방지할 수 있었을 것입니다. 하지만 자주 기능이 추가되거나 배포되는 서비스가 아닌데다, AMI를 빌드하는 과정이 CI/CD에 통합돼 있지 않고 어플리케이션만 지속적으로 배포하는 환경이었기에 편의상 서버를 종료하지 않고 장기간 관리를 해 오게 되었고, packer로 새로운 AMI 이미지를 빌드하는 것이 어려워 졌습니다. 때문에 AMI 빌드를 통한 배포 대신, 이미 운영 중인 kubernetes 클러스터에 도커 컨테이너를 빌드해 immutable한 형상으로 배포하기로 결정하였습니다. 두번째 문제의 간단한 해결책은 PhantomJS를 puppeteer로 변경하는 것입니다. 이 부분은 생각보다 간단했습니다. 의도했는지는 알 수 없으나 puppeteer의 api는 PhantomJS와 꽤나 비슷합니다. drop-in replacement까진 아니지만, PhantomJS api 호출하는 부분만 살짝 바꿔주는 정도로 교체가 가능하였습니다. 물론 교체만 하였다고 해서 기존에 개발된 템플릿이 의도된 대로 출력되는 것을 보장하지는 않기에, 렌더링 서버가 렌더링하는 수많은 템플릿들을 PhantomJS와 puppeteer로 각각 출력하여 일일히 비교하는 작업이 필요했습니다. 어떤 템플릿이 어떤 인자를 필요로하며 의도된 출력 결과가 무엇인지에 대한 정의가 남아있지 않았기에 템플릿마다 샘플 케이스들을 생성하는 작업이 필요했습니다. 아직까지는 수동으로 결과를 비교해야하는 문제점이 있지만 적어도 직접 확인할 수 있는 것은 큰 도움이 되었습니다. 향후에는 자동화된 테스트 케이스를 구성하여 기능 개발이 좀 더 용이하도록 보완할 계획입니다. 결과는 만족스러웠습니다. 많은 경우 기존과 출력 결과가 달랐지만, 최신의 크롬 웹킷이 사용되면서 오히려 템플릿을 개발할 때 의도했던대로 CSS를 더 정확하게 렌더링하게 된 것이었습니다.  FROM node:10-slim RUN apt-get update && \ apt-get install -yq gconf-service libasound2 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 \ libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 \ libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 \ libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 \ fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst ttf-freefont \ ca-certificates fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils wget unzip && \ wget https://github.com/Yelp/dumb-init/releases/download/v1.2.1/dumb-init_1.2.1_amd64.deb && \ dpkg -i dumb-init_*.deb && rm -f dumb-init_*.deb && \ apt-get clean && apt-get autoremove -y && rm -rf /var/lib/apt/lists/* RUN yarn global add [email protected] && yarn cache clean ENV NODE_PATH="/usr/local/share/.config/yarn/global/node_modules:${NODE_PATH}" RUN groupadd -r pptruser && useradd -r -g pptruser -G audio,video pptruser # Set language to UTF8 ENV LANG="C.UTF-8" RUN wget -P ~/fonttmp \ https://noto-website-2.storage.googleapis.com/pkgs/NotoSans-unhinted.zip \ https://noto-website-2.storage.googleapis.com/pkgs/NotoSansCJKjp-hinted.zip \ https://noto-website-2.storage.googleapis.com/pkgs/NotoSansCJKkr-hinted.zip \ https://noto-website-2.storage.googleapis.com/pkgs/NotoSansCJKtc-hinted.zip \ https://noto-website-2.storage.googleapis.com/pkgs/NotoSansCJKsc-hinted.zip \ https://noto-website-2.storage.googleapis.com/pkgs/NotoColorEmoji-unhinted.zip \ && cd ~/fonttmp \ && unzip -o '*.zip' \ && mv *.*tf /usr/share/fonts \ && cd ~/ \ && rm -rf ~/fonttmp WORKDIR /app # Add user so we don't need --no-sandbox. RUN mkdir /screenshots && \ mkdir -p /home/pptruser/Downloads && \ mkdir -p /app/node_modules && \ chown -R pptruser:pptruser /home/pptruser && \ chown -R pptruser:pptruser /usr/local/share/.config/yarn/global/node_modules && \ chown -R pptruser:pptruser /screenshots && \ chown -R pptruser:pptruser /usr/share/fonts && \ chown -R pptruser:pptruser /app # Run everything after as non-privileged user. USER pptruser RUN fc-cache -f -v COPY --chown=pptruser:pptruser package*.json /app/ RUN npm install && \ npm cache clean --force COPY --chown=pptruser:pptruser . /app/ ENTRYPOINT ["dumb-init", "--"] CMD ["npm", "start"]  puppeteer를 사용하면서 약간의 권한 문제가 있어서 결과적으로 위와 같은 Dockerfile을 작성하게 되었는데, puppeteer 도커 이미지 작성에 관한 최신 정보는 여기서 확인할 수 있습니다. 컨테이너 오케스트레이션(K8s)을 사용하면 process 기반의 스케일링은 컨테이너를 여러대 띄워 로드밸런싱을 손쉽게 할 수 있지만, 개별 컨테이너의 throughput을 향상시키기 위해 기존에 Ghost town을 작성해 PhantomJS 프로세스 풀을 만든 것처럼 크롬 프로세스 풀을 구성하기로 하였습니다. 프로세스 풀 구성에는 generic-pool 라이브러리를 사용하였으며 아래처럼 구성하였습니다.  const puppeteer = require("puppeteer"); const genericPool = require("generic-pool"); const puppeteerArgs = ["--no-sandbox", "--disable-setuid-sandbox", "--disable-dev-shm-usage"]; const createPuppeteerPool = ({ max = 5, min = 2, maxUses = 50, initialUseCountRand = 5, testOnBorrow = true, validator = () => Promise.resolve(true), idleTimeoutMillis = 30000, ...otherConfig } = {}) => { const factory = { create: async () => { const browser = await puppeteer.launch({ headless: true, args: puppeteerArgs }); browser.useCount = parseInt(Math.random() * initialUseCountRand); return browser; }, destroy: (browser) => { browser.close(); }, validate: (browser) => { return validator(browser) .then(valid => Promise.resolve(valid && (maxUses <= 0 || browser.useCount < maxUses xss=removed xss=removed xss=removed> genericAcquire().then(browser => { browser.useCount += 1; return browser; }); pool.use = (fn) => { let resource; return pool.acquire() .then(r => { resource = r; return resource; }) .then(fn) .then((result) => { pool.release(resource); return result; }, (err) => { pool.release(resource); throw err; }); }; return pool; }; module.exports = createPuppeteerPool;  Caveats PhantomJS에서 puppeteer로 전환함에 있어서 몇가지 주의해야 할 점이 있었는데요. 첫째는 기존에 사용하던 템플릿의 html에 이미지 소스를 file:// url 프로토콜을 이용해 로드하는 경우가 있었는데, PhantomJS에서는 정상적으로 로드가 되지만 Headless Chrome에서는 보안 정책으로 인해 로컬 파일을 로드할 수 없었습니다(관련 이슈). 때문에 로컬 이미지가 필요한 템플릿은 Express 서버에서 static file serving을 하도록 하고 http:// 프로토콜로 변경하였습니다. 다음으로 발생한 문제는 PhantomJS을 이용한 기존 구현에서는 jade template을 compile한 후 page 객체의 setContent 메소드를 이용해 html을 로드하였는데, puppeteer에서는 page#setContent API 호출 시 외부 이미지가 로드될 때까지 기다리지 않는다는 점입니다. puppeteer 에 올라온 관련 이슈에서는 `=setContent`= 대신 아래와 같이 html content를 data URI로 표현하고 page#goto의 인자로 넘기면서 waitUntil 옵션을 주는 방식을 해결방법으로 권하고 있습니다.  await page.goto(`data:text/html,${html}`, { waitUntil: 'networkidle0' });  이 때 주의해야 할 점은 waitUntil의 옵션으로 networkidle0이나 networkidle2 등을 사용하면 외부 이미지가 충분히 로드될 때 까지 기다리는 것은 맞지만, 500ms 이내에 추가적인 네트워크 커넥션이 발생하지 않을 때까지 기다리는 옵션이기 때문에 외부 이미지가 로드되더라도 추가적으로 500ms를 기다리게 됩니다. 때문에 SPA 웹페이지를 캡쳐하는 경우가 아니라 정적인 html을 로드하는 경우라면 `load` 이벤트로 지정하면 됩니다. 이외에도 향후에 프로젝트의 유지관리나 운영 중인 서비스의 모니터링을 위해 Metrics API 엔드포인트를 만들어 prometheus에서 메트릭을 수집할 수 있도록 하고 grafana 대시보드를 구성하였습니다. 이 대시보드는 어떤 템플릿이 실제로 사용되고 있는지, 템플릿 렌더링에 시간이 얼마나 소요되는지 등을 모니터링할 수 있도록 구성하여 사용되지 않고 있는 템플릿을 판단하거나 서비스 지표를 모니터링 하는 데 이용하고 있습니다. grafana와 prometheus를 이용해 구현한 렌더링 서버 모니터링 대시보드. 마치며 최근에 들어서는 PhantomJS를 사용하던 많은 곳에서 puppeteer로의 전환을 해오고 있어 본 포스팅에서 다루고 있는 내용이 크게 새로운 내용은 아닐 수 있습니다. 하지만 버즈빌에서는 렌더링 서버가 과거에 이미 PhantomJS를 사용하는 것을 전제로 상당한 최적화가 진행되어 왔고, 꽤나 높은 동시 처리량이 요구되는 상황에서 puppeteer로 교체를 해버리기에는 여러 불확실한 요소들이 존재하는 상황이었습니다. 버즈빌의 핵심 비즈니스 중 하나인 잠금화면에 사용되는 이미지를 렌더링하는 서비스가 레거시(개발이 중단된 PhantomJS)에 의존하는 코드베이스 때문에 변경이 어려워지는 것은 향후 꽤나 큰 기술부채로 작용할 것이라 판단하였습니다. 이번 마이그레이션을 진행하면서는 이 부분을 염두에 두고 컨테이너를 사용해 CI/CD 파이프라인을 구축해 지속적으로 컨테이너 기반의 이미지를 생성하도록 변경하였고, 그 결과는 꽤나 만족스러웠습니다. 마이그레이션 이후 그간 밀려 있던 신규 템플릿 개발이나 신규 컨텐츠 프로바이더를 추가하는 과정이 수월해졌기 때문입니다. 빠르게 변화하는 비즈니스 요구사항에 대응하다보면 기술부채는 필연적으로 쌓일 수밖에 없습니다. 개발자에게는 당연히 눈에 보이는 모든 기술부채들을 청산하고 싶은 욕구가 있지만 늘 빚 갚는데 시간을 쓰고 있을 수만은 없는 노릇입니다. 리소스에는 한계가 있으니까요. 어떤 기술부채를 지금 당장 해결해야하는지 의사결정을 하는데 있어 고민이 된다면 일단 “측정”을 해보는 것을 권장합니다. 수치화된 지표가 있다면 당장 의사결정권자나 팀을 설득하는 데 사용할 수도 있지만, 서비스의 핵심 지표들을 하나 둘씩 모니터링 해나가다 보면 서비스에 대한 가시성이 높아지고 미래에 정말로 병목이 되는 지점을 찾아내기 쉬워질 것입니다. 참고 자료  https://docs.browserless.io/blog/2018/06/04/puppeteer-best-practices.html https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md Icons made by Freepik from Flaticon is licensed by Creative Commons BY 3.0    *버즈빌에서 개발자를 채용 중입니다. (전문연구요원 포함)작가소개 Liam Hwang, Software Engineer 버즈빌에서 DevOps를 담당하고 있습니다. Cloud Native 인프라를 구현하기 위해 여러 노력을 기울이고 있으며 새로운 기술들을 공부하는 것을 좋아합니다.
조회수 2168

리디북스 서버 스택 소개

2대의 서버로 시작한 리디북스는 각 기능의 요구사항에 최적인 솔루션들을 채용하고, 고가용성(High Availability)을 지향하면서 매우 복잡하고 다양한 구성으로 변모해왔습니다. 이 글에서는 리디북스가 어떤 스택에서 서비스를 제공하고 있는지 간략히 소개하려고 합니다. 각 스택의 선택 이유나 문제에 부딪히며 배운 노하우 등은 차차 포스팅하겠습니다.대략적인 구조리디북스 백엔드 구조도로드 밸런싱로드 밸런싱은 소프트웨어 로드 밸런서인 HAProxy를 이용하고 있습니다. HAProxy는 L4, L7 스위치의 기능 및 로드 밸런싱을 제공하고 구성 역시 매우 간편합니다. 리디북스는 고가용성을 위해 Active - StandBy 서버 한 쌍이 가상 IP를 공유하고, keepalived를 통해 서로의 상태를 확인하며 자동 failover 됩니다. 각 서버군이 사용하는 네트워크 트래픽에 따라 스위치와 연결되어 있는 네트워크의 속도가 다른데, 이를 효율적으로 사용하기 위해 HAProxy 서버 쌍을 2개 구성하여 DNS를 통해 HAProxy로 들어오는 트래픽도 분산하는 방식으로 네트워크 효율화를 이루었습니다.웹 서버Ubuntu 14.04 LTS 기반에 웹서버로는 Apache, Nginx를 사용하고 있습니다. 서점 용 웹 서버, 정적 파일 서버(CSS, JS 등), 통계용 서버, 책 파일에 DRM을 씌워 전송하는 다운로드 서버 등 여러 개의 웹 서버 그룹을 나누어 관리하는데, 각 서버가 하는 역할이나 테스트를 통해 확인한 병목 지점을 고려해 웹서버를 채택합니다.API 서버리디북스는 서점이나 앱에서 이용하는 수많은 API가 존재하는데 종류에 따라서는 초당 수만 개의 호출이 발생하는 경우도 있습니다. 이러한 트래픽을 감당하기 위해 비동기 처리가 필요한 경우 Node.js를 주로 이용하여 구현하고 있습니다. Node.js 프로세스는 PM2를 통해 클러스터 모드로 실행되어 요청을 처리합니다. 클러스터 모드는 프로세스에 대한 로드 밸런싱을 지원하며 프로세스를 순차적으로 재시작할 수 있어 무정지로 서비스를 재시작할 수 있습니다데이터베이스서비스 초기에 MySQL을 사용했고 현재는 MariaDB로 변경한 상태입니다. 한때 DB가 SPOF(Single Point Of Failure)였던 시기를 겪으면서 read/write의 분산을 위해 많은 노력을 들였습니다. 리디북스에서 실행하는 대부분의 데이터 연산은 읽기 동작이므로 애플리케이션 레벨에서 읽기/쓰기 접근을 구분하여 1차적으로 부하를 분산하고, HAProxy를 통해 여러 대의 slave로 분배해 2차적으로 부하를 분산합니다. 쓰기 동작이 빈번하거나 데이터 성격상 NoSQL이 필요한 경우 Couchbase와 Redis를 적극적으로 사용하고 있으며, MariaDB 상에서도 쓰기 동작의 분산 필요성이 대두됨에 따라 상반기에 샤딩을 준비하고 있습니다. 사용자 행동, 트랜잭션 로그 등 하루에도 방대한 양이 쏟아지는 데이터의 경우 Azure 내에 구성한 Hadoop 클러스터에 보관하며, Hive 저장소를 BI(Business Intelligence) 시스템 기반으로 활용하고 있습니다.파일 시스템리디북스에서 다루는 책 파일은 매우 방대하고 중요한 데이터입니다. 어떠한 일이 있어도 데이터 유실이 발생해서는 안되며, 일부 하드웨어 혹은 노드에 장애가 발생하더라도 서비스 장애 없이 파일을 서빙할 수 있어야 합니다. 저희는 GlusterFS로 6대의 노드를 클러스터를 구성하고 이를 파일 접근이 필요한 서버에서 NFS-like 형태로 마운트하여 사용하고 있습니다. 동일 데이터는 여러 노드(3 replica)에 분산 저장되며, 각 노드에도 RAID 구성을 하여 빠른 장애 대응 및 데이터 유실 방지에 노력하고 있습니다.검색리디북스의 책/저자 검색 등은 ElasticSearch를 통해 이루어집니다. 형태소 분석기는 오픈소스인 은전한닢에 따로 정의한 dictionary를 조합해 사용하고 있고, 2대의 노드로 클러스터가 구성되어 있습니다. 추가/변경되는 도서 정보는 증분 색인을 통해 실시간으로 검색 서버에 반영됩니다.작업큐이메일 발송, PUSH 발송 등의 작업들은 웹 애플리케이션이 직접 실행할 경우 페이지 응답속도를 떨어뜨리고, 진행상황 파악이나 실패 시 재시도하는 등의 실행 관리가 어렵습니다. 이런 문제를 해결하기 위해 Beanstalk라는 Work Queue에 작업을 일단 쌓아두고, 여러 대의 서버에서 실행되고 있는 컨슈머들이 작업을 가져와 순차적으로 진행하는 형태로 구성되어 있습니다.모니터링장애 발생 포인트와 시점을 예측할 수 없는 만큼 장애 발생의 빠른 인지를 위해 모니터링은 매우 중요합니다. 리디북스는 99.999%의 고가용성(High Availability)을 목표로, 버그와 장애 없는 안전한 운영을 위해 아래와 같이 다양한 오픈소스 및 유료 솔루션을 도입하여 활용하고 있습니다.30+ 이상의 서버 리소스를 모니터링하기 위한 Munin(On-Premise) 및 NewRelic(SaaS)서버에서 발생하는 각종 오류와 예외를 모니터링하기 위한 Sentry로그인, 결제 등 서점의 핵심적인 기능의 정상 여부를 모니터링하는 Pingdom각종 배치작업과 주기적으로 실행되는 스크립트를 모니터링하기 위한 PushMonNode.js 프로세스나 Redis 상태 모니터링을 위한 Keymetrics(SaaS)데이터의 무결성을 주기적으로 감지하는 각종 In-house 스크립트#리디북스 #서버 #서버개발 #스택 #백엔드 #node.js #개발자 #개발언어 #스킬스택 #소개
조회수 956

비트윈 시스템 아키텍처

VCNC는 커플을 위한 모바일 앱 비트윈을 서비스하고 있습니다. 비트윈은 사진, 메모, 채팅, 기념일 등 다양한 기능을 제공하며, 오픈 베타 테스트를 시작한 2011년 11월부터 현재까지 연인 간의 소통을 돕고 있습니다. 그동안 비트윈 시스템 아키텍처에는 많은 변화가 있었으며 다양한 결정을 하였습니다. 비트윈 아키텍처를 발전시키면서 배우게 된 여러 가지 노하우를 정리하여 공유해보고자 합니다. 그리고 저희가 앞으로 나아갈 방향을 소개하려 합니다.소프트웨어 스택Java: 비트윈 API서버는 Java로 작성되어 있습니다. 이는 처음 비트윈 서버를 만들기 시작할 때, 서버 개발자가 가장 빨리 개발해낼 수 있는 언어로 프로그래밍을 시작했기 때문입니다. 지금도 자바를 가장 잘 다루는 서버 개발자가 많으므로 여전히 유효한 선택입니다.Netty: 대부분의 API는 HTTP로 호출되며, 채팅은 모바일 네트워크상에서의 전송 속도를 위해 TCP상에서 프로토콜을 구현했습니다. 두 가지 모두 Netty를 통해 사용자 요청을 처리합니다. Netty를 선택한 것은 뛰어난 성능과 서비스 구현 시 Thrift 서비스를 통해 HTTP와 TCP 프로토콜을 한 번에 구현하기 쉽다는 점 때문이었습니다.Thrift: API서버의 모든 서비스는 Thrift 서비스로 구현됩니다. 따라서 TCP뿐만 아니라 HTTP 또한 Thrift 인터페이스를 사용합니다. HTTP를 굳이 Thrift서비스로 구현한 이유는, TCP로 메세징 전송 시 똑같은 서비스를 그대로 사용하기 위함이었습니다. 덕분에 빠른 채팅 구현 시, 이미 구현된 서비스들을 그대로 사용할 수 있었습니다. 또한, 채팅 패킷들은 패킷 경량화를 위해 snappy로 압축하여 송수신합니다. 모바일 네트워크상에서는 패킷이 작아질수록 속도 향상에 크게 도움이 됩니다.HBase: 비트윈의 대부분 트랜젝션은 채팅에서 일어납니다. 수많은 메시지 트랜젝션을 처리하기 위해 HBase를 선택했으며, 당시 서버 개발자가 가장 익숙한 데이터베이스가 HBase였습니다. 서비스 초기부터 확장성을 고려했어야 했는데, RDBMS에서 확장성에 대해 생각하는 것보다는 당장 익숙한 HBase를 선택하고 운영하면서 나오는 문제들은 차차 해결하였습니다.ZooKeeper: 커플들을 여러 서버에 밸런싱하고 이 정보를 여러 서버에서 공유하기 위해 ZooKeeper를 이용합니다. Netflix에서 공개한 오픈 소스인 Curator를 이용하여 접근합니다.AWS비트윈은 AWS의 Tokyo리전에서 운영되고 있습니다. 처음에는 네트워크 및 성능상의 이유로 국내 IDC를 고려하기도 했으나 개발자들이 IDC 운영 경험이 거의 없는 것과, IDC의 실질적인 TCO가 높다는 문제로 클라우드 서비스를 이용하기로 하였습니다. 당시 클라우드 서비스 중에 가장 안정적이라고 생각했던 AWS 를 사용하기로 결정했었고, 지금도 계속 사용하고 있습니다.EC2: 비트윈의 여러 부가적인 서비스를 위해 다양한 종류의 인스턴스를 사용 중이지만, 메인 서비스를 운용하기 위해서는 c1.xlarge와 m2.4xlarge 인스턴스를 여러 대 사용하고 있습니다.API 서버: HTTP 파싱이나 이미지 리시아징등의 연산이 이 서버에서 일어납니다. 이 연산들은 CPU 가 가장 중요한 리소스이기 때문에, c1.xlarge를 사용하기로 했습니다.Database 서버: HDFS 데이터 노드와 HBase 리전 서버들이 떠있습니다. 여러 번의 테스트를 통해 IO가 병목임을 확인하였고, 따라서 모든 데이터를 최대한 메모리에 올리는 것이 가장 저렴한 설정이라는 것을 확인하였습니다. 이런 이유 때문에 68.4GB의 메모리를 가진 m2.4xlarge를 Database 서버로 사용하고 있습니다.EBS: 처음에는 HBase상 데이터를 모두 EBS에 저장하였습니다. 하지만 일정 시간 동안 EBS의 Latency가 갑자기 증가하는 등의 불안정한 경우가 자주 발생하여 개선 방법이 필요했는데, 데이터를 ephemeral storage에만 저장하기에는 안정성이 확인되지 않은 상태였습니다. 위의 두 가지 문제를 동시에 해결하기 위해서 HDFS multiple-rack 설정을 통해서 두 개의 복제본은 ephemeral storage에 저장하고 다른 하나의 복제본은 PIOPS EBS에 저장되도록 구성하여 EBS의 문제점들로부터의 영향을 최소화하였습니다.S3: 사용자들이 올리는 사진들은 s3에 저장됩니다. 사진의 s3키는 추측이 불가능하도록 랜덤하게 만들어집니다. 어차피 하나의 사진은 두 명밖에 받아가지 않고 클라이언트 로컬에 캐싱되기 때문에 CloudFront를 사용하지는 않습니다.ELB: HTTP는 사용자 요청의 분산과 SSL적용을 위해 ELB를 사용합니다. TCP는 TLS를 위해 ELB를 사용합니다. SSL/TLS 부분은 모두 AWS의 ELB를 이용하는데, 이는 API서버의 SSL/TLS처리에 대한 부담을 덜어주기 위함입니다.CloudWatch: 각 통신사와 리전에서 비트윈 서버로의 네트워크 상태와 서버 내의 요청 처리 시간 등의 메트릭을 CloudWatch로 모니터링 하고 있습니다. 따라서 네트워크 상태나 서버에 문제가 생긴 경우, 이메일 등을 통해 즉각 알게 되어, 문제 상황에 바로 대응하고 있습니다. Netflix의 Servo를 이용하여 모니터링 됩니다.현재의 아키텍처처음 클로즈드 베타 테스트때에는 사용자 수가 정해져 있었기 때문에 하나의 인스턴스로 운영되었습니다. 하지만 처음부터 인스턴스 숫자를 늘리는 것만으로도 서비스 규모를 쉽게 확장할 수 있는 아키텍쳐를 만들기 위한 고민을 하였습니다. 오픈 베타 이후에는 발생하는 트래픽에 필요한 만큼 여러 대의 유연하게 서버를 운영하였고, 현재 채팅은 TCP 위에서 구현한 프로토콜을 이용하여 서비스하고 있습니다.HTTP 요청은 하나의 ELB를 통해 여러 서버로 분산됩니다. 일반적인 ELB+HTTP 아키텍처와 동일합니다.채팅은 TCP 연결을 맺게 되는데, 각 커플은 특정 API 서버로 샤딩되어 특정 커플에 대한 요청을 하나의 서버가 담당합니다. 비트윈에서는 커플이 샤딩의 단위가 됩니다.이를 통해, 채팅 대화 내용 입력 중인지 여부와 같이 굉장히 빈번하게 값이 바뀌는 정보를 인메모리 캐싱할 수 있게 됩니다. 이런 정보는 휘발성이고 매우 자주 바뀌는 정보이므로, HBase에 저장하는 것은 매우 비효율적입니다.Consistent Hashing을 이용하여 커플을 각 서버에 샤딩합니다. 이는 서버가 추가되거나 줄어들 때, 리밸런싱되면서 서버간 이동되는 커플들의 수를 최소화 하기 위함입니다.클라이언트는 샤딩 정보를 바탕으로 특정 서버로 TCP연결을 맺게 되는데, 이를 위해 각 서버에 ELB가 하나씩 붙습니다. 어떤 서버로 연결을 맺어야 할지는 HTTP 혹은 TCP 프로토콜을 통해 알게 됩니다.Consistent Hashing을 위한 정보는 ZooKeeper를 통해 여러 서버간 공유됩니다. 이를 통해 서버의 수가 늘어나거나 줄어들게 되는 경우, 각 서버는 자신이 담당해야 하는 샤딩에 대한 변경 정보에 대해 즉각 알게 됩니다.이런 아키텍처의 단점은 다음과 같습니다.클라이언트가 자신이 어떤 서버로 붙어야 하는지 알아야 하기 때문에 프로토콜 및 아키텍처 복잡성이 높습니다.서버가 늘어나는 경우, 순식간에 많은 사용자 연결이 맺어지게 됩니다. 따라서 새로 추가되는 ELB는 Warm-up이 필요로 하며 이 때문에 Auto-Scale이 쉽지 않습니다.HBase에 Write연산시, 여러 서버로 복제가 일어나기 때문에, HA을 위한 Multi-AZ 구성을 하기가 어렵습니다.한정된 자원으로 동작 가능한 서버를 빨리 만들어내기 위해 이처럼 디자인하였습니다.미래의 아키텍처현재 아키텍처에 단점을 보완하기 위한 해결 방법을 생각해보았습니다.Haeinsa는 HBase상에서 트렌젝션을 제공하기 위해 개발 중인 프로젝트입니다. 구현 완료 후, 기능 테스트를 통과하였고, 퍼포먼스 테스트를 진행하고 있습니다. HBase상에서 트렌젝션이 가능하게 되면, 좀 더 복잡한 기능들을 빠르게 개발할 수 있습니다. 서비스에 곧 적용될 예정입니다.Multitier Architecture를 통해 클라이언트와 서버 간에 프로토콜을 단순화시킬 수 있습니다. 이 부분은 개발 초기부터 생각하던 부분인데, 그동안 개발을 하지 못하고 있다가, 지금은 구현을 시작하고 있습니다. 커플은 특정 Application 서버에서 담당하게 되므로, 인메모리 캐싱이 가능하게 됩니다. 클라이언트는 무조건 하나의 ELB만 바라보고 요청을 보내게 되고, Presentation 서버가 사용자 요청을 올바른 Application 서버로 릴레이 하게 됩니다.Multitier Architecture를 도입하면, 더 이상 ELB Warm-up이 필요하지 않게 되므로, Auto-Scale이 가능하게 되며, 좀 더 쉬운 배포가 가능하게 됩니다.Rocky는 API 서버의 Auto-Failover와 커플에 대한 샤딩을 직접 처리하는 기능을 가진 프로젝트입니다. 현재 설계가 어느 정도 진행되어 개발 중에 있습니다. 알람이 왔을 때 서버 팀이 마음을 놓고 편히 잠을 잘 수 있는 역할을 합니다.기본적인 것은 위에서 언급한 구조와 동일하지만 몇 가지 기능이 설정을 추가하면 Multi-AZ 구성이 가능합니다.특정 커플에 대한 모든 정보는 하나의 HBase Row에 담기게 됩니다.HBase의 특정 리전에 문제가 생긴 경우, 일정 시간이 지나면 자동으로 복구되긴 하지만 잠시 동안 시스템 전체에 문제가 생기가 됩니다. 이에 대해 Pinterest에서 Clustering보다는 Sharding이 더 낫다는 글을 쓰기도 했습니다. 이에 대한 해결책은 다음과 같습니다.원래는 Consistent Hashing을 사용하여 커플들을 Application 서버에 샤딩하였습니다. 하지만 이제는 HBase에서 Row를 각 리전에 수동으로 할당하고, 같은 리전에 할당된 Row에 저장된 커플들은 같은 Application 서버에 할당하도록 합니다.이 경우에, 같은 커플들을 담당하는 Application 서버와 HBase 리전 서버는 물리적으로 같은 머신에 둡니다.이렇게 구성 하는 경우, 특정 HBase 리전이나 Application 서버에 대한 장애는 특정 샤드에 국한되게 됩니다. 이와 같이 하나의 머신에 APP과 DB를 같이 두는 구성은 구글에서도 사용하는 방법입니다.이와 같이 구성하는 경우, Multi-AZ 구성이 가능하게 됩니다.AWS에서 같은 리전에서 서로 다른 Zone간 통신은 대략 2~3ms 정도 걸린다고 합니다.Presentation의 경우, 비동기식으로 동작하기 때문에 다른 리전으로 요청을 보내도 부담이 되지 않습니다.HBase에서 Write가 일어나면 여러 복제본을 만들게 됩니다. 하나의 사용자 요청에 대해 Write가 여러번 일어나기 때문에 HBase연산의 경우에는 서로 다른 Zone간 Latency가 부담으로 작용됩니다. Haeinsa가 적용되면, 한 트렌젝션에 대해서 연산을 Batch로 전송하기 때문에 AZ간 Latency 부담이 적습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!
조회수 1685

변화하는 웹 플랫폼 따라가기

플랫폼이 어떻게 변화해가는지를 살펴보면, 직접 경험해보지 않더라도 사람들의 문제의식이 어디에 있는지, 어떤 문제들이 언제부터 풀리게 되는지를 파악할 수 있습니다.이 글에서는 이런 변화들을 살펴볼 수 있는 몇가지 유용한 링크들을 소개하려고 합니다.어떤 논의들이 어디서 오가고 있을까WICG discoursehttps://discourse.wicg.io/WICG는 웹 인큐베이터 커뮤니티 그룹이라고 해서, 웹 표준에 기여해본 사람이 아니라도 토론을 통해 아이디어를 발전시켜서 사람들이 실제로 겪는 문제를 W3C 표준까지 끌어올리는 것을 목표로 하는 커뮤니티입니다.이 곳에서는 주로 CSS, DOM API에 대한 아이디어가 올라옵니다.ES-Discusshttps://esdiscuss.org/ES-Discuss는 WICG와 비슷하게 ECMAScript 스펙에 대해서 논의하는 메일링 리스트입니다. 위 링크는 메일링 리스트에서 오간 이야기를 쉽게 조회할 수 있도록 아카이빙 해놓은 사이트입니다.논의된 아이디어는 어디서 표준으로 다듬어지고 있을까HTML: https://github.com/w3c/html 또는 https://github.com/whatwg/htmlCSS: https://github.com/w3c/csswg-draftsJS: https://github.com/tc39/ecma262HTML은 W3C의 WebPlat WG와 WHATWG에서, CSS는 W3C의 CSSWG에서, JS는 ECMA의 TC39에서 표준을 이끌고 있습니다.위 저장소들에 공개된 초안은 표준이 되기까지 여러 단계를 거치게 되는데, 여기서 다루지는 않겠습니다. (2018-01-25 수정) 이에 대한 내용은 다음의 블로그 포스트에서 자세히 설명하고 있습니다.W3C 표준화 제정 단계ECMAScript와 TC39다듬어진 표준은 어떤 브라우저에서 얼마나 구현되고 있을까다음의 링크에서 각 주제에 대해 브라우저들이 현재 어디까지 구현을 했는지 파악할 수 있습니다.Chrome: https://www.chromestatus.com/featuresFirefox: https://platform-status.mozilla.org/Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/Safari: https://webkit.org/status/크롬 플랫폼 사이트의 경우 각 주제들이 어떤 버전에 반영되었는지 같이 확인할 수 있어서 편리합니다.나머지 브라우저들의 버전별 구현 상태는 https://caniuse.com/에서 주제를 검색하여 참고할 수 있습니다.구현된 기능들은 언제부터 사용할 수 있었고, 언제부터 사용할 수 있게 될까크롬과 파이어폭스는 릴리즈 캘린더를 공개적으로 관리하고 있습니다. 위에서 확인한 기능들을 담고있는 안정 버전이 언제쯤 릴리즈 될 지 다음의 링크를 보고 대략적으로 예상할 수 있습니다.Chrome: https://www.chromium.org/developers/calendarFirefox: https://wiki.mozilla.org/RapidRelease/Calendar크롬과 관련된 플랫폼 따라가기특정 크롬 버전이 어떤 V8 버전을 사용하고 있는지는 https://omahaproxy.appspot.com/에서 확인할 수 있습니다.Node.jsNode.js의 릴리즈 스케쥴은 https://github.com/nodejs/Release에서 확인할 수 있습니다.어떤 Node.js 버전이 어떤 V8 버전을 사용하고 있는지는 https://nodejs.org/en/download/releases/에서 확인할 수 있습니다.Electronhttps://electronjs.org/에서 일렉트론 최신버전이 어떤 노드, 크로미움, V8 버전을 사용하고 있는지 확인할 수 있습니다.일렉트론의 크로미움 팔로업은 깃헙 일렉트론 저장소의 Projects에서 확인할 수 있습니다: https://github.com/electron/electron/projects따라가는데 도움이 되는 블로그브라우저 벤더들이 직접 운영하는 블로그를 구독하면 웹 플랫폼의 소식을 가장 빠르게 접할 수 있습니다.ChromeChromium Blog: https://blog.chromium.org/V8 Blog: https://v8project.blogspot.kr/FirefoxMozilla Hacks: https://hacks.mozilla.org/SafariWebKit Blog: https://webkit.org/blog/EdgeMicrosoft Edge Dev Blog: https://blogs.windows.com/msedgedev/(2018-01-25 수정): @SaschaNaz님 제보로 Webkit status 사이트와 Edge 블로그 추가#스포카 #개발팀 #개발자 #인사이트 #업무일지 #후기
조회수 860

Culturalization of Video Game Soundtracks: An Interview with Pierre Langer, Managing Director & Founder of Dynamedion

 Game culturalization, the process of cultural adaption, is the key to successfully launching video games in foreign markets. The main aspects are to make content suitable, understandable, and meaningful for the gamers of the targeted markets. To achieve these objectives, it is necessary to look into the five central pillars of culturalization: history, religion, ethnic and cultural tensions, geopolitical situations, and in-game elements.One in-game element that must be considered is music. To learn more, we interviewed the video game music expert and composer Pierre Langer, founder and managing director of Dynamedion based in Mainz, Germany. Pierre will tell us more about his internationally renowned company, the video game music business, and the culturalization process of video game soundtracks.  Pierre Langer  Dear Pierre, please let us know more about you and your company and the key services that you provide.  Pierre Langer: Dynamedion was founded by Tilman Sillescu and me in early 2000. We started with work-for-hire audio in the German games industry doing music composition, sound design and later also interactive audio integration and Live Orchestra production. We were the first to produce with live orchestra for a German game, and we eventually rolled this out as a service for other composers and game developers all over the world.Today we are one of the biggest game audio studios in the world with nearly 50 people doing music composition, music licensing, sound design, source sound recordings, audio integration, audio software development, live orchestra and live choir recording, and orchestration and arrangement for all sorts of media. We are still very much focused on video games, having worked on more than 1,800 games, but we also do a lot of movie trailers, TV series, and films.In 2009 we started a sub company of Dynamedion called BOOM library, which produces original sound effects collections as products that can be licensed by audio professionals throughout the world. BOOM Library is today recognized as one of the most popular and high-quality sound effects libraries in the world. Apart from that we also run two side labels with royalty-free stock music in a unique adaptive format (SmartSound) and a new product line of virtual software instruments (SONUSCORE). Our latest addition to our services is that we have become well known for high end vehicle recordings (cars, airplanes, helicopters, bikes, tanks, etc.) – that is a lot of fun, but also a huge challenge to source all sorts of rare or weird or super expensive vehicles.So, in short: we are specialists for everything that has to do with music & sound for games – everything except voice overs, and our music or sound effects or live productions have been used and heard in nearly every large game worldwide. As an example, we recently have been involved in these titles: Assassin’s Creed Series, Elder Scrolls Online, Monster Hunter Online, Battlefield V, League of Legends, Destiny 1 & 2, Lineage II, Horizon Zero Dawn, Fortnite, Mortal Kombat Series, World of Tanks, Hitman Series, Total War Series.Currently we are working on five super large unannounced titles, all international.  What part of the world do your requests mainly come from?  Pierre Langer: It is very international, really. Up until 2009 we had a very strong (overly strong I would say) position in Germany, working on nearly every German game title, quite some in France and some occasional overseas projects. Meanwhile this has completely changed: we are doing a good amount of German titles, but the major part comes from the US, UK, Scandinavia, Japan, Korea and China – China being one of the most important markets now.  Have you experienced a shift or a change over the years in game creation from Western countries to an international mix?  Pierre Langer: Absolutely! It seems that the five big “individual” markets (North America, Europe, China, Japan / Korea) are getting closer to each other. Even very self-sustaining markets, like the Japanese market, are opening up for more international projects coming in, but they are also looking into getting their own games distributed internationally, and of course into becoming as successful as possible worldwide. And then there is a huge amount of projects coming from all the emerging markets, so it seems that there is really no end to a lot of new great games. The biggest challenge with a new game certainly is to make yourself “heard” or do something special that your competition does not do, in order to stand out in a new market.  Orchestral Session - Dynamedion  What is culturalization in terms of video game soundtracks and sound effect production?  Pierre Langer: It is actually a very straightforward thing and kind of a no-brainer, since audio is a rather inexpensive asset for a game, while it has a huge emotional and atmospheric impact. Culturalization of a game means that you adapt the game to the specific requests of a new market. Western world audiences are used to different things than Chinese players, for example. So, if a Chinese game developer wants to push a game into the Western market, the game should be “westernized” so to say. This certainly already happens with gameplay mechanics and with graphics and – of course – with the localization. But simply changing the texts and voice over from Chinese to English doesn’t adapt a Chinese game to an EU or US audience. The look and feel of a game need to change as well, and this is where music and sound “culturalization” comes in: adapting the music and sounds (and the way of implementation and audio functionality in the game) to the specific audience that is being targeted. This does of course work in all directions – Japan to China, China to Europe, Europe to Korea, etc.  Can you give us some examples of audio culturalization in specific markets? (E.g. MENA, South America, China/Asia)  Pierre Langer: Let me go back a few years, to our very first larger game title we did music and sound culturalization for. It was “Runes of Magic” by Runewaker Entertainment, a developer based in Taiwan. The game was not extremely successful in Taiwan and Mainland China, but a German publisher by the time (Frogster) saw some great potential in that game. So, they licensed the title and got the rights to publish it in Europe and the US. In some respects, the game was a mess for a Western audience, partly due to the music and the sound + the implementation of all audio. The marketing people at Frogster understood this very quickly and started working on all these issues. The music and sound side was done in a matter of a few weeks: they asked us to replace the soundtrack by using music we had in our back catalogue (music for games that we had written, that either failed, or that had been unsuccessful – which we kept the rights to) and write a few new themes that would work as the iconic main themes of the game, so that the audience has something new and recognizable. We did that, with a full focus on writing and licensing music that would be ideal for the target audience. Then we did a similar thing with the sound effects: we simply threw out all the stuff that was in there and replaced it with sounds that where produced to fit a Western audience. To give you a very quick example: Asian players are used to high frequency sounds, very aggressive, very loud, the whole sound atmosphere being very crowded. European and US players are used to low frequency sounds – sub-bass, deep impacts, rumbling and more focused sound design (you hear one thing prominently, and everything else gets balanced down to make space for the one important sound going on). This is a very clear and super important difference – and it is also easy to fix with some new content and some new mixing.  What are typical issues that occur in sound culturalization?  Pierre Langer: Typical issues are that there needs to be some trust from the developer to the sound team. In most cases, the developer asks for culturalization from their home market to a foreign market. So, a US developer asking us to adapt the sound to fit a Chinese audience better needs to trust us that we know what we are doing, since the US developer doesn’t know themselves (otherwise they wouldn’t need us). Then there is always a big challenge with the correct audio integration. The most important bit is certainly to replace music and sound effects, to get a fitting new set of assets for the target market. However, even the best assets do not help if they are poorly integrated. Simply swapping them is not enough if the way they are being played back is not fitting. This then needs some more time and attention and focus, since we need to work with the developer directly to e.g. add some audio functionality, balance mix and master the audio, or introduce an interactive music system. It can be a very elaborate thing, but you can achieve a lot of additional quality with the most basic strategies that only cost a lower 5 digit budget.  Dear Pierre, thank you for your time and effort in providing us such enlightening insights into your work!About Pierre:Pierre was born near Frankfurt / Germany. After years of playing in bands as a guitar player in his teens, he decided to take his studies in classical music at the Johannes Gutenberg University in Mainz..A few months before his final exams he met Tilman Sillescu in early 2000, Dynamedion was founded a few weeks later. In the first years of Dynamedion Pierre worked on basically every single bit of the job you can do as an audio person in the games business: music composition, sound design, audio integration, audio management, design of audio tool chains, recording, mixing, mastering, project management, etc.As the thing grew and all the other guys joined in, Pierre focused more and more on the business side of things, leaving the creative work to the really focused experts.Nowadays Pierre enjoys keeping in touch with all the different clients of Dynamedion, thinking up new product lines and business ideas to further expand the reach and prominence of Dynamedion and all related sub-labels such as BOOM Library, Sonic Liberty, Sonuscore... and more to come.The Interview was conducted by Moritz Demmig. 
조회수 1838

CTE for postgresql and sqlalchemy

저희 서비스는 가게마다 웹에서 접속할 수 있는 어드민을 제공하는데, 프렌차이즈가 아닌 하나의 독립적인 가게들일 경우 정보를 가져와 나타내는 데는 굳이 CTE 를 쓸 필요가 없지만 프렌차이즈일 경우 본사와 지점들로 나누어져 있어서 본사와 지점들 정보를 다 가져오기 위해서 CTE 를 사용하게 되었습니다.그럼 postgresql 의 CTEReadme 에 나와 있는 예제와 sqlalchemy core 로 변환하는 것까지 살펴보겠습니다.CTE란?Common table expression 의 약자로 ‘공통 테이블 식’입니다.CTE 특징WITH절 같은 SELECT 문에서 효과적으로 테이블 식을 정의 할 수 있습니다.CTE는 VIEW의 사용방법과 비슷하지만, VIEW보다 편리합니다.VIEW와 달리 사전에 CTE를 정의할 필요가 없습니다.개체로 저장되지 않고, 쿼리 지속시간에만 존재합니다.CTE는 재귀 쿼리를 사용할 수 있습니다.재귀 CTE는 여러행을 반환 가능합니다.동일 문에서 결과 테이블을 여러번 참조 가능합니다.재귀 CTE 예제아래 예제는 ‘A’부서 하위에 있는 부서만 추출하는 예제입니다.일단 재귀 CTE를 이용한 쿼리를 사용하려면 ‘WITH RECURSIVE’ 키워드를 추가해야 합니다.Table ‘department’ 인접 리스트로 조직 구조를 나타냅니다.CREATE TABLE department ( id INTEGER PRIMARY KEY, -- department ID parent_department INTEGER REFERENCES department, -- upper department ID name TEXT -- department name ); INSERT INTO department (id, parent_department, "name") VALUES (0, NULL, 'ROOT'), (1, 0, 'A'), (2, 1, 'B'), (3, 2, 'C'), (4, 2, 'D'), (5, 0, 'E'), (6, 4, 'F'), (7, 5, 'G');부서 구조:ROOT-+->A-+->B-+->C | | | +->D-+->F +->E-+->G A의 하위 부서를 추출, 다음과 같은 재귀 쿼리를 사용할 수 있습니다.WITH RECURSIVE subdepartment AS ( -- non-recursive term SELECT * FROM department WHERE name = 'A' UNION ALL -- recursive term SELECT d.* FROM department AS d JOIN subdepartment AS sd ON (d.parent_department = sd.id) ) SELECT * FROM subdepartment ORDER BY name;위의 쿼리는 다음과 같이 설명할 수 있습니다.중간 테이블(Intermediate table), 작업 테이블(work table), 결과 테이블(result table)이 있습니다.초기화비재귀 구간을 실행 (SELECT * FROM department WHERE name = ‘A’)ResultTable = WorkTable = (‘A’) 결과 테이블과 작업 테이블에 결과를 배치합니다.IntermediateTable = () 중간 테이블을 비웁니다.재귀 쿼리 실행(SELECT d.* FROM WT AS d JOIN subdepartment AS sd ON d.parent_department = sd.id) 하위 부서와 작업 테이블을 바꾸고, 재귀 구간을 실행합니다.중간 테이블에 쿼리 결과를 할당합니다.결과 테이블 및 작업 테이블에 중간테이블 추가합니다.중간 테이블을 비웁니다.재귀가 끝났는지 확인2번 과정의 중간테이블이 비어 있으면 재귀의 실행이 종료되고, 결과 테이블은 반환됩니다.중간테이블이 비어 있지 않으면 다시 2번의 과정으로 돌아갑니다.“subdepartment”는 재귀 표현을 포함하고 있는 CTE입니다. 먼저 비재귀항이 평가되고, 다음 재귀항이 평가됩니다. 재귀항은 평가하고 처리하는 데이터가 없을 때까지 결과가 반복적으로 이전 결과에 추가됩니다. 끝으로 마지막 SELECT가 실행되고 데이터는 결과 집합에서 추출됩니다.CTE의 한계점SEARCH 및 CYCLE 절은 구현되지 않습니다.상호 재귀는 허용되지 않습니다.UNION ALL의 마지막 SELECT만 재귀 이름을 포함할 수 있습니다.재귀와 재귀스캔(RecursiveScan) 계획의 비용은 항상 0입니다sqlalchemy 로 변환sqlalchemy 에서 필요한 모듈들을 불러옵니다.from sqlalchemy import Table, Column, Text, Integer, MetaData, select metadata = MetaData() department 테이블을 정의합니다.department = Table('department', metadata, Column('id',Integer), Column('parent_department',Integer), Column('name',Text)) WITH 절부터 시작되는 CTE 부분의 비재귀항을 subdepartment로 만듭니다. 재귀 사용을 위해 .cte( recursive=True) 부분을 붙여줍니다.subdepartment = select([ department.c.id, department.c.parent_department, department.c.name]).where(department.c.name == 'A') \ .cte(recursive=True) department 와 subdepartment 에 각각 alias를 붙여줍니다.subd_alias = subdepartment.alias() department_alias = department.alias() CTE 부분의 재귀항과 비재귀 항을 union all 해주는 subdepartment를 만듭니다. (이 부분이 postgresql 예제 쿼리에서 봤던 WITH RECURSIVE subdepartment 전체를 나타내는 부분이라 할 수 있습니다.)subdepartment = subdepartment.union_all( select([ department_alias.c.id, department_alias.c.parent_department, department_alias.c.name]) \ .where(department_alias.c.parent_department == subd_alias.c.id)) 마지막으로 결과 쿼리를 출력하기 위한 statement를 만듭니다.statement = select([ subdepartment.c.id, subdepartment.c.parent_department, subdepartment.c.name]).order_by(subdepartment.c.name) 원문: CTEReadme참조: 공통 테이블 식 사용 ,공통 테이블 식을 사용하는 재귀 쿼리#스포카 #개발 #개발자 #서버개발 #개발팀 #꿀팁 #인사이트 #조언

기업문화 엿볼 때, 더팀스

로그인

/