yeonwoosung/devopsmisc

Miscellaneous codes and writings for DevOps

Yeonwoo Sung

Skills

📚 Tech Stack 📚

       
       

Kaggle

Kaggle Competition Expert

Education

BSc in University of St Andrews (2016 - 2020)

NVIDIA, Deep Learning NLP certificate (2019)

NVIDIA, Rapid Application Development with Large Language Models (2024)

Coursera - Machine Learning, Certification for ”Machine Learning” course (2018)

Awards

• Dean’s List for academic excellence in the academic year 2019/20
• Medal for performance in Programming Projects module (2018)

devopsmisc's Issues

리눅스 로그 관리에 대하여

리눅스 로그 - system log, rsyslogd, 저널(journal) 로그, Logrotate, mongodb log rotate

백엔드나 시스템 개발자라면 로그의 중요성을 너무도 잘 알 것이다.
그러나, 로깅 그 자체도 컴퓨팅 파워를 많이 소모할 수 있으며, 대용량 트래픽 환경에서는 특히 최적화가 중요해지게 된다.

syslog와 journald가 함께 커널 로그를 관리하는 현대 리눅스 생태계에서 커널 로그를 잘 관리하면서, 어플리케이션 로그 역시 잘 관리할 수 있는 방법에 대해 많은 고찰이 필요한 요즘이다.

Handling large amount of network traffic for Open Chat service (Line Tech Blog)

tech blog: LINE 오픈챗 서버가 100배 급증하는 트래픽을 다루는 방법

• 오픈 채팅 서비스의 경우, 전체 채팅방들 중 일부 채팅방이 급격한 트래픽 증가를 가져오는 핫챗 현상이 일어날 수 있음
• 예를 들면, 게임 오픈 채팅방이나 특정 이벤트를 위한 오픈 채팅방 등의 경우 평소에는 정상적이다가 특정 상황(이벤트 상황) 등에 트래픽이 크게 늘 수 있음
• 갑자기 트래픽이 증가하게 되면 DBMS에 부하가 급격히 증가할 수 있음

해결법:

1. Redis 등에 각 채팅방의 트래픽 양을 실시간으로 기록하고, 특정 시간대에 일정 수준 이상의 트래픽이 몰리게 되면 해당 채팅방에 대해서는 푸시 알림 등의 요청을 block 시킴 (간단한 핫챗 throttling 로직)

2. 조인 throttling: kafka나 redis, local cache를 사용해서 트래픽 기록 및 throttle 적용.

• Kafka의 경우, 대용량 트래픽에 대해 쓰로틀 체크 시에 약간의 지연이 있을 수 있는데, 그 사이에 DB에 충분한 부하가 가해져서 시스템이 더 오랜 시간동안 손상될 수 있음
• Redis에 기록할 경우, 일부 핫챗을 위해 평상시에 다른 모든 수 많은 채팅방들에 대해서도 데이터를 Redis에 기록하고 체크하는 통신 알고리즘이 적용되어야 하는데, 이는 비효율적임
• 외부 서버의 Redis가 아닌 로컬 머신 내의 캐시를 사용하면 통신 등의 부하를 줄일 수 있음

3. 서킷 브레이커와 벌크헤드를 적용해서 특정 샤드에 문제가 생겨도 장애가 다른 샤드들로 전파되는 상황을 방지

• 서킷 브레이커는 문제가 발생한 지점을 감지하고 실패하는 요청을 계속하지 않도록 방지하도록 하는 것을 목표로 하는 디자인 패턴이다

Performance visualization with flamegraphs

If you read Netflix's tech blog, you could easily find extremely useful articles that debugs the performance of the system with flamegraphs

ref1, ref2

It is definitely useful to learn how to use flamegraphs for performance debugging with various programming languages and frameworks

AWS EC2 bandwidth - different instance type has different NW bandwidth

aws ec2 describe-instance-types --query "InstanceTypes[].[InstanceType, NetworkInfo.NetworkPerformance]" --output table

By running the command above, you could print out the network performance of each instance type

gRPC

gRPC는 구글에서 개발한 API 통신 방법으로, protobuf라는 구글의 인코딩 알고리즘을 활용해 효율적인 네트워크 통신을 하게 하며, HTTP/2를 사용해서 통신을 진행한다.

Disabling Garbage Collection to save more memory?

Instagram이 Python garbage collection 없앤 이유

네임스페이스와 cgroup은 무엇이며 어떻게 작동합니까?

네임스페이스와 cgroup은 무엇이며 어떻게 작동합니까?

AWS EC2 instance names explained

Amazon EC2 names explained

Instance families come in six different groups :

• General Purpose
• Compute
• Memory
• Accelerated
• Storage
• HPC

General Purpose

General purpose instances keep a balance between vCPU, memory, and network performance. Some instances add aditional capabilities to CPU (z) and network (n) and there are multiple CPU options for AMD (a), Intel (i), or graviton (g) chips.

The general purpose group includes: A, M, Mac, T

Compute Optimized

Compute optimized only includes the c type instance with different generations, capabilitities, and sizes. Almost every c instance has a 2:1 ration of memory to vCPU. If you use a medium instance with 1 vCPU it will have 2 GiB of memory. If you use a 32xlarge with 128 vCPUs it will have 256 GiB of memory.

These instances are ideal if your workloads need a lot of CPU power and not as much memory.

Memory Optimized

Memory optimized instances are for workloads that consume more memory than CPU. They have a memory to vCPU ratio ranging from 4:1 up to 32:1. An instance like r6i.xlarge has 4 vCPUs and 32 GiB of memory while an x2iedn.2xlarge has 256 GiB of memory with 8 vCPUs.

Memory optimized are some of the best instances for clusters like Kubernetes because many workloads are memory bound more than CPU bound. This will let you pack an instance with more workloads than types with lower memory to vCPU ratios.

Accelerated Computing

Accelerated computing is the most specialized of all of the groups. If you need specialized compute acceleration for your workloads you probably already know.

Most of these instance types have GPU accelerators or specialized machine learning chips. The only non-machine learning special accelerators are the f1 instances with field programmable gate arrays (FPGAs) and vt1 with Xilinx U30 media accelerator cards.

All of the types have a variety of local storage and high memory. The GPU types—g and p—have multiple video cards options with varying sizes of GPU memory. Some instances have multiple accelerators but not all accelerators can be shared with workloads at the same time.

It’s more important to chose the appropriate size for these instances to optimize your usage and keep your costs low.

The accelerated computing group includes: DL, F, G, Inf, P, Trn

Storage Optimized

Storage optimized is exactly what you might think—lots of throughput at low latency. All of these instances will have local storage of various sizes. For most of the instances the memory to vCPU ratio is either 4:1 or 8:1.

All that disk IO wouldn’t be very useful without good network throughput and these instances generally have more network performance at smaller instance size than any other type. They don’t have the fastest network available, but faster than many of the general purpose instance types.

HPC Optimized

This group only hase one type HPC with 2 options, the hpc6id.32xlarge or hpc6a.48xlarge. You can get a big instance with Intel (i) or AMD (a) processors with the main benefits being no hyper-threading and lots of network bandwidth.

If you want HPC instances you have a very specific need that needs either 16:1 or 8:1 memory to CPU ratio. They are only available in us-east-2 and GovCloud regions so don’t expect to use these in multi-region deployments.

Storage optimized group includes: D, H, I, Im, Is