카오스랩

컨테이너 관리 서비스들의 출시 이력 컨테이너 OS 특히 Linux 안에 서로 격리된 여러개의 환경을 제공하여 애플리케이션과 서비스를 가볍게 유지하고 빠른 속도로 실행할 수 있게 해주는 기술입니다. 도커 가장 잘 알려진, Linux 컨테이너 배포 및 관리를 위한 프로젝트 혹은 방법입니다. Kubernetes 구글이 설계하고 리눅스재단이 관리하고 있는 도커를 포함한 컨테이너들에서 어플리케이션 컨테이너의 배치, 스케일링, 운영을 자동화하기 위한 플랫폼을 제공하기 위한 오픈소스 툴입니다. Amazon ECS  컨테이너 관리 서비스이며, 확장성, 성능이 좋으며, 도커 컨테이너를 지원합니다. Amazon ECS 서울리전 출시 2017.10.5 AWS Fargate 출시 2017.12.12 Amazon EKS 출시 2018.6.8 Amazon SageMaker 서울리전 출시 2018.6.28

프라이빗 서브넷의 인스턴스가 외부망 혹은 인터넷에 연결이 필요할 때, NAT 게이트웨이를 사용하여 구성할 수가 있는데요, 그렇다면 NAT 게이트웨이는 AZ 마다 필요할까요? 정답은, "필요할 수도 있고 아닐 수도 있다" 입니다. NAT 게이트웨이는 하나의 AZ에서만 있어도 다른 AZ의 인스턴스가 속한 서브넷을 통해 라우팅이 가능합니다. 그런데, 서로 다른 AZ끼리 통신에는 비용이 발생하기 때문에 이 점을 고려해야 합니다. 결론은, NAT 게이트웨이를 통한 트래픽양이 많을 때는 각각 AZ에 NAT 게이트웨이를 구성하고, 적을 때는 하나의 AZ에만 구성하는 것이 경제적입니다. 주로, 디비서버 등의 yum update 정도 용도라면 하나의 NAT 게이트웨이만 운영하는 것이 좋겠네요~

AWS에서 S3를 오리진으로 CloudFront를 배포하고자 할 때, 단일 계정에서 구성은 특별히 복잡하지 않습니다. 그리고, A계정에는 S3를 B계정에는 CloudFront를 배포해야 하는 경우가 있는데, 이 경우에도 S3의 버킷을 퍼블릭 엑세스를 허용해도 좋다면 역시 복잡하지 않습니다. 그런데, S3 버킷에 직접 접근은 차단하고 반드시 CloudFront를 통해서면 접근할 수 있도록 구성해야 한다면 S3 버킷에 대한 접근제어를 적절하게 구성해 주어야 합니다. 먼저, CloudFront에서는 Origin Access Identity(OAI)를 생성하고 배포 생성 시 "Restrict Bucket Access"를 yes로 하여 OAI를 방금 만들어 둔 ID로 선택하여 생성합니다. 이 때, Origin Domain Name은 다른 계정의 S3 버킷을 기입해야 하므로 [버킷이름].s3.amazonaws.com 형식으로 된 도메인을 기입하여 줍니다. S3에서는, 버킷의 [권한>버킷 정책]에 아래 내용으로 입력 후 저장합니다. 이 때, CloudFront OAI의 Amazon S3 Canonical User ID는 예: 06456789ca4f9f615e52eaae632639537f81c08cb771e90f4889b473134a4483f1ad529cfd863107985aa39df 형식입니다. {    "Version":"2012-10-17",    "Id":"PolicyForCloudFrontPrivateContent",    "Statement":[      {        "Sid":" Grant a CloudFront Origin Identity access to support private content",        "Effect":"Allow",...

EBS Data LifeCycle Manager(DLM) 가 2018. 7. 12 부터 미국 동부 (버지니아)  ,  미국 서부 (오레곤)  및  EU (아일랜드)  지역에서 사용할 수 있습니다. 그 동안  EBS 스냅샷을 통한 백업 구성을 자동화 하려면, 시스템 매니저 서비스에서 CloudWatch 등을 통해서 트리거 생성을 하여 자동화 문서를 실행하는 방법을 사용해야 했는데, 이제는 RDS 스냅샷처럼 간편하게 백업 구성을 할 수 있게 되었습니다. 현재는 EBS 스냅샷에 대해서 하루에 2번 혹은 1번 주기로 지정된 태그가 있는 EBS 볼륩에 대해 지정한 시간에 스냅샷을 생성하고 태깅을 할 수 있습니다. 자동생성된 스냅샷은 지정된 스냅샷 갯수만큼 자동 유지됩니다. 이름에 EBS가 아닌 Data가 붙어 있는 걸로 알 수 있듯이, 추가 AWS 데이터 소스에 대한 지원을 더 할 계획입니다.  또한 매주 및 매월 스냅 샷을 수행할 수있는 정책을 지원할 계획이며 추가 일정 유연성을 제공 할 것으로 기대됩니다.

드디어 올것이 왔군요. 그 동안 한국에서 AWS가 다른 클라우드 벤더에 비해 유일하게 없던 것, 바로 클라우드 NAS인 Amazon EFS가 2018.5.30일자로 서울리전에 출시되었네요. EFS를 생성해서 EC2에 마운트 해 보니 # df -hP /efs Filesystem Size  Used Avail Use% Mounted on fs-b90de8d8.efs.ap-northeast-2.amazonaws.com:/  8.0E      0  8.0E   0% /efs TB보다 PB보다 큰 EB로 8EB의 NAS 스토리지를 그것도 Multi-AZ로 제공하네요. 이제 서로 다른 AZ에 웹/어플 서버들을 구성하고 Upload 폴더 등의 공유볼륨을 EFS로 생성하고 마운트해서 사용할 수 있겠네요. EFS 생성 시, Max I/O 옵션은 수십, 수백, 수천개의 EC2인스턴스가 엑세스하는 동작에 최적화되어 있습니다. (다만, 다소 파일 동작에 대한 레이턴시는 높아집니다) 기본적인 마운트 옵션을 보면, nfs4.1 기반, tcp:2049를 사용하고, recovery behavior는 hard 방식입니다. # mount |grep efs fs-b90de8d8.efs.ap-northeast-2.amazonaws.com:/ on /efs type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600, retrans=2,sec=sys,clientaddr=10.10.16.73,local_lock=none,addr=10.10.16.130)

쉽고 간단하게 AWS에서 제공하는 VPS를 사용할 수 있는 Amazon Lightsail이 서울리전에 출시되었습니다.(2018. 5. 8) 얼마나 쉽고 간단한지 Amazon EC2와 요금, 기능, 제약사항 등을 비교해보았습니다. Lightsail을 선택하는데 도움이 되시길 바랍니다. Lightsail vs EC2 구분 항목 EC2  Lightsail 요금 인스턴스 $5.28 (t2.nano 1c 0.5g 인스턴스) $5.00 (1c 0.5g + 20GB Disk + 1TB 전송량) 블럭스토리지 $114/1000GB (SSD gp2) $100/1000GB (기본디스크 20GB/30GB/40GB 등 무료 제공) 스냅샷 EBS 사이즈 까지는 무료 제공 EBS 비용과 동일 고정아이피 $3.66 $3.66, 5개까지 무료 로드밸런서 $22.42 (1ECU 기준) $18 (전송량은 요금에 반영 안되고 대신 인스턴스에서 LB로의 전송량이 반영됨) DNS $0.50 도메인 3개까지 무료 등록 전송량 $126.38/1TB 1TB+ 무료, 송수신 합산량으로 산정 삭제 후 생성시에도 전송량은 합산측정. 허용량 초과시에도 인스턴스로의 수신 트래픽은 허용됨 기능 스펙 다양함 2c8g/2c4g/1c2g/1c1g/1c0.5g 비용투명성 콘솔에서 요금 확인 어려움 콘솔에서 월예상 요금을 즉시 표시해 줌 인스턴스 복제 다양한 방법으로 제공 스냅샷 생성 후 원본서버와 동일하거나 큰 타입으로 복제 생성 가능 AWS 자원 연동 대부분의 자원과 연동 가능 VPC Peering 활성화를 통해 RDS, Aurora 와 연동 가능. 계정 > 고급 메뉴에서 블럭스토리지 추가 가능 8G,32,64,128,256,사용자지정 간편한 추가 방법 채택 방화벽 Security Group, NACL 등 인스턴스마다 단순 방화벽 제공. All Close. 특정 포트 혹은 사용자지정 포트에 대한 개방룰셋 추가. 특정 소스아이피 차단은 못함 로드밸런서 CLB,...

Amazon EC2는 기본적으로 모든 인스턴스의 SMTP(25) 트래픽을 제한하고 있습니다. 하지만, EC2를 메일서버로 구성하고자 할 때는 이러한 제한을 풀어야 하는데요, 이에 필요한 몇가지 사항에 대해서 알아봅니다. 1.Elastic IP(EIP) 준비 아웃바운드 이메일을 보내는데 사용하는 EIP 주소가 필요합니다. 혹, EIP 주소가 스팸 주소로 등록되어 차단될 경우를 대비하여 두 개의 EIP를 준비합니다. EIP는 EC2에 attach 하면 EC2 당 1개는 비용이 발생하지 않지만 추가 EIP는 월 $3.66 비용이 발생합니다. 2. Route53에 EIP에 대한 reverse DNS 등록 대부분의 대형 포털 메일서버는 수신한 메일의 스팸성을 스팸하우스 같은 안티스팸 기구에서 운영하는 디비를 참조하여 판단합니다. 메일 발송지의 아이피의 Reverse DNS 조회 결과와 메일 발신자의 도메인이 일치하도록 reverse DNS를 등록해 두면 스팸 판정을 크게 줄일 수 있습니다. Route53에서 Hosted Zone을 만들고 위에서 준비한 EIP로 메일도메인의 A 레코드를 등록하고 이에 따른 PTR 레코드를 등록해 줍니다. Route53의 Hosted Zone 당 월 $0.50 비용이 발생합니다. 참조: How do I enable reverse DNS lookup in Amazon Route 53? 3. 제한 해제 신청 SMTP 제한 해제는 Root 계정 자격으로만 가능합니다. 아래 페이지에서 위에서 준비한 두가지 정보를 입력하고 해제신청을 합니다. 해제신청: Request to Remove Email Sending Limitations 요청이 승인되면 25번 포트의 차단이 제거되었음을 알리는 이메일을 받게됩니다. 이상으로 EC2를 메일서버로 구성하기 위한 선결 사항들을 알아보았습니다.