레이블이 cloud인 게시물을 표시합니다. 모든 게시물 표시
레이블이 cloud인 게시물을 표시합니다. 모든 게시물 표시

cloudflare down

2025-11-18 cloudflare down
cloudflare 인프라를 사용하는 chatgpt, perplexity, cluade...등이 접속이 안된다.
이와중에 자체 인프라를 사용하는 구글의 gemini 는 잘된다.

구글은 자체 인프라가 있지만 나머지는 그렇지 못하다.
작은 회사가 급성장하면서 유명해지고 수십조를 벌었지만 수십년간 쌓아온 구글의 인프라는 짧은 시간에 채워넣을 수 없고 그래서 cloudflare 라는 회사도 같이 클 수 있었다.
어쩌면 당연한 흐름이고 이걸 탓하면 안될것 같다.

이번과 같은 인프라/클라우드로 전세계 패닉 사건은 최근 몇년간 꽤 심심치 않게 본다.


모든 것들이 클라우드로 서비스되면서 아주 커다란 크루즈에 올라탄 공동운명체가 된것 같다.
크루즈는 화려하고 편하고 좋지만 한번 사고나면 생각만해도 끔직하다.
클라우드로 대세화 되는건 거대한 흐름이지만 클라우드는 점점 더 많은 서비스가 생기고 복잡해진다.
20년전인가 암튼 오래전 클라우드라는 단어가 떠오르던 초창기만 하더라도 사내에서 원격 접속해서 사용하는 베어메탈 서버에 사원들이 각자 자기의 계정을 만들어 접속하는 형태였다.
그리고 자신의 계정에서 서비스를 올리는 형태였다.
하지만 virtualmachine, domain, loadbalancer, k8s, db, ai 까지 진짜 비지니스 로직만 신경쓰면 모든걸 클라우드가 해주는 시대가 됐다.
어떤 회사 클라우드를 사용하냐에 따라 그 사용방법을 숙지해야 되고 이것도 스펙이 된다.
이런 거대하고 복잡한 클라우드 서비스를 운영하려면 또 그만큼의 사람이 필요했고 많이 채용됐다.
그런데 코로나,ai시대를 거치면서 인력=비용이라는 문제가 발생했고 특히 북미에서는 빅테크 기업들이 필두로 해고 바람이 불었다.
1년전 쯤인가 cloudflare 직원이 해고되는 영상을 봤다.

aws, microsoft 도 기술직도 포함해 만명단위의 많은 직원을 내보냈다.
이런 기사를 볼때 처음에 아 이렇게 직원이 없어도 회사가 돌아가는 구나.
그 많은 사람들이 잉여 인력이 될 수 있구나하는 생각이 들었다.
그렇게 사람들이 내보내도 한동안 서비스에 문제가 없어 보였다.
그런데 이런 장애를 겪어 보니 어떤 사람을 내보냈고 내보낸 사람의 부재로 이런일이 발생하진 않았나 하는 생각이 든다.
어디서 본것 같은데 사람을 자를때 능력있고 우수한 직원을 내보내는게 아닌 부서단위로 전체를 내보내는 방법을 쓴다고 한다.
돈을 못버는 부서, ai 가 쉽게 대체할 수 있는 부서, 그런데 이들 부서들이 지금 보기엔 필요없을지 모르는데 한달,1년 후에 어떤 사이드 이펙트가 있을지 어떻게 모두 알까?
2025년 10월에 있었던 AWS US-EAST-1 지역 장애는 단순한 기술 결함이 아니라, 핵심 인력 유출로 인한 조직적 약화의 신호로 분석되는 말도 있다.
cloudflare 자르는 것도 그렇고 어떤 기준에 의해서 납득이 될 수 있는 이유가 있어야 하는데 너무 해고를 쉽게 한건 아닐까?
물론 ai 인간을 대체한다고 떠드는 세상이고 언제간 ai가 인간을 대신에 많은걸 대신할것은 분명해 보인다.
그래도 아직 ai가 완벽하지 않은데 잘못된 기준과 판단으로 인재들이 퇴출되고 있지는 않는지 잘 살펴야할것 같다.
해고에 모두를 만족시킬 수 있는 합당한 이유가 있을까만은 지금 천명, 만명등 숫자만 크게 부각돼 질이 아닌 양으로 비용절감만을 목표한다면 이런 전세계 장애가 아니더라도 그 회사 어딘간 탈이나고 또다른 재난의 작은 불씨가 남을것 같다.
비용절감을 위해 대부분 직원은 그냥 소모품으로 보고 ai만 바라보는 리더들은 살을 빼야지 다리는 자르는 대수술이 능사가 아니라는걸 알았으면 좋겠다.
아주 커다란 크루즈는 최첨단 항해 기능과 최신 엔진등으로 항해사, 엔지니어들의 수는 줄일 수 있지만 뛰어난 항해사 엔지니어 없이 현재 수준의 ai 가 모든걸 통제하는 배를 믿고 오를 여행객들이 얼마나 될지 생각해 보자.

구글 클라우드 데이 @판교

2017-09-12 판교에서 하는 구글 클라우드 데이 참석한 내용 정리

1.빅데이터와 머신런닝에 대한 심플한 소개
- 직접 하둡, 스파크 클러스터 구성시 보통 안정화 서비스까지 6개월 걸림
- 구글 클라우드는
: 수많은 리소스(cpu, memory)를 사용하기 때문에 수십억의 like성 질의를 수초에 처리 가능
: json 사용 가능
: 혼자서 수시간 코딩하여 분석(개발) 완료
ex) 모바일 게임에서 간단한 코드 추가로 게임내 발생하는 npc들의 이벤트(행동) 데이터를 모두 실시간으로 수집
ex) '요기요' 에서는 매니저, 마케터가 구글 클라우드에 직접 질의하여, 개발자에게 데이터 추출등의 작업 요청이 필요없음
- 머신러닝은
: 수십년전의 NeuralNet 의 문제점을 해결하여 딥러닝이라는 이름으로 만는으로 수학적으로 어렵지만 코딩적으로 봤을때 그리 어렵지 않다.
: 이미 머신러닝 대가들이 좋은 알고리즘을 공개하고 tensorflow 와 같은 오픈소스에 수많은 머신러닝 알고리즘 라이브러가 있으니 가져댜 쓰면 된디. 어떤 머신러닝 알고리즘을 사용하고 빠르게 개발환경(구글 클라우드)를 사용하여 원하는 인공지능 시스템을 구축하는게 경쟁력이다.

2. 구글 airflow 사용 사례 설명
- 빅데이터 워크(task) 플로우(수집 분석하는 파이프 라인)으로 airbnb 에서 개발하고 현재 아파치 오픈 소스 인큐베이팅
- 구글 클라우드에서 airflow 를 서비스하며 빅데이터 처리 후 빅쿼리 테이블로 저장
- 빅데이터 처리 흐름
 로그 ->
 airflow(cloudsql(mysql) -> embulk(데이터 수집 솔루션) -> cloud sotrage > big query)로 구성하여 스케줄링(자동화)
 -> 구글 리포팅 서비스
- 구글 airflow 내부 구성
 : bigquery(data warehouse, sql 문법)
 : embulk(데이터 수집 솔루션, 배치/병렬 처리, 다양한 플러그인 제공이 장점, 참고 http://bcho.tistory.com/1126)
 : compute engine(자바기잔의 vm 서비스)
 : cloud datalab(데이터 인사이트 솔수션, 오픈 소스 쥬피터 노트북)
 : etc 구글 서비스

3. 구글 클라우드를 이용한 네트워크 가속
- 구글 클라우드 플랫폼은 정말 많은 서비스를 제공하는데, 성능에 네트워크가 큰 영향
- 전세계 걸친 구글 네트워크를 사용하여 빠른 연결
 : 네트워크간 1Petabits/s 으로 통신
 : 10만 vm머신간에 10gbit/s 으로 통신
- vm 접속흐름
 : 내 위치에서 가장 가까운 펍(pub) 접속 -> 가까운 region(나라별) -> 내가 생성한 vm 있는 region
 : 펍 참고 http://bcho.tistory.com/1120
- 구글 클라우드 네트워크는 전세게에 있는 특정에 지역에 펍이 생성되면 전세계의 어느 vm과도 vpn 사용없이 직접(tcp) 접속 가능
 ex) 싱가폴, 도쿄 펍에 각각에 네트워크를 구성했다면 이들간에 direct 접근 가능
- 네트워크 성능 결정 요소
 : vm 인스턴스 크기 (코어당 2gbps 인스턴스당 최대 16gbps)
 : 네트워크 티어 (프리미엄:중간단 거치는 펍이 직방으로 연결되는 네트워크, 스탠다드:가격이 저렴하지만 여러 단계의 펍을 거침)
 : 로드밸런싱 (global tcp proxy load balancer 사용하면 빠름)
- cname 사용안하고 global ip 사용
- 네트워크 증설실 워밍 없이 바로 사용

중간 휴식 시간 30분을 제외하고 약 3시간 남지 6개의 세션이 진행되었는데, 3개만 득고 나옴.
시간이 짧아서인지 몰라도 대부분 구글의 이런 제품(서비스)를 사용해서 빠르고 편해서 좋다는 것.
기술적인 세부내용은 개인적으로 알아서 구글링해야 하는데 서비스되고 있는것들이 많음
(쉽게 빅데이터, 머신러닝을 처리할 수 있다고 하는데 서비스 각 요소를 이해 하는데도 시간이 걸릴것으로 보임)
조금 관심이 간건 airflow 와 embulk 를 보면서 elk 와 비슷한 느낌이 들었는데 elk 에 비해서 좋을지,
embulk - elasticsearch - airflow 등 구성은 어떨지등이 궁금.
네트워크, 인스턴스등이 경쟁사 aws 와의 비교 질문에 체험해보면 더 좋을것 이라고함.
사실 빅데이터, 머신런닝 시스템 구축에 많은 시간을 삽질(삽질하면 많이 배우기고 하는데ㅠ)하지 말고 구글 클라우드 서비스(일종의 패키지)를 쓰라하는데
비용이 발생되고 사내에 구축된 비슷한 시스템을 대체시킬 정도로 효과가 있는지를 솔직히 모르겠음.

golang Google App Engine 사용하기

golang Google App Engine 사용 정리
https://github.com/ysoftman/test_code/tree/develop/appengine

게임 storage 서비스

[Apple - GameCenter]
https://developer.apple.com/library/ios/#documentation/GameKit/Reference/GameKit_Collection/_index.html
- 친구, 사용자의 간단한 정보만 저장하고 게임 데이터 자체는 저장 안됨

[Valve - SteamCloud]
- http://hg.alliedmods.net/hl2sdks/hl2sdk-swarm/file/5476a15192a9/public/steam/isteamremotestorage.h
- steam works 라는 플랫폼의 하나로 데이터 저장 기능 제공
- 유저 1명당(1게임당) 1~100MB 공간 제공
- 각 게임별로 파일 저장 및 읽기 기능 제공
- 파트너쉽에게만 sdk 다운로드 제공

[OpenFeint]
- 아이폰, 안드로드 초장기에 랭킹 서비스등에 많이 사용
- cloud storage 라는 데이터 저장 기능 제공
- Gree 에 의해 1억달러에 인수 후 2014년 서비스 종료됨


Prev