Cloud

앞서 Terraform cloud를 소개하며 Workspace에서 AWS 인프라를 Apply하는 것을 알아보았다. 이 과정에서 AWS Credential을 Workspace에 변수로 두어서 적용했는데, 이렇게 장기 Credential을 발급하고 입력해두는 것은 여러 단점들을 가지고 있긴하다.Credential의 노출 : Credential 자체를 직접적으로 삽입해주기에 노출이 발생할 수 있다.주기적인 교체작업 : 장기 Credential을 보다 안전하게 사용하기 위해서는 주기적인 Credential 교체작업이 필요하다.이를 해결하기 위해 Terraform Cloud에서는 Dynamic Provider Credential 기능을 제공한다.Terraform을 통해 구성할 수 있는 다양한 CSP들에 대한 Pr..

앞서 우리는 로컬에서 Terraform 코드를 작성하고, CLI를 통해 적용(Apply)하면서 Terraform을 사용하고 있었다.인프라를 코드로 관리하는 IaC에 목적에 맞게 사용되긴하지만, 팀 간의 협업 속에서 상태(state)관리와 자동화 파이프라인 등에 있어서 분명 아쉬운 부분이 존재했다. 서비스 개발운영에서는 Jenkins나 Github Actions, ArgoCD와 같은 툴들을 통해 통합 빌드/배포 과정을 구현해왔지만, 인프라 개발운영 부문에서는 최적화된 플랫폼은 CSP 별로 존재하는 IaC 서비스외에는 마땅히 존재하는 것이 없었다. 이에 등장한 Terraform Cloud를 알아보도록 한다. Terraform CloudHashicorp에서 운영하는 Managed 서비스 플랫폼으로, 개인을 넘..

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에 연결된 각 리소스와 메소드..

앞서 쿠버네티스 클러스터에서 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를 직..

서비스나 파이프라인을 구성하면 Lambda나 SQS 등등 클라우드 서비스를 여러개 사용해서 워크플로우를 구성하게 된다.하지만, 구성이 커지면 이러한 워크플로우의 구성요소들 간의 로직이 복잡해지게 된다.AWS 서비스들을 통해 워크플로우를 간단하게 구성하고 시각화시켜 흐름을 파악할 수 있는 Step function에 대해 알아보도록 한다.  Step FunctionAWS 서비스들을 한데 묶어 일련의 작업 파이프라인을 생성할 수 있는 서비스Workflow Studio를 통해 작업들을 직접 배치하고 시각적으로 확인할 수 있다는 특징이 있다.  Step function은 '상태 머신[State Machine]'이라는 개념으로 워크플로우를 구성한다. [상태 머신 == 워크플로우]그리고 상태 머신의 각 단계는 ASL..

클라우드 서비스를 이용하다보면 이벤트 발생에 맞춘 로직 수행이나 주기적인 자동화를 수행해야할 경우가 존재한다.예를 들어, 워크로드 상에 존재하는 작업들의 이벤트 기반 상호작용이나 매일 새벽에 하루동안의 로그들을 바탕으로 보고서를 작성하는 등의 작업이 있을 것이다. 이러한 작업을 위해 Eventbridge의 Rule과 Scheduler를 이용할 수 있다.이번에는 Eventbridge의 구성요소와 이들을 활용한 간단한 자동화를 구성해보도록 한다. Eventbridge이벤트를 Application 요소들과 연결할 수 있는 서버리스 '이벤트 버스' 서비스, 이전에는 Cloudwatch Events로 불렸고, 현재는 Eventbridge로 명칭이 변경되었다고 한다.S3, EC2와 같은 AWS 서비스들에서 발생하는..

여러 AWS 서비스에서는 사용자를 대신해서 작업을 실행하기 위해 IAM Role을 부여한다. 그 과정에서 AssumeRole과 PassRole을 자주 볼 수 있는데, 이 둘은 간혹 보면 햇갈리는 점이 있다.이번에는 이 둘이 각각 어떤 기능이고, 어떤 차이점이 존재하는 지 알아보도록 한다. AssumeRole한 IAM Role이 다른 Role의 권한을 일시적으로 가져와서 사용할 수 있도록 하는 기능AssumeRole은 IAM이 아닌 STS(Security Token Service)라는 서비스의 Action으로 분류된다. Assume Role을 통해 User/Role은 자신에게 부여된 권한을 넘어 다양한 추가 권한을 임시로 얻어서 누릴 수 있게 된다.더불어, AssumeRole은 동일한 계정 내의 Role ..