【レポート】最新アーキテクチャの原則から実現まで!「モダンアプリケーションのためのアーキテクチャデザインパターンと実装」 #AWSSummit
はじめに
CX事業本部の佐藤智樹です。
今回は「モダンアプリケーションのためのアーキテクチャデザインパターンと実装」のセッションを聞いたのでレポートします。
これからマイクロサービスやサーバーレスなど新しい設計に挑戦する場合や既に取り入れている場合に、アーキテクチャデザインの指標として非常に参考になるセッションだったので是非動画を見てください。
セッションではモダンアプリケーションに対する定義を最初に示したのちに、Beyond the Twelve Factor Appの各要素がそれぞれどのような原則なのかまず抽象的な考えから入り、具体的にAWSサービスを使うならどのように実現できるかという流れで一貫して紹介されていました。
マイクロサービスやサーバーレスなどの設計は抽象例だけだと難しく、具体例だけでは機能にフォーカスしすぎて何が解決したかったのかが不明確になりやすいと感じています。
このセッションではどのような問題を解決するアーキテクチャパターンがあるのか紹介し、どのAWSサービスがアーキテクチャの実装に使えるかまでの繋ぎが分かりやすく構成されています。
本記事では、発表された内容をかいつまんで紹介していきます。
レポート
スピーカー: AWSJ 清水崇之さん(@shimy_net)
セッションページ:AWS-21: モダンアプリケーションのためのアーキテクチャデザインパターンと実装
概要
IT アーキテクチャのトレンドはモノリシックから SOA を経てマイクロサービスへと変遷してきましたし、日々さまざまな技術要素が目まぐるしくタイムラインを走り抜けます。この変化する世界において、一貫して俊敏で柔軟なモダンアプリケーションを実現するためには、最適な実装を選定しつつ拡張性の高いアーキテクチャをデザインしなくてはなりません。「イベントドリブンが流行っているから使ってみよう」ではダメなのです。我々アーキテクトは原理原則を尊重しつつ、あらゆる事象への理解を深めなくてはなりません。12 Factor App などの方法論やアプリケーション実装のためのデザインパターンを理解することは極めて重要です。このセッションでは、一般論としてのアーキテクチャやデザインパターンなどを紹介しつつ、それらを実現するために AWS でどのようにすればよいのか説明します。
背景
- 現在のアプリ開発の背景にある課題(労力が割かれている作業)
- アプリケーション構築
- インフラ構築
- 企業やチームがビジネスを成功させるためにはマーケットへの高速なリリースが必要
- 高速なリリースが可能なチームや企業は、アプリの設計・構築・運用を継続的に革新している
- 今回は継続的な革新ができることをモダンアプリケーションと定義する
- モダンアプリケーションには様々な用語が登場する
- サーキットトブレーカー
- REST API
- CQRS
- マイクロサービス etc
- 最初はどこから始めれば良いのか分かりづらい
- そこで一般論としてどのように設計を考えるのか紹介する
Beyond the Twelve Factor Appの紹介
- 昔はTwelve Factor Appが方法論の一つとしてあった
- 10年前の考え方ではあるのでコンテナやLambdaなどの状況も今とは違った
- 現代によった考え方としてBeyond the Twelve Factor Appがある
- モダンアプリケーション開発向けにアップデートされたもの
- オレンジ部分のAPIファーストや認証/認可、テレメトリなどが追記されている
- 全体で見ると関連がわかりづらいので、簡単化するためにざっくりと分類して紹介を行う
疎結合・相互運用
- Beyond the Twelve Factor App内の要素
- APIファースト
- バックエンド
- ポートバインディング
- 認証・認可
APIファースト/認証・認可
- APIはマイクロサービスの入り口となり二つの要素で構成する
- ゲートウェイ
- バックエンドへの呼び出しにゲートウェイを使って必要な処理をまとめる
- ロールベースアクセス制御
- 従来はIPによる認証の制御が多かったが、サーバーのスケーリングなどを考慮するとIPは一時的な可能性が高い
- そこで認証はロールに応じて行うような設計が必要
- AWSで実現するならばAPI Gateway(ゲートウェイ)+Cognito(ロールベースアクセス)で構築できる
バックエンド/ポートバインディング
- ディスクにデータを書き込むのでなくデータストアや認証のサービスを利用する
- ファイルストレージやDBをただのリソースと考えてアプリケーションのデプロイ不要で切り替えができるよう構成する
- バックエンドサービスから1つの観点を紹介
- ポリグロットパーシステンス
- 1つのデータストアだけでなく用途に応じて最適なデータストアを使い分けるという考え方
- トランザクションが必要なデータならRDBMSを、JSONデータならNoSQLサービスを利用する
- AWSでRDBMSならAurora、NoSQLならDynamoDBを使用するなど適所に応じて使い分ける
- 技術者のスキルセットに関する考慮も必要
サービス間相互運用の安定性を高める
- ひとつのサービス障害が全体に伝播しないようにするためのデザイン
- タイムアウト
- スロットリング
- リトライ
- サーキットブレーカー
- バルクヘッド
- サービスディスカバリ
- 上記三つはLambdaを使うことで実現できる
- 詳しくはRelese it 2nd Edition参照
時間の関係上一部のみ紹介
- サーキットブレーカーパターン
- サービス間の障害数をカウントし一定以上障害数でブレーカーをオープン状態にして切断する
- バルクヘッドパターン
- アプリケーションの要素を分解して、1つの要素の障害で全体が機能不全となることを防ぐ
伸縮性・弾力性
- Beyond the Twelve Factor App内の要素
- ログ
- 廃棄容易性
- ステートレスプロセス
- 並行性
- アプリケーションが伸縮性・弾力性を実現するためには上記3つが必要
- 従来通り仮想マシンやコンテナを使うこともできる
- Lambdaであればインフラの管理を最小限に抑えられ、並列性を含めた全てを満たす設計が可能
伸縮性・弾力性を高めるデザイン
- セッション内ではデータストアの伸縮性のみとりあげ、他のものは資料のAppendixに記載
コマンドクエリ責任分離(CQRS)
- リード・ライトのスループット、レイテンシー、整合性などが異なる場合は単一のデータストアで全てのデータを処理するには限界がある
- そこでコマンドクエリ責任分離(CQRS)を使う
- 更新と参照のワークロードを分離して管理する
- RDBMSのリードレプリカも広義の意味で言えばCQRSにあたる
- 例えば書き込みだけDynamoDB、読み取りだけAuroraを使うようなパターン
- CQRSはドメインレベルの競合を起こさずにスケールできる
イベントソーシング
- データを直接更新せずにデータに対して実行したイベントを記録しておくことで状態を再生する
- 送金などで口座へ金額をマイナスするイベントを残すイメージ
- AWSではKinesisやSQSを使用してイベントログを集約し、Lambdaでイベントを実行することで実現できる
モニタリング
- Beyond the Twelve Factor App内の要素
- ログ
- ログは原則としてローカルに標準出力せず1つの箇所に集約する。
- テレメトリ
- アプリケーションのパフォーマンス
- ビジネスのためのデータなどを分析するべきという考え方
- Lambdaを使えばログはCloudWatchLogsに集約され、パフォーマンスのモニタリングがX-Rayで出来る
自動化・継続性
- Beyond the Twelve Factor App内の要素
- 1コードベース、1アプリ
- 依存関係管理
- 設計、ビルド、リリース、実行
- 設定、クレデンシャル、コード
- 環境一致
- 管理プロセス
- CI/CDは素早いデリバリには必要不可欠
- 依存関係、設定、環境周りはAWSだとCloudFormation、CDK、SAMなどが使用できる
- ステージ構成やカナリアリリースなど柔軟なリリースが可能
詳細は別セッション参照:
AWS-26:AWSの継続的インテグレーション/デリバリー総まとめ!モダンアプリケーション構築のための CI / CD ベストプラクティス!
まとめ
- AWSを使用すればBeyond the Twelve Factor Appの原則に沿ったアーキテクチャが作成可能
- 特にLambdaを使用すればインフラへの労力を削減して、紹介してきた原則をうまくカバーできる
- ただ1つのアーキテクチャに盲信せず、アーキテクチャの構築にはビジネスも含めた全体を観測してバランス感覚をもつことが重要
所感
ただ漫然とAWSのサービスを利用しているだけでもある程度は自然とBeyond the Twelve Factor Appの原則に乗っかれてはいます。
しかし、どんな問題に対して特定のアーキテクチャを選定しているのかある程度理解しなければよくあるアーキテクチャパターンを盲信して構築し、実現したいビジネス・システムに適していないアーキテクチャを採用する可能性もあります。
このセッションがモダンアプリケーションの原則を理解して実践するためのとっかかりとして非常に有効だと感じました。自分も今後アーキテクチャを検討する上でこの動画を折に触れ参考にしたいと思っています。
今回レポートは初めてだったので拙い内容ですが元のセッションの動画や資料が少しでも広まれば幸いです。
AWS Summit 2020期間中に他のレポートもDevelopers.IOに随時アップロードされていくので是非ご確認ください。