AWSの様々なアーキテクチャ

Who am I ?
亀田治伸（Harunobu Kameda)
Facebook : facebook.com/harunobu.kameda/
Github : github.com/harunobukameda/
Sr. Evangelist
Amazon Web Services

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
アーキテクチャよもやま話

3
密結合
メンテナンス、
ビルド・テストが困難
Monolithic Architecture

システム組織
共に特異点が発生
システム特異点
組織特異点
が重なったときに
属人性は最大化する

マイクロサービス
アーキテクチャ

Frontend
Backend
API
API
イベント
API
イベント
API
モバイル
クライアント
クライアント
IoT
マイクロサービスとイベントドリブン

API
イベント
API
モバイル
クライアント
クライアント
IoT
マイクロサービスとイベントドリブン Serverless Computing

AWS のサービスを活用した疎結合の例３階層構造
ウェブサーバーはアプリサーバーと密結合
Web Server
App Server
ELB を挟んで疎結合に
Web Server
App Server
ELB
ELB は、 Auto Scaling を
組み合わせ、増減する
App Server を自動で
登録/解除可能
Web Server は単一の
ELB の DNS 名だけを
見てれば良い
(App Server は Web
Server にとってブ
ラックボックス)
スケールアウト/インする
たびに、Web Server の
設定ファイルの書き換え
が必要

VPC
Public subnet
Availability Zone
Private subnet
一般的なWEBサービスの構成図 2階層構造
VPC
Public subnet
Availability Zone
Availability Zone
Private subnet
ELB EC2 ElastiCache RDS

AWS のサービスを活用した非同期処理の例
Amazon SQS を挟んで Frontend と Backend を非同期かつ疎結合に
BackendもQueueの滞留に合わせてオートスケール
Frontend
Servers
ELB
Client
重たい処理は Backend
Servers に任せる
Sticky
Session
Backend
Servers
SQS キューから取得した
メッセージを元にバッチ
的に処理を実行していく
重たい処理は Backend で
非同期に行われるので、
Client へのレスポンスは
迅速に
Amazon SQS
Queue

単純なECサイトのシーケンス
クライアント WEB DB

非同期処理なECサイトのシーケンス
クライアント WEB DB
App
SQS

リアルタイムのレスポンスを要求しないシステム
IoT
センサーデバイス
Amazon
Kinesis

お客様事例：あきんどスシロー様
捨てていたデータをクラウドに送り、他のデータと合わせて分析することで、
今まで見えなかったことがデータとして可視化に成功。

Data Lake アーキテクチャ

データは企業の重要な資産に
常時インターネット
に接続
大量の構造化・
非構造化データ
機械学習
ディープラーニング

センサー
データ
非構造化ファイル
テキストファイル
RDBMS
データレイクの基本コンセプト
Amazon S3
• 99.9999999%のデータ堅牢性
• 容量は自動拡張
• 約2.3円/GB/月（オンライン）
• 約0.7円/GB（オフライン）
API
SQLクエリ実行
必要データの
取り出し
Amazon Athena AWS Glue
データのETL作業
整形（構造化）
より高価な
解析や
機械学習へ
Amazon
Redshift
Amazon
SageMaker

Amazon Greengrass
エッジコンピューティングモジュール

AWSの処理機能をデバイスの上に拡張
処理を
クラウドで実行
処理を
ローカルで実行
Moving to the edge
AWS Greengrass
開発、アップデート
最新モジュール
オフロード

エッジ推論
AWS Greengrass ML Inference
エッジ上での機械学習の
実行を簡単にする各種機能
を提供
• クラウドで学習したモデルを
簡単にデプロイ可能
• MXNet/TensorFlow/
Chainer をデバイスに簡単に
組み込める
• ローカルで機械学習の推論を
行うための実装例を提供
• GPU/FPGA活用が可能
モデルをGreengrassに出力
データ収集
モデル強化
推論を実行
AWS Cloud
for training

画像認識を多用途に活用する Vieureka プロジェクト
Amazon IoT Greengrass を活用して“進化するプラットフォーム”を実現
• まったく新しい AI/IoT
サービスの実現
• 小規模な組織で迅速かつ
低コストな開発を実施
• さまざまなプレイヤーが
参画できるプラット
フォームの構築
• 進化する AI/IoT プラット
フォームの実現
• さらなるイノベーションの
推進によるサービスの高度化
• ディープラーニングなどのよ
り高度な機械学習/分析基盤
の実装
「Vieureka プラットフォームを迅速かつ低価格で立ち上げたかった当社
にとって、AWS は最適な選択肢でした。今後も、お客様のニーズに合わ
せ Vieureka は日々アップデートしていきます。AWS の日々進化
する新サービスや機能に期待しています。」
宮崎秋弘氏
パナソニック株式会社ビジネスイノベーション本部
ビジョンセンシングプラットフォームプロジェクト CEO
<ご利用サービス>
AWS IoT
AWS IoT Greengrass
Amazon SageMaker Neo
Amazon DynamoDB
Amazon EC2/Amazon S3
導入前の課題導入効果と今後の展開
IoT + ML の導入事例

Database Freedom

A m a z o n
D y n a m o D B
キー
バリューインメモリグラフリレーショナル
A m a z o n
R D S
A m a z o n
Q L D B
元帳時系列
A m a z o n
T i m e s t r e a m
A m a z o n
A u r o r a
A m a z o n
D o c u m e n t D B
ドキュメント
A m a z o n
N e p t u n e
A m a z o n
E l a s t i C a c h e
A m a z o n
R D S f o r
V M W a r e E l a s t i C a c h e
f o r R e d i s
E l a s t i C a c h e
f o r M e m c a c h e d
A m a z o n
R e d s h i f t
データ
ウェアハウス移行
AWS Database Migration
Service
ワークロードに適した最適なデータベース選択

データの種類に応じて適切なデータストアを選択
サーバー
ローカル
ストレージ
サーバー
ローカル
ストレージ
共有
ストレージ
データベース
(RDBMS)
データベース
(NoSQL)
・ショッピングカート
・セッション情報
・ユーザ情報
・商品情報
・在庫情報
・商品画像データ
複数データストアの使い分けで効率を向上
“A one size fits all database
doesn't fit anyone”

グラフ
Amazon
QLDB
元帳時系列
Amazon
Timestream
Amazon
Neptune
高密度
結合
I n P r e v i e wN e w
時系列データ
の格納と操作
N e w
検証可能な
トランザクション
ログの提供

グラフデータベース
Graph

グラフ指向データベース
• データ間を相互に結びつけて
データ同士の関係をグラフという形で表す
• 複雑な関係性を表すのを得意とする
• SNSのフレンドの関連性等
多対多

ユースケース
SNSニュースフィードリコメンデーション不正検出
Friends
Use
Play
Like
Check in
Like
Connect
Read
Credit
card
Product
Email
address
Credit
card
Known
fraud
Uses
Paid
with
Uses
Paid
with
Paid with
Purchased
Approve
purchase?
Sport
Product
Purchased
Purchased
People
who also
follow sports
purchased…
Purchased
Knows
Knows
Do you
know…
Follows
Follows
Follows

サンプルデータ
ID Node Name Next Ptr
1 A NULL
2 B C
3 C A

サンプルデータその２
ID Node Name Next Ptr
1 A B
2 B C
3 C A
4 B A

ID Node Name Next Ptr Attr Num
1 A NULL NULL NULL
2 B C Like 1
3 C A Dislike 1
4 B A Like 2
5 B A Dislike 1
サンプルデータその3

選択指針
• 関連を探索するクエリ (トラバーサル)
• 短いクエリが大量に来る要件がある
• Amazon Neptune
• 数十億のリレーションシップを扱える
• ミリ秒台のレイテンシー
• グラフに最適化された、専用のグラフデータベースエンジン
• SPARQLとGremlinに対応

時系列データベース
Time-series

時系列データ
• 時間が唯一の主軸
• 特定の間隔で記録され続ける
• 時間の経過に伴う変化を測定
• リアルタイムの意思決定、警告等

選択指針
• 時系列データを扱うか
• 大量、粒度が小さい、すぐに分析したい
• 多数のソース (IoTデバイスなど) からの頻繁に送信されるか
• 一定の時間間隔で分析を実行したいか
• Amazon Timestream (Public Preview)
• RDB の 1/10 のコストで 1,000 倍のパフォーマンス
• 一日あたり数兆規模のイベントに対応
• 挿入とクエリを異なる処理階層で実行し、競合を解消

台帳データベース
Ledger

Basics of Block Chain
ビザンチン耐性
イミュータブルトランザクション

通常のオンラインバンキング
1:N取引であり銀行が
TrustAnchor
TrustAnchorへの攻撃が
成功すれば
ハッキング可能
高いセキュリティが必要
メンテナンス、障害による
ダウンタイムが発生

BlockChain の P2Pネットワーク
攻撃者は複数のノードを一度に攻撃しデータを
書き換える必要がある
→不可能。高セキュリティ
DNSやCDN(のEdge）と同じように、すべての
ノードが一度に停止することはない
→ゼロダウンタイムの実現
ビザンチン耐性

Block [Chain]
x x
x x
x x

台帳データベース
• データの変更履歴はイミュータブル
(変更や削除が不可能)
• 意図しない変更が発生していないことを
暗号技術で検証
C | H
J

選択指針
• 履歴の追跡と変更管理
• 完全で検証可能な変更履歴を長期間維持したい
• 管理者でも変更履歴を改ざんできないことを保証したい
• Amazon Quantum Ledger Database
• スケーラブルで完全
• 検証可能なトランザクション
• データの変更全てを追跡可能

データ構造
ID Manufacturer Model Year VIN Owner
1 Tesla Model S 2012 123456789 Robert Dennison
History
Current
INSERT… UPDATE… DELETE… UPDATE… UPDATE… UPDATE…
SEQUENCE
NUMBER: 789
SEQUENCE
NUMBER: 790
SEQUENCE
NUMBER: 791
SEQUENCE
NUMBER: 793
SEQUENCE
NUMBER: 792
SEQUENCE
NUMBER: --
Journal
元帳
データ Amazon
Quantum
Ledger Database
ID Version Start Manufacturer Model Year VIN Owner
1 0 7/16/2012 Tesla Model S 2012 123456789 Traci Russell
1 1 8/03/2013 Tesla Model S 2012 123456789 Ronnie Nash
1 2 9/02/2016 Tesla Model S 2012 123456789 Robert Dennison

1
Tracy buys a car on Aug 3, 2013
Journal CurrentDMV Scenario
History
Immutability
ID Version Manufacturer Model Year VIN Owner Date of
Purchase
1 0 Tesla Model S 2012 123456789 Traci
Russell
8/3/2013
Purchase
Russell
9/10/2014

1
2
Tracy sells car to
Ronnie on Sept 10, 2014
Immutability
Purchase
Russell
8/3/2013
1 1 Tesla Model S 2012 123456789 Ronnie
Nash
9/10/2014
Purchase
Nash
9/10/2014
History

1
2
Tracy sells car to
Ronnie on Sept 10, 2014
3
Ronnie’s car gets in an
accident and gets totaled
Purchase
Purchase
Russell
8/3/2013
Nash
9/10/2014
1 2 Deleted
Immutability
History
DELETE
DATE: 09/02/2016

数学的なデータ結合性
Journal
INSERT cars
ID:1
Manufacturer: Tesla
Model: Model S
Year: 2012
VIN: 123456789
Owner: Traci Russell
Metadata: {
Date:08/03/2013
}
H (T1) UPDATE cars
ID:1
Owner: Ronnie Nash
Metadata: {
Date:09/10/2014
}
H(T2) DELETE cars
ID:1
Metadata: {
Date: 09/02/2016
}
H(T3)
H(T1)
H(T1) +
Update
= H(T2)
H(T2) +
Update
= H(T3)

サーバー管理は
不要
利用状況に応じて
自動で拡張
利用していない
リソースは支払い不要
可用性や耐障害性は
実装済み
AWS Lambda
サーバーレスコンピューティング

仮想マシンコンテナ
コードと依存関係をまとめて
パッケージ化する
アプリケーション層の抽象化
1台のサーバーを
多数のサーバーに変換する
物理的なハードウェアの
抽象化
コンテナのメリット

水平スケーリングと垂直スケーリング
min
Max
(lambda default:1000)

完全ステートレス
セッション
処理ステータス
関数単位での権限制御関数単位のロギング
レイテンシ
リクエスト数
エラー
実行は最大９００秒
メモリ
（とそれに比例したCPU）
を割り当て
AWS Lambda 開発留意点

Lambdaによる言語の使い分け
アクセスがまばら： Python, Node.js（初動が早い）
常時アクセス、ないしは大量のCPU: Java, .NET, Go (初回実行コストが重たいが動作は高速）

LambdaによるDBの使い分け
Relational DB と NoSQL DB
Amazon VPC へのアクセス
Connection Pooling

リレーショナルデータ
• テーブル間でデータを分割
• 高度に構造化されたデータ
• キーを介して確立された
リレーションシップ(関係
性)
• データの完全性と一貫性
Patient
* Patient ID
First Name
Last Name
Gender
DOB
* Doctor ID
Visit
* Visit ID
* Patient ID
* Hospital ID
Date
* Treatment ID
Medical Treatment
* Treatment ID
Procedure
How Performed
Adverse Outcome
Contraindication
Doctor
* Doctor ID
First Name
Last Name
Medical Specialty
* Hospital Affiliation
Hospital
* Hospital ID
Name
Address
Rating
リレーション
多対 1

Amazon Relational Database Service (Amazon RDS)
6つのデータベースエンジンから選択できるマネージリレーショナルデータベース
容易な管理高可用性と永続性高スケール高速でセキュア
マネージドによる
運用自動化
データレプリケーション、
自動バックアップ、
スナップショット、
自動フェイルオーバー
コンピュートと
ストレージをスケール可能
SSDストレージのI/O保証、
保存時と通信時の暗号化

インターネット
リージョン
AZ AZ
インターネットゲートウェイ
Public
サブネット
AWS Lambda
基本サービス Amazon VPC

リージョン
AZ AZ
Public
サブネット
AWS Lambda
Elastic network
interface
2019年9月
パフォーマンス改善

リージョン
AZ AZ
Public
サブネット
AWS Lambda
Elastic network
interface
2019年12月
Proxy
Connection

Amazon DynamoDB
Key Value Store
Key-value

キーバリューストア (KVS)
• キーとバリュー（値）という単純な構造
• 超高速なパフォーマンス
• RDBMSに比べ読み書きが高速
Key1 Value1
Key2 Value2
Key3 Value3
1 対 1

選択指針
• スケーラビリティが求められる
• レスポンスタイム数ミリ秒が求められる
• シンプルなクエリ
• Amazon DynamoDB
• マルチリージョンマルチマスター構成
• 規模に関係なく、数ミリ秒のレスポンス
• 1 日に 10 兆件以上のリクエスト処理可能
• 毎秒 2,000 万件を超えるリクエストをサポート

AWSの様々なアーキテクチャ

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a AWSの様々なアーキテクチャ

Similar a AWSの様々なアーキテクチャ (20)

Más de Kameda Harunobu

Más de Kameda Harunobu (20)

AWSの様々なアーキテクチャ