SlideShare a Scribd company logo
© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
~マイクロサービスアーキテクチャとアジャイル開発
2020.06.25
Amazon Web Services Japan K.K.
Senior Dev.Advocate
Harunobu Kameda
AWS の基本コンセプト
必要な時に、必要なだけ、低価格で
使用分のみ支払い 初期投資不要  低額の変動費
開発者は作業を阻害しない
ITインフラが必要
API経由で操作可能な
コンピュートリソースプール
メカニズム
Mechanism
自動化を実現させる一連のプロセス
インプットを連続的にアウトプットへ変換
メカニズムとは?
べき等性 スピード 付加価値
Infrastructure as Code
Infrastructure as Code (IaC)
• リソースはAPI経由でプロビジョニング
• 定義ファイルによる、効率化と自動化
• エラーやセキュリテイ違反の除去
https://ja.wikipedia.org/wiki/Infrastructure_as_Code
Cloud Computing
• 大規模化、共有リソースプールによる効率化
• データセンター、ネットワーク、ハードウェアの抽象化
• 多くのマネージドサービス
190を超えるサービス – Building Block
マイクロサービス
アーキテクチャ
9
密結合
メンテナンス、
ビルド・テストが困難
水平スケーリングは不可能
垂直スケーリングのみ
Monolithic Architecture
システム 組織
特異点が発生
属人性の最大化
© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
スピードと俊敏性に
こだわるための小規模
チーム
Two-Pizza Teams
小さくそれぞれ
が自律的に動け
る組織
何を作るかから
実行までのすべ
ての権限を持つ
主体性 と 自立性 を
重視
© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
実験 は早めに、頻繁に
© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
AWS が提供するソリューションの数々
コンピューティング
開発者用ツール
機械学習
ビジネスの
生産性
ストレージ
管理ツール
モバイルサービス
デスクトップと
アプリケーションの
ストリーミング
データベース
メディアサービス
AR(拡張現実)と
VR(バーチャルリアリティ)
IoT
マイグレーション
セキュリティ
アクセス権管理、法令遵守
アプリケーション
構築
ゲーム開発
ネットワーク &
コンテンツ配信
分 析
カスタマー
エンゲージメント
ブロックチェーン
ロボット工学
人工衛星
190+
フロントエンドアプリケーション
マイクロサービス
API
API
マイクロサービス
マイクロサービス
イベント
API
マイクロサービス
イベント
API
マイクロサービス
モバイル
クライアント
クライアント
IoT
マイクロサービスの概要図
Microservice化とその成果
= 6700万回/年のデプロイ
数千のチーム
× Microservices
× 継続的デリバリ
× 複数の環境
Monolithic Deploy Model
開発者
releasetestbuild
デリバリパイプラインアプリ
開発者 デリバリパイプラインサービス
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
Microservices Deploy Model
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
Microservices Deploy Model + IaC
開発者 デリバリパイプラインサービス
LB
共有
データソース
Blue / Green Deployment
DNS
Application v1
WEB APP
Application v2
WEB APP
Snapshot
@2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved
What is Cloud Native ?
リソースは伸縮可能
API 経由で操作
セッションをお腹に持たない
べき等性
Restful, Stateless
CI/CD
サーバレス
コンテナ
@2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved
クラウドネイティブ開発だから
アジャイルでOK
アジャイルだから
ドキュメントは
後回しでいこう
@2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
アジャイルソフトウェア開発宣言
@2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved
顧客へ提供しうる価値の最大化
アジャイルソフトウェアとクラウド
【価値の最大化】のみを目的とし
Legacy手法の変更を行う
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
Microservice/アジャイル開発とドキュメンテーション
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
マイクロサービスとAPI
疎結合なAPI連携のみで有機的に結合
APIへの改修、新規APIリリースは最大限の注意が必要
改修
リリース
リリース
ドキュメンテーション&レビュー
非改修 (ソース = ドキュメント ?)
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
と、いうことは・・・? つまり
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
と、いうことは・・・? つまり
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
と、いうことは・・・? つまり
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T
と、いうことは・・・? つまり
NITROSERVER
Management,
security, and
monitoring
Network Storage
Nitro Hypervisor
Nitro Controller
C5
Virtualization
Classic
virtualization
S E R V E R
C U S T O M E R I N S T A N C E S
X E N H Y P E R V I S O R
VPC
NETWORKING
EBS
STORAGE
LOCAL
STORAGE
MANAGEMENT
SECURITY +
MONITORING
Dom0
Classic
virtualization
S E R V E R
COMPLEXITY, OVERHEAD,
VIRTUALIZATION TAX
C U S T O M E R I N S T A N C E S
X E N H Y P E R V I S O R
VPC
NETWORKING
EBS
STORAGE
LOCAL
STORAGE
MANAGEMENT
SECURITY +
MONITORING
Dom0
Monolith Microservice
API
Virtualization
re:Invented
AWS
Nitro System
S E R V E R
C U S T O M E R I N S T A N C E S
X E N H Y P E R V I S O R
VPC
NETWORKING
EBS
STORAGE
LOCAL
STORAGE
MANAGEMENT
SECURITY +
MONITORING
Dom0
Classic
virtualization
N I T R O
C U S T O M E R I N S T A N C E S
X E N H Y P E R V I S O R
VPC
NETWORKING
EBS
STORAGE
LOCAL
STORAGE
MANAGEMENT
SECURITY +
MONITORING
Dom0
S E R V E R
P C I e B U S
Nitro:
Step 1
C3 インスタンス
N I T R O P C I e B U S
C U S T O M E R I N S T A N C E S
X E N H Y P E R V I S O R
VPC
NETWORKING
EBS
STORAGE
LOCAL
STORAGE
MANAGEMENT
SECURITY +
MONITORING
Dom0
S E R V E R
Nitro:
Step 2
C4 インスタンス
N I T R O P C I e B U S
C U S T O M E R I N S T A N C E S
X E N H Y P E R V I S O R
VPC
NETWORKING
EBS
STORAGE
LOCAL
STORAGE
MANAGEMENT
SECURITY +
MONITORING
Dom0
S E R V E R
Nitro:
Step 3
N I T R O H Y P E R V I S O R
N I T R O P C I e B U S
C U S T O M E R I N S T A N C E S
VPC
NETWORKING
EBS
STORAGE
LOCAL
STORAGE
MANAGEMENT
SECURITY +
MONITORING
Nitro:
S E R V E R
μEMU
etc.
Step 4
ENA
C5 インスタンス
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
API
マイクロサービス
イベント
API
マイクロサービス
モバイル
クライアント
クライアント
IoT
マイクロサービスとイベントドリブン Serverless Computing
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
AWS のサービスを活用した疎結合の例 3階層構造
ウェブサーバーはアプリサーバーと密結合
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 の設定
ファイルの書き換えが必要
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
AWS のサービスを活用した非同期処理の例
Amazon SQS を挟んで Frontend と Backend を非同期かつ疎結合に
BackendもQueueの滞留に合わせてオートスケール
Frontend
Servers
ELB
Client
重たい処理は Backend
Servers に任せる
Sticky
Session
Backend
Servers
SQS キューから取得した
メッセージを元にバッチ的
に処理を実行していく
重たい処理は Backend で
非同期に行われるので、
Client へのレスポンスは迅
速に
Amazon SQS
Queue
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
単純なECサイトのシーケンス
クライアント WEB DB
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
非同期処理なECサイトのシーケンス
クライアント WEB DB
App
SQS
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
リアルタイムのレスポンスを要求しないシステム
IoT
センサーデバイス
Amazon
Kinesis
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
お客様事例:あきんどスシロー様
捨てていたデータをクラウドに送り、他のデータと合わせて分析することで、
今まで見えなかったことがデータとして可視化に成功。
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
データベースの選択
• AWS では多様な
データベースの選択肢
• ワークロードに応じて
最適な選択が可能
Purpose built
The right tool for
the right job
https://www.allthingsdistributed.com/2018/06/purpose-built-databases-in-aws.html
適材適所の選択
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
データの種類に応じて適切なデータストアを選択
サーバー
ローカル
ストレージ
サーバー
ローカル
ストレージ
共有
ストレージ
データベース
(RDBMS)
データベース
(NoSQL)
・ショッピングカート
・セッション情報
・ユーザ情報
・商品情報
・在庫情報
・商品画像データ
複数データストアの使い分けで効率を向上
“A one size fits all database
doesn't fit anyone”
VPC
Public subnet
Availability Zone
Private subnet
一般的なWEBサービスの構成図 2階層構造
VPC
Public subnet
Availability Zone
Availability Zone
Private subnet
ELB EC2 ElastiCache RDS
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
従来のエンタープライズ DB システム
アプリ
オンライン
トランザクション
ETLツール
分析
BIツールOLTP DB OLAP DB
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
万能のデータベース
は存在しない
“A one size fits all database
doesn't fit anyone”
Werner Vogels
CTO - Amazon.com
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
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
ワークロードに適した最適なデータベース選択
A m a z o n M a n a g e d
A p a c h e C a s s a n d r a
S e r v i c e ( M C S )
© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T

More Related Content

What's hot

Migration to AWS part2
Migration to AWS part2Migration to AWS part2
Migration to AWS part2
Kameda Harunobu
 
Japan Wrap Up re:Invent2018
Japan Wrap Up re:Invent2018Japan Wrap Up re:Invent2018
Japan Wrap Up re:Invent2018
Kameda Harunobu
 
AWSの様々なアーキテクチャ
AWSの様々なアーキテクチャAWSの様々なアーキテクチャ
AWSの様々なアーキテクチャ
Kameda Harunobu
 
[最新バージョンの情報がDescription欄にございます]AWS Black Belt Online Seminar 2018 Amazon Connect
[最新バージョンの情報がDescription欄にございます]AWS Black Belt Online Seminar 2018 Amazon Connect[最新バージョンの情報がDescription欄にございます]AWS Black Belt Online Seminar 2018 Amazon Connect
[最新バージョンの情報がDescription欄にございます]AWS Black Belt Online Seminar 2018 Amazon Connect
Amazon Web Services Japan
 
Migartion to AWS
Migartion to AWSMigartion to AWS
Migartion to AWS
Kameda Harunobu
 
AWS 資格試験対策講座
AWS 資格試験対策講座AWS 資格試験対策講座
AWS 資格試験対策講座
Kameda Harunobu
 
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
Amazon Web Services Japan
 
[CTO Night & Day 2019] 高可用性アーキテクチャについて考える #ctonight
[CTO Night & Day 2019] 高可用性アーキテクチャについて考える #ctonight[CTO Night & Day 2019] 高可用性アーキテクチャについて考える #ctonight
[CTO Night & Day 2019] 高可用性アーキテクチャについて考える #ctonight
Amazon Web Services Japan
 
[CTO Night & Day 2019] AWS のコスト最適化 #ctonight
[CTO Night & Day 2019] AWS のコスト最適化 #ctonight[CTO Night & Day 2019] AWS のコスト最適化 #ctonight
[CTO Night & Day 2019] AWS のコスト最適化 #ctonight
Amazon Web Services Japan
 
【12/5 最新版】AWS Black Belt Online Seminar AWS re:Invent 2018 アップデート情報
【12/5 最新版】AWS Black Belt Online Seminar AWS re:Invent 2018 アップデート情報【12/5 最新版】AWS Black Belt Online Seminar AWS re:Invent 2018 アップデート情報
【12/5 最新版】AWS Black Belt Online Seminar AWS re:Invent 2018 アップデート情報
Amazon Web Services Japan
 
[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonight
[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonight[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonight
[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonight
Amazon Web Services Japan
 
Jawsdays2021 preday
Jawsdays2021 predayJawsdays2021 preday
Jawsdays2021 preday
Kameda Harunobu
 
[JAWS DAYS] 20180310 Alexa for Business とワークスタイルの未来
[JAWS DAYS] 20180310 Alexa for Business とワークスタイルの未来[JAWS DAYS] 20180310 Alexa for Business とワークスタイルの未来
[JAWS DAYS] 20180310 Alexa for Business とワークスタイルの未来
Amazon Web Services Japan
 
2021 days opening
2021 days opening2021 days opening
2021 days opening
Kameda Harunobu
 
[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...
[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...
[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...
Amazon Web Services Japan
 
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
Amazon Web Services Japan
 
AWS Black Belt Online Seminar 2018 re:Invent recap IoT and DevOps
AWS Black Belt Online Seminar 2018 re:Invent recap IoT and DevOpsAWS Black Belt Online Seminar 2018 re:Invent recap IoT and DevOps
AWS Black Belt Online Seminar 2018 re:Invent recap IoT and DevOps
Amazon Web Services Japan
 
AWS Black Belt Online Seminar 2018 動画配信 on AWS
AWS Black Belt Online Seminar 2018 動画配信 on AWSAWS Black Belt Online Seminar 2018 動画配信 on AWS
AWS Black Belt Online Seminar 2018 動画配信 on AWS
Amazon Web Services Japan
 
20180516 AWS Black Belt Online Seminar Amazon Connect
20180516 AWS Black Belt Online Seminar Amazon Connect20180516 AWS Black Belt Online Seminar Amazon Connect
20180516 AWS Black Belt Online Seminar Amazon Connect
Amazon Web Services Japan
 
AWS All Stars ~Lightning Talks x 13~
AWS All Stars ~Lightning Talks x 13~AWS All Stars ~Lightning Talks x 13~
AWS All Stars ~Lightning Talks x 13~
Amazon Web Services Japan
 

What's hot (20)

Migration to AWS part2
Migration to AWS part2Migration to AWS part2
Migration to AWS part2
 
Japan Wrap Up re:Invent2018
Japan Wrap Up re:Invent2018Japan Wrap Up re:Invent2018
Japan Wrap Up re:Invent2018
 
AWSの様々なアーキテクチャ
AWSの様々なアーキテクチャAWSの様々なアーキテクチャ
AWSの様々なアーキテクチャ
 
[最新バージョンの情報がDescription欄にございます]AWS Black Belt Online Seminar 2018 Amazon Connect
[最新バージョンの情報がDescription欄にございます]AWS Black Belt Online Seminar 2018 Amazon Connect[最新バージョンの情報がDescription欄にございます]AWS Black Belt Online Seminar 2018 Amazon Connect
[最新バージョンの情報がDescription欄にございます]AWS Black Belt Online Seminar 2018 Amazon Connect
 
Migartion to AWS
Migartion to AWSMigartion to AWS
Migartion to AWS
 
AWS 資格試験対策講座
AWS 資格試験対策講座AWS 資格試験対策講座
AWS 資格試験対策講座
 
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
[CTO Night & Day 2019] CTO のためのセキュリティ for Seed ~ Mid Stage #ctonight
 
[CTO Night & Day 2019] 高可用性アーキテクチャについて考える #ctonight
[CTO Night & Day 2019] 高可用性アーキテクチャについて考える #ctonight[CTO Night & Day 2019] 高可用性アーキテクチャについて考える #ctonight
[CTO Night & Day 2019] 高可用性アーキテクチャについて考える #ctonight
 
[CTO Night & Day 2019] AWS のコスト最適化 #ctonight
[CTO Night & Day 2019] AWS のコスト最適化 #ctonight[CTO Night & Day 2019] AWS のコスト最適化 #ctonight
[CTO Night & Day 2019] AWS のコスト最適化 #ctonight
 
【12/5 最新版】AWS Black Belt Online Seminar AWS re:Invent 2018 アップデート情報
【12/5 最新版】AWS Black Belt Online Seminar AWS re:Invent 2018 アップデート情報【12/5 最新版】AWS Black Belt Online Seminar AWS re:Invent 2018 アップデート情報
【12/5 最新版】AWS Black Belt Online Seminar AWS re:Invent 2018 アップデート情報
 
[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonight
[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonight[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonight
[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonight
 
Jawsdays2021 preday
Jawsdays2021 predayJawsdays2021 preday
Jawsdays2021 preday
 
[JAWS DAYS] 20180310 Alexa for Business とワークスタイルの未来
[JAWS DAYS] 20180310 Alexa for Business とワークスタイルの未来[JAWS DAYS] 20180310 Alexa for Business とワークスタイルの未来
[JAWS DAYS] 20180310 Alexa for Business とワークスタイルの未来
 
2021 days opening
2021 days opening2021 days opening
2021 days opening
 
[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...
[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...
[最新版は別にございます! Descriptionをご確認ください] AWS Black Belt Online Seminar AWS re:Inven...
 
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight
 
AWS Black Belt Online Seminar 2018 re:Invent recap IoT and DevOps
AWS Black Belt Online Seminar 2018 re:Invent recap IoT and DevOpsAWS Black Belt Online Seminar 2018 re:Invent recap IoT and DevOps
AWS Black Belt Online Seminar 2018 re:Invent recap IoT and DevOps
 
AWS Black Belt Online Seminar 2018 動画配信 on AWS
AWS Black Belt Online Seminar 2018 動画配信 on AWSAWS Black Belt Online Seminar 2018 動画配信 on AWS
AWS Black Belt Online Seminar 2018 動画配信 on AWS
 
20180516 AWS Black Belt Online Seminar Amazon Connect
20180516 AWS Black Belt Online Seminar Amazon Connect20180516 AWS Black Belt Online Seminar Amazon Connect
20180516 AWS Black Belt Online Seminar Amazon Connect
 
AWS All Stars ~Lightning Talks x 13~
AWS All Stars ~Lightning Talks x 13~AWS All Stars ~Lightning Talks x 13~
AWS All Stars ~Lightning Talks x 13~
 

Similar to Microservice and agile development

デフォルトAWS時代にインフラエンジニアはどう向き合うべきか?
デフォルトAWS時代にインフラエンジニアはどう向き合うべきか?デフォルトAWS時代にインフラエンジニアはどう向き合うべきか?
デフォルトAWS時代にインフラエンジニアはどう向き合うべきか?
Yasuhiro Horiuchi
 
2013 デブサミ 「SIの未来ってどうなのよ?」
2013 デブサミ 「SIの未来ってどうなのよ?」2013 デブサミ 「SIの未来ってどうなのよ?」
2013 デブサミ 「SIの未来ってどうなのよ?」
Serverworks Co.,Ltd.
 
スタートアップがAWSを使うべき3つの理由
スタートアップがAWSを使うべき3つの理由スタートアップがAWSを使うべき3つの理由
スタートアップがAWSを使うべき3つの理由
Serverworks Co.,Ltd.
 
AWS IoT SiteWise のご紹介 (AWS IoT Deep Dive #5)
AWS IoT SiteWise のご紹介 (AWS IoT Deep Dive #5)AWS IoT SiteWise のご紹介 (AWS IoT Deep Dive #5)
AWS IoT SiteWise のご紹介 (AWS IoT Deep Dive #5)
Amazon Web Services Japan
 
Management & Governance on AWS こんなこともできます
Management & Governance on AWS こんなこともできますManagement & Governance on AWS こんなこともできます
Management & Governance on AWS こんなこともできます
Amazon Web Services Japan
 
Amazon Web Services(AWS)とcloudpack について
Amazon Web Services(AWS)とcloudpack についてAmazon Web Services(AWS)とcloudpack について
Amazon Web Services(AWS)とcloudpack について
Hiroyasu Suzuki
 
Serverless for VUI
Serverless for VUIServerless for VUI
Serverless for VUI
真吾 吉田
 
アマゾンクラウドの真価
アマゾンクラウドの真価アマゾンクラウドの真価
アマゾンクラウドの真価
kaminashi
 
AWSについて @ JAWS-UG 沖縄 CMS祭り!
AWSについて @ JAWS-UG 沖縄 CMS祭り!AWSについて @ JAWS-UG 沖縄 CMS祭り!
AWSについて @ JAWS-UG 沖縄 CMS祭り!
Yasuhiro Horiuchi
 
AWS re:Invent 2019 Recap IoT アップデート
AWS re:Invent 2019 Recap IoT アップデートAWS re:Invent 2019 Recap IoT アップデート
AWS re:Invent 2019 Recap IoT アップデート
Amazon Web Services Japan
 
20200811 AWS Black Belt Online Seminar CloudEndure
20200811 AWS Black Belt Online Seminar CloudEndure20200811 AWS Black Belt Online Seminar CloudEndure
20200811 AWS Black Belt Online Seminar CloudEndure
Amazon Web Services Japan
 
[CTO Night & Day 2019] よくある課題を一気に解説!御社の技術レベルがアップする 2019 秋期講習 #ctonight
[CTO Night & Day 2019] よくある課題を一気に解説!御社の技術レベルがアップする 2019 秋期講習 #ctonight[CTO Night & Day 2019] よくある課題を一気に解説!御社の技術レベルがアップする 2019 秋期講習 #ctonight
[CTO Night & Day 2019] よくある課題を一気に解説!御社の技術レベルがアップする 2019 秋期講習 #ctonight
Amazon Web Services Japan
 
MTDDC Meetup HOKKAIDO 2013 (サーバーワークス発表資料)
MTDDC Meetup HOKKAIDO 2013 (サーバーワークス発表資料)MTDDC Meetup HOKKAIDO 2013 (サーバーワークス発表資料)
MTDDC Meetup HOKKAIDO 2013 (サーバーワークス発表資料)
Serverworks Co.,Ltd.
 
あなたの ”Cloud” も ”One” ダフル!トレンドマイクロの新セキュリティ!
あなたの ”Cloud” も ”One” ダフル!トレンドマイクロの新セキュリティ!あなたの ”Cloud” も ”One” ダフル!トレンドマイクロの新セキュリティ!
あなたの ”Cloud” も ”One” ダフル!トレンドマイクロの新セキュリティ!
Kwiil Kang
 
エッジコンピューティングで実現できる活用シナリオ3選
エッジコンピューティングで実現できる活用シナリオ3選エッジコンピューティングで実現できる活用シナリオ3選
エッジコンピューティングで実現できる活用シナリオ3選
Jun Ichikawa
 
[CTC Forum 2019/10/25] 事例から学ぶ!AWS 移行でデータベースの管理・コストを削減する方法
[CTC Forum 2019/10/25] 事例から学ぶ!AWS 移行でデータベースの管理・コストを削減する方法[CTC Forum 2019/10/25] 事例から学ぶ!AWS 移行でデータベースの管理・コストを削減する方法
[CTC Forum 2019/10/25] 事例から学ぶ!AWS 移行でデータベースの管理・コストを削減する方法
Takanori Ohba
 
機密データとSaaSは共存しうるのか!?セキュリティー重視のユーザー層を取り込む為のネットワーク通信のアプローチ
機密データとSaaSは共存しうるのか!?セキュリティー重視のユーザー層を取り込む為のネットワーク通信のアプローチ機密データとSaaSは共存しうるのか!?セキュリティー重視のユーザー層を取り込む為のネットワーク通信のアプローチ
機密データとSaaSは共存しうるのか!?セキュリティー重視のユーザー層を取り込む為のネットワーク通信のアプローチ
Amazon Web Services Japan
 
クラウドを積極活用した サービスの開発のために
クラウドを積極活用したサービスの開発のためにクラウドを積極活用したサービスの開発のために
クラウドを積極活用した サービスの開発のために
Yuichiro Saito
 
Amazon Web Services 最新事例集
Amazon Web Services 最新事例集Amazon Web Services 最新事例集
Amazon Web Services 最新事例集
SORACOM, INC
 
What's new with Serverless
What's new with ServerlessWhat's new with Serverless
What's new with Serverless
Keisuke Nishitani
 

Similar to Microservice and agile development (20)

デフォルトAWS時代にインフラエンジニアはどう向き合うべきか?
デフォルトAWS時代にインフラエンジニアはどう向き合うべきか?デフォルトAWS時代にインフラエンジニアはどう向き合うべきか?
デフォルトAWS時代にインフラエンジニアはどう向き合うべきか?
 
2013 デブサミ 「SIの未来ってどうなのよ?」
2013 デブサミ 「SIの未来ってどうなのよ?」2013 デブサミ 「SIの未来ってどうなのよ?」
2013 デブサミ 「SIの未来ってどうなのよ?」
 
スタートアップがAWSを使うべき3つの理由
スタートアップがAWSを使うべき3つの理由スタートアップがAWSを使うべき3つの理由
スタートアップがAWSを使うべき3つの理由
 
AWS IoT SiteWise のご紹介 (AWS IoT Deep Dive #5)
AWS IoT SiteWise のご紹介 (AWS IoT Deep Dive #5)AWS IoT SiteWise のご紹介 (AWS IoT Deep Dive #5)
AWS IoT SiteWise のご紹介 (AWS IoT Deep Dive #5)
 
Management & Governance on AWS こんなこともできます
Management & Governance on AWS こんなこともできますManagement & Governance on AWS こんなこともできます
Management & Governance on AWS こんなこともできます
 
Amazon Web Services(AWS)とcloudpack について
Amazon Web Services(AWS)とcloudpack についてAmazon Web Services(AWS)とcloudpack について
Amazon Web Services(AWS)とcloudpack について
 
Serverless for VUI
Serverless for VUIServerless for VUI
Serverless for VUI
 
アマゾンクラウドの真価
アマゾンクラウドの真価アマゾンクラウドの真価
アマゾンクラウドの真価
 
AWSについて @ JAWS-UG 沖縄 CMS祭り!
AWSについて @ JAWS-UG 沖縄 CMS祭り!AWSについて @ JAWS-UG 沖縄 CMS祭り!
AWSについて @ JAWS-UG 沖縄 CMS祭り!
 
AWS re:Invent 2019 Recap IoT アップデート
AWS re:Invent 2019 Recap IoT アップデートAWS re:Invent 2019 Recap IoT アップデート
AWS re:Invent 2019 Recap IoT アップデート
 
20200811 AWS Black Belt Online Seminar CloudEndure
20200811 AWS Black Belt Online Seminar CloudEndure20200811 AWS Black Belt Online Seminar CloudEndure
20200811 AWS Black Belt Online Seminar CloudEndure
 
[CTO Night & Day 2019] よくある課題を一気に解説!御社の技術レベルがアップする 2019 秋期講習 #ctonight
[CTO Night & Day 2019] よくある課題を一気に解説!御社の技術レベルがアップする 2019 秋期講習 #ctonight[CTO Night & Day 2019] よくある課題を一気に解説!御社の技術レベルがアップする 2019 秋期講習 #ctonight
[CTO Night & Day 2019] よくある課題を一気に解説!御社の技術レベルがアップする 2019 秋期講習 #ctonight
 
MTDDC Meetup HOKKAIDO 2013 (サーバーワークス発表資料)
MTDDC Meetup HOKKAIDO 2013 (サーバーワークス発表資料)MTDDC Meetup HOKKAIDO 2013 (サーバーワークス発表資料)
MTDDC Meetup HOKKAIDO 2013 (サーバーワークス発表資料)
 
あなたの ”Cloud” も ”One” ダフル!トレンドマイクロの新セキュリティ!
あなたの ”Cloud” も ”One” ダフル!トレンドマイクロの新セキュリティ!あなたの ”Cloud” も ”One” ダフル!トレンドマイクロの新セキュリティ!
あなたの ”Cloud” も ”One” ダフル!トレンドマイクロの新セキュリティ!
 
エッジコンピューティングで実現できる活用シナリオ3選
エッジコンピューティングで実現できる活用シナリオ3選エッジコンピューティングで実現できる活用シナリオ3選
エッジコンピューティングで実現できる活用シナリオ3選
 
[CTC Forum 2019/10/25] 事例から学ぶ!AWS 移行でデータベースの管理・コストを削減する方法
[CTC Forum 2019/10/25] 事例から学ぶ!AWS 移行でデータベースの管理・コストを削減する方法[CTC Forum 2019/10/25] 事例から学ぶ!AWS 移行でデータベースの管理・コストを削減する方法
[CTC Forum 2019/10/25] 事例から学ぶ!AWS 移行でデータベースの管理・コストを削減する方法
 
機密データとSaaSは共存しうるのか!?セキュリティー重視のユーザー層を取り込む為のネットワーク通信のアプローチ
機密データとSaaSは共存しうるのか!?セキュリティー重視のユーザー層を取り込む為のネットワーク通信のアプローチ機密データとSaaSは共存しうるのか!?セキュリティー重視のユーザー層を取り込む為のネットワーク通信のアプローチ
機密データとSaaSは共存しうるのか!?セキュリティー重視のユーザー層を取り込む為のネットワーク通信のアプローチ
 
クラウドを積極活用した サービスの開発のために
クラウドを積極活用したサービスの開発のためにクラウドを積極活用したサービスの開発のために
クラウドを積極活用した サービスの開発のために
 
Amazon Web Services 最新事例集
Amazon Web Services 最新事例集Amazon Web Services 最新事例集
Amazon Web Services 最新事例集
 
What's new with Serverless
What's new with ServerlessWhat's new with Serverless
What's new with Serverless
 

More from Kameda Harunobu

Sapporo devfesta 2019/11/13
Sapporo devfesta 2019/11/13Sapporo devfesta 2019/11/13
Sapporo devfesta 2019/11/13
Kameda Harunobu
 
Aws handson 20181108
Aws handson 20181108Aws handson 20181108
Aws handson 20181108
Kameda Harunobu
 
JAWS FESTA 2018
JAWS FESTA 2018JAWS FESTA 2018
JAWS FESTA 2018
Kameda Harunobu
 
20180123 20分でlive配信aws media services(media live mediapackage)_pub
20180123 20分でlive配信aws media services(media live mediapackage)_pub20180123 20分でlive配信aws media services(media live mediapackage)_pub
20180123 20分でlive配信aws media services(media live mediapackage)_pub
Kameda Harunobu
 
Word press preinstall-iam対応版-aws体験ハンズオン-セキュア&スケーラブルウェブサービス構築編
Word press preinstall-iam対応版-aws体験ハンズオン-セキュア&スケーラブルウェブサービス構築編Word press preinstall-iam対応版-aws体験ハンズオン-セキュア&スケーラブルウェブサービス構築編
Word press preinstall-iam対応版-aws体験ハンズオン-セキュア&スケーラブルウェブサービス構築編
Kameda Harunobu
 
Migration to aws as of 20170920
Migration to aws as of 20170920Migration to aws as of 20170920
Migration to aws as of 20170920
Kameda Harunobu
 
20170826 Oita JAWS
20170826 Oita JAWS20170826 Oita JAWS
20170826 Oita JAWS
Kameda Harunobu
 

More from Kameda Harunobu (7)

Sapporo devfesta 2019/11/13
Sapporo devfesta 2019/11/13Sapporo devfesta 2019/11/13
Sapporo devfesta 2019/11/13
 
Aws handson 20181108
Aws handson 20181108Aws handson 20181108
Aws handson 20181108
 
JAWS FESTA 2018
JAWS FESTA 2018JAWS FESTA 2018
JAWS FESTA 2018
 
20180123 20分でlive配信aws media services(media live mediapackage)_pub
20180123 20分でlive配信aws media services(media live mediapackage)_pub20180123 20分でlive配信aws media services(media live mediapackage)_pub
20180123 20分でlive配信aws media services(media live mediapackage)_pub
 
Word press preinstall-iam対応版-aws体験ハンズオン-セキュア&スケーラブルウェブサービス構築編
Word press preinstall-iam対応版-aws体験ハンズオン-セキュア&スケーラブルウェブサービス構築編Word press preinstall-iam対応版-aws体験ハンズオン-セキュア&スケーラブルウェブサービス構築編
Word press preinstall-iam対応版-aws体験ハンズオン-セキュア&スケーラブルウェブサービス構築編
 
Migration to aws as of 20170920
Migration to aws as of 20170920Migration to aws as of 20170920
Migration to aws as of 20170920
 
20170826 Oita JAWS
20170826 Oita JAWS20170826 Oita JAWS
20170826 Oita JAWS
 

Microservice and agile development

  • 1. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ~マイクロサービスアーキテクチャとアジャイル開発 2020.06.25 Amazon Web Services Japan K.K. Senior Dev.Advocate Harunobu Kameda
  • 2. AWS の基本コンセプト 必要な時に、必要なだけ、低価格で 使用分のみ支払い 初期投資不要  低額の変動費 開発者は作業を阻害しない ITインフラが必要 API経由で操作可能な コンピュートリソースプール
  • 6. Infrastructure as Code (IaC) • リソースはAPI経由でプロビジョニング • 定義ファイルによる、効率化と自動化 • エラーやセキュリテイ違反の除去 https://ja.wikipedia.org/wiki/Infrastructure_as_Code Cloud Computing • 大規模化、共有リソースプールによる効率化 • データセンター、ネットワーク、ハードウェアの抽象化 • 多くのマネージドサービス
  • 11. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. スピードと俊敏性に こだわるための小規模 チーム Two-Pizza Teams 小さくそれぞれ が自律的に動け る組織 何を作るかから 実行までのすべ ての権限を持つ 主体性 と 自立性 を 重視
  • 12. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 実験 は早めに、頻繁に
  • 13. © 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved. AWS が提供するソリューションの数々 コンピューティング 開発者用ツール 機械学習 ビジネスの 生産性 ストレージ 管理ツール モバイルサービス デスクトップと アプリケーションの ストリーミング データベース メディアサービス AR(拡張現実)と VR(バーチャルリアリティ) IoT マイグレーション セキュリティ アクセス権管理、法令遵守 アプリケーション 構築 ゲーム開発 ネットワーク & コンテンツ配信 分 析 カスタマー エンゲージメント ブロックチェーン ロボット工学 人工衛星 190+
  • 19. LB 共有 データソース Blue / Green Deployment DNS Application v1 WEB APP Application v2 WEB APP Snapshot
  • 20. @2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved What is Cloud Native ? リソースは伸縮可能 API 経由で操作 セッションをお腹に持たない べき等性 Restful, Stateless CI/CD サーバレス コンテナ
  • 21. @2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved クラウドネイティブ開発だから アジャイルでOK アジャイルだから ドキュメントは 後回しでいこう
  • 22. @2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved プロセスやツールよりも個人と対話を 包括的なドキュメントよりも動くソフトウェアを 契約交渉よりも顧客との協調を 計画に従うことよりも変化への対応を アジャイルソフトウェア開発宣言
  • 23. @2018, Amazon Web Services, Inc. or its Affiliates. All rights Reserved 顧客へ提供しうる価値の最大化 アジャイルソフトウェアとクラウド 【価値の最大化】のみを目的とし Legacy手法の変更を行う
  • 24. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Microservice/アジャイル開発とドキュメンテーション
  • 25. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T マイクロサービスとAPI 疎結合なAPI連携のみで有機的に結合 APIへの改修、新規APIリリースは最大限の注意が必要 改修 リリース リリース ドキュメンテーション&レビュー 非改修 (ソース = ドキュメント ?)
  • 26. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T と、いうことは・・・? つまり
  • 27. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T と、いうことは・・・? つまり
  • 28. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T と、いうことは・・・? つまり
  • 29. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T と、いうことは・・・? つまり
  • 32. Classic virtualization S E R V E R C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0
  • 33. Classic virtualization S E R V E R COMPLEXITY, OVERHEAD, VIRTUALIZATION TAX C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0
  • 35. API
  • 37. S E R V E R C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0 Classic virtualization
  • 38. N I T R O C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0 S E R V E R P C I e B U S Nitro: Step 1 C3 インスタンス
  • 39. N I T R O P C I e B U S C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0 S E R V E R Nitro: Step 2 C4 インスタンス
  • 40. N I T R O P C I e B U S C U S T O M E R I N S T A N C E S X E N H Y P E R V I S O R VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Dom0 S E R V E R Nitro: Step 3
  • 41. N I T R O H Y P E R V I S O R N I T R O P C I e B U S C U S T O M E R I N S T A N C E S VPC NETWORKING EBS STORAGE LOCAL STORAGE MANAGEMENT SECURITY + MONITORING Nitro: S E R V E R μEMU etc. Step 4 ENA C5 インスタンス
  • 42. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. API マイクロサービス イベント API マイクロサービス モバイル クライアント クライアント IoT マイクロサービスとイベントドリブン Serverless Computing
  • 43. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS のサービスを活用した疎結合の例 3階層構造 ウェブサーバーはアプリサーバーと密結合 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 の設定 ファイルの書き換えが必要
  • 44. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS のサービスを活用した非同期処理の例 Amazon SQS を挟んで Frontend と Backend を非同期かつ疎結合に BackendもQueueの滞留に合わせてオートスケール Frontend Servers ELB Client 重たい処理は Backend Servers に任せる Sticky Session Backend Servers SQS キューから取得した メッセージを元にバッチ的 に処理を実行していく 重たい処理は Backend で 非同期に行われるので、 Client へのレスポンスは迅 速に Amazon SQS Queue
  • 45. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 単純なECサイトのシーケンス クライアント WEB DB
  • 46. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 非同期処理なECサイトのシーケンス クライアント WEB DB App SQS
  • 47. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. リアルタイムのレスポンスを要求しないシステム IoT センサーデバイス Amazon Kinesis
  • 48. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. お客様事例:あきんどスシロー様 捨てていたデータをクラウドに送り、他のデータと合わせて分析することで、 今まで見えなかったことがデータとして可視化に成功。
  • 49. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. データベースの選択 • AWS では多様な データベースの選択肢 • ワークロードに応じて 最適な選択が可能 Purpose built The right tool for the right job https://www.allthingsdistributed.com/2018/06/purpose-built-databases-in-aws.html 適材適所の選択
  • 50. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. データの種類に応じて適切なデータストアを選択 サーバー ローカル ストレージ サーバー ローカル ストレージ 共有 ストレージ データベース (RDBMS) データベース (NoSQL) ・ショッピングカート ・セッション情報 ・ユーザ情報 ・商品情報 ・在庫情報 ・商品画像データ 複数データストアの使い分けで効率を向上 “A one size fits all database doesn't fit anyone”
  • 51. VPC Public subnet Availability Zone Private subnet 一般的なWEBサービスの構成図 2階層構造 VPC Public subnet Availability Zone Availability Zone Private subnet ELB EC2 ElastiCache RDS
  • 52. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 従来のエンタープライズ DB システム アプリ オンライン トランザクション ETLツール 分析 BIツールOLTP DB OLAP DB
  • 53. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 万能のデータベース は存在しない “A one size fits all database doesn't fit anyone” Werner Vogels CTO - Amazon.com
  • 54. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 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 ワークロードに適した最適なデータベース選択 A m a z o n M a n a g e d A p a c h e C a s s a n d r a S e r v i c e ( M C S )
  • 55. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T

Editor's Notes

  1. このセッションではアマゾンのイノベーションに関する話を共有させていただきます。 AWSではEBCというファシリティを設けてお客様に様々な情報のご提供を差し上げていますが、一番人気であるのが、Amazonの文化に対するセッションです。 本日お届けするのは飽くまでもAmazonにおけるイノベーションの考え方や実行の話で、全てのお客様にこのやり方が合うとは思いませんが、皆様の会社におけるイノベーション展開の一助になればと幸いです。
  2. その考え方をもとにクラウドコンピューティングは誕生しました。 その基本的なコンセプトのおさらいがこちらです。 AWSは、初期費用が無償であり、低額な、従量課金です。必要な時に必要なだけITリソースを利用することができ、長期の契約は不要です。 このサービスの提供形態は、カスタマーの使い勝手を向上させ、そしてAWSが常にカスタマーに満足してもらう必要があることに繋がります。
  3. 1つ目がアーキテクチャの変更です。 モノリシックアーキテクチャをやめ、SOAサービス指向アーキテクチャへ移行します。 機能単位の小さなサービスに分割しました。 例えば、製品ページの購入ボタンと、税金を計算するサービスのようにです。 全てのサービスはWebサービスとしてパッケージ化して、HTTPのインターフェースを持ちます。 そして、これらのサービスは相互にHTTPのインターフェースを通じて通信します。 これは2009年、6年ほど前のことです。 左の図はアーキテクチャを図示したものです。 これはいわゆる最近だとMicroservicesと呼ばれるムーブメントになっています。 - we took the monolith and broke it apart into a service oriented architecture - factored the app into small, focused, single-purpose services, which we call "primitives" - for example, we had a primitive for displaying the buy button on a product page, and we had one for calculating taxes - every primitive was packaged as a standalone web service, and got an HTTP interface - these building blocks only communicated to each other through the web service interfaces - to give you an idea of the scope of these small services, I've included this graphic - this is the constellation of services that deliver the Amazon.com website back in 2009, 6 years ago - this term didn't exist back then, but today you'd call this a microservice architecture Moving to a SOA - everything gets a service interface - breaking monolithic app into small services (primitives) - picture of what amazon.com looked like after this transformation (actual depiction of our service architecture) - today, I guess it’s popular to call this “microservices”
  4. モノリシックアーキテクチャーは、その規模の拡大とともに、いろいろな問題を生じさせます。 まず、中身が複雑となりその全体像を把握することが困難となります。 そして新しいモジュールの投入や機能改善が、システムの他の部分に及ぼす影響を把握しずらくなり、 物理的限界を超えていきます。このため、ビルドやテストに時間がかかり、予期しない問題を引き起こし デグレードなどが発生しやすくなります。このため、デプロイ作業で問題が発生することも増加します。 さらに重要なことは、モノリシックなアーキテクチャは基本的にスケールアップにしか対応できず、スケーラビリティに限界が来ることです。
  5. We have a distinctly Amazonian way of organizing to optimize execution. We’re structured organizationally to try and enable agility. And one of the ways we’ve done that is what we call our ‘two-pizza teams. --meaning that no team should be big enough that it would take more than two pizzas to feed them. The fundamental concept of the two-pizza team came out of efforts to minimize the need for communications, minimize time in unnecessary meetings, and accelerate the decision making process.  While we can debate around the size of the pizza, this concept is fundamentally around creating a little startup of around 5-10 people. Providing the conditions so that each team has ownership and autonomy, and provide deep focus in one area. These decentralized, autonomous teams are empowered to develop and launch based on what they learn from interactions with customers. Why do we do this? We found there is an exponential function in the overhead of communication with the more people you add on a team. And once you get to 11 or 12 is when you hit that exponential rate. You add more people, more people means more communication, that slows things down. So a 2PT has the resources embedded in them to have full ownership. So they own every function from engineering, to testing, to product management – and we try to embed all those resources on that single team and make them single-threaded, with a single owner, and give them a very tight charter and mission to they can run as fast as possible and have focus in one area. [Single threaded leaders] So 2PT push ownership, push autonomy. You build the software, you test the software, you operate, you think about the future of it. Btw, this also has an impact on code quality. If you’re responsible for maintaining, and you’ll get paged on a sat. night if your software breaks, you’ll probably do a better job building it in the first place. As demands grow and the team needs to expand, we split teams into separate 2-pizza teams working on sub—areas, rather than simply make the team bigger. This concept of a 2PT has been around for many years, and culture at the individual team level has changed very little, because it’s self-reinforcing and it’s one of the things we’ve done that’s helped us scale dramatically over time.
  6. Enable experimentation via primitives Build on existing services Lower the costs of failure Prototype, iterate – a LOT Embrace failure as learning
  7. マイクロサービスで構成されたアプリケーションの概要図がこちらです。 お互いのコンポーネントは疎結合状態を保ち、独立したアプリケーションとして存在します。 そしてそれらの通信経路はAPIのみとすることで非同期な開発、バージョンアップを可能とします。 この際、各コンポーネント間の連携経路をリアルタイム型ではなく、イベント駆動型にすることで より独立した開発を可能とします。 リアルタイム連携の場合、常にお互いの同期がとれた状態である必要がありますが。 イベント駆動型の場合、指示を出すタミングのみ連携すればよく、分割した管理をよりやりやすくなります。
  8. そうして、2014年時点で、数千のチームがこのアーキテクチャを採用し、 継続的デリバリを個別に行いながら、複数の環境を維持し、年間5000万回のデプロイを実現しています。 この開発手法は、AWSそのものにも取り入れられており、 2017年では1430回の機能改善を実現しています。 そして複数のチームが独立した開発を行っています。
  9. 30
  10. So let’s start at one of the most fundamental layers in the cloud – Virtualization. Virtualization is one of the major technical underpinnings that have enabled cloud computing to become what it is today.
  11. Most people here probably have a reasonable understanding of what Virtualization and Virtual Machines are, but let’s talk about it at the most fundamental level – The hypervisor. A hypervisor is a piece of system software that provides virtual machines (VMs), which users can use to run their OS and applications on. The hypervisor provides isolation between VMs, which run independent of each other, and also allows different VMs to run their own OS. Like other virtualization techniques, hypervisors provide multitenancy, which simplifies machine provision and administration.  Hypervisors have been around for a very long time, going back to the late 60’s. In the late 90’s, the x86 based VMware hypervisor was released. This is when virtualization really began to go mainstream. It used binary translation to replace privileged instructions to trap into the hypervisor, while still running unprivileged instructions directly on the physical CPU, which solved x86’s virtualization issues (Adams and Agesen, 2006). This allowed the VMware hypervisor to run unmodified commodity OS’es on x86 hardware in virtual machines without the performance penalty of emulation. The Xen hypervisor released first in 2003 took a different approach to solving the x86 virtualization issue. Instead of binary translation, they modified the source code of the guest OS to trap to the hypervisor instead of executing non-trapping privileged instructions.
  12. Virtualization had significant impact on the IT industry, and allowed for systems administrators optimize resource utilization and use new availability techniques to improve uptime. With AWS, we have pushed the boundaries of what traditional virtualization can provide. As we’ve further optimized resource utilization we reached a point where the root virtualization IO tax (hardware on the boards, shared between all guests) – is something that has become a very real limitation. We need to create an environment where customers don’t see network jitter and these other virtualization challenges impacting their workloads.
  13. Just like with any monolithic app there were too many interconnected systems in the virtualization stack. This is one of the reasons why we found the need to rethink/refactor. In recent years we’ve seen a shift from monolithic architecture and design, to SoA and Microservices.
  14. As you look at this, you see how closely tied to the hardware this is, and you start to think of this as a distributed system. What lessons can we take from purpose built IoT devices, and build a system of independent controllers/devices connected together via an API?
  15. This is why we built Nitro. Nitro gives us modular, software programmable, virtualizable infrastructure. The modularity lets us recompose the infrastructure resources into different shape
  16. Let’s talk about how we actually built this. As we mentioned, traditional virtualization has limitations in the complex orchestration and virtualization traps that happen at the hypervisor level. A crucial observation here was that to deliver this experience, we need to vastly reduce the number of traps hypervisors take and replace software with hardware acceleration.
  17. Step 1: When we started building Nitro several years ago, we started by tackling networking and asking how we could eliminate those hundreds of thousands of traps required to download a file from S3. Our answer to this was our very first Nitro offload card which we launched at re:Invent 2013 in the C3 instance type, a full six years ago. We learned a lot building the first Nitro card. It took us multiple years including restarting the software stack at least twice. A really critical thing we learned is that when using hardware offloads like Nitro, we needed to build the software from the start to take advantage of the underlying hardware. {Internal note} This was not ENA at this point. Intel NIC.
  18. Step 2: The first Nitro card was great and customers loved the improved performance and consistency that came in C3 but we wanted to do more and were hitting the limits of off the shelf hardware. Fortunately, we began working with a startup called Annapurna Labs and launched our second generation of Nitro card in the C4 instance type. Instead of just offloading networking, we were also able to offload EBS storage delivering higher performance and better consistency. 
  19. Step 3: We had such great success with the Nitro card in C4 that had Annapurna Labs join AWS and we began working on our next big jump in Nitro technology which we launched with C5. For C5, we offloaded all I/O operations including networking, EBS storage, and local storage.
  20. Step 4: This is one of the most significant iterations yet, where we introduce the Nitro hypervisor for the first time. The Nitro hypervisor allows us to remove the Dom0 from the stack, where we take all of these management overhead capabilities, such as providing DNS, instance metadata and other things that the system board needs to interact with in order to boot (mouse/keyboard emulation, etc.) and move this off to an off-board Nitro controller. Here we also really introduced the first unified system for the elastic Network adapter, where it’s not a traditional NIC any more, but software running on an acclererated Nitro card and is one of the first things we co-built with Annupurna on the X1 instance type. https://aws.amazon.com/about-aws/whats-new/2016/06/introducing-elastic-network-adapter-ena-the-next-generation-network-interface-for-ec2-instances/
  21. マイクロサービスで構成されたアプリケーションの概要図がこちらです。 お互いのコンポーネントは疎結合状態を保ち、独立したアプリケーションとして存在します。 そしてそれらの通信経路はAPIのみとすることで非同期な開発、バージョンアップを可能とします。 この際、各コンポーネント間の連携経路をリアルタイム型ではなく、イベント駆動型にすることで より独立した開発を可能とします。 リアルタイム連携の場合、常にお互いの同期がとれた状態である必要がありますが。 イベント駆動型の場合、指示を出すタミングのみ連携すればよく、分割した管理をよりやりやすくなります。
  22. Loose Coupling As application complexity increases, a desirable attribute of an IT system is that it can be broken into smaller, loosely coupled components. This means that IT systems should be designed in a way that reduces interdependencies—a change or a failure in one component should not cascade to other components. 従来のインフラストラクチャでは、それぞれが特定の目的を備えた、一連の緊密に統合されたサーバーが中心となっていました。しかし、これらのコンポーネントやレイヤーの一つが停止すると、最終的にはシステムに致命的な中断が発生する場合があります。さらに、スケーリングも阻害されます。1 つのレイヤーにサーバーを追加または削除すると、それに接続していたすべてのレイヤーの全サーバーも適切に接続される必要があります。 疎結合により、可能な場合は、管理されたソリューションをシステムのレイヤー間の中間証明書として活用できます。これにより、コンポーネントやレイヤーの障害およびスケーリングが、この媒介である疎結合によって自動的に処理されます。 コンポーネントを非干渉化するための 2 大ソリューションは、ロードバランサーとメッセージキューです。
  23. Asynchronous Integration Asynchronous integration is another form of loose coupling between services. This model is suitable for any interaction that does not need an immediate response and where an acknowledgement that a request has been registered will suffice. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to- point interaction but usually through an intermediate durable storage layer (e.g., an Amazon SQS queue or a streaming data platform like Amazon Kinesis). This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. It also allows you to protect a less scalable back end service from front end spikes and find the right tradeoff between cost and processing lag. For example, you can decide that you don’t need to scale your database to accommodate for an occasional peak of write queries as long as you eventually process those queries asynchronously with some delay. Finally, by moving slow operations off of interactive request paths you can also improve the end-user experience.
  24. Asynchronous Integration Asynchronous integration is another form of loose coupling between services. This model is suitable for any interaction that does not need an immediate response and where an acknowledgement that a request has been registered will suffice. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to- point interaction but usually through an intermediate durable storage layer (e.g., an Amazon SQS queue or a streaming data platform like Amazon Kinesis). This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. It also allows you to protect a less scalable back end service from front end spikes and find the right tradeoff between cost and processing lag. For example, you can decide that you don’t need to scale your database to accommodate for an occasional peak of write queries as long as you eventually process those queries asynchronously with some delay. Finally, by moving slow operations off of interactive request paths you can also improve the end-user experience.
  25. Asynchronous Integration Asynchronous integration is another form of loose coupling between services. This model is suitable for any interaction that does not need an immediate response and where an acknowledgement that a request has been registered will suffice. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to- point interaction but usually through an intermediate durable storage layer (e.g., an Amazon SQS queue or a streaming data platform like Amazon Kinesis). This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. It also allows you to protect a less scalable back end service from front end spikes and find the right tradeoff between cost and processing lag. For example, you can decide that you don’t need to scale your database to accommodate for an occasional peak of write queries as long as you eventually process those queries asynchronously with some delay. Finally, by moving slow operations off of interactive request paths you can also improve the end-user experience.
  26. Asynchronous Integration Asynchronous integration is another form of loose coupling between services. This model is suitable for any interaction that does not need an immediate response and where an acknowledgement that a request has been registered will suffice. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to- point interaction but usually through an intermediate durable storage layer (e.g., an Amazon SQS queue or a streaming data platform like Amazon Kinesis). This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. It also allows you to protect a less scalable back end service from front end spikes and find the right tradeoff between cost and processing lag. For example, you can decide that you don’t need to scale your database to accommodate for an occasional peak of write queries as long as you eventually process those queries asynchronously with some delay. Finally, by moving slow operations off of interactive request paths you can also improve the end-user experience.
  27. 商品の画像データのような、データサイズが比較的大きいデータは、データベースではなく、共有ストレージであるS3に保存しましょう。 では、ここからS3について説明していきます。