Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
스타트업을 위한
라라벨 기술 스택
정광섭
발표자 소개
 치킨집 테크트리 안 타려고 노력중인 개발자
 “쉽게 배우는 라라벨5 프로그래밍”
 “리눅스를 활용한 회사 인프라 구축의 모든 것”
 https://lesstif.com
 https://github...
오늘 함께할 내용
 팀을 꾸리고 프로젝트를 진행할 때 흔히 접하는
실수(발표자가 많이 하는) 유형 및 회피술
 서비스 자체에 집중할 수 있도록 라라벨 기술
스택 구성 시 주의 사항 및 경험 공유.
스택 선정 기준
 익숙하고 (발표자가) 사용자가 많은 제품
 인프라(형상관리, 이슈관리등)에는 적절한
비용을 지불
 설치형보다는 관리가 용이한 SaaS 선호
스택 선정 기준
 러시아 페인트공 알고리즘, 마세라티 문제,
야크 털깍기 회피
 Laravel 에서 OOTB(Out Of The Box) 로 제공되는
기능 위주
러시아 페인트공 알고리즘
 페인트공이 첫날은 차선 페인트 작업을 300야드
칠함
러시아 페인트공 알고리즘
 둘째날은 150야드 칠함
러시아 페인트공 알고리즘
 셋째날은 30야드 칠함
 첫날은 어떻게 10배를 칠했는지 관리자가 묻자
러시아 페인트공 알고리즘
"저도 어쩔 수 없었습니다. 매일 페인트 통에서
점점 멀어지니까요."
- 조엘 스폴스키의 “조엘 온 소프트웨어” 중
러시아 페인트공 알고리즘
 잘 돌지만 일정 이상 규모가 되면 급격히 성능이
저하되고 문제를 일으키는 코드
 레거시, 기술 부채등의 원인이기도 함.
마세라티 문제(Maserati problem)
마세라티 문제(Maserati problem)
어떤 마세라티 모델과 색상을 구매할 지
고민하는 것.
마세라티 문제(Maserati problem)
나중에 마세라티 살 능력이 됐을 때 할 고민을
미리 하는 것.
돈 많은 금융과 증권계에서는 “boat naming”
이라고 함.
마세라티 문제(Maserati problem)
 당장 필요하지 않은 기술을 담보되지 않은
미래의 큰 성공에 대비하여 준비하는 것
 천만명을 처리할 서비스는 사용자가 10만은
됐을 때 고민
 엔지니어만 있는 스타트업...
야크 털깍기(Yak Shaving)
 어떤 목적을 달성하기 위해 전혀 상관없는
연속된 작업을 해야 하는 상황.
 그중 마지막 작업이 야크 털깍기
야크 털깍기(Yak Shaving)
 봄이 와서 세차를 하려는데 호스가 터졌음
 차로 홈 디포우에 가서 호스를 사려보니 다리를
지나야 하는데 통행 카드가 필요
 통행카드가 없어서 옆집 Bob 한테 빌리려는데
 아...
야크 털깍기(Yak Shaving)
 그런데 베개에 있는 야크털이 많이 빠져서 지금
베개를 갖다 줄 수 없음
 그래서 세차를 하기 위해 동물원에 가서 야크 털을
깍는중
- 세스 고딘의 “이제는 작은 것이 큰 것이다“...
기술 스택 구성시 야크 털깍기
 소스 코드를 가져와서 직접 컴파일
 컴파일러 최대 최적화 옵션 켜도 속도 향상
체감 안 됨.
 V8 Java script 엔진은 컴파일만 2시간
 패키지 업데이트와 보안 패치는 어...
기술 스택 구성시 야크 털깍기
 SaaS 대신 직접 내부에 설치 및 설정
 gitlab 사내에 설치하는 중이라 commit 을 못하고
있음.
 redmine 설치중이라 이슈 등록을 못하는중..
기술 스택 구성시 야크 털깍기
 필요한 모든 기능을 직접 구현…
 코드를 StackOverflow 에서 찾아서 Copy&Paste
하는것도 실력인 시대
 기능 구현전에 누가 구현한게 있는지 github나
packa...
야크 털깍기 대응법
 야크 털깍기로 배우는 것도 많지만 문제는
일정
 예정보다 많은 시간이 소요된다면 잠시 멈출
것
 원래 하려고 했던게 무엇인지 떠올려 보고
야크털깍기라 생각되면 했던 일을 과감히 중지
Laravel
 PHP 의 태생적 한계를 보완해 주는 Modern
Full Stack Framework(MVC, ORM, Template 등)
Laravel
 최신 PHP의 장점(Name Space, Trait,
Anonymous Function)을 적극 활용
 이로 인해 국내 IDC 등 PHP 버전이 낮은 경우
활용이 어려움(PHP 5.6 이상 필요)
Laravel
 Composer 를 적극 활용
 검증된 라이브러리나 컴포넌트(Sympony 의
컴포넌트 - HTTPKernel, Console)등 적극 차용
 많은 기능이 OOTB(Out of the Box) 로 ...
Laravel
이때문에 라라벨이 PHP 생태계의 가두리
양식장이 되고 있는 단점도 있음.
라라벨 활용처
 웹 서비스를 계획하고 있다면 좋은 선택
 사용이 쉽고 확장성이 좋아서 마세라티
문제를 피하며 서비스 개발 가능
 Ex: 사용자가 많아졌을 때 file session => redis
로 변경시 약간의...
라라벨을 잘 쓰려면
 PHP 최신 기능 습득
 객체 지향 지식
 몇 가지 디자인 패턴 학습 필요
 DI(Dependency Injection)
 IoC(Inversion of Control)
 CoC(Conv...
라라벨이 적당하지 않은 경우
머신러닝, 빅데이타, Computer vision 등은
사용하려는 라이브러리나 platform 이 잘
지원하는 언어(python, C++, Java) 채택
개발 인프라
서비스 개발에 꼭 필요한 인프라
시스템에 대해 알아봅시다.
버전 관리
 subversion 쓰겠다고 하면 뜯어 말리세요.
 당연히 git 사용 권장
 버전관리는 직접 구축보다는 SaaS 방식
권장(구축과 백업에 쓸 노력은 개발에 투입)
버전 관리
 Bitbucket, gitlab, github 중 선택은?
 Github, Bitbucket 중 추천하며 웬만하면
github
 이슈 관리로 JIRA 를 사용할 예정이면 특히
gitlab 은 추천하지 ...
이슈 관리
 버전관리와 함께 가장 중요한 인프라
 Issue != Problem, Issue is (Problem, Todo, Task,
Improvement, etc…)
 등록된 모든 이슈를 꼭 처리할 필요는 없...
이슈 관리
 끝판왕 JIRA 추천(Agile 개발시에도 추천)
 설치형보다는 SaaS 방식의 Cloud 서비스 권장
 10명 이내면 Starter license (연 10$)로 저렴하게
사용 가능
Documentation/Collaboration
 Markdown 은 비개발자는 어려워 함
 MediaWiki 는 훌륭하지만 편의성 부재
 Confluence 추천(관련 slideshare 보기)
기술 스택
라라벨 기반으로 서비스를 만들기 위한
추천 기술 스택에 대해 알아봅시다.
On Premise vs Cloud
 AWS 등 클라우드가 결코 싸지 않음(Instance
외에 Hidden Fee 가 많음)
 급속도로 확장될 여지가 있는 서비스를
탄력적으로 운영할 때 Cloud 가 장점이 많음
...
Linux 배포판
 Ubuntu 권장
 RHEL 계열은 패키지 정책이 너무 보수적
 docker에 익숙하다면 RHEL 계열도 좋음(반드시
7 버전 사용)
 AWS 사용시 Amazon Linux 도 좋은 선택 - ...
Linux 배포판
 금융권과 연계하는 서버로 보안성 심의
받아야 할 때 RHEL이나 CentOS 추천
 RHEL 사용자들이 가장 싫어하는 기능인
SELinux 는 심의때 매우 유용
로컬 개발 환경 구성
 자 이제 Apache/PHP/MySQL 을 설치해서
개발환경을 구성해 봅시다.
 APM은 EasyPHP, AutoSet, Apm_Setup, WAMP,
XAMPP, MAMP 등 너무 다양
로컬 개발 환경 구성
 운영환경은 nginx 를 사용 예정인데 deploy때
문제되지 않을지?
 key/value store 로 redis 쓸 예정인데 개발자 PC
는 윈도우
 PHP 의 mbstring, open...
로컬 개발 환경 구성
 고민하지 말고 Homestead
 VirtualBox + Vagrant 로 빠르게 Ubuntu 기반
라라벨 개발 환경 구축 가능
 라라벨 공식 서브 프로젝트
 개발팀이 모두 OS X 를 쓴...
프로젝트 생성
 composer create project 명령으로 새로
생성하는것 보다는 boilerplate 프로젝트 사용
 팀 전용 Boilerplate 프로젝트 작성 & 갱신
 팀원간 의존성 일치를 위해 c...
라라벨 의존성 관리
 라라벨은 유의적 버전(Semantic Versioning)
따르지 않음
 LTS(Long Term Support) version 이 LTS 가 아님
 vendor 밑에 들어가는 Illumina...
라라벨 의존성 관리
 update 시 Illuminate 만 업데이트 됨
 운 나쁘면 patch update 인데
기존 코드가 안 돌 수도 있음.
라라벨 의존성 관리
 의존성을 수정하는 composer update/require
명령은 주의해서 수행
 변경된 composer.lock 은 참여자간 의존성
일치를 위해 즉시 push
 production은 com...
composer.lock 미공유시 버전 문제
,
라라벨 의존성 관리
 중요한 모듈은 의존성 선언시 patch 버전까지
지정
,
보안
 개발자들은 바빠서 보안은 아예 고려 대상이
아니거나 우선순위가 9,999 위
 정보통신망법, 개인정보보호법등의 강화로
유출 사고시 사업 자체가 위험해질 수 있으므로
최소한의 보안 지식 필요
보안 - Application
 SQL Injection, XSS, CSRF 에
대한 이해는 필수
 라라벨은 보안을 고려해서
설계했지만 개발자가 잘
이해하고 사용해야 함
보안 - Infra
 Deny All, Permit Some 정책
 서비스에 불필요한 서버 정보 은닉
 Server 종류와 버전 정보 및 OS 정보
 X-Powered-By 정보 제거
보안 - Infra
 더 자세한 보안 강화 방안은 “견고한 웹 서비스를
위한 실용적인 보안 가이드” 참고
 https://github.com/lesstif/web-service-hardening
DBMS
 PostgreSQL 개발자를 만나 본적이 많지 않음
 지리 정보 처리등 PostgreSQL 을 꼭 써야 할
분야가 아니라면 MySQL 권장
DBMS
 서비스 성능 저하 원인
 Full scan 또는 최적화되지 않은
Query
 대규모 Insert/Update에 따른 IO
성능 저하
규모가 커지면 read only
slave 운영
DBMS
 NoSQL 의 JSON type 이 좋아 보이는데
익숙하지 않다면 MySQL 5.7 사용
 예전 버전 MySQL 은 DBMS 답지 않게
Constraint Check 를 안 하므로 주의 필요
 non s...
DBMS - 백업
 DB 백업은 매우 중요하므로 SaaS 로 제공되는
서비스 사용 권장(Aurora DB등)
 직접 IaaS 나 On-Premise 기반으로 DBMS 를
구성한다면 백업 정책 수립 필수
(Increm...
DB migration
 개발/테스트/Staging/Production 간 일관된
DB Schema 유지 필요
DB migration
 라라벨은 rails 처럼 migration 기능 제공
 손쉽게 스키마를 작성하고 버전 관리 가능
DB migration 적용
 php artisan migrate 한방으로 스키마 적용
 실수로 production 에서 migration refresh 나
reset 명령시 사업 접어야 할 수 있음.
DB migration 적용
.env 에 “APP_ENV=production” 으로 설정되어
있으면 reset 시 prompt 띄우므로 반드시 설정
DB migration 적용
 그래도 대형 사고의 위험은 존재
 개발자 PC 에서 운영 DB 직접 접근 제한
 db migration 시 공동 작업
DB ERD
 Migration 을 사용해 개발하다 보면 전체
스키마 구조와 테이블간 관계가 한 눈에 안
들어옴
 테이블 정규화등 체계적인 데이터 관리와
튜닝을 위해서는 스키마 가시성 확보가 필요
DB ERD
 migration 전에 ERD 를 그려 보는 것을 권장
 ERD tool 은 Schema Reverse engineering 을
지원하므로 현재 스키마 분석에도 용이
DB ERD
ORM
 Eloquent 이라는 가벼운 ORM 내장
 웹 개발시 CRUD 반복을 줄여주는 쓸만한
프레임워크
 ORM 을 잘 쓰려면 DBMS에 대해 깊은 지식 필요
ORM
 N+1 문제 등 ORM 특성으로 인한 성능 저하
대응 능력 필요(Lazy eager loading 등)
 모든 쿼리를 ORM 으로 작성할 필요는 없음
 복잡하거나 성능에 민감한 쿼리는 Query
Build...
Cache/Session & Key value Store
 Redis 추천
 .env 에 CACHE_DRIVER, SESSION_DRIVER
설정 변경으로 기존 코드 동작
File Storage
 flysystem 라이브러리를 사용하여 File System
추상화
 로컬 파일 시스템에서 AWS S3 로 전환시
코드 변경이 많이 필요하지 않음
 규모가 커질 경우 AWS S3 로 이전하...
Full Text Indexing
 Laravel 5.3 부터 Scout Indexing driver 제공
 기본 Algolia, Elastic Search 지원
 아직 기능은 미비하여 많은 customizing ...
Email
 Email 은 유용한 알림 수단
 laravel은 swiftmailer library 기반으로
추상화된 Email 드라이버 제공
 Sendmail 보다는 mailgun 이나 AWS SES 같은
SaaS...
Job Scheduling
 cron 은 $PATH, $LD_LIBRARY_PATH 등 유닉스
환경 변수에 대한 이해 필요
 cron 작업 변경 이력이 관리되지 않음
 서버가 여러 대일 경우 crontab 변경시 ...
Job Scheduling
 Laravel 은 cron 기반의 task scheduler 내장
 cron 은 laravel scheduler 구동 용도로 사용
 스케줄링이 PHP 코드이므로 이력 관리 및
다수 서버...
Logging
 Logging != App Performance Monitoring(APM)
 Logging 은 App 의 Error Tracking
 NewRelic = APM
 ELK stack 은 로깅 취합...
Logging
 ssh + tail –f laravel.log 로 log 파일 보는 것은
불편하고 원하는 로그를 찾기 어려움
 특정 예외(http 500등)가 발생하면 이벤트를
받고 싶음
예전 로그 내용이 필요한데...
Logging Service
 Sentry, Rollbar, bugsnag 등 다양한 logging service
 SaaS 방식의 Sentry 추천
 설치형도 권장(https://www.lesstif.com/x/...
Sentry - Dashboard
Sentry – Log info
Deploy
 PHP 이므로 별도의 컴파일 및 패키징없이
운영에 반영 가능
 db migration 등의 부가 작업이 없는
배포라면 git pull 로 배포 가능
Deploy
 2016년이니 더 그럴싸한 배포 전략을
사용해 봅시다.
Deploy - envoy
 Laravel 내장 가벼운 ssh task runner
 blade 문법과 유사
 git pull 같은 반복 작업을 여러 대에서
수행하기 적합
Deploy – envoy + CI
 운영 서버에 배포는 개발자 PC 보다는 별도
서버가 적합
 배포 서버에 ssh login 후 envoy 실행 귀찮음
 누가 언제 배포를 했고 결과는 어땠는지
관리하고 싶음
Deploy – envoy + CI
 CI 를 도입해서 envoy 로 배포 실행
 이왕이면 envoy 배포 전에 phpunit 으로
단위테스트도 구동
Deploy – envoy + CI(bamboo)
Deploy – envoy + CI(bamboo)
감사합니다.
Upcoming SlideShare
Loading in …5
×

40

Share

Download to read offline

Laravel로 스타트업 기술 스택 구성하기

Download to read offline

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Laravel로 스타트업 기술 스택 구성하기

  1. 1. 스타트업을 위한 라라벨 기술 스택 정광섭
  2. 2. 발표자 소개  치킨집 테크트리 안 타려고 노력중인 개발자  “쉽게 배우는 라라벨5 프로그래밍”  “리눅스를 활용한 회사 인프라 구축의 모든 것”  https://lesstif.com  https://github.com/lesstif
  3. 3. 오늘 함께할 내용  팀을 꾸리고 프로젝트를 진행할 때 흔히 접하는 실수(발표자가 많이 하는) 유형 및 회피술  서비스 자체에 집중할 수 있도록 라라벨 기술 스택 구성 시 주의 사항 및 경험 공유.
  4. 4. 스택 선정 기준  익숙하고 (발표자가) 사용자가 많은 제품  인프라(형상관리, 이슈관리등)에는 적절한 비용을 지불  설치형보다는 관리가 용이한 SaaS 선호
  5. 5. 스택 선정 기준  러시아 페인트공 알고리즘, 마세라티 문제, 야크 털깍기 회피  Laravel 에서 OOTB(Out Of The Box) 로 제공되는 기능 위주
  6. 6. 러시아 페인트공 알고리즘  페인트공이 첫날은 차선 페인트 작업을 300야드 칠함
  7. 7. 러시아 페인트공 알고리즘  둘째날은 150야드 칠함
  8. 8. 러시아 페인트공 알고리즘  셋째날은 30야드 칠함  첫날은 어떻게 10배를 칠했는지 관리자가 묻자
  9. 9. 러시아 페인트공 알고리즘 "저도 어쩔 수 없었습니다. 매일 페인트 통에서 점점 멀어지니까요." - 조엘 스폴스키의 “조엘 온 소프트웨어” 중
  10. 10. 러시아 페인트공 알고리즘  잘 돌지만 일정 이상 규모가 되면 급격히 성능이 저하되고 문제를 일으키는 코드  레거시, 기술 부채등의 원인이기도 함.
  11. 11. 마세라티 문제(Maserati problem)
  12. 12. 마세라티 문제(Maserati problem) 어떤 마세라티 모델과 색상을 구매할 지 고민하는 것.
  13. 13. 마세라티 문제(Maserati problem) 나중에 마세라티 살 능력이 됐을 때 할 고민을 미리 하는 것. 돈 많은 금융과 증권계에서는 “boat naming” 이라고 함.
  14. 14. 마세라티 문제(Maserati problem)  당장 필요하지 않은 기술을 담보되지 않은 미래의 큰 성공에 대비하여 준비하는 것  천만명을 처리할 서비스는 사용자가 10만은 됐을 때 고민  엔지니어만 있는 스타트업에서 자주 발생하는 현상
  15. 15. 야크 털깍기(Yak Shaving)  어떤 목적을 달성하기 위해 전혀 상관없는 연속된 작업을 해야 하는 상황.  그중 마지막 작업이 야크 털깍기
  16. 16. 야크 털깍기(Yak Shaving)  봄이 와서 세차를 하려는데 호스가 터졌음  차로 홈 디포우에 가서 호스를 사려보니 다리를 지나야 하는데 통행 카드가 필요  통행카드가 없어서 옆집 Bob 한테 빌리려는데  아들이 캠핑가려고 Bob 한테 베개를 빌린 후에 안 갖다 줌
  17. 17. 야크 털깍기(Yak Shaving)  그런데 베개에 있는 야크털이 많이 빠져서 지금 베개를 갖다 줄 수 없음  그래서 세차를 하기 위해 동물원에 가서 야크 털을 깍는중 - 세스 고딘의 “이제는 작은 것이 큰 것이다“ 중
  18. 18. 기술 스택 구성시 야크 털깍기  소스 코드를 가져와서 직접 컴파일  컴파일러 최대 최적화 옵션 켜도 속도 향상 체감 안 됨.  V8 Java script 엔진은 컴파일만 2시간  패키지 업데이트와 보안 패치는 어쩔….
  19. 19. 기술 스택 구성시 야크 털깍기  SaaS 대신 직접 내부에 설치 및 설정  gitlab 사내에 설치하는 중이라 commit 을 못하고 있음.  redmine 설치중이라 이슈 등록을 못하는중..
  20. 20. 기술 스택 구성시 야크 털깍기  필요한 모든 기능을 직접 구현…  코드를 StackOverflow 에서 찾아서 Copy&Paste 하는것도 실력인 시대  기능 구현전에 누가 구현한게 있는지 github나 packagist 에서 검색  시간을 줄이려면 정리된 list 참고(awesome-xxx)  awesome-php, awesome-laravel 등
  21. 21. 야크 털깍기 대응법  야크 털깍기로 배우는 것도 많지만 문제는 일정  예정보다 많은 시간이 소요된다면 잠시 멈출 것  원래 하려고 했던게 무엇인지 떠올려 보고 야크털깍기라 생각되면 했던 일을 과감히 중지
  22. 22. Laravel  PHP 의 태생적 한계를 보완해 주는 Modern Full Stack Framework(MVC, ORM, Template 등)
  23. 23. Laravel  최신 PHP의 장점(Name Space, Trait, Anonymous Function)을 적극 활용  이로 인해 국내 IDC 등 PHP 버전이 낮은 경우 활용이 어려움(PHP 5.6 이상 필요)
  24. 24. Laravel  Composer 를 적극 활용  검증된 라이브러리나 컴포넌트(Sympony 의 컴포넌트 - HTTPKernel, Console)등 적극 차용  많은 기능이 OOTB(Out of the Box) 로 제공
  25. 25. Laravel 이때문에 라라벨이 PHP 생태계의 가두리 양식장이 되고 있는 단점도 있음.
  26. 26. 라라벨 활용처  웹 서비스를 계획하고 있다면 좋은 선택  사용이 쉽고 확장성이 좋아서 마세라티 문제를 피하며 서비스 개발 가능  Ex: 사용자가 많아졌을 때 file session => redis 로 변경시 약간의 코드 수정만으로 가능 (물론 세션 데이터는 수동으로 옮겨야….)
  27. 27. 라라벨을 잘 쓰려면  PHP 최신 기능 습득  객체 지향 지식  몇 가지 디자인 패턴 학습 필요  DI(Dependency Injection)  IoC(Inversion of Control)  CoC(Convention over Configuration)  Repository, Façade
  28. 28. 라라벨이 적당하지 않은 경우 머신러닝, 빅데이타, Computer vision 등은 사용하려는 라이브러리나 platform 이 잘 지원하는 언어(python, C++, Java) 채택
  29. 29. 개발 인프라 서비스 개발에 꼭 필요한 인프라 시스템에 대해 알아봅시다.
  30. 30. 버전 관리  subversion 쓰겠다고 하면 뜯어 말리세요.  당연히 git 사용 권장  버전관리는 직접 구축보다는 SaaS 방식 권장(구축과 백업에 쓸 노력은 개발에 투입)
  31. 31. 버전 관리  Bitbucket, gitlab, github 중 선택은?  Github, Bitbucket 중 추천하며 웬만하면 github  이슈 관리로 JIRA 를 사용할 예정이면 특히 gitlab 은 추천하지 않음(연계가 귀찮아요…)
  32. 32. 이슈 관리  버전관리와 함께 가장 중요한 인프라  Issue != Problem, Issue is (Problem, Todo, Task, Improvement, etc…)  등록된 모든 이슈를 꼭 처리할 필요는 없음  페인트공, 야크털깍기, 마세라티 방지  모든 업무를 이슈관리 시스템에 등록  진행상황을 수시로 업데이트 및 리뷰  처리가 끝난 일이라도 주변 상황(사용자수 증가)에 따라 해당 이슈 갱신
  33. 33. 이슈 관리  끝판왕 JIRA 추천(Agile 개발시에도 추천)  설치형보다는 SaaS 방식의 Cloud 서비스 권장  10명 이내면 Starter license (연 10$)로 저렴하게 사용 가능
  34. 34. Documentation/Collaboration  Markdown 은 비개발자는 어려워 함  MediaWiki 는 훌륭하지만 편의성 부재  Confluence 추천(관련 slideshare 보기)
  35. 35. 기술 스택 라라벨 기반으로 서비스를 만들기 위한 추천 기술 스택에 대해 알아봅시다.
  36. 36. On Premise vs Cloud  AWS 등 클라우드가 결코 싸지 않음(Instance 외에 Hidden Fee 가 많음)  급속도로 확장될 여지가 있는 서비스를 탄력적으로 운영할 때 Cloud 가 장점이 많음  고객이 급속히 늘지 않는 서비스라면 x86 서버 사서 IDC 에 넣는게 더 저렴하고 성능도 좋을 수 있음
  37. 37. Linux 배포판  Ubuntu 권장  RHEL 계열은 패키지 정책이 너무 보수적  docker에 익숙하다면 RHEL 계열도 좋음(반드시 7 버전 사용)  AWS 사용시 Amazon Linux 도 좋은 선택 - RHEL 계열이지만 패키지 업데이트가 빠른 편
  38. 38. Linux 배포판  금융권과 연계하는 서버로 보안성 심의 받아야 할 때 RHEL이나 CentOS 추천  RHEL 사용자들이 가장 싫어하는 기능인 SELinux 는 심의때 매우 유용
  39. 39. 로컬 개발 환경 구성  자 이제 Apache/PHP/MySQL 을 설치해서 개발환경을 구성해 봅시다.  APM은 EasyPHP, AutoSet, Apm_Setup, WAMP, XAMPP, MAMP 등 너무 다양
  40. 40. 로컬 개발 환경 구성  운영환경은 nginx 를 사용 예정인데 deploy때 문제되지 않을지?  key/value store 로 redis 쓸 예정인데 개발자 PC 는 윈도우  PHP 의 mbstring, openssl extension 설치하고 모듈 활성화 방법은?
  41. 41. 로컬 개발 환경 구성  고민하지 말고 Homestead  VirtualBox + Vagrant 로 빠르게 Ubuntu 기반 라라벨 개발 환경 구축 가능  라라벨 공식 서브 프로젝트  개발팀이 모두 OS X 를 쓴다면 Valet 도 좋은 선택
  42. 42. 프로젝트 생성  composer create project 명령으로 새로 생성하는것 보다는 boilerplate 프로젝트 사용  팀 전용 Boilerplate 프로젝트 작성 & 갱신  팀원간 의존성 일치를 위해 composer.lock 은 꼭 버전관리에 추가
  43. 43. 라라벨 의존성 관리  라라벨은 유의적 버전(Semantic Versioning) 따르지 않음  LTS(Long Term Support) version 이 LTS 가 아님  vendor 밑에 들어가는 Illuminate 패키지와 app Root 가 라라벨 프레임워크
  44. 44. 라라벨 의존성 관리  update 시 Illuminate 만 업데이트 됨  운 나쁘면 patch update 인데 기존 코드가 안 돌 수도 있음.
  45. 45. 라라벨 의존성 관리  의존성을 수정하는 composer update/require 명령은 주의해서 수행  변경된 composer.lock 은 참여자간 의존성 일치를 위해 즉시 push  production은 composer install 만 실행 ,
  46. 46. composer.lock 미공유시 버전 문제 ,
  47. 47. 라라벨 의존성 관리  중요한 모듈은 의존성 선언시 patch 버전까지 지정 ,
  48. 48. 보안  개발자들은 바빠서 보안은 아예 고려 대상이 아니거나 우선순위가 9,999 위  정보통신망법, 개인정보보호법등의 강화로 유출 사고시 사업 자체가 위험해질 수 있으므로 최소한의 보안 지식 필요
  49. 49. 보안 - Application  SQL Injection, XSS, CSRF 에 대한 이해는 필수  라라벨은 보안을 고려해서 설계했지만 개발자가 잘 이해하고 사용해야 함
  50. 50. 보안 - Infra  Deny All, Permit Some 정책  서비스에 불필요한 서버 정보 은닉  Server 종류와 버전 정보 및 OS 정보  X-Powered-By 정보 제거
  51. 51. 보안 - Infra  더 자세한 보안 강화 방안은 “견고한 웹 서비스를 위한 실용적인 보안 가이드” 참고  https://github.com/lesstif/web-service-hardening
  52. 52. DBMS  PostgreSQL 개발자를 만나 본적이 많지 않음  지리 정보 처리등 PostgreSQL 을 꼭 써야 할 분야가 아니라면 MySQL 권장
  53. 53. DBMS  서비스 성능 저하 원인  Full scan 또는 최적화되지 않은 Query  대규모 Insert/Update에 따른 IO 성능 저하 규모가 커지면 read only slave 운영
  54. 54. DBMS  NoSQL 의 JSON type 이 좋아 보이는데 익숙하지 않다면 MySQL 5.7 사용  예전 버전 MySQL 은 DBMS 답지 않게 Constraint Check 를 안 하므로 주의 필요  non strict mode 일 때 data constraint 미체크  unsinged int 에 minus 값 입력시 0 이 저장  varchar 컬럼에 긴 데이터 입력시 초과 부분 잘라 버리기
  55. 55. DBMS - 백업  DB 백업은 매우 중요하므로 SaaS 로 제공되는 서비스 사용 권장(Aurora DB등)  직접 IaaS 나 On-Premise 기반으로 DBMS 를 구성한다면 백업 정책 수립 필수 (Incremental/Full backup 주기등)  백업 자동화 및 정기적인 복구 훈련  MySQL은 Percona XtraBackup 추천
  56. 56. DB migration  개발/테스트/Staging/Production 간 일관된 DB Schema 유지 필요
  57. 57. DB migration  라라벨은 rails 처럼 migration 기능 제공  손쉽게 스키마를 작성하고 버전 관리 가능
  58. 58. DB migration 적용  php artisan migrate 한방으로 스키마 적용  실수로 production 에서 migration refresh 나 reset 명령시 사업 접어야 할 수 있음.
  59. 59. DB migration 적용 .env 에 “APP_ENV=production” 으로 설정되어 있으면 reset 시 prompt 띄우므로 반드시 설정
  60. 60. DB migration 적용  그래도 대형 사고의 위험은 존재  개발자 PC 에서 운영 DB 직접 접근 제한  db migration 시 공동 작업
  61. 61. DB ERD  Migration 을 사용해 개발하다 보면 전체 스키마 구조와 테이블간 관계가 한 눈에 안 들어옴  테이블 정규화등 체계적인 데이터 관리와 튜닝을 위해서는 스키마 가시성 확보가 필요
  62. 62. DB ERD  migration 전에 ERD 를 그려 보는 것을 권장  ERD tool 은 Schema Reverse engineering 을 지원하므로 현재 스키마 분석에도 용이
  63. 63. DB ERD
  64. 64. ORM  Eloquent 이라는 가벼운 ORM 내장  웹 개발시 CRUD 반복을 줄여주는 쓸만한 프레임워크  ORM 을 잘 쓰려면 DBMS에 대해 깊은 지식 필요
  65. 65. ORM  N+1 문제 등 ORM 특성으로 인한 성능 저하 대응 능력 필요(Lazy eager loading 등)  모든 쿼리를 ORM 으로 작성할 필요는 없음  복잡하거나 성능에 민감한 쿼리는 Query Builder 사용해서 수작업
  66. 66. Cache/Session & Key value Store  Redis 추천  .env 에 CACHE_DRIVER, SESSION_DRIVER 설정 변경으로 기존 코드 동작
  67. 67. File Storage  flysystem 라이브러리를 사용하여 File System 추상화  로컬 파일 시스템에서 AWS S3 로 전환시 코드 변경이 많이 필요하지 않음  규모가 커질 경우 AWS S3 로 이전하거나 또는 개발은 로컬 파일로 하고 운영은 S3 사용
  68. 68. Full Text Indexing  Laravel 5.3 부터 Scout Indexing driver 제공  기본 Algolia, Elastic Search 지원  아직 기능은 미비하여 많은 customizing 필요  Sass 기반 Algolia 는 설정없이 CJK 도 잘 지원하나 비용 발생
  69. 69. Email  Email 은 유용한 알림 수단  laravel은 swiftmailer library 기반으로 추상화된 Email 드라이버 제공  Sendmail 보다는 mailgun 이나 AWS SES 같은 SaaS 기반 서비스 추천
  70. 70. Job Scheduling  cron 은 $PATH, $LD_LIBRARY_PATH 등 유닉스 환경 변수에 대한 이해 필요  cron 작업 변경 이력이 관리되지 않음  서버가 여러 대일 경우 crontab 변경시 반복 작업 수행 필요
  71. 71. Job Scheduling  Laravel 은 cron 기반의 task scheduler 내장  cron 은 laravel scheduler 구동 용도로 사용  스케줄링이 PHP 코드이므로 이력 관리 및 다수 서버에 배포 용이 * * * * * php /path/to/app/artisan schedule:run 1>> /dev/null 2>&1
  72. 72. Logging  Logging != App Performance Monitoring(APM)  Logging 은 App 의 Error Tracking  NewRelic = APM  ELK stack 은 로깅 취합용으로는 너무 과다
  73. 73. Logging  ssh + tail –f laravel.log 로 log 파일 보는 것은 불편하고 원하는 로그를 찾기 어려움  특정 예외(http 500등)가 발생하면 이벤트를 받고 싶음 예전 로그 내용이 필요한데 이미 rolling 되어 버림
  74. 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. 75. Sentry - Dashboard
  76. 76. Sentry – Log info
  77. 77. Deploy  PHP 이므로 별도의 컴파일 및 패키징없이 운영에 반영 가능  db migration 등의 부가 작업이 없는 배포라면 git pull 로 배포 가능
  78. 78. Deploy  2016년이니 더 그럴싸한 배포 전략을 사용해 봅시다.
  79. 79. Deploy - envoy  Laravel 내장 가벼운 ssh task runner  blade 문법과 유사  git pull 같은 반복 작업을 여러 대에서 수행하기 적합
  80. 80. Deploy – envoy + CI  운영 서버에 배포는 개발자 PC 보다는 별도 서버가 적합  배포 서버에 ssh login 후 envoy 실행 귀찮음  누가 언제 배포를 했고 결과는 어땠는지 관리하고 싶음
  81. 81. Deploy – envoy + CI  CI 를 도입해서 envoy 로 배포 실행  이왕이면 envoy 배포 전에 phpunit 으로 단위테스트도 구동
  82. 82. Deploy – envoy + CI(bamboo)
  83. 83. Deploy – envoy + CI(bamboo)
  84. 84. 감사합니다.
  • HaeJeongYu

    Jun. 19, 2020
  • ChoiBino

    Mar. 8, 2020
  • ssuser205fd2

    Nov. 25, 2019
  • kinjonggun

    Sep. 16, 2019
  • freezner3

    Jul. 1, 2019
  • landzz

    May. 11, 2019
  • SamYeolKim

    Jun. 15, 2018
  • ChunjaSong

    Jun. 12, 2018
  • chirho78

    Apr. 18, 2018
  • cyberhoon

    Mar. 14, 2018
  • seongminbag

    Feb. 14, 2018
  • ssuser0651d8

    Dec. 15, 2017
  • ssuser604e70

    Dec. 9, 2017
  • MGtheGuy

    Aug. 19, 2017
  • claude_yun

    Jun. 27, 2017
  • blankbob

    Jun. 26, 2017
  • 831jsh

    Jun. 18, 2017
  • SeongukJo

    Jun. 13, 2017
  • ssuser67ee35

    May. 29, 2017
  • DongkunLee1

    Mar. 29, 2017

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

Views

Total views

7,053

On Slideshare

0

From embeds

0

Number of embeds

2

Actions

Downloads

62

Shares

0

Comments

0

Likes

40

×