📌 Oracle 인라인 뷰(Inline View)와 WITH 구문(CTE) 정리 🚀

SQL에서 서브쿼리를 작성해 임시테이블을 활용방법 중 대표적인 것이 인라인 뷰(Inline View)와 WITH 구문(CTE, Common Table Expression)이야.

1️⃣ 인라인 뷰(Inline View)란?

🔹 개념

인라인 뷰(Inline View)는 FROM 절에서 서브쿼리를 사용하여 생성하는 임시 테이블이야.
즉, SQL 문 내에서 즉석에서 생성된 테이블처럼 동작하는 서브쿼리라고 생각하면 돼.

✅ 인라인 뷰 기본 구조

SELECT 컬럼명
FROM (서브쿼리) AS 별칭;

• FROM 절에서 서브쿼리를 사용하면, 해당 결과가 임시 테이블처럼 동작함.
• Oracle에서는 AS 키워드를 생략 가능하지만, 명확성을 위해 별칭(Alias)은 필수!

✅ 예제: 부서별 IT 부서 직원 조회

SELECT emp_id, name, salary
FROM (SELECT emp_id, name, salary FROM employees WHERE department = 'IT') subquery;

📌 실행 과정:
1️⃣ 서브쿼리 (SELECT emp_id, name, salary FROM employees WHERE department = 'IT') 실행
2️⃣ 그 결과를 subquery라는 임시 테이블로 사용
3️⃣ SELECT emp_id, name, salary FROM subquery; 실행

💡 즉, 서브쿼리는 마치 테이블처럼 동작하며, 원하는 조건을 추가로 적용할 수 있음!

✅ 예제: 인라인 뷰를 활용한 상위 3명의 급여 정보 조회

SELECT *
FROM (
    SELECT emp_id, name, salary 
    FROM employees 
    ORDER BY salary DESC
) subquery
WHERE ROWNUM <= 3;

📌 실행 과정:
1️⃣ 서브쿼리에서 ORDER BY salary DESC로 급여가 높은 순서대로 정렬
2️⃣ ROWNUM <= 3을 적용하여 상위 3명의 직원만 선택

💡 인라인 뷰를 사용하면, 복잡한 쿼리를 간결하게 만들 수 있음!

2️⃣ WITH 구문(CTE, Common Table Expression)이란?

🔹 개념

WITH 구문(CTE, Common Table Expression)은 쿼리 실행 중 일시적으로 사용할 수 있는 가상의 테이블을 정의하는 방식이야.
인라인 뷰와 비슷하지만, 가독성과 성능 면에서 더 유리한 경우가 많아.

✅ WITH 구문의 기본 구조

WITH 임시테이블명 AS (
    서브쿼리
)
SELECT 컬럼명 FROM 임시테이블명;

• WITH 절에서 서브쿼리를 정의하고, 해당 결과를 임시 테이블처럼 사용 가능
• 여러 개의 서브쿼리를 정의할 수도 있음!

✅ 예제: WITH 구문을 활용한 부서별 평균 급여보다 높은 직원 조회

WITH DeptAvg AS (
    SELECT department, AVG(salary) AS avg_salary
    FROM employees
    GROUP BY department
)
SELECT e.emp_id, e.name, e.salary, d.avg_salary
FROM employees e
JOIN DeptAvg d
ON e.department = d.department
WHERE e.salary > d.avg_salary;

📌 실행 과정:
1️⃣ WITH DeptAvg AS (...)에서 부서별 평균 급여를 계산하여 임시 테이블 생성
2️⃣ DeptAvg를 employees 테이블과 조인
3️⃣ 각 직원의 급여가 부서 평균보다 높은 직원만 필터링

💡 CTE는 동일한 서브쿼리를 여러 번 사용해야 할 때 더 효과적임!

3️⃣ 인라인 뷰 vs WITH 구문 비교

💡 즉, 인라인 뷰는 간단한 서브쿼리에 적합하고, WITH 구문(CTE)은 복잡한 쿼리를 깔끔하게 정리하는 데 유용함!

4️⃣ WITH RECURSIVE (재귀 CTE)

🔹 WITH RECURSIVE는 자기 자신을 참조하여 반복적으로 데이터를 생성할 때 사용돼! 🔹 일반적인 계층형 데이터(예: 조직도, 카테고리 트리)에서 활용 가능.

✅ 예제: 사원 계층 구조 (상사-부하 관계) 조회

WITH RECURSIVE EmployeeHierarchy AS (
    SELECT emp_id, name, manager_id, 1 AS level
    FROM employees
    WHERE manager_id IS NULL  -- 최고 관리자 (최상위 노드)

    UNION ALL

    SELECT e.emp_id, e.name, e.manager_id, eh.level + 1
    FROM employees e
    JOIN EmployeeHierarchy eh ON e.manager_id = eh.emp_id
)
SELECT * FROM EmployeeHierarchy;

✔ manager_id IS NULL인 직원부터 시작 (최상위 관리자)
✔ UNION ALL을 사용하여 부하 직원들을 재귀적으로 조회
✔ level 컬럼을 활용하여 계층 구조 확인 가능

🔥 결론

✅ 인라인 뷰(Inline View)

• FROM (서브쿼리) 형태로 사용되며, 임시 테이블처럼 동작
• 단순한 서브쿼리 처리에 적합하지만, 가독성이 떨어질 수 있음

✅ WITH 구문(CTE, Common Table Expression)

• WITH 테이블명 AS (서브쿼리) 형태로 사용되며, 가독성이 좋고, 재사용 가능
• 복잡한 SQL, 동일한 서브쿼리 반복 사용 시 유리

✅ WITH RECURSIVE (재귀 CTE)

• 계층 구조(조직도, 카테고리 트리) 데이터를 처리할 때 유용

📌 복잡한 SQL을 작성할 때는 가독성과 성능을 고려하여 적절한 방법을 선택하자! 🚀

1. employees 테이블: 직원 정보를 저장

   컬럼명	데이터 타입	설명
   emp_id	INT	직원 ID
   emp_name	VARCHAR	직원 이름
   dept_id	INT	부서 ID

2. departments 테이블: 부서 정보를 저장

   컬럼명	데이터 타입	설명
   dept_id	INT	부서 ID
   dept_name	VARCHAR	부서 이름

3. salaries 테이블: 급여 정보를 저장

   컬럼명	데이터 타입	설명
   emp_id	INT	직원 ID
   salary	DECIMAL	급여
   salary_date	DATE	급여 지급일

SQL 쿼리 예시

SELECT 
    e.emp_name,        -- 직원 이름
    d.dept_name,       -- 부서 이름
    s.salary           -- 급여
FROM 
    employees e        -- 직원 테이블
JOIN 
    departments d      -- 부서 테이블
    ON e.dept_id = d.dept_id  -- 부서 ID로 조인
JOIN 
    salaries s         -- 급여 테이블
    ON e.emp_id = s.emp_id  -- 직원 ID로 조인
WHERE 
    s.salary_date = (   -- 가장 최근 급여 정보만 선택
        SELECT MAX(salary_date) 
        FROM salaries 
        WHERE emp_id = e.emp_id
    )
ORDER BY 
    e.emp_name;        -- 직원 이름 기준으로 정렬

실행 결과 예시

쿼리 실행 결과로 예상되는 테이블은 다음과 같습니다:

결과 설명:

1. emp_name: 각 직원의 이름
2. dept_name: 각 직원이 소속된 부서 이름
3. salary: 각 직원의 가장 최근 급여

이 예시에서는 employees, departments, salaries 세 테이블을 조인하여 직원 이름, 부서명, 급여 정보를 출력했습니다. 결과는 직원 이름을 기준으로 오름차순으로 정렬되었습니다.

(참고) 서브쿼리 설명

WHERE 
    s.salary_date = (   -- 가장 최근 급여 정보만 선택
        SELECT MAX(salary_date) 
        FROM salaries 
        WHERE emp_id = e.emp_id
    )

에선 select가 employee 테이블의 행 개수만큼 실행되고, 한 번에 하나의 행만 반환한다. 이렇듯 한 번에 하나의 행만 반환하는 서브쿼리를 스칼라 서브쿼리 라고한다. 따라서 employee의 행이 많으면 성능적으로 부담이 될 수 있어 서 group by와 join을 사용해 아래와 같이 수행하는 것이 더 효과적이다.

SELECT e.emp_id, e.emp_name, d.dept_name, s.salary
FROM employees e
JOIN departments d ON e.dept_id = d.dept_id
JOIN salaries s ON e.emp_id = s.emp_id
JOIN (
    SELECT emp_id, MAX(salary_date) AS max_date
    FROM salaries
    GROUP BY emp_id
) latest_salary ON s.emp_id = latest_salary.emp_id AND s.salary_date = latest_salary.max_date;

SQL에서 ROLLUP과 CUBE는 그룹별로 다양한 수준의 집계 데이터를 생성할 때 유용한 함수다.
둘 다 GROUP BY 절과 함께 사용되며, 계층적인 집계를 만들 수 있다.
하지만 두 함수의 동작 방식에는 차이가 있다.

이번 글에서는 ROLLUP과 CUBE의 개념을 예제와 함께 쉽게 설명해보겠다.

🔹 ROLLUP과 CUBE의 개념

✅ ROLLUP이란?

• 위에서 아래로 계층적인 집계 값을 생성한다.
• GROUP BY에서 지정한 가장 마지막 컬럼부터 단계적으로 그룹을 제거하면서 집계를 수행한다.

✅ CUBE란?

• 가능한 모든 조합의 그룹을 생성하여 집계를 수행한다.
• ROLLUP보다 더 많은 집계 데이터를 생성한다.
• 다차원 분석(OLAP)에서 많이 사용된다.

🔹 ROLLUP 예제

📌 예제 데이터 (sales 테이블)

이제 region, product, month별로 매출을 집계하려고 한다.

SELECT region, product, month, SUM(sales) AS total_sales
FROM sales
GROUP BY ROLLUP(region, product, month);

🔹 결과

✅ ROLLUP(region, product, month)의 동작 방식

1️⃣ region, product, month별 총 매출
2️⃣ region, product별 총 매출 (month 값이 NULL)
3️⃣ region별 총 매출 (product와 month 값이 NULL)
4️⃣ 전체 총합 (region, product, month 모두 NULL)

✔ 특징: ROLLUP은 계층적인 집계를 생성하며, 마지막 단계에서 전체 합계를 구한다.

🔹 CUBE 예제

같은 데이터를 CUBE로 그룹화하면 어떻게 될까?

SELECT region, product, month, SUM(sales) AS total_sales
FROM sales
GROUP BY CUBE(region, product, month);

🔹 결과

✅ CUBE(region, product, month)의 동작 방식

1️⃣ region, product, month별 총 매출
2️⃣ region, product별 총 매출
3️⃣ region, month별 총 매출
4️⃣ product, month별 총 매출
5️⃣ region별 총 매출
6️⃣ product별 총 매출
7️⃣ month별 총 매출
8️⃣ 전체 총합

✔ 특징: CUBE는 모든 가능한 조합을 만들어서 집계한다.

🔹 ROLLUP vs CUBE 차이 비교

✔ ROLLUP은 계층적인 집계만 포함하지만,
✔ CUBE는 모든 조합을 고려한 다차원 집계를 수행한다.

🔹 언제 사용하면 좋을까?

✅ ROLLUP을 사용할 때

• 계층적 데이터 분석이 필요할 때
• 예) 년 → 분기 → 월 단위로 매출 분석할 때

✅ CUBE를 사용할 때

• 다차원 데이터 분석(OLAP)이 필요할 때
• 예) 제품별 / 지역별 / 전체 매출을 한 번에 분석하고 싶을 때

🔹 정리

✔ ROLLUP: 계층적인 집계를 생성 (특정 기준으로 단계적으로 그룹화)
✔ CUBE: 가능한 모든 조합의 집계를 생성 (더 많은 데이터 제공)
✔ ROLLUP은 한 방향의 그룹화, CUBE는 모든 방향의 그룹화

데이터 분석 목적에 따라 적절한 함수를 사용하면 더 효과적인 SQL 쿼리를 작성할 수 있다! 🚀

SQL에서 GROUP BY를 사용할 때, 집계 함수(다중행 함수)를 사용하지 않은 컬럼은 반드시 GROUP BY 절에 포함해야 한다.
그렇지 않으면 오류가 발생한다.

이 개념을 예제와 함께 쉽게 이해해보자.

🔹 문제 상황

다음과 같은 orders 테이블이 있다고 가정하자.

이제 고객별(customer) 총 주문 금액을 구하는 SQL을 작성해보자.

SELECT customer, SUM(price)
FROM orders
GROUP BY customer;

✅ 정상 실행 결과

🔹 GROUP BY에 포함되지 않은 컬럼을 사용할 때 발생하는 오류

만약 product 컬럼을 추가해서 다음과 같이 조회하려 하면 어떻게 될까?

SELECT customer, product, SUM(price)
FROM orders
GROUP BY customer;

❌ 오류 발생!

ERROR: column "orders.product" must appear in the GROUP BY clause or be used in an aggregate function

❓ 왜 오류가 발생할까?

• GROUP BY customer를 했기 때문에 각 고객별(customer)로 한 줄의 결과만 반환해야 한다.
• 그런데 product 컬럼은 그룹화되지 않았으므로, 어떤 값을 출력해야 할지 모호하기 때문이다.

예를 들어, 고객 B의 경우 product 컬럼에는 "Apple"과 "Banana"가 포함되어 있는데, 한 줄로 결과를 만들어야 하므로 어떤 값을 넣어야 할지 알 수 없다.

🔹 해결 방법

이 문제를 해결하는 방법은 크게 두 가지가 있다.

✅ 1) GROUP BY 절에 컬럼을 추가

모든 product별로 그룹을 만들려면 product 컬럼도 GROUP BY에 포함하면 된다.

SELECT customer, product, SUM(price)
FROM orders
GROUP BY customer, product;

🔹 결과

이렇게 하면 고객별 + 상품별로 그룹화되어 각 조합의 합계를 볼 수 있다.

✅ 2) 집계 함수(Aggregate Function) 사용

만약 특정 값을 하나만 선택하고 싶다면 MIN(), MAX(), STRING_AGG() 같은 집계 함수를 사용할 수 있다.

📌 예시 1: 대표적인 상품 하나 선택 (최소값 사용)

SELECT customer, MIN(product), SUM(price)
FROM orders
GROUP BY customer;

🔹 결과

이 방법은 단순히 알파벳 기준으로 가장 앞에 오는 제품을 선택하는 방식이다.
특정 기준에 따라 제품을 선택하려면 문자열을 묶어서 출력하는 방법을 사용할 수도 있다.

📌 예시 2: 고객이 주문한 모든 상품을 출력

SELECT customer, STRING_AGG(product, ', '), SUM(price)
FROM orders
GROUP BY customer;

🔹 결과

이렇게 하면 각 고객이 주문한 모든 상품을 쉼표로 구분하여 출력할 수 있다.

🔹 정리

✔ GROUP BY를 사용하면 그룹 단위로 한 줄씩 결과가 반환된다.
✔ GROUP BY에 포함되지 않은 컬럼은 SELECT에서 단독으로 사용할 수 없다.
✔ 해결 방법은

• GROUP BY 절에 컬럼을 추가하기
• 집계 함수를 사용하여 대표 값을 선택하기

📌 최초 옵션 행사일이란?

최초 옵션 행사일(First Call Date)은 발행자가 최초로 조기 상환(Call Option)을 행사할 수 있는 날짜를 의미해. 즉, 채권의 원래 만기보다 일찍 발행자가 "이제 채권을 상환할게!"라고 선택할 수 있는 최초의 시점이야.

✅ 왜 최초 옵션 행사일이 중요한가?

투자자 입장에서 '사실상 만기일'이 될 가능성이 높음 후순위채권이나 조건부자본증권(CoCo 본드)의 공식 만기는 30년, 50년 또는 무기한일 수도 있음 하지만 대부분의 경우, 최초 옵션 행사일(예: 5년 후)에 조기 상환될 확률이 높음 그래서 투자자들은 이 날짜를 사실상 만기일처럼 생각하는 경우가 많아 발행자는 이자 부담을 줄이기 위해 조기 상환할 가능성이 큼

후순위채권이나 CoCo 본드는 일반 채권보다 금리가 높음 시간이 지나면 회사의 신용등급이 개선되거나, 시장 금리가 낮아질 수도 있음 이 경우, 발행자는 낮은 금리로 새 채권을 발행하고 기존 채권을 조기 상환할 가능성이 높음 따라서 최초 옵션 행사일에 조기 상환이 이뤄지는 경우가 많음 하지만 반드시 상환된다는 보장은 없음

발행자의 재정 상황이 악화되거나, 시장 환경이 좋지 않으면 조기 상환을 안 할 수도 있음 이런 경우 투자자는 예상보다 더 오랜 기간 동안 채권을 보유하게 됨

📌 후순위채권 & CoCo 본드에서 최초 옵션 행사일 예시 💡 예제 1: 후순위채권 (은행 발행) 발행자: K은행 채권 조건: 만기: 30년 최초 옵션 행사일: 5년 후 금리: 연 5.5% (고정금리, 최초 옵션 행사일까지) 가능한 시나리오 5년 후(최초 옵션 행사일)에 K은행이 조기 상환하면, 투자자는 원금과 마지막 이자를 받고 투자 종료 하지만 K은행이 조기 상환을 안 하면, 투자자는 계속해서 채권을 보유하고 이자를 받음 💡 예제 2: CoCo 본드 (조건부자본증권) 발행자: H은행 채권 조건: 만기: 무기한 (Perpetual) 최초 옵션 행사일: 5년 후 금리: 연 6.0% (최초 옵션 행사일까지), 이후 변동금리 가능한 시나리오 5년 후 H은행이 조기 상환하면 투자자는 원금과 이자를 받고 투자 종료 하지만 은행이 조기 상환을 안 하면? 금리가 변동금리로 바뀌고 계속 유지됨 또, 은행이 재무 상태가 악화되면 CoCo 본드가 강제로 상각되거나 주식으로 전환될 위험도 있음 ✅ 정리: 최초 옵션 행사일이 사실상 만기일? ✔ 후순위채권과 CoCo 본드는 공식 만기(30년, 50년, 무기한 등)가 있지만, ✔ 대부분의 경우 최초 옵션 행사일(보통 5년 후)에 발행자가 조기 상환하는 경우가 많음 ✔ 그래서 투자자들은 이 날을 "사실상의 만기일"로 생각하는 경우가 많음 ✔ 하지만 조기 상환이 보장되는 건 아니니 발행자의 재무 상태와 시장 상황을 잘 분석해야 함 🚀

나의 말: 근데 너가 설명해준 후순위채권과 조건부자본증권에는 옵션 구조가 없었는데 옵션이 낀 후순위채권과 조건부자본증권도 있는거야? ChatGPT의 말: ✅ 옵션이 포함된 후순위채권과 조건부자본증권도 있음! 네가 지적한 대로, 기본적인 후순위채권과 조건부자본증권(CoCo 본드)에는 옵션이 포함되지 않을 수도 있지만, 실제로는 콜옵션(Call Option), 스텝업(Step-up), 전환옵션(Convertible) 등 다양한 옵션이 포함된 구조도 많아.

1️⃣ 옵션이 포함된 후순위채권 후순위채권 자체는 일반적으로 콜옵션이 없어도 발행될 수 있지만, 발행자가 조기 상환할 수 있도록 콜옵션(Call Option)이 포함된 형태가 일반적이야.

💡 예시: 콜옵션이 있는 후순위채권 발행자: A은행 채권 조건: 만기: 30년 최초 옵션 행사일(First Call Date): 5년 후 금리: 연 5.0% (최초 옵션 행사일까지 고정), 이후 변동금리 콜옵션(Call Option) 포함: 발행자는 5년 후 조기 상환 가능 📌 옵션의 의미 콜옵션(Call Option):

발행자는 5년 후 최초 옵션 행사일에 채권을 조기 상환할 수 있음 만약 금리가 낮아지거나, 은행이 더 유리한 조건으로 자금을 조달할 수 있다면 조기 상환 가능 하지만 은행의 재무 상태가 악화되거나 시장 상황이 안 좋으면 조기 상환을 안 하고 유지 스텝업(Step-up) 조항이 포함될 수도 있음

만약 5년 후 조기 상환을 안 하면 금리가 올라가는 구조 예: 연 5.0% → 5년 후 조기 상환이 안 되면 연 7.0%로 증가 이렇게 하면 발행자는 가급적 5년 후에 조기 상환을 하려는 유인이 생김 2️⃣ 옵션이 포함된 조건부자본증권(CoCo 본드) 조건부자본증권(CoCo 본드)도 다양한 옵션이 추가될 수 있어. 특히, 전환옵션(Convertible Option)과 콜옵션(Call Option)이 주요한 옵션이야.

💡 예시: 콜옵션과 전환옵션이 포함된 CoCo 본드 발행자: B은행 채권 조건: 만기: 무기한 (Perpetual) 최초 옵션 행사일: 5년 후 금리: 연 6.0% (최초 옵션 행사일까지), 이후 변동금리 콜옵션(Call Option) 포함: 발행자는 5년 후 조기 상환 가능 전환옵션(Convertible Option) 포함: 특정 조건 충족 시 채권이 자동으로 주식으로 전환 📌 옵션의 의미 콜옵션(Call Option):

후순위채권과 마찬가지로, 발행자가 5년 후 조기 상환할 수 있는 권리 만약 금리가 낮아지거나 은행의 재무 상태가 좋아지면 조기 상환 가능 전환옵션(Convertible Option):

발행자가 강제 전환(Forced Conversion)할 수 있는 구조도 있음 예를 들어, 은행의 BIS 자기자본비율(BIS Ratio)이 5% 이하로 떨어지면 채권이 주식으로 전환됨 즉, 투자자가 채권을 계속 보유하는 것이 아니라 은행 주식을 받게 되는 구조 💡 정리: 옵션이 포함된 후순위채권 & CoCo 본드의 핵심 포인트 ✔ 콜옵션(Call Option): 발행자가 조기 상환할 수 있는 권리 ✔ 스텝업(Step-up): 조기 상환을 안 하면 금리가 올라가는 구조 ✔ 전환옵션(Convertible Option): 특정 조건 충족 시 채권이 주식으로 자동 전환됨

📌 투자자 입장에서 주의할 점 ✅ 발행자의 재무 상태를 확인해야 함

발행자가 조기 상환할 수 있을 것 같아 보이지만, 금융위기나 회사 상황이 악화되면 상환을 안 할 수도 있음 특히 CoCo 본드는 은행이 위기에 빠지면 강제로 원금이 상각되거나 주식으로 전환될 위험이 있음 ✅ 최초 옵션 행사일이 "사실상의 만기"일 가능성이 큼

옵션이 포함된 후순위채권과 CoCo 본드는 5년 후 최초 옵션 행사일에 조기 상환될 확률이 높음 하지만 100% 보장되는 것은 아니므로 계약 내용을 잘 확인해야 함 ✅ 스텝업 조항이 있으면 조기 상환 가능성이 더 높아짐

금리가 올라가면 발행자는 추가 이자 부담을 줄이기 위해 조기 상환을 할 가능성이 높아짐 🚀 결론 옵션이 없는 후순위채권과 CoCo 본드도 있지만, 대부분의 경우 콜옵션(Call Option)이 포함됨 CoCo 본드는 전환옵션(Convertible Option) 같은 추가적인 옵션이 들어갈 수도 있음 최초 옵션 행사일에 조기 상환이 예상되지만, 반드시 상환된다는 보장은 없으므로 주의해야 함!

having은 group by 뒤에 group by에 의해 그룹화된 결과에 대해 적용된다. where처럼 개별 행에 적용되는 것이 아니다.

뭔 소리냐..?

예시를 보자.

🎯 부서별 평균 급여가 5000 이상인 부서만 조회하기

SELECT department_id, AVG(salary) AS avg_salary
FROM employees
GROUP BY department_id
HAVING AVG(salary) >= 5000;  -- ✅ 그룹화된 결과 필터링

여기서 HAVING은 부서에 의해 그룹화된 각각 부서그룹에 적용됐다. 이와 같이 having은 대부분 사용시 avg,max,min,sum,count등 그룹함수와 함께 사용된다.(꼭 그룹함수를 써야하는 것은 아니다.)

SQL 실행순서 , select문에서 sql의 실행순서

1.from,join 2.where 3.group by 4.having 5.select 6.order by

call by reference = 변수가 하나 더 생기는 게 아니라 별칭이 하나 더 생길뿐!

#include <iostream>
using namespace std;

void modify(int &x) { // x는 a의 참조
    x = 10; // x를 통해 원래 변수의 값을 변경
}

int main() {
    int a = 5;
    modify(a); // a의 주소가 전달됨
    cout << "a: " << a << endl; // a는 이제 10
    return 0;
}

여기서 modify(a)할 때 x에 a의 참조가 넘어간다 이게 무슨 소리냐? a라는 변수의 메모리 주소가 0x01이라고 하면, x라는 변수는 0x02이런 식의 메모리를 할당 받아서 그 안에 0x01을 넣는 게 아니라, x에는 새로운 메모리 할당이 안 된다. x는 그냥 a의 또다른 이름일 뿐이다. 이게 참조가 넘어간다는 것의 의미다.

class Data {
    int value;
}

class Test {
    static void modifyValue(Data d) {
        d.value = 100; // 객체의 필드값을 변경
    }

    public static void main(String[] args) {
        Data obj = new Data();
        obj.value = 10;

        modifyValue(obj);
        System.out.println("변경된 값: " + obj.value); // 출력: 변경된 값: 100
    }
}

반면 java의 위의 예시코드에서는 d에 새로운 메모리가 할당된다. obj의 주소가 0x01이라고하고 0x01메모리에 저장된 값이 0x02(실제 인스턴스의 주소)라고 하자. modifiyValue(obj)에서는 d라는 변수에 0x03이라는 주소의 메모리가 할당되고 0x03의 메모리에는 obj의 값인 0x02가 전달되어 d는 0x02를 값으로 저장한다. 그렇기에 d.value는 obj.value의 값을 수정한다. 즉, d는 obj의 또다른 이름이 아닌 것이다.

그래서

static void modifyValue(Data d) {
        d = new Data();
        d.value = 100; // 객체의 필드값을 변경
    }

이렇게 코드가 바뀌면 obj.value는 변하지 않는다. 만약 call by reference에 의해 d가 obj의 또다른 이름이었다면 obj의 value는 100으로 바뀌었을 것이다.

JVM(Java Virtual Machine)은 운영체제로부터 메모리를 할당 받는다. 이 할당받은 메모리의 구조에 대한 글이다.

1.Heap 영역

• 실제로 생성된 객체(인스턴스)가 저장되는 영역.
• 런타임시 동적으로 할당한다.(객체가 생성되면 heap영역에 할당)
• 가비지 컬렉션의 대상이다.(Stack영역의 변수가 heap영역의 변수를 더이상 참조하지 않으면 가비지 컬렉션의 대상이 된다.)
• 모든 스레드가 공유한다.

2.Stack 영역

• 자바 프로그램에서 메소드가 호출될 때 메소드의 스택 프레임이 저장된다.
• JVM은 자바 프로그램에서 메소드가 호출되면, 메소드의 호출과 관계되는 지역 변수와 매개변수를 스택 영역에 저장한다
• 객체의 참조값이 저장됨. 실제 객체는 heap에 저장.
• 이렇게 스택영역에 저장되는 메소드 호출정보를 스택 프레임이라고 한다.

3.Method영역(클래스 영역,static영역)

• 자바 프로그램에서 사용되는 클래스에 대한 정보와 함께 static변수가 저장되는 영역이다.
• 클래스 구조, static변수, 상수 등의 정보가 저장됨
• 프로그램 시작 전에 로드되고 프로그램 종료시 소멸된다.

참조: https://www.devkuma.com/docs/jvm/memory-structure/

javac.exe는 컴파일러로, .java로 끝나는 자바 소스코드파일을 바이트 코드(.Class로 끝나는 파일)로 컴파일한다. java.exe는 인터프리터로, 컴파일된 바이트코드를 해석하고 JVM에서 실행한다.

Elastic file system의 약자, EBS와는 다르게 여러 ec2에 연결가능하다.

EFS의 특징

EFS에 접근하기 위해서는 보안그룹을 거쳐야 한다. Linux기반의 AMI만 호환가능 NFSv4.I 프로토콜 사용 미리 용량을 설정할 필요 없이 쓰는만큼 확장되고 그에 따라 과금된다.

EFS Storage class

EFS 저장소의 클래스도 얼마나 자주 사용하는지에 따라 구분된다. 일정기간 동안 사용하지 않으면 하위 저장소로 내려보낸다. 하위 저장소일수록 보관비용은 싸고 접근비용은 비싸다.

특별한 타입의 ec2 instance로, ec2 instance에 연결된 하드웨어의 IO성능이 매우 좋다. 따라서 버퍼나 캐시 같은 일시적인 스토리지로 좋다. 단, ec2를 stop했을 때 데이터가 날아가기 때문에 장기적인 스토리지로 적합하지 않다. 장기적인 스토리지는 ebs를 사용하자.

Amazon Machine Image의 약자로, EC2를 시작하기 위한 기본 세팅의 모음이다.( EC2를 시작하기 위해 OS, 아키텍쳐 타입, 저장공간 용량등을 세팅해놓은 것)

참고: https://velog.io/@ghldjfldj/AWS-AMI%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

AMI 생성, AMI를 이용한 EC2 생성 실습

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/lecture/39476798#content

데이터를 블록단위로 저장하는 스토리지다. (파일 단위가 아니라 블록 단위로 다루서 I/O가 빠르다.), ec2 생성시 자동으로 EBS 볼륨 하나가 ec2에 연결된다.

EBS 볼륨의 특징

특정 EC2에 연결할 수 있다. 특정 가용영역(avaliability zone)에 종속된다. 원칙적으로 하나의 EBS볼륨이 두 개 이상의 ec2에 연결될 수는 없다. (io1과 io2 종류의 볼륨에서는 다중 연결 설정을 하면 가능하긴 하고, 최대 16개 인스턴스에 연결할 수 있다.) EC2 삭제 시 EBS볼륨도 자동삭제되게할 것인지 설정할 수 있다.

볼륨 생성,ec2에 연결, 탈착, 삭제

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/lecture/29388800?start=15#overview

EBS snapshot

특정 시점에서 EBS 볼륨의 상태를 백업해놓은 것 snapshot 작업 시 ec2에서 분리한 뒤 하는 것이 권장됨. 다른 가용영역으로 스냅샷을 전달하는 것도 가능함. 스냅샷 archive에 스냅샷을 저장하면 75프로 할인 받을 수 있고, 대신 스냅샷을 복구하는데 1일~3일 정도 걸림

스냅샷 생성, 아키이브 저장, 스냅샷을 이용한 ebs 볼륨 생성 등 실습 https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/lecture/39476796?start=45#content

볼륨과 스냅샷에 암호화를 걸어주는 실습 https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/lecture/29388816#content

검색을 빠르게 하기 위한 자료구조, 컬럼의 값을 사용하여 항상 정렬된 상태를 유지 (예를 들어, employee 테이블이 있다면 department가 index가 될 수 있다.)

DB의 index의 자료구조

MYsql innoDB에서는 B+tree같은 변형 B-tree로 이루어져 있다.

참고: https://velog.io/@chanyoung1998/B%ED%8A%B8%EB%A6%AC (B트리)

Index를 이용한 검색

1. secondary index를 이용해 데이터의 PK를 찾음
2. PK를 이용해 row를 찾음

의 구조.

아래는 B+트리를 이용해 secondary index(07, 사진에서 key = index, 실제 DB에서는 department등 컬럼값)를 통해 데이터의 PK(AH, 실제 DB에선 ID 등 Primary key)를 찾는 1번 과정이다. 이를 통해 PK를 찾으면 PK를 가지고 다시 한 번 B+트리를 이용해 데이터를 찾는다

Index를 이용한 검색의 장점

만약 index를 이용하지 않으면 테이블을 처음부터 끝까지 다 뒤져야한다 -> 디스크 IO작업이 훨씬 늘어나 성능저하가 발생

Index를 이용한 검색의 단점

인덱스를 관리하기 위해 DB의 약 10%에 해당하는 저장공간이 필요하다. 인덱스를 관리하기 위해 추가 작업이 필요하다.(index 업데이트,삭제 등) 인덱스를 잘못 사용할 경우 오히려 성능이 저하되는 역효과가 발생할 수 있다. (만약 테이블의 25퍼센트 이상의 데이터 조회시 인덱스를 이용하지 않는 것이 효율적이다.)

출처: https://mangkyu.tistory.com/96 [MangKyu's Diary:티스토리]

참고: https://mangkyu.tistory.com/96

ec2 인스턴스를 잠자기 모드로 만드는 것. OS를 종료하지 않고 RAM에 있는 데이터를 EBS에 저장해놓는다. 그래서 부팅시 엄청 빠르다. (stop, terminate보다 약한 '절전모드'라고 생각하면 된다// ebs는 AWS에서 할당해준 하드디스크라고 생각하면 된다.)

참고: https://velog.io/@whddms310/EC2-Hibernate%EB%9E%80 (hibernate) https://velog.io/@ghldjfldj/AWS-EBSAMISG (EBS)

EC2 hibernate 설정

EC2 생성 시 고급 세부 정보 - 최대 절전 중지 방식을 활성화 해줘야한다. 그리고 EBS의 암호화를 활성화 시켜줘야하고, RAM의 데이터를 백업할 EBS의 크기가 충분한지 확인해줘야한다.

1. 최대 절전 중지(hibernate)방식 활성화

2.EBS 암호화 활성화

3. EBS 크기 확인

위에서 EBS 볼륨이 8기가인데 나는 t2.micro를 사용했고 t2.micro의 ram은 1기가이므로 충분하다.

4. 인스턴스 hibernate 시키기

인스턴스 상태 - 인스턴스 최대 절전 모드 클릭

ec2에 붙는 가상의 랜카드라고 보면된다. (랜카드: 컴퓨터를 네트워크에 연결하는 역할을 하는 부품), 그래서 ec2를 서브넷에 연결해주는 역할을 한다. (원래 ec2는 서브넷 안에 있는거 아닌가?란 생각이 들었는데 사실은 ENI가 서브넷 안에 있고 이걸 통해 서브넷에 ec2를 연결해주는 거더라)

ENI는 하나의 사설 IP를 가지고 하나의 공용IP도 가질 수 있다.(공용 IP는 선택), ENI는 하나의 가용영역에 바인딩된다.

참고: https://jibinary.tistory.com/133

이게 왜 필요하냐?

** 장애대응에 좋다. 사실 **IP주소는 EC2가 아니라 ENI가 가지고있다. 따라서, 100이라는 IP주소에 연결된 서버 EC2 instance에 문제가 생기면 100이란 주소를 갖고있는 ENI를 예비 서버 EC2 instance로 옯기면 네트워크와 IP주소 설정을 변경하지 않아도 클라이언트는 서버에 정상적으로 접근할 수 있다.

ENI 생성과 EC2 instance에 연결

ec2생성시 하나의 ENI는 자동으로 생성되어 ec2에 연결된다. 그리고 이 ENI는 ec2가 삭제되면 같이 삭제된다. 이제는 수동으로 ENI를 하나 만들어서 ec2에 연결하는 방법을 알아보자.

EC2에 들어가서 좌측의 사이드바에서 네트워크 및 보안 - 네트워크 인터페이스에 들어가준다.

이 화면이 나오면 네트워크 인터페이스 생성을 눌러준다.

연결할 ec2가 있는 서브넷을 골라주고 description에 원하는 이름이나 설명을 적고

보안 그룹은 연결할 ec2가 있는 보안그룹을 골라주고 생성버튼을 눌러준다.

생성이 완료됐으면 우측 상단의 작업-연결을 눌러서

연결할 ec2가 있는 VPC를 눌러주고 연결할 instance를 택하고 연결버튼을 눌러준다.

EC2와 ENI를 연결해제하는 방법

네트워크 및 보안 - 네트워크 인터페이스에 들어가서 해당 ENI를 선택 후 우측 상단 작업-분리를 눌러준다.

EC2 인스턴스가 어떻게 AWS 인프라에 배치되는지를 제어하는 방식

1.cluster

모든 ec2 인스턴스가 동일한 가용영역(availability zone)에 있음 네트워크가 빨라서 계산작업에 유리함, 다만 가용영역에 문제가 생기면 모든 인스턴스가 장애를 겪음

2.분산배치그룹(spread)

ec2 인스턴스들이 다른 하드웨어에 분산되어 있는 방식, 따라서 다른 가용영역에 ec2인스턴스들이 존재할 가능성이 높다. (ex, ec2_1은 가용영역1의 1번하드웨어에, ec2_2는 가용영역1의 2번 하드웨어에, ec2_3은 가용영역3의 1번 하드웨어에 배치) -> 하드웨어 하나에 문제가 생겨도 다른 ec2 인스턴스들은 안전함. 다만, 가용영역당 7개의 인스턴스로 제한됨 따라서, 적당한 크기의 애플리케이션인데 인스턴스의 오류를 격리해야하는 경우에 적합함(하나의 인스턴스에서 오류난다고 서비스가 다운되면 안 되는 경우)

3.분할배치그룹(parition)

가용영역당 최대 7개의 파티션이 있을 수 있음, 각 파티션에 여러 개의 ec2 인스턴스 배치, 각 파티션은 AWS의 랙을 나타냄. 최대 수백개의 ec2 인스턴스를 얻을 수 있음. 각 파티션은 다른 파티션의 실패로부터 격리됨

cf) 랙(rack), 이렇게 수직으로 쌓은 하드웨어를 하나의 랙이라고 한다.

배치그룹 만들기

좌측하단의 배치 그룹 선택해서 들어가면 우측 상단에 배치그룹 생성이라고 보인다. 거기서 배치그룹 생성할 수 있고 어떤 방식의 배치그룹 만들건지 결정가능.

인스턴스 배치그룹에 할당

위의 사진에서 인스턴스 시작 누르고 '고급세부정보' 가며 만들어진 배치그룹 중에서 인스턴스를 할당받을 그룹을 선택할 수 있다.

쓴만큼 낸다. 그래서 비쌈

Reserved

기간을 정해 대여받고 할인받는다

Saving plans

'기간을 정해놓고 그 기간동안 시간당 얼마 내겠다' 이런 식으로 가격을 정하고 할인 받는데, 정해진 용량보다 더쓰면 On-demand요금 적용됨

Spot Instance

On-demand에 비해 가격이 가장 저렴함. 최대가격을 정해서 지불하는데 현재 EC2의 가격이 최대가격을 넘으면(이렇게 지불하겠다는 유저가 있으면 이렇게 됨, 일종의 경매임)인스턴스가 손실될 수 있음(AWS가 자원 회수할 수 있음) 그래서 인스턴스가 손실에 대한 회복력이 있으면 사용해볼만함(ex, 배치작업,이미지 프로세싱 등) DB같이 손실이 나면 안 되는 목적으로는 절대 쓰면 안 됨.

Dedicated Host

물리적 서버를 대여받음, 어떤 법규를 준수해야하거나 할 떄 많이 사용함, 요금제는 아니고 하나의 옵션인데, 요금제는 On-demand로 할 수도 있고 Reserved로 할 수도 있음

Dedicated Instance

전용 하드웨어가 대여되고 그 위에서 돌아가는 인스턴스, 같은 계정 내의 다른 인스턴스와 하드웨어를 공유할 수 있음

spot fleet과 spot instance (aws 시험에 자주 나옴)

• 스팟요청: 인스턴스 수,사양 등을 정해서 aws에 요청
• 스팟요청에는 ** 일회성 요청 과 **영구요청이 있는데, 일회성 요청은 요청의 유효기간이 딱 한 번 요청시에만 유효한거고 영구요청은 유효기간이 영구적인거다.
• 스팟요청을 취소하는 건 스팟 인스턴스를 종료하지 않는다.
• 영구 요청으로 스팟요청을 했을 경우, 인스턴스를 종료하기 전에 ** 스팟요청 취소부터 먼저 **해야한다. 안 그러면 인스턴스를 종료하고나서 아직 살아있는 유효한 스팟요청을 aws가 보고 인스턴스를 다시 실행시킬 수 있다.
• 스팟플릿: 스팟 인스턴스 세트를 정의하는 방법, set of spot instances + (optional)on demand instances로 구성됨.
• 스팟플릿은 요금제약하에서 가장 적절한 ** 런치 pool **을 알아서 선택한다. cf) 런치풀: OS,인스턴스 타입, Availiability Zone 등 다양한 옵션
• 런치 풀이 제약된 요금을 넘거나 용량을 넘으면 instance를 시작하는 것을 종료한다.

시험에 가장 자주 나오는 spot fleet의 인스턴스 할당 전략

• LowestPrice: 가격이 가장 싼 런치풀을 고른다.

• Diversified: 인스턴스들이 모든 풀에 분산되게 한다.
• capacityOptimized: 인스턴스 수에 맞는 최적의 용량을 가진 pool을 선택
• priceCapacityOptimzed: 사용가능한 용량이 가장 큰 풀을 먼저 선택하고, 이 풀들에서 가장 가격이 낮은 풀을 선택한다.

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/learn/lecture/29388768#overview 강의내용요약

EC2에는 IAM 역할을 부여해야지 Configure에서 Access키, Secret Access키 등 자격증명정보를 부여하면 안된다(보안상 심각한 문제가 생긴다, Access키가 Ec2에 속하면 Ec2에 접속하면 Access키가 탈취될 수 있다. 사실 무슨 말인지 모르겠는데 나중에 알아보자)