Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후기 - Full ver.
Similar to 혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후기 - Full ver. (20)
혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후기 - Full ver.
- 1. 혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후기 박태성(@geoseong) at IDEASAM
- 2. 공유하려고 하는 이유 발표자의 발전, 이 발표자료 를 보시는 분들의 발전을 위 해. 영감을 받으시거나 혹은 반 면교사로 삼으셨으면
- 3. 박태성 @IDEASAM R&D Specialist (개발잡부🤫) 발표자 소개 geoseong geoseong 구로디지털 #gudi Organizer 프론트엔드 #frontend Organizer Community Hero
- 4. MATCHMON - 주짓수 대회운영 플랫폼
- 5. 아키텍쳐 - 코드관리
- 6. [serverless.yml] [AWS 콘솔에 배포된 Lambda Layer의 모습] 아키텍쳐 - Lambda Layer /.next /node_modules
- 8. Lambda Layers serverless framework serverless cli framework $ STAGE=(dev|prod) next build frontend 아키텍쳐 - 프론트엔드 amplify cli $ amplify push $ sls deploy amplify framework cli
- 9. AWS Amplify https://www.slideshare.net/awskr/aws-community-day-2020-amplify 디스코드 커뮤니티(영문) https://discord.gg/amplify
- 10. 프론트엔드 프로젝트 구성
- 11. 프론트엔드 프로젝트 구성 matchmon.com/[pages] process.env.{...} import { createContext } from 'react' import { ThemeProvider } from 'styled-components'
- 12. MatchView.getInitialProps = async props => { // 백엔드 서버 요청 후 응답 받기 let responseObj = await fetch(endpoint, param) let { status, data } = responseObj return { status, data, … } } 프론트엔드 Server Side Rendering (Next.js) matchmon.com/match/gigipaivacup const MatchView = props => { return <div> <Head><title>{title}</title><meta property=”og:title” content={title} /></Head> <><Component /></> </div> } export default Index import Head from 'next/head'
- 13. 구현 - 프론트엔드 서버 (serverless framework)
- 14. 구현 - 프론트엔드 서버 (serverless framework)
- 15. 구현 - 프론트엔드 서버 (serverless framework)
- 16. 구현 - 프론트엔드 서버 (serverless framework)
- 17. 구현 - 프론트엔드 서버 (serverless framework) Lambda Layers ( /opt | /로컬람다레이어경로 )
- 18. 구현 - 프론트엔드 서버 (serverless framework)
- 19. Lambda Layer path 구현 - 프론트엔드 서버 (serverless framework)
- 20. prefetch img, … 구현 - 프론트엔드 서버 (serverless framework)
- 22. 백엔드 디버깅 VSCode 세팅
- 23. 백엔드 디버깅 VSCode 세팅
- 24. DB Instance
- 25. SQL Injection?
- 26. 아키텍쳐 - 백엔드 (VPC) serverless-vpc-plugin Private Subnet Public Subnet Security Group generate
- 27. 아키텍쳐 - 백엔드 (EventBridge) [출처: https://medium.com/hackernoon/im-afraid-you-re-thinking- about-aws-lambda-cold-starts-all-wrong-7d907f278a4f] Amazon EventBridge Event Rule
- 28. 관리자 회원 관리 (Amplify Framework) Amplify CLI로 Cognito UserPool을 만들고 Amplify sdk로 유저관리
- 29. $ amplify add auth Using service: Cognito, provided by: awscloudformation The current configured provider is Amazon Cognito. Do you want to use the default authentication and security configuration? Manual configuration Select the authentication/authorization services that you want to use: User Sign-Up & Sign-In only (Best used with a cloud API only) Please provide a friendly name for your resource that will be used to label this category in the project: kendrabuttonauth Please provide a name for your user pool: kendrabuttonauth Warning: you will not be able to edit these selections. How do you want users to be able to sign in? Username Do you want to add User Pool Groups? No 관리자 회원 관리 (Amplify CLI) [Log] https://github.com/awskrug/kendra-button/wiki https://github.com/awskrug/kendra-button/wiki /[Auth] Making Cognito Userpool for kendra button Do you want to add an admin queries API? No Multifactor authentication (MFA) user login options: OFF Email based user registration/forgot password: Enabled (Requires per- user email entry at registration) Please specify an email verification subject: Your verification code Please specify an email verification message: Your verification code is {####} Do you want to override the default password policy for this User Pool? No Warning: you will not be able to edit these selections. What attributes are required for signing up? Email Specify the app's refresh token expiration period (in days): 30 Do you want to specify the user attributes this app can read and write? No Do you want to enable any of the following capabilities? Do you want to use an OAuth flow? No
- 30. 관리자 회원 관리 (Amplify SDK)
- 31. 이미지 업로드 [프론트엔드] 백엔드에서 얻은 토큰으로 public 이미지 업로드
- 32. 이미지 업로드 [백엔드] S3 업로드 권한 얻기(cognito도 세팅 해봄) [호출->]
- 33. aws-sdk-js 활용 대회 주최 안내 및 공지메일 보내는 기능 SES로 구현 대회 주최 하루전에 메일 보내는 로직은 cron식 써서 CloudWatchEvents SDK를 이용해서 규칙 추가 참가자 이메일 알람
- 34. 참가자 이메일 알람 - 이메일 템플릿 생성
- 35. 참가자 이메일 알람 - 대회안내 이메일 전송
- 36. 대회 날짜 하루 전 이메일 보내는 람다함수를 명시적 호 출하는 이벤트 참가자 이메일 알람 - 대회 주최 하루 전 알람
- 37. SEO (Site Engine Optimization)
- 38. SEO (Site Engine Optimization)
- 39. SEO (Site Engine Optimization)
- 43. 회고 규모가 작더라도 개발기획은 꼭 세우자 목표를 잘개 쪼개놓고 하나씩 클리어 해 감으로써 성취감을 느껴 사기를 높이자 혼자 다 해내려고 하지 말고 다른 사람에게 도움을 요청해라 중간 결산을 위해 상대를 찾아 코드리뷰를 하자 커뮤니티 활동 덕분에 문제해결 많이했다 (아는척 할수 있게 되었다)
Editor's Notes
- 제가 지금 다니는 회사에서 2018년 말부터 2020년도 초까지 혼자서 부딪히면서 개발하며 얻게된 경험들을 공유하고자 발표준비를 겨우겨우 해서 이렇게 발표를 하게 되었습니다. 지금도 많이 늦긴 했는데, 하루라도 더 늦기전에 얼른 발표해야 옛날 기술들이라는 소리를 듣지 않게될거같아서, 무엇보다 더이상 안 쓰이는 고대 아키텍쳐를 이야기하게 될까봐 걱정되긴 하는데, 만약 실제 그렇다면 지적해 주시면 바로 소통해서 들으시는 여러분께 최신정보를 드릴 수 있게 하겠습니다.
- (AWS커뮤니티 나의 역할 소개) (슬랙아이디 소개하면서 DM, 발표문의 달라고 이야기하기) (회사 앱 연혁 소개. 우리는 어학앱회사 -> 게임회사 -> 웹플랫폼 회사..는 안되어서 아쉽) 빅데이터 국비교육 -> 스프링 웹개발 -> c# mssql aspx -> jquery-mobile -> cordova -> ionic -> react-native -> react -> unity jquery-mobile부터는 지금 다니는 아이디어샘에서 다 거쳤던 기술들
- MATCHMON - 주짓수 대회운영 플랫폼 (프로젝트 구현기간): 1년 6개월 (2018 ~ 2020) (프로젝트 참가 인원): 대표, 나, 베타테스트 이후 디자이너 (프로젝트 베타테스트 여정) (개발 난이도: 비즈니스 로직이 제일..)(간단한 소감) (언젠간 후기를 누군가에게 공유하겠다 마음먹은 지 1년 넘어서야 드디어..)
- (백엔드 아키텍쳐도 관심 있는지 참가자들 거수로 확인. 절반 넘으면 얘기하고 아니면 스킵하기) (밑밥 깔기. serverless framework 요즘 안 본다. 잘 모를 수 있다. 틀리면 얘기해 달라) Bitbucket에 코드를 푸쉬하고 있었고, 프론트/백엔드 리포지토리 따로 둠 Bitbucket Pipeline 이용해서 커밋할 때마다 배포되도록 ci cd 환경을 구축함 (bitbucket-pipelines.yml) 깃 푸쉬를 하면 bitbucket pipeline 내부 컨테이너에서 serverless framework를 설치시키고, 백엔드와 프론트엔드에 각자 맞는 테스트 툴을 돌리게 시킨 다음 serverless framework 배포 커맨드로 API Gateway & Lambda에 배포되도록 세팅했고 [프론트만 다른 점이 있다면] next.js framework 설치시킨 다음 next.js 번들 빌드를 시켜서 테스트 툴 돌리고 API Gateway & Lambda에 배포가 되도록 세팅한 점 프론트엔드/백엔드 공통으로 serverless framework 채택한 이유: 배포된 리소스 관리(배포/수정/삭제)하기 쉽게 해주는 프레임웍이 당시 serverless Framework이 핫했음 서버리스 아키텍쳐 구현 이유: EC2에 익숙치 않음. 서버리스가 더 쉽게 느껴짐. 종량제라는 것도 매력. 이 서비스는 대용량 트래픽이 있는 서비스가 아닐 거라고 예상하고, 저렴하게 구축하려 노력. SSR을 위해 프론트 서버를 구축함 Lambda Layer 실험적 도입: 프로젝트 하면서 aws에서 처음으로 선보여진 기능이었음. 다음 슬라이드에서 더 이야기할 거긴 한데 (Lambda Layer가 뭐냐 간단히 이야기하면 람다에서 공통으로 쓰이는 것을 패키징하여 보관을 시켜주는 놈. 어느 람다펑션에든 떼었다 붙일 수 있다) Lambda Layer 배포방법은 직저 package.json에서 npm 배포 스크립트 만들어서 수작업으로 배포시킴. 로컬에서 직접 npm커맨더 쳤음. [LambdaLayer프론트엔드] Lambda Layer 배포용 폴더: next.js 빌드된 것, npm node_modules폴더를 넣어둠 [LambdaLayer백엔드] Lambda Layer 배포용 폴더: npm node_modules폴더를 넣어둠 (나름 보안에 신경쓴다고) 환경설정 파일들은 s3에서 다운받아옴
- 각 Lambda에서 공통으로 사용되는 패키지들을 람다 Layer에 담아뒀음. serverless framework에서 Lambda Layer 관리가 가능함. 프론트엔드/백엔드, 스테이지별로 람다레이어 리소스를 관리했음 프론트(Layer-dev|prod-NextApp): 빌드된 next.js 프론트엔드 번들이 안에 있다. 그래서 프론트 SSR 서버에서 공통으로 참조할 수 있게 되었다. - url 라우팅마다 람다펑션이 있었는데, 이 여러 라우팅 펑션이 하나의 빌드된 next.js 번들을 바라보기 때문에 Lambda Layer에 담아 배포함 그리고 각 Lambda 함수마다 담고 있었어야 했던 /node_modules 폴더들을 Lambda Layer에 다 옮겨두고 각 펑션에서 가져다 쓸수 있게 해서 각 함수의 용량을 대폭 줄일 수 있었음. (200MB~ -> 10kb) 제일 좋았던 점은 급하게 코드를 수정해야 할 때 AWS 웹 콘솔에서 수정이 가능하게 되었다는 점. 왜냐하면 그 전에는 람다 함수가 몇메가(3메가?)만 넘어가도 AWS 웹 콘솔에서 코드 자체를 볼 수가 없었기 때문. (그당시 3메가 넘어가면 웹에서 코드수정 불가했음) Frontend, Backend에서 공통으로 사용되는 aws-sdk SDK같은 경우는 Backend 람다 레이어(Layer-dev-Packages)에 넣어서 백엔드와 프론트엔드 람다 펑션에서 가져다 쓸 수 있게 함.
- [사용했던 AWS 서비스 소개] 예전 아이콘도 다수 있을 수 있으니 참고.. CloudFront & Route53: 도메인 작업. Route53서 도메인 직접 구매함 API Gateway & Lambda(Layer) & S3 : API와 프론트 페이지 로딩에 사용됨. S3는 이미지 로드에 사용. severless framework를 통해 리소스 만듦. dev,prod 스테이징 나눠서 배포시킴 Cognito: 대회 주최자 admin 회원관리. Amplify Framework를 통해 리소스 만듦 SNS: 경기 임박 알림 메일 보낼 때 사용. CloudWatch(rate 예약): 람다펑션 워밍할때, 대회 알림메일 보낼때 쓰임. 콜드스타트때문에.. rate의 기능은 EventBridge로 바뀌었더라..
- - 회원인증은 Amplify Framework을 택했다. Amplify는 Cognito SDK를 랩핑해서 쉽게 사용할 수 있게 해 주도록 하는 게 장점이라 선택함. - 프론트엔드 프레임웍으로 next.js를 고름: SSR 을 쉽게 세팅해 줄 뿐만 아니라 페이지 별 라우팅 세팅도 쉬워서 선택.(js파일이 곧 url라우팅. 내장기능, 여러형태의 css을 내장으로 서폿. 본인은 css-in-js 애용). - SEO: 동적인 컨텐츠를 검색엔진에 걸리게 하기 위해서는 SSR구축이 필수였는데, 개발 당시인 2019년에는 서버가 꼭 있어야 구글봇이 크롤링을 잘 했던 경험이 있어서 프론트서버를 두기 위해 serverless framework를 활용했다. - Lambda@Edge 를 이용해서 동적인 SSR을 구현하는 것도 가능했으나, 그당시 나는 그 기술을 알게 되었을때 이미 serverless framework로 SSR 구현법 진도를 꽤 나갔던 이후라 더이상 알아보고 싶지 않았음. - 매치몬 프로젝트 도메인주소를 입력해서 들어가면 API Gateway가 맞이해 주고, API Gateway에 연결된 람다함수가 실행이 된다. 이 함수에서는 next.js의 SSR 관련 api를 이용해서 next.js 페이지를 뿌려주는 방식. - Lambda Layer내용 설명: (이전 슬라이드에서 충분히 설명 되었으면 스킵) 빌드된 next.js 프론트엔드 번들이 lambda layer 안에 있다. 그래서 프론트 SSR 서버에서 공통으로 참조할 수 있게 되었다. - 그니까 nextjs cli로 스에이지 별 커맨드 `STAGE=(dev|prod) next build frontend` 를 수행하면 `.next` 폴더 라는 이름으로 번들파일이 만들어지는데, 이 `.next`폴더를 lambda layer에 넣어서 배포한 것임.
- AWS Amplify는 모바일 및 웹 어플리케이션 개발을 위한 플랫폼이구요, Amplify CLI와 Amplify Framework으로 나뉩니다. Amplify CLI를 통해서 프로젝트를 만들고 AWS리소스들을 생성하고 배포 할 수 있습니다. 로컬에서 테스팅 할 수도 있습니다. 그리고 Amplify CLI와 Amplify Framework은 모두 GitHub에 올라가 있는 오픈소스 프로젝트 라서 직접 기여도 가능합니다. 참고로 저는 documentation쪽 리포지토리에다가 PR 한번 올려봤는데 반년 넘게 흐지부지 진행되다가 그냥 클로즈됐습니다 ㅎ 근데 이건 document 리포지토리니까 다른 코어 리포지토리는 좀 다르지 않을까.. 하는 생각이 있습니다.
- (타입스크립트 접하기 전에 프로젝트를 시작했음. 이후에 타입스크립트로 변환시키는 작업이 엄두가 안나 그냥 js로 사용.) prettier & eslint 사용 lambda layer 는 layers폴더 안에 있음 amplify & frontend & serverless 가 한 리포지토리에 공존
- (환경변수 주입) (styled-components Provider사용) (React ContextAPI 사용) 여러 Provider를 배열로 받아서 js의 reduce함수를 써서 리턴을 시키게 했는데요, 원래 여러 Provider가 겹겹이 감싸지는 코드였는데, 보기 안좋아서 이렇게 한번 처리해봄
- (서버사이드 렌더링 하는 코드) url과 pages폴더 내 js이름이 매칭되어 라우팅이 됨 공식 Next.js 에서 이야기하기를.. getInitialProps는 페이지에서 SSR을 활성화하고 초기 데이터를 가져올수 있도록 합니다. 이는 서버에서 이미 채워진 데이터가 있는 페이지를 보내는 것을 의미합니다. 이것은 특히 SEO에 유용합니다. getServerSideProps라는 함수도 있는데, 아마도 프론트 서버 구현을 안해도 데이터 패칭을 해서 미리 데이터를 보여주는 걸로 보이는데 실제 케이스를 눈으로 보지 못해서 확실히 이야기는 못하겠다. 혹시 아시는 분? 이 기능은 프로젝트 한창 진행 중 베타로 나왔음. 지금은 정식으로 포함되어 있더라.
- —------- serverless framework을 이용해서 프론트엔드 세팅을 어떻게 했는지 설명하겠음. 파일리스트: server_koa_xxxx는 에서 xxxx는 라우팅과 연관을 지어서 만들었음. 현재 매치몬 웹에 저 다섯가지 부류의 라우팅(admin, info, matches, root, static)이 존재해서, 각 라우팅마다 상황별 작업을 거친 뒤에 빌드된 nextjs 프론트엔드 컨텐츠를 서빙하기 위해서 저렇게 js파일들을 만들어놈. 보시는 이 코드는 root 주소 라우팅에 대한 설정을 보여주고 있음 —------- handler: 참조하는 스크립트 파일. 그리고 handler 점(.) 뒤에는 handler.js파일의 export된 함수의 이름 지목 environment: 환경변수 설정하는 부분. 다음 페이지에서 보겠지만 이 환경변수로 js파일 임포트하는 데에 쓰인다. package 안 include: 배포될 함수에 포함시킬 파일들의 경로 layers: (문법설명)스테이지 별로 람다 레이어를 임포트 할 수 있게끔 CloudFormation 문법을 사용하여 설정한 것임 그 외에 serverless framework에서 설정 가능한 옵션들이 많이 있고, 날이 갈수록 더 많아지고 있음.
- serverless framework을 이용해서 프론트엔드 구현한 방법 설명 파일리스트: server_koa_xxxx는 에서 xxxx는 라우팅과 연관을 지어서 만들었음. 현재 매치몬 웹에 저 다섯가지 부류의 라우팅(admin, info, match, static)이 존재해서, 각 라우팅마다 상황별 작업을 거친 뒤 빌드된 프론트엔드 컨텐츠를 서빙을하기 위해서 저렇게 js파일들을 만들어놈. 보시는 이 코드는 root 주소 라우팅에 대한 설정을 보여주고 있음 —------- handler: 참조하는 스크립트 파일. 그리고 handler 점(.) 뒤에 index는 handler.js파일의 export된 함수의 이름 지목 —------- environment: 환경변수 설정하는 부분. 다음 페이지에서 보겠지만 이 환경변수로 js파일 임포트하는 데에 쓰인다. package 안 include: 배포될 함수에 포함시킬 파일들의 경로 layers: (문법설명)스테이지 별로 람다 레이어를 임포트 할 수 있게끔 CloudFormation 문법을 사용하여 설정한 것임 그 외에 serverless framework에서 설정 가능한 옵션들이 많이 있고, 날이 갈수록 더 많아지고 있음.
- serverless framework을 이용해서 프론트엔드 구현한 방법 설명 파일리스트: server_koa_xxxx는 에서 xxxx는 라우팅과 연관을 지어서 만들었음. 현재 매치몬 웹에 저 다섯가지 부류의 라우팅(admin, info, match, static)이 존재해서, 각 라우팅마다 상황별 작업을 거친 뒤 빌드된 프론트엔드 컨텐츠를 서빙을하기 위해서 저렇게 js파일들을 만들어놈. 보시는 이 코드는 root 주소 라우팅에 대한 설정을 보여주고 있음 handler: 참조하는 스크립트 파일. 그리고 handler 점(.) 뒤에는 handler.js파일의 export된 함수의 이름 지목 —------- environment: 환경변수 설정하는 부분. 저는 이 환경변수를 js파일명으로 활용했다. 그래서 이 환경변수 값을 가져와 동적으로 임포트하는 데에 썼음. ex) process.env.TYPE package 안 include: 배포될 함수에 포함시킬 파일들의 경로 —------- layers: (문법설명)스테이지 별로 람다 레이어를 임포트 할 수 있게끔 CloudFormation 문법을 사용하여 설정한 것임 그 외에 serverless framework에서 설정 가능한 옵션들이 많이 있고, 날이 갈수록 더 많아지고 있음.
- serverless framework을 이용해서 프론트엔드 구현한 방법 설명 파일리스트: server_koa_xxxx는 에서 xxxx는 라우팅과 연관을 지어서 만들었음. 현재 매치몬 웹에 저 다섯가지 부류의 라우팅(admin, info, match, static)이 존재해서, 각 라우팅마다 상황별 작업을 거친 뒤 빌드된 프론트엔드 컨텐츠를 서빙을하기 위해서 저렇게 js파일들을 만들어놈. 보시는 이 코드는 root 주소 라우팅에 대한 설정을 보여주고 있음 handler: 참조하는 스크립트 파일. 그리고 handler 점(.) 뒤에는 handler.js파일의 export된 함수의 이름 지목 environment: 환경변수 설정하는 부분. 다음 페이지에서 보겠지만 이 환경변수로 js파일 임포트하는 데에 쓰인다. package 안 include: 배포될 함수에 포함시킬 파일들의 경로 —------- layers: (문법설명)스테이지(local,dev,prod) 별로 그에 맞는 람다 레이어를 임포트 할 수 있게끔 CloudFormation 문법을 사용하여 설정한 것임 ex) cf: 그 외에 설정 가능한 다양한 serverless옵션들이 많이 있고, 날이 갈수록 더 많아지고 있음. —-------
- [코드] —------- handler.js 파일 살펴보기. Overview: 이 파일은 각 url 라우팅에 공통으로 물려있는 파일이고, 아까 serverless.yml에서 정의한 환경변수를 이용해서 next.js 페이지를 뿌려주는 js 파일(server_koa_xxx.js)을 임포트해 와서 그 내용을 리턴해 주는 것임. getLayerPackages: (나의 창작물임. 공식 메소드 그런거 아님) 지금 람다펑션에 연결된 여러 람다 레이어 중에서 가져오고 싶은 내용을 가져올 수 있게 유틸성으로 모듈화 시킨 것임 람다 레이어 임포트 경로: 프로덕션모드에선 클라우드상에서 람다 레이어 컨텐츠를 불러와야 되니까 경로는 /opt, 로컬에서 테스트할때는 개발중인 PC 내에 람다레이어가 위치한 경로를 가져옴. —------- server: 아까 serverless.yml에서 세팅한 환경변수를 여기서 써먹는다. 왼쪽에 보이는 server_koa_xxx.js 파일을 지목해서 가져오는 데에 쓰인다. 이 server_koa_xxx.js의 내용은 next.js의 ssr패키지와 node.js의 koa framework을 사용해서 프론트엔드 컨텐츠를 리턴시킨다. koa framework 사용이유? express framework보다 훨 가벼워서 return await serverless(): serverless-http 패키지를 이용해서 프론트엔드 컨텐츠를 서빙하는 역할을 함.
- [코드] handler.js 파일 살펴보기. 이게 각 url 라우팅에 공통으로 물려있는 파일이고, next.js SSR 코드가 들어있는 파일들(server_koa_xxx.js)을 아까 serverless.yml에서 정의한 환경변수를 이용해서 임포트해 와서 내용을 리턴해 주는 것임. getLayerPackages: (나의 창작물임. 공식 메소드 그런거 아님) 람다 레이어 안에 require할 패키지들을 불러오도록 하는 유틸을 하나 만들어 놓은 함수. 배포된 여러 람다 레이어 중에서 가져오고 싶은 내용을 가져올 수 있게 유틸성 js파일을 만든 것임 메소드 안쪽: 프로덕션모드에선 클라우드상에서 람다 레이어 컨텐츠를 불러오는 경로인 /opt, 로컬에서 테스트할때는 프로젝트 내에 람다레이어가 위치한 경로를 가져옴. —------- server: 아까 serverless.yml에서 세팅한 환경변수를 여기서 써먹는다. 왼쪽 파일리스트에 보이는 server_koa_xxx.js 파일을 지목해서 가져오는 데에 쓰인다. 라우팅 주소가 무엇이냐에 따라 xxx의 이름이 달라지게 했다. 이 server_koa_xxx.js의 내용은 다음 슬라이드에서 따로 설명 하겠음. return await serverless(): 깃헙에서 구할 수 있는 모듈인데 serverless-http 모듈을 이용해서 프론트엔드 컨텐츠를 서빙하는 역할을 함. —-------
- [next.js SSR패키지 활용해서 프론트엔드 컨텐츠 리턴하는 영역] —------- 지금 보는건 server_koa_root.js 코드. 이 코드가 전부임 next.js 패키지와 koa framework를 사용했고, 람다 레이어에서 빌드된 nextjs 번들을 가져와서 서빙하는 내용임 사용된 모듈은 nextjs의 SSR에 대한 것과 express보다 가볍다고 알려져 있는 koajs 이다. nextappPath: Lambda Layer 내에 next.js 번들이 위치한 경로. 이전 슬라이드에서 설명했듯이 로컬 테스트 시에는 프로젝트 내 빌드된 프론트엔드 경로를 가르키고, 배포된 환경에선 /opt 경로를 입력해야 맞는 Lambda layer를 가져올 수 있다. 지금 루트 라우팅 스크립트 설명인데, ‘/’로 들어오는 routing들은 이 lambda 펑션에서 받아들여서 koa-router 모듈을 이용하여 분기를 한다 그러면 next.js 함수인 app.render()를 써서 Lambda Layer의 next.js 번들인 ‘.next’폴더 안에 있는 페이지 경로를 가져와서 서빙을 한다. —------- [static.js] 처리는 좀 다름. - 브라우저에 사이트가 처음 로드가 되고 난 이후에 nextjs 페이지가 불러오는 경로는 프로젝트의 /static, /.next/static 을 가져오게 된다. -> server_koa_static.js가 이 과정을 처리한다. - `/static/...`: static 파일 - (next.js프로젝트의 static폴더에 대한 설명) 이미지, 폰트같은 정적인 콘텐츠 - `/_next/static/...`: prefetch 되는 페이지 - (prefetch에 대한 간단한 설명): 다음 페이지 코드를 미리 가져와서 빨리 로드될 수 있게 준비하는 것
- [next.js SSR패키지 활용해서 프론트엔드 컨텐츠 리턴하는 영역] 지금 보는건 server_koa_root.js 코드. 이 코드가 전부임 next.js 패키지와 koa framework를 사용했고, 람다 레이어에서 빌드된 nextjs 번들을 가져와서 서빙하는 내용임 export된 모듈은 nextjs의 SSR에 대한 것과 express보다 가볍다고 알려져 있는 koajs 앱이다. nextappPath: Lambda Layer 임포트 경로. 프론트 서버가 lambda layer 내용을 불러오는 방법은 스테이징마다 다르게 분리 해 놨는데, (이전 슬라이드 설명한거 다시) 로컬 테스트 시에는 프로젝트 내 빌드된 앱 경로를 가르키고, 배포된 환경에선 /opt 경로를 입력해야 배포된 Lambda layer를 가져올 수 있다. 지금 루트 스크립트 설명인데, ‘/’로 들어오는 routing들은 이 lambda 펑션에서 받아들여서 koa framework를 이용하여 분기를 한다 그러면 next.js 함수인 app.render()를 써서 Lambda Layer의 ‘.next’폴더 안에 있는 페이지 경로를 가져와서 서빙을 한다. —------- [static.js] 처리는 좀 다름. router.get() 의 쓰임만 다르고 나머지는 같음. - 브라우저에 사이트가 처음 로드가 되고 난 이후에는 nextjs 앱이 프로젝트 안의 컨텐츠 경로인 /static, /.next/static 을 가져오게 된다. -> server_koa_static.js가 이 과정을 처리한다. - `/static/...`: static 파일(정적 파일) - (next.js프로젝트의 static폴더에 대한 설명) 이미지, 폰트같은 정적인 콘텐츠 - `/_next/static/...`: prefetch 되는 페이지 - (prefetch에 대한 간단한 설명): 다음 페이지 코드를 미리 가져와서 빨리 로드될 수 있게 준비하는 것 - path.replace() 를 쓴 이유는, 람다 레이어 안 빌드된 nextjs 번들 폴더 이름은 .next 이기 때문. 점으로 시작하는 라우팅 방법을 당시에 못찾아서 이렇게 했음. —-------
- [[백엔드]] node.js / 근본은 서버리스 프레임웍이다. 이걸로 API Gateway, 람다, 람다레이어, RDS접속을 위한 베스쳔 호스트 등을 만들었다. local / dev / prod로 스테이지를 나눴음 local 스테이지안에서 s3는 실제 AWS리소스 가져왔고, 나머지 람다 레이어, RDS 리소스는 로컬에 세팅된 것을 불러오고, dev / prod는 AWS에 배포된 리소스들을 불러오도록 했음 배포 스크립트는 package.json에서 스테이지별로 리소스가 분기되도록 함 백엔드 Lambda Layer 또한 모든 백엔드에서 공통으로 쓰이는 것들을 패키징했음. (/node_modules) API 요청 시 Cognito에 로그인 된 사용자만 접근할 수 있도록 authorizer 설정 구현: 이 설정 또한 serverless framework에 속성이 있음. authorizer설정에 참조한 Cognito 리소스는 프론트엔드에서 Amplify Framework으로 만들었던 Cognito User Pool 리소스 활용(만든 과정은 다음 슬라이드)
- .vscode/launch.json파일을 만들어서 package.json에 있는 스크립트를 디버그모드로 실행할 수 있게 세팅을 하였다. 3년전 세팅할 당시에는 launch.json에서 yarn으로 스크립트를 실행할 수 있는 방법을 찾지 못했었는데, 이번에 발표준비를 하면서 시도를 해 보니까 잘 되네요. 예전에는 안되어서 직접 sls 커맨더를 입력시키게 하였는데..
- 이렇게 세팅이 다 되고 나면 상단의 RUN AND DEBUG옆에 재생버튼을 눌러서 서버를 켜고, 코드에 브레이크포인트를 걸면 디버깅이 가능하다. 서버호출 테스트는 http확장자 파일을 만들어서 활용했는데, endpoint위에 자동으로 뜨는 Send Request버튼이 있는데, 한개의 http파일에 목적별로 여러 개의 endpoint를 입력해서 디버깅을 했던 기억이 난다.
- DB Instance 활용은 mysql2라는 패키지를 썼음. ORM을 쓰지 않고, 다른 개발자와의 소통을 위해 RAW SQL을 다룰 수 있는 mysql2패키지를 채택하였음. 당시 나 말고 다른 개발자는 ORM보다는 직접 MySQL Workbench에다가 쿼리를 직접 입력하면서 소통을 하는 스타일이었기 때문.. 설득할 시간도 없었고.. 그러다가 나도 점차 ORM보다는 로우쿼리로 개발하는 환경에 더 익숙해져 버렸다.. 로우쿼리를 짤때 조인문이나 UPSERT문 같은 경우는 그냥 개인적으로 구글링하면서 문법을 하나씩 알아가면서 해 나갔는데, 이렇게 새로 알아낸 쿼리를 써먹는 것에 재미가 붙어서 신나게 했던 기억이 남. BASTION HOST일 때에는 프로젝트 내의 pem파일을 불러와서 DB Instance를 가져오는 방식을 택하였음. 물론 pem파일은 gitignore에 포함이 되어 있음
- [[백엔드]] —------- VPC & NAT Gateway 를 설정함. 세팅된 VPC안에 Lambda, RDS가 들어있었고, 람다에서 S3 접근할때는 S3 endpoint를 설정해서 사용함. 이것은 제가 네트워크 알못이라 감사하게도 serverless-vpc-plugin 오픈소스가 있어서 이걸로 세팅을 했는데, 이 플러그인이 VPC, NAT Gateway, Bastion Host 리소스를 알아서 배포해줌. (내가 쓴 플러그인 설명) serverless-vpc-plugin 그당시 한국에 DAX 가 서비스 되지 않던 시절에 이 플러그인은 항상 배포 시 DAX옵션을 포함시켜서 한국리젼 배포에 에러가 났었는데, 그거를 고쳐서 풀리퀘를 올려서 기여를 했던 기억이 난다. - 그당시에는 모르는 상태에서 배워나가면서 힘겹게 따라잡으며 구현을 해 나갔는데, 우연치않게 서브넷 개념을 익히고 이렇게 오픈소스에 기여까지 하게 되니까 기분이 되게 좋았었던 기억이 난다. —------- [RDS: Bastion Host] 회사 특성상 이곳저곳에서 노마드생활이 가능하다보니 어떤 곳에선 RDS가 mysql 워크벤치를 통해 접속 되고, 어떤 곳에선 안되어서 (본가나 사무실에선 되는데 카페에선 안되고 내집에선 안됨) 검색해 보니 Bastion Host환경을 알게 되어 구축해 놓고 어느 곳에서든 접근이 가능하도록 했다. - 장소를 옮길 때마다 Bastion Host EC2인스턴스의 Security Group에서 그 장소의 네트워크 ip를 Inbound Rules에 추가하고, 그 장소를 떠나면 바로 지우는 부지런한 행동을 했었다.
- [[백엔드]] [람다펑션 워밍] Lambda의 콜드스타트가 많이 개선되었다고는 하지만 그래도 긴 텀을 두고 Lambda 펑션을 호출하면 응답까지 오래(몇초) 기다려야 했었다. 그래서 Lambda 펑션 워밍을 하기로 했고, 5분마다 CloudWatch Event Rule을 걸었다. (지금은 Amazon EventBridge Event Rule로 자동으로 옮겨졌더라.) 이 event를 설정하는 것 또한 서버리스 프레임웍으로 세팅이 쉽게 가능해서 활용했다.
- [Amplify & Cognito] 참고 자료: https://github.com/awskrug/kendra-button/wiki 원래는 Amplify에서 밀고 있던 완성된 UI 솔루션이 있었는데, 커스터마이징 하기는 너무 불편해서 그냥 Amplify auth API만 활용했다. 회원가입하면 이메일로 확인코드 날아감. 아이디/비번찾기도 Amplify auth API로 구현했음. (다음슬라이드에 구현 코드있음)
- (보여드리는 캡쳐는 다른 프로젝트의 예시임.) Amplify CLI 로 Cognito 리소스 만드는 장면. 이거는 다른 프로젝트 할때 기록한 것. 여러개를 물어봄. 어떤 형태의 인증 서비스를 쓸 것이냐 어떤 속성으로 로그인을 시키게 할 것이냐(Username이냐) UserPool Group을 만들 것이냐 회원가입/로그인 할때 추가액션을 할 수 있게 웹훅(?) 같은 라이프사이클 API를 추가하고 싶냐 MFA 붙일 것이냐 회원 가입/비번찾기할때 이메일로 인증코드 가게 할 것이냐 비밀번호 정책 쓸 것이냐 리프레시 토큰 며칠있다가 파기시킬 것이냐 CloudFormation 문법으로 파싱해서 리소스 배포해줌
- —------- (프론트엔드 얘기) Amplify에 S3를 쓰는 Storage API가 있었으나 파일 업로드 메소드를 쓸때 객체를 퍼블릭하게 공개하는 ‘public-read’ ACL 플래그가 빠져 있었다. 그래서 그냥 aws-sdk를 직접 임포트해서 코딩했다. aws-sdk로 S3 업로드르 하기 전에 백엔드에서 STS SDK를 이용한 임시 토큰 받아다가 accessKeyId, secretAccessKey, sessionToken 사용 투박한 방법이라고 개인적으로 생각. —------- (이렇게 하면 좋았을 걸 회고) - 누가 오픈소스로 amplify 리포지토리 fork를 해서 ACL을 포함시킨 API를 개발했었는데, 내가 공식적인것만 쓰고 싶어해서 애써 무시했다. 그냥 쓸껄 그랬나..? 그치만 시간 지나서 공식버전 쓴 게 아니란 걸 잊어버림 어떡해? - 그냥 preSigned url로 쓸걸 그랬나? Amplify팀에선 그걸 유도하려고 ACL을 뺀 게 아니었을까?
- (프론트엔드 얘기) Amplify에 S3를 쓰는 Storage API가 있었으나 파일 업로드 메소드를 쓸때 객체를 퍼블릭하게 공개하는 ‘public-read’ ACL 플래그가 빠져 있었다. 그래서 그냥 aws-sdk를 직접 임포트해서 코딩했다. aws-sdk로 S3 업로드르 하기 전에 백엔드에서 STS SDK를 이용한 임시 토큰 받아다가 accessKeyId, secretAccessKey, sessionToken 사용 투박한 방법이라고 개인적으로 생각. —------- 이게 백엔드 코드인데, AWS-SDK 의 STS API를 가져와서 S3 버킷 policy랑 role을 주입해가지고 토큰 정보를 얻는 것임. cognito쪽도 임시 토큰 받을 수 있도록 세팅은 했는데 결과적으론 cognito쪽은 안썼음 (이렇게 하면 좋았을 걸 회고) - 누가 amplify 리포지토리를 fork를 해서 “public-read” ACL을 포함시킨 API를 개발했었는데, 내가 공식적인것만 쓰고 싶어해서 애써 무시했다. 그냥 쓸껄 그랬나..? 그치만 시간 지나서 공식버전 쓴 게 아니란 걸 잊어버림 어떡해? - 그냥 preSigned url로 쓸걸 그랬나? Amplify팀에선 그걸 유도하려고 ACL을 뺀 게 아니었을까? —-------
- [[백엔드]] 대회 개최 하루 전에 모든 참가자들에게 안내메일 보내는 예약을 거는 기능을 도입하려고 했었다. dev 브랜치에서만 지금 구현되어있는데, CloudWatchEvents SDK로 cron식 써서 대회날짜 하루 전으로 설정해서 메일을 보내도록 했다.
- [[백엔드]] 백엔드에다가 템플릿 제작용 API를 이렇게 만들었음 이 API를 호출하면 새로운 버전의 이메일 양식 템플릿이 SES에 배포됨
- [[백엔드]] (대회안내 이메일 전송) 모든 참가신청자들에게 대회안내를 이메일로 보내는 람다 펑션 미리 준비되어 있는 SES 템플릿을 불러와서 여러 사용자에게 메일을 뿌리는 로직 aws-sdk SES의 sendBulkTemplatedEmail() 사용해서 여러 사용자에게 이메일을 뿌린다. 해당 함수가 최대 50개 대상에 메일을 보낼 수 있다고 해서 일단은 50개씩 끊어서 호출을 여러번 하는 식으로 했다. 물론 사용자가 너무 많아지면 발신한도 증가를 높이는 요청을 AWS에 할 수 있는 방법도 있다고 한다.
- [[백엔드]] (대회 주최 하루 전 알람) CloudWatch Events가 지금 Amazon EventBridge로 이동되어 있던데, SDK에서도 혹시 큰 변동이 일어난 것이 아닌지 모르겠다. 손을 안 댄 지 워낙 오래되었다보니.. putRule(): [좌측] 메일을 보내는 람다 함수에다가 대회 날짜 하루 전에 함수가 실행되는 cron식이 들어간 CloudWatch Event Rule을 퍼미션에 추가해 놓고, putTargets(): [우측] 해당 Rule에 대해서 실행시킬 람다함수 타깃들을 정의 해 놓는다. 그러면 CloudWatch Event가(Amazon EventBridge Event가), 시간이 되면 방금 전에 언급한 이메일 보내는 람다함수를 명시적으로 호출을 하게 됨.
- 좌측 사이드바 색인생성 -> Sitemaps 메뉴에서 일괄 페이지 등록 가능하지만 베타테스트 전 급하게 등록해야 해서 직접 등록시킴 어떻게 등록시켰냐면..
- URL검사 들어가서 url입력시키고 결과가 미등록되어 있다고 응답이 나오면 “색인 생성 요청”을 눌렀다.
- 베타테스트로 경기 당일에 현장에 가서 대형 tv랑 심판채점용 태블릿도 챙겨서 차에 싣고 김해로 달려감
- 베타테스트로 경기 당일에 현장에 가서 대형 tv랑 심판채점용 태블릿도 챙겨서