JG IT배움터

Code Series

• AWS에서 Developer Tools로 분류되어 있는 CodeCommit, CodeBuild, CodeDeploy, Codepipeline을 통칭하는 단어
• CI/CD를 단계적으로 수행할 수 있도록 적용 가능

CodeCommit

• repository를 담당하고 있는 서비스
• AWS에서 제공하는 완전 관리형 개발자 도구로, 안전하고 확장 가능한 git 리포지토리 호스팅 서비스
• 개발팀은 CodeCommit을 사용하여 소스 코드, 문서, 구성 파일 등의 버전 관리를 수행하고 협업 가능

CodeBuild

• Build를 담당하는 서비스
• Codecommit, S3, Github 등의 Repository로 부터 resource를 가져와서 buildspec(yml)으로 정의된 절차대로 build를 진행
• build는 별도로 구성된 docker에서 실행되며 docker에 대한 구성은 어느 정도 커스텀이 가능
• 이 docker가 실행될 VPC와 Subnet, Security group에 대해서도 지정이 가능
• CodeBuild를 사용하면 소스 코드를 컴파일하고 테스트하며, 배포 가능한 애플리케이션 빌드를 자동화 가능

CodeDeploy

• 애플리케이션의 배포를 자동화하기 위한 서비스
• 소프트웨어 배포 프로세스를 자동화하여 빠르고 안정적인 애플리케이션 업데이트를 가능
• Application과 Deployment groups으로 구성
• Application은 배포하고자 하는 대상을 의미하고 다수의 Deployment group을 가질 수 있음.
• Deployment group은 Deploy 대상이 되어 EC2/On-premises, AWS Lambda, AWS ECS로 총 3가지 유형이며 유형별로 필요한 IAM policy와 config 파일이 달라질 수 있음.

CodeDeploy 작동 방식

1. S3의 특정 revision 아카이브 파일을 EC2인스턴스로 가져온다.

2. 아카이브 파일의 압축을 푼다.

3. Deploy Agent는 압축을 푼 소스에서 AppSpec.yml에 명세된 지시사항을 처리한다.

    3-1. WAS를 정지 시킨다.

    3-2 소스의 내용을 WAS의 폴더로 복사

    3-3 WAS를 시작

기존 버전 : 1.19.9

업그레이드 할 버전 : 1.25.3

cp -r /etc/nginx /tmp/nginx.backup

systemctl stop nginx (현재 버전에서 재기동 잘 되는지 확인하기 위해 start 한 번 실행하고 작업 진행하면 좋음)

wget /https://nginx.org/download/nginx-1.25.3.tar.gz

tar -zxvf nginx-1.25.3.tar.gz

cd nginx-1.25.3

./configure --prefix=/etc/nginx

make

make install

 기존 nginx 설정을 가져올 경우 백업해놓은 디렉터리로 접근하여 nginx.conf를 가져오면 된다.

JAVA_OPTS="${JAVA_OPTS} -Xms8192m -Xmx8192m"

• Java 가상 머신의 초기 힙 크기를 8192MB로 설정합니다. 즉, Java 프로세스가 시작될 때 할당되는 힙 메모리의 최솟값을 지정합니다.
• Java 가상 머신의 최대 힙 크기를 8192MB로 설정합니다. 이는 Java 프로세스가 사용할 수 있는 최대 힙 메모리 크기를 제한합니다.

JAVA_OPTS="${JAVA_OPTS} -XX:MaxMetaspaceSize-1024m"

• Metaspace의 최대 크기를 1024MB로 설정합니다.
• Metaspace는 클래스 메타데이터를 저장하는 데 사용되는 JVM 메모리 영역입니다.

JAVA_OPTS="${JAVA_OPTS} -XX:+UseParallelGC"

• 병렬 가비지 컬렉션을 사용합니다.
• 이는 메모리 관리를 위해 Java의 Garbage Collector가 여러 스레드를 사용하여 동시에 가비지 컬렉션을 수행하도록 합니다.

JAVA_OPTS="${JAVA_OPTS} -XX:+UseparallelOldGC"

• 이전 세대의 병렬 가비지 컬렉션을 사용합니다.
• 이는 이전 세대 객체를 수거하기 위해 병렬 알고리즘을 사용하여 가비지 컬렉션을 수행합니다.

JAVA_OPTS="${JAVA_OPTS} -verbos"gc -Xloggc:/tomcat8/logs/gc/gc-tomcat-%t.log"

• GC 로그를 자세히 출력하고, 해당 로그를 /tomcat8/logs/gc/gc-tomcat-%t.log 파일에 기록합니다.
• %t는 로그 파일 이름에 현재 날짜 및 시간을 대체하는 플레이스홀더입니다.

JAVA_OPTS="${JAVA_OPTS} -XX:-UseAdaptiveSizePolicy"

• 자동 크기 조정 정책 비활성화.
• 이 옵션을 사용하면 자동으로 힙 크기를 조정하는 정책을 사용하지 않게 됩니다.

JAVA_OPTS="${JAVA_OPTS} -XX:+ExplicitGCInvokesConcurrent"

• 명시적 가비지 컬렉션 호출이 동시 가비지 컬렉션을 유발합니다.
• 명시적 가비지 컬렉션은 System.gc()와 같은 메서드 호출을 통해 발생할 수 있습니다.

JAVA_OPTS="${JAVA_OPTS} -XX:+HeapDumpOnOutOfMemoryError"

• OutOfMemoryError가 발생할 때 힙 덤프를 생성합니다. 이는 메모리 부족 오류가 발생했을 때 힙 상태를 분석하는 데 도움이 됩니다.

JAVA_OPTS="${JAVA_OPTS} -XX:HeapDumpPath=/tomcat8/logs/gc/tomcat-heapdump-'date +%Y-%m-%d-%H-%M-%S'.hprof"

• 힙 덤프 파일의 경로를 설정합니다.
• 덤프 파일은 /tomcat8/logs/gc/ 디렉토리에 위치하며, 파일 이름에는 현재 날짜 및 시간이 포함됩니다.

export JAVA_OPTS

• 이 명령어를 생략하면 위 옵션들이 적용되지 않습니다.

JAVA_OPTS="${JAVA_OPTS} -Xms8192m -Xmx8192m"
JAVA_OPTS="${JAVA_OPTS} -XX:MaxMetaspaceSize-1024m"
JAVA_OPTS="${JAVA_OPTS} -XX:+UseParallelGC"
JAVA_OPTS="${JAVA_OPTS} -XX:+UseparallelOldGC"
JAVA_OPTS="${JAVA_OPTS} -verbos"gc -Xloggc:/tomcat8/logs/gc/gc-tomcat-%t.log"
JAVA_OPTS="${JAVA_OPTS} -XX:-UseAdaptiveSizePolicy"
JAVA_OPTS="${JAVA_OPTS} -XX:+ExplicitGCInvokesConcurrent"
JAVA_OPTS="${JAVA_OPTS} -XX:+HeapDumpOnOutOfMemoryError"
JAVA_OPTS="${JAVA_OPTS} -XX:HeapDumpPath=/tomcat8/logs/gc/tomcat-heapdump-'date +%Y-%m-%d-%H-%M-%S'.hprof"
export JAVA_OPTS

• 개발자가 코드를 개발하여 Codecommit에 넣으면 Codebuild에서 해당 코드를 빌드 후 문제가 없으면 Codedeploy로 전송해 Codedeploy에서 배포한다.
• 서버들로 배포된 코드는 S3 버킷에 저장된다.

• Codecommit과 Codebuild는 운영 Account에 넣지 않는다.
• 개발 Account에 운영 Codecommit과 Codebuild가 존재해서 개발 commit에서 완료된 작업을 운영 commit으로 전송하여 배포한다.
• 운영 commit에는 개발자가 직접 본인의 코드를 넣을 수 없고 개발 commit에 있는 코드를 운영 commit으로 전송하여 배포해야 한다.

※ 배포 중에 두 가지 오류가 발생할 수 있다.

1. Codebuild에서 오류

• 개발 코드에서 발생하는 오류가 대부분이며 운영 중인 서버에 영향도가 없다.
• 긴급 상황은 아님.

2. 배포 완료 후 서비스 오류 (배포성공 서비스 오류)

ex) 네이버 홈페이지에서 개발 중에 구글 홈페이지의 기능을 가져오기 위해 구글 홈페이지의 코드를 복사 후 실수로 배포를 하는 경우 고객들은 네이버 페이지가 아닌 구글 홈페이지가 나올 수 있음.

ex2) 이벤트 페이지를 만들어서 배포하였는데 이벤트 페이지가 빈 페이지 일 경우

• 배포는 완료했지만 서비스에서 오류가 발생할 수 있다.
• 그렇기 때문에 운영 commit과 build를 운영 Account에 넣지 않고 개발 Account에서 관리하여 서비스 오류를 최소화한다.

※ 여러 서버에 배포 중 실패했을 경우

• 3번 서버 배포 도중에 에러가 발생하여 3번 서버만 버전이 다른 경우가 발생할 수도 있음.
• 보통 자동화가 걸려있기 때문에 Codecommit부터 다시 시작하긴 함.
• 해당 오류가 지속될 경우 고객은 1,2번 서버와 다른 버전의 페이지를 보게 될 수 있음.

• 개발하다가 운영에 넣어도 될 만큼 개발을 성공하면 운영에 적용 (1)
• 개발하는데 혼자 개발하고 싶은 부분이나 영향도가 큰 개발은 따로 feature으로 빼서 개발 후 적용(2)
• feature메서 개발한 부분까지 모두 가지고 운영에 배포(3)
• 운영에 배포를 했지만 (ex) 07/26 이벤트 시작인데 06/26 이벤트 시작으로 오타를 냈을 경우) 긴급하게 수정이 필요할 때 hotfix(4)
• hotfix가 오래 걸리는 경우 인프라에서 롤백을 해줄 수도 있음.(5)

Elasticsearch

•  오픈 소스 분산 검색 및 분석 엔진
• Java로 개발된 오픈 소스 검색 엔진
• HTTP 대시보드 웹 인터페이스 (Kibana)와 함께 분석되어 있는 다중 테넌트(분산 저장)에 저장된 전체 텍스트 검색 엔진을 제공
• JSON 문서 체계를 사용하여 데이터 요청, 검색, 저장을 수행하고, 로그 파일뿐만 아니라 각종 다양한 형태의 텍스트를 검색하는 데 사용
• 대용량 데이터 처리하는데 있어서 매우 강력하고 유연한 검색 및 분석 엔진, 검색 기반 애플리케이션, 로그 분석, 모니터링 등 다양하게 사용
• 데이터가 많아질 때 속도가 기하급수적으로 느려지는데, 그런 것들을 저장하고 빠르게 검색해서 찾으려고 할 때 매우 유용
• 데이터가 한 필드를 보는게 아닌 여러 가지 필드(문장 / 작성자) 식 여러 개의 조건을 걸어 검색할 때도 검색엔진의 성능이 두드러짐

Logstach

• 오픈 소스 데이터 수집 엔진
• 이벤트 및 로그 관리를 위한 오픈 소스 도구
• 데이터 수집을 위한 실시간 감시 가능을 제공
• Logstash는 로그 데이터를 수집하고 데이터를 JSON 문서로 변환 후 Elasticsearch에 저장하는 역할을 수행
• 대용량 로그 및 데이터를 실시간으로 수집, 분석하고 시각화하여 중요한 인사이트를 도출하는데 유용

Kibana

• Elasticsearch와 함께 사용되는 오픈 소스 데이터 시각화 및 대시보드 툴
• 직관적이고, 깔끔한 형태의 대시 보드 웹 인터페이스를 제공
• Elasticsearch에서 데이터를 관리하고, Kibana에서 데이터를 시각화

Beats

• Client에 설치하여 Client에서 발색하는 대량의 데이터를 Logstash & Elasticsearch 서버로 보낼 수 있는 경량 에이전트 데이터 전송 서비스
• Log File 전속에 사용되는 "Filebeat" 외의 다양한 Beat를 제공 ( "Metricbeat". "Packetbeat", "Winlogbeat" )
• 수집 에이전트 역할

작동 방식

1. Logstash에서 로그 및 데이터를 수집하고 가공 및 변환한다.
2. Elasticsearch에 로그 및 데이터를 저장하고 검색이 가능하다.
3. Kibana에서 Elasticsearch에 저장된 로그 및 데이터를 가져와 시각화하여 대시보드를 생성한다.

• WEB, WAS 서버가 2대씩 있어서 LB에서 로드밸런싱을 지원하는데 사용자가 1번서버에 접속 후 다시 접속할 때 2번서버로 접속하게되면 로그인을 다시해야하는 상황이 일어남
• 그런 상황을 방지하기 위해서 Session서버에서 사용자의 정보를 가지고 있는 역할을 한다.

※ Session 서버가 없으면 운영이 안되는 가?

• 아니다. Session 서버가 없는 구성일 경우 로드밸런서에서 해당 IP를 지정된 서버로 접속하게 설정할 수 있다.

S0C : Survivor 0 영역의 현재 크기 (바이트)

S1C : Survivor 1 영역의 현재 크기 (바이트)

S0U : Survivor 0 영역의 사용 중인 크기 (바이트)

S1U : Survivor 1 영역의 사용 중인 크기 (바이트)

EC : Eden 영역의 현재 크기 (바이트)

EU : Eden 영역의 사용 중인 크기 (바이트)

OC : Old (Tenured) 영역의 현재 크기 (바이트)

OU : Old (Tenured) 영역의 사용 중인 크기 (바이트)

MC : Metaspace 영역의 현재 크기 (바이트)

MU : Metaspace 영역의 사용 중인 크기 (바이트)

CCSC : Compressed Class Space의 현재 크기 (바이트)

CCSU : Compressed Class Space의 사용 중인 크기 (바이트)

YGC : Young Generation에서의 총 가비지 컬렉션 횟수

YGCT : Young Generation 가비지 컬렉션에 소요된 시간 (초)

FGC : Full 가비지 컬렉션 횟수

FGCT : Full 가비지 컬렉션에 소요된 시간 (초)

GCT : 총 가비지 컬렉션에 소요된 시간 (초)

IAC (Infrastructure As Code)

- 수동으로 엔지니어가 하나하나 리소스 정리하고 용량 정리하고 그 속에 운영체제, 서비스 구성하는 환경에서 자동화할 수 있는 도구를 사용해서 코드로 정의해서 한 번에 해결할 수 있게 하는 게 최근 트렌드

- 최근 수동으로 하는 작업은 잘 없음 (그렇다고 아예 없는 건 아님)

- 인프라를 코드로 정의해서 관리하는 것

- 테라폼이라는 도구를 이용해서 클라우드 환경에 해당하는 리소스들을 정의

- 리소스(인프라 자체)를 구성하는 데 사용하지 않는다

- 이미 구성이 되어있고 이미 정의가 된 image들의 공통의 작업을 수행해야 할 때 한 번에 설정할 때 사용

EX) AWS를 테라폼으로 관리를 하겠다면 YAML이라는 파일을 정의한다.

- 인스턴스 용량이라던지 속해야 하는 파일을 정리하는 것

- 정의를 하게 되면 AWS상에서 가상 네트워크 등이 생성된다.

- OS를 설치하지 않고 image를 사용한다. 이미지에 OS가 다 설치되어있음.

- 그래서 가상 머신에 OS가 자동으로 설치가 되어있다.

- 이런 시스템을 코드의 형태로 만드는 게 IAC

- AWS Cloudformation

※ 병렬 처리 : 동시다발적으로 처리한다.

Ansible 특징

- Agent Less 방식을 사용하는 게 가장 큰 특징

- 플레이북 단위로 작업 수행

- yaml을 작성해서 실행

절차적 작업 : 패키지를 설치 및 실행

선언적 작업 : 패키지가 설치된 상태에서 실행 중인 상태를 확인 후 있으면 다음 작업을 실행

Ansible 구성요소

# Ansible Software

- 상주 프로세스가 없고, 명령줄에 의해 동작 -> 장점

- Software만 설치하면 동작한다.

# Inventory

- 조작할 관리 대상 서버의 목록을 정의

- 여러 대의 관리대상 서버를 그룹화(인벤터리에서 제일 중요한 작업)하여 정의 가능

- WEB서버 DB서버 그룹화해서 사용 가능

- 정적 구성과 동적 구성으로 구분 (동적 인벤터리는 잘 사용하지 않음)

# Module

- Ansible에서 실행되는 하나의 명령

- 변경사항이 있을 경우에만 작업 수행

- Ansible 내부에 기본 내장 모듈이 존재

# Playbook

- YAML(어떤 구조인지만 파악) = JSON 같이 사용함

- 실제 스크립트 작업 과정을 YAML 형식으로 정의

- YAML : 데이터 정의어, 하나의 문법이라고 생각

- 프로젝트 단위 (작업 단위보다는 좀 더 큰 범주의 단위)

Ansible ad-hoc

- 단일 태스크 실행하여 자동화 가능

- 1회성 실행