Elasticsearch Update API로 Document 교체하기

Elasticsearch 는 기본적으로 Update API를 통해 요청하면 요청한 필드만 딱 업데이트한다.

그런데 종종 문서를 교체해야하는 일이 있다. update문서를 보면 문서의 Replace를 원하는 경우 Index API를 이용하라고 가이드 되어있다.

To fully replace an existing document, use the index API. update 문서참고

하지만 Index API는 만약 기존 문서가 존재하지 않으면 새로 생성해버리는 문제가 있다. 만약 기존 문서의 교체 만을 원한 것이라면 이게 문제가 된다. 기존 문서 교체를 원해서 index api를 날렸는데 실수로 id를 다르게 적었다면, 내가 교체하려는 문서는 그대로 있고 새로운 id에 문서가 생성되는 상황이 발생한다.

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인 경우에도 순단이 발생하지 않음.

Amazon Linux 2에 Airflow 설치하기

당연히 쉽게 될줄 알았던 airflow 설치에 꽤 애를 먹었다. 구글링을 해봐도 명확한 가이드가 나오질 않아서 내가 성공한 설치 방법을 공유한다.

1
# 의존성 설치 (가이드 상에는 python3, gcc, gcc-c++ 정도만 설치하면 된다는데 그렇게만 하면 자꾸 에러가 난다. gcc를 실행을 못한다든지...)
2
$ sudo yum update -y
3
$ sudo yum install group "Development tools" -y
4
$ sudo yum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel python3-devel.x86_64 cyrus-sasl-devel.x86_64 -y
5
$ sudo yum install libevent-devel -y
6
7
# 드디어 airflow를 설치. 여기에서 sudo를 생략하면 권한문제가 발생한다. 
8
$ sudo pip3 install apache-airflow
9
10
# 위의 과정을 마쳤으면 여기서부터는 공식 가이드 그대로. 
11
$ airflow initdb
12
$ nohup airflow webserver -p 8080 > webserver.out & 
13
$ nohup airflow scheduler > scheduler.out

다른 OS에서는 확인을 못해봤고 Amazon Linux2가 올라간 EC2에서는 정상적으로 작동된다. (2020.1.8 기준)

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포트는 임의로 정한것이며 아무거나 남는 포트를 정하면 된다.
끝.

문제 해결: Cannot Call methods on a stopped SparkContext

스파크로 이것저것 테스트해보기 위해 zeppelin을 사용하는데 갑자기 이런 에러가 발생했다.

java.lang.IllegalStateException: Cannot call methods on a stopped SparkContext.

즉, 지금 사용하려는 SparkContext가 이미 종료되었다는 것이다.

이걸 구글에 검색해도 ‘로그를 봐라’ 라는 식의 원론적인 답변이 나와서 헤매다가 해결방법이 떠올랐는데…

해결 방법

그냥 스파크 인터프리터를 재시작하면 된다.

스파크에 대한 아주 대략적인 정리

빅데이터를 공부해야할 일이 생겨서, 하둡을 먼저 공부했다. 쌩으로 클러스터를 만들고, 설정값을 변경해보고… 그렇게 클러스터를 만드는 일부터 맵리듀스 어플리케이션을 만드는 일까지 공부하는게 쉽지만은 않았다. 여기서 약간 빅데이터의 벽(?)같은걸 1차로 느꼈다.

그러다가 스파크를 만났다. 공부하다 보니 스파크가 그렇게 어렵지도 않고, 그런데 활용성은 굉장히 좋고, 성능도 좋다는 생각이 든다. 여기서 포인트는 그닥 어렵지 않다는 점이다. 자료들이 주로 scala라는 생소한 언어로 설명이 되어있지만, scala가 별로 어렵지 않다. 언어자체가 직관적이면서 간결하다. 그리고 scala로 배우는 스파크도 그닥 어렵지가 않다. 많은 기능을 제공하고 좋은 성능을 제공하지만, 기능들의 추상화가 잘 되어있어서 단순히 api만 호출하면 된다.

이거 사긴데? 쉽고 빠른 빅데이터 처리 엔진이라니…

그 동안 하둡을 공부하면서 느낀 어떤 답답함 같은게 해소되는 느낌이랄까. 맵리듀스를 짜면서 뭔가 병렬처리로 성능이 향상된다는건 알겠는데 코드 작성이 상당히 번거로웠다.(책에는 간단하다고 나와있는데 원리야 간단하지만 코드짜는건 안간단함 ㅇㅇ) 물론 하둡에는 맵리듀스 외에도 빠르게 분석할 수 있는 엔진들이 있지만, 그 중에 스파크가 가장 매력적으로 보인다.

블로그 개편

블로그 개편했어요!
전에는 Jekyll 을 썼었는데 계속 테마는 마음에 안들었었거든요.
그래서 예쁜 테마를 찾아보니… 예쁜 테마는 모두 hexo에 있더군요. 그래서 갈아탔습니다.

Lambda의 동시성에 대하여 - 1

Lambda가 진정한 cloud native인걸까!

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

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

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

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

Your browser is out-of-date!

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

×