2018년 4월 24일 화요일

[AWS] 프론트엔드 개발자가 혼자 웹어플리케이션 만들기. #3. AWS Amplify와 S3를 이용한 이미지 저장

[AWS] 프론트엔드 개발자가 혼자 웹어플리케이션 만들기. #3. AWS Amplify와 S3를 이용한 이미지 저장


시리즈 포스팅 순서
#1. 시리즈 포스팅 소개
#2. AWS Amplify와 Cognito를 이용한 회원가입, 로그인 기능 구현
#3. AWS Amplify와 S3를 이용한 이미지 저장
#4. AWS API Gateway, Lambda, DynamoDB를 이용한 REST API 구현
      (Amplify를 이용한 API 호출 방법 포함)
#5. AWS Lambda에 Express.js 기반의 웹어플리케이션 배포하기
      (AWS ACM, API Gateway를 이용한 Custom Domain 적용 방법 포함)
#6. AWS S3에 Static Web Hosting으로 SPA(Single Page Application) 웹어플리케이션 배포하기
      (AWS CloudFront, Route53을 이용한 HTTPS 지원방법 포함)


  이번 포스팅에서는 웹어플리케이션에서 AWS Amplify를 이용하여 AWS S3에 이미지를 업로드 하는 방법을 정리해보려합니다. 사실 이미지가 아닌 모든 파일이 가능하지만, 이번 시리즈에서 예시로 사용하는 웹어플리케이션인 NameSite에 필요한 기능이 이미지 업로드이기 때문에 이미지 파일을 업로드 하는 방법을 정리해봅시다.


> 1. AWS S3 준비

  가장먼저 준비되야할 것은 이미지 파일이 저장될 S3 버킷입니다. 버킷 생성은 매우 간단한 작업입니다.

  S3 대시보드에서 '버킷 만들기'를 클릭합니다.
(그림) '버킷 만들기' 클릭


  그렇게 하면, 아래와 같이 버킷 생성을 위한 정보를 입력하는 창이 뜨는데, 여기서 '버킷 이름'과 '리전'만 선택한 다음에 '생성'을 클릭합니다. 이름은 모든 AWS 유저의 S3 버킷 이름과 중복될 수 없습니다. 혹시 중복된 이름이라서 사용할 수 없다고 오류가 난다면, 조금 더 자신만의 식별자가 될 수 있는 이름을 사용하시길 권장합니다.

(그림) 버킷 생성을 위한 정보 입력


  이렇게 버킷 생성이 간단히 끝나면, 아래와 같이 생성한 버킷이 S3 대시보드의 버킷 리스트에 나타납니다.

(그림) 버킷 생성 후, 리스트에 버킷이 추가 됨


  지금부터는 방금 생성한 버킷을 웹어플리케이션의 리소스 저장소로 사용하기 위하여, 버킷을 Public으로 설정하고 CORS 설정을 하겠습니다.

  버킷을 Public으로 설정한다는 것은, 버킷에 업로드 된 파일들이 인터넷에 공개적으로 노출 된다는 것을 의미합니다. S3 버킷에 업로드 된 파일에는 각각이 고유한 URL이 생성되는데, 버킷이 Public이라면 익명의 사용자가 파일의 URL로 접근했을 때 파일을 다운로드 받을 수 있습니다. 그래서 AWS에서도 버킷을 Public으로 설정하는 작업은 조심하라고 주의를 주고 있습니다. 하지만, 웹사이트에 노출되야하는 이미지들은 Public이여야 하기 때문에 이번 포스팅에서는 S3 버킷을 Public으로 설정하겠습니다.

  버킷을 Public으로 설정하기 위해서는 아래와 같이 해당 버킷의 '권한' 탭으로 이동합니다. 그리고 하위 버튼 중에 '버킷 정책'을 선택합니다.

(그림) S3 버킷의 Public 설정을 위한 이동


  '버킷 정책'을 선택하면 하단에 정책을 입력할 수 있는 입력칸이 나타납니다. 그곳에 아래 정책을 복사하고, '{버킷 이름}' 부분만 본인의 버킷 이름으로 수정합니다. 아래 정책은 지정한 버킷의 모든 파일을 누구나 접근할 수 있게 허용하는 정책입니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::{버킷 이름}/*"
        }
    ]
}



  그리고 CORS 설정도 해줍니다. '버킷 정책'과 동일한 '권한' 탭에서 'CORS 구성'을 선택합니다.(권한탭에 '퍼블릿'이라는 이름이 붙었는데, 이는 버킷 정책에서 모든 사용자가 접근할 수 있게 정책을 설정해서 그런것입니다.)

(그림) 'CORS 구성' 선택


  CORS 구성을 선택하면 나타나는 입력칸에 아래 내용을 그대로 복사해서 붙여넣습니다.

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>DELETE</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <ExposeHeader>x-amz-server-side-encryption</ExposeHeader>
    <ExposeHeader>x-amz-request-id</ExposeHeader>
    <ExposeHeader>x-amz-id-2</ExposeHeader>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>


  이로써, 이미지 파일이 저장될 S3 버킷 준비는 끝났습니다.


> 2. AWS Amplify 설정

  위에서 이미지 파일을 저장할 S3 버킷을 생성했으니, Javascript에서 이미지 파일을 올려야합니다. 이때, AWS Amplify 라이브러리를 이용하려 합니다.

Amplify 라이브러리에 대한 소개와 Amplify 설정 위치는 이전 포스팅을 참고해주시기 바랍니다.

  AWS S3는 Amplify의 Storage 모듈을 이용해서 사용할 수 있습니다. 그러기 위해서 Amplify에서 Storage 모듈을 이용하기 위한 설정을 해주어야합니다. 그 방법은 아래와 같습니다.

  이전 포스팅에서는 Amplify의 Auth 모듈에 대한 설정을 했는데, 거기에 추가로 Storage 모듈에 대한 설정을 아래와 같이 추가합니다. Storage 모듈을 사용하려면 S3 버킷에 파일을 업로드 할 수 있는 권한을 가진 자격증명이 있어야하기 때문에 반드시 Auth 모듈과 함께 설정되어야합니다.
  그리고 로그인하지 않은 익명의 사용자도 파일을 업로드할 수 있게 하기 위해서는, 'identityPoolId'에 입력하는 자격증명풀은 생성하실 때 또는 수정에서 '인증되지 않은 자격 증명에 대한 액세스 활성화'를 체크하시고 IAM Role(역할)에서 해당 자격증명풀(Identity Pool)의 인증되지 않은 사용자를 위한 역할에 S3에 접근할수 있는 정책(Policy)을 추가시켜주셔야합니다.

  아래의 코드는 Storage 모듈을 사용하기 위한 최소한의 Auth 모듈 설정을 작성했습니다.

Amplify.configure({
  Auth: {
    identityPoolId: 'ap-northeast-0:00000000-0000-0000-0000-000000000000',
    region: '{리전 코드}', // 서울리전: ap-northeast-2
  },
  Storage: {
    bucket: '{버킷 이름}', // S3 버킷 이름
    region: '{리전 코드}', // 버킷을 생성한 리전 코드
  }
})



> 3. AWS Amplify.Stoarge API를 이용해서 S3에 이미지 파일 업로드하기

  Amplify의 Storage 모듈 설정이 끝났으면 Storage API를 이용해서 S3 버킷에 파일을 업로드할 수 있습니다.

  예시로 사용되는 코드는 Vue.js 기반의 코드입니다. 하지만 간단한 코드이기 때문에 다른 프론트엔드 프레임워크를 사용하시는 분들도 쉽게 응용가능하시리라 생각합니다.

  우선 html 코드에서 input태그로 파일을 입력받습니다. 그리고 저는 파일이 선택되었을때, handleOnChangeFileS3() 라는 메소드가 실행되도록 하였습니다.

<input type="file" @change="handleOnChangeFileS3($event)">


  handleOnChangeFileS3() 메소드의 코드는 아래와 같습니다. 단지 javascript에서 file 객체를 획득하고, 업로드할 파일 이름을 정한뒤에 Amplify Storage API로 업로드합니다.

handleOnChangeFileS3 (e) {
  e.preventDefault()

  let inputFile = e.target.files[0]
  let date = new Date()

  this.$s3.put(`test-${date.getTime()}-${inputFile.name}`, inputFile)
  .then(resp => {
    console.log(resp.key)
    // resp.key에 업로드한 파일의 이름이 응답으로 옴.
    //이때, 객체의 URL 주소가 아니라 그냥 파일 이름만 key에 담겨서 옴.
  }).catch(err => {
    console.log(err)
  })
}

  Amplify.Storage.put() 메소드를 이용해서 파일을 업로드하고 나면, 응답 객체에 업로드한 파일의 이름이 응답으로 전달됩니다. 그런데, 이 파일의 이름이 S3 객체의 URL이 아니라 그냥 파일 이름뿐이기 때문에, S3에 업로드된 파일의 URL을 javascript에서 쓰고 싶다면 수동으로 붙여줘야합니다.



  이로써, AWS Amplify를 이용해서 AWS S3에 이미지 파일을 업로드 하는 방법을 정리해보았습니다. 혹여 설명이 부족하다면 댓글로 질문해주시면 빠른 시일내에 답변드리겠습니다.
  또한, 잘못된 부분이 있거나 건의해주실 내용도 댓글로 달아주시면 추가 반영하도록 하겠습니다.

  감사합니다.




2018년 4월 18일 수요일

[AWS] 프론트엔드 개발자가 혼자 웹어플리케이션 만들기. #2. AWS Amplify와 Cognito를 이용한 회원가입, 로그인 기능 구현

[AWS] 프론트엔드 개발자가 혼자 웹어플리케이션 만들기. #2. AWS Amplify와 Cognito를 이용한 회원가입, 로그인 기능 구현



시리즈 포스팅 순서
#1. 시리즈 포스팅 소개
#2. AWS Amplify와 Cognito를 이용한 회원가입, 로그인 기능 구현
#3. AWS Amplify와 S3를 이용한 이미지 저장
#4. AWS API Gateway, Lambda, DynamoDB를 이용한 REST API 구현
      (Amplify를 이용한 API 호출 방법 포함)
#5. AWS Lambda에 Express.js 기반의 웹어플리케이션 배포하기
      (AWS ACM, API Gateway를 이용한 Custom Domain 적용 방법 포함)
#6. AWS S3에 Static Web Hosting으로 SPA(Single Page Application) 웹어플리케이션 배포하기
      (AWS CloudFront, Route53을 이용한 HTTPS 지원방법 포함)


  이번 포스팅에서는 웹어플리케이션에 회원가입, 로그인과 같은 회원 인증 관리 기능을 추가 하기 위하여 AWS Cognito를 이용하는 방법을 정리하겠습니다.

  먼저, AWS Cognito에 대하여 소개하고, Cognito에 새로운 User Pool을 생성하고 자격증명풀까지 생성한 다음에, AWS Amplify를 이용해서 웹어플리케이션에서 Cognito를 사용하는 방법을 소개하겠습니다.


> 1. AWS Cognito는 무엇인가?

  AWS의 Cognito는 손쉽게 회원 인증 관리 기능을 구현할 수 있는 서비스입니다. 쉽게 말하자면, 웹어플리케이션에서 회원가입, 로그인 기능을 구현 할 수 있게 간단히 백엔드 시스템을 만들어 주는 서비스입니다.
  또한, Facebook, Google 및 Amazon과 같은 소셜 자격 증명 공급자와 엔터프라이즈 자격 증명 공급자(SAML 2.0 사용)를 통한 로그인을 지원합니다.

> 2. AWS Cognito에서 UserPool(사용자풀) 생성하기

  AWS Cognito는 User Pool(사용자풀)과 Identity Pool(자격증명풀)을 제공합니다.
  User Pool은 회원 DB(Database)라고 생각하시면 됩니다. 그래서 User Pool에서는 회원가입 시에 어떤 정보를 필수로 입력 받을지, 비밀번호 규칙은 어떻게 될지 등의 설정을 하게 됩니다.

  이제, 웹어플리케이션에 연결시킬 User Pool을 생성하는 방법을 정리해보겠습니다.

  먼저, AWS Console에서 Cognito 서비스를 선택하면 아래와 같이 '사용자 풀 관리'와 '연동 자격 증명 관리'가 있습니다. 여기서 '사용자 풀 관리'를 선택합니다.

(그림) '사용자 풀 관리' 선택

  그러면, 새로운 User Pool을 생성할 수 있는 버튼이 있습니다. '사용자 풀 생성' 버튼을 클릭해서 User Pool을 생성하는 절차를 시작합니다.

(그림) '사용자 풀 생성' 클릭

  본 포스팅에서는 주요 설정에 대해서만 살펴보겠습니다. 여기서 다루지 않는 설정은 '다음 단계'를 클릭해서 넘어가도 괜찮습니다.

  첫번째로, '풀 이름'을 원하는 이름으로 입력하고, '설정을 순서대로 진행'을 선택합니다. '기본값 검토'는 모든 설정을 기본값으로 한 상태에서 마지막 검토 페이지로 바로 이동합니다. '설정을 순서대로 진행'을 선택하면 User Pool 생성 단계를 모두 거치면서 원하는 옵션을 선택할 수 있습니다.
  물론, '기본값 검토'를 선택해도 마지막 검토 페이지에서 특정 설정을 변경할 수 있습니다.

(그림) 풀 이름 입력


  로그인 방법 설정을 선택합니다.
  '사용자 이름'을 선택한다면, 회원 가입 시에 아이디(ID)를 입력받고 그것을 이용해서 로그인을 합니다. '사용자 이름' 하위에 있는 옵션들은 아이디는 아니지만 아이디처럼 입력해서 로그인 할 수 있는 옵션들입니다.
  '이메일 주소 또는 전화 번호'는 회원 가입 시에 아이디를 사용하지 않고 이메일이나 전화번호를 아이디로 사용하는 옵션입니다. 최근에는 많은 사이트에서 이메일을 아이디로 사용하는데, 이 옵션을 사용하면 그렇게 사용할 수 있습니다.

(그림) 로그인 방법 선택


  표준 속성 체크란은 회원이 회원 가입할 때 필수로 입력 받아야하는 속성을 선택하는 옵션입니다. 체크를 한다면 필수로 입력 받아야하지만, 체크를 하지 않는다고해서 사용 못하는 속성은 아닙니다. 체크를 하지 않더라도 회원 가입 시에 입력 받고 User Pool에 저장할 수 있습니다.
  그리고 사용자 지정 속성을 추가해서 기본 옵션 이외에 원하는 사용자 정보를 저장할 수 있습니다.

(그림) 사용자 속성 설정


  암호 규칙은 기본적으로 8자 이상 입력, 숫자 포함, 특수 문자 포함, 대소문자 포함을 권장합니다. 하지만 높은 보안성을 위한 권장 일뿐이라서 원하시는 옵션만 선택하셔도 됩니다.

(그림) 암호 규칙 설정


  이메일 또는 전화 번호(휴대폰 번호)를 입력 받기로 했다면, 각각에 대해서 본인 소유의 이메일 또는 전화 번호가 맞는지 확인을 요청할 수 있습니다.
  옵션에서 확인을 원하는 옵션을 선택합니다.
  만약, 전화 번호를 확인하기로 하였다면, 확인 방법은 문자메세지(SMS)로 인증 번호를 전송하고 이 인증 번호를 웹사이트에서 입력하여 확인하는 것입니다. 그렇기 때문에 Cognito가 SMS을 보낼 수 있는 권한이 있어야하기에 하단에 '역할 생성' 버튼을 눌러서 자동으로 역할이 생성되고 할당되도록 해주어야 합니다.

(그림) 연락처를 이용한 사용자 확인 방법 설정


  이메일이나 휴대폰 번호로 전송되는 메세지를 편집 할 수 있습니다.
  이메일의 경우에는 인증 방법이 2가지가 있는데, '코드' 방식은 SMS와 동일하게 인증번호를 보내고 이를 웹사이트에서 입력하여 확인하는 방법이고, '링크' 방식은 이메일로 확인 링크를 보내서 사용자가 링크를 눌렀을 때, 바로 사용자 확인이 되도록 하는 방식입니다.
  이때 주의할 사항이 한가지 있습니다. 페이지 언어가 한국어일 경우에 확인 링크가 들어가는 부분이 '{##이메일 확인##}'으로 되어 있는데, 기본값임에도 불구하고 나중에 풀생성 하려할때 오류가 발생합니다. 이 부분은 '{##Click Here##}'로 수정해주어야합니다.

(그림) 사용자 확인 메세지 설정

  앱 클라이언트는 생성하고 있는 User Pool을 웹어플리케이션 또는 앱(App)과의 연결점 입니다. 웹어플리케이션 또는 앱에서는 User Pool ID와 앱 클라이언트 ID로 User Pool에 접근할 수 있습니다.
  '앱 클라이언트 추가'를 클릭하면 아래처럼 추가 화면으로 바뀌고, 여기서 '앱 클라이언트 이름'을 입력해줍니다. 그리고 연결하려는 앱이 Javascript를 이용하는 웹어플리케이션이라면 반드시 '클라이언트 보안키 생성' 옵션을 체크해제 해주어야합니다. 그렇지 않으면 오류가 발생한다고 합니다.

(그림) 앱 클라이언트 추가

(그림) 앱 클라이언트 설정


  모든 설정을 완료하고나면 마지막으로 설정값들을 검토하는 페이지가 나타나며, 여기서 '풀 생성'을 클릭하면 User Pool 생성이 완료됩니다.

(그림) User Pool 생성 직전의 검토 단계


  풀 생성이 완료되면 User Pool ID가 부여되며, '앱 클라이언트 설정'에서는 앱 클라이언트 ID를 확인 할 수 있습니다. 이 값들은 나중에 웹어플리케이션에서 User Pool에 접근하기 위하여 Javascript 라이브러리의 설정으로 입력해야합니다.

(그림) User Pool ID 확인

(그림) 앱 클라이언트 ID 확인


  부가적으로, User Pool을 생성할 때 사용자 확인 방법을 이메일 링크 방식을 선택했다면, User Pool 생성 이후에 '앱 통합 > 도메인 이름'에서 서브 도메인을 설정해줘야합니다.
  왜냐하면, 사용자가 이메일에서 링크를 클릭했을 때, 확인 결과를 보여주는 페이지가 필요한데, 여기서 설정한 도메인을 해당 페이지 주소로 사용하기 때문입니다.
  도메인 이름을 설정하지 않는다면, 사용자 가입부터가 되지 않습니다.

(그림) 도메인 이름 설정.
이메일 링크 방식을 선택했다면 필수 작업.


> 3. AWS Cognito에서 Identity Pool(자격증명풀) 생성하기

  AWS Cognito에서 제공하는 두번째 서비스는 Identity Pool(자격증명풀)입니다.
  Identity Pool(자격증명풀)은 User Pool과 연결하여, 연결한 User Pool의 회원에게 임시 자격증명을 부여하여 권한에 맞는 AWS 자원에 접근이 가능하게 합니다.

  Identity Pool을 생성해보겠습니다.
  먼저, Cognito 페이지에서 '연동 자격 증명 관리'를 선택합니다.

(그림) 연동 자격 증명 관리 선택


  만들어 놓은 자격 증명 풀이 없다면, 바로 새로 생성하는 단계로 진입합니다. 그렇지 않다면, '새 자격 증명 풀 만들기'를 선택하여 풀 생성 단계로 진입합니다.

(그림) 새 자격 증명 풀 만들기 클릭


  생성에 필요한 정보는 '자격 증명 풀 이름'과 '인증 공급자'에 입력할 Cognito '사용자 풀 ID', '앱 클라이언트 ID'입니다.
  만약, 로그인 하지 않은 사용자에 대해서도 어느정도 AWS 자원에 접근 가능하게 해주고 싶다면, '인증되지 않은 자격 증명에 대한 액세스 활성화'를 체크하시면 됩니다.

(그림) 자격 증명 풀 생성을 위한 정보 입력


  '풀 생성'을 하려하면 역할 설정을 해주어야합니다. 위에서도 설명했듯이, Identity Pool은 로그인한 회원에게 임시 자격 증명을 부여합니다. 여기서 설정하는 역할 설정은, 임시 자격 증명으로 접근 가능한 AWS 자원을 설정하는 작업입니다.
  이 페이지에서 '허용'을 클릭했을 때, IAM 역할(role)에 새로운 역할이 생성되는데, 이 역할에 할당되어 있는 권한들이 임시 자격 증명을 가진 사용자들에게 부여되는 권한입니다.
  본 시리즈에서는 지금 생성하는 자격 증명으로 S3에 이미지 파일을 업로드하는 권한을 부여할 것이기 때문에, 자격증명풀 생성 이후에, 이 단계에서 생성되는 IAM 역할에 S3 버킷을 관리할 수 있는 정책을 추가해주시기 바랍니다.

(그림) 생성하는 자격 증명 풀이 AWS 자원에 접근할 수 있게 역할 부여


  모든 과정을 완료하면 샘플 코드에서 Identity Pool ID를 확인할 수 있습니다.

(그림) Identity Pool ID 확인


> 4. AWS Amplify를 이용해서 웹어플리케이션에서 Cognito 사용하기

  AWS Amplify는 AWS에서 만들고 있는 Javascript 라이브러리입니다. Amplify는 AWS 뿐만 아니라 다른 클라우드 서비스들을 Javascript에서 쉽게 사용할 수 있게 해주는 라이브러리입니다. 하지만 Amplify가 아직 완성도가 많이 높지는 않기 때문에 AWS에 가장 적합하며, AWS 서비스를 사용하기에도 조금은 미흡한 부분들이 있지만 기본적인 기능들은 아주 쉽게 이용가능합니다.

AWS Amplify 공식 웹사이트 : https://aws.github.io/aws-amplify

  공식 웹사이트를 참고해서 프로젝트에 Amplify를 설치하신 후에, 아래의 설명을 보시면서 웹어플리케이션에서 Cognito를 이용하실 수 있습니다.


  우선, Amplify을 웹어플리케이션에서 사용하기 위해서는 Amplify에 설정을 해주어야 합니다. Cognito를 이용하기 위한 설정은 아래와 같습니다.

  설정을 위해서는 2개의 파일이 필요합니다. 첫번째는, 설정값을 가진 객체를 export하는 파일(aws-export.js)이고, 두번째는, Amplify에 설정값을 적용하고 사용하는 파일(aws-amplify.js)입니다. 파일명은 원하시는 것으로 변경해도 좋습니다.
  이렇게 파일을 나눈 이유는, 설정값들이 공개되면 좋지 않은 AWS 자원의 고유값들이기 때문에 설정값을 가진 파일은 .gitignore에 추가하여 Git Repository에 업로드되어 공개되지 않게 하기 위함입니다.

  Cognito의 정보는 Auth라는 키값으로 설정하여 Amplify에 적용하게 됩니다. 그리고 하위 속성으로 region, identityPoolId, userPoolId, userPoolWebClientId를 입력해야합니다.
  각 속성에 대한 이해를 위해서 그림에 있는 주석을 확인해주시기 바랍니다.
  각 속성에 필요한 값들은 위의 Cognito Pool 생성에서 모두 확인 가능합니다.

(그림) Cognito 사용을 위한 Amplify Auth 설정. (aws-export.js)

  이제, 위에서 설정한 값을 Amplify에 적용해야합니다.
  저는 웹프레임워크로 Vue.js의 서버사이드렌더링(SSR) 프레임워크인 Nuxt.js를 사용합니다. 그래서 Amplify를 Vue의 Plugin으로 설정해서 조금 더 사용하기 쉽게 사용하려 합니다.
  아래 코드는 plugin으로 Amplify.Auth를 사용하는 코드입니다만, 중요한 부분은 위의 설정을 import해와서 Amplify.configure()로 적용시켜줬다는 것입니다. 다른 웹프레임워크를 사용하시더라도 이처럼 설정을 Amplify에 적용하시기만 하면 됩니다.
(그림) Amplify를 Vue.js의 plugin으로 등록

  Amplify.Auth를 Vue.js의 plugin으로 등록하여 vue 인스턴스 속성으로 만들었기 때문에 저는 아래와 같이 Amplify.Auth 기능을 사용할 수 있었습니다. signUp을 포함한 기타 함수들에 대한 정보는 Amplify의 Auth Docs에서 확인하실 수 있습니다.

(그림) Amplify.Auth를 이용한 Cognito 회원가입

  참고사항으로, Amplify.Auth를 이용하여 로그인(signIn) 함수를 수행했을때, Access Token등이 자동으로 로컬 브라우저의 특정 Storage에 저장됩니다. 만약, Storage를 쿠키로 설정했다면 로그인 후에 Cognito로부터 응답으로 오는 각종 Token이 쿠키에 저장됩니다.


  여기까지해서, AWS Cognito에서 User Pool과 Identity Pool을 생성하고, AWS Amplify를 이용해서 javascript에서 Cognito를 사용하는 방법을 정리해보았습니다.
  부족한 부분, 잘못 된 부분, 궁금한 부분은 언제나 댓글 또는 메일을 보내주시면 피드백 드리도록 하겠습니다.
  긴 글 읽어주셔서 감사합니다.


[AWS] 프론트엔드 개발자가 혼자 웹어플리케이션 만들기. #1. 시리즈 포스팅 소개

[AWS] 프론트엔드 개발자가 혼자 웹어플리케이션 만들기. #1. 시리즈 포스팅 소개


시리즈 포스팅 순서
#1. 시리즈 포스팅 소개
#2. AWS Amplify와 Cognito를 이용한 회원가입, 로그인 기능 구현
#3. AWS Amplify와 S3를 이용한 이미지 저장
#4. AWS API Gateway, Lambda, DynamoDB를 이용한 REST API 구현
      (Amplify를 이용한 API 호출 방법 포함)
#5. AWS Lambda에 Express.js 기반의 웹어플리케이션 배포하기
      (AWS ACM, API Gateway를 이용한 Custom Domain 적용 방법 포함)
#6. AWS S3에 Static Web Hosting으로 SPA(Single Page Application) 웹어플리케이션 배포하기
      (AWS CloudFront, Route53을 이용한 HTTPS 지원방법 포함)


이번에는 처음으로 포스팅을 한가지 주제에 대한 시리즈로 작성해보려고 합니다.
우선, 주제는 'AWS Serverless(서버리스)를 이용해서, 프론트엔드 개발자가 혼자 웹어플리케이션 만들기'입니다.

이번 포스팅에서는 본 시리즈에서 예시로 사용할 간단한 웹어플리케이션에 대한 소개를 하고, 해당 웹어플리케이션과 관련해서 제가 위와 같은 주제를 정리하게 된 이유를 소개하려합니다. 마지막으로는, 시리즈의 차례를 소개하겠습니다.


> 예시로 사용할 웹어플리케이션: NameSite

  이번 시리즈에서 예시로 사용할 웹어플리케이션의 이름은 NameSite입니다.
  보통 자신의 이름, 회사, 이메일, 연락처 등을 간단히 전달하기 위해 우리는 명함(NameCard)를 사용합니다.
  저는 명함(NameCard)와 같은 용도로 사용할 수 있는 템플릿이 정해진 개인 웹사이트를 만들 수 있는 웹어플리케이션을 만들어보려합니다. 그리고 그 웹어플리케이션의 이름을 NameCard에서 따와서 NameSite라고 지었습니다.

(그림) NameSite 간략 디자인

  NameSite에 대한 기능을 설명하자면, NameSite의 관리자페이지에서 로그인 한 사용자가 정해진 템플릿에 커버 이미지, 프로필 이미지, 해시태그, 기타 정보를 작성하고 저장합니다.
  저장 후에 개인 NameSite(ex. my-namesite.walkinpcm.com/{개인도메인})에 접속하면 명함처럼 저장된 정보가 나타나게됩니다.

  이와 같은 웹어플리케이션을 만들기 위해서는 크게 아래와 같은 기능들이 필요합니다.

  • 사용자 관리(로그인)
  • 이미지 저장
  • 정보 저장
  • 웹어플리케이션을 구동할 서버

  이런 기능들을 구현하려면 프론트엔드 개발 이외에, 백엔드에서 REST API를 제공하는 Web Server, Database, Storage 등을 구축해야할 것입니다.

> 프론트엔드 개발자의 한계

  NameSite를 만들기 위해서 프론트엔드 개발자와 백엔드 개발자가 모두 있었다면 각자의 역할을 수행하면서 NameSite를 만들어내면 될 것입니다. 하지만 문제가 있습니다. 제가 프론트엔드 개발자라서 프론트엔드는 직접 만들어내면 되지만, 백엔드 개발자가 없고 제가 백엔드를 구현할 능력도 없습니다.
  이렇게 한계에 부딪쳐서 만들고 싶은 웹어플리케이션을 못 만들게 될까요?

> 구원자, AWS Serverless

  이러한 고민을 하는 개발자가 비단 저 뿐만은 아닌듯 합니다. 그래서인지 언제나 개발자들을 최우선으로 생각하고 개발자들을 위한 좋은 서비스를 AWS에서는 Serverless 서비스들을 제공하고있습니다.

  Serverless에 대해서 AWS에서는 아래와 같이 정의하고 있습니다.

"서버리스 컴퓨팅을 사용하면 서버를 고려하지 않고 애플리케이션과 서비스를 구축하고 실행할 수 있습니다. 서버리스 애플리케이션에서는 사용자가 서버를 프로비저닝, 확장 및 관리할 필요가 없습니다. 거의 모든 유형의 애플리케이션 또는 백엔드 서비스를 서버리스로 구축할 수 있으며, 애플리케이션을 고가용성으로 실행하고 확장하는 데 필요한 모든 것이 자동으로 처리됩니다."

  강조해 놓은 부분들이 참 매력적인 말들입니다. 그리고 그 말들이 AWS Serverless의 장점들입니다. 기존의 IDC에서 서버 장비를 대여하는 방식이나, EC2와 같은 가상서버에서 서비스를 구현한다면, 구성요소 하나하나를 직접 구축해야하며, 고가용성을 달성하기 위한 시스템 아키텍처 구성 등의 작업도 해야할 것입니다.
  하지만, AWS Serverless를 이용한다면 AWS Console 화면에서 정말 간단한 절차로 고가용성의 백엔드 서비스를 만드는게 가능합니다. 이후의 포스팅에서는 NameSite의 핵심 기능들 만드는 방법을 소개하며, 이때 사용되는 AWS 서비스들을 함께 소개하겠습니다.

> 앞으로의 차례

본 포스팅에서 소개한 예시 웹어플리케이션인 NameSite를 만들기 위해 필수적인 백엔드 시스템을 만들기 위한 자세한 방법들을 아래와 같은 순서로 포스팅을 작성해보도록 하겠습니다.

  1. AWS Amplify와 Cognito를 이용한 회원가입, 로그인 기능 구현
  2. AWS Amplify와 S3를 이용한 이미지 저장
  3. AWS API Gateway, Lambda, DynamoDB를 이용한 REST API 구현
    (Amplify를 이용한 API 호출 방법 포함)
  4. AWS Lambda에 Express.js 기반의 웹어플리케이션 배포하기
    (AWS ACM, API Gateway를 이용한 Custom Domain 적용 방법 포함)
  5. AWS S3에 Static Web Hosting으로 SPA(Single Page Application) 웹어플리케이션 배포하기
    (AWS CloudFront, Route53을 이용한 HTTPS 지원방법 포함)



앞으로 작성하는 모든 글에 대해서 혹여 잘못 된 내용이 있거나, 질문이 있으시거나, 기타 의견이 있으시다면 언제든지 댓글 달아주시면 최대한 빨리 피드백 드리도록 하겠습니다.

감사합니다.




2017년 11월 11일 토요일

[Web] Vue.js + PWA + pre-render 프로젝트 틀 잡기 (feat. AWS S3를 이용한 웹호스팅)

Vue.js + PWA + pre-render 프로젝트 틀 잡기

(feat. AWS S3를 이용한 웹호스팅)



이번 포스팅에서는 [ Vue.js + PWA + pre-render ] 조합의 웹앱을 [ AWS S3 + CloudFront ] 조합에서 웹호스팅을 할 계획으로 Vue.js 프로젝트를 준비하는 과정을 정리해보려합니다.

0. 왜 이런 조합의 프로젝트를 준비하는가?

프로젝트를 준비하기에 앞서 제 스스로도 목적을 정리하고자 왜 위와 같은 조합을 만드는지 써보려합니다.
가볍게 의식의 흐름대로 써보자면 ㅎㅎ
Vue.js로 만든 웹페이지를 만들자!
=======================> Vue.js
그런데, 앱 같은 웹을 만들어서
우리는 웹을 만들지만 사용자는 앱을 사용하는 것처럼 느끼게 하자.
=======================> PWA(Progressive Web Apps)
이렇게 웹앱을 만들어서 AWS S3에서 웹호스팅하면,
서버 비용도 줄고 가용성도 좋으니깐, AWS S3에서 웹호스팅 하자.
=======================> AWS S3
아참! PWA를 위해서는 HTTPS를 지원해야겠다!
=======================> AWS CloudFront(with AWS ACM)
아...근데 일부 소개 페이지는 SEO도 되야겠는데..
서버가 없으니 SSR이 안되겠네..
그럼 SEO를 위한 페이지만 pre rendering을 하자!
=======================> pre-render

이런 의식의 흐름으로 [ Vue.js + PWA + pre-render ] & [ AWS S3 + CloudFront ] 조합이 탄생했습니다 ㅎㅎㅎㅎ


1. 프로젝트 시작

Vue.js webpack template 중에 PWA(Progressive Web Apps)를 위한 탬플릿이 이미 존재합니다.
아래 Github에서 해당 탬플릿을 시작할 수 있습니다.
https://github.com/vuejs-templates/pwa
해당 탬플릿의 원형은 vue webpack template이기 때문에 프로젝트 구조 등에 대한 문서는 아래 링크를 확인하면 좋습니다.
https://vuejs-templates.github.io/webpack
문서의 안내에 따라서 프로젝트를 시작할 폴더에서 아래의 명령으로 탬플릿을 다운로드 받습니다.
(단, vue-cli가 사전에 설치되어 있어야합니다.)
// 탬플릿 다운로드
$ vue init pwa my-project

// 프로젝트 폴더로 이동
$ cd my-project

// 의존 패키지 설치
$ npm install

// 개발 서버 시작
$ npm run dev
탬플릿을 다운로드 받을 때 프로젝트 설정을 위한 질문이 여러개 나오는데, 전부 디폴트로 설정해도 무방하고 조금 다른 설정을 해주고 싶은 것만 선택하시면 됩니다.
여기까지만으로도 벌써 Vue.js를 이용한 PWA 웹앱의 기반이 다져졌습니다!
여기서, 딱 두개만 수정을 하겠습니다.
(1) PWA 웹앱을 만들기 위한 manifest.json 파일에서 start_url을 아래와 같이 수정해줍니다.
// 
{
  "start_url": "/",
}
기본적으로는 /index.html로 설정되어 있는데 이것을 / 로 수정합니다.
왜냐하면, 본 포스팅에서는 PWA 웹앱을 AWS S3에 업로드하여 웹호스팅을 하고 AWS CloudFront와 연결하여 https 지원을 할 예정인데,
AWS에 PWA 웹앱을 연결하는 과정에서 이미 최초 진입 파일을 index.html로 설정하기 때문에 manifest.json에서는 시작 주소를 단지 루트(/) 경로만 표시해줘야 정상작동합니다.
(2) /build/service-worker-prod.js에서 service-worker.js 파일 위치를 수정합니다.
load 이벤트 리스너를 추가하는 부분에서 sevice-worker.js를 등록하는 코드가 아래처럼 있습니다.
navigator.serviceWorker.register('service-worker.js')
기존 처럼 되어 있으면 하위 path마다 각 path에서 service-worker.js를 찾게되고 당연히 파일이 없을거라서 등록에서 오류가 납니다.
그래서 아래처럼 파일 이름 앞에 슬래쉬를 붙여서 절대주소를 명시합니다.
navigator.serviceWorker.register('/service-worker.js')



2. 프로젝트 배포

2-1. AWS S3 + CloudFront 에 웹앱 배포

저는 AWS S3에 프로젝트를 배포하고 S3의 웹호스팅 기능으로 웹앱을 사용해 보려합니다.
AWS S3로 웹호스팅 하는 방법을 아래 링크를 참고하시면 좋습니다.
https://walkinpcm.blogspot.kr/2017/06/aws-aws-s3-static-website-hosting.html
링크의 내용에서는 HTTPS를 지원하는 내용까지 있는데,
PWA를 위해서는 웹앱이 HTTPS로 제공되어야 하기 때문에 일반적인 S3 Web Hosting 문서보다 위 문서가 도움이 되리라 생각됩니다.
배포할 파일들을 만들기 위해서 프로젝트 폴더에서 아래 명령으로 배포 파일을 준비합니다.
$ npm run build
빌드를 하고나면 프로젝트 폴더의 루트 경로에 dist 폴더가 생성됩니다.
dist폴더 내부의 모든 파일들을 S3에 업로드 하면됩니다.

2-2. SPA를 위한 AWS CloudFront 추가 설정.

SPA(Single Page Application)는 URL 주소가 변경되더라도 실제 다른 파일을 불러오는게 아니라 화면 요소만 바꿔줍니다.
그런 특징이 AWS S3 + CloudFront 조합에서는 문제점 하나를 야기합니다.
SPA에서 routing으로 URL 주소를 바꾼 상태에서(ex. '/def')
새로 고침을 하면 브라우저는 그 요청을 AWS CloudFront로 보내는데
CloudFront에는 '/def'에 대한 자원이 없어서 S3로 요청하게 되고 S3도 '/def'에 대한 자원은 없어서 결국에는 에러 페이지가 반환됩니다.
이 문제는 사용자 경험도 떨어 뜨릴 뿐 아니라 웹크롤러가 페이지를 읽지 못하는 문제이기도 합니다.
그래서 CloudFront의 에러페이지 설정에서 403, 404 에러가 발생하면 root path로 이동하도록 설정해줍니다.
설정 방법은 아래와 같습니다.
CloudFront에서 설정할 배포를 선택하고 Error Pages탭을 선탁합니다.
그리고 Create Custom Error Response를 선택합니다.

HTTP Error Code는 어떤 에러코드에 대해서 Error 처리를 할지 선택하는 것입니다.
403, 404 2개에 대해서 각각 추가해주셔야합니다.
Customize Error Response를 Yes로 선택하고,
Response Page Path에 /index.html을 기입합니다.
HTTP Response Code는 200: OK로 입력합니다.

에러코드 403, 404 대해서 위와같이 설정을 마치면 아래 처럼 에러 처리 항목 2개가 생겼을겁니다.

2-3. PWA 웹앱 확인

프로젝트 배포 파일들을 AWS S3에 업로드 하고난 뒤에 (HTTPS 까지 지원하게 한 뒤에), PWA 웹앱이라면 모바일 크롬에서 해당 페이지에 접속했을 때 하단에 홈 화면에 설치하겠냐는 배너가 나타나야 정상입니다.
하지만 설치 배너는 유저가 5분 동안 2번 방문해야 나타나는 조건이 있습니다.
개발과정에서는 그러한 조건을 충족시키기가 번거로우므로 웹앱에 브라우저로 접속했을 때 설치배너가 무조건 나타나게 해주는 설정을 합니다.
모바일 크롬에서 아래 주소를 주소창에 입력합니다.
chrome://flags/#bypass-app-banner-engagement-checks
그리고 해당 항목(bypass app banner engagement checks)를 사용으로 변경합니다.
변경하면 크롬을 다시 시작한다고 합니다. 다시 시작하고 다시 웹앱에 접속하면 설치배너가 나타납니다.
물론 설치배너를 통해서 설치 하지 않고, 크롬 메뉴에서 '홈 화면에 추가' 기능을 이용해도 똑같이 PWA 웹앱이 스마트폰에 설치되듯이 추가됩니다.


3. Pre render 플러그인 사용하기

위에서도 언급했듯이 Vue.js PWA 탬플릿은 원형이 Vue.js webpack 탬플릿이기 때문에 Vue.js webpack의 문서를 참고하면됩니다.
그리고 고맙게도 그 문서에는 Pre render에 대한 내용도 있습니다.
Vue.js에서 Pre render를 할 때는 prerender-spa-plugin를 추천합니다. Vue.js에서 공식적으로 추천하고 있습니다.
(문서: https://vuejs-templates.github.io/webpack/prerender.html)
(Github: https://github.com/chrisvfritz/prerender-spa-plugin )
사용방법은 무척 간단합니다.
(1) prerender-spa-plugin 설치
npm i prerender-spa-plugin --save-dev
(2) webpack.conf.js에 플러그인 설정
Vue.js PWA 탬플릿을 사용했다면 /build/webpack.prod.conf.js에 아래 코드들을 추가합니다.
먼저, 아래 require 문을 다른 어떤 require(또는 import)들 보다 상위에 작성합니다.
제일 상위에 위치하지 않으면 페이지가 정상적으로 표시되지 않습니다.
var PrerenderSpaPlugin = require('prerender-spa-plugin')
그리고, 아래 코드를 plugins 배열에 추가합니다.
new PrerenderSpaPlugin(
  // 컴파일된 파일들이 위치하는 폴더를 명시합니다.
  path.join(__dirname, '../dist'),
  // pre render를 할 path를 지정합니다. 콤마로 연결해서 여러 path를 기입할 수 있습니다.
  [ '/', '/abc' ]
)
(3) vue-router 의 mode를 history로 변경
prerender-spa-plugin을 사용하려면 router의 mode가 반드시 history여야합니다.
그러므로 아래와 같이 vue router의 mode를 history로 설정합니다.
const router = new VueRouter({
  mode: 'history',
  routes: [...]
})
Vue.js PWA 탬플릿을 사용한다면, /src/router/index.js에 mode를 추가하면 됩니다.
아래는 탬플릿의 원형에 mode만 추가한 것입니다.
import Vue from 'vue'
import Router from 'vue-router'
import Hello from '@/components/Hello'

Vue.use(Router)

export default new Router({
  mode: 'history',
  routes: [
    {
      path: '/',
      name: 'Hello',
      component: Hello
    }
  ]
})



여기까지 전부 하셨다면 Vue.js + PWA + pre render 조합의 웹앱의 기반을 잡으셨다고 할 수 있습니다.
그리고 그 웹앱을 AWS S3 + CloudFront를 이용해서 웹서버 없이 저렴하고 가용성 높게 배포 하게 되셨습니다.
혹시 참고하실 수 있으실까해서 이 포스팅을 준비하면서 연습해본 프로젝트 소스를 Github에 올려두었습니다.
아래 링크에서 참고하시면 도움이 되리라 생각됩니다.
(Github Repository 링크 : https://github.com/ChanMinPark/vue-pwa-prerender-s3-cloudfront )


이번 포스팅은 여기서 마치겠습니다.
혹여 내용이 틀리거나 수정 보완 해야하는 부분이 있다면 댓글로 남겨주세요.
감사히 받아들이고 수정, 보완하겠습니다.
감사합니다.


참고링크

2017년 8월 30일 수요일

[AWS] Express에서 동작하는 Swagger UI server 만드는 방법(AWS API Gateway, Lambda 이용)

Express에서 동작하는 Swagger UI server 만드는 방법(AWS API Gateway, Lambda 이용)

[How to make Swagger UI server on Express (with AWS API Gateway and Lambda)]

AWS의 API Gateway와 Lambda를 이용하면 간편하게 REST API를 만들 수 있습니다.
(아래 링크에 제가 예전에 정리했던 REST API 포스팅이 있습니다. 하지만, 해당 방법으로는 GET, POST, PUT, DELETE 메서드를 모두 한번에 ANY 메서드로 처리하므로 Swagger로 표현할 수 없습니다. 그러니, 참고만 하시면 좋을 것 같습니다.
https://walkinpcm.blogspot.kr/2017/05/aws-aws-api-gateway-lambda-rest-api.html )
그런데, 만든 API에 대한 정보를 다른 사람에게 알려야할 때 API Gateway에 접속해서 보라고 하기에는 비효율적이고 한눈에 알아보기도 쉽지 않습니다.
즉, API Gateway로 만든 API도 문서화가 필요합니다. API문서화는 여러 방법이 있는데, 본 포스팅에서는 Swagger UI를 이용해서 API Document Web Page를 만들어보겠습니다.

0. 구조


Swagger UI는 다양한 서버에서 동작할 수 있는데, 여기서는 node 환경에서 express 웹서버로 Swagger UI를 구성하겠습니다.
그리고 해당 express 웹서버를 AWS Lambda에서 구동시키고, API Gateway를 이용해서 접속 URL을 획득해서 브라우저에서 접속할 수 있게 구성할 것입니다.
Swagger UI는 json 또는 yaml로 작성된 API 정의 문서를 보기 좋게 GUI로 보여주는데, 본 포스팅에서는 json 파일을 AWS S3에 업로드해서 이용합니다.

1. 필요한 것들

yarn과 Node js 설치는 일반적인 사항이므로 여기서는 다루지 않겠습니다.
또한, API Gateway + Lambda + Express 로 웹 어플리케이션을 Lambda에서 구동하는 방법은 아래 링크를 참고해주시기 바랍니다. 여기서는 코드만 바로 작성하도록 하겠습니다.
( 링크 : https://walkinpcm.blogspot.kr/2017/08/awsaws-lambda-express-react-application.html )

2. 프로젝트 준비

프로젝트를 진행할 폴더 내에서 아래 작업들을 진행합니다.
우선 yarn 프로젝트를 초기화 합니다.
entry point는 lambda.js로 해주세요. 중요한건 아닌데.. 여기서는 index.js는 만들지도 않을 거에요.
yarn init
프로젝트 초기화가 되면 아래 명령으로 필요한 node 패키지들을 설치합니다.
기본적으로 이렇게 3개만 있으면 됩니다.
yarn add express swagger-ui-express aws-serverless-express

3. 소스파일 작성

2개의 파일이 필요합니다.
  • lambada.js
    • AWS Lambda에 프로젝트를 업로드 했을 때, API Gateway를 통해서 들어온 요청을 받아서 express로 전달할 파일입니다.
  • app.js
    • express가 동작하는 파일입니다.
lambda.js의 코드는 AWS Lambda에서 express 어플리케이션을 구동시키기 위해서 사용하는 일반적인 코드입니다.
// lambda.js
'use strict';

const awsServerlessExpress = require('aws-serverless-express');
const app = require('./app');
const server = awsServerlessExpress.createServer(app);

exports.handler = (event, context) => awsServerlessExpress.proxy(server, event, context);
// app.js
'use strict';

const express = require('express');
const app = express();

const awsServerlessExpressMiddleware = require('aws-serverless-express/middleware');

// swagger-ui-express 미들웨어를 불러옵니다.
const swaggerUi = require('swagger-ui-express');

app.use(awsServerlessExpressMiddleware.eventContext());

// 아래 처럼 작성하면 {API Gateway에서 획득한 주소}/api-docs/v1 으로 Swagger UI web page에 접속 할 수 있습니다.
// Swagger Json 파일은 AWS S3에 업로드 하고 해당 객체에 주어지는 URI를 6번째 인자에 복사해 넣습니다.
app.use('/api-docs/v1', swaggerUi.serve, swaggerUi.setup(null, null, null, null, null
    , '{Swagger Json 파일의 S3 주소}'
));

module.exports = app;

여기까지 진행하면 프로젝트 구조가 아래와 같습니다.
Project Folder
├── node_modules
├── app.js
├── lambda.js
├── package.json
└── yarn.lock

4. Swagger Json 파일을 AWS S3에 업로드

Swagger Json 파일을 AWS S3에 업로드 합니다.
혹시, Json 파일을 직접 작성하시기 전에 예제를 이용해서 테스트 해보고 싶으시다면, S3에 올리는 단계를 건너 뛰시고
Json 파일의 URL을 http://petstore.swagger.io/v2/swagger.json로 사용하시면 좋습니다.
해당 json 파일은 swagger-ui-express에서 제공하는 예제입니다.
S3에 Json 파일을 업로드 하면, 업로드 후에 2가지 작업을 해줘야합니다.
  • 첫번째, json 파일의 접근 권한을 public으로 설정해줘야합니다. 요즘엔 파일을 업로드하고 파일의 '개요'를 보면 '퍼블릭으로 설정' 기능이 있어서 간편하게 public으로 설정이 됩니다.
  • 두번째, json 파일을 업로드한 S3 Bucket의 CORS에 header를 추가합니다. Bucket의 '권한'에서 'CORS 구성'을 아래와 같이 작성합니다. 기본 작성된 것에 딱 한줄 추가됩니다.
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>Authorization</AllowedHeader>
    <AllowedHeader>Content-Type</AllowedHeader>      <!-- <<== 이거 한줄 추가합니다. -->
</CORSRule>
</CORSConfiguration>

5. 프로젝트를 AWS Lambda에 올리고 API Gateway와 연결하기

이 단계는 아래 링크를 참고해주세요.
이 단계만 해도 글이 어마어마하게 길어져서 이전의 포스팅을 안내해드립니다.
제 포스팅 뿐만아니라 제 포스팅을 시작으로 관련 키워드들을 많이 검색해서 자료를 보시길 추천드립니다.
( 링크 : https://walkinpcm.blogspot.kr/2017/08/awsaws-lambda-express-react-application.html )
핵심적인 사항은 아래와 같습니다.
  • Lambda Function을 만들 때, 프로젝트 파일들을 zip으로 압축해서 파일로 Lambda Function에 업로드하고 구성 설정에서 Handler를 lambda.handler로 해야합니다.
  • API Gateway는 아래와 같은 구조로 /{proxy+} 만 만들어주시면 됩니다. CORS도 설정해주시구요.
/
    /{proxy+}
        ANY
        OPTIONS

6. Swagger UI Web Page 접속

제대로 작업이 진행되었다면, 아래와 같이 Swagger UI 화면이 나타납니다.
접속 주소는 API Gateway에서 배포한 후에 생성된 URL에 위에서 설정했던 /api-docs/v1을 붙인 것입니다.



이상으로 Swagger UI Web Page를 만드는 방법을 끝마치겠습니다.
혹시 잘 안되거나 잘못 된 부분이 있다면 댓글 남겨주세요. 최대한 빠르게 확인하고 답변 또는 포스팅 수정/보완 하도록 하겠습니다.
감사합니다~

Tip.
아래 링크에서는 Json 또는 Yaml로 된 Swagger 문서를 바로바로 Swagger UI로 볼 수 있습니다. Swagger 문서를 작성할 때 좋습니다.
(링크 : http://editor.swagger.io )
제 경우에는 AWS API Gateway로 API를 작성했기 때문에 API Gateway의 기능인 '내보내기' 기능으로 Swagger 문서를 획득할 수 있어서 위 링크에 복사해두고 조금 더 다듬는 용도로 사용합니다.