「Cognito User Profiles Export リファレンスアーキテクチャ」を試してみる

現代的な Web サービスとしてエンドユーザーに提供する際、ほぼ必ず実装しなければならないのがユーザーを管理する機能です。情報発信のみを目的とする blog のように機能がさほど多くない Web サービスであっても、コメントや「いいね」ボタンの履歴を管理しようとすると、すぐにユーザー管理とそれに基づく認証認可が必要になります。Amazon Cognito は、お客様が開発する Web サービスに対して、素早く簡単にユーザー管理、認証、認可の機能を実装できるフルマネージドサービスです。Amazon Cognito は、サービスに登録したユーザーを管理し認証認可基盤を提供するユーザープールと、AWS リソースに対する認可基盤を提供する ID プールから構成されます。今回の記事では、ユーザープールで管理されているユーザー情報のバックアップについて考えてみたいと思います。

Web サービスを提供する際、ユーザー情報は最も価値ある資産のひとつです。ですので、ユーザー情報が失われないように対策することはアーキテクチャの設計上避けては通れないポイントになります。Amazon Cognito は AWS によるフルマネージドサービスであるため、ユーザープールを作成いただいたリージョン内でのデータの保護については AWS が責任を持っています。一方、リージョン全域に渡る大災害が発生したり、あるいは人手による操作でミスが発生したりした場合には、ユーザー情報が失われてしまうリスクは残っています。

しかし、Amazon Cognito は、ユーザープールに保存されたユーザー情報をワンクリックでバックアップ・リストアする機能を提供していません。この問題を解決するのが、この記事でご紹介する「Cognito User Profiles Export リファレンスアーキテクチャ」です！このソリューションを使用することで、お客様はユーザープールの情報を定期的にバックアップしたり、任意のタイミングで任意のリージョンにリストアすることができるようになります。それでは、このソリューションのアーキテクチャについて詳細に見ていきましょう！

「Cognito User Profiles Export リファレンスアーキテクチャ」では、AWS Step Functions を利用してユーザープールのバックアップとリストアを管理します。このソリューションでは、プライマリリージョンのユーザープールのユーザー・グループ情報を Amazon DynamoDB のグローバルテーブルにバックアップするための Export Workflow と、新しいユーザープール（バックアップ元と同じリージョンでも別のリージョンでも可）にリストアする Import Workflow の 2 つの Step Functions workflow が提供されています。

これらの workflow や、関連する AWS Lambda 関数などのリソースは全て AWS CloudFormation のテンプレートとして提供されていますので、お客様はバックアップしたいユーザープールの ID など、わずかな設定情報ををご用意いただくだけで、簡単にこれらのリソースをデプロイしていただけます。

続いて、Export Workflow と Import Workflow をそれぞれ詳細に見ていきましょう。

Export Workflow は、プライマリリージョンのユーザープールに保存されているユーザー情報を読み出し、DynamoDB global table に保存します。Export Workflow が開始されると、まず複数の workflow が同時実行されることによる不具合を回避するため、“check state machine” 関数によって現在実行されている workflow の他に Export Workflow が実行されていないことを確認します。続いて、"check user pool configuration" 関数がユーザープールの設定を確認します。この点について、詳しくは後の「制約」の項をご参照ください。

ここまでの事前準備が整うと、続いて “sync users”、“list groups”、そして “sync group and users in group” 関数がユーザープールからユーザーとグループの情報を読み出して DynamoDB に保存します。最後に、“clean up backup table” 関数が Amazon SQS キューを利用しながらDynamoDB 上の古いレコードの削除を行い、DynamoDB 上の情報が最新であることを確認します。ここまでの処理が完了すると、“send messages” 関数が Amazon SNS トピックへ完了通知を発信します。

なお、上記「概観」の図にあるとおり、この Export Workflow は Amazon EventBridge によって定期実行されます。

Import Workflow は、DynamoDB にバックアップされたユーザー・グループ情報を読み出し、バックアップ元とは別のユーザープールにリストアします。Import Workflow が開始されると、Export Workflow と同様に複数同時実行を防ぐための “check state machine” 関数が実行されます。続いて、 “check new user pool” 関数が、リストア先のユーザープールに workflow からアクセスできること、およびユーザープールが空（ユーザーやグループが登録されていない状態）であることを確認します。

ここまでの事前準備が整うと、“scan table” 関数が DynamoDB 上のレコードを読み取って、グループ情報を新しいユーザープールに登録すると同時に、ユーザー情報などを Amazon SQS キューに挿入します。その後、“import users” や “update users” 関数が Amazon Cognito へユーザー情報を登録したり、グループへの所属情報を更新したりします。ここで、ユーザー関連の情報が一度 SQS に保存されるのは、Amazon Cognito へユーザー情報を登録するためにはユーザーが所属しているグループの情報が必要であるため、“scan table” 関数がグループ情報を全て新しいユーザープールに登録した後に、ユーザーとグループの所属関係が処理されることを保証するための仕組みです。また、“import users” 関数はインポートしたユーザーの sub 属性を含む mapping file を Amazon S3 バケットに保存します。この mapping file は、インポートに失敗したユーザーがいた場合に、事後のトラブルシューティングのために利用できます。ここまでの処理が完了すると、“send messages” 関数が Amazon SNS トピックへ完了通知を発信します。

なお、この Import Workflow はお客様が Step Functions のマネジメントコンソールや CLI などを使って任意のタイミングで実行開始していただくものになります。

本ソリューションでは、以下の AWS サービスを使用します。使用するサービスは全てフルマネージドなサーバレスサービスですので、本ソリューションを利用するためにお客様でインフラストラクチャの追加の管理をしていただく必要はありません。

このソリューションでユーザープールをバックアップするにあたり、ご留意いただきたい制約事項は以下の通りです。

• 以下の場合、このソリューションを用いたバックアップは行なえません。
  • ユーザープールで多要素認証が有効になっている場合。
  • ログインに使用できるエイリアスとして、E メールと電話番号の両方が許可されている場合。
    
• その他の機能制限
  • セキュリティの観点から、Amazon Cognito はユーザーのパスワードをエクスポートする機能を提供しないため、パスワードはバックアップされません。リストアされたユーザープールを使用する際には、ユーザーにパスワードをリセットしていただくようご依頼ください。
  • バックアップ元とリストア先のユーザープールでは、各ユーザーの sub 属性が変わります。アプリケーションのロジックにおいて、一意の ID として sub 属性を使用している場合は、バックアップ元とリストア先のユーザープールで sub 属性を対応させる必要があります。この際、バックアップ元のユーザープールで sub 属性をカスタム属性としてコピーしておくと、DynamoDB テーブルにバックアップできるようになり、リストア後のユーザープールで sub 属性の対応関係を確認するために利用できます。
  • Amazon Cognito 経由で登録されたユーザー情報のみバックアップできます。サードパーティの認証（ソーシャルログイン）を使用して登録されたユーザーの情報はバックアップされません。ソーシャルログイン経由で登録されたユーザーは、リストア先のユーザープールに切り替わった段階で再度ログインしていただくようご依頼ください。また、ID プロバイダーの設定も引き継がれないため、リストア先のユーザープールでバックアップ元と同様に設定してください。
  • ユーザープールのアドバンスドセキュリティ機能をご使用の場合、ログイン履歴はバックアップされません。
  • グループに紐づけられた IAM ロールの情報はバックアップされません。
  • 記憶済みデバイスの情報はバックアップされません。

なお、このソリューションがバックアップ元のユーザープールを変更することはありません。

「Step 1 テンプレートの指定」ではそのまま「次へ」をクリックします。

「Step 2 スタックの詳細を指定」でスタックの名前を指定し、いくつかのパラメータを設定します。各パラメータの役割は以下の通りです。

「ステップ 3 スタックオプションの設定」は変更せず「次へ」をクリックします。

※ ここまでの手順は米国東部リージョン（バージニア北部）で実行してきましたが、ここから先の手順は東京リージョンで実行します。

それでは最後に、東京リージョンの新しいユーザープールにユーザー・グループ情報をリストアしてみましょう！東京リージョンに作成したリストア先のユーザープールの詳細画面から、ユーザープールの ID をクリップボードにコピーしてください。

なお、何らかの理由（例：メールアドレスが未検証）でリストア先のユーザープールへのインポートに失敗するユーザーが多数いる場合、“Too many users have failed or been skipped during the import.” というエラーメッセージとともに Import Workflow 全体が失敗します。その場合は、S3 バケットに保存されている mapping file などを参照しながら、手動で失敗したユーザーの処理を行ってください。

ソリューションが不要になった場合、バックアップ・リストアのアーキテクチャ本体は CloudFormation のスタックを削除すれば一度に削除できます。また、バックアップ元・リストア先のユーザープールは別途手動で削除いただく必要があります（参考：ユーザープールの削除方法）。

今回の記事では「Cognito User Profiles Export リファレンスアーキテクチャ」のソリューションをご紹介しました。CloudFormation テンプレートを使った簡単な設定で、定期的にユーザープールの情報をグローバルにバックアップできることをご理解いただけたかと思います。冒頭でも述べた通り、Amazon Cognito はフルマネージドサービスではありますが、それでも不慮のデータ喪失に備えることは大変重要です。このソリューションを利用して、みなさんがより堅牢にユーザープール情報を管理できるお手伝いができれば幸いです。

builders.flash では、他にもさまざまな AWS ソリューションの紹介記事を投稿しています。これまでの記事は こちら の記事カテゴリーで「AWSソリューション紹介」に絞ってご覧ください。それでは、次回の記事もぜひお楽しみに！