성능 최적화 전략

성능저하의 원인

프로그램이 어떤 자원을 많이 쓰는지에 따라 CPU바운드, I/O바운드 작업으로 나뉜다. I/O 바운드 작업은 디스크, 네트워크, 파일 시스템 등과 같은 입출력(I/O) 작업을 많이 요구하는 작업을 의미한다. CPU-바운드 작업은 CPU의 연산 능력을 많이 요구하는 작업을 의미한다. 주로, 실무에서는 CPU-바운드 작업 보다는 I/O-바운드 작업이 많다.

 

메모리 계층구조에 따른 소요시간

계층구조에 따른 소요시간이 다르다. 외부 데이터 접근을 최소화하는 것이 백엔드 입장에서 가장 중요한 성능적 

• 로컬 SSD/HDD 접근 (디스크 I/O)
  
  • SD: 100 ~ 500 마이크로초.
  • HDD: 수 밀리초.

• 내부 데이터베이스(DB) 접근 : 약 50,000 ~ 500,000 CPU 사이클(수백 마이크로초 ~ 몇 밀리초)
• 외부 API호출 : 약 10^6 ~ 10^8 CPU 사이클 (수십 ~ 수백 밀리초)

쓰레드 최적화

 

프로그램의 스레드의 개수는 CPU코어의 숫자를 고려해야한다. 이론적으로, 스레드의 숫자를 CPU의 숫자에 맞춘다면 모든 스레드가 코어에 할당되며 Context Switching도 없어서 최적의 상태에 이른다. 다만, 실무적으로 스레드들이 CPU를 100% 사용하는 경우는 없고 대부분의 스레드가 I/O 대기상태인 경우가 많으므로 무조건, CPU코어 +1로 맞추어서는 안된다.

 

• CPU-바운드 작업 : CPU 코어 수 + 1개, CPU를 100% 사용하는 작업이므로 스레드를 CPU 숫자에 최적화. +1은 특정 스레드가 잠시 대기할 때 남은 스레드를 활용할 수 있다.
• I/O-바운드 작업 : CPU 코어 수 보다 많은 스레드를 생성,  성능 테스트를 통해 CPU를 최대한 사용할 수 있는 숫자까지 스레드 생성.  단 너무 많은 스레드를 생성하면 컨텍스트 스위칭 비용도 함께 증가 - 적절한 성능 테스트 필요

 

 

 

 

 

캐싱전략

캐싱 : 임시로 데이터를 저장하는 것

 

캐싱전략 :

1.  메모리 Hierarchy 중 낮은 곳의 데이터를 높은 곳으로 데이터를 저장하여 I/O자원을 절약하는 전략
2.  CPU자원소모가 심한 연산의 결과값을 저장해두어 CPU자원을 절약하는 전략

캐싱적용 고려사항

1. 요청이 특정 데이터에 많이 몰리는가?

2. 데이터의 크기가 작은가? 

3. 데이터의 변경이 잦은가? 변경의 주기를 생각했을 때 캐싱이 의미가 있는지

 

캐쉬적용가능포인트

1. 브라우저 캐쉬 : 용자의 브라우저에 자주 요청되는 웹 자원을 저장

2. 어플리케이션 캐쉬 : 애플리케이션 레벨에서 자주 요청되는 데이터나 연산 결과를 메모리에 저장

 

 

 

Application Layer Cacheing : 캐시서버생성  

 

 

DataBase Layer Cacheing : 외부API호출 데이터를 내부DB로 캐싱

 

DataBase Layer Cacheing :  OS level Caching

  데이터베이스는 Linux로 운영되며 OS level에서 기본적인 캐싱을 제공한다. 데이터의 양이 그렇게 크지 않다면, I/O 병목이 생겼을때 데이터베이스 서버의 메모리를 증량시키는 것이 첫번째로 고려해볼만한 사항이다. I/O병목은 데이터베이스 서버에서 HDD Disk의 물리적 접근속도 한계로 인해 발생하는 것이기때문에 메모리에서의 캐싱이 제공된다면 접근속도를 상당히 줄일 수 있기때문이다.

  AP서버에서는 OS 캐쉬가 APP의 데이터 외 많은 종류의 데이터가 캐싱되기에 OS 캐쉬에 의존하기 보다는 APP 데이터에 특화된 캐쉬서버를 생성하는게 일반적이다.

 

 

 

many critical decisions about performance optimization are indeed made during the design and architecture stages of software development. This is because architectural choices lay the groundwork for how the system will operate, including how it handles growth, user load, data management, and fault tolerance

 

 

포트폴리오 내 키워드

- DB migration tool 제작 과정에서 entity manager을 호출하는 에러가 잦았고, spring 공식문서과 코드를 뜯어보면서JpaRepositoryFactoryPostProcessor 이해하여 문제해결

- MVC패턴을 도입하고, testcase를 만들고 빌드, 배포 과정까지 전부 혼자서 경험해봄

- 외부 API 사용시 rest template을 사용하면 new instance 생성보다 비용이 절약됨.

- 음료완료시 알람서비스를 양방향 websocket으로 구현하는 것은 오버스택이므로 단방향 SSE으로 결정 

- 

 

 

데이터 베이스 최적화

데이터베이스는 주로 I/O burden을 줄이는 것이 주요한 전략이다. I/O burden은  data search time 와data transferred time 두가지 모두에 영향을 받는다.

 

그러므로 search하는 

• 데이터탐색
  • 데이터의 빈도감소 : 캐쉬전략
  • 속도증가 : 인덱스 활용
  • 볼륨감소 : 정규화
• 데이터전송
  • 볼륨감소 :  DB내에서 전처리를 통해서 볼륨을 줄이는 것

이 유효한 전략일 것이다.

 

1. 정규화와 비정규화의 조화

2. 인덱스 설정

 

 

그외 최적화 전략

 

5. Load Balancing

• Horizontal Scaling: Distribute load across multiple servers to ensure that no single server becomes a bottleneck.
• Load Balancer Configuration: Use load balancers to distribute incoming network traffic across multiple backend servers to maximize throughput, minimize response time, and avoid overload of any single server.

6. API Management

• Rate Limiting: Implement rate limiting to prevent abuse and to manage the load on your backend systems.
• API Caching: Cache API responses where possible to reduce the number of times data needs to be recalculated or fetched from deeper backend layers.

9. Resource Management

• Memory Management: Optimize memory usage to avoid leaks and ensure efficient data storage and retrieval.
• Garbage Collection Tuning: In environments like Java or .NET, tune the garbage collector settings to optimize memory cleanup without significant pauses.