일주일간 나의 흥미를 끈 인사이트는??

📌목록

• 캐시 라인,( C++ STL std::list 보다 std:vector를 써야하는이유)
  https://cho001.tistory.com/136

• 추천팀의 DDD 도입기
  https://tech.kakao.com/2022/12/12/ddd-of-recommender-team/

• 섬세한 ISFP의 코드 가독성 개선 경험
  https://kakaoentertainment-tech.tistory.com/96?ref=codenary

• Technical Writing : 글로 하는 의사소통
  https://kakaoentertainment-tech.tistory.com/97

• ㄷㄷㄷ:Domain Driven Design과 적용 사례 공유
  https://kakaoentertainment-tech.tistory.com/95

• L4 웹 방화벽에 의한 성능 저하 사례
  https://brocess.tistory.com/category/Programming/Network

📌감상

1. 캐시 라인,( C++ STL std::list 보다 std:vector를 써야하는이유)

https://cho001.tistory.com/136
캐시에 대한 이야기 뿐만 아니라 c++로 알고리즘 공부를 하다보니 이 글에 관심이 많이 갔다.

1) 캐시
이 글 덕분에 내 컴퓨터의 캐시를 한번 확인해보는 계기가 되었다.

캐시라인이 멀티프로세서 환경에서 성능을 향상하기 위해 도입되었지만 멀티 프로세서 환경에서는 문제가 될 수 있는 여지가 있다고 한다. 다수의 CPU가 동일한 캐시라인을 보유하고 있는 상황에서 그 중 하나의 CPU가 해당 캐시라인을 수정하면, 다른 CPU가 들고 있는 캐시라인을 무효화시켜 메모리를 다시 읽어오는 방식으로 동기화 과정이 이루어지기 때문에 성능저하 현상이 발생한다고 한다.

2) vector
-- 연속적인 메모리 공간에 저장한다. -> 지역성이 좋아 캐시효율이 좋다.
-- 원시 타입이나 간단한 구조체에 대해서는 vector가 list에 비해 성능이 좋으나,원소의 크기가 커지게 되면 vector의 캐시 효율이 떨어지므로 list가 성능이 더 좋다.
-- deque, list에 비해 개별 원소에 대한 접근 속도와 컨테이너의 끝에서 삽입/제거하는 속도가 가장 빠르다. 다만 컨테이너 끝이 아닐경우 성능은 가장 떨어지게 된다.
-- 동적으로 확장/축소가 가능한 dynamic array로 구현되어 있다. 단 확장시 전체 메모리만큼 재할당을 하여 비용이 꽤 크다.

3) deque
-- vector와 다르게 원소를 컨테이너 끝뿐 아니라, 앞에서도 삽입/제거 하는 것이 빠르다. 따라서 STL의 스택과 큐는 deque로 기본 구현되어있다.
-- deque느 내부 capacity가 고갈되면 vector와 다르게 chunk 단위로 확장하여 확장 비용이 작다.
-- 컨테이너 처음부터 끝까지 연속 메모리 공간이 아니므로 vector에서 가능했던 원소들간 포인터 연산이 불가능하다.

4) list
-- doubly linked list로 구현되어 있다.
-- 어느 위치에서도 삽입/제거가 빠르고, 원소들의 컨테이너 내 순서 이동이 빠르다. (상수복잡도)
-- 특정 원소로 접근이 불가능하다.
-- 원소들간 상호 연결 정보를 위해 추가적인 메모리가 사용된다.

2. 추천팀의 DDD 도입기

https://tech.kakao.com/2022/12/12/ddd-of-recommender-team/
현재 DDD를 공부하고 있는 상황이기 때문에 관심이 간 글이었다. 여기서 아니 많은 경험이 있는 개발자는 아니지만 언급한 DDD는 툴이 아니고 설계 철학 같다는 말에 DDD를 하고 있는 입장에서 공감이 많이 갔다.

3. 섬세한 ISFP의 코드 가독성 개선 경험

https://kakaoentertainment-tech.tistory.com/96?ref=codenary
개발자는 혼자 일하는 직업이 아니기 때문에 내 코드를 보는 다른 개발자들을 위해 가독성있는 코드를 만들어야 한다고 생각하고 추구하고 있다. 이 글을 통해, 내가 가독성에 있어서 잘못된 습관을 가지고 있지 않은지 체크할 수 있는 글이었다. 이 글에서는 항상 정확한 표현을 찾기보다는 문맥에 맞게 가독성을 고민하는 것이 효과적이라 언급하고 있고, 그 외에도 더 잘보이는 형태를 고려해본 사례에 대해 이야기 하고 있다.

4. Technical Writing : 글로 하는 의사소통

https://kakaoentertainment-tech.tistory.com/97
나는 앞으로도 계속 블로그를 할 계획이다. 즉, Technical Writing을 계속 하게 될 것인데, 이에 대한 도움을 얻고자 이 글을 읽게 되었다.

5. ㄷㄷㄷ:Domain Driven Design과 적용 사례 공유

https://kakaoentertainment-tech.tistory.com/95
기존의 legacy코드를 그대로 유지하면서 신규 MSA 서버들이 동시에 동작할 수 있도록 점진적인 교체를 위해 시도한 방법으로 DDD를 선택했다는 내용을 다루었다. 전환하면서 DDD의 특징으로 각 도메인에 대한 높은 이해도가 필요하기 때문에 신규 도메인 또는 기존 도메인의 수정이 필요할 때는 설계에 대한 검토를 충분히 해야 구현을 할 수 있다는 점에 단점을 뽑으면서도, 기존 데이터들을 도메인으로 한번 정제했기 때문에, 도메인 간 관계가 복잡해도 정리가 가능하고, 도메인 분리에 따른 유지보수의 편의성이 높다는 점과 비지니스 로직에 집중하여 코드 가독성이 높다는 점을 장점으로 뽑고 있었다. 확실히 나도 프로젝트를 하다보면, 도메인끼리 분리되어 의존성을 낮추는 설계이다보니, 새로운 기능이 추가되어도 큰 부담없이 짤 수 있다는 느낌을 받았었어서 이러한 장점이 더 와닿았다.

6. L4 웹 방화벽에 의한 성능 저하 사례

https://brocess.tistory.com/category/Programming/Network
최근에 TCP연결 중 연결이 끊겼을 경우 취하는 타이머 4가지에 대해 공부를 하다보니, 해당 글이 읽혀져 신나는 마음에 글을 가져왔다. 이 글에 나오지는 않았지만 TCP 연결 중 연결이 끊겼을 경우 취하는 타이머에 대해 짧게 말하자면
1) 재전송타이머 - 정해진 시간 내 수신 확인응답이 안되면 재전송
2) 영속타이머 - 주기적으로 송식하는 widow probe 패킷의 송신 주기를 처리하는 타이머
3) 시간 대기 타이머 - 이전 연결 종료 전의 어떤 패킷이 늦게, 중복 지역 도착하는 것을 방지
4) keepalive타이머(연결 유지 타이머) - 이미 설정된 연결이 오랫동안 휴지 상태에 있지 않도록 하기 위함

이 글에서는 keepalive 타이머에 대해 이야기 하고 있는 것 같다. 이 글의 오류에 대한 원인은 keepalive 5초가 지나면 TCP 세션을 끊고 있는데, FIN 패킷이 클라이언트에 전달되지 않아 아직 살아있다고 생각하고, TCP 세션으로 HTTP 요청을 전송함으로써 이상을 감지하기 까지 오래 걸려서 화면 지연이 발생했다고 한다. 해당 FIN 패킷은 웹 방화벽에서 삼키었다고 한다. 웹방화벽에 의한 성능 저하 사례 중 하나로 하니 재미있게 본 글이다.