같지만 다른 은행에서 퍼블릭 클라우드 사용하기

#금융 #IaC #AWS #카카오뱅크

카카오뱅크는 같지만 다른은행을 만들기 위해 지속적으로 혁신 중입니다. 은행이 지켜야할 규제와 개발생산성 사이에서 계속 고민하고 있습니다. 카카오뱅크가 클라우드 사용을 준비하는 과정에서 무엇을 해야했는지, 규제를 비롯한 여러 요구사항들과 이를 기반으로 설계한 아키텍쳐를 간략하게 공유드립니다. 그리고 IaC로 무엇을 얻었고, 어떤 청사진이 있는지 소개합니다.

발표자 : chuck.kim
카카오뱅크에서 클라우드 엔지니어로 일하고 있는 척입니다. 금융의 클라우드 네이티브라는 멋진 목표를 가진 팀 안에서 즐겁게 일하고 있습니다.

Transcript

1. if(kakao)2022 같지만 다른 은행에서 퍼블릭 클라우드 사용하기 Copyright 2022. Kakao Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakaobank 김준식 Chuck.kim 카카오뱅크
2. 배경 클라우드 사용 준비 단계의 요구사항과 선택한 기술/전략 요구사항 분석 및 적용 Code Coverage Blueprint QNA
3. 배경 카카오뱅크의 클라우드 금융감독원 규정준수, 사내 내규 준수, 내규 신설, 망분리, 규제, 보안심의, 단말분리, 방화벽, 접근제어, 권한의 최소화 부여, 기록보관, 장비백업, 인프라 변경 증적관리, 결재 관리, BCP, DR, 정기점검, 일일점검, 이미지관리, 기반인프라 모니터링, 네트워크 연결 모니터링, 어플리케이션 모니터링, 시스템 로깅, 데이터베이스 권한/연결관리, 서비스 개발 인프라 지원, 클라우드 관리 서비 스 지원, 비용 모니터링, 인프라 형상관리, 비용 효율화 배포 과정 정의, 인프라 코드 개발, 이름 컨벤션, 태그관리, DNS 구조 설계 클라우드 사용 준비 What How 현재 사내 데이터센터로 사용중 클라우드 사용 준비 2020년 정보보호 심의/의결 통과 }클라우드 사용 준비
4. 카카오뱅크의 클라우드 요구사항 정의 아키텍쳐 설계 금융 규제준수와 안정적인 구조 지향 요구사항을 만족하는 설계
5. 분류 상세내용 선택한 기술/전략 운영우수한 인프라 구조와 배포 파이프라인 잘 설계된 구조의 기반 위로 유연하게 경영/금융망에 맞게 재정의가 가능한 절차가 필요함 IaC, JIRA, Git 인프라 변경 증적 관리 작업의 계획서를 기반으로 결재가 필요하고, 작업과정의 기록이 필요함 직무분리 인프라 자원 생성/변경은 클라우드팀이 결재완료 후 생성해야함 기록 보관 클라우드내 사용자/역할의 모든 활동과 네트워크 패킷기록이 일정 기간동안 저장이 필요함 VPC Flow log, CloudTrail 로그 저장 관리 클라우드 접근 단말 분리 클라우드 관리 콘솔에 접근하는 단말을 개발단말과 분리해야함 전용 VDI Cloud Native 서비스 설계/운영 Cloud Native한 컴퓨팅 자원, 서비스 배포, 운영 방식 필요함 Kubernetes, Serverless 접근제어 및 권한 최소화 일정기간동안 결재받은 사용자/장비만 접근 가능하도록 접근제어 및 필요권한 최소화 부여 LDAP기반 사용자 임시권한 획득, 결재기반 장비 권한 부여 그 밖의 컴플라이언스 규제준수와 안정성 확보 ( 골든이미지, Outbound Firewall, BCP, 백업, DR ) 다양한 방식 클라우드 사용 준비 단계의 요구사항과 선택한 기술/전략 카카오뱅크의 클라우드
6. 분류 상세내용 선택한 기술/전략 운영우수한 인프라 구조와 배포 파이프라인 잘 설계된 구조의 기반 위로 유연하게 경영/금융망에 맞게 재정의가 가능한 절차가 필요함 IaC, JIRA, Git 인프라 변경 증적 관리 작업의 계획서를 기반으로 결재가 필요하고, 작업과정의 기록이 필요함 직무분리 인프라 자원 생성/변경은 클라우드팀이 결재완료 후 생성해야함 기록 보관 클라우드내 사용자/역할의 모든 활동과 네트워크 패킷기록이 일정 기간동안 저장이 필요함 VPC Flow log, CloudTrail 로그 저장 관리 클라우드 접근 단말 분리 클라우드 관리 콘솔에 접근하는 단말을 개발단말과 분리해야함 전용 VDI Cloud Native 서비스 설계/운영 Cloud Native한 컴퓨팅 자원, 서비스 배포, 운영 방식 필요함 Kubernetes, Serverless 접근제어 및 권한 최소화 일정기간동안 결재받은 사용자/장비만 접근 가능하도록 접근제어 및 필요권한 최소화 부여 LDAP기반 사용자 임시권한 획득, 결재기반 장비 권한 부여 그밖의 컴플라이언스 규제준수와 안정성 확보 ( 골든이미지, Outbound Firewall, BCP, 백업, DR ) 다양한 방식 클라우드 사용 준비 단계의 요구사항과 선택한 기술/전략 카카오뱅크의 클라우드 TBA
7. 요구사항 분석 및 적용 운영우수한 인프라 관리 방식 세부 요구사항 정제된 요구사항 사용 기술/전략 망/환경별 비용, 권한 등 구분/관리필요 목적에 맞는 역할로 분리/위임된 다계정구조 CSP 조직단위 다계정 구조 방화벽, 권한의 적용이 명시적으로 관리가 필요함 코드와 자원형상의 동기화 IaC ( Terraform ) 예측가능한 작업을 자주 배포/ 롤백할 수 있어야함 작업 영향도와 과정/결과를 검증하는 절차 계정들 모두 일원화된 모양을 유지해야함 같은 코드 기반으로 인프라 프로비져닝 망/계정 별로 만들어져야 할 자원들이 독립적임 망/계정별 재정의(override) 가 가능한 구조 명확한 규칙 기반으로 생성되는 자원 자원의 이름, 생성과정을 일련화 metadata 정례화/관리 자원을 메타데이터를 이용하여 관리 Tag기반으로 자원관리 “잘 설계된 구조의 기반 위로 유연하게 경영/금융망에 맞게 재정의가 가능한 절차가 필요함”
8. 요구사항 분석 및 적용 운영우수한 인프라 관리 방식 정제된 요구사항 사용 기술/전략 목적에 맞는 역할로 분리/위임된 다계정구조 CSP 조직단위 다계정 구조 • 조직단위와 SCP • 중앙 집중식 계정 및 비용 관리 • SSO 통합 사용자 관리 • 역할별 다계정 • 권한 부여 범위의 세분화 • 중요 정보의 접근 제어 Root Kabang OU Master Account Core OU Service OU Member Account Member Account Member Account Member Account SCP 카카오뱅크 계정구조
9. 요구사항 분석 및 적용 운영우수한 인프라 관리 방식 정제된 요구사항 사용 기술/전략 코드와 자원형상의 동기화 IaC ( Terraform ) 작업 영향도와 과정/결과를 검증하는 절차 같은 코드 기반으로 인프라 프로비져닝 망/계정별 재정의(override) 가 가능한 구조 Terraform • 사람이 읽기편한 config 파일로 인프라 설정/관리 • Infrastructure as code tool • CSP, SaaS 등의 API를 통합사용가능 • 활성사용자, 성숙도 높음 • Git 기반의 권한/기록관리 가능 • 담당자의 부재/변경 시 레거시 인프라의 히스토리를 모르는 경우 • 작업의 결과가 미치는 영향도가 명확하게 보이지 않는 경우 • 테스트가 어려운 설정 변경의 경우 → 작업계획서와 결재 등으로 보완 인프라 변경이 어려운 이유 "IaC 로 해결해 볼수 있지 않을까?"
10. 요구사항 분석 및 적용 운영우수한 인프라 관리 방식 route.tf <terraform code> terraform.tfstate <AWS S3 Object> routing rule <AWS Route Table Rule> resource "aws_route" "dev_to_test" { route_table_id = route_table_id destination_cidr_block = destination_cidr vpc_peering_connection_id = var.peering_id } Plan Apply 코드기반으로 인프라가 생성되고, 상태값을 저장하여 코드와 형상의 불일치(drift)가 없는지 확인가능 #aws_route.dev_to_test["rtb-0bxxx9de.10.214.64.0/18"]: resource "aws_route" "dev_to_test" { destination_cidr_block = "10.214.64.0/18" id = "r-rtb-0b77xxxx39d" origin = "CreateRoute" route_table_id = "rtb-0bxxx9de" state = "active" vpc_peering_connection_id = "5e297dfd678d" } 정제된 요구사항 사용 기술/전략 코드와 자원형상의 동기화 IaC ( Terraform ) 작업 영향도와 과정/결과를 검증하는 절차 같은 코드 기반으로 인프라 프로비져닝 망/계정별 재정의(override) 가 가능한 구조
11. 요구사항 분석 및 적용 운영우수한 인프라 관리 방식 route.tf <terraform code> terraform.tfstate <AWS S3 Object> routing rule <AWS Route Table Rule> resource "aws_route" "dev_to_test" { route_table_id = route_table_id destination_cidr_block = destination_cidr vpc_peering_connection_id = var.peering_id } Plan Apply 코드기반으로 인프라가 생성되고, 상태값을 저장하여 코드와 형상의 불일치(drift)가 없는지 확인가능 #aws_route.dev_to_test["rtb-0bxxx9de.10.214.64.0/18"]: resource "aws_route" "dev_to_test" { destination_cidr_block = "10.214.64.0/18" id = "r-rtb-0b77xxxx39d" origin = "CreateRoute" route_table_id = "rtb-0bxxx9de" state = "active" vpc_peering_connection_id = "5e297dfd678d" } 정제된 요구사항 사용 기술/전략 코드와 자원형상의 동기화 IaC ( Terraform ) 작업 영향도와 과정/결과를 검증하는 절차 같은 코드 기반으로 인프라 프로비져닝 망/계정별 재정의(override) 가 가능한 구조
12. Module Network/VPC • 기반 구조 모듈화 • 보안조치 사전 완료 • 재사용성 및 일관성 향상 정제된 요구사항 사용 기술/전략 코드와 자원형상의 동기화 IaC ( Terraform ) 작업 영향도와 과정/결과를 검증하는 절차 같은 코드 기반으로 인프라 프로비져닝 망/계정별 재정의(override) 가 가능한 구조 모듈의 적절한 기능과 크기가 중요 “module A” “module A” - 망별로 다른 요구사항 만족해야함 - 코드의 파편화를 방지하는 강제력 발생 - 모듈변경/수정 영향이 전 환경으로 커짐 금융망 요구사항 경영망 요구사항 <카카오뱅크의 기본 네트워크 구조>
13. 모듈을 사용한 네트워크 구성 작업 영역의 구조설계 요구사항 분석 및 적용 VPC Module “192.168.0.0/16” “172.16.0.0/16” 운영우수한 인프라 관리 방식 정제된 요구사항 사용 기술/전략 코드와 자원형상의 동기화 IaC ( Terraform ) 작업 영향도와 과정/결과를 검증하는 절차 같은 코드 기반으로 인프라 프로비져닝 망/계정별 재정의(override) 가 가능한 구조 biz/dev/terraform.tfstate <AWS S3 Object> fin/prod/terraform.tfstate <AWS S3 Object> 경영 dev 금융 Prod 분류 특징 예시 자원중심 CSP 자원 구조의 의존성을 따라 기반 작업 구조 Network, Computing, Permission, Database 목적중심 자원중심의 기반구조를 사용하여 목적에 맞는 작업 영역의 구조 Service, Organization, Role
14. 자원이름 규칙 망, 계정, 지역, 서비스명, 어플리케이션명, 자원 자원 태그 규칙 요구사항 분석 및 적용 운영우수한 인프라 관리 방식 정제된 요구사항 사용 기술/전략 자원의 이름, 생성과정을 일련화 metadata 정례화/관리 Tag기반으로 자원관리 Name = join("-", [ var.env, var.account, var.region_code, "kakaobank", var.service, var.resource ]) => ex) "biz-dev-apne2-kakaobank-A-ec2" 태그명 변경 되는 사유 서비스 서비스이름의 변경 조직도 조직도 변경 담당자 담당자의 변경 결재 결재 기한만료, 증적 구분 기반인프라, 서비스, 모니터링 비용 비용관련 속성 default_tags { tags = { Service = "ifkakao2022" Department = "cloud-team" Owner = "chuck.kim" Approval = "5954954584" Category = "service" Cost = "bursting" Account = "dev" Env = "lab" LastModifier = "chuck.kim" Path = "${repo}/${path}" Team = "cloud" … TerraformManaged = true } } 자원명을 확인하면 즉각 어떤 자원인지 인지가능하고, 태그 기반 programmatic 자원관리가 가능해짐
15. 요구사항 분석 및 적용 세부 요구사항 정제된 요구사항 사용 기술/전략 작업계획서 작성후 결재 신청 MR기반의 terraform plan 결과 ( 변경될 인프라 형상 )로 결재 상신 Git기반 IaC 작업수행 결재번호로 작업 내용 확인 가능해야함 결재/작업완료된 결재문서에서 해당 작업 과정/결과 내용 확인가능 Git과 JIRA의 연동을 통한 증적관리 “작업의 계획서를 기반으로 결재가 필요하고, 작업과정의 기록이 필요함” *MR : Merge Request 인프라 변경 증적 관리
16. 요구사항 분석 및 적용 인프라 변경 증적 관리 정제된 요구사항 사용 기술/전략 MR기반의 terraform plan 결과 ( 변경될 인프라 형상 )로 결재 상신 Git기반 IaC 작업수행 결재/작업완료된 결재문서에서 해당 작업 과정/결과 내용 확인가능 Git과 JIRA의 연동을 통한 증적관리 Git 클라우드팀 Feature/ 작업계획 등록 결재시스템 Atlantis CI script 작업확인 결재확인 보안점검 작업승인 작업실행 작업내용확인 결재완료 Release/{결재ID} 배포 작업내용 등록 작업완료
17. 요구사항 분석 및 적용 직무분리 세부 요구사항 정제된 요구사항 사용 전략 클라우드팀 외 관리콘솔 접근 금지 직접적인 권한행사 말고 통제되고 제어가능한 방식으로 요청 Git기반의 IaC 협업 인프라자원은 클라우드팀만 배포 클라우드팀의 작은 변경코드의 MR리뷰를 통해 빠르게 배포가 가능해야함 “인프라 자원 생성/변경은 클라우드팀이 결재완료 후 생성해야함”
18. 요구사항 분석 및 적용 정제된 요구사항 사용 기술/전략 직접적인 권한행사 말고 통제되고 제어가능한 방식으로 요청 Git기반의 IaC 협업 클라우드팀의 작은 변경코드의 MR리뷰를 통해 빠르게 배포가 가능해야함 IaC Git Repo MR 생성권한 개발팀 직무분리
19. 97.3% 2.5% 0.2% 95% 4% 1% No Tags AWS Managed Tags IaC Managed Tags 경영 금융 Code Coverage ( IaC ) 22.09.01 기준
20. 클라우드팀 Blueprint 서비스 개발팀 클라우드팀 Application Low Level IaC 개발 검증 운영 Abstract IaC layer for service team 직무분리 개발팀과 복잡한 인프라사이에서 소비되는 시간 효율화 필요 Design, Develop Application
21. 클라우드팀 Blueprint 서비스 개발팀 클라우드팀 Application High Level IaC Low Level IaC 개발 검증 운영 Design, Develop Application Participate in the implementation of IaC Abstract IaC layer for service team GitOps 직무분리
22. CDKTF - Terraform의 HCL → Typescript , Python, Go 언어 - 클라우드팀 terraform module 재사용 가능 클라우드팀 Blueprint 인프라와 코드간 동기화 - IaC Drift 탐지/동기화 - 의존성이 있는 자원들의 변경후, 영향을 받는 자원들에게 배포를 유도 Terraform module - 클라우드팀이 작성한 terraform module을 서비스 개발팀에서 재사용 가능하게 제공 - 모듈 별 보안성 심의 확인을통해 향후 서비스 심의 기간 단축 기대 Managed Service - Lambda와 같은 서비스를 사용하기위해 독립적인 파이프라인 제공 - 클라우드팀의 기반 자원 참조하여 유연하게 사용 독려
23. CDKTF - Terraform의 HCL → Typescript , Python, Go 언어 - 클라우드팀 terraform module 재사용 가능 클라우드팀 Blueprint 인프라와 코드간 동기화 - IaC Drift 탐지/동기화 - 의존성이 있는 자원들의 변경후, 영향을 받는 자원들에게 배포를 유도 Terraform module - 클라우드팀이 작성한 terraform module을 서비스 개발팀에서 재사용 가능하게 제공 - 모듈 별 보안성 심의 확인을통해 향후 서비스 심의 기간 단축 기대 Managed Service - Lambda와 같은 서비스를 사용하기위해 독립적인 파이프라인 제공 - 클라우드팀의 기반 자원 참조하여 유연하게 사용 독려
24. CDKTF - Terraform의 HCL → Typescript , Python, Go 언어 - 클라우드팀 terraform module 재사용 가능 클라우드팀 Blueprint 인프라와 코드간 동기화 - IaC Drift 탐지/동기화 - 의존성이 있는 자원들의 변경후, 영향을 받는 자원들에게 배포를 유도 Terraform module - 클라우드팀이 작성한 terraform module을 서비스 개발팀에서 재사용 가능하게 제공 - 모듈 별 보안성 심의 확인을통해 향후 서비스 심의 기간 단축 기대 Managed Service - Lambda와 같은 서비스를 사용하기위해 독립적인 파이프라인 제공 - 클라우드팀의 기반 자원 참조하여 유연하게 사용 독려
25. CDKTF - Terraform의 HCL → Typescript , Python, Go 언어 - 클라우드팀 terraform module 재사용 가능 클라우드팀 Blueprint 인프라와 코드간 동기화 - IaC Drift 탐지/동기화 - 의존성이 있는 자원들의 변경후, 영향을 받는 자원들에게 배포를 유도 Terraform module - 클라우드팀이 작성한 terraform module을 서비스 개발팀에서 재사용 가능하게 제공 - 모듈 별 보안성 심의 확인을통해 향후 서비스 심의 기간 단축 기대 Managed Service - Lambda와 같은 서비스를 사용하기위해 독립적인 파이프라인 제공 - 클라우드팀의 기반 자원 참조하여 유연하게 사용 독려
26. Thanks
27. Appendix
28. 참고 문헌 AWS - Account Design : https:/ /docs.aws.amazon.com/whitepapers/latest/organizingÉyourÉawsÉenvironment/organizingÉyourÉawsÉenvironment.html - Organization : https:/ /docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_gettingÉstarted_concepts.html - Service Control Policy : https:/ /docs.aws.amazon.com/ko_kr/organizations/latest/userguide/orgs_manage_policies_scps.html Hashicorp Terraform - default_tags : https:/ /www.hashicorp.com/blog/defaultÉtagsÉinÉtheÉterraformÉawsÉprovider - Drift : https:/ /www.hashicorp.com/blog/detectingÉandÉmanagingÉdriftÉwithÉterraform