개발 피드 목록

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 잡학다이너마이트 변규홍 님을 만나보세요:)사진1. 스켈터랩스의 SW Engineer, 변규홍님규홍님의 인터뷰는 2개 파트로 나뉘어져 있습니다. 에서는 인공지능 대화 엔진을 개발에 관한 스켈터랩스 업무 이야기를 담았습니다. 을 아직 읽지 않은 독자들이라면, 먼저 ‘스켈티 인터뷰 w.Kyuhong’을 읽고 오시기를 추천합니다.’PART2. About Kyuhong Byun.Q. 자기 소개에 ‘20년 전부터 컴퓨터 공부를 시작한 컴퓨터 덕후'라는 얘기를 했다. 컴퓨터를 좋아하게 된, 그리고 개발자의 길을 선택한 계기가 따로 있나.A. 초등학교 2학년 때 컴퓨터에 대한 만화책을 우연히 선물받았다. 만화책에서 ‘GW 베이직(GW-BASIC)’언어로 작성된 컴퓨터 프로그래밍 코드가 딱 한 줄 적혀있더라. 그 한 줄을 컴퓨터가 실행하는 과정을 몇 페이지에 걸쳐 설명하는 책이었다. 책을 읽으며, ‘이걸 익힌다면 나도 게임을 만들 수 있지 않을까'란 생각을 했다. 당시 나는 일본의 컴파일(COMPILE)이라는 회사에서 제작한 PC용 게임 잡지인 디스크 스테이션(Disc Station)에 푹 빠져있었다. 그래서 GW베이직을 공부한다면 컴파일 사에 입사해서 아기자기하고 재밌는 게임을 만들 수 있겠다는 꿈을 꾸게되었다.Q. 어렸을 적의 꿈을 현실로 만들기가 쉽지 않지 않나. 어떻게 컴퓨터 공부를 이어갈 수 있었나.A. 어머니를 통해 상업계 고등학교 교과서인 ‘전자계산일반'을 구할 수 있었다. 그 책을 보면서 컴퓨터에 퀵베이직(Quick-Basic) 코드를 하나씩 입력해 보니 신기하게도 전부 그대로 실행이 되더라. 교과서를 따라 만들어보니 간단한 사칙연산을 실행하는 것에 멈추는 컴퓨터 계산기보다 훨씬 똑똑한 복합 연산 계산기까지 만들 수 있었다. 이러한 관심이 자연스럽게 한국정보올림피아드 대회 준비로 이어졌다. 대회를 준비하며 더욱 다양한 프로그래밍 언어를 배웠고, 복잡한 문제를 해결하는 알고리즘과 자료구조 구현법에 대하여 하나씩 접근해갈 수 있었다. 당시 <컴과 대화 맥스>라는 프로그램이 있었는데, 지치지 않고 나와 수다를 떨어주는 프로그램이었다. 사실 맥스는 그닥 똑똑한 프로그램은 아니었다. 툭 하면 무슨 말인지 모르겠다는 응답만 반복했지만, 그렇게 끈덕지게 대답을 이어가고 지치지 않는 다는 점이 재밌었다. 맥스와 대화하면서 맥스보다 더 똑똑하고 흥미롭게 대화를 이어갈 수 있는 프로그램을 만들고 싶은 욕심이 생겼다.Q. 어라, 그렇다면 컴파일 사의 게임프로그래머가 되는 꿈은 접은건가.A. 안타깝게도 2000년대 초에 컴파일 사는 도산했다. 그러나 컴파일 사를 이끌었던 니이타니 마사미츠 회장이 20여년 만에 컴파일마루라는 회사를 세워 게임 개발자로 돌아왔더라. 68세의 나이에 게임 개발은 물론 홍보를 위해 인터넷 방송까지 진행하고 있다. 다시 일어서는 니아티니 회장의 행보를 보면서 자극을 많이 받고있다.Q. 개인적으로 최근 가장 뿌듯함을 느낀 순간을 말한다면.A. 스켈터랩스는 자율출퇴근제를 운영하고 있다. 여기서 ‘자유'가 아닌 ‘자율'이라는 점에 주목해야 한다. ‘자율'이란 자신이 최선의 퍼포먼스를 낼 수 있도록 스스로 알맞은 규칙을 정해서 동료들과 협업함을 뜻한다고 생각한다. 사실 엄격한 출퇴근 시스템을 갖춘 이전 직장에서 스켈터랩스로 넘어오면서 한동안 자기 관리 문제를 겪었다. 체중도 많이 불었다. 건전한 몸에 건전한 정신이 깃든다고 하지 않나. 그래서 회사 근처의 헬스장에 등록하고 PT(Personal Training)을 시작했는데, 입사 초기만 해도 97킬로에 달한 몸무게를 현재는 20킬로 이상 감량한 상태다. 처음에 PT를 받기 시작했을 때 몸은 정말 힘든데, 체중도 변하지 않는 상태가 몇 주간 지속되었다. 스트레스 받고 지치기만 하더라. 그런 시기를 인내하고 견디니, 그제서야 몸에 변화가 온 것을 느낄 수 있었다. 그것도 엄청난 변화를 말이다. 이렇게 나름의 다이어트 성공 가도를 달리고 있는 것이 최근 느낀 뿌듯한 경험 중 하나다.Q. 네임카드(Name Card)에 독특한 자기소개를 발견할 수 있다. 네이버 웹툰 <공대생 너무만화>를 자문했는데, 어떻게 시작하게 되었나.A. 4년 전 카이스트에서 아티스트 레지던시 프로그램에 참여중이셨던 최삡뺩 작가와 인연을 맺게 되었다. <공대생 너무만화>의 자문으로 친구를 소개하는 과정에서 자연스럽게 친구와 함께 자문을 맡게 되었다. 사실 자문이라고 해서 거창한 것은 아니다. 공대 개그에 현실성을 불어넣는다거나 디테일을 살리는 정도다. 예를 들어 기절해 있던 공대 남학생이 이런 말을 들으면 너무 깜짝 놀라 눈을 번쩍 뜰 것 같은 대사를 요청받았다. 마침 당시에 전문연구요원 제도 존폐에 대한 얘기가 오가고 있었고, 이에 ‘전문연구요원 폐지됐대'라는 대사를 만들었다. 이 웹툰은 컷툰 형식으로 구성되어있는데, 해당 컷에 수많은 댓글이 달리는 것을 확인할 수 있었다.Q. 웹툰을 자문하면서 재미있는 일도 많았을 것 같다. 예상하지 못한 독자의 피드백을 받는 재미도 있을텐데, 에피소드를 소개해 줄 수 있나.A. 재미있는 에피소드야 굉장히 많다. <공대생 너무만화>의 이야기는 주인공이 대학에 입학하면서 시작된다. 주인공이 입학할, ‘토목공학과'지만 ‘토목공학과스럽지 않은' 학과 이름이 필요했다. 그래서 ‘사회에코시스템디자인과'라는 이름을 만들어냈다. 그런데 공교롭게도 독자들 사이에서 엉뚱한 오해가 시작되더라. <공대생 너무만화>가 교육부의 프라임 사업(산업연계 교육활성화 선도대학, PRIME) 홍보용 기획이라고. 학과를 통폐합하여 융합학과를 만드는 프라임 사업 때문에 비슷한 이름의 학과들이 생겼으니 그렇게 오해할 만은 했다. 작품이 진행되면서 오해가 풀린 일부 독자들은 아예 <공대생 너무만화>가 프라임 사업 비판 웹툰이라는 창의적인 해석을 내놓기도 하였다. 이런 저런 다양한 오해 속에서도 묵묵히 작업하는 작가분들에 대한 존경심까지 들었다. 사진2. <공대생 너무만화> 15화, 1화, 6화, © 최삡뺩웹툰의 첫 컷에 각종 수학, 과학, 혹은 프로그래밍 관련 문제를 출제하기도 했는데 문제를 받아보는 독자들의 반응이 정말 재미있다. 열심히 문제를 풀기도 하지만 엉뚱한 반응이 나오기도 한다. 한번은 ‘<발받악에 땀 망희 났어>를 아희 프린터로 실행하면 ?이다’라는 문제를 냈다. 딱 보면 발바닥에 땀이 많이 났다는 한국어 문장을 외계어처럼 적은 것처럼 보이지 않나. 그렇지만 사실 ‘아희'라는 프로그래밍 언어로 된 코드다. ‘발받'이라는 코드가 숫자 3과 5를 뜻하고 ‘땀'은 곱셈, ‘망'은 출력이라는 뜻이다. 다시 말해 ‘3과 5를 곱셈하여 출력하시오'라는 코드다. 이 컷의 베스트 댓글은 ‘그냥 한글이라길래 왠지 모르게 순간 설렌 문과입니다'더라. 이외에도 기막히게 재밌는 댓글들이 쏟아졌다. 나중엔 몇몇 아희 인터프리터의 개발자들이 테스트 케이스로 이 문제를 넣어주더라.Q. PT부터 웹툰 자문까지 다양한 활동을 하고있다. 평소의 취미는 무엇인가, 취미 부자로 보인다.A. 일단 서사, 즉 이야기라는 게 담긴 것이라면 뭐든 좋아한다. 만화부터 영화, 소설, 드라마, 연극까지 서사가 있는 콘텐츠는 다양하게 보는 편이다. 일본 스타일의 롤플레잉 게임도 서사가 풍부해서 즐겨 하고있다. SF소설 작성 특강을 듣고 꾸준히 소설도 쓰고 있다. 최근에는 컴퓨터의 기술 표준에 대한 논의에 관심을 갖고 있다. 한국인터넷거버넌스포럼(Kr-IGF, Korean Internet Governance Forum)이라는 행사에 패널로 참여했고, 인터넷 도메인 주소 규칙을 제정하는 KGP(Korean Generation Panel) 회의도 정기적으로 참관하고 있다. 깊은 논의를 거쳐 인터넷 생태계가 건강하고 발전적인 방향으로 운영되기를 바라고 있다.Q. 개발자이지만 다방면에 관심을 갖고 있는 것으로 보인다. 최근에 관심을 가지고 있는 이슈가 특별히 있는지.A. 얼마 전, 소프트웨어 마에스트로(SW Maestro) 과정 홈커밍 데이를 다녀왔다. 과학기술 정보통신부에서 매년 컴퓨터 분야에서 기술이 우수하거나 발전 가능성이 높은 100여명의 연수생과 산업계의 시니어 엔지니어 멘토를 을 선발하고 산업계의 시니어 엔지니어를 멘토로 선정하여 뛰어난 엔지니어로 성장하도록 독려하고 있다. 2010년 선발된 1기 연수생으로 홈커밍데이에 찾아가 보니 8기 연수생까지 폭넓은 연령층의 개발자 선, 후배들과 하루 종일 업계 동향, 최신 기술은 물론 다양한 주제로 이야기를 나눌 수 있었다. 이렇게 개발자로서 성장할 수 있는 기회와 개발자들이 교류할 수 있는 네트워크가 더 풍성해지고 넓어졌으면 좋겠다. 현재도 여러 기업과 비영리조직에서 다양한 캠프, 기술 컨퍼런스를 개최하는 등 다양한 성장과 교류의 장이 만들어지고 있는데, 이를 더욱 활성화하고 지원하여 양질의 개발자 네트워크가 형성되는 데 정부가 할 수 있는 일이 더 있지 않겠나.인공지능 대화 엔진 개발에도 정부의 도움이 절실하다. 다른 언어와 달리 한국어는 특히 엔진 개발을 위한 기초 자료가 너무나 부족한 게 현실이다. 자연언어처리 분야에서는 각 언어마다 이 언어에서 사람들이 실제로 쓰는 문장들을 폭넓게 모아둔 ‘말뭉치’(Corpus)가 기술 발전에 큰 영향을 준다. 특히 문장의 성분을 자세히 분석하여 함께 정리된 말뭉치가 풍성하면 풍성할수록, 머신러닝을 비롯한 다양한 기술에 힘입어 컴퓨터 스스로 사람의 언어를 스스로 학습함은 물론 이를 활용한 더 많은 가능성을 열 수 있다. 그러나 현재는 공개된 말뭉치가 너무 적고, 시대에 따라 개선되는 것도 미약하다. 그나마 안심하고 쓸 수 있는 신뢰도 있는 자료는 2000년대 초반에 구축되고 더 이상 개선이 없는 국립국어원의 ‘21세기 세종 계획’이 전부다. 많은 개발자들이 공통적으로 이 문제를 토로하는데, 어떻게 해야 메시지를 잘 전달하고 개발자끼리도 협업하여 기술 전반을 발전시킬 수 있는지에 대해 고민하고 있다.사진3. 소프트웨어 마에스트로 과정, 과학기술정보통신부가 프로그램을 운영하고 있다. 출처: SW Maestro 과정 페이스북Q. 개발자를 꿈꾸는 이들에게 하고싶은 말이 있다면.A. 수학에는 왕도가 없다고 한다. PT를 받으며 체중을 조절하는 것도 인내의 과정이었다. 개발자의 길도 마찬가지라고 생각한다. 지금 당장 눈 앞에 멋있는 결과를 내기 위해 튜토리얼(Tutorial)만 따라한다면, 단기간 내에 성과를 볼 수는 있지만 새로운 문제에 직면했을 때 스스로 해결책을 찾기 어려워진다. 때문에 튜토리얼을 따라하더라도 그 과정을 세심하게 들여다보고 원리를 이해하기 위해 인내심을 갖고 공부하면 좋겠다. 내가 구현한 코드, 내가 실행시킨 명령이 어떤 가정, 어떤 제반 환경, 어떤 원리에서 작동하는지 궁금해하고 깊이 파다 보면, 자연스럽게 같은 걸 두 번 세 번 공부하지 않고 한번에 깊게 이해할 수 있다.또한 혼자 공부할 경우 다른 사람이 이해하기 좋은 코드를 짜는 것을 소홀히 하게 되는 경향이 있다. 다른 사람이 작성한 코드를 읽어보고, 어떻게 하면 동료들이 이해하기 쉬운 코드를 짤 수 있는지 생각할 수 있을 때 폭넓은 발전을 할 수 있다. 좋은 동료와 함께 공부하는 것을 추천한다. 학생 신분이라면 소프트웨어 마에스트로 과정과 같은 기회를 적극 활용하는 것도 한 방법이다. 실제로 스켈터랩스에도 나를 비롯해 소프트웨어 마에스트로 과정을 거친 엔지니어들이 여러 명 있다.Q. 변규홍님 개인의 꿈은 무엇인가.A. 나와 하루 종일 재미있게 대화하는 챗봇을 개발하고 싶다. 일본어로 된 만화책을 집어넣으면 한국어 번역본이 바로 나오는 컴퓨터 프로그램도 만들고 싶다. 이 꿈을 위해서는 자연언어처리 기술과 머신러닝 발전에 기여하는 것이 우선이라고 생각한다. 그리고 이런 꿈을 함께 꿀 수 있는 좋은 동료를 스켈터랩스에서 더욱 많이 만나고 함께 나아가고 싶다.Q. 마지막으로 하고싶은 말은.A. 내가 가장 동경하는 개발자 중 한 분이 후배들에게 꼭 들려주고 싶은 이야기가 무어냐는 질문에 이렇게 답했다. ‘시간에 쫓겨 살지 말아요. 서두르지 않아도 괜찮아요. 넘어지거든 울어도 돼요. 아무렇지 않은 척 굴지 말고 자기 자신을 좀 더 아껴요.’ 내 생각에 우리 시대의 개발자들은 그 어느 때보다 강도 높은 경쟁 속에 살고 있다. 그 경쟁에서도 이 말을 잊지 말고 자신을 아끼고 돌아보며 살아가면 좋겠다.#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #개발팀 #팀원인터뷰 #팀원소개 #팀원자랑

비트윈의 서버에는 사용자들이 올리는 수많은 사진이 저장되어 있습니다. 2016년 3월 기준으로 커플들이 데이트에서 찍은 사진, 각자의 프로필 사진, 채팅을 나누며 올린 재미있는 짤방까지 약 11억 장의 사진이 저장되어 있습니다. 비트윈에서는 이러한 사용자들의 소중한 추억을 잘 보관하고, 사용자들의 요청을 빠르고 비용 효율적으로 처리하기 위해서 많은 노력을 기울이고 있습니다. 이번 포스팅에서는 비트윈 개발팀이 사용자들의 사진 처리를 보다 효율적으로 하기 위해서 어떠한 노력을 하였는지 공유하고자 합니다.기존의 아키텍쳐¶비트윈 사용자가 채팅창이나 모멘츠 탭에서 사진을 업로드 할 경우, 해당 사진은 업로더 서버라고 불리는 전 세계 각지에 퍼져 있는 사진 업로드 전용 서버 중 가장 가까운 서버를 자동으로 찾아서 업로드 됩니다. 업로더 서버는 사진을 해당 AWS Region의 S3 bucket에 적재하고, 미리 지정된 크기의 썸네일을 자동으로 생성하여 역시 S3에 저장합니다. 그리고 Tokyo Region에 있는 비트윈 메인 서버에 이 결과를 토큰 형태로 전송하여 DB에 그 정보를 저장하도록 합니다. 이러한 과정을 통해서 일반 HTTP request보다 훨씬 큰 용량을 가지고 있는 사용자의 사진이 최대한 적은 지연시간을 가지고 업로드되도록 합니다.사용자가 올린 사진은 원본이 S3에 저장됨과 동시에 미리 정해진 사이즈로 썸네일을 생성해서 저장된다.하나의 사진이 대략 5장에서 6장의 서로 다른 크기의 썸네일로 리사이징이 되는데, 이는 클라이언트의 디스플레이 크기에 따라서 최적화된 이미지를 내려주기 위함이었습니다. 예를 들어서 아주 작은 썸네일이면 충분한 채팅 프로필 표시 화면을 그리기 위해서 사용자가 올린 3백만 픽셀이나 되는 원본 사진을 받아서 클라이언트가 리사이징 하는 것은 지연 시간뿐 아니라 과도한 데이터 사용이라는 측면에서 효율적이지 않기 때문에 작게 리사이징 해놓은 사진을 내려주는 것이 더 바람직합니다.비트윈 사용자들의 넘치는 사랑(?)에 비트윈은 출시 후 5년 동안 약 11억 장, 썸네일을 모두 합치면 66억 장의 사진을 저장하게 되었습니다. 이 사진은 전부 AWS S3에 저장되어 있으며, 썸네일을 합친 총 용량은 2016년 3월 기준 무려 738TB였습니다. 이에 따라 사진을 저장하기 위한 S3 비용이 전체 인프라 운영 비용에서 상당 부분을 차지하게 되었습니다.기존 아키텍쳐의 비효율성¶비트윈 팀은 어느 날 위와 같은 기존의 사진 전송 아키텍쳐에 의문을 가지게 되었습니다. 비트윈 서비스가 다른 서비스와 가장 다른 특징 중의 하나는 커플 간의 데이터는 그 둘 사이에서만 공유된다는 점입니다. 일반적인 웹사이트 같은 경우, 하나의 게시물 혹은 이미지가 수천 수 만명의 유저에게 전달되지만 비트윈에서는 그렇지 않습니다. 즉, 개별 사진의 Fan-out이 작다는 점을 특징으로 가지고 있습니다.그리고 클라이언트에서 LRU를 기반으로 한 파일 캐쉬를 사용하고 있는데, 이를 통해서 위에서 말씀드린 채팅창 프로필 사진 같은 경우 클라이언트에서 캐쉬될 가능성이 매우 커지게 됩니다. 그리고 CDN으로 사용하고 있는 AWS의 CloudFront에서도 약 30~40%의 추가적인 Cache hit을 얻을 수 있었습니다. 즉, 이미 Fan-out이 낮은 리소스가 높은 Cache hit rate를 가지는 사용패턴을 가지고 있는 셈이 됩니다.더군다나 사용자의 디바이스 사이즈에 따라서 미리 리사이징 해놓은 썸네일 중 일부는 아예 사용하지 않는 사용패턴이 나타나기도 합니다. 아이패드와 같은 큰 디스플레이를 가진 클라이언트를 쓰는 사용자와 아이폰4를 사용하는 사용자가 필요로 하는 썸네일의 크기는 다를 수밖에 없기 때문입니다.아래의 그래프는 S3 접근 로그를 분석해서 파악한 특정 기간 내에 같은 해상도를 가지는 썸네일을 클라이언트가 한 번 이상 재요청 하는 비율을 나타내는 그래프입니다. 하루 내에 같은 해상도의 사진을 요청하는 경우는 10% 가 되지 않으며, 한 달 안에도 33% 정도에 불과한 것을 알 수 있습니다.특정 기간 내에 S3에 저장된 썸네일이 다시 요청되는 비율결국 비트윈 팀은 미리 여러 해상도의 썸네일을 준비해서 저장해 놓은 아키텍쳐보다는 사용자가 요청할 때 그 요청에 알맞게 리사이징된 썸네일을 새로 생성해서 내려주는 게 훨씬 비용 효율적이라는 결론에 도달하게 됩니다.새로운 아키텍쳐¶Skia¶하지만 이러한 온디맨드-리사이징 아키텍쳐로의 변환에 가장 큰 걸림돌이 있었습니다. 바로 사진의 리사이징에 오랜 시간이 걸린다는 점이었습니다. 비록 아키텍쳐 변화를 통해서 저희가 얻을 수 있는 비용 이득이 크더라도, 비트윈 사용자 경험에 느린 사진 리사이징이 방해가 되어서는 안 되었습니다.이때 저희가 찾은 것이 바로 Skia 라이브러리였습니다. Skia 라이브러리는 Google에 의해서 만들어진 2D 그래픽 라이브러리로써, 크롬이나 안드로이드, 모질라 파이어폭스 등에 사용되고 있었습니다. 그리고 이 라이브러리는 CPU 아키텍쳐에 따라서 인스트럭션 레벨로 매우 잘 최적화가 되어 있었습니다. 저희가 기존에 쓰고 있던 ImageMagicK에 비해서 거의 4배 속도로 이미지 리사이징을 처리할 수 있었으며, 총 CPU 사용량도 더 적었습니다. 저희는 이 라이브러리를 Python으로 wrapping한 PySkia라는 라이브러리를 내부적으로 만들어서 사진 리사이징에 사용하기로 하였습니다.WebP¶저희는 여기서 한발 더 나아가 보기로 했습니다. 단순히 리사이징만 Skia로 대체하는 것이 아니라, 원본 사진의 저장도 더 효율적으로 할 방법을 찾게 되었습니다. 그 결과 자연스럽게 떠오른 것이 비트윈 스티커 시스템에서 사용되었던 WebP 방식이었습니다. WebP 역시 구글이 만든 이미지 인코딩 방식으로써, 비슷한 화질을 가지는 JPEG에 비해서 약 26% 정도의 용량이 절약된다는 점에서 장점이 있습니다.온디멘드-리사이징¶위에서 언급한 대로 Skia 리사이징과 WebP 원본 저장을 합하여 아래와 같이 필요한 해상도의 사진을 그때그때 리사이징 하는 온디멘드-리사이징 아키텍쳐로 옮겨가게 되었습니다.사용자가 올린 사진은 원본이 WebP로 변환되어 S3에 저장된다. 클라이언트의 요청이 있을 때는 그때그때 요청한 사이즈로 리사이징한 썸네일을 생성해서 내려준다.리사이저 서버가 사용자의 요청을 받아서 원하는 해상도의 사진을 리사이징해서 내려주기까지 채 100ms가 걸리지 않는데, 이 정도면 사용자의 경험에 영향을 주지 않는다고 판단하였습니다. 리사이저 서버는 업로더 서버와 함께 세계 각지의 AWS Region에 배포되어 있으며, 이는 사용자가 요청한 사진을 최대한 빨리 받아가기 위함입니다.기존 사진 마이그레이션¶위와 같은 아키텍쳐 전환을 통해서 새롭게 업로드 되는 사진들은 원본만 WebP로 변환되어 저장한 후 요청이 들어올 때만 온디멘드 리사이징이 되지만, 그동안 비트윈 사용자들이 축적해 놓은 11억 장의 사진은 여전히 여러 사이즈의 썸네일로 미리 리사이징이 되어 있는 비효율적인 상태였습니다. 저희는 이 사진들도 마이그레이션하는 작업에 착수했습니다.11억 장이나 되는 원본 사진들을 전부 WebP로 변환하고, 나머지 50억 장의 미리 생성된 썸네일 사진을 지우는 작업은 결코 간단한 작업이 아니었습니다. 저희는 이 작업을 AWS의 Spot Instance와 SQS를 통해서 비용 효율적으로 진행할 수 있었습니다.Auto Scaling with Spot instance¶마이그레이션 작업은 크게 다섯 단계로 이루어져 있습니다.커플 단위로 작업을 쪼개서 SQS에 쌓아놓습니다.Worker가 SQS로부터 단위 작업을 받아와서, 해당 커플에 존재하는 모든 사진을 WebP로 변환하고 S3에 올립니다.S3로의 업로드가 확인되면, 그 변경 사항을 DB에 적습니다.기존 썸네일 사진들을 삭제합니다.기존 썸네일이 삭제되었다는 사실을 DB에 적습니다.작업을 하는 도중에 얼마든지 Worker가 중단되거나 같은 커플에 대한 작업이 두 번 중복되어서 이루어질 위험이 있습니다. 이를 위해서 마이그레이션 작업을 멱등적으로 구성하여서 사용자의 사진이 손실되는 등의 사고가 발생하지 않도록 하였습니다. 중간마다 DB에 접근해서 변경된 내용을 기록해야 하는 작업의 특성상, 작업의 병목 구간은 비트윈 DB였습니다. 그리고 사진 인코딩을 바꾸는 작업의 특징상 많은 CPU 자원이 소모될 것으로 생각하였습니다.DB에 부담이 가지 않는 범위내에서 많은 CPU 자원을 끌어와서 작업을 진행해야 할 필요성이 생긴 것입니다. 이 조건을 만족하게 하기 위해서 SQS를 바라보는 Worker들로 Auto-scaling group을 만들었습니다. 그리고 이 Auto-scaling group은 c3.2xlarge와 c3.4xlarge spot instance로 구성되어 있으며, DB의 CPU 사용량을 메트릭으로 하여 Scaling이 되도록 하였습니다. 작업은 주로 DB의 부하가 적은 새벽 시간에 집중적으로 이루어졌으며, 이 인코딩 작업은 대략 4일 정도가 소모되었습니다. 작업 과정에서 Tokyo Region에 있던 c4.2xlarge와 c3.4xlarge spot instance를 최대 140대를 사용했고, 총 사용 시간은 6,767시간이었습니다. 사용한 instance의 계산 능력을 ECU로 환산하면 총 303,933 ECU · hour를 작업에 사용하였습니다. 마이그레이션에 사용된 EC2 비용을 바탕으로 계산해 보면, 백만 장의 WebP 인코딩을 위해서 사용한 비용이 $1.8 밖에 되지 않았다는 것을 알 수 있습니다.작업 과정에서 AWS 서비스에 의외의 병목 구간이 있다는 것을 알게 되었는데, S3 단일 버킷에 1분당 1천만 개 이상의 object에 대한 삭제 요청이 들어오면 Throttling이 걸린다는 사실과 SQS의 in-flight message의 개수가 12만 개를 넘을 수 없다는 것입니다.결과¶위의 아키텍쳐 변화와 마이그레이션 작업 후 저희의 S3 비용은 70%가 넘게 감소했으며 전체 인프라 비용의 상당 부분이 감소하였습니다. 온디멘드 리사이징으로의 아키텍쳐 변화는 Storage 비용과 Computation 비용 사이의 교환이라고 볼 수 있는데, 아래 그래프에서 볼 수 있듯이 확연한 비용 절감을 달성할 수 있었습니다.총 마이그레이션 비용¶항목사용량비용 ($)EC2 spot instance6,767 hrs1,959.11SQS188,204,10489.59S3 Put/Get Requests2,492,466,8605,608.34총비용7,657.04마이그레이션 결과¶항목Before MigrationAfter Migration감소량 (%)S3 # of objects6.65 B1.17 B82.40S3 storage738 TB184 TB75.06비용 감소¶사진 저장과 리사이징에 관련된 비용이 68% 감소하였음못다 한 이야기¶이번 포스팅에서는 최근에 있었던 비트윈 사진 아키텍쳐의 변화에 대해서 알아보았습니다. 주로 사용자의 경험을 방해하지 않는 조건에서 비용을 아끼는 부분에 중점을 두고 저희 비트윈의 아키텍쳐 변화에 대해서 설명해 드렸습니다. 하지만 이 글에서 미처 언급하지 못한 변화나 개선 사항들에 대해서는 다루지 못했습니다. Tokyo Region에서 멀리 떨어져 있는 사용자를 위해서 전 세계 여러 Region에 사진 저장/전송 서버를 배포하는 일이나, 사진을 로딩할 때 낮은 해상도로부터 차례대로 로딩되도록 하는 Progressive JPEG의 적용, 사진을 아직 받아오지 못했을 때 Placeholder 역할을 할 수 있는 사진의 대표색을 찾아내는 방법 등이 그것입니다. 이에 관해서는 후에 자세히 다뤄보도록 하겠습니다.정리¶비트윈 개발팀에서는 많은 인프라 비용을 소모하는 기존 썸네일 저장 방식을 개선하여 70%에 가까운 비용 절감 효과를 보았습니다. 기존의 썸네일을 미리 생성해놓는 방식으로부터 클라이언트가 요청할 때 해당 크기의 썸네일을 리사이징해서 내려주는 방식으로 변경하였고, WebP와 Skia등의 새로운 기술을 적용하였습니다. 이를 통해서 사용자 경험에는 거의 영향을 주지 않은 상태로 비용 절감 효과를 볼 수 있었습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!