스토리 홈

인터뷰

피드

뉴스

조회수 775

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

크로키닷컴 6번째 인터뷰!오늘은 지그재그 앱 개발을 담당해주시는 앱 개발자 연미님, 하경님과 함께 현재 채용 중인 [안드로이드/iOS 개발자] 포지션 및 지그재그 앱에 관해 소개해보도록 하겠습니다. :-)Chapter 1. 저를 소개합니다!Q. 연미님, 하경님 안녕하세요! 이번 인터뷰이로 선정되신 소감과 간단한 자기소개 부탁드립니다.하경 저는 입사하기 전에 저희 파트 형준님 인터뷰(3편)를 봤었는데 되게 인상 깊었거든요. 그래서 제가 면접을 볼 때도 그 얘기를 했던 게 엊그제 같은데.. 제가 어느새 인터뷰를 하고 있는 모습을 보니 신기하고 뿌듯하네요. (웃음)연미 저는 앱 개발뿐만 아니라 다른 포지션에 대해 도움이 되는 정보를 드릴 수 있게 돼서 감사하게 생각하고 있습니다. 초대해주셔서 감사해요!하경 저는 iOS 개발을 주로 하고 있는 김하경이라고 합니다. iOS를 하다가 최근에는 조그만 것들부터 안드로이드도 시도해보고 있어요. 이번에 저희 지그재그 결제 서비스인 Z결제 소속으로 들어가게 되었는데요, 커머스 앱의 가장 중요한 기능 중 하나인 리뷰 서비스 개발을 맡게 되었어요. 한동안 굉장히 바쁘게 일하지 않을까 생각합니다.연미 저도 하경님과 같이 앱 개발을 하고 있는 손연미입니다. 저는 지그재그 서비스의 초반부터 안드로이드/iOS 개발을 모두 해왔는데, 요즘은 안드로이드 쪽에 좀 더 집중해서 하고 있어요. 이번에 저는 지그재그 서비스를 폭풍 성장시킬 그로쓰팀의 일원으로 들어가게 되었는데요, 유저의 사용성뿐만 아니라 또 다른 시야에서 서비스의 성장을 같이 일궈낼 예정입니다. (앗, 그러면 하경님이 입사 8개월 만에 연미님의 품을 벗어나게 된 건가요?)하경 네 맞아요. 저희가 이번에 처음으로 떨어지게 되었는데 약간은 두렵네요.연미 혹시 괴롭히는 사람 있으면 말하세요. 제가 혼내줄게요!오늘도 평화로운 지그재그 팀Q. 하경님은 지그재그로 이직을 하고 싶으셨던 이유나 계기가 따로 있으셨나요?하경 저는 예전에 정말 소규모의 스타트업에서 처음 iOS 개발을 시작했었어요. 심지어 같이 일하는 동료도 iOS 개발이 처음이었다 보니 같이 배워가는 입장이라 어려운 점이 많았고, 항상 부족하다는 느낌을 받았어요. 계속 검색에 의존하여 개발을 하다 보니, '더 좋은 코드를 짤 순 없을까?' 하는 욕구가 있었는데 우연히 지그재그의 글을 보게 되었어요. 지그재그 기술 블로그나 브런치 글들을 보면 아시겠지만, 성장이라는 문구가 되게 많이 나오거든요! 그게 저에게 굉장히 매력적이었어요. 채용 공고에도 같이 성장하고 싶은 팀원을 구한다고 적혀있길래 망설임 없이 지원했습니다. 저는 그때도 그렇고 지금도 그렇고 항상 성장하고 싶어요.(실제로 입사하시고 나서 겪어본 지그재그는 어떤가요?)하경 전 직장과 비교했을 때 저에게는 지그재그가 큰 회사로 느껴졌어요. 그러다 보니 왠지 이미 굳어진 정책 안에서 정해져 있는 일만 해야 하지 않을까 하는 개인적인 생각이 있었는데, 실제로 겪어보니 전혀 아니었어요. 매우 빠르게 성장하며 끊임 없이 변하고 있고, 이것 저것 새로운 걸 많이 시도해보는 게 신기했어요. 코드 리뷰도 처음 입사했을 당시에는 모든 코드에 대해 서로 꼼꼼히 리뷰한 후에 배포가 가능해서 그 과정에서 정말 많이 배울 수 있어서 너무 좋았는데, 최근에는 작은 부분에 대해서는 코드 리뷰를 거치지 않고 담당자가 빠르게 배포할 수 있도록 자율성을 부여하고 있어요. 이렇게 자율적으로 맡게 되니, 코드에 대한 책임감이 더 커지고 공부도 더 열심히 하게 되는 것 같아요.Q. 연미님은 지그재그 서비스 초기에 합류해서 지금까지 함께하고 계신데요! 처음 합류하시게 된 계기가 궁금합니다.연미 이전 회사에서는 주로 파견을 나가서 근무한 적이 많았어요. 그러다보니 제가 애정을 담아 지속적으로 키워나갈 수 있는 서비스가 없는 점이 항상 아쉬웠어요. 그래서 그런 서비스를 만들어나가는 사람들을 만나 함께 발전시켜나가고 싶다는 생각을 늘 했었는데, 운이 좋게도 지그재그 팀을 만나게 되었네요.(합류를 결정하실 때, CTO 상민님과 함께 일을 해보고 싶었던 마음도 한 몫(?) 했다고 들었어요!)연미 제 주변에서 상민님은 천재 개발자라고 불렸어요. 그러다 보니 저도 상민님과 함께 일하면서 배우고 싶었고, 같이 파이팅해보고 싶다는 의지가 매우 강했어요. 그렇게 합류한 이후 지금까지 상민님과 함께 개발을 하면서 정말 많이 배웠어요. 그리고 상민님과 저의 커뮤니케이션 스타일이 비슷한 부분이 있는데, 그래서 더 편하게 좋은 팀워크를 유지해올 수 있었던 것 같아요. 둘 다 말수가 적은 편이라 업무에 필요한 말만 간단히 주고 받는 편인데, 그게 오히려 서로에게 편하게 느껴진다는 것? (웃음)천재 개발자 상민님의 기술 블로그 놀러 오세요! https://devblog.croquis.com(하경님께서 이전에 코드 리뷰에 대해 언급해주셨는데요, 연미님은 개발팀의 문화로 자리 잡은 코드 리뷰에 대해 어떻게 생각하시나요?)연미 개발자들에게 코드 리뷰는 책임감이고, 방향성이고, 하나의 커뮤니케이션 방식이라고 생각해요. '우리는 코드로 얘기한다.'고 생각하는 개발자들이 모여있기 때문에, 서로가 어떤 생각을 가지고 코드를 짰는지 공유하고, 미처 발견하지 못한 문제점이 있다면 같이 해결해보고 하는 거죠. 같이 sync를 맞추고 신뢰를 쌓아가는 과정이랄까요? 다른 인터뷰에서도 다른 분들이 말씀하시긴 했지만, 우리 지그재그 팀은 다들 서비스에 대한 애정을 바탕으로 더 나은 서비스를 만들고 싶어하는 사람들이라서 이런 문화를 매우 선호하고 환영합니다!Chapter 2. 업무와 일하는 방식Q. 오늘은 지그재그 팀이 목적 조직으로 대대적인 조직개편을 한 그 첫 날인데요, 이 변화에 대해 두 분이 기대하는 점 또는 걱정되는 점이 있다면요?연미 작년에 인원이 많이 늘었고 회사도 커지면서 각자의 R&R이 명확해지다 보니 '함께 한다'는 느낌이 조금 약하게 느껴졌었어요. 그런데 목적 조직은 모두 하나의 목적을 가지고 으쌰 으쌰 하기 때문에 그렇게 생각을 덜 하게 되지 않을까 싶어요. 다만 조직개편 후에 놓치지 않도록 신경써야 되겠다고 생각하는 부분은 각 프로젝트팀의 목적 범위 외의 부분인 것 같아요. 주요 프로젝트 목적에 너무 치중하다보면 다른 부분에서 소홀해질 수 있기 때문에, 그런 경우가 생기지 않도록 어떻게 대비할 것인지 생각해두면 좋을 것 같아요.하경 우선 업무에 보다 집중을 할 수 있는 환경이 된 것 같아 기대가 됩니다. 그리고 개발자는 개발팀, 디자이너는 디자인팀 이렇게 각자의 팀에서 협업을 진행했었는데, 이제는 같이 한 팀이 되어 하나의 목적을 달성해나가게 되었으니 커뮤니케이션이 훨씬 더 수월해진 것 같기도 하고요. 그리고 그럴 일은 절대 없게끔 할테지만, 각 팀의 목적이 훨씬 뚜렷해진 만큼 만에 하나라도 목적을 달성하지 못하게 된다면 제가 너무 우울해지지 않을까 하는 생각이 들기도 해요. 반드시 달성하고 싶어요!Q. 지그재그 앱의 역사를 함께 해오셨는데, 새로운 기술이 도입될 때마다 적용시키는 과정이 궁금해요. 연미 인원이 늘기 전까지는 새로운 기술들에 대해서 시도를 많이 못해봤던 것 같아요. 1년 전부터 팀원이 늘어나게 되면서는 레거시를 바꾸는 작업을 계속 진행하고 있어요. 서비스 초기에 적용된 기존의 기술들을 계속 사용하기보다는 새로 합류하는 팀원들의 의견을 많이 들어보고 적용하려고 하고요. 예전 버전에서 지속적으로 업그레이드를 하고 있다고 생각해주시면 될 것 같아요.하경 우리 지그재그 팀원분들은 기술 그 자체이신 분들이 굉장히 많거든요. 다른 팀원들이 새로운 기술을 접목해서 우리 서비스에 득이 된다면 새로운 기술은 언제든 배우고 싶어요. 물론 서비스의 안정성이 가장 중요하기 때문에, 접목해보기 전 새로운 기술에 대한 충분한 공부가 선행되어야 하는 건 필수라고 생각해요!(새로운 걸 배운다는 게 쉬운 일은 아닌데요..!)하경 어렵지 않아요. 되려 재밌어요! 새로운 걸 배운다는 게 제가 개발을 하는 데 있어서 활력을 불어넣어주는 거라고 생각하거든요. 기존에 하던 대로만 개발을 해오다 보면 지루해져서, 새로운 걸 시도해보곤 한답니다.연미 학습 속도가 정말 빨라요. 뚝딱 하고 만들어내시거든요.하경 아니에요..(부끄) 재밌어서 하다 보니 그렇게 되었네요.빛의 속도 하경님!Q. 서비스 초기부터 앱 파트를 이끌어오신 연미님! 성과를 이루기 위해 해왔던 업무 방식이나 프로세스가 있다면 어떤 것인가요?연미 저는 업무에 대한 흥미도가 성과 향상에 많은 영향을 미친다고 생각해요. 그래서 태스크의 담당자를 정할 때에는 그 태스크에 관심이 있고 하고 싶어하는 팀원이 있는지를 우선적으로 고려하는 편이에요. 만약 지원자가 없는 업무라면 그땐 팀원들과 이야기를 나누며 팀의 상황에 따라 분배를 하긴 하지만요. (웃음)그리고 2019년 초반에는 앱 파트 팀원이 총 3명이었는데요, 그땐 집중 프로젝트라는 것을 적용해봤어요. 각자 하나의 프로젝트를 맡아서 본인이 주도적으로 타 팀과 커뮤니케이션을 하면서 프로젝트를 완료할 수 있게끔 해본 거였는데, 결론적으로는 팀원 분들이 좋아하셨어요! 책임감도 키울 수 있었고, 비즈니스적인 측면에서도 성장할 수 있었다고 생각해요. 내 프로젝트다!라는 생각이 있다 보니까 아이디어도 내보고, 의견 전달도 많이 하면서 진행될 수 있어 좋았습니다 .하경 집중 프로젝트를 통해 미리 경험을 했어서 그런지 이번에 목적 조직에 들어간 게 어색하지 않은 것 같아요. 이미 그 방식에 적응되어 있는 것 같거든요.Q. 하경님은 작년 제1회 지그재그 배 해커톤에서 1등을 하셨어요! 그때 만드신 프로젝트 '휴가봇'이 회사에서 실제로 활용되고 있는데, 기분이 어떠세요?하경 작년 추석쯤에 해커톤을 했었는데요, 뭘 만들어볼까 하다가 회사 생활하면서 작은 부분이지만 불편하게 느껴졌던 부분을 개선해보고 싶어서 만들게 되었어요. 이름은 달비 휴가봇이고 같은 Dev.팀의 우식님과 만들었는데, 이게 이렇게 큰 영향을 끼치게 될 줄 몰랐어요! 사실 지금도 계속 사용 중이니 계속 기능 업데이트를 위해 공부를 하게 되고요. 그래서 신기하기도 하고 뿌듯하기도 하답니다. 원래 쓰던 기술이 아닌 새로운 기술을 배우면서 만들어봤던 프로젝트라서 더 재밌었고, 만약 개발에 지루함을 느끼신 분이라면 이런 프로젝트도 시도해보시면 좋을 것 같아요.연미 새로운 기술을 쓰다 보면 시야가 넓어지거든요. 정말 추천드리고 싶습니다. 하경 그리고 달비 휴가봇을 같이 만들어주신 우식님께도 감사인사를 전하고 싶습니다. 지금까지도 얼떨결에 같이 개발을 하고 계시거든요..(웃음)Chapter 3. 저희 공고를 소개합니다!Q. 현재 채용 중인 [안드로이드/iOS 개발자] 얘기를 해볼까 해요. 어떤 앱 개발자를 찾고 있는지 말씀해주시겠어요?연미 일단 현재는 경력이 3년 정도는 있으신 분을 찾고 있어요. 아무래도 계속 새로운 작업들이 진행되고 있기도 하고 새로운 기술을 계속 적용하며 함께 업데이트를 해나가실 분을 모시고 있기 때문에 어느 정도의 경력은 있으시면 좋을 것 같아요.그래서 Dev.팀이 이번에 인턴쉽을 진행했을 때에도 앱 개발 분야는 별도로 접수를 받지는 않았는데요, 나중에 기회가 된다면 저희도 인턴이나 신입 개발자분들도 모시고 싶어요!하경 개인적으로 바라는 부분이기도 하지만 서비스에 대한 애정이나 관심이 있으신 분이면 좋겠어요. 저랑 같이 텅장을 만드실 분이랄까요.. (웃음) 장난이고요, 애정과 그 서비스에 쏟는 열정은 비례하다고 생각하거든요.연미 사용자가 지그재그 앱을 어떻게 더 편하게 사용할 수 있을지 같이 고민해주실 분을 찾고 있어요. 그리고 채용 공고 내에 우대사항으로 적힌 부분은 정말 우대사항이기 때문에 해당 기술을 알고 계시면 더욱 좋겠지만 모르셔도 괜찮아요. 들어오셔서 같이 배워나가시는 분들도 많이 계시고, 또 필요하면 팀 내에서 개발 스터디를 직접 오픈하실 수도 있고 이미 활발하게 진행중인 스터디에 참여하실 수도 있으니까요.하경 아! 그리고 서로에게 동기부여가 될 수 있는 팀원분을 모시고 싶어요. 앞에서 말씀 드렸던 코드 리뷰 같은 경우에도 서로 코드를 공유 하면서 모르는 기술도 알 수 있게 되고, 몰랐던 문제점을 알아갈 수 있으니 각자의 발전에도 도움이 되거든요! 저희 팀에서 자체적으로 OOP스터디도 진행했었는데, 같이 배우고 공유하면서 회사와 개인의 발전에 목표를 가지실 분이었으면 좋겠어요!Q. 지그재그의 예비 지원자에게 전하는 메시지!연미 지그재그 팀은 사업적인 측면에서도 그렇고, 기술적인 측면에서도 성장 가능성이 무한해요. 아무래도 새로운 시도를 할 때 오픈 마인드이기 때문이지 않을까 싶은데요, 팀원의 성장을 위해서 적극적으로 지원을 해주기 때문에 회사와 함께 발전하고 싶으신 분들은 맘껏 지원해주셨으면 좋겠어요.하경 주저하지 마시고 지원해주셨으면 좋겠어요! 전 개인적으로 빠르게 성장하고 있는 회사에서 일하다 보니 제 자신이 능동적이고 주도적으로 변해가는 걸 느꼈는데요, 그게 되게 회사에서 재밌게 일할 수 있게 해주는 것 같아요.Chapter 4. 마무리Q. 2020년 두 분의 목표가 있으신가요?하경 2019년에는 개인적으로 이사를 하게 되면서 인테리어에도 관심을 갖게 되었고, 특히 제가 청소에 빠지게 됐어요. 부모님이 보시면 어이없어하시겠지만. (웃음) 다른 것에 좀 더 포커싱이 가있었다 보니 개발 공부를 많이 못했던 것 같아요. 그래서 올해엔 공부를 열심히 할 생각이고, 마인드도 바꿔보려고요! 더 긍정적인 마인드!연미 저도 비슷한데, 개발자로서의 역할을 더 강화하고 싶어요. 저의 테크니컬한 부분을 더 발전시켜보려고요. 개인적인 목표는.. 내 집 장만입니다.하경 그거.. 작년 목표 아니었나요..?(웃음) 저는 건강관리도! 점심마다 샐러드를 먹고 있는데요, 공개적으로 말해두면 더 열심히 지키지 않을까 싶어 추가로 말씀드려봅니다.Q. 다음으로 인터뷰를 진행했으면 하는 팀이 계신가요? 궁금한 팀이 있으면 말씀해주세요!하경 저는 Relations팀이요. 전반적인 채용을 담당해주셔서 그 과정도 궁금하고, 이번에 팀 인원도 두 분 더 합류하셨는데 어떤 변화들이 생겼는지 궁금해요.연미 저는 3PL분들이요! 각자 프로젝트마다 어떤 방식으로 업무를 진행해가실 예정인지, 주간 미팅 때 공유해주시긴 했지만 좀 더 구체적인 가이드라인과 비전이 궁금해요. 이 인터뷰가 성사되고 많은 분들께 읽혀진다면, 각 팀의 목표에 공감하시는 좋은 분들이 많이 합류해주시지 않을까요! (*3PL은 지그재그의 새로운 프로젝트팀 리더 세 분을 의미합니다!)지그재그에서는 안드로이드/iOS 개발자를 포함하여 활발하게 채용을 진행하고 있습니다. 지그재그 팀과 함께, 수면 아래 숨겨진 가치를 찾아내는 경험에 동참할 팀원을 꼭 모시고 싶습니다 :-) 궁금하신 점은 언제나 job@zigzag.kr 또는 http://facebook.com/zigzagcareer로 연락 주세요!지그재그 [안드로이드/iOS 개발자] 포지션을 소개합니다!이런 일을 합니다.안드로이드, iOS이런 분을 모십니다.안드로이드iOS이 중 하나라도 가능하시다면 더더욱 좋아요 :)공통안드로이드iOS지원 방법채용 절차혜택과 복지   더 많은 공고는 채용 사이트에서 확인 가능합니다! >>> 채용 사이트 바로가기
조회수 749

[Tech Blog] Software architecture: The important stuff

마틴 파울러는 Software architecture 를 “무엇이건 간에 중요한 것들(The important stuff whatever it is)” 이라고 정의합니다. 조금은 재미있는 정의지만, 그 정의를 도출하기 위해 제시한 다른 정의를 들어보면 고개를 끄덕이게 합니다.  Software architecture 는 전문 개발자들이 같은 생각을 가지고 이해하는 시스템 디자인입니다. Software architecture 는 이른 시기에 정해져야 하는 디자인 결정들입니다. 혹은 여러분이 “아, 처음부터 좀 더 잘 생각하고 할 껄”이라고 후회하는 바로 그 결정들입니다. Software architecture 는 또한 바꾸기 어려운 결정들의 집합입니다.  결국 무엇을 중요하게 생각할 것인가, 그것이 Software Architecture 라는 의미입니다. Why is it important? 왜 중요한지 설득하지 못한다면 사실 중요하지 않은 것일지도 모르죠. 그래서 왜 Software Architecture 이 중요한지 짚어보고자 합니다. 쿠팡은 Microservice architecture 로 전환하는 여정을 글로 남겼는데요. 블로그 글의 제목을 “행복을 찾기 위한 우리의 여정” 이라고 지었습니다. (좋은 글이니 읽어보시길!) 다시 말해서, Software Architecture는 개발가자 더 좋은 제품을 만들 수 있는 길이기 때문에 중요하다고 말합니다. 그러나 좋은 Software Architecture를 만드는 일은 쉽지 않습니다. 블로그 글을 인용 해보겠습니다: “여기 저렴한 제품과 비싼 제품이 있습니다. 비싼 제품은 software architecture 가 잘 고려되어 있고, 저렴한 제품은 시스템 디자인에 대한 고민 없이 구현되어 있습니다. 하지만 두 제품은 겉으로 보기에 차이가 없습니다. 소비자가 보기에 똑같이 보이고, 똑같은 기능이 있으며, 성능 또한 같습니다. 어떤 제품을 사야할까요?” 소비자는 제품을 만든 개발자의 행복을 위해 더 비싼 제품을 선택하지는 않습니다. 개발자 역시 동료들에게 “내가 행복하려면 시간과 돈이 좀 더 들더라도 좋은 software architecture 를 구성해야 해.” 라고 주장하기엔 설득력이 부족하죠. Software architecture 가 왜 중요한지 모두가 공감하려면 경제적인 입장에서 그 중요성을 설득해야 합니다. “내부 품질을 좀 포기하더라도 이번 릴리즈에 더 많은 기능들이 들어가야 해.” 라는 의견에 “안돼 우리(개발자)는 더 전문적으로 구성해야 해.”라는 의견으로 대응하면 항상 질 수 밖에 없습니다. 장인 정신과 경제 논리 사이의 싸움에서는 경제 논리가 항상 이겨왔거든요.   Cumulative functionality over Time Software architecture 를 고려하지 않으면서 제품을 개발하면 초기에는 기능 추가 속도가 빠를 수 있지만, 시간이 흐름에 따라 제품의 기능 증가 속도는 점차 느려집니다. 이미 구현된 기능들과 코드가 새로운 기능을 추가하는데 걸림돌이 되기 때문입니다. 한편, 좋은 설계를 지속적으로 건강하게 유지하고, 주기적으로 리팩토링을 하고, 코드를 깨끗하게 유지한다면 시간이 흘러도 기능 추가가 느려지지 않을 수 있습니다. 오히려 기능을 추가하기 위해 수정해야 할 곳들이 명확하고 모듈화 또한 잘 되어있기 때문에 시간이 갈 수록 기능 추가가 더욱 빠르게 진행될 수 있습니다. 새로운 개발자가 참여하는 시점에도 시스템을 더욱 빠르게 이해하고, 더 빠르고 안전하게 기능을 추가할 수 있게 됩니다. 결국 장기적으로 더 많은 기능을 생산하고 빠르게 고객에게 전달하기 위해서 개발팀은 좋은 디자인과 설계에 대해 깊게 고민해야 합니다. What is the best software architecture? 옳은 software architecture 는 없습니다. 상황에 따라 해답은 다를 수 있습니다. Microservice architecture 가 좋다고 해서 모든 것에 대한 답이 microservice architecture 인 것은 아니고, 마찬가지로 어떤 시스템이 monolithic architecture 로 구현되어 있다고 해서 뒤쳐져 있는 것도 아닙니다. 모든 선택에는 Tradeoff 가 있기 마련이니까요. 유선 통신 시스템을 구성한다고 생각해 볼까요? 우리 나라처럼 인터넷이 잘 구성된 상황에서 Skype 로 할 수 있는 통화는 무료이고, 품질도 좋고, 영상 통화까지 됩니다. “Skype 만세! 인터넷을 통한 통신이 항상 옳습니다!” 라고 외치려던 시점에 정전이 되었습니다. 방금 외친 외침은 멀리 가봐야 옆집 정도 닿겠죠. 한편 기존 유선 전화 시스템은 느리고 화상 통화도 안되지만, 전화선 자체에 전원이 공급되고 있기 때문에 정전 시에도 통화가 가능합니다. 전쟁 상황이나 기타 재난 등에도 반드시 통신이 가능해야 하는 곳은 유선 전화 시스템이 꼭 필요할 것 같습니다. 은행 시스템도 적절한 예시가 될 수 있습니다. 비밀번호 입력, 전화 인증, OTP 확인하는 등 은행 업무는 왜이리도 복잡할까요? 그냥 비밀번호 기억해주고 로그인 유지해주면 참 편할텐데 말이죠. 안전하기 위해서겠죠. 여러분의 자산은 소중하니까요. 사용성(Usability)과 안전성(Security)은 종종 둘 사이를 조절해야 하는 Tradeoff 입니다. 만들려는 제품과 시스템, 환경, 시기와 조건 등에 따라서 적절한 architecture 는 달라집니다. 좋은 architecture 를 선택할때 개발자는 선택한 것의 대척점에 있는 무언가를 포기 해야합니다. 그렇기에 software architecture 는 기술적인 범주 안에서만 고려되면 안되고, 구현하고자 하는 비지니스를 매우 잘 이해하고 고려해서 적용해야 합니다. What are you going to do? 이미 구성된 software architecture 를 변경하는 것은 굉장히 어렵습니다. 이미 구성되어 있는 것들을 상세하게 알고 있어야 하고, 비지니스의 요구 사항을 수용해야 하며, 이미 존재하는 기능이 변경 도중 문제 없이 동작해야 합니다. 또한 기존 시스템에 기여한 개발자들과 변경 사항에 대한 공감대를 이뤄야 하며, 겉으로 보기에 당장 변화가 없는 것에 대한 비용에 대해 많은 사람들을 설득해야 합니다. 최근 Buzzvil 에서는 Architecture Task Force 팀을 구성하였습니다. 이를 통해 전체적인 설계를 정비하고 모든 개발팀이 구조적으로 같은 이해를 할 수 있도록 분석, 조사, 계획 수립, 실행에 옮길 예정입니다. 지속적인 공유를 통해 전사적인 공감대를 유지하고 체계적인 문서화와 가이드라인을 통해 모든 팀원이 함께 실행하며 성장할 수 있는 기반을 준비하게 될 것입니다. 궁극적으로 전사 프로젝트와 모든 팀이 더욱 빨리 움직일 수 있는 software architecture 를 구성하고, 이를 통해 더 많은 기능을 더 빠르게 전달할 수 있게 할 것입니다. 아직 해야할 일들이 많이 남아있지만 제대로 계획하고 빠르게 움직인다면 충분히 좋은 결과를 만들 수 있을 것 같습니다. 당장은 눈에 보이는 변화가 없을지라도, 좋은 디자인에 대한 고민과 실행이 우리가 궁극적으로 바라는 비전과 목표에 한 걸음 더 빠르게 다가가는 올바른 길이라고 믿습니다.   *버즈빌에서 개발자를 채용 중입니다. (전문연구요원 포함)작가소개 Whale, Chief Architect “Keep calm and dream on.”
조회수 1188

AWS Rekognition + PHP를 이용한 이미지 분석 예제 (1/2)

OverviewAWS Rekognition은 딥 러닝 기반의 이미지, 동영상 분석 서비스입니다. Rekognition API를 사용하면 서비스에서 객체, 사람, 텍스트, 장면 및 동작을 식별하고 부적절한 콘텐츠를 탐지할 수 있습니다. Rekognition은 딥 러닝 기술을 기반으로 하고 있기 때문에 지금 이 순간에도 새로운 데이터를 통해 끊임없이 학습하고 있고, AWS에서도 새로운 레이블과 얼굴 인식 기능을 추가하고 관리합니다. 이번에는 AWS S3 Bucket에 업로드한 이미지로 이미지 분석 결과를 볼 수 있는 예제 사이트를 통해, Rekognition과 친해지는 시간을 갖도록 하겠습니다. 저는 예제 사이트를 개발하기 위해 PHP 프레임워크인 CodeIgniter 3, MAMP, Bootstrap을 사용했습니다.1. AWS Rekognition SDK 설치하기1-1) AWS Rekognition 사이트에 접속해 Download SDKs 를 클릭합니다.1-2) AWS 에서 제공하는 다양한 언어의 SDK를 확인할 수 있습니다. 저는 PHP를 사용할 것이므로 PHP 의 Install을 클릭하겠습니다.1-3) AWS SDK 를 설치할 수 있는 방법은 여러가지가 있습니다. 이 중에서 저는 Composer를 이용해 설치했습니다.curl -sS https://getcomposer.org/installer | php php -d memory_limit=-1 composer.phar require aws/aws-sdk-php 1-4) 짠! 짧은 명령어 2줄로 SDK 설치가 완료되었습니다 :)2. AWS S3 Bucket 에 업로드된 이미지를 분석하기2-1) 여기에 임의로 만든 예제 사이트가 있습니다. [이미지 선택] 과 [S3에 이미지 업로드하기] 를 통해 이미지 파일을 등록하면, 백단(Back-end) 에서는 해당 파일을 특정 S3 Bucket 에 업로드 한 후 Rekognition 에게 이미지 분석을 요청하도록 짜여있습니다. 관련 코드는 아래와 같습니다.{     "Image": {         "S3Object": {             "Bucket": "bucket",             "Name": "input.jpg"         }     },     "MaxLabels": 10,     "MinConfidence": 80 } 위의 코드 블록은 AWS Rekognition 개발자 안내서에 나와있는 예제 포맷이고, 아래의 코드는 예제 포맷을 PHP 에서 요청할 수 있는 방식으로 코딩한 것입니다.detectLabels 메소드 를 이용해 분석할 이미지가 저장되어 있는 S3 Bucket 과 이미지의 Name 을 전달해줍니다. 1) MaxLabels : 응답 받을 최대 Label 수 2) MinConfidence : Label 에 대한 최소 신뢰성 여기서 Label 이란 ‘이미지에서 발견되는 객체, 장면 또는 개념’ 이라고 생각하면 됩니다. 예를 들어 해변에 있는 사람들을 촬영한 사진에는 ‘사람’, ‘물’, ‘모래’ (객체) 및 ‘해변’ (장면) 그리고 ‘야외’ (개념) 등이 Label 이 될 수 있습니다. 자, 우주 사진을 한 번 분석해볼까요? array(3) {     ["Labels"]=>     array(8) {       [0]=>       array(2) {         ["Name"]=>         string(9) "Astronomy"         ["Confidence"]=>         float(96.8987350464)       }       [1]=>       array(2) {         ["Name"]=>         string(5) "Earth"         ["Confidence"]=>         float(96.8987350464)       }       [2]=>       array(2) {         ["Name"]=>         string(5) "Globe"         ["Confidence"]=>         float(96.8987350464)       }       [3]=>       array(2) {         ["Name"]=>         string(11) "Outer Space"         ["Confidence"]=>         float(96.8987350464)       } ...     } Rekognition이 업로드한 우주 사진을 분석하여 정확히 연관된 Label들만 반환한 것을 확인할 수 있습니다. 이 Label을 가지고 이미지 태그를 간단하게 구현했습니다.참 쉽죠 ?Conclusion이번 시간에는 AWS Rekognition 을 이용하여 기본적인 이미지 분석을 해보는 시간을 가져봤습니다. 다음 시간에는 ‘얼굴 감지 및 분석’ 기능을 응용하여 Collection 을 생성해보고, 얼굴 검색을 해보는 시간을 갖겠습니다. 참고놀라운 무료 이미지 · Pixabay핀터레스트 스타일 레이아웃 만들기 (masonry) - 생활코딩이미지에서 레이블 감지 - Amazon Rekognition글김우경 대리 | R&D 개발1팀kimwk@brandi.co.kr#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 2629

Eclipse 디버거 사용법

꽤 많은 분들이 디버거의 존재 자체를 모르고 있거나 혹은 디버거가 있다는 사실은 알아도 그 효용성에 의문을 제기하곤 합니다. 왜냐하면, 우리에겐 Log 클래스나 혹은 printf같은 훌륭한(?) 디버깅 도구가 있다고 생각하기 때문이죠. 물론 이렇게 필요한 변수를 찍어보면서 어떤 곳에서 버그가 있는지를 알아보는 일이 잘못된 일은 아닙니다만 복잡한 여러 상황이 맞물려 재현되는 버그는 이러한 고전적인(?) 방법을 써서 알아보기가 매우 어렵습니다.원인을 정확히 그리고 빨리 파악하려면 디버거의 사용법을 숙지하고 사용하는 것이 가장 좋습니다. 대부분의 개발 환경에서 디버거를 제공하는데 다행히 이클립스에서도 쓸만한 디버거를 내장하고 있습니다.오늘 포스팅에서는 이클립스 디버거 사용법에 대해 다루어 볼까 합니다.이클립스 디버거 뷰이클립스는 디버거 뷰를 제공하여 디버거를 사용할 수 있도록 합니다. 디버거 뷰는 어디에서 확인할 수 있을까요? 바로 우측 상단에 Debug 뷰에 들어가면 그곳에서 확인할 수 있습니다.디버깅의 시작그렇다면 어떻게 디버깅을 활성화한 상태로 프로그램을 실행할 수 있을까요? 상단 메뉴의 Run에서 프로그램을 실행할 때 Debug를 이용하여 프로그램을 실행하면 디버거가 작동하게 됩니다.브레이크 포인트 설정과 뷰보통 디버깅을 할 때 가장 먼저 하는 일이 브레이크 포인트를 잡는 일입니다. 브레이크 포인트를 에러가 일어나는 라인이나 혹은 의심이 가는 변수를 추적할 수 있는 라인쯤에 잡아놓고 프로그램을 디버깅하면 해당 라인을 실행할 때 디버거가 작동하게 되고 그곳에서 프로그램을 라인 별로 진행해가며 관찰을 진행할 수 있게 됩니다.브레이크 포인트 설정은 매우 간단합니다. 편집기 왼쪽에 파란 부분(마커 바)을 더블 클릭하게 되면 파란 원이 생기는데 이 원이 브레이크 포인트입니다. 혹은 오른 클릭하여 Toggle break point를 누르면 됩니다. 설정 후 다시 더블 클릭하게 되면 브레이크 포인트가 사라지게 됩니다.또한, 디버그의 브레이크 포인트 뷰에서 지금까지 걸어놓은 모든 브레이크 포인트들의 위치를 확인할 수 있고 활성화/비활성화, 삭제도 할 수 있습니다. 여러 브레이크 포인트가 걸려있을 때에는 이 탭에서 확인하고 관리하는 것이 더 편합니다.또한, 디버깅을 진행하고 있는 도중에도 다른 의심이 가는 라인에 브레이크 포인트를 걸 수 있습니다.스텝 단위 진행지정한 브레이크 포인트에 다다르면 동시에 디버거가 작동하게 되고 그 라인부터 스텝 단위의 진행을 할 수 있게 됩니다.이제 이 뷰의 버튼들을 이용하여 현재 상황을 진행하거나 되돌릴 수 있습니다. 자주 사용하는 버튼의 사용법을 알아보면Resume : 다음 브레이크 포인트를 만날때까지 진행합니다.Suspend : 현재 작동하고 있는 쓰레드를 멈춥니다.Terminate : 프로그램을 종료합니다.Step Into : 메서드가 존재할 경우 그 안으로 들어가 메서드 진행 상황을 볼 수 있도록 합니다.Step Over : 다음 라인으로 이동합니다. 메서드가 있어도 그냥 무시하고 다음 라인으로 이동합니다.Step Return : 현 메서드에서 바로 리턴합니다.Drop to Frame : 메서드를 처음부터 다시 실행합니다.등이 있습니다.실제로 디버깅 화면에서 버튼들을 눌러보면 쉽게 그 쓰임새를 아실 수 있습니다.변수의 상태 확인을 쉽게 해주는 변수 뷰디버깅을 진행하는 도중 변수의 값이나 객체의 상태를 알고 싶은 상황이 생기게 됩니다. 현재 의심이 가는 변수 이외에도 이 변수에 영향을 끼칠 다른 변수들이나 객체들의 상황을 실시간으로 검사할 필요가 있을 때 변수 뷰를 이용하면 도움을 얻을 수 있습니다.이곳에서 변수나 객체의 상태를 확인하고 변수의 상황에 대해서 저장할 수 있습니다. 변수나 객체의 상황을 모두 저장해서 클립보드에 붙이고 싶은 일이 생기면 해당 변수를 오른클릭 후 Copy Variables를 선택합니다.편집 창으로 돌아가 변수에서 Command + shift + i를 누르게 되면(혹은 오른 클릭 후 Inspect를 선택) Inspector 창이 뜨게 됩니다. 이 창에서 다시 한번 Command + shift + i를 누르면 해당 변수를 Expression 뷰로 보내게 되고 이곳에서 지속해서 변수의 상태를 관찰할 수 있게 됩니다.Expression 뷰 이용Expression 뷰에서는 변수 이름을 입력하거나 수행해보고 싶은 명령어를 직접 입력하여 그 결과 값을 관찰할 수 있습니다. 결과 값을 관찰할 뿐만 아니라 Expression에 써놓은 변수들은 명시적으로 지우지 않는 이상 계속해서 관찰을 수행하기 때문에 변해가는 상황을 지속해서 관찰할 일이 있는 변수나 명령문을 등록해놓기에 좋습니다.Display 뷰 이용디스플레이 뷰에서는 현 문맥에서 사용할 수 있는 명령어를 실행하거나 변수의 값을 조작하는 일을 수행하기에 적합한 환경을 제공합니다. Expression에서도 비슷한 기능을 제공하지만, 디스플레이 뷰를 이용하는 것이 더 편합니다. 메모장과 같이 쉽게 쓰고 지울 수 있기 때문입니다.또한, 원본 코드의 수정 없이 편하게 현재의 맥락을 변화시킬 수 있는 것이 가장 큰 장점이라고 볼 수 있습니다.필요한 명령어들을 적어놓은 후 실행하고 싶은 부분만 드래그하여 수행하거나 혹은 값을 리턴받을 수 있습니다. 지금은 boolean변수 하나의 값을 바꿔보기도 하고 조건 값에 따라 무언가를 리턴 받도록도 해놓은 상황을 스크린 샷으로 담아보았습니다.값을 반환받고 싶을 때는 두 번째 버튼을, 단순히 실행만 할 때에는 세 번째 버튼을 누르면 됩니다.두 번째 버튼을 눌러 값을 반환받는 상황입니다.단순히 실행만 하려면 세 번째 버튼을 누릅니다.브레이크 포인트에 조건 걸기브레이크 포인트에 조건을 거는 것이 굉장히 유용할 때가 있습니다. 특히 반복문안에 들어가 있는 코드들을 디버깅할 때 유용하지요. 반복문의 경우 모든 상황을 검사한다기보다는 특정 조건에서 값이 어떻게 들어가는지를 분석하는 경우가 더 많은데 이러한 상황을 검사하기 위해서 브레이크 포인트에 조건을 걸어야 합니다.브레이크 포인트를 거는 과정까지는 똑같습니다. 브레이크 포인트를 건 후 그 포인트에서 오른 클릭을 하면 Breakpoint properties 옵션이 있는 것을 확인할 수 있습니다. 이 옵션에서 조건문을 설정하여 디버거의 활성화 조건을 설정할 수 있습니다.먼저 Conditional을 활성화하여 어떤 조건에서 디버깅 화면으로 전환할지를 쓰면 되는데 이 창에 조건식을 쓰면 됩니다.또 hit count를 이용하여 조건을 걸 수도 있습니다. hit count에 값을 적용하면 해당 라인에 브레이크 포인트가 hit count만큼 잡힌 이후 디버깅 화면으로 전환하게 됩니다. hit count옵션은 반복문에서 한 100번쯤 이후에 디버깅을 시작하고 싶거나 하는 일이 생길 때 유용하게 쓸 수 있습니다.#스포카 #개발 #개발자 #꿀팁 #조언 #인사이트 #디버거 #디버깅 #디버그 #Eclipse
조회수 8027

AWS Lambda에서 메모리 설정값과 CPU 파워의 관계

안녕하세요. 데이블 백엔드 개발팀 최형주입니다.이번에 말씀드릴 내용은 서버 없는 컴퓨팅(Serverless Computing)의 널리 사용되는 AWS(Amazon Web Service)의 Lambda에 대한 내용입니다. AWS Lambda는 메모리 설정값에 따라 CPU 파워가 결정되는데, 그 메모리 설정값에 따라 CPU 파워가 어떻게 변화하는지에 대한 실험 내용을 설명하겠습니다. 처음에 AWS Lambda가 무엇인지 간략하게 소개를 하고 왜 이번 실험을 하게 되는지 배경 설명을 드릴 것입니다. 그다음 메모리 설정값에 따른 CPU 파워는 어떻게 결정되는지를 규명하고 마지막으로 이번 포스트를 간략히 요약겠습니다.목차1. AWS Lambda란?2. 실험배경3. 메모리 설정값과 CPU 파워의 관계4. 요약AWS Lambda란?AWS Lamba의 웹사이트AWS Lambda는 이벤트에 응답하여 코드를 실행하고 자동으로 기본 컴퓨팅 리소스를 관리하는 서버 없는 컴퓨팅 서비스입니다. 즉 코드를 업로드 하기만 하면 높은 가용성과 확장성을 보장하는 Lambda 플랫폼에서 코드를 실행합니다.AWS Lambda를 사용의 장점은 서버관리 불필요(Serverless), 지속적인 조정(Scaling), 밀리 초 단위의 측정 및 과금(Demand-based Pricing)입니다. 즉 서버를 프로비저닝(Provisioning)하거나 관리할 필요 없이 AWS Lambda에서 코드를 자동으로 실행하기 때문에 코드를 작성하고 AWS Lambda에 업로드하기만 하면 됩니다. 또한, 각 트리거에 대한 응답으로 코드를 실행하여 애플리케이션을 자동으로 확장하거나 축소합니다. 즉 코드는 병렬로 실행되고 각 트리거는 개별적으로 처리되어 정확히 워크로드(Workload) 규모에 맞게 조정됩니다. 과금 방식은 100밀리 초 단위로 코드가 실행되는 시간 및 코드가 트리거 되는 회수를 기준으로 요금이 부과됩니다. 코드가 실행되지 않을 때는 요금이 부과되지 않습니다.실험 배경AWS Lambda의 과금은 요청 요금과 컴퓨팅 요금의 합으로 계산됩니다. 요청 요금은 Lambda 함수를 호출한 총 요청 수에 대해 요금을 부과하고, 컴퓨팅 요금은 사용자가 업로드한 코드를 실행한 시간을 계산하여 100ms당 요금을 부과합니다. 컴퓨팅 요금은 사용자가 설정한 메모리 크기에 선형 비례하여 다르게 부과됩니다. 예를 들어 128MB 메모리에서는 100ms당 0.000000208$이고 256MB는 128MB의 약 두 배인 0.000000417$입니다. 그리고 512MB에서는 256MB의 두 배인 0.000000834$입니다. 또한, 더 큰 메모리를 사용할수록 더 큰 CPU 파워를 제공합니다.가장 큰 메모리 설정값을 사용하면 좋겠지만, 비용적인 측면을 고려해볼 때 사용자 입장에서의 사용 목적은 AWS Lambda로부터 최소한의 요금으로 최대한의 계산 효율을 뽑아내는 것입니다. 이 목적을 달성하기 위해서는 Lambda 함수를 실행할 때 메모리의 크기와 CPU의 파워(코어 수, 연산능력)를 명확하게 규명할 수 있어야 합니다. 메모리 크기는 사용자가 설정할 수 있습니다. 하지만 아쉽게도 아마존에서는 CPU 용량은 설정한 메모리 크기에 비례하여 결정된다고만 설명되어 있고 어느 정도의 성능을 가졌는지 명시하지 않고 있습니다.하지만 데이블의 백엔드 개발팀에서, 실험을 통하여 AWS Lambda에서 메모리 설정값에 따라 CPU 파워가 어떻게 변하는지 규명해냈습니다. 이제 그것을 이 포스팅을 통해 설명해 드리고자합니다.메모리 설정값과 CPU 파워의 관계"설정한 메모리 크기와 CPU 파워는 지수적 감쇠 관계(Exponential Decay)를 보인다"앞서 "CPU 파워는 메모리 설정한 값에 비례하여 증가한다”라고 했습니다. "그러면 어느 정도로 어떻게 비례하는가?”, “당연히 선형관계 아닌가?"라는 질문이 자연스럽게 나올 것입니다. 저희는 이 질문에 대답하기 위해 각 메모리 설정값별로 100만 번의 덧셈연산을 하여 각 설정 별 처리시간을 계산해 보았습니다. 다음 [그림 1]은 100만 번의 덧셈 연산을 했을 때 처리시간을 나타낸 그래프입니다. X축은 할당한 메모리의 크기를 나타내고 Y축은 처리시간을 초 단위로 측정한 것입니다. 보시는 바와 같이 처리시간은 메모리 크기에 따라 지수적으로 감소함을 알 수 있었습니다. 그러므로 AWS Lambda에서는 설정한 메모리 크기와 CPU 파워는 지수적 감쇠 관계(Exponential Decay)를 보인다고 결론을 내릴 수 있습니다. 예를 들면 현재 설정한 메모리보다 2배 높은 CPU 파워를 사용하고 싶으면 2배로 큰 메모리 용량을 설정해야 합니다.[그림 1] 메모리 설정값에 따른 처리시간필요로 하는 메모리 크기와 사용하는 응용에 따라 다르겠지만, 일반적으로 메모리의 크기에 상관없이 사용하는 비용이 거의 같다고 얘기할 수 있습니다. [그림 2]는 앞서 100만 번 덧셈 연산을 1만 번 호출했을 때의 각 메모리 설정값 별 요금을 나타낸 것입니다. X축은 설정한 메모리 크기이고 Y축은 각 메모리 설정값 별 요금입니다. 보시는 바와 같이 분포가 급격히 변하지 않고 대체로 균일한 것을 알 수 있습니다.[그림 2] 메모리 설정값에 따른 요금하지만 프로그램의 실행 시간은 단순히 CPU 파워로만으로 처리 시간이 결정되지 않기 때문에 다양한 요인을 검토해야 합니다. 알고리즘의 시간복잡도, 메모리의 크기와 접근 횟수, 네트워크 비용 등 다양한 것들이 처리 시간에 영향을 미치기 때문에 단순히 메모리 설정값을 늘려서 사용하는 방법은 옳지 못합니다. 그러므로 위 자료를 참고 용도로만 사용하셔서 하고자 하는 목적에 맞게 가장 최적의 메모리 설정값을 설정하시면 됩니다.요약AWS Lambda는 대표적인 서버 없는 컴퓨팅 서비스입니다. AWS Lambda에서 뛰어난 가성비를 얻고자 할 때는 각 설정값에 따라 제공하는 자원을 예측할 수 있어야 합니다. 여러 설정값 중 가장 성능에 큰 영향을 미치는 것은 사용하고자 하는 메모리 크기인데 이 크기에 따라 CPU 파워가 결정됩니다. 하지만 각 메모리 설정값에 따른 CPU 파워 정보를 아마존에서 제공해 주지 않고 있으므로 실험을 통해서 확인하였습니다. 실험 결과 설정한 메모리 크기와 CPU 파워는 지수적 감쇠 관계(Exponential Decay)를 규명했습니다. 이 규명은 단순한 프로그램에서만 확인한 것이기 때문에 최고의 효율을 가지는 AWS Lambda를 사용하기 위해서는 그 밖의 다양한 것들을 고려하여 설정해야 합니다.  기타머신 성능 및 정보- 사용하는 CPU는 Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz, 코어의 개수는 2개, 그리고 캐시의 크기는 25600 KB 임(사용하는 Microcode는 바뀔 수 있음)- 메모리는 약 3.67GB를 가짐실험에 사용한 Lambda 함수import osimport multiprocessingimport timeimport subprocessdef lambda_handler(event, context):mem_bytes = os.sysconf('SC_PAGE_SIZE') * os.sysconf('SC_PHYS_PAGES')mem_gib = mem_bytes/(1024.**3)num_cores = multiprocessing.cpu_count()#start_time = time.time()print subprocess.check_output ('vmstat -s', shell=True)sum = 0for i in range(1000000):sum += iif sum 000 == 0:print subprocess.check_output ('vmstat -s', shell=True)print subprocess.check_output ('vmstat -s', shell=True)hostname = subprocess.check_output ('hostname', shell=True)cpuinfo = subprocess.check_output ('cat /proc/cpuinfo', shell=True)meminfo = subprocess.check_output('cat /proc/meminfo', shell = True)print hostnameprint '--------------------------------------------------------------\n\n'print 'CPU Information'print cpuinfoprint '--------------------------------------------------------------\n\n'print 'Memory Information'print meminfoprint '\n\n\n\n'참고 자료https://aws.amazon.com/ko/lambda/details/#데이블 #개발 #개발자 #인사이트 #꿀팁 #AWS #조언
조회수 3524

PHP Codeigniter 환경에서 VUE 사용해보기

Overview이번에는 PHP Codeigniter 기반의 서비스에 VUE를 적용시키려고 고민했던 것들을 나누려고 합니다. VUE JS는 가상 DOM을 활용하여 실시간으로 반응 컴포넌트를 제작할 수 있는 프레임워크입니다. 또한, VUE-ROUTER 및 VUEX라는 컴페니언 라이브러리를 통해 url 라우팅 및 전역상태를 관리하기에도 탁월하죠. VUE와 다른 프레임워크와의 비교 부분은 여기를 참고해주세요. 브랜디의 관리자 서비스는 PHP Codeigniter 프레임워크로 제작되었습니다. 하지만 관리자 서비스의 규모가 점점 커지고 기능이 다양해지면서 “자주 사용하는 기능을 묶어 컴포넌트화하자!”라는 숙제가 남아 있었죠. 요즘 잠깐의 여유가 생겨 이때다 싶었습니다. 관리자 서비스에 VUE를 도입하기 위한 시도를 시작했는데요. 얼마 지나지 않아 문제점에 봉착했습니다. 바로 IE9.0…. 개발자의 숙적 IE가 또 한 번 발목을 잡았습니다. 임포트가 되지 않아….VUE를 좀 더 편리하게 사용하려면 JS의 모듈화가 필요했지만, ES2015에서는 import 혹은 require 구문을 지원하지 않아 불편하고, arrow 함수 또한 사용할 수 없습니다. 게다가 VUE의 JAX 탬플릿 구문을 사용할 수도 없었죠!! 뭔가 배보다 배꼽이 더 커질 것 같은 조짐이 보였습니다.결국 Webpack의 도움 없이 VUE를 적용하려던 시도는 여러 가지 난관을 만났고, Codeigniter 프로젝트 내부에서 Webpack을 사용하는 방법을 연구하기 시작했습니다. Webpack은 모듈 번들러입니다. Webpack의 메인 페이지를 방문하면 아래 네 개의 슬로건이 빙글빙글 돕니다.Bundle your scriptsBundle your imagesBundle your stylesBundle your assets아래의 이미지는 Webpack이 무엇을 하는 녀석인지 잘 설명해줍니다.Webpack은 실제로 번들러라고 광고하는것 처럼 Only Webpack 빌드만으로는 소스 파일들을 모아줍니다. 만약 webpack-dev-server로 실행하면 websocket을 통해 소스가 변경됐을 때 실시간으로 화면을 갱신해주는 개발 툴 제공 정도의 역할 밖에 없습니다. (…충분히 훌륭하잖아?)대부분의 기능은 엄청난 확장성을 가진 webpack의 설정으로 모듈로서 작동할 수 있죠. 예를 들면 Babel은 우리의 발목을 잡았던 IE를 위해 ES6로 작성된 js 문법을 IE에서 사용할 수 있는 ES5문법으로 너무나 쉽게 트랜스컴파일할 수 있습니다.하지만… 관리자 서비스는 위에서 언급했듯이 Codeigniter 기반입니다. 따라서 완벽히 VUE와 API서버를 분리하려면 로그인, 메뉴구성, 헤더, 푸터 등 PHP 기반으로 제작된 모든 기능들과 인증 등 기존 방식을 전부 새로 만들어야만 VUE를 온전히 사용할 수 있습니다.문제점들을 모두 해결하고 넘어가기엔 여유가 부족하기 때문에 조금씩 적용하자고 생각했습니다. 덕분에 webpack-dev-server의 실시간 소스 반영 기능을 포기해야만 했죠.(눈물) 우리의 서버는 node기반이 아닌 apache-php 기반이었기 때문입니다.자, 그럼 Codeigniter 프로잭트 하위에 웹팩을 포함시켜 Hello World까지 가는 짧은(?)여정을 시작해봅시다.Hello world로 가는 여정Node, npm 설치맥에서도 유사한 명령어로 제작할 수 있도록 CMD 위주로 진행하겠습니다. 먼저, 여기를 클릭해 Node를 설치합시다. 8.11.3 LTS버전으로 진행했습니다.맥에서는 Homebrew를 통해 간편하게~brew install node 설치 확인npm 잘 설치되었네요.web pack 폴더 생성 및 이동mkdir webpack cd webpack nom init으로 초기화npm init webpack, vue, babel 설치npm install -D webpack webpack-cli webpack-dev-server npm install -D vue-loader vue-template-compiler npm install -D babel-core babel-loader babel-preset-es2015 여기서 VUE는 설치하지 않습니다! 왜냐하면 VUE.js는 로딩만 하면 되고 필요하지 않습니다! (읭?) VUE는 Codeigniter view에서도 사용해야 하기 때문에 해당 view에서 import 해줍니다. 따라서 VUE 컴포넌트가 들어가는 시점에는 이미 전역에 vue.js 가 있습니다. 따라서 굳이 각 모듈마다 VUE를 import 했다가 webpack 설정에서 다시 vue.js를 제외할 필요는 없습니다.VUE와 template 태그를 로딩할 수 있는 로더도 설치하고, 트랜스컴파일을 위한 바벨, IE9를 지원하기 위한 es2015프리셋도 함께 설치합니다.webpack 빌드명령어 package.json의 script부분에 추가"scripts": { "build": "webpack --mode production", "build-dev": "webpack --mode development",   } 이제 VUE를 빌드할 명령어를 작성합니다. 위처럼 두 가지 명령어를 제작해두면, 추후 env를 통해 webpack.config.js를 분기시켜 원하는 환경으로 빌드할 수 있습니다. 또한 production 모드로 빌드할 땐 자동으로 옵티마이저 - uglify 내장 플러그인이 적용되어 익숙한 min.js형태로 빌드되며 development를 빌드할 땐 사람이 알아볼 수 있는 형태로 빌드되고, debugger 코드 또한 살아있습니다.weboack.config.js 작성const { VueLoaderPlugin } = require('vue-loader'); module.exports = {   entry: {     HelloWorld: './src/main.js'   },    module: {     rules: [       {         test: /\.vue$/,         loader: 'vue-loader',       },       {         test: /\.js$/,         loader: 'babel-loader',       }     ]   },    resolve: {     alias: {       'vue$':'vue/dist/vue.esm.js'     }   },    plugins: [     new VueLoaderPlugin()   ]  } webpack.config.js 가 없다면 생성한 후 위와 같이 작성합니다..babelrc 작성{     "presets": ["es2015"] } 테스트용 파일 작성1)main.js 작성import HelloWorld from './HelloWorld.vue' Vue.component('hello-world', HelloWorld); 2)HelloWorld.vue 작성 [removed] export default {   name: 'app',   data: () => {     return {       word1: 'Hello',       word2: 'World'     }   }  } [removed] 테스트 빌드npm run build-dev 빌드를 할 땐 기본적으로 ‘/dist/’ 하위에 소스코드가 떨어집니다. 자, 여기까지 진행하셨다면 폴더 구조는 다음과 같을 것입니다.지금까지 진행한 파일 모습입니다.뷰 컴포넌트가 잘 제작되고 등록되는지 확인하려면 기본 빌드 폴더인 dist 폴더에 Test.html을 작성해 브라우저로 열어봅시다.확인용 html 파일 작성<!DOCTYPE html> <html lang="en"> <head>     <meta charset="UTF-8">     <title>VUE Test</title>     <!-- VUE 플러그인 -->     [removed][removed] </head> <body>                     [removed][removed]     [removed]         new Vue({             el: '#vue'         })     [removed] </body> </html> 잘 나옵니다.정상적으로 VUE가 적용된 것을 확인합니다.코드이그나이터 설치이제 코드이그나이터 프로젝트 내부에서 VUE 컴포넌트를 출력해보기 위해 코드이그나이터 프로젝트를 생성합시다. 먼저 Codeigniter와 XAMPP를 다운로드 받습니다.Codeigniter 받으러 가기XAMPP 받으러 가기프로젝트 폴더 하위에 Codeigniter 프로젝트용 폴더를 생성합니다.mkdir codeigniter-with-vue-webpack cd codeigniter-with-vue-webpack 다운받은 Codeigniter를 해당 폴더에 압축 해제하면 Codeigniter 설치가 끝납니다.XAMPP 설치 및 DocumentRoot 변경XAMPP를 설치하고 DocumentRoot를 테스트 프로젝트 폴더로 설정한 뒤 아파치를 실행합니다.Codeigniter 프로젝트가 생성되었고, 서버 실행이 완료되었습니다. webpack 폴더를 Codeigniter 프로젝트 하위로 이동node-modules는 너무 크기 때문에 기본 파일만 복사하고, npm install로 설치합니다.Codeigniter에서 VUE를 사용하기 위한 webpack dist설정기존의 프로젝트에서 스크립트를 모아두는 폴더 하위로 빌드 결과 파일을 보내기 위하여 webpack 빌드 시 dist 폴더가 아닌 /application/scripts/vue/hello_world 하위로 빌드 결과 파일이 생성되도록 설정합니다.// 기존 module.exports = {   entry: {     HelloWorld: './src/main.js'   },    //... 생략 } // 변경후 module.exports = {   entry: {     '../../application/scripts/vue/hello_world/HelloWorld.js': './src/main.js'   },    //... 생략 } Codeigniter의 load->view 기능을 활용하여 파일 작성1)header.php// application/views/common/header.php <!DOCTYPE html> <html lang="en"> <head>     <meta charset="UTF-8">     <title>VUE Test</title>     <!-- VUE 플러그인 -->     [removed][removed] </head> 2)실제 view// application/views/vue/hello_world/vueTestPage.php <?php $this->load->view( 'common/header' ); ?> <body>                 [removed] [removed]     [removed]         new Vue({             el: '#vue'         })     [removed] </body> <?php $this->load->view( 'common/footer' ); ?> 3)footer.php// application/views/common/footer.php </html> 실제 프로젝트 구성과 유사하게 header, body, footer로 나누어 파일을 작성해봅니다. 실제로는 더 복잡하지만 이 정도만 나누겠습니다.Codeigniter 테스트용 컨트롤러 작성// application/controllers/Vue.php <?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');   class Vue extends CI_Controller {      public function index()     {         $this->load->view('vue/vueTestPage');     }  } 정말 심플(?)한 테스트용 파일 작성이 모두 끝났습니다! 이제 잘 작동하는지 확인해볼까요?코드이그나이터에서 helloworld 출력짜잔이번엔 문제의 IE에서 확인해봅시다.IE9.0 환경에서 확인IE에서도 무사히 출력되는군요. 이제 코드이그나이터 환경의 프로젝트에서도 IE까지 지원하며 무사히 VUE를 사용할 수 있게 되었습니다! (시간이 없어서 가상머신에 IE9가 설치된 윈도우7까지 테스트하진 못했습니다!) 모든 작업이 완료한 후, 파일 폴더 구조는 아래와 같습니다.붉은 네모 부분이 실제로 제작하거나 수정한 파일들입니다.Conclusion여기까지가 Codeigniter 프래임워크 환경에서 webpack + vue를 사용하기 위한 웹팩의 설정 과정 및 테스트 결과였습니다. php 서버를 사용해야 하기 때문에 webpack-dev-server의 핫리로드 기능을 사용하지 못하는 건 매우 안타까운 일입니다. 하지만 짧은 시간에 신기술을 도입하면서도 수많은 리스크를 회피할 수 있다는 건 나쁘지 않은 선택이라 생각합니다.위의 웹팩설정을 조금만 활용한다면 다른 프레임워크 프로젝트에서도 무리없이 VUE를 사용할 수 있을 겁니다! 비슷한 고민을 하셨던 개발자님들… 집에 가기 전 말고 오전에 Webpack을 설치해보세요. 안 그러면 저처럼 집에 못갈 수도 있으니까요!참고.gitignore 작성, index.php 제거 등은 내용에 포함하지 않았으며, 아래의 링크로 자세히 알 수 있음.Codeigniter index.php 없애기글강원우 과장 | R&D 개발2팀kangww@brandi.co.kr브랜디, 오직 예쁜 옷만 #브랜디 #개발자 #개발팀 #인사이트 #경험공유 #PHP
조회수 937

잔디 iOS 개발자 Chris, 그가 처음으로 공개한 '잔디 1호 사원' 스토리

편집자 주: 잔디와 함께 하고 있는 멤버는 총 50여 명. 국적, 학력, 경험이 모두 다른 이들이 어떤 스토리를 갖고 잔디에 합류했는지, 무슨 일을 하고 있는지 궁금해하는 분들이 많습니다. 잔디 블로그에서는 이 궁금증을 해결해 드리고자 ‘맛있는 인터뷰’를 통해 ‘잔디’ 멤버들의 이야기를 다루고 있습니다.◇ 우리가 앉아 있는 이 공간이 어떤 곳인지 소개해 달라Chris: 설마 했다. 내가 맛있는 인터뷰 대상자가 될지는.. 머리가 멍해 고통받던 중 당신이 추천한 그릴 타이로 오늘 장소를 선정했다. 이름만 들었을 땐 ‘거기 뭥미?’ 이랬는데, 와보니 알겠다. 예전에 와 본 적이 있다.◇ 자기소개 좀 해달라C: 반갑다. 잔디에서 iOS 개발 파트를 담당하고 있는 1호 사원 Chris라고 한다. 아주 오랜 기간 동안 원래 이름인 ‘봉규’라고 불렸다가 얼마 전 회사 내 호칭에 변화가 생겼다. 아직 Chris로 불리는 게 어색하다.◇ 어떤 일을 하며 월급을 받고 있는지?C: 앞서 소개했듯 난 iOS 개발자다. 이 글을 읽는 독자분들 중 아이폰으로 ‘잔디’를 사용 중이라면, 필시 내가 개발한 잔디를 이용하고 있는 거다. 마음이 조금 아프지만 기획에 대한 관심으로 지난 겨울 잠시 PM 팀으로 외도했었다. 하지만 결국 내 마음의 고향, iOS 개발로 돌아왔다.◇ PM팀으로 외도를 했던 이유가 궁금하다C: 기획이라는 업무에 관심이 많았다. 개발을 하다 보니 자연스레 기획에도 관심을 갖게 되었다. 한 번쯤 해보고 싶었던 일이었기 때문에 롤이 주어졌을 때 정말 재미있게 일했다.하지만 PM 일을 직접 해보니 마냥 재미있기만 하지는 않더라. 비즈니스는 물론이고 개발자와 디자이너의 의견을 수렴해 조율까지 해야 하는데 모두의 의견을 100% 반영할 수 없으니 여간 괴로운 일이 아니더라. 기획자의 길이 쉽지 않다는 것을 깨닫게 되었다.그리고 PM의 업무라는 게 쉽게 눈에 띄지 않는 일이다. 제품이 아무리 잘 나와도 기획자에게 ‘기획 참 잘나왔어요’ 라고 말하는 경우를 많이 접하진 않았을 거다. 여러분 주위에 기획자를 만나게 되면 ‘고생이 많으십니다’라고 응원 한마디 해줬으면 좋겠다.◇ iOS 개발자로 컴백한 이유는 무엇인가? 향간의 소문엔 코딩이 그리워 개발자로 돌아갔는 소문이 있다C: 회사 측에서 기획보다는 iOS 개발을 다시 맡아주면 좋겠다는 이야기를 들었다. 사실 별다른 고민 없이 제안을 받아들였다. 아무래도 초기부터 개발한 자식 같은 iOS가 늘 머리 한 구석에 있었다. 물론, 잔디를 사랑하는 마음도 크게 한 몫 했다. 결코 어필하고 싶어 이런 멘트를 남기는 게 아니다.◇ 보여주기 멘트인 것 같지만 감동 받았다. 그렇다면 Chris에게 잔디 iOS란 무엇인지 조금 더 말해달라C: 나의 분신이다.  iOS는 곧 Chris다. 아무것도 없는 백지상태에서 지금에 이르기까지 수많은 과정이 있었고, 그 과정의 중심엔 언제나 내가 있었다. iOS는 분신이라는 단어 외엔 표현할 방법이 없다. 오바가 아니라 사무실 어딘가에서 누군가 ‘iOS’ 라고 속삭이면 몸이 반응한다. iOS에 대한 이야기는 곧 나에 대한 이야기와 마찬가지이니까.내가 곧 잔디 iOS이자, 잔디 iOS가 곧 나이다.그만큼 애착을 갖고 개발 업무에 임하고 있다.◇ 멘트가 찰지다. 듣기론 PM 팀의 데니스와 특별한 인연이 있다고 하는데?C: 동아리 이야기를 하는 것 같다. 사회에 나오기 전 연합 동아리 활동을 한 적이 있는데, 데니스가 그 동아리 후배다. 기수 차이가 많이 나 직접적으로 알던 사이는 아니었다. 내가 동아리에 잔디 채용 공고를 공유해 데니스가 합류하게 되었다. 특별한 인연이라면 특별하다고 볼 수 있다.◇ 어떤 동아리인지 궁금하다SOPT라는 연합 동아리로 선배들이 후배들에게 개발/디자인 등에 대해 강의하는  동아리다. 당시 나는 학년 차가 조금 되어 수업을 듣기보단 가르치는 역할을 맡았어야 했는데, 매주 시간을 내어 수업을 준비할 자신이 없어 디자인 수업을 들었다.◇ 잔디 1호 사원은 역시 남다른 것 같다. 디자인 수업은 어땠는지?C: 그 수업을 통해 내가 디자인에 소질이 없다는 사실을 깨닫게 되었다. 그림을 그리면 늘 내가 생각한 것과는 다른 결과물이 나오더라.◇ 그런데 정말 잔디 1호 사원인가?C: 말 그대로 1호 사원이다. 회사가 법인으로 등록하기 이전부터 함께 했다. 얼마 전 잔디 2주년 파티가 있었다. 나는 입사한 지 2년이 넘었다. 격세지감을 느낀다. 처음 잔디에 들어왔을 때, 나를 제외한 모든 사람이 C-Level이었다. 그리고 나서 개발자, 디자이너가 순차적으로 들어왔던 걸로 기억한다.◇ 법인 설립도 전에 잔디를 어떻게 알고 지원했나?C: 제대를 3개월 앞둔 군인 시절, 아이폰 개발자를 찾는 연락을 받았다. 그렇지 않아도 제대하고 바로 개발 경험을 쌓을 수 있었으면 좋겠다고 생각했다. 솔직히 말하면 그 당시엔 잔디가 어떤 회사인지 탐색이나 해보자는 생각에 멤버들을 만났다.◇ 그럼 사람들을 만나고 입사를 결심한 건가?C: 당시에는 아무것도 없었다. 잔디라고 말은 해도 유형적인 형태의 무언가가 존재하지 않았다. 멋진 사람들과 함께하며 일을 배울 수 있을 것 같다는 생각에 합류했다.◇ 마음가짐이 남다를 것 같다C: 내 스스로 창립 멤버라 생각하고 있다. 어찌 되었든 잔디가 지금의 모습을 갖추기 전부터 함께 해서인지 애착이 남다르다. 첫 직장이라는 사실도 한 몫하고 있고.◇ 그때로 다시 돌아가면 똑같은 결정을 할 것인가?C: 물론이다. 솔직히 좋은 결정이었다고 생각한다. 잔디가 이렇게 잘 성장하고 있고, 지금은 누구보다도 잔디의 성공을 확신한다.◇ 마지막 질문이다. 여름 휴가 계획은?C: 스타트업인이 휴가라니? 하하. 농담이다. 아쉽지만 아직 여름 휴가 계획이 없다. 생기면 알려주겠다.◇ 맛있는 인터뷰의 공식 마무리! 다음 인터뷰이에게 묻고 싶은 질문이 있다면?C: 꼭 물어봐 주셨으면 한다. “잔디에서 이루고 싶은 꿈이 있다면?”을 물어봐 달라.#토스랩 #잔디 #JANDI #iOS #개발자 #모바일개발자 #앱개발자 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화 #사내문화
조회수 1583

파이콘 2018 도도 파이터 후기

아이들과 오전에 놀아주고 집안일을 마치고 나서 지하철을 탔다. 파이콘에 가는 길이었다. 5년째 참석하다 보니 이제 모든 세션을 빡빡하게 들어야 한다는 부담이 없다. 그래서 늦었지만 여유로웠다. 가는 길에 습관적으로 본  페이스북 타임라인은 이미 파이콘 이야기로 가득했다. 인증과 세션 자료 그리고 개발자를 뽑고 싶어 하는 회사들의 홍보로. 피드에서 스포카에서 진행하는 도도 파이터 이벤트를 보고 "이건 뭐야?" 싶어서  링크를 눌렀다. 어이쿠 개발자 컨퍼런스에 이게 도대체 뭐야오. 깔끔하게 잘 만들었다. 예제 코드를 살펴보니 설명도 잘 되어 있고 간단하다. 도전해 보고 싶은 생각이 들었다. 지하철 자리에 앉아 테더링을 연결하고 코딩을 시작했다. (사실 이것이 내가 세션은 듣지 않고 이틀 동안 부스/이벤트 체험만 하게 된 계기가 될 줄은 몰랐다.)대단히 잘 할 생각은 없었다. 세상에 굇수는 많으니까. 참여에 의의를 둬야지 싶었다. 비록 설명에는 “인공지능 코드”를 작성하여 다른 참가자와 겨루는 “인공지능 격투 대전”이라고 되어 있지만 당연해 보이는 규칙만 구현하고 나머지는 랜덤으로 동작하게 해서 제출해 보자 싶었다. 코엑스에 도착한 후  조금만 더 작업해서 제출하려고 하는데 아무리 제출해도 제출이 되지 않고 다음과 같은 메시지만 받았다.  코드가 테스트를 통과하지 못했습니다.아니 랜덤 봇이랑 하면 잘만 이기는데 왜 통과를 못하는 거야! 하던 차에 다시 설명을 읽어 보니  가만히 있는 더미 에이전트를 상대로 이겨야 제출이 이루어집니다.란다. 먼저 가면 손해인지라 가까워지면 더 안 가고 제 자리에서 주먹질만 시켰더니 더미 에이전트를 못 이기나 보다. 그래서 5초 아래로 시간이 남고 지금까지 한 번도 안 싸웠으면 앞으로 가도록 했더니 테스트를 통과하고 제출이 되었다.  제출에 성공하고 기분 좋게 돌아다니면서 다른 부스도 구경하고 있는데 회사 슬랙으로 함께 파이콘에 참여하고 계신 동료 분이 메시지를 보내셨다.봇이 화끈하면 뭐햐나. 이기면 장땡!스포카 부스에서 사람들이 제출한 봇들을 랜덤으로 붙여 주는 모양이었다. 후후. 어찌 되었든 이겼다고 하니 기분이 좋군.첫날 마지막 행사인 라이트닝 토크에서 스포카 도도 파이터 개발자분의 발표가 있었다. 회사에서 파이콘을 준비하면서 한 달 가까이 준비했다고 한다. 그리고 최근 2주도 동안은 도도 파이터만 달렸다는 이야기를 해주셨다. 컨퍼런스 이벤트로 만든 게임의 퀄리티가 좋아서 감탄한 것도 있었지만 팀에서 개발자들에게 그런 여유를 줄 수 있는 것도 부러운 마음이 들었다. 좋은 회사다. 도도 파이터 토너먼트는 다음날 파이콘 정식 행사가 끝나고 열렸다. 기억으로는 80명 정도가 참여했었던 것 같다. 조별 토너먼트를 진행하고 우승자들을 모아서 다시 토너먼트를 하는 구조였다.   싸워라! 싸워라!조금 늦게 왔더니 자리가 없어서 가장 앞자리에 나왔는데, 내 봇의 차례가 될 때마다 github 계정의 내 얼굴이 스크린에 크게 나와서 부끄러웠다. 외국 친구들은 자기 얼굴 github 프로필에 잘 넣어 놓던데, 왜 우리나라 개발자들은 자기 사진을 안 넣는 걸까... 게다가 내 봇이 나오는 경기는 모두 지루하고 얍삽한 느낌이 있어서 왠지 더 부끄러웠다. 니가 올래? 내가 갈까?다행히 조별리그도 통과해서 결승 리그에 올라갔다. 사실 한 두경기만 이기면 좋겠다 했었는데, 결승 리그에 올라가니 왠지 욕심이 생겼다. 제일 그럴싸하게 싸운 경기운 좋게도 아슬아슬하게 16강부터 4경기를 모두 이겨서 우승을 하고 문성원 CTO님께 해피해킹 키보드도 상품으로 받았다. 기분이 좋으면서도 멋쩍기도 한 기분이다. 사실 이번 파이콘에 와서 여러 곳의 부스를 참여하고, 이벤트도 적극적으로 참여해 본 이유는 내년에 8퍼센트도 파이콘에 스폰서로 참여하고 싶어서 였다. 우리의 (잉여) 개발력도 보여주고, 다른 개발자 분들과도 적극적으로 교류하고 싶은 마음이었다. 그 바람이 꼭 이루어질 수 있게 다음 파이콘 때 까지 좋은 분들을 모시고, 회사의 성장을 만들어 나가야겠다는 생각이 들었다. 마지막으로 내 코드를 공개한다.  https://gist.github.com/leehosung/f784d9efc71dce12855739647dd98877다시 코드를 살펴보니 개선할 점도 여러 개 보인다. 하지만 기존에 제출한 코드를 보기 좋게 정리만 하고 주석만 붙여 보았다. 사실 별 특별한 것이 없는 코드다. 실제 작성하고 테스트하는 것에도 한 시간이 걸리지 않았다.다음에 이런 기회가 온다면 글을 읽으시는 분들도 가벼운 마음으로 도전해 보셨으면 한다.  성적이 좋으면 더 좋지만 나쁘면 또 어떠한가? 개발자인 우리만 즐길 수 있는 놀이인데.  #8퍼센트 #에잇퍼센트 #파이콘 #파이썬 #Python #Pycon #이벤트참여 #참여후기 #개발자 #개발
조회수 3136

리디북스 서비스 장애 복구 후기

지난 8월 26일에는 약 21분간 리디북스 서비스 전체가 중단되는 장애가 있었습니다.사실 서버 스택 일부에만 영향을 주는 장애는 눈에 잘 띄지 않지만 꽤 흔하게 발생하는 일입니다. 기기 1대당 외부적인 요인으로 인한 장애가 평균 2년에 1번 발생한다고 가정하면, 서버가 100대 있을 때는 대략 1주일에 1번꼴로 장애가 발생하는 셈입니다.이런 형태의 장애는 서버 스택의 한 곳에서만 발생하므로, 이중화 혹은 클러스터링을 통해서 극복하곤 합니다. 또한 원인이 명확하므로 해당 기술에 대한 이해도가 높다면 비교적 빠른 시간 내에 복구가 가능합니다.그러나 이번에 리디북스가 경험한 장애는 달랐습니다. 현재 리디북스는 2개의 데이터센터와 클라우드에 인프라가 분산되어 있는데, 이 중에서 1차 데이터센터의 전원 공급에 문제가 생겨 특정 서버 랙에 있는 서버 17대가 동시에 내려간 것입니다. 즉, 소프트웨어나 머신의 물리적인 장애가 아닌, 데이터센터의 장애였습니다. AWS로 비유를 하자면 가용 영역(Availability Zone)의 장애라고 할 수 있겠습니다.원인에 대해이번 장애의 근본적인 원인은 데이터센터가 전원을 정상적으로 공급해주지 못한 것입니다. 물론 데이터센터 혹은 클라우드 서비스(IaaS)는 고객사에게 전원과 네트워크를 안정적으로 제공해주어야 하는 의무가 있습니다.하지만 이들 역시 천재지변이나 사람의 실수에 대한 대비가 100% 완벽할 수는 없습니다. 따라서 이러한 점을 사전에 고려하고 인프라를 설계하지 못한 것이 2차적인 원인입니다.이번 계기를 통해 데이터센터 이중화를 계획하게 되었고, 사용 중인 클라우드 역시 지역(Region) 전체에 장애가 생길 경우에 대한 대비가 되어있지 않아, 이번 계기로 복제 계획(Geo-Replication)을 세우게 되었습니다.구체적인 상황당시 전원이 차단되어 강제 종료된 서버들은 아래와 같습니다.데이터베이스 프록시 x 2메인 리버스 프록시 x 1읽기 분산용 MySQL 슬레이브 x 1서점용 웹 서버 x 3추천 알고리즘 API 서버 x 1알림센터 API 서버 x 2메인 스토리지 서버 x 2출판 플랫폼용 데이터베이스 x 2테스트 및 배치 작업용 서버 x 3그림으로 표현해 보자면, 대략 아래와 같은 상황에서… 아래와 같은 상황이 된 셈입니다.서버 스택의 여러곳에 순간적으로 장애가 발생한 상황공인 IP가 할당된 메인 프록시 서버 중 1대가 내려갔지만, 실제로는 아래와 같이 가상 IP로 구성을 한 상태였기 때문에 대기 중인(stand-by) 프록시가 동작하여 곧 서점에 장애 공지를 띄울 수 있었습니다.[이미지 출처: DigitalOcean™]공지 이후의 움직임우리는 데이터센터의 복구 시점을 명확히 알 수 없어서 신규 구축(provisioning)을 시작함과 동시에, 서버들의 물리적인 위치 이동을 고려하고 있었습니다. 그러나 다행히 10분이 지난 시점에서 전원 문제는 해결되었고, 서버들은 순차적으로 부팅이 완료되었습니다.일부 서버들은 부팅 과정에서 예상치 못한 지연이 발생하기도 하였지만, 모든 서버의 부팅이 완료된 이후에도 서비스는 완전히 정상으로 돌아오지 않았습니다. 당시 우리가 겪었던 문제와 해결책은 아래와 같습니다.A. 읽기 분산용 MariaDB 슬레이브의 복제 지연(replication lag) 문제슬레이브 서버의 부팅이 완료되자 데이터베이스 프록시(HAProxy)는 해당 서버를 정상으로 간주하여 라우팅 대상에 포함하게 되었고, 애플리케이션 서버들은 정상적으로 커넥션을 맺기 시작하였습니다. 하지만 해당 슬레이브는 수십 분간 마스터를 따라잡지 못한 상태였기 때문에 최신 데이터가 보여지지 않는 문제(stale data)가 있었습니다. 우리는 즉시 해당 슬레이브를 제거하였고 지연이 사라진 이후에 다시 서비스에 투입하였습니다.B. 읽기 분산용 슬레이브의 웜업(warm-up) 문제복제 지연은 사라졌지만 서버의 CPU 사용량이 크게 높은 상태가 한동안 유지되었고, 응답속도는 정상적인 슬레이브에 비해서 많이 느렸습니다. 왜냐하면 캐시가 비워진 상태에서 바로 서비스에 투입되어, 캐시 미스가 휘몰아치는 현상(cache stampede)이 발생하였기 때문입니다. 따라서 간단한 쿼리도 평소보다 오래 걸렸고, 그대로 둔다면 커넥션풀이 꽉 차는 현상이 발생할 것으로 예상되었습니다.곧 우리는 HAProxy로 해당 서버의 가중치를 10%로 낮추어 인입되는 쿼리의 양을 조절하였으며 응답속도는 정상 수치로 돌아오게 되었습니다. 이후 스크립트를 작성하여 수동으로 캐시를 채워나감과 동시에 점차 가중치를 높여 처리량을 정상화하였습니다.프로덕션에서 사용하는 서버는 innodb_buffer_pool 이 100G 이상으로 매우 크게 설정되어 있으며, 재시작 시 캐시가 날아가는 현상을 해결하기 위해 innodb_blocking_buffer_pool_restore 옵션을 적용하고 있습니다. 하지만 지금처럼 메모리를 덤프하지 못하고 비정상 종료가 된 상황에서는 해당되지 않았습니다.C. 인메모리 데이터의 보존 문제알림센터는 다양한 프로모션과 개인화된 정보를 전달해주는 공간입니다. 알림센터의 특징은 데이터의 영구 보존(persistency)이 필요하지 않고, 매일 수백만 건의 개인화된 메시지가 기록된다는 것입니다. 이러한 특징은 인-메모리 데이터베이스에 적합하므로 우리는 Redis를 마스터/슬레이브로 구성하여 저장소로 사용하고 있었습니다.어떠한 이유로든 Redis를 재시작해야 할 경우가 생기면, 메모리 상의 데이터가 날아가는 것을 방지하기 위해 주기적으로 스냅샷을 남기고 있습니다만, 이번에는 로그가 마지막까지 기록되지 못한 상태에서 메모리의 데이터가 날아가 버렸습니다.다행히 알림 발송과 관련된 메타정보는 모두 MariaDB에 기록하고 있으므로, 우리는 이를 기반으로 소실된 시점부터의 알림을 순차적으로 재발송할 수 있었습니다. 물론 모든 알림이 신규 상태로 간주되어 아이콘이 잘못 노출되는 문제가 있었지만, 고객님들은 너그럽게 이해해 주신 것 같습니다. 😅그래서 앞으로는?리디북스 DevOps 멤버들은 이번 데이터센터 장애를 통해 현재 인프라의 한계점을 실감하였고, 앞으로의 개선 방향에 대해 고민하게 되었습니다.몇 가지를 정리하면 다음과 같습니다.랙 단위로 장애가 발생할 수 있음을 인지하고 대비하자.같은 기능을 하는 서버를 하나의 랙이나 같은 가용 영역에 두지 말자.2차 데이터센터는 더 이상 옵션이 아닌 필수다.낙뢰나 지진으로 인해 데이터센터에 문제가 생길 수도 있다.긴급하게 프로비저닝이 필요한 상황에 대비하자.문서화가 되어 있더라도 경험이 없다면 동일한 구성에 많은 시간이 소요된다.모든 구성요소들에 대한 Ansible 스크립트를 작성하여두자.캐시 웜업 스크립트도 작성하여 두자.백엔드 구성요소들 간의 불필요한 의존 관계를 끊자.단 한 줄의 코드라도 참조하고 있다면 이는 독립적인 것이 아니다.언제나 서비스 지향적인 설계를 추구하자.Uptime을 관리하자.최대 180일을 기점으로 무조건 리부팅을 하자.재시작 과정에서 다양한 문제와 개선점이 발견될 것이다.커널 패치, 보안 패치를 할 수 있는 것은 덤이다.아래와 같은 긍정적인 면도 발견하였습니다.장애 상황이 실시간으로 Slack 채널을 통해 전파되었음진행 상황에 대해 모두가 동일한 수준으로 이해할 수 있었다.모니터링 연동(integration) 기능 때문에라도, Slack은 유료로 구매할만한 값어치가 충분하다.같은 기능을 하는 서버들이 다른 랙에 많이 분산되어 있었다.인프라가 확장될 때마다 빈 공간에 필요한 서버를 추가했을 뿐이지만, 자연스럽게 물리적인 위치가 분산되는 효과가 있었다.이 외에도 특정 클러스터를 구성하는 노드들을 분산하여 배치시키자.서버별로 오너쉽이 부여되어 있어서 빠르게 복구가 된 점여러 명의 백엔드 개발자들이 병렬적으로 복구를 진행할 수 있었다.마지막으로넷플릭스의 엔지니어들은 무질서한 원숭이(Chaos Monkey)라는 프로그램을 만들어서 운영한다고 합니다. 이 원숭이는 서비스 인스턴스들을 무작위로 중단시키는 역할을 합니다. 다소 황당하게 들리지만, 넷플릭스에는 일부 서비스에 장애가 발생하더라도 나머지 부분은 문제없이 운영되어야 한다는 원칙이 있으므로, 이를 수시로 시뮬레이션하는 과정을 통해 복구 능력을 높여둔다는 것입니다.실제로 이렇게 급진적인 아이디어를 실천할 수 있는 회사는 매우 드물 것입니다. 하지만, 우리는 이번 계기를 통해 무질서한 원숭이의 필요성을 절감하였고, 이로 인해 서버를 주기적으로 리셋하는 정책을 만들게 되었으며 모든 단일 장애점(SPoF)에 대한 대비를 시작하게 되었습니다.장애를 단순히 피해라고만 생각한다면, 서로를 비난하고 책임을 전가하는 상황이 펼쳐질 것입니다. 하지만 고객의 불편함과 맞바꾼 매우 비싼 경험이라고 생각한다면, 보다 튼튼하고 회복탄력적인 시스템을 갖추기 위해 노력하게 될 것입니다. 그러다 보면 언젠가는 데이터센터 전체에 문제가 생겨도 버틸 수 있는 모습으로 진화할 것이라고 생각합니다.#리디북스 #장애복구 #역경돌파 #개발 #개발후기 #개발자 #서버개발 #서버
조회수 4804

AWS Instance Scheduler Bot 적용기

이 포스팅은 총 2부로 이어지며 현재는 2부입니다.1부 : AWS 비용 얼마까지 줄여봤니?2부 : AWS Instance Scheduler Bot 적용기1부에서 AWS 비용을 절감하기 위한 Instance Scheduler에 대한 소개를 하였습니다. 2부에서는 Instance Scheduler의 설정을 손쉽게 변경하기 위한 Bot을 적용한 사례에 대해서 소개합니다.Bot의 필요성Instance Scheduler의 설정을 변경하기 위해서는 정보를 담고 있는 Dynamo DB 의 데이터를 변경해야 합니다. AWS Console을 이용하여 직접 수정할 수도 있지만 여전히 불편하고 느립니다. 더군다나 이를 이용하는 사용자가 DB Table의 구조와 AWS Console 사용법을 알고 있어야 하고 비 개발자라면 더 쉽지 않은 문제입니다. 하지만 Bot을 이용하면 사용자는 어려운 DB Query나 구조를 알아야 할 필요도 없고 손쉽게 채팅 메시지를 통해 Bot에게 질의하고 처리 결과를 응답받을 수 있습니다.Outgoing WebhookJANDI에서는 Incoming Webhook과 반대되는 개념으로 Outgoing Webhook을 제공합니다. 특정 키워드로 시작하는 메시지가 있을 경우 내용을 설정된 URL Endpoint에 POST로 Webhook을 보내줍니다. Webhook을 수신한 곳에서는 일련의 처리 후 메시지 데이터 형식을 맞춰 응답하게 되면 채팅창에 메시지를 표시하게 됩니다. 이를 통해 다른 외부 시스템과 연동할 수 있습니다.POST Data예를 들어 날씨 키워드로 Outgoing Webhook을 생성했다면 /날씨 메시지가 시작될 때 다음과 같은 데이터가 Webhook으로 발송됩니다.{ "token": "YE1ronbbuoZkq7h3J5KMI4Tn", "teamName": "Toss Lab, Inc.", "roomName": "토스랩 코리아", "writerName": "Gloria", "text": "/날씨 서울", "keyword": "날씨", "createdAt": "2017-07-19T14:49:11.266Z" } token을 이용하여 요청의 유효성 체크를 할 수 있고 text를 적절히 파싱 하여 요청에 부합하는 처리를 할 수 있습니다.ResponsePOST Data를 적절히 처리 후 결과를 채팅창에 응답 메시지를 표시하고 싶다면 아래와 같은 JSON Data를 Response body에 넣어주면 됩니다.{ "body" : "서울의 현재 날씨", "connectColor" : "#FAC11B", "connectInfo" : [{ "title" : "온도", "description" : "최고:28.00, 최저:24.00, 현재: 24.30" }, { "title": "날씨", "description": "흐리고 비" }] } 이를 이용하여 Instance Scheduler에도 적용해봤습니다.Schedule BotSchedule Bot은 Instance Scheduler의 Lambda 함수에 함께 포함되어 작동하며 스케쥴 조회 / 예외 설정, 서버 강제 시작/중지, 서버 상태 조회 등의 기능을 수행합니다.API Gateway와 Lambda 함수를 연결하여 Endpoint URL을 생성하고 Outgoing Webhook URL로 설정하여 Webhook으로 Lambda 함수가 실행될 수 있도록 하였습니다. Lambda 함수는 Cloudwatch를 통해서 실행되면 Scheduler가 작동되고 API Gateway를 통해 실행되면 Schedule Bot이 작동됩니다.Schedule Bot 명령어Schedule Bot은 다음과 같은 명령어를 수행합니다./서버 help : 도움말 /서버 [스케쥴명] status : 현재 서버 상태 조회 /서버 [스케쥴명] info : 오늘의 스케쥴 조회 /서버 [스케쥴명] info [YYYY-MM-DD] : 특정일 스케쥴 조회 /서버 [스케쥴명] exception info : 오늘의 스케쥴 예외 조회 /서버 [스케쥴명] exception info [YYYY-MM-DD] : 특정일 스케쥴 예외 조회 /서버 [스케쥴명] exception set [YYYY-MM-DD] [start|stop] [h:m] : 예외 설정 /서버 [스케쥴명] exception del [YYYY-MM-DD] [start|stop] : 예외 삭제 /서버 [스케쥴명] force_start : 서버 강제 실행 /서버 [스케쥴명] force_stop : 서버 강제 중지 Schedule Bot 작동 화면Schedule Bot은 서버병이라는 컨셉으로 인격화(?)에 힘썼습니다.스케쥴 정보 조회서버 상태 조회서버 강제 시작/중지명령어 오류마무리AWS 기반의 서비스를 운영하는 스타트업이라면 더욱더 현실적으로 부딪히는 비용 문제에 대해서 저희가 고민한 내용과 솔루션에 대해서 공유하였습니다.아직 적용기간이 길지 않아 절감비용에 대해 수치적인 데이터를 언급하기는 힘들지만 많은 금액이 절감될 거라 예상하고 있습니다.저희와 같은 고민을 하고 있다면 Instance Scheduler를 적극 권장합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #AWS #도입후기 #일지 #인사이트 #경험공유
조회수 1003

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글윤석호 이사 | 브랜디 CTOyunsh@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 1195

비트윈의 멀티티어 아키텍처를 위한 프레젠터 이야기

블로그 첫 글에서 비트윈의 시스템 아키텍처에 대해 다룬 적이 있습니다. 시스템 구성의 미래에 대한 계획으로 멀티티어 아키텍처에 대해 언급했었는데, 이는 프로토콜을 단순화시키고 배포 자동화를 가능하게 하기 위해서 클라이언트와 비즈니스 로직을 담당하는 서버 사이에 일종의 게이트웨이를 두는 것이었습니다. 그 외에도 여러 가지 필요성이 생겨 해당 역할을 담당하는 프레젠터라는 것을 만들게 되었고 비트윈의 채팅 시스템에 적용하게 되었습니다. 만드는 과정 중에 여러 기술적인 문제들이 있었고 이를 해결하기 위한 노력을 하였습니다. 이 글에서는 비트윈 시스템에서의 프레젠터에 대해 이야기 하고자 합니다.프레젠터¶프레젠터는 일종의 게이트웨이 입니다. 기존의 시스템에서는 클라이언트들이 ELB를 통해 채팅 서버에 직접 TCP 연결을 하였습니다. 하지만 비트윈 PC버전과 자체 푸시 서버를 만들면서 ELB로는 해결할 수 없는 부족한 점들이 생겼고, ELB의 부족한 점을 채워줄 수 있는 시스템이 필요하게 되었습니다. ELB를 대체하는 역할 외에도 다른 여러 필요했던 기능들을 제공하는 프레젠터를 만들기로 하였습니다.프레젠터는 ELB의 역할을 할 뿐만 아니라 여러 다른 기능들도 제공합니다.프레젠터의 기능¶패킷을 적절한 샤드로 중계¶비트윈에서는 커플 단위로 샤딩하여 같은 커플의 채팅 요청에 대해서는 같은 채팅 서버에서 처리하고 있습니다. Consistent Hash를 통해 커플을 여러 채팅 서버로 샤딩하고 ZooKeeper를 이용하여 이 정보를 여러 채팅 서버 간 공유합니다. 프레젠터 또한 ZooKeeper와 연결을 하여 어떤 채팅 서버가 어떤 커플을 담당하는지에 대한 정보를 알고 있도록 설계되어 있습니다. 따라서 프레젠터는 첫 연결 시 보내는 인증 패킷을 보고 해당 채팅 연결에서 오는 요청들을 어떤 채팅 서버로 보내야 할지 판단할 수 있습니다. 어떤 채팅 서버로 보낼지 판단하는 과정은 처음 한 번만 일어나며, 이후 패킷부터는 자동으로 해당 채팅 서버로 중계합니다.프레젠터의 이런 기능 덕분에 클라이언트는 더 이상 어떤 채팅 서버로 붙어야 하는지 알아내는 과정 없이 아무 프레젠터와 연결만 맺으면 채팅을 할 수 있게 되었습니다. 기존에는 클라이언트들이 여러 채팅 서버 중 어떤 서버에 붙어야 하는지 확인하는 작업을 한 후에 할당된 채팅 서버로 연결 맺어야 했습니다. 그래서 클라이언트가 채팅 서버와 연결을 맺기 위해 다소 복잡한 과정을 거쳐야 했지만, 이제는 클라이언트가 프레젠터의 주소로 연결 요청만 하면 DNS Round Robin 통해 아무 프레젠터와 연결하는 방식으로 프로토콜을 단순화할 수 있었습니다. 덕분에 새로운 채팅 서버를 띄울 때마다 ELB를 Warm-Up 시켜야 했던 기존 시스템의 문제가 없어졌습니다. 그래서 비트윈 개발팀의 오랜 염원이었던 채팅 서버 오토스케일의 가능성도 열렸습니다.많은 수의 연결을 안정적으로 유지¶PC버전과 푸시 서버를 만들면서 기존의 채팅 연결과 다르게 많은 수의 연결이 장시간 동안 유지 되는 경우를 처리할 수 있어야 했습니다. 기존에는 TCP 릴레이를 하도록 설정된 ELB가 연결들을 받아주었습니다. 한 머신당 6만 개 정도의 Outbound TCP 연결을 맺을 수 있는데, ELB도 트래픽에 따라 여러 대의 머신에서 돌아가는 일종의 프로그램이므로 이 제한에 걸린다고 생각할 수 있습니다. 따라서 많은 수의 연결을 맺어놓고 있어야 하는 경우 ELB에 문제가 생길 수 있다고 판단했습니다. (과거 ELB가 연결 개수가 많아지는 경우 스케일아웃이 안되는 버그 때문에 문제가 된 적이 있기도 했습니다) 또한 클라이어트 연결당 내부 연결도 하나씩 생겨야 하면 클라이언트가 연결을 끊거나 맺을 때마다 서버 내부 연결도 매번 끊거나 연결해야 하는 오버헤드가 발생합니다.이를 해결하기 위해 프레젠터에서는 TCP 연결을 Multiplexing하는 프로토콜을 구현하여 적은 수의 내부 연결로 많은 수의 클라이언트 연결을 처리할 수 있도록 하였습니다. 서버 내부에서는 고정된 개수의 몇 개의 연결만 맺어 놓고 이 연결들만으로 수많은 클라이언트 연결을 처리할 수 있습니다. 이처럼 TCP Multiplexing을 하는 것은 Finagle과 같은 다른 RPC 프로젝트에서도 지원하는 기능입니다.TCP Multiplexing 프로토콜을 통해 많은 수의 클라이언트 연결을 소수의 서버 내부 연결로 처리합니다.또한, 프레젠터는 많은 수의 SSL 연결을 처리해야 하므로 암복호화 로직을 실행하는데 퍼포먼스가 매우 중요하게 됩니다. 채팅 서버 한 대를 제거하거나 하는 경우 많은 연결이 한꺼번에 끊어지고 연이어 한꺼번에 연결을 시도하게 되는 경우가 있을 수 있는데, 이 때 대량의 SSL Handshaking을 하게 됩니다. 기존 서버들로 대량의 SSL Handshaking을 빠른 시간안에 처리하기 위해서는 높은 퍼포먼스가 필요합니다. Java로 작성된 프로그램만으로 이런 퍼포먼스 요구사항을 달성하기 어려우므로, 클라이언트와의 연결을 담당하는 부분은 OpenSSL, libevent를 이용한 C++로 코드로 작성하였습니다. 인증 패킷을 파싱하거나 패킷들을 릴레이 하는 등의 로직을 담당하는 부분은 Alfred라는 Netty를 이용하여 만든 인하우스 RPC 라이브러리를 이용해 작성되었습니다. 연결을 담당하는 부분은 TCP 연결을 유지하는 역할과 들어온 패킷들을 Netty로 작성된 모듈로 릴레이 하는 역할만 담당하므로 매우 간단한 형태의 프로그램입니다. 짧은 시간 안에 어럽지 않게 구현할 수 있었습니다.클라이언트의 연결을 받아주는 역할을 하는 부분은 C++, 실제 로직이 필요한 부분은 Java로 작성하였습니다.여러 네트워크 최적화 기술의 지원¶ELB에는 여러 네트워크 최적화 기술들을 아직 제공하지 않는 경우가 있습니다. 대표적으로 HTTP/2 혹은 SPDY, QUIC, TCP Fast Open 등이 있습니다. 특히 모바일 환경에서는 SSL Handshaking 등 부가적인 RTT로 인한 지연을 무시할 수 없으므로 이런 기술들을 이용한 초기 연결 시간 최적화는 서비스 퀄리티에 중요한 부분 중 하나입니다. ELB는 AWS에서 관리하는 서비스이므로 AWS에서 이런 기능들을 ELB에 적용하기 전에는 이용할 수 없지만, 프레젠터는 직접 운영하는 서버이므로 필요한 기능을 바로바로 적용하여 서비스 품질을 높일 수 있습니다. ELB에서 이미 제공하는 최적화 기술인 SSL Session Ticket이나 다른 몇몇 기술은 이미 적용되어 있고 아직 적용하지 않은 기술들도 필요에 따라 차차 적용할 예정입니다.프레젠터의 구현¶C++ 연결 유지 모듈¶프레젠터는 퍼포먼스를 위해 C++로 작성되었습니다. 이는 Pure Java를 이용한 암복호화는 프레젠터에서 원하는 정도의 퍼포먼스를 낼 수 없기 때문입니다. 처음에는 OpenSSL과 libevent를 이용해 작성된 코드를 JNI를 통해 Netty 인터페이스에 붙인 event4j라는 인하우스 라이브러리를 이용하려고 했으나, 코드가 복잡하고 유지보수가 어렵다는 점 때문에 포기하였습니다. 그 후에는 netty-tcnative를 이용해보고자 했으나 테스트 결과 연결당 메모리 사용량이 큰 문제가 있었고, 이를 수정하기에는 시간이 오래 걸릴 것 같아 포기하였습니다. 결국, 페이스북에서 오픈소스로 공개한 C++ 라이브러리인 folly를 활용하여 프레젠터를 작성하게 되었습니다. folly의 네트워크 API들이 OpenSSL과 libevent를 이용해 구현되어 있습니다.릴레이 로직¶프레젠터는 첫 인증 패킷을 파싱하여 릴레이할 채팅 서버를 판단하며, 이후의 패킷부터는 실제 패킷을 까보지 않고 단순 릴레이 하도록 설계하였습니다. 처음의 Netty 파이프라인에는 Alfred 프로토콜을 처리할 수 있는 핸들러들이 설정되어 있어 인증 패킷을 파싱 할 수 있으며 인증 패킷에 있는 정보를 바탕으로 어떤 채팅 서버로 패킷을 릴레이 할지 결정합니다. 그 이후 파이프라인에 있던 핸들러를 모두 제거 한 후, 읽은 byte 스트림을 Multiplexing Protocol 프레임으로 감싸서 그대로 릴레이 하는 매우 간단한 로직을 담당하는 핸들러 하나를 추가합니다. 덕분에 로직 부분의 구현도 매우 간단해질 수 있었으며, 채팅 서버에 API가 추가되거나 변경되어도 프레젠터는 업데이트할 필요가 없다는 운영상 이점도 있었습니다.Multiplexing Protocol¶프레젠터의 Multiplexing Protocol은 Thrift를 이용하여 직접 정의 하였으며, 비트윈 개발팀 내부적으로 사용 중인 RPC 라이브러리인 Alfred에 이 프로토콜을 구현하였습니다. Thrift를 통해 C++과 Java로 컴파일된 소스코드를 각각 프레젠터의 연결 처리 부분과 로직 처리 부분에서 이용하여 통신합니다. 프레젠터에서는 Multiplexing된 TCP 연결들을 Stream이라고 명명하였으며 이는 SPDY나 HTTP/2에서의 호칭 방법과 유사합니다. SPDY나 HTTP/2도 일종의 Multiplexing 기능을 제공하고 있으며, 프레젠터의 Multiplexing Protocol도 SPDY 프레임을 많이 참고하여 작성되었습니다.수 많은 클라이언트와의 TCP연결을 Stream으로 만들어 하나의 내부 TCP연결을 통해 처리합니다.Alfred에서는 Multiplexing 된 TCP 연결을 Netty의 Channel 인터페이스로 추상화하였습니다. Netty에서 TCP 연결 하나는 Channel 하나로 만들어지는데, 실제 Stream도 Channel 인터페이스로 데이터를 읽거나 쓸 수 있도록 하였습니다. 이 추상화 덕분에 비트윈 비즈니스 로직을 담당하는 코드에서는 Stream으로 Multiplexing 된 TCP 연결을 마치 기존의 TCP 연결과 똑같이 Channel을 이용해 사용할 수 있었습니다. 그래서 실제 비즈니스 로직 코드는 전혀 건드리지 않고 프레젠터를 쉽게 붙일 수 있었습니다.로드 밸런싱¶클라이언트는 Route53에서 제공하는 DNS Round Robin 기능을 이용하여 아무 프레젠터에 연결하여 채팅 요청을 날리게 됩니다. 하지만 무조건 동등하게 Round Robin 하게 되면 새로 켜지거나 하여 연결을 거의 맺지 않고 놀고 있는 프레젠터가 있는데도 연결을 많이 맺고 있는 기존 프레젠터에에 연결이 할당되는 문제가 생길 수 있습니다. 충분한 시간이 흐르면 결국에는 연결 개수는 동등하게 되겠지만, 처음부터 놀고 있는 프레젠터에 새로운 연결을 가중치를 주어 할당하면 로드를 분산되는 데 큰 도움이 될 것입니다. 그래서 Route53의 Weighted Routing Policy 기능을 이용하기로 하였습니다. 현재 연결 개수와 CPU 사용량 등을 종합적으로 고려하여 Weight를 결정하고 이를 주기적으로 Route53의 레코드에 업데이트합니다. 이런 방법으로 현재 로드가 많이 걸리는 서버로는 적은 수의 새로운 연결을 맺게 하고 자원이 많이 남는 프레젠터로 더 많은 새로운 연결이 맺어지도록 하고 있습니다.스케일 인/아웃¶AWS에서는 트래픽에 따라 서버 개수를 늘리기도 하고 줄이기도 하는 AutoScaling 이라는 기능이 있습니다. 프레젠터가 스케일 아웃될때에는 프레젠터가 스스로 Route53에 레코드를 추가하는 식으로 새로운 연결을 맺도록 할 수 있습니다. 하지만 스케일 인으로 프레젠터가 제거될 때에는 Route53에서 레코드를 삭제하더라도 함부로 프레젠터 서버를 종료시킬 수 없습니다. 종종 클라이언트의 DNS 캐싱 로직에 문제가 있어, Route53에서 레코드를 삭제되었는데도 불구하고 이를 업데이트하지 못해 기존 프레젠터로 연결을 시도하는 경우가 있을 수 있기 때문입니다. 따라서 프레젠터 클러스터가 스케일 인 될 때에는 기존의 모든 연결이 끊어지고 충분한 시간 동안 새로운 연결이 생기지 않은 경우에만 서버를 종료시켜야 합니다. AutoScaling Group의 LifeCycleHook을 이용하여 위와 같은 조건을 만족 시켰을 때에만 프레젠터 서버를 완전히 종료시키도록 하였습니다.못다 한 이야기¶프레젠터라는 이름이 이상하다고 생각하시는 분들이 있을 것으로 생각합니다. 멀티티어 아키텍처를 이야기할 때 프레젠테이션 티어, 어플리케이션 티어, 데이터베이스 티어로 구분하곤 하는데 이 프레젠테이션 티어에서 나온 이름입니다. 지금은 실제 프레젠터가 하는 역할과 프레젠테이션 티어가 보통 맡게 되는 역할에는 많은 차이가 있지만, 어쩌다 보니 이름은 그대로 가져가게 되었습니다.프레젠터에서 AutoScaling을 하기 위해 LifeCycleHook을 이용합니다. 이때 프레젠터를 위해 LifeCycleHook 이벤트를 처리하는 프로그램을 직접 짠 것이 아니라 비트윈 개발팀이 내부적으로 만든 Kharon이라는 프로그램을 이용하였습니다. Kharon은 인스턴스가 시작되거나 종료될 때 실행할 스크립트를 작성하고 인스턴스의 특정 위치에 놓는 것만으로 LifeCycleHook을 쉽게 이용할 수 있게 하는 프로그램입니다. Kharon 덕분에 비트윈 내 다양한 시스템에서 별다른 추가 개발 없이 LifeCycleHook을 쉽게 활용하고 있습니다. 후에 Kharon에 대해 자세히 다뤄보도록 하겠습니다.정리¶비트윈 개발팀에서는 오랫동안 유지되는 수많은 채팅 서버 연결들을 처리하고 클라이언트와 서버 간 프로토콜을 단순화시키는 등 여러 이점을 얻고자 ELB의 역할을 대신하는 프레젠터를 만들었습니다. 프레젠터를 만드는 과정에서 여러 기술적 문제가 있었습니다. 이를 해결하기 위해 C++로 연결 유지 모듈을 따로 작성하였고 Multiplexing Protocol을 따로 정의하였으며 그 외 여러 가지 기술적인 결정들을 하였습니다. 이런 과정에서 시행착오들이 있었지만 이를 발판 삼아 더 좋은 기술적 결정을 내리기 위해 고민하여 결국 기존 시스템에 쉽게 적용할 수 있고 쉽게 동작하는 프레젠터를 만들어 이용하고 있습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 jobs@vcnc.co.kr로 이메일을 주시기 바랍니다!

기업문화 엿볼 때, 더팀스

로그인

/