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

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 서비스에서 확인해 본 적 있을 것이다.)의 케이스 스터디 ..