🛵꾸준한 꿈틀꿈틀

오늘은 2024년을 마무리하면서 2025년을 잘 보내보기 위해 2024년의 경험을 기반으로 개인 회고를 작성해보려고 합니다.이번 회고는 올해에 있었던 일들을 제가 추구했던 가치관 카테고리별로 돌아보고 마지막에 KPT방식으로 회고해보려고 해요.지난 2023년 회고회고를 작성하기 전에 2023년 회고를 다시 읽어봤는데, 아래와 같은 목표를 적어놨었던 걸 발견했습니다.2024년 중간에 여러 일들이 있었지만 결론적으로는 건강한 사람, "요새 좋아보인다"는 말을 여러명에게 듣게된 것 같습니다 ㅎㅎ 엔지니어링 분야에서 좋은 영향력을 나누자 - 컨퍼런스 발표, 커뮤니티 활동, 멘토링올해는 제가 소프트웨어 엔지니어로 일한지 3년이 되는 해였어요. 3년이라는 시간동안 업무와 공부를 열심히하느라 바쁜 시간을 보냈고 이제는..

혹시 Zero Copy에 대해서 아시나요? 저도 데이터 엔지니어링을 공부하면서 처음 알게되었고 꽤 흥미로운 메커니즘이었습니다 ㅎㅎ그리고 최근에 kotlin을 활용해서 파일 서빙을 다루는 작업을 진행했던 경험이 있는데, 당시 파일 전송 속도가 꽤 중요한 요소였고 자연스럽게 Zero Copy가 떠올랐습니다.kotlin을 사용하다보니 JVM이라는 도구에서 오는 특성 등도 고민하게 되고 꽤 의미있는 경험이었는데요.그래서 오늘은 Zero Copy에 대해서 간단하게 소개하고 kotlin S3 upload에서 Zero Copy가 가능한지? 등을 공유해보겠습니다 :)먼저, 코드레벨에서 파일 전송 등 local storage(e.g. disk)에서 파일을 읽어서 외부로 보내는 로직을 구성했다면 어떤 과정을 거치게 될까..

이 글은 최근에 있었던 서버 OOMKilled 장애 과정을 기록 및 공유하며 회고하는 글입니다.또한 이 글은 인프라 레벨(cpu, memory)에서의 장애 감지 및 대응 프로세스에 관한 내용을 기록하기 때문에 NPE(Null Point Exception) 같은 코드 레벨에서의 명확하고 단순한 문제는 크게 다루지 않습니다. 여러분들은 서버의 메모리가 부족해 OOMKilled 장애 발생 시 어떻게 대응하시나요?저는 보통 다음과 같은 프로세스로 대응합니다.1. 장애 감지2. 예상되는 원인 범위를 합리적으로 찾고 가설을 세운다. (가설 수립)3. 가설을 검증하기 위해 APM, log 등 단서들을 찾고 가설을 확인하고 원인 범위를 좁혀간다. (가설 검증 및 route finding)4. 위 과정을 반복하여 원인을..

'좋은 개발자 되기'에서 이어지는 글로 지극히 주관적인 내용을 다룹니다 :)2023년 9월에 '좋은 개발자 되기'라는 글을 통해서 비밀 노트(?)를 공개했었는데 이제는 1년이 지난 시점이 되었습니다.그 당시에 적었던 내용은 다음과 같이 항목이 2~3개 정도 되는 내용이었어요.  그리고 지금 시점으로는 1년 간의 경험이 담겨져 다음과 같은 내용으로 변경되었어요.오늘은 아래 내용의 각 꼭지별로 좀 더 이야기를 해보려고 합니다 :) AUSGCON이라는 컨퍼런스에서도 아래 내용을 기반으로 발표를 했었는데요! 관심있는 분들은 살펴보셔도 좋을 것 같습니다 ㅎㅎ> gRPC와 함께 알아보는 같이 일하고 싶은 엔지니어 발표자료 이건 하지 말자상대방 입장을 고려하지 않고 충분한 맥락 공유 없이 본인만 아는 이야기를 한다-..

MySQL 실행 계획 분석💡 실행 계획에서 표시되는 각 컬럼이 어떤 것을 의미하는지 알아보자메뉴얼한 작업이나 가끔 쿼리 성능을 확인하고 싶을 때 EXPLAIN 키워드를 통해 MySQL 실행 계획을 살펴보게 되는데, 각 칼럼의 의미에 대해서는 명확하게 정리하거나 알아본 경험이 없는 것 같아서 이번 기회에 이를 정리하고 상기합니다.각 칼럼의 구성은 다음과 같습니다.id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, Extra id 칼럼💡 ID 컬럼은 단순히 SELECT 쿼리 수를 의미하고 해당 SELECT 쿼리를 식별하기 위한 용도로 사용됨.SELECT 쿼리 수를 의미하므로 같은 ID가 여러..

트랜잭션의 격리 수준(isolation level)에 대해서 정확하게 이해하는 것은 애플리케이션 로직을 정확하게 제어하는 것에 있어서 중요합니다. 하지만 격리 수준이 구체적으로 어떻게 동작하는지 정확하게 모르고 있었던 사실을 발견해서 재학습을 위해 내용을 정리합니다. 이 글은 MySQL 기준으로 작성합니다. 트랜잭션 격리 수준 격리 수준은 크게 다음과 같이 4가지로 다음과 같이 나뉘게 됩니다. READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE 1번에서 4번으로 갈수록 트랜잭션 간의 데이터 격리 수준이 높아지며, 동시 처리 성능이 떨어지는 것이 일반적입니다. 그리고 보통 SERIALIZABLE 정도가 아니면 크게 성능의 개선이나 저하는 발생하지 ..

Java에서는 null을 안전하게 다루고 표현력을 높이는 방법으로 Optional이 잘 알려져있는 것 같습니다. 하지만 실제로 사용하다보니 wrapper 타입이라는 점으로 인해 고민되는 요인들이 꽤 많았는데요. 정확히는 Optional을 nullable 표현의 용도로 API response 필드 값에 사용하고 싶었는데 그 과정에서 고민되는 점이 있었어요. 오늘은 그 내용에 대해 개인적인 생각을 적어보려고 합니다. Optional을 response 필드에 사용할 때 문제점 1. 직렬화 "Optional은 직렬화하는데 의도치 않는 필드가 직렬화되는 문제가 발생할 수 있습니다." 직렬화 라이브러리의 구현마다 다르겠지만 모두 Optional을 호환하는지는 보장되지 않으므로 우리가 제어할 수 있는 영역이 줄어들고..

다음과 같은 지식을 학습하고 정리합니다 벌크형, 스트리밍 형 데이터 전송 스트리밍형의 데이터 전송인 메시지 배송 구조와 트레이드오프 성능을 얻고 신뢰성이 희생되는 경우 등 메시지 배송에 있어서 프로세스 시간과 이벤트 시간의 구별 이벤트 시간을 고려한 최적화 데이터 색인을 통한 최적화 NoSQL 데이터베이스의 몇 가지 특성과 구분 데이터 축적의 전반적인 플로우 4-1 벌크 형 스트리밍 형의 데이터 수집 데이터 전송에는 벌크 형과 스트리밍 형의 두 종류가 있음 각각의 방법으로 분산 스토리지에 데이터가 저장될 때까지의 흐름을 살펴보자. 객체 스토리지와 데이터 수집 빅데이터는 대부분의 경우 확장성이 높은 분산 스토리지에 저장됨 분산 형의 데이터베이스가 이용되는 경우도 있지만 대량으로 파일을 저장하기 위한 객체 ..