😊

AWSによるマイクロサービスの基本アーキテクチャ

に公開

はじめに

AWSによるマイクロサービスの基本アーキテクチャを設計してみたので、共有します。題材としてBtoB向けの課題管理ができるアプリケーションを構築するシナリオで考えてみました。ベースアーキテクチャまでなので、具体的なビジネス要件で求められる詳細な情報は省略しています。また、サーバーレスでないサービスを使わなければいけないケースはビジネス要件として何か特別な理由がない限り必要ないと思いますので、全てサーバーレスで設計しています。

システムの要件

ユーザー向け要件

  • Webインターフェース: ユーザーが直接操作するサービスは、Webブラウザ経由で提供されること。
  • シングルサインオン (SSO): ユーザーは1度のログインで、提供される全てのフロントエンドサービスを横断して利用できること。

システムアーキテクチャ要件

  • サービス間連携: 各マイクロサービスは、ビジネスロジックを実現するため、必要に応じてバックエンド間でセキュアに連携できること。

今回構築する主要マイクロサービス

認証サービス

ユーザーのサインアップ、ログイン処理を担当し、システムへのアクセスが正当であるかを検証します。

ユーザー管理サービス

ユーザーのプロフィール情報(氏名、所属など)を一元管理しますが、パスワードなどの認証情報は扱いません。

課題管理サービス

タスクやバグといった「課題」を作成し、その担当者やステータス(進捗状況)を追跡・管理するための中心的な機能を提供します。

通知サービス

「新しい課題が割り当てられる」といった、システム内でのユーザーのアクションや出来事をきっかけに、関係者へメール等の通知を送信する役割を担います。

アーキテクチャ図

アーキテクチャ図の解説

  1. 認証サービスがOIDCトークンを発行し、ユーザーはブラウザ経由で各マイクロサービスのBFFと直接やりとりをします。
  2. ④、⑨のBFFはGraphQLを想定していますが、API Gateway(REST API)でも問題はありません。
  3. ②、⑤、⑩のバックエンドはAPI Gatewayを前段に置き、ロジックを処理するサーバーや永続化するデータベースはビジネス要件によって柔軟に選ぶことができます。
  4. ユーザーサービス内で発生するイベント(ユーザー作成、ユーザー更新、ユーザー削除)は、⑥のイベント公開ではEventBridgeのカスタムイベントバスにPutEventsし、他のマイクロサービスが購読できるようにします。
  5. ⑫のイベント購読では、⑥から公開されたイベントを購読しています。ポイントは⑥のイベントルールのターゲットとして⑫のカスタムイベントバスを指定しているところです。ターゲットをカスタムイベントバスにすることで、課題管理サービスがイベントを正常に処理できなかった場合に、課題管理サービスだけの影響範囲でアーカイブをリプレイすることができるため、他のマイクロサービスへの影響を及ぼしません。
  6. ⑥と⑦、そして、⑪と⑫は、それぞれ別のカスタムイベントバスに分け、自サービス内で発生したイベントを公開するための用途と、他のサービスで発生したイベントを購読するための用途で使うことで役割を明確にします。
  7. 課題管理サービスのブラウザ画面に表示する目的で、ユーザー一覧を取得したい場合は、⑨から⑤へHTTP通信(同期通信)します。※実際にはサービス固有の権限を管理するため課題管理サービスの方にもユーザー(権限)データを持つことになるので不要です。今回はサンプルなので簡易版になります。
  8. ユーザーへ通知を送る場合は⑬のEventBridgeでリクエストを受け付けます。
  9. 各マイクロサービスは通知サービスへ通知を依頼したあとは、送達結果をイベント(⑦、⑫)で受け取ります。⑫のイベント購読では、ユーザーサービスのイベントと通知サービスのイベント、両方を受け取っています。

今回省略していること

  • 各通信は、それぞれの認証方法がありますが、今回は言及していません。
  • セキュリティ要件によってネットワークをどこまで限定するかについて、今回は言及していません。
  • 各マイクロサービスは全て別々のAWSアカウントを想定していますが、クロスアカウントの通信における、IAMロールの運用の仕方について、今回は言及していません。
  • バックアップと障害復旧の考え方について、今回は言及していませんが、結果整合性で構成されているものについては、イベントのアーカイブリプレイで復旧することを基本としています。
    ひとつひとつが、深いテーマなので今回は言及できませんでしたが、いつかテーマとして取り上げてみたいと思います。

おわりに

今回のアーキテクチャを基本として、サーバー負荷要件や、セキュリティ要件などによって構成を変えていく感じで考えてみました。たとえば常時高い負荷がかかり続けるサービスなら、プロビジョンサービスを選んだり、厳しいセキュリティ要件があるなら、VPCの内部にサーバーを構築するなどといった感じです。

レスキューナウテックブログ

Discussion