AWS上のレジリエントなシステムの構築

第4章. サーバーレス・アカウント・オープンAPI

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

便利なフロントエンドのユーザインタフェースは、ユーザ体験に命を吹き込むトランザクショナルサービスに支えられていることが多い。 口座開設サービスを検討する際には、第6章までに完全に組み立てられる完全なブローカープラットフォームの一部であることを想像してほしい。ブローカー顧客のゴールは、の新規口座を簡単かつ確実に開設し、株式投資を開始できるようにすることである。 証券会社の新規口座開設は、口座開設後に行われる高頻度の取引に比べ、取引量が少ないことを念頭に置いておこう。 さらに、ストレート・スルー処理モードで開設できる口座もあれば、支店での本人確認、人による承認、処理エラーやエントリエラーの処理など、オフラインのステップが必要な口座もある。 信頼性を最適化するため、口座開設サービスは非同期で、リソース使用量とコストを最適化するAWSサーバーレス・サービスで構築されている。

口座開設サービスはコントロールプレーンと考えることができる。 顧客が取引するために必要なインフラ、証券口座を作成する。 取引はデータプレーンであり、トランザクション的でリアルタイムであり、一度作成されれば、もはやコントロールプレーンの演算子に依存することはない。

デプロイとレジリエンステストシナリオを単純化するために、このサービスは、NoSQL データベースへの永続化という 1 つのビジネス機能のみを実行する。 現実の世界では、証券会社の Account Open サービスは、コンプライアンスチェック、顧客検証、法的文書生成、文書保管、取引シス テムへの永続化といったステップを含むワークフローをオーケストレーションする。 この章では、レジリエンスの概念を、より複雑なサーバーレスとイベント駆動型ワークフローに拡張するために必要な知識を得る。

この章では、AvailableTrade アプリケーションで新しい証券口座を確実に開設する非同期マイクロサービスをデプロイしてテストする。 あらかじめ構築されたソリューションとテストクライアントをデプロイした後、AWS ネイティブのサーバーレスレジリエンス機能とその対処に役立つデザインパターンを探求する：

• 無効な入力を処理する

• 重複投稿

• メッセージキュー処理の失敗

• 予期せぬ負荷スパイク

• 毒薬

• 地域障害

• ブルーグリーンコードデプロイ

テストシナリオを通して、障害を誘発し、回復することで、一般的な障害モードを軽減する方法を学ぶ。 組み込みのサーバーレス・レジリエンス機能とデザインパターンについて徹底的に理解する。

技術要件

ほとんどすべてのWeb対応ビジネスシナリオにおいて、ユーザ起動のアクティビ ティはAPIへのHTTPリクエストで始まる。 リクエストはまずHTTPリスナーによって受信され、そのリスナー はリクエストを処理コンポーネントに転送し、その処理コンポーネントはリクエストデータ に対して処理を実行し、その後レスポンスを提供する。これを同期リクエストフロー(図4-1)として視覚化することができる。リクエスト側は、レスポンスを受信する前に、すべての処理が完了するまで待機する。 同期フローは、成功するために、外部コンポーネントが利用可能で、遅延制約内で 動作することに依存する。 ハードディペンデンシーで障害が発生した場合、応答は顧客に引き渡されない。 ...