kakao·2026년 8월 6일·4분 읽기큐레이션 요약

개인화된 Airflow 테스트 환경 구축 및 운영 경험

수천 개의 Airflow DAG를 운영하는 카카오 데이터서비스 조직은 테스트 과정의 반복 작업과 환경 간 차이, 리소스 충돌 문제를 해결하기 위해 PR 단위의 개인 Airflow 환경인 AirZone을 구축했습니다. AirZone은 GitHub PR 코멘트에서 생성·삭제를 요청하면 Kubernetes Job과 전용 Helm 차트로 격리된 Airflow를 배포합니다. 사용자는 인프라를 직접 구성하지 않고 실제 운영 환경과 유사한 하둡·인증 환경에서 DAG를 테스트할 수 있습니다. ## 기존 테스트 방식의 한계 - **로컬 Airflow** - Airflow뿐 아니라 하둡 인증, 연결 설정, Docker 환경까지 직접 구성해야 합니다. - 초기 구축 비용이 크고, 로컬 환경과 운영 환경의 차이로 인해 실제 배포 후 실패할 수 있습니다. - **개발용 Airflow** - 코드를 커밋하고 푸시한 뒤 GitHub webhook, submodule 업데이트, DAG 파일 처리 과정을 기다려야 합니다. - DAG를 수정할 때마다 동기화 지연이 반복되어 개발 속도를 떨어뜨렸습니다. - **테스트용 Airflow** - SSH 컨테이너에 로컬 파일을 복사해야 하므로 코드 수정 때마다 추가 작업이 필요합니다. - 실제 데이터와 하둡에 접근하려면 prod VPN을 연결해야 하는 불편도 있었습니다. - **Production Airflow에서의 테스트** - 테스트 DAG가 스케줄러와 워커 자원을 점유해 다른 프로젝트의 실행을 지연시킬 수 있습니다. - 과도한 리소스 사용으로 노드 장애가 발생하면 같은 노드의 다른 태스크까지 중단될 위험이 있습니다. ## AirZone의 핵심 요구사항 - Kubernetes나 Helm을 몰라도 브라우저에서 Airflow 환경을 생성하고 삭제할 수 있어야 합니다. - 사용자는 DAG 검증에만 집중하고, 인프라 구성은 AirZone이 담당해야 합니다. - Jupyter Notebook을 제공해 별도 로컬 환경 없이 코드를 수정할 수 있어야 합니다. - 운영 환경과 유사한 DAG 실행 환경과 하둡 인증 방식을 제공해야 합니다. - PR마다 독립된 Airflow를 생성해 사용자와 테스트 작업을 서로 격리해야 합니다. ## PR 단위의 격리된 환경 - 레포지터리명과 PR 번호를 조합해 Kubernetes 네임스페이스를 생성합니다. - Airflow 웹 서버, 스케줄러, PostgreSQL, Jupyter, DAG PVC, 로그가 PR별로 분리됩니다. - 한 PR의 테스트가 다른 프로젝트의 스케줄러·워커 자원을 침범하지 않습니다. - 리뷰어는 PR에 남은 링크로 특정 코드 상태의 실행 결과를 직접 확인할 수 있습니다. - PR이 종료되면 네임스페이스를 기준으로 관련 리소스를 쉽게 정리할 수 있습니다. ## 요청 처리와 배포 작업의 분리 - `airzone-api`는 PR 존재 여부, PR이 열려 있는지, 네임스페이스 중복 여부 등 요청의 유효성만 검증합니다. - 실제 Helm 설치와 헬스체크는 별도의 Kubernetes Job이 수행합니다. - API가 수 분이 걸리는 배포 작업을 직접 기다리지 않으므로 빠르게 응답할 수 있습니다. - Job별로 상태와 로그가 독립적으로 남아 실패 단계와 원인을 추적하기 쉽습니다. - 실패한 Job을 삭제한 뒤 새 Job을 생성하는 방식으로 배포를 재시도할 수 있습니다. - 생성 요청은 `create-airzone-{namespace}`, 삭제 요청은 `delete-airzone-{namespace}` 형식의 Job 이름을 사용합니다. ## GitHub PR 코멘트를 사용자 인터페이스로 활용 - PR 생성 이벤트를 webhook으로 받아 저장소, 브랜치, PR 번호, 요청자 정보를 확인합니다. - 사용자가 선택할 수 있도록 하둡 환경별 AirZone 생성 링크를 PR 코멘트에 남깁니다. - 생성 완료 결과와 접속 정보도 PR에 표시해 별도 플랫폼 없이 테스트를 시작할 수 있습니다. - 다만 Jupyter 토큰과 Kubernetes 네임스페이스 토큰처럼 민감한 정보는 공개 범위가 넓은 PR 대신 카카오워크로 전달합니다. - 요청 접수와 배포 완료 시점에 카카오워크 알림을 보내 진행 상태를 알립니다. ## 전용 Helm 차트로 구성한 Airflow 기존 운영용 Airflow 차트가 아닌 AirZone 전용 Helm 차트를 만들어 테스트 환경에 필요한 구성만 묶었습니다. - **Airflow 구성** - 웹 서버와 스케줄러를 배포합니다. - `KubernetesExecutor`, DAG 스캔 주기, 로그 설정, 하둡 관련 변수를 테스트 환경에 맞게 설정합니다. - **데이터베이스와 저장소** - 개인 환경용 PostgreSQL을 함께 배포합니다. - scheduler와 Jupyter가 같은 DAG 작업 디렉터리를 사용하도록 DAG PVC를 공유합니다. - **DAG 동기화** - PR의 head repository와 branch 정보를 받아 해당 코드만 동기화합니다. - Git 초기화 컨테이너 등을 통해 배포 환경에 테스트 대상 DAG를 준비합니다. - **인증과 보안** - 사용자·공용 principal, 키탭, Jupyter 토큰을 환경에 주입합니다. - 하둡 접근에 필요한 Kerberos 인증을 운영 환경과 유사하게 구성합니다. - dkos에서 제공하는 TLS 인증서도 테스트 환경에 반영합니다. - **운영 연동** - 여유 있는 노드 그룹과 같은 리전의 `storageClass`를 선택합니다. - Airflow 로그를 Elasticsearch와 Kibana에서 확인할 수 있도록 연결 정보를 주입합니다. - Jupyter를 함께 제공해 브라우저에서 DAG와 관련 코드를 수정할 수 있게 합니다. ## 자동 정리와 운영 구조 - 생성·삭제 요청은 Kubernetes Job으로 처리합니다. - PR 종료 후 남아 있는 AirZone은 매일 실행되는 CronJob이 자동으로 회수합니다. - 사용자에게는 “PR 코멘트의 링크를 누르는 기능”으로 단순하게 보이지만, 운영자는 요청·설치·헬스체크·알림·정리 단계를 각각 추적할 수 있습니다. - 운영 환경에서 불필요한 PGBouncer나 외부 DB 연결 등은 제외해 개인 테스트 환경의 복잡도와 비용을 줄였습니다. AirZone과 같은 구조를 도입할 때는 테스트 환경을 운영 환경과 최대한 유사하게 유지하되, PR 또는 브랜치 단위로 리소스를 격리하는 것이 중요합니다. 또한 긴 배포 작업은 API 요청과 분리하고, Kubernetes Job의 상태·로그·재시도 기능을 활용하면 장애 대응과 운영 추적이 훨씬 쉬워집니다.

원문 읽기(새 탭에서 열림)

쿠버네티스PostgreSQLapache-sparkhelm+3

gitlab·2026년 8월 6일·3분 읽기큐레이션 요약

GitLab Secrets Manager, ESO·Terraform·API 지원 추가

GitLab Secrets Manager가 External Secrets Operator(ESO), Terraform/OpenTofu, CLI, API를 지원하면서 CI/CD 외의 환경에서도 하나의 비밀 저장소를 사용할 수 있게 되었다. OpenBao 기반의 Vault 호환 인터페이스를 통해 Kubernetes, 인프라 코드, 외부 자동화가 동일한 방식으로 비밀을 조회하며, 인증에는 단기 JWT를 사용한다. 이를 통해 여러 저장소와 인증 모델, 감사 로그를 따로 관리해야 하는 부담을 줄일 수 있다. ### GitLab Secrets Manager의 통합 비밀 관리 - 기존에는 CI/CD, Kubernetes, Terraform마다 별도의 비밀 저장소를 사용하는 경우가 많았다. - GitLab Secrets Manager는 OpenBao를 기반으로 다음 환경에 동일한 저장소를 제공한다. - Kubernetes 워크로드 - Terraform 및 OpenTofu 실행 - OpenBao 또는 Vault CLI - GitLab CI/CD 작업 - 외부 자동화 시스템 및 스크립트 - Vault 호환 KV v2 API를 제공하므로 기존 Vault 생태계 도구와 연동할 수 있다. - 중앙 집중식 저장소를 사용하면 접근 정책과 감사 추적을 일관되게 관리할 수 있다. ### Kubernetes와 External Secrets Operator 연동 - ESO는 Vault provider를 통해 GitLab Secrets Manager에서 비밀을 가져온다. - Kubernetes 워크로드는 단기 JSON Web Token(JWT)을 사용해 OpenBao에 인증한다. - `SecretStore` 리소스에서 다음 항목을 설정한다. - `server`: GitLab Secrets Manager의 Vault 호환 서버 주소 - `path`: KV v2 마운트 경로 - `namespace`: 조직·그룹·프로젝트 계층을 나타내며 접근 가능한 비밀 범위를 제한 - `auth.jwt.path`: JWT 인증 경로 - `auth.jwt.role`: 사용할 인증 역할 - `secretRef`: Kubernetes Secret에 저장된 JWT 참조 - `ExternalSecret`은 원격 비밀과 Kubernetes Secret 사이의 매핑을 정의한다. - `remoteRef.key`: GitLab Secrets Manager의 비밀 경로 - `property`: 원격 비밀 내부에서 가져올 필드 - `secretKey`: Kubernetes Secret에 저장될 키 - `target.name`: 생성할 Kubernetes Secret 이름 - ESO는 대상 Secret을 생성하고 소유하며, 설정된 `refreshInterval`마다 값을 다시 조회한다. - 비밀이 교체되면 애플리케이션을 재배포하지 않아도 Kubernetes Secret에 변경 사항이 반영된다. ### Terraform과 OpenTofu에서 비밀 조회 - Terraform의 `.tfvars` 파일이나 상태 파일에 인증 정보가 기록되면 자격 증명이 유출될 위험이 있다. - GitLab Secrets Manager를 Terraform data source로 조회하면 비밀을 `.tfvars`나 CI/CD 변수에 직접 저장하지 않고 실행 시점에 가져올 수 있다. - 일반적인 흐름은 다음과 같다. - 외부 스크립트로 GitLab 프로젝트의 단기 JWT를 발급 - Terraform Vault provider에 서버 주소, namespace, 인증 경로, role, JWT 전달 - `vault_kv_secret_v2` data source로 원하는 비밀 조회 - 필요한 경우 `sensitive = true`로 출력값을 민감 정보로 표시 - Terraform 실행 시점에 인증이 이루어지므로 장기 자격 증명을 코드나 설정 파일에 남기는 일을 줄일 수 있다. ### OpenBao 및 Vault CLI 사용 - 기존에 Vault용 CLI나 스크립트를 사용 중인 팀은 별도의 클라이언트를 도입하지 않아도 된다. - `VAULT_ADDR`와 `VAULT_NAMESPACE`를 설정한 뒤, 발급받은 JWT를 JWT 인증 엔드포인트에 전달한다. - 인증 결과로 받은 OpenBao 토큰을 `VAULT_TOKEN`에 설정한다. - 이후 `vault kv get` 명령으로 KV v2 경로의 비밀을 조회할 수 있다. - Vault 호환 방식을 사용하므로 기존 운영 자동화와의 통합 비용이 낮다. ### Secrets Manager API를 통한 외부 자동화 - GitLab CI/CD, Kubernetes, Terraform에 포함되지 않는 외부 시스템은 Secrets Manager API를 사용할 수 있다. - 서비스 계정 또는 액세스 토큰으로 프로젝트별 액세스 토큰 발급 API를 호출한다. - API 응답에는 다음과 같은 연결 정보가 포함된다. - Vault 서버 주소 - namespace - KV 마운트 경로 - 비밀 경로 - JWT 인증 경로 - 인증 role - JWT - 외부 시스템은 이 정보를 이용해 단기 인증을 수행하고 필요한 비밀만 조회한다. - 하드코딩된 비밀번호나 별도의 변수 파일을 유지하지 않아도 되는 것이 장점이다. ### 실용적인 적용 권장 사항 - Kubernetes에서는 ESO의 `SecretStore`와 `ExternalSecret`을 사용해 자동 동기화와 비밀 교체를 구성한다. - Terraform에서는 비밀을 `.tfvars`에 넣기보다 실행 시점의 data source 조회 방식으로 전환한다. - 기존 Vault 자동화가 있다면 OpenBao/Vault CLI 호환 기능을 우선 활용한다. - 외부 서비스에는 장기 토큰 대신 프로젝트 범위와 역할이 제한된 단기 JWT를 사용하고, 접근 범위와 감사 로그를 함께 관리하는 것이 좋다.

원문 읽기(새 탭에서 열림)

쿠버네티스Terraformjwtsecrets-management+4

aws·2026년 7월 13일·5분 읽기큐레이션 요약

AWS 주간 정리: 1주년을 맞은 AWS Builder Center, Security Hub의 네트워크 스캐닝, AWS용 Loom 등 (2026년 7월 13일) | Amazon Web Services

AWS Builder Center가 출범 1주년을 맞아 샌드박스, 워크숍, 커뮤니티 기능을 갖춘 AWS 학습·개발 생태계로 확장됐다. 동시에 AWS Security Hub의 네트워크 스캐닝 및 Azure 지원, SageMaker와 Hugging Face 통합, GPU 관리 비용 인하, Aurora DSQL CDC 정식 출시 등 주요 서비스 업데이트가 발표됐다. AWS는 보안·AI 에이전트·멀티클라우드 관리 기능을 통합해 개발 편의성과 운영 자동화를 강화하는 방향을 보이고 있다. ## AWS Builder Center의 1년 성장 - 2025년 7월 9일 출시 이후 커뮤니티 허브에서 종합 개발자 생태계로 확장됐다. - 주요 기능: - AWS 리전별 서비스 현황 - 커뮤니티가 직접 만드는 Spaces - 카테고리·난이도별 워크숍 - 배지와 연속 활동 기록 - 아티클 시리즈, 조회 수, 저장 항목 - 학생 상태 및 서비스 출시 알림 - GitHub·Amazon 계정 로그인 - 무료 샌드박스 환경 - 5,548명의 작성자가 6,448개 아티클을 게시했으며, 누적 조회 수는 1,040만 회를 넘었다. - 2026년 3월 배지 시스템 출시 후 약 99,226개의 배지가 발급됐다. - 사용자 요청 565건 중 10건이 실제 출시됐고, 20건은 단기 로드맵에 포함됐다. - 인기 글: - MCP와 Strands Agents SDK 기반 AWS Study Buddy: 5만 회 이상 - Kiro를 활용한 EOL Linux 서버 AWS 이전: 4만 5천 회 이상 - 신경 질환 조기 검사를 위한 멀티모달 AI: 3만 8천 회 이상 ## 8시간짜리 무료 AWS 샌드박스 - 워크숍 실습을 위해 사전 구성된 무료 AWS 계정을 제공한다. - 개인 AWS 계정, 신용카드, 수동 리소스 정리가 필요 없다. - 환경은 최대 8시간 동안 활성화되며 이후 계정과 리소스가 자동으로 제거된다. - 한 번에 하나의 샌드박스만 사용할 수 있고, 주 1회 신청할 수 있다. - AWS 서비스를 안전하게 실습하거나 교육용 워크숍을 진행하는 데 적합하다. ## Security Hub의 네트워크 및 멀티클라우드 보안 - **Network Scanning**은 실제 인터넷에서 리소스에 접근 가능한지를 직접 확인한다. - AWS와 Azure 환경에서 다음 리소스를 탐색한다. - 공용 IP 주소 - 가상 머신 - 로드 밸런서 - 접근 가능한 포트와 해당 포트에서 실행 중인 서비스를 식별한다. - 접근 가능한 포트마다 발견 근거와 함께 Security Hub finding을 생성한다. - 기존 네트워크 도달 가능성 분석이 “도달 가능하게 만들 수 있는 구성”을 찾는다면, Network Scanning은 실제 인터넷 도달 여부를 검증한다. - Security Hub Exposures가 관련 설정 및 보안 결과를 결합해 전체적인 위험도를 계산한다. - 신규 고객에게는 기본 활성화되며, 기존 고객은 계정·리전별 또는 조직 정책으로 활성화할 수 있다. - Security Hub Essentials에 추가 비용 없이 포함된다. - Azure 리소스도 자동 검색해 다음 항목을 통합 관리한다. - VM, 컨테이너 이미지, Function Apps, ID - 설정 오류, 인터넷 노출, 소프트웨어 취약점 - AWS와 Azure의 보안 결과를 동일한 형식과 자동화 흐름으로 한 화면에서 관리할 수 있다. ## SageMaker Studio와 Hugging Face 통합 - Hugging Face에서 모델을 선택한 뒤 한 번의 클릭으로 SageMaker Studio에서 커스터마이즈하거나 배포할 수 있다. - 지원 모델에는 다음 작업 흐름이 제공된다. - SageMaker에서 모델 커스터마이즈 - SageMaker 또는 Bedrock 엔드포인트 배포 - 모델 평가 - 사용자 정의 보상 함수를 활용한 강화학습 파인튜닝 - 신규 고객은 사전 구성된 권한과 환경을 갖춘 Studio를 빠르게 생성할 수 있다. - 검증된 고객은 별도 쿼터 증액 요청 없이 G5, G6, G4dn GPU 인스턴스에 기본 접근할 수 있다. - Studio 내부에서 GPU 쿼터 사용량도 확인할 수 있다. ## GPU 관리 비용 인하 - 2026년 7월 1일부터 EKS Auto Mode와 ECS Managed Instances의 가속 인스턴스 관리 비용이 자동으로 인하된다. - 인하 폭: - G 계열: 35% - P 계열 및 AWS Trainium: 60% - 기존 클러스터에도 자동 적용되며 별도 작업이 필요 없다. - EKS Auto Mode: - GPU 인스턴스의 병렬 이미지 풀링 - 로컬 NVMe 기반 가속 워크로드 지원 - 가속기 상태를 인식한 노드 복구 - ECS Managed Instances: - CloudWatch Container Insights 기반 GPU 메트릭 - GPU 하드웨어 장애 자동 모니터링 ## Aurora DSQL의 변경 데이터 캡처 - Aurora DSQL CDC가 정식 출시됐다. - INSERT, UPDATE, DELETE 결과를 변경 이벤트로 만들어 Amazon Kinesis Data Streams에 전송한다. - 활용 사례: - 마이크로서비스 간 데이터 동기화 - Lambda 함수 트리거 - Firehose를 통한 S3, Redshift, OpenSearch Service 전달 - 데이터베이스 워크로드 성능에 영향을 주지 않도록 설계됐다. - CDC 인프라를 별도로 구축하거나 운영할 필요가 없다. ## AWS용 Loom과 안전한 AI 에이전트 운영 - Loom은 AWS Strands Agents와 Amazon Bedrock AgentCore Runtime 기반 에이전트를 구축·배포하는 오픈소스 엔터프라이즈 플랫폼이다. - 제공 기능: - 통합 관리 UI와 백엔드 API - ID 공급자 연동 - 범위 기반 권한 제어 - 멀티 페르소나 탐색 - 에이전트, 메모리, MCP 서버, 에이전트 간 연동의 전체 수명주기 관리 - 멀티테넌트 환경을 위해 RBAC와 ABAC를 지원한다. - 리소스 태깅을 자동화해 비용을 사용자·팀별로 추적할 수 있다. - 표준화된 배포 블루프린트, AWS Agent Registry 연동, 민감한 작업 전 사람의 검토 절차도 제공한다. - AWS Labs GitHub에서 프로젝트를 확인할 수 있다. ## Claude 애플리케이션 접근 제어 - Claude Code와 Claude Desktop에 대한 접근, 비용, 정책을 중앙에서 관리하는 자체 호스팅 게이트웨이가 소개됐다. - OIDC 호환 ID 공급자와 연동하며, 모든 요청에 관리형 설정을 적용한다. - Amazon Bedrock 또는 AWS 기반 Claude Platform으로 추론 요청을 라우팅할 수 있다. - 사용자·그룹별 지출 한도를 설정할 수 있다. - 프라이빗 네트워크의 무상태 컨테이너로 실행되며, PostgreSQL은 단기 로그인 상태만 저장한다. - 개발자 장비에 장기 보안 키를 저장하지 않는 방식으로 보안을 강화한다. ## AWS MCP Server의 OAuth 지원 - AWS Console이나 CLI와 동일한 자격 증명을 사용해 브라우저 기반 OAuth로 AWS MCP Server에 연결할 수 있다. - IAM Federation, AWS IAM Identity Center, 루트 사용자 및 IAM 사용자를 지원한다. - AWS Sign-In이 단기 액세스·리프레시 토큰을 발급하고 토큰 갱신을 자동 처리한다. - 개발자는 재시작 후에도 반복 로그인 없이 에이전트를 인증 상태로 유지할 수 있다. AWS를 학습하거나 실험하려는 경우 Builder Center의 샌드박스와 워크숍을 활용하면 비용과 정리 부담을 줄일 수 있다. 운영 환경에서는 Security Hub의 실제 인터넷 도달성 검사와 Azure 통합을 우선 검토하고, AI 에이전트 도입 시에는 Loom·OAuth·중앙 정책 관리 기능을 통해 권한, 비용, 감사 체계를 함께 설계하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)

쿠버네티스모델 컨텍스트 프로토콜PostgreSQLAWS+4

gitlab·2026년 7월 9일·4분 읽기큐레이션 요약

그린 DevOps: 탄소 측정이 CI/CD 파이프라인에 포함되어야 하는 이유

CI/CD 파이프라인은 매일 상당한 컴퓨팅 에너지와 탄소를 소비하지만, 일반적인 파이프라인 지표에는 그 영향이 드러나지 않는다. 글은 GitLab에 Eco CI와 Carmen을 연동해 파이프라인·인프라·애플리케이션 수준의 탄소 배출량을 측정해야 한다고 주장한다. 측정만으로도 불필요한 테스트 실행, 의존성 재설치, 유휴 서비스 같은 낭비를 찾아 비용과 탄소 배출을 함께 줄일 수 있다. ## CI/CD 파이프라인에 탄소 측정이 필요한 이유 - 현대적인 개발 파이프라인은 하루에도 수백 개의 작업을 실행한다. - AI 기반 테스트, 코드 리뷰, 자동화 작업이 늘면서 과거보다 실행 작업과 에너지 소비가 증가했다. - 파이프라인 로그나 아키텍처 다이어그램에는 컴퓨팅에 따른 탄소 배출량이 표시되지 않는 경우가 많다. - 배출량을 줄이려면 먼저 파이프라인 실행별, 서비스별, 팟(pod)별 배출량을 측정해야 한다. - Green DevOps는 탄소 데이터를 엔지니어링 의사결정에 활용하는 실천 방식이다. ## 파이프라인 수준의 측정: Eco CI - Eco CI는 CI/CD 작업별 에너지 소비량과 탄소 배출량을 측정한다. - 별도 서버나 데이터베이스 없이 가벼운 Bash 스크립트로 실행할 수 있다. - 각 작업의 배출량을 확인하고, 자원 사용량이 큰 작업과 시간에 따른 추세를 파악할 수 있다. - README에 탄소 배출량을 보여주는 배지를 추가할 수도 있다. - 기존 GitLab 파이프라인에 몇 줄을 추가하는 방식이므로 도입 난도가 낮다. - 파이프라인 자체가 이미 관측 대상이므로, 초기 Green DevOps 도구로 적합하다. ## 인프라와 애플리케이션 수준의 측정: Carmen - Carmen(Carbon Measurement Engine)은 Green Software Foundation의 Impact Framework를 기반으로 한다. - Kubernetes에서 실행되는 가상 머신, 팟, 개별 애플리케이션 워크로드까지 측정한다. - 컴포넌트별 CSV 보고서를 생성하며 다음 탄소를 구분한다. - 운영 탄소: 전력 사용으로 발생하는 배출량 - 내재 탄소: 하드웨어 제조와 폐기 과정에서 발생하는 배출량 - 주요 출력 필드는 다음과 같다. - `EnergykWh`: 에너지 소비량 - `TotalCarbonGramsCO2eq`: CO₂ 환산 총 배출량 - 생성된 데이터는 Grafana, FinOps 대시보드, 사내 분석 도구에 직접 연결할 수 있다. - “어떤 서비스가 가장 많은 CO₂를 배출하는가?”, “API 게이트웨이와 데이터 처리 계층 중 어디가 더 큰가?” 같은 질문에 답할 수 있다. ## GitLab 파이프라인에 연동하는 방법 - Eco CI와 Carmen 모두 `.gitlab-ci.yml`에 직접 추가할 수 있다. - Carmen 예시는 다음 작업을 수행한다. - `python:3.12` 이미지 사용 - Node.js, npm, Git, `lsb-release` 설치 - Carmen 저장소를 Git으로 복제 - Impact Framework 관련 npm 패키지 설치 - Carmen을 Python 패키지로 설치 - `carbon-daemon` 실행 - 생성된 결과를 GitLab artifact로 보관 - 결과 artifact는 예를 들어 1주일 동안 보관한 뒤 다운로드해 첫 탄소 보고서로 활용할 수 있다. - Carmen 작업을 별도의 비차단(non-blocking) 작업으로 구성하면 기존 배포 경로를 지연시키지 않는다. ## 측정으로 발견할 수 있는 낭비 - 한 팀은 Eco CI 도입 후 통합 테스트가 전체 파이프라인 배출량에서 예상보다 큰 비중을 차지한다는 사실을 발견했다. - 원인은 테스트 코드가 아니라 매 실행마다 모든 의존성을 처음부터 다시 설치하는 설정이었다. - 의존성 캐시를 추가하면 다음 효과를 동시에 얻을 수 있다. - 테스트 실행 시간 단축 - CI 탄소 배출량 감소 - 개발자 대기 시간 감소 - CI 비용 절감 - Carmen을 스테이징 클러스터에 적용한 결과, 폐기된 기능의 데이터 처리 서비스가 유휴 상태로 계속 실행되고 있었다. - 해당 서비스를 제거함으로써 불필요한 운영 탄소와 내재 탄소 소비를 줄일 수 있었다. - 두 사례 모두 대규모 지속가능성 프로젝트가 아니라, 데이터 가시성에서 출발한 개선이었다. ## 낮은 도입 비용과 실질적인 효과 - Eco CI는 몇 줄의 설정과 Bash 스크립트만으로 추가할 수 있다. - 별도 인프라를 구축하지 않으며 파이프라인에 의미 있는 지연을 추가하지 않는다. - Carmen 역시 독립적인 작업으로 실행할 수 있어 기존 핵심 경로에 영향을 주지 않는다. - 측정 데이터는 향후 탄소 보고와 규제 대응을 위한 조직의 기준선(baseline)이 된다. - 탄소 배출이 적은 코드는 대체로 더 빠르고 저렴하다. - 의존성 캐시, 러너 규모 조정(right-sizing), 불필요한 서비스 제거는 환경 개선이면서 동시에 FinOps 최적화이기도 하다. ## 규제와 기업 요구사항 변화 - 탄소 인식형 엔지니어링은 선택적 활동에서 전문적인 개발 관행으로 자리 잡고 있다. - EU의 기업 지속가능성 보고 지침(CSRD)은 대기업에 클라우드 사용량을 포함한 가치사슬 전반의 배출량 공개를 요구한다. - 기업 고객도 공급업체 선정 과정에서 지속가능성 정책과 배출량 관리 여부를 확인하는 경우가 늘고 있다. - 법적 의무가 생긴 뒤 시작하기보다, 지금부터 작은 범위에서 측정 기준과 내부 운영 습관을 마련하는 편이 유리하다. Eco CI를 단일 GitLab 파이프라인에 먼저 적용해 작업별 탄소 배출량을 확인하고, 이후 Carmen으로 Kubernetes와 서비스 수준까지 범위를 확장하는 접근이 현실적이다. 특히 의존성 캐시, 유휴 리소스 제거, 러너 크기 조정처럼 비용과 성능도 함께 개선하는 항목부터 실행하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

쿠버네티스CI/CDgitlabDevOps+4

aws·2026년 7월 6일·4분 읽기큐레이션 요약

AWS 주간 요약: AWS에서 제공되는 Claude Sonnet 5, AI 에이전트를 위한 Amazon WorkSpaces, AWS 서비스 가용성 업데이트 등 (2026년 7월 6일) | Amazon Web Services

AWS는 이번 주 Claude Sonnet 5, AI 에이전트용 Amazon WorkSpaces, 로그 분석 최적화 OpenSearch 등 AI·인프라 관련 기능을 대거 공개했다. 특히 CloudFormation Express, EKS 버전 롤백, ACM의 ACME 지원처럼 개발·운영 속도와 안정성을 높이는 기능도 강화됐다. 동시에 여러 AWS 서비스와 기능이 유지보수 단계, 일몰 또는 지원 종료로 전환되므로 사용 중인 서비스의 마이그레이션 계획을 점검해야 한다. ## 주요 출시 및 업데이트 ### Graviton5 기반 Amazon EC2 C9g/C9gd - AWS Graviton5 프로세서를 탑재한 컴퓨팅 최적화 인스턴스다. - Graviton4 기반 인스턴스보다 최대 25% 향상된 컴퓨팅 성능을 제공한다. - 캐시 용량이 5배 커졌으며, 클라우드 프로세서 중 가장 빠른 메모리 성능을 제공한다. - C9gd는 로컬 NVMe 스토리지를 지원해 고성능 임시 데이터 처리에 적합하다. ### AWS CloudFormation Express 모드 - 인프라 배포 결과를 수초 내에 확인할 수 있도록 배포 흐름을 단축한다. - AI 에이전트와 개발자가 배포 결과를 빠르게 확인하고 반복 작업을 수행할 수 있다. - 모든 상용 AWS 리전에서 추가 비용 없이 제공된다. ### Amazon EKS Kubernetes 버전 롤백 - Kubernetes 클러스터 업그레이드 후 최대 7일 동안 이전 버전으로 되돌릴 수 있다. - 업그레이드 실패 시 클러스터를 새로 구축하지 않아도 된다. - Kubernetes 버전 업그레이드를 되돌릴 수 있는 저위험 작업으로 만들어 운영 안정성을 높인다. ### AWS Certificate Manager의 ACME 지원 - 표준 ACME 프로토콜을 사용해 퍼블릭 TLS 인증서 발급과 갱신을 자동화할 수 있다. - 기존 ACME 기반 도구 및 자동화 파이프라인과 연동하기 쉬워졌다. - 인증서 만료로 인한 서비스 중단 위험을 줄일 수 있다. ## AI 및 개발 생산성 기능 ### AWS에서 제공되는 Claude Sonnet 5 - Anthropic의 최신 Sonnet 모델로, 코딩·에이전트 작업·일반 업무를 대상으로 한다. - 대규모 코드베이스를 탐색하고 도구를 정확하게 호출할 수 있다. - 장시간 이어지는 에이전트 작업에서 상태를 유지하도록 설계됐다. - Sonnet 계열의 가격대에서 높은 수준의 추론 성능을 제공하는 것이 특징이다. ### AI 에이전트용 Amazon WorkSpaces - AI 에이전트가 관리형 WorkSpaces 환경에서 데스크톱 애플리케이션에 안전하게 접근하고 조작할 수 있다. - 기존 애플리케이션을 현대화하거나 별도의 맞춤형 통합을 구현하지 않아도 된다. - 레거시 GUI 애플리케이션을 AI 자동화 workflow에 포함할 수 있는 기반을 제공한다. - 정식 출시(GA) 단계로 제공된다. ### Amazon SageMaker AI 추론 확장 속도 개선 - 컨테이너 이미지 캐싱을 지원해 생성형 AI 모델의 scale-out 시간을 줄인다. - 추론 확장 이벤트에서 엔드투엔드 확장 속도가 최대 2배 빨라질 수 있다. - 트래픽 급증 시 새 추론 인스턴스를 준비하는 시간을 단축한다. ## 데이터 분석 및 모니터링 개선 ### 로그 분석에 최적화된 Amazon OpenSearch Service - 로그 분석 workload를 위해 별도로 설계된 새로운 엔진을 제공한다. - AWS 내부 벤치마크 기준 최대 4배 향상된 가격 대비 성능을 목표로 한다. - 로그 집계와 정밀한 전문 검색을 하나의 시스템에서 함께 수행할 수 있다. - 검색 기능과 분석 기능을 별도 시스템으로 분리해야 하는 부담을 줄인다. ### CloudWatch 로그 쿼리 기반 알람 - 로그 쿼리 결과에 직접 임계값을 설정해 알람을 만들 수 있다. - 기존처럼 먼저 메트릭 필터나 사용자 지정 메트릭을 생성할 필요가 없다. - 로그 분석과 장애 알림 설정을 하나의 workflow로 처리할 수 있다. ## AWS 서비스 가용성 변경 AWS는 서비스 또는 기능의 제공 상태가 바뀔 때 대체 서비스와 마이그레이션 지침을 제공한다. 2026년 6월 30일 기준으로 다음과 같은 변경이 발표됐다. ### 신규 고객 접근이 제한되는 유지보수 단계 2026년 7월 30일부터 신규 고객이 사용할 수 없게 되는 서비스 및 기능은 다음과 같다. - Amazon Bedrock Agents → Amazon Bedrock Agents Classic - Amazon Cognito Sync - Amazon Kendra - Amazon Q Business - AWS Directory Service – Simple AD - AWS IoT Device Defender – Detect - 2026년 8월 31일부터 신규 고객 접근 제한 - AWS Mainframe Modernization – Self-Managed Experience - AWS Management Console – myApplications - AWS Resource Groups – Group Lifecycle Events - AWS Service Catalog – Application Registry - AWS Systems Manager – Application Manager - SageMaker AI의 A2I, Clarify, Debugger, GeoSpatial, Ground Truth, Mechanical Turk, Model Monitor, Role Manager, Studio Lab ### 서비스 일몰(Sunset) 대상 - Amazon WorkSpaces – PCoIP - Amazon WorkSpaces – Pool - AWS Managed Services Advanced - AWS re:Post Private - Amazon SageMaker AI – Profiler ### 지원 종료 대상 2026년 6월 30일부로 다음 서비스의 지원이 종료됐다. - Amazon Chime SDK – Carrier Voice Focus - Amazon SageMaker AI – Ground Truth Plus ## 예정된 AWS 행사 - AWS Summits: - 2026년 하반기 각 지역에서 열리는 무료 클라우드·AI 행사다. - 최신 기술을 학습하고 커뮤니티와 교류할 수 있다. - AWS Community Days: - 커뮤니티가 직접 기획하고 운영하는 행사다. - 브라질에서는 AWS Community Day Belo Horizonte가 2026년 8월 22일 개최될 예정이다. - AWS Builder Center: - 개발자와 빌더가 솔루션을 공유하고 관련 콘텐츠 및 행사 정보를 확인할 수 있는 커뮤니티 공간이다. 사용 중인 AWS 서비스가 유지보수, 일몰 또는 지원 종료 대상인지 먼저 확인하고, 대체 서비스와 마이그레이션 일정을 미리 수립하는 것이 좋다. 신규 AI·인프라 프로젝트에서는 Claude Sonnet 5, CloudFormation Express, EKS 롤백, 로그 기반 CloudWatch 알람 등을 활용하면 개발 속도와 운영 안정성을 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)

쿠버네티스AWSamazon-sagemakeramazon-eks+4

aws·2026년 7월 1일·3분 읽기큐레이션 요약

Kubernetes 버전 롤백으로 Amazon EKS 클러스터를 안심하고 업그레이드하기 | Amazon Web Services

Amazon EKS가 Kubernetes 클러스터 업그레이드 후 7일 이내에 이전 마이너 버전으로 되돌릴 수 있는 버전 롤백 기능을 출시했습니다. 이는 업그레이드 실패 시 클러스터를 재구축하지 않고, 실제 운영에서 검증된 이전 버전으로 복구할 수 있게 해줍니다. 이를 통해 업그레이드에 대한 부담을 줄이고 보안 패치와 최신 버전 도입을 더욱 적극적으로 추진할 수 있습니다. ### 기존 Kubernetes 업그레이드의 한계 - 오픈소스 Kubernetes는 전통적으로 컨트롤 플레인 버전 롤백을 지원하지 않았습니다. - 업그레이드 후 문제가 발생하면 클러스터를 재구축하거나 장기간의 복구 작업을 진행해야 했습니다. - 조직들은 다음과 같은 보완책을 마련해야 했습니다. - 긴 사전 검증 및 bake 기간 - 단계적 업그레이드 그룹(stagger groups) - 자동 승인 절차 - 수개월에 걸친 업그레이드 일정 - 그 결과 보안 패치가 포함된 최신 Kubernetes 버전으로의 업그레이드를 미루고, 지원 종료나 연장 지원 기간에 임박하는 문제가 발생했습니다. ### Amazon EKS 버전 롤백 기능 - 업그레이드 후 **7일 이내**에 이전 Kubernetes 마이너 버전으로 되돌릴 수 있습니다. - 예를 들어 Kubernetes 1.34에서 1.35로 업그레이드한 뒤 문제가 발견되면 1.34로 복구할 수 있습니다. - 에뮬레이션된 버전이나 임시 상태가 아니라, 실제 운영에서 사용했던 검증된 이전 버전으로 복원합니다. - 한 번에 한 마이너 버전만 롤백할 수 있으며, 이는 EKS의 점진적 업그레이드 정책과 동일합니다. - 자체 관리 노드를 사용하는 클러스터와 AWS 관리형 노드를 사용하는 클러스터 모두 컨트롤 플레인 롤백을 지원합니다. ### 롤백 준비 상태 점검 - EKS는 클러스터 인사이트를 통해 롤백 가능 여부를 자동으로 평가합니다. - 다음과 같은 문제를 사전에 확인할 수 있습니다. - 노드와 컨트롤 플레인 간 버전 호환성 - 애드온 의존성 - 롤백을 방해할 수 있는 클러스터 구성 - 점검 결과를 확인한 뒤 롤백을 시작할 수 있습니다. - 긴급하게 진행해야 하는 경우 `--force` 옵션으로 준비 상태 검사를 우회할 수 있습니다. ### EKS Auto Mode의 노드 롤백 - EKS Auto Mode에서는 컨트롤 플레인과 관리형 노드를 함께 롤백해야 합니다. - 노드 롤백은 Pod Disruption Budget(PDB)을 준수하므로, 설정에 따라 완료까지 시간이 걸릴 수 있습니다. - 롤백이 지나치게 오래 걸리거나 전략을 바꾸고 싶을 때 사용할 수 있도록 취소 API가 제공됩니다. - 기본적으로 EKS는 롤백 중 PDB를 무시하지 않습니다. - 롤백을 빠르게 진행하려면 사용자가 직접 PDB를 수정하거나 제거해야 합니다. - 노드 롤백 기능은 EKS Auto Mode 클러스터에 제공됩니다. ### 롤백 과정과 운영 영향 - EKS 콘솔의 클러스터 설정 화면에서 롤백 가능 여부와 남은 롤백 기간을 확인할 수 있습니다. - 롤백 시작 전에 클러스터 인사이트를 검토해 노드 상태와 잠재적인 문제를 확인합니다. - 사례에서는 컨트롤 플레인 롤백에 약 20분이 걸렸으며, 이는 일반적인 업그레이드와 비슷한 수준입니다. - 롤백 중에도 클러스터는 계속 동작했습니다. - Auto Mode 노드는 PDB 설정에 따라 워크로드 중단을 최소화하면서 순차적으로 롤백됩니다. ### 제공 범위와 비용 - 상용 Amazon EKS가 제공되는 모든 AWS 리전에서 사용할 수 있습니다. - 추가 비용은 없으며, 기존 EKS 및 컴퓨팅 리소스 요금만 부과됩니다. - 표준 지원 또는 연장 지원 대상 Kubernetes 버전을 실행하는 클러스터가 지원됩니다. - 컨트롤 플레인 롤백은 모든 EKS 클러스터에서 사용할 수 있고, 노드 롤백은 EKS Auto Mode에서 지원됩니다. 운영 환경에서는 업그레이드 전에 롤백 가능 기간과 클러스터 인사이트를 확인하고, PDB와 애드온 호환성을 점검하는 것이 좋습니다. 특히 Auto Mode 사용자는 롤백 시간에 영향을 주는 PDB 설정과 취소 API 사용 방법을 미리 검토하면 안전한 복구 계획을 세울 수 있습니다.

원문 읽기(새 탭에서 열림)

쿠버네티스AWSamazon-ekseks-auto-mode+3

discord·2026년 6월 30일·3분 읽기큐레이션 요약

Discord API의 비용 귀속

Discord의 API는 1,700개 이상의 엔드포인트와 약 700개의 백그라운드 작업을 포함한 단일 Python 코드베이스로 운영되며, 수백 개의 Kubernetes 배포에 단계적으로 배포된다. 기존 모니터링은 지연 시간·처리량·오류율은 보여주지만, 메시지 전송이나 스트리밍 같은 제품 기능별 호스팅 비용은 충분히 설명하지 못했다. Discord는 배포 구조를 변경하지 않고 애플리케이션 프로파일링 도구를 확장해, 각 기능의 코드 실행 시간에 따라 배포 비용을 배분하는 방식을 도입했다. ### 대규모 단일 API 코드베이스의 운영 - Discord API는 하나의 Python 코드베이스로 구성되어 있다. - 1,700개 이상의 API 엔드포인트와 약 700개의 백그라운드 작업을 포함한다. - 엔지니어들은 매일 공통 코드에 변경을 가한다. - 변경 사항은 수백 개의 Kubernetes 배포 환경에 단계적 롤아웃 방식으로 지속 배포된다. - 규모가 크고 변경 빈도가 높기 때문에, 매일 발생하는 변화가 사용자나 시스템에 미치는 영향을 추적하기 어렵다. ### 기존 관측성의 범위 - Discord는 다음과 같은 운영 지표를 이미 수집하고 있었다. - 지연 시간 - 처리량 - 오류율 - 이러한 지표는 성능 저하나 오류 증가 같은 회귀(regression)를 감지하는 데 유용하다. - 그러나 특정 제품 기능이 전체 호스팅 비용에서 차지하는 비중은 파악하기 어려웠다. - 예를 들어 다음과 같은 질문에 답하기 어려웠다. - 메시지 송수신 API 운영 비용은 얼마인가? - 스트림 시작 기능에는 얼마가 드는가? - Nitro 선물 전송 비용은 얼마인가? - 특정 코드 변경이 팀의 호스팅 비용을 얼마나 변화시켰는가? ### Kubernetes 배포 단위만으로는 부족한 비용 추적 - 클라우드 제공업체는 일반적으로 Kubernetes 배포별 비용 분류를 제공한다. - 하지만 Discord의 모든 배포에는 동일한 API 코드베이스가 배포된다. - 각 배포는 특정 HTTP 트래픽이나 백그라운드 작업의 일부를 처리하지만, 제품 기능 단위로 깔끔하게 분리되어 있지는 않다. - 비용 추적을 위해 배포를 기능별로 더 세분화하면 운영 복잡성이 지나치게 커진다. - 따라서 기존 배포 토폴로지를 변경하지 않고 비용을 추적할 방법이 필요했다. ### 동시 실행 환경에서의 비용 배분 - 하나의 API 워커 프로세스는 여러 작업을 동시에 처리한다. - 같은 시점에 여러 제품 기능과 관련된 코드를 실행할 수 있다. - 일부 트래픽은 특정 배포로 격리되어 있지만, 기능별 비용 분석에 충분할 정도로 분리된 것은 아니다. - 따라서 단순히 배포 단위의 비용을 특정 기능에 모두 할당할 수 없다. - 정확한 비용 배분을 위해서는 각 배포가 특정 기능의 코드 실행에 얼마나 많은 시간을 사용했는지 측정해야 한다. ### 프로파일링을 활용한 해결책 - Discord는 기존 애플리케이션 프로파일링 도구를 확장했다. - 각 기능과 관련된 코드가 실행된 시간을 측정하고, 이를 기반으로 배포 비용을 배분한다. - 이를 통해 배포 구조를 바꾸지 않고도 다음 단위의 비용을 추정할 수 있다. - 개별 API 엔드포인트 - 여러 엔드포인트로 구성된 제품 기능 - 글에 제시되는 수치와 코드는 실제 운영값이 아닌 설명을 위한 예시다. ### 실용적인 결론 기능별 인프라 비용을 파악하려면 서비스를 물리적으로 기능별 배포로 나누기보다, 공통 실행 환경에서 각 기능이 소비한 컴퓨팅 시간과 리소스를 측정해 비용을 배분하는 방식이 효과적이다. 특히 대규모 단일 코드베이스에서는 기존 관측성에 비용 귀속 정보를 결합하는 것이 운영 구조를 복잡하게 만들지 않는 현실적인 접근이다.

원문 읽기(새 탭에서 열림)

쿠버네티스옵저버빌리티PythonAPI 설계+2

google·2026년 6월 26일·4분 읽기큐레이션 요약

동결된 멀티 토큰 예측으로 Pixel에서 Gemini Nano 모델 가속하기

기존 Gemini Nano v3 모델을 다시 학습하지 않고도 Multi-Token Prediction(MTP)을 추가해 Pixel 기기에서 온디바이스 추론을 가속하는 방법을 소개한다. 별도의 드래프터 모델 대신 본 모델에 가벼운 MTP 헤드를 붙이고, 기존 KV 캐시를 공유하는 zero-copy 구조를 사용해 메모리와 지연 시간을 줄였다. 그 결과 Pixel 9·10의 일부 기능에서 토큰 생성 속도가 50% 이상 향상되고, 인스턴스당 최대 130MB의 메모리를 절약했다. ## 모바일에서 자동회귀 생성이 느린 이유 - 기존 언어 모델은 한 번에 하나의 토큰만 생성하므로, N개 토큰을 만들려면 대형 모델의 추론을 N번 수행해야 한다. - 모바일 기기는 서버보다 RAM과 전력 예산이 제한적이다. - 토큰을 순차적으로 생성하는 과정은 연산 자원을 충분히 활용하지 못하고 메모리 대역폭과 배터리를 많이 소모한다. - 알림 요약, 메시지 교정처럼 짧은 응답도 빠르게 처리해야 하므로 추론 효율이 사용자 경험에 직접 영향을 준다. ## 별도 드래프터의 한계와 MTP - speculative decoding은 다음과 같은 두 단계로 동작한다. - **Draft:** 작은 드래프터 모델이 여러 후보 토큰을 빠르게 생성한다. - **Verify:** 대형 모델이 후보들을 병렬로 검증하고, 일치하는 토큰만 수용한다. - 별도 드래프터 모델은 추가 파라미터와 RAM을 필요로 한다. - 본 모델이 이미 계산한 풍부한 의미 정보를 활용하지 못하고, 텍스트 이력만으로 후보를 예측한다. - MTP는 별도 언어 모델 대신 본 모델의 마지막 층에 경량 Transformer 기반 MTP 헤드를 추가한다. - MTP 헤드는 본 모델의 hidden state를 이용해 여러 미래 토큰을 예측하고, 본 모델은 이를 병렬 검증한다. - 이러한 구조를 글에서는 본 모델의 깊은 지점에서 빠져나와 토큰을 예측하는 **“late exit” 전략**으로 설명한다. ## 동결된 백본에 MTP 헤드 추가 - 이미 배포된 Gemini Nano v3의 가중치는 그대로 동결한다. - 새로 학습하는 부분은 미래 토큰 예측을 담당하는 MTP 헤드뿐이다. - 기존 모델 전체를 다시 사전 학습하거나 별도 드래프터를 작업별로 미세 조정할 필요가 없다. - 백본을 동결하므로 기본 모델의 성능과 안전 정렬을 변경하지 않는다. - 잘못된 후보 토큰은 검증 단계에서 폐기되기 때문에 최종 출력은 기존 대형 모델과 비트 단위로 동일하다. - 따라서 기존 모델과의 하위 호환성을 유지하면서 추론 효율만 개선할 수 있다. ## KV 캐시를 공유하는 zero-copy 구조 - 일반적인 별도 드래프터는 자체 KV 캐시를 생성하고 유지해야 하므로 메모리를 중복 사용한다. - 제안된 MTP 헤드는 본 모델의 KV 캐시에 직접 cross-attention으로 접근한다. - 별도 프롬프트 처리(prefill)나 독립적인 과거 문맥 저장이 필요하지 않다. - 주요 효과는 다음과 같다. - 드래프터가 프롬프트를 다시 처리하지 않아 prefill 지연 감소 - 드래프터 전용 임베딩 테이블과 attention 구조 제거 - 애플리케이션별 튜닝 파라미터 및 중복 KV 캐시 절감 - standalone 드래프터와 비교해 인스턴스당 최대 130MB의 메모리를 절약했다. ## 풍부한 표현이 만드는 예측 정확도 향상 - MTP 헤드는 대형 백본이 이미 계산한 최종 hidden state를 활용하므로 별도 드래프터보다 정확한 후보를 생성한다. - Pixel 9에서 비슷한 규모의 standalone 드래프터보다 작업에 따라 50% 이상의 속도 향상을 보였다. - 복잡한 지시를 따르는 요약·재작성 작업에서 MTP가 크게 우수했다. - 스마트 답장처럼 문장 구조가 예측 가능한 작업에서는 본 모델의 구문 패턴을 잘 학습했다. - 이런 작업에서는 토큰 수용률이 최대 55% 향상됐다. ## Pixel 실사용 결과 - Gemini Nano MTP는 Pixel 9 및 Pixel 10 시리즈에 배포됐다. - 검증과 드래프팅 사이의 의존성을 처리하도록 온디바이스 추론 스택도 함께 재설계했다. - AI 알림 요약과 Proofread 같은 실제 작업에서 추론 한 번당 평균 약 2개의 추가 토큰을 정확히 예측했다. - 수용되는 토큰이 많아지면서 전체 검증 횟수가 감소했다. - 무거운 프로세서를 깨우는 횟수도 줄어들어 응답 시간이 짧아지고 배터리 사용량이 감소했다. ## 실용적인 결론 이미 배포된 온디바이스 모델을 유지해야 하는 경우, 별도 드래프터를 추가하는 것보다 동결된 백본에 MTP 헤드를 붙이고 KV 캐시를 공유하는 방식이 효율적이다. 특히 메모리와 전력이 제한된 모바일 환경에서 모델 출력의 동일성을 유지하면서 속도와 배터리 효율을 함께 개선할 수 있는 현실적인 최적화 전략이다.

원문 읽기(새 탭에서 열림)

쿠버네티스transformeredge-computingspeculative-decoding+3

line·2026년 6월 24일·6분 읽기큐레이션 요약

Flava DBaaS 딥다이브: 아키텍처부터 마이그레이션, 그리고 미래까지

LY Corporation은 Verda와 YNW를 차세대 프라이빗 클라우드 Flava로 통합하면서, 쿠버네티스 오퍼레이터 패턴 기반의 DBaaS를 설계했습니다. Flava DBaaS는 데이터베이스 비즈니스 로직과 IaaS 제어를 분리하고, 선언적 관리·자동화·일관된 사용자 경험을 제공하는 것을 목표로 합니다. 또한 DBaaS의 역할을 신규 데이터베이스 제공에 그치지 않고, 기존 플랫폼에서 Flava로의 원활한 마이그레이션까지 확장하고 있습니다. ## 쿠버네티스 오퍼레이터 기반의 선언적 DBaaS - 사용자가 원하는 데이터베이스의 상태를 커스텀 리소스(CR)로 선언하면, 컨트롤러가 실제 상태가 선언된 상태와 일치하도록 지속적으로 조정(reconcile)합니다. - 절차를 직접 지시하는 방식보다 운영 상태를 파악하기 쉽습니다. - 커스텀 리소스의 사양과 현재 상태 비교 - 컨트롤러 로그 및 이벤트 확인 - 문제 발생 원인 추적 - 이벤트 기반 컨트롤러이므로 대규모 데이터베이스 환경에서도 효율적으로 동작할 수 있습니다. - 쿠버네티스의 CI/CD, 권한 관리, API, 모니터링 등 생태계 기능을 활용할 수 있습니다. - 구현 난이도는 높지만, 장기적인 운영과 관리에는 유리합니다. ## 인프라 오퍼레이터를 통한 IaaS 추상화 - DBaaS는 여러 VM, 스토리지, 네트워크, 도메인 등 IaaS 자원을 조합해 데이터베이스 클러스터를 구성합니다. - DBaaS가 IaaS API와 호출 절차를 직접 처리하면 다음 문제가 발생합니다. - 인프라 제어 코드가 지나치게 많아짐 - 데이터베이스 운영 로직과 인프라 로직이 뒤섞임 - DBMS별 개발자가 IaaS 세부사항까지 이해해야 함 - Flava는 IaaS 자원을 인프라 오퍼레이터가 쿠버네티스 커스텀 리소스로 추상화하도록 구성했습니다. - 예를 들어 VM 생성 시 IaaS API를 직접 호출하지 않고, 다음과 같은 속성을 선언한 `server.yaml`을 작성한 뒤 `kubectl create -f server.yaml`로 리소스를 생성합니다. - 가용 영역 - 운영체제 이미지 - vCPU·메모리 등 서버 유형 - 계층은 다음과 같이 분리됩니다. - **DBaaS**: 데이터베이스 비즈니스 로직 담당 - **인프라 오퍼레이터**: IaaS를 쿠버네티스 리소스로 추상화 - **IaaS**: 컴퓨트·네트워크·스토리지 제공 - 이 구조를 통해 여러 DBMS가 IaaS 자원을 동일한 방식으로 사용하고, DBaaS 개발자는 DBMS별 기능에 집중할 수 있습니다. ## 커스텀 리소스와 세 가지 실행 컴포넌트 Flava에서 데이터베이스 클러스터 역시 쿠버네티스 커스텀 리소스로 표현됩니다. - 커스텀 리소스에는 다음과 같은 구성이 선언됩니다. - MySQL 버전 - VM 서버 사양 - 스토리지 종류와 용량 - 복제 멤버 수 - 리소스는 YAML 형태로 etcd에 저장되며 쿠버네티스 API를 통해 생성·조회·수정·삭제할 수 있습니다. DBaaS는 커스텀 리소스를 중심으로 API 서버, 매니저, 에이전트로 나뉩니다. - **API 서버** - 사용자와 UI, IaC 도구가 호출하는 REST API를 제공합니다. - 사용자의 요청을 DBaaS 커스텀 리소스 생성·수정·삭제 작업으로 변환합니다. - **매니저** - 커스텀 리소스의 변경을 감지하는 컨트롤러입니다. - 선언된 사양과 실제 클러스터 상태가 일치하도록 VM 생성, 구성 변경, 복제 설정 등을 조정합니다. - 인프라 오퍼레이터의 커스텀 리소스를 생성해 필요한 VM과 인프라를 준비합니다. - **에이전트** - 데이터베이스가 실행되는 VM 내부에서 동작합니다. - 운영체제 명령이나 데이터베이스 명령처럼 VM 내부에서 실행해야 하는 작업을 수행합니다. - MySQL 설치, 복제 구성, 프로비저닝 등 로컬 실행이 필요한 작업을 담당합니다. 예를 들어 MySQL 클러스터 생성 요청이 들어오면 API 서버가 MySQL 커스텀 리소스를 생성하고, 매니저가 필요한 VM을 만든 뒤, 에이전트가 VM 내부에서 MySQL과 복제 구성을 완료합니다. ## DBMS 지원과 확장성 개선 - Verda와 YNW에서 제공하던 DBMS를 통합해 Flava에서 지원하는 DBMS 종류를 확대했습니다. - 기존 사용자 만족도 조사와 운영 경험을 바탕으로 기능을 추가했습니다. - 스토리지를 100GiB 단위로 구성할 수 있어 용량 조정이 유연해졌습니다. - 블록 스토리지를 사용하는 DBMS는 최대 5TiB까지 지원합니다. - 기존에는 VM 로컬 디스크 용량이 하이퍼바이저의 VM 사양에 종속됐지만, Flava는 다음을 통해 제약을 줄였습니다. - 사용자 정의 인스턴스 유형 - VM과 분리된 블록 스토리지 - 확장된 최대 스토리지 용량 - 단일 VM의 저장공간 부족으로 샤딩을 검토해야 했던 사례를 줄일 수 있습니다. - 5TiB 제한은 대부분의 사용 사례를 충족하면서 블록 스토리지 측 서버 단편화를 방지하기 위한 설계 결정입니다. ## DBMS 전반의 통일된 사용자 경험 - 모든 DBaaS 상품에 공통 아키텍처와 UI·UX를 적용했습니다. - 한 DBMS에서 익힌 관리 방식으로 다른 DBMS도 사용할 수 있습니다. - MySQL에서 서버 사양을 변경한 경험을 Redis에도 적용 - Cassandra에서 설정한 모니터링 알람 방식을 MySQL에도 적용 - DBMS마다 별도의 사용법을 학습해야 하는 부담을 줄였습니다. - 플랫폼 차원에서 프로비저닝, 고가용성, 백업·복구, 확장성, 모니터링 같은 기본 기능을 제공합니다. ## 보안 및 편의 기능 강화 - DBaaS 기본 기능으로 다음 보안 기능을 제공합니다. - **TDE(Transparent Data Encryption)**: 저장 데이터 암호화 - **TLS(Transport Layer Security)**: 전송 구간 암호화 - **Custom DB Role** - 필요한 수준의 권한을 가진 데이터베이스 사용자를 생성·관리할 수 있습니다. - 정의한 역할을 재사용할 수 있습니다. - **Database Parameter Group** - 데이터베이스 파라미터를 원하는 값으로 관리할 수 있습니다. - 설정 그룹을 여러 클러스터에 재사용할 수 있습니다. - **Restore backup** - 특정 백업을 기반으로 새 데이터베이스 클러스터를 생성합니다. - 장애 복구뿐 아니라 실제 데이터가 필요한 성능 테스트 환경 구축에도 활용할 수 있습니다. - 일부 DBMS에서 아직 제공되지 않는 기능도 향후 확대할 예정입니다. ## 마이그레이션까지 포함하는 DBaaS의 책임 - 신규 DBaaS는 데이터베이스를 생성하는 기능만 제공해서는 충분하지 않습니다. - 기존 Verda·YNW 환경의 사용자가 Flava로 쉽게 이동할 수 있도록 마이그레이션 방법까지 제공해야 합니다. - 같은 DBMS 간 마이그레이션 방식은 크게 세 가지로 소개됩니다. ### 덤프 및 복구 - 소스 데이터베이스를 백업한 뒤 목적지 데이터베이스에 복구합니다. - 구현이 가장 단순합니다. - 데이터 정합성을 보장하려면 마이그레이션 중 애플리케이션 중단이 필요합니다. ### 실시간 복제 - DBMS 자체의 복제 기능으로 소스에서 목적지로 데이터를 실시간 복제합니다. - 복제가 완료되면 페일오버해 목적지 클러스터를 새로운 프라이머리로 전환합니다. - 이후 기존 소스 데이터베이스를 제거합니다. - 애플리케이션 중단을 최소화할 수 있지만, 프라이머리 전환 시 짧은 중단이 발생할 수 있습니다. - 데이터 정합성은 사용 중인 DBMS의 복제 메커니즘에 의존합니다. ## 실용적인 결론 Flava DBaaS의 핵심은 데이터베이스를 쿠버네티스 리소스로 선언하고, 인프라 오퍼레이터·매니저·에이전트가 실제 구성을 자동으로 맞추도록 만든 점입니다. 유사한 플랫폼을 설계할 때는 DBaaS와 IaaS의 책임을 분리하고, 공통 UI·보안·백업 기능을 플랫폼 수준에서 제공하며, 신규 기능뿐 아니라 기존 시스템의 마이그레이션 경로까지 함께 설계하는 것이 중요합니다.

원문 읽기(새 탭에서 열림)

쿠버네티스infrastructure-as-codemysqldatabase-migration+4

netflix·2026년 6월 22일·4분 읽기큐레이션 요약

넷플릭스는 Kueue로 배치 컴퓨팅을 어떻게 간소화했는가

Netflix는 기존 자체 배치 시스템인 CMB의 큐잉·스케줄링 기능을 Kubernetes 기반 오픈소스인 Kueue로 대체해 배치 컴퓨팅을 단순화했다. Kueue는 Titus의 기존 스케줄러를 유지하면서 멀티테넌트 용량 관리, 우선순위 큐, 선점, 공정 공유 등을 제공해 기능 확장과 Kubernetes 네이티브 전환을 지원했다. Netflix는 사용자 API와 경험을 그대로 유지한 채 수백만 개의 배치 작업을 이전했으며, 현재 Kueue를 프로덕션에서 완전히 운영하고 있다. ## CMB와 Titus의 기존 구조 - CMB(Compute Managed Batch)는 완료까지 실행되는 배치 작업을 제출·관리하는 Netflix의 관리형 서비스였다. - 작업은 테넌트 계층 구조에 따라 관리되며, 우선순위와 큐 순서에 따라 실행됐다. - Titus는 실제 작업 실행 플랫폼으로, 여러 Kubernetes 클러스터 또는 셀에 걸친 작업 배치와 용량 예약을 담당했다. - CMB는 단일 Titus 엔드포인트를 통해 클러스터 토폴로지를 직접 알지 않고도 작업과 용량 예약을 관리할 수 있었다. ## 테넌트 계층과 용량 관리 - **Internal Tenant** - 조직이나 애플리케이션 구조를 표현하기 위한 중간 노드다. - 직접 작업을 수용하지 않으며, 하위에 internal tenant나 leaf tenant를 둘 수 있다. - **Leaf Tenant** - 실제 작업을 제출할 수 있는 최종 테넌트다. - 큐를 가지며 하위 테넌트를 둘 수 없다. - **Reserved Capacity** - 내부 테넌트에서는 하위 트리 전체가 용량을 공정하게 공유한다. - 리프 테넌트에서는 특정 용량을 독점적으로 예약해 다른 테넌트가 해당 자원을 예약하지 못하도록 한다. - **Shared Capacity** - 모든 테넌트가 사용할 수 있는 전역 버스트 용량이다. - 기존 CMB에서는 작업이 승인된 뒤에는 선점되지 않았으므로, 이후 수요가 바뀌어도 작업이 끝까지 실행됐다. ## Kueue를 선택한 이유 - Kueue는 kube-scheduler를 대체하지 않으므로 Titus의 기존 스케줄링 프로파일과 통합할 수 있다. - YuniKorn이나 Volcano처럼 스케줄러 자체를 교체하면 작업 배치가 분산되어 효율이 저하될 수 있었다. - Kubernetes 생태계에서 빠르게 발전하고 있으며 채택 흐름도 강했다. - 서로 다른 하드웨어를 사용하는 환경에서 멀티테넌트 쿼터를 관리할 수 있다. - `v1.Pod`, `batch/v1.Job`뿐 아니라 RayJob, RayCluster 같은 고수준 리소스도 지원한다. - CMB에서 구현하기 어려웠던 기능을 기본 제공한다. - 선점(preemption) - 전체 작업 단위의 원자적 스케줄링(all-or-nothing scheduling) - 토폴로지 인지 스케줄링(topology-aware scheduling) ## Netflix Batch로의 마이그레이션 - 마이그레이션 프로젝트의 목표는 다음과 같았다. - CMB 사용자가 별도 작업을 하지 않아도 되는 투명한 이전 - 컨테이너 실행률과 전체 최대 처리량 유지 - CMB의 큐잉·스케줄링 로직을 Kueue로 대체 - 새로운 구조에서는 Kueue가 활성화된 Titus 셀에서 Kueue가 큐잉과 스케줄링을 담당한다. - Titus federation은 Netflix가 만든 Kueue router를 통해 작업을 적절한 Kueue 셀로 전달한다. - 운영자는 UI에서 테넌트의 마이그레이션 버튼을 누르는 것만으로 전환할 수 있으며, 문제가 발생하면 쉽게 롤백할 수 있었다. ## CMB 개념을 Kueue 리소스로 변환 - 기존 internal tenant는 Kueue의 **Cohort**로 변환됐다. - 기존 leaf tenant는 **ClusterQueue와 LocalQueue** 조합으로 변환됐다. - 테넌트의 용량 설정은 Kueue의 다음 개념으로 매핑됐다. - Resource Flavor - Nominal Quota - 이 구조를 통해 기존의 테넌트 계층과 용량 정책을 유지하면서 실제 큐 관리는 Kueue에 위임했다. ## 마이그레이션 과정에서 얻은 교훈 - 기존 API를 유지하고 내부 구현부터 교체하면 고객 경험을 바꾸지 않고 위험을 단계적으로 줄일 수 있다. - 가장 복잡한 사용 사례를 마지막으로 미루지 않는 것이 중요했다. - Netflix는 가장 크고 복잡한 고객을 초기에 이전했다. - 이를 통해 다른 고객의 이전 가능성을 검증했고, 실제 프로덕션 마이그레이션은 4주 만에 완료됐다. - 기본 설정만으로는 Netflix의 처리량을 감당할 수 없었다. - Kueue의 QPS, burst, `groupKindConcurrency` 값을 기본값보다 크게 조정해야 했다. - Titus와 유사한 개발 환경에서 부하 테스트를 일찍 수행해 성능 위험을 사전에 확인했다. ## 현재 운영 상태와 향후 방향 - Kueue는 Netflix 프로덕션에 완전히 배포되어 수백만 개의 배치 작업을 관리하고 있다. - Netflix는 더 많은 Titus 배치 작업을 Kueue 기반의 관리형 환경으로 편입할 계획이다. - 예약 용량 활용률을 높이기 위해 공정 공유와 선점 기능도 프로덕션 수준으로 확장했다. - 이러한 경험은 Kubernetes 네이티브 학습·트레이닝 인프라를 구축하는 다른 내부 팀의 작업 큐와 스케줄링 설정에도 활용되고 있다. Netflix의 사례는 기존 사용자 인터페이스와 실행 플랫폼을 유지하면서 큐잉 계층만 검증된 Kubernetes 구성 요소로 교체한 점이 핵심이다. 대규모 시스템에서는 한 번에 모든 것을 재작성하기보다 API 호환성, 단계적 전환, 조기 부하 테스트, 손쉬운 롤백을 함께 설계하는 접근이 실용적이다.

원문 읽기(새 탭에서 열림)

쿠버네티스container-orchestrationmulti-tenancykueue+4

line·2026년 6월 22일·5분 읽기큐레이션 요약

코드형 인프라(IaC)로 자동화에서 AI까지: OpenTofu와 ChatOps 도입기

LY Corporation의 LINE Plus SRE 팀은 운영 인프라를 콘솔·스크립트·문서가 아닌 OpenTofu와 Terragrunt 기반의 IaC로 통합했다. 약 1,500개 리소스를 GitOps 방식으로 관리하며, 모든 변경을 PR 리뷰와 CI/CD를 거치게 하고 실제 인프라와 코드의 차이도 자동 감지한다. 핵심은 기존 운영 리소스를 안전하게 import하고, 리소스별 특성과 의존 관계를 반영해 코드·state·실제 인프라를 일치시키는 것이다. ## 운영 규모 확대로 드러난 기존 방식의 한계 - 팀마다 Verda 대시보드, 자체 스크립트, 위키 매뉴얼 등 서로 다른 방식으로 인프라를 관리했다. - 설정 정보도 위키, 개인 문서, GitHub 등 여러 곳에 분산되어 있었다. - 서비스와 리소스가 늘어나면서 다음 문제가 누적됐다. - 변경 이력과 변경 주체를 일관되게 추적하기 어려움 - 동일한 작업을 반복 수행할 때 실수 가능성 증가 - 환경별 설정 차이와 실제 인프라 상태를 파악하기 어려움 - 변경 전 검토와 변경 후 검증이 체계적이지 않음 - 이를 해결하기 위해 인프라의 원하는 상태를 코드로 선언하고, 변경을 자동화·표준화할 필요가 생겼다. ## GitOps로 인프라를 애플리케이션 코드처럼 관리 - 인프라 설정을 Git 저장소에 선언하고 모든 변경을 PR로 진행한다. - 코드 리뷰, CI/CD, 변경 이력 관리 등 애플리케이션 개발 방식을 인프라에도 적용한다. - 콘솔에서 직접 클릭하거나 SSH로 수정하는 방식 대신 다음 흐름을 사용한다. - Git에 코드 변경 - PR 리뷰 - CI/CD를 통한 plan 및 적용 - 실제 인프라와 선언된 상태의 차이 자동 감지 - IaC의 목표는 단순한 자동화가 아니라 인프라를 다음과 같은 엔지니어링 산출물로 만드는 것이다. - 리뷰 가능 - 버전 관리 가능 - 재현 가능 - 변경 이력 추적 가능 ## OpenTofu와 Terragrunt 선택 - **OpenTofu** - Terraform의 오픈소스 포크다. - 기존 Terraform과 동일한 HCL 문법과 프로바이더 호환성을 유지한다. - 기존 Terraform 기반 작성 방식과 모듈 구조를 재사용하기 쉬워 학습 비용이 낮다. - **모듈화** - VM, 로드밸런서, 모니터링 알림 등을 공통 모듈로 분리했다. - 팀별로 모듈에 입력값만 전달해 동일한 구조의 인프라를 생성할 수 있다. - 모듈은 버전으로 관리하며, 새 버전은 필요한 환경에서만 명시적으로 올린다. - **Terragrunt** - OpenTofu의 환경 구성 중복을 줄이는 래퍼다. - 공통 설정은 상위 `root.hcl`에 정의한다. - 각 환경에는 서로 다른 입력값만 남긴다. - 결과적으로 OpenTofu 모듈은 리소스 정의 중복을, Terragrunt는 환경별 설정 중복을 줄였다. ## 기존 리소스의 단계적 IaC 전환 - 이미 운영 중인 약 300대의 VM, 160개의 LB, 350개의 DNS 레코드를 코드 관리 체계로 옮겨야 했다. - 리소스를 하나씩 수동 import하면 시간이 오래 걸리고 실수 가능성이 높기 때문에 자동화된 import 스크립트를 작성했다. - 전환은 두 단계로 진행했다. - **1단계:** 한 서비스를 선정해 import, 모듈, Terragrunt, CI/CD 전체 파이프라인을 검증 - **2단계:** 검증된 모듈과 import 스크립트를 나머지 서비스에 확산 - 운영 중인 인프라에 영향을 주지 않는 것이 가장 중요한 원칙이었다. ## import 스크립트의 표준 흐름 import 스크립트는 다음 과정을 공통 흐름으로 삼았다. - 현재 클라우드 리소스를 조회한다. - IaC로 관리할 대상과 제외할 대상을 구분한다. - 모듈 구조에 맞게 설정을 변환하고 Terragrunt 파일을 생성한다. - 실제 리소스를 OpenTofu state에 연결한다. - `plan` 결과를 확인해 불필요한 변경이 없는지 검증한다. 특히 다음 세 요소를 일치시키는 데 집중했다. - 코드에 선언된 값 - OpenTofu state 파일의 연결 정보 - 실제 클라우드 리소스의 상태 ## import 후 정규화와 가짜 변경 제거 - import를 완료해도 코드, state, 실제 리소스의 값 표현이 다르면 `plan`에서 계속 변경 사항이 나타날 수 있었다. - 예를 들어 네트워크 ID나 이미지 ID가 같은 대상을 가리키더라도 표현 방식이 다를 수 있다. - 이를 방치하면 `plan` 결과를 신뢰하기 어려워지므로 import 후 정규화 과정을 추가했다. - 정규화의 목적은 다음과 같다. - 동일한 리소스를 표현하는 값의 형식 통일 - 불필요한 diff 제거 - 실제 변경과 표현 차이에 따른 가짜 변경 구분 ## 리소스 특성에 따른 개별 import 전략 모든 리소스를 동일한 방식으로 가져올 수 없었기 때문에 리소스 유형과 의존 관계에 따라 import 단위를 달리했다. - **VM** - 개별 인스턴스를 기준으로 import한다. - **로드밸런서** - LB뿐 아니라 리스너와 풀 등 함께 동작하는 하위 리소스를 고려한다. - **DNS** - 존과 레코드의 관계를 유지한다. - **쿠버네티스** - 클러스터와 노드 풀을 어떤 단위로 관리할지 결정한다. - **IMON 알림** - 팀 → 알림 그룹 → 알림 규칙 → 알림 모니터의 계층 관계를 보존한다. - IMON 리소스는 실제 구조와 유사하게 디렉터리를 구성해 소속 관계를 쉽게 확인할 수 있도록 했다. ## 운영 리소스와 자동 생성 리소스의 구분 - OpenStack에는 사람이 만든 VM과 쿠버네티스가 자동으로 만든 VM이 함께 존재했다. - 두 리소스는 외형상 비슷하지만 관리 주체가 다르다. - 쿠버네티스가 관리하는 VM까지 IaC로 가져오면 클러스터의 기대 상태와 OpenTofu 관리 상태가 충돌할 수 있다. - 따라서 네이밍 패턴과 메타데이터를 기준으로 쿠버네티스 생성 VM을 import 대상에서 제외했다. - 모든 리소스를 무조건 코드화하는 것이 아니라, 관리 주체와 생명주기를 먼저 판단하는 것이 중요했다. ## 프로바이더와 리전 차이 해결 - 실제 클라우드와 OpenTofu 프로바이더의 검증·백엔드 동작이 완전히 일치하지 않는 문제도 발견됐다. - **LB 이름의 하이픈·언더스코어 충돌** - 클라우드는 `-`와 `_`를 모두 허용했다. - 그러나 프로바이더 백엔드의 검증 로직은 `_`를 허용하지 않았다. - 기존 LB를 import할 때 오류가 발생했다. - 프로바이더의 validation 로직을 수정해 해결하고, 해당 변경을 프로바이더에 기여했다. - **리전별 UUID 불일치** - 리전마다 `flavor_id`, `image_id`, `network_id`가 달랐다. - import 이후 `plan`에서 실제 변경이 아닌 불필요한 diff가 반복됐다. - 사용자는 사람이 읽기 쉬운 이름을 입력하고, 모듈이 리전별 실제 UUID로 변환하도록 매핑 로직을 추가했다. - 이 방식으로 코드 가독성을 높이고 가짜 변경을 줄였다. ## 실용적인 적용 시사점 - 기존 인프라를 IaC로 전환할 때는 단순히 import 명령을 실행하는 것보다 리소스 분류, 정규화, 의존 관계 분석이 중요하다. - 먼저 하나의 서비스에서 전체 프로세스를 검증한 뒤 다른 서비스로 확산하는 방식이 안전하다. - 자동 생성 리소스는 관리 주체가 다르므로 무조건 import하지 않아야 한다. - 프로바이더가 실제 클라우드의 모든 기존 상태를 완벽히 표현하지 못할 수 있으므로, import 후 반드시 `plan` 검증과 예외 처리가 필요하다. - 최종적으로 IaC의 효과는 코드 작성 자체보다 PR 리뷰, 자동 배포, 상태 차이 감지까지 포함한 운영 프로세스 전체를 표준화하는 데 있다.

원문 읽기(새 탭에서 열림)

쿠버네티스CI/CDinfrastructure-as-codegitops+3

toss·2026년 6월 19일·6분 읽기큐레이션 요약

Spark Connect on Kubernetes #1: 견고한 Spark Connect 만들기

토스증권은 여러 사용자가 안정적으로 사용할 수 있는 Production급 Spark Connect를 Kubernetes에서 운영하고 있습니다. Spark Connect는 Driver를 애플리케이션마다 실행하는 대신 장기 실행 서버로 분리해 가벼운 클라이언트와 빠른 세션 생성을 제공하지만, 여러 세션이 하나의 SparkContext를 공유하면서 장애 전파와 리소스 경합 문제가 발생합니다. 이를 해결하기 위해 글로벌 장애 카운터를 사실상 비활성화하고, 결과 크기를 제한하며, 여러 Replica로 Driver와 SparkContext를 분리하는 전략을 사용합니다. ## Classic Spark의 구조와 Spark Connect의 등장 - Spark는 작업을 계획·지휘하는 **Driver**와 실제 연산을 수행하는 **Executor**로 구성됩니다. - Classic Spark의 배포 방식은 다음과 같습니다. - **Client mode**: 클라이언트 프로세스가 Driver 역할을 수행합니다. - **Cluster mode**: 작업 제출 시 클러스터에 Driver가 생성되고 작업 종료 후 사라집니다. - 두 방식 모두 애플리케이션마다 Driver가 하나씩 생성되고, 애플리케이션의 수명과 함께 종료됩니다. - Spark Connect는 Spark 3.4부터 도입됐으며, 4.0에서는 기존 Dataset/DataFrame API와 거의 동등한 수준에 도달했습니다. - 글의 구현과 설정은 Spark 4.1을 기준으로 합니다. ## Spark Connect의 동작 방식 - Spark Connect에서는 Driver를 애플리케이션별 프로세스가 아니라 **미리 실행해 둔 서버**로 운영합니다. - 클라이언트는 Spark 라이브러리와 JVM을 직접 포함하지 않는 Thin Client입니다. - 클라이언트의 DataFrame·SQL 연산은 다음 과정으로 처리됩니다. - 연산을 Unresolved Logical Plan으로 변환 - Protocol Buffer로 인코딩 - gRPC를 통해 서버로 전송 - 서버가 분석, 최적화, 스케줄링, 실행 수행 - 결과를 Arrow 기반으로 클라이언트에 스트리밍 - 구조적으로는 JDBC 클라이언트가 데이터베이스 서버에 질의하는 모델과 유사합니다. ## Spark Connect의 장점 - 클라이언트에 무거운 Spark 의존성이나 JVM이 없어도 됩니다. - Python, SQL, 노트북, BI 도구 등 다양한 클라이언트가 같은 서버에 접속할 수 있습니다. - Driver가 이미 실행 중이므로 매번 프로세스를 생성하고 리소스를 협상할 필요가 없습니다. - 클라이언트가 종료되거나 네트워크가 끊겨도 서버에서 실행 중인 작업은 보호할 수 있습니다. - 반면 하나의 장기 실행 서버에 여러 사용자가 접속하면서, Spark의 기존 “애플리케이션 하나에 워크로드 하나”라는 전제가 깨집니다. ## 공유 Driver가 만드는 단일 장애점 - 여러 세션이 하나의 SparkContext와 Driver JVM을 공유합니다. - Driver가 장애를 일으키면 해당 서버의 모든 세션, 실행 중인 Job, 캐시가 함께 사라집니다. - `spark.executor.maxNumFailures`는 Executor 실패를 애플리케이션 전체 단위로 누적합니다. - 기본 임계값은 `max(3, 2 × executor 수)`입니다. - 임계값을 초과하면 `stopApplication()`이 호출되고, 결과적으로 `sys.exit(11)`로 서버 전체가 종료됩니다. - 이 카운터는 다음 이유로 멀티세션 환경에서 위험합니다. - 개별 쿼리의 Task 실패가 아니라 Executor 실패를 전역적으로 집계합니다. - 시간이 지나도 실패 기록이 계속 누적됩니다. - 서로 다른 사용자의 실패가 합산됩니다. - 문제가 없는 세션도 장애를 함께 겪게 됩니다. ## 세션 격리와 리소스 경합의 한계 - `newSession()`은 SQL 네임스페이스 등 세션 상태만 분리합니다. - CPU, 메모리, Executor, Task 슬롯은 모든 세션이 공유합니다. - 한 사용자가 대규모 Job을 제출하면 다른 사용자의 쿼리 응답도 느려질 수 있습니다. - 기본 FIFO 스케줄링에서는 먼저 제출된 작업이 우선하며, 선점이 없어 이미 실행 중인 Task를 중단할 수 없습니다. - Fair Scheduler를 사용해도 Task 슬롯을 배분하는 순서만 조정할 뿐, 사용자별 CPU·메모리 격리는 제공하지 않습니다. - Spark Connect에서는 `spark.scheduler.pool`이 기본적으로 제대로 전파되지 않아 모든 쿼리가 Default Pool에 들어갑니다. - Classic Spark에서는 `setLocalProperty()`가 Driver 스레드에 직접 적용됩니다. - Spark Connect에서는 클라이언트와 Driver가 분리되어 서버의 요청 처리 스레드에 값을 별도로 설정해야 합니다. - 토스증권은 서버 스레드에 사용자별 Pool을 직접 설정하는 방식으로 이 문제를 보완했습니다. - 사용자별 Pool을 적용하려면 먼저 요청의 사용자를 식별해야 하며, 인증·인가와 연결됩니다. - 궁극적인 CPU·메모리 격리는 Spark 스케줄러가 아니라 Spark 외부의 리소스 관리 계층에서 해결해야 합니다. ## 고정된 서버 스케일 문제 - Spark Connect 서버는 이미지, Driver·Executor 리소스, Spark 설정이 고정된 상태로 실행됩니다. - Dynamic Resource Allocation으로 Executor 수는 조절할 수 있지만, 서버 자체의 기본 스펙은 실행 중 바뀌지 않습니다. - 서버를 필요에 따라 생성·교체하거나 팀 단위로 격리하는 문제는 후속 글에서 다룹니다. ## 글로벌 장애 카운터 비활성화 - 서버 전체를 종료시키는 Executor 실패 경로를 차단하기 위해 다음과 같이 설정합니다. - `spark.executor.maxNumFailures`: 사실상 무한대로 설정해 글로벌 종료 조건을 비활성화 - `spark.executor.failuresValidityInterval`: 오래된 실패 기록을 주기적으로 제거 - `spark.task.maxFailures`: 동일 Task의 반복 실패를 제한 - `spark.stage.maxConsecutiveAttempts`: Shuffle Fetch 실패로 Stage가 반복 실행되는 상황을 제한 - `task.maxFailures`는 OOM이나 예외처럼 동일 Task가 반복 실패하는 경우를 담당합니다. - `stage.maxConsecutiveAttempts`는 Shuffle Fetch 실패로 Stage 전체가 반복되는 경우를 담당합니다. - 이 방식으로 문제가 있는 쿼리만 실패시키고 서버와 다른 사용자의 세션은 유지할 수 있습니다. - 다만 실패 허용 횟수를 지나치게 낮추면 일시적인 장애에도 정상 쿼리가 실패할 수 있으므로 워크로드에 맞춰 여유를 둬야 합니다. ## Driver 메모리 보호와 결과 크기 제한 - Spark Connect에서는 쿼리 결과가 Driver를 거쳐 클라이언트로 스트리밍됩니다. - 사용자가 대규모 테이블을 `collect`하면 Driver 메모리가 고갈될 수 있습니다. - `spark.driver.maxResultSize`는 한 액션에서 반환되는 Task 결과의 누적 크기를 제한합니다. - 제한을 초과하면 Driver가 결과를 모두 가져오기 전에 Job을 중단하므로, 대규모 결과가 Driver 메모리에 유입되는 것을 막을 수 있습니다. - 기본값인 1GB는 애플리케이션 하나만 실행하는 환경의 값이므로, 여러 세션이 동시에 결과를 가져가는 멀티세션 서버에서는 더 보수적으로 설정해야 합니다. - 이 설정만으로 Driver OOM이나 노드 장애까지 막을 수는 없습니다. ## 여러 Replica를 통한 장애 영향 축소 - Driver 자체의 OOM이나 노드 소실처럼 설정으로 막을 수 없는 장애에 대비해 Spark Connect 서버를 여러 Replica로 구성합니다. - 각 Replica는 독립적인 다음 요소를 갖습니다. - SparkContext - Driver - Executor - 한 Replica가 장애로 종료되어도 장애 범위가 해당 Replica에 한정되고, 다른 Replica가 새로운 세션 요청을 처리할 수 있습니다. - 단일 서버의 장애가 Spark Connect 전체로 확산되는 구조를 여러 독립 실행 단위로 나누는 것이 핵심입니다. ## 실용적인 운영 방향 - 멀티세션 Spark Connect에서는 전역 장애 카운터를 그대로 두지 말고, Task·Stage·Job 단위의 실패 제한으로 문제 쿼리를 격리하는 것이 안전합니다. - `spark.driver.maxResultSize`를 동시 세션 수와 쿼리 특성에 맞게 보수적으로 설정해야 합니다. - 스케줄러 Pool만으로는 CPU·메모리 격리가 불가능하므로, 강한 격리가 필요하면 Replica나 Kubernetes 리소스 정책을 활용해야 합니다. - 단일 Driver를 그대로 공유하기보다 여러 Replica를 운영해 장애의 영향 범위를 줄이는 것이 Production 환경에 적합합니다.

원문 읽기(새 탭에서 열림)

쿠버네티스apache-sparkgrpcfault-tolerance+4

aws·2026년 6월 18일·3분 읽기큐레이션 요약

NVIDIA RTX PRO 4500 Blackwell 서버 에디션 GPU로 가속되는 Amazon EC2 G7 인스턴스 발표 | Amazon Web Services

Amazon EC2 G7은 NVIDIA RTX PRO 4500 Blackwell Server Edition GPU와 6세대 Intel Xeon 프로세서를 결합한 GPU 인스턴스다. G6 대비 AI 추론 성능은 최대 4.6배, 그래픽 성능은 최대 2.1배 향상됐으며, 네트워크·스토리지·영상 처리 성능도 크게 개선됐다. AI 추론, 그래픽 렌더링, 영상 변환, VDI, 공간 컴퓨팅, 데이터 분석 등에 적합하다. ## NVIDIA Blackwell GPU 기반 성능 향상 - AWS 최초로 NVIDIA RTX PRO 4500 Blackwell Server Edition GPU를 지원한다. - GPU당 32GB 메모리를 제공하며, 인스턴스당 최대 8개 GPU와 총 256GB GPU 메모리를 구성할 수 있다. - G6 대비 GPU 메모리 용량은 1.33배, 메모리 대역폭은 2.45배 향상됐다. - 5세대 Tensor Core와 4세대 RT Core를 탑재해 AI 추론과 실시간 그래픽 처리를 가속한다. - G6 대비 AI 추론 성능은 최대 4.6배, 그래픽 성능은 최대 2.1배 높다. ## 네트워크와 로컬 스토리지 개선 - EFA(Elastic Fabric Adapter)를 지원하는 최대 700Gbps 네트워크 대역폭을 제공한다. - G6 대비 네트워크 처리량이 7배 증가해 다중 GPU·다중 노드 AI 및 분석 작업에 유리하다. - 최대 7.6TB의 로컬 NVMe SSD를 사용할 수 있다. - 대규모 모델과 데이터셋을 컴퓨팅 자원 가까이에 저장해 데이터 전송 지연과 처리 오버헤드를 줄인다. - 다중 GPU 환경에서는 NVIDIA GPUDirect P2P를, GPU와 네트워크·스토리지 간 통신에는 GPUDirect RDMA와 EFA를 지원한다. ## 영상 인코딩·디코딩 성능 - 9세대 NVENC와 6세대 NVDEC 엔진을 탑재했다. - 고해상도 영상 작업에 필요한 4:2:2 인코딩과 디코딩을 지원한다. - 동시 처리 가능한 영상 스트림 수가 G6 대비 1.5배 증가했다. - 영상 트랜스코딩, 스트리밍, 미디어 분석과 같은 작업에 적합하다. ## 인스턴스 구성 - 총 7개 크기로 제공된다. - 최대 사양: - NVIDIA RTX PRO 4500 GPU 8개 - GPU 메모리 256GB - vCPU 192개 - 시스템 메모리 768GiB - 네트워크 대역폭 700Gbps - 로컬 NVMe SSD 7.6TB - 12xlarge, 24xlarge, 48xlarge 크기는 Dedicated Instances도 지원한다. ## 지원 소프트웨어와 운영 환경 - AWS Deep Learning AMI와 NVIDIA Workstation AMI를 통해 사전 구성된 GPU 드라이버를 사용할 수 있다. - Amazon EKS에서 사용하려면 NVIDIA 드라이버 R595와 EKS 자동화 기능을 이용해 AMI를 구성해야 한다. - Amazon Linux, Ubuntu, RHEL, Windows Server를 지원한다. - DirectX, Vulkan, OpenGL 등 주요 그래픽 라이브러리와 호환된다. - Amazon EMR on EKS에서 GPU 가속 데이터 분석에도 활용할 수 있다. ## 제공 지역과 구매 방식 - 발표 시점에는 미국 동부 오하이오와 미국 서부 오리건 리전에서 사용할 수 있다. - 향후 리전 확대 여부는 AWS Capabilities by Region 페이지에서 확인할 수 있다. - On-Demand, Savings Plans, Spot Instances 방식으로 구매 가능하다. - 자세한 요금은 Amazon EC2 요금 페이지에서 확인해야 한다. G7은 GPU 메모리와 네트워크 대역폭이 중요한 AI 추론, 대규모 그래픽 처리, 영상 처리 및 분산 분석 작업에 특히 적합하다. 기존 G6에서 GPU·네트워크 병목을 겪고 있다면, 사용 리전과 실제 워크로드별 비용 대비 성능을 비교한 뒤 G7으로 이전하는 것이 좋다.

원문 읽기(새 탭에서 열림)

쿠버네티스AWSamazon-ec2gpu-acceleration+4

gitlab·2026년 6월 17일·3분 읽기큐레이션 요약

2026년 EMEA GitLab 파트너 어워드 수상자 소개

GitLab은 2026년 EMEA 지역에서 DevSecOps와 AI 기반 소프트웨어 개발 혁신에 기여한 파트너들을 선정해 시상했다. 수상 기업들은 클라우드·DevOps 전문성, 기술 솔루션 구현, GitLab 인증 인력, 신규 고객 확보, 공동 마케팅 등 다양한 분야에서 성과를 인정받았다. 이번 시상은 GitLab이 파트너 생태계와 협력해 고객의 소프트웨어 현대화와 AI 도입을 확대하고 있음을 보여준다. ### 지역별 올해의 파트너 - **중부 유럽: cc cloud GmbH** - 클라우드 애플리케이션과 플랫폼을 위한 인프라 및 DevOps 전문 기업이다. - 관리형 서비스 제공업체로서 고객사의 IT 인프라와 애플리케이션 운영을 맡아 고객이 핵심 사업에 집중하도록 지원한다. - **북유럽: Eficode** - 유럽과 북미에서 1,600개 이상의 고객사를 보유한 소프트웨어 개발 생명주기 전문 기업이다. - 관리형 서비스, 컨설팅, 툴체인 구축, AI 기반 개발 방식을 통해 엔터프라이즈의 소프트웨어 제공 속도를 높인다. - **남유럽: Kiratech** - 클라우드 네이티브, DevOps, PlatformOps를 활용해 대기업의 인프라 현대화를 지원하는 이탈리아 기업이다. - GitLab 공식 리셀러이자 Select 파트너 및 구현 파트너로 활동한다. - **동유럽 및 이스라엘: Bynet** - 40년 이상의 경험을 가진 이스라엘의 시스템 통합업체다. - 엔터프라이즈 IT, 클라우드, 사이버 보안, 현대화 프로젝트를 수행하며 정부 및 민간 부문의 DevSecOps와 AI 도입을 지원한다. ### 가장 뛰어난 기술 솔루션·프로젝트 - **Capgemini의 Sogeti** - 품질 엔지니어링, 데이터, 클라우드 분야에서 AI 기반 솔루션을 제공한다. - 복잡한 기술 아이디어를 빠르게 실행하고, 초기부터 측정 가능한 고객 성과를 창출한 점을 인정받았다. ### 인증 및 역량 강화 부문 - **Devoteam** - 30년간 기업의 기술 변화와 디지털 전환을 지원해 온 AI 중심 기술 컨설팅 기업이다. - 팀 내 GitLab 인증 전문가 수가 가장 많은 파트너로 선정됐다. ### 신인상과 신규 사업 개발 - **Rookie of the Year: ITDOTCOM** - 우즈베키스탄 기반의 부가가치 IT 유통업체다. - 소프트웨어 개발, 인프라, 사이버 보안, 업무 자동화 솔루션을 제공하며 중앙아시아 시장에서 글로벌 기술 공급업체와 현지 파트너의 확장을 돕는다. - **First Order Master: Linux Polska** - 오픈소스 솔루션과 엔터프라이즈 컨설팅을 제공하는 기업이다. - DevOps, 자동화, 컨테이너화, 데이터 분석 역량을 바탕으로 신규 고객 확보와 반복적인 신규 사업 수주에서 성과를 냈다. ### 공동 마케팅 협력 - **Conoa, PROACT 계열사** - Kubernetes, 클라우드 네이티브, 컨테이너 기술 전문 기업이다. - 전략 수립과 컨설팅부터 관리형 플랫폼 운영까지 제공하며, Kubernetes Certified Service Provider 자격을 보유하고 있다. - 규제가 엄격한 산업을 포함한 다양한 분야에서 GitLab과 공동 마케팅을 전개해 인지도와 성장을 높인 점을 평가받았다. 이번 수상 기업들은 단순한 제품 판매보다 클라우드 네이티브 전환, DevSecOps 구현, AI 활용, 운영 서비스, 기술 인력 양성 등 고객의 실제 현대화 과정을 폭넓게 지원한 파트너들이다. 기업이 GitLab 도입을 검토한다면 지역별 산업 경험, 구현 역량, 인증 전문가 수, 관리형 서비스 제공 여부를 파트너 선정 기준으로 삼는 것이 유용하다.

원문 읽기(새 탭에서 열림)

쿠버네티스AIgitlabDevSecOps+4

google·2026년 6월 12일·4분 읽기큐레이션 요약

사용하지 않는 휴대폰으로 만드는 저탄소 컴퓨팅 플랫폼

사용이 끝난 스마트폰의 메인보드를 모아 클러스터로 구성하면, 새 서버 제조를 줄이면서 저비용·저탄소 클라우드 컴퓨팅 플랫폼으로 재활용할 수 있다. UC 샌디에이고와 Google은 2,000대의 Pixel 스마트폰으로 데이터센터를 구축해 교육·연구용 컴퓨팅을 제공할 계획이다. 이 방식은 스마트폰의 제한된 메모리와 코어 수에 맞는 작업을 선별하고, 대규모 배포에서 소비자용 하드웨어의 신뢰성을 검증하는 것을 목표로 한다. ## 컴퓨팅의 탄소 배출과 스마트폰 재활용 - 컴퓨팅의 탄소발자국은 크게 두 가지다. - **운영 탄소**: 기기 사용 중 소비되는 전력에서 발생하는 배출량 - **내재 탄소**: 하드웨어 제조와 원자재 추출 과정에서 발생하는 배출량 - 전력 효율 향상과 재생에너지 사용으로 운영 탄소는 줄일 수 있지만, 제조 과정의 내재 탄소는 해결이 더 어렵다. - 사람들은 평균 4년마다 스마트폰을 교체하지만, 교체된 기기에도 프로세서, 가속기, 메모리, 저장장치 등 핵심 컴퓨팅 기능이 남아 있다. - 기존 스마트폰을 재사용하면 새 하드웨어 생산과 추가적인 원자재 채굴을 피할 수 있다. ## 스마트폰과 서버의 성능 차이 - 2023년형 Pixel Fold의 고성능 코어는 SPEC 벤치마크에서 일부 최신 데이터센터 서버의 단일 코어 성능을 웃돈다. - 다만 스마트폰은 서버보다 다음과 같은 제약이 있다. - 코어 수가 적고 CPU 구성이 이기종임 - 메모리가 약 8~12GB로 제한됨 - 서버처럼 대규모 멀티스레드 처리나 대용량 메모리를 제공하지 못함 - 따라서 하나의 스마트폰에 들어갈 수 있거나, 여러 기기로 분할할 수 있는 작업이 적합하다. - 벤치마크상 약 25~50대의 스마트폰이 현대적인 서버 한 대에 해당하는 성능을 낼 수 있다. ## 스마트폰을 데이터센터 하드웨어로 개조 - 소비자용 스마트폰을 그대로 데이터센터에 배치하면 비효율적이고 위험하다. - 디스플레이, 배터리, 카메라, 케이스 등 서버에 필요 없는 부품이 공간을 차지함 - 특히 배터리는 데이터센터 환경에서 장시간 사용하기에 적합하지 않을 수 있음 - 따라서 메인보드만 분리해 클러스터에 사용한다. - 메인보드는 스마트폰 내재 탄소의 약 50%를 차지하는 가장 중요한 부품이므로, 이를 재사용하는 것이 환경적 효과가 크다. - Android 기반의 모바일 사용자 공간은 범용 Linux 배포판으로 교체한다. - 클라우드 작업에 필요한 프로그래밍 환경을 제공함 - 모바일 기기용 보호 기능을 제거하거나 조정할 수 있음 - 예를 들어 메모리 부족 시 애플리케이션을 종료하는 ‘Low Memory Killer’의 영향을 줄일 수 있음 - 컨테이너화된 애플리케이션을 Kubernetes로 관리해 25~50대 단위의 자기관리형 클러스터를 구성한다. ## 교육·연구용 저탄소 클라우드 - 대학에서 사용하는 Jupyter 환경, 과제 채점 시스템, 병렬 계산 수업용 애플리케이션 상당수는 스마트폰 한 대 또는 소규모 클러스터로 처리할 수 있다. - 일반적인 과제 채점 백엔드는 AWS t3.micro 수준인 2 vCPU·1GB 메모리 인스턴스에서도 실행된다. - 20대 스마트폰 클러스터를 이용한 실험에서: - 75명 이상 수강하는 수업의 최대 과제 제출량을 처리함 - 일반적인 AWS 백엔드보다 낮은 채점 지연 시간을 기록함 - 약 50초가 걸리는 CPU 집약적 행렬 곱셈 과제도 처리 가능했음 - 2,000대 규모의 클러스터는 약 50대의 서버에 해당하는 컴퓨팅 자원을 제공하고, 동시에 약 100개 수업을 지원할 수 있을 것으로 예상된다. - 2026년 가을 전체 시스템 운영을 시작할 계획이다. ## 대규모 운영에서 검증할 과제 - 소비자용 스마트폰 메인보드를 장기간 데이터센터 부하로 사용할 때의 신뢰성을 검증해야 한다. - 다수 기기의 장애를 감지하고 작업을 재분배하는 클러스터 관리가 중요하다. - 제한된 메모리와 이기종 코어 구조에 맞도록 애플리케이션을 설계해야 한다. - 이 프로젝트는 실제 교육·연구 서비스를 제공하는 동시에 스마트폰 기반 컴퓨팅의 확장성과 지속 가능성을 시험하는 테스트베드 역할을 한다. 사용이 끝난 스마트폰은 서버 전체를 대체하기보다는 교육, 과제 채점, 소규모 웹 서비스처럼 자원 요구량이 제한적인 작업에 재활용하는 것이 현실적이다. 특히 메인보드 재사용과 컨테이너·Kubernetes 기반 클러스터 관리를 결합하면 비용 절감과 제조 탄소 감축을 동시에 달성할 가능성이 있다.

원문 읽기(새 탭에서 열림)

쿠버네티스Android분산 시스템클라우드 컴퓨팅+4