2024년은 나에게 많은 도전과 성장이 있었던 한 해였다. 다양한 개발 프로젝트를 수행하며 많은 것을 배웠다.

특히 친구가 요청했던 간단한 물류 관리 프로그램이 점차 확장되면서, 이제는 다른 고객들에게도 제공할 정도로 커졌다. 이 프로젝트는 나에게 소중한 경험이 되었고, 이를 계기로 사이드프로젝트로 관리 도구를 개발하게 되었다. 혼자서 데이터베이스 설계, 서버 구축, 호스팅까지 전 과정을 책임지며 개발하다 보니, 다양한 기술적 지식을 자연스럽게 습득하게 되었다.

하지만 아직 해결하지 못한 과제도 있다. 정보처리기사 자격증의 필기는 이미 2년 전에 통과했지만, 실기시험은 여전히 도전하지 못했다. 이러다가는 절대 못 딸 것 같아 2025년에는 반드시 꾸준히 공부해서 자격증을 취득하겠다는 목표를 세웠다.

또한 AWS SAP 자격증에도 관심이 생겨 공부를 시작했지만, 높은 시험 비용이 부담스러워 아직 도전하지 못했다. 이 자격증도 언젠가 꼭 취득하고 싶다.

2024년에는 특히 개발의 구조적, 동적 확장성을 고민하며 깊이 있는 개발 방식을 탐구했다. 어디까지 고려하고, 얼마나 완성도 높게 구현할 것인지에 대해 끊임없이 고민하며 시간을 보냈다. 그 결과, 개발의 폭넓은 시각을 가지게 된 점은 큰 성과였다.

2025년 목표

사이드프로젝트로 수익 창출

정보처리기사 자격증 취득

AWS SAP 자격증 취득

2. 웨이커

2024년을 통틀어 가장 큰 사건은 이직이었다. 신재생 에너지 솔루션 도메인을 떠나 전혀 새로운 도메인인 웨이커에 입사했다. 데이터 엔지니어로서 다양한 데이터를 수집하고 정형화하는 일을 하며 기술적인 성장뿐 아니라 새로운 도메인 지식도 기초부터 습득했다.

기간은 많이 짧지만 특히 내가 경험이 없었던 증권 분야에서 많은 것을 배우며 큰 흥미를 느꼈다. 증권 계좌조차 없었던 내가 직접 데이터를 다루고, 주식이라는 세계를 접하며 도파민이 펑펑 터지는 흥미로운 경험을 했다.

새로운 도메인에서의 업무는 도전적이었지만, 이 과정을 통해 성장하고 있다는 것을 느낄 수 있었다.

2025년 목표

실제 매출에 기여할 수 있는 상품을 2개 이상 개발

실패 없는 안정적인 데이터 수집 파이프라인 구축

딸깍 한 번으로 검증과 배포가 가능한 자동화된 파이프라인 개발

플랫폼 개발을 통한, 개발의 단순화

3. 취미생활

2024년은 취미 활동이 다소 제한적이었던 해였다. 별거 아니겠지 싶어 장난치다.공구를 잘못 다뤄 크게 다쳤고, 결과적으로 좋아하는 수상스키를 거의 타지 못했다. 23년에 50번 넘게 탔던 수상스키를 24년에는 5번도 채 타지 못한 것이 너무 아쉬웠다.

이 경험은 나에게 중요한 교훈을 남겼다. 공구는 함부로 다루거나 호기심을 가져서는 안 된다는 것을 깨달았다.

2025년 목표

수상스키 아마추어 대회 출전

스노우보드 자격증 취득

2024년은 도전과 배움으로 가득한 한 해였다. 다가오는 2025년은 이러한 경험을 바탕으로 더 큰 성취를 이루는 해가 되길 기대한다.

기존에는 도메인 -> API Gateway -> 서버(IP:port) -> 동작 이런 방식이였다면, Vpc link를 사용하여 도메인 -> Api Gateway -> NLB(Vpc link) -> Target Group -> 서버 의 동작의 형태로 변경할 예정이다. 기존에 x-api-key를 사용한 규칙은 그대로이니, 혹시 테스트할때 x-api-key를 꼭 사용해서 테스트를 진행하도록 하자

VPC link 연결 셋팅 순서

1. Target Group 생성
2. NLB 생성 및 Target Group 연결(리스너 연결)
3. EC2 보안 그룹 변경
4. Api Gateway 에 VPC Link로 NLB 연결
5. 배포 및 테스트

1.Target Group 생성

1. 나는 Target Group 에 Ec2를 연결할 예정이기때문에 instances를 선택했지만, endpoint에 서버IP,lambda, ALB를 연결하고싶다면, 변경해도 된다. 나는 EC2를 연결하려고 하기때문에 instance를 선택했다.
2. protocol은 TCP로 받아내고 port=20000을 했다. 내가 이전글에서 만들어놓은 dummy서버가 20000port로 동작하기 때문.
3. AWS를 사용하고 있다면, 당연히 VPC도 개별적으로 구축해서 만들었다고 생각하고 진행하겠다. Default외에 자신이 구축한 신규 VPC 가 있다면 거기에 연결해도 된다.

   단! VPC 내부의 IP가 어떤건지는 정확히 알고 있어야 한다. 또한 생성한 EC2도 같은 VPC내부에 있어야 한다.

   나는 내가 구축한 VPC로 연결하겠다. IP는 내부라서 추후에 같이 볼 수 있도록 하겠다.

개인 적으로 사용하는 서버 및 회사의 서버도 있기 때문에 가린것은 양해를 구합니다.

생성한 EC2를 선택하고 Target Group에서 보낼 port를 적은후 pending하여 아래에 포함하고, 생성을 누르자.

아직 NLB에 연결이 되어있지 않기 때문에 health check 가 되지 않는다, 무시하고 NLB랑 연결을 진행하도록 하자

2.NLB 생성 및 Target Group 연결(리스너 연결)

내가 생성한 VPC를 선택하자 내가 가용하는 VPC 내부 영역은 [ap-northeast-2a, ap-northeast-2c] 두가지다 public으로 구현 하도록 하겠다.

연결할 리스너를 Target Group에 맞춰서 protocol 과 port를 설정하는것이 중요하다. 리스너를 추가로 생성하여 여러가지의 라우팅리스너를 만들고 싶다면 Add listener를 여러개 해도 무방하다.

만약 내가 생성한 Target Group이 나오지않는다면 새로고침을 눌러 다시 확인을 해보자. summart를 확인하여 내가 만든 설정값이 맞는지 확인하고 생성을 눌러주자

3. EC2 보안 그룹 변경

EC2 콘솔로 들어와 다음과 같이 확인해보자 내가 생성한 dummy 서버의 보안그룹은 0.0.0.0 으로 모든 방화벽이 열려있다. 이걸 내가 생성한 VPC에 맞게 변경할 예정이다. 변경 하고 나면 Gateway랑 연결하기 전까지 통신은 불가능하다.

보안그룹을 VPC내부 IP에 맞게 변경해주자

1. 나의 VPC 내부 IP이다 가용영역에 따라 다르기 때문에 IP를 신경써서 변경해주도록 하자
2. 나의개인 로컬 IP이다.

4. Api Gateway 에 VPC Link로 NLB 연결

이전에 만들었던 Api gateway로 콘솔로 들어가보자.

Target NLB에 내가 생성한 NLB를 선택한다. 선택 리스트에는 이름으로 나오지만 선택이 되면 해당 NLB의 DNS로 나오기 때문에 걱정하지 말자. 가용 영역내의 NLB추가하는데에는 시간이 걸릴수도 있으니 조금만 기다려보자

여기 까지 했으면 여태동안 연결한 것들이 정상적으로 동작하고 있는지 확인해 보면서 기다려보자.

1. NLB에서 Target Group으로의 protocol 및 연결 상태 확인
2. Target Group의 health status 확인

   NLB의 DNS를 꼭 기억할것!!!!!!!!

   Jinho-VPC-NLB-ed6403bdde7604fd.elb.ap-northeast-2.amazonaws.com

위처럼 healthy로 동작되는지 확인해보자. 만약 healthy가 아니라연결이 안된다면, 서버에 flask가 해당포트로 동작하지 않을수도 있으니 확인하고, pending한다음에 다시 재연결 해보자

Vpc link 탭에 위 사진처럼 pending이 없어졌다면, 이제 Gateway안에 연결할 Method 쪽으로 들어가자

1. 연결타입에 VPC link를 선택하고, 동일하게 proxy를 사용하니 체크하도록하자
2. VPC link 에는 내가 생성한 VPC link를 선택하자
3. Endpoint URl에는 꼭 http 와 포트 , proxy를 작성하도록 하자

5. 배포 및 테스트

배포의 방법은 이전과 똑같다. 새로운 배포탭을 만들어도 되고, stage만 변경해도된다. 나는 동작 방식이 바뀌었으니, 새로운 Stage를 만들도록 하겠다. 정상적으로 배포가 되었으면 도메인에 연결된 API 매핑을 변경해줘야한다. 위처럼 stage를 변경하고 저장하도록 하자

배포 끝났으니 테스트를 해보자. 정상적으로 통신이 되는것을 확인할수있다. 성공~

AWS Gateway[1,2,3]을 구축하면서 빙빙돌아 실수했던부분을 정리해보자

1. Auth 인증 Lambda를 만들때 코드 및 API Keys를 정확하게 사용하자.
2. 테스트를 중간중간 진행하면서, 구축하자. 그냥 되겠지하고 만들다가 나중에가서 막히면 어디서 문제가 발생했는지, 찾기가 너무 힘들다.
3. API Gateway 의 콘솔에 Endpoint를 정확하게 http,https:// 부터 맨뒤의 port, url까지 정확하게 쓰자
4. VPC link에 NLB DNS를 정확하게 쓰기
5. EC2의 보안 그룹(VPC IP로 변경) 신경쓰자 NLB부터 통신이 안되서 뭐가 문제였는지 찾는데 한세월...
6. Target Group 포함 시킨 EC2 안에 서버가 정상적으로 가동되고있는지 확인하자[포트도 확인]
7. API gateway를 배포할때 Stage를 변경하였다면, 꼭 Custom Domain에 stage 매핑을 변경하도록하자

두번째 포스팅하는건데 캡쳐하고 박스하고 이런것들, 또 내가 개인적으로 사용하는 IP, DNS, VPC 가용영역,, 혹시 몰라서 검정박스로 쳤는데, 너무 지저분한거같다.. 다음 포스팅은 더 깔끔하고 두서있게 정리할 수 있도록 노력해야겠다.

!!수고하셨씁니다!!

먼저 api gateway를 통한 auth 인증에는 두가지가 있다.

1. api gateway 안에있는 기능(API Keys) 사용하여 API key 사용여부를 설정하는 방법
2. lambda를 통한 인증방법

오늘은 위의 두가지를 연습해보자

[1]먼저 API Keys를 사용한 인증방법

1. API keys 생성
2. 사용량 계획 생성
3. gateway 배포
4. 테스트

순서로 진행을 해보겠다.

1.API keys 생성

내가 생성한 gateway안에 API keys -> Actions 버튼안에 create Api key를 클릭하면 우측빨간 박스처럼 생성된다. Auto generate 는 자동으로 키가 생성되고, custom은 내가 생성하는 키 이다. 생성을 맞췄으면 save를 눌러주자

2.사용량 계획 생성

Throttling,Quota는 최대 API요청수를 제한하는것이다. 나는 단순 테스트 이기 때문에 둘다 체크하지 않고 다음으로 진행하겠다.

사용량 계획이 만들어졌다면, 배포했던 Stage를 이 사용량 계획에 추가해줘야한다.

또한 Api Keys에 내가 만든 Key 이름을 적어준다.

이렇게 하면 자동으로 내가 생성한 Api key에 연결이 된다.

3.gateway 배포

이제 key 사용여부 변경후 배포하기 위해 resource 에 들어간다. 아래처럼 false -> True 로 변경해준다.

이제 다시 배포한다.

4.테스트

나는 api requests 테스트를 하기위해 postman을 사용한다. 위의 key부분이 비활성화 되어있으므로 지금 현재 message가 forbidden으로 리턴되고있다.

아까 생성했던 API keys에 key값을 넣고 다시한번 요청을 보내보자 해당 값을 넣고 보내면 성공하는 것을 확인할 수 있다.

만약 여러 서비스합쳐서 운영하는 곳이라면 여러개의 api key 를 같은 Api Gateway에 추가하여 서비스를 막거나, 추가로 연결해주거나 할 수 있을것 같다.

여러개의 api key를 추가하는 방법은 사용량 계획에 추가했던 방식을 여러번 반복하면 된다.

[2]lambda를 통한 인증방법

이건 사실 나도 정확한 방법인지는 잘 모르겠지만, 람다를 통해 내가 코드로써 인증 및 여러가지를 커스텀 할 수 있다는것이 장점인것같다. 람다를 사용하는것도 매우 좋은 경험이라 시도해봤다.

1.lambda 생성 및 lambda 코드 작성 2.Api gateway 연결 3.Resource 수정 및 배포 3.테스트

1.lambda 생성 및 lambda 코드 작성

이미 내가 한번 만든 이름이라 중복확인이 뜨는것이니 무시하셔도 된다. 이렇게 코드를 작성해본다.

아! 코드를 다 작성한 이후에는 Test옆에있는 Deploy를 눌러 꼭 배포해주도록하자 그렇지않으면 저장된 코드로 람다가 실행되지 않는다

// A simple token-based authorizer example to demonstrate how to use an authorization token 
// to allow or deny a request. In this example, the caller named 'user' is allowed to invoke 
// a request if the client-supplied token value is 'allow'. The caller is not allowed to invoke 
// the request if the token value is 'deny'. If the token value is 'unauthorized' or an empty
// string, the authorizer function returns an HTTP 401 status code. For any other token value, 
// the authorizer returns an HTTP 500 status code. 
// Note that token values are case-sensitive.

exports.handler =  function(event, context, callback) {
    console.log(event)
    console.log()
    var token = event.authorizationToken;
    switch (token) {
        case 'zlO0zj2evv9kBA7Bi3zxC6swfQNB2TsKZtvuA4Nj':
            callback(null, generatePolicy('user', 'Allow', event.methodArn));
            break;
        case 'deny':
            callback(null, generatePolicy('user', 'Deny', event.methodArn));
            break;
        case 'unauthorized':
            callback("Unauthorized");   // Return a 401 Unauthorized response
            break;
        default:
            callback("Error: Invalid token"); // Return a 500 Invalid token response
    }
};

// Help function to generate an IAM policy
var generatePolicy = function(principalId, effect, resource) {
    var authResponse = {};

    authResponse.principalId = principalId;
    if (effect && resource) {
        var policyDocument = {};
        policyDocument.Version = '2012-10-17'; 
        policyDocument.Statement = [];
        var statementOne = {};
        statementOne.Action = 'execute-api:Invoke'; 
        statementOne.Effect = effect;
        statementOne.Resource = resource;
        policyDocument.Statement[0] = statementOne;
        authResponse.policyDocument = policyDocument;
    }

    // Optional output with custom properties of the String, Number or Boolean type.
    authResponse.context = {
        "stringKey": "tmp",
        "numberKey": 123,
        "booleanKey": true
    };
    return authResponse;
}

코드에 case zlO0zj2evv9kBA7Bi3zxC6swfQNB2TsKZtvuA4Nj 에 내가 저번시간에 만들었던 키를 그대로 사용하도록하겠다. 마음대로 변경해도 상관없다.

최종 코드

exports.handler =  function(event, context, callback) {
    var token = event.authorizationToken;
    switch (token) {
        case 'zlO0zj2evv9kBA7Bi3zxC6swfQNB2TsKZtvuA4Nj':
            callback(null, generatePolicy('user', 'Allow', event.methodArn));
            break;
        default:
            callback("Error: Invalid token"); // Return a 500 Invalid token response
    }
};

// Help function to generate an IAM policy
var generatePolicy = function(principalId, effect, resource) {
    var authResponse = {};

    authResponse.principalId = principalId;
    if (effect && resource) {
        var policyDocument = {};
        policyDocument.Version = '2012-10-17'; 
        policyDocument.Statement = [];
        var statementOne = {};
        statementOne.Action = 'execute-api:Invoke'; 
        statementOne.Effect = effect;
        statementOne.Resource = resource;
        policyDocument.Statement[0] = statementOne;
        authResponse.policyDocument = policyDocument;
    }

    return authResponse;
}

필요없는 주석 및 사용하지 않는 함수 조건등을 삭제하여 간단하게 적용했다.

위의 코드 및 (Token, request)에 대한 설명은 AWS 안내서에 설명되어있다. https://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html

이미 내가 트리거를 만들어서 API Gateway가 추가되어있지만 없다고 가정하고 추가를 해보자 Existing Api 에서 내가 만든 Api gateway를 선택하고, 배포 stage를 선택한다 security 도 IAM role을 따른다.

이렇게 트리거를 만들지않으면 API gateway로부터 요청을 받아낼수가 없다.

2.Api gateway 연결

lambda를 다 만들었다면, 이제 다시 Api Gateway쪽으로 돌아오자

Authorization Caching은 enabled 에 체크를 해제하자, 뭐때문인지, 체크를하면 요청이 연속적으로 들어가지 않는다.

Lamdba Function 에 내가 만든 lambda를 연결해주자

그리고 Event Payload에는 두가지 방법이있는데 Token으로 인증할것이냐, Requsts요청방법으로 인증할것이냐로 나뉜다, 두개의 설명은 위에 링크해놓은 AWS공식 문서에 나와있다. url path나 더 여러가지의 Querystring 등등으로 사용하여 key값을 다르게 설정하고싶다면, request방법을 써서 custom하는게 더 효과적인것 같다.

위처럼 설정하고 create를 눌러 생성해보자

위처럼 Test를 할텐데 내가 저장한 키로 요청을 보냈을때

다른 키로 요청을 보냈을 때 아무것도 보내지않았을때

정상적으로 결과가 리턴되는것을 볼수있다.

3.Resource 수정 및 배포

이제 Resource로 들어가서 Key 조건을 걸고 싶은 method로 들어가자

위처럼 변경해주자 새롭게 생성한 Authorizers이 보이면 클릭해주면된다, 만약 보이지않을경우, AWS콘솔을 다시 키거나 새로고침하면 보이니까 참고하자

기존에 사용하던 Stage에 배포를 쌓아주자

4.테스트

postman을 사용하여 요청을 보내보면 정상적으로 작동하는것을 확인할 수 있다

다음시간엔 서버를 로드밸런서에 연결해 vpc link를 사용하여 방화벽 및 보안에 더 신경쓴 작업을 하겠다.

작업간 내용 확인 할 것

1. Lambda의 코드를 수정하고 나선 무조건 Deploy를 눌러서 배포해주기
2. Api Gateway 작업을 수정하고나선 무조건 Deploy를 눌러 배포하기
3. 혹시 Api Gateway작업을 수정 하고 배포도[Stage를 새롭게 만들었을경우] 했는데 도메인에 연결이안된다면 Custom Domain Names쪽에서 Api mapping 수정해주기!
4. 그래도 안된다면, Auth 쪽에서 무언가 실수가있었는지 테스트를 꼼꼼하게 해보기 람다에서 Cloud watch로 로그를 볼수있으니까 활용해보기

혹시 추가 질문사항이나 안되는것이 있다면 알려주세요... 저도 처음이라..

내가 직면한 문제는 아래와 같다

1. 서버(개발, 운영) 에서 추가 IP 및 도메인 변경 등등의 문제로 협업 업체와의 통신 규칙 추가
2. 신규 기능 개발(API) 서버의 리소스가 부족한경우 다른 서버에 API서버를 돌려야하는데 그때 마다 통신규칙 및 방화벽 추가
3. 개발과 운영 서버의 도메인 통합 ex) https://dev.jinhoserver.com/{proxy}, https://prod.jinhoserver.com/{proxy}

서비스하는 서버에서 다른 협업하는 업체와의 테스트 및 운영을위해 도메인 및 IP로 통신하는데 개발서버의 IP가 바뀐다거나, 운영하는서버가 더 늘어날때마다 방화벽 및 보안규칙을 새롭게 등록하는데에 많은 공수와 시간이 드는것을 해결하고자 한다.

신규 API기능을 추가할때 서버마다의 특성을 고려하여 route규칙으로 새롭게 blueprint하여 코드 및 소스의 특성을 정리하고자 한다.

처음엔 그냥 EC2에 Kong이라는 docker images로 된 api gateway를 사용하려고 했으나, 이거를 사용하여 또다른 서버의 리소스를 낭비하는것이 맞는가, 또한 관리나 유지보수에 대한 공수가 많이 들것으로 예상하였다. 그리고 사용하지 않는 가장 큰 이유는 , 개발과 운영 서버의 도메인 통합 ex) dev.jinho.com, prod.jinho.com 등으로 한번에 관리할수가 없었기 때문이다. 물론 GUI또한 웹페이지로 바로 보여서 간단하고 누구나 사용할 수 있지만, 추후에 docker image 버전이나,, 등등을 감당하기 어려울 것 같다.

작업 순서

1.Api Gateway 생성 2.Resource, Method 생성 3.proxy 설정 및 예제 서버 코드 작성 4.배포 5.도메인 연결

API GATEWAY 작업 시작

AWS에 들어와 검색창에 api gateway를치면 아래와 같이 나온다. 우측 상단에 보이는 create Api를 클릭하자 우리는 3번째에 있는 REST API 를 빌드한다.

1. 만약 Python Fast Api 를 사용한다면, 자동으로 swagger 가 만들어지니 그걸 import 해서 사용하면 조금더 편리하고 빠르게 만들어 낼 수 있다. 나는 flask 를 사용하여 만들예정이라 new api를 선택했다.

2. Api gateway 이름과 앤드포인트를 설정하면되는데, 여기서는 나는 Seoul region안에 있는 ec2로 정할 거라서 regional을 선택한다. 만약 private 으로 설정한다면 내가 생성한 특정 vpc id정보를 쓰면 거기로만 통신할 수 있게 만들수 있다.

3. Create Method는 [delete,post,get,...] 등등등 생성할수 있다. url prefix는 현재 아무것도 없다.

4. Create Resource를 클릭하면 아래와 같다.

proxt resource 를 체크 하면 https://jinhoserver.com/{proxy}로 생성되게 되는데, 이렇게 된다면 , / 뒤에오는 모든것이 동적으로 변경이 가능하게 된다. 변수를 일일히 설정할 필요가 없이, endpoint에서 받아낼수 있다. 나는 proxy는 그 뒤에서 설정하고 여기서는 운영과 개발 두가지로 나누겠다.

아래 보이는 Enable Api gateway Cors 는 웹에서 받아낼때 cors 설정 유무 이다. cors는 웹[브라우저] 에서 백서버로 어떠한 정보를 넘기고 받을때 option method로 본요청이 전송되기 직전에 요청되는데, 이때 이걸 flask에서는 make response를 사용하여 성공으로 반환하고, 그이후에 본요청을 받게된다.[내가 사용하는 방법이다]

이걸 따로 서버쪽에서 처리하기 힘들다면 클릭하고 넘어가도록 하자.

dev로 resource를 만들고 그 하위에 proxy resource를 만든다면 아래와 같이 생성된다.

여기서 받아낼 endpoint를 정하면되는데,

1.lambda는 AWS안에 생성한 lambda로 바로 요청하여 별도의 서버없이 간단한 요청들을 처리할 수 있다. 2.HTTP Proxy는 특정한 서버의 endpoint로 요청하게된다. 3.VPC Link 는 내가 생성해놓은 VPC안에 특정 Network loadbalancer로 요청할 수 있다.[추후에 기회가 있다면 다시 설명하도록 하겠다.]

나는 2번 HTTP proxy로 설정하겠다. endpoint url에 받아낼 서버의 url로[포트가 필요하다면 url:~/{proxy}] 작성하고 !!꼭 뒤에 /{proxy}를 쓰도록하자

여기 까지 다했다면 잠깐 서버쪽 코드를 작성해보도록 하자. 나는 일단 간단하게 기존에 사용하던 서버 코드를 가져와서 testapi 를 만들었다.

이제 테스트를 위해

proxy 아래 생성된 Any 메서드를 클릭하면 우측과 같은 화면이 나온다. 이후 TEST를 눌러서 진행해보자

내가 만든 api함수로 요청되는것을 확인할수있다. 만약 테스트하는데 405에러가 뜬다거나, 요청이 제대로 가지않는다면 내가 만든 EC2서버에 보안규칙을 확인하길 바란다, 내가 공부한바로는 AWS API gateway는 계속 IP가 바뀌면서 요청되는데 왜이러는지는 알수가없다, 그래서 EC2의 보안규칙을 다열어야 하는데, 만약 이러한행동이 리스크가 크다면, VPC링크와 인증키 방식을 같이 사용하는것이 훨씬 좋다.

여기서 proxy로 만든것의 장점이 적용된다, 하나의 method를 만든것만으로 많은 api함수를 생성해낼수있다.

만약 특정 method방법으로 좀더 세분화 하고 싶다면, 아래와같이 여러개를 생성할수있다.

각각 method요청방법에 따른 endpoint도 따로따로 설정 할 수 있다. 예를 들어 단순 조회같은경우는 lambda를 사용하여 연결하면 db접근해서 간단한 쿼리를 사용해 조회할수있을것이고, 여러가지로 분산시켜 API를 개발할수있다

이제 실제 서비스를 할 수 있도록 배포를 해보겠다.

스테이지를 새롭게 생성하고 test로 이름을 만들어주자

빨간박스1번은 배포를 한 API gateway의 url이다 테스트를 해보자면 위와같이 내가 예상한 결과로 리턴되는것을 알 수 있다.

Log/Tracing 은 클라우드워치를 통해 로그 추적들을 사용여부를 변경할수있다. export는 swagger, openApi 3 등등으로 뽑아낼수있다. Deployment History는 배포 히스토리를 봄으로써 롤백 등등이 유용하다.

이제 저 invoke url을 사용하여 서비스를 할수 있게 되었다. 완벽한 서비스 및 개발 서버 배포를 위하여 도메인을 연결해보도록하겠다. 나는 AWS Route 53에 *.#######.com 으로 ssl인증서가 있으니 그걸 통해서 사용하겠다.

custom domain names을 생성했다면 아래와 같이 detail이 생성된다. 아래 처럼 configure API mappings에 들어가도록하자

내가 생성한 API 를 선택하고 만든 배포 Stage를 선택하고 save클릭하면 거의 다왔다.

이제 도메인을 route53에 등록만 하면 끝이다. 내가 사용하는 도메인 대시보드로 들어와 record를 새롭게 생성한다. 방금전에 생성한 API GateWay domain name과 똑같은걸 선택한다. create누르면 끝! 위처럼 나오면 끝이다! 수고하셨습니다.

2탄에서는 VPC link와 인증키 방법에 대해서 설명하겠슴다. 일단 여기까지했으면 쉬자..

_추후에 또 도메인을 만들거나 추가로 할일이 있다면 도메인에 대해서도 글 쓰도록 하겠슴니다. _

아래처럼 유저 리스트에 나오면 성공이다. Github_Actions_user의 access id,key를 꼭 기억하고있어야한다. 추후 github setting 환경변수에 사용하기 때문이다.

S3버킷을 생성해주고, 그안에 디렉토리를 하나 생성해보자

기본설정으로 버킷을 생성한후에 아래와 같이 리스트에 나오면 된다.

이제부턴 github 설정이 필요하다. 지금부터 살짝 어려우니 잘따라오길 바란당.

일단 나는 github action을 통해서 s3에 zip파일을 업로드하려고 하니까 action을 사용해야한다. 그 전에 github setting에서 aws access ID,KEY,Region을 등록해야한다. Actions에 들어가서 아래와 같이 key,value를 설정하면된다. 우측상단에 New repository secret을 눌러 생성한다.

이전에 저장해놨던 Github_Action_user의 id,access key, region 셋다 등록을 해준다.

이제부터 중요하다. github의 root디렉토리에 아래와같이 파일을 만들어준다. 이 파일은 EC2에 업로드되었을때 어떤실행을 할지 명령하는 것이다. hooks: 에는 afterInstall 말고도 엄청나게 많은 구분단계가있다. 여기서는 간단하게 인스톨이 끝난후에 어떤명령을 할지 적어놓았다.

back_up.sh

#!/bin/bash
now_dir_path=`pwd -P`
CUR_DATE='backup_'`date +%Y%m%d`
mkdir -p /home/ubuntu/$CUR_DATE

cp -r /home/ubuntu/smart_mirror /home/ubuntu/$CUR_DATE

cd /home/ubuntu/smart_mirror/
rm -rf `ls /home/ubuntu/smart_mirror/ | grep -v logs | grep -v keys`
rm -rf .git

cd $now_dir_path
cp -i -rf smart_mirror/* /home/ubuntu/smart_mirror/
cp -i -rf smart_mirror/.git /home/ubuntu/smart_mirror/

나는 만든 쉘스크립트는 살짝 야매라고 생각한다 backup파일을 해당날짜로 생성한후, .git 속성을 복사해서 업데이트되는 파일에 속성을 부여하는것이다.

run_docker.sh

echo killing old docker processes!
cd /home/ubuntu/smart_mirror
docker-compose rm -fs

echo building docker containers
docker-compose up --build -d

단순하게 이미 실행되고 있는 컨테이너를 종료한후 다시 빌드후에 실행한다.

다음은 github의 workflows 쪽이다. .github/workflows/aws.yml 을 추가한다. 위의 템플릿은 marketplace에 엄청나게 많다. 나는 이미 사용하고있는게 있어서 이전에 사용했던것과 동일한것을 복사해왔다.

name: Deploy to Amazon ECS

on:
  push:
    branches:
      - main

env:
  AWS_REGION: MY_AWS_REGION                   # set this to your preferred AWS region, e.g. us-west-1
  ECR_REPOSITORY: MY_ECR_REPOSITORY           # set this to your Amazon ECR repository name
  ECS_SERVICE: MY_ECS_SERVICE                 # set this to your Amazon ECS service name
  ECS_CLUSTER: MY_ECS_CLUSTER                 # set this to your Amazon ECS cluster name
  ECS_TASK_DEFINITION: MY_ECS_TASK_DEFINITION # set this to the path to your Amazon ECS task definition
  ZIP_NAME: export NAME:${GITHUB_SHA}


jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ secrets.AWS_REGION }}


    - name: zip create
      run: |
        echo ${GITHUB_SHA}_build.zip
        zip -qq -r ./${GITHUB_SHA}_build.zip .
      shell: bash

    - name: Upload to S3
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: ${{ secrets.AWS_REGION }}
      run: aws s3 cp --region ap-northeast-2 ./${GITHUB_SHA}_build.zip s3://jinho/smart-mirror/${GITHUB_SHA}_build.zip

    - name: Deploy
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: ${{ secrets.AWS_REGION }}
      run: aws deploy create-deployment --application-name my-CICD --deployment-config-name CodeDeployDefault.OneAtATime --deployment-group-name groupName --s3-location bucket=jinho,key=smart-mirror/${GITHUB_SHA}_build.zip,bundleType=zip

자 이제 이 파일을 해석해보도록하겠다. 생각보다 어렵지않다.

on:
  push:
    branches:
      - main

이부분은 다들알겠지만, 브랜치가 main인것으로 push되면 이 action을 실행하겠다는 말이다.

env:
  AWS_REGION: MY_AWS_REGION                   # set this to your preferred AWS region, e.g. us-west-1
  ECR_REPOSITORY: MY_ECR_REPOSITORY           # set this to your Amazon ECR repository name
  ECS_SERVICE: MY_ECS_SERVICE                 # set this to your Amazon ECS service name
  ECS_CLUSTER: MY_ECS_CLUSTER                 # set this to your Amazon ECS cluster name
  ECS_TASK_DEFINITION: MY_ECS_TASK_DEFINITION # set this to the path to your Amazon ECS task definition
  ZIP_NAME: export NAME:${GITHUB_SHA}

위 부분은 settings에 설정했던 환경변수들을 불러와서 사용할수 있도록 해주는 곳이다. 만약 settings에서 환경변수를 설정하기 싫다면, 여기에서 문자열로 대입해도 문제가 없다.

    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ secrets.AWS_REGION }}


    - name: zip create
      run: |
        echo ${GITHUB_SHA}_build.zip
        zip -qq -r ./${GITHUB_SHA}_build.zip .
      shell: bash

    - name: Upload to S3
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: ${{ secrets.AWS_REGION }}
      run: aws s3 cp --region ap-northeast-2 ./${GITHUB_SHA}_build.zip s3://jinho/smart-mirror/${GITHUB_SHA}_build.zip

    - name: Deploy
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: ${{ secrets.AWS_REGION }}
      run: aws deploy create-deployment --application-name my-CICD --deployment-config-name CodeDeployDefault.OneAtATime --deployment-group-name groupName --s3-location bucket=jinho,key=smart-mirror/${GITHUB_SHA}_build.zip,bundleType=zip

나의 workflow는 .zip파일을 만든후에 s3에 해당 zip파일을 올린다. region 은 자기가 해당하는 리전을 꼭 쓰도록한다.

      run: aws deploy create-deployment --application-name my-CICD --deployment-config-name CodeDeployDefault.OneAtATime --deployment-group-name groupName --s3-location bucket=jinho,key=smart-mirror/${GITHUB_SHA}_build.zip,bundleType=zip

애플리케이션 이름은 우리가 만들었던 이름을 사용하면된다. --deployment-config-name 은 우리가 설정한 것들중 한개를 선택하면된다.

여기까지하고 어떤것이던 push를 해보자 음 Upload to S3는 성공으로 실행되지만 Deploy 하는쪽에서 실패했다. 그럼 S3에 가서 .zip파일이 업로드되었나 확인해보자 잘 올라간것을 확인해볼수있다. 아! EC2에 codeDeploy agent 설치를 안했다. 설치를 진행해주도록 하자

$ aws s3 cp s3://aws-codedeploy-ap-northeast-2/latest/install . --region ap-northeast-2

./install을 설치후에 권한을 변경하고 실행시킨다

$ chmod +x ./install && sudo ./install auto

다시한번 main에 push 해보자

1. action은 성공적이다 다음은 s3에 정상적으로 파일이 업로드 되었는지 확인해보자

2. s3에도 정상적으로 파일이 업로드 되었다. codedeploy에 가서 배포그룹을 살펴보자

3. aws애플리케이션에 들어가서 배포 그룹을 확인해보자

4. 다음은 EC2에 들어가서 내가 원하는데로 이루어졌는지 확인해보자

• 도커 컴포즈는 정상적으로 실행되고있다.
• 원하는대로 백업파일이 해당 날짜로 생성되었다.

성공적이당ㅇ!

git에 코드를 푸쉬하는 순간부터 s3에 업로드되고, EC2서버에 자동으로 배포하며 트래픽을 막는순간부터 배포이후 실행하기 까지 다 했다.

나아가 더 해보고싶은단계는 좀더 디테일하게 트래픽을 막는순간부터 install단계를 나눠서 해보고 싶다. 시간적여유가 생긴다면?

처음으로 쓰는 Velog 여서 너무 앞뒤도안맞고 문법에 맞게 쓴지도 모르겠다.

이글의 최종목적은 서버로부터 최말단에 있는 스마트 PC로 코드가 자동으로 업데이트되며, 이력을 남기고 재실행시키는것이 나의 목표이다. 만약 폐쇄망에있는 PC의 경우에는 아웃바운드 규칙을 열어 서버로 API를요청하고 최신코드를 받아내어 배포를 수행하는 스크립트 작성까지가 목표이다.

github에 action을 사용해서 s3에 코드를 업데이트하고 ec2의 codedeploy agent가 s3에 이력이 생기면 최신코드를 가져와서 특정 스크립트를 실행시키게 하는것이다.

이러한 서비스를 구상하게 된 계기는 서비스하는 곳에 외부에서의 접근을 혀용시켜주지않았다. 해당폐쇄망에서 EC2에 있는 서버로는 ip와 port를 열어 줄 수 있다고해서 프로세스를 기획하게 되었다.

먼저 해야할 것은 IAM을 생성하는것이다.

사용사례에서 CodeDeploy를 선택한후 다음을 누른다. 위와같이 권한을 확인한후 넘어간다. 나의경우에는 권한경계설정은 하지않았다. 역할 이름과, 설명을 자기가 원하는데로 작성하고 신뢰할 수 있는 엔티티 및 다른 권한추가 없이 역할 생성을 누른다. 위의 태그는 태그로 이 IAM역할을 찾으려면 설정해도 무방하다. 위처럼 리스트에 내가 만든 code-Deploy 역할이 나오면 성공이다.

다음은 애플리케이션 codeDeploy 생성이다. 우측 상단에 생성을 눌러주자.

여기서도 이름을 자기가 원하는대로 작성한후 플랫폼을 EC2/온프레미스를 선택하고 생성한다. 위와같이나오면 이제 배포그룹을 생성한다. 배포그룹은 내가 배포서비스를 설정할지 정해준다.

여기서도 배포그룹 이름을 입력하고 서비스역할에는 내가 만든 IAM 권한이 있을것이다. 해당 서비스를 선택한다. 배포 유형은 현재위치/블루그린 두가지가 있다 간단하게 설명하자면 블루/그린은신버전의 서버로 한번에 업데이트시킨다. 그러므로 트래픽, 서버의 오류 등에 대해서 일순가에 커버가 불가능하다는 단점이있다.

현재위치는 해당하는 서버를 잠시동안 멈추고 업데이트한후에 실행하는 배포 방식이다. 해당 유형을 선택할경우 로드밸런서를 사용하여 여러개의 서버를 업데이트할때 유용하다. 예를들어 두개의 서버(A,B)가 로드밸런서에 연결되어있다고 가정하자. A가 업데이트될때에는 로드밸런서에서 자동으로 트래픽을 막아놓고 업데이트한후에 트래픽을 허용한다. 정상적으로 트래픽허용이 끝나고 성공적으로 배포가 이루어졌으면, B의 트래픽을 막고 배포 후에 트래픽을 허용한다. 무중단 배포가 가능하다.

하지만 나는 이번에는 로드밸런서를 사용하지 않을거기때문에 어떤것을 사용해도 상관없다.

연결하고자 하는 EC2의 이름으로 선택한다.

배포 설정에는 어떤것을 사용해도 상관없지만 자신이 해당하는 상황에 맞춰서 해야한다. 서비스를 중단할수없을경우 로드밸런서를 사용하여 OneAtATime을 사용하여 순차적으로 각각의 EC2에 배포하는것이 좋을것같다. 서비스하고있는 서버의 갯수가 많다면 HalfAtATime도 나쁘지않을것같다. 내가 일전에 만들어놓은 서비스는 두개의 EC2를 NLB,ALB 로드밸런서로 연결하였기때문에, OneAtATime을 선택하였다.

다 만들었으면 배포그룹 생성을 클릭하자

여기까지 했으면 일단 쉰다.

기본적으로 내가 개발에 사용하는 통신방식은 http통신이다.

각각의 핸들러는 실행되는 순서에 따라 나뉜다.

• before_first_request() 웹서버 실행이후 가장 먼저 처음으로 들어오는 api요청에만 실행된다.
• before_request() 매 api요청마다 실행된다.
• after_request(response) http 요청이 실행되고 api발신지로 return 하기 전에 실행된다.
• teardown_request(exception) api발신지로 return 한 후에 실행된다.
• teardown_appcontext(exception) (http요청이 완전히 완료되면 실행된다는데. 이것과 teardown_request와 차이점은 아직 모르겠다.)

내가 핸들러를 사용하는 가장큰 목표는 가시적으로 프로세스단위의 로그를 한눈에 확인할수있도록 하는데에 중점을 두었다.

먼저 아래와같이 시작하기전에 각 요청의 파라미터와 요청 방식(post/get)인지 확인할수 있도록 했다.

위와 같이 로그가 남은후에 각 프로세스마다 실행결과를 각각 로그로 남겼다.

이후 모든 프로세스의 실행이 끝난이후에 어떤결과값이 리턴이 되었으며, 해당 결과를 로그로 남기기 위하여 after_request(response)를 사용했다.

response값을 로그로 남기기 위하여 엄청 애를 썼다. after_request의 매개변수인 response를 표현하기위하여 온갖 방법을 다 써봤는데 다 실패한후, 구글링을 통해 찾을 수 있었다.

response의 type은 <class 'flask.wrappers.Response'> 이고 프린트를 찍었을땐 <Response 45 bytes [200 OK]> 결과의 status_code만 나오는것이 확인되었다.

결국 response의 data값을 뽑아내어 바이트의 형식의 값을 decode하여 표현했다.

예외처리한 이유는 api요청에서 로그로 남기는 작업보다 프로세스의 실행과 return 은 무조건 되야한다고 생각했기에 finally를 사용했다.

나중에 기회가 된다면, http 요청 핸들러를 더 깊게 공부할 수 있는 기회가 오면 좋겠다.

-- 처음작성하는 velog 재밌당