코딩하는 주노 이야기

[MSSQL] Blocking 유발하는 세션(root blocker)을 찾아내고, 운영자 계정에 root blocker만 kill할 수 있는 프로시저 제공하기

코_노 — Wed, 31 Dec 2025 11:37:57 +0900

원래 MSSQL 에서 Session Kill 할 수 있는 권한은 DBA만 가지고 있는 게 바람직하다.

MSSQL에서의 Session Kill 권한은 기본적으로, 'ALTER ANY CONNECTION' 권한이 부여되어 있어야 하며, 이는 서버 인스턴스 범위의 권한이기에, 해당 권한을 가진 SQL Login은 모든 세션에 대해 Kill 할 수 있는 아주 강력하고 위험한 권한을 가지게 된다.

그러나, 모든 운영 환경에 있어 DBA가 365일 24시간 내내 5분대기조처럼 있을 수는 없고,
상황에 따라서 Kill 을 수행할 수 있는 조건만 잘 제어한다면,
운영자에게 특정 상황의 경우에만 Kill 할 수 있는 프로시저를 제공하는 게,
긴급한 장애도 해결하고 DBA도 한결 편해질 수 있는 방법임을 요즘 체감한다.

오늘은 그에 대한 방법에 대해 알아보고자 한다.

먼저 현재 Blocking을 유발하는 세션, 즉, root blocker session을 찾는 쿼리는 다음 쿼리를 수행한다.

아래 쿼리를 프로시저화 시켜서, 운영자용 계정에 실행 권한을 부여하는 것도 blocking을 빠르게 확인하는 데에 도움이 될 것이다.

SELECT req.session_id
	, ses.host_name
	, ses.login_name
	, req.status
	, req.blocking_session_id	-- 이 값이 0이면, 다음 중 하나. 1. root blocker / 2. blocking 상태는 아님.
	, req.wait_type
	, SUBSTRING(sql_text.text,req.statement_start_offset/2, 
		(CASE 
			WHEN req.statement_end_offset = -1
			THEN LEN(CONVERT(NVARCHAR(max), sql_text.text)) * 2
			ELSE req.statement_end_offset 
			END - req.statement_start_offset)/2
	) AS [Query_Text] --- statement of batch or proc executing right now
	, DB_NAME(ses.database_id) AS [Current Used DB] 
	, CAST(DATEDIFF(ss, req.start_time, GETDATE()) AS NVARCHAR)+ N'초' AS [Request 경과시간]
	, object_name(sql_text.objectid) AS [SP명]	-- ad-hoc 또는 prepared SQL statement 라면, Null 로 나옴
	, req.cpu_time AS [CPU_Time (ms단위)]
	, req.total_elapsed_time
	, req.reads
	, req.writes 
	, req.logical_reads 
	, req.scheduler_id
FROM sys.dm_exec_requests AS req WITH (NOLOCK)
INNER JOIN sys.dm_exec_sessions AS ses WITH (NOLOCK) ON req.session_id = ses.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) AS sql_text
WHERE req.session_id > 50 
	AND sql_text.text NOT LIKE '%sp_server_diagnostics%'
ORDER BY req.blocking_session_id, req.session_id, req.status, req.cpu_time, req.logical_reads

0. 테스트 DB 및 Table 생성

프로시저를 생성하기에 앞서, 설명할 프로시저가 잘 동작하는 지 테스트 해 볼 필요가 있으므로, 테스트 환경을 구성하는 쿼리부터 수행하자. (이 프로시저를 운영 환경에서 바로 테스트하는 건 당연히 안 되니까.)

-- 테스트용 데이터베이스 생성 (최초 1회)
IF NOT EXISTS (SELECT name FROM sys.databases WHERE name = 'TestBlockingDB')
BEGIN
    CREATE DATABASE TestBlockingDB;
END
GO

USE TestBlockingDB;
GO

-- 테스트용 테이블 생성 (최초 1회)
IF OBJECT_ID('dbo.TestTable') IS NULL
BEGIN
    CREATE TABLE dbo.TestTable (
        ID INT PRIMARY KEY,
        Name NVARCHAR(50),
        Value INT
    );
    INSERT INTO dbo.TestTable (ID, Name, Value) VALUES (1, 'Item A', 10);
    INSERT INTO dbo.TestTable (ID, Name, Value) VALUES (2, 'Item B', 20);
    PRINT '[TestTable] Table creation and test data insertion complete.';
END
ELSE
BEGIN
    PRINT '[TestTable] already exists!!!';
END
GO

1. Session Kill 을 [운영자 계정] 대신 수행(IMPERSONATE)할 계정 생성

여기서는 'KillUser' 라고 유저를 생성해서 설명한다.

/* EXECUTE AS 용도로 사용할 KILL 전용 계정 생성 */

USE [master];
GO

IF NOT EXISTS (SELECT * FROM sys.sql_logins WHERE name = 'KillerUser')
BEGIN
    CREATE LOGIN KillerUser 
		WITH PASSWORD = 'MyStrongPassword!', 
		CHECK_POLICY = ON,
		DEFAULT_DATABASE = [master]
    PRINT '[KillerUser] Login creation complete.';
END
ELSE
BEGIN
    PRINT '[KillerUser] Login already exists!!!';
END

-- KillerUser SQL 로그인을 master DB의 유저로 매핑
USE [master]; -- master DB 컨텍스트에서 실행
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = 'KillerUser')
BEGIN
    CREATE USER KillerUser FOR LOGIN KillerUser;
    PRINT '[KillerUser] Login successfully mapped to the [master] database as a user.';
END
ELSE
BEGIN
    PRINT 'The user [KillUser] already exists in the [master] DB!!!';
END

-- KillerUser 로그인에게 ALTER ANY CONNECTION, VIEW SERVER STATE 서버 권한만 부여
GRANT ALTER ANY CONNECTION TO KillerUser;
PRINT 'ALTER ANY CONNECTION permission to [KillerUser].';
GRANT VIEW SERVER STATE TO KillerUser;
PRINT 'Granted VIEW SERVER STATE permission to [KillerUser].';

-- 생성된 KillerUser 로그인을 직접 로그인 불가하도록 DISABLE (보안상 권장)
ALTER LOGIN KillerUser DISABLE;
PRINT '[KillerUser] Login disable complete.';

-- 생성된 KillerUser 로그인을 impersonate 할 수 있도록 운영자 계정에 권한 부여
GRANT IMPERSONATE ON USER::KillerUser TO [특정_APP_운영자용_계정]

2. 프로시저 생성 및 실행 권한 부여

Blocking 유발 세션 조회 쿼리 프로시저인 [sp_GetBlockingInfo] 생성

USE master; -- 실제 운영 환경에서는 별도 공용 DB (ex. [DBA_Tools]) 생성 권장
GO

-- 기존 프로시저가 있다면 삭제
IF OBJECT_ID('dbo.sp_GetBlockingInfo') IS NOT NULL
    DROP PROCEDURE dbo.sp_GetBlockingInfo;
GO

CREATE PROCEDURE dbo.sp_GetBlockingInfo
    @specific_spid INT = NULL -- 특정 SPID를 입력받아 그 SPID 및 그와 관련된 blocking/blocked 정보를 조회
AS
BEGIN
    SET NOCOUNT ON;

    SELECT
        req.session_id,
        ses.host_name,
        ses.login_name,
        req.status,
        req.blocking_session_id,
        req.wait_type,
        SUBSTRING(sql_text.text, req.statement_start_offset / 2,
            (CASE
                WHEN req.statement_end_offset = -1
                THEN LEN(CONVERT(NVARCHAR(max), sql_text.text)) * 2
                ELSE req.statement_end_offset
            END - req.statement_start_offset) / 2
        ) AS [Query_Text],
        DB_NAME(ses.database_id) AS [Current Used DB],
        CAST(DATEDIFF(ss, req.start_time, GETDATE()) AS NVARCHAR) + N'초' AS [Request 경과시간],
        object_name(sql_text.objectid) AS [SP명],
        req.cpu_time AS [CPU_Time (ms단위)],
        req.total_elapsed_time,
        req.reads,
        req.writes,
        req.logical_reads,
        req.scheduler_id
    FROM sys.dm_exec_requests AS req WITH (NOLOCK)
    INNER JOIN sys.dm_exec_sessions AS ses WITH (NOLOCK) ON req.session_id = ses.session_id
    CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) AS sql_text
    WHERE
        req.session_id > 50
        AND sql_text.text NOT LIKE '%sp_server_diagnostics%'
        AND (@specific_spid IS NULL OR req.session_id = @specific_spid OR req.blocking_session_id = @specific_spid) -- 특정 SPID 관련 정보만 필터링
    ORDER BY
        req.blocking_session_id, req.scheduler_id, req.status, req.cpu_time, req.logical_reads;

END;
GO

-- sp_GetBlockingInfo 프로시저 실행 권한을 운영자 계정에 부여
GRANT EXECUTE ON dbo.sp_GetBlockingInfo TO [특정_APP_운영자용_계정];
-- KillerUser도 이 프로시저를 KillerUser 컨텍스트에서 호출할 수 있도록 PUBLIC에 EXECUTE 권한 부여
GRANT EXECUTE ON dbo.sp_GetBlockingInfo TO [KillerUser];

특정 세션 KILL 프로시저인 [sp_KillBlockingSession] 생성

우리는 이 프로시저를 Session Kill 권한이 없는 운영자 계정에 실행 권한을 부여할 예정이므로,
이 프로시저가 특정 상황에서만 동작하도록 잘 제한해야 한다.

간단하게 설명하면, 이 프로시저는 다음의 경우에만 동작한다.

프로시저의 파라미터로 입력한 SPID에 해당하는 세션이 현재도 유효한 활성 세션인지 확인
프로시저의 파라미터로 입력한 SPID에 해당하는 세션이 실제 root blocker 세션이 맞는 지 검증
프로시저의 실행 계정이 파라미터로 입력한 대상 DB에 대해 'public' 이상의 권한이 있는 지 확인

또한, 운영자 계정에 아래 프로시저에 대한 실행 권한뿐만 아니라, 자체적으로도 이미 DB 서버의 lock 등을 확인할 수 있는 권한인, VIEW SERVER STATE 권한도 필요하다. 혹시 해당 권한이 없다면, 아래 쿼리를 수행하여 부여할 수 있다.

-- 아래 쿼리는 sa 권한으로 수행
USE [master];
GRANT VIEW SERVER STATE TO [특정_APP_운영자용_계정];

USE [master]; -- [master] DB보다는 공통으로 관리되는 DB를 별도 생성하고, 해당 DB에 프로시저를 생성하는 것을 보안상 권장.
GO

-- 아래 프로시저를 생성하는 DB는 TRUSTWORTHY ON 설정이 되어 있어야 하므로, 보안 관리에 매우 주의가 필요.
ALTER DATABASE [master] SET TRUSTWORTHY ON;

-- 기존 프로시저가 있다면 삭제
IF OBJECT_ID('dbo.sp_KillBlockingSession') IS NOT NULL
    DROP PROCEDURE dbo.sp_KillBlockingSession;
GO

CREATE PROCEDURE dbo.sp_KillBlockingSession
    @spid_to_kill INT,
    @target_db_name SYSNAME
WITH EXECUTE AS 'KillerUser'
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @session_exists BIT = 0;
    DECLARE @is_root_blocker BIT = 0;
    DECLARE @session_db_name SYSNAME;
    DECLARE @caller_login_name SYSNAME = ORIGINAL_LOGIN();
    DECLARE @command NVARCHAR(100);

    -- sp_GetBlockingInfo의 결과를 저장할 임시 테이블 변수
    DECLARE @BlockingInfo TABLE (
        session_id INT,
        host_name SYSNAME,
        login_name SYSNAME,
        status NVARCHAR(30),
        blocking_session_id INT,
        wait_type NVARCHAR(60),
        Query_Text NVARCHAR(MAX),
        CurrentUsedDB NVARCHAR(100) NULL,
        Request_ElapsedTime NVARCHAR(50),
        SPName NVARCHAR(200) NULL,
        CPU_Time INT,
        Total_ElapsedTime INT,
        reads BIGINT,
        writes BIGINT,
        logical_reads BIGINT,
        scheduler_id INT
    );

    PRINT '--- SPID ' + CAST(@spid_to_kill AS NVARCHAR) + ' KILL trying... ---';
    PRINT 'Target DB: ' + @target_db_name;
    PRINT 'Caller User: ' + @caller_login_name;

    -- dbo.sp_GetBlockingInfo 호출 및 결과 저장
    INSERT INTO @BlockingInfo
    EXEC dbo.sp_GetBlockingInfo @specific_spid = @spid_to_kill;

    -- 1. 입력 SPID가 유효한 활성 사용자 세션인지 확인
    IF EXISTS (SELECT 1 FROM @BlockingInfo WHERE session_id = @spid_to_kill AND status <> 'sleeping' AND status <> 'dormant')
    BEGIN
        SET @session_exists = 1;
    END

    IF @session_exists = 0
    BEGIN
        PRINT 'ERROR: The specified SPID ' + CAST(@spid_to_kill AS NVARCHAR) + ' is not a valid user session or does not exist.';
        RETURN 1;
    END

    -- 2. Root Blocker 여부 확인 및 세션 DB 정보 가져오기
    SELECT TOP 1 @is_root_blocker = 1,
                 @session_db_name = CurrentUsedDB
    FROM @BlockingInfo
    WHERE session_id = @spid_to_kill
      AND blocking_session_id = 0 -- 본인이 block 당하고 있지 않음
      AND EXISTS (SELECT 1 FROM @BlockingInfo WHERE blocking_session_id = @spid_to_kill); -- 다른 세션을 block하고 있음

    IF @is_root_blocker = 0
    BEGIN
        PRINT 'ERROR: SPID ' + CAST(@spid_to_kill AS NVARCHAR) + ' is not a Root Blocker or a session executing a suitable query, so KILL is not performed.';
        -- 실제 Root Blocker를 찾는 힌트를 줄 수 있음
        DECLARE @actual_blocker_spid INT;
        SELECT TOP 1 @actual_blocker_spid = blocking_session_id
        FROM @BlockingInfo
        WHERE session_id = @spid_to_kill AND blocking_session_id <> 0;

        IF @actual_blocker_spid IS NOT NULL
        BEGIN
             PRINT 'INFO: SPID ' + CAST(@spid_to_kill AS NVARCHAR) + ' is being blocked by SPID ' + CAST(@actual_blocker_spid AS NVARCHAR) + '.';
             PRINT 'INFO: Root Blocker is SPID ' + CAST(@actual_blocker_spid AS NVARCHAR) + ' or in its preceding chain.';
        END
        RETURN 1;
    END

    PRINT 'INFO: SPID ' + CAST(@spid_to_kill AS NVARCHAR) + ' is a Root Blocker.';
    PRINT 'INFO: Current DB for the Root Blocker session: [' + @session_db_name + ']';

    -- 3. 입력받은 Target DB와 Root Blocker 세션의 Current Used DB 일치 여부 확인
    IF @session_db_name IS NULL OR @session_db_name <> @target_db_name
    BEGIN
        PRINT 'ERROR: The DB of the Root Blocker session ''' + ISNULL(@session_db_name, 'NULL') + ''' does not match the requested target DB [' + @target_db_name + ']. KILL will not be performed.';
        RETURN 1;
    END

    PRINT 'INFO: The Root Blocker session''s DB [' + @session_db_name + '] matches the requested target DB [' + @target_db_name + '].';

    -- 4. 프로시저 실행자가 대상 DB에 대해 'public' 이상의 권한이 있는지 확인
    DECLARE @caller_has_db_access BIT = 0;
    
    EXECUTE AS CALLER;
    BEGIN TRY
        IF HAS_DBACCESS(@target_db_name) = 1
        BEGIN
            SET @caller_has_db_access = 1;
        END
    END TRY
    BEGIN CATCH
        -- 대상 DB에 아예 접근 권한이 없어서 HAS_DBACCESS 호출 자체가 에러가 나는 경우
        SET @caller_has_db_access = 0;
    END CATCH
    REVERT;

    IF @caller_has_db_access = 0
    BEGIN
        PRINT 'ERROR: The caller [' + @caller_login_name + '] does not have permission (public or higher) to the target DB [' + @target_db_name + '], so the KILL operation will not be performed!';
        RETURN 1;
    END

    PRINT 'INFO: The calling user [' + @caller_login_name + '] has been verified to have permission for the target DB [' + @target_db_name + '].';
    
    -- KILL 실행 전, Root Blocker의 호스트명과 로그인명 출력
    DECLARE @root_blocker_hostname SYSNAME;
    DECLARE @root_blocker_loginname SYSNAME;

    SELECT TOP 1 @root_blocker_hostname = host_name,
                 @root_blocker_loginname = login_name
    FROM @BlockingInfo
    WHERE session_id = @spid_to_kill;

    PRINT 'WARNING: Attempting to KILL Root Blocker SPID ''' + CAST(@spid_to_kill AS NVARCHAR(10)) + '''.';
    PRINT 'WARNING: Session details - Host: [' + ISNULL(@root_blocker_hostname, 'N/A') + '], Login: [' + ISNULL(@root_blocker_loginname, 'N/A') + '].';

    -- 5. 모든 검증을 통과했으므로 KILL 명령 실행
    SET @command = 'KILL ' + CAST(@spid_to_kill AS NVARCHAR(10));
    PRINT 'INFO: Execute KILL command: ' + @command;
    EXEC sp_executesql @command;
    PRINT 'INFO: SPID ' + CAST(@spid_to_kill AS NVARCHAR(10)) + ' has been successfully KILLed.';

END;
GO

-- 프로시저 실행 권한 부여
-- '특정_애플리케이션_사용자명'에게 이 프로시저를 실행할 권한을 부여합니다.
GRANT EXECUTE ON dbo.sp_KillBlockingSession TO [특정_APP_운영자용_계정];

위 생성된 프로시저 사용 방법

USE [master];
EXEC dbo.sp_KillBlockingSession
    @spid_to_kill = 58,           -- Kill하려는 SPID (예시)
    @target_db_name = 'MyTargetAppDB'; -- Kill을 허용할 특정 DB명 (예시)

3. 실제 Blocking 상황을 테스트 DB에서 유발하고, 프로시저 잘 동작하는 지 확인

이 Blocking 상황을 유발하는 시나리오는 다음과 같다.

SSMS에서 첫번째 쿼리 창에서 아래 'SSMS 쿼리 창 #1' 쿼리를 수행하여 Exclusive Lock(X Lock)을 걸고 트랜잭션을 1시간동안 열어둔다. 그리고 이 쿼리 창은 테스트가 끝나기 전까지 닫거나 COMMIT 또는 ROLLBACK이 되지 않도록 한다.
SSMS에서 두번째 쿼리 창을 열어, 아래 'SSMS 쿼리 창 #2' 쿼리를 수행한다. 위 쿼리에서 잠근 ID = 1 인 행을 업데이트하려고 시도하도록 쿼리를 구성한 것이고, 위에서 실행한 세션이 당연히 닫히지 않았을 테니, 이 쿼리는 Block된다.

-- === SSMS 쿼리 창 #1: Blocking 유발 쿼리 (1시간 딜레이 후 자동 COMMIT) ===
USE TestBlockingDB;
GO

PRINT '=== Start executing query to block the other query ===';
SELECT @@SPID AS 'Blocking_SPID'; -- 이 세션의 SPID를 확인

BEGIN TRAN; -- 트랜잭션 시작

-- ID=1인 행을 업데이트하여 배타적 잠금을 걸고 트랜잭션을 열어둠
UPDATE dbo.TestTable
SET Value = 100
WHERE ID = 1;

PRINT 'Updating row ID=1 and maintaining lock...';
PRINT 'INFO: It will be automatically committed after a 1H delay.';

-- 1시간 대기 (01:00:00)
WAITFOR DELAY '01:00:00';

COMMIT TRAN; -- 1시간 후 자동으로 트랜잭션 커밋 (잠금 해제)

PRINT 'The transaction has been automatically committed. The lock has been released.';

-- === SSMS 쿼리 창 #2: Block될 쿼리 ===
USE TestBlockingDB;
GO

PRINT '=== Start executing query to be blocked ===';
SELECT @@SPID AS 'Blocked_SPID'; -- 이 세션의 SPID를 확인 (예: 59)

-- ID=1인 행을 업데이트 시도 -> Blocking 세션이 잠금을 해제할 때까지 Block될 것임
UPDATE dbo.TestTable
SET Value = 150
WHERE ID = 1;

PRINT 'INFO: Update complete (This message appears after the block is released)';

[sp_GetBlockingInfo] SP를 운영자용 계정에서 실행

-- === SSMS 쿼리 창 #4 (또는 창 #3): Kill 프로시저 실행 ===
USE master; -- 프로시저가 master DB에 있다고 가정
EXEC dbo.sp_GetBlockingInfo;

위 쿼리 수행 결과를 보면, 아래와 같이 block되고 있는 세션은 blocking_session_id의 값이 root blocker 세션의 session_id 값으로 나타날 것이다. 또한 root blocker의 경우, blocking_session_id 값이 0 으로 되어 있는 것을 확인할 수 있다.

[sp_KillBlockingSession] SP를 운영자용 계정에서 실행

-- === SSMS 쿼리 창 #4 (또는 창 #3): Kill 프로시저 실행 ===
USE master; -- 프로시저가 master DB에 있다고 가정

EXEC dbo.sp_KillBlockingSession
    @spid_to_kill = 260,           -- <<--- 실제 Blocking SPID를 입력하세요! (예: 260)
    @target_db_name = 'TestBlockingDB'; -- <<--- Kill하려는 SPID가 사용하는 DB 이름

위와 같이 'SPID # has been successfully KILLed.' 문구가 출력되었다면, 생성한 프로시저가 잘 동작하는 것이고, 테스트 시나리오에서 수행한 'SSMS 쿼리 창 #1'에 세션이 끊긴 문구가 출력된 것을 볼 수 있을 것이다.

4. 테스트 DB 삭제

위와 같이 생성한 프로시저들이 모두 잘 동작하는 것을 확인했다면, 다음과 같이 테스트 DB를 삭제하면서 마무리 하도록 하자!

-- 테스트 정리 (필요 시)
USE master;
GO
DROP DATABASE TestBlockingDB;
GO

[MSSQL] SQL Server Failover Cluster 구성

코_노 — Fri, 1 Aug 2025 19:14:52 +0900

0. 사전 준비

0.1. Windows Server Failover Cluster(WSFC) Feature(기능) 설치

아래와 같이 [Server Manager] 를 통해, 'Failover Clustering' Feature를 설치해 주어야 한다.

해당 feature 설치 후에는 안정적인 운영을 위해 시스템 reboot 가 필요할 수 있는 점 인지하자.

0.2. Windows Server Failover Cluster 구성

[Create Cluster] 를 클릭 후, [Create Clustser Wizard] 에서 아래와 같이, Failover Cluster에 추가할 node(서버)들의 hostname을 입력하여 추가한다.

그럼 다음과 같이 Failover Cluster 구성이 가능한 지 Validation을 할 것인지 묻는데, 안전하게 Failover Cluster를 구성하기 위해, Yes를 클릭 후 Next로 넘어가자!

위 과정에서 Next, Next 진행하다 보면, [Validate a Configuration Wizard] 가 나타나고, 여기에서 Failover Cluster 구성에 필요한 Validation을 실질적으로 진행하게 된다. 그럼 다음과 같이 'Summary' 로 결과까지 볼 수 있게 되는데, 여기에서 Success로 나타나지 않은 것들은 추후에 Failover Cluster 구성에 문제가 생길 수 있으므로, 문제가 생긴다면 이 부분 먼저 살펴보도록 하자.

Validation이 끝나면 다음과 같이 [Access Point for Administering the Cluster] 단계로, 여기에서 실제 Failover Cluster의 이름과 이에 매핑되는 IP를 지정하게 된다. 여기에서 설정하는 IP는 실제 다른 node에서 사용하고 있는 IP를 쓰면 안되므로, 잘 설정하자!

아래와 같은 화면을 본다면, WSFC 생성은 성공적으로 마친 것이다!

☞ Failover Cluster - 트러블슈팅

'Access is denied'

아래와 같은 에러가 나타났다면, 현재 Failover Clustesr 생성을 진행하고 있는 AD 계정이 domain controller 권한이 아니기 때문에, Computer Object 의 생성 권한이 없어서 생기는 문제일 것이다. 이는 사내의 AD 담당자에게 요청하여, 현재 구성을 진행하고 있는 AD 계정에 적절한 권한을 부여 받아야 한다.

위와 같이 기본적인 WSFC 기능의 활성화와 함께 SQL Server Failover Cluster 를 구성할 node들을 해당 WSFC에 구성하였다면, 본격적으로 SQL Server Failover Cluster 구성에 대해 알아보도록 하자.

1. SQL Server Failover Cluster 에서 사용할 디스크들을 WSFC에 등록

[Failover Cluster Manager] 를 열어, 왼쪽 탭에서 [Disks] 로 가면, [Add Disk]가 있는데, 이걸 클릭하면 아래와 같은 화면이 나온다. 이때, WSFC에 들어가 있는 node들 간에 공유할 수 있는 disk가 있다면, [Add Disk]를 수행할 디스크들을 선택할 수 있도록 하는 화면이 나오는 것이다.

MSSQL의 FCI(Failover Cluster Instance)를 구성하기 위해서는, 스토리지상 동일한 볼륨에 대해서 WSFC에 참여한 member node 간 disk를 Active-Standby 형태로 공유하는 것이므로, WSFC에 참여한 member node 들에서 하나의 node에만 해당 볼륨을 mount 하는 것이 맞다. (OS 상에서 동일한 볼륨에 대해 LUN을 같게 하는 것 자체가 불가할 것이다.)

1.1. Disk Witness in Quorum 설정 - SQL Server Failover cluster 노드 수가 짝수일 때에만 (특히 2대)

2노드 클러스터는 다음과 같은 문제를 가지고 있다.

노드 1 (1 투표 행사) + 노드 2 (1 투표 행사) = 총 2 투표
이 상태에서 만약 두 노드 중 하나라도 다운되거나 네트워크 통신이 끊기면, 남은 노드 혼자서는 과반수 (총 투표수 2의 과반수는 2)를 확보할 수가 없게 되므로, 클러스터 전체가 오프라인이 되어 버린다. 즉 기껏 Failover Cluster를 구성해 놓고도 HA가 보장되지 않는 것이다.

위와 같은 문제를 해결하기 위해, 1 투표를 행사할 수 있도록 하는 역할을 하는 볼륨을 하나 더 mount 하여, 해당 LUN에 대해 [Disk Witness] 역할을 수행하도록 하는 것이다. 따라서, 2노드로만 이루어져 있거나, 클러스터의 총 노드 수가 짝수가 되어 과반수가 애매해질 경우, 그만큼을 [Disk Witness] 로 설정하여 HA를 보장할 수 있도록 구성해야 한다.

참고로, Disk Witness 역할을 수행하는 Disk는 해당 LUN이 정상적으로 동작하기만 한다면 쿼럼상 1투표를 행사할 수 있는 것이기 때문에, WSFC 상에서 어느 node에 있던 상관이 없다.

[Disk witness] 방식의 쿼럼 설정 방법은 다음과 같다.

위와 같이 해당 [Failover Cluster Manager] - [해당 클러스터 이름] - Actions 탭의 [More Actions] - [Configure Cluster Quorum Settings] 를 클릭하고 [Next] 를 누르면 다음과 같이 나온다.

그럼 위와 같이 [Select the quorum witness] 를 선택하고 Next 를 클릭한다.

Quorum witness 를 구성하는 방식은 다양하지만, 여기서 우리가 설정할 것은 [Disk Witness in Quorum] 방식이므로, [Configure a disk witness] 를 선택한다.

필자의 경우, 이미 SQL Server FCI 와 쿼럼을 구성해놓은 상태이기 때문에 저렇게 나타나는데, 아직 쿼럼 구성을 해 두지 않았다면, 쿼럼용으로 mount 한 디스크 (SQL Server FCI 그룹에 들어가 있으면 안됨)를 선택하고 Next 를 클릭한다.

그럼 위와 같이 [Confirmation] 을 거쳐, 최종적으로 [Disk witness] 방식의 쿼럼을 설정하게 된다.

그럼 결과물로 아래와 같이 해당 disk가 [Disk Witness In Quorum] 으로 설정되어 있는 지 반드시 확인하자!

2. Active node에서 SQL Server FCI(Failover Cluster Instance) 최초 구성

위 MSSQL 설치 화면에서 [Installation] - [New SQL Server failover cluster installation] 을 클릭하고 다음을 넘어가다보면, 아래와 같이 Feature Selection 부분부터 세세히 봐야할 필요가 있다.

Instance root directory: SQL Server 인스턴스에 종속적인 핵심 파일이 설치되는 최상위 디렉토리로, 바이너리 파일(실행 파일, DLL 등), DB 엔진, 인스턴스별 설정 파일, 오류 로그, 트레이스 파일 등과 함께, SQL Server Agent, SSAS, SSIS, SSRS 인스턴스별로 선택된 기능의 실행에 필요한 파일들이 포함된다.
- FCI 구성 시에는, SQL Server 서비스가 실행될 각 Cluster node 에서의 local drive 하위로 지정이 되어야 한다.
  공유 스토리지가 아닌 각 node에 독립적으로 SQL Server 실행 파일을 가지고 있어야, failover 시 문제 없이 SQL Server 서비스가 시작될 수 있기 때문이다.
Shared feature directory: 서버에 설치된 모든 SQL Server 인스턴스가 공유하는 공통 구성 요소들이 설치되는 디렉토리로, Client Tools Connectivity (ODBC 드라이버, OLE DB provider, SQL Native Client 등), SQL Server Browser 서비스, SQL Server Writer 서비스와 같이 여러 MSSQL 인스턴스에 공통적으로 필요한 서비스 파일들이 설치되는 디렉토리이다.
Shared feature directory (x86): Shared feature directory와 동일하게 모든 SQL Server 인스턴스가 공유하는 공통 구성 요소들이 저장되는 디렉토리이지만, 32비트 버전의 파일들을 위한 경로

그럼 아래 화면에서 보면, [SQL Server Network Name] 을 입력해야 되는 부분이 나오는데, 이거는 실제 Client들이 SQL Server FCI에 연결할 때 사용할 SQL Server vIP와 매핑되는 domain name으로 신중하게 결정해야 한다.

특히, 기존에 이미 client들에게 공유된 domain name이 있고, 그 시스템을 마이그레이션하는 것이라면, 해당 domain name과 동일하게 설정하는 것이 나중에 client들이 변경사항을 최소화하므로 유리할 것이다.

여기에 입력된 domain name은 SQL Server FCI가 설치되면서 자동으로 DNS 서버에 [Cluster Network Configuration] 에서 지정한 IP와 함께 매핑되도록 등록한다.

위 단계 다음으로 [Cluster Resource Group] 단계이다.

아래 [SQL Server cluster resource group name] 에 설정하는 부분이 결국에 WSFC 상에서 아래와 같이 [Roles]의 name으로 설정되게 되므로, 각 인프라의 convention 에 따라 설정하면 되겠다.

그리고 [Qualified] 란이 빨간색 네모로 보이며, Message를 보면 자칫 Failover Cluster 를 구성할 수 없는 것처럼 보이는데, 이 상태에서 Next 로 다음 Phase로 넘어가도 SQL Server FCI를 구성하는 데에는 큰 문제가 없을 것이다.

그 이유는 SQL Server FCI가 구성하는 메커니즘을 이해해야 한다. SQL Server FCI는 WSFC에 이미 존재하는 리소스 그룹을 사용하는 게 아니라, 새로운 독립적인 리소스 그룹을 만들고, 그 안에 SQL Server FCI 자신이 필요로 하는 모든 리소스들을 포함하는 방식으로 생성이 된다. 따라서 아래의 [Qualified] 란에 빨간색으로 부적격으로 표시되는 이유는, 이미 WSFC에 생성되어 있는 Available Storage 그룹과 Cluster Group은 신규로 생성하는 SQL Server FCI에 사용하기에는 부적합하다는 의미로 받아들이면 된다. 따라서, 강제로 해당 그룹에 SQL Server FCI 리소스들을 넣으면 안된다는 것이다!

다음으로는 [Cluster Disk Selection] 단계이다. 여기서 매우 주의해야할 점이 있다.

필자의 경우, SQL Server FCI에서 사용할 데이터,로그,tempdb,백업 파일 등이 저장될 용도의 볼륨 1곳('Cluster Disk 1'), 쿼럼용 볼륨 1곳('Cluster Disk 2')으로 OS상에서 disk를 mount 시켰는데, 이 단계에서 쿼럼용 볼륨을 체크해서는 안된다. 여기에서 선택하는 disk는 오로지 SQL Server FCI 에서 사용되는 모든 DB와 관련된 파일(.mdf, .ldf, tempdb, backup files)등이 default 로 저장되는 위치로 설정해야만 올바른 SQL Server FCI를 구성할 수 있다. 쿼럼은 이러한 Disk의 failover 시 vote 역할만 수행하는 witness임을 잊지 말자!

다음으로는 [Cluster Network Configuration] 단계이며, 여기에서 중요한 포인트는 [Address] 를 설정하는 부분이다. 이 부분이 이전 [Instance Configuration] 에서 설정한 [SQL Server Network Name] 과 매핑될 IP이며, SQL Server FCI의 실제 vIP(Client가 접속을 시도하는 서비스 IP)에 해당하는 IP를 넣어야 하는 것이다.

[Server Configuration] 에서는 올바른 SQL Server 인스턴스 및 Agent의 서비스 계정 설정 및 Collation 을 선택하도록 하고, 다음으로 중요하게 볼 단계가 [Database Engine Configuration] 이다. 아래처럼 보이는 [Data Directories] 에서 각 항목별로 의미하는 바는 다음과 같다.

☞ 참고로 하기 디렉토리들에 이미 기존 MSSQL 인스턴스가 사용하거나 기존 MSSQL 인스턴스가 사용하던 .mdf, .ndf, .ldf, .bak 파일 등이 남아 있으면, 해당 경로를 지정하여 SQL Server 인스턴스 설치가 불가하므로, 미리 다른 데로 옮겨두든 삭제하든 해야 한다.

Data root directory: SQL Server 인스턴스가 설치될 때, 시스템 데이터베이스 파일(.mdf, .ldf)의 기본 저장 위치로 사용되는 경로로, 일반적으로 이 디렉토리 하위에 'MSSQL\Data'와 같은 디렉토리를 추가로 생성하여 그 하위에 SQL Server 인스턴스의 시스템 DB(master, model, msdb) 파일이 저장된다.
- 여기서 중요한 점은, SQL Server FCI의 경우, 시스템 DB가 Failover Cluster의 node간 공유가 되어야 하므로, node의 local drive가 아닌 WSFC에 디스크로 참여하는 공유되는 볼륨의 drive로 지정해야 한다는 것이다.
User database directory: 별도로 설정하지 않으면 [Data root directory] 하위에 'MSSQL\Data' 디렉토리 하위로 지정되며, 이 디렉토리는 User DB의 데이터 파일(.mdf)이 저장되는 위치이다. DB 생성 시, 각 DB마다 이 디렉토리와 다른 별도의 디렉토리로 해당 DB 파일의 저장 경로를 설정할 수 있지만, 별도로 설정하지 않게 되면 default로 사용하게 될 디렉토리이다.
User database log directory: User DB의 로그 파일(.ldf) 파일이 기본적으로 저장될 위치를 설정하는 것이다.
Backup directory: DB의 백업 파일 (.bak, .trn)이 기본적으로 저장될 위치를 설정하는 것이다.

위와 같은 과정을 거쳐 SQL Server Failover Cluster의 Active Node로 사용할 서버에서 SQL Server FCI 구성을 모두 마치게 된 것이다.

3. SQL server Failover Cluster에 Node 추가

아래와 같이 Standby Node로 이동하여 [SQL Server Installation Center] - [Installation] - [Add node to a SQL Server failover cluster] 를 선택하여 해당 node를 구성된 SQL Server Failover Cluster에 넣어주도록 하자!

몇 번 Next 로 넘어가다 보면, 아래와 같이 [Cluster Node Configuration] 단계가 나오는데, 여기에서 SQL Server Failover Cluster를 여러개 구성한 경우, 현재 node가 조인될 클러스터 그룹을 잘 선택하도록 하자.

그럼 아래와 같이 [Cluster Network Configuration] 단계가 되는데, 여기에 표기된 IP는 이미 SQL Server FCI 구성 시에 설정한 해당 failover cluster의 SQL Server vIP 를 그대로 가져오므로, 해당 IP가 맞는지 그리고 체크박스에 체크된 것 확인하고 넘어가면 된다.

다음 단계로는 [Service Accounts] 인데, 여기에서 SQL Server FCI 구성 시에 입력한 SQL Server 및 Agent의 서비스 계정 정보를 그대로 가져오므로, 해당 계정의 패스워드를 한번 더 입력한 후 Next로 넘어가야 한다.

나머지는 Next 를 하다 보면, [Complete] 가 되어 Add Node 까지 끝나게 된다!

이렇게 한 후, 아래 과정을 통해 ,실제 MSSQL 인스턴스의 failover 가 잘 수행되는 지 확인해 보면 SQL Server Failover Cluster 구성이 끝이 난다!

[Actions] Github Actions 를 시작하기 전, 기본 개념 익히기

코_노 — Sat, 22 Feb 2025 09:00:10 +0900

GitHub Actions 이란?

: 빌드, 테스트, 배포 파이프라인을 자동화할 수 있게 해주는 Github의 CI/CD 플랫폼

Github Repository로의 모든 Pull Request를 빌드하고 테스트하는 워크플로우를 생성하거나, Merge된 Pull Request를 프로덕션(서버)에 배포하는 등의 작업을 수행할 수 있게 함
단순히 DevOps를 넘어서, Github Repository에서 여러 이벤트가 발생할 때 워크플로우를 실행하게 한다. 예를 들어, 새로운 Issue를 만든 사람에게 자동으로 적절한 Label을 추가하는 워크플로우를 실행할 수도 있음
GitHub은 워크플로우를 실행할 Linux, Windows, macOS 기반의 VM을 제공하거나, 유저가 관리하는 데이터 센터 또는 클라우드 인프라에서 Self-Hosted Runner를 호스팅 할 수 있음

Github Actions의 Component

Github Actions의 Component인 'Event', 'Runner', 'Job', 'Step' 의 구조

Workflow (워크플로)

: Github의 Repository 안에서 하나 이상의 Job(작업)을 가지는 YAML 단위의 자동화 프로세스.

Repo 기준 최상단에서 .github/workflows 디렉토리 하위에 위치하며, .yml 파일로 존재
한 Repo 안에 여러 개의 워크플로(.yml 파일)를 가질 수 있고, 각각 다른 일련의 작업 수행 가능
Github의 Repository의 특정한 Event(Push, PR, Issue 등)에 의해 트리거됨
수동으로 트리거 또는 정의된 일정에 따라 진행 가능
한 워크플로 내에서 다른 워크플로 참조도 가능 (Reusing Workflow)
→ https://docs.github.com/en/actions/sharing-automations/reusing-workflows
워크플로에 대한 더 자세한 정보
→ https://docs.github.com/en/actions/writing-workflows

Events (이벤트)

: Workflow 실행을 트리거하는 Repository의 특정 활동

이 ‘활동’은 예를 들면, Github 상에서 누군가가 PR(Pull Request) 또는 Issue를 생성하거나, 커밋을 Repo에 Push 하는 등의 행위를 수행하는 것으로부터 기원한다.

워크플로 안에서 on 구문으로서, 첫 시작에 대한 조건에 해당하는 부분
on 구문 안에서 schedule 을 설정하여 일정 시간 자체를 트리거로 하는 워크플로 설정 가능
→ https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
REST API의 POST 요청으로 Repo에 이벤트를 가할 수도 있음
→ https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#create-a-repository-dispatch-event
워크플로를 트리거하는 데에 사용할 수 있는 전체 이벤트 목록
→ https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows

Jobs (작업)

: 한 runner 안에서 실행되는 하나의 워크플로 안의 ‘step’들의 집합

default로 job은 서로 간의 종속성이 없어 병렬로 실행되나, 서로 간의 종속성을 만들어 직렬로 수행도 가능
각 step은 실행될 쉘 스크립트 또는 실행될 하나의 action 단위를 의미
각 step은 순차적으로 실행되며, 이에 따라 이전 step에 의존하게 됨
각 step은 하나의 runner 안에서 실행되므로, 서로 데이터를 공유할 수 있음.
예를 들면, 애플리케이션을 빌드하는 step 다음에 빌드된 애플리케이션을 테스트하는 step을 가질 수 있음
작업에 대한 더 자세한 정보
→ https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does

Actions (액션)

: 복잡하지만 자주 반복되는 task를 수행하는 Github Actions 에서만 사용 가능한 커스텀 애플리케이션

워크플로 파일 안에서 반복되는 코드의 양을 획기적으로 줄여줌
워크플로가 실행되는 Github Repo와 연동되는 Git Repo 를 가져오거나, 빌드 환경에 맞는 올바른 Tool-Chain을 설정하거나, 클라우드 제공업체에 대한 authentication 을 설정 가능
Github 마켓플레이스에서 워크플로에 사용할 액션을 찾을 수 있고, 직접 작성도 가능
action 생성에 대한 더 자세한 정보
→ https://docs.github.com/en/actions/sharing-automations

Runners (러너)

: 워크플로가 트리거될 때, 해당 워크플로를 실행하는 주체가 되는 서버

각 러너는 한 번에 하나의 job을 실행할 수 있음
Github은 자체적으로 워크플로를 실행할 수 있는 Ubuntu, Windows, macOS 러너를 제공
각 워크플로 실행마다 깔끔하게 프로비저닝된 새삥(?) VM에서 실행됨
다른 OS 또는 특정 H/W 구성이 필요한 경우, ‘self-hosted’ runner 구성 가능
→ https://docs.github.com/en/actions/hosting-your-own-runners
‘larger runner’ 에 대한 더 자세한 정보
→ https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners

참고

https://docs.github.com/en/actions/about-github-actions/understanding-github-actions

Understanding GitHub Actions - GitHub Docs

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged

docs.github.com

[MSSQL] 모든 유저 데이터베이스의 파일 사이즈 기록하는 Agent Job 만들기

코_노 — Fri, 21 Jun 2024 08:23:38 +0900

DB 마이그레이션이나 다른 유지보수성 작업을 할 때,

DB에서의 데이터 사용량이 날마다 얼마나 늘어나는 지 기록해 둘 필요가 있을 수 있다.

물론, 요즘엔 모니터링 Tool 이 너무나 잘 나와서 이런 프로시저나 Agent Job 을 굳이 생성해야 하나 싶지만,

그런 모니터링 Tool 도입이나 사용이 어려운 상황이 있을 수 있으므로,

SQL Server 상에서 아래와 같이 관리용 테이블과 프로시저를 생성하고,

SQL Server Agent Job 을 활용하여 해당 DB의 사이즈들을 기록하는 방법에 대해 알아보자.

1. 파일 사이즈 기록해 둘 테이블 [DBFileSizesLog] 생성

-- 여러 관리 작업과 관련된 데이터가 저장되는 곳인 [msdb]에 테이블을 만들기로 했다.
USE [msdb];
GO

/* 각 DB들의 .mdf, .ldf 파일 사이즈를 기록해 둘 테이블 [DBFileSizesLog] 생성 */
CREATE TABLE DBFileSizesLog (
	[Log_Date] DATETIME DEFAULT GETDATE(),
	[DB_Name] NVARCHAR(50),
	[Logical_File_Name] NVARCHAR(50),
	[File_Storage_Path] NVARCHAR(200),
	[Current_File_Size_MB] DECIMAL(18,4),
	[Used_Space_MB] DECIMAL(18,4),
	[Free_Space_MB] DECIMAL(18,4),
	[Incremental_Usage_Daily_MB] DECIMAL(18,4)
);
GO

필자가 생성할 테이블 내의 컬럼 설명은 다음과 같다.

Log_Date: DB 사이즈를 확인하는 쿼리를 수행한 후, INSERT INTO가 되는 순간에 시간이 기록되는 컬럼
DB_Name: DB의 이름
Logical_File_Name: DB의 Logical Name
File_Storage_Path: 해당 DB의 파일이 저장되는 OS상 디스크 경로
Current_File_Size_MB: 현재 DB가 디스크 상에서 점유 중인 파일의 사이즈
Used_Space_MB: 디스크 상 점유 중인 파일의 사이즈 중에서 실제로 데이터가 사용 중인 사이즈
Free_Space_MB: [Current_File_Size_MB] - [Used_Space_MB]
Incremental_Usage_Daily_MB: 해당 DB의 (하루 전[Used_Space_MB]) - (오늘 확인된 [Used_Space_MB])

1-1. [DBFileSizesLog] 테이블의 사이즈 측정

데이터베이스의 파일 사이즈를 기록하는 테이블 자체 사이즈가 크다면, 배보다 배꼽이 더 커질 수 있으므로,

이 로깅을 위한 테이블의 사이즈가 얼마나 되는 지 가늠해보자.

Log_Date (DATETIME): 8 bytes
DB_Name (NVARCHAR(50)): (최대 50 characters) * (2 bytes per character) = 100 bytes
Logical_File_Name (NVARCHAR(50)) : (최대 50 characters) * (2 bytes per character) = 100 bytes
File_Storage_Path (NVARCHAR(20)) : (최대 200 characters) * (2 bytes per character) = 400 bytes
Current_File_Size_MB (DECIMAL(18,4)): 9 bytes
Used_Space_MB (DECIMAL(18,4)) : 9 bytes
Free_Space_MB (DECIMAL(18,4)) : 9 bytes
Incremental_Usage_Daily_MB (DECIMAL(18,4)) : 9 bytes

위 컬럼들의 사이즈를 모두 더하면, 한 Row의 최대 사이즈는 644 bytes 가 된다.

유저 데이터베이스가 대충 10개 정도 있다고 하고, 각 DB당 .mdf 파일 1개, .ndf 파일 10개, .ldf 파일 1개로 가정한다면,

10 * (1+10+1) * 644 bytes = 77,280 bytes = 75.47 KB 가 된다.

하루에 1번씩 위 프로시저를 수행하고 이 데이터들의 보관 주기를 2년으로 잡으면,

75.47 KB * 730 = 55,092 KB = 53 MB 정도 되므로, 사이즈를 그리 많이 차지하지 않는다.

하루에 1시간씩, 총 24번을 로깅한다고 하여도, 1 GB 를 조금 넘는 정도이다.

용량을 걱정하고 해당 테이블의 데이터를 주기적으로 삭제할 필요는 없을 듯 하다.

2. SQL Server Agnet Job으로 수행할 프로시저 생성

아래 쿼리를 먼저 수행하여, 프로시저 안에 있는 @sql 구문이 제대로 동작하는 지부터 확인해 보자!

 USE [사이즈 측정할 DB Name];
 
INSERT INTO [msdb].[dbo].[DBFileSizesLog] (
    [Log_Date], 
    [DB_Name], 
    [Logical_File_Name], 
    [File_Storage_Path],
    [Current_File_Size_MB], 
    [Used_Space_MB], 
    [Free_Space_MB],
    [Incremental_Usage_Daily_MB]
)
SELECT 
	[Log_Date] = GETDATE(), 
	[DB_Name] = DB_NAME(), 
	[Logical_File_Name] = name,
	[File_Storage_Path] = physical_name,
	[Current_File_Size_MB] = size / 128.0, 
	[Used_Space_MB] = CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0, 
	[Free_Space_MB] = size / 128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0,
	[Incremental_Usage_Daily_MB] = COALESCE(
		(CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0) - (
			SELECT TOP 1 [Used_Space_MB]
			FROM [msdb].[dbo].[DBFileSizesLog]
			WHERE [DB_Name] = DB_NAME() AND [Logical_File_Name] = name
			ORDER BY [Log_Date] DESC
		),
		0
	)
FROM [sys].[database_files]
WHERE type IN (0, 1);

위 쿼리가 제대로 동작한다면, 아래 쿼리로 생성되는 프로시저도 잘 동작할 것이다.

/* SQL Server Agent Job 으로 수행할 프로시저 생성 */
CREATE PROCEDURE USP_Logging_DB_Sizes
AS
BEGIN

	DECLARE @dbName NVARCHAR(128);
	DECLARE @sql	NVARCHAR(MAX);

	-- Cursor to loop through all database
	DECLARE db_cursor CURSOR FOR
	SELECT name
	FROM sys.databases
	WHERE state_desc = 'ONLINE'
	AND name NOT IN ('master', 'model', 'msdb', 'tempdb');

	OPEN db_cursor;
	FETCH NEXT FROM db_cursor INTO @dbName;

	WHILE @@FETCH_STATUS = 0
	BEGIN
		-- Dynamic SQL to switch to the target database and collect file size information
		SET @sql = '
            USE ' + QUOTENAME(@dbName) + ';
			INSERT INTO [msdb].[dbo].[DBFileSizesLog] (
				[Log_Date], 
				[DB_Name], 
				[Logical_File_Name], 
				[File_Storage_Path],
				[Current_File_Size_MB], 
				[Used_Space_MB], 
				[Free_Space_MB],
				[Incremental_Usage_Daily_MB]
			)
			SELECT 
				[Log_Date] = GETDATE(), 
				[DB_Name] = DB_NAME(), 
				[Logical_File_Name] = name,
				[File_Storage_Path] = physical_name,
				[Current_File_Size_MB] = size / 128.0, 
				[Used_Space_MB] = CAST(FILEPROPERTY(name, ''SpaceUsed'') AS INT) / 128.0, 
				[Free_Space_MB] = size / 128.0 - CAST(FILEPROPERTY(name, ''SpaceUsed'') AS INT) / 128.0,
				[Incremental_Usage_Daily_MB] = COALESCE(
					(CAST(FILEPROPERTY(name, ''SpaceUsed'') AS INT) / 128.0) - (
						SELECT TOP 1 [Used_Space_MB]
						FROM [msdb].[dbo].[DBFileSizesLog]
						WHERE [DB_Name] = DB_NAME() AND [Logical_File_Name] = name
						ORDER BY [Log_Date] DESC
						),
					0
				)
			FROM [sys].[database_files]
			WHERE type IN (0, 1);
        ';

		-- Execute the dynamic SQL
		EXEC sp_executesql @sql;

		FETCH NEXT FROM db_cursor INTO @dbName;
	END;

	CLOSE db_cursor;
	DEALLOCATE db_cursor;
END;

3. SQL Server Agent Job 등록

이제 작성한 프로시저를 SQL Server Agent Job 으로서 주기적으로 수행하도록 만들자.

Agent Job 생성은 아래와 같이 SSMS에서 GUI로 하도록 하자.

[SQL Server 에이전트] - [작업] - 마우스 우클릭하여 [새 작업]

새로운 Agent Job 을 생성하는 창이 아래와 같이 나타났다면, 알아볼 수 있도록 적절한 Job 의 이름을 지어주도록 하자.

[새 작업] 창에서 [일반] 탭 입력

그리고 [단계] 에서 새로운 [작업]을 만들며, 여기에서도 해당 [단계] 를 알아보기 쉽도록 'Run Procedures' 와 같이 지어준다.

그리고 가장 중요한 실제 프로시저를 실행하는 쿼리를 아래와 같이 작성해 준다. 위에서 우리가 만든 프로시저 이름을 호출하여 수행해 주어야 한다.

EXEC [msdb].[dbo].[USP_Logging_DB_Sizes]

[새 작업] 창에서의 [단계] - [새로 만들기] - [일반] 창 작성

그리고 다음과 같이 [작업 일정]에 대한 이름, 해당 agent job 이 어느 빈도로, 매번 몇시에, 몇 번이나 반복할 지 등을 다음과 같이 설정해 준다.

[새 작업] 창의 [일정] - [새로 만들기] - [새 작업 일정] 창 작성

그리고 [새 작업] 창의 [확인]을 눌러주면, 당신이 지정한 Job 이름으로 새로운 SQL Server Agent Job 이 생성된 것을 확인할 수 있을 것이다.

Agent Job 생성을 완료했다면, 아래 그림처럼 반드시 해당 Job 을 한번 실행시켜 보도록 하자.

이렇게 Agent Job이 별다른 에러 로그 없이 잘 실행이 되었다면, DB 사이즈를 로깅하는 위 과정을 모두 잘 수행한 것이다.

그럼, 다음 날에 DB 사이즈가 얼마나 변화했는 지 확인해보고, DB 사이즈의 추이를 파악해 보도록 하자!

[Linux] nohup 로그를 주기적으로 rotation 및 삭제하는 방법

코_노 — Tue, 21 May 2024 16:29:47 +0900

WAS(JBoss)의 nohup 로그가 rotate되지 않고 기하급수적으로 쌓인 특정 서버를 발견하고,

이번 기회에 nohup 로그를 일 단위로 rotation 하고, 90일 지난 로그는 삭제하도록 설정하는 방법에 대해 정리해 보고자 한다.

1. 'log_management.sh' 쉘 스크립트 작성

#!/bin/bash

JVM_NAME="$1"

LOG_FILE="/JVM_PATH/${JVM_NAME}/log/nohup/${JVM_NAME}.out"
DATE=$(date +%y%m%d_%H%M%S)
ROTATED_FILE="/JVM_PATH/${JVM_NAME}/log/nohup/${JVM_NAME}.out.${DATE}"


log_rotation() {

    if [[ -s $LOG_FILE ]]; then
        cp "${LOG_FILE}" "${ROTATED_FILE}"
        echo "logfile backup completed!!! cp ${LOG_FILE} ${ROTATED_FILE}"
        cat /dev/null > "${LOG_FILE}"
        
        chown {JBoss Service 계정}:{JBoss Service 그룹} ${ROTATED_FILE}
    else
        echo "There aren't any logs in ${LOG_FILE}"
    fi

    echo "*******************************************************"
}

log_delete() {
    find "/JVM_PATH/${JVM_NAME}/log/nohup/" -mtime +90 -name '*.out.*' | xargs rm
}

log_rotation
log_delete

nohup log의 rotation하는 로직은 간단하다.

현재까지 쌓인 nohup log 파일을 쉘 스크립트가 수행되는 시점이 들어간 파일명으로 복사한 후,

현재 쌓이고 있는 nohup log 파일은 아무 내용이 없도록 만드는 것이다.

이러한 간단한 로직이므로, 이 포스팅에서는 현재까지 쌓인 모든 nohup log를 날짜별로 파싱하여 해당 날짜별로 로그 파일을 따로 분리하는 것은 아님을 유의하자!

각 구문들을 간략히 설명해 보자면 다음과 같다.

JVM_NAME="$1"
'log_management.sh' 쉘 스크립트를 실행할 때, argument로 JVM Name을 넣어 특정 JVM의 nohup log 파일만 rotation 및 삭제하도록 구현하였다.
LOG_FILE="/JVM_PATH/${JVM_NAME}/log/nohup/${JVM_NAME}.out"
nohup log 파일이 쌓이는 절대 경로를 넣은 변수이다.
DATE=$(date +%y%m%d_%H%M%S)
쉘 스크립트를 수행하는 시점의 시간을 '20240521_160125' 와 같은 형태로 넣는 변수이다.
ROTATED_FILE="/JVM_PATH/${JVM_NAME}/log/nohup/${JVM_NAME}.out.${DATE}"
nohup log 파일이 rotation 하여 복사될 log 파일의 절대 경로를 넣은 변수이다.
cat /dev/null > "${LOG_FILE}"
현재 쌓이고 있는 nohup log 파일을 비우는 명령어이다.
chown {JBoss Service 계정}:{JBoss Service 그룹} ${ROTATED_FILE}
rotate된 로그 파일의 소유권을 Jboss 서비스 계정 및 그룹에게 넘겨, 추후 JBoss start,stop 시 에러가 생기지 않도록 한다.
find "/JVM_PATH/${JVM_NAME}/log/nohup/" -mtime +90 -name '*.out.*' | xargs rm
nohup log가 쌓이는 경로에서 파일명에 .out이 들어가는 모든 파일들 중 파일 수정 timestamp가 90일 이상이 된 파일들을 삭제하도록 하는 명령어이다.

(번외) 로그 파일들을 gzip 으로 압축하는 방법

아래 쉘 스크립트를 추가하면, 현재 쓰여지고 있는 로그를 제외한 nohup log, gclog, server.log (Jboss log) 의 모든 로그들을 gzip으로 압축시킬 수 있다.

find "로그파일의 상위 디렉토리" ! -name '*.gz' \( -name '*.out.*' -o -name '*.hprof' -o -name 'gc*.log' -o -name '*.log.*' \) -exec gzip {} \;

2. 쉘 스크립트를 주기적으로 실행하도록 설정 - crond 이용

2.1. 현재 등록된 cron job 확인

crontab -l

위 명령어를 수행하여, 현재 crond 로 어떤 job들이 수행되고 있는 지 확인해보자!

2.2. crontab에 'log_management.sh' 를 실행하도록 설정

# cron job 을 특정 주기로 등록하는 editor를 연다.
crontab -e

# 아래 내용을 넣고 저장
# minute hour day_of_month month weekday command
# 아래 문구는 매일 23시 59분으로 설정하여, 매일 nohup log가 rotation 및 삭제되도록 설정하는 것이다.
# 쉘 스크립트를 실행할 때, 마지막에 JVM Name에 해당하는 argument를 넣는 것을 잊지 말자!
59 23 * * * /PATH/log_management.sh JVM_NAME

위와 같이 crontab 내용을 설정하면 되는데, 해당 쉘 스크립트가 잘 동작하는 지 23시 59분까지 기다릴 수 없다면,

아래 방법으로 지금부터 매 분마다 수행되도록 하여 테스트 해보도록 하자!

# 테스트용 crontab 내용
* * * * * /PATH/log_management.sh JVM_NAME

2.3. cron 데몬 재시작 (생략 가능)

crontab -e 명령어로 crontab 에디터를 연 후, 알맞게 설정하여 저장하였다면,

해당 서버 내의 cron 데몬이 특이하게(?) 설정되어 있지 않다면, 특정 시간마다 crontab 내용을 읽어들여 자동으로 스케줄링을 하게 된다.

만약 적용되었는 지 확실치 않아 찝찝하다면, 아래 명령어를 수행하여 cron 데몬을 재시작 하도록 하자.

# cron 데몬 재시작
systemctl restart crond.service

# cron 데몬 서비스 상태 확인
systemctl status crond.service

위 과정을 모두 마쳤다면, 다음날에 반드시 nohup log의 rotation 과 삭제가 제대로 수행되었는 지 확인해보도록 하자!

참고

https://green-joo.tistory.com/26

nohup 사용법과 nohup.out 파일 명 변경, 로그 없이, 날짜 별로 rotation 하는 방법 ( Linux )

안녕하세요. 그린주입니다 ๑'ٮ'๑ 오늘도 힘차게 시작해보겠습니다! 개요 이번 글에서는 nohup 사용법과 nohup.out 로그 관련 설정, 프로세스를 종료하는 방법을 공유하고자 합니다. 목차 nohup 설명

green-joo.tistory.com

[httpd] https://{IP} 로 URL을 입력받았을 때, https://{domain name}으로 리다이렉션 시키는 방법

코_노 — Thu, 11 Apr 2024 16:45:24 +0900

사내에 여러 보안 사항을 DEV 및 QA 서버에서 테스트 하기 위해,

기존 SSL이 적용되지 않은 DEV 및 QA 서버에 SSL을 적용하였는데,

https://{IP} 로 입력하여 해당 서비스에 접근할 경우, 다음과 같이 SSL이 적용되지 않는 문제를 발견하였다.

http://{IP} -> https://{domain name} 으로 리다이렉션하는 설정은 쉽게 넣었는데,

https://{IP} -> https://{domain name} 은 찾는게 쉽지 않았다...

참고로, http://{IP} -> https://{domain name} 이 방법은, 다음과 같은 방법으로 진행하였다.

<VirtualHost *:80>
    RewriteEngine on
    # IP가 123.123.123.123 이라고 가정
    RewriteCond %{HTTP_HOST} ^123\.123\.123\.123$
    RewriteRule (.*) https://service.mydomain.co.kr%{REQUEST_URI}
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "${Document_Root_Path}"
    ServerName service.mydomain.co.kr
    ErrorLog "|${HTTPD_HOME}/bin/rotatelogs ${HTTPD_HOME}/logs/site-error_log.%Y%m%d 86400 +540"
    CustomLog "|${HTTPD_HOME}/bin/rotatelogs ${HTTPD_HOME}/logs/site-access_log.%Y%m%d 86400 +540" combined

    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://service.mydomain.co.kr%{REQUEST_URI} [L,R=301]

</VirtualHost>

물론 사이트를 단순히 접속하는 목적이라면, [고급] 탭을 눌러 안전하지 않은 연결을 통해 접속이 가능하지만,

사이트 관리자의 입장에서는 이런식으로 SSL을 우회할 가능성이 있기 때문에, https://{IP} 로 보내는 요청도 모두 DNS 서버에 등록된 domain name으로, 즉, https://{domain name} 으로 리다이렉션 시키고 싶어졌다.

나와 같은 고민을 한 해외 서버 관리자들이 꽤 있는 것 같은데, 아래 방법이 나의 케이스와 가장 잘 맞아 참고하였다.

https://serverfault.com/questions/993925/redirect-ip-address-to-domain-name-on-apache

Redirect IP address to domain name on apache

I am pretty computer savvy, but not with setting up web servers. I have a domain name that has an SSL certificate, so that https://example.org works and http://example.org redirects there. BUT, h...

serverfault.com

필자의 경우, https://{IP}의 리다이렉션 설정 전, 443 포트에 대한 VirtualHost 설정은 다음과 같았다.

<VirtualHost *:443>
    DocumentRoot ${SITE_DOCUMENT_ROOT_PATH}
    ServerName service.mydomain.co.kr
    
    SSLEngine On
    
    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite HIGH:MEDIUM:!SSLv2:!PSK:!SRP:!ADH:!AECDH:!3DES:!RC4

    SSLCertificateFile ${Certificate_Path}
    SSLCertificateKeyFile ${Certificate_Keyfile_Path}

    ErrorLog "|${HTTPD_HOME}/bin/rotatelogs ${HTTPD_HOME}/logs/site-error_log.%Y%m%d 86400 +540"
    CustomLog "|${HTTPD_HOME}/bin/rotatelogs ${HTTPD_HOME}/logs/site-access_log.%Y%m%d 86400 +540" combined

    
    # WebLogic과 연동하기 위한 설정
    <IfModule mod_weblogic.c>
     WebLogicCluster {Server IP}:{Service Port}
     ConnectRetrySecs 2
     ConnectTimeoutSecs 10
     FileCaching OFF
     WLIOTimeoutSecs 18000
     DynamicServerList OFF
     Idempotent OFF
     MatchExpression *
    </IfModule>
    
</VirtualHost>

위 VirtualHost 설정을 아래와 같이, Rewrite 설정을 추가하였다.

여기서 주의할 점은, SSL 설정 이전에 Rewrite 관련 설정을 넣고, Rewrite의 조건을 원하는 domain name이 아닌 모든 요청일 경우, 원하는 domain name으로 무조건 리다이렉션 하도록 설정하는 것이다.

이러면, 원하는 domain name으로 들어온 요청은 조건에 해당하지 않으므로, 자연스레 SSL 설정으로 넘어가게 된다.

<VirtualHost *:443>
    DocumentRoot ${SITE_DOCUMENT_ROOT_PATH}
    ServerName service.mydomain.co.kr
    
    RewriteEngine On
    RewriteCond %{HTTP_HOST} !^service\.mydomain\.co\.kr$
    RewriteRule ^(.*)$ https://service.mydomain.co.kr$1 [R=permanent,L]
    
    SSLEngine On
    
    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite HIGH:MEDIUM:!SSLv2:!PSK:!SRP:!ADH:!AECDH:!3DES:!RC4

    SSLCertificateFile ${Certificate_Path}
    SSLCertificateKeyFile ${Certificate_Keyfile_Path}

    ErrorLog "|${HTTPD_HOME}/bin/rotatelogs ${HTTPD_HOME}/logs/site-error_log.%Y%m%d 86400 +540"
    CustomLog "|${HTTPD_HOME}/bin/rotatelogs ${HTTPD_HOME}/logs/site-access_log.%Y%m%d 86400 +540" combined

    
    # WebLogic과 연동하기 위한 설정
    <IfModule mod_weblogic.c>
     WebLogicCluster {Server IP}:{Service Port}
     ConnectRetrySecs 2
     ConnectTimeoutSecs 10
     FileCaching OFF
     WLIOTimeoutSecs 18000
     DynamicServerList OFF
     Idempotent OFF
     MatchExpression *
    </IfModule>
    
</VirtualHost>

이게 정석적인 방법인지는 모르겠으나, 부디 나와 같은 삽질을 다른 사람들은 많이 하지 않도록,

https://{IP} -> https://{domain name} 방법을 이렇게 포스팅으로 공유해본다..!

[MSSQL] SQL Server 점검 시 유용한 쿼리 모음

코_노 — Mon, 8 Apr 2024 09:13:42 +0900

DBA라고 하기 부끄러운 수준이지만, 그래도 다른 사람보다 DB를 조금 더 자주 접하면서 MSSQL에서 가지고 있으면 유용한 쿼리를 아래에 정리해 본다. 모두 sysadmin의 Server-level role을 가지고 수행하였다.

참고로, 아래 모든 쿼리들이 서버에 부하를 얼마나 유발하는 지 확인해 보지 않았고, 매우 심각한 상황(쿼리 하나가 서버를 죽이든,살리든 하는 상황)에서는 한 번도 사용해보지 않았으므로, 반드시 유의해서 사용해야 한다...!

부하를 최소화한다든지, 새로운 쿼리를 알아내게 되면 이 포스팅에 계속 업데이트할 예정이므로, 이 포스팅 내용은 계속 변할 수 있다!

1. 현재 MSSQL의 상태 조회 쿼리

MSSQL 인스턴스 내 활성화되어 있는 모든 세션 정보 확인 - sys.dm_exec_sessions

sys.dm_exec_sessions 는 SQL Server 인스턴스에서 인증된 세션당 한 행을 반환하도록 하는 DMO(Dynamic Management Objects)이다. 즉 이 DMO를 통해 반환된 행은, SQL Server 인스턴스 내에서 활성화된 모든 세션에 대한 논리적인 정보를 담고 있으며, 이는 사용자 세션뿐 아니라, SQL Server 자체의 내부 작업, 백그라운드 프로세스 ,시스템 세션 등이 포함될 수 있음을 의미한다.

SELECT *
FROM sys.dm_exec_sessions
-- WHERE login_name = 'SQL Login Name' -- 현재 SQL Server에 활성화되어 있는 SQL Login name 기준으로 보고 싶을 때

MSSQL 인스턴스에 connect 되어 있는 connection 정보 확인 - sys.dm_exec_sessions, sys.dm_exec_connections

sys.dm_exec_connections 는 SQL Server 인스턴스에 establish된 각 connection에 대한 세부 사항을 반환하도록 하는 DMO로, 여기에는 네트워크 프로토콜, Client IP Address, 연결 시간 등의 정보가 포함된다. SQL Server 에 연결된 하나의 세션은 여러 개의 connection을 가질 수 있는 구조이다.

SELECT s.login_time
	, s.host_name
	, c.client_net_address
	, s.session_id
	, s.program_name
	, [DB Name] = db_name(st.dbid)
	, s.login_name
	, s.status
	, [CPU Time used by session (ms)] = s.cpu_time
	, [# of Pages In MEM] = s.memory_usage
	, [Total Scheduled Time (ms)] = s.total_scheduled_time
	, [Since Session established Time (ms)] = s.total_elapsed_time
	, s.last_request_start_time
	, s.last_request_end_time
	, [Physical Reads from Disk (Pages)] = s.reads
	, [Logical Reads from MEM (Pages)] = s.logical_reads
	, s.is_user_process
	, s.transaction_isolation_level
	, [해당 세션에서 현재까지 return된 행 수] = s.row_count
	, [가장 최근 수행한 sql문] = st.text
FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_connections c 
	ON s.session_id = c.session_id
CROSS APPLY sys.dm_exec_sql_text(c.most_recent_sql_handle) st
ORDER BY s.cpu_time DESC, s.reads DESC

각 DB별 연결되어 있는 Connection 개수 및 Login 계정 확인

SELECT 
    DB_NAME(dbid) as DBName, 
    COUNT(dbid) as NumberOfConnections,
    loginame as LoginName
FROM
    sys.sysprocesses
WHERE 
    dbid > 0
GROUP BY 
    dbid, loginame
;

SQL Server 인스턴스 내에서 현재 수행되고 있는 쿼리 확인

SELECT DISTINCT
    req.session_id,
    req.request_id,  -- (req.session_id, req.request_id) 값이 dm_exec_requests 에서 key 값으로 보고, 병렬 쿼리깢 있을 수 있는 상황 고려하여 request_id 까지 조회
    sqltext.TEXT AS executing_sql,
    req.command,
	req.status,
    req.wait_type,
    req.cpu_time,
    req.total_elapsed_time,
    sess.login_name,
    conn.client_net_address AS client_ip,
    sess.host_name,
    sess.program_name
FROM sys.dm_exec_requests req
INNER JOIN sys.dm_exec_sessions sess ON req.session_id = sess.session_id
INNER JOIN sys.dm_exec_connections conn ON req.session_id = conn.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) AS sqltext
WHERE sqltext.TEXT NOT LIKE '%sp_server_diagnostics%'
ORDER BY req.session_id, req.request_id;

Running 상태가 아닌, 문제가 있거나 Blocking 걸려 있는 트랜잭션 조회

SELECT req.session_id
	, ses.host_name
	, ses.login_name
	, req.status
	, req.blocking_session_id	-- 이 값이 0이면 다음 중 하나. 1. root blocker / 2. block 되고 있지는 않은 상태
	, req.wait_type
	, SUBSTRING(sql_text.text,req.statement_start_offset/2, 
		(CASE 
			WHEN req.statement_end_offset = -1
			THEN LEN(CONVERT(NVARCHAR(max), sql_text.text)) * 2
			ELSE req.statement_end_offset 
			END - req.statement_start_offset)/2
	) AS [Query_Text] --- statement of batch or proc executing right now
	, DB_NAME(ses.database_id) AS [Current Used DB] -- <<----- 이 부분을 수정했습니다!
	, CAST(DATEDIFF(ss, req.start_time, GETDATE()) AS NVARCHAR)+ N'초' AS [Request 경과시간]
	, object_name(sql_text.objectid) AS [SP명]	-- ad-hoc 또는 prepared SQL statement 라면, Null 로 나옴
	, req.cpu_time AS [CPU_Time (ms단위)]
	, req.total_elapsed_time
	, req.reads
	, req.writes 
	, req.logical_reads 
	, req.scheduler_id
FROM sys.dm_exec_requests AS req WITH (NOLOCK)
INNER JOIN sys.dm_exec_sessions AS ses WITH (NOLOCK) ON req.session_id = ses.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) AS sql_text
WHERE req.session_id > 50 
	AND sql_text.text NOT LIKE '%sp_server_diagnostics%'
ORDER BY req.blocking_session_id, req.session_id, req.status, req.cpu_time, req.logical_reads

'STATS' 키워드를 넣지 못한 Backup 또는 Restore 진행 시, 현재 진행상황 확인

SELECT ER.session_id
	, ER.command
	, ER.start_time
	, ER.percent_complete
	, ER.total_elapsed_time
	, ER.status
	, ER.last_wait_type
	, ER.estimated_completion_time /1000/60 AS [남은 시간(분)]	-- ms 단위로 저장되므로 분 단위 표시를 위해 (1000*60)으로 나눠주는 것임
	, EST.text
FROM sys.dm_exec_requests AS ER WITH(NOLOCK)
CROSS APPLY sys.dm_exec_sql_text(ER.sql_handle) AS EST
WHERE ER.command = 'BACKUP DATABASE' 
	OR ER.command = 'RESTORE DATABASE'
	OR ER.command = 'BACKUP LOG'
	AND ER.percent_complete > 0;

현재 tempdb의 사용량 확인 (Extent 기준으로 표시됨)

USE [tempdb];
DBCC showfilestats

현재 tempdb를 사용하고 있는 세션별 각 resource 사용량 확인하는 쿼리

SELECT
	es.session_id AS [SESSION ID]
  , DB_NAME(su.database_id) AS [DATABASE Name]
  , es.host_name AS [System Name]
  , es.program_name AS [Program Name]
  , est.text AS [Query_Text]
  , es.login_name AS [USER Name]
  , er.status
  , es.cpu_time AS [CPU TIME (in milisec)]
  , es.total_scheduled_time AS [Total Scheduled TIME (in milisec)]
  , es.total_elapsed_time AS    [Elapsed TIME (in milisec)]
  , (es.memory_usage * 8)      AS [Memory USAGE (in KB)]
  , (su.user_objects_alloc_page_count * 8) AS [SPACE Allocated FOR USER Objects (in KB)]
  , (su.user_objects_dealloc_page_count * 8) AS [SPACE Deallocated FOR USER Objects (in KB)]
  , (su.internal_objects_alloc_page_count * 8) AS [SPACE Allocated FOR Internal Objects (in KB)]
  , (su.internal_objects_dealloc_page_count * 8) AS [SPACE Deallocated FOR Internal Objects (in KB)]
  , CASE is_user_process
		WHEN 1	THEN 'user session'
		WHEN 0  THEN 'system session'
		END AS [SESSION Type]
  , er.row_count AS [ROW COUNT]
FROM 
	sys.dm_db_session_space_usage AS su
INNER JOIN sys.dm_exec_sessions AS es
	ON es.session_id = su.session_id
INNER JOIN sys.dm_exec_requests AS er
	ON er.session_id = es.session_id
CROSS APPLY sys.dm_exec_sql_text(er.sql_handle) AS est
ORDER BY [Total Scheduled TIME (in milisec)] DESC, [Elapsed TIME (in milisec)] DESC

최근 쿼리플랜에서 Hash Match, Sort, Spool 연산자로 인해 tempDB spill 가능성 높은 쿼리 찾기

SELECT TOP 100
	DB_NAME(qp.dbid) AS database_name
	, qs.total_worker_time / qs.execution_count AS avg_cpu_tme
	, qs.total_logical_reads / qs.execution_count AS avg_reads
	, qs.total_elapsed_time / qs.execution_count AS avg_elapsed_time
	, qs.execution_count
	, qs.creation_time
	, qs.last_execution_time
	, qs.last_rows
	, qs.last_grant_kb
	, qs.last_spills
	, st.text AS query_text
	, qp.query_plan
FROM 
	sys.dm_exec_query_stats qs
CROSS APPLY 
	sys.dm_exec_sql_text(qs.sql_handle) st
CROSS APPLY 
	sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qp.query_plan.exist('
		declare namespace p="http://schemas.microsoft.com/sqlserver/2004/07/showplan";
		//p:RelOp[p:Spool or p:Hash or p:Sort]
		') = 1
ORDER BY last_spills DESC;

SQL Server Instacne의 Uptime 확인 쿼리

USE master
go
SELECT sqlserver_start_time AS [SQL Server Instance Uptime] 
FROM sys.dm_os_sys_info

평균 Blocking 당한 시간이 긴 쿼리 Top100 조회

sys.dm_exec_query_stats: SQL Server에서 캐시된 쿼리 계획에 대한 집계 성능 통계를 반환하는 DMV

이 DMV에서 반환되는 Row의 유효 기간은 쿼리 플랜 자체와 연결되어 있다.
따라서, 해당 플랜이 캐시에서 제거되면, 이 DMV 결과로도 확인할 수 없다는 점을 유의하자.
이 DMV의 total_elapsed_time 은 해당 플랜의 쿼리 실행이 완료되기까지 소요된 총 경과 시간을 [μs](마이크로 초) 단위로 보여준다.

USE [DATABASE_NAME]
SELECT TOP(100)
	[Average Time Blocked (초)] = (total_elapsed_time - total_worker_time) / qs.execution_count / 1000000 -- 초 단위로 보여주기 위해 나눔
	, [Total Time Blocked (초)] = total_elapsed_time - total_worker_time / 1000000 -- 초 단위로 보여주기 위해 나눔
	, [Execution count] = qs.execution_count
	, [Individual Query] = SUBSTRING (qt.text,qs.statement_start_offset/2,
         (CASE WHEN qs.statement_end_offset = -1
            THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
			ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)
	, [Parent Query] = qt.text
	, [DatabaseName] = DB_NAME(qt.dbid)
  , [마지막 실행 시점] = qs.last_execution_time
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
ORDER BY [Average Time Blocked (초)] DESC, [Execution count] DESC;

2. 권한 관리 관련 쿼리 (주로 Audit 또는 보안 상태 점검 시 사용)

Public을 제외한 다른 서버 고정 역할을 가지고 있는 SQL Login의 Role, Default Database 조회

SELECT [Login Name] = B.name 
	, [Principal ID] = B.principal_id
	, [Role] = A.name
	, B.type_desc
	, B.default_database_name
FROM sys.server_role_members rm
INNER JOIN sys.server_principals A
	ON A.principal_id = rm.role_principal_id
INNER JOIN sys.server_principals  B 
	ON B.principal_id = rm.member_principal_id
WHERE B.name = '조회를 원하는 SQL Login Name'

고정 데이터베이스 역할 리스트 조회

SELECT DP1.name AS DatabaseRoleName,   
   isnull (DP2.name, 'No members') AS DatabaseUserName   
 FROM sys.database_role_members AS DRM  
 RIGHT OUTER JOIN sys.database_principals AS DP1  
   ON DRM.role_principal_id = DP1.principal_id  
 LEFT OUTER JOIN sys.database_principals AS DP2  
   ON DRM.member_principal_id = DP2.principal_id  
WHERE DP1.type = 'R'
ORDER BY DP1.name;

특정 유저의 user mapping DB 및 해당 DB에서의 Database-level roles 확인

DECLARE @command nvarchar(4000) 
DECLARE @DBRole TABLE (DBName sysname, UserName sysname, RoleName varchar(255))
SELECT @command = '
USE [?]
SELECT ''?'' AS DB_Name
	, (CASE prin.name
		WHEN ''dbo'' THEN (
			SELECT SUSER_SNAME(owner_sid)
			FROM master.sys.databases
			WHERE name = ''?'')
			ELSE prin.name
			END
		) AS UserName
	, ISNULL(USER_NAME(mem.role_principal_id), '''')  AS AssociatedRole
FROM sys.database_principals prin
LEFT OUTER JOIN sys.database_role_members mem
	ON prin.principal_id = mem.member_principal_id
'

INSERT INTO @DBRole
EXEC sp_MSforeachdb @command 

SELECT * FROM @DBRole t 
WHERE t.UserName LIKE '%특정 유저 네임%'

위 쿼리를 수행하면 아래와 같은 결과를 얻을 수 있다.

특정 DB 내에서 특정 사용자가 어떠한 오브젝트들에 대해 어떤 권한들을 가지고 있는 지 확인

USE [Database Name]; -- DB Name

SELECT 
    dp.name AS UserName,
    s.name AS SchemaName,
    o.name AS ObjectName,
    p.permission_name AS PermissionType,
    p.state_desc AS PermissionState
FROM 
    sys.database_permissions p
JOIN 
    sys.objects o ON p.major_id = o.object_id
JOIN 
    sys.schemas s ON o.schema_id = s.schema_id
JOIN 
    sys.database_principals dp ON p.grantee_principal_id = dp.principal_id
WHERE 
    dp.name = 'User Name' -- 특정 사용자명
ORDER BY 
    s.name, o.name, p.permission_name;

특정 유저가 해당 오브젝트에 대해서 어떤 권한을 가지고 있는 지 확인

fn_my_permissions의 경우, 임시 테이블을 Insert, Delete 하는 과정이 수반되므로, Audit Scope에 해당하는 DB에 대해서 사용하는 것에는 각별한 주의가 필요하다.

EXECUTE AS LOGIN = 'LOGIN USER NAME';

SELECT * 
FROM fn_my_permissions('[DATABASE NAME].[SCHEMA NAME].[TABLE | VIEW NAME]', 'OBJECT')
ORDER BY subentity_name, permission_name;

REVERT;

유저가 생성한 Stored Procedure에 대한 권한에 대해 특정 유저가 어떠한 권한을 가지고 있는 지 확인

SELECT
	[SQL Login Name] = USER_NAME(dp.grantee_principal_id)
	, [Permission_State] = dp.state_desc
	, [Permission_Name] = dp.permission_name
	, [Schema_Name] = s.name
	, [Object_Name] = o.name
FROM 
    sys.database_permissions dp
JOIN sys.objects o 
	ON dp.major_id = o.object_id
JOIN sys.schemas s 
	ON o.schema_id = s.schema_id
WHERE 
    dp.grantee_principal_id = USER_ID('%USER_NAME%')
    AND o.type = 'P' -- 'P'는 저장 프로시저를 의미
ORDER BY [Object_Name]

위 쿼리 수행 결과 예시

3. Size 또는 Index 관련 쿼리

현재 MSSQL 인스턴스 내 모든 DB의 용량 확인

USE master
GO
 
SELECT sys.databases.name
	, [Disk Usage (MB)] = CONVERT(VARCHAR,SUM(CAST(mf.size AS bigint))*8/1024) +' MB'
	, [Disk Usage (GB)] = CONVERT(VARCHAR,SUM(CAST(mf.size AS bigint))*8/1024/1024) +' GB'
FROM sys.databases
JOIN sys.master_files AS mf
	ON sys.databases.database_id = mf.database_id
WHERE sys.databases.name != 'tempdb'	-- sys.master_files 뷰에서의 tempdb 의 사이즈는 initial size를 의미한다. 그러므로 현재 tempdb 사이즈가 아니기 때문에 제외하였다.
GROUP BY sys.databases.name
ORDER BY SUM(CAST(mf.size AS bigint))*8/1024 DESC		-- DB 총 사이즈별로 내림차순 정렬

해당 DB의 mdf, ldf 전체 사이즈 및 실제 남은 공간 확인

USE [DB_NAME]
SELECT [DB NAME] = DB_NAME() 
	, [Logical File Name] = name
	, type_desc
	, [Physical File Path] = physical_name
	, [Current File Size (MB)] = size / 128.0
	, [Used Space (MB)] = CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0
	, [Free Space (MB)] = size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0
	, [사용률] = (CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT) / 128.0) / (size / 128.0) * 100.00
FROM sys.database_files
WHERE type IN (0,1);

-- Log space만 확인하고 싶을때
DBCC SQLPERF(LOGSPACE)

해당 DB의 테이블별 사이즈 확인

USE [DB_NAME];

WITH PartitionStats AS (
    SELECT 
        ps.object_id,
        SUM(CASE WHEN (ps.index_id < 2) THEN row_count ELSE 0 END) AS [rows],
        SUM(ps.reserved_page_count) AS [reserved],
        SUM(CASE 
                WHEN (ps.index_id < 2) THEN (ps.in_row_data_page_count + ps.lob_used_page_count + ps.row_overflow_used_page_count)
                ELSE (ps.lob_used_page_count + ps.row_overflow_used_page_count)
            END) AS [data],
        SUM(ps.used_page_count) AS [used]
    FROM sys.dm_db_partition_stats ps
    GROUP BY ps.object_id
),
InternalTableStats AS (
    SELECT 
        it.parent_id,
        SUM(ps.reserved_page_count) AS [reserved],
        SUM(ps.used_page_count) AS [used]
    FROM sys.dm_db_partition_stats ps
    INNER JOIN sys.internal_tables it ON (it.object_id = ps.object_id)
    WHERE it.internal_type IN (202, 204)
    GROUP BY it.parent_id
)
SELECT
    [Schema Name] = OBJECT_SCHEMA_NAME(a2.object_id),
    [Table Name] = a2.name,
    [Rows] = FORMAT(a1.rows, '#,#'),
    [Reserved Size (MB)] = FORMAT(CAST(ROUND(((a1.reserved + ISNULL(a4.reserved, 0)) * 8) / 1024.00, 2) AS NUMERIC(36,2)), '#,#'),
    [Data Size (MB)] = FORMAT(CAST(ROUND(a1.data * 8 / 1024.00, 2) AS NUMERIC(36, 2)), '#,#'),
    [Index Size (MB)] = FORMAT(CAST(ROUND((CASE WHEN (a1.used + ISNULL(a4.used, 0)) > a1.data 
        THEN (a1.used + ISNULL(a4.used, 0)) - a1.data ELSE 0 END) * 8 / 1024.00, 2) AS NUMERIC(36, 2)), '#,#'),
    [Unused Size (MB)] = FORMAT(CAST(ROUND((CASE WHEN (a1.reserved + ISNULL(a4.reserved, 0)) > a1.used 
        THEN (a1.reserved + ISNULL(a4.reserved, 0)) - a1.used ELSE 0 END) * 8 / 1024.00, 2) AS NUMERIC(36, 2)), '#,#')
FROM PartitionStats a1
LEFT OUTER JOIN InternalTableStats a4 
	ON a4.parent_id = a1.object_id
INNER JOIN sys.all_objects a2 
	ON a1.object_id = a2.object_id
WHERE a2.type <> N'S' AND a2.type <> N'IT' 
	--	AND a2.name = N'TABLE NAME'  -- 원하는 테이블 있으면 해당 조건 넣기
ORDER BY CAST(ROUND(((a1.reserved + ISNULL(a4.reserved, 0)) * 8) / 1024.00, 2) AS NUMERIC(36,2)) DESC;
	-- FORMAT 함수 사용한 컬럼 기준으로 정렬 시, 숫자 기준으로 정렬하기 위해 계산식 그대로 사용

특정 테이블 내의 인덱스의 사용 빈도 확인

SELECT a.object_id
	, [Table Name] = object_name(a.object_id)
	, a.index_id
	, [Index Name] = b.name
	, a.user_seeks									-- 사용자 쿼리별 Seek 연산 횟수
	, a.last_user_seek								-- 사용자 쿼리에 따른 마지막 Seek 연산 수행 시간
	, a.user_scans									-- 사용자 쿼리별 Scan 연산 횟수
	, a.last_user_scan								-- 사용자 쿼리에 따른 마지막 Scan 연산 수행 시간
FROM sys.dm_db_index_usage_stats AS a
INNER JOIN sys.indexes AS b
	ON a.object_id = b.object_id
	AND a.index_id = b.index_id
WHERE a.database_id = DB_ID(N'DATABASE_NAME')
	AND OBJECT_NAME(a.object_id) = N'TABLE_NAME'  -- 스키마명 제외한 순수 테이블명만 넣을 것.

특정 테이블 내 인덱스들의 조각화 정도 확인

SELECT a.object_id
	, [Table Name] = object_name(a.object_id)
	, a.index_id
	, [Index Name] = b.name
	, avg_page_space_used_in_percent
	, avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(
	DB_ID (N'DB_NAME')
	, OBJECT_ID(N'TABLE_NAME')     -- 스키마 네임은 빼고 순수 테이블명만 넣기
	, NULL
	, NULL
	, 'SAMPLED'
	) AS a
INNER JOIN sys.indexes AS b
	ON a.object_id = b.object_id
	AND a.index_id = b.index_id

Compression Backup 시에, 압축 비율 및 현재 백업 파일 사이즈 확인

SELECT name 
	, backup_start_date
	, [compressed_backup_size (MB)] = CONVERT(DECIMAL(10, 2), compressed_backup_size / 1024. / 1024.)
	, [compression ratio] = compressed_backup_size/backup_size * 100
FROM msdb..backupset
WHERE backup_start_date >= '2023-12-11'  -- 확인이 필요한 특정 날짜를 조건절에 꼭 넣어서 쿼리할 것.
ORDER BY backup_start_date DESC

4. 기타 등등?

프로시저 조회

USE [데이터베이스명]

-- 전체 프로시저 오브젝트 조회
SELECT *
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='PROCEDURE'

-- 프로시저 이름, 프로시저 내용만 조회
SELECT [ProcedureName] = ROUTINE_NAME
	, [ProcedureContents] = ROUTINE_DEFINITION
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='PROCEDURE'

참고

https://99lib.tistory.com/541

문제상황시 유용한 sql쿼리들

--get the connections select st.text, c.connect_time, c.net_transport, c.auth_scheme, c.num_reads, c.num_writes, c.last_read, c.last_write, c.connection_id, c.parent_connection_id, st.dbid, st.objectid from sys.dm_exec_connections c cross apply sys.dm_exec

99lib.tistory.com

https://sharedstoryit.tistory.com/entry/MSSQL-%EC%BF%BC%EB%A6%AC-%ED%8A%9C%EB%8B%9D%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%BF%BC%EB%A6%AC-%EB%B0%8F-%EC%8B%9C%EC%8A%A4%ED%85%9C-%ED%85%8C%EC%9D%B4%EB%B8%94

[MSSQL] 쿼리 튜닝을 위한 쿼리 및 시스템 테이블

데이터베이스별 누락된 인덱스SQL Server가 쿼리를 처리할 때 최적화 프로그램은 쿼리를 수행하기 위해 사용하려고 시도한 인덱스에 대한 기록을 보관합니다. 이러한 인덱스가 없는 경우 SQL Server

sharedstoryit.tistory.com

[httpd] RedHat JBCS httpd 에서 Apache httpd로 이전하기 (1)

코_노 — Sun, 7 Apr 2024 21:52:59 +0900

사내 취약성 기준이 httpd 버전을 2.4.58 이상으로 반드시 쓰라는 얘기가 나와서,

기존에 설치되어 있던 RedHat JBCS httpd 에서 Apache httpd 로 이전해보고자 한다.

RedHat JBCS httpd도 분명 꾸준히 업데이트가 되고 있지만,

단순 버전 차이에서 오는 문제라든지, OpenSSL의 종속성 문제라든지, 대부분의 구글링 문서들이 Apache httpd 문서 기준이라든지(RedHat JBCS httpd와 Apache httpd의 디렉토리 구조가 다르다.), 앞으로도 계속 이런 자잘자잘한 문제들이 나를 괴롭힐 수 있을 것 같다는 생각에,

Apache httpd 를 컴파일 설치하여, RedHat JBCS httpd를 걷어내보고자(?) 한다!

참고로, 필자의 경우, RHEL 7,8,9 에서 OpenSSL 1.0.2k, 1.1.1k, 3.2.1 버전 모두 Apache httpd 컴파일 설치를 진행해본 결과, 몇몇 에러들만 잡으면, 구동 및 운영에는 문제가 없는 것으로 보였다.

따라서, RHEL 7 이상, OpenSSL은 3.2.1. 버전 이상 기준으로 설명한다.

아래 명령어는 모두 root와 동등한 권한으로 수행하고, 추후에 'apache' 계정으로 권한 및 소유권을 조정할 것이다.

1. openssl 1.1.1 컴파일 설치

1.1. openssl 컴파일 설치 진행되는 디렉토리 생성

mkdir /opt/openssl_compile
cd /opt/openssl_compile

1.2. openssl 공식 홈페이지에서 tar.gz 파일 받기

이 글 작성일 기준(2024.04.05.)으로 openssl3 버전의 latest stable version은 ‘3.2.1’ 이다.

openssl 다운로드는 아래 사이트를 참조한다.

https://www.openssl.org/source/

[ Downloads ] - /source/index.html

Downloads The master sources are maintained in our git repository, which is accessible over the network and cloned on GitHub, at https://github.com/openssl/openssl. Bugs and pull patches (issues and pull requests) should be filed on the GitHub repo. Please

www.openssl.org

wget https://www.openssl.org/source/openssl-3.2.1.tar.gz
tar xvf openssl-3.2.1.tar.gz

1.3. 소스 컴파일 전, Makefile(환경설정 파일) 생성

cd openssl-3.2.1

# 서버에 기존 사용하는 openssl이 있을 수 있으니, 
# 컴파일 설치하는 openssl3는 다음과 같이 설정하여, 기존 설치된 openssl과 구분하도록 하자!
./config --prefix=/usr/local/openssl3 --openssldir=/usr/local/openssl3 shared

--prefix : 설치할 위치 지정

--openssldir : openssl 실행 시, 참조할 기본 디렉토리 지정

아래와 같은 문구가 나타났다면, openssl config가 정상적으로 수행된 것이다.

Cant' locate IPC/Cmd.pm in @INC (you may need to install the IPC::Cmd module) 에러

IPC-Cmd 가 없는 문제이므로, yum으로 해당 패키지를 설치한다.

yum install perl-IPC-Cmd perl-Pod-Html

# 기존 configure 및 캐시 삭제
make distclean

# make 파일 재설정
./config --prefix=/usr/local/openssl3 --openssldir=/usr/local/openssl3 shared

No C compiler found, please specify one with the environment variable CC 에러

C 및 C++ 에 대한 컴파일러가 없어서 나타나는 문제이므로, 아래와 같이 컴파일 설치에 필요한 패키지를 설치한다.

yum install gcc gcc-c++

# 기존 configure 및 캐시 삭제
make distclean

# make 파일 재설정
./config --prefix=/usr/local/openssl3 --openssldir=/usr/local/openssl3 shared

1.4. Makefile 을 이용한 파일 컴파일 설치

make && make install

모두 컴파일 하는 데에 시간이 꽤나 걸린다. 차분히 기다리자!

아래와 같은 ‘Leaving directory’ 문구가 나타나면, 컴파일이 끝난 것이다!

1.5. 공유 라이브러리 등록

openssl 설치 시, 동적 라이브러리를 이용하도록 설정(shared 옵션)했기 때문에, 동적 라이브러리 로딩 정보에 새로 설치한 openssl과 관련된 라이브러리 디렉토리를 추가해야 한다.

1.5.1. Linux 공유 라이브러리 conf 파일 설정

vim /etc/ld.so.conf.d/openssl3.conf 
# 여기서 파일명을 'openssl3.conf'로 지정했지만, 임의로 지정 가능

# openssl3.conf 에 아래 문구 넣기
/usr/local/openssl3/lib64

1.5.2. 공유 라이브러리 캐시를 재설정 및 확인

ldconfig -v | grep -E "libssl.so|libcrypto.so"

ldconfig -v 명령어를 사용하면, 현재 모든 shared library cache 목록이 나타나게 되는데, 이러면 openssl3와 관련된 shared library는 확인이 어려우므로, grep -E "libssl.so|libcrypto.so" 명령어를 사용하였다.

1.6. /usr/lib64 디렉토리에도 라이브러리의 링크 추가

아래 명령어를 통해, 동적 라이브러리를 처음 찾는 디렉토리인 /usr/lib64에도 해당 라이브러리가 존재하는 지 확인해보자.

ls -al /usr/lib64 | grep -E "libssl|libcrypto"

그러면 필자의 경우, 위와 같이 openssl3 설치와 함께 생긴 library는 아직 /usr/lib64에는 없는 것으로 보인다.

이럴 경우, 아래 과정을 거쳐 심볼릭 링크로 등록해주어야 한다.

1.6.1. /usr/lib64 디렉토리에 새로 설치한 openssl3 의 동적 라이브러리 심볼릭 링크 추가

ln -s /usr/local/openssl3/lib64/libssl.so /usr/lib64/libssl.so.3
ln -s /usr/local/openssl3/lib64/libcrypto.so /usr/lib64/libcrypto.so.3

# 위 명령어 수행 후, 동적 라이브러리 디렉토리 다시 확인
ls -al /usr/lib64 | grep -E "libssl|libcrypto"

2. 기존 'openssl' 명령어가 실행되는 경로를 새로 설치한 openssl3 경로로 변경

2.1. 현재 시스템의 'openssl' 명령어 실행 경로 확인

which oepnssl
openssl version

기존 openssl은 openssl 1.1.1k 버전으로 설정되어 있으므로, 이 경로를 openssl3 로 변경해 줄 것이다.

2.2. 기존 명령어의 이름을 변경

mv /usr/bin/openssl /usr/bin/openssl_1.1.1k

2.3. 새로 설치한 openssl3 버전의 명령어를 '/usr/bin/openssl' 로 만들기

cp /usr/local/openssl3/bin/openssl /usr/bin/openssl

2.4. 'openssl' 명령어가 openssl3로 제대로 업데이트 되었는 지 확인

openssl version

위와 같은 명령어 수행 결과가 나온다면, 새로 설치한 OpenSSL3의 동적 라이브러리를 불러와서 잘 동작하는 것이다.

3. Apache httpd 2.4.59 수동 설치

3.1. httpd 수동(컴파일) 설치 위한 사전 준비

# Apache httpd 컴파일 설치 시 필요한 유틸리티 설치
yum install gcc-c++ expat-devel

# Apache httpd 컴파일 설치에 필요한 라이브러리들을 설치할 디렉토리 생성
mkdir /opt/apache_compile
cd /opt/apache_compile

3.2. apr, apr-util, pcre 라이브러리 설치

httpd 를 수동으로 빌드하기 위해서는 apr, apr-util, pcre 라이브러리가 필수적으로 필요한데, httpd 설치파일에 포함되어 있지 않다.

따라서, 해당 라이브러리들의 설치가 필요하다.

아래 경로를 참고해서 apr과 apr-util 을 설치하자.

https://apr.apache.org/download.cgi

Download - The Apache Portable Runtime Project

The currently selected mirror is https://dlcdn.apache.org/. If you encounter a problem with this mirror, please select another mirror. If all mirrors are failing, there are backup mirrors (at the end of the mirrors list) that should be available. You may a

apr.apache.org

3.2.1. apr 라이브러리 설치

아래 명령어로 apache_compile 디렉토리를 새로 생성하여, 해당 디렉토리에 apr을 설치하자!

# apr 라이브러리 tarball 다운로드
wget https://dlcdn.apache.org//apr/apr-1.7.4.tar.gz
tar xvf ./apr-1.7.4.tar.gz

# apr 라이브러리 설치 디렉토리로 이동
cd ./apr-1.7.4

# apr 설치 위한 make 파일 설정
./configure --prefix=/usr/local/apr

rm: cannot remove 'libtoolT' : No such file or directory 에러

-> 현 디렉토리(/opt/apache_compile/apr-1.7.4.tar.gz) 에서 아래 명령어 수행한다.

# 에러 해결 위함
cp -arp libtool libtoolT

# 기존 configure 설정 및 캐시 제거
make distclean

# apr 설치 위한 make 파일 재설정
./configure --prefix=/usr/local/apr

아래 명령어 통해 컴파일 설치

make && make install

이러한 문구가 나온다면 apr 설치가 잘 된 것이다!

3.2.2. apr-util 라이브러리 설치

cd /opt/apache_compile

# apr-util 라이브러리 tarball 다운로드
wget https://dlcdn.apache.org//apr/apr-util-1.6.3.tar.gz
tar xvf ./apr-util-1.6.3.tar.gz

# 압축 푼 apr-util 라이브러리 설치 디렉토리로 이동
cd ./apr-util-1.6.3

# make 파일 설정
./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr

# 컴파일 및 설치
make && make install

이러한 문구가 나온다면 apr-util 라이브러리가 잘 설치된 것이다!

3.2.3. pcre 라이브러리 설치

https://www.pcre.org/

PCRE - Perl Compatible Regular Expressions

PCRE - Perl Compatible Regular Expressions The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl 5. PCRE has its own native API, as well as a set of wrapper functions that cor

www.pcre.org

위 링크를 통해 pcre 라이브러리 tarball 다운로드 링크를 참고하자.

cd /opt/apache_compile

# pcre 라이브러리 tarball 다운로드
wget https://github.com/PCRE2Project/pcre2/releases/download/pcre2-10.43/pcre2-10.43.tar.gz
tar xvf ./pcre2-10.43.tar.gz

# 압축 푼 pcre 라이브러리 설치 디렉토리로 이동
cd ./pcre2-10.43

# make 파일 설정
./configure --prefix=/usr/local/pcre2

# 컴파일 및 설치
make && make install

3.3. httpd 2.4.59 설치 (2024.04.05 기준 latest version)

mpm module을 선택하기 위해, 기존에 사용하고 있던 RedHat JBCS httpd가 어떤 mpm module을 사용하고 있었는지,

다음 명령어를 통해 조회 가능하다.

cd ${RedHat JBCS HTTPD DIR}/bin
./httpd -V

이후 아래 링크를 참고하여 Apache httpd 소스 tarball을 다운로드하자!

https://httpd.apache.org/download.cgi#apache24

Download - The Apache HTTP Server Project

Downloading the Apache HTTP Server Use the links below to download the Apache HTTP Server from our download servers. You must verify the integrity of the downloaded files using signatures downloaded from our main distribution directory. The signatures can

httpd.apache.org

cd /opt/apache_compile

# Apache httpd 소스 tarball 다운로드
wget https://dlcdn.apache.org/httpd/httpd-2.4.59.tar.gz
tar xvf ./httpd-2.4.59.tar.gz

cd ./httpd-2.4.59

# httpd의 설치 경로를 /opt/httpd 로 한다고 가정하고, make 파일 설정 위한 다음 명령어 수행
# httpd가 사용하는 openssl의 경로는 /usr/local/openssl3
# --with-mpm : 2.4.x 버전 기준, default로 'Event' MPM Module로 설정되며, 다음과 같이 플래그를 주면, 해당 MPM Module을 사용하게끔 설치된다.
# MPM Module의 경우, Thread-Safety한 상황이라면, 'Event' MPM Module이 성능이 가장 좋다. 
./configure --prefix=/opt/httpd \
--with-ssl=/usr/local/openssl3 \
--enable-mods-shared=all \
--enable-modules=all \
--with-apr=/usr/local/apr/bin/apr-1-config \
--with-apr-util=/usr/local/apr-util/bin/apu-1-config \
--with-pcre=/usr/local/pcre2/bin/pcre2-config \
--with-mpm=prefork 

# 컴파일 및 설치
make && make install

다음 명령어를 통해 Apache httpd가 제대로 설치되었는 지 확인해보자!

cd /opt/httpd/bin

# httpd 버전 확인
./httpd -v

Apache httpd의 성공적인 설치!

3.4. Apache 기본적인 설정 및 구동 테스트

이제 Apache httpd 설치가 모두 완료되었으니, 다음 명령어를 입력하여, httpd가 제대로 실행되는 지를 확인해보자!

cd /opt/httpd/bin

# httpd 실행
./apachectl -k start

# httpd 프로세스 확인
ps -ef | grep httpd

위와 같이 httpd 프로세스가 떠 있는 것을 확인했다면, httpd://{httpd 가동한 서버 IP}:80/ 을 주소창에 입력하면 아래와 같은 문구가 나타날 것이다. 그럼 httpd가 정말 제대로 실행된 것이다!

httpd 실행 성공 브라우저 화면

이제 그럼 아래 포스팅을 통해, RedHat JBCS httpd 에서 Apache httpd로 변경할 때,

세부 configuration들을 어떻게 이전시키고 설정해야 할지에 대해 알아보자!

참고

[CentOS 7] Apache 2.4.48 웹서버 수동 설치 및 TLS 1.3 적용하기

TLS 1.3 을 지원하려면? openssl 1.1.1 수동설치 openssl 1.1.1 설치 공유 라이브러리 등록 openssl 관련 라이브러리 확인 및 추가 openssl 관련 라이브러리 확인 및 등록 httpd 2.4.51 수동설치 필수 패키지 사전

blog.jiniworld.me

Apache HTTPD versions supported by Red Hat - Red Hat Customer Portal

What version of httpd is supported on RHEL? Is the community version of Apache httpd supported? Which versions of Apache httpd are supported? How can I install Apache 2.5/2.6? Is Apache httpd 2.5/2.6 supported? Does Redhat support self compiled apache inst

access.redhat.com

[Ansible] playbook으로 ansible managed node들에 ssh 패스워드 없이 접속하도록 자동화하기

코_노 — Tue, 2 Apr 2024 23:28:53 +0900

Ansible Playbook 으로 ssh-copy-id 자동화하기

처음에는 뭣도 모르고, 80대가 넘는 managed node에 직접 ssh-copy-id 로 ssh public key를 전송하고, ssh 접속 테스트까지 했다… 근데 이것 또한 Ansible로 자동화가 가능하다! Ansible은 정말 미쳤다!

아래에서 설명할 playbook yml 파일에서 사용되는 hosts 파일의 내용은 다음과 같다.

아래처럼 hosts 파일에 그룹별로 나누어 IP를 작성하면, 아래 단계를 모두 적용시켜야 하는지, 부분 적용시켜야 하는 지를 hosts 파일 수정만으로 구분이 가능하게 되므로 참고하자!

[KNOWN_HOSTS]
10.123.123.11

[AUTHORIZED_KEYS]
10.123.123.12

[EXISTING_RSA_KEYS]
10.123.123.13

[PLAYBOOK_TEST]
10.123.123.14

[KNOWN_HOSTS] : 아래에서 설명할 'auto_add_known_hosts.yml' playbook 을 실행시킬 대상
-> Control Node 상에서 ~/.ssh/known_hosts 파일에 Managed Node(Remote Host) 정보들이 등록되지 않아 있는 상태이므로, 첫 번째 playbook 의 수행 대상이 되는 그룹이다.
[AUTHORIZED_KEYS] : 아래에서 설명할 'auto_authorized_keys.yml' playbook 을 실행시킬 대상
-> Control Node 상의 ~/.ssh/known_hosts 파일에는 기재가 되었고, 이후에 Managed Node의 ~/.ssh/authorized_keys 파일에 Control Node의 ssh public key 파일 내용을 기재해주어야 하므로, 이 작업 대상이 되는 그룹이다.
[EXISTING_RSA_KEYS] : 아래에서 설명할 'remove_rsa_authorized_keys.yml' playbook 을 실행시킬 대상
-> 이미 Control Node의 RSA 방식의 public key 값의 내용을 ~/.ssh/authorized_keys 파일에 가지고 있는 Managed Node들이 들어가는 그룹이다.
[PLAYBOOK_TEST] : 아래에서 설명할 'uptime_test.yml' playbook 을 실행시킬 대상
-> known_hosts, authorized_keys 파일 작업 수행 후에, 이 그룹에 있는 Managed Node 들에 대해 ssh 로 테스트 명령어를 수행하도록 하는 playbook 을 실행시킬 대상이다.

아래에 Ansible Playbook 으로 동작시킬 YAML 파일 코드를 첨부한다.

1. known_hosts 등록

: Control Node의 ~/.ssh/known_hosts 에 Managed-Node들을 등록

# auto_add_known_hosts.yml

---
- hosts: KNOWN_HOSTS
  connection: local
  serial: 1
  gather_facts: no

  tasks:
    - name : Get known_hosts fingerprint for remote nodes from local host (Ansible Server)
      command: "/usr/bin/ssh-keyscan -t ed25519 {{ ansible_host }}"
	    register: keyscan    # 원격지 호스트에 대한 fingerprint 를 스캔

    - name: Add ansible_host to known_hosts
      lineinfile:
        path: ~/.ssh/knwon_hosts
        line: "{{ item }}"
        create: yes
      with_items:
        - "{{ keyscan.stdout_lines }}"

playbook 수행 명령어

ansible-playbook -i [hosts 파일 path] ['auto_add_known_hosts.yml' path] -k

2. SSH Server에 SSH Client의 pub 파일 등록

2.1. Managed-Node들이 PW방식이 아닌 Key파일 방식으로 ansible 수행되도록 설정하기

Managed Node들에 SSH Password 입력 없이 스크립트 수행을 하게 하기 위한 사전 작업이라고 생각하면 된다.

key파일을 이용하여 ansible을 사용하지 않을거라면, 이 과정은 생략해도 된다.

key파일 방식으로 변경을 원치 않으면, 2.2.의 과정 또한 진행하지 않아도 된다.

Managed Node에 로그인할 user에 대한 ~/.ssh/authorized_keys 파일에 Control Node 가 생성한 SSH Public Key 내용 복사

# auto_authorized_keys.yml

---
- hosts: AUTHORIZED_KEYS    # {Inventory 파일에 있는 그룹명 또는 호스트명} ex) CentOS or 10.0.2.15
	gather_facts: no    # Facts : Remote host의 Hostname, CPU, Memory 정보 등을 수집하는 setup 모듈
  
  tasks:
    - name: Copy SSH Public Key from Control Node to Managed-Node
      authorized_key: 
        user: root # Managed-Node의 로그인할 user를 지정
        state: present
        key: "{{ lookup('file', '/root/.ssh/id_ed25519.pub') }}"
				# lookup: Control Node의 /root/.ssh/id_ed25519.pub 파일의 모든 내용을 찾는다.

playbook 수행 명령어

ansible-playbook -i [hosts 파일 path] ['auto_authorized_keys.yml' path] -k [-c paramiko]

‘-c paramiko’ 를 사용하는 이유
[ansible] ansible의 paramiko

이 과정이 정상적으로 수행되었다면, 이제 ssh-agent가 가동되어 있고, 올바른 key파일로 캐싱되어 있다면,
ansible-playbook 수행 시, -k 옵션을 넣지 않아도 된다!

만약 아무 반응 없이 위 playbook이 수행되지 않는다면 아래 2.2 방법으로 수행해본다.

2.2. 만약 Managed Node에 이미 key 파일로 로그인하도록 등록되어 있다면?

ansible의 특성상, ansible-playbook -k 옵션을 수행하면, SSH Password 방식으로 connection이 맺어지기 때문에, 이미 Managed Node에 key파일 방식으로 connection이 맺어지도록 설정되어 있다면, ansible-playbook -k 명령어가 수행되지 못한다.

따라서 이런 경우에는, Managed Node의 authorized_keys 파일에서 이미 등록되어 있는 key파일 내용을 지워줘야 한다. 이 과정 또한 ansible-playbook 으로 진행이 가능하므로, 아래 과정으로 진행해보자.

2.2.1. ssh-agent 가동

# eval : "" 안에 내용을 한번 검증 후 백그라운드로 실행하겠다.
# ssh-agent -s : ssh-agent 시작
eval "$(ssh-agent -s)"

2.2.2. ssh-agent에 key파일 캐싱

# ssh-keygen 으로 생성한 SSH Key 파일을 ssh-agent 에 캐싱하는 명령어
# 명령어 수행시, 최초에만 ssh-keygen 으로 key 파일 생성할 때 넣은 passphrase 입력해야 함
ssh-add ~/.ssh/id_rsa

2.2.3. 기존 key파일 제거하는 playbook 수행

참고로 아래 플레이북은 Managed Node의 RSA 알고리즘을 사용한, root 유저 접속에 대한 키 파일의 내용을 삭제하는 것이다. 다른 유저로 되어 있다면, 아래 'user' key 의 값을 해당 유저로 설정해 주면 된다.

# remove_rsa_authorized_keys.yml

---
- hosts: RSA_HOSTS
  serial: 1
  gather_facts: no

  tasks:
    - name: Remove root's public key from the authorized_keys file on the Managed-Node
      authorized_key:
        user: root
        state: absent
        key: "{{ lookup('file', '/root/.ssh/id_rsa.pub') }}"

playbook 수행 명령어

ansible-playbook -i [hosts 파일 path] ['remove_rsa_authorized_keys.yml' path] -k [-c paramiko]

이 과정이 완료되고, 다른 알고리즘의 key 파일 방식으로 Managed Node들을 설정하고 싶다면, hosts 파일의 [AUTHORIZED_HOSTS] 그룹에 해당 호스트의 IP들을 넣고, 2.1.의 내용을 다시 수행하면 된다.

3. Managed Node 들에 Ansible playbook SSH password 없이 가능한 지 테스트

위 playbook 으로 known_hosts, authorized_keys 파일 작업 수행 후에 다음과 같은 playbook 실행으로 테스트 해보도록 하자!

해당 playbook 은 Managed Node 들의 uptime 을 간단하게 조회하는 playbook 이다.

# uptime_test.yml

---
- name: Test passwordless ssh command on managed nodes
  hosts: PLAYBOOK_TEST
  gather_facts: no
  tasks:
    - name: Run uptime command via ssh without password
      shell: ssh root@{{ inventory_hostname }} uptime
      register: uptime_output

    - name: Show uptime command result
      debug:
        msg: "{{ inventory_hostname }} uptime: {{ uptime_output.stdout }}"

playbook 수행 명령어

ansible-playbook -i [hosts 파일 path] ['uptime_test.yml' path] -k [-c paramiko]

참고

Lookup plugins — Ansible Documentation

Lookup plugins — Ansible Community Documentation

Ansible Community Documentation Ansible Lookup plugins Lookup plugins are an Ansible-specific extension to the Jinja2 templating language. You can use lookup plugins to access data from outside sources (files, databases, key/value stores, APIs, and other s

docs.ansible.com

ansible.posix.authorized_key module – Adds or removes an SSH authorized key — Ansible Documentation

ansible.posix.authorized_key module – Adds or removes an SSH authorized key — Ansible Community Documentation

Ansible Community Documentation Ansible ansible.posix.authorized_key module – Adds or removes an SSH authorized key Note This module is part of the ansible.posix collection (version 1.5.4). You might already have this collection installed if you are usin

docs.ansible.com

ansible.posix.authorized_key module – Adds or removes an SSH authorized key — Ansible Documentation

ansible.posix.authorized_key module – Adds or removes an SSH authorized key — Ansible Community Documentation

docs.ansible.com

Append or remove SSH public certificates from an authorized_keys file

FreeKB

my Interwebs Free Knowledge Base

www.freekb.net

[Java] Java의 메모리 영역(Runtime Data Area)과 OOM 종류

코_노 — Wed, 20 Mar 2024 09:00:24 +0900

WAS에 올라와 있는 한 애플리케이션에서 *Heap Dump 파일(.hprof 파일)이 떨어져, 이번 포스팅을 계기로 Java의 Heap 메모리 영역에 대해 정리하고, OOM을 어떻게 해결할 수 있을 지 알아보려고 한다!

*Heap Dump 파일 : Runtime 중인 애플리케이션의 힙 메모리 영역에 대한 스냅샷을 찍어 해당 내역을 저장한 파일을 일컫는다.

Java에서의 메모리 영역

Java로 짜여진 프로그램이 실행되려면, JVM(Java Virtual Machine)이 OS로부터 정해진 메모리를 할당 받고, 해당 JVM 위에서 Java로 짜여진 프로그램이 실행되는 것이다.

이때, JVM에 할당된 메모리 영역(Runtime Data Area)은 용도에 따라 여러 영역으로 나누어 관리되는데, Data type별로 Stack 영역, Heap 영역, Static 영역 등으로 나뉘게 된다.

한 JVM 에서의 Runtime Data Area 도식화 / 출처 : https://velog.io/@indongcha/Runtime-Data-Area%EC%9D%98-%EA%B5%AC%EC%84%B1

출처 : https://www.devkuma.com/docs/jvm/memory-structure/

컴퓨터의 메모리는 사용할 수 있는 공간이 무한하지 않으므로, 어떻게 관리하느냐에 따라 프로그램의 성능이 좌우되며,

이 Java 메모리 영역이 제대로 관리되지 않으면 심할 경우 서비스가 down되기도 한다.

따라서, Java 애플리케이션에서 잘 만들기 위해서는 메모리 구조와 특징에 대해 이해하고 코딩할 필요가 있다.

Java 변수의 종류

Java에서는 Data type 별로 메모리 영역이 나뉜다고 하였으므로, Java에서의 Data type이 어떻게 정의되는 지 볼 필요가 있다.

Java에서의 변수는 크게 4가지로 다음과 같이 나뉜다.

클래스 변수(Class Variable, Static Variable)
- 클래스 영역에서 타입 앞에 static 키워드가 붙는 변수
- 객체를 공유하는 변수로, 여러 객체에서 공통으로 사용하고 싶을 때 정의
인스턴스 변수(Instance Variable)
- 클래스 영역에서 static이 아닌 변수
- 개별적인 저장 공간으로, 객체/인스턴스마다 다른 값을 저장할 수 있음
- 인스턴스 생성만 하고 참조 변수가 없는 경우에는 GC(Garbage Collector)에 의해 자동 제거된다.
지역 변수 (Local Variable)
- 메서드 내에서 선언되고, 메서드 수행이 끝나면 소멸되는 변수
- 초기값을 지정한 후에만 사용 가능
매개 변수(parameter)
- 메서드 호출 시, '전달하는 값'을 가지고 있는 인수
- 지역 변수와 동일하게, 선언된 곳부터 수행이 끝날때까지만 유효하다.

1. Method 영역

: JVM이 동작하여 클래스 로더가 클래스를 로딩할 때 곧바로 생성되는 영역으로, JVM이 읽어들인 클래스와 인터페이스에 대한 Runtime Constant Pool, 멤버 변수(필드), 클래스 변수(Static 변수), 상수(final), 생성자(constructor), 메소드(method) 등을 저장하는 공간이다.

Method(Static) 영역에 있는 것은 어느 곳에서나 접근이 가능
Method(Static) 영역의 데이터는 프로그램의 시작부터 종료까지 컴퓨터의 메모리에 상주한다.
-> Method 데이터를 무분별하게 많이 사용할 경우, 메모리 부족 현상이 일어날 수 있게 된다.

출처 : https://inpa.tistory.com/entry/JAVA-%E2%98%95-%EA%B7%B8%EB%A6%BC%EC%9C%BC%EB%A1%9C-%EB%B3%B4%EB%8A%94-%EC%9E%90%EB%B0%94-%EC%BD%94%EB%93%9C%EC%9D%98-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%98%81%EC%97%AD%EC%8A%A4%ED%83%9D-%ED%9E%99#recentEntries

2. Stack 영역

: 메소드 내에서 정의하는 기본 자료형에 해당되는 지역변수의 데이터 값이 저장되는 공간이다.

메소드가 호출될 때, 스택 영역에 스택 프레임이 생기고, 스택 프레임 안에 메소드를 호출하게 됨
primitive 타입의 데이터(int, double, byte, long, boolean 등)에 해당되는 지역변수, parameter 데이터 값이 저장됨
메소드가 호출될 때 메모리에 할당되고, 종료되면 메모리에서 사라짐
Stack은 LIFO(Last-In-First-Out)의 특성을 가지므로, 스코프의 범위를 벗어나면 스택 메모리에서 사라지게 된다.

3. Heap 영역

: JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해, Runtime 시 동적으로 할당하여 사용하는 영역이다.

참조형(Reference Type) 데이터 타입을 갖는 객체(인스턴스), 배열 등이 저장되는 공간
Heap 영역에 있는 인스턴스들을 가리키는 레퍼런스 변수는 Stack 영역에 적재된다.
Heap 영역은 Stack 영역과 다르게, 해당 인스턴스 또는 배열의 호출이 끝나더라도 메모리 할당이 곧바로 해제되지 않는다. 그러다 어떤 참조 변수도 Heap 영역에 있는 인스턴스를 참조하게 않게 되었을 때, GC에 의해 메모리에서 제거된다.
Stack 영역은 스레드 갯수마다 각각 생성되는 반면, Heap 영역은 몇개의 스레드가 존재하든 상관없이 JVM 당 하나의 Heap 영역만 존재하게 된다.

OOME(Out Of Memory Error)란?

: JVM의 메모리가 부족하여 발생한 에러로, GC의 한계점에 이르면 OOME가 나타나고, 이때 Heap Dump가 떨어지게 된다.

객체를 생성하는 과정에서 Heap영역에 객체를 할당하기 위한 공간이 부족한 경우 발생
GC를 수행하는 데 과도한 시간이 소비되어 메모리를 사용하지 못하는 경우 발생
기본 할당 조건을 충족하지 못하는 경우, 네이티브 라이브러리 코드에 의해서도 발생 가능 (Swap 공간 부족)

OOME의 종류

OutOfMemoryError : Java Heap space

◎ 원인 : 자바 Heap 영역의 공간이 부족하여, 새로운 객체를 생성할 수 없는 경우에 발생한다.

Heap 영역에 대한 공간 확보는 GC를 통해 이루어지는 데, GC를 수행하기 이전에 Heap 메모리 영역이 부족할 경우 발생

가장 많이 확인되는 케이스
메모리 누수가 아닌, 지정된 Heap size가 애플리케이션에 충분히 할당되지 않은 경우에도 발생
LifeCycle이 긴 애플리케이션의 경우, finalize를 과도하게 사용할 때 발생하기도 함
→ finalize는 소멸을 명시적으로 할 때 사용하나, GC에 마킹하는 데 오래 걸리는 단점이 있음

OutOfMemoryError : GC Overhead limit exceeded

◎ 원인 : Heap 공간이 부족하여 GC가 이루어졌지만, 새로 확보된 Heap 공간이 전체 메모리의 2% 미만일 때 발생

‘Java Heap Space’ 케이스와 유사하게 자주 발생하는 이슈로, 무분별하게 객체를 생성할 경우 발생
더 이상 GC를 할 수 없을 정도로 메모리를 과도하게 사용한다는 것
문제점을 해결하고, 경우에 따라 Heap 메모리 사이즈를 늘리는 것을 추천
-XX:-UseGCOverheadLimit 옵션을 사용하여, GC Overhead에 대한 limit 자체를 꺼버릴 수도 있지만, 추천하지 않음

OutOfMemoryError : Requested array size exceeds VM limit

◎ 원인 : 애플리케이션 혹은 애플리케이션을 사용하는 API가 할당된 Heap 공간보다 큰 사이즈의 배열 할당을 시도하는 경우 발생

배열 사이즈를 조정하거나 Heap 메모리 사이즈를 증가시켜서 해결

OutOfMemoryError : Metaspace

◎ 원인 : 자바 클래스의 메타데이터(클래스 이름, 생성 정보, 필드 정보, 메서드 정보 등)가 저장되는 *PermGen 또는 *Metaspace의 공간이 부족할 경우 발생. Metaspace의 경우, 자동으로 크기를 증가하는 과정보다 더 많은 메타 데이터들이 저장되면 이 에러가 발생할 수 있다.

클래스의 메타데이터가 저장되는 공간으로, JDK7 이전에는 PermGen으로 정의되었음
-XX:MetaspaceSize, -XX:MaxMetaspaceSize 설정을 추가하여 오류를 해결할 수도 있음 (default는 20MB)

*PermGen(Permanent Generation) : Java7 에서의 메타데이터가 저장되는 영역

**Metaspace : PermGen 영역은 Heap 메모리에 포함되어, 작은 사이즈로 설정되었기 때문에, GC가 빈번히 발생하였는데, 이러한 문제를 개선하고자 Java8에서는 Heap 메모리 영역에서 분리하여, OS에서 제공하는 native 메모리 영역을 사용하도록 한 영역. GC를 수행하지 않고도 자동으로 크기를 증가 시켜 공간을 확보할 수 있게 되었다.

OutOfMemoryError : request size bytes for reason. Out of swap space?

◎ 원인 : 자바 HotSpot VM 코드가 Native heap을 고갈시켜, Native heap에 할당할 수 없는 경우 발생

이 에러 코드와 함께 실패한 요청의 바이트 크기와 메모리 요청의 이유를 나타내며, 대개의 경우 메모리 할당에 실패한 소스 모듈의 이름을 출력한다.
Heap 메모리 로그 또는 Memory-map 정보를 분석하는 것이 유용하다.
OS의 문제 유틸리티(Native Operation System tools 등)를 사용하여 문제를 진단할 수 있다.

OutOfMemoryError : unable to create native thread

◎ 원인 : 시스템 리소스 제한에 도달하여 새로운 네이티브 스레드를 생성할 수 없을 때 발생

Thread를 과도하게 많이 사용하는 경우 발생할 수 있음
OS의 메모리가 부족해서일 수도 있고, OS 자체적으로 쓰레드 개수를 제한해서일 수도 있음

참고

https://inpa.tistory.com/entry/JAVA-%E2%98%95-%EA%B7%B8%EB%A6%BC%EC%9C%BC%EB%A1%9C-%EB%B3%B4%EB%8A%94-%EC%9E%90%EB%B0%94-%EC%BD%94%EB%93%9C%EC%9D%98-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%98%81%EC%97%AD%EC%8A%A4%ED%83%9D-%ED%9E%99#recentEntries

☕ 그림으로 보는 자바 코드의 메모리 영역(스택 & 힙)

자바의 메모리 영역 이번 포스팅에선 자바(JAVA)를 사용하는 입장에서 알아야 할 메모리 구조 및 특징에 대해서 알아보려고 한다. 자바 프로그램이 실행되면 JVM(자바 가상 머신)은 OS로부터 메모

inpa.tistory.com

https://incheol-jung.gitbook.io/docs/q-and-a/java/heap-dump-feat.-oom

heap dump 분석하기 (feat. OOM) | Incheol's TECH BLOG

만약 메모리가 8 GB의 인스턴스에서 아무런 설정 없이 애플리케이션을 운영한다면? 최대 메모리 사이즈 : 8GB / 4 = 2GB 초기 메모리 사이즈 : 8GB / 64 = 127MB

incheol-jung.gitbook.io

https://devhtak.github.io/java%20study/2021/07/29/Java_OOM.html

Java - OOM 종류 및 조치

Heap

devhtak.github.io

[개념] 프롬프트 엔지니어링의 개념과 LLM 활용 시 꿀팁

코_노 — Wed, 17 Jan 2024 12:10:22 +0900

프롬프트 엔지니어링을 얘기하기 전에, LLM이 무엇인지 정확히 알고 가자!

LLM(Large Language Model, 대규모 언어 모델)이란?

: 빅데이터 시대에 등장한 수억 개의 매개 변수를 가진 인공신경망으로 이루어진 거대한 언어모델로, 대량의 텍스트 데이터, 특히 인간의 자연어 처리를 위해 학습된다. 이러한 언어 모델은, 주어진 문맥 정보를 바탕으로 텍스트를 생성하거나 이해하는 데에 사용된다.

LLM의 주요 특징

대량의 데이터 학습 : 웹상의 텍스트(Wikipedia, Github, Twittwer 등), 책, 기사 등 다양한 소스에서 수십 또는 수백 GB의 텍스트 데이터에 대해 학습한다.
수억 개의 매개 변수 : LLM은 수억 또는 그 이상의 매개변수를 포함할 수 있으며, 이로 인해 더 복잡한 패턴과 구조를 학습할 수 있게 된다.
다양한 태스크 수행 : LLM은 다양한 자연어 처리 태스크를 수행할 수 있는데, 이를테면, 텍스트 생성, 질문 응답, 번역, 요약 등의 작업을 수행할 수 있다.
전이 학습(Transfer Learning) : 하나의 문제를 해결하고 이와 다르면서 관련된 문제에 적용하는 동안 얻은 지식을 저장하는 데에 집중하는 기계 학습 기법이다.
Emergent Ability : 데이터의 학습량에 따라 성능이 미미하다가, 특정 임계점을 지나면 급작스럽게 뛰어난 퍼포먼스 및 자연어 처리 능력을 갖추게 되는 것이 LLM의 특징이다. Emergent Ability를 갖게 되면, 다음과 같은 3가지 특징을 띄게 된다.
- Instruction Following : 명령어를 그대로 따르는 특성이다. Emergent Ability 단계 이전의 언어 모델은, 앞뒤 문맥을 파악하여 정답일 확률이 높은 문장들을 내어주거나 학습된 문장들 중 비슷한 문장을 쿼리해주는 역할이 위주인 반면, Emergent Ability 단계 이후의 언어 모델은, 단순 확률 및 쿼리에 그치지 않고, 앞에 있던 문장을 이해해서 그것의 지시를 따르는 수준까지 이르게 되는 것이다.
  
  프롬프트 예시)
  더보기
  양자역학의 불확정성의 원리에 대해 200자 이내로 설명해줘.
- In-Context Learning(ICL) : 맥락을 굉장히 잘 파악하고, 해당 맥락에 맞는 텍스트를 생성할 줄 안다. 이를 통해, 문서에 대한 유사도 검색까지도 가능해진다.
  
  프롬프트 예시1)
  더보기
  너는 리처드 파인만이고, 나는 물리학에 대해 아무것도 모르는 일반인이다. 일반인도 이해하기 쉽게 불확정성 원리에 대해 200자 이내로 설명해줘.
  
  프롬프트 예시2)
  
  더보기
  다음 글을 참고하여 홍길동이 밥을 언제 먹었는지 알려줘라.
  """
  새벽녘, 홍길동은 쌀로 만든 따뜻한 국물 요리와 신선한 야채 샐러드로 아침을 시작했다. 향긋한 녹차로 마무리 지으며, 하루를 여는 에너지를 얻었다. 정오가 되자, 그는 해산물과 여러 채소가 들어간 김치찌개와 바삭한 김 몇 조각을 즐겼다. 오후 시간에는 과일과 견과류로 달콤하고 건강한 간식을 골랐다.
  저녁이 되어, 홍길동은 구운 닭고기와 다양한 야채를 곁들인 샐러드를 택했다. 밤이 깊어감에 따라, 그는 가벼운 야식으로 우유와 쿠키를 조금 취했다. 이렇게 홍길동은 하루 종일 다양한 음식을 취하며 건강하고 활기찬 하루를 보냈다.
  """
- Step-by-step Reasoning : LLM의 단점에서 기인한 것으로, LLM은 논리적 추론 능력은 뛰어나지 못하다. 그래서 커다란 질의를 단계별 또는 작은 단위의 태스크들로 수행하게끔 하면, 작은 단위에서의 파악할 문맥 및 논리가 급격히 줄어들기 때문에 더 잘 수행하는 특징이 있다.
  
  프롬프트 예시)
  더보기
  다음 문제를 보고 Data analysis를 사용하지 말고, 문제를 다시 말하거나 풀이과정 없이 답만 말해라.
  """
  A는 현재 총 5개의 테니스공을 가지고 있다.
  
  테니스를 칠 때마다 시간당 1개의 공을 잃어버린다.
  
  테니스를 치기 전 다음의 규칙에 따라 공을 구매해야 한다.
  1. 공이 2개 이하로 남아있다.
  2. 해당 주에 공을 구매한 적이 없어야 한다. (월요일부터 일요일까지를 한 주로 본다.)
  3. 공은 한 번 구매할 때 5개씩 구매한다.
  
  평일에는 1시간씩 테니스를 치고, 토/일요일에는 하루에 2시간씩 친다.
  
  오늘은 월요일이며 오늘부터 1일차라고 했을 때, A가 공이 없어서 테니스를 치지 못하는 날은 몇일차인가?
  """
  
  프롬프트 보완)
  더보기
  날짜별로 다음의 항목을 표시하여 다시 계산하여라.
  [n]주차 {요일} : 공 m개가 남아 있음. {공을 구매함} l개 소모. 총 K개 남음. 이번주 구매내역 {있음/없음}

LLM의 한계

최신의 데이터가 학습되어 있지 않다.
할루시네이션(Hallucination) : AI 모델이 정확하지 않거나 사실이 아닌 조작된 정보를 생성하는 것을 의미
근거자료가 부족하다.
커스터마이징에 어려움이 있다. 다시 학습시키거나 fine-tuning조차도 비용이 상당히 많이 든다.

프롬프트 엔지니어링(Prompt Engineering)이란?

: NLP 분야의 개념으로, AI가 생성하는 결과물의 품질을 높일 수 있는 *프롬프트 입력값들의 조합을 찾는 작업

*프롬프트(Prompt) : AI 분야에서의 프롬프트는, AI 모델로부터 응답을 생성하기 위한 입력값이라고 정의할 수 있다.

프롬프트는 다음과 같은 구성 요소를 가지며, 해당 요소들을 반드시 모두 포함하여야 하는 것은 아니다.

프롬프트의 구성 요소

Instruction : 모델이 수행하기를 원하는 특정 Task 또는 지시 사항
Context : 모델이 보다 더 나은 답변을 하도록 유도하는 외부 정보 또는 추가 내용
Input Data : 답을 구하고자 하는 것에 대한 Input 또는 Query문
Output Indicator : 결과물의 유형 또는 형식을 나타내는 요소

프롬프트를 잘 사용하는 방법은, LLM의 특성을 얼마나 최대한으로 활용하는가로 볼 수 있다.

프롬프트 작성을 위한 기본 가이드라인

1. 대화 스타일 조정

API를 호출하여 사용할 경우, AI 모델의 대화 스타일을 조정할 수 있는 주요 값들이 있는데, 이것들을 적절히 조율할 경우, 프롬프트 결과의 정확도를 높일 수 있다.

Temperature : 답변의 창의성과 무작위성을 조정하는 값.
최소 0, 최대 1의 값을 가지며, 해당값이 낮을수록 사실에 근거한 정확한 답변을 제공하고, 높을수록 보다 창의적인 결과물을 생성하게 된다.
Top_p : 답변의 무작위성을 제어하는 조정값.
Temperature와 마찬가지로, 값이 낮을수록 답변이 보다 정확하고 높아질수록 창의적이고 광범위해진다.
frequency_penalty : 값이 높을수록 AI가 기존 답변에서 많이 사용하는 단어를 답변에 포함하도록 한다.
반대로 값이 0이라면, 페널티가 전혀 주어지지 않아, AI가 흔히 사용되지 않는 단어를 답변에 포함할 가능성을 높이게 된다.
presence_penalty : 값이 높을수록 AI가 유사하거나 동일한 단어 및 문구를 답변 시 반복할 가능성을 낮추게 된다.
반대로 값이 0이라면, 페널티가 전혀 주어지지 않아, AI가 단어나 문구를 반복할 가능성이 높아지게 된다.

2. 미사여구를 최소화하여 쉽고 간결하게 표현

프롬프트로서 비추천 예시)

혹시 가능하다면, 인공지능 분야에서 트랜스포머가 어떤 개념인지, 파이썬이나 C++같은 프로그래밍 언어들을 한 번도 활용 해본 적 없는 모든 사람들을 대상으로 알아듣기 쉽게 글로 설명해줄 수 있어?

위 예시를 개선한 프롬프트)

비개발자들을 대상으로 트랜스포머의 개념을 쉽게 설명해줘.

3. 열린 질문보다는 닫힌 지시문을 사용할 것

LLM의 Instruction Following 특징을 잘 활용하기 위해 지정된 프롬프트 가이드라인이라고 볼 수 있다.

다음과 같이, 모호하고 주관적인 답변이 많이 가능할 것 같은 질문보다는, LLM이 적절한 근거를 들어 답변을 낼 수 있도록 보고서와 같은 Form을 함께 제시하여 지시문을 사용해야, 맥락을 이해하고 해당 지시를 잘 따를 수 있게 된다.

프롬프트로서 비추천 예시)

프롬프트 엔지니어라는 직업이 미래에도 지속될 수 있을까?

위 예시를 개선한 프롬프트)

프롬프트 엔지니어가 미래에도 지속될 수 있는 직업인지에 대한 보고서를 써줘.

4. Instruction과 Context를 구체적으로 명시

구분 기호를 사용하여 참고 문장 또는 맥락 문장(Context)를 앞에 작성하며, 지시 문장(Instruction)은 가능한 맨 뒤에 사용하는 것이 좋다.

아래 링크의 예시를 통해 살펴보자!

https://chatx.ai/marketplace/chatgpt/write-a-novel-with-chatgpt/

Write a novel with ChatGPT - ChatX

This ChatGPT prompt can help you with a starting point. By using this prompt, you can generate ideas for characters, storylines, and settings.

chatx.ai

소설가로서의 역할과 목표를 chatgpt에게 Context로 알려주고, 이후 사용자가 실제 원하는 Instruction에 대해서는 특수 문자로 묶어준 예시)

소설가로서 너의 임무는 독자의 마음을 사로잡고 오랜 시간동안 몰입할 수 있는 이야기를 만드는거야.

장르는 판타지, 로맨스, 역사 소설 등 어떤 장르든 자유롭게 선택 가능해.

주요 목표는 매력적인 줄거리, 잘 발달된 캐릭터, 놀라운 클라이맥스로 눈에 띄는 이야기를 만드는 거야.

너의 첫 번째 과제는, [다른 행성에 사는 한 남자의 이야기를 다룬 공상과학 소설을 작성하는 것으로, 미래 기술, 외계 생명체, 환상적인 개념을 다룰 수 있어. 너의 이야기는 독자들을 모험과 미스터리 흥분으로 가득 찬 흥미진진한 신세계로 안내해야 해. 목표는 독자들에게 깊은 인상을 남길 수 있는, 생각을 자극하는 동시에 재미있는 공상 과학 소설을 만드는거야.]

5. 예제를 함께 제공

Main-Task 또는 Instruction을 요청하기 전, 올바른 질문과 답변 예제를 한 개 또는 다수 제공하는 기법을 활용할 수 있다.

6. RAG를 활용

RAG(Retrieval Augmented Generation, 검색 증강 생성)

: 외부 소스에서 가져온 정보로 생성형 AI 모델의 정확성과 신뢰성을 향상시키는 기술

-> LLM 모델의 학습되어 있는 데이터만 활용하지 않고, 모델 외부의 자료도 답을 도출하는 데에 함께 사용할 수 있도록 한다.

-> 모델 학습 없이도 외부 데이터를 사용함으로써 최신 데이터에 기반으로 한 정답에 대한 정확도가 올라간다.

-> 이에 따라 최신 회사 정보도 활용이 가능하다.

RAG의 한계점

내부 데이터의 DB/검색엔진의 성능이 매우 중요하다.
RAG을 위한 별도의 내부 시스템 구축이 필요하다.
Hallucination 및 부정확한 결과 출력을 100% 막을 수는 없다.

참고

https://www.youtube.com/watch?v=rMJErYfGLCU&t=310s

https://tech.kakaoenterprise.com/188

[IT TREND] 프롬프트 엔지니어링, AI라는 도구를 잘 사용하는 방법

시작하며 생성형 AI, 그 중에서도 특히 거대 언어 모델들을 중심으로 기술 시장은 이례없던 속도로 움직이고 있습니다. 대중의 생성형 AI에 대한 높아진 관심을 기반으로 다양한 애플리케이션 사

tech.kakaoenterprise.com

[Terraform] AWS 3-tier Achitecture를 구성하기 위한 Terraform 프로젝트 구조 잡기

코_노 — Wed, 10 Jan 2024 15:12:52 +0900

아직 Terraform을 통해 AWS의 VPC 생성 조차 해보지 않았다면, 아래 링크인 이전 포스팅을 참고하길 바란다.

https://co-no.tistory.com/entry/Terraform-%ED%85%8C%EB%9D%BC%ED%8F%BC%EC%9D%84-%ED%86%B5%ED%95%9C-AWS-%EA%B5%AC%EC%84%B1-VPC-%EC%83%9D%EC%84%B1

[Terraform] 테라폼을 통한 AWS 3-tier 구성 (1) - AWS CLI 설정 및 VPC 생성

0. AWS CLI 및 AWS Configure 테라폼으로 aws 리소스를 관리하기 위해서는, 테라폼이 구동되는 동일한 환경 내에서 AWS CLI가 설치되어 있고, AWS CLI를 통해 모든 리소스의 접근 권한을 가진 AWS IAM User와의

co-no.tistory.com

일단 Terraform 파일을 작성하기 전에, 깔끔한 Terraform 프로젝트 관리를 위해 Terraform 공식 홈페이지에서 권장하는 'Standard Module Structure' 를 참고하여 다음과 같이 디렉토리를 구성하자.

https://developer.hashicorp.com/terraform/language/modules/develop/structure

Standard Module Structure | Terraform | HashiCorp Developer

Learn about the recommended file and directory structure for developing reusable m

테라폼 프로젝트 '3-tier-aws' 의 디렉토리 구조

이전 포스팅에서 테스트한 AWS VPC 만드는 과정을, 테라폼 프로젝트를 깔끔하게 관리하기 위해 다음과 같이 구성하였다. 구성할 때, 외국 개발자 깃헙 중 테라폼 프로젝트가 아주 깔끔해 보여 해당 구조를 차용하였다.

https://github.com/BJWRD/three-tier-architecture/blob/main/main.tf

odules distributed as separate repositories.

잘 이해가 가지 않더라도, 일단 아래 tf 파일들을 우선 다 작성하자!

**1. 프로젝트 *루트 모듈의 main.tf**

*루트 모듈 : 테라폼이 실행되는 디렉토리를 '모듈'이라 하는데, 이때 루트 모듈이란, 기본 작업 디렉터리의 정의된 파일 집합을 '루트 모듈'이라고 한다.

# main.tf

provider "aws" {
  region = var.region
}

module "vpc" {
  source       = "./modules/network"
  project_name = var.project_name
  environment  = var.environment
  vpc_id       = module.vpc.vpc_id
  vpc_cidr     = var.vpc_cidr
}

**2. 프로젝트 *루트 모듈의 variables.tf**

# variables.tf

variable "region" {
  description = "AWS Region"
  type        = string
  default     = "ap-northeast-2"
}

variable "project_name" {
  description = "Name of Terraform Project"
  type        = string
  default     = "AWS_3-Tier-Architecture"
}

variable "environment" {
  description = "Environment Type"
  type        = string
  default     = "dev"
}

################################################################################
# VPC Module - Variables 
################################################################################

variable "vpc_id" {
  description = "The VPC to be deployed"
  type        = string
  default     = "aws_vpc.VPC_3Tier.id"  
  # vpc module의 main.tf에서 지정한 aws_vpc 리소스의 name을 가지고 id를 조회해야 함.
}

variable "vpc_cidr" {
  description = "The VPC Network Range"
  type        = string
  default     = "10.0.0.0/16"
}

3. modules/network/variables.tf

variable "project_name" {
  description = "Name of Terraform Proejct"
  type        = string
}

variable "environment" {
  description = "Environment Type"
  type        = string
}

variable "vpc_id" {
  description = "The VPC to be deployed"
  type        = string
}

variable "vpc_cidr" {
  description = "The VPC Network Range"
  type        = string
}

4. modules/network/main.tf

locals {
  required_tags = {
    project      = "AWS_3-tier-architecture"
    environment  = "dev"
  }
}

################################################################################
# VPC
################################################################################
resource "aws_vpc" "VPC_3Tier" {
  cidr_block = var.vpc_cidr
  
  tags = merge(local.required_tags, { Name = "VPC-3Tier" })
}

5. modules/network/output.tf

output "vpc_id" {
  description = "The VPC to be deployed"
  value       = aws_vpc.VPC_3Tier.id
}

테라폼은 관리하는 인프라 인스턴스마다 모듈별로 나누어 관리할 수 있으며, 하위 모듈(디렉토리)에 작성한 tf 파일은 직접 실행이 되지 않는다. 루트 모듈에서 해당 하위 모듈을 호출하는 방식으로, 실제적으로 '실행'되는 것은 루트 모듈(main.tf) 하나인 것이다.

Visual Studio Code의 'Graphviz Interactive Preview' 라는 플러그인을 활용하여, terraform graph > graph.dot 명령어 수행을 통해 생성된 graph.dot 파일을 아래 그림과 같이 확인해 보자!

위 테라폼 프로젝트의 graph

테라폼 코드의 실행 순서는 terraform init 명령을 수행한 디렉토리를 루트 모듈(디렉토리)로 잡고, 그 하위에 있는 모든 .tf 파일을 스캔한다. 이때 해당 코드를 분석하여 실행 순서를 결정하는데, 만약 코드 실행 선후관계까 없다면 해당 코드는 병렬로 수행되고, 반대로 선후관계가 존재한다면 해당 코드는 순서대로 실행되게끔 종속성 그래프에 해당 정보가 들어간다.

위와 같은 테라폼 수행 방식을 이해했다면, 다음과 같이 테라폼 코드를 작성하는 순서를 어느정도 결정할 수 있다.

루트 모듈의 main.tf를 작성한다. 이때, main.tf는 서브 모듈을 호출하는 방식으로만 작성한다.
루트 모듈의 main.tf 실행에 필요한 변수들을 루트 모듈의 variables.tf 파일로 작성한다.
루트 모듈의 variables.tf를 통해 유저로부터 입력받은 또는 정의된 변수를 실제 인스턴스 생성에 관여하는 서브 모듈(main.tf)의 속성값으로 넣어주어야 하는데, 이에 대한 매개체 역할이 서브 모듈의 variables.tf 파일이다.
따라서 우선 서브 모듈의variables.tf 파일을 루트 모듈의 variables.tf 타입과 맞추어 작성해 준다.
서브 모듈의 main.tf 를 작성한다. 서브 모듈의 main.tf는 루트 모듈에서 호출하는 module에 대한 실제 구현방식(?)인 resource 구문으로 작성한다. 그리고 루트 모듈에서의 변수 입력이 아닌, 서브 모듈의 resource 구문에서 곧바로 필요한 변수를 local 변수로 작성한다.
서브 모듈의 resource 구현 이후 (실제 인스턴스 생성 이후)에 발생하는 variable이 루트 모듈에서 사용되어야 한다면, 해당 서브 모듈의 output.tf 파일로 작성한다.

위와 같이 구조를 잡고 테라폼 일단 테라폼 프로젝트를 작성하면, 반복되는 코드의 사용 및 수정이나 종속성에 영향이 생기는 문제는 많이 줄일 것으로 예상된다.혹여나 중간에 큰 문제가 생기면, 다시 프로젝트 구조를 변경해야 할 수도 있다.

더 좋은 프로젝트 구조를 발견하고 테라폼 동작 방식을 좀 더 명료하게 설명할 수 있다면, 이 포스팅을 수정될 수도 있다..!

참고

https://github.com/BJWRD/three-tier-architecture

GitHub - BJWRD/three-tier-architecture: Highly Available, Fault Tolerant, Three-Tier-Architecture on AWS provisioned via Terrafo

Highly Available, Fault Tolerant, Three-Tier-Architecture on AWS provisioned via Terraform - GitHub - BJWRD/three-tier-architecture: Highly Available, Fault Tolerant, Three-Tier-Architecture on AWS...

github.com

https://malwareanalysis.tistory.com/619

테라폼으로 EKS만들기 프로젝트 3-2편 - 테라폼 동작원리

이 글은 테라폼이 어떻게 동작하는지 설명합니다. 3편에서 실행했던 hello world예제를 참고합니다. ▶ 테라폼 동작원리 유투브 영상: https://youtu.be/47FJVP437nk 1. 동작원리 테라폼은 코드를 읽어 코드

malwareanalysis.tistory.com

[RDBMS] DB의 정규화 단계(1NF, 2NF, 3NF, BCNF, 4NF, 5NF)의 개념 및 예시

코_노 — Sun, 7 Jan 2024 11:12:00 +0900

이번 포스팅에서는 테이블 설계에 있어, 데이터베이스 이론가들이 확립시켜 놓은 일종의 규칙,

즉, 정규화 단계가 무엇이 있는지 살펴볼 것이다.

우선 이러한 정규화를 하는 목적에 대해 먼저 살펴 보자.

정규화 목적

중복 데이터를 최소화하여 테이블 불일치 위험을 최소화한다.
수정, 삭제 시 이상 현상을 방지함으로써, 데이터 구조의 일관성을 최대화한다.
데이터 삽입 시 릴레이션의 재구성에 대한 필요성을 줄인다.
효과적인 검색 알고리즘을 생성하도록 돕는다.

그럼 데이터베이스 이론가들이 확립시켜 놓은 정규화 단계가 어떻게 구성되는 지 살펴보자.

1. 제 1정규화 (1NF, 1st Normal Form)

: 비정규형 -> 1NF로 바꾸는 것을 말하며, 테이블 내의 속성값이 모두 원자값(Atomic Value)만으로 구성되어야 한다는 원칙을 가지고 있다.

여기에서 원자값이란, 더 이상 쪼개질 수 없는 단위를 말하며, 다음과 같은 조건을 만족한다.

각 속성은 하나의 값만을 가진다.
하나의 속성은 같은 종류나 타입(type)을 가져야 한다.
각 속성은 유일(unique)한 이름을 가져야 한다.
각 속성 간의 순서가 상관이 없어야 한다.

비정규형의 [학생] 테이블

학번	지도교수	학과	수강 과목	성적
100	이상철	컴퓨터공학과	데이터베이스개론, 자료구조	A, B
200	박종인	컴퓨터공학과	클라우드	B
300	안주은	전자공학과	통신공학	A
400	김유이	수학과	미적분학	C

위 테이블은 '100'이라는 학번을 가진 학생의 '수강 과목'이 '데이터베이스개론, 자료구조'로 2개의 값을 가지고 있기 때문에, 원자값을 가져야 한다는 1NF의 조건을 만족하지 못한다. 따라서 다음과 같이 테이블을 분리해주어야 한다.

학번	지도교수	학과	수강 과목	성적
100	이상철	컴퓨터공학과	데이터베이스개론	A
100	이상철	컴퓨터공학과	자료구조	B
200	박종인	컴퓨터공학과	클라우드	B
300	안주은	전자공학과	통신공학	A
400	김유이	수학과	미적분학	C

2. 제 2정규화 (2NF, 2nd Normal Form)

: 1NF -> 2NF로 바꾸는 것을 말하며, *부분 함수 종속을 제거한다는 원칙을 가지고 있다. 그리고 2NF는 1NF의 조건도 반드시 만족해야 한다.

제 1정규형까지만 정규화할 경우, 위에서 언급한 삽입이상, 삭제이상, 갱신이상이 발생할 수 있게 된다.

Case 1. 학생이 새 과목을 수강 신청할 때는 반드시 학생의 지도교수까지 알아야 한다. (과목이랑 지도교수는 연관성이 없는 데이터인데, 하나의 데이터를 삽입하기 위해 불필요한 정보를 알아야 한다.)

=> 삽입 이상

Case 2. '300'번 학생이 '통신공학' 과목을 취소하면, '300'번 학생의 레코드가 사라질 수 있다.

=> 삭제 이상

Case 3. '100'번 학생이 지도교수를 변경할 때, 위 테이블의 예시에서는 2개의 레코드 값을 모두 변경해주어야 한다.

=> 갱신 이상

이러한 이상 현상이 발생하는 이유는, 기본키('학번'과 '수강과목')가 아닌 속성들이 기본키에 *완전 함수 종속되지 못하고, 부분 함수 종속되어 있기 때문이다.

* 완전 함수 종속 : 종속자가 기본키에만 종속되며, 기본키가 여러 속성으로 구성되어 있을 경우, 기본키를 구성하는 모든 속성이 포함된 기본키의 부분집합에 종속된 경우

* 부분 함수 종속 : 테이블에서 기본키가 복합키일 경우,종속자가 기본키를 구성하는 속성 중 일부에게만 종속된 경우

위 예시로 보면 다음과 같이 테이블을 분리하는 것이다.

[학생] 테이블

학번	지도교수	학과
100	이상철	컴퓨터공학과
100	이상철	컴퓨터공학과
200	박종인	컴퓨터공학과
300	안주은	전자공학과
400	김유이	수학과

[성적] 테이블

학번	수강 과목	성적
100	데이터베이스개론	A
100	자료구조	B
200	클라우드	B
300	통신공학	A
400	미적분학	C

3. 제 3정규화 (3NF, 3rd Normal Form)

: 2NF -> 3NF로 바꾸는 것을 말하며, *이행 함수 종속을 제거한다는 원칙을 가지고 있다.

위 예시를 다시 살펴보면, 2NF를 만족하는 [학생] 테이블에서 이행 함수 종속이 생기는 것을 볼 수 있다.

즉, '학번' 데이터를 알면, '지도교수' 데이터를 알고, 그에 따라 '학과' 데이터도 알 수 있게 된다.

*이행 함수 종속 : 한 테이블 내에서 X, Y, Z 라는 3개의 속성이 있을 때, X->Y, Y->Z 란 종속 관계가 있고 X->Z가 성립한다면, 이를 이행 함수 종속이라고 말한다. 즉, X를 알면, Y도 알고 그를 통해 Z도 알 수 있는 경우를 말하는 것이다.

위 예시처럼 이행 함수 종속이 생기면, 다음과 같은 문제가 발생한다.

Case 1. 신설 학과가 생성되었는데, 아직 학생(학번)이 없으므로, 신설 학과에 대한 데이터를 추가할 수 없다.

=> 삽입 이상

Case 2. 기존 학과가 다른 학과로 통폐합되었는데, 지도교수와 학생은 여전히 학교에 존재한다. 이럴 경우, 기존 학과 데이터를 삭제하면 학생과 지도교수 데이터가 모두 사라지게 된다.

=> 삭제 이상

Case 3. 기존 학과 이름이 바뀌었는데, 이럴 경우 해당 학과에 속하는 학생들의 모든 '학과' 데이터를 변경해야 한다.

=> 갱신 이상

따라서 2NF만을 만족하는 테이블은 3NF도 만족하도록 테이블 설계를 업그레이드(?) 해야 한다. 위 예시의 [학생] 테이블을 다음과 같이, [학생] 테이블, [지도교수] 테이블로 나누면, 이행 함수 종속을 탈피할 수 있다.

[학생] 테이블

학번	지도교수
100	이상철
200	박종인
300	안주은
400	김유이

[지도교수] 테이블

지도교수	학과
이상철	컴퓨터공학과
박종인	컴퓨터공학과
안주은	전자공학과
김유이	수학과

3.5 BCNF (Boyce and Codde Normal Form)

: 3NF를 조금 더 강화시킨 개념으로, 강한 제3 정규형이라고도 한다. 모든 결정자는 항상 *후보키가 된다는 원칙을 가지고 있다.

*후보키 : 각 행을 유일하게 식별할 수 있는 최소한의 속성들을 가진 집합으로, 기본키가 될 수 있는 후보들이다. *슈퍼키 중 더 이상 줄일 수 없는 형태이기 때문에, 유일성과 최소성을 동시에 만족한다.

*슈퍼키 : 각 행을 유일하게 식별할 수 있는 속성들의 집합으로, 유일성은 만족하나, 최소성은 만족하지 못한다.

BCNF는 왜 필요할까? 다음과 같이 3NF를 만족하는 [학생수강] 테이블이 있다고 가정하자.

[학생수강] 테이블

이런식의 테이블 설계는 왜 문제일까?

Case 1. 새로운 교수가 특정 과목을 담당하게 되어, 데이터를 추가하려고 하면, 아직 수강 학생이 없기 때문에, 새로운 교수 및 과목에 대한 레코드 삽입이 불가하다.

=> 삽입 이상

Case 2. 학번 '100'이 '자료구조' 과목을 취소하면, '이상철' 교수가 '자료구조'를 담당한다는 정보도 삭제되어 버린다.

=> 삭제 이상

Case 3. '이상철' 교수의 과목이 '자료구조'에서 '알고리즘'으로 바뀐다면, 담당교수가 '이상철'인 레코드를 모두 바꿔야 하는 문제가 생겨 버린다.

=> 갱신 이상

이러한 이상현상은 결국 결정자가 후보키로 취급되고 있지 않기 때문에 발생한다. 다음과 같은 테이블 구성을 통해 (학번, 과목명), (담당교수)의 집합을 기본키로 지정하면, 위와 같은 이상현상을 해결할 수 있다.

BCNF를 만족하기 위한 과정

보통 실무에서는, BCNF 단계까지만 수행하는 경우가 많다.

대부분의 릴레이션의 경우, BCNF까지만 수행하여도 5NF의 요건을 만족하게 되기 때문이다.

4NF, 5NF로의 정규화는, 릴레이션 내의 모든 속성이 키에 해당되는 릴레이션일 경우에만 진행한다.

즉, 릴레이션 내에 존재하는 후보키가 복합키일 때만 필요한 것이다.

BCNF 이상으로 정규화를 수행하여 테이블을 쪼개놓으면, 장점보다는 단점이 더 많이 작용할 수 있다.

특히 *연결의 함정(Connection Trap)이 발생할 여지가 다분하다.

그래도 개념은 알아두면 좋으니, 제 4정규화와 제 5정규화까지 뭔지 살펴보도록 하자!

4. 제 4정규화 (4NF, 4th Normal Form)

: 3NF(or BCNF) -> 4NF의 과정으로, *다치 종속(Multi-valued Dependency)이 없어야 한다는 원칙을 가지고 있다.

아래와 같은 다치 종속을 만족하는 [학생] 테이블을 살펴보자.

[학생] 테이블

*다치 종속(Multi-valued Dependency) : 어떠한 조건을 만족하는 튜플이 릴레이션 안에 있을 것을 요구하는 일종의 제약조건. 함수적 종속성에 속하는 것이 아닌, 별도로 구분되는 개념으로 본다.

'학과'와 '동아리'는 서로 관계가 없는 독립적인 관계인데, '학번'에 따라 결정되는 특성이 있다.

Case 1. 학번 '100' 학생의 경우, 컴퓨터공학과 전자공학 복수전공을 하고 있는데, 동아리도 2개를 가입하고 있다. 이런 상황에서, 학번 '100' 학생이 동아리 하나를 더 가입하면, '100' 학생에 대한 레코드를 의미없이 2개나 더 추가해야 하는 상황이 생겨버린다.

=> 삽입 이상

이렇게 서로 연관이 없는 여러 컬럼들이 결정자에 대해서 종속자의 관계를 가지고 있다면, 다음과 같이 결정자와 종속자가 1:1 관계가 되도록 테이블을 분해해주면 4NF를 만족한다.

제 4정규화를 거쳐 생성된 [학생학과] 테이블과 [학생동아리] 테이블

참고로, [학생학과] 테이블은 복수전공을 한 학생은 학번 데이터가 2개 이상일 수 있으며, [학생동아리] 테이블은 한 학생이 동아리를 여러 개 가입했다면 학번 데이터가 2개 이상일 수 있다.

5. 제 5정규화 (5NF, 5th Normal Form)

: 4NF -> 5NF의 과정으로, *JOIN 종속을 제거한다는 원칙을 가지고 있다.

위에서 예시로 나온 4NF 형태의 [학생학과] 테이블과 [학생동아리] 테이블을 '학번'을 기준으로 JOIN 연산하면, 다음과 같은 테이블이 생성된다.

4NF의 테이블들을 '학번' 기준으로 JOIN한 테이블

*JOIN 종속 : 하나의 테이블을 여러 개의 테이블로 분해하였다가, 다시 조인했을 때 데이터 손실은 없지만, 필요없는 데이터가 생기는 것을 말한다. 다치 종속의 개념을 더 일반화시킨 것이라 볼 수 있다.

위 테이블과 같이 중복된 데이터가 많아지면, 하나의 튜플이 가지는 특별한 의미도 없고, DB에서의 불필요한 연산도 증가하게 된다. 따라서 아래와 같이 3개의 테이블로 분해하여 JOIN 종속을 없앨 수 있다.

제 5정규화 과정

참고

https://velog.io/@wisdom-one/%EC%A0%95%EA%B7%9C%ED%99%94Normalization

정규화 (1NF, 2NF, 3NF, BCNF, 4NF, 5NF)

1. 정의 Normalization 관계형 데이터 모델에서 데이터의 중복성을 제거하여 이상 현상(Anomaly)을 방지하고, 데이터의 일관성과 정확성을 유지하기 위해 무손실 분해하는 과정을 말한다. > #### 이

velog.io

https://rebro.kr/160

[DB] 8. 정규형 (1NF, 2NF, 3NF, BCNF)

[목차] 1. 제1 정규형 2. 제2 정규형 3. 제3 정규형 4. BCNF 정규형이란 정규화된 결과를 말하며, 제1 정규형, 제2 정규형, 제3 정규형, BCNF, 제4 정규형, 제5 정규형이 있다. 실무적으로 제4, 제5 정규형은

rebro.kr

https://www.sunny-son.space/MySQL/RDBMstart04/

관계형 데이터베이스 실전 입문 - 04. 정규화 논리(두 번째) - 결합 종속성

1. 결합 종속성(JD) 함수 종속성을 사용한 정규화는 후보키가 되는 속성을 찾아내는 작업이다. 그리고 이런 숨겨진 후보키가 발견됐을 때에는 릴레이션을 무손실 분해해 릴레이션 내부의 중복을

www.sunny-son.space

[RDBMS] RDB 정규화와 이상(Anomaly)현상의 개념 및 예시

코_노 — Wed, 3 Jan 2024 23:18:55 +0900

정규화(Normalization)란?

: 어떤 대상을 일정한 규칙이나 기준에 따르는 '정규적인' 상태로 바꾸거나, 비정상적인 대상을 정상적으로 되돌리는 과정을 뜻한다. 특히, RDB(관계형 데이터베이스)에서는, 이상 현상이 존재하는 릴레이션을 분해하여, 여러 개의 릴레이션으로 생성하는데, 이를 단계별로 구분하여 정규화 과정이 고도화될 수록 이러한 이상 현상을 줄일 수 있다.

그렇다면, DB에서의 '이상 현상(Anomaly)'이란 무엇일까?

불필요한 데이터 중복으로 인해 릴레이션에 대한 데이터 삽입, 수정, 삭제 연산을 할 때 발생할 수 있는 문제 또는 DB의 무결성을 저해하는 부작용을 말한다.

기본적으로 DB에서 말하는 이상 현상은 크게 다음과 같이 3가지이다.

삽입 이상(Insertion Anomaly)
삭제 이상(Deletion Anomaly)
갱신 이상(Update Anomaly)

1. 삽입 이상이란?

: 레코드를 테이블에 삽입할 때, 의도하지 않은 데이터까지 삽입을 해야만, 해당 레코드를 테이블에 추가가 가능한 현상

예시)

Q. 사원 테이블을 다음과 같이 구성했을 때, 새로운 부서에 대한 부서 이름만 추가하고 싶어요. 그런데, 주민등록번호가 기본키여서, Not null 제약조건이 걸려 있어요. 어떻게 해야 할까요?

잘못 구성한 [사원] 테이블

A. 그 [사원] 테이블을 둘로 쪼개세요! [사원] 테이블과 [부서] 테이블을 따로 관리하면 됩니다.

삽입 이상을 개선한 [사원] 테이블과 [부서] 테이블

2. 삭제 이상이란?

: 어떤 레코드를 삭제하면, 의도하지 않은 다른 데이터까지 삭제되어 버리는 현상

예시) [사원] 테이블

E_NAME	B_DATE	ADDRESS	D_NUMBER	D_NAME	D_MANAGER
정재호	2024.01.04	인천	101	IT팀 운영파트	이상철
홍인광	2024.01.04	김포	102	IT팀 개발파트	박종인
김가희	2023.05.01	서울 광진구	103	인사총무팀 인사파트	안주은
연동호	2003.01.03	파주	104	QA팀	김유이

Q. '김유이'라는 매니저가 퇴사해서, [사원] 테이블에서 '김유이'라는 데이터를 삭제하고 싶은데, 그러면 '연동호' 사원 데이터까지 모두 사라져버려요. 어떻게 해야 될까요?

A. 다음과 같이 [사원] 테이블과 [부서] 테이블로 나누세요!

[사원] 테이블

E_NAME	B_DATE	ADDRESS
정재호	2024.01.04	인천
홍인광	2024.01.04	김포
김가희	2023.05.01	서울 광진구
연동호	2003.01.03	파주

[부서] 테이블

D_NUMBER	D_NAME	D_MANAGER
101	IT팀 운영파트	이상철
102	IT팀 개발파트	박종인
103	인사총무팀 인사파트	안주은
104	QA팀	김유이

3. 갱신 이상이란?

: 중복된 데이터 중 일부만 수정되어 데이터 모순이 일어나거나, 한 데이터 수정이 불필요한 수많은 데이터 수정을 야기하는 현상

예시) [주문] 테이블 ver.1 (총 매출 : 38,000원 / 입금된 금액 : 38,000원)

주문자명	주문상품	상품 금액	배송지	배송상태
정재호	닭가슴살	10,000	인천	배송 중
정재호	닭가슴살	10,000	진천	배송 준비중
홍인광	고구마	3,000	김포	배송 중
홍인광	소고기	15,000	김포	배송 완료

[주문] 테이블 ver.2 (총 매출 : 78,000원 / 입금된 금액 : 58,000원)

주문자명	주문상품	상품 금액	배송지	배송상태
정재호	닭가슴살	20,000	인천	배송 완료
정재호	닭가슴살	20,000	진천	배송 완료
홍인광	고구마	3,000	김포	배송 완료
홍인광	소고기	15,000	김포	배송 완료
정재호	닭가슴살	20,000	인천	배송 준비중

Q. 미친 인플레이션 때문에 닭가슴살 가격을 10,000원 -> 20,000원으로 인상해야 해요. 그런데 이렇게 올리고 나면, [주문] 테이블을 기준으로 매출을 계산하는 저희 회사는, 입금된 금액이랑 총 매출이랑 맞지 않게 돼요. 어떻게 해야 할까요?

A. [상품] 테이블 [주문] 테이블을 나눠서 관리하세요! 그럼 상품 가격의 변동이 있을 때, [상품] 테이블에서의 '상품 가격' 컬럼만 수정하면, 상품 가격 변동 이전에 [주문] 테이블에 들어간 데이터는 변경되지 않을 수 있습니다.

[상품] 테이블

상품명	상품 가격
닭가슴살	20,000
고구마	3,000
소고기	15,000

[주문] 테이블 (총 매출 : 58,000원 / 입금된 금액 : 58,000원)

(닭가슴살 가격이 10,000 -> 20,000 원으로 인상되어도, 이전에 주문된 닭가슴살의 주문 금액은 바뀌지 않으므로, 입금된 금액이랑 총 매출이 다르게 될 위험이 없음.)

주문자명	주문상품	주문 금액	배송지	배송상태
정재호	닭가슴살	10,000	인천	배송 완료
정재호	닭가슴살	10,000	진천	배송 완료
홍인광	고구마	3,000	김포	배송 완료
홍인광	소고기	15,000	김포	배송 완료
정재호	닭가슴살	20,000	인천	배송 준비중

여기까지 봤다면, 이런 궁금증이 생길 것이다.

"대체 테이블을 쪼개는 기준이 뭐지? 그때그때의 상황마다 다른건가?

그런데, 그렇게 상황마다 테이블 스키마를 변경하려면 DB 작업 시간 잡느라 Downtime도 잡아야 하고, 컬럼을 늘릴 때 데이터 제약조건은 어떻게 잡을 지, 제약조건에 따른 Null값은 어떻게 처리할지, 만약 다른 상황이 생긴다면 설계된 테이블을 계속 쪼개기만 하면 되나...? 하아.. 이거 수정하는 거에 따라서 애플리케이션도 다 변경해야 하는데..."

와 같은 수많은 문제에 직면하게 된다.

이런 문제를 여러 번 경험한 데이터베이스 이론가들은 일종의 정규화에 대한 규칙이 고민하고 확립하게 된다.

이를 다음 포스팅에서 알아보도록 하자!

https://co-no.tistory.com/entry/RDBMS

참고

https://velog.io/@kon6443/DB-%EC%A0%95%EA%B7%9C%ED%99%94%EC%9D%98-%ED%95%84%EC%9A%94%EC%84%B1-%EB%B0%8F-%EA%B0%9C%EB%85%90

[DB] 정규화의 필요성 및 개념

정규화(Normalization)란 중복된 데이터 방지, 부모와 자식 데이터 간의 논리적 관계 유지, 에러 감소 및 재개발 비용 감소 등을 위해 존재한다.어려운 말로는, 테이블 간 중복된 데이터를 줄이며 데

velog.io

https://dev-coco.tistory.com/63

[DataBase] 이상 현상(Anomaly)이란?

좋은 관계형데이터베이스를 설계하는 목적 중 하나가 정보의 이상 현상(Anomaly)이 생기지 않도록 고려해 설계하는 것입니다. 이상 현상은 테이블을 설계할 때 잘못 설계하여 데이터를 삽입, 삭제

dev-coco.tistory.com

[Terraform] 테라폼을 통한 AWS 3-tier 구성 (1) - AWS CLI 설정 및 VPC 생성

코_노 — Fri, 29 Dec 2023 10:25:32 +0900

0. AWS CLI 및 AWS Configure

테라폼으로 aws 리소스를 관리하기 위해서는, 테라폼이 구동되는 동일한 환경 내에서 AWS CLI가 설치되어 있고, AWS CLI를 통해 모든 리소스의 접근 권한을 가진 AWS IAM User와의 연동이 필요하다. AWS 루트사용자와 동일한 권한을 가진 IAM User 설정이 되지 않았다면, 아래 포스팅을 참고하길 바란다.

https://co-no.tistory.com/entry/AWS-AWS-%EA%B0%80%EC%9E%85-%ED%9B%84-%EC%B4%88%EA%B8%B0-%EC%84%B8%ED%8C%851-IAM

[AWS] AWS 가입 후 초기 세팅 - IAM, Budgets 설정

IAM(Identity and Access Management)이란 무엇인가? : AWS를 사용하는 데에 가장 기초적인 서비스 중 하나로, AWS의 리소스들을 관리하고 권한을 설정하며, 각 리소스 간의 연계를 위해 필수적인 시스템이다

co-no.tistory.com

0.1. AWS CLI 설치

테라폼이 작동할 동일한 환경에서 AWS CLI를 설치해보자!

필자의 경우, 테라폼을 AWS와 전혀 상관 없는 개인 랩탑에서 사용할 것이고, WSL의 Ubuntu22.04 를 이용할 것이므로,

다음과 같이 진행한다.

# aws 공식홈페이지의 awscli-exe-linux-x86_64.zip 파일을 awscliv2.zip 파일로 내려받기
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

# 내려받은 압축 파일 압축 해제
unzip awscliv2.zip

# aws cli 설치
sudo ./aws/install

# aws cli 설치 완료 후, 버전 확인하여 설치 제대로 되었는지 확인
aws --version

0.2. AWS Configure 설정

다음 명령어를 통해, AWS CLI와 연동시키려는 AWS 환경에 대한 'AWS Access Key ID'와 'AWS Secret Access Key' 입력이 필요하다.

참고로, --profile 옵션을 주어, AWS CLI 상에서 해당 키 값을 프로필 config로 설정할 것이고, 이 프로필을 테라폼의 provider 설정에도 사용할 것이다.

리전은 한국에서만 테스트 할테니, 'ap-northeast-2'로 설정해주자. output format은 json으로 설정하여 범용적으로 사용해보자!

aws configure --profile [원하는 profile name]
# 필자의 경우, 'myAWSIAM' 이라고 프로필 이름을 설정

# AWS Access KEY ID [None] : <루트사용자와 동등한 권한의 IAM User 통해 발급받은 액세스 키ID>
# AWS Secret Access Key [None] : <루트사용자와 동등한 권한의 IAM User 통해 발급받은 private 액세스 키>
# Default region name [None] : ap-northeast-2
# Default outpu format [None] : json

# 생성한 프로필 목록 확인
aws configure list-profiles

# 프로필 지정에서 값이 잘 들어갔는지 확인하기 위한 해당 프로필의 region 값 확인하기
aws configure get region --profile [생성한 profile name]

# 생성한 프로필을 AWS CLI의 기본 프로필로 지정
export AWS_DEFAULT_PROFILE=[생성한 profile name]

위 과정을 마친 후, 아래 명령어를 수행하여 AWS CLI와 실제 AWS 환경과 연동이 잘 되었는 지 확인한다.

aws s3 ls

위 명령어는 연동한 AWS 환경에서의 S3에 'ls' 명령어를 날리는 것으로,

해당 AWS 환경에 S3가 셋업되어 있다면, 어떤 결과물이 출력될 것이고, 그게 아니라면 아무것도 나타나지 않을 것이다.

만약 "Invalid Access Key" 와 같은 에러가 나타난다면, 키 값이 잘못 입력되었거나, 유효하지 않은 키 값이므로 상황에 맞춰 이를 해결해야 한다.

1. AWS provider 셋업

테라폼이 AWS 서비스의 api 액세스를 하기 위해서는, 내가 구성한 AWS의 Key 값을 테라폼이 인식하여야 한다.

그 과정을 .tf 파일에 하드코딩으로 넣어두면 보안이 매우 취약해지니,

다음과 같이 테라폼 provider 파일에서 AWS CLI에서 설정한 프로필 네임을 가져오자.

# 테라폼 working 디렉토리로 이동 (필자의 경우, WSL 환경이므로, /mnt/c/Terraform 이라는 디렉토리를 만들었음.)
cd /mnt/c/Terraform

# provider.tf 작성 (vi provider.tf)
provider "aws" {
  profile = "myAWSIAM"
  region = "ap-northeast-2"
}

# terraform init을 통한 provider 환경 구축
# init 시에 등록되어 있는 'AWS_ACCESS_KEY_ID', 'AWS_SECRET_ACCESS_KEY', 'AWS_DEFAULT_REGION' 환경변수를 읽어옴.
terraform init

terraform init 성공시 나오는 메시지

2. VPC 생성을 위한 테라폼 resource 파일 작성

# vpc.tf

resource "aws_vpc" "VPC_TEST" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = "true"
  instance_tenancy     = "default"
  
  
  tags = {
    Name = "3-Tier 구성을 위한 테스트 VPC"
  }
}

cidr_block : VPC의 IP주소 대역을 Classless Inter-Domain Routing(CIDR) 표기법을 사용하여 설정하는 것
참고로, AWS에서는 VPC의 10.0.0.0 대역은 10.0.0.0/16 ~ 10.0.0.0/28 까지만 지원한다.
enable_dns_hostnames (Optional) : VPC가 Public IP 주소가 있는 인스턴스에 대해서는 Public DNS hostnam을 할당하는 것에 대한 지원 여부를 결정하는 옵션. Default는 false
instance_tenancy : VPC 내부에서 동작하는 인스턴스에 대한 테넌시 옵션.
- default : 인스턴스가 기본 테넌시로 배치됨 = 인스턴스가 공유 호스트에 배치됨 = 사용자가 누구인지 상관없이 AWS의 인스턴스가 모두 한 동일한 물리적 하드웨어에 배치된다는 의미
- dedicated : 인스턴스가 전용 테넌시로 배치됨 = 특정 유저별로 인스턴스가 위치하는 물리적 하드웨어가 달라짐
- host : 인스턴스가 전용 호스트 테넌시로 배치됨 = 어떤 인스턴스도 들어갈 수 없는, 한 호스트만을 위한 물리적 하드웨어에 인스턴스가 배치됨

**3. resource 파일 작성 후, terraform plan 으로 resource 파일 디버깅 및 apply 준비**

resource 파일 작성이 완료되었다면, 아래 명령어를 수행하여 .tf 파일의 문법 오류나 문제가 되는 부분이 없는지 검증한다.

terraform plan

위에서 작성한 vpc.tf의 plan이 성공적으로 이루어졌다면, 아래 이미지와 같은 문구가 출력될 것이다.

트러블슈팅)

필자의 경우, 아래와 같은 "Invalid provider configuration" 에러와 "No valid credential sources found" 에러가 나왔다.

aws configuration 과정을 빼먹어서 그런 듯 하다.

Provider "registry.terraform.io/hashicorp/aws" requires explicit configuration 에러

위 에러 해결방법은 0.AWS CLI 및 AWS Configure 과정을 다시 진행해보길 바란다.

4. terraform apply 수행하여 실제 AWS에 VPC 생성하기

위 plna 과정이 정상적으로 되었다면, 아래 명령어를 수행하여 실제 나의 AWS 환경에 VPC를 구축해보자!

terraform apply

명령어를 수행하면 다음과 같은 문구들이 출력되고, 'yes'라는 값을 입력하라고 나올 것이다.

그럼 'yes'라고 입력하고 terraform apply가 성공적으로 수행되었을 때, "Apply complete! Resources: [수] added" 라는 문구가 출력될 것이다!

테라폼을 통해 AWS의 VPC가 성공적으로 구축되었다면, 실제 나의 AWS에 접속하여 VPC가 생성되었는지 다음과 같이 확인해주자.

실제 AWS에서도 VPC가 잘 생성된 것을 확인할 수 있다!

여기까지 하면 테라폼을 통해 VPC를 성공적으로 생성한 것이다.

다음 포스팅을 통해 3-tier 구축을 위한 Subnet, IGW, NAT Gateway, Route Table, Network ACL을 구성해 보자!

참고

https://aws.amazon.com/ko/cli/

Command Line Interface - AWS CLI - AWS

aws-shell은 명령줄 셸 프로그램으로서, AWS 명령줄 인터페이스를 사용하는 새로운 사용자와 고급 사용자 모두에게 도움이 되는 편의 기능 및 생산성 기능을 제공합니다. 주요 기능은 다음과 같습

aws.amazon.com

https://engmisankim.tistory.com/68

terraform 을 통한 클라우드 인프라 관리

AWS의 클라우드포메이션처럼 AWS를 포함한 여러 클라우드 환경 및 컨테이너 환경의 인프라를 제어할 수 있는 infrastructure as code 도구인 terraform을 이용하여 AWS 인프라를 제어하는 방법에 대해 공유

engmisankim.tistory.com

https://cloudbim.tistory.com/14

#010) 테라폼 terraform 으로 VPC, EC2 생성하기

https://www.terraform.io/intro What is Terraform | Terraform by HashiCorp Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. www.terraform.io 사이트로 가서 테라

cloudbim.tistory.com

https://gurumee92.tistory.com/230

04장. Terraform으로 AWS 관리하기 (01) AWS 준비하기

이번 장은 추후 진행될 실습을 위해서 Terraform으로 AWS 리소스들을 관리하기 위한 준비 작업을 진행한다. 이를 위해서 AWS CLI를 설치하고 AWS의 모든 리소스의 접근을 할 수 있도록 해당 권한을 가

gurumee92.tistory.com

https://developer.hashicorp.com/terraform/language/modules/develop/structure

Standard Module Structure | Terraform | HashiCorp Developer

Learn about the recommended file and directory structure for developing reusable modules distributed as separate repositories.

developer.hashicorp.com

[Terraform] Terraform 개념, Architecture, 설치

코_노 — Thu, 28 Dec 2023 11:41:51 +0900

Terraform이란?

: 테라폼(Terraform)은 하시코프(Hashicorp)에서 오픈소스로 개발 중인 *IaC 도구로, 인프라를 안전하고 효율적으로 구축, 변경, 버전 관리할 수 있게끔 한다. 여기에서 말하는 인프라는, 컴퓨팅 인스턴스, 스토리지, 네트워킹과 같은 low-level 컴포넌트와 DNS 항목 및 SaaS 기능과 같은 High-level의 컴포넌트를 모두 포함한다.

*IaC(Infrastructure as Code) : 수동 프로세스가 아닌, 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말한다.

Terraform의 Arhictecture

Terraform Architecture / 출처 : https://spacelift.io/blog/terraform-architecture

Terraform Core

: Terraform CLI라고도 하는 Terraform Core는 Go 언어를 사용하여 개발된 정적으로 컴파일된 바이너리를 기반으로 만들어졌다.

이 바이너리는 'terraform' 이라는 CLI 도구를 생성하며, 이 CLI 도구가 테라폼 사용자를 위한 기본 인터페이스 역할
이 바이너리는 오픈 소스이며, Terraform GitHub 리포지토리를 통해 접근 가능

Terraform Provider

: Terraform provider는 테라폼이 다양한 범주의 서비스 및 리소스와 통신을 가능하게끔 해주는 모듈이다. 이러한 서비스 및 리소스는 단순히 Cloud providers, 데이터베이스, DNS 서비스 등으로만 제한되지 않는다.

각 Provider는 특정 서비스 내에서 Terraform이 관리할 수 있는 리소스에 대한 정의 및 Terraform configuration 내용을 해당 서비스에 대한 특정 API 호출로 변환하는 역할을 가지고 있다.
Provider는 AWS, Azure, Goolge Colud와 같은 주요 클라우드 공급자에 의해 개발된 서비스 및 리소스는 물론이고, community-supported provider를 통해 다양한 서비스에 대해서도 사용이 가능하다.

State file

: state file은 테라폼의 기능 중 필수 요소로, 테라폼이 관리하는 리소스 정보뿐만 아니라, 리소스에 대한 현재 상태, 종속성 등을 저장하는 JSON 파일이다.

Terraform은 State file을 활용하여 새로운 테라폼 configuration이 적용될 때에 실제 인프라 리소스에 반영되어야 할 변경사항을 결정한다.
State file은 Terraform Core를 실행하는 Machine에 로컬로 보관할 수도 있고, Azure 스토리지 계정, AWS S3, 하시코프 Consul과 같은 원격 백엔드를 사용하여 원격으로 보관할 수도 있다.
State file에는 현재 관리 중인 인프라에 대한 민감한 정보가 포함되어 있으므로, 안전하게 보호 및 보관되어야 하고, 자주 백업하는 것이 좋다.

Terraform Provisioners

: 새로 생성된 리소스나 인스턴스에 대해 스크립트나 명령을 실행할 수 있도록 하는 기능. 여기에 사용되는 스크립트는 인프라 설정 및 구성, 소프트웨어 설치, 테스트 실행, 기타 필요한 작업 수행 등의 다양한 용도로 사용될 수 있음.

Provisioner는 리소스가 생성된 후에 실행되며, 리소스가 파괴될 때에 트리거되는 것도 가능하다.
테라폼에는 해당 리소스에 파일을 복사하기 위한 file provisioner와 원격 명령 실행을 위한 remote-exec provisioner를 비롯한 여러 가지 기본 제공 provisioner가 포함되어 있다.
또한, 더 다양한 유즈케이스에 대한 커스텀 provisioner를 생성하는 것도 가능하다. 그런데 이러한 커스텀 provisioner는 테라폼에 존재하는 기존 리소스 블록으로 원하는 결과를 얻을 수 없는 경우에 최후의 수단으로 사용하는 것이 좋다.

Terraform의 동작 방식

Write : 다수의 클라우드 provider 및 서비스에 걸쳐 있을 수 있는 리소스에 대해서 정의하는 단계
ex) 보안 그룹과 로드밸런서가 있는 VPC(Virtual Private Cloud) 네트워크 안에 있는 VM에 애플리케이션을 배포하도록 configuration 생성
Plan : 기존 인프라와 사용자가 작성한 configuration을 기반으로, 인프라스트럭처에 생성, 업데이트 ,삭제에 관한 실행 계획을 테라폼이 생성하고 리뷰하는 단계
Apply : Plan에 대한 리뷰 승인 후, 리소스에 대한 종속성을 고려하여 Plan에서 제안된 작업을 올바른 순서대로 수행하는 단계
ex) VPC의 property값과 VPC 내부의 VM 개수를 변경한다고 가정하면, 이 apply 단계에서 테라폼은 VM 스케일링 작업 이전에 VPC를 먼저 다시 만든다.

다음은 테라폼 설치에 대해 알아보자!

필자의 경우, AWS의 다양한 리소스를 프로비저닝하기 위해 테라폼을 사용할 것이며, 사용 환경에 별도의 VM을 만들지 않고, 윈도우에서 제공하는 WSL을 이용하여 ubuntu 22.04 의 리눅스 OS 환경을 구성 후, 테라폼을 실행할 예정이다.

따라서 아래 Linux 기반으로 수행되는 명령어들은 모두 ubuntu 22.04 임을 참고하자!

Terraform 설치

https://developer.hashicorp.com/terraform/install?product_intent=terraform

Install | Terraform | HashiCorp Developer

Explore Terraform product documentation, tutorials, and examples.

developer.hashicorp.com

Terraform 공식 홈페이지의 Download 페이지(위 링크)로 가면, Linux에서 테라폼을 설치하는 방법이 나온다. 다음과 같이 명령어를 수행해 주자.

# 미리 생성해둔 Terraform 디렉토리로 이동하여 명령어 수행
# Terraform 디렉토리는 어디에 놔도 상관 없음

# 테라폼 설치
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

# 테라폼 설치 완료 확인(버전 확인)
terraform version

설치된 Terraform 버전 확인

이렇게 버전 확인이 된다면, 테라폼 설치가 완료된 것이다!

참고

https://developer.hashicorp.com/terraform/intro

What is Terraform | Terraform | HashiCorp Developer

Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently.

developer.hashicorp.com

https://spacelift.io/blog/terraform-architecture

Terraform Architecture Introduction - Structure and Workflow

See the beginner friendly introduction to Terraform architecture and it's several key components.

spacelift.io

[AWS] AWS 가입 후 초기 세팅 - IAM, Budgets 설정

코_노 — Thu, 28 Dec 2023 08:30:03 +0900

IAM(Identity and Access Management)이란 무엇인가?

: AWS를 사용하는 데에 가장 기초적인 서비스 중 하나로, AWS의 리소스들을 관리하고 권한을 설정하며, 각 리소스 간의 연계를 위해 필수적인 시스템이다.

가장 기초적으로 세팅해야 하는 서비스이고, 유저 로그인, 유저 간 권한 관리, 패스워드 설정, 리소스 간 연계 시 권한 등의 세밀한 설정이 가능하다.

AWS를 가입한 후에, 처음 다시 로그인하게 되면, 아래와 같은 창을 확인할 수 있다.

IAM이란 것을 설정하기 전에는 '루트 사용자'에 체크하고, 처음 가입할 때 넣었던 이메일 주소로 로그인할 텐데, 이 '루트 사용자'는 Linux의 root 라고 생각해보면 된다.내가 만든 AWS 시스템의 모든 권한을 다 가지고 있다는 것이다.
특히 돈과 관련된, billing과 관련된 모든 설정을 변경하는 것도 가능하므로, 가능한 한 IAM을 만들어 해당 IAM 계정으로 로그인을 하고, 루트 사용자는 MFA를 적용하고, 반드시 필요할 때만 사용하도록 하는 것이 보안상 필수적으로 필요한 과정이다.

AWS 로그인 화면

1. [IAM user and role access to Billing information] 활성화

IAM 계정을 생성하기 전, 해당 옵션을 루트 사용자에서 활성화함으로써, IAM 유저가 billing과 관련된 설정에 접근할 수 있도록 해야 한다.

1.1. [Account] 메뉴 진입

아래 그림처럼 AWS에 가입한 사용자로 로그인(루트 사용자)을 한 후, 계정 옆 [화살표] - [Account] 를 클릭한다.

1.2. [IAM user and role access to Billing information] - [Edit] 버튼 클릭

Account 메뉴에서 보면, [IAM user and role access to Billing information] 이 보일텐데, 이 설정을 활성화 해줌으로써, 루트 사용자가 아닌 특정 IAM 사용자가 Billing 및 Cost와 관련된 관리 설정에 접근할 수 있도록 한다.

우리는 최종적으로 루트사용자 최대한 사용하지 않도록 할 것이므로, 특정 IAM 사용자는 Billing 및 Cost와 관련된 관리 설정에 접근할 수 있도록 해야 한다.

1.3. 'Activate IAM Access' 체크 - [Update] 버튼 클릭

2. MFA 등록

여기에서 등록하는 MFA는, [IAM Identity Center]에 대한 MFA가 아닌, [IAM]에 대한 MFA임을 주의하자.

여기에서 MFA를 등록하면, 루트 사용자에 대한 MFA도 등록되어, 루트 사용자로 함부로 로그인되는 것을 막을 수 있다.

2.1. [서비스 검색] 란에서 'IAM' 이라고 검색 - [IAM] 서비스로 접근

2.2. MFA 추가

2.3. MFA 추가 시 필요한 정보 입력

Device name에는 필자가 알아보기 쉽게 Galaxy S23 등으로 지정하였고, 인증 수단을 3가지 중에 선택할 수 있는 데, 필자의 경우, [Authenticator app]을 선택하여 Google의 Authenticator App으로 등록하였다.

3. IAM 생성

3.1. [서비스 검색] 란에서 'IAM' 이라고 검색 - [IAM] 서비스로 접근

3.2. [IAM] 서비스 - [Users] 메뉴 선택 - [Create user] 클릭

3.3. [User name]에 원하는 로그인 name 입력
- 'Provide user access to the AWS Management Console' 체크(루트사용자와 동등한 권한 갖게 하기 위함)
- 'Specify a user in Identity Center' 클릭

그럼 아래와 같은 창이 뜰텐데, 'Manage in Identity Center' 를 클릭해준다. ~~(아놔, 결국 AWS Identity Center 콘솔에서 다시 계정 추가를 해줘야 하나보다.)~~

[IAM Identity Center]에서 생성한 IAM 계정은, 여기에서 공유되는 특정 Access URL을 통해서만 해당 AWS 서비스로 접근이 가능하다. 이 점을 유의하고 [IAM Identity Center]와 [IAM]을 구분하자!

3.4. 'Enable IAM Identity Center'의 [Enable] 버튼 클릭

3.5. [Enable with AWS Organizations] 선택 - [Continue] 버튼 클릭

3.6. IAM Identity Center 활성화 후 - [IAM Identity Center] 웹 콘솔 진입
- [Users] 메뉴 클릭 - [Add user] 버튼 클릭

3.7. 유저 생성 양식 작성

필자는 [Primary information]을 모두 작성한 후에, 추가로 [Preferences]의 'Nickname'과 'Timezone'만 설정해 주었다.

이렇게 하고 넥스트~ 넥스트~ 눌러주면, [IAM Identity Center] 웹 콘솔의 홈 화면으로 이동하면서, 아래와 같은 메시지가 상단에 노출될 것이다.

[Primary information]에 입력한 이메일을 확인하여, 인증 과정을 마쳐야만 IAM 유저가 정상적으로 추가된다.

메일에서 Accept를 클릭해주면, 해당 IAM 계정으로 로그인되고, 새로운 비밀번호를 설정하는 창으로 리다이렉션된다.

거기에서 새로운 비밀번호로 설정해주자.

그리고 아직 루트사용자 로그인은 로그아웃하지 말자!!

3.8. [IAM Identity Center] 웹 콘솔 - [Groups] 메뉴 - [Create group] 버튼 클릭

3.9. [Create Group] 화면에서 Group name 설정 - [Add users to group] 에서 생성한 계정 추가

필자는 그룹명을 'Administrators'라고 지었는데, 이건 원하는대로 아무렇게나 지어도 된다.

3.10. [IAM Identity Center] 웹 콘솔
- [Multi-account permissions]의 [AWS accounts] 메뉴
- 3.7.에서 생성한 계정 선택 - [Assign users or groups] 버튼 클릭

우리가 추가한 계정 및 그룹이 루트 사용자의 권한처럼 로그인하려면, 루트 사용자 하위에 'management account'에 대한 Multi-account permission이 필요하다.

3.11. Multi-account permission을 추가할 [IAM Identity Center]의 계정 및 그룹 선택

3.12. [Select permissions sets] 화면 - [Create permissions set] 클릭

위 [Create permissions set] 버튼을 클릭하면 창이 하나 뜨는데, 다음 이미지와 같이 진행하자.

[Types] 에서 'Predefined permissions set' 을 선택하고, [Policy for predefined persmission set] 에서 'AdministratorAccess'를 선택하면 루트사용자와 동일한 권한을 가지게 된다.

이 다음 Step 2인 [Specify permission set details] 에서도 디폴트로 설정되어 있는 것을 그대로 두고, [Next] 버튼을 클릭하자.

역시 그다음 Step 3인 [Review and create] 에서 [Create] 버튼을 클릭하면 [permissions set]이 생성 완료된다.

[Assign users and groups] 창으로 돌아와, 새로고침 버튼을 눌러주면 다음과 같이 'Permission set'이 생긴 걸 확인할 수 있고, 이를 체크하고 [Next]버튼 클릭 - 다음 Step 3 [Review and submit]에서 [Submit] 버튼 클릭하면 된다.

그럼 다음과 같이 성공 문구와 함께 AdministratorAccess 권한이 들어간 것을 볼 수 있다.

3.13. 인증 메일 통해서 리다이렉션 되는 로그인 화면에서 로그인

인증 메일의 링크를 클릭하면, AWS 로그인 창으로 리다이렉션 되는데, 여기에서 IAM Username과 Password를 입력하여 로그인 성공 되는 것을 확인하면 된다.

그리고 이때, MFA를 또 등록하게 되는데, 이 MFA는 IAM 전체(?)에 대한 MFA와 별개이므로, 별도로 또 등록을 해주는 것이 맞다.

또 한가지 주의할 점은, [IAM Identity Center]를 통해 생성한 계정은, 아래 그림에서 보이는 'AWS 액세스 포털 URL'을 통해서만 로그인이 가능하다는 것이다. 따라서 저 액세스 포털 URL을 Admin만이 아는 어떤 곳에 잘 복사해두고 사용하도록 하자!

Budgets이란 무엇인가?

: AWS에서 제공하는 유동적인 예산 및 예측 기능으로, 비용적인 측면에서의 계획 및 비용 제어 과정을 개선할 수 있는 서비스이다.

사용자 지정 예산을 통해 비용, 사용량, 적용 범위를 추적할 수 있다.
지출 및 리소스 사용에 대한 예측 정보를 계속 제공받을 수 있다.
사용자 지정 작업을 생성하여 초과 요금, 비효율적인 리소스 사용 또는 적용 범위 부족을 방지할 수 있다.

AWS에 대한 학습은 최대한 프리 티어를 이용할 것이기 때문에,

0.01$ 이상의 비용이 발생하면 메일로 알림을 오도록 설정할 것이다.

4. Budgets 설정

4.1. [Account] - [Billing and Cost Management] 화면에서 [Budgets] 메뉴 클릭 - [Create a budget] 버튼 클릭

4.2. Budgets 양식 작성

친절하게도, Budgets 생성을 하면 'Zero spend budget' 이라는 템플릿이 이미 있어, 해당 템플릿으로 적용하면 AWS 프리 티어 초과 사용량에 대한 0.01$ 이상의 비용이라도 발생하면 알림을 발생할 수 있게 해준다.

4.3.생성된 Budgets 확인

그럼 다음과 같이 생성된 것을 확인할 수 있다!

참고

https://jodev.kr/entry/AWS-AWS-%EA%B0%80%EC%9E%85-%ED%9B%84-%EC%A0%9C%EC%9D%BC-%EB%A8%BC%EC%A0%80-%ED%95%B4%EC%95%BC%ED%95%A0-%EC%9D%BC

[AWS] AWS 가입 후, 제일 먼저 해야할 일

본 글은 AWS에서 제공하는 AWS Documentation (user guides, developer guides, API references, tutorials, etc)를 참고하여 작성하였습니다. https://docs.aws.amazon.com/ IAM (Identity and Access Management) AWS에서는 IAM (Identity and Acce

jodev.kr

https://growth-coder.tistory.com/115

[AWS] Identity Center를 활용한 관리자 IAM 사용자 생성 (관리자 IAM 사용자를 사용하는 이유)

이전 포스팅에서 AWS에서 S3 스토리지를 생성하고 업로드 및 정책 설정을 해보았다. 루트 사용자 계정으로 콘솔에서 S3 스토리지를 생성하고 사용해보았는데 실제로는 이렇게 사용하는 경우가 많

growth-coder.tistory.com

https://aws.amazon.com/ko/aws-cost-management/aws-budgets/

사용자 지정 비용 및 사용 예산 설정 - AWS Budgets - Amazon Web Services

AWS Budgets를 사용하면 사용자 지정 예산을 설정하여 비용 및 사용량을 추적하고, 임계값 초과 시 이메일 또는 SNS 알림에서 수신된 알림에 빠르게 대응할 수 있습니다.

aws.amazon.com

[개념] DDD와 SQL 중심 설계 (feat. ORM과 SQL Mapper)

코_노 — Thu, 28 Dec 2023 00:00:25 +0900

데이터 모델링의 원칙 등을 공부해서 정리하려다가, 실무적으로 접근할 필요가 있을 것 같아, 최근 웹 개발의 90% 이상을 차지하고 있는(~~국내 대기업도 이정도일까...?~~) DDD 설계와 정통적인 방법인 SQL 중심 설계의 차이점을 먼저 정리해보고자 한다.

이번 포스팅은 더더욱이 DDD, ORM, DB 설계 등의 매우 깊은 내용을 담고 있기에, 내가 쓰는 내용이 틀릴 확률이 상당히 높다.

그러니 읽으시는 독자 분들께서 틀린 내용이 있다면, 꼭 지적해주셨으면 한다.

DDD(Domain Driven Design)란 무엇인가?

: Domain의 사전적 의미는 '영역, 집합'으로, 비즈니스 Domain에 기반한 애플리케이션의 디자인 패턴을 말한다.

여기서 비즈니스 Domain이란, 유사한 업무의 집합을 의미한다.

도메인은 다시 하위의 여러 도메인으로 나누어지곤 하는데, 예를 들면 아래 이미지와 같다. '온라인 쇼핑' 도메인은 '상품',' 주문', '회원'과 같은 하위 도메인으로 나뉘고, 이 중 '주문' 도메인은 다시 '주문자', '주문 상품', '배송'과 같은 하위 도메인으로 나눠질 수 있다.

'온라인 쇼핑' 도메인과 그의 하위 도메인 / 출처 : https://medium.com/myrealtrip-product/what-is-domain-driven-design-f6fd54051590

여기서 '집합'이라는 의미에 좀 더 초점을 두고 싶다. 필자가 생각하기에, 기존의 데이터 기반 설계(SQL 기반 설계)와 비교하면, 데이터가 RDBMS의 특징을 잘 살려 어떻게 저장될 지는 설계 과정에서 크게 고려하지 않고,

데이터가 처리되는 단위들 즉, 비즈니스를 애플리케이션 로직으로 어떤 단위로 어떻게 처리할 지를 기준으로 설계하는 방식으로 보인다.

DDD는, 기존의 애플리케이션 설계가 비즈니스 Domain에 대한 이해가 부족한 상태에서 설계 및 개발되었다는 반성에서 출발하게 된다. 그렇기에, DDD에서는 기존의 현업->IT로의 일방향 소통 구조를 탈피함으로써, 현업<->IT 라는 쌍방향 커뮤니케이션을 매우 중요하게 생각하는 철학이 담겨 있다.

DDD의 특징

기존에 많이 사용되어 왔던 '데이터' 중심의 접근법을 탈피하여, 순수한 도메인의 모델과 로직에 집중한다.
*유비쿼터스(Ubiquitous, 보편적인) 언어를 사용하는 걸 원칙으로 한다.
이는, 도메인 전문가(현업 전문가)와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고, 양쪽 모두가 직관적으로 이해할 수 있으며, 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어 체계를 구축해 나가는 과정을 말한다. 이로써, 분석 작업과 설계 그리고 구현에 이르기까지 통일된 방식으로 커뮤니케이션이 가능해지는 것을 지향한다.
소프트웨어 엔티티(Entity)와 도메인 Concept을 가능한 한 가장 가까이 일치시키는 것을 목표로 한다.
분석 모델과 설계가 다르고, 그로 인해 비즈니스 요구사항과 실제 코드가 다른 구조로 진행되는 것이 아니라, 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향하는 것이 DDD의 핵심 원리이다.
DDD의 소프트웨어 아키텍처 측면에서의 핵심 목표는, "Loosly coupling, High cohension" 으로, 애플리케이션 또는 작은 단위의 모듈 각각은 서로간 의존성을 최소화시키고, 응집도는 최대화하는 것이다.

*유비쿼터스 언어(Ubiquitous Language) : 도메인에서 사용하는 용어를 코드에 반영하지 않으면, 그 코드는 개발자에게 코드의 의미를 해석해야만 하는 부담을 준다. 보편적인 언어를 사용함으로써, 개발자로서는 코드의 가독성을 높여 코드를 분석 및 이해하는 시간을 절약하고, 도메인 전문가와의 소통의 어려움을 많이 낮춘다.
또한, 도메인 전문가와 소통하며 용어가 정의될 때마다 용어 사전에 이를 기록하여 명확히 정의함으로써, 다른 사람이 이 프로젝트에 합류하여도 공통된 언어를 사용할 수 있도록 도와준다.

DDD를 올바르게 설계하고 이행하려면, 다음과 같은 과정을 거치게 된다.

핵심 도메인을 나누고, 해당 도메인에 집중한다.
각각의 도메인을 정교하게 구축하고 세분화한다.
해당 도메인의 문제를 해결할 수 있는 전문가와 적극적인 협업을 한다.

위와 같은 과정에서 다음과 같이 전략적 설계와 전술적 설계의 단계로 나뉘게 된다.

DDD의 전략적(Strategic) 설계와 전술적(Tactical) 설계

전략적 설계(Strategic Design)

*Model과 **Bounded Context를 나누는 설계로, 협업을 위한 Ubiquitous Language의 정리도 여기에 포함된다.

현실에서의 개념을 시스템 상의 코드로 구현하기 전, 모델들 사이의 상호작용을 고려하여 인터페이스 등을 정의하거나,
전체적인 흐름을 파악하고 경계를 나누면서 여러 문제를 명확히 이해할 수 있도록 하는 과정이다.

전술적 설계(Tactical Design)

시스템 상에서 실제 구현하기 위한 세부 아키텍처를 설계하는 단계로, 코드의 구현과 직접적으로 연관된 부분이며,
전략적 설계에서 나뉜 경계와 모델 등을 유지보수성과 확장성을 고려하여 코드를 구성하는 등의 작업 과정을 말한다.

데이터 흐름 등을 고려한 세부적인 설계를 수행하고, 구현 과정에서 발생할 수 있는 다양한 문제들을 해결하며,
코드의 유연성과 유지보수성을 개선시키는 과정이 핵심이다.

*Model(모델) : 도메인에 대한 이해화 복잡성을 해결하기 위해 해당 도메인의 규칙, 개념, 프로세스 등을 포함하는 추상적 개념. 각각의 모델은 서로 간 경계가 확실해야 하며, 개발자와 해당 도메인 전문가가 함께 구축해 나가야 하는 개념.

**Bounded Context(바운디드 컨텍스트) : 같은 용어라도 어떤 도메인인지에 따라 의미가 다르고, 용어가 다름에도 서로 다른 도메인 간 비슷한 역할을 하는 용어들이 있다. DDD의 철학을 위배하지 않으려면, 각 모델은 명시적으로 구분되는 경계를 가짐으로써 서로 섞이지 않아야 하는데, 이렇게 섞이지 않는 특정한 Context 내에서의 완전한 의미를 갖도록 하는 경계를 Bounded Context라고 한다.
(ex) [카탈로그] 도메인에서의 '상품' - [재고 관리] 도메인에서의 '상품' / [회원] 도메인에서의 '회원' - [주문] 도메인에서의 '주문자')

SQL 중심 설계란 무엇인가?

: SQL-DD(SQL Driven Design)이란, RDBMS 측면(인프라적 측면)에서의 데이터베이스 구조와 데이터의 흐름을 중심에 놓고 설계하는 패턴을 말한다.

정통적인 거의 모든 애플리케이션의 전형적인 설계 패턴이었으며, 이는 DB가 올라가는 물리적 서버의 스펙이 가장 좋았기 때문에, 대부분의 비즈니스 로직 처리를 DB 쿼리로서 처리하고자 한 것에서 기인한 걸로 보인다.

SQL-DD의 특징

데이터베이스에 대한 전문적인 지식이 있다면, 도메인 모델과 관계형 데이터베이스 간의 일관성을 유지하여 도메인 모델링과 관계형 데이터베이스 설계 간의 간극을 줄이는 것이 가능하며, 이것이 곧 목적이기도 하다.
데이터에 초점을 두고 설계를 하기 때문에, 애플리케이션 로직에서는 객체 자신이 포함하고 있는 데이터를 조작하는 데에 필요한 행동을 정의하여야 한다.
설계 시, 협력에는 큰 중요성을 두지 않았기 때문에, 과도한 접근자와 수정자가 탄생하게 된다. 이는 결과적으로, 애플리케이션 구현에 있어 대부분의 객체 구조 및 구현이 노출되므로, 캡슐화의 원칙을 위반하게 된다. 따라서, API를 설계하고 공개하는 것도 불가능하게 된다.
추상적인 개념 대신 직관적인 데이터를 위주로 개발이 가능하며, 직관적인 SQL 쿼리 작성으로 빠른 개발이 가능하다.
But, DB에 대한 낮은 이해로 인해 마구잡이로 개발되어 오히려 서비스 전체의 성능을 악화시키는 요인이 되기도 한다.
역정규화를 통해 도메인 모델과 데이터베이스 구조 간의 일관성을 유지할 수 있으며, 이에 따른 개발 생산성과 성능을 높일 수 있다.
But, 역정규화를 거듭할수록 중복된 코드의 양이 늘어나거나 데이터 무결성을 저해할 가능성이 높아질 수 있다.
또한, 데이터의 일관성, 코드 컨벤션의 유지가 역정규화가 이뤄질수록 어려워지기 때문에, 유지 보수의 어려움과 Scale-out의 어려움, 그에 따른 성능에 악역향을 불러올 수도 있다.
서비스 자체가 동적인 변화가 잦다면, 대응이 매우 어렵다. 예를 들면, '학생', '교사' 이외의 '교환학생', '강사' 라는 도메인이 추가된다면, 새로운 DB 스키마가 필요하며, 그에 따라 모든 쿼리문 및 애플리케이션 로직의 수정이 불가피할 수 있다.

여기까지 잘 읽었다면, 어려운 개념을 소화해 낸 당신 참 대단하다는 말을 해주고 싶다.

아키텍처 관점에서의 모델링이 어떻게 되는 지를 알았다면, 이 모델링 결과가 애플리케이션에서 어떤 것을 통해 활용되는 지를 알아야, 모델링을 더 잘 수행할 수 있을 것이라 생각한다.

그래서 모델링의 결과를 개발 과정에서 '어떤 것'을 통해 활용하는지, 그 '어떤 것'이 무엇인지 확인해보도록 하자!

ORM(Object Relational Mapping)이란 무엇인가?

: 객체-관계 매핑으로, 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑해주는 것을 말한다.
Java 진영에서는 가장 대표적으로 JPA(Java PersistAnce)가 있다.

객체 지향 프로그래밍(특히 Java)은 클래스를 사용하고, 관계형 데이터베이스는 테이블을 사용한다.
이에 따른, 객체 모델과 관계형 모델 간 불일치가 필연적으로 존재하게 된다.
이에 대한 해결책으로 나온 것이 ORM으로, 객체 간의 관계를 바탕으로 SQL을 자동으로 생성하여
이러한 불일치 문제를 해결한다.
Persistant API라고도 하는데, 여기서 말하는 Persistant(영속적인) 즉, Persistance(영속성)란, 다음과 같다.
- 영속성(Persistance) : 데이터를 생성한 프로그램이 종료되더라도, 그 데이터는 사라지지 않는 데이터의 특성을 의미.
장점)
- 객체 지향적인 코드로 인해 더 직관적이고 비즈니스 로직에 더 집중할 수 있게 도와줌
  => SQL 쿼리가 아닌, 직관적인 코드(메서드)로 데이터를 조작하게 됨.
- 재사용 및 유지보수의 편리성이 증가함
  => ORM은 독립적으로 작성되어 있으며, 해당 객체들을 재활용할 수 있음. (객체의 특징)
- DBMS에 대한 종속성이 줄어듦
  => DBMS에 따른 자료형의 종속성에서 많이 벗어날 수 있으며, 이기종 DB 사용가능.
단점)
- 100% ORM만으로 서비스를 구현하기는 어려움
  => 설계부터 매우 신중해야 하기 때문에, 100% 완벽한 설계는 존재할 수가 없으며, 프로젝트의 복잡성이 커질 경우 난이도 또한 올라가게 됨.
- 프로시저가 많은 시스템에서는 ORM의 객체 지향적인 장점을 활용하기가 어려움
  => 이미 프로시저가 많은 시스템에서는, 해당 프로시저를 구현하는 데에 필요한 객체들을 다시 설계하고 바꿔야 하므로, 생산성 저하 및 리스크가 발생할 수 있음.

SQL Mapper란 무엇인가?

: 객체와 관계형 데이터베이스의 데이터를 개발자가 작성한 SQL로 매핑시켜주는 프레임워크.

대표적으로 MyBatis 라는 프레임워크가 있다.

ORM과 동일한 기능으로 보이나, 가장 큰 차이점은 이 프레임워크에서 객체와 관계를 매핑하여 사용하기 편한 메서드 등을 제공해주는 것이 아닌, 개발자가 직접 작성한 SQL문의 결과와 객체의 필드를 매핑하여 데이터를 객체화 시킨다는 점이다.
장점)
- JDBC를 사용했을 때 발생하는 불필요한 코드들을 줄일 수 있다. (Connection 관리, Checked Exception 처리 등)
- DAO로부터 SQL문을 분리함으로써, 코드의 간결성 및 유지보수성을 향상할 수 있다.
- DBMS에 대한 지식이 해박하다면, 쿼리를 직접 작성하여 그대로 적용할 수 있으므로, 복잡한 JOIN, 튜닝 등을 좀 더 수월하게 작성이 가능하다.
단점)
- SQL문을 직접 모두 작성해야 한다.
  => DB 설정 변경 또는 DBMS가 바뀔 시, 수정할 부분이 너무나도 많아지게 된다.
- 객체 모델과 관계 모델을 각각 따로 개발해야 함으로써, 유지보수성이 하락된다.
- DBMS에 대한 종속성이 매우 크므로, 이기종 DB를 사용하는 것 자체가 리스크가 된다.

우리 회사 또는 우리 팀이 개발한 프로젝트에서 지금 사용하고 있는 아키텍처는 뭐지?

약 8년 전, 실제 Spring, JPA 강의의 대가 김영한 님이 OKKY라는 IT 커뮤니티 사이트에 썼던 글이기도 하고, 그에 대한 댓글들에서 많은 인사이트들을 얻을 수 있는 것 같아 아래 글을 첨부한다. 여기에서 'fender' 님의 댓글이 인상깊어서 가져와본다.

Q. 현재 개발 중인 프로젝트에 대해 '퇴사 처리'는 어떻게 해야 하지?

A1. 회원 테이블 또는 그와 관련된 레코드를 찾아 이 컬럼값을 바꾸면 되지!

=> 해당 프로젝트는 데이터베이스 중심적(SQL-DD)으로 설계되고 구현되고 있다는 것에 대한 반증일 가능성이 매우 높다.

A2. 회원 클래스를 가져와서 이 속성을 이렇게 바꾸면 되지!

=> 해당 도메인 클래스의 인스턴스에 대한 영속성을 확보한다는 측면에서 JPA와 같은 본격적인 ORM 라이브러리 도입이 자연스러운 선택이 되는 프로젝트일 가능성이 높다.

https://okky.kr/questions/286812

OKKY - ORM의 사실과 오해

ORM의 사실과 오해 http://okky.kr/article/286531 개시물에 댓글을 해주신 자유로운 새님의 글에 대해 질답 하는 형식으로 한 말씀 올리겠습니다. 먼저 은탄환은 없다는 것을 말씀드립니다. ORM은 절대 만

okky.kr

그래서 무엇이 기본으로 지향해야 하는 아키텍처일까?

현대 사회에서의 웹 개발자라면 DDD가 더 옳은 방향이라고 생각한다. 대부분의 웹 개발이 Java로 이루어지며, 이 'Java'라는 언어 자체가 '객체 지향'이다. 그런데, RDBMS는 '관계 지향'이며, 데이터를 중심으로 잘 정규화하여 '저장'하는 것에 기본적인 의미를 두고 설계되었기 때문에, 이 둘이 서로 지향하는 방향이 약간 다르다.

인프라 엔지니어의 입장에서 보면, DB 서버는 Scale-out이 매우 어렵고 신경 써야할 것이 매우 많은 반면, APP 서버는 Scale-out이 비교적 쉽고, 신경 써야할 것이 DB 서버에 비해 상당히 적다.

따라서, 데이터는 최대한 가볍게 꺼내 쓰고 가볍게 저장하며, 이를 기반으로 APP 서버가 열심히 일하여 비즈니스 로직을 처리하도록 개발하는 것이, 기업의 비용을 절감하고, 추후의 인적 리소스를 확보하는 데에 있어서도 더 옳은 방향이라고 생각한다.

참고

https://happycloud-lee.tistory.com/94

DDD 핵심만 빠르게 이해하기

마이크로서비스의 설계 방법론인 DDD(Domain Driven Design)에 대해 제가 가진 지식과 그간의 경험을 기반으로 정리하였습니다. 이 글을 읽기 전에 먼저 일하는 방식 변화를 이끌고 있는 애자일, 마이

happycloud-lee.tistory.com

https://incheol-jung.gitbook.io/docs/q-and-a/architecture/ddd

DDD(Domain Driven Design) - Incheol's TECH BLOG

이벤트 소싱과 항상 함께 알아두어야 할 개념으로 CQRS가 있으며 간단히 설명하면 커맨드와 쿼리의 책임을 분리하자는 것이다. 커맨드는 일반적인 디비 기준으로 상태를 변경하는 C,U,D와 같은 메

incheol-jung.gitbook.io

https://youwjune.tistory.com/38

DDD 설계 vs SQL 중심 설계

1. DDD란? DDD(Domain Driven Design : 도메인 주도 설계)란? 도메인 패턴을 중심에 놓고 설계하는 패턴이다. 즉, 도메인 간의 상호작용이 설계의 중심이 된다. 도메인이란, 소프트웨어로 해결하고자 하는

youwjune.tistory.com

https://velog.io/@cv_/DDD-vs-SQL-%EC%A4%91%EC%8B%AC-%EC%84%A4%EA%B3%84-%EC%B0%A8%EC%9D%B4

DDD vs SQL 중심 설계 차이

DDD(Domain-Driven Design)와 SQL-DD (Structured Query Language-Driven Design)는 소프트웨어를 개발하는 여러 방법론중 일부이다. 두 방식의 차이는?

velog.io

https://gmlwjd9405.github.io/2019/02/01/orm.html

[DB] ORM이란 - Heee's Development Blog

Step by step goes a long way.

gmlwjd9405.github.io

https://jongsky.tistory.com/15

ORM vs SQL Mapper

1. 글을 작성하게 된 이유 Rest API를 만들면서 생겨난 이슈사항이다. FastAPI를 이용해 request가 왔을 때 response를 해주는 Rest API를 만들고 있었다. response를 위해서는 기존에 만들어진 db(mysql)에서 데

jongsky.tistory.com

[MSSQL] 데이터베이스명, 논리적 파일명, 물리적 파일명(.mdf, .ldf)을 쿼리로 변경하기

코_노 — Wed, 27 Dec 2023 10:07:46 +0900

SSMS를 통한 데이터베이스 이름 변경

0. 현재 변경하려는 데이터베이스를 반드시 single_user 모드로 변경하기

USE [master]

-- DB 단일 사용자 모드(Single User mode)로 변경
-- 'WITH ROLLBACK IMMEDIATE' : 이 ALTER문이 발생하는 도중 생기는 다른 트랜잭션들은 모두 즉시 롤백하라는 옵션
ALTER DATABASE [데이터베이스명]
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE

-- 작업 완료 후 DB를 다시 원상태(Multi User mode)로 변경
ALTER DATABASE [데이터베이스명]
SET MULTI_USER

1. 데이터베이스 이름 변경

-- 만약 현재 변경하려는 데이터베이스가 특정 SQL User에서 default database로 설정되어 있다면,
-- 아래 쿼리문 수행하여, default database 명 먼저 변경하기.
-- 그렇지 않으면, 4064 에러(Cannot open u ser default database) 뜸
USE [master]
ALTER LOGIN [SQL Login Name] WITH DEFAULT_DATABASE=[변경하려는 데이터베이스 이름]


-- 데이터베이스 이름 변경
ALTER DATABASE [현재 데이터베이스 이름]
MODIFY NAME = [변경되는 데이터베이스 이름]

-- SP로도 가능하다.
EXEC sp_renamedb '현재 데이터베이스 이름', '변경되는 데이터베이스 이름'

논리적 파일명 또는 물리적 데이터 파일명을 변경하기 전에 다음 쿼리를 수행하여, 현재 설정되어 있는 논리적 파일명 및 물리적 데이터 파일명을 어딘가에 반드시 적어두자!

-- 현재 데이터베이스의 Logical File Name 확인 방법
USE [확인하려는 데이터베이스명]
SELECT FILE_ID
    , [Logical File Name] = name
    , [Physical File Name] = physical_name
FROM sys.database_files

-- 위 결과 복사해두기.

2. 물리적 데이터 파일명(.mdf 또는 .ldf) 변경

2.1. Backup 및 Restore(복원)을 이용한 방법

이 방법은 이미 백업파일이 존재하고, 해당 파일로 Restore를 하는 과정에서 변경하고 싶을 때 사용하면 좋은 방법이다.

-- 해당 백업파일의 Logical Name 확인
RESTORE FILELISTONLY 
FROM DISK=N'백업파일 절대경로'

-- 해당 백업파일로 복원하면서 저장될 physical 파일 이름을 변경하는 방법
RESTORE DATABASE [복원하려는 데이터베이스명]
FROM DISK = N'백업파일 절대경로'
WITH FILE = 1
    , STATS = 10
    , RECOVERY
    , REPLACE
    , MOVE N'MDF Logical Name' TO N'바뀔 Physical .mdf 파일 디렉토리'
    , MOVE N'LDF Logical Name' TO N'바뀔 Physical .ldf 파일 디렉토리'

2.2. 데이터베이스 Detach/Attach 를 이용한 방법

데이터베이스 Detach(분리)란, 데이터 파일을 새로운 디스크로 옮기는 등의 작업이 필요할 경우, 해당 DB의 Physical 파일은 그대로 보존하면서, 해당 DB에 대한 유저 Access는 차단하는 방법이다. 즉, 해당 DB를 SQL 인스턴스에서 떼어내는 방법이다.

데이터베이스 Detach를 수행할 경우, database file information, status information 등의 sys.databases에서 볼 수 있는 모든 metadata가 삭제되므로, 이 점을 주의해야 한다.

-- 해당 DB 분리(Detach) 수행
USE [master]
EXEC SP_DETACH_DB '데이트베이스명', 'TRUE'

-- 해당 데이터베이스의 파일명 또는 디렉토리를 OS 내에서 변경한다.

-- 해당 DB 다시 연결(Attach) 수행
USE [master]
EXEC SP_ATTACH_DB '데이터베이스명', '변경된 .mdf 파일 디렉토리', '변경된 .ldf 파일 디렉토리'

-- 해당 DB Attach 할 때 .mdf 파일만 연결하기.
EXEC SP_ATTACH_SINGLE_FILE_DB '데이터베이스명', '변경된 .mdf 파일 디렉토리'

3. 논리적 파일명 변경

USE [변경하려는 데이터베이스 이름]

-- 데이터 파일과 로그 파일이 각각 다르게 설정되어 있으므로, 쿼리를 각각 수행해줘야 한다.
-- .mdf에 대한 logical name 변경
ALTER DATABASE [변경하려는 데이터베이스 이름]
MODIFY FILE (
    NAME = '기존 Logical File Name'
    , NEWNAME = '바뀔 Logical File Name'
)

-- .ldf에 대한 logical name 변경
ALTER DATABASE [변경하려는 데이터베이스 이름]
MODIFY FILE (
    NAME = '기존 Logical File Name'
    , NEWNAME = '바뀔 Logical File Name'
)

참고

https://learn.microsoft.com/ko-kr/sql/relational-databases/databases/rename-a-database?view=sql-server-ver16

데이터베이스 이름 바꾸기 - SQL Server

데이터베이스 이름 바꾸기

learn.microsoft.com

https://dbrang.tistory.com/106

[2k] 논리적 파일명 및 물리적 파일명 바꾸기

/********************************************************************************************** -- Title : [2k] 논리적 파일명 및 물리적 파일명 바꾸기 -- Reference : dBRang.com -- Key word : alter database, restore database, sp_detach_db ***

dbrang.tistory.com

[개념] MSA, 컨테이너의 등장과 Agile, DevOps 문화는 무엇인가

코_노 — Thu, 14 Dec 2023 09:00:26 +0900

제조업에서 DBA, 미들웨어 엔지니어로 일하면서 가장 크게 느낀 부분은, 한 번 설계하고 배포한 시스템은 그 시스템을 전부 뒤엎지 않는 이상, 변경을 하기가 굉장히 까다롭다는 것이다.

이는 필자가 일하고 있는 회사가 제조업이기 때문이고, 제조업 특성 상 생산 가동 시간이 매출에 가장 큰 영향을 미치며, 이는 곧 IT 조직의 '변화'에 대한 두려움으로 경직을 불러옴으로써 야기된 결과라고 생각한다. 이러한 문제가 비단 제조업에서만 일어날 것 같지는 않다.

각설하고, 더 이상의 레거시 시스템을 찍어내는 행동을 반복하지 않기 위해, 나부터라도 조금씩 최신 IT 트렌드를 공부하고 이러한 기술들을 사내에 안정적으로 도입 및 적용시키며, 기존의 변화가 어려운 낡은 시스템에서 유연한 변화가 가능한 시스템으로 탈바꿈하는 것을 목표로 해보고자 한다.

그러기 위해서는, 이제는 트렌드라고 부르기도 뭐한, IT의 기본적인 아키텍처 또는 문화로 자리 잡은 MSA, 컨테이너, Agile, DevOps 등의 개념부터 알아볼 필요가 있다. 이번 포스팅에서는 이러한 것들의 개념을 정리하고자 한다.

MSA(Micro Service Architecture)를 논하기 전에, 우리는 지난 수십년 간 IT 시스템의 표준이었던 모놀리식 아키텍처(Monolithic Architecture)에 대해 알아볼 필요가 있다.

모놀리식 아키텍처(Monolithic Architecture)란?

: MSA와 반대되는 개념으로, 전통의 아키텍처를 지칭하는 의미로 생겨난 단어이다. 통상적으로, 단일 코드 베이스의 애플리케이션 또는 그러한 애플리케이션이 동작되는 시스템을 말하며, 이 애플리케이션 하나는 단일 데이터베이스에 연결되는 구조이다.

모놀리식 아키텍처의 다이어그램

모놀리식 아키텍처의 장점

단순성 : 모든 코드가 단일 코드 베이스에 있으므로, 변경 사항이 발생할 경우, 적용할 모든 코드가 한 곳에(한 프로젝트 내에) 존재한다는 의미이다. 또한 개발환경 즉, 로컬에서 실행해야 할 경우, 단일 애플리케이션만 실행하면 되는 단순함이 있다.
간편한 배포 : 단일 프로젝트로 배포하면 되므로 간편하다(?). → (Downtime이 자유로운 도메인이라면, 간편하다.)
보편성 : 대부분의 개발자가 모놀리식 아키텍처에서 작업한 경험이 있어, 프로젝트를 쉽게 시작할 수 있다.
인프라 구성 용이 : 하나의 프로젝트, 즉, 하나의 애플리케이션 및 DB만 배포하면 되므로, 인프라 구성이 쉽고 관리 point가 적다. (초기에만 그렇다고 본다.)

모놀리식 아키텍처의 단점

유지 보수의 어려움 : 시간이 지남에 따라 분명 애플리케이션의 규모가 커질텐데, 이에 따른 어려움이 생길 수밖에 없다. 단일 프로젝트로 개발하면서 필요한 모듈들이 굉장히 많을텐데, 하나의 기능을 변경하고자 하면, 이를 참조하거나 영향을 받는 모든 모듈들도 수정해야 하기 때문이다. 또한 가장 큰 문제로는, 작은 부분을 수정하고 반영하는 데에 있어서도, 전체 애플리케이션이 한 번은 종료되어야 한다는 점이다.
유연하지 않은 확장성(Scale 측면) : 애플리케이션의 특정 부분에 대한 요청을 받으면, 이 부분만을 확장할 수는 없고, 전체 애플리케이션을 확장해야 한다.
대규모 팀 작업의 어려움 : 모든 팀이 동일한 코드, 동일한 프로젝트에서 작업하기 때문에, 코드 병합에 대한 충돌 가능성이 높고, 기능 변경 시 다른 팀의 작업에 영향을 줄 수 있다.
기술 사용 제한 : 모듈 간의 의존성이 매우 높아, 다른 기술 스택으로 변경하는 것이 매우 어렵다.

MSA(Micro Service Architecture)란?

: 애플리케이션을 작은 서비스로 분할하고, 각 서비스가 서로 독립적(느슨한 결합)이므로 기술 및 의존성에 구애 받을 확률이 낮다. 또한, 각 서비스 별로 고유한 데이터베이스를 소유할 수 있으며, 그로 인해 많은 이점도 제공하지만, 여러 문제와 복잡성 또한 수반하게 된다.

MSA 아키텍처의 다이어그램

MSA의 장점

유연한 확장성(Scale 측면) : 각각의 마이크로 서비스는 서로 독립적이므로, 매우 유연한 확장이 가능하다. 또한 이는 애플리케이션의 고가용성이 필요할 때 매우 유용하게 된다.
독립적인 배포 : 마이크로 서비스는 서로 느슨하게 결합되어 있으므로, 하나의 마이크로 서비스만 배포할 수 있다. 수정 사항이 생겼을 때, 전체 애플리케이션의 작동을 멈출 필요가 없게 되는 것이다.
SPOF 제거 : 애플리케이션을 여러 소규모 서비스로 분할하여, 전체에 영향을 미치는 단일 실패 지점을 제거할 수 있다.
서로 다른 DB 소유 가능 : 각 마이크로 서비스의 특징에 따라, RDBMS가 적합할 수도 있고, NoSQL이 적합할 수도 있다. 이러한 각 서비스에 적합한 DB와 연결하여 서비스의 유연한 변화 및 확장을 가져갈 수 있다.
다양한 기술 스택 사용 가능 : 하나의 프로젝트가 아니기 때문에, 서로 다른 언어를 사용하여 개발할 수 있게 된다.
민첩성 : 전체 애플리케이션에 큰 영향을 주지 않고, 새로운 것을 추가할 수 있어, 새 버전을 배포하는 것이 매우 쉽다.

MSA의 단점

개발 환경의 뒷받침 : 여러 개의 마이크로 서비스 중 하나에 새로운 기능을 구현해야 할 때, 다른 서비스에 접근할 수 있도록 개발환경(로컬)에서 많은 애플리케이션을 실행할 수 있는 환경이 갖춰져야 한다.
디버깅의 어려움 : 디버깅 및 테스트 시, 둘 이상의 마이크로 서비스를 실행해야 할 수 있어, 이 부분이 어려울 수 있다.
개발의 어려움 : 마이크로 서비스 간의 통신에서 동기/비동기 방식의 통신을 고려하고, 다양한 Workflow 및 시나리오에서의 오류 처리, 중앙화된 모니터링 체계의 필요성, 오류 식별의 어려움 등이 있을 수 있어, 개발하는 동안에 복잡성이 증가한다.

여기까지 애플리케이션 개발 및 유지 보수에 대한 측면, 즉, 개발자의 입장에서 모놀리식 아키텍처와 MSA의 아키텍처를 이해했다면, 이제 인프라 엔지니어의 입장에서 생각해보자.

“MSA, 좋다 이거야. 근데 그렇게 잘게 잘게 쪼개 놓은 서비스들을 올릴 서버는 다 어떻게 만들고 관리하라고?” 라는 문제를 인프라 엔지니어가 해결해야 한다.

소규모의 마이크로 서비스들을 하나의 물리적 서버에 모두 올리자니, 이건 MSA의 최대 장점인 유연한 확장성을 없애버리는 것이고, 그렇다고 각 서비스마다 VM을 만들자니, 불필요한 OS 관리 포인트(취약성 패치 등..)와 OS가 차지하는 리소스와 오버헤드가 과도하게 증가하게 된다.

이러한 문제의 해결책으로, 한 물리적 서버에 대해서(하나의 OS 안에서) 각 서비스별로 독립된 공간을 만들어보자는 아이디어가 나오고, 이는 곧 컨테이너의 등장이 된다.

(물론, 컨테이너의 등장 배경은, 정확히 이러한 문제보다는 애플리케이션 개발과 운영 간 간극을 최소한으로 좁히고, 이를 이미지로 관리하기 위함이라는 게 더 옳은 듯 하다.)

컨테이너(Container)란?

: 어떤 환경에서나 실행하기 위해 필요한 모든 요소를 포함하는 소프트웨어 패키지.

OS를 가상화하여 프라이빗 데이터 센터에서 퍼블릭 클라우드 또는 개발자의 개인 노트북에 이르기까지 어디서나 실행이 가능하다.

왼쪽: Virtual Machine / 오른쪽 : Container (Docker 예시)

컨테이너의 장점

책임 분리 : 컨테이너화를 통해 개발자와 운영팀의 책임을 분리함으로써, 각자가 잘하는 것에 더 집중할 수 있게 된다. 개발자는 컨테이너에 함께 빌드할 애플리케이션의 로직과 종속 관계에 집중하고,
운영팀은 특정 소프트웨어 버전 및 구성과 같은 애플리케이션의 세부 요소 대신 배포 및 관리에 집중할 수 있게 된다.
Workload 이동성 : 컨테이너는 Linux, Windows, Mac 등의 OS를 가지리 않고, VM, 물리적 서버, 개발자 컴퓨터, 데이터 센터, 온프레미스 환경, 퍼블릭 클라우드 등 사실상 어느 환경에서나 구동되므로, 개발 및 배포가 매우 쉬워지게 된다.
애플리케이션 격리 : 컨테이너는 OS 수준에서 CPU, 메모리, 스토리지, 네트워크 리소스를 가상화하므로, 개발자에게 다른 애플리케이션으로부터 논리적으로 격리된 OS 환경을 제공한다. 즉, 다른 컨테이너의 과부하로 인해 내 컨테이너가 죽는 경우를 보지 않아도 된다.

컨테이너의 단점

모든 컨테이너는 동일한 OS에서 실행되어야 하며, OS 또는 버전을 조합해서 사용할 수 없는 게 관리 Point 면에서는 장점이 될 수 있지만, 거대한 시스템에 대해 다양한 환경으로 운영할 수 없다는 게 단점으로 될 수 있겠다.
컨테이너가 올라가는 OS가 모든 컨테이너에 대해 공유되므로, VM보다 보안이 취약해질 수 있다.
MSA 아키텍처가 적용되지 않은 컨테이너는 이미지로 만들어 찍어낼 수 있다는(?) 장점 외에, 비용 대비 VM과 견주어 우위에 있는 장점이 없어 보인다.

MSA와 컨테이너의 공통되는 키워드는 결국 ‘경량화’이다. 애플리케이션 아키텍처도, 인프라 아키텍처도 결국 '커다란 문제를 해결하기 위해 작은 단위로 쪼개야 한다'는 IT의 보편적인 진리가 한번 더 통한 셈이다.

그렇다면, 개발과 운영 업무를 하는 문화에도 ‘경량화’란 게 있을까? 우리는 이를 ‘Agile’ 방법론과 ’DevOps’ 문화라는 키워드로 살펴보기로 하자.

Agile 방법론이란?

: ‘Agile’이란, ‘기민한, 민첩한’ 이라는 뜻으로, 일정한 주기를 가지고 빠르게 제품을 출시하여 고객의 요구사항, 변화된 환경에 맞게 요구를 더하고 수정해 나가는 탄력적인 방법론을 말한다.

짧은 단위의 스프린트가 모여 스크럼 형태로 일하는 Agile 방법론

오늘날 많은 기업에서는 위 그림과 같은 *스크럼 형태로 애자일 프로세스를 주로 활용하는데, 특징적인 것은 변화에 수동적으로 대처하기보다 변화를 하나의 고정값으로 전제하여, 1~4주라는 짧은 단위의 스프린트 단위로 디자인,개발,테스트를 진행한다는 것이다. (⇒경량화한 프로세스의 지속적인 반복)

*스크럼 : 비즈니스 요구를 충족시키는 데에 초점을 맞추기 위해, 작은 목표를 짧은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발 및 전달하는 관리 프레임워크

Agile 방법론의 등장배경

IT 엔지니어라면, Agile하면 Waterfall(폭포수) 방법론이 당연하게 떠오를 것이다.

Waterfall 방법론은 아래 그림과 같은 요구사항 정의 및 서비스 설계 → 디자인 → 개발 → 테스트 → 배포 과정이 순차적으로 진행되며, 이전 단계가 완료된 후에야 그 다음 단계로 나아가게 된다.

하나의 IT Product가 출시되기까지 심사숙고(?)하는 Waterfall 방법론

이 방법의 장점으로는, 단계별로 업무를 분담하므로 맡은 바가 명확하고, 계획 단계의 문서화로 단계마다 소요되는 시간이나 현재 상황을 추적하고 병목을 파악하기도 쉽다는 것이다.

그러나, 위에서 물이 떨어질 때까지 마냥 기다리고 있어야 하니 서비스 런칭까지의 속도가 매우 느리며, 떨어진 요구사항대로 기능을 만들었으나 느린 속도에 의해 수 개월이 지난 시점에 해당 서비스가 배포되고 나면, 시장 상황은 이미 변해버려 더 이상 고객이 그 기능을 필요로 하지 않은 경우도 발생할 수 있다는 치명적인 단점을 가지고 있다.

결국 고객의 요구사항을 더 기민하게 대응하고 실현시키기 위한 방법론으로 Agile 방법론이 등장하게 되었다고 볼 수 있다.

Agile 소프트웨어 개발 방법론에서는 다음과 같은 가치를 더 중요시 한다.

과정에 대한 공정과 과정에 사용되는 도구 자체 < 개인과의 상호작용, 커뮤니케이션
포괄적인 문서 < 작동하는 소프트웨어 자체
계약 협상을 통한 이득 < 고객과의 협력을 통한 프로젝트 성공을 통한 이득
계획은 일단 따르는 것 < 계획과 다르더라도 변화에 기민하고 유연하게 대응하는 것

DevOps란?

기존 개발팀과 운영팀 간의 Silo(사일로) 현상을 제거하는 소프트웨어 제공 접근 방식 또는 그러한 문화를 말한다. 이는 새로운 Tool과 문화를 통해 코드 배포 또는 인프라 프로비저닝과 같이 수동적이고 느리던 기존 프로세스에 대해 자동화하는 것을 목표로 한다. 이러한 자동화를 통해 애플리케이션 및 서비스를 신속하게 제공할 수 있는 조직의 능력 향상이라는 방향성을 가지는 문화라고 볼 수 있다.

선순환(?) 고리를 통한 IT Product의 지속적인 개선을 지향하는 DevOps

DevOps 등장 배경

하나의 IT Product를 출시하기 위해서는, 프로젝트를 개발하고, 빌드하고, 테스트하고, 배포하고, 운영하는 등의 업무가 필요한데, 보통 지금까지의 회사들은 이를 개발팀과 운영팀으로 나누어 수행해왔다.

시스템 간 연결이 점점 더 복잡해지고, 그에 따른 필요한 기술과 고객의 요구사항이 지속적으로 변화해 감에 따라, 한 IT Product를 출시하고 운영하는 데에 있어서 같은 방향을 바라봐야할 IT팀 내에서도, 개발팀과 운영팀 간의 소통은 매우 어려워져 갔다.

이러한 사일로 현상을 타파하고, 개발팀과 운영팀 간의 협력과 통합을 강조하며, “개발팀처럼 생각하는 운영팀, 운영팀처럼 생각하는 개발팀”이라는 슬로건을 통해, 개발과 운영이 하나의 파이프라인으로 통합되어, IT Product의 품질 향상과 고객 요구사항을 더 기민하게 만족시키자는 것이다.

번외 - Agile과 DevOps의 구분?

필자는 DevOps라는 문화 자체가 Agile 방법론을 IT 실무적으로 좀 더 효율적으로 수행하기 위한 구체적인 방법론 또는 문화라고 생각하기에 둘의 차이점에 대해 굳이 알고 싶지는 않지만,
Agile은 고객과의 상호 작용에,
DevOps는 개발팀과 운영팀 간의 긴밀한 협력 관계 구축에 집중한다는 포인트로 접근하면 좋을 듯 하다.

결국 이 두 용어가 추구하는 공통적인 가치는, 공유/개방성/자율성 및 소통과 협력을 매우 중요시하며,
경량화 및 MVP 모델을 지향하고, 절차와 프로세스보다는 Fast Fail 및 이에 대한 피드백에 대한 반복을 통한
지속적인 개선과 변화를 장려한다는 것에 있다.

참고

https://yozm.wishket.com/magazine/detail/1813/

모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까? | 요즘IT

모놀리식 애플리케이션은 소프트웨어 개발을 위한 기본 접근 방식이다. 그렇다면 마이크로서비스가 대세가 된 현재 모놀리식 접근 방식을 버려야 할까? 만약 모놀리식 애플리케이션에서 마이

yozm.wishket.com

http://www.itdaily.kr/news/articleView.html?idxno=208378

[전문가 강좌] MSA와 애자일(Agile) - 아이티데일리

[아이티데일리] 1960년대 최초의 단지형 아파트인 마포아파트는 6층이었다. 시간이 지나면서 건축공법, 재료, 도구들이 발전하여 이제는 100층이 넘는 초고층의 빌딩을 지으면서도 에너지와 관리

www.itdaily.kr

https://cloud.google.com/learn/what-are-containers?hl=ko

컨테이너란? | Google Cloud

컨테이너는 어떤 환경에서나 실행하기 위해 필요한 모든 요소를 포함하는 경량 소프트웨어 패키지입니다.

cloud.google.com

https://www.vmware.com/kr/topics/glossary/content/vms-vs-containers.html?resource=cat-1065884937#cat-1065884937

Why use containers vs. VMs? | VMware Glossary

Virtual Machines (VMs) and containers are complimentary and similar – both improve IT efficiency, application portability, and enhance DevOps.

www.vmware.com

https://www.codestates.com/blog/content/애자일방법론-워터폴방법론

애자일과 워터폴 방법론 비교 | 정의, 차이, 장단점, 적합한 조직 - 코드스테이츠 공식 블로그

애자일 방법론의 출발은 소프트웨어 개발 방식이었지만 이제는 제품 개발을 넘어 하나의 일하는 방식, 워크플로우로 자리 잡았습니다. 대표적인 프로덕트 개발 방법론인 애자일 방법론을 소개

www.codestates.com

https://engineering-skcc.github.io/devops/DevOps1-애자일과데브옵스/

데브옵스 알아가기(1) : 애자일과 데브옵스

애자일과 데브옵스의 차이는 무엇일까요?

engineering-skcc.github.io

[httpd] Apache httpd의 로그 삭제 스크립트 및 crontab 등록하여 로그 파일 삭제 자동화하기

코_노 — Wed, 22 Nov 2023 15:56:59 +0900

apache httpd를 apachctl -k start 명령어로 실행하면, 다음과 같이 rotatelogs 플래그가 붙어서 실행되는 것을 확인할 수 있다.

rotatelogs는 apache httpd 패키지에 포함되어 있는 logrotate 바이너리인데, 문제는 이 녀석이 자동으로 삭제는 지원을 안 하는 듯 하다. (~~아니 이걸 왜 안함? ㅡㅡ~~)

그래서 간혹 아파치 웹서버 로그 파일들 때문에 스토리지가 Full 나버려서 장애가 발생하는 경우가 있으니, 아파치 웹서버를 사용하는 환경에서는 반드시 아래 스크립트를 작성하고 crontab을 등록하여 로그가 쌓여 스토리지가 Full 나버리는 상황을 예방해보자.

30일 이상 지난 로그 파일 삭제하는 스크립트 작성 - 'Delete_Log.sh'

#!/bin/sh

# 필자의 경우, httpd 로그 파일이 저장되는 경로가 /etc/apache/logs 라고 가정하였다.
# 필자의 경우, 로그 파일명이 '애플리케이션명_log.날짜' 와 같은 형태임을 유의하자.
# 최근 수정 날짜가 30일 이상인 파일들을 find 하고 해당 파일들에 rm 명령어를 수행한다.
/usr/bin/find /etc/apache/logs/ -name '*log.*' -mtime +30 | xargs -r rm

xargs -r : 표준 입력이 empty일 경우, 뒤에 오는 command를 수행하지 않도록 하는 옵션

작성한 스크립트 파일의 파일 권한을 실행할 수 있도록 수정 (예시는 root 계정만 수행할 수 있도록 설정)

chmod 744 Delete_Log.sh

작성한 스크립트 파일을 crontab에 등록

crontab에 등록함으로써, OS 상에서 지정한 스케줄에 맞춰 자동으로 해당 스크립트가 수행되도록 설정한다.

# crontab 등록 명령어
crontab -e

# 위 명령어 수행 결과로 나타나는 editor에서 다음 내용을 기입후 저장(:wq)
# '0 0 * * *'은 매일 00시 00분에 해당 명령을 수행한다는 의미
0 0 * * * {Delete_Log.sh 파일 위치}/Delete_Log.sh

# 위 editor를 빠져나온 후에 아래 명령어 수행하여 등록된 crontab 리스트 조회
crontab -l

[Nginx] http → https 리다이렉션 및 SSL 인증서 적용 (Nginx ver.1.20.1 기준)

코_노 — Fri, 3 Nov 2023 08:13:36 +0900

CSR을 만들고 SSL 인증서 파일을 발급 받는 과정은 무사히 마쳤다고 생각하고 생략하기로 한다.

필자는 기관에 요청하여 받은 인증서 파일이 base64 방식으로 인코딩된 .p7b 파일과 DER 방식으로 인코딩된 .cer 파일로 2개였다.

둘 중에 하나로 원하는 걸 사용하면 되고, 두 인증서 포맷은 다음과 같은 특징이 있으므로, 참고하면 된다.

또한, 다양한 인증서 관련 파일 포맷에 대한 설명이 아래 링크에 있으니, 확인하면 되겠다.

.p7b 확장자
- PKCS#7 포맷
- [‘서버 인증서’ + ‘Root 인증서’ + ‘Chain 인증서’] 를 모두 담을 수 있어, SSL 인증서 적용 또는 이전 시에 상당히 유용하고 편리
- Windows 에서는 자동 인식, 일부 서버에서는 p7b 포맷으로만 인증서 설정이 되는 경우도 있다.
- 인증서 내 private key 는 포함 X. key 파일에 대한 설정(nginx 에서는 ‘ssl_certificate_key’ 구문)은 별도의 키 파일로 잡아주어야 한다.
.cer 확장자
- Windows 에서는 기본 인식되는 확장자
- 대부분 PEM 포맷이나, Binary 포맷일 때도 있음
- 주로 Windows 기반에서 인증서 파일임을 구분하기 위해서 사용되는 확장자
- .crt 확장자와 거의 동일한 의미

SSL 인증서 파일 포맷 종류 - crt, cer, csr, pem, der, pfx, p12, p7b, jks, key - SecureSign

www.sslcert.co.kr

인증서 파일 확장자를 .p7b → .pem 변환

대부분의 글들이 .pem 확장자 기준으로 설명하므로, 나도 혼란을 방지하기 위해 .p7b → .pem 변환 먼저 수행하겠다. .p7b 확장자와 .pem 확장자는 변환 시 100% 호환된다고 생각해도 무방할 듯 하다.

아래 명령어를 수행하여 확장자를 .pem 으로 변환하자!

openssl pkcs7 -in [발급받은 .p7b 인증서] -out [.pem으로 만들 파일 이름.pem] -print_certs -text

# ex) openssl pkcs7 -in Issued_Cert.p7b -out Integrated_Cert.pem -print_certs -text

SSL 인증서(.pem 확장자 기준) 적용하기

이제 변환된 .pem 파일과 CSR 발급 시 사용한 key 파일을 SSL 인증 옵션 구문에 함께 넣어주면 된다.

필자는 특정 사이트에 대한 server 옵션들을 모아둔 파일인 sites-available/{사이트명} 파일에 아래 구문을 넣었다.

server {
    listen      443 ssl;
    server_name Example.co.kr;

    ssl_certificate             [변환한 Cert 파일명.pem 파일 경로];
    ssl_certificate_key         [decrypted 키 파일명.key 파일 경로];

    ssl_session_timeout         5m;
		
    # SSL 취약성 제거 위한 설정
    ssl_protocols               SSLv3 TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers   on;
    ssl_ciphers                 HIGH:!aNULL:!MD5;

    location / {
        include proxy_params;
        # 동일 host 내의 gunicorn 서버로 request 전달하기 위함
        proxy_pass <http://unix>:{gunicorn의 unix .sock 파일 경로};
    }
}

위 구문을 추가한 nginx site 설정 파일명을 ‘test_ssl’ 이라고 가정하면,

아래 명령어를 수행하여 sites-available/test_ssl 사이트 설정 파일을 sties-enabled/PRD 파일로 심볼릭 링크를 걸고, nginx 를 재기동하여 사이트 설정을 load하여 테스트 해보자.

# test_ssl -> PRD 심볼릭 링크
ln -s /etc/nginx/sites-available/test_ssl /etc/nginx/sites-enabled/PRD

# nginx 관련 파일 syntax 검사
nginx -t

# nginx 새로운 설정 적용 방법1 - 설정파일만 reload
nginx -s reload

# nginx 새로운 설정 적용 방법2 - nginx 재기동
systemctl restart nginx

http://{Domain Name}:443/ 으로 접속했을 때, 이상 없이 해당 웹 사이트 접속이 된다면, SSL 인증서 설정이 문제 없이 적용 된 것이다.

만약 뭔가 문제가 생겼다면, ‘PRD’ 심볼릭 링크를 제거하고, 기존의 site 설정 파일인 ‘test_old’ 파일로 다시 심볼릭 링크를 걸고, nginx 설정 파일을 리로드하여 롤백하면 된다.

# 새롭게 적용한 site 설정 파일인 'PRD' 심볼릭 링크 제거
rm /etc/sites-enabled/PRD

# 기존에 사용하던 site 설정 파일인 'test_old' 심볼릭 링크 걸기
ln -s /etc/sites-available/test_old /etc/sites-enabled/PRD

# nginx 설정 파일 리로드
nginx -s reload

http → https 리다이렉션 설정하기

SSL을 적용하였으니, 기존의 사이트 설정에 있는 LISTEN 80 블록은 아래와 같이 변경해주어야 한다.

필자의 경우, 아래와 같이 servername {ip} 인 블럭과 servername {domain name} 인 블럭 두 개를 설정하여,

IP와 80 포트로 접속하는 경우, domain name과 80포트로 접속하는 경우 모두를 https://{domain-name} 으로 리다이렉션 하도록 설정하였다.

참고로, [::] 은,

# {IP}:80, {domain name}:80, www.{domain name}:80 으로 접속하는 경우 리다이렉션 설정
server {
    listen 80;

    server_name Example.co.kr www.Example.co.kr 10.123.123.123;

    return 301 https://Example.co.kr$request_uri;
}

위 설정을 한 후, 다시 심볼릭 링크 및 nginx 설정 reload를 한 후에, http://{IP}, http://Example.co.kr 로 접속해서 https://Example.co.kr 로 리다이렉션이 잘 되는 지 확인해보면 된다!

참고

https://velog.io/@coastby/Nginx-SSL-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0

[Nginx] SSL 적용하기

SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)은 전송계층 상에서 클라이언트, 서버에 대한 인증 및 데이터 암호화를 수행한다. 클라이언트와 서버 양단 간 응용계층 및 TCP 전송계층 사이에서

velog.io

https://www.comodossl.co.kr/Certificate/ssl-installation-guides/Nginx.aspx

Nginx : 인증서 적용 - HanbiroSSL

SSL 보안 서버 인증 가장 합리적인 가격의 Sectigo SSL 인증을 통해 귀사의 웹서버에 접속하는 회원들의 개인 정보를 안전하게 보호해 주시기 바랍니다. --> 본 가이드는 인증서 파일 설정시 참고 예

www.comodossl.co.kr

[Gunicorn] logrotate, crond를 활용한 nginx와 gunicorn의 log 파일 관리하기

코_노 — Thu, 2 Nov 2023 07:02:22 +0900

logrotate 란?

Linux 환경에서 로그의 관리를 도와주는 CUI 기반의 도구이다.

사용자가 정한 주기마다 쌓인 로그를 아카이빙, 아카이빙된 파일의 갯수를 일정 갯수로 제한하는 등의 로그 관리를 하여, 스토리지 용량이 부족해지는 등의 문제를 방지할 수 있도록 한다.

logrotate 자체는 daemon이 아닌, 로그의 관리를 도와주는 단순 실행파일이므로, 주기적으로 알아서 작업할 수 있는 능력이 없다. 따라서, 반드시 Linux 내의 ‘crond’ 와 같은 스케줄러 설정이 필요하다.

그리고 /etc/logrotate.d 디렉토리에 각 로그파일마다의 logrotate 설정에 대한 파일들이 있는데, 여기에 ‘nginx’, ‘{Gunicorn으로 구동할 APP 이름}’ 으로 파일명을 하여 Nginx 및 Gunicorn 에 대한 logrotate 설정을 할 것이다.

Nginx logrotate 설정

# /etc/logrotate.d/nginx 파일

/etc/nginx/log/*.log {
    daily
    dateext
    dateyesterday
    rotate 60
    missingok
    compress
    delaycompress
    notifempty
    create 0640 nginx nginx
    sharedscripts
    postrotate
            if [ -f /run/nginx.pid ]; then
                kill -USR1 `cat /run/nginx.pid`
            fi
    endscript
}

위 logrotate 설정 파일의 해석은 다음과 같다.

맨 위 /etc/nginx/log/*.log : /etc/nginx/log 디렉토리에 있는 *.log 파일에 대해 다음 logrotate 옵션을 지정한다.
daily : 매일 logrotate를 수행하여, 일별로 새로운 로그 파일이 생성되도록 한다.
dateext : 로그 파일명에 ‘20231028’ 과 같은 날짜 형식을 추가하여 로그파일이 생성되도록 한다.
dateyesterday : dateext로 붙는 날짜 형식에 하루 전날 기준으로 생성하도록 한다.
⇒ 이 옵션을 사용하지 않으면, logrotate를 수행한 해당 시점 기준으로 파일명에 날짜가 새겨져서 헷갈리게 된다. 예를 들면 2023.10.28. 에 logrotate를 하게 되면 결과로 생성된 로그 파일(ex) error.log-20231028)에는 2023.10.27. 의 로그들만 있는데, 이를 방지하고자 이 옵션을 사용하면, 2023.10.28에 logrotate를 한 결과 로그 파일명이 ‘error.log-20231027’로 되는 것이다.
rotate [숫자] : 해당 개수만큼만 로그 파일을 보관한다. 이 수를 초과하면, 오래된 로그부터 삭제된다.
missingok : 로그 파일이 없는 경우에도 경고 없이 진행한다.
compress : 로그 파일을 압축하여 저장한다.
delaycompress : 다음 logrotate 가 진행되기 전까지 압축을 지연시킨다. ⇒ 2023.10.28. 에 logrotate 가 수행된다면, 이때 결과 파일로 생기는 로그 파일은 압축을 하지 않고(다음날인 2023.10.29.에 해당 파일이 압축된다.), 2023.10.27. 에 logrotate 수행한 파일을 압축하게 된다.
notifempty : 로그 파일이 비어 있으면 로테이션하지 않도록 한다. 즉, 해당 날짜에 대한 새로운 로그가 생기지 않았다면, 로그 파일명 기준으로 해당 날짜에 대한 로그가 누락된 것처럼 보일 수도 있겠다…!
create 0640 nginx nginx : logrotate 결과 생기는 파일에 대한 권한을 설정하는 것으로, 이 예시에서는 해당 로그 파일에 대해 0640 permission 으로 ‘nginx’ 유저, ‘nginx’ 그룹에 소유권을 부여한다는 의미이다.
sharedscripts : 여러 로그 파일이 있는 경우, 한 번만 logrotate 를 수행하도록 하여, 이 옵션으로 지정된 logrotate 중복 수행을 방지하고, 실행시간 및 리소스 사용을 줄인다.
postrotate : logrotate 수행 이후에 수행할 작업을 정의하는 구문으로, 위 예시에서는 nginx에 USR1 시그널을 보내어 log 파일을 re-open 함으로써, logrotate 수행 결과 생성된 로그 파일에 현재 구동중인 nginx의 로그가 계속하여 쌓이는 것을 방지한다.
endscript : ‘prerotate’ ‘postrotate’ 와 같은 옵션 블록을 사용할 때, 이 블록에 속한 명령어나 스크립트의 실행 범위의 끝을 나타내는 키워드에 해당한다.

Gunicorn logrotate 설정

# /etc/logrotate.d/{Gunicorn으로 구동할 APP 이름} 파일

/apps/venvs/qa_portal/logs/*.log {
    daily
    dateext
    dateyesterday
    rotate 60
    missingok
    compress
    delaycompress
    notifempty
    create 0640 gunicorn gunicorn
    sharedscripts
    postrotate
            if [ -f /apps/venvs/qa_portal/qa_portal.pid ]; then
                kill -USR1 `cat /apps/venvs/qa_portal/qa_portal.pid`
            fi
    endscript
}

crond 란?

Cron(주기적인 job 스케줄 실행을 위한 S/W 유틸리티)의 daemon 프로세스이다.

crond 는 기본적으로 아래와 같은 구조로 crontab 과 cron.d 의 수행해야 할 작업 내역을 불러와서 일정 주기마다 해당 작업을 수행한다.

출처 :  https://blog.o3g.org/server/logrotate를-활용하여-로그-관리하기/

필자는 간편하게 crontab을 활용하여 스케줄 job을 등록하고자 한다.

crontab

crontab은 cron의 실행주기 및 실행시간이 지정된 작업의 모음으로 아래와 같은 명령어 형식을 통해 스케줄 job을 등록할 수 있다.

* * * * * [실행 명령어 또는 쉘 스크립트]

# 첫번째   '*' : 0~59 의 숫자를 입력하여, **몇 분**에 해당 명령을 수행할 지 결정
# 두번째   '*' : 0~23 의 숫자를 입력하여, **몇 시**에 해당 명령을 수행할 지 결정
# 세번째   '*' : 1~31 의 숫자를 입력하여, 매달 **며칠**에 해당 명령을 수행할 지 결정
# 네번째   '*' : 1~12 의 숫자를 입력하여, **몇 월**에 해당 명령을 수행할 지 결정
# 다섯번째 '*' : 0~7 의 숫자 또는 [sun | mon | tue | web | thu | fri | sat] 중 하나 입력
# **무슨 요일**에 해당 명령을 수행할 지 결정 / 일:0,7 / 월:1 / 토:6

다음 명령어를 통해 nginx의 logrotate와 gunicorn의 logrotate를 매일 하루의 시작인 00시 00분에 수행하도록 해보자.

# crontab 스케줄 등록 (crontab -e)
# vi editor처럼 나타나는데 거기에 등록하려는 crontab 형식의 스케줄을 입력하고 :wq로 저장하면 된다.
crontab -e 

# crontab -e 로 나오는 텍스트 에디터에서 다음을 입력하고 ':wq' 입력하여 저장 및 종료
# nginx의 logrotate를 crontab에 매일 오전 00:00 으로 등록
0 0 * * * /usr/sbin/logrotate -f /etc/logrotate.d/nginx

# Gunicorn으로 구동하는 App의 logrotate를 crontab에 매일 오전 00:00 으로 등록
0 0 * * * /usr/sbin/logrotate -f /etc/logrotate.d/{Gunicorn으로 구동하는 App의 logrotate 설정 파일명}

# 현재 crontab으로 걸려 있는 모든 스케줄 job 조회
crontab -l

참고

https://sangchul.kr/entry/Nginx-%EB%A1%9C%EA%B7%B8-%ED%8C%8C%EC%9D%BC%EC%9D%98-%EB%A1%9C%ED%85%8C%EC%9D%B4%EC%85%98-%EC%84%A4%EC%A0%95nginx-logrotate

Nginx 로그 파일의 로테이션 설정하는 방법(nginx logrotate)

Nginx 로그 파일의 로테이션 설정하는 방법(nginx logrotate) Nginx 로그 파일을 주기적으로 로테이션(순환)하여 로그 파일 크기를 관리하고 오래된 로그를 보관하려면 logrotate를 사용할 수 있습니다. Ngi

sangchul.kr

https://m.blog.naver.com/hello_world_study/221501251102

gunicorn, flask 그리고 log 설정하기 with logrotate

#gunicorn 은 tomcat 과 같은 웹서버입니다. 보통 tomcat 은 자바와 연결되어 동작하고, gunicorn 의 경우 ...

blog.naver.com

https://blog.o3g.org/server/logrotate%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%98%EC%97%AC-%EB%A1%9C%EA%B7%B8-%EA%B4%80%EB%A6%AC%ED%95%98%EA%B8%B0/

logrotate를 활용하여 로그 관리하기 : 오픈 인프라 엔지니어 그룹

1. 서론 데이터베이스 시스템이나 어플리케이션 서버, 웹 서버를 운용하다 보면 어느순간 쌓여 있는 로그들을 확인할수 있다. 이렇게 쌓인 로그들은 운영중인 시스템에 장애가 발생했을때 원인

blog.o3g.org

[Gunicorn] gunicorn - nginx 연동

코_노 — Tue, 31 Oct 2023 21:43:35 +0900

1. nginx 디렉토리 권한 수정

RHEL9 에서 dnf로 nginx를 설치하면 nginx 디렉토리들에 대한 권한이 default로 root로 들어가 있을 것이다. 이는 보안상 취약하므로, 아래 명령어를 수행하여 ‘nginx’ 유저 및 그룹으로 변경해 주도록 하자.

# /etc/nginx/ 디렉토리 권한을 nginx:nginx로 변경 
chown -R nginx:nginx /etc/nginx/

2. SELinux 설정 변경

SELinux는 최신 RHEL 및 CentOS 에서 기본적으로 활성화되어 있는 Linux 시스템용 보안 아키텍처이다. SELinux 모듈이 켜져 있으면, 파일 접근 권한, Upstream 위치로의 Proxy 및 소켓을 통한 다른 프로세스와 통신하는 것 등에 제한이 따르기 때문에, nginx 도 구동부터 막히게 된다.

따라서 아래 명령어 및 파일 수정으로 SELinux를 enforcing → permissive 로 변경해보자!

# 현재 SELinux 상태 확인 명령어 
sestatus

서버를 처음 셋업하고 SELinux에 대한 설정을 건드리지 않았다면, 위와 같이 Current mode가 enforcing 일 것이다. 이 상태면, systemctl start nginx 가 되지 않는다.

# 현재 SELinux 를 enforcing -> permissive 로 변경 
setenforce 0  

# SELinux 상태 다시 확인 
sestatus

이제 nginx 는 구동시킬 수 있을 것이다.

문제는 이 서버가 재부팅되면, 다시 SELinux의 config 파일을 읽어와서

enforcing 모드로 될 것이므로, 아예 config 파일에서도 permissive로 설정을 바꿔보자!

# RHEL9 기준, vim /etc/selinux/config  
# /etc/selinux/config 파일 
# 아래와 같이 'SELINUX' 값을 'permissive'로 변경 

SELINUX=permissive

SELinux 의 config 파일을 permissive로 변경 후에 다시 sestatus 명령어를 수행해보면, 위 그림과 같이 Mode from config file 의 값이 permissive로 변경된 것을 확인할 수 있다!

3. nginx 기본 설정 파일 수정 - nginx.conf

# nginx 설치 경로로 이동 
cd /etc/nginx  

# nginx.conf 파일 수정 전 원본 복사 
cp nginx.conf nginx.conf_ori  

# nginx.conf 파일을 수정 
vim nginx.conf

# nginx.conf  

# worker 프로세스를 실행할 사용자 설정 
# 이 user에 따라 권한이 달라질 수 있다. 
user nginx; 

# 실행할 worker 프로세스 설정 
# 서버에 장착되어 있는 코어 수만큼 할당하는 것이 보통. 
worker_processes auto;  

# 오류 로그를 남길 파일 경로 지정 
# 여기에서는 /etc/nginx/log 디렉토리를 만들었다고 가정 
error_log /etc/nginx/log/error.log warn;  

# nginx 마스터 프로세스 ID를 저장할 파일 경로 지정 
pid /run/nginx.pid;   

# 접속 처리에 관한 설정 
events { 	
    # 워커 프로세스 한 개당 동시 접속 수 지정 (512 or 1024 추천) 	
    worker_connections 1024; 
}  

# 웹, 프록시 관련 서버 설정 
http {  	
    # 액세스 로그 형식 지정 	
    log_format main '$remote_addr - $remote_user [$time_local] "$request" ' 									'$status $body_bytes_sent "$http_referer" ' 									
    '"$http_user_agent" "$http_x_forwarded_for"';  	
    
    # 액세스 로그를 남길 파일 경로 지정 		
    access_log /etc/nginx/log/access.log main; 	 	
    
    # sendfile api 를 사용할 지 말 지 결정 	
    sendfile        on; 	
    
    # on - 데이터를 클라이언트로 전송할 때 데이터를 버퍼링하여 전송 지연을 최소화. 	
    tcp_nopush      on; 	
    
    # on - 작은 패킷을 빠르게 전송하여 지연 시간을 최소화.   
    tcp_nodelay   on; 	
    
    # 접속 시 커넥션을 몇 초동안 유지할 지에 대한 설정   
    keepalive_timeout 65; 	
    
    # nginx가 MIME 타입을 해시 테이블에 저장하는 데 사용하는 메모리의 최대 크기 (default 4096) 	
    type_hash_max_size 4096;  	  	
    
    # mime.types 파일을 읽어온다. 	
    include /etc/nginx/mime.types; 	
    
    # MIME 타입 설정 	
    default_type application/octet-stream;  	
    
    # 보안을 위해 nginx 버전을 숨기도록 지정 	
    server_tokens off;  	
    
    # /etc/nginx/conf.d 디렉토리에 하위의 모든 .conf 파일을 읽어오도록 설정 	
    include /etc/nginx/conf.d/*.conf;  	
    
    # RHEL9 의 dnf 배포판에는 없어 별도로 디렉토리 생성 및 conf 구문 추가 	
    # /etc/nginx/sites-enabled 디렉토리 하위의 모든 사이트 설정을 불러오도록 지정 	
    include /etc/nginx/sites-enabled/*; 
}

4. nginx-gunicorn 연동을 위한 config 파일 작성

필자는 RHEL9에서 dnf로 설치한 nginx에 sites-available 디렉토리가 따로 없었다. 그래서 별도로 생성해주었고, 해당 디렉토리는 실제 conf파일이 반영 되는 곳이 아닌, 미리 conf파일을 작성하여 저장하는 용도로 사용된다.

# /etc/nginx/sites-available 디렉토리 하위에 [gunicorn에 배포할 프로젝트 이름] 으로 설정 파일을 만들 것이다. 
# 예시 : /etc/nginx/sites-available/test_project  

server { 	
    listen 80; 	
    server_name [IP address | Domain name];  	
    
    location / { 		
        include proxy_params; 		
        proxy_pass http://unix:/apps/venvs/{프로젝트의 가상환경명}/run/{프로젝트명}.sock; 	
    } 
}

location / : 모든 요청을 구문에 맞게 리다이렉션 하라는 의미

http://unix:/~.sock : 해당 요 청을 Gunicorn의 Unix Domain Socket으로 보내라는 의미

5. proxy_params 파일 작성

위 test_proejct에 대한 config 파일에 include proxy_params 구문이 있는데, 우리는 해당 파일을 아직 작성하지 않았다. proxy_params 파일은 해당 사이트에 대한 별도의 프록시 파라미터 설정을 해주는 파일이다. 다음과 같이 작성해보도록 하자.

# vim /etc/nginx/proxy_params  
# proxy_params 파일  

# Request를 넘겨 받을 때 아래 Proxy Header 정보를 지정 
proxy_set_header X-Real-IP $remote_addr; 
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme; 
proxy_set_header X-NginX-Proxy true;  

# 서버(웹사이트)에 업로드 가능한 파일 최대 용량 
# default : 1M 
client_max_body_size 128M;  #

클라이언트 Buffer 사이즈 (body 들어오는 사이즈) 
# default : 32bit=8k, 64bit=16k 
client_body_buffer_size 1M;  

# 백엔드 서버로부터 해당 response를 버퍼링할 지 여부 정의 
# on : 버퍼가 제공하는 메모리 공간을 이용하여 응답 데이터를 메모리에 저장 
# off : 응답을 직접 클라이언트에게 전달 
proxy_buffering on;  

# 백엔드 서버로부터 response 데이터를 읽는 데 사용할 버퍼의 수와 크기 설정 
proxy_buffers 256 16k;  

# 백엔드 서버 response의 첫 부분을 읽기 위한 버퍼 크기 지정 
proxy_buffer_size 128k;  

# 여기서 지정한 값을 버퍼가 초과하면, 데이터를 클라이언트로 보내고 버퍼를 비움 
proxy_busy_buffers_size 256k;  

# 한 번에 사용할 수 있는 임시 파일 용량 
proxy_temp_file_write_size 256k;  

# 최대 사용할 수 있는 임시 파일 용량 
proxy_max_temp_file_size 1024M;  

# 백엔드 서버 접속 제한 시간(sec 단위)을 정의 
proxy_connect_timeout 3600;  

# 백엔드 서버로부터 데이터를 읽을 때의 제한 시간 
proxy_send_timeout 3600; 

# 백엔드 서버로 데이터를 전송할 때의 제한 시간 
proxy_read_timeout 3600;  

# 백엔드 서버가 보내오는 모든 에러 페이지를 nginx가 직접 클라이언트에게 회신 
proxy_intercept_errors on;

6. sites-enabled에 링크 생성을 통한 프로젝트 config 파일 적용

sites-available 에서 작성한 프로젝트에 대한 config파일을 sites-enabled 디렉토리 하위에 심볼릭 링크로 만들어 해당 config가 적용되도록 한다. nginx는 이러한 방식을 통해, 현재 서버에 적용되고 있는 config 파일을 직접 수정하지 않고, 별도의 파일로 작성 후에 바로 적용할 수 있도록 구현되어 있다.

# 실제 nginx에서 가져오는 설정 파일인 sites-enabled 하위 파일을 심볼릭 링크로 생성 
ln -s /etc/nginx/sites-available/test_project /etc/nginx/sites-enabled/test_project  

# 생성된 심볼릭 링크에 대한 소유권을 'nginx' 로 변경 
chown -h nginx:nginx /etc/nginx/sites-enabled/test_project

7, gunicorn 전용 계정 생성 및 권한 부여

python과 관련된 디렉토리인 /apps와 그 하위 디렉토리들에 대한 권한을 모두 ‘gunicorn’이라는 계정으로 소유권을 이전할 것이다. 일단 OS 계정부터 만들어야 하니, 다음 명령어를 수행하여 계정을 만들자.

# 아래 명령어는 모두 root 또는 root 계정과 동등한 권한으로 수행 
# 'gunicorn' Linux 계정 생성 
useradd gunicorn 

# 'gunicorn' Password 설정 
passwd gunicorn  

# python과 관련된 디렉토리인 /apps 및 그 하위 디렉토리의 소유권을 모두 gunicorn으로 변경 
chown -R gunicorn:gunicorn /apps  

# 'gunicorn' 홈 디렉토리 설정 
usermod -d /apps gunicorn  

# 'gunicorn'이 구동되면서 생성될 소켓 파일이 위치할 디렉토리 생성 
# 'gunicorn' 으로 계정 전환하여 생성하기 
mkdir /apps/venvs/test_project/run

8. gunicorn의 socket 파일에 대한 보안 컨텍스트 변경

nginx ↔ gunicorn 간 통신을 TCP가 아닌 Unix Domain Socket을 이용하여 셋업하고자 한다.

필자의 경우 nginx 와 gunicorn을 같은 서버에 둔다고 가정하여, 불필요한 네트워크 오버헤드를 없애기 위해 로컬 환경 안에서의 UDS(Unix Domain Socket)을 통한 통신으로 설정하는 것이다.

우선 /run/test_project.sock 파일이 생성되려면, gunicorn을 UDS 방식으로 한번 구동시켜줘야 한다.

gunicorn이 이미 실행되어 있다면 종료시키고, 다음 명령어로 gunicorn을 다시 구동시키자.

# python 프로젝트에 대한 venv 활성화 및 프로젝트의 홈 디렉토리에서 수행 
# "pybo:create_app()" 구문은 배포하는 애플리케이션에 맞춰 지정해야 한다. 
gunicorn --bind unix:/apps/venvs/test_project/run/test_project.sock "pybo:create_app()" &  

# /run/test_project.sock 파일 생성 확인 후, gunicorn 종료 
kill -9 [gunicorn PID]

gunicorn의 UDS 소켓 파일의 보안 컨텍스트를 변경하지 않으면, nginx 의 포트(IP:80)를 통한 접속 시,

502 Bad Gateway

에러와 nginx의 에러 로그에서는

Connection refuesed

에러를 마주할 것이다.

정석이라면 /apps/venvs/test_project/run/test_project.sock 파일의 보안 컨텍스트를 변경해줘야 하지만,

그냥 더 쉽게 ‘nginx’ 계정이 ‘gunicorn’ 그룹에 들어가도록 하자.

usermod -G nginx gunicorn

→ 이렇게 하면, nginx가 'gunicorn' 계정과 동일한 그룹으로 구동되어, gunicorn에 의해 생성되는 sock 파일을 접근할 수 있게 된다.

2. 작성한 nginx의 모든 config 파일 syntax 검사

nginx -t

위와 같이 syntax is ok 및 test is successful 이라는 문구가 나타났다면, nginx config 파일의 syntax error는 없다고 볼 수 있다.

10. nginx 구동

config 파일에 이상이 없으니, 이제 nginx 를 구동하여 WSGI서버와 연동이 잘 되었는지 확인해보자!

systemctl start nginx

11. {IP}:80 를 통한 접속으로 test_project Web App 접속 여부 확인

nginx 및 gunicorn이 10.123.123.123 서버에서 구동된다면, http://10.123.123.123:80/ 로 접속하여 gunicorn으로 구동하는 애플리케이션의 인덱스 페이지가 나타나는 지 확인하면 된다.

12. gunicorn service 등록

systemctl 명령어로 gunicorn을 쉽게 올리고 내릴 수 있도록, service 파일로 작성해보자.

서비스 파일에 사용될 환경변수가 선언된 파일이다. 이는 해당 프로젝트의 venv 디렉토리에 위치시키도록 하자.

# /apps/venvs/test_project/test_project.env 파일 
FLASK_APP=pybo 
FLASK_DEBUG=false    # 운영 환경이므로 디버깅 모드는 false로 한다. 
APP_CONFIG_FILE=/apps/projects/test_project/config/production.py

이제 서비스 파일을 작성해보자. python의 경우 venv를 프로젝트 단위로 구성하였으므로, 서비스 파일 또한 gunicorn으로 구동시킬 프로젝트 단위로 생성해야 함을 주의하자!

# gunicorn으로 구동 시킬 프로젝트에 대한 서비스 생성 (root 계정 또는 그와 동등한 계정으로 수행) 
# 위 예시와 맞추기 위해 service 명을 'test_project'로 지정 
vim /usr/lib/systemd/system/test_project.service  

# test_project.service 파일 
[Unit] 
Description=gunicorn daemon 
After=network.target  

[Service] 
User=gunicorn 
Group=gunicorn 
WorkingDirectory=/apps/projects/test_project 
EnvironmentFile=/apps/venvs/test_project/test_project.env 
ExecStart=/apps/venvs/test_project.sh 
ExecStart= 
ExecStart=/apps/venvs/test_project/bin/gunicorn \         
    --workers 2 \         
    --bind unix:/apps/venvs/test_project/run/test_project.sock \         
    --access-logfile /apps/venvs/test_project/logs/access.log \         
    --error-logfile /apps/venvs/test_project/logs/error.log \         
    "pybo:create_app()"  
    
[Install] 
WantedBy=multi-user.target

참고

https://wikidocs.net/81078

4-11 웹 서버, Nginx 사용해서 파이보에 접속하기

여기서는 웹 서버 Nginx를 설치하고 사용해 보자. Nginx는 높은 성능을 목적으로 개발한 웹 서버로 파이썬 웹 프레임워크인 장고나 플라스크에서 많이 사용한다. Nginx를 …

wikidocs.net

https://velog.io/@odh0112/Django-Nginx-Gunicorn-%EC%97%B0%EB%8F%99-2-fb00a9kg

[Django] - Nginx + Gunicorn 연동 (2)

1. Nginx란 이전에 gunicorn을 이용해 서버 가동을 했다면 이제는 웹서버인 Nginx와 연동해 서비스를 꾸려나가볼 것입니다. 우선 Nginx는 트래픽이 많은 웹사이트의 서버(WAS)를 도와주는 고성능 경량 웹

velog.io

https://kscory.com/dev/nginx/setting

Uploaded by

N2T

[Gunicorn] RHEL9, Python 3.11 환경에서 Gunicorn(구니콘) 설치

코_노 — Sun, 29 Oct 2023 12:00:48 +0900

사전 요구 사항

Python, pip 설치 - https://co-no.tistory.com/entry/Python-RHEL9%EC%97%90%EC%84%9C-Python-311-%EC%84%A4%EC%B9%98-%EA%B0%80%EC%83%81%ED%99%98%EA%B2%BDvenv-%EA%B5%AC%EC%84%B1
내 환경의 경우, Python 3.11로 개발하였기 때문에 아래 문서 모두 Python 3.11, pip 3.11을 기준으로 한다.

0. 프로젝트에 대한 가상환경 활성화

gunicorn은 pip로 설치하는 Python 패키지이므로, gunicorn에서 띄우려는 애플리케이션(프로젝트)에 대한 가상환경을 구성한 후에 해당 가상환경을 활성화하도록 하자.

이 글의 예시에서는 배포하려는 애플리케이션의 이름을 ‘test_project’로 한다.

Python venv(가상환경) 활성화

# 'test_project'의 venv를 /apps/venvs/test_project 디렉토리에 이미 구성하였다고 가정한다.
source /apps/venvs/test_project/bin/activate

pip 최신화

그리고 pip 자체의 업데이트를 위해 다음 명령을 수행하자.

# 가상환경 안에서는 'pip3.11' 로 사용하지 않고, 'pip'로 사용해도 된다. 
pip install --upgrade pip

venv 내의 pip 필요 패키지 설치

pip 업그레이드도 되었으니, 이제 배포하려는 프로젝트에서 사용하는 패키지들을 서버 내 가상환경에 설치해주어야 한다.

# 가상환경 활성화 된 상태로 진행
# 개발자가 requirements.txt 를 줬다고 가정
pip install -r requirements.txt

가상환경에 flask와 관련 패키지 설치

pip install flask
pip install flask-migrate
pip install flask-wtf

1. gunicorn pip로 설치

# 'test_proejct' 가상환경이 activate 되어 있는 상태에서 수행
pip install gunicron

2. gunicorn 설치 및 동작 확인

2.1. gunicorn이 OS 상에서 어느 경로에 설치되어 있는지 확인

pip show gunicorn

→ 가상환경(venv)로 지정한 디렉토리 안에 gunicorn 또한 설치된 것을 확인할 수 있다.

2.2. gunicorn 정상 실행 확인

gunicorn 설치 경로로 이동

cd /apps/venvs/test_project/lib64/python3.11/site-packages

gunicorn 실행

gunicorn --bind 0.0.0.0:8000 [Flask 프로젝트명].wsgi &

--bind 0.0.0.0:8000 : 모든 IP의 접속에 대해 허용하고, 8000번 Port로 gunicorn을 서비스한다.
gunicorn 앞에 nohup을 붙이면, gunicorn을 실행시킨 SSH 세션이 끊어져도 gunicorn 서버(서비스)는 계속 On 상태가 된다.

2.3. 샘플 app을 gunicorn으로 구동

테스트 코드의 github 링크를 첨부하니, 이걸 사용해서 배포했을 때 정상적으로 페이지가 나타난다면, 일단 gunicorn 구동에는 문제가 없다고 보면 된다.

https://github.com/jjh2x/Flask_Sample_App

자 그럼 서버 환경에서 github의 위 샘플 코드를 받아와 보자.

# python 프로젝트 코드가 저장되는 디렉토리로 이동
cd /apps/projects

# Sample Flask Web App 프로젝트를 위의 예시와 맞추기 위해,
# 'test_project' 라는 이름으로 clone
git clone <https://github.com/jjh2x/Flask_Sample_App.git> test_project

클론이 완료되면 다음 명령어를 통해 아래 그림과 같은 결과를 확인할 수 있을 것이다.

ls
ls -al test_project/

gunicorn으로 샘플 앱 구동

github에서 받아 온 sample app은 ‘pybo’라는 이름으로 애플리케이션 팩토리가 정의되어 있다. (=init.py) 또한 해당 애플리케이션 팩토리 안에 ‘create_app()’ 이라는 함수가 정의되어 있다.

따라서 아래와 같이 gunicorn으로 해당 app을 구동하면 된다.

gunicorn --bind 0:8000 "pybo:create_app()" &

혹시 아래와 같은 페이지와 함께 sample app에 대한 접속이 되지 않는다면, 서버의 내부 방화벽에서 막고 있는 건 아닌지 확인이 필요하다. 필자는 테스트를 위해 내부 방화벽을 우선 다 내리고 진행하였다.

3. gunicorn의 로깅

우선 log가 쌓일 디렉토리를 만들기 위해 아래 명령어를 수행하자.

mkdir /apps/venvs/test_project/logs

이후 gunicorn 구동 시, --access-logfile, --error-logfile 플래그를 추가하여 다음과 같이 수행하면 된다.

gunicorn --bind 0:8000 --access-logfile /apps/venvs/test_project/logs/access.log --error-logfile /apps/venvs/test_project/logs/error.log

후.. gunicorn 하나 켜고 끄기 명령어가 너무 빡센 것 같다.

다음 포스팅에서 nginx와 gunicorn 연동 과정에서 gunicorn 서비스 파일도 만들 것이니, 일단은 임시로 위의 명령어를 사용하도록 하자…!

참고

https://wikidocs.net/81077

4-10 WSGI 서버 Gunicorn 사용하기

이제 파이보에서 사용할 WSGI 서버인 Gunicorn을 설치하고 사용해 보자. > Gunicorn은 구니콘이라고 읽는다. [TOC] ## Gunicorn 설치하고 사용해 …

wikidocs.net

https://velog.io/@yejin20/TILGunicorn-%EC%82%AC%EC%9A%A9-%EB%AA%85%EB%A0%B9%EC%96%B4

[TIL]Gunicorn 사용하기

Gunicorn은 Green Unicorn이라는 뜻으로 Python WSGI HTTP 서버다.웹서버와 WAS 사이를 연결하는 인터페이스로 파이썬에서는 wsgi를 사용하고 있다.이렇게 서버를 실행하면 EC2를 종료해도 서버가 계속 켜져

velog.io

[Python] RHEL9에서 Python 3.11 설치, 가상환경(venv) 구성

코_노 — Sat, 28 Oct 2023 15:39:57 +0900

출처 : https://discover.hubpages.com/technology/Installing-Python-on-Red-hat-enterprise-Linux-RHEL-6-and-RHEL-7

0. dnf(yum) update

최신 패키지를 사용하도록 dnf 업데이트를 수행하자.

dnf update

1. Python 3.11 dnf로 설치

dnf install python3.11

→ dnf install python3 는 python 3.9 가 설치되므로, 유의하자!

2. Python 3.11 설치 확인

python3.11 --version

→ python 3.9 버전과 구분하기 위해, python3.11 을 구동하는 명령어는 default로 python3.11 로 설정되어 있다.

위 명령어 수행 시, 특정 버전이 나타난다면 설치는 잘 된 것이다!

pip를 설치하기에 앞서, Python은 Dependency 부분에서 꽤나 골치 아픈 언어이다. 사람들이 많이 사용하는 만큼, 업데이트 주기도 빠르다. 그리고 그 업데이트에 따라 변동사항이 꽤나 큰 경우도 많다. 따라서 Python을 개발 또는 운영 환경에 배포할 때에는 웬만하면, 아니 반드시.. 가상환경을 구성해서 각 프로젝트별로 애플리케이션 구동 환경을 구분지어야 한다.

가상환경의 필요성에 대한 글은 다음 글이 잘 설명해주는 것 같아 링크를 첨부한다.

https://heytech.tistory.com/316

3. Python 가상환경 구성

3.1. Python 애플리케이션이 배포될 폴더 생성

# /(root) 하위에 'apps' 라고 생성하기로 한다.
mkdir /apps

3.2. Python 가상환경(venv) 폴더 생성

# /apps 하위에 웹 애플리케이션이 올라갈 'projects' 폴더 생성
mkdir /apps/projects

# /apps 하위에 Python 가상환경을 구분시킬 'venvs' 폴더 생성
# 'venvs' 폴더 하위에 각 프로젝트명 또는 애플리케이션 이름별로 가상환경 폴더를 구성한다.
mkdir /apps/venvs

3.3. ‘venvs’ 폴더 하위에 프로젝트에 대한 가상환경 구성

# 이 글에서는 'test_project'라는 프로젝트를 예시로 사용하기로 한다.

# /apps/venvs 디렉토리로 이동
cd /apps/venvs

# RHEL9의 경우, venv 모듈이 별도 설치 없이 python3.11 만 설치해도 존재한다.
# 'venvs' 디렉토리 하위에 'test_project'라는 프로젝트의 가상환경 구성
python3.11 -m venv 'test_project'

3.4. ‘test_project’의 가상환경 진입

# 'test_project' 프로젝트의 가상환경 디렉토리로 이동
cd /apps/venvs/test_project

여기에서 ls -al 또는 ll 을 입력하면, python으로 가상환경을 구성했을 때 어떠한 디렉토리들이 생성되는지 다음과 같이 확인할 수 있다!

그리고 다음 명령어를 통해 실제 ‘test_project’의 가상환경을 작동시켜보자.

# 'test_project'의 가상환경 작동
source /apps/venvs/test_project/bin/activate

가상환경이 활성화되면, 다음과 같이 Shell 앞에 (venv 이름) 이 생긴다.

가상환경에서 벗어나고 싶다면, 가상환경의 shell에서 deactivate 를 아무데에서나 입력하면 된다.

참고

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/installing_and_using_dynamic_programming_languages/assembly_installing-and-using-python_installing-and-using-dynamic-programming-languages

[MSSQL] SQL Server Linked Server(연결된 서버) 추가와 로그인 매핑정보 / 삭제

코_노 — Fri, 20 Oct 2023 14:59:51 +0900

SQL Server (MSSQL)의 Linked Server(연결된 서버)란?

: 데이터베이스 엔진에서 다른 SQL Server 인스턴스 또는 Oracle과 같은 이기종 데이터베이스 제품의 테이블을 포함하는 Transact-SQL 문을 실행할 수 있도록 설정하는 것이다.

Linked Server 를 Configuration 하는 데에 있어, 서버의 기능 및 필수 Parameter는 MS 공식 문서에서 제공하는 일반적인 예시와는 크게 다를 수 있다고 공식 문서에서도 명시되어 있으니, 다양한 케이스에 따라 많은 학습이 필요할 것으로 보인다.

필자의 경우에는, SSMS GUI로는 원인 파악이 제대로 되지 않는(?) 다양한 에러(대부분 복잡한 권한 문제가 아닐까 싶다…)가 나는 것 같아, 아래와 같이 쿼리로 확실하게 수행하는 법을 기록해 두고자 한다.

0. 현재 시스템의 Linked Server 확인 쿼리

/* 현재 시스템에 세팅되어 있는 Linked-Server 확인 쿼리 */
SELECT * 
FROM master.dbo.sysservers
WHERE srvname = '[연결된 서버별칭]'

/* 현재 시스템에 세팅되어 있는 Linked-Server의 로그인 매핑 정보 확인 쿼리 */
SELECT *
FROM master.sys.linked_logins
WHERE remote_name = '[Remote DB 로그인 계정]'

1. Linked Server 추가

EXEC sp_addlinkedserver
	@server = N'[연결된 서버 별칭]'
	, @srvproduct = N'[OLE DB Source DB의 제품 이름]'
	, @provider = N'[OLE DB Provider의 PROGID(프로그래밍 식별자)]'
	, @datasrc = N'{IP},{PORT}'          -- PORT 생략 시 OLE DB의 Default 포트로 연결

/* 예시 */
EXEC sp_addlinkedserver
	@server = N'REMOTE_DB_TEST'
	, @srvproduct = N''                    -- 공식문서에 기본값이 Null이라고 되어 있지만, 이렇게 빈 문자열로 명시해주어야 에러 없이 생성이 된다.
	, @provider = N'SQLOLEDB'
	, @datasrc = N'10.123.123.123,55555'

2. 생성된 Linked Server에 대한 로그인 계정 매핑 정보 추가

로그인 계정 매핑 정보를 반드시 추가할 필요는 없다.

만약 추가하지 않는다면, ‘NT AUTHORITY\ANONYMOUS LOGON’ 계정으로 연결을 시도하는데, 일반적으로 접근 권한이 제한되어 있다. 따라서 연결이 안될 것이다. 보안상 연결이 안 되는 것이 맞다.

필자의 경우, SSMS의 GUI로 설정하는 건 parameter가 내가 의도하는 대로 설정이 되지 않는지, 아래와 같은 에러가 뜨면서 연결 테스트 진행이 되지 않아, SP(Stored Procedure)로 수행하였다.

Access to the remote server is denied because no login-mapping exists 에러

따라서 아래와 같이 Linked-Server에 대한 로그인 계정 매핑 정보도 별도로 추가해 주어야 한다.

EXEC sp_addlinkedsrvlogin
	@rmtsrvname = N'[연결된 서버 별칭]'
	, @useself = N'FALSE'              -- 로컬 로그인 계정으로 원격 로그인 계정에 그대로 사용할지 말지 정하는 옵션
	, @locallogin = N'[Local DB의 올바른 권한을 가진 계정]'
	, @rmtuser = N'[Remote DB의 올바른 권한을 가진 계정]'
	, @rmtpassword = N'[Remote DB 계정의 Password]'

/* 예시 */
EXEC sp_addlinkedsrvlogin
	@rmtsrvname = N'REMOTE_DB_TEST'
	, @useself = N'FALSE'
	, @locallogin = N'LOCALDBADM'
	, @rmtuser = N'REMOTEDBADM'
	, @rmtpassword = N'My_Password123~!'

useself 의 값을 TRUE로 할 경우, 현재 로컬 서버의 로그인 계정으로 로그인을 하게 되는데,
만약 원격 DB 서버에 동일한 이름의 계정이 없거나 필요한 권한을 가지고 있지 않으면, 로그인이 되지 않아 Linked-Server를 사용할 수 없으니, 이 점 유의하자!

3. 생성된 Linked Server 연결 테스트

SSMS의 DB 인스턴스 - [서버 개체] - [연결된 서버] - 해당 연결된 서버 마우스 우클릭 - '연결 테스트'

유의할 점 : Linked-Server를 만든 계정은 System Admin 권한을 가졌을 것이고, 이는 로그인 계정 매핑에 사용된 계정과는 다를 가능성이 높다. (SA 권한을 거기에 박는건 보안상 너무 위험하니까…) 따라서, 위와 같은 SSMS GUI 상의 [연결 테스트]는 로그인 계정으로 들어간 계정으로 다시 DB에 로그인하여 테스트 해야 한다. 이는 Linked-Server를 이용하는 프로시저와 Agent Job을 테스트 할 때에도 마찬가지이다.

Linked-Server 삭제 방법

Linked-Server 삭제를 할 때에는 로그인 매핑 정보를 먼저 삭제한 후, Linked-Server 개체를 삭제해야 한다.

SP로 수행하려면 다음 쿼리를 순서대로 수행하면 된다.

/* Linked-Server 로그인 매핑 정보 삭제 SP */
EXEC sp_droplinkedsrvlogin
    @rmtsrvname = N'[연결된 서버 별칭]'
    , @locallogin = N'[로그인 매핑 정보의 Local 로그인 계정]'

/* Linked-Server 개체 삭제 SP */
EXEC sp_dropserver
	@server = N'[연결된 서버 별칭]'

/* 예시 */
EXEC sp_drolinkedsrvlogin
	@rmtsrvname = N'REMOTE_DB_TEST'
	, @locallogin = N'LOCALDBADM'

EXEC sp_dropserver
	@server = N'REMOTE_DB_TEST'

참고

https://learn.microsoft.com/ko-kr/sql/relational-databases/system-stored-procedures/sp-addlinkedserver-transact-sql?view=sql-server-ver16

sp_addlinkedserver(Transact-SQL) - SQL Server

sp_addlinkedserver(Transact-SQL)

learn.microsoft.com

https://learn.microsoft.com/ko-kr/sql/relational-databases/system-stored-procedures/sp-addlinkedsrvlogin-transact-sql?view=sql-server-ver16

sp_addlinkedsrvlogin(Transact-SQL) - SQL Server

sp_addlinkedsrvlogin(Transact-SQL)

learn.microsoft.com

https://blog.naver.com/diceworld/220311810558

MSSQL 연결된서버 사용하기 (linked server)

- MSSQL 연결된 서버란? MSSQL 은 연결된서버 기능을 ...

blog.naver.com

[보안] SSH Protocol의 암호화, Hashing 알고리즘 (feat. Linux OpenSSH)

코_노 — Mon, 18 Sep 2023 12:00:12 +0900

OpenSSH 기준으로, SSH의 암호화 또는 Hashing과 관련된 알고리즘의 분류를 다음과 같이 4가지 정도로 할 수 있다.

Key Exchange Algorithms
MAC Algorithms
Ciphers
HostKey Algorihtms

SSH 프로토콜에서 통신을 할 때에는 SSH Client와 SSH Server 간에 위 알고리즘에 대해 서로 일치하는 게 반드시 1개는 필요하다.

/etc/ssh/ssh_config 에는 해당 host가 SSH Client로 동작할 때에 지원하는 알고리즘 리스트가 나와 있다. 즉, 해당 configuration을 통해 weak algorithms을 인위적으로 제외시킬 수 있다는 것이다. 만약 KexAlgorithms, MACs, Ciphers, HostKeyAlgorithms 와 같은 구문이 없다면, 해당 OpenSSH 버전에서 Default로 지원하는 알고리즘 set을 사용하고 있는 것이다.

/etc/ssh/sshd_config 는 해당 host가 SSH Server로 동작할 때에 지원하는 알고리즘 리스트가 나와 있다. 해당 configuration을 통해 weak algorihtms 을 인위적으로 제외시킬 수 있다는 것이다. 사실상 SSH Server 쪽의 weak algorithms 들을 제외하여 원천적으로 차단하는 것이 보안 적용에 효과적이므로, 원격 제어 자주 당하거나(?) SFTP 서버 등으로 활용되는 Host의 경우, 반드시 sshd_config 를 철저하게 설정해 주어야 한다.

Key Exchange Algorihtms

: SSH 프로토콜에서 Client와 Server 간에 Public Key(공개키)를 주고 받는데, 이 공개키를 기반으로 암호화 및 복호화에 사용되는 대칭키를 생성하게 된다. 이러한 SSH 프로토콜 상 Client와 Server간에 Public Key를 주고 받는 과정 자체가 보호되어야 하기 때문에, 이 교환 과정에서 사용되는 알고리즘을 말한다.

OpenSSH - 현재 Host가 SSH Server로 동작할 때 지원하는 Key Exchange Algorithms 확인 방법

sshd -T | grep -oP '(?<=^kexalgorithms\\s)\\S+'

MAC Algorithms

: SSH 프로토콜에서 Client와 Server 간에 데이터를 주고 받을 때, 해당 데이터가 올바른 Client 또는 올바른 Server로부터 온 게 맞는지 확인하기 위한 Hashing 알고리즘이다. 즉, 데이터의 무결성을 보장하기 위한 알고리즘이다.

OpenSSH - 현재 Host가 SSH Server로 동작할 때 지원하는 MAC Algorithms 확인 방법

sshd -T | grep -oP '(?<=^macs\\s)\\S+'

Ciphers

: SSH 프로토콜에서 Client와 Server 간에 주고 받는 데이터의 실질적인 내용을 암호화하는 알고리즘Set이다. SSH Server에서 설정되어 있는 순서에 따라, Cipher Suite 채택에 대한 Preference가 결정된다.

Client로부터 받은 Cipher Suite 중에서 Server가 지원하는 Cipher Suite와 일치하는 것을 확인하고, 그 중 Server에서 가장 앞에 설정된 Cipher Suite가 Client 및 Server 간에 주고 받는 데이터에 대한 암호화 알고리즘set으로 채택된다.

OpenSSH - 현재 Host가 SSH Server로 동작할 때 지원하는 Cipher Algorithms 확인 방법

sshd -T | grep -oP '(?<=^ciphers\\s)\\S+'

HostKey Algorithms

: SSH 프로토콜에서 Client 및 Server의 Host Key를 생성하고 검증하는 데 사용되는 암호화 알고리즘이다. 여기서 Host Key란, 해당 SSH Client에 대한 Server를 인증할 때 사용되는 Key이다.

OpenSSH - 현재 Host가 SSH Server로 동작할 때 지원하는 HostKey Algorithms 확인 방법

sshd -T | grep -oP '(?<=^hostkeyalgorithms\\s)\\S+'

[Protocol] SSH의 개념, 통신 과정(feat. OpenSSH)

코_노 — Sun, 17 Sep 2023 23:35:18 +0900

SSH(시큐어 셸, SecureSHell) 란?

: 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에서 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해 주는 응용 프로그램 또는 그 프로토콜을 가리킨다.

- 위키백과 -

Default로 22번 포트를 사용
Sender - Receiver 간 주고 받는 데이터 자체가 암호화되어, 해당 패킷이 스니핑 되더라도 복호화할 수 있는 Key를 획득하지 못하면 해당 정보를 알 수 없게끔 설계되어 있다.
SSH Client : SSH 프로토콜을 이용하여 원격 시스템(SSH Server)에 접속 및 명령을 내리도록 하는 주체
SSH Server : SSH Client로부터 SSH 프로토콜을 통해 받은 명령을 수행하는 주체(?). 쉽게 말해, 원격지 서버 또는 컴퓨터.

등장 배경

사실 원격 시스템에서의 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해주는 동일한 기능을 가진 응용 프로그램은 기존에도 있었다.

rsh, rlogin, telnet, ftp 등이 그것들인데, 이러한 응용 프로그램 또는 프로토콜들은 세션을 맺는 과정 또는 데이터를 통신하는 과정 등에서 암호화가 되어 있지 않아, *스니핑(Sniffing) 공격에 늘 노출되어 있었다.

✳ 스니핑(Sniffing) : 사전적 의미로는 ‘코를 킁킁거리다’, ‘냄새를 맡다’로, IT 용어에서는 송신자(Sender)와 수신자(Receiver) 간 교환되는 패킷 정보를 네트워크 상에서 도청하는 행위를 말한다.

SSH 통신 과정

1. Session Authentication

SSH Client와 Server 간 세션이 맺어지려면, Client와 Server 가 서로가 올바른 노드인지 인증하는 절차가 필요하다. SSH 프로토콜에서는 이를 Public Key(공개키)와 Private Key(개인키)로 이루어지는 비대칭키 암호화 방식을 이용한다.

세션이 맺어지기 전부터 이러한 인증 과정을 거치는 이유는, SSH Client 가 최초에 요청한 SSH Connection Request를 Attacker가 가로채어 SSH Server인 척 하지 못하게 하려는 이유이다.

Linux 에서는 대부분 OpenSSH 라는 프로그램을 통해 SSH 프로토콜을 이용하게 된다.

SSH 프로토콜은 기본적으로 Client의 Public Key, Private Key / Server의 Public Key, Private Key 가 갖추어져 있어야만 통신이 가능하다.

우선 SSH 프로토콜의 세션 인증 과정이 어떻게 진행되는 지 다음 그림을 통해 살펴보자.

SSH 프로토콜에서 SSH Client와 SSH Server 간 세션을 맺는 인증 과정

✳ KEX : SSH에서 Key Exchange Algorithm 을 가리키는 말로, SSH Client와 Server가 서로의 Public Key를 공유할 때, Attacker가 해당 Public Key를 가로채어 SSH Client인 척 또는 SSH Server인 척 하지 못하도록 방지하는 알고리즘이다. 여기서 알아두어야 할 점은, 이 KEX 알고리즘은 암호화 알고리즘이 아니며, 서로 간 안전하게 Public Key를 공유할 수 있도록 해주는 알고리즘이라는 점이다.

✳ 해시 함수(Hashing) : 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 함수.

해시 함수에 의해 만들어진 출력값을 가지고 역으로 입력값을 찾는 것이 계산적으로 불가능하기 때문에, 암호화-복호화의 용도로 보기에는 어렵다.

SSH 프로토콜에서는, SSH Connection 이 성공적으로 이루어지기 전에, 즉 위 과정 중간에 Attacker가 잠입하여 교환되는 모든 정보를 조작할 수도 있으므로, 이를 방지하기 위해 **Sender 가 보낸 메시지가 변조되지 않았는지 확인(데이터의 무결성 보증)**하는 절차가 존재한다. 이 때 사용하는 알고리즘이 MAC(Message Authentication Code) Algorithms 이다.

2. User Authentication

위 세션 인증 과정을 거쳐 SSH Client와 SSH Server 간에 Connection이 열리게 되면, 이제 접속을 시도하는 User가 접속 권한이 있는 사람인지 확인하는 절차가 필요하다. 즉, 위 세션 과정에서 정상적인 과정을 거쳐 정상적으로 SSH Conneciton이 생성되었다 하더라도, SSH Client를 사용하는 유저 자체가 Attacker였다면, 말짱 도루묵이 된다.

SSH 프로토콜에서 유저에 대한 Authentication을 하는 방법은 크게 2가지가 있다.

2.1. Password 인증

사용자가 입력한 비밀번호를 Session Authentication 과정에서 생성한 Session Key로 암호화하여 SSH Server에게 보내고, 이를 SSH Server가 검증하면 끝나는 방식
보안상 권장하지 않는 방식이다.
- Attacker가 Brute-Force 공격으로 Password를 알아낼 수 있다.
- 사용자가 PW를 까먹어버리면 큰일이다!

2.2. Key-Pair 인증

SSH Client에서 Public Key, Private Key를 생성하고, 이를 SSH Server에 접속할 때 Public Key를 제출하여 인증되는 방식
Password 방식보다 높은 수준의 보안이다.
- SSH Server에 기존에 등록되어 있는 user 및 host가 아니라면, 일단 Attakcer의 host라고 의심하고 보는 것이다.
- Key-Pair 인증 방식을 적용하려면, 최초에 SSH Client가 ssh-copy-id 명령어를 사용하여 SSH Server에 Public Key 파일을 보내주어야 한다. 이때 SSH Server에 대한 PW를 입력하여, SSH Server에 Public Key 파일을 넣을 수 있도록 한다.
- SSH Server에서 접속을 허용하는 Client의 Public Key가 authorized_keys 파일에 한번 등록되었다면, SSH Client는 추후 접속에서 해당 Key 파일에 대한 Passphrase를 입력하기만 하면 SSH 접속이 가능해진다. (Passphrase는 SSH Client에서 ssh-keygen 명령어를 이용하여 키 파일을 생성할 때 입력할 수도 있고, 입력하지 않으면 Passphrase는 존재하지 않게 된다.)

SSH Protocol의 User Athentication - Key-Pair 인증 방식

참고

https://veneas.tistory.com/entry/Linux-%EB%A6%AC%EB%88%85%EC%8A%A4-ssh-%EB%8F%99%EC%9E%91-%EB%B0%A9%EC%8B%9D-%EC%84%A4%EC%B9%98-%EB%B0%8F-%EC%82%AC%EC%9A%A9%EB%B2%95

[Linux] 리눅스 ssh 동작 방식, 설치 및 사용법

목차 1. SSH SSH 이란 Secure Shell Protocol의 약자로, FTP / Telnet에 비해 보안에 초점을 맞춘 Protocol입니다. 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에서 명령을 실행하고 다른 시스템으

veneas.tistory.com

https://gwonbookcase.tistory.com/56

SSH 공개키 인증 과정

1. 공개키 암호화란? 공개 키 암호 방식은 암호 방식의 한 종류로 사전에 비밀 키를 나눠가지지 않은 사용자들이 안전하게 통신할 수 있도록 한다. 공개 키 암호 방식에서는 공개 키와 비밀 키가

gwonbookcase.tistory.com

https://swalloow.github.io/ssh-tunneling/

SSH 프로토콜과 Tunneling 이해하기

지금까지 아무 생각없이 SSH를 사용하다가 한번 정리해보았습니다. SSH Protocol SSH는 Secure Shell의 약자입니다. SSH는 한마디로 정의하면, 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에

swalloow.github.io

https://seunghyunson.tistory.com/4

SSH란 무엇일까?

SSH란 무엇일까? SSH를 왜 사용할까? SSH의 장단점은? GitHub 계정 연동까지! 다들 한 번쯤 SSH라는 단어를 들어보거나 본 적이 있을 것입니다. GitHub에서 repository를 clone 받을 때도 등장하고, 배포용으

seunghyunson.tistory.com

[MSSQL] SQL Server의 메모리 관련 문제를 진단하는 1차적인 방법

코_노 — Mon, 21 Aug 2023 17:00:42 +0900

시작하기에 앞서, 이 포스팅 하나만으로 SQL Server의 Memory Pressure (메모리 압박)을 진단하는 것은 섣부른 판단일 수 있다. 정확한 Memory Pressure를 진단하고 그것을 개선하는 프로세스는 상당히 디테일하게 진행이 되어야 하므로,

굉장히 긴 튜닝의 여정이 될 수 있다는 점을 미리 알아두자.

일단 Memory Alert 이 떴다든가, 유저가 쿼리 결과가 너무 늦는다거나와 같은 얘기를 들었을 때,

우리는 SQL Server 상에서 Memory Pressure가 일어났을 것이라는 짐작해볼 수 있다.

다음은 가장 먼저 시도해 볼 간단한 쿼리 3가지를 소개한다.

1. sys.dm_os_sys_memory

: OS level 에서의 설정된(?) 메모리 관련 정보를 반환하는 테이블

SQL Server는 기본적으로, OS level에 있는 external memory 조건과 하드웨어 기반의 물리적인 제한(물리적인 메모리 양 등)에 맞춰 제한되고 반응한다.

따라서 가장 첫 번째로, OS level 에서의 메모리 사용량이 어떻게 되는 지를 우선 체크해봐야 할 것이다.

SELECT [Total Physical Memory in MB] = total_physical_memory_kb/1024
	, [Physical Memory Available in MB] = available_physical_memory_kb/1024
	, system_memory_state_desc
FROM sys.dm_os_sys_memory

total_physical_memory : OS가 사용할 수 있는 물리적인 메모리 전체 총량
available_physical_memory : total_physical_memory 에서 가용 가능한 남은 용량
system_memory_state_desc : system_high_memory_signal_state 와 system_low_memory_signal_state 의 값에 따라 문구가 정해지는 column
- Available physical memory is high) system_high_memory_signal_state = 1 / system_low_memory_signal_state = 0 ⇒ 가용가능한 Physical Memory 양이 충분하다.
- Available physical memory is low) system_high_memory_signal_state = 0 / system_low_memory_signal_state = 1 ⇒ 가용가능한 Physical Memory 양이 부족하다.
- Physical memory usage is steady) system_high_memory_signal_state = 0 / system_low_memory_signal_state = 0 ⇒ 가용가능한 Physical Memory 가 충분하지도, 부족하지도 않게 적절하다.
- Physical memory state is transitioning) system_high_memory_signal_state = 0 / system_low_memory_signal_state = 0 ⇒ 가용가능한 Physical Memory 가 급격하게 변화하는 순간에 이 쿼리가 수행되었다면 나올 수 있는 값이다.
- 위 값에서 실제 메모리 문제로 인식되는 것은 ‘Available physical memory is low’ 라고 보면 될 것이다.

2. sys.dm_os_process_memory

: OS level 에서 프로세스에 할당된 메모리를 확인할 수 있는 테이블

SELECT [Physical Memory Used in MB] = physical_memory_in_use_kb/1024
	, [Physical Memory Low] = process_physical_memory_low
	, [Virtual Memory Low] = process_virtual_memory_low 
FROM sys.dm_os_process_memory

physical_memory_in_use_kb : OS에 보고된, 프로세스에서 실제 사용하는 메모리 분량을 KB 단위로 나타낸 값
process_physical_memory_low : 0 또는 1의 값으로, process 에서 사용 가능한 physical memory양이 부족할 때 1로 반응하는 값이다.
process_virtual_memory_low : 0 또는 1의 값으로, process 에서 사용 가능한 virtual memory (Physical memory 가 아닌 영역, 페이지 파일 등) 의 양이 부족할 때 1로 반응하는 값이다.
- process_physical_memory_low 값과 process_virtual_memory_low 값 중 둘 중 하나라도 1이 나온다면, Memory Pressure의 원인을 면밀히 조사해 볼 필요가 있다.

3. sys.dm_os_sys_info

: Computer(노드)에 대한 다양한 metric과 현재 가용 가능하거나 SQL Server에 의해 소비되고 있는 리소스에 대한 정보를 반환하는 테이블

SQL Server 2008 버전에서 사용)

SELECT [Physical Memory in MB] = physical_memory_in_bytes/1024/1024
	, [Virtual Memory in MB] = virtual_memory_in_bytes/1024/1024
	, [SQL Server Committed Memory in MB] = bpool_committed/1024
	, [SQL Server Target Committed Memory in MB] = bpool_commit_target/1024 
FROM sys.dm_os_sys_info

SQL Server 2012 이상 버전에서 사용)

SELECT [Physical Memory in MB] = physical_memory_kb/1024
	, [Virtual Memory in MB] = virtual_memory_kb/1024
	, [SQL Server Committed Memory in MB] = committed_kb/1024
	, [SQL Server Target Committed Memory in MB] = committed_target_kb/1024 
FROM sys.dm_os_sys_info

physical_memory_kb | physical_memory_in_bytes : 해당 machine의 physical memory 총량
virtual_memory_kb | virtual_memory_in_bytes : 해당 machine의 virtual memory 총량
committed_kb | bpool_committed : SQL Server memory manger에 의해 커밋된(committed) 메모리 양
committed_target_kb | bpool_commit_target : SQL Server memory manager에 의해 소비될 수 있는 메모리 총량으로, 예상치를 의미한다. 이 값에 따라 SQL Server memory manager가 committed 메모리 양을 늘릴지 또는 축소할 지를 결정한다.
- committed_target_kb > committed_kb
  ⇒ SQL Server Memory Manager가 추가적인 메모리를 더 잡으려고 할 것이다. Memory Pressure 가 없이 아직 여유 있는 상태라고 봐도 무방하다.
- committed_target_kb ≤ committed_kb
  ⇒ SQL Server Memory Manager가 현재 커밋된 메모리를 줄일려고 할 것이므로, 현재 가용가능한 Memory 양을 봐야 한다. 만약 (committed_kb - committed_target_kb) 값이 가용 가능한 Memory 양보다 크다면, Memory Pressure 가 일어나고 있다고 볼 수 있을 것이다.

만일 위 3개의 쿼리 수행 결과, 좋지 않은 징후를 발견했다면, 현재 서버가 Memory Pressure에

있다고 보고 면밀히 조사하는 것이 좋을 것이다.

[Prometheus] node_exporter와 Windows_exporter 에 적용시키는 샘플 rules.yml

코_노 — Fri, 31 Mar 2023 16:18:53 +0900

프로메테우스로 전사의 서버를 커버하려면, Linux 와 Windows Server 에 따라서 exporter 가 다르므로, 서로 다르게 rule을 적용시켜줘야 할 필요가 있다.

아래 샘플은 CPU usage, Memory Usage, Disk Space 를 기준으로 alert을 받기 위한 rules.yml 이다.

참고로 rules.yml 의 파일명은 자유롭게 설정 가능하다!

Linux) node_exporter 를 통해 metric을 수집하므로, 아래의 node_exporter_rules.yml 을 적용 받는다.

# 'node_exporter_rules.yml'

groups:
  - name: custom_rules
    rules:
      - record: node_CPU_Usage_percent
        expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m]) * 100))

      - record: node_Memory_Usage_percent
        expr: 100 - ((node_memory_MemAvailable_bytes * 100) / node_memory_MemTotal_bytes)

      - record: node_Filesystem_Free_percent
        expr: 100 * node_filesystem_free_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}

  - name: alert_rules
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Instance [{{ $labels.instance }}] down"
          description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute."
     
      - alert: High_CPU_Usage_80
        expr: node_CPU_Usage_percent >= 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Instance [{{ $labels.instance }}] CPU Usage High - 80%"
          description: "[{{ $labels.instance }}] has ben exceeded 80% of CPU usage in the last 5 minutes."
      
      - alert: High_CPU_Usage_90
        expr: node_CPU_Usage_percent >= 90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Instance [{{ $labels.instance }}] CPU Usage High - 90%"
          description: "[{{ $labels.instance }}] has ben exceeded 90% of CPU usage in the last 5 minutes."

      - alert: High_Memory_Usage_80
        expr: node_Memory_Usage_percent >=80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Instance [{{ $labels.instance }}] Memory usage High - 80%"
          description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been exceeded {{ $value }}% or more of Memory usage."
       
      - alert: High_Memory_Usage_90
        expr: node_Memory_Usage_percent >= 90
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "Instance [{{ $labels.instance }}] Memory usage High - 90%"
          description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been exceeded {{ $value }}% or more of Memory usage."
         
      - alert: DiskSpace_Free_10
        expr: node_Filesystem_Free_percent <= 10
        labels:
          severity: critical
        annotations:
          summary: "Instance [{{ $labels.instance }}] has 10% or less Free disk space"
          description: "[{{ $labels.instance }}] has only {{ $value }}% or less free."
      
      - alert: DiskSpace_Free_20
        expr: node_Filesytem_Free_percent <= 20
        labels:
          severity: warning
        annotations:
          summary: "Instance [{{ $labels.instance }}] has 20% or less Free disk space"
          description: "[{{ $labels.instance }}] has only {{ $value }}% or less free."

Windows Server) windows_exporter 를 통해 metric을 수집하므로, 아래의 windows_exporter_rules.yml 을 적용 받는다.

# 'windows_exporter_rules.yml'

groups:
  - name: custom_record
    rules:
      - record: Windows_Server_CPU_Usage
        expr: 100 - (avg by (instance) (rate(windows_cpu_time_total{mode="idle"}[2m])) * 100)

      - record: Windows_Server_Memory_Usage
        expr: 100 - ((windows_os_physical_memory_free_bytes / windows_cs_physical_memory_bytes) * 100)

      - record: Windows_Server_DiskSpace_Usage
        expr: 100 - (windows_logical_disk_free_bytes{volume!~"HarddiskVolume.+"} / windows_logical_disk_size_bytes{volume!~"HarddiskVolume.+"})*100


  - name: alert_rules
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Instance [{{ $labels.instance }}] down"
          description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute."
      
      - alert: Windows_Server_CPU_Usage_90
        expr: Windows_Server_CPU_Usage >= 90
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "Instance [{{ $labels.instance }}] CPU Usage High - 90%"
          description: "[{{ $labels.instance }}] has ben exceeded 90% of CPU usage in the last 3 minutes."
      
      - alert: Windows_Server_CPU_Usage_80
        expr: Windows_Server_CPU_Usage >= 80
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "Instance [{{ $labels.instance }}] CPU Usage High - 80%"
          description: "[{{ $labels.instance }}] has ben exceeded 80% of CPU usage in the last 3 minutes."
       
      - alert: Windows_Server_Memory_Usage_90
        expr: Windows_Server_Memory_Usage >= 90
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "Instance [{{ $labels.instance }}] Memory Usage High - 90%"
          description: "[{{ $labels.instance }}] has ben exceeded 90% of Memory usage in the last 3 minutes."
      
      - alert: Windows_Server_Memory_Usage_80
        expr: Windows_Server_Memory_Usage >= 80 unless on(instance) {instance="예외 적용시킬 호스트의 IP:Port"}
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "Instance [{{ $labels.instance }}] Memory Usage High - 80%"
          description: "[{{ $labels.instance }}] has ben exceeded 80% of Memory usage in the last 3 minutes."

      
      - alert: Windows_Server_DiskSpace_Usage_90
        expr: Windows_Server_DiskSpace_Usage >= 90
        labels:
          severity: critical
        annotations:
          summary: "Instance [{{ $labels.instance }}] has 10% or less Free disk space"
          description: "Disk usage is more than 90%\n LABELS = {{ $labels }}\n VALUE = {{ $value }}"

위 샘플의 'Windows_Server_Memory_Usage_80' 이라는 이름의 alert을 보면, expr 에 unless on 구문도 사용 가능한 것을 확인할 수 있다.

unless on([앞 promquery 결과 값의 label]) {labelname="원하는 조건"}

위와 같이 사용하여, unless 기준 앞 구절의 결과로 나온 값에서 원하는 label 을 기준으로 하여 해당 label의 특정 값을 가지면, 이 alert을 적용시키지 않도록 하는 구문이다.

또한 lable set ({~}) 구문에서 =~ Operator로 정규식 형태로 표현도 가능하다. 예시는 아래와 같다.

unless on(instance) {instance=~"(A_HOSTNAME)|(B_HOSTNAME)"}

rules.yml 파일 내의 내용이 syntax에 어긋나지 않는 지 확인하기

bin/promtool check rules rules/node_exporter_rules.yml

Promquery를 사용하면서 유용한 rules.yml 에 대한 문법들을 알게 되면 여기에 추가적으로 기록할 예정이다.

참고

https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/

Alerting rules | Prometheus

An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.

prometheus.io

https://awesome-prometheus-alerts.grep.to/rules.html

Awesome Prometheus alerts

Collection of alerting rules

awesome-prometheus-alerts.grep.to

https://stackoverflow.com/questions/69435005/use-conditional-operator-in-prometheus-alert-rules-to-set-severity

[MSSQL] SQL Server 호스트의 Disk Space Alert 설정하기 / Powershell 방식 VS MSSQL 쿼리 방식

코_노 — Fri, 31 Mar 2023 10:09:04 +0900

DBA로서, 데이터베이스가 저장되는 Disk의 Space를 관리하는 일은 대단히 중요하다.

데이터 파일이 저장될 Disk의 용량이 부족하다면, 당연하게도 데이터가 계속적으로 증가하는 서비스는 멈추게 된다.

따라서 DBA는 데이터베이스가 저장되는 Disk의 Space를 수시로 확인하여 용량이 부족할 경우, 스토리지 담당자와 컨택하여 최대한 빠르게 스토리지 공간을 늘리는 것이 중요하다. 그러기 위해서는 Disk Space를 수시로 체크하고 DBA와 스토리지 담당자에게 Alert을 보내는 시스템을 구축해야 한다.

이번 포스팅에서 그 Alert 시스템 구축에 대해 간단히 알아보자!

이 포스팅에서는 크게 2가지 방법을 소개한다. 첫번째는 Powershell 스크립트 방법, 두번째는 MSSQL 쿼리를 활용한 방법에 대해 알아볼 것이다. 또한 alert 시스템은 실제 Production 환경에서 5분 단위로 job이 돌게끔 지정하기도 하는데, 이렇게 자주 도는 만큼 서버의 리소스를 많이 차지하면 안되므로, 어떤게 더 리소스 효율적인지도 알아보자!

1. Powershell 스크립트 방식

# SQL Server가 설치되어 있는 hostname을 'hostname' 변수에 담기
$hostname=Get-WMIObject Win32_ComputerSystem | Select-Object -ExpandProperty name

# 임계치 설정 (GB)
# powershell의 hashtable 자료형으로 선언. Disk의 Drive Letter와 Threshold 값을 매칭시킨다.
$thresholdList = @{
    # Threshold 값은 각 드라이브 Total Size의 10% 정도로 잡았다.
    C = 20
    D = 50
    K = 15
    L = 10
    M = 0.05
    T = 2.5
    S = 1
}

# 이메일 정보 설정
$smtpServer = "SMTP Server IP"
$smtpPort = [SMTP Server Port]
$username = "SMTP Server Authentication Username"
$password = "SMTP Server Authentication Password"
$from = "Alert 메일의 보내는 이를 지정"
$to = "Alert 메일이 가는 대상을 지정, 여러 명 가능"
$subject = "$hostname : DISK Space Alert"	# $hostname 변수를 사용하여 Alert의 대상이 되는 호스트네임을 메일 제목에 확인하기 쉽게 넣기
$body = ""	# 메일의 내용에 해당하는 부분으로, 아래 foreach 구문 위해 빈 str으로 지정

# 드라이브 목록 설정
$drives = Get-PSDrive -PSProvider FileSystem | Where-Object { $_.Free -ne $null -and $_.Root -notlike '*swdist*' }

# 각 드라이브별 공간 확인
foreach ($drive in $drives) {
    $driveLetter = $drive.Root	# C 드라이브를 예로 들면, 'C:\' 가 'driveLetter' 변수에 담기게 됨.
    $pdriveLetter = $driveLetter[0]	# 'C:\'에서 첫번째 문자인 'C'만 추출.

    $freeSpace = [math]::Round($drive.Free / 1GB, 2)	# GB 단위로 체크할 것이므로, '1GB' 로 나눈다.
    $totalSpace = [math]::Round(($drive.Used + $drive.Free) / 1GB, 2)
    $percentFree = [math]::Round(($freeSpace / $totalSpace) * 100, 2)


    # 각 드라이브별로 threshold 값 체크하여 body 메시지 작성해주기.
    # 드라이브의 남은 용량이 threshold 값보다 작을 경우, body에 메시지를 추가한다.
    if ($freeSpace -lt $thresholdList["$pdriveLetter"]) {
        $body = $body + "`n`n" + "'$hostname' : Drive $driveLetter is running low on disk space (Free: $freeSpace GB, Total: $totalSpace GB, Free %: $percentFree %)"
    }
    # 명목상 powershell 상에서 else문을 타는지 확인하기 위함.
    else {
        Write-Host "'$hostname' : Drive $driveLetter is available."
    }
}

# 'body' 변수가 빈 문자열이 아니라면 이메일 발송
if ($body -ne "") {
    Send-MailMessage -SmtpServer $smtpServer -Port $smtpPort -From $from -To $to -Subject $subject -Body $body    
}

2. MSSQL 쿼리 방식

MSSQL 쿼리 방식은 [msdb] 를 활용한다. 참고로 SQL Server에서 [msdb] 란, SQL Server 엔진을 설치하면 기본으로 생성되는 시스템 데이터베이스로, SQL Server Agent의 Alerts 및 Jobs 를 예약하고, SSMS, Service Broker 및 Database Mail과 같은 기타 기능에 사용되는 데이터베이스이다.

MSSQL 쿼리 방식의 디스크 여유 공간을 확인하는 로직은 Powershell과 비슷하다.

[현재 드라이브들의 남은 용량을 테이블에 기록한다.]

-> [각 드라이브별 Threshold를 기록해놓은 테이블을 참조한다.]

-> [지정해놓은 Threshold보다 드라이브의 남은 용량이 작다면, 메일의 내용 부분에 해당하는 변수에 담는다.]

-> [최종적으로 메일의 내용 부분에 해당하는 변수를 파라미터로, 메일을 전송한다.]

위 과정을 수행하기 위해서는 먼저 [msdb]에 테이블을 생성해야 한다.

2-1. Disk Space의 Threshold 정보를 지정하여 넣을 테이블 생성 - 'driveThreshold'

/* Disk Space Threshold 테이블 생성 */

USE [msdb]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[driveThreshold](
	[drive_letter] [varchar](1) NOT NULL,
	[total_size_MB] [int] NULL,
	[threshold_size_MB] [int] NULL,
	[is_check] [int] NULL,	-- is_check는 해당 드라이브에 대하여 alert 을 적용할 지 말지 선택할 때 사용한다.
PRIMARY KEY CLUSTERED 
(
	[drive_letter] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[driveThreshold] ADD  DEFAULT ((1)) FOR [is_check]
GO

2-2. 드라이브별 Threshold 값 지정하여 'diskThreshold' 테이블에 넣기

우선, OS의 각 드라이브별 총 사이즈를 확인하기 위해 다음 쿼리 'xp_cmdshell' 을 이용할 건데, 이는 sp_configure를 통해 xp_cmdshell 이 수행되도록 전역 설정 변경이 필요하다. 아래 쿼리를 수행하여 xp_cmdshell 을 enable 설정하자. 보안상 계속 enable 해두는 것은 위험하므로, 이 2-2. 마무리 단계에 xp_cmdshell 을 다시 disable 할 것이다.

EXECUTE sp_configure 'show advanced options', 1
GO
RECONFIGURE 	-- reconfigure 명령어는 'ALTER SETTINGS' 서버 수준 권한 또는  sysadmin 및 serveradmin 고정 서버 역할이 필요하다.
GO

EXECUTE sp_configure 'xp_cmdshell', 1;
GO
RECONFIGURE
GO

EXECUTE sp_configure 'show advanced options', 0
GO
RECONFIGURE
GO

OS에 mount 되어 있는 drive 의 총 사이즈 (=Capacity), 사용 가능 공간 (=Free Space) 로 임시테이블 생성

DECLARE @svrName VARCHAR(255)
DECLARE @sql VARCHAR(400)

SET @svrName = @@SERVERNAME
SET @sql = 'powershell.exe -c "Get-WmiObject -ComputerName ' + QUOTENAME(@svrName,'''') + ' -Class Win32_Volume -Filter ''DriveType = 3'' | select name,capacity,freespace | foreach{$_.name+''|''+$_.capacity/1048576+''%''+$_.freespace/1048576+''*''}"'

--creating a temporary table
CREATE TABLE #output
(line varchar(255))

--inserting disk name, total space and free space value in to temporary table
INSERT INTO #output
EXEC xp_cmdshell @sql

GO

/* diskThreshold 테이블에 각 드라이브별 Threshold 값 지정  */

-- 위 #output 임시 테이블 통해 드라이브별 총 사이즈를 'driveThreshold' 테이블에 삽입
INSERT INTO [msdb].[dbo].[driveThreshold] ([drive_letter], [total_size_MB])
--script to retrieve the values in MB from PS Script output
	SELECT RTRIM(LTRIM(SUBSTRING(line,1,CHARINDEX('|',line) -3)))		AS [drive_name]
	   , ROUND(CAST(RTRIM(LTRIM(SUBSTRING(line,CHARINDEX('|',line)+1,
	   (CHARINDEX('%',line) -1)-CHARINDEX('|',line)) )) AS Float),0)	AS [Capacity (MB)]
	FROM #output
	WHERE line like '[A-Z][:]%'
	ORDER BY [drive_name]

-- driveThreshold 테이블 데이터 Insert 잘 되었는지 확인
SELECT * FROM [msdb].[dbo].[driveThreshold]

-- Threshold 값 일괄적으로 각 드라이브의 Total Size * 0.1 (10%) 로 변경하기
UPDATE [msdb].[dbo].[driveThreshold]
SET [threshold_size_MB] = [total_size_MB] * 0.1

--'driveThreshold' 테이블 값 삽입하기 위해 만들었던 임시테이블 삭제
DROP TABLE #output

GO

xp_cmdshell disable 설정

EXECUTE sp_configure 'show advanced options', 1
GO
RECONFIGURE 	-- reconfigure 명령어는 'ALTER SETTINGS' 서버 수준 권한 또는  sysadmin 및 serveradmin 고정 서버 역할이 필요하다.
GO

EXECUTE sp_configure 'xp_cmdshell', 0;
GO
RECONFIGURE
GO

EXECUTE sp_configure 'show advanced options', 0
GO
RECONFIGURE
GO

2-3. 쿼리가 수행되는 순간의 각 드라이브 여유 공간을 기록할 테이블 생성 - 'driveAvailable'

/* 현재 드라이브의 남은 용량을 기록할 테이블('driveAvailable') 생성 */

USE [msdb]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[driveAvailable](
	[id] [int] IDENTITY(1,1) NOT NULL,		-- 드라이브 사이즈 기록의 순번 용도
	[drive_letter] [varchar](1) NULL,
	[drive_available_MB] [int] NULL,
	[datetime] [datetime] NULL,				-- 드라이브 사이즈를 체크한 순간의 시간 기록
PRIMARY KEY CLUSTERED 
(
	[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[driveAvailable] ADD  DEFAULT (getdate()) FOR [datetime]
GO

2-4. SQL Server Agent의 Job 으로 등록할 쿼리 (Job step의 Type을 T-SQL로 지정)

USE [msdb]

SET NOCOUNT ON	-- 쿼리 수행결과 중 영향받은 행 수를 나타내는 메시지 반환을 하지 않겠다.

DECLARE @subjectstr varchar(100)
	, @querystr varchar(1000)
	, @limit int, @rowcnt int

INSERT INTO msdb.dbo.driveAvailable(drive_letter, drive_available_MB) 
EXEC xp_fixeddrives

SET @rowcnt = @@rowcount

SET @subjectstr = @@servername + ': DISK Space Alert'	--메일 제목
SET @querystr ='
SELECT ''"'' + @@servername +''": ''+ da.drive_letter + '' drive is '' + convert(varchar(10), convert(numeric(5,2), ((drive_available_MB/(total_size_MB * 1.0)) * 100))) + '' % remained. ('' + convert(varchar(10), drive_available_MB) + '' MB available)''
FROM msdb.dbo.driveThreshold t 
	JOIN (
	    SELECT TOP (' + CONVERT(VARCHAR(10), @rowcnt) + ') * 
	    FROM msdb.dbo.driveAvailable ORDER BY id DESC
	    ) da 
	ON t.drive_letter = da.drive_letter
WHERE is_check = 1
	AND da.drive_available_MB < t.threshold_size_MB
' -- 메일 내용에 해당


IF(EXISTS(
	SELECT *
	FROM msdb.dbo.driveThreshold t 
		JOIN (SELECT TOP (@rowcnt) * FROM msdb.dbo.driveAvailable ORDER BY id DESC) da ON t.drive_letter = da.drive_letter
	WHERE t.is_check = 1
		AND da.drive_available_MB < t.threshold_size_MB
		)
)
BEGIN
	EXEC msdb.dbo.sp_send_dbmail  
		@profile_name = 'SSMS Database Mail Profile',		-- SSMS 상의 Database Mail 에 설정되어 있는 Profile명
		@recipients = 'alert 메일 갈 메일 주소. 여러개 가능.',	-- alert 메일이 갈 대상
		@query =  @querystr,  
		@subject = @subjectstr,  
		@attach_query_result_as_file = 0
END

2.5. 매일 일정한 시간에 따라 변화된 Disk Space 값 조회

SELECT [id]
	, [drive_letter]
	, [drive_available_MB]
	, [datetime]
FROM [msdb].[dbo].[driveAvailable]
WHERE [drive_letter] = 'F'
	AND [datetime] >= DATEADD(DAY, -100, GETDATE())	-- 최근 100일 동안의 데이터
	AND CONVERT(VARCHAR, [datetime], 8) BETWEEN '08:00:00.000' AND '08:05:00.000' -- 5분 단위로 Disk Space를 기록한다고 했을 때, 매일 8시 00분대의 데이터 조회 위함 
ORDER BY [datetime] DESC

3. 결론

Intel Xeon의 8코어(logical 16코어) CPU로 테스트 해본 결과, Windows의 Performance Monitor의 %Processor Time 메트릭 기준으로, Powershell 스크립트 기반으로 동작하는 Agent Job은 순간적으로 5%~7% 가량의 CPU 부하율을 보였고,

T-SQL 스크립트 기반으로 동작하는 Agent Job은 순간적으로 1~3% 가량의 CPU 부하율을 보였다.

단순 Percentage 값으로 보면 최대 6% 차이이지만, 이러한 job을 수많은 트랜잭션이 오고 가는 Production 서버에서 5분 단위로 수행한다면, 이 6%가 어마어마한 차이를 낼 수도 있을 것이라 생각한다.

따라서, SQL Server 의 데이터 파일이 차지하는 드라이브의 Disk Alert을 보내는 시스템은 가능하면 위 두 방법 중 T-SQL 기반으로 하는 방법을 채택하는 게 올바른 것으로 보인다.

혹여나 Disk 의 현재 용량을 측정하고 기록해두는 테이블(driveAvailable) 자체가 차지하는 용량이 많지 않을까도 염려스러웠는데, 계산해보면 이렇다.

id - int : 4바이트
drive_letter - varchar(1) : 1바이트
drive_available_MB - int : 4바이트
datetime - datetime : 8바이트

한 Row 당(한 드라이브에 대한 정보) 총 17바이트로, 위 예시에서는 체크하는 드라이브 개수가 6개, 이를 5분 단위로 한다고 했을 경우 1시간에 12번 job이 돌고, 이를 1년으로 환산할 경우의 driveAvailable 테이블 용량은 다음과 같다.

(17*6) * 12 * 24 * 365 = 10,722,240 바이트 = 10.22 MB 이다.

즉, 이러한 job을 Windows의 Drive Letter 최대 개수인 26개로 잡고, 10년동안 돌려도 500 MB 가 안된다. 그러니 'driveAvailable' 테이블이 차지하는 용량은 신경 쓰지 않아도 된다!

참고

https://learn.microsoft.com/ko-kr/sql/relational-databases/databases/msdb-database?view=sql-server-ver16

msdb 데이터베이스 - SQL Server

msdb 데이터베이스

learn.microsoft.com

https://learn.microsoft.com/ko-kr/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql?view=sql-server-ver16

int, bigint, smallint 및 tinyint(Transact-SQL) - SQL Server

Int, bigint, smallint, tinyint 데이터 형식의 Transact-SQL 참조입니다. 해당 데이터 형식은 정수 데이터를 나타내는 데 사용됩니다.

learn.microsoft.com

https://www.mssqltips.com/sqlservertip/2444/script-to-get-available-and-free-disk-space-for-sql-server/

Script to Get Available and Free Disk Space for SQL Server

Often we face the situation where we need to check the total disk space and available disk space for both physical and LUN/Mount drives. The extended stored procedure XP_FixedDrives is unable to help us in this scenario, so we have to log into the machine

www.mssqltips.com

[Prometheus] Metric의 Threshold를 지정하고 AlertManager로 메일 통해 알람 받기

코_노 — Sat, 18 Mar 2023 16:55:20 +0900

1. Prometheus의 Alertmanager 플러그인 설치

# alertmanager 설치 파일 다운로드
# cd ~/Downloads
# wget https://github.com/prometheus/alertmanager/releases/download/v0.25.0/alertmanager-0.25.0.linux-amd64.tar.gz
# tar -xzvf alertmanager-0.25.0.linux-amd64.tar.gz
# rm -rf alertmanager-0.25.0.linux-amd64.tar.gz

# alertmanager 유저 추가
# useradd --no-create-home --shell /bin/false alertmanager

# alertmanager의 디렉토리를 opt 하위로 이동 및 관리 편의를 위한 logs, conf, bin, data 디렉토리 생성
# mv ~/Downloads/alertmanager-0.25.0.linux-amd64 /opt/alertmanager
# mkdir /opt/alertmanager/logs /opt/alertmanager/conf /opt/alertmanager/bin /opt/alertmanager/data
# mv /opt/alertmanager/alertmanager.yml /opt/alertmanager/conf
# mv /opt/alertmanager/alertmanager /opt/alertmanager/bin/
# mv /opt/alertmanager/amtool /opt/alertmanager/bin/

# alertmanager HOME 디렉토리 권한 부여
# chown -R alertmanager:alertmanager /opt/alertmanager

# vi /etc/sysconfig/alertmanager 로 'alertmanager' 환경변수 위한 파일 생성

# /etc/sysconfig/alertmanager 파일

ALERTMANAGER_USER=alertmanager

ALERTMANAGER_GROUP=alertmanager

ALERTMANAGER_HOME=/opt/alertmanager

LOG_DIR=/opt/alertmanager/logs

DATA_DIR=/opt/alertmanager/data

CONF_DIR=/opt/alertmanager/conf

CONF_FILE=/opt/alertmanager/conf/alertmanager.yml

# Only used on systemd systems
PID_FILE_DIR=/var/run/alertmanager

# alertmanager service 등록
# vi /usr/lib/systemd/system/alertmanager.service 로 'alertmanager.service' 파일 생성

# alertmanager.service 파일 내용

[Unit]
Description=Alertmanager
Wants=network-online.target
After=network-online.target

[Service]
EnvironmentFile=/etc/sysconfig/alertmanager
PIDFile=/var/run/alertmanager.pid

User=alertmanager
Group=alertmanager
Type=simple
Restart=always
WorkingDirectory=/opt/alertmanager
RuntimeDirectory=alertmanager
RuntimeDirectoryMode=0750
ExecStart=/opt/alertmanager/bin/alertmanager    \
    --config.file=${CONF_FILE}                  \
    --storage.path=${DATA_DIR}/                 \
    --cluster.listen-address=                   \


[Install]
WantedBy=multi-user.target

- alertmanager가 정상 설치 되었는지 확인하기 위해 alertmanager 웹 콘솔 접속하기

# alertamanger.service 가동
systemctl start alertmanager.service

alertmanager 서버를 작동시킨 후, {alertamanger 를 설치한 IP}:9093 (Default Port) 로 접속하면, alertmanager 가 정상 설치 및 정상 가동 되었다면 아래와 같은 화면을 볼 수 있다.

Alertmanager 웹 콘솔 화면

- 프로메테우스의 alert 시스템을 설치한 'alertmanager' 로 등록하기

# vi /opt/prometheus/conf/prometheus.yml 로 prometheus.yml 파일 수정

# /opt/prometheus/conf/prometheus.yml 파일의 'alerting:' 부분

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["your_alertmanager_IP:9093"]

# promtool check config <config-files> 로 prometheus.yml 검증하기

# /opt/prometheus/bin/promtool check config /opt/prometheus/conf/prometheus.yml

# 변경된 prometheus.yml 적용하기 위해 프로메테우스 서버 재시작 하기

# systemctl restart prometheus.service

2. 프로메테우스의 rules.yml 설정

# 프로메테우스가 설치되어 있는 경로로 이동
# cd /opt/prometheus

# 'rules' 라는 디렉토리 생성 - rule과 관련된 yml 파일들을 따로 모아두기 위함.
# mkdir rules

# 'rules' 디렉토리가 root 계정으로 생성되었으므로, 권한 부여하기
chown -R prometheus:prometheus /opt/prometheus/

- rules.yml 생성 (여기서는 이름을 'test-rules.yml' 로 지정하겠다.)

# vi /opt/prometheus/rules/test-rules.yml 로 'test-rules.yml' 생성

# /opt/prometheus/rules/test-rules.yml 파일

groups:
  - name: custom_rules
    rules:
      - record: node_memory_MemFree_percent
        expr: 100 - (100 * node_memory_MemFree_bytes / node_memory_MemTotal_bytes)

      - record: node_filesystem_free_percent
        expr: 100 * node_filesystem_free_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}

  - name: alert_rules
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Instance [{{ $labels.instance }}] down"
          description: "[{{ $labels.instance }}] of job [{{ $labels.job }}] has been down for more than 1 minute."
          
      - alert: DiskSpaceFree10Percent
        expr: node_filesystem_free_percent <= 10
        labels:
          severity: warning
        annotations:
          summary: "Instance [{{ $labels.instance }}] has 10% or less Free disk space"
          description: "[{{ $labels.instance }}] has only {{ $value }}% or less free."

- 생성한 rule 파일을 prometheus 에 인식시키기.

rule 파일의 syntax error 등이 없는 지, 다음 명령어를 통해 확인한다.

# 생성한 rule 파일에 prometheus로 소유권 변경
chown prometheus:prometheus /opt/prometheus/rules/test-rules.yml

# 프로메테우스 설치 경로의 'promtool' 명령어 통해 확인
# promtoll check rules { rule.yml의 경로 }
# /opt/prometheus/bin/promtool check rules /opt/prometheus/rules/test-rules.yml

# vi /opt/prometheus/conf/prometheus.yml 수행하여 아래 문구 추가

# /opt/prometheus/conf/prometheus.yml 파일

rule_files:
  - "/opt/prometheus/rules/test-rules.yml"

# prometheus.yml 변경사항 적용 위한 프로메테우스 재시작
# systemctl restart prometheus.service

- prometheus 서버에 rules가 적용되었는지 확인하기

{프로메테우스가 설치된 서버 IP}:9000/rules 페이지

3. alertmanager.yml 설정

- alertmanager.yml 파일 내용 작성

# /opt/alertmanager/conf/alertmanager.yml 파일

global: 	
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: 'Receiver Name'
   
receivers:
  - name: 'Receiver Name'
    email_configs:
      - to: 'your-email@yourdomain.com'
        from: 'Prometheus_Alert@yourdomain.com'
        smarthost: 'your_smtp_server_IP:your_smtp_port'
        auth_username: 'your_smtp_auth_username'
        auth_password: 'your_smtp_auth_password'
        require_tls: false		# 디폴트가 true인데, 테스트하려는 smtp 서버가 tls 인증을 지원하지 않는 경우, false로 지정해야 메일이 성공적으로 발송된다.

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'instance']

global : Alertmanager 전반에 적용되는 설정

resolve_timeout : alert이 EndsAt(해당 사안 종료 시각)을 명시하지 않을 경우, 이 옵션으로 설정해놓은 시간이 지나면, alert을 Alertmanager에서 Resolve 처리하게 된다. 기본값은 5m
smtp_* : Alertmanager가 이메일 알림을 보낼 때 사용하는 SMTP 서버와 인증 정보를 global로도 박을 수 있다. receiver의 대상 메일 서버가 하나인 경우 주로 global로 박아서 사용하게 될 것이다.
구체적인 내용은 '참고'의 프로메테우스 공식 문서 참고.
slack_* : Alertmanager가 Slack 메시지를 보낼 때 사용하는 webhook URL과 인증 토큰을 설정.
구체적인 내용은 '참고'의 프로메테우스 공식 문서 참고.
pagerduty_* : Alertmanager가 PagerDuty 알림을 보낼 때 사용하는 인증 토큰을 설정.
구체적인 내용은 '참고'의 프로메테우스 공식 문서 참고.

route : alert 라우팅 규칙을 정의

receiver : alert을 수신하는 대상을 지정. 여러 대상 지정 가능
group_by : alert을 그룹화하는 기준을 설정. alert이 발생한 대상에 대한 label 등을 기준으로 그룹화 하는 설정
group_wait : alert 그룹에 대한 notification 을 다시 보내기 전, 얼마나 기다려야 하는지를 설정. 기본값은 30s
만약 이 시간 내에 [group_by] 의 동일한 label을 가진 다른 alert이 발생한다면, 해당 그룹에 추가하고, 다시 또 다른 alert 오는지 대기했다가, 없을 경우에 지금까지 온 해당 그룹의 모든 alert 을 notify 한다.
group_interval : 아직 resolved 되지 않은 alert에 대해 반복 알림(notification)을 보내기 전, 대기하는 시간을 설정.
기본값은 5m
repeat_interval : 반복적으로 알림을 보내는 경우, 알림을 보내는 간격을 설정. 기본값은 3h

receivers : 알림(notification)을 수신하는 대상의 정보를 정의

email_configs : 이메일로 알림을 보내는 경우 사용되는 SMTP 서버 및 수신자 정보를 설정
webhook_configs : 웹훅을 사용하여 알림을 보내는 경우, 웹훅 End point 와 인증 정보를 설정
pagerduty_configs : PagerDuty 알림을 수신하는 경우, 서비스와 인증 토큰을 설정
slack_configs : Slack 메시지를 수신하는 경우, 웹훅 URL과 인증 토큰을 설정

inhibit_rules: source_match 에서 지정한 label에 해당하는 label을 가진 alert이 이미 있다면, target_match 에서 지정한 label에 해당하는 label을 가진 alert에 대한 notification 은 하지 않도록 지정하는 설정

source_match : 이 단락에 명시된 조건을 충족하면, inhibit_rule 을 적용하게 된다. 따라서 이 단락에 명시된 조건에 해당하는 alert만 notify 한다.
target_match : 이 단락에 명시된 조건의 alert은 notify 되지 않는다.
equal : 동일한 alert을 평가하는 기준으로, 위 예시에서는 alert의 이름과 해당 alert이 발생한 instance가 동일하다면, 동일한 alert으로 보고, severity 가 warning인 alert은 무시하고, severity가 critical 인 alert만 notify 하게 된다.

- alertmanager.yml 파일 검증

작성한 alertmanager.yml 파일의 syntax error 등은 없는지 확인한다.

# amtool check-config {alertmanager.yml의 경로}
# /opt/alertmanager/bin/amtool check-config /opt/alertmanager/conf/alertmanager.yml

# alertmanager.yml 적용시키기 위해 alertmanager 재시작하기
# systemctl restart alertmanager.service

- alertmanager.yml 파일 적용이 되었는지 프로메테우스 콘솔 창에서 확인

프로메테우스 콘솔창의 [Alerts] 메뉴에서 'InstanceDown' 과 'DiskSpaceFree10Percent' 가 적용됨을 확인할 수 있다.

참고

https://prometheus.io/docs/alerting/latest/alertmanager/

Alertmanager | Prometheus

An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.

prometheus.io

https://godekdls.github.io/Prometheus/alerting.configuration/

Alert Configuration

Alertmanager 설정 가이드

godekdls.github.io

https://medium.com/techno101/how-to-send-a-mail-using-prometheus-alertmanager-7e880a3676db

How to Send a Mail Using Prometheus Alertmanager?

How to create Alerting Rules? Install and configure Alertmanager to send mail on alert firing.

medium.com

https://awesome-prometheus-alerts.grep.to/rules.html#windows-server

Awesome Prometheus alerts

Collection of alerting rules

awesome-prometheus-alerts.grep.to

-> Alert rules 작성 예시 참고하기 좋은 사이트!

[Prometheus] Node Exporter 를 CentOS 7 서버에 설치하기

코_노 — Thu, 16 Mar 2023 12:13:36 +0900

1. Node Exporter 설치

서버 리소스 metric이 모니터링 되는 대상 서버를 이제부터 클라이언트라고 칭하겠다.

클라이언트에 Node Exporter 를 설치해야만, 프로메테우스가 Node Exporter로부터 metric을 수집해 올 수 있다.

Node Exporter 설치 방법을 살펴보자!

프로메테우스의 Node Exporter는 아래 github 에서 설치할 수 있다.

https://github.com/prometheus/node_exporter/releases/tag/v1.5.0

Release 1.5.0 / 2022-11-29 · prometheus/node_exporter

NOTE: This changes the Go runtime "GOMAXPROCS" to 1. This is done to limit the concurrency of the exporter to 1 CPU thread at a time in order to avoid a race condition problem in the Linux kernel (...

github.com

리눅스 서버에서 명령어를 통한 설치는 아래와 같다.

# Node_Exporter를 설치하려는 디렉토리로 이동
# 나는 나중에 어디에 설치되어 있는지 확인하기 쉽게, /usr/share/에 'node_exporter' 라는 디렉토리를 따로 만들었다.
$ cd /usr/share/node_exporter

# 설치하려는 클라이언트의 Linux 버전에 따라 설치 파일이 다르다. 유의하자.
$ wget https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-amd64.tar.gz

# 다운로드 받은 파일 압축 해제
$ tar -xzvf ./node_exporter-1.5.0.linux-amd64.tar.gz

2. Node Exporter 를 서버 부팅과 함께 실행하도록 service 파일 만든 후, 실행하기

# 서비스 파일 생성
# vi /usr/lib/systemd/system/node_exporter.service

# /usr/lib/systemd/system/node_exporter.service 파일

[Unit]
Descripion=Node Exporter
After=network.target

[Service]
User=root
Group=root
Type=simple
ExecStart=/usr/share/node_exporter/node_exporter

[Install]
WantedBy=multi-user.target

# 작성한 서비스 파일 systemctl로 불러오기
# systemctl daemon-reload

# 부팅 시 자동실행 되도록 enable 설정하기
# systemctl enable node_exporter.service

# Node_Exporter 실행하기
# systemctl start node_exporter.service

위 과정을 거쳐 node_exporter 를 실행한 후, 브라우저에서 아래 URL로 접속하면 클라이언트의 metric이 프로메테우스가 가져올 수 있는 형태로 수집되는 것을 확인할 수 있다. 디폴트 포트가 9100 으로 설정되어 있다는 것을 알아두자!

{node_exporter가 설치된 서버의 IP}:9100/

{node_exporter가 설치된 서버의 IP}:9100/metrics

3. 프로메테우스 서버에 모니터링 할 클라이언트(Node_exporter가 설치된 서버) 등록하기

# 프로메테우스가 설치된 서버

# 프로메테우스로 유저 전환
# su - prometheus

# 프로메테우스 서버의 설정파일 변경
$ vi $PROMETHEUS_HOME/prometheus.yml

# 'scrape_configs' 에 아래 내용 추가 또는 변경

  - job_name: "프로메테우스에서 인식할 job name으로 설정"
    
    static_confgis:
      - target: ["{Node_Exporter가 설치된 서버 IP}:9100"]

참고

https://sanggi-jayg.tistory.com/104

Prometheus + Node Exporter + Grafana 연동

프로메테우스 설치 https://prometheus.io/ # 유저 추가 useradd -m -s /bin/bash prometheus su - prometheus # 다운로드 cd /home/prometheus wget https://github.com/prometheus/prometheus/releases/download/v2.28.0/prometheus-2.28.0.linux-amd64.tar

sanggi-jayg.tistory.com

[Grafana] CentOS 7 에서 Grafana(Prometheus 데이터를 시각화해주는 서버) 설치하고 프로메테우스와 연동하기

코_노 — Thu, 16 Mar 2023 10:21:21 +0900

0. 현재 Grafana 릴리즈된 버전 확인하기

https://grafana.com/grafana/download/9.4.3?edition=oss

Download Grafana | Grafana Labs

Overview of how to download and install different versions of Grafana on different operating systems.

grafana.com

2023.03.16 기준, 9.4.3 버전이 최신 버전이므로, 아래 설치 과정도 9.4.3 버전(OSS) 로 진행하겠다.

1. Grafana 설치

# 그라파나 다운로드
# cd ~
# wget https://dl.grafana.com/oss/release/grafana-9.4.3-1.x86_64.rpm
# 위 다운로드 링크는 설치하려는 그라파나의 버전, OS 버전에 따라 달라진다.

# 다운로드 받은 그라파나 rpm파일을 yum으로 설치 진행
# 추후 취약성 등의 보안 패치 등을 수월하게 하기 위해 yum 으로 수행
# yum install ~/grafana-9.4.3-1.x86_64.rpm

# 'grafana' 유저 추가는 선택 사항. (yum으로 설치 시, /sbin/nologin 으로 grafana 계정 생성된다.)
# useradd -m -s /bin/bash grafana

# 'grafana' 유저로 전환 (yum으로 진행 시 X)
# su - grafana

2. yum 으로 설치 된 Grafana의 각종 디렉토리 및 파일 확인

Grafana 엔진(GRAFANA_HOME) 디렉토리

# Grafana 엔진 디렉토리 확인하기
# ls -al /usr/share/grafana

/usr/share/grafana

┖ bin/

┖ conf/

┖ plugins-bundled/

┖ public/

┖ VERSION

Grafana의 환경변수

# Grafana의 환경변수 확인하기
# vi /etc/sysconfig/grafana-server

GRAFANA_USER=grafana

GRAFANA_GROUP=grafana

GRAFANA_HOME=/usr/share/grafana

LOG_DIR=/var/log/grafana

DATA_DIR=/var/lib/grafana

MAX_OPEN_FILES=10000

CONF_DIR=/etc/grafana

CONF_FILE=/etc/grafana/grafana.ini

RESTART_ON_UPGRADE=true

PLUGINS_DIR=/var/lib/grafana/plugins

PROVISIONING_CFG_DIR=/etc/grafana/provisioning

# Only used on systemd systems
PID_FILE_DIR=/var/run/grafana

Grafana의 서비스 파일(grafana-server.service) 확인

# Grafana의 service 파일 확인하기
# vi /usr/lib/systemd/system/grafana-server.service

[Unit]
Description=Grafana instance
Documentation=http://docs.grafana.org
Wants=network-online.target
After=network-online.target
After=postgresql.service mariadb.service mysqld.service

[Service]
EnvironmentFile=/etc/sysconfig/grafana-server
User=grafana
Group=grafana
Type=notify
Restart=on-failure
WorkingDirectory=/usr/share/grafana
RuntimeDirectory=grafana
RuntimeDirectoryMode=0750
ExecStart=/usr/share/grafana/bin/grafana server                                     \
                            --config=${CONF_FILE}                                   \
                            --pidfile=${PID_FILE_DIR}/grafana-server.pid            \
                            --packaging=rpm                                         \
                            cfg:default.paths.logs=${LOG_DIR}                       \
                            cfg:default.paths.data=${DATA_DIR}                      \
                            cfg:default.paths.plugins=${PLUGINS_DIR}                \
                            cfg:default.paths.provisioning=${PROVISIONING_CFG_DIR}

LimitNOFILE=10000
TimeoutStopSec=20
CapabilityBoundingSet=
DeviceAllow=
LockPersonality=true
MemoryDenyWriteExecute=false
NoNewPrivileges=true
PrivateDevices=true
PrivateTmp=true
ProtectClock=true
ProtectControlGroups=true
ProtectHome=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectProc=invisible
ProtectSystem=full
RemoveIPC=true
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true
SystemCallArchitectures=native
UMask=0027

[Install]
WantedBy=multi-user.target

3. Grafana 실행

Grafana 서버 실행

# 그라파나 서버 실행
# systemctl start grafana-server.service

# 그라파나 서버 실행 상태 확인
# systemctl status grafana-server

Grafana 웹 콘솔 접속

{그라파나가 설치된 IP}:3000/

-> 기본 포트는 3000이다.

접속하면 ID와 PW를 입력하라는 창이 나타나는데, Grafana를 설치한 후, 아무것도 설정하지 않은 채 바로 웹 콘솔에 접속하였다면, 초기 ID와 PW 는 'admin' / 'admin' 이다.

그라파나 웹 콘솔 화면

위와 같은 웹 콘솔 화면이 보인다면, grafana-server 실행은 정상적으로 잘 된 것이다.

4. Grafana 데이터 소스 추가

설치한 그라파나가 프로메테우스 서버의 metric 들을 가져오기 위해서는, 그라파나에 프로메테우스 Datasource 를 추가해주어야 한다.

추가 화면은 아래와 같다.

그라파나 웹 콘솔 - 왼쪽 메뉴의 [Configuration] - [Data sources] - 'Add data source' 클릭

'Add data source' 를 클릭하면 아래 그림처럼 추가할 수 있는 데이터소스 목록이 나오는데, 우리는 여기에서 'Prometheus'를 선택한다.

[Add data source] - 'Prometheus' 선택

그럼 아래 그림처럼 해당 데이터소스를 통해 어떤 서버를 바라볼 것인지부터 Scrape interval 등 다양한 옵션들을 지정해 줄 수 있는데, 적절히 선택 후에 'Save & test' 버튼을 클릭하면 된다.

그라파나 data source 설정 (1)

그라파나 data source 설정 (2)

5. Grafana에 Node_Exporter Metric 기반의 유용한 대시보드 구성 - 'Node Exporter Full'

그라파나 공식 사이트에는 여러 사람들이 커스터마이징 해놓은 대시보드들이 공유되어 있다.

대시보드의 내용은 datasource를 제외하고는 모두 json 으로 설정이 유지된다. 이 말인 즉슨, json 설정만 export 또는 import 하게 되면 그라파나 서버가 어디에 있든, 쉽게 해당 대시보드의 설정 및 패널을 공유하여 재사용성을 높일 수 있다!

이 포스팅에서는 Node_Exporter 메트릭에서 서버 모니터링을 수월하게 하도록 의미있는 정보들로 대시보드를 만들어놓은, 대표적인 대시보드인 'Node Exporter Full' 을 기준으로 살펴본다.

'Node Exporter Full' 대시보드 템플릿(?) 사이트

https://grafana.com/grafana/dashboards/1860-node-exporter-full

Node Exporter Full | Grafana Labs

Edit Delete Confirm Cancel

grafana.com

'Node Exporter Full' 대시보드 사이트

JSON 형태로도 다운 받을 수 있는데, 그라파나에 쉽게 바로 적용하기 위해 'Copy ID to clipboard' 로 이 대시보드의 ID만 복사해서 사용하자!

그라파나에 대시보드 ID로 대시보드 Import 하기

그라파나 웹 콘솔에서 왼쪽 메뉴의 [Dashboards] - [+ Import] 를 클릭하자!

그라파나 웹 콘솔 - 왼쪽의 [Dashboards] 메뉴 - [ + Import] 클릭

복사한 대시보드 ID를 입력하고 'Load' 버튼을 클릭하자!

[Import dashboard] 창 - 복사한 대시보드 ID 입력 - 'Load' 버튼 클릭

그럼 아래 그림처럼 이 대시보드를 어떤 이름으로, 어떤 폴더에 저장할 것이고, 어떤 데이터소스를 기반으로 할 것인지를 선택할 수 있다. 우리는 프로메테우스 서버의 데이터를 시각화하여 대시보드를 만드는 것이므로, 데이터 소스를 프로메테우스로 설정한 데이터소스로 잡아주자. 그리고 'Import' 버튼을 클릭하면 된다!

[Import dashboard] 창 - Options 작성 / 데이터소스를 프로메테우스 기반 데이터소스로 설정 - 'Import' 버튼 클릭

Import 된 'Node Exporter Full' 대시보드 확인

Import 된 'Node Exporter Full' 대시보드

참고

패스트캠퍼스 - '한 번에 끝내는 데이터 엔지니어링 초격차 패키지 Online' 중 Part.5 Observability - Ch 04_01. / Ch 04_02.

[MSSQL] Lock 상황 유발해보고, Lock을 유발하는 세션 찾아서 종료시키기

코_노 — Tue, 14 Mar 2023 16:37:51 +0900

Lock 유발시키기에 앞서, 아래 쿼리는 Lock을 인위적으로 유발하기 위해 사용하는 쿼리로, 인위적으로 트랜잭션의 수행시간을 1시간으로 지정한다.

현업의 운영 DB에서는 해당 쿼리를 절대 사용하면 안된다. 반드시 테스트 용도로만 사용해야 한다.

1. 테이블 Lock 걸리도록 하는 쿼리 수행

-- 테스트 DB로 SQL Server 에서 공식적으로 제공하는 'AdventureWorks2019' 샘플 DB를 사용한다.
USE AdventureWorks2019

-- 테스트 해볼 row를 조회하는 쿼리
SELECT ProductID, Name
FROM Production.Product
WHERE ProductID=999
-- 수행 결과 : ProductID: 999 / Name: Road-750 Black, 52

BEGIN TRAN
	UPDATE Production.Product SET Name='test'
    WHERE ProductID=999
    
    WAITFOR DELAY '01:00:00' 	-- 트랜잭션은 임의로 1시간 delay
   
COMMIT TRAN

위 쿼리를 수행한 후, 동일한 DB의 새 쿼리 창을 연 다음 아래 쿼리를 수행해보자.

SELECT ProductID, Name
FROM AdventureWorks2019.Production.Product
WHERE ProductID=999

그럼 결과는 아래와 같이, 당연하게도 1시간동안 트랜잭션으로 해당 테이블을 Lock 걸게 만들었으니, SELECT 쿼리가 수행되지 않을 것이다.

Lock 걸린 테이블을 조회해서 쿼리가 지연되는 상황

2. 현재 Lock 을 유발하는 쿼리가 사용하고 있는 데이터베이스의 ID 확인

해당 데이터베이스가 Lock 걸린 상황인 것을 확인했다면, 이제 그 데이터베이스의 개체 ID를 조회해보자!

'sys.dm_tran_locks' T-SQL 을 사용하기 위해 DB_ID를 확인하는 것이다.

-- name='Lock 걸린 데이터베이스 이름'
SELECT database_id, name FROM sys.databases
WHERE name = 'AdventureWorks2019'

Lock 걸린 데이터베이스인 'AdventureWorks2019' 의 DB_ID 확인

3. Lock 정보를 확인하기

-- Lock 정보를 조회하는 쿼리
-- resource_database_id = <dbid> 값에 위에서 조회한 데이터베이스의 ID를 넣어야 함.
SELECT resource_type, resource_associated_entity_id,  
    request_status, request_mode,request_session_id,  
    resource_description   
FROM sys.dm_tran_locks  
WHERE resource_database_id = 5

'sp_lock' 을 사용해도 되나, 이는 SQL Server 2016 버전 이후부터는 Deprecated 되어 더이상 권장하지 않는 방법이므로, 'sys.dm_tran_locks' 를 사용하자!

sys.dm_tran_locks 결과

위 결과를 보면, mode가 IX로 배타적 잠금에 걸린 걸 확인할 수 있다. Lock 걸린 개체(테이블)의 entity ID는 '72057594061783040' 인 것을 확인할 수 있고, Lock 을 잡고 있는 세션의 ID는 '52' 인 것을 기억해두자!

아래 쿼리는 entity ID 로 object ID를 알아보기 위한 쿼리이다. 참고로 알아두자.

SELECT object_name(object_id), *  
FROM sys.partitions  
WHERE hobt_id=72057594061783040

sys.partitions 쿼리 수행 결과

4. Lock 을 유발시키는 세션 ID를 통해 해당 세션이 수행한 스크립트를 확인해보자

-- Lock 을 유발시키는 Session_ID를 통해 해당 세션이 수행한 스크립트를 확인하는 T-SQL
-- DBCC INPUTBUFFER ('session_id')
DBCC INPUTBUFFER (52)

Lock 유발한 범인을 확인할 수 있다.

5. Lock을 유발한 세션 종료시키기

mass update 성격의 쿼리가 수행되는 세션을 함부로 종료했다가는 데이터의 정합성이 다 깨져버리니, 세션을 강제 종료시킬 때에는 정말 신중해야 한다.

※ 해당 세션을 종료시키게 되면, 쿼리가 중간에 수행되다 중단되는 것이기 때문에, 반드시 해당 애플리케이션 오너와 상의가 필요하다. 예를 들어, 회사에서 급여를 올리는 batch 를 돌렸는데 그 세션을 중간에 종료시켜버리면, 어떤 사람은 급여가 올라갔는데, 어떤 사람은 올라가지 않은 불상사가 발생할 수 있다.

-- 종료를 해도 되는 세션이라면 강제로 종료시키는 방법
-- 여기서는 일부러 딜레이 시키는 쿼리를 수행하는 세션이므로 종료시켜도 된다.
-- KILL 'session_id'
KILL 52

6. 원래 수행하려던 쿼리 수행하여 Lock 해제된 것 확인하기.

SELECT ProductID, Name
FROM AdventureWorks2019.Production.Product
WHERE ProductID=999

AdventureWorks2019 DB 의 Lock 이 해제되어 정상적으로 데이터가 조회된다.

참고

https://learn.microsoft.com/ko-kr/sql/relational-databases/system-dynamic-management-views/sys-dm-tran-locks-transact-sql?view=sql-server-ver16

sys.dm_tran_locks(Transact-SQL) - SQL Server

sys.dm_tran_locks(Transact-SQL)

learn.microsoft.com

[Prometheus] CentOS 7 에서 프로메테우스(Prometheus) 설치 및 기본 설정, 실행

코_노 — Tue, 14 Mar 2023 08:44:45 +0900

1. 프로메테우스 설치

# 'prometheus' 유저 추가
# useradd --no-create-home --shell /sbin/nologin prometheus

# 프로메테우스 다운로드
# cd ~/Downloads
# wget https://github.com/prometheus/prometheus/releases/download/v2.42.0/prometheus-2.42.0.linux-amd64.tar.gz
# 위 다운로드 링크는 설치하려는 프로메테우스의 버전, OS 버전에 따라 달라진다.

# 다운로드 받은 프로메테우스 tar.gz 파일 압축 풀기
# tar -xzvf prometheus-2.42.0.linux-amd64.tar.gz

# prometheus 설치 경로 변경
# mv ~/Downloads/prometheus-2.42.0.linux-amd64 /opt/prometheus

# 관리 편의를 위한 디렉토리 생성
# mkdir /opt/prometheus/bin /opt/prometheus/conf /opt/prometheus/data

# prometheus HOME 디렉토리 권한 부여
# chown -R prometheus:prometheus /opt/prometheus

2. 프로메테우스 실행

# 프로메테우스 설치 경로로 이동
$ cd /opt/prometheus

# 프로메테우스 서버 실행
$ ./prometheus --config.file=/opt/prometheus/conf/prometheus.yml

프로메테우스 실행 성공 출력 화면 - "Starting rule manager..." 를 확인하기

- 프로메테우스 접속 - default는 9090 포트

http://{프로메테우스 올라간 서버 IP 또는 DNS 호스트네임}:9090/

ex) http://10.0.2.15:9090/

위 url로 접속이 된다면 프로메테우스 서버가 정상적으로 구동된 것이다.

3. Metric 이름으로 검색해보기

http://{프로메테우스 올라간 서버 IP 또는 DNS 호스트네임}:9090/metrics 로 접속하면 프로메테우스 서버가 수집한 metric 들을 확인할 수 있다. 이러한 metric 들은 프로메테우스의 GUI 콘솔 상에서도 다음과 같이 검색이 가능하다.

/metrics 에서 확인해본 'go_memstats_alloc_bytes' 메트릭

프로메테우스 콘솔 페이지에서 metric 이름으로 검색한 화면

4. prometheus.yml (프로메테우스 configuration 파일) 의 Default 설정 살펴보기

# prometheus.yml 파일

# my global config
global:
  scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).
 
# Alertmanager configuration
alerting:
  alertmanagers:
    - static_configs:
        - targets:
          # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

 # A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
    - job_name: "prometheus"
    
      # metrics_paht defaults to '/metrics'
      # scheme defaults to 'http'.
      
        static_configs:
          - targets: ["localhost:9090"]

5. systemctl에 service 등록하기

- service 파일 생성

# vi /usr/lib/systemd/system/prometheus.service

# /usr/lib/systemd/system/prometheus.service 파일

[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
Wants=network-online.target
After=network-online.target

[Service]
EnvironmentFile=/etc/sysconfig/prometheus
PIDFile=/var/run/prometheus.pid

User=prometheus
Group=prometheus
Restart=on-failure

WorkingDirectory=/opt/prometheus
RuntimeDirectory=prometheus
RuntimeDirectoryMode=0750

ExecStart=/opt/prometheus/bin/prometheus                                \
  --config.file=${CONF_FILE}                                            \
  --storage.tsdb.path=${DATA_DIR}										\
  --web.console.templates=${PROMETHEUS_HOME}/consoles                   \
  --web.console.libraries=${PROMETHEUS_HOME}/cconsole_libraries         \
  --web.enable-admin-api
  --storage.tsdb.retention.time=30d    # prometheus에서 수집한 데이터 보관 주기를 30일로 지정

[Install]
WantedBy=multi-user.target

- service 파일 작성시 깔끔하게 작성하기 위한, /etc/sysconfig/prometheus 작성

# vi /etc/sysconfig/prometheus 로 파일 생성

# /etc/sysconfig/prometheus 파일

PROMETHEUS_USER=prometheus

PROMETHEUS_GROUP=prometheus

PROMETHEUS_HOME=/opt/prometheus

LOG_DIR=/opt/prometheus/logs

DATA_DIR=/opt/prometheus/data

CONF_DIR=/opt/prometheus/conf

CONF_FILE=/opt/prometheus/conf/prometheus.yml

# Only used on systemd systems
PID_FILE_DIR=/var/run/prometheus

- 새로 작성한 .service 파일을 systemctl 에 인식시키기

# systemctl daemon-reload

- 프로메테우스를 systemctl 로 구동하기

# systemctl start prometheus

- 부팅시 자동으로 서비스 시작하도록 하기

# systemctl enable prometheus.service

참고

https://sanggi-jayg.tistory.com/91

[CentOS 7] Prometheus + Grafana 설치

CentOS 7 에 Prometheus + Grafana 설치 메뉴얼 프로메테우스 설치 https://prometheus.io/ # 유저 추가 useradd -m -s /bin/bash prometheus su - prometheus # 다운로드 cd /home/prometheus wget https://github.com/prometheus/prometheus/releases

sanggi-jayg.tistory.com

패스트캠퍼스 - '한 번에 끝내는 데이터 엔지니어링 초격차 패키지 Online' 중 Part.5 Observability - Ch 02_02.

[Linux][CentOS 7] vi, vim 테마(colorscheme) 설정 - onehalf

코_노 — Wed, 8 Mar 2023 11:47:33 +0900

0. vi -> vim 으로 설정하기

* vim : vi 에디터보다 쉬운 텍스트 에디터이며, vi에서 확장된 기능들을 가지고 있다.

vim 설치 - yum 으로 진행

# yum -y install vim

alias 설정

- 전역으로 설정하기 (모든 user들에 적용됨)

# vi /etc/bashrc

- 해당 계정에만 설정하기

$ cd ~
$ vi .bashrc	('.bashrc' 라는 파일을 User의 홈 디렉토리에 생성하여 내용 설정)

- alias 구문 추가

아래 구문을 /etc/bashrc 파일 또는 ~/.bashrc 파일 가장 아래에 추가한다.

alias vi='/usr/bin/vim'

/etc/bashrc 파일의 예시

- 변경된 설정 내용 적용

# source /etc/bashrc

또는

$ source ~/.bashrc

위 과정을 모두 진행하면, vi 명령어가 vim 으로 자동 적용되는 것을 확인할 수 있다.

1. onehalf 테마 다운로드 하기

https://github.com/sonph/onehalf/tree/master/vim/colors

GitHub - sonph/onehalf: Clean, vibrant and pleasing color schemes for Vim, Sublime Text, iTerm, gnome-terminal and more.

Clean, vibrant and pleasing color schemes for Vim, Sublime Text, iTerm, gnome-terminal and more. - GitHub - sonph/onehalf: Clean, vibrant and pleasing color schemes for Vim, Sublime Text, iTerm, gn...

github.com

위 링크로 들어가면, vim에 대한 onehalf 컬러 스키마를 다운 받을 수 있다!

참고로 나는 어두운 게 좋아서 'onehalfdark.vim' 으로 설치했다.

2. onehalf 테마 파일 위치해놓기

- 전역으로 설정

# cp ${테마 설치한 경로}/onehalfdark.vim /usr/share/vim/vimfiles/colors/	# /usr/share/vim/vimfiles/colors 에 컬러스키마 파일들이 모여 있음.

- 해당 유저만 설정

$ mkdir -p ~/.vim/colors/		# 홈 디렉토리에 .vim 와 colors 디렉토리 만들기

$ cp ${테마 설치한 경로}/onehalfdark.vim ~/.vim/colors/	# 홈 디렉토리의 .vim/colors 하위에 테마 파일 복사하기

3. vimrc 파일에 'colorscheme' 구문 추가하여 테마(vim 파일) 지정해주기

- 전역으로 설정

# vi /etc/vimrc		# /etc/vimrc 파일 열어서 수정하기

/etc/vimrc 파일 가장 하단에 아래 구문 추가

colorscheme onehalfdark

- 해당 유저만 설정

$ vi ~/.vimrc	# 홈 디렉토리의 .vimrc 파일 열어서 수정하기

.vimrc 파일 가장 하단에 아래 구문 추가

colorscheme onehalfdark

~/.vimrc 파일 예시

위 과정까지 완료하면, 이제 vi 에디터를 열 때, 예쁘게 테마가 설정된 걸 확인할 수 있다!

혹시나 적용이 되지 않는 경우에는, 테마 파일의 파일 권한이 644(rw-r--r--) 인지 확인해보자!

참고

https://shary1012.tistory.com/231

[linux] vimrc 설정 (vim install 부터 colorscheme 다운로드 받아서 적용하기)

1. 설치 및 기본 적용 vimrc를 적용하기 위해서는 'xxx.vim' 파일을 특정 폴더(/usr/share/vim/vim00)에 넣고 colorscheme를 적용하면 되는데, 리눅스를 처음 설치했을 때에는 '/usr/share/vim' 디렉토리가 생성되어

shary1012.tistory.com

[Linux] CentOS 7 에서 User 생성(useradd)과 User 홈 디렉토리 설정

코_노 — Tue, 28 Feb 2023 14:46:38 +0900

우선 아래 command 들은 모두 root 권한과 동일한 유저로 진행했음을 먼저 일러둔다.

User 생성 명령어

$ useradd [OPTIONS] USERNAME

주요 옵션)

-p : 사용자의 암호(Password) 추가
-d : 홈 디렉토리 지정
* 최종 디렉토리만 생성하므로, 중간 경로가 존재하지 않는 경우 미리 생성해두어야 한다.
-g : 기본그룹을 지정할 때 사용
* 지정할 그룹이 미리 생성되어 있어야 함.
* 이 옵션을 넣지 않을 경우, default로 USERNAME 과 동일한 그룹에 포함됨. (Redhat 계열)
-G : 기본 그룹 외의 추가로 그룹에 속하게 할 경우 (--groups)
-c : 사용자에 대한 설명(Caption)을 설정
-s : 사용자가 사용할 쉘(Shell)을 지정할 때 사용
-D : /etc/default/useradd 에 설정된 유저 추가와 관련된 기본 사항들을 보여줌
-m : 사용자를 생성할 때, 홈 디렉토리를 생성해주는 옵션
* Redhat 계열에서는 이 옵션을 사용하지 않아도 홈 디렉토리가 USERNAME에 맞춰 알아서 생성됨
* 보통 -k 옵션과 함께 사용하여 사용자 생성시 기본적으로 부여되는 목록이 들어있는 skeldir 을 지정할 때 사용
-k : 사용자 생성 시 제공되는 환경 파일들은 기본적으로 /etc/skel 로 지정되는데, 이외의 디렉토리를 지정할 때 사용
-f : 사용자의 패스워드 만기일을 날짜수로 지정할 때 사용
-e : 계정의 만기일(Expiration)을 YYYY-MM-DD 형식으로 지정하여 사용
-u : 사용자 추가 시, UID 값 지정
-r : 시스템 계정 추가 시 사용. /etc/login.defs 파일에서 정의된 UID_MIN 값보다 작은 UID 값을, GID_MIN 값보다 작은 GID를 자동으로 선택하여 추가하게 됨. '-u UID' 및 '-g GID' 와 같이 직접 UID나 GID를 추가옵션을 사용한다면 -r 옵션은 사용되지 않음.
-h : --help

User 암호(Password) 설정

$ passwd USERNAME

User 생성 예시

1. 'testuser1' 라는 사용자를 생성하면서 홈 디렉토리의 경로 및 그룹을 지정하는 명령어

* 홈 디렉토리 : /home/tester/testuser1 / 그룹 : tester

* 위 디렉토리와 그룹은 모두 미리 생성되어 있는 걸로 가정

$ useradd testuser1 -d /home/tester/testuser1 -g tester

2. 'testuser2' 라는 사용자를 생성하면서 여러 그룹으로 할당시키는 명령어

* 기본 그룹 : 'tester' / 보조 그룹 : 'wheel', 'developers'

* 위 그룹들은 모두 미리 생성되어 있는 걸로 가정

$ useradd -g tester -G wheel,developers testuser2

현재 사용자 추가시, default로 지정되는 옵션 확인하기

$ useradd -D

# 내 로컬 환경에서 useradd -D 결과
# 이 설정들은 /etc/default/useradd 에서 확인 및 변경 가능
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes

참고

https://jjeongil.tistory.com/1449

Linux : User 생성 방법, 예제, 명령어(useradd Command)

리눅스는 다중 사용자 시스템으로, 둘 이상의 사용자가 동시에 동일한 시스템과 상호 작용할 수 있습니다. 시스템 관리자는 사용자를 생성 및 제거하고 다른 그룹에 할당하여 시스템의 사용자

jjeongil.tistory.com

https://starrykss.tistory.com/1631

[리눅스 명령어] useradd / useradd -D

useradd / useradd -D useradd 사용자의 ID를 생성하는 명령 사용법 useradd [option] [사용자 계정 이름] 주요 옵션 옵션 설명 -p 사용자의 암호(Password)를 추가할 때 사용 -d - 홈 디렉터리(Directory)를 지정할 때

starrykss.tistory.com

[MongoDB] CentOS 7 에 MongoDB 설치 및 샤드 클러스터 구성하기

코_노 — Mon, 27 Feb 2023 11:58:21 +0900

0. 서버 구성

이 포스팅에서의 MongoDB 구조

보다시피, Config 서버, Router 서버, 샤딩 서버가 모두 한 물리적 서버(VM Machine)에 존재하기 때문에, 사실상 HA(High Availability) 기능은 없다고 봐야 한다. J_Mongo 1번서버가 Down되면 MongoDB 시스템 전체가 Down 되기 때문이다.

정석적으로 하려면 최소 Config 서버 3대(Primary-Secondary-Secondary 또는 Arbiter) / Router 서버 2대(1대는 스페어이자, request 자체의 분산 목적) / Sharding 서버 2대(데이터 분산 목적)*3 (Priamry-Secondary-Secondary 또는 Arbiter 구성의 Replica Set) 으로 총 11대가 필요하다.

여기서 데이터의 변경이 잦아 샤드 클러스터를 추가한다고 하면, 필요한 서버의 대수가 기하급수적으로 증가하게 된다.

이 포스팅에서는 샤딩이 어떻게 되는지, 레플리카셋에서 쿼리 분산이나 Fail-Over가 어떻게 진행되는지 '살펴보기' 위한 목적이므로, 3대의 서버(VM Machine)으로만 진행하기로 하자...!

1. MongoDB 설치

여기서는 MongoDB 5.0 버전을 기준으로 한다.

우선 아래와 같이 /etc/yum.repos.d/ 아래에 'mongodb-org-5.0.repo' 라고 이름 지어(이름은 사실 자유) yum 레포를 설정해준다.

[mongodb-org-5.0]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/5.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-5.0.asc

그리고 다음 명령어로 mongodb 를 설치한다.

# yum install -y mongodb-org

2. MongoDB의 DATA, config, log 디렉토리 생성

디렉토리 역시 관리하기 편한대로 구성하면 되나, 기본적으로 data가 들어가는 디렉토리, mongodb 를 실행할 때 불러올 conf 파일이 있는 디렉토리, 로그가 쌓이는 디렉토리는 따로 분리하는 것이 관리하기에 편할 것이다.

내 디렉토리 구조는 아래와 같다.

내가 설치한 mongodb 디렉토리 구조

# 1번 서버 - Config 서버, Router 서버, 샤드 서버(Primary) 3개로 구성 예정
mkdir /home/mongodb/config
mkdir /home/mongodb/DATA
mkdir /home/mongodb/DATA/conf
mkdir /home/mongodb/DATA/rs1
mkdir /home/mongodb/DATA/rs2
mkdir /home/mongodb/DATA/rs3
mkdir /home/mongodb/log


# 2번 서버 - 샤드 서버(Secondary) 3개로 구성 예정
mkdir /home/mongodb/config
mkdir /home/mongodb/DATA
mkdir /home/mongodb/DATA/rs1
mkdir /home/mongodb/DATA/rs2
mkdir /home/mongodb/DATA/rs3
mkdir /home/mongodb/log


# 3번 서버 - 샤드 서버(Secondary) 3개로 구성 예정
mkdir /home/mongodb/config
mkdir /home/mongodb/DATA
mkdir /home/mongodb/DATA/rs1
mkdir /home/mongodb/DATA/rs2
mkdir /home/mongodb/DATA/rs3
mkdir /home/mongodb/log

3. Authorization 을 위한 Key 파일 생성

# 1번 서버에서 openssl로 생성하여 scp로 2번서버, 3번서버로 복사하기.
openssl rand -base64 755 > /home/mongodb/config/mongodb-keyfile

# 파일 권한 변경
chmod 600 /home/mongodb/config/mongodb-keyfile

# 2번, 3번 서버로 복사
scp /home/mongodb/config/mongodb-keyfile mongo@{2번서버 IP}:/home/mongodb/config/mongodb-keyfile
scp /home/mongodb/config/mongodb-keyfile mongo@{3번서버 IP}:/home/mongodb/config/mongodb-keyfile

4. Mongo 인스턴스를 실행할 때 불러올 conf 파일 생성

4-1. Config 서버

# vim /home/mongodb/config/mongod_config.conf

# mongod_config.conf

# for documentation of all options, see:
#    http://docs.mongodb.org/manual/reference/configuration-options/

# 로깅 데이터 설정
systemLog:
    destination: file
    logAppend: true
    path: /home/mongodb/log/mongod_config.log

# 데이터 저장 설정
storage:
    dbPath: /home/mongodb/DATA/conf
    journal:
        enabled: true
    engine: "wiredTiger"

# 몽고DB 인스턴스의 프로세스 설정
processManagement:
    fork: true	# fork and run in background
    pidFilePath: /home/mongodb/log/mongod_config.pid	# location of pidfile

# 네트워크 인터페이스 설정
net:
    port: 20000
    bindIp: 0.0.0.0 	 # MongoDB 인스턴스가 실행되는 서버에서 모든 IP 주소에서 들어오는 클라이언트 연결을 수신하도록 설정하는 것
    
# 레플리케이션 설정
# Config 서버는 Config 서버끼리 같은 Replica Set 이름으로 지정
replication:
    replSetName: "configRepl"

# 샤딩 설정
# 샤딩 클러스터에서 이 인스턴스가 어떠한 역할을 할지 알려주는 것
sharding:
    clusterRole: configsvr
    
# Security 설정
# 이 구문은 mongodb 셋업이 끝난 후, Primary 노드에서 유저 생성을 한 이후에 넣을 것.
security:
    keyFile: /home/mongodb/config/mongodb-keyfile
    authorization: "enabeld"

4-2. Shard 서버

# vim /home/mongodb/config/mongod_shard_rs1.conf

# vim /home/mongodb/config/mongod_shard_rs2.conf

# vim /home/mongodb/config/mongod_shard_rs3.conf

# mongod_shard_rs1.conf

# for documentation of all options, see:
#    http://docs.mongodb.org/manual/reference/configuration-options/

# 로깅 데이터 설정
systemLog:
    destination: file
    logAppend: true
    path: /home/mongodb/log/mongod_shard_rs1.log	# [rs1 | rs2 | rs3].log

# 데이터 저장 설정
storage:
    dbPath: /home/mongodb/DATA/rs1	# # [rs1 | rs2 | rs3]
    journal:
        enabled: true
    engine: "wiredTiger"

# 몽고DB 인스턴스의 프로세스 설정
processManagement:
    fork: true	# fork and run in background
    pidFilePath: /home/mongodb/log/mongod_shard_rs1.pid	# location of pidfile / [rs1 | rs2 | rs3].pid

# 네트워크 인터페이스 설정
net:
    port: 30001	# 동일한 레플리카셋으로 넣는다면 포트도 동일하게 설정 [30001 | 30002 | 30003]
    bindIp: 0.0.0.0 	 # MongoDB 인스턴스가 실행되는 서버에서 모든 IP 주소에서 들어오는 클라이언트 연결을 수신하도록 설정하는 것
    
# 레플리케이션 설정
# Sharding 서버는 Port 넘버 기준으로 같은 노드끼리 같은 Replica Set 이름으로 지정
# Secondary 노드에서도 동일하게 설정한 후, Primary 노드에서 rs.initiate()로 Secondary 노드를 추가하면 자동으로 Secondary 노드에 데이터 동기화 됨.
replication:
    replSetName: "rs1"	# [rs1 | rs2 | rs3]

# 샤딩 설정
# 샤딩 클러스터에서 이 인스턴스가 어떠한 역할을 할지 알려주는 것
sharding:
    clusterRole: shardsvr
    
# Security 설정
# 이 구문은 mongodb 셋업이 끝난 후, Primary 노드에서 유저 생성을 한 이후에 넣을 것.
security:
    keyFile: /home/mongodb/config/mongodb-keyfile
    authorization: "enabeld"

4-3. Router 서버

# vim /home/mongodb/config/mongos_config.conf

# mongos_config.conf

# for documentation of all options, see:
#    http://docs.mongodb.org/manual/reference/configuration-options/

# 로깅 데이터 설정
systemLog:
    destination: file
    logAppend: true
    path: /home/mongodb/log/mongos.log

# 몽고DB 인스턴스의 프로세스 설정
processManagement:
    fork: true	# fork and run in background
    pidFilePath: /home/mongodb/log/mongos.pid	# location of pidfile

# 네트워크 인터페이스 설정
net:
    port: 20001	
    bindIp: 0.0.0.0 	 # MongoDB 인스턴스가 실행되는 서버에서 모든 IP 주소에서 들어오는 클라이언트 연결을 수신하도록 설정하는 것
    
    
# 샤딩 설정
# Router 서버에서는 샤드 클러스터의 config 서버를 바라보도록 설정해야 한다.
sharding:
    configDB: configRepl/10.0.2.16:20000
    
    
# Security 설정
# 이 구문은 mongodb 셋업이 끝난 후, Primary 노드에서 유저 생성을 한 이후에 넣을 것.
security:
    keyFile: /home/mongodb/config/mongodb-keyfile

5. Mongo 인스턴스 실행 및 초기 설정

5-1. Config 서버

5-1-a. Config 서버 인스턴스 실행

$ mongod --config /home/mongodb/config/mongod_config.conf

5-1-b. Config 서버 Replica Set 설정

# config 서버 접속
$ mongo 10.0.2.16:20000

# config 서버 shell에서
> rs.initiate({
    _id: "configRepl",
    members: [
        { _id: 0, host: "10.0.2.16:20000" }
    ]
})

5-1-c. Config 서버 계정 생성

> use admin
> db.createUser({user: "root", pwd: "블라블라~", roles: ["root"]})
# 서버의 모든 administration 작업을 위한 root 권한의 계정 생성

> use testdb
> db.createUser({user: "testuser", pwd: "블라블라~", roles: [{role: "readWrite", db: "testdb"}]})
# 'testdb' 라는 데이터베이스만 사용할 수 있도록 하는 테스트 계정 생성

5-2. Shard 서버

5-2-a. Shard 서버 인스턴스 실행

$ mongod --config /home/mongodb/config/mongod_shard_rs1.conf
$ mongod --config /home/mongodb/config/mongod_shard_rs2.conf
$ mongod --config /home/mongodb/config/mongod_shard_rs3.conf

5-2-b. Shard 서버 Replica Set 설정

# shard 서버 접속
$ mongo 10.0.2.16:30001 ~ 30003

# shard 서버 shell에서
> rs.initiate({
    _id: "rs1",
    members: [
        { _id: 0, host: "10.0.2.16:30001" }
        { _id: 1, host: "10.0.2.17:30001" }
        { _id: 2, host: "10.0.2.18:30001" }
    ]
})
> rs.status()

5-2-c. Shard 서버 계정 생성

> use admin
> db.createUser({user: "root", pwd: "블라블라~", roles: ["root"]})
# 서버의 모든 administration 작업을 위한 root 권한의 계정 생성

> use testdb
> db.createUser({user: "testuser", pwd: "블라블라~", roles: [{role: "readWrite", db: "testdb"}]})
# 'testdb' 라는 데이터베이스만 사용할 수 있도록 하는 테스트 계정 생성

5-3. Router 서버

5-3-a. Router 서버 인스턴스 실행

$ mongos --config /home/mongodb/config/mongos_config.conf

5-3-b. Router 서버 Shard Set 설정

# mongos 서버 접속
$ mongo 10.0.2.16:20001

# Router 서버 shell에서
> sh.addShard("rs1/10.0.2.16:30001")
> sh.addShard("rs2/10.0.2.16:30002")
> sh.addShard("rs3/10.0.2.16:30003")
> sh.status()

5-3-c. Router 서버 계정 생성

> use admin
> db.createUser({user: "root", pwd: "블라블라~", roles: ["root"]})
# 서버의 모든 administration 작업을 위한 root 권한의 계정 생성

> use testdb
> db.createUser({user: "testuser", pwd: "블라블라~", roles: [{role: "readWrite", db: "testdb"}]})
# 'testdb' 라는 데이터베이스만 사용할 수 있도록 하는 테스트 계정 생성

6. 샤딩 테스트

데이터가 분산되어 잘 저장되는지 확인해보자!

6.1. 테스트 DB 생성 및 샤딩 선언, 데이터 생성

# Router 서버 접속
$ mongo 10.0.2.16:20001

# 데이터베이스 생성 및 collection 인덱스 생성
> use testdb
> db.test.createIndex({"index": 1})

# shard를 할 것이라고 배포
> sh.enableSharding("testdb")
> sh.shardCollection("testdb.test", {index: "hashed"})

# 테스트용 데이터 1000개 document 생성
> for (var n=1; n<=1000; n++) {
    db.test.insert({index: n, value: "test"})
}

# 'test' 컬렉션의 document 수 확인
> db.test.count()

Router 서버에서의 db.test.count() 결과 화면

6.2. 각 샤드 서버(rs1, rs2, rs3) 에 데이터가 골고루 분산되어 저장되었는지 확인

# 샤드 노드 1번 접속 및 document 개수 확인
$ mongod 10.0.2.16:30001

> use testdb
> db.getCollecion("test").find({}).count()

샤드 1번 노드에서의 db.getCollection("test").find({}).count() 결과

# 샤드 노드 2번 접속 및 document 개수 확인
$ mongod 10.0.2.16:30002

> use testdb
> db.getCollecion("test").find({}).count()

샤드 2번 노드에서의 db.getCollection("test").find({}).count() 결과

# 샤드 노드 3번 접속 및 document 개수 확인
$ mongod 10.0.2.16:30003

> use testdb
> db.getCollecion("test").find({}).count()

샤드 3번 노드에서의 db.getCollection("test").find({}).count() 결과

310 + 346 + 344 = 1000 으로, 정상적으로 document 들이 분산되어 저장되 것을 확인할 수 있다!

참고로 이 포스트의 구성에서는, 샤딩할 경우 데이터가 어떻게 분산되는지만 확인할 것이었기에 한 개의 VM Machine 에 3개의 샤드 서버 인스턴스를 모두 몰아 넣었다.

실제 샤딩 환경에서는 각 샤드 서버가 서로 다른 각각의 물리적 서버에 있을 것이므로, 방화벽 등의 설정을 통하여 기본 통신이 원활하게 되는지 반드시 확인하는 작업이 필요하다!

참고

https://developer-ljo.tistory.com/36

centos mongodb 설치 및 샤딩

0. 서버 구성 - 서버2대 - 서버 1 : mongos,config,shard1~3 - 서버 2 : shard1~3 1. mongodb 설치 # mongodb repository 등록 vi /etc/yum.repos.d/mongodb-org-3.4.repo [mongodb-org-3.4] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/re

developer-ljo.tistory.com

https://urame.tistory.com/entry/%EB%AA%BD%EA%B3%A0%EB%94%94%EB%B9%84mongodb-%EC%83%A4%EB%93%9Cshard-%EC%84%A4%EC%A0%95

몽고디비(mongodb) 샤드(shard) 설정

금일은 몽고디비 샤드에 대해 알아보겠다. 금일 몽고디비 구성도는 아래와 같다. 2번정도 쭉 따라서 확인차 만들어 보았다. 큰 문제 없이 구성이 된다. 단, 위 그림에서 회색으로 표현된 부분은

urame.tistory.com

[네트워크] Linux 환경에서 네트워크 관련 트러블슈팅을 위한 기본 command 가이드

코_노 — Tue, 14 Feb 2023 10:47:56 +0900

1. ping

: 대상 호스트(hostname or IP주소)로 ICMP(Internet Control Message Protocol)을 보내는 명령어

- 서비스가 안된다는 말을 들었을 때, 가장 먼저 해봐야 하는 command

- 해당 소프트웨어가 문제인지, 소프트웨어가 올라가 있는 호스트(서버) 자체의 문제인지 판단하기 위함

- 대상 호스트 자체가 살아 있다면 ping은 나가므로, ping이 나간다고 해서 해당 소프트웨어가 정상이라고 판단하지 말 것

$ ping [hostname]
또는
$ ping [IP address]

ping 정상 결과 출력 화면

ping 비정상 결과 출력 화면

2. netstat

: Network Statistics로, TCP/IP Connection 네트워크의 통계 정보를 제공해주는 명령어

- 열려있는 포트 및 동작하고 있는 소프트웨어 정보를 함께 확인할 때 사용

옵션)

- a : 모든 네트워크 상태 출력 [-all]

- i : 인터페이스별 통계값 출력 [--interface]

- n : IP address 및 Port 표시 ( netstat는 역dns 질의를 통해 각 IP에 매칭되는 Hostname을 얻으려 하는데, 이때 출력에 지연이 생기게 된다. 굳이 Hostname이 필요 없다면 해당 옵션을 사용하길 권장한다.)

- p : PID(프로세스 ID)와 사용중인 프로그램명 출력 [--program]

- r : 라우팅 테이블 출력 [--route]

- t : TCP 프로토콜만 출력 [--tcp]

- u : UDP 프로토콜만 출력 [--udp]

- l(엘) : 대기중인 네트워크 [--listening]

$ netstat -tnlp
(-> TCP 프로토콜만 출력, IP주소 및 포트 형식으로 표시, LISTEN 중인 녀석들만 출력, PID까지 표시)

netstat -tnlp 결과 예시

결과 설명)

Proto : 프로토콜 종류. TCP, UDP RAW 등
Recv-Q : 해당 프로세스가 현재 받는 Byte 수 표기
Send-Q : 해당 프로세스가 현재 보내는 Byte 수 표기
Local Address : 출발지 주소 및 포트
Foreign Address : 목적지 주소 및 포트
State : 포트의 상태

3. traceroute

: 지정된 Host까지 패킷이 전달되는 경로를 표시. IP 패킷의 TTL(Time-To-Live) 필드를 활용하여 Destination 까지의 Traffic Path 를 알아내는데, 해당 방법을 정리하면 다음과 같다.

① TTL 1 부터 한 패킷씩 전송을 시작한다.

② 패킷이 전송 중에 만료될 것이므로, Upstream Router는 ICMP Time-To-Live Exceeded 패킷을 보내면서 hop 을 식별한다.

③ 위 과정을 반복하며, 다음 hop을 식별한다.

④ 위와 같이 패킷 전송을 반복하여, 최종 Destination 까지 도달하는 과정 중의 라우터 리스트를 알아낸다.

- 특정 호스트에 대한 ping이 날라가지 않는 경우, traceroute를 통해 해당 호스트 자체에 문제가 있는지, 호스트에 도달하기까지의 경로 상에 있는 네트워크 인터페이스에 문제가 있는지 알아보는 데에 사용

$ traceroute [Hostname]
or
$ traceroute [IP Address]

traceroute 출력 결과

4. route

: Host의 Routing Table을 확인 및 설정하는 유틸리티.

* Routing Table : Router 가 특정 서브넷에서 다른 서브넷으로 패킷을 보낼 때 네트워크 노선(?)을 변환시키는데, 이때 활용하는 정보를 말한다.

- 네트워크 단의 문제를 확인할 때에는 'route -n' 을 사용하여 IP별로 패킷이 어떤 라우터로 거쳐가는지 확인할 수 있다.

$ route -n

route -n 결과 화면

결과 설명)

아래와 같은 규칙을 따라 라우팅 테이블을 해석한다.

① 컴퓨터는 위의 첫번째 행부터 다음 행으로 차례대로 한 행씩 읽어가며 처리할 패킷을 보낼 수 있는지 확인하게 된다.

② default(0.0.0.0) 라는 것은 이 Host의 기본 게이트웨이 설정을 의미하며, 이 행의 Gateway 값이 기본 게이트웨이의 IP 주소를 나타낸다.

③ 보낼 데이터의 목적지 IP 주소와 Genmask 값과의 AND 연산을 하여 그 결과가 해당 행의 Destination 항목과 동일할 경우, 해당 행의 Iface에 있는 인터페이스로 해당 패킷을 전송한다. 해당 행의 Destination 항목과 다르다면 다음 행으로 이동한다.

④ Iface 의 값이 'lo'로 되어 있는 것은, 이 Host의 루프백 데이터를 처리하기 위한 설정이다. 즉, 자기 자신에게 데이터를 보낼 때 처리를 담당하는 인터페이스를 의미한다.

필드 설명)

Destination : 목적지 네트워크 주소
Gateway : 목적지로 가기 위한 게이트웨이 주소
Genmask : 목적지 네트워크의 넷마스크 주소 (패킷의 목적지 IP 주소와 Genmask 값을 'AND 연산'한 결과가 해당 패킷이 이동할 다음 목적지 IP 주소가 된다.)
Flags : 해당 경로에 대한 정보를 알려주는 기호
- U : 해당 경로 유효
- H : 해당 경로가 호스트를 향하고 있음. (Destination의 IP가 Host임을 나타냄.) 즉, 라우터를 거치지 않아도 됨.
- G : 해당 경로가 게이트웨이를 향하고 있음. 즉, 해당 Destination 으로 가려면, 라우터를 통과해야한다는 의미.
- I : 해당 경로 무효
Metric : 다음 라우터까지의 거리
Ref : 경로를 참조한 횟수
Use : 경로를 탐색한 횟수
Iface : 패킷이 오가는 데 사용하게 될 네트워크 인터페이스

5. ss (Socket Statistics)

: 리눅스 시스템의 소켓 상태를 조회할 수 있는 유틸리티. netstat와 비슷한 역할을 수행하나, 최근 리눅스 배포판에서는 netstat보다는 ss 사용을 권장하고 있음

옵션)

- a : 모든 소켓을 표시 [--all]

- l : 접속 대기 상태 소켓만 표시 [--listening]

- n : 호스트 DNS명이 아닌 IP Address 형태로 표시 [--numeric]

- t : TCP 소켓만 표시 [--tcp]

- u : UDP 소켓만 표시 [--udp]

- x : UNIX 도메인 소켓을 표시 [--unix]

- p : 포로세스명을 표시 [--process]

- s : 각 프로토콜의 통계 정보를 표시 [--summary]

$ ss

ss 결과 화면

결과 설명)

Netid : 프로토콜명.
State : 소켓 상태
Recv-Q : 수신 실패 데이터 바이트 수
Send-Q : 송신 실패 데이터 바이트 수
Local Address:Port : 소켓에 연결된 경로명 또는 로컬 호스트명(IP 주소)와 포트 번호
Peer Address:Port : 원격 호스트 호스트명(IP 주소)와 포트 번호

참고

https://jaemunbro.medium.com/linux-network-%EB%AC%B8%EC%A0%9C%ED%95%B4%EA%B2%B0-%EA%B0%80%EC%9D%B4%EB%93%9C-for-beginners-b167d5175ef8

[Linux] 네트워크 트러블슈팅 가이드

늘 네트워크를 활용하고 있기는 하지만 네트워크의 개념과 설비가 방대하기 때문에 전체적으로 이해하기는 쉽지 않은 분야이다. 네트워크 이슈가 생겼을때 대응할 수 있는 기본적인 원인 파

jaemunbro.medium.com

https://websecurity.tistory.com/103

리눅스(Linux) netstat 명령어 사용법, 네트워크 상태 확인하기

netstat네트워크 연결상태, 라우팅테이블, 인터페이스 상태등을 보여주는 명령어[사용법]#> netstat [옵션] [옵션]옵션 설명-a모든 네트워크 상태 출력 [-all]-c현재 실행 명령을 매 초마다 실행 [--continu

websecurity.tistory.com

https://deadheromaybewantsomething.tistory.com/30

라우팅 테이블에 대해서

라우팅 테이블 route 혹은 netstat라는 명령어를 사용해 라우팅 테이블을 확인할 수 있다. [root@was01 ~]# route Kerenl IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0

deadheromaybewantsomething.tistory.com

https://www.lesstif.com/lpt/linux-socket-ss-socket-statistics-91947283.html

linux socket 상태를 조회하는 ss(socket statistics) 명령어 사용법

www.lesstif.com

[MSSQL] Enable 계정 및 각 계정별 발급일, PW 변경일 확인

코_노 — Tue, 7 Feb 2023 10:50:16 +0900

DB admin으로서, 각 계정이 언제 생성되었는지, PW가 언제 변경되었는지 확인해야 되는 상황이 생길 수 있다.

그런 상황에서 유용한 sys.server_principals(T-SQL) 을 활용하여 원하는 정보를 쿼리로 획득해보자!

먼저 현재 SQL Server에서 활성화된 계정을 확인할 필요가 있다.

1. MSSQL 상에서 Enabled 되어 있는 계정 확인

SELECT *
FROM sys.server_principals
WHERE is_disabled = 0 AND type in ('S')

sys.server_principals SELECT 결과

name : 보안 주체의 이름. 서버 내에서 고유. (sysname 데이터타입)
principal_id : 보안 주체의 ID 번호. 서버 내에서 고유. (int 데이터 타입)
sid : 보안 주체의 SID(보안 ID). Windows 보안 주체의 경우 Windows SID와 일치. (varbinary(85) 데이터타입)
type : 보안 주체 유형. (char(1) 데이터타입)
- S : SQL 로그인
- U : Windows 로그인
- G : Windows 그룹
- R : 서버 역할(Role)
- C : 인증서에 매핑된 로그인
- E : Azure Active Directory 에서 외부 로그인
- X : Azure Active Directory 그룹 또는 애플리케이션의 외부 그룹
- K : 비대칭 키에 매핑된 로그인
type_desc : 보안 주체 유형에 대한 설명. 값은 아래 중에 하나.
SQL_LOGIN / WINDOWS_LOGIN / WINDOWS_GROUP / SERVER_ROLE / CERTIFICATE_MAPPED_LOGIN / EXTERNAL_LOGIN / EXTERNLA_GROUP / ASYMMETRIC_KEY_MAPPED_LOGIN
is_disabled : 1=로그인할 수 없는 상태 / 0=로그인 가능한 상태
credential_id : 이 보안 주체와 연결된 자격증명의 ID. 이 보안 주체와 연결된 자격 증명이 없는 경우 NULL 이 된다.

2. MSSQL Enable된 계정의
Default 데이터베이스, 최초 생성일, 계정 관련 변경일, PW 변경일, 해당 PW 사용일 수
확인 쿼리

SELECT NAME AS id
, default_database_name AS 기본_데이터베이스
, create_date AS 최초_생성일
, modify_date AS 계정설정_변경일
, LOGINPROPERTY(NAME, 'PasswordLastSetTime') AS 패스워드_변경일
, DATEDIFF(DD, CONVERT(SMALLDATETIME, LOGINPROPERTY(name, 'PasswordLastSetTime')), GETDATE()) AS 패스워드_사용일수
FROM sys.server_principals
WHERE is_disabled = 0 AND type in ('S')

sys.server_principals 를 통한 패스워드 변경일 조회 결과

위와 같이 각 계정별 최초 생성일 및 패스워드 변경일 등의 유용한 정보를 쿼리를 통해 확인할 수 있다!

참고

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

MSSQL 활성화 계정 및 비밀번호 변경 이력 확인

#mssql비밀번호변경이력 #MSSQL계정확인 #MSSQL보안확인 1. mssql 활성화 계정 확인 (is_disable...

blog.naver.com

https://learn.microsoft.com/ko-kr/sql/relational-databases/system-catalog-views/sys-server-principals-transact-sql?view=sql-server-ver16

sys.server_principals(Transact-SQL) - SQL Server

sys.server_principals(Transact-SQL)

learn.microsoft.com

[MSSQL] [트러블슈팅] \nError converting data type nvarchar to float. [8114]

코_노 — Fri, 3 Feb 2023 09:50:22 +0900

SQL Server 계정에 대한 권한 정리 및 패스워드 변경 작업을 하면서 겪은 상황이다.

신규 계정을 생성한 후, 사용하는 DB에 대한 권한만 넣었는데,

DB 접근도 잘 되고,

특정 프로시저에 대한 접근(SSMS 상에서 보임), 실행("1개 행 적용됨" 메시지 출력 및 "프로시져 실행 시작.." 메시지 출력) 은 되는데,

"\nError converting data type nvarchar to float. [8114]" 라는 메시지가 나타났다.

처음에는 원래 접속하던 계정이 가지고 있던 권한(SA 권한이었다...) 에서 빠진 게 있나 하고, 시스템 DB에 대한 db_owner 권한도 넣어보고 했지만, 여전히 위의 에러코드가 출력되었다.

그러던 중, SA의 로그인 속성은 기본 언어가 한국어인 반면, 내가 새로 만든 계정은 English 인 것을 발견했다!

해당 SQL Server 계정에 대한 '기본 언어' 속성을 한국어로 바꾸고 나니, 프로시저 실행이 잘 되었다.

아무래도 한글로 되어 있는 어떤 데이터를 인식을 못하여 float 데이터로 바꾸지 못하던 현상인 듯 하다.

"\nError converting data type nvarchar to float. [8114]"

위의 에러 메시지로 잘 되던 프로시저가 갑자기 잘 안된다면,

해당 계정의 [로그인 속성] - [기본 언어] 가 NVARCHAR 타입으로 되어 있는 데이터의 언어와 맞게끔 변경해보도록 하자!

MSSQL 계정에 대한 기본 언어 설정 화면

[Java] JVM 실행 옵션 (3) - Advanced Runtime Options

코_노 — Mon, 28 Nov 2022 14:23:04 +0900

본 포스팅은 java 8 버전 (openjdk 1.8)을 기준으로 작성한다.

이전 포스팅에 이어, 이번 포스팅에서는 Java HotSpot Virtual Machine 의 런타임 동작을 컨트롤 하는 옵션인

Advanced Runtime Options에 대해 알아보도록 하자!

들어가기에 앞서, JVM 실행 옵션 중 Advanced 옵션들은 모두 'XX'가 붙는다는 것을 알아두자!

-XX:+CheckEndorsedAndExtDirs

: Java 애플리케이션이 *Endorsed-Standards Override Mechanism 또는 **Extension Mechanism을 사용하는 경우, java 커맨드가 실행되지 않도록 예방할 수 있는 옵션. 이 옵션은 아래와 같은 확인 과정을 거쳐 java 애플리케이션이 위와 같은 메커니즘을 사용하는지 판단한다.

java.ext.dirs 또는 java.endorsed.dirs 시스템 속성의 설정 여부
lib/endorsed 디렉토리 존재 여부
lib/ext 디렉토리에 JDK 이외의 다른 JAR 파일 존재 여부
system-wide platform-specific extension 디렉토리에 JAR 파일 존재 여부

*Endorsed-Standards Override Mechanism : JDK는 CORBA, DOM, SAX와 같은 패키지를 Java Endorsed Standards 로 분류하고 런타임에 포함시켜 놓았는데, 이러한 Endorsed-Standards 라이브러리들을 지정된 버전 또는 다른 구현체(implementation)로 바꾸고 싶을때 override 하는 것을 의미한다.

**Extension Mechanism : Java 플랫폼에서 실행되는 모든 어플리케이션 상에서 cumstom API를 사용할 수 있도록 하는 표준적, 확장 가능한 방법을 제공하는 메커니즘을 의미한다.

-XX:+DisableAttachMechanism

: jcmd, jstack, jmpa jinfo와 같은 Tool들을 JVM에 연결하는 것을 disable 하는 옵션. Default는 해당 옵션이 꺼져 있어(-XX:-DisableAttachMechanism), 이와 같은 Tool들을 모두 JVM에 연결시킬 수 있다.

-XX:ErrorFile=filename

: 복구할 수 없는 Error 가 발생했을 때, 해당 에러 데이터를 어떤 위치의 어떤 파일로 쓸지 정하는 옵션. 디폴트로는, 현재 작업 디렉토리(JVM이 실행되는 현재 디렉토리)에 hs_err_pid%p.log 라는 파일명으로 생성된다.

/var/log/java/java_error.log 라는 디렉토리로 해당 에러 파일을 생성하고자 한다면 아래와 같이 설정하면 된다.

+XX:ErrorFile=/var/log/java/java_error.log

-XX:+FailOverToOldVerifier

: 새로운 type checker가 fail 났을 때, 이전 verifier로 자동으로 Fail Over 할 수 있도록 하는 옵션. 디폴트로는, disable 되어 있다.

-XX:+FlightRecorder

: 애플리케이션 런타임 동안 JFR(Java Flight Recorder) 를 사용할 수 있도록 하는 옵션. 이 옵션은 commercial 기능이므로, 아래와 같이 '-XX:+UnlockCommercialFeatures' 옵션과 함께 사용해야 한다.

java -XX:+UnlockCommercialFeatures -XX:+FlightRecorder

-XX:FlightRecorderOptions=parameter=value

: JFR의 동작을 제어하도록 하는 파라미터를 넣어 사용하는 옵션.

이 옵션은 아래처럼 사용하면 된다.

-XX:FlightRecorderOptions=defaultrecording=true,disk=true,maxchunksize=10M

아래는 사용 'parameter'의 값으로 사용 가능한 것들이다.

defaultrecording={true|false}
: Java 애플리케이션에 작동하자마자 자동으로 레코딩을 시작할지 지정하는 파라미터. 디폴트로는 false이다.
disk={true|false}
: 디스크에 임시 데이터를 저장할 것인지 정하는 파라미터. 디폴트로는 false이다.
dumponexit={true|false}
: JVM에 정상적으로 종료됐을 시, 덤프 파일 또는 JFR 데이터를 생성할 것인지 지정하는 파라미터. 디폴트로는 false이다. 이 파라미터를 사용하려면, defaultrecording 파라미터도 true로 설정하여야 한다. 또한 덤프 파일이 저장되는 경로는 아래에서 설명할 파라미터인 'dumponexitpath=path' 를 통해 지정한다.
dumponexitpath=path
: path로 지정한 곳에 JFR에 대한 덤프파일이 저장되는 파라미터. 만약 해당 경로에 이미 덤프파일이 존재한다면, 파일명 뒤에 날짜와 타임스탬프를 추가하여 새 덤프파일을 생성하게 된다.
globalbuffersize=size
: data retention 에 사용될 primary memory의 총 공간을 지정하는 파라미터. 단위는 바이트이며, 디폴트로는 462848 바이트로 지정되어 있다.
loglevel={quiet|error|warning|info|debug|trace}
: JFR에 의해 쓰여질 로그파일에 대한 로그레벨을 지정하는 파라미터. 디폴트로는 info 이다.
maxage=time
: 디폴트 레코딩으로 보존될 데이터의 최대 시간을 지정하는 파라미터. 디폴트로는 15m(minutes) 이다. 이는 'disk=true' 파라미터가 지정되어 있어야 설정 가능하다.
maxchunksize=size
: 레코딩 할 때의 최대 데이터 청크 사이즈를 지정하는 파라미터. 디폴트로는 12MB 로 되어 있다. 이 파라미터 역시, 'disk=true' 파라미터가 지정되어 있어야 설정 가능한 파라미터이다.
maxsize=size
: 레코딩 할 때의 최대 데이터 사이즈를 지정하는 파라미터. 디폴트로는 최대 사이즈가 지정 되어 있지 않는데, 이 때 값이 0이다. 이 파라미터 역시, 'disk=true' 파라미터가 지정되어 있어야 설정 가능한 파라미터이다.
repository=path
: 임시 디스크 스토리지를 지정하는 파라미터. 디폴트로는 시스템 임시 디렉토리가 지정되어 있다.
samplethreads={true|false}
: 스레드 샘플링을 사용할 지 정하는 파라미터. 디폴트로는 true로 되어 있다.
settings=path
: 이벤트 설정 파일(JFC 타입)의 경로 및 이름을 지정하는 파라미터. 디폴트로는 'default.jfs' 로 되어 있는데, 이는 $JAVA_HOME/jre/lib/jfr 을 의미한다.
stackdepth=depth
: JFR에 의해 추적할 스택 깊이를 지정하는 파라미터. 디폴트로는 64이며, 지정할 수 있는 최댓값은 2048, 최솟값은 1이다.
threadbuffersize=size
: 스레드당 로컬 버퍼 사이즈를 지정하는 파라미터. 높은 값을 가질 수록, global 스토리지로 플러쉬없이 데이터를 버퍼에 갖고 있을 수 있다. 디폴트로는 5 KB 로 되어 있다.

-XX:LargePageSizeInBytes=size

: Solaris 환경에서 Java 힙에 사용될 페이지의 최대 사이즈를 지정하는 옵션. 이때 size 값은 2의 배수가 되어야 하며, 아래와 같이 사용한다.

-XX:LargePageSizeInBytes=4m

-XX:MaxDirectMemorySize=size

: New I/O(java.nio 패키지에 해당하는 부분)에 대한 direct-buffer 할당 최대 사이즈를 지정하는 옵션.

-XX:NativeMemoryTracking=mode

: JVM의 네이티브 메모리 사용에 대한 추적을 지정하는 옵션. 'mode' 에 들어갈 argument는 아래와 같다.

off : JVM 네이티브 메모리 사용에 대한 추적을 하지 않는 argument
summary : Java 힙, 클래스, 코드, 스레드와 같은 JVM 서브시스템의 메모리 사용량만 추적하는 argument
detail : summary에 더해, 각각의 CallSite, 가상 메모리 영역, commited 영역의 메모리 사용량까지 추적하는 argument

-XX:ObjectAlignmentInBytes=alignment

: 자바 객체에 대한 메모리 배정을 지정하는 옵션. 디폴트로는 8바이트로 지정되어 있다. 'alignment' 에 바이트 단위의 값이 들어가며, 이 값은 8 ~ 256 범위의 2의 배수여야 한다.

-XX:OnError=string

: 복구할 수 없는 에러가 나왔을 때, 큰 따옴표 안에 ';'(세미 콜론)을 구분자로 지정한 명령어를 수행하도록 하는 옵션.

아래와 같이 사용한다.

-XX:OnError="gcore %p;dbx - %p"

-XX:OnOutOfMemoryError=string

: Out Of MemoryError Exception이 처음 발생할 때 실행할, 사용자 지정 명령 또는 일련의 ';'(세미콜론)으로 구분된 명령을 설정하는 옵션. string에 들어갈 문자열 형식은 -XX:OnError의 string 형식과 동일하다.

-XX:+PerfDataSaveToFile

: Java 애플리케이션이 종료될 때, jstat(1) 바이너리 데이터를 저장하는 옵션. 이 바이너리 데이터는 hsperfdata_<pid> 라는 파일에 저장되며,다음과 같이 jstat 명령어를 사용함으로써 해당 파일에 있는 performance 데이터를 표시할 수 있다.

jstat -class file:///<path>/hsperfdata_<pid>
jstat -gc file:///<path>/hsperfdata_<pid>

-XX:-PreferContainerQuotaForCPUCount

: 이 옵션이 enable 되어 있을 경우, CPU CFS(Completely Fair Scheduler) 할당량 값을 기준으로 컨테이너 CPU 가용성을 계산한다. 만일 -XX:ActiveProcessorCount 옵션을 이 옵션 사용할 때에 명시하지 않았다면, JVM은 사용가능한 프로세서 수 계산을 위해 컨테이너 CPU 가용성을 사용한다.

-XX:+PrintCommandLineFlags

: 명령줄에 나타난 인체공학적(?)으로 선택된 JVM 플래그들을 출력할 수 있게 해주는 옵션.

힙 공간 사이즈와 선택된 garbage collector 와 같은, JVM에 의해 인체공학적(?)으로 선택된 이 값들을 아는 것이 유용할 수 있다. 디폴트로 이 옵션은 Disable 되어 있다.

-XX:+PrintContainerInfo

: 다음 항목들과 같은 컨테이너에 대한 정보를 출력하는 옵션.

cpuset.cpus : 둘 이상의 CPU 또는 코어가 있는 경우, 컨테이너에서 사용할 수 있는 CPU 또는 코어의 범위. ','(쉼표) 또는 '-'(하이픈)으로 구분되어 있음. 예를 들어, 값 '0-3' 이 의미하는 바는, 컨테이너가 첫번째, 두번째, 세번째, 네번째 CPU를 사용할 수 있음을 의미함.
cpuset.mems : NUMA(Non-Uniform Memory Access) 시스템 상에서만 효과적으로 애플리케이션을 실행하도록 허용하는 메모리 노드의 범위. ','(쉼표) 또는 '-'(하이픈)으로 구분되어 있음.
CPU Shares : 프로세스에 사용할 수 있는 CPU 공유량.
CPU Quota : 프로세스가 실행되는 것이 보장되는 기간 대비 밀리세컨드(milliseconds).
CPU Period : CFS 주기. ms 단위.
OSContainer::active_processor_count : JVM에 사용할 액티브 프로세서 수
Memoery Limit : 컨테이너가 사용할 수 있는 메모리 최대 사이즈. 바이트 단위.
Memory Soft Limit : Memory Limit 보다 작은 값으로, 컨테이너가 초과할 수도 있는 메모리 최대 사이즈. 바이트 단위.
Memory Usage : 이 프로세스에서 사용되고 있는 메모리 량. 바이트 단위.
Maximum Memory Usage : 이 프로세스에서 사용할 수 있는 메모리 최대 사이즈. 바이트 단위.

-XX:+PrintNMTStatistics

: Native Memory Tracking 이 가능하다면, JVM 종료시, 해당 데이터를 출력하는 옵션. 디폴트로 이 옵션은 Disable 되어 있다.

-XX:+RelaxAccessControlCheck

: 검증자(Verifier)의 Access Control 체크량을 줄이는 옵션. 디폴트로 이 옵션은 Disable 되어 있으며, 최신 바이트코드 버전이라면 무시될 수 있는 옵션이다.

-XX:+ResourceManagement

: 애플리케이션의 런타임동안 Resource Management를 사용할 수 있도록 하는 옵션. 이 옵션은 아래와 같이
'-XX:+UnlockCommercialFeatures' 옵션과 함께 사용해야 하는 상용 옵션이다.

java -XX:+UnlockCommercialFeatrures -XX:+ResourceManagement

**-XX:ResourceManagementSampleInterval=value (milliseconds)**

: Resource Management 측정에 대한 샘플링 간격 값을 지정하는 옵션. ms 단위이다.
이 옵션은 '-XX:+ResourceManagement' 옵션이 활성화 되어 있는 경우에만 사용 가능하다.

-XX:SharedArchiveFile=path

: path에 CDS(Class Data Sharing) 아카이브 파일의 디렉토리를 명시한다.

-XX:SharedClassListFile=file_name

: CDS(Class Data Sharing) 아카이브에 저장할 클래스 파일의 이름이 들어 있는 텍스트 파일을 지정한다. 이 파일에는 '/'(슬래시), '.'(마침표)를 제외한, 한 줄당 하나의 클래스 파일의 full-name이 포함된다. 예를 들어, java.lang.Object 와 hello.Main 두 클래스들을 지정한다고 하면, 다음과 같이 텍스트 파일을 작성한다.

java/lang/Object
hello/Main

이 텍스트 파일에서 지정하는 클래스 파일들은 애플리케이션에서 일반적으로 사용하는 클래스 파일들이 포함되어야 하며, 여기에는 애플리케이션, extension 또는 부트스트랩 클래스 경로가 포함될 수 있다.

-XX:+ShowMessageBoxOnError

: JVM에서 복구할 수 없는 에러가 발생할 경우, 다이얼로그 상자를 표시하도록 하는 옵션.

이 옵션을 Enable 하면, JVM이 종료되지 않은 상태로, 디버거를 연결하여 오류의 원인을 조사할 수 있다. 디폴트로 이 옵션은 Disable 되어 있다.

-XX:StartFlightRecording=parameter=value

: Java 애플리케이션에 대한 JFR 레코딩을 시작하는 옵션.

'-XX:+UnlockCommercialFeatures' 옵션과 함께 사용해야 하는 상용 옵션이다. 또한 이 옵션은 런타임 중에 레코딩을 시작하는 JFR.start 진단 명령과 동일하다. JFR 레코딩을 시작할 때, 다음과 같은 parameter 들을 지정할 수 있다.

compress={true|false} : gzip 파일 압축 유틸리티를 사용하여 디스크에서 JFR 레코딩 로그 파일을 압축할지 여부를 지정.
defaultrecording={true|false} : 레코딩이 연속적인 백그라운드 레코딩인지 아니면 제한된 시간동안만 동작하는 레코딩인지를 지정하는 parameter. 디폴트로는 false로 지정되어 있다. 연속적인 백그라운드 레코딩을 수행하려면, true로 지정해야 한다.
delay=time : Java 애플리케이션 시작 시간과 레코딩 시작 사이의 지연 시간을 지정하는 parameter. 디폴트로는 값이 0으로 지정되어 있다.
dumponexit={true|false} : JVM이 적절한 방법으로 종료될 때, JFR 데이터의 덤프 파일을 생성해야 하는지에 대한 여부를 지정하는 parameter. 디폴트로는 false로 지정되어 있다. 덤프 파일은 'filename' 파라미터로 지정된 경로에 만들어진다.
duration=time : 레코딩의 기간을 지정. 디폴트로는 값이 0으로, 기간이 제한되어 있지 않음.
filename=path : JFR 레코딩 로그 파일의 경로를 지정하는 parameter.
name=identifier : JFR 레코딩에 대한 식별자를 지정. 디폴트로, Recording x 로 설정되어 있음.
maxage=time : 기본 레코딩에 대해서 디스크 내에 보관될 최대 기한을 지정하는 parameter. 디폴트로 15분으로 지정되어 있음.
maxsize=size : 기본 레코딩에 대해서 디스크 내에서 보관될 최대 크기를 지정하는 parameter. 바이트 단위이다. 디폴트로 0으로 지정되어 있어, 크기가 제한되어 있지 않다.
settings=path : 이벤트 설정 파일의 디렉토리를 지정하는 parameter. 디폴트로 $JAVA_HOME/jre/lib/jfr 에 있는 'default.jfc' 파일이 사용됨.

이 옵션은 여러 parameter들을 쉼표로 구분하여 아래와 같이 사용한다.

-XX:StartFlightRecording=filename=test.jfr,compress=true

-XX:ThreadStackSize=size

: 스레드 스택 크기를 설정하는 옵션. 기본값은 플랫폼에 따라 아래와 같이 달라진다. '-Xss' 옵션과 동일하다.

Linux/ ARM(32비트) : 320 KB
Linux/ i386(32비트) : 320 KB
Linux/ x64(64비트) : 1024 KB
OS X(64비트) : 1024 KB
Oracle Solaris/ i386(32비트) : 320 KB
Oracle Solaris/ x64(64비트) :1024 KB

-XX:+TraceClassLoading

: 클래스가 로드될 때 Tracking을 활성화하는 옵션. 디폴트로 Disable 되어 있다.

-XX:+TraceClassLoadingPreorder

: 로드된 모든 클래스를 참조되는 순서대로 Tracking 하는 옵션. 디폴트로 Disable 되어 있다.

-XX:+TraceClassResolution

: *상수 풀(Constant Pool) resolution을 Tracking 하는 옵션. 디폴트로 Disable 되어 있다.

* Constant Pool Resolution : Resolution이란, Symbolic reference로 표현된 Entry를 찾아서 Direct Reference로 변경하는 과정을 말하는데, 클래스의 모든 Symbolic Reference는 메서드 영역의 Constant Pool이라는 곳에 저장되기 때문에, 이 Resolution을 Constant Pool Resolution이라 부른다. 즉, Constant Pool Resolution 정보란, Constant Pool의 포인터 정보를 일컫는다. 이 포인터 정보(주소)를 보고, Constant Pool(메모리에서의 PEM 영역)을 찾아가는 것이다.

-XX:+TraceClassUnloading

: 언로드되는 클래스들을 Tracking 하는 옵션. 디폴트로 Disable 되어 있다.

-XX:+TraceLoaderConstraints

: 로더 제약조건 레코딩을 Tracking 하는 옵션. 디폴트로 Disable 되어 있다.

-XX:+UnlockCommercialFeatures

: 상용 기능(Commercial Features)을 사용하도록 하는 옵션. 상용 기능들은 아래 링크에 Java SE Products 라고 정의되어 있는, Oracle Java SE Advanced 또는 Oracle Java SE Suite 패키지에 포함되어 있다. 디폴트로 Disable 되어 있으며, 이는 상용 기능(별도의 기능) 없이 JVM이 실행된다는 의미이다. 만일 해당 JVM 프로세스에 이 옵션이 Enable되도록 설정한 이후에는, 프로세스가 종료되지 않는 이상, 중간에 해당 옵션을 Disable 할 수 없다.

이 옵션을 사용하지 않아도, jcmd 진단 명령을 사용하여 가동 중인 JVM 상에서 상용 기능의 잠금을 해제할 수 있다.

http://www.oracle.com/technetwork/java/javase/terms/products/index.html

Java SE Products

Introducing Oracle Java SE Subscriptions The Java SE Advanced, Java SE Advanced Desktop, and Java SE Suite products have transitioned to a Java SE Subscriptions offering that provides more flexibility to customers. Customers who have Java SE Advanced, Java

www.oracle.com

-XX:+UseAltSigs

: JVM 내부 신호로 사용되는 SIGUSR1 및 SIGUSR2 에 대한 대체신호를 지정하는 옵션. 디폴트로 Disable 되어 있으며,

'-Xusealtsigs' 옵션과 동일하다.

-XX:+UseAppCDS

: 애플리케이션 클래스 데이터 공유(AppCDS) 기능을 Enable 하는 옵션. 이때 AppCDS를 사용하려면, CDS 덤프 타임 기간(-Xshare:dump 옵션) 및 애플리케이션 런타임 동안에 -XX:SharedClassListFile 값과 -XX:SharedArchiveFile 값을 지정해야 한다.

이는 상용기능으로서, -XX:+UnlockCommercialFeatures 옵션을 함께 사용해야 한다.

-XX:-UseBiasedLocking

: *Biased Lock 기능을 비활성화하는 옵션. 상당한 양의 제어되지 않은 synchronization 을 가지고 있는 애플리케이션의 경우, 이 옵션이 활성화(+)되어 있는 상태에서 상당한 속도 향상을 달성할 수 있는 반면, 특정 패턴의 lock 기능이 있는 애플리케이션은 속도가 느려질 수 있으므로, 비활성화(-)를 권장한다. 디폴트로 이 옵션은 Enabled 이다.

*Biased Lock : 일반적으로 쓰레드 간 경쟁을 피하기 위해, 개발 시에 Synchronized 키워드를 통해 쉽게 lock을 설정하는데, 그렇게 하면 일부는 여러 쓰레드 간 경쟁이 발생하기보다는 동일한 쓰레드에 대해서만 엑세스가 일어나는 경우가 자주 발생한다. 이런 경우, 모니터를 할당 받고 해제하는 과정이 성능상 비효율적일 수 있는데, Thread id 를 체크하여 lock을 획득하고자 하는 쓰레드가 반복해서 동일한 쓰레드라고 판단되면, OS lock을 사용하지 않도록 하는 lock을 말한다.

-XX:-UseCompressedOops

: **Compressed OOPS 사용을 Disable 하는 옵션. 디폴트로 이 옵션은 Enable 되어 있으며, Java 힙 크기가 32GB 미만일 때에 Compressed OOPS가 사용된다. 이 옵션이 Enable 되어 있으면, 개체 참조가 64비트 포인터 대신에 32비트 offset으로 표시되므로, 일반적으로 힙 크기가 32GB 미만인 환경에서 애플리케이션의 성능을 향상시킬 수 있다. 이 옵션은 64비트 JVM에 대해서만 동작한다.

*OOPS(Ordinary Object Pointers) : java는 포인터가 없는데, 이 말은 즉슨 모든게 포인터가 될 수 있다는 말이기도 하다. jvm은 오브젝트의 레퍼런스를 관리하기 위해 OOPS라고 불리는 자료구조를 가지는데, 32비트 시스템(ILP32)에서는 oops가 최대 힙의 4GB 까지 사용할 수 있다. 64비트 시스템(LP64)에서는 oops가 최대 힙의 18.5EB(엑사바이트) 까지 사용할 수 있다.

**Compressed OOPS : Java 에서는 OOPS가 차지하는 메모리의 양을 줄이기 위해 Tricky 한 방법을 사용한다.

Compressed OOPS 를 통해 32비트 만으로도 32GB 힙을 사용할 수 있도록 하는 것인데, 기존에는 OOPS가 4GB 만큼의 메모리 영역을 직접 관리하였다. 그러나 Compressed OOPS 방식을 통해, OOPS 가 오브젝트를 레퍼런싱 하는 대신, 오브젝트의 offset 을 레퍼런싱하여, 3비트 만큼을 더 사용할 수 있으므로써, 64비트 방식이 아닐 때에도 2^32 (4GB) * 2^3 = 32 GB 만큼의 힙을 사용할 수 있도록 한다. 다만, 32GB 를 넘게 되면, 기존의 OOPS 방식을 사용하게 된다. (64비트 시스템)

-XX:-UseContainerSupport

: VM에서는 VM이 도커 컨테이너 안에서 실행 중인 Java 프로세스에 대해서 사용할 수 있는 메모리 양과 프로세스 수를 결정할 수 있는 자동 컨테이너 감지 기능(Automatic Container Detection)을 제공하는데, 이 정보를 사용하여 시스템 리소스를 할당하는 옵션이다. 이 옵션은 오직 Linux x64 플랫폼에서만 지원되며, 지원된다면 디폴트로 enable되어 있다.

-XX:+UseHugeTLBFS

: 리눅스의 경우, '-XX:+UseLargePages' 옵션을 사용하는 것과 동일한 효과이다. 디폴트로 disable 되어 있다. 이 옵션은 메모리가 점유되어 있는 경우, 모든 *Large Page를 미리 할당하도록 하는 옵션이다. 이렇게 되면, JVM은 Large Page 메모리 영역을 동적으로 늘리거나 축소할 수 없게 된다.

*Large Page : 프로세서 TLB(Translation-Lookaside Buffers) 캐시에서 일부 작업을 제거할 수 있도록 하는 기술이다. 여기서 TLB 캐시란, 가상 메모리 주소를 물리적 메모리 주소로 변환하는 시간을 단축하는 데에 사용된다. 대부분의 아키텍처에서는 여러 Page 사이즈를 지원하며, 대부분 4KB를 기본값으로 가지는데, 메모리 점유가 매우 큰 애플리케이션의 경우, 메모리를 Large Page의 granularity(세분성)와 일치시켜주는 것이 TLB 캐시의 히트율을 높이는 방법으로 합리적이다.
x86-64 에서는 이러한 목적으로 2MB 및 1GB의 페이지를 사용할 수 있으며, 메모리 사용량이 많은 워크로드의 경우, 이러한 Large Page 기능이 매우 큰 영향을 미칠 수 있다.

그러나 Large Pages 가 시스템 퍼포먼스에 부정적인 영향을 미치는 경우도 있다. 예를 들어, 애플리케이션에 의해 많은 양의 메모리가 예약되어 있는 경우, Large Pages 기능은 오히려 regular memory 부족을 초래하고, 다른 애플리케이션에서의 과도한 페이징을 유발하며 이는 전체 시스템을 느리게 만들 수 있다. 또한, 오랜 기간 가동되고 있는 시스템의 경우, 과도한 단편화가 진행되어 있을 것인데, 이는 충분한 Large Page를 할당하지 못하게 하기도 한다. 만약 이렇게 Large Page를 할당하지 못할 경우, OS 또는 JVM에서 regular page를 사용하도록 전환하게 된다.

-XX:+UseLargePages

: Large Page 메모리를 사용 가능하도록 하는 옵션으로, 디폴트로는 disable 되어 있다.

-XX:+UseMembar

: 스레드 상태 전환 시 'Membar(*Memory Barrier)' 를 활성화 하는 옵션. 이 옵션은 ARM을 제외한 모든 플랫폼에서는 디폴트로 Disable 되어 있고, ARM 시스템에서는 디폴트로 Enable 되어 있다. (ARM 서버에서 Disable 시키는 것은 권장하지 않는다.)

*Memory Barrier : 메모리 베리어는 CPU나 컴파일러에게 barrier 명령문 전 후의 메모리 연산을 순서에 맞게 실행하도록 강제하는 기능을 말한다. 즉, barrier 이전에 나온 연산들이 barrier 이후에 나온 연산보다 먼저 실행이 되는게 보장되도록 하는 것이다.

-XX:+UsePerfData

: 'perfdata' 기능을 활성화하는 옵션. JVM 모니터링 및 퍼포먼스 테스트를 허용하기 위해 디폴트로 Enable 되어 있다. 이 옵션을 비활성화 한다면, 'hsperfdata_userid' 디렉토리가 생성되지 않는다.

* perfdata 또는 hsperfdata : Java 코드가 실행될 때, JVM에 의해 생성되는 로그 디렉토리로, 디폴트로 OS 에서 사용하고 있는 tmp 폴더에 생성되며, 파일 이름은 해당 JVM 프로세스의 PID로 된다.

-XX:+UseTransparentHugePages

: 리눅스 환경에서 동적으로 증가 또는 축소가 가능한 Large Pages 기능을 활성화 하는 옵션. 이 옵션은 디폴트로 Disable 되어 있다. Large Page를 만들기 위해 OS가 다른 페이지를 이동할 때, transparent huge page 문제를 마주할 수 있는데, 이 옵션을 통해 해당 문제에 대해 테스트 해볼 수 있다.

-XX:+AllowUserSignalHandlers

: 애플리케이션에 의한 신호 핸들러를 설치할 수 있도록 하는 옵션. 디폴트로 이 옵션은 Disable 되어 있다.

참고

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

java

Large Pages Also known as huge pages, large pages are memory pages that are significantly larger than the standard memory page size (which varies depending on the processor and operating system). Large pages optimize processor Translation-Lookaside Buffers

docs.oracle.com

https://fuirosun.tistory.com/entry/java-endorsed-override-mechanism

java endorsed override mechanism

JDK 8u25 버전을 쓰다가 JDK 업데이트를 하려고 Release Note를 봤다. 8u40릴리즈 노트에 "endorsed-standards override mechanism"가 deprecated API로 잡혀있었는데 처음 들어보는 용어라 찾아봤다. 공식 문서는..

fuirosun.tistory.com

https://xephysis.tistory.com/6

JVM Compressed OOPS

들어가는 말 몇 년 전 elasitcsearch 클러스터를 새로 구성했을 때 heap 관련 설정으로 찾았던 내용을 기록한다. 기본적으로는 ES 공식 가이드 (구버전)의 내용을 따라간다. 요약 jvm 기반의 애플리케이

xephysis.tistory.com

https://yoojin99.github.io/cs/Memory-Barrier/

Memory Barrier, 메모리 배리어란?

Memory Barrier가 무엇인지 알아보자.

yoojin99.github.io

[Java] Spring 프레임워크에서의 MVC 패턴과 레이어드 아키텍처

코_노 — Thu, 3 Nov 2022 11:14:54 +0900

1. MVC 패턴이란?

: 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴의 한 종류를 말하는데, Model-View-Controller의 약자이다.

이 패턴을 사용하는 궁극적인 목적은, 사용자 인터페이스(Interface)로부터 비즈니스 로직(Logic)을 분리함으로써, 애플리케이션의 시각적 요소와 그 이면에서 실행되는 비즈니스 로직 간에 영향을 최소한으로 줄여, 프로그램의 유지 보수성을 높이고, 성능을 향상시키는 데에 있다.

2. MVC 패턴의 구성 요소와 원칙

모델(Model)
: 데이터와 관련된 책임을 담당하는 레이어
- [POJO] 비즈니스 로직을 수행한다.
- 주로 상태 변화를 처리한다. (최근에는 Entity, VO, Aggregate로 나누어서 관리한다. -> 도메인 주도 설계)
- 데이터와 그 데이터를 통한 행동을 갖는 객체이다.

원칙)
"Model은 Controller와 View에 의존해서는 안된다!"
☞ Model이 Controller, View의 책임을 가지면 안 된다는 것이다. 각 레이어에서 담당하는 책임이라는 것이 존재한다.
☞ 오로지 '데이터'에 대한 '순수 로직'만 존재하는 것이 바람직하다.
뷰(View)
: 사용자에게 보여질 사용자 인터페이스(UI)를 담당하는 레이어
- 웹에서는 웹 브라우저로 렌더링 되는 페이지들을 View의 영역으로 말한다.
- 모델이 처리한 데이터를 받아서 합산하고 사용자(Client)의 브라우저로 렌더링 되는 페이지이다.
- 동적으로 처리되어야 할 데이터를 시각화 해주는 역할도 하는데, 이때 상황과 도메인에 따라 달라지는 값을 가져와야 하는 경우에만 Model에서 받아온다.

원칙)
"데이터 및 로직과 관련된 코드가 없어야 한다!"
☞ 오로지 UI에만 관여하는 레이어이므로, 당연하다.

"View는 Model에만 의존해야 한다!"
☞ 여기서 말하는 '의존'은 코드상의 의존이 아닌, 순수 도메인 데이터에 대한 의존을 말한다.
즉, View에 사용되는 값은 오로지 Model을 통해서 전달된 값이어야만 한다는 것이다.
컨트롤러(Controller)
: Model과 View를 연결해주는 레이어
- 일종의 중개자로서, 사용자의 요청에 맞는 서비스를 실행하는데, 이때 실질적인 로직의 처리는 Model에서 진행하는 것이다.
- Model 에서 처리한 값을 View에 전달하여 반환하는 역할도 한다.
- 사용자의 요청(웹 브라우저를 통해 들어오는 요청)을 가장 먼저 마주하는 레이어이다.(URL을 요청 받으면, 그에 맞는 화면을 띄워주므로, View 보다도 먼저 마주한다고 볼 수 있다.)

원칙)
"Controller는 Model과 View에 의존해야 한다!"
☞ 여기서 말하는 '의존'은, 중개자 역할로서의 의존을 말한다. 즉, Controller 혼자 데이터(Model 영역)에 대한 처리를 단독으로 하면 안된다는 말이다.

3. Spring 프레임워크에서의 레이어드 아키텍처(Layered Architecture)

앞서 우리는 MVC 패턴이 무엇인지에 대해 배웠는데, 실무에서는 단순히 Model - View - Controller 인 이 3가지로 구성하다 보면, 여러 문제가 발생할 수 있다. 큰 그림에서는 Model - View - Controller로 구분함으로써, 비즈니스 로직 부분과 UI를 철저하게 구분한다는 원칙에는 변함이 없지만, 백엔드 엔지니어가 실무 프로젝트를 다룬다면, Controller 부분과 Model 부분에서 보통 더 세분화하여 개발하곤 한다. 이 포스팅에서는 그러한 세분화된 패턴인 레이어드 아키텍처에 대해 알아보기로 하자!

Layered Architecture / 출처 : rypro.tistory.com/216

Presentation Layer
- 사용자와 가장 가까운 계층으로, 사용자와의 상호작용을 담당.
- Spring 에서의 MVC 패턴이 가장 도드라지게 나타나는 영역이며, 여기에 프론트-컨트롤러(DispatcherServlet), 컨트롤러, 뷰, 모델이 포함된다.
Business Layer (Service Layer)
- 실제 비즈니스 로직을 수행하는 컴포넌트로, 트랜잭션 및 실질적인 비즈니스 로직 수행 담당.
- 컨트롤러(Presentation Layer)에서 요청을 보내면, *DAO(Data Access Layer) 를 이용하여 실제로 비즈니스 로직을 수행하게 된다.
- 보통 하나의 비즈니스 로직은 하나의 트랜잭션(ACID 특징)으로 동작한다는 원칙이 있다.
Data Access Layer(Repository Layer)
- 데이터베이스에 연동되어 데이터의 저장과 조회를 담당하는 영역.
- DB에 값을 저장하거나 가져오기 위해, JDBC, MyBatis, JPA 등을 사용하여 구현한 DAO 영역이다.

※ 실제 프로젝트에서의 패키지 구성

4. Domain Object / Entity / VO / DTO / DAO 의 개념

DTO, DAO 이해를 위한 그림 / 출처 : https://velog.io/@ohzzi/Entity-DAO-DTO가-무엇이며-왜-사용할까

Domain Object
: 말 그대로 도메인 객체를 말하는데, 여기서 '도메인(Domain)'이란, 일반적인 요구사항, 전문 용어, 그리고 컴퓨터 프로그래밍 분야에서 문제를 해결하기 위해 설계된 어떤 소프트웨어 프로그램에 대한 기능성을 정의하는 연구의 한 영역.
즉, 애플리케이션의 기능, (기획의) 요구사항을 개발하는 영역을 도메인이라고 정의하고 있다.
예를 들어, 온라인 서점 사이트에서 책을 조회하고 구매한다고 가정할 때, 온라인 서점 소프트웨어는 상품의 조회, 구매, 결제 등의 기능을 제공해야 한다. 이때 '온라인 서점'은 소프트웨어로 해결하고자 하는 문제 영역, 즉 도메인에 해당된다.
이러한 도메인은 다시 하위 도메인으로 나눌 수 있으며, '온라인 서점'을 다시 예로 든다면, 하위 도메인으로는 '주문', '결제', '배송' 과 같이 나눌 수 있을 것이다.
JPA 에서는 Entity와 Domain을 용어적인 측면에서 혼용하여 사용하기도 한다.
Entity
: 엔티티의 가장 큰 특징은 식별자를 가진다는 것이다. 즉, 식별자 외의 데이터가 변경된다고 해서, 그 식별자를 가진 객체가 다른 객체가 되지는 않는다는 것이다. 예를 들어, Purchase 라는 도메인이 주문id를 식별자로 가진다고 하자. 이때 Purchase의 주문 상태 데이터를 변경한다고 해서, 해당 주문이 다른 주문으로 되지는 않는다는 말이다.
또한 데이터베이스의 '테이블'과 혼동하면 곤란하다. 엔티티는 SQL 상에 실제로 존재하는 것이 아닌, 일종의 개념이다. 반면 데이터베이스의 테이블은 DB 또는 SQL 상에 실제로 존재하며, 물리적인 구조를 가지고 있다. 따라서 엔티티는 논리 모델에서 사용되고, 테이블은 물리 모델에서 사용되는 용어이다.
정리하면, Entity는 실체, 객체라는 의미를 담고 있으며, 업무에 필요하고 유용한 정보를 저장 및 관리하기 위한 집합적인 개념이라고 말할 수 있다.
Spring에서 사용되는 Entity라는 용어는, 주로 ORM 혹은 ODM 등과 같이 DB의 Row 또는 Document를 객체에 매핑시켜주는 기술에서 사용된다. 즉, 이때의 Entity는 DB 의 데이터와 맵핑되는 객체를 말하며, 식별자가 존재하는 특성 덕분에 Setter를 이용하여 '가변 객체'로서 사용할 수 있다.
VO(Value Object)
: 값 그 자체를 표현하는 객체로 사용된다. VO는 Entity와 달리, 식별자를 가지지 않는다. 즉, VO 객체 내의 단 하나의 데이터라도 변경되면, 그 객체는 서로 다른 객체가 되어 버린다. 이 때문에 같은 객체임을 확실하게 보장하기 위해, VO는 일반적으로 '불변 객체'로서 사용한다. 이 말은 Setter 를 구현하지 않는다는 말이기도 하다. 또한 서로 다른 인스턴스이더라도 값이 같으면 같은 객체가 되기 때문에, 서로 같은 객체인지를 판단할 때, equals 또는 hashCode 를 구현하여 판별한다.
또한 Spring의 MyBatis 를 사용할 때 주로 VO 라는 개념을 사용한다. 그 이유로는, MyBatis는 *SQL-Mapper 이기 때문에, 어떠한 로직에 의해 가져온 데이터는 그저 맵핑되는 값을 가져온 것일 뿐, 실제 DB의 테이블과 매핑되는 것은 아니기 때문이다.

★ MyBatis에서는 VO! / JPA에서는 Entity!
Spring에서 DB와의 연동 기술을 적용할 때, MyBatis(SQL-Mapper)를 사용하는 경우라면, VO 라고 표현 및 사용하고,
JPA(ORM 기술)를 사용하는 경우라면, Entity 라고 표현 및 사용한다.
SQL-Mapper 는 RDBMS를 객체 지향 모델로 매핑하는 걸 도와주는 인터페이스(?)로 보면 된다. 즉, 객체를 SQL statement에 매핑시킬 수 있도록 도와주는 역할만 하므로, SQL문을 명시해줘야 한다. 또한, 개발자가 작성한 SQL 문으로 해당되는 Row를 읽어온 후, 결과 값을 오브젝트화시켜 사용가능하도록 만들어준다.
ORM(Object Relational Mapping)은 데이터베이스를 객체로 매핑함으로써, 객체 간의 관계를 바탕으로 테이블을 만들고 관리하는 것을 말한다. 즉 SQL-Mapper처럼 단순 인터페이스 역할이 아닌, 객체가 DB에 직접적으로 매핑된다는 특징을 가지고 있어, RDBMS 상에서의 '관계' 까지 Object에 반영되며, 이로 인해 SQL문을 명시하지 않고, 정해진 직관적인 코드(메서드)로 데이터를 조작할 수 있게 해준다.
DTO(Data Transfer Object)
: 데이터 교환을 위한 객체이다. DB와 연동되어 있는 VO 또는 Entity에서의 데이터 조작을 피하기 위해, DTO를 로직의 파라미터 및 리턴으로 사용한다. 데이터 교환만을 위해 사용되므로, DTO가 직접적인 로직을 갖지는 않으며, Getter와 Setter 만을 가진다.
DAO(Data Access Object)
: 데이터베이스의 Data에 접근하기 위한 객체이다. 프로젝트의 서비스 레이어(실제 비즈니스 로직이 돌아가는 곳)와 실제 데이터베이스를 연결하는 역할을 하며, 특히 JPA에서는 DB에 데이터를 CRUD 하는 'Repository' 객체들이 DAO에 해당된다.
(정확하게 말하면 'Repository'는 원래 Entity 객체를 보관하고 관리하는 '저장소'를 말하며, 메모리에 로드된 객체 컬렉션에 대한 집합 처리를 위한 인터페이스 제공을 위한 역할이다.
'DAO'는 퍼시스턴스 로직인 Entity Bean을 대체하기 위해 만들어진 개념으로, DB의 CRUD 쿼리와 1:1 매칭되는 세밀한 단위의 오퍼레이션을 제공한다.
JPA를 활용한 개발에서는, 데이터에 접근하도록 하는 DB접근 관련 로직(여러 오퍼레이션)을 모아둔 객체인 DAO의 기능이 하나의 Repository 안에 포함시켜 개발하는 경우가 많으므로, 용어적인 측면에서 DAO와 Repository를 동일한 의미로 사용하기도 한다.)

/* MemberService 코드 */

import {Group}.{Artifact}.domain.Member;
import {Group}.{Artifact}.repository.MemberRepository;

import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class MemberService {

    private final MemberRepository memberRepository;

    //회원 가입
    @Transactional
    public Long join(Member member) {
        validateDuplicateMember(member);    // 중복 회원 검증 로직
        memberRepository.save(member);
        return member.getId();
    }

    private void validateDuplicateMember(Member member) {
        //EXCEPTION
        List<Member> findMembers = memberRepository.findByEmpID(member.getEmp_ID());
       if (!findMembers.isEmpty()) {
           throw new IllegalStateException("이미 존재하는 회원입니다.");
       }
    }

    //회원 전체 조회
    public List<Member> findMembers() {
        return memberRepository.findAll();
    }
    
    //회원 단일 조회
    public Member findOne(Long memberId) {
        return memberRepository.findOne(memberId);
    }

    @Transactional
    public void update(Long id, String mem_Name) {
        Member member = memberRepository.findOne(id);
        member.setMem_Name(mem_Name);
    }
}

/* Member 엔티티 */


import lombok.Getter;
import lombok.Setter;

import javax.persistence.*;

@Entity
@Getter @Setter
public class Member {

    @Id @GeneratedValue
    @Column(name = "pri_member_id")
    private Long id;

    //권한 부여 위한 그룹 넘버링
    private Long GROUP_NO;

    //회원 사번
    private Long emp_ID;

    //회원 이름
    private String mem_Name;

    //회원 직급
    private String level;

    //회원 로그인 아이디
    private String mem_ID;
    //회원 패스워드
    private String mem_PWD;


}

/* MemberRepository 코드 */

import {Group}.{Artifact}.domain.Member;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

import javax.persistence.EntityManager;
import java.util.List;

@Repository
@RequiredArgsConstructor
public class MemberRepository {

    private final EntityManager em;

    public void save(Member member) {
        em.persist(member);
    }

    public Member findOne(Long id) {
        return em.find(Member.class, id);
    }

    public List<Member> findAll() {
        return em.createQuery("SELECT m from Member m", Member.class).getResultList();
    }

    public List<Member> findByEmpID(Long emp_Id) {
        return em.createQuery("SELECT m from Member m WHERE m.emp_ID = :emp_ID", Member.class)
                .setParameter("emp_ID", emp_Id)
                .getResultList();
    }

//    public Member findByEmpID(Long emp_id) {
//        return em.find(Member.class, emp_id);
//    }

}

참고

https://m.blog.naver.com/jysaa5/221751719334

[용어] MVC, Spring Framework MVC, Controller, Service, DAO, DTO, VO - 개념

MVC (Model-View-Controller) - 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다. - 이 패...

blog.naver.com

https://velog.io/@jybin96/Controller-Service-Repository-%EA%B0%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

Controller, Service, Repository 가 무엇일까?

찾아본 결과 Controller가 무엇인지 알기 전에 MVC 패턴에 대하여 먼저 아는 것이 중요합니다!MVC패턴은 Model-View-Controller의 약자로서 개발을 할 때 3가지 형태로 역학을 나누어 개발하는 방법론입니

velog.io

https://murphymoon.tistory.com/entry/%EC%9A%B0%EC%95%84%ED%95%9C-%ED%85%8C%ED%81%AC-MVC-%EB%A6%AC%EB%B7%B0-%EB%A0%88%EC%9D%B4%EC%96%B4-MVC-%ED%8C%A8%ED%84%B4-5%EB%A0%88%EC%9D%B4%EC%96%B4

우아한 테크 -MVC 패턴 리뷰- [레이어, MVC 패턴, 5레이어]

발표자료들 범블비(2020) : MVC 패턴에 대한 설명 + MVC 패턴의 역사 제리(2021) : MVC 패턴의 활용성에 대한 원칙 해리&션(2019) : MVC의 Model, Controller, View에 대한 소개. 제이임(2019)의 MVC 패턴 : 미션과 관

murphymoon.tistory.com

https://www.inflearn.com/questions/111159

domain과 repository 질문 - 인프런 | 질문 & 답변

안녕하세요, 강의 듣다 궁금증이 생겨 질문 남깁니다. 질문 1. domain == vo, repository == dao 이렇게 똑같이 봐도 괜찮은 건가요? 같은 것이라면 왜 vo, dao가 아닌 다른 이름을 사용한 것인지, 다른 것이

www.inflearn.com

https://www.inflearn.com/questions/16046

프로젝트 폴더 구조와 강의 일정에 관하여 질문이 있습니다. - 인프런 | 질문 & 답변

1. 실무에서 프로젝트 구현시 보통 폴더 구조를 어떤식으로 하시나요? 프로젝트를 하는데 폴더 구조를 어떻게 해야 좋을지 궁금합니다. 강의와 같이 api 패키지를 하나 만들고 Controller 클래스 안

www.inflearn.com

https://rypro.tistory.com/216

[Spring] Layered Architecture

Layered Architecture 효율적인 개발과 유지보수를 위해 어플리케이션을 계층화하여 개발하는 것을 말한다. 대체적으로 중/대규모 어플리케이션에서 사용하고 있다. Pressentation Layer - 사용자와 가장

rypro.tistory.com

https://doing7.tistory.com/79

Domain, Entity, Value(Object)

Spring 프로젝트 중에 Domain, Entity, VO(value object)라는 용어들이 반복적으로 등장하지만, 정작 이들의 차이를 모르고 있다는 생각이들었다. 이에 관련되어 더 공부하고자 DDD START 도메인 주도 설계(최

doing7.tistory.com

https://velog.io/@gidskql6671/DTO-VO-Entity

DTO, VO, Entity

데이터를 다루기 위해 사용되는 개념들인 DTO, VO, Entity에 대해 정리하려고 한다.

velog.io

[Java] Spring Boot에서 H2 데이터베이스 설치 및 테스트 작동 확인하기

코_노 — Mon, 24 Oct 2022 13:34:00 +0900

1. H2 데이터베이스 설치

https://www.h2database.com/html/main.html

H2 Database Engine

H2 Database Engine Welcome to H2, the Java SQL database. The main features of H2 are: Very fast, open source, JDBC API Embedded and server modes; in-memory databases Browser based Console application Small footprint: around 2.5 MB jar file size Supp

www.h2database.com

위 링크에서 OS에 맞는 버전을 설치하면 된다.

H2 설치 화면

H2를 실행하려면 H2가 설치되는 디렉토리를 반드시 기억해야 한다! 설치되기 전에 설치되는 디렉토리를 꼭 확인하자!

2. H2 데이터베이스 실행하기

H2의 디렉토리에서 'bin' 으로 이동 후 H2 실행

나는 OS가 Windows 10 이므로, Powershell로 H2가 설치된 디렉토리인 C:\Program Files (x86)\H2 로 이동한 뒤, 'bin' 디렉토리로 이동하여 'h2.bat' 프로그램을 실행하였다. 그러면 H2 데이터베이스가 실행되면서, 아래 그림과 같은 H2 콘솔 화면이 뜨게 된다.

H2 실행한 후, 콘솔 화면

3. H2 데이터베이스 파일 만들기(DB 맨 처음 만들 때에만 하는 과정)

H2 콘솔 화면

H2 데이터베이스를 처음 만들 때에는 반드시 DB 파일을 생성해주어야 한다. [JDBC URL] 항목에 해당 DB 파일이 설치될 경로를 입력해주는 데, 이때 양식은 'jdbc:h2:{DB 파일이 설치될 경로}' 이다.

위 그림에서는 '~/h2_db_testfile' 이라고 지정하여, 홈 디렉토리에 'h2_db_testfile' 이라는 이름으로 H2 데이터베이스 파일을 생성하겠다는 것이다.

연결을 누르면 콘솔 창이 아래 그림처럼 이동하면서 DB에 연결된다.

H2 DB에 연결된 화면 (H2 콘솔 창)

또한 홈 디렉토리로 이동하면 아래 그림과 같은 지정한 이름으로 파일(.mv 형식)이 생성된 것을 확인할 수 있을 것이다!

생성된 H2 데이터베이스 파일

4. Spring Boot 프로젝트와 H2 데이터베이스 연동시키기 (application.yml 작성)

application.yml 디렉토리 반드시 확인!

자 이제 H2 데이터베이스 파일도 생성된 것을 확인했으니, 우리가 작성하는 Spring Boot 프로젝트에서 생성한 DB로 연동하는 것을 해보자!

우선 프로젝트 폴더 내의 [src] - [main] - [resources] 디렉토리 아래에 'application.yml' 파일을 생성해주자!

이때 디폴트로 'application.properties' 라는 파일이 있을 텐데, 프로젝트의 설정 파일은 하나만 존재해야 하므로, 본 포스팅에서는 해당 파일을 삭제하고 'application.yml' 파일로 새로 작성하기로 한다.

application.yml 파일의 내용은 아래와 같다.

spring:
    datasource:
        url: jdbc:h2:tcp://localhost/~/h2_db_testfile;
        username: sa
        password:
        driver-class-name: org.h2.Driver
    
    jpa:
        hibernate:
            ddl-auto: create
        properties:
            hibernate:
                show_sql: true
                format_sql: true
                
logging:
    level:
        org.hibernate.SQL: debug

참고로 위 코드에서 보이는 들여쓰기는 반드시 4칸으로 해야 한다.

위 코드를 하나하나 해석하자면 다음과 같다.

spring.datasource : DB Connection 정보
spring.jpa.hibernate.ddl-auto :
none : No action is performed. The schema will not be generated.
create : Create the schema, the data previously present (if there) in the schema is lost
create-drop : (default) Create the schema with destroying the data previously present(if there). It also drop the database schema when the SessionFactory is closed.
update : update the schema with the given values.
validate : validate the schema. It makes no change in the DB.
spring.jpa.properties.hibernate.show_sql : 콘솔에 JPA 실행 쿼리 표시할지 여부 지정
spring.jpa.properties.hibernate.format_sql : 실행쿼리를 가독성 있게 표현할지 여부 지정
logging.level.org.hibernate.SQL : 로깅 레벨을 지정

5. H2 데이터베이스에 잘 연동되었는지 테스트 하는 코드 작성

application.yml 작성을 통한 애플리케이션-DB 간 연동 과정을 마쳤으니, 이제 실제로 애플리케이션의 로직이 DB에 잘 반영되는지 테스트를 해보자!

5.1. Entity 클래스 생성 - 'Member'

프로젝트의 [src] - [main] - [java] - [프로젝트 아티팩트] 디렉토리 아무 곳에 다음과 같은 'Member' 엔티티 클래스를 생성해주자.

import lombok.Getter;
import lombok.Setter;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity
@Getter @Setter
public class Member {

    @Id
    @GeneratedValue
    private Long id;

    private String username;
}

5.2. Repository 클래스 - 'MemberRepository'

프로젝트의 [src] - [main] - [java] - [프로젝트 아티팩트] 디렉토리 아무 곳에 다음과 같은 'MemberRepository' 클래스를 생성해주자.

import org.springframework.stereotype.Repository;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Repository
public class MemberRepository {

    @PersistenceContext
    private EntityManager em;
	
    // H2 DB에 member 엔티티에 해당하는 데이터 생성
    public Long save(Member member) {
        em.persist(member);
        return member.getId();	// member 가 잘 생성되었는지 확인하기 위한 id 컬럼 조회
    }
	
    // 
    public Member find(Long id) {
        return em.find(Member.class, id); // 해당 id 값을 가지는 레코드 조회
    }
}

5.3. 테스트 코드 작성 - 'MemberRepositoryTest'

프로젝트 내의 [src] - [test] - [java] - [프로젝트 아티팩트] 디렉토리 아무 곳에 다음과 같은 'MemberRepositoryTest' 클래스를 생성해 주자.

import org.assertj.core.api.Assertions;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.annotation.Rollback;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.transaction.annotation.Transactional;


@RunWith(SpringRunner.class)
@SpringBootTest
public class MemberRepositoryTest {

    @Autowired MemberRepository memberRepository;

    @Test
    @Transactional
    @Rollback(false)	// H2 DB 상에서 직접 확인하기 위해, 테스트 이후에도 DB를 롤백하지 않겠다.
    public void testMember() throws Exception {
        //given
        Member member = new Member();
        member.setUsername("memberA");

        //when
        Long savedId = memberRepository.save(member);
        Member findMember = memberRepository.find(savedId);

        //then
        Assertions.assertThat(findMember.getId()).isEqualTo(member.getId());
        Assertions.assertThat(findMember.getUsername()).isEqualTo(member.getUsername());

    }
}

위와 같은 테스트 코드를 작성한 후, Run 하여 테스트 코드가 정상적으로 작동한다면, 애플리케이션과 H2 DB 간 연동이 잘 되었다는 것을 의미한다.

MemberRepositoryTest 테스트 코드 정상 작동

6. H2 데이터베이스 상에서 쿼리 통한 직접 확인

H2 콘솔 화면 - 생성한 테스트 데이터 조회

H2 콘솔로 DB에 접속하여, 직접 SELECT 쿼리를 날려서 데이터가 제대로 들어갔는지 확인할 수 있다.

위 그림처럼 테스트 코드에서 추가한 레코드가 존재한다면, 애플리케이션과 DB 간 연동이 되었다는 것을 이제 확신할 수 있을 것이다!

참고로 위 그림은 MEMBER 도메인에 'city', 'street', 'zipcode' 라는 튜플을 추가하고, 'id' 컬럼을 'member_id'로, 'username' 컬럼을 'name'으로 바꾼 것이다. 5.1. 과 똑같은 코드를 작성했다면, 'id', 'username' 컬럼이 나타날 것이다.

참고

인프런 - 실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발 (김영한 님 강의)

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-JPA-%ED%99%9C%EC%9A%A9-1/unit/24278

학습 페이지

www.inflearn.com

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-JPA-%ED%99%9C%EC%9A%A9-1/unit/24279

학습 페이지

www.inflearn.com

https://vkein.tistory.com/entry/JPA-%EC%84%A4%EC%A0%95h2-%EC%83%98%ED%94%8C-applicationyml

JPA 설정(h2) 샘플 (application.yml)

spring: datasource: url: jdbc:h2:tcp://localhost/~/task_agile_test username: sa password: driver-class-name: org.h2.Driver jpa: database-platform: org.hibernate.dialect.H2Dialect open-in-view: false..

vkein.tistory.com

[Ansible] 베이그런트(Vagrant)를 통해 Virtualbox 프로비저닝 하기

코_노 — Thu, 13 Oct 2022 16:34:20 +0900

0. 베이그런트(Vagrant) 란?

: 포터블 가상화 소프트웨어 개발환경(Virtualbox, Hyper-X, Docker container, VMware, AWS 등)의 생성 및 유지보수를 위한 오픈 소스 소프트웨어 제품의 하나. 'HashiCorp' 회사의 제품이다. (베이그런트의 default 설치 디렉토리가 C:\HashiCorp\Vagrant\ 이므로 참고하자!)

베이그런트 파일은 Ruby 로 작성되어 있으나, PHP, Python, Java, C#, JS 와 같은 다른 프로그래밍 언어들로 작성된 프로젝트에서도 사용할 수 있다.

※ 프로비저닝(Provisioning) : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다.

서버 리소스 프로비저닝, OS 프로비저닝, 소프트웨어 프로비저닝, 스토리지 프로비저닝, 계정 프로비저닝 등이 있으며, 이를 수동으로 처리하는 '수동 프로비저닝'과 자동화 툴을 통해 처리하는 '자동 프로비저닝'으로 나뉜다.

Vagrant의 기초 명령어

vagrant init
: 프로비저닝을 해주는 예제 스크립트 생성
vagrant up
: Vagrant 파일을 읽어들여 프로비저닝을 진행
vagrant halt
: 베이그런트에서 다루는 host 들을 종료
vagrant destroy
: 베이그런트의 host 들을 삭제
vagrant ssh
: 베이그런트의 host 에 ssh 로 접속
vagrant provision
: 베이그런트의 host 의 설정 변경 적용

1. notepad++ 설치

노트패드란++ 란?

: 문서 편집기이자, 소스 코드 편집기이다. Windows 에서 기본으로 제공하는 문서 편집기인 메모장에 견주어, notepad++ 는 탭 편집을 제공하므로 여러 개의 파일을 동시에 열어서 편집할 수 있다. 50개 이상의 프로그래밍, 스크립트, 마크업 언어에 대한 문법 강조 및 코드 접기를 지원한다.

다른 문서 편집기가 편하다면 다른 걸 설치해도 상관 없다!

notepad++ 설치 링크

https://notepad-plus.en.softonic.com/download?utm_source=SEM&utm_medium=paid&utm_campaign=EN_UK_DSA&gclid=Cj0KCQjwy5maBhDdARIsAMxrkw2axoWUjmN-spAxl4-4mFVV3PpYu8T4pkKupFQJXXt5pGcZw874D4oaAp9ZEALw_wcB

Notepad++

Free open-source text & code editor

notepad-plus.en.softonic.com

2. 베이그런트 설치 및 초기화

2.1. 베이그런트 설치

Vagrant 설치 링크

https://www.vagrantup.com/downloads

Vagrant by HashiCorp

Vagrant enables users to create and configure lightweight, reproducible, and portable development environments.

www.vagrantup.com

위 링크를 통해 베이그런트를 설치한 후, 정상적으로 설치되었는지 확인하기 위해, cmd 창을 열어서 'vagrant' 를 입력하면 아래와 같이 나타나게 된다.

Vagrant 정상 설치 이후 cmd

2.2. 베이그런트 초기화

[vagrant 설치 디렉토리 이동] - [베이그런트 초기화]

'vagrant init' 명령어를 통해 C:\HashiCorp 디렉토리에 'Vagrantfile' 이라는 샘플 코드를 만들게 되는데, 이 샘플 코드를 수정하여 앞으로의 베이그런트 원하는 동작을 수행하게 될 것이다.

'Vagrantfile' 샘플 코드

3. 베이그런트 파일 수정 및 플러그인 설치

3.1. 'Vagrantfile' 수정

[config.vm.box] 수정하기

15번째 줄에 보면 'config.vm.box' 라는 부분의 값이 "base"로 되어 있는데, 이 값을 수정하여 Virtualbox 의 VM 이미지의 OS를 지정할 수 있다.

우리가 하려고 하는 CentOS 설정 방법은 위 코드 14번째 줄에 'https://vagrantcloud.com/search' 에서 찾을 수 있다!

Vagrant.configure("2") do |config|
  config.vm.box = "centos/7"
end

CentOS로 설정하는 법은 위와 같으므로, 아래 그림처럼 코드를 수정해준다.

[config.vm.box] 값 수정 완료 후

3.2. 베이그런트 플러그인 설치 - Virtualbox 확장팩 위함

Virtualbox 의 경우, 각각의 VM들의 모든 기능을 사용하기 위해서는 Virtualbox 확장팩이 필수적이다.

베이그런트에서는 Virtualbox 확장팩을 설치할 수 있도록 하는 명령어를 자체 제공하는데, 이는 다음과 같다.

vagrant plugin install vagrant-vbguest

베이그런트를 통한 Virtualbox 확장팩 설치 명령어 결과

4. 프로비저닝한 CentOS 이미지를 Virtualbox 에 설치하기

# 아직 VM을 생성하지 않았다면,
vagrant up

# VM을 생성했으나, 중간에 멈추거나 에러가 나와서 다시 가동시키려고 한다면,
vagrant reload

그런데 3.2에서 설치한 Virtualbox 확장팩 버전에 문제가 있는지, 아래와 같은 에러를 뿜으며 VM 생성이 제대로 되지 않았었다.

Error: Nothing to do
Unmounting Virtualbox Guest Additions ISO from: /mnt
umount: /mnt: not mounted
==> servernfs: Checking for guest additions in VM...
    servernfs: No guest additions were detected on the base box for this VM! Guest
    servernfs: additions are required for forwarded ports, shared folders, host only
    servernfs: networking, and more. If SSH fails on this machine, please install
    servernfs: the guest additions and repackage the box to continue.
    servernfs:
    servernfs: This is not an error message; everything may continue to work properly,
    servernfs: in which case you may ignore this message.
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

umount /mnt

Stdout from the command:



Stderr from the command:

umount: /mnt: not mounted

https://www.devopsroles.com/vagrant-no-virtualbox-guest-additions-installation-found-fixed/

Vagrant No VirtualBox Guest Additions installation found [Fixed] - DevopsRoles.com free 1

How to fix the error Vagrant No VirtualBox Guest Additions installation found....

www.devopsroles.com

구글링해본 결과 위 링크의 게시글을 발견했는데, Virtualbox 확장팩의 버전을 '0.21' 로 재설치하면 된다고 하여 시도해봤더니, 베이그런트를 통한 Virtualbox에 CentOS 이미지 설치가 잘 되었다! 재설치 명령어는 아래와 같다.

# 기존의 Virtualbox 확장팩 삭제
vagrant plugin uninstall vagarnt-vbguest

# '0.21' 버전의 Virtualbox 확장팩 설치
vagrant plugin install vagrant-vbguest --plugin-version 0.21

# 확장팩 재설치후, vagrant 다시 프로비저닝
vagrant reload

5. 베이그런트 ssh로 접속하여 상태 확인

'vagrant ssh' 명령어를 입력하여 생성한 VM에 접속하면 아래와 같이 성공한 것을 볼 수 있다.

vagrant ssh 접속 성공 화면

참고

인프런 강의 - [기초-응용] 다양한 환경을 앤서블(Ansible)로 관리하기 with 베이그런트(Vagrant) (조훈 님 강의)

https://www.inflearn.com/course/ansible-%EC%9D%91%EC%9A%A9/unit/10185

학습 페이지

www.inflearn.com

[Git] 브랜치(branch) 전략 - git-flow 방식 / github-flow 방식 / git-lab 방식

코_노 — Fri, 7 Oct 2022 13:53:25 +0900

1. 브랜치(branch) 란?

브랜치(branch) : 독립적으로 어떤 작업을 진행하기 위한 개념. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않으므로, 여러 작업을 동시에 진행할 수 있도록 해주는 개념이다.

브랜치 개념 / 출처 : backlog.com/git-tutorial/kr/

브랜치의 기본적인 메커니즘은 다음과 같다.

여러 명이서 동시에 작업을 할 때, 다른 사람의 작업에 영향을 주거나 받지 않도록, 메인 브랜치(master)에서 각자의 작업 전용 브랜치를 만든다. 그리고 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용함으로써, 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하여 그 결과를 하나로 모아 나가게 된다.

하나의 '작업 단위'인 브랜치를 통해 작업하는 중간 중간에 기록을 남기게 되므로, 작업 중간에 발생하는 문제의 원인을 찾아 대첵을 세우기 수월해진다.

브랜치의 개념(2) / 초록색=메인브랜치 / 출처 : backlog.com/git-tutorial/kr

2. origin/master 브랜치와 master 브랜치

git을 사용하다 보면, 'origin/master' 와 'master' 라는 용어를 보게 될텐데, 처음 보면 도대체 무슨 말인지 알 수 없을 때가 있다. 간단히 말하면, 'origin/master'는 원격 저장소의 master 브랜치를 말하고, 'master'는 로컬 저장소의 메인 브랜치(master 브랜치) 를 말한다. 대부분 원격 저장소의 master 브랜치(origin/master)는 소스코드의 배포 직전 최종본이므로, 가장 최신 기능과 안정적인 버전인 상태로 두고, 로컬 저장소에 이 원격 저장소의 소스코드를 불러와 수정 작업을 진행하게 된다.

그렇다면 현재 내가 어떤 브랜치에서 작업을 하고 있는지 확인을 해야 되는데, 이것이 바로 'HEAD'라는 개념이다.

git 에서 HEAD는 특정 브랜치의 마지막 커밋에 대한 포인터이다.

HEAD 개념(1) / 출처 : soy3on.tistory.com/152

위 그림을 보면, 'HEAD'가 'master' 와 'origin/master', 'origin/HEAD'를 화살표를 통해 가리키고 있는 것을 볼 수 있다.

이는 현재 내가 작업하고 있는 브랜치가 로컬 저장소의 master이며, 이 로컬 저장소 master 브랜치의 최종 커밋이 origin/master 브랜치의 최종 커밋과 일치한다는 것을 의미한다. 즉, 원격 저장소의 소스코드 내용과 로컬 저장소의 소스코드 내용이 일치한다는 것이다.

'origin/HEAD' 에서의 'HEAD'는 원격 저장소의 현재 작업 위치를 나타내므로, 현재 원격 저장소의 작업 위치는 'origin' 브랜치임을 의미한다.

참고로 위 git log는 아래에서 위로 봐야 시간 순서와 일치한다.

그렇다면 내 로컬 저장소에서 'f3.txt' 라는 파일을 생성하고, 이를 로컬 저장소의 'master' 브랜치에 커밋하면 어떻게 될까?

HEAD 개념(2) / 출처 : soy3on.tistory.com/152

위 그림처럼 'HEAD' 가 'master'만을 가리키는 것을 볼 수 있는데, 이는 현재 최종 커밋이 로컬 저장소의 'master' 브랜치임을 의미한다. 또한 이는 'f3.txt' 파일을 생성한 후 커밋한 후, 원격 저장소로의 push는 진행하지 않았기 때문에, 원격 저장소의 메인 브랜치인 'origin/master' 브랜치와는 최종 커밋이 서로 다름을 의미한다.

git status / 출처 : soy3on.tistory.com/152

이 상태에서 위 그림처럼 'git status' 명령어의 출력 결과를 확인하면 더 확실히 이해할 수 있다!

'On branch master' : 현재 checkout 된(작업하고 있는) 브랜치가 'master' 브랜치이다.

'Your branch is ahead of 'origin/master' by 1 commit.' : 현재 당신이 작업하고 있는 브랜치는 'origin/master' 브랜치보다 1커밋 앞선다. 즉, 현재 작업하고 있는 master 브랜치가 원격 저장소의 'origin/master' 브랜치보다 1 커밋 변경사항이 생겼다.

git status 명령어를 통해 push 하라는 메시지도 받을 수 있으니, 현재 내 작업 상황과 원격 저장소의 싱크가 맞는지 궁금하면 git status 를 잘 활용하면 될 것이다!

3. 브랜치 전략을 세워야 하는 이유

브랜치 전략이란?

: 여러 명의 협업자가 Git의 브랜치(branch)를 사용하여 하나의 공동 저장소를 효율적으로 사용하기 위한 전략 (Work-Flow)을 말한다.

브랜치 전략을 세우지 않고 그때그때마다 필요한 브랜치를 마구 생성하거나, 또는 하나의 브랜치로만 계속 개발을 하게 된다면, 체계 없는 브랜치 생성과 병합이 생길 수 있고, 이에 따른 중구난방 흩어진 이슈와 커밋(개발 히스토리) 관리가 되지 않으며, 이는 곧 협업의 어려움과 프로젝트의 마감의 연기, 중단까지 이어질 수 있다.

브랜치 전략 수립의 목표는, 범용적으로 사용되는 'Git-flow', 'Github-flow', 'Gitlab-flow' 를 참고하여 각 회사 또는 조직마다의 환경 및 제약 조건을 반영한, 최상의 코드 품질 및 유지 보수성을 목적에 둔 코드 저장 관리 방식이 되어야 한다.

그렇다면 범용적으로 사용되는 'Git-flow', 'Github-flow', 'Gitlab-flow' 의 개념에 대해 알아보자!

4. 브랜치 전략의 종류

4.1. Git-flow 방식

Git-flow 방식의 예시 / 출처 : https://nvie.com/posts/a-successful-git-branching-model/

2010년, 'nvie'라는 닉네임을 사용하는 개발자에 의해 알려지기 시작한 방식으로, 프로젝트의 규모가 어느정도 있다면, 대부분의 팀들이 채택하는 방식이다. 그러나 최근에는 Git-flow 방식은 소프트웨어 버전 관리가 필요한 APP이나 솔루션, 또는 public API에 적합한 워크플로우라고 보는 시선도 많다. 웹 어플리케이션에서 Git-flow는 고려할 전략이 아니라고 본다.

브랜치를 대략 5가지로 구분하는데 각 브랜치마다의 기능 및 목적 은 다음과 같다.

master : 제품 출시를 위한 코드
develop : master 브랜치를 최초 base로 둔, 다음 버전의 개발을 위한 코드
feature/{feature_name} : 제품의 세부 기능(새로운 기능) 개발을 위한 코드
- 베이스 브랜치 : develop
- merge의 목적지 : develop
- origin 브랜치에는 반영하지 않고, 주로 개발자의 repo에만 존재하는 경우가 많음.
release : 어느정도 완성된 develop 브랜치를 최초 base로 둔, 제품 출시 준비(QA 등)를 위한 코드
- 베이스 브랜치 : develop
- merge의 목적지 : develop, master
- 안정적인 상태의 develop 브랜치에서 release 브랜치를 생성한 후, develop 브랜치에서는 다음 버전 배포를 위한 새로운 기능 개발에 주력하도록 만들 수 있게 된다.
- release 브랜치에서는 디버그에 대한 부분만 커밋하도록 하며, 완전한 deploy에 대한 준비가 완료되었다고 판단되었을 때, master로의 병합을 진행한다.
- merge를 끝낸 후에는, tag 명령을 통해 배포 버전에 대한 기록을 남기도록 한다.
- release 에서 수정된 커밋들이 master로의 merge 까지 완료되었다면, 이후 새로운 안정적인 develop 브랜치 구성을 위해, develop 브랜치로의 merge를 수행한다.
hotfix : master 브랜치를 최초 base로 둔, 이미 출시된 버전의 버그 수정을 위한 코드
- 베이스 브랜치 : master
- merge의 목적지 : develop, master
- 배포된 제품(origin/master)에서 버그가 발생했을 경우, 신속한 처리를 위한 브랜치이다. 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영하며, tag를 통한 관련 정보를 기록해둔다. 이후 버그를 해결하면 제거하는 것이 원칙이다.
- release 브랜치가 이미 생성되어 관리중인 상태라면, 해당 브랜치에 hotfix 정보를 병합시켜 다음 deploy 시(master로의 merge), 반영이 정상적으로 이루어질 수 있도록 해야 한다.

Git-flow 방식을 운용하는 구조 및 흐름은 다음과 같다.

가장 많이 사용하는 브랜치(base를 두는)는 master 와 develop이 되며, 정상적인 프로젝트를 진행하기 위해서는 둘 모두를 운용해야 한다.
feature, release, hotfix 브랜치는 사용하지 않는다면 지워도 오류가 발생하지 않아야 하며, 깔끔한 프로젝트 진행을 원한다면 필요 없어진 것들은 지우고, 필요한 상황이 왔을 때에만 따로 만드는 것을 권장한다.
대부분의 작업은 develop 브랜치에 취합한다고 생각하면 되고, QA를 통해 더 이상의 변동사항이 없을 것이라고 판단될 때 master 브랜치로의 병합을 진행한다.
master가 아닌 나머지 브랜치들은 master의 변동사항을 꾸준히 주시해야 한다.

4.2. Github-flow 방식

Github-flow 방식의 프로세스 / 출처 : subicura.com/git/guide/github-flow.html

Github-flow 예시 / 출처 : brownbears.tistory.com/603

2011년, GitHub CIO인 Scott Chacon이 처음 언급한 방식으로, Git-flow 가 가진 가장 큰 문제는 개발자가 요구하는 상황보다 훨씬 더 복잡한 프로세스라고 지적하면서 생겨난 방식이다. Work-flow를 단순화해야 개발자들이 빨리 습득할 수 있으며, 단순할수록 오버헤드가 발생하지 않아 브랜치 전략을 이해하지 못하여 생기는 문제를 줄일 수 있다고 보는 관점이다.

등장한 배경처럼 진행 방식 또한 굉장히 단순하다. 따라서 상시 배포가 가능하고 그렇게 수행하는 프로젝트에 적절한 방법이다. 또한 상시 배포 환경이므로, CI/CD 자동화가 되어 있는 것이 바람직하다.

Github-flow 의 메커니즘 및 정책은 다음과 같다.

origin/master 브랜치는 언제든지 배포가 가능하다.
새로운 프로젝트는 master 브랜치를 기반으로 별도 브랜치를 생성하여 작업을 진행한다.
기본적으로 개발 브랜치는 개발자 로컬에 commit 하고, 정기적으로 원격 브랜치에 push 한다.
피드백 또는 도움이 필요하거나, 코드를 merge할 준비가 되었다면 pull request 를 만든다.
다른 사람들의 피드백과 master 브랜치의 최종 승인자가 검토 및 승인을 마치면 master 브랜치(원격 저장소)에 merge 한다.

4.3. Gitlab-flow 방식

pre-production 브랜치가 없는 GitLab-flow 방식 / 출처 : brownbears.tistory.com/605

pre-production 브랜치가 추가된 GitLab-flow 방식 / 출처 : brownbears.tistory.com/605

Gitlab-flow 방식의 메커니즘 및 정책은 다음과 같다.

production 브랜치는 오직 배포만을 담당한다. (Git-flow 방식에서의 master 브랜치와 동일 취급)
master 브랜치는 production 브랜치로의 병합을 목적으로 한다. (Git-flow 방식에서의 develop 브랜치와 비슷한 역할)
pre-production 브랜치가 존재한다면, production 브랜치로 merge 하기 전, QA 과정을 진행한다. (스테이징 서버와 비슷)
실제 기능을 개발하는 feature 브랜치는 master 브랜치에서 분기(생성)하도록 한다.
production 브랜치에서 릴리즈된 코드가 항상 프로젝트의 최신 버전 상태를 유지할 필요가 없다.
최신 버전의 상태는 master 브랜치 또는 pre-production 브랜치가 담당하게 되는 것이다.

마치며

위 3가지 Work-flow 중 어떤 것이 가장 나은 방식이라고 딱 정할 수 없다. 프로젝트, 개발자, 개발 환경, 팀 환경, 릴리즈 계획 등 모든 상황을 검토한 후, 가장 적절한 방법을 선택하는 것이 가장 나은 방식이 된다. 대신 수년간 검증되어 온 위 3가지 방식을 골자로 하여 해당 프로젝트 또는 팀 환경에 맞게 변형한다면, 최고의 Work-flow 가 탄생할 것이라고 본다.

참고

http://blog.hwahae.co.kr/all/tech/tech-tech/9507/

Git 브랜치 전략 수립을 위한 전문가의 조언들 – 화해 블로그 | 기술 블로그

Git 브랜치 전략 효과적으로 VCS를 사용하려면 프로젝트 여건에 어울리는 브랜치 전략을 세워야 합니다. 이를 위한 첫 번째는 바로 브랜치 전략에 대한 비교 분석입니다. Git기반으로 워크플로우

blog.hwahae.co.kr

https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html

누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog

누구나 쉽게 알 수 있는 Git에 입문하신 것을 환영합니다. Git을 사용해 버전 관리를 할 수 있도록 함께 공부해봅시다!

backlog.com

https://soy3on.tistory.com/152

HEAD -> master, origin/master의 의미

HEAD -> master, origin/master의 의미 다음은 git log --oneline 을 입력했을 때의 결과 창이다. git log --oneline 이 때, 맨 위의 HEAD -> master, origin/master와 같은 로그의 의미는 뭘까? 간단하게 말..

soy3on.tistory.com

https://blog.lulab.net/programming-tools/the-need-for-a-git-branch-strategy/

Git 브랜치 전략(Git flow, Changes)의 필요

즐겁게 코딩을 하면서 즐기는 공간 '룰루랄라코딩'입니다. 'Git 브랜치 전략(Git flow, Changes)의 필요'을 한 번 살펴보세요.

blog.lulab.net

https://codingtrainee.tistory.com/156

Git Flow와 GitHub Flow의 이해

Git Flow 기본적인 가지의 이름은 아래의 5가지로 구분하곤 한다. feature > develop > release > hotfix > master 위 순서들은 왼쪽으로 갈수록 포괄적인 가지이며 master branch를 병합할 경우 그 왼쪽에 있는 h..

codingtrainee.tistory.com

https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5

Git branch 전략(Git-Flow, Github-Flow, Gitlab-Flow)

Branch란?브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니

velog.io

[Git] Git의 기본 개념과 용어 정리

코_노 — Fri, 7 Oct 2022 08:47:44 +0900

조별 과제를 모두 해본 적이 있을 것이다. 조별 과제를 하다 보면, 발표 자료 PPT나 발표 대본 스크립트 등을 여러 사람이역할 분담하여 작성하면서 최종으로 사용하게 될 자료가 계속 바뀌게 되는데, 이때 어떤 게 가장 최신 버전인지 헷갈린 경험이 분명 있을 것이다!

프로그래밍 코드도 마찬가지다. 프로그래밍 코드는 특히나 이런 발표 자료보다 더더욱 많은 프로젝트 참여자, 각 참여자가 수정하는 사항들이 더더욱 많이 생기게 마련이다. 이번 포스팅에서는 프로그래밍에서 형상관리에 엄청난 도움을 주는 'Git'이라는 툴에 대해 알아보도록 하자!

문서 관리의 중요성 / 출처 : https://backlog.com/git-tutorial/kr/intro/intro1_1.html

1. 'Git'을 왜 써야 할까?

1-1. Git 의 정의

: 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템.

**1-2. *형상 관리를 하는 이유**

* 형상 관리 : 소프트웨어 구성 관리(Software Configuration Management) 또는 형상 관리는 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것으로, 형상 관리는 일반적인 단순 버전관리 기반의 소프트웨어 운용을 좀 더 포괄적인 학술 분야의 형태로 넓히는 근간을 이야기한다.

다음 그림을 살펴보자. 사람 A,B,C,D가 나눠서 협업하여 진행하는 프로젝트 'X'가 있다고 가정해보자.

협업 프로젝트 'X' / 출처 : cupjoo.tistory.com/6

협업하는 프로그래밍 프로젝트를 경험해봤다면 다음과 같은 문제가 충분히 발생할 수 있다는 걸 분명 알 것이다!

A가 맡은 기능을 다 구현했는데, B가 맡은 파트를 아직 완성하지 못해서 B의 완성된 코드를 공유받지 못해 다음 단계로 나갈 수가 없는 상황
B가 코드를 완성하고 A의 코드와 합쳤으나, 코드 충돌이 발생하여 심각한 에러가 발생, 애플리케이션이 정상 작동하지 않는 상황. 이로 인해, C와 D는 A와 B의 코드가 완성되어야 진행할 수 있기 때문에 하염없이 기다리는 상황이다.
A와 B의 코드가 완성되어(Code 1) 이제 C가 Code 1에 본인의 기능을 추가한 Code 2를 코딩하고 있는데, 심각한 에러가 발생하여, Code 2의 처음 상황(Code 1)으로 돌아가야 하나, 백업해 둔 사람이 아무도 없는 상황
어찌저찌하여 Code 2까지 완성했고, D가 Code 2에 이은 Code 3 을 작성하는 중에, 호환성 문제를 발견하여 Code 1 부분에서 수정이 필요한 상황인데, 어느 부분에서 수정을 해야 하는 지 알 수 없는 상황

위 상황 하나하나가 모두 협업 프로젝트를 진행해봤다면 알겠지만, 잘못하면 시간만 어마어마하게 잡아먹을 수 있는 아찔한 상황이다. 이러한 상황을 방지하기 위해 협업 프로젝트에서의 형상 관리는 필수이다.

Git은 이러한 형상 관리를 매우 편리하게 도와주는 Tool로서, 분산 버전 관리를 통해 작업 일지 기록이나 협업, 백업 등을 가능하게 해준다. 또한 형상 관리 Tool 들 중 현재로선 점유율이 가장 높은 관계로, 개발자를 하기로 마음 먹었다면 git에 대해 반드시 알아야 한다!

2. Git 의 개념과 용어 정리

Git의 단순한 구조 / 출처 : cupjoo.tistory.com/6

위 그림을 보면, Git의 구조를 대충 파악할 수 있다. 요약하면 이렇다. 최종 소스코드를 저장하고 공유하는 역할인 원격 저장소가 있고, 여기에서 소스코드를 내 로컬 저장소(내 PC)로 받아와서 소스코드를 수정한 후, 다시 원격 저장소로 업로드하는 구조이다. 그럼 이제 Git에서 실제 사용하는 용어를 중심으로 Git이 어떤 기능을 가지고 있는지 살펴보자!

2.1. Git의 저장소의 종류

● Remote Repository (원격 저장소)

: 원격 서버(GitHub)에 저장된 저장소로, 여러 사람이 함께 공유한다.

● Local Repository (로컬 저장소)

: 사용자가 직접 관리하는 저장소로, 내 PC 에 저장되어 있다.

2.2. 프로젝트의 전체 복사

clone 과 fork의 구분

● Clone

: Remote Repository 에서 내 Local Repository로 복사하여 내 PC에 새로운 저장소를 만드는 것.

- Clone 한 원본 Repository(Remote) 를 origin 으로 갖고 있는데, 기본적으로 이 origin에 대한 권한이 없으면, 해당 저장소로 push 할 수 없다.

- Clone을 하게 되면, 내 PC의 지정된 폴더에 .git 이라는 숨겨진 폴더가 생성되고, 이러한 .git 폴더를 가지고 있는 폴더를 '작업 폴더(Working Directory)' 라고 한다. 이 작업 폴더는 자동으로 github의 Remote Repository와 링크가 맺어지게 된다.

● fork

: 다른 사람의 Remote Repository(Github) 에서 내 Remote Repository(Github)으로 복제하는 기능.

- 원본(다른 사람의 Remote Repo)과 연결되어 있으며, 여기서 '연결되어 있다'의 의미는, Original Repository에 어떤 변화가 생기면, forked 된 Repository로 Fetch나 Rebase의 기능을 통해 변동사항을 반영할 수 있다.

- 원본(다른 사람의 Remote Repo)에 내가 수정한 코드를 적용하고 싶으면, 해당 저장소에 PR(Pull Request)를 해야 한다.

이때, 원본의 관리자로부터 승인을 받으면, 내가 수정한 코드가 Commit&Merge 되어, 원본 Repo (다른 사람의 Remote Repo)에 반영된다.

2.3. 내 로컬 Repo 에서의 변경 사항 관리

Stage의 개념 / 출처 : cupjoo.tistory.com/6

※ Stage(Staging)

: 특정 파일이나 코드를 변경한 후 해당 이력을 *Index 에 기록하는 행위.

*Index : commit 을 통해 변경사항들이 반영되기 전, 해당 변경 사항의 이력들이 저장되는 '공간'을 말한다. Staging Area 라고도 한다. commit 되기 이전의 임시 저장소라고 생각하면 된다.

● Add

: 작업 폴더(Working Directory) 는 처음에는 아직 관리 대상(Tracked)이 아니다. Untracked 인 상태는 아무런 히스토리 정보를 가지지 못하는데, 우리가 Git을 사용하는 목적은 이러한 히스토리를 관리하기 위함이다. 따라서 해당 작업 폴더를 관리 대상으로 삼기 위해, add 명령어를 수행해주어야 한다. 처음 add 명령을 수행하면, Index 가 생기고, 이후 모든 수정 사항에 대한 Staging 행위(add 명령을 통해 수행)가 Index 에 저장된다.

● Commit

: Staging 된 파일들을 Local Repository에 등록하는 행위. 스냅샷의 형태로 Local Repository에 저장되며, 하나의 commit 단위로 해당 파일을 롤백할 수도 있고, 미래(?) (더 이후 시점의 commit)로 갈 수도 있다.

2.4. Local Repository -> Remote Repository 변경사항 반영하기

● Push

: 현재 내 로컬 저장소에서 작업한 변경 사항들을 원격 저장소에 반영하는 것을 말한다.

- 로컬 저장소의 commit 된 모든 내용 그대로 원격 저장소에 올린다.

- 대부분 commit 직후에 수행하여 원격 저장소에 곧바로 변경사항을 적용시킬 때 사용하며, push가 완료되면, 로컬 저장소와 원격 저장소의 소스코드 내용이 동일하게 된다.

● Merge

: 두 개 이상의 개발 히스토리(branch) 를 하나로 합치는 작업을 의미한다.

- merge를 하게 되면, 각각의 개발자가 작업한 히스토리가 모두 보존(Preserved) 된다는 특징이 있다.

● Rebase

: branch 의 base 를 재설정하여 다시 커밋을 재적용하는 작업을 의미한다.

Git Rebase 개념

Git Rebase 예시 / 출처 : devowen.com/430

- git rebase master feature-2 는 feature-2 브랜치를 master 브랜치로 리베이스 한다는 의미로, master 브랜치의 가장 최근 commit 뒤로 feature-2 브랜치의 commit들이 붙게 된다. 이때 엄밀히 말하면, feature-2의 commit들은 rebase 되면서, 아예 다른 commit이 되는 것이므로, C5*, C6* 로 표기하는 것이 맞다.

- 각 branch들은 해당 branch의 최초 히스토리가 되는 base 지점을 가지고 있는데, 이러한 base 지점을 새로운 브랜치로 갱신하여, 히스토리를 하나로 통합하기 위해 사용한다.

- Rebase 는 충돌을 유발할 수 있어, 아래의 원칙을 지키는 것이 바람직하다.

원격 저장소에 올라간 커밋은 리베이스 하지 말 것.
rebase 전에 rebase 하려는 브랜치 끝에서 백업 브랜치를 만들어 놓을 것.
큰 규모의 팀에서는 되도록 merge를 할 것.

2.5. Remote Repository -> Local Repository 로 변경사항 가져오기

● Pull

: 원격 저장소에 있는 변경사항들을 로컬 저장소로 가져와 소스코드를 병합(Merge)하는 명령어.

- Fetch + Merge 의 개념으로 보면 된다.

- 일단 한 번은 원격 저장소와 링크가 맺어져 있어야(Clone 또는 Fork 이후) 실행 가능한 명령어이다.

● Fetch

: 원격 저장소에 있는 변경 사항들을 로컬 저장소에 병합하기 전, 해당 변경 내용들을 확인만 하려고 할 때 사용하는 명령어.

- 로컬 저장소로 변경된 소스코드 내용을 가져오지는 않음 (코드 합치려면 Merge가 필요함.)

- 원격 저장소의 최신 commit 이력을 로컬 저장소의 이름 없는 브랜치로서 가져오게 된다. 이 브랜치는 'FETCH_HEAD'의 이름으로 Checkout 도 가능하다.

참고

https://cupjoo.tistory.com/6

Git에 대해 알아보자 1. Git의 개념과 Git Flow

개발을 하다 보면 Git이나 GitHub, GitLab 같은 용어를 상당히 자주 듣게 된다. 오픈소스 프로젝트에 참여하려 했더니 GitHub 아이디를 물어보는 것도 모자라 인턴 지원을 하는데도 GitHub 주소를 알려달

cupjoo.tistory.com

https://ux.stories.pe.kr/182

그림으로 보는 Git의 개념 이해하기

Git은 Svn 이후로 현재 가장 많이 사용되어지는 형상관리 툴입니다. 위키백과를 보면 아래와 같이 정의를 하고 있습니다. 깃(Git /ɡɪt/)은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들

ux.stories.pe.kr

https://wlqmffl0102.github.io/posts/Git-organizing-the-terms/

Git 용어 정리

Git 여담으로 끼워넣겠습니다. 전혀 모르고 하다보면 어느순간 이해하게 됩니다만, 그렇지만 간단한것은 한번씩 짚고 넘어가려고 합니다. 깃 블로그 만들기에는 꼭 필요한 내용은 아닙니다. 넘

wlqmffl0102.github.io

https://backlog.com/git-tutorial/kr/intro/intro1_1.html

누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog

누구나 쉽게 알 수 있는 Git에 입문하신 것을 환영합니다. Git을 사용해 버전 관리를 할 수 있도록 함께 공부해봅시다!

backlog.com

[Java] JVM 실행 옵션 (2) - Non-Standard Options

코_노 — Tue, 4 Oct 2022 13:15:23 +0900

본 포스팅은 java 8 버전 (openjdk 1.8) 을 기준으로 작성한다.

이전 포스팅에 이어, 이번 포스팅에서는 Java HotSpot Virtual Machine 에 특정한 범용 옵션인, Non-Standard Option 들에 대해 살펴보도록 하자! 들어가기에 앞서, Non-Standard Option 의 경우, 모든 옵션 앞에 'X'가 붙는다는 것을 알아두자!

Non-Standard Options

-X

: 사용 가능한 모든 -X 옵션(Non-Standard Option)에 대해 도움말을 출력한다.

-Xbatch

: JVM은 디폴트로 백그라운드 작업으로 컴파일하고, 백그라운드 컴파일이 끝날때까지 메소드를 인터프리터 모드에서 동작하게 되는데, 이 옵션을 사용하면 백그라운드 컴파일을 Disable 하게 된다. 이렇게 함으로써, 모든 메서드들은 동작이 완료될때까지 포그라운드(foreground) 방식으로 동작하게 된다.

이는 Advanced JIT Compiler Option의 '-XX:-BackgroundCompilation' 과 같은 효과이다.

-Xbootclasspath:path

: 부트 클래스 파일을 검색할 디렉토리, JAR 파일, ZIP 아카이브를 ':'(colon, 콜론) 으로 구분하여 지정하는 옵션.

이렇게 지정한 파일들은 jvm이 실행될 때 JDK에 포함된 부트 클래스 파일을 대신하여 실행되도록 한다. 단, 이 옵션을 사용하여 rt.jar 안에 있는 클래스를 재정의(Overriding) 하는 애플리케이션을 배포하여서는 안된다. 이는 JRE 바이너리 코드 라이센스에 위반된는 행위이다.

-Xbootclasspath/a:path

: 'Xbootclasspath:path' 옵션과 동일한데, 지정한 경로 앞에 'a'를 붙이므로써, 해당 경로는 디폴트 부트스트랩 클래스 경로의 하위 경로로 지정되어 부트 클래스 파일을 검색하는 옵션이다.

-Xbootclasspath/p:path

: 'Xbootclasspath:path' 옵션과 동일한데, 지정한 경로 앞에 'p'를 붙이므로써, 해당 경로는 디폴트 부트스트랩 클래스 경로의 상위 경로로 지정되어 부트 클래스 파일을 검색하는 옵션이다.

-Xcheck:jni

: *JNI(Java Native Interface) 기능에 대한 추가 검사를 수행하는 옵션. JNI 요청을 처리하기 전, JNI 함수와 런타임 환경 데이터에 전달된 매개 변수를 확인한다. 만약 잘못된 결과 데이터가 나온다면 이는 네이티브 코드에 문제가 있음을 나타내며, 이러한 경우 복구할 수 없는 에러와 함께 JVM을 종료하게 된다.

*JNI(Java Native Inteface) : JVM 위에서 실행되고 있는 java 코드가 네이티브 응용 프로그램(하드웨어 및 OS 플랫폼에 종속된 프로그램 등), C, C++, 어셈블리 같은 java 와는 다른 언어로 작성된 라이브러리들을 호출하거나 반대로 호출되는 것을 가능케 하는 프로그래밍 프레임워크를 말한다.

이는 일부 하드웨어를 처리해야 하거나, 매우 까다로운 프로세스의 성능 향상을 요하거나, 타 언어로 작성된 기존의 라이브러리를 java로 재작성하려고 할 때 사용하는데, 이를 달성하기 위해 JDK에서는 JVM 에서 실행되는 바이트코드(.java 파일이 컴파일 된 .class파일)와 기본코드(.java 파일) 사이에 브릿지를 도입해야 하는데 이 브릿지 역할을 JNI가 하게 된다.

-Xcomp

: 첫 번째 메서드 호출 시, 강제로 컴파일하도록 하는 옵션이다. 원래 JVM에서는 디폴트로, 효율적인 컴파일을 위한 정보 수집을 위해 Client 버전의 경우 1,000개의 인터프리트된 메서드 호출, Server 버전의 경우 10,000개의 인터프리트된 메서드 호출을 수행하는데, 이 옵션을 사용하게 되면 인터프리트된 메서드 호출을 Disable하여, 전체 컴파일의 효율성을 포기하고 컴파일 자체의 퍼포먼스를 높이기 위해 사용된다.

-Xdiag

: 추가적인 진단 메시지를 출력하는 옵션.

-Xfuture

: 클래스 파일 형식 규격을 엄격하게 준수하도록 하는 'strict class-file check'를 Enable 하는 옵션. 미래 릴리즈(?)에서는 strict check가 디폴트로 될 것이므로, 개발자에게는 새로운 코드를 개발할 때 이 옵션을 사용하는 것이 권장된다.

-Xint

: 애플리케이션을 interpreted-only 모드로 작동시킨다. 이렇게 되면, 네이티브 코드로의 컴파일이 disable되며, 모든 바이트코드가 인터프리터에 의해 실행된다. 즉, JIT 컴파일러에 의한 성능 이점이 이 모드에서는 나타나지 않게 된다.

-Xinternalversion

: -version 옵션보다 자세한 JVM 버전 정보를 출력한 후 jvm을 종료하는 옵션.

-Xloggc:filename

: 로깅을 위해 상세 GC 이벤트 정보를 리다이렉션할 파일을 설정하는 옵션. 이때 해당 파일에 기록된 정보는, 기록된 각 이벤트 전 첫번째 GC 이벤트 이후에 경과된 시간으로, -verbose:gc 의 출력 결과와 비슷하다. 따라서 동일한 java 명령어 내에서 -Xloggc 옵션과 -verbose:gc 옵션이 함께 쓰였다면, -Xloggc 옵션으로 재정의 된다.

-Xmaxjitcodesize=size

: JIT-컴파일 코드에 대한 최대 캐시 사이즈(바이트 단위)를 지정하는 옵션. 디폴트 캐시 사이즈는 240 MB 이며, 만약 '-XX:TieredCompilation' 옵션을 사용하여 계층형 컴파일 옵션을 disable 했을 경우, 디폴트 캐시 사이즈는 48 MB 가 된다.

아래와 같이, 킬로바이트면 k/K, 메가바이트면 m/M, 기가바이트면 g/G를 숫자 뒤에 붙여 사용한다.

-Xmaxjitcodesize=240m

'-XX:ReservedCodeCacheSize' 옵션과 동일하게 사용된다.

-Xmixed

: 네이티브 코드로 컴파일 된 hot method를 제외한, 모든 바이트 코드를 인터프리터를 통해 실행하는 옵션.

-Xmnsize

: 힙 메모리의 nursery 영역의 최대 사이즈를 설정하는 옵션.

JVM의 힙 영역은 물리적으로 두 부분으로 나눠지는데, nursery(young generation) 파트와 tenure(old generation) 파트이다.

여기서 nursery 파트는 새로운 객체를 할당하기 위해 힙에 확보된 공간으로, nursery 가 가득 차게 되면, young collction 또는 minor GC 라는 가비지 컬렉션이 수행된다. 이 과정 중, 살아있는 객체들만 체크하고 나머지는 다 없애버리게 되는데, 남아있는 객체들 중 어느정도 오래 머물렀던 객체들을 tenure 파트에 이동시켜 nursery의 공간을 다시 한번 확보하게 된다.

nursery 파트의 공간이 너무 작으면, 많은 minor GC 가 발생하게 될 것이고, 공간이 너무 크다면, 완료되는데에 오랜 시간이 걸리는 full GC 만 수행되게 될 것이다. 오라클에서는 전체 힙 사이즈의 25% ~ 50% 만 nursery 파트의 공간으로 잡을 것을 권장한다.

nursery 파트의 최대 사이즈를 256 MB로 설정하는 옵션 예시는 아래와 같다.

-Xmn256m
-Xmn262144k
-Xmn268435456 		# 단위를 표시 안 하면 바이트 단위임.

-Xmssize

: 힙 메모리(nursery 파트 + tenure 파트)의 최소 및 초기 사이즈를 설정하는 옵션.

이 옵션이 지정되지 않았다면, nursery 파트에 대한 초기 힙 사이즈는 '-Xmn' 옵션 또는 '-XX:NewSize' 옵션을 통해 정해진 사이즈로 지정된다.

사용 예시는 '-Xmn' 옵션과 동일하다.

-Xmxsize

: 힙 메모리(nursery 파트 + tenure 파트)의 최대 사이즈를 설정하는 옵션.

JVM Server 모드의 경우, -Xms 와 -Xms 가 동일하게 설정된다.

사용 예시는 '-Xmn' 옵션과 동일하다.

-Xnoclassgc

: 클래스에 대한 GC(Garbage Collection)을 Disable 하는 옵션. GC 타임을 없애므로써, 애플리케이션 구동 간에 interruption 을 단축시킨다. 그러나 메모리 부족에 관한 Exception이 발생할 확률이 매우 높으므로, 주의하여 사용해야 한다.

-Xprof

: 실행 중인 프로그램을 프로파일링하고, 프로파일링 데이터를 표준 출력으로 보내는 옵션. 이 옵션은 프로그램 개발에 유용한 옵션으로, Production 시스템에서는 사용되지 않는다.

-Xrs

: JVM에 의한 OS 신호 사용을 줄이는 옵션. 예를 들면, 기본적으로 JVM은 OS가 종료 중이거나, 사용자 로그아웃 중임을 알리는 신호를 OS에서 포착하여 자체적으로 종료하는데, 이 동작으로 인해 사용자가 OS상에서 로그아웃 할 때 Application Server 서비스까지 종료되는 문제가 발생하게 된다. OS 사용자 로그아웃 여부와 관계없이 Java 애플리케이션이 종료되지 않고 실행되기 위해 해당 옵션을 사용한다.

-Xshare:mode

: *CDS(Class Data Sharing) 모드를 설정하는 옵션. 가능한 'mode' 에 대한 매개변수로는 아래와 같다.

auto : CDS가 가능하다면 사용한다는 옵션. Java HotSpot 32비트 Client의 디폴트 옵션.
on : CDS를 사용해야 하는 옵션으로, CDS가 사용될 수 없다면 에러 메시지를 호출하고 JVM 종료.
off : CDS를 사용하지 않는 옵션. Java HotSpot 32비트 서버, 64비트 서버, 64비트 클라이언트의 디폴트 옵션.
dump : 수동으로 CDS 아카이브를 생성.

* CDS(Class Data Sharing) : JVM 기동 시 성능을 향상하기 위한 목적으로, JVM에서 공통으로 사용하는 클래스들을 공유저장소에 위치시키고 이를 각 JVM 들이 공유하여 사용하는 방식을 제공하는 모드.

-XshowSettings:category

: 설정을 출력하고 JVM 실행을 계속 한다. 'category' 매개변수에 들어갈 수 있는 옵션으로는 다음과 같다.

all : 설정의 모든 카테고리를 출력. 디폴트 옵션이다.
locale : locale과 관련된 설정을 출력.
properties : 시스템 속성과 관련된 설정을 출력.
vm : JVM과 관련된 설정을 출력.

-Xsssize

: 스레드 스택 사이즈를 설정하는 옵션. 아래는 플랫폼별 스레드 스택 사이즈의 디폴트 값을 나타낸다.

Linux/ARM (32비트) : 320 KB
Linux/i386 (32비트) : 320 KB
Linux/x64 (64비트) : 1024 KB
OS X (64비트) : 1024 KB
Oracle Solaris/i386 (32비트) : 320 KB
Oracle Solaris/x64 (64비트) : 1024 KB

-Xusealtsigs

: JVM 인터널 신호에 대한 SIGUSR1, SIGUSR2를 대신하여 대체 신호를 사용하는 옵션.

-Xverify:mode

: 바이트코드 검증자 모드를 설정하는 옵션. 바이트코드 검증은 클래스 파일이 적절하게 형성되었는지, JVM 스펙에 따른 클래스 파일에 대한 제약사항을 잘 따랐는지를 검증한다. 가능한 'mode' 매개변수로는 아래와 같다.

remote : 부트스트랩 클래스 로더에 의해 로드되지 않는 모든 바이트 코드를 검증. 디폴트 옵션이다.
all : 모든 바이트코드를 검증.
none : 모든 바이트 코드에 대한 검증을 Disable

참고

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

java

docs.oracle.com

https://velog.io/@vrooming13/JNI-JAVA-Native-Interface

JNI (JAVA Native Interface)

JNI란? 자바 네이티브 인터페이스는 자바 가상머신(JVM)위에서 실행되고 있는 자바코드가 네이티브 응용 프로그램(하드웨어와 운영 체제 플랫폼에 종속된 프로그램들) 그리고 C, C++ 그리고 어

velog.io

https://shinjekim.github.io/java/2020/01/06/%EC%9E%90%EB%B0%94%EC%9D%98-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EA%B5%AC%EC%A1%B0/

[Java] 자바의 메모리 구조 · Challengist

[Java] 자바의 메모리 구조 06 Jan 2020 | Java 자바의 메모리 구조 자바(JVM)의 메모리 영역은 heap, stack, static이 전부인것으로 알고있었다. 그런데 구글링을 해보니 블로그마다 설명하는 용어가 조금씩

shinjekim.github.io

https://johngrib.github.io/wiki/jvm-memory/

JVM 메모리 구조와 GC

작성중인 문서

johngrib.github.io