본 후기는 작성자가 소속된 회사와는 상관 없는 개인의 생각입니다.
Intro
3월 15일, AWS 담당 매니저님이 보낸 안내 메일로 AWS Startup Week 2023을 알게 되었습니다.
재직 중인 에딘트에서 근무 시간에 방문을 허락해주셨습니다. 😊
3월 30일, CTO Jeff님과 서버 개발자 Lay님과 함께 AWS Startup Week 2023에 방문해서 유익한 시간을 보냈습니다.
컨퍼런스 동안 Lay가 정리해주신 내용을 공유해주셔서 회고 내용을 훨씬 깔끔하게 정리할 수 있었습니다.
Track 3 우리 서비스에 효율화 더하기 + 고객사례를 들었습니다.
1. 개발도 빠르게 운영도 간단히! 서버리스 잘 한번 써볼까
발표자 : 최철우, 솔루션스 아키텍트, AWS
서버리스 환경에서 FE 및 BE가 서비스를 런칭할 수 있는 서비스를 소개해주셨습니다.
- AWS Amplify를 사용해서 서버리스 환경에서 React 개발 및 배포하기
- AWS SAM을 이용해서 서버리스 환경에서 Lambda 개발 및 배포하기
1.1. AWS Amplify
AWS Amplify는 웹 및 모바일 어플리케이션 개발을 위한 프레임워크입니다.
React, React Native, Angular, Vue와 같은 웹 및 모바일 프레인쿼으와 통합이 가능합니다.
몇년 전부터 AWS에서는 다양한 스타일의 완전관리형 서비스를 내고 있습니다.
그래서 Amplify의 존재를 처음 알았을 때도 "아 그냥 완전관리형 서비스 중 하나"라고 느꼈습니다.
실제로 Amplify를 사용한 매력적인 이점이나 프렉티스를 보지 못한 것도 큰 이유였습니다.
이번 컨퍼런스에서 그 사례를 볼 수 있었습니다.
- Amplify를 통해 Figma 컴포넌트를 그대로 React 컴포넌트로 생성
- Amplify에서 Mock Data를 넣고 React 컴포넌트에 데이터 바인딩
- Amplify를 통해서 사이트 배포
기본적으로 AWS Amplify에 종속되는 구조기 때문에 범용적으로 쓰기는 어려울 것 같았습니다.
그럼에도 "회사 공식 사이트 등과 같이 지속적으로 고쳐야 하지만 리소스 투자가 애매한 부분에서는 유용하게 쓸 수 있지 않을까?"라는 느낌이 들었습니다.
제대로 된 A to Z 튜토리얼이 시중에 공개된 것이 없어서 약간 아쉬운 느낌이었습니다.
1.2. AWS SAM
AWS AMM은 서버리스 어플리케이션을 개발, 테스트, 배포하기 위한 프레임워크입니다.
내부적으로 AWS CloudFormation을 사용하며 API Gateway, Lambda, DynamoDB, S3 등과 연동하여 사용하곤 합니다.
AWS CloudFormation은 JSON 혹은 YAML 파일을 통해서 AWS Infrastructure를 프로비저닝할 수 있는 툴입니다.
이제는 실버 불릿인지 재앙인지 많은 토픽이 나오고 있는 서버리스 REST API에 대한 예제였습니다.
서버리스 환경은 서버의 최소 유지비 측면에서 매우 유리하고 CI/CD와 같은 관리 포인트가 줄어드는 장점이 있습니다. 하지만 난해한 로컬 테스트와 난해한 디버깅, 콜드 스타트 등의 여러 불편한 점도 있습니다.
개인적으로는 이벤트 타입을 모킹해서 로컬에서 jest를 이용해서 테스트하는 것이 가장 아름다운 구조가 아닌가 생각합니다.
결국은 서버리스 REST API를 작업하기 위한 탬플릿을 만들어야 합니다.
대표적인 방법은 3가지가 존재하고 저는 SAM보다는 CDK가 좋은 것 같습니다.
| 구분 | 난이드 | 특징 |
|---|---|---|
| Serverless Framework | 매우 쉽다 | [단점] 리전 별로 지원 현황이 열악하다. [단점] AWS 리소스가 아닙니다. |
| SAM + API Gateway + Lambda | 상대적으로 쉽다. | [장점] REST API 샘플(프로토타입)이 빠르게 나옵니다. [단점] 실사용자 층을 만나기 힘들었습니다. [단점] 다른 코드형 인프라 툴(Terraform)에 비해서 강력한지 모르겠습니다. |
| CDK + Lambda | 상대적으로 쉽다. | [장점] AWS만 사용할 경우, 꽤 편리하게 사용할 수 있습니다. [장점] 다양한 AWS 리소스를 커스텀해서 쓸 수 있습니다. [단점] 실사용자 층을 만나기 힘들었습니다. [단점] 에러 메세지에 불안정성이 존재합니다. - https://github.com/aws/aws-cdk/issues/22997 |
개인적으로 굳이 코드형 인프라를 쓴다면 테라폼(Terraform)을 쓰는 것이 가장 매력적이라고 생각합니다.
하지만 AWS 리소스만 쓰고 있다면 AWS CDK도 나쁘지 않은 경험을 제공해줬습니다.
- 설치 및 준비
npm install -g aws-cdk
cdk init app --language typescript- 코드 스니펫
import * as cdk from 'aws-cdk-lib';
import { App, Stack, StackProps } from 'aws-cdk-lib';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';
class MyStack extends Stack {
constructor(scope: App, id: string, props?: StackProps) {
super(scope, id, props);
// Lambda 함수 생성
const myLambda = new lambda.Function(this, 'MyLambda', {
runtime: lambda.Runtime.NODEJS_14_X,
handler: 'index.handler',
code: lambda.Code.fromInline(`
exports.handler = async (event) => {
return {
statusCode: 200,
body: 'Hello from Lambda!'
};
};
`),
});
// API Gateway 생성
const api = new apigateway.RestApi(this, 'MyApi');
const helloResource = api.root.addResource('hello');
helloResource.addMethod('GET', new apigateway.LambdaIntegration(myLambda));
}
}
// CDK 애플리케이션 생성
const app = new App();
new MyStack(app, 'MyStack');2. AWS에서 Docker Container 사용하기
발표자 : 신정섭, 솔루션스 아키텍트, AWS
발표자 : 안성진, 솔루션스 아키텍트, AWS
발표자 : 정주홍, Head of Backend Engineering, AB180
시간이 지날수록 Docker 컨테이너와 관련된 내용들이 많이 보인 것 같습니다.
AWS 측에서 한 번, AB180 측에서 한 번 발표해주셨습니다.
하지만 Docker를 적극적으로 사용하고 있지 않아서, 이해할 수 있었던 부분만 적고자 했습니다.
2.1. EC2 vs ECS Fargate
EC2와 ECS Fargate를 비교한 내용이 있었습니다.
내용은 아래와 같고 핵심은 실제로 벤치마킹해볼 것입니다.
- 대체로 Fargate가 낫다.
- 워크로드가 예상 불가능한 경우- 비용 최적화가 어려운 경우
- 스케일아웃이 많이 발생하는 경우
- 아래의 경우 EC2가 나쁘지 않다.
- 일정한 수의 서버가 실행되어야 하는 경우- 비용 최적화할 자신이 있는 경우
2.2. Docker Image 최적화
Docker Image에서 레이어가 먹는 용량이 꽤 큽니다.
따라서 apt install과 같은 구문들은 최대한 하나의 레이어에 쓰도록 합시다.
이를 통해서 이미지 전체 용량을 효율화 할 수 있습니다.
- 나쁜 사례
RUN apt install a
RUN apt install b
RUN apt install c
RUN apt install d- 좋은 사례
RUN apt install a \
apt install b \
apt install c \
apt install d3. AWS에서 효율적으로 글로벌 인프라 사용하기
발표자 : 김창순, DevOps 팀 리더, Channel Corp
서버와 요청자의 거리가 멀면 멀수록 사용자 경험이 나빠지는 것은 잘 알려진 사실입니다.
이 경우 다음과 같은 선택지들이 존재합니다.
- AWS CloudFront를 통해서 캐싱
- AWS Global Accelertor를 통해서 요청 속도 증가
- Option 메서드 캐싱
Channel Corp에서는 AWS GA와 Option 메서드 캐싱을 통해서 성능을 끌어올렸습니다.
1. AWS CloudFront를 통해서 캐싱
가장 흔한 사례는 CDN 서비스를 이용하는 것입니다.
하지만 대부분의 서버 요청은 모두 다른 정보를 반환합니다.
따라서 캐싱 적중률이 높기 힘들어 비용 및 성능 효율적이지 않습니다.
또한 CDN 비용과 서버 데이터 비용이 이중으로 지출되는 문제가 있습니다.
2. AWS Global Accelerator를 통한 요청 속도 증가
AWS Global Accelerator를 사용하면 최대 네트워크 속도를 60% 가까이 올릴 수 있습니다.
3. Option 메서드 캐싱
브라우저에서는 Option 메서드 요청, 본 요청이 2개가 갑니다.
즉, Option 메서드만 캐싱해도 네트워크 성능이 2배가 됩니다.
4. 결론
다양한 사례 중, 제 상황에서 경험했거나 경험하고 싶은 사례만을 정리해보았습니다.
다른 회사에서 재직하고 계시는 리드, 시니어급 DevOps의 생각을 엿볼 수 있어서 매우 좋았습니다.
린(Lean)하게 접근하고 실제 측정한 데이터를 사용한다는 부분은 현업에서 적용해서 사용해서 유의미한 성능 및 비용 절감을 누린 것 같습니다.
전체적으로 유익한 시간이었습니다.
