개념정리

* TCP 3-way-handshake diagram

 

* Windows Server (23.A.1)

a. Administrator 계정의 자격 증명으로 NAS의 네트워크 드라이브를 연결하여 로컬 시스템 계정으로 기동한 서비스에서 접근 (X)

- 작업 스케줄러에 OS 모니터링 스크립트 등록, 사용자 로그온/로그오프

- 세션 로그오프 하더라도 영향을 받지 않고, 서버 기동시 자동 기동 가능

- 부모 자식 프로세스 모두 종료 가능 / 특정 CPU에서만 실행 되도록 설정 가능

 

* run.sh 쉘 스크립트 실행 결과 (23.A.2)

표준에러(stderr)에 대해서도 저장되도록 보완

a. # /scripts/run.sh >> /logs/run.log 2>&1

실행결과가 파일에도 출력되도록 보완

a. # scripts/run.sh 2>&1 | tee -a /logs/run.log

 

* 해킹 상태. TCP 3-way-handshake. TCP Diagram. (23.A.3)

a. 공격 받은 서버에서 netstat -an 명령으로 확인하면 SYN_RCVD 상태가 많이 누적.

- Connection timeout / 공격자 IP 차단 / 클라이언트-서버 간 연결 방식 / SYN 패킷을 보낼 차례

 

* password 정책 설정 파일. minimum password 길이. (23.A.4)

a. /etc/pam.d/system-auth 

- 기본 password 정책은 /etc/login.defs 에서 설정. PAM 모듈의 system-auth 파일 수정으로도 (password 길이, 대소문자, 특수문자 etc)가능.

 

* kubernetes 컨테이너 환경 로깅 아키텍처. 로그 점유 용량. 사이드카. (23.A.5)

a. 클러스터 레벨 로깅 아키텍처 / Pod, Container, Node 종료 경우에도 로그에 접근 가능하도록

a. Node에서 사용 가능한 모든 스토리지 용량을 로그가 점유하지 않도록 logrotate 설정 / 적용

a. 로깅에 대한 기능은 별도 컨테이너에 위임하는 사이드카 패턴 적용

Pod 내에서 컨테이너 간 볼륨 공유 가능하도록. Pod 삭제 될 때 함께 삭제.

a. varlognginx / emptyDir: {}

 

* VMWare 솔루션. (23.A.6)

a. vMotion 시 가상 머신의 MAC 주소값과 물리적인 스위치 포트 매핑 변경에 대한 RARP 요청이 브로드캐스팅 됨됨

- 재해복구 사이트 구축, 데이터센터 이전 > SRM

- CPU Affinity 설정하면 vMotion 불가

- VMDK는 가상 머신 디스크 파일. 설정을 저장하는 텍스트 파일은 VMX(가상 머신 구성 파일).

- RDM 방식의 경우에도 vMotion 가능

 

* HCI 구조 아키텍처. (23.A.7)

a. HCI에서 X86 Server 수량이 많아질수록, 스토리지 I/O의 성능은 이론 상 점차 저하 (X)

- HCI에서 더 많은 디스크가 필요 / 파일시스템은 둘다 동일하게 생성 / HCI 데이터 복제 가능 / SAN&NAS 동시에 단일 LUN 사용 불가

 

* Web 서버로 서비스 연결 불가. telnet, curl 수행. (23.A.8)

a. Web 서버의 서버 프로그램이 내려갔거나, 8080 port 가 Listen 상태가 아님. > (1-2초수행)  connection refused 에러는 방화벽 정책에서 해당 포트가 오픈되서 외부에서 연결가능하나 포트에 서비스 daemon 이 구동 안 되어 발생하는 경우

- Web 서버가 구동 중인 VM 다운 & Web서버로의 라우팅 경로 찾지 못함 & 방화벽 Drop > (수십초간 연결시도) connection timeout 이 발생

 

* root 계정의 .bash_profile 설정. (23.A.9)

a. $(uname -n)에 사용한 쌍따옴표는 생략해도 동일 동작 > "$(uname -n)" 과 $(uname -n)은 동일

- Alias가 아닌 Function / 상대 경로가 아닌 절대 경로 / root 계정의 bash_profile은 다른 계정과는 연관 없음 / bash_profile은 cron과 연관 없음

 

* API G/W 에 자원 사용율 차이가 발생하는 원인. (23.A.10)

a. LB SLB 정책에 의해 부하가 API G/W 2로 덜 들어감 (Hash 정책이나 Sticky 세션)

a. VMWare 물리 서버 BIOS/Hypervisor/OS의 전원 정책 설정 차이

a. API G/W 솔루션의 구성/설정이나 소스 배포가 다르게 되어

 

* Public Cloud 상에 서비스의 가용성을 높이는 다중화와 DR 구성 방안. (23.A.11)

a. AWS의 복제 지연시간을 줄이기 위해 Aurora mysql에서 RDS mysql로 변경 (X) > 반대

- 블루그린은 자원 사용률 2배 / 데이터 손실 대비를 위해 AWS DynamoDB 고려 / S3 bucket에 replication rule을 적용할 때 기존 데이터는 batch replication을 통해 동기화 해야함 / 재해 상황에 신속한 기동을 위해 IaC를 활용하여 구성

 

* $HOME 이 아닌 Host OS의 /home에 볼륨 마운트. 컨테이너 보안. 컨테이너 실행 권한. (23.A.12)

a. Host OS 상에서 UserB의 디렉토리에 UserA가 접근하지 못하도록 권한을 강화 (X) > 컨테이너 실행시에 root 계정으로 실행이 되어서 아무리 디렉토리 권한을 강화해도 소용 없음.

- Host OS의 볼륨 마운트 시에는 경로 입력을 제대로 / 컨테이너 실행 시 사용자 ID를 지정하지 않으면 HostOS의 root 권한이 컨테이너에 그대로 적용 / --userns-remap 옵션으로 UID GID 매핑하여 root 사용자와 격리 / root mode로 컨테이너를 실행하면 보안이 취약해짐. rootless mode로 컨테이너 엔진 설정

 

* AWS EC2에서 disk I/O가 발생. 여유 스토리지 공간은 전혀 없는 상태. (23.A.13)

a. 할당된 EBS 볼륨이 적다

 

* AWS 배치 테스트. EKS 기반 RDS. Master - Slave 구조. (23.A.14)

a. AZ #1에 Read Replica를 생성하여 Read Call은 Replica를 활용 (X) > 해당 내용은 AWS RDS의 Read Replica에 대한 개념으로, 트래픽 분산 처리와 관련된 기능.

- 이슈는 AZ 간의 RTT 지연(AZ #1로 Affinity 설정 추가)에 따른 / DB Call 횟수에 따른(DB Call 횟수 줄이기 위해 Cache 처리, 반복적으로 Read하지 않고 한번에 가져오도록 로직 수정) / Fetch 건수(Fetch 사이즈 조정)에 따라 발생.

 

* 미들웨어. 클라우드나 컨테이너와 같은 새로운 플랫폼 상에 신규 아키 구축. 고려사항. (23.A.15)

a. WAS의 경우. Auto Scaleout 환경에서 세션 클러스터 기능을 사용한다면. dependency가 발생하는 별도 세션 서버 방식보다 동적으로 세션 복제를 할수 있는 Peer to Peer 방식 권장 (X) > 클라우드 환경에서는 P2P 세션 클러스터 방식보다. 분리된 별도의 세션 서버 방식이 올바름.

- 서비스간 약결합 구성 바탕의 MSA 기반 설계 검토(MOM을 통해 구현) / 클라우드 환경에서 리소스 변경이 용이하나, 성능 이슈 등의 이유로 JVM 설정에 대한 변경이 없다면 증설 효과를 보기 힘듦 / PaaS 관리형 서비스를 검토하면 직접 설치와 방식과 비용 비교 필요 / OSS 위주로 구성하는 것 검토

 

* Nginx 서버에서 502 Bad Gateway 오류 발생. (23.A.16)

a. upstream 서버로의 연결 상태를 확인. > 502 bad gateway 에러 코드는 게이트웨이, 프록시 역할을 하는 서버가 다른 서버로부터 유효하지 않은 응답을 받았을 때 나타남.

 

* MSA 아키텍처 패턴. Backend와 Frontend를 분리하고 서비스는 API만 리턴하는 구조. Client Side LoadBalancing BFF / Server Side Load Balancing BFF (23.A.17)

MVC 패턴 대비 부하 감소. 네트워크 트래픽 감소. > 장점 

내부 구성요소가 클라이언트 서비스에 노출. 개발범위 증가의 부담. > 단점

a. Client Side Load Balancing BFF 

a. 기존 구성보다 뛰어난 성능. (X)

- MSA Outer Architecture 구성요소 전체를 포함하는 아키텍처 패턴은 service mesh 때문에 부하가 몰려 성능이 느려질 수 있고, 시스템의 런타임 인스턴스 수가 증가 할 수 있음.  / Service Mesh로 관리하면 Client Side 구성보다 개발 부담 복잡성이 해결되고 보안을 강화할 수 있음

 

* MSA Outer Architecture에서 Telemetry를 사용하는 주된 이유 (23.A.18)

a. 개별 Micro Service의 성능과 가용성을 모니터링하여 빠른 대응 및 최적화를 가능하게 함

- 서비스에 대한 호출과 트랜잭션 관리 / 보안 및 안정성을 강화 / 확장성과 유연성을 높임 / 통신 및 데이터 전송을 최적화 > 모두 마이크로 서비스의 중요 이점. Telemetry와는 관련이 적음.

 

* RDBMS를 주로 사용하는 모놀리식 아키에서는 crud를 하나의 도메인 모델로 구성. 이를 MSA로 분리할 경우. CQRS 패턴 활용. Read와 CUD를 분리. (23.A.19)

a. 쓰기 작업이 실패한 경우, 롤백을 수행하거나 재시도하는 방식으로 회복성 보장 (X) > SAGA 패턴 설명

- CQRS는 CUD와 R을 분리하여 조회성 데이터의 성능을 향상 시킴 / Read에서 Cache를 제공하여 RDBMS의 부하가 줄지만 통계와 같은 대용량 데이터 처리는 부적합 / 서비스간 책임 분리 / 서비스를 수평적으로 확장하기 용이 / 서비스간 결합도를 낮추고 유연성을 높임

 

* AI 분산학습 인프라 아키텍처 설계.  (23.A.20)

a. 분산병렬 스토리지 (메타데이터와 Object 데이터를 분산 처리하여 대규모 데이터셋을 처리할 때 많이 사용, API 기반의 파일 접근)

a. LVLink (GPU 카드 간에 통신 경로 최적화. 고성능, 고효율 통신경로 확보)

a. InfiniBand 스위치 (GPU 노드 간의 고성능, 고대역폭, 낮은 지연의 통신경록 확보, GPUDirect RDMA 통신 및 MPI 통신 최적화)

 

* Windows Server. 디스크 관련 정보. GPT / MBR (23.B.1)

a. Disk0 으로 부팅될 경우, 부트 섹터를 거치지 않고 파티션에서 바로 부트 로더를 실행. > Disk 0 는 GPT 파티션 구조. 부팅모드가  UEFI이며 EFI 시스템 파티션에서 부팅 로더를 실행하여 운영 체제를 시작.

- 디스크 크기 보다 파일시스템 용량은 더 작을 수 있음(파티션 나누면) / GPT 파티션은 주파티션 128개까지 생성 가능 / GPT 파티션은 2TB 이상의 디스크 크기를 지원 

- MBR과 GPT 파티션을 혼용해서 부팅디스크로 쓰면 안됨 / 하지만 그냥 혼용해서 사용하는것은 가능

 

* Linux FD(File Descriptor)에 관한 개념. (23.B.2)

a. Ulimit 명령어로 FD의 soft limit과 hard limit을 설정할 수 있지만 현재 쉘만 적용. > ulimit 명령어는 일시적이며 현재 세션에만 적용됨. 그리고 서버 재부팅을 해도 원복됨.

- FD 값은 3부터 순차적으로 부여 (0은 stdin / 1은 stdout / 2는 stderr) / 최대 오픈 가능한 파일수를 초과하면 Time out open files 에러 발생 

- /proc/sys/fs/file-max 파일 값을 변경하면 FD 최대 개수 변경할 수 있지만 영구적으로는 X > 영구 적용은 sysctl -w fs.file-max 명령어 혹은 /etc/sysctl.conf 파일 수정

- /etc/security/limits.conf의 nproc은 프로세스 생성 최대 개수 제한. nofile으로 FD 최대 개수 설정 가능.

 

* 라우팅 테이블. 203.10.100.77가 외부망 DMZ IP. 내부망 IP(165.100.10.34)로 통신해야하는 특정 대역 및 IP 만 라우팅 테이블에 등록하여 사용. (23.B.3)

a. Active Route에 있는 일부 경로를 Persistent Routes에 추가 > 리부팅 해도 라우팅 경로 적용 되어 있도록

 

* Kfaka 이슈 및 개선사항. (23.B.5)

a. service network를 통해 replication이 이루어지고 있어 대량  메시지 처리로 인한 commit 지연 시 replication 부하로 인해 network 전체 병목이 발생 / Rplication-Broker network를 분리 구성하여 성능개선

a. replication factor가 3이라 2대의 broker가 동시 장애가 나면 min ISR 2를 만족시키지 못하므로 비정상 / replication factor를 4로 늘리고 min ISR은 2로 유지하면 broker 2대가 동시 장애가 나도 정상적인 서비스 가능

 

* VMWare 가상화. (23.B.6)

a. Datastore - 가상머신파일을 저장하기 위해 사용되는 논리적 컨테이너 / VMFS - 블록스토리지를 제공하고 여러대의 호스트에서 공유 가능. snapshot, clustering, vMotion 기능 지원 / VMDK - 파일 형식으로 가상 디스크를 저장 / vVols - 를 이용하면 개별 가상 머신이 스토리지 관리 단위가 되어 볼륨 장애 시 영향도 차단

 

* 스토리지 / 백업 솔루션 (23.B.7)

a. NVMe 프로토콜은 PCI-e를 통한 로컬 SSD 연결에 국한되지 않고 NVMe-oF를 통해 다양한 네트워크들을 이용하여 장치들을 연결 가능 > 파이버 채널과 이더넷 같은 네트워크를 통해 네트워크 상에 존재하는 NVMe 장치에도 접근할 수 있음

- SAN NAS에 단일 LUN을 동시 사용은 불가 / 백업시간이 준다고 복구 목표시간이 주는 것은 아님 / thin provisioning 방식이 효율적 / 중복 제거율이 높고 자주 백업 받는 데이터는 VTL / 압축률이 낮고 장기 보관할 데이터는 VTL에 보관

 

* 리눅스 운영체제. 프로파일링 도구. (23.B.8)

a. pstack은 동적으로 할당되는 stack 메모리 영역을 tracing하여 메모리 누수를 진단(X) > stack은 컴파일 시 컴파일러가 자동할당. 자동으로 할당/해제 되어 메모리 누수 미발생. 지역 변수 및 함수호출에 사용

- heap 메모리는 프로그램에서 필요한 만큼 동적할당. 메모리 누수 발생. 동적으로 변하는 데이터 구조 및 데이터 저장 / strace는 시스템 콜을 추적하여 프로그램이 어떤 파일, 소켓, 파이프 또는 시그널을 사용하는지 알 수 있음 / nmon은 CPU,메모리, 디스크 I/O, 네트워크 I/O등의 성능 정보를 실시간으로 수집하고 그래프로 시각화하여 보여줌. CSV 파일형식 가공 가능 / perf는 linux 커널 성능 분석 도구. / tcpdump는 네트워크 트래픽을 캡처하여 헤더,패킷데이터정보를 분석하는데 활용

 

* bash shell 스크립트.

a. 원격 접속에 사용되는 관리 포트 접속용 계정은 XCC_LIST.txt 내 작성된 모든 서버가 동일 > 'USERID@${XCC_ip}' 로 접속하기 때문에 USERID는 변수가 아님. 모두 동일 계정.

- XCC_LIST.txt 의 구분자는 콤마(,) / 원격 접속 실패경우 스크립트 계속 진행 (continue) / 블필요한 문제 제거는 sed / awk 를 보면 공백으로 출력하기 때문에 일련번호,serverity,발생일시는 제외하고 이벤트만 출력

 

* TCP Connection 에러. 수만 건 처리시 빈도 증가. Client IP/Port 중복으로 연결 거부. (23.B.10)

a. 방화벽이 단일 IP NAT 이기 때문에 TCP 연결이 수만개 이상으로 많아지면 외부기관 입장에서는 ClientIP/Port의 중복으로 생각. / NAT IP 개수를 늘리거나, WAS 서버 별로 Client Port 범위를 다르게 지정(리눅스 커널 파라미터 지정). 

 

* AWS 시스템 구축. 아키텍처. (23.B.11)

a. 인스턴스에 연결된 볼륨 1개의 물리적인 오류에도 정상적인 서비스가 가능한 구성이어야함 / 서로 다른 AZ에 EBS 볼륨을 각각 하나씩 생성. EC2 인스턴스에 생성한 EBS를 모두 할당한 후 Linux OS의 DM-Mirror 기능을 활용하여 이중화 구성. (X) > 다른 AZ에 있는 EBS에는 EC2를 붙일수없음.

 

* Docker 컨테이너. containers 디렉토리 용량. (23.B.12)

a. /etc/docker/daemon.json 파일에 log rotate 옵션을 추가 후 Docker 데몬을 재시작하면, 기생성 되었던 컨테이너들도 Log rotate 설정이 적용됨 (X) > 기 생성되었던 컨테이너들은 새로 생성하거나 내렸다가 올려야함.

 

* GCP Compute Engine 인스턴스와 디스크 성능 최적화. (23.B.13)

a. 인스턴스가 위치한 서브넷

- 연관 있는 것은 인스턴스와 디스크의 위치, 디스크 유형, 인스턴스 머신 유형, 디스크의 수량, 크기

 

* 클라우드 성능 테스트. EC2. (23.B.14)

a. EC2를 m6i.2xlarge 에서 c6i.2xlarge 로 변경 (X) > C시리즈 특성은 컴퓨터 집약이기 때문에 io개선과는 연관이 적음.

- EBS를 EFS로 변경 / 프로비저닝과 동시에 최대 성능을 발휘하기 위해서 스냅샷에 빠른 스냅샷 복구를 활성화 / Auto Scaleing용 Warm pool을 설정 / Scale Out 후 임의의 IO를 발생시킨 뒤에 응용프로그램을 기동

 

* 미들웨어 설계, 구축 및 운영. (23.B.15)

a. web서버에서 404에러가 발생한 경우 관련 파일/페이지의 권한이 적절한지 확인 (X) > 404는 파일/페이지가 없는 경우 발생. 403에러가 권한이 적절하지 않을때.

- 401(Unauthrized)는 아예 로그인 하지 않은 채 무언가를 요청할때 / 403(Forbidden)은 로그인은 하였는데 해당 계정의 권한이 부족하여 거절될때

 

* 거래 처리 시간이 지연되는 문제. 리소스 사용량은 정상 범위. 로그분석을 통해 웹 서버에서 애플리케이션 서버로의 요청 처리 시 Keep-Alive 기능이 적절하게 작동하지 않고 있음 확인. (23.B.16)

a. 성능 저하 원인: 매 요청마다 TCP 연결이 생성 되어, 연결 설정 및 해제에 많은 시간이 소요됨.

a. 해결 방안: Keep Alive 활성화를 통해 트랜잭션 특성에 따라 일정시간 재사용 가능하도록 함.

 

* istio 서비스 메쉬. sidecar 패턴으로 사용중. 시작 직후에 일시적으로 다른 서비스로부터 요청을 받지 못하는 문제가 발생. (23.B.17)

a. 원인: 서비스 컨테이너와 sidecar 컨테이너가 동시에 기동되기 때문에 sidecar 컨테이너인 Envoy 프록시가 준비되기 전에 서비스 컨테이너가 요청을 받음

a. 수정 방안: 서비스 container에 readinessProbe를 설정 / 서비스 시작 script에서 envoy proxy 연결 시까지 서비스 대기하도록 함

 

* API Gateway 도입시 조건(각 서비스간의 완전한 책임 / 인증 권한 요구사항이 복잡하여 각 마이크로서비스는 요청에 대한 보안 검사를 수행해야함) 고려할때 가장 적절한 솔루션 (23.B.18)

a. 각 마이크로서비스에 대해 개별 API Gateway를 구성하되, 인증 및 권한 부여를 별도의 공통 서비스로 처리한다.

 

* 마이크로서비스에서 데이터베이스와 연결(소수의 인원만 접근 가능하도록)할 때. 적절한 구성 옵션. (23.B.19)

a. Secret을 사용하여 각 환경별 데이터베이스 연결 정보를 저장하고, 컨테이너에 환경 변수로 주입. 

- Secret와 Congmap 모두 가능하지만, 문제에서 보안을 강조했으므로 Secret

 

* NVIDIA GPU카드. Deep Learning 모델 개발. GPU Driver를 설치하려고 함 (23.B.20)

a. NVIDIA GPU 드라이버 설치시 사용 Installer 포맷 > Runfile Installers, Package Managers, Containerized Drivers

a. Package Manager를 활용하여 NVIDIA GPU Driver를 설치하려고 할 때, 컨테이너 내의 CUDA Toolkit 버전과 충돌을 방지하기 위해 사용가능한 메타 패키지 명 > cuda-drivers

 

* Windows 2016 의 세션, 프로세스, 서비스 (22.n.1)

a. Windows Service가 기동한 프로세스는 0번 세션에 속하며, 이 세션은 사용자와 격리됨

 

* 리눅스 시스템에서의 사용자 인증 권한관리 (22.n.2)

a. 리눅스에서 사용자 인증과 접근제어를 관장하는 모듈 중 pam_rootok.so 는 UID=0 인 사용자를 인증하는 역할을 하며, root가 패스워드 입력없이 서비스에 대한 접근을 허용할 때 주로 사용.

- pam_rootok는 UID가 0이면 사용자를 인증하는 PAM 모듈

 

* AWS VPC 정보를 보니 IPv4 CIDR이 10.99.18.0/23(서브넷 주소 계산기 활용). (22.n.3)

a. 보조 CIDR을 추가하지 전에는 10.99.19.25 인 IP를 사용할 수 없음 (X) > 해당주소는 CIDR 주소 범위에 포함됨. 그냥 사용 가능.

 

* linux OS 보안 취약점 점검 항목. (22.n.4)

a. $PATH에는 "."을 포함하여 꼭 필요한 경로만 등록하여 사용 > 명령어 파일을 가장한 악의적 파일이 실행되는 것을 방지하기 위해 $PATH에 . 포함하면 안됨.

a. 계정의 홈 디렉토리의 소유자는 해당 계정이어야 하나, 홈 디렉토리가 반드시 존재할 필요는 없다 > 홈디렉토리는 반드시 있어야함. 로그인시 임의의 디렉토리로 로그인되어 악의적으로 사용 가능. 

- 기본 환경 파일(/root/profile, /etc/bashrc 등)과 주요 설정 파일(rc.local, cron, hosts 등)은 root 계정으로만 수정 / 악의적인 파일 삭제 방지를 위해 /tmp 디렉토리는 Sticky bit(1000)을 설정. / 소유자 이외의 수정권한 부여되지 않으려면 umak 022로 설정 > 계산해보기

 

* 시스템 테스트 총괄계획서.(22.n.5)

a. 사전 합의한 성능 측정 기준을 충족하면서 요구 성능목표에 도달하는지 확인하고 성능 개선항목을 도출하여 개선.

a. 시스템의 최대 처리량을 확인하고, 용량 임계 상황시 발생할 수 있는 현상 및 취약점을 점검하고 개선 (핵심업무 최대 처리건수 / 과부하상태에서의 서비스 응답시간 / 자원 사용률 및 경합 현상 / 시스템 성능 변화 모델)

a. 내구성 테스트 / 대량 부하 장시간 지속에 따른 이상 현상 / 자원 leak 발생 여부 / 자원 사용률 변동 추이

a. 주 센터의 기능을 DR센터로 이관하는 데에 소요되는 시간 (RTO)

 

* HBA SAN 스위치. (22.n.6)

a. 단일 SAN 스위치 포트 상에 다수의 WWN이 인식되기 위해서는 NPIV 설정을 활성화 > 동일한 포트에 2개 이상의 WWN이 로그인 되어야 하므로 NPIV 활성화

 

* RAID 구성. (22.n.7)

a. RAID5와 RAID6은 패러티 개수 차이. RAID5는 1개, RAID6은 2개로 오류 발생률이 차이남.

a. RAID10은 RAID1 구성 후 RAID0으로 Stripe하는 방식으로 안정성은 RAID1과 동일 

a. 스토리지 HDD에 데이터가 기록되전에 (캐시 메모리)에만 써도 스토리지는 서버에서 쓰기 완료가 되었다고 응답.

 

* Oracle Tablespace 증설 외장 디스크 추가 (22.n.8)

a. echo 1 > sys/block/sdau/device/delete (X) > 디스크 제거

a. systemctl restart multipathd (X) > daemon reload를 해야함

a. multipath -f mpath 7 (X) > 디스크 제거

 

* Bash Shell 스크립트. crontab에 등록하여 사용. (22.n.9)

a. 홑따옴표는 쌍따옴표로 수정해야 함 > 변수를 홑따옴표를 쓰면 특수기호 있는 그대로 출력하기 때문에 쌍따옴표 사용해야함.

a. Crontab의 환경변수 PATH에 경로가 포함되어 있다면 절대경로를 사용하지 않아도 Crontab에서 정상수행됨 > crontab도 환경변수 PATH를 사용함

- Bash Shell 산술 연산 구문은 "$(())" 혹은 "expr" 사용해야함

 

* 지연 원인과 개선안. DB. RPO. MES AP. 동기 복제 방식을 사용한 이중화 구성. MS-SQL.(22.n.10)

a. Sync 방식의 복제 구조 기반 이중화 구성 시 Target 측의 IO,CPU 등의 이슈로 지연이 발생하는 경우 원래의 Transaction 속도에 영향을 줄 수밖에 없는 구조. / 스토리지를 하이엔드로 교체하거나 ASYNC 방식의 복제 DB를 신규로 구성

 

* AWS 기반 재구축. WAS에서 Thread Dump를 보면. LRedisCacheAdaptor.add / util.SessionUtil (22.n.11)

a. 지연구간 : 함수 패턴을 보면 ElasticCache for Redis에서 지연 발생. / 원인: t2.small 은 cpu/mem 사양과 네트워크 대역폭이 낮음. 자원의 제약으로 인한 병목 / 개선: was 자체의 local cache로 변경 / t2.small 타입을 높은 사양으로 수직 확장 / replica의 개수를 늘리거나 shard를 늘리는 수평 확장

 

* AWS의 비용 최적화. 예약 인스턴스(RI). Savings Plans. (22.n.12)

a. Convertable RI는 사용 중에 인스턴스 패밀리, 플랫폼, 테넌시, 결제 옵션, Region을 변경 가능.(X) > 리전은 변경 불가

a. 요구사항 변경으로 구매한 예약 인스턴스가 필요없을 때 RI는 재판매 불가(X) > 수수료를 부가하여 재판매 가능.

- 플랫폼, 테넌시, 결제옵션 / Regional RI는 같은 Region 내 인스턴스 사이즈 상관 없이 할인 적용 

 

* AWS 기반. ALB HTTP, HTTPS. SSL 터미네이션. (22.n.13)

a. HTTPS, TCP, 443, sg-alb: ALB로부터 HTTPS를 수신하기 위해 ALB 보안그룹 ID를 소스로 지정 > HTTPS는 ALB에서 Termination 되었으므로 EC2는 HTTP를 받음.

 

* JVM의 OOME. Transaction 유실. 컨테이너 Scale Out. gc log와 덤프를 볼 수 없음. (22.n.14)

a. 덤프 경로는 EFS 같은 공유 저장소에 구성.

a. GC로그 정보는 EFK 등의 통합 로그 저장소에 구성.

- JVM의 OOME는 Container Limit과는 관계없고 java -Xmx Heap memory 영역을 늘려주어야함.

- OOM과 미리 Scale Out하는 것은 연관 없음.

 

* 미들웨어 영역. (22.n.15)

a. 3-Tier 구조에서 정적 컨텐츠는 WAS 서버에서 처리 (X) > web서버에서 처리.

- TP-Monitor 미들웨어는 트랜잭션 처리/관리에 특화된 제품. / ESB는 기업내의 다양한 디지털 서비스를 상호 간에 연결하기 위한 기술

 

* WEB/WAS 성능 관련 요소. (22.n.16)

a. WEB 서버의 MaxClients 설정은 최대 접속 가능 connection 수를 의미하며, 일반적으로 사용자 한 명 당 Web Server Thread 한 개가 할당 (X)> 보통 사용자 한명이 여러개의 Web Server Thread를 사용.(2-4개 사용)

a. DB Connection Pool은 WAS의 요청 시에 대기하는 것을 최소화하도록 WAS의 최대 Thread 개수보다 크게 설정해야함 (X) > DB Connection Pool의 최대 연결 개수는 WAS의 최대 Thread 개수를 넘지 않도록 설정.

- Keepalive 타임아웃을 너무 크게 설정하면 서버에 연결된 네트워크 연결 수가 크게 증가하고, File Descriptor 사용 수도 같이 증가하여 한계 도달시 네트워크나 파일을 열수없어 에러 발생 > Keepalive 타임아웃을 크게 설정하면 이미 연결된 네트워크들에 대해 오랫동안 연결을 지속하기 때문에 연결수가 매우 증가하게 됨.

- was 서버의 maxThread를 너무 크게 설정하면 Thread간 Context Swiching이 빈번하게 발생. 오버헤드 발생.

- was와 DB사이에 방화벽이 있거나 Idle session timeout이 짧게 설정되어 있으면 Idle DB connection이 비정상적으로 끊어져 응용에러 발생할 수 있음.

 

* MSA를 구현하기 위한 Inner Architecture 와 빠른 개발, 테스트, 배포, 운영, 확장성 확보 등 기능적, 운영적 관점의 Outer Architecture. (22.n.17)

a. Telemetry는 서비스 진단 및 모니터링을 위해 서비스간 비동기 통신, 이벤트 전달 등을 위한 Message Queue / MOM 기반 서비스를 제공 (X) > Backing Service에 해당하는 설명.

- Telemetry / Service Mesh / CICD / Backing Service / 

 

* MSA. OSS로 ELK Stack을 주로 사용. (22.n.18)

a. 대량 로그 수집에 따른 과부하 / Logstash 앞단에 Buffer(Redis,Kafka 등)를 둔다

 

* MSA. Telemetry를 위한 정보수집 방식. Pull, Push 방식.(22.n.19)

a. 모니터링 서버가 서비스에 접근하여 Metric을 수집하는 방식 / 중소규모 환경 / Prometheus

a. 서비스별로 agent를 설치하여 모니터링 서버로 Metric을 전송하는 방식 / 대규모 환경 / Graphite

 

* AI 산업의 급격한 발전에 따른 인공지능 프로세서. (22.n.20)

a. CPU-GPU간 Direct 상호 통신 링크를 위해 PCIe로 연결하여 병렬 작업 부하를 Off Load 할 수 있음 (X) > NVLink에 대한 설명 

a. TPU는 프로세서에 직접 메모리를 배치하여 데이터 지연과 대기시간을 최소화하는 도구 (X) > IPU에 대한 설명

- FPGA / NPU는 GPU에 비해 범용성이 떨어짐 / 그래프코어의 IPU

 

* Linux Shell 명령 실행 방식. (22.n+1.1)

a. alias rm 명령만 수행 시점에서 rm 수행 결과와 alias rm / function rm 모두 수행했을 때 rm 수행 결과는 서로 다름 > alias가 fuction 보다 우선순위가 높아 두 경우 모두 rm -i 가 실행되긴 하지만, 모두 수행한 경우는 rm -i 의 rm은 function의 rm이 실행 됨.

- root cron에 $PATH 에 /usr/bin이 포함되어 있어, 절대 경로 없이도 rm  명령 사용할 수 있음. / type 명령어시 /usr/bin/rm 이런식으로 나오면 파일시스템 파일명령어임. builtin 명령어 이면 shell built in 으로 나옴. / 함수는 쉘스크립트 실행시 적용되지 않음 (export -f [함수명] 를 사용해야함)

 

* Linux OS 의 파일 및 디렉토리 권한. (22.n+1.2)

a. 파일명 맨앞에 마침표(.)가 있으면, Hidden File이 되어 ls -h 옵션을 주어야 볼 수 있음 (X) > ls -a 옵션으로 조회해야함

a. A서버 user1 계정이 B서버 user2 계정으로 패스워드 입력없이 ssh 접속을 허용하기 위해서는 user2 계정의 ~/.ssh/authorized_keys 파일 내에 user1의 private key 내용을 넣음 (X) > user1의 public key 내용을 넣어야함

- 쓰기 권한이 없는 파일을 vi로 편집하여 저장하면 read-only라고 뜨며 저장되지 않지만 root 경우 예외적으로 :wq!와 같이 느낌표를 추가할 경우 저장이 가능

- 디렉토리에 실행 권한이 없으면 cd /디렉토리 이동이 불가 

 

* 서버 이중화. 네트워크 설정. Teaming 티밍.(22.n+1.3)

a. 별도 인터페이스가 없다면 Server#1에서 총 6개의 활성화된 네트워크 어댑터가 조회됨 > 서버에서 네트워크 어댑터를 조회하면 6개.(물리 NIC 4개, 티밍용 NIC 2개)

- Teaming 구성시, nic별로 IP는 필요하지 않으며 Teaming용 1개 필요

- 대역폭을 늘리려면 Link Aggregation 설정 별도로 필요 / Cluster Service IP는 한쪽서버에만 Alias로 할당됨 / Default Gateway는 Service Network 용 1개만 등록

 

* iptables. Linux 환경. (22.n+1.4)

a. INPUT 정책과 함께 해당 IP, 포트에 대해 output 정책도 추가하여야함 (X) > INPUT은 들어오는 패킷만 통제

a. 서비스 포트가 포함되어 있지 않음 > dport:1024는 1024 이하의 모든 포트 허용

 

* 3-tier 아키텍처. Web,WAS,DB 서버 이중화. 스토리지 및 데이터 저장방식 개선. 백업환경 및 수행방식 개선. (22.n+1.5)

a. Session Clustering 적용하여 WAS 서버 이중화 or 별도의 Session Server 도입 및 WAS 서버 이중화

a. Oracle RAC 구성하여 DB 서버를 이중화 구성

a. DAS 방식에서 SAN 방식으로 변경하여 확장성, 유연성 확보

a. NAS Gateway 도입하여 외장 스토리지에 WAS 첨부파일 저장 / 백업솔루션 / VTL, PTL 백업장비 

 

* VMWare vSphere 서버 가상화 환경. DB Cluster 구성하기 위해 RDM(Raw Device Mapping) 기술을 사용. (22.n+1.6)

a. RDM 사용시 vMotion 기능 사용 불가 (X) > 사용 가능.

a. SCSI 시리얼 번호 정보를 제공하지 않는 Block 장치(Direct-Attached 장치나 RAID 장치)로도 RDM 구성 가능 (X) > RDM은 SCSI 시리얼 번호를 기반으로 동작함

- RDM 은 가상서버가 물리적 스토리지 LUN에 직접 접근 할 수 있음 / RDM은 별도의 vmfs 볼륨에 위치하는 Mapping 파일로 물리적인 장치 (LUN)을 관리하고 접근을 Redirect 하기 위한 Metadata를 포함하고 있음 / Write 작업 충돌을 방지하기 위해 Lock 기능을 제공하는 Oracle ASM이나 MS CSV와 같은 Cluster Filesystem 구성이 필요

 

* DB 서버 Active-Standby 이중화. 운영중에 개발환경이 필요하여 Stanby 서버를 개발 DB로 사용. Active DB 장애가 발생하여 운영 DB의 fail over는 정상적으로 이루어 졌으나. 개발 DB가 Down. (22.n+1.7)

a. Fail-over 시 파일시스템이 Standby 서버의 /data/에 마운트 되면서 /data 디렉토리 하위에 있던 파일들을 사용하지 못하게 됨

 

* 리눅스 I/O scheduler. IO 스케줄러. (22.n+1.8)

a. Deadline 스케줄러는 데이터베이스 파일시스템과 같이 몇몇 프로세스가 많은 IO를 발생시키는 환경에 적합

a. CFQ는 프로세스마다 작업 queue를 가지고 있고, 이것들이 Round Robin 방식으로 정해진 Time Slice내에서 작업을 수행하는 방식.

a. RHEL 8 기본 IO Scheduler는 mq-deadline 이며, 읽기작업이 쓰기 작업보다 많은 경우 적합

- NOOP 스케줄러는 간단한 FIFO 알고리즘으로, 플래터(platter)를 회전시키는 HDD의 추가적 부하경감을 위해 적용 (X) > Noop은 아무것도 추가적으로 조정하지 않는 스케쥴러. 지능형 RAID 컨트롤러를 사용하거나, SSD와 같이 고성능의 디스크를 사용하는 경우 사용. 고성능 디스크를 사용하는 Case 에서 추가적으로 커널의 부하를 경감하고자 함.

- Anticipatory(AS) 스케줄러는 인접한 블록의 연속적 IO 처리를 위해 최대 6ms까지 대기하여 지연시간을 줄이고 처리량을 향상시키는 방식으로 대량의 LUN 구조에 적합 (X) > 데스크탑과 같은 소규모 LUN에 적합, 리눅스 커널 2.6.33에서 제거.

 

* PowerShell 스크립트. (22.n+1.9)

a. -1을 넣어서 마지막으로 발생한 Alarm을 조회할 수 있음 > Array의 index에 -1을 사용하면 마지막 변수 조회 가능.

- 최초 1회 수행시에는 마지막 Alarm 정보가 저장된 파일만 만들고 exit0로 스크립트를 종료.

- Import는 세션 한정 / Array 타입에서 Count와 Length 둘다 Array에 저장된 변수 개수 조회 / 반복문 수행은 ForEach-Object 사용. / tee는 화면 출력.

 

* DBMS 지연 현상 원인. 개선과제. (22.n+1.10)

a. DB 백업 시 NFS 영역에 Write를 대량으로 하게 되어 해당 구간 병목 발생. binlog 또한 NFS 영역이므로 전체적 지연.

a. 백업 위치를 Local 영역이나 신규 SAN으로 이동 / binlog를 Local 영역이나 신규 SAN 영역으로 이동

a. 네트워크 대역폭 증설 및 네트워크 분리

 

* AWS Seoul Region을 해외 Region으로 DR 구성 검토. (22.n+1.11)

a. S3 bucket 에 replication rule을 적용할 경우 다른 region의 bucket으로 복제 구성이 가능하며 replication 적용 전에 존재했던 source bucket의 데이터도 함께 복제. (X) > S3 bucket에 replication rule을 적용할 경우 rule 적용 전 object는 동기화되지 않음. S3 Batch Replication 을 통해 기존의 object를 동기화.

- 서울 리전에 재해 발생시 국내의 Direct Connect가 정상 작동하지 않을 수 있기 때문에 해외 리전과 on-premise간에 site-to-site VPN을 사전에 구성해 놓고 재해발생 시 Direct Connect를 대신하여 활용

- Route 53은 Global 서비스 이기 때문에 Route53 자체를 별도의 DR로 구성할 필요 없음. DR 상황이 되었을 때 DR에서 서비스 되는 리소스에 맞게 Route53의 개별 record는 변경이 필요.

- ECR에 보관되고 있는 container image를 DR로 구성하기 위해서는 ECR 설정에 다른 region으로 image를 replication 해줄 수 있는 속성을 enable 함

 

* 고객사는 기존 IDC 내 일부 서비스를 새롭게 구성한 클라우드 랜딩존으로 이전하려함. Plan 선정 사유. AWS Fargate (22.n+1.12)

- Compute Saving Plan / Instance Saving Plan / Fargate / Lambda 

 

* PV. PVC. k8s. (22.n+1.13)

a. Persistentvolumeclaim (calim-log-1)의 accessModes를 ReadWriteMany로 설정.

 

* java heap mem. GC 로그. container. (22.n+1.14)

a. pod의 limit 값과 java heap max size가 동일하게 설정되어 있어 limit 값에 도달하면 프로세스가 kill 당하게 됨.

a. java heap max size(Xmx 값)을 줄이거나 limit 값을 증가.

 

* 미들웨어 솔루션. (22.n+1.15)

a. JVM 기반의 미들웨어는 통상 Single-Thread 기반이므로 CPU Clock-Speed가 높아야 성능에 유리. (X) > JVM은 Multi Thread이며 Multi core가 많을 수록 유리

- 정적 컨텐츠는 Web에서 처리하거나 CDN에서 처리하는게 바람직. 

- node.js는 크롬 v8 엔진을 기반으로 javascript를 서버 상에서 수행하여 응용 프로그램을 서비스함

- MSA에서 비동기 통신을 위해서는 Kafka나 RabbitMQ와 같은 메시징 큐를 사용.

 

* 다음 web/was 의 주요 기능. (22.n+1.16)

a. 과다한 세션 개수를 사용하거나, 세션에 많은 데이터를 저장하는 경우 서비스 WAS나 세션 서버의 oom 원인이 되기 때문에 session-timeout은 가능하면 길게 설정하는 것을 권고 (X) > 전체 세션 개수를 줄이기 위해 session-timeout은 되도록이면 짧게 설정하는 것을 권고

- Web Server의 Virtual Host 기능은 하나의 Web Server를 이용하여 여러 개의 도메인 명을 호스트 함으로써 마치 여러 개의 WebServer를 사용하는 것처럼 해주는 기능

- URL 기반 WAS Plug-in / Idle session timeout/ JDBC Connection Pool 설정 중 vaildationQuery, testWhileIdle 파라미터 DB Connection

 

* API Gateway. Rate-Limit 알고리즘. (22.n+1.17)

a. Sliding Window는 시간단위 고정길이를 가진 윈도우로 호출을 추적하는 구조로, 윈도우 임계치 도달 시 추가 요청은 버려지는 구조. (X) > 해당 설명은 Fixed Window에 대한 설명. Sliding Window는 Fixed Window의 낮은 처리비용과 Sliding Log의 향상된 기능을 조합한 하이브리드 알고리즘으로 유연한 확장이 가능하고, 타 알고리즘의 단점을 커버하는 알고리즘으로 대규모의 클러스터 환경에 권장하는 방식.

 

* Amazon API Gatewa. Private Network 환경에서의 아키텍처 (22.n+1.18)

a. API Gateway는 VPC 외부의 자원이기 때문에 lb에 요청을 보내기 위해서 LB는 Public이어야함

a. API Gateway 와 서비스 인스턴스 사이에 (HA)Proxy를 둔다.

 

* API Gateway. 대규모 환경 확장시. 모놀리식 어플리케이션 아키텍처와 비슷하게 변모 될 수 있음 (22.n+1.19)

a. API Gateway를 비즈니스나 Client 앱 단위로 나누어 분산 / BFF 아키텍처 패턴 적용

 

* AI. 머신러닝.딥러닝. 인공지능.(22.n+1.20)

a. 멀티모달 AI - 복잡한 과제 해결과 높은 정확도 달성을 위해 텍스트, 음성, 이미지, 수치형 데이터 등의 다양한 데이터 유형을 동시에 받아들이고 처리하는 인공지능 모델

a. XAI(eXplainable AI) - 판단과 결정에 대한 이유를 사람이 이해할 수 있는 방식으로 제시하여 결과에 대한 불확실성을 해소하여 신뢰성을 향상시키는 인공지능

a. AIOps - IT 운영의 자동화 및 관리를 위해 빅데이터 분석에 머신러닝을 적용한 것으로 로그분석, 어플리케이션 모니터링, 인시던트 대응 등 IT 운영을 인공지능으로 확장한 플랫폼

a. 초거대 AI - 대용량 연산이 가능한 컴퓨팅 인프라를 기반으로 스스로 데이터를 학습하고 사고하며 판단할 수 있는 인간의 뇌 구조를 모방한 차세대 인공지능

a. AGI(Artifical General Intelligence, 범용인공지능) - 특정 분야에 한정된 기능의 인공지능을 넘어 다양한 업무 수행 및 지적 판단이 가능한 확장된 인공지능

 

* Window 서버. 디스크 정보. 부팅 디스크 (21.1.1)

a. 파티션 크기의 제약이 있어, Disk 2는 파티션 2개로 나누어 사용. (X) > MBR 파티션은 2TB 까지 파티션 생성 가능

- GPT 파티션으로 부팅했다면 UEFI 펌웨어 모드이며 Secure Boot가 지원됨

 

* Linux 파일 및 디렉토리 권한 설정. (21.1.2)

a. 0775 / 3777

- Sticky bit 설정되면 1000 + Set gid 는 2000 = 3000

- Sticky bit는 모든 사용자가 파일을 생성하고 확인할 수 있으므로 777 권한.

- 디렉토리 실행권한이 없으면 Sticky bit가 "t"가 아닌 "T"로 표현되는 특수접근권한 설정 오류 발생

 

* OS. Network Session. TCP 연결. TCP Diagram. (21.1.3)

a. 클라이언트는 FIN Packet을 받지 못했으므로 TIME_WAIT 상태로 대기하게 된다. (X) > FIN Patcket 을 전달받기 전 클라이언트는 FIN_WAIT2 상태로 대기.

- netstat -an / TCP 세션 연결 수 

 

* Linux 계정. /etc/shadow 파일. 패스워드. (21.1.4)

a. 패스워드를 설정해주어야 함. (2번째 항목이 암호화된 패스워드. !!이면 로그인이 불가하고 패스워드를 변경해주면 로그인 가능.)

b. 로그인 만료기간 미설정. change나 파일의 5번째 컬럼을 수정하여 만료기간 설정해주기.

 

* 가상화 시스템 제안. CPU MEM 용량 산정. (21.1.5)

a. 물리서버 1대 스펙 X 가상화율(%)

a. 위에값 X (100% - Hypervisor 오버헤드율(%)) 

a. 위에값 X 운영 임계치(%)

a. 전체 시스템 자원 규모 / 위에값

 

* 빅데이터. SSD. 구조적인 특성. SSD 고장. (21.1.6)

a. 구조적 제약: SSD는 구성하는 메모리 소자는 Flash 메모리(=Cell)이며, 수명이 존재하여 쓰기 횟수에 제한이 있음. 이로 인해 제한에 근접할 정도로 대량의 Write(기록)이 발생하면 사용치 못하는 제약이 발생.

a. 제조사 적용 방안/기능: 웨어 레벨링이라는 기능을 통해 Cell 전반적으로 균등하게 기록하는 기능을 통해 최대한 전체를 사용하게 만듦.

a. 사용자/아키텍트 설계/구성 시 고려사항: 쓰기에 대한 부하를 분산하기 위해 SSD를 추가하여 RAID 구성. 쓰기 요청 자체를 줄이기 위한 데이터 전처리 하거나 압축 적용. 주기적인 디스크 상태 모니터링 하여 임계치 이상이 되면 선제적으로 디스크 교체

 

* 외장 스토리지. 시점데이터. 운영데이터. 스냅샷. (21.1.7)

a. 파일 단위의 복구를 할 수 있는 방법이 없고 특정 시점으로 데이터 전체를 되돌려야 함 (X) > 스냅샷 볼륨을 불러와서 마운트하여 파일 단위로 복구 할 수 있음.

 - 스냅샷은 일반 백업보다 유리한 RTO 및 RPO 구현 가능. / Thick Provisioning으로 할당했더라도 스토리지 용량 모니터링이 적용되어 있어야 함 / 데이터의 정합성에 민감한 어플리케이션이나 변경량이 많은 대용량 데이터베이스의 경우 추가적인 데이터 보호 방안이 필요

 

* GCP. Terraform 코드. 백업 정책 (21.1.8)

a. days_in_cycle = 1 / start_time = "11:00" / max_retention_days = 10

- 시작시간은 UTC기준으로 설정해야함.

 

* U2L. Unix to Linux. 점검용 스크립트 결과 동일한 명령어에 대해 서로 다른 결과값 출력. (21.1.9)

a. CPU 유형별 서로 다른 Byte Ordering 방식을 사용하기 때문에 상이한 결과가 출력.

- 엔디안은 컴퓨터의 메모리와 같은 1차원 공간에 여러 개의 연속되 ㄴ대상을 배열하는 방법. 바이트를 배열하는 방법을 특히 바이트 순서(Byte Order)라 함. RISC 프로세서를 사용하는 Unix의 경우 Big-endian 방식을 사용. Intel 프로세스를 사용하는 Linux의 경우 Little-endian 방식 사용.

- 빅에디안은 최상위 바이트부터 차례로 저장하는 방식. 리틀 에디안은 최하위 바이트부터 차례로 저장하는 방식.

 

* bash shell script. 쉘 스크립트. (21.1.10)

a. HOSTNAME_까지 변수명으로 인식.

a. ${HOSTNAME}_${DATETODAY} 와 같이 중괄호 사용.

 

* 지연원인. NAS. L2 스위치. WEB/WAS. Thread Dump. (21.1.11)

a. 지연 원인: Thread 정보와 업무 이름으로 유추하면 파일 업로드 시 WAS에서 NAS에 파일을 저장하는 구간에서 시간이 지연됨. > L2와 NAS 구간에서 지연 발생.

a. L2 스위치 대역폭 증가. / NAS 자원(CPU,IO)가 부족한지 확인하고 자원 증설/부하분산하거나 NFS옵션 조정 등 튜닝.

 

* Azure Public Cloud. Cassandra DBMS N계층 어플리케이션 아키텍처 구성. (21.1.12)

a. Data tier 서브넷의 NSG는 Business tier 서브넷의 인바운드 트래픽과 Jumpbox의 관리자용 ssh 트래픽만 허용하고 그 외 모든 인바운드 트래픽을 거부하도록 설정. (X) > 데이터베이스 복제와 장애 조치에 필요한 데이터베이스 vm간 통신을 위해 Data tier 서브넷 자체의 인바운드 트랙도 허용해야함.

- Application Gateway는 WAF 기능을 제공하는 L7 부하분산 장치. / vm들은 가용존과 부하분산을 통해 / Cassandra Cluster는 가용존과 복제/장애조치(failover)를 사용하여 고가용성 확보 / 서브넷과 네트워크 인터페이스에 각각 NSG를 연결하는 경우 규칙의 충돌 발생할 수 있음. 가급적이면 하나에만 설정

 

* GCP VPC 내부 VM에서 On-Premise 환경의 DNS에 쿼리. (21.1.13)

a. DNS Forwarder / Forward Query

- 이중화 하여 구축 / Private DNS Zone / DNS 도메인을 Lookup 가능하게 함

 

* Public Cloud 기반의 Cloud Native한 환경. gc log. OOME 발생시 heap dump 기록. 확인 불가. (21.1.14)

a. 원인: 컨테이너가 Scale Out 되어 새로 생성이 되고 해당 컨테이너 내부 저장소에 gc log 및 dump가 저장되게 설정되어서 신청 기간이 끝나고 부하가 감소한 시점에 Scale in이 발생하고 해당 컨테이너는 소멸되어 그 안에 있던 파일은 더 이상 확인이 불가한 상황임

a. gc log 정보를 ELK 등의 별도 로깅 저장소에 저장하도록 설정 변경

a. AWS 라면 EFS나 S3에 저장 가능하도록 설정 변경.

 

* Kubernetes 배포방식 (21.1.15)

a. Blue Green Update

- 기존꺼 띄워두고 / 새로 배포하고 / 트래픽 new로 전환

 

* Container / k8s / CSP 별 구현 사항 (21.1.16)

a. k8s의 Vertical Pod Auto-scaler는 자원 부족 감지 시 Pod의 개수를 늘려 확장하는 방식을 사용 (X) > VPA는 Pod의 자원 제한을 늘려 재기동 하는 방식이며. Horizontal Pod Autoscaler는 Pod의 개수를 늘려 확장하는 방식.

 

* Kubernetes 오브젝트 (21.1.17)

a. Limit Range 리밋레인지

- 네임스페이스별로 Pod 또는 Container 수준에서 자원 제약조건을 관리하기 위하여 정책을 정의. 해당 정책이 적용되면 해당 정책 내의 제약조건을 벗어난 리소스를 요청하는 Pod 또는 컨테이너는 생성이 거부됨.

 

* WAS 서버 / 미들웨어 / 에러 메시지 / Too many open files (21.1.18)

a. 미들웨어 로그의 경로를 확인하고 해당 경로에서 파일의 크기가 과도하게 증가한 파일이 있는지 검토하고 주기적으로 내용을 삭제 (X) > openfiles 개수랑 파일의 크기는 연관 없음

- file descriptor 부족에 의한 에러 사례 기반 문항. NW 연결을 위한 socket은 전부 file로 처리하는 OS의 특성.

 

* SAN. HBA Port. Storage. 스토리지. (①.1.8)

- 채널 이중화. SAN Switch. Zoning. 1:n. FA Port 증설. HA 구성. 

 

* 내부 복제 솔루션. 비동기식 볼륨 복제. 대용량 DB 백업. 부하를 절감. (①.1.9)

- RAID mirror / 운영서버 자원 / 복제 소요 시간 / 대용량 Oracle DB / 동기화 시작 - 동기화 완료 확인 - Begin Backup 수행 - 운영볼륨복제볼륨 분리 - End Backup 수행

 

* Raid 2개 깨졌을 때. 손실. (①.2.Q)

- Raid 6 > 패리티 2개로 데이터 손실 없음

 

* DBMS / AIX / NFS 서비스 최적화 / NAS / DW DB / HP-UX / 전송 속도가 너무 느림. (①.2.4)

- Jumbo Fram(MTU=9000) 설정

- NIC 설정 / 원격 네트워크 패킷 전송 요청 횟수 / NFS 마운트 옵션 / Block size(resize, wsize)를 16Kbyte로 상향

- NFSD 개수

 

* SAN 스위치 장애 / 교체 작업 / 사전 Zoning 불가 > WWN Zoning은 장비의 고유 WWN을 알아야 하므로 사전 조닝 불가 (①.2.4)

 

* AP서버 OS백업 백업 대상 동일 위치에 저장되어 디스크 장애시 데이터 소실 위험 > LTO, DAT, VTL 등 다른 미디어로 백업 위치를 지정해야 함(①.6.서술)

- AP서버의 RPO를 반으로 줄여야 하는 요구사항이 도출됨 > 백업 주기 중 증분 백업을 일1회에서 2회로 증가

- Oracle 12c + ASM으로 변경 > asmcmd RMAN 백업 수행방법

- 장비 노후화 및 미디어 Faile 과 배송에 따른 미디어 유실 위험 > PTL의 Media Fail 개선과 Tape 배송 Risk를 줄이기 위해 VTL도입 / VTL 구성 시 DR센터로의 복제 구성을 통해 미디어 배송 필요성 제거

 

* L4 SLB / IP기반 hash / Round Robin / Least Connection / GC 경합 / 우선 접속 / 세션 유지 조건 / Sticky 설정 (①.6.서술)

 

* DR 인프라 개선 방향 / 유휴 상태 DR 인프라 자원 /  복구 많은 시간 소요 / 운영 비용 많이 소요 / Manual 방식 / DR 훈련 / VxLAN / DR 전환 프로세스 및 수행 스크립트 기반으로 자동화된 DR 훈련 테스트 및 전환을 수행할 수 있도록 한다 / DR 센터의 서버 가상화/클라우드 환경 (①.7.19)

 

* Oracle DB / no archive mode / 온라인 백업 / 다운타임 / Linux LVM snapshot 기능 / 다운타임 최소화 / tape 백업 (①.10.13)

- DB 중지 - LVM snapshot 수행 - DB 기동 - Snapshot LV에 대한 Tape 백업을 수행

 

* OS 패치, OS 업그레이드 전에 OS백업 필수. OS백업 방법 에 대한 설명.

(①.10.11)

- AIX / HP-UX / LVM Mirror / Hyper-V / VMware / Hypervisor 에서 제공하는 Snapshot 기능을 사용하면 / tar 명령어로 OS 관련 파일시스템을 백업 받는 방식도 사용 가능

 

* 스위치. L2 L3 L4.(②.1.2)

- 패킷의 IP를 인식 / 올바른 경로 / 패킷의 TCP 프로토콜 인식 / L4스위치는 L2,L3 모두 수행 가능

 

* OS 개념 및 프로세스 (②.3.1)

- OS는 프로세스가 요청한 메모리 영역이 실제 메모리에 존재하지 않을 경우에는 Page Fault를 발생시켜서 실제 메모리 영역으로 필요 데이터를 가져옴

- 표준 인터페이스 함수 / 우선순위가 높은 프로세스 작업 / 프로세스 분할 / 시분할 방식

- process / system call 

 

* Linux OS 파일 디렉토리 권한 (②.3.2)

- /usr/bin/passwd setuid

- /etc/shadow

- startup.sh bash startup.sh / umask 027 / 640 / 750

- inode 번호는 시스템 전체에서 unique (X) > 파일시스템 별로 unique

 

* MongoDB. LVM 사용. Striping 명령어. (②.3.4)

- lvcreate -L 100G -i 3 -n lv_node1 nv_node1

- LVM에서 스트라이핑 하면 LV 생성시 -i 옵션을 통해 구성함

 

* 좀비프로세스 생성 이유 > 자식 프로세스는 살아있는데 부모 프로세스가 먼저 죽은 경우 PPID가 1로 변경됨 (②.8.Q)

 

* 리눅스 볼륨 구성 절차, 개념 (②.8.4)

- pvcreate -s (striping) -> vgcreate -> lvcreate -> mkfs

 

* Windows Server 작업 스케줄러. (②.9.1)

- 작업 스케줄러 / OS 모니터링 스크립트를 로그온 로그오프 / 세션 로그오프 / 부모-자식 프로세스 / Administrator 계정 자격 증명 / NAS 로컬 시스템 / CPU 과점

 

* apache 사용자 정보 확인. / /etc/passwd / x:500:Apache:/var/www:/sbin/nologin  (②.11.5)

- 로그인 권한 / shell에 대한 접근 권한

- ssh, ftp, telnet 등의 로그인

- 서비스를 위한 계정으로 외부 접속이 필요 없을 때 사용할 수 있음

 

 * Web 서버 서비스 연결이 안됨 (②.12.8)

Connection refused. 실패 응답이 1-2초 이내 발생 > 프로세스가 내려가거나 port가 Listen 상태가 아님

Connection Timeout > 방화벽, 가상머신 장애, 라우팅 설정 오류

 

 * root 계정으로 set 명령어. .bash_profile.(②.8.9)

- .bash_profile에서 설정한 내용은 cron으로 동작하는 스크립트에서는 적용되지 않음

- Function VS Alias

 

 * 보안/서비스 관리 (②.8.13)

- PAM 리눅스 시스템 인증 모듈. 

- telnet 접속은 막고 ftp 접속만 허가.

- 사용자 패스워드 길이 제한

 

* AWS Cloud 아키텍처. Direct Connect. VPN. On-Premise. S3.(③.1.16)

- S3 접근 위치 / Endpoint 타입 / S3 IP 타입 / DNS Name 타입

- Gateway Endpoint / INterface Endpoint

 

* On-Premise 에서 Azure 로 환경 구축. (③.1.18)

- Application Gateway / Shared Disk / MSCS / Azure Backup Center / Disk Backup / Azure Files / AP 이중화 구성 / 가용성 집합(Availability Set)

- 네트워크 보안 그룹 / NACL 

 

*  AWS DNS 조회 FLOW (③.2.17)

- 사용자 > 내부 DNS 서버 > Route53 Resolver Inbound Endpoint > AWS-provided Internal DNS > Route53 Private Hosted Zone

- 사용자 > 외부 DNS 서버 > Internet Gateway > Public Hosted Zone

- MSSQL AlwaysOn 구성되어 있는 서버의 DNS: AWS ActiveDirectory

- EFS 서버 DNS: VPC Subnet DNS

 

* NFS와 Object storage에 대한 공통점(③.3.20)

- ACL 기반의 파일 권한 관리 가능

- Host에 로컬 파일시스템으로 mount(X), http/https로 Internet 상에서 접근(X), unix-rwx type의 파일 권한 제어 제공(X)

 

* Azure Cloud (③.4.1)

- Azure Service Management Model / VM 워크로드 다중 리소스 그룹 / 높은 가용성 SLA 리소스 그룹 / 리소스 그룹 단위 삭제 수행 시

 

* 리소스 배포 시 Cloud 플랫폼과 연관된 파라미터 (③.4.2)

- AWS 볼륨 Region, AZ, 스냅샷 이미지, 용량 / OpenStack 로드밸런서 Region 서브넷 / AWS 이미지 Region 스냅샷 이미지 공유여부

 

* AWS Cloud의 VPC에 구성된 리소스 삭제 순서  (③.4.3)

LB > VM(instance) > Network 는 순서 지켜야하며, 나머지(데이터 Volume, Security Group, Key pair, 데이터 Volume Snapshot)는 순서 관계 없음.

 

* cloud native application 기반 micro service 아키텍처 (③.4.4)

- Fault로 인한 중단 / 독립적이고 분권화 / 데이터베이스 정규화 / 서비스간 결합된 스키마 / 고립된 서비스

 

* AWS Cloud Formation 템플릿 (③.4.5)

- Type AWS EC2 VPC / EnableDnsSupport / EnableDnsHostnames / InstanceTenancy

 

* Public Cloud / 다중 서브넷 (③.6.10)

- AWS 각 서브넷의 인터페이스를 라우터에 연결(X)

- Azure는 자동으로 각 서브넷간 라우팅 가능

- Openstack 서브넷 라우팅 테이블 / 모든 서브넷간 통신을 자동 제공 (X)

 

* Azure Cloud / 메모리 32GB / D 드라이브 / Instance restart 데이터 사라짐 (③.6.12)

- D 드라이브는 Temporary Disk

 

* Azure Cloud에서 웹서버와 DB서버 / Availability Set 활용 / 총6대 서버 확대 구성 / 구성방안 (③.6.14)

- ARM(Azure Resource Manager) model / 서버의 종류에 따라 구분하여 사용

 

* AWS 이관(③.9.17)

- Internal ALB / internal ALB의 보안 그룹 / DNS Target / Gateway Enpoint / External ALB

 

* Azure (③.10.18)

- MS Fail-over Cluster MS SQL DB 서버 / Azure SQL Managed Instance

- Application Gateway / IP 기반 통신 차단 / Azure WAF / Application Gateway

- Loadbalacner 이중화 된 VM 2대 가용성 영역 가용성 집합(Availability Set)

- 네트워크 인터페이스와 서브넷에 각각 NSG 을 적용할 수 잇으며, 모두 허용

 

* On-Premise 데이터 백업본 / 클라우드 스토리지 / 클라우드 자원 사용 비용 / 관리 비용 절감 (③.10.19)

- VTL Interface / Tape 기반 백업 솔루션

- Media Changer 가상 Tape Drive / iSCSI 장치

- 낮은 Latency 

- Virtual Tape에 저장된 백업 데이터

 

* Multi-Account 환경 DNS 정책 (③.12.15)

- Inbound DNS Product / Outbound DNS Product / Private DNS Product

 

* Azure Public Cloud (③.14.14)

- 고가용성 / 보조 지역 / Traffic Mnager / 단일 리소스 그룹 / VNet Peering

 

* containerd (③.15.20)

- Kubernetes 컨테이너 런타임 중 하나. kubernetes container runtime interface 구현체.

- OCI / 런타임 대비 성능 향성

 

* S3 통신(③.18.15)

- DNS Resolution이 정상적으로 비활성화 (X)

- Service Route Talbe S3 Endpoint Route가 설정

- IAM 정책 / S3 BUCKET / Security Group / NACL Outbound TCP 443 Port

 

* 서비스 제어 정책 AWS 계정(⑤.3.15)

- Policy / IAM / Route53 / Global AWS / EC2 Instance / EBS 볼륨 Attatch / Deny 정책

 

* Azure Site Recovery (⑤.5.19)

- ASR 라이선스 무료 / 요금 / 사용량 기준 부과 / Gen SKU / Managed Disk / Unmanaged Disk 15일 / 보관 기간 / Purning 메커니즘 Snapshot 저장공간 / DR 상황 발생 시 , Failover

 

* 머신러닝, 딥러닝 기술의 발전 인공지능 (⑤.13.20)

- 복잡한 과제 해결과 높은 정확동 달성 > 멀티모달먀

- 판단과 결정에 대한 이유를 사람이 이해할 수 있는 방식으로 제시 불확실성을 해소 > XAI

- IT 운영의 자동화 및 관리를 위해 빅데이터 분석에 머신러닝을 적용한 것으로 로그분석 > AIOps

- 대용량 연산이 가능한 컴퓨팅 인프라 인간의 뇌 구조를 모방 차세대 인공지능 > AGI

 

* 미들웨어 MSA Outer Architecture 6가지 구성요소 (⑤.14.-)

- API GATEWAY / Service Mesh / Container Management / Backing Services / Telemetry / CI/CD