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

텀 프로젝트에서
제품 프로젝트로
6개월간의 현업 경험담
경희대학교 성준영

발표자 소개
성준영
경희대학교 컴퓨터 공학과 3학년
T.G.WinG
Nomadstar 서버개발 인턴
wnsdud1861@gmail.com

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
API
DATA
BASE
IMAGE
STORAGE
CLIENT

2.2
ELB (Elastic Load Balancing)
자동 부하분산 시스템으로,
주기적인 서버 상태를 체크하여 자동 트래픽 분산
AWS 이전의 이유 세번째
SERVER
API
DATA
BASE
IMAGE
STORAGE
CLIENT
SERVER
API
DATA
BASE
IMAGE
STORAGE

현업 경험담 > 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
AutoScaling
Launch Config
AutoScaling
Group
V1 V1
현업 경험담 > AWS Lambda > Lambda 를 사용한 이유

2.3
서버를 배포할 때,
업데이트된 인스턴스로부터
AMI 를 업데이트하고, Launch Config를 재설정하는 과정 필요
배포의 자동화가 이루어지지 않은 상태의 번거로운 작업
AutoScaling
Launch Config
AutoScaling
Group
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 {
}
})
원본 이미지의 저장이 성공하면
콜백의 결과를 받아서 이미지를 압축하고...

if (err)
else {
resizeImage(savedImage, function(err, resizedImage) {
if (err)
return '이미지 리사이징 에러';
else {
saveResizedImage(resizedImage, result){
if (err)
return ’리사이징 된 이미지 저장 에러';
else {
return '성공';
}
}
}
})
}
})

if (err)
else {
if (err)
else {
if (err)
else {
return '성공';
}
}
}
})
}
})
???

saveOriginalImage(image, function(err, result) {
if (err)
else {
resizeImage(result, function(err, resizedImage) {
if (err)
else {
if (err)
else {
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 의 사용
if (err)
else {
if (err)
else {
if (err)
else {
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/write
CI_Controller 를 상속받는 클래스명에 대응

기존 API 의 URI 구성 _ Default Codeigniter
클래스 내의 메서드명에 대응

기존 API 의 URI 구성 _ 리뷰
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/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 설계의 문제점 파악 세번째
story
review
event
story_comment
review_comment
event_comment
리소스간의 관계가 무의미한 설계로
지나친 코드의 중복으로 인한 유지보수의 어려움

기존 API 설계의 문제점 파악 세번째 _ 재설계
리소스간의 관계파악 후
소스코드의 설계로
유지보수가 쉽고,
확장성 있는 코드의 작성
story
comment
review event
sub_commet

현업 경험담 > REST API > 느낀 점2.4
설계와 분석
처음 피부에 와닿도록 느낀
시스템 분석에 따른
좋은 설계의 중요성

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

정리 > 입사 전과 비교해본 나 >3.2
항상 듣던 너무 당연한,

항상 듣던 너무 당연한,
하지만 추상적이고 머리에 떠다니던 개념들

AWS 로 서버이전을 하면서,

문서화 개발자 컨퍼런스 설계와 분석
경험이 없었던 node.js 로 API를 옮기면서
코드 리뷰와 리펙토링

문서화 개발자 컨퍼런스
기존 서버의 유지보수와 새로운 API 설계를 맡으면서
코드 리뷰와 리펙토링 설계와 분석

현업을 겪으며 다시금 생각하게 된
‘당연한 이야기들’

정리 > 결론 >3.3
모자른 발표로나마 간접경험을 통해
함께 성장하는 개발자가 되었으면 좋겠습니다 :)

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

Similar to 텀 프로젝트에서 제품 프로젝트로 - 성준영님 (20)

More from NAVER D2

More from NAVER D2 (20)

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