본문 바로가기

개발

SRE 7장 - 구글의 발전된 자동화 SRE에게 자동화는 만병통치약이 아니라 주어진 방향으로 힘을 더하는 것과 같다. 목표는 결국 고수준의 시스템, 즉 자율 시스템을 디자인하는 것이다. 자동화의 가치 자동화의 진정한 가치는 무엇일까? 일관성 시스템이 스케일(scale) 조정은 자동화를 채택하는 주된 이유이기는 하지만, 그 외에도 많은 이유들이 존재한다. 기본적으로 한 사람 또는 수백 명의 사람이 수행하는 모든 작업들은 매번 같은 방식으로 수행되는 것들이 아니다. 아무리 노력하더라도 사람이 기계처럼 일관성을 가지기란 불가능에 가깝다. 이처럼 예상치 못한 일정하지 못한 방식은 실수와 간과로 인해 데이터 품질의 문제를 유발하며, 결국 신뢰성의 문제로 발전하게 된다. 정확하게 정의된 업무 범위와 정해진 절차를 수행하는 데 있어 일관성의 가치는 다양.. 더보기
Mac OS에서 Minikube로 Kubernetes 로컬 개발환경 구축하기 Minikube란? 기본적으로 k8s 사용을 위해서는 master 노드와 slave(worker) 노드를 세팅하여 사용해야 한다. GKE, AWS 등의 서비스를 이용할 수도 있지만, 학습을 위해서는 돈이 나갈 수 있으므로.. 하나의 머신에서 간단하게 k8s를 구동해볼 수 있는 minikube를 많이들 쓴다. 대부분의 기능을 사용하는데에 문제가 없다고 한다. Install 1. Docker Desktop을 설치 https://docs.docker.com/docker-for-mac/install/ 에서 Docker Desktop on Mac를 설치한다 Install Docker Desktop on Mac docs.docker.com 2. Hyperkit 설치 여부 확인 (Docker Desktop에 포함) .. 더보기
SRE 5장 - 삽질은 이제 그만! 평범하게 운영 중인 당신의 시스템에 운영자가 손을 대야 한다면 그 시스템에 버그가 있다는 뜻이다. - 칼라 가이저, 구글 SRE 이 장에서는 운영 업무라는 단어의 의미가 사람에 따라 다르게 해석될 수 있으므로 삽질이라고 표현하기로 하겠다. 삽질의 정의 단순히 '하고 싶지 않은 일'을 의미하지만은 않는다. 그렇다고 관리를 위한 허드렛일이나 지저분한 일을 의미하는 것도 아니다. 반드시 수행해야 하며 삽질로 분류해서는 안 되는 업무들도 있다. 이런 업무들이 바로 부하를 일으킨다. 팀 회의나, 둘러앉아 목표를 결정하는 일, 업무 보고, 그리고 구인을 위한 서류 작업 같은 업무들을 포함한다. 지저분한 일은 간혹 장기적으로는 가치가 있을 수도 있다. 그런 경우에는 삽질로 분류해서는 안 된다. 시스템에서 경고와 관련.. 더보기
SRE 4장 - 서비스 수준 목표 서비스를 운영하는 데 있어 가장 중요한 지표들과 이 지표들을 측정하고 평가하는 방법에 대한 올바른 이해 없이는 서비스를 올바르게, 알아서 잘 돌아가도록 관리한다는 것은 불가능하다. 그래서 여기서는 사용자에게 필요한 서비스의 적정 수준을 정의하고 제공하는 방법에 대해 이야기하고자 한다. 이 내용은 우리 저자들의 직감과 경험(오... 직감과 경험...), 그리고 사용자가 서비스 수준 척도(SLI), 서비스 수준 목표(SLO), 서비스 수준 협약(SLA) 등을 어떻게 정의하고 있는지에 대한 이해를 바탕으로 하고 있다. 이 세 가지를 살펴보면 주요 지표들의 기본 속성과 각 지표들의 적정 값, 그리고 기대했던 수준의 서비스를 제공하지 못했을 때의 대처 방안 등을 알 수 있다. 결국 어딘가에 문제가 발생했을 때 올.. 더보기
Effective Java ( 이펙티브 자바 ) - 아이템 51 메서드 시그니처를 신중히 설계하라 이번 아이템에는 개별 아이템으로 두기 애매한 API 설계 요령들을 모아 놓았다. 배우기 쉽고, 쓰기 쉽고, 오류 가능성이 적은 API를 만들 수 있을 것이다. 메서드 이름을 신충히 짓자 항상 표준 명명 규칙을 따라야 한다. 일관되고, 널리 받아들여지는 이름을 사용하는 것이다. 긴 이름은 피하자. 편의 메서드를 너무 많이 만들지 말자 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다. 인터페이스도 마찬가지다. 메서드가 너무 많으면 이를 구현하는 사람과 사용하는 사람 모두를 고통스럽게 한다. 확신이 서지 않으면 만들지 말자. 매개변수 목록은 짧게 유지하자 4개 이하가 좋다. 일단 4개가 넘어가면 기억하기가 쉽지 않다. IDE를 사용.. 더보기
Effective Java ( 이펙티브 자바 ) - 아이템 50 적시에 방어적 복사본을 만들라 자바는 안전한 언어다. 자바를 쓰는 즐거움 중 하나다. 하지만 아무리 자바라 해도 다른 클래스로부터의 침범을 아무런 노력 없이 다 막을 수 있는 건 아니다. 그러니 클라이언트가 여러분의 불변식을 깨뜨리려 혈안이 되어 있다고 가정하고 방어적으로 프로그래밍해야 한다. 충분한 시간을 투자하자. 어떤 객체든 그 객체의 허락 없이는 외부에서 내부를 수정하는 일은 불가능하다. 하지만 주의를 기울이지 않으면 자기도 모르게 내부를 수정하도록 허락하는 경우가 생긴다. 흔히 발생하는 문제다. 예컨대 기간을 표현하는 다음 클래스는 한번 값이 정해지면 변하지 않도록 할 생각이었다. public final class Period { private final Date start; private fi.. 더보기
Effective Java ( 이펙티브 자바 ) - 아이템 49 - 8장 - 메서드 이번 장에서는 메서드를 설계할 때 주의할 점들을 살펴본다. 구체적으로는 매개변수와 반환값을 어떻게 처리해야 하는지, 메서드 시그니처는 어떻게 설계해야 하는지, 문서화는 어떻게 해야 하는지를 다룬다. 생성자에도 적용된다. 주요 관점은 사용성, 견고성, 유연성에 집중한다 매개변수가 유효한지 검사하라 메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 객체 참조는 null이 아니어야 하는 식이다. 이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다. "오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다"는 일반 원칙의 한 사례이기도 하다. 메서드 몸체가 실행되기 전에 매개변수를 확인한다면 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다. 그렇지 못하면, .. 더보기
Effective Java ( 이펙티브 자바 ) - 아이템 48 스트림 병렬화는 주의해서 적용하라 주류 언어중, 동시성 프로그래밍 측면에서 자바는 항상 앞서갔다. wait/notify -> Executor -> fork-join -> parallel 스트림의 순서로 자바로 동시성 프로그램을 작성하기가 점점 쉬워지고는 있으나, 이를 올바르고 빠르게 작성하는 일은 여전히 어려운 작업이다. 동시성 프로그래밍을 할 때는 안전성(safety)과 응답 가능(liveness) 상태를 유지하기 위해 애써야 하는데, 병렬 스트림 파이프라인 프로그래밍에서도 다를 바 없다. 아이템 45에서 다루었던 메르센 소수를 생성하는 프로그램을 다시 살펴보자. public static void main(String[] args) { primes().map(p -> TWO.pos(p.intValueE.. 더보기