endpoint 설정 없이 사설 ip로 S3 접근하기 (feat. hosts 파일)

S3 interface endpoint 출시

S3 endpoint service 에 드디어 interface endpoint가 나왔다.

AWS S3 public 서비스라던데… 혹시 VPC에서는 사설통신이 되나요?

네 됩니다.

AWS에는 Private Link 혹은 VPC Endpoint 라고 불리는 서비스가 있다. 이름에서 알 수 있듯이 AWS의 서비스를 뭔가 Private 하게 쓸수 있게 해주는 기능이다. 여기에는 Interface Endpoint, Gateway Endpoint 두가지 타입이 있는데 S3는 그 동안엔
gateway endpoint 만 제공했다. 사실 모든 서비스가 둘중 하나의 타입으로만 제공했다. 예를들어 SQS 나 DynamoDB 같은 경우엔 Gateway 타입으로만 제공이 됐고 나머지는 Interface 타입으로만 제공이 됐다. gateway endpoint는 VPC 내에서는 어플리케이션에서 엔드포인트 변경등이 필요없이 바로 적용이 되는 장점이 있지만 ip가 제공되지 않는다는 단점이 있다.

EMR 6 버전 출시 (Hadoop 3.0, Hive LLAP, Spark3.0 지원)

아주 오랜만의 포스팅.

EMR 6.0

너무 늦은감이 있지만 EMR 6버전이 새로 출시되었다.

찾아보니 올해 4월에 출시가 되었는데… 무려 7개월만이다.
(https://aws.amazon.com/ko/about-aws/whats-new/2020/04/amazon-emr-announces-emr-release-6-with-new-major-versions-hadoop-hive-hbase-amazon-linux-2-docker/)

RDS, DocumentDB 는 Readreplica 생성시 다운타임이 발생하나요?

TL;DR

  • RDS의 경우 single-az에 스냅샷을 한번도 생성한적이 없으면 I/O 지연이 발생할 수 있음
  • Aurora, Document DB 는 공유스토리지 덕분에 single instance인 경우에도 순단이 발생하지 않음.

Bastion Host를 통해 내부 서버에 SSH 접속하기 (터널링)

aws 상에서 보안을 위해 그림과 같이 실제 사용하는 인스턴스는 private subnet에 숨기고, public에 bastion host 라는 걸 둬서 접근하는 방식이 있다.

이렇게 하면 관리할 구멍을 하나만 만들고 그 외에는 접근이 원천적으로 불가능해지기 때문에 보안적으로는 좋아지긴 하는데… 그 내부로 접근하기가 매우 귀찮아지는 단점이 있다.

결국 private subnet 안에 있는 인스턴스에 접근하려면 배스쳔호스트를 거쳐야 하는데,
매번 그 명령어를 까먹어서 기록해둔다.

방법은 아래와 같다


1.타겟의 22번 포트를 배스천호스트를 통해 로컬(내컴퓨터)의 33322 포트로 포워딩

포트 포워딩
1
ssh -i "bastion-host-key.pem" -N -L 33322:{target-private-ip}:22 ec2-user@{bastion-host-public-ip}

(주의) 새 터미널을 띄운 후

2.로컬호스트의 33322포트를 이용해 타겟으로 접속

접속
1
ssh -i "target-key.pem" -p 33322 {target-user(대체로 ec2-user)}@localhost

타겟의 22번 포트를 배스천호스트를 통해 로컬(내컴퓨터)의 33322 포트로 포워딩

(용어정리)

  • bastion-host-key.pem: bastion host에 접근할 수 있는 key,
  • target-private-ip: 최종 접속할 인스턴스의 프라이빗 ip,
  • target-key.pem: bastion host의 key,
  • bastion-host-public-ip: 말 그대로 bastion host의 퍼블릭 ip

33322포트는 임의로 정한것이며 아무거나 남는 포트를 정하면 된다.
끝.

Lambda의 동시성에 대하여 - 1

Lambda가 진정한 cloud native인걸까!

300원에 200만뷰 소화하기라는 포스팅을 읽은 적이 있습니다.

그리고
AWS와 함께 천만 사용자 웹서비스 만들기라는 슬라이드도 본 적이 있습니다.

저 슬라이드를 처음 봤던 때에는 Lambda에 대해서 많이 사용을 안해봐서 그런지 저 자료들만 보면 왠지 엄청난 트래픽을 아주 적은 비용으로 큰 문제 없이 수용할 수 있을 것만 같았습니다. 그러면서 언젠가 full-serverless 로 구성된 서비스를 한번 만들어 봐야겠다는 생각을 했었습니다. 생각만요.

생각해보면 단순히 REST API에 대한 요청만 받아주는 서비스라면 API GATEWAY + Lambda 로만 구성하는게 충분히 메리트 있을것 같았습니다. 그러면 정말 진정한 의미에 Pay-as-you-go 를 구현하는 클라우드 네이티브를 구현해볼 수 있지 않을까요…?

EMR 에 올라간 Zeppelin 활용하여 Athena 이용하기.

들어가기 전에…

최근에 AWS Datascience 소그룹 모임의 자료를 쭉 보던 중 아주 정리가 잘 되어있는 자료를 보았습니다. AWS 기반 지속 가능한 데이터 분석하기 라는 자료인데 SK 빅데이터 허브에서 제공하는 배달 업종 통화 기록을 베이스로 spark로 데이터를 변환하고 athena, Presto, tableau 를 이용해서 시각화 하는 내용을 담고 있습니다. ETL 부터 시각화까지의 내용을 아주 재밌는 데이터와 함께 잘 정리한 글입니다. (AWS 데이터사이언스 모임은 가보지 않았지만 언젠간 한번 꼭 참석하리라 마음을 먹은지 벌써 몇달째… )

Amazon Elasticsearch Dedicated Master의 스토리지 비용은?

Amazon Elasticsearch Dedicated Master의 스토리지 비용은?

Amazon Elasticsearch 에는 Dedicated Master를 설정해줄 수 있습니다. 마스터노드의 기능만 하는 노드를 따로 빼서 클러스터의 안정성을 높이는 방안입니다. Elastic의 문서에도 클러스터의 사이즈가 큰 경우 마스터 노드를 분리하는 것을 권장하고 있네요. (참고: https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html)

오늘 내용은 Dedicated Master에 대한 디테일한 내용이 아니라 비용에 관한 간단한 얘기입니다.

AWS Athena, CF Log 분석을 위한 쿼리 예시

AWS Athena, Cloudfront Log 분석을 위한 쿼리 예시

Cloudfront는 고맙게도 Edge단에서 발생하는 처리 로그들을 모아서 제공해 줍니다. CF Log는 기본적으로 S3에 gz 형태로 압축되엇 제공이 되고
다음과 같은 DDL을 통해 테이블을 정의하면 Athena에서 조회할 수 있습니다.

AWS Athena, Zeppelin과 함께 사용하기 (feat. ALB 로그분석)

Athena, 심플하고 강력하지만 아쉬운 인터페이스

이번 포스팅에서는 Athena 와 Zeppelin을 엮어서 사용하는 방법에 대해서 정리하려고 합니다. Athena는 써보면 써볼수록 요물이라는 생각이 드는 제품입니다. S3에 데이터만 잘 저장해 놓으면 그걸 SQL문으로 빠르게 쿼리할 수 있다는 컨셉이 간단하지만 강력하네요. 다른 분산처리 플랫폼도 많지만, 일단 간단하게 시작하기에는 Athena가 최적인것 같아요.

다만, Athena가 워낙 심플한 구조를 갖고 있고 제공해주는 기능도 심플하다 보니 조금 아쉬운점도 있는데요, 일단 제 생각에 가장 아쉬운 점은 인터페이스 입니다. ‘대화형 쿼리’ 라는 컨셉으로 단순한 쿼리창만 갖고 있지만, 사실 ‘대화형’ 이라는 말처럼 채팅기록이 남진 않는게 제 생각엔 커다란 단점인 것 같아요. 우리나라 정서가 워낙 UI에 이것저것 많은 기능을 좋아해서 상대적으로 AWS의 UI가 좀 빈약하다는 느낌을 많이 받는데 Athena의 인터페이스도 그 중 하나인 것 같습니다. 그래도 ‘대화형’이라는 컨셉을 완성하기 위해서는 조금 더 인터페이스가 발전해야 할 것 같다고 생각합니다.

AWS Lightsail VS EC2

그림0

Lightsail 이라는 서비스가 나온지는 좀 되었다. 간단하게 소개하면 아마존에서 제공하는 웹 호스팅 서비스 이다. 기본적인 컨셉 자체는 AWS라는 복잡하고 어려운 클라우드 어쩌구를 몰라도 웹호스팅을 다른 업체만큼 싸게 제공해주는 데 목적이 있는 듯하다. 영세한 웹호스팅업계에 AWS라는 공룡이 침입한 게 아닌가 싶다. Digital Oceans 같은 호스팅업체와 제공하는 서비스와 심지어 UI까지 비슷하다. Digital Oceans는 점점 클라우드 업체처럼 되어가고 있고 아마존은 호스팅 업계의 영역까지 군침을 흘리고 있는 모양새다.

어쨌든 Lightsail은 그저 ‘아마존의 웹호스팅 서비스’라는 것이 중요하다.

그런데, AWS를 사용하고 있는 사람 입장에서는 그럼 AWS에서 EC2를 사용하는것과 Lightsail에서 사용하는 것과 뭐가 다른지가 궁금하다. 간단하게 그 차이점을 정리해보려고 한다.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×