サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ

そもそも、べき等性とは、どういうことを言うのでしょうか ? これは「ある操作を 1 回行っても複数回行っても結果が同じである」ことをいう概念です。

こうした障害復旧のケースでは、全体フロー内で、障害が起きた場所より前のステップにあたるどこかを復旧ポイントとして、そこから再実行するような手順が一番よく使われます。この再開する処理は、べき等性が求められるポイントになっています。今のシナリオでは、障害復旧時に中間データを削除して再実行、としました。これを踏まえて、そもそも処理2の最初の初期化タスクとして中間データの削除という実装が備わっていたら、処理2は、復旧作業に関わらずべき等性が保証された処理ということになります。

今あげた例でわかるように、べき等性という性質は、マイクロサービスやサーバーレスに特化したことではありません。

では、なぜ、べき等性がマイクロサービスやサーバーレスの文脈で強調して必要性を言われるのでしょう ? 理由は 2 つあります

1. マイクロサービス / サーバーレスでは、一つの処理単位が小さく独立している
2. サーバーレスでは、リトライが自動で実行されることがある
   

正常終了の場合はどちらでも変わりはないですが、なにか問題や障害が起きた場合やトランザクションのキャンセル時の対処は変わります。マイクロサービス型では、個々のマイクロサービスで一つの処理が完結しているため、一連のフローの途中からの再開がしやすい反面、業務トランザクションの単位でのキャンセル処理は少し複雑になります。

加えて、サーバーレスアプリケーションでは、マイクロサービスに該当する処理関数 (AWS Lambda) のリトライ処理が自動で行われる設定があります。例えば、Amazon S3 → AWS Lambda の連携処理などでの リトライの自動管理・実行 です。リトライは、Lambda 関数のコード実装の不備や実行時メモリ不足などにより関数実行が正常に終了しないケースで行われますが、前述の障害復旧の例を思い浮かべていただければ、この Lambda 関数でべき等性が考慮されている必要があることが理解できるでしょう。

マイクロサービスやサーバーレスアプリケーションでべき等性の考慮が強調されるのは、このような理由からです。

別の議論として、マイクロサービスやサーバーレスではステートレスな処理・関数の実装が求められます。処理や関数が内部でステート (状態) を持たないようにするということです。これはべき等性と強い関連があります。

ステートフルは、二度目以降の呼び出しの対象となる処理リソース (インスタンス、プロセス) が一度目と同じであることを期待した作りになっています。これにより、処理効率の良さ、レスポンスの最適化などのメリットがある反面、障害に弱い、スケーラビリティにかけるなどの課題に繋がるため、トレードオフの議論だといえます。一般に、ユーザー数やデータ量が増加する可能性があるアプリケーションでは、個々の処理のベストなレスポンスを求めるよりも、処理の並列化 (スケーラビリティ) で解決するほうが得策です。

ステートフルを避ける典型的な方法は、ステートを内部保持するのではなく、外部のデータベースなどに保持して、データとして都度出し入れすることです。ステートを内部保持する方式と比べるとレスポンスに影響が出ることは想像できますし、データベースの利用が増える、処理コードが煩雑になるなどのデメリットも思い浮かびます。処理ロジック内の内部変数でステートを保持したほうが効率的に見えますが、「早すぎる最適化は諸悪の根源」という言葉があるように、ある一時点での局所的な最適化を求めることの良し悪しは冷静に見極めて判断してください。ステートレスであることは、べき等性の確保のための第一歩になりますが、それ以前に、スケーラビリティや可用性を高めるという意味で、サーバーレスやマイクロサービスとは関係なく価値があります。

べき等性の考慮が必要になるのは、おもに処理内でなにかのデータストアに書き込みをするような部分が中心になります。読み取りのみの処理では、ステートレスであることを意識すれば十分です。

書き込みを行う処理は、ステートレスであることだけでは不十分で、複数回の実行が行われても結果に違いが出ないように実装に注意する必要があります。

冒頭の例であげた、お客様の特定の注文に対する確定処理をもう一度思い浮かべてください。それがたとえシステム上の都合で複数回実行されたとしても、業務データとしては一つの注文であるべきです。複数の商品が配送されては問題ですし、課金が二重三重になっては困ります。このような場合には、どこかで複数データを解決することが必要になります。

べき等性をどのスコープで保証するか、というのも考慮すべきポイントになります。
複数のマイクロサービスの組み合わせで一つの業務トランザクションが成り立つようなケースでは、個々のマイクロサービスの失敗やキャンセルよりも、業務トランザクションとしての成否のほうが業務的に重要です。業務トランザクションを意識した、より大きなスコープでのべき等性の確保という視点が必要になってきます。

次では、データの重複の解決や、より大きなスコープでべき等性を考えるということについて触れます。

ある処理 X がデータストアに書き込みを行うケースを想定します。

データストアへの書き込み処理を複数回やっても結果として処理対象となるデータは論理的に一つ、という状況にすることがゴールです。このために、特定の処理リクエストが論理的に同じであることを判別するための一意な値を、処理X の呼び出し元で生成して引数として渡す形が望ましいです。その引数の値によって、処理リクエストが同一のリクエストなのか別のリクエストなのかを判別できます。

それぞれの業務において、何が一意な値になるのかは見極めが必要です。例えば、ネットショッピングで購入確定に伴って処理を呼ぶような場合、Web セッション ID を一意の値とするのでは不十分です。一つの Web セッションで複数の購入を行う可能性が考えられるからです。対応策として、購入アクションのタイミングでセッション ID とタイムスタンプで一意の値を生成するなどが考えられます。こうして用意した一意の値を、処理 X を呼ぶ際の引数に使います。

一意の値を伴って呼び出される処理 X がべき等性を保証するための実装として、典型的な形が 2 つあります。

• データストアへの入力 / 登録時にチェックする
• データストアからの出力 / 取得時にチェックする
  

データストアへの書き込み時に注意を払うやり方です。処理 X が複数回実行されてもデータが重複して格納されないように、データストアの一意属性を使って重複をチェックします。

• 一意の値を引数として受け取る。
• データストアへ格納する際に、データストアとなる DB がもつ一意性チェックの機能を利用する。
• 一意性チェックでエラーが出た場合、複数回実行されたことを認識して、例外処理でログに残し、正常終了とする。
• 定期的にログを確認し、重複実行の状況を監視する。特に運用開始当初は、業務的には弾くべきではなかったデータ投入処理を実装の不具合でエラーにしていないかを注意してチェックする。
• 処理 X 側では、データストアに対する一意性チェックのエラーが来たら複数回実行されたことを認識してログに残し、正常終了する

前提として、データストア側での一意性チェック機構が必要になります。データストアに格納された内容は整合性が確保された状態になりますので、別の開発チームがこのデータを利用して後続の処理を開発するような場合に、あまり深い考慮がなくても読み取り処理でデータ整合性の問題は起きません。

参考 : Lambda 関数を冪等にするにはどうすればよいですか ? »

データストアから読み取る際に注意を払うやり方です。データストアへの入力時にはデータ投入の重複を許容するため、入力時のチェック作業 / 負荷を軽減させることができます。

• 一意の値を引数として受け取る。
• データストアへの格納では重複チェックをせずにすべてのデータを格納するようにする。
• データソースからの読み取り時に、一意判定をする属性を使って、重複を排除して取得する (SQL クエリで Distinct 句を使う、など)
  

実際の業務では、もう少し事情は複雑です。

ネットショッピングのケースを考えてみます。利用者が商品を選択した後、購入に至る過程では、在庫から商品の個数を引当てて、注文を確定します。この一連のトランザクションを完了するには、在庫データの更新、注文データの更新の 2 つが少なくとも必要ですし、連動して、顧客のポイントデータの更新、配送用のデータ連携や決済のための処理も発生します。

このうち、在庫データの更新と注文データの更新は、ほぼ同時に行う必要があります。必要な個数の在庫が引き当てられなければ、注文を成立させることができません。商品が複数存在する場合、すべての商品の在庫引当ができてはじめて注文確定に至ります。こうした複数のデータ更新が求められるケースでは分散トランザクションを使うことがあります。これはシステムとして All or Nothing でトランザクションの可否を判定する形になります。

• 在庫引当をそれぞれの商品で実施
  → すべてうまくいけば注文確定として、予約を確定化させる (コミット)
  → どれかがうまく行かなければ、予約をキャンセル (ロールバック)

マイクロサービス方式では、例えば、こうなります。

• 在庫引当 (予約) をそれぞれの商品で実施: 予約フラグを立てる
  → すべてうまくいけば注文確定として、予約を確定化させる
  → どれかがうまく行かなければ、予約できた分だけ発注するかどうかを判断
  　→ 部分注文の確定 or 予約キャンセル (予約フラグのリセット)

このようなケースでは、個々の処理機能の単位でべき等性を確保していたとしても、それとは別に業務スコープでの考慮が必要になります。一部の処理機能で期待通りの結果が得られなかった場合に、その処理機能だけではなく、業務スコープでの整合性の取れたキャンセル処理の検討が必要になります。これは、キャンセル処理を自己制御することになります。自己制御するということは手間ではありますが、より柔軟な制御ができるともいえます。前述の例では、部分注文の確定といった機能を実装可能になります。

もう少し時間を伴うケースを見てみましょう。
購入・配送した後、お客様が実物を見てやっぱりキャンセル・返品するという場合、以下のようなことが起こります。

2 つの例で紹介したキャンセル型の処理を補償トランザクションといいます。

All or Nothing で良ければ、従来型の分散トランザクション機能に頼るほうがシンプルです。しかし、上記の例のように、すべてのケースで分散トランザクションが利用可能なわけではないので、補償トランザクションの考え方はどちらにしろ必要になるでしょう。

すべてをマイクロサービスで、補償トランザクションで、ということでもありません。要件によっては、部分的に従来型実装 (分散トランザクション) を使うというのも一つの判断だと言えます。補償トランザクションは設計を複雑にしてしまうデメリットはあるので、トレードオフを適切に判断してください。アプリケーション全体が一枚岩なモノリスでないなら、部分的に従来型実装を使った機能が含まれても、全体としてマイクロサービスのメリットは得られる、という思考ですすめるのが良いのではないかと思います。

サーバーレスアプリケーションは、自然にマイクロサービス型の効果が得られます。その意味で、サーバーレス設計にはべき等性やステートレスの考慮が必要になってきます。こうした考え方に慣れるという意味では、サーバーレスやマイクロサービス型の設計を読み取り型の処理やシンプルな更新処理から始めると良いかもしれません。

今回は、AWS のサービスに依存するような内容に極力触れない形にしました。次回は、AWS のサービスを使ってこれらの典型的なべき等性のパターンを実装するとどのような形になるのか、どんな機能を使うと便利なのかをご紹介します。