전체 글

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

이번에는 간단한 프로젝트를 Github Actions를 통해 CI/CD 파이프라인을 구성하고 테스트해보도록 한다. 초기 세팅 먼저, 테스트에 사용할 Repository를 하나 생성해준다. 이 Repository를 clone해주고, 내용을 추가한다. 이번에는 따로 코드를 작성하지 않고, Spring 프로젝트를 하나 가져와서 추가해주었다. GitHub - spring-projects/spring-petclinic: A sample Spring-based application A sample Spring-based application. Contribute to spring-projects/spring-petclinic development by creating an account on GitHub. gith..

Github Actions Github Repository를 기반으로 빌드/테스트/배포의 Workflow를 자동화할 수 있는 CI/CD 도구 다른 CI/CD 도구들과 비교했을 때, Github Actions는 딱 Github 플랫폼 하나에서만 모든 CI/CD 과정을 처리할 수 있다는 점이 존재하며, Github이 Workflow를 처리할 수 있는 환경을 자체적으로 제공하기 때문에 Jenkins와 같이 따로 처리환경을 생성하지 않고도 간단하게 사용할 수 있다는 점이 장점으로 존재한다. Github Actions 단위 개념 Workflow Github Actions에서의 최상위 개념으로, 자동화시켜놓은 작업의 전체 과정/흐름이다. 각 Repository의 최상단에서 .github/workflows 디렉토리 ..

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..

컨테이너 설정파일을 관리하는 방법으로는 컨테이너 이미지를 빌드할때에 복사하거나, 컨테이너를 실행했을 때에 외부 호스트에서 파일을 연결해주는 방법이 있다. 쿠버네티스에서는 ConfigMap 리소스를 통해 설정파일을 관리하는 방법을 제공한다. ConfigMap 컨테이너의 환경설정 값을 저장하기 위한 리소스로 키-값 쌍의 데이터를 저장한다. ConfigMap에는 주로 Application의 설정값, 컨테이너의 환경변수, 설정파일과 같은 데이터를 저장한다. 아래는 ConfigMap을 정의하는 Manifest이다. apiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: NGINX_PORT: "8080" NGINX_SERVER_NAME: "my-ngin..

이번에는 쿠버네티스에서 데이터를 저장하는 Volume을 정리해보도록 한다. Volume 컨테이너가 데이터를 저장하고 공유하는 방식을 제공하는 객체, 기존 컨테이너에서의 Volume과 유사하나 더 유연하게 사용할 수 있다. 이전의 Service를 정리했을때에 알아보았듯이 컨테이너는 일시적인 특성을 가져 일반적으로 컨테이너가 삭제되면 컨테이너에 저장된 내용들이 휘발되는 점이 존재한다. 특히나 데이터베이스와 같은 리소스는 파드나 컨테이너가 삭제되더라도 내부의 데이터를 보존을 해주어야하는데, 여기서 Volume을 사용하게 된다. 쿠버네티스에서 제공하는 Volume의 종류는 아래와 같다. emptyDir hostPath PV/PVC emptyDir 파드 내에서만 지속되는 컨테이너의 임시적인 데이터를 저장하기 위한..