Domain HealthChecking on AWS Cloud
오픈채널서비스팀과 AWS?
저희팀에 대해 간단히 소개하자면, KT ITO업무를 수행하며 크게 마이케이티, 케이티샵, 케이티닷컴, 온라인/스마트신청서, MVNO 파트로 나뉘어집니다.
오픈채널서비스팀원들은 이미 사내망으로 확인할 수 있는 모니터링 툴이 존재합니다. 대표적으로 와탭(WhaTap)이나 다양한 오픈소스 솔루션이 있지만, 이것을 사외망으로도 손쉽게 어디서든 확인할 수 있는 방법이 무엇일까 하며 가벼운 마음으로 AWS을 접했습니다.
팀원들은 각각 다른 직무를 수행하며 온프레미스에 익숙한 팀원들과 클라우드 환경에 익숙해지고 기술역량향상을 목적으로 진행 중에 있습니다.
1. AWS Architecture
사용한 AWS 서비스에 대한 간단한 설명입니다.
AWS 서비스 | 서비스 기능 및 역할 |
Route 53 | DNS 설정 관련 서비스 |
IAM (Identity and Access Management) | AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스 |
ACM (AWS Certificate Manager) | AWS 서비스 및 연결된 내부 리소스에 사용할 공인 및 사설 SSL/TLS 인증서를 관리 |
S3 (Simple Storage Service) | 정적파일 스토리지 (파일을 저장하기 위해 사용할 수 있는 서비스) |
NAT gateway | 외부 서비스에서는 프라이빗 서브넷 내의 인스턴스와의 연결 할 수 없도록 하기 위해 NAT 게이트웨이를 사용 |
ALB (Application Load Balancer) | AWS에서 제공하는 로드밸런서 중 하나로 OSI Layer7인 어플리케이션 계층에서 동작하는 로드밸런서 |
ECS (Elastic Container Service) | 컨테이너 애플리케이션을 쉽게 배포, 관리 및 확대할 수 있도록 도와주는 완전 관리형 컨테이너 오케스트레이션 서비스 |
AWS Fargate | 컨테이너를 지원하는 서버리스 컴퓨팅 엔진으로 서버를 관리하지 않고 사용한 만큼만 비용을 지불 |
RDS (Relational Database Service) | 관계형 데이터베이스를 간편하게 클라우드에서 설정, 운영, 확장이 가능하도록 지원하는 웹 서비스 |
AWS Cloudwatch | AWS 리소스 전반의 데이터를 수집하여 전체 시스템의 성능을 파악할 수 있도록 하는 모니터링 서비스 |
ECR (Elastic Container Registry) | AWS 관리형 컨테이너 이미지 레지스트리 서비스 |
AWS Codepipeline | CodeCommit, CodeBuild, CodeDeploy를 하나의 프로세스로 통합시켜주는 CI/CD 도구 |
아키텍처 설계를 위와 같이 판단한 이유는 아래와 같습니다.
먼저 URL healthchecking 부분은 스프링부트 스케줄러를 이용해서 소스단에서 확인해볼 계획입니다.
개발소스 부분을 Gitlab 통해서 공유를 하며 코드파이프라인을 구축해 커밋을 할때마다 감지되어 빌드를 진행합니다. 물론 이부분은 제어가 가능합니다.
빌드/배포된 소스는 ECR, 엘라스틱컨테이너레지스트리에 저장되며 ECS의 간단한 작업정의를 통해 task 로 배포하게됩니다. 이것이 서비스고 컨테이너입니다.
데이터베이스의 경우에는 저희가 관리해야할 도메인부분을 저장할 용도로 사용할예정이며. 그림상 2개로 보여지는 것은 백업용 DB입니다. 하지만 저희는 비용절감을 위해 한 개의 DB만 사용할 계획입니다.
S3의 경우 simple storage service고 흔히 알고 계시는 하드디스크나 SSD와 같은 저장장치 입니다. 도메인 헬스 체크 중 에러 발생시 저장될 로그를 S3에 위치시킬 예정입니다.
네트워크 측면으로 확인해보면, public subnet과 private subnet이 존재합니다. 프라이빗서브넷의경우에는 내부망이라고 생각해주시면 되고 내부망은 외부망으로 나갈수 없기 때문에 NAT gateway를 퍼블릭 서브넷에 구축해두었습니다. 이렇게되면 in은 ALB(host header/path로 분류)로, out은 NAT로 네트워크가 구성됩니다.
이렇게 구축된 모든 AWS서비스들은 cloudwatch를 통해 로그/그래프로 분석및 확인이 가능하며 애플리케이션 개발에 집중할 것으로 예상됩니다.
최종적으로는 저희 ds임직원이 외부망을 통해 지정된 도메인, 라우트53을 통해 도메인을 구매하여 매핑해줄 예정이며 (e.g. helathcheck.kt.com), SSL 인증서 또한 AWS 제공해주는 certificate manager(ACM)를 통해 해결할 예정입니다.
2. 구상한 화면설계서
간단한 화면 설계서입니다.
케이티닷컴 클릭시 DB에서 URL을 가져와 호출해 200 OK 응답을 받게 되면 OK로 표기하고 그렇지 못한경우 워닝표시로 나타나며 케이티닷컴(KT.com) 관계자분들에게 알람이 가게 됩니다.
알람이 전송되는 방법에 대해서는 AWS SNS를 사용하거나 소스 자체적으로 작성할지 검토중 입니다.
도메인 등록/삭제 기능의 경우 임직원이 아닌 특정 유저가 사용할수 있는 위험으로 관리자 테이블을 사용하여 테이블에 등록된 인원만 제어할 수 있게 할 예정입니다.
3. 마치며
ITO 업무만 주로 진행한 팀원들로선 AWS 클라우드의 기본적인 용어와 클라우드의 개념을 인지는 하지만, 사용하기 어려움이 있습니다. 이에 따라 저희는 기본개념과 기본용어들을 학습하며 클라우드를 무작정 접하는게 아닌, 조금씩 클라우드에 다가가고 있습니다. 결과적으로는 현재 팀원들도 AWS 기본인 3-tier 구조와 code pipeline까지 구성완료한 상태며 클라우드에 대한 자신감이 향상되었습니다.
이런 어려움을 팀원들과 다같이 부족한 것을 공유하며, 해결해 나가는 모습은 각자 개개인이 뿌듯함을 느끼고 있을 것이라 생각합니다. 차근차근 한발짝씩 나아가면, 저희도 AWS cloud에 대한, 나아가 다른 퍼블릭 클라우드도 아우르는 멀티클라우드 개발/운영 담당자가 되어 있을 것이라 확신합니다.