AWS 활용 우수 기업으로 선정된 핀다의 AWS 활용 경험

Kang Keonah
RayonProtocol
Published in
14 min readJul 30, 2018

핀다는 지난 4월 열린 2018 AWS Summit에 모든 개발자가 참석할 정도로 AWS를 효율적으로 활용하기 위해 꾸준히 노력하고 있습니다.

그러던 중에 Amazon의 어카운트 매니저와 솔루션 아키텍트로부터 AWS 활용과 관련하여 컨설팅을 받을 기회가 있었습니다.

핀다 AWS 구성도

핀다 AWS 구성도와 몇가지 사전 인터뷰 질문에 대한 답변을 정리하여 미리 제공하였고, 컨설팅 과정에서 API Gateway, Elastic Beanstalk, Application Load Balancer 등을 활용하는데 대한 개선점을 제안받거나, 신규로 활용하는 방안을 제안받았습니다.

이 과정에서 담당 어카운트 매니저로부터 핀다의 AWS 활용 수준에 대해 다양한 긍정적인 피드백을 받았습니다.

  • 본인이 담당하는 기업들 중 최고의 활용 역량을 보여주고 있다.
  • 컨설팅에서의 핀다의 질문 난이도가 높아서 쉽게 답변이 어려운 것들이 많다.
  • 비용 최적화가 이렇게 잘 된 기업은 처음이다.
  • 핀다의 AWS 활용 사례를 홍보에 활용하고 싶다.

결국, 핀다의 AWS 활용 사례를 마케팅에 활용하도록 동의하는 협약을 Amazon과 핀다 양사 간에 체결하였습니다.

이 글에서는 금융상품 추천 및 검색 서비스 핀다(https://www.finda.co.kr)를 개발하고 운영하면서 Amazon AWS를 다각도로 활용하고 여러 문제점을 해결한 경험 및 사례를 공유하고자 합니다. 이 글에서 다루고자 하는 AWS 서비스는 다음과 같습니다.

  • Elastic Beanstalk: 웹 애플리케이션 간편 배포, 운영, 오토 스케일링, 모니터링 등
  • Certificate Manage: 편리한 SSL 인증서 생성 및 설정
  • Application Load Balancer: 경로에 따른 웹 애플리케이션 트래픽 분기를 위해 활용
  • RDS: 데이터베이스의 TimeZone, General Log 설정
  • API GATEWAY: API생성, 게시, 유지관리, 모니터링 및 보호 서비스

이 외에도 핀다는 VPC, S3, CloudFront, Batch, Redshift, Elastic Search, Target Group, IAM, SecurityGroup, Lambda, CloudWatch, GuardDuty, WAF, Route53, SNS, DirectConnect, ReservedInstance등 다양한 AWS 서비스 및 기능을 활용하고 있습니다.

Elastic Beanstalk

AWS를 사용하여 웹서비스를 하는 경우 배포, 오토 스케일링, 로드 밸런싱, SSL 인증서 설정 등 다양한 작업이 필요합니다. 일일이 설정한다해도 별개 서비스들을 연관성있게 관리하기란 매우 어려운 일입니다. 서버 어플리케이션의 라이프사이클을 종합적으로 관리해주는 AWS 서비스가 Elastic Beanstalk입니다. 아래 그림과 같이 화면을 이용하여 애플리케이션 목록을 생성, 확인, 관리할 수 있습니다.

Elastic Beanstalk 메인 화면

Elastic Beanstalk Application 관리 화면
Elastic Beanstalk Application 선택 화면

어플리케이션을 선택하면 위와 같이 현재 어플리케이션의 상태와 실행 버전, OS 구성 및 최근 이벤트를 확인 할 수 있습니다. 배포를 긴급하게 이전 버전으로 되돌려야 하는 경우 Upload and Deploy버튼을 눌러서 이전 버전을 선택하면 됩니다.

Configuration overview

Elastic Beanstalk 애플리케이션 구성 설정 화면

Configuration 선택 화면인데 좀 복잡해 보이지만 주로 사용하는 기능을 살펴보겠습니다.

소프트웨어 설정

소프트웨어 설정 화면

먼저 소프트웨어 수정을 보면 웹서버 및 Node.js버전을 선택할 수 있습니다. 참고로 Node.js외에도 애플리케이션 생성 시 여러 플랫폼을 선택 할 수 있습니다. 그리고, Node command를 지정할 수도 있는데 공란으로 두면 npm start 커맨드로 실행 됩니다. 마지막으로 환경변수를 지정하면 생성된 EC2인스턴스에서 해당 변수를 사용할 수 있습니다.

인스턴스 타입

Elastic Beanstalk 인스턴스 설정

위 화면은 Elastic Beanstalk가 생성하는 EC2 인스턴스에 대한 설정인데 간단해 보이지만 EC2 인스턴스가 여러개일 경우 일괄적으로 인스턴스 타입 및 AMI를 변경 할 수 있어 편리합니다.

오토스케일링 설정

Elastic Beanstalk 용량 설정

용량설정에서 환경타입을 보면 Single은 하나의 EC2인스턴스만 사용하겠다는 의미이고 Load Balanced는 로드밸런서를 사용하고, 서버를 자동으로 추가하거나 제거하겠다는 의미인데, LoadBalanced를 선택한 경우 상황에 맞게 인스턴스의 최대값, 최소값, 증가, 감소 등을 설정할 수 있습니다. 해당 설정 값들은 서비스상황에 맞게 다각도록 트래픽 테스트를 하여 결정해야 합니다.

로드밸런서 설정

Elastic Beanstalk 로드밸런서 설정

Application Load Balancer는 단순히 트래픽을 분산시켜주는 역할 뿐만 아니라, SSL 인증서 설정할 수 있고 및 호스트 및 경로에 따라 요청을 분산할 수 있어 유용합니다. 참고로 비용이 서울 REGION 기준 시간(또는 부분 시간)당 0.0225 USD로 적지 않으므로 잘 고려하여 사용해야 합니다.

롤링 업데이트와 배포 설정

Elastic Beanstalk 롤링 업데이트와 배포 설정

롤링 업데이트 설정을 이용하여 여러개의 EC2 인스턴스가 가동 중인 상황에서 배포를 점진적으로 할 수 있고, EC2인스턴스를 새로 생성하여 배포 후 이전 인스턴스를 제거하는 방식으로, 서비스 중단 없이 배포 할 수도 있습니다.

배포 방식은 아래와 같습니다.

  • 한번에 모두
  • 롤링 (Elastic Beanstalk 환경의 EC2 인스턴스를 배치로 분할하여 배포)
  • 추가 배치를 사용한 롤링 (배포 중 전체 용량을 유지해야 하는 경우 인스턴스를 서비스에서 제거하기 전에, 새로운 인스턴스가 추가될 수 있다)
  • 변경 불가능 ( 변경 불가능한 업데이트를 수행하여 기존 버전을 실행하는 인스턴스와 별도로, Auto Scaling 그룹에서 애플리케이션의 새 버전을 실행하는 새로운 인스턴스 세트를 생성한다)
Elastic Beanstalk 보안 설정

보안설정에서는 role과 EC2 key pair를 설정 할 수 있는데, role은 AWS 서비스에 부여되는 권한으로 IAM 서비스를 통해서 생성하거나 기본으로 제공되는 role을 사용합니다. EC2 key pair는 보안 관리상 일정 기간마다 일일이 바꿔주어야 하므로 일괄 적용할 수 있어 편리합니다.

네트워크 설정

Elastic Beanstalk 네트워크 설정

네트워크 설정에서는 로드밸런서와 EC2의 가용영역별 서브넷을 지정 할 수있어 VPC를 함께 활용하여 보안수준을 높여서 AWS를 이용할 수 있게 해줍니다.

Certificate Manger

HTTPS로 웹서비스를 하기 위하여 SSL 인증서를 발급받아 서버에 설치하는 것은 번거로운 작업인데 AWS Certificate Manager를 이용하면 버튼 몇번 클릭만으로 인증서를 발급받을 수 있습니다. 단점은 발급받은 인증서를 서버가 아니라 ALB(Application Load Balnancer)에 설정해야 해서 ALB 를 꼭 사용해야 합니다. ALB 비용은 1 LCU(시간당 사용된 로드 밸런서 용량 단위)에 0.008 달러가 과금됩니다. 이미 ALB를 사용하고 있는 경우 유용합니다.

Certificate Manager 화면

설정 방법은 위 화면에서 Request a certificate을 클릭하여 발급받을 수 있고, 발급 받은 후 Route53 서비스에서 인증서 정보의 NAME, VALUE를 CNAME 형식으로 등록해줘야 합니다.

Load Balancer에 인증서를 설정한 화면

ALB (Application Load Balancer)

핀다 웹 서버는 기존에 ‘/post’가 포함된 경로에 대해 다른 웹 서버를 통해 서비스하였는데, HTTP 요청을 redirect 하지 않고 프록시 기능을 활용하였습니다. 이 때문에, 웹 서버를 AWS S3등을 활용하여 정적 웹사이트 방식으로 호스팅할 수 없었습니다.

웹 서버 내에서 프록시 하지 않고, 그 이전에 ALB에서 경로에 따라 분기하는 다음 그림과 같은 방식으로 아키텍쳐를 개선함으로, 웹 서버를 정적 웹사이트로 변경할 수 있었습니다.

ALB로 /post 요청을 다른 Target Group에 매핑

ALB 설정 과정을 소개하겠습니다.

LOAD BALNACING > Target Groups 선택 화면

라우팅하려는 대상 호스트가 AutoScaling되는 경우를 고려해서 설정해야 합니다. 라우팅 할 대상 그룹 생성합니다. 대상 탭에서 대상을 추가 해도 되지만 AutoScaling을 고려해야 되므로 의미가 없고 아래 화면과 같이 Auto Scaling Group 에서 Target Group으로 지정해 줍니다.

Auto Scaling Group에서 Target Groups를 설정

참고로 대상그룹의 인스턴스가 Unhealthy 상태라면 Health checks 탭의 Path를 확인하거나 SecurityGroup에서 Port가 등록되어 있는지 확인을 해봐야 합니다.

로드밸런서의 Listener탭에서 ‘View/edit rules’를 클릭하여 설정하는 화면

마지막으로 위 화면에서 Host, Path에 따라서 로드밸런서의 대상그룹을 지정할 수 있습니다.

이와 같이 하면 API의 경로 별로 다른 EC2 인스턴스 서버 혹은 Elastic Beanstalk 앱으로 분기하게 됩니다.

RDS(Relational Database Service)

RDS란 클라우드에서 관계형 데이터베이스를 더욱 쉽게 설정,운영 및 확장할 수 있도록 지원해주는 서비스입니다.

MySql Timezone 변경 방법

데이터베이스의 타임존이 현재 시간과 달라서 시간 확인 시 일일이 계산이 필요한 불편함이 있었습니다. 타임존을 맞추기 위해 MySql Timezone을 Asia/Seoul로 해두면 GMT시간을 별도로 고려하지 않아도 되므로 편리합니다.

설정 방법을 알아보겠습니다.

먼저 MySql에 접속 후 아래 코드를 이용하여 프로시저를 생성합니다.

DELIMITER |
CREATE PROCEDURE mysql.`store_time_zone`()
IF NOT (POSITION('rdsadmin@' IN CURRENT_USER()) = 1) THEN
SET SESSION time_zone = 'Asia/Seoul';
END IF |
DELIMITER ;
RDS의 Parameter groups 설정

RDS의 parameter groups 설정 화면에서 init_connect의 값으로 CALL mysql.store_time_zone을 넣고 리부팅 해주면 됩니다.

MySql 로그 수집

MySql에서 실행된 쿼리를 mysql.general_log와 mysql.slow_log를 통해서 확인 할 수 있는데 약간의 셋팅이 필요합니다.

위에서 init_connect 파라미터를 설정해 준 것 처럼 아래와 같은 값으로 설정하여 줍니다.

general_log = 1
slow_query_log = 1
log_output = TABLE

이제 로그용 테이블에 로그가 쌓이게 되고, 로그가 데이터베이스 용량의 20%까지 차지할 수 있고 용량을 다 사용하면 오래된 로그가 자동으로 삭제됩니다.

참고로 general_log는 실행 쿼리가 많아지면 용량을 많이 차지하게 되는데 정해진 규칙대로 제거되지만 rotate_general_log 명령어를 사용해서 강제로 제거 할 수 있습니다.

API Gateway

API Gateway란 API를 생성, 게시, 유지 관리 모니터링 및 보호할 수 있는 서비스입니다. 핀다 서비스는 API를 웹 애플리케이션 서버에 직접 호출하여 사용하고 있었는데 로그를 쌓는 것외에 API를 모니터링 및 관리할 방법을 찾던 중 API Gateway를 적용하게 되었습니다.

기존에 사용중인 서버의 API를 API Gateway를 통해 proxy하는 방법에 대해서 알아보겠습니다.

API Gateway API 작성 화면

먼저 위 그림의 API Gateway의 API 메뉴에서 API 작성을 클릭하여 생성합니다.

API Gateway 메서드 Import

Swagger 2.0 형식 JSON파일을 생성하여 위와 같이 한번에 Import할 수 있습니다. Import 완료 후 아래 그림에서 스테이지를 생성 한 후 배포합니다.

API Gateway Stage 생성
사용자 지정 도메인 이름 생성

배포가 완료된 후사용자 지정 도메인 이름을 위와 같이 생성하고 Route53에서 Target Doman Name을 원하는 도메인 이름에 매칭해 줍니다. 마지막으로 기본경로를 설정하면서 앞서 만든 스테이지를 선택해 줍니다.

설정이 완료되고 proxy되는 API 상태를 모니터링

여기까지 Elastic Beanstalk, Certificate Manage, Application Load Balancer, RDS, API GATEWAY 활용 방법에 대해서 살펴봤습니다.

다음 포스트에서는 VPC, S3, CloudFront, Batch, Redshift, Elastic Search, Target Group, IAM, SecurityGroup, Lambda, CloudWatch, GuardDuty, WAF, Route53, SNS, DirectConnect, ReservedInstance 등 다른 AWS 서비스 및 기능을 다뤄보겠습니다.

참고문서

--

--