障害は必ず起こる。だから事実として受け入れ、レジリエントでなければならない。それは単に、ソフトウェア・システムをよりフォールトトレラントにする、という意味ではない。ビジネスプロセスをもっとリアクティブに再設計することが必要だ。そうすれば、ソフトウェアもそのように振る舞うことが可能になる。Bernd Reucker氏はQCon Londonで、"Moving Beyond Request-Reply: How Smart APIs are Different"と題して講演し、このような指摘を行った。講演のビデオとその内容はInfoQで公開されている。
Reucker氏は、障害を処理する一般的な方法として、ユーザにエラーメッセージを表示するなどの例をいくつか紹介した上で、それらがユーザエクスペリエンスとして不満を残す理由について説明した。氏が航空機の搭乗券をプリントアウトできなかった時、"後ほど再度お試しください"というエラーメッセージが表示された。そのため氏は、ステートフルな再試行マシンを作らなければ(自分自身で再度実行しなければ)ならず、そのためのリマインダをカレンダに追加した。より望ましいソリューションは、システム内部にステートフルな再試行の仕組みを用意して、ユーザにその旨を通知した上で、搭乗券が発行された時に自動的にそれを送信することだろう。
この種の調整には、障害に対応するビジネスプロセスと、新しい、より複雑なプロセスを実装するソフトウェアの両面での再考が必要になる。このようなケースの大部分には、長期間動作とリトライの実装が可能なワークフローエンジンのように、耐久性のあるステートマシンが関与することになる。さらに氏は、可能な限りプロセスを冪等(idempotent)にするように提案する。それにより、副次的影響のない安全なリトライが可能になるからだ。
すべての分散システムには管理を要する複雑性が伴っており、それがReucker氏の言う"スマートAPI"につながっている。長期間動作するサービスの実装が可能であることが、スマートAPIには不可欠だ。一般的なリクエスト/リプライAPIはステートフルではないので、Reucker氏は(Sam Newman氏の言を引用しながら)、"無気力(anemic)なサービスに指示のできるような、スマートな神(god)サービスをいくつか"付け加えておくように提案している。
スマートエンドポイントは長期間動作しているので、長期間動作するサービスを実装可能であることは、技術的な理由ではなく、ビジネス的理由において重要である。これには非同期通信の必要性が伴うため、さらなる複雑性をもたらすことになる。Reucker氏は非同期通信のおもな問題として、レイテンシの増加、可用性の低下、実装の難しさ、UX面での考慮が必要、などの点を指摘した。
一般的なパターンのひとつは、ウェイトとコールバックあるいはポーリングによって同期性をシミュレーションすることだが、この方法も万能ではない。障害を処理する単純な技術的ソリューションというものは存在しないので、ビジネスプロセスをよりリアクティブに再設計する必要がある。そうすれば、ソフトウェア設計をそのリアクティブなプロセスに合わせることが可能になるのだ。
講演のまとめとしてRucker氏は、リアクティブシステムではイベント駆動アーキテクチャ(EDA)が多用されているが、そのリスクを十分に理解することが必要だ、と説明した。EDAは通知サービスにおいては優れたパターンだが、ピアツーピアのイベントチェーンでは問題になる。実際のワークフローが見えなくなり、ワークフローの変更に複数のサービスの修正が必要になるため、結果として独立的なマイクロサービスの目的が損なわれることになるのだ。オーケストレーションとコリアグラフィ(choreography)のバランスを取ることが、優れたソリューションには必要である。氏は、Martin Fowler氏の書いたイベント駆動システムに関するさらなるアドバイスを読むことを推奨している。