AWSの各セッションの資料/動画、並びに一部お客様事例の資料/動画が7月1日より随時公開されます。
一番重要のやつ最初に書く - モダンアプリ開発のBest Practices
チェックリストにもご利用なれます。
- アプリケーションのライフサイクル全体に渡って コンプライアンスとセキュリティ を構築する
- アプリケーションの構造を マイクロサービス の集まりにする
- 可能な限り サーバレス の技術で構築する
- アプリケーションのモデリングとインフラにコード を利用する
- CI/CD を利用して高品質な機能を 迅速にリリースする
- モニタリング によってアプリケーションの振る舞いの洞察を得る
なぜモダンアプリケーションなのか
モダンアプリケーション開発は素早いイノベーションによって競争の差別化を作り出す
急速なイノベーションはもはや必須
- 今ある人材を活用
- 利益を伸ばす
- 新たな機会を探索
- 新しいアイデアを育てる
急速なイノベーションがビジネスを進化させる
- 新たなマーケット
- 新たな顧客価値
- 新たなデジタル製品とサービス
実験がイノベーションを加速する
- Innovation Flywheel と呼ぶ
- こんなサイクルを回す
- Experiment 実験
- Listen 傾聴
- Iterate 反復
AWSのイノベーションのベース
- 2017年1430 Updates
- 2018年19xx Updates
数千のチーム
x マイクロサービスアーキテクチャ
x 継続的デリバリー
x 複数の環境
様々タイプのデポロイ
-----------------------------
= 年間数百万回のデポロイ
AWS アプリケーションのモダン化パターン
- 1つずつ調査し、優先順位付け
- モダン化のパスを決定
- パス基本4種類
モダン化のパス種類
- Re-host (lift-and-shift)
- ほとんど変更する必要のない社内システム
- data center -> EC2
- Re-Platform (lift-tinker-shift)
- 並列処理が可能なバッチアプリケーション
- VMs -> containers
- Re-architecure
- 機能追加要求が多い、大規模アプリケーション
- monolith -> microservices
- Re-invent (cloud-native)
- 顧客が利用する迅速なリリースとアップデートを繰り返す新規アプリケーション
- new serverless microservices
モダンアプリケーションの能力
- Secure
- Resilient
- Elastic
- Modular
- Automated
- Interoperable
モダンアプリケーション開発のベストプラクティス
ここからはベストプラクティスの詳細、チェックリストにもなります。重要のやつは2回言います。
アプリケーションのライフサイクル全体に渡ってコンプライアンスとセキュリティを構築する
ライフサイクルをセキュアにすることでイノベーションの速度を落とすことなく脅威に対応
- Authenticate 認証
- Authorize 認可
- Audit & Govern 監査
- Validate 検証
AWS セキュリティオートメーション ツールボックス
- ID管理
- Identity and Access Management (IAM)
- Single Sign-On
- Organizations
- 発見的統制
- AWS CloudTrail
- Amazon CloudWatch
- Amazon GuardDuty
- Amazon Inspector
- インフラストラクチャ保護
- Amazon VPC
- AWS WAF
- AWS Shield Standard
- データ保護
- AWS Key Management Service (KMS)
- AWS Certificate Manager (ACM)
- インシデントレスポンス
- AWS Lambda
- Amazon CloudFormation
- AWS Step Functions
アプリケーションの構造をマイクロサービスの集まりにする
モノリシックが悪いというのではありません。
- 変更の影響は小さくなると、リリースの速度が向上可能に
- APIと疎結合なコミュニケーションが自動化を可能にして信頼性向上
- ワークフローで複数サービスを連携することで、俊敏性、生産性、および柔軟性向上
可能な限りサーバレスの技術で構築する
自動化と抽象化によって課題から解放
- インフラの管理が不要
- オートスケール
- 価値に対して支払う、課金モデル
- 高い可用性
最小の努力で最大のアジリティを提供
- Focus on creating business value
- Remove heavy lifting with serverless everything
コンピュートの選択はトランスフォーメーションの核心
- AWS Lambda
- サーバーレス ファンクション
- イベント駆動
- 多言語ランライム
- データソースとの統合
- サーバー管理不要
- AWS Fargate
- サーバーレス コンテナ
- ロングランニング
- バッチ処理
- オーケストレーション
- クラスタスケーリング
モデリングとインフラにコードを利用する
全てをソフトウエアとして扱うことでインフラのデプロイのスピードとアジリティを向上
- インフラのBlue/Greenデポロイがおすすめ
- アプリケーションコード + インフラテンプレートの作成
- 設計
- スタックの作成
- 繰り返し
AWS Cloud Development Kit (CDK)
Developer Preview中、本番で使わないこと、Breaking Change多い
https://github.com/awslabs/aws-cdk
CI/CDを利用して高品質な機能を迅速にリリースする
CD/CDを自動化しているチームは、コードをより速く、自信を持ってかいている
提供元:https://puppet.com/resources/whitepaper/2017-state-of-devops-report
- 30倍、頻繁なデポロイ
- 440倍、リードタイムの短縮
- 60倍、ミスが減少
- -21%、予期しない作業の削減
- +44%、新しい作業着手
AWS Developer Tools for CI/CD
- Source
- AWS CodeCommit
- Build
- AWS CodeBuild
- Test
- AWS Codebuild + ThirdParty
- Deploy
- AWS CodeDeploy
- Monitor
- AWS X-Ray
モニタリングによってアプリケーションの振る舞いの洞察を得る
より速く問題を識別すると、より速く解決できる
- 上から推移順
- Monitoring
- メトリックス、ログとトレース
- モニタリング、デバッグ、アラート
- リソースとアプリケーションの可視化
- リアルタイムインサイト
- Observability
分散されたアプリケーションをどのように可視化すべきか?
- Amazon CloudWatch
- クラウドソースとアプリケーションに可視化をもたらす
- アプリケーションのモニタリング
- パフォーマンス変化に応答
- リソース使用率を最適化
- オプレーションヘルスを一元観察
- AWS X-Ray
- プロダクション環境、分散アプリケーションを分析とデバッグ
- 性能のボトルネックを特定
- 根本原因をトラブルシュート
- あらゆるアプリケーションのユーザーリクエストをトレース
モダンアプリケーションの実装パターン
マイクロサービスアーキテクチャをメインに紹介します。各パターンの詳細は省略します。実際使用するAWSのサービスを記載します。
API ゲートウェイ パターン
Amazon API Gateway
サービス ディスカバリ/サービス レジストリ パターン
- AWS Cloud Map
- DNSよるも可能
サーキット ブレーカーパターン
- ECS (Linkerd)
- EKS (Istio + Envoy)
コマンドクエリ責務分離パターン(CQRS)
- UpdateとQueryのデータソース分離
- UpdateとQueryの非同期でデータ同期するため、データ一致性が持たない
- 例:Update -> DynamoDB -> Lambda -> Aurora -> Query
イベント ソーシング パターン
- Event -> Queue -> State
- AWS Kinesis -> Lambda
コレオグラフィパターン
- request -> request queue -> services A, B, C
- Amazon SNS -> Fan out -> Amazon SQS -> AWS Lambda
集約ログパターン
- Amazon CloudWatch Logs
- AWS X-Ray
Polyglotパーシステン パターン
- Polyglot パーシステムは異なるデータ処理のニーズに対しては、異なるデータストレージ テクノロジーを利用するというコンセプト
- システム全体で共通の1つのデータソースを選択した場合、どのような要求も同じテクノロジーで実装しなければならず、要件によってはパフォーマンスへの影響や実装の難易度があがるなど弊害がある
- データソースがサービスごとに選択可能になるとクエリや更新の要件に最適なデータソースを選択することで、実損の難易度を下げ、パフォーマンスやスケーラビリティが向上するなどのメリットが生まれる
AWSにおける継続的にインテグレーションと継続的のデリバリーの実現
継続的デリバリーの基本
- バージョン管理されたソース
- 自動化されたビルド
- 自動化されたデプロイメント
- デプロイ > インスタンス
- 単体テスト
- 結合テスト
- 継続的デリバリ
- オペレーションダッシュボード
SPAのデプロイ - AWS Amplify Console
- Source: AWS CodeCommit
- Build : AWS Amplify Console
- Deploy: Amazon S3 -> Amazon CloudFront
- Deploy: AWS AppSync -> Amazon DynamoDB
コンテナのデプロイ - AWS CodePipeline
- Source: AWS CodeCommit
- Build : AWS CodeBuild
- Build Output: Amazon ECR
- Deploy: Amazon ECS
- Blue/Green Deployment
- CodeDeploy
Lambdaへのカナリア デプロイ - AWS CodePipeline
- Source: AWS CodeCommit
- Build : AWS CodeBuild
- Build Output: Amazon S3
- Deploy: AWS CodeDeploy
- Canary Deployment
- CodeStar
- 非常に簡単にできる