AWS 밖에 안써봐서 생소했지만, 서비스가 다 거기서 거기지 뭐....

프로젝트 구성을 위해, 간단하게 서버를 만들고, 해당 서버에 mysql, redis 를 연결해야했다.

db Connection Pool 구성

redis 구성

로컬에서 테스트할땐 HOST는 localhost, PORT는 각각 기본 포트인 3306, 6379로 사용했고, 연결 완료 후 테스트까지 잘 완료했다.

이후 배포환경에 azure mysql, redis에서 설정된 host와 port로 바꿔주고 실행을 시켰다

이런 에러가 발생했다.....

에러 발생지점도 나오지 않고 덜렁 저렇게 코드만...

구글링 결과 tcp 연결 에러로 나온다(타임 아웃과 유사한건가??)

예상 원인

1. mysql 연결 에러. 구글링 했을때 tcp 연결 실패 에러 케이스가 대부분 mysql이었다. 로컬 mysql workbench 에서 ssh연결로 연결했을 때 정상적으로 접속이 되었었고. vm 상에서 mysql -h blahblah -P 3306 -p로 연결했을 떄도 정상적으로 접속이 가능했다.

2. redis 연결 에러.(범인) ```redis-cli -h blahblah -p 6379`` 명령어로 로컬 환경에서도 연결이 안됐었고, vm에서도 연결이 안됐었다.

azure cache for redis 서비스에서 확인해보니

이런 옵션이.......켜져있었다.....

https://learn.microsoft.com/ko-kr/azure/azure-cache-for-redis/cache-nodejs-get-started

azure 공식 문서에서 알아보니 redis 접속 시, password 옵션으로 access_key가 필요하다는걸 알았다.

access_key를 REDIS_PASSWORD라는 환경 변수에 할당해주고 vm에서 실행을 시켰다!!

동작하지 않는다....... 30분 가량 삽질하다가.... azure 공식 문서에서 답을 찾았다

프로토콜이.... redis가 아닌.... rediss로 되어야했다......... s......

개발 환경에 맞춰 실행할 수 있도록 REDIS_PROTOCOL이라는 환경 변수를 만들어주었고 실행시켰더니.. 정상 작동 된다...

결론 : 공식 문서를 잘 읽자.

• AWS 리소스 아키텍처 다이어그램 수정
• AWS 리소스 아키텍처 다이어그램 피드백
• AWS 리소스 아키텍처 다이어그램 피드백 후 수정

- AWS 리소스 아키텍처 다이어그램 수정 & 피드백

기존 REST API는 SNS topic발행만 하게하고 Lambda에서 모든 기능이 실행된다고 생각하고 구상했었다....

Lambda와 rds가 통신하기도 하고, 다시 봐도 이해하기 힘든 로직이긴 하다. 너무 기능 분리에 몰두했다보다.

AWS 리소스 아키텍처 다이어그램 피드백 후 수정

피드백 후 분리된 도메인 내에서 처리가 가능한 기능들은 웹 서버에서 처리하고, 각 도메인 간에 상호 작용이 필요한 부분만 SNS -> SQS -> Lambda -> 웹 서버 구조로 처리하게 만들었다.

• AWS 리소스 아키텍처 다이어그램 작성

AWS 리소스 아키텍처 다이어그램

• 이벤트 스토밍 결과(DDD 구현) 피드백 받기
• 피드백 후 수정
• API 명세서 작성
• ERD 작성

이벤트 스토밍 결과 및 기능·인프라 요구사항 피드백

이전에 작성했었던 이벤트 스토밍 결과

피드백

1. 이벤트 스토밍

우리가 작성했던 것들은 DDD라 보기 힘들다. DDD는 조직구조를 반영한다. (ERD랑은 다릅니다)

• 애그리거트가 없다
• 조직단위 바운디드 컨텍스트가 아니다
  • 바운디드 컨텍스트라면 배송관리팀, 결제관리팀, 제품관리팀, 시스템관리팀 으로 나누어져있어야 하는 것

2. 기능·인프라 요구사항 피드백

기능·인프라 요구사항들이 너무 방대하다. 주어진 기안 내에 다 하지 못할 뿐더러, 현재 상황에선 손도 못댈 것들이 많다. (PG모듈 같은 것들...)

수정된 DDD

수정된 기능 요구사항

• 판매자가 크라우드펀딩 제품을 오픈하고 펀딩을 받는다
• 후원자가 프로젝트에 일정 금액을 펀딩한다
• 목표 금액이 달성되면, 해당 프로젝트는 성공으로 간주한다 (판매자가 제품을 만들고 배송하는 것은 부차적인 것)

수정된 인프라 요구사항

• 컨테이너 베이스 구현

• 데이터베이스를 쓰는데, 목적에 맞게 선정이 필요

  • 프로젝트 CRUD: 어떤 종류의 데이터베이스를 써도 상관이 없음
  • 결제 -> 결제 시도 및 결과와 관련한 이벤트 로그가 항상 있어야 한다. (후원자의 트랜잭션, 프로젝트에 쌓인 트랜잭션이 일치할 수 있도록, 최종적 일관성만 확보되면 됨)
    • mq가 로그 저장소의 역할도 하니까 고려해보시면 좋을 듯하다
    • 바로 결제시스템을 연결하기보다는 (강결합 x), 일종의 사이버머니(포인트)가 트랜잭션 상에서 왔다갔다 하는게 구현도 편하고, 테스트도 편하고, 컨셉 증명도 편하다. (확장성에도 좋음)

• 가용성

  • 가장 빈번한 트래픽 발생은 어디서 발생할까?: 상품 후원 -> 결제 쪽 데이터베이스에 가용성 확보 전략을 마련해야 할듯하다.
  • API Server도 이중화 시키고 로드밸런서는 붙여야할듯.

• 보안부분은 아키텍쳐 회의때 진행하기로함.

• 모니터링

  • 무엇을 모니터링할 것인가?
    • 프로젝트 별 후원 상태
    • 결제 시도 시 실패가 어디에서 발생하는지
    • 4xx 5xx 에러

그 외

• 결제는 필연적으로 외부 시스템과 연동이 되어야 하는 것
  • 트랜잭션 기록은 항상 실패에 대비해 구현해야 하고
  • 외부 시스템의 의존성 문제도 생각해야 한다.

기존에 생각하고 작성했던 부분들(DDD)에 대한 개념정리가 확실하지 않았었다. 사실 아직도 잘 모르겠다.

프로젝트 개요

Achievment Goals

• 실무와 가까운 클라우드 아키텍처를 구현할 수 있다(팀)
• 실무의 커뮤니케이션과 흡사하게 롤플레잉을 통해 의뢰인으로부터 자세한 요구사항을 이끌어낼 수 있다.(팀/개인)
• 낮선 기술스택과 요구사항에 대해서 스스로 학습하여 적용할 수 있다.(개인)
• 클라우드 아키텍처에 대한 그림을 그리고 설명할 수 있다. (팀)
• 구현의 디테일에 대한 질문을 받을 때 답변할 수 있다.(개인)

요구사항 구체화

우리 팀이 진행하는 시나리오는 자유주제 - 컨테이너 기반 시스템이었다. 간단한 3티어 혹은 2티어 아키텍처를 시스템이 컨테이너 환경에서 실행될 수 있게 하는 인프라를 구현해야한다.

기능 요구사항

• 최소 1개의 CRUD 기능을 가진 자유로운 시스템 구성
• 로직 티어와 데이터 티어는 구분되어야 한다.

인프라 요구사항

• 사용되는 애플리케이션들은 컨테이너로 구동되어야한다.
• 시스템 전반에 가용성, 내결함성, 확장성, 보안성이 고려된 서비스들이 포함되어야 한다.
• 하나 이상의 컴퓨팅 유닛에 대한 CI/CD 파이프라인이 구성되어야 한다.
• 시스템 메트릭 또는 저장된 데이터에 대한 하나 이상의 시각화된 모니터링 시스템이 구축되어야 한다.

오늘 진행한 것들

• 진행 시나리오 설정
• 팀 규칙 결정
• 프로젝트 유저 스토리 작성
• DDD 이벤트 스토밍(진행 중)

진행 시나리오 : 클라우드 펀딩 플랫폼

제품 아이디어 기획으로 크라우드 펀딩을 진행하는 예전의 와디즈와 유사하게 진행 중.

기능 요구사항

• 사용자 등록 및 프로필 관리: 사용자는 플랫폼에 가입하고 프로필을 설정할 수 있어야 합니다.
• 프로젝트 생성 및 관리: 사용자는 프로젝트를 생성하고 관리할 수 있어야 합니다. 프로젝트에는 제목, 설명, 목표 금액, 기간 등의 정보가 포함될 수 있어야 합니다.
• 펀딩 및 결제: 사용자는 프로젝트에 펀딩을 할 수 있어야 합니다. 결제는 안전한 방법으로 이루어져야 하며, 다양한 결제 수단을 지원해야 합니다.
• 프로젝트 업데이트: 프로젝트 창작자는 프로젝트 진행 상황을 업데이트하고 후원자에게 공유할 수 있어야 합니다.
• 리워드 관리: 프로젝트 창작자는 펀딩에 대한 보답으로 리워드를 제공할 수 있어야 합니다. 사용자는 리워드를 선택하고 받을 수 있어야 합니다.
• 커뮤니케이션 기능: 창작자와 후원자 사이의 소통을 위한 커뮤니케이션 기능이 필요합니다. 채팅, 댓글, 메시지 등의 기능을 포함할 수 있습니다.
• 검색 및 탐색 기능: 사용자는 다양한 프로젝트를 검색하고 탐색할 수 있어야 합니다. 카테고리, 인기 프로젝트, 추천 프로젝트 등의 기준으로 프로젝트를 필터링할 수 있어야 합니다.

인프라 요구사항

• 컨테이너 오케스트레이션 플랫폼: 컨테이너 기반 시스템을 구축하기 위해 Kubernetes, Docker Swarm 등의 컨테이너 오케스트레이션 플랫폼을 사용할 수 있습니다.
• 데이터베이스: 사용자 정보, 이벤트 정보, 주문 내역 등을 저장하기 위한 데이터베이스가 필요합니다. 관계형 데이터베이스(예: MySQL, PostgreSQL)나 NoSQL 데이터베이스(예: MongoDB, Cassandra)를 선택할 수 있습니다.
• 웹 서버: 사용자 인터페이스를 제공하기 위한 웹 서버가 필요합니다. Nginx, Apache 등의 웹 서버를 사용할 수 있습니다.
• 보안: 사용자 정보와 결제 정보를 보호하기 위해 SSL 인증서를 사용하는 HTTPS 통신과 데이터 암호화를 구현해야 합니다.
• 결제 게이트웨이: 다양한 결제 수단을 지원하기 위해 결제 게이트웨이(예: Stripe, PayPal)를 통합해야 합니다.(보류)
• 이메일 서비스: 티켓 구매 확인, 알림 등을 위해 이메일 서비스를 사용해야 합니다.
• 파일 저장소: 이벤트 사진, 티켓 디자인 등의 파일을 저장하고 관리하기 위한 파일 저장소가 필요합니다. AWS S3, Google Cloud Storage 등의 클라우드 기반 파일 저장소를 사용할 수 있습니다.
• 모니터링 및 로깅: 시스템의 상태를 모니터링하고 로그를 기록하기 위한 모니터링 및 로깅 시스템을 구축해야 합니다. Prometheus, ELK 스택(Elasticsearch, Logstash, Kibana) 등을 사용할 수 있습니다.

프로젝트 유저 스토리

유저

• 서비스 사용자가 서비스를 이용하기 위해 회원 가입버튼을 누다.
• 서비스 사용자가 서비스를 이용하기위해 로그인버튼을 누른다.
• 서비스 사용자가 비밀번호를 바꾸기위해 비밀번호 리셋버튼을 누다.
• 서비스 사용자가 아이디를 찾기위해 이메일을 검색한다(회원 가입시 이메일 작성)
• 서비스 사용자가 더이상 서비스를 사용하지않기위해 로그아웃버튼을 누른다.
• 서비스 사용자가 더이상 서비스를 사용하지않기위해 회원탈퇴버튼을 누른다.
• 서비스 사용자가 회원 정보 변경을 위해 회원정보수정 버튼을 누른다.(유저 페이지)

아이디어(상품)

• 서비스 사용자가 관심있는 아이디어상품을 기억하기위해 즐겨찾기 아이콘을 누른다.
• 서비스 사용자가 원하는 아이디어 상품을 찾기위해 원하는 아이디어 상품 카테고리/아이디어상품 이름 등을 검색한다. (-> 아이디어 이름, 제작상태랑 후원상태 포함)
• 서비스 사용자(판매자)가 아이디어 상품을 팔기 위한 후원 받기 위해 아이디어 상품을 생성버튼을 누른다.(등록을 할 때 기입, 카테고리로 나눈 걸 기입)
• 서비스 사용자가(판매자)가 아이디어 상품 수정을 하기위해 아이디어 상품수정버튼을 누른다
• 서비스 사용자가(판매자)가 아이디어 상품을 더이상 후원을받지 않기 위해 아이디어 상품삭제버튼을 누른다.
• 서비스 사용자가(구매자)가 원하는 아이디어상품의 판매자와 커뮤니케이션 하기위해 댓글을 입력한다.

후원

• 서비스 사용자가(구매자)가 원하는 상품을 사기위해 후원버튼을 누른다.
• 서비스 사용자가(구매자)가 상품을 더이상 사지 않기위해 후원취소버튼을 누른다.

결제

• 서비스 사용자(구매자)가 후원을 하기위해 결제방법을 선택한다. (결제방법 생각해보기)
• 서비스 사용자(구매자)가 카드결제하기위해 카드정보를 입력한다.
• 서비스 사용자(구매자)가 무통장입금을 하기위해 입금할 은행을 선택한다.
• 관리자가 구매자의 무통장 입금을 위해 은행정보를 화면에 보여준다..?

Notification

• 시스템 상에서 실패한 후원케이스를 구매자에게 알리기위해 후원실패 알림 보낸다.
• 시스템 상에서 후원한 상품 출고를 알려주기 위해 알림문자를 보낸다..?
• 시스템 상에서 결제완료확인을 위해 구매자에게 결제완료 이메일을 전송한다.
• 시스템상에서 결제 실패를 구매자에게 알리기 위해 결제실패 알림 이메일을 전송한다.
• 시스템상에서 구매자로부터 구매확정을 받기위해 구매확정 알림 이메일 전송한다.
• 판매자는 상품 출고를 배송업체에게 알리기위해 출고준비 버튼을 누른다.
• 시스템상에서 판매자가 아이디어를 수정할 시 아이디어상품 구매자에게 수정, 삭제되었다고 알림

이벤트 스토밍(진행 중)

terraform init

터미널에서 terraform init명령어를 실행한다.

명령어를 실행하면 .terraform이라는 폴더와 .terraform.lock.hcl이라는 파일이 생성된다.

.terraform폴더는 main.tf파일에 명시된 프로바이더나 모듈들의 데이터를 다운로드 받아 보관한다.

.terraform.lock.hcl파일은 팀에서 협업을 하거나 CI/CD 파이프라인을 구성할때 필요하다. 해당 워크스페이스에서 사용하는 프로바이더를 확인하고, 버전과 해시를 확인하여 다른 개발자들과 환경을 동일하게 유지하기 위해 사용한다.

로컬 프로바이더 생성

로컬 프로바이더는 주어진 컨텐츠로 로컬 환경에 파일을 생성한다.

main.tf파일을 생성 후 공식 문서 우측 상단에 USE PROVIDER를 클릭해 provider 블록을 복사해준다.

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "2.4.0"
    }
  }
}

provider "local" {
  # Configuration options
}

여기서 terraform block은 여러 provider를 사용하거나 특정 버전의 terraform을 요구하는 설정에서 유용하다.

terraform block으로 provider에 대한 정보를 지정하지 않으면 terraform은 기본적으로 최신 버전의 provider를 사용한다. 하지만 최신 버전의 provider는 항상 기존 terraform 코드와 호환되는 것은 아니다. provider의 새 버전에서는 종종 기능이 변경되거나 삭제되기도 하며, 이러한 경우 기존의 terraform 코드가 예상대로 작동하지 않을 수 있다.

그리고 terraform block에 require_providers 블록을 사용하면 terraform 코드의 이식성이 향상된다. 즉 다른 사람이나 다른 시스템에서 해당 코드를 실행할 때 동일한 provider 버전을 사용하도록 상제함으로써 일관성을 보장할 수 있다.

Resource

리소스는 프로바이더를 통해 관리할 수 있는 인프라 리소스이다. 데이터를 쓰는 용도로 사용된다.

1. 로컬 파일 리소스 생성

   resource "local_file" "foo" {
   filename = "${path.module}/foo.txt"
   content = "hello world!"
   }
   # 현재 폴더에 "hello world!"라는 내용을 가진 foo.txt파일을 생성하는 코드이다.

위 코드에서 사용된 ${}는 terrform에서 inter polation 이라는 문법이다. 문자열 내부에 hcl에서 제공하는 변수나 컨텍스트에 접근하여 값을 가져오기 위함이다.

path.module은 해당 파일이 위치한 디렉토리 경로이다.

2. 변경 사항 확인 terraform plan 명령어로 내가 작성한 tf파일이 어떤 변경사항을 불러 일으키는지 확인할 수 있다.

Plan: 1 to add, 0 to change, 0 to destroy.

마지막 출력문으로 어떤 리소스가 추가, 변경, 삭제되었는지 확인할 수 있다.

3. 변경 사항 적용 terraform apply 명령어로 변경사항을 적용시킬 수 있다.

명령어 실행 후 foo.txt파일과 terraform.tfstate파일이 생성되었다.

terraform.tfstate파일은 테라폼 상태 파일이라고 볼 수 있는데, 현재 리소스의 상태를 기록하고 있다. terraform.tfstate파일을 통해 main.tf를 수정하고 변경할 때 diff 결과를 명확하게 확인할 수 있다.

Data Source

데이터 소스 리소스를 관리할때 데이터를 참조해야할때 사용한다. 데이터를 읽는 용도로 사용된다.

데이터 소스는 리소스와 다르게 data라는 지시어로 사용된다.

data "local_file" "bar" {
  filename = "${path.module}/bar.txt"
}

위 코드를 작성 후 terraform plan명령어를 실행하면 bar.txt 파일이 없다는 에러가 출력된다. Data Source는 워크스페이스의 리소스를 사용하기 때문이다.

data "local_file" "foo_value" {
  filename = "${path.module}/foo.txt"
}

올바르게 코드를 작성하고 terraform plan -> terraform apply를 통해 변경사항을 적용시켜 준다. (diff가 없을 것이다) 읽어들인 Data Source는 output 이라는 지시어로 출력할 수 있다.

output "file_foo" {
  value = data.local_file.foo_value
}

tf apply를 해보면, 인프라 상에 변경사항은 없지만, 아래와 같이 Output 섹션에 결과값이 출력된 것을 볼 수 있다.

메트릭이란?

메트릭은 시간에 따라 측정한 결과값이다. 보다 넓은 의미로는 비즈니스 개념을 나타내는 수치 측정을 의미하기도 한다.
예를 들어, 시간당 CPU 사용률, 연간 순매출과 같이 시간이라는 차원이 함께 적용되어야 한다. 시간이 다른 차원을 기준으로 삼을 수도 있다.

모니터링의 목표

모니터링을 통해 얻는 것은 다음과 같다.

1. 시간을 기준으로 측정되는 주요 메트릭을 최소화하여 고가용성을 달성
2. 사용량을 추적하여, 배포에 앞서 세운 가설을 검증하고 개선

구글이 이야기 하는 모니터링의 목표

• 장기적인 트렌드 분석
  • DB가 얼마만큼의 용량을 차지하며, 얼마나 빨리 용량이 증가하는가?
  • DAU는 얼마나 빨리 증가하는가?
• 시간의 경과 및 실험 그룹 간의 비교
  • 어떤 DB를 썼을때 쿼리가 빠른가?
  • 캐시용 노드를 추가했을 때, 캐시 적중룔이 얼마나 향상되는가?
  • 지난주보다 사이트가 얼마나 느려졌는가?
• 경고
  • 인프라의 어떤 부분이 고장 났는가? 혹은 고장 날 수 있는가?

측정 메트릭

• 캐시 사용률
• CPU, Memory
• 인스턴스의 개수
• 연결 유지

주요 메트릭은 노드에 따라 다르게 측정할 수 있다.

• 단일 노드일 경우 리눅스를 통해 측정할 수 있다.
• 클러스터 형태일 경우 AWS, Azure, GCP의 콘솔을 통해 이미 제공되고 있는 경우가 많다.
  
  
  
  

  모니터링 구분

어떠한 서비스가 제대로 작동되는지 확인하려면, 서비스 또는 시스템과 관련한 모든 변수들을 모니터링해야 한다.

하지만 모든 메트릭을 실시간으로 보는 것은 불가능할뿐더러, 너무 많은 메트릭을 모니터링하다 보면, 정말 중요한 신호를 발견하기도 어렵다.

따라서 모니터링을 할 때에는 단계를 구분해서 계층적으로 할 필요가 있다.

블랙박스 모니터링과 화이트박스 모니터링

블랙박스와 화이트박스의 구분은 박스를 기준으로 관찰자가 밖에서 바라보느냐, 안에서 바라보느냐의 차이이다. 박스는 애플리케이션이 될 수도 있고, 쿠버네티스 시스템이 될 수도 있다.

블랙박스 모니터링은 CPU/메모리/스토리지 등 인프라 수준의 모니터링에 유용하다. 쿠버네티스 시스템의 경우, 클러스터 정상 작동여부 등 쿠버네티스 컴포넌트 그 자체를 모니터링하는 것도 블랙박스 모니터링에 해당한다. 그러나, 애플리케이션이 왜 오류를 내는지는 알 수 없다.

화이트박스 모니터링은 시스템 내부의 측정 기준에 따라 모니터링하는 것을 의미한다. 예를 들면, HTTP 요청, 500 에러의 발생 횟수, 레이턴시 등이 이에 해당한다. 단순히 현상만 바라보는 것이 아닌, 현상이 발생한 근거를 알 수 있는 모니터링 방식이다.

계층에 따른 모니터링 구분

논리적인 리소스의 집합이 하나의 상위 계층을 만든다. 오케스트레이션 툴이나, AWS의 서비스가 제공하는 계층을 이해하면, 어떤 것을 모니터링해야 하는지 보다 쉽게 파악이 가능하다.

• 쿠버네티스
  • 노드 > 클러스터 컴포넌트 > 파드
• ECS
  • 클러스터 > 서비스 > 태스크
• EC2: 인스턴스에 대한 메트릭만 볼 수 있다.
• Lambda: 함수에 대한 메트릭만 볼 수 있다.

Proxy 서버의 메트릭

애플리케이션 서버의 압단에 캐시 서버 혹은 인증서버, 로드 밸런서와 같은 Proxy 서버가 존재한다면, 이는 애플리케이션 서버와는 별도로 모니터링해야 한다. 애플리케이션 서버가 각 노드의 컴퓨팅 자원을 모니터링하는 데에 중점을 뒀다면, Proxy 서버, 그중에서도 HTTP 라우팅을 다루고 있는 서버는 요청 그 자체와 연관된 메트릭을 위주로 모니터링해야 gksek.

HTTP 요청/응답 관련 모니터링 대상은 쿠버네티스의 경우 인그레스, AWS 생태계에서는 ALB를 중점으로 보아야 한다.

• AWS 클라우드 환경을 기반으로 하는 느슨하게 연결된(loosely coupled) 애플리케이션 아키택처에 대한 이해
• SNS, SQS, DQL에 대한 이해
• Publisher-Subscriber 패턴과 Producer-Consumer 패턴에 대한 이해
• MSA에 대한 이해

Issues

1. Lambda 함수로 넘어오는 event객체 이해 부족

Event 객체에서, http 요청으로 받은 body에서 MessageAttributes를 가져오려는데 body에 MessageAttributes가 없다는 에러가 나왔다.

const consumer = async (event) => {

  console.log(event)
  const record = event.Records[0]
  console.log('body,',record.body)
  // point 1
  // 여기까진 나옴
  const {MessageAttributes} = record.body
  //에러 발생.
  console.log('body,',record.body)
  console.log('MessageAttributes,',MessageAttributes)
  const {MessageAttributeProductId} = MessageAttributes
  console.log('MessageAttributeProductId',MessageAttributeProductId)
  const sku = getValue(MessageAttributeProductId)    

};

point 부분에서 record.body의 객체에서 내가 필요로 하는 MessageAttributes가 있었지만, 계속 찾을 수 없다는 에러를 뱉어내고 있었다.

해결

record.body의 값

{
    "Type": "Notification",
    "MessageId": "xxxxx-xxxx-xxxx-xxxx-xxxxx",
    "TopicArn": "arn:aws:sns:ap-northeast-2:BlahBlah:BlahBlahBlahBlah",
    "Subject": "도너츠 재고 부족",
    "Message": "도너츠 재고가 없습니다. 제품을 생산해주세요! \n메시지 작성 시각: Thu May 25 2023 06:26:57 GMT+0000 (Coordinated Universal Time)",
    "Timestamp": "2023-05-25T06:26:57.595Z",
    "SignatureVersion": "1",
    "Signature": "BlahBlahBlahBlahBlahBlahBlahBlahBlahBlahBlahBlahBlahBlahBlahBlahBlahBlah",
    "SigningCertURL": "https://sns.ap-northeast-2.amazonaws.com/SimpleNotificationService-BlahBlahBlahBlahBlahBlahBlahBlahBlahBlah.pem",
    "UnsubscribeURL": "https://sns.ap-northeast-2.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=aBlahBlahBlahBlahBlahBlahBlahBlah",
    "MessageAttributes": {
        "MessageAttributeProductId": {
            "Type": "String",
            "Value": "CP-502101"
        },
        "MessageAttributeFactoryId": {
            "Type": "String",
            "Value": "xxxxx-xxxx-xxxx-xxxx-xxxxxxxx"
        }
    }
}

위 값처럼 JSON 객체가 직렬화 되어있었다.

  const record = event.Records[0]
  const {MessageAttributes} = JSON.parse(record.body)
  const {MessageAttributeProductId} = MessageAttributes
  const sku = getValue(MessageAttributeProductId)    

JSON.parse(record.body) 를 사용하여 해결하였다.

2. Lambda 권한 문제

serverless.yml 작성 후 serverless deploy로 배포 시도 중 lambda에서

• SQS ReceiveMessage
• SQS DeleteMessage
• SQS GetQueueAttributes

관련 권한이 없어 생성하지 못하는 에러가 발생.

해결

IAM -> 역할 -> 생성하려는 LambdaRole -> 권한 추가

 "sqs:ReceiveMessage",
 "sqs:DeleteMessage",
 "sqs:GetQueueAttributes"

위 권한 추가 후 정상실행.

배운 점

에러 핸들링으로 배운 점은 아니지만

• MSA로 아키텍쳐 구성할때 도메인은 SQS를 기준으로 나눈다.
• SQS를 써야하는 이유는 영속성 즉, 느슨한 연결을 위한 연결다리의 역할과 메시지가 전달되는 다음 리소스에 에러가 발생해도 이전 리소스에서 전달받은 메시지를 SQS가 가지고 있어 내구성 있는 서비스를 구성할 수 있다.
• Publisher-Subscriber 패턴과 Producer-Consumer 패턴에 대한 이해
  • (API-Gateway -> SNS(Publisher))(Producer) -> SQS(Subscriber) -> Lambda(Consumer)

쿠버네티스의 영역은 크게 노드를 하나로 묶는 클러스터를 관리하는 Control Plane 영역과 흩어져 있는 각 노드를 관리하는 노드 영역으로 나눌 수 있다.

K8s라고도 한다.

K8s 클러스터 설계 원칙

K8s 클러스터가 갖춰야 할 특성은 다음과 같다.

• 보안성: 최신 보안 모범 사례를 따라야 한다.
• 사용 편이성: 몇 가지 간단한 며 ㅇ령으로 작동할 수 있어야 한다.
• 확장 가능성: 하나의 제공업체만을 선호해서는 안 되고 구성 파일을 통해 사용자 정의를 할 수 있어야 한다.

K8s 구성 요소

작동 중인 K8s 배포를 클러스터라고 한다. K8s 클러스터는 Control Plane과 Node 2개 부분으로 시각화할 수 있다. 각 노드 자체는 Linux환경이며 물리 또는 가상 머신일 수 있다.

Control Plane

Control Plane는 클러스터에 관한 결정을 내리고 클러스터 이벤트를 감지하며 반응한다. Control Plane은 클러스터 내 어떠한 머신에서라도 동작할 수 있다.

Component

• kube-apiserver: K8s의 모든 컴포넌트의 통신을 담당한다.

• etcd: 모든 클러스터 데이터를 담는 K8s 뒷단의 저장소로 사용되는 키-밸류 저장소이다.

• kube-scheduler: 노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 컴포넌트이다.

• kube-controller-manager: 컨트롤러를 구동하는 컴포넌트이다. 종류로는 노드 컨트롤러, 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 서비드 어카운트, 토큰 컨트롤러 등이 있다.

Node

K8s클러스터는 컨테이너화된 애플리케이션을 실행하는 Node라는 워커 머신의 집합이다.

워커 노드는 애플리케이션의 구성요소인 Pod를 호스트한다.

minikube start --nodes=3

위 명령어를 통해 여러개의 노드를 구성할 수 있다.

여러 개의 노드를 만들면, 첫 번째는 master, 나머지 두 개의 노드는 worker 노드로 구성된다. 여러 개의 노드를 구성할 경우, 워커 노드에는 실제로 실행되는 애플리케이션을 배치하며, 마스터 노드는 클러스터 관리 그 자체에 집중하게 한다.

Component

• kubelet: 클러스터의 각 노드에서 실행되는 에이전트이다. kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다.

• kube-proxy: 클러스터의 각 노드에서 실행되는 네트워크 프록시로, K8s 서비스 개념의 구현부이다. 또한 노드의 네트워크 규칙을 유지, 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 Pod로 네트워크 통신을 할 수 있도록 해준다.

Terraform은 IaC 도구이며, 이 도구를 사용하면 사람이 읽기 쉬운 선언적 구성 파일에서 리소스와 인프라를 정의할 수 있으며 인프라의 라이프사이클을 관리할 수 있다.

Terraform의 장점

• 여러 클라우드 플랫폼에서 인프라를 관리할 수 있다.
• 사람이 읽기 쉬운 구성 언어를 사용하면 인프라 코드를 빠르게 작성할 수 있다.
• Terraform의 state를 사용하여 배포 상태에서 리소스 변경 내용을 추적할 수 있습니다
• configuration을 버전 관리 시스템에 커밋하여 인프라에 대한 협업을 안전하게 진행할 수 있습니다

Terraform의 특징

모든 인프라 관리

Terraform의 프로바이더는 Terraform이 API를 통해 클라우드 플래솦ㅁ이나 다른 서비스와 상호 작용할 수 있게 해준다. 이미 사용 중인 플랫폼이나 서비스에 대한 프로바이더는 Terraform레지스트리에서 찾아볼 수 있다(AWS, Azure, GCP...).

배포 워크플로우 표준화

프로바이더는 인프라 개별 단위를 정의한다(EC2, VPC...). 서로 다른 프로바이더의 리소스를 모듈이라고 불리는 재사용 가능한 Terraform구성으로 조합할 수 있고, 일관된 언어와 워크플로우를 관리할 수 있다.

Terraform의 구성 언어는 선언적으로, 인프라의 원하는 최종 state를 설명해주고, 절차적 프로그래밍 언어와 다르게 단계별 지시사항을 요구하지 않는다.

Terraform 프로바이더는 리소스 간 의존성을 자동으로 계산해서 올바른 순서로 생성하거나 제거할 수 있게 해준다.

테라폼의 배포 워크 플로우

• scope - 프로젝트에 필요한 인프라 파악.
• author - 인프라 구송 작성.
• initialize - 인프라 관리를 위해 Terraform 플러그인(프로바이더)을 설치.
• plan - Terraform이 변경될 내용을 미리 살펴본다.
  

인프라 추적

• Terraform은 state 파일에서 실제 인프라를 추적한다.
• Terraform은 state 파일을 사용하여 구성에 맞게 인프라에 적용할 변경 사항을 결정한다.
  

• 사용된 단어를 담는 배열(usedWords)과, 직전 단어를 (beforeWord)담을 변수를 선언

• 문자를 담은 배열을 순회하며 이전에 사용된 단어들과 직전 단어를 비교.

  1. 첫 번째 단어일 경우 usedWords에 단어를 추가하고, beforeWord에 단어를 할당한다.
     2. 현재 단어가 usedWords에 있고, 현재 단어의 첫 번째 알파벳과 직전 단어의 마지막 알파벳이 일치하지 않을 경우(끝말잇기 실패), [실패한 사람의 번호, 차례]를 담는 배열을 반환한다.
  • 실행 횟수 % n -> 실패한 사람의 번호, 0일시 n
    • math.ceil(실행 횟수/n) -> 차례
  3. 현재 단어가 usedWords에 없고 현재 단어의 첫 번째 알파벳과 직전 단어의 마지막 알파벳이 일치할 경우(끝말잇기 성공), usedWords에 현재 단어를 추가하고, beforeWord에 현재를 할당한다.

2. 코드

import math
def solution(n, words):
    usedWords = []
    beforeWord =""
    index = 0

    while 1:        
        if index==0:
            usedWords.append(words[index])
            beforeWord =words[index]  
            index = index+1
            continue
        elif len(words) == index:
            return [0,0]


        curWord = words[index]   
        if usedWords.count(curWord)!=0 or beforeWord[-1] !=curWord[0]:       
            cnt = index+1
            num = n if cnt%n ==0 else cnt%n
            turn = math.ceil(cnt/n)            
            return [num,turn]
        else:
            usedWords.append(curWord)
            beforeWord =curWord
            index = index+1


    return                          

3. 후기

처음 python으로 풀어본 알고리즘이라 전체적으로 미숙했던 부분이 많았던 것 같다.

익숙해지는 과정이 필요하다.

YAML은 최근 들어 많이 활용되고 있는 데이터 형식이며, 사람이 읽고 이해하기 쉬운 형태를 가지고 있다.

확장자는 .yml 또는 .yaml을 사용한다.

YAML 문법

데이터 정의

YAML은 기본적으로 데이터를 정의할 때, key:value형태로 데이터를 정의한다.

이때 : 뒤에는 키와 값을 구분하기 위해 반드시 공백문자가 있어야 한다.

데이터 타입으로는 Number, String, Boolean이 있으며, 문자열에 \n, @ 등의 특수 문자가 포함된 경우에만 " "를 사용하여 작성한다.

#주석
Name: DongWook
Age: 

Array/Lists

배열이나 리스트의 구조를 표현할땐 -를 사용한다. -는 배열의 한 요소를 가리킨다.

Fruits:
    - Orange
    - Apple
    - Banana
Vegetables:
    - Carrot
    - Lettuce

{
    Fruits : ["Orange","Apple","Banana"],
    Vegetables:["Carrot","Lettuce"]
}

Dictionary/ Map

계층 구조를 표현하고 싶은 경우, 기본적으로 2칸 혹은 4칸의 들여 쓰기를 사용한다. 들여 쓰기를 사용할 때, 각 아이템에 대해서 꼭 같은 수의 공백문자를 사용하여 들여 쓰기를 해야 한다.

Fruits:
    Name: Pear
    Quantitiy: 5
    Origin: Naju
Vegetables:
    Name: Garic
    Quantitiy: 3
    Origin: Uiseong

Multi-lines

값으로 여러 행의 문장을 작성할 때 \n,>,|을 사용한다.

     example: "this is multiline string \n and this is nextline \n and nextline \n"

> 문자는 한 줄을 모두 비웠을 때만 줄 바꿈으로 인식을 하고, 그냥 줄 바꿈을 할 때에는 공백문자로 인식한다.

example: >
    this is multiline string
    and this is nextline
    and next

example2: >
  this is multiline string 

  and this is nextline 

  and nextline

| 문자는 모든 줄 바꿈을 인식하며, 마지막 문장의 끝도 마찬가지로 줄 바꿈으로 인식한다.

example1: |
  this is multiline string 
  and this is nextline 
  and nextline

네트워크, 로드밸런서, 저장소, 서버 등의 인프라 자원을 수동 술정이 아닌 코드를 이용하여 프로비저닝하고 관리하는 것

대표적인 IaC 도구로 Terraform, CloudFormation, Pulumi, Azure Arm Template 등이 있다.

형상 관리(Configuration Management)

서버 운영체제 상에 필요한 소프트웨어를 설치하고 원하는 설정으로 관리하는 것, CaC(Configuration as Code)라고도 불림

이미지 빌드(Image Build)

AWS EC2, VMware, VirtualBox, Docker 등 여러 플랫폼에서 재사용 가능한 머신 이미지를 빌드하는 것 대표적인 이미지 빌더로 패커(Packer), AWS EC2 Image Builder 등이 있음.

코드로 관리한다는 것(... as Code)

• 사람이 수동으로 처리하는 것을 코드로 작성하여 관리

  • 휴먼 에러 방지
  • 재사용성
  • 일관성

• 소프트웨어 개발처럼 Git과 같은 버전 관리 시스템(VCS) 활용 가능

  • 코드 리뷰 가능
  • 변경내용 추적 가능
  • 버전 관리
  • 협업

코드가 어떻게 관리되느냐에 따라 선언형 설정(Declartive Configuration)과 절차형 설정(Imperative Configuration)으로 분류할 수 있다.

선언형 설정

선언형 설정에서는, 우리가 워나는 시스템의 최종 상태에 대해 '선언'한다. 이를 통해, 시스템은 최종 상태를 달성하는 데 필요한 단계를 자체적으로 결정하고 수행할 수 있다.

선언형 설정은 코드의 명확성과 유지 관리 용이성을 높이며, 사이드 이펙트를 최소화하는 데 효과적이다.

Terraform, Kubernetes, Ansible이 이에 해당한다.

절차형 설정

시스템에게 상태를 변경하는 방법에 대한 명령을 '지시'한다. 이 경우, 명확한 단계와 절차를 제공해야하며, "어떻게"이러한 상태를 달성할 것인지를 지시한다. 절차형 설정은 세부적인 제어와 특정 동작에 대한 완전한 통제를 가능하게 한다.

Shell scripts, Python, JavaScript 등의 일반적인 프로그래밍 언어들, Chef와 Puppet과 같은 관리 도구들이 이에 해당한다.

컨텐츠를 좀더 빠르고 효율적으로 제공하기 위해 등장한 서비스

CDN의 특징

• 원복을 복사하여 저장할 여러개의 캐시 서버로 구성
• 컨텐츠를 요청받은 경우 데이터를 전달하기 가장 유리한 캐시 서버에서 관련 콘텐츠를 제공한다.
  • 제공할 컨텐츠를 가지고 있으며 위치상으로 가장 가까운 캐시 서버가 우선순위를 가짐.

컨텐츠 종류

정적 컨텐츠

내용이 거의 변하지 않는 컨텐츠

1. HTML 파일, 동영상과 같은 컨텐츠.
2. 변화가 없는 컨텐츠.
3. 개인화되지 않은 대중적인 컨텐츠.

위와 같은 컨텐츠들은 CDN의 캐시 서버에 저장하기 적합하다.

동적 컨텐츠

접속할때 마다 내용이 바뀌거나 사용자 마다 다른 내용을 보여주는 컨텐츠.

1. 위치, IP주소, 사용시간 관련 컨텐츠.
2. 사용자가 접근할때 마다 내용이 달라지는 컨텐츠.
3. 카드 번호, 전화번호등 개인화된 정보 관련 컨텐츠.

컨텐츠가 바뀔때 마다 캐시 서버에 바뀐 컨텐츠가 전파되어야 함

CDN의 이점

1.DDoS공격에 대해 어느정도 대응이 가능
    - 지리적으로 가까운 다른 서버에서 컨텐츠 제공

2.로딩속도 감소로 인한 사용자 경험 향상 3.트래픽 분산으로 인한 트래픽 관련 비용 절감.     - 서버 분산으로 지역에 맞게 서버의 성능과 인터넷의 성능을 낮춘다 해도 무리 없이 서비스 제공 가능.     - 외국에 있는 사용자들의 로딩 시간을 단축가능.

네트워크 구성 방법

Scattered방식

1. 세계 곳곳에 최대한 많은 캐시 서버를 제공.
2. 낮은 수용량의 데이터 센터 및 캐시 서버.
3. 매우 높은 관리비용 및 사용자 요금.
4. 연결 수요가 적은 지역 대상으로 적절한 방식.

Consolidated방식

1. 다수의 고성능 서버로 통합하여 운용하는 방식
2. 응답시간 증가. 하지만 관리 및 유지 비용이 낮아짐.
3. 연결 수요가 많은 지역 대상으로 적절한 방식.

NoSQL 은 매우 넓은 범위에서 사용하는 용어로, 관계형 테이블의 방법을 사용하지 않는 데이터 저장소를 뜻한다.

NoSQL 데이터를 행과 열이 아닌, 체계적인 방식으로 저장한다.

엇떨때 사용?

1. 비구조적인 대용량의 데이터를 저장하는 경우

• NoSQL 데이터베이스는 관계에 중점을 둔 SQL 데이터베이스보다 자유로운 형태로 데이터를 저장할 수 있으므로 필요에 따라 새로운 데이터 유형을 추가할 수 있다.
• SW 개발에 정형화되지 않은 많은 양의 데이터가 필요할 경우, NoSQL이 효율적일 수 있다. (비정형 데이터 저장에 효율적)

2. 클라우드 컴퓨팅 및 저장공간을 최대한 활용하는 경우 NoSQL 데이터베이스는 데이터베이스를 클라우드 기반으로 쉽게 분리 할 수 있도록 지원하며, 저장공간을 효율적으로 사용한다. 시스템이 커지면서 DB를 증설해야 하는 시점이 오면, SQL 데이터베이스에서는 수직적 확장의 형태로 DB를 증설한다. 수직적으로 확장된 DB는 관리가 어려워질 수 있는데에 반해, NoSQL은 수평적 확장의 형태로 증설하므로, 이론상 무한대로 서버를 계속 분산시켜 DB를 증설할 수 있다.

3. 빠르게 서비스를 구축하고 데이터 구조를 자주 업데이트 하는 경우 NoSQL 데이터베이스의 경우 스키마를 미리 준비할 필요가 없어서, 개발을 빠르게 해야하는 경우에 매우 적합하다.

ACID 를 지켜야 할땐 RDB 아니면 NoSQL을 쓰자

렉시컬 스코프는 JS의 특별한 개념이 아니라 스코프를 결정하는 방법론? 중 하나이다.

1. 식별자를 어디서 호출하였는지에 따라 상위 스코프를 결정하는 방법.
2. 식별자를 어디서 선언하였는지에 따라 상위 스코프를 결정하는 방법.

첫 번째 방식을 동적 스코프(Dynamic scope)라 하고, 두 번째 방식을 렉시컬 스코프(Lexical scope) 또는 정적 스코프(Static scope)라 한다.

JS를 비롯한 대부분의 프로그래밍 언어는 두 번째 방식을 따른다고 한다.

JS는 렉시컬 스코프를 따르므로 함수를 선언한 시점에 상위 스코프가 결정된다. 함수를 어디에서 호출하였는지는 스코프 결정에 아무런 의미를 주지 않는다.

let name = '이동욱';

function a() {
  let name = '이동훅'
  bar();
}

function b() {
  console.log(x);
}

a(); // ?
b(); // ?

위 예제 코드의 실행 결과는 어떻게 될까?

a() // 이동욱
b() // 이동욱

둘 다 같은 이동욱 즉, 전역 스코프의 name 변수를 참조하여 출력한다.

클로저

클로저 역시 JS 고유의 개념이 아니라 함수를 일급 객체로 취급하는 함수형 프로그래밍 언어에서 사용되는 중요한 특성이다.

MDN 은 클로저에대해 아래와 같이 정의한다.

클로저는 함수와 함수가 선언된 어휘적 환경(Lexical environment)의 조합이다. 클로저를 이해하려면 자바스크립트가 어떻게 변수의 유효범위를 지정하는지(Lexical scoping)를 먼저 이해해야 한다.

머선 말인지 모르겠다.. 예제로 한번 살펴보자.

let name= '이동욱'

const outer=()=>{
    let name ='이동훅'
    const inner=()=>{console.log(name)}
    return inner
}

let inner = outer() 
inner()// '이동욱'

위 에제에서 outer는 내부함수 inner를 반환하고 생을 마감했다. 즉, 함수 outer는 실행된 이후 콜스택에서 제거되었으므로 함수 outer의 name 또한 더이상 유효하지 않게 되어 변수 name에 접근할 수 있는 방법은 없을듯하다

하지만 위 코드의 실행 결과는 변수 name값인 '이동욱' 이다.

이처럼 자신을 포함하고 있는 외부함수보다 내부함수가 더 오래 유지되는 경우, 외부 함수 밖에서 내부함수가 호출되더라도 외부함수의 지역변수에 접근할 수 있는 함수를 클로저라고 부른다.

다시 MDN 정의를 살펴보자.

클로저는 함수와 함수가 선언된 어휘적 환경(Lexical environment)의 조합이다.

위 정의에서 "함수"A 는 반환된 내부함수를 의미하고, "함수가 선언된 어휘적 환경"B는 내부 함수가 선언됐을 때의 스코프를 의미한다. 즉, 클로저는 반환된 내부함수가 자신이 선언됐을 떄의 환경(Lexical environment)인 스코프를 기억하여 자신이 선언됐을 때의 스코프 밖에서 호출되어도 그 스코프에 접근할 수 있는 함수를 말한다.

조금 더 간단히 하면 클로저는 자신이 생성될 때의 스코프를 기억하는 함수 라고 할 수 있다

*스코프는 참조 대상 식별자(identifier, 변수, 함수의 이름과 같이 어떠한 대상을 다른 대상과 구분하여 식별할 수 있는 유일한 이름)를 찾아내기 위한 규칙이다. *

 let name = '이동욱'

const a=()=>{
  let name= '이동훅'
  console.log(name)
  {
      let name ='이동훅훅'
    console.log(name)
  }
}

a() 
//이동훅훅
//이동훅
console.log(name) //이동욱

이름이 같은 변수 name이 중복 선언되었다. 전역에서 변수 name을 참조할 때, 그리고 함수 foo내부에서 변수 name을 참조할 때 이름이 중복된 2개의 변수를 JS는 엇덕혜 식별하는 것일까?

프로그래밍은 변수를 선언하고 값을 할당하며 변수를 참조하는 기본적인 기능을 제공하며 이것으로 프로그램의 상태를 관리할 수 있다. 변수는 전역, 함수 내부, 코드 블록에 선언하며 코드 블록이나 함수는 중첩될 수 있다. 식별자는 자신이 어디에 선언됐는지에 의해 자신이 유효한 범위를 갖는다.

위 코드에서 전역에 선언된 변수 name은 어디에든 참조할 수 있다. 하지만 함수 a내에서 선언된 변수 name는 함수 a내부에서만 참조할 수 있고 함수 외부에서는 참조할 수 없다. 이러한 규칙을 스코프라고 한다.

스코프의 구분

JS의 스코프에대해서 알아보자

전역 스코프(Global Scope)

전역에 변수를 선언하면 이 변수는 어디서든지 참조할 수 있는 전역 스코프를 갖는 전역 변수가 된다. var로 선언한 전역변수는 Browser-side 에서 window 객체의 프로퍼티 , Server-side 에서는 global 객체의 프로퍼티가 된다. (let, const는 아님)

지역 스코프(Local Scope)

JS는 함수 레벨 스코프를 사용했지만 ES6로 넘어오면서 변수 선언시 let과 const를 권장하면서 사용하면서 블록 레벨 스코프가 되었다 해도 무방하다.(사견임)

함수 내에 존재하는 함수인 내부 함수의 경우를 살펴보자

let name = '이동욱'

const outer =()=> {
  let name = '이동훅'
  console.log(name);

  const inner=() =>{  // 내부함수
    console.log(name); // ?
  }

  inner();
}
outer();
console.log(name); // ?

내부함수는 자신을 포함하고 있는 외부함수의 변수에 접근할 수 있다.

함수 inner에서 참조하는 변수 name은 outer에서 선언된 지역변수이다. 이는 실행 컨텍스트의 스코프 체인에 의해 참조 순위에서 전역변수 name이 뒤로 밀렸기 때문

소수 테스트

숫자가 소수인지 알아보는 방법은 숫자 n을 2부터 n-1까지의 수로 나눠 나머지가 0인지 확인하면 된다.

const isPrime=(n)=>{
    if(n<=1){
        return false
    }

    // 2부터 n-1까지의 수로 나눈다.
    for(let i =2 ; i<n;i++){
        if(n%i===0){
            return false
        }
    }

    return true
}

위의 코드의 시간 복잡도는 O(n)이다. 0부터 n까지의 모든 수를 확인하기 때문이다.

위의 알고리즘 수행 방식에서 패턴을 찾아 알고리즘을 더 빠르게 만들 수 있을까?

우선 2의 배수는 무시해도 된다. 하지만 이뿐만 아니라 최적화 가능한 부분이 더 있다.

우선 소수를 나열해보면

2,3,5,7,11,13,17,19,23,29 ...

알아차리기 힘들 수도 있지만 2와 3을 제외하고는 모든 소수는 6k +- 1의 형태를 지닌다. 여기서 k는 정수다.

5 =(6-1), 7 = (6+1) , 11 = (2*6 -1) ...

또한 n이 소수인지 알아보기 위해 반복문을 n의 제곱근까지만 확인해보면 된다. n의 제곱근이 소수가 아니면 n은 수학 정의에 의해 소수가 아니기 때문이다.

const isPrime = (n)=>{
    if(n <= 1 ) return false
    if(n <=3 ) return true

    //입력된 수가 2 또는 3인 경우 아래 반복문에서 
    //다섯 개의 숫자를 건너뛸 수 있다.

    if(n%2 ===0 || n%3===0) return false

    for(let i =5;i*i<=n; i +=6){ 
        //i*i <=n 인 이유는 제곱근이기 때문
        if(n%i===0 || n%(i+2)===0){
            return false
        }

    }

    return true;
}

위의 개선된 알고리즘의 시간복잡도는 O(sqrt(n)) 이다. 시간을 상당히 줄인다.

소인수분해

또 다른 유용하 알고리즘으로 어떤 숫자의 소인수분해를 구하는 것이 있다. 소수는 암호화와 해싱의 기반이 되고 소인수분해는 주어진 숫자를 만들기 위해 어떤 소수들이 곱해져야 하는지 구하는 과정이다.

const primeFactors=(n)=>{
    // n이 2로 나눠진다면 나눠질 수 있는 수만큼 2가 출력된다.
    while(n%2 ==0){
        console.log(2)
        n /= 2
    }

    //이 지점에서 부터 n은 홀수이다.
    //따라서 수를 두 개씩 증가시킬 수 있다.
    //3부터 n의 제곱근까지 반복한다.
    for(let i =3; i*i <=n ; i = i+2){
        while(n%i ==0){
            console.log(i)
            n /=i
        }
    }

    //n이 2보다 큰 소수인 경우를 처리하기 위한 조건문이다.
    if(n>2){
        console.log(n)
    }
}

primeFactors(10) -> '2'와 '5'를 출력한다.

무작위 수 생성기

무작위 수 생성은 어떤 조건이 어떤 식으로 동작하는지 확인하는 데 있어 중요하다. JS에는 수자를 생성하기 위한 내장 함수인 Math.random()이 있다.

Math.random()은 0과 1 사이의 부동소수점을 반환한다.

무작위 정수나 1보다 큰 무작위 수를 얻는 방법은 Math.random()에 범위를 곱하면 된다.

Math.random()*100  // 0부터 100까지의 부동소수점
Math.random()* 25+5 // 5부터 30까지의 부동소수점
Math.random()*10-100 // -100부터 -90까지의 부동소수점

무작위 정수를 얻기 위해서는 Math.floor(), Math.round(),Math.ceil()을 사용해 부동소수점을 정수로 만들면 된다.

Math.floor(Math.random()*100)  // 0부터 99까지의 정수
Math.round(Math.random()* 25+5) // 5부터 30까지의 정수
Math.ceil(Math.random()*10-100) // -100부터 -90까지의 정수

• + : 덧셈
• - : 뺄셈
• / : 나눗셈
• * : 곱셈
• % : 나머지 연산

위의 연산자들은 다른 프로그래밍 언어에서도 일반적으로 사용되며 JS에 한정된 것은 아니다.

JS는 숫자에 대해 부호 (1비트), 지수(11비트), 소수(52비트) 총 64비트로 이루어진 부동소수점 표현을 사용한다. (JS가 모든 숫자를 나타낼 때 부동소수점을 사용한다... 정로도만 이해하자)

JS 숫자 객체

JS가 모든 숫자를 나타낼 때 부동소수점을 사용하기 떄문에 정수 나눗셈은 소용이 없다.

JAVA와 같은 프로그래밍 언어에서 정수 나눗셈의 결과는 해당 나누기의 몫이다.

    JAVA : 5/4 === 1
    JS   : 5/4 ===1.25

자바에서는 명시적으로 데이터 형식을 선언해야 하기 때문이다. ex) int , float ...

따라서 결과는 부동 소수점이 될 수 없다.

정수 내림, 반올림, 올림

JS에서 정수 나눗셈을 하길 원한다면 다음 중 하나를 사용해야 한다.

Math.floor - 가장 가까운 정수로 내림한다.
Math.round - 가장 가까운 정수로 반올림한다.
Math.ceil  - 가장 가까운 정수로 올림한다.

Number.EPSILON

Number.EPSILON은 두 개의 표현 가능한 숫자 사이의 가장 작은 간격을 반환한다. 이는 부동소수점 근사치를 활용해 분수가 제대로 표현되지 않는 문제를 해결하는 데 유용하다.

function numberEquals(x,y){
    return Math.abs(x-y) < Number.EPSILON
 }

 numberEquals(0.1 + 0.2 ,0.3); true

 // JS에서는 십진분수로 인해 소수점 연산을 정확하게 표현할 수 없다.
 ex) 0.1+0.2 === 0.3 //false
     0.1+0.11 ===0.12 //false

최대치

Number.MAX_SAFE_INTEGER

Number.MAX_SAFE_INTEGER는 가장 큰 정수를 반환한다.

Number.MAX_SAFE_INTEGER+1 ===Number.MAX_SAFE_INTEGER + 2 //true

위의 코드에서 두 수는 더 이상 커질 수 없기 때문에 true를 반환한다. 하지만 위의 코드를 부동소수점과 같이 사ㅇㅇ하면 제대로 동작하지 않으면 결과는 false이다.

Number.MAX_SAFE_INTEGER +1.111 ===Number.MAX_SAFE_INTEGER +2.022 //false

Number.MAX_VALUE

Number.MAX_VALUE는 가능한 가장 큰 부동 소수점을 반환한다.

Number.MAX_VALUE는 1.7976931348623157e +308 라고한다 (뭔지는 모르겠다)

Number.MAX_VALUE +1 === Number.MAX_VALUE +2       //true
Number.MAX_VALUE +1.111 ===Number.MAX_VALUE+2.022 //true

Number.MAX_SAFE_INTEGER 와는 다르게 부동소수점에 대해서도 잘 동작한다.

최소치

Number.MIN_SAFE_INTEGER

Number.MIN_SAFE_INTEGER는 가장 작은 정수를 반환한다.

Number.MIN_SAFE_INTEGER는 -9007199254740991이다.

Number.MIN_SAFE_INTEGER -1 === Number.MIN_SAFE_INTEGER -2 //true

위의 코드에서 두 수가 더 이상 작아질 수 없기 때문에 true를 반환한다. 하지만 역시 부동소수점과 함께 사용하면 제대로 동작하지 않는다.

Number.MIN_VALUE

Number.MIN_VALUE는 JavaScript에서 표현할 수 있는, 0에 가장 가깝지만 음수는 아닌 수이다. Number.MIN_VALUE는 5e-324 이다.

무한

Number.MAX_VALUE 보다 큰 유일한 것은 Infinity 이고 Number.MIN_SAFE_INTEGER보다 작은 유일한 것은 -Infinity이다.

크기 순서

-Infinity < Number.MIN_SAFE_INTERGER < 0 < Number.MIN_VALUE < Number.MAX_SAFE_INTEGER < Number.MAX_VALUE < Infinity 

위의 코드와 같이 JS 숫자의 크기를 가장 작은 것(왼쪽)부터 가장 큰 것(오른쪽) 순으로 요약했다.

URL 은 Uniform Resource Locator의 줄임말로, 네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위치한 정보를 나타낸다.

URI

URI 는 Uniform Resource Identifier의 줄임말로, 일반적으로 URL의 기본 요소에 더해 query, bookmark를 포함한다.

query는 웹 서버에 보는 추가적인 질문이다.

URI 는 URL을 포함하는 상위 새념이다. 따라서 'URL은 URI이다' 는 참이고, 'URI는 URL이다는' 거짓이다.

URL , URI 구성 요소

• scheme : 통신 프로토콜이다.
  • file://, http://, https://
• hosts : 웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP이다.
  • 192.168.1.1,www.naver.com
• port : 웹 서버에 접속하기 위한 통로이다.
  • :80, :8080, :3000
• url-path : 웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일 위치까지의 경로를 나타낸다
  • /search, /User/username/Desktop
• query : 웹 서버에 전달하는 추가 질문이다.
  • name=이동욱,q=JavaScript