オンプレで稼働しているアプリケーションをAWS等のパブリッククラウドへマイグレーションすることやそこからクラウドネィティブなデザインへ変更する際には、同時並行性について考慮する必要があると思いますので、この記事で紹介しようと思います。
同期処理アプリケーションでは
同期処理でAPI処理を実装する場合、リクエストを受けるハンドラがあって、そのリクエスト内容に応じて、リレーショナルDBへ問い合わせて、結果を返すというような仕組みになるかと思います。マイグレーションするときに、リホストでAWSへのマイグレーションを行うと大抵下記のようなパターンになります。
実は、この構成はスケーリングの観点で考えると問題があります。
高負荷の状況でのAmazon API Gateway、Amazon Lambdaは、需要に応じて、素早く、スケーリングされます。Amazon API Gateway、Amazon Lambdaがスケールするので、RDSへの同時接続が増えるということです。リレーショナルDBでは、データベースコネクション数(=同時接続数)というものが決まっているので、それを超えてしまったり、リソース上限(=スロットリング)と呼ばれるような問題が発生して、サービスの停止を引き起こす可能性が上がります。
クラウドネィティブにするには
AWSを始めとするサービスが提供するServerlessプラットフォームでは、需要に応じて、素早く、簡単に、スケーリングするサービスが多くあります。上のような同期処理で処理フローを行うとどこかでしわ寄せが発生します。このようなケースでは、非同期モデルの疎結合なアーキテクチャを採用することで、上記の問題に対処できます。
AWSでは、非同期イベントソース(Amazon Kinesis、Amazon SQS)を使って、非同期な処理へ変更することができます。
このようにすることで、上位からの要求に対しては、柔軟にスケールして、RDSへの同時接続に絡んだ問題への対処も行うことができます。
スケーリングする際の考慮点
上の例でも見てきましたが、スケールする際に考慮しなければならない点は、同実行された際の挙動です。Concurrency(同時並行性)については、常に意識して考えなければなりません。また、上の例では、AWS Lambdaが複数回起動された際の冪等性の問題についても残っています。この問題については、別の記事でまとめたいと思います。
今回は、クラウドネィティブ化する上で最も重要だと考えられるConcurrency(同時並行性)について例を交えて見てきました。設計や実装の際に頭に入れておくことをおすすめします。