240819 TIL

송형근·2024년 8월 19일

CVE SQL injection TIL XSS csrf 공부 모니터링 시큐어코딩 알고리즘 장애 분석 장애 식별 장애 진단

TIL

목록 보기

16/43

스파르타 Java 단기 심화 과정

코드카타

프로그래머스 155652 둘만의 암호

https://school.programmers.co.kr/learn/courses/30/lessons/155652

— 문제 설명

두 문자열 s와 skip, 그리고 자연수 index가 주어질 때, 다음 규칙에 따라 문자열을 만들려 합니다. 암호의 규칙은 다음과 같습니다.

문자열 s의 각 알파벳을 index만큼 뒤의 알파벳으로 바꿔줍니다.
index만큼의 뒤의 알파벳이 z를 넘어갈 경우 다시 a로 돌아갑니다.
skip에 있는 알파벳은 제외하고 건너뜁니다.

예를 들어 s = "aukks", skip = "wbqd", index = 5일 때, a에서 5만큼 뒤에 있는 알파벳은 f지만 [b, c, d, e, f]에서 'b'와 'd'는 skip에 포함되므로 세지 않습니다. 따라서 'b', 'd'를 제외하고 'a'에서 5만큼 뒤에 있는 알파벳은 [c, e, f, g, h] 순서에 의해 'h'가 됩니다. 나머지 "ukks" 또한 위 규칙대로 바꾸면 "appy"가 되며 결과는 "happy"가 됩니다.

두 문자열 s와 skip, 그리고 자연수 index가 매개변수로 주어질 때 위 규칙대로 s를 변환한 결과를 return하도록 solution 함수를 완성해주세요.

— 제한 조건

5 ≤ s의 길이 ≤ 50
1 ≤ skip의 길이 ≤ 10
s와 skip은 알파벳 소문자로만 이루어져 있습니다.
- skip에 포함되는 알파벳은 s에 포함되지 않습니다.
1 ≤ index ≤ 20

— 입출력 예

s	skip	index	result
"aukks"	"wbqd"	5	"happy"

입출력 예 #1

본문 내용과 일치합니다.

— 문제 풀이

class Solution {
    public String solution(String s, String skip, int index) {
        StringBuilder sb = new StringBuilder();
        
        for(int i=0;i<s.length();i++){
            char c = s.charAt(i);
            int cnt = 0;
            for(int j=1;j<=index;){
                if(skip.contains((char)((c - 'a' + cnt + 1) % 26 + 'a')+"")){
                    cnt++;
                }else {
                    cnt++;
                    j++;
                }
            }
            char nChar = (char)((c - 'a' + cnt) % 26 + 'a');
            sb.append(nChar);
        }
        
        return sb.toString();
    }
}

CSRF ( Cross-Site Request Forgery )

CSRF란?

Web App의 취약점을 이용해 사용자가 의도하지 않은 요청을 보내도록 하는 공격 기법
공격자는 사용자가 인증된 상태를 악용하여 사용자가 원하지 않는 행동을 수행하게 만듦
- ex) 사용자가 로그인된 상태에서 악의적인 웹사이트를 방문하면, 그 웹사이트가 사용자 권한을 이용해 은행 계좌에서 돈을 송금하도록 할 수 있음

CSRF 상황

사용자 로그인 : 사용자가 Web App에 로그인함
세션 유지 : 로그인 후 세션 쿠키가 브라우저에 저장됨
악성 웹사이트 방문 : 사용자가 다른 웹사이트를 방문함. 이 웹사이트는 CSRF 공격 코드를 포함
악의적인 요청 전송 : 악성 웹사이트는 사용자의 세션 쿠키를 이용해 원본 Web App으로 요청 보냄
서버 처리 : 서버는 정상적인 사용자의 요청으로 인식하고 처리함

CSRF 방지 방법

Referer 헤더 검증
- 서버는 요청의 Referer 헤더를 확인하여 요청이 신뢰할 수 있는 출처에서 온 것인지 확인할 수 있음
- 그러나 Referer 헤더는 사용자가 조작할 수 있고, 일부 브라우저에서는 이 헤더를 포함하지 않을 수 있음
CSRF 토큰 사용
- 가장 일반적인 방지 방법으로서, 서버는 각 요청에 대한 고유한 토큰을 생성하고, 이를 폼에 포함시킴. 서버는 요청이 들어올 때 이 토큰을 거증
form 대신 API 사용
- API를 통해 JSON 데이터로 통신한다면 해당 이슈를 피할 수 있음

CSRF 토큰 실습

의존성
- Spring Web
- Spring Security
- Thymeleaf

SampleSecurityConfig

@Configuration
public class SampleSecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
                .authorizeRequests(authorize -> authorize.anyRequest().permitAll())
                .csrf(csrf -> csrf.csrfTokenRepository((CookieCsrfTokenRepository.withHttpOnlyFalse())));

        return http.build();
    }
}

SampleController

@Controller
public class SampleController {

    @GetMapping("/")
    public String showForm() {
        return "form";
    }

    @PostMapping("/sumbit")
    public String handleFormSubmit(@RequestParam("name") String name, @RequestParam("csrf") String csrfToken) {
        System.out.println("Received CSRF Token : " + csrfToken);
        System.out.println("Received name : " + name);
        return "result";
    }
}

HTML Files

form

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title>CSRF Example</title>
</head>
<body>
<form th:action="@{/submit}" method="post">
    <label for="name">Name:</label>
    <input type="text" id="name" name="name"/>
    <button type="submit">Submit</button>
</form>
</body>
</html>

result

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title>Result</title>
</head>
<body>
<h1>Form submitted successfully!</h1>
<a th:href="@{/}">Go back to form</a>
</body>
</html>

XSS ( Cross-Site Scripting )

XSS 란?

Web App의 취약점을 이용해 악성 스크립트를 다른 사용자의 브라우저에서 실행시키는 공격
이를 통해 공격자는 사용자의 세션을 가로채거나, 악성 코드 실행, 웹사이트 변조 등의 공격을 수행할 수 있음

XSS 공격 유형

반사형 XSS (Reflected XSS)
- 사용자가 입력한 데이터가 즉시 웹 페이지에 반영되어 발생하는 공격. 보통 URL에 포함된 악성 스크립트를 통해 이루어짐
저장형 XSS (Stored XSS)
- 악성 스크립트가 서버에 저장되어 여러 사용자가 해당 스크립트를 실행하게 되는 경우
  - ex) 악성 스크립트를 포함한 게시글 작성 → 게시글을 보는 모든 사용자의 브라우저에서 스크립트 실행
DOM 기반 XSS (DOM-based XSS)
- 클라이언트 측에서 JS를 통해 DOM을 동적으로 조작할 때 발생. 서버에 요청을 보내지않고, 클라이언트 측에서 스크립트가 실행됨
  - ex) 스크립트가 URL 패러미터를 읽어와 DOM에 삽입할 때, 악성 스크립트가 포함될 수 있음
반사형 XSS와 DOM 기반 XSS의 차이점
- 반사형 XSS와 DOM 기반 XSS는 발생 위치와 동작 방식에서 차이가 있음
- 반사형 XSS는 서버측에서 발생하며, 입력된 데이터가 서버를 통해 반사되어 클라이언트로 돌아옴
- DOM 기반 XSS는 클라이언트 측에서 발생하며, 클라이언트 측 JS가 직접 데이터를 처리하고 DOM을 조작함

XSS 공격의 위험성

세션 하이재킹 : 사용자의 세션 쿠키를 탈취하여 공격자가 사용자의 계정으로 로그인할 수 있음
악성 코드 실행 : 악성 스크립트를 실행하여 사용자의 시스템에 피해를 줄 수 있음
피싱 공격 : 사용자를 속여 민감한 정보를 입력하도록 유도할 수 있음
웹사이트 변조 : 웹 페이지의 내용을 변경하여 사용자에게 잘못된 정보를 제공할 수 있음

XSS 방어 기법

입력 검증 및 인코딩
- 사용자의 입력을 철저히 검증하고, 출력할 때 적절히 인코딩하여 스크립트가 실행되지 않도록 함
  - ex) HTML 인코딩, JS 인코딩, URL 인코딩 등
CSP (Content Security Policy)
- CSP는 Web App이 허용된 컨텐츠 소스를 명시하여 XSS및 데이터 삽입 공격을 방지하는 보안 기능
- CSP는 Web App이 로드할 수 있는 리소스의 출처를 정의하는 HTTP 응답 헤더. 이를 통해 개발자는 특정 스크립트, 스타일시트, 이미지 등을 로드할 수 있는 출처를 제한할 수 있음
- ex) Content-Security-Policy: default-src ‘self’ https://trusted.cdn.com;
HTTPOnly 쿠키 사용
- 세션 쿠키에 HttpOnly 속성을 설정하여 JS에 접근하지 못하도록 함. 이를 통해 세션 하이재킹을 방지할 수 있음
- HTTPOnly 쿠키는 서버측에서 설정함
- ex) Set-Cookie: sessionId=abc123; HttpOnly; Secure
JavaScript 안전하게 사용하기
- 클라이언트 측에서 사용자 입력을 직접적으로 처리하지 않도록 함. JavaScript를 사용할 때, DOM 조작 시 사용자 입력을 안전하게 처리

SQL Injection

SQL Injection 이란?

공격자가 Web App의 DB Query에 악의적인 SQL 코드를 삽입하여 DB를 조작하거나 민감한 정보를 탈취하는 공격. App이 사용자 입력을 제대로 검증하지 않을 때 발생

SQL Injection의 위험성

데이터 탈취 : 공격자가 DB에서 민감한 정보를 탈취할 수 있음
데이터 변조 : DB의 데이터를 변경하거나 삭제할 수 있음
권한 상승 : 공격자가 DB 관리자 권한을 얻을 수 있음
전체 시스템 장악 : 심각한 경우 서버 전체를 장악할 수 있음

SQL Injection 공격 예시

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class SqlInjectionExample {
    public static void main(String[] args) {
        String username = "admin'; --";
        String password = "password";
        String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

        try (Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/testdb", "root", "password");
             Statement stmt = conn.createStatement();
             ResultSet rs = stmt.executeQuery(query)) {

            if (rs.next()) {
                System.out.println("User authenticated");
            } else {
                System.out.println("Authentication failed");
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

공격자는 username 필드에 admin'; --를 입력
SQL 쿼리는 SELECT * FROM users WHERE username = 'admin'; --' AND password = 'password'로 변경됨
--는 SQL 주석 처리 기호로, 이후의 코드는 무시됨
결과적으로 쿼리는 SELECT * FROM users WHERE username = 'admin';가 되어, 공격자가 비밀번호를 입력하지 않아도 인증이 됨

SQL Injection 방어 기법

Prepared Statements : SQL 쿼리를 미리 컴파일하여 패러미터화된 쿼리를 사용
Stored Procedures : DB에서 미리 정의된 저장 프로시저를 호출하여 실행
ORM : Hibernate 같은 ORM 프레임워크를 사용하여 DB 접근을 추상화
입력 검증 및 인코딩 : 사용자 입력을 철저히 검증하고 인코딩하여 SQL 쿼리에 직접 포함시키지 않음
최소 권한 원칙 : DB 사용자에게 최소한의 권한만 부여

그 외 보안 문제들

Open Redirect

공격자가 Web App의 리다이렉션 기능을 악용하여 사용자를 악성 사이트로 유도하는 공격
예시
- 공격 시나리오
  1. 공격자의 준비 : 공격자는 피싱 사이트 http://malicious.example.com를 운영하는데, 이 사이트는 실제 금융 웹사이트와 매우 유사하게 보이도록 만들어져 있음
  2. 공격자 링크 제작 : 공격자는 다음과 같은 링크를 만듦
    
    http://bank.example.com/login?redirectUrl=http://malicious.example.com
    - 이 링크는 사용자가 bank.example.com에 로그인한 후 malicious.example.com으로 리다이렉션 되도록 설정되어 있음
  3. 사용자 유도 : 공격자는 이메일, 소셜 미디어, 메시지 앱 등을 통해 이 링크를 사용자에게 보냄. 사용자는 이 링크를 클릭하면, 자신이 신뢰하는 bank.example.com 로그인 페이지로 이동함
  4. 사용자 로그인 : 사용자는 평소와 같이 bank.example.com에 로그인하고, 로그인 성공 후, 사용자는 자동으로 malicious.example.com으로 리다이렉션 됨
  5. 피싱 사이트 : 사용자는 리다이렉션된 malicious.example.com에서 실제 금융 웹사이트와 매우 유사한 페이지를 보게 됨. 사용자는 자신의 계정 정보를 다시 입력하라고 요구받고, 사용자가 정보를 입력하면, 이 정보는 공격자에게 전송됨
방어 기법
- 허용된 URL 목록 사용
  - 리다이렉션할 수 있는 URL 목록을 미리 정의하고, 해당 목록에 포함된 URL로만 리다이렉션 함
- 입력 검증
  - 리다이렉션 대상 URL을 철저히 검증하여, 신뢰할 수 있는 URL로만 리다이렉션하도록 함
- 상대 경로 사용
  - 리다이렉션을 외부 URL이 아닌 App 내의 상대 경로로 제한하여 공격을 방지할 수 있음

Directory Traversal

공격자가 WEb App의 파일 시스템에서 허용되지 않은 파일이나 디렉토리에 접근할 수 있도록 하는 공격
주로 App이 파일 경로를 사용자 입력을 통해 받아서 처리할 때 발생
예시
- 공격 시나리오
  1. 공격자 준비 : 공격자는 App이 상대 경로를 제대로 검증하지 않는다는 사실을 발견하고, 시스템의 중요한 파일에 접근하기 위해 상대 경로를 이용함
  2. 공격자 링크 제작 : 공격자는 다음과 같은 URL을 만듦
    
    http://example.com/download?file=../../etc/passwd
  3. 파일 접근 : App은 사용자가 제공한 파일명을 검증하지 않고, 해당 경로의 파일을 열어서 사용자에게 전송함
방어 기법
- 서버 설정 강화
  - 웹 서버 설정을 통해 허용되지 않은 디렉토리 접근을 차단함
- 경로 검증
  - 파일 경로를 검증하여 허용된 디렉토리 내에서만 파일을 접근하도록 함
- 허용된 파일 목록 사용
  - 허용된 파일 목록을 미리 정의하고, 해당 목록에 포함된 파일만 접근하도록 함. 이 방법은 파일 이름을 미리 정의된 안전한 목록에서 확인함

Clickjacking

공격자가 웹 페이지의 투명한 프레임을 사용하여 사용자가 클릭하도록 유도하는 공격
사용자가 알지 못하는 사이에 악성 동작을 수행할 수 있음
방어 기법
- X-Frame-Options 헤더 사용
  - DENY 또는 SAMEORIGIN 값을 사용하여 웹 페이지가 iframe으로 포함되지 않도록 설정함
  - DENY: 어떠한 사이트에서도 이 페이지를 iframe으로 포함할 수 없도록 함
  - SAMEORIGIN: 동일 출처에서만 이 페이지를 iframe으로 포함할 수 있도록 함
- Content Security Policy (CSP)
  - CSP 헤더를 사용하여 iframe의 포함을 제한함

Sensitive Data Exposure

App이 민감한 데이터를 충분히 보호하지 않아 공격자가 이를 탈취하는 공격
민감한 데이터가 안전하게 저장되거나 전송되지 않을 ㄸ ㅐ발생
- ex) 비밀번호 평문, 신용카드 정보 암호화X 등
방어 기법
- 데이터 암호화
- 강력한 암호 정책
- HTTPS 사용 : HTTPS를 사용해 전송시 데이터 암호화
- 접근 제어 : 민감한 데이터에 대한 접근을 최소화

Insecure Deserialization

공격자가 악의적으로 조작된 객체를 App에 전달하여 실행시키는 공격
시스템 내에서 임의의 코드를 실행하거나 데이터를 조작할 수 있음
App이 직렬화된 데이터를 역직렬화할 때, 해당 데이터가 신뢰할 수 있는지 검증하지 않으면, 공격자가 악의적으로 조작된 직렬화 데이터를 주입할 수 있음
방어 기법
- 데이터 검증 : 역직렬화된 객체가 예상된 타입인지 검증하여, 신뢰할 수 없는 객체를 역직렬화하지 않도록 함
- 안전한 라이브러리 사용 : Java의 기본 직렬화 대신, 안전한 직렬화 라이브러리를 사용하여 역직렬화 과정에서의 보안을 강화할 수 있음.
  - ex) Jackson 라이브러리를 사용하여 JSON 데이터 직렬화 및 역직렬화
직렬화와 역직렬화
- 직렬화 (Serialization)
  - 직렬화는 객체를 저장하거나 전송하기 위해 객체의 상태를 바이트 스트림으로 변환하는 과정
  - 이를 통해 객체를 파일로 저장하거나 네트워크를 통해 전송할 수 있음
- 역직렬화 (Deserialization)
  - 바이트 스트림으로 변환된 객체 데이터를 다시 원래의 객체 형태로 복원하는 과정
  - 이를 통해 저장된 객체를 다시 사용하거나, 네트워크로 전송된 객체 데이터를 수신하여 사용할 수 있음

Insufficient Loggin & Monitoring

App이 적절한 로그를 기록하지 않거나, 이상 행동을 감시하지 않아 공격을 조기에 발견하지 못하는 경우
방어 기법
- 포괄적인 로깅 : 중요한 이벤트와 에러를 포괄적으로 로그로 기록함
- 실시간 모니터링 : 실시간 모니터링 시스템을 사용하여 이상 행동을 감지
- 로그 검토 : 주기적으로 로그를 검토하여 이상 징후를 발견하고 대응함

CVE, CVSS

CVE (Common Vulnerabilities and Exposures)는 특정 소프트웨어 및 하드웨어의 취약점을 고유하게 식별하기 위해 사용되는 표준화된 명명 시스템
각 CVE 항목은 고유한 CVE ID를 부여받으며, 이는 해당 취약점을 참조할 때 일관된 명칭을 제공하여 커뮤니케이션을 용이하게 함
CVE 프로그램은 MITRE에 의해 관리되며, 미국 국토안보부(DHS)와 사이버 보안 및 인프라 보안국(CISA)의 후원을 받고 있음
CVE는 취약점의 심각성을 정량적으로 측정하기 위한 방법론
CVSS 점수는 0에서 10까지의 범위로, 낮은 점수는 덜 심각한 취약점을, 높은 점수는 매우 심각한 취약점을 나타냄

Log4j 취약점 사태

개요
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- Log4j 사태는 2021년 12월 초에 발견된 심각한 보안 취약점으로, Apache Software Foundation에서 개발한 Log4j 2 라이브러리에서 발견됨
- 이 취약점은 전 세계 수많은 서버와 애플리케이션에 영향을 미침
취약점 설명
- 이 취약점은 CVE-2021-44228로 등록되었으며, 일반적으로 “Log4Shell”이라고 불림
- 해커가 로그가 기록되는 곳을 찾아 취약점을 이용하는 것
영향
- 광범위한 영향 : 많은 Java 기반 App과 서버에서 사용되므로, 많은 장비와 서비스를 위험에 빠뜨렸음
- 즉각적인 패치 필요 : 여러 조직은 즉각적으로 패치를 적용하고 보안 조치를 취해야했음
- 대규모 공격 시도 : 취약점 공개 후, 많은 공격자들이 이를 악용하기 시작했으며, 짧은 시간안에 수많은 공격이 시도됨
대응
- 패치 배포 : Apache에서 취약점을 해결하기 위해 Log4j 2.15.0 버전을 신속하게 배포했음. 이후 추가적인 문제를 해결하기 위해 여러 번의 패치가 더 배포되었음
- 보안 권고 : 각국의 보안 기관 및 주요 IT 기업들은 신속히 보안 권고를 발행하고, 사용자들에게 최신 버전으로 업데이트할 것을 권장했음
- 시스템 점검 : 많은 조직이 자사 시스템을 점검하고, 취약점의 영향을 받는지 확인하는 작업을 수행했음
예방 조치
- 최신 버전 사용
- 모니터링 및 탐지
- 보안 인식 교육

장애 식별

모니터링

시스템의 상태를 지속적으로 관찰하고 분석하여 장애를 조기에 식별하고 대응할 수 있도록 하는 필수 과정.

모니터링 범위

참고 : https://velog.io/@lukeydokey/240816-TIL#모니터링의-범위

시스템 모니터링
- 리소스 사용량 추적
- 서버 및 App 상태
  - 서버의 가용성, 응답 시간, 오류 로그 등을 모니터링하여 서버 상태와 App 작동 여부 점검
- 장애 예측
  - 머신러닝 기반의 예측 분석을 통해 리소스 사용 패턴을 학습하고, 이상 패턴을 사전에 감지하여 장애를 예방
App 모니터링
- 로그 모니터링
  - 중앙 집중형 로그 관리 시스템을 통해 모든 로그를 통합하고 분석하는 것이 효과적
- 성능 모니터링
  - 응답시간, 처리량, 오류율 등을 측정하여 성능 문제를 조기에 식별
- 서비스 헬스 체크
사용자 경험 모니터링
- End-to-End 모니터링
  - 사용자가 서비스를 사용하는 전체 경로를 모니터링하여, 사용자 경험 기반으로 장애 식별. 사용자 지연, 실패 요청 등의 데이터를 수집 ( ex) 셀레니움 )
- 사용자 피드백 수집
  - 고객 지원 채널을 통해 사용자 피드백을 수집하고, 이를 분석하여 잠재적인 문제 조기에 식별
- 리얼 유저 모니터링(RUM)
  - 실제 사용자의 웹 브라우저에서 데이터를 수집하여 페이지 로드 시간, 응답시간 등을 모니터링하고 사용자 경험을 개선함 (ex) 구글 애널리틱스 )

알림 및 경고 시스템

알림 설정 : 임계값을 설정하여 시스템 상태가 비정상일 때 자동으로 알림 전송
경고 기준 : 명확한 경고 기준을 설정하여 불필요한 알림을 줄이고 장애에 즉시 대응할 수 있도록 해야함
알림 자동화 : 장애 발생 시 자동으로 대응 프로세스를 실행할 수 있도록 자동화된 스크립트를 설정

모니터링 도구

Prometheus & Grafana : 오픈 소스 모니터링 및 알림 툴로서, 시스템의 메트릭 데이터를 수집하고 시각화하는 데 사용됨. 대시보드를 생성하고 데이터를 시각적으로 분석하는 데 유용
ELK 스택 (Elasticsearch, Logstash, Kibana) : 로그 데이터를 수집, 저장, 분석 및 시각화하는 데 사용되는 강력한 도구. 각 컴포넌트는 각각의 역할을 수행하여 대규모 로그 데이터를 효율적으로 처리함
New Relic : App 성능 모니터링 (APM) 및 사용자 경험 모니터링을 위한 도구로, 실시간 성능 데이터를 제공하여 문제를 신속히 해결할 수 있도록 도움

모니터링 고려사항

지속적인 모니터링 및 개선 : 정기적으로 점검하고 조정하여 모니터링 시스템을 최신 상태로 유지해야함
중앙 집중식 로그 관리 : 로그는 한 곳에 모아 분석하여 시스템의 전반적인 상태를 명확하게 파악할 수 있어야 함
협업과 공유 : 모니터링 데이터를 팀 간에 공유하여 보다 효과적인 장애 대응이 가능하도록 함
테스트 및 시뮬레이션 : 장애 시나리오를 테스트하고 모니터링 시스템이 정확하게 작동하는 지 검증

장애 분석 및 진단

초기 대응

장애 보고 및 인지
- 장애 보고 체계 확립 : 누군가가 계속해서 모니터링 하기에는 실 서비스에서는 많은 인프라가 동작하고 있음. 자동 알림 시스템을 통해 장애 발생을 즉시 인지할 수 있도록 설정함
- 장애 상황 인지 : 장애 발생 시, 즉시 관련 팀에게 통보하여 초동 조치를 취할 수 있도록 함
초기 평가
- 장애의 심각도 평가 : 장애의 영향을 평가하여 우선순위를 정함. 서비스 중단, 성능 저하, 데이터 손상 등의 영향을 고려함
- 초기 대응 전략 수립 : 장애 상황에 맞는 초기 대응 계획을 수립하고, 관련 리소스를 할당함
장애 원인 분석
- 문제 재현 : 장애 상황을 재현하여 근본 원인을 명확히 파악함. 이를 통해 동일한 상황에서 재발 방지를 위한 구체적인 조치를 설계할 수 있음
- 장애 패턴 인식 : 장애 로그와 메트릭을 기반으로 과거 유사한 장애 패턴을 분석하여 패턴에 따른 원인을 찾아냄

로그 및 메트릭 분석

로그 분석
- 로그 수집 : 중앙 집중식 로그 관리 시스템에서 로그 데이터를 수집하고 분석함
- 오류 및 예외 분석 : 로그를 통해 App에서 발생한 오류와 예외를 추적하여 장애의 원인을 파악함
- 로그 패턴 분석 : 패턴 인식을 통해 과거의 유사한 장애 사례를 파악하고 대응책을 도출함
메트릭 분석
- 실시간 메트릭 모니터링 : CPU 사용률, 메모리 사용량, 네트워크 트래픽 등 실시간 메트릭을 모니터링하여 비정상적인 활동을 탐지함
- 메트릭 데이터 비교 : 정상 상태와 장애 상태의 메트릭을 비교하여 이상 현상을 식별함
- 임계값 분석 : 설정된 임계값을 초과하는 메트릭을 확인하여 장애의 징후를 발견함

시스템 및 네트워크 분석

시스템 분석
- 프로세스 상태 점검 : 프로세스를 점검하여 비정상적으로 작동중인 프로세스를 식별
- 리소스 사용 추적 : 시스템 리소스(CPU, 메모리, 디스크 I/O)의 과도한 사용을 추적하여 장애의 원인을 분석함
- 스레드 덤프 분석 : JVM 스레드 덤프를 분석하여 교착 상태(Deadlock) 및 스레드 고갈 문제를 진단함
네트워크 분석
- 네트워크 트래픽 모니터링 : 네트워크 트래픽을 분석하여 패킷 손실, 지연, 대역폭 초과 등의 문제를 식별함
- 네트워크 토폴로지 점검 : 네트워크 구조를 점검하여 구성상의 문제를 진단함
- 연결 상태 분석 : 외부 시스템 및 API와의 연결 상태를 점검하여 네트워크 장애를 진단함

DB 분석

쿼리 성능 분석
- 슬로우 쿼리 로그 분석 : 성능이 저하된 쿼리를 식별하고, 인덱스 최적화 및 쿼리 재작성으로 해결함
- DB 락 분석 : 락 대기 및 데드락 상황을 식별하고 해결책을 찾음
- 커넥션 풀 상태 점검 : DB 커넥션 풀(DBCP)의 상태를 점검하여 연결 문제를 진단
데이터 일관성 점검
- 데이터 무결성 확인 : DB의 무결성을 점검하여 데이터 손상 여부를 확인
- 데이터 복구 절차 실행 : 손상된 데이터의 복구 절차를 실행하여 DB의 정상 상태를 복구함

송형근

기록을 남겨보자

이전 포스트

240818 TIL

다음 포스트