Cloud

이번에는 EC2 인스턴스의 Metric을 Prometheus로 수집하고, Grafana까지 연동까지 진행해보도록한다. Prometheus와 Grafana가 연동된 아키텍쳐 구조를 먼저 보도록한다. 각 노드들의 node-exporter로 부터 Prometheus 서버가 metric을 Pull해오고, Grafana가 Prometheus 서버에 PromQL을 날려 쿼리 결과를 가져와 Dashboard 형태로 보기좋게 구성을 해주게 된다. Prometheus 설치 수집한 Metric 데이터를 모을 인스턴스에 Prometheus를 설치한다. 공식 페이지에서 Prometheus 설치는 바이너리 / 소스 / Docker 이미지 형태로 제공한다. 이 글에서는 Docker 이미지를 받아 컨테이너 방식으로 설치하도록 한다..

서버나 서비스 등의 운영에 있어서 모니터링은 필수 요소이다. 개발 Language 못지않게 모니터링 툴/시스템들도 굉장히 다양한 종류가 존재하고 새롭게 생겨나고 있다. 나는 기존에는 Cloudwatch Agent나 Logstash + Datadog 등을 이용해서 서버나 서비스에서 발생하는 데이터들을 모니터링하도록 구성했었다. 다만, Datadog의 요금정책 등의 이슈들로 인해 다른 모니터링 도구 탐색을 하게 되었다. 그렇게 최근들어 알게된 Prometheus를 적용하고 깊게 공부해보고자 해서, 이 시리즈를 작성하기로 했다. 이번에는 Prometheus의 기본 개념과 특징을 알아보도록한다. Prometheus Metric 수집 모니터링 오픈소스 프로젝트, SoundCloud사에서 개발했으며 CNCF 소속 ..

AWS의 다양한 서비스들을 이용하다 보면 리소스를 생성하는 과정을 마주하게 된다. 그 과정 속에서 간간히 KMS라는 단어를 볼 수 있는데, 대부분의 상황에서 이 KMS 설정은 기본값으로 두거나 아예하지 않고 넘어갔었다. 매번 마주했지만 그 기능에 대해 깊게 공부해본 경험은 없었다. 그나마 SAA 공부할 때 잠깐 얕게 공부해본게 전부라 이 참에 내용을 정리하는 겸 KMS를 활용해보도록 한다. KMS Key Management Service, 데이터를 암호화할때 사용되는 암호화 Key에 대한 전체적인 관리를 해주는 서비스 암호화 Key의 클라우드 서비스를 통해 중앙 집중식으로 관리해준다는 목적을 가진다. KMS의 대표적인 특징은 아래와 같다. 특징 내용 중앙집중식 제어 KMS 키의 수명 주기와 권한을 중앙집..

바로 앞 글에서 Network Firewall의 개념을 알아보고 간단한 아키텍쳐를 구성했다. 실제 방화벽이 VPC에 연결되어 트래픽 차단을 수행도록 하기 위해 VPC 네트워킹 작업이 더 필요하다. Firewall Endpoint가 활성화된 것을 확인 후, 라우팅 테이블 설정을 진행한다. 라우팅 테이블 설정 트래픽이 정상적으로 흐를 수 있도록 각 서브넷들의 라우팅 테이블 설정을 해주어야 한다. 라우팅 테이블을 적용한 아키텍쳐의 구성은 아래와 같다. 먼저, Firewall Endpoint가 위치한 Pub-NFW-a와 Pub-NFW-c의 라우팅테이블을 작성한다. 0.0.0.0/0의 인터넷 게이트웨이로 타고 나갈 수 있도록 구성한다. 다음으로 서비스가 있는 Pub-a와 Pub-c의 라우팅테이블을 작성한다. 여기..

지금까지 AWS 클라우드 환경에서 Application의 보안책으로 WAF(Web Application Firewall)를 주로 이용하였다. 대상들이 모두 웹 서비스였기도 했고, WAF와 ALB 정도의 구성으로 비교적 간단하게 문제없이 운영했었다. 이후에 새롭게 맡은 클라우드 서비스의 보안 아키텍쳐 구성 업무에서 L7의 웹 트래픽 뿐만 아니라 L3/4와 같은 네트워크 레벨에서의 트래픽도 커버할 수 있는 구성을 요청받게 되었다. 그리고 유입되는 네트워크 트래픽을 바탕으로 차단을 수행하고 로깅하는 기능까지 요구사항으로 요청하셨다. 원래 이정도 스케일의 요구사항이면 3rd party 어플라이언스를 도입하는 것이 맞다고 생각했으나, 비용 등의 이유로 추진할 수 없었다. 그렇게 찾은 방안이 오늘 소개할 Netwo..

이번엔 Terraform의 꽃으로 불리는, 처음에는 조금 이해하기 어려운 개념인 Module을 알아보도록 한다. Module Terraform 코드들을 관련되어있는 것끼리 그룹으로 모아서 하나의 패키지 형태로 구성한 것 이때, 하나의 그룹으로 묶이는 단위는 '폴더'가 되며, 이 폴더 내의 테라폼 코드들이 모듈이 된다. 개발을 해본 사람이면 쉽게 라이브러리 개념으로 바라볼 수 있다. 정의해둔 라이브러리를 다른 프로젝트나 코드에서 import해서 사용하는 것같은 느낌이다. Module의 장점 재사용성 Module은 코드의 재사용성을 높일 수 있다. 한번 작성해놓은 인프라 리소스 모듈을 다른 인프라나 프로젝트에서 호출함을 통해 개발비용을 줄이고 일관된 구조를 유지할 수 있다. 구조화와 가독성 본래 Terraf..

Azure도 공부할 겸 계정을 하나 파기로 했다. 학교이메일이 살아있는 기간 동안에 최대한 먹을거 다 털어먹어보자는 마인드로 찾아본 결과, Azure for Students라는 서비스를 발견했다. Azure for Students MS에서는 대학교 이메일만 있으면 학생용 Azure 계정을 생성해 사용할 수 있도록 한다. $100 양의 크레딧을 주고, 가입할때에 카드정보를 등록할 필요가 없다고 한다. 보통 다른 퍼블릭 클라우드 서비스들 가입할때에는 카드정보를 입력받지만, Azure for Students는 가입 당시 등록하지 않고 크레딧을 다쓰거나 기간이 끝나면 그때 카드정보를 등록해 종량제로 전환하는 방식이라고 한다. 카드정보를 미리 등록하지 않으니 크레딧 기간동안은 혹시나 발생하는 과금폭탄을 맞을 일은..

이전 글에서 DeepRacer 모델을 직접 생성해 보았다. 이번에는 이 모델을 평가해보고 Race에 제출해본다. 모델 평가 생성한 모델을 Race에 제출하기 전, 트랙에서 돌려보는 최종 평가를 진행한다. Evaluation에서는 episode 횟수를 지정하고, 그 결과값(완주 시간, 완수율, off-track 횟수, 패널티 시간 등)들을 직접 확인할 수 있다. 생성한 모델 > Evalutaion > Start New Evaluation 모델 이름과 Race Type을 지정한다. 평가를 하기 위한 trial 수와 트랙을 지정한다. 가장 하단은 해당 Evaluation 기록을 공식 open Race에 제출할 것인지 여부를 묻는 항목이다. 이렇게 Evaluation을 제출하면 각 trial에 대한 정보와 시뮬..