Monday, June 28, 2021

Amazon 量子元帳データベース (QLDB)

 

台帳とは?
台帳は、記録管理システムです
業務記録を保持するためのシステムには、情報のキャプチャ、チェック、記録、レビュー、および情報の処理が含まれます。

量子台帳データベース (QLDB) とは?
Amazon QLDB は、信頼できる中央機関が所有する、透過的で不変で暗号的に検証可能なトランザクション ログを提供する完全マネージドの元帳データベースです。

QLDB は、分割できない離散変化のように「量子」と呼ばれます。 すべてのトランザクションは、各ブロックが個別の状態変化を表す透過的なジャーナルに記録されます。 Amazon QLDB を使用して、すべてのアプリケーション データの変更を追跡し、時間の経過に伴う完全で検証可能な変更履歴を維持できます。

ビジネスユースケース:

製造業:
多くの企業はほとんどの場合、製品の完全な製造履歴を追跡するために、自社のサプライチェーン・システム間でデータを調整する必要があります。 台帳データベースを使用して、各トランザクションの履歴を記録し、施設で製造された製品の各バッチの詳細を提供できます。
製品のリコールが発生した場合、メーカーは QLDB を使用して、製品の生産および流通ライフサイクル全体の履歴を簡単に追跡できます。

人事と給与支払い:
多くの場合、人事システムは給与、ボーナス、福利厚生、業績履歴、保険など、従業員の詳細の記録を追跡および維持する必要があります。 QLDB を使用して記録システム アプリケーションを実装することにより、顧客は従業員のデジタル履歴の信頼できる完全な記録を 1 か所で簡単に管理できます。

小売業及びサプライチェーン:
多くの小売業者は、製品がどこから来たのか、製品の何品目が出荷されたのか、誰に、誰が出荷を処理したのかなど、製品のサプライ チェーンのすべての段階に関する情報にアクセスする必要があります。 QLDB を使用すると、小売企業は製品のすべての物流段階で、在庫とサプライ チェーン トランザクションの完全な履歴を遡り確認、追跡できます。

AWS の他の目的で構築された DB は何ですか?

リレーショナルと QLDB の用語:

その仕組みは?

Amazon QLDBは、各アプリケーションデータの変更を追跡するジャーナルを使用し、時間の経過とともに変更の完全で連続した履歴を維持します。 ジャーナル上のデータは削除や修正ができません。 データベースの完全な履歴にアクセスすることができ、履歴を照会・分析して、データが時間の経過とともにどのように変化したかを確認することができます。

Amazon QLDBを使用すると、アプリケーションデータの変更履歴が正確であることを信頼できます。 QLDBは、暗号化ハッシュ関数(SHA-256)を使用して、データの変更履歴の安全な出力ファイル(ダイジェストと呼ばれる)を生成します。 このダイジェストは、データの変更履歴を証明するものとして機能し、データ変更の整合性を振り返って検証することができます。

Amazon QLDBは、高可用性を目指して設計されており、1つのアベイラビリティーゾーン(AZ)内だけでなく、AWSリージョン内の3つのAZにまたがって複数のデータコピーを複製することができ、追加のコストや設定は必要ありません。

QLDB テーブル
QLDBデータは、ドキュメントのテーブル、より正確にはドキュメント・リビジョンに整理されています。 ドキュメントリビジョンとは、ドキュメントの全データセットの1回の反復を表す構造であり、ユーザーデータとシステムが生成したメタデータの両方を含みます。 文書がテーブルから削除された場合、同じ文書IDを持つ文書を同じ台帳で再び作成することはできません。

QLDBのドキュメントは、Amazon Ion形式で保存されています。 Ionは、JSONのスーパーセットであり、有効なJSONドキュメントは、有効なIonドキュメントでもあるということです。 Ionには、追加のデータタイプ、タイプアノテーション、コメントが含まれています。 Ionは、構造化データと非構造化データの両方を保存することができる抽象的なデータモデルに基づいています。

QLDBジャーナル
アプリケーションがドキュメント内のデータを変更する必要がある場合、データベース・トランザクションでそれを行います。 QLDBのトランザクションはACIDに準拠しており、最高レベルの分離性である完全なシリアライズが可能です。 トランザクションでは、データが元帳から読み込まれ、更新され、ジャーナルにコミットされます。 ジャーナルは、データに対するすべての変更の完全かつ不変の履歴を表します。 QLDB は、1 つのトランザクション内で、1 つ以上の連鎖したブロックをジャーナルに書き込みます。 各ブロックには、挿入、更新、削除したドキュメント・リビジョンを表すエントリ・オブジェクトと、それらをコミットした PartiQL ステートメントが含まれます。

トランザクションがジャーナルに書き込まれると、暗号化されたダイジェストが計算され、トランザクションの一部として保存されます。 トランザクションがシステム内を移動するたびに、ダイジェストが破損していないかどうかがチェックされます

QLDBでは、各元帳は正確に1つのジャーナルを持ちます。 現在、ジャーナルは、ストランドと呼ばれる1つのパーティションのみを持ちます。

Amazon QLDB の機能:

  • 不変で透過的
  • 暗号化された検証可能性
  • サーバーレス
  • 高可用性
  • ストリーミング機能

価格:
Amazon QLDB元帳で消費されるストレージはGB月ごとに、消費されるIOは100万リクエストごとに請求されます。 Amazon QLDB元帳が消費するストレージとIOに対してのみ支払います。 ストレージには、お客様が書き込んだデータに加えて、履歴、インデックス、システムが生成したメタデータが含まれます。 これらに加えて、標準的なデータ転送料が適用されます

  • 書き込み I/O 100 万リクエストあたり $0.799
  • 読み取り I/O 100 万リクエストあたり $0.155 ジャーナル
  • ストレージ レート $0.034/GB/月
  • インデックス付きストレージ レート 1 GB あたり $0.285

実践:

お客様のアカウントに “myBankLedger “という名前のLedgerを作成します。

それでは、クエリエディタを使ってテーブルとインデックスを作成してみましょう。

CREATE TABLE Accounts
CREATE TABLE AvailableBalanceCREATE INDEX ON Accounts (AccountId)
CREATE INDEX ON AvailableBalance (AccountId)

デモデータを読み込んでみましょう。

INSERT INTO Accounts
<< {
'AccountId' : 'LEWISR261LL',
'AccountType' : 'Savings',
'FirstName' : 'Raul',
'LastName' : 'Lewis',
'DOB' : `1963-08-19T`,
'Address' : '1719 University Street, Seattle, WA, 98109'
},
{
'AccountId' : 'LOGANB486CG',
'AccountType' : 'Savings',
'FirstName' : 'Brent',
'LastName' : 'Logan',
'DOB' : `1967-07-03T`,
'Address' : '43 Stockert Hollow Road, Everett, WA, 98203'
},
{
'AccountId' : 'PENAB486CG',
'AccountType' : 'Business',
'FirstName' : 'Alexis',
'LastName' : 'Pena',
'DOB' : `1974-02-10T`,
'Address' : '4058 Melrose Street, Spokane Valley, WA, 99206'
},
{
'AccountId' : 'P626168765',
'AccountType' : 'Business',
'FirstName' : 'Melvin',
'LastName' : 'Parker',
'DOB' : `1976-05-22T`,
'Address' : '4362 Ryder Avenue, Seattle, WA, 98101'
} >>INSERT INTO AvailableBalance
<< {
'AccountId' : 'P626168765',
'Balance': 1000.00,
'Currency': 'JPY'
},
{
'AccountId' : 'PENAB486CG',
'Balance': 1000.00,
'Currency': 'JPY'
},
{
'AccountId' : 'LOGANB486CG',
'Balance': 1000.00,
'Currency': 'JPY'
},
{
'AccountId' : 'LEWISR261LL',
'Balance': 1000.00,
'Currency': 'JPY'
} >>
SELECT * FROM Accounts

それでは、お金を送ったり受け取ったりしてみましょう。

-- P626168765 → LOGANB486CG 300 JPYUPDATE AvailableBalance ab
SET ab.Balance = 700.00
WHERE ab.AccountId = 'P626168765'UPDATE AvailableBalance ab
SET ab.Balance = 1300.00
WHERE ab.AccountId = 'LOGANB486CG'-- LOGANB486CG → LEWISR261LL 100 JPYUPDATE AvailableBalance ab
SET ab.Balance = 1200.00
WHERE ab.AccountId = 'LOGANB486CG'UPDATE AvailableBalance ab
SET ab.Balance = 1100.00
WHERE ab.AccountId = 'LEWISR261LL'-- CASH ADD PENAB486CG 100 JPY
UPDATE AvailableBalance ab
SET ab.Balance = 1100.00
WHERE ab.AccountId = 'PENAB486CG'
SELECT * FROM AvailableBalance

履歴機能:

履歴関数は、アプリケーション データと関連するメタデータの両方を含む、テーブルのコミットされたビューのリビジョンを返します。 メタデータには、各リビジョンがいつ、どの順番で、どのトランザクションでコミットされたかが正確に示されています。

 -- History Function
SELECT * FROM history(AvailableBalance) AS ab
WHERE ab.data.AccountId = 'LOGANB486CG' 

View as Ion — リビジョンを見ることができます

台帳のドキュメントを検証する

 SELECT * FROM _ql_committed_AvailableBalance AS a
WHERE a.data.AccountId = 'PENAB486CG' 
  • 元帳 — myBankLedger を選択します。
  • ブロック アドレス — 上記のクエリによって返される blockAddress 値
  • ドキュメント ID — 上記のクエリによって返される ID 値
  • ダイジェストを取得 — QLDB Ledger -> ダイジェストを取得ボタン

最後に。

読んでいただきありがとうございます😃

Monday, June 14, 2021

AWS Amplify — 3分でわかる静的ウェブホスティング

 


3分でわかる SSL 証明書を使用する静的 Web ホスティング用の AWS Amplify

AWS Amplify とは何ですか?

AWS Amplifyは、モバイルやフロントエンドのWeb開発者が、AWSを利用して安全でスケーラブルなフルスタックアプリケーションを構築し、デプロイすることを可能にするエンド・ツー・エンドのソリューションです。

Amplifyでは、数分でアプリのバックエンドを設定し、数行のコードでアプリに接続し、3ステップで静的なWebアプリをデプロイすることができます。

AWS Amplifyで市場投入までの時間を短縮しましょう。

このブログでは、AWS Amplifyの「Static Web Hosting」オプションについてご紹介します。

AWS Amplify スケーラブルなウェブホスティング。

・フィーチャーブランチの導入
・カスタムドメインの設定
・ワークフローの継続(CD)
・グローバルに利用可能
・インスタント+アトミックデプロイメント
・パスワードによる保護

どのように機能するのか?

1.リポジトリへの接続
2.ビルド設定
3.アプリのデプロイ

価格について:

静的 Web ホスティング — 無料利用枠*

ビルド & デプロイ

・1 か月あたり 1000 ビルド分

ホスティング

. 1か月あたり5GBの保存・1か月あたり
. 15GBのサービス
*無料利用枠は、12 か月の AWS 無料利用枠期間の終了時に期限切れになります。

静的 Web ホスティング — 従量課金制

ビルド&デプロイ

・ビルド分あたり$0.01

ホスティング

・1 か月あたり 1 GB あたり 0.023 ドル保存
・1 GB あたり 0.15 ドル

プロジェクトごとに複数のサイト、追加費用なしでパブリック SSL 証明書が含まれています。

ハンズオン — 3 分以内の静的 Web ホスティング

前提条件:

1.  AWS アカウントにログインします (アカウントを持っていない — アカウントを作成します)
2. AWS Amplify アクセスの IAM ロールと権限

開始:

・AWSアカウントにログインして「AWS Amplify」を選択

・「デプロイ→開始」を選択

・ここでは「GitHub」を使用しますが、必要に応じて他のオプションを使用できます。

・GitHubにログイン

・GitHub に対して AWS Amplify を認証する

リポジトリ ( https://github.com/skynet86/aws-amplify-static-webをフォークできます) とブランチ (このブランチにコミットすると、新しいバージョンの自動デプロイが開始されます) を選択します。

・ビルド設定を構成し、デモではデフォルトのままにします。

確認して「保存してデプロイ」をクリックします。

・数秒で完了です。

完了です。私たちはアプリで生きています。

・カスタム ドメインを追加:

ドメイン管理→ドメイン追加」を選択

・ドメインの指定 (続きを読む) — Route 53 にすでにドメインがある場合は、ワンクリックですべてのセットアップが数分で自動的に行われます。

アクセス ログを表示します。

HTTP から HTTPS へのリダイレクト:

「ブランチのデプロイとチームのワークフローの機能」や「アクセスの制限」など、他にもたくさんの機能があります。AWS Amplify でさらに探索することをお勧めします。

最後に。

読んでいただきありがとうございます😃

Source:

Tuesday, June 8, 2021

Container Images with AWS Lambda

 

Image : Fiver

Container images for your serverless functions

Lambda Support Container Images

You can package your code and dependencies as a container image using tools such as the Docker CLI. You can then upload the image to a container registry such as Amazon Elastic Container Registry. You can now package and deploy Lambda functions as container images of up to 10 GB in size. In this way, you can also easily build and deploy larger workloads that rely on sizable dependencies, such as machine learning or data intensive workloads.

AWS provides a set of open-source base images that you can use to build the container image for your function code. Lambda provides base images for the following runtimes:

  • Node.js (Docker Hub: amazon/aws-lambda-nodejs)
  • Python (Docker Hub: amazon/aws-lambda-python)
  • Java (Docker Hub: amazon/aws-lambda-java)
  • .NET (Docker Hub: amazon/aws-lambda-dotnet)
  • Go (Docker Hub: amazon/aws-lambda-go)
  • Ruby (Docker Hub: amazon/aws-lambda-ruby)

You can also use alternative base images from other container registries. AWS also provides an open-source runtime client that you add to your alternative base image to make it compatible with the Lambda service.

Base Images for Custom Runtimes

AWS provides base images that contain the required Lambda components and the Amazon Linux or Amazon Linux2 operating system. You can add your preferred runtime, dependencies and code to these images.

Docker Hub: amazon/aws-lambda-provided

Before going hands on with Container Image with Lambda, Let’s clear some basic understanding about Lambda.

AWS Lambda Execution Environment

Lambda invokes your function in an execution environment, which provides a secure and isolated runtime environment. The execution environment manages the resources required to run your function. The function’s runtime communicates with Lambda using the Runtime API. Extensions communicate with Lambda using the Extensions API. Extensions can also receive log messages from the function by subscribing to logs using the Logs API.

Lambda Execution Environment Lifecycle

  • Init — In this phase, Lambda creates or unfreezes an execution environment with the configured resources, downloads the code for the function and all layers, initializes any extensions, initializes the runtime, and then runs the function’s initialization code (the code outside the main handler). The Init phase happens either during the first invocation, or in advance of function invocations if you have enabled provisioned concurrency.
  • Invoke — In this phase, Lambda invokes the function handler. After the function runs to completion, Lambda prepares to handle another function invocation.
  • Shutdown — This phase is triggered if the Lambda function does not receive any invocations for a period of time. In the Shutdown phase, Lambda terminates the runtime, alerts the extensions to let them stop cleanly, and then removes the environment. Lambda sends a Shutdown event to each extension, which tells the extension that the environment is about to be shut down.

Why we need Runtime Interface Client?

“To implement the Lambda Runtime API”

The runtime interface client in your container image manages the interaction between Lambda and your function code. AWS have open-sourced a set of software packages, Runtime Interface Clients (RIC), that implement the Lambda Runtime API, allowing you to seamlessly extend your preferred base images to be Lambda compatible. The Lambda Runtime Interface Client is a lightweight interface that allows your runtime to receive requests from and send requests to the Lambda service.

Why we need Runtime interface emulator?

“For local testing of container image and Lambda”

Lambda provides a runtime interface emulator (RIE) for you to test your function locally. The AWS base images for Lambda include the RIE. For other base images, you can download the Runtime interface emulator from the AWS GitHub repository.

mkdir -p ~/.aws-lambda-rie curl -Lo ~/.aws-lambda-rie/aws-lambda-rie https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie chmod +x ~/.aws-lambda-rie/aws-lambda-rie

Let’s build custom image for Node.js

  • our app.js (save under “./myFunction” folder)
"use strict";exports.handler = async (event, context) => { return 'Hello World!'+'Event:'+JSON.stringify(event)+'Context:'+JSON.stringify(context); }
  • our Dockerfile
# Define custom function directory
ARG FUNCTION_DIR="/function"FROM node:12-buster as build-image# Include global arg in this stage of the build
ARG FUNCTION_DIR# Install aws-lambda-cpp build dependencies
RUN apt-get update && \
apt-get install -y \
g++ \
make \
cmake \
unzip \
libcurl4-openssl-dev# Copy function code
RUN mkdir -p ${FUNCTION_DIR}
COPY myFunction/* ${FUNCTION_DIR}WORKDIR ${FUNCTION_DIR}# If the dependency is not in package.json uncomment the following line
RUN npm install aws-lambda-ricRUN npm install# Grab a fresh slim copy of the image to reduce the final size
FROM node:12-buster-slim# Include global arg in this stage of the build
ARG FUNCTION_DIR# Set working directory to function root directory
WORKDIR ${FUNCTION_DIR}# Copy in the built dependencies
COPY --from=build-image ${FUNCTION_DIR} ${FUNCTION_DIR}ENTRYPOINT ["/usr/local/bin/npx", "aws-lambda-ric"]
CMD ["app.handler"]
  • Now let’s build image or download from dockerhub
docker build -t myfunction:latest .
docker pull bhargavshah86/myfunction:latest
  • Install RIE in local for local testing
mkdir -p ~/.aws-lambda-rie && \
curl -Lo ~/.aws-lambda-rie/aws-lambda-rie https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie && \
chmod +x ~/.aws-lambda-rie/aws-lambda-rie
  • Run our container image in local
docker run -d -v ~/.aws-lambda-rie:/aws-lambda -p 9000:8080 \
--entrypoint /aws-lambda/aws-lambda-rie \
myfunction:latest \
/usr/local/bin/npx aws-lambda-ric app.handler
  • Test our function using curl
curl -XPOST "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'

We have succesfully created image which support Lambda.

Now lets use same container image with Lambda using AWS console

  • Test our lambda in console.
  • Same logs can we found in AWS Cloudwatch Logs

Source : shahbhargav