AWS의 서비스에서 이벤트에 대한 알림을 발송해야 할 때 SNS와 EventBridge를 자주 사용한다.     두 가지 서비스를 활용하면 이벤트 기반 아키텍처를 설계할 수 있다. 그런데 어떤 상황에서는 EventBridege를 활용해서 알림을 보내기도 하고 SNS로 알림을 보내기도 한다.이런 상황의 차이는 무엇일까?    대상의 차이SNS 주제의 구독 대상은  상당히 적다.AWS의 서비스로는 Kinesis, SQS, Lambda 밖에 지원이 안 되고 있다.    EventBridge 출시 전에는 SNS와 연동된 Lambda를 통해서 다른 서비스와의 연동을 진행했다고 한다.이러한 Lambda 코드의 관리 또한 문제가 발생할 수 있는 지점이다. 반면 비교적 새로 출시된 서비스인 EventBridge는 대상..

Hypervisor의 OverCommit가상화의 핵심인 하이퍼바이저는 자원을 극한으로 효율적으로 사용하기 위해 OverCommit 기능을 사용한다. VM들이 모두 같은 자원량을 나누어 사용한다고 가정해 보자.이 기능을 사용하면, 하이퍼바이저가 물리 호스트의 자원을 정확히 VM 개수만큼 N등분하지 않고 N개 이상의 VM을 동작시킨다.  사실 모든 VM이 자원을 100% 활용하지 않기 때문에, AWS와 같은 CSP 입장에서는 자원을 1:1 크기로 예약해 두면 유휴 자원이 발생한다. 이러한 자원 낭비를 막고자 물리적인 컴퓨팅 자원보다 VM들에게 더 많은 CPU와 메모리를 프로비저닝 하게 된다. 이를 Overcommit이라고 한다.      CPU overcommitCPU overcommit은 CPU 자원을 물..

왜 CloudWatch가 EC2 Memory 모니터링을 제공하지 않을까?  EC2에서 CloudWatch는 CPU와 네트워크 정보는 기본적으로 수집을 제공한다.반면에 Memory와 Disk 정보에 대해서는 CloudWatch Agent를 OS에 추가로 설치해야만 수집할 수 있다. CPU까지는 기본적으로 수집할 수 있는데, 왜 Memory는 추가적인 소프트웨어를 설치해야만 수집할 수 있는 것일까?핵심적인 원인은 Hypervisor Level과 OS Level에서 수집할 수 있는 정보의 차이다.      CPU는 Hypervisor Level   하이퍼바이저는 기본적으로 물리적 Host의 CPU 사용을 VM마다 적절히 분배해야 한다.Guest OS는 하이퍼바이저에게 제공받는 시간만큼의 CPU를 사용하기 때문..

VPC 세팅이 필요 없는 서버리스 AWS의 서버리스 서비스들은 별도의 VPC를 필요로 하지 않기 때문에, 기존에 VPC 자원들에서 사용해야 하는 보안요소에 신경 쓸 필요가 없다. 접근을 IAM Role 위주로만 관리해 주면 되기 때문에 보안적으로 우수하다고도 볼 수 있다.  특히 Lambda의 경우 서버리스 DB 인 DynamoDB와 연동하게 되면, 복잡한 세팅 없이 서로 Role로 접근하면 되기 때문에 찰덕 궁합이다. 따라서 서버리스는 서버리스와 사용했을 때 장점이 극대화된다고도 볼 수 있다.       Lambda와 VPC 내부 자원의 연결 하지만 RDBS를 사용해오기 때문에 DynamoDB가 아닌 RDS를 Lambda와 연동해야 할 수도 있다.이럴 때 Lambda는 리전 level의 서비스인데, R..

Docker를 사용하다 보면, Ubuntu Image위에 세팅을 하여 container Image를 빌드하고는 한다.그렇다면 이 Image는 하나의 VM처럼 Ubuntu OS를  가상화해 제공해 주는 것일까?Host OS의 커널을 공유하기 때문에 경량화와 최적화가 가능했는데, 이런 것이 가능할까?또는 CentOS에 Docker를 설치하고 Ubnutu Image를 실행하면, 동작이 가능한 것일까? (미리 언급하면 가능하다.) 이번에는 이 주제에 대해서 알아보자.      핵심은 Host OS의 커널 공유   왼쪽에서 확인할 수 있듯이, Docker는 Host OS위에 Docker engine이 동작하여 Container 들이 이 커널을 공유하는 형태이다.따라서 container는 일종의 프로세스처럼 취급될..

Lamdba의 기반인 Firecracker와 microVMAWS의 Lambda도 결국에는 컨테이너 기반의 서비스이다.Docker와 같은 컨테이너 서비스보다 훨씬 빠른 반응 속도를 보이는 것은 AWS가 개발한 Firecracker 기반의 가상화 기술을 활용하기 때문이다. 기존의 다양한 서비스보다는 간단한 게스트 기능만을 제공하기 때문에 보안뿐만 아니라 오버헤드까지 줄였다.이때 사용되는 것이 경량화 가상 머신인 mircoVM이다.microVM는 약 5MiB의 메모리와 125밀리 초 안에 실행시킬 수 있다고 공식 문서에서 밝히고 있다.     Cold Start와 Warm Start 그리고 성능 향상 Lambda가 이러한 microVM에서 동작하기 때문에 굉장히 빠르지만, 결국에는 초기에는 사용자 코드를 다운..

3Tier 기본적으로 3Tier는 Presentation, Application 그리고 Data Tier로 나뉜다.여기서 웹서비스라면  Presentation Tier는 Web server로, Application Tier는 WAS(Web Application Server)로 대표된다.   Data Tier는 주로 RDBS처럼, 웹 개발 중에 자연스럽게 분리되는데 문제는 Web server와 WAS이다.검색하는 여러 장점이 있더라도 Web server와 WAS를 굳이 다른 서버로 분리할 필요가 있을까?WAS의 Nginx나 Apache가 Web server의 역할도 수행해도 문제가 없어 보이기도 한다.  실제로 PHP의 대표적인 웹 서비스 오픈소스인 워드 프레스는 web server와 WAS가 하나로 합쳐..

일반적인 3Tier에서의 ALB AWS에서 3Tier를 구성하는 경우, 일반적으로 ALB를 Presentaion Tier(Web Server)와 Application Tier(WAS) 사이에 하나씩 배치한다. Interfacing ALB는 Web server에 트래픽을 분산한다.만약 동적인 페이지가 필요하다면, Internal ALB로 WAS로 다시한번 트래픽을 분산하는 설계이다. 이를 위해서는 모든 동적 페이지 요청과 응답이 Web server를 거치도록 프록시 설정이 되어야 한다.또한 Internal ALB가 추가로 배치되어 비용이 발생한다.       본인의 토이 프로젝트처럼, 단순히 WAS용 페이지(예를 들면 로그인, 회원가입, 개인정보 페이지)와 Web server용 페이지(메인 정적 페이지)가..

buildspec.yamlAWS의 Code build에서는 Buildspec이라는 yaml 파일에 어떻게 빌드를 진행할지 작성해주어야 한다.Build는 어떤 것을 CI 하느냐에 따라서 빌드 방식이 달라지기 때문에 이러한 빌드 파일작성은 Git Actions에서도 아래처럼 특정 폴더에 build 파일을 작성해 주어야 한다.     Code build 생성시 별다른 세팅이 없다면, 자동으로 소스 코드의 루트 디렉터리에 존재하는 buildspec.yaml을 사용하게 된다.       buildspec 예시 Code commit 레포지토리의 파일들을 git 레포지토리로 옮겨둔 링크이다. https://github.com/overnew/AWS_PHP_SDK_CodeBuild_example GitHub - over..

이전글에서 AMP를 세팅한데 이어서 AWS Grafana를 통해 시각화를 해보자.   AWS ECS Fargate 모니터링 (1) - Side car (otel), AMP AWS ECS Fargate 모니터링 (1) - Side car (otel), AMPFargate를 위한 실시간 모니터링 ECS의 Fargate도 모니터링은 Container insight를 활용하면 Cloud Watch에서도 각 Task의 지표 정보를 수집할 수 있다.하지만 Cloud Watch의 한계로 지표를 확인할 때까지 1분 이everenew.tistory.com     AWS GrafanaAMP(AWS Managed Service for Prometheus)는 설치형 Prometheus와 다르게 대시보드 자체의 접근을 지원하지..