본문 바로가기
728x90

전체 글98

[알고리즘 뽀개기] 링크드리스트 팁 https://leetcode.com/explore/learn/card/linked-list/219/classic-problems/1210/ 팁이 잘 나와있네요. 겨우 팰린드롬 링크드리스트 풀었습니다.Palindrome Linked List slow와 fast를 두고 중간값을 찾아가는데,그 와중에 slow의 역순까지 만듭니다. 그리고, 중간 이후부터 팰린드롬인지 검사하면 됩니다. 2024. 6. 28.
[알고리즘 뽀개기] 링크드리스트 해시맵, 투포인터 전략 링크드리스트가 순회하는지 확인하는 전략은 다음과 같다.- 해시테이블- 투포인터 - 방문 마킹- 등등 그 중에 투포인터와 해시맵 전략을 알아본다. https://leetcode.com/explore/learn/card/linked-list/214/two-pointer-technique/1212/https://leetcode.com/explore/learn/card/linked-list/214/two-pointer-technique/1214/ 릿코드에서 해시테이블은 기본 임포트가 아닌가보다. 해시테이블로 써야할 것을 해시맵으로 변경했다. 2024. 6. 25.
[알고리즘 뽀개기] Arrays101 #2 끝~!  괜찮은 editorial을 발견했습니다.https://leetcode.com/problems/third-maximum-number/editorial/ 비기너에게 아주 유용해보여요. 2024. 6. 23.
이슈 발생시 이슈 및 원인을 공유하고 빠른 해소가 가능한지 이야기 나눈 후에 빠른 해소가 불가능하다 싶으면, 이용자 액션으로 풀 수 있냐?를 질문하고.이게 가능하면죄송합니다 도개자박고 공지하는건 어떨까. 2024. 6. 21.
분석용 데이터 수집 및 모델링 -2. 데이터 전처리 수집한 데이터를 곧바로 분석하는 것은 불가능합니다.따라서 분석이 가능하도록 데이터 추출, 결측치 처리, 이상치 제거, 분포 변환, 표준화, 카테고리화, 차원 축소와 같은 작업을 수행해야 합니다.이러한 과정을 통틀어 데이터 전처리라고 합니다. 데이터 전처리를 어떻게 하느냐에 따라 분석 결과가 유의미한 결과를 도출할 수도 있고, 그렇지 않을 수도 있으며 좋은 성능의 모델을 만들 수도, 만들지 못할 수도 있습니다.  전처리는 수작업으로 진행하며 자동화하는 것이 어렵기에 일반저긍로 분석 프로세스의 전체 실행시간 중 60~70%(많게는 90%)를 차지합니다.  데이터 전처리는결측치, 이상치, 중복데이터를 제거하여 데이터 왜곡을 없애고, 모델의 정확도를 높여줍니다. 데이터 전처리 방법.* 데이터 타입의 일관성 : .. 2024. 6. 21.
분석용 데이터 수집 및 모델링 -1. 요구사항 요즘 데이터의 중요성이 다시금 떠오르고 있습니다.과거에는 엔티티의 최종 상태가 모인 디비에 요리조리 쿼리를 날려 지표를 뽑았다면,요즘에는 분석이 메인이 되어 분석을 위한 데이터를 쌓고 쿼리하는 요구사항이 날로 늘어갑니다. 저는 데이터 엔지니어는 아니지만, 잡부이므로 관련 요청을 받았습니다. 잘은 모르지만, 얼핏 책에서비즈니스를 전개하는데 쓰이는 데이터 모델링과 분석을 위해 쌓는 데이터 모델링은 굉장히 다르다는 것을 보았습니다. 그래서 분석용 데이터를 모델링 하기 위해 기초적인 내용을 좀 학습해볼까 합니다.(아예 아무것도 모르는 상태라서..) 2024. 6. 21.
Optional에 대하여 핑이 발표한거 적었습니다. Optional을 도입할 만큼 Null을 핸들링할 만큼 Null은 NPE를 발생시키고 애플리케이션에 위험을 발생시킬 수 있음.Null이라는 문제를 줄이기 위해 Optional을 사용하면 좋겠고, 가장 중요한건 불필요하게 Null을 만들지 않는게 중요함.값이 절대적으로 존재함에도 불구하고 Boxing을 쓰곤 함. 이런게 꼼꼼한 개발자일수록 불필요한 null에 대한 고려를 하게 됨.  - Optional이 Serializable을 구현하지 않아서 필드에 부적합함- argument에도 적합하지 않음. 필요하면 JSR 305의 @Nullable 사용할 것 -> 정적분석기에 hint를 줌- Optional은 공짜가 아님. 성능이 진~짜 중요한 부분에서는 Optional을 지양하기도 함-.. 2024. 6. 21.
OOM 발생시키고 CPU, Memory Usage 확인하기 객체를 계속 만들고 무한루프를 돌면서 리스트에 삽입합니다.리스트에 레퍼런스가 있기 때문에 만들어진 객체는 정리되지 않고 계속 쌓일 것입니다. 그렇게 OOM이 발생합니다.  OOM이 발생할 때의 지표를 보겠습니다.  정상적으로 작동하는 앱은 GC가 적절할때 돌기 때문에 힙 메모리 사용 모습이 peak, vally를 반복하는 모습입니다.하지만 위 지표는 메모리 누수가 발생하여 메모리 사용량이 꾸준히 증가합니다.GC activity도 높습니다. 계속 메모리를 정리하려고 하는데, 정리할 메모리가 없습니다.  이렇게 메모리 누수가 계속 발생하다가 GC가 충분한 데이터를 삭제할 수 없게 되고 언젠가 메모리가 가득 차면 OOM이 발생할 것입니다. 2024. 6. 16.
동시성 예제를 통해 보는 좀비스레드가 있을 때와 없을 때 차이 뇌가 뜨거워지는 어쩌고에서 작성한 것처럼, 여러 스레드가 비동시성 컬렉션에 액세스하여 변경을 시도하면 경쟁상태가 발생하게 됩니다. 마치 앱이 중단된 것처럼 보이지만 내부적으로는 굉장히 열일을 하고 있는 것이죠. CPU리소스는 쓰고 있으나, GC activity는 0입니다. (즉 GC에 사용되는 CPU 사용량은 없다는건, GC가 안되고 있다는 뜻 더 나아가 할 게 없다는 뜻이기도 합니다) 일반적으로 동시성 문제로 발생하는 좀비 스레드를 나타내는 이상징후로 볼 수 있다고 합니다.오히려 CPU 사용량에 GC에 의해 사용되는 비율이 월등히 높다면 메모리 누수 징후일지도 모릅니다. 어쨌든, 앱이 처리능력은 사용하고 있는데, 실제로 아무것도 처리하고 있지 않는 것입니다. 또한 우측의 메모리 사용량도 보면 거의 사용.. 2024. 6. 16.
토스 카프카 IDC 이중화 솔루션을 보고 토스에서 발표한 카프카 IDC 이중화 전략 발표영상을 보았습니다. 토스증권은 각종 주식데이터, 사용자데이터, 로그 등등 대부분의 곳에 카프카를 쓴다고 합니다.그러므로 카프카의 가용성과 내고장성이 매우 중요한 상태고단순한 브로커 이중화뿐만 아니라DR의 일환으로, IDC 단위로 장애가 났을 때를 대비하여 IDC또한 이중화를 한다고 합니다. 다만 보통 IDC단위의 이중화를 할 때는 active-standby 모드로 구성합니다.active를 사용하고 있다가 active에서 문제가 발생하면 standby가 active를 해주는 것이죠.  하지만 active-standby 모델은 유지보수 관점에서 운영에 이슈가 있다고 합니다.standby로 유지되던 것이 실제 장애가 발생하여 active역할을 수행하려고 할 때 여.. 2024. 6. 16.
컨슈머 주도 계약, Spring Cloud Contract https://spring.io/projects/spring-cloud-contract  아키텍쳐 책을 보다가 컨슈머 주도 계약이라는 개념을 보았습니다.일반적으로 하나의 프로바이더와 여러 컨슈머가 있을 때, 프로바이더가 업스트림이 되어 계약을 주도하고 컨슈머는 순응하게 됩니다.하지만 이 개념은, 컨슈머가 직접 프로바이더와 컨슈머간의 계약을 정의하고 시스템적으로 계약을 강제하기까지 하는 것입니다. 먼저1. 컨슈머가 계약을 정의합니다.2. 프로바이더와 컨슈머는 이 계약을 강제합니다 (ex. 테스트코드, 피트니스함수) 저는 처음에 1번의 과정이 단순히 프로바이더-컨슈머간 구두로 얘기 정도밖에 생각나지 않았습니다.이게 시스템적으로 가능할까? 싶었는데, 함께 스터디하는 고-수 개발자님께서, Spring Clou.. 2024. 6. 16.
뇌가 뜨거워지는 멀티스레드 프로그램에서 좀비스레드 동시성 프로그래밍을 연습중입니다. 좀비스레드는,앱 실행이 끝난 뒤에도 계속 실행 상태로 남아 앱의 리소스를 차지하는 스레드입니다. 좀비스레드는 다양한 상황에서 발생할 수 있습니다.예외처리 미흡, 스레드 자원정리 미흡, 스레드풀 사용시 등등,, 저는 동시성 프로그래밍을 연습하면서 좀비스레드를 만들어보았습니다. 동시성 처리가 되어있지 않은 ArrayList에 데이터를 발행/소비하는 Producer와 Consumer를 만들고 이를 여러 스레드로 수행했습니다.일부 예외가 발생한 스레드는 상위로 전파되어 Runnable이 종료되어 스레드 정리가 되었으나,일부 스레드는 계속 해당 로직에서 busy waiting 상태로 머물러있었습니다. Producer 하나와 Consumer 3개를 만들었는데, Producer1,.. 2024. 6. 15.
728x90