2月19日、デブサミ2016に行ってきて、
AWSで実現するクラウドネイティブなアプリ開発のポイント
を聞いてきたのでメモメモ
なお、メモ中の「資料」(このプレゼンの発表内容)は
http://www.slideshare.net/keisuke69/aws-58452190
にあります。一部、メモしきれなかったところを、資料をみて補足しています。
■AWSで実現するクラウドネイティブなアプリ開発のポイント
・資料はUPする。触れないところはのちほどみてね
・自己紹介
・バズワードいっぱい
・AWS
代表サービスEC2.S3、RDS、
そのほかにも、結構サービス(60以上)
アプリ開発関連
・今日のお話:クラウドネイティブなアプリ開発
クラウドネイティブ?
クラウドで提供されるサービス利用を前提に構築するシステム及びアプリ
クラウドの特性を踏まえ利点を最大限に
→最初からクラウド乗で生まれるアプリ
クラウドの特性
✤障害を前提としたデザイン(Design for failure)
✤疎結合
✤弾⼒性の実装
✤全てのレイヤでセキュリティを担保
✤制約を恐れない
✤並列処理
✤複数あるストレージのオプション
・クラウドネイティブなアーキテクチャ
Microservices
コンテナ技術、デプロイメント自動化
マイクロサービスってなんだ
→マーティンファウラーのブログから
9つのポイント(1つ1つがふかい)
✤Componentization via Services
✤Organized around Business Capabilities
✤Products not Projects
✤Smart endpoints and dumb pipes
✤Decentralized Governance
✤Decentralized Data Management
✤Infrastructure Automation
✤Design for failure
✤Evolutionary Design
→きょうはいくつか
マイクロサービス
小さなサービスの組み合わせ
各サービスは独立したサービスで単一でデプロイ、実行可能
技術的な境界でなく、ビジネスの遂行能力で分割する
サービスをデプロイするのに必要な能力を持てるように分割する
組織構造と密接に関連
機能だけが別チームDB共通で持つということをしない
サービス間のコミュニケー損は軽量な手段を利用
Restful
利点
モノリシックなシステムからの解放
単独でデプロイ・実行可能であるため、個々のサービスで自由にスケールすることが可能
各サービスで独立性の高い実装が可能
サービス間は独立しているため、個々の可溶性の問題が全体に影響しない
ビジネス上の境界とより密接に新井んされる
パラレルな開発とデプロイ
迅速なデプロイ
考慮点
分散した複数のコンポーネントをあつか会うことのむずかしさ
コンポーネント間のコミュニケーションメッセージの増加によるレイテンシ増
トランザクションの取り扱いと結果整合性の検討
サービスディスカバ理
分散するシステムのテストにおける複雑さ
分散するシステムの運用とデプロイの複雑さ
AWS上で追う地区
✤API Gateway + Lambda
✤EC2 + ECS
✤EC2 + Elastic BeanStalk
✤EC2 + ELB + ASG + Runtime
いっぱんてきなアーキテクチャ
EC2+ELB+ RDS:サーバー1台稼働させる必要
サーバーレスアーキテクチャ
API Gateway+Lambda:AWSサービスを呼び出す
CloudFront +S3
2ティア
Javascript SDKからAWSサービスを直接呼び出す
→課題解決される
API Gateway:フルマネージド型サービス
AWS Sigv4の利用、リクエストのスロットリングとモニタリング
レスポンスのキャッシュ
DDOS対策
Swaggerのサポート
SDKの自動生成
Lambda
アプリケーション実行
自動的にスケール他のサービスに連携できる
100ミリ秒単位
サーバーレスアーキテクチャのメリット
コスト効率高い
付加価値を生まない重労働からの解放
何をするかを書くだけで良い
→うまくあてはまれば・・・
すべての要件を満たせるとは限らない
→コンテナの採用
長時間処理にも
・コンテナ
プロセスの隔離:ポータブル、フレキシブル、速い、効率的
Docker:
パッケージ
ship
run
→効率的リソース管理
クラスタマネジメント docker run myimage
→dockerが100個以上あったら・・・コンテナ死んだら?
・コンテナのオーケストレーション:ECS
クラスタ管理を簡単に
フレキシブルなコンテナ配置
アプリケーション
バッチジョブ
:
・サービスディスカバリー
→DNS,HTTP経由のエンドポイント登録・けんさく
・クラウドネイティブなアプリ開発
The 12 Factor App(http://12factor.net/ja/)
モダンなWebアプリケーション開発のための方法論
直接的にマイクロサービスと関連する話ではないが、一読しておくべき
コードベース
依存関係
設定
ビルド
プロセス
ボートバインディング
並行性
廃棄容易性
本番一致
ログ
管理プロセス:CI
・アプリケーションの実装パターン
いくつかの典型的なパターンがある
どのやり方が許容できるかはチームで決めること
最初に選んだやり方を最後まで貫く必要はない
・Graceful Degradation:500エラーを返すな。全体をエラーにしない
・Throttling:内部サービスによる偶発的DoS→API Gatewayを使えば簡単にできます
・Fail Fast:エラー検知したら早く返す
・Fail Silently:エラーは内部で気に処理しユーザーに成功返す
・Static Fallback:なにかかえす
・Retry:シンプルにリトライで成功すること多い。Exponential back off フィボナッチ数列
・Caching:キャッシュ有効活用
・Circuit Breaker:フォールバックプラン実行
・Think ぱられる
・smooth internal traffic:キューの利用
クラウドネイティブなデプロイ
・DevOps:ソフトウェア開発のライフサイクル
モノリシックな開発サイクル
The Amazon Way : 2 Pizza Rule 2枚のピザで賄える人数→サービスチーム
プロダクト開発(ロードマップ)
開発
運用
サポート
you build it,You run it
デリバリパイプライン
AWS DevOps Services
Code Pipeline:継続的デリバリとリソース
Code Deploy:オンプレにも
CodeCommit:Gitリポジトリ
AWSで実現するクラウドネイティブなアプリ開発のポイント
を聞いてきたのでメモメモ
なお、メモ中の「資料」(このプレゼンの発表内容)は
http://www.slideshare.net/keisuke69/aws-58452190
にあります。一部、メモしきれなかったところを、資料をみて補足しています。
■AWSで実現するクラウドネイティブなアプリ開発のポイント
・資料はUPする。触れないところはのちほどみてね
・自己紹介
・バズワードいっぱい
・AWS
代表サービスEC2.S3、RDS、
そのほかにも、結構サービス(60以上)
アプリ開発関連
・今日のお話:クラウドネイティブなアプリ開発
クラウドネイティブ?
クラウドで提供されるサービス利用を前提に構築するシステム及びアプリ
クラウドの特性を踏まえ利点を最大限に
→最初からクラウド乗で生まれるアプリ
クラウドの特性
✤障害を前提としたデザイン(Design for failure)
✤疎結合
✤弾⼒性の実装
✤全てのレイヤでセキュリティを担保
✤制約を恐れない
✤並列処理
✤複数あるストレージのオプション
・クラウドネイティブなアーキテクチャ
Microservices
コンテナ技術、デプロイメント自動化
マイクロサービスってなんだ
→マーティンファウラーのブログから
9つのポイント(1つ1つがふかい)
✤Componentization via Services
✤Organized around Business Capabilities
✤Products not Projects
✤Smart endpoints and dumb pipes
✤Decentralized Governance
✤Decentralized Data Management
✤Infrastructure Automation
✤Design for failure
✤Evolutionary Design
→きょうはいくつか
マイクロサービス
小さなサービスの組み合わせ
各サービスは独立したサービスで単一でデプロイ、実行可能
技術的な境界でなく、ビジネスの遂行能力で分割する
サービスをデプロイするのに必要な能力を持てるように分割する
組織構造と密接に関連
機能だけが別チームDB共通で持つということをしない
サービス間のコミュニケー損は軽量な手段を利用
Restful
利点
モノリシックなシステムからの解放
単独でデプロイ・実行可能であるため、個々のサービスで自由にスケールすることが可能
各サービスで独立性の高い実装が可能
サービス間は独立しているため、個々の可溶性の問題が全体に影響しない
ビジネス上の境界とより密接に新井んされる
パラレルな開発とデプロイ
迅速なデプロイ
考慮点
分散した複数のコンポーネントをあつか会うことのむずかしさ
コンポーネント間のコミュニケーションメッセージの増加によるレイテンシ増
トランザクションの取り扱いと結果整合性の検討
サービスディスカバ理
分散するシステムのテストにおける複雑さ
分散するシステムの運用とデプロイの複雑さ
AWS上で追う地区
✤API Gateway + Lambda
✤EC2 + ECS
✤EC2 + Elastic BeanStalk
✤EC2 + ELB + ASG + Runtime
いっぱんてきなアーキテクチャ
EC2+ELB+ RDS:サーバー1台稼働させる必要
サーバーレスアーキテクチャ
API Gateway+Lambda:AWSサービスを呼び出す
CloudFront +S3
2ティア
Javascript SDKからAWSサービスを直接呼び出す
→課題解決される
API Gateway:フルマネージド型サービス
AWS Sigv4の利用、リクエストのスロットリングとモニタリング
レスポンスのキャッシュ
DDOS対策
Swaggerのサポート
SDKの自動生成
Lambda
アプリケーション実行
自動的にスケール他のサービスに連携できる
100ミリ秒単位
サーバーレスアーキテクチャのメリット
コスト効率高い
付加価値を生まない重労働からの解放
何をするかを書くだけで良い
→うまくあてはまれば・・・
すべての要件を満たせるとは限らない
→コンテナの採用
長時間処理にも
・コンテナ
プロセスの隔離:ポータブル、フレキシブル、速い、効率的
Docker:
パッケージ
ship
run
→効率的リソース管理
クラスタマネジメント docker run myimage
→dockerが100個以上あったら・・・コンテナ死んだら?
・コンテナのオーケストレーション:ECS
クラスタ管理を簡単に
フレキシブルなコンテナ配置
アプリケーション
バッチジョブ
:
・サービスディスカバリー
→DNS,HTTP経由のエンドポイント登録・けんさく
・クラウドネイティブなアプリ開発
The 12 Factor App(http://12factor.net/ja/)
モダンなWebアプリケーション開発のための方法論
直接的にマイクロサービスと関連する話ではないが、一読しておくべき
コードベース
依存関係
設定
ビルド
プロセス
ボートバインディング
並行性
廃棄容易性
本番一致
ログ
管理プロセス:CI
・アプリケーションの実装パターン
いくつかの典型的なパターンがある
どのやり方が許容できるかはチームで決めること
最初に選んだやり方を最後まで貫く必要はない
・Graceful Degradation:500エラーを返すな。全体をエラーにしない
・Throttling:内部サービスによる偶発的DoS→API Gatewayを使えば簡単にできます
・Fail Fast:エラー検知したら早く返す
・Fail Silently:エラーは内部で気に処理しユーザーに成功返す
・Static Fallback:なにかかえす
・Retry:シンプルにリトライで成功すること多い。Exponential back off フィボナッチ数列
・Caching:キャッシュ有効活用
・Circuit Breaker:フォールバックプラン実行
・Think ぱられる
・smooth internal traffic:キューの利用
クラウドネイティブなデプロイ
・DevOps:ソフトウェア開発のライフサイクル
モノリシックな開発サイクル
The Amazon Way : 2 Pizza Rule 2枚のピザで賄える人数→サービスチーム
プロダクト開発(ロードマップ)
開発
運用
サポート
you build it,You run it
デリバリパイプライン
AWS DevOps Services
Code Pipeline:継続的デリバリとリソース
Code Deploy:オンプレにも
CodeCommit:Gitリポジトリ