Category: AWS

A contents of Amazon Web Services

AWS CloudFormation 보안 모범 사례

이 문서는 다음의 내용을 번역한 것입니다.

AWS CloudFormation을 사용하면 개발자와 시스템 관리자가 AWS와 연관된 리소스 모음을 질서있고 예측 가능한 방식으로 프로비저닝하고 업데이트하여 쉽게 생성하고 관리 할 수 ​​있다. 우리의 많은 고객들은 그들의 AWS 환경에서 변경사항을 간단하게 캡쳐하고 버전 제어를 실행하고 인프라에서 다른 작업 중에서도 비용을 관리하는 등에 모든 리소스를 제어하기 위해 CloudFormation 을 사용한다.

고객들은 자주 어떻게 CloudFormation 스택에 허가권을 제어하는 우리에게 묻는다. 이 글에서, 우리는 CloudFormation 에 대한 AWS Identity 와 IAM 정책을 사용, CloudFormation 에 특화된 IAM 조건 그리고 CloudFormation 스택 정책들을 포함하는 몇가지 모범사례를 공유한다. 대부분의 CloudFormation 배포는 AWS CLI 나 SDK 를 통해서 이루어지기 때문에 우리는 모범 사례를 어떻게 구현하는지 보여주기 위해서 AWS CLI 와 SDK 사용에 포커스를 둘 것이다.

IAM 을 통한 CloudFormation 스택 접근 제한

IAM 을 통해서, 여러분은 정책이나 사용자 혹은 롤(role) 을 사용함으로써 AWS 서비스나 리소스 접근을 보안적으로 통제할 수 있다. CloudFormation 은 fine-grained(세분화된) 액세스 제어를 제공하기 위해서 IAM 을 지렛대로 사용한다.

모범사례를 통해서, 우리는 최소 권한 원칙을 적용된 IAM 정책들을 통해 AWS 서비스 및 자원 접근을 제한하기 권한다. 이것을 하는 가장 단순한 방법은 CloudFormation 에 특정 API 콜을 제한하는 것이다. 예를들어, 여러분은 특정 IAM 유저나 롤이 CloudFormation 스택을 삭제하거나 업데이트하길 원하지 않을 것이다. 다음의 단수한 정책들은 모든 CloudFormation API 접근을 허용하지만 여러분의 프로덕트 스택의 UpdateStack 과 DeleteStack API 접근은 거부한다.

CloudFormation 을 위한 정책(Polices)
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect":"Allow",
        "Action":[        
            "cloudformation:*"
        ],
        "Resource":"*"
    },
    {
        "Effect":"Deny",
        "Action":[        
            "cloudformation:UpdateStack",
            "cloudformation:DeleteStack"
        ],
        "Resource":"arn:aws:cloudformation:us-east-1:123456789012:stack/MyProductionStack/*"
    }]
}

IAM 정책은 종종 특정 리소스를 생성할 수 있도록 허용해야 하지만 이러한 리소스를 CloudFormation의 일부로 생성하지 않을 수 있다. 이것이 CloudFormation 의 IAM 조건 지원이 제공된다.

CloudFormation 을 위한 IAM 조건

다음은 여러분의 IAM 정책에 추가할 수 있는 세가지 CloudFormation 특화된 IAM 조건들이다.

  • cloudformation:TemplateURL
  • cloudformation:ResourceTypes
  • cloudformation:StackPolicyURL

이러한 세가지 조건을 통해서, 여러분은 특정리소스 생성, 업데이트, 특정 템프릿 사용등과 같은 스택 작업을 API 로 가능해지거나 스택 업데이트 중에 의도하지 않게 업데이트나 삭제가 될수 있는 스택 리소스를 방지하는 스택 정책을 사용해 특정 리소스를 제한할 수 있다.

Condition: TemplateURL

첫째 조건, Condition: TemplateURL, 생성, 업데이트, reside 등과 같은 스택 작업에 대해 CloudFormation 템플릿을 지정하도록 하고 그것만 사용하도록 강제한다. IAM 정책에서, 다음과 같다.

Condition: TemplateURL 을 위한 정책(Polices)
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            “cloudformation:UpdateStack”
        ],
        "Resource": "*",
        "Condition": {
            "StringNotEquals": {
                "cloudformation:TemplateURL": [
                    "https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template"
                ]
            }
        }
    },
    {
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack"
        ],
        "Resource": "*",
        "Condition": {
            "Null": {
                "cloudformation:TemplateURL": "true"
            }
        }
    }]
}

첫번째 구분은 지정된 템플릿에 한해서 모든 CreateStack 과 UpdateStack API 콜을 활성화 한다. 두번째 구분에서 모든 CreateStack 이나 UpdateStack API 콜들은 TemplateURL 파라메터를 반드시 포함하도록 한다. CLI 에서 여러분의 호출들은 –template-url 파라메터를 포함해야 한다.

CLI를 이용한 template-url
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template

Condition: ResourceTypes

CloudFormation 은 IAM 정책을 통해서 템플릿 생성, 업데이트에 리소스 타입을 제어할 수 있도록 해준다. CloudFormation API는 ResourceTypes 파라메터를 받는다. API 호출에서, 생성이나 업데이트할 수 있는 리소스 유형을 지정할 수 있다. 하지만, 새로운 ResourceTypes 파라메터를 사용하기 위해서는 다음과 같이 컨디션 조건을 추가함으로서 특정한 파라메터 사용이 가능하도록 IAM 정책을 수정할 필요가 있다.

새로운 ResourceType 설정
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
{
    "Version":"2012-10-17",
    "Statement":[{
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack"
        ],
        "Resource": "*",
        "Condition": {
            "ForAllValues:StringLike": {
                "cloudformation:ResourceTypes": [
                    "AWS::IAM::*"
                ]
            }
        }
    },
    {
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack"
        ],
        "Resource": "*",
        "Condition": {
            "Null": {
                "cloudformation:ResourceTypes": "true"
            }
        }
    }]
}

CLI 에서, 여러분의 호출은 –resource-types 파라메터 포함할 필요가 있다. 여러분의 스택을 업데이트하기 위한 호출은 다음과 같다.

CLI를 이용한 --resource-types
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –resource-types="[AWS::IAM::Group, AWS::IAM::User]"

쉘(Shell)에 따라서 명령어는 쌍따옴표를 사용해야할 수도 있다. 그렇지 않으면 “No JSON object could be decoded” 에러를 보게 될 것이다.

CLI 사용시 쌍따옴표 사용
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –resource-types='["AWS::IAM::Group", "AWS::IAM::User"]'

ResourceTypes 조건은 CLI 나 API 호출을 통해서 CloudFormation 이 올바른 리소스 타입과 템플릿을 생성, 업데이트 하도록 합니다. 첫번째 예제에서, 우리의 IAM 정책은 AWS::IAM 리소스를 포함한 예제였기 때문에 API 호출을 차단했을 것이다. 만약 우리의 템플릿이 오직 AWS::EC2::Instance 자원만 포함한다면, CLI 명령어는 다음과 같을 것이며 성공할 것입니다.

CLI command 예제
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –resource-types='["AWS::EC2::Instance"]'

세번째 조건은 StackPolicyURL 조건이다. 어떻게 동작하는지 설명하기 전에, 우리는 스택 정책에 대해 몇가지 추가적인 컨텍스트를 제공할 필요가 있다.

Stack Policies

가끔, 최악의 운영 중단은 의도되지 않은 리소스에 변경으로 발생 된다. 이 리스크를 완화하는데 도움이 되기 위해, CloudFormation 은 스택 정책들을 제공는데 이것은 스택 업데이트 중에 의도치않은 업데이트나 삭제로부터 스택 리소스들을 보호해준다. IAM 과 함께 사용할 경우, 스택 정책들은 스택 리소스에 대해 악의적이고 의도치않은 변경 모두에 대해 두번째 방어 계층을 제공 한다.

CloudFormation 스택 정책은 스택 업데이트 작업의 일부로 업데이트할 수 있는 항목을 정의하는 JSON 문서다. 정책을 지정하거나 업데이트하기 위해서, 여러분의 IAM 사용자 혹은 롤(Role)은 반드시 우선적으로 Cloudformation::SetStackPolicy 액션을 호출 할 수 있어야 한다.

여러분 스택에 직접 스택 정책을 적용한다. 주의해야할 것은 이것은 IAM 정책이 아니다. 기본적으로, 스택 정책 설정은 명시적으로 Allow 지정하지 않는 한 업데이트를 거부하기 위해 Deny 를 사용해 모든 스택 리소스들을 보호한다. 이것은 만약 오직 몇가지 리소스들만 제한 하길 원한다면, 리소스 “*” 를 사용해 Allow 를 포함으로써 모든 업데이트를 반드시 명시적으로 허용해야 하며 특정 리소스를 Deny 해야 한다.

예를들면, 스택 정책은 라이브로 진행되는 데이터를 포함하고 있기 때문에 프로덕션 데이터베이스를 보호하는 데 종종 사용된다. 변경중인 필드에 따라 업데이트중에 전체 데이터베이스를 교체할 수 있는 경우가 있다. 다음의 예제는, 스택 정책은 명시적으로 프로덕션 데이터베이스 업데이트 시도를 거부한다.

프로덕션 데이터베이스 업데이트 거부
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
  "Statement" : [
    {
      "Effect" : "Deny",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "LogicalResourceId/ProductionDB_logical_ID"
    },
    {
      "Effect" : "Allow",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "*"
    }
  ]
}

여러분은 모든 RDS DB 인스턴스나 주어진 ResourceType 을 포함하도록 여러분의 스택 정책을 일반화 할 수 있다. 이것을 얻기 위해서는 컨디션 사용한다. 그러나, 우리의 예제는 와일드카드를 사용했기 때문에, condition 은 반드시 “StringEquals” 이 아닌 “StringLike” condition 을 사용해야 한다.

StringLike 사용예
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "Statement" : [
    {
      "Effect" : "Deny",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "*",
      "Condition" : {
        "StringLike" : {
          "ResourceType" : ["AWS::RDS::DBInstance", "AWS::AutoScaling::*"]
        }
      }
    },
    {
      "Effect" : "Allow",
      "Action" : "Update:*",
      "Principal": "*",
      "Resource" : "*"
    }
  ]
}

스택 정책에 대한 보다 많은 정보는  Prevent Updates to Stack Resources 참고하라.

마지막으로, 여러분의 모든 스택에 알맞은 미리 정의된 스택 정책을 가지고 있는지를 확인해라. 이것을 해결할려면 IAM 정책을 봐야 한다.

Condition:StackPolicyURL

여러분의 IAM 정책 내에서, 여러분은 모든 CloudFormation 스택이 StackPolicyURL 조건을 가지고 생성된 것과 연결된 스택 정책을 가지는지를 확인할 수 있다.

StackPolicyURL 조건 예제
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
{
    "Version":"2012-10-17",
    "Statement":[
    {
            "Effect": "Deny",
            "Action": [
                "cloudformation:SetStackPolicy"
            ],
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringNotEquals": {
                    "cloudformation:StackPolicyUrl": [
                        "https://s3.amazonaws.com/samplebucket/sampleallowpolicy.json"
                    ]
                }
            }
        },    
       {
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack"
        ],
        "Resource": "*",
        "Condition": {
            "ForAnyValue:StringNotEquals": {
                "cloudformation:StackPolicyUrl": [
                    “https://s3.amazonaws.com/samplebucket/sampledenypolicy.json”
                ]
            }
        }
    },
    {
        "Effect": "Deny",
        "Action": [
            "cloudformation:CreateStack",
            "cloudformation:UpdateStack",
            “cloudformation:SetStackPolicy”
        ],
        "Resource": "*",
        "Condition": {
            "Null": {
                "cloudformation:StackPolicyUrl": "true"
            }
        }
    }]
}

이 정책은 SetStackPolicy 가 호출될때마다 반드시 스택 정책 URL 이 지정되어 있는지 확인한다. 이 경우에, URL 은 https://s3.amazonaws.com/samplebucket/sampleallowpolicy.json 다. 유사하게, 모든 생성과 업데이트 스택 연산에서, 이 정책은 StackPolicyURL 은 S3 에 sampledenypolicy.json 문서로 지정되었고, StackPolicyURL 은 항상 지정된다. CLI 에서 create-stack 명령어는 다음과 같다.

StackPolicyURL CLI 명령어 예제
ZSH
1
aws cloudformation create-stack –stack-name cloudformation-demo –parameters ParameterKey=Password,ParameterValue=CloudFormationDemo –capabilities CAPABILITY_IAM –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –stack-policy-url https://s3-us-east-1.amazonaws.com/samplebucket/sampledenypolicy.json

주의해야 할 것은 만약 스택 업데이트에 새로운 스택 정책을 지정한다면, CloudFormation 은 이미 있는 스택 정책을 사용한다. 새로운 정책은 오직 이후 업데이트에만 새 정책을 사용한다. 예를들어, 현재 정책이 모든 업데이트를 거부하도록 지정되어 있다면, 딱 한개 업데이트를 허용하기 위해서 스택정책을 변경할려면 반드시 SetStackPolicy 명령어를 실행해야 한다. 그리고 여러분은 스택에 대해서 업데이트 명령어를 실행할 수 있다. 이미 생성된 스택 업데이트를 위해서 다음과 같이 실행 할 수 있다.

SetStackPolicy CLI 명령어 예제
ZSH
1
aws cloudformation set-stack-policy –stack-name cloudformation-demo –stack-policy-url https://s3-us-east-1.amazonaws.com/samplebucket/sampleallowpolicy.json

그리고 업데이트를 실행할 수 있다.

SetStackPolicy 이후에 stack 업데이트 실행
ZSH
1
aws cloudformation update-stack –stack-name cloudformation-demo –parameters ParameterKey=Password,ParameterValue=NewPassword –capabilities CAPABILITY_IAM –template-url https://s3.amazonaws.com/cloudformation-templates-us-east-1/IAM_Users_Groups_and_Policies.template –stack-policy-url https://s3-us-west-2.amazonaws.com/awshubfiles/sampledenypolicy.json

우리가 사용하는 IAM 정책은 스택이 생성 혹은 업데이트 될때마다 스택에 적용되어질 특정한 스택 정책을 보장한다.

Conclusion

CloudFormation 은 연관된 AWS 리소스를 생성, 관리하는 반복적인 방법을 제공한다. IAM 정책, 사용자, 롤, CloudFormation-specific IAM condition, 스택 정책을 조합해 사용함으로써, 여러분은 CloudFormation 스택을 의도한데로 사용하고 잘못된 업데이트, 삭제를 최소할 수 있다.

You can learn more about this topic and other CloudFormation best practices in the recording of our re:Invent 2015 session, (DVO304) AWS CloudFormation Best Practices, and in our documentation.

AWS EKS 클러스터 셋업

How to setup

AWS 의 EKS Cluster 를 셋업할 수 있는 방법에는 다음과 같다.

  • AWS Management Console
  • eksctl utility provided by AWS
  • IaC (Terrform, Ansible)

여기서는 AWS Management Console 를 이용한 방법을 사용할 것이다.

Prerequirement

AWS 를 사용하기 위해서는 권한이 있어야 한다. 다음과 같은 권한이 일단 필요하다.

  • AWS Account with Admin Privileges
  • AWS Cli Access to use Kubectl utility
  • Instance (To manage cluster by using Kubectl)

AWS 계정은 될수 있는한 관리자 권한이 필요하다.

Create IAM role for EKS Cluster

EKS Cluster 를 위한 IAM를 생성해야 한다. 이것은 IAM 서비스에서 역할(Role) 을 이용해서 생성한다.

각각의 허가권(Permission) 을 설정할 필요 없이 사용사례선택에서 EKS – Cluster 를 선택하고 Role 이름을 설정하면 끝나게 된다.

다음으로 일반 사용자가 이 Role 을 위임받을 수 있도록 신뢰관계를 맺어준다.

Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::1111111111111111:user/systemv"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

systemv 사용자에 대해서 신뢰관계를 만들어 줬다.

Create Dedicated VPC for the EKS Cluster

VPC 를 생성해야 하는데, 하나하나 생성할 수도 있다. 하지만, EKS 를 위해서 AWS 는 CloudFormation 템플릿을 제공하고 있다. 이 정보는 다음의 링크를 통해서 확인할 수 있다.

위 내용을 보면 S3 에 CloudFormation 용 템플릿을 제공한다. 이를 이용하면 손쉽게 VPC 를 생성할 수 있는데 생성되는 리소스는 대략 다음과 같다.

  • 퍼블릭 서브넷 2개, 모든 서브넷에는 로드밸런서 할당을 위해 태그가 지정된다.
  • 엘라스틱 IP 할당.
  • 프라이빗 서브넷 2개, 모든 서브넷에는 내부 로드밸러서 할당을 위해 태그가 지정된다.
  • NAT 게이트웨이 1개
  • 모든 인바운드 트래픽을 차단하고 아웃바운드 트래픽을 허용하는 보안그룹.

AWS EKS 는 Master Node, Worker Node 로 구성되는데, Master Node 는 Managed 서비스이며 이것은 퍼블릭 서브넷이 필요하게 된다. Worker Node 는 EC2 인스턴스에 Docker 가 설치되며 EKS 에 의해서 제어된다. 이것은 프라이빗 서브넷이 필요하게 된다.

모든 인바운드 트래픽은 차단되고 아웃바운드 트래픽을 허용하기 위해서 NAT 게이트웨이가 설치가 된다.

CloudFormation 을 이용해 이런 제반사항들을 손쉽게 만들 수 있다.

AWS EKS 생성을 위한 CloudFormation 스택 이름 변수 정하기
AWS EKS 생성을 위한 CloudFormation 스택 이름 변수 정하기

스택이름만 쓰고 나머지는 그냥 기본적으로 제공하는 값을 사용해도 된다. 다음화면에서 태그나 기타 필요 옵션등을 선택할 수 있는데, 아무것도 안하고 넘어가도 된다.

CloudFormation 을 이용한 AWS EKS VPC 생성완료
CloudFormation 을 이용한 AWS EKS VPC 생성완료

생성된 자원들을 보면 어떤 것을 생성했고 어떻게 연결을 했는지도 눈에 보인다. SecurityGroup 은 ControllPlane 에 접근을 위해서 만들어졌다.

Login AWS Account for creating Cluster

앞에 CloudFormation 작업은 AWS Root 계정으로 진행 된다. 어짜피 네트워크 작업이며 이를 제어하기 위한 퍼미션만 사용자가 가지고 있어도 되기 때문이다. 하지만 서비스는 다르다. 서비스는 Role 기반으로 작동되는 경우가 많아 반드시 일반 계정으로 생성을 해야 한다.

만일 AWS Root 계정으로 EKS Cluster 를 생성할 경웨 피고한 경우가 생길 수 있다. 따라서 반드시 일반 계정으로 로그인을 해준다. 그 계정에 다음과 같은 정책을 생성해 준다.

system-eks-policy
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:CreateInstanceProfile",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:DescribeRegions",
                "autoscaling:DescribeLaunchConfigurations",
                "iam:CreateRole",
                "iam:AttachRolePolicy",
                "iam:AddRoleToInstanceProfile",
                "iam:PassRole",
                "autoscaling:DescribeScalingActivities",
                "ec2:CreateSecurityGroup",
                "ec2:RevokeSecurityGroupEgress",
                "autoscaling:DescribeAutoScalingGroups",
                "iam:ListAttachedRolePolicies",
                "autoscaling:UpdateAutoScalingGroup",
                "ec2:DescribeKeyPairs",
                "ec2:AuthorizeSecurityGroupEgress",
                "iam:GetRole",
                "ec2:CreateTags",
                "iam:ListRoles",
                "ssm:GetParameters",
                "ec2:DescribeSecurityGroups",
                "cloudformation:DescribeStacks",
                "ec2:RevokeSecurityGroupIngress",
                "ec2:DescribeImages",
                "autoscaling:CreateLaunchConfiguration",
                "iam:CreateServiceLinkedRole",
                "cloudformation:CreateStack",
                "ec2:DescribeVpcs",
                "ec2:DescribeSubnets",
                "eks:*",
                "autoscaling:CreateAutoScalingGroup"
            ],
            "Resource": "*"
        }
    ]
}

EKS Cluster 를 위한 권한이 대부분 다 들어 있다.

Create EKS Cluster

이제 네트워크 환경이 모두 구성됐으니 EKS Cluster 를 만들어야 한다. AWS 콘솔에서 EKS 를 검색해 서비스로 이동하면 된다.

AWS EKS Cluster 기본정보 입력
AWS EKS Cluster 기본정보 입력

Kubernetes 버전은 최신버전으로 했지만, 실제 서비스 운영은 기본값을 사용하길 권장한다. 클러스터 서비스 역할에는 맨처음에 만들었던 역할을 지정해 주면 된다.

AWS EKS Cluster 네트워킹 지정
AWS EKS Cluster 네트워킹 지정

네트워킹은 CloudFormation 으로 생성한 네트워크를 지정해 줘야 한다.

AWS EKS Cluster 클러스터 엔드포인트 액세스
AWS EKS Cluster 클러스터 엔드포인트 액세스

클러스터 엔드포이트 액세스는 퍼블릭 및 프라이빗으로 선택한다. 그리고 Amazon VPC CNI 는 최신버전으로 선택.

AWS EKS Cluster 클러스터 로깅
AWS EKS Cluster 클러스터 로깅

CloudWatch Logs 는 비활성화해서 넘어간다. 단, 실제 서비스를 운영할때는 활성화를 해준다. 적어도 Authenticator 정도는 해준다.

Install & Setup IAM Authenticator and Kubectl Utility

설치 aws-iam-authenticator 문서를 보고 authenticator 를 설치해 준다.

iam authenticator
ZSH
1
2
3
4
5
6
7
8
]$
$ curl -o aws-iam-authenticator https://amazon-eks.s3.us-west-2.amazonaws.com/1.18.9/2020-11-02/bin/linux/amd64/aws-iam-authenticator
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 33.6M  100 33.6M    0     0  2763k      0  0:00:12  0:00:12 --:--:-- 3229k
$ chmod +x ./aws-iam-authenticator
$ mv -vv aws-iam-authenticator ~/.local/bin/
renamed 'aws-iam-authenticator' -> '/home/sbhyun/.local/bin/aws-iam-authenticator'

AWS EKS 를 위한 kubectl 명령어를 다운로드 받는다.

AWS 를 위한 kubectl 다운로드
ZSH
1
2
3
4
5
6
7
8
9
10
]$
$ curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.19.6/2021-01-05/bin/linux/amd64/kubectl
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.4M  100 57.4M    0     0  3116k      0  0:00:18  0:00:18 --:--:-- 6107k
$ chmod +x kubectl
$ mv -vv kubectl ~/.local/bin/
renamed 'kubectl' -> '/home/sbhyun/.local/bin/kubectl'
$ kubectl version --short --client
Client Version: v1.19.6-eks-49a6c0

설치된 Client 버전과 AWS EKS 에서 버전이 같은지 확인한다.

이제 kubectl 명령어가 사용되는지를 확인해 본다.

AWS kubectl 사용확인
ZSH
1
2
3
]$
]$ kubectl get svc
The connection to the server localhost:8080 was refused - did you specify the right host or port?

접속을 위한 아무런 정보가 없기 에 localhost 에 접속을 시도했다.

AWS kubectl 접속정보
ZSH
1
2
3
]$
]$ aws eks --region ap-northeast-2 update-kubeconfig --name eks-cluster
Added new context arn:aws:eks:ap-northeast-2:1111111111111:cluster/eks-cluster to /home/systemv/.kube/config

접속을 위한 정보를 받아서 $HOME 에 .kube/config 에 저장이 된다. 이제 잘되는지 다음과 같이 확인해 보자.

kubectl 로 AWS Cluster 확인
ZSH
1
2
3
]$  kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   6m49s

위와같이 나오면 정상이다. 만일 위와같이 나오지 않는다면 Role 를 지정해줄 수도 있다.

kube 설정파일을 Role 지정 업데이트
ZSH
1
aws eks --region ap-northeast-2 update-kubeconfig --name eks-cluster --role-arn arn:aws:iam::11111111111111:role/systemv-ekscluster-role

이렇게 했는데도 안된다면 다음의 링크가 도움이 될지 모른다.

정상적으로 작동한다면 다음과 같이 Node 는 아무것도 안나올 것이고 Namespace 는 나올 것이다.

kubectl get nodes,ns
ZSH
1
2
3
4
5
6
7
8
$ kubectl get nodes
No resources found
$ kubectl get ns
NAME              STATUS   AGE
default           Active   20m
kube-node-lease   Active   20m
kube-public       Active   20m
kube-system       Active   20m

Create IAM Role for EKS Worker Nodes

EKS Cluster 는 Kubernetes 에서는 Master 작업이 끝난것이라고 보면 된다. 아직은 Work Node 가 없다. Work Node 는 NodeGroup 으로 묶여서 생성되고 Work Node 를 위한 Role 이 필요하다.

AWS Role for EKS WorkNodes
AWS Role for EKS WorkNodes

이와 더블어서 ssm.amazonaws.com, eks.amazonaws.com 을 신뢰관계에 추가 해준다.

많은게 필요가 없다. 이제 worknode 를 위한 group 를 생성해 보자.

AWS EKS WorkGroup 생성하기 - 기본정보 입력
AWS EKS WorkGroup 생성하기 – 기본정보 입력

이름과 역할을 지정해준다. 역할은 앞에서 생성한 역할이 자동으로 나올 것이다.

AWS EKS Workgroups 생성하기 - 컴퓨터 자원 생성
AWS EKS Workgroups 생성하기 – 컴퓨터 자원 생성

서비스 운영을 위한 시스템 자원을 선택해 준다. 이 시스템 작원은 물리적인 하드웨어를 선택하는 것이다. 이 자원 위에서 Docker 를 기반으로 Micro Service 가 돌아가게 된다.

AWS EKS Workgroups 설치하기 - 네트워크 설정
AWS EKS Workgroups 설치하기 – 네트워크 설정

서브넷은 AWS EKS 를 위한 서브넷을 선택되어 있어야 한다. 노드에 대한 액세스가 필요할 경우에 해주면 되고 보안 그룹은 기본보안 그룹(22 port 만 열려 있다)을 선택해 줬다. 서비스를 운영할때에는 적절하게 바꿔준다.

생성이 완료되면 다음과 같이 Node 가 나오게 된다.

kubectl get nodes
ZSH
1
2
3
4
$ kubectl get nodes
NAME                                                 STATUS   ROLES    AGE     VERSION
ip-192-168-187-113.ap-northeast-2.compute.internal   Ready    <none>   7m51s   v1.19.6-eks-49a6c0
ip-192-168-246-188.ap-northeast-2.compute.internal   Ready    <none>   8m      v1.19.6-eks-49a6c0

이것이 Kubernetes 에서 Master, Work node 작업이 완료된것과 같은 AWS EKS Cluster 가 세팅이 완료가 된 것이다.

이 글은 초기버전이다. 큰 틀에서 대충 이렇게 한다는 것을 보여주는 것 외에는 깊이가 없다.

Nginx 액세스 로그를 CloudWatch Logs Agent 로 보내기

이 글은 다음의 글을 번역한 것입니다. 저작권은 원작자에게 있습니다.

최근에 나는 Ubuntu 18.04 에서 CloudWatch Logs 를 어떻게 설정하는지에 대한 글을 썼다. 그 글에서 나는 Agent 가 */var/log/syslog* 를 CloudWatch Logs로 syslog log 파일을 푸쉬하도록 설정했다. 이전 글을 보고 여기로 오길 바라고 혹시나 여러분이 Ubuntu 를 사용하지 않는다면 여러분이 사용하는 OS 에 CloudWatch Logs Agent 를 설치하기 위해서 AWS 문서를 체크해야 한다.

여기서 나는 Nginx 의 액세스 로그(access log) 와 에러 로그(Error log) 를 AWS CloudWatch Logs Agent 를 통해서 CloudWatch Logs 로 어떻게 전송하는지를 보여줄 것이다.

우리는 에이전트가 소비하기 원하는 두개의 Nginx 로그 파일을 가진다고 가정하자: */var/log/nginx/access.log* 와 */var/log/nginx/error.log* 로 원하는 만큼 많은 Nginx 로그를 추가할 수 있다.

AWS CloudWatch Logs Agent 는 *amazon-cloudwatch-agent.json* 파일로부터 설정들을 가지고 오고 이것은 Ubuntu 에서 */opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json* 위치해 있다.

이미 파일이 그곳에 있을거라 생각하고 collect_list 배열 아래쪽에 다음을 추가하면 된다.

AWS CloudWatch Logs Agent 설정
Default
1
2
3
4
5
6
7
8
9
10
11
12
{
  "file_path": "/var/log/nginx/access.log",
  "log_group_name": "web-server-log-group",
  "log_stream_name": "{hostname}/access.log",
  "timestamp_format" :"[%d/%b/%Y:%H:%M:%S %z]"
},
{
  "file_path": "/var/log/nginx/error.log",
  "log_group_name": "web-server-log-group",
  "log_stream_name": "{hostname}/error.log",
  "timestamp_format" :"[%d/%b/%Y:%H:%M:%S %z]"
}

여기서 핵심은 Nginx 로그 파일에서 timestamp_format 과 일치하는 포맷을 찾는다는 것이고, 만약 Ubuntu 에서 Nginx 에 기본 로깅 설정을 사용중이라면 위 설정은 잘 맞는다.

또 log_group_name 이 CloudWatch Logs Agent 의 자격증명에 로그 스트림 생성을 위한 logs:CreateLogSteam, 로그 스트림 기술을 위한 logs:DescribeLogStream 그리고 로그 이벤트를 푸쉬하기 위한 logs:PutLogEvents 의 IAM 허가권을 가지는 로그 그룹과 일치하는지 확인해봐야 한다.

amazon-cloudwatch-agent.json 파일을 업로드 한 후에 agent 서비스를 재시작해줄 필요가 있다:

AWS CloudWatch Logs Agent 재시작
Shell
1
service amazon-cloudwatch-agent restart

곧바로 CloudWatch Logs 에서 Nginx 로그들이 표시된다.

Ubuntu 18.04 LTS 에 CloudWatch Logs Agent 설정하기

이 글은 다음의 글을 번역한 것입니다. 저작권은 원작자에게 있습니다.

AWS CloudWatch Logs Agent 는 서버로부터 AWS CloudWatch Logs 서버로 로그를 전송하기 위해 설정될 수 있다. 이 문서에서, 나는 어떻게 Ubuntu 18.04 LTS 에 어떻게 설정하는지 보여줄 것이지만 여러분은 Ubuntu16.04 혹은 다른 운영체제 에서도 유사한 절차를 따를 수 있다. CloudWatch Logs Agent 는 Windows Servers 에서 EventViewer 로그를 수집하기 위해 설정할 수도 있다.

아주 좋은것은 여러분이 AWS EC2 를 실행하지 않는다고 하더라도, Azure, Google Cloud, Linode, Digistal Ocean 등과 같이 어떤 서버든지 이 기술을 사용할 수 있다는 점이다. 이 문서는 여러분이 따라하기에 쉬운 간단한 샘플이다.

여러분은 이러한 절차를 설정관리 스크립트로 손쉽게 만들거나 자신만의 Docker 이미지 사용을 위해 Dockerfile에 추가할 수 있어야 한다.

Download / Install the Debian Package

AWS 는 그들의 문서에 CloudWatch Logs Agent 데미안 패키지 위치를 기술하고 있고 우리는 curl 을 이용해 다운로드하고 실행하면 된다.

amazon-cloudwatch-agent 다운로드 및 설치
ZSH
1
2
3
4
#download it
curl -o /root/amazon-cloudwatch-agent.deb https://s3.amazonaws.com/amazoncloudwatch-agent/debian/amd64/latest/amazon-cloudwatch-agent.deb
#install it
dpkg -i -E /root/amazon-cloudwatch-agent.deb

이 문서의 모든 명령어는 sudo 를 사용허거나 root 사용자로 실행하는 것으로 한다.

Add cwagent User to adm group

다음으로 우리는 설치 프로그램이 생성한 cwagent 리눅스 사용자 계정을 Ubuntu 시스템 로그들에 읽기 허가권을 주기 위해서 adm 그룹에 추가하는 수정작업을 할 것이다.

amazon-cloudwatch-agent를 위한 계정 생성
ZSH
1
usermod -aG adm cwagent

Setup an IAM User Account and Permissions

이제 우리는 여러분의 AWS 계정에 CloudWatch Logs 에 로그 데이터를 전송하기 위해 Ubuntu 서버에 허가권을 부여할 필요가 있다.

만약 AWS EC2 운영하고 있다면, 이 과정을 건너뛰고 Assumed Role 를 사용해라. 하지만 IAM 허가권을 가진 Assumed Role 이 있는지 확인할 필요가 있다.

AWS Console 에서 IAM 사용자를 생성하고 AWS accessID 와 AWS secretKey 를 기록하고 여러분의 Ubuntu 서버에서 다음과 같이 /home/cwagent/.aws/credentials 파일을 생성하십시오.

Amazon 서비스 접속키 설정
INI
1
2
3
[AmazonCloudWatchAgent]
aws_access_key_id = aaaaaaaa
aws_secret_access_key = bbbbbbbb

또, 다음과 같이 /home/cwagent/.aws/config 파일을 생성하십시오

Amazon 서비스 접속 설정
INI
1
2
3
[AmazonCloudWatchAgent]
output = text
region = us-east-1

AWS console 에서 만든 새로운 IAM user 의 aws_access_key_id 와 aws_secret_access_key 를 사용해야 해야하며 region 또한 정확하게 지정해야 한다. 다음과 같이 /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml 에 추가함으로써 인증을 위해 CloudWatch Logs Agent 가 여기를 바라보도록 한다.

amazon-cloudwatch-agent 설정
ZSH
1
2
echo "[credentials]" >> /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml
echo '    shared_credential_file = "/home/cwagent/.aws/credentials"' >> /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml

Create a Log Group

어떻게 로그들을 구성하길 원하는지에 대해서 잠깐 동안 생각해봐야 한다. CloudWatch Logs 는 Log Groups 과 Logs Streams 개념을 제공한다. 로그 그룹을 로그별로 다이나믹하게 생성하거나 하나의 로그 그룹에 모든 서버 로그들을 사용할지와 같은 것이다. 이 문서에서 우리는 hostname.example.com/syslog 와 같은 로그 스트림을 생성하는 여러 서버에 대한 로그를 가질 수있는 하나의 로그 그룹을(web-server-log-group) 생성할 것이다.

나는 단일 로그 그룹에 스트림을 생성하고 로그를 출판하기 위한 접근만 제공하기 위해 IAM 허가권을 제한할 수 있기 때문에 이러한 접근방법을 선호한다.

Grant the IAM User / Role Permission to Publish Logs

web-server-log-group 으로 명명된 로그 그룹을 가지고 있다고 가정하고 이전 절차에서 생성한 IAM user에 IAM 정책(Policy) 를 붙일 것이다. 만약 EC2 를 운영중이라면 Assumed Role 에 이 정책을 붙일 수 있다.

IAM Role 설정
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchLogAgentPutForWebServerLogGroup",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:DescribeLogStreams",
        "logs:PutLogEvents"
      ],
      "Resource": [
        "arn:aws:logs:us-east-1:1234567890:log-group:web-server-log-group",
        "arn:aws:logs:us-east-1:1234567890:log-group:web-server-log-group:*:*"
      ]
    }
  ]
}

주의해야 할 것은 숫자 1234567890 는 여러분의 AWS account id 로 바꿔야 한다. 만약 CPU, Memory, Network, Disk 와 같은 서버 메트릭 데이터를 CloudWatch Logs Agents 가 출판하길 원한다면 다음과 같이 cloudwatch:PutMetricData 허용을 위해 추가적인 정책을 붙일 필요가 있다.

서버 매트릭 출판을 위한 IAM Role 설정
Default
1
2
3
4
5
6
7
8
9
10
11
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchPutMetricData",
      "Effect": "Allow",
      "Action": "cloudwatch:PutMetricData",
      "Resource": "*"
    }
  ]
}

나도 리소스(Resource)에 대해 와이들카드(*) 를 사용하는 대신에 좀더 제한적일 수 있는지 좀 더 찾아봐야 한다.

또, AWS 는 여러분이 사용할 수 있도록 CloudWatchAgentServerPolicy 으로 명명된 이미 만들어진 정책을 제공한다. 하지만 개인적으로 이건 조금 과도한 허가권이라 생각한다. 이것은 Agent 가 새로은 로그 그룹과 모든 로그 그룹에 로그를 출판하도록 서버에 허가한다.

Telling CloudWatch Logs Agent Which Log Files to Collect

AWS CloudWatch Logs Agent 는 위자드(Wizard) 를 통해서 json 설정 파일 생성을 위해 실행할 수 있는 툴을 가지고 있다:

Wizard를 이용한 설정
ZSH
1
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

아니면 이 위치에: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json 수동으로 JSON 파일을 생성할 수 있는데 다음과 같다.

amazon-cloudwatch-agent 설정
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "cwagent",
    "credentials_path":"/home/cwagent/.aws/credentials"
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/syslog",
            "log_group_name": "foundeo-web",
            "log_stream_name": "{hostname}/syslog",
            "timestamp_format" :"%b %d %H:%M:%S"
          }
        ]
      }
    }
  }
}

이것은 Ubuntu 서버의 /var/log/syslog 의 내용을 AWS CloudWatch Logs 서비스로 출판 한다. 여기에 nginx 로그를 CloudWatch Logs로 전송하는 예제가 있다.

Enable and Start the CloudWatch Logs Agent service

마지만 단계로 AWS CloudWatch Logs Ubuntu 서비스를 활성화 해주고 서비스를 시작해준다. 이것은 다음의 두개 명령어로 실행할 수 있다.

amazon-cloudwatch-agent 서비스 시작
ZSH
1
2
systemctl enable amazon-cloudwatch-agent.service
service amazon-cloudwatch-agent start

AWS CDK 개발 환경 구축하기

이 문서는 AWS CDK 개발 환경 구축에 대한 글이다. AWS CDK 는 코드로 AWS 자원을 관리하게 해주는 것으로 Infrastructure As Code 에 부합한다. 이를 사용하기 위해서는 환경 구축이 필수이기에 이를 기록한다.

구축 환경

AWS CDK 는 몇가지 언어를 지원 한다. 나는 Python 을 사용할 것임으로 Python 관련된 설정도 필수다. 그런데, Python 을 사용해보면 알겠지만 Windows 플랫폼 보다는 Unix 스타일의 플랫폼이 적합하다는 것을 알게 된다. 따라서 구축 환경은 다음과 같이 정했다.

  • OS: Mint Linux 19.3 Tricia XFCE
  • Python3

한가지 더 있다. Python3 을 사용할 경우에 AWS SDK 등을 모두 설치해야 한다. 하지만 Python 은 캡슐화를 지원한다. Virtualenv 가 바로 그것인데, 모든 것을 Virtualenv 환경으로 구축을 할 예정이다.

PreRequirement

이제 본격적으로 구축을 해보자. 이를 위해서 필수 프로그램이 필요한데, 이는 다음과 같다.

  • npm (Node)

이는 다음의 URL 을 명시되어 있다.

Node, npm 설치

npm 을 기반으로 한다고 문서에 나와 있다. 따라서 npm 을 설치해 줘야 한다. npm 은 Node.js 기반이며 Node.js 를 설치하는 방법은 다양하지만 이전에 이에 대해서 기술한 문서가 이미 있기에 다음을 참고 했다.

주의할 것은 AWS 의 문서에 나와 있다시피 LTS 버전을 설치해줘야 한다. AWS 문서에 나와 있듯이 CDK 를 설치해 준다.

AWS-CDK&nbsp;설치&nbsp;
ZSH
1
2
3
4
5
]$ npm install -g aws-cdk
/home/systemv/.nvm/versions/node/v12.15.0/bin/cdk -> /home/systemv/.nvm/versions/node/v12.15.0/lib/node_modules/aws-cdk/bin/cdk
+ aws-cdk@1.23.0
added 234 packages from 227 contributors in 11.018s
]$ cdk --version

Python3 환경 구축

Python3 에도 필요한 것이 있는데, distutils 패키지 이다. 이것은 우분투 패키지로 설치를 해줘야 한다. 다음과 같이 설치를 해준다.

Python3&nbsp;의존성&nbsp;라이브러리&nbsp;설치
ZSH
1
]# apt install python3-distutils

이것을 설치해야지만 python3 을 로컬 계정에서 환경을 구축할 수 있다. 다음과 같이 pip 를 설치해 준다.

Python3&nbsp;캡슐환경&nbsp;설치
ZSH
1
2
3
]$ wget https://bootstrap.pypa.io/get-pip.py
]$ python3 get-pip.py --user
]$ .local/bin/pip3 install virtualenv

virtualenv 를 설치하고 난 후에 이제 캡슐환경을 만들어준다. 그냥 .python3 으로 만들어준다.

Python3&nbsp;캡슐환경&nbsp;활성화
ZSH
1
2
3
4
5
6
7
8
9
]$ virtualenv .python3
]$ .local/bin/virtualenv .python3
Using base prefix '/usr'
New python executable in /home/systemv/.python3/bin/python3
Also creating executable in /home/systemv/.python3/bin/python
Installing setuptools, pip, wheel...
done.
]$ source .python3/bin/activate
(.python3) $

여기서 이제 AWS CLI 와 기타 몇가지를 함께 설치해준다. 이는 Python3 에 패키지로 존재함으로 pip 명령어를 이용해서 설치하면 된다.

Python3&nbsp;캡슐환경에&nbsp;aws-sam-cli&nbsp;설치
ZSH
1
(.python3) $ pip install awscli aws-toolkit aws-sam-cli

이로써 필수 프로그램 설치는 다 됐다.

VS Code 설정

이제 Editor 설정을 해야 한다. VS Code 라면 AWS CDK 를 사용하는데 부족함이 없다. 데스크탑 리눅스를 사용함으로 VS Code 에서 우분투 패키지를 다운로드해 설치하면 된다.

Color Themes

좋은 Color Themes 가독성을 높여줘 프로그래밍을 하는데 많은 도움이 된다. 내가 주로 사용하는 Color Themes 는 다음과 같다.

  • Ayu
  • Primal

물론, 이건 지극히 개인적인 것임으로 검색을 통해서 자신에게 맞는 Color Themes 를 찾으면 된다.

Python Extension 설정

VS Code 가 Python 을 지원하도록 해야 한다. 이를 위해서 Python Extension 을 설치하고 다음과 같이 설정을 해준다. 그리고 다음과 같이 pip 를 이용해서 프로그램을 설치해준다.

Python3&nbsp;캡슐환경에&nbsp;의존성&nbsp;라이브러리&nbsp;설치
ZSH
1
(.python3) $ pip install pycodestyle pydocstyle pylint pytest autopep8 black cfn-lint

AWS Toolkit for Visual Studio Code

AWS Tookit Extension 을 설치해 준다. 별도의 설정은 해주지 않아도 된다.

Indenticator, indent-rainbow

Python, Yaml 문법의 특성상 Indent 를 기반으로 문법 체크를 하는데 이 Extension이 도움이 된다.

Sort lines

라인을 알파벳 순, 숫자순으로 정렬을 해준다.

vscode-cfn-lint

cfn 는 CloudFormation 을 말한다. CloudFormation 문법을 체크해 준다.

YAML Support by Red Hat

CloudFormation 은 YAML 문법을 따른다. 이 문법을 체크해 준다.

Cloudformation YAML snippets for VS Code

코딩을 할때에 필요한 코드 조작을 넣어준다.

Better Comments

주석에 색깔을 입혀서 가독성을 높여준다.

이렇게 설치한 Extension 에 대한 설정값은 다음과 같다.

VSCode&nbsp;Extension&nbsp;설정
Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
{
    "workbench.colorTheme": "Ayu Mirage",
    "workbench.iconTheme": "material-icon-theme",
    "python.venvPath": "~/.python3",
    "python.testing.pytestEnabled": true,
    "python.venvFolders": [
        ".python3"
    ],
    "python.pythonPath": "~/.python3/bin/python3",
    "python.autoComplete.extraPaths": [
        "~/.python3/lib/python3.6",
        "~/.python3/lib/python3.6/site-packages"
    ],
    "python.formatting.provider": "black",
    "python.formatting.blackArgs": [
        "--line-length",
        "100"
    ],
    "editor.formatOnSave": true,
    "python.linting.pylintEnabled": true,
    "python.linting.lintOnSave": true,
    "python.linting.enabled": true,
    "indenticator.inner.showHighlight": true,
    "indentRainbow.includedLanguages": [],
    "indentRainbow.excludedLanguages": [
        "plaintext"
    ],
    "indentRainbow.updateDelay": 100,
    "cfnLint.path": "~/.python3/bin/cfn-lint",
    "yaml.validate": false,
    "yaml.customTags": [
        "!And",
        "!And sequence",
        "!If",
        "!If sequence",
        "!Not",
        "!Not sequence",
        "!Equals",
        "!Equals sequence",
        "!Or",
        "!Or sequence",
        "!FindInMap",
        "!FindInMap sequence",
        "!Base64",
        "!Join",
        "!Join sequence",
        "!Cidr",
        "!Ref",
        "!Sub",
        "!Sub sequence",
        "!GetAtt",
        "!GetAZs",
        "!ImportValue",
        "!ImportValue sequence",
        "!Select",
        "!Select sequence",
        "!Split",
        "!Split sequence"
    ]
}

AWS Credential 세팅

Python3 에 가상환경에서 aws configure 명령어를 이용해서 접속을 위한 credential 을 만들어준다.

AWS&nbsp;접속&nbsp;설정
ZSH
1
2
3
4
5
(.python3) ]$ aws configure --profile
AWS Access Key ID [None]: *********************
AWS Secret Access Key [None]: ******************************
Default region name [None]: ap-northeast-2
Default output format [None]:

이로써 AWS CDK 를 위한 VS Code 설정을 기술했다. 정답은 없다. 개인적으로 사용하는 설정을 기반으로 보다 좋은 방법, 환경을 위한 설정이 있을 것이다.

Ansible, ec2.py 를 이용한 Dynamic Inventory 활용

Ansible 에는 접속 정보와 관련된 정보들을 Inventory 라고 부른다. 접속 호스트, 접속 계정 정보뿐만 아니라 이들을 그룹으로 묶거나 변수 설정도 가능하다.

그런데, 클라우드 시스템과 같이 서버 관련 정보를 API 형식으로 제공할 경우에 일일이 호스트 정보를 파일로 저장할 필요가 없다. 클라우드 시스템에 서버 관련 정보를 호출하며 자동으로 Inventory 정보가 생성되는 기능을 제공하는데 이를 Dynamic Inventory 라고 한다. 이 기능은 클라우드 뿐만 아니라 LDAP 과 같은 인증 시스템에도 활용가능하다.

Ansible 세팅

AWS 클라우드의 Dynamic Inventory를 활용하기 위한 Ansible 을 세팅해 보자. 가장 중요한 ansible.cfg 는 다음과 같다.

Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
[defaults]
inventory      = ~/.ansible/inventories/production/ec2.py
library        = ~/.ansible/library
module_utils   = ~/.ansible/module_utils
roles_path     = ~/.ansible/roles
#remote_tmp     = ~/.ansible/tmp
local_tmp      = ~/.ansible/tmp
#plugin_filters_cfg = /etc/ansible/plugin_filters.yml
#forks          = 5
#poll_interval  = 15
remote_user    = ec2-user
sudo_user      = root
#ask_sudo_pass = True
#ask_pass      = True
transport      = smart
remote_port    = 22
 
host_key_checking = False
 
[privilege_escalation]
become=True
become_method=sudo
become_user=root
become_ask_pass=False

특별히 inventory 에는 AWS 클라우드에 제공하는 Dynamic Inventory 스크립트 위치를 지정해준다. ansible 을 이용한 접속 정보, 실행할 계정에 대한 정보등을 기재한다.

디렉토리는 구조는 대략 다음과 같다.

Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ tree
├── ansible.cfg
├── filter_plugins
├── inventories
│   └── production
│       ├── ec2.ini
│       ├── ec2.py
│       ├── group_vars
│       │   └── tag_Service_jmeter_server.yml
│       ├── hosts
│       └── keypairs
│           └── test-server.pem
├── library
├── module_utils
├── roles
└── tmp

AWS 클라우드 Dynamic Inventory 파일

AWS 클라우드의 경우에도 Ansible 의 Dinamic Inventory 기능을 제공한다. 작동원리는 AWS 자원 정보를 불러오고 이것을 Ansible 이 인식하는 Inventory 정보를 구성하는 것이다. AWS 자원 정보를 불러오기 위해서 AWS 는 다음과 같은 스크립트와 환경설정 정보를 제공한다.

ec2.py 는 AWS 클라우드 시스템에 호스트 관련 정보를 불러오도록 한다. ec2.ini 는 어디, 어떤 정보를 불러올 건지 어떤 내용을 출력할 것인지를 지정할 수가 있다. 예를들면 다음과 같다.

Default
1
2
3
4
5
regions = ap-northeast-2
vpc_destination_variable = private_ip_address
route53 = False
rds = False
elasticache = False

regions 이 기본값은 all 이다. 이러면 모든 리전에 대해서 호스트 정보를 수집할려고 하기 때문에 시간이 오래걸리는 문제가 발생한다. 특정한 리전에 대해서만 수행하도록 지정하는 것이 좋다.

IAM 설정

가장 중요한것이 IAM 설정이다. Ansible 을 실행하는 서버에는 호스트 정보를 불러올수 있는 IAM 권한이 필요하다. 보통 IAM Role 지정이라고 하는데 대략 다음과 같은 Policy 를 만들어 Role 적용을 하면 된다.

Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*",
                "elasticache:Describe*",
                "rds:Describe*",
                "route53:ListHostedZones",
                "route53:ListResourceRecordSets"
            ],
            "Resource": "*"
        }
    ]
}

Access Key, Secret key 를 이용하는 방법도 있지만 권장하지 않는다.

ec2.py 테스트 및 특징

이제 요건이 갖춰졌으니 테스트를 해보자.

Default
1
2
3
4
5
6
7
8
9
10
11
12
13
$ ec2.py --list
  "tag_Name_com_jenkins_master": [
    "10.18.198.155"
  ],
  "tag_Name_com_linux": [
    "10.18.198.172"
  ],
  "tag_Name_com_nat1": [
    "10.18.198.205"
  ],
  "tag_Name_com_nat2": [
    "10.18.198.209"
  ],

내용을 보면 위와같은 key 값들을 보게 된다. 집작했겠지만 ec2.py 는 ec2 인스턴스의 tag 를 key 로 지정해준다. tag 뿐만 아니라 ec2 인스턴스의 정보를 key 만들어준다.

이 key들은 Ansible Inventory 의 group 변수로 활용이 가능하다.

ec2 key pair 를 이용한 접속 정보 만들기

ec2.py 에서 key 들은 곧바로 Ansible 의 group 으로 활용 가능하다. 이를 위해서 inventory/production/group_vars 디렉토리에 key 이름으로 yaml 파일을 생성한다. 그리고 다음과 같이 내용을 입력한다.

Default
1
ansible_ssh_private_key_file: ~/.ansible/inventories/production/keypairs/test-server.pem

Ansible이 그룹 접속을 할때에 위 변수를 활용하게 된다. AWS 클라우드 ec2 접속하기 위한 keypair 를 이용하는데 따른 설정이다.

접속 테스트

이제 다 됐다. 다음과 같이 접속 테스트를 한번 해본다.

Default
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ ansible tag_Service_jmeter_server -m ping
[DEPRECATION WARNING]: The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on
deprecation. This feature will be removed in version 2.10. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[WARNING]: Invalid characters were found in group names but not replaced, use -vvvv to see details
 
[WARNING]: Platform linux on host 10.18.193.62 is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter could change
this. See https://docs.ansible.com/ansible/2.8/reference_appendices/interpreter_discovery.html for more information.
 
10.18.193.62 | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": false,
    "ping": "pong"
}

위와같이 나오면 성공한 것이다.

AMAZON S3 버킷 램덤화 객체 접두사 불 필요.

과거에 AMAZON S3 버킷 성능 끌어올리기 라는 글을 통해서 S3를 사용하는데 있어서 성능향상 방법에 대해서 설명한 적이 있다. 핵심은 객체 접두사를 램덤화해서 S3에 올라가는 파일들이 균일하게 넓게 퍼질 수 있도록 해야한다는 것이였다.

하지만 2018년 7월 17일에 AWS 에서는 S3에 성능향상을 언급하면서 이제 객체 접두사의 랜덤화는 불필요하다고 말했다.

Amazon S3, 요청 처리 성능 개선 발표

이 같은 S3 요청 처리 성능 향상으로 인해 객체 접두사를 랜덤화하여 더 빠른 성능을 실현하라는 이전의 지침은 더 이상 적용되지 않습니다. 즉, 이제 성능 저하 없이 S3 객체에 논리적 또는 순차적 명명 패턴을 사용할 수 있습니다. 이 성능 향상은 이제 모든 AWS 리전에서 제공됩니다. 자세한 내용은 Amazon S3 개발자 가이드를 참조하십시오.

이제 S3 버킷에서 객체를 저장할때 접두사를 램덤화하려는 고민을 하지 않아도 된다.

외부MySQL 에서 AWS Aurora로 마이그레이션

데이베이스 이전은 매우 중요한 작업이다. 다른 IT 인프라와는 다른 속성을 가진 데이터베이스를 물리적 공간도 다른 곳에 옮기기는 쉬운 일이 아니다. 더군다나 데이터베이스는 모든 IT 비지니스에 핵심으로 사업 성공에 성패를 가르기도 한다.

AWS 를 사용하다보면 데이터베이스 이전 작업을 종종 겪게 된다. 처음부터 AWS 에서 제공하는 DaaS 인 RDS, Aurora 를 사용한다면 별 걱정이 없겠지만 AWS도 아닌 일반 IDC 의 데이터베이스를 AWS RDS, Aurora 로 옯기기는 매우 힘든 작업이다.

외부 MySQL 에서 RDS로 마이그레이션 하기
외부 MySQL 에서 RDS로 마이그레이션 하기

한마디로 말하면 답이 없는 작업이다. AWS 의 모범사례를 보면 이렇게 외부에MySQL 데이터베이스가 존재할 경우에 mysqldump 명령어를 이용해서 데이터를 Export 한 다음에 AWS RDS, Aurora 에 데이터를 Import 하고 외부MySQL(Master) – AWS RDS,Aurora(Slave) 로 묶어 둔 후에 Application 에서의 작업을 통해서 최종적으로 AWS RDS Aurora 만 사용하도록 하고 있다.

외부MySQL 과 RDS 의 리플리케이션 연결
외부MySQL 과 RDS 의 리플리케이션 연결

문제는 용량이다. 만일 외부MySQL 데이터베이스의 용량이 10TB, 아니 4TB 라고 해보자. 그러면 4TB 를 덤프 뜨는 시간이 얼마나 걸릴지 예상하기도 쉽지 않다. MySQL 은 데이터를 덤프 뜨는 동안 테이블을 잠그기 때문에 그동안 서비스를 중단해야 한다.

서비스 중단없이 어떻게 데이터 이전을 할것인하는 건 모든 사업자라면 하는 고민일 것이다.

Netflix 도 이에 대한 고민을 했던 것으로 보인다. 더군다나 외부데이터베이스 시스템이 Oracle 이고 이전하고자하는 데이터베이스가 MySQL 이라면 데이터 변환작업도 함께 진행되어야 한다. 거기다 무중단 서비스…

Netflix 의 이러한 고민은 다음의 기사로 나왔는데, 결론은 Oracle 의 Golden Gate 를 이용했다는 것이다. OGG 라고 불리우기도하는데, 개인적인 경험으로 매우 훌륭한 툴이다. OGG 와 같은 동일한 역할을 하는 소프트웨어가 여럿 존재할 것이다.

핵심은 외부 데이터베이스를 AWS 로 이전하려고 할 경우에 서비스 무중단을 원한다면 OGG 와 같은 프로그램을 이용하는게 답이라는 거다.

만일 무중단 데이터 이전을 자체적으로 하기 힘들다면 국내에 데이터베이스 기술지원을 하는 업체를 돈을 들여서라도 이용하는 편이 낫다. 괜히 능력도 안되는데 의지만 앞선 나머지 일을 진행하다가 데이터 손실이라도 발생하면 사업에 아주 심각한 영향을 줄것이기에 데이터베이스 만큼은 확실한 방법이 요구된다.

AWS Aurora Endpoint and WAS Connection Pool

Abstract

AWS Aurora 는 DB Cluster 로 구현된다. DB Cluster 는 Aurora 인스턴스와 Endpoint 를 포함한 일종의 그룹 개념이다. 이 DB Cluster 에는 1개의 Primary 인스턴스와 15개의 Replica 를 가질 수 있다.

각각의 구성에서 접속이 가능한 지점은 다음과 같이 3가지가 있다.

  • Cluster Endpoint
  • Read Replica Endpoint
  • Instance Endpoint

이러한 Endpoint 와 Aurora 인스턴스 그리고 Primary, Replica 를 조합한 아키텍쳐는 다음과 같다.

AWS Aurora Architecture
AWS Aurora Architecture

Cluster Endpoint

Cluster Endpoint 는 Aurora Cluster 에서 현재 Primary 인스턴스에 접속하기 위한 Endpoint 이다. 모든 Aurora Cluster 는 반드시 하나의 Primary 인스턴스와 이를 연결하는 Cluster Endpoint 를 가진다.

Primary 인스턴스는 Insert, Update, Delete 그리고 DDL(Data Definition Language) 에 관한 모든 쓰기 연산을(write operation) 지원하며 데이터 읽기 연산인 Select 도 지원한다. Cluster Endpoint 는 read/write 를 연산을 제공하는 Primary 인스턴스 접속을 제공한다.

Cluster Endpoint 는 read/write 접속에 대한 자동 FailOver 를 제공한다. Primary 인스턴스에 문제가 발생하면 Replica 인스턴스 중 하나를 Primary 인스턴스로 선택한다. Cluster Endpoint 는 DNS 를 이용해 기존의 Primary 인스턴스의 도메인을 버리고 Replica 인스턴스로 변경한다. 이렇게 함으로써 Cluster Endpoint 도메인 주소는 변경없이 계속 유지 된다. Cluster Endpoint 에서 새로운 Primary 인스턴스로 지정된 Replica 인스턴스는 read/write 역할을 위해서 Primary 인스턴스로 승격된다.

Reader Endpoint

Reader Endpoint 는 Aurora Replica 중에 하나와 연결된다. Aurora Replica 는 읽기 연산(read operation) 만 지원하기 때문에 Reader Endpoint 는 읽기 전용 연결지점이 된다.

만일 Aurora Replica 가 한개 이상이라면 Reader Endpoint 는 Load Balancing 을 지원한다. 각각의 연결은 Round robin 방법으로 Replica 인스턴스 하나와 연결이 되어 연결에 따른 부하가 분산된다.

Instance Endpoint

Aurora DB 를 생성은 결국 Instance 를 생성하게 된다. 모든 Aurora 에 인스턴스는 Endpoint 를 가지는데 이게 Instance Endpoint 이다. 모든 Instance 는 타입과 관련없이 유일한 Instance Endpoint 를 가진다.

이 Instance Endpoint 는 도메인 이름으로 불변이며 Cluster Endpoint, Reader Endpoint 에 CNAME 으로 등록되어 이들의 연결지점으로 사용되어 진다.

WAS Connection Pool

이제 WAS 에서 AWS Aurora 접속을 위한 설정에 대해서 이야기 해보자. WAS 서버가 무엇이든 AWS Aurora 접속을 위해서는 MySQL, MariaDB Connector/j 드라이버를 사용해야 한다.

그런데, Aurora Cluster 를 구성할 경우에 Primary 인스턴스와 Replica 인스턴스로 구성하고 Endpoint 를 각각 Cluster, Reader 로 구성하게 될 것이다. 이렇게되면 WAS 에서는 이를 분산해서 접속해야 할 필요가 생긴다.

MySQL, MariaDB 는 이렇게 read/write 접속과 read only 접속을 분리해서 연결하도록 하는 기능을 제공하는데 이를 Smart Driver 라고 부른다.

한가지 먼저 짚고 넘어가자면, AWS Aurora 를 사용할 경우에는 MariaDB Connector/j 드라이버를 사용할 것을 권장하고 있는데, MariaDB Connector/j 드라이버는 Aurora 를 공식적으로 지원한다.

MariaDB Connector/j 드라이버를 이용해 Cluster Endpoint, Reader Endpoint 를 설정하는 방법은 다음과 같다. (Tomcat 기준 JNDI 설정이다)

Default
1
url="jdbc:mysql:aurora://aurora-demo1-cluster.cluster-xxxxxxx.us-east-1.rds.amazonaws.com:3306,aurora-demo1-cluster.cluster-ro-xxxxxxx.us-east-1.rds.amazonaws.com:3306"

이렇게 Cluster Endpoint, Reader Endpoint 주소를 연속해서 주면 된다. 이렇게하면 서버단에서 접속 설정은 끝이난다.

하지만, 이렇게 서버단에서의 설정만으로 접속이 분리되는 것은 아니다. Spring MVC 기준으로 말을 하자면 Transactional 의 ReadOnly 프로퍼티를 준 경우에만 Reader Endpoint 로 접속이 이루어지고 이외에는 전부 Cluster Endpoint 로 접속이 이루어진다.

Spring MVC 에서 이것을 각각 지정하기보다는 TX, AOP 설정을 통해서 한꺼번에 설정이 가능하다.

XHTML
1
2
3
4
5
6
7
8
9
10
11
12
<!-- required to connect Slave Server only for get* method on Aurora Replication  -->
<tx:advice id="txAdvice" transaction-manager="transactionManager">    
    <tx:attributes>      
        <tx:method name="*" propagation="REQUIRED" />    
        <tx:method name="get*" read-only="true" />    
    </tx:attributes>    
</tx:advice>    
        
<aop:config>    
    <aop:pointcut expression="execution (* com.systemv.service.*.*(..))" id="services" />      
    <aop:advisor advice-ref="txAdvice" pointcut-ref="services" />    
</aop:config>

위와같이 했을 경우에 get* 으로 시작하는 메소드 이름을 가진 Service 빈에서 Read-Only 속성을 부여해 Reader Endpoint 로만 접속하도록 하게 할 수 있다.

마지막으로 고려해야할 것이 한가지 더 있는데, Connection Pool 의 경우에는 접속/해제에 대한 오버헤드를 줄이기 위해서 미리 연결을 해놓는 경우인데, 만일 Aurora FailOver 기능을 사용할 경우에 기존의 Fail된 인스턴스와 연결을 계속 유지하는 경우가 생긴다.

Cluster Endpoint FailOver
Cluster Endpoint FailOver

Replica Role 이 승격되서 새로운 Primary Role 이 되면서 Read/Write 역할을 수행하게 되는데, 이때 Cluster Endpoint 의 DNS 의 CNAME 이 변경된다. 하지만 WAS 서버의 Connection Pool 은 장애가 발생한 기존 Primary Role 인스턴스를 가지고 있게 된다.

MariaDB Connector/J 드라이버에는 이를 위해서 SOCKET_TIMEOUT 값을 두고 있다. Aurora 의 경우에는 10000ms 로 10초 동안 접속이 이루어지지 않을 경우에 Socket Timetout 으로 간주해 FailOver 로직을 수행한다.

Socket Timeout 은 JDBC 드라이버 측에서 설정을 해줘야 한다. 이는 대부분 URL 에 파라메터로 지정하는데, 다음과 같이 할 수 있다.

Default
1
url="jdbc:mysql:aurora://aurora-demo1-cluster.cluster-xxxxxxx.us-east-1.rds.amazonaws.com:3306,aurora-demo1-cluster.cluster-ro-xxxxxxx.us-east-1.rds.amazonaws.com:3306?connectTimeout=10000&socketTimeout=10000"

MariaDB connector/J 에서 connectTimeout 기본값은 0이며 socketTimeout 의 경우 Aurora 일 경우 10000ms 로 되어 있다. 이정도면 MariaDB Connector/J 를 사용하는데 있어서 별도의 설정을 해주지 않아도 될 정도다.

AWS Aurora With MySQL

AWS Aurora(오로라) 는 AWS RDS 서비스 중에 하나 이다. 다른 RDS 서비스들은 기존 오픈소스, 상용 데이터베이스를 이용해 만든 반면에 Aurora 는 AWS가 자체 개발한 데이터베이스이다.

AWS RDS 는 Database-as-a-service (DBaaS) 인데, 이는 데이터베이스 관리에 많은 부분을 AWS가 알아서 해준다. 예를들면 데이터베이스 서버운영, 버그 패치, 이중화, 자동 FailOver등이며 웹 콘솔을 이용해 사용자의 각종 설정들을 처리해는 서비스다.

이 글은 AWS Aurora, 그중에서 MySQL Engine 에 대해서만 간단히 정리한 것이다. 이 글은 AWS Aurora 전부를 담고 있지 않음을 주의해야 한다.

Aurora MySQL Engine

Aurora 는 2가지 엔진(PostgreSQL, MySQL) 을 호환 엔진을 가진다. MySQL 호환 엔진의 경우에 MySQL 메이저 버전별로(MySQL 5.6, 5.7) 또 나뉜다.

Aurora MySQL 엔진을 이해하기 위해서 먼저 MySQL 를 간단히 살펴보자.

MySQL Architecture

기존의 MySQL 이중화 아키텍쳐는 다음과 같다.

MySQL With Replica On AWS
MySQL With Replica On AWS

AWS RDS MySQL 인데, 일반적인 MySQL 의 Replication 도 위와 동일 하다. 이 그림이 설명하는 특징은 다음과 같다.

  • MySQL 서버들은(Primary, Replica) 자신만의 Storage 를 가진다.
  • Storage 는 EBS Storage 이다.
  • Replica Instance 는 Primary Instance 로부터 Binary log 를 전송받아 이것을 Relay 해 데이터를 복제한다.

AWS RDS MySQL 서비스조차도 MySQL이 제공하는 복제방식을 그대로 사용했기 때문에 On-Demand 의 MySQL Replication 아키텍쳐와 동일하다.

이런 아키텍쳐 운영에서 문제는 추가적인 Replica 구성에 있다. 추가적인 Replica 를 더했을 경우에 기존 데이터를 전부 덤프를 뜨고 Restore 해준다음에 Position 값을 맞춰줘야 한다.

거기다 Replica가 바쁜 상태일때에 Binlog Relay가 느려지는 Replication Lag 현상도 문제다. Primary 에 추가된 레코드가 한참이 지나도록 Replica 에서 조회가 안될 수도 있다.

Aurora Architecture

AWS Aurora Architecture
AWS Aurora Architecture

AWS Aurora 아키텍쳐로 특징은 다음과 같다.

  • Storage 는 모든 인스턴스에 공유 된다. .
  • Storage 는 EBS 가 아닌 Distributed Virtual Volume Storage 다.
  • Redo Log 만 전송된다.
  • Pallarel Query 를 지원한다.

Aurora MySQL 특징

가장 큰 차이점을 살펴봤는데, 이외에도 몇가지 차이가 존재한다.

  • Multi-AZ 를 지원하지 않는다. – 오해의 소지가 있는데, 기존의 Multi-AZ 는 내부 StandBy 서버를 말했었다. 하지만 Aurora 는 Muti-AZ Deployment 를 할 경우에 내부 StandBy 서버 없이 Read Replica 가 AZ 로 생성되면서 이 역할을 대신한다. 용어의 혼돈이 존재하는 부분이다.
  • MySQL 의 Single thread connection 방식인데, Aurora MySQL 은 Dynamic 방식이다. 내부적으로 Epoll Multiplex 를 사용한다.
  • 사용할 Storage 용량을 정하지 않아도 된다. 10GB 씩 최대 64TB 까지 자동으로 늘어난다. (AWS RDS MySQL 의 경우 EBS 한계치인 16TB 까지다.)
  • Replica 에 대한 LoadBalancer 를 지원해 이중화를 지원한다. 이를 위해서는 읽기전용 Cluster Endpoint를 사용해야 한다.
  • FailOver 시에 Read Replica 중에 하나를 Primary Role 로 승격 시킨다. Primary Cluster Endpoint 를 사용하면 접속지점 변경이 없다.

중요한 특징들도 존재한다.

  • Aurora DB Cluster 역추적(Backtrack, 되감기)

보통의 DB 에서 특정 시점으로 되돌리기 위해서는 백업본을 이용해 Point-In-Time 복원을 수행해야 한다. AWS RDS 의 경우 특정 시점의 백업을 이용해 복원해 새로운 DB 클러스터를 만들어 내는데 이것이 Aurora DB 클러스터 백업 및 복원에 대한 개요 다.

Aurora DB Cluster 역추적은 백업/복원 과정이 아닌 데이터베이스를 특정시점으로 되감는 것이다. 새로운 DB 클러스터는 생성되지 않는다.

역추적 기능이 활성화된 상태에서 생성한 DB 클러스터에서만 역추적이 가능하다. (새 DB 클러스터를 만들 때, DB 클러스터의 스냅샷을 복원할 때, DB 클러스터를 복제할 때) 역추적 기능이 비활성화된 상태에서 생성한 DB 클러스터에서 역추적이 불가능 하다.

역추적이 활성화된 Aurora DB 클러스터를 업데이트하면 변경 레코드가 생성된다. Aurora은 대상 기간에 대한 변경 레코드를 보존하며 이 레코드를 저장하기 위해 시간당 요금을 지불한다.

  • Aurora Storage IOPs 는 오직 Aurora 의 인스턴스 타입에 따른다.

AWS RDS MySQL 의 경우에 EBS Storage 를 사용하기 때문에 IOPs 를 따로 결정할 수 있다. 하지만 AWS Aurora 의 경우에는 Storage 타입이 존재하지 않음으로 인해서 IOPs 는 인스턴스 타입에 따른다.

결과적으로 빠른 IOPs 가 필요하다면 Aurora 인스턴스 타입을 업그레이드 해줘야 한다.

  • Global Database 지원 – Region Replica 를 지원 한다.

Region 간 복제를 지원하는것인데, 현재 3개 지역만 지원한다.

  • Multi Master Replica

현재 Preview 단계에 있다. 언제 정식 서비스 될지는 모르지만 Preview로 맛을 볼수는 있다.

  • Free Tier 를 제공하지 않는다.

AWS Aurora 는 Free Tier 를 제공하지 않는다. 공자 사용 안된다는 이야기.

  • T2 타입에서 Performance Schema 활성화 안됨

적용 Capacity 를 가진 타입의 경우에 Performance Schema 활성화가 안된다.

AWS Aurora 비용

선택한 옵션에 따라서 추가 비용 부담이 있지만 기본적으로 가장 많은 비용이 들어가는 것으로는 다음과 같다.

  1. Storage I/O 요금 – 1백만 건당 0.22 USD
  2. 스토리지 요금 – 월별 GB 0.11 USD
  3. Global Database – 복제된 쓰기 I/O 백만 건당 0.22 USD

Storage I/O 요금을 주의해야 하는 것은 데이터 이관시다. AWS Aurora 로 데이터베이스를 바꿀려고 할 경우에 데이터를 부어야 하는데, 이때 대량의 Storage I/O 가 발생하게 되며 고 비용을 물어야 한다. – 처음부터 AWS Aurora 를 선택하는게 좋을 수 밖에..