전체보기

AWS CognitoCognito는 사용자 인증을 위한 서비스로 'User Pool'에 등록된 사용자를 인증하고, OAuth나 OpenID Connect 표준에 따라 Access/ID/Refresh Token을 발급해준다.이 Token을 통해 Application이나 서비스 API에 접근할 수 있도록 인증/인가할 수 있고, 'Identity Pool'과 연동해서 AWS 리소스 접근 권한도 관리할 수 있다. 이번에는 Lambda와 Integration된 API Gateway와 Cognito를 통해 JWT 토큰을 발급받아 API gateway의 API들에 접근하도록하는 아키텍처를 구성해보도록 한다. 사용자가 Cognito로 부터 인증 Token을 발급 받고,API Gateway에 연결된 각 리소스와 메소드..

기존 프로젝트에서 사용했던 Elastic Transcoder는 Rekognition API(FaceSearch)를 통해 비디오에서 특정얼굴이 탐색된 구간(timestamp)들을 하나로 묶어주는 'Clip Stitching'을 수행하기 위해 포함되던 서비스였다. 최근 확인한 바로 Elastic Transcoder가 2025년 11월로 서비스 종료한다는 이슈가 있었다.그에 따라 이 서비스를 대체할 것을 찾아야했고, 공식에서 대체 서비스로 추천해주는 MediaConvert를 찾게되었다. MediaConvert는 기존의 Elastic Transcoder가 지원했던 영상관련 트랜스코딩 등의 기능을 그대로 가지고 있고, 자막이나 워터마크같이 더 확장된 기능들을 지원하고있다.기존 Elastic Transcoder에..

App-of-AppsApp들을 관리하기 위한 App이라는 의미로, argoCD와 같은 GitOps에서 '상위' App이 다수의 '하위' App들을 묶어서 관리하는 구조App들 간의 계층을 둔 구조로 보면 된다. 이때, 상위 App을 "Root App"이라 하며, 하위 Application을 포함한 구조를 가진다. 간단하게 보면 계층화된 회사의 구조로 볼 수도 있다. CEO와 각 부서별로 부서장의 관계에서, CEO는 전사 전략을 세우고, 각 부서장들에 세부적인 수행내용을 지시하고, 부서장들은 각자 프론트엔드/백엔드/DB등의 세부적인 본인 부서들을 운영하는 것이다. 아래와 같은 서비스들을 배치하는 쿠버네티스 클러스터를 예로 들어보자..└── deploy └── kubernetes ├──..

앞서 쿠버네티스 클러스터에서 Prometheus를 구축할 수 있는 Prometheus Operator에 대해서 개략적으로만 알아보았다.Prometheus Operator의 CRD들을 통해 간편하게 Prometheus 스택을 설치하고, 서비스 중단없이 스크래핑 대상을 추가할 수 있는 등의 장점을 봤는데, 이번에는 직접 Prometheus에 스크래핑 Job을 동적으로 추가할 수 있도록 알아본다. Exporter하드웨어나 프로세스로부터의 Metric을 수집해서 Prometheus가 스크래핑해갈 수 있도록 서빙하는 객체Application이나 시스템이 자체적으로 노출하지 않는 내부의 지표들을 Prometheus가 이해할 수 있는 포맷으로 변환해준다.즉, 현지어(각 Application 별 Metric)를 영어(..

앞서 Prometheus와 Exporter 아키텍처를 구축해보면서 node-exporter를 통해 메트릭을 가져오는 것을 알 수 있었다.prometheus 설정파일에 exporter의 정보를 추가하면서, Prometheus가 Scraping할 대상을 등록했었다. [Observability] Prometheus & Grafana 연동이번에는 EC2 인스턴스의 Metric을 Prometheus로 수집하고, Grafana까지 연동까지 진행해보도록한다. Prometheus와 Grafana가 연동된 아키텍쳐 구조를 먼저 보도록한다. 각 노드들의 node-exporter로 부터 Promethblog.omoknooni.me 그렇다면 쿠버네티스 환경에서는 어떨까?쿠버네티스 환경에서도 마찬가지로 Prometheus를 직..

최근 진행하고 있는 쿠버네티스 기반의 서비스 플랫폼 프로젝트에서 각 서비스들의 빌드 과정을 자동화하기 위한 과정이 있었다.현재 관리하는 서비스들은 4개로, 각각 별도로 고유한 컨테이너 이미지가 존재한다.여기에서 Github Actions를 이용해 각 서비스 별로 변경점의 push가 발생하면, 그에 맞는 서비스 이미지를 새로 빌드해서 허브에 push하도록 구성하고자 했었다. 여기서 들었던 의문점은 '이 4개의 서비스를 어떻게 워크플로우로 빌드 과정을 작성할 수 있을까' 라는 것이였다.물론 각 서비스별로 빌드 Job을 생성해서 코드로 작성하면 구현은 되는 것인데, 그러면 중복이 생기게 되고 워크플로우 코드와 추후의 유지보수가 복잡해진다는 점이 다가오게 되었다.name: CI - Build & Push to ..

앞서 Github Actions를 통한 Application CI/CD와 ArgoCD를 통한 클러스터 CD 파이프라인에 대한 글을 작성했다.다만, Github Actions CI/CD에서 CD 부분은 CI에서 빌드한 내용을 Artifact로써 CD Job에서 사용하고, SSH 연결을 통해서 직접 운영 서버에 Deploy해주는 방식으로 구성했기에 아래와 같은 문제점이 거론될 수 있었다. 기존 Github Actions CI/CD의 이슈특정 서버에 강하게 의존이 배포는 SCP로 파일을 전송하고 SSH 연결을 거쳐 배포 스크립트를 실행하는 방식으로 되어있음따라서 특정 원격 서버와 배포 스크립트에 강하게 의존하고 있어서 확장성과 서버 장애나 IP 변경에 배포 실패 가능성을 가짐상태 관리 불가Workflow가 동..

ArgoCD쿠버네티스 환경에 친화적인 선언적 GitOps CD 도구GitOps?Git 저장소에 정의된 상태와 실제 환경의 상태를 지속적으로 비교하고 동기화하는 방식Git 저장소만이 오직 유일한 진실된 원천(Single Source of Truth)임을 원칙으로 삼는다⇒ “선언형” 방식에 초점을 두고, “원하는 상태”를 정의하고 이를 실제환경에 반영하려는 철학 Syncrepository의 코드 상태(Desired State)와 클러스터의 Application의 상태(Live State)를 비교해서 일치시키려는 작업두 상태의 비교 결과에 따라 Synced / OutOfSync로 나뉘는 것을 볼 수 있다. argoCD에서는 Application과 Project라는 단위로 리소스를 정의한다.Application..