행복한디벨로퍼

2월 한달 간 읽었던 포스팅 중 유익했던 블로그 글들에 대해 정리해보려 한다. 총 3개의 글로 현재 개발 6년차인 나에게 부족했던 부분에 대한 지식을 완고히 해주었거나 너무 익숙해서 그냥 지나쳤던 것들에 대해 다시 한 번 생각해 보게 하는 글들이였다.

1. Java, max user processes, open files (관련한 발생가능한 문제와 해결에 관한 글)_

실제 서비스를 운영하다 보면 리눅스의 커널 설정을 변경해주어야 하는 경우가 종종 발생한다. 예를 들어 request가 유실된다던지 open files의 설정과 max user processes의 설정이 낮게 잡혀있어 요청처리율이 낮은 경우입니다. 이외에도 tcp timeout과 같은 네트워크 적인 설정 부분도 있지만 해당 포스팅에서는 주로 접할 수 있는 open files로 인한 문제와 그로 인한 테스트 해결책들을 상세하게 설명하여 기존에 대략적으로 알고 있던 부분에 대한 내용에 대해 다시 한 번 리마인드할 수 있었습니다.

https://woowabros.github.io/experience/2018/04/17/linux-maxuserprocess-openfiles.html 

2. Java NIO는 생각만큼 non-blocking하지 않다.

자바의 NIO에 관련해 왜 생각만큼 non-blocking하지 않는지에 대해 예를 들어가며 설명해주는 글로 NIO에 대해 잘 모르시고 궁금하신 분이라면 한 번 쯤 읽어보길 권장드립니다.

https://homoefficio.github.io/2016/08/06/Java-NIO%EB%8A%94-%EC%83%9D%EA%B0%81%EB%A7%8C%ED%81%BC-non-blocking-%ED%95%98%EC%A7%80-%EC%95%8A%EB%8B%A4/

3.싱글톤 패턴(Singleton pattern)을 쓰는 이유와 문제점

애플리케이션이 시작될 대 어떤 클래스가 최초 한 번만 메모리에 할당되고 그 메모리에 인스턴스를 한 번 만들어놓고 지속적으로 가져다 사용하는 디자인 패턴인데요. 아마 스프링을 쓰시는 분들은 @Bean이라는 어노테이션을 통해 많이들 사용하고 계시리라 생각됩니다. 하지만 싱글톤 패턴의 장점은 잘알고 있지만 단점에 대해서 잘 모르고 저 또한 사용하고 있었고 해당 포스팅에서는 @Bean 어노테이션을 사용하지 않고 싱글톤 패턴을 구현하는 방법들에 대해 설명해 주고 있으며 일반적으로 알고 있는 잘못된 방법에 대해서도 설명해 줍니다. 실제 멀티쓰레드 환경에서 자바 모듈을 구현해야하는 분들이시라면 읽어보면 많은 도움이 되실 것 같습니다.

https://jeong-pro.tistory.com/86

이전에 적어놓았던 독서노트 문구중 공유할만한 문구 몇 가지를 소개해볼까 한다. 어떤 책인지는 적어놓지 않아 모르겠다ㅠㅠ

개발자로 일을 하고 있지만 나 또한 처음 개발자로 취업한 것이 결코 코딩을 하는 것이 즐겁거나 재미있어서가 아니였다. 하지만 지금은 하루 하루 코딩하며 개발자로서의 삶을 살아 갈 수 있다는 것이 큰 기쁨이다. 어떻게 이렇게 된걸까?라고 생각을 해보면 분명 힘든 시절이 있었다. 남들과의 비교로 내 실력이 형편없어 보일 때 오는 좌절감과 특정 기능 구현에서 막혔을 때의 막막함이 있었지만 그런 고통 속에서 나는 하루 하루 성장해 나갔던 것 같다. 그렇게 다양한 문제들에 직면하고 해결하는 과정, 비교로부터오는 좌절감을 극복하기 위한 공부는 내 개발실력을 조금씩 향상시켜주었다. 사람은 이기적인 동물이라 내가 잘하는 것은 재밌다고 느낄 확률이 크고 잘 하지 못하는 것에 대해서는 하기 싫은 법이다. 적성에 맞는지 안맞는지는 내가 그 일을 '잘한다'라는 생각이 들 위치까지 올랐을 때 잘함에도 불구하고 흥미를 느끼지 못하거나 더이상 하고 싶지 않을 때 생각해봐도 충분하다고 생각한다. 일단 지금의 일을 잘하기 위해 노력부터 해보자.

아래의 문구들은 나의 위의 생각들을 뒷받침해주는 내용이기에 공감이 가서 노트에 적어 놓았던 것 같다.

• 인생을 행복하게 보내려면 자신이 좋아하는 일을 해야 한다고 말하는 사람이 많다. 자신이 좋아하는 일을 해야 능률이 오르고 집중할 수 있다고 말이다. 그러나 처음부터 자신이 좋아하는 분야를 선택해 평생 자신의 직업으로 삼는 사람이 얼마나 될까? 애석하게도 그런 사람은 1,000명 중 한 명이 될까 말까다. 더구나 자신이 좋아하는 회사에 들어갔더라도 본인이 희망하는 부서에 배치되고, 자신이 원하는 일을 하는 사람은 1만 명 중 한 명도 되지 않는다. 그렇다면 1,000명 중 999명 1만 명 중 9,999 명은 불행하고 좋아하지도 않는 일을 억지로 해야 하기 때문에 능률이 떨어진다고 봐야 할까? 그렇지 않다. 오히려 자신이 좋아하지 않는 분야에서 출발했지만 그 분야에서 두각을 나타내는 사람이 크게 성공할 수 있다.

• 자신에게 주어진 일이 천직이라는 마음으로 즐겁게 일하는 것이 중요하다. 주어진 일이라서 어쩔 수 없이 한다는 생각을 버리지 않으면 절대로 일하는 고통에서 벗어날 수 없다.

• 자기가 좋아하는 일을 추구하는 것은 유토피아를 찾는 것과 같다. 유토피아는 화려하지만, 현실에서는 절대 이루어질 수 없다. 유토피아는 유토피아일 뿐이다. 그래도 유토피아를 현실에서 이루고 싶다면, 지금 자신 앞에 놓인 일을 먼저 사랑하라.

• 할 수 없다고 생각하면 아무것도 할 수 없지만, 할 수 있다고 믿으면 아무리 캄캄한 어둠 속에서도 반드시 길어 보이는 법이다.

예전에 이 포스팅을 보고 신선한 충격으로 머리를 한 대 맞은 듯한 기분이 들었다. 개발자가 발표라니???

'하용호'라는 분이 발표로 인해 본인의 커리어와 인생이 달라지는 이야기를 해주고 있는 글이다.

두고두고 보고 싶은 글이라 포스팅 해본다. 

항상 느끼지만 개발자들은 세상에 너무나도 많다. 그 속에서 내 스스로 어떤 개발자가 되고 싶은가? 실력으로 그들을 다 앞설 것인가? 

아니면 또 다른 나만의 무기를 장착할 것인가??? 그것은 본인의 선택이다. 

요즘 드는 생각은 내가 가진 기술로 어떤것들을 해보고 싶은지에 대한 구체적인 계획이 필요한 것 같다.

https://www.slideshare.net/yongho/ss-52116574

해당 내용은 '소프트웨어 장인'이라는 책의 Chapter11장의 '잘못된 면접 방식'이라는 주제에서 와닿는 내용 몇 개만 발췌한 내용이다. 많은 분들이 공감할 거라 생각한다. 물론 아닌 분들이 계실수도 있겠지만 그 회사의 그 업무에 맞는 면접질문을 하는게 가장 좋다고 생각한다. 읽어보면서 공감가는 부분과 공감가지 않는 것에는 어떤 것이 있는지 생각해보며 읽으면 좋을 듯하다. 해당 내용들은 내게 공감이 많이 되었던 내용들만 추려 포스팅한 것이다.

1. 똑똑한 척하는 면접관을 세운다.

면접관이 지원자보다 똑똑하거나 더 우월해봉고 싶어해서는 안 된다. 면접관의 사사로운 즐거움을 위해 지원자를 힘든 상황으로 몰아붙이고, 자신의 직함, 권한, 지식같은 것들로 지원자를 압도하고 싶어 해서는 안된다. 어느 정도 경험이 있고 실력있는 개발자라면 면접관의 성향을 즉시 알아채고 같이 일하기 싫다는 생각을 할 것이다. 지원자 앞에서 겸손하고 정직해야 한다. 지원자를 프로페셔널 개발자로서 대하고, 채용을 위한 평가나 취조가 아니라 당신이 존주우하는 누군가와의 유익한 기술 토론이 되도록 면접을 이끌어야 한다. 무엇보다도, 지원자의 이야기를 경청하고 그에게 마음을 여는 것이 중요하다. 

2. 답을 모르는 질문을 한다.

면접관으로서 어떤 질문에 어떤 답변이 나와야 하는지 잘 모르겠다면 채용중인 직무와 관련해서는 그다지 중요한 질문이 아닐 가능성이 높다. 해당 직무에 대해서 잘 알고 있다면 무엇이 중요하고 무엇이 중요하지 않은지 이미 알고 있을 것이다. 엉뚱한 질문으로 지원자를 혼란스럽게 하거나 잘못 이끌지 말자. 팀 동료에게 흔히 하지 않는 질문이라면, 팀 동료가 짜증을 낼 질문이라면, 지원자에게도 삼가해야 한다.

3. 종이에 코드를 작성하게 한다.

지원자에게 종이나 화이트보드에 코드를 작성토록 하는 것은 참으로 바보 같은 면접 방법이다. 면접관 스스로도 할 수 없는 일이나 실제 업무 현장에서 부딪히지 않을 상황을 지원자에게 요구해서는 안된다. 실제 업무에서도 종이에 테스트 코드 작성, 코드 리펙토링을 하는가? 고등학교 교사가 학생들에게 알고리즘의 의사 코드를 작성하라고 하는 것과 프로페셔널 소프트웨어 개발자를 채용하는 것은 다르다. 자신의 도구와 기술을 마스터하고 테스트와 리펙토링을 통해 잘 작성된 코드를 만들 수 있는 개발자를 찾아야한다.

4. 알고리즘 문제를 낸다.

알고리즘 무누제를 코딩 면접 과제로 선택하는 면접관들이 많다. 시스템 개발에 필요한 상당수의 업무들이 알고리즘에 대한 깊은 이해를 필요로 하지 않는다. 그럼에도 불구하고 "지원자의 문제 해결 능력을 보아야 한다"라고들 이야기한다. 물론 틀린 이야기는 아니지만 알고리즘 문제 대신 회사의 실제 프로젝트와 가까운 연습문제를 통해서도 '문제 해결 능력'을 평가할 수 있다. 여러 시스템의 문제들 중 거의 대부분이 알고리즘이 어떻게 작성되었느냐와는 관계가 없었다. 테스트가 덜 되었거나 또는 좋은 테스트 방법이 준비되지 못했거나, 잘못된 설계, 떨어지는 응집성, 깊은 종속성, 새 기능 추가 시 부족했던 리팩토링, 지속적인 요구사항 변경, 도메인 모델이 꼼꼼하지 못했거나 등이 가장 흔한 문제였다. 이러한 것들이 '실전 문제'였다. 알고리즘은 절차적이고 함수적인 형태로 구현된다. 알고리즘을 만들 때 비지니스 도메인 모델이나 클래스를 만들지는 않는다.

시스템의 주요 문제가 알고리즘이 아니라면 코딩 면접 때 알고리즘 문제 대신 실제 문제와 가까운 과제를 제시해야 한다. 지원자가 비즈니스 도메인을 표현하고 솔루션을 설계할 역량이 있는지 집중해야 한다. 테스트 주도 개발이나 설계에 스킬이 뛰어난 개발자를 찾고 있다면 그 부분을 반영할 수 있는 코딩 문제를 제시해야 한다. 애플리케이션이 온통 알고리즘에 대한 것이라면 당연히 알고리즘 개발 역량을 평가해야 한다. 요지는 코딩 면접에 알고리즘 문제를 내야 하느냐의 여부가 아니라 프로젝트를 위해 실제 필요한 역량이 무엇인지, 무엇이 가장 가치 있는지를 면접용 코딩 문제에 잘 반영하고 있어야 한다는 것이다.

해당 내용은 '실무로 배우는 시스템 성능 최적화'의 내용중 일부를 발췌한 내용입니다. 웹 방화벽에 의한 성능 저하 사례로 방화벽으로 인해 이러한 문제가 발생할 수 있구나 정도로 인지하고 있다면 비슷한 이슈가 발생했을 때 보다 빠르게 대응을 할 수 있을 거라 생각되어 남겨 봅니다.

현상

전국에서 사용하는 시스템으로, 특정 지역의 윈도우7 사용자만 화면 응답시간이 급격히 느려져 1분 이상 소요되는 현상이 발생했다. 그러나 항상 느린 것은 아니고 동일한 화면도 느릴 때와 빠를 때가 있는데 대부분은 느렸다.

접근 방법

현상을 정확히 확인하기 위해 해당 기관을 방문해 직접 화면을 사용하면서 네트워크 패킷을 수집해서 분석했다. 화면이 느릴 때는 HTTP 요청에서 TCP 재전송이 발생하면서 지연되는데, 결국은 서버로부터 HTTP 요청에 대한 ACK를 받지 못하고 타임아웃인 1분에 걸려서 해당 TCP 세션을 강제로 끊고 새로운 TCP 세션을 맺어 HTTP 요청을 보내어 응답을 받음으로써 1분 이상 소요됐다.

그런데 이상한 것은 아파치 웹 서버의 Keepalive 타임아웃이 5 초인데 사용자단 브라우저 TCP 세션은 5초가 이상 지나도 계속 ESTABLISH 상태를 유지하고 있고, 느릴 때는 5초 이상 경과된 TCP 세션을 사용하고 있었다. 그러나 웹 서버에서는 Keepalive 5초가 경과해서 해당 TCP 세션을 끊기 위해 FIN을 보냈음에도 클라이언트로부터 FIN을 받지 못하고 있는 TIME_WAIT 상태였다.

따라서 클라이언트와 웹 서버 사이 어디에선가 웹 서버가 보낸 TCP 세션 종료 신호인 FIN 패킷을 삼키고 있는 것으로 판단했다. 이런 현상이 특정 기관 사용자에게서만 발생하고 있어 해당 기관 내부 네트워크 이상으로 판단했다. 그러나 웹 서비스의 대표 IP인 L4의 가상 IP 대신 실제 서버 IP를 사용해 테스트를 진행하면 웹 서버 2대 모두로부터 정상적으로 클라이언트가 FIN 패킷을 받았다. 이에 L4 가상 IP 사용과 실 서버 IP 사용 시 발생하는 차이가 웹 방화벽 경유로 기인했음을 확인하고 L4 가상 IP를 사용하더라도 웹 방화벽을 경유하지 않도록 네트워크 설정을 수정해 다시 테스트를 진행한 결과, 웹 서버가 보낸 FIN 패킷을 클라이언트가 정상적으로 받는 것이 확인됐으며, 화면 응답시간도 정상이었다.

원인

웹 서버는 Keepalive 5초가 경과한 TCP 세션을 끊고 있으나 FIN 패킷이 클라이언트에 전달되지 않아 클라이언트는 웹 서버가 close한 세션을 살아있다고 생각하고 해당 TCP 세션으로 HTTP 요청을 전송함으로써 이상을 감지하기까지 오래 걸려 화면 지연이 발생했다. 웹 방화벽에서 웹 서버가 보낸 FIN 패킷을 삼킨 것으로 테스트에서 확인했다.

블로그를 처음 시작하게 된 건 2014년이었다. 처음 시작은 네이버 블로그에서 부터시작했었다.

처음에 블로그를 시작하게 된 계기는 2014년 9월쯤 회사에서 블로그를 만들고 일주일에 하나씩 글을 쓰라는 반강제적인 요구에 의해서 였다. 그렇게 나는 처음 포스팅이라는걸 해보게 되었다. 내가 이렇게 포스팅 하는 글을 남들이 본다고 생각하니 어디서 부터 어떻게 써야할지도 되게 막막했었던 기억이 난다. 그래서인지 포스팅 하는 것 자체가 나에겐 스트레스로 다가왔고 자연스럽게 각자의 팀에 배정되고 나서 부터 터치를 받지 않게 되자 포스팅과는 당연시스럽게 거리가 멀어졌다.

그렇게 6개월 정도 흐르고 다시 포스팅을 시작하게 된 것은 내가 다른 블로그 글들로 부터 많은 도움을 받고 있고 나도 이렇게 글을 남기면 남들이 내 글을 보고 도움을 받을 수 있겠다는 생각에서였다. 그렇게 나는 회사에서 업무를 하다가 처리했던 기술 이슈들 삽질, 그리고 경험들을 블로그에 남겼다. 하지만 이전과 같이 블로그에 글을 쓸 때 마다 정말 내가 겪고 처리한 이슈이외에도 관련된 내용들을 수집해 정말 누가 봐도 괜찮은 포스팅을 하기위해 노력하다보니 글 하나를 쓰는데 많은 시간이 걸렸다. 그렇다보니 일주일에 포스팅을 하나씩 하자고 마음먹었던 것과는 달리 한 달에 하나 두 달에 하나씩 쓰고 있는 나의 모습을 발견하였다.

그렇게 포스팅을 하는데 회의감을 느꼈고 또 잠깐의 공백이 생겼던 것 같다. 포스팅을 하고 있지 않던 그 기간동안 느꼈던 것은 '그래 그냥 누군가 보는데 의식하지말고 정말 그냥 내 개인 웹 노트라고 생각하고 너무 부담갖지 말고 포스팅을 해보자'라는 생각이 들었다. 그즈음이 광고관련 팀으로 이동을 했을 때라 어느정도 광고에 대한 개념도 생겨있었고 adsense를 달아 수익화도 해보고 싶다는 생각이 들었다.

그래서 나는 naver블로그에서 tistory블로그로 갈아타게 된다. 기존의 naver블로그의 글들을 evernote를 통해 tistory로 옮기고 정말 내 개인 노트에 글을 작성하듯 단순 한 것부터 내가 문득문득 든 생각, 읽었던 좋았던 문구들을 가볍게 써나가기 시작했다. 그렇게 포스팅을 하는데 부담감이 사라지니 자연스레 글을 쓰는 횟수도 많아졌고 자연스레 방문자수도 증가했다. 물론 심도 있는 글들을 많이 쓰지 못해 이탈률이 높긴 했지만 그 전처럼 포스팅 하나하나를 쓰는데 너무 많은 시간과 노력을 들이며 부담감을 느끼고 싶지 않았다. 

그렇게 티스토리 블로그를 운영한지 벌써 4년차가 되어가고 작년 2019년의 평균 하루 방문자수는 400~600정도 사이에 이르렀다. 그러다가 최근 처음으로 하루 방문수가 2020/02/18, 2020/02/19 이틀 동안 1,000이 넘었다.

구글 애널리틱스를 보면 /267 개발자 직장생활과 실력향상 관련 좋은 글 번 글이 소히 말하는다른 외부 sns를 통해 공유되어 트래픽이 터진 것이다.

해당 글은 이전에 내가 읽었던 개발자의 커리어와 관련된 글 중 인상깊었던 글을 모아 포스팅했던데 지나지 않았다. 포스팅을 하는데 오래걸리지도 않았을 뿐더러 많은 노력을 하진 않았지만 해당 글로 인해 이틀간이나 하루 방문수가 1,000을 넘게 되었던 것이다.

물론 하루 방문수가 중요한 것은 아니다. 내가 느꼈던 것은 '뭐라도 하지 않으면 아무것도 일어나지 않고 내가 들인 노력, 시간과는 별개로 컨텐츠가 사람들에게 많이 검색되고 읽힐 수 있다는 것이다.' 나는 작년부터 유튜브 컨텐츠도 만들고 있지만 블로그 글들의 통계를 보며 정말 유튜브도 너무 컨텐츠를 잘만드려고 노력하다가 한달에 한번도 안올리는 것 보다는 가볍게 자주 올리는 것이 내 목표인 구독자 천명에 더 빨리 다다를 수 있을 거라는 생각이 들었다. 

그리고 항상 느끼지만 꾸준함에 대한 어려움을 느끼고 무엇인가를 꾸준히 하는 사람들에 대한 존경심을 가지게 된다. 꾸준함은 또 하나의 재능이라고 생각하고, 지금 내가 하고 있는 기술블로그, 유튜브, 운동, 개발 모두 남들과 비교했을 때 느리더라도 꾸준히 앞으로 한 발짝 한 발짝 나아가다 보면 좋은 결과가 있을 거라고 생각한다. 아래의 말로 포스팅의 마무리를 지어보려 한다. 모두 원하는 목표에 도달할 때 까지 화이팅이다!

사람마다 꽃피는 시기는 다른 법이다.

이전에 적어 놓았던 문구들 중 최근에 읽어도 와닿는 문구 몇개만 살포시 포스팅 해본다.

참묘하다
살아서는 어머니가 그냥 어머니더니, 그 이상은 아니더니
돌아가시고 나니 그녀가 내 인생의 전부였다는 생각이 든다.

아이에서 어른이 된다는 건
자신이 배신당하고 상처받는 존재에서 
배신을 하고 상처를 주는 존재인걸 알아 채는 것이다.

우리가 알고 있는 카오스는 혼돈, 혼란, 무질서를 의미하지만,
인문학적 의미의 카오스 이론은 그 혼돈, 혼란, 무질서 속에서도
일정한 규칙이 있는 걸 의미한다.

내 자존심을 지킨답시고, 나는 그녀를 버렸는데, 
그럼 지켜진 내 자존심은 지금 대체 어디에 있는 걸까?

머니문(Moneymoon)의 함정에 빠지지 말라, 머니문이란 어떤 물건을 구매하고 흡족해 하는 심정이 유지되는 기간을 의미한다.
당신이 그것을 구입하기 위해 돈을 지불했다고 해서 반드시 그것이 어떤 가치를 갖는 것은 아니다.
우리가 돈을 지불한 대상 중에서 제값을 하지 않는 것도 많다. 
우리는 구매를 하는 과정에서 많은 실수를 저지르지만 다만 그것을 인정하고 싶어 하지 않을 뿐이다.

활자를 읽는 것에 대한 거부감을 갖고 있다는 것은 진수성찬을 두고 구경만 하는 것과 같다.

사랑이라는 감정을 배우는 요령은 자기감정에 충실한 거에요. '나중에 사랑이 아니면 어쩌지?'이런 생각하지 마세요. 그런 생각하면 사랑 못해요. 하나만 따져요. 감정에 정직했느냐만, 내가 가진 감정이 사랑인지 아닌지는 모르죠. 하지만 사랑이라고 느꼈으면 정직하게 하고, 아니라는 게 확인 될 때 아니라고 이야기해주는 것, 이게 자신과 상대방에 대한 최소한의 예의입니다. 그것만 지키세요.

DSR(Direct Server Return)

:DSR 구조는 L4가 서버들의 로드밸런싱은 하지만 리턴은 서버에서 클라이언트로 바로 리턴 되는 구조

SLB(Server Load Balancing)

:클라이언트의 request와 서버의 Responnse가 둘다 L4를 거쳐 나가는 구조.

최근 운영하고 있는 하둡 클러스터의 노후 장비 교체건으로 데이터노드 한대를 제거 하는 작업이 진행되었다.

해당 로그는 클러스터에 붙어 hdfs을 쓰고 있던 외부 서버에서 발생한 로그이다.

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.server.namenode.LeaseExpiredException): No lease on /user/example....log._COPYING_ (inode 428475201): File does not exist. Holder DFSClient_NONMAPREDUCE_-1052637306_1 does not have any open files.

로그가 발생한 이유는 해당 서버가 hdfs 해당 데이터노드 특정 파일에 write작업을 하고 있었는데 중간에 데이터노드가 내려가면서 write하고 있던 파일을 찾지 못해 발생한 것이다. 

HDFS에서 Lease는 다음과 같이 정의된다.

In HDFS these locks are called Leases. Leases are granted to a client which request to open a file for a write operation (e.g. create / append / truncate a file.) Every lease belongs to a single HDFS Client but could be for several HDFS files. Often enough a lease has several thousand files open for write by a single HDFS client. As the client opens and closes files, the appropriate lease must be identified and updated. The exact datastructures have been changed quite frequently over the years to provide better lookups, better reverse lookups, speed and space efficiency etc. However all this accounting obviously is done on the NameNode. This is in stark contrast to GFS, where a lease is tracked by the Namenode (master server in their parlance) and Datanodes (chunk servers in their parlance) (Section 3.1 in the Google File System paper). For HDFS this means the Namenode has a higher overhead of now maintaining these leases (something GFS expressly wanted to avoid). However this also allows HDFS to allow renames of files being written (which in my experience is not too uncommon an operation.)

이 경우 외에도 스파크(Spark)나 hive의 병렬 작업시에도 작업이 꼬여 발생할 수 있다는 걸 검색을 하다가 알게되었다.

해당 내용은 아래의 블로그를 참고하길 바란다.

https://knight76.tistory.com/entry/hadoop-No-lease-on-File-does-not-exist