혁신적인 아키텍처 시리즈, 3부

‘To the moon 🚀’

‘Evolutionary Architectures’는 4부로 구성된 블로그 시리즈로, Startup 수명 주기의 여러 단계를 거치면서 기업의 솔루션 설계 및 의사 결정 방식이 어떻게 변화하는지 보여줍니다. 이 시리즈에서는 Fantasy Sports League와 유사한 ‘판타지 주식 시장’ 애플리케이션을 만들겠다는 아이디어를 가진 Example Startup이라는 회사의 여정을 따라가 봅니다. 이 회사는 일 년 동안 네 차례 ‘토너먼트’를 개최하는 방안을 구상하고 있습니다.

두 번째 블로그에서는 창업자들이 자금 조달을 준비하는 동안 이 Startup이 어떻게 기술 솔루션을 발전시키기 시작하는지를 설명했습니다. 3부에서는 Example Startup이 어떻게 더 발전하여 기술 스택의 완성도를 높이고 확장성을 확보하는지 살펴보겠습니다.

마이크로서비스 아키텍처로 전환하여 효율적으로 확장

판타지 주식 거래 팀이 성장하고 있으며, 새로운 구성 요소와 솔루션이 구축되고 있습니다. 기술 포트폴리오가 확장됨에 따라 팀이 해결해야 할 몇 가지 문제들이 나타나기 시작합니다.

“오래된 습관은 쉽게 사라지지 않습니다.” 그리고 팀은 그런 습관이 어떻게 Startup의 성장을 저해하는지 깨닫기 시작합니다. 공격적인 일정과 더 적은 리소스로 더 큰 성과를 내고자 하는 열정이 기술적 부채를 증가시키고 있습니다. 이러한 기술적 부채의 한 단면으로서, 팀이 처음에 결정했던 마이크로서비스 아키텍처와 대비되는 모놀리스 방식이 점진적으로 확산되고 있습니다. 확장성 및 성능 병목 현상과 같은 모놀리스의 문제점들이 테스트를 실시하고 새로운 기능을 도입하는 과정에서 나타나기 시작합니다. 다행히 팀은 이러한 모놀리스 접근 방식이 워크로드를 최적으로 확장하는 데 있어 유발하는 문제를 빠르게 인식합니다. 팀은 한 걸음 물러나 개발 방식을 재평가하기로 결정합니다. 개발자 중 한 명은 이전에 나눈 대화에서 AWS Solutions Architect(SA)가 이러한 문제 중 일부를 예상했던 것을 기억하고 있습니다. Example Startup 팀은 도움을 받기 위해 AWS와 통화 일정을 잡습니다.

모놀리스 방식을 해체하고 마이크로서비스 기반 패러다임으로 전환하는 것은 매우 포괄적인 주제이므로, AWS SA는 Example Startup의 팀을 App Modernization Immersion Day를 개최할 것을 제안합니다. Immersion Day는 관련 워크숍을 바탕으로 Startup과 관련된 워크로드에 중점을 두고 진행됩니다. 회사의 거의 모든 개발자가 이벤트에 참여했고, 이 이벤트는 결국 게임체인저가 되었습니다. 하루 동안 팀은 마이크로서비스를 올바르게 정의, 설계 및 구현하는 방법을 배울 수 있습니다. 또한 모든 것을 한 번에 다시 실행할 필요 없이, 모놀리스 애플리케이션에서 마이크로서비스 세트로 점진적으로 마이그레이션할 계획을 수립하는 방법도 배웁니다. 팀은 실수를 조기에 발견하고 다음 단계를 진행하는 데 도움이 될 만한 몇 가지 모범 사례를 알게 된 데 매우 만족합니다. Solutions Architect는 Example Startup 팀의 지식 격차를 해소할 수 있는, 현대화 전략을 중점적으로 다룬 AWS 백서도 공유합니다.

앱 현대화 경험이 Example Startup에 매우 큰 가치를 제공했기에, 팀은 앞으로 기존 모범 사례를 활용하는 동일한 접근 방식을 다양한 업무 영역에 적용하기로 결정했습니다. 엔지니어와 제품 관리자는 중복 작업을 피하기 위해 올해 남은 기간 동안의 로드맵을 AWS와 공유하는 통화 일정을 잡습니다. Example Startup은 이미 AWS와 상호 기밀 유지 협약(MNDA)을 체결했고, 이 대화에서 양측 모두 생산적인 아이디어를 자유롭게 교환할 수 있었습니다. 다른 좋은 소식도 있었습니다. Example Startup이 자체적으로 구축하는 방안을 고려했던 기능이 이미 AWS의 다음 분기 로드맵에 포함되어 있어 팀의 엔지니어링 시간을 크게 절약할 수 있다는 것입니다.

Example Startup의 개선 사항 목록에서 다음 주제는 코드형 인프라(IaC), 지속적 통합 및 지속적 전달(CI/CD), 자동 테스트와 관련이 있습니다. 새로 고용된 두 명의 개발 운영(DevOps) 담당자는 이 Startup의 여러 현재 운영 방식, 특히 구축 및 테스트 환경, 코드 아티팩트 관리 방식 등에 만족하지 못하고 있습니다. Example Startup의 팀이 성장함에 따라 더 많은 사람들이 이러한 민감한 프로세스에 액세스할 수 있게 되어 불필요한 리스크가 발생합니다. 두 명의 신입 팀원은 이미 IaC를 위한 도구로 Terraform을 사용한 경험이 있습니다. 두 사람은 Terraform에서 AWS가 잘 지원된다는 사실을 알게 되고, 대안이 필요할 경우를 대비하여 AWS CloudFormation 및 AWS CDK와 같은 다른 도구를 발견하게 된 데 만족합니다. 하지만 여전히 CI/CD를 설정하는 데 도움이 필요합니다. 지금까지의 시도는 일관성이 부족했고 빌드 도구가 배포 도구와 잘 연동되도록 만들기가 어렵다는 사실을 알게 되었습니다. 또한 컨테이너 이미지를 관리하기 위한 적절한 접근 방식을 여전히 찾는 중입니다. AWS 팀은 AWS CodePipeline이 빌드와 배포 도구를 원활하게 통합하기 위한 요구 사항을 충족하고 다양한 환경에 대한 지원 기능과 함께 자동화된 테스트 기능도 포함하고 있는 만큼 AWS CodePipeline을 고려해볼 것을 제안합니다. CodePipeline을 사용하면 AWS CodeBuild, AWS CodeDeploy 및 서드 파티 도구와 같은 다른 도구에 대한 강력한 지원 기능을 이용할 수 있을 뿐만 아니라, AWS에 기본적으로 빌드되지 않을 수도 있는 솔루션과도 통합이 가능합니다. CodePipeline을 구현하면 Example Startup에서 목록의 또 다른 중대한 과제 하나를 해결할 수 있습니다.

마이크로서비스의 올바른 구현이라는 목표를 향해 순조롭게 나아가다 보니, 아직 해결되지 않은 다른 복잡한 문제도 해결할 수 있다는 자신ㄱ감을 얻게 되었습니다. 우선, 독립적으로 운영되는 여러 서비스의 존재로 인해, 자연스럽게 이러한 서비스 간의 커뮤니케이션 문제가 발생합니다. 커뮤니케이션에서 모든 서비스 간 호출을 동기식으로 구현할지 비동기식으로 구현할지, 그리고 팀에서 게시/구독(PubSub) 메시징과 같은 모범 사례 패턴을 어떻게 도입해야 할지와 관련해서도 큰 의문이 남습니다. 팀은 모놀리식 구조를 벗어나려는 상황에서는 특히, 이벤트 기반 아키텍처를 도입하는 것이 도움이 될 것이라는 점을 폭넓게 이해하고 있지만, Amazon EventBridge, Amazon Simple Queue Service(Amazon SQS), Amazon Simple Notification Service(SNS), Amazon Managed Streaming for Apache Kafka(Amazon MSK) 등(이에 국한되지 않음) 수많은 AWS 서비스 앞에서 다소 혼란을 느끼게 됩니다. 이번에는 팀이 해당 주제와 관련한 매우 유용한 워크숍 및 블로그와 같은 몇 가지 리소스를 직접 찾을 수 있었습니다. ‘이벤트 기반’ 패러다임은 서서히 이 팀이 활용할 또 다른 도구로 자리잡고 있습니다.

보다 강화된 보안 전략 개발

Startup의 최우선 과제는 보안이며, AWS Startup 보안 기준(AWS SSB)과 같은 도구를 활용하면 보안 개발을 시작하는 데 도움이 됩니다. 안타깝게도 보안을 너무 높은 수준으로 강화할 수는 없습니다. AWS WAF의 초기 구현은 좋은 출발점이었지만, 팀은 예방, 탐지 및 해결과 관련하여 좀더 사전 예방적인 방식을 고려하기 시작해야 합니다. 이들은 강력한 보안 전략을 구현하는 데 도움이 될 수 있는, 보안에 중점을 둔 다양한 AWS 서비스를 활용하기 위한 기술 역량을 습득하기 시작합니다.

팀의 성장과 파트너의 참여로 인해 액세스 제어, 권한, 거버넌스 등의 다른 주제에도 더욱 주의를 기울여야 할 상황이 되었습니다. 팀은 권한 적용 시 최소 권한 원칙과 같은 모범 사례를 구현하려고 노력하고 있습니다. 이들은 최소한 프로덕션 워크로드를 별도의 자체 계정으로 옮기려고 합니다. 팀이 이러한 모범 사례를 도입함에 따라, 이제 처리해야 할 관리 및 권한 계층이 추가되어 운영이 더욱 복잡해지고 있음을 알게 되었습니다. 계정 구조에 대한 기계화된 접근 방식이 필요하다는 것이 금세 명확해지고 있습니다. 누군가 AWS Organizations를 언급했는데, 이는 올바른 방향으로 한 걸음 나아가는 것이라고 판단되어 신뢰할 수 있는 AWS SA에 연락하여 대화를 나눕니다. SA는 여러 계정 및 AWS Organizations를 관리하기 위한 좀더 간편한 도구로서 AWS Control Tower를 제안하는 등, 몇 가지 관련 조언을 공유합니다. 이는 강력한 다중 계정 전략을 실현하기 위한 여러 단계 중 첫 번째 단계이므로, AWS SA는 ‘Transitioning to multiple AWS accounts’라는 규범적 가이드를 팀과 공유하기도 했습니다. 이 가이드에는 다중 계정 설정으로 전환할 경우의 계정 마이그레이션, 사용자 관리, 네트워킹, 보안 및 아키텍처와 관련한 모범 사례가 포함되어 있습니다.

성능 향상을 위한 워크로드 최적화

이 팀은 Startup이 적절한 속도로 성장할 수 있도록 몇 가지 기본적인 요소를 해결하고 있습니다. 목록의 몇 가지 중대한 항목이 해결되었고, 다른 항목의 경우 실행 계획이 마련되어 있습니다. 개발자들은 성능 향상을 위해 워크로드를 최적화하고자 애쓰고 있지만, Amazon CloudFront를 사용한 엣지 캐싱, Amazon ElastiCache를 사용한 애플리케이션 수준의 캐싱 및 데이터베이스 캐싱과 같이 코드의 범주를 넘어서는 추가 개선의 기회를 포착했습니다. 팀은 관련 운영 복잡성을 최소화하면서 필요한 기능을 제공하기 위해 AWS Managed Services에 갈수록 더 많이 의존하고 있습니다. 일부 개발자가 발견하고 뛰어난 사용 편의성에 놀란 또 다른 관리형 서비스로 AWS Batch가 있습니다. AWS Lambda를 사용한 초기 피드 처리 방식은 처리해야 하는 데이터의 양이 기하급수적으로 증가하면서 한계에 도달하기 시작했습니다. 몇 가지 실험을 거친 후 개발자들은 AWS Batch를 사용하는 방안을 계획할 수 있었습니다. 이를 통해 가중되는 운영 부담을 최소화하고 비용을 낮게 유지하면서 성장을 이어갈 수 있습니다.

Startup의 가치 제안 검증

Example Startup에서의 이 모든 뛰어난 성과는 단연 돋보입니다. 단기적인 해결 방법에 의존하지 않고 민첩하면서도 지속 가능한 방식으로 솔루션을 구축한다는 것은 회사가 장기적으로 생각하고, 높은 성숙도를 보이며, 성과를 달성할 역량을 갖추고 있음을 입증합니다. 이러한 특성은 혁신적인 솔루션 및 시장에 적합한 우수한 제품과 함께, 회사 가치 제안의 핵심 요소가 됩니다. 창업자들은 회사의 가치를 여러 벤처 캐피털 회사에 성공적으로 전달하고 첫 번째 시리즈 A 펀딩 라운드를 마감했습니다. Example Startup이 목표에 한걸음 더 다가가고 있습니다.

Evolutionary Architectures 시리즈의 첫 번째 블로그와 두 번째 블로그를 참조하세요.