architecture

넷플릭스의 클라우드 엔지니어링

정리 Netflix의 도구들 Eureka : Service Discovery Hystrix : Circuit breaker Ribbon : Client side load balancing Archaius : Library for configuration management API runtime에 설정 변경 지원 Prana : Sidecar Raigad : ElasticSearch 관리도 Chaos Engineering The Netflix Simian Army key-value 저장소 EVCache : Memcached 기반의 분산 메모리캐쉬 Moneta : A unified interface for key/value stores 모니터링 Atlas : Time series 데이터 관리 Servo : Application Monitoring Library Spectator : About Client library for collecting metrics Vizceral : 트래픽 흐름 시각화 도구 Turbine : Server Side Event Stream Aggregator Titus : 컨테이너 플랫폼 https://netflix.

Get Your Hands Dirty on Clean Architecture

감상 2022.09.05 책도 얇은 편이지만 재미가 있어서 중간에 끊지를 못하고 끝까지 읽었던 기억이 있습니다. 웹 어플케이션의 구조를 어떻게 잡을지는 프로젝트마다 매번하는 고민인데, 이 고민에 생각할 거리를 더 던져주는 점에서 유익했습니다. 엉클밥 아저씨의 ‘클린 아키텍처'가 코드가 없어서 아쉬웠던 점을 이 책에서 많이 채워주는 면도 있습니다. 이 책에서 권장하는 구조가 꼭 정답은 아닐 수도 있습니다. 이 책에서 제시한 ‘계층형 아키텍처'의 문제점이 계층형을 쓰면서 극복이 불가능한 문제는 아닐수도 있다는 생각도 듭니다. 책에서 제시한 persistent layer와 serice layer의 의존관계 역전을 실무 사례를 아직까지 못 본적은 없습니다.

Microservices Patterns

Audible에서 Audio Book으로도 들을 수 있다. https://www.audible.com/pd/Microservices-Patterns-Audiobook/B07ZFZ464G 참고 링크 https://microservices.io/patterns/microservices.html https://eventuate.io/ 인상 깊은 단락 (번역판 페이지 기준) p92 DDD와 마이크로서비스 아키텍처는 거의 찰떡궁합입니다. DDD의 하위 도메인, 경게 컨텍스트 개념은 마이크로서비스 아키텍처의 서비스와 잘 맞고, 마이크로서비스 아키텍처의 서비스 자율팀 개념은 도메인 모델을 개별 팀이 소유/개발한다는 DDD 사고방식과 어울립니다. 자체 도메인 모델을 가진 하위 도메인이라는 개념 덕분에 만능 클래스를 제거하고 서비스로 분해하기가 더 수월해집니다. p109 ‘하위 호환되는 소규모 변경'에 ‘속성을 응답을 추가'로 해당.

스프링 5.0 마이크로서비스

인상 깊은 단락 2ed p76 scale cube 참고 http://theartofscalability.com/ https://microservices.io/articles/scalecube.html 요약 x축 : 애플리케이션을 복제해서 수평적으로 확장 y축 : 서로 다른 기능들을 분리 Z축 : 데이터 파티셔닝 또는 샤딩 p188 https://github.com/Nilhcem/FakeSMTP 를 이용한 테스트 환경 구성 https://github.com/benelog/devnote/blob/master/smtp.adoc 에 관련 도구들을 정리했다. p218 공유 데이터 모델, 공유 스키마, 공유 테이블은 좋지 못한 방법이며, 마이크로서비스 개발을 재앙으로 이끌 수도 있다. 처음에는 좋은 수도 있지만, 복잡한 마이크로서비스를 개발하다 보면 데이터 모델 사이에 계속 관계를 추가하고, 조인 쿼리를 만들어내게 된다.

아마존 웹 서비스 클라우드 디자인 패턴 설계 가이드

인상 깊은 단락 129 s3fs : S3의 버킷을 EC2의 디스크로 마운트

클라우드 컴퓨팅 어플리케이션 아키텍처

감상 2010년 출판된 책이라서 2012년 현 시점에는 다소 맞지 않는 내용이 있다. 예를 들면 Google App Engine이 Python만 지원한다고 써 있는 내용. 관심가는 솔류션 http://www.valtira.com/ http://www.opentext.com/ : CMS 솔류션 http://mesh.com : 각종 디바이스 동기화, 원격 제어 클라우드 관리 솔류션 : http://enstratus.com/, http://www.rightscale.com/ 인상 깊은 내용 p20 마이크로소프트, Xen, VMWare 같은 엔터프라이즈 가상화 기술은 CPU제조업체가 지원하는 하드웨어 지원 가상화 기술을 제공하고, 실제 물리적 서버와 거의 유사한 수준까지 성능을 낸다.

소프트웨어 아키텍트가 알아야할 97가지 이야기

인상 깊은 단락 6쪽 기교로써 단지 대화에 익숙해지는 것만으로는 충분하지 않습니다. 존경심을 가지고 사람을 대하는 것을 배우고, 사람에 대한 성급한 판단을 버리는 것을 배우는 것이 영리한 아키텍트가 유능한 아키텍트로 변하는 핵심 기술 중 하나입니다. 38쪽 좋은 아키텍트는 사례르 통해 팀을 이끌어야 합니다. 아키텍트는 네트워크를 설치하고 빌드 프로세스를 설정하는 것에서부터 단위 테스트를 작성하고 벤치마킹을 수행하는 것까지 자신의 팀 내 어떠한 역할도 수행할수 있어야 합니다. … 훌륭한 아키텍트는 문제를 찾아내어 팀을 소집하고, 희생자를 지적해내지 않고, 무엇이 문제인지 설명하고, 정교한 대안이나 해결책을 제시할 수 있어야 합니다.

Software Architecture In Practice 2nd Edition

감상 몇년전에 이 책을 봤을 때에는 ‘상식적인 내용을 체계적으로 잘 정리했군’ 정도로 큰 감흥이 없었다. 그런데 상식이라고 생각한 것을 결론으로 내든 근거로 쓰든 간에, 여러 상식을 묶어서 다른 이를 설득하려면 체계성이 가장 중요하다는 것을 이제서야 조금 깨닳은 듯 하다.

엔터프라이즈 SOA

감상 SOA는 구체적인 기술이 아니라, 구조를 의미한다. SOA를 하기 위해서 꼭 특정기술을 써야한다는 주장만이 들리고 있고, 다른 선택을 말할 수 없는 상황이라면, 시스템의 이해관계자 중 솔류션 벤더사나 특정 개발 조직의 이익만이 정치적으로 관철되어 있는 상황이 아닐까? 인상깊은 부분 20쪽 SOA는 엔터프라이즈 기술 표준이 아니다. 이는 SOA가 IIOP나 SOAP 같은 특정 단일 기술 프로토콜에 의존적이지 않다는 것을 의미한다. 대신 SOA는 아키텍처 청사진을 뜻하여, 이는 많은 상이한 기술들을 통합할 수 있고, 특정 프로토콜이나 연계기술을 요구하지 않는다는 것을 의미한다.

Expert One-on-One J2EE Design and Development

감상 시간이 지나서 다소 빛이 바랜 내용도 있지만, 이 책이 2002년도에, 그것도 당시 32살정도였던 사람이 썼다니 감탄이 나올 뿐이다. 인상 깊은 단락 p120 Strictly seaping, this is a special case of the Strategy design pattern: it appears different because the interfaces involved are so simple. )