1. api 패키지 설치

$ sudo apt-get update

$ sudo apt-get install ca-certificates

$ sudo apt-get install curl

$ sudo apt-get install gnupg

$ sudo apt-get install lsb-release

1-2. GPG 키 추가 (docker 프로그램 자체를 인증하기 위한 키)

$ sudo mkdir -p /etc/apt/keyrings

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

1. docker 설치

$ sudo apt update
$ sudo apt install docker-ce docker-ce-cli containerd.io

위 코드들 중 입력해야 될 부분은 없다.

docker hub 사용법

docker hub에 회원가입 후 Repository를 생성해 준다.

그 후 docker hub에서 Account Settings > Security > Access Tokens를 통해 토큰을 새로 발급한다. (github 토큰과 마찬가지로 다시 볼 수 없으니 꼭 저장해둔다.)

docker login

or

docker login -u <docker ID>

위 명령어를 입력 후 pw부분에 발급 받은 토큰을 넣어주면 된다.

명령어를 통해 local에 인증을 하신 후

docker push <Repository name>

을 통해 docker hub에 업로드를 진행하면 된다.

반대로 서버에 이를 받기 위해선 동일하게 설치 > 로그인을 진행한 후

docker pull <Repository name>

VPC란?

Amazon VPC는 Amazon에서 제공하는 Private한 네크워크 망

• Virtual Private Cloud(VPC) — 사용자의 AWS 계정 전용 가상 네트워크입니다.
• 서브넷 — VPC의 IP 주소 범위입니다.
• 라우팅 테이블 — 네트워크 트래픽을 전달할 위치를 결정하는 데 사용되는 라우팅이라는 규칙 집합입니다.
• 인터넷 게이트웨이 — VPC의 리소스와 인터넷 간의 통신을 활성화하기 위해 VPC에 연결하는 게이트웨이입니다.
• NAT 게이트웨이 — 네트워크 주소 변환을 통해 프라이빗 서브넷에서 인터넷 또는 기타 AWS 서비스에 연결하는 게이트웨이입니다.
• 씨큐리티 그룹 — 보안 그룹은 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할을 하는 규칙 집합입니다..
• VPC 엔드포인트 — 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결을 필요로 하지 않고 PrivateLink 구동 지원 AWS 서비스 및 VPC 엔드포인트 서비스에 VPC를 비공개로 연결할 수 있습니다. VPC의 인스턴스는 서비스의 리소스와 통신하는 데 퍼블릭 IP 주소를 필요로 하지 않습니다. VPC와 기타 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다.

[AWS] 가장쉽게 VPC 개념잡기

IP 네트워크 대역과 사설IP,공인IP

VPC 생성해보기

위의 사설망에서 보듯이 우리가 aws측에서 받아온 공인 ip 내부의 사설망 구조를 잡아주는 것이라고 생각하면 된다.

192.168.x.x, 172.16–31.x.x, 10.x.x.x IP 이 세가지 대역들은 사설망 내부의 ip이다.

• 사설 네트워크에 활용하는 IP 대역 범위는 10.0.0.0 ~. 10.255.255.255, 172.16.0.0 ~ 172.31.255.255, 192.168.0.0 ~ 192.168.255.255 이다.

2023년 1월 기준 가장 최신의 vpc 생성창의 모습이다. 네트워크의 모든 구조를 안다면 vpc만 생성하기를 통해 기초부터 만들기가 가능하지만 모든 편의성과 간소화를 위해 vpc 등을 선택하여 만들어 준다.

• IPv4 CIDR 블록

  • 이 부분이 위에서 말한 사설 네트워크이다. 즉, 192.168.x.x, 172.16–31.x.x, 10.x.x.x 이 셋중 하나를 입력해주면 되는데 뒤의 / 는 무엇일까?

  • 아래 링크에서 간단하게 이해하고 서브넷 마스크 치트 시트 이 부분만 인지하면 된다. (간단하게 이해하면 숫자가 클수록 해당 네트워크 안에서 사용할 수 있는 ip 주소의 갯수가 줄어든다고 생각하면 된다.)

    서브넷 마스크란 무엇인가요?

• 가용 영역(AZ)

  • aws 온프레미스 실제 데이터센터 내에 물리적으로 떨어져 있다는 것을 의미 a,b,c,d로 나누어져 있다.
  • 이전에 카카오 화재 사건때를 봤을 때 a zone에서 사고가 생겨도 b,c,d 존은 서버를 유지 할 수 있게 설계 되어 있다.
  • 이런 것을 고가용성 설계(high availability) 설계라고 한다.

• NAT 게이트웨이

  • 서브넷은 public 서브넷과 private 서브넷으로 나누어져 있다. public의 경우에는 인터넷 게이트웨이(igw)를 통해 외부 인터넷과 통신이 가능하게 만들어 놨지만 private은 외부 인터넷의 접근을 차단하고 내부 망에서만 사용이 가능하게 만든 서브넷이다. (ex. DB)

  • 이러한 private 서브넷을 외부 인터넷을 통해 업데이트를 진행하는 등 접근이 필요한 경우를 위해 사용되어지는 것이 NAT 게이트웨이이다.

    • 예시 그림

      

- 이전에 private subnet의 DB에 접속하기 위해 public의 ec2에 ssh 접속을 해서 접근했던 방식이 있었는데 이와 비슷하다고 생각하면 된다.

// provider.tf
provider "aws" {
  region = "ap-northeast-2"
}

위와 같이 파일을 생성해주고 terraform init 명령어를 입력하면

그러면 initialize가 진행이 되고 프로바이더를 다운로드 받는다.

local에는 아래와 같은 폴더 두개가 생긴다.

.terraform , .terraform.lock.hcl

.terraform은 프로바이더에 명시한 cloud의 api 라이브러리들을 가져와 저장한다.

.terraform.lock.hcl은 잠금 파일이며 경쟁 상태에서 생길 수 있는 문제들을 피할 수 있게 해줍니다.

Terraform plan

// s3.tf
resource "aws_s3_bucket" "test" {
  bucket = "terraform-inflearn-chs"
}

위와 같이 resource를 작성해주고 terraform plan을 입력해주면

# aws_s3_bucket.test will be created
  + resource "aws_s3_bucket" "test" {
      + acceleration_status         = (known after apply)
      + acl                         = (known after apply)
      + arn                         = (known after apply)
      + bucket                      = "terraform-inflearn-chs"
      + bucket_domain_name          = (known after apply)
      + bucket_regional_domain_name = (known after apply)
      + force_destroy               = false
      + hosted_zone_id              = (known after apply)
      + id                          = (known after apply)
      + object_lock_enabled         = (known after apply)
      + policy                      = (known after apply)
      + region                      = (known after apply)
      + request_payer               = (known after apply)
      + tags_all                    = (known after apply)
      + website_domain              = (known after apply)
      + website_endpoint            = (known after apply)

      + cors_rule {
          + allowed_headers = (known after apply)
          + allowed_methods = (known after apply)
          + allowed_origins = (known after apply)
          + expose_headers  = (known after apply)
          + max_age_seconds = (known after apply)
        }
...

이러한 형태가 return 된다.

위의 결과를 보면 bucket의 이름의 경우 필수 값이기 때문에 반드시 입력이 되었고 나머지는 default값 혹은 정의를 해도 되고 안해도 되는 그러한 부분들이다.

Terraform apply

...

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

위와 같이 출력이 되는데 실제로 yes 를 입력 해주어야한다.

실제 인프라에 적용이 되는 부분이기 때문에 굉장히 예민한 작업이 될 수 있기에 경고문 역활을 한다.

이후 ls 명령어를 치면 terraform.tfstate 파일이 추가된 것을 볼 수 있다.

→ backend를 따로 지정해주지 않았기에 local이 backend가 된 것이다.

Terraform import

기존에 작성했던 s3 bucket들의 정보도 가져올 수 있다.

작동원리를 잘 이해해야된다.

1. 기존 작성했던 resource를 삭제하고 import를 진행하면 code가 없기 때문에 에러가 난다.

2. 그 후 다시 똑같이 resource를 작성하고 plan을 하면 plan은 성공으로 나온다.

   → 여기서 알 수 있는 것은 plan은 실제 리소스가 있는지 없는지 검사하지 않는다는 점이다.

    Do you want to perform these actions?
      Terraform will perform the actions described above.
      Only 'yes' will be accepted to approve.
   
      Enter a value: yes
   
    aws_s3_bucket.test: Creating...
    ╷
    │ Error: creating Amazon S3 (Simple Storage) Bucket (terraform-inflearn-chs): BucketAlreadyOwnedByYou: Your previous request to create the named bucket succeeded and you already own it.

3. 이럴 때 사용하는 것이 import이다.

5가지 철학

문화(Culture)

• 올바른 기업문화를 가져나가는 것

자동화(Automation)

• 업무를 자동화
• 변경에 유연하고 탄력적인 서비스를 구축

측정(Measurement)

• 변경 사항을 항상 측정, 예측

공유(Sharing)

• 언제든 접근 가능한 투명한 데이터
• 문제를 함께 해결 (open 되어있어야함)

축적(File up & Pile up)

데브옵스는 어떤 요구사항을 효율적으로 만족시키기 위하여, 일을 자동화하며 변경사항 지표들을 측정하고, 공유하고, 이 모든 결과물들을 지속적으로 축적해 나아가는 문화를 만들어가는 철학, 방법론, 기술

DevOps 엔지니어

올바른 DevOps 문화를 위해 서비스 혹은 S/W LifeCycle에서 반복적인 일들을 자동화하고, 기술적 문제 혹은 팀의 차이를 기술적으로 예방하고, 해소시키는 사람

• DevOps 엔지니어의 역량에 따라 차이가 큰 편임
• 파이프라인 구성, 빌드 자동화

Infrastructure as Code (코드로써의 인프라)

Infrastructure as Code, 즉 코드로써의 인프라는 인프라를 이루는 서버, 미들웨어 그리고 서비스 등 인프라 구성요소들을 코드를 통해 구축하는 것.

IaC는 코드로써의 장점, 즉 작성용이성, 재사용성, 유지보수 등의 장점을 가진다.

Terraform

.tf 의 파일 형식을 가짐 (확장자)

Terraform구성요소

• provider - 테라폼으로 생성할 인프라의 종류를 의미
• resource - 테라폼으로 실제로 생성할 인프라 자원을 의미
• state - 테라폼을 통해 생성한 자원의 상태를 의미
• output - 테라폼으로 만든 자원을 변수 형태로 state에 저장하는 것을 의미
• module - 공통적으로 활용할 수 있는 코드를 문자 그대로 모듈 형태로 정의하는 것을 의미
• remote - 다른 경로의 state를 참조하는 것을 말한다. output변수를 불러올 때 주로 사용

Terraform provider

provider "aws" {
  region = "ap-northeast-2"
  version = "~> 3.0"

}

provider 안에서 다양한 Arguments를 가진다.

AWS resource를 다루기 위한 파일들을 다운로드 하는 역활을 합니다. (aws-sdk)

Terraform resource

# main.tf, vpc.tf 등 원하는 형태로 파일이름을 사용
# Create a VPC
resource "aws_vpc(리소스 명)" "실제 이름" {
  cidr_block = "10.0.0.0/16"
  ...
}

테라폼으로 VPC를 생성하는 코드 일부

Terraform state

# terrafrom.tfstate 라는 파일명을 가진다.
{
  "version": 4,
  "terrafrom_version": "0.12.24",
  "serial": 3,
  "lineage": "3c77XXXX-2de4-7736-0447-038974a2c127",
  "outputs": {},
  "resources": [
    {...},
    {...},
  ]
}

테라폼으로 작성된 코드를 실행하게 되면 생성되는 파일(package.json 같은?)

현재 인프라의 실제 상태를 의미하는 것이 아님

그러므로 가장 중요한 것은 현재 인프라 상태와 state를 똑같이 유지하는 것이다.

현업에서는 원격 저장소인 ‘backend’에 저장하여 사용

Terraform output

resource "aws_vpc(리소스 명)" "실제 이름" {
  cidr_block = "10.0.0.0/16"
  ...
}

output "vpc_id" {
  value = aws_vpc.default.id
}

output "cidr_block" {
  value = aws_vpc.default.cidr_block
}

resource를 통해 무언가를 생성하였을 때 나오는 id, cidr 값 등을 참조해서 변수(ex. vpc_id, cidr_block)를 통해 state 파일에 저장을 하는 것

리모트를 통해 사용가능

Terraform module

module "vpc" {
  source = "../_module/vpc"

  cidr_block = "10.0.0.0/16"
}

module은 한 번 만들어진 테라폼 코드로 같은 형태를 반복적으로 만들어 낼 때 주로 사용

재사용에 대한 강점 ( module의 사용을 보고 테라폼을 잘 쓰냐 못 쓰냐를 판단할 수 있을 정도)

Terraform remote

# remote는 원격 참조 개념으로 이해
data "terraform_remote_state" "vpc(고유값)" {
  backend = "remote"

  config = {
    bucket    = "terraform-s3-bucket"
    region    = "ap-northeast-2"
    key       = "terraform/vpc/terraform.tfstaqte"
  }
}

state 파일에서 output으로 저장된 변수를 가져오는 것

Terraform 기본 명령어

Process

Init - 작성한 코드에서 init 명령어를 입력 - 테라폼의 다른 명령어들을 위한 설정 진행

Plan - 실제로 작성한 테라폼 코드가 어떻게 만들어질지 예측 - 가장 많이 쓰이는 명령어로 plan에서 문제가 없어야 apply도 문제가 없을 확률이 높다. ⇒ 습관화

Apply - 실제로 작성한 코드로 명령어를 생성하는 명령어 - 실제 인프라에 영향을 끼치는 명령어로 주의가 필요

코드

// import AWS from 'aws-sdk';
const AWS = require('aws-sdk');

const s3 = new AWS.S3();

exports.handler = async (event, context, callback) => {
    try{
        const { id } = event;

        const arCategory = id.split(' ');

        let bucket, key;

        if (arCategory[0] === 'video') {
            bucket = '버켓명';
            key = arCategory[1] + '.arexport';
        }
        if (arCategory[0] === 'makers') {
            bucket = '버켓명';
            key = arCategory[1] + '/' + id + '.arexport';
        }

        // console.log(bucket,key)

        const params = {
            Bucket: bucket,
            Key: key,
        };

        // return params;

        return s3.getObject(params, async (err, data) => {
            if (err) {
                err.message = 'Not yet!!!!!!!!';
                return err.message;
                // next(err); // an error occurred
            } else {
                const jsonData = data.Body;
                // 여기 수정 현재는 파일안의 링크 => 파일 자체 링크
                // const jsonText = `https://${params.Bucket}.s3.ap-northeast-2.amazonaws.com/${params.Key}`;
                const jsonText = JSON.parse(jsonData.toString());
                console.log(jsonText);
                if (jsonText) {
                    callback(null, jsonText);
                    return {statusCode: 200, body: JSON.stringify(jsonText)};
                //    res.status(200).json(jsonText);
                } else {
                    return params;
                //    res.sendStatus(400);
                }
            } // successful response
        }).promise();
    }catch(e){
        console.log(e);
    }
}

기능을 간단하게 설명하면 S3에 파일이 업로드 되었는지 체크하는 API이다.

1. 리전 문제

해당 lambda 함수는 최초에 오레곤(us-west-2)에서 작성이 되었고 s3 또한 오레곤에 존재했었다. 하지만 메인 서버는 서울(ap-northeast-2)에 존재 하였고 이에 맞춰 S3를 서울에 새로 생성하니 테스트시 지속적인 에러가 발생하였다.

Error Log

  "errorType": "NoSuchKey",
  "errorMessage": "Not yet",
  "trace": [
    "NoSuchKey: Not yet",
    "    at Request.extractError (/opt/nodejs/node_modules/aws-sdk/lib/services/s3.js:711:35)",
    "    at Request.callListeners (/opt/nodejs/node_modules/aws-sdk/lib/sequential_executor.js:106:20)",
    "    at Request.emit (/opt/nodejs/node_modules/aws-sdk/lib/sequential_executor.js:78:10)",
    "    at Request.emit (/opt/nodejs/node_modules/aws-sdk/lib/request.js:686:14)",
    "    at Request.transition (/opt/nodejs/node_modules/aws-sdk/lib/request.js:22:10)",
    "    at AcceptorStateMachine.runTo (/opt/nodejs/node_modules/aws-sdk/lib/state_machine.js:14:12)",
    "    at /opt/nodejs/node_modules/aws-sdk/lib/state_machine.js:26:10",
    "    at Request.<anonymous> (/opt/nodejs/node_modules/aws-sdk/lib/request.js:38:9)",
    "    at Request.<anonymous> (/opt/nodejs/node_modules/aws-sdk/lib/request.js:688:12)",
    "    at Request.callListeners (/opt/nodejs/node_modules/aws-sdk/lib/sequential_executor.js:116:18)"
  ]
}

해결 S3와 Lambda는 같은 리전에서 사용한다.

2. Timeout (시간 제한)

제일 처음 나왔던 에러메세지는 다음과 같다.

Task timed out after 3.00 seconds

이런 에러 메세지와 함께 함수가 아예 실행되지 않았다. 찾아보니 Lambda의 기본 제한 시간 설정이 3초로 되어 있어 설정한 시간동안 함수가 끝이 나지 않으면 Timeout을 리턴하는 것이였다.

• 람다 함수의 제한 시간 설정
  • 설정한 시간이 지날 때까지 함수의 실행이 끝나지 않으면 함수는 실패함
  • 함수의 실행이 예상 외로 오래걸리거나 무한로딩되지 않도록 제한 시간이 지나면 실패시킴

• 발생 원인
  • 원격 API에 연결할 수 없거나 API 호출에 응답하는 데 오래 걸림
  • API 호출 시 소켓 제한 시간 내에 응답을 받지 못함
  • API 호출 시 Lambda 함수의 제한 시간 내에 응답을 받지 못함
  • 네트워크 문제로 인해 재시도 및 중복 API 요청이 발생시

해결

[구성] -> [일반구성] -> [편집] 에 들어가 제한 시간을 늘려주면 된다.

3. try/catch

위와 같이 timeout이 발생했을때에 관하여 찾아보다가 알게된 부분이다. 단순 handler 함수라고 생각하고 기능적인 부분만 생각을 하고 작성을 하였었는데 람다 함수의 성능 개선 부분에서 try/catch를 통해 API가 설정한 제한 시간까지 무한정 기다리지 않게 작성을 해주는 것이 좋다.

[참고] - https://dev.classmethod.jp/articles/lim-lambda-performance/

시작

Github과 jenkins를 연동하여 웹에서 프로젝트 생성시 Github repo가 생성 됨과 동시에 jenkins job 또한 자동으로 빌드 되어 생성되는 기능을 개발하고자 하였다.

문제

기존에 Github과 Jenkins의 연결을 ssh-key를 통한 연결을 하였다. 이 부분에서 문제가 생겼는데, Jenkins에서 생성한 Credential 하나에 ssh-keygen을 통해 생성한 key를 등록하고 동일한 key를 Github repo에 등록하는 식으로 하였다. 하지만 Github는 서로 다른 Repo에서 동일한 ssh key를 사용할 수 없었고 이에 새로운 repo당 Credential을 하나씩 생성해 주어야 됐다.

첫번째 방향성

단순히 ssh-keygen을 통해 생성된 키를 github api와 jenkins api 혹은 cli로 각각 Repo 생성, job생성을 하면 될 줄 알았다.

하지만 jenkins cli는 생각보다 어렵고 난해했다.

[참고]
[https://stackoverflow.com/questions/29616660/how-to-create-jenkins-credentials-via-the-rest-api](https://stackoverflow.com/questions/29616660/how-to-create-jenkins-credentials-via-the-rest-api)
- 위 방법에도 curl을 활용한 방법 밖엔 없었다. 원하던 ssh키를 넣는 방법은 존재하지 않았다.

시도

jenkins 서버에 다이렉트로 접속하여 /var/lib/jenkins에 직접 들어가 xml을 수정하는 방법을 생각하였다.

해당 경로에 가면 jobs라는 디렉토리가 존재하고 해당 디렉토리 안의 job을 복사하고 내부의 config.xml, credential.xml 파일을 수정할 생각이였다.

첫번째 방향성의 문제

1. xml 파일을 거의 처음 접해보았다. 구조가 약간 html 과 비슷(?) 하여 태그로 구분하였지만 정확히 구분 하였는지는 잘 알지 못하였다.
2. jenkins cli 중 해당 job의 credential.xml을 가져오는 get-credentials-as-xml 을 사용하였는데

<com.cloudbees.jenkins.plugins.sshcredentials.impl.BasicSSHUserPrivateKey plugin="ssh-credentials@291.v8211e4f8efb_c">
  <scope>GLOBAL</scope>
  <id>sshtest</id>
  <description></description>
  <username>quantum-universe</username>
  <usernameSecret>false</usernameSecret>
  <privateKeySource class="com.cloudbees.jenkins.plugins.sshcredentials.impl.BasicSSHUserPrivateKey$DirectEntryPrivateKeySource">
    <privateKey>
      <secret-redacted/>
    </privateKey>
  </privateKeySource>
</com.cloudbees.jenkins.plugins.sshcredentials.impl.BasicSSHUserPrivateKey>

이러한 형식으로 직접적으로 ssh 키를 넣는 것이 아닌 패키지를 활용하여 값을 넣는 방식이라 직접적으로 파일을 수정하여 적용시키기엔 어려움이 있었다. 즉, ssh키를 직접적으로 넣어 credential을 생성할 수 없었다.

1. 제일 큰 문제로는 get-job 을 통한 job의 설정을 변경하는데 있었다. config.xml의 파일이다.

<?xml version='1.1' encoding='UTF-8'?>
<project>
  <actions/>
  <description></description>
  <keepDependencies>false</keepDependencies>
  <properties/>
  <scm class="hudson.plugins.git.GitSCM" plugin="git@4.11.3">
    <configVersion>2</configVersion>
    <userRemoteConfigs>
      <hudson.plugins.git.UserRemoteConfig>
        <url>git@github.com:quanutum-universe/test.git</url>
        <credentialsId>ec2joo</credentialsId>
      </hudson.plugins.git.UserRemoteConfig>
    </userRemoteConfigs>
    <branches>
      <hudson.plugins.git.BranchSpec>
        <name>*/main</name>
      </hudson.plugins.git.BranchSpec>
    </branches>
    <doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations>
    <submoduleCfg class="empty-list"/>
    <extensions/>
  </scm>
  <canRoam>true</canRoam>
  <disabled>false</disabled>
  <blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
  <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
  <triggers>
    <com.cloudbees.jenkins.GitHubPushTrigger plugin="github@1.34.4">
      <spec></spec>
    </com.cloudbees.jenkins.GitHubPushTrigger>
  </triggers>
  <concurrentBuild>false</concurrentBuild>
  <builders>
    <hudson.tasks.Shell>
      <command>#!/bin/sh
</command>
      <configuredLocalRules/>
    </hudson.tasks.Shell>
  </builders>
  <publishers/>
  <buildWrappers>
    <jenkins.plugins.nodejs.NodeJSBuildWrapper plugin="nodejs@1.5.1">
      <nodeJSInstallationName>node16_ec2</nodeJSInstallationName>
      <cacheLocationStrategy class="jenkins.plugins.nodejs.cache.DefaultCacheLocationLocator"/>
    </jenkins.plugins.nodejs.NodeJSBuildWrapper>
  </buildWrappers>
</project>

기존의 job dir를 복사하여 name이나 repo 주소, branch 명 등을 변경하고 script를 추가할 수 있었다. 그 후 복사된 job이 적용되었나 jenkins에 접속하여 확인해 보았지만 적용이 되지않았다. 나중에 그냥 create-job cli로 변경하니 문제는 해결되었다.

• 원인

  jenkins 서버내의 파일들은 레플리카( 백업 복제본 ) 인 것 같았다. 그렇기에 설정파일을 변경해도 실제 서버에 적용 되지않았다. 이를 적용하기 위해선

  jenkins 관리 > Reload Configuration from Disk 를 통해 다시 적용 시켜주어야 했다.

두번째 방향성

찾다보니 ssh를 통한 Git 연결외에 Token을 통한 연결이 가능하다는 사실을 알게 되었다. 이전에 초기 셋팅을 할때 private repo는 ssh로만 연결이 가능할 줄 알았었지만 그렇지 않았다.

[참조]
https://kitty-geno.tistory.com/m/88
감사합니다

이전에 Token으로 했을 때 실패했던 원인에 대해서 좀 정리해보자면

총 2개의 Credential이 필요했었다.

1. Github Token 발행
2. jenkins 관리 > 시스템 설정 > Github > Add Github Server >

Add를 통해 새로운 Credential 생성

• kind - Secret text

• Secret - Git Token

• ID - Credential 이름 (정해주면 된다)

  그 후 Test connection을 해준뒤

Credentials verified for user {Credential 이름}, rate limit: 4998

이러한 형식으로 나오면 저장하면된다.

1. 새롭게 job 생성에 들어간 후
2. Repo url을 적어주고 branch를 적용할 branch로 변경 해준 후

Credentials Add를 통해 새로운 Credential을 만들어준다.

• Kind - Username with password
• Username : GitHub 계정 입력
• Password : Github token 입력 (계정 비밀번호 X)
• ID : Credentials의 이름 ( 직접 작성 )

Lambda

• 함수 생성

  • 생성시 실행 역할 설정이 중요
    • 요번에 만든 함수는 S3 버킷 내부의 파일들을 읽는 것임으로 IAM에서 S3 read에 관한 권한만 준다.

• Lambda Test 필수

  • lambda는 default

• 함수 생성 후 중요한 것 두가지

  • 트리거 추가
  • Layers 설정

트리거 추가

• API Gateway이다. Lambda에 대한 요청들을 걸러주는(?) 곳이다.
• 생성할 때 REST API로 생성해 주었다.
• 생성 후에 API 리소스에 들어간 후 메소드를 수정해준다. (ex. 쿼리 파라미터, 요청 본문 (body)
• 리소스
  • 작업에서 CORS에 대한 설정을 해준다.
  • 중요. TEST를 한 후 API 배포를 해주어야 POSTMAN 등 외부에서 사용이 가능하다.

Layers 설정

• 계층 설정으로 nodeJS 패키지 등 모듈들을 저장해 두는 곳이다.
• 호환 런타임이 설정 사항이라 되어 있지만 입력하지 않을시 추가 할 때 보이지 않음. 꼭 넣어주자.
• 파일을 .zip 형태 혹은 S3에서 다이렉트로 가져오는 두가지 방법이 있다.
  • .zip파일로 넣을 때 node_modules 파일만 압축해서 넣으면 인식이 되지않는다.
    • 꼭 nodejs/node_modules 의 형태로 넣어야된다.

작성시 주의 사항

1. 지속적으로 처음 요청을 보냈을 때 ERROR가 발생 ( error code : PermanentRedirect )
   • 원인을 찾아보니 S3에 접근할 때 리전이 서로 달라서 생기는 현상 ( lambda는 오레곤, s3는 오하이오 였음) 수정하니 에러 발생 X

• docker build ./ (현재 디렉토리)
  • -t : tag의 약자. 컨테이너 이름 짓기
• Node 베이스 이미지를 통해 임시 컨테이너를 생성한 후 docker 이미지를 만든다.
  • Base image → 임시 컨테이너 → docker image
  • 그렇기 때문에 생성할 때 none 이라는 이미지가 생성되었다가 사라진다.

docker 이미지 실행

• docker run { 이미지 이름 }
  • -it : 실행을 이어 가겠다. 바로 종료시키지 않겠다.
  • -p : 포트 포워딩. 어떤 포트로 접속해도 연 서버로 프록시
  • -d : detach 터미널을 바로 탈출

Dockerfile

# 베이스 이미지를 명시해준다.
FROM node:{Version}

# 모든 파일들을 포함시키기 위해서 (ex. package.json, app.ts)
COPY ./ ./

# 추가적으로 필요한 파일들을 다운로드 한다.
RUN npm install

#컨테이너 시작시 실행될 명령어들을 작성한다.
CMD [ "npm", "run","start"]

위가 기본틀의 예시이다. (NestJS 기준)

WORKDIR /usr/src/app

WORKDIR = 이미지 안에서 어플리케이션 소스 코드를 가지고 있을 디렉토리를 생성하는 것

이 디렉토리가 어플리케이션의 working 디렉토리가 된다.

문제점 및 사용이유

• Root 디렉토리에 모두 합쳐지기 때문에
  1. 원래 있던 home, lib 등 이름이 겹치는 것들은 덮어 씌우기가 된다.
  2. 정리정돈이 안된다.

package.json

위 Dockerfile 에서는 COPY를 통해 한 번에 모든 파일을 불러왔지만 실제로는 조금 다르다.

FROM node:{Version}

WORKDIR /usr/src/app

COPY package.json ./

RUN npm install

COPY ./ ./

CMD [ "npm", "run","dev" ]

이러한 이유는 코드가 수정이 되고 다시 빌드를 할 때 발생한다. ( 위의 Dockerfile을 수정전, 아래의 Dockerfile을 수정후라 부르겠다. )

핵심 - Dockerfile을 빌드 할 때 캐싱이 발생한다.

그렇기 때문에 수정전에 경우 재빌드를 할 때 종속성이 변경된 것이 아니라 소스만 변경되었으면 package.json을 통해 다시 한 번 RUN npm install 을 수행하게 된다.

이에 따라 수정후의 경우는 소스 변경의 경우 npm install 이 따로 실행되지 않는다.

• 문제 발생

  package-lock.json은 실제 package.json에 정의된 node module의 dependencies tree를 정의하기 때문에 package-lock.json파일도 반드시 필요하다.

  그렇기에

    COPY package*.json ./

  와 같이 써야한다.

    npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!

  또 위와 같은 에러가 나타났는데 이는 npm 버전에 나타났던 문제인데 핵심은

    FROM node:{Version}

  이 부분에서의 문제였다. package

Docker Volume

기존 방식은 COPY를 통해 도커 컨테이너에 새롭게 빌드하여 진행

Volume 방식은 도커 컨테이너에서 로컬의 소스들을 참조(Mapping) 하여 진행

docker run -d -p 4000:8080 -v /usr/src/app/node_modules -v $(pwd):/usr/src/app chsu00/hello-docker

배포 생성으로 들어간다.

처음엔 전부 셋팅하지만 나중에 수정할 땐 3부위로 나뉜다.

• 일반 - 설정
• 원본 도메인
• 동작

원본( 원본 도메인 )

원본 도메인 선택

• S3, Elastic Load Balancer등을 연결 시킬 원본 도메인(엔드포인트?)

이름 - 이름

기본 캐시 동작 ( 동작 )

경로 패턴 - 기본값

자동으로 객체 압축 - Yes

뷰어 엑세스 제한 - *따로 정리**

캐시 키 및 원본 요청

캐시 정책 - CachingOptimized

원본 요청 정책 - CORS-S3Origin (S3의 Cors 정책을 똑같이 따르겠다.)

응답 헤더 정책 - CORS-with-prefilght-and-SecurityHeadersPolicy( 모든 Cors 정책과 보안 헤더 정책을 적용시키겠다?)

설정( 일반 - 설정 )

다 필요 없고 - 물론 아직은

기본값 루트 객체 - S3라면 빌드 파일의 시작 index.html

뷰어 엑세스 제한

서명 URL이라고도 하며 인증이 된 URL을 통해서만 접근이 가능하도록 URL을 만들어 전달한다.

이 URL은 수명을 줄 수도 있다.

YES를 선택할 경우

Trusted key groups 와 Trusted signer 이렇게 있는데

Trusted key groups

• 키 그룹을 만들어 허용된 키들만 접근이 가능하게 한다.

Trusted signer

• 인증된 사용자들만 사용할 수 있게 하는 것인데 아마 이 부분에서 필요했던거 같다..
• 바로 cloudfront public key, private key, access key id 이렇게 3개를 만들어 준다. (말이 3개지 그냥 하나 만들면 다 만들어진다)
• 일단 Node 버전으로 다 실패 했고 Python으로 성공하였다. ( 나머지 : Perl, PHP, Java, C#)

서명 URL에 대한 서명을 만드는 코드 예제

import datetime

from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import padding
from botocore.signers import CloudFrontSigner

def rsa_signer(message):
    with open('<private key 경로>', 'rb') as key_file:
        private_key = serialization.load_pem_private_key(
            key_file.read(),
            password=None,
            backend=default_backend()
        )
    return private_key.sign(message, padding.PKCS1v15(), hashes.SHA1())

key_id = 'access key id'
url = '<cloudfront 도메인 + /index.html'
expire_date = datetime.datetime(2023, 1, 1) # 수명 주기를 정할 수 있다.

cloudfront_signer = CloudFrontSigner(key_id, rsa_signer)

# Create a signed url that will be valid until the specific expiry date
# provided using a canned policy.
signed_url = cloudfront_signer.generate_presigned_url(
    url, date_less_than=expire_date)
print(signed_url)

위 코드를 실행하면 생성되는 URL을 통해 접근을 하면 된다. ( 기존 cloudfront 도메인으로 접속시 Missing key만 뜬다.)

전체 시스템에서 클래스의 인스턴스를 하나만 존재하도록 하는 패턴이다.

• 객체 리터럴

// object literal
const obj = {
    name: 'singleton',
};

console.log(obj);

하지만 이 객체는 캡슐화가 되어 있지 않아 결합도가 커지며 데이터를 보호(모든 속성이 다 공개 되어 있음)하는데 문제가 생길 수 있다.

• ES5

// ES5
const ES5_Singletion = (function () {
    let instance;

    function setInstance() {
      instance = {
        id: 1,
        text: 'hello',
      };
    }

    return {
        getInstance() {
            if (!instance) {
                setInstance();
            }
            return instance;
        }
    };
})();

const es5Singletion1 = ES5_Singletion.getInstance();
const es5Singletion2 = ES5_Singletion.getInstance();

console.log('Singleton function', es5Singletion1 === es5Singletion2);

즉시 실행함수를 활용해서 instance 와 setInstance 함수를 캡슐화

• ES7

// ES7
let instance;

class Singleton {
  static instance
  constructor(){
    if (instance) return instance;
    this.id = 1;
    this.name = 'hello';
    instance = this;
  }
}

const es6Singleton1 = new Singleton();
const es6Singleton2 = new Singleton();

console.log("singleton class", es6Singleton1 === es6Singleton2);

정적 필드

게임 을 실행 했을 때 게임은 한 번만 켜져야하기 때문에 싱글톤 패턴이 적절하다.

Prototype

프로토타입 패턴은 객체를 생성할때 원본객체를 복사해서 생성하는 방식을 말한다.

JS에선 Class가 아닌 함수로 객체를 생성한다.(ES5)

function A(){
    this.user = "aaa";
};

// new 연산자
var new_a = new A();

// Object.create
var object_a = Object.create(A);

A.prototype.admin = "test";

위의 A함수를 생성자로 호출하면서 생성된 new_a객체는 A.prototype 객체를 원본 객체로하여 복제된 객체이다.

console.log(new_a);
// A { user: 'aaa' }

console.log(new_a.user);
// aaa

console.log(new_a.admin);
// test

console.log(new_a.__proto__);
// { admin: 'test' }

console.log(A.prototype === new_a.__proto__);
// true

A의 prototype 객체와 new_a의 원본 객체가 일치한다.

console.log(object_a);
// A {}

console.log(object_a.user);
// undefined

console.log(object_a.admin);
// test

console.log(object_a.__proto__);
// { admin: 'test' }

console.log(object_a.__proto__ === A.prototype);
// true

• A의 prototype 객체와 object_a의 원본 객체가 일치하지만 new 연산자와는 다르게 A의 user는 받아오지 못하였다.
  • 이는 new 연산자는 Object.create()에 coustructor를 추가해 실행하였기 때문이였다.
  • 그럼에도 Object.create가 생겨난 이유
    • constructor가 있는 prototype을 새로운 객체로 덮어 씌우면 원래 자기 자신의 constructor를 상실하게 된다.
    • 즉, JS내부에서 constructor가 망가지는 것을 원하지 않았기에
    • 하지만 더이상 거의 쓰이지 않는다..

그래서 찾아보다 발견한 것이 "AWS SES" (Simple Email Service) 였다.

이 글은 Nodejs를 기반으로 작성되었습니다.

프리티어는 매 달 62,000건의 메세지까지는 무료이고 요금은 아래와 같다.

사용

우선 AWS SES에 접속하여준다.

오른쪽의 Create Identity를 클릭하여 자격증명에 들어간다.

자격증명을 할 이메일을 적어준다. 메일에 들어가 aws 측에서 온 메일을 5분 안에 확인하고 링크를 클릭하여 자격 증명을 해준다.

aws-sdk

aws-sdk에서 사용할 IAM을 생성해주고 액세스키와 비밀키를 가져와 저장해준다. 아래 코드를 형식에 맞게 작성하고 보내주면 된다.

import nodemailer from 'nodemailer';
import dotenv from 'dotenv';
import AWS from 'aws-sdk';
import { logger } from './winstonLog';

AWS.config.update({ region: (SES 리전) });

const transporter = nodemailer.createTransport({
    host: 'email-smtp.(SES 리전).amazonaws.com',
    port: 465,
    secure: true,
    auth: {
        user: (IAM 액세스 키 ID),
        pass: (IAM 비밀키),
    },
});

export function SendMail(email: string, link: string | undefined) {
    transporter.sendMail(
        {
            from: (보내는 메일 주소(어디서)),
            to: (보낼 메일 주소(어디로)),
            subject: (메일 제목),
            html:(메일 내용)
        },
        (err: any, info: { envelope: object; messageId: string }) => {
            if (err) {
                logger.error(err);
            }
            logger.info('sendEmail: ' + JSON.stringify(info.envelope));
            logger.info(info.messageId);
        },
    );
}

1. Mac? Window?

활용하는 AR툴이 Window 버전과 Mac버전 두개밖에 존재하지 않고 linux가 따로 없었다. GUI 때문에 그런거 같기에 처음엔 AMI가 많고 더 사용하기 쉽고 비용이 저렴한 Window서버를 사용해서 진행을 하였다. 하지만 개발을 하다보니 만들어진 AR파일들이 핸드폰에선 모두 깨지는 현상이 일어났다. 이때 AWS에 존재하는 모든 Window AMI들을 다 사용해 보았고 이유를 발견할 수 있었다.

바로 그래픽카드

그래서 GPU 인스턴스인 p2,p3,p4,g3 등등 사용하려 했지만

GPU 인스턴스들의 vCPU가 0으로 기본 설정이 되어 있어 이를 사용하기 위해서는 aws측에 요청을 해야했다. 요청을 보내도 언제 답이 올지 모르는 상황이고 해서 요청을 보내 놓고 결국 Mac 인스턴스를 사용하기로 하였다.

2. Mac 인스턴스

Suyeon's Blog - [AWS] EC2에서 MAC 인스턴스 생성 및 접속 위 블로그 외에는 한글로 된 정보를 찾기 어려웠다. (감사합니다) Mac 인스턴스는 단 하나의 인스턴스 유형만 사용이 가능하다.

mac1.metal

또한 다른 인스턴스들과 다르게 전용 호스트를 먼저 할당을 해준 후에 생성이 가능하다.

전용 호스트란?

• 사용자 전용의 EC2 인스턴스 용량을 갖춘 물리적 서버
• 간단하게 PC한대를 빌리면 된다고 생각하면 좋을꺼 같다.

위와 같이 간단하게 설정을 해주고 생성을 하면된다.

주의할 점

- 전용 호스트는 생성 후 24시간 동안 삭제가 불가하며 하루치 만큼의 비용이 반드시 청구 된다.

그 후 다시 인스턴스 생성으로 돌아가 전용호스트에 만들어준 전용 호스트를 넣고 생성해주면 된다.

3. 연결 안됨

이게 왠걸 하라는데로 했는데 생성된 인스턴스가 상태 검사에서 1/2로 계속 실패한다. 참조 - aws 인스턴스 상태 확인

위와 같이 아무리 만들고 지우고를 반복해도 생성되지 않았다..

한참을 삽질한 결과 원인은 간단했다.

4. 해결

이걸 따로 써야할지도 의문이다만 원인은 리전이였다. 처음 서버를 만든 리전은 싱가포르였고 삽질을 하던 곳도 싱가포르였다. 혹시 모르는 생각에 리전을 오하이오로 옮겼고 정말 무슨 문제가 있었냔 듯이 깔끔하게 생성이되었다.

아마 싱가포르 리전에 Mac이 없었을지도

ORM을 쓰는 이유 데이터베이스의 접근을 줄이는 방법 Django를 좀 더 활용하는 법

드디어 그 세번째 Django를 좀 더 활용하는 법(ft.데이터베이스 접근을 줄이는 방법)에 대해 정리한다.

select_related, prefetch_related

이 두 가지를 알기 위해선 좀 더 django에 대해 생각해보아야한다.

N+1 problem

N+1 Problem이란 쿼리 1번으로 N건을 가져왔을때, 관련 컬럼을 얻기 위해 쿼리를 N번 추가 수행하는 문제이다. Django ORM은 Lazy-Loading방식이므로 ORM에서 명령을 사용할 때마다 DB에서 데이터를 가져오는 것이 아닌 모든 처리가 끝나고 호출 시정에서 쿼리를 실행하는 것이다. 이러한 Lazy-Loading의 문제를 해결할 방법이 Eager-Loading이다. Eager-Loaging은 사전에 쓸 데이터를 포함하여 쿼리를 날려준다.

여기서 Eager-Loading이 바로 select_related와 prefetch_related이다.

쿼리셋과 캐싱 각각의 쿼리셋에는 데이터베이스 액세스를 최소화하기 위한 캐시가 포함되어 있다. 처음 생성된 쿼리셋에서는 캐시가 비어있기 때문에 Query가 발생한다. 그 후 동일한 쿼리셋이 사용되어 질 경우 추가적인 Query가 발생하지 않고 캐시에서 꺼내 사용하게 된다.

select_related

select_related는 foreign-key, OneToOne처럼 single-valued relationship에서 사용이 가능하며 INNER JOIN 하여 데이터를 가져온다.

prefetch_related

prefetch_related는 foreign-key, OneToOne뿐만이 아닌 ManyToMany, ManyToOne과 같은 모든 관계에서 사용이 가능하다. prefetch_related는 데이터를 가져와서 MEMORY JOIN하는 형식으로 저장해 둔다.

ORM을 쓰는 이유 데이터베이스의 접근을 줄이는 방법 Django를 좀 더 활용하는 법

바로 "데이터베이스의 접근을 줄이는 방법"에 대한 생각이다.

데이터 베이스 접근 줄이기(최적화)

시리즈와 가장 알맞는 고민이였던 같다. 가장 기본적인 DB hit수를 줄여 최적화 시키는 방법에 대해 고민을 해봤다.

정말 단순하게 생각을 해서 Queryset 사용횟수를 최소화하기로 했다. 아래와 같다.

# 이전
"sns": [sns.id for sns in Sns.objects.filter(maker_id=maker.id)],

# 이후
"sns": list(maker.sns_set.values_list("address", flat=True)),

이와 같이 반복문을 통해 모든 결과값마다 DB를 Hit시키는 방법을 values() 혹은 values_list()를 통해 한번에 값들만 가져 나올 수 있게 진행하리라 생각했다. 하지만 착각한 것이 있었다.

착각

훨씬 더 전에 코드를 작성할 때 썻던 append()와 list comprehension과의 차이를 간과하고 있었다. for loop를 돌리면서 append를 하면 루프가 돌 때마다 DB hit이 이뤄지는 것이 맞지만 list comprehension은 그렇지 않았다. 하지만 덕분에 의외의 것들을 찾아내었다.

list() vs list comprehension

Python list() vs list comprehension building speed 내용을 정리하자면 list comprehension은 일반 루프와 마찬가지로 Python bytecode로 루프를 실행한다. 반면, list()은 C code로만 반복되며, 훨씬 더 빠르다.

다음

또한 마찬가지로 데이터베이스 접근을 줄이는 방법에 대해 찾았지만 세번째 주제와 공통적인 부분으로 다음 글에서 정리하려한다. 앞으로 개발을 하면서 가장 크게 작용할 부분이라 생각이든다. 또한 앞의 글들은 사실 다음 글을 위한 빌드라고 생각해도 무방할정도로 중요한 내용일 것이다.

21-12-08 추가

너무 간단하게 생각했던것 같다.. list() 메소드와 list comprehension을 비교한다는 것은 좋았으나 내부의 쿼리가 일치하지 않다는 것을 알아버렸다. 그렇기 때문에 코드 수정한것만 가지고 list() 와 list comprehension을 비교하는 것은 옳지 않다는 것을 알았다.. 단순히 결과 값이 잘 나왔을 뿐.. 또한 글 제목과 내용이 일치하지 않아서 어떻게 할지 고민중이다. ㅠㅠ 일단 제목은 바꿀 것이다.

또한 시리즈에서 제외했다..!

1. ORM을 쓰는 이유
2. 데이터베이스의 접근을 줄이는 방법
3. Django를 좀 더 활용하는 법

그 중 첫번째 ORM을 쓰는 이유에 관한 글이다.

Django ORM을 사용하는 이유

ORM(Object Relational Mapping)은 객체 관계 매핑으로 객체 지향 언어와 데이터 베이스의 통역사 같은 역활을 한다. 전에 생각으론 단순히 ORM을 사용하는 이유는 보다 직관적이고 사람이 이해하기가 쉬워서만 사용한다고 생각하였다. 하지만 찾아보니 좀 더 많은 이유가 있었고 그에 따른 단점들도 존재 하였다.

장점

1. 직관성(객체 지향적 코드)

• SQl문이 아닌 클래스의 메서드를 통해 데이터베이스를 조작하기 때문에 객체 모델만을 이용해 프로그래밍을 할 수 있다.
• CRUD를 위한 SQL문을 작성할 필요가 없다.(쿼리 작성은 필요)
• 각 객체 별로 작성하기 때문에 가독성이 높다.

2. 재사용, 유지보수의 편리성이 증가

• ORM은 독립적으로 작성이되어있고, 객체로 작성되었기 때문에 재활용이 가능하다.
• 매핑하는 정보가 명확하여 ERD를 보는 의존도를 낮출 수 있다.

3.DBMS 종속성 하락

• 객체 간의 관계를 바탕으로 SQL문을 자동으로 생성하고, 객체의 자료형 타입까지 사용할 수 있기 때문에 RDBMS의 데이터 구조와 객체 지향 모델 사이의 간격을 좁힐 수 있다.
• 객체에만 집중할 수 있기 때문에 DBMS를 교체하는 큰 작업에도 리스크가 적다.

단점

1. 완벽한 ORM 으로만 서비스를 구현하기가 어렵다.

• 사용하기는 편하지만 설계는 매우 신중하게 해야한다.
• 프로젝트의 복잡성이 커질경우 난이도 또한 올라갈 수 있다.
• 잘못 구현된 경우에 속도 저하 및 심각할 경우 일관성이 무너지는 문제점이 생길 수 있다.
• 일부 자주 사용되는 대형 쿼리는 속도를 위해 SP를 쓰는등 별도의 튜닝이 필요한 경우가 있다.
• DBMS의 고유 기능을 이용하기 어렵다. (하지만 이건 단점으로만 볼 수 없다 : 특정 DBMS의 고유기능을 이용하면 이식성이 저하된다.)
• 복잡한 쿼리문의 경우 SQL문이 좀 더 직관적이면서 효율적일 수 있다.

2. DB와 바로 연결하는 것보다 초기설정이 더 많아지거나 복잡해 질 수있다.

3. DB와 ORM 프레임워크, 내부코드에 대한 충분한 이해가 없는 경우 문제 해결이 힘들다.

4. DB에 직접 Query문을 보내는 것이 아니기 때문에 성능저하가 발생한다.

정리

Django ORM을 사용하면서 느꼈던 장단점도 있고 생각하지 못한 장단점도 있다. 직관성이나 재사용성은 생각을 해보았지만 데이터베이스 측면 즉, 서버에서의 생각을 많이 하지 못한것 같다. 단순히 ORM을 사용만 하는 것이 아닌 동작 방식을 이해하고 작성해야 서버의 성능을 향상시킬 수 있다는 것을 알게 되었다.

매운 것을 좋아하는 Leo는 모든 음식의 스코빌 지수를 K 이상으로 만들고 싶습니다. 모든 음식의 스코빌 지수를 K 이상으로 만들기 위해 Leo는 스코빌 지수가 가장 낮은 두 개의 음식을 아래와 같이 특별한 방법으로 섞어 새로운 음식을 만듭니다.

섞은 음식의 스코빌 지수 = 가장 맵지 않은 음식의 스코빌 지수 + (두 번째로 맵지 않은 음식의 스코빌 지수 * 2)

Leo는 모든 음식의 스코빌 지수가 K 이상이 될 때까지 반복하여 섞습니다.Leo가 가진 음식의 스코빌 지수를 담은 배열 scoville과 원하는 스코빌 지수 K가 주어질 때, 모든 음식의 스코빌 지수를 K 이상으로 만들기 위해 섞어야 하는 최소 횟수를 return 하도록 solution 함수를 작성해주세요.

제한 사항

• scoville의 길이는 2 이상 1,000,000 이하입니다.
• K는 0 이상 1,000,000,000 이하입니다.
• scoville의 원소는 각각 0 이상 1,000,000 이하입니다.
• 모든 음식의 스코빌 지수를 K 이상으로 만들 수 없는 경우에는 -1을 return 합니다.

입출력 예

1. 스코빌 지수가 1인 음식과 2인 음식을 섞으면 음식의 스코빌 지수가 아래와 같이 됩니다.새로운 음식의 스코빌 지수 = 1 + (2 * 2) = 5가진 음식의 스코빌 지수 = [5, 3, 9, 10, 12]
2. 스코빌 지수가 3인 음식과 5인 음식을 섞으면 음식의 스코빌 지수가 아래와 같이 됩니다.새로운 음식의 스코빌 지수 = 3 + (5 * 2) = 13가진 음식의 스코빌 지수 = [13, 9, 10, 12]

모든 음식의 스코빌 지수가 7 이상이 되었고 이때 섞은 횟수는 2회입니다.

풀이

import heapq

def solution(scoville, K):
    answer = 0
    heapq.heapify(scoville)
    while len(scoville) >= 2:
        s = heapq.heappop(scoville) + (2*heapq.heappop(scoville))
        heapq.heappush(scoville, s)
        answer += 1
        if scoville[0] >= K:
            return answer
    return -1

힙 (heap) 특징

• heapq를 import하여 좀 더 간결하게 코드를 짤 수 있음
• 부모 노드가 자식 노드보다 무조건 값이 작아야한다.
• 최소값 혹은 최대값을 구하는 문제에서 많이 사용된다.
• 주어진 리스트를 heapq.heapifty()를 통해 정렬을 먼저 해줘야한다.
• heapq.heappop()를 통해 최상단의 노드를 꺼내며 출력할 수 있다.
• heapq.heappush()를 통해 새로운 노드를 추가할 수 있다.

순서

1. heapq.heapify(scoville)을 통해 scoville을 정렬한다.
2. while문을 통해 scoville의 길이가 2이상인 경우에만 반복할 수 있게한다.
3. 연산방법에 따라 제일 작은 노드와 그 다음 노드를 연산해준다.
4. 연산된 값을 push해준다.
5. 그만큼 answer(count)를 1씩 증가시킨다.
6. push된 scoville에서 제일 부모노드(제일 작은 노드)가 K보다 작다면 answer를 return 한다.
7. 만약 이 조건이 맞지 않아 반복문을 탈출할경우 -1을 리턴한다.

n개의 음이 아닌 정수가 있습니다. 이 수를 적절히 더하거나 빼서 타겟 넘버를 만들려고 합니다. 예를 들어 [1, 1, 1, 1, 1]로 숫자 3을 만들려면 다음 다섯 방법을 쓸 수 있습니다.

• `-1+1+1+1+1 = 3
• 1-1+1+1+1 = 3
• 1+1-1+1+1 = 3
• 1+1+1-1+1 = 3
• 1+1+1+1-1 = 3`

사용할 수 있는 숫자가 담긴 배열 numbers, 타겟 넘버 target이 매개변수로 주어질 때 숫자를 적절히 더하고 빼서 타겟 넘버를 만드는 방법의 수를 return 하도록 solution 함수를 작성해주세요.

제한사항

• 주어지는 숫자의 개수는 2개 이상 20개 이하입니다.
• 각 숫자는 1 이상 50 이하인 자연수입니다.
• 타겟 넘버는 1 이상 1000 이하인 자연수입니다.

입출력 예

풀이

count = 0
def dfs(n, numbers, target): 
    global count
    if not numbers:
        if n == target:
            count += 1
    else:
        dfs(n+numbers[0], numbers[1:], target)
        dfs(n-numbers[0], numbers[1:], target)

def solution(numbers, target):
    dfs(0,numbers,target)
    answer = count
    return answer

DFS 와 BFS의 특징

• 트리로 문제를 구현해야하며 최하단의 모든 노드의 값들이 필요하기 때문에 입력되는 데이터의 크기가 크지 않다.
• 위와 같은 이유로 모든 값을 구하기 위해 재귀를 많이 사용함

순서

1. 전역 변수로 count를 선언해둔다.
2. dfs 함수에 number와 target과 함께 현재까지의 계산 결과를 저장할 n값을 같이 보내준다.
3. dfs함수 안에서 number가 없으면 조건을 넣어준다.(최하단 노드까지 도착했다는 뜻 = 모든 값들을 연산에 넣었다.)
4. 그 상태에서 최종 노드값이 target값과 일치하면 count에 1을 더해준다.
5. 만약 최종 노드까지 도달하지 못한 것이라면 값을 양수로 계산했을 경우 하나 음수로 계산했을 경우하나 이렇게 두가지의 값을 가지고 재귀함수를 실행한다.
6. 재귀함수를 돌리기 전 n 값에는 현재 인덱스 위치의 값을 더해주거나 뺴주며, numbers 배열같은 경우는 현재 계산된 값을 제외한 다음 인덱스부터 끝까지의 배열을 다시 보내준다.

필수 조건은 아래와 같다.

• 게시물 카테고리 및 필터 적용
• 게시글 검색 기능 추가
• 댓글 및 대댓글 기능 추가
• 게시물 조회수 구현
• Unit Test
• RestFul API
• mongodb

팀원

개발기간

21.11.1 ~ 21.11.3

기술스택

• python, django
• mongoDB, djongo
• AWS EC2
• Slack, Git

ENDPOINT

개발

초기 셋팅 및 기본 게시판 CRUD구현은 기존에 pre-onboarding 지원과제로 제출했던 git을 클론해와서 진행하였다.

필수 요청 사항 중, 기술적으로 3가지로 나눠 각자 하나씩 맡아 진행하였다. 그 중 내가 맡은 부분은 게시물 카테고리 적용과 게시물 조회수 구현 이였다.

mongodb

django와 mongodb를 연결하기 위해 djongo 모듈을 사용하여 진행하였다. djongo는 django의 ORM을 지원해주는 모델이다. 연결을 위해 아래의 강의를 보며 학습했다.

Using Django with MongoDB | MongoDB + Django CRUD API

또한 mongodb를 좀 더 쉽게 사용하기 위해 GUI환경인 MongoDB Compass를 사용하였다.

MongoDB Compass

🏷 게시물 카테고리

카테고리는 RDBMS로 보았을 때 게시물과 1:M 관계로 모델링을 추가하고 카테고리가 출력 되어져야 하는 부분에 각각 데이터를 받아와주었다.

# models.py
class Post(TimeStamp):
   ...
   category = models.ForeignKey("Category", on_delete=models.CASCADE)
   ...

 class Category(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        db_table="categories"

또한 카테고리를 통한 필터를 가능하게 만들어 필터에 대한 정보가 주어졌을 때 그에 맞는 카테고리를 가지고 있는 게시글들만 출력하게 구현하였다.

# view.py
class ListView(View):
    def get(self, request):
    if category:
            category_id = Category.objects.get(name=category).id
            posts = Post.objects.filter(category_id=category_id).order_by('-id')
        else:
            posts = Post.objects.all().order_by('-id')

또한 전체 게시글을 출력할 때 pagination을 통해 출력되는 게시글의 개수를 정해줬었는데 이 또한 동일하게 구현하였다.

# view.py
class ListView(View):
    def get(self, request):
        try:
            page       = request.GET.get("page")
            page       = int(page or 1)
            page_size  = 10
            limit      = page_size * page 
            offset     = limit - page_size
        ...
        result = [{
                "count" : len(posts)-(offset+i),
                "title" : post.title,
                "hit" : post.hit,
                "body" : post.body,
                "nickname" : post.user.nickname
            } for i,post in enumerate(posts [offset:limit])]

데이터를 가져올 때 게시글 앞에 번호를 매겨주고 싶었는데 데이터를 hard delete로 지울 경우 id값이 밀리는 현상이 생겨 고민을 하다가 전체 게시글의 수에서 offset과 반복되는 인덱스만큼의 값을 빼줘 중간에 데이터가 비어있다해도 번호가 이어지게 만들었다.

🏷 게시물 조회수 구현

기존에 구현한 조회수 같은 경우 get으로 게시글이 불러오질 때마다 hit을 1씩 추가시켜 저장을 하여 구현했었다.

post.hit += 1
post.save()

하지만 위와 같이 구현할 경우 한 사용자가 중복으로 조회수를 올릴 수 있는 문제 점이 존재하였다. 이에 관하여 찾아보니 3가지 방법이 있었다.

1. session
2. ip
3. cookie

세 가지 방식 중 가장 많이 사용되는 방식이 cookie 를 통하여 조회수를 관리하는 방법이였다. 기존 방식에는 cookie 만료 시간을 주어 지정한 시간이 지나면 자동으로 쿠키가 삭제되는 방식이였다. 하지만 이번 과제에는 "중복된 user가 조회수를 올릴 수 없게 구현" 이라 서술되어 있어 만료시간을 주지 않았다.

class PostView(View):
    @transaction.atomic
    @login_decorator
    def get(self, request,post_id):
        try:
            post = Post.objects.get(id=post_id)

            ...

            response = JsonResponse({"Result" : result, "Comment" : Result_comment}, status=200)

            if request.COOKIES.get('hit'):
                cookies = request.COOKIES.get('hit')
                cookies_list = cookies.split('|')
                if str(post.id) not in cookies_list:

                    post.hit += 1
                    post.save()

                    result["hit"] = post.hit
                    response = JsonResponse({"Result" : result, "Comment" : Result_comment}, status=200)

                    response.set_cookie('hit', cookies+f'|{post.id}', expires=None)
            else:
                post.hit += 1
                post.save()

                result["hit"] = post.hit
                response = JsonResponse({"Result" : result, "Comment" : Result_comment}, status=200)

                response.set_cookie('hit', post.id, expires=None)
            return response

        except Post.DoesNotExist:
            return JsonResponse({"message" : "POSTS_NOT_FOUND"}, status=404)

1. 첫번째 조건문을 통해 cookie에 hit이 존재하는지를 확인한다. 만약 없을 경우 바로 조회수를 '1' 추가 해주고 return 한다.
2. 존재할 경우 쿠키를 '|'를 기준으로 나누어준다.(cookie hit=1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1)
3. 게시물의 id가 cookie_list에 존재하지 않을 경우 '1' 추가해준다.

🏷 아쉬운 점

1. IP를 통해 접속기록을 저장하여 하는 방식도 구현해보고 싶었는데 어렵고 이를 습득하여 적용하기엔 시간이 부족하였다.
2. mongodb 즉, NoSQL을 사용하는데 이를 재대로 활용하기에는 시간이 많이 모자랐다. 하지만 기존에 사용하던 RDBMS만 사용해서 구현을 하다 NoSQL에 관해서 보았는데 굉장히 흥미로웠다. 어떤 점에서 보면 좀 더 가용성이 좋아보이기도 하고 재밌어보였다.
3. 게시물 상세 get 함수 상단에 "@transaction.atomic"이 있는데 이는 쿠키에 저장하기 위해 트랜젝션을 써주었다. 하지만 지금 생각해보니 굳이 함수 전체를 원자성으로 묶을 필요가 있었을까 싶다. 쿠키에 저장하는 부분만 with을 통해 원자성을 부여했다면 더 좋은 코드가 되었을 것 같다.

EC2

Amazon Elastic Compute Cloud의 줄임말로써 공식 문서에는 클라우드에서 확장 가능 컴퓨팅 용량을 제공한다라고 써져있다. 또한 Amazon EC2를 사용하면 하드웨어에 선투자할 필요가 없어 더 빠르게 애플리케이션을 개발하고 배포할 수 있습니다. Amazon EC2를 사용하여 원하는 수의 가상 서버를 구축하고 보안 및 네트워킹을 구성하며 스토리지를 관리할 수 있습니다. Amazon EC2에서는 확장 또는 축소를 통해 요구 사항 변경 또는 사용량 스파이크를 처리할 수 있으므로 트래픽을 예측할 필요성이 줄어듭니다라고 작성되어있다. 간단하게 말해 서버를 제공해준다라고 할 수 있을꺼 같다. 내 pc로 항상 서버를 켜둘 수 없으니 서버를 빌려줄테니 이걸로 자신만의 서버를 돌려봐라는 것이다. 이제 사용법에 대해 간단하게 알아보자.

단계 1: Amazon Machine Image(AMI) 선택

인스턴스를 시작하는데 필요한 운영 체제를 선택하는 부분이다. 프리티어를 사용하는 사람입장에서는 다른 선택보다는 우분투 서버를 이용하는것이 가장 좋은 것 같다.

단계 2: 인스턴스 유형 선택

인스턴스의 유형을 선택하는 부분이다. CPU, 메모리, 스토리지 및 네트워킹 등 다양한 조합이 있으나 이전과 마찬가지로 프리티어는 선택지가 하나밖에 없다..

단계 3: 인스턴스 세부 정보 구성

인스턴스를 구성하는 부분에서 가장 중요한 설정인거 같다. VPC를 생성해서 네트워크를 설정해주거나 private 서브넷과 public서브넷을 생성하여 설정해주거나 우발적인 종료로부터 보호등 많은 설정등이 가능하다 하지만 가장 기본적인 부분만을 사용하기 위해 지금은 기본값으로 설정해주겠다.

단계 4: 스토리지 추가

인스턴스의 디바이스 설정을 하는 부분이다. 서버의 용량이나 SSD등 설정을 하는 부분이다. 크기 부분을 함부로 수정했다가는 요금폭탄을 맞을 수 있으니 조심하자.

단계 5: 태그 추가

태그를 추가하는 부분이다. 이 부분은 지금까지 해오면서 특별히 어떠한 기능을 하는 것 같진 않는다. 하지만 나중에 따로 알아보고 정리할 예정이다.

단계 6: 보안 그룹 구성

보안 그룹은 인스턴스이 트래픽을 제어하는 방화벽을 정하는 부분이다. 쉽게 말하면 어떠한 프로토콜들이 이 서버에 접속이 가능한지 지정하는 부분이다. 이 부분에서 소스에는 종류가 3가지가 존재하는데 사용자 지정, 위치 무관, 내 IP이렇게 존재한다. 차례대로 내가 지정한 아이피만, 누구든지, 나만 이러한 뜻이다.

단계 7: 인스턴스 시작 검토

이제 지금까지 작성한 부분에 대해 검토를 하는 부분이다. 지금까지의 인스턴스 설정이 맞는지 확인을 하고 시작하기를 누르면 아래와 같은 화면이 나온다. 이 부분에서 암호화?를 한다고 생각하면 되는데 기존에 존재하지 않으면 새로 키 페어를 생성해주고 키 페어를 다운받으면 된다. 그러면 pem형식의 파일이 다운로드되는데 이것이 키페어 파일이다. 이 파일이 없으면 이 서버에는 더 이상 접근을 할 수가 없다.