メインコンテンツまでスキップ

「AWS」タグの記事が97件件あります

全てのタグを見る

· 約7分
moritalous
お知らせ

過去にQiitaに投稿した内容のアーカイブです。

最近Azureも触りだしましたが、AWSにない便利な機能の一つにAzure Cloud Shellがあります。

Azure Cloud Shellとは

Azure Cloud Shell は、Azure リソースを管理するための、ブラウザーでアクセスできる対話形式の認証されたシェルです。 Bash または PowerShell どちらかのシェル エクスペリエンスを作業方法に合わせて柔軟に選択できます。

https://docs.microsoft.com/ja-jp/azure/cloud-shell/overview

ブラウザからちょっとしたコマンドが実行できるので便利ですね。また、Windows ターミナルやスマホアプリからも使用することができます。 Azure Cloud shellの環境にAWS CLIをインストールしてしまおうという作戦です。

image.png

Azure Cloud Shellの概要

公式サイトからの引用です

概念

  • Cloud Shell は、ユーザーごとにセッション単位で一時的に提供されるホスト上で実行されます。
  • Cloud Shell は、無操作状態で 20 分経過するとタイムアウトとなります。
  • Cloud Shell では、Azure ファイル共有がマウントされている必要があります
  • Cloud Shell では、Bash と PowerShell に対して同じ Azure ファイル共有が使用されます
  • Cloud Shell には、ユーザー アカウントごとに 1 台のマシンが割り当てられます。
  • Cloud Shell はファイル共有に保持されている 5 GB のイメージを使用して $HOME を永続化します
  • Bash では、標準の Linux ユーザーとしてアクセス許可が設定されます。

Bashが使え、5GBのファイル領域があり、$HOMEは永続化されるところがポイントです。

価格

Cloud Shell のホストとなるマシンは無料です。ただし、前提条件として Azure Files 共有をマウントする必要があります。 ストレージのコストは通常どおりに適用されます。

月額約¥6.72/Giなので5G使っても月35円ぐらいです。

AWS CLI V2のインストール

Linux での AWS CLI バージョン 2 のインストールを参考にしますが、ポイントは

  • ホームディレクトリ内にインストールする

です。

@Azure:~$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 31.9M 100 31.9M 0 0 102M 0 --:--:-- --:--:-- --:--:-- 102M
@Azure:~$ unzip -q awscliv2.zip
@Azure:~$ ./aws/install -i ~/aws-cli -b ~/bin
You can now run: /home/xxxxxx/bin/aws --version
@Azure:~$ rm -rf aws
@Azure:~$ rm -rf awscliv2.zip
@Azure:~$
@Azure:~$ ~/bin/aws --version
aws-cli/2.0.46 Python/3.7.3 Linux/4.15.0-1093-azure exe/x86_64.ubuntu.16
@Azure:~$

~/binディレクトリにパスが通るように、.bashrcに書いておきましょう

@Azure:~$ echo 'export PATH=~/bin:$PATH' >> .bashrc
@Azure:~$
@Azure:~$ source .bashrc
@Azure:~$ aws --version
aws-cli/2.0.46 Python/3.7.3 Linux/4.15.0-1093-azure exe/x86_64.ubuntu.16
@Azure:~$

これでインストールは完了です。

認証情報の設定

通常、AWSの認証情報は~/.awsに保管されますが、Azure Cloud Shellの説明に

SSH キーなどのシークレットを格納するときは、ベスト プラクティスを使用します。 Azure Key Vault などのサービスには、設定用のチュートリアルが用意されています。

とありますので、これを使って認証情報を保存してみましょう。

Key Vaultの作成と認証情報の登録

Key Vaultの作成 cloud-shell-aws-cliがKey Vaultの名称です。

@Azure:~$ az keyvault create --name cloud-shell-aws-cli --resource-group [リソースグループ名] --location japaneast

AWS アクセスキーの登録

@Azure:~$ az keyvault key create --vault-name cloud-shell-aws-cli --name aws-access-key-id --protection software
@Azure:~$ az keyvault secret set --vault-name cloud-shell-aws-cli --name aws-access-key-id --value [AWS アクセスキー]

シークレットキーの登録

@Azure:~$ az keyvault key create --vault-name cloud-shell-aws-cli --name aws-secret-access-key --protection software
@Azure:~$ az keyvault secret set --vault-name cloud-shell-aws-cli --name aws-secret-access-key --value [シークレットキー]

AWS リージョンの登録(機密性はありませんが。。)

@Azure:~$ az keyvault key create --vault-name cloud-shell-aws-cli --name aws-default-region --protection software
@Azure:~$ az keyvault secret set --vault-name cloud-shell-aws-cli --name aws-default-region --value ap-northeast-1

Key Vaultに登録した値の取得

登録した値の取得は以下でできます。

@Azure:~$ az keyvault secret show --vault-name cloud-shell-aws-cli --id https://cloud-shell-aws-cli.vault.azure.net/secrets/aws-default-region
{
"attributes": {
"created": "2020-09-06T02:02:45+00:00",
"enabled": true,
"expires": null,
"notBefore": null,
"recoveryLevel": "Recoverable+Purgeable",
"updated": "2020-09-06T02:02:45+00:00"
},
"contentType": null,
"id": "https://cloud-shell-aws-cli.vault.azure.net/secrets/aws-default-region/28db5ad04abf4a1a92d43f7ae9cccae8",
"kid": null,
"managed": null,
"name": "aws-default-region",
"tags": {
"file-encoding": "utf-8"
},
"value": "ap-northeast-1"
}
@Azure:~$

このままだと扱いづらいので必要な値だけを取得します。

@Azure:~$ az keyvault secret show --vault-name cloud-shell-aws-cli --id https://cloud-shell-aws-cli.vault.azure.net/secrets/aws-default-region --output tsv --query "[value]"
ap-northeast-1
@Azure:~$

余談となりますが、az keyvault secret showのパラメーターで必要なidhttps://[Key Vault名].vault.azure.net/secrets/[Key名]の書式ですが、以下のコマンドで取得することも可能です。

@Azure:~$ az keyvault secret list --vault-name cloud-shell-aws-cli
[
{
"attributes": {
"created": "2020-09-06T02:01:33+00:00",
"enabled": true,
"expires": null,
"notBefore": null,
"recoveryLevel": "Recoverable+Purgeable",
"updated": "2020-09-06T02:01:33+00:00"
},
"contentType": null,
"id": "https://cloud-shell-aws-cli.vault.azure.net/secrets/aws-access-key-id",
"managed": null,
"name": "aws-access-key-id",
"tags": {
"file-encoding": "utf-8"
}
},
{
"attributes": {
"created": "2020-09-06T02:02:45+00:00",
"enabled": true,
"expires": null,
"notBefore": null,
"recoveryLevel": "Recoverable+Purgeable",
"updated": "2020-09-06T02:02:45+00:00"
},
"contentType": null,
"id": "https://cloud-shell-aws-cli.vault.azure.net/secrets/aws-default-region",
"managed": null,
"name": "aws-default-region",
"tags": {
"file-encoding": "utf-8"
}
},
{
"attributes": {
"created": "2020-09-06T02:01:44+00:00",
"enabled": true,
"expires": null,
"notBefore": null,
"recoveryLevel": "Recoverable+Purgeable",
"updated": "2020-09-06T02:01:44+00:00"
},
"contentType": null,
"id": "https://cloud-shell-aws-cli.vault.azure.net/secrets/aws-secret-access-key",
"managed": null,
"name": "aws-secret-access-key",
"tags": {
"file-encoding": "utf-8"
}
}
]
@Azure:~$

ここまでで認証情報をKey Vaultに登録及び取得ができました。

なのでこれも.bashrcに登録しちゃいましょう。

@Azure:~$ echo 'export AWS_ACCESS_KEY_ID=`az keyvault secret show --vault-name cloud-shell-aws-cli --id https://cloud-shell-aws-cli.vault.azure.net/secrets/aws-access-key-id --output tsv --query "[value]"`' >> .bashrc
@Azure:~$ echo 'export AWS_SECRET_ACCESS_KEY=`az keyvault secret show --vault-name cloud-shell-aws-cli --id https://cloud-shell-aws-cli.vault.azure.net/secrets/aws-secret-access-key --output tsv --query "[value]"`' >> .bashrc
@Azure:~$ echo 'export AWS_DEFAULT_REGION=`az keyvault secret show --vault-name cloud-shell-aws-cli --id https://cloud-shell-aws-cli.vault.azure.net/secrets/aws-default-region --output tsv --query "[value]"`' >> .bashrc
@Azure:~$
@Azure:~$ source .bashrc
@Azure:~$

動作確認

@Azure:~$ aws sts get-caller-identity
{
"UserId": "XXXXXXXXXXXXXXXXXXX",
"Account": "999999999999",
"Arn": "arn:aws:iam::999999999999:user/XXXXXXXXXX"
}

うまくいきました。

· 約7分
moritalous
お知らせ

過去にQiitaに投稿した内容のアーカイブです。

AWS_CLI-v2.0.36 Azure_CLI-v2.11.0 AWS IoT CoreとAzure IoT HubでIoT機器からデータをアップロードするサンプルを試しました。

手順の比較

No.AWS IoT CoreAzure IoT Hub
(事前)-Azure CLIにエクステンションを追加する
(事前)-リソース グループを作成する
1-IoT Hubを作成する
2モノを作成するデバイスを作成する
3証明書を作成する-
4ポリシーを作成する-
5証明書にポリシーをアタッチする-
6証明書にモノをアタッチする-
7送信側のプログラムを作成する送信側のプログラムを作成する
  • AzureはIoT Hubそのものを作成する手順があります。
  • 認証方式がAWSはX.509 証明書、Azureは対称キーです。他の認証方式を使うと手順も変わると思います。

AWSの手順

モノを作成する

コマンド一発です。

aws iot create-thing --thing-name Thing001

証明書を作成する

パラメータで出力ファイル名を指定しています。

aws iot create-keys-and-certificate --certificate-pem-outfile "Cert001.cert.pem" --public-key-outfile "Cert001.public.key" --private-key-outfile "Cert001.private.key" --set-as-active

この先の手順で、実行結果に含まれる証明書のARN(certificateArn)が必要となりますのでメモっておきましょう。(下の実行結果はAWS CLIのリファレンスの例です)

実行結果
実行結果
{
"certificateArn": "arn:aws:iot:us-west-2:123456789012:cert/9894ba17925e663f1d29c23af4582b8e3b7619c31f3fbd93adcb51ae54b83dc2",
"certificateId": "9894ba17925e663f1d29c23af4582b8e3b7619c31f3fbd93adcb51ae54b83dc2",
"certificatePem": "
-----BEGIN CERTIFICATE-----
MIICiTCCEXAMPLE6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgEXAMPLEAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSEXAMPLE2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYEXAMPLEb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCEXAMPLEJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDAEXAMPLEsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEXAMPLE25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+aEXAMPLE
EXAMPLEfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZEXAMPLELG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAEXAMPLEWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9qEXAMPLEyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDEXAMPLEBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE=
-----END CERTIFICATE-----\n",
"keyPair": {
"PublicKey": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkEXAMPLEQEFAAOCAQ8AMIIBCgKCAQEAEXAMPLE1nnyJwKSMHw4h\nMMEXAMPLEuuN/dMAS3fyce8DW/4+EXAMPLEyjmoF/YVF/gHr99VEEXAMPLE5VF13\n59VK7cEXAMPLE67GK+y+jikqXOgHh/xJTwo+sGpWEXAMPLEDz18xOd2ka4tCzuWEXAMPLEahJbYkCPUBSU8opVkR7qkEXAMPLE1DR6sx2HocliOOLtu6Fkw91swQWEXAMPLE\GB3ZPrNh0PzQYvjUStZeccyNCx2EXAMPLEvp9mQOUXP6plfgxwKRX2fEXAMPLEDa\nhJLXkX3rHU2xbxJSq7D+XEXAMPLEcw+LyFhI5mgFRl88eGdsAEXAMPLElnI9EesG\nFQIDAQAB\n-----END PUBLIC KEY-----\n",
"PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\nkey omittted for security reasons\n-----END RSA PRIVATE KEY-----\n"
}
}

ポリシーを作成する

まずポリシードキュメントを作成します。お試しなのでフルオープンですのでお気をつけください。

policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iot:*"
],
"Resource": [
"*"
]
}
]
}

次にポリシーを作成します。

aws iot create-policy --policy-name Policy001 --policy-document file://policy.json

証明書にポリシーをアタッチする

コマンド一発。証明書のARNは先の手順で取得したものです。

aws iot attach-policy --policy-name Policy001 --target "{証明書のARN}"

証明書にモノをアタッチする

こちらもコマンド一発。証明書のARNは先の手順で取得したものです。

aws iot attach-thing-principal --thing-name Thing001 --principal "{証明書のARN}"

送信側のプログラムを作成する

https://aws.amazon.com/jp/premiumsupport/knowledge-center/iot-core-publish-mqtt-messages-python/ にあるサンプルを使います。

AWS IoT SDK for Python v2のインストール

pip install awsiotsdk

ソースコードの変更

変数名内容
ENDPOINT*1で取得できます
CLIENT_IDモノの名前(Thing001)
PATH_TO_CERTCERTのファイルパス(Cert001.cert.pem)
PATH_TO_KEYプライベートキーのファイルパス(Cert001.private.key)
PATH_TO_ROOTここのAmazonルートCA 1をダウンロード

*1 aws iot describe-endpoint --endpoint-type iot:Data-ATSコマンド

実行結果

20回送信したら終了します。

Connecting to xxxxxxxxxxxxxx-ats.iot.ap-northeast-1.amazonaws.com with client ID 'Thing001'...
Connected!
Begin Publish
Published: '{"message": "Hello World [1]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [2]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [3]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [4]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [5]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [6]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [7]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [8]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [9]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [11]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [12]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [13]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [14]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [15]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [16]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [17]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [18]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [19]"}' to the topic: 'test/testing'
Published: '{"message": "Hello World [20]"}' to the topic: 'test/testing'
Publish End

Azureの手順

Azure CLIにエクステンションを追加する

一部エクステンションが必要なコマンドがあるため、azure-iotエクステンションをインストールします。

az extension add --name azure-iot

リソース グループを作成する

IoT部分とは直接関係ありませんが、Azureの場合は必ずリソースグループが必要です。

az group create --name iot-resource-group --location japaneast

IoT Hubを作成する

コマンド一発。お試しなのでSKUはF1(無料)としてます。

az iot hub create --name iot-hub-00001 --resource-group iot-resource-group --partition-count 2 --sku F1

デバイスを作成する

コマンド一発

az iot hub device-identity create --hub-name iot-hub-00001 --device-id Device001

送信側のプログラムを作成する

https://github.com/Azure-Samples/azure-iot-samples-python/blob/master/iot-hub/Quickstarts/simulated-device/SimulatedDevice.py にあるサンプルを使います。

IoT Hub Device SDKのインストール

pip install azure-iot-device

ソースコードの変更

変数名内容
CONNECTION_STRING*2で取得できます

*2 az iot hub device-identity connection-string show --hub-name iot-hub-00001 --device-id Device001コマンド

実行結果

無限に続きます

IoT Hub Quickstart #1 - Simulated device
Press Ctrl-C to exit
IoT Hub device sending periodic messages, press Ctrl-C to exit
Sending message: {"temperature": 22.73671571030419,"humidity": 65.13300283503716}
Message successfully sent
Sending message: {"temperature": 21.122891449050375,"humidity": 75.35478976197727}
Message successfully sent
Sending message: {"temperature": 30.11015190710952,"humidity": 79.1313503131281}
Message successfully sent
Sending message: {"temperature": 29.056883680577876,"humidity": 74.9253608733604}
Message successfully sent
Sending message: {"temperature": 30.35374671931261,"humidity": 73.57241118544626}
Message successfully sent
Sending message: {"temperature": 33.336413834339076,"humidity": 65.31133008367256}
Message successfully sent
Sending message: {"temperature": 34.92260215374919,"humidity": 69.53101153342156}
Message successfully sent

確認方法について

AWSとAzureでメッセージが届いたか確認する方法が違ったので、紹介します。

AWSの場合

マネジメントコンソールのテストで確認できます。

image.png

Azureの場合

CLIコマンドで確認できます。

az iot hub monitor-events --hub-name iot-hub-00001 --device-id Device001
Starting event monitor, filtering on device: Device001, use ctrl-c to stop...
{
"event": {
"origin": "Device001",
"module": "",
"interface": "",
"component": "",
"payload": "{\"temperature\": 24.86829506815134,\"humidity\": 62.82101201700818}"
}
}
{
"event": {
"origin": "Device001",
"module": "",
"interface": "",
"component": "",
"payload": "{\"temperature\": 27.671191300371653,\"humidity\": 70.30860685264159}"
}
}
{
"event": {
"origin": "Device001",
"module": "",
"interface": "",
"component": "",
"payload": "{\"temperature\": 22.581311567865644,\"humidity\": 66.70979111038993}"
}
}
Stopping event monitor...

おしまい。

· 約7分
moritalous
お知らせ

過去にQiitaに投稿した内容のアーカイブです。

同じARMというだけですが、Graviton2搭載のEC2とRaspberry Pi 4でunixbenchしてみました。 https://github.com/kdlucas/byte-unixbench

スペックGraviton2 EC2Raspberry Pi 4
インスタンスタイプc6g.xlarge(コンピューティング最適化)-
CPUGravition2Broadcom BCM2711
CPU(クロック)2.5 GHz1.5GHz
CPU(コア)44
メモリ8GB8GB
ディスク汎用SSD 8GiBmicroSD 32GiB
OSAmazon Linux 2Raspberry Pi OS(64bit)

コア数とメモリ容量を合わせるためc6g.xlargeインスタンスを選択しました。 クロック数が結構違いますね。

結果

テストGraviton2 EC2Raspberry Pi 4
running 1 parallel copy of tests1711.0348.9
running 4 parallel copies of tests4204.2954.8
結果(Graviton2 EC2)
   BYTE UNIX Benchmarks (Version 5.1.3)

System: ip-172-31-24-63.ap-northeast-1.compute.internal: GNU/Linux
OS: GNU/Linux -- 4.14.186-146.268.amzn2.aarch64 -- #1 SMP Tue Jul 14 18:17:02 UTC 2020
Machine: aarch64 (aarch64)
Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
13:58:30 up 7 min, 1 user, load average: 0.42, 0.13, 0.04; runlevel 2020-08-26

------------------------------------------------------------------------
Benchmark Run: Wed Aug 26 2020 13:58:30 - 14:26:28
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 41225693.4 lps (10.0 s, 7 samples)
Double-Precision Whetstone 5930.3 MWIPS (9.6 s, 7 samples)
Execl Throughput 6945.2 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1024476.6 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 285037.5 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 2920798.7 KBps (30.0 s, 2 samples)
Pipe Throughput 1785412.0 lps (10.0 s, 7 samples)
Pipe-based Context Switching 137584.6 lps (10.0 s, 7 samples)
Process Creation 10991.4 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 9165.4 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 2545.4 lpm (60.0 s, 2 samples)
System Call Overhead 1731853.4 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 41225693.4 3532.6
Double-Precision Whetstone 55.0 5930.3 1078.2
Execl Throughput 43.0 6945.2 1615.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 1024476.6 2587.1
File Copy 256 bufsize 500 maxblocks 1655.0 285037.5 1722.3
File Copy 4096 bufsize 8000 maxblocks 5800.0 2920798.7 5035.9
Pipe Throughput 12440.0 1785412.0 1435.2
Pipe-based Context Switching 4000.0 137584.6 344.0
Process Creation 126.0 10991.4 872.3
Shell Scripts (1 concurrent) 42.4 9165.4 2161.6
Shell Scripts (8 concurrent) 6.0 2545.4 4242.3
System Call Overhead 15000.0 1731853.4 1154.6
========
System Benchmarks Index Score 1711.0

------------------------------------------------------------------------
Benchmark Run: Wed Aug 26 2020 14:26:28 - 14:54:24
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables 164931718.6 lps (10.0 s, 7 samples)
Double-Precision Whetstone 23713.5 MWIPS (9.6 s, 7 samples)
Execl Throughput 19361.7 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1063484.1 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 299432.0 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 2984459.9 KBps (30.0 s, 2 samples)
Pipe Throughput 7148051.0 lps (10.0 s, 7 samples)
Pipe-based Context Switching 1322151.5 lps (10.0 s, 7 samples)
Process Creation 35507.0 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 21132.9 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 3038.7 lpm (60.0 s, 2 samples)
System Call Overhead 4935484.7 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 164931718.6 14133.0
Double-Precision Whetstone 55.0 23713.5 4311.5
Execl Throughput 43.0 19361.7 4502.7
File Copy 1024 bufsize 2000 maxblocks 3960.0 1063484.1 2685.6
File Copy 256 bufsize 500 maxblocks 1655.0 299432.0 1809.3
File Copy 4096 bufsize 8000 maxblocks 5800.0 2984459.9 5145.6
Pipe Throughput 12440.0 7148051.0 5746.0
Pipe-based Context Switching 4000.0 1322151.5 3305.4
Process Creation 126.0 35507.0 2818.0
Shell Scripts (1 concurrent) 42.4 21132.9 4984.2
Shell Scripts (8 concurrent) 6.0 3038.7 5064.5
System Call Overhead 15000.0 4935484.7 3290.3
========
System Benchmarks Index Score 4204.2
結果(Raspberry Pi 4)
   BYTE UNIX Benchmarks (Version 5.1.3)

System: raspberrypi: GNU/Linux
OS: GNU/Linux -- 5.4.51-v8+ -- #1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020
Machine: aarch64 (unknown)
Language: en_US.utf8 (charmap="ANSI_X3.4-1968", collate="ANSI_X3.4-1968")
14:43:43 up 4 days, 11:40, 4 users, load average: 0.25, 0.43, 0.34; runlevel Aug

------------------------------------------------------------------------
Benchmark Run: Wed Aug 26 2020 14:43:43 - 15:11:31
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 15215662.4 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2548.0 MWIPS (9.2 s, 7 samples)
Execl Throughput 1611.0 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 99063.1 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 29139.6 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 291775.2 KBps (30.0 s, 2 samples)
Pipe Throughput 270717.1 lps (10.0 s, 7 samples)
Pipe-based Context Switching 47508.6 lps (10.0 s, 7 samples)
Process Creation 2797.1 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 2815.6 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 657.8 lpm (60.1 s, 2 samples)
System Call Overhead 233131.0 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 15215662.4 1303.8
Double-Precision Whetstone 55.0 2548.0 463.3
Execl Throughput 43.0 1611.0 374.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 99063.1 250.2
File Copy 256 bufsize 500 maxblocks 1655.0 29139.6 176.1
File Copy 4096 bufsize 8000 maxblocks 5800.0 291775.2 503.1
Pipe Throughput 12440.0 270717.1 217.6
Pipe-based Context Switching 4000.0 47508.6 118.8
Process Creation 126.0 2797.1 222.0
Shell Scripts (1 concurrent) 42.4 2815.6 664.1
Shell Scripts (8 concurrent) 6.0 657.8 1096.4
System Call Overhead 15000.0 233131.0 155.4
========
System Benchmarks Index Score 348.9

------------------------------------------------------------------------
Benchmark Run: Wed Aug 26 2020 15:11:31 - 15:39:21
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables 60352336.5 lps (10.0 s, 7 samples)
Double-Precision Whetstone 10173.2 MWIPS (9.2 s, 7 samples)
Execl Throughput 4667.7 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 241446.5 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 69320.4 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 626527.5 KBps (30.0 s, 2 samples)
Pipe Throughput 1073258.4 lps (10.0 s, 7 samples)
Pipe-based Context Switching 175098.6 lps (10.0 s, 7 samples)
Process Creation 6117.2 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 5161.1 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 892.0 lpm (60.2 s, 2 samples)
System Call Overhead 906068.3 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 60352336.5 5171.6
Double-Precision Whetstone 55.0 10173.2 1849.7
Execl Throughput 43.0 4667.7 1085.5
File Copy 1024 bufsize 2000 maxblocks 3960.0 241446.5 609.7
File Copy 256 bufsize 500 maxblocks 1655.0 69320.4 418.9
File Copy 4096 bufsize 8000 maxblocks 5800.0 626527.5 1080.2
Pipe Throughput 12440.0 1073258.4 862.7
Pipe-based Context Switching 4000.0 175098.6 437.7
Process Creation 126.0 6117.2 485.5
Shell Scripts (1 concurrent) 42.4 5161.1 1217.2
Shell Scripts (8 concurrent) 6.0 892.0 1486.7
System Call Overhead 15000.0 906068.3 604.0
========
System Benchmarks Index Score 954.8

ということで、正解は4.4~4.9個分でした。 CPUクロック以上に性能差がありそうですね。

Raspberry Pi 4のCPU温度

ベンチマーク中のRaspberry Pi 4のCPU温度は77℃ぐらいまで上がりました。 (ヒートシンク付き、オフィシャルケースの蓋を開けた状態)

image.png

参考

https://aws.amazon.com/jp/ec2/instance-types/ https://www.raspberrypi.org/products/raspberry-pi-4-model-b/specifications/

· 約6分
moritalous
お知らせ

過去にQiitaに投稿した内容のアーカイブです。

※個人の調査によるものです。誤りがあればご指摘ください ※2020/8/8現在の情報をもとにまとめました。

AWSとAzureのリージョンなどの考え方を比較しました。

AWS

分類レベル名称定義
レベル小データセンター1つの物理的なデータセンター
レベル中アベイラビリティゾーン (AZ)1 つの AWS リージョン内でそれぞれ切り離され、冗長的な電力源、ネットワーク、そして接続機能を備えている 1 つ以上のデータセンターのことです。各 AZ はそれぞれ他の AZ から物理的に意味のある距離、つまり数キロメートル離れていますが、すべて 100 km 以内 (互いに 60 マイル) に配置されています。
レベル大リージョン1 つの地理的エリアにある、複数の、それぞれが隔離され物理的にも分離された AZ によって構成されています。1 つのデータセンターを 1 つのリージョンとして定義することが多い他のクラウドプロバイダーとは違い、全 AWS リージョンが採用するこのマルチ AZ デザインは、お客様にいくつかのメリットをご提供するものです。

大阪ローカルリージョンは特殊で、

  • 分離された耐障害性の高いインフラストラクチャデザインが 1 つのデータセンター内で構成されます。
  • アジアパシフィック (大阪) ローカルリージョンは 1 つのアベイラビリティーゾーンで構成されており、アジアパシフィック (東京) リージョンと組み合わせて使用することが意図されています。
  • このリージョンには、お客様のセールス担当者からのリクエストが必要です。

とのこと。

他にはLocal Zonesというものがあるようです。現在はロサンゼルスのみで提供されています。

https://aws.amazon.com/jp/about-aws/global-infrastructure/ https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/ https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/

Azure

分類レベル名称定義
Azure データセンターネットワークに接続されたコンピューター サーバーのグループを収容する、世界中に存在する一意の物理的な建物です。
Azure Availability ZonesAzure リージョン内の一意の物理的な場所であり、データセンターの障害からアプリケーションとデータを保護する高可用性を提供しています。それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。
Azure リージョンAzure リージョンは、待機時間で定義された境界内でデプロイされ、低遅延の専用リージョン ネットワークを使用して接続された一連のデータセンターです。
特大Azure 地域通常、1 つ以上のリージョンを含み、データ所在地とコンプライアンスの境界を保持します。

AWSにはない、「地域」というものが出てきました。リージョンも地域のような気もしますが、英語名はAzure リージョンがAzure regionで、Azure 地域がAzure geographyです。 東日本リージョンと西日本リージョンはペアに指定されているようで、このAzure 地域に該当するようです。

ペアになっているリージョンのメリットとしては、以下が上げらててました

  • 物理的な分離
  • プラットフォームに備わっているレプリケーション
  • リージョン復旧順序
  • 順次更新
  • データ所在地

https://azure.microsoft.com/ja-jp/global-infrastructure/ https://azure.microsoft.com/ja-jp/global-infrastructure/geographies/#geographies https://docs.microsoft.com/ja-jp/azure/best-practices-availability-paired-regions

日本国内リージョンの比較

比較項目AWS東京リージョンAWS大阪ローカルリージョンAzure東日本リージョンAzure西日本リージョン
開設時期2011年2018年2014年2014年
AZ数4131

調べていると、AWS東京リージョンに4つ目のリージョンが開設されたのが、2018年、Azure東日本リージョンがAZに対応したのが2019年のようです。この間はAWS東京リージョンが4AZ、Azure東日本リージョンが1AZとかなりの差があったような形ですね。 また、AWS大阪ローカルリージョンは2021年初頭までに3つのAZをもつフルリージョンになるようです。

https://aws.amazon.com/jp/blogs/news/the-fourth-new-availability-zone-tokyo-region/ https://azure.microsoft.com/ja-jp/updates/general-availability-azure-availability-zones-in-japan-east/ https://aws.amazon.com/jp/blogs/news/in-the-works-aws-osaka-local-region-expansion-to-full-region/

まとめ

AWS側のほうが知識があるので、AWS押しのような内容となりましたが、Azure側の押しポイントがあれば教えて下さい。

· 約10分
moritalous
お知らせ

過去にQiitaに投稿した内容のアーカイブです。

Quarkus(https://quarkus.io/) とはSUPERSONIC SUBATOMIC JAVAで、

A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards.

だそうです。 何言ってるかわかりませんがすごそうです。

GraalVMの機能でJavaのプログラムをネイティブに変換することが可能なので、AWS Lambdaのカスタムランタイムと組み合わせることで AWS Lambda上で動作するJavaアプリケーションの特性である コールドスタートが遅い問題 の解決に期待ができます。

公式サイトの手順に従い試してみましたので、手順を残します。

QUARKUS - BUILDING A NATIVE EXECUTABLE https://quarkus.io/guides/building-native-image

QUARKUS - AMAZON LAMBDA https://quarkus.io/guides/amazon-lambda

環境

  • Docker Desktop (Mac) 2.3.0.4
  • VSCode + Visual Studio Code Remote - Containers extension
  • Amazon Linux 2 (on Docker)

雛形アプリのデプロイ手順

手順1. Amazon Linux 2の環境設定

DockerイメージのAmazon Linux 2はtarunzipができないので色々入れておきます。 全部必要かわからないですが、これぐらい入れておきました。

yum install -y sudo shadow-utils procps tar.x86_64 gzip xz unzip witch git python3 tree

手順2. GraalVMのインストール

公式サイトからダウンロードして展開します。

curl -s -L -o /tmp/graalvm-ce-java11-linux-amd64-20.1.0.tar.gz https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-20.1.0/graalvm-ce-java11-linux-amd64-20.1.0.tar.gz
tar zxf /tmp/graalvm-ce-java11-linux-amd64-20.1.0.tar.gz -C /opt/
ln -s /opt/graalvm-ce-java11-20.1.0 /opt/graalvm

JAVA_HOMEをGraalVMにして、MavenでのビルドにGraalVMを使用します。

export GRAALVM_HOME=/opt/graalvm
export JAVA_HOME=$GRAALVM_HOME
export PATH=$GRAALVM_HOME/bin:$PATH

最後にNativeビルド時に必要なnative-imageをインストールします。コマンドはgu(GraalVM Updater)です。

gu install native-image

手順3. Mavenのインストール

Quarkusのビルドで使用するMavenは3.6.2以上のバージョンが必要です。yumでインストールできるバージョンが古かったので、公式サイトからダウンロードしてインストールしました。

curl -s -L -o /tmp/apache-maven-3.6.3-bin.tar.gz https://downloads.apache.org/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
tar zxf /tmp/apache-maven-3.6.3-bin.tar.gz -C /opt/
ln -s /opt/apache-maven-3.6.3 /opt/apache-maven

mvnのバージョン確認

bash-4.2# mvn --version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /opt/apache-maven
Java version: 11.0.7, vendor: GraalVM Community, runtime: /opt/graalvm-ce-java11-20.1.0
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.19.76-linuxkit", arch: "amd64", family: "unix"
bash-4.2#

GraalVMのJVMで動作していることがわかります。

手順4. Mavenでプロジェクト作成

mvnコマンドでプロジェクトを生成します。

mvn archetype:generate \
-DarchetypeGroupId=io.quarkus \
-DarchetypeArtifactId=quarkus-amazon-lambda-archetype \
-DarchetypeVersion=1.6.0.Final

しばらくするとプロンプトで質問されますので答えます。 []で囲んだ部分がユーザー入力です。

Define value for property 'groupId': [myGroup]
Define value for property 'artifactId': [myArtifact]
Define value for property 'version' 1.0-SNAPSHOT: : []
Define value for property 'package' myGroup: : [example]
Confirm properties configuration:
groupId: myGroup
artifactId: myArtifact
version: 1.0-SNAPSHOT
package: example
Y: : [Y]

artifactId(myArtifact)でディレクトリが作成され、プロジェクトが生成されます。

作成直後のプロジェクト構成はこんな感じ。

bash-4.2# tree myArtifact/
myArtifact/
├── build.gradle
├── gradle.properties
├── payload.json
├── pom.xml
├── settings.gradle
└── src
├── main
│ ├── java
│ │ └── example
│ │ ├── InputObject.java
│ │ ├── OutputObject.java
│ │ ├── ProcessingService.java
│ │ ├── StreamLambda.java
│ │ ├── TestLambda.java
│ │ └── UnusedLambda.java
│ └── resources
│ └── application.properties
└── test
├── java
│ └── example
│ └── LambdaHandlerTest.java
└── resources
└── application.properties

9 directories, 14 files
bash-4.2#

手順5. Lambdaで起動するHandlerの設定

Lambdaで呼び出されるHandlerはresources/application.propertiesquarkus.lambda.handlerにて設定します。

resources/application.properties
quarkus.lambda.handler=test

上記設定の場合は、以下のtestと名前をつけたクラスが呼び出されます。

main/java/example.TestLambda.java
@Named("test")
public class TestLambda implements RequestHandler<InputObject, OutputObject> {
}

あとは通常のLambdaと同様にコーディングします。 雛形にはtestの他にstreamなども用意されています。

手順6. デプロイパッケージの作成

一旦雛形のままデプロイパッケージを作成してみます。

mvn clean package -Pnative

めちゃくちゃ時間がかかります。10分以上かかると思います。

手順7. デプロイパッケージの内容の確認

無事デプロイパッケージができると、target/function.zipが生成されいます。試しに展開してみると、中身はbootstrapのみでした。

bash-4.2# unzip function.zip 
Archive: function.zip
inflating: bootstrap
bash-4.2#

手順8. Lambdaのデプロイ

targetディレクトリ内には、manage.shというファイルも生成されており、ここからAWS上にデプロイしたりできるようです。 私はカスタムランタイムが初めてだったこともあり、マネジメントコンソールから試してみました。 デプロイパッケージ作成後に、target/sam.native.yamlというファイルも生成されるので、ハンドラー名や環境変数はこちらを参考にしました。

関数を新規作成します。 ランタイムをユーザー独自のブートストラップを提供するとします。

ap-northeast-1.console.aws.amazon.com_lambda_home_region=ap-northeast-1(Laptop with MDPI screen).png

関数を作成したら、プログラムをアップロードします。 関数コードのところのアクションから.zipファイルをアップロードを選び、function.zipを選択します。

ap-northeast-1.console.aws.amazon.com_lambda_home_region=ap-northeast-1(Laptop with MDPI screen) (1).png

ハンドラーはnot.used.in.provided.runtimeとなります。

ap-northeast-1.console.aws.amazon.com_lambda_home_region=ap-northeast-1(Laptop with MDPI screen) (2).png

環境変数にDISABLE_SIGNAL_HANDLERSを追加し値をtrueとします。

ap-northeast-1.console.aws.amazon.com_lambda_home_region=ap-northeast-1(Laptop with MDPI screen) (4).png

ここまでで設定は完了です。以下のJSONをインプットにテスト実行してみましょう。

ap-northeast-1.console.aws.amazon.com_lambda_home_region=ap-northeast-1(Laptop with MDPI screen) (3).png

{
"name": "Bill",
"greeting": "hello"
}

動作結果がこちら。無事動きました。

ap-northeast-1.console.aws.amazon.com_lambda_home_region=ap-northeast-1(Laptop with MDPI screen) (5).png

AWS SDK を追加

AWS SDKを使用するには単純にpom.xmlに追加するだけでなく、いくつか設定が必要です。

手順1. SSL通信の有効化

resources/application.propertiesに以下の内容を追加します。(公式ドキュメント的にはデフォルトで有効って書いてある気もしますが)

resources/application.properties
quarkus.ssl.native=true

手順2. 依存関係の追加

まずは、quarkus-jaxbが必要とのことで、これを追加します。

pom.xml
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-jaxb</artifactId>
</dependency>

次にAWS SDKのライブラリーを追加するのですが、

For native image, however the URL Connection client must be preferred over the Apache HTTP Client when using synchronous mode, due to issues in the GraalVM compilation (at present).

翻訳すると ただし、ネイティブイメージの場合、GraalVMコンパイルの問題(現在)のため、同期モードを使用するときは、Apache HTTPクライアントよりもURL接続クライアントを優先する必要があります。 だそうです。そのため、以下のような記述となります。

pom.xml
<properties>
<aws.sdk2.version>2.10.69</aws.sdk2.version>
</properties>

<dependencyManagement>
<dependencies>

<dependency>
<groupId>software.amazon.awssdk</groupId>
<artifactId>bom</artifactId>
<version>${aws.sdk2.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>

</dependencies>
</dependencyManagement>
<dependencies>

<dependency>
<groupId>software.amazon.awssdk</groupId>
<artifactId>url-connection-client</artifactId>
</dependency>

<dependency>
<groupId>software.amazon.awssdk</groupId>
<artifactId>apache-client</artifactId>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>

<dependency>
<groupId>software.amazon.awssdk</groupId>
<artifactId>s3</artifactId>
<exclusions>
<!-- exclude the apache-client and netty client -->
<exclusion>
<groupId>software.amazon.awssdk</groupId>
<artifactId>apache-client</artifactId>
</exclusion>
<exclusion>
<groupId>software.amazon.awssdk</groupId>
<artifactId>netty-nio-client</artifactId>
</exclusion>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>

<dependency>
<groupId>org.jboss.logging</groupId>
<artifactId>commons-logging-jboss-logging</artifactId>
<version>1.0.0.Final</version>
</dependency>
</dependencies>

手順3. Javaコードの作成

S3にアクセスする例ですが、S3Clientを生成する際に、httpClientにて明示的にUrlConnectionHttpClientを指定します。

S3Client s3 = S3Client.builder()
.region(Region.AP_NORTHEAST_1)

.httpClient(software.amazon.awssdk.http.urlconnection.UrlConnectionHttpClient.builder().build())
.build();

手順4. SSL通信に必要な設定

SSL通信を行うためにデプロイパッケージに以下を含める必要があります。

  • カスタムBootstrap
  • libsunec.so
  • cacerts

まず、src/main/zip.native/ディレクトリを作成し、bootstrapを作成します。

zip.native/bootstrap
#!/usr/bin/env bash

./runner -Djava.library.path=./ -Djavax.net.ssl.trustStore=./cacerts

次にlibsunec.socacertsをコピーします。この2つのファイルはGraalVMに含まれています。

cp $GRAALVM_HOME/lib/libsunec.so $PROJECT_DIR/src/main/zip.native/
cp $GRAALVM_HOME/lib/security/cacerts $PROJECT_DIR/src/main/zip.native/

手順5. デプロイパッケージの作成

デプロイパッケージの作成手順は変わりません。

mvn clean package -Pnative

手順6. デプロイパッケージの内容の確認

SSL有効化した状態でデプロイパッケージを作成すると、target/function.zipの中身が変わります。

bash-4.2# unzip function.zip 
Archive: function.zip
inflating: bootstrap
inflating: cacerts
inflating: libsunec.so
inflating: runner
bash-4.2#

事前準備したbootstrap``cacerts``libsunec.soが含まれているのがわかります。

終わりに

通常のJavaランタイムよりも、コールドスタートが早くなる検証結果はこちらで確認ください。

QuarkusがJava Lambdaを救う!?