EKS의 관리영역중 Addon 이나 필수 컴포넌트중에 Node에서 동작해야하는 것들이 있다. 이 경우에 NodeGroup을 운영해야한다. NodeGroup에 여러 파드들이 스케줄링되고 관리형 Pod들은 다른 서비스에 운영되는 NodeGroup과 섞여서 스케줄리되어야 하는데, 이것의 가장큰 문제는 Node의 사망이 기능의 장애로 이어진다는 점이다. 따라서 Node를 전용 Node로 사용하면 좋은데 아주작은 노드를 스케줄링한다고 해도 관리되어야 하는 대상이 됨은 틀림없고, 노드를 정해서 사용해야 하는 문제점들이 생기게된다. 이러한 문제를 해결하기에 EKS에서는 Fargate가 있다. 1Node - 1Pod 라는게 아주 중요한 포인트다. ...
일단 SQS를 터질때 까지 밀어넣어 보기로 했다. 목표 메시지수는 100만건. 100만건의 메시지를 100초안에 SQS에 넣는게 목표다. TPS 10000 이라는 소리다. 목표를 이루기위해선 첫번째 SQS의 TPS는 3000이다. 초당 3000의 메시지를 넣을수 있다. 먼저 큐를 4개를 만들었다. 목표수치에 가려면 TPS가 10000은 나와야한다. 그렇다면 큐를 병렬로 줄세운다 4개의 큐를 만든다. 이제 넣어봤다. import boto3 import json import uuid from concurrent.futures import ThreadPoolExecutor import random import string sqs = boto3.client('sqs') queue_urls = [ 'linuxer-sqs-1', 'linuxer-sqs-2', 'linuxer-sqs-3', 'linuxer-sqs-4' ] def random_string(length): return ''.join(random.choices(string.ascii_letters + string.digits, k=length)) def create_dummy_data(): return { 'id': str(uuid.uuid4()), 'data': f"host-{random_string(5)}-count", 'padding': random_string(10 * 1024 - 100) # 10KB 크기의 더미 데이터를 생성 } def send_message_batch(queue_url, messages): entries = [] for idx, message in enumerate(messages): entries.append({ 'Id': str(idx), 'MessageBody': json.dumps(message) }) response = sqs.send_message_batch( QueueUrl=queue_url, Entries=entries ) return response def generate_and_send_dummy_data(num_messages=100000, batch_size=10, num_threads=10): with ThreadPoolExecutor(max_workers=num_threads) as executor: for _ in range(num_messages // (batch_size * num_threads * len(queue_urls))): batch_futures = [] for queue_url in queue_urls: messages = [create_dummy_data() for _ in range(batch_size)] future = executor.submit(send_message_batch, queue_url, messages) batch_futures.append(future) for future in batch_futures: future.result() if __name__ == '__main__': generate_and_send_dummy_data() 대충 이코드는 TPS 100 정도이다. ...
이제야 블로그가 손에 잡혀서 오랜만에 글을 쓰기위해 책상앞에 앉았다. 이게다 내 게으름 때문이다. 맨날 이 뻔한 핑계를 치면서 한번 웃고야 말았다. 이번에 쓸 블로깅은 T101에서 한번 발표한 적인 있는 내용이다. 이 포스팅에선 EventBridge와 CloudTrail을 집중적으로 다룬다. https://nyyang.tistory.com/126 이블로그를 보고 작업을 시작했다. 먼저 시작하기전에 EventBridge Bus 규칙에서 Trail에서 패턴을 감지하기위해선 이벤트버스는 무조건 Default여야한다. 다른 버스에 만들면 버스 지나간 다음 손 흔들어야 한다. 패턴을 감지할수 없다는 이야기다. 골자는 이렇다. CloudTrail 에서 발생하는 이벤트를 EventBridge 는 특정 패턴을 감지해서 이벤트를 발생시킬수 있다. ...
가시다님과 스터디를 한지도 5번째 이번엔 테라폼이다. 오늘 블로그를 쓰게된건 중간과제를 설명하기 위해서다. 바로 본론으로 들어간다. 내 GIT 이다 https://github.com/Cloud-Linuxer/T101/tree/main/4week variable "availability_zone" { description = "Seoul region availability zone" type = list default = ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c", "ap-northeast-2d"] } variable "subnet_numbers" { type = list default = [10, 20, 30, 40] } variable "az_count" { type = list default = ["A", "B", "C", "D"] } 나의 Variables는 이런식으로 구성되어있다. 모든 타입을 List로 선언하여 사용한다. 5주차에 할 테라폼 의 반복문을 사용하기 위한 형태다. 가장 중요한 부분은 subnet_numbers 부분이다. 10, 20, 30, 40 이 핵심이다. ...
S3는 청크 단위로 파일을 잘라서 업로드 할수있는 기능을 제공한다. 이 기능의 정식명칭은 multipart upload 이다. https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html MPU라고 줄여서 부른다. MPU는 업로드 속도를 빠르게 해줄수있는 아주 좋은 기능이지만, 업로드에 실패할 경우 완성되지 않은 청크단위의 파일들이 S3스토리지에 저장되게 된다. 업로드가 정상적으로 이루어진 경우 청크단위로 나뉜 파일을 하나의 파일로 합쳐서 객체로 보이게 되지만, 그렇지 않은 파일은 우리의 눈에 보이지 않지만 S3의 스토리지에 비용만 발생시키며, 하등 쓸모없는 상태로 저장만 되어있는다. 이런 경우를 "incomplete multipart uploads" 라 부른다. ...
가시다 님과 함께하는 CASS 스터디를 시작했다. 첫시간은 OU / IAM과 함께하는 즐거운 시간. MSP에서 OU는 열심히 익힌터라 좀 자신이 있었다. 그래서 나는 IAM Center를 써봤다. 검증할것은 이것이다. 지금까지는 각 계정에 역할을 생성하고, STS를 통해서 계정에 접근했다면 IAM Center에선 통합계정을 생성하여 OU에 연결된 루트계정들에 접근할수 있도록한다. 먼저 OU에 계정을 연결한다. 3개의 계정이 연결된것을 확인할수있다. linxuer 계정이 Root OU를 관리한다. linuxer 계정에서 IAM Identity Center서비스 로 이동한다. 그리고 사용자를 생성한다. ...
이번엔 FinOps에 대한 이야기를 할거다. 먼저 본론으로 들어가기 전에 FinOps에 대한 정의부터 이야기할까 한다. 우리가 흔히 알고있는 DevOps는 Development 과 operations 의 합성어 이다. FinOps는 이 DevOps 에 Finance를 더한것이다. ( Finance + Development + Operations ) IT infra 상에서 발생하는 비용을 제어하고 투자하는 방식을 말하는것이다. '투자' 라고 말하면 의아 할수도 있는데 클라우드 상의 자원은 무한하지만 사용자에게 할당된 비용은 유한하다. 그렇기에 제한된 비용내에서 적절한곳에 맞는 리소스를 투입하는것이 FinOps 에서 투자인것이다. ...
가시다님과 함께하는 스터디는 항상 즐겁다. 이번 스터디엔 라이브로 못해서..일단 바닐라쿠버 배포하고 시작했다. Headless 서비스는 ClusterIP가 None으로 설정하며 kubeproxy를 통하지않고 pod의 endpoint가 svc에 연결된다. 나는 먼저 NFS 서버를 Headless 로 배포하기로 했다. kind: PersistentVolumeClaim apiVersion: v1 metadata: name: nfs-server-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi --- kind: Service apiVersion: v1 metadata: name: nfs-service spec: type: ClusterIP clusterIP: None selector: role: nfs ports: # Open the ports required by the NFS server # Port 2049 for TCP - name: tcp-2049 port: 2049 protocol: TCP # Port 111 for UDP - name: udp-111 port: 111 protocol: UDP # Port 20048 for TCP - name: tcp-20048 port: 20048 protocol: TCP --- apiVersion: v1 kind: ReplicationController metadata: name: nfs-server spec: replicas: 1 selector: role: nfs-server template: metadata: labels: role: nfs-server spec: containers: - name: nfs-server image: gcr.io/google_containers/volume-nfs:0.8 ports: - name: nfs containerPort: 2049 - name: mountd containerPort: 20048 - name: rpcbind containerPort: 111 securityContext: privileged: true volumeMounts: - mountPath: /exports name: nfs-export volumes: - name: nfs-export-fast persistentVolumeClaim: claimName: nfs-server-pvc-fast ? ...
시작하는 사람을 위한 안내서를 작성하고 싶었는데, 좀 늦었다. 매번 하는 말이지만 내 게으름 때문이다. 꼭 누군가에게 도움이 되는 글을 작성하고 싶었는데 그게 바로 오늘인 듯 하다. 클라우드를 하려면 먼저 계정을 생성하여야 한다. 계정을 생성 하였는가? 축하한다. 드디어 클라우드에 입문한 셈이다. 클라우드는 보통 웹 콘솔로 처음 접하게 된다. CSP 에서 제공하는 웹사이트에 가입을 했다면 뭘 해야 할지 고민이 될 것이다. ...
Data Analytics 까지 시험을 봤습니다. 이 사태의 원인은 세웅님이었습니다. 치명적인 속도로 AWS 자격증을 클리어하는 것이 제가 나태한것 같이 느껴졌습니다. 그래서 MLS를 끝내고 DAS를 바로 시작했습니다. DAS는 DBS-DAS-MLS 순으로 보면 좋은시험 같았습니다. DAS는 주로 ETL 과 Analytics에 관련한 문제가 나옵니다. https://jayendrapatil.com/aws-certified-data-analytics-specialty-das-c01-exam-learning-path/ 제 블로그를 봐온 분들이라면 다들 아시겠지만 저는 jayendra 님의 블로그로 먼저 시험을 준비합니다. 도메인 분리도 잘되어있고, 요약정리가 정말 깔끔하기 때문입니다. 요약정리를 다 읽고 AWS에서 주로 사용할 서비스에 대한 이해가 필요합니다. kinesis stream와 firehose 의 차이를 알면 정말 편해집니다. ...