Forem: Nutchanon Leelapornudom

Visualising your Amazon DynamoDB data with Amazon QuickSight

Nutchanon Leelapornudom — Tue, 22 Mar 2022 15:25:57 +0000

Please noted that this content is translated from Thai language on this Blog because it has high demand for implementing this solution in real life.

Table of Content

Introduction
Architecture Diagram
Cost Estimation
Step 1: Prepare AWS Services
Step 2: Create Amazon Athena data source
Step 3: Test query on your data in DynamoDB via Amazon Athena
Step 4: Connect Amazon QuickSight and Amazon Athena with Federated Query
Step 5: Create QuickSight dataset of DynamoDB via Athena
Step 6: Create QuickSight analyse from DynamoDB dataset
Conclusion

Introduction

In modern application, NoSQL databases are used widely in the organisation, including Amazon DynamoDB, Amazon DocumentDB, Apache HBase, and so on, which each of them has their own query language. However, there is a demand that want to visualise those data in form of graphs for business purpose.

AWS has Amazon QuickSight, a cloud-native business intelligent tool that help you to create a dashboard, visualise data, find insights, and has build-in Machine Learning capability. Amazon QuickSight support many native build-in data source, such as Amazon RDS, Amazon Aurora, Self-Managed MySQL, or 3rd party software.

But NoSQL databases, which mostly do not natively support SQL language, need to have data pipeline or data processing to store that data into somewhere else, for example Amazon S3, before visualising that data in the business intelligent tool.

In this blog, I will show you how to visualise data on Amazon DynamoDB, one of AWS NoSQL database, without moving the data out, and natively update the data in near-real time on Amazon QuickSight.

Architecture Diagram

Cost Estimation

Pricing for Storage and Read Capacity Unit (RCU) of Amazon DynamoDB
Pricing for Data Scan of Amazon Athena
Pricing for User and SPICE of Amazon QuickSight
Pricing for Storage of Amazon S3

ℹ️ Info: It might has a bit additional price for AWS Lambda and Data Transfer.

Step 1: Prepare AWS Services

Get started at Amazon Athena console, the engine version 2 is required, and prepare S3 Result Data bucket (e.g. nutchanon-athena-query-results).
Create an Amazon S3 bucket for Spill Bucket Data of Athena.
Go to Amazon QuickSight console - Setting Up for Amazon QuickSight.
Prepare Amazon DynamoDB table with the sample data (e.g.quicksight-ddb).

ℹ️ Info: if you do not have the data in DynamoDB for testing, please check วิธีการนำข้อมูล CSV จาก Amazon S3 เข้า Amazon DynamoDB (English translation is required)

Step 2: Create Amazon Athena data source

Create new data source from "Connect data source".
Choose "Query a data source" and "Amazon DynamoDB".
Choose "Configure new AWS Lambda function" for creating Lambda Connector.
Choose "SpillBucket", "AthenaCatalogName" and confirm "Custom IAM Roles", and then click "Deploy". The system will automatically create AWS CloudFormation for Lambda Connector.
Go back to choose Lambda Connector that you just created (might need a refresh), then provide the name of the catalog.

Step 3: Test query on your data in DynamoDB via Amazon Athena

Choose "Data Source" to be your newly created catalog, then the table of DynamoDB will be able to selected. Let's try to query via DynamoDB data via Athena.

Step 4: Connect Amazon QuickSight and Amazon Athena with Federated Query

Change QuickSight region to N.Virginia for edit configuration. Then go to "Manage QuickSight".
Allocate SPICE capacity. (What QuickSight SPICE is? Please see Managing SPICE Capacity
For "Security & Permission" choose "Add or Remove".
Choose Amazon Athena (If it already has chosen, please click twice times), then you will see the window of permission for Amazon S3. Next, choose Athena Spill and Result Data Bucket with write permission.
Change QuickSight region to Singapore (or your preferred region) for creating the dataset.
Go back to AWS Management Console and go to "IAM" Service. Then go to IAM Role.
Add policy at IAM Role "aws-quicksight-s3-consumers-role-v0", which the system automated generated when you grant S3 permission in QuickSight. Add "inline policy" name "InvokeAthenaFedereted" by follow JSON document as below.

⚠️ Please change "aws_account_id" and Lambda Function name that you created in step 2 ("AthenaCatalogName").

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "InvokeAthenaFedereted",
            "Effect": "Allow",
            "Action": "lambda:InvokeFunction",
            "Resource": "arn:aws:lambda:ap-southeast-1:<aws_account_id>:function:dynamocatalog"
        }
    ]
}

Step 5: Create QuickSight dataset of DynamoDB via Athena

Create dataset from Athena Data Source with the connection name, e.g."athena-dynamodb".
Choose catalog name that you created in step 2, and the table.
Choose to create from SPICE.
Wait until the data is imported into SPICE.
Change data type of each column appropriately for the data calculation and filtering in the future.

Step 6: Create QuickSight analyse from DynamoDB dataset

You can create analyse and dashboard directly from DynamoDB data.

ℹ️ Info: Changing the data type of dataset directly affect how to do calculation on graphs.

Conclusion

Amazon QuickSight can connect to non-directly support data source via Amazon Athena Federeted Query, which allow you to expand the functionality of building graph on many data source. By using Amazon Athena Federeted Query, you can even expand to NoSQL databases on AWS, such as Amazon DynamoDB, Amazon DocumentDB, or Amazon OpenSearch Service.

This solution will help to you easily build dashboard or visualise data on Amazon QuickSight without data movement or need to build data pipeline platform. Also, the data that show in the dashboard will be refreshed in near real-time based-on the source of data as well.

Reference

[1] https://aws.amazon.com/blogs/big-data/accessing-and-visualizing-data-from-multiple-data-sources-with-amazon-athena-and-amazon-quicksight/
[2] https://aws.amazon.com/blogs/big-data/query-any-data-source-with-amazon-athenas-new-federated-query/

ตัวอย่างการนำข้อมูล CSV จาก Amazon S3 เข้า Amazon Elasticsearch Service

Nutchanon Leelapornudom — Thu, 07 Oct 2021 08:10:19 +0000

สารบัญ (Table of Content)

บทนำ
แผนผังของระบบ
การประเมินราคาเบื้องต้น
ข้อจำกัดของตัวอย่างที่ควรรู้
ขั้นตอนที่ 1: นำข้อมูลตัวอย่างเข้า Amazon S3
ขั้นตอนที่ 2: สร้าง Amazon Elasticsearch Service domain
ขั้นตอนที่ 3: สร้าง AWS Cloud9 และเตรียม configuration
ขั้นตอนที่ 4: แก้ไข application configuration ให้พร้อมกับการใช้งาน
ขั้นตอนที่ 5: Execute import code บน AWS Cloud9
ขั้นตอนที่ 6: ตรวจสอบข้อมูลที่ import ที่ Amazon Elasticsearch Service

บทนำ

หลาย ๆ ครั้ง ผู้ใช้งานมีความต้องการที่จะนำข้อมูล จากระบบฐานข้อมูลแบบตาราง (RDBMS) ซึ่งอยู่ในรูปแบบ CSV file นำเข้า (import) ไปยังระบบฐานข้อมูลแบบ NoSQL อย่างเช่น Amazon Elasticsearch Service เป็นต้น และผู้ใช้งานพบว่า Amazon Elasticsearch Service ไม่ได้มี feature อย่างเช่นการ import โดยตรง ทำให้ผู้ใช้งาน พบปัญหาเกี่ยวกับการเขียน application ขึ้นมาเอง และวิธีการกำหนดสิทธิต่าง ๆ

ในบทความนี้จะเป็นตัวอย่างของการนำข้อมูล CSV file เข้า Amazon Elasticsearch Service โดยมีวิธีการ รวมถึงตัวอย่าง code ที่ผู้ใช้งานสามารถนำไปปรับใช้ให้เหมาะสมกับข้อมูลที่ผู้ใช้งานต้องการได้อีกด้วย

แผนผังของระบบ (Architecture Diagram)

การประเมินราคาเบื้องต้น (Cost Estimation)

ราคา Cluster ของ Amazon Elasticsearch Service - Amazon Elasticsearch Service Pricing
ราคา Storage ของ S3 - Amazon S3 Pricing
(option 1) ราคาของ AWS Cloud9 Instance - AWS Cloud9
(option 2) ราคาเครื่องของ Amazon EC2 - Amazon EC2 Pricing

ℹ️ หมายเหตุ: อาจจะมีราคาอีกนิดหน่อยในส่วนของ Network ที่ยังไม่ได้รวม

ข้อจำกัดของตัวอย่างที่ควรรู้

CSV file จะต้องมี header อยู่ที่ row แถวแรกของ file
หากผู้ใช้เลือก Amazon EC2 ในการติดตั้ง application จะต้องทำการติดตั้ง Python Binary version 3.7 เป็นต้นไปด้วย แต่หากใช้ AWS Cloud9 จะทำการติดตั้งไว้ให้เรียบร้อยแล้ว
ผู้ใช้งานสามารถเลือกใช้งาน Internet Gateway (IGW) หรือ VPC S3 Gateway Endpoint สำหรับเชื่อมต่อระหว่าง Amazon S3 กับ Internal VPC services ได้
ในตัวอย่าง เป็นการเลือกติดตั้ง Amazon Elasticsearch Service บน VPC และเปิดการใช้งาน "Fine-grained Access Control" ผ่าน HTTP สำหรับ Username และ Password

ขั้นตอนที่ 1: นำข้อมูลตัวอย่างเข้า Amazon S3

Download ข้อมูลตัวอย่าง SaaS-Sales.csv
Upload ข้อมูลตัวอย่างขึ้น S3 (e.g. nutchanon-es-importer)

ขั้นตอนที่ 2: สร้าง Amazon Elasticsearch Service domain

สร้าง Amazon Elasticsearch cluster พร้อมกับปรับ configuration ด้านความปลอดภัยให้เหมาะสมตามนี้
- กำหนด access control policy ใน "Fine-grained Access Control" เพื่อให้ user สามารถเขียนข้อมูลใน index ที่กำหนดได้
- เลือก deploy บน VPC และกำหนด security group สำหรับให้ Cloud9 หรือ EC2

ขั้นตอนที่ 3: สร้าง AWS Cloud9 และเตรียม configuration

สร้าง AWS Cloud9 environment สำหรับใช้งาน
ตรวจสอบ version ของ python ผ่าน command line โดยคาดหวังว่าจะเจอ Python version 3.7+

python3 -V

ทำการ download code ตัวอย่างจาก Github:load-s3-to-es[1]

git clone https://github.com/nutchanon-l/load-s3-to-es.git

ทำการติดตั้ง Python packages สำหรับ pre-requisite ที่จำเป็นผ่าน

pip3 install -r load-s3-to-es/requirements.txt

ทำการสร้าง IAM Role สำหรับ AWS Cloud9 ให้สามารถดึงข้อมูลจาก Amazon S3 ด้วย IAM Policy ดังตัวอย่าง (อย่าลืมเปลี่ยน Amazon S3 Bucket)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ReadObject",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::nutchanon-es-importer",
                "arn:aws:s3:::nutchanon-es-importer/*"
            ]
        }
    ]
}

ทำการ attach IAM role ไปยัง AWS Cloud9 Instance ผ่าน Amazon EC2 Console

ขั้นตอนที่ 4: แก้ไข application configuration ให้พร้อมกับการใช้งาน

แก้ไข config.json ไฟล์ (อย่าลืมเปลี่ยน Elasticsearch endpoint ด้วย)

{
    "s3": {
        "bucket": "nutchanon-es-importer",
        "prefix": "/"
    },
    "elasticsearch": {
        "url": ["https://vpc-nutcha-es-01-jozw26jnqvxcufjccrpcmiowam.ap-southeast-1.es.amazonaws.com"],
        "port": 443,
        "username": "<your_username>",
        "password": "<your_password>"
    }
}

แก้ไข metadata.json ไฟล์

{
    "index": {
        "es_index_as_filename": true,
        "es_index_name": ""
    },
    "data": {
        "headers": ["Row ID", "Order ID", "Order Date", "Date Key", "Contact Name", "Country", "City", "Region", "Subregion", "Customer", "Customer ID", "Industry", "Segment", "Product", "License", "Sales", "Quantity", "Discount", "Profit"],
        "id_field": "Row ID"
    }
}

ขั้นตอนที่ 5: Execute import code บน AWS Cloud9

ทำการรัน code ด้วย command ดังต่อไปนี้

cd load-s3-to-es
python3 s3-to-es.py

รอจนสุดท้ายขึ้นว่า

INFO: Bulk write succeed: 9994 documents

ขั้นตอนที่ 6: ตรวจสอบข้อมูลที่ import ที่ Amazon Elasticsearch Service

ตรวจสอบ index ที่ทำการ import จาก command ดังนี้ (อย่าลืมเปลี่ยน Elasticsearch endpoint ด้วย)

$ curl -u <your_username>:<your_password> -X GET "https://vpc-nutcha-es-01-jozw26jnqvxcufjccrpcmiowam.ap-southeast-1.es.amazonaws.com/_cat/indices?v&s=index"
health status index                uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   .kibana_1            cJyYpOa0RkOmvZHKCFAgMw   1   1          0            0       416b           208b
green  open   .opendistro_security 15W1rxD9TJOTfuld6W_p1g   1   2          9            4    172.9kb         59.6kb
green  open   saas-sales           KvhEecP2QvCO4UfThBki_A   5   1       9994            0      8.4mb          4.1mb

ทดสอบการค้นหาข้อมูลด้วย search API ผ่าน "saas-sales" index (อย่าลืมเปลี่ยน Elasticsearch endpoint ด้วย)

curl -u <your_username>:<your_password> -X GET "https://vpc-nutcha-es-01-jozw26jnqvxcufjccrpcmiowam.ap-southeast-1.es.amazonaws.com/saas-sales/_search"

แหล่งอ้างอิงอื่น ๆ

[1] https://github.com/nutchanon-l/load-s3-to-es

การแชร์ข้อมูลบน Amazon S3 ผ่าน Presigned URL

Nutchanon Leelapornudom — Tue, 28 Sep 2021 04:55:28 +0000

สารบัญ (Table of Content)

บทนำ
การประเมินราคาเบื้องต้น
ขั้นตอนที่ 1: ทำการสร้าง IAM User
ขั้นตอนที่ 2: กำหนด Amazon S3 Bucket Policy
ขั้นตอนที่ 3: สร้าง presigned URL ของ Amazon S3 ผ่าน AWS CLI
บทสรุป

บทนำ

โดยปกติแล้ว ทุก ๆ object ใน Amazon S3 จะเป็นลักษณะ private คือไม่สามารถแชร์ให้กับผู้ที่ไม่มีสิทธิเข้าถึงได้ แต่ในบางกรณี ผู้ใช้งานต้องการที่จะแชร์ข้อมูลใน Amazon S3 Bucket ให้ผู้ใช้งานทั่วไปสามารถเข้าถึงได้แบบ public ในช่วงระยะเวลาหนึ่ง ๆ แบบจำกัด

ทาง Amazon S3 มีความสามารถที่ให้ผู้ใช้งานสามารถสร้าง URL พิเศษ ที่มีสิทธิในการเข้าถึงข้อมูล Amazon S3 Bucket แบบ public เป็นการชั่วคราว เรียกว่า presigned URL โดยผู้ใช้งาน สามารถระบุเวลาที่จะให้หมดอายุได้อีกด้วย

การประเมินราคาเบื้องต้น (Cost Estimation)

ราคาการเรียกใช้งาน Amazon S3 - Amazon S3 Pricing

ขั้นตอนที่ 1: ทำการสร้าง IAM User

ทำการสร้าง IAM User โดยไม่ต้องกำหนด permission ใด ๆ ให้เลย

ขั้นตอนที่ 2: กำหนด Amazon S3 Bucket Policy

หากผู้ใช้งานยังไม่มี Amazon S3 Bucket ให้ทำการสร้างก่อน
ทำการกำหนดให้ IAM User ที่ต้องการให้สามารถอ่านข้อมูล object ใน Amazon S3 บน bucket ที่ระบุไว้ผ่าน Bucket Policy (อย่าลืมเปลี่ยน AWS_ACCOUNT_ID กับชื่อของ bucket
ผู้ใช้งานยังสามารถกำหนด policy เฉพาะส่วนของ prefix ที่ต้องการได้ เพื่อความปลอดภัยที่มากขึ้นได้

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "s3-presigned-read-only",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/presigned"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::nutchanon-thailand-shared/*"
        }
    ]
}

ขั้นตอนที่ 3: สร้าง presigned URL ของ Amazon S3 ผ่าน AWS CLI

ทำการติดตั้ง AWS CLI และสร้าง configuration profile ให้เรียบร้อย
จากนั้นสร้าง presigned URL ด้วย command ดังต่อไปนี้
- โดยผู้ใช้งานสามารถเลือก option "--expires-in" ในการกำหนดเวลาที่จะให้ presigned URL หมดอายุในหลักวินาทีได้อีกด้วย

aws s3 presign s3://${S3_BUCKET}/${S3_OBJECT} --expires-in ${S3_EXPIRE} --profile default

ผู้ใช้งานจะได้รับ presigned URL เป็น response ที่สามารถนำไปแชร์ให้กับผู้อื่นได้
นอกจากวิธีการสร้าง presigned URL ผ่าน AWS CLI แล้ว ผู้ใช้งานยังสามารถสร้างจาก AWS SDK ในภาษาต่าง ๆ ได้อีกด้วย

บทสรุป

ผู้ใช้งานสามารถเลือกที่จะแชร์ข้อมูลบน Amazon S3 ผ่าน Presigned URL ที่สามารถกำหนดให้ผู้อื่นเข้าถึงข้อมูลแบบชั่วคราวได้ โดยจะเป็นการเพิ่มความปลอดภัยให้กับข้อมูล และยังช่วยให้ผู้ใช้งานไม่ต้องจดจำสิทธิหรือ configuration ต่าง ๆ

นอกจากนี้การทำ presigned URL บน Amazon S3 ยังสามารถนำไปประยุกต์ใช้กับระบบ automation ได้หลากหลาย ทั้งการติดต่อกับ Amazon API Gateway ในกรณีที่ต้องการ upload/download ข้อมูลขนาดใหญ่ผ่าน API ได้อีกด้วย[3]

แหล่งอ้างอิงอื่น ๆ

[1] https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html
[2] https://github.com/nutchanon-l/s3-presigned-url
[3] https://aws.amazon.com/blogs/compute/uploading-to-amazon-s3-directly-from-a-web-or-mobile-application/

การทำ encrypt AWS Lambda Environment Variables ผ่าน AWS KMS

Nutchanon Leelapornudom — Tue, 21 Sep 2021 03:38:56 +0000

สารบัญ (Table of Content)

บทนำ
แผนผังของระบบ
การประเมินราคาเบื้องต้น
ขั้นตอนที่ 1: สร้าง AWS Lambda Function
ขั้นตอนที่ 2: สร้าง CMK บน AWS Key Management Service (KMS)
ขั้นตอนที่ 3.1: ทำการ encrypt Lambda Environment Variables ผ่าน AWS Management Console
ขั้นตอนที่ 3.2: ทำการ encrypt Lambda Environment Variables ผ่าน AWS CloudFormation
ขั้นตอนที่ 3.3: ทำการ encrypt Lambda Environment Variables ผ่าน AWS Serverless Application Model (SAM)
ขั้นตอนที่ 4: ทดลองเข้าใช้งานบน IAM User อื่น
บทสรุป

บทนำ

ในการใช้งาน AWS Lambda หลาย ๆ ครั้ง ผู้ใช้งานมักจะมีการเขียนข้อมูล parameter ที่ใช้ในการทำ Authetication กับระบบอื่น ๆ อย่าง Database Username/Password หรือ API Key บน Environment variables เพื่อให้ง่ายต่อการเรียกใช้งานหรือแก้ไข

แม้ว่าผู้ใช้งานจะมีการปกป้องข้อมูลเหล่านั้นด้วยการใช้ Secrets Key/Value Software อย่าง AWS Systems Manager Parameter Store หรือ AWS Secrets Manager บน template อย่าง AWS CloudFormation หรือ AWS Serverless Application Model (SAM) แต่อย่างไรก็ตาม เมื่อตัว AWS Lambda Function ถูก deploy ในระบบแล้ว จะพบว่าผู้ใช้งาน สามารถเข้าไปยังหน้า AWS Management Console แล้วมองเห็นค่าจริงบน Environment variables ได้อยู่ดี

ในบทความนี้ จะเป็นวิธีการนำ AWS Key Management Service (KMS) เข้ามาช่วยในการปกป้อง Environment variables ของ AWS Lambda ไม่ให้ผู้ใช้งานที่ไม่มีสิทธิในการเข้าถึงข้อมูลเหล่านี้ สามารถมองเห็นข้อมูลได้

แผนผังของระบบ (Architecture Diagram)

การประเมินราคาเบื้องต้น (Cost Estimation)

ราคาการเรียกใช้งาน Lambda - AWS Lambda Pricing
ราคาการเรียกใช้งาน KMS - AWS KMS Pricing

ขั้นตอนที่ 1: สร้าง AWS Lambda Function

กรณีที่มีการใช้ AWS Lambda อยู่แล้ว สามารถใช้ตัวเดิมได้เลย
เลือกตรวจสอบ Configuration -> Environment variables
- โดยจะพบว่า ปกติแล้วจะมองเห็นค่า key/value ของ Environment variables ในลักษณะของ plain text เลย แม้ว่าจะมีการเขียน configuration ของ CloudFormation[1] หรือ Serverless Application Model (SAM)[2] ให้ทำการอ่านข้อมูลจาก AWS Systems Manager - Parameter Store หรือ AWS Secrets Manager ก็ตาม
- ส่งผลให้เกิด security risk ที่เกิดขึ้นในระบบ โดยผู้ใช้งานอื่น ๆ สามารถเข้ามาดูข้อมูลใน AWS Lambda ได้ แม้ว่าจะมีการแยก IAM User ให้กับแต่ละผู้ใช้งานแล้วก็ตาม

ขั้นตอนที่ 2: สร้าง CMK บน AWS Key Management Service (KMS)

ให้ทำการตรวจสอบ Lambda Execution Role จาก Configuration -> Permission
สร้าง CMK ด้วย การเลือก Symmetric Key
ตั้งชื่อให้กับ CMK Key
เลือก key administrator (ในตัวอย่างเลือก IAM Role ของ account)
เลือก grant access ให้กับ IAM Role - โดยให้เลือกให้กับ Lambda Execution Role

ขั้นตอนที่ 3.1: ทำการ encrypt Lambda Environment Variables ผ่าน AWS Management Console

ไปที่ Lambda Function -> Configuration -> Environment variables แล้วเลือก "Edit" ที่ด้านขวาบน
จากนั้นให้เลือก Encryption Configuration แล้วเลือก CMK ที่สร้างมา

ℹ️ หมายเหตุ: จะเห็นว่ามีอีก option ให้ผู้ใช้งานสามารถเลือก Encryption in transit ได้ โดยจะเป็นการ encrypt value ของ Environment variables ให้อยู่ในรูป BASE64 โดยต่อให้ผู้ใช้งานมีสิทธิมองเห็นค่าของ Environment variables ก็จะไม่สามารถดูเนื้อข้อมูลจริงได้ แต่การนำข้อมูลไปใช้งานต่อ ต้องทำการ decrypt ผ่าน CMK และ BASE64 ก่อนด้วย[3]

ขั้นตอนที่ 3.2: ทำการ encrypt Lambda Environment Variables ผ่าน AWS CloudFormation

ตัวอย่าง AWS CloudFormation สำหรับ Lambda ที่ต้องใส่ให้ถูกต้องคือ "Role" และ "KmsKeyArn" (อย่าลืมแก้ไข AWS_ACCOUNT_ID)

AWSTemplateFormatVersion: '2010-09-09'
Description: Lambda function demo
Resources:
  HelloworldCFN:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: HelloworldCFN
      Runtime: python3.9
      Role: arn:aws:iam::<AWS_ACCOUNT_ID>:role/service-role/HelloWorld-role-nj8898dr
      Handler: index.lambda_handler
      Code:
        ZipFile: |
          import json

          def lambda_handler(event, context):
          # TODO implement
            return {
            'statusCode': 200,
            'body': json.dumps('Hello from Lambda!')
            }
      Environment:
        Variables:
          db_user: nutcha
          db_pass: nutchapass
      KmsKeyArn: arn:aws:kms:ap-southeast-1:<AWS_ACCOUNT_ID>:key/f102024f-3ab8-4da9-8e80-13e163aa5cf9

⚠️ คำเตือน: ในการระบุ Environment variables ใน AWS CloudFormation ในการใช้งานจริง ควรใช้คู่กับ AWS Systems Manager - Parameter Store หรือ AWS Secrets Manager แทนการฝัง (hard coded) ตัว username และ password ไว้ใน template

ขั้นตอนที่ 3.3: ทำการ encrypt Lambda Environment Variables ผ่าน AWS Serverless Application Model (SAM)

ตัวอย่าง AWS Serverless Application Model (SAM) สำหรับ Lambda ที่ต้องใส่ให้ถูกต้องคือ "Role" และ "KmsKeyArn" (อย่าลืมแก้ไข AWS_ACCOUNT_ID)

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Sample SAM Template for Lambda Helloworld
Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: HelloworldSAM
      CodeUri: hello_world/
      Handler: app.lambda_handler
      Runtime: python3.8
      Role: arn:aws:iam::<AWS_ACCOUNT_ID>:role/service-role/HelloWorld-role-nj8898dr
      KmsKeyArn: arn:aws:kms:ap-southeast-1:<AWS_ACCOUNT_ID>:key/f102024f-3ab8-4da9-8e80-13e163aa5cf9
      Environment:
        Variables:
          db_user: nutcha
          db_pass: nutchapass

⚠️ คำเตือน: ในการระบุ Environment variables ใน AWS Serverless Application Model (SAM) ในการใช้งานจริง ควรใช้คู่กับ AWS Systems Manager - Parameter Store หรือ AWS Secrets Manager แทนการฝัง (hard coded) ตัว username และ password ไว้ใน template

ขั้นตอนที่ 4: ทดลองเข้าใช้งานบน IAM User อื่น

ทดลองเข้าใช้งาน IAM User อื่น ที่แม้มีสิทธิ "AWSLambda_FullAccess" ก็จะไม่สามารถมองเห็นข้อมูลได้

บทสรุป

ผู้ใช้งานสามารถทำการปกป้องข้อมูลใน Environment variables ของ AWS Lambda ได้โดยการใช้ CMK บน AWS KMS โดยเฉพาะผู้ที่มีสิทธิ์ถอดรหัส (decrypt) เท่านั้นที่จะสามารถมองเห็นค่าใน Environment variables บน AWS Management Console ได้

โดยการเข้ารหัส (encrypt) นั้น ผู้ใช้งานสามารถทำได้ทั้งผ่าน AWS Management Console, AWS CloudFormation และ AWS Serverless Application Model (SAM)

แหล่งอ้างอิงอื่น ๆ

[1] https://aws.amazon.com/th/cloudformation/
[2] https://aws.amazon.com/serverless/sam/
[3] https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html#configuration-envvars-encryption

วิธีการสร้างกราฟข้อมูลจาก Amazon DynamoDB ด้วย Amazon QuickSight

Nutchanon Leelapornudom — Tue, 14 Sep 2021 03:20:25 +0000

สารบัญ (Table of Content)

บทนำ
แผนผังของระบบ
การประเมินราคาเบื้องต้น
ขั้นตอนที่ 1: เตรียมความพร้อมของ AWS Services
ขั้นตอนที่ 2: สร้าง Amazon Athena Data source
ขั้นตอนที่ 3: ทดลอง Query ข้อมูล DynamoDB ผ่าน Amazon Athena
ขั้นตอนที่ 4: เชื่อมต่อ Amazon QuickSight กับ Amazon Athena ด้วย Federated Query feature
ขั้นตอนที่ 5: สร้าง QuickSight Dataset จาก DynamoDB ผ่าน Athena
ขั้นตอนที่ 6: ทดลองสร้าง QuickSight Analyse จาก DynamoDB Dataset
บทสรุป

บทนำ

บางครั้งในองค์กร อาจจะมีความต้องการที่จะนำข้อมูลที่อยู่ในระบบฐานข้อมูล (database) อย่าง Amazon DynamoDB, Amazon DocumentDB, Apache HBase, และอื่น ๆ นำมาแสดงผลในรูปของกราฟ (graph) หรือสร้าง dashboard เพื่อวิเคราะห์ หา insights จากข้อมูล

ทาง AWS มี service ที่ใช้สำหรับทำ Business Intelligent (BI) tool ชื่อว่า Amazon QuickSight โดยสามารถใช้ service ในการสร้างกราฟหรือ dashboard จากฐานข้อมูลที่รองรับได้ เช่น Amazon RDS and Aurora, Amazon S3, Amazon Athena, และอื่น ๆ

แต่ Amazon QuickSight ไม่ได้มี native support ระบบฐานข้อมูลแบบ NoSQL เช่น Amazon DynamoDB, Amazon DocumentDB เป็นต้น ทำให้ผู้ใช้งานต้องทำการย้ายข้อมูลไปยังถังข้อมูลอื่น ๆ ซึ่งจะเกิด overhead ในส่วนของ data synchronization และ การจัดการ application ที่ใช้ย้ายข้อมูล

บทความนี้จะแสดงวิธีการเชื่อมต่อระหว่าง Amazon QuickSight ไปยังระบบฐานข้อมูลแบบ NoSQL เช่น Amazon DynamoDB โดยตรง โดยไม่มีการย้ายข้อมูลจากต้นทาง และทำให้ข้อมูลที่แสดงอยู่ในกราฟ มีความถูกต้องเหมือนข้อมูลต้นทาง

แผนผังของระบบ (Architecture Diagram)

การประเมินราคาเบื้องต้น (Cost Estimation)

ราคา Storage และ Read Capacity Unit (RCU) ของ DynamoDB - Amazon DynamoDB Pricing
ราคา Data Scan ของ Athena - Amazon Athena Pricing
ราคา User และ SPICE ของ QuickSight - Amazon QuickSight Pricing
ราคา Storage ของ S3 - Amazon S3 Pricing

ℹ️ หมายเหตุ: อาจจะมีราคาอีกนิดหน่อยในส่วนของ Lambda, Network ที่ยังไม่ได้รวม

ขั้นตอนที่ 1: เตรียมความพร้อมของ AWS Services

เริ่มใช้งาน Amazon Athena โดยต้องเป็น engine version 2 และกำหนด S3 Result Data bucket (e.g. nutchanon-athena-query-results)
สร้าง Amazon S3 สำหรับ Spill Bucket Data ของ Athena
เริ่มใช้งาน Amazon QuickSight โดยการ Setup - Setting Up for Amazon QuickSight
ตรวจสอบข้อมูลใน DynamoDB Table (e.g.quicksight-ddb) ว่าพร้อมสำหรับใช้งาน

ℹ️ หมายเหตุ: โดยหากสำหรับผู้ที่ยังไม่มีข้อมูล DynamoDB ที่ใช้ในการทดลองสามารถดูวิธีการนำข้อมูลตัวอย่างจาก CSV file เข้าใน DynamoDB Table ได้จาก วิธีการนำข้อมูล CSV จาก Amazon S3 เข้า Amazon DynamoDB

ขั้นตอนที่ 2: สร้าง Amazon Athena Data source

สร้าง Data Source ใหม่จาก "Connect data source"
เลือก "Query a data source" และ "Amazon DynamoDB"
เลือก "Configure new AWS Lambda function" เพื่อสร้าง Lambda Connector
เลือก "SpillBucket", "AthenaCatalogName" และยืนยัน "Custom IAM Roles" แล้วกด "Deploy" จากนั้นระบบจะทำการสร้าง Cloudformation สำหรับ Lambda Connector ให้
กลับมาเลือก Lambda Connector ที่เพิ่งสร้าง (อาจจะต้องกด refresh 1 ครั้ง) แล้วตั้งชื่อ catalog ให้เรียบร้อย

ขั้นตอนที่ 3: ทดลอง Query ข้อมูล DynamoDB ผ่าน Amazon Athena

เลือก "Data Source" เป็น catalog name ที่เพิ่งสร้าง หลังจากนั้นจะปรากฏข้อมูล table ของ DynamoDB ให้ทำการ select ข้อมูลดู

ขั้นตอนที่ 4: เชื่อมต่อ Amazon QuickSight กับ Amazon Athena ด้วย Federated Query feature

เปลี่ยน QuickSight region ไปที่ N.Virginia เพื่อแก้ไข configuration และเลือกไปที่ "Manage QuickSight"
จองข้อมูล SPICE Capacity ให้เรียบร้อย (อ่านว่า SPICE คืออะไร ได้จาก Managing SPICE Capacity
ในส่วนของ "Security & Permission" ให้เลือก "Add or Remove"
ให้เลือก Amazon Athena (หากเลือกอยู่แล้ว ให้กด 2 ครั้ง) จะมีหน้าต่างให้เลือก permission สำหรับ Amazon S3 ให้เลือก Athena Spill และ Result Data Bucket พร้อมกับ write permission
เปลี่ยน QuickSight region ไปที่ Singapore (หรือต้นทางที่ใช้งาน) เพื่อเตรียมพร้อมสำหรับการสร้าง Dataset
กลับไปที่หน้า AWS Management Console และไปยัง "IAM" Service และไปยัง IAM Role
เพิ่ม policy ที่ IAM Role "aws-quicksight-s3-consumers-role-v0" ที่ทางระบบจะสร้างให้อัตโนมัติหลังจาก grant S3 permission ใน QuickSight โดยทำการเพิ่ม "inline policy" ชื่อ "InvokeAthenaFedereted" ตาม JSON ด้านล่าง

⚠️ อย่าลืมแก้ "aws_account_id" และ Lambda Function name ที่กำหนดไว้ในขั้นตอนที่ 2 (ตัว "AthenaCatalogName")

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "InvokeAthenaFedereted",
            "Effect": "Allow",
            "Action": "lambda:InvokeFunction",
            "Resource": "arn:aws:lambda:ap-southeast-1:<aws_account_id>:function:dynamocatalog"
        }
    ]
}

ขั้นตอนที่ 5: สร้าง QuickSight Dataset จาก DynamoDB ผ่าน Athena

เลือกสร้าง Dataset จาก Athena Data Source โดยให้ตั้งชื่อ connection เช่น "athena-dynamodb"
เลือก catalog name ที่สร้างเอาไว้ (ชื่อเดียวกับที่สร้างไว้ในขั้นตอนที่ 2) และ table ให้เรียบร้อย
เลือกสร้างข้อมูลจาก SPICE
รอจน import data เข้าไปที่ SPICE ให้เรียบร้อย
เปลี่ยน data type ของแต่ละ column ให้เหมาะสมกับต้นทาง ซึ่งจะมีผลกับการนำไปสร้างกราฟต่อ ๆ ไป

ขั้นตอนที่ 6: ทดลองสร้าง QuickSight Analyse จาก DynamoDB Dataset

ทดลองสร้างกราฟ จะพบว่า สามารถสร้างกราฟต่าง ๆ จากข้อมูล DynamoDB ได้โดยตรง

ℹ️ หมายเหตุ: การเปลี่ยน data type ของแต่ละ column ใน dataset มีผลต่อการสร้างกราฟอย่างมาก

บทสรุป

Amazon QuickSight สามารถเชื่อมต่อโดยตรงกับระบบฐานข้อมูล หรือ data source ที่ไม่ได้ support โดยตรงผ่าน Amazon Athena Federeted Query ได้ โดยผู้ใช้งานสามารถสร้าง Lambda Connector ไปเชื่อมต่อระบบฐานข้อมูลอย่าง Amazon DynamoDB หรือ Amazon DocumentDB ได้

ซึ่งจะช่วยให้ผู้ใช้งาน สามารถสร้างกราฟจากข้อมูลต่าง ๆ ที่อยู่บนระบบฐานข้อมูลโดยไม่จำเป็นต้องย้ายข้อมูลไปที่อื่น ไม่จำเป็นต้องจัดการ application ที่ใช้สำหรับย้ายข้อมูล และยังได้ข้อมูลที่นำมาแสดงผลแบบ real-time อีกด้วย

แหล่งอ้างอิง

วิธีการนำข้อมูล CSV จาก Amazon S3 เข้า Amazon DynamoDB

Nutchanon Leelapornudom — Tue, 07 Sep 2021 05:16:20 +0000

สารบัญ (Table of Content)

บทนำ
แผนผังของระบบ
การประเมินราคาเบื้องต้น
ข้อจำกัดของตัวอย่างที่ควรรู้
ขั้นตอนที่ 1: นำข้อมูลตัวอย่างเข้า Amazon S3
ขั้นตอนที่ 2: สร้าง DynamoDB Table และเตรียม configuration
ขั้นตอนที่ 3: สร้าง Lambda Function และเตรียม configuration
ขั้นตอนที่ 4: Copy python code สำหรับ import ไปยัง Lambda
ขั้นตอนที่ 5: Execute Lambda Function
ขั้นตอนที่ 6: ตรวจสอบข้อมูลที่ import ที่ DynamoDB
วิธีการอื่น ๆ เพิ่มเติม

บทนำ

หลาย ๆ ครั้ง ผู้ใช้งานมีความต้องการที่จะนำข้อมูล จากระบบฐานข้อมูลแบบตาราง (RDBMS) ซึ่งอยู่ในรูปแบบ CSV file นำเข้า (import) ไปยังระบบฐานข้อมูลแบบ NoSQL อย่างเช่น Amazon DynamoDB เป็นต้น และผู้ใช้งานพบว่า Amazon DynamoDB ไม่ได้มี feature อย่างเช่นการ import โดยตรง ทำให้ผู้ใช้งาน พบปัญหาเกี่ยวกับการเขียน application ขึ้นมาเอง และวิธีการกำหนดสิทธิต่าง ๆ

ในบทความนี้จะเป็นตัวอย่างของการนำข้อมูล CSV file เข้า Amazon DynamoDB โดยมีวิธีการ รวมถึงตัวอย่าง code ที่ผู้ใช้งานสามารถนำไปปรับใช้ให้เหมาะสมกับข้อมูลที่ผู้ใช้งานต้องการได้อีกด้วย

แผนผังของระบบ (Architecture Diagram)

การประเมินราคาเบื้องต้น (Cost Estimation)

ราคา Storage, Write Capacity Unit (WCU) และ Read Capacity Unit (RCU) ของ DynamoDB - Amazon DynamoDB Pricing
ราคา Storage ของ S3 - Amazon S3 Pricing
ราคา Invocation ของ Lambda - AWS Lambda Pricing

ℹ️ หมายเหตุ: อาจจะมีราคาอีกนิดหน่อยในส่วนของ Network ที่ยังไม่ได้รวม

ข้อจำกัดของตัวอย่างที่ควรรู้

CSV file จะต้องมี header อยู่ที่ row แถวแรกของ file
การกำหนด partition key ของ DynamoDB จะต้องชื่อตรงกับ column header name ที่อยู่ใน file แบบ case-sensitive (ตัวเล็กตัวใหญ่มีผล)
Lambda resource และ timeout configuration ควรปรับเปลี่ยนให้เหมาะสมกับขนาดของข้อมูล
IAM Policy ของ Lambda Execution Role ควรกำหนดให้เหมาะสม เมื่อนำไปใช้งานจริง

ขั้นตอนที่ 1: นำข้อมูลตัวอย่างเข้า Amazon S3

Download ข้อมูลตัวอย่าง SaaS-Sales.csv
Upload ข้อมูลตัวอย่างขึ้น S3 (e.g. nutchanon-ddb-importer)

ขั้นตอนที่ 2: สร้าง DynamoDB Table และเตรียม configuration

สร้าง DynamoDB Table ชื่อ "quicksight-ddb" โดยมี parition key ชื่อ "Row ID" (ตัวเล็กตัวใหญ่ มีผลต่อข้อมูลตัวอย่าง) และปรับ capacity mode เป็น On-Demand

ขั้นตอนที่ 3: สร้าง Lambda Function และเตรียม configuration

สร้าง Lambda Function ด้วย python 3.9 (e.g. ddb-csv-importer)
ปรับ Lambda resource และ timeout configuration ให้เป็น 256MB และ timeout 15 นาที
จากนั้นเพิ่ม permission ให้ Lambda Execution Role สามารถอ่านข้อมูลจาก S3 และเขียนข้อมูลเข้า DynamoDB ได้ (DDBBatchWrite)

⚠️ สำหรับการทดสอบเท่านั้น ในการใช้งานต้อง จะต้องมีการระบุ IAM policy ให้ restrict เฉพาะเท่าที่ใช้งานเท่านั้น

ขั้นตอนที่ 4: Copy python code สำหรับ import ไปยัง Lambda

Copy Python Lambda code ตามด้านล่าง แล้วอย่าลืมเปลี่ยน configuration "s3_csv_bucket", "s3_csv_data", "ddb_table_src" ให้เป็นของผู้ใช้งานด้วย

import boto3
import os
import json
import csv
import codecs
import json

s3 = boto3.client('s3')
ddb = boto3.resource('dynamodb')
s3_csv_bucket = "nutchanon-ddb-importer" # Source Amazon S3 bucket
s3_csv_data = "SaaS-Sales.csv" # Source Amazon S3 object file
ddb_table_src = "quicksight-ddb" # Target Amazon DynamoDB Table

def lambda_handler(event, context):
    # get data
    obj = s3.get_object(Bucket= s3_csv_bucket, Key= s3_csv_data)

    # json data
    ddb_data = []
    for rows in csv.DictReader(codecs.getreader("utf-8-sig")(obj[u'Body'])):
        ddb_data.append(rows)

    # define dynamodb table
    ddb_table = ddb.Table(ddb_table_src)

    # batch write data to dynamodb table
    with ddb_table.batch_writer() as batch:
        for item in ddb_data:
            batch.put_item(Item=item)

    return None

ขั้นตอนที่ 5: Execute Lambda Function

รัน execute บน Lambda function ด้วย test event ใด ก็ได้ รอจน return success

ขั้นตอนที่ 6: ตรวจสอบข้อมูลที่ import ที่ DynamoDB

ตรวจสอบข้อมูลใน DynamoDB Table ด้วย "Give live item count"

วิธีการอื่น ๆ เพิ่มเติม

ทาง AWS Blog เองก็มีจะวิธีการในการ import ข้อมูลจาก Amazon S3 ไปยัง DynamoDB รวมถึงตัวอย่าง code ที่สามารถใช้งานได้ ดังต่อไปนี้
1. Creating a scalable serverless import process for Amazon DynamoDB
2. Github: S3-to-DynamoDB importer

10 วิธีลด Cost ในการใช้งาน Elasticsearch บน AWS

Nutchanon Leelapornudom — Wed, 01 Sep 2021 16:24:24 +0000

สารบัญ (Table of Contents)

0. บทนำ
1. ลบข้อมูลที่ไม่จำเป็น
2. จำแนกข้อมูลที่ไม่เกี่ยวข้องกัน แบ่งออกเป็นหลาย ๆ Index
3. กำหนด Data Lifecycle Management Policy
4. รวบรวม Elasticsearch หลาย ๆ cluster ในองค์กร ให้เหมาะสม
5. Right Sizing Elasticsearch Servers
6. ไม่ใช้ dedicated master nodes ถ้า cluster ไม่ได้สำคัญ หรือไม่ใหญ่พอ
7. ซื้อ Reserved Instance (RI)
8. ย้ายมาใช้ Amazon Elasticsearch Service เพื่อลด maintenance และ Data Transfer Inter-AZ Cost
9. เปลี่ยน Instance Type เป็น Graviton เพื่อ price/performance ที่ดีกว่า
10. ใช้พระเอก/นางเอก UltraWarm และ Cold Storage features บน Amazon Elasticsearch Service

บทนำ

Elasticsearch เป็น Search Engine NoSQL Database ที่มีการใช้งานเป็นวงกว้างและหลากหลาย ไม่ว่าจะเป็นการใช้งานการทำ Operational Logging, Log Analytics, การทำ Catalog Search หรือการทำ Index Table Searching ล้วนแล้วแต่เป็นการใช้งานที่จำเป็นต่อองค์กร และมักจะส่งผลให้เกิดค่าใช้จ่าย (cost) บน Elasticsearch cluster/servers ที่หลาย ๆ บริษัทอยากที่จะลดค่าใช้จ่ายในส่วนนี้ลง

สำหรับวิธีเบื้องต้นในการลดค่าใช้จ่ายที่อยากจะมาแนะนำผู้ใช้งาน Elasticsearch ทั้งในส่วนที่เป็น self-managed (ติดตั้ง Elasticsearch software เอง บน IaaS อย่าง Amazon EC2) หรือจะเป็น AWS managed service อย่าง Amazon Elasticsearch Service

1. ลบข้อมูลที่ไม่จำเป็น

สำหรับข้อแรก ที่ดูเหมือนจะทำง่ายแต่จริง ๆ แล้วทำยาก แต่รู้ไหมว่านี่คือวิธีที่ได้ผลที่สุดในการลดค่าใช้จ่าย Elasticsearch เนื่องด้วย mindset ส่วนใหญ่เวลามีการใช้งาน Elasticsearch โดยเฉพาะ Logging use case แล้ว มักจะเกิดเหตุการณ์ "เก็บ ๆ ไปก่อน ใช้ไม่ใช้ไม่รู้ แต่สักวันอาจจะได้ใช้" ส่งผลให้เกิดค่าใช้จ่ายมหาศาลที่องค์กรต้องแบกรับ

วิธีแก้คือ ถ้าไม่ค่อยได้ใช้ (อาจจะดูจาก Search/Bulk metrics ของแต่ละ Index) ให้ปรับเปลี่ยน mindset ของผู้จัดเก็บ เช่นเอาเฉพาะ ERROR log level มาเท่านั้น หรืออีกวิธีง่าย ๆ คือเปลี่ยนไปเก็บที่ storage engine อื่นที่ถูกกว่า อย่างเช่น Amazon S3 แล้วถ้าจะใช้ ค่อย load กลับไปเมื่อต้องใช้ หรือใช้ Amazon Athena ดึงข้อมูลแทน

2. จำแนกข้อมูลที่ไม่เกี่ยวข้องกัน แบ่งออกเป็นหลาย ๆ Index

การทำการใด ๆ ก็ตามบน Elasticsearch มักจะอยู่ในรูปแบบของ Index (คล้าย ๆ Table ใน Relational Database) เช่นการเพิ่ม replica shard, ปรับ schema, หรือการลบข้อมูล เพราะฉะนั้นหากจำแนกข้อมูลที่ไม่เกี่ยวข้องกันให้อยู่ตามแต่ละ index ได้ จะส่งผลให้จัดการข้อมูล เช่นทำ compress, ย้ายไปยัง tier ต่าง ๆ, หรือลบ ได้อย่างสะดวกและเหมาะสม

การจำแนกข้อมูลนี้ สามารถทำได้ในระดับ insight ที่รู้เนื้อหา เช่นแยก Logging ในแต่ละ Level -> INFO, ERROR, TRACE, DEBUG ออกจากกัน หรือแบ่งส่วน application, security, server logging แยกจากกัน หรือจะแบ่งตามวันเวลา เช่น daily, monthly เป็นต้น

แต่ข้อควรระวังคือ ในแต่ละ Elasticsearch Cluster จะมี best practice index/shard sizing recommendation อยู่ ให้พยายาม design ให้อยู่ในกรอบนี้ (เกินได้นิดหน่อย) เพื่อให้ cluster stable[1]

3. กำหนด Data Lifecycle Management Policy

Elasticsearch ใน version ใหม่ ๆ จะมาพร้อมกับ feature Index Management[2] ที่จะช่วยให้ผู้ใช้งานสามารถกำหนด policy ของ index ได้ ว่าจะให้ทำการ merge, ลด replica, ย้าย tier, ปรับ priority, หรือลบข้อมูลได้

ต่อเนื่องจากข้อ 2 จะทำให้ผู้ใช้งานสามารถกำหนด policy ข้อมูล ตามการใช้งานจริงได้ เช่นข้อมูลที่สำคัญอย่าง security logging ให้ลบหลังจาก 2 ปี แต่ข้อมูลไม่สำคัญเช่น INFO logging อาจจะลบทุก ๆ 3 วัน เป็นต้น

แต่หากใครที่ใช้ version เก่าหน่อย ก็ลองดูตัว open-source เช่น Curator ในการสร้าง policy ได้เช่นกัน

4. รวบรวม Elasticsearch หลาย ๆ cluster ในองค์กร ให้เหมาะสม

ในการใช้งาน Elasticsearch จริง ๆ แล้วผู้ใช้งานสามารถแบ่ง tenancy ของการเข้าถึงข้อมูลผ่าน Index และกำหนดสิทธิในการเข้าถึงข้อมูลผ่าน Authorization feature บน Fine-Gain Access Control ซึ่งแทนที่ผู้ใช้งานจะทำการสร้าง Elasticsearch cluster ขึ้นมาหลาย ๆ อัน (บางครั้งสร้างตาม application ด้วยซ้ำ) สามารถใช้งาน cluster เดียว ในรูปแบบของ share resource ได้ ซึ่งก็จะช่วยให้ผู้ใช้งาน utilize server resource ได้อย่างเต็มที่ และลดค่าใช้จ่ายในภาพรวมได้

5. Right Sizing Elasticsearch Servers

ในการใช้งาน Elasticsearch resource ก็จะมีความคล้ายกับ database ทั่ว ๆ ไป คือ เมื่อมีขนาดของข้อมูลเยอะขึ้น จำนวน resource (CPU, Memory, Disk) ที่ต้องการก็มากขึ้นตาม ทำให้บางครั้งเกิดการ over-provisioning บน Elasticsearch cluster ขึ้นมาได้ โดยหากผู้ใช้ทำการจัดการข้อมูล (ตามขั้นตอน 1,2,3,4) แล้วอาจจะพบว่า ข้อมูลมีขนาดลดลง ต่อมาก็จะเป็นการเปิดกว้างให้ผู้ใช้งานทำการปรับขนาดของ Elasticsearch server ให้เหมาะสม โดยอาจจะทำการลด size ของ server ให้เท่ากับที่ใช้งานในช่วง peak hour ได้

ซึ่งวิธีการปรับขนาดของ server ที่นิยมกันคือเพิ่ม (add) node ใหม่ที่มีขนาดเล็กกว่าเข้าไป แล้วค่อยถอด (remove) node ที่มีขนาดใหญ่กว่าออก เพื่อให้มี downtime น้อยที่สุดในการปรับเปลี่ยน server

ทาง AWS ก็มี guideline ให้กับผู้ใช้งานเบื้องต้นในการ sizing cluster ทั้งในส่วนของ Storage -> Calculating storage requirements และ Instance -> Choosing instance types and testing

6. ไม่ใช้ dedicated master nodes ถ้า cluster ไม่ได้สำคัญ หรือไม่ใหญ่พอ

การสร้าง Dedicated Master Node ถือเป็น Best Practice ใน production workload หรือ cluster ที่มีจำนวน shard และข้อมูลขนาดใหญ่ เพื่อ stability ของ cluster

แต่ไม่ใช่ทุก cluster จำเป็นที่จะต้องมี dedicated master node โดยทางผู้ใช้สามารถกำหนด node role ให้เป็นได้ทั้ง master และ data ได้ โดยตัว node นั้นจะทำงานทั้งสองงาน ซึ่งแน่นอนว่าก็จะใช้ resource มากกว่าปกติ และอาจจะไม่ stable เท่า แต่หากคิดถึงการใช้งาน non-production หรือ project ที่ไม่ได้ต้องการ 9'4 uptime ก็จะช่วยลดค่าใช้จ่ายได้อย่างมาก เพราะ dedicated master nodes ก็ต้องใช้อย่างน้อย ๆ 3 nodes ขึ้นไป ถึงจะเกิด stability ของ cluster

ตัว Amazon Elasticsearch Service ก็เปิดกว้างให้ผู้ใช้งานเลือกไม่มี dedicated master nodes ผ่าน "Custom" บน "Deployment Type" ด้วย

ในส่วนของการ sizing dedicated master node ทาง AWS ก็มี guideline ให้กับผู้ใช้งาน Dedicated master nodes

เฉพาะ AWS หรือ Amazon Elasticsearch Service

วิธีการต่อไปนี้ สามารถทำได้บน AWS หรือ Amazon Elasticsearch Service ได้อย่างง่ายเนื่องจากตัว service มีการดูแลและจัดการให้อัตโนมัติ แต่อย่างไรก็ตาม ผู้ใช้งานสามารถนำ idea ไปปรับใช้กับ self-managed ได้เช่นกัน

7. ซื้อ Reserved Instance (RI)

วิธีนี้ใช้ได้กับทั้ง EC2 และ Amazon Elasticsearch Service โดยการซื้อ Reserved Instance จะเป็นการ commit จำนวนปีที่ต้องการใช้งาน แลกกับส่วนลดที่ทาง AWS มอบให้กับผู้ใช้งาน ยกตัวอย่างเช่นใน ap-southeast-1 region ใช้ data node r5.xlarge.elasticsearch จะมีค่ายใช้จ่าย on-demand $0.448/hr แต่หากซื้อ RI 1 year no-upfront จะมีค่ายใช้จ่าย $0.309/hr ซึ่งลดลงมาประมาณ 31% เลย โดยไม่ต้องแก้ไขหรือปรับแต่ง Infrastructure ใด ๆ

8. ย้ายมาใช้ Amazon Elasticsearch Service เพื่อลด maintenance และ Data Transfer Inter-AZ Cost

การย้ายจาก self-managed มายัง Amazon Elasticsearch Service นอกจากจะลดปัญหาเรื่องการดูแล Elasticsearch ด้วยตัวเองแล้ว ยังช่วยให้ผู้ใช้งานไป focus กับงาน implementation และ automation แทน รวมถึงยังช่วยลดค่า Data Transfer ระหว่าง Availability Zone ที่เกิดขึ้นภายใน Elasticsearch cluster ได้อีกด้วย

อ่านเพิ่มเติมเรื่องการคิดค่า Data Transfer บน Amazon Elasticsearch Service ได้จาก Standard AWS data transfer charges

9. เปลี่ยน Instance Type เป็น Graviton เพื่อ price/performance ที่ดีกว่า

ตอนนี้ทาง AWS ได้มีการออก Instance Type แบบใหม่ที่นอกเหนือจาก Intel และ AMD ในชื่อ Graviton (m6g, r6g, c6g) ซึ่งจะมีค่าใช้จ่ายที่ถูกกว่าและมี performance ที่ดีขึ้น ในจำนวน CPU และ Memory ที่เท่าเดิม โดยตอนนี้ตัว Graviton ได้รองรับ Amazon Elasticsearch Service เรียบร้อยแล้ว โดยผู้ใช้งานสามารถเปลี่ยนมาใช้งาน Graviton Instance Type โดยไม่ต้องแก้ไข application หรือทำ data migration

ตัวอย่างเช่น หากเดิมมีการใช้งาน r5.2xlarge.elasticsearch (8 vCPU, 64GiB) ที่มีค่าใช้จ่าย On-Demand อยู่ที่ $0.897/hr แต่หากเปลี่ยนไปใช้งาน r6g.2xlarge.elasticsearch (8 vCPU, 64GiB เท่าเดิม) ที่มีค่าใช้จ่าย On-Demand อยู่ที่ $0.807/hr ซึ่งจะเห็นว่าถูกกว่าราว ๆ 10%

แต่มีข้อแม้ว่า จะต้องทำการ upgrade Amazon Elasticsearch Service ไปที่อย่างน้อย version 7.9 แล้วเท่านั้น[3]

10. ใช้พระเอก/นางเอก UltraWarm และ Cold Storage features บน Amazon Elasticsearch Service

หากพูดถึงการลด cost โดยเฉพาะ Logging หรือ Time-Series use cases การทำ Data Lifecycle Management (ข้อ 3) ถือเป็นจุดสำคัญที่ช่วยลด cost ขององค์กรอย่างมาก แต่หลาย ๆ ครั้งจะพบว่า การลบข้อมูลที่จำเป็นต้องใช้เร็วเกินไป อาจจะไม่ส่งผลดีนัก หรือผู้ใช้ไม่รู้ว่าข้อมูลนี้สามารถลบได้หรือไม่ ก็เกิดขาดความมั่นใจในการลบข้อมูล

ทาง Amazon Elasticsearch Service ได้มีการเพิ่ม feature Storage Tiering เข้ามาให้กับผู้ใช้งาน ซึ่งจะช่วยให้ผู้ใช้งานยังสามารถเก็บข้อมูล ค้นหาข้อมูล และสร้างกราฟจากข้อมูลบน data node และ storage ที่ถูกลง ผ่าน UltraWarm Storage โดยจะเป็นการย้ายข้อมูลส่วนที่เป็นข้อมูลเก่า, read-only ไปยังกลุ่ม nodes ที่มีราคาถูก โดยที่ยังสามารถ query หรือจัดการข้อมูลแบบเดิม, บน cluster เดิม, ไม่ต้องทำการแยก cluster ออกมาให้วุ่นวาย ซึ่งวิธีนี้จะช่วยให้ลดค่า cost ของ Elasticsearch cluster ได้อย่างมาก (สูงสุดราว ๆ 60-80% ขึ้นอยู่กับชนิดและขนาดของข้อมูล)

นอกจาก UltraWarm แล้ว ทาง Amazon Elasticsearch Service ยังได้เพิ่ม feature Storage Tiering ที่ถูกแบบพิเศษเข้ามา ในชื่อ Cold Storage ซึ่งจะช่วยให้ผู้ใช้งานเสียเงินเฉพาะค่า storage อย่างเดียว (ไม่เสียค่า compute เมื่อไม่ได้ใช้) แต่เมื่อใดก็ตามที่ผู้ใช้งานเรียกข้อมูลจาก Cold Storage ระบบจะค่อยคิดค่าใช้จ่ายตามเวลารันจริงที่เกิดขึ้นเท่านั้น

โดยทางผู้ใช้งานสามารถกำหนด policy ของการย้ายข้อมูลจาก Hot->UltraWarm->Cold ผ่าน Index State Management เพื่อให้เกิดการทำแบบ automation ได้ทันที

แต่มีข้อแม้ว่า จะต้องทำการใช้ Amazon Elasticsearch Service ที่มี version อย่างน้อย 6.8 สำหรับ UltraWarm[4] และ version อย่างน้อย 7.9 สำหรับ Cold[5] โดยต้องมีการใช้ dedicated master nodes ใน cluster ด้วย

แหล่งอ้างอิง

[1] https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/sizing-domains.html#aes-bp-sharding
[2] https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/ism.html
[3] https://aws.amazon.com/about-aws/whats-new/2021/05/amazon-elasticsearch-service-offers-aws-graviton2-m6g-c6g-r6g-r6gd-instances/
[4] https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/ultrawarm.html
[5] https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/cold-storage.html

ทำความรู้จัก Apache Cassandra และ Amazon Keyspaces

Nutchanon Leelapornudom — Tue, 31 Aug 2021 08:23:28 +0000

สารบัญ (Table of Contents)

บทนำ
Apache Cassandra คืออะไร
ข้อดีของ Apache Cassandra
Amazon Keyspaces (for Apache Cassandra) คืออะไร
ข้อดีของ Amazon Keyspaces (for Apache Cassandra)
บทสรุป
แหล่งอ้างอิง

บทนำ

สำหรับหลายท่านที่เพิ่งศึกษาการใช้งานระบบฐานข้อมูล (database) มักจะรู้จักระบบฐานข้อมูลแบบตารางเช่น MySQL, PostgreSQL, Oracle, Microsoft SQL Server ซึ่งระบบฐานข้อมูลเหล่านี้ จะถูกจัดอยู่ในหมวดหมู่ Relational Database Management Software (RDBMS)

แต่ในระยะหลัง ๆ เรื่องการทำงานแบบ Microservices Application ก็มักจะได้ยินระบบฐานข้อมูลประเภท NoSQL (Not-Only-SQL) ซึ่งเป็นระบบฐานข้อมูลที่ช่วยผู้ใช้งานในเรื่องของ ภาษาเข้าถึง (Query Language), การขยาย (Scale), การจัดเก็บ (Storage Engine), และความเร็ว (Performance)

โดยระบบฐานข้อมูลแบบ NoSQL มีหลายยี่ห้อมากมาย ทั้งที่เป็น Commercial บน open-source อย่างเช่น MongoDB, Redis, Elasticsearch หรือจะเป็น open-source หลัก ๆ อย่าง Apache Cassandra, Prometheus โดยแต่ละยี่ห้อก็จะมีความแตกต่างกันทั้งในแง่ของ ภาษาเข้าถึง, รูปแบบการขยาย, ลักษณะข้อมูลที่จัดเก็บ, และความเร็วในการเข้าถึงที่แตกต่างกัน

Apache Cassandra คืออะไร

Apache Cassandra คือระบบฐานข้อมูล open-source NoSQL แบบ distributed ที่มีจุดเด่นในเรื่องของการขยาย (scalability) และความพร้อมใช้ (high availability) อีกทั้งยังมีความเร็วสูง (performance) นอกจากนั้นยังรองรับเรื่องการ Linear-scale ที่สามารถใช้ได้กับ commodity hardware เพื่อช่วยกันทำงานให้เกิดประสิทธิภาพดียิ่งขึ้น [1]

การจัดเก็บของ Apache Cassandra จะอยู่ในรูปแบบ Column Family (CF) [2] โดยจะเป็นรูปแบบแถว ที่มี key/value ในแต่ละ column (คล้าย ๆ กับ row ใน table) และมีภาษาเข้าถึงชื่อว่า CQL (Cassandra Query Language) ที่มีการเขียนแบบ SQL-Like

โดยถ้าอ้างอิงจากเว็บไซต์ DB-Engines[3] ตัว Apache Cassandra ถือว่าเป็นระบบฐานข้อมูลที่ได้รับความสนใจ โดยอยู่ในลำดับที่ 11 (เมื่อก่อนเคยอยู่ Top 10 ด้วย) ซึ่งก็ถือว่าเกาะกลุ่มผู้นำ โดยจะช่วยให้ผู้ใช้งาน สามารถหาข้อมูล วิธีการใช้ หรือคำตอบของปัญหาที่เจอแต่ละวันจากเว็บไซต์ต่าง ๆ หรือใน community ได้ง่าย

ข้อดีของ Apache Cassandra

Masterless Architecture - Apache Cassandra เป็นระบบฐานข้อมูลที่ทำงานแบบ cluster โดยไม่มี master ซึ่งการสื่อสารกันของข้อมูลภายใน cluster จะทำงานแบบ peer-to-peer โดยใช้ gossip protocol ในการติดต่อกัน
Distributed and Linear Scale-out - Apache Cassandra ทำงานแบบ distributed database ผ่าน shard/token โดยแต่ละ node ใน cluster จะทำงานเฉพาะข้อมูลที่ตัวเองเป็นผู้ถือครองเท่านั้น และหากมีการออกแบบที่ถูกต้อง การเพิ่มจำนวน node ใน cluster จะเป็นการเพิ่มการรองรับโหลดแบบ linear scale ได้อีกด้วย (เช่น 10 nodes รับโหลดได้ 10,000 w/s หากขยายเป็น 20 nodes ก็จะรับโหลดได้ 20,000 w/s เป็นต้น)
Active-Active Multiple Clusters - Apache Cassandra รองรับการทำ architecture แบบหลาย cluster ได้ โดยสามารถเลือกที่จะเขียนข้อมูลที่ cluster ไหนก็ได้ อีกทั้งยังสามารถควบคุม data consistency ระหว่าง cluster ได้อีกด้วย ส่งผลให้เกิดการออกแบบ DC/DR ข้าม region ได้
Flexible for Data Consistency or Partition Tolerance - Apache Cassandra มีการออกแบบให้รองรับเรื่องการทำซ้ำ (replication) ของข้อมูลจากตัวระบบฐานข้อมูลเอง โดยผู้ใช้งานสามารถเลือก 3 copies หรือ N copies (แนะนำเป็นเลขคี่) แล้วแต่ผู้ใช้งานเอง ทำให้แม้ว่าจะเกิด node มีปัญหา ก็ยังสามารถกู้ข้อมูลคืนได้ และผู้ใช้งานยังสามารถกำหนดความถูกต้องของข้อมูลผ่าน Consistency Level ระหว่างอ่าน (read) หรือเขียน (write) ได้ โดยแลกกับความเร็ว (performance)

โดย Apache Cassandra มี keywords สำคัญ ๆ ที่ควรจะรู้ดังนี้

Node - เครื่องหรือ process ที่ทำงานระบบฐานข้อมูล โดยจะทำการทั้งการจัดเก็บ การประมวลผล และการพูดคุยเชื่อมต่อกันระหว่าง node ภายใน cluster
Cluster - กลุ่มของ node ที่ช่วยกันทำงานบนระบบฐานข้อมูล โดยการเชื่อมต่อจาก application จะเชื่อมต่อเข้ามาทำงานในระดับ cluster
Keyspace - Logical Isolation ของข้อมูล โดยเป็นส่วนที่สามารถแบ่งแยกกลุ่มของ table (คล้ายกับ database ใน RDBMS)
Replication Factor - ค่าทำซ้ำ (replication) ของข้อมูล โดยสามารถเลือกจำนวน copy ได้ เช่น 3,5,7 เป็นต้น โดยสามารถกำหนดในแต่ละ Keyspace ของแต่ละ "DC" ได้
Table - Schema ที่ใช้ในการจัดเก็บข้อมูล โดยมีการระบุ column name, data type รวมถึง Keys ต่าง ๆ เพื่อใช้ในการเข้าถึงข้อมูล (คล้ายกับ table ใน RDBMS)
Partition Key(s) - Column(s) ที่ระบุให้ทำการ shard ไปในแต่ละ node ของ cluster โดย partition key(s) เป็นสิ่งที่ require ในการทำ equal filtering เวลาเข้าถึงข้อมูล
Clustering Key(s) - Column(s) ที่ระบุให้ทำการเรียง (sort) ของข้อมูล ซึ่งจะสามารถเข้าถึงข้อมูลแบบ range filtering ได้
Primary Key - ส่วนประกอบของ Partition Key(s) กับ Clustering Key(s) ที่แสดงถึงความเป็น Unique ของ record ใด ๆ โดยหากมีการเขียนซ้ำที่ record ที่มี Primary Key เดียวกัน จะเป็นการ Upsert โดยอัตโนมัติ ซึ่งรูปแบบการจัดการ conflict จะเป็นลักษณะ Last-Write-Win
Consistency Level - กำหนดความถูกต้องของข้อมูล โดยสามารถกำหนดแยกกันระหว่างการเขียน (write) กับการอ่าน (read) ได้ โดยจะส่งผลทั้งเรื่องของ performance, availability ด้วย เช่น ONE, QUORUM, ALL, LOCAL_ONE, LOCAL_QUORUM เป็นต้น

ต่อมาเมื่อผู้ใช้งาน Apache Cassandra ใช้งานไปสักระยะนึงแล้ว มีการขยายจำนวน node ใหญ่ประมาณนึง ผู้ใช้งานมักจะพบปัญหาเรื่องการจัดการ การดูแล รวมถึงความรู้ความใจเชิงลึกของตัว software

การปรับ cassandra.yaml[4] - จำนวนของ configuration ที่สามารถปรับเปลี่ยนได้มีเยอะมาก ๆ และต้องใช้ expert ที่เข้าใจระบบค่อนข้างสูง ซึ่งจะส่งผลทั้งเรื่อง performance และ stability
การจัดการผ่าน Nodetool - ตัว software ของ Apache Cassandra จะมี tool ที่ใช้ในการจัดการ node ผ่าน Nodetool แต่การทำงานผ่าน Nodetool ส่วนใหญ่จะมีผลกับ node ที่ระบุเท่านั้น โดยหากต้องจัดการระดับ 20-100+ nodes จะต้องเสียเวลาทำ automation เพิ่มเติมด้วย
การดูแล compaction tasks - compaction เป็นเรื่องสำคัญที่ต้องดูแลเพราะจะส่งผลทั้งในแง่ของ performance และการ stream ของข้อมูลในการเพิ่ม/ลด node
การ replace dead node - day-to-day maintenance ที่ต้องทำเพื่อการแก้ไข node ที่มีปัญหา และต้องคอยดูแลไม่ให้เกิดการ stream ข้อมูลผิดพลาด
การ repair inconsistent data - ตัว Apache Cassandra เมื่อมีการทำงานไปสักพักจะเกิด data inconsistent ใน cluster โดยจะมี practice ที่ต้องทำการ full repair data ก่อนเกิด garbage collection ของข้อมูล (default 10 days)
การ monitor low-level - แม้ว่าส่วนใหญ่ตัว Apache Cassandra จะให้ metrics ผ่าน MBean หรือ Nodetool มา แต่การที่จะดูแลและเข้าใจ ต้องใช้ผู้เชี่ยวชาญที่เข้าใจ architecture และ configuration ค่อนข้างสูง

Amazon Keyspaces (for Apache Cassandra) คืออะไร

Amazon Keyspaces คือ Serverless Apache Cassandra–compatible platform ที่ให้ผู้ใช้งานสามารถใช้งาน service ได้ทันที โดยยังคงความสามารถต่าง ๆ ที่ตัว Apache Cassandra ทำได้ ทั้งในเรื่องของ Scalability, High Availability รวมถึงตัว Driver, Code และภาษาเข้าถึงอย่าง CQL

โดยคำว่า Serverless หมายความว่าทางผู้ใช้งานไม่ต้องทำการ provision ไม่ต้อง patch ไม่ต้องดูแล server, ไม่ต้องติดตั้ง (install), ดูแล (maintain), หรือจัดการ (operate) software อีกต่อไป

นอกจากนั้นยังเพิ่มเติมความสามารถอย่าง Data Encryption การทำ Backup และ Point-in-time Recovery[5]

ข้อดีของ Amazon Keyspaces (for Apache Cassandra)

Serverless on Apache Cassandra architecture - โดยหลัก ๆ แล้วข้อดีเรื่อง architecture ก็จะยังอยู่ครบทั้งเรื่องของ scalability, high availability, partition tolerance และผู้ใช้งานยังสามารถเลือก Consistency Level ได้เหมือนเดิม และมีส่วนเพิ่มเติมคือเรื่องของ Serverless Architecture ที่ช่วยให้ผู้ใช้งานไม่ต้องดูแล server ไม่ต้องติดตั้ง software ไม่ต้องจัดการ software รวมถึงรองรับ Mutliple Availability Zone ที่ช่วยเพิ่ม SLA ของ service ให้กับผู้ใช้งานอีกด้วย
คงความเป็น Apache Cassandra Compatibility - หากตัว application มีการติดตั้ง driver/client ที่ใช้กับ version 3.11.2 ได้ ก็จะยังสามารถใช้ตัวเดิม เชื่อมต่อ Amazon Keyspaces ได้เลย โดยไม่ต้องมีการติดตั้งใหม่[6] และยังรองรับภาษา CQL ในการอ่านและเขียนข้อมูลได้อีกด้วย ซึ่งหมายถึงผู้ใช้งานสามารถเลือกใช้ Apache Cassandra หรือ Amazon Keyspaces โดยไม่ต้องแก้ไข application เหมาะกับการโยกย้ายไปมาได้สะดวก แต่แน่นอน ว่านี่เป็น compatibility service แนะนำให้อ่านความแตกต่างในรายละเอียดได้บน Compare Amazon Keyspaces with Cassandra
เพิ่มเติมในส่วนของ Security และ Data Protection - ตัว Amazon Keyspaces มี default เป็น Data Encryption At-Rest และ security มุมอื่น ๆ อีกมากมาย ที่จะช่วยให้ผู้ใช้ตอบโจทย์เรื่อง Security and Compliance รวมถึงการจัดการ Backup/Restore ที่รองรับรูปแบบ Point-in-Time Recovery อีกด้วย
รองรับการใช้งานผ่าน Capacity แบบ Provisioned และ On-demand และการคิดเงินแบบ pay-as-you-go model - โดย Provisioned จะเป็นรูปแบบกำหนด throughput ที่ผู้ใช้งานจะสามารถ ทั้งในส่วนของการอ่านและเขียน (คล้ายซื้อค่า internet) หรือ on-demand ที่ให้ผู้ใช้งาน ใช้เท่าไหร่จ่ายเท่านั้น โดยทั้งสองแบบนั้นยังรองรับการทำ Auto-Scaling เพื่อให้มั่นใจได้ว่า ตัว service สามารถรองรับก็ load ที่เกิดขึ้นได้

บทสรุป

Apache Cassandra คือระบบฐานข้อมูลแบบ Distributed NoSQL ที่มีจุดเด่นในเรื่องของการทำ Scale-out Architecture, High Availability, และ Performance ที่สูง โดยผู้ใช้งานสามารถเลือกปรับ Data Consistency ให้เหมาะสมกับ Use Case ที่เลือกใช้ได้ และยังรองรับภาษา CQL (SQL-Like) ซึ่งจะช่วยให้ผู้ใช้งานไม่ต้องปรับตัวมากนัก

Amazon Keyspaces (for Apache Cassandra) คือ 1 ใน Database Services ที่ทาง AWS ให้บริการในรูปแบบ Serverless Apache Cassandra Compatibility Service ที่ช่วยให้ผู้ใช้งานสามารถใช้ driver/client เดิม รวมถึงภาษา CQL เดิมที่เคยใช้อยู่แล้ว นำมาใช้กับ Amazon Keyspaces ได้ทันที โดยทาง AWS ช่วยเรื่องของการจัดการ infrastructure, software, scaling ต่าง ๆ ให้ รวมถึงมีการเพิ่ม features บางส่วนเช่น security backup/restore และให้บริการในรูปแบบ pay-as-you-go model

แหล่งอ้างอิง

[1] https://cassandra.apache.org/
[2] https://en.wikipedia.org/wiki/Column_family
[3] https://db-engines.com/en/ranking
[4] https://github.com/apache/cassandra
[5] https://aws.amazon.com/keyspaces/
[6] https://docs.aws.amazon.com/keyspaces/latest/devguide/programmatic.drivers.html

แหล่งอ้างอิงรูปภาพ

[a] https://cassandra.apache.org/_/cassandra-basics.html