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

일반적인 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와 다르게 대시보드 자체의 접근을 지원하지..

Fargate를 위한 실시간 모니터링 ECS의 Fargate도 모니터링은 Container insight를 활용하면 Cloud Watch에서도 각 Task의 지표 정보를 수집할 수 있다.하지만 Cloud Watch의 한계로 지표를 확인할 때까지 1분 이상의 지연이 발생한다.예를 들면 12분 0초의 지표가 13분에야 확인이 된다. 실시간 모니터링이 필요하다면, Container insight와 Cloud watch만으로는 한계가 있다. 만약 EC2 Base의 ECS라면 EC2 자체에 Prometheus Agent를 설치하여 지표를 수집할 수 있지만, Fargate는 OS에 커스텀을 할 수가 없다. 그러므로 Task내에 지표 수집 및 전송을 제공하는 Side Car를 배치하여 실시간 모니터링을 제공해보자. ..

ECS Task란? ECS의 배포/관리의 최소 단위는 Task이다. Kubernetes의 배포/관리의 최소 단위인 Pod와 굉장히 유사하다. Task는 여러 개의 컨테이너로 구성되며, Fargate를 사용하는 경우 실시간 모니터링을 위해 Side car 컨테이너를 같이 배치하기도 한다. 실제로는 여러 개의 컨테이너를 Task나 Pod에 배치하는 것은 권장되지 않고 Side car나 필수 보조 컨테이너를 배치하는 정도로만 사용된다. 처음에는 Task를 그냥 컨테이너로 생각해도 괜찮다고 본다.    ECS Service와 Task Auto Scaling 여러개의 Task를 독립적으로 하나하나 관리하는 것은 어렵다. ECS도 Kubernetes의 Service(Deployment나 replica set)처럼 ..

기존에는 VPC Interface Endpoint 중에 ecr.api만 연결해 주면, ECR private link로 연결되는 알았다.하지만 테스트 결과, NAT Gateway를 VPC에서 빼주면 Fargate가 ECR에서 컨테이너 이미지를 가져오지 못하는 것을 확인했다. 결론을 이야기 하면, ECR 연결을 위해서는 아래의 3가지 Endpoint가 필요하다. Interface endpoint: ecr.dkr, ecr.apiGateway endpoint: S3 dkr까진 이해가되도 S3는 굉장히 뜬금없지 않은가?그 이유를 지금부터 확인해보자.    Docker hub는 S3 저장소를 사용아래의 Cloud flare(네트워크 전문 회사로 주로 CDN 서비스에서 확인해 본 적 있을 것이다.)의 케이스 스터디 ..

ubuntu EC2에 apache2와 php를 설치 후, AWS PHP SDK를 세팅해 보자. sudo suapt-get updateapt-get install apache2 -yapt-get install php -y apt-get install p7zip -y   (현재 최신버전인 php 8.1이 설치됨)  작업 폴더를 이동시키고 진행해 주자.cd /var/www/html  PHP 의존성 관리 도구인 Composer 설치설치하자.                  https://getcomposer.org/download/ ComposerDownload Composer Latest: v2.7.6 To quickly install Composer in the current directory, run the..

Code deploy의 ECS로 배포는 블루/그린 배포 방식으로 업데이트를 진행해보자.블루 그린은 한번에 모든 트래픽을 새로운 서버자원으로 이동시키는 무중단 배포 방식이다. 이때 하나의 로드밸런서에서 두 개의 리스너와 대상 그룹을 요구한다.그 이유를 배포 방식을 통해 알아보자.      배포 원리 배포 이벤트의 순서는 아래와 같다.     install전에는 서비스 중인 Production Listener의 대상 그룹을 Test Listener도 가리키고 있다.    여기서 install 이벤트가 실행되면, 다른 Target group에 업데이트된 task들이 배포된다.위의 이벤트 소요시간을 확인해보면, 컨테이너를 올리는 작업 및 상태 체크 때문에 다른 이벤트보다 시간이 많이 소요된다.    AllowT..

고가용성을 가진 웹서비스 인프라를 만들어보는 중에 Elastic cache를 활용해서 세션 쿠키를 캐싱할 계획이었다.     Memcached를 선택한 이유는 단순히 세션 쿠키를 저장하고 읽는 것이라면,단순한 기능을 제공하는 대신 빠른 성능을 보이는 Memcached가 redis보다 좋다고 판단했다. 고가용성을 보장하려면, 두 개 이상의 노드가 동작해야 하기 때문에 memcached 노드를 두 개를 다른 AZ에 배치하였다.    클러스터라면 노드 간의 동기화가 당연하게 일어날 줄 알았지만, 하나의 노드에서 key 저장 후, 다른 노드에서 키를  확인해 보니 서로 데이터는 독립적으로 처리하는 것이 확인되었다.      이처럼 AWS Memcached은 노드 간의 동기화가 제공되지 않는 것이 확인된다.그럼에..