SaaS SA가 하는 일 (2)
내가 내리는 기술적 결정들
앞선 글에서 내가 실제로 하는 프로젝트들에 대해 설명했다. 이 프로젝트에 들어갈 때 기술적으로 고려해야 하는 것에는 어떤 게 있을까?
1. Solutions Architect 의 덕목 - 아니 너 그래서 하는 일이 뭔데? 에 대한 긴 답변
3. SaaS SA가 하는 일 (1) - 아니 너 그래서 하는 일이 뭔데?에 대한 더더더 구체적인 답변
4. SaaS SA가 하는 일 (2) - 내가 내리는 기술적 결정들
보안
시스템과 시스템 통합의 가장 중요한 점은 첫째도 보안, 둘째도 보안, 셋째도 보안이다. 자칫 잘못하면 양쪽 모두 큰 문제에 빠질 수 있기 때문이다. 상당히 중요한 고객의 데이터를 주고 받게 되는 것이므로, 상대방의 데이터를 충분히 안전하게 저장하고 관리하고 있음을 서로에게 증명할 수 있어야 한다.
인증 방식
그 중 가장 첫번째로 만나는 것이 인증 방식이다. 말하자면 한 사용자가 “나 너네 둘 서비스 연결할래!”라고 온다면 가장 먼저 발생하는 것이 해당 유저를 양방에서 인증하는 것이기 때문이다. 지금까지 경험한 인증 방식과 각각을 설계할 때 주의해야 하는 점은 이렇다.
OAuth 2.0: 업계에서 가장 표준이라고 말할 수 있는 인증 방식이다. 서로 정해진 시간 동안만 유효한 토큰을 정기적으로 갱신하기 때문에 서버 차원에서는 귀찮지만 가장 안전한 방법 중 하나라고 할 수 있다. OAuth 2.0 자체에는 문제가 없지만 주의해야 할 점은 우리가 이 토큰을 저장해야 할 수도 있다는 점이다. 1:1으로 즉시 연결을 맺는 경우는 크게 문제가 없겠지만, 만약 서로의 시스템에 직접 접근하지 못하는 제3의 지대에 시스템을 마련해야 하는 경우가 그렇다. 대표적으로 다른 수행사를 고용하여 개발시키고 운영을 맡기는 경우가 이 경우에 포함된다. 이때 토큰들이 저장되는 데이터베이스에 대한 보안을 대단히 철저히 유지해야 한다.
API Key 기반: 이상적이지는 않지만 API Key를 기반으로 데이터 연결을 해야 하는 경우도 발생한다. 양측 중 한 곳이 OAuth 2.0 을 위한 서버 준비가 안됐을 때 보통 API Key를 가지고 인증을 한다. 유저가 본인의 로그인 정보 외에 API Key를 획득해서 직접 전달해줘야 한다는 점에서 사용자 경험이 안 좋은 면도 있지만, 무엇보다 이 API Key는 갱신이 되지 않아서 노출되는 순간 바로 악용이 가능해 훨씬 취약하다는 치명적인 단점이 있다. 그래서 이 API Key를 다룰 때에는 되도록 DB에 저장해야 되는 일이 생길 때에도 직접 암호화를 먼저 해서 저장하기를 권한다.
AWS 계정 간 연결: 흔치는 않지만 외부 인터페이스가 없을 때 이렇게 각자의 클라우드 환경을 직접 연결해야 되는 때도 온다. IAM Role 을 통해서 cross account 정책을 주는 식이다. 이때는 반드시 정해진 액션만 할 수 있게 정책 관리를 철저히 해야 한다는 점을 반드시 염두에 두어야 한다. 잘못 설정했다가는 시스템에 직접 침입할 수 있는 길을 열어주는 꼴이니 관리적인 부담도 꽤나 있는 편이다. 그렇지만 AWS 클라우드 안에서 소통을 하게 되면 외부 인터넷을 통하지 않게도 할 수 있는 길이 있기 때문에 확실한 이점도 있다.
데이터 전달 방식
실제 가장 중요한, 어쩌면 보안 내용을 정리하는 것보다도 먼저 정의하게 될 비즈니스 데이터 전달 방식은 어떤 방식이 있고 어떤 것들을 고려해야 할까.
일단 어느 방식을 선택하든지 간에 공통적으로 반드시 사전에 확인해야 하는 것들이 몇 가지 있다. 1/ 받아들일 수 있는 페이로드의 최대 사이즈 2/ 응답 최대 대기 시간 3/ API Rate limit 4/ 서로가 갖고 있는 데이터 스키마. 필수인 값과 필수가 아닌 값은 무엇이 있는지 확인. 서로의 시스템에 대해 이런 얘기들을 주고 받다보면 자연스럽게 대화가 우리가 데이터를 어떻게 주고 받는 것이 좋을지 의논하게 된다. 그리고 이 과정에서 위에 정의된 프로젝트 요구사항을 다시 살펴보게 된다. 데이터 전달에는 다음과 같은 두 가지 방식이 있기 때문이다.
첫번째는 이벤트 기반이다. 어느 쪽에서 실제 데이터가 생성이 됐을 때 바로 상대방 시스템에 알림을 보내는 것이다. 이 방식은 모든 데이터 처리를 준 실시간으로 처리할 수 있다는 점에서 비즈니스 쪽 사람들이 좋아하는 방식이다. 그렇지만 기술자 관점에서는 이벤트 기반 아키텍처로 갈 때 고려해야 하는 것들이 많다. 1/ 이벤트가 갑자기 한 번에 몰려왔을 때 얼마나 감당 가능할 수 있어야 하는지? (1000개의 이벤트가 ms 안에 한꺼번에 발생할 수 있는지?) 2/ 한 이벤트 안에 담겨 있는 데이터를 처리하기 위해 어떤 내외부 시스템과 소통해야 하는지? 일종의 데이터 전처리가 필요한지? 3/ 이벤트가 최종적으로 상대방에게 전달될 때 악의적인 사용자에 의해 조작된 게 아닌 것을 어떻게 확인할지 등등이다. 1번 고려사항을 대처하기 위해서는 아키텍처 적으로 많은 컴포넌트들이 들어오게 되고 이를 운영하기란 꽤나 비용이 드는 일이므로, “우리 이거 정말 실시간이어야 해?”라는 질문을 비즈니스 팀과 다시 한 번 확인할 필요가 있다. 2번과 3번은 서로 갖고 있는 API limit 과도 긴밀하게 영향이 있다. 요새는 Thin event 라고 해서 이벤트 페이로드 안에는 ID만 담고, 상세 내용은 한 번 더 API 요청을 보내 확인하게 하는 방식을 많이 사용한다. 이벤트 전달 과정에서 데이터 유출을 최소화하기 위함이다. 그런데 이러다보면 경우에 따라 하나의 요청을 처리하기 위해 여러번의 API 요청을 발생시키게 되는데, 이게 리밋에 걸리게 되면 초당 처리할 수 있는 최대 이벤트의 개수가 줄어든다. 또 데이터 정합성이 중요한 경우, 받은 데이터가 빠짐 없이 잘 처리가 되었는지 확인하기 위해 전체 List API 콜을 해서 확인해야 하기도 한다. 또 하나 문제가 되는 점은 Dead letter 처리 방식이다. 모종의 이유로 이벤트 전달이 되지 않았거나 중간에 전처리 과정에서 문제가 생겼을 경우, 해당 데이터에 어떻게 대처할 것이냐 하는 것이다. Dead letter queue는 어디에 둘 것인지, 얼마 간의 주기로 재시도 할 것인지, 어느 순간이 되었을 때 사용자에게 의사결정을 하라고 넘겨줄 것인지 이런 것들을 잘 설계해야 한다. 이런 부분들을 종합적으로 고려해서 이벤트 동기화가 실제로 필요한지, 그렇다면 얼마 만큼의 케파를 원하는지 등을 정의해나가야 한다.
두번째는 배치 기반이다. 정기적으로 데이터가 필요한 쪽에서 상대방에게 “너 내가 마지막으로 데이터 가져온 시점 이후에 더 추가되거나 수정된 데이터가 있니?”라고 물어보는 것이다. 폴링 방식이라고도 한다. 이는 이벤트 기반과 달리 순간적인 피크에 대응해야 할 부담이 상대적으로 줄어들고, 한번에 가져올 데이터 양을 유도리 있게 조정 가능하다는 점에서 서로의 시스템에 부하를 감당 가능한 선으로 줄여준다. 나는 개인적으로 이 방식을 더 선호하는데 합리적인 주기로 배치(15분?)를 실행한다면 인프라 비용도 아끼고 운영 부담도 줄일 수 있기 때문이다. 어차피 위에 말한 것처럼 이벤트로 가더라도 데이터 정합성 체크를 해야 하는 경우가 많아서 거기에서도 배치 코드를 짜야 하기 때문이다. 그리고 사실상 실시간을 원한다고 말하는 사람들도 얼마나 실시간성을 원하는지, 정말로 실시간이어야만 하는 이유가 뭔지는 설명하지 못하는 경우가 대부분이다. 이벤트 기반과 배치 기반의 아키텍처를 일단은 둘 다 고려하고 배치로 가면 얼마나 비용이 절감되는지 등을 근거로 대화를 이끌어나갈 수 있어야 한다.
로그와 메트릭
로그와 메트릭은 필연적으로 비즈니스적 KPI 와 긴밀한 연관을 갖게 된다. 양방이 서로 프로젝트에 착수하기로 마음 먹을 때에는 그 성패를 결정짓는 KPI 가 무엇이며 어느 정도의 목표를 갖는지 합의한다. 많은 것들이 있겠지만 서로의 채널을 통해 새로 유입된 유저 수, 서로의 채널을 활성화한 후 실제 발생한 고객 비즈니스 지표(conversion rate 등)가 있을 수 있다. 이런 비즈니스 지표를 산출하기 위해서는 많은 시스템 지표들을 필요로 하게 된다. 이 기반 지표를 만들기 위해 다음은 필수로 측정하려고 한다. 1/ # of new launch request 2/ # of successful new launch request 3/ # of delivered events (# of created records) 4/ # of failed events
여기에 더해 향후 고객 문제가 발생했을 때 트러블슈팅을 하기 위해서 1/ 고객의 최초 런칭 정보와 타임스탬프 2/ 전달된 이벤트가 상대방에서 Accept 되었는지 ACK flag (데이터 정합성에 꼭 필요한 경우) 와 모든 액티비티의 로그가 꼭 필요하다
