생각한 풀이 방식은 다음과 같다 맨 윗줄 ➡️ 맨 오른쪽 줄 ⬇️ 맨 아랫줄 ⬅️ 맨 왼쪽 줄 ⬆️으로 숫자를 하나씩 증가시키며 채워 나가되, 사각형의 크기를 점점 줄여주는 것이다.

아무튼, start = 0, end = N-1로 설정하고, for문 네 개로 가장 바깥쪽 테두리의 숫자를 채운 후, start++, end--로 범위를 좁혀가며 end가 start보다 작아질 때까지 반복한다.

시간 복잡도는 O(T*N^2)로, 1 ≤ N ≤ 10라서 충분하다!

#include <iostream>
#include <algorithm>
#include <vector>
using namespace std;


int main(int argc, char** argv)
{
    int test_case;
    int T, N, i, j, start, end, num;
    cin>>T;

    vector <vector <int>> snail;

    for(test_case = 1; test_case <= T; ++test_case)
    {
            cin>>N;
            snail.clear();
            snail.resize(N,vector<int>(N,0));
            start=0;
            end=N-1;
            num=1;

            while(start<end){
                for( i=start; i<=end; i++ ){
                    snail[start][i]=num++;
                }   
                for( i=start+1;i<=end;i++){
                    snail[i][end]=num++;
                }
                for( i=end-1;i>=start;i--){
                    snail[end][i]=num++;
                }
                for( i=end-1;i>start;i--){
                    snail[i][start]=num++;
                }
                start++;
                end--;

            }
            if(start==end) snail[start][start]=num++;

            cout<<"#"<<test_case<<"\n";
            for( i=0;i<N;i++){
                for( j=0;j<N;j++){
                    cout<<snail[i][j]<<" ";
                }
                cout<<"\n";
            }   

    }
    return 0;
}

snail.clear();를 사용하지 않으면 두 번째 테스트케이스부터 이상한 결과가 나왔다.

찾아보니, C++에서 resize()는 벡터의 크기를 변경하지만, 메모리 용량(capacity)은 그대로 유지할 수 있다고 한다. 즉, 벡터가 이전 테스트케이스에서 할당한 메모리를 그대로 사용하면서 이전 데이터가 남아 있을 수 있다는 의미다.

크기를 바꾸고 0으로 초기화까지 했는데 왜 그런지 정확히는 모르겠지만.. 벡터를 재사용할 때 clear()는 꼭 해 줘야겠다

다른 풀이를 찾아보니, 방향 d를 설정해 계속 바꿔가며 진행하는 방식과 DFS를 활용한 풀이도 있었다. 내 방법도 좋지만, DFS를 적용할 생각은 전혀 못했다....! 다양하게 생각해보기:)

우선, 최대 가격일 때 팔아야 하고, 이후에 또 물건이 남아 있다면 그 중 최대 가격일 때 다시 판매해야 한다.

예를 들어, 가격이 1 1 3 1 2로 주어진다면, 전체에서 최댓값은 3이다.
그러면 첫째 날과 둘째 날에 구매한 후, 셋째 날에 판매하면 된다.
이렇게 셋째 날까지 총 4의 이익을 얻는다.

그다음, 넷째 날 이후의 가격에서 다시 최댓값을 찾는다.
이 경우, 다섯째 날이 최댓값이므로 넷째 날에 구매 후 다섯째 날에 판매하면 된다.
이때 1의 이익이 추가된다.

생각 1

이런 로직으로 생각해 max_element 함수를 사용해 앞에서부터 진행하며 최대값인 인덱스 전까진 구매하고, 최대일 때 판매한 뒤, 이후 범위에서 다시 최대값을 업데이트했다.
하지만 max_element를 너무 자주 쓰는 것 같아 조금 찝찝한 풀이였다.

#include <iostream>
#include <algorithm>
#include <vector>
using namespace std;

int main(int argc, char** argv)
{
    int test_case;
    int T, N, maxIndex, answer;
    vector <int> future;
    vector <int> tmp;

    cin>>T;

    for(test_case = 1; test_case <= T; ++test_case)
    {
        cin>>N;
        future.resize(N,0);
        for(int i=0;i<N;i++){
            cin>>future[i];
        }

        tmp.clear();
        maxIndex=0; answer=0;
        maxIndex=max_element(future.begin(), future.end()) - future.begin();

        for(int i=0;i<N;i++){
            if(i<maxIndex){
                tmp.push_back(future[i]);
            }
            else if(i==maxIndex){
                for(int t:tmp){
                    answer+=future[i]-t;
                }
                tmp.clear();
                maxIndex=max_element(future.begin()+i+1, future.end())- future.begin();
            }
        }
        cout<<"#"<<test_case<<" "<<answer<<endl;


    }
    return 0;
}

시간 초과도 아니고 Fail(오답) 메시지가 떴다..

생각 2

인터넷에서 다른 풀이를 참고해 보았다. 생각 자체는 비슷했지만, 탐색을 아예 맨 뒤에서부터 시작하면 max 변수만 업데이트하면서 진행할 수 있다는 점을 알았다! 시간 복잡도를 개선하려면 많은 고민이 필요하구나..

그런데.. 그렇게 작성한 코드도 예상 외로 _Fail(오답)_이 나오는것이다....

생각 3

놀랍게도 원인은 answer 변수의 자료형에 있었다. int가 아닌 long long을 사용해야 했다...

long long으로 변경하니 드디어 PASS!

최종 코드는 아래와 같다.

#include <iostream>
#include <algorithm>
#include <vector>
using namespace std;

int main(int argc, char** argv)
{
    int test_case;
    int T, N, max;
    long long answer;
    vector <int> future;

    cin>>T;

    for(test_case = 1; test_case <= T; ++test_case)
    {
        answer=0;max=-1;
        cin>>N;
        future.resize(N,0);
        for(int i=0;i<N;i++){
            cin>>future[i];
        }


        for(int i=N-1;i>=0;i--){
            if(future[i]>max){
                max=future[i];
            }
            else{
                answer+=max-future[i];
            }
        }


        cout<<"#"<<test_case<<" "<<answer<<endl;


    }
    return 0;
}

생각 1의 코드도 answer의 자료형을 long long으로 바꾸니 PASS였다. 그래도 이건 제한 시간이 길어서 가능한 것!

시간 복잡도에 항상 유의하며 잘 공부하자.

1,000,000일 동안 매일 10,000원에 가깝다면
1,000,000 * 10,000 = 10,000,000,000 (100억)이다...! 워~~ 근데 오버플로우라고 안뜨고 오답이라고 뜨다니 너무하다

long long 정리

• int

  • 32비트
  • 범위: -2,147,483,648 ~ 2,147,483,647 (약 21억)

• long long

  • 범위: -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807

틀림~

1. power가 짧다고 아랫것도 push안함 (testcase없으면 어떻게 알아낼건데)
2. OFF한 본인은 아랫것들 알림 받을수가 있었음;;
3. 아예 수신가능 알림 수를 계속 업데이트 해서 사용. 500 호출 시 for문돌리면 시간초과남 근데 dp 로직 자체가 답을 봐도 이해가 안돼서 오답 포기.. 강해져서 돌아오자

#include <iostream>
#include <algorithm>
#include <vector>
#include <queue>
using namespace std;
int N;


int val[21];
int info[100001][21];


struct node {
    int data;
    int parent;
    int authority;
    int alarm;
};
vector <node> Chat;

void update (int start){
    for(int i=start;i<=N;i++){
        int curr=i;
        int x=Chat[curr].authority;
        while(Chat[curr].parent!=0&&x!=0){
            curr=Chat[curr].parent;
            x--;
            if(x>0) val[curr]++;
            nx[curr][x]++;
        }
    }

}



void alarmOn(int c){
    if(Chat[c].alarm==1)Chat[c].alarm=0;
    else Chat[c].alarm=1;
}
void powerChange(int c, int power){
    Chat[c].authority=power;
}
void changeParents(int c1, int c2){
    int tmp=Chat[c1].parent;
    Chat[c1].parent=Chat[c2].parent;
    Chat[c2].parent=tmp;
}
void checkAlarm(int c){
    int cnt=0;
    queue <pair<int,int>> check;
    check.push(make_pair(c,1));
    while(!check.empty()){
        int front_data=check.front().first;
        int front_length=check.front().second;
        check.pop();
        for(node n:Chat){
            if(n.parent==front_data&&n.alarm==1){
                if(n.authority>=front_length){
                    cnt++;
                }
                check.push(make_pair(n.data,front_length+1));
            }
        }
    }
    cout<<cnt<<endl;

}

int main() {
    int order,Q,value1, value2;
    cin>>N>>Q;
    Chat.resize(1+N);

    // 100 준비 
    cin>>order;
    for(int i=1;i<=N;i++){
        cin>>Chat[i].parent;
        Chat[i].data=i;
        Chat[i].alarm=1;
    }
    for(int i=1;i<=N;i++){
        cin>>Chat[i].authority;
    }

    // 명령 입력
    int num=1;
    while(num++<Q){
        cin>>order;
        if(order==200){
            cin>>value1;
            alarmOn(value1);
        }
        else if (order == 300){
            cin>>value1>>value2;
            powerChange(value1,value2);
        }
        else if (order == 400){
            cin>>value1>>value2;
            changeParents(value1,value2);
        }
        else if (order == 500){
            cin>>value1;
            checkAlarm(value1);
        }
    }




    return 0;
}

#include <iostream>
#include <algorithm>
#include <vector>
using namespace std;

int main()
{
    int N;
    cin>>N;
    vector <vector<pair<int,int>>> vec(N+1);// i날 끝나는거 모음:시작 날짜, 금액
    vector<int> dp(N+1);

    int t,p;
    for(int i=1;i<=N;i++){
        cin>>t>>p;
        if (i + t - 1 <= N) vec[i+t-1].push_back(make_pair(i,p));
    }

    for(int i=1;i<=N;i++){
        dp[i]=dp[i-1];
        for(pair<int,int> p : vec[i]){
            dp[i]=max(dp[i],dp[p.first-1]+p.second);
        }
    }

    cout<<dp[N];

    return 0;
}

1. if (i + t - 1 <= N) 이거 추가 안하고서 왜 코드 안돌아가징.. 이랬다..
2. dp 식에서 dp[p.first-1]+p.second인데 처음엔 dp[p.first]+p.second로 작성했다,,
3. 식: 현재 i일에서 끝나는 모든 상담에 대해 진행 start: 현재 보고있는 상담이 시작하는 날 / p: 현재 보고있는 상담의 금액 dp[i]=max(dp[i-1]+dp[start-1]+p)

#include <iostream>
#include <algorithm>
#include <vector>
#include <queue>
#include <set>
using namespace std;
int L,N,Q;
int dx[]={-1,0,1,0};
int dy[]={0,1,0,-1};
vector <vector <int>> chess;
vector <vector <int>> knLo;

struct knight {
    int r;
    int c;
    int h;
    int w;
    int k;
    int dm;
};

vector <knight> Knight;

void move(int n,int d,set<int> s){
    for (auto element : s){
        // 기존 위치 다 0으로 설정
        for(int j=0;j<Knight[element].h;j++){
            for(int k=0;k<Knight[element].w;k++){
                knLo[Knight[element].r+j][Knight[element].c+k]=0;
            }
        }
    }
    for (auto element : s){
        // 위치정보 r,c 변경
        Knight[element].r+=dx[d];
        Knight[element].c+=dy[d];

        // 명령 받은애 아니면 데미지 계산, 죽나 확인
        if(element!=n){
            for(int j=0;j<Knight[element].h;j++){
                for(int k=0;k<Knight[element].w;k++){
                    if(chess[Knight[element].r+j][Knight[element].c+k]==1){ // 함정이라면
                        Knight[element].dm++; //데미지 계산
                        Knight[element].k--; // 체력 계산
                        if(Knight[element].k<=0){ // 체력 고갈된 경우 죽음
                            Knight[element].r=-1; 
                            Knight[element].c=-1;
                            Knight[element].h=-1;
                            Knight[element].w=-1;
                            break;
                        }
                    }
                }
                if(Knight[element].r==-1)break;
            }
        }
    }
    for (auto element : s){
        if(Knight[element].r!=-1){ //안죽었으면 다시 배치
            for(int j=0;j<Knight[element].h;j++){
                for(int k=0;k<Knight[element].w;k++){
                    knLo[Knight[element].r+j][Knight[element].c+k]=element;
                }
            }
        }
    }



}

void play(int n,int d){

    int r=Knight[n].r;
    int c=Knight[n].c;
    int h=Knight[n].h;
    int w=Knight[n].w;
    if(r==-1) return; // 마지막에 추가. 없으면 테스트케이스 18번에서 틀림

    queue <int> nextK;
    set <int> tmp;
    tmp.insert(n);
    int can=1;
    for(int j=0;j<h;j++){
        for(int k=0;k<w;k++){
            if(chess[r+j+dx[d]][c+k+dy[d]]==2){
                can=0;
                break;
            }
            int next= knLo[r+j+dx[d]][c+k+dy[d]];
            if(next!=0&&next!=n) {
                nextK.push(next);
                tmp.insert(next);
            }
        }
        if(can==0)break;
    }
    if(can==1){
        while(!nextK.empty()&&can==1){
            int nn=nextK.front();
            nextK.pop();
            for(int j=0;j<Knight[nn].h;j++){
                for(int k=0;k<Knight[nn].w;k++){
                    if(chess[Knight[nn].r+j+dx[d]][Knight[nn].c+k+dy[d]]==2){
                        can=0;
                        break;
                    }
                    int next= knLo[Knight[nn].r+j+dx[d]][Knight[nn].c+k+dy[d]];

                    if(next!=0&&next!=nn) {
                        nextK.push(next);
                        tmp.insert(next);
                    }
                }
                if(can==0)break;
            }
        }
    }
    if(can) move(n,d,tmp);

}



int main() {
    cin>>L>>N>>Q;
    chess.resize(L+2,vector <int>(L+2,2));
    knLo.resize(L+1,vector <int>(L+1,0));
    Knight.resize(N+1); 

    for(int i=1;i<=L;i++){
        for(int j=1;j<=L;j++){
            cin>>chess[i][j];
        }
    }
    int r,c,h,w,k;
    for(int i=1;i<=N;i++){
        cin>>r>>c>>h>>w>>k;
        Knight[i].r=r;
        Knight[i].c=c;
        Knight[i].h=h;
        Knight[i].w=w;
        Knight[i].k=k;
        Knight[i].dm=0;
        for(int j=0;j<h;j++){
            for(int k=0;k<w;k++){
                knLo[r+j][c+k]=i;
            }
        }
    }

    int n,d,rr=0;
    while(rr++<Q){
        cin>>n>>d;
        play(n,d);
        // for(int i=1;i<=L;i++){for(int j=1;j<=L;j++){cout<<knLo[i][j];}cout<<endl;}
    }
    int ans=0;
    for(knight k: Knight){
        if(k.r!=-1) ans+=k.dm;
    }
    cout<<ans;
    return 0;
}

1. 처음에 옆에 있는 기사들을 큐에 저장했더니 같은 기사가 여러 번 저장돼서 데미지가 여러번 계산됐다. 중복 안되게 set로 바꿨다.
2. deque나 map이나 set 써볼때 문법 찾아봤다. 안보고도 쓸줄알기
3. if(r==-1) return; 이거 마지막에 추가했다. 안하면 틀림

테스트 케이스 여러개가 아니면 이런 사소한 부분들을 다 안틀리고 챙길 수 있을지 모르겠다🥲

1. 총바꾸는 로직을 changeGun함수로 안빼고 중복된 코드를 계속 작성했었다.
2. gun을 sort해서 관리할 생각을 못해서 계속 push_back 하고 find해서 erase했었다. 비효율적이다.
3. ⭐️ 싸움 후 진사람 방향 바꿀 때 for문 안에서 새로운 방향을 nd에 저장하는게 아니라 d에 저장해서 계속 업데이트 했다. 그럼 당연히 방향이 제대로 설정이 안된다.... 이거때문에 틀린 부분 몇시간을 찾았다.

원스는 사용자가 보유한 카드 중 특정 결제처에서 최대 할인을 받을 수 있는 카드를 추천함으로써, 소비자가 모든 카드의 혜택을 최대한 손쉽게 활용할 수 있는 솔루션을 제공한다.

가장 핵심적인 서비스인 "카드 추천"의 구현을 위한 과정과 그 기술들을 정리해보고자 한다.

카드 추천 모델 선택 과정

최대 혜택을 주는 카드 추천 챗봇을 구현하기 위해 많은 시행착오와 결정이 있었다.
주어진 여러 카드들의 조합에서 최대의 혜택을 주는 카드를 "추천"한다는 점에서 추천 모델 사용을 고려하였지만, 사용자의 선호도 또는 과거의 기록과는 상관없는 단발적인 선택에 해당되기에, 생성형 ai를 사용하고, 가능하다면 파인튜닝하여 해당 작업에 대한 적합도를 높이기로 하였다.

1) End-to-end GPT 처리: GPT vs. Gemini

보유 카드의 크롤링한 혜택 정보 전부를 GPT와 Gemini에 입력하였다.

• GPT 기술 검증을 위해, 임의로 선택된 4개의 카드들의 혜택을 분석하여 20개의 테스트 키워드(결제처)와 그 예상 결과를 표에 작성하였다.
  GPT 모델에 어떤 행동을 할지 지정하는 system은 다음과 같이 작성하였다.

  너는 사용자의 결제 금액과 전월실적을 고려해 결제처에 가장 좋은 카드와 해당 혜택을 20글자 이내로 요약해 알려주는 카드 추천 보조야.
  혜택 정보에서 각 카드는 \n로 구분되고, 카드의 분야별 혜택은 ###로 구분돼

  이후 user가 내가 가진 카드 혜택이뭐야? 라고 하면, 챗봇에 해당하는 assistant가 각 카드들의 정보를 나열하였다.
  그 결과, 유의미한 결과값을 출력하며 높은 정확도를 보이는 것을 확인할 수 있었다. 하지만, 카드를 여러 장 활용해 test하던 도중 `InvalidRequestError: This model's maximum context length is 16385 tokens.` 에러를 마주치게 된다. GPT로 보낼 수 있는 context의 길이가 **최대 16385 토큰**이라는 것이다. GPT에 요청을 보낼 수 있는 메시지의 길이는 제한되어 있었고, 원스에서 사용자가 등록하는 카드 수에는 제한이 없고 몇몇 카드는 매우 긴 혜택 정보와 설명들까지 담고있기 때문에, 요약되지 않은 여러 개의 카드 혜택 정보를 한번에 입력하는 것이 불가능하였다.
  
  

• Gemini 생성형 ai를 통해 기술을 검증해보던 것은 2024년 1월이었고, 마침 2023년 12월에 생성형 ai인 Gemini가 출시되어 Gemini를 통해 카드 추천을 시도해보았다. 또한 Gemini는 최대 토큰 수가 30720 tokens이기에, 메시지 길이의 제한에서는 어느정도 자유로워질 수 있었다.
  Gemini 공식문서를 참고한 결과 구조화된 프롬프트가 일관된 출력 형식을 따르도록 하거나 모델이 수행하기를 원하는 작업을 말로 설명하기 어려울 때 유용하다는 점이 적합해 보였다. 동일하게 system prompt를 입력해주고, 예시로 input, output을 2개씩 써주었다. test해본 결과, CGV를 입력하였지만 "커피10%" 혜택을 출력하거나, 카드들 중 가장 혜택이 적은 카드를 출력하며, 전혀 카드들의 혜택을 이해하지 못하고, 계속해서 관련없는 답변을 반환하였다. system이 추상적이기 때문에 이러한 결과가 도출될 수 있다고 생각하여, system을 더 자세하게 수정하여 다시 기술 검증을 해 보았다. 새로 작성한 system은 다음과 같다. ``` 줄바꿈으로 구분되어 입력된 여러 카드들 중 어떤 카드의 어떤 혜택이 결제처에서 최고의 할인을 가져다줄지 골라주세요.\n 결제처, 결제금액, 여러 카드의 정보가 쉼표로 구분되어 입력됩니다. 입력된 결제처는 브랜드일수도 특정 분야일수도 있으니 카드 헤택 정보에서 관련이 있는 분야와 브랜드를 모두 잘 찾아야 합니다. 카드 정보는 여러 개의 {카드이름, 카드 고유 번호, 혜택 문자열}로 이루어집니다. 각 카드들은 줄바꿈으로 구분되어있으니 줄이 바뀐다면 그 다음 카드의 정보를 나타낸다는 것을 기억하세요. 한 카드 안에서 분야별 혜택은 ###로 구분되어 있습니다. 각각의 카드가 입력된 결제처에 해당되는 혜택을 가지고 있다면 할인 금액을 계산하고, 여러 카드 중 가장 할인 금액이 큰 카드의 고유번호, 결제처에 해당되는 혜택의 20글자 이내 요약 내용, 해당 혜택 적용 시 받게되는 할인 금액을 쉼표로 구분해 출력하세요. 할인이 n원이라고 써있으면 n원, n%라고 써있으면 결제금액의 n%를 직접 계산해야 합니다. ``` 여러 입력으로 테스트를 해보던 중 gemini가 카드들이 여러장이고, 각각의 혜택이 존재함을 인식하지 못하고 있다는 느낌이 들어, 두가지 카드의 혜택 정보를 순서만 바꾸어 입력해 본 결과 다음과 같은 결과가 출력되었다.무조건 앞에 있는 카드의 혜택을 찾아 출력한다.
  

이러한 과정을 통해 Gemini는 카드 추천에 적합하지 않다고 판단하여, GPT를 사용하기로 결정하였다.

2) GPT-3.5 Turbo vs. GPT-4

GPT를 선택하였다면, 다음으로 구체적으로 GPT의 어떤 모델을 사용할지 결정해야 한다.

GPT-4가 가장 최신 버전으로, GPT-3.5보다 더 높은 정확도와 언어 이해력을 가지고 있지만, 일반적으로 더 느린 응답 시간을 가진다.

실시간 추천 시스템에서 응답 시간은 매우 중요한 요소이기 때문에, 각 모델을 사용했을 때 걸리는 시간을 비교해보았다. 로컬에서 python으로 호출해 걸리는 시간은 실제 서비스와는 다를 수 있기 때문에, 백엔드 서버에서 각 모델을 활용해 호출 했을 때의 응답 시간을 확인하였다.

또한, GPT-4모델과 GPT-3.5모델은 가격 차이도 크다.

따라서 비용과 성능의 균형을 맞춘 GPT-3.5 Turbo모델을 선택하였다.

3) 카드 혜택 요약

Gemini 대신 정확도가 높은 GPT 모델을 사용하되, 토큰이 부족한 문제를 해결하기 위해 크롤링한 결과를 요약하여 카드 추천을 진행하기로 하였다.

카드 혜택 요약 또한 GPT를 이용하였다. 처음 작성한 system은 다음과 같다.

너는 크롤링한 카드의 혜택 정보을 분야별로 정리하는 데이터 추출 전문가야. 
데이터를 다음 키로 JSON 형식의 list로 제공해 줘: 혜택 분야-benefit_field, 혜택 정보-content. 

예를들어, ‘<대중교통(버스, 지하철)>    [대중교통(버스, 지하철)10% 청구할인] 대중교통(버스, 지하철)10% 청구할인 표의 칼럼은 
서비스 구분, 전월 이용실적 구간에 따른 할인률, 전월 이용실적 구간에 따른 월 할인한도, 1구간(40만원이상) 로 이루어져 있습니다.
표의 1번째 행은 대중교통(버스 지하철) 청구할인, 10%, 7천원 로 이루어져 있습니다.대상 : 버스, 지하철택시, 시외버스, 고속버스 제외
버스/지하철 요금할인은 실제 카드 사용일이 아닌 이용대금명세서상 기재된 이용일을 기준으로 서비스 제공
<편의점(GS25, CU)>[편의점(GS25, CU)10% 청구할인] 편의점(GS25, CU)10% 청구할인 표의 칼럼은 서비스 구분, 
전월 이용실적 구간에 따른 할인률, 전월 이용실적 구간에 따른 월 할인한도, 1구간(40만원이상) 로 이루어져 있습니다.
표의 1번째 행은 편의점(GS25 CU) 청구할인, 10%, 5천원 로 이루어져 있습니다.대상 : GS25, CU백화점, 대형쇼핑몰, 
역사(지하철, 철도, KTX 등) 내 입점한 가맹점의 경우, 할인대상에서 제외될 수 있음’은 
‘[{“benefit_field”: “대중교통(버스,지하철)”,“content”: “10%할인, 최대 7천원“},
{“benefit_field”: “편의점(GS25, CU)”,“content”: “10%할인”}]’로 요약해줘 

하지만 여러 카드를 요약해 보니, 터무니없는 결과를 반환한 카드들이 있어 분석해 보았다.

아래 사진처럼, 카드의 혜택 정보에 표가 존재하는 경우가 있다. 크롤링 할 때, table은 아래의 코드를 통해 표임을 알리고, "표의 칼럼은 ~ 로 이루어져 있습니다." "행은 ~ 로 이루어져 있습니다"등의 문구를 붙여 표를 기술하였다.

def findtableortext(str): # 테이블 추출
    try:
        thead = str.find('thead').findAll('th')
        sentence = " 표의 칼럼은 "

        for columnname in thead:
            columnname=columnname.text
            sentence+=columnname.replace('\n','')+", "
        sentence=sentence[0:-2]
        sentence += " 로 이루어져 있습니다."
        j=1
        tbodies = str.find('tbody').findAll('tr')

        for tbody in tbodies:

            tds = tbody.findAll('td')
            sentence += f"표의 {j}번째 행은 "

            for td in tds:
                sentence+=td.text.replace(",","").replace('\n','')+", "
            sentence=sentence[0:-2]
            sentence += " 로 이루어져 있습니다."
            j+=1

        return sentence
    except:
        sentence=str.text.replace('\n', '')
    return sentence

하지만 해당 표는 셀들이 병합되어 있기 때문에, html을 한줄씩 읽었을 때, 병합된 칸은 한번만 읽히고, 제대로 데이터를 수집할 수 없다.

따라서 다음과 같은 요약 결과가 생성된다. 셀을 병합한 경우를 모두 처리하는 코드를 작성하는 것은 불가능하고, 병합되지 않은 경우에도 gpt가 말로 표현된 표를 잘 이해하지 못하고 있기 때문에, table은 html을 그대로 전체 혜택에 포함하도록 크롤링 코드를 수정하였다. 크롤링한 결과는 다음과 같다.

[  청구 할인 서비스 ] <table cellpadding="0" cellspacing="0" class="tblH mT20"> 
<caption>청구 할인 서비스</caption> <thead> <tr> <th scope="col">구분</th> <th colspan="2" scope="col">세부 영역</th> 
<th scope="col">할인율</th> <th scope="col">월 할인한도</th> <th scope="col">전월 실적</th> </tr> </thead> 
<tbody> <tr> <td>대중교통 할인</td> <td colspan="2">버스, 지하철</td> <td>10%</td> 

...생략...

합 계</td> <td>1만5천원</td> <td></td> </tr> </tbody> </table> 
대중교통 : 택시, 시외버스, 고속버스, 공항버스 제외* 버스/지하철 요금할인은 실제 카드 사용일이 아닌 이용대금명세서 상 기재된 
이용일을 기준으로 서비스 제공 실적 유예 제공 : 최초 카드 사용 등록 후 다음 달 말일까지 전월 실적 조건 미달 시에도 서비스 제공 

이를 요약하면 이러한 결과가 나온다. 이전과는 다르게, 셀이 병합된 커피·약국·편의점·영화 모두 혜택 정보가 잘 담겨있는 모습이다.

이에 따라 예시로 표가 들어있던 system 또한 변경하였다. GPT가 요약은 잘 하기에, input예시는 제거하고 output의 예시를 들어 형식을 고정시키기 위해 노력하였다.

입력된 데이터를 key를 가지는 list로 요약하여 제공해 줘 [benefit_field, content]\\
nbenefit_field는 혜택의 분야, content는 혜택 할인율 정보를 핵심만 나타냄.\\
혜택과 관련없는 내용은 지우고, 혜택 분야는 최대한 세분화 할 것\\ 
output 형식의 예시는 다음과 같음     
[{\n  \"benefit_field\": \"편의점\",\n  \"content\": \"4대 편의점 이용 시 10% 적립\"\n },\n
{\n  \"benefit_field\": \"커피 업종\",\n  \"content\": \"10% 적립\"\n },\n 
{\n  \"benefit_field\": \"해외 이용금액\",\n  \"content\": \"1% 적립\"\n },\n   
{\n  \"benefit_field\": \"디지털 구독(넷플릭스, 쿠팡플레이)\",\n  \"content\": \"10% 적립\"\n},\n} ]

예시를 구체적으로 명시하고 출력 형식을 json으로 지정하니, 카드 혜택 정보가 정형화되고 단순한 혜택 정보를 포함하게 되었다.

4) 입·출력 형식 JSON

3월 한달에 걸쳐 카드 혜택 정보 요약의 구현을 완료한 후, 다시 카드 추천 구현을 시작하였다.

• 첫번째 시도 요약 후 첫번째로 test한 system은 다음과 같다.

  결제처, 결제금액, 카드들의 혜택 정보를 Input으로 하여 결제처에서 최적의 혜택을 누릴 수 있는 카드 번호, 혜택 정보, 할인 금액을 알려주어야 함.\n카드들의 혜택 정보에서 각 카드는 ‘/////’ 로 구분되고, 각 카드가 입력된 결제처에 해당되는 혜택을 가지고 있다면 할인 금액을 계산하고, 여러 카드 중 가장 할인 금액이 큰 카드의 고유번호 숫자, 결제처에 해당되는 혜택 정보 요약 텍스트(특수문자 없어야 함), 해당 혜택 적용 시 받게되는 할인 금액 숫자를 쉼표로 구분하여 제공해야 함. \n 

  user에 넣는 카드 혜택 정보는 이전과 다르게 요약한 혜택 정보로, 요약된 내용을 ‘/////’로 구분하여 입력하였다. 그 결과, 결제처에 따른 카드 추천 결과가 예상되로 출력되었으며, 전보다 높은 정확도를 확인할 수 있었다.

• JSON 형식 도입 카드 혜택을 요약하는 과정에서 JSON같은 key, value 형식을 지정하므로써 출력 형태를 고정하고 원하는 결과를 얻는데 도움이 된다는 교수님의 조언을 받았었다. 이는 카드 혜택 요약 과정에서 큰 도움이 되었다.
  카드 추천 또한 JSON 형식을 사용하면 더 높은 정확도와 정형화된 형식을 얻을 수 있겠다는 생각이 들었고, 바로 적용해 보았다. (왜 진작에 json을 사용하지 않았나 아쉽기도 했다:)))
  반환값의 json 형식을 지정한 system은 다음과 같다.

  결제처, 결제 금액, 카드들의 혜택정보를 Input으로 하여, 결제처에서 최적의 혜택을 누릴 수 있는 카드를 ”카드번호”, 
  “혜택 정보”, “할인 금액”을 키로 가지는 json형식으로 반환. output에 ``` 붙이지 말 것.\
  각 카드가 입력된 결제처에 해당되는 혜택을 가지고 있다면 할인 금액을 계산하고, 여러 카드 중 가장 할인 금액이 큰 카드를 찾아낼 것\
  ”카드번호” 는 해당 카드의 '카드 고유 번호',   “혜택 정보”는 결제처에 해당되는 혜택 정보 요약 텍스트(특수문자 없이 20자 이내)

  결제처와 결제금액, 카드들의 혜택 정보 또한 JSON으로 제공하였다. 기존에 각 카드들의 혜택정보를 독립적으로 이해하지 못하는 경우에 대해, Json의 list로 카드들을 분리하는 것이 큰 도움이 될 것이라 예상되었다.
  
  GPT에 전송되는 입력인 user 프롬프트는 다음과 같다.

  {
    ”결제 금액”: 20000, 
    “결제처”: “CU”, 
    “카드들의 혜택 정보”:[
        {
            ”이름”: “다담카드(비 OTP)”, 
            “카드 고유 번호” : 696, 
            “혜택”: “...생략...”
        }, 
        {
            ”이름”: “My WE:SH 카드”, 
            “카드 고유 번호” : 649 ,  
            “혜택”: “...생략...”
     ]
  }

  요청을 보낸 결과, json으로 정형화된 형식과 훨씬 정확한 카드 추천 결과가 반환되었다.

5) 파인튜닝

마지막으로, 카드 추천이라는 downstream task에 적합한 모델을 생성하기 위하여 GPT-3.5 Turbo 모델의 파인튜닝을 진행했다.

• 데이터셋 구축
  총 100개의 데이터셋 중 training dataset, validation dataset, test dataset을 각각 6:2:2의 비율로 나누어 사용했다. 데이터가 충분하지 않은 경우, 주로 이러한 비율을 선택한다.
  정확도가 높은 파인튜닝 모델을 위해 특정 결제처와 관련된 혜택을 가진 카드들을 비교하여, 가장 많은 할인을 제공하는 카드를 직접 정답으로 선택하는 방식으로 데이터셋을 생성했다.
  1인당 신용카드 보유 수는 평균 4.4장이므로, 각 데이터마다 3-5장의 카드를 가지도록 데이터셋을 구축했다. 이때 실제 카드 사용자들이 많을 것으로 예상되는 6개 카드사의 인기 카드의 비중을 높게 책정했다.
  아래의 이미지는 직접 구축한 데이터셋의 일부이며, 최종 발표 전까지 카드 추천 모델의 정확도 향상을 위해 더 많은 데이터셋을 구축할 계획이다.

  

• 파인튜닝 위에서 생성한 training dateset과 validation dataset을 이용해 모델 학습을 위한 json 파일을 생성했다.해당 프롬프트 string를 생성하기 위해, 임의의 api를 만들어 큰 도움을 받았다. 결제처, 결제금액, 사용할 카드들과 함께 예상 답변인 카드 id와 혜택 정보, 할인 금액을 입력하면 이를 프롬프트 형식에 넣어서 반환하게 하였다.구체적인 파인튜닝 구현 코드는 아래에서 설명하겠다.

• 파인튜닝 결과 확인 OpenAI API 사이트의 Playground에서 파인튜닝한 모델의 id를 선택하여, 해당 모델을 테스트해 볼 수 있다.
  다음 이미지는 앞서 생성한 파인튜닝 모델에 ‘이마트24’에서 최대 할인을 받을 수 있는 카드 추천을 요청한 결과이다.보유 중인 ‘신한카드 SOL 트래블 체크’, ‘#MY WAY(샵 마이웨이) 카드’, ‘LIKIT all 체크카드’ 중에 서 ‘이마트24’와 관련된 혜택을 찾은 후, ‘#MY WAY(샵 마이웨이) 카드’를 사용하면 가장 많은 할인을 받을 수 있다는 결과가 반환되었다.

• 파인튜닝 성능 측정 구체적으로 20개의 test dataset에 대하여, 파인튜닝된 모델과 파인튜닝 없이 gpt-3.5-turbo- 0125 모델에 프롬프트로 요청을 보내 테스트한 결과를 비교해 보았다. 아래 표에서 빨간색 배경으로 표시한 부분이 잘못된 결과를 응답한 경우를 나타낸다.

결과를 분석해 보면, 파인튜닝된 모델은 20개의 test dataset에 대하여 예상과 다른 결과가 3번 출력되었다. 반면, 프롬프트의 경우, 11번의 오류가 발생하였다.

즉, 파인튜닝 없이 프롬프트만을 사용할 경우, 요청을 보낼 때마다 반환되는 결과가 달라지며 모든 카드의 혜택을 정확히 이해하지 못하여 할인 금액이 가장 크지 않은 카드를 추천하는 등 잘못된 응답 결과가 발생하였다. 특히, 대중교통과 관련된 키워드를 입력할 경우에 ‘지하철’, ‘버스’ 등의 단어들을 교통 카테고리와 연관짓지 못하여 전혀 다른 분야의 혜택을 반환하는 것을 발견했다. 또한, 해당 카드가 가지지 않은 혜택 정보를 출력하거나, 올바른 혜택을 찾아냈음에도 할인 금액을 잘못 계산하는 오류도 발견되었다.

즉, 파인튜닝된 모델을 사용할 경우에 카드 추천 결과의 정확도가 높다는 것이 검증되었다.
따라서 Once의 주요 기능을 개발하기 위해 파인튜닝된 GPT-3.5 Turbo 모델을 최종 선택해 기술을 구현했다.

프로젝트 구현 개요

위의 과정을 거쳐 선택된 카드 추천 모델을 구현하기 위한 구체적인 기술과 코드들에 대해 설명하겠다.

1. 카드 혜택 정보 크롤링
2. 크롤링 자동화
3. 카드 혜택 정보 요약
4. 크롤링 자동화
5. 카드 추천 데이터셋 생성
6. GPT 파인튜닝
7. Spring Boot에서 GPT 호출

1. 카드 혜택 정보 크롤링

크롤링이란?

Web상에 존재하는 Contents를 수집 하는 작업이다. (프로그래밍으로 자동화 가능)

원스의 크롤링

원스에서는 카드들의 혜택 정보를 직접 크롤링해, 정확한 최신 버전의 카드 혜택을 가져온다.
우선적으로 국민 카드, 현대 카드, 삼성 카드, 신한 카드, 롯데 카드, 하나 카드의 카드들을 활용하며, 추후 서비스를 발전시키며 이외의 카드사들도 연결할 예정이다.

6개 카드사의 혜택 정보를 3명의 팀원이 2개씩 나눠 크롤링을 진행했으며, 나는 국민 카드와 롯데 카드의 크롤링을 담당하였다.

html의 구조를 파악하여 원하는 값을 추출하는 과정은 이전 포스트에 있어 생략하고, 추가되거나 발전된 내용을 소개하겠다.

국민 카드 혜택 정보 크롤링

csv로 데이터 저장

카드들의 정보는 csv로 저장한 뒤 db에 접속해 한번에 저장한다.

csv의 열이 될 정보들의 리스트를 선언한다

name = []
img_url = []
benefits = []
created_at = []

국민카드의 경우 전체 카드를 카테고리에 따라 분류해 제공하는데, 카테고리마다 중복되는 카드들이 존재한다. 이는 name 리스트 안의 중복여부에 따라 크롤링 진행 여부를 결정하여 해결한다.

        cardName=card_bs.find('h1',{'class','tit'}).text      # 카드 이름 추출

        if cardName not in name:     # 카드 존재 여부 확인 
            name.append(cardName)
            print(datetime.now().strftime("%Y-%m-%d %H:%M:%S")+" ["+cardName+"] --- 웹 페이지에 접속 중... ")
        else:                         # 이미 존재하는 경우 continue(크롤링 진행하지 않음)
            print(datetime.now().strftime("%Y-%m-%d %H:%M:%S")+" ["+cardName+"] --- 이미 존재하는 카드입니다 ")
            continue

카드별로 크롤링 완료할때마다 위에 정의한 list에 append한다.

모든 카드들의 크롤링이 완료되면, 데이터들을 모아 csv로 저장한다.

data = {"card_company_id":card_company_id, "name" : name, "img_url" : img_url, "benefits": benefits, "created_at": created_at,"type":type}
df = pd.DataFrame(data)

df.to_csv("./credit_benefit.csv", encoding = "utf-8-sig", index=False)

저장된 csv는 다음과 같다.

롯데 카드 혜택 정보 크롤링

S3 이미지 저장

다른 카드 사이트의 경우 일관되게 가로로 누운 카드 모양이거나, 세로로 긴 카드 모양을 가지고 있어 카드사 종류에 따라 처리하면 되었다.

하지만 롯데 카드 사이트는 카드들 이미지의 가로/세로 비율이 무작위로 가로되어있다는 문제점이 존재했다.

이에 따라 크롤링 과정에서 이미지가 세로인 경우에만 aws S3에 변환해 저장한 뒤 해당 url을 카드 이미지로 사용하였다.

• S3 연결

  config = configparser.ConfigParser()
  config.read('/crawling/config.ini')
  AWS_S3_ACCESSKEY = config['s3']['AWS_S3_ACCESSKEY']
  AWS_S3_SECRETKEY = config['s3']['AWS_S3_SECRETKEY']
  AWS_S3_BUCKET = config['s3']['AWS_S3_BUCKET']
  AWS_S3_REGION = config['s3']['AWS_S3_REGION']

  S3의 ACCESSKEY, SECRETKEY등의 정보는 인터넷 상에 공개되어서는 안되기 때문에, config.ini파일로 분리하였다.

  def s3_connection():
    try:
        s3 = boto3.client(
            service_name="s3",
            region_name="ap-northeast-2",
            aws_access_key_id="{AWS_S3_ACCESSKEY}",
            aws_secret_access_key="{AWS_S3_SECRETKEY}",
        )
    except Exception as e:
        print(e)
    else:
        print("s3 연결 성공")
        return s3

  • 이미지 저장 함수 호출 크롤링을 통해 얻은 카드 이미지의 url을 매개변수로 넣어 s3_put_object함수를 호출하였다.

    cardImg= "https:" + card.find('img').get('src')
    img_url.append(s3_put_object(cardImg,cardNo))

  • s3_put_object 함수 받은 이미지 url을 직접 이미지 객체로 변환한 뒤, 이미지의 가로폭이 세로폭보다 짧은 경우에만 90° 회전한 뒤 바이너리 스트림에 저장하였다.이미지를 AWS S3에 업로드한 뒤, 해당 url을 반환하였다. 이미지가 가로로 되어있다면, 그대로 받은 이미지 url을 반환하였다.

    from io import BytesIO
    from PIL import Image
    import boto3
    

  def s3_put_object(cardImg,cardNo): try:

    data = urlopen(cardImg).read()
    img = Image.open(BytesIO(data))
    w, h = img.size
    if w < h : # 이미지가 세로인 경우
        img = img.rotate(90, expand=True)            # 회전
  
        image_fileobj = BytesIO()
        img.save(image_fileobj, format='PNG')
        image_fileobj.seek(0)
  
        # S3에 업로드
        s3.upload_fileobj(image_fileobj, "{AWS_S3_BUCKET}", "lottecard/"+cardNo+".png",ExtraArgs={"ContentType": "image/jpg", "ACL": "public-read"})
        return "https://{AWS_S3_BUCKET}.s3.{AWS_S3_REGION}.amazonaws.com/lottecard/"+cardNo+".png"
    else:
        return cardImg

  except Exception as e:

    return False

csv데이터 RDS에 업로드

csv에 저장된 데이터는 일괄적으로 RDS에 업로드하였다. 코드의 재사용성을 높이기 위해, 카드 회사 이름과 신용카드/체크카드를 명령줄인수로 받아 사용하였다. 즉, 서로 다른 코드로 모인 각 카드사의 카드 혜택 정보는 모두 이 코드를 통해 rds에 저장된다.

• rds 연결

  config = configparser.ConfigParser()
  config.read('./crawling/config.ini')
  
  db_host = config['database']['host']
  db_user = config['database']['user']
  db_password = config['database']['password']
  db_database = config['database']['database']
  db_charset = config['database']['charset']

  rds또한 s3와 마찬가지로, config.ini파일을 통해 계정정보를 보호한다.

  connection = pymysql.connect(
    host=db_host,
    user=db_user,
    password=db_password,
    database=db_database,
    charset=db_charset,
    cursorclass=pymysql.cursors.DictCursor
  )

• csv 읽기

  with open(f'./{csv_file}_benefit.csv', 'r', encoding='utf-8') as csvfile:
     csvreader = csv.reader(csvfile)
     next(csvreader)
     for row in csvreader:
    card_company_id, name, img_url, benefits, created_at, type = row

  for문으로 모든 row에 접근중이며, card_company_id, name, img_url, benefits, created_at, type변수에 현재 row의 값들이 들어있다.

• rds에 삽입

  insert_query = """
    INSERT INTO card
    (card_company_id, name, img_url, benefits, created_at, type)
    VALUES (%s, %s, %s, %s, %s, %s)
    """
    cursor.execute(insert_query, (card_company_id, name, img_url, benefits, created_at, type))

  원하는 동작의 mysql문을 작성한 뒤, cursor.execute()로 실행할 수 있다.

크롤링 최종 코드는 깃허브에서 확인 가능하다.

2. 크롤링 자동화

카드들의 부가서비스는 간혹 변경되기도 하고, 카드 자체가 단종되기도 한다. 이러한 데이터의 변화를 원스 서비스의 데이터 베이스에 즉각적으로 반영하는것이 중요하다.

따라서 주기적으로 카드 혜택 업데이트를 진행한다.

각 카드들의 혜택 정보 이외에 카드사별 이벤트성 혜택 또한 크롤링 하여 사용한다. 카드의 혜택 정보는 주 1회, 이벤트성 혜택은 매일 업데이트를 진행한다.

가장 핵심인 카드 혜택 업데이트를 설명하겠다.

스케쥴링

Spring Boot에서는 @Scheduled 어노테이션을 이용하여 스케쥴러를 구현할 수 있다.

먼저, @Scheduled를 사용하기 위해 Application 클래스에 @EnableScheduling을 추가해준다.

@SpringBootApplication
@EnableScheduling
public class OnceApplication {

    public static void main(String[] args) {
        SpringApplication.run(OnceApplication.class, args);
    }

}

스케쥴러는 스프링 빈에 등록되어야 한다. @Service 애노테이션을 이용해서 빈에 등록하였다.

@Service
@Slf4j
@RequiredArgsConstructor
public class CrawlingService {

    // 매주 월요일 00:00 카드 혜택 크롤링
    @Scheduled(cron = "0 0 0 ? * 1")
    public void cardCrawling() throws CustomException {
        String[] cardCompanyList = {"Kookmin", "Hana", "Samsung", "Shinhan", "Lotte", "Hyundai"};
        for (String cardCompany : cardCompanyList){
            crawling(cardCompany);
        }
    }
   }

@Scheduled 속성에는 크게 fixedDelay, fixedRate, initDelay, cron 등이 있는데, 난 Scheduling의 정규 표현식인 cron 표현식을 사용하였다.

cron 표현식 cron은 아래와 같이 총 6개의 필드로 구성된다.

특수 문자

    private static void crawling(String cardCompany) throws CustomException{
        LOG.info(cardCompany+" 크롤링 시작");
        executeFile(cardCompany+"/credit.py");
        executeInsertData(cardCompany,"Credit");
        executeFile(cardCompany+"/debit.py");
        executeInsertData(cardCompany,"Debit");
    }

crawling함수에서는 크롤링 시작을 알리는 로그를 찍은 뒤, 신용카드 크롤링 코드 실행->DB에 반영->체크카드 크롤링 코드 실행->DB에 반영의 과정을 거친다.

Spring Boot에서 python 실행

스프링 부트는 Java 프레임워크이기 때문에, python을 실행하기 위해 몇가지 설정이 필요하다.

우선, 크롤링 코드(python)는 src/main/resources/crawling/{카드사 이름}/경로 안에 위치한다.

1) 도커 설정

스프링부트로 구현된 백엔드 서버는 도커를 통해 컨테이너화하고, 깃허브 액션을 통해 CI/CD 파이프라인을 구축하여 배포를 자동화하고 있다. 즉, EC2 서버에 SSH로 접속했을 때 애플리케이션 파일이 서버 파일 시스템에 직접 보이지 않고 도커 컨테이너 내부에 애플리케이션 파일이 존재한다.

스프링 부트 JAR 파일 내에서 Python 파일을 직접 실행하는 것은 지원이 되지 않기 때문에, jar파일이 아닌 도커 환경에서 python을 실행해야 한다. 이를 위해 python 관련 라이브러리 설치, 크롤링 코드 도커 안에 복사의 과정이 필요하다.

이 작업은 도커파일에서 진행된다. python 실행과 관련된 코드들만 가져와 설명하겠다.

RUN apt-get update && apt-get install -y python3 python3-pip wget unzip curl

파이썬을 설치한다.

RUN wget https://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_114.0.5735.198-1_amd64.deb && \
    apt -y install ./google-chrome-stable_114.0.5735.198-1_amd64.deb

RUN wget -O /tmp/chromedriver.zip https://chromedriver.storage.googleapis.com/114.0.5735.90/chromedriver_linux64.zip && \
     unzip /tmp/chromedriver.zip -d /usr/bin && \
     chmod +x /usr/bin/chromedriver

동적 크롤링을 위해 크롬을 설치해야 한다. chromedriver과 google-chrome 모두 다운로드 해준다.

COPY ./requirements.txt .
RUN pip install --no-cache-dir --upgrade pip && \
    pip install -r requirements.txt

크롤링을 위해 필요한 python의 라이브러리가 정리된 requirements.txt파일을 가져와 모두 install 해준다.

COPY ./src/main/resources/crawling /crawling

깃허브의 크롤링 코드들을 도커 안에 그대로 copy해준다.

이제 도커 안에서 python 파일을 실행할 준비가 완료됐다.

2) 크롤링 코드 수정

크롤링 코드들은 로컬에서 돌릴때와는 파일의 위치가 달라졌다. 이에 따라 python 코드 안에서 csv를 저장하고, 가져오기 위해 명시된 경로 또한 변경해 주어야 한다 ./credit_benefit.csv -> /app/src/main/resources/crawling/Kookmin/credit_benefit.csv 그냥 바로 가져다 쓰던 파일들 앞에 모두 /app/src/main/resources/crawling/라는 도커 안에서의 절대 경로를 적어준다.

웹 드라이버를 사용하기 위해 로컬에서는 다음과 같이 코드를 작성하였다.

chrome_options = Options()
chrome_options.add_argument('--headless')
chrome_options.add_argument('--disable-web-security')

driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()), options=chrome_options)

하지만 도커에서 돌리기 위해서는 다음과 같이 option을 추가하고, Service를 위해 실행 경로를 명시해 주어야 한다.

chrome_options = Options()
chrome_options.add_argument('--headless')
chrome_options.add_argument('--no-sandbox')
chrome_options.add_argument("--disable-dev-shm-usage")

service = Service(executable_path=r'/usr/bin/chromedriver')
driver = webdriver.Chrome(service=service,options=chrome_options)

3) spring boot에서 python 실행

Java의 ProcessBuilder를 활용하면 다른 외부 프로세스를 실행시키거나 컨트롤 할 수 있다.

ProcessBuilder pb = new ProcessBuilder("python3", "-u", "/crawling/"+path);
pb.redirectErrorStream(true);
Process p = pb.start();
BufferedReader br = new BufferedReader(new InputStreamReader(p.getInputStream()));

String line;
while ((line = br.readLine()) != null) {
    // 실행 결과 처리
    LOG.info(line);
}

p.waitFor();

이 작업을 완료하면, 월요일 00:00이후 EC2 서버에 들어가 sudo docker logs web명령어를 입력해 다음과 같이 크롤링 자동화가 진행되고 있는 것을 확인할 수 있다.

트러블 슈팅

크롤링 자동화는 전체 개발 과정중에서도 가장 큰 이슈 중 하나였다. 로컬에서는 어렵지 않게 구현하였지만, 서버에서 실행하는 것은 차원이 다른 문제였다. 수많은 오류를 겪었지만 큰 에러들을 정리해보겠다

1) csv 파일 위치 서버에서 돌아갈 때 깃허브에 있는 파일이 자꾸 없다고 오류가 떠서 당황스러웠던 기억이 있다. docker exec -it web sh명령어를 통해 직접 도커 컨테이너의 쉘로 접속하고, jar tf app.jar로 파일이 존재하는지 확인했다. 결과적으로는 jar 안이 아닌 도커 컨테이너 안에서 python을 실행해 해결할 수 있었고, 그러기 위해 도커에 crawling파일들을 복사하였다.

2) webdriver 동적 크롤링인 국민 카드의 크롤링까진 돌아가는 것을 확인했는데, 웹드라이버를 사용하기 위해 수많은 수정과 커밋과 커밋의 reset과(^^) 시도를 했다.

• DevToolsActivePort file doesn't exist chrome_options.add_argument('--headless') chrome_options.add_argument('--no-sandbox') 옵션 추가

• WebDriverError: unknown error: session deleted because of page crash chrome_options.add_argument("--disable-dev-shm-usage")옵션 추가

• chrome not reachable selenium.common.exceptions.SessionNotCreatedException: Message: session not created: This version of ChromeDriver only supports Chrome version 114 chromedriver와 google-chrome의 버전이 맞지 않아 진행이 되지 않았다. chromedriver --version google-chrome --version 명령어로 버전을 확인하였고, 안정적인 버전을 찾아 114.0.5735 버전으로 다운로드했다.

• session not created service = Service(executable_path=r'/usr/bin/chromedriver')로 웹 드라이버 절대경로로 호출

3) python 모든 설정이 된 것 같은데, python이 실행되지 않았다. ProcessBuilder pb = new ProcessBuilder("python", "-u", "/crawling/"+path); 코드를 ProcessBuilder pb = new ProcessBuilder("python3", "-u", "/crawling/"+path);로 수정해 해결되었다. 도커 이미지에서 Python 3이 설치된 경우, 인터프리터는 "python3"로 접근해야 할 수 있다.

3. 카드 혜택 정보 요약

월요일 00:00에 카드 혜택 정보 업데이트를 진행한 뒤, 매주 월요일 6:00에 크롤링한 헤택 정보의 요약 작업이 진행된다.

해당 service코드는 다음과 같다.

    @Scheduled(cron = "0 0 6 ? * 1")
    public void updateBenefitSummary() throws CustomException, JsonProcessingException {

        List<Card> cardList = cardRepository.findAll();

        int index = 1;
        for (Card card : cardList) {
            // 기존의 BenefitSummary 삭제
            List<BenefitSummary> existingSummaries = benefitSummaryRepository.findByCard(card);
            benefitSummaryRepository.deleteAll(existingSummaries);

            log.info("[" + card.getName() + "] - 카드 혜택 요약 중... (" + index + "/" + cardList.size() + ")");
            BenefitDto[] benefitJson = openaiService.gptBenefitSummary(card.getBenefits());

            for (BenefitDto benefit : benefitJson) {
                BenefitSummary benefitSummary = BenefitSummary.builder()
                        .benefitField(benefit.getBenefit_field())
                        .benefitContents(benefit.getContent())
                        .card(card)
                        .build();

                benefitSummaryRepository.save(benefitSummary);
            }
            index++;
        }
        log.info("전체 카드 혜택 요약 완료");
    }

모든 카드들에 대해 for문을 돌며, 기존의 요약된 혜택들 삭제하고, openaiService의 gptBenefitSummary함수를 호출해 요약을 진행한 뒤 요약된 혜택을 BenefitSummary로 저장한다.

GPT와 연결하기 위한 openaiService는 다음과 같다.

@Service
@Slf4j
@RequiredArgsConstructor
public class OpenaiService {

    @Qualifier("openaiRestTemplate")
    @Autowired
    private RestTemplate restTemplate;

    @Value("${openai.model}")
    private String model;

    @Value("${openai.api.url}")
    private String apiUrl;
}

test를 위해 gpt와 gemini모두 백엔드 서버와 연결되어 있어 여러 개의 RestTemplate 빈이 사용된다. @Qualifier("openaiRestTemplate")를 사용하여 "openaiRestTemplate"이라는 이름의 빈을 주입한다.

RestTemplate은 Spring에서 HTTP 요청을 보내고 응답을 받는 데 사용되는 클래스이다.

openai에 사용할 model과 apiUrl는 환경변수로 설정하였다.

gptBenefitSummary함수는 다음과 같다.

    public BenefitDto[] gptBenefitSummary(String benefits) throws CustomException, JsonProcessingException {

        String prompt = "입력된 데이터를 [] 사이에 주어진 key를 가지는 JSON 형식의 list로 요약하여 제공해 줘 [benefit_field, content]\\nbenefit_field는 혜택의 분야, content는 혜택 할인율 정보를 핵심만 나타냄. \\ output 형식은 다음과 같음.     [{\n     \"benefit_field\": \"편의점\",\n \"content\": \"4대 편의점 이용 시 10% 적립\"\n" +  },\n   {\n"        \"benefit_field\": \"커피 업종\",\n"   \"content\": \"커피 업종 이용 시 10% 적립\"\n   },\n  {\n  \"benefit_field\": \"해외 이용금액\",\n\"content\": \"해외 이용금액 1% 적립\"\n"   },\n {\n  \"benefit_field\": \"디지털 구독\",\n  \"content\": \"디지털 구독 영역 이용 시 10% 적립\"\n },\n {\n  \"benefit_field\": \"One Pick 쇼핑몰\",\n \"content\": \"One Pick 온라인 쇼핑몰 가맹점 최대 3천 포인트 적립\"\n"  } ]";

        // gpt 요청 보내는 부분
        OpenaiChatRequest request = new OpenaiChatRequest(model, prompt, benefits);
        OpenaiChatResponse response = restTemplate.postForObject(apiUrl, request, OpenaiChatResponse.class);

        if (response == null || response.getChoices() == null || response.getChoices().isEmpty()) {
            throw new CustomException(ResponseCode.FAILED_TO_OPENAI);
        }

        String result = response.getChoices().get(0).getMessage().getContent();

        ObjectMapper objectMapper = new ObjectMapper();
        BenefitDto[] benefitJson = objectMapper.readValue(result, BenefitDto[].class);

        return benefitJson;
    }

시스템 프롬프트에 해당하는 prompt와 유저 프롬프트에 해당하는 benefits, GPT 모델을 OpenaiChatRequest에 넣어 GPT에 전달할 요청 객체를 생성한다.

RestTemplate을 사용하여 GPT에 POST 요청을 보낸다. 이 요청은 apiUrl로 지정된 엔드포인트에 요청을 전송하고, 요청 본문으로는 OpenaiChatRequest 객체를 사용한다. 응답으로는 OpenaiChatResponse 객체가 반환된다.

요청에 대한 응답을 처리하고 예외가 발생하지 않았다면 결과를 가공하고, ObjectMapper를 사용하여 JSON 형식의 문자열을 BenefitDto 배열로 변환한다.

최종적으로 요약된 혜택 데이터를 나타내는 BenefitDto 배열을 반환한다.

4. 카드 추천 데이터셋 생성

카드 추천은 결제처 / 결제금액 / 보유카드목록을 입력으로 가지고 최대혜택카드id / 해당혜택요약 / 할인금액을 출력한다.

현재 데이터의 양과 기술로는 카드 추천 모델의 training을 위한 데이터를 직접 만드는 수밖에 없다.

각 카드사의 인기 카드를 중심으로 데이터 베이스에서 요약된 카드 혜택 정보들을 직접 읽어보며 데이터를 채워 나간다.

수작업이라 속도가 느린 만큼, 데이터들은 정확해야 한다. 추후 서비스를 통해 모이는 데이터를 활용할 수 있으면 좋겠다..

나는 데이터 작성을 위해, 키워드별로 해당하는 혜택을 가진 카드들을 나열하는 작업을 진행하였다. 위에 언급한대로, 각 카드사별 인기 카드의 비중을 높게 하였다.

편의점과 관련한 데이터들을 만들어보자. "편의점" 키워드의 혜택을 가진 카드들을 무작위로 배치한다. 중간중간 관련 혜택을 가지지 않은 카드들도 섞어서 값을 채워준다.

카드들의 혜택을 비교하고, 정답에 해당되는 최대혜택카드id / 해당혜택요약 / 할인금액을 도출해낸다.

ai 모델인만큼 training 데이터가 많아야 성능을 크게 높일 수 있고, test를 통해 얻게되는 정확도는 원스 서비스의 신뢰도와 직결되기 때문에, 계속해서 더 많은 데이터를 생성하는 것이 중요하다.

5. GPT 파인튜닝

만든 데이터 셋을 통해 파인튜닝 모델을 생성할 차례이다. 100개 중 60개의 training data를 ex_tran.jsonl에, 20개의 validation data를 ex_val.jsonl에 저장해 두었다.

세팅

• import 파이썬에서 사용되는 여러 가지 모듈과 라이브러리를 임포트해준다.

  import json
  import openai
  import os
  import pandas as pd
  from pprint import pprint

• OPENAI 인증키 OPENAI API 사이트에서 API KEY를 만들 수있다. 생성한 뒤 이를 복사해, 아래 {오픈AI의 API 키} 자리에 넣어주자. openai.api_key="{오픈AI의 API 키}"

데이터 파일 업로드

GPT 모델을 파인튜닝(fine-tuning)하기 위해 ex_val.jsonl와 ex_tran.jsonl을 OpenAI에 업로드한다

validation_file_name = "ex_val.jsonl"
training_file_name="ex_tran.jsonl"
training_response = openai.File.create(
    file=open(training_file_name, "rb"), purpose="fine-tune"
)
training_file_id = training_response["id"]
validation_response = openai.File.create(
    file=open(validation_file_name, "rb"), purpose="fine-tune"
)
validation_file_id = validation_response["id"]

OpenAI API 홈페이지의 storage에서 업로드된 파일을 확인하고 관리할 수 있다.

파인튜닝 작업 생성

response = openai.FineTuningJob.create(
    training_file=training_file_id,
    validation_file=validation_file_id,
    model="gpt-3.5-turbo",
    suffix="recipe-ner",
)
job_id = response["id"]

openai.FineTuningJob.create() 메서드로 GPT 모델을 파인튜닝하기 위한 작업을 생성한다. 이를 위해 훈련 데이터 파일과 검증 데이터 파일의 ID를 지정하고, 사용할 GPT 모델의 버전과 작업 이름에 접미사를 추가로 지정해준다.

파인튜닝 작업 상태/정보 조회

• 파인튜닝 작업의 진행 상태, 훈련 진행 상황을 조회한다.

  response = openai.FineTuningJob.retrieve("ftjob-iSlcJEn3kB5VOUhVDkhznTSR")
  
  print("Job ID:", response["id"])
  print("Status:", response["status"])
  print("Trained Tokens:", response["trained_tokens"])

  Job ID는 작업을 식별하고, Status는 작업의 진행 상태를 나타내며, Trained Tokens는 작업의 훈련 진행 상황을 알려준다. job의 status가 succeeded가 되었을 때 다음 작업을 진행하면 된다.

• 파인튜닝 작업에 대한 이벤트 조회,역순으로 출력

  response = openai.FineTuningJob.list_events(id=job_id, limit=50)
  

events = response["data"] events.reverse()

for event in events: print(event["message"])

반드시 필요한 부분은 아니다.작업의 상태 변화나 진행 상황을 더 자세히 추적하고 싶을 때 유용하다.

- 파인튜닝된 모델의 ID 확인
 ```python
response = openai.FineTuningJob.retrieve(job_id)
  fine_tuned_model_id = response["fine_tuned_model"]

  if fine_tuned_model_id is None: 
    raise RuntimeError("Fine-tuned model ID not found. Your job has likely not been completed yet.")

  print("Fine-tuned model ID:", fine_tuned_model_id)

OpenAI API 사이트에 접속하여 파인튜닝 현황 및 생성된 모델 결과를 확인할 수 있다.

챗봇 대화 생성

파인튜닝된 모델을 사용하여 챗봇 대화를 생성하고, 생성된 대화의 응답을 출력해보자.

responseTest = openai.ChatCompletion.create(
    model = fine_tuned_model_id,
    messages=[
        {"role": "system", "content":  system},
        {"role": "user", "content": testuser},
    ],
    temperature=0
)

print(responseTest["choices"][0]["message"]["content"])

model에 파인튜닝한 gpt모델의 id를 써주면 된다. 파인튜닝한 gpt 모델의 아이디는 ft:로 시작한다. 결과는 다음과 같다.

6. 백엔드에서 파인튜닝한 GPT 호출

이제 파인튜닝한 gpt 모델을 백엔드단에서 사용하면, 결제 전 최대 할인 카드를 찾아주는 모델은 완성이다!

이 과정은 카드 혜택 요약 과정에서 사용한 코드와 크게 다르지 않다.

메인 화면에서 사용자가 결제처와 결제 금액을 입력하면, 현재 로그인한 사용자 nowUser와 입력한 정보 keyword, paymentAmount를 매개변수로 넣어 cardRecommend()를 호출한다.

String response = openaiService.cardRecommend(nowUser, keyword, paymentAmount);

cardRecommend는 다음과 같다.

@Service
@Slf4j
@RequiredArgsConstructor
public class OpenaiService {

    @Qualifier("openaiRestTemplate")
    @Autowired
    private RestTemplate restTemplate;
    private final BenefitSummaryRepository benefitSummaryRepository;
    private final OwnedCardRepository ownedCardRepository;
    private final CardRepository cardRepository;

    @Value("${openai.model}")
    private String model;

    @Value("${openai.api.url}")
    private String apiUrl;


    // 결제할 카드 추천
    public String cardRecommend(Users nowUser, String keyword, int paymentAmount) throws CustomException {
        String prompt = "결제 금액, 결제처, 카드들의 혜택 정보를 입력으로 받아, 각 카드별로 결제처에 해당하는 혜택이 있다면 할인 금액을 계산합니다. 가장 큰 할인을 받을 수 있는 카드의 ”카드번호”, “혜택 정보”, “할인 금액”을 JSON 형식으로 반환합니다.\\\\```를 붙이지 않습니다. 결제처에 해당하는 카드의 혜택이 없거나, 결제처가 분야·브랜드명이 아니라면, 모든 value에 0을 넣어 반환합니다.\\\\”카드번호” 는 해당 카드의 '카드 고유 번호',  “혜택 정보”는 결제처에 해당되는 혜택 정보 요약 텍스트(특수문자 없이 20자 이내)를 의미합니다.";

        List<OwnedCard> ownedCards = ownedCardRepository.findOwnedCardByUsers(nowUser);

        String userInput = "{”결제 금액”: " + paymentAmount + ", “결제처”: “" + keyword + "“, “카드들의 혜택 정보“: [";
        for (OwnedCard ownedCard : ownedCards) {
            String name = ownedCard.getCard().getName();
            String id = ownedCard.getCard().getId().toString();
            Card card = ownedCard.getCard();
            userInput = userInput +"{”이름”: ”"+ name + "”, " + "”카드 고유 번호” : " + id + ", “혜택“: [ ";
            List<BenefitSummary> beneList = benefitSummaryRepository.findByCard(card);
            for( BenefitSummary benefit : beneList){
                userInput += "“"+benefit.getBenefitField()+"  "+benefit.getBenefitContents()+"“,";
            }
            userInput = userInput.substring(0, userInput.length() - 1);
            userInput += "” },";
        }
        userInput = userInput.substring(0, userInput.length() - 1);
        userInput += "]}";

        // gpt 요청 보내는 부분
        OpenaiChatRequest request = new OpenaiChatRequest(model, prompt, userInput);
        OpenaiChatResponse response = restTemplate.postForObject(apiUrl, request, OpenaiChatResponse.class);

        if (response == null || response.getChoices() == null || response.getChoices().isEmpty()) {
            throw new CustomException(ResponseCode.FAILED_TO_OPENAI);
        }

        String result = response.getChoices().get(0).getMessage().getContent();

        log.info(result);

        return result;
    }
}

for문을 돌며 사용자의 ownedCards들의 혜택 정보를 json에 삽입해 Input을 완성하고, OpenaiChatRequest에 넣은 뒤, RestTemplate을 사용하여 GPT에 POST 요청을 보낸다.

model에 파인튜닝한 모델의 id인 ft:gpt-3.5-turbo-0125:personal:recipe-ner:9Op9RHfV만 넣어주면 된다. 이는 스프링 부트의 application.properties에, 깃허브의 레포지토리 시크릿에 저장하고 있기 때문에, 파인튜닝을 추후 진행하더라도 코드의 수정 없이, 환경 변수만 다시 설정해주면 된다!

회고

기술 검증을 해가며 AI 모델을 선택하는 것부터, 구현하는 것까지 많은 것을 새롭게 시도하고 배운 것 같다. 수많은 오류들을 만나고 밤을 새웠었는데, 그 모든 내용들을 이렇게 글로 정리하니 스스로 대견하게 느껴지기도 한다. 감도 잡히지 않던 카드 추천 챗봇이 정상적으로 카드를 추천해 주고 있고, 끝나지 않을 것 같던 졸업 프로젝트가 끝이 보인다...! 남은 기간에 더 많은 데이터 셋을 구축해 완벽한 카드 추천을 구현 완료해야겠다. 원스 짱 루스 짱

DB 엔진의 유형: PostgreSQL, MySQL, MariaDB, Oracle Microsoft SQL Server, Aurora

관리형 서비스→데이터베이스 프로비저닝, 기본 운영체제 패치 완전 자동화

한 가지 단점- RDS 인스턴스에 SSH 액세스 불가

⭐️Storage Auto Scaling

활성화→RDS가 db공간 부족 감지해서 자동으로 스토리지를 확장 (db다운 x)

최대 스토리지 임곗값 설정 후 10% 미만 남으면 자동 수정

RDS Read Replica

요청이 너무 많아서 읽기를 스케일링

read replica 15개까지 생성 가능주 데이터베이스 인스턴스와 두 읽기 전용 복제본 사이에 비동기식 복제가 발생 (읽기 일관적으로 유지)

        SELECT문만 가능

        복제본 중 하나 승격시켜 db로 사용할수도있음 → 복제메커니즘 탈피, 자체적 life cycle 가짐

UseCase: 현재 내 데이터 기반으로 보고와 분석 실시할 예정, 보고 애플리케이션을 메인 rds에 연결하면 오버로드가 발생하고 생산 애플리케이션의 속도가 느려짐 → 이 workload를 위한 read replica 생성

Read Replica는 관리형 서비스로, 다른 AZ로 이동할 때 같은 region내라면 비용발생X 리전을 넘나들때는 네트워크 복제 비용 O

RDS Multi AZ

주로 재해 복구에 사용 (가용성 👆)

AZ A의 마스터 데이터베이스 인스턴스를 동기식으로 이를 AZ B에 스탠바이 인스턴스로 복제

        애플리케이션의 마스터에 쓰이는 변경 사항이 대기 인스턴스에도 그대로 복제

        하나의 DNS 이름을 갖고 통신하며 마스터에 문제가 발생시 스탠바이 데이터베이스에 자동으로 새로운 마스터

스탠바이 db는 대기목적 하나. 읽거나 쓰지x(scalingX)

⭐️RDS 읽기 전용 복제본 VS 다중 AZ:

⭐️ 재해 복구를 대비해서 읽기 전용 복제본을 다중 AZ로 설정 가능

⭐️단일 AZ에서 다중 AZ로 RDS 데이터베이스 전환이 가능, zero downtime operation(=단일 AZ에서 다중 AZ로 전환할 때 db 중지X)         기본 데이터베이스의 RDS가 자동으로 스냅샷을 생성, 새로운 스탠바이 데이터베이스에 복원

        두 데이터베이스 간 동기화 설정되어 스탠바이 데이터베이스가 메인 RDS 데이터베이스 내용을 모두 수용, 다중 AZ 설정 상태가 됨

실습에서 쓰는 SQL Electron (처음보는데 편해보임)

** 아는데…! 아는데! 자꾸 헷..갈리고 동기식/비동기식 “복제”는 어떤건지 궁금해져서

• 동기식 복제와 비동기식 복제동기 복제 와 비동기 복제 의 주요 차이점은 데이터가 복제본에 기록되는 방식입니다. 대부분의 동기식 복제 제품은 기본 스토리지와 복제본에 동시에 데이터를 씁니다. 따라서 기본 복사본과 복제본은 항상 동기화된 상태를 유지해야 합니다.
• 대조적으로, 비동기식 복제 제품은 먼저 기본 스토리지에 데이터를 쓴 다음 복제본에 데이터를 복사합니다. 복제 프로세스가 거의 실시간으로 발생할 수 있지만 복제가 예약된 방식으로 발생하는 것이 더 일반적입니다. 예를 들어, 쓰기 작업은 주기적으로(예: 5분마다) 일괄적으로 복제본에 전송될 수 있습니다.

RDS Custom

RDS에서는 기저 운영 체제나 사용자 지정 기능에 액세스 불가 / RDS Custom에선 가능

• Oracle
• Microsoft SQL Server

Custom: 기본 데이터베이스 및 OS에 액세스하여 • 설정 구성 • 패치 설치 • 기본 기능 사용 • SSH 또는 SSM Session Manager를 사용하여 기본 EC2 인스턴스 액세스

커스터마이징 하려면 Automation mode 비활성화 (ec2 인스턴스에 액세스가 가능해지면 문제발생 쉬우므로 db스냅샷 만들어두는게 좋음

RDS vs RDS Custom

RDS: 전체 데이터베이스 및 OS를 AWS가 관리

RDS Custom: 기본 OS 및 데이터베이스에 대한 전체 관리자(admin) 권한을 가짐

⭐️Amazon Aurora

AWS 고유의 기술( 오픈 소스X )

Postgres 및 MySQL과 호환

클라우드에 최적화되어 있고 여러 가지 똑똑한 최적화→ RDS의 MySQL보다 5배, Psostgres보다는 3배 높은 성능

스토리지 자동 확장 (10GB에서 시작, 12TB까지 커짐)

15개의 Read Replica 가능 (MySQL에서는 5개), 복제속도 빠름

Aurora High Availability and Read Scaling

AZ 3개에 걸쳐 기록할때마다 6개의 copies

        write에 사본 중 4개만 있으면 됨(AZ하나 작동 안해도 ㄱㅊ)

        read에는 사본 중 3개만 있으면 됨(읽기 가용성 높음)

마스터가 작동안하면 평균 30초 이내로 장애조치

백엔드 peer-to-peer replication으로 self healing

수백개의 볼륨 사용(단일볼륨에 의존x)마스터가 하나, 복제본들은 리전 간 복제 가능 , 작은 블록 단위로 자가 복구·확장

Aurora DB Cluster

마스터만 write가능- ⭐️라이터(Writer) 엔드포인트 제공 = DNS 이름 (마스터 가리킴)

        클라이언트가 라이터 엔드포인트와 상호작용, 올바른 인스턴스로 자동 리다이렉트

read replica 15개까지 자동 스케일링

자동스케일링 켜있으면 우리의 앱이 복제본이 어디있고 URL이 무엇이고 어떻게 연력하는지 파악하기 어려울수도

→ ⭐️리더(Reader) 엔드포인트

        라이터 엔드포인트와 정확히 같은 기능

        연결 로드 밸런싱에 도움

        모든 읽기 전용 복제본과 자동으로 연결

        클라이언트가 리더 엔드포인트에 연결될 때마다 읽기 전용 복제본 중 하나로 연결되며 로드 밸런싱을 도와줌

        로드 밸런싱 statement 레벨이 아닌 connection 레벨 **

** 클러스터:

컴퓨터 클러스터란 여러 대의 컴퓨터들이 연결되어서 하나의 시스템처럼 동작하는 컴퓨터들의 집합. 여러개의 객체를 하나로 모은다는 개념

DB 클러스터도 똑같은 맥락! DB 서버를 여러개 둔다고 생각하면 된다. 이에 대한 기본적인 장점은 서버 한 대가 죽어도 대비가 가능하다는 점이다.

Aurora Replicas - Auto Scaling

Custom Endpoints

Aurora 인스턴스의 하위 집합을 Custom Endpoint로 정의

사용자 지정 엔드포인트가 있는 경우, 일반적으로 리더 엔드포인트는 사용x

Aurora Serverless

사용량에 따라 자동화된 데이터베이스 인스턴스화 및 오토 스케일링을 제공

워크로드가 드물거나 간헐적이거나 예측할 수 없는 경우에 유용

용량 계획을 세울 필요X

클라이언트는 Aurora에서 관리하는 프록시 플릿과 소통

Aurora Multi-Master

continuous write availability를 원하는 경우

모든 aurora 인스턴스가 writer 노드

클라이언트가 Multiple writer endpoints로 연결 유지 가능

** endpoint가 뭔가

엔드포인트는 서비스를 사용 가능하도록 하는 서비스에서 제공하는 커뮤니케이션 채널의 한쪽 끝

→ 엔드포인트는 AWS 웹 서비스를 위한 진입점의 URL

Global Aurora

Aurora Cross Region Read Replicas → 재해 복구에 유용

Aurora Global Database → 최대 5개의 보조 읽기 전용 리전(복제delay 1초 미만), 중단되면 다른 리전을 활성화(1분 미만) (읽기전용이 읽고쓰게 승격)

⭐️ "Aurora 글로벌 데이터베이스의 데이터를 리전 간에 복제하는 데 평균 1초 미만이 소요됩니다"

        → 이 문장이 시험에 나온다면 글로벌 Aurora를 사용하라는 힌트

Aurora Machine Learning

SQL 인터페이스로 애플리케이션에 머신러닝 기반 예측을 적용 가능

• SageMaker : 백엔드에서 모든 종류의 머신러닝 모델을 사용할 수 있게 도움
• Amazon Comprehend : 감정 분석

비스 간의 간단하고 최적화된 안전한 통합입니다

두 가지 서비스에서 지원되는데요, SageMaker는 백엔드에서 모든 종류의 머신러닝 모델을 사용할 수 있게 해줍니다, 그리고 Amazon Comprehend가 있죠

RDS & Aurora- 백업과 모니터링

RDS Backups

Automated backups

        RDS 서비스가 자동으로 매일 데이터베이스의 전체 백업을 수행

        5분마다 트랜잭션 로그가 백업 (언제라도 5분 전으로 복원 가능), 자동 백업 보존 기간은 1~35일

Manual DB Snapshots

        수동 DB 스냅샷은 원하는 기간 동안 보관 가능

        ⭐️ex. 비용 절감하고싶을 때, 수냅샷 만들고 데이터 베이스 중지하여 사용할때만 스냅샷 복원

Aurora Backups

Automated backups

        1~35일 (비활성화 불가능)

        point-in-time recovery(시점 복구기능) - 어느 시점으로든 복구 가능

Manual DB Snapshots

        사용자가 수동으로 트리거, 원하는 기간동안 유지

Restore options

• RDS / Aurora backup or a snapshot을 복원할 때 새 데이터베이스 생성
• S3에서 MySQL RDS database 복구 (db 백업만 있으면 됨)
• S3에서 MySQL Aurora cluster 복구(Percona XtraBackup으로 백업한 다음, S3에서 Aurora DB 클러스터로 백업)

Aurora Database Cloning

기존 데이터베이스 클러스터에서 새로운 Aurora 데이터베이스 클러스터 생성 가능

ex. 프로덕션 데이터베이스 존재, 테스트 실행하기 위해db 복제→스테이징 Aurora 데이터베이스

        (스냅샷 찍고 복원보다 빠름

        → 복제는 copy-on-write 프로토콜**

        처음 복제본 만들때 원래 데이터베이스 클러스터와 동일한 볼륨 사용, 데이터 복사 안하니까 빠르고 효율적임

        프로덕션 Aurora 데이터베이스 ⇒ 스테이징 Aurora 데이터베이스에 업데이트 : 새로운 추가 스토리지가 할당되고, 데이터 복사

Database Cloning은 빠르고 비용 효율적, 프로덕션 db에 영향 X, db 복제에 유용 (스냅샷, 복원 기능 필요X)

** https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Clone.html

RDS & Aurora Security

At-rest encryption: AWS KMS를 사용해 마스터와 모든 replica 암호화 - 데이터가 볼륨에 암호화됨

        마스터 암호화 안했으면 read replica 암호화 불가

        암호화 안했던거 암호화하려면 스냅샷생성 → 암호화된 형태로 스냅샷 복원

In-flightencryption: 클라이언트, 데이터베이스 간의 전송중 데이터 암호화

        TLS default → 클라이언트가 TLS 루트 인증서 사용해야 함

IAM Authentication: IAM role 사용해 db에 접속

Security Groups: 특정 포트, IP, 보안 그룹 허용/차단

No SSH available: ssh액세스 없음

Audit Logs: 쿼리 기록, 데이터베이스 확인, CloudWatch Logs로 보내서 장기보관

Amazon RDS Proxy

바로 액세스 안하고 프록시하는 이유:

• 애플리케이션이 db내에서 연결 풀을 형성하고 공유 가능 ⭐️애플리케이션을 rds인스턴스에 일일이 연결하는 대신 프록시에 연결→ 프록시가 하나의 pool에 연결을 모음 → rbs 인스턴스로의 연결 감소 → CPU, RAM등 db리소스의 부담을 줄여 효율성 향상, db의 open connection과 timeout 최소화

• rds프록시는 완전한 서버리스 - autoscaling, highly available (multi-AZ) ⭐️장애나면 대기 인스턴스로 실행되어 장애조치시간(failover time) 66% 감소         메인 rds db instance에 애플리케이션 연결하고 각자 장애조치하는 대신, 장애조치와 무관한 RDS프록시에 연결 : RDS프록시가 장애 조치 발생한 RDS데이터베이스 인스턴스 처리해서 장애조치 시간 개선됨

• 애플리케이션 코드 변경 없이 rds프록시에 연결하면 됨 (rds db인스턴스, 오로라인스턴스 대신에)

• 데이터베이스에 IAM 인증 강제하여 IAM인증을 통해서만 rds db instance에 연결하게 함 자격증명은 AWS Secret Manager서비스에 안전하게 저장됨

• RDS는 public 액세스가 불가능.(VPC 내에서만 액세스 가능) → 보안 훌륭

• Lambda 함수와 사용하면 유용 람다함수는 빠르게 생성되고 사라져 연결많아지고 시간초과 발생 가능 → rds 프록시로 람다함수의 connection pool을 생성하면 람다함수가 rds프록시를 오버로드, 인스턴스 연결 감소

** 프록시란?

"대리"의 의미

특히 내부 네트워크에서 인터넷 접속을 할 때에, 빠른 액세스나 안전한 통신등을 확보하기 위한 중계서버를 "프록시 서버” 라고함

클라이언트와 Web서버의 중간에 위치하고 있어, 대신 통신을 받아 주는 것이 프록시 서버

Amazon ElastiCache

캐싱 기술인 Redis 또는 Memcached를 관리하는 것을 도움 (캐시: 높은 성능 짧은 delay의 인메모리(in-memory) 데이터베이스/ 읽기 집약적 워크로드의 db로드 줄여줌

** in-memory 컴퓨터의 주 메모리에 모든 조직 또는 개인의 데이터를 저장

일반적 쿼리는 캐시에 저장, 캐시만 사용해도 쿼리 결과 검색 가능

애플리케이션의 상태를 Amazon ElastiCache에 저장해 애플리케이션이 상태 비저장형(stateless)하게 도와줌

애플리케이션의 코드를 많이 바꿔야함**

        캐시를 쿼리하는 애플리케이션을 변경해야 함

ex. Amazon , RDS 데이터베이스, 애플리케이션

애플리케이션이 ElastiCache를 쿼리 → 이미 그 결과가 발생하여 저장하되어 있으면 Cache hit

⇒ 쿼리 수행 위해 RDS로 이동하는 시간 절약

캐시 무효화 전략 (invalidation strategy) - 최신 데이터만 사용해야 함

ex. 애플리케이션을 stateless로 만들기 위해 사용자 세션을 저장

사용자가 application에 로그인하면 세션 데이터를 ElastiCache에 씀

세션 캐시를 ElastiCache에서 검색가능하면 계속 로그인 상태인 것

Redis vs Memcache

Redis: 가용성 내구성이 뛰어난 복제된 캐시, 고가용성, 백업, 읽기 복제본을 위해 존재

        Multi AZ → Auto-Failover(자동 장애 조치 기능)         Read Replicas → ( scale reads, high availability)         AOF persistence → Data Durability(내구성)         Backup, restore         ⭐️Supports Sets, ⭐️Sorted Sets

Memcache: 분산되어있는 순수한 캐시. 데이터 손실되어도 괜찮음

        Multi-node for partitioning of data (=sharding)         No high availability (replication X)         Non persistent 영구 캐시 아님         No backup and restore         Multi-threaded architecture

** https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/mem-ug/SelectEngine.html

Redis랑 Memcached는 Amazon ElastiCache에서 지원하는 캐시엔진

Cache Security

Redis만 IAM 인증 지원 (나머진 id pw)

        IAM 정책 정의→AWS API-level security만 사용

Redis AUTH _ EC2인스턴스와 클라이언트가 있는 경우 Redis AUTH로 Redis 클러스터에 연결

        redis클러스터 만들때 “password/token” 설정

        캐시에 추가 보안 수준 제공 (보안그룹+α로)

        SSL 전송중 암호화 지원

Memcached는 SASL 기반 승인 제공

ElastiCache에 데이터 로드하는 패턴

Lazy Loading(지연로딩) : 모든 데이터 캐시

        캐시 히트 없는 경우에만 데이터를 ElastiCache에 로드

Write Through : 데이터가 기록될 떄마다 캐시에 데이터 추가, 엡데이트 (시간지연 X)

Session Store: ElastiCache에 세션 저장

Redis Use Case

⭐️게이밍 리더보드 만들기:

게임하는 어떤 순간이든 누가 1등? 2등? 3등?

⇒Redis Sorted sets은 고유성(uniqueness), 요소 순서(element ordering) 모두 보장

        요소가 추가될 때마다, 실시간으로 순위를 매긴 다음 올바른 순서로 추가

        ⇒ 애플리케이션에서 기능 프로그래밍할 필요 없이 실시간 리더보드에 액세스 가능

⭐️“중요한 포트”와 “RDS 데이터베이스 포트”를 구분할 줄만 알면 됨 중요한 포트:

FTP: 21

SSH: 22

SFTP: 22 (SSH와 같음)

HTTP: 80

HTTPS: 443

RDS 데이터베이스 포트:

PostgreSQL: 5432

MySQL: 3306

Oracle RDS: 1521

MSSQL Server: 1433

MariaDB: 3306 (MySQL과 같음)

Aurora: 5432 (PostgreSQL와 호환될 경우) 또는 3306 (MySQL과 호환될 경우)

용어 정리

RDS

• Storage Auto Scaling

• Read Replica 15개

• Multi AZ 다른az에 standby

• Custom

• 백업 매일 전체백업, 5분마나 트랜잭션로그 백업 + Manual DB Snapshots

• Proxy Amazon Aurora

• High Availability and Read Scaling 3개 AZ에 6개의 copies

• Aurora DB Cluster 라이터(Writer) 엔드포인트 리더(Reader) 엔드포인트

• Aurora Replicas - Auto Scaling

• Custom Endpoints

• Aurora Serverless

• Aurora Multi-Master Multiple writer endpoints

• Global Aurora 최대 5개 read replica region, 중단되면 메인으로 승격 (복제 1초미만)

• Aurora Machine Learning

• 백업 자동백업 비활성화불가 + Manual DB Snapshots Aurora Database Cloning         크기같은거 만들고나서 내용 복사. 빠르고 비용효율적

ElastiCache

• Redis

• Memcached 쿼리결과캐싱, stateless 애플리케이션, Supports Sets, Sorted Sets

: 데이터 저장, 엑세스, 보호 및 분석 기능을 갖춘 Amazon의 서비스

• Block Storage • 데이터를 일정 크기의 블록으로 나누어 저장 • 각 블록은 독립적인 주소를 가지며 이를 통해 랜덤 엑세스 가능 • Storage Area Network(SAN): 고성능의 전용 네트워크. 서버와 데이터 스토리지 시스템을 연결 • 빠른 입출력(I/O) 속도가 필요한 데이터베이스에 적합 • 높은 IOPS(초당 입출력 작업 수)와 낮은 지연 시간이 중요한 경우에 선택 • 운영 체제 또는 중요한 애플리케이션을 실행하는 데 사용됨

• File Storage • 데이터를 파일로 저장, 파일들은 폴더나 디렉토리에 조직 • 계층적인 파일 시스템 구조를 가짐 • Network Attached Storage(NAS): 네트워크에 연결돼 여러 사용자와 장치가 파일 기반의 데이터에 접근할 수 있게 해주는 전용 파일 스토리지 • 여러 서버나 사용자가 동일한 파일 시스템에 동시에 액세스해야 할 때 적합 • 파일과 디렉토리를 통해 데이터를 관리하고 싶을 때 유용 • 네트워크를 통한 파일 공유가 필요한 경우에 적합

• Object Storage • REST 기반의 API 호출을 통해 데이터에 접근 • HTTP 프로토콜 • 대용량 미디어 파일, 이미지, 백업 등을 저장할 때 적합 • 정적 웹 컨텐츠(예: 이미지, 비디오, HTML 페이지)를 호스팅할 때 유용 • 저렴한 비용으로 데이터를 오래 보관해야 할 때 선택 • 전 세계 여러 데이터 센터에 걸쳐 데이터를 분산시켜야 할 때 효과적

Amazon S3

usecase: 백업 및 스토리지, 재해 복구, 아카이브, 하이브리드 클라우드 스토리지, 애플리케이션 스토리지, 미디어 호스팅, 데이터 레이크 및 대규모 데이터 분석, 소프트웨어 배포, 정적 웹사이트 호스팅

특징

Access 제어 객체 별 ACL을 통해 데이터에 접근 가능한 사용자 특정이 가능 (ACL: Access Control List)

데이터 저장 데이터는 객체 단위로 저장

내구성 99.999999999%의 내구성

데이터 저장 용량 Standard의 경우 객체 하나의 크기는 최대 5TB까지

구성

Bucket - S3에 객체를 저장하게 해주는 시스템 - AWS 전역에서 단 한개만 존재: 리전과 관계 없이 전역적으로 Unique한 이름이 필요 - 리전 수준에서 정의: 데이터 저장 위치와 관련된 법률 및 규정 준수에 영향

Object - 객체는 보통 파일을 의미 (img, html,.. ) - 객체는 키를 가짐 (키는 파일의 전체 경로) - 객체 최대 크기는 5TB - 한번에 5GB이상 업로드 불가능

S3 Versioning

버킷의 버전 관리를 활성화하여 여러 버전의 객체 보관 가능 실수로 삭제되거나 덮어써진 객체 복원 가능 한번 활성화하면 비활성화 불가. 대신 중단 상태로 전환 가능

S3 Replication

• 버킷 내의 객체를 자동으로 다른 버킷으로 복사하는 기능. 비동기적
• CRR(Cross Region Replication) - 재해 복구, 사용자에게 더 빠른 액세스 제공, 규정 요구사항 충족을 위해
• SRR(Same Region Repplication) - 엑세스 제어, 실수로 인한 삭제 손상 방지, 효율적 데이터 관리

S3 Encryption - 정적암호화

서버 측 암호화(SSE)

• SSE-S3 (Server-Side Encryption with Amazon S3- Managed Key) : 각 객체마다 고유한 키를 사용하고, 추가 보안을 위해 이 키를 다른 마스터 키로 정기적으로 암호화. 사용자는 키 관리에 대해 걱정할 필요 없이 S3 에 의해 자동으로 처리됨. (default)

• SSE-KMS (Server-Side Encryption with AWS Key Management Service) : 사용자가 키의 사용을 제어하고 접근을 감사할 수 있음. 또한, 사용자 정의 키 관리 및 암호화 키의 로테이션을 지원. KMS-api 사용하므로 KMS 제한 사항에 영향을 받을 수 있음

• SSE-C (Server-Side Encryption with Customer- Provided Keys) : 데이터를 업로드하거나 다운로드할 때마다 사용자는 자신의 암호화 키를 제공해야 함. 이 방법은 키 관리의 책임이 사용자에게 있음. AWS로 키를 보내기 때문에 서버측 암호화 HTTP 요청마다 키를 헤더 제공해야하고, HTTPS 사용 필수

클라이언트 측 암호화 (CSE)

• CSE (Client-Side Encryption) 클라이언트 측에서 암호화하고, 암호화 된 데이터를 s3에 저장 암호화 키와 암호화 프로세스는 전적으로 사용자 측에서 관리 이는 보안을 높이지만, 키 관리 및 암호화 구현의 복잡성이 증가 (Amazon S3 Client-Side Encryption Library와 같은 클라이언트 라이브러리 사용)

S3 Encryption - 동적암호화

• 전송 중 암호화는 SSL 또는 TLS라고 함
• Amazon S3는 두 개의 엔드포인트가 있음

    - **HTTP** 엔드포인트: 암호화되지 않음
    - **HTTPS** 엔드포인트: 전송 중 암호화

• HTTPS가 권장됨
• SSE-C의 경우 HTTPS 프로토콜을 꼭 사용해야 함 대부분의 클라이언트는 기본적으로 HTTPS 엔드포인트를 사용함

S3 Security

• IAM
• 버킷 정책
• 접근 제어 목록 ACL

S3 Hosting

S3 버킷에 있는 파일을 이용해 정적 웹사이트 호스팅 가능

S3 CORS

CORS 요청 프로토콜의 일부로 다른 웹사이트에 요청을 보내야할 때 다른 오리진이 CORS Headers를 사용해서 요청을 허용하지 않는한 해당 요청은 이행되지 않음 (ex. Access-Control-Allow-Origin) S3 CORS

• 만약 클라이언트가 S3 버킷에서 교차 출처 요청 (cross-origin request)을 보내는 경우, 정확한 CORS 헤더를 활성화해야 한다
• CORS 헤더를 설정함으로써 특정 출처를 허용하거나 * (모든 출처)를 허용할 수 있음

S3 Pre-Signed URLS

• S3 콘솔, AWS CLI 또는 SDK를 사용하여 생성할 수 있는 URL
• 미리 서명된 URL을 받은 사용자는 GET / PUT에 대한 권한을 URL을 생성한 사용자로 부터 상속받음

S3 Classes

S3에는 다양한 클래스가 존재 -> 내구성은 동일하지만 가용성이 클래스마다 다름

S3 수명 주기 규칙

수명 주기 규칙은 크게 전환(Transition), 만료(Expiration) 작업으로 구성 (기간 설정도 가능)

Amazon CloudFront

CDN

Content Delivery Network 지리적 제약 없이 전세계 사용자에게 빠르고 안전하게 콘텐츠를 전송할 수 있는 기술

Edge Location

사용자에게 더 가까운 지리적 위치에 콘텐츠를 저장하는 데이터 센터 (Cloudfront에는 300개 이상의 엣지 로케이션)

Cloudfront Edge Location

Regional Edge Caches (REC) - 오리진과 엣지 로케이션 사이에 존재하는 캐시 계층 - 글로벌하게 배포되어있는 CloudFront 위치 - 리전 엣지 캐시는 표준 에지 로케이션에서 캐시하지 않는 콘텐츠를 저장 - 에지 로케이션에서 캐시 미스(cache miss)가 발생했을 때, 오리진 서버 대신 리전 엣지 캐시로부터 콘텐츠를 검색하여 더 빠른 응답 시간을 제공

Origin Shield (2020.10 릴리즈) - 2020년 10월에 발표된 새로운 기능으로, CloudFront에서 캐싱 계층을 하나 더 추가하여 사용자(클라이언트)와 엣지 서버간의 거리를 줄이는 기능. - 캐시 적중률을 높이고 오리진 서버의 부하를 줄여주어 로드 속도를 향상시키는 효과가 있다.

Amazon Cloudfront

- AWS에서 제공하는 CDN (글로벌) 서비스 - Client의 콘텐츠 요청으로 서버에서 받아온 콘텐츠를 캐싱하고 이후 같은 요청이 왔을 때, 그 캐싱해 둔 것을 제공하는 서비스 - 성능 향상, 데이터 전송 속도 빨라짐, 보안성 향상, 안정성 및 가용성 향상 - Origin에서 HTTPS를 지원하지 않아도, CloudFront 내에서 HTTPS 통신 지원 가능 - Shield, AWS Web Application Firewall을 제공함으로써 DDoS로부터 보호 제공 - S3와 연동 시 => 캐싱을 지원하기 때문에 s3에 저장된 컨텐츠를 직접 접근하지 않아도 되므로 s3의 비용이 감소하며, 더 빠른 응답 지원

Amazon Cloudfront 동작 순서

1. 사용자가 어플리케이션에 요청을 한다.
2. DNS는 사용자에게 적합한 Edge Location으로 라우팅 한다.
3. Edge Location에서 캐시를 확인하고 있으면 이것을 사용자에게 반환한다.
4. 없으면 가장 가까운 REC로 캐시가 있는지 요청한다.
5. 없으면 CloudFront는 오리진으로 요청을 전달한다.
6. 오리진은 '오리진 > REC > Edge Location > CloudFront가 사용자에게 전달' 수순을 밟는다. (캐시도 추가된다)
7. REC에 캐시가 있다면 REC는 콘텐츠를 요청한 Edge Location으로 반환한다.
8. REC로부터 콘텐츠의 첫 번째 바이트가 도착하는 즉시 Edge Location은 이를 사용자에게 반환한다.
9. Edge Location은 나중을 위해 이 콘텐츠 캐시를 저장한다.

Amazon Cloudfront Origin

콘텐츠는 TTL 값 동안 Edge Location에 캐싱되어 낮은 지연시간으로 콘텐츠를 요청

• 정적 콘텐츠 서버(EC2)가 필요하지 않음 이미지 등
• 동적 콘텐츠 서버가 필요한 콘텐츠들 (로그인 자료, 실시간으로 새롭게 추가되는 게시판 등) 이를 정적 캐싱하면 사용자는 TTL 시간동안 새롭게 추가 or 수정된 데이터를 볼 수 없게됨

Amazon Cloudfront 캐시 정책

- 목적: 캐시 정책은 CloudFront가 콘텐츠를 얼마나 오랫동안 캐시할 것인지, 어떤 HTTP 헤더, 쿼리 문자열 및 쿠키를 캐시에 포함할 것인지를 결정.

- 구성 요소: 캐시 정책 설정은 TTL(Time-To-Live) 값, 캐시할 헤더, 쿼리 문자열, 쿠키 등을 포함할 수 있음.

Amazon Cloudfront OAI

OAI (Origin Access Identity):

CloudFront가 S3에 저장된 _Private 객체_에 액세스 할 수 있도록 하는 특별한 식별자 외부 사용자가 S3 Endpoint를 통한 직접적인 요청이 아닌 CF의 배포를 통해 접근하도록 구성하고 싶다면 OAI를 고려할 수 있음 S3 Origin 보안 강화를 위해 요청을 식별하는 데 사용되는 S3만을 위한 CloudFront 서비스 (S3의 ‘Principal’을 통해 참조)

Amazon Cloudfront OAC

Amazon Cloudfront 응답 헤더 정책

CloudFront가 사용자에게 콘텐츠를 전달할 때 HTTP 응답에 추가할 헤더를 정의하는 기능

• 보안 헤더 추가: 보안 관련 HTTP 헤더를 응답에 자동으로 추가가능
• 사용자 정의 헤더: 특정 사용자 정의 헤더를 추가하여 응답을 더 유용하게 만들 수 있음 (애플리케이션 버전, 캐시 상태 등)
• 캐싱 동작 제어: Cache-Control 헤더를 통해 캐시 서버와 브라우저가 콘텐츠를 캐싱하는 방식을 제어할 수 있음 - CORS(Cross-Origin Resource Sharing) 설정: 다른 도메인의 웹 페이지에서 리소스를 요청할 수 있도록 허용하는 Access-Control-Allow-Origin과 같은 CORS 관련 헤더를 설정 가능
• 성능 최적화: 성능과 관련된 헤더를 추가하여 브라우저의 렌더링 성능을 개선할 수 있음 (Vary 헤더를 사용하여 다양한 장치 유형에 따라 적절한 콘텐츠를 제공)

Amazon Cloudfront 보안 Access 구성 및 제한

Signed Url 개별 파일에 대한 access 제공 (파일 하나당 하나의 url) 만료시간, IP주소 범위 등 지정 ex. 쿠키 구운 구독자에게만 웹툰을 제공

Signed Cookie 다수의 파일에 대한 access 제공 (다수의 파일에 하나의 signed cookie) 만료시간, IP주소 범위 등 지정 ex. 로그인 한 유료회원에게 콘텐츠를 제공

Amazon Cloudfront Pricing

• 서버 Edge Location마다 데이터 전송 비용이 다름
• 다양한 Price Class 존재 Price Class All Price Class 200 Price Class 100

수직확장성: 인스턴스 크기 확장

수평확장성: 인스턴스 개수 확장+분배시스템 - scale out/in

Availability(고가용성)

애플리케이션 또는 시스템을 둘 이상의 데이터센터에서 가동중

→ 고가용성으로 데이터 손실 없이 계속해서 작동하도록

Elastic Load Balancing

: 트래픽을 서버들로 전달: 부하 분산, 장애x

aws가 업그레이드, 유지관리, 고가용성 책임짐

• Health Check: 로드밸런서가 ec2인스턴스 작동 올바르게 되는지 확인

  포트와 라우터에서 진행, 200응답 아니면 트래픽 안보냄

  대상 그룹 level

• ec2보안그룹을 로드밸런서 그룹으로 연결

  ec2 인스턴스가 로드 밸런서에서 온 트래픽만을 허용

  ‼️이거 우리가 전에 어려워했던거!! 이렇게 쓰인다고 이해하니까 완전 알겠음

• 애플리케이션 서버는 클라이언트의 IP를 직접 못봄

• 종류

  • Classic Load Balancer

  • Application Load Balancer

    • HTTP 전용 로드밸런서 (7Layer)

    • HTTP에서 HTTPS로 트래픽을 자동 리다이렉트 가능

    • 다른 대상그룹에 라우팅 가능(path, hostname, query string, header)

      ex. 각 대상그룹마다 path에 따라 검색만. 조회만.. 다른 작업 처리 가능

    • 대상그룹: ec2 instance, ecs task, Lambda function, (사설)IP addr

    • 도커, ECS에 적합 - 포트 매핑 기능

    • 실습: 두 인스턴스 대상그룹에 넣고 ALB만들어 새로고침 계속하면 두 ec2인스턴스로 부하 분산 하나 끄면 다른데로만 연결됨 ALB > Listener에서 요청별로 (다른 대상그룹으로 연결/다른 url로 연결/바꿔서 다른 결과 반환) 가능 : 규칙 순서대로 우선순위

  • Network Load Balancer

    • TCP와 UDP 트래픽 (4Layer)
    • 가용 영역별로 하나의 고정 IP ⭐️1~3개의 IP로만 액세스할 수 있는 애플리케이션을 만들라 →NLB
    • 대상그룹: ec2 instance, private IP addr, ALB
    • Health Check - TCP, HTTP, HTTPs

  • Gateway Load Balancer

    • 네트워크 계층 3Layer
    • 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용
    • 애플리케이션에 도달하기 전에 모든 트래픽 검사 - 방화벽, 침입탐지에 강함
    • 기능: 투명 네트워크 게이트웨이 / 로드밸런서
    • ⭐️6081번 포트의 GENEVE 프로토콜을 사용 =GWLB
    • 대상그룹: EC2 instance, private IP addr

⭐️Sticky Sessions (Session Affinity)

특정 세션의 요청을 처음 처리한 서버로만 전송하는 것- 쿠키 사용

CLB, ALB 대상그룹에 설정하는 옵션

쿠키:

      Application-based Cookies

            대상으로 생성된 사용자 정의 쿠키 (애플리케이션에 필요한 모든 사용자 정의 속성을 포함)

      Duration-based Cookies

            로드밸런서에서 생성한 기간 기반으로 만료됨

            ALB에서 이름 - AWSALB

            CLB에서 이름 - AWSELB

Cross-Zone Load Balancing

가용영역에 상관없이 모든 인스턴스에 부하를 고르게 분배

아니라면) az에게 고르게 분배, 각 az안에서 인스턴스들에 분배

CLB, ALB에서 default 활성화, 데이터를 다른 az로 옮길때 비용X

NLB, NWLB는 비활성화, 비용O

SSL/TLS 암호화 기반 인터넷 보안 프로토콜

SSL(보안 소켓 계층): 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화(=in-flight 암호화), 송신자와 수신자 측에서만 복호화

TLS(전송 소켓 계층):새로운 버전의 SSL - 요즘 씀 걍 SSL이라부름

Public SSL 인증서는 인증기관CA에서 발급. 주기적으로 갱신.

HTTPs의 s가 SSL 인증서 써서 암호화해 안전하다는 의미

ACM - AWS 인증서 관리자

• Server Name Indication (SNI) 서버 이름 표시

  여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트 지원하도록 함

  즉, 단일 IP주소에서 여러 SSL 인증서를 호스팅할수있도록 도와줌

  클라이언트가 대상 서버의 호스트 이름을 지정 → 서버가 어떤 인증서 로드할지 알게됨

  ALB, NLB만

⭐️Connection Draining (Deregistration Delay)

인스턴스가 등록 취소 또는 비정상적인 상태일 때 인스턴스에 어느 정도의 시간을 주어 in-flight 요청을 완료할 수 있도록 만들어 주는 기능

연결이 draining 되면, 즉 인스턴스가 draining 되면 ELB는 등록 취소 중인 인스턴스로는 새로운 요청을 보내지 않게 된다.(새로운 요청은 shut down)

업로드와 같이 오래 걸리는 작업인 경우 파라미터를 높게 설정해 인스턴스 장애 복구 등의 작업을 진행

Auto Scaling Group

ASG를 통해 scale-out/scale-in

로드밸런서와 패어링하면 자동으로 모든 ec2인스턴스가 로드밸런서에 연결

인스턴스 비정상이면 종료하고 대체할 ec2인스턴스 생성

Min 용량/Max 용량/desired 용량, Lanch Template 설정

CloudWatch가 Auto Scaling Alarms

Scaling Policies

• Target Tracking Scaling - ex. 평균 CPU 설정
• Simple / Step Scaling -CloudWatch 알림 생성할때 인스턴스 생성 제거 조건 설정
• Scheduled Actions - 시간별 사용패턴 기준으로 scaling 여부 예측
• Predictive Scaling- 지속적으로 부하를 예측하고 이를 통해 다음 스케일링을 예측

스케일링의 지표

• CPUUtilization - 평균 CPU 사용량
• RequestCountPerTarget - 인스턴스 당 요청의 수
• Average Network In / Out
• 커스텀 지표

⭐️Scaling Cooldowns

• 스케일링 발생 후 휴지 기간 가짐
• 휴지기간동안 추가 인스턴스 실행/종료 불가

용어 정리

** Elastic Load Balancing

종류

• Classic Load Balancer
• Application Load Balancer
• Network Load Balancer
• Gateway Load Balancer

설정

Sticky Sessions (Session Affinity)

• 쿠키

Cross-Zone Load Balancing

Connection Draining (Deregistration Delay)

SSL/TLS

• SNI 서버 이름 표시

로드밸런서랑 SSL이랑 뭔상관!

로드밸런서로 SSL 적용

SSL이 적용된 로드밸런서에서의 호스트 기반 라우팅 동작 방식

Network Load Balancer, 이제 서버 이름 표시(SNI)를 사용하여 여러 TLS 인증서 지원

Auto Scaling Group에 로드밸런서를 연결

AZ에 속하는 network drive

Snapshots (AZ상관x)

Encryption: 스냅샷 →스냅샷암호화→그걸로 EBS생성 →EBS암호화

• General Purpose SSD
• Provisioned IOPS (PIOPS) SSD
• Hard Disk Drives (HDD)

EBS Multi-Attach – io1/io2 family

하나의 볼륨에 여러ec2를 연결 최대 16개의 EC2 Instances까지

AMI(Amazon Machine Image) :customization of an EC2 instance

region에 속함

** 난 이 상황에 AMI가 왜나오는지 이해가 안됐다!!
AMI와 EBS 스냅샷을 사용하여 EBS 볼륨 백업 생성 - AWS규범적 지침
AMI에는 이미지가 생성될 때 인스턴스에 연결된 EBS 볼륨의 루트 볼륨과 스냅샷이 포함

EC2 Instance Store

고성능 하드웨어 디스크

I/O performance 좋음

EFS – Elastic File System

AZ상관x

EBS보다 3배 큼

하나의 EFS에 여러 EC2연결 가능

⭐️ 언제 EFS를 사용해야 하는지, 네트워크 파일 시스템에 어떤 옵션을 설정해야 하는지 Use cases: content management, web serving, data sharing,Wordpress

EFS vs EBS

EFS

네트워크 파일 시스템 여러 az의 수백개의 instance에 연결

EBS

한번에 하나의 인스턴스에 attach

AZ안에 snapshot을 통해 다른 AZ로 복제해 이동

인스턴스 root ebs는 인스턴스 종료되면 종료

인스턴스 스토어

물리적으로 EC2에 연결, instance 종료→ 데이터x

+퀴즈에 영역 문제가 많다‼️

EBS - az

ami - region

EFS- 상관x

22 = SSH (Secure Shell) - log into a Linux instance

21 = FTP (File Transfer Protocol) – upload files into a file share

22 = SFTP (Secure File Transfer Protocol) – upload files using SSH

80 = HTTP – access unsecured websites

443 = HTTPS – access secured websites

3389 = RDP (Remote Desktop Protocol) – log into a Windows instance

(EC2 Instances Purchasing Options)

dedicated instances vs dedicated hosts

EC2 전용 인스턴스

그 인스턴스가 할당된 물리적 서버는 같은 AWS 계정(account)의 인스턴스만 할당되어 사용하는 옵션

전용 인스턴스 방식은 비어있는 호텔을 골랐을 때만 가능합니다. 룸이 10개라 하더라도 1개만 내가 먼저 예약하면 나머지 9개 룸은 누구도 예약할 수 없습니다. 즉 나만의 호텔을 잠깐 동안이지만 소유할 수 있습니다. 나만 온전히 사용할 수 있지만 비용은 On-Demand보다 훨씬 비싼 것은 어쩔 수 없습니다. 사용이 완료되면 사용 기간만큼 10개 룸의 사용 요금을 내고 퇴실합니다.

필요한 인스턴스만 빌림

EC2 전용 호스트

EC2 인스턴스가 있는 물리적 서버를 구매하여 전용 용량, 전담 호스트를 사용하는 방식 (물리적 서버를 점유)

전용 호스트 방식은 처음부터 이 호텔을 내가 작정하고 짓고 나만 소유하는 방식입니다. 호텔 룸이 비어있다고 하더라도 다른 누구도 사용할 수 없습니다. 오롯이 나만 소유할 수 있는 변경 없는 옵션이며 사용이 끝나면 모든 비용 처리를 해야 합니다. 가장 비싼 옵션입니다.

⇒ 더 조사!!

회사 차리면 필요한 물리적 hw 전체를 예약해버림

EC2 Spot Instances

Not suitable for critical jobs or databases

종료하는법

spot 요청 취소 후 인스턴스 종료 (내가 요청을 취소 안하면 aws에서 또 새로운 인스턴스를 만든다)

Spot Fleets

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/spot-fleet.html

스팟 인스턴스 및 선택적으로 온 디맨드 인스턴스의 모음

Spot Fleet는 Spot Fleet 요청에서 지정한 목표 용량을 충족하기 위해 스팟 인스턴스 및 온디맨드 인스턴스 수를 시작

사용 가능한 용량이 있고 요청에서 지정한 최대 가격이 현재 스팟 가격을 초과하면 스팟 인스턴스에 대한 요청이 이행

Spot Fleet은 또한 스팟 인스턴스가 중단된 경우 대상 용량 집합을 유지하려고 시도

Spot Fleet는 목표 용량을 가격 제한과 일치시키려고 시도함

Place Group

Parition

동일한 리전의 여러 가용 영역에서 파티션을 가짐

파티션 1, 파티션 2 및 파티션 3이 있는 파티션 배치 그룹에 배치된 인스턴스를 보여줍니다. 각 파티션은 여러 인스턴스로 구성됩니다. 각 파티션에 있는 인스턴스는 다른 파티션에 있는 인스턴스와 랙을 공유하지 않기 때문에 단일 하드웨어 장애의 영향을 관련 파티션으로만 국한할 수 있습니다.

Spread

각각 고유한 하드웨어에 배치된 인스턴스 그룹

7개의 인스턴스가 7개의 서로 다른 랙에 배치되며, 랙마다 자체 네트워크 및 전원이 있습니다. 각 인스턴스는 고유한 랙에 배치. 각 랙에는 인스턴스가 최대 1개

EC2 = Elastic Compute Cloud = Infrastructure as a Service (IaaS)

구성:

Renting virtual machines (EC2)- ec2인스턴스

Storing data on virtual drives (EBS)

Distributing load across machines (ELB)

Scaling the services using an auto-scaling group (ASG)

EC2 sizing & configuration options

Operating System (OS): Linux / Windows / Mac OS

compute power & cores (CPU)

random-access memory (RAM)

storage space:

Network-attached (EBS & EFS) hardware (EC2 Instance Store)

Network card: speed of the card, Public IP address

Firewall rules: security group

Bootstrap script (configure at first launch): EC2 User Data

EC2 User Data

EC2 User data script: EC2 사용자 데이터 스크립트를 사용해 인스턴스 부트 스트래핑 가능

bootstrapping: 머신이 작동될때 명령을 시작하는 것

처음 시작할때만 스크립트 실행

부팅 작업 자동화:

업데이트 설치 sw 설치 인터넷에서 common files 다운 ..

사용자 데이터 스크립트에 작업 추가할수록 부팅 시 인스턴스가 할일이 늘어남

EC2 InstanceTypes

명명규칙m: instance class 5: generation (AWS improves them over time) 2xlarge: size within the instance class

General Purpose

Balance between: Compute / Memory / Networking (t로 시작)

Compute Optimized

high performance 필요로 하는 compute-intensive tasks

    Batch processing workloads     Media transcoding     High performance web servers     High performance computing (HPC)     Scientific modeling & machine learning     Dedicated gaming servers

    (c로 시작)

Memory Optimized

Fast performance for workloads that process large data sets in memory

(메모리에서 빠른 성능)

    High performance, relational/non-relational databases     Distributed web scale cache stores     In-memory databases optimized for BI (business intelligence)     Applications performing real-time processing of big unstructured data

    R로 시작

Storage Optimized

high, sequential read and write access to large data sets on local storage필요한 storage-intensive tasks

    High frequency online transaction processing (OLTP) systems     Relational & NoSQL databases     Cache for in-memory databases (for example, Redis)     Data warehousing applications     Distributed file systems (분산파일 시스템)

Security Groups

control how traffic is allowed into or out of our EC2 Instances

only contain rules

reference by IP / by security group They regulate: • Access to Ports • Authorised IP ranges – IPv4 and IPv6 • Control of inbound network (from other to the instance) • Control of outbound network (from the instance to other)

인바운드는 허용하는 ip를 작성, 아웃바운드는 default로 모두 허용

IAM

오른쪽 상단에 아이디만 뜨면 루트 계정인것

사용자 생성

그룹을 만들거나 직접(인라인 정책) 권한 부여해야함 그룹 만들어서 진행해보자aws의 거의 모든 리소스엔 항상 태그가 존재(optional) 생성 완료!

+ 루트 사용자 계정 별칭 생성

계정 별칭: 더 빠르게 로그인하기 위해 설정할수 있는 기능

이어서.. stephan으로 로그인해보자url접근- 시크릿창 or 다른 웹 브라우저콘솔에 IAM user로 로그인됨
루트 사용자 vs IAM user

정책 변화주고 확인정책 작동방법

권한 변화주고 확인하기 지금 iam user도 콘솔 잘 보임(왼쪽 루트사용자, 오른쪽 stephan)관리자 그룹에서 stephan 삭제권한 없어져서 안보임다시 root account에서 사용자에 들어가서

1. 직접 권한 연결해주면 원래대로 돌아감=>그룹 생성의 권한은 없음
2. 그룹 생성해 stephan 추가⇒ 두 그룹에 속함

정책 작동방법

정책 작동 방법:정책 생성도 가능:visual editor에서 클릭하고 json으로 가면 추가되어있음

MFA

비밀번호 규칙 변경 가능

루트계정에 대한 멀티팩터 인증 설정(루트계정으로 로그인했을 때만 접근 가능) 이전에 했던 실습이다

CLI(터미널, CloudShell)

터미널

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html 액세스 키 확인 가능한 유일한 시간

aws configure

aws iam list-users

⇒ 모든 사용자 나열

관련 권한 지우면 터미널창에서 이 명령어 수행도 안됨

CLI권한은 IAM콘솔에서 얻는 권한과 완전히 같다

터미널 대안:

AWS CloudShell: 리전 가용성

AWS CloudShell는 다음의 AWS 리전에서 사용할 수 있습니다.

• 미국 동부(오하이오)
• 미국 동부(버지니아 북부)
• 미국 서부(오리곤)
• 아시아 태평양(뭄바이)
• 아시아 태평양(시드니)
• 아시아 태평양(도쿄)
• 유럽(프랑크푸르트)
• 유럽(아일랜드)

CloudShell은 AWS 클라우드에서 무료로 사용 가능한 터미널같은 개념 --region: API 호출을 할 리전 지정(default 지금 로그인한 계정

CloudShell 전체 저장소

여기서 파일 생성하면 새로고침해도 그대로 존재함

글씨크기 테마 등 구성 가능 작업>경로 쳐서 파일 다운로드 가능

IAM Role 생성

사용할 서비스 선택나중에 사용할것임

IAM Security Tools 생성, 확인

자격 증명 보고서 만들자최근 4시간만 추적 한번도 접속 안했다거나 하는 기록이 권한 변경의 근거가될수있음

IAM: Identity and Access Management

Global service

Root account: 회원가입하면 default로 생김

Users: 조직에 있는 사람. 0개 이상의 그룹에 속한다

Groups: User을 포함. 다른 그룹을 포함X

Permissions: User나 Group에 할당하는 JSON 문서인 policy가 정의하는 권한

최소권한 원칙(least privilege principle)

IAM Policies Structure

⭐️구성⭐️

• Version: policy language version. 항상 “2012-10-17” 포함
• Id: 정책의 식별자 (optional)
• Statement (required) 1개 이상의 statements
  • Sid: statement의 식별자 (optional)
  • Effect: 허용할지 거부할지 (Allow / Deny)
  • Principal: 적용할 account/user/role
  • Action: 허용or거부할 action의 list
  • Resource: action적용할 리소스 list
  • Condition: 언제 영향줄지 (optional)

그룹과 사용자 보호

1st:

IAM – Password Policy

Strong passwords = 높은 보안

직접 pw policy 설정 가능:

• minimum password length
• Require specific character types
  • including uppercase letters
  • lowercase letters
  • numbers
  • non-alphanumeric character
• IAM user가 password 바꾸게 허용
• 특정 기간마다 꼭 바꾸도록 (password expiration)
• password re-use 방지

2nd:

Multi Factor Authentication - MFA

MFA = password you know + security device you own → 비밀번호 알아도 계정 보호됨

⭐️MFA devices options⭐️

• Virtual MFA device

AWS에 접근

1. AWS Management Console (password + MFA)
2. AWS Command Line Interface (CLI): access keys. 컴퓨터 터미널에서 접속
3. AWS Software Developer Kit (SDK): for code, access keys. 애플리케이션 코드 내부

Access Key ID ~= username Secret Access Key ~= password

절대공유X

AWS CLI

셸에서 명령어 사용해 AWS 서비스들과 상호작용하게 해주는 도구 (command-line shell)

모든 명령어 aws로 시작

aws 서비스의 공용API로 직접 access

리소스 관리하는 스크립트 개발해 일부 작업 자동화

open-source

AWS SDK

AWS Software Development Kit

특정 언어로 된 라이브러리의 집합(언어마다 개별 SDK존재)

코딩을 통해 어플리케이션에 심어둠 (Embedded)

IAM Roles for Services

policy와 같지만 사용자가 아닌 AWS 서비스가 사용

IAM Security Tools

IAM Credentials Report (account-level): 자격중명 보고서

계정의 사용자와 다양한 자격 증명 상태 포함

IAM Access Advisor (user-level)

사용자에게 부여된 서비스와 그 서비스에 마지막으로 엑세스한 시간 조회 가능

최소 권한 원칙에 유용

Cloud Provider use on demand(사용한 만큼 지불), scale easily(쉽게 규모 조절) use case: build sophisticated, scalable applications • Enterprise IT, Backup & Storage, Big Data analytics • Website hosting, Mobile & Social Apps • Gaming

ONCE는 카드 결제 전 보유한 카드 중 결제처에서 최적의 혜택을 받을 수 있는 카드를 미리 추천해주는 AI 모바일 어플리케이션이다.

[ 매년 사라지는 카드 포인트 1000억원, 이대로 괜찮을까? ]

우리나라 1인당 신용카드 보유 개수는 3.6장이며, 개인의 신용카드 보유율은 80.2%에 달한다. 하지만 전체 발급 카드 중 1년 동안 사용 실적이 없는 휴면카드가 1300만장에 육박하며, 매년 사라지는 카드 포인트 1000억원이 소비자가 아닌 카드사의 부가 수입으로 들어가는 이유에 의문을 가지고 프로젝트를 시작하게 되었다.

필요 기술 1 : 스크래핑 기반 금융 API를 이용한 사용자 정보 조회 (*스크래핑 : 각 카드사와 통신하여 실제 데이터를 제공)

→ CODEF API를 이용하여 실제 카드 보유 목록, 혜택 정보 및 실적을 불러올 수 있다.

필요 기술 2 : 크롤링을 이용한 카드사 별 카드 혜택 정보 실시간 수집

→ 파이썬 크롤링 라이브러리 BeautifulSoup, Selenium, Requests 등을 이용하여 카드별 혜택의 상세 정보를 불러올 수 있다.
필요 기술 3 : 자연어 처리 사전 훈련 언어 모델을 활용한 카드 혜택 학습

→ 사용자가 이용 중인 카드가 어떤 혜택을 제공하는지 분석하기 위해 수집한 상세 카드 혜택 정보를 BERT 모델을 활용하여 이해 및 학습시킨다.
필요 기술 4 : 트랜스포머 모델을 활용한 사용처에 맞는 최적의 카드 추천

→ 자연어 처리 기술을 활용하여 아이템을 벡터로 표현한 후, 사용자가 입력한 결제처와의 유사도를 계산하여 사용처에서 최적의 혜택을 제공하는 카드를 추천한다.
필요 기술 5 : 챗봇을 통한 사용자와의 상호작용

→ ChatGPT API를 활용하여 메인화면에서 사용자와의 주요 상호작용을 처리할 수 있도록 한다.

CODEF API를 이용해 금융정보 가져오기

1. API란?

   • 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스

   • 어떠한 응용프로그램에서 데이터를 주고 받기 위한 방법

**오픈 API**:

오픈API란 누구나 사용할 수 있도록 공개된 API

데이터를 표준화하고 프로그래밍해 외부 소프트웨어 개발자나 사용자가 바로 개발(어프리케이션)에 활용할 수 있는 형태의 개방 형식

업데이트가 빈번하고 활용도가 높은 대용량의 데이터를 연계 개발할 때, 날씨나 교통 정보 등 실시간 업데이트되는 데이터를 연계가 필요할 때 유용 

2. ONCE에서의 필요

   ONCE는 사용자에게 맞춤화된 서비스를 제공하기 위해서, 사용자의 카드 관련 정보들이 필요하다.

   기본적으로 사용자가 보유하고 있는 카드의 종류를 파악하고 있어야 하고, 전월 실적을 파악해 혜택의 조건을 고려할 때 활용해야 한다. 또한 이번 달의 받은 혜택 정보와 실적이 얼마나 채워졌는지 등의 정보를 실시간 업데이트 하여 저장할 수 있어야 한다.

   ONCE는 금융, 카드 관련 서비스로 보안 또한 중요한 지점이기 때문에, 이 정보들을 믿을 수 있는 방식으로 활용 가능한 금융 API를 활용하기로 결정하였다.

3. CODEF API 선정 이유
   카드 관련 api를 제공하는 여러 사이트가 존재하고, 우리가 대학생 창업 프로젝트의 과정에서 사용할 수 있는 서비스를 조사하였다.
   해당 정보들이 민감한 개인정보인 만큼 금융결제원 오픈API과 바로빌 카드 정보 조회 API는 실제로 사업자 등록을 한 경우에만 회원가입이 되었고, API를 활용하기 위해서는 기업간 계약 체결을 진행해야 했기에, 현재 우리의 단계에는 적합하지 않았다.
   신한 Open API에서 원하는 API를 제공 중인 것을 보았지만, 신한 카드의 정보만으로는 우리의 서비스를 완성시킬 수 없고, 다른 카드 회사들의 API를 모두 따로따로 불러오기는 어렵다는 결론을 내렸다.
   토스 페이먼츠 개발자센터에서는 "카드사 혜택 조회" API를 제공중인데, 이는 하나하나 카드 상품의 혜택 정보를 원하는 우리 서비스의 의도와 맞지 않았다.
   이에 따라 현재 대학생 신분에 사업자 등록 없이도 돈을 지불한다면 활용이 가능하고, 실제 창업 전에 DEVELOPER 모드로 기술 검증을 해볼 수 있으며 "보유 카드 목록 조회", "승인 내역 조회", "실적 조회"가 가능한 CODEF API를 활용하기로 결정하였다.

4. API 활용 과정 CODEF에서 정보를 제공해주는 과정은 다음과 같다.CODEF의 모든 api를 사용하기 위해서는 헤더에 accessToken이, body에 connectedID가 필요하다. connectedID는 CODEF에서 사용하는 개념으로, 한개의 커넥티드 아이디로 엔드 유저가 사용하는 N개의 기관에 등록이 가능하다. 제공하는 여러 API들은 커넥티드 아이디 계정 등록으로 받은 accessToken과 connectedID, 필수 파라미터들을 담아 요청하여 원하는 정보들을 반환받을 수 있다.

5. 구현 해당 실습은 API 요청이 제대로 실행되는지 확인하는 test용으로, 실제 서비스에서는 서버에서 자동으로 처리되는 로직을 가진다.
   Django를 이용해 진행하였다. Django는 urls.py에 써있는 url에 접속하면 해당하는 views.py의 함수가 실행된다.

1) accessToken, connectedID 발급

urls.py
path('tocken/',tockenView),

views.py

    @api_view(['GET'])
    def tockenView(request):
    client_id="[키 관리>client_id]"
    client_secret="[키 관리>client_secret]"
    url='https://oauth.codef.io/oauth/token' 
    authHeader = stringToBase64(client_id + ':' + client_secret).decode("utf-8")
    headers = {
        'Acceppt': 'application/json',
        'Content-Type': 'application/x-www-form-urlencoded',
        'Authorization': 'Basic ' + authHeader
        }
    response = requests.post(url, headers = headers, data = 'grant_type=client_credentials&scope=read')
    print(response.status_code)
    response_text=response.text
    json_data = json.loads(response_text)
    access_token = json_data.get('access_token')

필요한 정보(client_id,client_secret)를 담아 https://oauth.codef.io/oauth/token에 요청을 보내 access_token을 받는다.

공동인증서를 이용한 로그인도 가능하지만, 서비스 이용 비용이 있어 카드사별 계정으로 직접 로그인하는 방식을 사용한다.

    bank_code='0306'              # 신한 코드
    user_id='[신한 카드 홈페이지 아이디]'          
    user_password='[신한 카드 홈페이지 패스워드]'
    pubkey="[키 관리>public_key]"
    codef_account_create_url = 'https://development.codef.io/v1/account/create'
    codef_account_create_body = {
            'accountList':[
                {
                    'countryCode':'KR',                     # KOREA
                    'businessType':'CD',                    # CARD
                    'clientType':'P',                       # PERSONAL
                    'organization':bank_code,
                    'loginType':'1',                        # 아이디 패스워드로 로그인
                    'id':user_id,
                    'password':publicEncRSA(pubKey, user_password)    # 퍼블릭 키로 패스워드 암호화
                }
            ]
        }

    response_account_create = http_sender(codef_account_create_url, access_token, codef_account_create_body)                
    decoded_response_text = urllib.parse.unquote(response_account_create.text) # URL 디코딩

필요한 파라미터들을 담아 데이터를 만들고, 해당 url에 요청한다. 이때 CODEF에서 제공해주는 API 명세서를 잘 참고해야 한다.

    try:
        response_data = json.loads(decoded_response_text)
        connected_id = response_data['data']['connectedId']
        return render(request,'home.html',{'tocken':access_token,'connectedID':connected_id})
    # 예외처리

완료되어 얻은 access_token과 connected_id를 담아 home.html를 호출한다.

home.html은 access_token과 connected_id를 화면에 보여주고 세가지 api를 호출하는 버튼으로 구성하였다.

2) 보유 카드 조회

보유카드 조회 버튼 클릭 시 실행되는 함수이다.

@api_view(['GET'])
def mycardView(request,tocken,connectedID):
    codef_mycard_url = 'https://development.codef.io/v1/kr/card/p/account/card-list'
    codef_account_create_body = {
                    'organization':'0306',
                    'connectedId':connectedID,
                    'loginType':'1',
                    'inquiryType':'1'
    }
    response_account_create = http_sender(codef_mycard_url, tocken, codef_account_create_body)
    my_data=unquote(response_account_create.text)
    my_data=json.loads(my_data)
    my_data=json.dumps(my_data,ensure_ascii=False)
    return render(request,'home.html',{'my_data': my_data,'tocken':tocken,'connectedID':connectedID})

토큰을 header에, connectedId와 카드회사, 로그인type등 정보를 담아 보유카드를 조회하는 EndPoint에 정보를 전달한다.

그 결과는 다음과 같다. 카드 이름과 카드 번호, 카드 종류 뿐만아니라 교통카드 기능이 있는지, 카드 이미지 등의 정보가 반환된다.

3) 승인 내역 조회

(2)번 보유 카드 조회처럼 api 명세서의 필수 파라미터들을 담고, 해당 엔드포인트에 요청을 보내면 된다.

카드 승인 내역 정보로, 날짜와 시간, 금액과 사용한 결제처 등의 정보를 확보 가능하다. 사용자가 자주 들른 매장인 경우 GPS를 이용해 근처일 경우 알림을 울리는 기능을 구현할 때, 사용자의 단골 매장을 찾는데 사용될 API이다.

4) 실적 현황 조회

각 카드가 가지고 있는 혜택들과 해당 혜택을 받기 위한 실적이 채워졌는지 여부를 알려준다. 이번 달 해당 카드로 사요한 금액도 확인이 가능하다.

카드 혜택 정보 크롤링

1. 크롤링이란?
   Web상에 존재하는 Contents를 수집 하는 작업 (프로그래밍으로 자동화 가능)
   1) HTML 페이지를 가져와서, HTML/CSS등을 파싱하고, 필요한 데이터만 추출하는 기법
   2)Open API(Rest API)를 제공하는 서비스에 Open API를 호출해서, 받은 데이터 중 필요한 데이터만 추출하는 기법
   3)Selenium등 브라우저를 프로그래밍으로 조작해서, 필요한 데이터만 추출하는 기법
   
   

2. ONCE에서의 필요
   원스는 사용자의 결제처, 전월실적, 혜택을 받기 위한 최저 결제 금액과 최고 할인 금액을 파악하고 있어야 한다.
   그러기 위해 각 카드 상품들의 페이지에 나와있는 유의사항 하나하나까지 파악해야 한다.
   이에 따라 카드 혜택 정보 저장을 위해 크롤링을 이용하기로 하였다.
   
   

3. 크롤링 종류
   

정적 크롤링:
웹에 있는 정적인 데이터를 수집할 때 사용. 주소를 통한 단발적 접근. 정적 데이터: 변하지 않는 데이터. 한 페이지 안에서 사전 작업 없이 드러나는 정적인 데이터 수집속도가 빠르지만, 수집 대상에 한계가 있음 사용 라이브러리: requests, BeautifulSoup
동적 크롤링:
웹에 있는 동적인 데이터를 수집할 때 사용. 브라우저를 사용한 연속적 접근. 동적 데이터: 입력, 클릭, 로그인 등과 같이 페이지 이동이 있어야 얻을 수 있는 데이터. 속도가 느리지만 더 많은 정보 수집 가능 사용 라이브러리: selenium, chromedriver

4. 구현

1) 정적 크롤링, csv파일로 저장

import csv

csvFile = open('kb_test.csv', 'w+')

writer = csv.writer(csvFile)
writer.writerow(('card name', 'part', 'discount','notice'))

카드 혜택을 저장할 csv파일을 연다. 칼럼명에는 카드이름, 혜택 분야, 할인 내용, 유의사항이 있다.

from urllib.request import urlopen
from bs4 import BeautifulSoup

html=urlopen('https://card.kbcard.com/CRD/DVIEW/HCAMCXPRICAC0076?mainCC=a&cooperationcode=09123')
bs=BeautifulSoup(html,'html.parser')

urlopen함수를 이용해 원하는 카드 상품의 페이지를 연다.

name = bs.find('h1', {'class':'tit'}).get_text()
soups=bs.findAll('div',{'id':'tabCon011'})
for i in range(1, 3):

    partname=soups[i].find('h2').text[7:]
    parts=soups[i].findAll('div', {'class':'titArea'})

    for part in parts:
        discount=part.find('h2', {'class':'titDep2'}).text
        notice=part.find('div', {'class':'benefitBox1'}).text
        writer.writerow((name,partname,discount,notice))

html의 구조를 파악하고, 원하는 정보의 class, id등을 이용하여 경로를 찾고 값을 저장한다. writerow함수로 찾은 값들을 csv파일에 한줄씩 적는다.

생성된 결과는 다음과 같다. 카드의 이름과 혜택 분야별 할인 내용이 잘 저장되었음을 확인 가능하다. 저장이 완료되면 csvFile.close()명령어로 csv파일을 닫는다.

2) 동적 크롤링

# selenium의 webdriver를 사용하기 위한 import
from selenium import webdriver
from selenium.common.exceptions import TimeoutException

# selenium으로 키를 조작하기 위한 import
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.by import By

# 페이지 로딩을 기다리는데에 사용할 time 모듈 import
import time

필요 라이브러리들을 import

# 크롬드라이버 실행
driver = webdriver.Chrome() 

url = 'https://card.kbcard.com/CRD/DVIEW/HCAMCXPRICAC0076?mainCC=a&cooperationcode=09123'
#크롬 드라이버에 url 주소 넣고 실행
driver.get(url)

# 페이지가 완전히 로딩되도록 3초동안 기다림
time.sleep(2)

크롬드라이버를 이용해 해당 url의 페이지를 연다.

# 링크 클릭
link = driver.find_element(By.ID,'topTab1').find_element(By.TAG_NAME,'a')
link.click()

상세 혜택을 보기 위해 "상세 혜택" 버튼을 클릭한다. 크롬 드라이버에서 코드의 명령에 따라 click해준다.

# 페이지 소스 가져오기
page_source = driver.page_source

# BeautifulSoup을 사용하여 파싱
soup = BeautifulSoup(page_source, 'html.parser')

# 원하는 데이터 추출
title = soup.find('div', {'id':'tabCon010'}).get_text()

클릭을 통해 새롭게 나타난 페이지에서 원하는 데이터를 추출한다.

동적 크롤링만으로 정보를 얻을 수 없는 카드사 사이트인 경우 위와 같이 Selenium을 이용해 원하는 데이터를 추출할 예정이다. csv파일에 저장하는 과정은 (1)과 같으므로 생략하겠다

3) AWS RDS에 연결해 크롤링한 데이터를 바로 저장

host_name = "[RDS 엔드포인트]"
username = "[rds username]"
password = "[rds password]"
database_name = "[데이터베이스 이름]"
db = pymysql.connect(
    host=host_name, 
    port=3306,
    user=username,  
    passwd=password, 
    db=database_name, 
    charset='utf8'
)

이 코드를 실행하여 AWS의 RDS와 연결한다

cursor.execute("DROP DATABASE IF EXISTS once;")
db.commit()

cursor.execute("CREATE DATABASE itta DEFAULT CHARSET=utf8 COLLATE=utf8_bin;")
db.commit()

cursor.execute("USE once;")
db.commit()

cursor.execute("DROP TABLE IF EXISTS `CARD`;")
db.commit()

cursor.execute("""
CREATE TABLE `CARD` (
    # 테이블 구성..
) DEFAULT CHARSET=utf8;
""")
db.commit()

SQL문을 직접 입력하여 동작을 수행한다. 이 코드는 CARD 테이블을 생성한다.

이후 (1), (2)처럼 원하는 데이터를 추출하는 크롤링을 진행한다. 원하는 데이터들을 변수에 저장해둔 뒤, cursor.execute()``db.commit()을 이용해 INSERT문을 실행하면 된다.

GPT 파인튜닝으로 카드 추천

1. 파인튜닝이란?
   사전 학습된 인공지능 모델의 가중치를 새로운 데이터에 맞게 세밀하게 조정하여 성능을 향상시키고 학습 시간을 줄이는 과정 (이미 배운 것을 기반으로 새로운 문제를 해결하는 과정)
   인공지능 모델 활용 시 파인튜닝이 필요한 이유:
   
   • 특정 도메인이나 작업에 최적화: 사전 학습된 인공지능 모델은 대규모 데이터셋으로 학습되어 일반적인 작업에 적합하지만, 특정 작업에 대한 성능이 제한적일 수 있기에, 파인튜닝으로 특정 작업에 맞게 조정해 성능을 향상시킨다.
     
   • 자원 및 시간 절약:
     사전 학습된 모델을 기반으로 파인튜닝하여, 작은 양의 데이터와 상대적으로 짧은 학습 시간으로도 좋은 성능을 얻을 수 있다.
     
   • 새로운 데이터에 대한 적응: 모델이 새로운 데이터에 더 잘 적응하고, 그에 따른 예측이나 추론 성능이 향상된다.
     
     

2. GPT란?
   1) 개념
   
   자동 회귀 언어 모델로 ChatGPT와 같은 생성형 AI 애플리케이션을 지원하는 인공 지능(AI) 분야의 발전을 보여주는 주요 모델
   

    **Transformer 아키텍처**를 기반으로 구축된 신경망 기반 언어 예측 모델로, 프롬프트라는 자연어 쿼리를 분석하고 언어에 대한 이해를 바탕으로 가능한 최상의 응답을 예측<br>
    애플리케이션에서 인간과 유사한 텍스트 및 콘텐츠(이미지, 음악 등) 를 생성하고 대화형 방식으로 질문에 답할 수 있는 기능을 제공<br>
    업계 전반의 조직들이 Q&A 봇, 텍스트 요약, 콘텐츠 생성 및 검색에 GPT 모델 및 생성형 AI를 사용<br><br>

   2) 실습
   GPT를 파이썬으로 실행시켜보자.
   ① OpenAI API 신청
       OpenAI에 접속해 회원가입해준다. 여러 모델이 존재하고, 특징 및 가격이 다르니 사이트를 잘 참고하자.
                   API활용을 위해 Settings>Billing에 카드를 등록했다.                 프로필 클릭 > Views API keys                 나온 API key를 복사한다.
   ** ② 파이썬 openai 모듈 설치
                   터미널에 pip install openai를 입력해 openai 관련 패키지를 다운받는다.
   
   **③ 파이썬 코드 실행하기
                   GPT3.5를 지원해주는 text-davinci-003 모델을 사용해보자     

   import os import openai

   openai.api_key = "[API 키]"

   response = openai.Completion.create(

    model = "text-davinci-003",
    prompt = "my name is chaerin.\n\nQ: who am I?\nA:",
    temperature = 0,
    max_tokens=100,
    top_p = 1,
    frequency_penalty = 0.0,
    presence_penalty = 0.0,
    stop = ["\n"]

   )

   print(response) print(response.choices[0].text.strip())

model: openai가 제공해주는 모델 중 사용할 모델의 이름
prompt: 원하는 실행어 입력 - 좋은 결과를 위해 많은 테스트 필요
max_tokens: 입력+출력 값으로 잡을 수 있는 최대 토큰 길이. 초과되면 에러가 난다 (한글은 토큰이 많이 쓰여 영어 위주로 사용할 예정)
stop: stop 지점을 설정한다. 여기서는 "\n"이다
결과는 다음과 같다. 내 이름을 알려준 뒤 내가 누군지 물었는데, 의도대로 내 이름을 답해준다.

3. GPT 파인튜닝이란?
   GPT 3.5 "davinci-003"모델은 2021년까지의 데이터만 학습되어 있어, 2022년도에 대한 답을 하지 못한다. 또한 ChatGPT는 웹 페이지, 책, 기타 문서 등 방대한 양의 일반 텍스트 데이터로 학습하여 언어의 패턴과 구조를 학습한 상태이므로, 특정 주제에 대한 질문에 대한 텍스트를 생성할 때 최적의 성능을 발휘하지 못할 수 있다.
   
   예를 들어 특정 제품이나 서비스에 대한 고객의 질문에 답변할 수 있는 챗봇을 만들려면 해당 제품이나 서비스에 대한 고객 문의 및 응답 데이터 세트에 대해 ChatGPT를 Fine-tuning 하여 해당 도메인에서 사용되는 언어의 패턴과 뉘앙스를 더 잘 이해하고 보다 관련성 있고 정확한 응답을 생성할 수 있다. 질문에 대한 답을 알려주기도 하고, 원하는 format으로 답이 나오도록 유도할 수 도 있다.
   
   

4. OpenAI의 Fine-tuning API 장점
   1) 프롬프트 디자인보다 높은 품질의 결과
   2) 프롬프트에 맞지 않는 예제를 학습할 수 있는 능력
   3) 짧은 프롬프트로 인한 토큰 절약
   4) 낮은 지연 요청 시간
   파인튜닝은 프롬프트에 맞지 않는 예제를 포함한 훨씬 많은 예제로 학습함으로써 다양한 작업에서 더 나은 결과를 얻을 수 있다. 모델을 파인튜닝한 후에는 더 이상 프롬프트에서 예제를 제공할 필요가 없기에 비용을 절감하고 지연 시간이 낮은 요청이 가능하다.
   
   

5. 모델 별 파인튜닝 비용

6. ONCE에서의 필요
   GPT는 뛰어난 모델이지만, 카드 추천이라는 우리의 서비스에 적합하게 학습된 상태가 아니다. 따라서 우리가 질문할 예정인 문장과, 이에 원하는 대답의 형식을 정해주어 학습시킬 것이다.
   또한 GPT는 모든 은행의 카드 혜택 정보를 가지고 있지 않으며, 더더욱이 2022 이후의 데이터는 알 수 없기 때문에 두번째 기술 크롤링을 통해 얻은 카드 및 혜택 정보들을 입력하여 우리의 서비스에 관련된 정확한 응답을 생성하도록 할 것이다.

7. GPT 파인튜닝 과정
   ① 데이터 준비(format 맞추기)
   모델을 파인튜닝하기 위한 데이터를 먼저 준비해야 한다. prompt(원하는 프롬프트)-completion(원하는 답 형태) 쌍으로 이루어진 JSON 형태의 데이터 단일 입력 예제와 해당하는 출력으로 구성 CLI 데이터 준비 도구로 Fine-tuning 할 수 있는 데이터 생성: openai tools fine_tunes.prepare_data -f <로컬_파일>
   
   ② Fine-tuning 모델 생성
   OpenAi에서 제공하는 base model을 활용 (ada, babbage, curie, davinci)
   OpenAI CLI를 사용하여 파인튜닝 작업 시작 openai api fine_tunes.create -t <TRAIN_FILE_ID_OR_PATH> -m <BASE_MODEL>   ex. openai --api-key [YOUR_KEY] api fine_tunes.create -t example_prepared.jsonl -m davinci
   이 코드의 작업:        - 파일을 파일 API를 사용하여 업로드 (또는 이미 업로드된 파일을 사용)        - 파인튜닝 작업을 생성        - 작업이 완료될 때까지 이벤트를 스트리밍 (보통 몇 분 소요, 대기 중인 작업이 많거나 데이터셋의 크기에 따라 몇 시간)

   추가 명령어들

   생성된 모든 파인튜닝 작업 나열

   openai api fine_tunes.list

   파인튜닝 상태 검색. 결과 객체에는 작업 상태 (대기 중, 실행 중, 완료 또는 실패 중 하나일 수 있음)와 기타 정보가 포함됩니다.

   openai api fine_tunes.get -i

   작업 취소

   openai api fine_tunes.cancel -i
   
   ③ Fine-tuning 모델 사용
   OpenAI 내 계정 정보 > Fine-tune training에 정보 추가됨, playground에서 확인 및 사용 가능
   작업이 성공 시, fine_tuned_model 필드에 모델의 이름 저장됨 이 모델을 Completions API의 매개변수로 지정하여 Playground를 사용하여 요청 보내기 가능
   + 파인튜닝된 모델 삭제

8. 오버피팅과 언더피팅 대응 전략
   

데이터 추가 수집: 더 많은 데이터는 모델이 다양한 패턴을 학습하고 오버피팅의 위험을 줄이는 데 도움이 된다
데이터 증강: 백트랜스레이션과 유의어 대체와 같은 데이터 증강 기법을 사용하여 추가적인 훈련 예제를 생성하고 오버피팅을 줄일 수 있다
모델 단순화: 모델이 오버피팅되었다면, 모델의 크기나 복잡성을 줄이는 것을 고려하라
모델 복잡성 증가: 언더피팅이 문제라면, 데이터의 패턴을 파악하기 위해 더 복잡한 모델이 필요할 수 있다

9. 파인튜닝 모델 평가
   모든 인공지능 모델은 학습 및 테스트 후 모델이 학습한 내용을 얼마나 잘 일반화했는짖 명확하고 객관적으로 측정할 수 있어야 한다. 평가를 통해 모델이 세밀 조정 과정에서 실제로 유용한 내용을 학습했는지 아니면 훈련 데이터에만 과적합되었는지를 정량적으로 판단할 수 있다.
   
   자연어 처리(NLP)에서 사용되는 일반적인 지표:

• 정밀도(Precision):
  이 지표는 양성으로 예측한 사례 중 실제 양성인 경우의 비율로, "모델이 양성으로 예측한 사례 중 실제로 양성인 것이 얼마나 많은가?"라는 질문에 대답한다. 정밀도 = TP / (TP + FP)
  
  
• 재현율(Recall, 민감도 또는 진양성 비율):
  실제 양성 사례 중 모델이 정확하게 양성으로 예측한 경우의 비율로, "실제 양성 사례 중 모델이 얼마나 정확하게 양성으로 예측했는가?"라는 질문에 대답한다. 재현율 = TP / (TP + FN)
  
  
• F1-Score:
  F1-Score는 정밀도와 재현율의 조화 평균으로, 이 둘을 균형 있게 조합한다. 데이터에 클래스 불균형이 있는 경우 특히 유용하다. F1-Score = 2 * (정밀도 * 재현율) / (정밀도 + 재현율)
  
  
• 정확도(Accuracy):
  정확하게 예측한 사례의 비율로, 데이터의 클래스 불균형이 있는 경우에는 신뢰할 수 없는 지표이다. 다수 클래스의 사례가 소수 클래스의 사례보다 많은 경우에는 특히 그렇다. 정확도 = (TP + TN) / (TP + TN + FP + FN)
  
  
• AUC-ROC (Receiver Operating Characteristic Curve의 면적): 모든 가능한 분류 임계값에서의 성능을 종합적으로 제공한다. 모델이 클래스를 구별할 수 있는 정도를 나타낸다.
  
  

9. GPT 파인튜닝 실습
   현재 감정을 표현하고 이름을 말하면 기분에 맞는 반응을 해주고, 이름을 다시 출력하도록 만들자
   파인튜닝 전, 기존 "text-davinci-003"모델을 사용해 다음과 같은 입력을 주면 prompt = "Feel: Smile \nMSG:my name is Chaerin.\n ->", 이러한 결과가 나온다.
   하지만 내가 원하는 형식대로 데이터를 만들어 보겠다. example_prepared.jsonl이 생성되었다. openai --api-key [API KEY] api fine_tunes.create -t example_prepared.jsonl -m ada 만들어진 모델을 이용해 prompt를 보내보았다.

10. ONCE에 GPT 파인튜닝 적용 방안 prompt와 completion의 형식에서, 카드 추천을 위해 파인튜닝을 적용할 방법을 구상해 보았다.
    1) 각 사용자가 가진 카드와 해당 카드의 혜택 정보를 원하는 결제처와 함께 입력하여 그 중 하나의 카드를 도출해낸다.
    {”prompt” : “<결제처, [카드 1, 카드 1 상세 혜택, 카드 1 실적 충족 여부], ..., [카드 N, 카드 N 상세 혜택, 카드 N 실적 충족 여부]>”, “completion” : “<결제처에서 사용할 카드>”}
    

-> 각 사용자마자 파인튜닝을 진행해야 하므로 현실성이 떨어진다.

2) 한 카드의 혜택정보와 결제처를 입력하여 해당 결제처에서 받을 수 있는 하나의 혜택 항목만을 뽑아낸다. 사용자가 보유한 모든 카드에 대한 혜택 추출이 완료되면, 이 결과들을 비교해 최적의 카드를 찾는다.
GPT 모델 1 : {”prompt” : “<결제처, 카드명, 그 카드의 혜택, 실적 조건>”, “completion” : “<결제처에서 해당 카드로 누릴 수 있는 혜택(실적 채운 경우와 채우지 못한 경우 나눠서)>”}

→ [결제처, 카드명, 카드의 혜택]을 보고 누릴 수 있는 혜택을 찾아주는 역할

GPT 모델 2 : 모델 1에서 나온 결과들을 비교하여 가장 최대 혜택을 제공하는 카드 선택
{”prompt” : “<[결제처 A, 카드명1, 결제처에서 해당 카드로 누릴 수 있는 혜택1], ... , [결제처 A, 카드명N, 결제처에서 해당 카드로 누릴 수 있는 혜택N]>”, “completion” : “<결제처, 사용할 카드, 그 카드의 혜택>”}

→ 직접 사용자가 [결제처]를 입력했을 때, [사용할 카드]를 출력

3) Chat Completion을 이용해 사용자가 가진 카드의 정보들을 GPT에게 준 다음, 결제처를 입력해 하나의 최선의 카드를 출력하도록 한다.
Chat Completion: openai로 요청을 보낼 때 과거의 대화 기록을 포함하게 한다(원래 openai는 과거 요청을 기억x)         - user 메시지 : 사용자의 질문이나 설명         - assistant 메시지 : 이전 assistant 메시지(openai 응답)을 저장, 사용자가 원하는 동작의 예를 제공하기 위해 작성하기도
"user": "A카드, B카드, D카드의 혜택이 뭐야?", "assistant": "A카드 혜택: [A 카드 혜택 정보],B카드 혜택: [B 카드 혜택 정보],C카드 혜택: [C 카드 혜택 정보]" "user": "GS25에서 10000원 결제하려면 이 중 어느 카드를 쓸까?" 이와 같은 형식으로, user의 질문에 대한 GPT의 답변을 지정해주어 카드의 혜택을 GPT가 파악하도록 하고, 결제처 입력을 통해 이 중 사용할 카드를 출력하도록 한다.
여기서 카드 목록, 카드별 헤택 정보, 결제처는 백엔드 파트에서 입력받은 입력들을 알맞은 자리에 대입하여 완성한다.

파인 튜닝 관련 자문 및 조사를 통해 3번의 방식대로 파인 튜닝을 진행하기로 하였다. 크롤링한 정보를 어떤 형식으로 넘길지를 포함하여 input과 output의 형식에 따라 GPT의 답변과 정확도가 달라질 것이다. 이를 모두 고려해 test해보며, 최고의 서비스를 구현해보자

• 클라우드 리소스를 자동으로 조정하여 지정된 조건에 따라 필요할 때만 필요한 만큼의 컴퓨팅 리소스를 사용 할 수 있도록 하는 AWS 서비스
• 사용량이 증가하면 Auto Scaling은 사용자 정의 규칙에 따라 자동으로 EC2 인스턴스를 추가하여 용량을 늘 리고, 사용량이 감소하면 리소스를 줄여 비용을 절감

“ 수요 예측을 정확히 하기란 사실상 불가능 하므로 트래픽 변화에 유연하게 대응하자 ! ”

Scale up vs Scale out

Scale Up <-> Scale Down 하나의 인스턴스의 리소스(예: CPU, 메모리)를 늘리는 것을 의미 예) 더 강력한 CPU나 더 많은 RAM을 갖는 더 큰 인스턴스 유형으로 전환(리소스 업그레이드 / 다운그레이드) 주로 수동으로 수행 (리부팅, 서비스 중단 야기 -> 수평 확장 선호) Scale Out <-> Scale In 더 많은 인스턴스를 추가하여 전체 시스템의 용량을 늘리는 방식 (리소스 개수 추가 / 축소) AWS Auto Scaling - AWS의 관리형 서비스들은 주로 Scale out & in을 지원

AWS Auto Scaling Resource

EC2 Auto Scaling

: EC2 인스턴스에 대한 Scale in & out을 제어할 수 있는 서비스 이점 - 비용절감: 필요에 따라 용량을 동적으로 늘리거나 줄임, 사용한만큼만 비용 지불 - 내결함성 향상 : 인스턴스가 비정상 상태일 때 이를 종료하고, 새로운 인스턴스를 시작 -> 하나의 가용 영역이 불가 상태가 되면 다른 가용 영역에서 새 인스턴스를 시작 - 가용성 향상 : 현재 트래픽 요구를 처리할 수 있는 적정 용량을 갖추도록 도움을 주고, 가용 영역 전반에 인스 턴스 분산

EC2 Auto Scaling 구성요소

1.** Launch Configurations / Launch Templates**: 인스턴스를 시작할 때 사용할 EC2 인스턴스 설정을 정의. 여기에 는 인스턴스 유형, AMI, 키 페어, 보안 그룹 및 기타 구성 세부 정보가 포함됨

2. Auto Scaling Groups (ASGs): Auto Scaling이 관리할 EC2 인스턴스의 집합입니다. ASG는 최소, 최대, 원하는 용량을 설정하여 그 범위 내에서 인스턴스를 유지하도록 합니다.

3. Scaling Policies: 인스턴스 수를 언제 확장하거나 축소할지 결정하는 규칙을 정의. 메트릭(예: CPU 사용률, 네트워 크 입출력 등)에 기반하여 동작.

   
   (1) **CPU 사용률**: 애플리케이션의 CPU 사용이 높고, 이것이 서비스 성능에 직접적인 영 향을 미치는 경우 이 지표를 사용하면 좋다! ex. 계산 작업이 많은 애플리케이션 또는 서버가 최대 성능으로 운영되어야 하는 게 임 서버, 데이터베이스 서버 등

4. 네트워크 입출력: 네트워크 트래픽이 성능의 제한 요소가 되는 환경에서는 이 지표가 유용하다. ex. 큰 파일을 전송하거나 스트리밍 서비스를 운영하는 경우

5. ALB 요청 수 (LoadBalancerRequestCountPerTarget): 웹 애플리케이션이나 API 게이트웨이를 운영하고 요청 처리 능력을 기반으로 스케일링을 하고 싶을 때 적합하 다.이 지표를 사용하면 각 인스턴스가 처리해야 하는 HTTP/HTTPS 요청의 수를 기준 으로 인스턴스 수를 조정할 수 있다.

6. 사용자 지정 지표 (Custom Metrics): Amazon CloudWatch를 통해 사용자가 직접 지표를 생성하고 이를 Auto Scaling에 활용할 수 있음. 이는 표준 지표로는 해결되 지 않는 특수한 요구 사항을 가진 시스템에 적합. ex. 특정 애플리케이션 큐의 길이나 특정 데이터베이스의 쓰기/읽기 지연 시간 등

Load Balancer

네트워크 트래픽을 여러 서버에 균일하게 분산시키는 장치 또는 소프트웨어. 웹사이트 또는 어플리케이션의 가 용성과 내구성을 높이기 위해 사용             대표적인 AWS의 서비스 : Elastic Load Balancer

Load Balancing

여러 리소스에 부하를 분산시키는 기술

• 부하 분산 처리 하나의 리소스에 트래픽이 과도하게 몰려 서비스 중단되는 현상을 막기 위함
• 하나의 엔드포인트 제공 트래픽을 하나의 경로로 받아 여러 인스턴스에 분산시키기 때문에, 사용자 입장에서는 서로 다른 인스턴스에 접속하게 되더라도 같은 엔 드포인트(주소)로 접속하면 됨

Scale in & out으로 사이즈 조절하는 Auto Scaling과 뗄레야 뗄 수 없는 관계!

Load Balancer + Auto Scaling

참고

Elastic Load Balancer

트래픽을 여러 대상에 자동으로 분산시켜주는 서비스 VPC에 탑재되며, 사용자의 요청을 받아 VPC 내의 리소스를 적절한 부하 분산

Elastic Load Balancer 내부 구성요소

리스너(Listener) - 프로토콜과 포트를 기반으로 요청을 받아 검사하고 이를 적절한 타겟으로 전달하는 기능을 수행 - 리스너가 외부의 요청을 받아들이기 때문에 모든 로드 밸런서는 최소 한 개 이상의 리스너를 필요로 하며 최대 10개까지 설정 가능. + SSL 인증서를 게시하여 SSL Offload를 실시할 수도 있다

규칙(Rule) - 리스너와 타겟그룹 사이의 트래픽 분배를 위한 라우팅 규칙 - 우선순위, 액션, 조건 등의 정보를 담고 있으며 특정 조건이 만족되었을 때 지정된 액션을 수행

대상 그룹 (Target Group) - 리스너가 전달한 요청을 처리하기 위한 부하 분산 대상들의 모임 - 대상 그룹에 등록된 인스턴스의 정보 + EC2가 전달받은 요청을 처리할 수 있는 지를 체크하는 헬스체크 + 이 대상 그룹에 요청처리가 가능한 EC2가 몇 개인지, 불가능 한 EC2는 몇 개인지를 확인하는 모니터링 기능이 들어있다 - 쉽게 말해 오토스케일링 하기 위해 오토스케일링 그룹 만든 것처럼, 로드 밸런싱 하기 위해 대상 인스턴스들 묶어 놓은 그룹 -> 그리고 이 대상 그대로 오토스케일링 그룹으로도 만들 수 있다

유휴 제한 시간 (Connection Time out) - 사용자가 ELB를 거쳐 EC2에 접근하여 서비스를 접속하면 Connection이 생성됨 - 이 커넥션으로 통신하는데, 더 이상의 통신이 없을 때엔 유후 제한 시간이 작동하게 되고 그 시간이 지나면 커 넥션이 사라짐

Cross-Zone Load Balancing

두 개의 AZ 영역이 있고 각 영역에서 로드 밸런서가 위치하고 있다면 Cross-Zone Load Balancing이 이를 보완    AZ를 가리지 않고 고르게 분배 / ALB는 기본적으로 활성화 / NLB는 기본적으로 비활성화

Health Check

ELB에 연결된 인스턴스에 직접 트래픽을 발생시켜 인스턴스가 살아있는지 체크함 타겟그룹에 대한 헬스 체크를 통해 정상적으로 작동하는 인스턴스로만 트래픽을 분배 - InService : 서비스 살음 / OutofService : 서비스 죽음

Elastic Load Balancer의 종류

Application Load Balancer(ALB)

1. ALB는 OSI 7 Layer에서 일곱 번째 계층에 해당하는 Application Layer를 다루는 로드밸런서
2. ALB는 HTTP/HTTPS 프로토콜의 헤더를 보고 적절한 패킷으로 전송 (지능적인 라우팅)
3. ALB는 IP주소 + 포트번호 + 패킷 내용을 보고 스위칭
4. ALB는 IP 주소가 변동되기 때문에 Client에서 Access 할 ELB의 DNS Name을 이용
5. ALB는 L7단을 지원하기 때문에 EC2 대신에 SSL 적용이 가능

Network Load Balancer(NLB)

1. NLB는 L4(Transport Layer)단의 로드 밸런서를 지원
2. NLB는 TCP/IP 프로토콜의 헤더를 보고 적절한 패킷으로 전송 (당연히 HTTP헤더는 해석 못함)
3. NLB는 IP + 포트번호를 보고 스위칭
4. NLB는 할당한 Elastic IP를 Static IP로 사용이 가능하여 DNS Name과 IP주소 모두 사용이 가능 (IP 고정 가능!)
5. NLB는 SSL 적용이 인프라 단에서 불가능하여 애플리케이션에서 따로 적용해 주어야 함

=>ALB처럼 똑똑하게 주소로 보내주는게 아닌 단순한 라우팅이 필요하고,트래픽이 극도로 많은 경우에는 ALB 보다는 NLB를 사용하는 것이 적합하다고 할 수 있다.

Gateway Load Balancer(GLB)

- GWLB는 L3단의 로드 밸런서를 지원 - 트래픽이 EC2에 도달하기 전에 먼저 트래픽을 검사하거나 분석하거나 인증하거 나 로깅하는 작업을 수행 - 트래픽을 체크하는 애, 위의 일반 로드밸런서와 조금 역할이 다름

SQL을 언어로 사용하는 managed database service

• 프로비저닝, OS 패칭 전부 자동
• 지속적 백업 & 특정 시간으로 복구 (Point in Time Restore)
• 모니터링 대시보드 존재
• read Replicas 읽기 요청 몰리면 읽기 전용 용량 자동으로 늘어남 ex. 회사에서 하루/한달에 한번씩 통계용으로 데이터 읽어오는데 성능에 문제발생
• multi AZ 셋업 가능 High Availability 다중AZ 설정-> AZ별 인스턴스에 마스터DB의 Sync 복제 여러 rds지만, 하나의 DNS active가 아닌 standby - 장애 대비 용도
• Scaling capability Storage Auto Scaling (Horizontal scaling) 데이터베이스 인스턴스 수를 조절(증가/감소), 읽기부하높을 때 read replica 생성해 부하 분산
• EBS 스토리지 사용

+) active-active VS activce-standby :(서버를 이중화 하는 방법) Active-active: 여러 개의 자원이 동시에 서비스 되는것 Active-standby: 말 그대로 하나의 서버가 대기(Stanby) 상태

EC2에서 MySQL vs RDS

rds는 HA, Scalability지원 / EC2보다 비쌈 -> 데이터를 오래 관리해야하고, 안정성이 중요한 입장(데이터 무결성, 내결함성이 너무 중요)이라면 rds

DynamoDB

AWS에서 만든 DBMS (독점기술) managed serverless NoSQL DB     Managed: 완전 관리형     Serverless: 서버리스     NoSQL: 관계형 DB 아님

Key-value store, 키-값 데이터베이스 기본 연산 put(key, value): 키-값 쌍을 저장소에 저장 get(key): 인자로 주어진 Key에 대응되는 값 조회

테이블: 데이터를 저장하는 기본 단위 아이템: 테이블 내의 개별 레코드 (RDB의 row) Primary Key = PK + SK

• key/value 스토어, TTL 기능 지원
• HA, Multi AZ, Read and Writes are decoupled, transaction capability
• DAX 클러스터를 읽기 캐시로 생성할 수 있다. -> ms 단위의 latency
• IAM을 통한 보안, 인증, 인가
• Event Processing: DynamoDb 스트림과 Lambda/Kinesis Data Streams를 통합할 수 있음. - 따라서 Dynamo 테이블의 모든 변화에 따라 함수를 호출할 수 있다.
• Global Table 기능: active-active 설정이 가능하다.

인터넷을 통해 서버, 스토리지, DB, 네트워크 및 기타 컴퓨팅 자원에 대한 온디맨드 액세스를 제공하는 서비스 사용자가 직접 인프라를 보유하거나 관리할 필요 없이 필요할 때 원하는 컴퓨팅 리소스를 사용하도록 함

AWS의 주요 컴퓨팅 엔진

Infrastructure as a Service(IAAS)

EC2: - AWS에서 가장 기본적이고 널리 쓰이는 인프라, 가상머신으로 제공되며 인스턴스라고 불림 - 물리 환경의 컴퓨터처럼 컴퓨팅 리소스를 제공 (피씨방가서 돈내고 컴퓨터 이용하는 것과 비슷) Lightsail: - 초보자 친화적인 서비스로, 주어진 리소스 옵션 중 하나를 골라 단일 가상 서버를 간단히 설정하는 서비스 - 사전에 구성된 템플릿을 이용해 인스턴스를 빠르게 배포 가능

Serverless

(PaaS) Elastic Beanstalk: - EC2 위에 구축된 고급 관리 플랫폼 - 사용자는 애플리케이션 코드를 EB에 업로드하기만 하면 EB가 EC2인스턴스를 자동으로 생성하고 배포과정을 관리함 - 코드를 업로드하기만 하면 프로비저닝, 로드밸런싱, Auto Scaling, 운영체제 관리 등의 개발과 배포 자동화 (FaaS) Lambda: - 모든 유형의 애플리케이션이나 백엔드 서비스에 대한 코드를 별도의 관리 없이 실행하는 서비스 - 서버에 대한 걱정없이 코드만으로 서비스를 실행, 이벤트 기반으로 실행되는 서버리스 컴퓨팅서비스 - 서버 및 운영 체제 유지 보수, 용량 프로비저닝 및 자동 확장, 코드 모니터링 및 로깅과 같은 컴퓨팅 리소스의 모든 관리를 자체적으로 수행하므로, Lambda가 사용하는 언어 중 하나로 코드를 제동하기만 하면 됨

Lightsail & EC2

Lightsail

가상 머신, 컨테이너, 데이터베이스, CDN, 로드 밸런서, DNS 관리 등 프로젝트를 빠르게 시작하는 데 필요한 모든 기능을 신속하게 이용 가능하도록 하는 VPC 서비스 (Virtual Private Server) 1대의 물리적 서버에 다수의 가상 서버를 구축 인스턴스, 컨테이너, DB, 스토리지, DNS 등을 한 곳에서 관리 가능

기능

1. Instance

• AWS 클라우드에 있는 가상 프라이빗 서버(VPS)
• 리전과 가용영역 선택, 인스턴스 이미지로 선택할 플랫폼과 블루프린트(미리 정의된 설정, 구성 및 자원의 모음) 선택
• 인스턴스 시작 시 스크립트 설정, SSH 키 페어, 데일리 백업 설정 및 인스턴스 플랜 설정
• 인스턴스 이름, 갯수, 태그 설정 후 생성, SSH접속이 가능하며, 방화벽 설정 가능
• 기본 수준의 CPU 성능을 발휘하면서 추가적으로 버스트 성능을 발휘할 수 있는 인스턴스 이용
• 즉 비디오 인코딩같은 어플리케이션과 같은 일관되게 높은 CPU 성능을 쓰려면 EC2 추천
• 가격에 따라 정해진 CPU, 메모리, 디스크 용량을 선택하게되고 정해진 가격만큼 과금되는 형식
• 한달 내내 실행시키되 트래픽이 많지않다면 EC2보다 훨씬저렴!
• 실행가능한 소프트웨어 ◦ 다양한 운영 체제와 자동으로 설치되는 인스턴스 이미지(AMI) 제공 ◦ 인스턴스 이미지에는 특정 운영체제와 소프트웨어 구성이 들어있음 ◦ WordPress, Django, Nginx(LEMP) Node.js, Ubuntu, CentOs 등이 있고, 브라우저 내 SSH 또는 자체적인 SSH 클라이언트를 사용하여 인스턴스에 소프트웨어를 추가로 설치할 수 있음 (1) Amazon Linux : 기본적인 웹 애플리케이션, 백엔드 서버, 개발 및 테스트 환경 등에 적합한 이미지. 여러 프로그래밍 언어와 관련된 라이브러리 및 도구가 설치되어 있음 (2) Ubuntu: 다양한 웹 애플리케이션, DB 서버, 컨테이너 환경 등을 호스팅할 때 사용. 널리쓰임 (3) WordPress: 블로그나 웹사이트 호스팅에 특화. Apache 웹 서버, MySQL DB가 미리 설치됨 (4) LAMP: Linux, Apache, MySQL, PHP를 포함한 전통적인 LAMP 스택을 위한 이미지. 웹 애플리케이션 개 발과 호스팅을 위해 널리 사용되는 이미지로, PHP 기반의 웹 애플리케이션을 개발할 때 적합. (5) Node.js: 노드 기반 웹 애플리케이션을 개발하고 호스팅에 사용. Node.js와 npm이 사전 설치됨

2. Container Service

• 클라우드에서 컨테이너형 애플리케이션을 쉽게 실행하도록 돕는 서비스
• 필요한 배포 이미지, 성능, 노드 수만 지정하면 인프라를 관리할 필요 없이 컨테이너 서비스 실행
• 도커 컨테이너 실행이 가능하며 windows 컨테이너는 지원되지 않음
• 단, Lightsail 컨테이너 서비스가 직접적으로 CDN의 오리진 서버로 사용될 수는 없음 - Lightsail의 컨테이너 서비스로 실행되는 애플리케이션을 CDN을 통해 직접적으로 분배하려면 추가적인 설정이나 중간 계층 필요
• 컨테이너 서비스는 Lightsail의 로드밸런스 대상이 될 수 없음
• Lightsail의 로드밸런서는 인스턴스 간의 트래픽을 분산하는 데 사용되지만, 컨테이너 서비스의 경우 수동으로 로드밸런싱을 해주어야 함

3. Database DBMS 선택 및 master user name, 데이터베이스 이름 설정, 데이터베이스 선택 가능

4. Networking 고정 IP : Lightsail로 만들어진 인스턴스에 고정 IP주소 할당 Distribution : 콘텐츠 전송 네트워크 (CDN) 기능 제공 Load Balancer : 트래픽을 여러 서버로 균등하게 나누는 기능을 제공 (ec2만큼의 퀄리티의 서비스를 지원해주지 않지만 간단하고 빠르게 필요하다면 매력적!!)

5. Storage Bucket 생성 : 파일, 이미지, 비디오등의 객체를 저장하고 엑세스하는 공간을 제공 Disk 생성 : 라이트세일 인스턴스에서 하드 드라이브로 마운트 할 수 있는 스토리지 볼륨

6. Snapshot 인스턴스나 디스크의 상태를 캡처하여 백업 또는 복원에 사용하는 기능 문제 발생시 백업, 애플리케이션을 확장을 위한 복제, 다른 AWS서비스로의 마이그레이션 등에 이용 (lightsail로 시작했는데 사용자 늘어난다면 스냅샷 찍은 후 AMI 만들어서 그대로 EC2로 옮길 수 있음)

7. DNS Zone 도메인 이름 시스템(DNS) 레코드를 관리하는 방식을 제공

EC2 (Amazon Elastic Compute Cloud)

AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공하는 서비스로, 하드웨어 투자 없이 빠르게 어플리케이션을 개발하고 배포하도록 가상 서버의 구축과 네트워킹 구성, 스토리지 관리등을 돕는 서비스

1. Amazon Machine Image (AMI) 도커의 이미지와 같은 역할이지만 EC2를 특정 환경으로 실행시키기 위한 레시피
   • 인스턴스를 실행하기 위한 정보를 모은 단위
   • 직접 만들 수 있으며, 백업에도 사용
   • Lightsail을 EC2로 마이그레이션 할 때에도 AMI를 이용

2. 보안 그룹과 키페어 (1) 보안 그룹: 가상 방화벽 역할을 하여 인스턴스로의 트래픽을 제어. 인바운드(들어오는)와 아웃바운드(나가는) 규칙을 정의하여 특정 트래픽만을 허용하도록 설정할 수 있다 (2) 키 페어: AWS에서는 공개 키 인프라(PKI)를 사용하여 인스턴스에 로그인함. 키 페어는 사용자가 EC2 인스턴스의 암호화된 로그인 정보를 안전하게 전달할 수 있는 방법을 제공 EC2 Keywords
   

공개 키(Public Key): AWS에서 인스턴스를 생성할 때 사용되며, 인스턴스 내부에 자동으로 저장 개인 키(Private Key): 사용자가 인스턴스를 처음 생성할 때 다운로드하며, 해당 키는 절대로 AWS에 업로드되지 않는다. 사용자만이 이 개인 키를 가지고 있어야 하며, 이를 사용해 EC2 인스턴스에 접근한다.

3. 탄력적 IP 주소(EIP) : 인스턴스 재시작시 바뀌는 IP 주소의 고정을 위한 것 (주의 : 프리티어에는 1개의 EIP가 포함되어 있는데 중단된 인스턴스와 연결되어 있거나, 아무 인스턴스와도 연결되어 있지 않으면 과금된다.)

4. 인스턴스 스토어 볼륨 : 인스턴스와 물리적으로 직접 연결된 스토리지(디스크 드라이브)로 임시 데이 터를 저장하는 스토리지 볼륨

5. Amazon Elastic Block Store(Amazon EBS) - 클라우드에서 사용하는 가상의 하드디스크 - EC2와 별개로 동작 -> 인스턴스가 종료되어도 별개로 작동 가능 - EC2와 같은 AZ에 있어야 함

Lightsail vs EC2