Cloud Computing On Demand

메타버스가 핫 키워드가 되면서 메타버스의 본질을 연구하는 사람들부터
메타버스에 편승하여 이익을 취하는 조직들까지 다양한 양태가 현실과 산업 전반을 휩쓸고 있습니다.

이게 정말 실체가 있는 것인가?
메타버스가 도대체 뭔데? 하는 생각을 하다보니...
스스로 한번 정의도 정리해보고 관련된 기업이나 산업도 정리해 볼 필요가 있어서 포스팅을 열어봅니다.

메타버스의 정의

여러가지 정의들이 있지만 마음에 들어나 와닿았던 것들을 한 번 적어보면...

• 통용되는 의미 - 현실세계와 같은 사회적, 경제적 활동이 통용되는 3차원 가상공간 (출처 : 위키)
• 데이브 바즈키 (Roblox CEO) - 메타버스는 실제처럼 보이는 것이 아닌, 실제처럼 느껴지는 것이다
• 김국현 (IT 평론가) - 현실의 재구성
• 류철균 (교수) - 생활형 가상세계, 실생활과 같이 사회, 경제적 기회가 주어지는 가상현실공간

...대략 위의 정도 메세지들이 기억에 남습니다. 

메타버스를 정의한 여러 사람들의 이야기를 듣다보면 재미있는 현상이 있습니다. 
기술에 가까운 일을 했던 사람들은 3차원 가상공간에 많이 주목을 하는 느낌이고
학술적인 연구를 많이 헀던 분들은 경제, 현실과의 접점에 많은 무게를 두고 있습니다.

어느 순간이 되면 메타버스도 현실과 경계가 무너질거라 생각하기 때문에
두 정의중 어느것이 맞다, 틀리다라고 생각하기 보다는 
이 두가지가 결국 만나는 접점에서 사용자들의 흥미를 잘 이끌어내는
상품이나 서비스가 사용자들에게 사랑 받을 거라는 예상을 해봅니다.

메타버스를 추구하는 회사/서비스들

자신들의 정의에 따라 메타버스를 from the scratch 로 만드는 곳들도 있지만 
이미 있던 회사들이 자신들의 성격을 메타버스로 재정의 하는 경우도 많습니다. 
뭐가 되었던 간에 `메타버스`를 언급하는 것만으로도 주가 폭ㄷ... 같은 현상들이 나타나고 있습니다.

• 메타 - 구 페이스북. 아직 실체는 없지만 Oculus 를 갖고 있어서 왠지 선두주자처럼 느껴지는 회사
• 제페토
  • 네이버의 자회사인 스노우의 자회사인 네이버제트의 서비스
  • 원래 얼굴 인식을 통한 아바타 제작 앱으로 시작했지만 본격적으로 메타버스로 방향 전환한 사례
• 슈퍼캣 - 네이버제트와 손잡고 협업메타버스라는 장르에 잽(Zep) 서비스로 진출. 게더류의 서비스?
• 마인크래프트 - 설명이 필요없는 곳.
  • 이미 돈도 많이 벌고 충성 사용자층도 두터운데... 가상공간에서의 게임에 방점이 찍힌 느낌
  • 교육과의 연결고리가 있고 CPU 를 만드는 것과 같은 흥미로운 일도 있지만... 
• 로블록스 - 상장사.
  • 저작권 침해의 바로미터로 핫한 이슈가 재빠르게 반영되는 곳
  • 로벅스라는 가상 화폐가 상당히 Active 하게 사용되고 있기도 함
  • 하지만 그래픽이 마음에 들지 않는다는 것이 일반적인 평이고 아이들이 노출되기 안좋은 컨텐츠도 많이 뿌려짐
• NFT / 코인에 진입하는 많은 회사들 - 메타버스 세상에도 돈이 필요하다는 전제하에...
• Unity / Epic (Unreal) - xR 이 메타버스에 꼭 필요한지와 별개로... 일단 키워드 관련하여 가장 핫한 곳.

단상

가만히 살펴보면 지금 우리가 `메타버스`라고 부르고 있는 것들이 과연 메타버스인지 좀 의문입니다. 
결국 모두가 가두리 양식을 하고 있는 중이고 영화 <레디플레이어원>에서 봤던 것처럼
모든 사람들이 공통으로 사용하는 진짜 `메타`공간은 그 어디에도 아직 없습니다.

20억 이상의 사용자를 갖고 있는 페이스북도 결국 10~20대 사용자들이 거부감을 느끼면서
새로운 사용자 유입에 어려움을 겪고 있으며, 결정적으로 그 누구도 FB를 공통 플랫폼이라고 생각하지 않습니다.
다만 사용자가 많이 몰려 있는 공간이니 비즈니스 기회가 많아 정도의 인식으로 접근한다는 느낌입니다.

현재의 `마이크로버스`를 넘어선 `메타버스`가 탄생하려면 결국 
수많은 `유니버스`들 간에 연결고리가 있어야 하고 공통된 규격이 있어야 하지 않을까 싶습니다.
`닷컴`열풍처럼 또 하나의 `트렌드`로서 끝날 것인지 주목해 봅시다.

기타

주식시장에서 메타버스 ETF 가 핫한데... 대표적으로 TIGER Fn메타버스(400907) 같은 것이 있다.
그런데 이 ETF의 구성종목을 한번 보면...?

전세계를 휩쓸고 있는 log4j 보안 취약점에 대한 대응이 슬슬 후반부로 들어가는 느낌입니다. 
log4j 보안 취약점에 대한 대응이 진행되지 못한 곳도 여전히 보이지만 주요한 글로벌 소프트웨어들은
log4j 의 새로운 버전 릴리즈에 맞추어 새롭게 패키징 된 버전들을 속속 공개하고 있습니다. 

취약점이 제거된 log4j의 2.16 버전 공개

이번 사태의 원흉(?)이 된 log4j의 새로운 2.16버전이 13일에 공개되었습니다. 
어떻게 대응을 했는가 가만히 살펴보니 기본적으로 JNDI 기능을 Disable 상태로 변경한 것으로 보입니다. 

https://logging.apache.org/log4j/2.x/changes-report.html?fbclid=IwAR2MKfhkCHCqeWzJ2LbTuRugBrshBGZfkDBS-5vWhI2y7fXNxUQPGCxWdrM#a2.16.0 

취약점이 제거된 Logstash의 새로운 버전 7.16.1과 6.8.21 버전 공개

Logstash는 7버전과 6버전의 두개의 스트림이 존재합니다. 
이번 취약점은 7버전과 6버전 모두에 해당되었기에 양쪽의 버전이 하나씩 올라갔습니다.

Logstash의 릴리즈 노트를 살펴보면 의존성 라이브러리로 포함되어 있는 log4j의 버전을 
취약점이 제거된 2.15.0 버전으로 변경했다는 것을 확인할 수 있습니다. 

지난 포스팅에서 소개했던 것처럼 임시로 JNDI를 Logstash의 core-jar 에서 제거한 상태로 써도 무방하지만 
기왕 새로운 버전이 나온 김에 릴리즈 노트를 살펴보고 오래된 Logstash 버전들을 개비해주는 것도 좋은 선택입니다. 

• Logstash 7.16.1 다운로드 : https://www.elastic.co/kr/downloads/logstash

• Logstash 6.8.21 다운로드 : https://www.elastic.co/.../past-releases/logstash-6-8-21

Logstash 업그레이드 방법은?

설치되어 운영중인 Logstash의 버전 업그레이드는 사용 환경에 따라 다릅니다.
패키지 매니저를 이용해서 설치한 경우라면 운영체제 버전에 맞추어 아래의 명령을 사용하시면 되겠습니다. 

# Ubuntu
apt-get upgrade logstash

# CentOS / Redhat
yum update logstash

# Mac
brew upgrade logstash

널리 사용되는 라이브러리에서 발생하는 문제는 늘 많은 어려움을 낳습니다. 
특히 의존성 관계를 갖게 되는 라이브러리라면 그 파급효과가 엄청납니다. 
아무쪼록 이번 보안 취약점으로 인해 큰 탈을 겪지 않았길 바래봅니다.

(2021.12.14 업데이트) 그 사이 log4j 의 패치 버전이 나오고, 패치된 log4j를 탑재한 Logstash의 새로운 버전이 공개되었습니다. 자세한 내용은 새로 올린 아래 포스팅을 참고해 보세요!

주말 내내 log4j 에 대한 폭풍이 계속 이어지고 있습니다. 직접 개발한 소스코드를 이용하는 경우 새로 공개된 log4j 의 바이너리(2.15.0+)를 이용해 빌드를 다시 하면 되지만 그렇지 않은 오픈소스나 외부의 패키지를 이용한 경우들이 계속 발견되고 보고되고 있습니다. 

저 역시 로그 수집을 위해 Logstash 클러스터를 운영하고 있던 관계로 log4j 에 대한 취약점 대응을 해야 했습니다. 직접 만든 코드가 아니다보니 log4j 에 대한 대응을 어떻게 해야 하나 찾아본 결과를 정리해 봅니다.

https://ondemand.tistory.com/345

영향받는 logstash 버전은?

Logstash의 6.8.20 이하, 혹은  7.16.0 이하 버전은 모두 영향범위에 들어갑니다. 오래된 버전은 log4j 의 낮은 버전이 탑재되어 있을 수 있겠지만 기본적으로 현시점까지 릴리즈된 버전은 모두 영향범위로 보는 것이 맞겠습니다.

// logstash의 경로는 사용 환경에 따라 다를 수 있습니다
//
$ /usr/share/logstash/bin/logstash --version
logstash 7.3.1

새로운 버전의 릴리즈는?

가장 확실한 방법은 새로운 버전의 릴리즈를 기다리는 것입니다. Logstash의 가장 최신 버전은 7.16.0 버전으로 확인됩니다 (2021.12.13 오전 7:38 기준) 이 버전에서 사용하고 있는 log4j 는 취약점이 있는 버전으로 조치가 필요합니다.

현재 예고되어 있는 패치 버전의 공개는 한국 시간으로 늦어도 14일까지 릴리즈 될 예정입니다. 따라서 아직까지는 보안 취약점이 제거된 새로운 릴리즈 버전을 사용할 수 없고, log4j 의 취약점 대응을 다른 방식으로 해야만 합니다.

Logstash core-jar 파일에서 jdni 클래스를 삭제하기

elastic 에서 logstash 의 log4j 취약점 제거를 위해 공식 가이드하고 있는 방법은 logstash 패키지에 포함된 core-jar 파일에서 jdni 클래스를 제거하는 방법입니다. 느낌이 왔겠습니다만 아주 확실하고 강려크한 방법이라고 생각합니다. 참고로 한때 유통되던 log4j 의 실행시 옵션을 주는 방법은 유효하지 않다고 합니다. 클래스를 확 날려버리는게 현재로서는 가장 확실한 방법입니다.

// jdnilookup.class 를 삭제합니다
// 경로 (/usr/share/logstash)는 각자의 환경에 맞추어 수정합니다
//
sudo zip -q -d /usr/share/logstash/logstash-core/lib/jars/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class

// 자바 클래스 재로딩을 위해 logstash 를 재기동합니다
//
sudo systemctl restart logstash

log4j 처럼 광범위하게 사용되는 패키지의 취약점 발견으로 여기저기 들썩들썩합니다. 모두들 무탈히 이슈 대응 하시길 기원합니다!

지난주 후반부, 한국 뿐만 아니라 전세계가 시끌시끌했습니다. 
사실상의 서버측 로깅 표준으로 자리잡힌 log4j 로깅 모듈의 보안 취약점이 발견되었고
공격방법이 인터넷에 고개되면서 Zero Day Vulnerability 가 발생했기 때문입니다.

취약점을 간단히 요약하자면,
"로그로 기록되어야 하는 문자열에 악의적인 내용을 집어넣어 원격지에서 서버의 코드, 명령을 실행할 수 있는 취약점이 있었음"
입니다.

취약점을 통해 외부에 노출되지 않은 LDAP 서버 등으로 악의적인 코드가 담긴 자바 클래스를 전송하고 
log4j 를 통해 이 클래스를 메모리에 로딩하는 방식으로 서버에 침투하게 됩니다. 
이번 취약점은 오래전 SSL 프로토콜의 취약점으로 명성을 날렸던 하트블리드(heartbleed)급으로 알려졌습니다.

취약점에 대한 대응은 크게 두가지 방식으로 진행되었습니다. 
1. 취약점이 패치된 log4j 가 배포되기 전까지는 코드 인젝션이 발생할 수 있는 JNDI 의 옵션을 끈다
2. 취약점 패치 버전 (2.15.0+) 가 배포된 후에는 새로운 log4j 로 교체한다

이런 대응이 여러 회사의 개발조직 중심으로 대응되는 동안 
물들어올때 노를 저어야 한다는 것을 잘 알고 있는 클라우드 벤더들은 
열심히 관련된 포스팅을 날리며 자사의 보안 솔루션들을 홍보하기 시작했습니다. 

간만에 글로벌 초대형 급의 취약점으로 주말이 시끌시끌 했습니다. 
아직까지 취약점은 현재 진행형이기 때문에 두눈 부릅뜨고
log4j 를 쓰는 곳이 없는지 살펴봐야 하겠습니다!

스크래치 Scratch 를 비롯한 드래그 앤 드랍 방식의 코딩 도구들이 아이들 코딩 교육에 많이 쓰입니다.
스크래치 이후 등장한 엔트리 entry 등 수많은 도구들은 스크래치가 제안한 블록 코딩을 철저히(?) 따르고 있기도 합니다.
성인들의 세계에서는 블록 코딩은 아니지만 노코드 No code 개발이 하나의 트랜드가 된 것 같습니다.

구글에서 내놓은 앱시트 AppSheet 역시 노코드를 표방하는 개발 도구입니다.
단순히 노코드를 하는 것을 넘어서 데이터 기반으로 개발한다는 것을 강조하고 있습니다. 
파이어베이스 Firebase 류의 Pass Storage를 바탕으로 개발 작업을 할 때 느꼈던 감성을 
앱시트를 사용한 개발에서도 느낄 수 있는 것인가, 하는 기대감이 생기게 되더군요. 

사실 원래부터 모든 어플리케이션, 소프트웨어, 서비스는 데이터 중심이었죠. 
데이터가 없으면 잘 만든 UI도 아무짝에 쓸모 없습니다. 
근래에는 데이터하면 결국 AI, ML로 이어지니 이런 맥락에서 앱시트는 포지셔닝을 하는 느낌입니다. 
쉽고 빠르게 필요한 것을 데이터 기반으로 만들고 거기서 또 데이터를 추출해낸다?

가령 구글 시트에 위와 같은 간단한 테이블을 만들어 두고
앱시트를 통해서 Form 중심으로 CRUD 를 할 수 있는 앱을 만든다가 기본적인 컨셉입니다.
어차피 대부분의 어플리케이션이 DB에 대한 CRUD 라는 것에서 착안한 듯 합니다.
특히나 기업에서 사용하는 In-House 도구에서는 무척 유용할 것 같네요

노코드는 앱 에서 뿐만 아니라 머신러닝 쪽에서도 대세로 자리잡는 느낌입니다.
코드를 써야하는 과제와 쓰지 않아도 되는 과제의 분리를 통해 
누구나 필요한 것을 만들어 쓸 수 있게 하는 방향성은 이제 대세가 된 것 같네요!

피쳐에 대해서 잘 정리된 블로그 하나 링크해 둡니다!
https://meir.tistory.com/m/89

트위터의 창업주 3인방중 하나였던 잭 도시가 트위터 CEO직을 내려놓았다. 
이로써 먼저 회사를 떠난 에반 윌리엄스, 비즈스톤에 이어 마지막으로 회사를 떠났다.
물론, 스퀘어 Square 라는 걸출한 사업을 하고 있기 때문에 
재벌 걱정, 부자 걱정 할 필요 없는 것과 마찬가지라는 느낌이다.

그런데, 그 직후 바로그 스퀘어가 사명을 블록 Block 으로 바꿨다.
위 이미지에서 보이는 것처럼 블록 = ["스퀘어", "캐시앱", "스파이럴", "타이달", "TBD54566975"] 라고 정의하고 있다. 
스퀘어를 제외한 나머지가 뭔지 좀 찾아봤다.

• 스퀘어 Square / https://squareup.com/us/en
  • 전자 결제 회사
  • 기기도 만들고 온/오프라인에 걸쳐 사업 영역이 꽤 넓다
  • 상장사
• 캐시앱 Cash App
  • 아티스트와 팬이 직접 지불(?)할 수 있는 서비스 플랫폼
• 타이달 Tidal / https://tidal.com/
  • 음원 스트리밍 서비스. 사용자 수? 잘 모르겠음
  • 그 어느 서비스보다 많은 음원 수수료를 아티스트에게 지급한다는 소문
• 스파이럴 Spiral / https://spiral.xyz/
  • Formerlly called <Square Crypto>
  • 비트코인과 관련한 개발을 하고 있으며 SDK, 툴킷 등을 만들고 있음
• TBD54566975 / https://twitter.com/TBD54566975
  • 스퀘어에서 차세대 파이낸셜 서비스를 만들고 있던 개발 유닛이었음
  • 이제 막 독립을 시작하여 활발하게 채용도 전개하고 있는 중
  • TBD 는 To be detailed... 인듯 -_-;;

대략 정리해보면 컨텐츠 서비스들과 파이낸셜 서비스가 밍글되고 있는 느낌이다.
용처를 이미 찾아놓고 비트코인, 새로운 결제 수단? 시스템?을 만들어 나가려고 진영을 구축하는 것 같기도 하다.

가끔 드는 생각이지만, 오래전에 <소셜 네트워크로 세상을 바꾼 사람들> 책을 썼을때
트위터 편의 중심이 "에반 윌리엄스"였던 것은 다소 좀 실책이었다는 느낌이다. 
이후 비즈 스톤을 정말 좋아했었는데... 근래에는 잭 도시만 존재감이 있다.
세상은 알다가도 모르겠다... 싶다. 

AWS의 CDN 제품인 CloudFront는 원본 서버에서 제공하는 기본 오브젝트를 지정할 수 있는 기능을 제공하고 있습니다. 보통은 원본 서버에서 사용하는 웹 서버에서 기본 오브젝트를 지정하는 경우가 많지만 S3 등 다른 제품을 함께 사용할 때는 기본 오브젝트를 지정할 수 있는 방법이 없기 때문에 파일명을 지정할 수 있는 기능이 필요합니다.

기본 루트 오브젝트 설정 Set Default Root Object

CloudFront Distribution의 기본 설정 탭에서 기본 루트 오브젝트를 설정할 수 있습니다. Distribution 목록에서 작업하려는 Dist ID를 선택하여 상세 화면으로 진입합니다. 상단 탭중 첫번째 탭인 General 탭으로 이동합니다. Settings 섹션의 `Edit` 버튼을 눌러 상세 설정 화면으로 진입해 봅니다. 

Edit 화면의 중간 정도를 살펴보면 `Default root object - optional` 항목을 찾으실 수 있습니다. 이곳에 지정된 파일 이름이 CloudFront를 통해 접근시 사용되는 기본적인 파일 이름이 됩니다. 가령 www.iamnopd.com  이라는 도메인이 있다고 가정했을 때, 브라우저에 www.iamnopd.com  만 입력해도 알아서 index.html 을 찾아 사용자 브라우저로 응답을 하게 되는 거죠. 

다양한 경로에 대한 기본 오브젝트 설정 

그런데 문제가 있습니다. `Default root object`에 지정한 파일 이름은 진짜, 레알, 루트 경로에 대한 요청에 대해서만 적용되는 한계가 있습니다. 가령 원본이 S3 버킷이라고 했을 때, 버킷의 최상위 경로에도 index.html 이 있고, 버킷에 생성되어 있는 api 폴더의 하위에도 index.html 이 있다고 해봅시다.

아마도 여러분이 기대하는 것은 www.iamnopd.com  접근시에도 index.html 을 읽어들이고 www.iamnopd.com/api  접근시에도 index.html 을 읽어들여 사용자에게 제공되는 시나리오였을겁니다. 하지만 첫번째 케이스와 달리 두번째 api 경로에 대한 접근은 index.html 을 알아서 패칭해오지 않습니다. 반드시 www.iamnopd.com/api/index.html  로 호출을 해야 컨텐츠를 읽어오게 됩니다.

원본의 서로 다른 경로를 특정 사용자 Path의 루트로 바인딩 하기 위해서는 (아시겠지만) 아래와 같이 동일 원본을 Origin Path만 분기하여 등록하면 됩니다. 이 구성과 Default root object 의 조합은 /api 경로에 대해서 적용되지 않는다는 상황으로 이해하지면 될 것 같습니다. 그러면 어떻게 하면 될까요?

CloudFront Function을 이용한 경로 조작

S3에서 뭔가를 하면 되지 않을까? 하고 생각했을지도 모르지만 그것보다는 CloudFront Function을 쓰면 간단하게 구현할 수 있습니다. 아시겠지만 Lambda@Edge를 쓰는 것보다 CloudFront Function을 쓰는 것이 사용도 간편하고(=기능이 다소 적고) 비용도 저렴합니다. 묻지도 따지지도 말고 바로 코드를 보겠습니다.

function handler(event) {
    var pathFrom = /^\/api$/g
    var pathTo   = '/api/index.html'
    var pathDecided = '';   
	var request = event.request;
    pathDecided = request.uri;

	if (pathDecided.match(pathFrom) != null) {
    	pathDecided = pathDecided.replace(pathFrom, pathTo);
	}

    request.uri = pathDecided;
    return request;
}

코드는 무척 간단합니다. 간단한 Regex 를 이용하여 들어온 URI (request.uri)를 단순히 문자열 비교한 후에 실제로 원본이 받게될 URI 를 변경해서 return 해주는 코드입니다. 요청량이 많아도 크게 부담스러운 금액이 나오지는 않을것 같습니다. 간단하지만 Default root object가 단일 경로에 대해서만 적용되는 제약을 회피(?)하는 방법을 살펴봤습니다 :-)

테스트도 참 쉽죠? 원하는 결과를 테스트를 통해 얻었다면, 만든 함수를 적용하고자 하는 Distribution의 Behavior의 Viewer Request 함수로 지정하면 됩니다. 끝!

일단 최강의 참조글은 https://homoefficio.github.io/2015/07/21/Cross-Origin-Resource-Sharing/ 이다.