1. 아키텍트 역할 정의

이러한 조직이 MSA로 가기 위하여 가장 고민해야 할 부분은 아키텍트들이다. 개발자들은 대부분 개발을 하고 공통 프레임 워크를 사용하고, 강력한 표준 준수를 규정으로 정의하여 자율성을 최대한 적게 가져갔던 Monolithic 아키텍처 대비 개발자가 거의 모든 일을 알아서 해야 하는 그리고 자 율도가 많은 MSA 특성에 맞는 시스템을 구현하기 위하여 아키텍트의 역할은 많은 변화가 필요하다.
"Building microservices Sam Newman" 책에서는 아키텍트의 역할을 "진화적 아키텍트"라는 용어를 사용하여 정의하였다.
진화적인 아키텍트는 [원칙과 실천]으로 분리하여 아키텍트 역할을 정의해야 한다고 했다.

  • 원칙 : 변하지 않는 것으로 한 프로젝트 혹은 한 회사의 아키텍처 원칙을 정의한다. 예를 들면 우리의 아키텍처는 "외부 의존성은 낮추고, 복잡성은 제거 해야 하며, 인터페이스와 데이터의 흐름은 일관성을 유지한다" 라는 원칙을 세웠다고 하 자.
  • 실천 : 위의 원칙을 지키고자 하는 여러 아키텍처를 활용하는 것이다. 예를 들면 "표준 인터페이스는 Rest API, 통합 DB 는 사용하지 않으나 업무 종류별 회사 표준의 DB를 활용 한다" 등등. 각 시스템에 맞는 그러나 표준은 준수하는 실천을 해 야 하는 것이다.

아키텍트는 이렇게 원칙을 정의하고 실천은 알아서 하되, 이를 원칙에 맞게 조율하고 준수하게 하는 통합 아키텍트와 각 서비스에서 아키텍처를 구현하는 서비스 영역내 아키텍트로 구분하여 역할을 만들어야 한다.
[출처]MSA 어플리케이션 구축 시 조직 구성은 어떻게 해야 할까요?|작성자리니

원칙을 정하고 원칙에 의해 아키텍처를 적용하면 진행방향이 흔들리지 않을 것입니다.

2. TDD

  1. 프로그램을 개발하기 전에 먼저 테스트 코드를 작성하는 것...이라고 하지만 개인적인 생각은 꼭 "먼저"일 필요는 없다이다. 이것이 test code가 필요없다는 것이 아니라 프로그래밍 시작이건 중간이건 끝나고던 배포전에만 testcode가 작성되어 있다면 된다는 것이다. 그러 나 먼저 하는 것을 추천한다. 항상 할 일을 미루면 프로그램 중에도 찝찝하고 한 번 미룬건 계속 미루기 쉽상이기 때문이다.
  2. TDD를 통해서 얻고자 하는 최종 목적은 잘 동작하는 깔끔한 코드(clean code)이다. 이는 유지보수의 편의성, 가독성, 안정성등의 여러가 지 의미를 내포한다.
  3. TDD 진행
    1. 과정 질문(Ask) : 테스트 작성을 통해 시스템에 질문한다.(테스트에 실패할만한 질문을 해야한다.)
    2. 응답(Response) : 테스트를 통과하는 코드를 작성해서 질문에 대답한다. (테스트에 통과할 최소의 코드만을 작성해야 한다.)
    3. 정제(Refine) : 아이디어를 통합하고, 불필요한 코드를 제거하고 모호한것을 명확히한다.
    4. 반복(Repeat) : 다음 질문을 통해 계속해서 진행해 나간다.

3. CI/CD Automation

  1. CI (Continuous Integration)
    1. 개발자가 자신의 코드를 중앙 코드와 통합하면 자동으로 빌드되고 report가 생성된다.
    2. 이때 위의 TDD에서 작성한 test code의 coverage에 따라 영향을 받는다.
  2. CD (Continuous Delivery)
    1. 사실상 CI의 연장선, CD를 하려면 CI가 선행되어야 한다고 봐도 무방하다.
    2. 현재 우리 회사는 Jenkins가 사용되고 있으므로 검토대상 1호이다.

4. Container Management

  1. Kubernetes같은 orchestration tool이 하는 일이다.
  2. 하지만 현실적으로 cloud의 기능을 사용해야 할 듯 하다.
  3. resiliency 복원력 정도로 해석할 수 있다. 다음 이야기 하는 service mesh와 함께 문제가 되는 container를 다시 동작하도록 하는 기능이 있다.

5. Service Mesh

  1. 밑에 그림 처럼 outer gateway가 아닌 inner gateway에서 적용되어야 할 부분이다.
  2. AWS App Mesh
    1. https://docs.aws.amazon.com/ko_kr/app-mesh/latest/userguide/what-is-app-mesh.html
  3. Azure service Fabric Mesh
    1. https://docs.microsoft.com/ko-kr/azure/service-fabric-mesh/service-fabric-mesh-overview
  4. Spring Cloud Consul
    1. Consul은 full featured control plane을 제공하는 service mesh solution.
    2. service discovery, health checking, key-value store, secure service communication, multi datacenter
    3. https://www.consul.io/intro/index.html
      1. Consul vs. Other Software
        1. 다른 소프트웨어와의 비교를 consul입장에서 정리한 것 같다.
  5. Istio
    1. load balancing, service registry, API management등의 기능이 있는 차세대 service mesh
    2. 그럼 흔히 알고 있는 netflix OSS의 service mesh와는 뭐가 다르길래 차세대라고 하는건지?
      아래 그림을 참고하자.
      1. 비즈니스 로직에 service mesh 관련 코드가 있는지 없는지가 큰 차이다.
      2. 항상 코드에 섞여 있는 것은 (특히 인프라 부분) 좋은 상황은 아니다.
      3. 그래서 properties나 yaml이라도 사용하여 소스 코드와 분리하려고 하지 않는가.

6. Distributed Tracing

  1. AWS App Mesh
    1. https://docs.aws.amazon.com/ko_kr/xray/latest/devguide/xray-guide.pdf
  2. Azure Application Insight
    1. https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/app-insights-overview
  3. Spring Sleuth - zipkin을 이용
    1. trace, span ID를 이용하여 remote logging을 하고 micro service간의 log들을 추적할 수 있다.
    2. 위의 두 서비스에 비해 분명 개발 및 운영도 해야 되어서 손이 많이 가지만 가격적인 측면도 무시 못한다.
    3. 이러한 tracing서버는 한 번 구축 하면 다른 서비스도 적용 가능해서 어느 정도 서비스가 많아 지면 손익 변곡점을 넘기게 마련이다. 중장기적인 플랜을 기준으로 판단이 필요하다.

그냥 간단하게 생각 나는 것들을 정리해 보았습니다. log에 대한 visualize라든가 ELK를 이용하는 것들이 더 생각 하는데 조금씩 살을 덧붙여 처음 시작할 때는 고려사항 목록으로, 진행하면서는 check list로 활용하도록 해볼 생각 입니다.

https://prev.rust-lang.org/ko-KR/faq.html

 

자주 묻는 질문들 · Rust 프로그래밍 언어

자주 묻는 질문들 이 문서는 Rust 프로그래밍 언어에 대한 흔한 질문들을 답하기 위해 존재합니다. 이 문서는 언어에 대한 완전한 안내서도 아니고, 언어를 가르치는 도구도 아닙니다. 이 문서는 Rust 커뮤니티에서 사람들이 되풀이하여 맞닥뜨리는 질문들을 답하고, Rust의 일부 설계가 왜 그렇게 결정되었는지를 밝히기 위한 참조서입니다. 여기에서 답하지 않았지만 흔하거나 중요한 질문이 누락되어 있다고 생각하신다면 저희가 고칠 수 있도록 부담 없이 도와주세요

prev.rust-lang.org

이렇게 정리된 language가 있었던가???

'Programming > Rust' 카테고리의 다른 글

RUST 자주 묻는 질문들 (FAQ)  (0) 2020.01.14

작년 12월에 했던 생각들과 올해 1월에 했던 생각들이 왜 이렇게 다를까? 아직 1월의 1/3도 안 지났는데 문득 그런 생각이 들었다. 내 주위에 환경이 달라지니 분위기도 달라지고 생각의 흐름도 바뀌었다. 다행히 내 생각의 흐름은 아직 8일밖에 안 지났지만 좋은 쪽으로 흐르는 듯하다.

개인적으로는 지난 12월을 돌이켜 보면 그다지 좋았던 것은 아니었다. 노력한 것에 비해 결과가 좋지 않았던 것도 있고 별거 아닌 말 한마디에 상처받고 마음이 지하로 가라앉은 것 같은 느낌도 받았던 시간이었다. 그런데 해가 바뀌었다고 새로운 마음가짐과 함께 훌훌 털어버린 것은 어쩌면 단순히 해가 바뀌어 그런게 아닐까 싶다. 사실 12월과 1월... 정말 별거 아닌 것이 시간은 언제나 똑같이 흐르기 때문이다. 단지 내 생각이 바뀐 것 뿐인데...

시간의 흐름은 내 마음이 쪼갤 수 있구나....라고 새삼스레 생각해 본다. 안 좋았던 시간은 끊어 내고 지금 좋은 시간이 흘렀으면 한다.

1월에는 Rust를 공부해 보려고 한다. 이건 단지 IoT에 써먹을 수 있을까 하는 생각도 있고 내 호기심이 여기에 꽂혔다. 스터디를 사내에서 진행해 보고 좀 더 실용적인 방안으로 발전시켜보고 싶다.

'Doodle' 카테고리의 다른 글

연말과 연초  (0) 2020.01.09
벌써 9년차가 되었다...  (0) 2019.12.23

+ Recent posts