내 잡다한 노트

먼저, 가상화란? -> 하나의 물리적 서버에서 여러 운영체제와 애플리케이션을 실행할 수 있도록 하는 기술 컨테이너나 VM의 근본적인 기술은 가상화이다. 컨테이너는 호스트 OS 커널을 공유한다. 그리고 컨테이너 간에는 프로세스 수준의 격리를 사용한다. (cgroups, namespaces ) 그에 비해, 가상화는 하이퍼바이저 위에서 완전한 운영 체제를 실행한다. 애플리케이션과 해당 OS를 모두 포함하므로 크기가 크다.하드웨어만 공유를 하게 된다. (호스트 OS와 게스트 OS는 별개)그리고, 각 VM은 하드웨어 수준에서 완전히 격리된다.  둘은 성능의 차이도 나는데,컨테이너는 호스트 OS 커널을 공유하므로 부팅 과정이 필요가 없고, 애플리케이션 수준에서 바로 실행이 가능하다.또한, 가볍게 사용할 수 있다. ..

1. 문제 정의 문제가 무엇인지, 그리고 어떤 영향을 미치는지 명확히 정의한다. 무엇이 작동하지 않는지(증상), 언제부터 발생했는지(타이밍), 어디에서 발생했는지(위치), 어떤 서비스와 사용자가 영향을 받았는지, 최근 어떤 변경사항이 있었는지를 확인하며 문제를 정확하게 파악한다. 모든 트러블 슈팅 과정에서 이 부분은 공통적으로 포함되고 중요한 부분인 것 같다.찾아보니 이런 것을 5 Whys 기법이라고 한다. 증상, 타이밍, 위치, 범위, 변경사항 등을 체크해가며 왜 이런 문제가 발생했는지를 반복적으로 질문하며 근본적인 원인을 찾는다고 한다.  또한, 문제가 재현 가능하다면 동일한 조건에서 다시 발생시키고, 어떤 요소가 문제를 유발하는지 확인한다.  문제와 관련이 있는 fact와 관련이 없는 fact를 분..

자신이 작업한 내용을 체계적으로 평가하고, 개선점을 도출한다. 작업은 서버실 건물에 정전 공사가 일어나 대비를 했던 작업에 대한 리뷰이다.   1. 작업 내용 정리먼저, 자신이 진행한 작업의 목적, 범위, 구체적인 실행 내용을 정리합니다.정리 내용은 간단하게 작성하되, 상급자가 이해하기 쉽게 구성하세요.정리할 항목:작업의 목적: 정전 후 서비스 중단을 최소화하기 위해 어떤 점을 대비했는가?진행한 작업 목록: 구체적으로 어떤 설정을 했는지 (e.g., 컨테이너 재시작 정책, 백업, 테스트).결과: 작업이 제대로 수행되었는지, 예상했던 효과를 검증했는지. 2. 리뷰 기준 설정자신의 작업을 객관적으로 평가하기 위해 리뷰 기준을 설정합니다.예시 기준:작업의 완성도: 필요한 모든 항목을 꼼꼼히 준비했는가?테스트 ..

**멀티스테이지 빌드(Multi-stage Build)**는 Dockerfile에서 단계별로 빌드 환경을 분리하고, 최종 실행에 필요한 최소한의 파일만 포함하여 경량화된 이미지를 생성하는 방식입니다. 멀티스테이지 빌드란?멀티스테이지 빌드는 Dockerfile 내에서 여러 베이스 이미지를 정의하고, 각 단계(stage)에서 작업을 수행하며, 최종 단계에서는 필요한 파일만 가져옵니다.빌드 도구(컴파일러, 패키지 매니저 등)는 중간 단계에서만 사용하고, 최종 이미지는 실행 파일이나 애플리케이션 코드만 포함.최종 이미지는 작고, 불필요한 파일(빌드 도구 등)이 제거된 상태로 배포.  멀티스테이지 빌드를 사용하는 이유이미지 크기 최소화빌드 과정에서 필요한 도구(예: gcc, make)가 최종 이미지에 포함되지 않..

Dockerfile 최적화는 이미지 크기를 줄이고, 빌드 속도를 개선하며, 실행 성능과 보안을 강화하는 데 중점을 둡니다. 잘 최적화된 Dockerfile은 효율적인 CI/CD 파이프라인과 배포 환경을 구축하는 데 필수적입니다. 1. 이미지 크기 줄이기2. 빌드 속도 개선3. 실행 성능4. 보안 이걸 중점으로 최적화를 하도록 하자.   1. 이미지 크기 최적화(1) 경량 베이스 이미지 사용항상 필요한 최소한의 구성 요소만 포함된 경량 베이스 이미지를 사용합니다.예:ubuntu 대신 debian:slim 또는 alpine 사용.Python 프로젝트의 경우 python:3.9-slim 사용. (2) 멀티스테이지 빌드빌드 단계와 실행 단계를 분리하여 최종 이미지에서 불필요한 빌드 도구를 제외.멀티스테이지 빌드..

tmux는 터미널 멀티플렉서로, 하나의 터미널에서 여러 세션을 실행하거나, 세션을 유지하고 다시 연결할 수 있도록 도와줍니다. 다음은 tmux를 효율적으로 사용하기 위해 자주 쓰이는 명령어와 설명입니다.  기본 tmux 명령어1. 세션 관리새 세션 생성새로운 tmux 세션을 생성하고 이름을 지정합니다.tmux new -s  현재 세션에서 분리세션에서 빠져나오지만, 세션은 백그라운드에서 계속 실행됩니다.Ctrl-b d세션 목록 보기실행 중인 모든 tmux 세션을 표시합니다.tmux list-sessions 기존 세션에 연결특정 세션에 다시 연결합니다.tmux attach -t  세션 종료세션 안에서 exit을 입력하여 종료.exit

엔지니어링에서 사용하는 TA(Technical Architect), AA(Application Architect), **SA(Solution Architect)**는 시스템 설계와 개발 과정에서 서로 다른 수준에서 역할을 수행하는 아키텍처(Architecture) 전문 분야를 지칭합니다. 이 용어들은 IT 및 소프트웨어 엔지니어링에서 주로 사용되며, 각 용어가 맡는 책임과 초점은 다릅니다.  1. TA (Technical Architect)의미**TA(Technical Architect)**는 특정 기술(Tech Stack)이나 소프트웨어 시스템의 기술적인 구조와 구현 세부 사항을 설계하고 최적화하는 데 초점을 맞춘 역할입니다.주요 역할기술 스택(프레임워크, 프로그래밍 언어, 데이터베이스 등)을 선정하고..

**Throttling(쓰로틀링)**은 시스템, 네트워크, 애플리케이션 또는 API에서 과도한 요청이나 작업을 제한하여 성능을 유지하고 리소스 사용을 최적화하는 기술 또는 메커니즘을 말합니다. 또는 PC, 노트북의 CPU, GPU 등이 지나치게 과열될 때 기기의 손상을 막고자 클럭과 전압을 강제적으로 낮추거나 강제로 전원을 꺼서 발열을 줄이는 기능으로 불리기도 한다.  API Throttling은 주로 API를 사용하는 환경에서 적용되며, 클라이언트가 일정 시간 동안 보낼 수 있는 요청 수를 제한하여 API 서버가 과부하에 걸리지 않도록 보호합니다.  1. Throttling의 일반 개념목적리소스 보호: 서버, 네트워크, 데이터베이스 등의 과부하를 방지.공정한 리소스 분배: 여러 사용자 간에 리소스를 공..