2026년 9월 18일 금요일

정보관리기술사 4일차


< 3일차 보완 >

1. Kubernetes의 정의
 - 다수의 Container를 자동화 하여 운영 배포, 관리, 장애 대응 하기 위해 만들어진 플랫폼이다.
 2. Kubernetes가 필요한 이유
 - 다수의 Container를 사람이 관리하기 위해서는 배포, 운영 관리, 장애 대응 등 복잡한 운영 관리를 위해 다수의 인적자원이 필요로 한다 이러한 운영 관리의 영역을 자동화하여 일관된 상태로 운영하기 위해 Kubernetes가 필요하다. 
 3. Kubernetes 주요 구성요소
 - Control Plane
 Pod의 Current Statue를 체크하여 Disierd State로 유지하도록 관리한다
  · API Server
 Kubernetes API에 대한 중앙 진입점으로, 사용자의 요청을 수신하고 각 구성 요소 간 API 통신을 중계한다.
 · etcd
 Kubernetes Cluster의 Object 및 Desired State 등의 상태 정보를 저장하는 분산 Key-Value Store
 · Scheduler
 생성될 Pod 의 요구 사항과 Node의 상태 등을 고려하여 Pod가 배치 될 Worker Node를 선정
 · Controller / Controller Manager 
 Controller는 Desired State와 Current State 간 차이를 지속적으로 감시하고 필요한 조치를 수행하여 Desired State를 유지 한다 Controller Manager는 Controll Plane 구성 요소 중 하나로 여러 Controller를 실행 관리 한다.
 - Worker Node
 Pod가 실행되어 동작하는 영역
 · kubelet
 Pod의 생명 주기를 관리하며 API Server에서 전달된 명령을 수령
 · Container Runtime 
 Container를 API Server의 명령에 맞춰 실행
 4. Application 배포 및 실행 과정
 - API Server로 Pod 에 대한 명령이 인입되어 etcd 에 해당 Pod의 Diesired State를 기록하여 보관하고 Scheduler가 해당 Container가 어떤 Worker Node에 배치 될지 결정하며, Controller를 통해 해당 Container의 Desiered State 상태로 유지되도록 조정되도록 운영이 된다. Worker Node 에서는 Kubelet이 Pod의 생명 주기를 관리하고 Container Runtime이 Pod의 명세를 확인하여 정의된 대로 Container 서비스를 생성, 실행 하게 된다.
 5. Desired State와 Reconciliation
 - Kubernetes에서 선언한 Application 및 Cluster Resource의 목표 상태를 Desired State 라 하며 Controller는 Current State를 지속적으로 체크하여 Desired State 와 상이할 경우 Desired State와 동일하게 맞추기 위해서 필요한 Pod의 생성, 삭제, 변경 등의 조정하게 되는 데 그 행위가  Reconciliation(조정) 이다.
 6. Scaling
 - HPA는 CPU / Memory 등의 Metric을 기반으로 Pod의 Replica 수를 자동으로 증감 시켜 Scale-out / Scale-in 을 수행한다
 7. Self-Healing
 - Pod의 장애나 리소스의 부하로 인해 Desired Stated와 Current State 간 차이가 발생하면 Controller가 이를 감지하여 Pod를 재생성 등의 조치를 수행하여 서비스의 연속성을 확보하는 행위를 말한다.
 8. Service / Network
 - Pod의 생성 시 Pod 의 IP는 고정 IP가 아니다 하지만 서비스는 안정적인 지점을 바라보고 서비스를 하기 때문에 Pod와 요청 클라이언트 구간에서 변경되는 Pod IP를 추상화하여 안정적인 접근점을 제공하는 역할을 수행하며 http, https 등의 외부 호출에 대한 라우팅 역할을 하는 Ingress도 있다.
 9. 결론
 - 시스템의 발전으로 운영자가 다수의 Container의 관리가 필요하여 Kubernetes Platform이 등장하게 되었다. 이러한 Kubernetes 를 통해 다수의 Container를 운영 자동화하기 위해 Desired State를 선언하고 Current State와의 차이를 지속적으로 Reconciliation(조정)하여 Application의 배포 확장 장애 복구를 자동화 하는 Container Orchestration Platform이다.
 이를 통해 대규모의 Container 운영 환경에서 운영 복잡성을 감소시키기고 Self-Healing 을 통한 자동화 복구 기반 운영으로 서비스의 안정성을 높이고 운영 효율성을 높일 수 있다 향후 DevOps, CI/CD, Cloud Native 환경과 연계하여 Application 개발부터 배포 운영까지 자동화하는 기반 기술로 활용이 가능하다.



2026년 9월 17일 목요일

정보관리기술사 3일차

1. Kubernetes의 정의
- 다수의 Container 를 Orchestration하여 운영 관리, 배포, 확장, 장애 복구를 자동화 하기 위해 만들어진 Platform
2. Kubernetes가 필요한 이유
- 다수의 Container 관리 함에 있어서 정해진 설정을 기반으로 자동화 하여 관리, 배포, 장애 복구 등을 위해 필요하다.
3. Kubernetes 주요 구성요소
- K8S를 Control Plane 영역으로 API Server, etcd, Controller, scheduler 가 있으며 API Server의 경우 K8S의 명령어를 수행하게 되며, etcd에 container를 운영하게 될 설정 값들을 보관하고,  Controller를 통해서 Current State를 비교하여 Desired State 상태로 유지하며, scheduler를 통해 어떤 Wokrer Node에 배치 할 지 정하게 된다. Controller를 통해 실제 Pod 운영을 위한 자동화 업무를 수행하게 된다. Worker Node에서는 kubelet 을 통해 API Server에서 Pod 관련 명령을 전달 받아 Pod를 관리하고 Container runtime이 Contrainer를 실행하게 된다.
4. Container/Pod 배포
- API Server 를 통해 Pod 생성 명령이 전달이 되면 etcd 에 관련된 state를 기록하여 저장 후 scheduler를 통해 Worker Node 로 생성이 될지 지정되며 kubelet을 통해 수령된 명령을 container runtime을 통해 Pod를 생성하게 된다. 
5. 확장(Scaling)
- 장애나 성능관련 Auto Scaling 을 통해 Pod의 성능이 떨어 질 경우 Sacle Out 진행하여 pod를 증설하여 업무 분담
6. 장애복구
- pod 가 죽는 장애가 발생 시 Self Healing 을 통해 가지고 있는 image 를 가지고 자동으로 pod 서비스를 기동
7. Service / Network
- Pod가 동작 시 각각의 Pod는 pod의 서비스 포트를 가지고 있으며 클라이언트가 해당 Pod의 Container 에서 수행되는 Application을 이용하기 위해서는 Service를 통해 Pod로 접근하게 되며 http/https 통신의 경우 Ingress 를 통해 라우팅 되어 Pod에 전달되어 진다.
8. 결론
- application 서비스의 자동화된 운영 관리, 배포, 장애 복구 등을 위해서 k8s를 사용하게 된다. 이러한 자동화된 환경을 통해 장애 포인트에 대한 즉각 대응하여 원활하고 안정화된 서비스를 제공하는 인프라 환경을 조성 할 수 있게 된다.

배경 지식 부족으로 현재로 종료하고 추후 다른 Part로 따로 나눠 보완 예정.

2026년 9월 14일 월요일

정보관리기술사 2일차

문제

"서버 가상화(Virtualization)의 개념과 주요 특징을 설명하고, 가상머신(VM)과 컨테이너(Container)의 차이점 및 각각의 활용 방안을 설명하시오."


1. 가상화의 정의 

 - 한정된 하드웨어 자원을 하나의 서버가 아닌 여러 VM 이라는 형태로 제공하기 위해 Hyper Visor 기술을 이용하여 물리 자원을 논리 자원으로 효율적으로 구성하는 것을 의미

2. 가상화가 필요한 이유 

 - 한정된 하드웨어 자원을 통해 여러 서버를 운용하기 위해서 가상화를 통해 더 효율적인 하드웨어 자원 관리, 그에 따른 비용절감, 서버를 운용함에 있어 유연성과 가용성을 챙기고 물리 서버를 여러대의 가상화 서버로 나누어 사용하여 서버 한 대에 여러대를 통합 관리 하는 관리의 효율성도 챙길 수 있다.

3. 가상화의 주요 구성요소

 - 주요 구성으로는 HW, Hypervisor, VM 형태로 구성되며 그 VM을 구성하기 위해 가상화 네트워크, shared storage(datacenter) 등이 부수적으로 구성된다.

4. VM의 특징 

 - VM의 특징으로는 클러스터링 된 가상화 환경에서 가상 자원을 할당하여 운용되므로 가용 할당된 자원 내에서 유동적으로 자원을 증설 할 수 있음 기존 물리서버에 1대의 서버를 올렸다면 가상화 클러스터링 된 서버들의 자원을 논리적으로 할당하여 HostOS 갯수 이상의 VM을 구성 가능함

5. Container의 특징 

 - VM 보다 더 유연적으로 구성되며 자원 효율이 높다. nginx, apache, tomcat, mysql 등 microservice 단위로 Container를 기동하여 가볍고 빠르게 기동이 되며 scale-out 을 통해 부하 분산 및 load balancing 된 서비스 제공이 가능

6. VM vs Container 비교 

- VM의 경우 HyperVisor에 Guest OS 방식으로 올라가다 보니 자원을 받아 소유하고 지속적으로 운영하면서 가상화 서버를 운영 하는 것으로 물리 서버로 구성해야 할 사이즈를 효율성 있게 가상화 VM 환경에서 구동하는 방법으로 사용되며 Container의 경우 Apache, tomcat 등 단순 Microservice 를 운영하기 위해 해당 Application 만 가볍게 운용하는 측면이 차이점이라고 생각한다.

7. 활용 방안

-  현재 귀사에서도 사용중 이지만 가상화 VM의 자원을 여유롭게 할당하여 K8S 환경을 구축하여 microservice 단위로 pod를 기동하여 웹 기반 서비스인 메일링, 사내 메신저등을 구동하여 사용 중 이다. 이렇게 VM과 Container를 적절히 조합하여 사용 중이다.

8. 결론

 - 가상화라는 기능을 통해 한정된 물리 자원에서 효용성을 높여 비용감면 효과를 볼 수 있는 데 나아가 VM, K8S 환경을 서비스의 기능에 초점을 두어 구성 운영하여 효율적인 가상화 환경을 운영하고 나아가 자동화된 구성이 필요하다. 

지피티 피셜 70점 짜리 

2026년 9월 11일 금요일

정보관리기술사 1일차

문제

"IT 시스템의 고가용성(HA, High Availability)을 설명하고, 서버·네트워크·데이터베이스 관점에서 고가용성 확보 방안을 설명하시오."


 1. 고가용성의 정의

 - 고가용성은 서비스 운영에 있어서 장애 발생 시 최단 시간 혹은 무중단으로 서비스를 연속적으로 유지하는 걸 의미 한다.

 2. 고가용성이 필요한 이유 

 - 고가용성은 서비스를 운영하면서 필연적으로 발생하는 장애에 대해서 서비스를 연속적으로 제공하며, 장애에 대응 및 서비스 흐름의 끊김을 최소화 하여 대고객 서비스의 경우 고객의 신뢰를 높이고 금융 기관의 경우 금전적인 피해를 낮추기 위해서 필요하다.

 3. 서버 관점의 HA 

 - 물리적인 이중화의 경우 서버의 H/W 및 S/W 장애로 해당 서버의 가용이 불가할 경우 물리적으로 Active - Stand By 구조로 구성을 하여 Stand By 서버로 Fail over 를 통해 서비스의 연속성을 확보하게된다.

 - 서버의 App 관점의 경우 앞서 서버를 HA 구성하여 2대를 운영하여 Application 도 cluster로 구성하여 한 개의 App 서비스가 불가 할 경우 다른 하나로 서비스를 연속적으로 제공하여 서비스의 끊김을 줄이고 신속하게 장애를 조치하게 된다.

- HA 구성의 경우 서비스의 경우에 따라 다르지만 HA 구성 시 shared volume 을 사용하여 데이터를 동기화 해야 하는 경우가 있으며 HA 전용 솔루션의 경우 보통은 지원하게 된다. 

- 장애의 탐지의 경우 HeartBeat를 통해 Health Check를 하여 장애 상황을 판단 시 Auto Fail over 하여 서비스의 연속성을 확보하게 된다.

 4. 네트워크 관점의 HA

 - 네트워크 장애 발생 시 네트워크 장비 이중화, 회선 이중화 등을 통해 서비스의 연속성을 확보하며 장비의 경우 Fail Over 를 통해 순단을 통한 서비스 연속성 확보를 진행한다

 - Router 관점에서의 경우 VRRP, HSRP를 통한 VIP 설정을 통해 Router 장애 발생 시 Stand By router 로 서비스 연속성을 확보 할 수 있도록 한다

 - L2 의 관점의 경우 HA 구성 시 Loop 에 빠지지 않도록 STP를 이용하여 논리적 차단이 필요하다.

 5. DB 관점의 HA

 - DB의 경우 Active-Active 의 cluster 구조 / Primary-Stand By 구조를 예로 들면 Active-Active 구조의 경우 Active 서버의 한 대 장애로도 연속성 유지가 되는 편이지만 Primary-Stand By 구조의 경우 Primary가 장애 발생 시 Stand By 서버로 Fail over 되어 Primary 가 변경되며 평상시에 Data를 Primary 에서 Stand By 서버로 replication 하여 데이터의 무결성 유지하여 Fail Over가 되어도 Data의 정합성 및 무결성을 유지하도록 구성 한다.

 6. 장애 발생 시 대응 방안 

 - 장애 발생 시 서버 / 네트워크 / DB 측면에서 다양한 방법으로 조치가 되겠지만 H/W 기반 장애의 경우 Fail Over를 통한 Stand By 서버로 운영 전환하여 운영하는 케이스가 보편적이며, 서버에서도 App, OS 등의 장애로 서버가 원활하게 작동이 불가 할 경우 Fail over를 통한 운영 서비스 전환 네트워크 및 DB 도 마찬가지로 생각 된다. 

 7. 결론

 - 고가용성은 대고객 서비스 및 대량의 트랜잭션을 다루는 서비스에서는 필수적인 요소이며 나아가 운영 서비스에서는 뗼 수 없는 조건이라고 생각된다. 서버 장애의 발생 확인 시 Fail Over를 통해 서비스 정상화 시도를 하고 서비스의 정상화 유무 확인 및 DB의 경우 데이터의 정합성 및 무결성을 따로 검증하여 고객 및 회사에 금전적인 피해가 없도록 확인 하는 것이 필요하다. 자연 재해 같은 천재 지변에 따라 IDC 자체가 사용이 불가피 한 경우를 대비 하여 DR 환경을 구축하여 장애 상황 발생시 Fail Over를 진행 하는 것도 필요하다.


GPT 피셜 70점 답안------------------------------------------------------------------------


* GPT 피셜 권장 답안에 포함 되어야 할 내용들

1. 고가용성(HA)의 정의

고가용성(High Availability)이란 시스템 구성요소의 장애 발생 시에도 서비스 중단을 최소화하고 정상적인 서비스를 지속적으로 제공하기 위한 시스템 설계 및 운영 기술이다.

핵심적으로 장애 감지 → 장애 격리 → Failover → 서비스 복구 체계를 통해 서비스 연속성을 확보한다.

2. 고가용성의 필요성

  • 서비스 연속성 확보
  • 장애 발생에 따른 다운타임 최소화
  • SLA 및 서비스 가용성 확보
  • 업무 연속성(BCP) 확보
  • 장애에 따른 데이터 및 비즈니스 손실 최소화
  • 고객 신뢰성 확보

또한 업무 중요도에 따라 RTO/RPO를 정의하고 이에 적합한 HA/DR 수준을 설계해야 한다.

3. 서버 관점의 HA

서버 장애에 대비하여 시스템을 이중화하고 장애 발생 시 자동 또는 수동 Failover를 수행한다.

Active-Active

  • 복수의 서버가 동시에 서비스 수행
  • Load Balancer를 통한 부하분산
  • 처리량 및 확장성 확보
  • 한 서버 장애 시 다른 서버가 서비스 지속

Active-Standby

  • Active 서버가 주 서비스를 수행
  • Standby 서버는 대기
  • 장애 발생 시 Standby 서버로 Failover
  • 중요 시스템의 서비스 연속성 확보

주요 구성요소:

Health Check, Heartbeat, Cluster, Failover, Load Balancing

4. 네트워크 관점의 HA

네트워크 장비 및 회선 장애로 인한 단일 장애점(SPOF)을 제거하고 네트워크 서비스의 연속성을 확보한다.

주요 방안:

  • Router 이중화
  • Switch 이중화
  • 회선 이중화
  • NIC Bonding/LACP
  • VRRP/HSRP
  • Routing 이중화
  • Load Balancer 이중화

장애 발생 시 Health Check 및 Routing/Failover 메커니즘을 통해 정상 경로로 트래픽을 우회한다.

5. 데이터베이스 관점의 HA

DB 장애 발생 시에도 데이터 서비스의 연속성을 확보하기 위한 복제 및 이중화 기술이다.

주요 방안:

  • Primary-Standby 구조
  • DB Replication
  • DB Cluster
  • 자동 Failover
  • 데이터 정합성 확보
  • Backup 및 Recovery

특히 DB HA의 핵심 목적은 단순한 성능 향상이 아니라 장애 발생 시 서비스 연속성 확보이며, 성능 향상 및 Scale-out은 별도의 설계 목적과 함께 고려한다.

6. 장애 발생 시 대응

장애 발생 계층에 따라 다음과 같이 대응한다.

Application → OS → Hardware → Network → Storage → DB

장애 발생 시

Detect → Isolate → Failover → Recover → Verify

절차에 따라 대응하며, 장애 원인 및 서비스 중요도에 따라 자동 Failover와 수동 복구를 적용한다.

또한 장애 이후 원인 분석(RCA), 로그 분석 및 재발 방지 대책을 수립한다.

7. 결론

고가용성은 단순한 서버 이중화를 의미하는 것이 아니라 SPOF 제거, 장애 감지, 자동 Failover, 데이터 정합성, 모니터링, 백업 및 DR​을 종합적으로 고려하여 서비스 연속성을 확보하는 체계이다.

따라서 업무 중요도에 따른 RTO/RPO와 SLA를 정의하고 비용과 복잡도를 고려한 적정 수준의 HA 아키텍처를 설계·운영해야 한다.