라라벨로 스타트업(startup)에 필요한 업무 환경 및 기술 스택 구성하기.

1. 스타트업을 위한
라라벨 기술 스택
정광섭

2. 발표자 소개
 치킨집 테크트리 안 타려고 노력중인 개발자
 “쉽게 배우는 라라벨5 프로그래밍”
 “리눅스를 활용한 회사 인프라 구축의 모든 것”
 https://lesstif.com
 https://github.com/lesstif

3. 오늘 함께할 내용
 팀을 꾸리고 프로젝트를 진행할 때 흔히 접하는
실수(발표자가 많이 하는) 유형 및 회피술
 서비스 자체에 집중할 수 있도록 라라벨 기술
스택 구성 시 주의 사항 및 경험 공유.

4. 스택 선정 기준
 익숙하고 (발표자가) 사용자가 많은 제품
 인프라(형상관리, 이슈관리등)에는 적절한
비용을 지불
 설치형보다는 관리가 용이한 SaaS 선호

5. 스택 선정 기준
 러시아 페인트공 알고리즘, 마세라티 문제,
야크 털깍기 회피
 Laravel 에서 OOTB(Out Of The Box) 로 제공되는
기능 위주

6. 러시아 페인트공 알고리즘
 페인트공이 첫날은 차선 페인트 작업을 300야드
칠함

7. 러시아 페인트공 알고리즘
 둘째날은 150야드 칠함

8. 러시아 페인트공 알고리즘
 셋째날은 30야드 칠함
 첫날은 어떻게 10배를 칠했는지 관리자가 묻자

9. 러시아 페인트공 알고리즘
"저도 어쩔 수 없었습니다. 매일 페인트 통에서
점점 멀어지니까요."
- 조엘 스폴스키의 “조엘 온 소프트웨어” 중

10. 러시아 페인트공 알고리즘
 잘 돌지만 일정 이상 규모가 되면 급격히 성능이
저하되고 문제를 일으키는 코드
 레거시, 기술 부채등의 원인이기도 함.

11. 마세라티 문제(Maserati problem)

12. 마세라티 문제(Maserati problem)
어떤 마세라티 모델과 색상을 구매할 지
고민하는 것.

13. 마세라티 문제(Maserati problem)
나중에 마세라티 살 능력이 됐을 때 할 고민을
미리 하는 것.
돈 많은 금융과 증권계에서는 “boat naming”
이라고 함.

14. 마세라티 문제(Maserati problem)
 당장 필요하지 않은 기술을 담보되지 않은
미래의 큰 성공에 대비하여 준비하는 것
 천만명을 처리할 서비스는 사용자가 10만은
됐을 때 고민
 엔지니어만 있는 스타트업에서 자주
발생하는 현상

15. 야크 털깍기(Yak Shaving)
 어떤 목적을 달성하기 위해 전혀 상관없는
연속된 작업을 해야 하는 상황.
 그중 마지막 작업이 야크 털깍기

16. 야크 털깍기(Yak Shaving)
 봄이 와서 세차를 하려는데 호스가 터졌음
 차로 홈 디포우에 가서 호스를 사려보니 다리를
지나야 하는데 통행 카드가 필요
 통행카드가 없어서 옆집 Bob 한테 빌리려는데
 아들이 캠핑가려고 Bob 한테 베개를 빌린 후에 안
갖다 줌

17. 야크 털깍기(Yak Shaving)
 그런데 베개에 있는 야크털이 많이 빠져서 지금
베개를 갖다 줄 수 없음
 그래서 세차를 하기 위해 동물원에 가서 야크 털을
깍는중
- 세스 고딘의 “이제는 작은 것이 큰 것이다“ 중

18. 기술 스택 구성시 야크 털깍기
 소스 코드를 가져와서 직접 컴파일
 컴파일러 최대 최적화 옵션 켜도 속도 향상
체감 안 됨.
 V8 Java script 엔진은 컴파일만 2시간
 패키지 업데이트와 보안 패치는 어쩔….

19. 기술 스택 구성시 야크 털깍기
 SaaS 대신 직접 내부에 설치 및 설정
 gitlab 사내에 설치하는 중이라 commit 을 못하고
있음.
 redmine 설치중이라 이슈 등록을 못하는중..

20. 기술 스택 구성시 야크 털깍기
 필요한 모든 기능을 직접 구현…
 코드를 StackOverflow 에서 찾아서 Copy&Paste
하는것도 실력인 시대
 기능 구현전에 누가 구현한게 있는지 github나
packagist 에서 검색
 시간을 줄이려면 정리된 list 참고(awesome-xxx)
 awesome-php, awesome-laravel 등

21. 야크 털깍기 대응법
 야크 털깍기로 배우는 것도 많지만 문제는
일정
 예정보다 많은 시간이 소요된다면 잠시 멈출
것
 원래 하려고 했던게 무엇인지 떠올려 보고
야크털깍기라 생각되면 했던 일을 과감히 중지

22. Laravel
 PHP 의 태생적 한계를 보완해 주는 Modern
Full Stack Framework(MVC, ORM, Template 등)

23. Laravel
 최신 PHP의 장점(Name Space, Trait,
Anonymous Function)을 적극 활용
 이로 인해 국내 IDC 등 PHP 버전이 낮은 경우
활용이 어려움(PHP 5.6 이상 필요)

24. Laravel
 Composer 를 적극 활용
 검증된 라이브러리나 컴포넌트(Sympony 의
컴포넌트 - HTTPKernel, Console)등 적극 차용
 많은 기능이 OOTB(Out of the Box) 로 제공

25. Laravel
이때문에 라라벨이 PHP 생태계의 가두리
양식장이 되고 있는 단점도 있음.

26. 라라벨 활용처
 웹 서비스를 계획하고 있다면 좋은 선택
 사용이 쉽고 확장성이 좋아서 마세라티
문제를 피하며 서비스 개발 가능
 Ex: 사용자가 많아졌을 때 file session => redis
로 변경시 약간의 코드 수정만으로 가능
(물론 세션 데이터는 수동으로 옮겨야….)

27. 라라벨을 잘 쓰려면
 PHP 최신 기능 습득
 객체 지향 지식
 몇 가지 디자인 패턴 학습 필요
 DI(Dependency Injection)
 IoC(Inversion of Control)
 CoC(Convention over Configuration)
 Repository, Façade

28. 라라벨이 적당하지 않은 경우
머신러닝, 빅데이타, Computer vision 등은
사용하려는 라이브러리나 platform 이 잘
지원하는 언어(python, C++, Java) 채택

29. 개발 인프라
서비스 개발에 꼭 필요한 인프라
시스템에 대해 알아봅시다.

30. 버전 관리
 subversion 쓰겠다고 하면 뜯어 말리세요.
 당연히 git 사용 권장
 버전관리는 직접 구축보다는 SaaS 방식
권장(구축과 백업에 쓸 노력은 개발에 투입)

31. 버전 관리
 Bitbucket, gitlab, github 중 선택은?
 Github, Bitbucket 중 추천하며 웬만하면
github
 이슈 관리로 JIRA 를 사용할 예정이면 특히
gitlab 은 추천하지 않음(연계가 귀찮아요…)

32. 이슈 관리
 버전관리와 함께 가장 중요한 인프라
 Issue != Problem, Issue is (Problem, Todo, Task,
Improvement, etc…)
 등록된 모든 이슈를 꼭 처리할 필요는 없음
 페인트공, 야크털깍기, 마세라티 방지
 모든 업무를 이슈관리 시스템에 등록
 진행상황을 수시로 업데이트 및 리뷰
 처리가 끝난 일이라도 주변 상황(사용자수 증가)에 따라 해당
이슈 갱신

33. 이슈 관리
 끝판왕 JIRA 추천(Agile 개발시에도 추천)
 설치형보다는 SaaS 방식의 Cloud 서비스 권장
 10명 이내면 Starter license (연 10$)로 저렴하게
사용 가능

34. Documentation/Collaboration
 Markdown 은 비개발자는 어려워 함
 MediaWiki 는 훌륭하지만 편의성 부재
 Confluence 추천(관련 slideshare 보기)

35. 기술 스택
라라벨 기반으로 서비스를 만들기 위한
추천 기술 스택에 대해 알아봅시다.

36. On Premise vs Cloud
 AWS 등 클라우드가 결코 싸지 않음(Instance
외에 Hidden Fee 가 많음)
 급속도로 확장될 여지가 있는 서비스를
탄력적으로 운영할 때 Cloud 가 장점이 많음
 고객이 급속히 늘지 않는 서비스라면 x86 서버
사서 IDC 에 넣는게 더 저렴하고 성능도 좋을 수
있음

37. Linux 배포판
 Ubuntu 권장
 RHEL 계열은 패키지 정책이 너무 보수적
 docker에 익숙하다면 RHEL 계열도 좋음(반드시
7 버전 사용)
 AWS 사용시 Amazon Linux 도 좋은 선택 - RHEL
계열이지만 패키지 업데이트가 빠른 편

38. Linux 배포판
 금융권과 연계하는 서버로 보안성 심의
받아야 할 때 RHEL이나 CentOS 추천
 RHEL 사용자들이 가장 싫어하는 기능인
SELinux 는 심의때 매우 유용

39. 로컬 개발 환경 구성
 자 이제 Apache/PHP/MySQL 을 설치해서
개발환경을 구성해 봅시다.
 APM은 EasyPHP, AutoSet, Apm_Setup, WAMP,
XAMPP, MAMP 등 너무 다양

40. 로컬 개발 환경 구성
 운영환경은 nginx 를 사용 예정인데 deploy때
문제되지 않을지?
 key/value store 로 redis 쓸 예정인데 개발자 PC
는 윈도우
 PHP 의 mbstring, openssl extension 설치하고
모듈 활성화 방법은?

41. 로컬 개발 환경 구성
 고민하지 말고 Homestead
 VirtualBox + Vagrant 로 빠르게 Ubuntu 기반
라라벨 개발 환경 구축 가능
 라라벨 공식 서브 프로젝트
 개발팀이 모두 OS X 를 쓴다면 Valet 도 좋은
선택

42. 프로젝트 생성
 composer create project 명령으로 새로
생성하는것 보다는 boilerplate 프로젝트 사용
 팀 전용 Boilerplate 프로젝트 작성 & 갱신
 팀원간 의존성 일치를 위해 composer.lock 은 꼭
버전관리에 추가

43. 라라벨 의존성 관리
 라라벨은 유의적 버전(Semantic Versioning)
따르지 않음
 LTS(Long Term Support) version 이 LTS 가 아님
 vendor 밑에 들어가는 Illuminate 패키지와 app
Root 가 라라벨 프레임워크

44. 라라벨 의존성 관리
 update 시 Illuminate 만 업데이트 됨
 운 나쁘면 patch update 인데
기존 코드가 안 돌 수도 있음.

45. 라라벨 의존성 관리
 의존성을 수정하는 composer update/require
명령은 주의해서 수행
 변경된 composer.lock 은 참여자간 의존성
일치를 위해 즉시 push
 production은 composer install 만 실행
,

46. composer.lock 미공유시 버전 문제
,

47. 라라벨 의존성 관리
 중요한 모듈은 의존성 선언시 patch 버전까지
지정
,

48. 보안
 개발자들은 바빠서 보안은 아예 고려 대상이
아니거나 우선순위가 9,999 위
 정보통신망법, 개인정보보호법등의 강화로
유출 사고시 사업 자체가 위험해질 수 있으므로
최소한의 보안 지식 필요

49. 보안 - Application
 SQL Injection, XSS, CSRF 에
대한 이해는 필수
 라라벨은 보안을 고려해서
설계했지만 개발자가 잘
이해하고 사용해야 함

50. 보안 - Infra
 Deny All, Permit Some 정책
 서비스에 불필요한 서버 정보 은닉
 Server 종류와 버전 정보 및 OS 정보
 X-Powered-By 정보 제거

51. 보안 - Infra
 더 자세한 보안 강화 방안은 “견고한 웹 서비스를
위한 실용적인 보안 가이드” 참고
 https://github.com/lesstif/web-service-hardening

52. DBMS
 PostgreSQL 개발자를 만나 본적이 많지 않음
 지리 정보 처리등 PostgreSQL 을 꼭 써야 할
분야가 아니라면 MySQL 권장

53. DBMS
 서비스 성능 저하 원인
 Full scan 또는 최적화되지 않은
Query
 대규모 Insert/Update에 따른 IO
성능 저하
규모가 커지면 read only
slave 운영

54. DBMS
 NoSQL 의 JSON type 이 좋아 보이는데
익숙하지 않다면 MySQL 5.7 사용
 예전 버전 MySQL 은 DBMS 답지 않게
Constraint Check 를 안 하므로 주의 필요
 non strict mode 일 때 data constraint 미체크
 unsinged int 에 minus 값 입력시 0 이 저장
 varchar 컬럼에 긴 데이터 입력시 초과 부분 잘라
버리기

55. DBMS - 백업
 DB 백업은 매우 중요하므로 SaaS 로 제공되는
서비스 사용 권장(Aurora DB등)
 직접 IaaS 나 On-Premise 기반으로 DBMS 를
구성한다면 백업 정책 수립 필수
(Incremental/Full backup 주기등)
 백업 자동화 및 정기적인 복구 훈련
 MySQL은 Percona XtraBackup 추천

56. DB migration
 개발/테스트/Staging/Production 간 일관된
DB Schema 유지 필요

57. DB migration
 라라벨은 rails 처럼 migration 기능 제공
 손쉽게 스키마를 작성하고 버전 관리 가능

58. DB migration 적용
 php artisan migrate 한방으로 스키마 적용
 실수로 production 에서 migration refresh 나
reset 명령시 사업 접어야 할 수 있음.

59. DB migration 적용
.env 에 “APP_ENV=production” 으로 설정되어
있으면 reset 시 prompt 띄우므로 반드시 설정

60. DB migration 적용
 그래도 대형 사고의 위험은 존재
 개발자 PC 에서 운영 DB 직접 접근 제한
 db migration 시 공동 작업

61. DB ERD
 Migration 을 사용해 개발하다 보면 전체
스키마 구조와 테이블간 관계가 한 눈에 안
들어옴
 테이블 정규화등 체계적인 데이터 관리와
튜닝을 위해서는 스키마 가시성 확보가 필요

62. DB ERD
 migration 전에 ERD 를 그려 보는 것을 권장
 ERD tool 은 Schema Reverse engineering 을
지원하므로 현재 스키마 분석에도 용이

63. DB ERD

64. ORM
 Eloquent 이라는 가벼운 ORM 내장
 웹 개발시 CRUD 반복을 줄여주는 쓸만한
프레임워크
 ORM 을 잘 쓰려면 DBMS에 대해 깊은 지식 필요

65. ORM
 N+1 문제 등 ORM 특성으로 인한 성능 저하
대응 능력 필요(Lazy eager loading 등)
 모든 쿼리를 ORM 으로 작성할 필요는 없음
 복잡하거나 성능에 민감한 쿼리는 Query
Builder 사용해서 수작업

66. Cache/Session & Key value Store
 Redis 추천
 .env 에 CACHE_DRIVER, SESSION_DRIVER
설정 변경으로 기존 코드 동작

67. File Storage
 flysystem 라이브러리를 사용하여 File System
추상화
 로컬 파일 시스템에서 AWS S3 로 전환시
코드 변경이 많이 필요하지 않음
 규모가 커질 경우 AWS S3 로 이전하거나
또는 개발은 로컬 파일로 하고 운영은 S3 사용

68. Full Text Indexing
 Laravel 5.3 부터 Scout Indexing driver 제공
 기본 Algolia, Elastic Search 지원
 아직 기능은 미비하여 많은 customizing 필요
 Sass 기반 Algolia 는 설정없이 CJK 도 잘
지원하나 비용 발생

69. Email
 Email 은 유용한 알림 수단
 laravel은 swiftmailer library 기반으로
추상화된 Email 드라이버 제공
 Sendmail 보다는 mailgun 이나 AWS SES 같은
SaaS 기반 서비스 추천

70. Job Scheduling
 cron 은 $PATH, $LD_LIBRARY_PATH 등 유닉스
환경 변수에 대한 이해 필요
 cron 작업 변경 이력이 관리되지 않음
 서버가 여러 대일 경우 crontab 변경시 반복
작업 수행 필요

71. Job Scheduling
 Laravel 은 cron 기반의 task scheduler 내장
 cron 은 laravel scheduler 구동 용도로 사용
 스케줄링이 PHP 코드이므로 이력 관리 및
다수 서버에 배포 용이
* * * * * php /path/to/app/artisan schedule:run 1>>
/dev/null 2>&1

72. Logging
 Logging != App Performance Monitoring(APM)
 Logging 은 App 의 Error Tracking
 NewRelic = APM
 ELK stack 은 로깅 취합용으로는 너무 과다

73. Logging
 ssh + tail –f laravel.log 로 log 파일 보는 것은
불편하고 원하는 로그를 찾기 어려움
 특정 예외(http 500등)가 발생하면 이벤트를
받고 싶음
예전 로그 내용이 필요한데 이미 rolling 되어
버림

74. Logging Service
 Sentry, Rollbar, bugsnag 등 다양한 logging service
 SaaS 방식의 Sentry 추천
 설치형도 권장(https://www.lesstif.com/x/t4XUAQ)
 Sentry와 Laravel 연동은
https://www.lesstif.com/x/7YXUAQ 참고

75. Sentry - Dashboard

76. Sentry – Log info

77. Deploy
 PHP 이므로 별도의 컴파일 및 패키징없이
운영에 반영 가능
 db migration 등의 부가 작업이 없는
배포라면 git pull 로 배포 가능

78. Deploy
 2016년이니 더 그럴싸한 배포 전략을
사용해 봅시다.

79. Deploy - envoy
 Laravel 내장 가벼운 ssh task runner
 blade 문법과 유사
 git pull 같은 반복 작업을 여러 대에서
수행하기 적합

80. Deploy – envoy + CI
 운영 서버에 배포는 개발자 PC 보다는 별도
서버가 적합
 배포 서버에 ssh login 후 envoy 실행 귀찮음
 누가 언제 배포를 했고 결과는 어땠는지
관리하고 싶음

81. Deploy – envoy + CI
 CI 를 도입해서 envoy 로 배포 실행
 이왕이면 envoy 배포 전에 phpunit 으로
단위테스트도 구동

82. Deploy – envoy + CI(bamboo)

83. Deploy – envoy + CI(bamboo)

84. 감사합니다.