목록DevOps (180)
devops
EKS에는 기본적으로 Cluster Autoscaler가 있다. Karpenter가 나오기 전에 유일하게 노드를 확장해주는 방식으로, 여러 프로바이더를 지원한다.그러나 CA는 하나의 자원을 두 주체(ASG, EKS)가 각자의 방식으로 관리하기 때문에 관리 정보에 싱크가 맞지않아 여러 문제가 발생한다. 대표적으로 EKS에서 노드를 삭제해도 인스턴스(노드)가 삭제되지 않는 현상이 있다. 또한, CA의 노드 스케일인 옵션이 적고 느리다. CA의 문제점들 AWS Auto scaling에만 의존하여, 직접적인 노드 삭제와 생성이 안됨 EKS에서 노드 삭제해도 인스턴스가 삭제되지 않음 노드 축소 시, 특정 노드 축소가 어려움 Pulling 방식이기 때문에 API 제한이 걸릴 수 있음 스케일링 속도가 아주 느림 Ka..
우리 팀에서는 실제 여러 클라우드 환경에서 서비스를 운영, 테스트하고 있기 때문에 서비스 별로 각기 다른 config 파일을 관리해야 한다. 처음엔 환경마다 Parameter store를 이용해 파일과 key들을 관리했지만 환경에 접속해서 매번 수정하는 게 아주 번거로웠다. 특히나 github action에서 action을 위한 secret 환경변수도 레포마다 관리하는 것이 쉽지 않았다. 이렇게 흩어져있는 설정 파일 혹은 key값들을 중앙화시킬 필요가 있었고, 쿠버네티스를 사용하기 때문에 모든 환경에서 작동하는 컴포넌트의 배포 상태와 흐름을 파악할 수 있어야 했다. 이 요구사항들을 바탕으로 Vault, ECR, ArgoCD가 사용되는 Github action CICD 파이프라인을 구축하게 되었다. EKS..
Vault의 시크릿 엔진은 data를 암호화하고 저장하고 생성하는, 어떤 기능을 하는 유연한 특징을 가진 컴포넌트로 보면된다. 어떤 시크릿 엔진은 단순히 데이터 저장과 읽기만 제공하지만, 어떤 것은 서비스와 연결되어 동적인 Credential을 생성하기도 하고 인증 역할을 하기도 한다. 모든 시크릿 엔진은 볼트의 path를 통해서 활성화된다. 그래서 볼트에 요청이 올때 자동으로 해당 경로로 라우팅되어 처리된다. 시크릿 엔진은 개별 경로(path)와 속성이 정해져있기 때문에 사용하는 유저입장에서는 Virtual Filesystem이라고도 볼 수 있음 Lifecycle Enable : 시크릿 엔진의 경로와 함께 Enable된다. (몇몇 시크릿 엔진은 여러 경로로 Enable이 될 수 있음) 각 시크릿 엔진은..
ServiceAccount에 적용된 Role의 신뢰관계 설정 문제일 가능성이 크다. ServiceAccount가 AWS 리소스에 접근할 권한이 없기 때문. $ kubectl describe sa aws-load-balancer-controller -n kube-system 먼저 ALB Controller의 SA를 상세 정보를 확인하면, 위와 같이 Annotation에 선언된 Role을 확인할 수 있음. 위에선 AmazonEKSLoadBalancerControllerRole이 SA의 Role로 선언되어 있음. AmazonEKSLoadBalancerControllerRole을 확인해보면 아래와 같은 신뢰관계가 구성되어있다. { "Version": "2012-10-17", "Statement": [ { "Ef..
Ingress 동작 방식 ALB Controller는 API 서버의 Ingress 이벤트를 모니터링한다. 요구 사항을 충족하는 수신 리소스 발견 시, AWS 리소스 생성을 시작한다. 수신 리소스에 맞춰 AWS에서 ALB(ELB v2)를 생성한다.(이 ALB는 인터넷 연결이 되거나 내부에 존재할 수 있으며 Annotation으로 서브넷 지정 가능) Target Group은 수신 리소스에서 지정된 고유 k8s 서비스에 대해 AWS에서 생성된다. 수신 리소스의 Annotation에 설명된 모든 포트에 대해 리스너가 생성된다. 포트는 80과 443이 디폴트며, Annotation에 인증서 첨부도 가능하다. 수신 리소스에 각 경로에 대한 규칙이 생성된다. 특정 경로에 대한 트래픽이 적절한 k9s 서비스로 라우팅된..
이더리움의 트랜잭션은 암호로 서명된 Data message다. 한 이더리움 account에서 다른 account로 ETH를 전송하거나, 블록체인에 배포된 Smart Contract와 상호작용하는 역할을 한다. 트랜잭션은 블록체인에 있어 아주 기본적이지만, 중요한 개념이기 때문에 관련 종사자라면 필수적으로 알아야하는 부분이기도 하다. 트랜잭션 Transaction 트랜잭션은 EVM 상태 변경을 위해 전체 네트워크에 Broadcast되어야 한다. 모든 노드는 EVM에 실행될 트랜잭션에 대한 요청을 Broadcast할 수 있어야하며, Broadcast된 후에는 Validator가 트랜잭션을 실행하고 상태가 변경된 결과를 네트워크에 전파한다. 이더리움 네트워크에서 트랜잭션은 Serialize되어 전송되는데, 각..
서비스 테스트를 위해서, 자체적으로 구축한 아비트럼 체인의 TxGas 수수료를 제로로 하는 테스트를 진행했다. 짧은 시간에 Tx가 많이 요구되는 서비스라면 사용자 경험을 최적화하기 위해서, 가스비를 0로 해야할 수 있다. 서비스 테스팅을 위해서 아래 local-dev-node 방식으로 일부 코드를 수정하여 체인을 구축했다. https://developer.arbitrum.io/node-running/local-dev-node Running a local dev node | Arbitrum Documentation Center 1. Install developer.arbitrum.io 아비트럼의 가스비는 ETH로 사용되며, Arbos의 L2Pricing 기능을 통해서 비용이 결정되는데, Arbos가 Nit..
[Arbos] nitro 노드는 아래와 같은 세가지 layer로 구성된다. base layer : evm contract 실행과 state를 구성하는 데이터 구조를 유지 관리하는 core 역할을 담당한다. nitro에선 필요한 hook를 추가하기 위해 몇가지 수정을 거쳐 이 코드를 라이브러리로 컴파일한다. middle layer : arbos로써, sequencer의 batch와 압축 및 해석, layer 1 가스비용 계산과 요금 징수 등 레이어 2의 추가 기능을 제공하는 custom s/w. 크로스체인 브릿지 기능을 지원한다. top layer : geth 에서 가져온 노드 소프트웨어로 구성된다. client로부터 접속과 RPC request를 처리하고 Ethernet 호환을 위한 노드를 작동시키는 기..
아비트럼이 현재 옵티미즘 롤업 기반 L2 사이에서 높은 TPS를 자랑한다. 많은 Layer 1 프로젝트들이 Layer 2 연구에 옵티미즘을 많이 사용하는 만큼, 가장 빠른 아비트럼으로 테스트를 진행해봤다. 조만간 Orbit이 출시하면 더 친절한 자료들이 나오겠지만, 시급한 서비스 테스트를 위해 현재 Arbitrum Nitro를 L1인 위믹스3.0 테스트넷에 연결시켰다. https://developer.arbitrum.io/node-running/local-dev-node Running a local dev node | Arbitrum Documentation Center 1. Install developer.arbitrum.io 위 링크에 들어가면 Local 환경에서 docker-compose로 손쉽게 ..
아비트럼에서 다양한 컴포넌트에 대한 설명부터, 클라이언트가 서명한 트랜잭션이 생성되어 레이어 1에서 컨펌되는 과정을 단계별로 정리해본다. 지난 포스팅에서 블록체인의 간단한 구조를 정리했는데, 트랜잭션의 라이프사이클만 확인해도 전체적인 프로세스를 이해하는 데 많은 도움이 된다. 1. Sequencer의 트랜잭션 수신 트랜잭션 라이프사이클의 시작은 Sequencer가 클라이언트로부터 트랜잭션을 수신하면서 시작된다. Sequencer는 두 가지의 방법으로 트랜잭션을 수신한다. Directly/Offchain 아비트럼의 Dapp에서 발생하는 트랜잭션은 클라이언트가 지갑을 L2 노드에 연결하여 서명된 트랜잭션을 직접 전달함 Delayed Inbox 클라이언트는 아비트럼의 Delayed Inbox에 L1 트랜잭션에..