https://wa.aws.amazon.com/

The top reason why companies and governments are moving to the cloud is the speed and agility with which they can change customer experiences, and security has become one of the top selling points for choosing No. 1 Amazon Web Services, according to Amazon Web Services CEO Andy Jassy.

In a wide-ranging technology leadership talk at CERAWeek 2019, Jassy talked about the cloud’s value proposition and the challenges it presents for some companies, and the new technologies most piquing his interest.

He also spoke to Amazon’s culture, the importance of hiring “builders,” speed to market and having senior leaders who are open to big ideas and tolerate failure in the roughly half-hour conversation at the annual energy conference in Houston hosted by IHS Markit.

And Jassy filled in the audience about Amazon’s prohibition on PowerPoint presentations.

기업과 정부가 클라우드로 전환하는 가장 큰 이유는 고객 경험을 바꿀 수 있는 속도와 민첩성 때문이며, 보안은 아마존 웹 서비스 1위를 선택하는 데 있어 최고의 판매 포인트 중 하나가 되었다고 Andy Jassy 아마존 웹 서비스 CEO가 말했다.

Jassy는 CERAWeek 2019에서 열린 광범위한 기술 리더십 강연에서 클라우드의 가치 제안과 클라우드가 일부 기업에 제시하는 과제, 그리고 그의 관심을 가장 자극하는 새로운 기술에 대해 이야기했다.

그는 또한 IHS 마킷이 주최하는 휴스턴에서 열린 연례 에너지 컨퍼런스에서 약 30분 동안 열린 대화에서 큰 아이디어에 개방적이고 실패를 용인하는 아마존의 문화와 "Builder" 고용의 중요성에 대해 이야기했다.

그리고 Jassy는 청중들 속에서 Amazon의 파워포인트 프레젠테이션 금지에 대해 이야기했다.

Jassy On The Value Proposition Of Cloud

AWS is a $30 billion revenue-run-rate business that’s growing about 45 percent year over year in the midst of a “titanic shift” to the cloud, Jassy said.

Cost is almost always the “conversation starter” when it comes to companies moving to the cloud. Not having to lay out capital up front for servers and data centers, and instead paying for cloud as a variable expense as they consume it, is very attractive, he said.

“The variable expense is lower than what virtually every company can do on its own because we have such large scale that we pass on to customers in the form of lower prices,” Jassy said. “We’ve lowered our prices on 70 different occasions in the last 10 years—largely in the absence of any competitive pressure to do so—just because the DNA inside Amazon is we relentlessly work to take out costs to give those back to customers so they can do more.

“In the cloud, you just provision what you need,” Jassy said. “If it turns out you need more, you seamlessly provision up in minutes, and if it turns out you need less, you give it back to us and stop paying for it.”

But the No. 1 reason enterprises and governments are moving to the cloud is the agility and speed with which they can change their customer experiences, according to Jassy.

“If you look at most companies’ on-premise infrastructure, to get a server typically takes 10 to 12 weeks,” he said. “If you actually find something that you like and want to roll out, it takes longer, and then you have to build all of this surrounding infrastructure software like compute and storage and database and analytics and machine learning. In the cloud, you can provision thousands of servers within minutes, and then we have 165 services that you can put together and use in whatever combination so want. You get from an idea to implementation in several orders of magnitude faster.”

Jassy는 AWS는 "타이타닉 클라우드 전환"으로 인해 매년 약 45%씩 성장하고 있는 300억 달러의 수익률의 사업이라고 말했다.

클라우드로 전환하는 기업의 경우 비용은 거의 항상 "대화 시작자"이다. 서버와 데이터 센터를 위한 자본을 미리 마련할 필요가 없고, 대신 클라우드를 소비함에 따라 변동 비용으로 비용을 지불하는 것이 매우 매력적이라고 그는 말했다.

Jassy는 "변동비용은 가격 인하 형태로 고객에게 전가할 정도로 규모가 크기 때문에 사실상 모든 기업이 스스로 할 수 있는 비용보다 낮다"고 설명했다. "우리는 지난 10년 동안 70여 차례에 걸쳐 가격을 인하했는데, 그 이유는 단지 아마존 내부의 DNA가 고객들에게 더 많은 일을 할 수 있도록 그 비용을 회수하기 위해 끊임없이 일하고 있기 때문이다.

"클라우드에서는 필요한 것을 프로비저닝하기만 하면 됩니다,"라고 Jassy는 말했다. "더 필요한 것이 드러나면 몇 분 만에 원활하게 프로비저닝을 하고, 덜 필요한 것이 드러나면 다시 돌려주고, 더 이상 비용을 내지 않는 겁니다."

그러나 Jassy에 따르면 기업과 정부가 클라우드로 전환하는 첫 번째 이유는 고객 환경을 변화시킬 수 있는 민첩성과 속도라고 한다.

그는 "대부분의 기업의 사내 인프라를 살펴보면 서버를 구하려면 일반적으로 10~12주가 걸린다"고 말했다. "실제로 롤아웃하고 싶은 것을 찾으면 시간이 더 오래 걸리고 컴퓨팅, 스토리지, 데이터베이스, 분석 및 기계 학습과 같은 주변 인프라 소프트웨어를 모두 구축해야 하는 겁니다. 클라우드에서는 수천 대의 서버를 몇 분 내에 프로비저닝할 수 있으며, 원하는 조합에 모두 사용할 수 있는 165개의 서비스를 갖추고 있으며, 아이디어에서 구현까지 훨씬 더 빠르게 몇 가지 순서를 밟게 될 겁니다."

Jassy On Different Industries’ Speeds To The Cloud

Every imaginable vertical business segment is moving significantly to the cloud, according to Jassy.

“The three industries that I would say were most conservative moving were financial services, health care and oil and gas,” Jassy said. “We have this very strong view that we’ve had for a while, which I think you’re seeing borne out in the market, that in the fullness of time—and I don’t know if that’s 10 years from now or 20 years from now—relatively few companies will own data centers, and those that do will have much smaller footprints. All of that is moving to the cloud, and really the question now is … just when and how fast and in what order.”

Jassy에 따르면 상상할 수 있는 모든 수직적 비즈니스 부문이 클라우드로 크게 이동하고 있다고 한다.

"내가 가장 보수적인 움직임이라고 말하고 싶은 세 가지 산업은 금융 서비스, 건강 관리, 석유와 가스였다."라고 Jassy는 말했다. "우리는 한동안 우리가 가지고 있던 매우 강한 관점을 가지고 있는데, 그것은 당신이 시장에서 잉태되고 있는 것 같으며, 나는 그것이 지금부터 10년 후인지 아니면 20년 후인지 모르겠다. 상대적으로 적은 수의 회사들이 데이터 센터를 소유하게 될 것이고, 그러한 회사들은 훨씬 더 작은 발자국을 갖게 될 것이다. 이 모든 것이 클라우드로 전환되고 있으며, 이제 정말 궁금한 것은 ... 언제, 얼마나, 그리고 어떤 순서로 진행하느냐입니다."

Jassy On Challenges Encountered By Companies Moving To The Cloud

There always are some technical challenges when shifting business functions from on-premises to a different medium such as the cloud, but the reality is most of enterprises’ biggest challenges are cultural and leadership- and process-oriented rather than technical, according to Jassy.

“The senior leadership team has to have conviction that you’re going to make a move to the cloud because inertia is a very powerful thing, and it’s easy to block in the middle,” Jassy said. “Coupled with that, you need to set an aggressive top-down goal that forces the organization to move faster organically than it otherwise would.”

General Electric’s chief information officer, for example, decided to move 50 of the company’s applications to AWS in 30 days, according to Jassy.

“She got her technical leaders together, and she said for 45 minutes, they all told her how dumb it was and how it was impossible,” Jassy said. “She listened to them and said, ‘I hear you all, but we’re going to do it, so let’s giddy-up.’ They got to about 40 applications in 30 days, but in the process they learned their security model, their compliance model and they figured out how to architect and operate in the cloud. They had a lot of success and momentum, and now they’re in the process of moving 9,000 applications to AWS.”

Companies sometimes will get paralyzed if they can’t figure out how to move every last application, Jassy said. When AWS goes through a deep portfolio analysis with companies, it characterizes which applications are easiest to hardest to move, and which ones need to be rearchitected.

“Lots of your applications are pretty easy to move,” Jassy said. “And it turns out getting those early workloads in the cloud informs how the hardest workloads that you’re going to move last will be moved as well.”

Training also is key to companies successfully moving to the cloud.

“The companies that really succeed are the ones that train significant numbers of people,” Jassy said. “We train hundreds of thousands of people a year just for that reason because once you get that firm base and experience, it becomes much easier.”

Jassy에 따르면, 사내에서 클라우드와 같은 다른 미디어로 비즈니스 기능을 전환할 때는 항상 기술적인 문제가 있지만, 기업의 가장 큰 과제는 기술보다는 문화적, 리더십 및 프로세스 지향이라는 것이 현실이라고 한다.

Jassy는 "관성이 매우 강력한 것이고, 중간에 차단하기도 쉽기 때문에 수석 리더십 팀은 클라우드로의 전환을 할 것이라는 확신을 가져야 한다"고 말했다. "그것과 결합하여, 조직이 다른 방법보다 유기적으로 더 빨리 움직이게 하는 공격적인 하향식 목표를 세워야 한다."

예를 들어 제너럴 일렉트릭(General Electric)의 최고 정보책임자는 회사 신청서 중 50개를 30일 안에 AWS로 옮기기로 했다고 Jassy는 전했다.

"그녀는 그녀의 기술 지도자들을 모았고, 그녀는 45분 동안 그것이 얼마나 어리석은지 그리고 그것이 어떻게 불가능한지에 대해 그녀에게 말했다."라고 Jassy는 말했다. "그녀는 그들의 말을 듣고는 '모두들 들었지만 우리가 할 테니 어지럽히도록 합시다'라고 말했다. 30일 동안 40여 개의 애플리케이션에 도달했지만, 이 과정에서 보안 모델과 규정 준수 모델을 익히고 클라우드에서 설계 및 운영 방법을 알아냈다. 이들은 많은 성공과 추진력을 가지고 있었고, 지금은 9,000개의 애플리케이션을 AWS로 옮기는 과정에 있다."

Jassy는 "기업들이 모든 애플리케이션을 어떻게 옮길지 알지 못하면 때때로 마비될 것"이라고 말했다. AWS는 기업과 심층적인 포트폴리오 분석을 할 때 어떤 애플리케이션을 가장 이동하기 쉽고 어떤 애플리케이션을 다시 설계해야 하는지를 특징으로 한다.

Jassy는 "여러 애플리케이션은 이동하기가 매우 쉽다"고 말했다. "그리고 클라우드에서 초기 워크로드를 확보하면 마지막으로 이동할 가장 어려운 워크로드도 어떻게 이동할 것인지 알 수 있다."

클라우드 환경으로 성공적으로 전환하기 위해서는 교육도 중요하다.

"진짜 성공한 회사들은 많은 사람들을 훈련시키는 회사들이다,"라고 Jassy는 말했다. "저희는 일단 그런 확고한 기반과 경험을 쌓으면 훨씬 쉬워지기 때문에 그런 이유만으로 연간 수십만 명을 훈련시키고 있는 겁니다."

Jassy On Cloud Security

Security is the top priority for Amazon, according to Jassy, and it will drop everything if it thinks something needs shoring up.

AWS has been in the market for just about 13 years, and in the first eight or so, security was the biggest “blocker” for enterprises and governments moving to the cloud, he said.

“There wasn’t a specific problem or gap, it was just the nervousness of a different model,” he said. “But I would say in the last four to five years, security probably has become one of the top few selling points of people moving to AWS and the cloud.”

That comes down to the numbers of people Amazon has focused on the cloud and capabilities it gives to customers to protect themselves, Amazon’s compliance, certification and security practices, the way AWS is architected, and the way it gives unusually fine-grained access control that allow companies to do things that are much harder on-premises, he said.

“Most people come away feeling like their security posture improves when they’re in AWS versus when they’re on-premises,” Jassy said. “If you’re a CIO, you have all these servers that you’ve distributed over many years —you don’t know where they all are. You don’t know what things are running under people’s desks.”

“In the cloud, you can make a single API call and know where every single one of those servers are, who’s checked them out and what access control they have, and the ability to change it and put more guardrails in place,” he said.

Jassy에 따르면, 아마존의 최우선 과제는 보안이며, 만약 아마존이 무언가를 개선해야 한다고 생각한다면, 모든 것을 포기할 것이다.

AWS는 불과 13년 동안 시장에 존재해왔으며, 처음 8년 정도에는 클라우드로 전환하는 기업과 정부에게 보안이 가장 큰 "차단기"였다고 그는 말했다.

그는 "특정 문제나 공백이 있는 게 아니라 다른 모델의 초조함일 뿐"이라고 말했다. "하지만 지난 4~5년 동안 보안은 아마도 AWS와 클라우드로 이전하는 사람들의 몇 안 되는 영업 포인트 중 하나가 되었을 겁니다."

이는 아마존이 스스로를 보호하기 위해 고객에게 제공하는 클라우드와 기능, 아마존의 컴플라이언스, 인증 및 보안 관행, AWS의 설계 방식, 그리고 기업이 사내에서 훨씬 어려운 일을 할 수 있도록 하는 비정상적으로 미세하게 세분화된 액세스 제어를 제공하는 방식으로 귀결된다.e는 말했다.

"대부분의 사람들은 그들이 AWS에 있을 때 보다 그들이 사내에 있을 때 그들의 보안 태세가 향상되는 것처럼 느끼면서 떠난다"고 Jassy는 말했다. "CIO인 경우 수년 동안 배포한 서버를 모두 보유하게 됩니다, 모두 어디에 있는지 알 수 없습니다, 사람들 책상 밑에서 무슨 일이 벌어지고 있는지 모르잖아."

그는 "클라우드에서는 단일 API 호출을 할 수 있으며 서버 한 대 한 대당 어디에 있는지, 누가 체크아웃했는지, 어떤 액세스 제어를 가지고 있는지, 이를 변경하고 더 많은 가드레일을 배치할 수 있다"고 말했다.

Jassy On What New Technologies Excite Him

Machine learning and artificial intelligence, the Internet of Things and edge computing, and robotics and drones are among the new technologies that capture Jassy’s imagination and will be game-changers to business, he said.

“Most applications in five to 10 years will be infused in some way with machine learning and artificial intelligence,” Jassy said. “Companies will work at different layers of a stack. You’ll have expert machine- learning practitioners that will build models for you on the frameworks. You’ll have everyday developers and data scientists that use this abstraction which we have that’s called SageMaker, which is really a managed service to build, train, tune and deploy machine-learning models. We have a lot of customers who will be able to do what they typically think of as AI services that closely mimic human cognition—so text to speech, speech to text, translation across a lot of languages, natural language processing—so you don’t have to read and figure out what’s in every piece of corpus text. You can kind of get meaning from something in a machine-learning fashion—the ability to recognize video and what’s in it, images and what’s in it.

“A second technology that we’re pretty excited about is what people call IoT, the Internet of Things or edge computing,” Jassy said. “When we think about 10 years from now and when we think about hybrid, we don’t think the on-premises part is going to be in data centers. We think the on-premises part will be billions of these devices that sit at the edge—in our houses, in our offices, in factories and oil fields and agricultural fields and planes and ships, and automobiles—everywhere. These devices have relatively little CPU and relatively little disc, and so the cloud becomes disproportionately important in implementing all of those devices.”

Jassy pointed to John Deere, which he said has a few hundred thousand telematically enabled tractors collecting planting information in real time, sending it to the AWS cloud, doing analytics and then sending the information back down to planters to take action. And to monitor its liquified natural gas facilities, Woodside Energy has set up AWS’ IoT capabilities on all sensors, enabling them to detect well in advance when foaming is happening so it doesn’t have unplanned downtime, Jassy said.

“The amount of capabilities of what you can do at the edge—not just collecting the data and analyzing it in the cloud, and then taking action back on the device itself, but also building machine-learning models in the cloud and pushing the predictions and inferences over to the edge—you’re going to see that as a real game-changer,” he said.

There will be a number of activities done today by humans that in the future will be done by robots and drones, Jassy said.

“We’re starting to see a lot of oil and gas companies who are starting to build drones,” Jassy said, noting AWS’ RoboMaker robotics service. “They’re starting to build these drones that go up into the rigs and evaluate whether there’s safety issues or whether there’s a leak or whether the gates have rust—all kinds of things that are dangerous and arduous for human beings to do that you’re going to have robots do. And then we’ll use the human beings on more value-added activities where their safety and their intellect are better utilized.”

"기계학습과 인공지능, 사물인터넷과 엣지 컴퓨팅, 로봇과 드론 등이 Jassy의 상상력을 사로잡는 신기술 중 하나이며 비즈니스에 판도를 바꾸는 역할을 할 것"이라고 그는 말했다.

"5년에서 10년 안에 대부분의 어플리케이션은 어떤 식으로든 기계학습과 인공지능에 주입될 것입니다,"라고 Jassy는 말했다. "기업들은 서로 다른 층의 스택에서 일하게 될 겁니다. 당신은 기계-학습 전문가들을 갖게 될 것이다. 그것은 프레임워크에서 당신을 위한 모델을 만들어 줄 것이다. 매일의 개발자들과 데이터 과학자들이 우리가 가지고 있는 '세이지메이커'라는 추상화를 사용할 겁니다. 이 서비스는 기계 학습 모델을 만들고, 훈련하고, 튜닝하고, 배치하는 관리형 서비스 입니다. 우리는 그들이 일반적으로 생각하는 AI 서비스 즉, 텍스트에서 음성, 음성에서 텍스트로 변환, 많은 언어를 통한 번역, 자연 언어 처리 등을 할 수 있는 많은 고객들이 있다. 그래서 당신은 말뭉치 텍스트의 모든 부분에 무엇이 있는지 읽고 알아낼 필요가 없다. 여러분은 어떤 것에서 의미를 얻을 수 있다. 즉, 비디오와 그 안에 있는 것, 이미지, 그리고 그 안에 있는 것을 인식하는 능력이다.

Jassy는 "우리가 상당히 흥분한 두 번째 기술은 사물인터넷(IoT), 즉 엣지 컴퓨팅(Edge Computing)이라고 부르는 것이다"라고 말했다. "지금으로부터 10년 정도 뒤에 생각하고 하이브리드라고 생각하면 사내 부분은 데이터센터에 없을 겁니다. 우리는 사내에서 집, 사무실, 공장, 유전, 농경지, 비행기, 선박, 자동차 등 모든 곳에서 가장자리에 있는 수십억 개의 장치들이 될 것이라고 생각한다. 이러한 기기는 CPU와 디스크가 상대적으로 적기 때문에 클라우드는 이러한 모든 기기를 구현하는 데 있어 불균형적으로 중요해진다."

Jassy는 수십만 대의 텔레매틱스 기능이 있는 트랙터가 실시간으로 정보를 수집하여 AWS 클라우드에 전송하고 분석을 한 다음, 정보를 다시 플랜터에게 보내 조치를 취하도록 했다고 말한 John Dere를 가리켰다. 그리고 우드사이드 에너지는 액화천연가스 시설을 감시하기 위해 모든 센서에 AWS의 IoT 기능을 설정해 포밍이 발생했을 때 미리 잘 감지해 계획되지 않은 다운타임을 방지할 수 있도록 했다고 Jassy는 말했다.

"데이터를 수집하여 클라우드에서 분석한 다음 장치 자체에 대한 조치를 취하는 것뿐만 아니라 클라우드에 머신러닝 모델을 구축하고 예측과 추론을 가장자리에 밀어 넣는 것 등 가장자리에서 할 수 있는 기능의 양으로 볼 수 있을 것입니다,"라고 그는 말했다.

"미래에는 로봇과 드론이 할 수 있는 여러 가지 활동이 있을 것"이라고 Jassy는 말했다.

Jassy는 AWS의 로보메이커 로봇 서비스에 주목하면서 "드론 제작에 나서는 석유·가스 업체들을 많이 보기 시작했다"고 말했다. "그들은 이 드론을 제작하기 시작했는데, 이 드론은 안전상의 문제가 있는지, 새는 곳이 있는지, 게이트에 녹이 슬었는지 등을 평가하기 시작했는데, 이 모든 것들은 인간이 로봇이 하게 될 위험하고 힘든 것들이었습니다. 그리고 나서 우리는 인간을 그들의 안전과 지성이 더 잘 활용되는 부가가치 활동에 이용할 것이다."

Jassy On Joining Amazon

In the spring of 1997, Jassy was attending Harvard Business School and just returned on a red-eye flight from the West Coast and a final-round interview with business and financial software company Intuit. He was back in Boston for three hours and driving with a friend to New York to see a concert.

Jassy listened to an answering machine message, and it was Amazon, which had an 8 a.m. interview cancellation for an open job.

“I didn’t really know anything about Amazon, but I thought it sounded interesting and, why not, I was there,” Jassy said.

1997년 봄, Jassy는 하버드 경영대학원에 다니고 있었고 방금 서부 해안에서 출발하는 적목 비행과 비즈니스 및 금융 소프트웨어 회사인 Intuit와의 최종 면접을 위해 돌아왔다. 그는 보스턴에서 세 시간 동안 돌아와 친구와 함께 뉴욕으로 가서 콘서트를 보았다.

Jassy는 자동응답기 메시지를 들었는데, 오전 8시 공개 취소를 한 아마존이었습니다.

Jassy는 "아마존에 대해 아는 것은 없지만 흥미롭게 들린다고 생각했고, 왜 아니겠느냐"고 말했다.

Jassy On Amazon’s Culture And The Importance of Speed, ‘Builders’

Jassy joined Amazon a little less than two years after it was founded.

“Amazon was always a place that if you were a builder, you were going to love it,” he said. “When we really thing about our culture at Amazon—we talk about it internally all the time—we’re trying to build a place that builders can build.

“There was this maniacal view that everything you did started with the customer,” Jassy said, “and all your strategies and tactics worked backwards from there. That was really palpable inside the company. I remember there were lots of moments we were all running around like our heads were cut off. We all had jobs that were way too big for us, and we just realized there was this land rush going on, and people were starting to get used to buying online.

“We had this incredible opportunity,” Jassy said. “And one of the things we felt then—and I feel even more strongly about today, maybe 10 times more strongly than I even did in 1997—is that speed disproportionately matters to companies in every size and every stage.”

But, Jassy said, “You can’t have speed at the expense of security and operational performance or safety— that’s a disaster. But the reality is, if you’re in any business where you think speed doesn’t matter, I think you’re kidding yourself. The world is a competitive place. It changes a lot, and that’s what I saw a lot at Amazon.

“There are a few things that we do to try to move quickly—the first is who you hire,” Jassy said. “And we disproportionately index on who we hire on builders. We think of builders as people who are inventors— people who look at customer experiences and try to be honest about what is not right about those and seek to reinvent those; people who realize that launching something is the starting line, not the finish line. At a lot of companies, you get these people who … love to get to launch and then lose interest. Nothing any of us builds catches lightning in a bottle on day one. There’s a lot of iterating and listening to customers.”

In the early days of Amazon, product managers were in one group, engineers in another and the operations folks were in their own group, which led to a lot of “finger-pointing” at each other when projects were late or inadequate, according to Jassy.

Now those employees are together in autonomous groups that are given AWS building blocks and “own their own destiny,” Jassy said, a move that allows Amazon to move more quickly in all of its businesses.

“You don’t get that weird effect where engineers would build something and throw it over the wall to ops, and the ops guys would say, ‘These guys built something that doesn’t work,’” Jassy said. “When you’re carrying the pager, and you get the page at 2:30 in the morning, you have a way of building software a little differently.”

Jassy는 아마존이 설립된 지 2년도 채 되지 않아 아마존에 입사했다.

그는 "아마존은 항상 건축가라면 좋아할 만한 곳이었다"고 말했다. "우리가 아마존에서 우리의 문화에 대해 정말로 생각할 때, 우리는 항상 내부적으로 그것에 대해 이야기한다. 우리는 건축업자들이 지을 수 있는 장소를 건설하려고 한다.

"고객으로부터 모든 것을 시작했다는 광적인 견해가 있었다."라고 Jassy는 말했다. "그리고 당신의 모든 전략과 전술은 거기서부터 거꾸로 작용했다. 그것은 회사 내에서 정말 눈에 잘 띄는 것이었다. 우리 모두 머리가 잘린 것처럼 뛰어다녔던 순간들이 많았던 것으로 기억한다. 우리 모두는 우리에게 너무 큰 직업을 가지고 있었고, 우리는 단지 이 땅 붐이 일어나고 있다는 것을 깨달았고, 사람들은 온라인 구매에 익숙해지기 시작했다.

"우리는 이 놀라운 기회를 가졌다,"라고 Jassy는 말했다. "그리고 우리가 그때 느꼈던 것 중 하나는, 그리고 나는 오늘에 대해 훨씬 더 강하게 느끼고 있는데, 아마도 1997년에 내가 했던 것보다 10배나 더 강하게 느껴지는데, 그 속도는 모든 규모와 모든 단계에서 기업에 불균형적으로 중요하다는 것이다."

그러나 Jassy는 "보안과 운영 성능이나 안전을 희생하면서 속도를 낼 수는 없다. 그것은 재앙이다. 하지만 현실은, 속도가 중요하지 않다고 생각하는 어떤 사업에 종사하고 있다면, 나는 당신이 스스로 농담하고 있다고 생각한다. 세상은 경쟁적인 곳이다. 많이 변했고, 아마존에서 많이 본 겁니다.

"우리가 빨리 움직이려고 노력하는 몇 가지가 있다. 첫째는 당신이 누구를 고용하느냐이다"라고 Jassy는 말했다. "그리고 우리는 건설업자에게 누구를 고용하느냐에 대해 불균형적으로 지수를 매긴다. 우리는 건설업자를 발명가라고 생각한다. 즉, 고객 경험을 보고 무엇이 옳지 않은지에 대해 솔직해지려고 노력하는 사람들, 그리고 그것들을 재창조하려고 하는 사람들, 무언가를 시작하는 것이 결승선이 아니라 출발선이라는 것을 깨닫는 사람들. 많은 회사에서는 출시를 좋아하지만 그 후 흥미를 잃게 되는 이 사람들을 볼 수 있다. 첫날에 우리 중 누구도 병에 번개를 잡지 못한다. 고객들의 말을 듣고 또 반복해서 듣는 것도 많고."

Jassy에 따르면 아마존 초기에는 제품 관리자들이 한 그룹에 있었고, 엔지니어들이 다른 그룹에 속해 있었으며, 운영자들은 그들 자신의 그룹에 속해 있었으며, 이로 인해 프로젝트가 지연되거나 불충분할 때 서로 "손가락질"을 많이 하게 되었다고 한다.

Jassy는 아마존이 모든 사업에서 더 빨리 움직일 수 있도록 하기 위해 AWS를 설립하고 "자신의 운명"을 부여받은 자율적인 단체에 그 직원들이 함께 있다고 말했다.

"기술자들이 뭔가를 만들어서 벽에 던져 ops에 넣는 그런 이상한 효과를 얻을 수 없을 겁니다. 그리고 ops guys는 '이 사람들은 효과가 없는 것을 만들었다'고 말할 것입니다,"라고 Jassy는 말했다. " 호출기를 들고 있다가 새벽 2시 30분에 페이지가 나오면 소프트웨어를 조금 다르게 만드는 방법이 있는 겁니다."

Jassy On Being Open To Big Ideas And Failure

As most companies get larger, they also tend to get more conservative and have senior leaders walking into meetings on new ideas looking for ways to say no, according to Jassy.

“Not because they’re ill-intended, but just it’s a lot to manage, and you get a little bit more conservative,” he said. “The opposite is true with Amazon. As senior leaders, we’ll all tell you that our favorite meetings— and the ones we look most forward to—are the ones on altogether new ideas. We don’t say ‘yes’ to everything, but if you watch the behavior of leaders in those meetings, we are trying to figure out ways to problem-solve to get to yes.

“If you’re going to invent a lot, and if you’re going to move fast a lot like we do, you have to be comfortable with failure,” Jassy said. “It’s a real dichotomy at Amazon because we hire these very achievement-oriented, Type A people who hate to fail. And yet if you’re inventing and pushing the envelope, you are going to fail sometimes.”

Jassy pointed to Amazon’s failed 2014 release of its Fire smartphone as “very culturally reaffirming.”

“Our phone was not a success, in case you didn’t know that,” he said. “But the way we view all of our initiatives inside of Amazon is we think about outputs, and we think about inputs. The ultimate output for a public company is your share price, and other outputs are things like free cash flow and operating. But you can’t manage the outputs. The only way you can drive the outputs is to be focused on the inputs. Ninety-nine percent of the goals that we care about are the inputs. And in the case of the phone, there were a lot of good inputs. We hired a great team who built really difficult technology and did a lot of invention, and delivered it on time. It turned out we had the value proposition wrong for the phone.

“But if you don’t have a way to reward the people who takes risks on new initiatives when they did a good job on the inputs and have a good landing spot for them, then you won’t get good people who will work on new initiatives,” Jassy said. “They’ll only work on things that are the sure bets.”

Jassy에 따르면, 대부분의 회사들이 규모가 커질수록, 그들은 또한 더 보수적이 되는 경향이 있고, 고위 지도자들이 거절할 방법을 찾기 위해 새로운 아이디어에 대한 회의에 참석하도록 한다.

그는 "그들이 의도를 잘못해서가 아니라 그저 관리해야 할 일이 많고, 조금 더 보수적이 된다"고 말했다. "아마존의 경우는 그 반대야. 수석 리더로서, 우리는 여러분에게 우리가 가장 좋아하는 모임, 그리고 우리가 가장 기대하고 있는 모임들이 완전히 새로운 아이디어에 대한 것이라고 말할 것이다. 우리는 모든 것에 '그렇다'고 말하지 않지만, 만약 여러분이 그 회의들에서 지도자들의 행동을 본다면, 우리는 문제를 해결하기 위해 예에 도달하기 위한 방법을 찾으려고 노력하고 있다.

재시는 "발명을 많이 할 것이고, 우리처럼 빨리 움직이려면 실패에 편해야 한다"고 말했다. "실패하는 것을 싫어하는 이런 매우 성취 지향적인 A형 사람들을 고용하기 때문에 아마존에서는 정말 이분법적인 겁니다. 그런데도 그 봉투를 발명하고 밀어붙이고 있다면 때로는 실패하게 될 겁니다."

재시는 2014년 아마존의 불스마트폰 출시 실패를 문화적으로 매우 재확인한 것이라고 지적했다.

그는 "우리 휴대전화는 성공하지 못했다"고 말했다. "하지만 아마존 내부의 모든 이니셔티브를 보는 시각은 산출물에 대해 생각하고, 입력에 대해 생각하는 겁니다. 공기업에 대한 궁극적인 산출물은 당신의 주가로, 다른 산출물은 무료 현금흐름이나 영업과 같은 것이다. 하지만 당신은 출력을 관리할 수 없다. 출력을 구동할 수 있는 유일한 방법은 입력에 집중하는 것이다. 우리가 관심을 갖는 목표의 99%가 투입이다. 그리고 전화의 경우, 좋은 입력들이 많이 있었다. 우리는 정말 어려운 기술을 만들고 많은 발명을 한 훌륭한 팀을 고용해서 제시간에 그것을 배달했다. 알고 보니 우리는 전화에 대한 가치 제안을 잘못했다.

"하지만 투입을 잘했고, 투입을 잘 했을 때 새로운 이니셔티브에 대한 위험을 감수하는 사람들에게 보상할 방법이 없다면, 새로운 이니셔티브를 위해 일할 좋은 사람들을 얻을 수 없을 것이다."라고 Jassy는 말했다. "그들은 확실한 내기를 하는 일에만 매달릴 거야."

Jassy On Why Amazon Doesn’t Allow PowerPoint Presentations

Amazon outlawed PowerPoint presentations for internal meetings in 2002 because they disproportionately reward charismatic presenters and penalize those who aren’t, Jassy said.

“Oftentimes, people really don’t understand the content, but they get swayed by the person presenting,” he said. “And then the PowerPoint presentations are very easy on the presenters and hard on the people listening, because the slides are really skin-deep. You can’t really understand any depth and the ideas, so you constantly have to be asking questions and interrupting. It just takes too long to get through it, and we found it took us many meetings, and it was a really disjointed way to get through information.”

Amazon instead uses “narratives” that can be a maximum of six pages long, excluding the appendix.

“The thing that’s great about narratives, and I think has really been a key part of our success and our ability to move quickly, is that if you write a narrative that is skin-deep, it is painfully obvious,” Jassy said. “A good narrative gets a room full of people who aren’t close to the topic up to speed really quickly on the background and the context, and the three or four issues that really need to be figured out. So … we get right at the heart of those issues, and we have intelligent conversations, because people have some background. We tend to get through issues in a lot more detail, a lot more crisply, knowing what we’re going to do and faster.”

Jassy는 아마존이 2002년 내부 회의에서 파워포인트 프레젠테이션을 금지했다고 말했다. 왜냐하면 그들은 카리스마 있는 발표자들에게 과도하게 보상을 하고 그렇지 않은 사람들에게 불이익을 주기 때문이다.

그는 "과거에는 사람들이 정말 내용을 이해하지 못하는데, 발표하는 사람에게 휘둘린다"고 말했다. "그리고 파워포인트 프레젠테이션은 발표자들에게는 매우 쉽고, 듣는 사람들에게도 힘든데, 그 슬라이드는 정말 피부 깊이가 있기 때문이다. 당신은 어떤 깊이와 생각을 정말로 이해할 수 없기 때문에 끊임없이 질문을 하고 방해해야 한다. 그냥 지나치기엔 너무 오래 걸리고, 많은 미팅이 필요하다는 것을 알게 되었고, 정보를 얻는 데는 정말 비협조적인 방법이었습니다."

아마존은 그 대신 부록을 제외한 최대 6페이지가 될 수 있는 "서술 Narrative"을 사용한다.

“서술에 있어서 가장 좋은 점은, 그리고 우리가 성공하고 빠르게 움직일 수 있는 능력의 핵심 요소라고 생각합니다. 피부 깊숙이 있는 서술을 쓰면 고통스러울 정도로 분명하다는 것입니다. “좋은 이야기라면 그 주제에 근접하지 않은 사람들로 가득 찬 방을 만들어서 배경과 맥락, 그리고 정말로 알아내야 할 세 가지나 네 가지 문제를 빠르게 처리할 수 있습니다. 그래서 우리는 그 문제의 핵심에 도달하고 지적인 대화를 나누었습니다. 왜냐하면 사람들은 배경이 있기 때문입니다. 우리는 더 자세하게, 더 선명하게, 더 빨리, 더 빨리, 더 자세히 문제를 해결하는 경향이 있습니다.”

원문: https://www.crn.com/news/cloud/aws-ceo-andy-jassy-drills-down-on-cloud-adoption-and-amazon-s-culture

The Amazon i3 Family

Amazon has recently released to general availability the i3.metal instance, which allows us to do some things which we could not do before in the Amazon cloud, such as running an unmodified hypervisor. We were able to run more than six thousand KVM virtual machines on one of these instances, far beyond our pessimistic guess of around two thousand. In the remainder of this post we will discuss what makes these platforms important and unique, how we ran KVM virtual machines on the platform using Amazon’s own Linux distribution, and how we measured its performance and capacity using kprobes and the extended Berkeley Packetcpu Filter eBPF .

Read on for details!

i3.metal and the Nitro System

The i3 family platforms include two improvements from what Amazon has historically offered to AWS customers. The first is the combination of the Annapurna ASIC and the Nitro PCI card, which together integrate security, storage, and network I/O within custom silicon. The second improvement is the Nitrohypervisor, which replaces Xen for all new EC2 instance types. Together, we refer to the Nitro card, Annapurna ASIC, and Nitro hypervisor as the Nitro System. (See the EC2 FAQs entry for the Nitro Hypervisor for some additional details.)

Although Amazon has not released much information about the Nitro system there are important technical insights in Brendan Gregg’s blog and in two videos ( here and here ) from the November 2017 AWS re:Invent conference. From these presentations, it is clear that the Nitro firmware includes a stripped-down version of the KVM hypervisor that forgoes the QEMU emulator and passes hardware directly to the running instance. In this sense, Nitro is more properly viewed as partitioning firmware that uses hardware self-virtualization features, including support for nested virtualization on the i3.metal instances.

Nitro protects the Annapurna ASIC and the multi-root PCI hardware from being reprogrammed for the i3.metal systems, but nothing else (this invisible presence is to protect against the use of unauthorized elastic block stores or network access.) For example, while Nitro has no hardware emulation (which is the role of QEMU in a conventional KVM hypervisor), Nitro does enable self-virtualizing hardware (pdf). Importantly, Nitro on the i3.metal system exposes hardware virtualization features to the running kernel, which can be a hypervisor. Thus, a hypervisor such as KVM, Xen, or VMWare can be run directly in an i3.metal instance partitioned by the Nitro firmware.

Image above: Amazon’s i3 platform includes the Annapurna ASIC, the Nitro PCI Card, and the Nitro Firmware. See https://youtu.be/LabltEXk0VQ

Key Virtualization Features Exploited by the Nitro Firmware

Below is a brief, incomplete summary of virtualization features exploited by the Nitro system—particularly in the bare metal instances.

VMCS Shadowing

Virtual Machine Control Structure (VMCS) Shadowing provides hardware-nested virtualization on Intel Processors. The VMCS is a set of registers that controls access to hardware features by a virtual machine (pdf). The first-level hypervisor—in this case the Nitro system—keeps a copy of the second to nth level VMCS and only investigates registers that are different from the cached version. Not every register in the VMCS requires the first level hypervisor to monitor. The Nitro firmware thus provides nested virtualization with no material effect on performance (consuming only a small amount of additional processor resources). If the instance hypervisor does not violate the boundaries established by Nitro, there is no intervention and no effect upon performance.

Most significantly, VMCS shadowing registers are freely available to the kernel running on the bare-metal instance, which is unique for EC2  instances.

Extended Page Tables

Once the hypervisor has established memory boundaries for the virtual machine, Extended Page Tables (EPT) are a hardware feature that allows a virtual machine to manage its own page tables. Enabling this hardware feature produced a two order magnitude of improvement in virtual machine performance on x86 hardware.

Like VMCS shadowing, EPT works especially well with nested hypervisors. The Nitro firmware establishes a page table for the bare-metal workload (Linux, KVM, or another hypervisor.) The bare-metal workload manages its own page tables.

As long as it does not violate the boundaries established by the Nitro firmware, Nitro does not effect the performance or functionality of the bare-metal workload. Nitro’s role on i3.metal workloads prevents the workload from gaining the ability to re-configure the Annapurna ASIC or the Nitro card and violating the limits set for the instance.

Posted Interrupts

The multi-root virtualization capability (pptx) in the i3 instances virtualizes the Amazon Enhanced Networking and Elastic Block Storage (EBS) using PCI hardware devices (Annapurna ASIC and the Nitro card) assigned by the Nitro firmware to specific bare-metal workloads.

Posted interrupts (pdf) allow system firmware to deliver hardware interrupts directly to a virtual machine, when that virtual machine is assigned a PCI function. The Nitro system uses posted interrupts to allow the bare-metal workload to process hardware interrupts generated by the Nitro hardware without any intervention from the Nitro System.

That is, the Annapurna ASIC and Nitro PCI card can interrupt the bare-metal workload directly, while remaining protected from re-configuration by the bare metal workload. There are no detrimental effects on performance as long as the Nitro System does not over-provision CPUs, which it does not do. (The bare-metal workload may, even if it is a hypervisor, as we will see below in the limited testing we did)

Loading KVM on a Bare Metal Instance

On an EC2 Bare Metal system (i3.metal in the screen grab above), Nitro is hardware partitioning firmware. The Nitro firmware is based on KVM and does not use hardware emulation software (such as QEMU). It does initialize the custom Amazon hardware and pass-through hardware to the running instance: networking, storage, processors, PCI trees, and memory. It then jumps into the bare-metal instance kernel, which in our testing was Amazon Linux. (Amazon also supports the VMware Hypervisor as a bare-metal instance)

The Nitro firmware only activates if the bare-metal kernel violates established partitioning. The fact that the Nitro firmware is actually Linux and KVM is not new: Linux has been used as BIOS for many years for complex systems that consolidate networked or shared resources for hardware platforms.

Passing-through the VMX flag and Running Nested Virtualization

The Bare Metal kernel sees the vmx flag when it inspects /proc/cpuinfo:

This flag is necessary in order to load KVM. It indicates that the Virtual Machine Control Structure (VMCS) is programmable by the Linux-KVM kernel. VMCS Shadowing makes this possible; it uses copy-on-write methods and register caching in the processor itself to run each layer in the stack (Nitro, KVM, and the Virtual Machine) directly on the processor hardware. Each layer is controlled by the layer beneath it.

The i3.metal systems use register caching and snooping to provide hardware-virtualized processors to each layer in the system, beginning with the Nitro System, up to virtual machines being run by the bare-metal instance (KVM in this case).

The Nitro firmware does not use QEMU because it does not emulate any hardware. In our testing, we did use QEMU hardware emulation in the upper layer virtual machines. This resulted in the picture below, where the Nitro firmware is running beneath the i3 instance kernel. We then loaded KVM, and used QEMU to provide hardware emulation to the virtual machines:

When running a hypervisor such as KVM on the i3.metal systems, each layer has direct access to the processor through VMCS Shadowing, which provides each layer with the Virtual Machine Control registers.

Installing KVM on an Amazon Linux Image

The Amazon Linux distribution is derived from Fedora Linux with KVM available as two loadable modules. (KVM is maintained and supported by Amazon as a standard feature of the bare metal instance.)

Some components need to be installed, for example QEMU:

Libvirt is not part of the Amazon Linux distribution, which saves cost . We do not need Libvirt, and it would get in the way of later testing.

Libvirt is an adequate collection of software, but qemu-kvm is not aware of it, meaning the virtual machine state information stored by Libvirt may be out of sync with qemu-kvm . Libvirt also provides an additional attack vector to KVM while providing little additional functionality over what is provided by standard Linux utilities and kernel features, with  qemu-kvm.

Built-in Processor Support for KVM

The i3.metal instance has 72 threads running on 36 physical cores that support KVM and posted interrupts. This information may be read in /proc/cpuinfo: 

Loading KVM on the Nitro system is most easily done by   modprobe’ing the KVM modules:

The irqbypass  module provides posted interrupts to KVM virtual machines, reminding us again that we may pass PCI devices present on the bare-metal host through to KVM virtual machines.

Built-in virtio virtual I/O at the Linux Kernel Level

virtio  is a Linux kernel i/o virtualization feature: it is maintained and supported by Amazon and that it works with qemu-kvm  to provide isolated (not shared as in Xen’s dom0  netback and blockback) virtual i/o devices for virtual machines that do not need direct access to a hardware PCI device. Each virtio  device is a unique and private virtual PCI device with separation provided by the Linux kernel.

The Amazon Linux kernel supports virtio devices, as shown by this excerpt of the Amazon Linux configuration file:

Kernel Shared Memory (KSM)

KSM is a Linux kernel feature that scans memory pages, merges duplicates, marks those pages as read-only, and copies the pages when they are written (COW).  KSM provides a kernel-level mechanism for over-provisioning memory. KSM is automatic, built in, and does not require an external module as Xen does, for example, with its Dom0 balloon driver.

KSM is documented in the Linux kernel documentation directory.

The Amazon Linux kernel is configured with KSM:

Running a KVM virtual machine with copy-on-write memory is straightforward, by starting the virtual machine with the mem-merge feature turned on: 

Using the -machine mem-merge=on  command upon virtual machine startup causes QEMU to execute anmadvise system call with the MADV_MERGEABLE parameter for the virtual machine memory, marking the VM memory as merge-able.

To disable merging for a virtual machine upon startup, use the same command but substitute  mem-merge=off . 

Running the KVM Virtual Machine

We created a virtual machine using a minimal Linux distribution: TTY Linux. It has an image built specifically to run with KVM using virtio  network and block devices.

We ran KVM Linux virtual machines using this command line:

Only three steps are required to create the virtual machine:

1. Download the TTY Linux distribution and unzip to an iso image:

2. Create the qcow disk image for the virtual machine:

3. Run the virtual machine:

We were struck by how easy it was to run KVM virtual machines on these Nitro systems, configured as they are with Amazon Linux. Each virtual machine in our testing had 1G of memory and 1G of writeable storage.

numactl and other Linux Process Control

A benefit of  KVM on i3.metal is the ability to use standard Linux system calls to control virtual machine resources. A good example is using the Linux numactl  command to allocate CPU cores for a kvm virtual machine: 

The above command uses numactl utility to bind the KVM virtual machine to Core #1.  It demonstrates how integrated KVM is with the Linux kernel and how simple it is to allocate memory and cores to specific virtual machines.

Integration with the Linux Kernel: cgroups, nice, numactl, taskset

We can turn the Linux kernel into a hypervisor by loading the KVM modules and starting a virtual machine, but the Linux personality is still there. We can control the virtual machine using standard Linux resource and process control tools such as cgroups, nice, numactl, and taskset :

All cgroup  commands work naturally with KVM virtual machines. As far as cgroups is concerned, each KVM virtual machine is a normal Linux process (although KVM runs that process at the highest privilege level in VMX guest mode (pptx), which provides hardware virtualization support directly to the virtual machine). There are two utilities to bind a KVM virtual machine to a specific processor, NUMA node, or memory zone:taskset  and numactl .

In summary, the Linux command set along with qemu-kvm  allows us native control over processors, memory zones, and other platform properties for to running KVM virtual machines. Libvirt, on the other hand, is a layer over these native control interfaces that tends to obscure what is really going on at the hardware level.

Testing the Limits of  Bare-Metal AWS Hypervisor Performance

To more securely run virtual-machine workloads on cloud services, we accessed a bare-metal instance for project research during the preview period. We wanted to first verify that KVM can be used as a hypervisor on EC2 bare-metal instances, and second, get a read on stability and performance. We had limited time for this portion of the research.

To measure system response, we decided to use the BPF Compiler Collection (BCC) (building and using this toolset may be the subject of another blog post).

BCC uses the extended Berkeley Packet Filter, an amazing piece of technology in recent Linux Kernels that runs user-space byte code within kernel space. BCC compiles byte code that uses dynamic kernel probes to instrument kernel behavior.

To test CPU load, we added a simple shell script to each VM’s init process:

This ensured that each virtual machine would be consuming all the CPU cycles allowed to it by KVM.

Next, we used a simple shell script to start KVM virtual machines into oblivion:

Then we ran the BCC program runqlat.py, which measures how much time processes are spending on the scheduler’s run queue – a measure of system load and stability. The histogram below shows the system when running 6417 virtual machines.

The histogram above demonstrates how long, within a range, each sampled process waited on the KVM scheduler’s run queue before it was actually placed on the processor and run. The wait time in usecs shows how long a process that is runnable (not sleeping or waiting for any resources or events to occur) waited in order to run. There are three things to look for in this histogram:

1. How closely grouped are the sampled wait times? Most processes should be waiting approximately the same time. This histogram shows this is the case, with close to half samples waiting between 4 and 15 microseconds.
2. How low are the wait times? On a system that is under-utilized, the wait times should be mostly immaterial (just a few microseconds or less on this hardware). This system is over-utilized, and yet the wait times for most of the samples are fewer than 15 microseconds.
3. How scattered are the samples in terms of wait times? In this histogram there are two groups: the larger group with wait times less than 511 microseconds, and the smaller group with wait times between 1024 and 32767 microseconds. The second group consists of only roughly 7% of samples. We would expect a distressed system to show several different groups clustered around longer wait times, with outliers comprising more than 7% of all samples.

Firecracker는 Serverless 컴퓨팅을 위한 안전하고 빠른 microVM을 위한 AWS에서 만든 KVM기반의 새로운 hypervisor 이다.

Lambda와 Fargate등 컨테이너를 써야 하지만 공유 보안이 문제가 되는 곳에  컨테이너 수준의 빠른 실행을 보장하는 hypervisor이다.

이는 AWS 뿐만 아니라 OnPremise이든 IBM의 Baremetal이든 다 올릴 수 있다. 물론 PC에서도 가능하다.  (vagrant에 쓰면 좋겠는데?)

원문 : https://aws.amazon.com/ko/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/

가상화 기술의 새로운 과제

오늘날 고객은 서버리스 컴퓨팅을 사용하여 인프라의 구축 또는 관리에 대한 걱정없이 애플리케이션을 구축 할 수 있습니다. 개발자는 코드를 AWS Fargate를 사용하여 서버리스 컨테이너를 사용하거나 AWS Lambda를 사용하여 서버리스 함수들을 사용 할 수 있습니다. 고객들은 서버리스의 낮은 운영 오버 헤드를 너무 좋아합니다. 우리 또한 서버리스가 향후 컴퓨팅에서 중추적 인 역할을 계속할 것으로 믿습니다.

고객이 서버리스를 점점 더 많이 채택함에 따라 기존의 가상화 기술은 이벤트 중심 또는 짧은 수명의 특성이 있는 이러한 유형의 워크로드의 특성에 최적화되지 않았음을 알게 되었습니다. 우리는 서버리스 컴퓨팅을 위해 특별히 설계된 가상화 기술을 구축 할 필요성을 확인했습니다. 가상 시스템의 하드웨어 가상화 기반 보안 경계를 제공하면서도 컨테이너 크기와 기능의 민첩성을 유지하면서 크기를 유지할 수있는 방법이 필요했습니다.

Firecracker Technology

Meet Firecracker, an open source virtual machine monitor (VMM) that uses the Linux Kernel-based Virtual Machine (KVM). Firecracker allows you to create micro Virtual Machines or microVMs. Firecracker is minimalist by design – it includes only what you need to run secure and lightweight VMs. At every step of the design process, we optimized Firecracker for security, speed, and efficiency. For example, we can only boot relatively recent Linux kernels, and only when they are compiled with a specific set of configuration options (there are 1000+ kernel compile config options). Also, there is no support for graphics or accelerators of any kind, no support for hardware passthrough, and no support for (most) legacy devices.

Firecracker boots a minimal kernel config without relying on an emulated bios and without a complete device model. The only devices are virtio net and virtio block, as well as a one-button keyboard (the reset pin helps when there’s no power management device). This minimal device model not only enables faster startup times (< 125 ms on an i3.metal with the default microVM size), but also reduces the attack surface, for increased security. Read more details about Firecracker’s promise to enable minimal-overhead execution of container and serverless workloads.

In the fall of 2017, we decided to write Firecracker in Rust, a modern programming language that guarantees thread and memory safety and prevents buffer overflows and many other types of memory safety errors that can lead to security vulnerabilities. Read more details about the features and architecture of the Firecracker VMM at Firecracker Design.

Firecracker microVMs improve efficiency and utilization with a low memory overhead of < 5 MiB per microVMs. This means that you can pack thousands of microVMs onto a single machine. You can use an in-process rate limiter to control, with fine granularity, how network and storage resources are shared, even across thousands of microVMs. All hardware compute resources can be safely oversubscribed, to maximize the number of workloads that can run on a host.

We developed Firecracker with the following guiding tenets (unless you know better ones) for the open source project:

• Built-In Security: We provide compute security barriers that enable multitenant workloads, and cannot be mistakenly disabled by customers. Customer workloads are simultaneously considered sacred (shall not be touched) and malicious (shall be defended against).
• Light-Weight Virtualization: We focus on transient or stateless workloads over long-running or persistent workloads. Firecracker’s hardware resources overhead is known and guaranteed.
• Minimalist in Features: If it’s not clearly required for our mission, we won’t build it. We maintain a single implementation per capability.
• Compute Oversubscription: All of the hardware compute resources exposed by Firecracker to guests can be securely oversubscribed.

We open sourced this foundational technology because we believe that our mission to build the next generation of virtualization for serverless computing has just begun.

Firecracker Usage

AWS Lambda uses Firecracker as the foundation for provisioning and running sandboxes upon which we execute customer code. Because Firecracker provides a secure microVM which can be rapidly provisioned with a minimal footprint, it enables performance without sacrificing security. This lets us drive high utilization on physical hardware, as we can now optimize how we distribute and run workloads for Lambda, mixing workloads based on factors like active/idle periods, and memory utilization.

Previously, Fargate Tasks consisted of one or more Docker containers running inside a dedicated EC2 VM to ensure isolation across Tasks. These Tasks now execute on Firecracker microVMs, which allows us to provision the Fargate runtime layer faster and more efficiently on EC2 bare metal instances, and improve density without compromising kernel-level isolation of Tasks. Over time, this will allow us to continue to innovate at the runtime layer, giving our customers even better performance while maintaining our high security bar, and lowering the overall cost of running serverless container architectures.

Firecracker runs on Intel processors today, with support for AMD and ARM coming in 2019.

You can run Firecracker on AWS .metal instances, as well as on any other bare-metal server, including on-premises environments and developer laptops.

Firecracker will also enable popular container runtimes such as containerd to manage containers as microVMs. This allows Docker and container orchestration frameworks such as Kubernetes to use Firecracker. We have built a prototype that enables containerd to manage containers as Firecracker microVMs and would like to with with community to take it further.

Getting Started with Firecracker

Getting Started with Firecracker provides detailed instructions on how to download the Firecracker binary, start Firecracker with different options, build from the source, and run integration tests. You can run Firecracker in production using the Firecracker Jailer.

Let’s take a look at how to get started with using Firecracker on AWS Cloud (these steps can be used on any bare metal machine):

Create an i3.metal instance using Ubuntu 18.04.1.

Firecracker is built on top of KVM and needs read/write access to /dev/kvm. Log in to the host in one terminal and set up that access:

sudo setfacl -m u:${USER}:rw /dev/kvm

Download and start the Firecracker binary:

curl -L https://github.com/firecracker-microvm/firecracker/releases/download/v0.11.0/firecracker-v0.11.0
./firecracker-v0.11.0 --api-sock /tmp/firecracker.sock

Each microVM can be accessed using a REST API. In another terminal, query the microVM:

curl --unix-socket /tmp/firecracker.sock "http://localhost/machine-config"

This returns a response:

{ "vcpu_count": 1, "mem_size_mib": 128,  "ht_enabled": false,  "cpu_template": "Uninitialized" }

This starts a VMM process and waits for the microVM configuration. By default, one vCPU and 128 MiB memory are assigned to each microVM. Now this microVM needs to be configured with an uncompressed Linux kernel binary and an ext4 file system image to be used as root filesystem.

Download a sample kernel and rootfs:

curl -fsSL -o hello-vmlinux.bin https://s3.amazonaws.com/spec.ccfc.min/img/hello/kernel/hello-vmlinux.bin
curl -fsSL -o hello-rootfs.ext4 https://s3.amazonaws.com/spec.ccfc.min/img/hello/fsfiles/hello-rootfs.ext4

Set up the guest kernel:

curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT 'http://localhost/boot-source'   \
    -H 'Accept: application/json'           \
    -H 'Content-Type: application/json'     \
    -d '{        "kernel_image_path": "./hello-vmlinux.bin", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"    }'

Set up the root filesystem:

curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT 'http://localhost/drives/rootfs' \
    -H 'Accept: application/json'           \
    -H 'Content-Type: application/json'     \
    -d '{        "drive_id": "rootfs",        "path_on_host": "./hello-rootfs.ext4",        "is_root_device": true,        "is_read_only": false    }'

Once the kernel and root filesystem are configured, the guest machine can be started:

curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT 'http://localhost/actions'       \
    -H  'Accept: application/json'          \
    -H  'Content-Type: application/json'    \
    -d '{        "action_type": "InstanceStart"     }'

The first terminal now shows a serial TTY prompting you to log in to the guest machine:

Welcome to Alpine Linux 3.8
Kernel 4.14.55-84.37.amzn2.x86_64 on an x86_64 (ttyS0)
localhost login:

Log in as root with password root to see the terminal of the guest machine:

localhost login: root
Password:
Welcome to Alpine! 

The Alpine Wiki contains a large amount of how-to guides and general information about administrating Alpine systems. 

See <http://wiki.alpinelinux.org>. 

You can setup the system with the command: setup-alpine 

You may change this message by editing /etc/motd.

login[979]: root login on 'ttyS0' 
localhost:~#

You can see the filesystem usingls /

localhost:~# ls /
bin         home        media       root        srv         usr
dev         lib         mnt         run         sys         var
etc         lost+found  proc        sbin        tmp

Terminate the microVM using the reboot command. Firecracker currently does not implement guest power management, as a tradeoff for efficiency. Instead, the reboot command issues a keyboard reset action which is then used as a shutdown switch.

Once the basic microVM is created, you can add network interfaces, add more drives, and continue to configure the microVM.

Want to create thousands of microVMs on your bare metal instance?

for ((i=0; i<1000; i++)); do
    ./firecracker-v0.10.1 --api-sock /tmp/firecracker-$i.sock &
done

Multiple microVMs may be configured with a single shared root file system, and each microVM can then be assigned its own read/write share.

Firecracker and Open Source

It is our mission to innovate on behalf of and for our customers, and we will continue to invest deeply in serverless computing at all three critical layers of the stack: the application, virtualization, and hardware layers. We want to offer our customers their choice of compute, whether instances or serverless, with no compromises on security, scalability, or performance. Firecracker is a fundamental building block for providing that experience.

Investing deeply in foundational technologies is one of the key ways that we at AWS approach innovation – not for tomorrow, but for the next decade and beyond. Sharing this technology with the community goes hand-in-hand with this innovation. Firecracker is licensed under Apache 2.0. Please visit the Firecracker GitHub repo to learn more and contribute to Firecracker.

By open sourcing Firecracker, we not only invite you to a deeper examination of the foundational technologies that we are building to underpin the future of serverless computing, but we also hope that you will join us in strengthening and improving Firecracker. See the Firecracker issues list and the Firecracker roadmap for more information.

AWS 비용 계산기가 새로 나왔습니다.

UI도 깔끔해졌고, 여러 리전을 그룹으로 지정해서 같이 계산도 가능합니다.

Edit Group으로 원하는 리전을 먼저 그룹으로 만들고 시작하세요.

https://calculator.aws/

cpio를 이런데 쓸줄이야. (사실 검색해보기 전까지는 backup용으로 쓰이던걸 몰랐다. Android fs 빼낼때나 썻지...)

fpart + cpio + GNU Parallel 은 참신하다. Amazon EFS 외에도 잘 써먹을 수 있겠다.

참고 : https://github.com/aws-samples/amazon-efs-tutorial

원문 : https://s3.amazonaws.com/aws-us-east-1/demo/efs-parallel-file-transfer-test.html

Amazon EFS Parallel File Transfer Test

AWS Storage Days | New York | September 6-8, 2017

Version 1.0

© 2017 Amazon Web Services, Inc. and its affiliates. All rights reserved. This work may not be reproduced or redistributed, in whole or in part, without prior written permission from Amazon Web Services, Inc. Commercial copying, lending, or selling is prohibited.

Errors or corrections? Email us at darrylo@amazon.com.

Step-by-step Guide

Launch this environment to evaluate how the different instances types, I/O size, and thread count effects throughput to an Amazon EFS file system.

AWS CloudFormation template will launch:

• Three Auto Scaling groups
• Recommend using default instance types for each Auto Scaling group
  • t2.micro for Auto Scaling group 0
  • m4.large for Auto Scaling group 1
  • c4.xlarge for Auto Scaling group 2
• Minimum and desired size for each Auto Scaling group is 1 (maximum 4)
• Each Auto Scaling group instance will auto mount the identified Amazon EFS file system, generate 5GB of 1MB files & 5GB of 10MB files using smallfile, and install the following applications:
  • nload - is a console application which monitors network traffic and bandwidth usage in real time
  • smallfile - https://github.com/bengland2/smallfile - used to generate test data; Developer: Ben England
  • GNU Parallel - https://www.gnu.org/software/parallel/ - used to parallelize single-threaded commands; O. Tange (2011): GNU Parallel - The Command-Line Power Tool, ;login: The USENIX Magazine, February 2011:42-47
  • Mutil mcp - https://github.com/pkolano/mutil - multi-threaded drop-in replacement of cp; Author Paul Kolano (NASA)
  • fpart - https://github.com/martymac/fpart - sorts file trees and packs them into partitions; Author Ganaël Laplanche
  • fpsync - wraps fpart + rsync - included in the tools/ directory of fpart

NOTICE!! Amazon Web Services does NOT endorse specific 3rd party applications. These software packages are used for demonstration purposes only. Follow all expressed or implied license agreements associated with these 3rd party software products.

WARNING!! If you build the above mentioned environment, this will exceed your free-usage tier. You will incur charges as a result of creating this environment and running these scripts in your AWS account. If you run this environment for 1 hour, you may incur a charge of ~$1.18.

You can launch this CloudFormation stack, using your account, in the following AWS Regions:

AWS Region Code	Name	Launch
us-east-1	US East (N. Virginia)
us-east-2	US East (Ohio)
us-west-2	US West (Oregon)
eu-west-1	EU (Ireland)
eu-central-1	EU (Frankfurt)
ap-southeast-2	AP (Sydney)

SSH to all three EC2 instances

Not all EC2 instances are created equal

Run this command against t2.micro

1. Write 17GB to EFS w/ 1MB block size

time dd if=/dev/zero of=/efs/dd/17G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=17408 conv=fsync &
nload -u M
While this is running, continue and run Step 2 in a separate terminal session.

Run this command against m4.large

2. Write 5GB to EFS w/ 1MB block size

time dd if=/dev/zero of=/efs/dd/5G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=5120 conv=fsync &
nload -u M

Maximize throughput using larger I/O size

Run the remaining commands against c4.xlarge

3. Write 2GB to EBS w/ 1MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress conv=fsync
Record run time.

4. Write 2GB to EFS w/ 1MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress conv=fsync
Record run time.

5. Write 2GB to EBS w/ 8MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress conv=fsync
Record run time.

6. Write 2GB to EFS w/ 8MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress conv=fsync
Record run time.

Sample run times

7. Write 2GB to EBS w/ 1MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress oflag=sync
Record run time.

8. Write 2GB to EFS w/ 1MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress oflag=sync
Record run time.

9. Write 2GB to EBS w/ 8MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress oflag=sync
Record run time.

10. Write 2GB to EFS w/ 8MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress oflag=sync
Record run time.

Sample run times

Maximize throughput using parallel, multi-threaded access

Run the remaining commands against c4.xlarge

11. Write 2GB to EBS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 3 | parallel --will-cite -j 4 'dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=512 oflag=sync'
Record run time.

12. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 3 | parallel --will-cite -j 4 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=512 oflag=sync'
Record run time.

13. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ once at the end

time seq 0 3 | parallel --will-cite -j 4 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=512 conv=fsync'
Record run time.

14. Write 2GB to EBS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 7 | parallel --will-cite -j 8 'dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=256 oflag=sync'
Record run time.

15. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 7 | parallel --will-cite -j 8 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=256 oflag=sync'
Record run time.

16. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ once at the end

time seq 0 7 | parallel --will-cite -j 8 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=256 conv=fsync'
Record run time.

Sample run times

Maximize throughput - EFS parallel file transfer test

Run the remaining commands against c4.xlarge

Identify size of data set to be transferred.

du -csh /ebs/data-1m/
find /ebs/data-1m/. -type f | wc -l

Set variable

instanceid=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

17. Transfer files from EBS to EFS using rsync

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time rsync -r /ebs/data-1m/ /efs/rsync/${instanceid} &
nload -u M
Record throughput.

18. Transfer files from EBS to EFS using cp

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time cp -r /ebs/data-1m/* /efs/cp/${instanceid} &
nload -u M
Record throughput.

Set variable

Set the threads variable to 4 threads per vcpu.
threads=$(($(nproc --all) * 4))

19. Transfer files from EBS to EFS using fpsync

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time /usr/local/bin/fpsync -n ${threads} -v /ebs/data-1m/ /efs/fpsync/${instanceid} &
nload -u M
Record throughput.

20. Transfer files from EBS to EFS using mcp

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time mcp -r --threads=${threads} /ebs/data-1m/* /efs/mcp/${instanceid} &
nload -u M
Record throughput.

21. Transfer files from EBS to EFS using efscp script (cp + GNU Parallel)

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time /home/ec2-user/efscp.sh /ebs/data-1m/ /efs/efscp ${threads} &
nload -u M
Record throughput.

22. Transfer files from EBS to EFS using fpart + cpio + GNU Parallel

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time /usr/local/bin/fpart -Z -n 1 -o /home/ec2-user/fpart-files-to-transfer /ebs/data-1m
time parallel --will-cite -j ${threads} --pipepart --round-robin --block 1M -a /home/ec2-user/fpart-files-to-transfer.0 'sudo cpio -pdm {} /efs/parallelcpio/${instanceid}/' &
nload -u M
Record throughput.

Sample run times

Re-run steps 17-22, changing the source path from /ebs/data-1m to /ebs/data-10m to compare the throughput differences between small and large I/O size.

Cleanup

Delete all files on the EFS file system that were created using these scripts and delete the CloudFormation stack, so you don’t continue to incur additional charges for these resources.

Conclusion

The distributed nature of Amazon EFS enables high levels of availability, durability, and scalability. This distributed architecture results in a small latency overhead for each file operation. Due to this per-operation latency, overall throughput generally increases as the average I/O size increases, because the overhead is amortized over a larger amount of data. Amazon EFS supports highly parallelized workloads (for example, using concurrent operations from multiple threads and multiple Amazon EC2 instances), which enables high levels of aggregate throughput and operations per second.

For feedback, suggestions, or corrections, please email me at darrylo@amazon.com.

메인프레임까지... ㅎㄷㄷ

 APN Blog 메인프레임 섹션 에 참조할 만한 많을 글이 있다.

https://aws.amazon.com/ko/blogs/korea/yes-you-should-modernize-your-mainframe-with-the-cloud/

클라우드 이전 시 많은 대기업 고객이 떨쳐버리지 못하는 걱정은 마이그레이션하고 나면 저 메인프레임(Mainframe)은 어떻게 해야 하는지에 대한 것입니다. 사실 클라우드 기반으로 설계된 워크로드는 수평적 확장성에 집중합니다. 즉, 컴퓨팅 처리 용량이 필요해지면 수요를 충족하기 위해 인스턴스를 추가하면 됩니다. 이에 반해 많은 레거시 시스템은 필요에 따라 더 크고 더 강력한 시스템을 추가하는 수직적 확장을 염두에 두고 설계되었으며, 결국 대기업에서 가장 중요한 워크로드는 메인프레임을 선정하고, 대체로 뛰어난 성능과 안정성을 제공했기 때문에 성공적입니다.

이 글은 메인프레임 워크로드를 클라우드로 마이그레이션하는 데 관심이 있는 기업들이 선택할 수 있는 여러 방안을 설명합니다.

왜 메인프레임이 아니고 클라우드인가?

대기업 고객에게는 기존 메인프레임을 AWS 클라우드로 마이그레이션하는 사업상 이유가 있습니다. 하지만, 메인프레임 현대화 프로젝트는 대체로 인내심과 강력한 리더십, 그리고 의도한 ROI를 달성할 탄탄한 접근 방법이 필요합니다. 기존에 AWS 클라우드로 이전하는 고객 프로젝트에서 성공을 거둔 경험을 바탕으로 우리는 새 메인프레임을 AWS로 이전하는 이니셔티브를 촉진하는 패턴, 교훈, 모범 사례를 파악했습니다.

우리는 고객이 AWS로 메인프레임 워크로드를 현대화하려는 여러 이유가 있음을 알게 되었습니다. 첫째, 비용 절감은 분명 메인프레임에서 AWS로 워크로드를 이전하는 데 따라오는 강력한 이점입니다. 자본 지출과 MIPS(millions of instructions per second)를 제거하고, 독립 소프트웨어 공급업체(ISV) 라이선스 비용을 줄이며, 탄력적 요금 모델을 활용할 수 있기 때문입니다. 둘째, 연속 통합 및 지속적인 업데이트(CI/CD)와 온디맨드로 사용하는 거의 무한한 인프라 리소스를 통해 개발 주기가 단축되어 민첩성을 얻게 됩니다. 셋째, 수십 년간의 비즈니스 거래가 포함되어 경쟁 차별화 요소를 모색하는 데이터 분석 또는 머신 러닝 이니셔티브를 제공할 수 있는 메인프레임 데이터 활용에 따른 장점이 있습니다. 마지막 네 번째로 AWS 클라우드로 이전을 통해 메인프레임 퇴역에 따른 기술 격차를 해결하고 새로운 인재를 유치하여 핵심 비즈니스 워크로드를 현대화할 수 있습니다.

AWS 클라우드를 통한 메인프레임 현대화에는 한 가지 해결책이 없습니다. 대기업 고객은 비즈니스 및 IT 전략에 따라 메인프레임 특유의 기술적 제약에 따라 가장 적합한 패턴을 선택해야 합니다. 메인프레임이 여러 워크로드를 처리할 만큼 크다면 각 워크로드의 특성마다 유리한 패턴이 다를 수 있습니다. 워크로드 자체가 특정 프로그램이나 데이터와 독립적일 경우에는 쉽게 파악할 수 있습니다. 하나의 메인프레임 내에서 안정화된 애플리케이션이 따르는 패턴이 있기도 하고, 계속해서 변화 중인 애플리케이션은 다른 패턴에 따를 수 있습니다. 이처럼 워크로드마다 적합한 여러 전략을 선택할 수 있다는 점이 위에서 설명한 네 가지 동인, 그중에서도 비즈니스 민첩성과 기술 격차를 활용하는 것이 고객이 성공을 거두는 비결입니다.

이를 바탕으로 AWS 고객 중 메인 프레임을 이전한 성공적인 패턴 몇 가지를 소개합니다.

패턴 1: 자동 리팩터링을 통한 단기 마이그레이션

자동 리팩터링은 레거시 스택(예: COBOL 기반)을 새로운 스택(예: Java 기반 또는 .Net 기반)으로 변환하기 위해 리버스 엔지니어링과 포워드 엔지니어링을 모두 자동화합니다. 효율성과 품질을 위해 이 변환에는 최대한 많은 자동화가 있지만 수동 코드 재작성은 없습니다. 일반적으로 이로 인해 애플리케이션은 클라우드 네이티브 애플리케이션과 비슷한 열 두가지 앱 모범 사례에 따라 다양한 AWS 서비스를 통해 탄력성, 수평적 확장성, 보다 간편한 통합을 제공합니다.

그림 1: 자동 리팩터링을 통한 단기 마이그레이션

이 패턴을 기본적인 줄 단위 코드 변환(예를 들어, 절차형 COBOL을 절차형과 유사한 Java(혹은 JOBOL)로 변환하는 것으로 유지 관리와 통합이 어려운 변환 작업)을 수행하는 언어 변환 도구와 혼동하면 안 됩니다. 자동 리팩터링 도구는 코드, 데이터 액세스, 데이터 스토어, 프레임워크, 트랜잭션 하위 시스템, 의존성 호출을 포함한 전체 레거시 스택을 분석하고 변환하는 종합적 접근 방법을 취합니다. 여기서 자동으로 생성되는 일관되고 기능적으로 동등한 대상 스택은 서비스 지향적이고 서비스 가능할 뿐 아니라 AWS 서비스를 위한 패키징된 최적화를 갖추고 있습니다. 또 마이크로서비스 생성을 위한 서비스 분해도 촉진합니다.

자동 리팩터링 도구의 가치와 차별화 요소는 주로 자동화된 포워드 엔지니어링 기능에 달려 있습니다. 리버스 엔지니어링 기능을 갖춘 도구는 많지만 강력하고 광범위한 포워드 엔지니어링 자동화를 갖춘 도구는 거의 없습니다.

일례로 미 국방부의 한 고객은 전체 메인프레임 COBOL 및 C-logistics 시스템(수백만 줄의 코드)을 AWS에서 Java로 자동으로 리팩터링하여 레거시 코드의 기술적 부채를 제거했습니다. APN 블로그는 ‘Blu Age와 AWS를 사용하여 메인프레임 배치를 클라우드 마이크로서비스로 마이그레이션하는 방법‘과 ‘클라우드 네이티브 Heirloom PaaS가 포함된 AWS의 고성능 메인프레임 워크로드‘에서 몇 가지 자동 리팩터링 도구를 보여 줍니다.

패턴 2: 에뮬레이터 리호스팅을 통한 단기 마이그레이션

이 패턴은 AWS 클라우드에서 실행되는 에뮬레이터에 대한 리플랫폼(re-platform)입니다. 이 접근 방법을 사용하면 레거시 애플리케이션 코드가 코드 변경이 최소화된 상태로 에뮬레이터로 이전되므로 동일한 애플리케이션 유지 관리 및 개발 기술이 유지되고 필요합니다. 이 마이그레이션은 최종 사용자의 관점에서 매끄러우며, 애플리케이션의 인터페이스와 룩 앤 필을 동일하게 유지합니다.

그림 2: 에뮬레이터 리호스팅을 통한 단기 마이그레이션

일반적으로 지원되는 소스 코드는 다시 컴파일되며 지원되지 않는 언어 코드는 먼저 지원되는 언어로 변환된 다음 다시 컴파일됩니다. 다른 타사 유틸리티 인터페이스와 통합하거나 그 과정에서 데이터 스토어 및 데이터 액세스를 현대화할 때는 코드 변경 또는 리팩터링이 필요합니다. 이 패턴의 경우, 도구에는 에뮬레이터와 컴파일러뿐 아니라 프로그램 및 데이터 마이그레이션 자동화에 필요한 유틸리티도 포함됩니다.

이 패턴을 더 큰 현대화 여정 내의 중간 단계 또는 안정화된 애플리케이션의 목표 상태로 보기도 합니다. 일례로 한 다국적 음료 회사는 AWS에서 에뮬레이터를 사용하여 배치 모드 및 온라인 트랜잭션 처리 기능을 다시 만들어 마이그레이션하면서 동일한 메인프레임 그린 스크린 경험을 제공했습니다. APN 블로그는 ‘NTT DATA 서비스를 사용하여 메인프레임 애플리케이션을 AWS로 리호스팅‘ 및 ‘5단계로 메인프레임을 AWS로 마이그레이션하기‘에서 몇 가지 에뮬레이터 도구를 보여 줍니다.

패턴 3: 데이터 분석을 통한 증설

이 패턴은 워크로드 마이그레이션이 아니라 AWS에서 민첩한 데이터 분석 서비스를 사용하는 메인프레임 증설에 대한 것입니다. 엄청나게 많은 사용자의 수십 년에 걸친 과거 비즈니스 트랜잭션이 포함될 수 있는 메인프레임 데이터는 강력한 비즈니스 장점입니다. 이에 따라 고객들은 빅 데이터 분석을 사용하여 메인프레임 데이터의 비즈니스 가치를 높입니다. 메인프레임이라는 대안에 비해 AWS의 빅 데이터 서비스를 사용하면 보다 빠른 분석 기능을 얻을 수 있으며, 데이터 레이크를 만들어 구조화된 데이터와 구조화되지 않은 데이터를 혼합하고 회사 데이터 자산에 대한 한층 더 종합적인 관점을 제공할 수 있습니다.

그림 3: 데이터 분석을 통한 확대

AWS는 수집부터 처리, 저장, 분석, 시각화, 자동화까지 전체 데이터 수명 동안 서비스를 제공합니다. 복제 도구는 메인프레임의 관계형, 계층적 또는 레거시 파일 기반 데이터 스토어에서 민첩한 AWS 데이터 레이크, 데이터 웨어하우스 또는 데이터 스토어로 메인프레임 데이터를 실시간으로 복사합니다. 이 실시간 복제로 데이터가 새것으로 유지되고 최신 분석과 대시보드가 가능해지며, 메인프레임은 레코드 원본으로 유지합니다.

일례로 미국의 한 여객 철도 회사는 이 절에서 설명한 패턴에 따라 판매, 마케팅, 수익, 사기 분석을 위한 실시간 대시보드와 보고를 통해 메인프레임 데이터를 활용했습니다. APN 블로그에서는 ‘AWS 및 Attunity Replicate로 메인프레임 데이터를 활용하는 방법‘을 통해 실시간 데이터 복제를 보여 줍니다.

패턴 4: 새로운 채널을 통한 확대

레거시 언어를 사용한 메인프레임 개발 주기는 느리고 융통성이 없기 때문에 고객들은 AWS를 사용하여 새로운 서비스를 신속히 구축하면서 로컬 AWS 데이터 스토어에 있는 실시간 메인프레임 데이터에 액세스합니다. 이것은 패턴 3의 변형으로서 로컬 메인프레임 데이터를 분석이 아니라 최종 사용자용 신규 통신 채널과 신규 기능에 사용합니다. AWS의 민첩한 새 기능은 레거시 메인프레임 애플리케이션을 확대합니다. 새로운 채널의 예는 모바일 또는 음성 기반 애플리케이션일 수도 있고, 마이크로서비스 또는 머신 러닝에 기반한 혁신일 수도 있습니다.

그림 4: 새로운 채널을 통한 확대

이 패턴은 AWS에서 새로운 채널을 배포하여 값비싼 메인프레임 MIPS 증가를 방지합니다. 데이터가 복제되기 때문에 데이터 아키텍트는 메인프레임과 AWS 데이터 스토어에서 잠재적인 데이터 일관성 또는 무결성 문제에 주의해야 합니다.

일례로 미국의 한 대형 상업 은행은 AWS에서 새로운 Lambda 기반 서버리스 마이크로서비스를 개발하여 DynamoDB에 있는 복제된 메인프레임 데이터에 액세스하고 이 새로운 서비스를 API 게이트웨이를 통해 모바일 사용자에게 제공했습니다. 이 패턴의 도구는 패턴 3 도구와 비슷하며, 레거시 데이터 스토어 또는 메인프레임 메시징 시스템에서 실시간 데이터 복제를 수행합니다.

메인 프레임 이전 과정 및 모범 사례

우리는 과거 프로젝트, 고객, 파트너 경험에서 배운 것을 토대로 메인프레임을 개발해 AWS 모범 사례로 개선하고 있습니다.

1. 신기술 적용 테스트 (POC) – AWS로 이전할 메인프레임 워크로드의 가장 복잡한 기술적 측면을 해결할 수 없으면 프로젝트는 실패할 수 있습니다. 위험을 줄이려면 고객은 복잡한 POC를 요청해 고객만의 가장 어려운 시나리오로 도구 기능을 평가해야 합니다. 이것은 POC 범위가 커야 한다는 뜻이 아니라 소수의 POC 테스트 케이스가 최대한 세밀해야 한다는 뜻입니다. 고객 메인프레임 워크로드에 따라 배치 기간, 다수의 프로그램 및 데이터 의존성, 비지니스 논리, 일반적이지 않은 레거시 기술 또는 버전, 지연 시간 요구 사항, 높은 초당 처리량이나 트랜잭션 또는 많은 양의 코드나 데이터에 있을 수 있습니다. 세밀한 POC는 도구의 능력을 검증하고, 도구 결과물의 품질을 보여 주며, 도구 공급업체와 고객에게 성공적인 협업을 보증합니다.
2. 자동화 – 메인프레임은 일반적으로 수백만 줄의 코드와 페타바이트 규모의 데이터를 호스팅합니다. 사람의 개입은 오류, 위험, 테스트, 기간, 비용을 늘립니다. 따라서 단기 현대화 프로젝트는 수동으로 재작성 없는 최대한의 자동화와 함께 입증된 소프트웨어 스택을 사용합니다. 이러한 자동화에는 마이그레이션 규칙을 적용하기 위한 자동화, 코드 리팩터링을 위한 자동화, 데이터 현대화를 위한 자동화, 테스트 실행을 위한 자동화(CI/CD 파이프라인)가 포함됩니다.
3. 패턴, 도구, 아키텍처, 활동 순서 결정 – 개별 이전 패턴은 전체 접근 방법의 틀을 잡으며, 패턴마다 다른 도구 세트가 필요합니다. 개발 도구는 메인프레임 현대화의 중요한 성공 요인이며, 가능한 한 일찍 세밀한 POC를 사용하여 기술적으로 테스트해야 합니다. 도구가 검증되면 도구와 AWS 모범 사례를 바탕으로 전체 아키텍처가 생성됩니다. 그 다음에는 기술적 아키텍처가 현대화 구현 활동을 주도합니다.
4. 벤더 중립적인 패턴 선택 – 메인프레임 현대화에서 모든 경우에 두루 적합한 단일 방법이나 단일 도구는 없습니다. 도구 공급업체들은 한 가지 패턴에만 집중하는 경향이 있습니다. 또한 패턴마다 여러 공급업체와 도구가 존재합니다. 따라서 패턴 선택은 공급업체 제약이 없어야 하고(vendor agnostic), 고객의 비즈니스 및 IT 전략 우선 순위와 고객 메인프레임 스택의 기술적 제약이 중심이 되어야 합니다.
5. 시스템 통합 사업자 선택 – 컨설팅 및 시스템 통합 서비스 회사는 AWS로의 메인프레임 현대화 프로젝트의 모든 단계에서 다양한 정도로 도움을 줄 수 있습니다. 오직 한 가지 패턴과 선호하는 한 가지 도구에만 특화되어 있는 시스템 통합 사업자가 있는가 하면 여러 패턴과 패턴별로 여러 도구를 아우르는 시스템 통합 사업자도 있습니다. 현대화 도구 선택에 앞서 한 가지 특정 도구에 대한 시스템 통합 사업자의 전문성이 아닌 고객의 최선의 이익을 기준으로 패턴과 도구에 대해 조언하려면 컨설팅 전문 서비스가 패턴 중립적이고 공급업체 중립적이어야 합니다. 다른 한편 일단 고객 시스템 통합 사업자가 도구를 선택하고 나면 전문 서비스는 선택된 메인프레임 현대화 도구와 AWS 관련 전문성을 갖춰야 합니다. 관련된 기능이 다양하기 때문에(컨설팅, 메인프레임, AWS, 현대화, 도구, 통합, 테스트) 팀 또는 전문 서비스 회사의 연합이 참여하는 것을 흔히 볼 수 있습니다.
6. 레거시 데이터 스토어 현대화 – AWS에서 계층적 데이터베이스 또는 색인 데이터 파일 같은 레거시 데이터 스토어를 유지하면 단일 장애 지점, 병목 현상 또는 낡은 데이터 모델 같은 레거시 기술 부채와 제약 및 인터페이스가 그대로 유지됩니다. 어떤 패턴이건 데이터 스토어 및 데이터 액세스 계층 현대화는 일반적으로 소규모 투자를 통해 확장성, 가용성, 민첩성, 운영, 기술, 비용 절감, 데이터 통합 및 새로운 기능 개발을 위한 더 큰 이득을 제공합니다.
7. 워크로드 기반 현대화 – 여러 독립적 워크로드를 호스팅하는 대규모 메인프레임의 경우, 워크로드마다 서로 다른 현대화 패턴에 따를 수 있습니다.
8. 기술적 이전과 비즈니스 팀과 동시 협업– 이전 도구는 일반적으로 빠르게 기술적인 현대화에 우선 최적화되어 있습니다. 비즈니스 수준의 변경 또는 리팩터링에는 수동 개입과 비즈니스 팀의 참여가 필요하며, 메인프레임과 AWS 사이에서 몇 가지 기능적 동등성 테스트를 수행할 수 없습니다. 따라서 비즈니스 현대화와 기술적 현대화를 동시에 혼용하면 복잡성, 기간, 위험, 비용이 증가합니다.
9. 도구 평가 방식 정의 – 레거시 기술 스택 지원, 복잡한 POC 성공, IT 전략 정렬, 프로젝트 속도(매달 마이그레이션되는 코드 줄 수 등), 대상 애플리케이션 스택 민첩성, 대상 데이터 스토어 민첩성, 대상 코드 유지 관리, 코드 줄당 마이그레이션 비용, 대상 스택 라이선스 비용, 투자 수익(ROI) 속도 등을 정의해야 합니다.
10. 이전 및 실행 시간 비용 추정 – 현대화 비용에는 현대화 과정에서 사용하는 도구의 라이선스 비용과 현대화 활동에 필요한 전문 서비스 비용이 포함됩니다. 여기에 더해 ROI 속도에 직접 영향을 미치는 대상 아키텍처의 반복적 실행 시간 비용이 중요합니다. 실행 시간 비용에는 도구 라이선스 비용(있는 경우)과 AWS 서비스 비용이 포함됩니다. 예를 들어 고객이 반복적인 연간 실행 시간 비용을 80% 줄이는 경우, 3년 후에 현대화 비용을 회수할 수 있어 그 이후로는 신규 투자에 사용할 수 있는 상당한 절감이 발생합니다.

마무리

최근 대기업 고객들은 AWS를 활용하여 메인프레임을 현대화합니다. 이 글에서 알려드린 패턴, 모범 사례, 파트너 프로그램 등이 이러한 프로젝트를 성공적으로 이끌고 있습다. 여러분이 메인프레임 현대화 프로젝트에 관심이 있으시다면, 여러 모로 도움이 되기를 바랍니다. 클라우드 이전을 시작하시려면 다음 조치를 취하는 것이 좋습니다.

1. 비즈니스 및 IT 우선 순위와 더불어 메인프레임의 기술적 아키텍처를 수집합니다.
2. 가능한 AWS 현대화 패턴을 이해하고 선호하는 패턴을 결정합니다.
3. 선택한 패턴과 메인프레임 특성을 가장 잘 지원하는 도구와 공급업체를 파악합니다.
4. 도구의 가치 제안을 평가하고 복잡한 개념 증명을 사용하여 선택을 확인합니다.

AWS로의 메인프레임 마이그레이션에 대해 자세히 알아보려면 언제든지 문의하십시오. APN Blog 메인프레임 섹션에서 우리 파트너의 가치 제안을 검토해 보십시오. 메인프레임이 아닌 레거시 AS/400 또는 iSeries 또는 IBM i 시스템을 위한 유사한 패턴과 모범 사례도 있습니다.

https://aws.amazon.com/ko/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/

Amazon Aurora- MySQL은 데이터베이스 워크로드를 통합(Database consolidation)하려는 고객에게 인기 있는 옵션입니다. Aurora MySQL은 고성능 상용 데이터베이스의 속도와 안정성에 오픈 소스 데이터베이스의 간편성과 비용 효율성이 결합된 관계형 데이터베이스 엔진입니다. 또한, 표준 MySQL 커뮤니티 에디션과 비교하여 최대 5배의 처리량을 제공합니다.

이 블로그 게시물에서는 대규모 통합 데이터베이스 워크로드를 위해 Amazon Aurora를 최적화하는 데 도움이 되는 몇 가지 지침을 제공합니다. 또한, “얼마나 많은 DB를 통합할 수 있습니까?” 혹은 “데이터 세트가 얼마나 커질 수 있습니까?”와 같은 일반적인 질문에 대한 답을 제공합니다. 이러한 질문이 간단하긴 하지만 답 또한 항상 간단한 것은 아닙니다. 답은 데이터 세트와 워크로드 패턴에 따라 크게 좌우됩니다.

데이터베이스 통합 정의

통합 사용 사례의 경우, 다음 차원에 초점을 맞춘 후 Aurora MySQL이 이러한 컨텍스트에서 어떻게 작동하는지를 자세히 설명합니다.

1. 테이블 크기. 더 큰 테이블은 일반적인 통합의 결과입니다. 광고 기술, IoT 또는 소비자 애플리케이션 분야라면 대개 대규모 동종 애플리케이션 데이터베이스를 데이터 하위 집합이 포함된 여러 개의 샤드로 분할합니다. Aurora에서는 샤딩을 완전히 포기할 수는 없지만 더 적은 수의 샤드로 통합하여 운영 오버헤드를 줄일 수 있습니다.
2. 테이블 수. 늘어난 테이블 수 또한 통합의 결과입니다. 이러한 결과는 테넌트 격리가 필요한 SaaS 애플리케이션, 즉 각 테넌트가 자체 데이터베이스 또는 테이블 세트를 사용하는 SaaS 애플리케이션에서 일반적으로 발생합니다. 이러한 유형의 멀티 테넌트는 더 적은 수의 더 큰 Aurora 클러스터로 함께 패키징되어 테넌트당 운영 비용을 줄입니다.
3. 데이터베이스 사용률. 동시 연결 수 증가를 비롯하여 여러 지표에서 통합된 데이터베이스 워크로드 사용률이 증가합니다.

실제로 동일한 프로젝트에서 이러한 차원 중 몇 가지가 증가하는 것을 경험하게 됩니다. 다음 지침은 이러한 차원 전체에서 워크로드를 최적화하는 데 도움이 됩니다.

데이터베이스의 최대 크기

Amazon Aurora에는 몇 가지 최대 한도가 있습니다. 가장 눈에 띄는 것은 Aurora 클러스터의 최대 스토리지 볼륨 크기가 64TB라는 것입니다. 볼륨 최대 크기는 Aurora 클러스터에 물리적으로 저장할 수 있는 데이터 양에 대한 상한을 제공합니다. 또한, 개별 테이블 크기에 대한 상한도 제공합니다.

MySQL 호환 데이터베이스 엔진인 Aurora MySQL은 MySQL과 InnoDB 스토리지 엔진의 속성을 다수 상속받습니다. 이 중 일부가 효과적으로 통합할 수 있는 양에 영향을 미칩니다.

테이블 크기를 최적화하는 방법

Amazon Aurora는 16KiB 페이지를 사용하여 데이터를 저장합니다. 페이지는 테이블과 관련 인덱스의 컨테이너 역할을 하는 테이블스페이스로 그룹화됩니다. 기본적으로 Aurora는 테이블별로 또는 테이블이 파티션된 경우 테이블의 파티션별로 별도의 테이블스페이스를 사용합니다. 테이블스페이스에 주로 포함된 것은 다음과 같은 데이터 구조입니다.

• 테이블 레코드가 포함되어 있고 테이블의 기본 키 또는 고유 키로 정렬된 클러스터링된 인덱스. 두 키 모두 사용할 수 없는 경우, 일정하게 증가하는 내부 행 ID가 레코드를 식별하고 정렬하는 데 사용됩니다.
• 테이블의 보조 인덱스.
• 클러스터링된 인덱스 레코드에 적합하지 않은 가변 길이 필드에 대한 외부 저장 값(BLOB, TEXT, VARCHAR, VARBINARY 등).

앞의 테이블 아키텍처는 주어진 테이블에 저장할 수 있는 최대 행의 수가 정해져 있지 않다는 것을 의미합니다. 최대 행 수는 몇 가지 요인에 따라 달라집니다.

• 기본 키 또는 고유한 키 옵션에서 지원하는 최대 고유 값 수. 예를 들어 기본 키에 부호 없는 INT 데이터 유형을 사용하는 경우(일반적인 선택), 테이블에서 최대 232 또는 최소 42억 9천 개의 행을 지원합니다.
• 보조 인덱스의 수 및 크기.
• 클러스터링된 인덱스 레코드에 직접 또는 외부 페이지에 저장된 가변 길이 데이터 양.
• 데이터 페이지가 얼마나 효과적으로 사용되는지.

스키마 디자인 및 쿼리 패턴은 실제로 얼마나 효과적으로 테이블을 통합할 수 있는지를 결정할 때 행 수보다 중요한 요인입니다. 테이블의 행 수가 증가하면 클러스터링된 인덱스 및 보조 인덱스의 크기와 이러한 인덱스를 트래버스하는 데 걸리는 시간도 증가합니다. 따라서 쿼리 성능은 테이블 크기에 따라 감소합니다. 성능 저하를 좀 더 심층적으로 완화할 수 있는 몇 가지 모범 사례와 방법을 살펴보겠습니다.

1. 대량 레코드 포함 테이블을 위한 스키마 설계

쿼리 패턴 및 스키마의 컨텍스트에서 페이지당 레코드 밀도는 큰 테이블 크기에서 점점 더 중요해집니다. 가변 길이를 제외하고 Aurora MySQL의 최대 행 길이는 8KB에 약간 못 미칩니다(데이터 페이지의 절반). 데이터베이스는 페이지를 관리하여 성능 저하 없이 스토리지 효율성을 유지합니다. MySQL 커뮤니티 에디션의 InnoDB처럼 Aurora MySQL은 향후 쓰기 작업을 수용하고 페이지 분할 수를 줄이기 위해 페이지 일부를 채우지 않고 비워둡니다. 또한, 채우기 비율이 50% 이하로 떨어지면 페이지를 함께 병합하려고 시도합니다. 페이지가 완전히 채워지는 경우는 없으므로 항상 일정량의 스토리지 오버헤드가 발생합니다.

최적의 스키마 디자인은 유용한 오버헤드가 과도한 스토리지 낭비가 되지 않도록 보장하는 최선의 방법입니다. 이러한 낭비는 리소스 사용률과 지연 시간 증가로 이어지므로, 수용 가능한 성능 이상으로 워크로드에 부담을 줍니다.

효과적인 스키마 디자인을 위한 두 가지 매우 중요한 지침이 있습니다.

1. 주어진 테이블 행의 모든 정보의 가치는 모두 같아야 합니다. 즉, 행의 모든 필드에 있는 데이터를 동일한 빈도로 쿼리하고 조작해야 합니다. 동일한 행에 사용 빈도가 다른 데이터를 저장하는 것은 비효율적입니다.
2. 항상 주어진 열에 저장된 값을 나타낼 수 있는 가장 작은 데이터 유형을 선택하십시오. 개별 행 수준에서는 효과가 미비할 수 있지만, 잠재적으로 수십억 개의 행에서는 그 효과가 확대되어 현저한 차이를 보입니다.

스키마에 가변 길이 필드가 포함된 경우, Aurora MySQL은 가능한 많은 가변 길이 데이터를 클러스터링된 인덱스 레코드에 저장하려고 시도하며 나머지는 외부 페이지에 저장됩니다. 대규모 데이터 레코드는 데이터 페이지의 레코드 밀도를 낮추어 쿼리 성능을 저하시킵니다. 하지만 쿼리가 가변 길이 필드를 비롯하여 모든 레코드 데이터(읽기 및 쓰기)에 지배적인 영향을 미치는 경우 여전히 대규모 레코드를 원할 수도 있습니다. 그런 경우가 아니라면 대규모 필드는 별도 테이블로 오프로드하는 것이 유용할 수 있습니다. 또는 데이터베이스가 아닌 Amazon S3와 같은 객체 스토어에 저장하는 것이 더 좋습니다.

인덱스는 쿼리 성능을 높이는 데 효과적입니다. 하지만 추가 비용이 발생하고 추가 스토리지와 메모리 공간을 소비하며 쓰기 성능을 저하시킵니다. 보조 인덱스 레코드는 열의 물리적 스토리지 좌표를 직접 가리키지 않습니다. 대신에 해당 열의 기본 키 값을 가리킵니다. 따라서 모든 보조 인덱스 레코드에는 해당 행의 기본 키 값 사본이 포함되어 있습니다.

이에 따라 복합 기본 키로 인해 더 큰 인덱스 레코드가 생기고 궁극적으로 스토리지 및 I/P 효율성이 떨어집니다. 필요한 인덱스만 사용하고 복합 인덱스에서 인덱스 선택은 왼쪽에서 오른쪽으로 이동한다는 것을 기억하십시오. 쿼리 패턴에서 해당 선택 규칙을 따르도록 허용하는 경우, 인덱스를 더 적은 수의 복합 인덱스로 대체하여 인덱스 수를 줄일 수 있습니다.

궁극적으로 효과적인 스키마 디자인을 사용하면 수용할 수 없는 성능을 경험할 필요 없이 더 많은 수의 행이 있는 테이블을 보유할 수 있습니다. 하지만 최대 행 수가 몇 개가 될지는 실제 데이터 및 해당 데이터와 상호 작용하는 방법에 달려 있습니다.

2. 대량 레코드 포함 테이블 쿼리

파티션(및 하위 파티션)은 대규모 테이블에서 성능 감소를 완화하는 도구입니다. 기본적으로 각 파티션은 별도의 테이블스테이스에 저장되므로, 파티션에는 파티셔닝 표현식에 정의된 대로 클러스터링된 인덱스, 보조 인덱스, 해당 특정 데이터 하위 세트의 외부 페이지가 포함되어 있습니다. 테이블당 최대 8,192개의 파티션 및 하위 파티션을 가질 수 있습니다. 하지만 파티션 수가 많으면 그 자체로 성능 문제가 발생합니다. 많은 수의 파티션을 사용하는 쿼리로 인해 메모리 사용률이 증가하고 성능 문제가 발생하는 것이 이에 포함됩니다.

파티션의 인덱스 구조가 더 작으므로 트래버스하는 것이 더 빠릅니다. 쿼리 패턴이 단일 파티션 또는 매우 작은 파티션 세트를 선택적으로 읽는 경우(파티션 프루닝(partition pruning)이라고 부르는 최적화 기능), 성능 이점을 누릴 수 있습니다. 하지만 예를 들어 파티션된 열이 포함되지 않은 조건자가 있는 쿼리처럼 일부 특정 파티션만 선택적으로 읽지 않는 쿼리는 속도가 더 느릴 수 있습니다. 파티션에서는 엔진이 하나의 더 큰 인덱스 대신 여러 개의 더 작은 인덱스를 트래버스해야 하므로 이 효과가 발생합니다. 따라서 파티션된 대규모 테이블의 성능 영향은 워크로드에서 파티션 프루닝 또는 파티션 셀렉션을 얼마나 효율적으로 활용하는지에 달려 있습니다.

대규모 테이블의 경우 정확한 통계가 쿼리 옵티마이저에 중요합니다. 정확한 통계는 쿼리 옵티마이저가 올바른 카디널리티로 가장 선별된 인덱스를 사용하도록 지원하므로 쿼리 성능이 향상됩니다. 기본적으로 Aurora MySQL은 20개의 임의 인덱스 페이지를 샘플링하여 통계와 카디널리티를 예측합니다. 하지만 매우 큰 테이블 또는 열 내 값이 균일하지 않은 테이블을 처리할 때는 이 개수로는 충분하지 않을 수 있습니다. 또한, 기본적으로 통계는 디스크에 유지되고 테이블의 상당 부분이 변경되면 자동으로 다시 계산됩니다. 10% 이상의 행에 영향을 미치는 DML(데이터 조작 언어) 작업을 예로 들 수 있습니다.

매우 큰 테이블에서는 이 정도 규모의 변경은 자주 발생하지 않으므로 시간이 지나면서 통계의 정확도가 감소할 수 있습니다. 따라서 임계점에 도달하고 쿼리 옵티마이저가 실행 계획을 변경하면 영향을 받은 쿼리의 성능이 시간이 지나면서 계속해서 또는 급격히 저하됩니다. 이것이 문제가 된다고 생각하는 경우, EXPLAIN 문을 사용하여 쿼리 실행 계획을 검토하여 예상되는 동작의 변경 사항을 찾아내십시오.

또한, 핵심 워크로드 쿼리의 예상 성능 기준선을 설정하고 시간이 지나면서 성능을 모니터링하는 것이 좋습니다. 느린 쿼리 로그는 특정 임계값을 초과하는 쿼리를 로깅하는 데 효과적이지만, 시간 경과에 따라 천천히 진행되는 성능 저하를 캡처하는 데는 효과적이지 않습니다. MySQL 5.6 호환 버전에서 지속적으로 쿼리 성능을 모니터링하려면 MySQL 성능 스키마를 사용하면 됩니다. 하지만 이 기능을 활성화하면 메모리 소비가 증가하고 전반적인 시스템 성능도 저하될 수 있습니다.

통계의 정확성을 개선할 수 있는 두 가지 메커니즘이 있습니다.

1. 정보 스키마를 사용하여 관련 테이블에 대한 테이블 및 인덱스 통계의 경과 시간을 모니터링(INNODB_TABLE_STATS 및 INNODB_INDEX_STATS)한 후 ANALYZE TABLE을 실행하여 적절하게 통계를 업데이트합니다.
2. DB 인스턴스에 대한 DB 파라미터 그룹을 사용자 지정하고 샘플링되는 페이지 수를 늘리면 정확도가 증가합니다(아래 표 참조). 하지만 샘플링되는 페이지를 늘리면 통계를 계산하는 데 걸리는 시간 또한 늘어납니다.

3. 대규모 테이블의 데이터 스키마에 대한 변경 처리

DDL(데이터 정의 언어) 작업이 문제가 되려면 테이블이 얼마나 커야 합니까? 크기도 한 요인이지만 테이블이 얼마나 활발하게 사용되는지가 더 중요할 수 있습니다. 테이블이 초당 수천 개의 쓰기 작업을 지원하고 있다면, 상대적으로 레코드 수백만 개의 상대적으로 작은 테이블도 DDL 작업을 실행하기에 문제가 될 수 있습니다.

워크로드 또는 워크로드에 대한 업데이트가 빈번한 DDL 작업 및 스키마 변경에 의존하는 경우, 이러한 작업으로 인해 매우 큰 테이블을 사용할 수 있는 기능이 제한될 수 있습니다. 이 동작은 MySQL 커뮤니티 에디션이 작동하는 방식과 비슷합니다. 오프라인 DDL 작업은 데이터를 올바른 스키마의 새로운 테이블스페이스로 복사합니다. 따라서 적절한 여유 용량을 확보해야 합니다. 또한, 작업 범위에 따라 테이블이 잠기므로 일반 워크로드에 영향을 줍니다. 온라인 DDL 작업은(수행 가능한 경우) 테이블 데이터를 직접 변경합니다. 하지만 임시 스페이스에서 테이블에 대한 새로운 쓰기를 버퍼링하므로 해당 쓰기가 다시 병합될 때만 테이블이 잠깁니다. 장기 실행 온라인 DDL 작업을 수행하는 테이블에 대한 매우 많은 수의 쓰기를 생성하는 워크로드의 경우, 병합할 변경 사항의 양이 상대적으로 많습니다. 이 크기는 병합 단계 잠금에 걸리는 시간일 길어지는 데 영향을 줍니다. 극단적인 경우, 테이블 변경 작업이 완료되기 전에 임시 스페이스가 고갈되어 실질적으로 온라인 DDL 작업이 완료되지 못할 수 있습니다.

Aurora MySQL은 빠른 DDL을 지원하므로, 거의 즉각적인 작업으로 테이블 끝에 nullable 열을 추가할 수 있습니다. 이 기능은 앞에서 설명한 DDL의 단점 일부를 완화하는 데 도움이 됩니다. 일반 DDL 또는 빠른 DDL 작업으로는 효율적으로 처리할 수 없는 DDL 작업의 경우, Percona 온라인 스키마 변경 도구를 사용하여 이 작업을 실행하는 것을 고려해 볼 수 있습니다. 이 도구를 사용 사례에 적용하면, 덜 파괴적인 방법으로 DDL 작업을 수행할 수 있지만 매우 큰 테이블에서는 작업이 더 오래 걸립니다.

다수의 테이블을 최적화하는 방법

통합된 워크로드로 인해 많은 수의 테이블이 Aurora 클러스터에 저장될 수 있습니다. 실제로 하나의 Aurora 클러스터에 통합될 수 있는 적정 테이블 수는 워크로드와 액세스 패턴에 따라 달라집니다.

파일 시스템 속성이 데이터베이스 확장성(테이블 크기와 수)을 제한하는 MySQL 커뮤니티 에디션과는 달리 Aurora MySQL은 특별히 구축된 분산 로그 구조의 스토리지 서비스를 사용합니다. 따라서 파일 시스템의 상속된 한계를 완화하기 위해 MySQL에서 사용자 지정 테이블스페이스 구성을 사용하는 수많은 이유가 Aurora에는 적용되지 않습니다. 운영 측면 또는 장애 복구 측면에서, 테이블 수가 많다고 해서 파일 시스템에 영향을 주지는 않습니다. Aurora 사용자 지정 DB 클러스터 파라미터를 사용하여 inndb_file_per_table 옵션을 비활성화할 수 있지만, 권장하지는 않습니다. 성능 또는 복구 시간에 더는 영향을 주지 않기 때문입니다.

하지만 Aurora에 많은 수의 테이블이 있으면 메모리 사용률에 영향을 줍니다. 기본 파라미터가 설정된 Aurora 클러스터의 메모리 사용량은 다음과 같습니다.

다수 테이블 관련 캐시 최적화

테이블 수가 많은 워크로드와 특히 관련이 캐시가 두 가지 있습니다. 이러한 캐시를 잘못 구성하면 잠재적으로 성능 및 안정성 문제가 발생할 수 있습니다.

테이블 캐시(또는 테이블 오픈 캐시)는 사용자 활동의 결과로 열린 테이블의 핸들러 구조를 저장합니다. 테이블은 각 세션별로 독립적으로 열립니다. 따라서 동일한 테이블에 액세스하는 여러 개의 동시 세션이 있는 경우 캐시는 해당 테이블에 대해 여러 항목을 포함할 수 있습니다. Aurora에서는 r4 클래스의 DB 인스턴스에 대해 이 캐시의 기본 크기를 6,000개의 오픈 테이블로 늘렸습니다. 하지만 이는 소프트 한도입니다. 이 캐시는 SQL 문과 관련된 테이블 수(및 해당 테이블의 파티션 수)에 따라 상당한 메모리를 소비하게 될 수 있습니다. 이러한 영향은 워크로드가 데이터베이스에서 실행하고 있는 동시 세션 수에 의해 증폭됩니다.

테이블 정의 캐시는 메모리에서 일반적으로 액세스되는 테이블에 대한 테이블 정의(스키마, 메타데이터)를 저장합니다. 테이블이 활발하게 사용될수록 테이블 정의를 캐시하는 것이 좋습니다. Aurora에서는 r4 클래스의 DB 인스턴스에 대해 이 캐시의 기본 크기를 최대 20,000개의 정의를 저장하도록 늘렸습니다. 따라서 이 캐시는 중요한 메모리 소비자가 될 수 있습니다. 수십만 개의 테이블을 사용하는 워크로드의 경우, 테이블 대부분이 활성 상태라면 이 캐시 크기를 기본 값 이상으로 늘릴 수 있는 혜택이 있습니다. 이 캐시 크기 또한 소프트 한도입니다. MySQL 데이터베이스 엔진은 상위-하위 외래 키 관련 테이블에 대한 테이블 정의를 제거하지 않습니다. 그러므로 캐시의 총 크기는 캐시 크기 한도를 초과할 수 있습니다.

따라서 효율적인 메모리 사용은 주어진 크기의 인스턴스로 Aurora 클러스터에서 운영할 수 있는 테이블 수를 실질적으로 제한할 수 있습니다. 이러한 캐시 공간을 줄이기 위해서는 이를 수용할 수 있도록 더 큰 DB 인스턴스 클래스를 사용해야 할 수 있습니다. 또는 이를 벌충하기 위해 쿼리 캐시 또는 버퍼 풀에 할당되는 메모리 양을 줄여야 할 수 있습니다. 이렇게 줄이면 다른 방식으로 워크로드 성능에 영향이 미칠 수 있습니다. 메모리가 작업 데이터 세트를 충족할 수 없기 때문입니다. 하지만 “너무 많은” 테이블이 정확히 몇 개를 말하는지 찾아내기가 어렵습니다. 다음 예제에서 이러한 효과를 더 잘 확인할 수 있습니다.

아래 차트는 테이블이 1,000개인 데이터베이스에 대해 40개의 동시 연결을 사용하여 수행된 sysbench 읽기 및 쓰기 OLTP 테스트의 향상된 모니터링 지표를 통해 보고된 free 메모리를 보여줍니다. 이 워크로드는 61GB의 메모리가 탑재된 Aurora MySQL 5.6 호환 db.r4.2xlarge DB 인스턴스(인기 있는 인스턴스 클래스)에서 단 10분 동안 실행되었습니다.

이 테스트의 경우 다음 명령을 사용해 테스트 실행 전에 데이터베이스와 테이블을 준비합니다.

sysbench oltp_read_write --table-size=1000 --tables=1000 --threads=40 --time=600 --max-requests=0 --db-driver=mysql --mysql-host=<aurora_db_cluster_endpoint> --mysql-db=sbtest --mysql-user=<user> --mysql-password=<password> prepare

이 시스템의 free 메모리는 테스트가 시작될 때 갑자기 12.2GB에서 5GB가 하락하고 CPU 리소스는 테스트를 거치면서 거의 모두 고갈됩니다. MySQL 커뮤니티 에디션과는 달리 Aurora는 버퍼 풀을 사전에 할당하며 이전 테스트에서 이미 워밍 상태였습니다. 비교적 적은 수의 활성 테이블(1,000개)과 총 동시 연결(40개)로 테스트를 수행했습니다. 메모리 소비는 테이블 캐시와 많은 수의 활성 테이블이 관련되어 있을 때 각 연결에 대한 증폭 효과로 인해 주로 발생합니다.

DB 인스턴스 파라미터 그룹의 table_open_cache 파라미터는 테이블 캐시 크기를 제어합니다. 기본적으로 이 파라미터는 다음 수식을 사용하여 설정됩니다.

lesser of (<DB instance class memory in bytes>/1,179,121) or 6,000

비교를 위해 다음 차트가 유사한 테스트를 보여줍니다. 유일한 차이점은 이 테스트에서 액세스하는 테이블이 500개뿐이라는 것입니다. 여기에서 시스템의 free 메모리는 테스트가 시작될 때 갑자기 12.2GB에서 약 2.5GB가 하락합니다.

다음 예제는 많은 수의 테이블이 사용될 때 테이블 정의 캐시의 영향을 보여줍니다. 이 테스트에서 예제 워크로드는 100,000개의 간단한 테이블을 생성하며, 각 테이블에는 자동 증가 정수 기본 키, 타임스탬프 열, 부동 소수점 열, 2개의 짧은 문자열 열이 있습니다. 이 테스트에서는 15.25GB의 메모리가 탑재된 Aurora MySQL 5.7 호환 db.r4.large DB 인스턴스에서 실행되는 단일 연결을 사용하여 하나의 행을 간단한 테이블 각각에 삽입합니다. Aurora 클러스터에서 실행되는 다른 활동은 없으며, 클러스터는 빈 상태에서 시작됩니다.

워크로드가 증가함에 따라 free 메모리가 어떻게 감소하는지 확인할 수 있습니다. 캐시 한도에 도달하면서 free 메모리가 안정화되며, 전체적으로 700MB의 메모리가 추가적으로 사용되고 이는 주로 테이블 정의 캐시에 사용됩니다.

DB 인스턴스 파라미터 그룹의 table_definition_cache 파라미터는 테이블 정의 캐시의 크기를 제어합니다. 기본적으로 이 파라미터는 다음 수식을 사용하여 설정됩니다.

lesser of (<DB instance class memory in bytes>/393,040) or 20,000

결론적으로 실제로 통합할 수 있는 테이블 수는 몇 가지 요인에 따라 달라집니다. 이러한 요인은 활발하게 사용되는 테이블 수, 가용 메모리 양, 지원해야 하는 동시 연결 수입니다.

높은 데이터베이스 리소스 사용률을 최적화하는 방법

이 게시물의 앞부분에서 더 큰 테이블 또는 더 많은 수의 테이블이 CPU 또는 메모리와 같은 서버 리소스 사용률에 영향을 미친다는 것을 설명했습니다. 하지만 워크로드 통합 자체가 사용률을 높입니다. 데이터베이스 샤드 수가 감소하면, 나머지 데이터베이스 샤드마다 더 많은 동시 연결이 설정될 수 있습니다. 각 통합 데이터베이스는 더 많은 작업을 수행하고 읽기 및 쓰기 쿼리 볼륨이 증가합니다.

Amazon Aurora for MySQL에는 내부 서버 연결 풀링 및 스레드 멀티플렉싱이 함께 제공되므로, 수천 개의 동시 연결을 처리할 때 경합을 줄이고 확장성을 개선할 수 있습니다. 최대 16,000개의 동시 연결을 허용하도록 각 Aurora DB 인스턴스를 구성할 수 있습니다. 하지만 워크로드 및 DB 인스턴스 클래스 선택에 따라 실제 최대 값이 이보다 적은 수로 제한될 수 있습니다.

각 연결, 세션 및 스레드는 현재 실행 중인 특정 SQL 문을 기반으로 다양한 버퍼, 캐시, 기타 메모리 구조에서 다양한 양의 메모리를 소비합니다. 이러한 소비는 결정적이지 않으며, 이 블로그 게시물의 앞부분에서 설명한 다른 구조들과 마찬가지로 같은 양의 가용 메모리를 두고 경쟁합니다. 효과적인 연결 관리 및 규모 조정에 대한 모범 사례를 이해하려면 연결 관리를 위한 Amazon Aurora MySQL DBA 핸드북 백서가 훌륭한 리소스입니다. 더 크고 더 높은 처리량의 워크로드에 대한 연결 사용률을 최적화하는 데 도움이 되는 유용한 조언이 포함되어 있습니다.

요약

Amazon Aurora with MySQL Compatibility를 여러 데이터베이스 워크로드 통합을 위한 솔루션으로 고려할 때 여러 가지 요인이 개입하게 됩니다. 완전한 목록은 아니지만, 앞서 설명한 항목에는 이러한 통합을 구현하는 고객을 지원할 때 보게 되는 공통된 고려 사항이 포함되어 있습니다. 모든 워크로드가 다르므로, 통합에 대한 실질적인 제한은 사례마다 다릅니다.

모범 사례는 프로덕션 규모의 기본값에서 구성 변경 사항을 철저하게 테스트하고 성능과 안정성에 수량화할 수 있는 긍정적인 영향이 미치는 경우에만 이를 구현하는 것입니다. 이 모범 사례는 MySQL 커뮤니티 에디션에서 구성을 가져올 때 특히 중요합니다. Aurora는 같은 방식으로 동작하지 않을 수 있기 때문입니다. 워크로드 통합 프로젝트를 실행하는 방법에 대한 자세한 내용은 AWS 데이터베이스 블로그의 Reduce Resource Consumption by Consolidating Your Sharded System into Aurora 게시물을 참조하십시오.

https://aws.amazon.com/ko/blogs/developer/aws-cdk-developer-preview/ 기계번역문

우리는 TypeScript, JavaScript 및 Java 용 AWS 클라우드 개발 키트 (CDK) 개발자 미리보기 릴리스 를 발표하게 된 것을 기쁘게 생각합니다 . .NET 및 Python이 곧 출시 될 예정입니다. AWS CDK는 클라우드 인프라를 코드로 정의하고 CloudFormation을 통해 프로비저닝하는 소프트웨어 개발 프레임 워크입니다. CDK는 AWS 서비스와 완벽하게 통합되며 AWS 리소스를 필수적으로 정의하기 위해 더 높은 수준의 객체 지향 추상화를 제공합니다. CDK는 현대 프로그래밍 언어의 힘을 사용하여 예측 가능하고 효율적인 방식으로 AWS 인프라를 정의하므로 엔드 투 엔드 개발 경험을 향상시킵니다.

CDK를 클라우드 인프라 스트럭처 "컴파일러"로 생각할 수 있습니다. AWS 클라우드 리소스를 추상화하고 AWS 모범 사례를 캡슐화하는 Constructs 라는 고수준 클래스 라이브러리 세트를 제공합니다 . 구문은 응용 프로그램 인프라를 정확하게 정의하고 모든 복잡한 상용구 논리를 처리하는 개체 지향 CDK 응용 프로그램 으로 함께 스냅 할 수 있습니다 . CDK 응용 프로그램을 실행하면 AWS 클라우드 인프라의 "어셈블리 언어"인 CloudFormation 템플릿 으로 컴파일됩니다 . 그러면 템플릿이 CloudFormation 프로비저닝 엔진에 의해 처리되어 AWS 계정에 배포 될 준비가됩니다. CDK 도구를 사용하면 쉽게 정의 할 수 있습니다.애플리케이션 인프라 스트럭처 스택, CloudFormation 서비스는 스택의 안전하고 신뢰할 수있는 프로비저닝 을 처리합니다.

익숙한 도구

CDK를 통해 우리는 매일 사용하는 친숙한 환경과 팀 워크 플로에 인프라 정의를 가져 와서 가장 편안하고 생산적인 곳에서 만날 수 있습니다. CDK는 사용자가 선호하는 객체 지향 프로그래밍 언어를 지원하므로 루프 및 조건과 같은 코드 논리를 자연스럽게 표현하여 모든 환경 또는 시나리오에 맞게 인프라를 사용자 지정할 수 있습니다. CDK 코드는 코드 일 뿐이므로 인라인 설명서, 리팩토링 도구, 코드 탐색 및 단위 테스트와 같은 기존 IDE 기능이 모두 예상대로 작동합니다. 다음 코드는 가용성 영역 및 지역별 AMI ID와 같은 인프라 스트럭처 논리 및 환경 컨텍스트를 사용하여 단일 코드 기반에서 다른 지역에 대한 다양한 응용 프로그램 스택을 만드는 방법을 보여줍니다. 인프라 정의 복사 및 붙여 넣기가 필요하지 않습니다.

// 현재 지역 / 계정에 대한 AZ 목록 가져 오기

const azs = new cdk.AvailabilityZoneProvider(this).availabilityZones;

//이 영역의 특정 Windows 버전에 대한 AMI ID 가져 오기

const ami = new ec2.WindowsImage(ec2.WindowsVersion.WindowsServer2016EnglishNanoBase).getImage(this);

for (const az of azs) {

// 가용성 영역을 기반으로 구조체 이름을 렌더링합니다.

const constructName = `InstanceFor${az.replace(/-/g, ”).toUpperCase()}`;

new ec2.cloudformation.InstanceResource(this, constructName, {

imageId: ami.imageId,

availabilityZone: az,

});

}

세부 사항 요약

CDK는 개발자가 최신 프로그래밍 언어와 객체 지향 기술을 사용하여 CloudFormation 템플릿을 생성 할 수있는 최초의 솔루션이 아닙니다. CDK는 AWS 서비스와 완벽하게 통합되어 IAM 정책, 보안 그룹 및 네트워크 구성과 같은 주요 리소스를 자동으로 종합하는 유용한 API를 제공합니다. 예를 들어 인프라에 Amazon Virtual Private Cloud (VPC)를 추가하려면 다음 코드 줄을 CDK 응용 프로그램에 추가하기 만하면됩니다.

new ec2.VpcNetwork(this, ‘MyVPC’);

CDK 애플리케이션이 컴파일되면 대상 지역의 각 가용 영역에 대한 서브넷과 경로, 경로 표, 서브넷 경로 표 연결, NAT 게이트웨이, 인터넷 게이트웨이 및 필요한 탄성 IP를 정의하는 긴 CloudFormation 템플릿이 생성됩니다 모든 일을하도록하십시오. 스마트 한 기본값 중 일부가 요구 사항을 충족시키지 못하면 VPC 매개 변수를 자신의 값으로 쉽게 재정의 할 수 있습니다.

확장 가능

AWS에서 작성한 CDK Constructs가 제공하는 유용한 API를 활용하는 것 외에도 예측 가능하고 재사용 가능한 코드로 자신 만의 모범 사례를 정의 할 수 있습니다. 예를 들어, 암호화가 활성화 된 S3 버킷을 항상 만드는 CDK 응용 프로그램을 제작하여 팀이 기본적으로 자연스럽게이 작업을 수행 할 수 있습니다.

new s3.Bucket(this, ‘EncryptedBucket’, {

encryption: s3.BucketEncryption.KmsManaged

});

독창적 인 클라우드 고유의 디자인 패턴을 인코딩하고 특정 사용 사례에 중점을두고 내부적으로나 전 세계와 공유하는 더 높은 수준의 CDK 응용 프로그램을 정의 할 수 있습니다. 우리는 당신이 만든 멋진 것들을보기 위해 기다릴 수 없습니다.

바자Bazaar 방문

우리는 닫힌 성당이 아닌 열린 시장처럼 CDK를 건설하고 있습니다. 아직 끝나지 않았습니다! 참조, 익숙하지 않은 사람들을 위해 성당과 시장 , 두 가지 기본적인 소프트웨어 개발 스타일을 대조 에릭 S. 레이몬드에 의해 에세이이며, 오픈 소스, "감안할 때 충분히 눈알, 모든 버그 얕은하다"인수한다 . 오픈 소스 개발자 미리보기이므로 AWS에서 클라우드 애플리케이션을 개발할 때 CDK를 최고의 경험으로 활용할 수 있도록 도와주십시오. aws-cdk GitHub README 를 방문하여 CDK를 시작하는 방법을 배우십시오. Gitter 에 게시 하여 대화를 시작하고, 개발자와 의견 을 교환하고, 풀 요청을 제출하십시오.귀하의 상품을 기부하거나, 단지 우리에게 관심을 보이기 위해 프로젝트에 별표 를 붙이십시오. 우리는 당신과의 협력을 기대합니다.

아마존의 14가지 리더십 원칙 (The amazon way, 14 leadership principle)

여기에서 리더는 당신이다. 즉, Self Leadership을 말하고 있는 것이다.

1. 고객에 집착하라

리더는 고객에서부터 시작하며 나머지는 그 다음이다. 리더는 고객의 신뢰를 얻고 유지하기 위해 끊임없이 노력하며, 경쟁사들에게 관심을 갖기는 해도 집착하는 대상은 어디까지나 고객들이다.

리더는 고객의 관점에서 생각하고 행동해야 한다. 고객에게 신뢰를 얻고 유지하기 위해 전력을 다해야 한다. 리더는 경쟁사에 신경을 써야 하지만, 무엇보다 고객을 중심으로 생각하는 데 집착해야 한다. 아마존의 미션과 비전인 고객 중심주의와 일맥상통하는 표현이기 때문에 가장 중요한 항목이다.

Customer Obsession

Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

2. 주인의식을 가져라

리더은 곧 주인이다. 그들은 장기적인 관점에서 생각하고, 단기적 성과를 위해 장기적 가치를 희생시키지 않는다. 또한 자신의 팀을 넘어서 회사 전체를 대표한다는 생각으로 행동한다. 리더들은 “그것은 내 일이 아니야."라고 절대 말하지 않는다.

리더에게는 주인의식이 필요하다. 리더는 장기적인 시야로 생각해야 하며, 단기적인 결과를 위해 장기적인 가치를 희생해서는 안 된다. 리더는 자신의 팀뿐만 아니라 회사 전체를 위해 행동해야 한다. 리더 입에서 “그건 내 업무가 아니다”라는 말이 절대로 나와서는 안 된다.

Ownership

Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job". 

3. 발명하고 단순화하라

리더는 그들의 팀에 혁신(innovation)과 창의(invention)을 요구하고 또한 기대하며, 항상 단순화 시킬 방법을 찾는다. 리더는 외부의 상황의 변화에 주의하고 모든 곳에서 새로운 아이디어를 얻는다.  "우리가 개발한 것이 아니다(NIH 신드룸)"라는 것에 얽매지 않는다. 우리는 새로운 아이디어를 실행에 옮길 때, 오랜 시간 동안 오해를 받을 준비도 되어 있다.

리더는 팀에 혁신과 창조를 요구해야 하며, 늘 심플한 방법이 없는지를 모색해야 한다. 상황의 변화를 예의주시하고, 모든 곳에서 새로운 아이디어를 찾아내야 한다. 본인들이 만들어낸 것에 국한된 이야기가 아니다. 리더는 새로운 아이디어를 실행하는 데 있어 오랜 기간에 걸쳐 외부에 오해를 살 수 있는 일이더라도 그것을 받아들여야 한다

리더는 그들의 팀이 발명(invention)하고 혁신(innovation)하기를 기대하고 요구하며, 단순화시킬 방법을 찾는 노력을 잠시도 멈추지 않는다. 또한 리더는 조직 외부의 상황에도 아주 밝아 모든 곳으로부터 새로운 아이디어를 얻는다. 뿐만 아니라 사고방식에 구애를 받지 않는다. 오히려 리더들은 오랜 시간 동안 오해 받을 상황을 무릅쓰고 두려움 없이 혁신에 뛰어든다.

Invent and Simplify

Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here". As we do new things, we accept that we may be misunderstood for long periods of time.

4. 리더는 정확하고 옳아야 한다

항상 옳지는 않아도, 대부분 옳다. 리더들은 뛰어난 사업적 판단력을 보유하고, 자신의 목표는 물론이고 성공을 측정하는데 사용되는 지표들을 더없이 명확히 밝힘으로써 다른 사람들에게 자신의 뛰어난 판단력을 전파한다.

리더는 모든 상황에 올바르게 판단해야 한다. 강력한 판단력과 더불어 경험에 기반을 둔 직감을 갖추어야 한다. 다양한 사고방식을 추구하고, 자신의 생각을 반증하는 데 거리낌이 없어야 한다.

리더는 대부분 올바른 판단을 한다. 그들은 좋은 본능적 감각으로 훌륭한 판단을 한다. 그들은 다양한 관점을 추구하며, 그들의 신념에 대해 반증하는 것도 마다하지 않습니다.

Are Right, A Lot

Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.

5. 자기계발 : 배우고 호기심을 가져라

리더에게 배움의 끝이란 없으며 리더는 항상 스스로를 발전시킬 방법을 찾아야 한다. 리더는 새로운 가능성에 강렬한 호기심을 갖고 가능성을 탐구하기 위해 행동한다.

리더는 끊임없이 배우고 자기 자신을 향상해야 한다. 새로운 가능성에 호기심을 갖고 실제로 그것을 행동으로 옮겨야 한다.

Learn and Be Curious

Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.

6. 최고를 채용하고 육성하라

리더는 모든 채용과 승진에 있어 성과 기준을 높인다. 리더는 특별한 인재를 알아보는 눈이 있고 조직 전반에 그들을 능동적으로 배치한다. 또한 리더는 미래의 리더들을 육성할 뿐 아니라, 다른 사람들을 올바른 방향으로 이끄는 코치로서의 역할에 최선을 다한다.

리더는 모든 채용과 승진에 참고가 되는 성과의 기준을 끌어올려야 한다. 뛰어난 재능을 가진 인재를 발굴해서, 조직 전체를 위해 능동적으로 활용해야 한다. 리더는 다른 리더를 육성하고 지도하는 데 진지하게 노력해야 하며 모든 구성원을 위해 새로운 성장 매커니즘을 창출해야 한다.

Hire and Develop the Best

Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.

7. 최고의 기준을 고집하라

리더는 많은 사람들이 터무니없이 높다고 생각할 만큼 높은 기준을 세운다. 하지만 여기서 그치지 않고, 그들은 기준을 끊임없이 끌어올리고 자신의 팀이 제품과 서비스 그리고 프로세스의 품질 수준을 지속적으로 향상시키도록 이끈다. 뿐만 아니라 리더는 조직이 높은 기준을 유지할 수 있도록, 아무리 적은 숫자라도 품질 관리 프로세스에서 걸러지지 않은 불량품이 생산되지 않도록 최선을 다하며 문제들을 해결한다.

리더는 남들이 터무니없다고 생각할 정도로 높은 수준을 추구해야 한다. 끊임없이 본인이 추구하는 수준을 끌어올려야 하고, 팀이 더욱 품질 높은 제품과 서비스, 프로세스를 실현할 수 있도록 촉구해야 한다. 리더는 결함 있는 제품을 다음 공정으로 내보내서는 안 되며, 문제를 확실히 해결하여 같은 문제가 재차 발생하지 않도록 개선책을 마련해야 한다.

Insist on the Highest Standards

Leaders have relentlessly high standards - many people may think these standards are unreasonably high. Leaders are continually raising the bar and drive their teams to deliver high quality products, services and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.

8. 크게 생각하라

협소한 관점으로 생각하는 것은 자기 충족적 예언이다. 아마존의 리더는 구체적인 결과를 만들어내는 대담한 목표점을 제시하고, 그 목표점을 널리 알리며 팀을 그 방향으로 이끈다. 그들은 다르게 생각하고, 고객을 섬기기 위한 최선의 방법을 찾아서 구석구석 살피고 또 살핀다.

좁은 시야로 생각하면 커다란 결과를 얻을 수 없다. 리더는 대담한 방침과 방향성을 마련하고 제시함으로써 성과를 끌어내야 한다. 고객에게 이바지하기 위해 기존과 다른 새로운 관점에서 모든 가능성을 모색해야 한다.

Think Big

Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

9. 신속하게 판단하고 행동하라

리더는 계산된 위험 감수를 가치 있게 생각한다. 비즈니스에서는 속도가 생명이다. 많은 결정과 행동은 되돌릴 수 있고, 광범위한 연구가 꼭 필요하지도 않다. 고로 확신이 없을 때는 우선 시도하라. 자신의 분야에서 첫번째 사람이 됨으로써 얻을 수 있는 기회를 최대한 활용하라.

비즈니스는 속도가 생명이다. 대부분의 의사결정과 행동은 나중에 바로잡을 수 있으므로 거창한 분석과 검토는 불필요하다. 리더는 예측 가능한 위험을 감수하는 것도 중요하다.

행동을 위한 편중

Bias for Action

Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

10. 근검절약을 실천하라

리더는 고객들에게 중요한 영향을 주지 않는 일에는 돈을 쓰려고 하지 않는다. 근검절약은 독창성을 드높이고, 자급자족 능력을 키우며 발명을 낳는다. 머릿수를 늘리고 예산을 올린다고 가산점이 주어지지는 않는다.

리더는 더 적은 자원으로 더 많은 것을 실현해야 한다. 절약 정신은 창의적 아이디어, 자립심, 발명을 만들어내는 원천이다. 직원 수, 예산, 고정비는 많다고 좋은 것이 아니다.

Frugality

Accomplish more with less. Constraints breed resourcefulness, self-sufficiency and invention. There are no extra points for growing headcount, budget size or fixed expense.

11. 신뢰를 얻어라

리더는 진실로 열린 마음을 갖고, 진심을 다해 경청하며, 겸손의 마음으로 자신의 가장 큰 신념을 시험한다. 그들은 솔직하고, 그래서 주변 사람들을 신뢰할뿐 아니라 주변 사람들의 신뢰를 얻을 수 있다.

리더는 주의 깊게 듣고, 솔직하게 말하며, 구성원을 존경심으로 대해야 한다. 잘못이 있다면 내키지 않더라도 솔직하게 인정해야 하며, 자신과 팀의 잘못을 그냥 넘어가서는 안 된다. 항상 자신과 팀을 최고 수준에서 비교 평가해야 한다.

Earn Trust

Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.

12. 깊게 파고들어라

리더는 모든 수준의 업무에 관여하고 매순간 세부사항을 파악하고 있을뿐 아니라 세부사항을 자주 점검한다. 그들에게 중요하지 않은 업무란 없다. 특정 프로세스의 가장 기본적인 사항까지 깊이 파고들어야만, 기회를 포착할 수 있고 문제가 손 쓸 수 없을 만큼 악화되기 전에 미리 해결할 수 있음을 알기 떄문이다.

리더는 모든 수준의 업무에 관여하고, 항상 세부 내용을 파악해 현황을 수시로 감시하며, 지표와 개별 사례가 일치하지 않는다면 의문을 제기해야 한다. 모든 업무에 가치가 있다고 여기고 관심을 기울여야 한다.

Dive Deep

Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.

13. 기개를 가져라 - 반대하되 받아들여라

리더에게는 굳은 신념과 확신이 있다. 어떤 결정에 반대할 때는 비록 불편하고 지치는 한이 있더라도 결정에 대해 정중하게 이의를 제기할 의무가 있다. 아마존의 리더는 결정을 할 때 집단 내부의 단결을 위해 타협하지 않는다. 그러나 논의 끝에 결정이 확정되고 나면 그 결정에 온전히 전념한다.

리더는 찬성할 수 없는 사안에는 정중하게 이의를 제기해야 한다. 번거롭고 피곤하겠지만 예외는 있을 수 없다. 리더는 신념을 가져야 하며 금방 포기해서는 안 된다. 쉽게 타협해 한통속이 되어서는 안 된다. 다만 논의 끝에 일단 결정이 내려졌다면 결정에 전념하고 몰두해야 한다.

자신의 신념에 대한 명확한 기준을 가지고 그에 대한 기개를 가져야 한다. 이를 위해 주장해야 하고 타협하지 않아야 한다. 하지만 어떤 방향이든 결정이 되면 그에 따라 전념한다.

Have Backbone; Disagree and Commit

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

14. 구체적인 성과를 내라

리더는 자신의 업무에서 핵심적인 산출물에 초점을 맞추고 적절한 시기에 적절한 품질의 결과물을 낸다. 리더는 어려움이 닥쳐도 잘 대처하고 절대 안주하지 않는다.

리더는 비즈니스상의 핵심 투입에 초점을 맞추고, 이를 신속하게 실행해 결과를 내야 한다. 설령 어려운 일이 생기더라도 당당하게 맞서야 하며 결코 타협해서는 안 된다.

Deliver Results

Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

출처:  https://www.amazon.jobs/principles  
https://m.blog.naver.com/playautocorp/221241097750   
https://books.google.co.kr/books?id=teZ1DwAAQBAJ&lpg=PP1&hl=ko&pg=PT301#v=onepage&q&f=false