들어가기 전에

• 원문: (영어) https://medium.com/google-cloud/how-to-run-visual-studio-code-in-google-cloud-shell-354d125d5748
• Visual Studio Code의 서버판인 code-server를 Google Cloud shell에 설치 및 구동하여 브라우저 환경의 개발 환경을 만들어 어서 쓸 수 구성하는 방법 입니다. 사실 그냥 서버에 설치하면 되긴합니다. 잠시 쓸 경우 비용감소와 편리성에 있겠네요.
• Cloud Shell : GCP 의 양방향 셸 환경
• 증폭 모드 (Boost mode) : 기본제공되는 g1-small(0.5vCpu x 1.70GB Memory)타입에서 24 시간동안 n1-standard-1(1 vCPU x 3.75GB Memory) 타입으로 성능을 올려서 사용하는 기능
• 상세내용은 다음 링크에서 확인가능합니다.
  https://cloud.google.com/shell/docs/features?hl=ko

1. console.cloud.google.com 로 접속후 Cloud Shell 을 띄웁니다.

2. 좀 더 빠르게 하기 위해 Cloud Shell 의 메뉴버튼에서 '증폭 모드'를 활성화 합니다.

3. Cloud Shell에 아래 내용을 붙여 넣어서 code-server 를 설치합니다.

export VERSION=`curl -s https://api.github.com/repos/cdr/code-server/releases/latest | grep -oP '"tag_name": "\K(.*)(?=")'`
wget https://github.com/cdr/code-server/releases/download/$VERSION/code-server$VERSION-linux-x64.tar.gz
tar -xvzf code-server$VERSION-linux-x64.tar.gz
cd code-server$VERSION-linux-x64

4. code-server를 실행합니다.

./code-server --no-auth --port 8080

5. '포트에서 미리보기 8080' 을 선택하여 새 탭에서 CloudShell을 엽니다.

6. 새창이 열리면서 404 에러가 뜰것입니다. 그러면 주소창에서 '?authuser=0' 를 삭제하고 엔터를 칩니다.

7. 이제 code-server를 사용하실 수 있습니다.

Java 에서는 자체적으로 DNS Caching을 하기 때문에 잘 신경 쓰지 않는데...

그 외의 경우... (사실 기본적으로 확인)

가끔, CPU도 놀고, Network도 여유있고, Memory도 여유 있고, Disk io도 여유 있고 (queue depth기준), 암튼 다 노는데.. 애플리케이션 느리 다면 한번쯤 DNS 쿼리 응답 속도를 체크 해볼 필요성이 있다.

그냥 로컬 DNS Caching 서비스를 설치하면 바로 개선이 보인다.

다면 Caching 시간은 Failover등으로 IP가 변경 될 수 있음을 고려할때, 초 단위로 짧게 하는게 맞을 듯 하다.

전통적으로 nscd 와 dnsmasq를 많이 쓰는듯하고. bind9 되고.. (갈수록 기능이 많고 덩치가 커짐)

AWS는 공식적으로 dnsmasq를 가이드 하는듯.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/dns-resolution-failures-ec2-linux/

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

IPMI CLI의 경우 서버 자체에서 실행시 Admin으로 실행이 된다. (인증 정보를 묻지 않음)
네트워크(ipmilan)을 통해서 Admin으로 실행 시키기 위해서 root의 권한을 변경해보자.
(Softlayer의 IPMI에서 root는 일반 유저(Operator) 권한이다)

Windows (IPMICFG는 Supermicro 홈페이지에서 다운.)

https://www.supermicro.com/SwDownload/SwSelect_Free.aspx?cat=IPMI

IPMICFG-Win.exe -user list  
IPMICFG-Win.exe -user level 3 4

Linux

ipmitool user list 1  
ipmitool channel setaccess 1 3 privilege=4

Linux 에서 IPMI Log 가져오기

결론 요약 커맨드

#로그 확인
ipmitool -I lan -U root -L USER sel list -H 10.178.209.106
#현재 시스템 시간
ipmitool -I lan -U root -L USER sel time get -H 10.178.209.106

네트워크 접근

Softlayer 에서는 IPMI의 사설 주소는 같은 계정 내에서는 모두 접근 할수 있다.
물론 네트워크 정책상 허용 했을 경우 이다. (기본 허용)
VLAN 분리나, 방화벽으로 분리한 경우는 당연히 안된다.

IPMI 계정 접근

포털 UI나 API로 확인 가능하다.
그런데 User ID는 기본으로 root인데 권한은 일반 USER이다. (괜히 헤갈리게 ㅡoㅡ+)
물론 티켓으로 root 유저를 Admin으로 승급 시켜달라고 하면 해주긴한다.
그냥 IPMI 커맨드를 날리면 Privilege Level : ADMINISTRATOR 로 잡기 때문에
Activate Session error: Requested privilege level exceeds limit 오류가 뜬다.
결론은 -L USER 옵션을 주면 그냥 USER 권한으로 실행한다.
지금은 로그 값 읽기만 하면 되므로 그냥 기본 USER 권한을 유지한 채로 사용 할것이다.

디버그 옵션

-vv 옵션을 주면 상세 내용이 나온다.

[root@cmd ~]# ipmitool -H 10.178.209.106 -U root fru
Password:
Activate Session error:    Requested privilege level exceeds limit
Error: Unable to establish LAN session
Error: Unable to establish IPMI v1.5 / RMCP session

이걸 -vv를 주면 Privilege Level : ADMINISTRATOR 를 요청 해서 오류나는것을 확인 할 수 있다.

[root@cmd ~]# ipmitool -vv -H 10.178.209.106 -U root fru
Password:
Sending IPMI/RMCP presence ping packet
Received IPMI/RMCP response packet:
  IPMI Supported
  ASF Version 1.0
  RMCP Version 1.0
  RMCP Sequence 255
  IANA Enterprise 4542

ipmi_lan_send_cmd:opened=[1], open=[-204238448]
Channel 01 Authentication Capabilities:
  Privilege Level : ADMINISTRATOR
  Auth Types      : MD2 MD5 PASSWORD
  Per-msg auth    : enabled
  User level auth : enabled
  Non-null users  : enabled
  Null users      : disabled
  Anonymous login : disabled

Proceeding with AuthType MD5
ipmi_lan_send_cmd:opened=[1], open=[-204238448]
Opening Session
  Session ID      : ff00001a
  Challenge       : 458a142850a040802142840810204080
  Privilege Level : ADMINISTRATOR
  Auth Type       : MD5
ipmi_lan_send_cmd:opened=[1], open=[-204238448]
Activate Session error:    Requested privilege level exceeds limit
Error: Unable to establish LAN session
Error: Unable to establish IPMI v1.5 / RMCP session

FRU (Field Replaceable Unit) 확인

root@cmd ~]# ipmitool -H 10.178.209.106 -U root -L USER fru
Password:
FRU Device Description : Builtin FRU Device (ID 0)
 Chassis Type          : Other
 Chassis Part Number   : CSE-819UTS-ㅇㅇㅇㅇ-ST031
 Chassis Serial        : C8ㅇㅇㅇㅇㅇㅇ13
 Board Mfg Date        : Mon Jan  1 09:00:00 1996
 Board Mfg             : Supermicro
 Board Serial          : OM17ㅇㅇㅇㅇ9
 Board Part Number     : X11DPU
 Product Manufacturer  : Supermicro
 Product Part Number   : SYS-ㅇㅇㅇㅇ-TN4R4T
 Product Serial        : A291ㅇㅇㅇㅇ908570

SEL (System Event Log) 확인

-I lan은 인터페이스 지정으로 위에서 처럼 생략 가능 하다. -L USER로 권한을 일반 유저로 지정한 것을 확인한다.

 [root@cmd ~]# ipmitool -I lan -U root -L USER sel list -H 10.178.209.106
Password:
   1 | 02/12/2019 | 23:43:04 | OS Boot | C: boot completed () | Asserted
   2 | 02/12/2019 | 23:56:40 | OS Critical Stop | Run-time critical stop () | Asserted
   3 | 02/12/2019 | 23:56:40 | OS Critical Stop | OS graceful shutdown () | Asserted
   4 | 02/12/2019 | 23:58:28 | OS Boot | C: boot completed () | Asserted
   5 | 02/12/2019 | 23:59:19 | OS Critical Stop | OS graceful shutdown () | Asserted
   6 | 02/13/2019 | 00:01:27 | OS Boot | C: boot completed () | Asserted
   7 | 02/13/2019 | 00:18:01 | Unknown #0xff |  | Asserted
   8 | 02/13/2019 | 00:19:30 | Physical Security #0xaa | General Chassis intrusion () | Asserted
   9 | 02/13/2019 | 00:20:08 | OS Boot | C: boot completed () | Asserted
   a | 02/13/2019 | 00:47:00 | OS Critical Stop | OS graceful shutdown () | Asserted
   b | 02/13/2019 | 00:49:20 | OS Boot | C: boot completed () | Asserted
   c | 02/14/2019 | 03:42:02 | OS Critical Stop | OS graceful shutdown () | Asserted
   d | 02/14/2019 | 10:18:49 | OS Boot | C: boot completed () | Asserted
   e | 02/14/2019 | 10:22:57 | OS Boot | C: boot completed () | Asserted
   f | 02/14/2019 | 10:35:27 | OS Boot | C: boot completed () | Asserted
  10 | 02/14/2019 | 10:49:15 | OS Critical Stop | Run-time critical stop () | Asserted
  11 | 02/14/2019 | 10:49:15 | OS Critical Stop | OS graceful shutdown () | Asserted
  12 | 02/14/2019 | 10:51:04 | OS Boot | C: boot completed () | Asserted
  13 | 02/14/2019 | 10:51:55 | OS Critical Stop | OS graceful shutdown () | Asserted
  14 | 02/14/2019 | 10:54:03 | OS Boot | C: boot completed () | Asserted
  15 | 02/14/2019 | 11:39:11 | OS Critical Stop | OS graceful shutdown () | Asserted
  16 | 02/14/2019 | 11:41:31 | OS Boot | C: boot completed () | Asserted
  17 | 03/21/2019 | 23:50:01 | OS Critical Stop | OS graceful shutdown () | Asserted
  18 | 03/21/2019 | 23:52:24 | OS Boot | C: boot completed () | Asserted
  19 | 03/21/2019 | 23:53:10 | OS Critical Stop | OS graceful shutdown () | Asserted
  1a | 03/21/2019 | 23:55:23 | OS Boot | C: boot completed () | Asserted
  1b | 04/14/2019 | 21:24:42 | Session Audit #0xff |  | Asserted
  1c | 04/14/2019 | 21:34:01 | Session Audit #0xff |  | Asserted
  1d | 04/14/2019 | 21:40:01 | Session Audit #0xff |  | Asserted
  1e | 04/14/2019 | 21:41:17 | Session Audit #0xff |  | Asserted

IPMI 상의 현재 시스템 시간 확인

 [root@cmd ~]# ipmitool -I lan -U root -L USER sel time get -H 10.178.209.106

활용

AWX에서 서버별 실행해서 Elastic Search로 집어넣으려고 했으나.... 변경 분만 어떻게 넣을 지 고민이다.
그냥 매번 넣고 ES에서 중복제거를 해야 할지..

IPMI 세부 참조는 아래 글 참고

https://docs.oracle.com/cd/E19464-01/820-6850-11/IPMItool.html#50602039_63068
http://fibrevillage.com/sysadmin/71-ipmitool-useful-examples
http://coffeenix.net/board_print.php?bd_code=1765
http://coffeenix.net/board_print.php?bd_code=1766
https://annvix.com/using_swatch_to_monitor_logfiles

클라우드 컴퓨팅은 소프트웨어 설계 및 데이터 센터의 역할 / 기능에 대해 우리가 알고있는 것을 변화 시켰습니다. 클라우드로의 여행은 클라우드 제공 업체를 선택하고 사설망을 프로비저닝하거나 사내 네트워크를 확장하는 것으로 시작됩니다. 클라우드에서 리소스를 프로비저닝하려는 고객은 다양한 클라우드 공급자가 제공하는 다양한 사설 네트워크 중에서 선택할 수 있습니다. 가장 많이 배치 된 사설망은 가상 네트워크 (VNet) 및 가상 사설 클라우드 (VPC)마이크로 소프트와 아마존으로부터 각각. 이 블로그는 잠재적 인 고객에게 두 개의 사설망을 차별화 할 수있는 정보를 제공하고 작업 부하에 적합한 결정을 내리는 데 도움이되는 두 가지 사설 네트워크 제품의 유사점과 차이점을 살펴 봅니다. 이 시리즈의 첫 번째 블로그에서는 모든 클라우드 네트워크의 기본 구성 요소를 다룰 것입니다. 이 현재 블로그는 복잡성 때문에 가격을 비교하지 않을 것이며 향후 게시물에서 다루어 질 것입니다.

개념적으로 Azure VNet과 AWS VPC는 ​​모두 클라우드에서 자원과 서비스를 프로비저닝하기위한 기반을 제공합니다. 두 네트워크 모두 동일한 빌딩 블록을 제공하지만 구현의 정도에는 차이가 있습니다. 다음은 이러한 빌딩 블록 중 일부에 대한 요약입니다.

• 서브넷 - Azure VNet과 AWS VPC는 ​​클라우드에 배치 된 자원을 효과적으로 설계하고 제어하기 위해 네트워크를 서브넷과 분리합니다. AWS VPC는 ​​해당 지역의 모든 가용 영역 (AZ)에 걸쳐 있으므로 AWS VPC의 서브넷은 가용 영역 (AZ)에 매핑됩니다. 서브넷은 하나의 AZ에만 속해야하며 AZ를 스팬 할 수 없습니다. Azure VNet 서브넷은 할당 된 IP 주소 블록에 의해 정의됩니다. AWS VPC의 모든 서브넷 간 통신은 AWS 백본을 통해 이루어지며 기본적으로 허용됩니다. AWS VPC 서브넷은 개인 또는 공개 중 하나 일 수 있습니다. 인터넷 게이트웨이 (IGW)가 연결된 서브넷은 공용입니다. AWS는 VPC 당 하나의 IGW 만 허용하며 공용 서브넷은 배포 된 리소스가 인터넷 액세스를 허용합니다. AWS는 각 지역에 대한 기본 VPC 및 서브넷을 만듭니다. 이 기본 VPC에는 VPC가 상주하는 각 지역에 대한 서브넷이 있으며, 이 VPC에 배포 된 모든 이미지 (EC2 인스턴스)에는 공용 IP 주소가 할당되므로 인터넷 연결이 가능합니다. Azure VNet은 기본 VNet을 제공하지 않으며 AWS VPC와 같이 개인 또는 공용 서브넷을 갖지 않습니다. VNet에 연결된 리소스는 기본적으로 인터넷에 액세스 할 수 있습니다.
• IP 주소 - AWS VPC와 Azure VNET 모두 RFC 1918에 명시된대로 개인 IPv4 주소 범위의 전역 적으로 라우팅 할 수없는 CIDR을 사용합니다.이 RFC의 주소는 전 세계적으로 라우팅 할 수 없지만 고객은 다른 공용 IP 주소를 계속 사용할 수 있습니다. Azure VNet은 지정된 CIDR 블록의 개인 IP 주소에 VNet에 연결되어 배포 된 리소스를 할당합니다. Azure VNet에서 지원되는 가장 작은 서브넷은 / 29이고 가장 큰 서브넷은 / 8입니다. 또한 AWS는 동일한 RFC 1918 또는 공개적으로 라우팅 가능한 IP 블록의 IP 주소를 허용합니다. 현재 AWS는 공개적으로 라우팅 가능한 IP 블록에서 인터넷에 직접 액세스 할 수 없으므로 인터넷 게이트웨이 (IGW)를 통해서도 인터넷에 연결할 수 없습니다. 가상 사설망을 통해서만 접근 할 수 있습니다. 이 때문에 Windows 인스턴스를 범위가 224.0.0.0~ 인 VPC에 시작하면 Windows 인스턴스를 올바르게 부팅 할 수 없습니다.255.255.255.255(클래스 D 및 클래스 E IP 주소 범위). 서브넷의 경우 AWS는 / 28의 최소 주소 블록과 / 16의 최대 주소 블록을 권장합니다. 이 블로그를 작성할 때 Microsoft Azure VNet의 IPv6 지원은 제한적이지만 AWS VPC는 ​​2017 년 1 월 현재 중국을 제외한 모든 지역에 대해 IPv6을 지원합니다. IPv6의 경우 VPC는 ​​고정 크기 인 / 56 (CIDR 표기법) 서브넷 크기는 / 64로 고정됩니다. IPv6에서는 모든 주소가 인터넷 라우팅이 가능하며 기본적으로 인터넷에 연결할 수 있습니다. AWS VPC는 ​​전용 서브넷의 리소스에 Egress-Only Internet Gateway (EGW)를 제공합니다. 아웃 바운드 트래픽을 허용하면서 들어오는 트래픽을 차단합니다. AWS를 사용하면 기존 리소스에 대해 IPv6을 사용하도록 설정하고 인터넷에 액세스해야하는 사설 서브넷의 리소스에 대해 전용 인터넷 게이트웨이를 제공 할 수 있습니다. 발신 전용 인터넷 게이트웨이는 인터넷에 액세스 할 수 있지만 들어오는 트래픽은 차단합니다. 이러한 CIDR 블록에서 IP 주소를 할당하는 방법을 이해하면 AWS VPC 네트워크를 설계하는 것이 중요합니다. 디자인 이후 서브넷 IP 주소를 변경하는 것이 쉽지 않기 때문입니다. Azure VNet은이 분야에서 더 많은 유연성을 제공합니다 -서브넷의 IP 주소 는 초기 설계 후에 변경할 수 있습니다. 그러나 현재 서브넷의 리소스는 현재 서브넷에서 마이그레이션해야합니다.
• 라우팅 테이블 - AWS는 경로 테이블을 사용하여 서브넷의 아웃 바운드 트래픽에 허용되는 경로를 지정합니다. VPC에서 생성 된 모든 서브넷은 자동으로 기본 라우팅 테이블과 연결되므로 VPC의 모든 서브넷은 보안 규칙에 의해 명시 적으로 거부되지 않는 한 다른 서브넷의 트래픽을 허용 할 수 있습니다. Azure VNet에서 VNet의 모든 리소스는 시스템 경로를 사용하여 트래픽 흐름을 허용합니다. 기본적으로 Azure VNet은 서브넷, VNets 및 사내 구축 형 네트워크 간의 라우팅을 제공하므로 경로를 구성하고 관리 할 필요가 없습니다. 시스템 경로를 사용하면 트래픽이 자동으로 원활하게 처리되지만 가상 어플라이언스를 통해 패킷 라우팅을 제어하려는 경우가 있습니다. Azure VNet은 시스템 경로 테이블을 사용하여 모든 VNet의 서브넷에 연결된 리소스가 기본적으로 서로 통신하는지 확인합니다. 하나, 기본 경로를 재정의하려는 경우가 있습니다. 이러한 시나리오의 경우 사용자 정의 라우트 (UDR)를 구현할 수 있습니다. 트래픽이 각 서브넷에 라우팅되는 위치 및 / 또는 BGP 라우트 (Azure VPN 게이트웨이 또는 ExpressRoute 연결을 사용하여 VNet을 사내 구축 형 네트워크로) 제어 할 수 있습니다. UDR은 서브넷에서 나가는 트래픽에만 적용되며 UDR의 목표가 일종의 검사 NVA 등으로 트래픽을 보내는 것이라면 Azure VNet 배포에 보안 계층을 제공 할 수 있습니다. UDR을 사용하면 다른 서브넷에서 하나의 서브넷으로 전송 된 패킷을 일련의 라우트에서 네트워크 가상 어플라이언스를 통과하도록 강제 설정할 수 있습니다. 하이브리드 설정에서 Azure VNet은 UDR, BGP (ExpressRoute가 사용되는 경우) 및 시스템 라우팅 테이블의 세 가지 경로 테이블 중 하나를 사용할 수 있습니다. Azure VNet에서, 서브넷은 라우트 테이블이 명시 적으로 서브넷과 연관 될 때까지 트래픽에 대한 시스템 라우트에 의존합니다. 연결이 설정되면, 즉 UDR 및 / 또는 BGP 라우트가 존재하면 가장 긴 접두사 일치 (LPM)를 기반으로 라우팅이 수행됩니다. 프리픽스 길이가 동일한 경로가 두 개 이상인 경우 경로는 사용자 정의 경로, BGP 경로 (ExpressRoute 사용시) 및 시스템 경로 순으로 해당 출발지를 기준으로 선택됩니다. 반면 AWS VPC에서 라우팅 테이블은 둘 이상일 수 있지만 동일한 유형입니다. BGP 경로 (ExpressRoute 사용시)와 시스템 경로. 반면 AWS VPC에서 라우팅 테이블은 둘 이상일 수 있지만 동일한 유형입니다. BGP 경로 (ExpressRoute 사용시)와 시스템 경로. 반면 AWS VPC에서 라우팅 테이블은 둘 이상일 수 있지만 동일한 유형입니다.
• 보안 - AWS VPC는 ​​네트워크에 배포 된 리소스에 대해 두 가지 수준의 보안을 제공합니다. 첫 번째 보안 그룹 (SG)이라고합니다. 보안 그룹은 EC2 인스턴스 수준에서 적용되는 상태 저장 개체입니다. 기술적으로이 규칙은 ENI (Elastic Network Interface) 수준에서 적용됩니다. 응답 트래픽은 트래픽이 허용되면 자동으로 허용됩니다. 두 번째 보안 메커니즘은 네트워크 액세스 제어 (NACL)라고합니다. NACL은 서브넷 수준에서 적용되며 서브넷에 배포 된 모든 리소스에 적용되는 상태 비 저장 필터링 규칙입니다. 진입 트래픽이 허용되면 응답은 서브넷에 대한 규칙에서 명시 적으로 허용되지 않는 한 자동으로 허용되지 않기 때문에 무 상태입니다. NACL은 서브넷에 들어가고 나가는 트래픽을 검사하여 서브넷 수준에서 작동합니다. NACL을 사용하여 허용 및 거부 규칙을 설정할 수 있습니다. NACL을 여러 서브넷과 연결할 수 있습니다. 그러나 서브넷은 한 번에 하나의 NACL 만 연결할 수 있습니다. NACL 규칙은 번호가 매겨져 가장 낮은 번호의 규칙부터 순서대로 평가되어 네트워크 ACL과 연결된 서브넷 안팎으로 트래픽이 허용되는지 여부를 결정합니다. 규칙에 사용할 수있는 가장 높은 번호는 32766입니다. 번호가 매겨진 마지막 규칙은 항상 별표이며, 서브넷에 대한 트래픽을 거부합니다. NACL 목록의 규칙이 트래픽과 일치하지 않는 경우에만이 규칙에 도달합니다. Azure VNet은 NSG (Network Security Groups)를 제공하며 AWS SG 및 NACL의 기능을 결합합니다. NSG는 상태 기반이며 서브넷 또는 NIC 수준에서 적용될 수 있습니다. 하나의 NSG 만 NIC에 적용 할 수 있습니다.
• 게이트웨이 - VNet과 VPC 모두 서로 다른 연결 목적을 위해 다른 게이트웨이를 제공합니다. AWS VPC는 ​​NAT 게이트웨이를 추가하는 경우 주로 세 개의 게이트웨이 (네 개)를 사용합니다. AWS를 사용하면 하나의 인터넷 게이트웨이 (IGW)가 IPv4를 통해 인터넷 연결을 제공하고 IPv6 만 사용하는 인터넷 연결을 위해 송신 전용 인터넷 게이트웨이를 제공 할 수 있습니다. AWS에서 IGW가없는 서브넷은 사설 서브넷으로 간주되며 NAT 게이트웨이 또는 NAT 인스턴스가없는 인터넷 연결이 없습니다 (AWS는 고 가용성 및 확장 성을 위해 NAT 게이트웨이를 권장합니다). 또 다른 AWS 게이트웨이 인 VPG (Virtual Private Gateway)를 통해 AWS는 VPN 또는 Direct Connect를 통해 AWS에서 다른 네트워크로 연결을 제공 할 수 있습니다. 비 AWS 네트워크에서 AWS는 AWS VPC에 연결하기 위해 고객 측의 고객 게이트웨이 (CGW)를 요구합니다. Azure VNet은 VPN 게이트웨이와 ExpressRoute 게이트웨이의 두 가지 유형의 게이트웨이를 제공합니다. VPN 게이트웨이는 VNet에서 VNet으로의 암호화 된 트래픽을 VNet 또는 VNet VPN의 경우 공용 연결을 통해 또는 Microsoft의 백본에서 온 - 프레미스 위치로 암호화합니다. 그러나 ExpressRoute 및 VPN 게이트웨이에는 게이트웨이 서브넷이 필요합니다. 게이트웨이 서브넷에는 가상 네트워크 게이트웨이 서비스가 사용하는 IP 주소가 들어 있습니다. Azure VNET to VNET은 VPN을 통해 기본적으로 연결할 수 있지만 AWS에서는 VPC와 VPC가 서로 다른 지역에있는 경우 VPC와 타사 NVA가 필요합니다. 게이트웨이 서브넷에는 가상 네트워크 게이트웨이 서비스가 사용하는 IP 주소가 들어 있습니다. Azure VNET to VNET은 VPN을 통해 기본적으로 연결할 수 있지만 AWS에서는 VPC와 VPC가 서로 다른 지역에있는 경우 VPC와 타사 NVA가 필요합니다. 게이트웨이 서브넷에는 가상 네트워크 게이트웨이 서비스가 사용하는 IP 주소가 들어 있습니다. Azure VNET to VNET은 VPN을 통해 기본적으로 연결할 수 있지만 AWS에서는 VPC와 VPC가 서로 다른 지역에있는 경우 VPC와 타사 NVA가 필요합니다.
• 하이브리드 연결성 - AWS VPC와 Azure VNet은 각각 VPN 및 / 또는 Direct Connect와 ExpressRoute를 사용하여 하이브리드 연결을 허용합니다. Direct Connect 또는 ExpressRoute를 사용하면 최대 10Gbps의 연결을 사용할 수 있습니다. AWS DC 연결은 라우터의 포트와 Amazon 라우터 간의 단일 연결로 구성됩니다. 하나의 DC 연결을 통해 공용 AWS 서비스 (예 : Amazon S3) 또는 Amazon VPC에 가상 인터페이스를 직접 만들 수 있습니다. AWS DC를 사용하기 전에 가상 인터페이스를 만들어야합니다. AWS는 AWS Direct Connect 연결 당 50 개의 가상 인터페이스를 허용하며, AWS에 연락하면이 인터페이스를 확장 할 수 있습니다. 이중화가 필요한 경우 AWS DC 연결은 중복되지 않으며 두 번째 연결이 필요합니다. AWS VPN은 AWS VPC와 사내 구축 형 네트워크간에 두 개의 터널을 생성합니다. Direct Connect에 내결함성을 제공하려면, AWS는 터널 중 하나를 사용하여 VPN 및 BGP를 통해 사내 구축 형 데이터 네트워크에 연결할 것을 권장합니다. Azure ExpressRoute는 또한 연결 용으로 두 개의 링크와 SLA를 제공합니다. Azure는 최소 99.95 % ExpressRoute 전용 회로 가용성을 보장하므로 예측 가능한 네트워크 성능을 보장합니다.

원문: https://devblogs.microsoft.com/premier-developer/differentiating-between-azure-virtual-network-vnet-and-aws-virtual-private-cloud-vpc/

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/