AvalonBay の不動産リースと検索のためのイベント駆動型ソリューション構築

このブログ記事では、スケーラブルで回復力のある不動産リースと検索のためのイベント駆動型サーバーレスソリューションを構築する方法を紹介します。このソリューションは、不動産投資信託 (REIT) の先駆者である AvalonBay Communities, Inc. 向けに開発されました。このソリューションにより以下が可能になります。

• 1 日あたり 150,000 件以上のマルチパラメータ検索
• 1 か月あたり 3,500 件以上のリース申請への対応と 85,000 件の家賃支払い処理

AvalonBay はエクイティ REIT です。同社は、米国の主要市場でアパートの開発、再開発、買収、管理を行ってきた長い実績があり、革新的なテクノロジーソリューションを使用して顧客に長期的な価値をもたらしています。AvalonBay はデータ主導型のインサイトがビジネスの成長に貢献することを理解していました。しかし、不動産から不動産管理システム、財務システム、会計システムまで、複数のデータセット間の複雑な相互依存関係を管理するには、新しいソリューションが必要であることに気づきました。

課題

AvalonBay は、2022 年 9 月 30 日現在、12 の州とワシントンD.C. の 88,405 戸の集合住宅を含む 293 のアパートコミュニティを直接的、間接的に保有しています。このうち 18 のコミュニティは開発中、 1 つは再開発中でした。こうした状況は、複数の地域で、様々な基準に基づいてアパートを検索して賃貸することを検討している社内外のユーザーとって課題となりました。たとえば、特定のアメニティ、賃貸条件、家具、空室日が設定されている建物内のユニットを見つけることが必要です。

ソリューション概要

AvalonBay の申込者と居住者向けのフルマネージド型のリーシングソリューションは、アマゾンウェブサービス (AWS) 上にホストされています。このソリューションは安全で、オートスケーリングが可能で、マルチリージョンに対応しているため、リソースを効率的に使用しながら耐障害性とパフォーマンスを確保できます。
このイベント駆動型のソリューションの中では、 AvalonBay のリーシングサービスが複数の AWS リージョン上にホストされており、さまざまな地域のユーザーに対して低レイテンシーの応答を提供します。
このブログ記事では、図 1 に示す1 つのリージョン (Region East) のみでのユースケース実装に焦点を当てています。

図1 : AvalonBay リーシング処理プラットフォーム

このソリューションには、会社の主要な目標を達成するために、いくつかの AWS サービスが統合されています。それぞれのアーキテクチャとその目的について見ていきましょう。

1. Amazon Route 53 : AvalonBay のリーシング処理ソリューションではサービス障害が継続してしまう状況は容認できません。リーシング処理はマルチ AZ アーキテクチャによって高い耐障害性を提供するだけでなく、マルチリージョンのアクティブ-アクティブ構成のアーキテクチャによって、リージョンレベルの高可用性を実現します。レイテンシーに基づくルーティングを備えた Amazon Route 53 では、数秒以内にリクエストを別のリージョンに動的に再ルーティングできます。
2. Amazon API Gateway : Amazon Route 53 のレイテンシーに基づくルーティングは、複数の AWS リージョンの API ゲートウェイエンドポイントにトラフィックをルーティングするように設定されています。Amazon Cognito ユーザープールを使用して API へのアクセスを制御するために API Gateway Authorizer が追加されています。
3. Provisioned Concurrency が有効化された AWS Lambda : AWS Lambda は複数のアベイラビリティーゾーンを跨いでオートスケーリングし、プライベートサブネットを介して保護されるよう設定されています。これにより、アベイラビリティーゾーン全体にわたる水平スケーリング機能、自己修復能力、耐障害性が実現します。 Provisioned Concurrency は、実行環境のセットアップによるコールドスタートを最小限に抑え、 API 呼び出しにかかる時間を大幅に短縮します。
4. Amazon Aurora Serverless v2 PostgreSQL 互換エディション : Amazon Aurora Serverless v2 は Amazon Aurora 用のオンデマンドの自動スケーリング設定です。リーシング処理ソリューションには、Amazon Aurora Serverless v2 PostgreSQL 互換エディションが使用されています。Amazon Aurora Global Database は 2 つのリージョンで構成されています。 us-east-1 リージョンはプライマリクラスター、 us-west-2 リージョンはセカンダリークラスターです。 計画的なフェイルオーバー、計画外のフェイルオーバーの両方に対応可能なグローバルデータベースエンドポイントの自動管理は、Amazon Route 53 プライベートホストゾーン、 Amazon EventBridge 、 AWS Lambda によって設定されています。
5. Amazon RDS Proxy for Aurora : Amazon RDS Proxy を使用すると、リーシングアプリケーションがデータベース接続をプールして共有できるため、スケーリング能力が向上します。また、アプリケーション接続を維持したままスタンバイデータベースインスタンスに自動接続できるので、リーシングソリューションのデータベース障害に対する耐性が高まります。
6. Amazon EventBridge : Amazon EventBridge は、主に次の2つの目的でソリューションをサポートします。
   1. リーシングフローの監視 – リース申請プロセス中、このソリューションは AvalonBay 、プロパティマネジメント、ファイナンスポータル、管理業務などの外部アプリケーションで使用される様々なイベントを生成します。リーシングイベントは AWS Lambda 、 Amazon Simple Notification Service (Amazon SNS) 、外部の API エンドポイントなど、複数の宛先に対してのイベントルールが設定された Amazon EventBridge に送信されます。
   2. Amazon Aurora Serverless v2 グローバルフェイルオーバー処理 – Amazon Aurora は、あらゆる種類のグローバルデータベースアクティビティを含むアクションやイベントをもとにイベント情報を生成します。
      1. 計画されたフェイルオーバーが実行された時 – AWS コマンドラインインターフェイス (AWS CLI) 、API 、コンソールのいずれかを介して、グローバルデータベースフェイルオーバープロセスが開始され、イベントが生成されます。
      2. Aurora クラスターの 1 つが AWS CLI 、 API 、コンソールを使用してグローバルクラスターから削除されると、Aurora クラスターは単一のプライマリクラスターとして昇格されます。このプロセスが完了すると、イベントが生成されます。EventBridge ルールは、グローバルデータベースが管理する計画的フェイルオーバーが正常に完了した際のイベントパターンに合わせて作成されています。フェイルオーバーが完了すると完了イベントが検出され、このルールがトリガーされます。イベントルールは、グローバルデータベースのフェイルオーバー時にトリガーされる Amazon CloudFront CNAME レコードを正しい値に更新する Lambda 関数を呼び出すように設定されています。

スケーラブルな検索ソリューション

リーシングの専門家は要求された情報を得るために、AvalonBay の検索ソリューションを使用して膨大な量の物件情報を簡単にスキャンできる必要があります。

Amazon OpenSearch Service を使用すると、エージェントはプロパティプロファイルやその他の資産データを生成して、一致するユニットを特定し、エンドカスタマーに迅速に対応できます。Amazon OpenSearch Service はビジネスデータや運用データのリアルタイム検索、監視、分析を安全に実現する完全にオープンソースの検索および分析エンジンです。Amazon OpenSearch Service はアプリケーション監視、ログ分析、オブザーバビリティ、ウェブサイト検索などのユースケースに採用されています。

Amazon OpenSearch Service を特徴とする AvalonBay 検索サービスのソリューションアーキテクチャを図 2 に示します。

図2 AvalonBay 検索サービスアーキテクチャ

AvalonBay の検索には、キーワードとURI検索、SQL ベースの検索、カスタムパッケージ検索を含んだ検索条件が必要です。これらの詳細は Amazon OpenSearch Service 開発者ガイドに記載されています。

Amazon OpenSearch は、障害が発生した OpenSearch サービスノードを自動的に検出して置き換えるため、インフラ管理に関するオーバーヘッドが軽減されます。このアーキテクチャーを段階的に詳しく見ていきましょう。

1. Amazon Kinesis イベントストリーム – AvalonBay コミュニティでは、アメニティ、機能、プロモーション、価格などの検索属性をニアリアルタイムで更新する必要があります。さまざまなプロデューサーによって作成されたイベントは Amazon Kinesis を通じてストリーミングされ、 Amazon OpenSearch Service に挿入、更新されます。
2. Amazon OpenSearch Service – Amazon OpenSearch Service はエンドツーエンドのコミュニティ検索に使用されます。マネージドサービスによってAmazon OpenSearch Service クラスターは AWS クラウドに簡単にデプロイ、運用、スケーリングすることができます。コミュニティ検索データは読み取り専用であるため、使用頻度に応じて UltraWarm ストレージとコールドストレージを使用します。
3. Amazon Simple Storage Service (S3) – さまざまなコミュニティ文書、ポリシー、画像ファイル、動画ファイルは主要な検索要素です。これらは契約上の義務により、何年にもわたって安全かつ確実に維持されなければなりません。Amazon S3 は、高い耐久性、ライフサイクルルール、さまざまな保存管理により、この作業を簡素化します。

まとめ

この記事では、AvalonBay が AWS のサーバーレスプラットフォームを利用して、耐障害性、パフォーマンス、拡張性を損なうことなく、カスタムされたリーシングと検索ソリューションをデプロイした方法について説明しました。このソリューションはフルマネージド型で年中無休で稼働し、オンプレミスに追加の機器を用意する必要はありません。

リーシングと検索のソリューションに AWS を選択したことで、AvalonBay はコスト面でのメリットを生かしながら、動的に規模を拡大し、将来の成長需要に対応できるようになりました。さらに、AWS のサービスは世界中で利用できるため、パフォーマンス要件を満たすサービスを地理的に離れた場所にデプロイすることが可能になります。

著者について

翻訳はソリューションアーキテクトの奈良が担当しました。原文はこちらです。