DynamoDB를 알기 전에 기존의 데이터베이스 형태에 대해서 먼저 알아보자. 기존의 데이터베이스의 형태는 거의 대부분이 관계형 데이터베이스였다. 예를 들면 MySQL, PostgreSQL 등이 있다.
이런 관계형 데이터베이스의 가장 큰 특징은 데이터에 대한 형식이 아주 견고하게 존재한다는 것이다. 그래서 형식에 맞지 않는 데이터를 넣지 못한다. 그 말은 어떤 데이터를 넣더라도 예측 가능한 데이터가 된다. 그러나 이러한 점이 단점으로 부각되기 시작한다. 그 내용은 기업이 활용할 수 있는 데이터가 다양해지면서 데이터의 형식이 다양해지고 내용이 방대해졌다는 뜻이다. 그 말은 예측이 불가능한 데이터가 더 많아진다는 뜻이다.
그래서 이러한 단점(자유도가 떨어진다) 을 극복하기 위해 다른 방식의 데이터베이스가 생겨나기 시작했다.
즉, 어떤 정제가 되지 않은, 있는 그대로의 데이터를 모두 받아들일 수 있는 AWS S3와 같은 DataLake나 NoSQL(Not Only SQL)과 같은 데이터베이스가 점점 두각되는 추세이다. 이 NoSQL의 하나가 DynamoDB이다.
NoSQL은 말 그대로 SQL만을 취급하지 않는다는 것이다. 즉, 형식이 지정되어 있기도 하지만 지정되지 않은 상태여도 무방하다라는 뜻이다.
- Partition Key: Primary key는 아니지만 그와 비슷한 키를 의미한다. 중복이 될 수 있다.
- Sort Key: 또 하나의 키. 이 또한 중복이 될 수 있다.
- Primary Key: Partition Key + Sort Key. 이는 중복이 될 수 없다. 중복된 데이터가 들어오면 받아주지 않는다.
- GSI(Global Secondary Index): 아이템에 대한 키 역할을 하지는 않지만 인덱스(필터링하기 위한)로서의 역할을 할 수 있는 데이터가 Attribute내에 존재할 때 그 값을 따로 빼어내서 인덱스로 만드는 것.
Partition Key
Sort Key
GSI
Attribute
OrderID
Date
Region
Attribute
1
210701
Seoul
{...json...}
2
210701
Busan
{...json...}
2
210702
Busan
{...json...}
3
210703
Daegu
{...json...}
Sort Key, GSI와 같은 인덱스는 없어도 된다. 그러나 없을 때 Partition Key가 고유값이 아니면 데이터에 대한 무결성을 장담할 수 없게된다. 이렇기 때문에 Sort Key가 필요해지고 이 Sort key와 Partition key의 결합이 Primary key가 되는 것.
DynamoDB 생성하기
AWS Console에 'DynamoDB'를 검색해서 나온 서비스를 클릭한다.
최초 화면은 다음과 같이 보여질 것이다. 우측 'Create table' 버튼 클릭
이제 설정하는 부분인데 이 설정 부분이 꽤나 양이 많다. 우선 다음을 보자.
- Table name: Orders
- Partition key: OrderID
- Sort key: Date
위에서 배운대로 Partition key와 Sort key 두 개를 모두 설정하겠다. 이 두개가 더해진 것이 Primary key가 된다. 다른 말로 이 두개가 같은 Item은 있을 수 없다.
- Table settings: Customize settings
- Table class: DynamoDB Standard
- Read/write capacity settings: On-demand
Provisioned를 사용하지 않는 이유는 Provisioned는 미리 할당된 만큼의 데이터 비용을 지불한다는 것인데 나는 실습차원에서 만드는 것도 있고 Provisioned는 일반적으로 예측 가능한 트래픽인 경우에 사용한다. 트래픽의 등락이 크면 On-demand가 유리하다.
- Secondary indexes: 여기서 Global Index가 위에서 말한 GSI이다. 이후에 생성해도 되고 지금은 필요도 없기 때문에 넘어간다.
- Encryption at rest: Owned by Amazon DynamoDB
이렇게 설정한 후 테이블을 최종적으로 만든다. 테이블을 만들면 다음과 같이 리스트에 만든 테이블 하나가 노출된다.
저 안으로 들어가보면 다음과 같이 생겼다. 테이블에 대한 정보가 이렇게 보여지고, 아이템을 추가할 수 있다.
우측 상단 Actions > Create item 버튼을 클릭해서 아이템 하나를 만들어보자.
이러한 화면에서 원하는 값을 입력하면 된다.
이 상태에서 새로운 속성을 더 넣어주고 싶으면 우측 "Add new attribute" 버튼을 클릭해서 자유롭게 추가가 가능하다. 이게 위에서 말한 형식에서의 자유로움이다.
그리고 이 상태에서 우측 상단 "JSON view" 버튼을 클릭하면 이 데이터를 JSON으로는 어떻게 넣는지 보여준다.
여기서 "S"가 어떤 의미냐면 "String"의 의미이다.
이 상태에서 "Create item" 버튼을 클릭해보자. 그럼 다음과 같이 리스트에 만든 아이템 하나가 보여진다.
그리고 이 화면에서 쿼리도 날릴 수 있다. 내가 원하는 데이터만 추출할 때 유용하다.
이런식으로 DynamoDB를 이용할 수 있다. 이제 Lambda를 만들어서 이 DynamoDB와 연동해보자.
Lambda function에서 DynamoDB 접근하기
다음과 같이 만들어 준다. 런타임은 Node.js 16.x를 사용해보자.
우선 코드를 수정하기 전 이 람다함수가 DynamoDB에 접근할 수 있도록 권한 설정을 해주어야한다.
다음과 같이 Configuration > Permissions 에 들어가보면 적용된 Role이 보여진다. Role 클릭.
다음과 같이 해당 역할 내부로 들어와서 Permissions policies 섹션에 우측 Add permissions > Attach policies 버튼 클릭
DynamoDB를 검색해서 나오는 AmazonDynamoDBFullAccess를 선택 후 Add permissions 클릭
그럼 이렇게 Permissions policies 섹션에 이제 방금 추가한 정책이 들어가 있다.
이제 람다의 코드를 수정해보자. 다음과 같이 작성한다.
우선 "aws-sdk"를 임포트해야 한다. 이 녀석으로부터 AWS에 접근해야 하기 때문이다.
const AWS = require("aws-sdk");
그리고 이 녀석을 통해 DynamoDB를 가져온다. 가져올 땐 지역을 설정해줘야 한다. 당연히 내가 만든 DynamoDB에 대한 지역을 설정.
const ddb = new AWS.DynamoDB.DocumentClient({"region": "ap-northeast-2"});
그리고 리턴할 handler를 만든다. 이 함수는 비동기 함수로 우선 requestId를 받아 저장한다.
그리고 하단에 만든 createMessage()를 호출하는데 이 함수는 인자로 requestId를 넘겨주고 콜백함수를 호출한다. 이는 리턴 객체를 보내기 위함이다.
AWS에서 Step functions이라는 서비스가 있다. 이 서비스는 Step by Step으로 어떤 작업을 수행해나가는 서비스를 말한다. 비즈니스 워크플로우에 맞춰 수행되는 작업이 정해지는 것인데 그것을 람다와 연동해서 사용할 수 있다. 말보다 직접 해보면서 이해하는게 훨씬 더 이해가 수월한듯해서 바로 만들어보자.
IAM Role 생성
우선 Step function을 람다와 사용하기 위해선 Role을 새롭게 만들어야 한다. 왜냐하면 Step Functions이 람다 함수에 접근하기 위해 AWS에서 기본으로 제공해주는 역할이 없기 때문이다.
역할을 만들기 위해 IAM > Roles > Create role 클릭
설정 부분은 다음과 같다.
- Trusted entity type: AWS service
- Use case: Step Functions
선택하면 다음과 같이 정책이 미리 선택되어 있다. 확인 후 'Next'
다음 화면에서 이름을 적절하게 입력 후 "Create role" 클릭
Role을 정상적으로 만들었으면 Roles 리스트에 만든 역할이 잘 보여져야한다.
이렇게 Role을 만들었으면 이제 Step Functions에서 사용될 람다 함수를 만들어야한다.
Lambda Function 만들기
이름을 Step-1으로 하고 Runtime을 Python3.12로 만들어 볼 예정이다.
아래와 같이 간단한 코드를 작성하고 Deploy한다.
이제 Step-2 람다 함수를 만든다. 마찬가지로 같은 코드로 작성 후 Deploy한다.
이렇게 간단하게 두개의 람다 함수를 만들고 Step functions을 만들어보자.
Step Functions 만들기
AWS Console에 "Step functions"을 검색해서 나오는 서비스를 클릭한다.
Step functions을 만들기를 시작하면 다음과 같은 화면이 보이는데 여기서 상단에 "Code" 버튼을 클릭해서 다음과 같은 상태로 만들어주자.
"StartAt"은 시작점이 어디인지를 말한다. 아래 States에 여러개의 컴포넌트를 만들면 되는데 컴포넌트들 중 어떤 컴포넌트에서 시작할지를 말한다. 그리고 저 "Code"를 다음과 같이 수정해보자.
여기서 "Start"라는 State는 둘 중 하나를 선택하는 형태이다. 그래서 Type은 "Choice"가 된다. 그리고 그 선택지는 "Choices"로 설정해준다. 각 Choice는 Variable 값에 따라 정해진다. 변수로 들어오는 "type"이라는 값이 "first" 또는 "second" 어느것이냐에 따라 다음 State를 결정해준다. 그 State는 Step1, Step2인데 이 녀석들은 만든 람다함수가 된다.
Step1, Step2 모두 람다 함수이기 때문에 "Resource"를 지정해주는데 여기서 Resource는 람다 함수의 ARN이 된다.
그리고 이 이후에 끝난다는 것을 알려주기 위해 각 Step1, Step2 모두 "End": true를 입력해준다.
이렇게 코드를 작성하면 우측 다이어그램처럼 모양이 나온다.
이렇게 만들고 상단에 "Config" 버튼을 클릭해서 위에서 만든 IAM Role을 적용하자.
이 상태에서 우측 상단 'Create' 버튼을 클릭해보자. 그럼 다음과 같이 Step Functions이 만들어진다.
여기서 우리가 만든 Step Functions을 테스트해보기 위해 우측 상단 "Start execution" 버튼을 클릭해보자.
그럼 이러한 화면이 노출된다. 여기서 우리가 변수로 받기로 한 "type"을 명시해주면 된다.
"Start execution" 버튼을 클릭하면 실행이 된다. 그리고 다음과 같은 화면이 보인다.
이 하단에 보면 다이어그램을 통해 어떤 흐름으로 수행됐는지 시각적으로 확인이 가능하다.
당연히 "type"값을 "first"로 주었기 때문에 Step1이 실행된 모습이다.
그럼 만약 "type"이라는 값 말고 "type1" 이라는 키로 잘못 입력하면? 다음과 같은 결과를 얻는다.
Lambda에서 Layer라는 개념이 있다. 이 Layer는 어떤 기능을 하고 왜 있는지 알아보고 직접 적용해보자.
Lambda는 너무나도 독립적이기 때문에 생기는 문제가 있다. 예를 들면, 정확히 동일한 패키지와 환경을 사용하더라도 각각의 람다 함수는 독립적으로 해당 환경을 구성해줘야한다. 단적인 예시로 20개의 람다 함수가 있고 그 20개의 람다 함수가 모두 같은 패키지를 사용할때도 각각의 람다함수마다 같은 패키지를 업로드해줘야한다. 이건 효율성도 떨어지지만 비용 측면에서도 상당히 불리하다. 이를 해결하기 위해 어떤 기반으로된 환경위에 람다 함수를 올리게 하는 Layer가 존재한다. Layer는 말 그대로 람다 함수가 올라갈 자리를 말하는것이다. 기본적으로 필요한 패키지나 환경에 대한 설정을 Layer에 깔아둔 후 그 Layer 위에 람다함수를 올리는 것이다.
그래서 이 Layer를 만드는 것부터 시작해보자.
Layer 생성하기
AWS Console에서 "Lambda"를 검색해서 나오는 서비스를 클릭한다.
좌측 사이드바에서 'Layers'를 클릭한 후 나오는 메인 화면에서 우측 상단 Create layer 버튼 클릭.
여기서 업로드 할 패키지가 있어야 하는데 이 패키지를 업로드할 때 Zip 파일로 업로드해 볼 예정이다. 그래서 우선 패키지를 내려받아야한다. "requests"라는 파이썬 패키지를 업로드해 볼 것이고 이 패키지를 내려받을 경로 하나를 설정해야 하는데 그 경로가 중요하다. 왜냐하면 경로에 맞는 곳에서 이 Lambda가 패키지를 내려받기 때문에 경로 설정이 상당히 중요한데 이 경로를 당연히 AWS 문서에서 잘 알려준다.
나는 위 문서에 따라 "python/lib/python3.12/site-packages" 이러한 경로 내부에 requests를 내려받기 위해 아래처럼 입력했다.
pip install requests -t .
"-t" 옵션을 부여해서 특정 경로에 패키지를 내려받겠다고 선언해주면 해당 경로에 requests 패키지를 사용하기 위해 필요한 모든 dependencies가 내려받아진다.
그런 다음 해당 경로 전체를 .zip 파일로 만들어준다.
zip -r python.zip python
이렇게 zip 파일로 필요한 패키지를 묶은 다음 다시 Layer 생성화면으로 돌아가보자.
설정 부분은 다음과 같다.
- Name: cwchoiit-python3-layer
- Description: requests package layer
- Upload a .zip file
- Runtimes: Python 3.12
'Create' 버튼을 클릭해서 Layer를 생성하자. 그럼 Layers 리스트에 만든 Layer가 잘 노출된다.
이제 기존에 람다함수가 없다고 가정하고 람다함수를 새로 생성해보자. 설정 부분은 다음과 같다. 런타임을 위에 만든 Layer와 잘 맞춰주자.
람다 함수를 만들고 나면 만들어진 람다 함수 내부로 들어가서 하단으로 스크롤을 내려보면 다음과 같이 Layers 섹션이 있다. 여기에 "Add a layer" 버튼 클릭
Layer를 추가하는 화면이다. 설정 부분은 다음과 같다.
- Layer source: Custom layers
- Custom layers: 방금 만든 layer
- Version: 원하는 버전 선택 (지금은 1밖에 없을 것)
Layer가 람다 함수에 잘 추가가 되면 상단에 다이어그램에 다음과 같이 Layer가 0에서 1로 적용된 수가 바뀜을 알 수 있다.
그럼 "requests"라는 패키지를 추가했으니까 이 패키지를 임포트할 수 있어야 한다. 임포트 한 후 테스트를 실행해보자.
Canary Release는 배포 전략 중 하나이다. 이 배포 전략은 새롭게 배포되는 버전의 리스크를 줄이는 방법인데 기존 버전과 새로운 버전이 있을 때 기존 버전에서 바로 새로운 버전을 출시하는게 아니라 기존 버전과 새로운 버전 두 개 모두를 프로덕션 환경으로 올리지만 가중치를 두어 사용자들이 겪는 새로운 버전에 대한 오류나 문제점에 대한 비율을 줄이는 방식이다. 예를 들어, 기존 버전이 있고 새로운 버전이 새로 출시될 때 기존 버전에 가중치를 60% 새로운 버전의 가중치를 40%로 할당해서 사용자들이 접속할 때 가중치에 따라 60%는 기존 버전을 그대로 사용하게 하고 40%는 새로운 버전을 사용하게 하므로써 새 버전에 대한 문제를 40%로 낮추는 방법이다. 이렇게 최초에 40%로 가중치를 두다가 점점 안정화가 되면 그 가중치를 점점 높여 새 버전이 안정적이게 자리잡을 수 있게 배포하는 방법이라고 생각하면 된다.
다음 그림이 이 내용을 완벽하게 설명한다.
이렇듯 대부분의 유저를 기존에 버전으로 접속하게 하고 5% 정도의 유저만 새로운 버전을 경험하게 하면서 새 버전이 가질 수 있는 문제점이나 예상하지 못한 문제를 줄이는 방법이라고 생각하면 된다. 이 방법을 AWS Lambda와 API Gateway도 사용할 수 있다. 바로 사용해보자.
Lambda 버전 생성하기
우선 다음은 가장 기본 형태의 람다 함수 코드이다. 소스 코드가 중요한 게 아니고 버전에 따른 가중치를 두는것을 중점으로 봐보자.
이러한 형태의 결과를 뱉는 람다 함수가 있고 이에 대한 버전을 만들어보자.
버전을 만들기 위해 우측 상단 Actions > Publish new version 클릭
Version description을 다음과 같이 old로 작성해보자.
Publish 버튼을 클릭하면 버전이 만들어지고 다음과 같이 Versions 탭을 클릭해보면 새로 생긴 버전이 보인다.
이 상태에서 소스 코드를 다음과 같이 변경해보자. 리턴하는 문자열을 "New Version !!!" 이라고 작성했다. 이 상태에서 Deploy 버튼을 클릭한다.
이제 다시 버전을 만들어보자. 이번엔 new 라는 Description을 지어주자.
그럼 버전 리스트에 두 개의 버전이 보인다.
이렇게 만들고 별칭을 생성하자. Actions > Create alias 클릭
설정 부분은 다음과 같다.
- Name: production
- Description: prod via canary
- Version: 1
- Weighted alias
- Additonal version: 2 / 40%
이렇게 설정하면 버전 1에 대한 가중치가 60%, 2에 대한 가중치가 40%로 이 람다 함수가 실행된다는 의미다. 이렇게 만든 alias를 API Gateway에 등록하면 퍼센티지에 맞게 유저가 실행하는 람다 함수가 정해진다.
API Gateway에서 원하는 리소스 내 메서드를 만든다. 메서드를 만들 때 다음과 같이 새로 만든 별칭을 넣어줘야 한다.
Lambda function을 선택 후 생성된 람다함수를 클릭한다음 그 뒤에 ":<alias-name>"를 입력해준다.
이렇게 리소스와 메서드를 만들었으면 이제 배포를 하면 된다. 우측 상단 Deploy API 버튼 클릭
설정 부분은 다음과 같다.
- Stage: New stage
- Stage name: v1
Stage를 만들면 다음과 같이 해당 스테이지로 접속할 수 있는 URL을 알려준다. 이 URL에 아까 만든 리소스대로 접속해보자.
그럼 다음과 같이 각 가중치에 맞게 해당 버전을 응답으로 돌려준다. 60% / 40% 이니까 두번에 한번 정도 낮은 가중치의 버전이 노출됐다.
결론
이렇게 Canary Release를 Lambda와 API Gateway를 이용해서 수행할 수 있었다.
Lambda는 AWS에서 제공해주는 서버리스 서비스이다. 서버리스(Serverless)란 말 그대로 서버가 없다는 의미고 그 말은 진짜 서버가 아예 없다는게 아니라 관리할 서버가 없다. 즉, 관리할 필요가 없다란 의미가 된다.
개발자는 서버를 관리할 필요없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델을 서버리스 아키텍트라고 한다. 이 구조의 장점은 항상 대기하고 있는 전용 서버가 없어서 실행이 끝나면 자원을 반납하고 사용할 때만 자원을 가져다가 사용하는 구조라고 할 수 있다. 그러나 장점만 있는 구조는 없다. 장점과 단점을 둘 다 알아보자.
장점
서버 관리(자동 확장, 장애 방지)가 불필요
관리보다 개발에 집중이 가능
사용한 만큼 과금
급격한 트래픽 변화에 유연
단점
다른 클라우드 컴퓨팅 자원보다 비쌈
느림(호출과 동시에 서버가 세팅되기 때문)
장기적인 작업에는 적합하지 않음
함수의 처리 결과에 따라 상태를 따로 저장
단점 중 장기적인 작업에는 적합하지 않다라고 되어 있는데 이 말은 한 작업이 1시간, 2시간 또는 그 이상의 시간을 소요하는 작업이라면 그 시간만큼 과금이 되기 때문에 다른 클라우드 컴퓨팅 자원보다 비싼 과금을 내는 서버리스보단 온프레미스나 클라우드 컴퓨팅 서버를 사용하는게 더 유리할 수 있다는 소리다.
서버리스의 2가지 서비스 형태
BaaS(Backend As a Service)
클라우드 공급자가 제공하는 서비스를 이용해 백엔드 기능들을 쉽게 구현
Customizing이 어렵다
Google Firebase
FaaS(Function As a Service)
FaaS는 기능을 하나의 함수로 구현
함수가 실행할 때마다 서버 자원을 할당받아 사용
로직을 개발자가 작성하므로 Customizing이 가능
AWS Lambda
AWS Lambda 구축하기
이제 람다가 어떤것인지 알았으니 한번 만들어보고 사용해보자.
우선 AWS Console에 "Lambda"를 입력하고 나온 서비스를 클릭한다.
Create a function 버튼 클릭
설정화면은 다음과 같이 설정한다.
- Author from scratch
- Function name: cwchoiit-first-lambda
- Runtime: Python 3.12
Runtime은 어떤 환경을 사용할 것인지를 의미한다. NodeJS, Java 등등 다양하게 있다. 본인은 Python을 선택했다.
이 상태로 Create function 버튼을 클릭하면 Lambda가 만들어지면서 다음 화면이 노출된다.
아래 코드를 보자. 간단한 파이썬 코드로 된 함수 하나가 있다. 이 코드가 곧 하나의 람다 함수가 된다. 이 소스를 실행하기 위해 "Test" 버튼을 클릭해보자.
그럼 이러한 화면이 보여지는데 우선 Event name만 입력해보고 "Save" 버튼을 클릭해보자.
그러면 이렇게 내가 만든 이벤트 하나가 리스트에 보여진다. 이 이벤트를 클릭하면 아까 구성한대로 이벤트가 트리거될 준비가 된 상태이고 "Test" 버튼을 클릭하면 그 이벤트가 실행된다.
다음은 테스트 실행 결과다. 이벤트 이름, 응답 등등이 보여지고 코드에서 리턴하는 내용처럼 응답에는 statusCode와 body값이 있다.
그럼 아까 이벤트를 만들 때 이 부분이 무엇인지 알아보자.
람다 함수는 이 함수로 들어오는 데이터 같은 것들을 이벤트로 받아준다. 그 이벤트를 출력해보자.
이렇게 소스를 변경하면 Deploy 버튼을 클릭해서 새롭게 소스를 배포해야 한다.
배포가 끝나면 다시 테스트 버튼을 클릭해보자. 이 이벤트에 대한 내용이 출력될 것이다.
이렇게 이벤트를 출력하면 테스트 구성시에 작성했던 데이터가 담겨있는 것을 알 수 있다. 이렇듯 람다 함수에 뭔가를 전달할 때 이벤트라는 파라미터안에 그 데이터들이 담긴다고 생각하면 된다.
그리고 이 실행에 대한 로그를 볼 수 있는데 로그는 CloudWatch에 기록된다. 한번 확인해보자. 위에 탭 중에 Monitor 탭이 있다. 해당 탭을 누르면 다음 화면이 보이는데 여기서 View CloudWatch logs 버튼을 클릭하자.
그럼 이러한 화면이 보여진다. 내가 만든 람다 함수에 대한 로그가 기록되어있다. 그리고 저 아래 빨간 표시로 해둔것은 배포 버전별로 다르게 기록되는 로그이다. 처음 람다함수를 만들면 그게 최초 배포버전이고 내가 중간에 이벤트를 찍어보겠다고 소스를 변경하고 배포를 다시했기 때문에 저렇게 두 개의 다른 로그가 쌓인다고 보면된다. 배포를 새로 또 하면? 3개가 된다.
안으로 들어가보면 다음처럼 화면이 보여진다. 내가 찍은 "print(event)" 역시 로그로 남게 된다. 이렇게 로그도 확인이 가능하다.
이렇게 간단하게 AWS Lambda 함수를 생성해서 서버리스 서비스를 구현해보았다. 이 서버리스를 API Gateway에 붙여서 실제 서버가 있는것처럼 실행하게 만들수도 있다. 그 부분을 다음 포스팅에서 해보자.
# encrypt.py
import aws_encryption_sdk
from base64 import b64encode
from aws_encryption_sdk import CommitmentPolicy
# AWS KMS Client 생성
client = aws_encryption_sdk.EncryptionSDKClient(commitment_policy=CommitmentPolicy.REQUIRE_ENCRYPT_REQUIRE_DECRYPT)
# Your AWS KMS Key ARN
key_arn = "your aws kms key arn"
# 암호화 하고자 하는 텍스트
source_plaintext = "hi"
kms_kwargs = dict(key_ids=[key_arn])
# 나의 CMK
master_key_provider = aws_encryption_sdk.StrictAwsKmsMasterKeyProvider(**kms_kwargs)
# 암호화 된 텍스트와 Encryptor Header
ciphertext, encryptor_header = client.encrypt(source=source_plaintext, key_provider=master_key_provider)
# 암호화 된 텍스트 출력
print(ciphertext)
# 복호화 된 텍스트와 Decryptor Header
cycled_plaintext, decrypted_header = client.decrypt(source=ciphertext, key_provider=master_key_provider)
# 복호화 된 텍스트 출력
print(cycled_plaintext)
이제 이 파일을 실행해보자.
python3 encrypt.py
실행 결과:
결과를 보면 암호화 된 텍스트는 저렇게 쭉 길게 늘어진 알 수 없는 문자열이고 복호화 된 텍스트는 빨간 박스로 친 'hi'이다.
결론
이렇게 AWS KMS를 사용해서 암호화 하고자하는 것을 암호화하고 복호화할 수 있다. 주로 사용되는 예시라고 함은 Django를 사용할 때 settings.py 파일에서 ALLOWED_HOSTS = []에 사용되는 URL을 암호화한 상태로 저장하고 복호화하는 코드만 넣어서 URL을 숨길수도 있다.
NACL과 Security group 모두 보안을 위한 녀석들이다. AWS에서 크게 인스턴스를 보호하는 방법은 두가지인데 그 두 가지가 이 NACL과 Security group이다. 이 두 녀석으로 외부의 특정 클라이언트와 통신을 허가할지 거부할지를 결정하게 된다. 그럼 이 둘의 차이는 무엇일까?
NACL (Network Access Control List)
NACL은 Stateless한 보안 체계이다. 즉, 요청을 한 번 받으면 그 요청에 대해 기억하고 있지 않다는 의미이다. 그래서 다음 그림을 보자.
NACL로 보안 체계를 걸어둔 VPC가 있는데 이 NACL이 들어오는 포트는 80으로 허가했고 나가는 포트는 아무것도 허가한게 없을 때, 외부에 있는 클라이언트에서 요청이 들어오면 클라이언트는 응답을 받을 수 있을까?
요청은 가능하지만 응답은 할 수 없다. 왜냐하면 NACL은 Outbound로 허가한 포트가 없고 NACL은 Stateless 보안 체계이기 때문이다.
그래서 NACL은 Inbound, Outbound 규칙이 명확하게 명시되어야 한다. 오로지 규칙만을 보고 요청과 응답을 허가하거나 거부하기 때문이다.
그렇다면 Security group은 어떻게 다를까?
Security group
Security group은 Stateful한 보안 체계이다. 즉, 들어오는 요청을 기억하고 있다가 응답한다는 의미이다. 결론부터 말하면 이 Security group에 위 NACL처럼 Inbound에 80, Outbound에 아무것도 허가하지 않더라도 요청을 80으로 했다면 클라이언트는 요청에 대한 응답을 받을 수 있다.
클라이언트가 특정 VPC내 80 포트에 매핑된 어떤 서버에 접속할 때 이 EC2 보안 그룹에 인바운드 아웃바운드 규칙이 그림처럼 되어있다면 아웃바운드로 아무것도 허가하지 않았지만 응답을 받을 수 있다. 이는 Security group이 Stateful 보안 체계라 들어온 요청을 기억하고 있다가 응답을 보내주기 때문이다.
NACL 설정해보기
NACL을 직접 설정해서 어떻게 동작하는지 확인해보자. 우선 VPC > Security > Network ACLs로 들어가야 한다.
이렇게 보다시피 화면 우측 상단 Create network ACL 버튼이 보인다. 클릭.
나는 아래와 같이 설정한 뒤 만들었다.
- Name: private-nacl
- VPC: 사용중인 VPC
만들고 나면 리스트에 만든 NACL이 보이는데, 클릭해서 우선 서브넷을 연동하자.
연동하고자 하는 서브넷을 선택하고 'Save changes' 클릭
이제 Inbound, Outbound 설정을 해야한다. 인바운드는 들어오는 트래픽이고 아웃바운드는 여기서 나가는 트래픽을 말한다.
예를 들어, Bastion host에서 이 private EC2로 SSH로 접속하는것을 허용하고 싶다면 Inbound에는 SSH 또는 포트(22) 선택을 한 후 Source에 Bastion host가 위치한 IPv4 CIDR를 입력하면 된다.
중요한건 이제 밖으로 나가는 Outbound인데 여기서 나가는 포트는 22가 아니다. 왜냐하면 들어오는 포트가 22인거지 나를 호출한 곳은 22가 아니란 얘기다. Outbound에 22로 설정하면 이 private EC2에서 어딘가로 SSH를 접속하는것을 의미하게 된다. 난 그것을 원하는게 아니고 나의 22번 포트로 들어온 요청에 대한 응답을 보내고자 한다. 그래서 Outbound는 임시포트(1024 - 65535) 중 아무거나를 허용해야 한다. 다음 그림처럼 말이다.
자, 이렇게 설정하고 Bastion host에서 이 private EC2에 접속해보자.
위 그림에서 10.0.0.208이 private EC2이고, 10.0.0.24가 Bastion host이다. 접속해보자.
다음과 같이 잘 접속된다.
NACL은 Stateless 보안 체계라고 했다. 그래서 규칙이 절대적인데 그 말은 이 상태에서 Outbound 규칙을 제거하면 접속이 불가능해야 한다. 한번 해보자. 보다시피 Outbound 규칙이 전부 Deny 상태이다.
다음 화면처럼 접속되지 않는다. 이런 보안 체계가 NACL이다. 만약, Security group으로 같은 행위를 했다면 정상적으로 접속이 될 것이다. 왜냐하면 Security group은 Statefull한 보안 체계니까.
