catpark's something new

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로 활용하도록 해볼 생각 입니다.