아키텍트에게 누군가가 와서 말합니다. "우리는 이런 시스템을 구축하고 싶습니다.
로그인 시스템을 분리해서 공통 인증을 사용하는
여러 마이크로서비스를 구축하고 싶습니다. 어떻게
할 수 있을까요?" 당신의 임무는 그 방법을 고안하는 것입니다.
우선, 지금 무엇을 가지고 있나요?
조직과 소프트웨어 팀에서는 종종
두 가지 버전의 진실이 있습니다. 하나는 사람들이
고성능 트랜잭션 처리 시스템에 많은 돈을 지불했기 때문에 가지고 있다고 생각하는 것이고,
다른 하나는 실제로 가지고 있는 것입니다.
그것은 제대로 작동하지 않는 10만 줄의 Ruby 코드일 수 있죠.
이러한 차이를 이해해야 합니다. 제가 발견한 가장 좋은 방법은
서로 다른 시스템 간의 경계를 살펴보는 것입니다.
이 시스템들의 구성 요소 사이를 흐르는
트래픽을 이해하고 싶을 것입니다. 코드에 대해
너무 걱정하지 마세요, 사양에 대해서도 걱정하지 마세요. 그리고 사람들이 무언가가 어떻게 작동한다고 말할 때,
그것을 반신반의하세요. 유용하지만 100% 정확하지 않을 수 있습니다.
여기 제가 생각할 수 있는 가장 간단한 시스템
다이어그램이 있습니다. 아키텍트로서 당신은
그 웹사이트가 PHP인지 .NET인지 Perl인지 Ruby인지 상관하지 않습니다.
그리고 인터넷은 다른 사람의 문제입니다. 하지만 중간에 있는 이 HTTP는,
이에 대해 얼마나 많은 질문을 할 수 있을까요? 얼마나 많은 트랜잭션을 처리할 수 있나요?
HTTPS가 적용되어 있나요? 인증서는 언제 만료되나요?
GET, PUT, POST를 처리할 수 있나요? 프록시를 넣으면 어떻게 될까요?
이 중 얼마나 캐시할 수 있을까요? 트래픽에 ETag를 사용하고 있나요?
HTTP에 네트워크 추적을 설정하고 30분만 지켜봐도
이 웹사이트가 실제로 어떻게 작동하는지 더 많이 알 수 있습니다
코드를 읽고 '이 모듈이 흥미로워 보이네'라고 생각하며
몇 시간을 보내는 것보다 말이죠.
오, 이건 한 번도 실행되지 않았네요. 왜 여기 있는지 모르겠어요.
트래픽이 실제입니다. 트래픽은 살아있는 시스템의 생명줄입니다.
무언가가 어떻게 설계되었는지는 중요하지 않습니다. 아폴로 13의 진 크란츠처럼
그것이 무엇을 할 수 있는지가 중요합니다. 당신은 이해해야 합니다
시스템의 실제 능력을, 스펙에 있는 내용이 아니라.
때로는 실망스러울 수 있습니다. 고성능 인증 시스템이
분당 6명의 사용자밖에 처리하지 못한다든지.
때로는 즐거운 놀라움이 있을 겁니다. AWS를 파고들어 보면,
"우리가 몰랐던 Redis 클러스터가 여기 있네요. 이거 정말
훌륭해요. 이걸 이용해서 여러 가지를 가속화할 수 있겠어요. 우리
웹 서버 앞에 Varnish를 둘 수 있고, 순식간에 가속화됩니다. 그리고
뭔가를 다시 작성하기 시작할 수 있죠. 실망스러운 일도 있겠지만
즐