O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

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

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

  • Seja o primeiro a comentar

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. 감사합니다.

×