AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안
Slide share 에서 AWS 아키텍트에 대한 강좌
Source: AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안
요약
마이크로 서비스
정의: 위키피디아 - 작응 빌딩 블록, 높은 비결합성, 디자인 스타일, 작은 작업을 수행, 모듈식의 접근
Monolithic vs SOA vs Microservices
Microservices - API를 사용하여 연결
Monolithic
- 복잡한 코드와 관리의 어려움
- Bottleneck이 될 수 있는 배포
- 변경의 두려움
- 부족한 주인의식
- 연쇄 실패
- 확장의 어려움
마이크로 서비스로 얻을 수 있는 것들
- 서로 다른 언어로 개발 가능
- 쉽게 이해하고 수정 가능한 코드들 - 새로운 팀원의 생산성 향상
- 최근 기술을 비교적 쉽게 도입
- 빠른 서비스 시작 속도와 배포 속도
잦은 오해
- 다양한 기술과 신기술을 쓴다고 마이크로서비스는 아니다
조직 구조가 그대로 시스템의 구조로 나타난다 - 아키텍처와 팀조직은 긴밀하게 연결되어 있다
Amazon EC2 Container Service
- 유연한 컨테이너 배치
- AWS와 함께 사용되도록 설계
- 크기 상관 없는 클러스터 관리
ECS와 Route53
Weaveworks - Router/DNS
- 각각의 컨테이너간 관계 표시
Blue-Green 배포
'프로그래밍??? > AWS' 카테고리의 다른 글
ftp 접속 시 226 Transfer done (but failed to open directory). 에러 발생 (865) | 2018.08.28 |
---|---|
HVM vs PV 성능차이 (0) | 2017.12.26 |
고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced (0) | 2017.09.27 |
AWS EC2를 다른 리전으로 이전하기 (0) | 2017.08.29 |
AWS SDK for C++/Go and S3 upload time check (0) | 2017.05.29 |
고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced
Slide share 에서 AWS 아키텍트에 대한 강좌
Source:고급 클라우드 아키텍처 방법론- 양승도 솔루션즈 아키텍트:: AWS Cloud Track 2 Advanced
요약
디자인 원칙
- 추정을 하지 마십시오
- 프러덕션 시스템과 동일한 테스트 시스템을 구축하십시오
- 아키텍트 변경에 대한 위험을 낮추십시오
- 아키텍처에 대한 변경과 실험을 자동화 하십시오 - AWS CloudTrail / Config
- 지속적으로 아키텍처를 개선하십시오
- 보안(Security)
- 모든 영역에 보안 적용
- 추적 로그 수집
- 보안 이벤트 대처 자동화
- 보안에 대한 best practice 자동화
- 안정성(Reliability)
- 성능 효율화(Performance Efficiency)
- 비용 최적화(Cost Optimization)
보안 영역
- 데이터 보호
- 권한 관리
- 인프라 보호
- 감시 제어
보안 권장
- IAM 계정을 생성해서 권한관리를 하라
- MFA를 적용하라
- OS/App logs
- VPC Flow logs - 방화벽 로그
- AWS CloudTrail
- ELB
안정성
- 복구 절차 테스트
- 문제 발생시 자동 복구 구성
- 수평 확장으로 시스템 가용성을 높여라
- 필요한 용량을 추측하지 말라
- 하나의 리전에서 EC2 인스턴스는 초기 20개까지만 허용된다
- limit 해제 request를 할 수 있다
- Auto-Healing - Auto Scaling을 auto healing으로 할 수 있다(min-max를 1로 하여 하나만 운영할 수 있다)
- EC2 Auto recovery - EC2 인스턴스 하나에 cloud watch에서 이벤트를 걸어 운영할 수 있다
성능 효율화
- 최신 기술을 쉽게 사용하라 - 최신 타입 인스턴스
- 여러 리전에 서비스를 배포
- 서버리스 아키텍쳐 구성하라
- 더 자주 새로운 아이디어 실험
- 컴퓨터
- 스토리지
- 데이터베이스
- 용량-시간의 Trade-off
- Alarm Based Notification
- Trigger Based Actions
- CloudWatch
- 비용을 업무/부서별로 투명하게 - 태그 사용
- 관리 서비스 이용
- CAPEX를 OPEX로 전환
- 규모의 경제를 통한 혜택
- 필요한 만큼만 사용
- 비용 효율적인 자원
- 비용 인지
- 지속적인 최적화
- Cost Explorer
- CloudWatch Alerts
- CloudWatch Monitoring
- Tagging
- Spot Instance
- Reserved Instance (RI)
- AWS 보안 credential이 애플리케이션 소스코드에 하드코딩 하면 안된다
애플리케이션 디자인 원칙
- 장애를 대비한 아키텍처 디자인 하십시오
- 느슨한 결합 구조의 아키텍처가 여러분을 자유롭게 합니다
- 탄력적인 아키텍처를 구현하십시오
- 모든 계층에서 보안을 구축하십시오
- 제약조건을 두려워 마십시오
- 병렬적으로 생각하십시오
- 다양한 스토리지 옵션을 고려하십시오
'프로그래밍??? > AWS' 카테고리의 다른 글
HVM vs PV 성능차이 (0) | 2017.12.26 |
---|---|
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 (0) | 2017.09.28 |
AWS EC2를 다른 리전으로 이전하기 (0) | 2017.08.29 |
AWS SDK for C++/Go and S3 upload time check (0) | 2017.05.29 |
Amazon S3 REST API (0) | 2017.05.11 |
[20170831] Golang 프로젝트에 TDD 도입하기
Golang 프로젝트에 TDD 도입하기 - Golang Korean Community
위의 내용에 따라 간단한 테스트를 진행해 봤다.
이와 함께 assertion 패키지를 인스톨하고 사용했다.
if문으로 도배될 많은 테스트 코드들을 위해서 assertion은 필수라고 생각한다.
원래의 테스트 코드는 아래와 같이 if와 else로 구성할 수 밖에 없다.
func TestGetWords(t *testing.T) { if words, err := dbjobs.GetWords(); nil != err { t.Error("GetWords() return error. " + err.Error()) } else { tWord := []string{"a", "c", "d", "xxdfs", "ワード"} isSame := true for i, _ := range words { if words[i] != tWord[i] { isSame = false break } } if isSame { t.Logf("result is %v", words) } else { t.Errorf("Value is Not valid. \n first %v \n second %v", tWord, words) } } }
github.com/stretchr/testify 패키지를 인스톨하고 assert로 변경한 코드이다.
func TestGetWords(t *testing.T) { assert.Equal(t, 123, 125, "they should be equal") assert.NotEqual(t, 123, 456, "they should not be equal") words, err := dbjobs.GetWords() assert.Nil(t, err) t1Word := []string{"a", "c", "d", "xxdfs", "ワード"} assert.Equal(t, t1Word, words, "Words are not what I want.") t2Word := []string{"a", "b", "c", "d", "xxdfs", "ワード"} assert.Equal(t, t2Word, words, "Words are not what I want.") }
assertion 사용에 따른 결과는 아래와 같다.
Error Trace: job4mariadb_test.go:32 Error: Not equal: expected: 123 actual: 125 Messages: they should be equal Error Trace: job4mariadb_test.go:40 Error: Not equal: expected: []string{"a", "c", "d", "xxdfs", "ワード"} actual: []string{"a", "b", "c", "d", "xxdfs", "ワード"} Diff: --- Expected +++ Actual @@ -1,3 +1,4 @@ -([]string) (len=5) { +([]string) (len=6) { (string) (len=1) "a", + (string) (len=1) "b", (string) (len=1) "c", Messages: Words are not what I want.
-꼬리-
* 티스토리의 스타일 변경을 했다가 오랜 시간 기존 작성글들을 다시 수정해야 했다.
* 그 과정에서 오늘자로 작성한 내용이 날아갔다. ㅠ.ㅠ
* 그래서 간략히 다시 작성
'프로그래밍??? > 매일코딩' 카테고리의 다른 글
[20171227] git difftool로 beyond comprare 사용하기 (0) | 2017.12.27 |
---|---|
[20170830] Go에서 테스트 작성하기 (0) | 2017.08.31 |
[매일] 시작 (0) | 2017.08.31 |
[20170830] Go에서 테스트 작성하기
Go에서 테스트 작성하기 - 예제로 배우는 GO 프로그래밍
위의 내용을 참고하여 job4mariadb_test.go를 만들고 테스트를 하였다.
gogland에서 자동완성으로 테스트명과 테스트 함수를 편하게 생성할 수 있다.
또한 해당 파일만을 컴파일할때는 자동으로 go test를 실행해준다
package dbjobs_test import ( "testing" "asker/theWords/dbjobs" ) func TestGetWords(t *testing.T) { if words, err := dbjobs.GetWords(); nil != err { t.Error("GetWords() return error. " + err.Error()) } else { tWord := []string{"a", "b", "c", "d", "xxdfs", "ワード"} isSame := true for i := range words { if words[i] != tWord[i] { isSame = false break } } if isSame { t.Logf("result is %v", words) } else { t.Errorf("Value is Not valid. \n first %v \n second %v", tWord, words) } } }
'프로그래밍??? > 매일코딩' 카테고리의 다른 글
[20171227] git difftool로 beyond comprare 사용하기 (0) | 2017.12.27 |
---|---|
[20170831] Golang 프로젝트에 TDD 도입하기 (0) | 2017.08.31 |
[매일] 시작 (0) | 2017.08.31 |