텀 프로젝트에서 제품 프로젝트로 - 성준영님

텀 프로젝트에서제품 프로젝트로

6개월간의 현업 경험담

경희대학교 성준영

발표자 소개

성준영

경희대학교 컴퓨터 공학과 3학년

T.G.WinG

Nomadstar 서버개발 인턴

[email protected]

0_ 발표자 소개

1_ 개요

스타트업 인턴으로 맡은 포지션

거쳐간 업무들

2_ 현업 경험담

6개월의 타임라인

AWS 서버이전 > 컨퍼런스와 문서화

AWS Lambda > 코드리뷰와 리펙토링

REST API 설계 > 좋은 설계

3_ 정리

경험과 교훈의 요약

입사 전과 비교해본 나

결론

목차

개요 > 스타트업 인턴으로 맡은 포지션

쓰담 (Beta)솔직한 사용자 후기를 이용하여,

반려 동물의 특성에 딱 맞는 제품을

찾을 수 있도록 돕는

반려동물 제품 리뷰 SNS

어플리케이션 (Adroid)

1.1

쓰담 서비스의 서버 관리 및

백엔드 API, 데이터베이스 작성과 설계

1.1 개요 > 스타트업 인턴으로 맡은 포지션

개요 > 거쳐간 업무들

AWS Lambda

Dynamodb

이미지 포맷 변경

REST API

1.2

관리자 페이지

쓰담 홈페이지

AWS 서버이전

이미지 압축 및 리사이징

1.2

AWS Lambda

Dynamodb

이미지 포맷 변경

REST API

관리자 페이지

쓰담 홈페이지

AWS 서버이전

이미지 압축 및 리사이징


1.2

가장 많은 것을 배우고 느꼈던

세가지 경험을 여러분과 공유하려 합니다.


AWS 서버이전 > 컨퍼런스와 문서화

AWS Lambda > 코드리뷰와 리펙토링

REST API > 좋은 설계

현업 경험담 > 6개월의 타임라인2.1

관리자 페이지

AWS 서버이전

홈페이지

이미지 압축및 리사이징

AWS Lambda이전 시작( ~ 현재 )

이미지 포맷변경

REST API( ~ 현재 )

16.09 16.12 17.02

dynamodb

버전 1.0 개발

현업 경험담 > AWS 서버이전 > AWS 란?2.2

컴퓨팅 서버, 스토리지, 데이터베이스, 네트워크 등

웹 서비스에 필요한 모든 서비스를 제공하는

세계 1위 클라우드 서비스 플랫폼

현업 경험담 > AWS 서버이전 > AWS Summit Seoul2.2

입사 전 (16.5.17) 참관했던

코엑스에서 열린 AWS 컨퍼런스

AWS 임직원과 전문가들의 강연

파트너 솔루션 전시

임원 초청 행사

현업 경험담 > AWS 서버이전 > AWS Summit Seoul2.2

입사 전 (16.5.17) 참관했던

코엑스에서 열린 AWS 컨퍼런스

AWS 임직원과 전문가들의 강연

파트너 솔루션 전시

임원 초청 행사

멍때리며 들은

멍때리며 본

멍때리며 박수친

현업 경험담 > AWS 서버이전 > 왜?2.2

국내 클라우드 서비스에서

아마존 웹 서비스로 이전왜?

2.2

SNS의 특성상

이미지가 많고, 파일이 계속 늘어남에 따라

고가용성의 이미지 서버가 필요

AWS 이전의 이유 첫번째

Image Server

IMAGE FILES

현업 경험담 > AWS 서버이전 > 왜?

2.2

AWS S3

무한대에 가까운 스토리지 제공

여러 물리적 저장소에 대한 중복 저장으로,

99.999999999% 내구성과 99.99%의 가용성 보장

AWS 이전의 이유 첫번째

S3

IMAGE FILES …


2.2

트래픽에 비해

지나친 스펙의 서버, 비용절감의 필요성

AWS 이전의 이유 두번째

트

래픽

낭비되는영역

Before


2.2

AWS 이전의 이유 두번째

간단한 절차만으로 서버를 늘렸다 줄이는

오토 스케일링이 가능

트

래픽

절약되는영역

Before

After

인스턴스

갯수


2.2

단일 서버 구성으로 인해 서버 장애발생 시

모든 서비스의 마비 가능성

AWS 이전의 이유 세번째

SERVER

APIDATABASE

IMAGESTORAGE

CLIENT


2.2

ELB (Elastic Load Balancing)

자동 부하분산 시스템으로,

주기적인 서버 상태를 체크하여 자동 트래픽 분산

AWS 이전의 이유 세번째

SERVER

APIDATABASE

IMAGESTORAGE

CLIENT

SERVER

APIDATABASE

IMAGESTORAGE


현업 경험담 > AWS 서버이전 > API EC2 이전2.2

AWS 에 첫 발을 딛은

기존 국내 클라우드 서버에 있던 API 들을

EC2 인스턴스로 이전하는 작업

API

EC2 Instance

API


AWS EC2 (Amazon Elastic Compute Cloud)

가상 컴퓨터 환경을 제공하는 인스턴스,

머신 이미지를 제공하는 AMI, 스토리지 볼륨인 EBS 등을 포함하는 서비스


API를 옮기고 테스트 중, 푸시 메시지가

클라이언트로 전송 되지 않는 현상을 발견

EC2 Instance

API???

PUSH


푸시 데이터를

쌓긴 하는데…

PUSH DATA


쌓아놓은 푸시를

클라이언트 기기로 보내주는 코드가 없음

?


??????

?


API

1. 푸시상황이 되면 푸시 데이터를 쌓는다.

2. ?

3. 성공 후 비운다.


API

1. 푸시상황이 되면 푸시 데이터를 쌓는다.

2. Shell Script 를 cron 으로 반복한다.

3. 성공 후 비운다.


리눅스 작업 스케줄러인 cron 으로

쉘스크립트를 1분 간격으로 계속 호출하고 있었던 것

* * * * * /path/push_fcm.sh


/** 푸시 전송 : /path/push_fcm.sh* crontab 1분에 1회 반복합니다.*/

API 코드 내 주석 혹은 문서만 있었다면

크게 줄어들었을 작업시간…


다음 개발자가 이런 일로 고생할 일이 없도록

코드로는 이해못할 부분에 대한 문서화와 주석

현업 경험담 > AWS 서버이전 > AWS 아키텍처2.2

EC2 로 서버도 만들어봤는데! 이왕 AWS 를 쓸거,

AWS 를 최대한 활용하여 백엔드를 구축해 보자!클라우드 데이터베이스 서비스인 RDS 활용과 AWS 아키텍처의 구성


그러나 너무 많은 서비스들아키텍처는 고사하고 뭔지도 모르겠는데요..


그때 기억난 멍때리며 들었던 윤석찬님의

“AWS 클라우드로 천만명 웹서비스 확장하기”세션


당시의 발표 자료와 영상을 찾아

프레젠테이션을 참고하며 따라해보기 시작

http://www.slideshare.net/awskorea/your-first-10-million-customer-web-service-on-aws-channy-yun


완성된 초기 쓰담 서비스의 AWS 아키텍처


컨퍼런스에서 들은 내용을 바탕으로

실제 서비스의 적용까지

현업 경험담 > AWS 서버이전 > 느낀 점2.2

문서화

개발자 컨퍼런스


문서화

실제로 고생을 해 보고 중요성을 실감

앞으로 짜게될 코드에 대한

똑똑한 주석과 문서화의 필요성


개발자 컨퍼런스

컨퍼런스를 통한

잠재 지식의 확대와 최신 트랜드 파악

나아가 프로젝트에의 적용

EC2 인스턴스 에서 Lambda 로

Backend API 전환

현업 경험담 > AWS Lambda > AWS Lambda 로의 이전결정2.3


Beta 에서 정식 버전으로 가면서

대대적인 기획안 변경


Beta 에서 정식 버전으로 가면서

대대적인 기획안 변경

에 따른 대대적인 백엔드 API 변경


백엔드, 갈아엎자!EC2 에서 Lambda 로

PHP 에서 node.js 로RDS 에서 dynamodb 로

현업 경험담 > AWS Lambda > AWS Lambda 란?2.3

AWS Lambda

2014년 발표된, 특정한 이벤트에 응답하여 실행되는,

자동으로 컴퓨팅 리소스를 관리하는 서버리스 컴퓨팅 시스템

API Gateway 를 통해 URI, method 와 연결하거나,

S3 / Dynamodb 등 AWS 리소스의 특정 트리거와 연결해 호출가능

Lambda node.js Hello World 예제

현업 경험담 > AWS Lambda > AWS Lambda 란?2.3

exports.handler = function(event, context) {context.succeed('Hello World');

}

현업 경험담 > AWS Lambda > Lambda 를 사용한 이유2.3

Lambda 사용의 이유 첫번째

초기 버전의 난항으로 인한

잦은 백엔드 변경사항 발생으로

스케일링 관리와 배포의 번거로움

2.3

Lambda 사용의 이유 첫번째 > 스케일링 관리와 배포의 번거로움

오토스케일링

필요한 소프트웨어가 이미 구성되어 있는 인스턴스 템플릿인

AMI (Amazon Machine Image) 로 Launch config 를 만들고,

오토 스케일링 그룹 설정

AMI

AutoScalingLaunch Config

AutoScalingGroup

V1 V1

현업 경험담 > AWS Lambda > Lambda 를 사용한 이유

2.3

서버를 배포할 때,

업데이트된 인스턴스로부터

AMI 를 업데이트하고, Launch Config를 재설정하는 과정 필요

배포의 자동화가 이루어지지 않은 상태의 번거로운 작업

AutoScalingLaunch Config

AutoScalingGroup

V2 V2 V2

Lambda 사용의 이유 첫번째 > 스케일링 관리와 배포의 번거로움


2.3

Lambda 사용의 이유 첫번째

서버의 운영과 관리

(스케일링, 모니터링, 보안, 코드배포..) 는

AWS 에서 수행해 주므로

별도의 번거로운 서버작업이 필요없어짐


2.3

Lambda 사용의 이유 두번째

사수님 曰,

“재밌겠다. 해보자, 스타트업이잖아."


2.3

Lambda 사용의 이유 세번째

node.js 로 작성하고 API-Gateway로 묶은

이벤트 기반의 Lambda Function들은

Roopback, restify 등 REST API 프레임워크로

쉬운 이전이 가능


2.3

Lambda 사용의 이유 세번째

Lambda 의 한정된

Timeout 과 Memory에 한계가 보인다면.

언제든지 REST 기반 프레임워크로 이전

> 부담없는 시작


현업 경험담 > AWS Lambda > PHP to node.js2.3

Lambda function 언어 결정

부담없는 시작

npm 의 모든 패키지가 사용가능

Lambda 관련 라이브러리가 가장 활성화


PHP 에서 node.js로 모든 API 의 변경


node.js 로 API를 변경하며 겪었던 난항

진행할수록 가독성 떨어지는 코드

1. 이미지 버퍼를 받는다.

2. 원본을 저장한다.

3. 이미지를 리사이징한다.

4. 리사이징된 이미지를 저장한다.

받은 이미지를 리사이징 후 저장


<?php..// 원본을 저장한다.saveOriginalImage($image);

// 이미지를 리사이징해 용량을 줄인다.$resizedImage = resizeImage($image);

// 리사이징한 이미지를 저장한다.saveResizedImage($resizedImage);..

?>


이벤트 기반 / 비동기 / 콜백 ....

나도 대충 알아! 짤수 있다!



saveOriginalImage(image, function(err, savedImage) {if (err)

return '원본이미지 저장 에러';else {

}})


원본 이미지의 저장이 성공하면

콜백의 결과를 받아서 이미지를 압축하고...



resizeImage(savedImage, function(err, resizedImage) {if (err)

return '이미지 리사이징 에러';else {

saveResizedImage(resizedImage, result){if (err)

return ’리사이징 된 이미지 저장 에러';else {

return '성공';}

}}

})}

})









return '성공';}

}}

})}

})???


saveOriginalImage(image, function(err, result) {if (err)


resizeImage(result, function(err, resizedImage) {if (err)




somefunction1(result, function(err, result) {if (err)

return ’이런 에러';else {

somefunction2(result, function(err, result){if (err)

return ’저런 에러';else {

somefunction3(result, function(err, result){if (err)

return ’요런 에러';else {

???????


점점 읽기 힘들어지는 코드들

Callback Hell




https://cnodejs.org/topic/570fb6a40a1e9da252f1e310

http://thecodebarbarian.com/2015/03/20/callback-hell-is-a-myth




그렇게 우여곡절 끝에

로그인 API 완성

현업 경험담 > AWS Lambda > 코드리뷰와 리펙토링2.3

“코드리뷰 한번 해볼까요?”네?


“코드리뷰 한번 해볼까요?”내 코드를 보여주는 것에 두려움과 부끄러움


단일 Lambda 함수에 대한 코드리뷰 진행

node.js 에서 알아두면 좋을 패턴에 대한 소개

효율적인 코드를 위한 토론

좋은 라이브러리의 제안

잘못된 코드에 대한 지적


단일 Lambda 함수에 대한 코드리뷰 진행

Callback Hell을 해결할 수 있는 Promise 라는 패턴이 있어요.

Array.some 메서드를 쓰면 코드가 좀 더 간결해 지지 않을까요?

이미지를 다룰때 Imagemagick 도 좋지만, sharp 도 한번 찾아보세요!

여기서 === 연산자를 쓰지 않으면 문제 발생의 가능성이 있어요.


수 번의 리펙토링과 리뷰 반복

코드리뷰로 얻은 결과를 통해


코드리뷰로와 리펙토링으로 변경된

Promise 패턴과 Arrow function 의 사용







return '성공';}

}}

})}

})

코드의 규모가 커질수록 콜백의 중첩으로

순차적인 작업 진행 시 가독성이 매우 떨어지는 코드에서,


saveOriginalImage(image).then(function(savedImage){

return resizeImage(savedImage);}).then(function(resizedImage){

return saveResizedImage(resizedImage);}).then(function(result){

return '성공';})).catch(function(err){

return err;})

Promise 패턴의 적용으로

한결 간결해진 코드


ECMA 6 Arrow function 의 적용과

축약한 통용 단어의 사용으로

더욱 직관적이고 간결해진 코드

코드리뷰로와 리펙토링으로 변경된

Promise 패턴과 Arrow function 의 사용

saveOrigImg(img).then(savedImg => resizeImg(savedImg)).then(resizedImg => saveResizedImg(resizedImg)).then(result => '성공').catch(err => err);

현업 경험담 > AWS Lambda > 느낀점2.3

코드 리뷰와 리펙토링

남이보는 내 코드에 대한 두려움을 버리고

동료 프로그래머와의 페어 프로그래밍

혹은 코드리뷰로

결함의 감소와 품질 향상, 나아가 성장

현업 경험담 > REST API > REST API 란?2.4

로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개,

웹의 장점을 최대한 활용할 수 있는 아키텍처

URI 와 HTTP Method 를 이용해 API 를 만드는 것

RESTGET / POST / PUT / DELETE


첫 번째,

URI는 Resource(자원)를 표현한다.

두 번째,

Resource 에 대한 행위는

HTTP Method로 표현한다.

POST : Create

GET : Read

PUT : Update

DELETE : Delete

RESTful API


첫 번째,

URI는 Resource(자원)를 표현한다.

두 번째,

Resource 에 대한 행위는

HTTP Method로 표현한다.

설계 방법론에 대한

많은 책들이 존재하지만,

정해진 룰은 없음

하지만..

RESTful API

현업 경험담 > REST API > 기존 API의 수정 경험2.4

리뷰, 이야기, 이벤트만 존재하던 탭

페이스북 페이지의 반려동물 팁 컨텐츠의 증가에 따라,

앱 내에서도 컨텐츠를 볼 수 있도록

매거진 탭의 추가와

댓글에 댓글을 달아달라는 많은 사용자의 요구에 따른

댓글의 댓글 기능 기능 추가

기능 추가 요청


기존 API 의 URI 구성 _ Default Codeigniter기능 추가 요청

https://Base_url/review/writeCI_Controller 를 상속받는 클래스명에 대응


기존 API 의 URI 구성 _ Default Codeigniter기능 추가 요청

https://Base_url/review/write클래스 내의 메서드명에 대응


기존 API 의 URI 구성 _ 리뷰

https://Base_url/review/write

https://Base_url/review/update

https://Base_url/review/delete

https://Base_url/review/list

https://Base_url/review/detail



기존 API 의 URI 구성 _ 리뷰

https://Base_url/review/write

https://Base_url/review/update

https://Base_url/review/delete

https://Base_url/review/list

https://Base_url/review/detail

https://Base_url/review_comment/write

https://Base_url/review_comment/update

https://Base_url/review_comment/delete

https://Base_url/review_comment/list



https://Base_url/story/write

https://Base_url/story/update

https://Base_url/story/delete

https://Base_url/story/list

https://Base_url/story/detail

https://Base_url/story_comment/write

https://Base_url/story_comment/update

https://Base_url/story_comment/delete

https://Base_url/story_comment/list

기존 API 의 URI 구성 _ 스토리기능 추가 요청


매거진의 추가?기능 추가 요청

https://Base_url/magazine/write

https://Base_url/magazine/update

https://Base_url/magazine/delete

https://Base_url/magazine/list

https://Base_url/magazine/detail

https://Base_url/magazine_comment/write

https://Base_url/magazine_comment/update

https://Base_url/magazine_comment/delete

https://Base_url/magazine_comment/list

너무 많은 코드의 중복과

불필요한 작업의 증가


댓글의 댓글 기능?기능 추가 요청

많은 방법을 생각해 봤으나

구현 후 더이상의 유지보수 및

기능추가는 NAVER...

현업 경험담 > REST API > API 의 재설계2.4

HTTP 는 서버와 클라이언트의

정보를 주고받기 위해 약속된 통신 규약 (프로토콜)

기존 API 설계의 문제점 파악 첫번째

POST : Create

GET : Read

PUT : Update

DELETE : Delete


HTTP 프로토콜을 무시한 Method

리소스에 대한 행위를 표현하지 않고 무의미한 사용






POST

POST

POST

GET

GET

기존 API 설계의 문제점 파악 첫번째


HTTP 프로토콜을 준수하며

HTTP 메소드로 리소스에 대한 행위를 표현하도록






POST

POST

POST

GET

GET

스토리 작성

특정 스토리 업데이트

특정 스토리 삭제

스토리 리스트 불러오기

특정 스토리 불러오기

CREATE

UPDATE

DELETE

READ

READ

기존 API 설계의 문제점 파악 첫번째 _ 재설계


HTTP 프로토콜을 준수하며

HTTP 메소드로 리소스에 대한 행위를 표현하도록

https://Base_url/stories

https://Base_url/stories/{story_id}


https://Base_url/stories


POST

PUT

DELTE

GET

GET

스토리 작성

특정 스토리 업데이트

특정 스토리 삭제

스토리 리스트 불러오기

특정 스토리 불러오기

CREATE

UPDATE

DELETE

READ

READ

기존 API 설계의 문제점 파악 첫번째 _ 재설계


리소스간의 관계가 무의미한 설계로

URL과 Method로는 API 파악의 어려움

기존 API 설계의 문제점 파악 두번째

https://Base_url/story_comment/write댓글은 이야기의 하위 리소스이지만 분리되어 작성된 URL

어떤 스토리의 댓글을 쓰기 위한 API 인지 알기 위해서는,

서버에서 요구하는 parameter의 story_id 를 알아야 함

POST무의미


리소스간의 관계파악으로

URL 과 Method 로 어떤 API 인지 파악가능하도록

기존 API 설계의 문제점 파악 두번째 _ 재설계

https://Base_url/stories/{story_id}/comments/{comment_id}

{story_id} 스토리의 {comment_id} 댓글을 수정하는 API 이구나!

PUT

https://Base_url/stories/{story_id}/comments GET

{story_id} 스토리의 모든 댓글들을 가져오는 API 이구나!


기존 API 설계의 문제점 파악 세번째

storyreviewevent

story_commentreview_commentevent_comment

리소스간의 관계가 무의미한 설계로

지나친 코드의 중복으로 인한 유지보수의 어려움


기존 API 설계의 문제점 파악 세번째 _ 재설계

리소스간의 관계파악 후

소스코드의 설계로

유지보수가 쉽고,

확장성 있는 코드의 작성

story

comment

review event

sub_commet

현업 경험담 > REST API > 느낀 점2.4

설계와 분석

처음 피부에 와닿도록 느낀

시스템 분석에 따른

좋은 설계의 중요성

정리 > 요약 >3.1

문서화 개발자 컨퍼런스 코드 리뷰와 리펙토링 설계와 분석

정리 > 입사 전과 비교해본 나 >3.2


항상 듣던 너무 당연한,



항상 듣던 너무 당연한,

하지만 추상적이고 머리에 떠다니던 개념들



AWS 로 서버이전을 하면서,


문서화 개발자 컨퍼런스 설계와 분석

경험이 없었던 node.js 로 API를 옮기면서

코드 리뷰와 리펙토링


문서화 개발자 컨퍼런스

기존 서버의 유지보수와 새로운 API 설계를 맡으면서

코드 리뷰와 리펙토링 설계와 분석


현업을 겪으며 다시금 생각하게 된

‘당연한 이야기들’

정리 > 결론 >3.3

모자른 발표로나마 간접경험을 통해

함께 성장하는 개발자가 되었으면 좋겠습니다 :)

경청해주셔서 감사합니다 :D

텀 프로젝트에서 제품 프로젝트로 - 성준영님

Technology