링크 로컬 주소란? 링크 로컬 주소 같은 네트워크와 브로드케스트 도메인에서만 통신이 유효한 네트워크 주소이다.라우터 외부로 나가면, 더 이상 같은 네트워크가 아니기 때문에 라우터가 패킷을 전송하지 않는다.     IPv4에서는 169.254.0.0/16 범위, IPv4에서는 fe80::/10 범위가 링크 로컬 주소로 예약되어 있다.(IPv4에서 실제로 사용가능한 주소는 169.254.1.0 ~ 169.254.254.255이다.)  이러한 링크 로컬 주소는 일반적으로 DHCP를 통해 주소를 할당받을 수 없을 때 (DHCP 서버가 존재하지 않거나 더 이상 IP 풀이 없을 때), 예약된 링크 로컬의 범위 내에서 랜덤으로 IP를 선택한다.선택한 IP로 ARP를 날려, 응답이 있다면 다른 IP를 선택하고 응답이 ..

Route 53 Resolver를 VPC 내부에서만 사용하는 경우 VPC 내에서는 외부로의 인터넷 접근을 차단해도 VPC의 내부 서비스의 DNS 쿼리 가능하다.그 이유는 Route 53 Resolver가 VPC 내부에서의 DNS 서비스를 제공하기 때문이다.  Route 53 Resolver는 해당 VPC의 IP 주소에 0.0.0.2를 더한 IP로 정의된다. (VPC + 2라고 표현하는 듯하다.)10.0.0.0/24라면 10.0.0.2가 해당 VPC의 Route 53 Resolver IP이다.(이미 예약되어있으므로 다른 자원들 사용할 수 없다.) IPv6의 경우 fd00:ec2: :253 주소를 사용한다.  VPC의 DNS resolution 기능이 활성화되면, VPC 내부에서 발생하는 DNS 쿼리 요청은..

VPC Endpoint란? VPC endpoint는 AWS의 서비스를 public internet을 통하지 않고, AWS 백본 네트워크인 Private Link를 통해 안전하고 빠르게 접근할 수 있는 서비스를 제공한다.이를 위해서 VPC에는 목표 서비스의  Gateway endpoint 또는 interface endpoint를 배치해야 한다. S3는 VPC Gateway endpoint를 지원하다가 interface endpoint 서비스가 생기면서  interface endpoint 까지 생성할 수 있게되었다.  일반적으로 DynamoDB와 S3는 Gateway endpoint를 사용하는 것이 권장되는데, 어떤 상황에서 어떤 것이 좋을지 확인하기 위해 두 서비스의 명확한 차이를 알아보자.      Ga..

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가 하나로 합쳐..