코로나 이후 2023년에 지속적으로 미국 연준은 금리 인상을 이어왔고, 그 여파로 시장에 변동성이 줄어들며 스타트업이 투자 유치를 받지 못해 레이오프를 진행하는 등 경기가 빠르게 둔화되고 있는 것을 체감하고 있습니다. 이러한 배경에서 2024년에 어떻게 주식에 투자해야 할 지 인사이트를 공유하는 책을 이벤트를 제공받았고, 읽고난 후의 서평을 간단하게 공유하려 합니다.

『2024 새로운 주식시장에 올라타라』 는 가까운 미래의 주식 시장을 탐색하며 투자자들에게 실전 투자 기법을 제공하는 도서입니다. 저자들은 다양한 분야의 전문가로 구성되어, 경제 변동성과 AI, 로보틱스 등의 산업에서의 기술 발전이 주식 시장에 미치는 영향을 분석합니다. 특히, 저출산과 고령화 사회에서 주목받고 있는 로봇과 바이오 종목의 성장 가능성을 짚으며, 이에 대한 투자 조언을 제공하는 부분은 도움이 많이 되었습니다. 그 중에서도 현대가 투자한 보스턴다이내믹스에 대해서 관심을 가지고 보고 있었는데, 내용 중 언급이 있어 반가웠습니다.

 

디스플레이에 대한 성장 언급 또한 중요한 부분이었다고 생각이 듭니다. 삼성전자의 영업이익을 리드해왔던 DS 부문의 누적적자는 작년 1~3분기 동안 12조원이 넘는데 반해, 삼성디스플레이는 호실적을 기록했습니다. 애플의 비전프로를 시작으로 AR/VR/XR 시장이 더욱 활발해질 것으로 예상되며, 해당 OLED를 공급하는 LGD 또한 시장의 성장에 힘입어 유망하다는 것에 공감이 갔습니다.

 

로봇과 바이오, 디스플레이 분야의 성장 가능성을 탁월하게 진단한 부분은 좋았으나, 아쉬웠던 부분도 일부 존재했습니다. 생성형 AI 산업, 특히 MS에서 투자한 OpenAI, Amazon에서 투자한 Anthropic, 그리고 Google의 Gemini와 같은 대표적인 AI 빅테크에 대한 언급은 좋았으나, 각각의 비교 분석이 약간 내용이 부족했다고 생각이 들었습니다. 이는 2023년 동안 쭉 이어져온 AI 기술의 빠른 발전과 시장 내 경쟁 구도를 이해하는 데 중요한 부분이며, 2024년의 투자 포트폴리오 구성을 위해 빠져서는 안되는 부분이라 생각합니다. 개인적으로는 2024년이 여전히 AI, 클라우드가 이끄는 시장이 될 것이라고 예상하고 있습니다.

 

또한, 경기 침체에 대비한 구체적인 대응책이 미흡하다는 점도 아쉬웠습니다. 과연 연준이 디플레이션을 일으키지 않고 시장을 연착시킬 수 있을까요? 완전한 연착은 불가능하며, 투자자들이 불확실성에 대처하기 위해 보충되어야 하는 내용이었다고 생각합니다. 과거의 많은 금융위기가 부동산으로부터 시작되었다는 점을 상기하면, 부동산 PF가 심각한 현재 한국의 상황에서 리스크를 헷징할 수 있는 방안을 모든 투자자가 세워야 한다고 생각이 듭니다.

 

 

 

※ 더리치 X 매경출판 이벤트를 통해 『2024 새로운 주식시장에 올라타라』 도서를 제공받아 서평을 작성하였습니다.

아래 Medium 블로그로 이전합니다.

https://medium.com/@nuatmochoi

'AWS' 카테고리의 다른 글

Amazon MemoryDB for Redis  (0) 2022.06.13
AWS EFS  (0) 2021.09.08
DynamoDB 특징에 대해 알아보자  (0) 2021.08.23
Amazon Aurora 알아보자  (0) 2021.08.23
AWS Pinpoint  (0) 2021.06.17

Amazon MemoryDB for Redis

  • 다중 AZ의 내구성을 갖춘 Redis 호환 인메모리 DB 서비스
  • DMS 통해서 ElastiCache에서 Migration 가능

ElastiCache for Redis 가 있는데 왜?

  • MSA로 오면서, Hot Data를 지원하기 위한 데이터베이스가 필요했다
    • Fast
    • Flexible
    • Friendly
  • DB를 관리하기 어려워질 수 있다 (항상 가동)
  • Robust 하게 만들기가 어렵다. (내구성 및 데이터 손실 zero)
  • Scaling 어려울 수도
  • 비싸거나
  • ElastiCache는 기본 DB및 다른 저장소의 Data를 캐싱 or 내구성이 필요하지 않은 일시적 데이터를 위함
    • memcached와 비슷하게 이슈가 있어서 노드가 다운되면 데이터가 날아감
    • 직접 구성하는 Redis의 경우 HDD에 저장되겠지만, ElastiCache는 날아감
      • 단일 노드의 경우 AOF 기능을 통해 노드 재부팅 시 데이터 지속, but 노드 손상 시 데이터 손실
      • multi-AZ(replica) 구성 시에도 노드 승격이 비동기 작업이기 때문에 down-time은 발생할 수 있음
    • 따라서 Multi AZ가 필요함
  • MemoryDB는 멀티 AZ 내구성 / 애플리케이션의 기본 DB(Primary DB)로 지정 가능 (캐싱과는 별개) / 그러면서 Redis API와 호환
    • 영구 저장
    • 쓰기 속도는 ElastiCache보다 좀 느림 (ElastiCache는 쓰기 읽기 모두 microsecond 단위)

기능

  • microsecond read / 한자리 ms write
  • cluster scale out 시 초당 수백만 건의 트랜잭션까지 가능
    • 처리량이 높고 대기 시간이 짧은 까다로운 애플리케이션 지원 가능
  • 관리작업 (스냅샷 등) 자동화
  • Redis API 100% 호환하는 Primary DB
  • multi-AZ 기본 지원 (cluster mode를 통함)
  • DB의 key set 별로 샤드당 최대 5개의 복제본 생성하여
    • 해당 key space에 대한 고가용성 및 읽기 성능 확장
  • 최대 500개의 노드를 가질 수 있음
    • 250개의 Primary + 250개의 Replica (multi-AZ에 따라)
    • 클러스터 당 128TB의 저장소까지 지원

사용 사례

  • 리테일 : 고객 프로파일, 계정 정보 저장 / 재고 트래킹 및 이행 (추적 및 제공)
  • 게임 : 리더보드, 플레이어 데이터 스토어, 세션 히스토리
  • 은행 및 금융 : 유저 트랜잭션, 사기 탐지(실시간 - 빠르게 레코드를 수집하고 Redis를 활용하여 실시간 분석)
  • 미디어 : 유저 데이터 및 실시간 스트리밍
  • IoT : 들어오는 데이터에 대한 실시간 분석 / redis의 기능인 공간 조회(spatial lookup --> 공간 반경 등)

벤치마크

  • R6g.16xlarge 에서
  • 초당 390,000개의 reads / 1.3GB/s read
  • 초당 100,000개의 write / 100MB/s write

스케일링 매우 쉽다

  • aws memorydb update-cluster --cluster-name my-cluster --shard-configuration ShardCount=5

오픈소스 Redis 라면..

  • 데이터 전송 시 기본 시스템이 다운되면, 해당 Replica와 해당 데이터는 사라질 것 (Primary가 act, but not deliver)
  • MemoryDB는 이를 내부적으로 multi-AZ transaction log에 저장하여 모든 노드에 저장되고 원하는 곳으로 전달될 것.
  • 모든 것은 Primary DB로 Redis를 제공하기 위한 설계

AWS 서비스간 비교 (내구성 측면 )

ElastiCache for Memcached

  • 내구성 측면 지속성 없다.

ElastiCache for Redis

  • 내구성 없으며, 실제로 다른 데이터 베이스를 캐싱하거나
  • 임시 데이터의 Primary DB 역할을 할뿐임
  • 스냅샷을 사용하거나(연속 스냅샷은 불가)
  • 다른 노드에 대한 비동기식 복제 --> 문제는 비동기이므로 데이터 손실 생길 수 있음

MemoryDB for Redis

  • Multi AZ transaction log -> 모든 쓰기 작업은 내구성을 가짐

Reference

 

'AWS' 카테고리의 다른 글

AWS 블로그 이전합니다.  (0) 2023.05.08
AWS EFS  (0) 2021.09.08
DynamoDB 특징에 대해 알아보자  (0) 2021.08.23
Amazon Aurora 알아보자  (0) 2021.08.23
AWS Pinpoint  (0) 2021.06.17

Serive proxy

proxy and service

(이미지는 ClusterIP 기준)

  • kube-proxy는 고전적 의미의 proxy가 아니라 서비스에 대한 가상 IP를 구현하기 위함
  • proxy를 사용하는 이유는 인바운드 트래픽을 백엔드에 전달하기 위함.

Proxy mode

  1. Userspace
    • Service가 생성되면 Node에 Proxy port 생성
    • 클라이언트 요청 인입 시, iptables는 요청한 ClusterIP와 Port를 확인하고, Proxy Port로 트래픽 라우팅
    • kube-proxy는 기본적으로 Round Robin 방식으로 백엔드 Pod 선택 + Session Affinity(AWS ELB의 Stick Session과 동일)에 따라 Pod 중 하나를 선택하여 트래픽 전달
      • Pod로의 요청 실패 시 자동으로 다른 Pod로 연결 재시도
      Userspace
  2. iptables : default proxy mode. userspace와 달리 kube-proxy는 iptables만 관리하며, 직접 트래픽을 받지 않음. iptables을 거쳐 요청이 직접 포드로 전달되어 userspace보다 빠르다.
    • Service 생성되면 Node에 kube-proxy에 의해 iptables 갱신
    • 클라이언트 요청 인입 시, 패킷의 Target이 Service의 IP와 Port로 설정
    • iptables의 rule 중 맞는 Backend가 있다면 Random하게 선택
      • pod로의 요청 실패 시 재시도 없이 그냥 실패. 방지를 위해 Readiness Probe(컨테이너의 요청 준비 여부 확인) 설정 필요
    • 지정된 Pod으로 패킷 전달 전, 패킷의 Target의 IP와 Port를 해당 Pod으로 수정
    iptables
  3. IPVS : Linux 커널 제공 L4 LB인 IPVS가 Proxy 역할을 수행. iptables보다 높은 성능(low latency & high throughput)IPVS

'Docker & k8s' 카테고리의 다른 글

[K8S] 4. Cluster Networking  (0) 2022.02.03
[K8S] 3. Kubernetes Network Commands  (0) 2022.02.03
[K8S] 2. Kubernetes Commands  (0) 2022.02.03
[K8S] 1. Kubernetes Core Component  (0) 2022.02.03
도커란? (Docker)  (0) 2020.12.17

Cluster Networking

  1. Pod 내 Container간 통신
  • veth0(VNI)는 하나의 IP를 사용하며, 각 컨테이너끼리는 port 번호로 서로를 구분

2. Pod-to-Pod 통신

  • Pod 하나는 고유한 IP 주소를 가지며, IP 주소로 서로 통신

3. Pod-to-Serivce 통신

  • Pod는 죽었다가 살아날 수 있고, IP 주소가 동일할 것이라는 보장이 없기 때문에, Service 앞단에 reverse-proxy나 Load Balancer를 둠으로써 통신이 가능
  • service 정의 시 selector를 통해 트래픽을 전달할 Pod를 결정

4. External-to-Service 통신

Service

  • Pod는 클러스터 내에서 노드를 옮기며 IP가 변경됨
  • 동적으로 변하는 Pod의 IP를 특정하기 위한 방법이 Service
  • label과 label selector를 활용하여, 어떤 Pod를 Service로 묶을지 정의

Service Type (서비스를 외부 IP 주소에 노출하는 방법)

ClusterIP

  1. ClusterIP : 클러스터 내부에서만 접근. 실서비스에서 단독 사용 X
    • 기본적으로 외부와 통신 불가
    • 외부와 통신을 위해서는
      • netfilter chain rule을 통해 IP로 들어온 패킷을 각 Pod에 포워딩하는 설정을 하거나
      • worker node 내 reverse proxy를 생성하여 ClusterIP로 패킷 포워딩
      • 위 세팅을 EKS에서 진행하기 위해서는 EKS cluster 생성 시에 ssh 접근을 위한 값들을 입력해주어야 함
  2. NodePort : 모든 Node에서 특정 포트를 열고, 이 포트로 보내지는 모든 트래픽을 서비스로 forwarding
    • 포트당 한 서비스만 할당
    • 30000~32767 사이 포트만 사용 가능
    • Node의 IP주소가 바뀌면 이를 반영해야 함
  3. LoadBalancer : 모든 트래픽이 로드밸런스를 거쳐 서비스로 포워딩
    • AWS EKS에서 LoadBalancer 타입은 NLB를 프로비저닝 (L7을 사용하려면 Ingress 타입으로 배포)
  4. Ingress : 도메인 및 경로를 기반으로 들어오는 패킷을 특정 서비스로 포워딩
    • AWS EKS에서 Ingress 타입은 ALB를 프로비저닝함
    • ingress 사용 이전에 clusterIP나 NodePort 타입의 서비스가 생성되어 있어야 함
    • worker node 내부에 ingress를 감지하여 로드밸런서를 프로비저닝하는 ingress controller가 있어야 함

ETCD

  • 2379 포트에서 클라이언트 통신을 받고, 2380포트에서 서버간 통신

Reference

'Docker & k8s' 카테고리의 다른 글

[K8S] 5. Kubernetes Service Proxy  (0) 2022.02.03
[K8S] 3. Kubernetes Network Commands  (0) 2022.02.03
[K8S] 2. Kubernetes Commands  (0) 2022.02.03
[K8S] 1. Kubernetes Core Component  (0) 2022.02.03
도커란? (Docker)  (0) 2020.12.17

Command network

  • Network interface : ip a, ip link
    • state 확인 가능
  • MAC address of ControlPlane : ip link show etho0
  • arp -a
  • 외부 통신 : ip route show default
  • 모든 열린 TCP 소켓 리스트 : netstat -nplt
  • 포트의 상태 확인 : netstat -anp

CNI

  1. /opt/cni/bin : 설치된 CNI의 배포 패키지 확인
    • 네트워크 인터페이스 : 인터페이스를 컨테이너의 Network Namespace에 추가하고, 호스트와 연결 (veth pair)
      • BRIDGE, VLAN, IPVLAN, MACVLAN, WINDOWS 등
    • IPAM 플러그인 : 인터페이스에 IP를 할당하고, Routing Table 갱신
      • host-local, dhcp, static 등
  2. /etc/cni/net.d : 설치된 CNI의 설정 파일
    • 예를 들어 Calico 설치시, 설정 파일을 /etc/cin/net.d/10-calico.conflist에 저장하는 식
  3. kubectl get daemonset -n kube-system : CNI에 해당하는 daemonset 확인
  • weave-net deploy : kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
  • cluster ip range : cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep cluster-ip-range
  • kube exec -it pod -- sh로 쉘 실행 이후, curl http://web-service.default.svc 등 FQDN을 통해 액세스 여부 판단 가능
    • ex> bacekend-database.default.svc.cluster.local
      • backend-database : 서비스 이름
      • default: 서비스가 정의된 namespace
      • svc.cluster.local : 클러스터의 도메인 접두사
  • k exec -it hr -- nslookup mysql.payroll > /root/CKA/nslookup.out

'Docker & k8s' 카테고리의 다른 글

[K8S] 5. Kubernetes Service Proxy  (0) 2022.02.03
[K8S] 4. Cluster Networking  (0) 2022.02.03
[K8S] 2. Kubernetes Commands  (0) 2022.02.03
[K8S] 1. Kubernetes Core Component  (0) 2022.02.03
도커란? (Docker)  (0) 2020.12.17

+ Recent posts