| Drills Down On Cloud Adoption And Amazon’s Culture (0) | 2019.04.30 |
|---|---|
| Running Thousands of KVM Guests on Amazon's new i3.metal Instances (0) | 2019.03.18 |
| Firecracker로 VM을 매우 빠르고 가볍게 띄워보자. (0) | 2018.12.14 |
| 신규 AWS 비용 계산기 AWS Calculator (0) | 2018.10.29 |
| NFS Performance Test with Amazon EFS (0) | 2018.09.15 |
클라우드 컴퓨팅은 소프트웨어 설계 및 데이터 센터의 역할 / 기능에 대해 우리가 알고있는 것을 변화 시켰습니다. 클라우드로의 여행은 클라우드 제공 업체를 선택하고 사설망을 프로비저닝하거나 사내 네트워크를 확장하는 것으로 시작됩니다. 클라우드에서 리소스를 프로비저닝하려는 고객은 다양한 클라우드 공급자가 제공하는 다양한 사설 네트워크 중에서 선택할 수 있습니다. 가장 많이 배치 된 사설망은 가상 네트워크 (VNet) 및 가상 사설 클라우드 (VPC)마이크로 소프트와 아마존으로부터 각각. 이 블로그는 잠재적 인 고객에게 두 개의 사설망을 차별화 할 수있는 정보를 제공하고 작업 부하에 적합한 결정을 내리는 데 도움이되는 두 가지 사설 네트워크 제품의 유사점과 차이점을 살펴 봅니다. 이 시리즈의 첫 번째 블로그에서는 모든 클라우드 네트워크의 기본 구성 요소를 다룰 것입니다. 이 현재 블로그는 복잡성 때문에 가격을 비교하지 않을 것이며 향후 게시물에서 다루어 질 것입니다.
개념적으로 Azure VNet과 AWS VPC는 모두 클라우드에서 자원과 서비스를 프로비저닝하기위한 기반을 제공합니다. 두 네트워크 모두 동일한 빌딩 블록을 제공하지만 구현의 정도에는 차이가 있습니다. 다음은 이러한 빌딩 블록 중 일부에 대한 요약입니다.
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 주소 는 초기 설계 후에 변경할 수 있습니다. 그러나 현재 서브넷의 리소스는 현재 서브넷에서 마이그레이션해야합니다.원문: https://devblogs.microsoft.com/premier-developer/differentiating-between-azure-virtual-network-vnet-and-aws-virtual-private-cloud-vpc/
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!
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
Below is a brief, incomplete summary of virtualization features exploited by the Nitro system—particularly in the bare metal instances.
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.
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.
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)
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.
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.
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.
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:
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 .
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:
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.
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.
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:
Upon reaching 6417 virtual machines, the system was unable to start any new VMs, due to memory exhaustion. However we were able to ssh to running VMs; when we stopped a VM, KVM started a new one. This system appeared to be capable of running indefinitely with this extreme load placed upon the CPU resources.
When fully loaded with virtual machines, CPUs were overloaded 10:1 virtual cycles to physical cycles. There were more than thirty thousand processes running on the system, and it was actively reclaiming memory using KSM (discussed above). Before running the tests, the consensus among our team was that perhaps we could run 2K virtual machines before the system fell apart. This guess (that’s all it was) proved to be overly pessimistic. (However, we did not test I/O capacity in any significant way.)
Beyond proving that we could run a hell of a lot of virtual machines on the i3.metal platform, and that CPU over provisioning was wickedly efficient, we didn’t accomplish much else; for example, we can conclude nothing about the I/O performance of the system. But these are rich grounds for further performance and limit testing using the BCC toolkit, which we hope to discuss in a later blog post.
| AWS Well-Architected (0) | 2019.06.03 |
|---|---|
| Drills Down On Cloud Adoption And Amazon’s Culture (0) | 2019.04.30 |
| Firecracker로 VM을 매우 빠르고 가볍게 띄워보자. (0) | 2018.12.14 |
| 신규 AWS 비용 계산기 AWS Calculator (0) | 2018.10.29 |
| NFS Performance Test with Amazon EFS (0) | 2018.09.15 |
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를 사용하여 서버리스 함수들을 사용 할 수 있습니다. 고객들은 서버리스의 낮은 운영 오버 헤드를 너무 좋아합니다. 우리 또한 서버리스가 향후 컴퓨팅에서 중추적 인 역할을 계속할 것으로 믿습니다.
고객이 서버리스를 점점 더 많이 채택함에 따라 기존의 가상화 기술은 이벤트 중심 또는 짧은 수명의 특성이 있는 이러한 유형의 워크로드의 특성에 최적화되지 않았음을 알게 되었습니다. 우리는 서버리스 컴퓨팅을 위해 특별히 설계된 가상화 기술을 구축 할 필요성을 확인했습니다. 가상 시스템의 하드웨어 가상화 기반 보안 경계를 제공하면서도 컨테이너 크기와 기능의 민첩성을 유지하면서 크기를 유지할 수있는 방법이 필요했습니다.
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:
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.
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 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/kvmDownload 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.sockEach 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.ext4Set 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 tmpTerminate 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 &
doneMultiple microVMs may be configured with a single shared root file system, and each microVM can then be assigned its own read/write share.
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.
| Drills Down On Cloud Adoption And Amazon’s Culture (0) | 2019.04.30 |
|---|---|
| Running Thousands of KVM Guests on Amazon's new i3.metal Instances (0) | 2019.03.18 |
| 신규 AWS 비용 계산기 AWS Calculator (0) | 2018.10.29 |
| NFS Performance Test with Amazon EFS (0) | 2018.09.15 |
| 어떻게 메인프레임을 AWS 클라우드로 이전하나요? (0) | 2018.09.10 |
AWS 비용 계산기가 새로 나왔습니다.
UI도 깔끔해졌고, 여러 리전을 그룹으로 지정해서 같이 계산도 가능합니다.
Edit Group으로 원하는 리전을 먼저 그룹으로 만들고 시작하세요.
| Running Thousands of KVM Guests on Amazon's new i3.metal Instances (0) | 2019.03.18 |
|---|---|
| Firecracker로 VM을 매우 빠르고 가볍게 띄워보자. (0) | 2018.12.14 |
| NFS Performance Test with Amazon EFS (0) | 2018.09.15 |
| 어떻게 메인프레임을 AWS 클라우드로 이전하나요? (0) | 2018.09.10 |
| Amazon Aurora – MySQL에서 DB 부하에 대한 최적화 방법 (0) | 2018.08.30 |
아마존의 14가지 리더십 원칙 (The amazon way, 14 leadership principle)
여기에서 리더는 당신이다. 즉, Self Leadership을 말하고 있는 것이다.
리더는 고객에서부터 시작하며 나머지는 그 다음이다. 리더는 고객의 신뢰를 얻고 유지하기 위해 끊임없이 노력하며, 경쟁사들에게 관심을 갖기는 해도 집착하는 대상은 어디까지나 고객들이다.
리더는 고객의 관점에서 생각하고 행동해야 한다. 고객에게 신뢰를 얻고 유지하기 위해 전력을 다해야 한다. 리더는 경쟁사에 신경을 써야 하지만, 무엇보다 고객을 중심으로 생각하는 데 집착해야 한다. 아마존의 미션과 비전인 고객 중심주의와 일맥상통하는 표현이기 때문에 가장 중요한 항목이다.
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.
리더은 곧 주인이다. 그들은 장기적인 관점에서 생각하고, 단기적 성과를 위해 장기적 가치를 희생시키지 않는다. 또한 자신의 팀을 넘어서 회사 전체를 대표한다는 생각으로 행동한다. 리더들은 “그것은 내 일이 아니야."라고 절대 말하지 않는다.
리더에게는 주인의식이 필요하다. 리더는 장기적인 시야로 생각해야 하며, 단기적인 결과를 위해 장기적인 가치를 희생해서는 안 된다. 리더는 자신의 팀뿐만 아니라 회사 전체를 위해 행동해야 한다. 리더 입에서 “그건 내 업무가 아니다”라는 말이 절대로 나와서는 안 된다.
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".
리더는 그들의 팀에 혁신(innovation)과 창의(invention)을 요구하고 또한 기대하며, 항상 단순화 시킬 방법을 찾는다. 리더는 외부의 상황의 변화에 주의하고 모든 곳에서 새로운 아이디어를 얻는다. "우리가 개발한 것이 아니다(NIH 신드룸)"라는 것에 얽매지 않는다. 우리는 새로운 아이디어를 실행에 옮길 때, 오랜 시간 동안 오해를 받을 준비도 되어 있다.
리더는 팀에 혁신과 창조를 요구해야 하며, 늘 심플한 방법이 없는지를 모색해야 한다. 상황의 변화를 예의주시하고, 모든 곳에서 새로운 아이디어를 찾아내야 한다. 본인들이 만들어낸 것에 국한된 이야기가 아니다. 리더는 새로운 아이디어를 실행하는 데 있어 오랜 기간에 걸쳐 외부에 오해를 살 수 있는 일이더라도 그것을 받아들여야 한다
리더는 그들의 팀이 발명(invention)하고 혁신(innovation)하기를 기대하고 요구하며, 단순화시킬 방법을 찾는 노력을 잠시도 멈추지 않는다. 또한 리더는 조직 외부의 상황에도 아주 밝아 모든 곳으로부터 새로운 아이디어를 얻는다. 뿐만 아니라 사고방식에 구애를 받지 않는다. 오히려 리더들은 오랜 시간 동안 오해 받을 상황을 무릅쓰고 두려움 없이 혁신에 뛰어든다.
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.
항상 옳지는 않아도, 대부분 옳다. 리더들은 뛰어난 사업적 판단력을 보유하고, 자신의 목표는 물론이고 성공을 측정하는데 사용되는 지표들을 더없이 명확히 밝힘으로써 다른 사람들에게 자신의 뛰어난 판단력을 전파한다.
리더는 모든 상황에 올바르게 판단해야 한다. 강력한 판단력과 더불어 경험에 기반을 둔 직감을 갖추어야 한다. 다양한 사고방식을 추구하고, 자신의 생각을 반증하는 데 거리낌이 없어야 한다.
리더는 대부분 올바른 판단을 한다. 그들은 좋은 본능적 감각으로 훌륭한 판단을 한다. 그들은 다양한 관점을 추구하며, 그들의 신념에 대해 반증하는 것도 마다하지 않습니다.
Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.
리더에게 배움의 끝이란 없으며 리더는 항상 스스로를 발전시킬 방법을 찾아야 한다. 리더는 새로운 가능성에 강렬한 호기심을 갖고 가능성을 탐구하기 위해 행동한다.
리더는 끊임없이 배우고 자기 자신을 향상해야 한다. 새로운 가능성에 호기심을 갖고 실제로 그것을 행동으로 옮겨야 한다.
Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.
리더는 모든 채용과 승진에 있어 성과 기준을 높인다. 리더는 특별한 인재를 알아보는 눈이 있고 조직 전반에 그들을 능동적으로 배치한다. 또한 리더는 미래의 리더들을 육성할 뿐 아니라, 다른 사람들을 올바른 방향으로 이끄는 코치로서의 역할에 최선을 다한다.
리더는 모든 채용과 승진에 참고가 되는 성과의 기준을 끌어올려야 한다. 뛰어난 재능을 가진 인재를 발굴해서, 조직 전체를 위해 능동적으로 활용해야 한다. 리더는 다른 리더를 육성하고 지도하는 데 진지하게 노력해야 하며 모든 구성원을 위해 새로운 성장 매커니즘을 창출해야 한다.
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.
리더는 많은 사람들이 터무니없이 높다고 생각할 만큼 높은 기준을 세운다. 하지만 여기서 그치지 않고, 그들은 기준을 끊임없이 끌어올리고 자신의 팀이 제품과 서비스 그리고 프로세스의 품질 수준을 지속적으로 향상시키도록 이끈다. 뿐만 아니라 리더는 조직이 높은 기준을 유지할 수 있도록, 아무리 적은 숫자라도 품질 관리 프로세스에서 걸러지지 않은 불량품이 생산되지 않도록 최선을 다하며 문제들을 해결한다.
리더는 남들이 터무니없다고 생각할 정도로 높은 수준을 추구해야 한다. 끊임없이 본인이 추구하는 수준을 끌어올려야 하고, 팀이 더욱 품질 높은 제품과 서비스, 프로세스를 실현할 수 있도록 촉구해야 한다. 리더는 결함 있는 제품을 다음 공정으로 내보내서는 안 되며, 문제를 확실히 해결하여 같은 문제가 재차 발생하지 않도록 개선책을 마련해야 한다.
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.
협소한 관점으로 생각하는 것은 자기 충족적 예언이다. 아마존의 리더는 구체적인 결과를 만들어내는 대담한 목표점을 제시하고, 그 목표점을 널리 알리며 팀을 그 방향으로 이끈다. 그들은 다르게 생각하고, 고객을 섬기기 위한 최선의 방법을 찾아서 구석구석 살피고 또 살핀다.
좁은 시야로 생각하면 커다란 결과를 얻을 수 없다. 리더는 대담한 방침과 방향성을 마련하고 제시함으로써 성과를 끌어내야 한다. 고객에게 이바지하기 위해 기존과 다른 새로운 관점에서 모든 가능성을 모색해야 한다.
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.
리더는 계산된 위험 감수를 가치 있게 생각한다. 비즈니스에서는 속도가 생명이다. 많은 결정과 행동은 되돌릴 수 있고, 광범위한 연구가 꼭 필요하지도 않다. 고로 확신이 없을 때는 우선 시도하라. 자신의 분야에서 첫번째 사람이 됨으로써 얻을 수 있는 기회를 최대한 활용하라.
비즈니스는 속도가 생명이다. 대부분의 의사결정과 행동은 나중에 바로잡을 수 있으므로 거창한 분석과 검토는 불필요하다. 리더는 예측 가능한 위험을 감수하는 것도 중요하다.
행동을 위한 편중
Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.
리더는 고객들에게 중요한 영향을 주지 않는 일에는 돈을 쓰려고 하지 않는다. 근검절약은 독창성을 드높이고, 자급자족 능력을 키우며 발명을 낳는다. 머릿수를 늘리고 예산을 올린다고 가산점이 주어지지는 않는다.
리더는 더 적은 자원으로 더 많은 것을 실현해야 한다. 절약 정신은 창의적 아이디어, 자립심, 발명을 만들어내는 원천이다. 직원 수, 예산, 고정비는 많다고 좋은 것이 아니다.
Accomplish more with less. Constraints breed resourcefulness, self-sufficiency and invention. There are no extra points for growing headcount, budget size or fixed expense.
리더는 진실로 열린 마음을 갖고, 진심을 다해 경청하며, 겸손의 마음으로 자신의 가장 큰 신념을 시험한다. 그들은 솔직하고, 그래서 주변 사람들을 신뢰할뿐 아니라 주변 사람들의 신뢰를 얻을 수 있다.
리더는 주의 깊게 듣고, 솔직하게 말하며, 구성원을 존경심으로 대해야 한다. 잘못이 있다면 내키지 않더라도 솔직하게 인정해야 하며, 자신과 팀의 잘못을 그냥 넘어가서는 안 된다. 항상 자신과 팀을 최고 수준에서 비교 평가해야 한다.
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.
리더는 모든 수준의 업무에 관여하고 매순간 세부사항을 파악하고 있을뿐 아니라 세부사항을 자주 점검한다. 그들에게 중요하지 않은 업무란 없다. 특정 프로세스의 가장 기본적인 사항까지 깊이 파고들어야만, 기회를 포착할 수 있고 문제가 손 쓸 수 없을 만큼 악화되기 전에 미리 해결할 수 있음을 알기 떄문이다.
리더는 모든 수준의 업무에 관여하고, 항상 세부 내용을 파악해 현황을 수시로 감시하며, 지표와 개별 사례가 일치하지 않는다면 의문을 제기해야 한다. 모든 업무에 가치가 있다고 여기고 관심을 기울여야 한다.
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.
리더에게는 굳은 신념과 확신이 있다. 어떤 결정에 반대할 때는 비록 불편하고 지치는 한이 있더라도 결정에 대해 정중하게 이의를 제기할 의무가 있다. 아마존의 리더는 결정을 할 때 집단 내부의 단결을 위해 타협하지 않는다. 그러나 논의 끝에 결정이 확정되고 나면 그 결정에 온전히 전념한다.
리더는 찬성할 수 없는 사안에는 정중하게 이의를 제기해야 한다. 번거롭고 피곤하겠지만 예외는 있을 수 없다. 리더는 신념을 가져야 하며 금방 포기해서는 안 된다. 쉽게 타협해 한통속이 되어서는 안 된다. 다만 논의 끝에 일단 결정이 내려졌다면 결정에 전념하고 몰두해야 한다.
자신의 신념에 대한 명확한 기준을 가지고 그에 대한 기개를 가져야 한다. 이를 위해 주장해야 하고 타협하지 않아야 한다. 하지만 어떤 방향이든 결정이 되면 그에 따라 전념한다.
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.
리더는 자신의 업무에서 핵심적인 산출물에 초점을 맞추고 적절한 시기에 적절한 품질의 결과물을 낸다. 리더는 어려움이 닥쳐도 잘 대처하고 절대 안주하지 않는다.
리더는 비즈니스상의 핵심 투입에 초점을 맞추고, 이를 신속하게 실행해 결과를 내야 한다. 설령 어려운 일이 생기더라도 당당하게 맞서야 하며 결코 타협해서는 안 된다.
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
| Amazon Aurora – MySQL에서 DB 부하에 대한 최적화 방법 (0) | 2018.08.30 |
|---|---|
| AWS CDK 개발자 미리보기 (0) | 2018.08.29 |
| Amazon EC2 인스턴스 내부 네트워크 대역폭 상향 (0) | 2018.02.08 |
| AWS 베어메탈 출시 (0) | 2017.11.29 |
| Amazon Polly 서울 리전 출시 및 한국어 여성 ‘서연(Seoyeon)’ 음성 지원 (0) | 2017.11.29 |
https://aws.amazon.com/ko/blogs/korea/the-floodgates-are-open-increased-network-bandwidth-for-ec2-instances/
요약:
| AWS CDK 개발자 미리보기 (0) | 2018.08.29 |
|---|---|
| 아마존의 14가지 리더십 원칙 (0) | 2018.08.12 |
| AWS 베어메탈 출시 (0) | 2017.11.29 |
| Amazon Polly 서울 리전 출시 및 한국어 여성 ‘서연(Seoyeon)’ 음성 지원 (0) | 2017.11.29 |
| AWS OpsWorks for Puppet Enterprise (0) | 2017.11.29 |
AWS는 re:Invent 때 항상 깜짝 놀랄만한 서비스를 출시합니다.
아무도 예상 못해선... 설마했던... 그것을 아마존이 또 출시했네요.. 바로 VM이 아닌 물리서버인 베어메탈 서비스 입니다.
사실 VMware on AWS를 출시할 때 부터 가능성이 점쳐졌던 거긴 한데요...
설마 진짜 베어메탈 서비스를 출시 할지 몰랐네요. 사용자 입장에서의 사용성은 베어메탈도 VM과 동일 합니다.
서버의 순수한 성능을 다 확보 할수 있고, 라이센스 정책에서 좀 더 자유로울 수 있겠네요.
Softlayer(IBM Cloud)가 거의 베어메탈의 표준 처럼 잡고 있는 클라우드였는데요.... 이제 긴장해야겠습니다.
아직 AWS가 프리뷰이긴하지만 언제 훅 치고 들어올지 모르니까요.
출처: https://aws.amazon.com/ko/blogs/aws/new-amazon-ec2-bare-metal-instances-with-direct-access-to-hardware/
When customers come to us with new and unique requirements for AWS, we listen closely, ask lots of questions, and do our best to understand and address their needs. When we do this, we make the resulting service or feature generally available; we do not build one-offs or “snowflakes” for individual customers. That model is messy and hard to scale and is not the way we work.
Instead, every AWS customer has access to whatever it is that we build, and everyone benefits. VMware Cloud on AWS is a good example of this strategy in action. They told us that they wanted to run their virtualization stack directly on the hardware, within the AWS Cloud, giving their customers access to the elasticity, security, and reliability (not to mention the broad array of services) that AWS offers.
We knew that other customers also had interesting use cases for bare metal hardware and didn’t want to take the performance hit of nested virtualization. They wanted access to the physical resources for applications that take advantage of low-level hardware features such as performance counters and Intel® VT that are not always available or fully supported in virtualized environments, and also for applications intended to run directly on the hardware or licensed and supported for use in non-virtualized environments.
Our multi-year effort to move networking, storage, and other EC2 features out of our virtualization platform and into dedicated hardware was already well underway and provided the perfect foundation for a possible solution. This work, as I described in Now Available – Compute-Intensive C5 Instances for Amazon EC2, includes a set of dedicated hardware accelerators.
Now that we have provided VMware with the bare metal access that they requested, we are doing the same for all AWS customers. I’m really looking forward to seeing what you can do with them!
New Bare Metal Instances
Today we are launching a public preview the i3.metal instance, the first in a series of EC2 instances that offer the best of both worlds, allowing the operating system to run directly on the underlying hardware while still providing access to all of the benefits of the cloud. The instance gives you direct access to the processor and other hardware, and has the following specifications:
Bare Metal instances are full-fledged members of the EC2 family and can take advantage of Elastic Load Balancing, Auto Scaling, Amazon CloudWatch, Auto Recovery, and so forth. They can also access the full suite of AWS database, IoT, mobile, analytics, artificial intelligence, and security services.
Previewing Now
We are launching a public preview of the Bare Metal instances today; please sign up now if you want to try them out.
You can now bring your specialized applications or your own stack of virtualized components to AWS and run them on Bare Metal instances. If you are using or thinking about using containers, these instances make a great host for CoreOS.
An AMI that works on one of the new C5 instances should also work on an I3 Bare Metal Instance. It must have the ENA and NVMe drivers, and must be tagged for ENA.
— Jeff;
| 아마존의 14가지 리더십 원칙 (0) | 2018.08.12 |
|---|---|
| Amazon EC2 인스턴스 내부 네트워크 대역폭 상향 (0) | 2018.02.08 |
| Amazon Polly 서울 리전 출시 및 한국어 여성 ‘서연(Seoyeon)’ 음성 지원 (0) | 2017.11.29 |
| AWS OpsWorks for Puppet Enterprise (0) | 2017.11.29 |
| Amazon Redshift Spectrum 한국리전 출시 (0) | 2017.11.29 |
Polly 가 드디어 한국어를 합니다. 기계합성어 답지않게 정말 자연스럽습니다. 이제 음성합성은 구글보다 Polly를 이용할것 같습니다.
더 자연스럽고, 더 쉽게 쓸 수 있습니다. 아래 링크로 한번 들어 보시죠.
출처: https://aws.amazon.com/ko/blogs/korea/now-available-amazon-polly-in-seoul-region-and-korean-woman-voice-seoyeon
Amazon Polly는 고급 딥 러닝 기술을 사용하여 실제 사람 목소리처럼 음성을 합성하는 텍스트 음성 변환 서비스입니다. 텍스트를 다양한 언어로 수십 개의 생생한 음성이 제공되므로 여러 국가에서 적합한 음성을 선택하여 음성 지원 애플리케이션을 개발할 수 있습니다.
오늘부터 Amazon Polly를 서울 리전에서 사용 가능합니다. 또한, 한국어 여성 ‘서연(Seoyeon)’음성을 공개합니다.
Amazon Polly의 종량 요금제, 변환 문자당 저렴한 비용, 무제한 재생은 거의 모든 애플리케이션에서 음성 합성을 구현하는 비용 효과적인 방법을 제공합니다. 이전에 재생된 오디오를 재생할 때마다 로열티를 요구하거나 요금을 부과하는 다른 솔루션과 달리, Amazon Polly는 추가 요금 없이 무제한 재생을 허용합니다. 이러한 무료 재생은 오프라인 사용까지 확대됩니다. MP3 및 OGG와 같은 다양한 표준 형식으로 음성 파일을 생성하여 오프라인 재생 전용으로 휴대폰 또는 사물 인터넷(IoT) 디바이스와 같은 디바이스에 저장할 수 있습니다.
실제 같은 음성과 대화 사용자 경험을 제공하기 위해서는 일관되게 빠른 응답 시간이 요구됩니다. Amazon Polly API로 긴 텍스트를 전송하더라도 Amazon Polly API가 오디오를 스트림으로 애플리케이션으로 반환하므로 즉시 음성을 재생할 수 있습니다.
아래 샘플 코드에 대한 음성 파일을 확인해 보실 수 있습니다.
from boto3 import client
polly = client("polly", region_name="ap-northeast-2")
response = polly.synthesize_speech(
Text="안녕하세요. 제 이름은 서연이에요! 저는 새내기 아마존 폴리 음성 비서입니다. 텍스트를 입력하시면 읽어드릴께요.",
OutputFormat="mp3",
VoiceId="Seoyeon")
특히, 음성 합성 애플리케이션을 위한 Speech Synthesis Markup Language(SSML), W3C 표준, XML 기반 마크업 언어를 지원하고 표현, 강조 및 억양을 위한 일반 SSML 태그를 지원합니다. 이러한 유연성은 청중의 관심을 끌 수 있는 생생한 음성을 생성하는 데 도움이 됩니다.
아래 샘플 코드에 대한 음성 파일을 확인해 보실 수 있습니다.
<speak>
오늘의 <prosody rate="x-slow">날씨를 전해 드리겠습니다</prosody>.
현재, 전국이 구름이 많은 가운데 일부 중부 지역과 전북에는 <prosody volume="x-loud">눈이 날리거나</prosody><break time="1s"/> <prosody pitch="x-high">빗방울이 떨어지는 곳이 있습니다.
</prosody>. 서울의 경우 북부 지역을 중심으로 <amazon:effect name="whispered"><prosody rate="-10%">눈이 날리고 있으나,</prosody></amazon:effect> 공식적인 첫눈으로 기록되지는 않습니다.
</speak>
자세한 내용은 SSML 태그에 대한 Amazon Polly 설명서를 참조하십시오.
Amazon Polly는 월 5백만자 까지 무료로 제공됩니다. 그 이상의 경우, 한 자당 $0.000004 per 또는 제작된 오디오 분당 $0.004로 과금 됩니다. 일반적인 한국어 뉴스 기사 (2,500자)의 경우, $0.01 (11원) 정도로 매우 저렴합니다. 예를 들어, 영어로 된 Adventures of Huckleberry Finn이라는 책 원문 전체는 약$2.4 정도 됩니다. 더 자세한 것은 Polly 요금 정보를 참고하세요.
이제 Amazon Polly를 통해 뉴스 및 전자책 리더, 게임, 전자 학습 플랫폼, 시각 장애가 있는 사람을 위한 접근성 애플리케이션, 빠르게 성장하는 사물 인터넷(IoT) 세그먼트 등과 같은 모바일 애플리케이션이 등 다양한 한국어 지원에 활용하실 수 있습니다. Amazon Polly에 대한 더 자세한 사항은 제품 페이지나 기술 문서를 참고하시기 바랍니다.
| Amazon EC2 인스턴스 내부 네트워크 대역폭 상향 (0) | 2018.02.08 |
|---|---|
| AWS 베어메탈 출시 (0) | 2017.11.29 |
| AWS OpsWorks for Puppet Enterprise (0) | 2017.11.29 |
| Amazon Redshift Spectrum 한국리전 출시 (0) | 2017.11.29 |
| AWS, 새 하이퍼바이저로 ‘젠’ 대신 ‘KVM’ 채택 (0) | 2017.11.20 |
Amazon Redshift Spectrum은 Athena만큼 기대되는 제품이 였는데 드디어 서울리전에도 사용이 가능해졌습니다.
Athena가 EMR을 공유인프라를 활용한 SaaS 형으로 제공서비스라면
Redshift Spectrum은 이름처럼 Redshift를 공유인프라를 통해 SaaS형으로 제공하는 서비스입니다. 구글 빅쿼리랑 대응 되겠네요.
둘다 S3 데이터를 직접 다룰 수 있습니다.
세부 내용은 아래 AWS 블로그 내용 참고 하시 면 되겠습니다.
출처: https://aws.amazon.com/ko/blogs/korea/10-best-practices-for-amazon-redshift-spectrum/
Amazon Redshift Spectrum 을 사용하면 Amazon S3에 저장된 데이터에 대해 Amazon Redshif SQL 쿼리를 실행할 수 있습니다. 즉, Amazon Redshift의 분석 기능을 데이터웨어 하우스(DW) 내 로컬 디스크에 저장된 데이터 이상으로 확장 할 수 있습니다. 시간이 많이 걸리는 추출, 전송 및 로드 (ETL) 프로세스를 거치지 않고 Amazon S3내의 “데이터 레이크(Data Lake)”에서 방대한 양의 데이터를 바로 쿼리 할 수 있으며, 정교한 쿼리 최적화를 적용하고 수천 노드의 프로세싱을 확장하여 빠른 성능을 제공합니다.이 글에서는 Amazon Redshift Spectrum에 대한 중요한 모범 사례를 몇 가지 분류를 통해 알려 드리고자 하며, 주로 Amazon Redshift 고객과의 많은 대화와 직접 진행한 프로젝트에서 나온 것들입니다.
Amazon Athena와 Amazon Redshift Spectrum를 언제 사용하는지 궁금해 하는 고객들이 있습니다.
Amazon Athena는 SQL을 사용하여 Amazon S3에 저장된 데이터에 대해 대화 형 애드훅(Ad-hoc) 쿼리를 실행하는 경우에 유용합니다. Amazon Athena의 서버리스 아키텍처는 쿼리를 수행하기 위해 클러스터를 미리 프로비저닝하지 않아도 됩니다. 각 쿼리에서 스캔 한 S3 데이터의 양에 따라 요금이 부과됩니다. 데이터를 압축, 분할 또는 컬럼 형식으로 변환하여 비용을 크게 절감하고 성능을 향상시킬 수 있으므로 Amazon Athena가 쿼리를 실행하기 위해 스캔해야 하는 데이터 양이 줄어 듭니다. JDBC를 사용하는 모든 주요 BI 도구 및 SQL 클라이언트는 Amazon Athena에서 사용할 수 있습니다. 쉬운 시각화를 위해 Amazon QuickSight를 사용할 수도 있습니다.
만약, 대용량의 구조화 된 데이터 집합에 대해서는 Amazon Redshift를 사용하는 것이 좋습니다. Redshift Spectrum은 원하는 형식으로 원하는 위치에 자유롭게 데이터를 저장할 수 있게 해주며, 필요시 언제든지 처리 할 수 있으며, 클러스터 확장에 대해 걱정할 필요가 없습니다. 이를 통해 스토리지를 분리하고 계산할 수 있으므로 각 스토리지를 독립적으로 확장 할 수 있습니다. 동일한 Amazon S3 데이터 레이크에 대해 여러 개의 Amazon Redshift 클러스터를 실행하여 대량으로 동시성을 구현할 수도 있습니다. 즉, 자동으로 수천 개의 인스턴스로 확장되기 때문에, 쿼리가 테라 바이트, 페타 바이트 또는 엑사 바이트를 처리하든 상관없이 신속하게 실행됩니다. 이를 염두하시고 판단하시면 됩니다.
Amazon Redshift Spectrum을 시작하기 위한 전제 조건 및 단계에 대한 정보는 Redshift Spectrum 시작하기 문서를 참조하십시오.
모든 데이터 세트를 사용하여 테스트를 수행하여, 이 글에서 설명한 모범 사례를 검증 할 수 있습니다. 한 가지 중요한 요구 사항은 가장 큰 테이블의 S3 파일이 CSV 형식, 분할 Parquet, 비분할 Parquet 형식 등 세 가지 데이터 형식이어야 합니다. 한 파일 형식에서 다른 파일 형식으로 변환하는 방법은 아래 방법을 참고하시기 바랍니다.
외부 스키마 만들기
Amazon Athena 데이터 카탈로그를 메타 데이터 저장소로 사용하고, 다음과 같이 “spectrum”이라는 외부 스키마를 만듭니다.
Redshift 클러스터와 Amazon S3의 데이터 파일은 동일한 AWS 리전에 있어야합니다. Redshift 클러스터에는 Amazon Athena의 외부 데이터 카탈로그 및 Amazon S3의 데이터 파일에 액세스 할 수 있는 권한이 필요합니다. 클러스터에 연결된 AWS Identity and Access Management (IAM) 역할 (예 : aod-redshift-role)을 참조하여 해당 권한을 제공합니다. 자세한 내용은 Amazon Redshift 용 IAM 역할 만들기를 참조하십시오.
외부 테이블 정의
Partwise Parquet 파일을 사용하는 Amazon Redshift Spectrum 외부 테이블과 CSV 파일을 사용하는 다른 외부 테이블은 다음과 같이 정의됩니다.
데이터 쿼리
요약하면, Amazon Redshift Spectrum은 외부 테이블을 사용하여 Amazon S3에 저장된 데이터를 쿼리합니다. 다른 Amazon Redshift 테이블과 동일한 SELECT 구문을 사용하여 외부 테이블을 쿼리 할 수 있습니다. 다만, 읽기 전용이므로 외부 테이블에 쓸 수 없습니다.
먼저 외부 데이터베이스를 참조하는 외부 스키마를 작성합니다. 외부 스키마는 Amazon Athena 데이터 카탈로그 또는 Amazon EMR과 같은 Apache Hive 메타 스토어에 있을 수 있습니다. 그런 다음 외부 스키마를 사용하여 Amazon Redshift에서 외부 테이블을 생성합니다. 테이블을 생성하고 Amazon Redshift로 읽어 올 필요 없이 테이블 이름 앞에 스키마 이름을 붙임으로써 SELECT 문에서 외부 테이블을 참조하면 됩니다.
외부 스키마는 외부 데이터 카탈로그의 데이터베이스를 참조합니다. 이를 위해서는 클러스터를 대신하여 Amazon S3 및 Amazon Athena에 액세스 할 수 있는 권한을 부여하는 IAM 역할이 필요합니다.
Amazon Redshift Spectrum을 사용하여 테스트를 수행하려면, 다음 두 가지 쿼리를 시작하는 것이 좋습니다.
QUERY 1:
이 쿼리에는 하나의 테이블 만 포함되며 Amazon Redshift Spectrum 레이어에서 제공하는 추가 처리 성능을 강조 표시하는 데 사용할 수 있습니다.
QUERY 2:
이 쿼리에는 3 개의 테이블이 결합되어 Amazon Redshift Spectrum의 성능과 기본 Amazon Redshift의 성능을 비교하는 데 매우 유용합니다.
아래 모범 사례는 Amazon Redshift Spectrum을 사용하여 동시 작업 부하 성능을 최적화하는 데 도움이됩니다.
1. 스캔 집약적인 동시 작업 부하 향상
Amazon Redshift Spectrum은 클러스터와 독립적 인 전용 Amazon Redshift 서버에 있습니다. 조건부 필터링 및 집계와 같은 많은 컴퓨팅 집약적인 작업을 Redshift Spectrum에서 처리하기 때문에, 쿼리를 위한 클러스터 처리 용량을 훨씬 적게 사용합니다. 또한 Amazon Redshift Spectrum은 지능적으로 확장되기 때문에 쿼리 요구를 기반으로 잠재적으로 수천 개의 인스턴스를 사용하여 대규모 병렬 처리 (MPP)를 활용할 수 있습니다. 동시 스캔 및 / 또는 집약적 인 작업 부하의 일부 사용 사례의 경우 Amazon Redshift Spectrum이 평균 Amazon Redshift보다 우수한 성능을 보입니다.
모든 MPP 시스템에서 가장 자원이 많이 드는 과정이 바로 데이터 로딩 프로세스입니다. 이는 컴퓨팅 뿐 아니라 MVCC (Multiversion Concurrency Control)를 통해 테이블을 잠그는 것과 같은 능동적인 분석 쿼리와 경쟁하기 때문입니다. 그러나, Amazon Redshift Spectrum을 사용하여 Amazon S3에 작성한 새 외부 파일에 파일을 추가 한 다음 메타 데이터를 새 파티션으로 포함하도록 업데이트하면 Amazon Redshift 클러스터에서 이러한 부하가 제거됩니다. 이것은 동시성에 즉각적이고 직접적인 긍정적 영향을 주게 됩니다.
2. 다수 Redshift 온 디멘드 클러스터를 통한 동시성 확장
Redshift Spectrum은 Amazon S3에 데이터를 저장합니다. Amazon S3에 여러 Amazon Redshift 클러스터에서 접근하여 동시 작업 로드 성능을 향상 시킵니다. 일반적인 Redshift 고객은 업무 패턴과 관련 없이 많은 동시적 쿼리 작업 부하를 가지게 되는데, Redshift Spectrum 이 나오기 전에는 동시성을 처리하기 위해 스냅샷을 복원하여 여러 개의 “읽기 전용” 클러스터를 만들어 두어야 했습니다. 이 접근법의 문제점은 수 테라 바이트의 데이터가 있는 DW의 경우 복원 프로세스가 오래 걸릴 수 있어 데이터 대기 시간 문제가 발생한다는 것입니다.
Amazon Redshift Spectrum을 사용하면 가장 큰 테이블을 Amazon S3로 옮길 수 있으며, 각 Amazon Redshift 클러스터는 로컬 디스크에 적은 양의 데이터만 보관합니다. 데이터 양이 줄어들기 때문에 까다로운 쿼리 작업 부하를 처리하기 위한 “읽기 전용” 클러스터를 생성 및 복원하는 것이 훨씬 빠릅니다 (그림 1 참조). 비용을 줄이려면 이러한 “온-디멘드” 클러스터를 작업후 바로 종료하면 됩니다.
그림 1: 다중 읽기 전용 Amazon Redshift 클러스터에서 Redshift Spectrum 공유하기
Amazon Redshift 고객은 pgbouncer-rr을 사용하여, 여러 Redshift 클러스터를 배포 할 때 클라이언트 쿼리 라우팅을 단순화하고 제어하여 동시성을 확장할 수 있습니다. 자세한 내용은 Amazon Redshift 및 PostgreSQL을위한 pgbouncer-rr 소개 : Query Routing and Rewrite (영문)를 참조하십시오.
스토리지 최적화 고려 사항에서는 모든 단계에서 I/O 워크로드를 줄이는 것이 좋습니다. 이는 각 스토리지 블록에 더 많은 레코드를 맞추기 위해 압축을 사용하고 데이터 파티셔닝을 지원하는 형식을 사용하여 컬럼 기반 파일 형식을 사용해야 합니다. Amazon Redshift Spectrum에서 지원되는 파일 형식으로는 CSV, TSV, Parquet, Sequence 및 RCFile이 있습니다.
추가적인 최적화 방법은 압축을 사용하는 것입니다. 현재 Amazon Redshift Spectrum은 Gzip, Snappy 및 BZ2를 지원합니다.
3. 성능 향상과 비용 절감을 위해 Apache Parquet 파일 사용
Apache Parquet은 데이터 처리 프레임 워크, 데이터 모델 또는 프로그래밍 언어의 선택 여부와 상관없이 Apache Hadoop의 모든 프로젝트에서 사용할 수 있는 컬럼 형식 저장소 형식입니다. 자세한 내용은 Apache Parquet 정보 페이지를 참조하십시오.
Redshift Spectrum은 S3에서 쿼리에 필요한 파일의 컬럼(Column)만을 읽으며, 쿼리 당 S3에서 스캔되는 데이터의 양에 따라 요금을 부과합니다. 따라서, Parquet 형식의 데이터는 컬럼 형식으로만 저장하므로, 스캔 중에 불필요한 데이터를 제거 할 수 있습니다. 예를 들어, CSV 텍스트 파일과 Parquet 파티션 파일 간의 쿼리 성능 차이를 비교하면 바로 알 수 있습니다. 여러 가지 테스트 결과에 따르면 파티션 된 Parquet 파일은 성능이 빠르고 비용 효율적입니다.
SVL_S3QUERY_SUMMARY를 사용하면 분할 된 Parquet 파일을 사용하는 쿼리에 대한 흥미로운 S3 측정값에 대한 통찰력을 얻을 수 있습니다.
s3_scanned_rows 및 s3query_returned_rows 등 두 가지 측정 항목에 주의하십시오. CSV 파일과 비교할 때 최종 처리를 위해 Redshift Spectrum에서 Redshift 네이티브로 반환 되는 데이터의 양이 엄청나게 줄어들 것입니다.
4. 자주 사용하는 칼럼에 대한 Parquet 파일 분할
최적의 파티션 칼럼을 정할 때는 아래 사항을 고려하시기 바랍니다.
파티션 정리 (partition pruning)의 이점을 살펴보려면, Parquet 형식을 사용하여 두 개의 외부 테이블을 작성하는 것을 고려해야 합니다. 하나의 테이블은 파티션하지 않고, 다른 파티션은 일별로 분할합니다.
파티션한 테이블 스캔은 파티션 하지 않은 테이블보다 2~4 배 빠릅니다.
“파티션 정리”가 유효한 지 알아보려면, SQL을 사용하여 파티션 정리의 효율성을 분석 할 수 있습니다. 쿼리가 몇 개의 파티션에만 적용하여, 실제 예상대로 작동하는지 확인할 수 있습니다.
5. 올바른 클러스터 구성으로 Redshift Spectrum 성능 최적화
Amazon Redshift Spectrum 쿼리에는 두 가지의 Amazon S3 요청 병렬 처리 방식이 있습니다.
노드 수준 (노드에서 실행되는 모든 S3 쿼리, 노드 유형에 따라 상이함)노드 인스턴스 타입에 따라 상이함
간단한 계산 방법은 다음과 같습니다. “총 파일 수 <= 쿼리당 병렬 처리 수 (예 : 10) * 총 슬라이스 수” 일 때, 더 많은 노드를 가진 클러스터를 만들어도 성능이 향상되지 않을 수 있습니다. 좋은 방법은 Amazon Redshift Spectrum 테이블에 있는 파일 수를 확인하는 것입니다. 그리고, 특정 클러스터 크기 (슬라이스 관점에서)까지 추세를 측정하여 클러스터 노드 수가 증가하는 경우에도 성능이 더 이상 올라가지 않을 때를 확인합니다. Amazon Redshift 클러스터의 최적의 크기 (주어진 노드 유형에 대한)는 더 이상의 성능 향상을 얻을 수 없는 지점입니다.
몇 가지 간단한 기술을 사용하여 Amazon S3에서의 쿼리 성능을 향상시킬 수 있습니다.
6. 신속하게 스캔 및 집계가 필요한 쿼리에 주로 활용하기
Query 1과 같은 조인(Join)이 없는 특정 쿼리에서 성능은 일반적으로 검색 속도와 같은 물리적 I/O 비용에 의해 좌우됩니다. 이러한 쿼리의 경우, Redshift Spectrum이 Redshift보다 빠를 수 있습니다. 반면에 쿼리 2와 같이 여러 테이블 조인이 포함될 경우, 로컬 스토리지를 사용하는 매우 최적화 된 네이티브 Redshift 테이블이 훨씬 성능이 좋습니다.
7. 조건절(Predicate) 푸시 다운으로 S3 쿼리 성능 향상
Amazon Redshift Spectrum 수준 (S3 스캔, 프로젝션, 필터링 및 집계)에서 수행되는 처리는 개별 Amazon Redshift 클러스터와는 독립적이고, Redshift 클러스터의 리소스를 사용하지 않습니다.
따라서, Redshift Spectrum 에서 푸시 다운 할 수 있는 특정 SQL 작업이 있습니다. 가능한 한 이를 활용하고 싶다면, 다음 몇 가지 예를 참고하시기 바랍니다.
DISTINCT 및 ORDER BY와 같은 특정 SQL 작업은Redshift Spectrum으로 푸시 다운 될 수 없기 때문에 Redshift에서 수행해야 합니다. 가능한 경우 사용을 최소화하거나 사용하지 않아야 합니다.
다음 두 가지 쿼리를 사용하여 테스트를 수행하면 큰 차이가 있음을 알 수 있습니다.
자연 스럽게 왜 그런지 의문이 듭니다.첫 번째 쿼리에서는 S3 Aggregate가 Redshift Spectrum으로 푸시되고, 집계 된 결과만 최종 처리를 위해 Amazon Redshift로 반환됩니다.
반면에 두 번째 쿼리를 면밀히 살펴보면 Redshift Spectrum이 DATE를 일반 데이터 형식 또는 DATE 변환 함수로 지원하지 않았기 때문에 Redshift Spectrum 계층에서 S3 집계가 없음을 알 수 있습니다. 결과적으로 이 쿼리는 S3에서 대용량 데이터를 Redshift로 직접 가져와 변환 및 처리를 해야합니다.
또 다른 대안적인 방법은 두 SQL 문에 대한 SVL_S3QUERY_SUMMARY 시스템 뷰 (s3query_returned_rows 컬럼)에 대해 쿼리하는 것입니다. Redshift Spectrum에서 Redshift로 반환되는 행(row)수에서 큰 차이가 있다는 점을 알게 될 것입니다.
8. DISTINCT를 GROUP BY로 바꾸기
GROUP BY, MIN/MAX/COUNT 등과 같은 특정 SQL 연산자는 Redshift Spectrum 계층으로 푸시 다운 할 수 있습니다. 다만, DISTINCT 및 ORDER BY와 같은 다른 SQL 연산자는 푸시 다운 할 수 없습니다. 일반적으로 Redshift Spectrum을 지원하는 강력한 인프라 때문에 푸시 다운 할 수 있는 모든 작업의 성능이 Redshift 대비 향상됩니다.
예를 들어, 다음 두 기능적으로 동일한 SQL 문을 테스트해보시기 바랍니다.
DISTINCT로 인해 첫 번째 쿼리에 푸시 다운은 없습니다. 대신 Amazon Redshift에 다량의 행(row)이 반환 및 정렬됨으로서 중복을 제거합니다. 두 번째 쿼리에서 S3 HashAggregate 는 Redshift Spectrum으로 푸시됩니다. 여기서는 대부분 무거운 작업 및 집계를 수행합니다. SVL_S3QUERY_SUMMARY에 대한 질의 계획상 차이점을 확인할수 있습니다.
여기서 우리는 가능하면 SQL 문에서 “DISTINCT“를 “GROUP BY“로 대체하면 좋다는 사실을 알 수 있습니다.
아래 간단한 지침은 최고의 성능을 위해 테이블을 저장할 최적의 위치를 결정하는 데 도움을 줄 것입니다.
9. S3에 큰 팩트 테이블을 넣고 Redshift에 다른 팩트 테이블 두기
3 개의 테이블 조인이 있는 Query 2를 생각해 보겠습니다. 자연스럽게 세개의 테이블 모두가 S3에서 분할 된 Parquet 파일로 되어 있는 경우 어떻게 될까요? 일반적으로 Amazon Redshift에서 세 개의 테이블 모두 사용하는 것보다 성능이 좋을까요 아니면 나쁠까요?
조인(Join) 최적화 된 Amazon Redshift 테이블 세트 (적절한 분배 및 정렬 키 포함)가 Redshift Spectrum보다 성능면에서 뛰어 납니다. Redshift Spectrum 외부 테이블은 통계를 지원하지 않습니다. 데이터베이스 엔진은 추론 또는 간단한 행 수를 사용하여 조인 순서를 결정합니다. 어떤 경우에는 이것이 최적의 방법이 아닐 수 있습니다. AWS의 권장 사항은 Amazon S3에 가장 큰 팩트 테이블만 넣고, 중간 혹은 작은 크기의 테이블은 edshift에 남겨 두는 것입니다. 이렇게 하면 최적화 프로그램을 가장 효과적으로 활용할 수 있습니다.
최근에 CREATE EXTERNAL TABLE 및 ALTER TABLE 명령에서 TABLE PROPERTIES 절을 사용하여 테이블 통계 (numRows)를 설정하는 지원을 추가했습니다. 이를 활용하여 테이블의 정확한 행 번호를 설정하고, 최적의 쿼리 실행 계획을 생성하도록 프로그램에 지시 할 수 있습니다. 자세한 내용은 Amazon Redshift 설명서의 CREATE EXTERNAL TABLE을 참조하십시오.
적어도 세 개의 외부 테이블을 포함하는 추가 쿼리를 정의하고, 올바른 조인 순서 (Explain을 활용 가능)를 사용하여 실행하도록 요청합니다. Amazon Redshift Spectrum을 사용하여 여러 개의 외부 테이블을 절대 결합해서는 안된다는 결론을 성급히 내리지 않도록 하기 위함입니다.
10. 자주 조인하는 대형 테이블을 S3에 넣을 때 조심하기
Amazon Redshift는 Query 2처럼 보이는 질의에 대해서 Redshift Spectrum에서는 많은 동시성 레벨에서 거의 3 배 이상 높은 성능을 보일 수 있습니다. Query 1과 Query 2의 차이점은 Query 1에서 하나의 테이블에 대한 집계 연산만, Query2에서는 비교적 큰 세 개의 테이블 조인 된다는 점입니다.
좀 더 명확하게 말하자면, 성능 차이의 주요 원인은 Amazon Redshift에서 조인이 실행 되기 때문입니다. 조인하는 모든 데이터는 먼저 S3에서 로드되어 Amazon Redshift 클러스터의 개별 슬라이스로 즉시 배포되어야 합니다. 따라서 Amazon Redshift 로컬 스토리지에 접근할 때 보다 Redshift Spectrum을 사용하면 지연 시간이 현저하게 길어집니다.
따라서 조인을 자주하는 서 너개의 테이블이 Amazon Redshift에 있고, 이들 쿼리 작업 부하가 엄격한 SLA의 영향을 받는 경우, 이들은 Amazon S3에 두지 않는 것이 나을 수 있습니다.
이 글은 Amazon Redshift Spectrum의 성능을 향상시키는 몇 가지 중요한 모범 사례를 설명하였습니다. 각 경우는 특이하기 때문에 모범 사례에 맞는 권장되는 특정 상황에 적용에 대한 테스트를 직접해야 합니다. 질문이나 제안 사항이 있으시거나, Amazon Redshift 클러스터 최적화에 대한 추가 지원이 필요하면 AWS 기술팀에 문의하십시오.
| AWS 베어메탈 출시 (0) | 2017.11.29 |
|---|---|
| Amazon Polly 서울 리전 출시 및 한국어 여성 ‘서연(Seoyeon)’ 음성 지원 (0) | 2017.11.29 |
| AWS OpsWorks for Puppet Enterprise (0) | 2017.11.29 |
| AWS, 새 하이퍼바이저로 ‘젠’ 대신 ‘KVM’ 채택 (0) | 2017.11.20 |
| AWS 일본 자료 싸이트 링크 (0) | 2016.10.03 |