⚠ Switch to EXCALIDRAW VIEW in the MORE OPTIONS menu of this document. ⚠ You can decompress Drawing data with the command palette: ‘Decompress current Excalidraw file’. For more info check in plugin settings under ‘Saving’
Excalidraw Data
Text Elements
https://www.youtube.com/live/ZWWUSN13Wzw?si=jUgyfOWovBN8NmfS
-
장인정신이란 무엇?
-
기능만 동작하면 끝인 걸까?
-
더 개선할 여지는 없을까?
예제1. 1부터 N까지의 정수 합 구하는 함수 작성 ^rsCjZSa8
-
for 문
-
스트림
-
가우스 공식
자 보면 가우스방식은 n끼리 곱이 있어서 루프 방식보다 n값의 커버리지가 작음. long으로 바꿔도 결국은 루프방식보다 커버리지가 낮다. 속도는 훨씬 빠르지만…
곱이 문제니 미리 나눌수 있지 않을까???
사칙연산
아! 이렇게 깊이 생각할 수 있구나!!!
예제2. 배치 작업 ^IAJPqgOz
상황
-
어떤 기기가 1분 마다 스캔한 데이터를 디비에 저장하고 있는 상황
-
해당 기기가 100대 있음
-
배치 작업: 검수를 위해 하루 한번 100대가 하루동안 스캔한 데이터를 각각의 압축 파일로 만들어 3rd party API 통해 업로드
-
최초의 배치는 싱글 스레드로 구현: 총 7시간 소요
-
이걸 스레드 10개로 증가: 총 3시간 정도로 시간 단축!
-
이정도도 괜춘.
-
하지만! 더 나은 방법 없는가?
-
왜 스레드 개수를 열개로 잡았나? a:일단 트라이한거라 시니어가 대답하고 휴가감…
- 이 태스크를 조금 더 구체적으로 분석해보자! (1) 기기 한 대가 하루 동안 스캔한 데이터를 압축 ⇒ CPU Bound, 소요 시간은 약 4분 (2) 압축 파일을 검수 API에 업로드 ⇒ I/O Bound, 소요 시간은 약 1분
I/O Bound 일 때는 스레드가 적당히 많으면 오히려 병렬성에 좋음
CPU Bound 일 때 스레드가 많으면???
서버 코어 수를 확인! 배치 서버는 2코어임. 이때 스레드 10개를 만들어 놓음. 압축 작업시 코어를 계속쓰게됨 압축 동안에 다른 스레드들은 암껏도 못함. CPU가 필요하기 때문이지… CPU 바운드 작업시
결국! CPU 바운드 작업시 context switching은 계속 일어나지만 병렬성 자체는 2개로 유지되서 오히려 CPU 시간(context switching 때문)을 낭비하게 됨!!!!!
-
아 10개가 최선이 아닐수도 있겠다. 더 나은 스레드 개수가 있을 수 있음. 다섯개로 조정해볼까?
-
근데 최적의 스레드 수를 찾는게 베스트일까? 오버 엔지니어링 아닐까?
- 데이터 양이 미래에 어케될지 모르기 때문에 이 고민을 할 필요가 있는지 등등
-
관점의 재 점검: 스레드 수 조정 외에 다른 접근은 없을까???
- scale up! core 수 증가
- scale out! 더 많은 서버 사용
-
좋은데 현재 서버 스펙에서 더 개선할 수 없을까? 위에건 돈들어…
-
기기 100대에 대해서 (1)작업 부터 먼저 다 하고 이어서 (2)번 작업을 한번에 하면 어떨까?
- (1) 작업 때는 2~3개의 스레드
- (2) 작업 때는 비동기 호출(WebClient, etc…)
-
이게 진짜 최선일까? 더 개선 여지 없을까 고려한건?
- 검수 API에 부하를 주진 않을까?( 동시에 몇 개의 파일을 업로드 할 지 고려)
- DB에서 데이터를 읽어 올때 하루 치 스캔 데이터를 한번에 다 읽어오면 서버 메모리는 괜찮을까?
- 스트림 방식으로 압축 파일 생성 방법 검색
- etc 압축 방식(알고리즘)쓸지 도 고려해보기
예제 3. 캐싱 ^FAuSQskZ
스프링 앱에서 로컬(인메모리) 캐싱하는 코드
이게 최선일까?
- 나: 아 가격이 바뀔 수 있어서 그런감…
캐싱된 데이터를 바꿔서 문제다. 원천 데이터는 원화 데이터임. 문제는 자바의 모든 객체는 레퍼런스로 접근. 아 여기서 price를 달러로 바꿨음. 근데 다른 스레드가 접근했을때도 저 price로 접근해서 원화를 달러로 보게되는 엄청난 문제 발생.
가격에 final을 붙이기. 나머지도 붙이고. 아 캐싱된 데이터는 불변객체로 만들자!
캐싱 데이터는 참조될거니까 함부로 바뀌면 안되겠네… 그래서 final 붙였어 근데 이게 최선?? 아 불변 객체가 있구먼!!!!
불변 객체로 만들어서 변경을 아예 차단한다!!
JDK 16 부터는 불변 객체를 위한 record를 사용해볼수 있음!
- 질문: 여기에 List 멤버가 추가된다면? List
이건 어케 불변 객체화 하징? ^favygeOJ
그외
- 우리 사이트에서 원화로 팔다가 달러로도 팔려함.
- 백, 프 각 각 코드 조금 고치면 달러로도 판매하게끔 만들 수 있겠는데
- 근데 앞으로 일본, 동남아도 공략…
- 추가 통화(currency)지원 필요 미래 가능성 존재.
- 이 상황에서 어떤 것 최선?
- 매번 추가마다 코드 수정이 좋은가?
- 아니면 어드민 페이지에서 딸깍으로 통화 추가/제거가 자유롭게 되는게 좋을까?
근시안적 해결 VS 원시안적 해결 ⇒ 트레이드 오프 고려
정리: 이게 최선일까? 고민하는 습관
성능 혹은 안정성의 관점에서 늘 고민 리소스는 언제나 한정되어 있다 명확한 근거를 추구하고 있는가? 바라보는 관점을 다양화 하기 더 편할 순 없는가?
Embedded Files
7527952db094fac25a00991d522d0d64fea1410c: SCR-20250419-tjjd.png
8b64fce6b75b7e8da33f8d326bcd48e0b50ad1a4: SCR-20250419-tjkd.png
457889bdf371d06f0875e2a376a921a81ffc2611: SCR-20250419-tkil.png
757b33b7154c95da5422638a4022374b35e7572f: SCR-20250419-tmac.png
0a1e1cc8d10baebf491a2392269996b9055c2915: SCR-20250419-tvfw.png
972a3becc08febad1a47b1426ed95fe658af959b: SCR-20250419-tvux.png
0882b403aa46b971b7a4f46c907f99f67ae48828: SCR-20250419-twjd.png
cdb44e281e2d33dc776c02e261f00b1c799ae9e2: SCR-20250419-txqj.png
2a6383f01247dbdd61f07243cfa081ad095bab4d: SCR-20250419-tydp.png
