Haonly's Blog

기본서이긴 하지만 기본이 없는 나를 위한 정리! 

(진짜 진짜 뭐라도 공부 좀 하자 싶어서 ^^)

인터넷은 잘 동작하고 있어서 대부분의 사람들은 인공의 무언가라기보다 태평양 같은 천연자원으로 생각한다. 이런 규모의 기술이 이토록 오류가 없었던 적은 언제가 마지막일까?
- 앨런 케이, Dr. Dobbs 저널 인터뷰에서(2012)

-> 내가 든 생각은 누군가의 영혼이 갈려서..? ㅋㅋㅋ

데이터 중심 애플리케이션의 경우 CPU 성능은 애플리케이션을 제한하는 요소가 아니며, 더 큰 문제는 보통 데이터의 양, 데이터의 복잡도, 데이터의 변화속도다.

데이터 중심 애플리케이션은 

• 데이터베이스
• 캐시(읽기 속도 향상)
• 검색 색인
• 스트림 처리
• 일괄 처리

를 필요로 한다.

그러나, 애플리케이션마다 요구사항이 다르기 때문에 애플리케이션을 만들 때 어떤 도구와 어떤 접근 방식이 수행 중인 작업에 가장 적합한지 생각해야 한다.

-> 신뢰성 / 확장성 / 유지보수성

데이터 시스템에 대한 생각

데이터 저장과 처리를 위한 여러 새로운 도구들이 모여 만드는 데이터 시스템에 대한 이해가 필요!

데이터 시스템에서의 좋은 API는 어떤 모습일까?

1. 신뢰성

하드웨어나 소프트웨어 결함, 심지어 휴먼에러 같은 역경에 직면하더라도 시스템은 지속적으로 올바르게 동작해야 한다.

-> 올바르게, 무언가 잘못되더라도 지속적으로 올바르게 동작함.

잘못될 수 있는 일: 결함

결함을 예측하고 대처할 수 있는 시스템: 내결함성, 탄력성(resilient)

사실 모든 결함을 막을 수 없기에(블랙홀이 지구와 지구상의 모든 서버를 삼켜버려도 웹 호스팅이 가능한 내결함성을 지닐 순 없기에...ㅋㅋ),

특정 유형의 결함 내성에 대해서만 이야기 하는 것이 타당하다.

결함과 장애는 다름

결함: 사양에서 벗어난 시스템의 한 구성 요소

장애: 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우.

내결함성 시스템을 훈련시킴 -> 넷플릭스 카오스 몽키 예시

오류와 결함의 종류:

하드웨어 결함 / 소프트웨어 오류(신속한 해결책이 없음) / 인적 오류(롤백 필요, 테스트 추가, 모니터링 대책, 조기 교육(ㅜㅜ))

신뢰성은 단순한 것이 아니다. 일상적인 애플리케이션 조차도 안정적으로 작동해야 한다.

"중요하지 않은" 애플리케이션도 사용자에 대한 책임이 있어야 한다. 사진 애플리케이션에서 사진이 모두 사라진다면 어떻게 될 것인가? 백업을 복원하는 방법을 알고 있을까?

2. 확장성

시스템의 데이터 양, 트래픽 양, 복잡도가 증가하면서 이를 처리할 수 있는 적절한 방법이 있어야 한다.

시스템이 현재 안정적으로 동작한다고 해서 미래에도 안정적으로 동작한다는 보장은 없다. 

시스템은 전에 처리했던 양보다 더 많은 데이터를 처리하고 있을지도 모른다.

확장성은 증가한 부하에 대처하는 시스템 능력을 말하는데, 이때 고려한 질문은,

"시스템이 특정 방식으로 커지면 이에 대처하기 위한 선택은 무엇인가?", "추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까?"라는 구체적인 용어이다.

부하 기술하기

부하 매개변수: 웹 서버의 초당 요청 수, 데이터베이스의 읽기 대 쓰기 비율, 활성 사용자 수, 등

트위터 예시: 

사용자는 팔로워에게 새로운 메시지를 게시할 수 있다(평균 초당 4.6k 요청, 피크일 때 초당 12k 요청 이상)
사용자는 팔로우한 사람이 작성한 트윗을 볼 수 있다(초당 300k 요청)

성능 기술하기

1. 부하 매개변수를 증가시키고 시스템 자원은 변경하지 않고 유지하면 시스템 성능은 어떻게 영향을 받을까?

2. 부하 매개변수를 증가시켰을 때 성능이 변하지 않고 유지되길 원한다면 자원을 얼마나 많이 늘려야 할까?

시스템 성능 면에서 일괄 처리 시스템은 처리량, 온라인 시스템은 응답시간이 중요한 성능 지표이다.

평균보다 여러가지 상황을 고려한 백분위 응답시간을 사용하는 것이 좋다.

사용자가 보통 얼마나 오랫동안 기다려야 하는지 알고 싶다면 중앙값이 좋은 지표다.(p50)

응답 시간 지연에 따라 매출에 영향을 주기도 하는 시스템이 있다는 것을 기억하자!

시스템의 확장성을 테스트하려고 인위적으로 부하를 생성하는 경우 부하 생성 클라이언트는 응답 시간과 독립적으로 요청을 지속적으로 보내야 한다. 만약 클라이언트가 다음 요청을 보내기 전에 이전 요청이 완료되길 기다리면 테스트에서 인위적으로 대기 시간을 실제보다 더 짧게 만들어 평가를 왜곡한다.

부하 대응 접근 방식

성능 측정을 위한 부하와 지표 매개변수를 확인했다.

부하 매개변수가 어느 정도 증가하더라도 좋은 성능을 유지하려면 어떻게 해야 할까?

흔히 아는 내용: 스케일 업 / 스케일 아웃

적절한 사양의 장비 몇 대가 다량의 낮은 사양 가상 장비보다 훨씬 간단하고 저렴함

일부 시스템은 탄력적이다. 컴퓨팅 자원을 자동으로 추가할 수 있다는 점.

그렇지 않은 시스템은 수동으로 확장해야 한다.(수동으로 확장하는 시스템이 더 간단하고 운영상 예상치 못한 일이 더 적다. -> 이해 안됨!)

다수의 장비에 stateless 서비스를 배포하는 일은 상당히 간단하지만,

단일 노드에 stateful 데이터 시스템을 분산 설치하는 일은 복잡하다.

그래서 대용량 데이터와 트래픽을 다루지 않는 사용 사례에도 분산 데이터 시스템이 향후 기본 아키텍처로 자리 잡을 가능성이 있다.

특정 애플리케이션에 적합한 확장성을 갖춘 아키텍처는 주요 동작이 무엇이고 잘하지 않는 동작이 무엇인지에 대한 가정을 바탕으로 구축하고 이 가정은 곧 부하 매개변수가 된다.

3. 유지보수성

시간이 지남에 따라 여러 다양한 사람들이 시스템 상에서 작업할 것이기 때문에 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있게 해야 한다.

초기 개발 그 이후 지속해서 이어지는 유지보수에 소프트웨어 비용의 대부분이 들어간다.

레거시 시스템 유지보수 작업은 모두가 싫어하는 일이다(나도..)

그래서 이러한 유지보수 중 고통을 최소화하고 레거시 소프트웨어를 직접 만들지 않게끔 애초에 설계를 잘해야 한다. 

이러한 원칙으로는

• 운용성: 운영팀이 시스템을 원활하게 운영할 수 있게 쉽게 만들어라.
• 단순성: 시스템에서 복잡도를 최대한 제거해 새로운 엔지니어가 시스템을 이해하기 쉽게 만들어라.
• 발전성: 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 하라. 그래야 요구사항 변경 같은 예기치 않은 사용 사례를 적용하기가 쉽다. 이 속성은 유연성/수정가능성/적응성으로 알려져 있다.

운용성 책임 작업 중 기억에 남는 작업:

• 시스템 장애, 성능 저하 등의 문제의 원인을 추적
• 예측 가능한 운영과 안정적인 서비스 환경을 유지하기 위한 절차 정의
• 개인 인사 이동에도 시스템에 대한 조직의 지식을 보존함

단순성에서 기억에 남는 내용:

• 변수 명명, 모듈 간 강한 커플링, 임시방편으로 문제를 해결한 사례, 복잡한 의존성 등등이 복잡도의 다양한 증상이다.

복잡도 때문에 시스템 유지보수가 어려울 때 예산과 일정이 초과되며 버그가 생길 위험이 더 크다.

시스템을 단순하게 ㅁ나든느 일이 반드시 기능을 줄인다는 의미는 아니다. 우발적 복잡도를 줄인다는 뜻일 수 있다.

추상화하면 우발적 복잡도를 제거할 수 있다.

발전성: 변화를 쉽게 만들기

시스템의 요구사항이 영원히 바뀌지 않을 가능성은 매우 적다.

(최근 진행한 업무에서 짠 스크립트는 버전 26까지 갔던 거 보면 사실인 듯하다 ㅋㅋ)

조직 프로세스 측면에서 애자일 작업 패턴은 변화에 적응하기 위한 프레임워크를 제공한다. 

애자일 커뮤니티에서는 자주 변화하는 환경에서 소프트웨어를 개발할 때 도움이 되는 기술 도구와 패턴을 개발하고 있다.

정리

데이터 중심 애플리케이션을 생각하는 기본적인 방법 몇 가지를 알아봤다.

애플리케이션이 유용하려면 충족되어야 할 요구사항(비기능적 요구사항, 기능적 요구사항) 중 신뢰성/유지보수성/확장성을 살펴봤다.

신뢰성: 결함이 발생해도 시스템이 올바르게 동작하게 만드는 것.

확장성: 부하가 증가해도 좋은 성능을 유지하기 위한 전략.

유지보수성: 본질은 시스템에서 작업한느 엔지니어와 운영팀의 삶을 개선. 좋은 추상화를 통한 복잡도를 줄이기.

안타깝게도 애플리케이션을 신뢰할 수 있고, 확장 가능하며 유지보수하기 쉽게 만들어주는 간단한 해결책은 없다. 

하지만 여러 애플리케이션에서 계속 재현되는 특정 패턴과 기술이 있다.

사용자를 위한 웹 API 디자인하기

주제

• 어떤 관점으로 API를 디자인해야 하는가?
• 사용자 인터페이스를 디자인하듯 API 디자인하는 법
• API의 실제 목표를 정확하게 결정하는 법

API를 사용하는 사람들이 원하는 것이 무엇인지의 관점.

소셜 네트워크의 API는 사진 공유, 친구 추가, 친구 리스트 표시 등이 API의 목표이며 이러한 목표들이 효과적인 API를 디자인하는데 필요한 기능적 청사진 역할을 함

그렇기 때문에 목표 식별이 중요하며 서로 연관된 포괄적인 요구사항들을 정리할 수 있도록 컨슈머의 관점에 중점을 두어야 한다.

사용자가 얻을 결과에만 집중하는 것이 중요하다. 즉, 컨슈머 관점에서 사용하기 쉽도록 개발해야 한다.

API의 목표 식별 과정

API를 디자인할 때 고려해야 하는 점

• 누가 API를 사용하는가?
• 무엇을 할 수 있는가?
• 어떻게 하는가?
• 하기 위해서 무엇이 필요한가?
• 끝나면 무엇을 반환하는가?

-> 사용자들의 요구사항을 수집하고, 그 요구사항을 깊이 파고 들어가 정확히 이해하며, 마침내 그 목표를 조금이라도 효율적이며 정확하게 달성해야 한다.

이때 누락된 목표나 사용자는 없는지 잘 확인해야 한다.

API 목표 캔버스를 사용하여 "누가", "무엇을", "어떻게", "입력", "출력" 목표"를 설정.

누가 사용자인지와 흐름들로부터 새로운 목표를 찾아내는 과정들이 중요하다.

API 디자인에서 피해야 할 프로바이더 관점

API는 근본적으로는 컨슈머와 프로바이더라는 두 개의 다른 소프트웨어 간의 데이터를 교환하는 방법을 의미한다.

프로바이더 관점에서 데이터의 체계와 이름을 그대로 API 목표와 데이터에 매핑하는 실수를 하기도 하는데, 이는 이해하기도 어렵고 사용하기도 어렵게 만든다.

데이터 모델과 조작에 관한 내용은 노출되면 안 된다.

내부 비즈니스 로직의 노출은 API의 컨슈머가 이해하기도 어렵게 하며 프로바이더에게도 위험하다.

숨겨야 하는 인적 조직을 API 디자인에 매핑시키지 않아야 한다.

요약

API 목표 목록은 포괄적이고 컨슈머 지향적이어야 하며 프로바이더 관점이 드어가서는 안된다.

카프카 아키텍처 생각해 보다가 갑자기 궁금한 점이 생겼다.

카프카는 같은 파티션 안에서 순서를 보장해주며 여러 파티션을 분산 처리할 수 있는 장점을 가지고 있기 때문에 사용한다.

근데 "같은 파티션 안에서 순서를 보장해준다면 같은 토픽의 다른 파티션 간의 순서는?" 이라는 의문이 들었다.

마침 우아한형제들에서 진행하는 우아한테크세미나에서 이 의문에 대해 의외로 간단한 답변으로 답을 듣게 되었다.

다른 파티션 간의 순서는 보장 안한다.

물론 아주 복잡하게 순서가 뒤바뀌어 들어와 처리 순서가 많이 뒤바뀌진 않기도 하겠지만, 다른 파티션 간의 순서까지 보장하려면 FIFO 쓰지 왜 카프카 쓰겠느냐는 것이다. 

음식 주문의 예시로 생각해보면 1분에 1000개 주문이 들어온다고 할 때, 그 안에서의 순서는 크게 서비스에 영향을 미치지 않는다는 것 같다.

파티션이 4개라면 그 안에서 250개의 주문들은 각 파티션 안에서 순서가 지켜질 것이다.

카프카를 나름 잘 안다고 생각하고 있는데, 공부하면 할수록 공부할 것들이 많다...!

카프카 스트림즈라는 카프카 내의 새로운 개념까지 최근에 알아버려 공부할 게 또 생겼다.

재미있기는 한데 나는 왜이리 모르는 게 많은 건지ㅠㅠ ㅋㅋㅋ 시간을 쪼개어 공부를 열심히 해야겠다! 

와! 2021년 정리하고 2022년 맞이하는 글도 못쓴 체 결국 근 두 달 만에 또 주간회고를 쓰다니!

나 자신 정말 게을러!

2021년 정리하고 2022년 맞이하는 글은 일요일 오전에 꼭 쓸 것임..(많이 놀고 운동도 했으니 2022년에는 더 열심히 살아보자 뭐 이런..)

이번 주는 별게 없었다. 월요일에 시승차 반납할 겸 출근하고, 쭉 재택 하면서 나름 일 진도도 빼고 한의원도 다녀오고

운동도 하고 소화가 잘 되지 않아 먹는 것 조금 조심하며 지냈더니 벌써 금요일이다.

크게 바쁘거나 대단한 일을 하고 있지는 않은데 항상 바쁜 것 같다.

영어모임 하거나 미팅 한두개 하고 운동 다녀오면 하루가 끝난다. 그래서 운동하는 시간도 줄여봤는데 여전히 좀 바쁜 것 같다.

토스트마스터즈

특히 이번주에는 토마 연설과 디비전 모임이 하루에 몰려 있었고 그 외에 클럽 오피서 모임도 있었다. 

가끔 이렇게 몰려있거나 내가 토마에 시간을 좀 많이 쓴다는 생각이 들 때 이렇게 까지 해야 하나 싶기도 하다.

운영진 역할 까지는 괜찮고, 리더 역할은 이제 그만하고 싶다는 생각이 막막 든다... ㅠㅠ 아직은 현생이 더 중요한 시기라는 생각이 크게 들기 때문인 듯하다.

그래도 내가 준비한 이벤트(1월의 운영진 교육, 디비전 모임 등)를 잘 마치면 참 뿌듯하다. 부족한 점도 깨닫게 되고 더 잘하고 싶은 욕심도 생긴다. 

이번 연설에서는 내 리더십에 관한 이야기를 했다. 시간과 체력을 쏟다가 '내가 왜 이걸 하나, 현생에서 여기서 배운 리더십을 써먹을 일이 있긴 하나'라는 생각이 든다고 솔직히 이야기하며 앞으로 그럼에도 토마에 계속 있는 이유와 리더 경험을 공유하며 부족한 점도 고민하고 공유하는 시간을 가졌다.

다음 임기에는 그래도 클럽에 집중하는 리더이고 싶다! 어떻게 될지 아직 아무도 모르고 갑자기 변덕으로 또 디스트릭트 리더 역할을 맡게 될 수도 있겠지🤣

클라이밍하러 대전까지 가는 사람? 저요~

여전히 클라이밍은 재밌다.

이번에는 회사 시승차를 빌린 김에 대전으로 클라이밍을 하러 갔다! 운동도 재밌게 하고 GV80도 타봐서 정말 재미있었다!

대전 맛집들도 다녀와서 나름 알찬 여행이었다.

(그렇지만.. 다음에는 안 피곤 하게 다녀오고 싶다.. ㅎㅎ)

요즘 현생에 조금 더 집중하려고 운동하는 시간은 조금 줄이고 있다. 평일에 5시 땡 되자마자 퇴근하고 운동하러 갔다가 9시에 돌아오는 삶에서, 5시 퇴근하고 할 일 조금 하다가 7시쯤 운동하는 그런 패턴이랄까.. ㅎㅎ

클라이밍을 하다보면 발에 꽉 끼는 암벽화를 신게 되는데 어느 순간부터 발 뒤꿈치 뼈가 튀어나오기 시작했다.

근데 암장에 비슷게 발 뒤꿈치가 튀어나오는 사람들이 많다. 친한 언니가 보더니 문제 있을 수 있다며 알아봐 준 결과 헤글룬드? 헤이글런드? 기형이라고 한다. 크게 이상은 없을 것 같지만 나중에 뼈나 근육에 문제가 있을 수 있다고 병원 가는 것을 추천해 주었다..내 꼭 갈게,, 병원,, 그치만 클라이밍은 포기하지 않을 거야..https://www.vondt.net/ko/hvor-har-du-vondt/vondt-i-haelen-haelsmerter/haglunds-deformitet/

헤이글런드 설명 자료!

인생 스터디

인생 스터디라고 하면 좀 거창하지만 '퇴근 후의 삶을 낭비하지 말아 보자!'라는 목표로 마음 맞는 동기들과 스터디를 하고 있다.

그냥 각자 일주일 동안 자기 계발 및 커리어 개발을 위해 한 일들? 정리한 생각들을 공유하며 서로 동기부여 주고받는 형태이다. 이제 3주 차이지만 크게 동기부여가 되어 미뤄뒀던 커리어 개발을 하고 있다.

내가 이 전 직장에서 했던 일, 지금 직장에서 하는 일 정리와 내가 원하는 커리어 방향 등을 정리하고 기술 정리도 하고 있다. 업무를 진행하며 배우는 것들, 내가 지금 하고 있는 일들 등을 정리하면서 나름 생각 정리도 되고 공부할 것들도 정리가 되니 말 그대로 퇴근 후 낭비하는 시간 자체가 줄어들면서 바쁘지만 열심히 살게 되는 것 같다.

이런 동기들이 있어 정말 행복하고 모두 다 원하는 방향으로 잘 되었으면 좋겠다.

성격

사람 성격은 가지가지이다.

나랑 안 맞는 사람도 있고 맞는 사람도 있다.

나랑 안맞는 사람을 만나게 되면 나에게서 문제를 찾는다. 근데 진짜로 내가 문제인 것 같다는 생각이 들어서이다.

최근 이런 생각들이 더 자주 든다. 물론 지금 뭔가 갈등이 있는 사람이 있는 것은 아니지만(나가지를 않으니...) 내가 좀 예민하다는 것은 내가 알기 때문에, 이 전에 있던 갈등이나 불편했던 상황들을 생각하면 내가 문제였던 것 같다는 생각이 든다..

이 전에는 아니라고, 저 사람이 이상한 거라고 생각했는데 요즘 문득 내가 진짜 좀 모난 걸까 하는 생각이 자꾸 괴롭힌다ㅠㅠ

위로상 아니라는 말이 듣고 싶은 것이 아니라 정말 내가 예민하고 모난 것 같아서 조금 고쳐보려고 한다.

좀 더 유하고 착한 사람이고 싶다.