알로그

정보관리기술사 답안지 작성 팁

알로그 — Sun, 20 Jul 2025 23:22:18 +0900

지난 3개월간 정보관리기술사를 취득하기 위해 공부하며 느낀점과 피드백 받은 내용을 내가 잊지 않기 위해 정리해본다.

공통

리드문 작성
간글 작성 (페이지 레이아웃 고려하기 위해)
가독성, 글씨
3단락 표 (구분, 기술요소, 설명)
법 문제 작성 시 몇 조항까지 작성
빈 공간 없이 작성
표를 빠르게 작성할 수 있도록 자에 공간 미리 표시
절차도 작성 시 그림에 넘버링
마지막 제언은 한계 대신 극복방안, 제언 등으로 작성
계산 문제는 자신있을때 들어가기
법 문제는 조항까지 작성해야 함

1교시

정의, 키워드 핵심
3단락 작성 (시간 배분 고려)
문제당 1.2 페이지 이상, 총 12 페이지 이상 작성

2-4교시

논리적으로 흐름이 자연스럽도록 작성
3 또는 4단락 작성 (시간 배분 고려)
문제당 3 페이지 이상, 총 13 페이지 이상 작성

마지막 단락 제언으로 쓰기 좋은 단어

AI, 클라우드, 보안, 법/제도, 프로세스, 전문가, 교육 등

하나카드 최대 25만원 캐시백

알로그 — Tue, 24 Jun 2025 10:38:58 +0900

롯데카드로 캐시백을 받기 위해 LOCA 카드를 신청했었는데, 환불을 고려 못하는 바람에 몇 천원 차이로 실적 충족을 못해서 캐시백 조건을 실패했다..
그래서 다음 캐시백을 뭘 할까 고민하다가 카카오페이에서 진행하는 하나카드 최대 25만원 이벤트를 바로 신청했다.

대상은 JADE Classic 카드와 원더카드인데, 혜택이 원더카드가 더 잘 맞아서 원더카드로 신청했다.

원더카드 혜택

아파트관리비, 전기세, 가스비 10% 청구할인
병원/약국 10% 청구할인
주유 10% 청구할인
커피 10% 청구할인
대중교통, 카카오 T, UT 10% 청구할인

각 혜택은 한도가 있음 참고

이벤트 기간은 6월 1일부터 30일까지만 사실상 종료하기 전까지 매 달 진행하는 것 같다. (7월도 진행)

첫 번째 혜택은 6월 30일까지 이벤트 응모를 하고 나서 7월 15일까지 10만원 이상 이용 시 7만 카카오페이포인트와 3만 캐시백이 8월 31일 이내에 지급된다.

두 번째 혜택은 25년 8월부터 26년 5월까지 매월 3만원 이상 이용 시 1.5만원 캐시백이 지급되는 구조라 꽤 장기간동안 사용을 해야 하는 단점이 존재하지만 금액이 적어서 크게 상관없어 보였다.

혜택 1은 충족 완료했으니 캐시백을 기다려보자..!

정보관리기술사 기본반 수업 끝

알로그 — Thu, 12 Jun 2025 09:42:09 +0900

어느새 정보관리기술사 자격증 준비를 위해 등록했던 학원의 기본필수반 9주가 지났다.
2025.04.16 - [정보관리기술사] - 정보관리기술사(Professional Engineer Information Management) 준비

정보관리기술사(Professional Engineer Information Management) 준비

육아휴직 중 어떻게하면 좀 더 의미있게 시간을 보낼 수 있을까 고민하다가 정보관리기술사(Professional Engineer Information Management)를 준비하기로 했다. 참고로 정보관리기술사란 한국산업인력공단

hungc.tistory.com

보통 정보관리기술사 학원을 등록하게 되면 기본반을 거쳐서 심화반을 합격할 때까지 돌리게 되는데,
내가 등록한 학원의 경우 기본반이 9주였다.

첫 수업을 듣고 저녁에 집에 가면서 이 짓을 어떻게 계속 하지? 했는데 참 시간 빠르다.

아이랑 저녁을 보내기 위해 그다음부턴 5시쯤 집에 가긴 했지만 결석은 한 번도 하지 않았고 오전 시험은 모두 참석했다.

수업은 온라인으로 들을 수 있지만 시험 준비와 멘토님으로부터 시험 피드백은 중요하기 때문에 꼭 참석하는것이 좋다.

집에 가는 길

그리고 드디어 지난 주가 마지막 9주차였고 마지막 수업에는 200분동안 Final Test 시험을 본다.
멘토님께서 시험에 대한 힌트도 어느정도는 알려 주고 등수가 크게 중요하진 않지만 다행히 목표한대로 1등으로 졸업을 했다.

9주동안 고생한 기념으로 인스파이어 호캉스에서 이틀은 신나게 놀고 다녀와서 바로 심화반에 등록했다.
우선은 8월 시험을 목표로 가보자!

OWASP Top 10

알로그 — Thu, 22 May 2025 14:58:05 +0900

웹 애플리케이션을 개발하거나 운영 중이라면 반드시 알아야 할 보안 지침이 있습니다.
바로 OWASP Top 10입니다.

이 글에서는 OWASP Top 10이 무엇인지, 각 항목이 어떤 취약점이며 왜 중요한지를 작성합니다.

1. OWASP Top 10이란?

OWASP(Open Web Application Security Project)는 전 세계 보안 전문가들이 모여 웹 애플리케이션의 주요 보안 취약점을 분석·정리하는 비영리 단체입니다.

OWASP는 약 3~4년마다 가장 심각하고 빈번한 취약점 10가지를 OWASP Top 10이라는 리스트로 발표합니다.

이는 사이버 보안의 기준이자, 개발자/운영자/보안 담당자의 체크리스트로 활용됩니다.

https://owasp.org/www-project-top-ten/

OWASP Top Ten | OWASP Foundation

The OWASP Top 10 is the reference standard for the most critical web application security risks. Adopting the OWASP Top 10 is perhaps the most effective first step towards changing your software development culture focused on producing secure code.

owasp.org

2. OWASP Top 10

아래는 2021년 기준 OWASP Top 10의 항목과 간단한 설명입니다.

순위	취약점명	한글 번역
A01	Broken Access Control	취약한 접근 통제
A02	Cryptographic Failures	암호화 실패
A03	Injection	주입(Injection) 취약점
A04	Insecure Design	보안이 고려되지 않은 설계
A05	Security Misconfiguration	보안 설정 오류
A06	Vulnerable and Outdated Components	취약하거나 오래된 구성요소
A07	Identification and Authentication Failures	인증 및 신원 확인 실패
A08	Software and Data Integrity Failures	소프트웨어 및 데이터 무결성 실패
A09	Security Logging and Monitoring Failures	보안 로그 및 모니터링 실패
A10	Server-Side Request Forgery (SSRF)	서버 측 요청 위조

2. 각 취약점 상세 내용

A01. Broken Access Control (접근 통제 실패)

권한 없는 사용자가 관리자 페이지, 다른 사용자 데이터 등에 접근할 수 있는 취약점
예: /admin URL을 직접 입력하면 관리자 페이지 접근 가능

A02. Cryptographic Failures (암호화 실패)

민감 정보가 암호화되지 않았거나, 약한 알고리즘을 사용하는 경우
예: 비밀번호를 평문으로 저장하거나 HTTPS 미사용

A03. Injection (명령어 삽입)

외부 입력값이 검증 없이 SQL, OS 명령어, LDAP 등에 포함되어 실행
예: ' OR 1=1 -- 같은 SQL 인젝션

A04. Insecure Design (보안 미설계)

아예 설계 단계에서 보안을 고려하지 않은 구조
예: 인증 절차 없이 내부 API에 접근 가능한 구조

A05. Security Misconfiguration (보안 설정 오류)

디버깅 모드 ON, 기본 비밀번호 사용 등 설정 부주의로 인한 문제
예: AWS S3 버킷 퍼블릭으로 설정

A06. Vulnerable and Outdated Components (취약한 구성요소)

사용 중인 오픈소스나 라이브러리가 구버전 또는 취약점 포함
예: jQuery, Spring 등 구버전 사용

A07. Identification and Authentication Failures (인증 실패)

인증 로직이 약하거나, 세션 관리가 부실한 경우
예: 세션 탈취, 비밀번호 추측 공격

A08. Software and Data Integrity Failures (무결성 실패)

신뢰할 수 없는 소스에서 소프트웨어/데이터를 받아 실행
예: 서명되지 않은 패키지를 자동 업데이트

A09. Logging and Monitoring Failures (모니터링 부재)

공격 징후를 탐지할 수 없거나, 로그가 없어서 추적 불가
예: 실패한 로그인 시도 기록 없음

A10. Server-Side Request Forgery (SSRF)

공격자가 서버에게 내부 주소로 요청을 보내도록 유도
예: 서버가 내부 IP 127.0.0.1로 접근하게 유도하여 민감 데이터 노출

3. 대응방법

사용자 입력은 반드시 검증 및 필터링
민감 정보는 강력한 암호화로 보호
신 보안 패치 유지
한 관리 철저 (Role-based Access Control)
그 및 이상 탐지 시스템 도입
보안 점검 자동화 도구 활용 (예: SonarQube, Snyk, Burp Suite)

OWASP Top 10은 웹 애플리케이션 보안의 가장 핵심적인 지표입니다.
개발자라면 프로젝트 시작 단계부터 이 리스트를 참고해, 안전한 아키텍처를 설계하고 보안 취약점이 최소화된 코드를 작성해야 합니다.

데이터베이스 (DB) 개요

알로그 — Mon, 19 May 2025 10:51:30 +0900

1. 데이터베이스 개요

● 데이터베이스란?

데이터베이스(Database)는 데이터를 효율적이고 체계적으로 저장하고 관리하는 시스템입니다. 수많은 데이터를 중복 없이 저장하며, 다양한 사용자들이 동시에 안전하게 데이터를 사용할 수 있게 도와줍니다.

Database

예: 은행의 고객정보, 계좌정보, 거래내역 등은 모두 데이터베이스에 저장되어 있고, 이를 여러 시스템이 동시에 안전하게 사용하는 구조입니다.

2. 데이터 모델링과 구조

● 데이터 모델링 계층 설명

개념적 모델: 현실 세계를 추상화하여 데이터 구조를 표현합니다. ERD(Entity-Relationship Diagram)로 설계되며, 개체(Entity), 속성(Attribute), 관계(Relationship) 등으로 구성됩니다.
논리적 모델: 개념 모델을 릴레이션(Relation)으로 구조화한 것입니다. 이 단계에서 정규화를 적용하여 이상현상(Anomaly)을 제거합니다.
물리적 모델: 논리 모델을 DBMS가 이해할 수 있는 실제 테이블, 인덱스 등의 구조로 구현합니다.

● 스키마 3계층 구조

외부 스키마: 사용자 관점에서 보는 뷰(View)
개념 스키마: 데이터베이스 전체의 논리적 구조
내부 스키마: 데이터의 물리적 저장 구조 (파일, 블록 등)

3. 정규화와 반정규화

● 정규화란?

정규화(Normalization)는 데이터의 중복을 최소화하고 무결성을 높이기 위한 테이블 구조 설계 방식입니다. 이를 통해 삽입, 삭제, 갱신 이상 현상을 방지합니다.

주요 단계

단계	설명	예시
1NF	원자값으로 분해	복수 전화번호 → 별도 행 분리
2NF	부분 함수 종속 제거	복합키의 일부분에만 종속된 속성 제거
3NF	이행 함수 종속 제거	비키 속성이 다른 비키 속성에 종속된 경우 제거
BCNF	결정자이지만 후보키가 아닌 것 제거	고급 정규형

● 반정규화란?

반정규화(Denormalization)는 정규화를 해제하거나 일부 중복을 허용하여 조회 성능을 향상시키는 기법입니다. 실무에서는 조인 성능 이슈, 보고서 최적화를 위해 자주 활용됩니다.

4. 트랜잭션과 동시성 제어

● 트랜잭션이란?

트랜잭션(Transaction)은 데이터베이스에서 하나의 논리적 작업 단위입니다. 여러 SQL 문이 하나의 트랜잭션으로 묶이며, 모두 성공하거나 전부 실패해야 합니다.

● ACID 4대 특성

특성	설명
Atomicity (원자성)	전부 수행 또는 전부 무효
Consistency (일관성)	일관된 상태 유지
Isolation (고립성)	동시 실행 시 간섭 없음
Durability (지속성)	성공한 트랜잭션은 영구 반영

● 동시성 제어 기법

Lock 기반: Shared Lock, Exclusive Lock, 2PL(2단계 잠금)
타임스탬프 순서 기법: 트랜잭션 타임스탬프를 기준으로 순서 결정
낙관적/비관적 제어: 충돌 가능성 여부에 따라 접근 방식 다름

5. 무결성과 키 설계

● 무결성이란?

무결성 제약(Integrity Constraint)은 데이터의 정확성과 일관성을 보장하는 규칙입니다.

주요 무결성 제약

개체 무결성: 기본키는 NULL이거나 중복될 수 없음
참조 무결성: 외래키는 반드시 참조 대상이 존재해야 함
도메인 무결성: 값이 허용된 범위 내에 있어야 함 (예: 나이는 0 이상)

● 키의 종류

기본키(Primary Key): 각 행(Row)을 유일하게 식별하는 키
예: 주민등록번호, 사번 등
후보키(Candidate Key): 기본키로 사용할 수 있는 모든 키 후보들
슈퍼키(Super Key): 유일하게 식별할 수 있는 속성 집합 (후보키 + 여분 속성 포함 가능)
외래키(Foreign Key): 다른 테이블의 기본키를 참조하여 관계를 맺는 키
예: 주문 테이블의 고객ID → 고객 테이블의 기본키 참조

6. 성능 최적화 설계

● 인덱스란?

인덱스(Index)는 데이터 검색 속도를 향상시키기 위한 자료구조입니다. 책의 목차와 유사한 개념입니다.

B-tree 인덱스: 범위 검색에 유리
Bitmap 인덱스: 중복도가 높은 컬럼에 유리

● 파티셔닝

파티셔닝(Partitioning)은 대용량 테이블을 논리적으로 분할하여 관리 성능을 높이는 기법입니다.

Range Partitioning: 날짜 등 연속 범위 기준
List Partitioning: 명확한 목록 기반
Hash Partitioning: 해시 함수를 이용한 균등 분할

● 조인 알고리즘

Nested Loop Join: 소규모 테이블에 적합
Sort-Merge Join: 양 테이블 정렬 후 병합
Hash Join: 메모리 기반 해시 테이블 생성

7. 데이터베이스 관리와 운영

● 백업과 복구

Full Backup: 전체 데이터를 백업
Incremental Backup: 변경된 데이터만 백업
Differential Backup: 마지막 전체 백업 이후 변경된 전체 내용 백업

복구 시에는 로그 파일(Redo/Undo), 체크포인트, 아카이브 로그 등이 활용됩니다.

● 보안과 접근제어

인증(Authentication): 사용자 신원 확인
인가(Authorization): 권한 부여 (RBAC 등)
암호화: 저장 데이터 또는 전송 데이터 보호
감사 로그(Audit Log): 모든 행위 기록

8. NoSQL과 최신 트렌드

● NoSQL이란?

NoSQL은 RDBMS의 한계를 극복하고 대규모 데이터 처리와 비정형 데이터를 저장하기 위해 등장한 시스템입니다.

유형	설명	예시
Document	JSON 기반 문서 저장	MongoDB
Column	열 기반 스토리지	Cassandra
Key-Value	단순 키/값 저장	Redis
Graph	노드-엣지 구조	Neo4j

● CAP 이론

Consistency(일관성): 모든 노드가 같은 데이터 보장
Availability(가용성): 응답 가능성 유지
Partition Tolerance(분산 허용성): 네트워크 분할 시에도 동작 보장

→ 이 세 가지 중 두 가지를 보장하는 구조만 가능

● BASE 이론

NoSQL에서 전통적인 ACID 대신 사용

Basically Available
Soft state
Eventually consistent

9. 실무 연계 흐름도 (학습 로드맵)

데이터 모델링 → 정규화 → 무결성 → 키 설계 → 트랜잭션 → 동시성 제어 → 성능 최적화 → 보안 → 최신 기술 연계

136회 정보관리기술사 시험 후기

알로그 — Sat, 17 May 2025 08:10:05 +0900

정보관리기술사 빈자리 시험 접수를 하고 7일 후 5월 17일에 준비물을 챙겨서 바로 시험을 보러 갔다.

준비물

다음에도 시험도 봐야 하니 내가 잊지 않기 위해 준비물을 추가 작성해 본다.

신분증
수험표
공부자료(패드)
볼펜 4자루
자
테이프
타이머
물
옷 (에어컨 대비)
휴지
점심
초콜렛

집에서 7시 40분쯤 나와 택시 타고 도착해 보니 8시가 약간 넘은 시간이었다.

오래 봐야 하는 시험이다 보니 생긴 지 얼마 안 된 마곡하늬중학교로 선택했는데, 좋은 선택이었던 것 같다.

일찍부터 사람들이 꽤 많았는데, 정보관리기술사 시험 응시자뿐만 아니라 건축, 전기 등 모든 기술사가 함께 시험을 응시한다
일찍이 다들 공부 중이었는데, 나만 느긋하게 마음 편히 온 듯했다.

대충 훑어보니 나이가 있으신 분들이 꽤 있었고 나는 젊은 축에 속한 편이었던 것 같다.
새삼 참 많은 사람들이 열심히 살고 있구나란 생각이 들었다.

각 교시에 대한 정보는

1교시 09:00 ~ 10:40 (100분)
2교시 11:00 ~ 12:40 (100분)
점심 12:40 ~ 13:30 (50분)
3교시 13:40 ~ 15:20 (100분)
4교시 15:40 ~ 17:20 (100분)

1교시는 13문제 중 10문제를 작성해야 하는데, 확실하게 1.2page 이상 쓸 수 있는 건 DevOps 1문제였다..
화이트 레이블 마케팅, 범용 인공지능 위험관리 프레임워크, Agentic AI, 4차 정규화, 프록시 디자인패턴, DevOps 장단점, 세그먼테이션 오류 등의 문제가 출제되었다.

2교시 ~ 4교시는 6문제 중 4문제를 작성해야 하며, 각 문제당 3~3.5 페이지를 작성해야 한다.
공급망관리, PMO, LLM, Product Line, 품질보증, 혼동행렬, AI 윤리 기준 등의 문제가 출제되었다.

각 교시는 6~7 페이지 정도씩 작성하고 빠르게 제출하고 나와서 그냥 쉬었다.

SW공학, 프로젝트 관리, 보안, 인공지능 쪽의 문제가 많이 출제되었다고 한다.

4교시를 마치고 짐을 싸서 나왔는데, 페이지를 많이 작성하지 않아서 그런지 손은 안 아팠는데 허리가 너무 아팠다.

가능할지 모르겠지만 이 시험 최대한 빨리 끝내야겠다..

6+6 육아휴직 2개월차 급여 입금

알로그 — Wed, 14 May 2025 15:00:01 +0900

벌써 육아휴직을 한 지 2개월이 지났다.
육아휴직 시간은 참 빠르게 지나가고 특히 더 아깝게 느껴진다.

2개월차 육아휴직 급여도 직접 신청해야 하고 방법은 이전과 동일하다.

2025.04.18 - [Daily/육아] - 6+6 육아휴직 남편 급여신청

6+6 육아휴직 남편 급여신청

6+6 육아휴직 급여신청3월에 육아휴직을 시작하고 한 달이 지나서 급여신청을 했다. 참고로 6+6 육아휴직은 부모 모두 통상임금이 월 450만원 이상일 때부: 250, 250, 300, 350, 400, 450 만원보: 250, 250, 300

hungc.tistory.com

1개월, 2개월 수당은 2,500,000원으로 동일하다.

그래서 나는 마찬가지로 2,500,000원이 입금되었고,

와이프는 1,375,000원(이전에 받은 금액에서 250만원의 차액)이 입금되었다고 한다.

다음 달부터는 육아휴직 수당 금액이 늘어나서 나는 3,000,000원, 와이프는 1,875,000원이 들어올 것으로 예상된다.

조금 더 여유로워지겠구나 !

기업 생존을 위한 재해복구 전략 BCP, DRP, BIA

알로그 — Mon, 12 May 2025 22:00:43 +0900

BIA, BCP, DRP, DRS, DR, ISO 22301

오늘날 기업이 예기치 못한 사고, 재해, 사이버 공격 등으로부터 살아남기 위해 반드시 갖춰야 할 전략이 있습니다.

바로 비즈니스 연속성 관리(BCM)이며, 그 핵심에는 DRS, DRP, BCP, BIA, ISO 22301 등이 존재합니다.

이번 포스트에서는 이 개념들이 어떻게 연결되고, 어떤 시스템과 기준으로 구현되는지를 이해하기 쉽게 풀어보겠습니다.

1. DR(Disaster Recovery)란?

재해복구(Disaster Recovery, DR)는 시스템 중단이나 데이터 손실 등의 위기 상황에서 IT 서비스를 신속하게 복구하고 업무를 재개하는 전략입니다. DR은 단순한 백업이 아니라, 복구 시간(RTO)과 데이터 손실 허용범위(RPO)를 기준으로 한 정교한 복구 체계입니다.

2. DR 형태 구분 (Mirror / Hot / Warm / Cold Site)

DR 구현 방식은 복구 시간의 속도와 비용 수준에 따라 네 가지 유형으로 나뉩니다:

유형	설명	RTO/RPO	비용	복구 속도
Mirror Site	실시간 복제 + 자동 전환, 이중화 클러스터	수 초 / 없음	매우 높음	매우 빠름
Hot Site	주요 시스템을 실시간 복제하며 상시 대기	수 분 / 거의 없음	높음	빠름
Warm Site	시스템/데이터 일부만 미리 준비	수 시간 / 몇 시간	중간	보통
Cold Site	공간만 확보, 필요 시 장비 설치	수 일 / 수 일	낮음	느림

기업의 예산, 중요 시스템의 복구 필요성에 따라 혼합 운영도 가능.

3. DRP(Disaster Recovery Plan)

DRP는 DR 실행을 위한 절차서입니다.

누가, 무엇을, 언제, 어떻게 복구할지 상세히 기술
역할 분담, 복구 우선순위, 연락 체계, 전환 시나리오 포함
실제 재해 상황을 대비해 모의훈련을 주기적으로 실행해야 함

4. DRS(Disaster Recovery System)

DRS는 DR을 실현하는 기술 인프라입니다.

백업 시스템, 재해복구 서버, 복제 시스템 등 포함
온프레미스 혹은 클라우드 기반으로 구축 가능
DRP에 따라 자동 또는 수동으로 전환 동작

최근에는 AWS, Azure와 같은 클라우드 기반 DRS 구축이 증가하고 있습니다.

5. BIA(Business Impact Analysis)

BIA는 재해가 발생했을 때 업무에 어떤 영향이 있는지 분석하는 단계입니다.

업무별 손실 규모, 고객 영향, 법적 책임 등을 평가
복구 우선순위 결정의 핵심 도구
DRP 및 BCP 수립의 기초 자료

예시:

"주문 시스템 다운 시 하루 손실 5억 원 → 최우선 복구 대상 선정"

6. BCP(Business Continuity Planning)

BCP는 전사적인 비즈니스 연속성 계획입니다.

단순한 IT 복구를 넘어 전 조직이 위기 상황에서도 운영을 지속할 수 있도록 계획
인력 대체, 공급망 대책, 커뮤니케이션 방안 포함
BIA와 DRP 기반으로 수립

구성요소:

핵심업무 목록
대체 업무 프로세스
비상 대응팀 및 연락망
복구 테스트 계획

7. ISO 22301: 국제표준

ISO 22301은 BCP 및 BCM(비즈니스 연속성 관리)을 위한 국제 표준 인증 체계입니다.

위험 식별, BIA 수행, 문서화된 BCP 요건 포함
기업이 위기 대응 능력을 체계적으로 보유하고 있음을 증명
글로벌 비즈니스 및 공공 조달 시 신뢰 요소로 작용

종합 구성도: BCP ~ DRS의 흐름

다음 그림은 각 요소가 어떻게 유기적으로 연결되는지를 흐름입니다:

위험 발생
BIA (업무 영향 분석)
BCP (비즈니스 연속성 계획)
DRP (재해복구 계획)
DRS (재해복구 시스템)
복구 실행: Mirror / Hot / Warm / Cold Site

요약

용어	설명
DR	시스템 및 서비스의 재해 복구 자체
DRP	복구 절차와 책임 분담을 문서화한 실행 계획
DRS	복구를 위한 IT 인프라 시스템
BIA	재해가 업무에 미치는 영향을 분석
BCP	전사적 관점의 비즈니스 연속성 전략
ISO 22301	BCP를 국제적 수준으로 표준화한 인증 체계

결론

기업은 단순한 백업을 넘어 지속가능한 운영 체계를 갖춰야만 예기치 못한 위기 속에서도 살아남을 수 있습니다.

DR, DRP, DRS는 기술적인 기반이고, BIA는 분석 도구, BCP는 전략, ISO 22301은 그 모든 것을 포괄하는 국제 인증 체계입니다.

정보관리기술사 빈자리 시험접수

알로그 — Mon, 12 May 2025 11:01:01 +0900

많은 고민 끝에 정보관리기술사 빈자리 시험을 접수했다.
아직 학원 기본반이 6주 차밖에 진행하지 않았지만 시험 당일의 분위기를 느껴보는 것도 중요할 것 같았다.

본래 5월 시험은 4월 7일 ~4월 10일에 접수기간이었지만 당시에는 별 관심도 없었고, 뒤늦게 접수를 하려고 했지만 3일의 짧은 신청기간을 놓쳤었다.

다행히 빈자리 접수를 시험 전 주에 접수를 받고 있었고 고민하다가 시험을 접수했다.
자리가 없을까 봐 고민이었지만 생각보다 포기한 사람들이 꽤 있었나 보다 ㅎㅎ

시험 접수는 Q-Net 에서 진행할 수 있다.

대학생때 정보처리기사 시험 접수한 뒤로 거의 10년만에 접속한 것 같다.

https://www.q-net.or.kr/man001.do?gSite=Q

Q-net 자격의모든것

원서접수 큐넷에서 원서접수를 더 쉽게! 원서접수 초일, 접수시작 시간안내 기술사, 기능장, 기사, 정기·상시 기능사 오전 10:00 부터 전문자격(공인중개사, 변리사 등 37종목) 오전 09:00 부터 --> [2

www.q-net.or.kr

5월 11일 00시 되자마자 들어갔는데 접수 메뉴가 없었고 알고 보니 오전 10시부터 접수를 할 수 있었다.
마침 학원에서 수업을 듣고 있던 시간이라 수업을 들으면서 시험을 접수했다.

서울은 시험 볼 수 있는 장소가 꽤 많은데, 마곡이 집에서 가깝고 건물이 신식이길래 마곡하늬중학교로 접수했다.
별 생각이 없었는데 가격도 50% 할인이 됐다!?

알아보니 만 34세 청년(90년 1월 1일 이후 출생자)들의 취업을 위해 1년에 3번 응시료 50%를 지원해준다고 한다!

접수가 완료되면 한국산업인력공단에서 알림을 보내준다.

시험은 당장 이번 주 토요일인 5월 17일이다.

1/3은 작성이라도 할 수 있을지 모르겠다.
어차피 포기는 하지 않을 거니까 이번 시험을 통해 무언가를 느끼고 더 열공할 수 있길 바라본다.

RDBMS vs NoSQL

알로그 — Mon, 12 May 2025 08:22:16 +0900

RDBMS vs. NoSQL

효율적인 데이터베이스 설계를 위해 가장 먼저 고려해야 할 것이 RDBMS(관계형 DB)와 NoSQL(비관계형 DB)의 차이입니다.

이번 포스팅에서는 두 시스템의 구조적 차이부터 선택 기준까지 실무 중심으로 정리해보겠습니다.

1. RDBMS와 NoSQL의 구조적 차이

항목	RDBMS(Relational DB)	NoSQL(Not Only SQL)
데이터 모델	테이블 기반 (행/열 구조)	키-값, 문서, 컬럼, 그래프 등 다양한 구조
스키마 구조	고정된 스키마 (사전 정의 필수)	유연한 스키마 (필요 시 동적 변경 가능)
관계 표현	외래 키로 명시적 연결	중첩 구조로 관계 표현 (중복 허용)
확장성	수직 확장 중심 (서버 성능 ↑)	수평 확장 중심 (노드 추가)
쿼리 언어	SQL (표준화된 쿼리 언어)	JSON 기반 쿼리 또는 전용 API
무결성 관리	제약조건 기반 내부 통제	무결성은 어플리케이션에서 통제

2. 설계 철학 차이

RDBMS는 데이터를 정규화(Normalization)하여 중복을 최소화하고, 무결성과 정합성을 유지하는 데 중점을 둡니다.
NoSQL은 반정규화(Denormalization)와 중첩 구조로 빠른 응답성과 확장성에 최적화되어 있습니다.

이처럼 정합성 중심 vs 성능 중심이라는 설계 철학의 차이가 뚜렷합니다.

3. 어떤 상황에서 무엇을 선택해야 할까?

선택 기준	RDBMS가 적합한 경우	NoSQL이 적합한 경우
정합성 중요도	데이터 무결성이 최우선 (예: 은행, 회계)	일시적인 불일치는 감수 가능 (예: SNS, 로그)
데이터 구조	스키마가 고정적이고 정형적	데이터 구조가 자주 바뀌거나 유연함
성능/확장성	안정된 서버 기반, 트랜잭션 중요	초대용량, 실시간 처리, 클라우드 환경
쿼리 복잡도	복잡한 조인, 분석 쿼리 필요	단순한 Key 기반 조회가 많음

4. 실무 사례로 보는 차이점

분야	RDBMS	NoSQL
금융/보험	고객 정보, 거래 기록	거의 사용되지 않음
전자상거래	주문/결제/배송 정보	상품 후기, 실시간 인기 검색어
SNS 플랫폼	회원/로그인 기록	게시물, 좋아요, 실시간 댓글
IoT/로그 분석	-	센서 데이터, 실시간 로그 스트림

5. 혼합 설계

현대의 많은 시스템은 RDBMS와 NoSQL을 함께 사용하는 하이브리드 설계를 채택합니다. 예를 들어, 고객 정보는 RDBMS에 저장하고, 로그 데이터는 NoSQL로 수집 및 분석하는 구조입니다.

Polyglot Persistence(다중 DB 전략)과 CQRS(명령/조회 분리) 같은 아키텍처는 이런 상황에 최적화된 방식입니다.

RDBMS와 NoSQL은 서로 대체 관계가 아니라 보완 관계입니다.
시스템의 특성과 요구사항을 정확히 분석한 뒤, 가장 적합한 데이터베이스 구조를 선택하는 것이 설계의 핵심입니다.

AI 환각현상과 RAG 기술

알로그 — Fri, 9 May 2025 23:31:08 +0900

AI 환각현상(Hallucination)과 해결책 RAG(Retrieval-Augmented Generation)

인공지능이 아무리 똑똑해 보여도, 가끔 전혀 사실이 아닌 정보를 그럴듯하게 말하는 경우가 있습니다.
이처럼 AI가 거짓 정보를 실제처럼 생성하는 현상을 "AI 환각(Hallucination)"이라고 부릅니다.
환각 문제의 개념과, 이를 해결하기 위한 핵심 기술 RAG (Retrieval-Augmented Generation)에 대해 알아보겠습니다.

1. AI 환각현상(Hallucination)이란?

AI 환각이란, 언어 모델이 존재하지 않는 정보나 틀린 사실을 진짜처럼 말하는 현상입니다.
이것은 AI가 의도적으로 거짓말을 하는 것이 아니라, 내부에 저장된 지식을 바탕으로 확률적으로 가장 그럴듯한 문장을 만들어내기 때문입니다.

✔ 대표적인 환각 예시

입력환각	응답 예시
테슬라의 CEO는 누구야?	"트럼프입니다." (틀림)
1990년 노벨 AI 수상자는?	"존 스미스가 받았습니다." (존재하지 않는 인물)
논문 출처 알려줘	"Journal of AI, 2017" (없는 논문 생성)

✔ 왜 환각이 발생할까?

(데이터) 지식의 한계: 모델은 훈련 시점 이후의 정보를 알 수 없음
(검증) 정보 검증 불가: 외부 지식에 실시간 접근하지 않음
(모델) 확률적 생성 메커니즘: “가장 자연스러운 문장”을 만드는 것이 목표이지, “가장 정확한 정보”가 목표는 아님

2. RAG (Retrieval-Augmented Generation) 기술이란?

RAG는 이러한 환각을 줄이기 위한 기술로, 언어 모델이 외부 지식 저장소(예: 문서, 데이터베이스)에서 실시간으로 관련 정보를 검색한 후, 그 내용을 바탕으로 답변을 생성하는 방식입니다.

✔ 핵심 개념 요약

RAG = 검색(Retrieval) + 생성(Generation)
→ "모르면 검색해서 답하자"는 AI의 구조적 개선

3. RAG의 작동 절차 (6단계 요약)

질문 입력: 사용자가 자연어로 질문
질문 임베딩: 의미를 숫자 벡터로 변환
문서 검색: 벡터 DB에서 유사 문서 검색
문서 선택/정제: 관련 문서를 압축 정리
응답 생성: 검색 결과 기반으로 LLM이 답 생성
응답 출력: 최종 결과 제공 (+ 출처 가능)

4. 일반 vs RAG 비교

항목	일반 LLM	RAG 기반 LLM
정보 출처	내부 학습된 데이터	외부 실시간 문서
정확도	환각 가능성 높음	높은 신뢰도 유지
최신 정보 반영	불가능	가능
출처 제시	어려움	명확한 출처 제공 가능

5. RAG 기술의 활용 사례

기업용 사내 지식 검색 챗봇
의료 분야 문헌 기반 진단 지원
법률 문서 분석 및 조문 응답
실시간 뉴스 기반 질문 응답 서비스

AI 인공지능 용어 정리

알로그 — Thu, 8 May 2025 09:00:00 +0900

AI 인공지능 맛보기

1. 인공지능(AI)이란?

AI (Artificial Intelligence)는 인간처럼 사고하고 학습하며 판단하는 컴퓨터 시스템을 의미합니다.
가장 상위 개념으로, 모든 스마트한 기술을 포괄합니다.

예: 자율주행차, 챗봇, 번역기, 음성 인식 비서

2. AI 하위 개념: 머신러닝과 딥러닝

AI > Machine Learning > Deep Learning

출처: https://en.wikipedia.org/wiki/Artificial_intelligence#/media/File:AI_hierarchy.svg

머신러닝 (Machine Learning)

머신러닝은 데이터를 기반으로 스스로 규칙을 학습하는 기술입니다.
사람이 일일이 프로그래밍하지 않아도 데이터로부터 패턴을 찾아냅니다.

딥러닝 (Deep Learning)

딥러닝은 머신러닝의 한 분야로, 인간의 뇌 구조를 본뜬 인공 신경망(Neural Network)을 사용해 복잡한 문제를 해결합니다.
현재 GPT 같은 최신 모델도 이 딥러닝 기술 기반입니다.

3. 머신러닝의 학습 유형

구분	설명	예시
지도학습	정답(라벨)이 있는 데이터를 학습	이메일 스팸 분류
비지도학습	정답 없이 데이터의 패턴 탐색	고객 군집화
준지도학습	일부만 라벨이 있는 혼합 데이터 사용	의료 영상 진단
강화학습	보상을 기반으로 스스로 최적 행동을 학습	게임 AI, 로봇 제어

지도학습과 비지도학습

출처: https://en.wikipedia.org/wiki/Artificial_intelligence#/media/File:Supervised_and_unsupervised_learning.png

4. 딥러닝의 구성 요소

신경망 (Neural Network)

입력 → 은닉층(hidden layer) → 출력 구조를 가지며, 데이터의 특징을 계층적으로 학습합니다.

신경망

출처: https://en.wikipedia.org/wiki/Artificial_intelligence#/media/File:Artificial_neural_network.svg

활성화 함수 (Activation Function)

각 뉴런이 활성화될지 결정합니다. 대표적으로 ReLU, Sigmoid 함수가 사용됩니다.

손실 함수 (Loss Function)

예측값과 실제값의 차이를 수치로 표현하며, 모델이 얼마나 틀렸는지 알려줍니다.

경사하강법 (Gradient Descent)

손실 값을 줄이기 위해 가중치를 조정하는 모델 최적화 알고리즘입니다.

과적합 (Overfitting)

학습 데이터에는 잘 맞지만, 새로운 데이터에는 성능이 떨어지는 현상입니다. 일반화 능력이 떨어지는 상태입니다.

정규화 (Regularization)

과적합을 방지하기 위한 기술로, Dropout이나 L2 정규화 등이 있습니다.

5. 최신 AI 트렌드: 트랜스포머와 LLM

트랜스포머 (Transformer)

자연어 처리(NLP)에서 사용되는 딥러닝 모델 구조로, 문장 내 단어들 사이의 관계를 동시에 처리할 수 있습니다.
GPT, BERT 모델의 기반이 되는 구조입니다.

어텐션 메커니즘 (Attention Mechanism)

트랜스포머의 핵심 개념으로, 어떤 단어에 집중할지 가중치를 부여하여 문맥 이해를 향상시킵니다.

LLM (Large Language Model)

수십억~수천억 개의 파라미터를 가진 대규모 언어 모델입니다.
방대한 텍스트를 학습하여 사람처럼 자연스럽게 문장을 생성하고 이해합니다.

대표 모델: GPT-4, Claude, Gemini, LLaMA 등

사전학습 & 파인튜닝 (Pretraining & Fine-tuning)

사전학습(Pretraining): 일반 데이터를 이용해 모델이 언어를 기본적으로 이해하도록 학습
파인튜닝(Fine-tuning): 특정 작업(요약, 번역 등)을 위해 추가 학습

6. 주요 응용 분야

분야	설명	예시
자연어 처리 (NLP)	텍스트 분석 및 생성	번역기, 챗봇, 감성 분석
컴퓨터 비전 (CV)	이미지/영상 분석	얼굴 인식, 자율주행
생성 AI (GAN 등)	새로운 데이터를 생성	AI 이미지, 딥페이크
추론 (Inference)	학습된 모델을 실제 적용	고양이 이미지 인식, 문장 생성

7. AI의 한계와 윤리적 이슈

허위 생성 (Hallucination)

LLM이 존재하지 않는 정보나 사실과 다른 내용을 만들어내는 현상입니다.

편향 (Bias)

학습 데이터가 편향되어 있으면, 모델도 차별적 결과를 낼 수 있습니다.

설명가능성 (Explainability)

AI가 어떤 이유로 그 결과를 냈는지 이해하고 설명할 수 있는 능력이 중요합니다.

윤리와 규제

AI의 발전과 함께 개인정보 보호, 공정성, 책임 소재 등 사회적 기준 마련이 중요해졌습니다.

요약

AI는 사람처럼 사고하는 기술 전체
머신러닝은 데이터를 통해 학습하는 기술
딥러닝은 신경망 기반의 심층 학습
트랜스포머 & LLM은 최신 언어 이해/생성 기술
실생활에 널리 응용되며, 윤리 문제도 반드시 고려해야 함

제네시스 홈투홈 서비스

알로그 — Wed, 7 May 2025 10:10:23 +0900

제네시스 홈투홈 서비스

어느 날 차량에 엔진오일 교체 경고등 알람이 발생했고, MY GENESIS 어플에서는 배터리 주의, 기본점검 알림이와 있었다.
총체적 난국이다..

차량 정기점검받은 지도 얼마 안 됐었고 5월 중순에는 와이프 K3 결함이 있다고 점검받으라고 연락이 온터라, 차 점검으로만 시간이 너무 뺏긴다고 생각이 들어서 답답했다.. ㅠ

제네시스 홈투홈서비스 예약방법

어쨌든 차량 점검은 해야 하니 점검 예약을 진행하려고 했더니 제네시스 홈투홈 서비스를 제공하는 것이다!
(참고로 제네시스 점검 예약은 'MY GENESIS' 어플로 쉽게 예약할 수 있다.)

어떤 정비를 할 건지 항목을 선택하는데, 크게 모빌리티케어, 소모품교체, 일반/품질 정비, 제네시스 안심점검으로 나눠진다.
나는 엔진오일 교체하고 하는 김에 곧 여름이니 에어컨 필터 교체와 함께 안심점검을 선택했고 요청사항에 배터리 경고등 발생도 함께 작성했다.

그리고 날짜와 함께 장소를 선택하면 되는데, GPS 기반으로 현재 위치에서 가까운 장소가 나열된다.

그리고 정비 예약을 눌렀는데, 아래와 같이 홈투홈 서비스 팝업이 떴다!
예약을 자연스럽게 유도해 주고 제네시스 앱에서 UX에 신경을 좀 썼네라고 생각이 들었다.

나도 몰랐는데 잔여 6개가 남아있었고 바로 홈투홈 서비스를 통해 예약을 진행했다.
예약은 크게 안 어려웠고 어디로 차량을 픽업할 건지 주소와 연락처 정보를 기입하면 된다.

참고로 기본거리가 12km 초과 시 고객부담금액이 발생하므로 차량을 픽업할 수 있는 장소와 가까운 지점에서 검사를 받는 것을 권장한다.

예약을 하고 나면 약간이 시간이 흐른 뒤에 아래와 같이 카톡으로 알람 메시지가 전송된다. (개인정보 제거)

아직 서비스를 직접 받진 않았는데, 받게 되면 후기를 아래에 다시 남기겠다.

홈투홈서비스 후기

우선 서비스 결과는 너무 만족스러웠다.
3일 전, 하루 전에 예약 알림 문자가 와서 잊지 않도록 리마인드 해주고 당일에 기사님 출발 알림톡을 받을 수 있다.

그리고 차량 키를 전달해드리고 점검 후에 다시 차를 전달받으면 끝이다.
그동안 기사님 출발 -> 차량 인수 -> 점검 시작 -> 점검완료 후 출발 -> 차량 인계 완료 알림톡이 계속 실시간 상황을 받아 볼 수 있다.

마지막으로 만족도 조사 알람이 오는데, 당연히 너무 만족스러워서 5점으로 평가했다.

앞으로 잔여쿠폰 다 사용할 때까지 해당 서비스를 이용할 계획이다.

가상화(Virtualization) 기술

알로그 — Sat, 3 May 2025 12:54:44 +0900

가상화(Virtualization)는 현대 IT 환경의 핵심 기술 중 하나로, 서버 자원의 효율적인 활용은 물론, 클라우드 인프라, 소프트웨어 테스트, 개발 환경 격리 등 다양한 분야에서 필수적으로 사용됩니다.

가상화 기술의 개념부터 종류, 하이퍼바이저, LXC, Docker까지 구조와 비교를 포함해 쉽게 정리해봅시다.

1. 가상화란?

가상화란, 물리적인 자원을 논리적으로 분리하여 하나의 시스템에서 여러 개의 독립된 시스템처럼 운영할 수 있게 하는 기술입니다. 서버, 운영체제, 저장소, 네트워크 등 다양한 자원을 가상화할 수 있으며, 효율성, 확장성, 보안성 측면에서 큰 이점을 제공합니다.

예를 들어, 하나의 서버에서 여러 개의 운영체제를 동시에 실행하거나, 하나의 운영체제 안에서 여러 개의 앱을 각각 격리된 환경에서 실행할 수 있습니다.

2. 가상화 기술의 분류

<목적에 따른 분류>

서버 가상화	물리 서버를 여러 가상 머신으로 분할
데스크탑 가상화	사용자 환경을 중앙 서버에서 가상으로 제공
스토리지 가상화	다양한 저장소를 하나의 논리 저장소처럼 운영
네트워크 가상화	네트워크를 논리적으로 분리하여 다중 네트워크 구현
애플리케이션 가상화	OS와 애플리케이션 간의 실행 환경을 분리

<실행 방식에 따른 분류>

✅ 하이퍼바이저 기반 가상화

Type 1 (Bare-Metal): 하드웨어에 직접 설치되어 실행 (ex. VMware ESXi, KVM)
Type 2 (Hosted): 기존 운영체제 위에서 실행 (ex. VirtualBox, VMware Workstation)

✅ 컨테이너 기반 가상화

리눅스 커널의 namespace, cgroups 등을 이용하여 사용자 공간 격리
대표 기술: LXC, Docker, Podman

3. 하이퍼바이저란?

하이퍼바이저(Hypervisor)는 가상 머신(VM)을 생성하고 관리하는 소프트웨어입니다.

Type 1	하드웨어에서 직접 실행	VMware ESXi, Hyper-V, KVM
Type 2	OS 위에서 실행되는 애플리케이션 형태	VirtualBox, VMware Workstation

하이퍼바이저는 CPU, 메모리, I/O 등의 자원을 분리하여 각 VM에 분배하고, 격리된 환경을 제공합니다.

Hypervisor 유형

4. LXC(Linux Containers)

LXC는 리눅스 커널의 Namespaces와 Cgroups 기능을 활용하여 컨테이너를 구현하는 운영체제 수준 가상화 기술입니다.

하이퍼바이저 없이 커널을 공유
컨테이너: 격리된 사용자 공간에서 앱 실행
libvirt / LXC 도구: 컨테이너 생성 및 관리
커널 공유: 모든 컨테이너가 동일한 리눅스 커널 사용

Docker의 초기 버전도 내부적으로 LXC를 기반으로 했으며, 지금은 runc라는 런타임을 사용합니다.

5. Docker

Docker는 컨테이너 기술을 더 쉽게 사용할 수 있도록 만든 애플리케이션 중심의 가상화 플랫폼입니다. LXC와 유사하게 리눅스 커널을 공유하지만, 애플리케이션 단위로 패키징하고 배포할 수 있어 DevOps, CI/CD, 마이크로서비스 환경에서 널리 활용됩니다.

Docker Engine: 컨테이너 생성·실행·관리 (runc + containerd)
이미지 기반 배포: 앱과 환경을 하나로 패키징
오케스트레이션: Kubernetes와 연동하여 대규모 운영 가능

6. 차이점 분석

구분	가상머신	LXC	도커
격리 수준	하드웨어 수준	OS 수준	OS 수준 (경량화됨)
부팅 속도	느림	빠름	매우 빠름
커널 공유	X (자체 커널 사용)	O	O
용도	OS 환경 전체 가상화	시스템 단위 컨테이너	애플리케이션 단위 컨테이너
대표 기술	VMware, Hyper-V, KVM	LXC	Docker, Kubernetes

결론

가상화 기술은 클라우드 컴퓨팅, 개발 환경 구성, 인프라 통합, 보안 강화 등 다양한 분야에서 핵심 역할을 합니다.
특히, 컨테이너 기반 기술은 최근 DevOps와 마이크로서비스 아키텍처에서 표준처럼 사용되고 있습니다.

가상화를 통한 자원 효율성 향상, 비용 절감, 유연한 확장성, 격리성, 빠른 배포와 백업이 가능해집니다.

상암 별소아청소년과 의원

알로그 — Wed, 30 Apr 2025 21:04:00 +0900

상암 별소아청소년과 의원

상암으로 이사 온 뒤 맛집, 어린이집, 공원 등 만족스러운 게 많은데, 그 중 소아과 만족도가 Top 3 안에 드는 것 같다.
이사오기 전에 다니던 소아과는 너무 불친절하고 접종주사를 착각할 뻔한 적도 있어서 다니기 싫었지만 근처 소아과가 하나뿐이라 억지로 다녔었다.

아이가 한창 어린이집에 다니고 감기에 걸려올 일이 많아 병원 갈 일이 많은데, 상암 별 소아청소년과는 다녀본 병원 중 가장 친절한 병원이라고 생각된다.

서울 마포구 월드컵북로 347 상암메디컬빌딩 4층

상암초 정문 옆에 상암메디컬빌딩 4층에 위치하고 있다.
빌딩 이름이 메디컬빌딩인 것처럼 다양한 종류의 병원이 있다.

병원 내부 사이즈는 아담한 편이다.
두 분의 의사 선생님이 계시고 각각 1 진료실, 2 진료실에서 매일 번갈아가면서 진료를 봐주시는듯하다.

원장 선생님들과 간호사 선생님들이 너무 친절하고, 아이에게도 상냥하고 친근하게 대해 주시고 기억해 주시는 것 같다.
그 덕에 처음에는 병원 엘리베이터만 타도 울던 아이가 점차 적응해서 이제 아~ 소리를 내며 입을 벌린다.

진료가 끝나고 나서는 항상 비타민 사탕을 주시는데, 아기가 매번 기억하는지 끝나고 나오자마자 당당하게 "삐약이 까까"라고 외쳐서 머쓱했다. ㅎㅎ

1층에는 약국이 있어서 편하게 약을 처방받을 수 있다.

상암 세계로 약국

참고로 똑딱으로 예약할 수 있으며, 똑딱을 통한 예약은 9시 10분부터 가능하고 환절기라 환자가 꽤 많기 때문에 10시 이전 예약은 대기가 오래 걸릴 수 있다.

나도 8시 50분에 도착해서 대기했을 때, 대기 5번이었는데 9시 10분에 대기가 15명으로 는 걸 보면..

아이가 점차 병원과 약에 적응해 가는 게 대견하기도 하지만 안쓰럽고 미안한 마음도 동시에 드는 건 어쩔 수 없는 것 같다.
이따 또 병원 가야지..

카드고릴라 삼성카드 탭탭 캐시백 후기

알로그 — Sun, 27 Apr 2025 10:13:40 +0900

카드고릴라 삼성카드 탭탭 캐시백

2월부터 여행을 비롯해 돈 쓸 일이 꽤 많아서 카드테크를 해보기로 시도해 봤다.

카드테크로 유명한 카드고릴라 사이트에서 적당한 카드를 살펴봤는데, 보통 캐시백 혜택이 많은 카드들은 이달의 이벤트카드라고 해서 홈페이지 접속하자마자 볼 수 있다.

그리고 캐시백을 받기 위해서는 보통 6개월간 해당 카드의 거래 이력이 없어야 한다.

이미 현대카드, KB카드, 신한카드를 사용 중이었기에 혜택과 캐시백을 고려했을 때 삼성카드 탭탭이 가장 적합해 보였다.

삼성카드 탭탭

삼성카드 탭탭의 주요 정보는 다음과 같다.

연회비: 국내 1만원, 해외 1만원
기준실적: 직전 1개월 합계 30만원 이상
주요 혜택: 스타벅스 50%, 교통 10%, 쇼핑 7% 등 (한도 있음)

게다가 스타벅스를 애용하는 나에게 50% 할인이라는 점이 매력적이었다. 월 할인 한도는 1만원까지 가능하다.

나 같은 경우 2월 초에 카드를 신청했고 4월 결제일에 14만원 캐시백이 되는 구조였다.

한참 잊고 있다가 오늘 명세서를 확인해 보니 캐시백이 지급된 걸 확인할 수 있었다.

현금으로 지급되는 구조는 아니고 내가 쓴 금액에서 차감되는 형태였다.

만약 캐시백을 받는 14만원보다 덜 사용했을 경우 다음 달 명세서에서 차감된다고 하니 참고하자.

여행이나 쇼핑 등 큰 돈이 나갈 계획이 있으면 카드테크를 해보는 것도 좋은 것 같다.

다음엔 롯데카드를 신청할 계획이다.

한국교통안전공단 성산 자동차 검사소

알로그 — Wed, 23 Apr 2025 11:46:56 +0900

상암 성산 자동차 검사소

GV70을 운전한 지 어느새 2년이 지나 자동차 정기검사 알람이 왔다.
차량 정기검사 예약은 한국교통안전공단에서 진행할 수 있다.
https://www.cyberts.kr/portal/main.do

사이버검사소 | 한국교통안전공단

현재 고객님께서는 인터넷 익스플로러 브라우저를 이용하고 계십니다. 인터넷 익스플로러(Internet Explorer)[] 브라우저 이용 시 일부 기능이 동작하지 않거나 오류가 발생할 수 있습니다. 보안

www.cyberts.kr

간단하게 예약을 진행할 수 있고 예약하게 되면 아래와 같이 카톡으로 알람이 온다.
검사 예약일 전날에도 까먹지 않게 알림을 보내준다.

한국교통안전공단 알림톡

참고로 예전에 차량 검사를 받을 때는 차량등록증이 필요했지만 이제는 필요하지 않다.
장소는 집에서 가까운 성산자동차 검사소로 예약을 했고, 마포구청 옆에 위치하고 있다.

위치: 서울 마포구 월드컵로 220 성산자동차 검사소

참고로 처음에 티맵 네비가 알려주는 대로 후문?쪽으로 갔는데 막혀있어서 바로 정문으로 가는 걸 추천한다.

성산자동차검사소 정문

정문을 통해서 안으로 좀 들어가다 보면 안내해 주시는 분이 몇 번 라인으로 가서 서라고 알려주신다.

나 같은 경우에는 2번으로 알려주셨는데, 2번 라인에 차량이 많아서 4번 라인으로 갈아탔다 ㅎㅎ
총 6번 라인까지 있는데 눈치껏 줄을 잘 서는 것도 10~20분 정도는 단축시킬 수 있는 걸로 보인다.

내가 예약한 시간은 4월 23일 수요일 오전 10시 20분이었는데, 평일이었는데도 불구하고 대기 중인 차량이 많았다.

10시 10분부터 줄을 섰는데 10시 40분부터 검사를 받을 수 있었다.

차 키는 차에 두고 내리면 되고, 바닥에 표시된 고객대기실 안내를 따라서 고객대기실에서 대기하고 있으면 된다.

검사 시간은 대략 15분 정도 걸린다고 안내되어 있는데, 실제로 걸린 시간은 10분 정도였다.
10분 정도 뒤 관리사분께서 간단하게 요약해서 설명을 해주시는데, 다행히 차량에 아무 문제가 없어서 무사 귀가 할 수 있었다.

상암 햄버거, 크라이치즈버거

알로그 — Wed, 23 Apr 2025 00:18:15 +0900

늦은 점심을 뭐 먹을까 고민하다가 요새 홍보를 자주 하는 크라이치즈버거에 방문했다.

최근에 버거 탈을 쓰시고 전단지 나눠주시는 모습을 자주 봐서 그런지 갑자기 생각이 났다.
문득 이래서 기업에서 홍보에 그렇게 많은 돈을 쓰나 생각이 들었다.

위치는 상암 DDMC 건물로 내가 좋아하는 솥밥 맛집인 솔솥과 같은 건물이다.

위치 : 서울 마포구 매봉산로 75 B109, B110
영업시간 10:30 ~ 21:00

크라이치즈버거

2013년부터 시작해서 벌써 12년째라고 하며, 치즈버거만 집중하고 있다고 한다.
개인적으로 이름이 궁금해서 찾아봤는데, 치즈가 녹는 모습을 우는 모습이라고 생각해서 만들어진 이름이라고 한다.

DDMC 1층 입구로 들어가면 우측에 바로 매장 입구를 볼 수 있다.

키오스크에서 주문할 수 있다.

치즈버거에만 집중해서 그런지 메뉴가 몇 개 없고 정말 심플하다.
대표메뉴인 더블 치즈버거로 주문했다.

늦은 점심이라 그런지 사람이 1-2명밖에 없었다.

콜라, 빨대, 케첩은 별도의 공간에 마련되어 있어서 자유롭게 가져갈 수 있다.

메뉴는 아래와 같이 준비가 되고 패티 두 장에 치즈, 양파, 토마토, 양상추 등 기본으로 구성되어 있다.

특히 번이 맛있었고 역시 생각했던 대로 담백하고 깔끔한 치즈버거 맛이다.
개인적으로 나는 마지막에 치즈가 약간 물리긴 했지만, 치즈버거를 좋아하는 사람들에겐 추천할 만하다.

세면대가 안에 있어서 화장실을 안 가도 돼서 편했다.

무중단 배포 (카나리, 블루그린, 롤링 배포)

알로그 — Tue, 22 Apr 2025 13:35:00 +0900

현대의 소프트웨어 배포는 무중단(Zero-Downtime)이 핵심입니다.

대표적인 3가지 배포 전략인 카나리 배포, 블루-그린 배포, 롤링 배포에 대해 알아봅시다.

1. 카나리 배포 (Canary Deployment)

카나리 배포는 새로운 버전을 소수의 사용자에게만 먼저 제공해 테스트하고, 문제가 없으면 점진적으로 전체 사용자에게 확대 적용하는 방식입니다.

✔ 특징

초기에는 전체 트래픽 중 일부(예: 5%)만 신규 버전으로 전환
문제 발생 시 빠르게 롤백 가능
실제 사용자 기반 테스트 가능

✅ 장점

실 사용자 피드백을 바탕으로 검증 가능
롤백 속도가 빠름

❗ 단점

모니터링 및 트래픽 분산 설정이 필요
테스트 범위가 제한적일 수 있음

2. 블루-그린 배포 (Blue-Green Deployment)

블루-그린 배포는 두 개의 환경(Blue, Green)을 번갈아 운영하면서 배포 시 환경 전환을 통해 즉시 전환 및 롤백을 가능하게 하는 전략입니다.

✔ 특징

기존 운영 환경(Blue)은 유지한 채 신규 환경(Green)에 배포
Green 환경이 검증되면 트래픽을 Green으로 전환
문제가 생기면 다시 Blue로 빠르게 전환 가능

✅ 장점

무중단 배포 + 즉시 롤백 가능
운영 중인 버전과 완전 분리 가능

❗ 단점

두 개의 환경 유지로 인한 비용/리소스 부담
데이터베이스 변경 시 복잡성 증가

3. 롤링 배포 (Rolling Deployment)

롤링 배포는 기존 인스턴스를 하나씩 점진적으로 새 버전으로 교체해 나가는 방식입니다.

✔ 특징

전체 인프라 중 일부씩 순차적으로 업데이트
배포 중에도 서비스는 계속 유지

✅ 장점

리소스를 많이 사용하지 않음
간단한 배포에 적합

❗ 단점

롤백이 느리고 복잡할 수 있음
실시간 트래픽에 영향을 줄 수 있음

4. 비교 요약

항목카나리 배포블루-그린 배포롤링 배포

항목	카나리 배포	블루-그린 배포	롤링 배포
배포 속도	느림 (점진적)	빠름 (즉시 전환)	중간
롤백 용이성	빠름	매우 빠름	느림
무중단 여부	가능	가능	가능
리소스 소비	중간	높음	낮음
실사용자 테스트	가능	제한적	제한적

5. 마무리

배포 전략은 서비스 규모, 위험도, 예산, 인프라 구성에 따라 달라집니다.

신중한 검증이 필요하면: 카나리 배포
⚡ 빠른 롤백이 중요하면: 블루-그린 배포
자원 효율성이 중요하면: 롤링 배포

블랙박스 테스트 vs 화이트박스 테스트

알로그 — Mon, 21 Apr 2025 23:24:17 +0900

블랙박스 테스트 vs 화이트박스 테스트: 소프트웨어 품질 확보의 두 축

소프트웨어 테스트는 단순한 기능 확인을 넘어서, 제품의 신뢰성과 안정성을 확보하는 핵심 품질 활동입니다.
이 중에서도 블랙박스 테스트(Black-box Testing)와 화이트박스 테스트(White-box Testing)는 가장 기본적이면서도 상호보완적인 테스트 접근 방식으로, 다양한 프로젝트에서 병행 활용됩니다.

블랙박스 테스트(Black-box Testing)

정의

블랙박스 테스트는 시스템의 내부 구조나 구현 로직을 고려하지 않고, 입력(Input)과 출력(Output)만을 기준으로 소프트웨어의 기능을 검증하는 방식입니다.

주로 기능 명세서(Requirements Specification) 기반으로 설계되며, 사용자 관점에서의 정상/비정상 동작을 확인하는 데 초점을 둡니다.

특징

테스트 설계 시 소스코드 접근이 불필요
기능 요구사항 기반의 시나리오 중심 테스트
주로 시스템 테스트(System Testing), 인수 테스트(Acceptance Testing) 단계에서 활용

대표 기법

기법	설명
동등 분할(Equivalence Partitioning)	유효/무효 입력값 그룹화 후 대표 값으로 테스트
경계값 분석(Boundary Value Analysis)	경계 근처 값에서 오류 발생 가능성 집중 검증
상태 전이(State Transition)	시스템의 상태 변화 및 전이 규칙 테스트
결정 테이블(Decision Table)	조건 조합에 따른 결과 도출 구조화

화이트박스 테스트(White-box Testing)

정의

화이트박스 테스트는 시스템의 내부 로직, 알고리즘, 조건문 등의 구조를 기반으로 설계된 테스트입니다.

“코드가 어떻게 동작하는가”를 직접 확인하는 테스트 방식으로, 일반적으로 개발자 또는 코드 레벨에서 품질을 보장해야 하는 역할에서 수행됩니다.

특징

소스코드 분석을 기반으로 테스트 설계
로직 커버리지, 조건문 분기, 반복문 경로 등 세부 제어 흐름 검증
주로 단위 테스트(Unit Testing), 구조 테스트 단계에서 활용

대표 기법

기법	설명
문장 커버리지	코드 내 모든 문장이 최소 1회 이상 실행되었는지 확인
분기 커버리지	조건문(if/else 등)의 모든 경로를 실행해보는 방식
조건 커버리지	복합 조건문의 각 개별 조건이 True/False를 모두 가지도록 테스트
경로 커버리지	가능한 모든 실행 경로를 조합해 테스트

블랙박스 테스트 vs 화이트박스 테스트 비교

항목	블랙박스 테스트	화이트박스 테스트
테스트 기준	요구사항/기능 명세	코드 로직/제어 흐름
접근 범위	외부 동작 중심	내부 구조 중심
테스트 설계 주체	QA, 테스터	개발자
테스트 시점	시스템/인수 테스트	단위 테스트, 구조 테스트
장점	사용자 관점 오류 탐지, 요구사항 검증	로직 결함, 경로 누락 탐지에 효과적
단점	내부 오류 탐지 어려움	사용자 시나리오 검증 어려움

마무리

블랙박스 테스트는 사용자 요구사항이 제대로 구현되었는지를 검증
화이트박스 테스트는 내부 코드가 의도대로 작동하는지를 검증

두 테스트는 성격이 다르기 때문에, 서로를 보완적으로 활용하는 것이 이상적입니다.
실무에서는 일반적으로 화이트박스 테스트로 단위 수준의 품질을 확보한 뒤, 블랙박스 테스트를 통해 전체 시스템의 안정성을 검증합니다.

솥밥 맛집, 솔솥 상암점

알로그 — Sun, 20 Apr 2025 10:32:03 +0900

솔솥 상암점

상암에 드디어 솔솥이 생겼다..!!

비슷한 계열의 맛집인 담솥도 있지만, 개인적으로 솔솥을 더 선호한다.
담솥은 타임스퀘어 또는 상암에 이미 있어서 방문을 여러번 해봤지만 근처에 솔솥은 없어서 너무 아쉬웠었다.

처음에 판교에서 솔솥을 먹고 너무 맛있어서 종종 생각났었는데, 상암 DDMC 빌딩에 생겼길래 바로 방문했다.

위치: 서울 마포구 매봉산로 75 지하1층, 101호
영업시간 11:00 ~ 21:00
브레이크타임 16:00 ~ 17:00

DDMC 지하 1층 에스컬레이터 바로 뒷편에 자리잡고 있다.

솔솥 상암점

주말 일요일 저녁에 방문해서 그런지 사람이 아무도 없었다.
아마 평일 낮엔 사람이 엄청 많을 것으로 예상된다.

대표 메뉴는 11가지로 보통 스테이크 솥밥과 도미관자 솥밥을 많이 시켜먹는 것 같다.
전에 스테이크 솥밥을 먹었어서 이번에는 도미관자 솥밥과 연어 솥밥을 주문했다.

솔솥 메뉴

오픈 이벤트라고 고로케도 주셨는데, 사진 찍는걸 깜빡했다. ㅎㅎ

그림처럼 메뉴가 서빙되며, 솥밥에 있는 밥과 내용물을 섞어서 그릇으로 옮긴 뒤에 먹고 나서 누룽지로 먹는 형태다.

연어 솥밥과 도미관자 솥밥

연어솥밥과 도미관자 솥밥 모두 맛있었는데, 개인적으로는 도미관자가 더 맛있던것 같다.
연어는 간장 베이스의 양념 맛이 느껴지고 도미관자는 담백한 맛이다.

둘다 건강한 맛의 느낌이고, 와이프와 가족들 모두 만족스러운 식사였다.
특히 어머니들이 좋아할만한 메뉴인 것 같다.

주차는 1시간 지원 받았다.

상암에 맛집들이 계속 생기는 것 같아서 이사오길 더 잘한 것 같다.
다음에 장어솥밥을 먹으러 재방문할 계획이다.

SBOM (Software Bill of Materials)

알로그 — Sun, 20 Apr 2025 10:31:06 +0900

소프트웨어 자재 명세서, SBOM이란 무엇인가?

최근 몇 년간 소프트웨어 공급망 보안과 투명성에 대한 요구가 크게 증가하면서, SBOM(Software Bill of Materials)이 필수 요소로 부상하고 있다.

SBOM이란 정확히 무엇이고 왜 중요할까?

SBOM이란?

SBOM은 소프트웨어를 구성하는 모든 오픈소스 및 서드파티 컴포넌트의 목록을 정리한 문서이다.
제조업에서 흔히 사용되는 제품에 사용된 모든 부품을 기록하는 '자재 명세서(BOM)'처럼, SBOM은 소프트웨어가 어떤 구성요소로 이루어져 있는지를 명확히 보여준다.

SBOM에는 어떤 정보가 들어있을까?

Component Name (예: log4j)
Version (예: 2.17.1)
Supplier/Author (예: Apache Software Foundation)
License (예: Apache-2.0, MIT 등)
Dependency Type (직접/간접 의존성)
Package URL (purl) 및 Hash 정보 (무결성 검증용)

왜 SBOM이 중요한가?

SBOM은 소프트웨어의 투명성, 보안, 법적 컴플라이언스, 공급망 리스크 관리에 핵심적인 역할을 한다.

주요 목적설명

보안취약점 관리	취약한 오픈소스 탐지 및 패치 대응 가능
라이선스 컴플라이언스	라이선스 위반 사전 방지
공급망 리스크 관리	외부 컴포넌트 변경 이력 추적 및 리스크 분석
고객 및 감사 대응	소프트웨어 구성요소를 명확하게 문서화하여 신뢰도 확보

미국 바이든 행정부는 2021년 행정명령(EO 14028)을 통해 정부 납품용 소프트웨어에 SBOM 제공을 의무화했다.

이에 따라 글로벌 기업들도 SBOM 채택을 가속화하고 있다.

SBOM 표준은 무엇이 있을까?

표준명설명

SPDX	Linux Foundation 주도, ISO/IEC 5962 국제표준으로 채택됨
CycloneDX	OWASP 주도, 보안 중심의 SBOM 포맷
SWID Tags	ISO/IEC 19770 기반, 상용 소프트웨어 중심 메타데이터 제공

️ SBOM 생성 도구

SBOM을 수동으로 작성하기는 현실적으로 어렵기 때문에, 다양한 자동화 도구가 등장하고 있다.

도구특징

Syft	CLI 기반의 경량 SBOM 생성기, SPDX/CycloneDX 지원
Trivy	보안 취약점 탐지 + SBOM 생성 기능
FOSSology	라이선스 식별 및 SPDX 기반 리포트 생성
CycloneDX CLI	CycloneDX 포맷 SBOM 생성 전용 툴

국내에서는 LG전자의 FOSSLight, 카카오의 Olive를 주로 활용하고 있다.

✅ SBOM 도입을 위한 팁

자동화 도구 도입: 개발 파이프라인(CI/CD)에 SBOM 생성 툴 통합
주기적인 갱신: 소프트웨어 버전 업데이트 시 SBOM도 함께 갱신
라이선스 정책 정의: 조직 내 금지/허용 오픈소스 기준 마련
SBOM 저장소 관리: 중앙에서 SBOM 버전 관리 및 감사 로그 확보

결국 회사의 서비스가 어떤 오픈소스와 컴포넌트로 구성되어 있는지 SBOM을 통해 관리될 수 있어야 하며,

Log4j와 같은 보안취약점 이슈가 발생했을때 Log4j를 사용하고 있는 서비스를 모두 식별하여 빠르게 조치할 수 있어야만 한다.

6+6 육아휴직 남편 급여신청

알로그 — Fri, 18 Apr 2025 12:42:00 +0900

6+6 육아휴직 급여신청

3월에 육아휴직을 시작하고 한 달이 지나서 육아휴직 급여신청을 했다.

참고로 6+6 육아휴직은 부모 모두 통상임금이 월 450만원 이상일 때

부: 250, 250, 300, 350, 400, 450 만원
보: 250, 250, 300, 350, 400, 450 만원

총 4,000만원을 받을 수 있는 엄청난 혜택이다.

6+6 육아휴직에 대한 자세한 내용은 고용노동부 유튜브를 참조하자.
https://www.youtube.com/watch?v=4w-EO8YU_pQ

(첫 달 금액이 200 -> 250만원으로 변경되면서 위의 영상에서 언급하는 3,900만원에서 4,000만원으로 올랐으니 참고)

우리 집 같은 경우에는 와이프가 23년 10월부터 1년 넘게 먼저 육아휴직을 사용했고,
이때 150만원 * 0.75의 금액만큼 지급을 받았었다.

현재는 사후지급금이 폐지되었지만 당시에는 75%만큼 육아휴직 금액을 받고 회사에 복귀하면 25%를 추가로 돌려받는 시스템이었다.

육아휴직 급여신청 방법

육아휴직 급여신청은 고용24 사이트에서 진행할 수 있다.

고용24 육아휴직

휴직하고 나서 얼마 뒤 접수를 하려고 했는데 아래와 같이 급여신청 제출 불가라고 나왔다.

검색을 해봤더니 회사에서 먼저 육아휴직 확인서를 등록해줘야 한다고 했다.
회사가 등록해 줄 때까지 매주 한 번씩 확인을 했는데, 변화가 없어서 회사에 문의했더니 등록을 이미 했다고 전달을 받았다.

알고 보니 회사에서 등록을 해주고 한 달이 넘어야 급여 신청 제출이 가능했다.
3월 4일에 휴직을 했는데, 4월 5일이 되니까 위와 같은 문구가 사라졌다.

신청인 정보, 배우자 정보, 계좌 등 각 항목들을 입력하는 건 크게 어렵지 않으니 생략한다.

4월 7일에 접수해서 4월 14일에 입금되었으니 입금되는데 기간은 일주일정도 소요되는 것 같다.

와이프한테도 마찬가지로 사후지급금(150만원 * 0.25) 금액과
첫 달에 받아야 할 250만원에서 차액 보전분까지 같이 입금되었다.

와이프가 육아휴직을 2년 쓰는 것보다 남편과 나눠서 사용했을 때 약 3천만 원 정도의 금액이 차이 나는 것으로 보인다.
(물론 남편이 육아휴직을 쓸 수 있는 환경이어야 하고 통상임금에 대한 의존도가 있지만..)

이제 육아휴직을 한 지 한 달이 좀 지났는데, 아이와 소중한 시간을 보낼 수 있음에 너무 감사하게 생각하고 있다.
아이가 아빠 껌딱지가 되어서 이제 엄마보다 날 더 찾는 것에 신기하고 뿌듯하다.

스무 살 이후로 처음으로 생긴 여유라 하루하루가 더 소중하고 감사한 것 같다.

이 혜택을 받을 수 있게 해 준 정책과 회사, 팀 동료, 와이프에게도 너무 고마운데,
이 시간들을 낭비하지 말고 보람 있게 쓸 수 있도록 더 노력해야겠다.

서울형 키즈카페 마포구 상암점

알로그 — Wed, 16 Apr 2025 13:54:52 +0900

서울형 키즈카페 마포구 상암점

아이가 어린이집에 끝나면 매번 아이와 어떻게 놀아줄지가 고민인데..
서울형 키즈카페를 통해서 많은 도움을 받고 있다.

서울형키즈카페 상암점

가격이 저렴(영유아 2,000원 / 보호자 1,000원)하고 시설도 좋고 넓은데, 평일엔 사람이 별로 없다.
2층과 3층으로 구분되어 있고 2층은 활동적인 놀이 중심으로 구성되어 있고, 3층은 좀 더 정적인 활동(책읽기, 블록쌓기) 할 수 있는 것 같다.

2층 이미지

서울형 키즈카페 마포구 상암동점

이용정원: 개인 46명
이용연령: 1~6세
주소: 서울특별시 마포구 상암산로1길 71 마포구육아종합지원센터 2~3층 서울형 키즈카페 마포구 상암점 (상암동)

주차가 헬이라 차는 가지고 오지 않는것이 좋다.

서울형 키즈카페 예약

https://icare.seoul.go.kr/icare/user/kidsCafe/BD_selectKidsCafeList.do

서울형 키즈카페 예약 : HOME > 예약신청 > 서울형키즈카페 > 서울형 키즈카페 예약

icare.seoul.go.kr

아래와 같은 시간대로 운영되며, 본인이 가고자 하는 날짜와 시간을 선택해야 한다.

<평일운영시간>
-1회차 : 9:40~11:40 (단체)
-2회차 : 13:20~15:20 (공용)
-3회차 : 16:00~18:00 (공용)

<토요일, 일요일 운영시간>
-1회차 : 9:10~11:00
-2회차 : 11:10~13:00
-3회차 : 14:10~16:00
-4회차 : 16:10~18:00

보호자는 최대 2인까지 입장 가능하며, 1일 1회만 입장이 가능하다.
중요한 점이 만약 예약을 하고 못 갈것 같다면, 이용 시작 시간 30분전까지는 반드시 직접 취소해야 한다. (전화 취소 불가)
노쇼 패널티로 30일간 예약 및 이용이 불가할 수가 있기 때문이다.

그리고 입장시 등본을 확인하기 때문에 항상 가방에 등본을 챙겨서 다니고 있다.

오늘도 어린이집 하원 후 들러서 아이와 놀아줘야겠다.

정보관리기술사(Professional Engineer Information Management) 준비

알로그 — Wed, 16 Apr 2025 10:02:27 +0900

육아휴직 중 어떻게하면 좀 더 의미있게 시간을 보낼 수 있을까 고민하다가
정보관리기술사(Professional Engineer Information Management)를 준비하기로 했다.

정보관리기술사 준비 이유

정보관리기술사를 취득하게 되면 따라오는 혜택은 다음과 같다.

자격 수당
수석감리자격
평가위원
멘토링, 강의, 저서
전문직 대출
5급공무원 지원자격

나에게 기술사를 추천해준 친구는 회사에서 매달 30만원의 자격 수당을 지원해준다고 한다.
내가 다니는 회사는 정보관리기술사에 대해 딱히 크게 혜택을 제공해주진 않아서 취득하게 되더라도 평가위원이나 멘토링 정도 할 수 있으려나.. 당장은 크게 피부로 와닿을만한 메리트는 없어보였다.
노후를 위한 감리자격도 큰 메리트이긴 하지만 빠른 은퇴가 목표인 나에겐 크게 와닿진 않았다.

그럼에도 도전하게 된 이유는 IT 분야 최고 자격증이라는 점과 여태까지 배운 기술을 다시 한번 정리하고 큰 숲을 보고 싶었다.
그리고 학부에서 컴퓨터공학, 대학원에서는 소프트웨어공학을 전공하고 회사를 다니며 방통대에서 통계를 전공했기 때문에 남들보다 조금 더 수월하지 않을까 생각했고 육아휴직 기간동안 준비하기에 최적의 자격증이라고 생각했다.

정보관리기술사 시험범위

참고로 정보관리기술사란 한국산업인력공단에서 시행하는 시험이다.
년 3회 정도 시험이 있으며, 1차 필기시험은 400분 시간동안 손으로 시험을 봐야하는 엄청난 시험이다.

우선 공부해야 할 범위가 너무나 방대한데, 과목은 아래와 같다.

IT경영전략
소프트웨어공학
프로젝트관리
디지털서비스
디지털네트워크
보안
DB
CA/OS
DS/알고리즘
AI/통계

자격증을 취득하기 위해서 보통 회사를 다니면서 평일 4시간, 주말 10시간 공부(주 40시간)를 하면
보통 1년~1년 반 정도의 시간이 소요된다고 한다..

정보관리기술사 학원등록

4월 6일 일요일부터 시작하는 ITPE을 등록했고,
현재 한 주 싸이클을 돌아봤는데 범위가 너무 방대해서 생각했던거보다 더 빡센 것 같다.

https://itpe.co.kr/main/course/courseView.do?menuType=off&cateId=XAL0000219&pntCateId=XAL0000080&subCode=1&courseId=002940

ITPE 정보관리기술사 PMP자격증 감리사 정보통신기술사 Flipped Learning!

itpe.co.kr

한 주의 사이클은
- 일요일에 09:00 ~ 20:00 수업
- 수요일까지 과제
- 토요일까지 셀프테스트
물론 매일 한 주의 범위에 해당하는 도메인당 30-50개의 토픽을 외우기 위해서 공부도 해야 하며, 차주 수업 예습 인터넷 강의도 들어야 한다.

언제 합격하게 될 지는 모르겠지만.. 1년 후 합격 후기를 다시 쓸 수 있길 바라본다.

폭포수 모델 (Waterfall Model)

알로그 — Tue, 15 Apr 2025 13:09:37 +0900

폭포수 모델이란?

폭포수 모델은 개발 단계를 순차적으로 수행하는 전통적인 방식의 소프트웨어 개발 방법론으로 각 단계가 완료되어야 다음 단계로 넘어갈 수 있으며, 마치 폭포수가 위에서 아래로 흐르듯, 한 단계가 끝나야 다음 단계로 넘어갈 수 있다.

폭포수 모델(Waterfall Model)

주요 단계

요구사항 분석 – 사용자 요구를 명확하게 정의
설계 – 시스템 구조 및 세부 설계
개발 – 설계서를 기반으로 코딩
테스트 – 소프트웨어 품질 검증
배포 – 운영 환경에 설치
유지보수 – 배포 후 오류 수정 및 개선

✅ 장점

개발 절차가 명확하고 문서화가 잘 됨
초기 계획 수립이 잘 되어 있으면 관리가 용이
변경 가능성이 낮은 프로젝트에 적합

❌ 단점

변경에 매우 취약함
고객 피드백 반영이 늦음
작동 가능한 소프트웨어를 늦게 볼 수 있음

폭포수 모델 vs 애자일 모델 비교

진행 방식	선형적, 단계별 진행	반복적, 점진적 진행
요구사항 변경	변경 어려움	언제든지 가능
고객 참여	초기만 참여	지속적인 피드백 제공
문서화	상세한 문서 중심	최소한의 문서, 실용 중심
위험 관리	후기 발견	조기 피드백으로 빠른 대응
배포 시점	개발 후반에 전체 배포	매 이터레이션마다 작동 가능한 결과물 제공

어떤 모델을 선택해야 할까?

폭포수 모델이 적합한 경우
- 요구사항이 명확하고 변경 가능성이 낮은 프로젝트
- 안전성과 품질이 중요한 분야 (예: 항공, 금융, 의료)
- 문서화가 필수인 계약 기반 개발 환경
애자일 모델이 적합한 경우
- 요구사항이 자주 바뀌는 프로젝트
- 빠른 피드백이 필요한 스타트업이나 MVP 개발
- 고객과의 소통이 중요한 B2C 서비스 개발

프로젝트 특성, 팀 구성, 고객 요구사항에 맞는 모델을 선택해야 한다.

때로는 두 방법론을 혼합하여 사용하는 하이브리드 방식도 좋은 선택이 될 수 있다.

FastAPI Data Validation

알로그 — Sun, 15 Jan 2023 19:33:10 +0900

FastAPI Data Validation

유데미 FastAPI 강의 스터디를 진행하면서 내용을 정리해본다.

FastAPI - The Complete Course 2023 (Beginner + Advanced) (총 196강, 17시간)
https://www.udemy.com/course/fastapi-the-complete-course/

FastAPI - The Complete Course 2023 (Beginner + Advanced)

Dive in and learn FastAPI from scratch! Learn FastAPI, RESTful APIs using Python, SQLAlchemy, OAuth, JWT and way more!

www.udemy.com

Data Validation

Field를 이용해 min_length, max_length, gt, lt 등을 확용하여 validation 할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

from typing import Optional
from fastapi import FastAPI
from pydantic import BaseModel, Field
from uuid import UUID
 
app = FastAPI()
 
class Book(BaseModel):
    id: UUID
    title: str = Field(min_length=1)
    author: str = Field(min_length=1, max_length=100)
    description: Optional[str] = Field(title="Description of the book", 
                             max_length=100,
                             min_length=1)
    rating: int = Field(gt=-1, lt=101)
 
 
BOOKS = []
 
@app.get("/")
async def read_all_books():
    return BOOKS
 
@app.post("/")
async def create_book(book: Book):
    BOOKS.append(book)
    return book
Colored by Color Scripter

cs

BaseModel Configurations

Swagger 문서 내에 기본으로 스키마를 제공해줄 수 있다.

아래와 같이 BaseModel을 상속으로 받는 Book 클래스 내에 Config 클래스를 작성하면..

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class Book(BaseModel):
    id: UUID
    title: str = Field(min_length=1)
    author: str = Field(min_length=1, max_length=100)
    description: Optional[str] = Field(title="Description of the book", 
                             max_length=100,
                             min_length=1)
    rating: int = Field(gt=-1, lt=101)
 
    class Config:
        schema_extra = {
            "example": {
                "id": "fa9e694b-efb6-41b0-bdb6-606975d23290",
                "title": "Computer Science",
                "author": "hunk",
                "description": "A very nice description of a book",
                "rating": 70
            }
        }
Colored by Color Scripter

cs

Request Body에 아래와 같이 값이 기본으로 세팅된다.

FastAPI BaseModel

알로그 — Sat, 31 Dec 2022 09:47:53 +0900

FastAPI BaseModel

유데미 FastAPI 강의 스터디를 진행하면서 내용을 정리해본다.

FastAPI - The Complete Course 2023 (Beginner + Advanced) (총 196강, 17시간)
https://www.udemy.com/course/fastapi-the-complete-course/

FastAPI - The Complete Course 2023 (Beginner + Advanced)

Dive in and learn FastAPI from scratch! Learn FastAPI, RESTful APIs using Python, SQLAlchemy, OAuth, JWT and way more!

www.udemy.com

REST USES HTTP REQUEST METHODS

GET / => Get all the books
GET / <book UUID> => Get specific book
PUT / <book UUID> => Update specific book
POST / => Create new book
DELETE / <book UUID> => Delete specific book

BaseModel

pydantic: Data validation and settings management using Python type hints.

Type annotation을 통해 데이터 유효성 검사 목적으로 타입을 강제하고 타입이 유효하지 않은 경우 에러를 발생시킨다.

UUID(Universally Unique IDentifier)

고유성을 보장하는 ID로 DB의 primary key로 종종 사용된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

from fastapi import FastAPI
from pydantic import BaseModel
from uuid import UUID
 
app = FastAPI()
 
class Book(BaseModel):
    id: UUID
    title: str
    author: str
    description: str
    rating: int
 
 
BOOKS = []
 
@app.get("/")
async def read_all_books():
    return BOOKS
 
@app.post("/")
async def create_book(book: Book):
    BOOKS.append(book)
    return book

cs

Swagger Example Value에 아래와 같이 스키마 양식을 보여준다.

Curl에 -d (data)로 Request Body가 함께 요청됨을 볼 수 있다.

author를 제외하고 요청을 보내면 field required 메시지와 함께 422 오류 발생한다.

만약 author를 숫자로 13을 보내면 문자열 “13”으로 변경해서 요청된다.

남자 연예인 인스타 팔로워 순위

알로그 — Sat, 24 Dec 2022 17:20:22 +0900

남자연예인 인스타 팔로워

남자 연예인 인스타그램 팔로워 순위입니다.

BTS 압도적이네요.

여자 연예인 인스타 팔로워 순위

알로그 — Thu, 15 Dec 2022 22:30:30 +0900

여자연예인 인스타 팔로워

여자 연예인 인스타 팔로워 순위입니다.

역시 블랙핑크가 탑이네요.

AWS Certified Solutions Architect 오답정리

알로그 — Sun, 11 Dec 2022 14:27:28 +0900

AWS Certified Solutions Architect 오답정리

자격증을 준비하면서 문제풀이 중 정리할만한 내용을 기록해봄

S3에 수백만명 사용자 접속, 원본 부하 줄이기 위한 방법

=> S3 버킷앞에 CloudFront

AWS 계정에 대한 공격 방어

=> GuardDuty

데이터베이스 write가 drop되지 않도록 설정

=> Amazon Simple Queue Service(SQS) FIFO 대기열 사용

S3 버킷 사진 업로드 속도 향상

=> S3 Transfer Acceleration

다른 리전의 S3 버킷에 데이터 복사

=> S3 교차 리전 복제 구성

초당 수백만 요청 처리, 밀리 초 응답

=> Amazon DynamoDB

클릭스트림 데이터 전송 처리

=> Amazon Kinesis Data Streams

EC2, S3 간 비공개 보안 연결

=> VPC 엔드포인트를 통해 VPC와 S3간 연결 구성

온프레미스 데이터를 네트워크를 통해 AWS로 전송

=> AWS Data Sync

고가용성, 인메모리 데이터베이스

=> Redis용 Amazon ElastiCache

Amazon EMR 클러스터

=> 빅데이터 처리하기 위한 고성능 분산 병렬처리 시스템

Amazon EFS

=> 여러 가용영역의 EC2 인스턴스에서 동시 연결 가능, EBS는 단일 가용영역의 EC2만 연결

=> 여러 EC2에 하나의 EFS를 연결해 컨텐츠를 저장하여 변경사항 일관성을 가질 수 있음

AWS Lambda

=> 최대 15분까지만 실행 가능. 장기 실행 프로세스에 부적합

Transit Gateway

=> VPC, VPN을 하나의 Transit gateway로 연결하므로 중앙 관리형 네트워킹 설정 충족

인터넷 통하지 않고 S3 액세스

=> VPC 엔드포인트를 사용해서 S3에 프라이빗 연결

Global Accelerator

=> 글로벌 사용자에게 최적화된 경로 제공으로 라우팅 속도 빠르게

RedShift

=> SQL 쿼리 및 BI 도구 액세스

DynamoDB 일정 기간 데이터만 필요

=> TTL을 사용해 타임스탬프 유지시간 뒤 데이터 제거하도록 설정

AWS 서비스 (관리, 거버넌스, 보안, 컨테이너, 머신러닝 등)

알로그 — Sun, 4 Dec 2022 22:04:32 +0900

AWS 서비스

AWS Certified Solutions Architect 클라우드 자격증 취득 준비를 위해 AWS 서비스에 대해 요약 정리해본다.

AWS Console에서 서비스를 검색해보면 아래와 같이 많은 서비스가 있는데, 일부 중요한 서비스에 대해 알아보자.

2022.12.04 - [Web/Cloud] - AWS 서비스 (컴퓨팅, 스토리지, 데이터베이스, 네트워킹 및 컨텐츠 전송)

AWS 서비스 (컴퓨팅, 스토리지, 데이터베이스, 네트워킹 및 컨텐츠 전송)

AWS 서비스 정리 AWS Certified Solutions Architect 클라우드 자격증 취득 준비를 위해 AWS 서비스에 대해 요약 정리해본다. AWS Console에서 서비스를 검색해보면 아래와 같이 많은 서비스가 있는데, 일부 중

hungc.tistory.com

관리 및 거버넌스

IAM

계정 및 권한 관리 서비스 (글로벌 서비스)
사용자, 그룹, 역할, 정책
역할: 특정 AWS서비스가 다른 서비스에 액세스하여 작업을 수행할 때 필요한 권한
신뢰정책을 이용해서 다른 AWS 계정에 역할 위임 가능 (dev. prod 예제)

AWS Organizations

OU: 조직 단위로 그룹화하여 관리, Root OU
SCP: 서비스 제어 정책. 계정 또는 OU 단위로 적용

CloudWatch

AWS 리소스 상태 모니터링

CloudTrail

AWS계정이 수행하는 작업에 대해 로그 기록
기본으로 활성화되어 있음

Config

AWS 리소스 구성 변경사항을 로그기록하는 기능

System Manager

앱 및 인프라를 관리하는데 도움이 되는 기능 모음
애플리케이션 관리, 변경관리, 노드관리, 운영관리

보안, 자격증명 및 규정 준수

Certificate Manager

SSL/TLS 인증서를 중앙에서 관리하는 서비스

Shield

Standard는 기본적으로 적용됨

WAF(Web Application Firewall)

규칙에 기반해서 허용, 거부 가능

GuardDuty

위협 탐지 서비스
Macie: 민감한 데이터 검색 보호
Inspector: 취약성 관리 서비스

컨테이너 서비스

ECS(Elastic Container Service)

도커 컨테이너를 배포, 관리하는 컨테이너 오케스트레이션 서비스

EKS(Elastic Kubernetes Service)

Fargate

서버리스 컨테이너 서비스

ECR(Elastic Container Registry)

머신러닝

Comprehend: 텍스트에서 특정 항목을 찾아내는 서비스
Rekognition: 이미지, 비디오 분석
Polly: 텍스트 -> 음성
Lex: 음성인식, 챗봇
Textract: 스캔문서에서 문자, 테이블, 양식 추출
Translate: 번역
Transcribe: 음성 -> 텍스트
SageMaker: 머신러닝 모델 구축,훈련 및 배포
Forecast: 시계열 예측
Kendera: 지능형 검색
Personalize: 추천
Connect: 클라우드 기반 고객센터 서비스

애플리케이션 통합

Simple Queue Service(SQS)

표준, FIFO 중 선택
DLQ

Kinesis

실시간 스트리밍 데이터를 수집, 처리, 분석하는 서비스
Data Streams: 데이터 스트림을 캡처, 처리, 저장
Data Firehose: 스트리밍 데이터를 데이터 스토어와 분석도구에 로드
Data Analytics: SQL 또는 Apache Flink를 사용하여 스트리밍 데이터를 변환하고 분석

API Gateway

개발자가 API 생성, 게시, 유지관리, 모니터링, 보안 유지할 수 있게 하는 서비스

Amazon EventBridge

거의 실시간 이벤트 자동 전송 서비스

마이그레이션 및 전송

Snow Family

데이터를 네트워크가 아닌 물리적인 장치에 저장하여 전송할 수 있는 디바이스.
1회성 대용량 마이그레이션 용도

Data Sync

snowball과 달리 온라인으로 데이터 전송.
storage gateway와 달리 1회성 초기용 마이그레이션.

AWS 서비스 (컴퓨팅, 스토리지, 데이터베이스, 네트워킹 및 컨텐츠 전송)

알로그 — Sun, 4 Dec 2022 18:40:58 +0900

AWS 서비스

AWS Certified Solutions Architect 클라우드 자격증 취득 준비를 위해 AWS 서비스에 대해 요약 정리해본다.

AWS Console에서 서비스를 검색해보면 아래와 같이 많은 서비스가 있는데, 일부 중요한 서비스에 대해 알아보자.

컴퓨팅

EC2 (Elastic Compute Cloud)

가상 서버로 가장 많이 쓰는 서비스 중 하나
On-Demand Instance: 사용한만큼 지불
Reserved Instance: 1년 또는 3년 약정. 저렴하며 예측가능한 경우 사용
Saving Plans: 1년 또는 3년 기간에 특정 사용량 약정. 시간당 $5 약정하면 $5까진 Saving 그 이후 On-Demand
Spot Instance: 사용하지 않는 예비 EC2 용량을 경매방식으로 구매
보안그룹: 인바웃드 및 아웃바운드 트래픽 제어하는 가상 방화벽 역할. ENI와 연결됨. 허용규칙만 지정가능. 인바운드 허용이면 아웃바운드는 자동허용

EC2 Auto Scaling

EC2의 규모가 자동으로 조절되는 서비스로 최소 용량, 원하는 용량, 최대 용량을 정할 수 있음
오토스케일링 그룹, 시작템플릿
조정 정책: 현재 인스턴스 수준 관리, 수동 조정, 일정 기반 조정, 온디맨드 기반 조정, 예측 조정
수명주기 후크

Lambda

코드를 실행하여 동작하는 서버리스(서버를 사용자가 관리할 필요가 없음) 컴퓨팅
온디맨드 방식의 이벤트 중심 실행. 자동으로 용량 확장되므로 확장성이 뛰어나며 다양한 프로그래밍 언어 지원

스토리지

S3(Simple Storage Service)

데이터 저장 방식은 오브젝트 스토리지(식별자, 키 이용), 블록 스토리지, 파일 스토리지가 있는데 S3는 오브젝트 스토리지에 해당함
버킷(=project)과 객체(file)로 구성. 버킷은 리전 단위 생성이고 유니크해야함
버킷 정책(json), 퍼블릭 액세스 차단, ACL(액세스 제어 목록) 관리
버전 관리 가능. 암호화 가능
정적 웹사이트 호스팅 가능
Replication (복제 규칙), 버전관리 되어 있어야 함
HTTP Referer(어디서 접속했는지), 버저닝, 수명주기 관리 가능(오래 된 객체 스토리지 클래스 낮추거나 삭제)
S3 Glacier, S3 Glacier Deep Archive: 데이터 아카이브 용도

EFS(Elastic File System)

리눅스 전용 네트워크 파일 스토리지
NFS 프로토콜 지원
여러 가용영역 가능, 보안그룹 통해 연결
표준스토리지(3개 가용영역), 표준IA, One Zone, One Zone IA

EBS(Elastic Block Storage)

EC2와 연결하는 저장장치
HDD, SSD 등 선택.
스냅샷 기능 있음, 스냅샷으로 이미지(AMI) 생성 가능
하나의 볼륨은 하나의 EC2랑 연결 가능.

FSx

리눅스 환경을 위한 고성능 병렬 스토리지 시스템
분산파일 시스템
FSx for Windows File Server: SMB 프로토콜

Storage Gateway

온프레미스 데이터센터의 데이터와 클라우드 스토리지 연결

AWS Backup

중앙 집중식 백업 관리 서비스

데이터베이스

RDS(Relational Database Service)

기존 앱, 전사적 자원 관리(ERP), 고객 관계 관리(CRM), 전자 상거래 등에 사용
Aurora, RDS, Redshift, PostgreSQL, MySQL 등

NoSQL

높은 트래픽 웹, 전자 상거래, 게임 등에 사용
DynamoDB

인메모리 데이터베이스

디스크가 아닌 주 메모리에 데이터 저장. 속도가 빠름
Elasticashe, MemoryDB for Redis

기타

문서: DocumentDB(MongoDB 호환)
와이드 컬럼: Keyspaces
그래프: Neptune
시계열: Timestream
원장: Ledger Database Services(QLDB)

네트워킹 및 컨텐츠 전송

VPC(Virtual Private Cloud)

가상네트워크, 기본 VPC 네트워크는 인터넷과 연결되어 있고 EC2를 생성하면 기본 VPC에 연결됨
CIDR(Classless Inter-Domain Routing): IP 주소 범위를 정의하는 방식. 192.168.32.1/24 -> 24는 서브넷 마스크. IP대역을 24비트로 나눈것(32.0~32.255)
Private IP 대역 사용 (10, 172, 192)
기본 VPC, CIDR 방식으로 IP 할당, VPC 내에 서브넷이 할당되어 있고 IP가 할당됨. EC2가 생성되면 해당 서브넷에 할당. 서브넷은 라우팅테이블에 연결되어 있고 igw가 연결되어 있음
NACL은 개별 EC2가 아닌 서브넷 단위로 설정

Route 53

DNS 서비스, 라우팅 정책 적용 가능
TTL: Time To Live. DNS를 재요청하는 시간
Simple, Weidgted Routing Policy
Latency Routing Policy (리전 설정 후 가까운 지연 시간으로)
Failover Routing Policy (상태 검사 생성 후 장애조치 및 기본 보조로 설정)

CloudFront

컨텐츠 전송 네트워크 서비스(CDN)
엣지 로케이션(캐시 서버)의 콘텐츠 캐싱을 이용해 사용자에게 더 빨리 서비스 가능
EC2등 오리진 서버 부하 줄일 수 있음
사용자 요청 헤더 값에 따라 다른 버전 컨텐츠 제공 가능
3가지 가격 등급 존재
고가용성을 위한 Origin Group. 기본 오리진이 실패하면 보조 오리진으로 전환
보안 액세스 - Signed URL, Signed Cookies, 지역 제한, 필드 레벨 암호화(오리진 서버로 안전하게 전송)

Global Accelerator

고정된 IP주소 사용, 가장 가까운 리전의 엔드포인트로 최적화된 경로 찾는데 사용
TCP/UDP 프로토콜 적합(UDP 기반 게임, VoIP, 모바일 앱 등)

2022년 넷플릭스 인기 TV프로그램 순위

알로그 — Mon, 28 Nov 2022 23:15:21 +0900

넷플릭스 TV프로그램 순위

2022년 넷플릭스 TV프로그램 전세계 순위입니다.

넷플릭스 볼만한거 찾던 분에게 유용할만한 영상입니다.

데이터는 Flixpatrol에서 크롤링으로 가져와서 영상을 만들었습니다.

#넷플릭스 순위 #넷플릭스 인기순위 #넷플릭스순위 #넷플릭스인기순위 #netflix #netflix rank

About Me

알로그 — Mon, 10 Oct 2022 13:42:00 +0900

VSCODE 주석 단축키 오류

알로그 — Mon, 10 Oct 2022 00:52:42 +0900

가끔 Visual Studio Code에서 주석 단축키가 안 먹히고 '/' 만 입력되는 경우가 있는데 한국어 입력키와 관련이 있다.

CTRL + SHIFT 를 누른 상태에서 SHIFT만 떼면 정상동작된다.

파이썬 코루틴(coroutine)

알로그 — Sun, 2 Oct 2022 16:17:42 +0900

파이썬 코루틴(coroutine)

파이썬 비동기 함수는 코루틴 함수로 만들 수 있다.

코루틴은 진입점과 탈출점이 여러 개가 있는 함수라고 할 수 있다.

파이썬 코루틴 공식 홈페이지에 있는 예제를 살펴보면 asyncio API에 대해 설명하고 있다.

다음 코드는 "hello"를 인쇄하고 1초를 기다린 다음 "world"를 인쇄한다.

import asyncio

async def main():
    print('hello')
    await asyncio.sleep(1)
    print('world')

asyncio.run(main())

코루틴 함수를 만들기 위해는 함수 앞에 async 키워드를 붙여주면 된다.

await는 어웨이터블 객체만 사용할 수 있으며, 코루틴 내에서 다른 코루틴을 호출하고 결과를 받을 때 사용된다.

import asyncio
import time

async def say_after(delay, what):
    await asyncio.sleep(delay)
    print(what)

async def main():
    print(f"started at {time.strftime('%X')}")

    await say_after(1, 'hello')
    await say_after(2, 'world')

    print(f"finished at {time.strftime('%X')}")

asyncio.run(main())

약 3초가 걸린다.

위의 코드는 단순 코루틴을 호출하는 것이지 여러 코루틴을 동시에 실행하는 것은 아니다.

asyncio.create_task()로 태스크를 실행하도록 예약해야 한다.

import asyncio
import time

async def say_after(delay, what):
    await asyncio.sleep(delay)
    print(what)

async def main():
    task1 = asyncio.create_task(say_after(1, 'hello'))
    task2 = asyncio.create_task(say_after(2, 'world'))

    print(f"started at {time.strftime('%X')}")

    # await say_after(1, 'hello')
    # await say_after(2, 'world')

    await task1
    await task2

    print(f"finished at {time.strftime('%X')}")

asyncio.run(main())

2초로 줄어드는 걸 볼 수 있다.

asyncio.gather로 여러 태스크를 한번에 등록할 수 있다.

다른 예제를 살펴보자.

네이버, 구글, 인스타그램을 각각 10번씩 요청해서 그에 대한 응답을 가져오는데, 약 10초정도 소요된다.

import requests
import time


def fetcher(session, url):
    with session.get(url) as response:
        return response.text


def main():
    urls = ["https://naver.com", "https://google.com",
            "https://instagram.com"] * 10

    with requests.Session() as session:
        result = [fetcher(session, url) for url in urls]
        print(result)


if __name__ == "__main__":
    start = time.time()
    main()
    end = time.time()
    print(end - start)

위의 코드를 비동기 코드로 변경해보자.

우선 aiohttp 패키지가 필요하므로 이를 pip를 이용해서 설치하고 변경하면 아래와 같다.

import aiohttp
import time
import asyncio


async def fetcher(session, url):
    async with session.get(url) as response:
        return await response.text()


async def main():
    urls = ["https://naver.com", "https://google.com", "https://instagram.com"] * 10

    async with aiohttp.ClientSession() as session:
        result = await asyncio.gather(*[fetcher(session, url) for url in urls])
        print(result)


if __name__ == "__main__":
    start = time.time()
    asyncio.run(main())
    end = time.time()
    print(end - start)

약 3초정도 걸린다.

적절한 때에 비동기 형태로 코드를 구성하면 많은 시간을 단축할 수 있다.

References:

https://docs.python.org/ko/3/library/asyncio-task.html

코루틴과 태스크 — Python 3.10.7 문서

코루틴과 태스크 이 절에서는 코루틴과 태스크로 작업하기 위한 고급 asyncio API에 관해 설명합니다. Coroutines declared with the async/await syntax is the preferred way of writing asyncio applications. For example, the follo

docs.python.org

https://github.com/amamov/teaching-async-python

GitHub - amamov/teaching-async-python: [인프런] 파이썬 동시성 프로그래밍 (feat. FastAPI)

[인프런] 파이썬 동시성 프로그래밍 (feat. FastAPI). Contribute to amamov/teaching-async-python development by creating an account on GitHub.

github.com

Kubernetes Architecture

알로그 — Sun, 10 Jul 2022 18:02:59 +0900

컨트롤 플레인 컴포넌트

kube-apiserver: 쿠버네티스 API를 노출하는 쿠버네티스 컴포넌트
etcd: 모든 클러스터 데이터를 담는 키-값 저장소
kube-scheduler: 노드가 배정되지 않은 새로 생성된 파드를 감지하고 실행할 노드를 선택하는 컴포넌트
kube-controller-manager: 노드 컨트롤러, 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 서비스 어카운트, 토큰 컨트롤러를 포함한다.
cloud-controller-manager: 클라우드별 컨트롤 로직을 포함하는 컴포넌트

노트 컴포넌트

kubelet: 각 노드에서 실행되는 에이전트. 파드에서 컨테이너가 확실하게 동작하도록 관리
kube-proxy: 각 노드에서 실행되는 네트워크 프록시로 서비스 개념의 구현부
컨테이너 런타임: 컨테이너 실행을 담당하는 소프트웨어

마스터 노드에는 etcd, kube-scheduler, kube-apiserver가 존재하고 이는 /etc/kubernetes/manifests에 각각 해당하는 yaml 파일이 존재한다.

워커 노드에는 kubelet과 container runtime이 구성되어 있으며, 데몬셋인 kube-proxy가 구성되어 있다.

파드 생성 과정

요청자가 kubectl create 명령어로 파드 생성 요청
kube-apiserver로 전달되며, etcd에 pod에 대한 이력정보를 저장
kube-scheduler는 수시로 각각의 노드 자원을 수집하고 있으며, kube-apiserver에 watch 기능으로 etcd에 파드 생성요청이 왔는지 모니터링 후 노드 자원 상태를 확인한 후 etcd 파드에 노드정보를 추가
kubelet도 kube-apiserver에 watch가 걸려있고 자신의 노드가 붙어있는 파드를 발견하면 정보를 가져와서 파드를 생성하고자 함
kubelet이 container runtime에 컨테이너를 생성하라고 요청
kubelet은 kube-proxy한테 네트워크 생성요청을 하고 kube-proxy가 통신이 되도록 설정

디플로이먼트 생성 과정

kube-controller-manager.yaml 파일에 의해 Controller Manager가 존재하며 여러 컨트롤러가 각 스레드로 도는중
요청자가 kubectl create 명령어로 디플로이먼트(replicas:2) 생성 요청
kube-apiserver로 전달되며, etcd에 정보를 저장
Controller Manager의 Deployment가 kube-apiserver에 watch로 모니터링 중이며, 레플리카셋을 생성하라고 요청함
ReplicaSet도 watch가 걸려있어 감지 후 파드를 생성하라고 요청
kube-scheduler는 수시로 각각의 노드 자원을 수집하고 있으며, kube-apiserver에 watch 기능으로 etcd에 파드 생성요청이 왔는지 모니터링 후 노드 자원 상태를 확인한 후 etcd 파드에 노드정보를 추가
kubelet도 kube-apiserver에 watch가 걸려있고 자신의 노드가 붙어있는 파드를 발견하면 정보를 가져와서 파드를 생성하고자 함
kubelet이 container runtime에 컨테이너를 생성하라고 요청
kubelet은 kube-proxy한테 네트워크 생성요청을 하고 kube-proxy가 통신이 되도록 설정

References:

https://kubernetes.io/ko/docs/concepts/overview/components/

쿠버네티스 컴포넌트

쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 컴포넌트로 구성된다.

kubernetes.io

https://kubetm.github.io/k8s/09-intermediate-architecture/component/

쿠버네티스 (Kubernetes) 배포를 위한 고급 설정

알로그 — Sun, 26 Jun 2022 00:48:10 +0900

쿠버네티스는 클러스터 내부에서 컴퓨팅 자원 활용률(Utilization)을 늘리는 것이 중요하다.

컨테이너와 포드의 자원 사용량 제한: Limit, Request

apiVersion: v1
kind: Pod
metadata:
  name: resource-limit-with-request-pod
  labels:
    name: resource-limit-with-request-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
  resources:
    limits:
      memory: "256Mi"
      cpu: "1000m"
    requests:
      memory: "128Mi"
      cpu: "500m"

- 참고: cpu 1개를 뜻하는 1000m(밀리코어)

requests는 적어도 이만큼의 자원은 컨테이너에게 보장되어야 한다라는 의미이며 limits은 최대사용량

즉 위에서는 최소 128Mi 메모리 사용은 보장되지만 유휴 메모리 자원이 있다면 최대 256Mi까지 사용할 수 있다란 의미

QoS 클래스와 메모리 자원 사용량 제한 원리

CPU 사용량에 경합이 발생하면 throttle이 발생하지만 컨테이너 자체에는 문제가 발생하지 않는다.
하지만 메모리는 incompressible 자원으로 경합이 발생하면 우선순위가 낮은 포드 또는 프로세스가 종료된다.

강제 종료된 포드는 다른 노드로 옮겨가게 되는데, 이를 퇴거(Eviction)이라고 표현한다.

쿠버네티스는 포드의 우선순위를 구분하기 위해 3가지 종류의 QoS(Quality of Service) 클래스를 명시적으로 포드에 설정한다. 우선순위는 OOM(Out Of Memory) 값으로 설정되며 OOM 점수가 높을수록 우선순위가 낮아져 강제종료된다.

각 클래스는 kubectl describe 명령어로 확인 가능

Guaranteed 클래스 - Limit과 Request의 값이 동일할 때 부여되는 클래스. Requests를 생략하면 Limit으로 동일하게 설정되며 이 경우 OOM 점수는 -998로 설정된다.
Burstable 클래스 - Limit의 값이 Request보다 큰 포드를 의미함.
BestEffort 클래스 - Limit과 Request를 아예 설정하지 않은 포드에 설정되는 클래스.

기본적으로 Guaranteed가 우선순위가 가장 높으며, 그 뒤로 Burstable와 BestEffort 순이다.

따라서 노드에 메모리가 부족하면 BestEffort 클래스 포드 먼저 종료된다.

하지만 메모리 사용량에 따라 우선순위가 역전될 수도 있는데, 메모리를 많이 사용하면 사용할수록 우선순위가 낮아진다.

ResourceQuota로 네임스페이스의 자원 사용량 제한

네임스페이스에서 할당할 수 있는 자원의 총합을 제한할 수 있음
네임스페이스에서 생성할 수 있는 리소스의 개수를 제한할 수 있음

ResourceQuota와 LimitRange는 namespace 에서 이미 살펴봤으므로 간단하게 넘어가자.

$ kubectl get quota
$ kubectl describe quota

리소스 개수를 제한하려면 count/<오브젝트이름>을 명시

scope로 BestEffort 클래스의 포드 개수 제한 가능

LimitRange로 자원 사용량 제한

포드의 컨테이너에 CPU나 메모리 할당량이 설정돼 있지 않은 경우, 컨테이너에 자동으로 기본 Request 또는 Limit 값을 설정할 수 있음
포드 또는 컨테이너의 CPU, 메모리, 퍼시스턴트 볼륨 클레임 스토리지 크기의 최소값/ 최대값 설정 가능

쿠버네티스 스케줄링

스케줄링에 관여하는 컴포넌트는 kube-scheduler와 쿠버네티스 클러스터의 전반적인 상태 데이터를 저장하는 일종의 데이터베이스인 etcd이다.

스케줄링 종류

nodeName (노드명 지정, 그러나 노드가 삭제되면 이름이 바뀌기 때문에 유의)
nodeSelector (키, 값이 있는 노드로 지정, 그러나 매칭이 되는 라벨이 없으면 어느 노드에도 매칭이 안됨)
nodeAffinity (키만 설정해도 자원이 많은 노드에 설정됨. 매칭이 안 되어도 스케줄러가 자원이 많은 노드에 매칭가능)
podAffinity (관련 파드가 같은 노드에 매칭이 되어야 하는 경우에 사용, ex. PV)
podAntiAffinity (관련 파드가 다른 노드에 매칭이 되어야 하는 경우에 사용, ex. master-slave)

노드 라벨 생성 명령어

$ kubectl label nodes k8s-node1 kr=az-1
$ kubectl label nodes k8s-node2 us=az-1

Taints와 Tolerations를 이용한 포드 스케줄링

Taints는 특정 노드에 얼룩(Taint)을 지정함으로써 해당 노드에 포드가 할당되는 것을 막는 기능이며, 이에 대응하는 Tolerations를 포드에 설정하면 Taints가 설정된 노드에도 포드를 할당할 수 있다.

쿠버네티스는 기본적으로 다양한 Taints를 노드에 설정한다.

지금까지 포드를 생성하면 기본적으로 마스터 노드가 아닌 워커 노드에 할당됐는데, 이는 기본적으로 마스터 노드에 Taints NoSchedule이 설정되어 있기 때문이다. 장애가 발생한 경우엔 NoExecute로 다른 노드에 설정되게끔 한다.

Taints 효과에는 NoSchedule(포드를 처음 매칭할 때 스케줄링하지 않음), NoExecute(포드의 실행 자체를 허용하지 않음), PreferNoSchedule(가능하면 스케줄링하지 않음) 총 3가지가 있다.

$ kubectl taint node ip-10-43-0-30.ap-northeast-2.compute.internal alicek106/your-taint=your-taint-value:NoExecute

포드가 디플로이먼트나 레플리카셋 등과 같은 리소스로 생성됐다면 NoExecute에 의해 포드가 종료됐더라도 포드는 다른 노드로 옮겨가는 퇴거(Eviction)가 발생한다.

또한 쿠버네티스는 특정 문제가 발생한 노드에 대해서는 자동으로 Taint를 추가한다.

대표적으로 아직 노드가 준비되지 않은 상태(NotReady), 네트워크가 불안정한 상태(Unreachable), 메모리 부족(memory-pressure)이나 디스크 공간 부족(disk-pressure)에 대한 Taint 등이 있다.

cordon을 이용한 스케줄링 비활성화

cordon 명령어로 지정된 노드는 새로운 포드가 할당되지 않는다.

$ kubectl cordon ip-10-43-0-30.ap-northeast-2.compute.internal

kubectl get nodes 명령어로 STATUS 항목 확인 가능

drain 명령어로 노드 비활성화

drain은 cordon처럼 해당 노드에 스케줄링을 금지한다는 것은 같지만, 노드에서 기존에 실행중이던 포드를 다른 노드로 옮겨가도록 퇴거(Eviction)를 수행한다는 점이 다르다.

$ kubectl drain ip-10-43-0-30.ap-northeast-2.compute.internal

PodDisruptionBudget으로 포드 개수 유지

kubectl drain 명령어 등으로 포드에 퇴거가 발생할 때, 특정 개수 또는 비율만큼의 포드는 반드시 정상적인 상태를 유지하기 위해 사용된다.

$ kubectl get pdb

<simple-pdb-example.yaml>

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: simple-pdb-example
spec:
  maxUnavailable: 1 # 비활성화될 수 있는 포드의 최대 개수 또는 비율
  # minAvailable: 2
  selector:
    matchLabels:
      app: webserve

커스텀 스케줄러 및 스케줄러 확장

포드를 생성하면 기본적으로 기본 스케줄러(kube-scheduler)를 사용하게 된다.

추가로 본인이 스케줄러를 구현해서 사용할 수도 있다.

쿠버네티스 애플리케이션 상태와 배포

간단히 사용하기에는 kubectl apply -f 명령어도 나쁜 방법은 아니지만 좀 더 고도화된 배포방식을 원한다면 Spinnaker, Helm, Kustomize 또는 ArgoCD나 Jenkins와 같은 CD 도구를 사용할 수 있다.

디플로이먼트를 이용한 레플리카셋의 버전 관리

--record 옵션을 추가해 디플로이먼트의 변경사항을 적용하면 이전에 사용하던 레플리카 셋의 정보는 디플로이먼트 히스토리에 기록된다.

$ kubectl apply -f deployment-v1.yaml --record
$ kubectl apply -f deployment-v2.yaml --record
$ kubectl rollout history deployment nginx-deployment

배포중에 애플리케이션이 중단돼도 괜찮은 경우는 ReCreate 방법을 사용할 수 있다.

<deployment-recreate.yaml>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-recreate
spec:
  replicas: 3
  strategy:
    type: Recreate

하지만 이를 허용하지 않았을때는 ReCreate 방식은 적절하지 않으며, 쿠버네티스에서는 포드를 조금씩 삭제하고 생성하는 롤링 업데이트 기능을 제공한다. 별도의 설정하지 않아도 롤링 업데이트를 사용하도록 설정돼있음

...
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 2
...

maxUnavailable: 롤링 업데이트 도중 사용 불가능한 상태가 되는 포드의 최대 개수 설정
maxSurge: 롤링 업데이트 도중 전체 포드의 개수가 디플로이먼트의 replicas 값보다 얼마나 더 많이 존재할 수 있는지 설정

블루그린 배포

기존 버전의 포드를 그대로 놔둔 상태에서 새로운 버전의 포드를 미리 생성해 둔 뒤 서비스의 라우팅만 변경하는 배포 방식

특정 순간에는 디플로이먼트에 설정된 replicas 개수의 두 배에 해당하는 포드가 실행되기 때문에 자원을 많이 소모할 수 있다.

참고)

포드의 생애 주기(Lifecycle)

Pending: 포드를 생성하는 요청이 API 서버에 의해 승인됐지만, 문제가 발생해서 생성되지 않은 상태
Running: 정상적으로 실행
Completed: 포드가 정상적으로 실행돼 종료됐음을 의미함. 포드 컨테이너의 init 프로세스가 종료 코드로 0을 반환
Error: 포드가 정상적으로 실행되지 않은 상태로 종료됐음을 의미. init 프로세스가 0이 아닌 종료 코드 반환
Terminating: 포드가 삭제 또는 퇴거 되기 위해 삭제 상태에 머물러있는 경우에 해당

포드의 재시작 정책을 설정하는 restartPolicy는 기본적으로 Always로 설정되어 있고 포드의 컨테이너가 종료되면 자동으로 재시작한다. restartPolicy 값을 Never로 설정하면 재시작하지 않는다.

Running 상태가 되기 위한 조건

포드가 Running 상태에 머물러 있다고 해서 컨테이너 내부의 애플리케이션이 제대로 동작하고 있을 것이란 보장은 없다.

쿠버네티스는 다음과 같은 기능을 제공함

- InitContainer

- postStart

- livenessProbe, readinessProbe

apiVersion: v1
kind: Pod
metadata:
  name: init-container-example
spec:
  initContainers: # 초기화 컨테이너를 항목에 정의합니다.
    - name: my-init-container
      image: busybox
      command: [" sh" , "-e" , "echo Hello World!"]
  containers: # 애플리케이션 컨테이너를 항목에 정의합니다.
    - name: nginx
      image: nginx

포드의 컨테이너가 실행되거나 삭제될 때, 특정 작업을 수행하도록 훅을 정의할 수 있다.

컨테이너가 시작될 때 실행되는 postStart와 종료될 때 실행되는 preStop 이다.

apiVersion: v1
kind: Pod
metadata:
  name: poststart-hook
spec:
  containers:
    - name: poststart-hook
      image: nginx
      lifecycle:
        postStart:
          exec:
            command: ["sh", "-c", "touch /myfile"]

postStart 명령이나 HTTP 요청이 제대로 실행되지 않으면 컨테이너는 Running 상태로 전환되지 않으며, Init 컨테이너와 마찬가지로 restartPolicy에 의해 해당 컨테이너가 재시작된다. 또한 시간이 오래 걸리면 그만큼 Running 상태까지 도달하는 시간이 길어질 수 있다.

애플리케이션의 상태 검사, livenessProbe, readinessProbe

Init 컨테이너나 postStart 훅이 정상적으로 실행됐다고 해서 애플리케이션이 제대로 동작하고 있다고 보장할 수 없다.

livenessProbe: 컨테이너 내부의 애플리케이션이 살아있는지 검사. 실패인 경우 restartPolicy에 의해 재시작
readinessProbe: 컨테이너 내부의 애플리케이션이 사용자 요청을 처리할 준비가 됐는지 검사. 실패할 경우 컨테이너는 서비스의 라우팅 대상에서 제외됨

apiVersion: v1
kind: Pod
metadata:
  name: livenessprobe-pod
spec:
  containers:
    - name: livenessprobe-pod
      image: nginx
      livenessProbe: # 컨테이너에 대해 livenessProbe 정의합니다.
        httpGet: # HTTP 요청을 통해 애플리케이션의 상태를 검사합니다.
        port: 80 # <포드으 IP):801 경로를 통해 헬스 체크 요청을 보냄니다.
        path: /

3가지 방식이 있으며 httpGet, exec, tcpSocket 등이 있다.

위에서 파드를 생성한 후, 일부러 index.html 파일을 삭제해서 livenessProbe가 실패하도록 유도하면

시간이 지난 뒤 포드의 RESTARTS 횟수가 증가하고 컨테이너가 재시작함으로써 Nginx 서버의 index.html 파일이 원래대로 돌아오기 때문에 livenessProbe는 다시 성공하게 됨 (describe 명령어로 확인 가능)

<readinessprobe-pod-svc.yaml>

apiVersion: v1
kind: Pod
metadata:
  name: readinessprobe-pod
  labels:
    my-readinessprobe: test
spec:
  containers:
    - name: readinessprobe-pod
      image: nginx              # Nginx 서버 컨테이너를 생성합니다.
      readinessProbe:           # <포드의 IP):80/ 상태 검사 요청을 전송합니다.
        httpGet:
          port: 80
          path: /

---
apiVersion: v1
kind: Service
metadata:
  name: readinessprobe-svc
spec:
  ports:
    - name: nginx
      port: 80
      targetPort: 80
  selector:
    my-readinessprobe: test
  type: ClusterIP

파드를 생성한 후 엔드포인트 리소스 목록을 확인해보면 서비스로 접근하는 요청이 포드의 IP로 라우팅되고 있는것을 볼 수 있음

$ kubectl get endpoints

마찬가지로 고의적으로 index.html 파일을 삭제하면 livenessProbe와 달리 RESTARTS 횟수가 증가하지 않고 단순히 READY 상태인 컨테이너가 하나 줄어든다.

readinessProbe가 실패했기 때문에 컨테이너가 준비되지 않았다고 간주하며 서비스 리소스는 사용자 요청을 이 포드로 전달하지 않는다.

엔드포인트 리소스 목록을 확인해보면 라우팅 대상에서 포드의 IP가 제거되어 있다.

세부옵션

periodSeconds :상태 검사를 진행할 주기를 설정합니다. 기본값은 10초
initialDelaySeconds: 포드가 생성된 상태 검사를 시작할 때까지의 대기 시간을 설정합니다. 기본적으로는 설정돼 있지 않음
timeoutSeconds :요청에 대한 타임이웃 시간을 설정합니다. 기본값은 1초
successThreshold: 상태 검사에 성공했다고 간주할 검사 성공 횟수를 설정합니다. 기본값은 1
failureThreshold: 상태 검사가 실패했다고 간주할 검사 실패 횟수를 설정합니다. 기본값은 3

명령어 Tip)

$ kubectl get events -w | grep [pod 이름]                                      # 파드 이벤트 확인
$ kubectl describe pod [pod 이름] | grep -A5 Conditions              # 파드 컨디션 확인

Terminating 상태와 애플리케이션의 종료

apiVersion: v1
kind: Pod
metadata:
  name: prestop-hook
spec:
  containers:
    - name: prestop-hook
      image: nginx
      lifecycle:
        preStop:
          exec:
            command: ["/usr/sbin/nginx", "-s", "quit"]

preStop 훅이 실행되고나면 포드의 컨테이너들에게 SIGTERM 시그널을 보냄으로써 포드가 곧 종료될 것이라고 알린다.

이때 애플리케이션의 소스코드에서는 SIGTERM 시그널을 수신했을 때 어떤 행동을 취할 것인지 별도로 구현해야 한다.

만약 포드 내부의 애플리케이션이 SIGTERM을 수신했는데도 특정 유예 시간 이내에 종료되지 않으면 쿠버네티스는 SIGKILL 시그널을 전송해 강제로 프로세스를 종료하게 된다. (기본 30초이며 terminationGracePeriodSeconds 값을 통해 조정 가능)

References:

https://kubetm.github.io/k8s/04-beginner-controller/deployment/

Deployment

Recreate, RollingUpdate

kubetm.github.io

SonarQube on Kubernetes

알로그 — Sat, 25 Jun 2022 14:14:48 +0900

SonarQube on Kubernetes

Azure에서 쿠버네티스를 기반으로 SonarQube를 적용해보자.

PersistentVolumeClaim 생성

data와 plugin 저장을 위한 2개 PVC 생성

<sonar-data.yaml>

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sonar-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: default
  resources:
    requests:
      storage: 31Gi

<sonar-extension.yaml>

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sonar-extensions
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: default
  resources:
    requests:
      storage: 31Gi

시크릿 생성

PostgreSQL 패스워드 저장을 위한 Secret 생성

<sonar-secret.yaml>

apiVersion: v1
kind: Secret
metadata:
  name: postgres
type: Opaque
data:
  password: aHVuZ3Bvc3RncmVz

디플로이먼트 생성

<sonar-deployment.yaml>

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: sonarqube
  name: sonarqube
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sonarqube
  template:
    metadata:
      labels:
        app: sonarqube
    spec:
      containers:
        - name: sonarqube
          image: sonarqube:latest
          volumeMounts:
            - mountPath: "/opt/sonarqube/data/"
              name: sonar-data
            - mountPath: "/opt/sonarqube/extensions/"
              name: sonar-extensions
          env:
            - name: "SONARQUBE_JDBC_USERNAME"
              value: "hung"
            - name: "SONARUQBE_JDBC_URL"
              value: jdbc:postgresql://sonar-postgres:5432/sonar
            - name: "SONARQUBE_JDBC_PASSWORD"
              valueFrom:
                secretKeyRef:
                  name: postgres
                  key: password
          ports:
            - containerPort: 9000
              protocol: TCP
      volumes:
        - name: sonar-data
          persistentVolumeClaim:
            claimName: sonar-data
        - name: sonar-extensions
          persistentVolumeClaim:
            claimName: sonar-extensions

서비스 생성

<sonar-svc.yaml>

apiVersion: v1
kind: Service
metadata:
  labels:
    app: sonarqube
  name: sonarqube
spec:
  ports:
    - name: sonar
      port: 80
      protocol: TCP
      targetPort: 9000
  selector:
    app: sonarqube
  type: LoadBalancer

위 external-ip로 서비스 접속 확인

References:

https://medium.com/@akamenev/running-sonarqube-on-azure-kubernetes-92a1b9051120

Running SonarQube on Kubernetes

medium.com

쿠버네티스 워커노드 초기화

알로그 — Sun, 12 Jun 2022 12:11:23 +0900

$ kubeadm reset

명령어를 수행하면 아래와 같이 메시지가 나오고 메뉴얼대로 /etc/cni/net.d 삭제할 것

google-cloud-sdk 설치

알로그 — Mon, 23 May 2022 10:58:00 +0900

google-cloud-sdk 설치

echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] http://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -

sudo apt-get update

sudo apt-get install google-cloud-sdk

여의도 오마카세 스시코하루

알로그 — Sat, 21 May 2022 19:19:47 +0900

여의도 오마카세 스시코하루

서울 영등포구 국제금융로8길 27-9 지하 1층 101호

캐치테이블로 예약 필요

입구

내부

계란찜

전복과 전복내장

숙성시킨 광어

참돔

참치중뱃살

한치

단새우 with 우니크림

간장에 절인 참치속살

잿방어

줄무늬 전갱이

청어

홍새우

고등어봉초밥

간장에 절인 삼치

연근, 새우튀김 고로케

뭐였지?

지라시스시 with 아귀간

바다장어

쿠버네티스(Kubernetes) PV, PVC

알로그 — Fri, 20 May 2022 18:08:08 +0900

쿠버네티스(Kubernetes) PV, PVC

여태껏 각 포드는 별도의 데이터를 갖고 있지 않았고 단순히 요청에 대한 응답만을 반환했다.

DB처럼 포드 내부에서 특정 데이터를 보유해야 하는 상태가 있는(stateful) 애플리케이션의 경우 데이터를 어떻게 관리해야 할지 고민해야 한다.

MySQL 디플로이먼트를 통해 포드를 생성했더라도 디플로이먼트를 삭제하면 포드도 함께 삭제되고 데이터도 함께 삭제된다. 이를 해결하기위해 쿠버네티스에서도 호스트에 위치한 디렉토리를 각 포드와 공유함으로써 데이터를 보존하는 것이 가능하다.

로컬볼륨: hostPath, emptyDir

hostPath는 호스트와 볼륨을 공유하기 위해 사용하고 emptyDir은 포드의 컨테이너 간에 볼륨을 공유하기 위해 사용함

워커 노드의 로컬 디렉터리를 볼륨으로 사용: hostPath

포드의 데이터를 보존할 수 있는 가장 간단한 방법은 호스트의 디렉터리를 포드와 공유하는 것

<hostpath-pod.yaml>

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-pod
spec:
  containers:
    - name: my-container
      image: busybox
      args: [ "tail", "-f", "/dev/null" ]
      volumeMounts:
      - name: my-hostpath-volume
        mountPath: /etc/data
  volumes:
    - name: my-hostpath-volume
      hostPath:
        path: /tmp

volumes 항목에 볼륨을 정의한 뒤, 이를 containers 항목에서 참조해서 사용함

호스트의 /tmp를 포드의 /etc/data에 마운트 함

$ kubectl apply -f hostpath-pod.yaml  
$ kubectl exec -it hostpath-pod touch /etc/data/mydata

포드가 생성된 워커 노드로 접속한 뒤, /tmp 디렉터리를 확인하면 확인 가능함

참고) volumes.hostPath.type에 DirectoryOrCreate를 명시하면 실제 경로가 없다면 새로 생성함

DirectoryOrCreate : 실제 경로가 없다면 생성
Directory : 실제 경로가 있어야됨
FileOrCreate : 실제 경로에 파일이 없다면 생성
File : 실제 파일이 었어야함

하지만 위와 같은 데이터 보존은 바람직하지 않다.

디플로이먼트의 포드에 장애가 생겨 다른 노드로 포드가 옮겨간 경우 이전 노드에 저장된 데이터를 사용할 수 없기 때문이다.

특정 노드에만 포드를 배치하는 방법도 생각할 수 있지만 이 방법 또한 호스트 서버에 장애가 생기면 데이터를 잃게 된다는 단점이 존재한다.

hostPath 볼륨은 모든 노드에 배치해야 하는 특수한 포드의 경우에 유용하게 사용할 수 있다.

만약 CAdvisor와 같은 모니터링 툴을 쿠버네티스의 모든 워커 노드에 배포해야 한다면 hostPath를 사용하는 것이 옳을 수 있지만 그 외에는 보안 및 활용성 측면에서 그다지 바람직하지 않으므로 사용을 고려해보는 것이 좋다.

포드 내의 컨테이너 간 임시 데이터 공유: emptyDir

포드가 실행되는 도중에만 필요한 휘발성 데이터를 각 컨테이너가 함께 사용할 수 있도록 임시저장 공간을 생성함

<empty-pod.yaml>

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-pod
spec:
  containers:
    - name: content-creator
      image: alicek106/alpine-wget:latest
      args: ["tail" , "-f", "/dev/null"]
      volumeMounts:
        - name: my-emptydir-volume
          mountPath: /data 

    - name: apache-webserver
      image: httpd:2
      volumeMounts:
        - name: my-emptydir-volume
          mountPath: /usr/local/apache2/htdocs

  volumes:
    - name: my-emptydir-volume
      emptyDir: {}

$ kubectl apply -f emptydir-pod.yaml

content-creator 컨테이너 내부로 들어가 /data 디렉터리에 웹 컨텐츠를 생성하면 apache-webserver 컨테이너의 htdocs 디렉터리에도 동일하게 웹 컨텐츠 파일이 생성될 것이고(mount 명령어로 확인 가능), 이는 최종적으로 웹 서버에 의해 외부에 제공됨

네트워크 볼륨

NFS(Network File System)는 대부분의 운영체제에서 사용할 수 있는 네트워크 스토리지로 여러 개의 클라이언트가 동시에 마운트 해서 사용할 수 있는 특징이 있다. NFS는 NFS 서버와 NFS 클라이언트가 필요하며, 서버는 영속적인 데이터가 저장되는 네트워크 스토리지 서버이며, 클라이언트는 NFS 서버에 마운트해 스토리지에 파일을 읽고 쓰는 역할이다.

임시 NFS 서버 생성

<nfs-deployment.yaml>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-server
spec:
  selector:
    matchLabels:
      role: nfs-server
  template:
    metadata:
      labels:
        role: nfs-server
    spec:
      containers:
        - name: nfs-server
          image: gcr.io/google_containers/volume-nfs:0.8
          ports:
            - name: nfs
              containerPort: 2049
            - name: mountd
              containerPort: 20048
            - name: rpcbind
              containerPort: 111
          securityContext:
            priviledged: true

<nfs-service.yaml>

apiVersion: v1
kind: Service
metadata:
  name: nfs-service
spec:
  ports:
    - name: nfs
      port: 2049
    - name: mountd
      port: 20048
    - name: rpcbind
      port: 111
  selector:
    role: nfs-server

$ kubectl apply -f nfs-deployment.yaml
$ kubectl apply -f nfs-service.yaml

<nfs-pod.yaml>

apiVersion: v1
kind: Pod
metadata:
  name: nfs-pod
spec:
  contaIners:
    - name: nfs-mount-container
      image: busybox
      args: [ "tail" , "-f" , "/dev/null" ]
      volumeMounts:
        - name: nfs-volume
          mountPath: /mnt 
  volumes:
    - name : nfs-volume
      nfs:
        path: /
        server: {NFS_SERVICE_IP}

포드 컨테이너의 /mnt 디렉터리에 파일을 저장하면 NFS 서버에 데이터가 저장됨

NFS 볼륨의 마운트는 컨테이너 내부가 아닌 워커 노드에서 발생하므로 서비스의 DNS 이름으로 NFS 서버에 접근할 수 없으므로 NFS 서비스의 Cluser IP를 직접 얻은 뒤 YAML 파일에 사용하는 방식으로 포드를 생성해보자.

$ export NFS_CLUSTER_IP=$(kubectl get svc/nfs-service -o jsonpath='{.spec.clusterIP}')
$ cat nfs-pod.yaml | sed "s/{NFS_SERVICE_IP}/$NFS_CLUSTER_IP/g" | kubectl apply -f -

혹시 ContainerCreating 상태에서 파드가 생성되지 않는다면 kubectl describe pods 명령어로 무엇이 문제인지 파악하고 포드가 할당된 워커노드에서 apt-get install nfs-common 명령어로 패키지를 설치해야 함

NFS 서버가 /mnt 디렉터리에 마운트 됐으므로 포드의 컨테이너 내부의 /mnt 디렉터리에 저장된 파일은 포드가 다른 노드로 옮겨가거나 포드를 재시작해도 삭제되지 않는다.

실제 운영 환경에서는 NFS 서버를 도입하려면 백업 스토리지를 구축해 NFS 데이터 손실에 대비하거나 서버의 설정 튜닝 및 접근하기 위한 DNS를 준비해야 할 수도 있다.

PV, PVC를 이용한 볼륨 관리

PV와 PVC는 포드를 생성하는 YAML 입장에서 네트워크 볼륨이 NFS인지, AWS의 EBS 인지 상관없이 볼륨을 사용할 수 있도록 추상화해주는 역할을 담당한다.

인프라 관리자는 네트워크 볼륨의 정보를 이용해 퍼시스턴트 볼륨 리소스를 미리 생성해두고 사용자(개발자)는 퍼시스턴트 볼륨 클레임을 명시하고 생성하면 된다.

AWS의 EBS를 퍼시스턴트 볼륨으로 사용해보는 예제(EBS 생성했다는 가정)

<ebs-pv.yaml>

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ebs-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce 
  awsElasticBlockStore:
    fsType: ext4
    volumeID: <VOLUME_ID>

5Gi 볼륨의 크기와 ReadWriteOnce는 해당 볼륨이 1:1로 마운트 가능함을 의미한다.

이러한 항목들은 볼륨의 속성을 나타내며, 퍼시스턴트 볼륨 클레임의 요구 조건을 매칭할 때 사용한다.

$ cat ebs-pv.yaml | sed "s/<VOLUME_ID>/$VOLUME_ID/g" | kubectl apply -f -
$ kubectl get pv

아직 퍼시스턴트 볼륨 클레임을 생성하지 않았기 때문에 Status가 Available로 나오는 것을 확인할 수 있음

<ebs-pod-pvc.yaml>

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-ebs-pvc
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteOnce 
  resources:
    requests:
      storage: 5Gi
 
-----
apiVersion: v1
kind: Pod
metadata:
  name: ebs-mount-container
spec:
  containers:
    - name: ebs-mount-container
      image: busybox
      args: ["tail", "-f", "/dev/null"]
      volumeMounts:
        - name: ebs-volume
          mountPath: /mnt
  volumes:
    - name: ebs-volume
      persistentVolumeClaim:
        className: my-ebs-pvc

포드와 퍼시스턴트 볼륨 생성

$ kubectl apply -f ebs-pod-pvc.yaml
$ kubectl get pv, pvc
$ kubectl get pods
$ kubectl exec ebs-mount-container -- df -h | grep /mnt

요약하자면..

AWS에서 EBS 볼륨을 생성하고 ebs-pv.yaml 파일을 통해 퍼시스턴트 볼륨을 등록한다.

ebs-pod-pvc.yaml 파일을 통해 퍼시스턴트 볼륨 클레임을 생성하고, 요구조건이 만족되면 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임이 bound 된다. 마지막으로 파드에서 볼륨 클레임을 사용한다고 명시하면 최종적으로 EBS 볼륨이 컨테이너 내부에 마운트된다.

퍼시스턴트 볼륨을 선택하기 위한 조건 명시로 accessMode, 볼륨 크기 등이 이런 조건에 해당한다.

accessMode와 볼륨 크기, 스토리지 클래스, 라벨 셀렉터를 이용한 퍼시스턴트 볼륨을 선택할 수 있다.

ReadWriteOnce(RWO) -> 1:1 마운트만 가능, 읽기 쓰기 가능
ReadOnlyMany(ROX) -> 1:N 마운트 가능, 읽기 전용
ReadWriteMany(RWX) -> 1:N 마운트 가능, 읽기 쓰기 가능

storageClassName 이름을 사용하면 일치하는 퍼시스턴트 볼륨과 퍼시스턴트 볼륨 클레임이 서로 연결된다.

또는 라벨 셀렉터를 사용할 수도 있다. labels <-> selector.matchLabels

Recliam Policy

퍼시스턴트 볼륨은 처음에 생성했을 때 Status가 Available 이었다가 퍼시스턴트 볼륨 클레임을 연결하면 Bound로 변경됐는데, 퍼시스턴트 볼륨 클레임을 삭제하면 다시 Available이 되는 것이 아니라 Released로 변경된다.

Released 상태의 퍼시스턴트 볼륨은 다시 사용할 수 없지만 데이터는 볼륨안에 보존되어 있다.

퍼시스턴트 볼륨의 사용이 끝났을 때 해당 볼륨을 어떻게 초기화할 것인지 별도로 설정할 수 있는데, 이를 Reclaim Policy라고 한다. Retain, Delete, Recycle 방식이 있으며, 기본적으로 데이터를 보존하는 방식인 Retain을 사용한다.

Delete는 PV도 함께 삭제되는 방식이며, Recycle은 deprecated 될 예정이다.

다이나믹 프로비저닝과 스토리지 클래스

다이나믹 프로비저닝은 퍼시스턴트 볼륨 클레임이 요구하는 조건과 일치하는 퍼시스턴트 볼륨이 존재하지 않는다면 자동으로 퍼시스턴트 볼륨과 외부 스토리지를 함께 프로비저닝 하는 기능이다.

<storageclass-slow.yaml>

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs
parameters:
  type: st1
  fsType: ext4
  zones: ap-northeast-2a

<storageclass-fast.yaml>

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4
  zones: ap-northeast-2a

스토리지 클래스 생성

$ kubectl apply -f storageclass-slow.yaml
$ kubectl apply -f storageclass-fast.yaml
$ kubectl get sc

<pvc-fast-sc.yaml>

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-fast-sc
spec:
  storageClassName: fast
  accessModes:
    ReadWriteOnce
  Resources:
    requests:
      storage: 1Gi

 $ kubectl apply -f pvc-fast-sc.yaml

원래라면 퍼시스턴트 볼륨이 없기 때문에 퍼시스턴트 볼륨 클레임은 계속 pending 상태로 남아있어야 하지만 다이나믹 프로비저닝을 통해 동적으로 SSD 타입의 EBS가 생성되고, 이로부터 퍼시스턴트 볼륨이 생성된다.

인프런

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-03
spec:
  capacity:
    storage: 2G
  accessModes:
  - ReadWriteOnce
  local:
    path: /node-v
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - {key: kubernetes.io/hostname, operator: In, values: [k8s-node1]}

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-01
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1G
  storageClassName: ""

apiVersion: v1
kind: Pod
metadata:
  name: pod-volume-3
spec:
  containers:
  - name: container
    image: kubetm/init
    volumeMounts:
    - name: pvc-pv
      mountPath: /mount3
  volumes:
  - name : pvc-pv
    persistentVolumeClaim:
      claimName: pvc-01

References:

http://www.yes24.com/Product/Goods/84927385

https://kubetm.github.io/k8s/03-beginner-basic-resource/volume/

Volume

emptyDir, hostPath, PV/PVC

kubetm.github.io

[troubleshooting] [ERROR CRI]: container runtime is not running

알로그 — Mon, 16 May 2022 02:05:42 +0900

[ERROR CRI]: container runtime is not running

/etc/containerd/config.toml 파일에서

disabled_plugins 항목에서 CRI 제거한 뒤

$ systemctl restart containerd

쿠버네티스(kubernetes) ingress

알로그 — Sun, 15 May 2022 09:39:16 +0900

쿠버네티스(kubernetes) ingress

인그레스(Ingress)는 일반적으로 외부에서 내부로 향하는 것을 지칭하는 단어

외부 요청을 어떻게 처리할 것인지 네트워크 7계층 레벨에서 정의하는 쿠버네티스 오브젝트

외부 요청의 라우팅
가상 호스트 기반의 요청 처리
SSL/TLS 보안 연결 처리

외부 요청에 대한 처리 규칙을 쿠버네티스 자체 기능으로 편리하게 관리할 수 있다는 것이 인그레이스의 핵심

$ kubectl get ing

<ingress-example.yaml>

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-example
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec;
  rules:
  - host: alicek106.example.com 
    http:
      paths:
      - path: /echo-hostname 
        backend:
          serviceName: hostname-service 
          servicePort: 80

host: 해당 도메인으로 접근하는 요청에 대해서 처리 규칙을 적용
path: 해당 경로에 들어온 요청을 어느 서비스로 전달할 것인지 정의. 위에서는 backend로 처리함
serviceName, servicePort: path로 들어온 요청이 전달될 서비스와 포트

인그레이스 생성

$ kubectl apply -f ingress-example.yaml
$ kubectl get ingress

인그레스는 규칙을 적용하는 인그레스 컨트롤러와 함께 사용해야 한다.

Ngnix 웹 서버 인그레이스 컨트롤러 설치

$ kubectl apply -f https:llraw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.0/deploy/static/provider/baremetal/deploy.yaml

https://kubetm.github.io/k8s/08-intermediate-controller/ingress/

Nginx 인그레스 컨트롤러를 설치하기 위해 다양한 쿠버네티스 리소스를 한번에 생성함

$ kubectl get pods, deployment -n ingress-nginx

Nginx 웹 서버를 외부에 노출하기 위한 서비스를 생성해야 한다.

<ingress-service-lb.yaml>

kind: Service
apiVersion: v1
metadata:
  name: ingress-nglnx
  namespace: ingress-nglnx
spec:
  type: loadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  ports:
  - name: http
    port: 80
    targetPort: http
  - name: https
    port: 443
    targetPort: https

생성 후 확인

$ kubectl apply -f ingress-service-lb.yaml
$ kubectl get svc -n ingress-nginx

-------------------

대세는 쿠버네티스 강의 실습

쇼핑과 고객서비스를 위한 pod, service 각각 두개 생성

apiVersion: v1
kind: Pod
metadata:
  name: pod-shopping
  labels:
    category: shopping
spec:
  containers:
  - name: container
    image: kubetm/shopping
---
apiVersion: v1
kind: Service
metadata:
  name: svc-shopping
spec:
  selector:
    category: shopping
  ports:
  - port: 8080

apiVersion: v1
kind: Pod
metadata:
  name: pod-customer
  labels:
    category: customer
spec:
  containers:
  - name: container
    image: kubetm/customer
---
apiVersion: v1
kind: Service
metadata:
  name: svc-customer
spec:
  selector:
    category: customer
  ports:
  - port: 8080

서비스로 curl 날려서 응답 확인

ingress 생성

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: service-loadbalancing
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-shopping
            port:
              number: 8080
      - path: /customer
        pathType: Prefix
        backend:
          service:
            name: svc-customer
            port:
              number: 8080

ingress 생성 후 Port와 path를 통해 응답 확인

References:

http://www.yes24.com/Product/Goods/84927385

https://kubetm.github.io/k8s/08-intermediate-controller/ingress/

Ingress

Service Loadbalancing, Canary Upgrade

kubetm.github.io

쿠버네티스(kubernetes) Namespace, ConfigMap, Secret

알로그 — Sat, 14 May 2022 23:08:35 +0900

쿠버네티스(kubernetes) Namespace, ConfigMap, Secret

네임스페이스(Namespace): 리소스를 논리적으로 구분하는 장벽

네임스페이스는 일종의 포드, 레플리카셋, 디플로이먼트, 서비스 등과 같은 리소스들이 묶여 있는 하나의 가상공간 또는 그룹이라고 이해하면 됨

$ kubectl get namespaces
$ kubectl get ns

default라는 이름의 네임스페이스에 생성된 포드를 확인하려면..

$ kubectl get pods --namespace default

--namespace 옵션을 명시하지 않으면 모두 default 네임스페이스에서 수행된다.

쿠버네티스 클러스터를 여러 명이 동시에 사용해야 한다면 사용자마다 네임스페이스를 별도로 생성해 사용하도록 설정할 수 있음. 용도에 따라 네임스페이스를 생성해서 특정 네임스페이스에서만 존재하도록 구성하도록 가능

* 리눅스 네임스페이스는 컨테이너의 격리된 공간을 생성하기 위해 리눅스 커널 자체 기능을 활용하는 것이며, 일반적으로 네트워크나 마운트, 프로세스 네임스페이스를 의미하며 쿠버네티스의 네임스페이스 오브젝트는 리눅스 네임스페이스와 완전히 다른 것

<production-namespace.yaml>

apiVersion: v1
kind: Namespace
metadata:
  name: production

$ kubectl apply -f production-namespace.yaml

또는 명령어로 바로 생성할 수 있다.

$ kubectl create namespace production

특정 네임스페이스에 리소스를 생성하려면 기존에 작성한 YAML 파일에서 metadata - namespace: production 만 추가해주면 된다.

쿠버네티스 클러스터 내부에서는 서비스 이름을 통해 포드에 접근할 수 있는데, 이는 같은 네임스페이스 내의 서비스만 가능하다.

네임스페이스를 삭제하려면

$ kubectl delete namespace production

네임스페이스에 존재하는 모든 리소스가 함께 삭제되니 리소스 목록을 미리 확인할 것

네임스페이스에 존재하는 오브젝트의 종류를 확인하려면

$ kubectl api-resources --namespaced=true

추가로 네임스페이스에는 ResourceQuota와 LimitRange를 설정할 수 있다.

ResourceQuota는 네임스페이스의 자원 한계를 설정하는 오브젝트로 네임스페이스에 들어갈 파드의 전체 requests와 limits을 설정할 수 있다. 이 경우에는 파드에 requests와 limits의 스펙을 명시해야만 한다.

LimitRange는 각 파드마다 네임스페이스에 들어올 수 있는지 자원을 체크하는 오브젝트이다.

컨피그맵(Configmap), 시크릿(Secret): 설정값을 포드에 전달

설정값을 YAML 파일에 env 옵션을 통해 작성할 수 있지만 이런 경우에는 개발, 운영 파일마다 각각 config 값을 명시해줘야 하는 경우가 생긴다. 각각 관리하는 경우 결국 큰 용량의 컨테이너 이미지를 각각 관리하는 것인데 이는 부담되는 일이다.

이러한 제약을 해결하기 위해 컨피그맵을 사용하면 1개의 포드 YAML 파일만을 사용하되 환경에 따라 다른 컨피그맵을 생성해서 사용할 수 있다.

$ kubectl create configmap <컨피그맵이름> <설정값들>
$ kubectl create configmap log-level-configmap --from-literal LOG_LEVEL=DEBUG4
$ kubectl create configmap start-k8s --from-literal k8s=kubernetes --from-literal container=docker

확인하려면..

$ kubectl get cm
$ kubectl describe configmap log-level-configmap

컨테이너 내부에서 env 명령어를 통해 확인할 수 있다.

생성된 컨피그맵을 포드에서 사용하려면 환경변수로 사용하거나 포드 내부 파일로 마운트해 사용할 수 있다.

컨피그맵의 값을 포드에서 환경변수로 사용하려면..

...

spec:
  containers:
  - name: my-container
    image: busybox
    agrs: ['tail', '-f', '/dev/null']
    envFrom:
    - configMapRef:
        name: log-level-configmap
    - configMapRef:
        name: start-k8s

envFrom 항목은 하나의 컨피그맵에 여러 키-값 쌍이 존재하더라도 모두 환경변수로 가져오도록 설정

따라서 총 3개의 환경변수가 등록되어 있음

다른 방법으로 컨피그맵에서 특정 데이터만 가져오려면..

...
env:
- name: ENV_KEYNAME_1
  valueFrom:
    configMapKeyRef:
      name: log-level-configmap
      key: LOG_LEVEL
- name: ENV_KEYNAME_2
  valueFrom:
    configMapKeyRef:
      name: start-k8s
      key: k8s

포드 내부에 마운트하려면..

apiVersion: v1
kind: Pod
metadata:
  name: configmap-volume-pod
spec:
  containers:
  - name: my-container
    image: busybox
    args: ["tail" "-f", "/dev/null" ]
    volumeMounts:
    - name: configmap-volume 
      mountPath: /etc/config 

  volumes:
  - name: configmap-volume
    configMap:
      name: start-k8s

컨피그맵을 생성한 후 etc/config 맵을 조회해보면 값을 출력할 수 있다.

$ kubectl apply -f volume-mount-configmap.yaml
$ kubectl exec configmap-volume-pod ls /etc/config
$ kubectl exec configmap-volume-pod cat /etc/config/k8s

items와 path 항목을 통해 원하는 키-쌍 데이터만 선택해서 포드에 파일로 가져올 수 있음

파일로부터 컨피그맵을 생성하려면..

$ kubectl create configmap <컨피그맵이름> --from-file <파일이름>

기본적으로 파일 이름이 키로, 내용이 값으로 저장된다.

--from-env-file 옵션으로 여러 개의 키-값, 여러 줄로 구성된 설정 파일을 한번에 컨피그맵으로 가져올 수도 있음

출력 내용을 YAML 파일로 작성한 뒤, kubectl 명령어로 컨피그맵 생성 가능

$ kubectl create configmap my-configmap --from-literal mykey=myvalue --dry-run -o yaml >my-configmap.yaml
$ kubectl apply -f my-configmap.yaml

시크릿은 SSH 키, 비밀번호 등과 같이 민감 정보를 저장하기 위한 용도로 사용되며, 네임스페이스에 종속되는 쿠버네티스 오브젝트로 컨피그맵과 사용 방법이 비슷하다. 일반적인 쿠버네티스 오브젝트 값들은 쿠버네티스 DB에 저장되는데, 시크릿은 메모리에 저장된다. 컨피그맵의 경우 key, value 쌍을 무한히 넣을 수 있지만 시크릿은 1Mbyte까지 가능하다.

$ kubectl create secret generic my-password --from-literal password=123123

--from-file 이나 --from-env-file 옵션도 사용 가능

$ kubectl get secrets my-password -o yaml

패스워드는 인코딩한 값으로 저장되어 있음

컨피그맵과 사용 방법이 비슷하므로 YAML 파일에서 secretRef로 가져오거나 secretKeyRef로 특정 데이터만 선택해 원하는 이름의 환경변수로도 가져올 수 있고, 볼륨 마운트도 가능하다.

시크릿의 종류는 Type으로 볼 수 있는데, 기본은 Opaque이며 생성할 때 generic이라고 명시했던 것이 Opaque 타입에 해당하는 종류임

도커 허브에 공개돼있는 이미지는 다운받는데 문제없지만 사설 레지스트리 또는 도커 허브, 클라우드 레지스트리를 사용한다면 인증 절차가 필요하다.

쿠버네티스에서는 docker login 명령어 대신 별도의 시크릿을 생성해서 사용한다.

두 가지 방법이 있는데 첫 번째는 docker login 명령어로 성공했을 때 도커 엔진이 생성하는 ~/.docker/config.json 파일을 이용하는 것이다.

$ kubectl create secret generic registry-auth \
--from-file=.dockerconfigjson=/root/.docker/config.json \
--type=kubernetes.io/dockerconfigjson

또는 직접 --docker-username과 --docker-password 옵션을 통해 직접 입력하면 된다.

이렇게 생성한 시크릿은 디플로이먼트 또는 포드 등에서 imagePullSecrets, name 항목을 통해 이미지를 받아올 때 사용할 수 있다.

시크릿의 데이터가 많아질수록 YAML 파일에 데이터를 저장하는 것은 가독성이나 관리에 있어 바람직하지 않다.

이러한 단점을 해결하기 위해 시크릿이나 컨피그맵을 배포하기 위해 YAML 파일을 작성할 때 데이터를 YAML 파일로부터 분리할 수 있는 kustomize 기능을 사용할 수 있다.

secretGenerator:
- name: kustomize-secret
  type: kubernetes.io/tls
  files:
  - tls.crt=cert.crt
  - tls.key=cert.key

시크릿을 생성하기 전에 kustomize로부터 생성될 시크릿의 정보를 미리 확인하려면..

$ kubectl kustomize ./

kustomize.yaml 파일로부터 시크릿을 생성하려면..

$ kubectl apply -k ./

컨피그맵이나 시크릿을 포드에 제공하는 방법으로 두 가지 중 환경변수로 설정 값을 제공하는 방법과 볼륨 파일로 마운트하는 방법이 있었는데, 첫 번째는 컨피그맵이나 시크릿 값을 변경해도 자동으로 재설정되지 않으며 디플로이먼트의 포드를 다시 생성해야만 한다. 파일로 포드 내부에 마운트 된 설정 파일은 컨피그맵이나 시크릿을 변경하면 내용도 자동으로 갱신된다.

단, 포드 내부에 마운트된 설정 파일이 변경됐다고 해서 실행중인 애플리케이션의 설정이 자동으로 변경되는 것은 아니니 로직을 직접 구현해야 한다.

요약 이미지

References:

https://kubetm.github.io/k8s/03-beginner-basic-resource/configmap/

ConfigMap, Secret

Env(Literal, File), Mount(File)

kubetm.github.io

http://www.yes24.com/Product/Goods/84927385

시작하세요! 도커/쿠버네티스 - YES24

본서는 도커를 처음 접하는 개발자를 위한 도커 컨테이너와 이미지의 기본적인 개념을 먼저 설명한 뒤, 도커 컴포즈와 스웜 모드를 통해 컨테이너 애플리케이션을 YAML 파일로 작성하고 클러스

www.yes24.com

쿠버네티스(kubernetes) Deployment, Service

알로그 — Sat, 14 May 2022 10:31:13 +0900

쿠버네티스(kubernetes) Deployment, Service

디플로이먼트(Deployment): 레플리카셋, 포드의 배포를 관리

쿠버네티스 운영환경에서 레플리카셋을 YAML 파일을 통해 사용하는 경우는 거의 없고, 대부분은 레플리카셋과 포드의 정보를 정의하는 디플로이먼트라는 이름의 오브젝트를 YAML 파일로 정의해서 사용한다. (디플로이먼트는 레플리카셋의 상위 수준의 오브젝트)

<deployment-nginx.yaml>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      name: my-nginx-pod
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.10
        ports:
        - containerPort: 80

디플로이먼트 생성

$ kubectl apply -f deployment-nginx.yaml
$ kubectl get deploy
$ kubectl get replicasets
$ kubectl get pods

디플로이먼트, 레플리카셋 함께 생성되어 있음

디플로이먼트를 삭제하면 레플리카셋, 포드 또한 삭제됨

kubectl delete deploy my-nginx-deployment

디플로이먼트를 사용하는 이유는 애플리케이션의 업데이트와 배포를 더 편하게 만들기 위해서다.

디플로이먼트를 이용해 앱의 버전을 업데이트해 배포하는 간단한 예시를 살펴보자.

$ kubectl apply -f deployment-nginx.yaml --record
$ kubectl get pods

nginx의 버전을 변경하려면..

$ kubectl set image deployment my-nginx-deployment nginx=nginx:1.11 --record

YAML 파일에서 직접 수정하거나 kubectl edit 명령어로도 사용 가능함

그 뒤에 레플리카셋의 목록을 출력해보면?

$ kubectl get replicasets

두 개의 레플리카셋이 있는 걸 볼 수 있다.

디플로이먼트는 포드의 정보를 업데이트함으로써 새로운 레플리카셋과 포드를 생성했음에도 불구하고 이전 버전의 레플리카셋을 삭제하지 않고 남겨두고 있다. 해쉬값이 변경되어 관리되며 이전의 정보를 리비전으로 보존한다.

리비전 정보를 다음 명령어로 더 자세히 확인 가능

$ kubectl rollout history deployment my-nginx-deployment

이전 버전으로 롤백하고 싶다면?

$ kubectl rollout undo deployment my-nginx-deployment --to-revision=1

리소스 정리

$ kubectl delete deployment, pod ,rs --all

서비스(Service): 포드를 연결하고 외부에 노출

현재까지는 로컬 개발 환경 또는 클러스터 내부에서만 접근이 가능했다.

포트를 외부로 노출해 사용자들이 접근하거나, 다른 디플로이먼트의 포드들이 내부적으로 접근하려면 서비스라고 부르는 별도의 오브젝트를 생성해야 한다.

서비스 기능

고유한 도메인 이름을 부여함
로드 밸런서 기능 수행
포드를 외부로 노출

호스트 이름을 반환하는 간단한 웹 서버의 디플로이먼트 생성

<deployment-hostname.yaml>

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      name: my-webserver
      labels:
        app: webserver
    spec:
      containers:
      - name: my-webserver
        image: alicek106/rr-test:echo-hostname
        ports:
        - containerPort: 80

$ kubectl apply -f deployment-hostname.yaml

서비스는 포드에 어떻게 접근할 것이냐에 따라 종류가 여러개로 세분화 된다.

목적에 맞는 적절한 서비스의 종류를 선택해야 하며 주로 사용하는 서비스 타입은 3가지다.

ClusterIP: 쿠버네티스 내부에서만 포드에 접근할 때 (관리자가 주로 사용)
NodePort: 클러스터의 모든 노드에 동일하게 개방
LoadBalancer: 로드 밸런스를 동적으로 프로비저닝하여 포드에 연결

ClusterIP 타입의 서비스

<hostname-svc-clusterip.yaml>

apiVersion: v1
kind: Service
metadata:
  name: hostname-svc-clusterip
spec:
  ports:
  - name: web-port
    port: 8080
    targetPort: 80
  selector:
    app: webserver
  type: ClusterIP

spec.selector 어떤 라벨을 갖는 포드에 접근할 수 있게 만들 것인지 결정
spec.ports.port: 쿠버네티스 내부에서만 사용할 수 있는 고유한 IP
spec.ports.tartgetPort: selector 항목에 의해 정의된 라벨에 의해 접근 대상이 된 포드들이 내부적으로 사용하고 있는 포트

서비스 목록 확인

$ kubectl apply -f hostname-svc-clusterip.yaml

$ kubectl get services
$ kubectl get svc # services

생성된 서비스를 확인할 수 있고, 출력 내용 중에서 CLUSTER-IP와 PORT(S)를 통해 요청 보내면 된다.

임시 포드를 만들어 요청해보면..

$ kubectl run -i --tty --rm debug --image=alicek106/ubuntu:curl --restart=Never -- bash

# 서버에 접속한 뒤
$ curl 10.101.98.33:8080 --silent | grep Hello
$ curl hostname-svc-clusterip:8080 --silent | grep Hello

서비스 이름 자체로도 접근 가능

서비스의 IP와 포트를 통해 포드에 접근하고 있으며, 별도의 설정을 하지 않아도 로드 밸런싱이 수행되어 요청이 분산됨

서비스 삭제

$ kubectl delete svc hostname-svc-clusterip
$ kubectl delete -f hostname-svc-clusterip.yaml

NodePort 타입의 서비스

ClusterIP 타입의 서비스는 내부에서만 접근 가능하지만, NodePort 타입의 서비스는 클러스터 외부에서도 접근 가능함

모든 노드의 특정 포트를 개방해 서비스에 접근하는 방식

apiVersion: v1
kind: Service
metadata:
  name: hostname-svc-nodeport
spec:
  ports:
    - name: web-port
      port: 8080
      targetPort: 80
  selector:
    app: webserver
  type: NodePort

서비스 생성하면..

$ kubectl apply -f hostname-svc-nodeport.yaml
$ kubectl get services

PORT(S) 항목에 31514라고 출력되는데, 이는 모든 노드에서 동일하게 접근할 수 있는 포트를 의미한다.

모든 노드에 내부 IP 또는 외부 IP를 통해 31514 포트로 접근하면 동일한 서비스에 연결할 수 있다.

한 가지 특이한 점은 kubectl get service 명령어에서 CLUSTER-IP 항목에 내부 IP가 할당되어 있는데, 이는 NodePort 타입의 서비스가 ClusterIP의 기능을 포함하고 있기 때문이다.

즉, NodePort 타입의 서비스는 내부 네트워크와 외부 네트워크 양쪽에서 접근할 수 있다.

클라우드 플랫폼의 로드 밸런서와 연동하기

LoadBalancer 타입의 서비스는 서비스 생성과 동시에 로드 밸런서를 새롭게 생성해 포드와 연결한다.

NodePort를 사용할 때는 각 노드의 IP를 알아야만 접근할 수 있었지만 LoadBalancer 타입의 서비스는 클라우드 플랫폼으로부터 도메인 이름과 IP를 할당받기 때문에 더 쉽게 접근할 수 있다.

일반적으로 AWS, GCP와 같은 클라우드 플랫폼 환경에서 LoadBalancer 타입을 사용할 수 있으며 가상 머신이나 온프레미스 환경에선 힘들 수 있다.

hostname-deployment라는 디플로이먼트는 미리 생성되어 있다고 가정

<hostname-svc-lb.yaml>

apiVersion: v1
kind: Service
metadata:
  name: hostname-svc-lb
spec:
  ports:
    - name: web-port
      port: 80
      targetPort: 80
  selector:
    app: webserver
  type: LoadBalancer

서비스 생성

$ kubectl apply -f hostname-svc-lb.yaml

LoadBalancer 타입 또한 NodePort나 ClusterIP와 동일하게 IP가 할당됨

눈여겨봐야 할 것은 EXTERNAL-IP가 생성되며 이는 클라우드 플랫폼에서 자동으로 할당된 것임

인프런: 대세는 쿠버네티스 강의자료 참조

추가 중급 서비스 내용

파드를 동시에 생성하는 경우에 파드에서 파드로 접근할 때, IP를 알 수 없으니 Headless를 이용하여 도메인을 통한 접근하는 방법과 파드와 서비스를 연결하는 Endpoint 그리고 ExternalName도 알아둘 것

References:

https://kubetm.github.io/k8s/03-beginner-basic-resource/service/

Service

ClusterIP, NodePort, LoadBalancer

kubetm.github.io

http://www.yes24.com/Product/Goods/84927385

시작하세요! 도커/쿠버네티스 - YES24

www.yes24.com

[troubleshooting] [kubelet-check] It seems like the kubelet isn't running or healthy.

알로그 — Sat, 14 May 2022 00:29:33 +0900

오류 메시지: [kubelet-check] It seems like the kubelet isn't running or healthy.

/etc/docker/daemon.json에 아래와 같이 작성 후

{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}

다시 초기화

$ kubeadm reset
$ kubeadm init

그래도 안되면 리부팅 후 다시 초기화 진행

쿠버네티스(kubernetes) Pod, Replica Set

알로그 — Sun, 8 May 2022 16:14:53 +0900

쿠버네티스(kubernetes) 포드(Pod), 레플리카셋(Replica Set)

쿠버네티스의 모든 리소스는 오브젝트 형태로 관리된다.

$ kubectl api-resources
$ kubelctl explain pod

쿠버네티스는 명령어보다 YAML 파일을 더 많이 사용한다.

쿠버네티스는 여러 개의 컴포넌트로 구성되어 있다.

마스터 노드는 클러스터를 관리하는 역할을 담당하고, 워커 노드에 애플리케이션 컨테이너가 생성됨
마스터 노드에는 API 서버, 컨트롤러 매니저, 스케줄러, DNS 서버 등이 실행되며 모든 노드에는 오버레이 네트워크 구성을 위해 프락시와 네트워크 플러그인이 실행됨
마스터 노드에서 "docker ps" 명령어를 실행해보면 매우 많은 컨테이너가 실행되고 있음
kubelet이라는 에이전트가 모든 노드에서 실행되는데, 컨테이너 생성, 삭제 뿐만 아니라 마스터와 워커 노드 간의 통신 역할을 담당하는 에이전트임
쿠버네티스가 반드시 도커를 사용해야 하는 것은 아니며, OCI(Open Container Initiative)라는 컨테이너 런타임 표준을 구현한 CRI(Container Runtime Interface)를 갖추고 있다면 어떤 컨테이너를 써도 상관없음

포드(Pod): 컨테이너를 다루는 기본 단위

1개 이상의 컨테이너로 구성된 컨테이너의 집합

YAML 파일은 일반적으로 apiVersion, kind, metadata, spec 4가지 항목으로 구성됨

<nginx-pod.yaml>

apiVersion: v1        # 오브젝트의 API 버전
kind: Pod             # 리소스 종류
metadata:             # 라벨, 주석, 이름 등 부가 정보 입력
  name: my-nginx-pod
spec:                 # 리소스 생성을 위한 자세한 정보 입력
  containers:
  - name: my-nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
      protocol: TCP

포드 생성하기

$ kubectl apply -f nginx-pod.yaml

포드 목록 출력

$ kubectl get pods

리소스의 자세한 정보를 얻어오려면..

$ kubectl describe pods my-nginx-pod

포드의 IP가 출력되는데, 이는 외부에서 접근할 수 있는 IP가 아니라 클러스터 내부에서만 접근 가능하다.

따라서 외부 또는 내부에서 포드에 접근하려면 서비스(service)라고 하는 오브젝트를 따로 생성해야 한다.

일단은 클러스터의 노드 중 하나에 접속한 뒤 nginx 포드의 ip로 http 전송하면 정상 실행임을 알 수 있다.

포드 컨테이너 내부로 접속하려면..

$ kubectl exec -it my-nginx-pod bash

로그 확인

$ kubectl logs my-nginx-pod

쿠버네티스의 오브젝트는 kubectl delete -f 명령어로 삭제할 수 있음

$ kubectl delete -f nginx-pod.yaml

쿠버네티스가 포드를 사용하는 이유는 여러가지가 있지만 그 이유 중 하나는 여러 리눅스 네임스페이스를 공유하는 여러 컨테이너를 추상화된 집합으로 사용하기 위해서이다.

kubectl get pods 명령어로 포드의 목록을 출력했을 때, READY 항목의 1/1 이라는 출력은 1개의 컨테이너가 정의돼있으며 이 컨테이너는 정상적으로 준비되었다는 뜻이다.

<nginx-pod-with-ubuntu.yaml>

apiVersion: v1        # 오브젝트의 API 버전
kind: Pod             # 리소스 종류
metadata:             # 라벨, 주석, 이름 등 부가 정보 입력
  name: my-nginx-pod
spec:                 # 리소스 생성을 위한 자세한 정보 입력
  containers:
  - name: my-nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
      protocol: rep
  - name: ubuntu-sidecar-container
    image: alicek106/rr-test:curl
    command: ["tail"]
    args: ["-f", "/dev/null"] # 컨테이너가 종료되지 않도록 유지

yaml 파일을 쿠버네티스에 적용해보면 2개의 컨테이너가 실행중인 것을 확인할 수 있음

$ kubectl apply -f nginx-pod-with-ubuntu.yaml
$ kubectl get pods

우분투 컨테이너 내부로 들어가려면..

$ kubectl exec -it my-nginx-pod -c ubuntu-sidecar-container bash

위 컨테이너에서 로컬호스토로 HTTP 전송을 하면 nginx 서버 응답이 도착하는데, 이는 포드 내의 컨테이너들이 네트워크 네임스페이스 등과 같은 리눅스 네임스페이스를 공유해 사용하기 때문이다.

실제 쿠버네티스 환경에서는 1개의 컨테이너로 구성된 포드를 사용하는 경우가 많지만 기능 확장을 위한 추가 컨테이너를 포함시킬 수 있으며 이러한 부가적인 컨테이너를 사이드카(sidecar) 컨테이너라고 부른다.

레플리카셋(Replica Set): 일정 개수의 포드를 유지하는 컨트롤러

동일한 여러 개의 포드를 직접 생성하는 방법은 적절하지 않다.

포드가 어떤 이유로 삭제되거나 장애가 발생해 더 이상 포드에 접근하지 못 하게 됐을 때, 직접 삭제하고 생성하지 않는 한 해당 포드는 복구되지 않는다.

이런 한계점을 해결해주는 것이 레플리카셋인데 정해진 수의 동일한 포드가 항상 실행되도록 관리하거나 노드 장애 등의 이유로 포드를 사용할 수 없다면 다른 노드에서 포드를 다시 생성할 수 있다.

<replicaset-nginx.yaml>

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-nginx
spec:
  replicas: 2
  selector:
    matchLabels: 
      app: my-nginx-pods-label
  template:
    metadata:
      name: my-nginx-pod
      labels:
        app: my-nginx-pods-label
    spec:
      containers:
      - name: my-nginx-container
        image: nginx:latest
        ports:
        - containerPort: 80

레플리카셋 생성

 $ kubectl apply -f replicaset-nginx.yaml

레플리카셋과 포드 목록 확인

$ kebectl get po
$ kubectl get rs

yaml 파일에서 포드를 3개로 늘리면 이미 생성된 래플리카셋을 다시 삭제하고 생성할 필요없이 1개가 더 추가된다.

이는 Label Selector를 이용해 이뤄지기 때문에 동일한 라벨을 가지는 포드를 미리 생성한다음 레플리카셋을 생성하더라도 동일하게 동작한다.

레플리카셋이 생성해 놓은 1개 포드의 라벨을 삭제한다면?

$ kubectl edit pods replicaset-nginx-(hash값)

기존 파드는 이제 더 이상 관리 대상이 아니게 되며, 새로운 파드를 하나 더 생성된다.

$ kubectl get pods --show-label

따라서 더 이상 관리대상이 아니기 때문에 레플리카셋을 삭제하더라도 해당 포드는 삭제되지 않으므로 직접 수동으로 삭제해야 한다.

$ kubectl delete rs replicaset-nginx
$ kubectl get pods
$ kubectl delete pods replicaset-nginx-(hash값)

레플레카셋의 목적은 포드를 생성하는 것이 아닌 일정 개수의 포드를 유지하는 것이기 때문에 포드가 너무 많으면 포드를 삭제해 replicas에 설정된 숫자만큼 포드를 유지하고자 한다.

대세는 쿠버네티스 인프런 강의자료

References.

http://www.yes24.com/Product/Goods/84927385

시작하세요! 도커/쿠버네티스 - YES24

www.yes24.com

https://kubetm.github.io/k8s/04-beginner-controller/replicaset/

Replication Controller, ReplicaSet

Template, Replicas, Selector

kubetm.github.io