▶ 유형

• 맨해튼 거리(Manhattan Distance)는 도시 블록을 따라 이동하는 거리를 계산하는 방식이다.
• 수학에서의 거리 공식이랑은 다른데, |x1 - x2| + |y1 - y2| 로 두 점 사이의 x좌표 차이의 절댓값과 y좌표 차이의 절댓값의 합을 맨해튼 거리라고 부른다.
• 즉 격자형 구조에서의 최단 거리를 구하면 되는 거니까 좌표평면이나 대각선을 고려하지않는 상황에서 유용한 수식이라고 생각하면 된다.
• 근데 이걸 여러 점들 사이에서 맨해튼 거리 최소 합을 구하려면 중앙값을 선택하면 된다.

▶ 전략

1차원, 2차원으로 나눠서 보겠다.

1차원에서 여러 점들로부터의 맨해튼 거리 합이 최소가 되는 지점이 중앙값인 이유를 알아보자.

수평선에 n개의 점 x₁, x₂, ..., xₙ이 있을 때, 거리 합을 생각해본다면 

• p가 어떤 점 xᵢ보다 작으면: -1 기여
• p가 어떤 점 xᵢ보다 크면: +1 기여

라고 볼 수 있다. 그래서 결국 최적값을 찾기 위해서는 기준 점을 중심으로 작은 점들의 개수, 큰 점들의 개수가 같은 지점에 놔야하는데, 이 말은 곧 중앙값이라는 얘기가된다.

다시 말하자면, 수평선에서

중앙값에서 왼쪽으로 이동할 경우 왼쪽 점들과의 거리는 줄지만, 오른쪽 점들과의 거리가 더 많이 증가하고
중앙값에서 오른쪽으로 이동: 오른쪽 점들과의 거리는 줄지만, 왼쪽 점들과의 거리가 더 많이 증가한다.

그래서 중앙값이 이 때 최적점이 되는 것이다!

그럼 2차원으로 가보자

2차원은 수평선이 단순히 2개 있다고 생각하면 된다. 곧 x축과 y축이 독립적으로 존재하고, 각각의 축을 기준으로 1차원 맨해튼 거리 최적점 찾듯 하면 된다.

즉 x좌표의 중앙값과 y좌표의 중앙값이 만나는 점이 전체 최적해라고 생각할 수 있다. 

바로 문제 풀어보자.

https://www.acmicpc.net/problem/18310

1차원 맨해튼 거리 합 최적점을 찾는 문제다.

난 처음에 이렇게 작성했다가 바로 시간초과가 났다.

public static void go() {
    int[] target = new int[n];
    for (int i = 0; i < n; i++) {
        target[i] = point[i];
    }
    Arrays.sort(target);
    int min = Integer.MAX_VALUE;
    int minT = Integer.MAX_VALUE;
    for (int i = 0; i < n; i++) {
        for (int j = 0; j < n; j++) {
            int center = (target[j] + point[i]) / 2;
            int dist = 0;
            for (int k = 0; k < n; k++) {
                int d = Math.abs(point[k] - center);
                dist += d;
            }
            if (min > dist) {
                min = dist;
                minT = center;
            }
            // System.out.println("dist: " + dist + " minT: " + minT + " center: " + center);
            // System.out.println();
        }
    }
}

진짜 완전탐색 방식으로 푼건데 이렇게 하면 보다시피 O(n^3)이다.

n이 20만이라 절대 이렇게 하면 안된다.

수평선 최적점을 생각하며 다시 풀면 아래와 같이 짧은 풀이가 완성된다.

public static void go() {
    Arrays.sort(point);
    System.out.println(point[(n - 1) / 2]);
}

이걸 2차원으로 들고 가면 아래 문제가 된다.

https://www.acmicpc.net/problem/1090

처음에 중앙값이 항상 최적인 이유를 모르고, 주어진 점을 활용해서 거리합을 구했다. 이렇게하면 첫번째 예시에서 0 2 4 6이 나오며 틀린 답만 내놓는다.

그래서 x 축, y 축을 분리해 각 좌표를 떼어내어 조합해야된다.

처음 작성할 때 중앙값 비교를 생각하지 못해서 계속 틀렸다.

public static void go() {
    for (int k = 1; k <= n; k++) {
        // k일때 최소거리합
        int res = Integer.MAX_VALUE;

        for (int i = 0; i < n; i++) {
            for (int j = 0; j < n; j++) {
                int centerX = checker[i][0]; // 원 대상의 X
                int centerY = checker[j][1]; // 비교 대상의 Y

                int[] dist = new int[n];
                for (int p = 0; p < n; p++) {
                    dist[p] = Math.abs(checker[p][0] - centerX) + Math.abs(checker[p][1] - centerY);
                }
//                    System.out.println(Arrays.toString(dist));
                Arrays.sort(dist);

                int sum = 0;
                for (int d = 0; d < k; d++) {
                    sum += dist[d];
                }

                res = Math.min(res, sum);
            }
        }
        sb.append(res).append(" ");
    }
}

원대상의 X좌표, 비교 대상의 Y좌표를 기준으로 해서 맨해튼 거리를 구하며 k 만큼의 합을 계속 만들어가면 되는 문제다. 나는 난이도를 모두 가리고 풀기 때문에 이게 플레라는 걸 알고 좀 놀랐다.

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!

▶ 유형

• 모노톤 스택은 스택의 요소들이 항상 단조 증가하거나 단조 감소하도록 유지되는 특별한 형태의 자료구조다. 그래서 단조 스택이라고도 한다.
• 모노톤 스택의 가장 큰 장점은 특정한 패턴을 가진 다음/이전 원소를 찾는 문제를 선형 시간에 해결할 수 있다는 점인데, 각 원소는 최대 한 번씩만 스택에 들어가고 나오기 때문에 O(n^2)이 될 코드가 O(n)으로 유지된다., 이게 엄청 큰 장점이다.
• 배열에서 각 원소의 다음으로 큰 수 찾기, 히스토그램에서 가장 큰 직사각형 넓이 구하기, 온도가 더 높아지는 날까지 기다려야 하는 일수 계산하기 같은 유형에 적용할 수 있다.

flowchart TD
    Start([시작]) --> Init[스택 초기화]
    Init --> InputCheck{새로운 원소가<br>있는가?}
    
    InputCheck -->|Yes| StackEmpty{스택이<br>비어있는가?}
    InputCheck -->|No| End([종료])
    
    StackEmpty -->|Yes| PushElement[스택에 원소 추가]
    StackEmpty -->|No| CompareTop{스택 top과 비교}
    
    CompareTop -->|조건 위배| PopElement[스택에서<br>top 원소 제거]
    CompareTop -->|조건 만족| PushElement
    
    PopElement --> ProcessPopped[제거된 원소로<br>결과값 계산]
    ProcessPopped --> CompareTop
    
    PushElement --> InputCheck

▶ 전략

오름차순이면 들어가려는 수가 top 보다 작거나 같은 경우 pop을 반복하고 내림차순이면 들어가려는 수가 top 보다 크거나 같은 경우 pop을 반복하면 구현된다.

[2, 1, 4, 3, 5]를 예로 들어보겠다.

먼저 2가 들어온다. 그 다음 1이 들어오는데, 1은 2보다 작으므로 2를 pop하고 1을 push한다. push 전에 top과 비교하는 게 핵심이다.

4는 1보다 크므로 그대로 push하고, 3이 들어와야되는데 3은 4보다 작으니까 4을 pop 하고 3을 push한다. 이런식으로 진행이 되는데, 만약 입력 배열이 [2, 3, 5, 1] 이라면 어떻게 될까?

5까지 담았을 때 1과 비교하면 5가 pop되야한다. 여전히 top이 1보다 크므로 3도 pop, 2도 pop하면 스택이 빈 상태로 1이 push 되는 것이다.

즉 스택에 어떤 값을 넣기 전에 k 이상의 수를 모두 제거하고 k를 넣는 것이다.

https://www.acmicpc.net/problem/1725

얘를 한번 풀어보자.

for (int i = 1; i <= n; i++) {
    // 현재 막대(arr[i])보다 큰 높이의 막대들을 처리
    while (!st1.isEmpty()) {
        if (st1.peek() > arr[i]) {
            long nowVal = st1.pop();     // 현재 처리할 높이
            st2.pop();                   // 해당 높이의 위치도 함께 제거
  
            // 직사각형의 왼쪽 경계 찾기
            int leftIdx = -1;
            if (st2.isEmpty())
                leftIdx = 1;             // 스택이 비었다면 처음부터
            else
                leftIdx = st2.peek() + 1; // 이전 막대 다음 위치부터
            
            // 직사각형의 오른쪽 경계는 현재 위치 직전까지
            int rightIdx = i - 1;
            
            // 넓이 계산
            long width = rightIdx - leftIdx + 1;
            long area = width * nowVal;
            
            max = Math.max(max, area);
        } else {
            break;  // 현재 막대보다 작거나 같은 높이를 만나면 중단
        }
    }
    
    // 현재 막대의 정보를 스택에 추가
    st1.push(arr[i]);
    st2.push(i);
}

메인 로직이다.

입력 값과 top을 비교하는데, top이 더 크면 pop하고, idx를 들고있던 스택도 pop한다.(동기화)

지금 스택에 들어있는 값이 직사각형의 높이가 될 것이고, 인덱스의 차이만큼이 너비가 되는 것이다.

그래서 pop되는 시점의 바로 이전 인덱스가 top이 유지되고있는 인덱스이기 때문에 그걸 너비로 계산하면 끝난다. 물론 이 작업 후에, 아직 스택이 비어있지 않을 수 있기 때문에 스택을 비워주는 작업도 필수다. 근데 이미 탐색을 모두 한 시점이기 때문에, 오른쪽 끝을 n으로 잡고 시작한다.

// 남은 스택 정리
while (!st1.isEmpty()) {
    Long nowVal = st1.pop();
    st2.pop();
    int rightIdx = n; // 오른쪽 끝
    int leftIdx = -1;
    if (st2.isEmpty()) {
        leftIdx = 1;
    } else {
        leftIdx = st2.peek() + 1;
    }
    long width = rightIdx - leftIdx + 1;
    long area = width * nowVal;
    max = Math.max(max, area);
}

이 문제는 단조 증가로 해결했지만, 어떻게 문제에서 단조 증가, 감소를 파악할 수 있을까?

단조증가와 단조감소를 구분하는 핵심은 "요구사항"에 달려있다.
먼저 결과값의 조건을 파악해야한다. 찾는 값이 "더 큰 수"인지 "더 작은 수" 인지 구분해야된다.

• "더 큰 수"를 찾는 경우 → 단조감소 스택 유지
• "더 작은 수"를 찾는 경우 → 단조증가 스택 유지

이렇게 나눌 수 있는데,

https://www.acmicpc.net/problem/2493 
탑 문제를 보면, 이전 스택에 더 큰 수가 수신 기둥이다. 그래서 단조감소 스택을 유지하는 것이다.

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.util.ArrayDeque;
import java.util.Arrays;
import java.util.LinkedList;
import java.util.StringTokenizer;

public class Main {
    public static int[] input;
    public static ArrayDeque<Integer> stack;
    public static ArrayDeque<Integer> idx; // idx
    public static int n;
    public static int[] res;

    public static void main(String[] args) throws Exception {
        // System.setIn(new FileInputStream("res/input.txt"));
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringBuilder sb = new StringBuilder();
        n = Integer.parseInt(br.readLine());
        input = new int[n + 1];
        res = new int[n + 1]; // idx 번 기둥이 수신했음을 기록하려고
        // idx 계산 1부터
        StringTokenizer st = new StringTokenizer(br.readLine(), " ");
        for (int i = 1; i <= n; i++) {
            input[i] = Integer.parseInt(st.nextToken());
        }
        // 입력 끝
        stack = new ArrayDeque<>();
        idx = new ArrayDeque<>();
        go();
        for (int i=1; i<=n; i++){
            sb.append(res[i]).append(" ");
        }
        System.out.println(sb);
    }

    public static void go() {
        for (int i = 1; i <= n; i++) {
            // 단조 감소 스택으로 가면 될 것 같다.
            int now = input[i];
            while (!stack.isEmpty()) {
                if (stack.peek() < now) { // top이 더 작으면 빼야된다
                    stack.pop();
                    idx.pop();
                } else {
                    // 그게 아니라면 수신한 것
                    res[i] = idx.peek();
                    break;
                }
            }
            stack.push(now);
            idx.push(i);
        }
    }
}

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!

오늘 부터 오픈소스 웹 통신 프레임 워크를 만들기 위한 여정을 떠나보려고 한다.

일단 제일 먼저 TCP 통신을 직접 구현해보며, 네트워크 지식을 더 깊게 경험해보는 게 첫번째 목표다.

# TCP

TCP(Transmission Control Protocol)는 인터넷 프로토콜 스위트의 핵심 프로토콜로, 신뢰성 있는 데이터 전송을 보장한다. 신뢰성 있는 데이터 전송이라 하면, 보내고 받았다는 게 확인 된다는 것이다.

연결할 때는 3-way handshake, 연결을 종료할 때는 4-way handshake가 일어난다.

sequenceDiagram
    participant C as Client
    participant S as Server
    
    Note over C,S: 3-Way Handshake (연결 수립)
    C->>S: SYN (seq=x)
    Note right of C: 클라이언트: 연결 요청
    S->>C: SYN + ACK (seq=y, ack=x+1)
    Note left of S: 서버: 요청 수락 & 동기화
    C->>S: ACK (ack=y+1)
    Note right of C: 클라이언트: 연결 확인
    
    Note over C,S: 데이터 전송
    C->>S: Data Transfer
    S->>C: ACK
    S->>C: Data Transfer
    C->>S: ACK
    
    Note over C,S: 4-Way Handshake (연결 종료)
    C->>S: FIN
    Note right of C: 클라이언트: 연결 종료 요청
    S->>C: ACK
    Note left of S: 서버: 종료 요청 확인
    S->>C: FIN
    Note left of S: 서버: 서버도 종료 준비 완료
    C->>S: ACK
    Note right of C: 클라이언트: 종료 확인

3way handshake의 경우에는 연결 시도, 연결 확인 및 승인 요청, 최종 확인 단계로 이루어진다.

SYN을 C-> S로 전달하고, 시퀀스 번호랑 같이 담아서 보낸다. 서버는 SYN과 받은 시퀀스 번호를 가지고, 서버 쪽 시퀀스 번호와 클라이언트 가 준 시퀀스 번호에 +1 해서 ACK으로 보낸다. 만들어진 ACK + 클라이언트 가 준 SYN을 다시 클라이언트에게 보내면 클라이언트 쪽에서 이번에는 서버의 시퀀스 번호에 1을 더해 ACK로 응답해준다. 이게 서버에 도착하면 연결이 성립된다.

4way handshake는 조금 복잡한데 신뢰성이라는 개념을 들고가면 똑같다.

시작은 여전히 클라이언트다. 연결을 종료하겠다고 FIN을 보낸다. 그러면 서버가 요청을 받았음을 알려주는 ACK를 보내고, 서버 자체도 종료하겠다고 FIN을 보낸다. 그러면 클라이언트에서 서버의 종료 응답을 받고 ACK를 다시 서버에 전해주며 연결이 종료된다. 양쪽 모두 더이상 보낼 데이터가 없으니 리소스를 해제해야하는데, 상태확인을 한다음에 끊는 방식으로 안정성을 확보하게 되는 것이다.

시퀀스 번호를 사용하니 순서가 보장되기 때문에, 이점이 UDP 통신과 다른 것이다.

흐름제어도 가능하고, 혼잡 제어도 가능하다. 패킷의 체크섬을 사용해 오류 검출과 손상 패킷 재전송 기능도 있기 때문에 신뢰성 있는 통신이라고 할 수 있게 된다. 

interface TcpServer { // 라이프사이클 관리용 인터페이스
    fun start(port: Int)
    fun stop()
    fun isRunning(): Boolean
}

시작, 종료, 상태확인용 함수를 인터페이스로 만들어 시작했다.

private val isRunning = AtomicBoolean(false)
private var serverSocket: ServerSocket? = null
private val threadPool = Executors.newCachedThreadPool()

소켓 통신의 구현체로는 ServerSocket을 사용할 것이다. AtomicBoolean가 멀티스레트 환경에서 race condition 발생을 방지해준다고 해서 이걸 상태 확인 변수로 만들었다.

그리고 클라이언트 연결을 처리할 쓰레드 풀을 만들어 주면 끝난다.

cacheThreadPool이라 스레드를 생성하고, 60초간 사용되지않는 스레드는 제거해준다.

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>());
}

start부터 구현한다.

override fun start(port: Int) {
    if (isRunning.get()) {
        throw IllegalStateException("Server is already running")
    }

    serverSocket = ServerSocket().apply {
        bind(InetSocketAddress(port), backlog)
    }
    isRunning.set(true)

    threadPool.submit {
        while (isRunning.get()) {
            try {
                val clientSocket = serverSocket?.accept() ?: break
                handleNewConnection(clientSocket)
            } catch (e: Exception) {
                if (isRunning.get()) {
                    e.printStackTrace()
                }
            }
        }
    }
}

private fun handleNewConnection(clientSocket: Socket) {
    threadPool.submit {
        try {
            connectionHandler.handle(clientSocket)
        } catch (e: Exception) {
            e.printStackTrace()
        } finally {
            try {
                clientSocket.close()
            } catch (e: Exception) {
                e.printStackTrace()
            }
        }
    }
}

ServerSocket객체를 할당하는 게 TCP/IP계층에서 LISTEN상태로 진입하는 TCP 연결의 시작점이다. OS가 저기서 받는 port에 대한 TCP 리스너를 생성하고 baklog에는 대기열을 처리할 TCP의 SYN 큐 크기를 지정해준다. 이걸 백프레셔라고 하는 것 같다.

SYN 큐에 완료되지않은 연결요청들이 쌓여있을 예정이다. 

public Socket accept() throws IOException {
    if (isClosed())
        throw new SocketException("Socket is closed");
    if (!isBound())
        throw new SocketException("Socket is not bound yet");
    Socket s = new Socket((SocketImpl) null);
    implAccept(s);
    return s;
}

실행중이라면 계속 요청을 보내고 응답을 받을 수 있다. 이때 `serverSocket?.accept()`부분이 3way handshake가 일어나는 부분이다. accept 자체가 연결완료되었을 때 반환된다.

TCP연결에 성공했다면 그 연결한 소켓에서 통신을 이룬다. 커넥션 핸들러를 구현하기 나름인걸로 해두었는데 일단 단순 에코용으로만 작성했다. TCP이 스트림으로 동작하니까 inputstream, outputstream으로 관리한다.

class EchoConnectionHandler : ConnectionHandler {
    override fun handle(socket: Socket) {
        val input = socket.getInputStream().bufferedReader()
        val output = socket.getOutputStream().bufferedWriter()

        input.lineSequence().forEach { line ->
            output.write("$line\n")
            output.flush()
        }
    }
}

커넥션 메서드에서의 `clientSocket.close()` 는 accept와 반대로 4way handshake를 발동시킨다.

telnet으로 테스트하면, 한글은 깨져서 오지만 일단 입력한게 응답으로 돌아오는 걸 볼 수 있다.

지금 구현해둔건 쓰레드 풀을 사용하긴 했지만 blocking I/O 방식이라 각 연결마다 하나의 스레드를 필요로한다. 커넥션이 열리는 만큼 스레드를 열어야하기 때문에 생성 비용이 1MB 스택 메모리인걸 감안했을 때 매우 비효율적임을 알 수 있다.

# 블로킹, 논블로킹, 동기, 비동기

일단 블로킹 I/O랑 논블로킹 I/O의 차이점을 살펴보자. 매우 헷갈리는 개념들인데, 블로킹/논블로킹과 동기/비동기는 서로 다른 개념인걸 알고 들어가야된다.

블로킹, 논블로킹은 호출 함수가 제어권을 바로 돌려주는 지, 아니면 대기 시키는 지에 대한 차이고, 동기 비동기는 작업완료의 통지 방식 차이를 나타낸다. 그래서 동기는 직접 완료가 됐다고 통지를 해주고, 비동기는 콜백형식으로 통지를 해서 다른 작업을 수행할 수 있게 분리시켜주는 것이다.

예시를 카페로 들어보면 좀 더 이해가 잘 된다. 커피를 주문하는 게 함수를 호출하는 것이라고 가정하겠다.

• 블로킹은 주문 받았으니 카운터에서 커피 기다리라고 시키는 것
• 논블로킹은 진동벨을 주고 기다리라고 하는 것
• 동기는 커피가 나왔을 때 사람이 직접 알려주는 것(알려줄 때 까지 기다려야된다)
• 비동기는 진동벨이 울렸을 때 찾아가라고 하는 것

이렇게 4가지로 정리 하겠다.

위에서 내가 Tcp서버를 구현한 방식은 블로킹 방식이다. 각 커넥션 마다 스레드를 할당해서 호출을 기다린다.

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!

개인적으로 기출문제 300문제보다 이거 하나가 더 어려웠다

전송 중인 데이터에 SSL을 사용하도록 RDS를 구성한다.

전송 중인 데이터를 암호화하기 위해 여러분은 보안소켓계층/전송계층보안(SSL/TLS) 연결을 사용할 수 있습니다. Amazon RDS는 SSL 인증서를 생성하고 인스턴스가 프로비저닝될 때 해당 인증서를 DB 인스턴스에 설치합니다. MySQL의 경우, --ssl_ca 파라미터를 사용하여 MySQL 클라이언트를 실행하여 공용 키를 참조해서 연결을 암호화합니다. SSL을 사용하면 여러분의 애플리케이션과 PostgreSQL DB 인스턴스 간에 PostgreSQL 연결을 암호화할 수 있습니다. 여러분의 PostgreSQL DB 인스턴스에 대한 모든 연결이 SSL을 사용하도록 강제할 수도 있습니다.

Amazon API Gateway, Amazon SQS, Amazon Kinesis

Amazon API 게이트웨이는 토큰 하나가 요청 하나에 해당하는 토큰 버킷 알고리즘을 사용하여 여러분의 API에 대한 요청을 스로틀링합니다. 구체적으로는, API 게이트웨이가 여러분의 계정에 있는 모든 API에 대해 정상 상태(steady-state) 속도 및 요청 제출 버스트에 제한을 설정합니다. 토큰 버킷 알고리즘에서 버스트(burst)는 최대 버킷 크기를 가리킵니다.

Amazon SQS - Amazon Simple Queue Service(SQS)는 여러분이 마이크로서비스, 분산 시스템, 서버리스 애플리케이션을 디커플링하고 스케일링할 수 있게 해주는 완벽히 관리되는 메시지 대기열화 서비스입니다. Amazon SQS는 메시지를 잃거나 레이턴시를 증가시키지 않고 일시적인 볼륨 폭증을 매끄럽게 해주는 버퍼링 능력을 제공합니다.

Amazon Kinesis - Amazon Kinesis는 실시간으로 스트리밍 데이터를 소화, 버퍼링, 처리할 수 있는 완벽히 관리되는 스케일링 가능한 서비스입니다.

게이트웨이 엔드포인트는 지원되는 AWS 서비스를 향하는 트래픽을 위해 여러분의 라우트 테이블에 타깃으로 지정한 게이트웨이입니다. 요청을 스로틀링하거나 버퍼링하는 데 도움이 되지 않습니다.

30일 뒤에 객체를 Amazon S3 One Zone-Infrequent Access(S3 One Zone-IA)로 전환하도록 수명 주기 정책을 설정한다. 

S3 One Zone-IA는 액세스 빈도가 낮지만 필요할 때는 빠른 액세스가 필요한 데이터에 사용합니다. 최소한 3개의 가용 영역(AZ)에 데이터를 저장하는 다른 S3 스토리지 클래스와 달리, S3 One Zone-IA는 하나의 AZ에 데이터를 저장하고 S3 Standard-IA에 비해 비용이 20% 적게 듭니다. S3 One Zone-IA는 액세스 빈도가 낮고 재생성이 가능한 데이터에 대해 낮은 비용 옵션을 원하지만 S3 Standard 또는 S3 Standard-IA의 가용성과 회복성이 필요하지 않은 고객들에게 적합합니다. 최소 보관 기간은 30일이며 그 전에 여러분은 객체를 S3 Standard에서 S3 One Zone-IA로 이전할 수 있습니다. -> 스토리지 클래스 최소 보관 기간은 30일이다!

S3 One Zone-IA는 S3 Standard와 같은 높은 내구성, 빠른 처리 속도, 낮은 레이턴시를 제공하며 GB당 저장 가격 및 GB당 검색 요금이 낮습니다. S3 스토리지 클래스는 객체 수준에서 구성할 수 있고 S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA에 걸쳐 저장된 객체들을 하나의 버킷에 담을 수 있습니다. S3 라이프사이클 정책을 이용하여 애플리케이션 변경 없이 스토리지 클래스들 간에 객체를 자동으로 이전할 수 있습니다.

Amazon GuardDuty를 사용해 S3에 저장된 데이터에 대한 악의적인 시도를 모니터링하고, Amazon Macie를 사용해 S3에 저장된 민감 데이터를 식별한다.

Amazon GuardDuty는 여러분이 AWS 계정, 워크로드, Amazon S3에 저장된 데이터를 연속적으로 모니터링하고 보호할 수 있는 위협 탐지 기능을 제공합니다. GuardDuty는 여러분의 계정에서 생성된 연속적인 메타데이터 스트림 및 AWS CloudTrail 이벤트, Amazon VPC 플로우 로그, DNS 로그에서 발견된 네트워크 활동을 분석합니다. 또한 알려진 악성 IP 주소 및 이상 탐지, 더욱 정확하게 위협을 식별하기 위한 머신러닝 등 통합 위협 인텔리전스를 이용합니다.

Amazon Macie는 머신러닝과 패턴 매칭을 사용하여 Amazon S3에 있는 여러분의 민감한 데이터를 발견하고 보호하는 완벽히 관리되는 데이터 보안 및 데이터 프라이버시 서비스입니다. Macie는 이름, 주소, 신용카드 번호 등의 개인식별가능정보(PII) 등 점점 늘어가는 민감한 데이터 유형 목록을 자동으로 감지합니다. 또한 Amazon S3에 저장된 여러분의 데이터의 데이터 보안과 데이터 프라이버시에 대한 계속적인 가시성을 제공합니다.

Redis AUTH를 사용한다. 

Amazon ElastiCache for Redis는 인터넷 스케일의 실시간 애플리케이션에 밀리 초 미만의 레이턴시를 제공하는 번개처럼 빠른 인메모리 데이터 스토어입니다.

Amazon ElastiCache for Redis는 캐싱, 챗/메시징, 게이밍 리더보드, 지리공간, 머신러닝, 미디어 스트리밍, 대기열, 실시간 분석기, 세션 스토어 등 실시간 트랜잭션 및 분석 프로세싱 활용 사례에 아주 적합합니다.

ElastiCache for Redis는 구성 없이 곧바로 복제, 높은 가용성, 클러스터 샤딩을 제공합니다. ElastiCache는 IAM Auth를 지원하지 않습니다.

Redis 인증 토큰을 사용하면, 클라이언트가 명령을 실행하기 전에 Redis가 토큰(패스워드)을 요구할 수 있도록 해주어 데이터 보안이 개선됩니다.

ElastiCache는 IAM Auth를 지원하지 않음.

KMS는 암호화 실현을 위한 사용자 이름과 패스워드를 지원하지 않음.

보안그룹 = 가상 방화벽

통합 결제가 활성화되지 않았다. 월 사용 요금이 한 번만 청구되도록 모든 AWS 계정을 하나의 통합 결제 조직 밑에 둬야 한다.

다수의 AWS 계정이 있다면 AWS 관리 콘솔 또는 API를 사용하여 각각의 계정에서 개별적으로 구독을 활성화하여 다수의 AWS 계정들을 AWS Shield Advanced에 포함시킬 수 있습니다. AWS 계정들이 모두 하나의 통합 결제에 속해 있는 한, 여러분은 월 요금을 한 번만 결제하게 되며, 모든 AWS 계정과 그 계정들의 모든 리소스를 소유하게 됩니다.

AWS Shield Standard는 추가 비용 없이 모든 AWS 고객에게 자동으로 활성화되고, AWS Shield Advanced는 AWS 외부의 리소스에 대한 보호를 제공함.

Amazon VPC 콘솔 마법사는 다음과 같은 네 가지 구성을 제공합니다.

1. 단일 퍼블릭 서브넷이 있는 VPN - 이 시나리오를 위한 이 구성에는 단일한 퍼블릭 서브넷이 있는 가상 사설 클라우드(VPC)와 인터넷을 통한 통신을 실현하는 인터넷 게이트웨이가 포함됩니다. 블로그나 단순한 웹사이트 같은 싱글 티어 일반용 웹 애플리케이션을 실행해야 할 경우에 이러한 구성을 권장합니다
2. 퍼블릭 및 프라이빗 서브넷이 있는 VPC(NAT) - 이 시나리오를 위한 이 구성에는 퍼블릭 서브넷 하나와 프라이빗 서브넷 하나가 있는 가상 사설 클라우드(VPC)가 포함됩니다. 공개적으로 액세스할 수 없는 백엔드 서버를 유지하는 한편 일반용 웹 애플리케이션을 실행하려는 경우에는 이 시나리오를 권장합니다. 일반적인 예에는 퍼블릭 서브넷에 웹 서버가 있고 프라이빗 서브넷에 데이터베이스 서버가 있는 멀티 티어 웹사이트가 있습니다. 여러분은 보안과 라우팅을 설정하여 웹 서버가 데이터베이스 서버와 통신할 수 있도록 할 수 있습니다.
3. 퍼블릭 및 프라이빗 서브넷이 있는 VPC와 AWS Site-to-Site VPN 액세스 - 이러한 시나리오를 위한 구성에는 퍼블릭 서브넷과 프라이빗 서브넷, 그리고 IPsec VPN 터널을 통해 여러분의 네트워크와의 통신을 실현하는 가상 프라이빗 게이트웨이가 있는 가상 프라이빗 클라우드(VPC)가 포함되어 있습니다. 여러분의 네트워크를 클라우드로 확장하고 또한 여러분의 VPC에서 직접 인터넷에 액세스하려는 경우에 이러한 시나리오를 권장합니다. 이 시나리오를 이용하면 퍼블릭 서브넷에 있는 스케일링 가능한 웹 프론트엔드가 있는 멀티 티어 애플리케이션을 실행하고, IPsec AWS 사이트 간 VPN 연결을 통해 여러분의 네트워크와 연결된 프라이빗 서브넷에 여러분의 데이터를 저장할 수 있습니다.
4. 프라이빗 서브넷만 있고 AWS 사이트 간 VPN 액세스가 있는 VPC - 이러한 시나리오를 위한 구성에는 하나의 프라이빗 서브넷, 그리고 IPsec VPN 터널을 통해 여러분의 네트워크와의 통신을 실현하는 가상 사설 게이트웨이가 있는 가상 사설 클라우드(VPC)가 포함되어 있습니다. 인터넷을 통한 통신을 실현하는 인터넷 게이트웨이는 없습니다. 여러분의 네트워크를 인터넷에 노출시키지 않고 Amazon의 인프라를 이용하여 여러분의 네트워크를 클라우드로 확장하려는 경우에 이러한 시나리오를 권장합니다

Site to Site VPN = IPsec VPN 연결

AWS Site-to-Site VPN은 온프레미스 네트워크(여러분의 회사 데이터센터나 사무실)와 AWS VPC(Virtual Private Cloud) 사이에 안전한 연결을 만드는 서비스. 구성요소 세가지는 아래와 같다.

1. Virtual Private Gateway (VGW)
AWS 쪽에 위치한 VPN 연결의 시작점입니다
VPC에 연결되어 있으며, VPN 트래픽의 진입점 역할을 합니다

2. Customer Gateway (CGW)
여러분의 데이터센터나 사무실 쪽에 있는 장비입니다
물리적인 장비일 수도 있고, 소프트웨어로 구현될 수도 있습니다

3. VPN 터널
두 게이트웨이 사이에 암호화된 연결이 만들어집니다
이중화를 위해 항상 2개의 터널이 생성됩니다
IPsec 프로토콜을 사용하여 데이터를 암호화합니다

Amazon GuardDuty ->VPC Flow Logs, DNS 로그, CloudTrail 이벤트

Amazon GuardDuty는 여러분의 AWS 계정, 워크로드, Amazon S3에 저장된 데이터를 보호하기 위해 악의적인 활동과 무단 행동을 연속적으로 모니터링하는 위협 탐지 서비스입니다. 클라우드를 사용하면 계정과 네트워크 활동의 수집과 집계가 간단하지만 보안팀이 연속적으로 이벤트 로그 데이터를 분석하여 잠재적인 위협을 찾기 위해서는 많은 시간이 소요될 수 있습니다. GuardDuty를 사용하면 이제 AWS에서 경제적으로, 그리고 연속적으로 스마트하게 위협을 탐지할 수 있습니다. 이 서비스는 머신러닝, 이상 탐지, 통합 위협 인텔리전스를 사용하여 잠재적인 위협을 식별하고 우선순위화합니다.

GuardDuty는 AWS CloudTrail 이벤트, Amazon VPC Flow Logs, DNS 로그 같은 다수의 AWS 데이터 소스에 걸쳐 수백억 개의 이벤트를 분석합니다.

AWS 관리 콘솔에서 클릭 몇 번만 하면 배포하거나 유지할 하드웨어나 소프트웨어 없이 GuardDuty를 활성화할 수 있습니다. Amazon EventBridge 이벤트와 통합된 GuardDuty 경보는 액셔너블하며 손쉽게 다수의 계정들을 집계할 수 있고 기존의 이벤트 관리 및 워크플로 시스템에 곧바로 통합할 수 있습니다.

새로운 시작 구성을 만들어 올바른 인스턴스 유형을 사용하도록 설정하고, 오토 스케일링 그룹에서 새로 만든 시작 구성을 사용하도록 수정한다. 기존 시작 구성은 더 이상 필요하지 않으므로 삭제한다.

시작 구성은 오토 스케일링 그룹(ASG)이 EC2 인스턴스를 실행하는 데 사용하는 인스턴스 구성 템플릿입니다. 시작 구성을 생성할 때는 인스턴스에 관한 정보를 명시합니다. Amazon Machine Image(AMI)의 ID, 인스턴스 타입, 키 쌍, 하나 이상의 보안 그룹, 블록 장치 매핑을 포함합니다.

일단 생성된 시작 구성은 변경할 수 없습니다. 올바른 인스턴스 타입을 사용하기 위해 새로운 시작 구성을 생성합니다. 이 새로운 시작 구성을 사용하기 위해 오토 스케일링 그룹을 변경(수정)합니다. 예전의 시작 구성은 더 이상 필요하지 않으므로 삭제합니다.

오토 스케일링 그룹을 이용하여, 사용되는 인스턴스 타입을 직접 변경할 수 없다!! 

VPC 엔드포인트를 사용해 Amazon SQS에 액세스한다.

AWS 고객은 공용 IP를 사용하지 않고, 또한 공용 인터넷을 거치지 않고 VPC 엔드포인트를 사용하여 자신들의 Amazon 가상 사설 클라우드(Amazon VPC)로부터 Amazon Simple Queue Service(Amazon SQS)에 액세스할 수 있습니다. Amazon SQS의 VPC 엔드포인트는 여러분이 사적으로 VPC를 지원되는 AWS 서비스에 연결할 수 있게 해주는 스케일링 가능한 고가용성 기술인 AWS PrivateLink가 지원합니다.

Amazon VPC 엔드포인트는 구성이 간단합니다. 또한 인터넷 게이트웨이, 네트워크 주소 번역(NAT) 인스턴스, VPN 연결 또는 AWS Direct Connect 연결 없이 Amazon SQS에 대한 안정적인 연결성을 제공합니다. VPC 엔드포인트를 사용하면 여러분의 Amazon VPC와 Amazon SQS 대기열 간에 데이터가 Amazon 네트워크 안에서 전송되어 여러분의 인스턴스를 인터넷 트래픽으로부터 보호하는 데 도움이 됩니다.

AWS PrivateLink를 사용하면 데이터가 공용 인터넷에 노출되지 않으므로 클라우드 기반 애플리케이션과 공유되는 데이터의 보안이 간단해집니다. AWS PrivateLink는 Amazon 네트워크에서 안전하게 VPC, AWS 서비스, 온프레미스 애플리케이션 간에 사적 연결성을 제공합니다. AWS PrivateLink를 사용하면 다양한 계정과 VPC 간에 서비스들을 쉽게 연결하여 네트워크 아키텍처가 상당히 단순해집니다.

Amazon Neptune

Amazon Neptune은 긴밀히 연결된 데이터셋들을 이용하는 애플리케이션을 쉽게 구축하고 실행할 수 있게 해주며 완벽히 관리되는 빠르고 안정적인 그래프 데이터베이스 서비스입니다. Amazon Neptune의 핵심은 목적에 맞게 구축된 고성능 그래프 데이터베이스 엔진으로서 수십억 개의 관계를 저장하고 밀리 초 단위의 레이턴시로 그래프를 쿼리할 수 있게 최적화되어 있습니다. Neptune은 추천 엔진, 사기 탐지, 지식 그래프, 약품 발견, 네트워크 보안 등 그래프 활용 사례에 힘을 더해 줍니다.

Amazon Neptune은 읽기 전용 레플리카(read replicas), PITR(Point-In-Time Recovery), Amazon S3에 대한 연속적인 백업, 가용 영역 간 복제 등 가용성이 높습니다. Neptune은 HTTPS 암호화 클라이언트 연결 및 저장 중 암호화(encryption at rest)를 지원하여 매우 안전합니다. Neptune은 완벽히 관리되므로 하드웨어 프로비저닝, 소프트웨어 패칭, 설정, 구성, 백업 등의 데이터베이스 관리 작업을 더 이상 걱정할 필요가 없습니다.

Amazon Neptune은 많은 양의 사용자 프로필 세트와 상호작용을 빠르게 쉽게 처리하여 소셜 네트워킹 애플리케이션을 구축할 수 있습니다. Neptune을 사용하면 빠른 처리 속도의 고도화된 대화형 방식 그래프 쿼리를 사용하여 소셜 기능을 애플리케이션에 추가할 수 있습니다. 예를 들어 여러분이 애플리케이션에 공급되는 소셜 피드를 구축한다면 Neptune을 사용하여 가족의 최신 업데이트, ‘좋아요’를 한 친구들의 업데이트, 가까이 있는 친구들의 최신 업데이트를 보여주는 우선순위화된 결과를 제공할 수 있습니다.

기본적으로 Lambda 함수는 항상 AWS 소유의 VPC에서 동작하기 때문에 공용 인터넷 주소나 공용 AWS API에 접근할 수 있다. Lambda 함수가 VPC를 사용하도록 설정되어 있다면 퍼블릭 서브넷에서 NAT 게이트웨이를 통해 라우팅하여 퍼블릭 리소스에 접근해야 한다.

람다 함수는 항상 AWS가 소유한 VPC로부터 작동합니다. 기본적으로 여러분의 함수는 모든 공용 인터넷 주소에 네트워크 요청을 할 완벽한 능력을 갖습니다. 여기에는 공용 AWS API에 대한 액세스도 포함됩니다. 예를 들어 여러분의 함수는 AWS DynamoDB API와 상호작용하여 기록물을 PutItem하거나 Query할 수 있습니다. 여러분은 프라이빗 서브넷에 있는 사적 리소스와의 상호작용이 필요할 때에만 VPC 액세스를 위한 함수를 활성화해야 합니다. RDS 인스턴스가 좋은 예입니다.

여러분의 함수에 VPC가 활성화되면 여러분의 함수에서 나오는 모든 네트워크 트래픽은 VPC/서브넷의 라우팅 규칙을 따르게 됩니다. 여러분의 함수가 공용 리소스와 상호작용을 해야 한다면 퍼블릭 서브넷의 NAT 게이트웨이를 통한 라우트가 필요할 것입니다.

Lambda 함수가 아주 빠르게 늘어날 수 있기 때문에 동시 실행(Concurrent Executions) 또는 동시 호출과 같은 함수 지표가 예상 임계값을 초과했을 때 팀에게 알려줄 수 있도록 CloudWatch 경보를 배포하는 것이 좋다.

람다 함수는 매우 빠르게 스케일링할 수 있기 때문에 여러분은 동시성이 급증하면 알림을 받을 수 있는 통제장치를 해두어야 합니다. ConcurrentExecutions 또는 Invocations 같은 함수 지표가 여러분의 한계치를 초과하면 여러분의 팀에게 알리는 CloudWatch 알람을 배포하는 것이 좋습니다. 여러분은 매일 비용을 모니터링할 수 있도록 AWS Budget을 생성해야 합니다.

모든 의존성도 하나의 람다 배포 패키지에 패키징됨

둘 이상의 Lambda 함수에서 코드를 재사용할 거라면 코드 재사용이 가능한 Lambda 계층 생성을 고려해야 한다.

 여러분은 람다 함수를 구성하여 레이어 형태로 된 추가적인 코드와 콘텐츠를 가져올 수 있습니다. 레이어는 라이브러리, 커스텀 런타임 또는 기타 의존성이 포함되어 있는 ZIP 아카이브입니다. 레이어를 사용하면 여러분은 배포 패키지에 넣지 않고도 함수에서 라이브러리를 사용할 수 있습니다. 레이어를 사용하면 배포 패키지의 크기를 작게 유지하여 개발이 더 쉬워집니다. 함수는 한 번에 레이어를 5개까지 사용할 수 있습니다.

AWS Database Migration Service를 사용해 데이터베이스에서 Amazon Redshift로 데이터를 복제한다.

AWS 데이터베이스 마이그레이션 서비스를 이용하면 빠르고 안전하게 데이터베이스를 AWS로 마이그레이션할 수 있습니다. 마이그레이션 중에 소스 데이터베이스가 완벽하게 운영되므로 데이터베이스에 의존하는 애플리케이션의 불가동 시간이 최소화됩니다. AWS 데이터베이스 마이그레이션 서비스를 이용하면 높은 가용성을 유지하면서 여러분의 데이터를 계속적(지속적)으로 복제하고, 데이터를 Amazon Redshift 및 Amazon S3로 스트리밍하여 데이터베이스를 페타바이트 규모 데이터 웨어하우스에 통합할 수 있습니다.

Amazon EMR은 Apache Spark, Apache Hive, Apache HBase, Apache Flink, Apache Hudi, Presto 같은 오픈소스 툴을 사용하여 대량의 데이터를 처리하기 위한 업계를 선도하는 Hadoop기반 클라우드 빅데이터 플랫폼이다.

VPN CloudHub

여러분에게 다수의 AWS 사이트 간 VPN 연결이 있다면, AWS VPN CloudHub를 이용하여 사이트 간에 보안 통신을 제공할 수 있습니다. 여러분의 원격 사이트들이 VPC뿐만 아니라 서로 간에 통신할 수 있게 됩니다. 가상 사설 게이트웨이에 대한 AWS Direct Connect 연결을 사용하는 사이트들도 AWS VPN CloudHub의 일부가 될 수 있다. VPN CloudHub는 VPC와 함께, 또는 VPC 없이 사용할 수 있는 단순한 허브 앤 스포크(hub-and-spoke) 모델로 작동합니다. 여러분에게 다수의 지점 사무실과 기존 인터넷 연결이 있고 그러한 원격 사무실들 간에 기본 또는 보조 연결성을 위해 편리하고 비용도 절약할 수 있는 허브 앤 스포크 모델을 구현하려고 한다면 이러한 설계가 적절합니다.

제시된 활용 사례에서 기업 본사에는 VPC에 대한 AWS Direct Connect 연결이 있고 지점 사무실에는 VPC에 대한 사이트 간 VPN 연결이 있습니다. 그러므로 AWS VPN CloudHub를 사용하여 지점 사무실들은 서로 간에, 그리고 기업 본사와 데이터를 전송하고 수신할 수 있습니다.

VPC Endpoint

VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 장치, VPN 연결 또는 AWS Direct Connect 연결 없이 여러분의 VPC를 지원되는 AWS 서비스 및 AWS PrivateLink가 제공하는 VPC 엔드포인트에 사설로 연결할 수 있습니다. 여러분의 VPC 안의 인스턴스들은 서비스의 리소스와 통신하기 위해 공용 IP 주소를 필요로 하지 않습니다. AWS PrivateLink를 사용하면 데이터가 공용 인터넷에 노출되지 않으므로 클라우드 기반 애플리케이션과 공유되는 데이터의 보안이 간단해집니다. 여러분이 VPC 엔드포인트를 사용할 때 여러분의 VPC와 다른 AWS 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다. 따라서 이 선택지는 회사의 원격 지점 사무실들 간에 데이터를 전송하고 수신하는 데 사용할 수 없습니다.

VPC Peering

VPC 피어링(peering) 연결은 사설 IPv4 주소 또는 IPv6 주소를 이용하여 VPC 간의 트래픽을 라우팅할 수 있게 해주는 두 VPC 간의 네트워킹 연결입니다. 한 VPC의 인스턴스들은 마치 동일한 네트워크 안에 있는 것처럼 서로 통신할 수 있습니다. VPC 피어링은 AWS 네트워크 안에 있는 두 VPC 간의 연결을 보조합니다. 따라서 이 선택지는 회사의 원격 지점 사무실들 간에 데이터를 전송하고 수신하는 데 사용할 수 없습니다.

Amazon Cognito 사용자 풀을 사용한다. -> 인증 메커니즘

사용자 풀은 Amazon Cognito의 사용자 디렉터리입니다. 여러분은 Amazon Cognito 사용자 풀을 사용하여 내장된 사용자 관리를 제공하거나 Facebook, Twitter, Google+, Amazon 같은 외부 자격 증명 제공자와 통합할 수 있습니다. 여러분의 사용자가 직접 로그인하든 제3자를 통해 로그인하든 사용자 풀의 모든 구성원은 여러분이 소프트웨어 개발 키트(SDK)를 통해 액세스할 수 있는 디렉터리 프로필을 갖게 됩니다. API 게이트웨이에서 Amazon Cognito 사용자 풀을 만든 다음에 여러분은 해당 사용자 풀을 사용하는 COGNITO_USER_POOLS 권한 부여자를 생성해야 합니다.

자격 증명 풀은 다른 AWS 서비스에 대한 액세스 권한을 여러분의 사용자에게 부여하기 위한 AWS 자격 증명을 제공할 수 있지만, 인증 메커니즘이 아니다!

NAT 인스턴스를 배스천(bastion) 서버로 사용할 수 있다.
보안 그룹은 NAT 인스턴스와 연결할 수 있다.
NAT 인스턴스는 포트 포워딩을 지원한다.

NAT 인스턴스 또는 NAT 게이트웨이는 퍼블릭 서브넷과 여러분의 VPC에서 사용하여 프라이빗 서브넷에 있는 인스턴스들이 인터넷을 향해 아웃바운드 IPv4 트래픽을 개시할 수 있게 해줍니다.

클러스터 배치 그룹 (Cluster Placement Group)

클러스터 배치 그룹은 단일 가용 영역 내에서 인스턴스들을 서로 가깝게 묶어두는 전략입니다. 이것은 마치 아파트의 같은 층에 있는 여러 세대를 하나의 가족이 사용하는 것과 비슷합니다.

• 단일 가용 영역 내에서만 운영됨
• 매우 낮은 지연 시간 (10마이크로초 미만)
• 높은 네트워크 처리량
• 인스턴스들이 물리적으로 가까이 위치

사용 사례:

• 빅데이터 처리 (Hadoop, Spark)
• 고성능 컴퓨팅(HPC) 애플리케이션
• 실시간 데이터 처리가 필요한 시스템

파티션 배치 그룹 (Partition Placement Group)

파티션 배치 그룹은 인스턴스들을 논리적인 파티션으로 나누어 관리합니다. 각 파티션은 자체 랙(하드웨어 세트)에서 실행됩니다. 이는 마치 큰 회사 건물에서 각 부서가 다른 층을 사용하는 것과 유사합니다.

• 여러 가용 영역에 걸쳐 구성 가능
• 각 파티션은 다른 랙에서 실행되어 하드웨어 장애 격리
• 최대 7개의 파티션 생성 가능
• 각 파티션은 여러 인스턴스를 포함할 수 있음.  각 파티션에 들어갈 수 있는 인스턴스의 수는 AWS 계정의 기본 인스턴스 제한에 따라 달라짐

사용 사례:

• 대규모 분산 데이터베이스 (Cassandra, HBase)
• 카프카와 같은 분산 메시징 시스템
• 하드웨어 장애에 대한 내구성이 중요한 애플리케이션

스프레드 배치 그룹 (Spread Placement Group)

스프레드 배치 그룹은 인스턴스들을 물리적으로 최대한 멀리 떨어뜨려 배치하는 전략입니다. 이는 마치 재난 대비를 위해 한 회사의 사무실을 여러 다른 도시에 분산 배치하는 것과 비슷합니다.

• 각 인스턴스는 별도의 하드웨어 랙에서 실행
• 가용 영역당 최대 7개의 인스턴스 배치 가능
• 완벽한 하드웨어 격리 제공
• 여러 가용 영역에 걸쳐 구성 가능

사용 사례:

• 고가용성이 필요한 중요 애플리케이션
• 금융 거래 시스템
• 개별적으로 실행되어야 하는 중요한 서비스들

배치 그룹 선택 시 고려사항:

1. 애플리케이션의 성능 요구사항
   • 낮은 지연시간이 필요하다면 → 클러스터
   • 하드웨어 장애 격리가 중요하다면 → 스프레드
   • 대규모 분산처리가 필요하다면 → 파티션
2. 비용 효율성
   • 클러스터: 단일 가용 영역으로 비용 효율적
   • 파티션/스프레드: 여러 가용 영역 사용으로 추가 비용 발생 가능
3. 확장성
   • 클러스터: 단일 가용 영역 내 제한
   • 파티션: 대규모 확장 가능
   • 스프레드: 제한된 수의 인스턴스만 지원

스프레드 배치 그룹

스프레드 배치 그룹은 구분되는 랙에 배치된 인스턴스 그룹으로서, 각각의 랙에는 고유한 네트워크 및 전원이 있습니다.

스프레드 배치 그룹은 다른 것과 구분하여 보관해야 할 핵심적인 적은 수의 인스턴스가 있는 애플리케이션에 적합합니다. 스프레드 배치 그룹에서 인스턴스를 실행하면 인스턴스들이 같은 랙을 공유할 때 발생할 수 있는 동시적 고장의 위험이 감소하게 됩니다.

스프레드 배치 그룹은 동일한 리전(Region)에 있는 다수의 가용 영역에 분산될 수 있습니다. 그룹 및 가용 영역(AZ)당 최대 7개의 실행 인스턴스를 가질 수 있습니다. 그러므로 하나의 스프레드 배치 그룹에 15개의 EC2 인스턴스를 배포하려면 회사는 3개의 AZ를 사용해야 합니다.

aws S3 sync 명령어를 사용해 소스 버킷에서 대상 버킷으로 데이터를 복사한다.

aws S3 sync 명령은 S3 버킷들 간에 객체를 복사하기 위해 CopyObject API를 사용합니다. sync 명령은 소스와 타깃 버킷을 나열하여 소스 버킷에는 있지만 타깃 버킷에는 없는 객체를 식별합니다. 해당 명령은 또한 타깃 버킷에 있는 객체와 LastModified 날짜가 다른 소스 버킷의 객체들도 식별합니다. 버저닝된 버킷에 대한 sync 명령은 현재의 객체 버전만 복사하며 이전 버전은 복사되지 않습니다. 기본적으로 객체 메타데이터가 보존되지만 여러분의 AWS 계정에서 접근통제목록(ACL)이 FULL_CONTROL로 설정되며, 그러면 추가적인 ACL이 모두 삭제됩니다. 작업이 실패하면 이전에 복사한 객체를 복제할 필요 없이 sync 명령을 다시 실행할 수 있습니다.

S3 배치 복제를 사용하면 복제 구성이 이루어지기 전에 있었던 객체, 이전에 복제되었던 객체, 복제에 실패했던 객체를 복제할 수 있습니다. Batch Operations 작업을 이용하여 복제할 수 있습니다.

온디맨드 인스턴스와 스팟 인스턴스를 모두 사용해 원하는 규모, 성능, 비용을 달성하려면, 각 인스턴스 유형의 용량을 프로비저닝할 때 시작 템플릿(Launch Template)만을 사용해야 한다.

시작 템플릿은 Amazon Machine Image(AMI)의 ID, 인스턴스 타입, 키 쌍, 보안 그룹, 그리고 여러분이 EC2 인스턴스를 시작하기 위해 사용하는 다른 파라미터 같은 인스턴스 구성 정보를 지정한다는 점에서 시작 구성과 비슷합니다. 또한 시작 구성 대신에 시작 템플릿을 정의하면 여러분은 다수의 템플릿 버전을 가질 수 있습니다.

시작 템플릿을 사용하면 여러분이 원하는 스케일, 성능, 비용을 달성하기 위해 온디맨드 인스턴스와 스폿 인스턴스를 모두 사용하여 다수의 인스턴스 타입에 걸쳐 용량을 프로비저닝할 수 있습니다. 

시작 구성은 오토 스케일링 그룹이 EC2 인스턴스를 실행하는 데 사용하는 인스턴스 구성 템플릿이다

사용자 데이터(UserData)로 입력된 스크립트는 기본적으로 루트 사용자 권한으로 실행된다.

사용자 데이터로서 입력된 스크립트는 루트 사용자 권한으로 실행되며, 따라서 스크립트에 sudo 명령을 쓸 필요가 없습니다. 여러분이 생성한 모든 파일은 루트가 소유하며, 루트 사용자 이외의 사용자가 파일에 액세스해야 한다면 스크립트에서 적절히 권한을 수정해야 합니다.

사용자 데이터는 기본적으로 인스턴스를 처음 시작할 때의 부팅 주기 동안만 실행된다.

기본값으로서, 사용자 데이터 스크립트와 cloud-init 명령은 여러분이 인스턴스를 최초로 실행할 때 부팅 사이클 중에만 실행됩니다. 여러분이 인스턴스를 재시작할 때마다 사용자 데이터 스크립트와 cloud-init 명령이 실행되도록 구성을 업데이트할 수 있습니다.

Amazon Simple Queue Service(SQS)

SQS는 마이크로서비스, 분산 시스템, 서버리스 애플리케이션을 디커플링하고 스케일링할 수 있게 해주는 완벽히 관리되는 메시지 대기열화 서비스입니다. SQS는 복잡성을 줄여주고 메시지에서 유래되는 미들웨어의 관리와 운영에 관련된 경상운영비를 줄여주며 개발자들이 차별화 업무에 집중할 수 있도록 역량을 강화해줍니다. 여러분은 SQS를 사용하여 메시지를 잃거나 다른 서비스를 사용할 필요 없이 모든 볼륨의 소프트웨어 컴포넌트 간에 메시지를 전송, 저장, 수신할 수 있습니다.

SQS는 두 가지 유형의 메시지 대기열을 제공합니다. 표준 대기열은 처리 속도가 극대화되고 순서가 최적화되며 최소한 한 번 전달이 이루어집니다. SQS FIFO 대기열은 메시지가 전송된 순서대로 정확히 한 번 처리되도록 보장하기 위해 고안되었습니다.

기본값으로서, FIFO 대기열은 배칭(batching)을 이용하여 초당 최대 3,000개의 메시지를 지원하거나 배칭 없이 초당 최대 300개의 메시지를 지원합니다(초당 300회의 전송, 수신 또는 삭제 작업). 그러므로 배칭을 사용하면 여러분은 초당 최대 3,000개의 메시지 처리 속도 요구사항을 충족할 수 있습니다.

FIFO 대기열의 이름은 .fifo라는 접미어로 끝나야 합니다. 접미어도 80자라는 대기열 이름 한도에 포함됩니다. 어떤 대기열이 FIFO인지 결정하기 위해, 여러분은 대기열 이름이 그 접미어로 끝나는지 확인할 수 있습니다.

만일 표준 대기열을 사용하는 기존 애플리케이션이 있고, FIFO 대기열의 정렬(ordering) 또는 정확히 한 번(exactly-once) 처리 기능을 이용하고 싶다면 대기열과 애플리케이션을 정확히 구성해야 합니다. 기존의 표준 대기열을 FIFO 대기열로 변환할 수는 없습니다. 구성을 위해 여러분은 애플리케이션을 위해 새로운 FIFO 대기열을 만들거나 기존의 표준 대기열을 삭제하고 FIFO 대기열로서 새로 만들어야 합니다.

EC2 시작 유형의 ECS는 EC2 인스턴스 및 EBS 볼륨 사용량에 따라 요금이 청구된다.
Fargate 시작 유형은 컨테이너화된 애플리케이션이 요청하는 vCPU 및 메모리 리소스 양에 따라 요금이 부과된다.

Amazon Elastic Container Service(Amazon ECS)는 완벽히 관리되는 컨테이너 오케스트레이션 서비스입니다. ECS를 이용하면 AWS에서 Docker 콘테이너 애플리케이션을 손쉽고 안전하게 실행하고 스케일링할 수 있습니다. Fargate 시작 타입을 선택하면 여러분의 컨테이너화된 애플리케이션이 요청하는 vCPU 및 메모리 리소스의 양에 대해 비용을 지불합니다. vCPU 및 메모리 리소스는 여러분의 컨테이너 이미지를 당겨온 시각부터 Amazon ECS 작업*이 종료될 때까지 계산되며, 초 단위까지 반올림됩니다. EC2 시작 타입을 선택하면 EC2 시작 타입에 대해 추가 요금이 부과되지 않습니다. 여러분은 애플리케이션을 저장하고 실행하기 위해 생성한 AWS 리소스(예, EC2 인스턴스 또는 EBS 볼륨)에 대해 요금을 지불합니다.

AWS Global Accelerator를 사용해 트래픽의 일부를 특정 배포로 분산한다.

AWS 글로벌 액셀러레이터는 AWS 글로벌 네트워크에 걸쳐 트래픽을 최적의 엔드포인트로 인도하는 네트워크 레이어 서비스입니다. 이로써 인터넷 애플리케이션의 가용성과 성능이 개선됩니다. AWS 글로벌 액셀러레이터는 하나 또는 다수의 AWS 리전에서 애플리케이션 로드 밸런서, 네트워크 로드 밸런서, 탄력적 IP 주소 또는 Amazon EC2 인스턴스 등 여러분의 애플리케이션 엔드포인트에 대한 고정된 진입점 역할을 하는 정적 애니캐스트(anycast) IP 주소를 2개 제공합니다.

AWS 글로벌 액셀러레이터를 사용하면 클라이언트 장치의 DNS 캐싱, 인터넷 리졸버, 트래픽 다이얼과 상관없이 청색 및 녹색 환경 간에 점진적으로 또는 한꺼번에 트래픽을 이전할 수 있으며 엔드포인트 가중치 변경은 몇 초 안에 유효해집니다.

온프레미스 데이터를 여러 Snowball Edge Storage Optimized 장치로 전송한다. Snowball Edge에서 Amazon S3로 데이터를 복사하고, 수명 주기 정책을 생성하여 해당 데이터를 AWS Glacier에 백업한다.

수 테라바이트 내지 페타바이트급의 데이터를 AWS로 안전하고 빠르게 전송해야 한다면 Snowball Edge Storage Optimized가 최적의 선택입니다. 최대 사용 가능한 HDD 저장소 80TB, vCPU 40개, SATA SSD 저장소 1TB를 제공하며, 대규모 데이터 전송 및 전처리 활용 사례를 위해 최대 40Gb의 네트워크 연결성을 제공합니다. 1PB를 전송하려면: 1,024TB ÷ 80TB = 약 13대의 Snowball Edge 장치를 쓰면 된다. Snowball Edge 장치에 저장된 데이터는 S3 버킷에 복사할 수 있고, 나중에 라이프사이클 정책을 통해 AWS Glacier로 이전할 수 있습니다. 여러분은 데이터를 직접 Snowball Edge 장치에서 AWS Glacier로 복사할 수 없습니다.

프로세스가 기존 객체를 변경한 뒤 즉시 읽으려고 하면 Amazon S3는 항상 최신 버전의 객체를 반환한다.

Amazon S3는 성능이나 가용성을 변경하지 않고, 또한 애플리케이션의 지역적 분리도를 희생시키지 않고 어떠한 추가 비용도 없이 자동으로 강력한 쓰기 후 읽기(read-after-write) 일관성을 제공합니다.

새로운 객체를 성공적으로 쓰거나 기존 객체에 덮어 쓴 후에 이루어지는 읽기 요청은 즉시 객체의 최신 버전을 받게 됩니다. S3는 또한 리스트 작업에도 강력한 일관성을 제공하기 때문에 쓴 다음에 즉시 모든 변경사항을 반영하여 버킷에 있는 객체의 목록화를 수행할 수 있습니다.

강력한 쓰기 후 읽기 일관성은 여러분이 쓴 다음에 즉시 객체를 읽어야 할 때 유용합니다. 예를 들어 여러분이 자주 읽고 객체를 쓴 다음에 즉시 목록화를 할 경우에 강력한 쓰기 후 읽기 일관성이 도움을 줍니다.

요약하자면, 모든 S3의 GET, PUT, LIST 작업, 그리고 객체의 태그, ACL 또는 메타데이터를 변경하는 작업에 강력한 일관성이 있습니다. 여러분이 기록한 바로 그것을 읽게 되고, LIST의 결과는 버킷 안에 있는 것들을 정확히 반영하게 됩니다.

VPC 공유를 사용해 AWS Organizations에서 동일한 상위 조직에 속한 다른 AWS 계정과 하나 이상의 서브넷을 공유한다.

VPC 공유(리소스 액세스 매니저의 일부)를 이용하면 다수의 AWS 계정이 EC2 인스턴스, RDS 데이터베이스, Redshift 클러스터, 람다 함수 같은 애플리케이션 리소스를 공유되고 일원적으로 관리되는 Amazon 가상 사설 클라우드(VPC)로 만들 수 있습니다. 이렇게 설정하기 위해 VPC를 소유한 계정(오너)은 AWS 조직의 동일한 조직에 속한 다른 계정(참여자)과 하나 이상의 서브넷을 공유합니다. 오너 계정은 VPC 자체를 공유할 수 없습니다. 서브넷이 공유된 후에 참여자는 공유된 서브넷에서 자신들의 애플리케이션 리소스를 열람, 생성, 변경, 삭제할 수 있습니다. 참여자들은 다른 참여자 또는 VPC 오너에게 속한 리소스를 열람, 변경 또는 삭제할 수 없습니다.

여러분은 Amazon VPC를 공유하여, 높은 수준의 상호연결성을 요구하고 동일한 신뢰성 경계 안에 있는 애플리케이션들을 위해 VPC 안의 암묵적 라우팅(implicit routing)을 활용할 수 있습니다. 그렇게 하면 청구와 액세스 통제를 위해 별도의 계정을 사용하는 한편, 여러분이 생성하고 관리하는 VPC의 개수가 감소합니다.

AWS Elastic Beanstalk

AWS Elastic Beanstalk는 Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker로 개발한 웹 애플리케이션과 서비스를 Apache, Nginx, Passenger, IIS 등의 유명한 서비스에 배포하고 스케일링하는 데 사용되는 간편한 서비스입니다.

여러분이 간단히 코드를 업로드하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, 자동 스케일링부터 애플리케이션 건전성 모니터링까지 배포를 자동으로 처리합니다. 또한 여러분은 애플리케이션을 지원하는 AWS 리소스에 대해 완전한 통제력을 유지하고 언제라도 그러한 리소스에 액세스할 수 있습니다.

여러분이 AWS Elastic Beanstalk 환경을 생성할 때 플랫폼 버전에 포함된 표준 Elastic Beanstalk AMI 대신에 Amazon Machine Image(AMI)를 지정할 수 있습니다. 커스텀 AMI를 사용하면 표준 AMI에 포함되어 있지 않은 많은 소프트웨어를 설치해야 할 경우, 여러분의 환경에서 인스턴스가 실행될 때 프로비저닝 시간을 개선할 수 있습니다.

정적 설치 컴포넌트가 구성되어 있는 골든 이미지(Golden AMI)를 생성한다. - Golden AMI는 구성, 일관된 보안 패칭, 보강을 통해 표준화하는 AMI입니다. Golden AMI에는 여러분이 로깅, 보안, 성능 모니터링 등을 위해 승인한 에이전트도 포함되어 있습니다. 제시된 활용 사례의 경우, 여러분은 Golden AMI를 통해 이미 설정한 정적 설치 컴포넌트를 가질 수 있습니다.

EC2 사용자 데이터를 사용해 부팅 시점에 동적 설치 부분의 설정을 변경한다. - EC2 인스턴스 사용자 데이터는 여러분이 인스턴스를 실행하는 중에 구성 스크립트 형태로 지정하는 데이터입니다. 여러분은 EC2 사용자 데이터를 이용하여 부팅 시 애플리케이션 자체를 설치하는 대신에, 부팅 시 동적 설치 부분을 사용자 지정할 수 있습니다.

Amazon S3 버킷 정책을 사용한다.

Amazon S3의 버킷 정책을 사용하여 하나의 버킷에 있는 객체 일부 또는 전부에 걸쳐 권한을 추가하거나 거부할 수 있습니다. 정책을 사용자, 그룹 또는 Amazon S3 버킷에 부착하여 권한을 일원화해서 관리할 수 있습니다. 버킷 정책을 사용하면 여러분의 AWS 계정 또는 다른 AWS 계정에 있는 사용자들에게 여러분의 Amazon S3 리소스에 대한 액세스 권한을 부여할 수 있습니다.

여러분은 특정한 조건을 기준으로 구체적인 리소스에 대한 액세스를 더욱 제한할 수도 있습니다. 예를 들면, 여러분은 요청 시간(날짜 조건), 요청이 SSL을 이용하여 전송되었는지의 여부(불리언 조건), 요청자의 IP 주소(IP 주소 조건) 또는 요청자의 클라이언트 애플리케이션(문자열 조건)을 기준으로 액세스를 제한할 수 있습니다. 그러한 조건들을 식별하기 위해 정책 키를 사용할 수 있습니다. 버킷에 대한 객체(데이터) 액세스!!!

IAM 정책을 사용하면 여러분의 AWS 계정 안에 있는 사용자들에게만 여러분의 Amazon S3 리소스에 대한 액세스 권한을 부여할 수 있는데, 다른 계정 사용자들한테는 부여가 안된다!

S3 전송 가속화(Transfer Acceleration)를 사용하여 목적지 S3 버킷으로 더 빠르게 파일을 업로드한다.

 Amazon S3 Transfer Acceleration을 사용하면 여러분의 클라이언트와 S3 버킷 사이의 먼 거리에 걸쳐 파일들을 빠르고 쉬우며 안전하게 전송할 수 있습니다. Transfer Acceleration은 Amazon CloudFront의 전 세계적으로 분포된 엣지 위치를 활용합니다. 데이터가 엣지 위치에 도달하면 최적화된 네트워크 경로를 거쳐 데이터가 Amazon S3로 라우팅됩니다.

멀티파트(multipart) 업로드를 사용해 목적지 S3 버킷으로 더 빠르게 파일을 업로드한다.

멀티파트 업로드를 사용하면 하나의 객체를 부분들로서 업로드할 수 있습니다. 각각의 부분들은 객체 데이터의 인접한 부분들입니다. 여러분은 그러한 객체 부분들을 독립적으로, 그리고 어떤 순서로도 업로드할 수 있습니다. 어떤 부분의 전송이 실패하면 여러분은 다른 부분에 영향을 미치지 않고 그 부분을 재전송할 수 있습니다. 객체의 모든 부분이 업로드되면 Amazon S3는 그 부분들을 조립하여 객체를 만듭니다. 일반적으로 여러분의 객체 크기가 100MB에 도달하면 객체를 한 번의 작업으로 업로드하는 대신에 멀티파트 업로드 이용을 고려해야 합니다. 멀티파트 업로드는 처리속도가 개선되므로 더 빠르게 파일을 업로드하는 데 도움이 됩니다.

권한 경계(Permissions boundary)를 사용해 직원이 IAM 주체에게 부여할 수 있는 최대 권한을 제어한다.

권한 경계를 사용하여 직원들이 그들이 생성하고 관리하는 IAM 주체에 부여할 수 있는 최대 권한 수(즉 사용자와 역할)를 통제할 수 있습니다. IAM 관리자로서 여러분은 관리된 정책을 이용하여 하나 이상의 권한 경계를 정의하고 직원들이 이 경계 안에서 주체를 생성하도록 할 수 있습니다. 이어서 직원들은 그러한 주체에게 권한 정책을 부착할 수 있습니다. 그러나 권한 경계와 권한 정책의 교차점이 주체의 효과적인 권한이라고 할 수 있습니다. 결과적으로 새로운 주체는 여러분이 정의한 경계를 초과할 수 없습니다. 그러므로 권한 경계를 사용하는 것이 이 활용 사례의 적절한 솔루션

Lambda 함수에 S3 버킷에 대한 액세스 권한을 부여하는 IAM 역할을 생성하고, 해당 IAM 역할을 Lambda 함수의 실행 역할로 설정한다. 버킷 정책에서 Lambda 함수의 실행 역할에도 액세스 권한을 부여하는지 확인한다.

동일한 AWS 계정에서 여러분이 람다 함수에 대해 IAM 역할을 생성한 경우, IAM 역할과 버킷 정책 모두에 Amazon S3 권한을 부여할 필요가 없습니다. 대신에 여러분은 IAM 역할에 권한을 부여하고, 이어서 버킷 정책이 람다 함수 역할에 대한 액세스를 명시적으로 거부하지 않는지 확인할 수 있습니다. IAM 역할과 버킷이 다른 계정에 있는 경우, 여러분은 IAM 역할과 버킷 정책 모두에 Amazon S3 권한을 부여해야 합니다. 그러므로 이것이 제시된 활용 사례에서 AWS Lambda에 대한 액세스 권한을 부여하는 올바른 방법입니다.

Redshift Spectrum을 사용해 S3에 있는 과거 데이터를 가리키는 Redshift 클러스터 테이블을 생성한다. 분석 팀은 과거 데이터를 쿼리하여 Redshift의 일일 보고서와 상호 참조할 수 있다.

Amazon Redshift는 대규모 데이터셋의 저장과 분석을 위해 고안된 완전히 관리되는 페타바이트 스케일 클라우드 기반 데이터 웨어하우스 제품입니다.

Amazon Redshift 스펙트럼을 이용하면 Amazon Redshift 테이블에 데이터를 로딩할 필요 없이 Amazon S3 안의 파일에서 구조화/반구조화 데이터를 효율적으로 쿼리하고 검색할 수 있습니다.

Amaozn Redshift 스펙트럼은 전용 Amaozn Redshift 서버에 상주하며, 여러분의 클러스터와 독립되어 있습니다. Redshift 스펙트럼은 조건 필터링, 집계처럼 연산집약적인 많은 작업을 Redshift 스펙트럼 레이어까지 푸시합니다. 따라서 Redshift 스펙트럼 쿼리는 다른 쿼리에 비해 여러분 클러스터의 처리 능력을 훨씬 덜 사용합니다.

EC2 전용 호스트를 사용한다.

여러분은 전용 호스트를 사용하여 Amazon EC2 인스턴스를 여러분의 전용 물리 서버에서 실행할 수 있습니다. 전용 호스트를 사용하면 인스턴스가 물리 서버에 어떻게 배치되어 있는지 눈으로 확인하고 통제할 수 있으며 오랫동안 동일한 물리 서버를 안정적으로 사용할 수 있습니다. 결과적으로 전용 호스트를 사용하면 여러분은 Windows Server 같은 서버에 연계된 기존 소프트웨어 라이선스를 사용하고 기업의 규정 준수 및 규제 요건을 충족할 수 있게 됩니다.

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!