【レポート】クラウドネイティブなモダンアプリケーション開発を始めよう！クラウドネイティブ設計とデプロイメントパターン #AWSSummit

AWS Summit Tokyo 2019

#AWS

#イベントレポート

佐伯航

2019.06.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、佐伯です。

AWS Summit Tokyo 2019 Day3に行われたセッション「クラウドネイティブなモダンアプリケーション開発を始めよう！クラウドネイティブ設計とデプロイメントパターン」のレポートを書きましたのでご覧頂ければと思います。

セッション概要

オンプレミスのシステムを単純にクラウドへ移行するだけではクラウドの様々なメリットを享受することはできません。このセッションではクラウドネイティブなモダンアプリケーションの開発について、AWSの各種サービスをアプリケーションブロックとして利用するアプリケーション構成やAWSの各種サービスを利用したCI/CDの実現についてアーキテクトやデベロッパーの観点で解説します。

セッションレポート

Agenda

なぜモダンアプリケーションなのか
モダンアプリケーション開発とは
モダンアプリケーションの実装パターン
AWSにおける継続的インテグレーション/デリバリーの実現

なぜモダンアプリケーションなのか

急速なイノベーションはもはや必須

利益を伸ばす
- 今ある人材を活用
新たな機会を探索
- 新しいアイデアを育てる
新たなマーケット
新たな顧客価値
新たなデジタル製品とサービス

実験→傾聴→反復がイノベーションを加速する

AWSのイノベーションのペース

2017年は1430の新たな機能、サービスをリリース

数千のチーム
マイクロサービスアーキテクチャ
継続的デリバリー
複数の環境
様々なタイプのデプロイ
年間数百万回のデプロイ

モダンアプリケーション開発とは

AWSアプリケーションのモダン化のパターン

全部マイクロサービス化やサーバーレス化する必要はない、ひとつずつ調査し優先順位付けをしモダン化のパスを決定することが大事。

Re-host(list-and-shift)
- ほとんど変更する必要のない社内システムなど
- オンプレ -> EC2
Re-platform(lift-tinker-shift)
- 並列処理が可能なバッチアプリケーション
- VM -> コンテナ
Re-architecture
- 機能追加要求が多い、大規模アプリケーション
- モノリス -> マイクロサービス
Re-invent(CloudNatibve)
- 迅速なリリースとアップデートを繰り返す新規アプリケーション
- 最初からサーバーレス化やマイクロサービス化を検討

モダンアプリケーションの能力

Secure
Resilient
Elastic
Modular
Automated
Interoperable

モダンアプリケーション開発のベストプラクティス

アプリケーションのライフライクル全体に渡ってコンプライアンスとセキュリティを構築
アプリケーションの構造をマイクロサービスに集まりにする
可能な限りサーバーレスの技術で構築する
アプリケーションのモデリングとインフラにコードを利用する(IaC)
CI/CDを利用して高品質な昨日を迅速にリイリースする
モニタリングによってアプリケーションの振る舞いの洞察を得る

アプリケーションのライフライクル全体に渡ってコンプライアンスとセキュリティを構築

ライフライクルをセキュアにすることでイノベーションの速度を落とすことなく脅威に対応
強力なアクセス制御で認証されていないアクセスを防ぐ
柔軟なポリシーを使用してロールベースのアクセス制御を実装する
アプリケーションの振る舞いを評価し、コンプライアンス要件に従っていることを確認する
各ステップを検証する
イノベーションの速度を下げすにセキュリティを担保
自動化された、継続的なセキュリティ評価が必要

AWSをセキュリティオートメーションツールボックス

ID管理
発見適当性
インフラストラクチャ保護
データ保護
インシデントレスポンス

アプリケーションの構造をマイクロサービスに集まりにする

変更の影響は小さくなると、リリースの速度が向上可能になる
モノリス(すべてを実行) -> Microservices(ひとつのことを実行)
APIと疎結合なコミュニケーションが自動化を可能にして信頼性を向上
イベント駆動にすることで非同期化、一方のサービスが停止してたとしてもキューイングで継続することができる。
ワークフローで複数のサービスを連携することで、敏捷性、生産性、および柔軟性が向上
データと処理の状態をトラッキング、冗長なコードを削除
AWS StepFunctionsのようなワークフローサービス

可能な限りサーバーレスの技術で構築する

自動化と抽象化によって課題から開放

インフラのプロビジョニングや管理が不要
利用単位ごとにオートスケール
価値に対して支払う課金モデル
高い可用性と耐久性

サーバーレスアーキテクチャは最小の努力で最大のアジリティを提供

ユーザーはAPIの設計とビジネスロジックにフォーカスできる
コンピュートの選択はトランスフォーメーションの革新
サーバーレスファンクション(AWS Lambda)
- イベント駆動な処理がマッチしている
サーバーレスコンテナ(AWS Fargate)
- ロングランニングやバッチ処理に向いている

アプリケーションのモデリングとインフラにコードを利用する

すべてをソフトウェアとして扱うことでインフラのデプロイスピードとアジリティを向上
アプリケーションのコードの記述、インフラテンプレートの作成
設計→スタックの作成→繰り返し

AWS Cloud Develoipment Kit (CDK)

CloudFormationはYAML/JSONで記述するが、AWS CDKはJavaScript, Java, TypescriptやC#などプログラミング言語で記述しCFnテンプレートを生成。

CI/CDを利用して高品質な機能を迅速にリリースする

CI/CDを自動化しているチームはコードをより早く、自信を持ってコードを書いている。

頻繁なデプロイが 33倍増加
リードタイムが 440倍減少
ミスが 60倍減少
予期しない作業を 21% 削減
新しい作業にあてる時間を 44% 増加

AWS Developer Tools for CI/CD

AWS Codepipeline
AWS CodeCommit
AWS Codebuild
AWS CodeDeploy
AWS X-Ray

モニタリングによってアプリケーションの振る舞いの洞察を得る

より早く問題を識別すると、より早く解決できる

メトリクス、ログとトレース
モニタリング、デバッグ、アラート
リソース、アプリケーションの可視化
リアルタイムインサイト

分散されたアプリケーションをどの様に可視化すべきか

モノリシックアーキテクチャはサーバーのモニタリングしてればよかったが、マイクロサービスアーキテクチャは分散しているため情報の収集と可視化が必要となる。

CloudWatch
- アプリケーションのモニタリング
- パフォーマンス変化に応答
- リソース使用率を最適化
- オペレーショナルヘルスを一元管理
AWS X-Ray
- リクエスト動作の確認
- 性能のボトルネックを特定
- 根本原因をトラブルシュート

モダンアプリケーションの実装パターン

APIゲートウェイパターン

APIゲートウェイパターンはバックエンドのAPI呼び出しが多いサービスや、デバイスごとにコンテンツを変えたりするサービスに向いている。

AWSサービス: AWS API Gateway
- スロットリング機能
- キャッシュ機能
- 認証認可機能
- AWS APIへのプロキシサービス

サービスディスカバリ/サービスレジストリパターン

マイクロサービス化するとお互いがお互いのサービスの場所を見つける必要がある。起動時にサービスレジストリに自身の情報を登録、呼び出し側はサービスディスカバリを呼び出してアクセス先を見つける。

AWSサービス: AWS Cloud Map
- DNS名前解決
- ARNによる解決

サーキットブレーカーパターン

サービス間連携があるとき呼び出し先のサービスに障害が発生した場合、呼び出し元が再試行を繰り返してしまう。サーキットブレーカーは呼び出しサービス障害時は安全に機能低下しつつ、復旧した場合はリクエストを受け付ける。

定期的に呼び出し先のAPIを監視
サービスが落ちた場合は即座エラー応答
復旧したら使えるようにしてくれる

サイドカー方式でサーキットブレーカーパターンを実装するパターンが多い。

Amazon ECS: Linkerd を作る
Amazon EKS: Istio + Envoyを使う

コマンドクエリ責務分離パターン(CQRS)

コマンドクエリ責務分離はデータの読み込みと書き込みは違うものだという前提に基づく考えたもの。更新と参照でデータソースを分離、それぞれスケールできるように設計。注意事項: 書き込み後に読み込み用データソースに反映するので結果整合性を許容できる場合に採用できる

DynamoDB -> DynamoDB Stream

イベントソーシングパターン

データの更新をイベントとして共有する
イベントリストにストア、プロセスを再生することでデータソースを更新
CQRSパターンの組み合わせられる
Amazon Kinesis -> AWS Lambda

コレオグラフィーパターン

マイクロサービスにおいて各サービスが自立して動作するのがコレオグラフィ。対比としてひとつのサービスが関連する個々のサービスを呼び出すオーケストレーションと言う。

Amazon SNS -> Amazon SQS -> AWS Lambda

集約ログパターン

マイクロサービスそれぞれにまたがった情報をどうやってまとめるか。

Amazon CloudWatch Logs
AWS X-Ray

Polyglotパーシステンスパターン

異なるデータ処理のニーズに対しては異なるデータストレージテクノロジーを利用すると言うコンセプト。
システム全体で共通のデータソースを選択した場合、要件によってはパフォーマンスへの影響や実装の難易度があがる。
マイクロサービスごとで要件に最適なデータソースを選択することでパフォーマンスやスケーラビリティが向上するなどのメリットが生まれる

AWSにおける継続的インテグレーションと継続的デリバリー

継続的デリバリーの基本

バージョン管理されたソース
自動化されたソース
自動化されたデプロイメント
単体テスト、結合テスト
継続的デリバリ
オペレーションダッシュボード

シングルページアプリケーションのデプロイ

Amplify Consoleでソースの変更を検知してビルドとデプロイを実施。

AWS CodeCommit -> Amplify Console
- Amplify Console -> Amazon S3 -> Amazon CloudFront (フロントエンド)
- Amplify Console -> AWS AppSync -> Amazon DynamoDB (バックエンド)

認証が必要であればCognitoも連携できる

コンテナへのデプロイ

AWS CodePipelineでソースの変更を検知してパイプラインを開始。

AWS CodeCommit -> AWS CodePipeline -> Amazon S3 -> AWS CodeBuild -> Amazon ECR -> Amazon ECS

ECSへのBlue/Greenデプロイ

同様にAWS CodePipelineでソースの変更を検知してパイプラインを開始。CodeDeployでBlue/Greenデプロイ。

CodeCommit -> CodePipeline -> S3 -> CodeBuild -> ECR -> AWS CodeDeploy -> Amazon ECS

AWS Lambdaへのカナリアデプロイ

トラフィックコントロールが可能
10分間10%のトラフィックを新しいバージョンのAWS Lambdaへルーティングするなどが可能
AWS CodeCommit -> AWS CodePipeline -> S3 -> AWS CodeBuild -> Amazon S3 -> AWS CodeDeploy -> AWS Lambda

SAMテンプレートをベースにパッケージ化してデプロイする必要があり、CodeStarにサンプルテンプレートが一式入ってるので試してみるには簡単。