개발일기🌷

1. 컨테이너

• 호스트 OS상에 논리적인 구획(컨테이너)을 만들고,
  어떤 환경에서도 애플리케이션을 실행할 수 있도록 필요한 모든 요소를 포함하는 소프트웨어 패키지.
• 시작이 빠르고 운영체제 전체 부팅보다 메모리를 훨씬 적게 차지한다는 이점
• 컨테이너 런타임 : 컨테이너를 쉽게 다운받거나 공유, 구동할 수 있게 도와주는 역할
  - 컨테이너 런타임 중 가장 유명한 도구가 '도커'

2. 도커(Doker)

• 컨테이너 기반의 오픈소스 가상화 플랫폼.
• 컨테이너 이미지를 생성, 관리, 공유, 구동하는 작업을 손쉽게 하도록 도와줌
  - 이미지 : 컨테이너 실행에 필요한 파일과 설정값들을 포함하고 있는것

3. 쿠버네티스(Kubernetes)

• 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 시스템으로
  도커를 관리하는 오케스트레이션 툴
• 컨테이너 런타임을 통해 컨테이너를 오케스트레이션하는 도구
  (오케스트레이션 : 다수의 컨테이너 및 사용환경을 관리하는 것)
  → 각각의 컨테이너를 하나하나 관리하지 않아도 되고, 기밀이나 앱환경구성과 같은 세부관리 기능
• 서버리스, 머신러닝 등 다양한 기능이 쿠버네티스 플랫폼 위에서 동작

4. 쿠버네티스 v1.20부터 도커 지원 중단(2020.12.08)

• 컨테이너 런타임과 통신시 CRI라는 표준 인터페이스를 사용하는데, 도커가 이를 지원하지 않아 호환성 문제가 발생했기 때문
• 호환성 문제로 도커와 쿠버네티스 API를 연결하는 도커심을 사용했으나, v1.24부터 도커심 기본지원도 중단

• 방안 : 도커심을 통하지 않고, CRI를 준수하는 컨테이너 런타임 선택
  → 크리도커드(cri-dockerd), containerd, CRI-O
• 쿠버네티스 런타임에서 도커를 제거하더라도 도커에서 만든 컨테이너 이미지를 등록, 실행하는 것은 가능

참고) https://www.samsungsds.com/kr/insights/220222_kubernetes1.html

참고) https://captcha.tistory.com/46

참고) https://fastcampus.co.kr/story_article_kubernetes

1.메세지 큐(Message Queue)

• 메세지 지향 미들웨어(MOM)를 구현한 시스템으로 프로그램(프로세스) 간의 데이터를 교환할 때 통신하는 방법
• 메시지를 통해 분산되어 있는 시스템 간 Connector 역할을 하여 결합성을 낮추고 실시간 비동기식 데이터 교환
  → Producer : 메세지를 Queue에 전송하는 곳
  → Consumer : Queue의 메세지를 꺼내 처리하는 곳
  → Consuming : 메세지를 Queue에서 꺼내는 것

1-1. 메세지 지향 미들웨어(Message Oriented Middleware)

• 응용 소프트웨어 간의 데이터(비동기 메세지) 통신을 위한 소프트웨어
• 장점 : 메시지를 전달하는 과정에서 보관 / 라우팅 / 변환할 수 있다.
• 단점
  → 시스템 성능 및 신뢰성 저하
  → 관리가 어렵고, 비용 발생
  → 매커니즘 불일치(애플리케이션 간의 통신 : 동기 / 메시지 기반 통신 : 비동기)

1-2. 큐(Queue)

• 선입선출방식(First In First Out)으로 데이터를 처리하는 자료구조

2. 메세지큐 사용의 장점

• 비동기(Asynchronous): Queue에 넣기 때문에 나중에 처리가 가능.
• 비동조(Decoupling): Application과 분리할 수 있다.
• 확장성(Scalable): 여러개의 서비스들이 큐에 메세지를 보낼 수 있다.
• 탄력성(Resilience): 일부의 실패가 전체에 영향을 주지 않는다.
• 과잉(Redundancy): 실패시 재실행이 가능하다.
• 보증(Guarantees) : 작업이 처리된 것을 확인할 수 있다.

3. 사용처

- 다른 곳의 API로부터 데이터 송수신
- 다양한 애플리케이션에서 비동기 통신
- 이메일 발송 및 문서 업로드
- 대용량 프로세스들을 처리하기 위한 배치작업
- 채팅서비스

4. 종류

• Kafka, RabbitMQ, ActiveMQ 가 대표적. Amazon SQS, Amazon MQ 등이 있다.
  → Kafka : 처리량이 많은 분산 메시징 시스템에 적합
  → RabbitMQ, ActiveMQ : 신뢰성있는 메시지 브로커가 필요한 경우 적합

4-1. Apache Kafka
- 높은 처리량을 요구하는 실시간 데이터 피드처리, 대기시간이 짧은 플랫폼을 제공하는 것을 목표로 함
- TCP 기반 프로토콜 사용

4-2. RabbitMQ
- AMOT 프로토콜을 구현해놓은 프로그램
- 빠르고 쉽게 구성가능, 직관적

4-3. ActiveMQ
- 자바로 만든 오픈소스 메세지 브로커
- 다양한 언어와 프로토콜 지원

참고) https://sorjfkrh5078.tistory.com/291

참고) https://steady-snail.tistory.com/165

참고) https://programming-and-dt.tistory.com/entry/%EB%A9%94%EC%8B%9C%EC%A7%80-%ED%81%90-%EC%A2%85%EB%A5%98Message-Queue-MQ

참고) https://pamyferret.tistory.com/38

1. 프레임워크(Framework)

• 원하는 기능 구현에 집중해 개발할 수 있도록 일정한 형태와 필요한 기능을 갖추고 있는 골격을 의미
• 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용 가능하도록 협업화된 클래스들을 제공
• 앱/서버 등의 구동, 메모리관리, 이벤트루프 등 공통된 부분을 관리

1-1. 프레임워크의 장점

• 획일화
• 확장성 우수, 높은 완성도
• 안정적 유지보수

1-2. 프레임워크의 단점

• 코드습득을 위한 학습시간 필요
• 유연한 개발이 어려움
• 프로젝트 용량 증가

1-3. 프레임워크의 종류

• 백엔드 프레임워크 : Spring(자바), Django(파이썬), Rails(루비), Express(자바스크립트)
• 프론트엔드 프레임워크 : Angular, React, Vue ( → 모두 자바스크립트 기반)

2. 라이브러리(Library)

• 소프트웨어 개발시 사용되는 프로그램의 구성요소로서, 공통으로 사용될 수 있는 특정 기능들을 모듈화한 것
  → 표준 라이브러리 : 기본적인 기능수행, 디버깅, 성능측정을 위한 API
  → 런타임 라이브러리 : 실제 환경에서 실행되기 위해 필요한 모듈

2-1. 라이브러리 예시
Java : java.lang, java.utill, java,io, java.net, java.text, java.sql 등
Javascript : jQuery, DOM, AJAX, Date 등

3. 프레임워크 vs 라이브러리

참고) https://moolgogiheart.tistory.com/87

참고) https://cocoon1787.tistory.com/745

1. 메모리 구조(Memory Structure)

• 운영체제(Operating System)의 메모리 구조
  → 커널영역 : kernel 은 운영체제의 핵심, 커널영역은 system call을 통해 커널모드로 전환해야만 접근 가능
  → 유저영역 : Code, Data, Stack, Heap 4가지로 구성
• 프로그램 실행을 위해 운영체제가 프로그램 정보를 메모리(RAM)에 공간을 할당해주어야함
  → CPU가 코드를 처리하기 위해서는 메모리가 명령어와 데이터들을 저장해야함
  → 할당받는 대표적인 메모리공간(=유저영역)

2. Code 영역 ( = Text 영역 )

• 기계어로 컴파일되어 적재되는 코드 자체의 영역 / Read-only
• 실행할 프로그램의 코드가 저장되는 영역
• 프로그램의 시작부터 종료까지 메모리에 계속 남아있음
• CPU는 이 영역에 저장된 명령을 하나씩 가져가 처리

3. Data 영역

• 전역변수(Global)와 정적변수(Static)가 저장되는 영역
• 프로그램 시작과 함께 할당되고, 프로그램이 종료되면 소멸
• Read-Write

4. Heap 영역

• 프로그래머가 직접 공간을 할당, 해제하는 공간
  → 메모리 할당 : malloc() 또는 new 연산자 이용
  → 메모리 해제 : free() 또는 delete 연산자 이용

5. Stack 영역

• 프로그램이 자동으로 사용하는 임시 메모리 영역
• 호출시 지역변수, 매개변수가 저장되고, 호출완료되면 사라짐
  → 저장된 함수의 호출정보 : stack frame
  → 저장 : push / 인출 : pop

6. Heap VS Stack

7. 오버플로우

• 할당 가능한 메모리 영역을 넘어설 때 발생하는 오류
  → 이러한 특성을 이용해 해킹공격에 사용될 수 있다고함
• 종류
  → 힙 오버플로우 : 힙이 스택을 침범하는 경우
  → 스택 오버플로우 : 스택이 힙을 침범하는 경우, 오버플로우 중 가장 많이 발생

참고) https://mentum.tistory.com/475

참고) https://zangzangs.tistory.com/107

참고) https://hdacker.tistory.com/6

1. 클린코드란?

• 원하는 로직을 빠르게 찾을 수 있는 코드
• 모든 팀원이 해당 코드의 동작을 직관적으로 예측하기 쉽도록 작성된 코드
• 성능향상 / 가독성이 좋아 코드의 의미가 명확 / 중복을 제거해 생산성 향성

2. 클린코드의 중요성

• 유지보수 시간 단축(코드리뷰, 코드파악, 디버깅 시간 단축)
• 기술부채감소 (Technical Debt 기술부채  : 쉬운 솔루션을 채택함으로써 발생되는 추가적 재작업의 비용)

3. 클린코드의 원칙(General)

• Follow Standard Conventions : 코딩의 표준, 아키텍쳐 표준 및 설계 가이드 준수
• Keep it Simple, Stupid(KISS) : 단순한 것이 효율적, 복잡합을 최소화
• Boy Scout Rule : 참조되거나 수정되는 코드는 원래보다 클린하게 해야함
• Root Cause Analysis : 항상 근본적인 원인을 찾아라. 그렇지 않으면 반복될 것
• Do not Multiple Languages in One Source File : 하나의 파일은 하나의 언어로 작

3-1. 객체지향설계 SOLID 원칙(Class Design) → 설계관점 클린코드시 많이 회자된다고 함.

참고) https://talkwithcode.tistory.com/73

참고) https://zwzwzw123-daily-daily.tistory.com/96?category=994308