Implementing GCP Stackdriver and Adapting SRE Practices to Samsung’s AI System (Cloud Next '19)

[음악 재생] TERRY CHO : 안녕하세요 좋아, 이번이 마지막 세션이야, 그렇지? 세션이 끝나면 집으로 돌아갈 수 있습니다

아니면 친구들과 술을 마셔도됩니다 만나서 반갑습니다 저는 클라우드 팀의 고객 엔지니어 인 테리입니다 Stackdriver 로깅을 소개하는 것은 영광입니다 유스 케이스, 삼성

고객을 소개하기 전에 로깅 자체 및 스택 드라이버를 간략하게 소개합니다 좋습니다, 시작합시다 로깅이란 무엇입니까? 이벤트 및 정보를 수집하는 로깅 시스템의 상태를 확인합니다 여기에서 문제 해결을 위해 로깅을 사용했습니다 및 디버깅

그리고 우리는 로그를 하나의 파일로 수집합니다 tailing 명령을 사용하여 모니터 할 수 있습니다 그러나 로깅은 여러 목적으로 사용될 수 있습니다 예를 들어 개발자의 경우 로깅 디버깅 및 코드 최적화에 사용할 수 있습니다 시스템 엔지니어에게는 상태 점검 및 시스템 모니터링에 사용됩니다

보안 엔지니어의 경우 비정상적인 동작을 찾기 위해 시스템을 보호하는 데 사용됩니다 그리고 요즘에는 데이터가 일반적으로 중요합니다 따라서 로그를 통해 데이터를 수집 할 수 있습니다 통찰력을 찾는다 이러한 이유로 더 많은 로그를 수집해야합니다

다양 한 레이어에서 예를 들어 CPU와 메모리 상태를 수집 할 수 있습니다 인프라 및 OS 수준 웹에서 웹 액세스 로그를 얻을 수 있습니다 서버 또는 데이터베이스

또한 일반적인 응용 프로그램에서 로그를 수집 할 수 있습니다 이러한 로그는 비즈니스와 같이 여러 목적으로 사용될 수 있습니다 분석, 감사, 대금 청구 등이 있습니다 그렇기 때문에 더 많은 [무관심] 터미널이 필요합니다 지금까지는 괜찮을지도 모릅니다

그러나 문제는 시스템이 존재한다는 것입니다 분산 아키텍처로 이동, 마이크로 서비스와 비슷합니다 그 때문에 많은 로그 파일이있을 수 있습니다 따라서 단일 모니터에서는 전체 로그를 모니터 할 수 없습니다 그래서 해결책은 무엇입니까? 해결책은, 점점 더 많이 다른 것을 사용할 수 있다는 것입니다

모니터, 맞지? 그러나 실제로는 기술적 솔루션입니다 그래서 기술 솔루션을 소개 할 것입니다 분산 아키텍처를 모니터링합니다 다음은 로깅 시스템의 일반적인 아키텍처입니다 시스템에서 로그를 수집 할 수 있습니다

카프카 (Kafka)와 같은 메시지 대기열로 보내십시오 메시지 대기열 뒤에서 로그를 수집 할 수 있습니다 수집 된 로그는 로그 저장 시스템에 저장됩니다 보관 목적으로 로그는 다음을 사용하여 인덱싱됩니다

그러한 목적을위한 인덱서 따라서 사용자는 로그를 검색하고 볼 수 있습니다 그러나 문제는 내가 언급했듯이, 로그는 데이터와 같이 여러 목적으로 사용될 수 있습니다 분석 또는 시스템 알림 그리고 요즘에는 기계 학습이 더 중요합니다

따라서 로그 데이터는 [INAUDIBLE] 모델 학습을위한 기계 학습 시스템 이 시스템은 사용자가 직접 구현할 수 있으며, 이 시스템을 합성하여 구현할 수있는 곳 다중 오픈 소스 그러나 문제는 로그하는 데 시간이 오래 걸리고, 또한 과부하 작업을 가져올 수도 있습니다 그래서 해결책은 무엇입니까? Google에는 Stackdriver가 있습니다 스택 드라이버는 운영 및 모니터링 시스템입니다

그것은 로깅, 모니터링, 디버깅, 흔적, 등등 Stackdriver를 조사 할 기회가 없다면, 데모 부스를 방문하는 것이 좋습니다 Stackdriver 데모가 많이 있다는 것을 알았습니다 정말 멋진 도구입니다 또한 Stackdriver는 여러 클라우드에서 실행될 수 있습니다

Google Cloud 및 Amazon을 포함한 인프라 서비스 오늘 저는 로깅 문제에 중점을 둘 것입니다 Stackdriver 로깅에서 로깅을 지원할 수 있습니다 컬렉션 게시물 SDK 또는 일부 에이전트를 사용하여 로그를 수집 할 수 있습니다

수집 된 로그는 저장되며, 그것을 검색하고 볼 수 있습니다 내장 Stackdriver 로깅 콘솔에 있습니다 그리고 집단 로그를 라우팅 할 수 있습니다 여러 목적지로 Stackdriver는 로그 라우터를 사용할 수 있습니다 예를 들어, 오픈 소스의 Kafka와 매우 유사합니다 로그 파일에서 메트릭을 추출 할 수 있습니다

예를 들어, 오류의 수를 세어 볼 수 있습니다 또는 우리는 서비스의 전반적인 응답 시간을 추출 할 수 있습니다 이 측정 항목을 정의하고 알림을 정의 할 수도 있습니다 예를 들어, 우리가 사고의 숫자가 있다면, 시스템 운영자에게 알림 메시지를 보낼 수 있습니다 이메일, SMS 또는 [INAUDIBLE]에 대한 페이지를 사용하여 마지막은 로그 관리입니다

여러 프로젝트의 경우 이제 제가 언급했듯이 시스템 아키텍처 이 분산 방식으로 변경되고 있습니다 따라서 응용 프로그램을 배포 할 수 있습니다 Google의 경우 여러 클라우드 프로젝트로 아마존의 경우 복수 계정이 필요합니다 우리가 다른 프로젝트의 모든 로그 행을 모니터링해야한다면 서로 다른 클라우드 개념으로 매우 고통 스러울 수 있습니다 따라서 스택 드라이버는 모든 로그를 수집 할 수 있습니다

모든 로그를 모니터링 할 수 있습니다 유리 한면에 자, 각 로그를 그림으로 깊이 들어가 봅시다 가장 먼저 로그를 수집하는 방법입니다 Stackdriver는 SDK를 제공합니다 SDK는 잘 알려진 로깅과 쉽게 통합 될 수 있습니다

뼈대 예를 들어 Java의 경우 [INAUDIBLE] 및 로그백 일반적으로 사용됩니다 이것은 Java 예제입니다 보시다시피, 코드 변경은 없습니다 Maven 종속성을 변경하기 만하면됩니다

Stackdriver 로깅 라이브러리를 삽입합니다 정말 쉽습니다 하지만 불행히도 때때로, 우리는 내장 솔루션에서 로그를 수집하려면, 데이터베이스 또는 웹 서버처럼 또는 로깅 프레임 워크가 지원되지 않는 경우도 있습니다 스택 드라이버에 의해

이 경우 Stackdriver 에이전트를 사용할 수 있습니다 이것은 유창한 오픈 소스 에이전트를 기반으로합니다 따라서이 에이전트를 사용하여 파일에서 로그를 수집 할 수 있습니다 로그를 수집하면 쉽게 검색하고 볼 수 있습니다 Stackdriver 로깅 내장 콘솔을 사용하여 로그를 저장하십시오

정말 쉽고 지원도 가능합니다 이 같은 코딩 언어 앞서 언급했듯이 로그를 수집 한 후, 다목적 용도로 여러 대상으로 라우팅 할 수 있습니다 Google Cloud Storage와 마찬가지로 로그 보관 용도로 사용됩니다 그리고 Pub / Sub는 로그 스트리밍에 사용될 수 있습니다

따라서 Pub / Sub 뒤에는 실시간을 넣을 수 있습니다 우리의 [INAUDIBLE] 시스템 또는 일부 변형 시스템에서 데이터가 허용되는 경우 또는 데이터를 BigQuery로 내보낼 수 있습니다 해석학 로그를 여러 대상으로 내보낼 수 있습니다 필터링을 기반으로합니다 따라서 로그를 선택적으로 내보낼 수 있습니다

여러 목적지로 또한 기본적으로 Stackdriver 로깅 가격 책정 저장된 로그 크기를 기반으로합니다 많은 로그를 저장해야하는 경우, 비용 문제가 발생할 수 있습니다 그래서 Stackdriver는 제외 필터를 제공합니다 즉, 로그를 기반으로 선택적으로 저장할 수 있습니다 필터에

그리고 비용을 절감 할 수 있습니다 요즘 로깅은 의미가 있습니다 내 말은, 몇 년 전에, 우리는 단지 문제 해결을 위해 그래서 문자 메시지로 충분했습니다 그러나 개발자는 사용자 ID와 같은 일부 데이터 및 트랜잭션 ID, 가격 로그에서

이 경우 구조화 된 로깅 형식 JSON 형식이나 CSV 형식과 같이 더 효과적입니다 Stackdriver는 JSON 형식을 지원합니다 이것은 nodejs 예제입니다 JSON 형식으로 로그를 작성하는 경우, JSON 페이로드 요소에 자동으로 충족됩니다

Stackdriver 로그 항목에 있습니다 이 JSON 로그를 BigQuery로 내보내는 경우, JSON 페이로드의 각 요소는 BigQuery 표의 열에 매핑됩니다 따라서 검색 가능성과 가독성을 높여줍니다 저장된 로그에서 메트릭을 정의 할 수 있습니다 이미 사전 정의 된 측정 항목이 있습니다

시스템 메트릭이라고합니다 바이트 수와 같은 데이터를 얻을 수 있습니다 또는 로그 항목의 수입니다 그러나 특정 정보를 수집하려면 로그에서 두 가지 방법으로 사용자 정의 로그를 정의 할 수 있습니다 첫 번째 방법은 카운터 메트릭입니다

간단한 카운터 메트릭이지만 몇 가지 조건을 정의 할 수 있습니다 예를 들어, 로그 수를 수집하려고합니다 그 웹 대기 시간은 10 초 이상입니다 그리고 다른 방법은 배포 메트릭입니다

통계 분포를 기록하고, 표준 편차, 합계, 평균과 같습니다 예를 들어 평균 응답을 수집 할 수 있습니다 귀하의 서비스 시간 그런 다음 메트릭을 정의하는 방법의 예입니다 정말 쉽습니다

이 측정 항목을 사용하면 측정 항목을 시각화 할 수 있습니다 Stackdriver 모니터링 콘솔을 통해 그래프를 사용합니다 웹 응답 시간의 한 예가 있습니다 히트 맵 그래프입니다 시스템 상태에 대한 통찰력을 얻을 수 있습니다

이 같은 메트릭을 정의한 후에는 경고 시스템을 만들 수 있습니다 미리 정의 된 규칙을 사용하면 Stackdriver 여러 목적지에 알림을 보냅니다 이메일에서 SMS를받습니다 그리고 신청서를 통해 통보를 보낼 수 있습니다

Pub / Sub 대기열을 통해 마지막으로 중앙 집중식 로깅입니다 앞서 언급했듯이 마이크로 서비스 아키텍처에서, 각 서비스는 다른 시스템에 배치 될 수 있으며, Google의 다른 제품, 및 다른 아마존 계정 따라서 중앙 집중식 시스템에 로그를 수집하는 것입니다 매우 중요합니다

그래서 Stackdriver는 모든 로그를 수집 할 수 있습니다 하나의 GCP 제품에 로그 모니터링을위한 유리의 단일 평면 이제까지 로깅 시스템을 살펴 보았습니다 스택 드라이버로 그러나 로깅 시스템은 다양한 목적으로 확장 될 수 있지만, 큰 데이터 분석을 좋아합니다

이것은 로깅 시스템을 확장 할 수있는 방법입니다 현실 세계에서 로그를 사용하려고 할 때 큰 데이터 분석을위한 데이터, 실제 데이터는 실제로 더럽습니다 나는 형식을 따르지 않는다는 것을 의미한다 때로는이 유형을 따르지 않습니다 때로는 필드가 null입니다

따라서 우리는 데이터 검증과 변환이 필요합니다 Stackdriver에서 로깅을 내보낼 수 있습니다 Stackdriver 로깅 뒤에있는 Pub / Sub에 넣습니다 및 [INAUDIBLE] (데이터 흐름에 의해) 데이터 흐름은 Apache의 오픈 소스 버전이며, 이는 Apache Spark Streaming과 매우 유사합니다

또한 빅 데이터 분석에 사용할 수 있습니다 그래서 당신은 몇 가지 검증과 변형을 할 수 있습니다 Google 데이터 흐름의 논리 그러나 유감스럽게도 데이터 흐름에는 코딩이 필요합니다 Java와 Python을 사용하여 그것은 약간의 작은 학습 곡선을 필요로합니다

그러나 수동 코딩 대신, Stackdriver는 템플릿 기능을 제공합니다 즉, 코딩 할 필요가 없음을 의미합니다 Google 클라우드 콘솔에서 여러 번 클릭하면 당신은 데이터 주입 파이프 라인을 만들 수 있습니다 또한 변환 논리를 추가해야하는 경우, 당신은 단순히 그것을 사용하여 구현할 수 있습니다 UDF, 사용자 정의 함수 (User Defined Function)라는 JavaScript

따라서 사용자 정의 기능을 GCS에 업로드 할 수 있습니다 Java에서 [INAUDIBLE]과 같은 패키지를 사용하지 않아도됩니다 그래서 당신은 그것을 간단히 언로 드하고 그것을 지적합니다 데이터 흐름 콘솔에서 데이터 흐름 실행 중에 변환 논리를 가져옵니다

데이터 형식을 변환합니다 Stackdriver 로깅을 사용하면, 우리는 서버 측에서 로그를 수집 할 수 있습니다 그러나 큰 데이터 분석 세계에서는 모든 사용자 여행을 모으고 싶었습니다 마케팅, 모바일, 그런 식으로 말입니다 다행히도 Google은 해결책을 제공했습니다

모바일 용 Firebase [INAUDIBLE] 모든 사용자 이벤트 정보 수집 그것을 BigQuery로 보냅니다 웹의 경우 Google 애널리틱스에서 모든 사용자 이벤트를 수집 할 수 있습니다 사이트에서 또한 BigQuery 자체에는 많은 데이터 커넥터가 있습니다 Google은 광고, 네트워크 데이터, Google Play, YouTube 데이터

내가 아는 한, 이번 주에 Google은 BigQuery를 발표했습니다 파트너를 통한 추가 커넥터 이제는 100 개가 넘는 데이터를 수집 할 수 있습니다 SNS, 광고, 및 [INAUDIBLE] 시스템을 포함합니다 따라서 모든 데이터를 BigQuery에 저장할 수 있습니다

끝에서 끝까지 사용자 동작을 분석 할 수 있습니다 정말 멋지다, 그렇지? 아니? 고맙습니다 마이크로 서비스 아키텍처의 다른 문제 로그 레코드의 관계라고합니다 문제는 사용자 A가 요청을 보낸다고 가정 해 보겠습니다 사용자 서비스

그리고 로그를 로거 파일 시스템에 씁니다 그리고 다른 서비스에 요청을 보냅니다 아이템 서비스처럼 사용자 B도 같은 것을 호출합니다 하지만 문제는 사용자 A를 추적하려고합니다

요청 만 그렇다면 사용자 서비스와 아이템 서비스를 어떻게 연관시킬 수 있을까요? 로그? 그런데, 우리는 추적 ID 인 코드 관계 ID를 넣을 수 있습니다 따라서 사용자가 사용자 서비스를 호출 할 때, 추적 ID를 자동으로 생성합니다 함께 로그에 저장하십시오 그리고 사용자 서비스는 항목 서비스에 요청을 보냅니다

이 추적 ID는 함께 전파됩니다 로그 파일에 기록됩니다 따라서이 추적 ID를 사용하여 로그 항목을 상관시킬 수 있습니다 다른 서비스들 사이 혼자서 구현할 수 있습니다 그러나 다행히 Zipkin이라는 오픈 소스가 있습니다

로깅에 Zipkin 오픈 소스를 통합하는 경우 시스템에서 자동으로 추적 ID를 생성합니다 ID를 다른 시스템으로 전파하십시오 또한 추적 ID는 자동으로 로그 파일을 함께 반환하십시오 사실, 지프 킨은 로깅 시스템이 아닙니다 원래는 분산 시스템을 지원하도록 설계되었습니다 자취

이는 분산 형 시스템의 대기 시간을 추적 할 수 있음을 의미합니다 간격으로 시스템 예를 들어 사용자 서비스 및 품목 서비스를 호출합니다 하지만 병목이 어디 있는지 알고 싶습니다 품목 서비스에 소요되는 시간은 얼마나됩니까? Zipkin 통합 후 Stackdriver도 Stackdriver 추적을 사용하여 Zipkin을 지원하십시오

스택 드라이버 추적은이 대기 시간 정보를 수집합니다 이와 같은 그래프를 사용하여 시각화 할 수 있습니다 이것은 정말로 좋다 그러나 문제는 Zipkin을 사용하는 것입니다 Zipkin 소스를 주입해야합니다

코드를 응용 프로그램에 추가하십시오 그러나 다른 시스템 대기 시간을 수집하기를 원했습니다 Zipkin에서 삽입 할 수없는 데이터베이스 (예 : 데이터베이스, 웹 서버 하지만 추적을 확인하고 싶었습니다 이 경우이 문제를 해결할 수 있습니다

인프라 영역에서 코드를 수정하는 대신 프록시를 넣을 수 있습니다 특사 프록시 인 서비스 앞에서 이것은 [INAUDIBLE] 프록시와 매우 유사합니다 그러나 마이크로 서비스 세계에서 우리는 각 서비스 앞에 많은 프록시를 배치해야합니다 그 대신에, istio는 대사 서비스를 만들었습니다

그것은 서비스 앞에서 특사를 자동으로 색인화 할 수 있습니다 그래서 응용 프로그래밍의 릴리스에 관한 언어를 사용하면 모든 추적 로그를 수집 할 수 있습니다 이러한 추적 로그는 Stackdriver와 통합 될 수 있습니다 서비스 모니터링 보시다시피, 마이크로 서비스 분야에서, 토폴로지 및 서비스 종속성 정말로, 정말로 복잡합니다

하지만 이것은이 토폴로지를 보여줍니다 또한 중요한 정보를 제공합니다 응답 시간, 오류율, GPU 사용률과 비슷합니다 좋아요, 마지막으로 개인 정보입니다 개인 정보는 매우 민감합니다

맞습니까? 개인 정보를 저장 장치에 저장하는 경우, 원래 개인 정보 용으로 설계된 경우 처리, 당신은 문제가 없을 수도 있습니다 그러나 예기치 않게 PII 또는 사용자 정보 로깅 시스템에 저장할 수 있습니다 그것은 매우 중요합니다 이를 방지하기 위해 DLP API를 사용할 수 있습니다 데이터 손실 방지 – Google 시스템을 기반으로합니다

학습 기술 그것은 자동으로 사용자 정보를 탐지 할 수 있으며, 사회 보장 번호처럼 다른 정보입니다 그리고 그것은 익명으로 해시 값으로 만들 수 있습니다 그래서 개인 정보를 막을 수 있습니다 로깅 시스템에 저장됩니다

좋아요, 작년부터 Stackdriver 로깅을 사용하여, 삼성 전자는 혁신으로 옮기기 시작했습니다 SRE와 DevOps 연습 오늘은 삼성 모바일 운영 책임자를 소개하겠습니다 시스템, 진 임, 무대에 진, 네 차례 야

HYUNG JIN LIM : 고맙습니다 [박수 갈채] 좋아, 여기 와서 반가워 실제로 선물하는 것은 영광입니다 Google Next에서 내 프리젠 테이션 이 대형 기술 회의에 오면 나에게있어서, 정말 저에게 대접입니다

내 첫 번째 큰 회의가 약 9 번 이었음을 기억한다 몇 년 전 저는 인프라 엔지니어였습니다 이 큰 소프트웨어 회사와 서비스 엔지니어 그 당시 클라우드 회의에 관한 것이 었습니다 그리고 그것은 나를 위해 정말로 눈을 뜨고있었습니다

인프라 엔지니어로서, 엔지니어링 팀에서 나에게 묻는다면 새로운 소프트웨어를 배치, 배치 기존 데이터 센터에서는 약 3 개월이 소요됩니다 업계 표준이라고 생각합니다 기존 데이터에 새 소프트웨어를 배포하려고 할 때마다 센터에서 약 3 개월이 걸립니다 그러나이 회의에서 그들은 다음과 같이 말합니다 여러 서버에서 프로비저닝 할 수 있습니다

10 분 안에 그리고 그것은 같았습니다, 이것은 내가 있어야 할 곳입니다 내 경력으로, 나는 구름 속에 있고 싶다 나는 더 많은 일을하려고 노력하고 있습니다 내 인생을 더 편하게 만들고 엔지니어링 팀을 돕습니다

게다가 올해 Google Next와 함께했던 그런 느낌 게다가 Anthos에 관해 들었을 때, 그것은 나를위한 새로운 세상과 같았습니다 게다가

내가 기존 시스템의 일부를 옮기기 위해 노력했기 때문에 [INAUDIBLE]로 전환하고 더욱 효율적이고 유연하게 작업 할 수 있습니다 그리고 많은 시간을 얻는 것이 정말 어려웠습니다 엔지니어링 팀에서 코드 변경을 요청합니다 그런데 Anthos, 우리는 코드없이 그것을 할 수 있습니다 변화, 그리고 그것은 무료입니다

이런 종류의 미래를 갖는 것이 정말 기쁩니다 업계에도 나옵니다 삼성 전자의 회사 이름을 들었습니까? [웃음] 그래 좋아 나는 당신이 삼성 전자에 대해 알고 있다고 확신한다 우리는 꽤 멋진 가전 제품을 제작하거나 제작합니다

핸드셋 장치 포함 – 매우 혁신적입니다 그리고 우리는 삼성 전자 내부의 사업 목록을 가지고 있습니다 한국에서 삼성 전자는 소비자 전자 제품에 관한 우리는 건설, 보험, 테마 파크, 호텔 및 기타 많은 비즈니스 우리는 한국에 있습니다 그들은 비즈니스를 나열하는 것이 더 쉽다고 말했다 삼성은 우리가있는 것과 비교가 안된다

이 거대한 기술 회사는 엄청난 가치가 있습니다 그들의 이름으로 그리고 대부분의 대학 졸업자들에게는 삼성에 와서 꿈을 꾼다 회사를 위해 일합니다 이유 중 하나가 좋은 지불이기 때문에 물론, 직업 안전을 제공합니다

그 이유는 우리에게는 큰 사업 포트폴리오가 있기 때문입니다 하나의 사업에 침체가 있다면, 우리는 그 사람들을 수송 할 수 있습니다 우리는 사람들을 눕힐 필요가 없습니다 내 말은, 우리는 그 사람들 중 일부를 배에 데려 간다 그것들을 다른 사업 분야로 옮깁니다

그래서 삼성과 함께, 큰 회사와, 당신은 꽤 좋은 수준의 직업 안정감을 가지고 있습니다 그리고 몇몇 사람들에게는 좋은 기회가 될 것입니다 지구 환경에서 일하기 당신은 많은 글로벌하고 똑똑한 사람들과 이야기하게됩니다 당신의 경력을 배우고, 이해하려고 노력합니다

지구 환경에서 그래서 그것은 그 대학의 다른 이점입니다 아이들도 갖고 싶어합니다 그런데 나는 그것이 단지 최근 일 뿐이라고 확신한다 삼성도 서비스 회사로 알려지기 시작했다

그래서이 응용 프로그램 서비스 목록이 있습니다 더 많은 가치를 더하려고 애쓰다 우리 스마트 폰 장치에 예를 들어, 삼성 Pay는 제 의견으로는 가장 혁신적입니다 우리가 삼성 전자에서 만든 서비스, 디지털화 된 신용 카드 또는 은행 제공 카드를 휴대 전화에 넣으십시오 그리고 당신은이 전화를 사용하여 실제로 지불 할 수 있습니다

지불하고자하는 곳이면 어디에서나 지불 할 수 있습니다 이 판매 시점 관리 장치 자기 전용 인 MST 만 허용합니다 삼성 유료 기기를 계속 사용할 수 있습니다 삼성은 그것을 지불하기 위해 서비스를 지불한다 한국과 일부 다른 국가에서 큰 성공을 거두었습니다

게다가 우리는 삼성 계정을 보유하고 있습니다 우리는 생체 인식 인증 인 Samsung Pass를 보유하고 있습니다 메커니즘, 엄지가있는 한, 네트워크에 액세스하려고 할 때 로그인 정보와 비밀번호를 가진 리소스, 그 정보가 전화에 저장된 후에, 더 이상 암기 할 필요가 없습니다 정보가 기기에 안전하게 저장됩니다

액세스하려면 엄지 손가락 만 있으면됩니다 귀하의 모든 네트워크 리소스 그리고 우리는 B2B 사업에도 종사하고 있습니다 Android 기기 용 [INAUDIBLE] 솔루션을 제공하고, 서로 다른 비즈니스 분야에서 파트너와 함께 일하려고합니다 좀 더 보여줄거야

Bixby라고 불리는 삼성 AI 시스템에 대해서 [비디오 재생] [음악 재생] – 새 Bixby, 삼성 전자에 인사 해 지능형 조수 안녕, 빅스 비 오늘 오후에 뭐하는거야? 오늘 오후 1시에 하나의 일정이 잡혔습니다

패턴 메이커와의 만남 -이 이벤트 시간을 오후 2 시로 변경하십시오 – 모든 설정 나는 사건을 저장했다 [음악 재생] 안녕, 빅스 비

근처에 이탈리아 식당을 찾으십시오 – 근처에 이탈리아 식당이 있습니다 오늘 오후 1시에 Luciano 's에서 테이블 3 개를 가져와 너 모두 점심 먹으러 왔어 [음악 재생] 안녕, 빅스 비

Uber에게 일하게 해줘 -이 승차 요금은 $ 2172입니다 탈것을 요청할 준비가 되셨습니까? – 완벽 해 [음악 재생] 안녕, 빅스 비

실행 시간입니다 – 좋아, 블루투스 켜기 삼성 헬스에서 달리기 시작, 실행 재생 목록 재생 [끝내기] HYUNG JIN LIM : 좋습니다 그건 Bixby에 관한 것입니다

현재 약 5 천 7 백만 명의 등록 사용자 Bixby 서비스를 이용하고 있습니다 그리고 Bixby 서비스의 최신 버전으로, 우리는 한국어, 영어 및 중국어를 지원합니다 그리고 올해는 이미 다섯 가지 언어를 추가했습니다 오늘날 대부분의 유럽 사람들이 그것을 사용하고 있습니다 올해는 내년에 갈 예정입니다

계속 확장하고, 다른 언어를 지원한다 세계에 그리고 우리가 Bixby로 만든 20의 변화로, 큰 변화는 AI를 열려고하는 것입니다 시스템을 파트너에게 제공합니다

우리는 동일한 기계 학습 도구를 제공합니다 우리가 내부에서 사용하고있는 우리 파트너에게도이를 활용할 수 있습니다 뿐만 아니라 파트너 당신이 개발자이고 오래 동안 도구 사용 방법을 알기 때문에 Bixby와 통합 할 수 있어야합니다 앱을 Play에 업로드 할 수있는 Play 스토어와 같은 종류 저장

Bixby Development와 비슷한 일을 할 수 있습니다 문 따라서 Bixby Department Portal에서 더 많은 정보를 찾으십시오 귀하의 비즈니스를 위해 5,700 만 명의 사용자를 확보하려는 경우 그리고 그것은 핸드셋 장치 일뿐만 아니라 그것은 TV와 냉장고가 될 것입니다 모든 가전 장치는 우리 네트워크에 연결할 수 있습니다

우리는 앞으로 Bixby와 통합 할 것입니다 다음으로, 내 동료 조영이 설명 할 것입니다 우리가 관리해온 과제는 무엇입니까? Bixby 마이크로 서비스의 50 플러스 크기와 로그의 큰 크기 우리는 오늘 달리고, Stackdriver가 우리를 어떻게 돕는 지 알려줍니다 그 문제의 일부를 해결하는 것 조영

JOOYOUNG HWANG : 안녕하세요 내 이름은 Jooyoung이고, 저는 DevOps 멤버입니다 Bixby 프로젝트에서 여기에 제 경험을 전하는 것이 정말 영광입니다 우리의 작은 경험이 당신에게 기회를 줄 수 있기를 바랍니다

우리가 그 상황을 어떻게 극복했는지 이해하는 것 로깅에 대해, 그리고 그것은 좋은 기술 참조가 될 것입니다 너를 위해서 그래, 배경으로 들어 가자 사실, 우리는 이제 새로운 Bixby 서비스를 갖게되었습니다 이전에 우리에게는 또 다른 Bixby 서비스가 있다는 것을 의미합니다 보통 우리가 로깅 시스템에 관해서 전화 할 때, 로깅 시스템은 일반적으로 디버깅을위한 것이며, 모니터링 및 분석 목적에 대해서도 마찬가지입니다

그러나 프로젝트 나 서비스의 규모가 작아서 아마도 로깅을 위해 ELK를 사용하는 것으로 생각할 수 있습니다 시스템, 또는 일종의 오픈 소스 솔루션 상황을 극복하기 위해 그러나 고객 서비스 또는 그 이상을위한 일부 서비스 대규모 서비스는 항상 자체 로깅 시스템을 구축하려고합니다 그것은 신뢰성과 확장 성을위한 것입니다 그리고 현재, 새로운 Bixby, 로그 데이터 하루에 거의 1

5 테라 바이트입니다 그리고 우리는 어떻게 우리가 다음을 사용하여 실시간 모니터링을 만족시킬 수 있습니다 우리의 현재 내부 로깅 시스템 또한 신뢰성을 보장해야합니다 확장 성 또한 고객 서비스에있어 중요합니다

따라서 이전 로깅에 대해 생각할 때 Bixby 서비스의 시스템, 주요 요점 디버깅을위한 로깅이었고, 다른 하나는 저장 점의 비용입니다 사실, 이전의 내부 로깅 시스템 우리 자신에 의해 개발되었습니다 이는 시장에서 알려진 솔루션이 아니라는 것을 의미합니다 그것은 우리 편에서 설계되었으며 우리의 개발 과정에서 개발되었습니다 팀

또한 클라우드 인프라 스트럭처에 배포됩니다 대부분의 요구 사항은 내부 사용자에 의해 결정되었습니다 따라서 모든 요구 사항을 충족시키는 것이 더 쉽습니다 우리가 로깅 시스템을 개발할 때 그러나 새로운 기능을 추가하고자 할 때, 추적 또는 E3 테스트와 마찬가지로 인프라와 디자인을 변경해야한다

로깅 시스템의 개념입니다 그러나이 시스템은 당시에 설계되지 않았습니다 간단히 말해서, 모든 로그 메시지를 로깅 시스템에 기록했으며, 간단한 모니터링은 Grafana에 의해서만 지원되었습니다 그래서 우리에게는 몇 가지 도전이 있습니다 개발자에게 추적 메커니즘을 제공 할 수있는 방법 문제를 어떻게 디버깅 할 수 있는지에 대한 도움을주기 위해 일부 문제는 자체 응용 프로그램에서 감지됩니까? 그리고 실제로 새로운 로깅 시스템을 추가 할 때 클라우드 인프라 스트럭처에 시스템의 복잡성 우리가 기대했던 것보다 훨씬 더 많이 올라간다

새로운 기능을 추가하는 것은 쉽지 않습니다 새로운 로깅 시스템으로 뿐만 아니라 비용도 올라간다 비용은 우리에게 커다란 도전이었습니다 원가 계산 비용을 줄입니다 이것이 주요 도구 요청입니다

개발자 팀 측에서 그리고 우리는 변화해야합니다 시장에서 사용 가능한 솔루션을 찾으십시오 그래서 우리는 다른 팀으로부터 몇 가지 제안을 받았습니다 사실 그것은 Google의 [INAUDIBLE]이 아니 었습니다 Google은 웹 사이트에서 Stackdriver를 검색했습니다

우리는 우리가 새 로깅을 제공하기위한 핵심 기능은 무엇입니까? 체계 먼저, 우리는 실시간 모니터링에 대해 생각해야합니다 Stackdriver는 실시간 모니터링이 로그 기반 메트릭을 기반으로합니다 로깅 시스템이 스택 드라이버를 사용 중입니다 또한 실시간 모니터링을 지원할 수 있습니다

그러나 그것은 또한 쉬운 방법을 제공했다 다른 모니터링 솔루션과 통합 할 수 있습니다 Bixby 10에는 내부 모니터링 솔루션이 있으며, 그리고 그것은 또한 지속적으로 있어야합니다 우리의 작업에 사용합니다

따라서 Stackdriver가 지원할 수 있는지 확인해야합니다 타사 모니터링 솔루션 통합, 우리는 그것이 가능하다는 것을 보장 할 수 있습니다 두 번째 로깅 시스템에서 가장 중요한 점은 디버깅 경험입니다 이제 우리의 이전 로깅 시스템, 개발자가 모든 로그를 검색하려고 할 때, 그 당시 응용 프로그램 기반 로그 만 검색 할 수 있습니다 한 가지 문제는 모든 개발자가 한 번에 표준 로그 형식

삼성의 수많은 개발자 이 Bixby 개발에 참여했습니다 그리고 그들은 그들 만의 스타일을 만들었습니다 우리는 로그 메시지를 만들었습니다 관련 로그 메시지를 표시하지 않습니다 디버깅 목적으로

따라서 개발자는 새로운 발견 여부를 확인하기를 원합니다 문제는 해당 문제 또는 다른 모듈의 것입니다 문제 개발자에게 추적 메커니즘을 제공해야합니다 로그를 쉽게 찾을 수있는 방법을 제공합니다

디버깅을위한 메시지 그래서 우리가 Stackdriver를 점검했을 때, 그것은 또한 추적 메커니즘을 지원할 수 있습니다 자동화 된 추적을 사용합니다 그러나 내부 요구 사항에는 적용 할 수 없습니다 사실, 자동으로 생성 된 추적 ID를 추가하려는 경우, 우리는 모든 개발자를 설득해야한다

해당 요구 사항을 소스 코드에 적용합니다 쉽지 않아 나는 당신 중 일부가 대기업에서 일하고 있다고 생각합니다 대기업에는 여러 조직이 있습니다 그리고 그 조직 만 개발팀에 속한다

그들 만의 전략과 정책을 가지고있다 새 코드를 추가하는 것은 쉽지 않습니다 해당 코드에 추적 용도로만 사용하십시오 그들은 어떤 부작용과 어떤 성과 새로운 메커니즘을 추가함으로써 저하 자신의 코드로 그래서 우리는 추적이 또한 새로운 로깅 시스템을 추가해야합니다 그리고 새로운 표준 로그 형식을 만들었습니다

스택 드라이버를 적용합니다 둘째, 이전 로깅 시스템 또한 시스템의 분석을 제공합니다 이는 로그 메시지 중 일부를 수집해야한다는 것을 의미하며, 다른 분석 플랫폼으로 전송됩니다 그리고 그 플랫폼은 모든 데이터를 모으고 있습니다 및 분석 데이터를 제공하는 단계를 포함한다

우리는 스택 드라이버가 그것을 지원하기 위해 우리는 그게 가능한지 여부 그래서 모든 요구 사항을 확인한 후, 우리는 어떤 건물도없이 스택 드라이버와 함께 갈 수 있습니다 내부 로깅 시스템 내부 로깅 시스템은 일반적으로 너무 많은 노력을 필요로합니다 개발할

또한 모든 프로젝트 이정표를 만족시킬 수는 없습니다 앞으로 나아갈 것입니다 이제 우리는 그렇게 할 수 있습니다 우리는 로그 형식 표준화에 대해 그렇게해야합니다 그 추적 목적을 만족시킬 수 있습니다

다른 하나는 일반적으로 새로운 로깅을 빌드 할 때입니다 시스템, 항상 우리는 사용자 관리에 대해 생각해야합니다 그래서 Stackdriver를 사용할 때, 모든 사용자 인증 또는 사용자 관리는 IIM 정책에 의해 [비 적합]입니다 그리고 Stackdriver 로그 뷰어는 기본적으로 액세스 권한을 얻은 모든 사용자가 로그 뷰어 페이지로 이동하면 즉시 콘솔에 액세스하여 로그 메시지를 검색하십시오 그리고 가장 중요한 것은 인프라 관련 시스템 메트릭의 스택 드라이버에 의해 자동으로 만들어지며, Stackdriver 서비스로 보냅니다

그러나 우리는 또 다른 커스텀 메트릭도 필요로합니다 응용 프로그램 측에서 생성됩니다 그래서 Stackdriver에 관한 것들 중 하나 로그 기반 메트릭을 지원할 수 있다는 것입니다 우리가 다른 응용 프로그램과 통신 할 수 있다고하더라도 개발자는 우리가 정의 할 수 있습니다 로그 메시지는 필터링 된 메시지에 의해 수집 될 수 있습니다

로그 기반 메트릭 그리고 그것이 작동을위한 재료 중 하나입니다 모니터링 이제 간단한 다이어그램을 만들었습니다 각 모듈에 저장된 모든 로그는 서버 및 스택 드라이버 로깅에서 수집 중입니다 에이전트는 모든 데이터를 수집하고 있습니다

해당 데이터를 Stackdriver 서비스로 전송하십시오 그리고 우리는 Datadog와 통합 할 수 있습니다 우리의 주요 모니터링 솔루션 중, 로그 기반 메트릭을 모으고 있습니다 또한 대시 보드의 통일 된 형식 하나를 보여줄 수 있습니다 현재, 우리는 SLA 연습을하지 않을 것입니다

아직 그래서 우리는 전통적인 운영 관행을 가지고 있습니다 이제 모든 계층 1 및 계층 2, 심지어 계층 세 명이 문제를 해결하기 위해 그것을 사용하고 있습니다 우리 자신의 대시 보드에 의한 탐지 또한 스택 드라이버 모니터링 도구도 사용합니다

이 대시 보드는 맞춤 대시 보드도 제공하기 때문에 창조 또한이를 다른 솔루션과 통합 할 수도 있습니다 오픈 소스 Grafana처럼 그리고 우리는 슬랙 채널을 사용했습니다 편의성을 위해 모든 경고 또는 합병증을 알립니다

그리고 우리가 모든 경고를 정의 할 수 있다면 Stackdriver 및 데이터 행에서 슬랙 (Slack) 채널을 자동으로 보낼 수 있습니다 이해 관계자에게 갈 수 있습니다 문제를 조사하거나 운영 프로세스에 알릴 수 있습니다 기본적으로 디버깅을 사용할 수도 있습니다 우리가 로그 뷰어에 액세스 할 때

분석 목적으로 모든 로그를 수집합니다 메시지를 필터링하여 Google Cloud Storage에 필터링 서비스 Pub / Sub에 의해 분석 시스템으로 이동합니다 마지막으로, 우리는 시스템 로깅을위한 스택 드라이버, 우리는 효과의 네 가지 번호를 가질 수 있습니다 그 Stackdriver를 사용한 후에 첫째, 비용 절감에 대해 이야기 할 수 있습니다

우리는 비용 절약보다 최소한 3 배는 낮다고 말할 수 있습니다 Stackdriver를 사용할 때 가능했습니다 그래서 우리는 생각할 필요가 없다는 것을 의미합니다 시스템의 모든 인프라 변경 또는 유지 관리에 대해서만 우리는 서비스의 신뢰성에 최선을 다할 수있다 및 확장 성

둘째, 모든 작업 부하를 최소화 할 수 있습니다 따라서 우리는 유지 보수에 대해 생각할 필요가 없습니다 로깅 시스템에 대해 우리는 서비스의 신뢰성에 전적으로 힘을 실어 줄 수 있습니다 셋째, 스택 드라이버를 사용할 때, 우리는 또한이 로깅 시스템을 통합 실현 다른 프로젝트에 적용 할 수있다

그 요구 사항이 Bixby 프로젝트와 정말로 유사하다면, 우리의 운영 팀은 많은 수의 서비스를 제공합니다 Jin이 말했던 것처럼 가능하면 가능합니다 Stackdriver를 다른 서비스에 추가하십시오 로깅 시스템의 통일 된 플랫폼으로서 마지막으로 우리는 또한 분석과 통합했지만 삼성 전자 내부 데이터 시스템, 그러나 더 나은 확장 성

데이터 분석의 또 다른 목적 BigQuery를 사용할 때도 가능합니다 그래서 이것이 나의 마지막 페이지입니다 그래서 나는 진에게 돌아갈 것이다 고맙습니다 [박수 갈채] HYUNG JIN LIM : 그렇습니다

나는이 마지막 세션을 안다, 나는 알고있다 당신은 당신, 당신도 알다시피, 집으로 돌아 가기를 간절히 원합니다 그러나 나는 가능한 한 빨리 만들 것입니다 하지만 제가하고 싶었던 것은 제 이야기입니다 SRE를 연습하고, 우리 환경에서 그런 일이 일어나도록 노력합니다

게다가 그래서 보자 그래서 삼성 전자와 같은 몇 가지 도전 과제는 2013 년에 입사했습니다 나는 큰 소프트웨어 회사에서왔다 워싱턴 레드몬드에 본사를두고있다

나는 약 10 년에서 12 년을 보냈다 삼성에 고용되어 가족을 한국으로 이주 시켰습니다 그리고 그때, 나 같은 다른 사람들이있었습니다 누가 글로벌 소프트웨어 회사에서 왔습니다 그리고 나서 삼성은 그 (것)들에게 환경을 소프트웨어 개발 관리 회사가 가지고 있지 않기 때문에 우리 회사에 평범한 종류입니다

핵심 비즈니스의 소프트웨어 기반에서 나왔습니다 그들의 핵심 사업은 제조입니다 그래서 그들은 환경을 조성하려고 노력하고 있습니다 소프트웨어 개발 문화를 창출하려고합니다 그러나 회사가 더 많은 투자를하기 때문에 소프트웨어 개발에서 우리는 계속해서 더 많은 서비스를 창출했습니다

분명히 더 많은 서비스를 추가 할 때마다 그 서비스를 운영하는 사람들이 더 많아 질 것입니다 그래서, 아시다시피, 서비스는 생산에 더 많이 추가됩니다 환경, 우리는 운영하고 지원하는 더 많은 사람들이 필요합니다 그 서비스들 문제는, 우리는 우리가 우리 자신을 정당화 할 수있을 것 증가하는 운영 팀의 비율

따라서 우리는 새로운 작업 방식에 대해 생각할 필요가 있습니다 생산에 들어가는 많은 서비스를 지원합니다 내가 삼성과 함께 할 때, 나는 일종의 운이 좋게도 모든 변화를 목격 할 수 있습니다 삼성 전자 내부의 소프트웨어 관리에서도 마찬가지입니다 보시다시피, 알다시피, 박스 제품, 그렇지? 따라서 우리는 6 개월마다 주력 장치를 출시합니다

권리? 우리는 S 시리즈 있습니다 우리는 노트 시리즈 있습니다 약 6 개월이 걸립니다 개발 라이프 사이클 종류의 폭포 방법론 제조 시스템에서 상자 제품에 의미가 있습니다 그리고 우리는 모든 중요한 결정을했습니다

우리는 충분한 시간이 있기 때문에 경영진에 의해 만들어지고있다 이러한 제품의 수명주기 그리고 분명히 당시에 우리는 우리의 서버를 호스팅하는 많은 전통적인 데이터 센터 그리고 모든 시스템은 모 놀리 식 아키텍처와 비슷합니다 체계

하지만 일년 내내 우리는 더 이상이 유형의 관리를 서비스와 함께 할 수 없습니다 개발 그래서 우리는 폭포에서 오는 애자일로 바뀝니다 우리는 모든 작업을 분해합니다 우리는 백 로그를 만들고 우리는 다시 성취하려고 노력하고 있습니다

알다시피, 실제로 올바른 엔지니어가 주어진다면 이러한 백 로그를 담당합니다 그리고 우리는 매년 봄에 끝나고 나간다 생산에 선적 가능한 제품 그리고 모든 결정은 이제 PO에 의해 만들어졌습니다 또는 프로덕션의 모든 주요 기능, 그것이 생방송이 될 필요가 있건 없건간에, 제품 소유자가 결정합니다

그리고 당연히, 지금 당장은 대부분의 서버 준수가없는 한 클라우드에서 호스팅됩니다 서버가 기존의 데이터 센터에 있어야한다는 것입니다 그리고 여러분도 알다시피, 왜 이런 패턴의 제작을할까요? 프로덕션의 각 기능을 분석하십시오 자신을 마이크로 서비스로 설계하는 것이 합리적입니다 모 놀리 식의 대신에

아직도, 개발 라이프 사이클의 옛 방식에서, 제가 말씀 드렸다시피, 우리는 폭포에 6 개월의 시간을 가지고 있습니다 그리고 우리는 항상 가질 수 있습니다 우리가 새로운 서비스를 도입 할 때마다, 우리는 할 수 있습니다 수술로서 우리는 엔지니어 팀에게 물어볼 수 있습니다 운영 가이드, 기술 자료 문서 작성 및 수행 프로덕션에 들어 맞는 올바른 교육 팀 환경

그리고 그것은 모두 의미가 있습니다 그러나 Agile과 Sprint가 관리하는 프로젝트를 통해, 우리는 더 이상 그 사치품을 가지고 있지 않습니다 우리는 그들에게 물어볼 시간이 없다 또는 엔지니어링 팀에 시간이 없습니다 모든 정보를 제공합니다

우리는 또한 사업간에 갈등이 있습니다 엔지니어 및 작업, 우리의 우선 순위 고객에게 안정적인 서비스를 제공하고 있으며, 엔지니어링 팀이 새로운 가치를 추구하는 곳 우리의 생산 환경에 그래서 우리는 계속이 갈등을 겪고 있습니다 이 작업을 해결하려고하는 동안 갈등과 조직적인 도전, 우리는 Google과 함께 일할 수있는 기회를 갖게되었습니다 엔지니어, Google SRE 엔지니어 및 더 많은 것을 배우려고합니다

SRE 연습 및 Google에서 SRE 연습을하는 방법 그들의 끝에서 그리고 우리는 많은 회의와 세미나를 치렀습니다 Google 엔지니어와 그런데 삼성이 Google이 아니라는 것을 깨달았습니다 그래서 제가 의미하는 바는 우리가 소프트웨어에서 온 것이 아니라는 것입니다 개발 회사

우리는 프로세스 중심의 제조업체에서 왔습니다 우리 마음의 문화 그래서 우리가했던 다음 일은 OK였습니다 그래서 우리는 SRE가 우리에게 줄 수있는 것, 어떤 종류의 이점을 이해합니다 그러나 우리는 어떻게 질문에 답할 필요가 있습니다

우리는 어떻게이 관행을 우리 환경에 구현할 수 있습니까? 그래서 우리는 다른 업계 지도자들로부터 배우기 시작할 수 있습니다 SRE 연습에서 우리는 Netflix, LinkedIn, Uber, 그리고 많은 다른 사람들 그리고 그들은 모두 공통점이 있습니다, 맞습니까? 그래서 그들은 각 종류로 – 생산에 투입된 것을 분리하다 주소 지정을 담당해야하는 담당자를 분리해야합니다

그 문제들 그들은 당신이 만든 개념을 가지고 그것을 실행합니다 따라서 시도하는 개발자가있는 경우 생산에 몰두하고, 그 사람 이러한 문제를 해결하는 방법을 알고 있어야합니다 운영 엔지니어 그래서 우리는 거기에있는 운동의 개념을 정말로 좋아합니다

그래서 우리는 우리 자신의 SRE 버전을 만들었습니다 우리는이를 글로벌 서비스 안정성이라고 부릅니다 공학 그리고 우리는 다른 구현 영역으로 나뉩니다 전에는 거의 모든 서비스가있었습니다

현재 실행중인 SLA가 있습니다 우리는 핵심 가용성 지표를 가지고 있습니다 하지만 SRE 연습에는 충분하지 않습니다 우리는 우리가 무너지는 것을 확실히하고 싶다 서비스 내의 각 기능에 각 기능, 사용자 영향 기능, SLO, SLI를 가지고 있습니다

또한 Google은 오류가 예산이 엔지니어링 팀과 전달되고 있습니다 그래서 모든 SLO를 다 써버린다면 우리는 신뢰할 수있는 시스템을 만드는 데 중점을 둡니다 새로운 아이디어를 생산에 적용하는 대신 이것은 우리가 가지고있는 SLO 문서의 한 예입니다 내가 언급했듯이, 빅스 비 (Bixby) 서비스 내에서 다른 기능을 제공합니다 그 능력 중 하나는 ASR이며, 이는 발화를 번역합니다 텍스트

그래서 우리는이 템플릿을 만들었습니다 해당 SLO의 소유권으로 응용 프로그램 수준까지 SLO의 기본 소유권은 그 것입니다 우리는 기본 소유권 아래 있습니다 운영, 우리는 인프라 관리 SLO 수준 그리고 핵심 포인트 중 하나는 인프라입니다

SLO는 응용 SLO보다 훨씬 더 엄격합니다 분명히 알다시피, 애플리케이션 SLO 기본 프레임 워크가 아닌 경우 만들 수 없습니다 아직 거기 있지? 그래서 우리는 일종의 차별화를 시도하고 있습니다 운영 책임과 엔지니어링 사이 주요 책임 Stackdriver와 Datadog를 사용하면, 우리는 그 SLA를 위해 대시 보드를 만들 수있었습니다

따라서이 SLA를 기반으로 SLA가있는 경우 SLO가 위협을가합니다 이벤트가 발생하면 통합 할 수 있습니다 Datadog and Slack과 다른 경고 메커니즘을 사용합니다 우리는 적절한 엔지니어에게 경고를 줄 수 있습니다 또한 인스턴스 관리도 마찬가지입니다

그리고 전통적인 멀티 – 티어 에스컬레이션 경로를 취하기 전에, 권리? 우리는 1 단계, 2 단계, 3 단계, 본질적으로 개발자입니다 문제가 발생하면 1 단계에서 문제가 발생합니다 두 번째 단계로 이관합니다 문제를 해결하는 방법에 대한 정보가 충분하지 않습니다 그리고 운영 측면의 2 단계는, 대부분의 경우, 기능이 어떻게 실행되고 있는지 알고 있습니다

프로덕션 환경에서 그러나 애자일과 봉사의 이름으로 알다시피, 내가 말했듯이, 항상 정보가 부족합니다 프로덕션 및 응용 프로그램 수준에서 실행되는 항목 그래서 우리는 매번 개발자를 호출하게되었습니다 따라서 가용성에 대한 SLO가 395라고 생각하면, 허용 된 중단 시간은 22 분입니다 그래서 한밤중에, 하나 이런 일이 일어나는 경우, 약 30 분을 잃는 것은 쉽습니다

그 달에 우리가 하나의 인스턴스를 가지고 있다면, SLO를 위반하고 있습니다 그래서 우리는 SRE에서 다른 접근법을 취할 필요가있었습니다 따라서 실제 오류를 찾아내는 중입니다 우리 로깅에서 더 나은 일을해라 우리는 1 단계와 2 단계를 거치지 않아도됩니다

시스템이 올바른 정보를 생성하는 경우 이러한 경고를 올바른 엔지니어에게 전달하고, 이벤트이므로 개발자가 될 수 있습니다 SLO를 위반하려고 시도하고 있습니다 인프라 엔지니어에게 갈 수도 있습니다 네트워크를 위해 사전 구축 한 일부 SLO를 위반하는 경우, 예를 들면 그래서 우리는 경고를 정확하게 지적 할 수 있습니다

그리고 우리는 일을 끝낼 수 있습니다 우리는 거기에 다중 계층 에스컬레이션을 건너 뜁니다 이것은 정말 빨리 마무리해야합니다 관리 배치 같은 생각이야

운영 팀이 자체 배포에 사용했습니다 생산 환경의 우리는 스스로를 생산 기술자라고 부릅니다 맞습니까? 그래서 우리는 안정적이고 [INAUDIBLE]의 소유권을 가지고 있습니다 비즈니스 찾고 고객 찾고 그러나 그때 우리가 SLO와 분리 할 때 개발자 및 운영 엔지니어, 이제 우리는 인프라를 만들고 있습니다

코드로서의 코드로서의 구성 새로운 변경 사항을 추진하는 소유권이 운영에 있습니다 그것이 구성 및 인프라라면 개발 팀이 새로운 코드를 소유하고 있습니다 생산에 들어가기

그리고 그런 식으로, 우리는 개발을 멈출 필요가 없다는 것을 알고 있습니다 프로덕션에 새로운 코드를 배포하는 방법 문제 해결 방법에 대한 기술 자료 모음 이 경고 때문에, 그들은 새로운 아이디어를 밀어 때 문제가 발생하면 경고 메시지가 표시됩니다 개발자가 아닌 개발자에게 곧바로 갈 것입니다 그 변화들에 대해 아는 바가없는 사람에게 코드에서 문화의 변화는 지속되지만 듣지는 않습니다

이것은 가장 힘든 일입니다 맞죠? 우리는 이것을 우리의 지도력에 알릴 수 있습니다 그들은 모두 아이디어를 얻습니다 그리고 첫 번째 의견은 알고 있습니다 문화 혁신, 당신은 이야기해야합니다

모든 사람들이 합의에 도달했는지 확인하십시오 그래서 우리는 많은 [비 숙련 된] 세미나를하기 시작했습니다 앞선 엔지니어링 팀이이 아이디어를 추진 그들이 선상에 있는지 확인하십시오 그리고 우리는 무엇이 일어나야하는지 물었다 그리고 우리가 그들에게서 필요로 할 것 인 것은 무엇이 도움이되는지에 관해 안다

그리고 우리가 한 다른 것들 우리는 특별 전담반을 만들었지? 그래서 우리는 특별 전담반을 만들거나 팀을 바칩니다 툴셋을 만들려면, 맞습니까? 우리는 애플리케이션 배포를하지 않습니다 우리는 파이프 라인, CI / CD 파이프 라인, 점진적 변경이 파이프 라인에 포함됩니다 위험 관리는 파이프 라인에 내장되어 있습니다 우리 개발팀에게는 아무런 생각이 없습니다

그들이 새로운 아이디어를 추진하려고한다면 문제가 발생하기 시작하면 문제가 발생하기 쉽습니다 다시 돌아갈 수 있습니다 따라서 우리는이 유형의 도구를 제공하는 팀을 만들려고합니다 엔지니어링 팀에게도 도움이됩니다 따라서 로깅 및 모니터링도 마찬가지입니다

QA 자동화 – QA 자동화, 보안 기능이 없습니다 아직 자동화 우리는이 다중 계획 조직 변화를 가지고 있습니다 그리고 SRE의이 모델에 맞춰보십시오 우리가 모든 것을 제공하려고 노력하는 동안 우리 SRE를위한 동일한 툴 세트에서, 우리는 또한 실제로 일하는 SRE 서비스를 가지고 있습니다

프로젝트에서 해당 플랫폼 솔루션을 연결하려고 시도합니다 실제 서비스에도 적용됩니다 나는 정말로 모든 이점을 말할 수는 없다 우리는 여전히 있기 때문에 지금 당장 가지고 있습니다 SRE 채택 단계의 하지만 그때 우리는 기대하고 있습니다

측정과 함께 우리의 서비스에 대한 더 나은 가시성을 가질 수있다 생산 과정에서 일어나는 모든 일 그리고 평균 복구 시간을 줄이는 것은 분명합니다 그래서 SRO를 만나 릴리스 시간을 줄이려고 노력했습니다 CI / CD 파이프 라인 자동화 운영 리소스를 최적화 할 수 있습니다 그래서 나는 이것이 나의 마지막 세션이라고 생각한다

우리와 함께 해줘서 고마워 이제 너는 너의 가족에게 갈지도 몰라 [음악 재생]