카카오페이 프론트엔드 개발팀의 Client Side Rendering 환경 고도화

#UX #DX

카카오페이의 프론트엔드 서비스가 제공되는 환경에 대해 이야기 하고, 프론트엔드 서비스가 제공되는 환경의 관점에서 개발자 경험과 사용자 경험을 개선하기 위한 카카오페이 프론트엔드 팀의 작업을 사례를 통해 이야기합니다.

발표자 : eric.dev
카카오페이 FE인프라TF TF장 에릭입니다. 카카오페이 FE 서비스의 근간을 이루는 다양한 환경에 대한 고민을 하고 있습니다.

Transcript

1. 박병현 Eric.dev 카카오페이 카카오페이 프론트엔드 개발팀의 Client Side Rendering 환경 고도화 if(kakao)2022 Copyright 2022. Kakao Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakao.
2. 들어가며 이슈#1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경 이슈#2) 프론트엔드 서비스 배포 · 롤백에 오랜 시간 소요 이슈#3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 이슈#4) 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재
3. 들어가며 2018년과 2022년의 프론트엔드 개발팀
4. 2명 2018년 2018년과 2022년의 프론트엔드 개발팀 40명+ 2022년
5. 서비스 개발 2018년 2018년과 2022년의 프론트엔드 개발팀 환경 고도화 2022년
6. FE인프라TF 공통서버 개선 빠른 롤백 빠른 배포 Server Side Rendering 도입 서비스 가시성 증진 레포 단위 A/B 테스트 도입 서비스 성능 지표 수집 운영성 업무 개선 효율적이고 안정적인 서비스 운영을 위한 전반적인 FE 환경 개선 Open Graph 운영성 업무 FE 서비스 RC 배포
7. FE인프라TF 효율적이고 안정적인 서비스 운영을 위한 전반적인 FE 환경 개선 공통서버 개선 빠른 롤백 빠른 배포 Server Side Rendering 도입 Open Graph 운영성 업무 FE 서비스 RC 배포 서비스 가시성 증진 레포 단위 A/B 테스트 도입 서비스 성능 지표 수집 운영성 업무 개선 Client Side Rendering 환경 개선과 관련된 이야기
8. 우리가 늘상 겪는 상황들 우리 프론트엔드 서비스를 제공하는 서버의 운영이 너무 어려워.. 운영이 용이한 환경으로 바꿔야 할 때가 온 것 같은데.. SNS에서 페이지 미리보기가 제대로 나와야 잠재 사용자를 끌어올 수 있는데, Client Side Rendering 환경에서는 이 작업이 너무 번거로워! 새로운 기능을 퍼블릭 오픈하기 전에 운영 환경에서 최종 확인하고 싶은데.. 빠르게 핫픽스를 나가야 하는데.. 배포하는데 시간이 너무 오래 걸리네..
9. 우리 프론트엔드 서비스를 제공하는 서버의 운영이 너무 어려워.. 운영이 용이한 환경으로 바꿔야 할 때가 온 것 같은데.. 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경
10. 아주 간단한 서버 (2018년) User index.html 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경 카카오페이 CSR* 공통 서버 Application * Client Side Rendering
11. User Storage 카카오페이 CSR* 공통 서버 Application * Client Side Rendering 공통 서버 (현재) 서비스 개수 50+ 인증 SEO 기타 공통 기능 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경
12. 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경 User Storage 카카오페이 CSR* 공통 서버 Application * Client Side Rendering 공통 서버 (현재) 서비스 개수 50+ 인증 SEO 기타 공통 기능 공통 기능 사용을 위해 FE 서비스가 공통 서버에 의존 유입 트래픽의 지속적인 증가 현 상황에 맞는 신규 환경 구성 필요
13. 신규 환경 구성 후보 Serverless Static Web Hosting Server Side Rendering
14. Serverless Server Side Rendering 신규 환경 구성 후보 Static Web Hosting "공통 기능" 제공 부분에 대한 고려 필요
15. Static Web Hosting 신규 환경 구성 후보 Serverless Serverless Server Side Rendering 전체 서비스에 대한 마이그레이션 작업 필요
16. Serverless Static Web Hosting Server Side Rendering 신규 환경 구성 후보 큰 틀에서 기존과 동일한 환경구성 서비스 개발자들에게 과도한 마이그레이션 부담을 주지 말자 기존과 유사하지만 서버 관리 부담이 적은 환경을 구축하자
17. server server server 공통 서버(Lagecy)의 관리가 어려웠던 이유 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경
18. server server server 구매 설치 마이그레이션 유지보수 공통 서버(Lagecy)의 관리가 어려웠던 이유 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경
19. server server server 구매 설치 마이그레이션 유지보수 공통 서버(Lagecy)의 관리가 어려웠던 이유 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경
20. 카카오페이 FE Git Repository 구성 공통 서버 Git Repository 서비스 A Git Repository 서비스 B Git Repository 서비스 C Git Repository Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
21. 공통 서버 Git Repository 공통 서버 Application 서비스 A Git Repository 서비스 B Git Repository 서비스 C Git Repository Storage 배포 배포 배포 배포 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경
22. 서비스 공통 서버 1 Application Storage Application Storage 공통 서버 2 Application Storage 공통 서버 3 배포 배포 배포
23. Time line 배포 Ver A 기존 가동 서버
24. Time line 배포 Migration 서버 투입 시작 Ver A 기존 가동 서버 신규 투입 서버
25. Time line 배포 Migration 신규배포 Ver A Ver B 기존 가동 서버 신규 투입 서버 서버 투입 시작
26. Time line 배포 서버 투입 시작 Migration 신규배포 Ver A Ver B 서버 투입 완료 Migration Complete 기존 가동 서버 신규 투입 서버
27. Time line 배포 서버 투입 시작 신규배포 Ver A Ver B 서버 투입 완료 Migration Migration Complete 기존 가동 서버 신규 투입 서버 Ver B Ver A
28. User 신규 투입 서버 Application Storage Ver A Application Storage Ver B 기존 구동 서버
29. 신규 투입 서버 Application Storage Ver A Application Storage Ver B 기존 구동 서버 User 공통 서버가 물리 서버로 구성되어 있어 Scaling에 제약이 존재 서버 내부에 산출물이 보관되어 Scaling 시 산출물 버전이 달라질 가능성 존재 문제점
30. 신규 투입 서버 Application Storage Ver A Application Storage Ver B 기존 구동 서버 User 개선 방향 도출 물리 서버 기반의 공통 서버를 Container 기반 아키텍처로 변경 서버 내부에 보관되던 산출물을 별도 공간으로 분리
31. 신규 투입 서버 Application Storage Ver A Application Storage Ver B 기존 구동 서버 User 개선 방향 도출 물리 서버 기반의 공통 서버를 Container 기반 아키텍처로 변경 기존과 유사하지만 서버 관리 부담을 덜어낼 수 있는 환경 서버 내부에 보관되던 산출물을 별도 공간으로 분리
32. 신규 투입 서버 Application Storage Ver A Application Storage Ver B 기존 구동 서버 User 개선 방향 도출 서비스 개발자들에게 과도한 마이그레이션 부담을 주지 않는 방식 서버 내부에 보관되던 산출물을 별도 공간으로 분리 물리 서버 기반의 공통 서버를 Container 기반 아키텍처로 변경
33. Kubernetes (K8s) Kubernetes Logo from kubernetes is licensed under the Creative Commons Attribution 4.0 International. - 컨테이너화된 애플리케이션의 관리를 도와주는 오픈소스 시스템 - 점진적 롤아웃을 통한 안정적인 무중단 배포 가능 - 간편한 Scaling 지원 -> 물리 서버 환경에서 Container 기반의 K8s 환경으로 변경 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경
34. Kubernetes Logo from kubernetes is licensed under the Creative Commons Attribution 4.0 International. Kubernetes (K8s) - 컨테이너화된 애플리케이션의 관리를 도와주는 오픈소스 시스템 - 점진적 롤아웃을 통한 안정적인 무중단 배포 가능 - 간편한 Scaling 지원 -> 물리 서버 환경에서 Container 기반의 K8s 환경으로 변경 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경 카카오페이는 Kubernetes를 적극적으로 사용 중 카카오페이의 K8s 운영 노하우 활용 가능 개발 편의성 운영 안정성
35. 공통 서버 Application 배포 서비스 A 배포 서비스 B 배포 서비스 C 배포 공통 Server 외부 Storage -> 서버 내부에 보관되던 산출물의 별도 공간 분리 이슈1) 유연한 운영이 어려운 기존 프론트엔드 서비스 제공 환경
36. 공통 Server 1 Application 배포 배포 배포 공통 Server 2 Application 공통 Server 3 Application 외부 Storage 서비스 A 서비스 B 서비스 C 조회
37. 공통 Server 1 Application 배포 배포 배포 공통 Server 2 Application 공통 Server 3 Application 외부 Storage 서비스 A 서비스 B 서비스 C 조회 설정 변경 후 재배포만으로 마이그레이션 완료 서비스 개발자들에게 과도한 부담 없음
38. 사용자 서비스 개발자 물리 서버 Application HTML HTML HTML 물리 서버 Application HTML HTML HTML AS - IS 요청 요청 배포 배포
39. 사용자 Kubernetes Application Application Application Application 외부 Storage HTML HTML HTML 서비스 개발자 TO - BE 요청 배포
40. 우리 프론트엔드 서비스를 제공하는 서버의 운영이 너무 어려워.. 운영이 용이한 환경으로 바꿔야 할 때가 온 것 같은데.. Container 기반의 K8s 환경으로 이관하면서 서버 운영이 편해졌어! 힘들지 않게 신규 환경으로 넘어올 수 있었던 것도 참 좋은데?
41. 빠르게 핫픽스를 나가야 하는데.. 배포하는데 시간이 너무 오래 걸리네.. 이슈2) 프론트엔드 서비스 배포 · 롤백에 오랜 시간이 소요됨
42. 이슈2) 프론트엔드 서비스 배포 · 롤백에 오랜 시간이 소요됨 배포 프로세스 롤백 프로세스 Git Repository <master branch> Release Package Manager <npm ci> Build <npm run build> Git Repository <Commit Id> Release Package Manager <npm ci> Build <npm run build>
43. 이슈2.1) 프론트엔드 서비스 배포에 오랜 시간이 소요됨 배포 프로세스 Git Repository <master branch> Release Package Manager <npm ci> Build <npm run build> 1 min 1 min 5 min
44. Yarn Berry (Yarn 2) - Node.js 환경에서 사용 가능한 Package Manager - Node Module의 Plug'n'Play 지원 - 효율적인 의존성 관리 - 예측 가능한 의존성 사용 
 - 환경과 독립된 실행 환경 보장 Yarn Logo from yarnpkg/asset is licensed under the Creative Commons Attribution 4.0 International. -> Yarn Berry (Yarn 2) 도입 이슈2.1) 프론트엔드 서비스 배포에 오랜 시간이 소요됨
45. Yarn Plug'n'Play - Package(Node modules)를 node_modules 폴더가 아닌 .pnp.cjs 파일로 관리 
 - Package 파일은 프로젝트 내 Cache 폴더에 보관되고 Git으로 관리 
 - .pnp.cjs는 Cache 폴더의 패키지 파일을 참조 -> Yarn Berry (Yarn 2) 도입 이슈2.1) 프론트엔드 서비스 배포에 오랜 시간이 소요됨
46. -> Yarn Berry (Yarn 2) 도입 이슈2.1) 프론트엔드 서비스 배포에 오랜 시간이 소요됨 node_modules 제거 의존성 설치 Build Deploy AS - IS npm ci Build Deploy TO - BE
47. AS - IS -> Yarn Berry (Yarn 2) 도입 이슈2.1) 프론트엔드 서비스 배포에 오랜 시간이 소요됨 TO - BE 배포시간 (평균) 7~10분 배포시간 (평균) 1~2분
48. 이슈2.2) 프론트엔드 서비스 롤백에 오랜 시간이 소요됨 롤백 프로세스 Git Repository <Commit Id> Release Package Manager <npm ci> Build <npm run build> 1 min 1 min 5 min
49. 공통 Server Application 외부 Storage 서비스 A 구버전 구버전 조회 최신버전
50. 공통 Server Application 외부 Storage 서비스 A 구버전 구버전 최신버전 이전빌드 조회
51. symlink service_a. html version_a. html 조회
52. symlink service_a. html version_a. html 서비스 A 롤백 프로세스 개선 1. 해당 Commit Id의 빌드 산출물 존재 여부 확인
53. symlink service_a. html version_a. html 서비스 A 롤백 프로세스 개선 2. 해당 산출물로 symlink 교체
54. symlink service_a. html version_a. html version_c.
55. -> 산출물 조회 시 symlink 사용 이슈2.2) 프론트엔드 서비스 롤백에 오랜 시간이 소요됨 node_modules 제거 의존성 설치 Build Deploy AS - IS npm ci Build Deploy TO - BE
56. -> 산출물 조회 시 symlink 사용 이슈2.2) 프론트엔드 서비스 롤백에 오랜 시간이 소요됨 AS - IS TO - BE 롤백시간 (평균) 7~10분 롤백시간 (평균) 즉시
57. 이슈2.2) 프론트엔드 서비스 롤백에 오랜 시간이 소요됨 배포 소요시간 롤백 소요시간 변경 전 7~10분 변경 후 1~2분 변경 전 7~10분 변경 후 즉시 업무효율 향상 운영 안정성 증진
58. 빠르게 핫픽스를 나가야 하는데.. 배포하는데 시간이 너무 오래 걸리네.. 배포는 1분 만에, 롤백은 즉시 실행되니 맘 편히 배포할 수 있는걸?
59. 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 새로운 기능을 퍼블릭 오픈하기 전에 운영 환경에서 최종 확인하고 싶은데..
60. 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 Sandbox 개발 Beta 검증 운영 Production
61. 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 ≠ Sandbox 개발 Beta 검증 운영 Production
62. 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 3800만 이상 사용자에게 영향 Sandbox 개발 Beta 검증 운영 Production
63. 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 3800만 이상 사용자에게 영향 Sandbox 개발 Beta 검증 운영 Production 운영 환경에서 퍼블릭 오픈 전 최종 확인을 할 수 있다면?
64. Sandbox 개발 Beta 검증 운영 Release Candidate Production 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재
65. 일반 사용자 공통 서버 서비스 산출물 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 -> 사용자 계정 기반의 Release Candidate 배포 환경 구성
66. 일반 사용자 공통 서버 서비스 산출물 -> 사용자 계정 기반의 Release Candidate 배포 환경 구성 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 인증 값 인증 처리
67. 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 -> 사용자 계정 기반의 Release Candidate 배포 환경 구성 인증 값 인증 처리 일반 사용자 서비스 산출물 사용자 식별 가능 공통 서버
68. 일반 사용자 공통 서버 서비스 산출물 사내 사용자 Release Candidate 사내 사용자 여부 확인 구분된 산출물 제공 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 -> 사용자 계정 기반의 Release Candidate 배포 환경 구성
69. 이슈3) 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 -> 사용자 계정 기반의 Release Candidate 배포 환경 구성 일반 사용자 서비스 산출물 Release Candidate 사내 사용자 여부 확인 구분된 산출물 제공 사내 사용자 대상 "최종 실환경 검증" 사내 사용자 공통 서버
70. 새로운 기능을 퍼블릭 오픈하기 전에 운영 환경에서 최종 확인하고 싶은데.. Release Candidate 기능을 사용해서 퍼블릭 오픈 전 최종 확인이 가능해!
71. SNS에서 페이지 미리보기가 제대로 나와야 잠재 사용자를 끌어올 수 있는데, Client Side Rendering 환경에서는 이 작업이 너무 번거로워! 이슈4) 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재
72. 이슈4) 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재 Social Network 잠재 사용자 카카오페이 사용자 서비스 공유하기 공유링크 접속 서비스 유입
73. 적절한 URL 미리보기 제공이 중요 -> Open Graph를 통한 페이지 정보 정의 필요
74. 이슈4) 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재 Open Graph Protocol (aka. OG Tag) - 소셜 그래프 내에서 웹 페이지를 리치하게 표현하기 위한 프로토콜 - <meta> 태그의 Property와 Content를 사용하여 표현 <head> <meta property="og:type" content="website" /> <meta property="og:title" content="߽ਗࢲܨ ߊә" /> <meta property="og:description" content="प࠺୒ҳೡ ٸ ߽ਗ т ೙ਃহ੉ ߽ਗࢲܨ ߊә߉ਵࣁਃ!" /> <meta property="og:image" content="https://~/insurance-homme/images/insu-claim-docu-share-fb.png" /> </head>
75. 이슈4) 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재 <head> <meta property="og:type" content="website" /> <meta property="og:title" content="߽ਗࢲܨ ߊә" /> <meta property="og:description" content="प࠺୒ҳೡ ٸ ߽ਗ т ೙ਃহ੉..." /> <meta property="og:image" content=".../insu-claim-docu-share-fb.png" /> </head>
76. FE 공통 서버 치아보험 운전자보험 자동차보험 암보험 내 대출한도 보험 서비스 대출 서비스 신용 조회 Client Side Rendering 환경에서의 Open Graph 운영은 어렵습니다.
77. FE 공통 서버 치아보험 운전자보험 자동차보험 암보험 내 대출한도 신용 조회 보험 서비스 대출 서비스 -> 서비스마다 하나의 Open Graph 정의 가능 서비스마다 하나의 index.html 존재 Client Side Rendering 환경에서의 Open Graph 운영은 어렵습니다.
78. 신용 조회 치아보험 FE 공통 서버 운전자보험 자동차보험 암보험 내 대출한도 보험 서비스 대출 서비스 -> Open Graph로 최대한 리치한 정보 제공 페이지마다 다른 Open Graph 적용 필요 Client Side Rendering 환경에서의 Open Graph 운영은 어렵습니다.
79. 기본 미리보기 페이지별 미리보기
80. 이슈4) 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재 <AS - IS> - Open Graph를 포함한 Static HTML 페이지를 만들어서 배포 - Static HTML 페이지에 사용자 접속 시 원래 서비스 페이지로 Redirect 사용자 Crawler FE 공통 서버 Static Page -> 경로별 Open Graph 설정 가능하게끔 변경 Open Graph 확인 Static Page 열람 공통 서버로 Redirect
81. 이슈4) 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재 <AS - IS> - Open Graph를 포함한 Static HTML 페이지를 만들어서 배포 - Static HTML 페이지에 사용자 접속 시 원래 서비스 페이지로 Redirect 사용자 Crawler FE 공통 서버 -> 경로별 Open Graph 설정 가능하게끔 변경 Open Graph 확인 Static Page 열람 공통 서버로 Redirect 필요 시마다 Static Page 생성 작업 필요 Static Page
82. <TO - BE> - 경로별 Open Graph 값을 등록할 수 있는 환경 구축 - 사용자가 요청한 경로에 해당되는 Open Graph 값 제공 이슈4) 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재 -> 경로별 Open Graph 설정 가능하게끔 변경 사용자 Crawler FE 공통 서버 Open Graph 확인 경로별 Open Graph 설정 마케터 / PM / 개발자 서비스 사용
83. <TO - BE> - 경로별 Open Graph 값을 등록할 수 있는 환경 구축 - 사용자가 요청한 경로에 해당되는 Open Graph 값 제공 이슈4) 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재 -> 경로별 Open Graph 설정 가능하게끔 변경 사용자 Crawler FE 공통 서버 Open Graph 확인 경로별 Open Graph 설정 마케터 / PM / 개발자 서비스 사용 운영성 개발업무 감소 개발자 없이 유연한 Open Graph 운영 가능
84. SNS에서 페이지 미리보기가 제대로 나와야 잠재 사용자를 끌어올 수 있는데, Client Side Rendering 환경에서는 이 작업이 너무 번거로워! Open Graph 관리 시스템으로 더 이상 귀찮은 작업이 필요 없어!
85. 마무리 (Wrap Up) - 프론트엔드 서비스 제공 환경의 유연한 운영이 어려움 - 레거시 환경을 Container 기반 K8s 환경으로 이관하여 유연한 서버 관리 가능 - 배포 · 롤백에 오랜 시간 소요 - Yarn Berry 도입 및 롤백 전략 수립으로 배포 · 롤백 시간 대폭 단축 - 퍼블릭 오픈 전 기능 최종 확인 수단의 부재 - 계정 기반의 RC 배포 환경 도입으로 퍼블릭 오픈 전 추가 검증 레이어 확보 - 외부 트래픽을 전이시키기 위한 운영성 개발업무 존재 - 경로별 Open Graph 관리 시스템 구축으로 유연한 Open Graph 운영 가능
86. 카카오페이 FE인프라TF 성공적인 서비스 사용 경험 제공의 밑거름 개발자 경험 향상 운영 경험 향상 사용자 경험 향상
87. E.O.D