전체 글

목차 시작하며 CPU 무어의 법칙 프로세스와 스레드: 정의 프로세스와 스레드, 멀티프로세스와 멀티스레드 마치며 참고 시작하며 안녕 히로, 오늘 내가 프로세스와 멀티프로세스, 스레드와 멀티스레드, 컨텍스트 스위칭, 무어의 법칙, 암달의 법칙 등의 내용들을 설명하려고 함. 각 개념들을 정말 자세하고 깊게 설명해놓 블로그들은 많지만 너무 자세해서 연관짓기가 좀 복잡할 수도 있거든. 그래서 내가 이 개념들을 한데 묶어서 설명해줄게. 나중에 원하면 이 개념들을 더 디테일하게 찾아보시길. CPU CPU부터 시작하자. CPU가 뭘까? CPU를 컴퓨터의 대뇌라고도 하거든? 그리고 개발자가 만드는 프로그램, 시스템들은 모두 컴퓨터에서 동작하니까 이 CPU 를 알아야되는거지. CPU (Central Processing U..

Contents 이번 이야기 Definitions 테스트 Overview 1,000 RPS 테스트 : 설명 1,000 RPS 테스트 : 결과 2,000 RPS 테스트 : 설명 2,000 RPS 테스트 : 결과 점검의 시간 : What Application Load Balancer is doing for us 로드밸런싱 Health Check Scaling Service Discovery & Service Registration L7(Layer 7) Load Balancing 점검의 시간 : Scalability (확장성) 보완하기 10,000 RPS 테스트 : 설명 Computing 서비스 구조 Monitoring 서비스 구조 10,000 RPS 테스트 : 결과 1 10,000 RPS 테스트 : 결과 2..

개발하면서 이정도는 알고가볼까? 기초 지식을 학습하며 기록용으로 사용하고 있어서 구조가 난잡할 수도 있습니다. 네트워크 www.naver.com을 입력하면 무슨일이 발생하는가? 1. https://www.naver.com 해당 도메인네임의 IP 주소를 찾는다 1. 브라우저에 www.naver.com 으로 IP 주소 저장되어있는지 확인한다. 2. 없으면 OS 에서 확인한다. 3. 없으면 DNS로 질의한다. 4. 이렇게 IP 주소를 찾아서 2. 프로토콜, IP 주소, 포트 번호(기본 80) 으로 분해해서 HttpRequest를 만든다. 3. 직렬화하고 4. HTTP > TCP > IP > 거쳐 그 하위 레이어 까지 본인들이 필요한 정보를 붙이고 5. 전송한다. 6. LAN 어댑터를 거쳐서 허브/스위치를 통해..

가장 인상깊은 부분 "눈가리고 무작정 두발로 뛰어넘기" 는 상당히 좋은 효과를 거둔다. 만약 그것이 전혀 효과가 없다면 사람들은 결국 그 방식을 택하지 않을 테니 말이다. 이것이 가능한 이유는 문제 해결 자체가 흥미있는 일이기 때문이다. 만약 우리가 정말로 심각한 문제를 해결해야 할 때는 아주 별난 사람들만이 그일에 동참하려고 할 것이다. p. 154 "대체 뭐가 문제야" by 제럴드 M. 와인버그 나에게 가장 와닿았던 부분이다. 경험상 해결방법이 전혀 감이 안올때 작은 스케일로 (크면 줄여서) 시도하기 정말 좋은 방법이기 때문이다. 문제에 대한 인사이트를 얻을 수도 있으며 운이 좋으면 문제가 해결되기도 한다. 하지만 정말로 1도 생각않고 실행하지는 말자. 느낀점 빠른 프로덕트 출시사이클, Agile, ..

DDD 학습 계기 DDD가 뭐지? 도메인-드리븐 디자인이 뭐지? 왜 도메인-드리븐한 디자인이 필요하지? 개념인가? 실제 구현가능한 부분인가? 내 프로젝트는 domain-driven 하게 design 되었을까? 어떻게 프로젝트를 더 domain-driven 하게 만들 수 있을까? 어떻게하면 합리적인 도메인 모델링을 진행할 수 있을까? 내가 생각했던 DDD는? 최근 분산시스템, 마이크로서비스 아키텍처와 관련된 책을 읽고, 프로젝트를 진행하다보니 Domain-Driven Design, Bounded Context, Aggregate 와 같은 키워드들을 여러번 마주하게 되었다. 그래서 찾아본 DDD는 이렇다. Domain-Driven Design은 마이크로서비스 형식의 아키텍처에만 적용되는 개념이 아니다. DD..

독후감 : 책을 읽고 난 뒤의 느낌. 또는, 그것을 적은 글 (명사) 시작하기 전... 책 선물을 주신 Dina [F-Lab] 님 감사합니다! 정말로 시작하기 전... 프로그래밍 관점에서 장애는 예방하는 것이 아니라 관리하는 것 이라고들 합니다. 장애는 불가피하기 때문이며 관리가 예방의 사이드 이펙트보다 덜 치명적이기 때문입니다. 최근 읽은 애자일 관련 서적 "함께 자라기"에 의하면 미국 어딘가에서 산불을 예방하는 것이 아닌 관리하는 관점에서 피해를 최소화시켰다고도 합니다. 시스템의 장애를 부정적인 요소가 아닌 일종의 현상으로 바라보면 감정과도 비교할 수 있겠습니다. 사람이 감정을 느끼는 것은 인간의 호흡만큼이나 자연스러운 현상이기 때문이지요. 그런 감정을 우리는 우리가 감정적이라는 개념을 부정적으로 여..

분산 시스템, 마이크로서비스 아키텍처와 같은 개념들을 이야기하다 보면 빠지지 않는 것이 비동기 통신과 메시지 큐입니다. 대부분 메시지큐 기반 비동기 통신을 통해서 서비스간의 결합도를 낮춘다고 합니다. 우아한 중계서비스에서도 메시지큐를 활용한 비동기 통신을 고려하며 찾아본 내용들을 적어두었습니다. Table of Contents 메시지 큐를 통해 해결하려는 문제는? 디커플링(decopuling), 서비스 간의 결합도 감소 관심사의 분리를 통한 처리시간 최적화 트래픽 완충제 역할 메시지 큐 활용시 해결해야 하는 문제는? 시스템 가용성 감소 Availability 시스템 복잡도 증가 Complexity 데이터 일관성 문제 Consistency Cheography-based Saga Orchestration-b..

‘함께’는 협력을 말하고, ‘자라기’는 학습을 말한다. Contents 시작하며 Chapter. 구글이 밝히는 탁월한 팀의 비밀 Chapter. 당신이 제자리걸음인 이유 Chapter. 실수는 예방하는 것이 아니라 관리하는 것이다. 후기 시작하며 최근에는 개인 프로젝트에 몰두하느라 기술 서적 위주로 책을 읽어왔습니다. 최근 F-Lab의 모각코에 참석할 기회가 있었는데 Ricky 매니저님이 책 선물을 주셨습니다. (책 선물은 너무 감사하죠) 이번 기회에 잠시 근본적인 주제를 공부해보는 시간을 가지려 책을 펼쳐봤습니다. Chapter. 구글이 밝히는 탁월한 팀의 비밀 구글에서 연구한 바에 의하면 뛰어난 팀은 "팀의 심리적 안전감"과 높은 연관성을 가지고 있다고 합니다. 이 챕터에서는 긍정적인 피드백이 불러오..