대학교 3학년 때 안드로이드 강의를 들을 일이 있었고, 이때 간단한 자바 문법과 객체지향에 대한 배운 경험정도가 전부이다.

자바의 정석을 통해 자바 기초부터 다시 공부하고, 이펙티브 자바를 통해 좀 더 깊게 이해할 수 있었음 좋겠다.

그렇다면,

고객이 대출을 상환하는데에 있어서 어떤 방법으로 갚을 수 있을까?

전에 거치기간이라는 개념 부터 알아보자.

원금을 갚지 않고 이자만 지불하는 기간을 의미한다.

거치기간이 1년이면, 1년동안은 빌린 원금에 대한 이자만 지불하고 1년이 지난 이후부터 원금과 이자를 동시에 갚는(= 원리금이라 한다) 방식이 된다.

이제부터는 대출을 상환하는 방식에 대해 기술해 보겠다.

첫번째, 만기일시 상환이다

만기일시 상환은 대출 기간동안 이자만 내는 것이다. 원금을 갚지 않기 때문에, 원금에 대한 이자가 가장 많이 나가게 된다.

보통 전세자금 대출이 이에 해당한다. 전세기간동안 대출금에 대한 이자만 내고, 전세가 끝나서 집주인에게 보증금을 돌려 받으면 은행에 상환하는 방식이다.

두번째 , 원금 균등 상환이다.

원금 균등 상환은 이름에서 유추 할 수 있다 싶이 원금을 균등하게 상환하는 방식이다. 원금을 균등하게 갚다 보니, 상환 금액은 초반이 가장 많다. 매달 갚아야 하는 금액이 지속적으로 변해서 헷갈리겠지만 점점 줄어든다. (이자를 내야하는 원금의 양이 줄어들기 때문이다!)

마지막으로 원리금 균등 상환이다.

원리금을 균등하게 지불해야 하니 초반에 상환하는 원금 비율이 적다. 밑의 그림을 보면 이해가 쉬울 것 같다.

마이데이터 관련 이야기도 해보고자 한다.

금융 어플 ( 은행, 증권사 , 핀테크 등등 ) 에서 모든 계좌를 모아서 볼 수 있는 기능을 빈번하게 볼 수 있다.

마이데이터 덕분인데 , 해당 법률을 찾아보면 이와 같음을 알 수 있다

개인이 동의하게 된다면 , 본인의 금융 관련 정보를 API를 통해 끌어올 수 있다는 내용이다.

마이데이터 부서와 협업하는 과정에 있어 개인의 여신 계좌 거치기간의 시작 연월과 끝나는 연월 정보를 추가적으로 제공하는 프로젝트를 진행했었다.

사실 어려운 프로젝트는 아니였지만 (실행일에다가 거치기간을 더해서 연월 정보만 잘라내서 제공해주면 되는 것이므로)

거치기간이라는 개념을 알게 해준 것이 마이데이터 프로젝트여서 함께 정리해 본다.

대환대출 시스템

시스템을 구축하거나 그런 건 아니였고 전문들을 관리하는 서비스를 만드는 프로젝트를 하게 되었다. 그래도 곁눈으로 많이 보고 배우면서 은행의 프로젝트가 어떤식으로 진행되는지 알 수 있었다.

대환대출이란?

우선 대환대출이라는 것이 어떤 건지 설명을 해보자면,

A은행의 대출을 갚기 위해 B은행의 대출을 새로 신규하는 것 이라고 보면 된다. A은행에 입장에서는 고객이 도중에 대출을 완제하고 나간 거고, B 은행에서는 신규 고객이 들어온 셈이다.

하지만, 당연히 A은행에서는 손해다. 원래 대출을 만기까지 가지고 갔으면 받을 수 있던 이자가 있는데 말이다.

5월 말인가 6월 초에 오픈을 한 이후, 뉴스 기사를 통해

이렇게 어떤 은행이 신규을 잘 했냐.. 를 알 수 있었다.

대출이동시스템은 위에 볼드체로 적혀있는 글씨의 모든 과정이 하나하나 쪼개져서 (더 이상 자세히 말하지는 않겠다 ... 내가 만든게 아니니까 ...)

*금융결제원 전산망에 송수신 함으로써 대환 대출을 총체적으로 관리하게 하는 시스템이다. *

그나저나, 모든 은행은 가능한 대출 조건을 보여주거나 대출 가능 여부를 확인하기 위해 신용평가 모델을 태울텐데

모든 은행에 있어서 모델을 태우고 비교하는데에 시간이 꽤 걸리지 않았을 까 싶다.

대용량 데이터에 대한 감이 없고 어떠한 로직으로 상품을 비교하는 지를 모르니... 언젠가 알아봐야 겠다는 생각을 했다.

프로젝트 공부거리

1. 페이징 처리

프로그램을 이행시키고 다음날 사정이 있어서 회사를 못갔더니, 프로그램이 터져서 거래가 안되었다고 했다.

사유를 알아보니 , 너무 많은 데이터가 들어왔는데, 페이징 처리를 안해놔서 터졌다는 것이었다. (화면에서 받을 수 있는 데이터는 한정되어있었지만 백에서 많은 데이터를 줘서 화면이 터진다 )

어찌저찌 페이징 처리를 했지만 ... 외부 프레임워크에서는 어떤 방식으로 페이징 처리를 하는 지 궁금했고 공부를 할 예정이다.

웹 프로젝트를 한 경험이 거의 없어서 어떤 방식일지 궁금했다.

2. SQL indexing

전문의 양이 적지 않았고 전문을 저장하는 테이블의 칼럼이 최소 30개였다. 조회 조건은 대략 6가지 였는데 모두 NVL을 적용시켜줬지만 속도가 너무 느렸다.

그래서 화면단에서 날짜값을 필수적으로 입력받게 설정을 했다.

함께 프로젝트를 도와주시는 선배님께서

인덱싱 하고 싶거나 할게 있을거 같으면 말하라 하셨는데 솔직히 어떠한 기준으로 인덱스를 걸어야 할지 뭐 아는게 있어야 말이라도 하지...

최근에 인덱싱이 트리 베이스 라는 걸 알았지만 실질적으로 업무에서 어떤 걸 걸어야 겠다 라고 자신있게 말 못하겠다 생각해서 조금 더 알아 봐야겠다는 생각을 했다.

쿼리 튜닝이라는 것도 있던데...

3. 리눅스

할말이 없다. 리눅스는 무조건 공부 많이 해야하니까..

자주는 아니더라도 이렇게 기록을 남겨야 발전하는 내 자신이 될 것 같아서 꾸준히 포스팅을 할 예정이다!

끝.

입사 직무는 클라우드 였기에 들어가기 전까지 클라우드 할 줄 알고 들어갔었다.

들어가서 생각을 하다 보니 ,

클라우드를 하기에는 조금 보수적인 회사 (금융법상 어쩔 수 없다)여서 부서배치 면담 때 마음을 틀었다.

그래서 나는 지금 모 시중은행의 여신 관련의 부서에서 일을 하고 있다.

여신이란? 용어 그대로 해석하면 자금을 주는 업무를 말하는데 일반적으로 대출을 말한다. 은행이나 보험사 등 금융기관의 대출, 할부금융, 주택금융, 팩토링 등이 이에 해당된다.

1년 전만 해도 내가 금융 도메인에서 일을 하게 될 거라고 생각도 한 적이 없었는데, 나름 하다보니 재밌어서 만족중이다.

아무튼, 그래서 이제 블로그에는 금융 IT 관련해서 글을 작성할 것이고

내가 있는 여신 뿐만 아니라 다른 수신, 외환 등 은행의 각 부서에 다양한 동기들을 만나서 그들의 업무를 물어보고 정리할 수 있는 시간이 있으면 정리도 하면서 진행할 것이다.

내가 업무에 있어 크게 공부를 해야겠다 느낀 부분

• SQL
• Linux
• DB 트렌젝션
• async, sync
• 은행의 인프라

내가 미래를 위해 하고 싶은 공부

• Cloud
• JAVA

재밌어 보이는 공부

• Frontend (취업해서 js를 우연찮게 거의 처음 써봤는데 ... 나쁘지 않아 보였다)

아마 이런 주제들을 가지고 내 맘대로 이야기를 좀 적어가보지 않을까 싶다

1. Vertical Scalability

• 수직 확장성 : 인스턴스의 크기를 키운다는 생각을 하면 된다. t2.micro -> t2.large
• non distributed system인 DB에 적합하다.
• RDS, ElastiCache가 수직 확장성을 늘려주는 서비스들 이다.
• 보통은 수직 확장에는 HW limit 이 있기 마련이다.

2. Horizontal Scalability (= elasticity)

• 수평 확장성 : 인스턴스와 어플리케이션의 수를 늘리는 것이다.
• Distributed System에 적합하다.
• EC2를 덕분에 수평 확장성을 늘리기 쉽다.

High Availabilty의 개념

• 2개 이상의 AZ에서 서비스를 실행하는 것이 서비스가 High Availability가 있다고 한다 하나가 고장나도 나머지 하나가 해주면 되기 때문

• 그래서 multi AZ 서비스가 고 가용성이라고 한다.(시험에서!)

Load balancing이란?

트래픽을 여러 서버로 나눠서 보내주는 것을 의미한다.

• 왜 로드 벨런서를 사용할까?

1. 말 그대로 load를 분산시킬수 있다.
2. 진행하는 서비스의 single point로 나타낼 수 있다. DNS를 사용하면 되기 때문이다.
3. 서비스의 실패를 방지하기 위해 지속적으로 health check를 한다 (참고로 health check는 인스턴스들이 제대로 작동하는지 확인을 해주는 것이다)
4. 쿠키를 쓴다 ( 이따 나온다!)
5. public traffic 과 private traffic을 구분시켜 놓는다
6. 고가용성을 갖는다

등등이 있다.

Elastic load Balancer

• 엘라스틱 로드 벨런서는 AWS의 로드 벨런싱 시스템이다. AWS의 다양한 서비스와 통합되어 편하게 사용할 수 있다.

• 보안그룹을 사용할 수 있다.

Target Group

ELB에 등록된 EC2 인스턴스의 그룹이다.

Load Balancer의 4가지 종류

1. Classic Load balancer

• 가장 구형의 로드 벨런서 이다.
• L4/L7을 모두 지원한다.
• EC2-Classic을 사용하는 경우에 사용한다.

2. Application Load balancer

• L7 로드 벨런서이다.
• HTTP/HTTPS Header의 정보를 담아 요청을 전달한다.
• 각각 다른 경로로 리다이렉트 및 고정 페이지를 보여준다. (쿼리를 사용하거나 path를 사용할 수 있다) 이를 target group이 다르다고 표현할 수 있다. 즉, multiple target group에 route 할 수 있으며, health check는 target group 단위로 이루어진다.
• micro services, container-based application 에 적합한데, ECS의 dynamic port를 사용해 리다이렉션을 할 수 있기 때문이다. (ECS는 후에 나오지만 컨테이너 기술이다)
• target group: EC2 인스턴스, ECS , Lambda function, private IP가 될 수 있다 . (람다 함수는 serverless한 서비스를 제공하기 위한 방법인데 후에 나온다)
• X-forwarded-for을 사용해 EC2가 클라이언트의 IP를 확인할 수 있다.

3. Network Load balancer

• L4 로드 벨런서이다.
• TCP,UDP를 기반으로 하고, 성능이 굉장히 좋다.
• NLB는 AZ마다 고정 IP 가 생성된다.(elastic IP 사용도 가능하다)
• Target group: EC2, private IP, Application Load Balancer가 될 수 있다. (ALB랑 결합하는게 은근 많이 나온다 : 고정 IP를 가질 수 있어서 결합한다고 한다. )

4. Gateway Load balancer

• L3 로드 벨런서이다.
• 모든 트레픽이 가상 환경을 통과할 수 있게 만든다 (방화벽을 생각하면 편하다)
• Transparent Network Gateway : 모든 트레픽의 entry , exit을 파악한다
• GENEVE 라는 프로토콜을 사용하고 , 6081 포트를 사용한다.
• Target Group : EC2 인스턴스, private IP

Sticky Session

• CLB,ALB에만 적용되는 기술로, 같은 클라이언트로부터 온 트래픽을 알 수 있는 기술이다.
• 쿠키 라고 불린다 !
• 사용 예시 : 사용자가 세선 데이터를 잃지 않게 하고 싶다 !

쿠키의 종류

1. Application-based Cookies

• Custom Cookie 타겟에 의해 생성된다. 애플리케이션이 필요한 정보를 담을 수 있다. 이름이 각 target group 마다 specified 되어야 한다

• Application Cookie 로드 벨런서에 의해 생성된다 쿠키의 이름은 AWSALBAPP이다. ( 커스텀 쿠키에서 이름 사용 못하게 만든다 )

2. Duration-based Cookie 특정 기간이 지나면 만료가 되는 쿠키이다. 로드 벨런서가 생성한다. 이름이 정해져 있다.

Cross-Zone Load Balancing

• 교차영억 로드벨린싱은 EC2 개수에 기반으로 로드벨런싱을 하는 것이다.

• 예를 들어, AZ 1에는 인스턴스가 2개, AZ 2에는 인스턴스가 8개 있다고 하자 기본적으로 ELB는 AZ별로 Load를 50프로씩 뿌린다 교차영역 로드 벨런싱을 한다면 20:80으로 뿌린다. (EC2가 2:8 이니까)

• ALB CLB NLB 모두 지원하는 기능이다. (default로 ALB만 켜져있다)

SSL (Secure Sockets Layer)

• SSL은 client와 load balancer 사이의 트래픽을 암호화 시켜준다.
• TLS라고 Transport Layer Security도 나왔다.
• 만기일이 있다
• 로드벨런서는 ACM을 사용해 인증을 한다 (= AWS Certificate Manager)
• ACM에 개인 인증서를 올려서 인증 할 수도 있다.

SNI

Server Name Indication

• 하나의 Web server에 여러개의 SSL 인증서를 로딩해야하 하는 문제점을 해결해준다.
• 클라이언트가 처음 SSL handshake에서 hostname을 명시함으로써 어떠한 인증서를 사용해야 하는지 알려준다
• ALB,NLB,CloudFront 적용

Listener

포트로 들어오는 요청을 처리해주는 장치라고 생각하면 된다.

• ELB에서는 multiple listener를 둘 수 있고, multiple SSL certificate도 지원한다 SNI를 활용할 수 있다.

• NLB에서는 multiple listener를 둘 수 있고, multiple SSL certificate도 지원한다 SNI를 활용할 수 있다.

• CLB에서는 하나의 SSL certificate을 지원한다. multiple SSL certificate을 지원하고 싶으면 CLB 자체를 여러개 써야 한다.

Connection Draining

오토스케일링과 ELB를 같이 사용할 때, EC2 인스턴스 삭제시 세션이 완료되는 것을 기다리는 기능이다. 작업이 완료되지 않았는데, 오토 스케일링으로 인해 EC2 인스턴스가 삭제되면 안되기 때문.

Auto Scaling Group과 ELB

• ELB가 자동으로 EC2 instance를 증가(Scale out)시키거나 감소(Scale in)시키고, 등록도 한다. (load의 양에 따라)
• CloudWatch Alarm을 사용해 scaling이 가능하다. 기준은 마음대로 만들어 낼 수 있다.
• min,max number of EC2 instance가 정해져있다.
• 만약 not healthy 한 인스턴스가 있으면 종료시키고, 새로운 인스턴스를 만들어 대체한다.

ASG - 스케일링 방법론

1. Target Tracking Scaling 평균값을 목표로 인스턴스를 조절

• CPU가 40% 정도 쓰였으면 좋겠어요

2. Simple/step scaling Simple : 임계치에 도달하면 인스턴스 조정 Step : 여러가지 조건을 달 수 있다 ( Simple과 기본 원리는 같다)

• CPU가 70퍼 이상 쓰이면 2개 unit 더해주세요
• CPU가 30퍼 이하로 쓰이면 1개 unit 빼주세요

3. Scheduled Action 미리 생각해 두는 것

• 금요일 밤에는 트래픽이 보통 많으니 미리 넣어두자

CPUUtilization , RequestCountPerTarget , Average Network in,out 등 기준으로 할 것이 많다.

ASG - Scaling cooldown

• 인스턴스 생성, 제거를 후 또 다시 스케일링이 되어야 한다는 알림이 와도, 휴지기를 갖는 것
• 기본 설정은 300초이다.

ASG - Termination Policy

• 인스턴스가 가장 많은 AZ의 가장 오래된 instance부터 없앤다.
• AZ간의 인스턴스의 수를 맞추기 위한 정책

ASG - Lifecycle Hook

• Scale In,out 이후 Inservice 전에 , 사용자가 미리 정의한 작업을 하는 시간을 제공한다.

• 인스턴스 시작, 종료 시 사용자가 작업을 수행할 수 있다. 예를 들어, 종료 전에 작업 로그나 파일을 추출하고 종료하는 형식의 작업을 미리 설정해 둘 수 있는 것이다.

끝!

아 진짜 양 많네..

Elastic Block Store Volume : 네트워크 상 존재하는 storage

• Instance가 실행 중이거나 종료되어도 데이터를 보존할 수 있게 해준다.

• Volume 하나 당 EC2 하나에 부착 될 수 있다

• EBS volume은 특정 AZ에 한정되어 있지만, 다른 AZ에 옮길 수는 있다. (snapshot을 사용해서 다른 AZ에 또 만들면 된다)

EBS Volume Type

1. General Purpose SSD (gp2, gp3): 적절한 가격과 성능을 가지고 있어서 다양하게 쓰일 수 있다.

2. Provisioned IOPS SSD (io1, io2) : 좋은 성능을 가지고 있어서 low-latency + high-throughput 참고로 io1,io2는 데이터베이스 용도로 많이 쓰이고, Multi-Attach가 가능하다. (동일한 EBS를 EC2 여러개에 붙일 수 있다는 의미)

3. HDD(st1): 저렴한 HDD이고, 자주 접근하는 데이터 전용이다.

4. HHD(sc1) : 가장 저렴한 HDD , 자주 접근하지 않는 대용량 데이터 처리에 적합하다.

gp2, gp3, io1, io2 만 부트 볼륨으로 사용할 수 있다.

Instance 종료시 EBS 삭제여부

• Instance 종료시 EBS를 삭제할 지 말지 결정할 수 있다. Default = 삭제

EBS Encryption

• EBS를 암호화 하면, 내부에 있는 데이터와 인스턴스 사이의 데이터, 생성된 Snapshot, 그 Snapshot으로 부터 생성된 볼륨이 모두 암호화 된다.

• KMS(AES-256) 알고리즘을 사용해 암호화 한다.

AMI

Amazon Machine Image

• 인스턴스를 시작하는 데 있어 필요한 정보를 제공하는 이미지
• pre-packeged 되어 있기 때문에 필요한 환경 조성 시 빠르다.

EC2 Instance Store

• EBS Volumes 들은 제한된 성능을 가지고 있어서, 더 좋은 성능을 내기 위해 사용할 수 있다.
• 하드웨어가 고장나면 데이터 다 사라진다

EFS

NFS (Network File System)을 사용한 서비스로, 여러 EC2에 장착 될 수 있다.

• 쓴 만큼 돈을 내는 것이기 때문에 미리 크기를 잡아둘 필요가 없다.(Auto-Scaling도 가능하다)
• Multi-AZ 성격을 띄고 있다. = 여러 AZ에서 엑세스가 가능하고, 중복 저장되기 때문에 하나가 파괴되어도 상관 없다.
• Linux bases AMI에 적합하다.
• KMS 알고리즘을 사용해 암호화 시킨다.

EFS의 Performance mode 와 Throughput Mode

1. Performance mode (2가지) 기본적으로 latency sensitive 한 General purpose (웹 서버) MAX I/O : 지연시간이 길어지지만, 엑세스 하는 EC2가 많으면 사용 (미디어)

2. Throughput mode Bursting mode Provisioned : 처리량이 많으면 용량과 속도를 결정해 놓을 수 있는 모드를 사용

EFS의 Storage Tiers (생명주기)

• EFS Standard : 자주 접근되는 파일을 저장
• EFS IA(Infrequent access) : 저장하는 데에 저렴하지만, 찾을 때 돈 낸다. 접근이 안된 파일을 보냄 (기준은 정하기 마련)

EBS vs EFS 내용 정리

1. EBS

• 하나의 인스턴스에 하나만 붙을 수 있다.
• AZ 제한이 존재, 다른 AZ에 보내려면 snapshot 사용해야 한다!
• 기본적으로 Instance가 종료되면 EBS도 삭제 된다 ( 설정으로 바꿀 수 있다 )

2. EFS

• AZ 제한 없다.
• Linux Instances 전용 (POSIX)
• EFS가 EBS에 비해 비싸지만 , EFS-IA를 사용하면 좀 더 싸진다.

3. EC2 Instance Store도 있다는 거 기억!

EC2 = Elastic Compute Cloud

• EC2는 가상 머신을 빌려준다. OS가 사전 설치되어잇으며, 하드웨어 성능을 지정할 수 있다.

• Storage 방식이 두가지로 나뉨 네트워크 부착형인 EBS,EFS 하드웨어 형식의 EC2 Instance Store

• Security Group으로 방화벽 설정 가능하다

• 첫 부팅때 적용시킬수 있는 코드를 EC2 User data에 넣을 수도 있다.

• EC2 인스턴스 명명법 m5.2xlarge m : instance class , 5 = generation , 2xlarge = instance class의 사이즈

• 인스턴스를 고를 때 어떤 것에 초점을 맞출 지 고민해야 한다. Compute / Memeory / Networking

• EC2 인스턴스 role에 IAM을 활용하면 된다

EC2 Instances 구매

1. On demand = 필요할 때 바로 사는 것 , 예측할 수 없는 경우에 사면 편하다.
2. Spot = 경매 방식으로 사용. 다른 사람이 더 높은 가격에 사가면 인스턴스가 갑자기 종료된다. (2분 주니까 stop or terminate 하라고 한다)
3. Reserved = 예약하는 방식. 1,3년을 선택할 수 있으며 가격이 저렴해진다.
4. Dedicated = 통채로 빌린다.

• spot instance를 멈추게 하기 위해서는 spot request를 먼저 지우고 instance를 지워야 한다. 역순이 되면 , request가 instance를 다시 요청하기 때문에 안된다.

Spot Fleets

• Spot Fleet은 Spot Instance들과 On demand Instance를 결합시켜 사용하는 것
• 가격의 제한을 두고 가장 적절한 instance를 잡아준다.
• 자동으로 가장 저렴한 spot instance를 찾아주는 것이 핵심

Security Group

• EC2로 나오고 들어가는 traffic을 조절 할 수 있다. 여러 인스턴스에 적용 가능하고, 지역에 따라 한정되어있다.

Security group을 잘 활용해서 EC2에 붙이면 보안을 잘 설정할 수 있다.

Elastic IP

Fixed public IP를 Instance에 사용하고 싶을 때 사용할 수 있다.

• 계정당 5개로 제한 되어있다.
• Elastic IP 사용하는 것 보다는 random public IP 쓰고 DNS 설정 추천 아니면, 로드 벨런서 쓰는 것이 낫다.

Batch Group

• EC2를 쓰는 목적을 잡기 위해 사용

1. Cluster : Single AZ에서 low-latency를 구현 같은 HW,AZ여서 매우 빠르지만, HW가 고장나면 끝이다. 사용 예시) Big data 작업, low latency + hig network throughput이 필요한 곳

2. Spread : 인스턴스 개체 하나가 하나의 렉에 분산되어 배치된다. 사용 예시) 안정성이 강하기 때문에 항상 돌아가는 서비스에 사용한다.

3. Partitaion : 인스턴스가 담긴 그룹을 논리적으로 나누어 파티션에 놓는다. 파티션 별 자체 렉, 네트워크 전원이 나누어져 있다.

2,3번은 각각 개수의 제한이 존재한다.

ENI

• 가상의 네트워크 카드이며, EC2 가 Network에 Access 가능하게 해준다.
• EC2와 독립적으로 존재하며, AZ에 bounded
• 탈부착이 자유롭다.

EC2 Hibernate

• EC2의 상태 : Stop : 잠시 멈춰 두는 것 Terminate : 아예 종료된다 (없어진다)

• Hibernate는 RAM을 보존시켜 , 재시장 부팅이 빨라진다.

• EBS에 RAM을 저장하는 형식이지만, 하이버네이트 시키는 데 시간이 좀 걸리고, 60일 이상은 안해준다.

EC2 Nitro

아주 빠른 EBS를 사용할 수 있게 해주는 신세대 EC2 instance

마치며

서비스를 소개하는 느낌이다 보니 순차적으로 모든걸 담기가 쉽지가 않다.

강의로 1회독을 하고 정리를 하다 보니 모르는 단어는 별로 없어졌지만,

처음 공부했을때 헷갈릴만 하다는 생각이 들었다.

안배운 EBS가 포스팅 후반에 나와 대충 말하자면, EBS는 데이터를 가상 머신에 저장하는 Storage를 의미한다.

• Region은 data center의 cluster 이다.

• US-EAST-1 , US-EAST-2 , AP-EAST-1 등 전 세계에 분포되어 있으며, 많은 AWS 서비스들은 Region-scoped 되어있다.

• 어떠한 지역에 나의 서비스를 런칭할 건지 결정하기 위해 기준이 있다. 법률규제라던가 , 가격 , latency 등이 있으며

• 가장 중요한 것은 모든 서비스가 모든 리전에서 제공되지 않기 때문에 잘 알아보고 해야 한다.

AZ

• Availability Zone을 각 Region이 가지고 있다고 생각하면 된다. ap-southeast-2a , ap-southease-2b 식이다.

• 각 AZ는 하나 이상의 데이터 센터를 가지고 있고 , 각 AZ는 서로 분리되어 재해로부터 독립적이다.

• AZ끼리는 고성능의 네트워크로 서로 이어져 있다.

AWS의 서비스들

Global Service : IAM Route 53 CloudFront WAF

Region-scoped : EC2 Beanstalk Lambda Rekognition

이런식으로 Global (리전에 상관없이 제공되는) 과 Region마다 나누어져 있는 서비스가 따로 있다.

IAM

IAM : Identity and Access Management

• Root account : 기본으로 설정되어 있으며 , 사용자들이 사용하지 못하게 해야한다.

• User : 조직에 있는 사람으로써, 그룹화가 가능하다 (User는 다양한 Group에 들어갈 수 있다.)

• Group : 사람을 포함할 수 있는 집단이다. (Group 안에는 또 다른 Group이 들어갈 수 없다

IAM Permission

• User와 Group은 정책을 가질 수 있다.

• 권한들을 JSON 문서로 나타내어 관리하고 있으며, least privilege principle 로 정책을 관리 해야 한다. (최소한의 권한만을 제공해 주어야 한다. )

• Group에 정책을 설정해 두면 , 그 그룹안에 있는 user들에게도 모두 그 정책이 적용되며, 개개인에게도 따로 정책을 지정해줄 수 있다.

• 즉, 어떤 user가 group policies와 개인 정책 모두 가질 수 있다는 뜻

IAM Policies Structure

Sid : statement을 구분해주는 구분자다

Effect : 정책이 허용하는 정책인지 거부하는 정책인지 알려준다.

Principal : 어느 곳에 정책이 적용되는지 알려준다

Action : 허용되거나 거부되는 행위를 알려준다 ( GetObject 등)

Resource : 적용되는 곳이 어딘지 알려준다

Condition : 어떤 조건에서 이 정책이 적용되는지 알려준다.

Multi Factor Authentication - MFA

MFA = password + security device you own

다중 잠금 장치라고 생각하면 된다 .

(비밀번호를 누가 알아도 계정을 쓸 수 없다 )

AWS 접근 방법

1. Console로 접근 할 수 있다. (password + MFA)
2. CLI 로 접근할 수 있다
3. SDK를 사용해 접근 할 수 있다. (Application 내부에 넣어 놓음)

access key가 2,3번의 방법에 필요하며, API 사용에도 쓰인다.

IAM 정책을 서비스에 적용하기

• AWS service에 permission을 주기 위해 IAM Role을 사용한다. EC2 Instance Role , Roles for CloudFormation 등으로 말이다.

IAM 보안 도구

• IAM Credentials Report (account-level) Acoount의 사용자들이 각각 어떤 자격증명을 받았는지 알려준다.

• IAM Access Advisor(user-level) user에게 부여된 허용 권한이 어떤 것이고, 최근에 접근했는지 알 수 있다.

IAM Guideline

1. 루트 계정을 사용하지 마라
2. 실제 사람 한명당 하나의 AWS user를 설정해라
3. 그룹에 권한을 주고 그 그룹에 유저를 넣어라
4. 비밀번호를 빡세게 잡아라(어렵게 해라)
5. MFA를 사용해라
6. Role를 만들어서 AWS service에 허용 권한을 줘라
7. Access key를 활용해 CLI,SDK를 사용해라
8. IAM Credentials Report를 사용해 계정의 허용권한을 봐라
9. 계정 공유 x

복습 겸 내용을 블로그에 정리할 예정입니다.

무슨 시험인지 궁금하다면?

현재 udemy를 활용해 공부중이며, 강의가 마무리되는대로 기출을 돌릴 예정입니다

노골적인 강좌제목

끝!

아래는, 구글에서 제공하는 1단원의 학습 목표이다.

In this lab you will familiarize yourself with the basic Docker container environment commands. You will create, run, and debug containers, and learn to pull and push images to and from Google Container Registry.

베이직 도커 컨테이너 환경 커멘드에 대해 알고 컨테이너 이미지를 pull push 할 수 있게 된다.

나는 도커에 대한 기본적 배경 지식도 없어서 위 소개글의 image를 그림 파일이라고 생각하고 있었다.

이해가 가지 않아 , 유튜브에서 도커에 대한 기본적 영상을 찾아보고 개념을 세웠다.

개인적으로 좋아하는 나동빈씨가 정리해준 Docker 개념

Docker containers can be directly used in Kubernetes, which allows them to be run in the Kubernetes Engine with ease. After learning the essentials of Docker, you will have the skillset to start developing Kubernetes and containerized applications.

쿠버네티스에 도커를 쓰는 방법에 대해 알려준다 한다.

실습 시작!

Cloud Shell 과 명령어

실습에서는 전부 구글에서 제공하는 학습용 계정을 사용하게 된다.

Cloud Shell은 사이트에서 CLI 를 사용할 수 있게 해주는 역할을 하며(AWS에도 똑같은 것이 있다)

빨간 버튼을 누르면 CLI가 열린다.

Google cloud에서 쓰는 커멘드 앞에는 'gcloud' 가 붙게된다.

이런 식으로 말이다 !

더 많은 명령어가 궁금하다면 공식 문서를 참조하자.

Run docker

docker run hello-world

를 입력하면 ( 찾아보니까 도커에서 입문자들 용으로 만들어 놓은 것 같다 )

이런 창이 나오게 된다.

This simple container returns Hello from Docker! to your screen. While the command is simple, notice in the output the number of steps it performed. The docker daemon searched for the hello-world image, didn't find the image locally, pulled the image from a public registry called Docker Hub, created a container from that image, and ran the container for you.

학습자료에서 중요한 키워드는 Docker deamon이 주도적으로 image를 찾는다는 것.

그리고 local에서 찾지 못하면 공용 저장소인 Docker Hub라는 곳에서 찾아서 가져오고 container를 image로부터 만들어 작동시켜 준다 라는 이야기이다.

그렇게 다운받아 온 이미지를 확인해 볼 수 있다.

이제 다시

docker run hello-world

를 입력하면 이런 창이 뜬다.

docker daemon이 image를 local에서 발견했기 때문에 Docker hub에서 이미지를 가져 올 필요가 없다.

현재 실행되고 있는 컨테이너를 볼 수 있을 때 쓰는 커멘드

(이미 hello-world container는 종료된 상태이다)

옛날 기록도 볼 수 있게 하려면 docker ps -a 를 사용하면 된다.

Container ID는 도커에서 Container identify 하기 위해 설정.

Name도 랜덤하게 만들거나,

docker run --name [container-name] hello-world 을 사용해 지정할 수 있다.

Build

도커 파일을 만들어 주면 된다 .

3번째 ADD ./app 에서 .이 현재 디렉토리를 뜻하는 역할을 한다.

docker docs

간단한 서버를 작동시켜주는 node application을 만들어 본다.

Dockfile이 있는 디렉토리에서

docker build -t node-app:0.1.

-t는 이름을 붙여주기 위해서 사용하는 것이고 ,뒤에 0.1은 tag라고 한다. 테그를 확실하게 적어주지 않으면, 구형 image들과 헷갈릴 수 있다.(지정 하지 않으면, latest라는 테그로 설정됨.)

docker images 를 통해 생성된 도커들을 볼 수 있다.

node는 node-app의 base image여서 , node-app을 지우지 않은 상태에서 node 를 먼저 지울 수 없다. (참고로 여기서 사이즈를 보면, vm보다 훨씬 작다는 것을 알 수 있다 ! 더 작은 image들도 있다 하니 관심 있으면 찾아보면 된다. )

Run

컨테이너를 돌려보자 !

docker run -p 4000:80 --name my-app node-app:0.1

--name은 container의 이름을 설정해준다. -p는 host의 포트인 4000을 container의 포트 80에 mapping 시켜줄 수 있다.

http://localhost:4000 을 사용해 서버에 접근할 수 있게 되는 것이다!

와우~

이제 my-app container을 중지시키고, 삭제하자.

새로운 터미널 창을 열어서,

docker run -p 4000:80 --name my-app -d node-app:0.1

도커를 다시 돌려보고

docker ps

도커 목록을 뽑아보자

참고로 container_id을 다 치지 않아도 된다. 초반부 몇 글자정도만 쳐도 된다.

아까 만들었던 test 에 가서, 파일의 일부를 바꾸고 0.2 tag를 붙여 다시 빌드를 해보자.

step 2에서 cache를 쓰는 모습을 볼 수 있고 step 3 부터는 파일 정보가 바뀌어서 새롭게 만들어 지는 것을 볼 수 있다.

새로운 포트를 잡고 node-app:0.2를 실행 시킨다.

4000번 포트의 컨테이너와 8080 포트의 컨테이너가 모두 잘 실행되고 있다.

Debug

로그들을 실시간으로 볼 수 있는 -f

컨테이너 내부에서 bash를 사용하고 싶을때 , 새로운 창을 열어서

docker exec -it [c_id] bash

를 치면 된다

workdir 에서 bash가 실행되는 점!

ls 로 현재 디렉토리 봐주고

exit 하면 나가진다.

docker의 metadata를 볼 수 있는 command

json형식을 사용해서 특정 값만 뽑아 낼수도 있다.

inspect reference

exec reference

Publish

image를 Google Container Registry(GCR) 에 넣어놓고

내 모든 환경들을 리셋 후, 다시 깔아보는 실습을 진행한다.

프로젝트 아이디 찾아주고~

host id에 gcr.io를 붙여 push 할 준비를 하고

보내버리면 된다.

보내면 웹에서도 확인할 수 있다! (당연하지만..)

나에게 있는 모든 것들을 지워버리고...

image들도 다 지워버리고...

![] (https://velog.velcdn.com/images/computer_ing/post/5bcea52e-b284-4895-8081-1275e7e829f5/image.png)

gcr에 push 했던 image를 가져와서 실행시켜버리면.. 실행된다!

끝!

느낀점

1. js를 안해보다 보니까 사실 문법을 모르겠다 .

2. dockerfile의 형식에 대해서 공부를 깊게 해볼 필요가 있다.

3. 실제 프로젝트로 써보면 좀 알지도..?

1학기에 운영체제를 공부하면서, AWS를 사용할 기회가 있었고

그것을 계기로 AWS SSA를 준비하는 과정에 있다.

자연스럽게 클라우드 직무를 염두에 두게 되었고 준비 과정에 있어 쿠버네티스 + 구글 클라우드를 공부할 기회가 생겼다.

블로그에 글을 작성하면서 공부해 봐야 겠다는 생각을 하였다.

자꾸 지식을 저장해 놓지 않으면 붕붕 뜨는 느낌이 들었기 때문에...

멋진 야구모자는 덤이다 !...

👉 인터넷의 작동 원리

인터넷을 안 쓰는 사람은 없다. 하지만 작동법에 대해서 자신있게 말할 수 있는 사람은 몇이나 될까?

구글링을 시작해 보았다.

처음으로 본 영상

🖍 영상 요약본

• 인터넷은 Cloud가 아닌, Wire의 개념으로 이해하는 것이 맞다.

• Client는 Internet에 directly connected가 아닌, ISP(internet service provider)에 의해 연결된다.

• ISP와 Client의 연결 과정에서 DSL을 사용한다. ( DSL이 뭔지 잘 몰라서 찾아봤는데, 도메인 특화 언어라고 한다.)

• 정보를 보낼 때 쪼개서 보낸다. (Packet)

• 정보가 섞여서 보내게 되는 것을 방지 하기 위해서 IP주소를 사용한다고 한다.

• Router를 사용한 데이터의 송수신 과정 및 Boss와 나는 IP로 구분되어져 있다는 이야기. 업무시간에 Facebook하는 내용이 Boss의 컴퓨터로 가면 어떠겠냐고 물어봤다!

👍 좋은 영상인데, 내용이 부족하다.

마저 구글링을 해보았다.

두번째 자료 , 스텐포드에서 쓰는 1주차 내용이라고 하는데, 양이...

인터넷의 작동 원리가 그렇게 단순한게 더 이상한 것이기 때문에 꾹 참고 읽기로 하였다. 후에 작성할 포스트 내용도 여기 담겨 있는 것 같으니 말이다.

자료 읽기 시작 🖐

• 컴퓨터들의 고유의 IP address를 가지고 있어야 한다. 이 글에서 설명하는 것은 IPV4 address 인거 같다.
• ISP를 이용해 connect 하면 temporary IP를 , LAN을 이용해 connect하면 permanent IP, 또는 DHCP 가 주는 temporary IP를 얻는다고 한다. 핵심은 unique IP를 얻는다는 이야기이다.

DHCP가 뭔지 기억이 안나서 또 찾아보았다. DHCP의 동작 과정

• 정보를 보내기 위해서는 alphabetic 에서 electronic signal로 변환
• 받은 사람이 읽으려면 다시 electronic to alphabetic
• Protocol stack을 사용해 이 과정을 이루어지게 한다.
• Internet에 이용되는 Protocol stack은 TCP/IP stack. (우리말로는 TCP/IP 4계층이라고 했던 것 같다. OSI 7계층이랑 엮어서)

• Application Layer로 정보가 들어와서 Hardware Layer까지 정보 변환 후, Internet을 통해 상대방의 Hardware layer로 전달, 그리고 역으로 올라가는 과정에 대한 그림이다.

1. Top of protocol stack 에서 시작, 밑으로 간다.
2. Stack layer 내려갈때 마다 smaller chunk로 쪼개서 보내준다. (기억상으로는 각 단계에서의 chunk의 이름이 정해져 있던 거 같은데 ...)
3. TCP layer에 가면 Packet들이 port number을 할당받게 된다. 패켓들이 특정 포트로만 가기 때문에 어느 포트로 가야하는지 (어떤 프로그램이 사용하는지) 알아야 한다.
4. IP layer에 가면 이제 destination ip address를 알게 된다.
5. Port number과 IP address를 둘다 가지고 있기 때문에 전송될 준비가 된 상태이다. electronic signal로 바뀌주는 단계가 hardware layer에서 진행 된다.
6. ISP router가 보내준다. 어디로 보내는지에 따라 목적지가 달라질 수 있음. (다른 라우터로 갈 수도 있고, 아니면 뭐 같은 네트워크에 있으면 바로 destination으로 갈 수도 있음)
7. Destination에 도착 후, 4계층을 역으로 올라가는 과정이다.
8. 끝!

😇 끝