Zero to One

React 프로젝트 설정 (CRA + mobx + twin.macro)

지로원 — Mon, 8 Mar 2021 19:16:25 +0900

새로운 프로젝트를 들어가기에 앞서 새로운 라이브러리를 적용해보기로 했다.

MobX는 Redux와 같이 상태관리를 목표로 하는 라이브러리인데 Redux 보다 훨씬 쉽고 코드도 간편하고 단점보다는 장점이 많다고 생각되어 최근에 작업하는 모든 프로젝트를 MobX로 작업하고 있다. 생각같아서는 순수 React Context를 사용하여 상태관리를 하고 싶은데 아직 관리할 수 있는 디테일(?)이 살짝 부족하다고 생각되고 귀찮기도 해서 미루는 중이다.

(MobX 와 Redux 의 차이점은 여기에 자세히 나와있다.)

twin.macro 라는 라이브러리인데 요즘 유행(?)하는 tailwind.css 와 emotion 혹은 styled-component를 합쳐놓은 라이브러리다.

tailwind.css 는 Utility-First 컨셉을 가진 CSS 프레임워크로 bootstrap이랑 어느정도 비슷하다고 생각하면 된다.

emotion 혹은 styled components 는 CSS in JS 라는 개념을 도입한 라이브러리다.

(더 자세한 설명은 직접 찾아보는게 빠르다)

예전에는 리액트 개발을 위해서 css, sass, less 등의 css 파일을 분리해서 작성했고 그게 좋아보였지만

요즘에는 해당 파일들이 굳이 필요없다고 생각되고 괜히 프로젝트에 파일이 많아지면서 프로젝트 자체가 좀 지저분(?) 해보여서

tailwind와 styled-components 를 본격적으로 사용하게 된 것 같다.

styled-components는 사용한지 조금되었고 tailwind는 사용한지 얼마 되지 않았는데 각각의 장단점이 명확했고

두가지를 따로 사용해본 경험은 많았지만 둘 다 동시에 사용해본 경험은 없던 와중에 각각이 필요한 부분이 미묘하게 다른데

둘 다 사용하면 훨씬 더 많은 케이스에 적용할 수 있을 것이라는 생각이 들었고 관련 케이스를 구글링하던 와중에

twin.macro 라는 라이브러리를 발견했다. 처음은 항상 어렵지만 시간이 지나면 잘했다는 생각이 들 수 있게끔 잘 사용해보려고 한다.

그에 앞서 세팅을 정리해보려고 오랜만에 블로그 글을 쓴다!! 정말 오랜만에..... (작성하던 시리즈는 여러개인데 항상 중간에 관뒀었다...ㅠ)

자 이제 드가자~!

Chapter1

npx create-react-app react-twin-boilerplate

명령어를 통해 cra 기반 프로젝트를 생성한다.

프로젝트가 생성되면 우선 mobx 설정부터 해보자,

yarn add mobx mobx-react-lite

mobx-react 가 아닌 mobx-react-lite 을 설치한 이유는 어차피 훅 형태로 개발할거고 데코레이터 없이 사용하기 위해서이다. (Mobx 측에서도 데코레이터는 deprecated 되었다)

mobx를 성공적으로 추가했다면 store를 만들어보자.

간단하게 appStore를 만들고 title을 넣고 변경해보겠다.

Store를 만드는 방법은 여러가지가 있는데 3가지 방법으로 간단하게 만들어보겠다.

1. makeObservable을 이용한 class 형태의 store

// stores/ClassAppStore.js
import { makeObservable, observable, action } from 'mobx'

class ClassAppStore {
  constructor() {
    makeObservable(this, {
      appInfo: observable,
      changeAppTitle: action
    })
  }
  appInfo = {
    title: 'Hello React'
  }

  changeAppTitle = (title) => {
    this.appInfo.title = title
  }
}

const classAppStore = new ClassAppStore()
export default classAppStore

2. makeAutoObservable을 이용한 class 형태의 store

// stores/ClassAppStore2.js
import { makeAutoObservable } from 'mobx'

class ClassAppStore2 {
  constructor() {
    makeAutoObservable(this)
  }

  appInfo = {
    title: 'Hello React'
  }

  changeAppTitle = (title) => {
    this.appInfo.title = title
  }
}

const classAppStore2 = new ClassAppStore2()
export default classAppStore2

1번과 2번을 보면 2번이 훨씬 깔끔하다. 하지만 2번은 class에서 super 혹은 subclassed가 있을 경우 사용할 수 없다.

그러므로 두 방법 모두 알고 있는 것이 좋을 듯?

3. observable 을 이용한 function 형태의 store

// stores/FuncAppStore.js
import { observable } from 'mobx'

const funcAppStore = observable({
  appInfo: {
    title: 'Hello React'
  },
  changeAppTitle(title) {
    this.appInfo.title = title
  }
})

export default funcAppStore

제일 간단하다. 하지만 이 방식은 내부적으로 클론을 하고 observable 상태로 만드는 것이기에 쓸데없는 과정이 하나 더 있다고 보면 된다.

또한 Proxy object 형태로 생성하기 때문에 콘솔을 찍어보면 굉장히 복잡한 형태로 나오는 것을 확인할 수 있다.

MobX 에서 가장 추천하는 방식은 2번이기 때문에 이 방법을 기본으로 사용하되 super 혹은 subclass 가 있을 경우에는 1번 방법을 사용하자! :)

store/index.js

// stores/index.js
import { createContext, useContext } from 'react'
import funcAppStore from 'stores/FuncAppStore'
import classAppStore from 'stores/ClassAppStore'
import classAppStore2 from 'stores/ClassAppStore2'

export const stores = {
  funcAppStore,
  classAppStore,
  classAppStore2
}

export const storesContext = createContext({
  ...stores
})

export const useStores = () => {
  const store = useContext(storesContext)
  if (!store) {
    throw new Error('useStore must be used within a StoreProvider')
  }
  return store
}

각기 다른 페이지 혹은 컴포넌트 들에서 각각에 필요한 store들을 각각 호출해서 사용할 수 있지만

stores라는 변수 한 곳에 모아놓고 그때그때 호출해서 사용할 수 있게 useStore을 만들어준다.

App.js

// src/App.js
import logo from './logo.svg'
import './App.css'
import { useStores } from 'stores'
import { observer } from 'mobx-react-lite'

const App = observer(() => {
  const { classAppStore, classAppStore2 } = useStores()
  const { appInfo: appInfo2, changeAppTitle: changeAppTitle2 } = classAppStore2
  const { appInfo, changeAppTitle } = classAppStore

  return (
    <div className='App'>
      <header className='App-header'>
        <img src={logo} className='App-logo' alt='logo' />
        <p>makeObservable class store</p>
        <div>Title: {appInfo.title}</div>
        <input onChange={(e) => changeAppTitle(e.currentTarget.value)} />
        <p>makeAutoObservable class store</p>
        <div>Title: {appInfo2.title}</div>
        <input onChange={(e) => changeAppTitle2(e.currentTarget.value)} />
      </header>
    </div>
  )
})

export default App

가볍게 App.js 를 바꾸고 테스트를 해보자

초기

다음과 같은 화면이 나오고 input 값을 변경하게 되면,

input 입력

위와 같은 화면으로 바뀐다. 물론 아래도 똑같이 동작한다.

그럼 이제 twin.macro를 세팅해보자!

Chapter2

yarn add twin.macro tailwindcss styled-components

tail.macro, tailwindcss, styled-components를 설치한다.

그 다음 tailwindcss를 사용하기 위해서 twin.macro에서 GlobalStyles을 가져와서 적용해줘야 된다.

// src/GlobalStyles.js
import React from 'react'
import { GlobalStyles } from 'twin.macro'

export default function GlobalStylesComponent() {
  return <GlobalStyles />
}

// src/index.js
import React from 'react'
import ReactDOM from 'react-dom'
import './index.css'
import App from './App'
import reportWebVitals from './reportWebVitals'
import GlobalStyles from './GlobalStyles'

ReactDOM.render(
  <React.StrictMode>
    <GlobalStyles />
    <App />
  </React.StrictMode>,
  document.getElementById('root')
)

// If you want to start measuring performance in your app, pass a function
// to log results (for example: reportWebVitals(console.log))
// or send to an analytics endpoint. Learn more: https://bit.ly/CRA-vitals
reportWebVitals()

굳이 이렇게 불편하게 한번 거쳐서 작업하는 이유는 styled-components 와 관련된 이슈때문이다.

그 후 babel macro 설정까지 해주면 twin.macro를 사용할 수 있다.

// package.json
"babelMacros": {
  "twin": {
    "preset": "styled-components",
    "styled": {
      "import": "default",
      "from": "styled-components"
    },
    "css": {
      "import": "css",
      "from": "styled-components"
    },
  }
},

원래는 @babel-core 와 babel-plugin-macros 라이브러리들을 설치해줘야 되지만 CRA에 기본적으로 포함되어있으니 추가로 설정만 해주면 된다. package.json 안에서 styled-components 에 대한 설정을 마무리하자.

마지막으로 tailwindcss 를 적용해보자!

// src/App.js
import logo from './logo.svg'
import './App.css'
import { useStores } from 'stores'
import { observer } from 'mobx-react-lite'
import tw, { styled } from 'twin.macro'

const Input = tw.input`border hover:border-black px-2 outline-none`
const PurpleInput = tw(Input)`border-purple-500 text-purple-700`
const StyledP = styled.p(({ isPurple }) => [`color: black;`, isPurple && tw`text-purple-700`])
const StyledDiv = styled.div`
  color: black;
  ${({ isPurple }) => isPurple && tw`text-purple-700`}
`

const App = observer(() => {
  const { classAppStore, classAppStore2 } = useStores()
  const { appInfo: appInfo2, changeAppTitle: changeAppTitle2 } = classAppStore2
  const { appInfo, changeAppTitle } = classAppStore

  return (
    <div className='App'>
      <header className='App-header'>
        <img src={logo} className='App-logo' alt='logo' />
        <p>makeObservable class store</p>
        <div tw={'my-2 font-bold'}>Title: {appInfo.title}</div>
        <input css={[tw`rounded-2xl hocus: (outline-none) text-black`]} onChange={(e) => changeAppTitle(e.currentTarget.value)} />
        <StyledP isPurple={false}>makeAutoObservable class store</StyledP>
        <StyledDiv isPurple>Title: {appInfo2.title}</StyledDiv>
        <PurpleInput onChange={(e) => changeAppTitle2(e.currentTarget.value)} />
      </header>
    </div>
  )
})

export default App

결과 화면

위와 같이 여러가지 방법을 사용해서 적용시킬 수 있다. 이밖에도 다양한 방법으로 자신한테 편하게 골라서 쓸 수 있다!!

이로써 tailwindcss와 styled-components가 아주 잘 어우러지게 적용할 수 있었고 이로써 프로젝트에는 css파일이 필요없게 되었고 tailwindcss를 씀으로써 불필요하게 많은 코드도 사용할 필요가 없어졌다....!! 으메이징...

아 그리고 tailwind 설정파일을 정의하여 사전에 더욱 많은 스타일들을 정의할 수 있다. (프로젝트에서 빈번하게 쓰일수록 유용)

1. 처음부터 세팅 (tailwind doc페이지를 보면서 추가해나가면 됨.)

// {project Root}/tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {},
    },
  },
  plugins: [],
}

2. 풀세팅 파일 생성 (엄청난 설정파일이 하나 생성된다.)

npx tailwindcss-cli@latest init --full

그리고 아까 package.json 에 설정한 babelMacros 에 명시해주면 된다!

// 최종 package.json
{
  "name": "cra-twin-boilerplate",
  "version": "0.1.0",
  "private": true,
  "author": "zer01ne",
  "description": "cra-twin-boilerplate",
  "dependencies": {
    "@testing-library/jest-dom": "^5.11.4",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10",
    "mobx": "^6.1.8",
    "mobx-react-lite": "^3.2.0",
    "react": "^17.0.1",
    "react-dom": "^17.0.1",
    "react-scripts": "4.0.2",
    "styled-components": "^5.2.1",
    "tailwindcss": "^2.0.3",
    "twin.macro": "^2.3.0",
    "web-vitals": "^1.0.1"
  },
  "devDependencies": {
    "prettier": "^2.2.1"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "prettier": "prettier --write --config ./.prettierrc 'src/**/*.{js,jsx}'"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "babelMacros": {
    "twin": {
      "preset": "styled-components",
      "styled": {
        "import": "default",
        "from": "styled-components"
      },
      "css": {
        "import": "css",
        "from": "styled-components"
      }
    }
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

Fin.

아참, twin.macro가 좋은 이유는 정말 여러개가 있는데 이중에 하나는 잘못 썼으면 뭐가 틀렸는지, 어떤 옵션들이 있는지 보여준다. (그냥 tailwindcss만 쓰면 가끔 에러가 발생했을 때 찾기 어려울 수 있다)

이 외에도 많은 기능이 더 있고 현재도 활발하게 개발중이니 땡큐! 하면서 잘 사용해보자!

twin.macro 장점

정말 오랜만에 블로그 글을 쓰니까 뿌듯하긴한데 넘나 힘들다리...

AWS 를 사용한 서버리스 아키텍쳐 적용기(삽질기) (7) - IAM role 세팅

지로원 — Tue, 11 Jun 2019 12:33:30 +0900

저번 글에서 빠르게 만들면서 AdministratorAccess 정책을 이용해서 권한을 설정해줬습니다.

하지만 AdministratorAccess 는 모든 권한에 접근할 수 있기 때문에 혹시나 잘못되면 과금등에도 손댈 수 있기 때문에

role 변경이 필요해보입니다. 그럼 어떤 권한을 부여해야되는지 알아보도록 하겠습니다.

0. 기존 권한 확인 및 사용된 권한 확인.

AWS에서 IAM Management Console 로 이동해서 왼쪽 메뉴 중에서 '사용자' 를 클릭하면

정의된 사용자를 확인할 수 있습니다.

serverless 사용자

해당 사용자를 클릭하면 아래와 같이 AdministratorAccess 권한이 설정된 것을 확인할 수 있습니다.

정확하게 어떤 서비스들이 사용되었는지 확인하기 위에 엑세스 관리자를 클릭해 확인해보겠습니다.

serverless-demo 권한

다음과 같은 결과를 확인할 수 있습니다.

7개의 서비스를 이용했을 때 AdministratorAccess 권한이 사용된 것을 확인할 수 있습니다.

security token, s3, cloudwatch logs, cloudformation, api gw, lambda, IAM 서비스들이 사용됐네요.

그럼 이 서비스에 해당하는 권한들만 따로 모아서 부여해주면 정상적으로 작동하겠지요 ??

사용된 서비스들

1. 새로운 정책 생성.

위의 서비스들에 대한 권한을 새로 생성해보겠습니다.

좌측에 정책 메뉴를 클릭해서 정책 생성을 클릭해줍니다.

정책생성1

정책 생성 버튼을 누르면 다음과 같은 화면을 확인하실 수 있습니다.

권한 추가 버튼을 눌러 하나씩 추가해줍시다. 그 후 작업은 모든 작업을 체크해주고 리소스도 모두 선택을 체크해 모든 유형의 리소스를 통과시키도록 해줍니다.

S3 권한

아래와 같이 하나씩 해주기는 귀찮고 복잡하니깐 JSON 을 통해 한번에 정의해줍니다.

일단 이렇게 해놓은 뒤 정책을 적용하고 sls deploy를 해보겠습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudformation:*",
        "s3:*",
        "logs:*",
        "iam:*",
        "apigateway:*",
        "lambda:*"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

정책 검토 버튼을 클릭해줍니다.

이름은 적당히 full_serverless_role 로 명명해줍니다.

정책을 생성해줍니다.

정책 검토

아래와 같은 메시지가 출력된다면 정책이 제대로 생성된 것입니다.

success msg

2. 정책 적용

다시 사용자로 돌아가 serverless-demo 사용자를 클릭해주고 권한 탭에서 권한 추가 버튼을 눌러줍니다.

사용자 권한

아래와 같이 방금 생성한 정책을 체크하고 다음으로 넘어가서 권한을 추가해줍니다.

serverless-demo 권한추가

그 후 AdministratorAccess 정책을 삭제해주면 아래와 같은 화면이 됩니다.

여기까지 끝났으면 이제 제대로 돌아가는지 확인해보겠습니다.

full serverless role

3. 배포

sls deploy -v 명령어를 통해 배포해주겠습니다.

문제없이 배포 완료됩니다. (문제 발생시 다시 차례대로 설정을 진행해주세요.)

curl 명령어를 통해 배포된 api endpoint에 테스트를 해봐도 잘 동작하는 것을 확인할 수 있습니다!!!

배포

cloudwatch에 로그도 제대로 쌓입니다 :)

지금까지 IAM role 변경을 해봤습니다.

4. 세부 설정 및 응용

이제 조금 더 설정을 세부적으로 변경해보겠습니다.

앞서 한 IAM role setting은 serverless framework를 사용할 때 기본적으로 사용하는 권한 이외에도 모든 권한을 포함시켰습니다.

조금 더 필요한 권한 위주로만 세팅하고 region, account, service 도 제한을 두는 role을 설정해주겠습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudformation:Describe*",
        "cloudformation:List*",
        "cloudformation:Get*",
        "cloudformation:CreateStack",
        "cloudformation:UpdateStack",
        "cloudformation:DeleteStack"
      ],
      "Resource": "arn:aws:cloudformation:<region>:<account_no>:stack/<service_name>*/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "cloudformation:ValidateTemplate"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:DeleteBucket",
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": [
        "arn:aws:s3:::*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:*"
      ],
      "Resource": [
        "arn:aws:s3:::*/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogGroups"
      ],
      "Resource": "arn:aws:logs:<region>:<account_no>:log-group::log-stream:*"
    },
    {
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:DeleteLogGroup",
        "logs:DeleteLogStream",
        "logs:DescribeLogStreams",
        "logs:FilterLogEvents"
      ],
      "Resource": "arn:aws:logs:<region>:<account_no>:log-group:/aws/lambda/<service_name>*:log-stream:*",
      "Effect": "Allow"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:GetRole",
        "iam:PassRole",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:DetachRolePolicy",
        "iam:PutRolePolicy",
        "iam:AttachRolePolicy",
        "iam:DeleteRolePolicy"
      ],
      "Resource": [
        "arn:aws:iam::<account_no>:role/<service_name>*-lambdaRole"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "apigateway:GET",
        "apigateway:POST",
        "apigateway:PUT",
        "apigateway:DELETE"
      ],
      "Resource": [
        "arn:aws:apigateway:<region>::/restapis"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "apigateway:GET",
        "apigateway:POST",
        "apigateway:PUT",
        "apigateway:DELETE"
      ],
      "Resource": [
        "arn:aws:apigateway:<region>::/restapis/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "lambda:GetFunction",
        "lambda:CreateFunction",
        "lambda:DeleteFunction",
        "lambda:UpdateFunctionConfiguration",
        "lambda:UpdateFunctionCode",
        "lambda:ListVersionsByFunction",
        "lambda:PublishVersion",
        "lambda:CreateAlias",
        "lambda:DeleteAlias",
        "lambda:UpdateAlias",
        "lambda:GetFunctionConfiguration",
        "lambda:AddPermission",
        "lambda:RemovePermission",
        "lambda:InvokeFunction"
      ],
      "Resource": [
        "arn:aws:lambda:*:<account_no>:function:<service_name>*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "events:Put*",
        "events:Remove*",
        "events:Delete*",
        "events:Describe*"
      ],
      "Resource": "arn:aws:events::<account_no>:rule/<service_name>*"
    }
  ]
}

에러가 발생한다...

내용을 읽어보니 apigateway:PATCH 권한이 없어서 생기는 문제입니다.

위로 올라가서 apigateway 권한 Action 들이 쭉 있는곳에 추가해주면 문제해결!

(두군데 다 추가해주셔야 됩니다.)

deploy error 발생

최종적으로 배포하면 정상적으로 작동합니다!

IAM 에 대해선 다음에 기회가 되면 더 자세히 다루겠습니다. (워낙 양도 많고 들어갈수록 어렵습니다..)

+ 추가.. 나중에 production 모드로 추가배포했는데 배포 오류가 떠서 보니깐 s3 bucket 오류였습니다.

정책에서 "s3:Put*" 한줄 추가해주면 잘 작동합니다.

* 참고

https://www.youtube.com/watch?v=mQqVarM5mOY

https://serverless.com/blog/abcs-of-iam-permissions/

https://github.com/serverless/serverless/issues/1439

AWS 를 사용한 서버리스 아키텍쳐 적용기(삽질기) (6) - serverless 프레임워크 2

지로원 — Wed, 22 May 2019 11:27:09 +0900

저번 글에서 서버리스 프레임워크를 간단하게 사용해봤습니다.

이번 글에선 좀 더 많은 기능을 테스트해보겠습니다.

0. 새로운 프로젝트 생성

sls create -t aws-nodejs -p <프로젝트명>

명령어를 통해 다시 프로젝트를 생성하겠습니다.

생성한 다음 해당 폴더에 들어가서

yarn init -y

명령어를 통해 package.json을 만들어줍니다.

또한 이번에는 좀 더 편하게 사용할 수 있도록 serverless-http, serverless-webpack 등을 사용할 예정입니다.

* serverless-http? 기존 node 기반 백엔드 서버 구축에 사용되는 express, koa 등의 프레임워크로 람다 함수를 wrapping 해서 사용할 수 있게 만들어주는 일종의 툴.

* serverless-webpack? serverless용 웹팩이다. 웹팩은 검색해보면 관련된 좋은 설명들이 너무 많다. 많은 번들러 중에 굳이 왜 웹팩을 쓰느냐? 제일 좋아서 쓴다.

* serverless-offline? serverless는 코드를 수정하고 테스트를 해보고 싶으면 배포를 해야 테스트를 해볼 수 있다. 배포는 s3를 통해 배포되므로 곧 비용과 직결되는 문제이다. serverless-offline을 사용하면 로컬에서도 테스트를 해볼 수 있다!!

1. 본격적인 준비.

1-1. serverless.yml

우선 serverless.yml 파일을 수정해줘야 합니다.

serverless-http는 따로 설정 안 해주시고 npm 또는 yarn을 통해 install만 해주시면 됩니다. serverless-webpack과 serverless-offline은 yml에 설정해줘야 사용할 수 있습니다.

service: sls-assistant # 서비스 명.

plugins:
  - serverless-webpack # webpack이 먼저 와야됨.
  - serverless-offline

custom:
  webpack: # serverless-webpack 관련 설정
    webpackConfig: 'webpack.config.js'
    includeModules: true
    packager: 'yarn' # npm을 사용한다면, npm 으로 설정.

provider:
  name: aws
  runtime: nodejs8.10
  stage: dev
  region: ap-northeast-2 # 한국으로 설정.

functions:
  app:
    handler: src/app.handler
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'

1-2. webpack.config.js

명시된 것과 같이 webpack.config.js 파일을 통해 webpack 설정을 해줘야 합니다.

webpack.config.js 파일은 다음과 같이 작성해주시면 되겠습니다.

const path = require('path');
const serverlessWebpack = require('serverless-webpack');
const nodeExternals = require('webpack-node-externals');

module.exports = {
  // entry를 따로 설정하지 않아도 됨
  entry: serverlessWebpack.lib.entries,
  target: 'node',
  mode: serverlessWebpack.lib.webpack.isLocal ? 'development' : 'production',
  // webpack의 critical warning 메시지를 피하기 위한 용도
  externals: [nodeExternals()],
  resolve: {
    modules: [path.resolve('./src'), 'node_modules'] // src 디렉토리 내부에서 absolute import를 사용하기 위한 용도
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader'
          }
        ]
      }
    ]
  },
  output: {
    libraryTarget: 'commonjs',
    path: path.join(__dirname, '.webpack'),
    filename: '[name].js'
  }
};

코드를 보면 loader는 바벨을 쓰는 것을 확인할 수 있습니다.

따라서 install을 통해 바벨도 설치해주고 여러 가지 설치를 해줘야 됩니다.

1-3. package.json

그럼 어떤 것들이 설치되어야 하는지 package.json 파일을 잠시 보겠습니다.

{
  "name": "sls-assistant",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "axios": "^0.18.0",
    "express": "^4.16.4",
    "serverless-http": "^2.0.1"
  },
  "devDependencies": {
    "@babel/core": "^7.4.4",
    "@babel/preset-env": "^7.4.4",
    "babel-loader": "^8.0.6",
    "serverless-offline": "^4.10.0",
    "serverless-webpack": "^5.3.0",
    "webpack": "^4.31.0",
    "webpack-node-externals": "^1.7.2"
  }
}

바벨 관련된 패키지, serverless-offline, serverless-webpack 등등은 전부 개발할 때 빌드용으로 사용할 것이므로

devDependencies에 추가해주시면 되겠습니다.

dependencies 에는 저 같은 경우 람다에서 post, get 등의 http request를 보낼 것이므로 axios, body-parser, express 등을 사용합니다.

모두 yarn 또는 npm을 이용해서 옵션을 주고 install 해주시면 됩니다.

2. 구조

위에 webpack.config.js 파일에서 './src' 경로를 절대 경로로 설정해주었습니다.

그럼 폴더 구조가 어떻게 되어있는지 간단하게 보겠습니다.

디렉토리 구조

순서대로 보면

.serverless -> 어느 시점에 생긴 건지 정확히 확인하지 못했습니다...ㅜㅜ 대충 유추해보면 deploy를 할 때 생기는 폴더 같습니다. cloudformation 관련 설정 파일들과 람다에 올라가는 압축파일이 있습니다.

.webpack -> 위의 webpack.config.js 파일의 output을 보면 path가 .webpack 으로 설정해놓은 것을 볼 수 있습니다. 프로젝트가 빌드될 때 생성된 빌드 output 폴더입니다.

node_modules -> 패스

src -> 실질적으로 모든 코드가 있는 폴더입니다. 저 같은 경우 components 폴더 안에 express로 전달되는 각 경로에 따라 폴더를 따로 생성해서 알아보기 쉽도록 하였습니다.

3. 코드 실행 흐름

3-1. app.js

단순합니다. server.js를 가져와서 handler로 export 해줍니다.

import Server from './server';

const server = new Server();

// serverless-http 의 entry point
export const { handler } = server;

이를 통해 serverless.yml 파일에서 handler: src/app.handler로 설정해놓은 entry point를 server.js로 연결시킵니다.

3-2. server.js

사실상 모든 코드가 시작되는 부분입니다.

간단하게 구성해봤습니다.

import serverless from 'serverless-http';
import express from 'express';
import axios from 'axios';
import beginning from 'components/apart-evaluation/beginning';

export default class Server {
  constructor() {
    this.app = express();
    // this.app.use(express.urlencoded({extended: false}));
    this.app.use(express.json());

    this.app.get('/', (req, res) => { //get
      res.json({ hello: "world"});
    });

    this.app.post('/apart_evaluation/beginning', (req, res) => {
      beginning(req.body).then((data) => {
        console.log(JSON.stringify(data));
        res.json(data);
      });
    });
  }

  get handler() {
    // serverless-http 관련 설정
    return serverless(this.app);
  }
}

평범한 node의 express 프레임워크입니다.

beginning이라는 함수를 components 폴더 안의 어딘가에서 가져와서 사용합니다. 이때, Promise를 이용해서 결과 값을 전송해줍니다.

http request에는 항상 필수적으로 동기/비동기 제어가 중요합니다. (계속 써도 계속 헷갈리긴 하는데...ㅋㅋㅋㅋㅋ)

당연히 beginning 함수의 리턴에서 return new Promise 형태로 값을 리턴해줘야 되겠죠?

3-3. beginning.js

import axios from 'axios';

const Beginning = async (data) => {
  // console.log(data);
  let blockId = data.userRequest.block.id;
  let botUserId = data.userRequest.user.id;
  let plusFriendUserId = data.userRequest.user.properties.plusfriendUserKey;
  let key, msg, label;
  let webUrl = "http://kakao.chatbot/api/test/";
  let returnView;

  await axios.get("http://kakao.chatbot/api/test",{
    data : {
      block_id: blockId,
      user_id: botUserId,
      plus_friend_id: blockId
    }
  }).then(response => {
    if(response.data.status == "success") {
     ...
      returnView = {
        "version": "2.0",
        "template": {
         ...
        }
      };
    } else {
      msg = response.data.msg;
      returnView = {
        "version": "2.0",
        "template": {
          "outputs": [
            {
              "simpleText": {
                "text": msg
              }
            }
          ]
        }
      };
    }
  }).catch(error => {
    console.log(error);
    returnView = {
      "version": "2.0",
      "template": {
        "outputs": [
          {
            "simpleText": {
              "text": "error"
            }
          }
        ]
      }
    };
  });
  // promise returnView
  return new Promise(resolve => {
    console.log(returnView);
    resolve(returnView);
  });
};

export default Beginning;

저 같은 경우에는 카카오 챗봇에 연결했기 때문에 챗봇에 맞는 템플릿을 연결해줬습니다.

async & await 그리고 promise를 사용해서 비동기의 늪에서 헤어 나올 수 있었습니다ㅠㅠ (맨날 해도 맨날 헷갈리는 게 함정)

마지막 라인 쪽을 보시면 return new Promise 구문을 이용해 위의 axios를 이용한 api콜이 끝나면 그 결과를 리턴해줍니다.

리턴 받은 결과값을 위의 server.js 에서 최종적으로 처리합니다.

사실 server.js에서 다 처리해도 됩니다. 하지만 api콜이 여러 개 붙을수록 server.js 코드가 복잡해지겠죵?

그렇기 때문에 굳이 폴더를 나눠서 처리했습니다. (저는 하나의 함수는 하나의 기능만 수행하는 것이 모든 면에서 좋다고 생각합니다.)

추후에 api endpoint url 같은 경우도 따로 빼고 중요한 부분은 람다 함수의 환경변수로 모두 빼서 보안도 챙기고 나중에 수정할 때 편하게 수정할 수 있습니다.

4. 실행

그럼 이제 대충 코드가 완성되었으니 배포해야겠죠?

아 배포하기 전에

sls offline start

명령어를 통해 테스트를 해보고 에러처리를 한 뒤에 배포해줍시다!

sls deploy

명령어를 치게 되면 자동으로 파일들이 빌드되고 aws에 배포됩니다.

배포한 뒤 테스트를 해보면 성공적으로 돌아가는 것을 확인할 수 있습니다.

5. 결론

serverless 프레임워크가 정말진짜레알완전 편리한 것을 느낄 수 있었습니다.

기존의 정말 복잡한 여러 가지 세팅들을 할 필요 없이 바로 뚝딱뚝딱 간단하게 프로젝트에 적용할 수 있습니다.

물론 조금 더 세밀하게 구축하고 보안적인 부분도 신경 쓰려면 세팅을 조금씩 바꿔줘야 됩니다.

다음 글은 이렇게 만든 람다 함수를 실제로 적용하려면 어떠한 추가 작업들을 거쳐야 하는지 알아보겠습니다.

(공부를 많이 해야 될 것 같아서 오래 걸릴 듯....? 그냥 넘어갈수도?ㅋㅋㅋ)

p.s 카카오 챗봇 관련해서는 나중에 기회가 되면 포스팅...?

AWS 를 사용한 서버리스 아키텍쳐 적용기(삽질기) (5) - serverless 프레임워크 1

지로원 — Tue, 14 May 2019 18:03:31 +0900

0. serverless framework란?

serverless framework는 서버없는 아키텍쳐를 배치하고 운영하기 위한 프레임워크 입니다.

-> serverless architecture를 쉽게 설계, 운영하도록 도와주는 툴킷.

1. serverless 설치

공식 홈페이지인 https://serverless.com/ 에 들어가면 아래와 같은 메인 화면이 보입니다.

오른쪽에 커맨드를 보고 따라해보겠습니다!

그전에! npm을 사용하기 때문에 기본적으로 nodejs와 npm이 설치되어 있어야 합니다.

제 기준으로 nodejs는 현재 10.15.0, npm은 6.8.0 입니다.

람다에서 요구하는 노드 버전이 8.10 이므로 최소 8.10 이상으로 설치해야 되겠죠 ?!

준비를 끝낸 뒤에 보이는 것과 같이

npm i -g serverless

명령을 커맨드라인에 입력해줍니다.

serverless 공홈 메인

그 후 바로 밑에 명령어를 타이핑해줘도 되지만 aws-nodejs 라는 다른 템플릿을 사용하도록 하겠습니다.

2. aws-nodejs 템플릿 생성

잠깐 서버리스에서 제공하는 템플릿들이 무엇이 있는지 알아보도록 하겠습니다!

아래와 같은 명령어를 입력하면 어떤 템플릿들이 제공되는지 확인할 수 있습니다.

추가 옵션들도 확인 가능합니다.

serverless create --help

sls create -t aws-nodejs -p sls-sample

sls = serverless, -t = --template 의 줄임말 입니다. aws-nodejs 는 서버리스에서 제공하는 템플릿 중에 하나입니다.

-p sls-sample 명령어는 sls-sample 폴더 안에 해당 템플릿으로 생성하겠다는 뜻입니다.

명령어를 실행하면 다음과 같은 결과를 보실 수 있습니다.

create 입력 후

템플릿 생성.... 완료!

3. 배포

이제

sls deploy

명령어를 실행하면 아래와 같은 결과가 뜹니다.. Error ?!

aws credential 관련 에러내요.

IAM 을 통해 키를 발급받아야 됩니다.

deploy 에러

일단 에러를 해결하기 전에 템플릿으로 생성한 함수를 실행시켜 보겠습니다.

sls invoke local --function hello

명령어 실행 시

로컬에서 함수 실행

와 같은 결과화면을 볼 수 있습니다.

잘되네요 :)

다시 에러로 돌아가서...

공식 홈페이지를 통해 에러를 해결하겠습니다.

https://serverless.com/framework/docs/providers/aws/guide/credentials/ 에서 어떻게 해야되는지 자세하게 나와 있습니다.

그런데 영어를 읽으니까 토할꺼 같다고요??

https://www.youtube.com/watch?v=KngM5bfpttA 에서 영상보시고 편하게 하세요 :)

아무튼 알려주는 대로 따라하면 iam을 통해 자격증명을 생성하고 키를 발급받을 수 있습니다.

그럼 아래와 같이 명령어를 통해 credetial 등록을 해줍니다.

sls config credentials --provider aws --key <키> --secret <비밀키>

*** 만약 이전에 등록했던 aws credential 이 있다면 기본적으로 '~/.aws/credentials' 파일에 [default] 값으로 세팅이 되어있어 새로운 credential 등록이 되지 않습니다.

이 때, 2가지 방법이 있습니다. 덮어 씌우거나 다른 이름으로 credential 생성을 해주거나.

1번의 경우 -o 옵션을 붙여서 위의 명령어를 실행시켜주면 덮어씌워줍니다.

2번의 경우 직접 credentials 파일을 수정해서 아래와 같이 [default] 밑에 넣어주시면 됩니다. 그 후, sls deploy --aws-profile othercredential 옵션을 줘서 배포를 하시면 됩니다!! :)

[othercredential] 
aws_access_key_id = <키>
aws_secret_access_key = <비밀키>

그리고 다시 sls deploy... 를 하기 전에!! region하고 rest api 세팅을 해줘야 합니다. (안그러면 default region인 버지니아에 생성됩니다.)

아까 템플릿 생성할 때 생성된 serverless.yml 파일을 수정해줍니다.

저는 서울인 ap-northeast-2 로 설정해 줬습니다.

stage는 개발 버전으로 만들지, 배포 버전으로 만들지 설정해주는 부분입니다. (dev, prod)

events - http 에서 정말 쉽게 API Gateway를 통해 rest api를 만들 수 있습니다.

service: sls-sample # NOTE: update this with your service name

provider:
  name: aws
  runtime: nodejs8.10
  stage: dev
  region: ap-northeast-2

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get

위의 과정을 다 끝낸 후 다시 한번

sls deploy

를 입력합니다.

deploy 결과

짜잔!! 자동으로 모든게 생성됐습니다.

API Gateway, S3, lambda, cloudformation .... 이렇게 쉽게?!

직접하려면 이것저것 세팅하고 만들어주기 정말 힘듭니다ㅠㅜ (직접 해봐서 앎.. 프레임워크 짱!)

화면에 보이는 엔드포인트로 콜을 날려서 테스트 해보겠습니다.

4. 테스트

curl  https://jyw45r6pjk.execute-api.ap-northeast-2.amazonaws.com/dev/hello

아래와 같은 리턴 값이 돌아옵니다.

api call GET 실행 결과

끝... 너무 쉽네요.

이제 본격적으로 사용해보기 위해 다음 글에선 POST method와 기회가 되면 db 까지 연결해 보겠습니다.

AWS 를 사용한 서버리스 아키텍쳐 적용기(삽질기) (3) - API Gateway 1

지로원 — Thu, 9 May 2019 16:52:03 +0900

0. API Gateway 란?

이름에 보이는 것 처럼 API 와 관련이 있다는 것을 유추할 수 있숩니다.

AWS에서 정의되어 있는 것을 살펴보면, 'Amazon API Gateway는 규모와 상관없이 REST 및 WebSocket API를 생성, 게시, 유지하고 모니터링 및 보안하기 위한 AWS 서비스입니다.' 라고 명시되어 있숩니다.

쉽게 말해, API를 조금 더 쉽게 작성하고 사용할 수 있게 해주는 API 호스팅 서비스라고 해보겠습니다.

API gateway architecture

위는 api gateway의 아키텍쳐 입니다.

왼쪽에서부터 enduser가 사용하는 client App, API Gateway, AWS의 각종 서비스들로 구분됩니다.

AWS 클라우드 기반 어플리케이션을 구축할 때의 편리성, 보안성 등을 쉽게 얻을 수 있습니다.

API Gateway 기능

Amazon API Gateway는 다음과 같은 기능을 제공합니다.

상태 저장(WebSocket) 및 상태 비저장(REST) API에 대한 지원.
REST 및 WebSocket API에 대한 액세스를 제어하기 위한 다양한 옵션.
API를 게시하기 위한 개발자 포털.
변경 사항을 안전하게 롤아웃하기 위한 Canary 릴리스 배포.
API 사용 및 API 변경에 대한 CloudTrail 로깅 및 모니터링.
경보 설정 기능을 포함한 CloudWatch 액세스 로깅 및 실행 로깅. 자세한 내용은 Amazon CloudWatch로 API execution 모니터링 및 CloudWatch로 WebSocket API 실행 모니터링 단원을 참조하십시오.
AWS CloudFormation 템플릿을 사용하여 API 생성을 활성화할 수 있는 기능. 자세한 내용은 Amazon API Gateway 리소스 유형 참조 정보 및 Amazon API Gateway V2 리소스 유형 참조 정보.를 참조하십시오.
사용자 지정 도메인 이름 지원.
일반적인 웹 익스플로잇으로부터 API를 보호하기 위해 AWS WAF와 통합.
성능 지연 시간 파악 및 학습을 위해 AWS X-Ray와 통합.

API Gateway 기능의 전체 목록은 문서 이력 단원을 참조하십시오.

일단 이정도에서 각설하고.... 실습을 해봅시다!

1. 람다에서 트리거 추가

앞에서 생성했던 람다함수에서 Designer 메뉴 좌측에 트리거 추가라고 있고 이를 통해 트리거를 간단하게 추가할 수 있습니다.

다양한 트리거를 추가할 수 있지만 API gateway 트리거를 추가해보겠습니다.

클릭하게 되면 우측과 같이 'lambdaTest' 함수 밑에 'API 게이트웨이' 라는 항목이 생깁니다.

트리거 추가

클릭하게 되면 밑의 화면과 같이 트리거 구성 설정을 할 수 있습니다.

맨 위의 설정부터 차례대로 보면, 우선 API는 기존에 생성된 API가 없으므로 새 API 생성을 그대로 두면 됩니다.

보안 같은 경우 'IAM','API 키 설정', '열기' 가 있는데 저는 API 키 설정을 선택하겠습니다.

'IAM 설정'을 하실 경우 추가적으로 IAM 구성을 해줘야 합니다. '열기'의 경우 말그대로 열어놓는 것인데 내부적으로만 사용되는 것이 아닌 이상 당연히 안쓰는게 좋습니다. 왜? 그냥 열어놨다가 제한없이 사용되면 돈이 줄줄....

그 후 추가 세팅 탭에서 API 이름과 배포 단계 이름을 설정하면 됩니당.

전 건드릴게 없어서 그냥 다 냅뒀습니다. 나머지는 읽어보면 다 아니깐 건너뛰겠습니다.

트리거 구성 설정

구성을 완료하면 새로운 트리거가 생성된 것을 확인할 수 있습니다.

맨 위에 저장을 눌러줘야 저장됩니다.

완료되면 아래와 같이 api 엔드포인트와 키가 발급됩니다

트리거 정보

2. REST 구성

lambdaTest-API를 클릭하면 api 세팅화면으로 들어가게 됩니다.

최초에 보이는 것은 ANY라는 메소드가 있습니다.

API gateway 설정

리소스에서 /lambdaTest를 클릭한 뒤 작업에서 메서드 생성을 눌러 POST 메서드를 만들어 줍니다.

lambda 함수 입력부분에는 앞에서 만든 lambdaTest 를 쓰면 됩니다.

POST 메서드 생성

3. lambda 함수 변형 및 테스트

아래와 같이 람다함수를 조금 수정해 주겠습니다.

람다 함수 수정

게이트웨이에서 생성한 POST 메서드를 클릭하면 클라이언트에서 테스트를 해볼 수 있습니다.

요청 본문에 아래와 같이 key값과 value 값을 설정해주고 테스트 버튼을 돌린 결과,

우측에 상태 200으로 성공한 것을 확인할 수 있습니다. response 전체가 리턴되기 때문에 응답 본문에 response가 리턴된 것을 확인할 수 있습니다.

4. 배포

본격적으로 사용하기 위해 배포를 해주겠습니다.

배포에 앞서 아무나 접근해서 api콜을 마구잡이로 날리면 안되기 때문에 설정을 변경해줘야 합니다.

메서드 요청을 클릭한 뒤 보이는 설정에서 'API 키가 필요함' 을 false에서 true 로 변경해줍니다.

그 후 작업 메뉴에서 API 배포를 클릭합니다.

설정 변경

API 키 설정 변경 뒤 배포

배포를 클릭하면 아래와 같이 확인 창이 하나 뜨게 되는데 배포 스테이지를 설정할 수 있습니다.

배포 버전을 관리할 때 변경해서 사용하면 됩니다. 여기선 default 그대로 배포하겠습니다.

API 배포

기존에 post 요청을 보냈을 때와 배포를 완료한 후 post 요청을 보냈을 경우에 다른 응답이 오게 됩니다.

'Forbidden' 이라는 응답이 오는 것을 확인할 수 있습니다.

기존

설정 변경 후

5. 최종 수정 후 테스트

그 후 사용량 계획에 API키 탭에서 API 키를 추가하면 됩니다.

배포 스테이지까지 연결되면 끝!

사용량계획 메뉴

모든 설정을 끝내준 뒤에 Header에 x-api-key라는 이름에 API 키 값을 넣어서 요청하면

정상적으로 작동하는 것을 확인할 수 있다.

x-api-key 추가

이 API key는 헤더에 넣고 요청하면 노출되기 때문에 숨기는 것이 좋습니다.

API gateway에서 권한 부여자를 만들어서 이 부분을 제어할 수 있습니다.

cognito 또는 lambda를 통해 제어할 수 있다고 나와있는데

이 부분은 다음에 알아보도록 하겠슴다.

AWS 를 사용한 서버리스 아키텍쳐 적용기(삽질기) (2) - 람다함수 2

지로원 — Tue, 7 May 2019 11:54:04 +0900

1. 환경변수와 태그

람다에서는 환경 변수와 태그를 구성할 수 있습니다.

환경변수는 말 그대로 환경변수 입니다. 코드와 상관없이 함수 코드와 라이브러리에 설정을 동적으로 전달할 수 있게끔 만들어줍니다.

Node의 process.env 와 같다고 보면 됩니다. 예를 들어 api endpoint url, api 키 값 등 변할 수 있는 것들을 넣어서 사용할 수 있습니다.

(도커가 '짜잔!' 하고 뜬 이유? 어디서든 환경 설정할 필요없이 도커 이미지만 있으면 바로 사용할 수 있기 때문입니다.)

환경변수는 그러한 기능을 한다고 보면 됩니다. API 바꾸고 키 바꾸고 로컬 저장 장소등을 바꾸려고 할 때마다 코드를 수정하려면 너~무 귀찮고 시간 낭비가 생깁니다. 하지만 환경변수는 그때그때 값만 바꿔주면 된다는 점에서 훨씬 편리합니다.

또한 암호화 기능도 있어서 API 키를 숨기거나 할 수 있지만 여기서는 다루지 않겠습니다.

태그는 간단하게 해시태그라고 생각해도 무방합니다. 람다 함수를 많이 사용할 때 재활용하기 유용합니다.

예를 들어, 결제 모듈을 여기저기 달아서 사용하고 싶다면 결제 관련된 함수들에 동일한 태그를 지정해놓으면

검색해서 쉽게 가져다 쓸 수 있습니다.

환경 변수와 태그

위와 같이 사용하면 된다.

또한 아래와 같이 기본적으로 제공되는 환경 변수도 있어서 잘 사용하면 편리할 것 같습니다.

사전정의된 환경 변수

2. 실행 역할과 기본 설정

실행 역할에서는 함수에 대한 권한을 정의할 수 있습니다. 아직 여기를 건드리긴 너무 어설프기 때문에 패스..

기본 설정같은 경우는 메모리와 제한 시간 설정해줄 수 있습니다. 당연하지만 메모리가 많이 필요한 작업을 함수에서 처리하면 그에 맞게 메모리를 설정해줘야 됩니다. 제한 시간은 사용자가 함수에 접근할 수 있는 시간.

람다 함수의 경우 사용하는 만큼 과금이 되는 방식이기 때문에 두 요소 모두 과금과 직접적인 관련이 있습니다.

적절히 잘 설계하고 사용해야 된다는 말!!

실행 역할과 기본 설정

3. 나머지 (네트워크, 디버깅, 동시성 등)

네트워크의 경우 VPC를 설정해줄 수 있습니다. 접근을 제한한 DB등의 AWS 서비스가 있다면 VPC를 통해 접근해서 처리할 수 있습니다.

디버깅 및 오류 처리는 그냥 설명 그대로... 별거없음.

동시성은 람다함수에 동시에 접근할 수 있는 횟수입니다. 설정된 1000번 보다 많은 회수의 접근이 필요할 때는 (ex. 특수 이벤트) 그냥 늘려주면 됩니다.

나머지 요소

이렇게 모든 과정을 끝마치면 람다 함수를 저장하여 사용할 수 있습니다!!

4. 테스트

아래와 같이 테스트 코드를 작성해서 테스트를 할 수 있습니다.

json 형태로 테스트 이벤트 구성을 해보자! 아래와 같이 코드를 작성해봅니다.

테스트 코드 작성

위와 같은 과정을 마치고 나서 저장을 누르면 작성한 테스트 이벤트가 저장됩니다.

그 후 테스트 버튼을 클릭해주면...

이런식으로 실행 결과를 확인할 수 있습니다.

여러가지 정보가 있는데 대충 여기 나오는 정보들을 참고해서 설정 등을 다시 조정한 뒤에 함수를 저장해주면 될듯!! (메모리, 실행시간 등)

물론 위와 같이 하면 테스트 코드를 작성한 의미가 없기에 함수 코드를 변형해서 다시 테스트를 해보겠습니다!

response에 event 추가.

코드에 event를 추가!!

결과는...

코드 변경 후 테스트

위와 같이 함수가 반환한 response 안에 테스트에서 설정한 key와 value값을 결과에서 확인할 수 있습니다.

조금 더 재미있게 테스트를 해보자 !

함수 수정

함수를 수정해서 랜덤으로 숫자를 생성해서 해당 위치 키 값을 넣어서 결과를 출력해 봤습니다.

결과

미친 개발자....ㅋㅋㅋㅋ 기분 묘하네 ^_^

아무튼 이런식으로 해서 기본적인 사용법을 확인할 수 있습니다.

외부에서도 함수를 호출하면 되는데 다음 글에서 해보겠습니다!

ps. 계속 쓸 수 있을까... 블로그만 쓰면 넘나 귀찮아 진다...ㅠ

AWS 를 사용한 서버리스 아키텍쳐 적용기(삽질기) (1) - 람다함수 1

지로원 — Tue, 7 May 2019 11:43:29 +0900

서버리스 아키텍쳐 (serverless architecture) 란?

기존에 서버를 가지고 하던 서비스를 서버가 없이 동작하게 만드는 구조.

(그렇다고 진짜 서버가 없는 것은 아니고, 클라우드를 통해 서버가 없는 것처럼 사용한다는 뜻. 진짜 물리서버는 어딘가에 당연히 있음.)

서버리스를 구축하기 위한 방법에는 여러가지가 있지만 여기서는 서버리스를 구축하기 위해 AWS를 사용합니다.

0. AWS lambda란?

serverless event handling computing service.

다시말해, 서버가 없는 클라우드 함수 기반 마이크로 서비스. 기존의 서비스들은 서버에 코드를 올려 배포한 뒤 서비스를 제공하는 방식이었다면, 람다는 서버에 따로 올려서 서버를 관리할 필요가 없다는 것!! 넘나 좋은 것~

서버가 따로 필요없이 코드만 따로 배포가능. 그리고 서버가 없기 때문에 과금방식은 함수 실행 시 과금되는 방식.

여러가지 장점이 있으니 구글 교수님과 알아보도록 하겠습니다. 물론 단점도 존재. 제대로 사용하려면 이것저것 따져보고 공부도 많이 해야될 듯...

아무튼 이제부터 기초부터 살살 들여다 보겠습니다~!

1. 람다를 클릭해서 들어간 다음 region을 서울로 설정

람다 최초 화면

2. 함수 생성 버튼 클릭.

아래와 같은 화면이 나옵니다. (검색해보니 블루프린트는 사용 용도별 샘플 코드가 모여있음 !! 니즈가 잘 맞으면 사용하면 편할수도?)

하지만 저는 새로 작성 하겠습니다. 왜? (개발자 특, 자기가 다 만들어보고 싶음). Node로 할꺼니깐 node 버전은 8.10 선택! 밑에 권한 설정하는게 있는데 기본 Lambda 권한으로 세팅해주면 됩니다.

함수 생성 버튼 클릭 !

함수 생성 화면

3. 본격적으로 함수 생성.

세부적으로 여러가지 메뉴가 있는데 차근차근 araboza.

맨 처음 보이는 Designer 탭.... 보아하니 다른 아마존 서비스와 묶어 사용할 수 있도록 트리거가 제공되는듯..?

나중에 살펴보도록 하고 함수 코드 부분으로 넘어가겠습니다. 에디터가 요기잉네 ㅎ

저는 드라큘라를 사랑하기 때문에 다크 테마로 바꿨습니다ㅎㅎ. 앞단계에서 런타임을 node로 설정해줬는데 여기서 다시 바꿀 수 있습니다.

이제부터 공식문서를 살펴보면서 코드 분석 시작!!

함수 생성 화면2

hello로 함수 이름 변경

exports.hello = async (event) => {
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

요로케 생겼는데 문서를 읽어보니 람다 함수는 기본적으로 handler 객체를 통해 호출된다고 합니다.

물론 handler 객체는 이름 입력하기 나름. helloWorld 출력할 꺼니깐 함수이름을 hello로 바꾸겠습니다.

그리고 우측 상단에 보면 핸들러 라고 써져있는데 이 부분엔 문맥상 파일 이름하고 함수로 구성된듯 (파일이름.함수 == index.hello)

4. 공식 문서에 람다 함수가 지원하는 호출 유형은 두가지.

첫 번째는 RequestResponse 또는 동기식 실행.

exports.myHandler = function(event, context, callback) {
   console.log("value1 = " + event.key1);
   console.log("value2 = " + event.key2);  
   callback(null, "some success message");
   // or 
   // callback("some error type"); 
}

실행 완료시 코드에서 callback을 호출할 수 있는데 callback이 없으면 Lambda가 자체적으로 callback 호출을 하고 반환 값은 null을 반환합니다. 콜백 형식은 callback(Error error, Object result) 형식. 귀찮으니깐 예제로 ㄱㄱ

callback();     // Indicates success but no information returned to the caller.
callback(null); // Indicates success but no information returned to the caller.
callback(null, "success");  // Indicates success with information returned to the caller.
callback(error);    //  Indicates error with error information returned to the caller.

result 값은 JSON.stringify와 호환이 가능해야 한다고 나와있습니다.

두 번째는 event 또는 비동기 실행 방식.

exports.myHandler = async function(event, context) {
   console.log("value1 = " + event.key1);
   console.log("value2 = " + event.key2);  
   return "some success message";
   // or 
   // throw new Error("some error type"); 
}

이 경우 람다는 함수 호출의 결과를 모두 폐기합니다. api call 등을 할 때, await나 promise 쓰면 결과적으로 동일하게 작동할 듯.

console.log 를 통해 생성하는 로그 메시지들은 cloudWatch를 통해 기록할 수 있습니다.

이때 함수 인자로 있는 context는 람다에서 핸들러로 쓰이는 객체입니다. 여러 정보를 제공하는 메서드와 속성들을 포함.

컨텍스트 메서드

getRemainingTimeInMillis() – Returns the number of milliseconds left before the execution times out.

컨텍스트 속성

functionName – The name of the Lambda function.
functionVersion – The version of the function.
invokedFunctionArn – The Amazon Resource Name (ARN) used to invoke the function. Indicates if the invoker specified a version number or alias.
memoryLimitInMB – The amount of memory configured on the function.
awsRequestId – The identifier of the invocation request.
logGroupName – The log group for the function.
logStreamName – The log stream for the function instance.
identity – (mobile apps) Information about the Amazon Cognito identity that authorized the request.
- cognitoIdentityId – The authenticated Amazon Cognito identity.
- cognitoIdentityPoolId – The Amazon Cognito identity pool that authorized the invocation.
clientContext – (mobile apps) Client context provided to the Lambda invoker by the client application.
- client.installation_id
- client.app_title
- client.app_version_name
- client.app_version_code
- client.app_package_name
- env.platform_version
- env.platform
- env.make
- env.model
- env.locale
- Custom – 모바일 애플리케이션에서 설정된 사용자 지정 값입니다.
callbackWaitsForEmptyEventLoop – Node.js 이벤트 루프가 빌 때까지 대기하는 대신, 콜백이 실행될 때 즉시 응답을 보내려면 false로 설정합니다. false인 경우, 대기 중인 이벤트는 다음 번 호출 중에 계속 실행됩니다

다음 예제는 컨텍스트 정보를 기록하는 핸들러 함수를 보여줍니다.

예 index.js

exports.handler = function(event, context, callback) {
    console.log('remaining time =', context.getRemainingTimeInMillis());
    console.log('functionName =', context.functionName);
    console.log('AWSrequestID =', context.awsRequestId);
    callback(null, context.functionName);
};

나머지는 다음 글에서 이어서 작성!

Maria DB (1. HeidiSQL 설정)

지로원 — Mon, 21 Jan 2019 19:43:14 +0900

1. HeidiSQL 설정

HeidiSQL 이란?

쉽게 말하면 MySQL, MSSQL 등의 관계형 데이터베이스의 GUI 컨트롤러 이다.

단순히 타이핑으로만 작동하면 CUI 환경에서 좀 더 편하게 데이터베이스를 사용하기 위해

만든 GUI 툴이다. 편하게 사용하기 위해 만들었기 때문에 기존 CUI 환경보다 명령도 훨씬 편리하고 사용자가 보기도 편하다.

기존에 사용하지 않고 작업했던 때보다 훨씬 편하고 좋기 때문에 한번 사용하고 나면 CUI 환경으로 돌아가기가 힘들다는 단점이 있다(?)

Maria DB를 설치할 때, HeidiSQL도 같이 설치된 것을 확인했었습니다.

설치된 HeidiSQL을 실행시켜줍니다.

하단의 신규 버튼을 클릭해줍니다.

그럼 세션이 하나 생성됩니다.

오른쪽의 네트워크 유형에서 MySQL을 고르고 세션 이름을 Maria_test로 변경해줍니다.

그 후 하단에 보시는 것과 같이 여러가지를 세팅해줍니다.

암호는 처음에 마리아 DB를 설치할 떄 설정한 암호를 넣어줍니다.

포트는 마리아 DB와 맞춰줍니다.

코멘트는 중요하지 않습니다.

세팅을 마치고 열기 버튼을 누르게 되면 하단과 같은 창이 뜨게 됩니다.

보시는 것과 같이 마우스 우클릭을 통해 객체를 유형별로 묶기를 활성화 시켜줍니다.

그럼 왼쪽에 보시는 것과 같이 유형별로 정돈된 모습으로 데이터베이스를 확인할 수 있습니다.

1번에 위치한 쿼리 탭을 클릭하면

2번에 보시는 것과 같이 쿼리를 입력할 수 있습니다.

그 후 3번의 화살표를 클릭하게 되면 쿼리가 실행되고 실패시 에러가 발생합니다.

이 과정을 거치지 않더라도 단순히 클릭으로 'table'을 만들고 편하게 'column' 들을 생성할 수도 있습니다.

그렇게 쓰기 위해서 GUI 툴을 쓰는 것이겠지요? ㅎㅎ

아무튼 사용하면 훨씬 편하고 작업 능률이 올라가는 HeidiSQL에 대해 알아보았습니다!!!

다음에는 기본적인 SQL 명령어들을 알아볼 수 있으면 좋겠...네요..

시간이 된다면..ㅠ

MariaDB (0. 설치)

지로원 — Sun, 20 Jan 2019 13:51:32 +0900

0. Maria DB 설치

<https://downloads.mariadb.org> 에 들어가서 다운로드를 받아줍니다.

Stable 버전과 beta 버전이 있고 저는 Stable 버전을 다운받겠습니다~

Stable 버전을 클릭하시게 되면 아래와 같이 다운받을 수 있는 목록이 쭉 뜨게 됩니다.

저는 윈도우에 설치할 것이므로 바로 설치할 수 있는 win64용 msi 파일을 다운받겠습니다.

클릭하게 되면 정보를 입력하는 박스들이 나오지만 No thanks 를 클릭하고 넘어갑니다.

이제 본격적인 설치입니다.

다운받은 msi 파일을 실행시키게 되면 아래와 같이 창이 뜹니다.

우선 Next를 눌러 설치를 진행합니다~!~!

그러면, 라이센스 동의서가 뜨고 체크박스를 클릭한 후 Next를 누르면 다음 단계로 넘어갑니다.

참고로 Maria DB는 오픈소스 라이센스 중 GPL v2 라이센스를 따릅니다.

그 후 설치할 폴더를 정해주고 Next를 클릭합니다.

다음으로 넘어가면 아래와 같이 root 를 설정하고 비밀번호를 설정해줍니다.

또한, 한글 사용을 위해 UTF8 체크박스를 클릭해줍니다.

이름, 포트, 버퍼사이즈, 페이징 사이즈 등을 정해줍니다.

저는 딱히 건드릴 것이 없으므로 다음으로 넘어가겠습니다.

서비스 이름이 왜 MySQL 인지 궁금하신 분들이 계실 수 있습니다.

Maria DB는 MySQL과 소스코드가 같습니다.

왜냐하면, MySQL의 핵심 개발자인 몬티 와이드니어스가 개발 신조와 회사가

맞지 않는다고 생각했고 이로인해 기존 회사를 나와 만든 것이 Maria DB이기 때문입니다.

그렇기 때문에 거의 대부분의 파일, 폴더구조, 명령어 등이 MySQL과 동일하다고 보시면 됩니다.

하지만 성능 면에서나 호환성 등 여러가지 부분에서 MySQL보다 훨씬 뛰어난 성능을 보유하고 있습니다.

간단하게 말해 MySQL의 상위버전이라 보시면 됩니다.

마지막으로 서비스 피드백에 관련된 부분입니다. 체크하셔도 되고 안하셔도 됩니다.

설치가 완료되면 다음과 같이 설치된 목록이 보이게 됩니다.

지금은 간단하게 DB 실행만 해볼 것이므로 MySQL Client를 클릭해 줍니다.

실행하게 되면 아래와 같이 설정한 비밀번호를 통해 Maria DB 실행이 가능합니다.

이 때, 프로그램이 존재하는 디렉토리를 확인합니다.

그 후 '고급 시스템 설정' 에서 환경 변수를 클릭합니다.

환경변수에서 Path 를 클릭해 편집을 누르면 아래와 같이 편집할 수 있는 창이 뜹니다.

우측에 새로 만들기를 클릭한 후 Maria DB가 위치한 폴더의 bin 까지 경로에 포함시켜 추가시켜 줍니다.

그 후 cmd 창에서 'mysql' 명령어를 실행시키면 에러가 발생하게 되는데 이는 권한 문제이므로

사용하는 유저를 '-u root' 옵션으로 고정시켜주고 '-p' 옵션으로 패스워드 활성화를 시켜줍니다.

그 후 이전과 같이 비밀번호를 치고 Maria DB에 접속할 수 있습니다.

아래는 간단하게 show databases; 명령어로 현재 존재하는 db 목록을 확인할 수 있습니다.

Data Structures and Algorithms (자료구조와 알고리즘)

지로원 — Thu, 13 Dec 2018 12:55:33 +0900

- Data Structures and Algorithms -

Linear structures <선형 구조>

- array

- list (linked, double linked)

- stack

- queue, priority queue

- deque (double ended queue)

Non-linear structures <비선형 구조>

- sets

- trees (binary tree, b-tree, heaps, other trees)

- graphs

Dictionary structures <딕셔너리 구조>

- hash table

- hash map

Paradigms (패러다임 및 설계 기법)

- Dynamic programming

- Greedy algorithm

- Divide and Conquer

- Back-tracking

Sort Algorithms (정렬 알고리즘)

- Bubble Sort

- Insertion Sort

- Selection Sort

- Quick Sort

- Merge Sort

- Heap Sort

- Counting Sort

- Radix Sort

- Shell Sort

- Tim Sort

Search Algorithms (탐색 알고리즘)

- Binary search

- Binary tree search

- Depth-first search

- Breadth-first search

Heap Algorithms (힙 알고리즘)

- Binary heap

- Binomial heap

- (Binary) Indexed tree

최소 비용 신장 트리

- Prim

- Kruskal

Shortest path Algorithms (최단 경로 알고리즘)

- Dijkstra's algorithm

- Floyd's algorithm

- Bellman-ford's algorithm

- A* algorithm

Machine Learning (기계 학습 알고리즘)

- Unsupervised

- Supervised

- Reinforcement

Mathematics (수학)

- Euclidian (최대공약수 & 최소공배수)

- 소인수분해

기하, P&NP, 문자열&오토마타&구조, 정수론 기타 등등

제 기준에서 정리한 것이므로 다른 사람과는 다를 수 있습니다.

하나씩 천천히 구현해 볼 계획입니다... 천천히....

[참고] wikipedia, stackoverflow, blog(rats'go 등), etc ...