S3 버킷 CORS 설정 (json)

S3 의 CORS 설정이 기존 XML 방식에서 Json 방식으로 변경이 되었다 ‘ㅅ’a

웹콘솔에서 s3 버킷을 선택 하고 관리 탭의 하단에 있다.

사실 문법만 틀리겠지만 미리 정리를 해본다.

 

다음은 가장 일반적인 형태의 자신의 도메인 주소를 추가 하는 방법이다.

 

IDE를 가지고 개발하는 경우.. 개발자 PC 에서 웹서버가 자주 실행하고 테스트 해야 된다면 아래와 같이 localhost:* 을 추가 한다.

 

모든 곳에 허용(메일 삽입 이미지 등등) 하는 것은 Origin 설정을 * 으로 하면 된다 ‘ㅅ’a

 

AllowedMethods 는 GET, POST, HEAD, PUT, DELETE 를 지정 할수 있다.

 

PS. 터미널에서 curl 으로 CORS 검사는 아래와 같이 할 수 있다.

 

2.4Ghz 대역의 블루투스 및 wifi 와 USB3 간섭

USB 는 Universal Serial Bus 이고 일상적으로 쓰는 규격이다.

버전에 따라 최대 대역폭이 달라지는 것은 파동 간격을  줄여 같은 시간에 좀더 많은 데이터 전송을 가능하게 한다.

frequencies

위는 느린 USB 2.0 의 신호 형식(60MB/sec) 아래는 USB 3.0 의 신호 형식(625MB/sec)으로 이해 하면 되겠다.

모든 전자기기는 작동시 전자파를 발생시키는데 USB 3.0 에서 생성하는 전자파가 현재 주로 많이 쓰는

2.4Ghz (블루투스, WIFI) 에 간섭이 이루어 진다. 주로 신호 간섭 때문에 렉 혹은 튀는 증상이다.

 

실험 관련 문서: https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/usb3-frequency-interference-paper.html

 

문서 내용을 종합 하면

2020-10-20_164245

이 그림은 일반적인 사용 환경과 비슷하다. (CASE 1)

보통 usb 2 or 3 가 혼재 되어 있고 그림과 같이 쓰게 되는데

마우스가 2ft (약 70Cm) 이상 멀어지면 렉이 발생한다고 한다.

2020-10-20_164622

CASE 2 의 경우에는 usb 2.0 허브를 이용하여 USB3 포트에서 멀리 떨어트려 사용하는 것을 테스트 한

내용인듯 하여 2ft ~ 5ft (70Cm~180Cm) 까지 정상 사용이 가능했다고 한다 ‘ㅅ’a

 

CASE 3의 경우에는 usb 2 및 3 포트가 위아래로 바로 붙어 있는 형태

(가끔 메인보드에서 본적 있다.) 에서는 2ft ~ 5ft (70Cm~180Cm) 모두 사용 불가.

 

결론.

  1. wifi 및 블루투스 동글 등은 usb 2.0 허브를 이용해 usb3 에서 2ft 가까이 떨어트려서 사용한다.
  2. 인터넷 공유기에 포함된 USB 3.0 은 사용하지 말아야 한다.
  3. USB의 상위 버전은 하위 버전을 연결 할경우 하위 프리퀀시로도 동작이 가능하기 때문에 3.0 포트에 USB 2.0 장치 혹은 허브를 연결해도 된다.
  4. USB 3.0 과 USB 3.1 gen1 과 USB 3.2 gen1 은 단순 리브랜딩 이기 때문에 같은 문제가 있을것으로 판단 된다. (기술적으로 usb 2.0과 usb 3.x gen2 는 좋다 ‘ㅅ’a
  5. USB 3.0 허브를 사용하는 방법은 연결 부위 두곳 모두에서 발생하기 때문에 무선 충돌 해결에 1도 도움이 되지 않는다.
  6. 어쩔수 없는 경우에는 금속 쉴딩으로 어느정도는 해결이 가능하다. (물론 절연처리 된 금속 쉴딩)

 

PS. 쉴딩 처리 영역에 따른 전파 생성 그래프 ‘ㅅ’a (개인이 EMI 테이프 를 구하는것도 쉽지 않을듯.)

2020-10-20_170258

  1. 외장 하드 기판에 쉴딩
  2. USB 커넥터 부위에만 쉴딩
  3. USB 커넥터 및 커넥터 주위 기판까지 쉴딩
  4. 외장 하드 전체 쉴딩 (알루미늄 or 구리 EMI 필터)

 

CentOS 7 에서 systemd 의 쓸모 없는 로그를 필터링

시스템 로그 분석을 매주 진행하는데 systemd 에서 아래와 같은 메세지가 많이 표현됨.

 

로그 분석할때 쓸모가 없기 때문에 rsyslog 에서 예외 적용 한다.

 

출처 : https://access.redhat.com/solutions/1564823

AWS 상에서의 API Gateway – Lambda – python – pymysql – rds(mariadb) 구현

aws 에서는 API Gateway 를 제공 한다.

이는 serverless 기반의 API 생성 및 운영을 손쉽게 할 수 있는 서비스 이다. (근데 손쉽지 않더라..)

물론 굉장히 난해 하고 어렵지만 처음 한걸음은 항상 어려 웠다 ‘ㅅ’a (이 산을 넘으면 devops 가 되는 첫걸음이 된다.)

 

aws-api-lambda-python-rds

위 이미지 생성은 클라우드크래프트 (https://cloudcraft.co/) 에서 진행 하였다. (AWS 아키텍쳐를 짜는데 매우 유용함.)

 

즉 restful API 를 AWS 상에서 API gateway 와 Lambda 서비스를 이용하여 구축 하여 운영하는 것이다.

이미 이와 같은 많은 글을 참고 하였으나 대부분 아마존에서 제공 하는 nodojs 를 활용하는 방법만 존재 하더라…


1. Lambda 에서 함수를 생성 한다.

2020-08-07_154033


2. 함수가 생성 되면 기본 설정에서 함수의 제한 등을 확인할 수 있다.

핸들러의 의미는 함수가 실행되었을때 lambda_function.py 한의 def lambda_handler() 를 실행한다는 의미가 된다.

(물론 편집도 된다. DB 접근 시간이 있기 때문에 제한시간을 10~15초로 늘린다.)

2020-08-07_162631


3. 스크롤을 올려 보면 AWS Cloud 9 IDE 의 간소화 버전을 이용하여 수정을 할 수 있다.

2020-08-07_163001


4. Test 버튼을 눌러 테스트 셋을 생성 한다. (이미지는 없음)

테스트를 위한 좀더 많은 json 은 https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/sample-apps/nodejs-apig/event.json 에서 확인할 수 있다.

다시 TEST 버튼를 눌러보면 실행 API Gateway 에 연결 되었을때 실행 후 결과 값이 확인 된다.

2020-08-07_164220

함수 생성이 완료 되었지만 Hello World 를 보려고 이것을 하는게 아니기 때문에 API의 근본 목적인 데이터베이스 접속을 할 차례이다 ‘ㅅ’a


배포용 코드 작성은 AWS cloud 9 IDE 를 통해 작성을 할 예정이다. (일반적인 linux 나 windows 환경에서도 가능하다.)

물론 Cloud 9 을 통해 lambda 배포가 가능하지만 단순 소스 작성을 위해서만 이용할 예정 이다 ‘ㅅ’a  (이걸 하려면 또 Cloud Fomation 을 해야 하기 때문에…)

Lambda 에서는 일부 json, logging 등을 별다른 설정 없이 import 할 수 있지만 pymysql 과 같은 서버에 별도 설치가 필요한 부분은 같이 업로드가 되어야 한다.

때문에 아래와 같이 pymysql 설치를 한다.

db 정보를 저장할 dbinfo.py 파일과 AWS lambda 핸들러에서 지정된 lambda_function.py 파일을 같이 생성 한다.

위와 같이 작성을 하고 zip 파일로 압축을 한다.

압출한 파일을 AWS 웹콘솔 에서 업로드 한다.

2020-08-07_173321

zip 파일이 압축 해제가 되며 lambda001 아래에 파일 및 폴더가 위치 할 수 있는데 아래와 같이 드래그 앤 드롭으로 맞추어 준다.

아니면 기본설정-핸들러를 lambda_function.lambda001.lambda_handler 으로 바꾸어도 될꺼 같기도 하다 ‘ㅅ’a

2020-08-07_174505


데이터베이스의 경우 보안 때문에 IP를 막고 일부만 열어서 서비스 하는것이 일반적이기 때문에 실행하는 람다를 VPC 내에서 실행 되게 해야 한다.

그래서 생성한 lambda 함수가 자신의 VPC 에서 네트워크 인터페이스를 사용할 수 있는 권한을 주어야 한다.

2020-08-07_175052

화면 최상단의 권한 으로 이동하고 실행 역할(IAM role) 을 눌러 해당 정책에 정책 추가를 진행해야 한다.

아래의 권한으로 정책을 새롭게 생성해서 연결 해도 되고 인라인 정책 추가를 해도 된다.

추후 생성되는 Lambda 함수는 권한 부분에서 기존 역할로 이미 VPC 권한이 부여된 역할을 선택 해주면 좀더 편하게 사용할 수 있겠다.

2020-08-07_175631


lambda 실행될 VPC 에 대한 정보를 설정해 주어야 한다.

2020-08-07_180250

2020-08-07_180507

사용자 지정 VPC 지정과 VPC 지정 subnet 지정(2개 이상) 과 EC2보안그룹을 지정 하면 된다.


그리고 RDS 서버의 보안그룹에서 위에서 lambda 가 사용할 것으로 지정된 두개의 서브넷(172.31.0.0/20, 172.31.16.0/20)을 허용한다.

2020-08-10_113634


테스트를 달려 본다.

2020-08-07_181235

앗싸 가오리!


너무 길어져서 API 게이트웨이는 나중에 추가 할 예정이다 =_=a

팔로우 할때 주의 할점은 API 게이트 웨이의 리소스 > 메소드 에서 “통합 요청”의 유형이 LAMBDA 가 아닌 LAMBDA_PROXY 으로 해야 하는 python 코드 이다.

aws ubuntu 18.04 자동 업데이트 끄기

aws 에서 서버운영을 하는데

가장 작은 디스크 크기 8GB 으로 생성하고 1년정도 운영을 했을때 디스크가 초반에 4.XX GB만 사용이 되다가 점점 사용량이 증가 되었음 ‘ㅅ’a

 

ubuntu 의 경우 자동 업데이트로 꾸준히 커널을 업데이트 하기 때문에 발생하는 문제이고

특정한 서비스 포트만 열고 서비스 하는 서버이기 때문에 업데이트가 필요 없다고 판단되어 자동업데이트를 끄는 것으로…

 

이후 apt-get 을 이용하여 불필요한 패키지를 삭제한다 ‘ㅅ’a

 

linux-headers가 업데이트가 된 경우 재 부팅 이후에 autoremove를 해야할 수 있다.

혹은 너무 쌓여서 broken 이 된경우 /usr/src 에서  사용되고 있는 headers 를 제외하고 삭제를 해야 할 수 있겠다 ‘ㅅ’a