サーバーレスアプリケーション開発におけるエラーハンドリング

みなさん ! サーバーレスアプリケーションの開発楽しんでますか ?

サーバーレスアプリケーションの開発は、インフラ面での非機能要件の責任を AWS のマネージド型サービスに委譲できることから、アプリケーションの本質 である ”ロジック開発" に注⼒できる点が私は大好きです ! 機能を実装していくプロセスは、明確にやりたいことに向かって進んでいくこともあり、成果がわかりやすく非常に楽しいですよね。

しかしサーバーレスアプリケーション開発は実現したいロジックの実装に集中できるからといって、正常系の実装の検討しか行わずに、サービスをリリースしていませんでしょうか ? サーバーレス環境でアプリケーションを動かせば、無条件に品質の高いアプリケーション実現できるかと言うとそうではありません。インフラ面での非機能要件はクラウドサービスに任せられても、アプリケーション面でのエラーを含む例外的な処理に対しては、皆様で責任を負う必要があります。

つまり我々開発者は、正常に処理ができないあらゆるケースに対しての挙動を制御する必要があります。そのような処理のことをエラーハンドリングと呼びます。

エラーハンドリングが不十分なアプリケーションは様々な問題を抱えています。具体的には挙動が不安定であったり、バグ発生時に原因を特定しづらかったり、論理不整合を許容してしまったりします。こういった理由より、システムをリリースする際にエラーハンドリングの実装は必須です。

それにもかかわらず、エラーハンドリングの実装は、本来実現したいこととは直接的には関係のない処理であることから、そもそも検討がなされなかったり、また想定されるエラーケースのモレが見落とされたりして、エラーハンドリングが不十分な状態でアプリケーションがリリースされてしまうシーンも多いように思われます。

エラーハンドリングを検討する上で、網羅的なケースをカバーをするにはどのような検討を行うべきでしょうか。エラーのパターンはエラーの発生箇所の観点で、アプリケーション内で発生するエラーとアプリケーション外で発生するエラーに分けられます。

アプリケーション内で発生するエラーの例としては、コード起因によるRuntimeErrorや、ロジック起因による論理不整合によるエラーが挙げられます。このようなエラーは、実行されるプログラムのロジックにエラーの処理を含むことで、エラーハンドリングを行います。

一方アプリケーション外で発生するエラーの例としては、環境起因によるインフラ障害やNW障害や、設定起因によるスロットリングなどもあります。このようなエラーはアプリケーションを起動している側でエラーハンドリングを行います。

様々なエラーのパターンに対して検討すべきことはいくつもありますが、サーバーレスにおいては主にイベントによって生成されるメッセージの受け渡しや、メッセージのごとの処理の制御を行うための検討が重要です。言い換えると、メッセージを確実に受け渡しを行うためにどういった手法や機構を利用するのか、受け渡したメッセージが正常ではなかった場合にどの様なハンドリングを行うべきなのかについての検討が必要となってきます。

こういったエラーハンドリングを行うための手法について、全体観を以下のようにまとめました。これら 1 つ 1 つについて説明していきます。

メッセージの受け渡しの精度を高めるためのエラーハンドリングとしてリトライがあります。リトライについて検討するポイントとしては「何回またはどの期間リトライするか」、そして「どれくらい実行間隔をあけるか」になります。

配信セマンティクスは重複の管理を示す属性です。「At-Least-Once Delivery」と「Exactly-Once Delivery」 の 2 つの概念を紹介します。

At-Least-Once Delivery (少なくとも 1 回) は、「メッセージは欠損しないが重複しうる」という意味で、場合によっては 1 回以上のメッセージのコピーが配信されることがあります。SQS 標準キューや SNS 標準トピックのはこの属性を持ちます。この場合後続処理のべき等性について考慮し、同じ処理を複数回処理することによる論理的不整合が発生しないか検討すべきでしょう。

一方 Exactly-Once Delivery は (正確に 1 回)、「メッセージは欠損しないし重複もしない」という意味で、メッセージ配信における重複排除を提供します。FIFO キュー、FIFO トピックやストリーミングを扱うメッセージストレージはこの属性を持ちます。この場合、スケーラビリティについて考慮し、十分なスループットが担保出来ているのか検討すべきでしょう。

順序セマンティクスは順序の管理を示す属性です。「ベストエフォートな順序づけ」と「FIFO」の 2 つの概念を紹介します。

ベストエフォートな順序は、後続のワーカーにて処理される順番が担保されない代わりに、高いスループットを実現します。SQS 標準キューや SNS 標準トピックのはこの属性を持ちます。この場合処理の順序が担保されなくとも、データとしてはその後順序が必要になってくることも考慮し、各々のメッセージで後からソートできる情報を付与させるをこと検討すべきでしょう。

一方 FIFO 配信は順序性の担保を実現します。FIFO キュー、FIFO トピックやストリーミングを扱うメッセージストレージはこの属性を持ちます。FIFO 配信を採用する主なユースケースとしては、注文処理やチケット予約システム、金融取引などが挙げられるでしょう。この場合 FIFO 配信になることでどこかのメッセージで処理がストップしてしまうと、処理全体に影響が出てしまうので、データの破棄や退避や、FIFO である必要性の有無の検討などが必要になります。

メッセージの受け渡しにおいて、リトライは一時的なエラーやランダムなエラーに対しては効果がありますが、同様のリクエストを行っていたところで、何度もエラーを繰り返すだけとなるような、再現性のあるエラーも存在します。こういったエラーに対してはメッセージの破棄、または退避を行います。

マイクロサービスやワークフロー系のシステムにおいて受け渡したメッセージが正常でなかった場合、フローの途中でエラーが発生すると、複数のデータストアが全て正常に更新を完了しているか、またはすべてのデータストアが更新前の状態にロールバックされているかのどちらかの状態にする必要があります。従来のモノリシックなアプリケーションであれば、RDB のロールバックを利用することで、このような問題の発生を防ぐことが出来ますが、マイクロサービスにおいては、サービスごとに固有のデータベースを持つため、複数のデータベースにまたがってビジネス的な状態が更新前と整合する状態に戻すため専用の処理を行う必要があります。これが補償トランザクションと言われる処理になります。

これらのユースケースを実現するアーキテクチャ例として、公式サイトの サーバーレスパターン や、AWS Black Belt Online Seminar の  形で考えるサーバーレス設計 サーバーレス ユースケースパターン解説 があります。こちらについても合わせてご覧いただけると理解が深まるかと思います。