카테고리 없음

#1 CRScube의 DevOps 이야기 - DevOps 자동화 with Serverless

CRScube 2022. 4. 4. 19:45

CRScube 개발팀의 Tech Seminar는 매월 정기적으로 이루어진다.

그 Tech Seminar 중 지난 2022년 1월 28일에 있었던 DevOps팀의 세미나를 첫 번째로 포스팅한다.

 

세미나 일시: 2022년 1월 28일

발표자: DevOps팀

 

DevOps 자동화 with Serverless

1. Serverless

What is Serverless?

서버리스는 클라우드 시스템의 구현 방식 중 하나로, 서버가 없는 것이 아니라 서버의 관리가 필요 없다는 뜻입니다. 클라우드 서비스 공급자는 서버리스 서비스들을 통해 코드를 실행하는 데 필요한 인프라를 자동으로 프로비저닝, 크기 조정 및 관리하고 사용자는 사용한 만큼만 비용을 지불합니다.

 

Serverless Services (AWS)

AWS에서 제공되는 Serverless를 위한 Service는 다음과 같다.

 

Serverless in CRScube Solution

이 중 CRScube에서 사용하고 있는 Service는 다음과 같다.

 

AWS Lambda를 통해서 각 Servcie들을 Seamless 하게 엮어서 필요한 기능을 완성시킨다.

AWS Fargate를 통해서 CRScube Solution들을 동적으로 Scale In/Out 할 수 있는 Task로 실행시킨다.

AWS Step Functions으로 Solution들의 DR를 구성해서 주기적으로 DR Region으로 백업한다.

Amazon CloudWatch로 Solution Log를 수집하고, 설정한 임계값을 초과 또는 미달하는 경우 필요한 Alert을 발생시킨다.

 

2. DevOps 자동화 | 조금은 귀찮은 작업들 해결책

DevOps팀은 다음의 조금은 귀찮은 작업들을 자동화해서 삶의 질을 향상 시키고 있다.

 

A. 배포할 때 및 상시 솔루션 서버 Running 및 Healthy 상태 확인

B. 솔루션 로그 활용을 위해 CloudWatch에서 S3로 주기적으로 내보내기

C. ECS Fargate, RDS를 주기적으로 on/off

D. S3 Bucket 활용(솔루션 외 용도)의 여러 문제..

 

A. 배포할 때 및 상시 솔루션 서버 Running 및 Healthy 상태 확인

우리가 배포할 때나 Service를 운용할 때 항상 마주하는 대화이다.

이런 잦은 하지만 중요한 질문들은 DevOps 팀의 마찬가지로 번거롭지만 중요한 Ad-hoc이 된다.

Ad-hoc은 귀찮음을 떠나서 업무 계획을 제대로 세울 수 없는 난감한 현실을 초래한다.

그래서 DevOps 팀은

  • Application Load Balancer로부터 Healthy Count를 수집하고
  • AWS ECS의 Task count를 수집하고
  • 필요한 Alaram을 Amazon CloudWatch로부터 Detect 해서, 
  • AWS SNS를 통해 
  • AWS Lambda를 거쳐
  • Slack으로 Notification을 전달하는

System을 구축했다.

 

솔루션 서버 상태 Slack 알림 구성도

그래서 개발자나 운용 담당자가 DevOps팀에 문의하는 대신, 다음과 같이 Slack을 통해서 필요한 Alarm을 받아 볼 수 있다.

B. 솔루션 로그 CloudWatch에서 S3로 주기적으로 내보내기 

CRScube의 Solution들이 생성하는 Log는 엄청나게 많다.

이 로그들을 사람이 보고 적절한 시점에 S3로 Backup 하는 것은 무척 고단한 일이다.

그래서 다음과 같이 AWS Setup Functions, AWS Lambda, AWS DynamoDB를 이용해서 주기적으로 AWS CloudWatch Logs를 S3로 보낸다.

 

S3로의 로그 전송 자동화 구성도

이와 같이 보내진 로그는 AWS S3에 다음과 같이 쌓여서, 필요한 시점에 조회할 수 있다.

C. ECS Fargate, RDS를 같은 시간에 on/off 

Development Server (Dev Server)나 Staging Server (Stg Server)는 24/7 켜져 있을 필요가 없다.

개발자나 테스터가 사용할 때만 켜져 있으면 된다.

근검절약하기 위해서 사용하지 않을 때 Dev나 Stg Server는 내리고 올리면  좋겠지만, 이 것을 수동으로 하면 매우 번거로울 것이다.

그래서 초기에는 아래와 같이 모든 DEV,STG Server를 일괄적으로 On/Off하는 시스템을 만들었다.

하지만 솔루션별 개발자나 테스터가 테스트를 위해 Off를 원하지 않을 수 있어 필요에 따라 직접 시스템을 비/활성화 할 수 있도록 추가 구성했다.

  • AWS S3, CloudFront | 웹 호스팅 - 유저가 실제 자동화 서비스를 이용할 수 있도록 함
  • API Gateway | Lambda 함수 중계 - 유저가 Lambda 함수를 사용할 수 있도록 함
  • DynamoDB | 자동화 사용 솔루션 관리 - 솔루션 별로 자동화 사용 여부를 기록
  • Cognito | 유저 접근 관리 - 사용자 회원가입 / 로그인 담당

 

Resource ON/OFF 구성도
자동화 시스템 활/비활성화 웹 환경

 

D. S3 Bucket 활용의 여러 문제

사업팀에서 필요할 때마다 S3 Bucket 생성 요청을 하고 접근을 위한 AWS Key를 물어본다면, 이것을 수동으로 처리하는 DevOps팀에게는 또 하나의 큰 번거로운 일이 될 것이고 Key 관리도 되지 않는다.

그래서 DevOps 팀에서는 다음과 같이 사업팀에서 직접 Bucket을 생성하고 접근할 수 있는 Key를 관리할 수 있게 했다.

  • API Gateway | Bucket 사용 중계 - 유저가 S3 Bucket을 이용할 수 있도록 함
  •  IAM | Bucket Policy 관리 - S3 Bucket에 대한 권한을 관리
  • Lambda | Bucket Policy Update - 새로 만들어진 Bucket을 이용할 수 있도록 Policy를 수정함
  • Cognito | 유저 접근 관리 - 사용자 토큰을 관리하고 인증함

 

그리고 Bucket에 Read/Write 할 수 있는 RESTful API를 제공한다.