zik's world

 
로봇드림 재개봉 소식을 듣고 어제 친구와 신촌 메가박스에 호다닥 다녀왔다
결론부터 말하자면 영화 끝에 감정적으로 너무 괴로울 정도로 슬펐고, 지금까지 영화에 대한 생각을 떨칠 수가 없다. 
그럼에도 영화를 보길 정말 잘했다는 생각이 든다.
 
흔히 연인이나 친구를 그만 잊는것을 놓아주는 것이라고 말한다. 추억을 정리하고, 자꾸 떠오르는 마음을 누르는 행위들.
예전에는 내가 사랑하는 모든 것들은 (불가피한 경우를 제외하고) 내가 살아가고 있는 지금에 놓고 싶어 했다. 한때 내가 좋아했던 것들이 어색해지는게 참을 수 없었다. 멀어져가는 친구와 연락을 주고 받기 위해 노력하고, 더이상 같이 살지 않는 부모님께 매일 전화를 했다. 본가에서 자주 가던 빵집에 주말마다 갔으며 항상 가던 곳을 산책 했다. 
그런데 나이를 먹을수록 어느 순간 부터 내가 아무리 모두 끌어안고 있으려고 해도 결국 나의 상황에 따라 많은 것들이 과거로 남는다는 걸 느꼈다. 인간관계도 마찬가지. 어릴때는 에너지가 넘쳐서 부지런히 방법을 찾았지만, 몇번 시도하고 실망한 끝에 빛나는 순간들은 몇번이고 재연할 수 없다는 걸 어렴풋이 알게되었다.
그러므로 놓아준다는건 사랑하는 것을 나의 지금으로 끌고 오려고 애쓰지 않고 그 자리에 남겨두는것. 그렇게 함으로써 끝을 알고있는 그 시간을 더욱 아껴주는 방법이 아닐까 생각해본다.
 
아는 맛이 더 씁쓸했다. 

근래 한 일 중 가장 잘한 일 top1을 꼽자면 스피치 컨설팅을 신청한 것이다.
예전에 직장 선배가 받아보고 좋았다는 이야기를 듣고, 문득 한 번 받아보고 싶어서 구글에 검색했더니 숨고가 나와서(숨고가 이런것도 해?) 홀린듯이 일단 견적을 받았다. 그 중 아나운서 키워드가 없는 강사님과 1회 상담을 신청했는데 그 주에 바로 수업 가능하다고 해서 또 홀린듯이 수업을 신청했다. 그리고 운 좋게도 너무 멋진 분을 만났다.
 
내용이 너무 좋아서 잊지 않으려고 정리해본다. 메시지가 나를 한번 거치면서 내 주관적인 생각들이 섞여있고 직설적이다.

말은 내면을 반영한다.

선생님은 전체적으로 내가 말을 할때 힘이 빠져 있다고 했다. 말의 텐션(억텐x)이 없고 대화에 돌입할 때자세(등받이에 뒤로 기댄다거나, 양 손을 힘없이 떨구고 있다거나, 어깨는 한껏 말려있는 = 나)를 근거로 설명해주었다.
그게 보인다고 자각하지 못했어서 충격이었다. 왜 그랬을까? 이 자리, 이 대화는 내가 신청한 것이고 나에게 꽤 중요했다. 그럼에도 나는 누군가와 대화하는 것에 대해 방어적이고 수동적인 자세로 임했던 것이다, 평소처럼! 이미 이런 태도가 습관이 되었다는 것, 그리고 나의 내면이 이미 그렇게 물들어 있다는 것을 새롭게 자각했다.
 
[당장 해볼 수 있는 솔루션]
대화에 돌입할 때 자세를 의식적으로 고쳐 앉자. 그리고 문장을 끝까지 말하되 끝까지 처음의 강세를 유지하기 위해 의식적으로 노력해보자. 
내가 하는 모든 말들이 나를 구성한다고 생각하고 의미를 부여해보자. 대화를 할 때 대충 얼버무리거나 시간을 때운다는 마음가짐 보단 대화 자체에 집중하고 충실해보자.
 
또 하나, 나는 늘 내 말이 공격적으로 들리지 않을까 늘 조마조마했다. 그런데 제 3자가 보기에는 웃었을때 인상의 차이가 클 뿐 내가 무표정으로 말 한다고 해서 내 의도를 곡해할 정도는 아니라고 했다. 이 말이 나에겐 의외였다. 그럼 나를 두렵게 했던 실체없는 걱정의 원인이 뭐였을까. 사실 내면에 많은 화와 짜증을 숨기려는 내 무의식이었을 수 있다. 나의 말 뜻은 내가 제일 잘 알고 있기 때문이다.
그리고 지난 2년간의 직장 생활에서, 혹여 사수의 기분을 지나치게 의식하고 심기를 거르지 않기 위해 했던 모든 말들이 떠올랐다. 그렇게 자연스럽게 체화된 노예근성(ㅋㅋ)..사실은 불만이 많지만 그것을 꽁꽁 싸매는 습관. 나는 배려있는 사람이 아니라 눈치보는 사람이었던 것이다.
 

더 잘 말하는 요령이 있다

난 무언가에 대한 내 의견을 말하는 것이 어색하다. 선생님과 내가 사람의 행동을 지적해야 하는 상황을 가정하고 대화 시뮬레이션을 했는데, 이떻게 말하는게 좋다는 설명을 분명 들었음에도 나도 모르게 평소 말하던 습관대로 말이 튀어나왔다.
'다른 분들도~..' 
나는 사실 어떤 것에 대한 주관이 분명한 편인데도 늘 이런식으로 논거를 하는데는 내 감정은 항상 비이성적인것, 중요하지 않은 것이라는 무의식이 영향을 주는 것 같다. 그리고 안해버릇해서 감정을 표현할 때 사용하는 어휘도 빈약하다. (실제로 두번째 시도에서 어떻게 느꼈다고 해야 하지? 라는 생각에 머리가 멈췄다.) 
 
[당장 해볼 수 있는 솔루션] 
상황- (나의)감정- 바람 (줄여서 상감바)를 가이드라인 삼아서 말해보자. 자꾸 연습해보자.
대화 상대의 특성에 대해 알고 있으면 내 말이 더 효과적으로 전달될 수 있다. (말 잘하는 사람들은 이것이 자동으로 느껴진다) 성격이 급한 사람은 본론먼저, 섬세한 사람은 상황 설명부터 말하는 식이다. 내가 하고 싶은 말은 그냥 상대방에게 던지는게 아니라 상대의 특성에 맞게 주고 돌려받는다는 태도로 대화에 임해야 할 것 같다. 
 
상담이 마무리 될 때 쯤 선생님이 하신 말씀이 있다. 사람은 모두가 다 다르고 현명한 사람이라면 특정 특성만을 가지고 사람을 판단하지 않는다고. 내 존재가 나의 약점이 될 수 없다고. 대도시의 사랑법이라는 소설의 주인공의 대사라고 했다.
내가 이 수업을 신청한 이유는 내 약점이 나중에 내 발목을 잡을까 두려웠기 때문이다. 가능한 빨리 교정하자. 내가 원하는 이상적인 모습이 되기 위해
그런데 고치고 싶었던 내 자신의 모습이라도 그것이 결고 나의 약점이 될 수 없다는 이야기에 울컥하기도 하고 마음이 한결 가벼워졌다.
나를 사랑하는 일은 파도 파도 새롭고 신경 쓸 것들이 많다. 그치만 이렇게 하나씩 발견해 나가는 것도 나에게 새로운 감각과 기쁨을 준다. 
 
이상 끝
 

회사에서 기본 지식 1도 없이 부하테스트 준비하는 업무를 맡았다. 아는 만큼 보일 것 같아서 서점 가서 책 사서 일회독했다.

제목을 보면 AWS 특화된 지식일 것 같지만 전혀 아니고 부하테스트를 왜 해야 하고 어떻게 해야 하는지 잘 설득&설명하는 글이다. 강추!!

정리 해두지 않으면 날아갈 것 같아서 써보는 요약 글!

부하 테스트를 하기 전에 고려할 것들

• 부하테스트의 목적
  • 어떤 종류의 부하를 기대하는가?
    • 각 시스템의 특성 (로그 많음, db 접근, 암호화연결있음 등등) 은 어떻게 되는가?, 확인해야 하는 지표들에는 어떤 것이 있을까?
  • 얼마만큼의 부하를 기대하는가?
    • rps 산정 방법, 피크 계수 계산
• 부하테스트 준비 시
  • 실제와 테스트와의 차이를 이해하고. 네트워크 적으로 가까운 곳에서 부하 주는게 좋다.
  • 부하를 충분히(5분 이상)줘서 신뢰성 있는 결과를 얻었는가?
  • 어디가 병목인가? - 시스템을 구성하는 요소들이 복잡할 수록 throughput 계산이 어렵다. 일단 구간별로 throughput 계산 후 정확한 목표치를 설정한다.
  • 바람직한 latency 그래프를 그리는가를 이해하고 있어야 한다.
  • 부하테스트는 최대한 개발이 덜 됐더라도 빠르게 해야 한다.
• 부하 테스트 단계
  1. 도구 환경
     1. 부하가 제대로 걸리는지 확인
  2. 웹 프레임워크
     1. 미들웨어 설정?
        
        1. sticky session..
     2. 웹 가속기?
     3. db
        1. 커넥션 풀링 하지 않음
        2. 쿼리 이상함
           1. 인덱스 락
        3. db설정 맞지 않음
        4. 인덱스가 걸리지 않음
        5. cpu, 메모리 리소스 부족
        6. 캐시 시스템 이용 방법이 잘못됨
           1. 커넥션 재사용 문제
  3. 참조계 성능
  4. 갱신계 성능
  5. 외부 서비스 연동 성능
     1. nginx upstream keep alive 설정 확인
  6. 시나리오
  7. 스케일 업/아웃 테스트
  8. 한계 성능 테스트

socket programming 수업 들을 때 공부 좀 열심히 해둘 걸..

지나고 하는 후회는 다 부질없다. 이제라도 부끄러움을 무릅쓰고 정리 해보려 한다.

소켓 인터페이스는 UNIX 계열 시스템에서 함수의 통신을 위해 설계한 함수의 집합이다. 소켓 통신을 이해하려면 먼저 이 소캣 인터페이스가 어떻게 이루어져 있는지 이해해야 한다.

1. 소켓 연결 과정

1-1. socket() : 소캣 생성 + 파일 디스크립터 할당

file desciptor

유닉스 계열 시스템에서 모든 것은 파일이다. 소켓, 디렉토리 등등 프로세스의 모든 것은 파일로 관리되고, 이들 프로세스의 open file 을 관리하는 user file descriptor table의 인덱스를 파일의 식별자로 사용한다. 이를 file descriptor 이라고 부르는데, 프로세스가 system call¹ 할 때 이 0이 아닌 정수값 (0 < .. < OPEN_MAX) 인덱스를 보고 구조체 파일 (struct file fd_array) 에 접근하여 파일을 찾을 수 있다.

대학 수업 때 user space 와 kernel space 가 다르다는 것을 배웠다. 그리고 커널은 인터럽트를 통해서 모든 하드웨어 접근이 가능하나 응용 프로그램에서 이를 사용하려면 커널에 접근해야 한다고 배웠다.
시스템 호출이란 프로그래밍 언어에서 지원하지 않는 기능에 대하여 운영 체제의 루틴을 호출하여 이용하는 것을 말한다. 

<기능>
1. 사용자 모드에 있는 응용 프로그램이 커널의 기능을 사용할 수 있도록 한다.
2. 시스템 호출을 하면 사용자 모드에서 커널 모드로 바뀐다.
3. 커널에서 시스템 호출을 처리하면 커널 모드에서 사용자 모드로 돌아가 작업을 계속한다.

※ 시스템 호출의 유형
프로세스 제어(process control)
파일 조작(file manipulation)
장치 관리(device management)
정보 유지(information maintenance)
통신(communication)

소켓도 마찬가지로 socket()을 호출하면 fd 가 할당된다. 그리고 이 fd는 소켓 구조체를 가리키고 있다. 구조체에는 포트 넘버, ip 등 정보가 포함된다. 

1-2. server socket -> bind() / listen() / accept()

서버 소켓의 행동은 다음과 같다.

1. 소켓fd와 소켓 구조체에 나온 정보를 연결하는 bind()
2. 서버 소켓으로서 연결을 기다리도록 (listening socket) 명시하는 listen()
3. listening socket의 fd와 대기열에 있던 클라이언트의 주소를 주고 연결을 수락하는 단계인 accept() 

#include <sys/socket.h>
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

#include <sys/socket.h>
int listen(int sockfd, int backlog); // backlog 는 대기열의 크기

1-3. client socket -> connect()

클라이언트 소캣은 connect()로 서버 소캣과의 연결을 요청한다.

#include <sys/socket.h>
int connect(int clientfd, const struct sockaddr *addr,
            socklen_t addrlen);

이제 위 코드를 이해할 수 있게 되었다. 야호!

TCP 소켓이 연결을 맺는 과정은 https://squeak-squeak.tistory.com/35 여기에 정리했다. 이 과정과 관련한 서버 튜닝값에 대해 정리한 글이다.

2. 커널 튜닝 시 fd 값의 의미

위의 내용을 바탕으로 생각해보면 서버가 처리할 수 있는 커넥션 수를 늘리고 싶다면,  동시에 연결 맺을 수 있는 max client 값만 튜닝할 것이 아니라 이 fd 수도 따라 늘려줘야 할 것 같다. 

• 시스템에 할당된 파일 디스크립터 수. (max 값은 65536 라고 한다 참고~) 늘리기
• 리눅스의 경우 각 사용자 별로 이 값을 설정할 수 있기 때문에 사용자 레벨에서의 df limit 늘려주기

또한, file descriptor 값의 한도를 늘려줌과 동시에 시스템이 사용할 수 있는 최대 워커 스레드 수도 늘려줘야 합당할 것이다.

(thread_max). 실제로 회사에서 부하테스트를 거쳐 튜닝했던 vm 값 중에 fd가 있었다. 사실 이 글은 거기서 출발했다.

정리해놓고 보니 학생 때 나는 운영체제, 리눅스 시스템 설계, 네트워크 수업 시간에 도대체 뭘 한 건지.. 내 인생에서 가장 헛살았던 4년이 대학 다니던 시절이 아니었나 싶다. 그래도 포기하지 않고 개발자 하고 있는 걸 보면 신기하기도 하고 대단하기도 하고...운이 좋았던 것 같다. 

참고한 글 

https://dev-ahn.tistory.com/96

https://velog.io/@whwogur/파일-디스크립터File-descriptor-소켓-프로그래밍

짠

네트워크 수업 시간에 제일 먼저 배우게 되는 TCP 연결 방식인 3-way handshake 이다. 

고백하자면 나는 대학을 날로 먹어서 학교에서 예전에 배운 지식들이 요즘에서야 업무를 하며 새롭게 다가온다. 아! 이걸 이래서 배웠구나 깨달음을 얻는 재미가 쏠쏠하다.

우리 그룹은 몇 천 TPS의 트래픽을 제일 앞에서 받아내는 통신 미들웨어를 담당하는지라, 만들고 나서 서버 튜닝이 중요한 것 같다. 사실 작년에 엄청나게 얻어맞고 트래픽을 견디기 위해 다들 바쁘게 지냈지만 나는 그 아방하게 멀찍이 지켜만 보고 있었다. 이제라도 그 때 어떤걸 하셨는지, 왜 했는지 티켓을 보면서 복기하면서 vm의 커널 튜닝한 부분을 보고 있었는데 SYN backlog 값이 뭔지 찾아보다가 오랜만에 아는 개념이 나왔다. 

통신을 맺을 때, 신뢰성을 보장하기 위해 여러 장치가 있다. 서버는 소캣을 생성하고 바인딩 한 뒤에 클라이언트와 다음과 같이 연결을 맺게 된다. 그러나 실전으로 가니 밀리초 단위에서 이 과정은 전혀 매끄럽지 않다.

TCP handshake 과정을 살펴보면 다음과 같다. 

이때 네트워크 성능을 향상시키기 위해 튜닝 할 수 있는 부분은 외부로부터 패킷을 받는 용도의 버퍼 수를 튜닝하는 것이다. NIC max_backlog 에서 확인할 수 있다.

그렇게 받은 syn 패킷을 서버 소캣은 가지고 있는 두개의 큐로 받게 되는데,

1. 일단 receive queue에 저장
2. 프로세스가 이를 꺼내서 처리(syn-ack을 보내기)
3. ACK 수신시까지 대기 (send queue) 시킨다.

순간적으로 인입되는 요청은 많은데 드랍(drop)되는 연결이 많다면 receive queue를 늘려줄 수 있다.

또한 send queue의 크기를 SYN backlog 값으로 늘려줄 수 있다. 이를 늘려주면 ACK 패킷을 기다릴 수 있는 대기열이 늘어나서 ack 수신이 느려졌을 때 손실되는 패킷을 줄일 수 있다.

클라이언트로부터 ACK 패킷을 받으면 accept queue 로 이동하게 되는데 프로세스에서 accept() 를 호출할 때 여기서 꺼낸다. accept queue의 크기가 바로 somaxconn 값이다.

+ 덧붙이기

지금가지 회사에서 실험(?)해본 결과 somaxconn, 커넥션 재사용과 관련된 커널 파라미터 튜닝이 성능을 개선하는데 가장 많은 영향을 줬다. 이를 통해 순간적으로 트래픽이 몰리면 서버가 연결을 맺을때 느려지는 것이 주요 원인임을 알게 되었고 이러한 커넥션 과정이 병목을 발생시키는 것이라고 생각했다. (테스트 할 서버가 통신 플랫폼 역할이라 연산량이 많지 않고 자원이 충분한 편이라..)

또 테스트 서버 보단 부하기의 커널 튜닝이 중요했는데 그 이유는 충분한 부하를 주는 것이 오히려 어려웠기 때문이다. 시간에 따른 latency를 보니 활성화된 워커스레드 수와 거의 비슷한 형상이었다(ㅠㅡㅠ). 부하를 거는게 이렇게 어려울 줄이야... jmeter 서버 6개로는 안된 것 같다.. 

-계속!-

참고한 글

https://recipes4dev.tistory.com/153

https://brunch.co.kr/@growthminder/23

0. 직장 선배 추천으로 가입한 독서 모임 첫 날

아 이제까지 내가 살았던 세계와 다른 곳에서 사는 사람들을 만난 기분이었다. 정말 지적인 유희를 즐기려면 저 정도까지의 교양이 있어야 하는구나, 나는 아직 교양의 기억도 모르고 있구나 생각이 들었다. 

인생에서 또 다른 길이 펼쳐진 느낌이었다. 내가 할 일은 길의 풍경과 향기를 즐기며 그 길을 달려가는 것. 설레이기도 하고 이상하기도 하다. 다만 그들이 진짜 똑똑한건지, 삶이 여유로워서 잠깐 멋지게 느껴진 것인지 아직은 혼란스럽다. 좀 더 오랜 시간을 보내보고 판단해도 늦지 않겠지.

1. PT 선생님이 가르쳐 준 것

피티 첫날에 선생님이 운동에 재능이 있다고 말했다. 26년 평생 운동을 좋아해 본 적 없는 나는 당연히 그냥 번지르르한 칭찬인 줄 알았는데, 그분이 정말 진지하게 말씀하시길 운동신경이 좋은 사람보다 그렇게 고통을 잘 참는 사람들이 나중에는 운동을 더 잘 한다고 한다. 한계가 와도 끝까지 하는 의지를 가진건 재능이라고. 운동하면서 그 사람이 어떤 삶을 사는지 알 수 있다고 했다.  나는 순간 머리를 한 대 얻어 맞은 듯, 그것이 삶을 관통하는 원리라는 생각이 들었다.

참고 하는 사람만이 결국 그 상태가 된다. 남들보다 효율이 좋아도 끝까지 하지 않으면.. 안된다. 

그 말이 너무 기억에 남아서 집에 와서 생각해보니, 정말 그게 내 재능인 것 같았다. 이렇다 특별한 것도, 탁월한 것도 아닌 나의 재능

난 미래를 상상하며 눈앞의 고통을 참아내는 걸 잘한다. 이제서야 나라는 사람의 장점을 하나 꼽을 수 있게 됐다. 조금 행복했다. 나 자신을 알아갈수록 나라는 사람의 속이 꽉 채워지는 기분이었다. 

2. 자기만의 장점이 있어야 안짤려

덕메 언니와 석촌에서 점심을 먹고 카페를 갔다. 오랜만에 봤는데 서로 자연스레 고민도 이야기하고 편했다.

회사 이야기를 하다보니 내 마음이 뾰족해져서, 회사 동료들에 대한 불평과 속앓이 했던 것을 털어놓게 됐다. 그런데 언니가 되게 당연했지만 내가 받아들이지 못하고 있었던 사실을 알려줬다. 모두 자기만의 장점이 있어야 직장에서 안짤리고(?) 살 수 있다고. 그건 꼭 일을 잘하는 능력을 의미하는게 아니고, 때론 내가 이해하지 못하는 행동을 할 수는 있지만 그건 그 사람 나름의 전략이기 때문에 (그리고 나와 다를 수 있기 때문에) 이해해야 한다는 말이었다. 대화를 하면서 지금 나의 상황을 멀리서 내려다본 입장을 듣는 느낌이었고, 그래서 마음이 누그러졌다.

맞아. 쟤네들도 만들고 싶은 거였다. 자신들이 이 자리를 차지하고 있어야 하는 이유를 말이다. 

그럼 나는 그런게 무엇이 있을까 생각했다. 나도 이렇다 할 확실한 이유는 아직 모르겠다. 이 지루하고 불쾌한 회사 생활에 어떤 목표가 생기는 기분이었다. 어느 집단에 있든, 내 존재의 이유를 확실히 만들어 놓는것이 좋을 것이다. 회사원으로서 개발자로서 그 답을 찾는 것이 내 커리어 하이의 출발점이 아닐까 싶다.