JHB의 삽질 이야기

MSA 다룰 때 카오스엔지니어링은 중요하다. 하나의 서비스 장애가 전체 시스템 장애로 퍼지는 일이 흔하기 때문이다. MSA로 아키텍처를 구성하면, 어느 한 서비스가 장애 시간이 점점 쌓여서 Timeout이 계속 나는 상황이 되면.. 이거에 연관된 모든 서비스가 점점 느려지다가 전체 서비스가 한순간에 확 다운된다. 2차 함수 처럼 그래프가 한번에 확 올라간다. 느려지기 시작하는 지점을 엘보우 포인트라고 부르며, 이걸 빠르게 캐치하는게 중요하다. 그래서 프로덕션 전에 일부로 서비스 장애를 일으키고 이를 해결하기 위한 플레이북을 만들어 나가는 과정이 중요하다. 이때 서비스를 모두 띄워놓고 하나씩 죽여보는 날을 잡는데, 이걸 Demo Day 라고 부른다. 예를 들어 서비스에서 DB 요청 했는데 Timeout이 ..

Public Subnet에 EC2를 생성했고, Public IP는 할당하지 않았다. (Private IP만 있는 상황) 이 상황에서 AWS SDK를 통해 AWS Batch를 수행했는데... Timeout이 나면서 수행이 안된다. 도대체 무슨 일일까? 처음엔 IAM Role 문제 인줄 알았는데,, 아니었다. Public IP가 없으면 Internet 을 통해 외부로 요청이 불가한 것이었다. 차라리 Private Subnet 통해서 NAT - Internet Gateway로 갔으면 NAT의 Public IP를 달고 외부와 통신이 됐을 텐데.. IP 대역이 서로 다른 네트워크가 통신하려면 2개 중 하나를 만족해야 한다. 1. 서로 상대방의 IP 대역을 알고 있거나 - 가는 길을 알려줘야 하기 때문에 라우터를 ..

CDK에서 원하는 배포 환경으로 배포하기 위해 나는 ID를 바꾸는 Practice를 가장 많이 쓴다. https://jhb.kr/419 [CDK] 배포 환경에 따라 다른 스택으로 배포하기 CDK로 스택을 배포 할 때 Dev / Test / Prod 등의 환경으로 배포 하기 위해 여러가지 방법이 있다. 여러 가지 방법 중 핵심이 되는 것은 결국 '스택의 아이디를 배포 환경에 맞추어 바꾸어 준다'는 것이 jhb.kr 그러면 Service와 CI/CD에 대한 스택은 어떻게 구성하는게 좋을까? 처음에 나는 서비스 생성 자체는 ecs_patterns.ApplicationLoadBalancedFargateService 를 사용하였고, 이를 ServiceStack${env}이라 두고, 이를 관리하는 CI/CD를 Se..

codebuild 같은 CI/CD의 빌드 도구를 다루다 보면 aws cli 로 부터 결과값을 사용해야 할 때가 종종 있다. json으로 출력 후 jq 를 통해 파싱해서 쓰는 방법도 있지만, 애당초 aws cli의 결과물을 그대로 필터링해서 쓰는 방법도 있다. 쉬운 예제는 아래와 같다. AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) 더 자세한 내용은 아래의 레퍼런스를 참고하자 https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/cli-usage-filter.html AWS CLI 출력 필터링 - AWS 명령줄 인터페이스 지정한 출력 유형에 따라 --query 옵션 작동 방..

https://cicd-pipeline-cdk-eks-bluegreen.workshop.aws/en/ecsbg.html cicd-pipeline-cdk-eks-bluegreen Using CodeDeploy ECS Blue/Green Note: This is an bonus section to be completed as a stretch goal. Now that we understood the Blue/Green deployment concept in EKS, we will deploy a new environment using the native Blue/Green deployment feature of AWS CodeDe cicd-pipeline-cdk-eks-bluegreen.workshop.a..

Private Subnet에 배포된 EC2 인스턴스가 S3에 Gateway Endpoint를 통해 연결해야 하는 요구 사항을 처리해야 했다. 당연히 인터넷 망을 타면 안되는 상황이었다. 그리고 당연히 S3의 기본 정책은 Block Public Access On 인 상태. AWS SDK에서 제공하는 s3의 GetObject API를 사용하는건 전혀 문제가 되지 않았다. AWS SDK에서 접근 하는 것은 EC2의 InstanceRole Credential 정보를 담고 나가기 때문이다. 문제는, AWS SDK 없이 curl, wget, ffmpeg 등이 standalone application을 통해 S3의 주소로 접근 하려 할 때 문제가 발생했다. 일단, S3 주소는 크게 아래의 두가지가 존재한다. s3.a..

get-federation-token $ aws sts get-federation-token --name test { "Credentials": { "AccessKeyId": "ASIAU2YLFTR7ALYQWKL2", "SecretAccessKey": "pffWqq0UIbukJ0foBYxQ1Q+WpCfIapojN1MvCLgE", "SessionToken": "IQoJb3JpZ2luX2VjEAMaDmFwLW5vcnRoZWFzdC0yIkcwRQIhAJuho9YXm0q9eLX2ju7ZVX7TXnOdMIJvks96fZIFeLhMAiAJAgcuyE43fBS8wCronDADWzpiAVIsQ0xbeiVT9szwcCqDAgiN//////////8BEAEaDDMzMjM0NjUzMDk0MiIMrkO+6hagUL01xvnW..

CDK로 스택을 배포 할 때 Dev / Test / Prod 등의 환경으로 배포 하기 위해 여러가지 방법이 있다. 여러 가지 방법 중 핵심이 되는 것은 결국 '스택의 아이디를 배포 환경에 맞추어 바꾸어 준다'는 것이다. 예를 들어 FooStack이 있을 경우 new FooStack(app, `FooStack-${env}`); 와 같은 형태로 Stack의 ID를 정해놓고, env값을 dev, test, prod 로 각각 배포하면 FooStack-dev FooStack-test FooStack-prod 이렇게 3개의 스택이 생성된다. (당연히 스택 내의 리소스 생성시 리소스의 name을 배포 환경에 관계 없이 고정하는 행위는 절대 하지 말것... 예를 들면 Lambda Function의 이름이..