본문으로 건너뛰기

"professional-engineer" 태그로 연결된 270개 게시물개의 게시물이 있습니다.

기술사 관련 포스트

모든 태그 보기

크리덴셜 스터핑

· 약 3분

크리덴셜 스터핑의 개념

  • 공격자가 미리 확보한 사용자의 계정, 인증정보를 이용하여 다른 사이트에 무작위로 대입하여 정보를 탈취하는 사이버 공격
  • 인터넷 사용자가 동일 로그인 정보를 여러 사이트에서 사용한다는 점을 노린 자동화 공격

크리덴셜 스터핑 개념도, 공격절차, 대응방안

크리덴셜 스터핑 개념도

  • 무차별 대입 공격으로 탈취한 정보를 판매하여 2차 피해 발생

크리덴셜 스터핑 공격절차

구분절차설명
수집백도어 삽입취약점 이용 백도어 삽입
-개인정보 탈취내부시스템의 계정, 인증 정보 탈취
공격무차별 대입 공격계정정보로 무차별 로그인, 권한 획득
-중요정보 탈취중요정보 탈취 후 협박, 유포, 금전 요구
반복중요정보 판매정보를 다크웹에 판매, 공개
-추가피해 발생공개된 정보로 추가 공격 수행

크리덴셜 스터핑의 대응방안

구분방안설명
개인사이트별 고유 계정 사용동일 정보 사용 지양
-다단계 인증 활성화MFA 등 2단계 인증 활성화
-회사 이메일 사용 지양가입시 개인 이메일 사용
기업보안 모니터링트래픽 탐지로 동일 IP 차단
-로그인 시도 제한자동화 공격 방지
-대응 계획 수립개인 보안 조치, 주기적 교육
  • 크리덴셜 스터핑 공격은 자동화되어있으므로, 트래픽 변화, 로그인 실패 빈도 증가 등 선행 징조 확인 필요

크리덴셜 스터핑 대응시 고려사항

  • 공격을 사전에 예방하기 위해 IP보안, 2단계 인증 등 사용성을 고려한 보안 정책 도입 필요

실시간 스케줄링, 우선순위 역전

· 약 3분

Realtime Scheduling의 개념

  • 실시간 스케쥴링은 특정 태스크가 주어진 데드라인 내에 완료되도록 프로세싱을 보장하는 스케줄링 방법
  • 시스템 제약 만족, 예측 가능성, 응답성, Mission Critical 프로세스 처리

우선순위 기반 스케줄링 기법

RM, Rate Monotonic

비율 단조

  • 태스크의 주기가 짧을 수록 높은 우선순위로 스케줄링
  • 스케줄링 예상 가능, 단순 구현, 고정 우선순위, 제한적 CPU 활용, Soft RTOS

EDF, Earliest Deadline First

최단 마감시간 우선

  • 태스크의 데드라인이 가까울 수록 높은 우선순위로 스케줄링
  • 스케줄링 예상 어려움, 높은 CPU 활용, 동적 우선순위, 효율적, Hard RTOS
  • 주기가 짧거나 데드라인이 긴 태스크가 공유 자원을 선점하는 경우 우선순위 역전현상 발생

우선순위 역전현상 개념 및 세부 절차

우선순위 역전현상 개념도

   우선순위
Task1 |
Task2 |
Task3 |
--------------------------------------------> 시간
[ 자원R ]

우선순위 역전현상 세부 절차

순번절차내용
1임계영역 진입Task3은 자원R 사용 위해 진입
2프로세스 선점높은 우선순위의 Task1은 Task3의 임계영역 선점 스케줄링 실행
3임계영역 대기Task3이 진입 중이므로, Task1은 대기
4우선순위 역전중간 우선순위의 Task2가 선점하여 스케줄링, Task1은 계속 대기

우선순위 역전현상 해결방안

우선순위 상속

    우선순위
Task1 |
Task2 |
Task3 |
--------------------------------------------> 시간
[ 자원R ]
  • 임계영역에 진입한 낮은 우선순위 태스크의 우선순위를 진입 대기하는 높은 우선순위 태스크와 동일하게 부여

우선순위 올림

    우선순위
자원 R |
Task1 |
Task2 |
Task3 |
--------------------------------------------> 시간
[ 자원R ]
  • 임계영역 자원R에 가장 높은 우선순위를 부여하고, 임계영역 진입 태스크의 우선순위를 자원의 우선순위로 올림

CPU, GPU, FPGA, ASIC

· 약 3분

컴퓨팅 아키텍처의 개요

  • AI 등 병렬처리와 연산 효율이 필요한 최적화된 칩 수요의 증가로 ASIC 기반의 SoC으로 발전
  • FPGA: 이종병렬성, 설계 유연성
  • ASIC: 최고성능, 효율성

CPU, GPU, FPGA, ASIC 개념 및 특징, 적용분야

CPU, GPU, FPGA, ASIC 개념 및 특징

CPU

  • 복잡한 연산, 순차처리, 범용성

GPU

  • 단순한 연산, 병렬처리, 소숫점 연산 특화/FPU

FPGA

  • 설계 가능한 논리소자, 회로
  • 스위치를 주변으로 CLB가 감싸고 있는 구조
  • 목적별 재구성 가능, 유연성

ASIC

  • 특화 반도체
  • 저전력, 고효율, 대량생산

CPU, GPU, FPGA, ASIC 적용분야

구분분야비고
CPU범용 컴퓨팅웹브라우징, 오피스업무
GPU그래픽 렌더링, 병렬처리게임, 시뮬레이션, 머신 러닝
FPGA맞춤형 H/W디지털 회로 프로그래밍
ASIC특정 작업 최적화, 고성능스마트폰, N/W 장치, AI가속기

FPGA, ASIC 선택시 고려사항

  • 대량생산시 비용 절충점을 고려하여 ASIC 기반 SoC 도입 검토 필요

빅 엔디언, 리틀 엔디언

· 약 3분

빅 엔디언, 리틀 엔디언의 개념

  • 빅 엔디언: 데이터를 메모리에 적재시 메모리 시작 주소에 데이터의 상위 바이트부터 순차 저장하는 방식
  • 리틀 엔디언: 데이터를 메모리에 적재시 메모리 시작 주소에 데이터의 하위 바이트부터 순차 저장하는 방식

빅 엔디언, 리틀 엔디언 개념도, 세부 요소, 적용사례

빅 엔디언, 리틀 엔디언 개념도

빅 엔디언, 리틀 엔디언 세부 요소

구분빅 엔디언리틀 엔디언
저장방식낮은 주소에 MSB부터 저장, 앞쪽부터 스택에 푸쉬낮은 주소에 LSB부터 저장, 뒤쪽부터 스택에 푸쉬
장점우수한 가독성, 디버깅 편의성, 빠른 비교 연산후위 비트만 사용하는 계산 용이, 올림 연산 빠름, 가산기 구현 단순
단점수학 연산 어려움, 타입캐스팅 느림숫자 비교 느림, SW 디버깅 불편
대표회사IBMIntel, AMD

빅 엔디언, 리틀 엔디언 적용사례

구분빅 엔디언리틀 엔디언
N/W 프로토콜TCP/IP 주소 전송N/A
운영체제일부 유닉스 시스템윈도우, 맥, 리눅스
CPU 아키텍처IBM 메인프레임, 모토로라 프로세서x86, ARM 등 대부분 CPU

빅 엔디언, 리틀 엔디언, N/W 측면 고려사항

  • N/W 데이터 전송시 ntohl, htonl 함수를 사용하여 목적지 바이트 순서 변경 필요

리버스프록시, 로드밸런서, 그린 배포, 카나리 배포

· 약 5분

무중단 배포의 개념

  • 유저에게 서비스 중단 없이 새로운 버전의 서비스를 배포하는 것을 목표로 하는 배포 전략
  • 신규 버전 배포시 리스크 최소화, 빠른 롤백, 클라우드 컴퓨팅, 가상화 기술 발전으로 무중단 배포 활용

그린 배포, 카나리 배포의 개념도, 핵심 요소, 세부 절차

그린 배포, 카나리 배포의 개념도

  • 신버전을 모두 배포하고 트래픽을 일괄 전환하여 배포
  • 신버전에 점진적으로 트래픽을 늘려 위험을 감지하고 대응하여 배포

그린 배포, 카나리 배포 핵심요소 비교

구분그린카나리
목적신규버전 트래픽 일괄 전환신규버전 점진적 배포
리스크모든 사용자가 신규버전 즉시 사용리스크 최소화
복잡도일괄전환으로 간단비율 조정으로 복잡
테스트 범위모든 사용자가 새 버전 테스트초기 소규모 사용자만 테스트
배포 시간단시간상대적 장시간

그린 배포, 카나리 배포 세부 절차

구분그린카나리
준비단계신규버전 배포, 테스트카나리 환경 준비 초기 테스트
배포 방식전체 트래픽 일괄 전환소규모 트래픽에서 점진적 전환
모니터링전환 후 트래픽 모니터링점진적 모니터링 오류확인
롤백문제시 전체 롤백필요시 특정 비율 롤백

리버스 프록시와 로드밸런서 비교

리버스 프록시, 로드밸런서 개념도

  • 클라이언트 요청을 내부 서버로 전달하고 서버의 응답을 반환하는 중계 서버
  • 리버스 프록시는 L7 로드밸런서의 기능도 일부 수행
  • 트래픽을 여러 서버에 분산하여 부하를 관리하는 장치 또는 SW

로드밸런서의 구성요소

구분요소내용
유형L4 로드밸런서네트워크 계층이나 전송계층 정보로 부하 분산
-L7 로드밸런서응용 계층에서 헤더, 쿠키 등 요청 기반 정보로 부하 분산
알고리즘Round Robin순차, 순환, 응답시간 빠르고 구성이 간편
-Least Connection백엔드 서버 중 활성화 된 연결 계산, 가장 적은 커넥션을 가진 서버로 로드 밸런싱
-Response Time가장 빠른 응답 시간을 제공하는 서버로 로드 밸런싱
-HashingTCP/UDP 연결시 각 클라이언트에 대한 해시 생성하여 동일 서버 연결, 세션 유지 가능

스프링 부트

· 약 3분

스프링부트의 개념

  • 스프링 프레임워크를 기반으로 하여 쉽게 독립 실행형 어플리케이션을 만들 수 있도록 도와주는 오픈소스 프레임워크
  • 스프링 프레임워크의 복잡한 설정과 구성 문제를 해결하기 위해 등장

스프링부트의 구성도, 구성요소, 비교

스프링부트의 구성도

스프링부트의 구성요소

구분내용비고
내장톰캣서버스프링부트 자체 웹서버독립 실행 가능
컨트롤러사용자 요청 처리, 비지니스 로직 응답 반환RestController 등
서비스레이어비지니스 로직을 처리하는 계층DB연동, 트랜잭션 관리
레파지토리DB 접근하여 CRUD 작업 수행JpaRepository 등
모델데이터 구조를 정의하는 클래스Entity, DTO
  • Spring Starter, Auto Configurator 등 스프링부트 모듈을 활용하여 쉽게 기본 구성 사용 가능

스프링 프레임워크와 스프링부트 비교

구분스프링 프레임워크스프링 부트
설정방식수동설정, XML, Properties 등최소설정, 자동설정
의존성 관리직접 의존성 명시, 관리스타터를 통한 의존성 그룹화, 자동 관리
내장서버없음있음
목적엔터프라이즈 앱 개발 등REST API 개발 등

스프링부트 사용시 고려사항

  • 많은 어노테이션과 추상화된 설정과 라이브러리를 사용해야하므로, 개발자 숙련도를 고려하여 기능 선택 필요

VM, Container, 가상머신, 컨테이너

· 약 5분

가상화의 개념

  • 물리적인 자원들을 논리적으로 표현해 효율적으로 사용하고 관리하기 위한 기술
  • 클라우드 전환으로 자원활용률, 보안성, 확장성 높은 가상화 기술로 서버 제공, 논리적 투명성으로 사용자는 물리적 자원의 세부사항 미고려

VM, Container의 개념도, 핵심요소, 적용방안

VM, Container 개념도

  • VM: 하이퍼바이저를 통해 물리자원을 추상화한 Guest OS기반 가상화
  • Container: Host OS 커널 통해 격리된 컨테이너를 제공하는 가상화

VM, Container 핵심요소 비교

구분VMContainer
핵심기술하이퍼바이저, VM스냅샷컨테이너, 네임스페이스, CGROUP
환경다양한 OS지원, 독점적 자원할당단일 OS지원, 호스트OS커널 공유
장점강한 보안성, 장애 격리, 다양한 OS 실행빠른 부트시간, 이미지 경량화, 자원사용 효율성
단점높은 자원 소모, OS 라이센스 비용커널 공유로 인한 낮은 보안성, 호스트OS 종속성

VM, Container 적용방안

구분VMContainer
보안 및 격리높은 보안성과 격리성이 필요한 경우프로세스 수준 격리와 빠른 복구가 필요한 경우
CI/CDDevOps환경에서 다양한 운영체제 테스트 시나리오 자동화IaC 기반, GitOps의 지속적 통합, 배포
적합 환경기존, 레거시, 모놀리스클라우드 네이티브

가상화시 고려사항

  • 이미지, 스냅샷 레지스트리 관리와 보안 스캐닝을 통해 취약점 사전 조치 필요

컨테이너 취약점

취약점내용대응방안
스푸핑, Spoofing관리자의 인증 정보가 탈취되거나 무단 접근을 시도하는 위협보안 인증 방식(RBAC) 적용, 사용자 계정 관리
변조, Tampering악성 코드를 삽입하거나 데이터 변조를 통해 시스템에 악영향을 미치는 위협이미지 서명 및 무결성 검증, PodSecurityPolicy로 접근 제한
부인 방지, Repudiation감사 및 로그 관리 미흡으로 인해 악의적인 행동을 추적할 수 없는 위협로그 설정 및 관리 강화, 서비스 메시 플랫폼 설정
정보 유출, Information Disclosure중요 데이터(계정 정보 등)가 스니핑이나 오류 메시지 등을 통해 노출되는 위협TLS/HTTPS 암호화 통신 적용, 등급별 접근 제한 (RBAC) 적용
서비스 거부, Denial of Service과부하를 유발하여 서비스 가용성을 저하시키는 위협네트워크 정책 강화, 파드 및 노드에 대한 리소스 제한 설정
권한 상승, Elevation of Privilege일반 사용자가 권한을 초과하여 접근함으로써 시스템을 악용할 가능성최소 권한 원칙 적용, 적절한 계정 및 접근 제어 방안 (RBAC) 실시

웹 기반 서비스 성능관리, 웹 최적화

· 약 3분

웹 최적화의 개념

  • 웹 페이지의 로딩 속도, 응답속도 등 전반적인 성능을 향상시켜 사용자 경험을 개선하는 활동
  • 페이지 로드가 길어지면 이탈률 증가, SEO 지표 증가로 검색 우선순위 개선, 대역폭 사용 감소로 비용 절감

웹 성능 저하요인의 개념도, 세부요인, 해결방안

웹 성능 저하요인의 개념도

웹 성능 저하 세부요인

구분요인비고
브라우저렌더링 최적화 미흡, 많은 자바스크립트 로드렌더링 차단 리소스, 불필요한 JS로드
네트워크많은 리소스 요청, 대역폭 부족대용량 파일, 압축되지 않은 파일, 느린 N/W 속도
서버서버 처리능력 부족, DB 처리능력 부족H/W 성능 부족, 서버 과부하

웹 성능 최적화 방안

원인해결방안비고
대용량 파일이미지 최적화, 압축리사이즈, WebP 압축
많은 HTTP 요청요청 횟수 절감, 병렬처리HTTP2, 이미지스프라이팅
느린 N/W 속도사용자와 가까운 곳에 리소스 배치CDN 사용
느린 서버 응답하드웨어 개선, 튜닝, 부하 분산스케일업, 쿼리 튜닝, 샤딩
렌더링 차단 리소스JS 실행 시간 단축비동기처리, 트리쉐이킹

웹 최적화시 고려사항

  • Page Speed 등 웹 성능 측정도구를 활용하여 최적화 전/후 성능 비교 필요

메모리 인터리빙

· 약 3분

메모리 인터리빙의 개념

  • 메모리 접근시간을 최소화하기 위해 메모리를 복수개의 모듈로 나누고, 각 모듈에 연속적인 주소를 부여하여 동시에 접근이 가능하게 하는 기법
  • 버스의 경합이나 기억장치의 충돌 회피 가능

메모리 인터리빙의 개념도, 유형, 액세스방식

메모리 인터리빙의 개념도

  • 뱅크0 접근, 뱅크0 읽기 및 뱅크1 접근 순으로 병렬 접근

메모리 인터리빙의 유형

구분개념도내용
상위 인터리빙-주소의 상위비트로 모듈 선택, 순차적, 에러시 하나의 모듈 영향
하위 인터리빙-주소의 하위비트로 모듈 선택, 다수의 모듈 동시 접근, 에러 전파
혼합 인터리빙-모듈을 뱅크로 그룹화, 뱅크 선택시 상위 인터리빙, 뱅크 내 모듈 선택시 하위 인터리빙

인터리빙의 액세스 방식

구분개념도내용
C-Access, 순차접근-주소가 버스를 통해 순차적으로 모듈에 도착, 버스 경합 발생가능
S-Access, 병렬접근-읽기 동시 진행, 데이터 순차 전송하여 동시성 확보로 높은 성능, DDR DRAM 적용

인터리빙 고려사항

  • 메모리 접근 패턴, 시스템 성능 요구사항, 비용, 복잡도 등을 고려하여 최적의 인터리빙 방식 선택

정보시스템 하드웨어 규모산정 지침

· 약 4분

정보시스템 하드웨어 규모산정 지침 개념

  • 정보시스템 구축 시 필요한 하드웨어 자원적정 규모를 산정하기 위한 지침으로 시스템 성능 요구사항을 충족하면서 비용 효율적 H/W 자원을 도입하기 위해 사용
  • 경험기반 부정확한 규모산정 사례 증가, H/W 성능 향상으로 인한 기존 표준 개선 요구, 정보화 투자 및 효율 제고

정보시스템 하드웨어 규모산정 개념도, 구성요소, 주요기법

정보시스템 하드웨어 규모산정 개념도

  • 규모산정은 성능요구사항이나 성능을 결정하는 용량계획, 용량관리의 하위 개념

정보시스템 하드웨어 규모산정 구성요소

구분내용비고
용량관리요구사항 충족을 위해 용량계획수립, 비용-용량 균형 제고조직, 지속적
용량계획시스템 성능 요구사항과 성능을 결정하기 위한 계획조직, 시스템, 지속적
규모산정기본적인 용량과 성능 요구사항이 제시되었을 때, 시스템 요구사항으로 반영하는 것시스템, 일시적

정보시스템 하드웨어 규모산정 주요기법

구분내용비고
수식계산법유저 수 등 규모산정 요소 기반으로 용량 수치를 계산하고 보정하는 방법근거 명확, 보정치 오류 가능성
참조법업무량 등 기존 데이터를 기반으로 대략적인 시스템의 규모를 비교하여 산정비교적 안정, 근거 불명확
시뮬레이션법대상 업무에 대한 작업 부하를 모델링, 시뮬레이션하여 규모 산정높은 정확성, 시간 및 비용 소요
  • 공공부문에선 현실적으로 수식계산법을 사용하나, 다른 방법도 필요시 고려

정보시스템 하드웨어 규모산정 대상 및 절차

정보시스템 하드웨어 규모산정 대상

  • CPU, 스토리지는 OLTP, WEB/WAS 등 서버가 받는 부하에 따라 다르게 산정

정보시스템 하드웨어 규모산정 절차

  1. 구축 방향 및 기초 자료 조사
  2. 기초 자료 및 업무 분석
  3. 참조 모델 결정 및 서버 규모 산정
  4. 참조 모델별 가중치 적용

정보시스템 하드웨어 규모산정시 고려사항

  • 구축 시스템의 중장기적 측면 고려
  • 시스템 전략에 맞는 규모 여부 파악
  • 장비 설치 조건의 적합성
  • 기종별 슬롯 수 확인