강승훈

1주차 회고

• 페어 프로그래밍 진행
• 기능 구현에 집중하기 보다는, 서로의 다른 의견을 공유하며 보다 넓은 시야로 문제를 찾게되는 과정이 좋았음
• 둘의 의견이 [안정성,효율성]과 [객체 지향, TDD]로 완전 다른 가치관을 가지고 토론했기 때문에 더 좋았음

2주차 회고

24년 7월 3일 수업 Linux 설치

• 파일 시스템 마운팅은 중요하다는 것을 깨달았다.
  • 뭐가 잘못됐는지는 모르겠지만 계속 제자리였다.
  • 그래서 mysql, java 설치는 못했다.

was

학습 내용

• 객체지향, 구현에 집중하기 보다는 소켓이 무엇인가? 어떻게 동작하는가?에 대한 학습에 집중했습니다.
• 학습한 내용에 따르면, H/W 계층인 NIC 부터 Driver, TCP buffer, user mode buffer까지 전송되는 과정 모두 각각의 buffer를 통해 버퍼링이 된다는 것이 핵심이라고 생각합니다.
• TCP buffer의 경우 connection에 따라 각각의 메모리 영역을 활용하지만, 그 아래의 Driver, NIC 수준에서는 공유된 buffer를 사용할 것이고, 그렇다면 상위 계층에서 버퍼를 빠르게 비워주지 않으면 트래픽이 발생했을 때 문제가 된다고 생각했습니다.
• 이를 바탕으로 빨리 버퍼에서 데이터를 퍼올릴 생각을 했는데, 잘못된 생각으로 String으로 빠르게 전환하는 것에 집중했고, 이후에 java의 성능으로 빠르게 변환하는 것이 거의 영향이 없다는 것을 깨달았습니다.
• 단순히 버퍼의 내용을 다른 메모리에 적재하여 빠르게 비워주기만 하면 된다는 것을 깨닫고, output stream으로 우선 다른 버퍼에 데이터를 퍼올린 다음, 한 번에 파싱하는 방법을 적용했습니다.
• java의 스레드가 어떻게 매핑되는지 공부했고, pthread_create로 생성할 때 마다 커널 스레드도 생성되는 것을 확인했습니다. 그래서 무분별한 스레드 생성보다는 스레드 풀을 사용하는 것이 리소스를 보다 잘 활용할 수 있다는 것을 알게 되었습니다.
• 다만 매핑 과정이 항상 a스레드가 생성한 a 커널 스레드에 매핑되는 것은 아니고, 어떠한 이유로(컨텍스트 스위칭 등으로) 매핑이 해제된 커널 스레드는 다른 자바 스레드와 매핑을 하여 재활용 하듯이 동작할 수 있습니다.
• 스레드 풀이 각각의 스레드로 처리하는 메소드의 결과를 리턴하여 활용하고 싶었고, 비동기 처리가 가능한 CompletableFuture를 적용했습니다.
  • 다만, 비동기 프로그래밍, CompletableFuture의 경우 깊게 알지 못하기 때문에 이후 추가 학습이 필요할 것 같습니다.

느낀점

• 앞으로 상위 계층 구현을 할 것 같아 이제는 기능을 적절히 분리해야 할 것 같습니다.
• 왜? 어떻게 동작하는지에 집중하고 구현에 집중하지 않아 3단계 완성을 못했습니다. 우선 구현에 시간을 더 투자해야 할 지 고민입니다.

3주차 회고

학습 내용

• 클라이언트 소켓에는 포트가 없다는 새로운 사실을 알게 되었습니다.
• 이를 확인하기 위해 와이어 샤크를 활용하여 확인했습니다.
• 개념적으로 어떻게 동작하는지 다시 살펴볼 필요가 있어, 파일 시스템을 다시 살펴봤습니다.
• 이후 해당 개념을 바탕으로 리눅스에서 소켓이 어떤 구조체를 참조하고 있는지, 커널 레벨에서는 해당 구조체를 어떻게 관리하고 매핑하는지 살펴보았습니다.
• 살펴본 결과 <source IP, source Port, target IP, target Port>의 정보를 해시 테이블에 저장하고 이를 파일 디스크립터와 매핑하여 효율적으로 접근할 수 있음을 알 수 있었습니다.
• 결국 이러한 과정에서 추가 포트가 할당될 필요가 없음을 배웠습니다.
• 이외에도 리플렉션을 활용하여 다양한 작업이 가능함을 배웠습니다. 특히 인터셉터를 리플렉션으로 처리한 부분이 여러 인터셉터를 등록할 수 있어 좋았습니다.

4주차 회고

학습 내용

• IO작업은 상당히 오래 걸리는 작업이다.
• 디스크 IO를 할 때 읽기와 쓰기를 분리하여 처리하면 보다 효율적으로 작업을 할 수 있다.
• 위와 같이 비동기로 작업을 처리할 때 파일은 순차적으로 써야하기 때문에 동시성 이슈가 발생할 수 있다.
• 큐는 동시성 문제를 해결하기 위해 사용하기 좋은 자료구조이다.
• 여러 큐를 활용하여 작업을 병렬 처리하고, 큐마다 하나의 스레드가 작업을 처리한다면 순차적으로 파일을 쓸 수 있다.
• 가상 스레드 관련 기술 블로그를 보니 위와 같은 IO 작업을 가상 스레드가 하면 좋을 것 같다.
• 용량이 큰 파일의 경우 한 번에 읽어서 응답하기엔 너무 큰 부담이다. 이를 해결하기 위해 stream으로 응답할 수 있는 방법이 존재한다. Content-Type: chunked를 헤더로 응답해주면 클라이언트는 서버가 데이터를 계속 보내줄 것을 인지하고 커넥션을 끊지 않는다. 이 방법을 활용하면 사용자는 조금씩 이미지가 보이기 때문에 한 번에 받는 것 보다 빠르다고 체감할 것이다.

5주차 회고

학습 내용

• 이번 주는 크게 학습 보다는 기능 구현이 주가 되었던 것 같다.
• 단순 기능 구현이 싫어서 CS를 어떻게 프로젝트에 적용할 지 고민했다.

고민한 내용

• 현재까지 텍스트만 저자앟는 게시판에서 CS를 적용할 수 있는 부분은 캐시밖에 떠오르지 않았다.
• 게시글의 경우 최근에 올라온 글이나 인기글 위주로 조회를 많이 할 것이라고 생각했다.
  • 따라서 메모리 캐시를 만들어서 활용하면 시간 지역성을 보장할 수 있었다.
  • 이를 적용하기 위해 LRU 알고리즘을 적용하면 좋다고 생각했고, LinkedHashMap에서 해당 기능을 간편하게 제공해 주어 이중 연결리스트를 직접 만들 필요는 없었다.
  • 테스트를 해보니 내가 설정한 MAX 값을 넘어선 저장은 LRU 알고리즘처럼 조회된지 가장 오래된 노드가 제거되었고, 메모리에서 읽어오니 DB I/O가 감소한 모습도 볼 수 있었다.

6주차 회고

학습 내용

• 이번에도 기능 구현이 주가 되었다.
• 7주차 발표 자료 준비를 많이 했다.
• 발표 자료를 준비하며 CS 공부한 내용을 다시 복습했다.
• 발표 리허설을 했다.
• mmap에 대한 의문점이 있었는데 honux님께 질문을 드렸고 궁금했던 점을 해결할 수 있었다. 가상 메모리의 포인터가 메모리에만 향하는 줄 알았지만, mmap은 사실 disk에도 포인터가 있는 형태이고 디스크의 파일에도 데이터가 write가 된다는 사실이다. shared memory와의 차이점은 비휘발성/휘발성의 차이이다. 하지만 이렇게 만든 기능을 여러 사용자들이 어떻게 사용하냐에 따라서 disk에 기록되지 않게 사용할 수 있으며 이러면 shared memory처럼 동작하게도 되는 것으로 이해했다. 그리고 file에 쓰고 파일의 어느 부분에 쓰냐에 따라서 여러 프로세스들이 하나의 파일에서 mmap도 할 수 있다. 물론 동시에 같은 구역을 쓰면 안되니까 이런 이슈가 없도록 처리할 필요가 있다.

느낀점

• CS는 항상 부족한 것 같다.
• 설명을 잘 하기까지는 아직 부족한 것 같아 조금 더 내 지식으로 만들 필요를 느꼈다.

7주차 회고

학습 내용

• 리눅스 커널 이야기라는 책을 지하철에서 읽고 있는데, timeout 때문에 시스템에 문제가 발생할 수 있다는 점이 흥미로웠다. 특히 CS 학습에서는 4 way handshake로 커넥션을 종료하지만, 실제 네트워크 환경에서는 이런 handshake 시에 전송하는 패킷 자체가 손실될 수도 있고, 이로 인해 커넥션을 끊는 쪽에서 close wait 상태가 지속될 수 있다. 이런 상태가 쌓이게 된다면 시스템에 문제가 발생할 수 있다.
• NFS(Network File System)이라는 기술을 동근님이 알려주셔서 간단하게 살펴보았다. 나의 파일 시스템에 네트워크를 통해서 외부의 파일 시스템을 마운트를 할 수 있는 방법이었다. 다만, 스토리지 서비스를 제공할 때 각 파일 서버는 모두 같은 상태를 유지해야 하나의 서버가 죽어도 서비스를 유지할 수 있기 때문에 좋은 방법은 아닌 것 같았다. 물론 NFS를 사용하고 각각 마운트된 파일 시스템들을 직접 제어해서 동기화를 하고, fail over 전략 등을 전부 구성할 수 있었다. 하지만 이런 전략을 위해서 결국에는 이를 위한 다른 기술들을 사용해야 했다. 그래서 차라리 hadoop이나 glusterFS같은 기술을 사용하는게 조금 더 합리적이지 않나?라는 생각이 들었다.(NFS와 파일 동기화 기술이 각각이라 관리하기가 까다로울 것 같았다)
• 커버링 인덱스에 대해서 알게 되었다.
  • 민지님이 추천해주신 방법이었다.
  • 어차피 페이징을 할 때, 15개의 데이터만 읽어오기 때문에, 이 15개의 데이터만 인덱스를 사용한다면 굉장히 빨라질 것이다. 이런 방법을 활용한 방법인데, 서브 쿼리로 형성된 테이블과 현재 테이블을 조인한다. 이때 서브 쿼리로 형성된 데이터는 id만 읽어서 전부 인덱스로 읽는데 offset과 limit으로 15개만 읽어온다. 그리고 이후에 사용자 정보와 조인을 진행하기 때문에 조인 연산에서 15개만 보면 되기 때문에 굉장히 빨라졌다. 신기한 방법이었다.

느낀점

• 리눅스 커널 이야기라는 책을 읽을 때 CS 공부를 계속 했기 때문에 책을 이해하기 조금 더 수월했다. 하지만 그런 지식들이 복합적으로 적용되어 어떤 문제가 발생할 수 있고, 어떻게 해결하는 지 접근하는 것은 여전히 어려운 것 같다. 사실 아직도 완벽하게는 이해를 못한 것 같다.
  • 덕분에 이번 주차도 CS가 항상 부족한 것 같다는 느낌을 받았다

8주차 회고

• 팀 프로젝트를 시작했고, 코드 리뷰나 코드 컨벤션, 커밋 컨벤션을 지키며 개발하는 것이 처음이라 재밌었다.

• 파일 업로드 기능을 중진님과 페어로 담당하게 되었는데, 학습했던 CS 지식을 많이 활용할 수 있어서 좋았다. 확실히 CS 공부를 하기 전에는 시야가 좁았지만, 공부를 한 이후에는 시야가 넓어졌고, 리소스를 보다 효율적으로 쓸 방법, 그 과정에서 발생할 수 있는 문제들을 생각하고 프로젝트에 적용하는 과정이 재밌었다.

• 기능 완성을 하고 승수님과 페어로 폴더와 파일 삭제 기능을 담당했다. 데이터 일관성이 중요하다고 생각하여 DB에 락을 걸며 파일이나 폴더를 삭제하기로 결정했다. 확실히 느리긴 하지만, 파일 생성 중에 갑자기 제거되거나 이동되는 문제가 없었고, 사용자 입장에서도 이 방법이 좋을 것 같다고 생각했다.

• 이 과정에서 데드락이 발생했다. 이동이나 삭제 기능은 하위로 폴더를 탐색하며 락을 획득하고, 이후에 파일 크기를 업데이트 하는 과정은 상위 폴더를 탐색하며 락을 획득한다. 이 과정에서 경합이 발생하여 데드락이 발생했다. 어떻게 해결할지 고민했는데, 파일 경로를 저장해서 이걸 활용하는 방법을 고민했다. 하지만 이 경우 경로가 너무 길어지게 되면 인덱스를 사용하지 못하고, 중간에 경로가 변경되었을 때 정합성이 깨지는 문제도 있었다. 결국 데드락이 발생하면 에러 메세지를 응답하여 사용자가 재요청을 하는 방식을 선택했다. MySQL의 경우 데드락을 빠르게 감지하고 락 소유가 적은 트랜잭션을 빠르게 롤백시켜주기 때문에 큰 문제는 없었다.

9주차 회고

• 폴더와 파일 삭제 기능을 마무리 했다.
• 수현님과 페어가 되어 파일 및 폴더 공유 기능을 구현했다.
• 공유 기능에서 고민이 많았는데, 매 요청마다 탐색하며 권한을 획득할지, 레코드 상태만 공유 가능하게 변경할지 고민했다. 전자의 경우, 링크마다 별도의 권한을 사용할 수 있다는 장점이 있었고, 후자의 경우 구현이 간단하지만 공유 링크마다 다른 권한을 부여하기는 힘들었다. 하지만 이미 공유 링크를 발급하고 누군가에게 공유한 순간부터 사용자의 의도와는 상관 없이 공유될 수 있기 때문에 레코드 상태를 업데이트 하는 방법이 좋다고 생각했다. 방향성을 정한 이후에는 구현은 간단했고, 인증의 경우 컨트롤러의 파라미터 값을 확인해야 해서 AOP를 사용하면 좋다고 생각했다. AOP를 활용하여 공유가 되었는지 확인하고 처리하도록 구현했다.

10주차 회고