1. 대성당을 그리는 관점 “돌을 자를지라도 대성당을 그려라” 우리의 프로젝트(자동차 정비 프로젝트)의 “대성당”은 무엇인가? 프로젝트의 장기 목표 우리가 궁극적으로 만들고 싶은 가치 2. 다듬고 싶은 기술 목록 인프라 관련 IaC 기술 현 시점 가장 유용한 “바이브 코딩” 기술...

항목 8. 좋은 설계의 핵심 ETC(Easier to change), 하지만 적당히와 적절히! 엔지니어링 일지가 가장 좋은 툴이 블로그나 노션인데, 한동안 잘 안적고 있어서 적어야겠다고 생각. 항목 9. DRY: 중복의 해악 중복의 해악으로 주석과 코드가 그 지식이 중복된다는 것을 책을 보고 깨달음. 주석은 목적과 용도를 넣기...

내용 동기 회사 상품 목록 api 중 상당히 느린 코드가 있었다. 해당 코드는 코드 구조가 상당히 복잡하여, 속도 개선을 위해서 아래와 같은 선택지가 있었다. 해당 상품목록 api를 사용하는 프론트 코드에서 반드시 사용하는 response만 확인하여, 성능이 개선된 v3 api 개발. 반복적으로 호출하는 상품, 아이템에 캐싱을...

내용 3.2 Blameless Incident Response (비난 없는 장애 대응) 책임 추궁 대신 원인 분석 → 장애 발생 시, “누가 잘못했는가?”가 아니라 왜 이런 일이 발생했는가?를 분석 투명한 공유 및 개선 → 장애 원인과 대응 과정을 Post-Mortem을 통해 공유하고, 향후 개선점을 논의 재발 방지를 위한 학습 기회 ...

내용 장애 시뮬레이션 장애 시뮬레이션은 운영 환경에서 발생할 수 있는 장애를 미리 실험적으로 재현하여 대비하는 과정입니다. Chaos Engineering Chaos Engineering은 시스템의 복원력을 테스트하고 강화하기 위해 고안된 기법입니다. 2.2 Chaos Engineering 원칙 현실적인 조건에서 실험 실제...

12주3일차_장애_대응_프로세스_구축 장애 탐지 및 모니터링 시스템 구축 장애 탐지 주요 방법 1.1.3 장애 탐지 Best Practice 자동화된 모니터링 및 알림 시스템 구축합니다. AI 기반 예측 분석(AIOps) 활용하여 장애 예방합니다. 모니터링 데이터를 분석하여 장애 원인 식...

12주2일차_장애_발생_원인_분석 2일차. 장애 발생 원인 분석 (네트워크, 리소스 부족, 서비스 간 의존성, 배포 실패, DB 이슈 등) 내용 1.1. 장애 발생 원인 분류 1.2.2 장애 탐지를 위한 주요 모니터링 시스템 2.1 네트워크 장애 분석 방화벽 설정 오류 특정 포트가 차단됨 iptables -L, firewalld 확인 ...

내용 장애 심각도 분류 기준 일반적으로 장애 심각도는 Critical (P1), Major (P2), Minor (P3), Trivial (P4) 등으로 나뉩니다. 이는 SLA (Service Level Agreement) 및 장애 대응 프로세스에서 중요한 역할을 합니다. 3.4 장애 심각도 결정 기준 이 기준을 활용하여 장애 심각도...

내용 deployment 관련해서 selector: 이 Deployment가 관리할 포드를 선택하는 데 사용되는 라벨 셀렉터입니다. matchLabels: app: nginx 라벨을 가진 포드를 선택합니다. template: 포드 템플릿을 정의합니다. service 관련해서 minikube service ...

11주5일차_ELK_스택_기반의_로그_적재_구축_실습 1.1 E-commerce 로그 수집 아키텍처 Backend → File → Logstash → Elasticsearch → Kibana 실시간 로그 처리를 위해 Kafka와 Logstash 활용 example s3 -> filter -> s3 input ...