【AWS】「アーキテクチャ」の種類(モノリシック、SOA、マイクロサービス、サーバレス)

モノリシックアーキテクチャ

一つの構成図の中に様々なアプリケーションが含まれる構成です。一つの構成の中に様々な機能を含む形となります。

メリット

• 開発しやすい。
• 大きな変更を加えやすい。
• テストしやすい。
• 一つのjarになっているのでデプロイしやすい。
• 障害調査しやすい。

デメリット

• 時間と共に肥大化して手に追えなくなる。
• 影響範囲の特定が難しくなる。
• コンパイルの時間が長くなる。
• リリースする際にさまざまなモジュールの開発者との調整が必要になる。
• 何かしら問題があるとシステムの全てをロールバックする必要がありリスクが高まります。
• アプリが大きくなり転送遅延（デリバリー）が発生する可能性が高まります。
• 耐障害性が低い。（一部分が落ちたら全体が落ちる。）
• 技術が陳腐化した時の更新が難しい。

SOA(サービス指向アーキテクチャ)

いくつかのコンポーネントがWebサービスのAPIを提供していてそれぞれ相互に連携しあう構成です。システムの機能単位を業務単位で決めていく設計手法になります。

メリット

インフラが分離しているのでインフラやリソースの管理を独立して考えることが可能です。

構成

下記の3層構成にします。

• プレゼンテーション層
• ロジック層
• データ層

マイクロサービスアーキテクチャ

近年、サーバーサイド開発で小さくアプリケーションを作っていくスタイルが定着しつつあります。サーバーレスアーキテクチャの一つのサブセットになります。

特徴

• SOAのモジュールをより細かくして単一の機能を持つモジュールに分割していきます。
• 少人数でより深く単一の機能を開発することが可能
• Dockerとの親和性が高い。
• デリバリーのパイプラインがそれぞれのモジュールで生まれることになり早く開発サイクルを回せる。

SOAとマイクロサービスアーキテクチャの違い

	SOA	マイクロサービス
アーキテクチャ	リソース共有(サーバーが一つ）	独立したサービス(サーバーが複数）
コンポーネント共有	共有する	共有しない
サービス粒度	比較的大きい	非常に小さい
データ	共有DB	独立DB
サービス間通信	ESB(Enterprise Service Bus)	メッセージブローカー
通信プロトコル	SOAP	REST、gRPC

サーバレスとは？

サーバ管理が不要

柔軟なスケーリング

アイドル時のリソース確保が不要

アイドル時に課金が発生しない。リソースの確保が不要

組み込まれた高可用性

サーバレスのメリット

アプリの本質に集中できる。

ロジックの開発に注力でき、デベロッパーの生産性が向上し、マーケットに対するスピードを向上させることが可能。

サーバー構成を変えなくて良い。

小規模開発から大規模開発までサーバー構成を変えなくて良いです。

サーバレスのデメリット

サーバーが常に起動しているわけではないので即応性が低いことです。なので実行頻度が少ないシステムの実行に適しています。

サーバーレスのAWSサービス

ビルディングブロック（サービスの組み合わせ）で簡単に構築が可能

Lambda

アプリケーションをアップロードするだけで使える。

S3

課金のされ方

• コール回数

サーバレスの概要図

API Gateway

APIを作るためのサーバレスサービス

Lmbda

APIの独自ロジックを記述します。

DynamoDB

キーバリュー型のデータベース

デザインパターン

モバイルバックエンド（普通の同期通信）

サーバレスのデザインパターンで最もよく利用されるパターンらしいです。

ユースケース

• API公開の典型的なサーバレスアーキテクチャパターン
• REST APIによるリクエスト/レスポンスを利用して同期的にDBとやり取りする。
• SPAやモバイルアプリで多用される。

設計のポイント

• レガシーなWebやAPIサーバの置き換えに使う。
• 呼び出しに30秒を超える場合は非同期呼び出しを検討する。
• Cognitoとの連携等、認証、認可についても検討する。

業務APIグループ企業間API

ユースケース

内部データの公開ルートをAPI化します。

設計ポイント

API GatewayのVPCエンドポイント対応によりプライベートなAPIを作成することが可能

API Gatewayのキャッシュ機能により負荷を軽減することが可能

LambdaのHyperplane ENIによるVPCリソースへのアクセスが可能

Hyperplane ENIによりLambdaのオーバーヘッドなくアクセスすることが可能です。

RDSへのアクセスがバーストする場合はAmazon RDS Proxyの利用も検討すること

モバイルバックエンド（リアルタイム通信）

リアルタイム通信要件や、非接続状態（オフライン）のモバイル向け

AppSync

「API Gateway」の代わりに使えばリアルタイム通信をすることが可能です。

ワークフロー（アプリケーションワークフロー）

ユースケース

• 一連の処理フローを可視化する。
• エラー処理のフロー管理として利用可能です。

設計のポイント

AWS Step Functionsによってリトライや例外処理を宣言的に設定することが可能

個々の処理を非常にシンプルに保つことが可能です。

Step FunctionsからStep Functionsの呼び出しや他の処理の完了を待機してから再開することも可能

例えば、「人間の承認を得てから次の処理を行う」ということも可能です。

画像処理に使うパターン

• 画像の加工(サムネイル)やリサイズや数値計算ができる。
• 文字変換
• 並列に呼び出し完了時間を短縮することも可能です。

トリガー

• 画像ファイルアップロードをきっかけにファイル情報を引き渡して処理を起動する。

設計ポイント

Amazon S3からAWSをLambdaを非同期に呼び出す。

関数からエラーが返された場合は最大2回再試行

スロットルエラー(429)及びシステムエラー(500番台）の場合はLambdaはイベントをキューに返して最大6時間再実行。

再実行回数、イベントの最大有効期間は設定可能

Amazon S3のイベント発行はAt Least Onceなので発火漏れはないが重複して呼び出された場合は考慮する。

Amazon Alexa スキル　チャットボット

テキスト入力やAlexaからの音声入力に反応にしたイベント処理です。スキルをLambda上に作成することが可能です。

コードを記述する際に意識すること

コードはステートレスに記述する必要がある。

データは切り離す。

イベントとAPIを通じたコミュニケーションを意識する

イベント駆動の業務処理連携

かなり色々な企業で導入されているイベント駆動アーキテクチャです。

ユースケース

タスクをSQSキュー(S3)にプッシュして非同期で連携します。また、最近は「FIFO SNS」、「FIFO SQS」を組み合わせて順序性が重要なサービスの実装も可能になっています。

SNSトピック

業務のイベントとして設計、一つのトピックに対して複数の処理を並列して実行することも可能です。（ファンアウトパターン）

SQSキュー

一旦、ここに保存することで信頼性を担保します。後続のLambdaに処理を依頼します。

4つのアーキテクチャを実現するためのAWSツール

• EC2
• ECS
• Lambda
• AWS TrustAdvisor
• Elastic Beanstalk
• OpsWorks