본문
Everything your organization relies upon to produce and maintain code should be scalable in terms of overall cost and resource consumption. In particular, everything your organization must do repeatedly should be scalable in terms of human effort.
When your project doubles in scope and you need to perform that task again, will it be twice as labor intensive?Will you even have the human resources required to address the issue next time? .....
the development of that software also needs to scale, both in terms of human time involvement and the compute resources that power your development workflow. .....
Finally, the most precious asset of a software organization—the codebase itself—also needs to scale....
Many questions, such as “How long does it take to do a full build?”, “How long does it take to pull a fresh copy of the repository?”, or “How much will it cost to upgrade to a new language version?” aren’t actively monitored and change at a slow pace.
⇢ 확장 가능의 대상은 "노동", "개발 자원", "코드" 정도로 축약해서 생각해볼 수 있다.
⇢ 비용, 사용하는 자원 측면 모두에서 확장/축소 가능해야 한다.
Policies That Don’t Scale
In 2012, we tried to put a stop to this with rules mitigating churn: infrastructure teams must do the work to move their internal users to new versions themselves or do the update in place, in backward-compatible fashion. This policy, which we’ve called the “Churn Rule,” scales better: dependent projects are no longer spending progressively greater effort just to keep up. We’ve also learned that having a dedicated group of experts execute the change scales better than asking for more maintenance effort from every user: experts spend some time learning the whole problem in depth and then apply that expertise to every subproblem. Forcing users to respond to churn means that every affected team does a worse job ramping up, solves their immediate problem, and then throws away that now-useless knowledge. Expertise scales better.
⇢ 정책적으로 하위 층의 개발 프로젝트에서 의존성 문제를 해결하려고 한다.
⇢ 전문성 이라는것은 상대적인 것이지만,
⇢ 서비스 개발/배포 환경 입장에서 볼 때, 인프라 전문성은 서비스 개발자가 건드는 영역이 아니다.
⇢ 인프라(클라우드 처럼)를 잘 구성해 놓으면 이를 기반으로 여러가지 서비스를 만들 수 있다.
⇢ 수 많은 서비스가 각자 의존성을 체크하는 시간/노력/비용을 낭비하기 보다, 이들 서비스가 의존하고 있는 인프라를 호환 가능하도록 설계 해 두는 것이 바람직하다.
⇢ 하위 버전에 호환 가능하도록 설계하는 능력이 중요한것 같다.
Policies That Scale Well
One of our favorite internal policies is a great enabler of infrastructure teams, protecting their ability to make infrastructure changes safely. “If a product experiences outages or other problems as a result of infrastructure changes, but the issue wasn’t surfaced by tests in our Continuous Integration (CI) system, it is not the fault of the infrastructure change.” More colloquially, this is phrased as “If you liked it, you should have put a CI test on it,” which we call “The Beyoncé Rule.”(This is a reference to the popular song “Single Ladies,” which includes the refrain “If you liked it then you shoulda put a ring on it.”)
⇢ "비욘세 규칙"은 비욘세의 "싱글 레이디" 곡의 "put a ring on it" 이라는 부제를 지칭한다.
⇢ 이 말은 "책임을 져야 한다"는 말이고, "put a CI test on it" 이라고 대신 표현했다.
⇢ 즉 인프라 변화가 문제를 발생시키더라도, 이를 인프라 잘못으로 규정해서는 안된다는 것
⇢ 인프라 팀은 인프라대로 하위호완 가능하도록 기능 개발 계속해 나가고 있으며
⇢ 서비스 개발자는 그 변화를 수용할 수 있는지 확인 가능한 CI 테스트를 잘 작성해둬야 한다.
⇢ 결국 선순환 구조로 돌아간다. 인프라는 자체적인 마일스톤을 따라가지만, 하위버전 호환 가능하도록 설계된 구조를 가진다.
⇢ 이를 활용해 서비스가 개발되며, 하위버전 호환 가능하므로 코드 작성 자체에는 문제가 없다.
⇢ 하지만 내부적인 문제는 터질 수 있으며, 이는 서비스 개발자의 CI 테스트가 잡아낸다.
⇢ 문제가 보고되면, 해당 문제를 인프라 팀의 전문가 그룹이 해결한다.
⇢ 서비스 개발자가 해당 문제를 해결하는 workaround 를 만들려고 노력하지 않는다.
We’ve found that expertise and shared communication forums offer great value as an organization scales. New experts grow. If you have a hundred engineers writing Java, a single friendly and helpful Java expert willing to answer questions will soon produce a hundred engineers writing better Java code. Knowledge is viral, experts are carriers, and there’s a lot to be said for the value of clearing away the common stumbling blocks for your engineers.
⇢ 사내 커뮤니티를 활성화 하려는 노력도 중요하다.
⇢ 초기에는 전문가 그룹이 소수로 구성되지만, 적극적으로 전문성이 스며들게 만든다.
⇢ 그렇게 또 다른 전문가들이 (비교적) 단시간내에 길러지며
⇢ 이는 현재 기술적 어려움이 어느 시점에서는 마일드한 수준의 문제가 되며
⇢ 더 기술을 진보시키는 계기가 될 것이다
⇢ 거인의 어깨에 올라탄다와 비슷한 맥락이다.
Example: Compiler Upgrade
The more frequently you change your infrastructure, the easier it becomes to do so. We have found that most of the time, when code is updated as part of something like a compiler upgrade, it becomes less brittle and easier to upgrade in the future. In an ecosystem in which most code has gone through several upgrades, it stops depending on the nuances of the underlying implementation; instead, it depends on the actual abstraction guaranteed by the language or OS. Regardless of what exactly you are upgrading, expect the first upgrade for a codebase to be significantly more expensive than later upgrades, even controlling for other factors.
⇢ 안 해본것을 처음 다룰 때는 엄청난 양의 노력/시간이 투입된다.
⇢ 하지만, 그 처음의 고비를 넘기고 지속적으로 시스템, 서비스의 버전을 올려나갈 수록 쉬워진다.
⇢ 당연한 말이지만, 실천에 옮기기에는 쉽지 않다.
⇢ 오픈소스 프로젝트 공개 후, 1차 메인터넌스 조차 거치지 않는 경우가 많으며
⇢ 영원히 방치되는 경우도 많다.
⇢ 일종의 가속도를 얻어야 한다. 처음 체계가 잘 잡히면, 각 프로젝트 유지/보수에 드는 노력은 점점 줄어들 것이다.
⇢ 이와는 별개로 혼자만 이 내용을 알아서는 안된다. 모두가 같은 생각을 가지도록 유지하는것도 중요하다. 가령 10년간 유지/보수 하던 사람이 퇴사한다고 해서, 그 자리를 메꾸는 후임자가 또 다시 그만한 노력을 들여서는 안된다는 것이다.
⇢ 정책적으로 해결이 필요한 부분이다.
The underlying lesson is not about the frequency or difficulty of compiler upgrades, but that as soon as we became aware that compiler upgrade tasks were necessary, we found ways to make sure to perform those tasks with a constant number of engineers, even as the codebase grew.
⇢ 이 모든 노력은 코드의 양이 계속해서 증가하더라도
⇢ 여기에 엮인 엔지니어의 수는 가능한 한 "그대로"를 유지하기 위한 노력이다.
Shifting Left
One of the broad truths we’ve seen to be true is the idea that finding problems earlier in the developer workflow usually reduces costs.
⇢ 이것도 당연한 말이다. 그러나 실천은 생각보다 쉽지 않다.
⇢ 마인드셋, 이를 뒷받침 할 제도적 정책이 확립되어 있으면 좋을것 같다.
⇢ 코드는 결국 유기적으로 엮여 있고, 관심있는 코드, 그렇지 않은 코드, 어정쩡한 코드 등으로 나뉜 시선으로 전체 코드를 바라보게 된다.
⇢ 어느 한 쪽에서 터지는 문제는 다른 쪽에도 영향을 줄 수 밖에 없는것이 자연스럽다.
⇢ 하지만 관심 없는쪽의 코드라고 방치했다가는, 나중에 모든것을 다 뜯어 고쳐야 하는 수고스러움이 발생할 수 있다. 되도록이면 설계 단계에서 이를 잡아내는것이 좋다.